Section 8.5. WSCL

8.5. WSCL

WSCL, the least well-known of the choreography approaches, is easy to miss in the hunt for BPM standards. Its 24-page specification, submitted by Hewlett Packard to the W3C in the spring of 2002^[*] (ancient history, in BPM timelines), has never caught on with vendors and has not permeated the W3C's current choreography efforts. It's too bad, because WSCL's simple, elegant approach to choreography, using the idea of the state machine, has considerable merit.

^[*] W3C, "Web Services Conversation Language (WSCL) 1.0," http://www.w3c.org/TR/2002/NOTE-wscl10-20020314/, March 2002.

WSCL is an XML language whose main construct is a conversation, which represents a participant's web-service-based dialog with the other participants in the attainment of a business goal. The steps of the conversation are called interactions, in which the participant either calls or is called by other participants. WSCL supports four types of interactions, which are summarized in Table 8-2.

Table 8-2. WSCL interactions
WSCL type	WSDL type	Content	Description
Receive	One-way	Input message	Participant reacts to an inbound request message.
Send	Notification	Output message	Participant sends a message outbound.
Receive-send	Request-response	Input message, output message, multiple output fault messages	Participant reacts to an inbound request message and sends back a response message.
Send-receive	Solicit-response	Output message, input message, multiple input fault messages	Participant sends a message outbound and waits for the response to come back.

The link from one interaction (the source) to another (the destination) is called a TRansition. In the case where a source interaction has more than one outcome (e.g., success or one of several types of faults), the transition must specify which outcomethe source interaction condition to follow to traverse to the destination.

Two special interactions, called Start and End, determine the beginning and end, respectively, of the conversation.

Figure 8-10 shows the UML activity diagram representation of a WSCL conversation , from the retailer's view, of the purchasing scenario considered earlier. In the diagram, interactions are drawn as activities (rounded boxes)except the start and end interactions, drawn as solid ball and solid ball with outer circle, respectivelyand transitions as arrows. Each interaction has a name and a stereotype. The POToWarehouse interaction has two possible outcomes (POWarehouseACK and POWarehouseNAK), which transition to two separate destinations (POResponseToConsumer and POErrorToConsumer, respectively), shown in the diagram as an XOR split using the diamond symbol.

Figure 8-10. WSCL purchasing example

In the XML code in Example 8-5, the interactions are defined in lines 5-29, the transitions in lines 33-58. The first major step occurs when the retailer receives a purchase order request from the consumer in the interaction with ID POFromConsumer in lines 6-11. The retailer immediately sends back an acknowledgement (the outbound message in line 9), and the transition in lines 37-40 moves the conversation to the interaction POToWarehouse, defined in lines 12-19. In that interaction, the retailer sends the purchase order request to the warehouse (the outbound XML in line 13), and gets back either an acknowledgement (line 15) or a negative acknowledgement (line 17). The transition for the acknowledgement in lines 41-45 links to the interaction POResponseToConsumer, which, according to the definition in lines 20-23, sends a response message to the consumer. The transition for the negative acknowledgement (lines 46-50) moves control to the interaction POErrorToConsumer (lines 24-27), which sends an error to the consumer.

Example 8-5. WSCL sample

 1    <?xml version="1.0" encoding="UTF-8"?> 2    <Conversation name="POConversation" 3            xmlns="http://www.w3.org/2002/02/wscl10" 4            initialInteraction="Start"  finalInteraction="End"  > 5      <ConversationInteractions> 6        <Interaction interactionType="ReceiveSend" > 7            <InboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderReq.xsd" 8                    /> 9            <OutboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderAck.xsd" 10                    /> 11        </Interaction> 12        <Interaction interactionType="SendReceive" > 13            <OutboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderReq.xsd " 14                    /> 15            <InboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderAck.xsd" 16                    /> 17            <InboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderNak.xsd" 18                     /> 19        </Interaction> 20        <Interaction interactionType="Send"  > 21            <OutboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderRsp.xsd" 22                    /> 23        </Interaction> 24        <Interaction interactionType="Send"  > 25            <OutboundXMLDocument hrefSchema="http://mike.com/PurchaseOrderError.xsd" 26                    /> 27        </Interaction> 28        <Interaction interactionType="Empty"  /> 29        <Interaction interactionType="Empty"  /> 30      </ConversationInteractions> 31 32      <ConversationTransitions> 33        <Transition> 34          <SourceInteraction href="Start"/> 35          <DestinationInteraction href="POFromConsumer"/> 36        </Transition> 37        <Transition> 38          <SourceInteraction href="POFromConsumer"/> 39          <DestinationInteraction href="POToWarehouse"/> 40        </Transition> 41        <Transition> 42          <SourceInteraction href="POToWarehouse"/> 43          <DestinationInteraction href="POResponseToConsumer"/> 44          <SourceInteractionCondition href="POWarehouseACK "/> 45        </Transition> 46        <Transition> 47          <SourceInteraction href="POToWarehouse"/> 48          <DestinationInteraction href="POErrorToConsumer"/> 49          <SourceInteractionCondition href="POWarehouseNAK "/> 50        </Transition> 51        <Transition> 52          <SourceInteraction href="POResponseToConsumer"/> 53          <DestinationInteraction href="End"/> 54        </Transition> 55        <Transition> 56          <SourceInteraction href="POErrorToConsumer"/> 57          <DestinationInteraction href="End"/> 58        </Transition> 59    </ConversationTransitions> 60    </Conversation>

8.5.1. Writing a WSCL Application

A WSCL application is written as an XML file that references the WSCL schema, as well as application message schemas representing the interaction input and output messages. Imagining a graphical WSCL editor is easy:

Drag start and end interactions onto the canvas.
Import a number of WSDL definitions into the editor. Drag their operations on the canvas as interactions.
Draw transitions by connecting arrows between interactions.
Select the menu option Save as XML.

8.5.2. Weaknesses in WSCL

Here are the three main deficiencies of WSCL:

A conversation is the subjective view of a single participant, not a global view encompassing all participants. All WSCL interactions in a given conversation are for one role (e.g., retailer), although the identity of that role is not specified in the XML code. A send interaction, for example, represents a participant of that role sending a message (e.g., PO response) to another participant (e.g., consumer), whose role is not explicitly specified either. WS-CDL interactions, by contrast, are always tied to a specific relationship of roles, and a choreography can support multiple relationships. One implication of WSCL's subjectivity is that important interactions that do not directly involve the conversation's role (e.g., warehouse sends shipping notice to the consumer) are not captured at all in the conversation code. WS-CDL avoids this problem because of its ability to describe multiple roles and relationships.
NOTE
WSCL is not an orchestration language. Although a conversation captures the view of a single participant, it is the publicly observable view (i.e., just the interactions, not any other internal logic), and hence is essentially a choreography.
WSCL's state machine is too simplistic, lacking (for example) adequate exception handling and hierarchical state.
The relationship to WSDL is too weak. Why not reference port type and operation, rather than individual schema links, in the declaration of an interaction?

8.5.3. The Future of WSCL

Do not expect to see any WSCL implementations in the coming years. WSCL is far too obscure; its elegant approach cannot help it, and its weaknesses cannot hurt it. Nonetheless, those two factors make WSCL a prime case study for choreography; specifically, the importance of a global view.