WebServices dot org

The Smorgasbord of Web Services Transactions

The effects of such changes have been felt most strongly in business environments, fuelling the mindset for a transition from traditional atomic transactions to extended transaction models better suited for Internet interoperation.

Most business-to-business applications require transactional support in order to guarantee consistent outcome and correct execution. These applications often involve long running computations, loosely coupled systems and components that do not share data, location, or administration and it is thus difficult to incorporate traditional ACID transactions within such architectures.

The first real attempt at this was the OASIS Business Transaction Protocol in 2001 [1] ; this was then followed by the Web Services Atomic Transaction [2] and Web Services Business Activity [3] specifications from IBM, Microsoft and BEA in August 2002, and more recently by the Web Services Transaction Management specification [4] from Sun, Oracle and others in August 2003. In this paper we’ll give an overview of these specifications and show the commonality that does exist between them all.

Why ACID transactions are too strong

Atomic transactions are a well-known technique for guaranteeing consistency in the presence of failures [5] . The ACIDproperties of atomic transactions (Atomicity, Consistency, Isolation, Durability) ensure that even in complex business applications consistency of state is preserved, despite concurrent accesses and failures. This is an extremely useful fault-tolerance technique, especially when multiple, possibly remote, resources are involved.

The structuring mechanisms available within traditional atomic transaction systems are sequential and concurrent composition of transactions. These mechanisms are sufficient if an application function can be represented as a single atomic transaction. Transactions are most suitably viewed as “short-lived” entities executing in a closely-coupled environment, performing stable state changes to the system; they are less well suited for structuring “long-lived” application functions (e.g., running for hours, days, …). Long-lived atomic transactions (as typically occur in business-to-business interactions) may reduce the concurrency in the system to an unacceptable level by holding on to resources (e.g., locks) for a long time; further, if such an atomic transaction rolls back, much valuable work already performed could be undone.

It has long been realised that ACIDtransactions by themselves are not adequate for structuring long-lived applications. To ensure ACID-ity between multiple participants, a multi-phase (typically two) consensus mechanism is required, as illustrated in Figure 1: during the first (preparation) phase, an individual participant must make durable any state changes that occurred during the scope of the atomic transaction, such that these changes can either be rolled back (undone) or committed later once consensus to the transaction outcome has been determined amongst all participants, i.e., any original state must not be lost at this point as the atomic transaction could still roll back. Assuming no failures occurred during the first phase (in which case all participants will be forced to undo their changes), in the second (commitment) phase participants may “overwrite” the original state with the state made durable during the first phase.

Figure 1: Two-phase commit protocol.

In order to guarantee consensus, two-phase commit is necessarily a blocking protocol: after returning the phase 1 response, each participant which returned a commit response must remain blocked until it has received the coordinator’s phase 2 message telling it what to do. Until they receive this message, any resources used by the participant are unavailable for use by other atomic transactions, since to do so may result in non-ACID behaviour. If the coordinator fails before delivery of the second phase message these resources remain blocked until it recovers.

Therefore, structuring certain activities from long-running atomic transactions can reduce the amount of concurrency within an application or (in the event of failures) require work to be performed again. For example, there are certain classes of application where it is known that resources acquired within an atomic transaction can be released “early”, rather than having to wait until the atomic transaction terminates; in the event of the atomic transaction rolling back, however, certain compensation activities may be necessary to restore the system to a consistent state. Such compensation activities (which may perform forward or backward recovery) will typically be application specific, may not be necessary at all, or may be more efficiently dealt with by the application.

The three approaches

OASIS BTP

To ensure atomicity between multiple participants, BTP uses a two-phase completion protocol: during the first phase (prepare), an individual participant must make durable any state changes that occurred within the scope of the transaction, such that those changes can either be undone (cancelled) or made durable (confirmed) later once consensus has been achieved. Although BTP uses a two-phase protocol, it does not imply ACID semantics. How implementations of prepare, confirm and cancel are provided is a back-end implementation decision. Issues to do with consistency and isolation of data are also back-end choices and not imposed or assumed by BTP.

Because the traditional two-phase algorithm does not impose any restrictions on the time between executing the first and second phases, BTP took the approach of using this to allow business-logic decisions to be inserted between the phases. What this means is a user has to drive the two phases explicitly in what BTP terms an open-top completion protocol. The application has complete control over when transactions prepare, and using use whatever business logic is required later determine which transactions to confirm or cancel. Prepare becomes part of the service business logic, for example.

BTP introduced two types of extended transactions, both using the open-top completion protocol:

• Atom: an atom is the typical way in which “transactional” work performed on Web services is scoped. The outcome of an atom is guaranteed to be consistent, such that, all enlisted participants will see the same outcome, which will either be to accept (confirm) the work or reject (cancel) it;

• Cohesion: this type of transaction was introduced in order to relax atomicity and allow for the selection of work to be confirmed or cancelled based on higher level business rules. Atoms are the typical participants within a cohesion but, unlike an atom, a cohesion may give different outcomes to its participants such that some of them may confirm whilst the remainder cancel. In essence, the two-phase protocol for a cohesion is parameterized to allow a user to specify precisely which participants to prepare and which to cancel. Cohesions are meant to model long-running business activities, where services enroll in atoms (which are enrolled in the cohesion) that represent specific units of work and as the business activity progresses, it may encounter conditions that allow it to cancel or prepare these units, with the caveat that it may be many hours or days before the cohesion arrives at its confirm-set: the set of participants that it requires to confirm in order for it to successfully terminate the business activity. Once the confirm-set has been determined, the cohesion collapses down to being an atom: all members of the confirm-set see the same outcome.

In fact BTP really only has a single transaction model, since the atom model is a subset of the cohesion model, but where prepare, confirm and cancel parameterization isn’t used (e.g., an atom prepares all participants). What this means is that the single BTP model must be suitably generic enough to support a wide variety of applications.

WS-Atomic Transaction and WS-Business Activity

An atomic transaction (AT)model is similar to traditional ACID transactions and intended to support short-duration interactions where ACID semantics are appropriate. Within the scope of an AT, services typically enroll transaction-aware resources, such as databases and message queues, as participants under the control of the transaction. When the transaction terminates, the outcome decision of the AT is then propagated to each enlisted resource via the participant and the appropriate commit or rollback actions are taken by each.

As well as the two-phase commit protocol, WS-Atomic Transaction supports a synchronization protocol, provided by most traditional ACID transaction specifications and implementations. If you recall the original ACID properties, then you’ll remember that Durability is important. What this means is that applications interact with a persistence store of some kind (e.g., a database) and this can impose a significant overhead. One obvious solution to this problem would be to cache the state in memory and only operate on that for the duration of a transaction. You would then need some way of flushing the state back to the persistent store before the transaction terminates. This is what the synchronization protocol does.

Now at this stage you might be wondering why there is a WS-Atomic Transaction model if ACID transactions are too restrictive for Web Services. Although ACID transactions may not be suitable for all Web Services, they are most definitely suitable for some, and particularly high-value interactions such as those involved in finance. Web services are for interoperability in closely coupled environments such as corporate intranets as much as they are for the Web. Interoperability between existing heterogeneous transaction service implementations is a requirement and yet has been difficult to achieve in practice.

A business activity (BA) is designed specifically for long-duration interactions, where exclusively locking resources is impossible or impractical. In this model services are requested to do work, and where those services have the ability to undo any work, they inform the BA such that if the BA later decides to cancel the work, it can instruct the service to execute its undo behavior.

While the full ACID semantics are not maintained by a BA, consistency can still be maintained through compensation, though the task of writing correct compensating actions (and thus overall system consistency) is delegated to the developers of the services under control of the BA. Such compensations may use backward error recovery, but will typically employ forward recovery.

WS-Transaction Management

WS-TXM provides models that are designed to accommodate multiple use-cases, from tightly-coupled intranet-based transactions (TX-ACID), through to Internet-scale long lived transactions (TX-LRA), to business-process oriented transactions (TX-BP).

TX-ACID

As with the WS-Atomic Transaction specification, this model is designed to support interoperability of existing transaction processing systems via Web Services, given such systems already form the backbone of enterprise class applications. As a result, the ACID transaction model defined in WS-TXM has been designed with interoperability in mind.

TX-LRA

The long running action model (LRA) is designed specifically for those business interactions that occur over a long duration. Within this model, an activity reflects business interactions: all work performed within the scope of an application is required to be compensatable. Therefore, an application’s work is either performed successfully or undone. How individual Web services perform their work and ensure it can be undone if compensation is required, are implementation choices and not exposed to the LRA model. The LRA model simply defines the triggers for compensation actions and the conditions under which those triggers are executed.

TX-BP

In the business process transaction model (BP model) all parties involved in a business process reside within business domains, which may themselves use business processes to perform work. Business process transactions are responsible for managing interactions between these domains. A business process (business-to-business interaction) is split into business tasks and each task executes within a specific business domain. A business domain may itself be subdivided into other business domains (business processes) in a recursive manner.

Each domain may represent a different transaction model if such a federation of models is more appropriate to the activity. Each business task (which may be modelled as a scope) may provide implementation specific counter-effects in the event that the enclosing scope must cancel. In addition, periodically the controlling application may request that the entire business domains checkpoint their state such that they can either be consistently rolled back to that checkpoint by the application or restarted from the checkpoint in the event of a failure.

An individual task may require multiple services to work. Each task is assumed to be a compensatable unit of work. However, as with the LRA model described earlier, how compensation is provided is an implementation choice for the task.

Choices galore

Three years ago the world of Web services and transactions looked like a new frontier, requiring new techniques to address the problems that it presented. Although BTP was the first, it did not attract the backing of Web services heavyweights. Much more effort and publicity has gone into the latter two specifications, which although having marked differences, also share important commonality in terms of the types of extended transaction models that are being offered to Web service developers:

• ACID: Web services are for interoperability in closely coupled environments such as corporate intranets as much as they are for the Web. Interoperability between existing heterogeneous transaction service implementations is a requirement and yet has been difficult to achieve in practice. This transaction model is designed to support interoperability of existing transaction processing systems via Web services.

• Forward compensation based: this model is designed for those business interactions that are long in duration, where traditional ACID transactions are inappropriate. With this model, all work performed within the scope of an application can be compensated through some other activity (work). How a Web service performs its work and ensures that it can be undone if compensation is required, is an implementation choice. The model simply defines the triggers for compensation actions and the conditions under which those triggers are executed.

It is important to realise that BTP can support both of these models either within the baseline specification or through extensions.

So which specification should you use, whether you’re implementing or looking to leverage an existing implementation? As is often the case in Web Services, the political landscape is often as important as the technical. The reality is that although BTP can be a powerful and expressive model, it is seen by the majority of the industry and analysts as being overly complex for what it sets out to achieve. As such, unless you are looking to use these extended transaction models in non-Web Services environments, it’s probably not worth investing the time and effort here. It has certainly influenced those specifications that came afterwards, however.

That leaves us with OASIS WS-Transaction Management or WS-Atomic Transaction/WS-Business Activity, both of which are backed by transactional heavyweight companies and intended to fit in which existing infrastructure investments. As we’ve seen, there are similarities between these various specifications at a number of levels and there are technical pros and cons on both sides, but nothing so dramatic as to shift the balance of choice one way or another. In fact, one of the intentions of the OASIS WS-TXM work is that it should be possible to mix-and-match with the other specifications.

However, the major difference between these specifications is that of openness and controllability. WS-TXM is being developed within a recognized standards-setting organization to ensure that all vendors and users can help influence its direction. For customers, the promises of open standards are predictability, interoperability and reduced costs. In this context “open” means specifications that are reliable, free from the threat of legal encumbrances (truly royalty-free licensing terms), able to work across development and deployment environments, subject to peer review and input throughout most of their lifecycle, and aligned with general industry and customer needs.

At present the IBM, Microsoft and BEA specifications are being developed within a closed arena. However, we hope that in the future this will change and because both of these specifications are relatively close technically if the political will is available then a merging of both works should be possible. It would certainly be in the interests of the user community for this to happen.

References

[1] BTP Committee specification, http://www.oasis-open.org/committees/business-transactions/ , April 2002.

[2] The Web Services Atomic Transaction specification, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsat.asp

[3] The Web Services Business Activity specification, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsba.asp

[4] The Web Services Composite Application Framework Technical Committee, http://www.oasis-open.org/committees/documents.php?wg_abbrev=ws-caf

[5] Gray, Jim and Andreas Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufman, 1993.