by Thomas Erl
Transactions have been around for almost as long as automated computer solutions have existed. When managing certain types of corporate data, the need to wrap a series of changes into a single action is fundamental to many business process requirements. Atomic transactions implement the familiar commit and rollback features to enable cross-service transaction support.
The protocols provided by the WS-AtomicTransaction specification enable cross-service transaction functionality comparable to the ACID-compliant transaction features found in most distributed application platforms.
For those of you who haven't yet worked with ACID transactions, let's quickly recap this important standard. The term "ACID" is an acronym representing the following four required
characteristics of a traditional transaction:
- Atomic - Either all of the changes within the scope of the transaction succeed, or none of them succeed. This characteristic introduces the need for the rollback feature that is responsible for restoring any changes completed as part of a failed transaction to their original state.
- Consistent - None of the data changes made as a result of the transaction can violate the validity of any associated data models. Any violations result in a rollback of the transaction.
- Isolated - If multiple transactions occur concurrently, they may not interfere with each other. Each transaction must be guaranteed an isolated execution environment.
- Durable - Upon the completion of a successful transaction, changes made as a result of the transaction can survive subsequent failures.
Atomic Transaction Protocols
WS-AtomicTransaction is a coordination type, meaning that it is an extension created for use with the WS-Coordination context management framework we covered in the previous section. To participate in an atomic transaction, a service first receives a coordination context from the activation service. It can subsequently register for available atomic transaction protocols.
The following primary transaction protocols are provided:
- A Completion protocol which is typically used to initiate the commit or abort states of the transaction.
- The Durable 2PC protocol for which services representing permanent data repositories should register.
- The Volatile 2PC protocol to be used by services managing non-persistent (temporary) data.
Most often these protocols are used to enable a two-phase commit (2PC) that manages an atomic transaction across multiple service participants.
The Atomic Transaction Coordinator
When WS-AtomicTransaction protocols are used, the coordinator controller service can be referred to as an atomic transaction coordinator. This particular implementation of the WS-Coordination coordinator service represents a specific service model. The atomic transaction coordinator plays a key role in managing the participants of the transaction process, and in deciding the transaction's ultimate outcome.
The Atomic Transaction Process
As previously mentioned, the atomic transaction coordinator is tasked with the responsibility of deciding the outcome of a transaction. It bases this decision on feedback it receives from all of the transaction participants.
As shown in the following diagrams, the collection of this feedback is separated into two phases. During the prepare phase, all participants are notified by the coordinator and each is asked to prepare and then issue a vote. Each participant's vote consists of either a "commit" or "abort" request.
In the following figure, the coordinator is requesting that transaction participants prepare to vote.
Nex, the transaction participants vote on the outcome of the atomic transaction.
Once the votes are collected, the atomic transaction coordinator enters the commit phase. It now reviews all votes and decides whether to commit or rollback the transaction.
The conditions of a commit decision are simple: if all votes are received and if all participants voted to commit, the coordinator declares the transaction successful, and the changes are committed. However, if any one vote requests an abort, or if any of the participants fail to respond, then the transaction is aborted and all changes are rolled back.
In the diagram above, the coordinator finally aborts the transaction and notifies participants to rollback all changes.
Implementing a WS-AtomicTransaction Coordination Type
The specific protocol(s) that establish the rules and constraints of a service activity within WS-Coordination are identified within the CoordinationType element. The URI values that are placed here are predefined within the WS-AtomicTransaction specification.
In the following example, the CoordinationType element is assigned the WS-AtomicTransaction coordination type identifier, which communicates the fact that the header's context information is part of a short running transaction.
- The WS-Coordination Context Management Framework
- Cross-Service Transactions with WS-AtomicTransaction
- Long-Running Transactions with WS-BusinessActivity
- An Overview of the WS-Security Framework
- Service-Oriented Business Processes with BPEL
- Building a Communications Framework with WS-Policy and WS-ReliableMessaging
- Defining the Web Service with WSDL
- An Inside Look into SOAP Messaging
- UDDI In and Out of the Enterprise
- A W3C Web Services Glossary
- Understanding WS-Policy Part I: Operator Composition Rules and Attachments
- Understanding WS-Policy Part II: Operator Composition Rules and Attachments
- Web Service Contract Versioning Fundamentals Part I: Version Identifiers and Versioning Strategies
- Web Service Contract Versioning Fundamentals Part II: Version Identifiers andVersioning Strategies
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
For more information about these books, visit: www.servicetechbooks.com