The notion of a conversation is not new in distributed computing systems (or for that matter to human society). Every day we engage in both structured, contextualized conversations such as negotiating for a beer at a bar, and unstructured ad hoc conversations such as asking a work colleague about his plans for the weekend. We are also quite used to having conversations with machines in the form of ATM transactions and similar things (shouting at the monitor when the computer "misbehaves" does not count as a conversation). Take for example a typical barroom scene as shown in Figure 5-1. This is a typical pub situation where a customer orders a drink and goes through a relatively structured conversation with a server. Although the context is well established, a computer system would not be able to cope well with such a scenario because of the wide range of mannerisms that people use when ordering drinks, nor would a computer system be able to help the "customer" that just popped into the bar for directions.
Figure 5-1. A simple inter-human conversation.
While it is impossible for an unintelligent computer system to partake in unstructured conversations, using an ATM shows that it is quite possible for a computer system to understand structured conversations within a particular context. While we could yell at the ATM until it did what we wanted, we might be in for a long wait since such an ad hoc, unstructured, and out-of-context conversation is unlikely to be understood. Conversely, yelling at our friendly barman, though usually uncalled for and running the risk of a punch in the nose, will result in a continuation of the conversation.
From these scenarios we can deduce that conversations are only meaningful in a computing system where the context is well established, and the number, type, and semantics of possible exchanges are known in advance by both parties involved. If either party digresses from the agreed conversation format, then the conversation simply falls apart.
Conversational Requirements for B2B Interactions
While SOAP and WSDL (see Chapter 3) are fine for single-shot exchanges between a client and a Web service, most B2B and B2C interactions of any real value involve multiple message exchanges. Indeed even the simple process of ordering a beer (as shown in Figure 5-1) involves several well-orchestrated message exchanges in order to succeed. It is precisely because typical Web services interactions are multi-phased that we need a mechanism to accurately orchestrate which party is required to send what message and when.
For an analogy to help understand Web services conversations, consider a typical soda vending machine such as that shown in Figure 5-2. While we are all, of course, implicitly familiar with how these kinds of machines work and take for granted the sequence of actions that are necessary to buy a drink from them, it is useful to think about just how this is actually achieved.
Figure 5-2. Rich interfaces consist of operations plus descriptive metadata.
A typical vending machine actually has a number of buttons coin/note slots, trays and so forth that can be accessed by the user. In fact, the number of possible combinations of interactions with these machines is actually staggering, and only a few of them will result in a drink being dispensed.
This is rather like a Web service where we have operations exposed to the network that are analogous to the buttons and coin slots and so forth on the vending machine. A typical Web service will require its operations to be invoked in a certain order to progress the interaction through to completion. While on the vending machine we will often have a set of instructions that detail in which order money should be inserted, drink selected (or money reclaimed), and drink removed, our Web service's WSDL interface does not provide this additional meta-data (though it may well provide human-readable comments). To provide as rich an interface to Web services clients as vending machines do to their human clients, Web services must expose computer-readable descriptions of how they should be used, just like the human-readable descriptions posted on vending machines.
Of course to support conversations in Web services, we need a standard way of describing dependencies between operations in a standard, structured way. While natural languages might be implemented in user documentation or embedded as comments in a WSDL interface to aid a developer, this is generally not an approach that favors automation (which is ironic given the amount of tool support that exists to solve exactly this problem for WSDL interfaces). However, one proposed technology that seeks to redress the balance between static and dynamic descriptions of a Web service and thus enable conversations is the Web Services Conversation Language.