The cloud phenomenon is an interesting one, and a natural evolution of the outsourcing model. While a lot is going on around cloud computing itself, little is being said about reliability.

Do clouds offer reliability? In a way yes: caching systems like Terracotta, Gemstone or Oracle's Coherence offer a fail-safe mode for availability of your data in the form of caches. So if a cloud node goes down, chances are that a live copy of the data still exists somewhere else, which means that your process can continue working elsewhere.

All is fine (or mostly fine) if you are working with a single database and are processing, say, web requests in the cache. After all, if you only have one database and no other resources then you don't even need something like a transaction manager (or Atomikos, for that matter). There are at least two situations where things change:

• If you queue cache updates to enable write-behind, then you find yourself in a queuing scenario and are processing jobs from a queue to a database. Enter distributed transactions.
• If you are not processing web requests but rather get queued requests from the start. Enter distributed transactions.

In both cases you should at least consider using a transaction manager. In both cases, Atomikos is a good choice for the following reasons:

• It's open source (or at least our basic version is)
• It's very light-weight and easy to deploy (meaning it lends itself easily to cloud-oriented virtualized configurations)
• It bundles over 10 years of experience and market leadership
• It provides full crash recovery and all other bells and whistles - unlike many of the built-in solutions that you will find in a cache

So in that way, Atomikos provides "reliability for the cloud".

With the current (2008-2009) recession, cost cuts and commoditization of both software and hardware, the end result seems to be converging towards the state predicted by the late Jim Gray during his Turing Award speech in 1998:

"Cheap and buggy. Sometimes it will work, sometimes not, and nobody will really know why".

Given the perspective of such a world, it seems like some precautions are justified. Since it can't be repeated often enough, here is the Atomikos view on how to alleviate all this:

• Use our transaction technology to avoid data inconsistency after a failure or crash. It acts like an insurance, really: you don't need it when things are fine, but when things are turning bad you're sure glad to have one!
• Use queuing to your advantage. Avoid depending on the availability of a remote service by delaying requests until they can be performed (i.e., when the remote service is up).
• Add virtually unlimited scalability while you're at it…

The combination of technologies and techniques outlined here will increase your reliability while decreasing costs. You save on expenses by using commoditized hardware and software. You also save on man-hours of development because our products will allow you to focus on the happy path (failure handling is automated to a large part by our software). This significantly decreases the complexity of the workflow your developers have to code, maintain and debug. Less code in turn means less bugs, so this again increases reliability. Isn't that beautiful?

Check out this link: Red Hat Reacts to SpringSource Leadership (warning: broken link) and scroll down to the comments. Some (most?) of them seem to be acknowledging the Atomikos role in shaping the future of JEE…

Regards

2018 UPDATE: the link seems to be broken by now, apologies for that…

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.

Sure you've heard about JEE… And if you know SCRUM then you probably also think that JEE is often counter-productive because of application-server issues.

Well, it doesn't have to be like that: with Atomikos products and in combination with Spring and Hibernate, you can essentially ditch the application server and do everything inside a regular Java (JSE) virtual machine. The advantage: you can test what you deploy (nothing else is generated, nothing else is to be configured in XML files or anything). This actually redefines the meaning of test coverage: instead of testing your application classes, you can now also test most of the entire runtime as well, including the runtime jars. Add to that the tremendous improvement in turn-around time that Atomikos gives you, and you will never want to do agile in a different way again…