Atomic transactions
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 (Figure 6.20).
Figure 6.20. Atomic transactions apply an all-or-nothing requirement to work performed as part of an activity.
Note
The concepts discussed in this section were derived from the WS-AtomicTransaction specification, which defines protocols for use with WS-Coordination. (For a simple example of how the WS-AtomicTransaction coordination type is referenced as part of a SOAP header, see the WS-Coordination overview section in Chapter 16.)
6.4.1. 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.
6.4.2. 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.
6.4.3. 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 (Figure 6.21) plays a key role in managing the participants of the transaction process and in deciding the transaction's ultimate outcome.
Figure 6.21. The atomic transaction coordinator service model.
6.4.4. 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.
The collection of this feedback is separated into two phases. During the prepare phase (Figure 6.22), 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 (Figure 6.23).
Figure 6.22. The coordinator requesting that transaction participants prepare to vote.
Figure 6.23. The transaction participants voting on the outcome of the atomic transaction.
After 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 (Figure 6.24).
Figure 6.24. The coordinator aborting the transaction and notifying participants to rollback all changes.
6.4.5. Atomic transactions and SOA
Much of the transactional functionality implemented in service-oriented solutions is done so among the components that execute an activity on behalf of a single service. However, as more services emerge within an organization and as service compositions become more commonplace, the need to move transaction boundaries into cross-service interaction scenarios increases. Being able to guarantee an outcome of an activity is a key part of enterprise-level computing, and atomic transactions therefore play an important role in ensuring quality of service.
Not only do atomic transactional capabilities lead to a robust execution environment for SOA activities, they promote interoperability when extended into integrated environments. This allows the scope of an activity to span different solutions built with different vendor platforms, while still being assured a guaranteed all-or-nothing outcome. Assuming, of course, that WS-AtomicTransaction is supported by the affected applications, this option broadens the application of the two-phase commit protocol beyond traditional application boundaries (thus, supporting service interoperability). Figure 6.25 illustrates how atomic transactions support these aspects of SOA.
Figure 6.25. Atomic transaction relating to other parts of SOA.
Case Study
Continuing with our previous case study example, a look under the hood reveals that TLS actually wraps Steps 3 and 4 into an atomic transaction. This guarantees that should any one update fail by any of the services involved in this composition, all previous updates performed (as of Step 3) will be rolled back (Figure 6.26). Figure 6.26. All changes made by the TLS Accounts Payable, Vendor Profile, and Ledger Services are under the control of an atomic transaction. To accomplish this, TLS relies on WS-Coordination, as implemented by the WS-AtomicTransaction coordination type. It utilizes the context coordinator along with the Complete transaction protocol to incorporate ACID-type transaction features into this complex activity. |
SUMMARY OF KEY POINTS |
---|
|