Is WS-Transaction useable in the real world today?

The WS-Transaction specifications can be used by a Web service to include the processing of the service in a distributed transaction. But Web services themselves are often simply a means to integrate existing applications into new composites and/or a means to expose those applications to new types of clients/channels. So, in a bottom-up design where new Web services that can exploit WS-Transaction capabilities are wrappering existing back-end applications, do the back-end applications have to have been designed to be used with transactions?

The answer is: it depends...

The back-end applications might provide a core business service that has been doing its job well for many years and runs in an environment that ensures the transactional integrity of any data updates performed by the application, such as a CICS program. Or the back-end application might be a database stored procedure, or a purchase order workflow or anything else.

Most of them will have been around for longer than the WS-Transaction specifications but equally most of them can be exposed through Web services that exploit WS-Transaction capability.

• WS-AT is typically useful only when the back-end application runs in an environment that supports some form of distributed 2PC, although the precise manner of the 2PC really doesn't matter since the WS-AT provider can adapt the AT protocol messages to the desired domain-specific transaction protocols. So, for example, WebSphere Application Server represents a received WS-AT context as a JTA transaction within the AppServer process and hence subordinates any XA resource managers (including XATransaction JCA resource adapters) and downstream OTS resources (and on zOS, any RRS unit of recovery) to the received WS-AT context.
• WS-BA is typically useful when any work performed by the back-end application can be undone/reversed through a compensation handler that drives another back-end application (or by the same back-end application with a different set of data). The compensation handler logic itself is application logic but the determination of when/if such a compensation handler should be driven and the recoverable recording of data to be used by the compensation handler is what the WS-BA infrastructure must provide.

WAS provides robust runtime support and application assembly for Web services to exploit WS-AT or WS-BA which can be used in highly available configurations as well as mediated/proxied toplogies. The development tasks associated with supporting WS-AT and WS-BA in WAS are focussed on application assembly and configuration rather than Java programming, the only coding requirement being the CompensationHandler class (a plain old Java object) in the case of WS-BA.

There's plenty of information in the WAS 6.0 and 6.1 InfoCenters on how to use this feature of WAS and samples that can be downloaded from developerWorks. As a general guide through all that information, I posted an article on Web Service Transaction support in WAS on the WebSphere Community Blog. There's also a good article on Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction that describes how to configures both systems for WS-AT interoperability.

Going back to the title of this article, I believe the answer is a resounding Yes and there are numerous commercial runtimes - including IBM's WebSphere Application Server and CICS - that have tried and tested production-ready support available today.

Feel free to comment on any gaps in the information that could be usefully filled.

Web Services Transaction 1.1 OASIS Standard published

OASIS, the international standards consortium, announced on 8 May 2007 that its members have approved Web Services Transaction (WS-Transaction) version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification.

The final open standard versions of the WS-Transaction 1.1 are now available at the locations referenced in my earlier post.

Which J2EE platform does Ségolène Royal use?

Ségolène Royal
Originally uploaded by Fr@nçois.

WS-Transaction 1.1 has been committed

The WS-Tx TC - which IONA's Eric Newcomer and I chair - has now delivered the WS-Transaction 1.1 OASIS Standard which comprises the following specifications:

• WS-Coordination 1.1 - which describes a common framework for Web services transaction models,
• WS-AtomicTransaction 1.1 - which uses WS-Coordination and describes a Web services protocol for atomic, 2PC transactions,
• WS-BusinessActivity 1.1 - which uses WS-Coordination and describes a Web services protocol for compensating transactions.

The TC held its first meeting in November 2005 and took, as input, drafts of these three specs that were contributed by members of the TC including IBM, Microsoft, IONA, Hitachi and BEA. During the course of the TC a number of the companies involved in the TC (IBM, Microsoft and JBoss/RedHat) developed implementations of the specifications to test the completeness of the specification by driving a number of pre-agreed AT and BA interop scenarios. We did this remotely using internet endpoints and it successfully validated all the parts of the specs covered by the scenarios. You can view the results for AT and BA scenarios.

Follow-on work

The TC will continue in maintenance mode to work on any maintenance issues brought to our attention and to produce a new version of the specifications with an updated references to WS-Policy 1.5 once the W3C has published a W3C Recommendation for WS-Policy 1.5 anticipated in August 2007.

Tags: ws-tx, WS-Transaction, WS-AtomicTransaction, WS-Coordination, WS-BusinessActivity, WS-AT, WS-BA

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

The final WS-Tx TC meeting?

Last week we had what will probably be the final WS-Transaction TC (WS-Tx) face-to-face meeting, here in Hursley in the UK. Its nice to have everyone else do all the travelling now and again.
I have co-chaired the TC with Eric since November 2005 and we are now nearing the end of the standardization process.


The TC will shortly vote on the approval of committee specification status for our 3 specs - WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity. This is the penultimate stage before submitting to the OASIS membership for consideration as an OASIS standard.

You can see the excitement on the faces of the technical committee as we prepare for the final stage of the standards effort...

The photo was taken in the Kings Head in Hursley, by Bob Freund.


Its been a long and winding road - early drafts of the input specs were published as long ago as 2002 and the foundation WS-Coordination specification was itself inspired by earlier work on the CORBA Activity service. There are already several generally available implementations of the input specifications and pre-production implementations of the proposed final standard. It is to be hoped that the proven success of the WS-Tx protocols in existing, commercially available products together with the extensible nature of WS-Coordination will make this technology the obvious base for new types of coordination protocols. Time will tell...

Margaret Thatcher and me

I am proud to have one thing in common with The Iron Lady.

Before she married Dennis, became Prime Minister, destroyed Britain's coal industry, and gave us all a laugh by leaving Downing Street in tears, Margaret Roberts was a research chemist whose work included the study of Langmuir-Blodgett films, the topic of my own PhD. Margaret and I both moved on from our careers in research.

Ultimately though, neither of us was as successful as Katherine Blodgett who, as you can see from the link, went on to become Queen Elizabeth II.

WS-ResourceTransfer update

In 2006 IBM, Microsoft, HP and Intel announced an initiative to unify the WSDM and WS-Management standards supporting service management. This initiative includes the unification of the infrastructure that underpins WSDM and WS-Management. I'm the editor of the first specification published (in Aug 2006) as part of that initiative - WS-ResourceTransfer (WS-RT) - which defines a Web service retrieval and update protocol for manageable resources. This specification took as its inputs the WS-Transfer W3C member submission and the WS-ResourceFramework (WSRF) OASIS standard; our goal is to bring together the two communities using these specifications, and those that build on them,

At the time of writing the most recent activity on this specification was the public feedback workshop held in Cupertino, CA, on 6 Dec 2006. The feedback we received was generally very positive and will be factored in a future revision of this specification. A foilset that describes the WS-RT specification and the feedback we received are available through the WS-RT Workshop YahooGroup.