WSCL Interface Components

A WSCL interface is both complimentary and similar in spirit to its associated WSDL description. Like WSDL, a WSCL interface starts off simple and gradually builds up its description stage by stage until a whole conversation pattern is formed, ready for consumption on the Web. Our discussion on WSCL will follow the same pattern. Using the bar scenario as our example, we will start at the abstract sections of the WSCL interface and work our way through to a full-fledged conversation.


An interaction with a conversational Web service is modeled as an XML document exchange whose flow is seen from the point of view of the service being invoked. WSCL supports four distinct message exchange patterns.

  • Send The service creates a one-way message that is sent to the consumer and expects no correlated response from that consumer.

  • Receive The service expects to receive a message from the consumer, while the consumer expects no message back in return.

  • SendReceive The service initiates a bilateral message exchange with the consumer, for which it expects a correlated response.

  • ReceiveSend The service expects to receive a message from the consumer to which it will respond.

In our bar scene example there are seven interactions that comprise no fewer than 13 exchanged messages, as we see in Figure 5-6. Even though 13 messages is not a small number of exchanges just to order a beer, this situation can be much more complicated if, for example, the drink that the customer wants is out of stock, or the customer tenders insufficient money to pay for the drinks.

Figure 5-6. Determining the interaction types of the conversation.


The diagram shown in Figure 5-6 separates the conversation between the "thirsty author" and "friendly barman" endpoints into seven distinct interactions. In addition, those parts of the conversation where further progression is conditional on past execution have been highlighted where:

  • The customer has selected a drink the barman cannot offer and until that situation is resolved, the barman is unable to accept further drink requests.

  • The customer and the barman are unable to wish each other farewell until all drinks have been paid for.

Although the conversation represented in Figure 5-6 is necessarily simple, it shows all forms of possible interactions supported by WSCL. The interactions have been specifically factored this way to allow iteration within the conversation should it be necessary. For instance, during the sendReceive interaction where the "friendly barman" asks whether the "thirsty author" would like anything to extend his order, we reached a natural point in the conversation where the previous interactions could be repeated to order several drinks.

Using Figure 5-6 as the basis for our conversation, we can now progress to designing the messages exchanged by the parties and ordering those messages within interactions. In our bar scenario, the messages within the conversation deal with two types, namely beer and money, where broadly speaking messages are passed between the two conversation participants which amount to the fact that beer is exchanged for money. Figure 5-7 and Figure 5-8 show the implementations of the beer and money types as XML Schema schemas that are referenced within the messages exchanged during the interactions of the conversation.

Figure 5-7. Defining the "Beer" schema.
 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs=""   elementFormDefault="qualified"   xmlns:b=""   targetNamespace=" ">   <xs:complexType name="beer">     <xs:sequence>       <xs:element name="name" type="xs:string"/>       <xs:element name="brewer" type="xs:string"/>     </xs:sequence>     <xs:attribute name="domestic" type="xs:boolean"       use="required"/>   </xs:complexType>   <xs:element name="beer" type="b:beer"/> </xs:schema> 
Figure 5-8. Defining the "Money" schema.
 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs=""   elementFormDefault="qualified"   xmlns:m=""   targetNamespace="">   <xs:complexType name="money">     <xs:sequence>       <xs:element name="currency" type="xs:string"/>       <xs:element name="value" type="xs:decimal"/>     </xs:sequence>   </xs:complexType>   <xs:element name="money" type="m:money"/> </xs:schema> 

Once the XML schema types involved in the conversation are declared and hosted at a URI addressable location, we can move on to designing the messages exchanged within the interactions. A subset of the messages for this conversation (enough to give a flavor of the full message set) are presented in the subsequent set of figures, starting with the initial CustomerGreetingMessage (Figure 5-9) and ending with the BillMessage (Figure 5-12) toward the end of the conversation, with some of the more interesting intermediate messages in between. It is assumed for the purposes of this example that the targetNamespace attribute of each schema also resolves to the location where that schema resides (and thus can be accessed by any WSCL interfaces through their hrefSchema attributes).

Figure 5-9. The CustomerGreetingMessage schema.
 <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace= "" xmlns:xs="" elementFormDefault="qualified" attributeFormDefault="unqualified">   <xs:element name="CustomerGreetingMessage">     <xs:simpleType>       <xs:restriction base="xs:string">         <xs:enumeration value="Hello"/>       </xs:restriction>     </xs:simpleType>   </xs:element> </xs:schema> 

Figure 5-9 shows the schema for the customer's initial message to the bar service. The content of the message is simply the string Hello (which is aimed at helping any human readers of the message understand its intent, rather than any WSCL-aware software agent since for those components the message type is sufficient for its purpose).

Figure 5-10 is the response to the CustomerGreetingMessage, the StaffGreetingMessage which contains string content that helps any human readers of the message to understand its intent in the form of "Hello, how may I help you?" On receipt of this message, both parties are effectively agreed that they are both engaged in the conversation.

Since the primary goal of using the bar service is to order a drink, it is satisfying to see the message exchange that achieves this conversation goal. The order message, called CustomerOrderMessage is shown in Figure 5-11. It uses the previously declared beer type from Figure 5-7 to convey to the bar service the type of drink required.

Toward the end of the conversation, the bar service must account for any drinks dispensed and issues a bill to the consumer. Figure 5-12 shows the message sent from the bar service to the consumer to request payment for the ordered drinks. In this case, the message makes use of the externally defined type money, which we defined previously in Figure 5-8. The corresponding message that conveys payment back to the service has a similar structure, but a different name of BillPaymentMessage.

Figure 5-10. The StaffGreetingMessage schema.
 <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace= "" xmlns:xs="" elementFormDefault="qualified" attributeFormDefault="unqualified">   <xs:element name="StaffGreetingMessage">     <xs:simpleType>       <xs:restriction base="xs:string">         <xs:enumeration value="Hello, how may I help you?"/>       </xs:restriction>     </xs:simpleType>   </xs:element> </xs:schema> 
Figure 5-11. The CustomerOrderMessage schema.
 <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace= "" xmlns:xs="" xmlns:b="" elementFormDefault="qualified" attributeFormDefault="unqualified">   <xs:element name="CustomerOrderMessage" type="b:beer"/> </xs:schema> 
Figure 5-12. The BillMessage schema.
 <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace=     ""     xmlns:xs=""     xmlns:m=""     elementFormDefault="qualified"     attributeFormDefault="unqualified">   <xs:element name="BillMessage" type="m:money"/> </xs:schema> 

Once we are happy with the messages that will be exchanged, we can begin to group these messages into the constituent interactions for the conversation. Each interaction in a WSCL message consists of a parent Interaction element that has attributes interactionType (one of those permitted interaction types: Send, Receive, SendReceive, and ReceiveSend) and a unique identifier. Within the Interaction element, a number of InboundXMLDocument and OutboundXMLDocument elements are embedded that define the messages to be sent or received. Within any individual Interaction element at most one InboundXMLDocument and one OutboundXMLDocument will be sent/received. The InboundXMLDocument and OutboundXMLDocument elements each contain a unique identifier and a hrefSchema attribute which references the schema that constrains the message. The attribute hrefSchema is optional, which allows the schema definition to be omitted in case of binary payload. This generic form can be seen in Figure 5-13.

Figure 5-13. The general form of a WSCL interaction.
 <Interaction interactionType="<send, receive, etc>"        >   <InboundXMLDocument hrefSchema="<schema URI>"        />   <OutboundXMLDocument hrefSchema="<schema URI>"        /> </Interaction> 

One significant limitation of the current WSCL W3C note is that the hrefSchema attribute is specified by the WSCL schema as anyURI, which means that messages can only be defined by directly Web-addressable resources. Therefore there is no way in which the messages defined in a WSDL document can be reused in a WSCL document since they are not addressable through a URI (though they are addressable through a QName or even could be made addressable through an XPath expression). Working within this limitation means that each of the messages that may be exchanged in a WSCL conversation, and indeed any XML Schema types used by those messages have to be accessible through a URI (which is likely to share its root path with the WSDL document of the service).

The interactions between the endpoints are specified in terms of the message we previously defined. Where in our human conversation we might expect the exchange along the lines of:

 Thirsty author: Hello. Friendly barman: Hello, what can I get you? 

We would now expect their (rather less personal) WSCL interaction equivalents:

 <Interaction interactionType="ReceiveSend" >   <InboundXMLDocument hrefSchema=       ""       />   <OutboundXMLDocument hrefSchema=       ""        /> </Interaction> 

Similarly, instead of the human interaction:

 Friendly barman: That will be $3.00 please. Thirsty author: Cheers (passes money to barman) 

we have the WSCL interaction that captures this action:

 <Interaction interactionType="SendReceive" >   <OutboundXMLDocument hrefSchema=       ""       />   <InboundXMLDocument hrefSchema=       ""        /> </Interaction> 

which describes the barman service demanding payment from the customer service (the outbound BillMessage message), to which the customer service responds with payment (via the inbound BillPaymentMessage message).

The fact that billing occurs after goods have been delivered is because the conversation takes place in a trusted environment (a pub in which if the customer leaves without paying, he will encounter an angry bouncer at the exit). Similarly, in trusted Web services-based trading environments where a system interacts with the systems of a partner, this approach also works (since businesses are used to sending invoices first and receiving payments later). However, in untrusted B2C and B2B conversations, it makes sense to take payments before releasing goods!

Although the interactions have been presented in an abbreviated form, the other interactions in this conversation are similar to those shown (all interactions are shown in the complete WSCL example at the end of this chapter). Knowing what interactions occur in the conversation, we can now move on to developing the transitions that dictate the overall flow of interaction between parties in this conversation.


Having implemented our conversation types, its message set and its set of interactions, we can now go one stage further with our implementation and actually design the transitions that implement the state machine for this conversation that is, actually get down to the business of ordering the interactions into a full-fledged conversation. For this, we use the communication pattern derived from Figure 5-6, which we have redrawn for clarity as a UML Activity Diagram in Figure 5-15. The activity diagram shows the possible states of the conversation and highlights the message exchanges at each state, along with the interaction patter. We have also taken the opportunity to tighten up the error handling aspects of the conversation so that no transitions permit the conversation to go wrong. This means that both orders that the barman cannot fulfill and any payment discrepancies (at least from the barman's perspective) will prevent the conversation from progressing until such matters are rectified.

Figure 5-15. A UML activity diagram for the bar conversation.


Codifying such rules in WSCL is straightforward. Each Transition element in a WSCL document has the following form:

 <Transition>   <SourceInteraction href="{some interaction}"/>   <DestinationInteraction href="{another interaction}"/>   <SourceInteractionCondition href="{some message}"/>     ... more conditions </Transition> 

Where the Transition element is a container for the following items:

  • A previous interaction that has occurred referenced by a SourceInteraction element.

  • The next interaction to occur references by the DestinationInteraction element.

  • A number of SourceInteractionCondition elements that only allow this transition to occur if the referenced message was the last document sent (by the Web service) during the interaction.

While the concept of specifying the source and destination of a transition in WSCL is both obvious and straightforward to implement, the guarding against particular transitions with the SourceInteractionCondition element is a little more tricky and subtle, allowing the conversation to constrain its transitions to arbitrary paths through the possible set of state transitions for particular conversations. Although there may be many legal paths through a conversation at first, the choices made as to which states we have been to may be used to constrain those that we may move to.

Figure 5-14 shows how the SourceInteractionCondition element can be used to guard against taking particular transitions in a conversation. The SourceInteractionCondition element that references an OutboundXMLDocument from an Interaction which must previously have been sent to allow the transition to occur and thus the use of SourceInteractionCondition is predicated on the existence of more than one possible OutboundXMLDocument for an Interaction. Note that the OutboundXMLDocument part of an interaction is used as opposed to the InboundXMLDocument part because the sender is implicitly aware of something that it sends, and may not be aware of something that it was intended to receive (for instance in a failure case).

Figure 5-14. Guarding state transitions with SourceInteractionCondition elements.


In this example, the execution of future interactions InteractionX and InteractionY are guarded by the sending of specific OutboundXMLDocument messages, MessageA and MessageB respectively. Given the constraints specified by the SourceInteractionCondition, it is now illegal in this example conversation to move from InteractionX to InteractionY if InteractionX sent a MessageB message (and the same holds for InteractionZ and MessageA messages).

Having understood the notion of an individual transition, we can now begin to build up a pattern of transitions which collectively define the conversation. For each transition identified in the conversation, an individual Transition element is declared in the WSCL interface, as is exemplified by the direct correspondence between each Transition element in our WSCL interface with each arrow in the activity diagram shown in Figure 5-15.

The conversation shown in Figure 5-15 moves from the (empty) Start state, to the Greeting state, to the Order state, after which time the customer is given a chance to augment the order on reaching the ExtendOrder state. Once the final order has been created, the conversation moves into the Serve state followed by the Bill state where drinks are paid for. Once a single order has been paid for, the customer has another chance to order drinks when the conversation moves to the ReOrder state. The conversation draws to an end when it moves from the ReOrder state to the Goodbye state, which results in the farewell messages being exchanged and the conversation ends in the (empty) End state.

Although the Start and End states do not appear in the human level conversation since the start and end of human conversations are implicit within the social protocols that we use, they are a feature of WSCL transitions which allows computing systems to understand the significance of the beginning and end of conversations in the same way. The upshot of this is that every WSCL conversation should have at least one possible transition from the Start state into the actual conversation and, similarly, at least one transition from some state in the conversation to the End state.

The WSCL specification does not mandate Start and End interactions, but as we shall see, it is good practice to use them to delineate the boundaries of conversations.

Having grasped the basics of WSCL Transitions, let's tackle the parts of the WSCL description that implement this simple UML activity. In Figure 5-15 we see that the interaction begins with a ReceiveSend operation that accepts a customer message and responds with a greeting from the barman. This transition causes the state to move from the special Start state to the Greeting state. The WSCL for this is shown below, and simply declares a source interaction and a destination interaction for this transition.

 <Transition>   <SourceInteraction href="Start"/>   <DestinationInteraction href="Greeting"/> </Transition> 

Following the Greeting state, we transit to the Order state, which allows the transition to the part of the activity where the customer orders a drink.

 <Transition>   <SourceInteraction href="Greeting"/>   <DestinationInteraction href="Order"/> </Transition> 

And so the conversation progresses until we arrive at the Bill state whose behavior is a little different since we have to deal with the constraint that a customer may not be billed without first having received the drinks. In our simple scenario, there is in fact no other way that the bill state can be reached without the customer having received the drinks. However in large, complex conversations, the ability to constrain access to a state based on activity in other parts of the conversation without having to contrive intricate transition paths is indeed a blessing. As such, the SourceInteractionCondition stays, not just as an example of its use, but as a means of increasing the robustness of the conversation in the face of future extensions.

 <Transition>   <SourceInteraction href="Serve"/>   <DestinationInteraction href="ReOrder"/>   <SourceInteractionCondition href="OrderMessage"> </Transition> 

There is one important limitation to specifying transitions without SourceInteractionCondition: If there exists a transition from SourceInteraction A to DestinationInteraction B that specifies a SourceInteractionCondition, then it is not possible to also specify a transition from SourceInteraction A to DestinationInteraction B without a SourceInteractionCondition.[3] That is, if there is a SourceInteractionCondition present which guards the execution of a transition, that SourceInteractionCondition cannot be bypassed by clever "routing" of other transitions, which prevents our constraints from being undone by future extensions to the conversation.

[3] This is taken from the WSCL 1.0 note at

Although it is the set of transitions which ultimately defines the set of permissible orders of interactions within a conversation, where there are choices in messages exchanged to trigger a transition, those choices are made by the logic residing in the application endpoints and are not expressed in WSCL. For instance, at the point in our example conversation where the customer decides whether to order another drink, the resulting message is produced as the result of some logic occurring in the customer's system (i.e., the thought, "Am I still thirsty?" is considered). Although the WSCL interface constrains the responses, it is not semantically rich enough to help with that decision. At the end of the day, a human programmer still has to understand any choices that can be made during the conversation.


The Conversation part of the WSCL description draws together the messages, interactions, and transitions into the final conversation description. Our discussion of the conversation part of WSCL begins with its endpoints, how conversations are begun and ended.

The first and last interactions of the conversation are given special identifiers in the WSCL specification such that a software agent consuming a WSCL interface can readily determine how to start a conversation and figure out when it has finished. If we examine the conversation element that supports our bar example, we see the following (abbreviated) opening tag for the Conversation element:

 <Conversation name="BarConversation"   initialInteraction="Start"   finalInteraction="End"> 

At this point it is worth pointing out that instead of the Start and End element being identified as the source and sink for the conversation, that the Greeting and Goodbye interactions could have been used. However, owing to the syntax of WSCL, it is only possible to specify a single initialInteraction and finalInteraction attribute for a conversation, though clearly it is possible to start and end a conversation in more than one way. In those cases where conversations can be struck up in a variety of ways, the Start and End interactions can in effect act as a "multiplexer" between the possible paths in the conversation, and the single source/sink syntax of WSCL. Although our conversation can, at the moment, only be begun or ended in one way, using the Start and End element provides that comfortable level of indirection should the conversation be extended in the future.

This strategy can work because the Start and End interactions are of type Empty. An Empty interaction is one that does not send or receive any messages, and acts as a "silent" intermediate state between two or more other states. In an Empty interaction, the XML form of the interaction is devoid of any InboundXMLDocument or OutboundXMLDocument child elements, like so:

 <Interaction interactionType="Empty" /> 

A possible conversation graph that shows this multiplexing behavior is presented in Figure 5-16.

Figure 5-16. Multiplexing endpoints with empty Start and End interactions.


Figure 5-16 shows two possible starting and ending points for the conversation, and shows how the empty interactions "Start" and "End" (i.e., the two that have no inbound or outbound messages) are used to multiplex the two possible conversation streams. In the declaration for the conversation, only the "Start" and "End" interactions are referenced, while the other more sophisticated interactions remain encapsulated away from the root conversation. This provides two ways of starting and two of ending the conversation, while remaining consistent with the Conversation element's syntax.

Having understood the role of the empty interactions, we are now ready to see how the conversation itself is represented in WSCL, as shown in Figure 5-17.

Figure 5-17. The Conversation element.
 <wscl:Conversation   xmlns:wscl=""   name="BarConversation" initialInteraction="Start"   finalInteraction="End"   targetNamespace=""   description="Simple bar conversation" >     <!--The rest of the conversation omitted --> </wscl:Conversation> 

The Conversation element for our bar example provides attributes that identify (name), optional version (version), and an optional annotation (description) for the conversation interface. In addition it declares the target namespace (targetNamespace) of the interface just like WSDL does, and identifies the schema (hrefSchema) which can be used to validate the document. The name attribute is a shared piece of information that both parties in the conversation use to ensure they both use the same conversation type. The value of the name attribute will also be propagated as part of a SOAP header in any of the messages exchanged within the context of the conversation to ensure correlation of conversation messages at both sides of the conversation. Of course, the root element's attributes also declare the entry and exit points of the conversation as we saw earlier.

Developing Enterprise Web Services. An Architect's Guide
Developing Enterprise Web Services: An Architects Guide: An Architects Guide
ISBN: 0131401602
EAN: 2147483647
Year: 2003
Pages: 141

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: