OASIS tackles Web services transactions

OASIS has formed a committee to ratify a family of Web services transactions standards, paving
the way for service-oriented architectures to do more actual business in the future.

The proposed standards are WS-Coordination, which creates the framework for a transaction,
and WS-AtomicTransaction (WS-AT) and WS-BusinessActivity (WS-BA), which enable short- and
long-duration transactions. The standards come to OASIS in fairly solid shape, with
interoperability tests already having been run on them.

Though the first meeting of the standards committee isn't until mid-November, proposed co-
chair Ian Robinson, a transaction architect for IBM's WebSphere Application Server, believes
WS-Coordination can be ratified within six months with the other two to follow six months
later.

"It is quite aggressive, but I think it's realistic," he said. "Based on our
experience with testing, we know these specifications can work. Our
expectation is that this will mostly involve refinement."

Fellow proposed co-chair, Eric Newcomer, chief technology officer at

Iona Technologies Inc., added that while the work may progress quickly,
Web services transactions are a tricky business.

"People do transactions over the Web all the time, but those tend to be
single database transactions," he said.

These standards will attempt to create the mechanism through which a more detailed and
complex business relationship can be executed. Newcomer envisions everything from multi-
phase supply chain transactions to distributed online shopping carts.

"I think everybody saw where it was going early on in the dot-com days, but it's taken a while to
get there," he said.

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.

It defines how a service gets activated and registered, after that the WS-AT and WS-BA will take
care of how the transaction gets processed.

WS-AT will handle short-duration transactions.

"It's designed to recognize the common denominators in two different transaction models and
provide you a context for extensibility," Robinson said. "It will allow proprietary systems to
interoperate with each other."

While breaking out of the proprietary transaction model may be a powerful idea, Robinson
touted WS-BA as the specification with the greatest long-term potential.

"It's designed to allow these new types of transactions we're trying to build with Web services,"
he said. "You could take two different BPEL [Business Process Execution Language] processes
and come to a joint consensual agreement between them."

Literally, it could facilitate SOA-to-SOA communication.

As with all other Web services standards, the transaction family will be designed to
interoperate with other specifications, such as those concerning security, addressing and
reliable messaging.

Chris Kurt, director of Web services standards for Microsoft, said layering and dependencies are
part and parcel of how businesses will customize the standards to fit their individual needs.

"Folks that are adopting Web services will be able to combine them in pretty much any
reasonable way," he said.

Transaction support from SOA platforms

What type of transaction support do current SOA platforms provide?

When it comes to transaction management, the key limitation in many Web services-based
implementations is performing cross-service transactions. As long as a service is at the root of a
transaction and the scope of the transaction is limited to activities that are performed by the service's
underlying solution logic, there is no need for cross-service transaction functionality, and the transaction
can be managed by whatever proprietary technology (component-based, legacy, or otherwise) it
encapsulates. However, as the amount of services in an environment grows, the need to span
transactions across those services increases. To address this requirement a set of WS-* specifications
were developed a while ago.

First, the WS-Coordination specification provides a context management mechanism implemented

through a set of stateful system services capable of logging information about and tracking the status of
an on-going activity performed by a set of services that have registered to participate within this activity.
Two supplementary specifications, WS-AtomicTransaction and WS-BusinessActivity, were developed to
work in conjunction with WS-Coordination by providing business protocols to its generic context
management features.

These protocols dictate the terms of the activity. WS-AtomicTransaction, for example, provides
protocols for ACID-type transactions with two-phase capability. WS-BusinessActivity provides protocols
for long-running transactions with compensation processes (as opposed to a rollback). Adoption of these
specifications has been slow and gradual. They are expected to become increasingly important in the
next 1-2 years. Microsoft's Indigo, for example, has already been promoted as supporting WS-
AtomicTransaction.

WSTx (Web Services Transactions)

WSTx (Web Services Transaction) is a set of XML markup specifications designed to permit the
use of open, standard protocols for secure, reliable transactions across the Web. Three
constituent standards were approved in April 2007:

 WS-Coordination
 WS-AtomicTransaction
 WS-BusinessActivity
The standards were created to accommodate two typical transaction patterns involving
multiple, distributed software components and services:

1. individual atomic transactions that represent the building blocks for more complex
transactions among peers and partners
2. Web-based interactions that result in the exchange of goods, information, or services,
usually called business activities.
WS-coordination refers to the mechanisms whereby atomic transactions may be composed into
complete business activities, and thus also provides the glue that ties the overall WSTx
environment together.

WSTx standards are overseen by a technical committee of the same name at OASIS (the
Organization for the Advancement of Structured Information Standards). The technical
committee is staffed with vendors and users of Web Services technologies. On its Web pages,
the committee describes its agenda as: "…to define a set of protocols to coordinate the
outcomes of distributed application actions." Vendors involved in the WSTx committee include
Adobe, BEA Systems, Fujitsu, Hitachi, IBM, Microsoft, Oracle, SAP and TIBCO, among numerous
others.

Handling Web services transactions

Executing individual pieces of software to perform as one unit of work is an area consistently
tackled by many software platforms and an issue that is central to many business processes.
The all encompassing term for this subject is named "transactions." In the upcoming
paragraphs, we will address many of the issues and approaches to working with transactions in
the context of Web services.

The importance of dealing appropriately with transactions in Web services arises from the same
cross-platform manner in which Web services operate. Since transactions offer an "all or
nothing" contract for executing a unit of work, bridging the disparities that might exist between
platform specific transaction mechanisms is a necessity in many SOAP-based applications.

Take the Java platform, while JTA (Java Transaction API) provides extensive support for dealing
with many transaction scenarios within Java applications, as soon as transaction integrity is
required outside the boundaries of any non-Java applications -- such as .NET or PHP --
transaction support generally entails ad-hoc techniques with very strict limitations.

Web services, being a technology used to bridge disparate platforms, has a series of
specifications designed to deal with the intricacies of transactions.

Developed by heavyweight industry players like IBM, BEA and Microsoft, Web services
transactions specifications are currently split into three major working groups: WS-
Coordination, WS-Atomic Transaction and WS-Business Activity.

WS-Coordination defines the underlying foundations for any transactional process taking place
between Web services. Used in conjunction with either WS-Atomic Transaction or WS-Business
Activity, WS-Coordination is used to define the mechanism by which Web services register and
coordinate themselves to take part in a transaction.

In transactional speak, what WS-Coordination achieves is setting up a context under which to

execute and manage the different units -- Web services -- that will take part in a transaction.
But while WS-Coordination forms the foundation for transactions, it leaves the transaction
protocol details to the two complementary specifications: WS-Atomic Transaction and WS-
Business Activity.

WS-Atomic Transaction is actually closely pegged to an existing and widely known protocol in
enterprise software: the two-phase commit protocol. While delving into details of this protocol
would go beyond the scope of Web services, the basics behind its operation consist of
synchronizing an all or nothing task between two resources in order to ensure a consistent
outcome.

Generally speaking, the use of a two-phase commit, and hence WS-Atomic Transaction, centers
around short-lived operations, or in other words, processes were the success or failure of a
transaction is needed to be known rapidly.

WS-Business Activity on the other hand is designed with longer running transactions in mind.
The other major difference being the robustness with which it can handle transactional
scenarios when compared to WS-Atomic Transaction.
While WS-Atomic Transaction provides an all or nothing solution to transactions -- either
success or failure -- WS-Business Activity has provisions for such things as exception handling
with the capacity to execute compensatory tasks.

Now that we have covered the conceptual part of Web services transactions, you may be asking
yourself how to put transactions together in real world Web services applications. For this, like
any other specification, you need an implementation and one such project isKandula , produced
by the Apache Software Foundation.

Being an Apache project, the transactional facilities in Kandula are closely pegged to Axis, which
is the de-facto Web services platform developed by Apache. Since this last project is focused on
Java, the WS-* transaction support in Kandula plays into Java transactional facilities.

The simplest manner to exemplify the use of Kandula is observing a code snippet, listing 1.1
illustrates what a Web services class using Kandula WS-Atomic Transaction would look like.

Listing 1.1 WS-Atomic Transaction usage in Java using Kandula

import org.apache.kandula.coordinator.at.TransactionManagerImpl;

public class Fullfilment {

public void order(int orderId) {

// More Business Logic

Inventory inventory = new Inventory().getInventory();
TransactionManagerImpl tm = TransactionManagerImpl.getInstance();
tm.begin();
try {
inventory.ship(orderId);
inventory.deduct(orderId);
}catch (Exception e)
{
tm.rollback();
}
tm.commit();
// More Business Logic
}
}
Although the code is Java specific, notice that the calls nested within the try/catch block are
making a call to the Inventory class, which in itself is nested between the begin and commit
methods of the Kandula TransactionManager. You might also notice the in case an error occurs,
a call to the rollback method in the same TransactionManager class is invoked.
Now, as far as the actual methods calls in the Inventory class -- ship() and deduct() -- which
form the transaction, even though they form part of the Inventory Java class it is assumed they
are in themselves part of a stub class generated from a WSDL contract which is communicating
to a remote Web service written in Java or any other Web services supported platform.

By nesting in this manner, Kandula via Axis is propagating transactional information to the
Inventory class that is later wrapped in the corresponding SOAP payload for later consumption
and coordination by the service end points.

While transactions are often an afterthought for many software projects, when the need arises
to manage them explicitly they provide a critical role in fulfilling a software's business functions.
The specifications we just covered provide this pivotal role in the still emerging world of
service-oriented architecture.

WS-I Organization (Web Services Interoperability)

The WS-I (Web Services Interoperability) Organization is an association of IT industry
companies, including IBM and Microsoft, that aim to create Web services specifications that all
companies can use. As of August 15, 2002, these specifications included:

 The Business Process Execution Language (BPEL)

 WS-Coordination
 WS-Transaction
 WS-Security
The WS set of specifications agreed upon by the WS-I Organization members are expected at
some point to be proposed to one or more standards groups for official ratification. Current
Web services standards (or de facto standards) include the Simple Object Access Protocol
(SOAP), which provides a common industry mechanism for transmitting a request to a Web
service and returning a response; Universal Description, Discovery and Integration (UDDI),
which allows a company to publicize its services to other companies and Web users; and Web
Services Description Language (WSDL, which enables a business to formally describe what its
service does.

WS-AtomicTransaction (WS-AT)
WS-AtomicTransaction (WS-AT) is a protocol for managing atomic transactions between
distributed applications, transaction managers and resource managers. An atomic transaction is
a single, irreducible component of a classic transaction, such as making a purchase. WS-AT
ensures that if a single atomic transaction fails, the whole transaction fails: A partial transaction
cannot take place. For example, if a customer is transfering funds from one account to another,
WS-AT makes it impossible for funds to be removed from one account successfully but not
deposited into the target account.

There are multiple atomic transactions within most classical transactions. For example, when a
consumer makes a retail purchase using a credit card, several steps are involved: ringing up the
sale, swiping the card through a reader, verifying the validity of the account associated with the
card, ensuring that the account has sufficient available credit and producing a receipt. Each of
these components is an atomic transaction. In combination, they constitute a classical
transaction.

WS-AT defines how transactions are carried out based on WS-Coordination and WS-

Transaction, companion specifications for information exchange in business processes. There
are three agreement protocols involved: completion, volatile two-phase commit (2PC), and
durable 2PC. The completion protocol initiates the process that can ultimately lead to 2PC.
Volatile 2PC applies to resources subject to frequent change, such as data stored
inRAM (random-access memory). Durable 2PC applies to more permanent resources such
asdatabases that may be stored on a hard disk or other non-volatile media. The ultimate result
of an atomic transaction is either a "commit" (successful completion) or an "abort" (failure to
complete).

The WS-AtomicTransaction specification is an activity of the Web Service Interoperability

Organization (WS-I Organization), an industry-wide effort devoted to standardizing the ways in
which Web services are requested and delivered.

Is there a framework that will support the WS-AtomicTransaction spec?

We are publishing certain interfaces through Web services. The Web service performs one unit
of work. There are scenarios where the client can have this Web service participating in a
transaction originating in the client. The problem is this: The clients are able to rollback or
execute updates via other non Web service components, but they are not able to do so with
those done via the Web service. The Web service and the client are all implemented in .NET. I
have read the WS-AtomicTransaction specification but have struggled to find a framework
which supports it.
Have you faced such a problem and if so, can you please share your experience and
recommend a framework that will support this specification?

What you are looking for is Indigo, the next generation of .NET. Indigo will provide a service-
oriented programming model that encapsulates the process of promoting transactions from
lightweight transactions that do not require the Distributed Transaction Coordinator (DTC), to
DTC-enabled transactions that support cross process and distributed .NET components, to Web
service transactions that require WS-AtomicTransaction. All of this will be done through a
similar declarative (implicit) programming model as is done today with EnterpriseServices
in .NET 1.1. An explicit programming model will also be available for greater control. Today,
in .NET 2.0, a transitional set of functionality is already available. The Lightweight Transaction
Manager (LTM) will automatically promote to DTC transactions when more than one Resource
Manager is participates in a transaction, for example.

For more information on 2.0 transactions with a 1.x backgrounder, read my colleague Juval
Lowy's white paper.

So, what can you do today? Sigh. Roll your own I'm afraid. In my opinion you are in for a long
road if you try to implement your own plumbing for the WS-Coordination (WS-COOR) and WS-
AtomicTransaction (WS-AT) protocol. You're better off waiting, and taking the plumbing for
free. Mind you the specifications for WS-Coordination and WS-AtomicTransactions although far
along, are not yet ratified. By the time platform support is available on the .NET and Java side
they should be. They will handle all of the state management and XML serialization
requirements for incorporating a service operation into a transaction, and you can work as you
do today, applying declarative transaction attributes to the operation.

I should also mention that on the Java side, there are a few vendor platforms that include
implementations for WS-COOR and WS-AT, they are:

- IBM WebSphere offer WS-AT for WAS

- Choreology offers a Business Transaction Management (BTM) product called Cohesions

These won't help you with your .NET services obviously, but it is at least interesting that there
are vendors out there that have begun to support these standards even in their interim state.

WS-Policy (Web Services Policy Framework specifications)

WS-Policy is an abbreviation for the Web Services Policy Framework specifications, members of
the core Web Services architecture specifications. Web Services Policy Framework
specifications are currently published by IBM, but also include BEA Systems, Microsoft, SAP AG,
Sonic Software, and Versign as other named contributors.

WS-Policy defines a general-purpose XML-based model and syntax that may be used to

describe and communicate the policies that inhere to any Web-based service. In other words,
WS-Policy assertions express the capabilities and constraints that apply to some particular Web
service to which they pertain.

More specifically, WS-Policy delivers a flexible, extensible grammar for assertions regarding the
capabilities, requirements, and general characteristics in a specific XML Web services based
system. WS-Policy allows such properties to be stated as policies, which may be simple
declarative assertions but may also be more complex conditional declarations. In this context, a
policy consists of one or more policy assertions and may include such things as authentication
schemes, transport protocol selection, privacy policy, QoS characteristics, and more.

The WS-Policy Story

As the concept of XML-based "Web services" has grown from the simple days of XML-RPC
things have gotten a lot more complicated. The pioneering developers communicated service
requirements in text documentation, sample code and user mailing lists. Then came SOAP and
more formal documentation such as WSDL and UDDI. Now the list of formal specifications
related to Web services and generated by a variety of organizations is astonishingly long. Here
are some of the most significant:

Name Lead Function.

Organization

SOAP W3C Defines the XML message format for Web services.

WSDL W3C XML format description of a Web service suitable for

automatically generating client code.

UDDI OASIS Provides a method for publishing the access information for a
Web service.

WS-Security OASIS Sign, verify and encrypt SOAP messages.

WS- W3C Defines transport-neutral mechanisms to address Web services.

Addressing

As Web services have gotten more complicated, communication between potential client and
service has become more difficult and early attempts such as WSDL have not always been up to
the task of completely defining the requirements. Typically developers fall back on text
documentation, discussions on user mailing lists or calling a more knowledgeable person to
resolve a problem.

What is WS-Policy?
The Web Services Policy Framework (or WS-Policy for short) is intended to provide a basic
general purpose model and XML syntax for describing policies related to a Web service. Policies
can be defined, not only for a given Web service, but also by potential clients of the service. For
example, your company might require that developers only access Web services using digital
signatures. WS-Policy functions as an addition to WSDL, UDDI and other WS-* specifications.

A WS-Policy document expresses rules that may be as simple as a requirement to use WS-
Addressing in SOAP headers or as complex as giving a list of "assertions" about alternate
message signing algorithms which the service can recognize. Essentially, WS-Policy attempts to
formalize in both machine- and human-readable form aspects of Web service communication
that might otherwise require extensive text documentation or direct person to person
communication. The examples given by the WS-Policy working group show how to express
complex security requirements.

The WS-Policy specification has undergone a series of drafts and is now at the "Last Call
Working Draft" stage, but does not yet have official W3C status. You can get a copy of the
current working draft documentation from the Web Services Policy Working Group URL given in
the resources.

Creators of WS-Policy

The list of participants working on WS-Policy shows that a wide spectrum of industry
heavyweights have been contributing to the process of refining the framework. As part of the
W3C's recent emphasis on software patent policy, these companies have made licensing
commitments to ensure that when WS-Policy reaches Recommendation stage it will be royalty
free.

Web Services Policy Attachment

The basic WS-Policy specification does not state how a given policy document gets associated
with a specific Web service. That function is being covered in a separate WS-PolicyAttachement
specification that defines mechanisms by which a policy gets associated with a Web service
entity and with WSDL or UDDI descriptions.

Implementations

Microsoft provides the Web Services Enhancements add-on for Visual Studio.NET which
supports WS-Policy and many other of the latest Web services related specifications.

The Apache "Commons" open source project contains a set of Java classes for reading and
manipulating WS-Policy documents. This toolkit is part of the new Apache Axis2 Web services
toolkit, but not part of Sun's Java Web Services Developer Package. The Apache API includes the
rather elegant capability of automatically combining a WS-Policy document for a service with
potential client policy alternatives to reveal the policy or policies where there is mutual
agreement.

Conclusion

For me the question is - will WS-policy prove to be the solution to the obvious problem of
helping developers coordinate all of the various specifications related to Web services or will it
join the ranks of elegant specifications that everybody admires but few people use? Check back
again in a year, maybe we will know by then.

Web services, Java and XA for distributed transactions

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.)
WS-TX implementations

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 JTAtransaction to
which the WS-AT transaction is federated.

Implications

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.

Using Web services as distributed transactions and the role of XA

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.
Implications

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.