In retrospect, approaches to implementing distributed transactions -- more specifically, short running business data transactions -- have remained remarkably unchanged both at the physical and logical level in the midst of considerable computer technological advance.
Even with the advent of the WS-AtomicTransaction (WS-AT) and WS-Coordination (WS-COOR) specifications approved this year, which are fundamentally a veneer of technology and metadata wrapping the venerable XA protocol, there still remain less than a handful of system use cases for implementing distributed transactions.
The purpose of the OASIS WS-Transaction (WS-TX) specifications is to define a set of protocols to coordinate the outcomes of distributed application actions, that is, specification-speak for transactions, although it can represent other types of events.
Distributed transaction solution set
In the absence of high-end data integration tools, like IBM's WBI (WebSphere Business Integrator) or BEA's WLI (Weblogic Integrator), you may need to consider a programmatic-intensive solution for distributed transactions and/or moving data at the application-level.
The following system use cases for implementing distributed transactions have been identified:
- Bean-managed transactions - the code in the application explicitly marks and manages the boundaries of the distributed transaction.
- Container-managed XA-style transactions – the container manages the transaction and relies on the XA protocol and two-phase commits for coordinating the distributed transaction.
- Web services transactions – use WS-COOR, a basic coordination mechanism on which protocols are layered, and WS-AT, a classic two-phase commit protocol.
In practice, the first two approaches are really more appropriate for enterprise-wide type integration; whereas, the last construct could be used over the Internet for B-to-B type integration, if you consider your organization to be a cutting-edge adopter of technology.
Given the finite set of alternatives for distributed transaction processing, this discussion attempts to define why XA has been and will remain a key component within enterprise-wide systems reference architecture, until a completely new paradigm for managing distributed transactions is invented.
Bean-managed distributed transactions
Using Bean-managed transactions, as an alternative to XA, is probably the most popular construct for building distributed transactions. Figure 1 depicts a typical distributed transaction.
Figure 1 - Moving data between two databases and a JMS message within a tightly coupled workflow
Although, using an EJB for Bean-managed transactions is not strongly recommended, since one of the reasons you use an EJB is to provide container-managed transactions for XA or non-XA-style transactions. With XA in place, an EJB can manage a transaction that spans multiple XA-compliant resources and treats those resources, essentially as a single resource. If you aren't using EJB in this fashion, it probably isn't worth using at all.
Container-managed EJB distributed transaction
For Java EE applications, a container-managed EJB is the best construct for implementing an XA-style transaction. It essentially is performing the same fundamental operations as the Bean-managed EJB. However, the container manages all transaction instructions and, in the event of a failure, the Java Transaction Service (JTS) will roll back all of the participating resources. From a programmer perspective, this solution still represents the simplest approach to implementing distributed transactions, even compared to Web services as we will soon see.
WS-Transaction-managed distributed transaction
At a high-level, WS-AT is designed so you can include two or more Web services into the same transaction. WS-AT provides the ability for your Web service applications to participate in global transactions. For example, you have Web service one (a Microsoft-bound Web service) and Web service two (a Solaris-bound Web service) and you can coordinate and manage the services as a single logical unit of work, similar to an XA-style transaction.
XA is not really the same thing as WS-AT, since it's the interface between the transaction manager and the resource manager. And, it is important to point out, that XA is not a remote protocol. However, the fundamental result is the same, that is, the transaction is coordinated among disparate resources.
Essentially, WS-AT's responsibility is to manage the distributed the transaction between your Web service applications, while the JTS takes care of registering the XA resources that are participating in the global transaction. When evaluating WS-AT, the complexity of "managing the distributed transaction between Web services," in my mind's eye, appears to be the most daunting part of using the technology.
The sequence diagram below focuses on the coordination and registration process when using a WS-AT style transaction. The model represents the database operations depicted in Figure 1 exposed as Web services. The basic Web flow is:
- an application makes a request to the activation service;
- the coordinator begins a new activity;
- the application registers;
- the application invokes 1 to N Web services;
- the Web service(s) make a request to the registration service to use a specific coordination protocol, which includes the coordination context passed by the application;
- Web services complete their work and control returns to the application;
- the coordination service manages the outcome of the transaction.
Figure 2 - Using WS-AT to manage a Distributed Transaction via Web services
Note: the diagram is a high-level representation of a two-phase commit use case scenario, based on my understanding of the WS-AT and WS-COOR specs. Web service N is a logical realization of the transaction in that the transaction can span multiple XA-compliant resource (JMS, D2, Oracle, SQL Server, etc.)
Currently, WS-TX implementations are available from IONA Technologies, IBM, Microsoft, Red Hat (i.e. JBoss) and Choreology (a small UK company). In addition, Sun will release a version soon, if they haven't already. Oracle and BEA participated in the development of the standard and are expected to also have their own implementations of the specs.
The nascent "best practice" use of WS-AT
SOAP-based and WS-* specifications are designed to work together to define a rich Web services (transaction) environment. WS-AT by itself does not define all features required for a complete solution. WS-AT is considered a building block used with other specifications of Web services (e.g., WS-Coordination, WS-Policy, WS-Security, etc.) and application-specific protocols that are able to accommodate a wide variety of coordination protocols related to the coordination actions of distributed applications.
WS-AT is a two-phase commit transaction protocol and is suitable for short duration transactions only. Application servers that implement the WS-AT specification, enabling the Web services application to participate in global transactions distributed across a heterogeneous Web services environment. As a transaction manager, the application server supports the coordination of resource managers through their XAResource interfaces and participates in distributed global transactions with transaction managers that support WS-AT.
The expected best practice is to use WS-AT within a single enterprise, avoiding WS-AT usage across enterprise domains. The application server runtime takes responsibility for registering WS-AT participants in the same way as XA resources are registered in the JTA transaction to which the WS-AT transaction is federated.
In keeping with the spirit of Web services as interfaces to existing implementations, the WS-AT and WS-COOR specification author's design exposes XA. As a consequence, organizations that in the past have had issues with supporting XA will also have issues with supporting this new technology, which adds a layer of abstraction and complexity in addition to XA. Although, it seems that Web services and SOA have enjoyed, so far, a certain cache that XA never had and organizations will probably go through the necessary hurdles in order to support it.
About the author
Frank Teti is a principal architect and industry analyst. He can be reached at firstname.lastname@example.org.