Sitemap Contribute Organization Index
SOA SpecsSemantic
Web Specs
Cloud SpecsBig Data Specs (Coming Soon)Web/REST SpecsWS-* SpecsComponent SpecsXML Specs

Cross-Service Transactions with WS-AtomicTransaction
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.


View Larger Image

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

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>

Articles and Tutorials

•  WS-* Specs
•  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 and
Versioning Strategies
Service Technology Magazine Issue LXXXIV
Service Technology Magazine
This issue features the following new articles:
"Big Data as a Service", by Varun Sharma; "SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Customer", by Leszek Jaskierny; "Cloud and Virtual Data Storage Networking: Data Footprint Reduction", by Greg Schulz; and "An SOA Maturity Ecosystem", by Hector Fabio Meza and Paul Escobar Mossos.
For more information:
www.servicetechmag.com

SOA Design Patterns by Thomas Erl
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.
Web Service Contract Design & Versioning for SOA by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley
SOA Principles of Service Design by Thomas Erl
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl
Service-Oriented Infrastructure:On-Premise and in the Cloud by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso
Next Generation SOA:A Real-World Guide to Modern Service-Oriented Computing by Pethuru Cheliah, Thomas Erl, Clive Gee, Robert Laird, Berthold Maier, Hajo Normann, Leo Shuster, Bernd Trops, Clemens Utschig, Torsten Winterberg
SOA with .NET & Windows Azure: Realizing Service-Orientation with the Microsoft Platform by David Chou, John deVadoss, Thomas Erl, Nitin Gandhi, Hanu Kommalapati, Brian Loesgen, Christoph Schittko, Herbjorn Wilhelmsen, Mickey Williams
SOA Governance:
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
SOA with Java by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Modern SOA Methodology: Methods for Applying Service-Orientation On-Premise & in the Cloud by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Cloud Computing: Concepts, Technology & Architecture by Thomas Erl, Zaigham Mahmood, Ricardo Puttini
Cloud Computing Design Patterns by Thomas Erl, Amin Naserpour

For more information about these books, visit: www.servicetechbooks.com


Arcitura Education Inc.
Arcitura Education Inc. is a leading global provider of progressive, vendor-neutral training and certification programs, providing industry-recognized certification programs for a range of certifications.
For more information:
www.arcitura.com
SOA Certified Professional (SOACP)
The books in this series are part of the official curriculum for the SOA Certified Professional program.
For more information:
www.soaschool.com
Cloud Certified Professional (CCP)
The books in this series are part of the official curriculum for the Cloud Certified Professional program.
For more information:
www.cloudschool.com
Big Data Science Certified Professional (BDSCP)
The books in this series are part of the official curriculum for the Big Data Science Certified Professional program.
For more information:
www.bigdatascienceschool.com/


The Prentice Hall Service Technology Series From Thomas Erl
   
Arcitura Education Inc.
www.arcitura.com
info@arcitura.com
+1-800-579-6582
1-604-904-4100

Copyright © Arcitura Education Inc. • Arcitura is a trademark of Arcitura Education Inc.