Today, many technologists believe that Web services are the proper mechanism for integrating with disparate database environments. Contrary to public opinion, Web services and distributed (aka XA) transactions are complementary, not alternative, technologies.
Recently, I read an article that stated that:
"Enterprise service buses are the preferred tools for integrating systems with heterogeneous data interchange interfaces and based on a wide array of technologies, from COBOL to CORBA to JEE". (Eugene Ciurana, Mule: A Case Study, TheServerSide.com)
While Web services are clearly useful for integration with heterogeneous data sources, relying solely on Web services, especially for heterogeneous (that is, distributed) transactions is more complex than supporting XA and architecturally limiting. Furthermore, the Web services specifications and resulting implementations are new, and therefore not as mature as XA. If Web services are pursued, a number of other WS-* specifications would need to be in place to begin to construct the transactional management that XA provides.
Still, I agree with Dan Foody, CTO of Actional in that "The long term success of Web services and SOA is directly affected by their ability to be used for mission critical solutions in the enterprise. Because many mission critical applications require transactional integrity, WS-TX (Web Services Transaction) will enable these applications to be successfully built and deployed using Web services without sacrificing multi-vendor interoperability."
Business and technical requirements
For the most part, all business software systems are derived from corporate processing requirements. Even the modern concept of an "enterprise service bus" I am sure was developed within a PowerPoint presentation of a senior business analyst in order to address the dysfunctional enterprise environment after a merger and acquisition.
Still, business process analysts should not be encumbered by the technological feat of a process design during the visioning stage of a new application, even if the requirements indicate the need for heterogeneous transactions between legacy applications. After all, that is what XA is all about.
My most recent project can be characterized as a significant enhancement to a five-year-old J2EE application, which by today's standards is part service bus and part business process management. This application was designed to integrate and unify the many claims management systems within a large insurance company.
These integration points are at the individual claim transaction level, so internal consistence of workflow transactions is paramount to the overall "enterprise-wide" system staying internally consistent. Based on these requirements and the specified logical units of work (see figures: Logical Unit of Work 1 and 2), it became clear to me that the best way to guarantee transaction integrity was to develop a set of XA-style transactions. While some analysts suggest that a set of Web services could accomplish the same object, there are limitations to using that construct, which will be further discussed.
XA-style distributed transactions
The XA interface is a mature protocol for treating DB2, Oracle and JMS (an XA-compliant interface to a physical queue) as essentially one resource, where logical transactions can be committed and rolled back. Using an XA-style transaction, the programmer does not need to be concerned with handwriting defensive, compensating transaction code, which is by nature error prone, in the event of unknown application-bound SQLExceptions or Java runtime exceptions.
The programmer, because of the enabling XA technology, can focus more on simply creating the atomic transaction code, let the XA resource manager handle rollback and commit logic. Without XA, the programmer needs to find a creative solution to rolling back the distributed transaction in case one of the participating resources fails, instead of a standard mechanism. Alternatively, the programmer might develop an optimistic construct and assume that his code will never fail, and it may not … until he/she leaves the project.
According to the XA specification documents in the Open Group's X/Open Distributed Transaction Processing (DTP) model, which defines how an application program uses a transaction manager to coordinate a distributed transaction across multiple resource managers, any resource manager that adheres to the XA specification can participate in a transaction coordinated by an XA-compliant transaction manager, thereby enabling different vendors' transactional products to work together.
High-end JEE application servers, such as, Oracle Application Server, WebLogic and WebSphere support JTA (Java Transaction API) required for XA style transactions. An XA transaction involves coordination among the various resource managers, which is the responsibility of the transaction manager.
The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. JTA specifies standard Java interfaces between the transaction manager and the application server and the resource managers.
All XA-compliant transactions are distributed transactions. XA supports both single-phase and two-phase commit. A distributed transaction is a transaction between two or more independent transactional resources (for example, two separate databases). For the transaction to commit successfully all of the individual resources must commit successfully; if any of them are unsuccessful, the transaction must roll back in all of the resources.
XA - The forgotten protocol
However, finding individuals initiated to XA is now becoming a somewhat elusive endeavor. Although, a colleague of mine within the organization corroborated that XA would be an appropriate mechanism, based on the design requirements (see figures below).
My next step was to contact the infrastructure manager(s) to see if XA was supported in the enterprise environment. I was surprised that the individual I contacted, although at least candid, did not know what XA was. After contacting other administrators that did, they were opposed to supporting XA, because of the additional OS and middleware (i.e. XA-specific database drivers) support the technology would require.
I first used XA on a large-scale DCE (Distributed Computing Environment) project with a major NYC bank where we used Transarc's Encina Transaction C++ (now an IBM company). This was in the middle '90s and XA was already established and one of the key protocols within the DCE. After all, if you are going to call yourself the "distributed computing environment" you better support distributed transactions.
XA, then and even now has a reputation for being slow, mainly because of the complex prepare and commit transaction lifecycle among disparate resources coordinated by the transaction manager. Although, considering the alternatives, it remains an important tool in the integration architect's toolbox. Indeed, XA outside the banking industry still appears to be an unknown or at least a little-used protocol.
Identifying the need for a distributed transaction
If your organization doesn't have a high-end data integration tool, you may need to develop custom distributed transactions applications. Here is a short list of reasons for using XA:
Moving data between a database and a JMS message within a tightly coupled workflow -- An application may need to move data from a database to another database and then send a JMS message to another disparate system or a message-driven bean that indicates the new data has arrived (see figure below).
Moving data between disparate databases as a transaction hand-off -- Moving data from one database to another requires an XA-style transaction or a normal transaction that includes a compensating transaction in the event of a failure. For example, the insert completes and the update fails (see figure below).
Alternatives to XA: The creative art of compensating transactions
As mentioned, most Java programmers use bean-managed transactions for developing distributed transactions. While bean-managed transactions can be straightforward, developing compensating transactions in the event of a failure sometimes can be challenging, especially with JMS in the mix that is.
A compensating transaction can take the form of a delete operation or a forced rollback. For example, for bean-managed transactions, an update, although successful, can be rolled back if the insert operation fails (see Logical Unit of Work 2) in order to keep the application workflow internally consistent.
Alternatively, for Logical Unit of Work 1, if the JMS send fails, the application construct can be built to be idempotent. That is, if the send operation fails it can be "repeated safely" maybe not immediately, because a failure might indicate that the resource is in an inconsistent state, but at some future time. Again, the application workflow will remain internally consistent. As a colleague of mine once cautioned, maintaining state in a distributed environment is an evil thing.
The point here is not that designing and developing compensating constructs is necessarily complicated. It is that in the absence of XA, non-standard and sometimes very unique strategies need to be devised for each distributed action failure, instead of letting the XA protocol and underlying resource manager manage the transaction. Essentially, the programmer has a standard mechanism for managing distributed transactions.
Alternatives to XA: Web services
Today some technologists are even positioning the enterprise service bus (ESB) as a standard mechanism for integrating systems with heterogeneous data interfaces. While ESB and Web services can clearly be used to move data between disparate data sources, I would not recommend using a set of Web services to implement a distributed transaction if the transaction requirements could be achieved by using XA, even if the enabling Web services technology supported WS-Transaction (WS-TX). The one advantage Web services have over XA is that XA is not a remote protocol, though.
WS-Transaction is the name of the OASIS group that is currently working on the transaction management specification. WS-TX is the name of the committee, and they are working on three specs:
- WS-Coordination (WS-C) - a basic coordination mechanism on which protocols are layered;
- WS-AtomicTransaction (WS-AT) - a classic two-phase commit protocol similar to XA;
- WS-BusinessActivity (WS-BA) - a compensation based protocol designed for longer running interactions, such as BPEL scripts.
In practice, WS-AT should be used in conjunction with XA to implement a true distributed transaction. WS-TX essentially extends transaction coordinators, such as OTS/JTS and Microsoft DTC to handle transactional Web services interoperability requirements.
I recently spoke with a senior member of the OASIS WS-TX committee from Oracle while researching this article regarding the robustness of WS-AT versus XA. He clearly indicated that while the technology was similar, testing at Oracle was problematic in certain system use case scenarios. This discussion has further corroborated my opinion that in the near future, if a distributed transaction is warranted, I will rely on XA rather that an immature, albeit, modern solution.
XA supported within JEE application servers, OS platforms and databases
Oracle, WebSphere and WebLogic application servers support XA transactions on Microsoft Windows (32-bit versions only), IBM AIX, Sun Solaris and HP-UX. The following enterprise grade databases are XA-compliant: IBM DB2 Universal Database V8.2 and Oracle 9i and 10g. Note that this is not a complete list of XA-compliant DBMS and it depends on your definition of enterprise grade.
Of interest to the Open Source and Java communities, MySQL 5.0 now has distributed transaction processing support through XA. Additionally, FirstSQL/J Enterprise Server has comprehensive support for connection pooling and Java Transaction APIs (JTA) for distributed transaction (that is, XA) capabilities.
Truth be told, XA is viewed as a luxury and not a "required" application tool for programmers within most organizations. However, infrastructure groups that don't support XA are essentially establishing an asymmetrical transaction failure risk curve that is skewed against the application programmer.
About the author
Frank Teti is a principal architect and industry analyst. He can be reached at firstname.lastname@example.org.
Other Related Articles by the Author