The cloud phe­nom­e­non is an in­ter­est­ing one, and a nat­ur­al evo­lu­tion of the out­sourc­ing mod­el. While a lot is go­ing on around cloud com­put­ing it­self, lit­tle is be­ing said about re­li­a­bil­i­ty.

Do clouds of­fer re­li­a­bil­i­ty? In a way yes: caching sys­tems like Ter­ra­cot­ta, Gem­stone or Or­a­cle's Co­her­ence of­fer a fail-safe mode for avail­abil­i­ty 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 ex­ists some­where else, which means that your process can con­tin­ue work­ing else­where.

All is fine (or most­ly fine) if you are work­ing with a sin­gle data­base and are pro­cess­ing, say, web re­quests in the cache. After all, if you only have one data­base and no oth­er re­sources then you don't even need some­thing like a trans­ac­tion man­ag­er (or Atomikos, for that mat­ter). There are at least two sit­u­a­tions where things change:

• If you queue cache up­dates to en­able write-be­hind, then you find your­self in a queu­ing sce­nario and are pro­cess­ing jobs from a queue to a data­base. En­ter dis­trib­uted trans­ac­tions.
• If you are not pro­cess­ing web re­quests but rather get queued re­quests from the start. En­ter dis­trib­uted trans­ac­tions.

In both cas­es you should at least con­sid­er us­ing a trans­ac­tion man­ag­er. In both cas­es, Atomikos is a good choice for the fol­low­ing rea­sons:

• It's open source (or at least our ba­sic ver­sion is)
• It's very light-weight and easy to de­ploy (mean­ing it lends it­self eas­i­ly to cloud-ori­ent­ed vir­tu­al­ized con­fig­u­ra­tions)
• It bun­dles over 10 years of ex­pe­ri­ence and mar­ket lead­er­ship
• It pro­vides full crash re­cov­ery and all oth­er bells and whis­tles - un­like many of the built-in so­lu­tions that you will find in a cache

So in that way, Atomikos pro­vides "re­li­a­bil­i­ty for the cloud".

With the cur­rent (2008-2009) re­ces­sion, cost cuts and com­modi­ti­za­tion of both soft­ware and hard­ware, the end re­sult seems to be con­verg­ing to­wards the state pre­dict­ed by the late Jim Gray dur­ing his Tur­ing Award speech in 1998:

"Cheap and bug­gy. Some­times it will work, some­times not, and no­body will re­al­ly know why".

Giv­en the per­spec­tive of such a world, it seems like some pre­cau­tions are jus­ti­fied. Since it can't be re­peat­ed of­ten enough, here is the Atomikos view on how to al­le­vi­ate all this:

• Use our trans­ac­tion tech­nol­o­gy to avoid data in­con­sis­ten­cy af­ter a fail­ure or crash. It acts like an in­sur­ance, re­al­ly: you don't need it when things are fine, but when things are turn­ing bad you're sure glad to have one!
• Use queu­ing to your ad­van­tage. Avoid de­pend­ing on the avail­abil­i­ty of a re­mote ser­vice by de­lay­ing re­quests un­til they can be per­formed (i.e., when the re­mote ser­vice is up).
• Add vir­tu­al­ly un­lim­it­ed scal­a­bil­i­ty while you're at it...

The com­bi­na­tion of tech­nolo­gies and tech­niques out­lined here will in­crease your re­li­a­bil­i­ty while de­creas­ing costs. You save on ex­pens­es by us­ing com­modi­tized hard­ware and soft­ware. You also save on man-hours of de­vel­op­ment be­cause our prod­ucts will al­low you to fo­cus on the hap­py path (fail­ure han­dling is au­to­mat­ed to a large part by our soft­ware). This sig­nif­i­cant­ly de­creas­es the com­plex­i­ty of the work­flow your de­vel­op­ers have to code, main­tain and de­bug. Less code in turn means less bugs, so this again in­creas­es re­li­a­bil­i­ty. Isn't that beau­ti­ful?

Check out this link: Red Hat Re­acts to SpringSource Lead­er­ship (warn­ing: bro­ken link) and scroll down to the com­ments. Some (most?) of them seem to be ac­knowl­edg­ing the Atomikos role in shap­ing the fu­ture of JEE...

Re­gards

2018 UPDATE: the link seems to be bro­ken by now, apolo­gies for that...

Atomikos Ex­tremeTrans­ac­tions sup­ports web ser­vice trans­ac­tions and also com­pen­sa­tion-based TCC (Try-Con­firm/Can­cel) so your ap­pli­ca­tion/ser­vice is in con­trol of what roll­back or com­mit means.

Ac­cord­ing to more than one an­a­lyst we spoke to, web ser­vice trans­ac­tions are sup­pos­ed­ly in­com­pat­i­ble with the loose cou­pling de­sired by SOA (Ser­vice Ori­ent­ed Ar­chi­tec­ture), with the fol­low­ing be­ing cit­ed as the main rea­sons (read: prob­lems):

• Any 'hid­den' in­ter­ac­tions (like out-of-band two-phase com­mit) are mis­tak­en­ly per­ceived as a vi­o­la­tion of the loose cou­pling and con­tract-based SOA de­sign prin­ci­ples.
• As a re­sult, a com­mon prob­lem is that a trans­ac­tion­al ser­vice calls oth­er ser­vices that are not trans­ac­tion­al - and this go­ing un­no­ticed. This be­comes a prob­lem when the de­sired out­come is roll­back be­cause those non-trans­ac­tion­al ser­vices will com­mit their work right-away.

With Atomikos, these are all non-is­sues for the fol­low­ing rea­sons:

• Both the sender and re­ceiv­er in a trans­ac­tion­al (web) ser­vice in­ter­ac­tion can spec­i­fy (and en­force) their trans­ac­tion pref­er­ences/as­sump­tions by means of our in­ter­me­di­aries ('han­dlers' in JAX-WS ter­mi­nol­o­gy).
• For in­stance, if a ser­vice ('A') ex­pects an­oth­er ser­vice ('B') to be trans­ac­tion­al then it suf­fices to add our out­go­ing han­dler to the call chain at A. Thanks to the na­ture of our pro­to­cols, the calls to B will then car­ry the trans­ac­tion con­text of A, and more­over the re­sult­ing SOAP re­turn mes­sage from B will also in­di­cate whether or not it has tak­en part in that trans­ac­tion. If not, then the han­dler at A (in­spect­ing the re­turn mes­sage) will throw an ex­cep­tion to in­di­cate the con­tract breach. So this guar­an­tees the trans­ac­tion con­tract be­ing re­spect­ed from A's point of view.
• How about B? There the so­lu­tion is sim­i­lar: if B wants in­com­ing calls to be trans­ac­tion­al, it suf­fices to add a han­dler to the in­com­ing call chain at B. This han­dler can be con­fig­ured with sim­i­lar trans­ac­tion de­mar­ca­tion pref­er­ences as in JEE (REQUIRED, REQUIRES_NEW, ...).

So it is re­al­ly sim­ple to en­force a trans­ac­tion­al con­tract among ser­vices in a SOA, thanks to Atomikos. Com­pare this to the pop­u­lar al­ter­na­tive of mod­el­ling roll­back in the ser­vice work­flow (which at least dou­bles the work­flow com­plex­i­ty and makes the whole SOA ini­tia­tive more brit­tle and less ag­ile) and it be­comes clear why we say: use Atomikos and fo­cus on the hap­py path! (TM)

If you would like to try this out in prac­tice, just check out Ex­tremeTrans­ac­tions for your­self.

Sure you've heard about JEE... And if you know SCRUM then you prob­a­bly also think that JEE is of­ten counter-pro­duc­tive be­cause of ap­pli­ca­tion-serv­er is­sues.

Well, it doesn't have to be like that: with Atomikos prod­ucts and in com­bi­na­tion with Spring and Hiber­nate, you can es­sen­tial­ly ditch the ap­pli­ca­tion serv­er and do every­thing in­side a reg­u­lar Java (JSE) vir­tu­al ma­chine. The ad­van­tage: you can test what you de­ploy (noth­ing else is gen­er­at­ed, noth­ing else is to be con­fig­ured in XML files or any­thing). This ac­tu­al­ly re­de­fines the mean­ing of test cov­er­age: in­stead of test­ing your ap­pli­ca­tion class­es, you can now also test most of the en­tire run­time as well, in­clud­ing the run­time jars. Add to that the tremen­dous im­prove­ment in turn-around time that Atomikos gives you, and you will nev­er want to do ag­ile in a dif­fer­ent way again...