Section 8.4. WSCI

8.4. WSCI

Version 1.0 of WSCI^[*] was written by BEA, Intalio , Sun, and SAP in 2002. Its syntax and semantics are strikingly similar to those of BPML, which is not surprising, given Intalio's participation in both specifications. In turn, BPML's close resemblance to BPEL seemingly implies that WSCI participates in a technology competitionXML process definition languagesthat has already been won by BPEL. The temptation to dismiss WSCI outright is irresistible.

^[*] W3C, "Web Services Choreography Interface (WSCI) 1.0," http://www.w3c.org/TR/wsci/, August 2002.

But there are subtle differences. WSCI is a web services technology, not a business process technology: it extends WSDL with a language that builds stateful, conversational processes out of stateless, atomic web services. BPM languages, by contrast, build business processes whose external interactions are web services. If web services did not exist, BPM languages could substitute a different integration technology, but WSCI would have no reason to exist.

8.4.1. Anatomy of a WSCI Application

The typical WSCI application describes a business process that spans multiple participants and has both a single global, objective view and individual subjective views for each participant. In Example 8-1, there are separate processes for Consumer, Retailer, and Warehouse, each of which controls the logic for that participant, and there is also the overall exchange of messages. If we were to model this behavior in UML, each process would be represented as an activity diagram, and the overall message exchange would be modeled as a sequence diagram, as in Figure 8-6.

Figure 8-6. Choreography in UML: global and subjective view

The idea of WSCI, though not derived from this usage of UML, is similar in spirit: WSCI is an XML language that can model both individual participant processes as well as the global exchange. The main parts of a WSCI application are depicted in Figure 8-7.

Figure 8-7. Components of a WSCI application

Here are the components:

WSDL: WSDL defines the static web service interfaces to be choreographed by WSCI.
WSCI interface: A WSCI interface specifies the process governing how the web services defined in the WSDL are used, normally from the point of view of one of the participants. The interface is intended to show only the publicly observable behavior of the participant process, and hence is not an orchestration but, is, when combined with the WSCI interfaces of the other participants, a choreography. The interface is coded using a variety of control flow patterns (sequential, parallel, conditional, iterative, and exceptional), and supports cross-service message correlation.
WSCI global model: The global model demonstrates the overall message exchange. It consists of a set of connections, each of which links the web service operation of one participant to the complementary (mirror-image) operation of another participant. For example, a retailer's operation to send a purchase order response links to a consumer's operation to receive a purchase order response.

8.4.2. WSCI Interface

WSCI is quite similar to BPML, and hence a detailed treatment of the WSCI interface object model or its syntax and semantics is not provided here (see the discussion of BPML in Chapter 6). The differences between WSCI and BPML are minor, the most salient of which is the treatment of the action activity, which functions as a web service integration point. In BPML, the input and output messages to a WSDL operation are explicitly mapped to process-level properties, whereas in WSCI, the input and output parameters are omitted altogether.

Instead, we focus on how a WSCI interface can be used to describe the choreography of a web service interface. In the purchasing example considered earlier, the web service interface offered by the retailer is described in Example 8-2.

Example 8-2. WSDL for retailer

 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 = "Retailer"> 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             <fault message = "defs:poNAK"/> 18          </operation> 19          <operation name = "SendPOResponse"> 20             <output message = "defs:poResponse"/> 21          </operation> 22          <operation name = "SendPOError"> 23             <output message = "defs:poError"/> 24          </operation> 25       </portType> 26    </definitions>

The retailer's use of the four operations listed in the WSDL, stated informally, is as follows:

ReceivePO triggers the retailer to begin processing the specified purchase order request, passed to it by the consumer.
The retailer passes the request to the warehouse by calling SendPOToWarehouse.
If SendPOToWarehouse returns successfully, the retailer invokes the operation SendPOResponse to notify the consumer that the purchase order request was successful. Otherwise, the retailer calls SendPOError to notify the consumer that the request failed.

Example 8-3 shows the WSCI code.

Example 8-3. WSCI interface for retailer

 1    <?xml version = "1.0" ?> 2    <wsdl:definitions name = "Retailer" 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       <wsdl:import  namespace = "http://mike.com/retailer " 10                   location = "http://mike.com/retailer.wsdl" /> 11       <interface name = "Retailer"> 12          <process name = "ProcessPO" instantiation = "message"> 13             <sequence> 14                <!-- po from consumer --> 15                <action name = "ReceivePO" role = "tns:Retailer" 16                   operation = "tns:Retailer/ReceivePO"/> 17                <context> 18                   <!-- send po to warehouse --> 19                   <action name = "SendPOToWarehouse" role = "tns:Retailer" 20                      operation = "tns:Retailer/SendPOToWarehouse"/> 21                   <exception> 22                      <!-- if warehouse returns NAK, send po error to consumer --> 23                      <onFault> 24                         <action name="SendPOError" role="tns:Retailer" 25                            operation="tns:Retailer/SendPOError"/> 26                         <!-- propagate error up --> 27                         <fault code="tns:poNAK"/> 28                      </onFault> 29                   </exception> 30                </context> 31                <!-- got out of warehouse step OK, send po response to consumer --> 32                <action name = "SendPOResponse" role = "tns:Retailer" 33                   operation = "tns:Retailer/SendPOResponse"/> 34            </sequence> 35         </process> 36       </interface> 37    </wsdl:definitions>

The four action elements (lines 41-42, 45-46, 50-51, and 58-59) map to the four WSDL operations, and are called in a sequence (lines 39-60). ReceivePO occurs first, followed by SendPOToWarehouse. Because SendPOToWarehouse can fault (on a negative acknowledgement), it is wrapped in a context element with an exception handler (exception) that calls SendPOError when the fault occurs. If the warehouse interaction is successful, the process calls SendPOResponse.

NOTE

Notice that the interface is enclosed in a wsdl:definitions element. Because of this, the example WSCI code could have been embedded in the WSDL document.

Notice also that in the action elements, WSCI, unlike BPML, does not explicitly show the web service input and output messages. Because of this, WSCI actions are hard to read and require constant back-and-forth cross-referencing with the WSDL.

A full implementation of the purchasing example also requires interfaces for consumer and warehouse. The WSDL and WSCI representations of these participants are omitted for brevity.

8.4.3. WSCI Global Model

A WSCI interfacea control flow shaped by constructs such as loops, sequences, decisions, and parallels pathsis essentially procedural in nature, whereas a WSCI global model , built as the declaration of a set of connections between interfaces, is declarative. Figure 8-8 illustrates the main pieces of a global model.

A global model references a set of WSCI interfaces and one or more connections. Interestingly, the connections are defined by WSDL port type and operation rather than WSCI interface action, which raises the question of why the WSCI interface references are required in the first place. The destination operation is a mirror image of the source, with matching message types but opposite direction, as outlined in Table 8-1.

Figure 8-8. WSCI global model

Table 8-1. Global model connections: destination is the mirror image of the source
Source	Destination
Out	In
Out-In	In-Out
In	Out
In-Out	Out-In

8.4.3.1 Writing a WSCI global model

Writing a global model assumes that a WSCI interface has been created for each participant and that a WSDL exists that captures each interface action. Example 8-4 demonstrates the structure of a global model for the communication of consumer, retailer, and warehouse.

Example 8-4. WSCI global model sample

 1    <?xml version = "1.0" ?> 2    <wsdl:definitions name = "GlobalModel" 3       targetNamespace = "http://mike.com/purchasing" 4       xmlns = "http://www.w3.org/2002/07/wsci10" 5       xmlns:wsdl = "http://schemas.xmlsoap.org/wsdl/" 6       xmlns:c = "http://mike.com/purchasing/consumer" 7       xmlns:r = "http://mike.com/purchasing/retailer" 8       xmlns:w = "http://mike.com/purchasing/warehouse"> 9 10       <wsdl:import  namespace = "http://mike.com/purchasing/consumer " 11          location = "http://mike.com/purchasing/consumer.wsdl" /> 12       <wsdl:import  namespace = "http://mike.com/purchasing/retailer" 13          location = "http://mike.com/purchasing/retailer.wsdl" /> 14       <wsdl:import  namespace = "http://mike.com/purchasing/warehouse" 15          location = "http://mike.com/purchasing/warehouse.wsdl" /> 16 17       <model name = "PurchasingGV"> 18 19          <interface ref = "c:Consumer" /> 20          <interface ref = "r:Retailer" /> 21          <interface ref = "w:Warehouse" /> 22 23          <connect operations="c:Consumer/SendPO r:Retailer/ReceivePO" /> 24          <connect operations="r:Retailer/SendPOToWarehouse w:Warehouse/ReceivePO" /> 25          <connect operations="r:Retailer/SendPOResponse 26                               c:Consumer/ReceivePOResponse"/> 27          <connect operations="r:Retailer/SendPOError c:Consumer/ReceivePOError" /> 28          <connect operations="w:Warehouse/SendShipment c:Consumer/ReceiveShipment" /> 29       </model> 30    </wsdl:definitions>

Figure 8-9 captures the global view visually. A connection is an arrow linking two operations residing in separate port types. For example, as the code states in line 23, SendPO in Consumer links to ReceivePO in Retailer. The global view does not specify the direction of the connection (which would be valuable), but that information can be found in the corresponding WSDLs. In this case, as the figure shows, SendPO is out-in and its complement ReceivePO in-out, implying that the consumer calls SendPO by passing its request and waiting for a response; the retailer's ReceivePO is triggered as an event, and the retailer sends back a response.

Figure 8-9. WSCI global view for purchasing

8.4.4. Weaknesses in WSCI

WSCI is unwieldy. Expressing complex multiparticipant choreographies in WSCI requires too many artifactstypically one interface per participant (though WSCI's interface does support multiple roles), plus a global view. WSCI would be stronger if its global view could be enhanced to capture the behavioral elements of the interfaces; in that case only one artifact would be required to capture everything! WS-CDL, in fact, has succeeded in reconciling these two approaches.

8.4.5. The Future of WSCI

Despite its leadership role in the writing of the WSCI specification, BEA Systems has all but abandoned WSCI and shifted its support to BPEL, which it cowrote with IBM and Microsoft. Oracle and WSCI coauthor Sun Microsystems have supported WSCI for some time, but Oracle has been building BPEL tools recently and is the main force behind the latest choreography specification, WS-CDL.

All signs point to the demise of WSCI. Positioned as a business process language, WSCI is overwhelmed by BPEL. In the choreography layer of the emerging web services stack, WSCI is surpassed by WS-CDL.

On the other hand, to actually omit WSCI from a current discussion of choreography is premature. WSCI is still a recognizable name in the BPM community, and to not see it discussed would confuse many readers. To understand choreography, it helps to observe the contrast of WSCI to WS-CDL and to know that WSCI's effect is waning.