Section 11.2. Motivation for Transactions

11.2. Motivation for Transactions

11.2.1. Classic Transactions

Unfortunately, applications are prone to multiple modes of failure. When applications execute across distributed systems, they encounter greater reliability problems because such environments introduce additional sources of failure. Distributed systems generally consist of several computers connected by a network, where each system can be subject to independent failure of any of its components, such as the computers themselves, network links, operating systems, middleware, or individual applications. You must deal with failure of any component part of the application in the context of the whole application to ensure the overall correct execution of the application.

The concept of transactions is aimed at satisfying this consistency requirement through a property called atomicity, in which the application either completes normally, producing the intended results, or is aborted, restoring any resources that had been changed to their original values. The way this is done is typically an implementation choice, normally handled by a transaction service that an operating system or system middleware provides.

The application works in conjunction with system middleware that provides a transaction service to orchestrate the transaction outcome. Using the transaction service, the application indicates when the transaction begins and determines when and how it should end. The transaction service records the Web services accessed by the application so that it can perform the necessary outcome processing when the application ends.

A transaction can be completed in two ways: committed or aborted (cancelled). When a transaction is committed, all changes that are caused by operations of the business application are made durable (forced onto stable storage such as a disk). When a transaction is aborted, all changes that are made during the lifetime of the transaction are undone.

Most transaction systems in use today implement ACID transactions. They use a two-phase protocol to achieve atomicity between the Web services accessed by the application. The transaction service establishes roles, in which a coordinator acts on behalf of the application to orchestrate the outcome processing between the participant Web services (see Figure 11-2).

Figure 11-2. Transaction service roles.

• Phase 1: Preparation During the first phase of the atomic transaction protocol, the coordinator ballots the participants for a vote on the transaction outcome. All participants indicate their particular view of the transaction outcome by responding either positively or negatively to the ballot request.

• Phase 2: Outcome During the second phase of the atomic transaction protocol, the coordinator, having collected the preparation responses, informs the participants of the transaction outcome.

During the first phase, the coordinator sends the ballot request as a Prepare operation to the participants. The participants must make durable any state changes that occurred during the scope of the transaction. This allows the participants to either commit or abort (roll back) these changes later, after they've determined the overall transaction outcome (see Phase 1 of Figure 11-3).

Figure 11-3. Two-phase commit protocolsuccess.

Assuming that no failures occurred during the first phase, the coordinator sends the outcome as a second phase Commit operation to the participants. The participants can overwrite the original state of the Web service with the state made durable during the first phase (see Phase 2 of Figure 11-3).

However, if a failure occurs during the first phase (that there is any"no" vote to the ballot request (see Figure 11-4, Phase 1), the coordinator sends the outcome as a second phase Rollback operation to all the participants (see Figure 11-4, Phase 2). The participants abort the work performed during the transaction and return the state of the Web service to the original state that existed prior to the transaction.

Figure 11-4. Two-phase commit protocolfailure.

To guarantee consensus, two-phase commit is necessarily a blocking protocol. After returning the Phase 1 response, each participant who returns a Prepared response must remain blocked until it has received the coordinator's Phase 2 message. Until a participant receives this message, any resources that it uses will be unavailable for use by other transactions, because to do so might violate the Isolation property of ACID behavior. Such a "classic" ACID protocol is said to be a well-formed and two-phase protocol. That is well-formed if all its operations are covered by corresponding locks and two-phased if the lock protocol acquires and releases locks in separate locking and unlocking phases such that no unlock ever precedes a lock for any of the operations.

Figure 11-5 illustrates that all the Web services that the application uses remain blocked, and the results are unavailable until the transaction is completed. If the coordinator fails before delivery of the second phase message, these resources remain blocked until the transaction recovers.

Figure 11-5. Classic transaction.

11.2.2. Business Transactions

Most business applications (workflow, business to business collaboration) need to reach a mutually agreed upon outcome. However, certain characteristics of these applications preclude the straightforward application of classic ACID transaction protocols. These characteristics include the following:

• Long duration activity^[1]. Web services that a business application accesses might take longer to respond, and the overall application can remain active for an extended period of time (minutes, hours, days, weeks).

  ^[1] Definition: An activity is defined as a computational unit composed of a number of tasks carried out across one or more Web services.

• The ability of the application to apply business logic to handle failures and continue processing when something goes wrong with a particular Web service request.

• The capability to select which Web services are included in the overall transaction outcome.

• Applications that typically span cross-enterprise business domains within which Web service implementations generally might not allow an outside control to hold their resources.

Therefore, business transactions require a mechanism to track the Web services that the application accesses, determine which Web services are included in the transaction, and provide common outcome processing across such an environment.

It is difficult, if not impossible, to use only classic transaction architectures within such environments. Long-running applications that execute using just ACID transaction properties present some real problems. The duration of the application could mean that the level of concurrency offered by a classic transaction needs to be lowered significantly, depending on approaches taken to provide isolation (such as locking).

Failures are handled differently to avoid significant amounts of work being redone because ACID transactions will abort all work done rather than selectively. Some Web services might not be included within the overall outcome processing when a business application chooses to select among alternative results (such as selecting the lowest-cost provider from many solicited suppliers). Business process logic within typical business process management systems supports complex, long-running processes, where undoing the work of tasks that have already completed might be more appropriate to effect recovery. Alternatively, the business process can choose another acceptable execution path to continue forward processing. (As Figure 11-6 illustrates, the application decides the reservation only needs to include a flight and hotel operation and cancels the rental car.)

Figure 11-6. Business transaction.

In such scenarios, the properties of an ACID transaction have to be relaxed to provide what are typically referred to as extended transactions. An extended transaction model, for example, might relax the isolation property so that concurrent users can observe the intermediate updates of operations or in situations in which the holding of locks by operations against a service in an independent Web service is precluded (for example, to view a flight summary to check current seat availability). Figure 11-6 illustrates the Web services that the application uses, where the results of the flight, hotel, and rental car operations are made available before the transaction completes. As you shall see, protocols, such as WS-Business Activity, fall into this extended spectrum of transaction behavior, which provides a varying degree of functionality associated with each of the ACID transaction properties.

In certain classes of applications, it is known that resources acquired within a transaction can be released early, so you don't have to wait until the overall transaction finishes. If you adopt such a strategy, and if the overall transaction cancels, you might need to take certain actions to restore the system to a consistent state. Perhaps you'll need to perform compensation or countereffects on the resources that have been released early. Figure 11-6 illustrates this. Because the Web services are made available before the transaction is complete, cancellation of the rental car operation means you must perform compensation. Such recovery via compensation or fault-handling activities (which might perform forward or backward recovery) is typically application specific, might not be necessary at all, or might be more efficiently dealt with by the application. Therefore, an extended transaction model is usually more appropriate for lengthy interactions. For example, an airline reservation system might reserve a seat on a flight for an individual for a specific period of time. However, if the individual does not confirm the seat within that period, the system will reclaim it for another passenger.

Transactional support ensures that the appropriate outcome is observed across all of the tasks within the application that comprise the business activity. As indicated earlier, the results of a task might be made available before the overall business application or activity completes.

To understand business transactions more clearly, you can imagine the relatively simple scenario of arranging travel and accommodation for a conference (see Figure 11-7). Typically, an attendee requires transportation to the city where the conference is being held (via plane, train, or automobile), accommodation at a hotel (luxury, standard, or budget), and possibly other related bookings at the conference venue (a rental car or local transportation such as a shuttle, restaurant reservations, or tickets to entertainment events).

Figure 11-7. Travel arrangement scenario.

While assembling the booking, the travel agent needs to ensure that he can reserve likely options while processing the overall reservation. The business application must fulfill the travel agent's requirement to satisfy both the needs of the conference attendee and allowing Web services providers the autonomy to maintain control of its own resources (such as airlines, hotels, rental agencies, and restaurants).

The tasks that are required for the booking are interrelated within this business application, yet they are not necessarily predetermined. The tasks need to proceed independently, but all the resulting selections need to be booked together.

The travel agent offers a range of travel options that reflect a customer's preference or criteria based on such factors as cost, schedule, or availability. When the travel agent executes a task with a Web service provider, he might or might not include the task in the resulting reservation, dependent on the selection that the customer makes.

For example, the customer might either need to travel at specific times or might have more flexibility and want to consider the low-cost travel options. The travel agent would perform tasks soliciting reservations from various airlines. Based on schedule, cost, cancellation fees, and so on, the airline would perform a booking, and the customer would select a flight. The flight selected would be added to the tasks included when confirming the overall transaction. The remaining flights would be cancelled without affecting the overall reservation. In addition, selecting a particular option could affect other tasks; for example, a flight on a particular date might determine the customer's specific accommodation needs.