Conversation Support
for agents, e-business, and component integration

Frequently Asked Questions

• How does Conversation Support compare to proposed standards such as BPEL or WSCI?

  The short answer is that it's complementary to them; see the article here for a fuller discussion.

  The essential point is that conversation support is not about Web Service choreography, whereas WSCI and BPEL are.

  Certainly the high-level description of WSCI, for example, attempts to position it as providing support for conversations. Unfortunately, the terminology is getting increasingly muddied, because conversation is used by different people to mean different things.

  At bottom, BPEL, WSCI, etc., are languages for describing sequences of Web Service invocations: e.g., you use BPEL to specify the conditions under which such-an-such an operation can be invoked. The operations themselves are described by the usual WSDL. In this respect, WSCI is the same as BPEL, its predecessor WSFL, and even WSCL. Interestingly, WSCI seems to address some of the ideas of WSFL that didn't make it into BPEL--such as WSFL's plug links.

  WSCI, BPEL, WSFL, and WSCL all model an interaction as a kind of flow chart. E.g., first party A takes action X, then party B takes action Y, and so on. There are constructs for expressing conditional correlation of which action can follow which, and so forth.

  One important way in which conversation support is different is that it treats conversations as first-level concepts, and then represents interaction patterns in terms of state-machine-based protocols, not activity sequences or flow charts. The difference may seem subtle at first, but it's crucial. Perhaps an analogy will clarify things.

  We can think of a standard Web Service as a vending machine, in which its WSDL port types and operations define the various buttons, levers, slots, and so forth, on the front of the machine. Just by looking at the WSDL, there's no way to determine, for example, that you need to put money in the slot before you push any of the buttons. Web Service choreography languages such as WSCI, BPEL, WSFL, and WSCL all attempt to solve this problem in the same way: in effect, by giving instructions on which buttons to push in what order.

  Conversation support, on the other hand, replaces the "vending machine" model with a "telephone call" model. Two (or more) parties set up a conversational session, exchange various messages in the context of that conversation, and then, finally, close it down. The interaction protocol (expressed as a cpXML file) is used as a guide for how inbound messages are interpreted--not, as in the vending-machine model, whether they are deliverable at all. And instead of having each different kind of message correspond to a different Web Service operation, CS-WS uses an inbox/outbox model in which all messages sent to a given party in a conversation are sent to the *same* invocation point. Once a message arrives in the inbox for that conversation, the recipient's conversation management system attempts to interpret it using the information contained in the conversation policy--the cpXML file--that it is currently following. Note that this means that even unexpected messages get delivered and in many cases can be at least partially interpreted--enough to send back a specifically targeted request for clarification, for example, or to engage in a sub-conversation to find out what protocol the other participant is following.

• How to choose when to use conversations vs. service invocation choreography?

  Conversations permit a much looser, more flexible, and more dynamic coupling between participants than is possible with strongly-typed service invocations. One way to put it is this: standard Web Services enable loose coupling of implementations, but require tightly coupled interfaces; conversation support enables loose coupling of both implementation and interface.

  But this isn't necessarily always a good thing. For example, when two companies have both committed to a relatively long-term relationship, they can work together to define compatible sets of strongly-typed service interfaces in WSDL. In that case, the extra cost of conversation support, as measured in code complexity and runtime efficiency, may not be worth it. Similarly, there are probably a number of basic commodity services (such as registries and, say, stock-tickers), for which there's already a mature, stable strongly-typed service interface, which one might as well go ahead and use.

  The real value of conversations arises in situations where the collection (or economy or ecology) of available services is heterogeneous and/or changing over time. In such a situation, service providers will continually be trying to upgrade their services, fix bugs, and differentiate themselves from their competitors. Sticking with strongly-typed service invocations would lead to an insupportable proliferation of port types, or, worse, endless squabbles in standards committees. Conversation support, on the other hand, provides the degree of flexibility and feedback necessary to permit services to cope with a dynamic, heterogeneous, evolving community.

  One instructive thought-experiment in this regard is to imagine what would have happened to Frequent Flyer programs, if the travel industry operated using strongly-typed service invocation. In the 1970s, American Airlines invented the frequent flyer program, offering it to customers without consulting the other airlines. This gave it about a two year jump on its competition, who had to scramble to catch up. Between then and now, a series of modifications or improvements have been gradually introduced: options for seat upgrades; dozens of different rules and methods for getting upgraded; introduction of other measures of value (e.g. segments rather than miles); incorporation of ticket price into miles earned; affinity programs with other industries, such as car-rental agencies; hybrid rewards (get a ticket with miles+ cash instead of just miles); expiration dates on miles; cross-airline combined programs; etc.

  If all this change is going on in so simple and well-understood a process as buying airplane tickets, how much worse will it be for online services in general? Clearly, both providers and consumers of services will need some way of coping with it. Conversation support supplies that need.

• How does Conversation Support compare to ebXML?

  Conversation Support shares much of the same approach as ebXML's BPSS, particularly in its goal of describing protocols of message (e.g. XML Document) exchange. What's different is that (1) conversation support interposes itself at a lower level--i.e., it describes machine-to-machine conversations of any sort, not just business-to-business; and (2) conversation support, as it is currently implemented, bases its protocols on a model of interacting nested state machines, which is more powerful than BPSS.