Transformation to SOA: Part 4. How Web service processes transform from UML to BPEL in IBM Rational Software Architect

Document options PDF - Fits A4 and Letter 135KB (22 pages) Get Adobe® Reader® Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Murali Pattathe (pattathe@ca.ibm.com), Advisory Software Developer, IBM Canada

18 Mar 2008

The article explains how to model BPEL process implementation details in UML. The Unified Modeling Language (UML) provides convenient, well-understood, well-documented, and commonly practiced support for use case, collaboration, data, interface, class, component, interaction, state, and activity modeling. You can exploit this to capture application models that can be transformed to various platform architectures. The transformation from UML to Process Execution Language (UML-to-BPEL) that this article describes translates UML artifacts into BPEL artifacts.

The Business Process Execution Language for Web Services (BPEL4WS or BPEL) is an XML-based standard for specifying business process behavior that is based on Web services. It builds upon the Web Services Definition Language (WSDL) and XML Schema Definition (XSD). The UML (Unified Modeling Language) to BPEL transformation can take models of processes developed in a UML tool, such as IBM Rational Software Architect or Rational Software Modeler, and convert them to the correct BPEL, XSD, and WSDL files that are necessary to implement that process.

Currently, the UML-to-BPEL transformation that can be performed in IBM® Rational® Software Architect (7.0.0.5) is not a standalone transformation; therefore, you do not run the transformation alone. Rather, it is invoked by the UML-to-SOA (service-oriented architecture) transformation when it is necessary. Rational Software Architect provides many useful tools that help a software architect design the system. UML transformations, such as UML to XSD and UML to WSDL, are available only in Rational Software Architect, and UML-to-BPEL transformation uses it for generating XSD and WSDL artifacts.

Overview of BPEL

BPEL provides an XML notation and related semantics for specifying business process behavior that is based on Web services. A BPEL4WS process is defined in terms of its interactions with partners. A partner may provide services to the process, require services from the process, or participate in a two-way interaction with the process. Thus, BPEL orchestrates the integration of Web services by specifying the order in which it is meaningful to call a collection of services, and it assigns responsibilities for each of the services to partners. You can use it to specify both the public interfaces for the partners and the description of the executable process.

The reason to use UML

UML is an Object Management Group (OMG) standard that provides a visual modeling notation that is valuable for designing and understanding complex systems. UML has several general advantages:

• It is the most widely known object-oriented modeling notation.
• It uses a graphical notation that is readily understood.
• It offers a rich set of semantics for capturing key features of object-oriented systems.

UML is widely used in the development of object-oriented software. It has also been used, with customizations, for component-based software, business process modeling, services modeling, and systems design. This enables you to apply the considerable body of UML experience to maturing Web service technologies.

Mapping to BPEL for Web services

A UML-to-BPEL transformation uses the following approach to generate a BPEL file:

1. The BPEL process is generated based on a UML component.
2. A BPEL scope is generated in the BPEL process for each of the UML Activities of the UML Component.
3. BPEL partner links are generated based on the details of ports owned by the UML Component.

UML-to-BPEL transformation requirements should take into consideration the process of modeling a UML Activity.

The focus here is mainly on how the UML-to-BPEL transformation is currently supported in Rational Software Architect Version 7.0.0.4 and some of the key requirements of UML modeling that are necessary for generating BPEL artifacts. This article uses a sample model, Purchase Order Process, to explain some of the UML-to-BPEL transformation requirements when you model an Activity diagram.

Currently, the process of UML-to-BPEL transformation does not require extending or customizing the UML, but it is necessary to have some of the details in place when you model an Activity diagram.

Purchase Order Process model in detail

Let's look closer at the sample process. The UML OrderProcessor Component contains four ports:

• The Purchasing port, which contains a provided Interface called Purchasing.
• The Invoicing port that contains one provided Interface called InvoiceProcessing and one required Interface called Invoicing.
• The Scheduling port, which contains a required Interface called Scheduling.
• The Shipping port that contains one provided Interface called ScheduleProcessing and one required Interface called Shipping.

The UML processPurchaseOrder Activity is an owned behavior of the OrderProcessor Component, which is the activity that provides all necessary implementation details for the Component.

Figure 1 shows a UML Activity that is an owned behavior of the OrderProcessor (a UML Component). The OrderProcessor component is shown in Figure 2.

This is the property value setting of the specification:

Purchasing::processPurchaseOrder(customerInfo:Customer, 
purchaseOrder:PurchaseOrder):Invoice

The Activity must have Activity parameters that correspond to parameters in the Activity specification operation.The Activity shown previously in Figure 1 contains three Activity Parameter nodes that represent customerInfo:

• Customer
• purchaseOrder: PurchaseOrder
• invoice: Invoice

Note:
It is mandatory that Activity parameters match the signature of the operation's parameters.

The UML-to-BPEL transformation generates a BPEL Receive activity with two output parameters, which code Listing 1 illustrates.

                
<bpws:receive createInstance="yes" name="processPurchaseOrder" 
operation="processPurchaseOrder" partnerLink="purchasingPurchasing" 
portType="ns2:Purchasing">
      <wpc:output>
        <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/>
        <wpc:parameter name="purchaseOrder" variable=
"processpurchaseorder_purchaseOrder"/>
      </wpc:output>
</bpws:receive>

There are three activity partitions (Invoicing, Shipping, and Scheduling) in the Receive activity that represent each port in the Component. They represent the properties of each partition as they are set to their corresponding ports in the Component. A control flow begins with an initialNode in the Receive activity, and it is connected to a forkNode. Three controlFlows are starting from the forkNode, and each one is connected to separate Action. This indicates that multiple sequences of actions are going to run when the control reaches to the forkNode. The UML-to-BPEL transformation generates a BPEL Flow activity and three BPEL sequences in the flow.

A control flow starts from the initialNode, and it is connected to a forkNode. Three controlFlows are starting from the forkNode, and each one is connected to an Action. This indicates that multiple sequences of actions can execute simultaneously when the control reaches to the forkNode. The UML-to-BPEL transformation generates a BPEL Flow activity and three BPEL sequences in the flow.

Let's examine the first outgoing control flow from the forkNode. The flow is connected to an Action called initiatePriceCalculation (a Call Operation action), and the UML operation for the action is set to this:

PurchaseOrderProcess::com::acme::credit:
:Invoicing::initiatePriceCalculationOperation(customerInfo
        : Customer, purchaseOrder : PurchaseOrder)

Hence, the Action contains three inputPins. The right-most inputPin is a targetInputPin (the name of the pin is empty, because the action is part of an activity partition). The first and second inputPins indicate that there are two input parameters for the operation associated with the Action. The name of the pin must represent a data object. That object could be the name of the UML Variable, UML Property, or UML Parameter that must exist in the UML Activity or UML Component. In this model, customerInfo and purchaseOrder are parameters in the Activity. The UML-to-BPEL transformation generates a BPEL Invoke activity with two input parameters, as Listing 2 shows.

                
<bpws:invoke name="initiatePriceCalculation" operation="initiatePriceCalculation" 
partnerLink="invoicingInvoicingPartner" portType="ns3:Invoicing">
            <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
            </wpc:input>
</bpws:invoke>
      

The outgoing control flow from the initiatePriceCalculation action is connected to the completePriceCalculation action (a Call Operation action) with this setting for the UML operation for the Action:

PurchaseOrderProcess::com::acme::credit::Invoicing::completePriceCalculation
        (shippingInfo : Manifest)
      

The Action contains two inputPins (the right-most inputPin is a targetInputPin, but its name is empty because the action is part of an Activity partition). The single inputPin indicates that there is one input parameter for the operation associated with the action. The name of the pin must represent a data object, which could be the name of the UML Variable, UML Property, or UML Parameter that must exist in the UML Activity or UML Component. In this model, shippingInfo is a UML property in the Component. You have probably noticed that there is another incoming control from the requestShipping action, which indicates that the completePriceCalculation action must be invoked before completing the action called requestShipping.

The UML-to-BPEL transformation generates a BPEL Invoke activity with an input parameter, a target BPEL link for the requestShipping action, and a link that will be set as a source BPEL link in the Invoke activity for the requestShipping action, which you can see in Listing 3.

                
<bpws:invoke name="completePriceCalculation" 
operation="completePriceCalculation" partnerLink="invoicingInvoicingPartner" 
portType="ns3:Invoicing">
            <wpc:input>
              <wpc:parameter name="shippingInfo" variable="shippingInfo"/>
            </wpc:input>
            <bpws:targets>
              <bpws:target linkName="processPurchaseOrderLink1"/>
            </bpws:targets>
</bpws:invoke>

The outgoing control flow from the completePriceCalculation action is connected to the processInvoice action (an Accept Call action). The triggers that come from this action contain one CallEvent, with this setting for its associated operation:

PurchaseOrderProcess::org::ordermanagement::InvoiceProcessing::processInvoice
        (invoice : Invoice)
      

The Action contains two outputPins (the right-most outputPin represents returnInforation property of the action). The single outputPin indicates that there is one input parameter for the operation associated with the action. The name of the pin must represent a data object, which could be the name of the UML Variable, UML Property, or UML Parameter that must exist in the UML Activity or UML Component. In this example, Invoice is a parameter in the Activity. The UML-to-BPEL transformation generates a BPEL Receive activity with an output parameter.

Two other sequences of control flows from the forkNode are processed similarly. At the end, a BPEL Reply activity is generated, because the Activity::specification operation contains a return parameter. (In this example, the Activity specification operation is PurchaseOrderProcess::org::ordermanagement::Purchasing::processPurchaseOrder.) This is shown in Listing 4.

                
<bpws:reply name="processPurchaseOrder" operation=
"processPurchaseOrder" partnerLink="purchasingPurchasing" portType=
"ns2:Purchasing">
      <wpc:input>
        <wpc:parameter name="result" 
variable="processpurchaseorder_result"/>
      </wpc:input>
</bpws:reply>

Listing 5 shows the full BPEL file that is generated by the UML-to-BPEL transformation for the orderProcessor component.

                
<?xml version="1.0" encoding="UTF-8"?>
<bpws:process xmlns:bpws="
http://schemas.xmlsoap.org/ws/2004/03/business-process/" 
xmlns:ns="http://org/ordermanagement/OrderProcessorArtifacts/" 
xmlns:ns0="http://org/crm/" 
xmlns:ns1="http://org/crm/domain/" 
xmlns:ns2="http://org/ordermanagement/Purchasing/" 
xmlns:ns3="http://com/acme/credit/Invoicing/" 
xmlns:ns4="http://org/ordermanagement/InvoiceProcessing/" 
xmlns:ns5="http://com/acme/shipping/Shipping/" 
xmlns:ns6="http://org/ordermanagement/ScheduleProcessing/" 
xmlns:ns7="http://com/acme/productions/Scheduling/" 
xmlns:wpc="http://www.ibm.com/xmlns/prod/websphere/business-process/6.0.0/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" expressionLanguage="
http://www.ibm.com/xmlns/prod/websphere/business-process/expression-lang/java/6.0.0/" 
name="OrderProcessor" suppressJoinFailure="yes" targetNamespace="
http://org/ordermanagement/OrderProcessor/">  <bpws:import importType="
http://schemas.xmlsoap.org/wsdl/" 
location="OrderProcessorArtifacts.wsdl" namespace="
http://org/ordermanagement/OrderProcessorArtifacts/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/PurchaseOrder.xsd" 
namespace="http://org/crm/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/Invoice.xsd" 
namespace="http://org/crm/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/Manifest.xsd" 
namespace="http://org/crm/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" location="
../../../PurchaseOrderProcess/org/crm/domain/Customer.xsd" 
namespace="http://org/crm/domain/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/Schedule.xsd" 
namespace="http://org/crm/"/>  <bpws:partnerLinks>
    <bpws:partnerLink myRole="PurchasingRole" 
name="purchasingPurchasing" 
partnerLinkType="ns:PurchasingPLT"/>
    <bpws:partnerLink name="
invoicingInvoicingPartner" 
partnerLinkType="ns:InvoicingPLT" 
partnerRole="InvoicingRole"/>
    <bpws:partnerLink myRole="InvoiceProcessingRole" 
name="invoicingInvoiceProcessing" 
partnerLinkType="ns:InvoiceProcessingPLT"/>
    <bpws:partnerLink name="schedulingSchedulingPartner" 
partnerLinkType="ns:SchedulingPLT" 
partnerRole="SchedulingRole"/>
    <bpws:partnerLink name="shippingShippingPartner" 
partnerLinkType="ns:ShippingPLT" 
partnerRole="ShippingRole"/>
    <bpws:partnerLink myRole="ScheduleProcessingRole" 
name="shippingScheduleProcessing" 
partnerLinkType="ns:ScheduleProcessingPLT"/>
  </bpws:partnerLinks>  <bpws:variables>
    <bpws:variable name="id" 
type="xsd:string"/>
    <bpws:variable name="shippingInfo" 
type="ns0:Manifest"/>
    <bpws:variable name="schedule" 
type="ns0:Schedule"/>
    <bpws:variable name="
processpurchaseorder_customerInfo" 
type="ns1:Customer"/>
    <bpws:variable name="
processpurchaseorder_purchaseOrder" 
type="ns0:PurchaseOrder"/>
    <bpws:variable name="
processpurchaseorder_result" 
type="ns0:Invoice"/>  </bpws:variables>
  <bpws:sequence name="Sequence">
    <bpws:receive createInstance="yes" 
name="processPurchaseOrder" 
operation="processPurchaseOrder" 
partnerLink="purchasingPurchasing" 
portType="ns2:Purchasing"> <wpc:output>
        <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
        <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
      </wpc:output> </bpws:receive>
    <bpws:scope name="
processPurchaseOrder">
      <bpws:flow name="
processPurchaseOrderFlow"> <bpws:links>
          <bpws:link name="
processPurchaseOrderLink1"/> <bpws:link name="
processPurchaseOrderLink2"/> </bpws:links>
        <bpws:sequence name="Sequence3">
          <bpws:invoke name="
initiatePriceCalculation" operation="
initiatePriceCalculation" partnerLink="
invoicingInvoicingPartner" 
portType="ns3:Invoicing"> <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
            </wpc:input> </bpws:invoke>
          <bpws:invoke name="completePriceCalculation" 
operation="completePriceCalculation" 
partnerLink="invoicingInvoicingPartner" 
portType="ns3:Invoicing"> <wpc:input>
              <wpc:parameter name="shippingInfo" 
variable="shippingInfo"/>
            </wpc:input> <bpws:targets>
              <bpws:target linkName="
processPurchaseOrderLink1"/>
            </bpws:targets> </bpws:invoke>
          <bpws:receive name="processInvoice" 
operation="processInvoice" 
partnerLink="invoicingInvoiceProcessing" 
portType="ns4:InvoiceProcessing"> 
<wpc:output> 
         <wpc:parameter name="invoice" 
variable="processpurchaseorder_result"/>
            </wpc:output> </bpws:receive>
        </bpws:sequence> <bpws:sequence name="Sequence4">
          <bpws:assign name="Assign1">
            <bpws:copy> <bpws:from 
variable="processpurchaseorder_purchaseOrder">
                <bpws:query queryLanguage="
http://www.w3.org/TR/1999/REC-xpath-19991116"><!
[CDATA[/oid]]></bpws:query>
              </bpws:from> <bpws:to variable="
processpurchaseorder_customerInfo">
                <bpws:query queryLanguage="
http://www.w3.org/TR/1999/REC-xpath-19991116"><!
[CDATA[/firstname]]></bpws:query>
              </bpws:to></bpws:copy>
          </bpws:assign><bpws:invoke name="requestShipping" 
operation="requestShipping" 
partnerLink="shippingShippingPartner" 
portType="ns5:Shipping">
            <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="shippingInfo" 
variable="shippingInfo"/>
            </wpc:input><bpws:sources>
              <bpws:source linkName="processPurchaseOrderLink1"/>
            </bpws:sources> </bpws:invoke>
          <bpws:receive name="processSchedule" 
operation="processSchedule" 
partnerLink="shippingScheduleProcessing" 
portType="ns6:ScheduleProcessing">
            <wpc:output>
              <wpc:parameter name="schedule" 
variable="schedule"/>
            </wpc:output> <bpws:sources>
              <bpws:source linkName="
processPurchaseOrderLink2"/>
            </bpws:sources> </bpws:receive>
        </bpws:sequence> <bpws:sequence name="Sequence5">
          <bpws:invoke name="
requestProductionScheduling" operation="
requestProductionScheduling" partnerLink="
schedulingSchedulingPartner" 
portType="ns7:Scheduling"> <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
            </wpc:input> </bpws:invoke>
          <bpws:invoke name="sendShippingSchedule" 
operation="sendShippingSchedule" 
partnerLink="schedulingSchedulingPartner" 
portType="ns7:Scheduling"> <wpc:input>
              <wpc:parameter name="schedule" 
variable="schedule"/>
            </wpc:input> <bpws:targets>
              <bpws:target linkName="
processPurchaseOrderLink2"/>
            </bpws:targets>
          </bpws:invoke>
        </bpws:sequence>
      </bpws:flow>
    </bpws:scope>
    <bpws:reply name="processPurchaseOrder" 
operation="processPurchaseOrder" 
partnerLink="purchasingPurchasing" 
portType="ns2:Purchasing">
      <wpc:input>
        <wpc:parameter name="result" 
variable="processpurchaseorder_result"/>
      </wpc:input>
    </bpws:reply>
  </bpws:sequence>
</bpws:process>

Back to top

Interpretation of UML elements by UML-to-BPEL transformation

The UML-to-BPEL transformation uses specific information from a UML model to generate BPEL artifacts. An incorrect or incomplete model can generate errors or incorrect BPEL artifacts, or both. You will want to avoid this, of course. The following tables should help you understand the expected outcomes that will derive from various transformation activities.

Transformation of UML elements

Table 1 lists the UML elements that the transformation supports and the corresponding BPEL construct or activity that the transformation creates.

Transformation of UML Activity edges

Table 2 lists the Activity edge types that the transformation supports and the corresponding BPEL sequence and links that the transformation creates.

Transformation of control or decision nodes

Table 3 lists the control and decision nodes that the transformation supports and the corresponding BPEL output that the transformation creates.

Transformation of object nodes

Table 4 lists the object nodes that the transformation supports and the corresponding BPEL activity that the transformation generates.

Transformation of loop nodes

Table 5 lists loop node elements that the transformation supports, and the corresponding BPEL activity that the transformation generates.

Where to learn more

Now that you understand the basics of UML-to-BPEL transformation and some of the details of how to model a BPEL Process implementation in UML, you might want to read some of the related articles listed in Resources to find use case scenarios.

Resources

• Part 1 of this series, Transformation to SOA: Part 1. From business process to service model architecture using IBM WebSphere Business Modeler and IBM Rational Software Architect.
  
  
• Part 2 of 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.
  
  
• Part 3 of this series, Transformation to SOA: Part 3. UML to SOA.
  
  

• For additional useful information, read this series of five articles by Jim Amsden about developing software based on service-oriented architecture (SOA):

  • Modeling SOA: Part 1. Service identification shows how to use UML models extended with the IBM Software Service Profile to design an SOA solution that is connected to business requirements, yet independent of the solution implementation. The author describes the business goals and objectives and the business processes implemented to meet those objectives, and then explains how to use the processes to identify business-relevant services necessary to fulfill the requirements that they represent.
  • Modeling SOA: Part 2. Service specification. The author continues defining the SOA solution by modeling the specification of each service in detail. These specifications will define contracts between consumers and producers of the service. These contracts include the provided and required interfaces, the roles those interfaces play in the service specification, and the rules or protocol for how those roles interact.
  • Modeling SOA: Part 3. Service realization. This third article explains how SOA-based Web services are actually implemented. The service realization starts with deciding what component will provide what services. That decision has important implications in service availability, distribution, security, transaction scopes, and coupling. After these decisions have been made, you can model how each service functional capability is implemented and how the required services are actually used. Then you can use the UML to SOA transformation feature included in IBM Rational Software Architect to create a Web services implementation that can be used in IBM WebSphere Integration Developer to implement, test, and deploy the completed solution.
  • Modeling SOA: Part 4. Service composition. This fourth article covers how to assemble and connect the service providers modeled in "Part 3. Service realization" and choreograph their interactions to provide a complete solution to the business requirements. The resulting component will be a service participant that composes the services provided by the Invoicer, Productions, and Shipper components to provide a service capable of processing a purchase order. It also shows how this service participant fulfills the original business requirements.
  • Modeling SOA: Part 5. Service implementation. In this final article in the series, the author describes how to create an actual implementation that is consistent with the architectural and design decisions captured in the services model. We'll generate the platform-specific implementation by exploiting both model-driven development and the IBM Rational Software Architect UML-to-SOA transformation feature to create a Web service from the SOA model.
  
  
• Read BPEL 1.1 Specification (IBM® developerWorks®, Feb 2007)
  
  
• Read From UML to BPEL (IBM® developerWorks®, Sep 2005)
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
  
  
• Browse the SOA and Web services area on developerWorks to get the resources you need to advance your skills in service- oriented architecture.
  
  
• Visit the IBM Service-Oriented Architecture (SOA) Solutions area on IBM.com.
  
  
• Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
  
  
• Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

• Download trial version of IBM Rational Software Architect, Version 7.
  
  
• Download trial versions of IBM Rational software.
  
  
• Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

		Murali Pattathe is an IBM Rational advisory software developer in the IBM Ottawa Lab, Ontario, Canada. He has more than 15 years of experience in designing and developing applications and tools for the software development industry. He was involved in developing many other transformations, as well as transformation frameworks.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top