A Conversation about Web Service Conversations (Part 1)

This article distills some of my thoughts surrounding Web service conversations—a seemingly easy-to-grasp concept that can be surprisingly subtle. As I have the time, I hope to add more parts to this article; if you have suggestions, please feel free to add comments here.

What is "Conversation"?

Conversation in the Web services domain is a set of semantics overlaid atop a lower-level series of message exchanges. Any particular message exchange may or may not be considered part of a conversation.

Conversational state is the full set of information pertinent to these exchanges. Conversational state may be centralized (for example, in a message's content) or distributed (for example, in various stateful service instances), depending on the way conversation participants interact. It's important to understand that, technically, conversational state is not necessarily limited to business protocol state. Rather, conversational state may also be information pertaining to the ability of a particular service implementation to act on a message. For example, a set of configured components inside a service implementation may be considered part of the conversational state, even though it is static and unchanging across multiple conversations (though presumably not across all).

I can think of two broad perspectives on the meaning of the term conversation:

  1. As describing a causal set of message exchanges, where the causality implied by these exchanges is meaningful in some regard (though perhaps this "meaning" is simply the recognition by an omniscient observer that these exchanges are causally related). In this scenario, the body of information for the conversation is fully described by the message content exchanged between participants. For example, the state of the conversational information could be derived by simply looking at a log of the messages that were exchanged between participants. One way to think of this perspective is as messages acting as nouns, and service operations acting as verbs; messages are the embodied state of the conversation, and operations act upon this state to change it in some fashion.
  2. As describing the presence of context which provides additional information or semantics that is logically part of the body of information shared between the conversation participants. The information contained within messages themselves, then, are only part of the full set of information important to the combined function of the conversation participants. In this view, the full state of the conversational information is the state of the context of each participant. In this perspective, contextual information act as direct objects, and messages act as verbs to effect changes in that information. Each particpant retains a set of information relevant to that conversation.

State Implications of Conversation

Because the conversational state in perspective (1) is wholly described by the messages exchanged between participants, service implementations can be stateless. The necessary conversational state is reconstituted per request by a service implementation based solely on message content, and any particular service implementation's cache of this state is destroyed when a particular request has been satisified (for, example, by sending another message or by consuming the information in the message in some fashion).

Perspective (2), however, implies statefulness on the part of individual participants. Conversational state is the union of all contextual state from each particpant, and this state is inherently distributed.

Perspective (1) is a familiar paradigm from the Web application domain (actually, the Web application domain has versions of both (1) and (2)). For scalability, Web application servers may remain stateless and rely on a client to return any relevant state to the server during a subsequent request. In the Sun Java Studio Web Application Framework (a k a JATO), this capability exists as the page session and client session features. In JavaServer Faces, this capability exists as the client-state saving setting for an application.

However, Web applications also have the ability to maintain server-side session state (perspective (2) above). The server and client use a correlation strategy to associate a particular set of server side state with a particular client request. In Java servlet terms, this manifests as a jsessionid cookie being passed between client and server as part of a requests or response. The predominant Web application correlation strategy is based on an arbitrary, protocol-level key assigned by the server.

Although it is possible to define conversation in terms of perspective (1), perspective (2) appears to be the predominant assumption behind conversation in the BPEL domain (from which the formalism of conversation arose). The BPEL spec talks about process instances and correlation of messages to these instances. In various implementations (Collaxa, BEA Workshop), conversational state is typically either embodied as a "working set" of data used for a particular request (Collaxa), or embodied as a stateful object instance on the server to which messages correlating to that instance are routed (BEA Workshop). These approaches are equivalent—in both cases, a particular conversational context is present during the processing of a message which is determined to be part of that conversation; whether that state persists as a live object instance or a dehydrated set of data is an implementation detail.

Based on the way BPEL spec writers and various BPEL/service runtimes approach conversation, I assert that if there is no contextual state, there is no need for conversation as narrowly defined in the Web services domain.

Correlation Strategies

Correlation refers to the technique of assigning a particular message to a conversation. In implementation terms, it refers to the mechanism by which a particular message is assigned to a stateful process or service instance (or in other words, a context) for handling. Correlation is directly related to conversation; it is the mechanism by which conversation is tracked.

There are many possible correlation strategies. Here are a few being used today:

  • WS-Addressing: provides the ability to pass endpoint references as well as "thread" information, i.e. which message a reply message is in response to.
  • WS-Conversation: BEA's proposed spec for handling conversation using simple callback addresses and arbitrary conversation IDs. (WS-Conversation is implemented in WebLogic Workshop 8.x.)
  • Content-based: uses business protocol information to associate conversational state with messages.

Different correlation strategies have an effect on the ability to support bilateral or multilateral conversations (see section below). For example, content-based correlation appears to be the only correlation strategy to naturally support multilateral conversations, because the correlation information is potentially shared between all participants. By contrast, WS-Conversation requires the use of a conversation ID, which cannot easily be made known to more than two particpants (the originator and the recipient).

Types of Conversation

There are two distinct types of Web service conversations: bilateral and multilateral.

Bilateral conversations take place between only two participants. A particular particpant may be involved in more than one bilateral conversation simultaneously, but these conversations are distinct. That is, service A can simultaneously participate in bilateral conversations with service B and with service C, but the A-B and A-C conversations are distinct. The only common element is service A as a participant in both conversations; thus, B and C are not part of the same conversation. It is perhaps natural to consider these distinct conversations as part of a single, logical, overarching interaction, particularly if they are causally related. That is, from an omniscient view, we may consider these to be part of a single "conversation" in the broadest sense, but this usage of the term does not fit the narrower Web services defintion of conversation.

In a multilateral conversation, more than two participants may be involved in a single conversation. Using the example above, A, B, and C would all be participating in a single conversation, and B and C would be considered part of the same conversation. This type of conversation could be considered conversation in the broad sense, in that it corresponds to the omniscient perception of conversation. However, it is more rigorous than merely perception, in that a multilateral conversation implies some shared state between all participants, and some shared information used to correlate messages to the conversation.

In fact, this latter point is the main differentiator between bilateral and multilateral conversation. In a bilateral conversation, information used to correlate messages to the conversation is not shared by all participants and is limited to just two participants. In a multilateral conversation, more than two participants may share the same correlation information. The distinction between bilateral and multilateral conversations is important when talking about conversational state and correlation strategies at runtime.

Before I forget, there is a potential pitfall when using multilateral conversation with component-based Web service runtimes or frameworks. Specifically, these runtime architectures allow multiple Web service client components pointing to the same target service to be added to a single parent service. This causes a problem when the target service has a callback—the callback must be correlated to a particular component instance in order for it to take action in response to the callback. There seems to be no clear way to perform this correlation without using bilateral conversation, in which each invocation of the target service can occur within a different conversation. Within a multilateral conversation, there would be no way to differentiate callbacks meant for separate components. Therefore, multilateral conversations (and thus content-based correlation) may be incompatible with multiple service client component instances. The question is open as to whether an IDE or toolset could restrict the number of component instances if content-based correlation is being used, or if this limitation simply means that content-based correlation could not be used at all.


Post a Comment:
Comments are closed for this entry.



« July 2016