Web Services Conversation Language

The rationale behind WSCL is that it captures the "time" dimension of Web services conversations and allows Web services to declare the conversation pattern through which they can be driven. WSCL is, at the time of writing, a W3C note submitted by the Hewlett-Packard Company. In January 2003, along with the process modeling language WSCI,^[1] WSCL became one of the inputs for the W3C's Choreography working group.

^[1] See Chapter 6 for a detailed discussion of workflow and business process modeling.

Although WSCL is now providing a basis for future conversation standards, it remains in use today in its current form. For example, UDDI.org uses WSCL as its first proposed language for describing the interfaces of conversational Web services.^[2]

^[2] See http://www.uddi.org/pubs/wscl_TN_forUDDI_5_16_011.pdf for UDDI.org guidelines on using WSCL.

The interaction between the consumer and provider of a service is achieved through XML document exchange where WSCL is used to orchestrate the various message exchanges that occur at each stage of the conversation. In fact, WSCL provides a means for declaring the types of messages that are exchanged, specifying the type of interaction that a message is used in (e.g. a one-way message from client-to-server, or a bilateral exchange), and the transition conditions that allow the conversation to progress from one interaction to the next.

Consuming WSCL Interfaces

Like WSDL, WSCL is an interface language designed to be consumed by Web services toolkits. Using both WSDL and WSCL, it is possible for toolkits to create proxies for Web services that not only encapsulate the remote operations and SOAP serialization aspects, but also provide structured help on the order in which operations should be invoked. That is, while WSDL provides message format and operation information, the WSCL description supports the creation of a conversation state machine that can guide the consumer of a Web service through its use. For example, consider the Java interfaces shown in Figure 5-3 and Figure 5-4.

Figure 5-3. A "Static" interface

 public boolean login(String user, String pass); public boolean buySong(String title, String artist); public File pay(CreditCard cc); 

Figure 5-3 shows the Java interface produced by consuming the WSDL of a simple MP3 vending service. For developers looking at this interface (or indeed the original WSDL interface), its use seems intuitively obvious. The user logs in, then tentatively buys a song which results in a unique token being presented, and then that token is used with credit card details to retrieve a file.

However, there is no way that an automatic system could have made the assumptions that we made to compile the interaction that is so simple for a human to undertake. Since humans are blessed with intuition and can deal well with ad hoc structures and arbitrary contexts, it is straightforward for us to reconstruct the state machine that represents this conversation we are uniquely privileged insofar as even if we cannot second guess what this state machine is, we can simply read the documentation!

On the other hand, even if a computer system made guesses until it got the interactions correct, it would require on average 7.5 guesses to reach a correct guess for this simple interface (given there are 15 possible use combinations). If the number of methods increases, then the number of guesses needed skyrockets.

Figure 5-4. A more "Conversational" interface.

 public boolean login(String user, String pass); public boolean buySong(String title, String artist)                       throws NotLoggedInException; public File pay(CreditCard cc)                       throws NoSongBoughtException; 

Figure 5-4 is a much richer interface since with the exception declarations it is possible for the proxy that the toolkit generated from the WSCL description of the service to take care of much of the error handling of the conversation. A simple example of a conversation-aware proxy can be seen in Figure 5-5.

Figure 5-5. A simple WSCL-based proxy implementation.

 public boolean login(String user, String pass) {   // Login to service...   _loggedIn = // The result of logging into the service   return _loggedIn; } public boolean buySong(String title, String artist)                                   throws NotLoggedInException {   if(!_loggedIn)   {     throw new NotLoggedInException();   }   // Buy song logic   _token = // The token from the remote service   return true; } public File pay(CreditCard cc) throws NoSongBoughtException {   if(_token == null)   {     throw new NoSongBoughtException();   }   // Retrieve the file   return file; } 

Although the approach adopted in the example of Figure 5-5 is simple, it does serve to show that a conversational interface can be used to guide the consumer's side of a conversation toward the correct interaction pattern for that service. Given a toolkit that supports WSCL and a service that describes itself with WSCL, we are already a significant way toward using conversations as part of our everyday Web services development.

At this point we can pause for breath, knowing that once again toolkits will make the consumption and application of WSCL straightforward. However, if we're developing rather than consuming a service, things aren't so simple. Given an arbitrary interface, it is highly unlikely that a piece of software can guess its conversation pattern and so, at some point, we will have to actually write WSCL (or at least provide assistance to a tool that creates valid WSCL for us). That means we have to drill down into the WSCL syntax and semantics and see for ourselves exactly how it works.