Scaling Transactions to Web Services

ACID transactions in their centralized or distributed variations are especially suited to the bank account credit-debit type of problem, and offer the kinds of guarantees on which truly dependable back-end computing systems can be built. There is, however, a practical limitation to how far ACID transactions can be applied to the Web services world, even with advanced mechanisms like nesting and interposition.

To preserve the ACID properties, locks must be maintained on data throughout the duration of a transaction. While maintaining locks for the duration of a transaction is a reasonable thing to do within your own organization, it becomes less so when third parties are given access to your systems through Web services. The last thing that we would want to happen is for a mischievous party to run and never terminate a transaction. This would hold locks on data for extended periods, with the upshot that the holding of such locks would prevent actual business from being conducted through a denial of service attack.

It would seem, therefore, that we have a paradox. We need Web services to be able to conduct business from an interoperation point of view, but we need transactions if we are going to conduct business of any real value. If we decide to apply ACID transactions directly to the Web, then this paradox becomes a reality and our systems will grind to a halt. If, however, we take the general concepts of prior transaction models and re-cast them into a Web services-friendly model, then it is possible to overcome that paradox, albeit at the cost of relaxing the ACID properties. The underlying assumptions about the environment in which the two-phase algorithm is executed remain the same for Web service transactions as they do for regular distributed transactions. We must assume that work finishes before the transaction can terminate, there are no Byzantine failures, and so forth. Without such assumptions the two-phase model could not safely be applied to Web services transactions, just as it could not safely be applied to regular distributed transactions. Thus we can re-cast the original ACID properties to be more suitable for Web services as follows:

• Atomic This aspect is not relaxed in the Web services model, since its exclusion would reduce the value of using transactions at all.

• Consistent Since Web services effectively demarcate the boundaries of a system to which external users have no visibility, it is impossible to mandate that data remains consistent (since there is no possibility of direct control of that data). However, it is reasonable to mandate that Web services participating in a transaction receive consistent outcomes. That is, if the decision is to abort the transaction, all Web services involved with a particular transaction receive an abort message (and similarly, a commit message in the case of commit). One useful twist on this consistent outcome philosophy is to allow subsets of Web services (as defined by the application) to receive consistent outcomes. As we shall see later, the Business Transaction Protocol uses such a mechanism to provide flexibility in transaction structure.

• Isolated Ensuring isolation is usually achieved through locking of shared data. Given the fact that Web services expose data to potentially unknown and untrusted third parties, it may be unwise to lock data since it provides an opportunity for denial of service (though there is no reason why we would not lock data provided we had a limited trusted domain). Since there may be no strict locking involved in a Web service transaction, the level of isolation may not be as high as a traditional back-end transaction processing system.

• Durable Web services participating in a transaction must be supported by some recoverable infrastructure (as must any transaction coordinator), so that in the event of failure they can rejoin the transaction on recovering. Again, since the actual implementation of a Web service is not available, transaction users of that Web service have no system-level guarantees that the service will be recoverable, only that if it exposes transaction endpoints that it should be.

Given the Web services (or for that matter any other loosely-coupled) architecture, it's clear that we simply aren't going to utilize ACID transactions in the general case. Though we may still hope for all-or-nothing semantics, consistent outcomes and some level of durability, we cannot realistically hope for isolation unless we are operating within a specific domain of trust. What is needed is a twist on the classic two-phase algorithm for ACID transactions to turn it into a two-phase-based algorithm for Web services transactions. Fortunately, candidates for just such a protocol do exist.