In our conceptualisation of SOA (asynch. business document messaging + REST) there is no temporal coupling between communicants, no resource locking and no stateful services. That pretty much rules out ACID based transactions:-)
Invariably, we get asked to explain our approach to transactions. Our answer is:
(a) if you really, really need transactions - don't attempt to do it with Web Services. The CORBAs and the TPMs of this work do that stuff bettter than any amout of new fangled lets-do-it-with-angle-brackets ever will.
(b) Do you really need transactions? There are times when yes, you absolutely do but equally there are times when you ended up needing transactions become of a function centric/object centric design model. Given that distributed transactions are hard and expensive (you cannot design away the network, you can hide it with dollar bills but you cannot design it away), it makes business sense to only use them when you need to.
(c) Automatic rollback? Give me a break. 99% of business process rollback is business logic specific and is most cost effectively done by people who understand the context and can compensate much more intelligently than machines. If you have really simple compensation requirements then congratulations! You are in a minority in my experience.
(d) Systems that have ACID semantics make perfectly good services to expose on an SOA. Like any paradigm, one of the skills of service decomposition is knowing when to stop. A temporal coupling boundary (such as a classic ACID) is a good place to stop.
I recommend Carlos Peres
why pessimistic transactions arent practical.