- Two-Phase Commit
- Transactions and Web Services
- Web Services Transaction Architectures
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Transactions and Web Services
Most service-based or business-to-business (B2B) applications would like to have the data consistency and correctness guarantees provided by existing transaction-processing platforms. Unfortunately, achieving these goals is difficult because interactions between the participants may be complex—involving multiple parties, spanning different organizations, and, most notably, lasting for hours or even days. For example, a transaction for a computer parts ordering application may involve different suppliers and may not be complete until all parts have been delivered. Should the various suppliers block part requests until this transaction is complete? Multiple reasons prevent such services from locking their back-end data resources for long durations: for example, the inability to service additional incoming requests, and the potential for enabling denial-of-service attacks.
Therefore, web service transaction implementations must provide a framework that essentially "loosens" the ACID properties associated with the standard two-phase commit protocol. In effect, a web service transaction should compose the various participants into one or more consensus groups such that all members of a given group have the same result. All of the services in a transaction may not necessarily belong to the same consensus group, and the business transaction can selectively commit a subset of services while other services are rolled back.
Consider a travel application that can book a flight, rent a car, and purchase travel insurance (see Figure 2). A user of this application initially books an airline ticket and reserves a rental car. Given that neither of these two actions should occur independently, the two services are assembled into one consensus group; if either of these services fails to execute, both participants will roll back. However, once the user proceeds to the travel insurance purchase, he may want to obtain multiple quotes. Each quote can be handled within its own consensus group, thus allowing the user to actually purchase a quoted policy in order to reserve the price—but subsequently cancel (roll back) the purchase if another travel insurance service provides a lower quote.
)
Figure
2 Service-based travel application.
But the consensus group construct solves only part of the problem. While consensus groups allow the web services transaction coordinator to identify a core set of services required for the successful completion of the transaction, they don't address the responsibilities of the services as transactional participants. Recall that in a standard transaction-processing system, the transaction coordinator interacts with resource managers, such as databases, to achieve a consensus. However, in the services domain the services are effectively acting as the resources (either directly or via a registered participant provided by a web services transactioning infrastructure implementation); ultimately, the services in some way respond to transaction-demarcation requests from the coordinator.
Thus, a service within a distributed business transaction may need to support provisional or tentative state changes during the course of a transaction. Rather than thinking in terms of "prepare" and "commit" phases, a service may actually support the completion of a business transaction by either "confirming" or "canceling" the work executed; when asked to cancel, or compensate, the service must undo the work it performed.
For example, in our travel application example, once the user has elected to purchase a travel insurance policy, the relevant service may actually commit the purchase information and record it in a back-end database; the back-end resource is not locked for any significant period of time and other quote requests can be fulfilled by the service. However, if in the course of the overall business transaction the user subsequently cancels the purchase, the service will have to perform a compensating action such as executing another transaction to remove the purchase data from the database. Clearly, the responsibilities of a transactional service are more significant and require more thought and planning than in a traditional, single-process application.
Now that we've established the unique aspects of long-running business activities, let's examine the architectural elements required to support web services transactions.