The three main aspects of a Web service's interface are:
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]
Where WSDL and WSCL overlap, we can map the different terminology used as shown in Table 5-2.
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:
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 DoThe 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]
|