Archive for April, 2009

ExtremeTransactions 3.6.2 released

Thursday, April 9th, 2009

This is a maintenance release that improves the JAX-WS handler configuration of the JAX-WS demo.

Download is recommended if you are interested in web service transactions…

TransactionsEssentials 3.5.4 Community Release

Tuesday, April 7th, 2009

As part of our ExtremeTransactions 3.6.1 release we have produced TransactionsEssentials 3.5.4 - a bug fix release for TransactionsEssentials.

The most important fixes in this release concern statement invalidation after transaction timeout and JMS/JNDI initialization improvements - both suggested by the community (for which thanks!)…

ExtremeTransactions 3.6.1: JAX-WS Transactions Illustrated…

Tuesday, April 7th, 2009

We now have our 3.6.1 release of ExtremeTransactions ready and online. This release includes a new and working JAX-WS demo performing a distributed transaction (where the commit scope reaches across web service calls) as well as several bug fixes. This release also includes a new version of the core: TransactionsEssentials 3.5.4

Feel free to check it out, all feedback is welcome!

Transactions, SOA and Loose Coupling

Saturday, April 4th, 2009

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.