The roots of WS-Coordination

When the OASIS WS-Tx TC was formed, Eric and I (as the co-chairs) did a number of press and analyst interviews to explain what it was all about. Eric, being the urbane and media-savvy CTO, made observations such as "I think everybody saw where it was going early on in the dot-com days, but it's taken a while to get there". My pearl of wisdom that got used in the same article:

Though WS-Coordination is the first spec in line for approval, Robinson called it "perhaps the hardest to understand."
"It deals with the context of the transactions," he said.

Well I'm glad that's clear then.

So what are the origins of the WS-Coordination part of WS-Transaction and what is it all about? WS-Coordination is one of three specs that together comprise WS-Transaction 1.1. The underlying two-phase commit (2PC) and compensating transaction models that underpin the other two specs - WS-AtomicTransaction (WS-AT) and WS-BusinessActivity (WS-BA) - are well-known from the literature (for example Gray&Reuter); WS-AT and WS-BA pretty much just describe an XML structure for the 2PC and compensation model protocol messages that defines those two transaction models. But what about WS-Coordination?

The origins of WS-Coordination are in the CORBA Activity service, which itself was the result of an OMG request for proposals to specify Additional Structuring Mechanisms for the OTS Specification.

CORBA Activity Service.
The Activity service defines a CORBA framework for extended transaction models, recognizing the common attributes of distributed transaction models without preferring any specific one of them. Specifically, the framework defines:

• a generic Activity context that is distributed to Activity participants
• a generic ActivityCoordinator with which Activity participants are registered and which is extended by model-specific SignalSets
• the notion of a transaction-model-specific SignalSet which produces model-specific Signals that the ActivityCoordinator delivers to the registered Actions (participants) and consumes Outcomes that are returned by the Actions. For example, a 2PC SignalSet produces "Prepare", "Commit", "Rollback" etc Signals and consumes "Prepared", "Committed", "Aborted" etc Outcomes.
  

A specific transaction model is defined in terms of its SignalSet, the Signals produced by the SignalSet and the Outcomes consumed by the SignalSet. The participants in any specific transaction model are Actions which must be implemented to understand the model-specific set of Signals and Outcomes.

The Activity service specification defines an overall extended transaction framework architecture but does not explicitly distinguish which parts of the architecture are intended to be provided by middleware infrastructure and which parts are intended to be provided by the transaction-model-provider. Such architectural partitioning is explicitly specified in the J2EE rendering of this architecture - the J2EE Activity service (JSR 95), which finalized in 2006.

J2EE Activity Service
The J2EE Activity service defines Java interfaces for the Activity service objects. It defines the notion of a "High Level Service" (HLS) which embodies a specific transaction model. The J2EE Activity service specification defines a specific contract between a J2EE container and a HLS in much the same way that the Java Connector Architecture specification defines a contract between a J2EE container and a resource adapter.



In the J2EE Architecture, the server runtime implements the ActivityCoordinator interface which supports the registration of participants (Actions), and the UserActivity interface which supports Activity demarcation. The server runtime also marshals/demarshals Activity contexts on remote invocations; the J2EE architecture leverages the CORBA Activity service specification for its definition of interoperable Activity service contexts in much the same way that the EJB specs leverages the CORBA OTS specification for its definition of interoperable transaction service context. Providers of specific transaction protocols can then register a transaction protocol-specific HLS with the container's Activity service to integrate transaction-specific behaviour into the container. Such an HLS implements the SignalSet, Signal, Action and Outcome interfaces that the Activity service drives. The HLS and Activity service cooperate together during transaction completion but maintain separation of concern: the ActivityCoordinator maintains knowledge of which participants are registered, obtains each distinct protocol Signal from the local HLS SignalSet, distributes it to each of those registered participants ("Actions") and feeds the results ("Outcomes") back into the SignalSet.

WS-Coordination
The WS-Transaction architecture is a Web services evolution of the Activity service, focusing on the interoperable context and Web service messages that flow between coordinator and participant. WS-AT and WS-BA each essentially describe an HLS, defining a transaction-model-specific set of messages. WS-Coordination fulfils the role of the container-provided Activity service, defining the interoperable XML CoordinationContext and the means for participants to be registered with an Activity.

The focus of WS-Transaction is the interoperability between coordinators and participants in different systems; consideration of intra-process separation between the transaction service provider itself and the runtime (application-hosting) container and/or hosted applications is a domain-specific detail that is outside the scope of the Web service specifications. As a result, the WS-Transaction specifications do not define any equivalent of the HLS SignalSet interface nor do they define a generic mechanism for producing and consuming a single (extensible) typed Signal. Instead the WS-Transaction architecture requires each transaction model-specific protocol specification (such a WS-AT and WS-BA) to define its own set of XML protocol messages along with coordinator and participant WSDL portTypes to consume these messages. In common with Activity service HLS's, individual WS-Transaction protocol specifications are at liberty to define model-specific interfaces/protocols to enable applications to demarcate transaction boundaries. WS-AT, for example, defines a Completion portType and protocol through which an application can request the completion of an AT transaction (which then causes the 2PC protocol to be initiated with the registered participants).

Since the WS-Transaction architecture is a Web services evolution of the Activity service, it should be possible to implement it on top of an existing Activity service architecture, right? After all, a significant amount of Web services infrastructure is a thin XML veneer on top of something else, right? Well, yes. I'll blog about how we do that in WebSphere Application Server another day.

Further Reading
This posting has focused on how the CORBA/J2EE Activity service provided much of the inspiration for WS-Coordination. For a discussion on where a number of other extended transaction models, such as BTP and WS-CAF, fit in and compare with WS-Transaction the following articles are useful:

• Extended transaction models for Business Process Management: from CORBA to Web Services
• A comparison of Web services transaction protocols