Transactions and SOA

Sean McGrath (hmm? Did the Irish invent upper camel case?) commented about transactions and SOA that is worth taking down:

(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.

Certainly one can feel the utter futility of building business processes using ACID transactions as the core building block. That's a strike against EJB at a fundamental level.

I like the term Sean uses "temporal coupling". The interesting thing is that reasoning about time can be extremely complex however is essential if you want to reason about interaction. Sean makes an extremely good suggestion, when refactoring your legacy system, if you hit something with high temporal coupling then don't even bother decoupling it. High temporal coupling should be a indicator that you should bundle the separate information content into a single document. Let message passing and its implicit side effect of serialization do the transaction handling for you.