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.)

In Plain English

While we were washing my car, a neighbor stops by and offers us some money to wash his car. Having nothing else planned for the afternoon, we oblige and apply the same car washing process to the neighbor's car.

In the following weeks, word of our car washing abilities gets around, and others from the neighborhood start requesting our services. We soon find ourselves washing four or five cars every weekend.

We then come across a car with a special metallic finish. Not knowing any better, we proceed to apply our standard car washing process. When the car dries, though, we notice spots of discoloration throughout its exterior. A subsequent investigation leads us to find out that the soap we've been using is not suitable for some finishes (including metallic paint).

This turns into an expensive lesson, as we subsequently fund a new paint job. To prevent this from happening again, we decide to take measures. We proceed to purchase some specialized soaps for use in our water. The choice of soap is dependent on the finish of the car we are washing.

Sometimes the use of these new soaps requires us to carefully mix two or more cleaning solutions together. We determine a correct mixture by assessing the resulting color of the water. However, because we tend to eyeball this process, it can sometimes go wrong. We agree that if the correct color is not attained, we empty the contents of the bucket and start again.

This change to our process affects the following two steps:

4.	Fill bucket with warm water.
5.	Add soap to water.

Originally, these steps were simply performed in sequence as a continuation of the overall process. Now we have a requirement that dictates that should the resulting soap mixture be unacceptable, the bucket needs to be reset to its original state (empty). This requirement emulates an atomic transaction, where at the completion of Step 5, the process is either rolled back to the beginning of Step 4, or the quality of water is accepted (committed) so that it can be applied to washing the car.

 

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

• WS-AtomicTransaction is a coordination type that supplies three coordination protocols that can be used to achieve two-phase commit transactions across multiple service participants.
• The atomic transaction coordinator makes the ultimate decision to commit or rollback a transaction. This decision is based on votes collected from participants.
• Contemporary SOAs can incorporate cross-service, ACID-type transaction features by using WS-AtomicTransaction.