Tool Mentor: Configure and Run the UML-to-SOA Transform
Create XSDs, WSDLs, BPEL, and SCDL components using the UML-to-SOA transform.
Tool: Rational Software Architect
Relationships
Main Description

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.