Introduction
Rational Software Architect for WebSphere Software (henceforth "RSA") provides an extensible UML-to-SOA
transform. The productized implementation generates artifacts that are targeted for downstream consumption
by WebSphere Integration Developer version 6.0.2 or later, for use in process choreography and service deployment
into WebSphere Process Server. These artifacts include a set of Module and Library projects that
contain SCDL artifacts, as well as referenced XML Schema Definition (XSD), Web Services Description Language
(WSDL), and Business Process Execution Language (BPEL) resources.
-
See
Transforming UML models into
software services artifacts for full information on the UML-to-SOA transform.
-
See
UML-to-SOA transforms for
essential information regarding:
-
-
Valid transformation sources and targets
-
Transformation output
-
See
UML-to-SCDL transforms for
essential information on the UML-to-SCDL transform. This is an internal transform, called by UML-to-SOA to
generate the WebSphere Integration Developer input artifacts.
-
See
Configuring
Transformations for instruction as to how to create and configure a new UML-to-SOA transformation.
-
See
Running and rerunning UML-to-SOA
transformations for guidance regarding how to run a UML-to-SOA transformation.
BPEL Generation
The UML-to-SCDL transform calls an internal UML-to-BPEL transform, see UML-to-BPEL transformations for
details. This generates BPEL for each service operation whose provider owns an Activity-based
description of the operation's implementation. So, the generated BPEL is based upon the IT
organization's considerations as to how each such operation needs to be realized. An
integration developer who begins his service choreography with this BPEL largely will be relieved of the
responsibility of conceiving the IT solution to the business problem.
Considerations for Modeling Elements in UML Activities
See the Help topics, Considerations for
modeling elements in UML Activities and Interpretation of UML elements by UML-to-BPEL transformations, to understand the
requirements for Activity models that are intended to be the source for BPEL generation. For a detailed example
of an Activity diagram that can be used to successfully generate BPEL, examine the sample service model that is
provided with Example: Sample SoaML Design Model and see the OrderProcessor's Activity for
the processPurchaseOrder operation.
Here are some modeling points that are easy to miss:
-
The Activity's Specification property -- reachable using the General tab of its Properties View -- must
be set to the operation it is describing.
-
The Activity needs to own Activity Parameter Nodes that are set to the parameters and return type of the operation
it is describing. With the Activity diagram being open, create these nodes using the diagram palette. Apply
the nodes to the outer border of the diagram.
-
The name of each input pin and output pin that is associated with a call operation action or an accept call
action, except the target input pin and the return information of the action, is the name of either an activity
parameter or a property.
If you examine the processPurchaseOrder Activity, you will note that its collective Call Operation Actions and
Accept Call Actions used five data elements as action parameters, three of which are satisfied by the
parameters of the Activity. The other two data elements -- a Schedule and a Manifest -- were added to the
Activity as Data Store Nodes, to satisfy the third point that is listed above.
|