Relationship Between WSCL and WSDL

The three main aspects of a Web service's interface are:

• Abstract interfaces: The application payload (in the form of messages) being exchanged and the order in which they are exchanged (which is known as choreography).

• Protocol bindings: The protocols used to enable the sending and receipt of messages.

• Services: The concrete service implementation that provides a network accessible address for a particular protocol at which the given message set is understood i.e., the location of an instance of the Web service.

If we reflect on our experience with WSCL and our previous experience with WSDL, then it is clear (as we might expect from two technologies that are both Web service interface languages) that there is some overlap, as shown in Table 5-1:^[4]

^[4] The following tables are taken from the W3C WSCL Note at http://www.w3.org/TR/wscl10/.

Table 5-1. WSDL and WSDL Complimentary Features

Aspect	Function	WSDL	WSCL
Abstract Interfaces	Choreography	N/A	Transition
	Messages	Operation	Interaction
Protocol Bindings		Binding	N/A
Concrete Services		Service	N/A

Where WSDL and WSCL overlap, we can map the different terminology used as shown in Table 5-2.

Table 5-2. Mapping WSDL to WSCL

WSDL	WSCL
Port Type	Conversation
Operation One-way Request-response Solicit-response Notification	Interaction Receive ReceiveSend SendReceive Send
Input	InboundXMLDocument
Output, Fault	OutboundXMLDocument
Operation name	ID attribute of Interaction element
Operation input	ID attribute of InboundXMLDocument
Operation output	ID attribute of OutboundXMLDocument
Message	URI (which references an external schema)

The WSCL specification suggests that there are three possible approaches for combining WSDL and WSCL into a single Web service interface, depending on which stage the development of the Web service interface has reached. These are:

1. Where only abstract aspects of the WSDL interface exist, a conversational binding can be added to the WSDL interface.

2. Where existing portType declarations have been written, a cut-down WSCL description consisting of transition elements which reference existing operations can be added.

3. If a fully-formed WSDL description has already been written, a separate, full WSCL interface can be created which simply references the messages from the original WSDL document.

If the abstract parts of the WSDL interface have been completed, then we are able to provide WSCL functionality simply by adding a protocol binding. This is shown in Figure 5-21 where a conversational binding is provided where the operations in that binding reference the interactions of a WSCL interface, in accordance with the mapping shown in Figure 5-19.

In Figure 5-19, the attribute type="conv:BarServiceConversation" binding element references the name of the conversation in our example WSCL document presented in Figure 5-18, while the names of each of the operations refers to the ID of the interactions, thus exposing the conversation as WSDL operations.

Figure 5-19. WSDL binding to WSCL conversation.

 <?xml version="1.0" encoding="UTF-8"?> <definitions name="BarService"   xmlns="http://schemas.xmlsoap.org/wsdl/"   targetNamespace=" http://example.org/wsdl/bar"   xmlns:conv="http://example.org/conversations/bar" >   <binding name="BarServiceConversationBinding"     type="conv:BarServiceConversation">     <soap:binding style="document"/>     <operation name="conv:Greeting">       <soap:operation soapAction="Greeting">     </operation>     <operation name="conv:Order">       <soap:operation soapAction="Order">     </operation>   <! Other operations omitted -->   </binding>   <service name="BarService">     <port name="BarServicePort"       binding="BarServiceConversationBinding">       <soap:Address location="http://example.org/bar"/>     </port>   </service> </definitions> 

If the WSDL is already formed to the point where is has a portType definition, then we can bolt on the choreography aspects of the service with a cut-down WSCL description containing only the Transition elements. In this case we can simply map the SourceInteraction and DestinationInteraction elements of the Transition elements to the names of operations in the WSDL document, while any SourceInteractionConditions map to output or fault elements. Of course for this to work, WSCL would have to be equipped to reference elements in other documents (via QNames as we saw earlier). An example of this is shown in Figure 5-20.

The third and final method of combining WSCL and WSDL according to the WSCL specification is to simply provide full specifications for both, but where both interfaces share common messages. For instance the message declaration for Order in WSDL could simply refer to the same (externally defined) Order message that the WSCL interface uses, like so:

Figure 5-20. Combining WSCL and WSDL via portType QNames.

 <message name="Order"      xmlns:msg="http://conversations.example.org/bar/CustomerOrderMessage">      <part name="body" element="msg:OrderMessage" />  </message> <wsdl:definitions name="BarService"   targetNamespace="http://example.com/bar/wsdl"   xmlns:msg="http://example.org/conversations/bar"> <wsdl:portType name="OrderDrinkPortType">   <wsdl:operation name="CustomerOrder">     <wsdl:input name="Order"          message="msg:CustomerOrderMessage"/>     <wsdl:output name="OrderAvailable"          message="msg:OrderAvailableMessage"/>     <wsdl:fault name="Orderunavailable"                      message="msg:OrderUnavailableMessage"/>   </wsdl:operation> </wsdl:portType> ... </wsdl:definitions> <wscl:Conversation     ...   targetNamespace="http://example.org/conversations/bar"   xmlns:wsdl="http://example.com/bar/wsdl"> <wscl:Interaction interactionType="ReceiveSend"   >   <wscl:InboundXMLDocument name="wsdl:CustomerOrder"        />   <wscl:OutboundXMLDocument name="wsdl:OrderAvailable"        />   <wscl:OutboundXMLDocument name="wsdl:OrderUnavailable"        /> </wscl:Interaction> 

This is also used in the corresponding WSCL interface (where we see a matching hrefSchema attribute for our previously declared namespace):

 <wscl:InboundXMLDocument   hrefSchema="http://conversations.example.org/bar/CustomerOrderMessage"  /> 

Assuming a client of the Web service can access both interfaces, it is a straightforward task to marry the operations to the choreography based on their common messages.

What WSCL Doesn't Do

The WSCL specification contains the smallest possible set of elements and attributes to describe conversations. This set is thought sufficient to model many of the conversations needed for Web services. However, there are more complex interactions that may need additional capabilities from a conversation definition language. Such additional requirements include the following:^[5]

^[5] This summary is abridged from the WSCL Note available at http://www.w3.org/TR/wscl10/.

• Defining document types that have non-XML content (e.g., binary attachments). This is different from omitting the hrefSchema attribute because it supports constrained arbitrary data, whereas the absence of hrefSchema allows unconstrained data.

• Explicit description of the roles of participants (the only role that WSCL implicitly supports is that of the Web service itself).

• Multi-party conversations with more than two participants or roles. (Once we begin to coordinate multiparty conversations, we are in effect in the territory of business process management and outside of the scope of conversations per se. See Chapter 6 for a detailed discussion of workflow and business process management.)

• Expressing timeouts and other quality of service characteristics of individual interactions.

• Expressing more complex SourceInteractionCondition elements (e.g., listing several documents, excluding documents, or even referencing the content of documents).

• Events (interactions that can occur at any time within a conversation instance).

• Recursive conversations, aggregating conversations into larger conversations.

• Subtyping and extending existing conversation definitions.