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.