Posted: Sep. 23, 2002

WS-Transaction is a newly released specification, developed by Microsoft, IBM, and BEA, that defines how Web services coordinate their activities in order to ensure the integrity of underlying database operations. WS-Transaction defines two models for transactions over Web services: atomic transactions for those cases where the highest level of protection is required; and business activity transactions in which using a lower level of protection offers better scalability.

Atomic Transactions Offer Strongest Protection

WS-Transaction supports atomic (all-or-nothing) transactions in which a coordinator queries each participant in the transaction to find out if they are capable of processing the update. Each participant typically locks any database records involved in the transaction to prevent any changes from being made to the data while the transaction is being processed. Only when all participants have indicated a readiness to commit does the coordinator instruct them to make the changes. If any participant either vetoes the transaction or fails to respond, the coordinator instructs all participants to abort the transaction and discard any changes. This process is typically known as "two-phase commit" (or 2PC) and is widely used in products such as Microsoft’s Distributed Transaction Coordinator (DTC) and IBM’s CICS.

WS-Transaction defines how Web services register their intent to use two-phase commit and how they communicate status information (such as decisions to veto the transaction) with other services.

Although two-phase commit is a widely used technique for internal corporate applications, the drawback of this approach is that each database involved in the transaction must hold some kind of lock on records for the duration of the transaction, thereby making those records unavailable to other clients. While the duration of a transaction on an internal network is likely to be relatively small, the highly distributed nature of the Internet makes holding locks on the Web, and therefore in Web services that span organizational boundaries, problematic. A manufacturer, for example, might not trust a distributor enough to lock its inventory database for days while the distributor processes an order. It also would not want transient network failures to force all pending transactions to roll back and be resubmitted.

Business Activity Supports Long-Lived Transactions

In order to address the need to support transactions, without requiring locks on all database records, WS-Transaction defines an alternate model, known as Business Activities. Business Activities are designed for long-lived transactions where longer time durations and a lower level of trust between participants make atomic transactions inappropriate.

The key concept behind business activities is compensation. Rather than requiring each participant in the transaction to lock data and hold off on committing changes until all participants approve, compensation assumes that all updates will succeed and commits the changes immediately, but prepares a way to undo the changes and therefore compensate for the failure of any component. Using the example of a bank transfer, a business activity that requires withdrawing money from a bank account can prepare a compensating update (in this case, a credit to compensate for the debit) should another component of the transaction fail.

WS-Transaction supports loosely coupled business activity transactions, in addition to the stronger, atomic transactions, by defining how one Web service can request another service to compensate for (or undo) its previous changes. When any participant indicates a failure, the Web service that initiated the entire process requests other participants to compensate.

Business activities, however, are not without limitations. Because the changes are committed immediately, business activity transactions do make intermediate results visible to other database clients while atomic transactions offer a higher level of isolation between running transactions. Using the same example of a bank account, during the period of time between when a debit is processed and a corresponding compensation is processed, other applications that query the account balance would retrieve an incorrect result.