Roger Sessions writes about WS-Transactions in his ObjectWatch news letter and the article shocks me a bit. First, his "Shootout at the Transaction Corral" has a pretty confusing lead-in story for a story about transactions. It starts with how to get breakfast from two places at the same time and how that is a real life coordinated transaction -- it may be so, but why make a "real life analogy" if that by itself is so far fatched that it's somewhat losing the point.

If you're still reading once you made it through the introduction it getting interesting:

"The complexity would be justified if WS-C showed that it was a useful generic framework that could be specialized for purposes other than WS-T. But no such justification is included, other than the fact that WS-C forms the basis for both AT (atomic transactions) and BA (business activity). "

It takes little to none visionary talent to see that WS-Coordination is about setting up general-purpose service contexts for all sorts of things and not only for transactions. Synchronization services, session and object state and such things can very well be attached to WS-Coordination. As in J2EE and COM+ a transaction is just a property that is associated with a context.

"However, as anybody who is familiar with the software fortress model would know, one would never, never, never allow true atomic transactions to move from one web service to another. To do so is to violate the trust chasm that naturally separates web services. ATs thus have absolutely no place in a web service transaction specification."

That's a pretty short-sighted statement, because that says that a fortress (I personally prefer the cuter term "fiefdom" coined by the guy who actually came up with this model: Pat Helland) is always implemented as a homogeneous system. Not so: A "fortress" is a system which can very well be implemented as a heterogenous assembly of services implemented on different machines, different OSses and different platforms. If that's so, you will need AT to coordinate local, distributed transactions across, for instance, J2EE and .NET. Web Services are about interop, not the internet!

"Problem three with the WS-T specification is that it includes features that are likely to cause database corruption. I am referring to the so-called phase-0 protocol, part of the AT specification. [...] This implies that the server is caching data. "

Phase0 is called that way because it happens before transaction coordination starts. Befort the coordination phase begins, every data sink can do whatever it wants with the data, including holding local caches as long as it has a proper strategy for dealing with concurrency on its local data store. Each store is responsible for doing it's thing for "ACI" at that time. If that's achieved through optimistic locking and in-memory cached keys, etc. that's perfectly legal. Phase0 is triggered so that you can take all of your current transient work and make it part of the transaction before 2PC starts - that's a Good Thing.

"I can tell you what SHOULD happen. IBM, Microsoft, and BEA SHOULD redo their model and make three changes: eliminate the WS-C specification, remove the WS-T dependency on WS-C, and put atomic web service transactions (ATs) where they belong, in the trash. "

I think that Roger Session may not fully understand the interconnections of web services, transactions and real world system complexity here. Even inside the "fortress", interop counts.

Transactions with support for synchronous ACID transactions must, are and will remain to be a core feature of all major enterprise technology stacks - whether the transport is RMI, CORBA, DCOM or anything with an XML payload. Compensation has always been a real-life requirement long before Web services came along. What web services change is that they enable cross-organization integration by lowering development and infrastructure cost; hence, such transaction problems now become mainstream.

Web services standards are about making transport interop happen and about making service and security negotiation work across systems. This is true for both, inside and outside the firewall. Web services don't fundamentally change all of the world as we know it.