Conversations in SCA (Service Component Architecture)

Services often interact multiple times to complete a business activity. Such interactions are said to be part of a conversation. In the Database world, a series of database activities are grouped as a part of a transaction. The notion of transaction was extended to Distributed Computing too. In the world of distributed computing, many frameworks and services came up to support distributed transactions. When webservices evolved, standards like WS-Transaction and WS-Transaction Management (WS-TXM) tried to solve the transaction problem. However, a conversation is not a transaction. It does satisfy ACID test of transactions. Rather a conversation is just a way of identifying a series of interactions as a part of one larger activity. In other words, it is like correlating various service invocations related to a single business activity. Hence, conversations and transactions are handling with different constructs in SCA.

Multiple efforts have already been made to standardize conversations in Web services. A long time back, in 2002, HP submitted a specification to define a Web Service Conversation language (WSCL), which was a supposed to be supplementary to WSDL. However, it did not receive any support. Last few years parallel efforts were made at OASIS to standardize two competing specifications, WS-Context and WS-Coordination. Both of them at a very higher level defined notions of context and frameworks to manage them. ebXML supported its own way of conversational trading interactions. BEA implemented annotations based conversations for JWS. SCA’s proposal can be viewed as evolved from annotation based conversation and additional declaration of the conversation intent in policies.

The concept of conversation in SCA is very simple. A conversation may start with calling a method of conversational service (annotated as @Conversational). The conversation continues till a service reference created at start of the conversation is being used. Finally, the conversation ends with invoking a method annotated as @EndsConversation or the conversation timeouts due to being idle for a long time or continued more than a maximum age set for the conversational service. Any further attempt to participate in the “ended” conversation results into an exception, namely, ConversationEndedException.

To make this working in SCA, in addition to annotations in WSDL or Java sources, a conversational intent needs to be declared in policies for the conversational interfaces. Policy interceptors and binding components would then handle the work of populating the conversational context and interact with conversation framework. Thus the developers of services would be spared from the overload of managing conversation.

However, SCA does specify any implementation framework for managing conversation. Rightly so it does not even define a format for conversation identifier. SCA conversation intended to be complementary to various existing standards. Why re-invent the wheel? So one may use a sequence of WS-RM, or correlation id of JMS, context of WS-Context or WS-C, or MessageID of WS-Addressing as a conversation indetifier and use policy/binding implementations based on WS-Addressing, WS-RM, WS-Coordination, WS-Context for conversations.

Like BPEL, SCA assumes that conversations may also be long running. In case of BPEL, a conversation is maintained by using a concept of correlationSets, which can be mapped to a payload. Oracle’s BPEL PM additionally supports WS-addressing based correlations. BPEL does not support explicit end or aging of the conversations. SCA containers would need a framework to handle end of conversations. Meanwhile, a lightweight conversations based only on conversation ID may be sufficient for many applications.

I am attaching a simple diagram representing a conversation between two services. It is based on a business interaction to configure and purchase a PC.

SCA