Atomikos ExtremeTransactions supports web service transactions and also compensation-based TCC (Try-Confirm/Cancel) so your application/service is in control of what rollback or commit means.
According to more than one analyst we spoke to, web service transactions are supposedly incompatible with the loose coupling desired by SOA (Service Oriented Architecture), with the following being cited as the main reasons (read: problems):
- Any ‘hidden’ interactions (like out-of-band two-phase commit) are mistakenly perceived as a violation of the loose coupling and contract-based SOA design principles.
- As a result, a common problem is that a transactional service calls other services that are not transactional - and this going unnoticed. This becomes a problem when the desired outcome is rollback because those non-transactional services will commit their work right-away.
With Atomikos, these are all non-issues for the following reasons:
- Both the sender and receiver in a transactional (web) service interaction can specify (and enforce) their transaction preferences/assumptions by means of our intermediaries (’handlers’ in JAX-WS terminology).
- For instance, if a service (’A') expects another service (’B') to be transactional then it suffices to add our outgoing handler to the call chain at A. Thanks to the nature of our protocols, the calls to B will then carry the transaction context of A, and moreover the resulting SOAP return message from B will also indicate whether or not it has taken part in that transaction. If not, then the handler at A (inspecting the return message) will throw an exception to indicate the contract breach. So this guarantees the transaction contract being respected from A’s point of view.
- How about B? There the solution is similar: if B wants incoming calls to be transactional, it suffices to add a handler to the incoming call chain at B. This handler can be configured with similar transaction demarcation preferences as in JEE (REQUIRED, REQUIRES_NEW, …).
So it is really simple to enforce a transactional contract among services in a SOA, thanks to Atomikos. Compare this to the popular alternative of modelling rollback in the service workflow (which at least doubles the workflow complexity and makes the whole SOA initiative more brittle and less agile) and it becomes clear why we say: use Atomikos and focus on the happy path! (TM)
If you would like to try this out in practice, just check out ExtremeTransactions for yourself.
Contrary to what I expected, going from ant to maven seems to simplify our build after all: maven seems to be maturing, and new team members tend to know maven better than ant.