Section 9.4. IBM WSFL: BPEL Forerunner


9.4. IBM WSFL: BPEL Forerunner

IBM published Web Services Flow Language[*] in 2001 with the familiar purpose of standardizing the design of web-service-oriented business processes spanning multiple participants. WSFL has so much in common with BPML, WSCI, XLANG, BPEL, and other XML-based process languages that given also its complete lack of industry support, it is tempting to discount it entirely. Indeed, even IBM has given up on it, but only because IBM decided to join forces with Microsoft and BEA on BPEL. As it turns out, IBM's involvement in the design of BPEL resulted in core WSFL ideas (e.g., flow, dead path elimination) infiltrating BPEL. WSFL's influence on BPEL makes it worthy of investigation.

[*] F. Leymann, "Web Services Flow Language (WSFL 1.0)", IBM, http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf, 2001.

WSFL supports the definition of two types of process models:


Flow model

The orchestration of web service operations for a single participant.


Global model

The exchange, or choreography, of messages by web service invocation across a set of participants.

The ubiquitous purchasing example (used in countless BPM discussions) demonstrates a WSFL implementation of both models. Figure 9-9 shows the exchange of messages between three participants: Consumer, Retailer, and Warehouse. Each participant has its own flow model, shown as the arrangement of circles (representing activities) and solid arrows (control links) running from top to bottom starting immediately below the participant name. The dotted arrows, which connect activities across different flows, are called plug links ; the global model captures the complete set of these external interactions.

Figure 9-9. WSFL purchasing example


The consumer flow model begins by sending a purchase order to the retailer, then waiting for a response from the retailer and a shipping notice from the warehouse. The retailer flow model starts by receiving the purchase order from the consumer; the retailer then sends the purchase order to the warehouse, and, subsequently, sends a response to the consumer. The warehouse flow model, triggered by receipt of the purchase order from the retailer, sends a shipping notice back to the consumer once the warehouse has filled the order.

As with every other XML-based process language, WSFL source code is a combination of standard WDSL and process definition XML. In the case of WSFL, the process XML normally resides a separate file that references the WSDL port types and message definitions. Most of the activities in the process definition map to port type operations. Activities that are triggered by the receipt of a message terminate a plug link (e.g., Get PO), whereas those that send a message originate a plug link (e.g., Send Notice). The remaining activities (e.g., Fill Order) have no web services interaction but perform internal logic, such as calling Java code, an operating system program, or a CICS transaction.

The code sample Example 9-4 lists the WSDL for the retailer. Its port type, RetailerPT, is listed in lines 9-21.

Example 9-4. Retailer WSDL
 1    <?xml version = "1.0" ?> 2    <definitions name = "Retailer Purchasing" 3       targetNamespace = "http://mike.com/retailer" 4          xmlns = "http://www.w3.org/2002/07/wsci10" 5          xmlns:wsdl = "http://schemas.xmlsoap.org/wsdl/" 6          xmlns:tns = " http://mike.com/retailer" 7          xmlns:defs = " http://mike.com/purchasing/definitions"> 8 9       <portType name = "RetailerPT"> 10          <operation name = "ReceivePO"> 11             <input message = "defs:poRequest"/> 12             <output message = "defs:poACK"/> 13          </operation> 14          <operation name = "SendPOToWarehouse"> 15             <output message = "defs:poRequest"/> 16             <input message = "defs:poACK"/> 17          </operation> 18          <operation name = "SendPOResponse"> 19             <output message = "defs:poResponse"/> 20          </operation> 21       </portType> 22    </definitions>

The retailer flow model is shown in Example 9-5.

Example 9-5. Retailer WSFL flow model
 1    <definitions name="retailer " 2       targetNamespace="http://mike.com/retailer " 3       xmlns:r="http://mike.com/retailer" 4       xmlns:w="http://mike.com/warehouse" 5       xmlns:c="http://mike.com/consumer" 6       xmlns:defs = " http://mike.com/purchasing/definitions"> 7       xmlns=""> 8 9     <!--  A service provider flow for each participant: retailer, wh, consumer --> 10       <serviceProviderType name="warehouseFlow"> 11          <portType name="w:WarehousePT"/> 12       </serviceProviderType> 13       <serviceProviderType name="retailerFlow"> 14          <portType name="r:RetailerPT"/> 15       </serviceProviderType> 16       <serviceProviderType name="consumerFlow"> 17          <portType name="c:ConsumerPT"/> 18       </serviceProviderType> 19 20       <!-- Flow model for retailer to handle PO --> 21       <flowModel name="processPO" serviceProviderType="retailerFlow"> 22          <flowSource name="retailerFlowSource"> 23             <output name="processInstanceData" message="defs:poRequest"/> 24          </flowSource> 25 26          <!-- warehouse and consumer will be the other service providers --> 27          <serviceProvider name="warehouse" type="warehouseFlow"/> 28          <serviceProvider name="consumer" type="consumerFlow"/> 29 30          <export lifecycleAction="spawn"> 31             <target portType="r:RetailerPT" operation="receivePO"> 32                   <map . . . . . /> <!-- data mapping skipped --> 33             </target> 34          </export> 35 36          <activity name="sendPOToWarehouse"> 37             <input name="poRequest" message="defs:poRequest"/> 38             <output name="poResponse" message="defs:poResponse"/> 39             <performedBy serviceProvider="warehouse"/> 40             <implement> 41                <export portType="r:RetailerPT" 42                   operation="sendPOToWarehouse"> 43                   <map . . . . . /> <!-- data mapping skipped --> 44                </export> 45             </implement> 46          </activity> 47 48          <activity name="sendResponse"> 49             <input name="poResponse" message="defs:poResponse"/> 50             <performedBy serviceProvider="consumer"/> 51             <implement> 52                <export portType="r:RetailerPT" operation="sendPOResponse"> 53                   <map . . . . . /> <!-- data mapping skipped --> 54                </export> 55             </implement> 56          </activity> 57 58          <dataLink name="initialDataLink" source="retailerFlowSource" 59             target="sendPOToWarehouse"/> 60          <!-- other data links not shown --> 61 62          <controlLink name="sendWH-sendResp" source="sendPOToWarehouse" 63             target="sendPOResponse"/> 64       </flowModel> 65    </definitions>

Lines 10-18 define service provider types for the three participants; the names and WSDL port types are stipulated for each. The retailer's flow model begins on line 21; the model, named processPO, is an orchestration of the retailerFlow service provider type. Lines 22-27 declare that the retailer flow will referencethat is, will interact withthe other two service providers.

Determining how this process starts requires some digging. First, the flowSource element, defined in lines 22-24, specifies the input source of the process; the flow source is named retailerFlowSource and accepts as its input a defs:poRequest WSDL message. Next, line 58 specifies a data link that connects the flow source to the activity sendPOToWarehouse. Finally, according to the export in lines 30-34, this process is spawned when the operation receivePO on port type r:RetailerPT is called. Bringing it all together, when that WSDL operation is called, this process commences and control is passed to the sendPOToWarehouse activity.

Each activity has a name, an input and an output, a stipulation of which of the declared service provider performs the activity, and a statement of the implementation of the activity: web-service based (export) or internal. Lines 36-56 list the activities. The list matches the list of nodes in the retailer flow depicted in Figure 9-9, with one exception: ReceivePO is missing from the XML sample because it represents the initialization step of the spawn; it is not strictly an activity.

The flow of control from one activity to another is dictated by control links. This flow has only one control link, listed in lines 62-63, which connects sendPOToWarehouse to sendPOResponsethe last step in the process. A WSFL flow, like XPDL described in Chapter 7, is modeled as a directed graph whose nodes are activities and arcs are control links are arcs. Each control link connects a source activity to a target activity.

The three web service-based activities in the retailer flow represent interactions with external participants. The specific web service is given by the port type and operation; for example, sendPOToWarehouse, in lines 36-46, references port type r:Retailer and operation sendPOToWarehouse. You may not see that the direction of interaction for a given action (i.e., whether it is a send or a receive) is immediately obvious. You may also need to look at the WSDL: the activity is a send if the corresponding WSDL operation begins with an output message and a receive if the operation begins with an input. Table 9-2 describes the details for the three web-service-based agent activities.

Table 9-2. Direction of interaction for retailer activities

Activity

Operation

Send/receive

Service provider

Receive PO (the initiating activity)

receivePO

Receive (and send back a result synchronously)

Consumer

Send PO to Warehouse

sendPOToWarehouse

Send (with a result returned synchronously)

Warehouse

Send response to Consumer

sendPOResponse

Send

Consumer


NOTE

The retailer flow is sequential, but WSFL's flow model also supports conditional transitions, splits and joins, loops, and dead path elimination. The semantics are similar to that of the BPEL flow activity. The influence on BPEL is noted in the next section.

The global model captures the overall choreography across service providers. A web service interaction between one provider and another is represented as a plug link. It maps the sender's port type and operation to those of the receiver. An excerpt from this example's global model is shown in Example 9-6; some code is removed for sake of brevity.

Example 9-6. Purchasing WSFL global model
 1    <definitions name="Purchasing" 2       targetNamespace="http://mike.com/purchasing " 3       xmlns:tio="http://mike.com/purchasing" 4       xmlns=""> 5 6       <globalModel . . .> 7          . . . 8          <!-- the four plug links from the diagram --> 9          <plugLink> 10             <source serviceProvider="consumer" portType="c:ConsumerPT" 11                operation="sendPO"/> 12             <target serviceProvider="retailer" portType="r:RetailerPT" 13                operation="receivePO"/> 14          </plugLink> 15          <plugLink> 16             <source serviceProvider="retailer" portType="r:RetailerPT" 17                operation="sendPOToWarehouse"/> 18             <target serviceProvider="warehouse" portType="w:WarehousePT" 19                operation="receivePO"/> 20          </plugLink> 21          <plugLink> 22             <source serviceProvider="retailer" portType="r:RetailerPT" 23                operation="sendPOResponse"/> 24             <target serviceProvider="consumer" portType="r:ConsumerPT" 25                operation="receivePOResponse"/> 26          </plugLink> 27          <plugLink> 28             <source serviceProvider="warehouse" portType="r:WarehousePT" 29                operation="sendShipNotification"/> 30             <target serviceProvider="consumer" portType="r:ConsumerPT" 31                operation="receiveShipNotification"/> 32          </plugLink> 33          . . . 34       </globalModel> 35    </definitions>

The four plug links are listed in lines 9-32. In the first (lines 9-14), the consumervia the sendPO operation of the ConsumerPT port typesends a purchase order to the retailer (receivePO operation in RetailerPT). In the second (lines 15-20), the retailer (sendPO in RetailerPT) sends the purchase order to the warehouse (receivePO in WarehousePT). The third and fourth cases follow the same pattern: the source web service operation sends to that of the target. As with the flow model, the global model uses a directed graph representation; the nodes of the graph are web service operations, the arcs invocations between them.



    Essential Business Process Modeling
    Essential Business Process Modeling
    ISBN: 0596008430
    EAN: 2147483647
    Year: 2003
    Pages: 122
    Authors: Michael Havey

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net