Level: Intermediate Nicholas Bennett (nbennett@ca.ibm.com), Software Engineer,
IBM
Natalia Balaba-Liaskovski (nbalaba@ca.ibm.com), Software Engineer,
IBM
26 Dec 2007 IBM® Rational® Software Architect provides the necessary tools to use
UML to model SOA solutions when you are developing service-oriented architecture (SOA) for
your software. This four-part series of articles explores this SOA
transformation functionality. This article explains how to use IBM®
WebSphere® Business Modeler and Rational Software Architect to transform a
business process to an SOA model.
Overview of the Business
Process Analysis model
A typical development cycle starts by capturing and analyzing business
requirements and goals. Part of the analysis consists of identifying core services
that are necessary to create service-oriented architecture (SOA) solutions to meet
business requirements.
The task of analyzing business requirements typically falls to a business
analyst, who usually uses IBM® WebSphere® Business Modeler to create a
Business Analysis model (also called a Service Specification
model), as well as to refine, extend, or optimize this model by using the
built-in analysis and simulation functions of the WebSphere software. The end
product of this analysis stage is a model that defines core services (business
processes), how they interact, and how they are invoked by actors or other
services.
You can find a detailed outline of service specification modeling in the
"Modeling SOA: Service Specification" article from the
"Modeling SOA" series by Jim Amsden (see
Resources).
Transforming a business
process to high-level architecture
The next step in the cycle is to transition the Business Analysis model into a
Design Solution Architecture model. This is a task typically performed by a
software architect. The Business Process-to-Service Model transformation feature
of IBM® Rational® Software Architect aids this transition.
You can use a WebSphere Business Analysis model project within the Rational
Software Architect workbench that is configured with the WebSphere Business
Modeler Integration feature. When you open it, the software creates an in-memory
UML representation of the business model that you can use as the basis for
modeling business operational requirements.
The Business Analysis model from WebSphere Business Modeler is converted into a
UML representation by reflecting a role-based view of the business process. That
is, you can look at a business process as a collaboration between the required
roles for the tasks and the services involved in the process. You can view each
required role as a UML interface that defines operations for each task and
WebSphere Business Modeler service, for which it is responsible. Figure 1 shows a
portion of a business process in WebSphere Business Modeler that describes how to
handle customer orders in a business. In this view, the process shows swim lanes,
with each representing a particular role that participates in the process.
A portion of a WebSphere
Business Modeler process for Customer Order Handling
The UML representation of the business process includes a UML use case that
represents each process, as well as Actors for each of the roles that participate
in the use case. This representation shows the relationship between roles and
processes at a high level of abstraction, which is suitable for getting an
overview of a business process. Figure 2 shows the use case and Actors for the
Customer Order Handling business process.
Figure 2. UML use case
representation of the Customer Order Handling business process
Figure 3, which follows, shows the UML collaboration that represent the same
process, along with its relationship to the UML interfaces that represents the
required roles and the UML use case for the process. In the figures that follow,
notice that the tasks that Figure 1 shows as requiring the
CRMApplication role (Determine Requester Status, for example) have been translated
into operations in the CRMApplication UML Interface (see
Figure 3).
In addition to the use case and collaboration, the behavioral aspect of the
business process (that is, how the roles interact with each other in performing
their tasks) is represented as a UML Activity owned by the collaboration. Each
task from the original business process is represented by a UML Call Operation
action that invokes the appropriate operation, as defined in the role interfaces
described previously. Flows between tasks, as well as the control nodes
(decisions, forks, merges, and so forth) are also represented in the UML Activity.
The collaboration shows which roles work together to define a process, and the
Activity specifies how these roles interact with each other. The partitions within
the activity represent the roles within the collaboration. This UML model provides
what is, in essence, a specification that defines both structural and behavioral
requirements that must be satisfied by any solution model that implements the
business process.
Figure 3. UML collaboration for
the Customer Order Handling business process showing relations to use case,
interface, and Activity
Tip:
See the business services modeling article in the Modeling SOA
series by Jim Amsden, cited in Resources, for a more
thorough discussion of the relationship between elements of the WebSphere Business
Modeler Business Analysis model and the UML counterpart.
Figure 4. UML representation of
the WebSphere Business Modeler model in Rational Software Architect
The UML representation of the model in WebSphere Business Modeler is intended to
be viewed as a requirements contract to be fulfilled by an architected solution
model. The purpose of Business Process-to-Service Model SOA transformation feature
in Rational Software Architect is to create an initial, or default, SOA solution
model.
To create and configure this transformation, select Modeling >
Transform > Create new configuration menu in the Modeling perspective
(see Figure. 5). The transformation will accept a model open in WebSphere Business
Modeler as a valid source and any Eclipse project as a valid target.
Figure 5. Creating a
transformation from a business process to a service model
Figure 6 shows a single WebSphere Business Modeler model and a target, which can
be any Eclipse project or folder where you want to put the output generated by the
transformation.
Figure 6. Specifying the
transformation source
The UML services model created by the transformation represents a service
decomposition from the analysis model for each business process. You can configure
the type of the decomposition from the transformation UI and apply it to an
individual business process. The structure of decomposition depends on the target
domain (implementation language, deployment environment, and so forth).
The decomposition for each service will be produced by an extension. Although the
transformation comes with three extensions, it is not limited to these three (a
high-level UML, a generic SCDL decomposition, and an empty implementation for Do
Not Transform). The transformation is extendable and allows clients to create and
add custom extensions. We will take a closer look at each default extension in
detail later in this article.
After the model is generated by the transformation, system or software architects
can further refine the service model by specifying more implementation details or
creating references to other services or legacy libraries for reuse.
Contract verification in
requirements traceback
Regardless of any specific decomposition, the architected solution model created
by the transformation (also called a service model, or contract
fulfillment model) preserves the contract information defined in the
specification model. It also provides the implementation details required to
fulfill the contract.
A business process in the specification model is represented by a UML
Collaboration element. UML Collaboration elements from the specification model are
transformed into UML Component elements in the architected solution model. The
transformation populates the generated components with ports that specify
interfaces for services required or provided by the business process.
In addition, the transformation generates a
CollaborationUse element inside of each component. The
CollaborationUse element maintains a link between the original Collaboration
element in the specification model and the Component element in the service model.
The transformation creates UML bindings between component ports and collaboration
roles. The port and role bindings established through the CollaborationUse element
define the roles in the contract requirements that are played by parts in the
services software. This enables traceability between the solution and the business
requirements that it fulfills, as well as a means of verifying that the solution
actually meets the business requirements represented by the WebSphere Business
Modeler business model.
Consider the example in Figure 7, which depicts a contract verification for the
Customer Order Handling business process and the associated service model.
Figure 7. Example of a
composite structure diagram
The Customer Order Handling component that represents the service contains a
CollaborationUse element with a Collaboration type that points back to the
Customer Order Handling Collaboration element defined in the Business Analysis
model created in WebSphere Business Modeler. The Customer Order Handling
Collaboration roles are played by (or bound to) the component ports. Each port
specifies interfaces provided or required by this business process, as outlined by
the Business Analysis model. For example: The port that provides an interface to
the service (myRole) is bound to the Collaboration role, which represents the
business process itself. The other ports, which represent various actors
(potentially, other services), are bound to their respective roles in the
Collaboration element. These ports (for example, PaymentHandling,
OrderVerification, CRMApplication, and so on) require interfaces to communicate
with the pertinent Actors. Both required and provided interfaces are defined in
the WebSphere Business Analysis model, and the services model in Rational Software
Architect points back to those interfaces, as Table 1 shows.
Table 1. Transformation mapping
| Specification model element | Transformation output (UML high-level architectural model) |
|---|
| Model or package | The transformation creates a UML model or package with the same name, a
containment structure for nested packages, and collaborations. Nested packages
or collaborations might also contain UML activities. Interfaces, classes
and data types, and activity elements are not transformed. When necessary,
the generated model creates use relationships that correspond to these
elements in the source model.
The generated model has the
<<serviceModel>>
stereotype applied to it.
|
|---|
| Collaboration | The transformation creates a UML component with the
<<serviceProvider>>
stereotype from the Software Services profile applied to it. The generated
component has the same name and containment structure as the source
Collaboration element. The transformation creates a CollaborationUse
element for each component.
The type of the CollaborationUse element is set to the collaboration
element in the source model.
Each port in the generated component binds to a respective role in the
collaboration through the CollaborationUse element. For details about the
ports that the transformation creates, see the Collaboration role::type
row that follows in this table.
|
|---|
| Collaboration role | The transformation creates a UML port on the component. The generated port
has the same name as the role in the source model. Each port binds to a
role by using a collaboration use relationship.
|
|---|
| Collaboration role::type | If the role::type property specifies the same
interface that is realized by the collaboration element, the
role::type property is set to an interface that is
provided by the port. The type of the port is also set to that interface.
All other role::type properties are set to a
required interface. The transformation sets the port type to a UML class
that has a use relationship to the interface that is defined by the source
model. The name of the UML class in the use relationship is the same as the
interface name in the source model, but with a suffix of
Protocol.
|
|---|
Electing process
decomposition
The Business Process to Service Model transformation provides extensions for
transforming business processes in a specification model.
The Default Implementation decomposition describes the behavior of the process by
assigning a UML Activity as an owned behavior of the business process, as
represented by UML Component (see Figure 8). This decomposition can later be used
by the UML-to-SOA transformation to generate Services Component Definition
Language (SCDL) modules with Business Process Execution Language (BPEL) artifacts.
Figure 8. Using the
transformation configuration to specify the decomposition type for each business
process
As Figure 9 shows, the default Implementation extension produces decomposition
where behavior is described by an Activity element that is cloned from the
business analysis model.
Figure 9. Default Implementation extension
Note:
The Do Not Transform option is offered in case you do not want
to consider certain processes for transformation. This extension simply means
"Ignore this process."
The Skeleton Only implementation transforms behavior into structure, creating a
generic decomposition for Services Component Definition Language (see Figure 9).
It produces an inner component for each Collaboration role in order to perform any
preprocessing (such as obtaining proxies, for example) before making a call to the
role's respective Actor (possibly another service). A model such as this
can be used by the UML-to-SOA transformation to generate output, which can be
deployed by the IBM® WebSphere® Integration Developer.
Figure 10. SCDL decomposition
created by the Skeleton Only extension
To create UML service models that contain implementation details for other
domains, clients can create and register custom extensions for the Business
Process-to-Service Model transformation.
An example of creating customized decomposition will be presented in the next
article in this series, "Transformation to SOA: Part 2. Creating a custom
extension for the Business Process-to-Service Model transformation feature in IBM
Rational Software Architect" (see More in this series above the
table of contents here).
What Part 2 covers
This article focused on integrating WebSphere Business Modeler artifacts into the
Rational Software Architect environment and the tooling provided to create a
bridge between business models and software analysis and design models. Part 2
gives you a step-by-step example of how to create a custom process decomposition
for transforming a business process to a service model. It is intended for readers
who are familiar with authoring transformation extensions.
Resources Learn
Get products and technologies
Discuss
About the authors  | | | Nicholas is a software engineer supporting IBM Rational software tools. |
| | | Natalia is a software engineer supporting IBM Rational software tools. |
Rate this page
| 
