 by Thomas Erl |
WS-* Specifications |
 |
|
|
Cross-Service Transactions with WS-AtomicTransaction |
|
| 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. |
|
|
ACID transactions |
| 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 |
SOA: Principles of Service Design by Thomas Erl  An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation). 
Service-Oriented Architecture:Concepts, Technology, and Design by Thomas Erl The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design. 
Service-Oriented Architecture:A Field Guide to Integrating XML and Web Services by Thomas Erl The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices. For more information about either book, visit: www.soabooks.com |
About SOA Systems
SOA Systems Inc. provides strategic SOA consulting services and offers a comprehensive SOA training program. For more information see: • www.soasystems.com • www.soatraining.com |
| 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. |
|
<wsc:CoordinationType> http://schemas.xmlsoap.org/ws/2003/09/wsat </wsc:CoordinationType> |
|
To learn more about WS-AtomicTransaction, view the specification by visiting www.soaspecs.com
|
|
|
|
|
|
|
| Home | Copyright © 2003-2007 SOA Systems Inc. |