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

Ex­cit­ing news for all those who have been wait­ing for this: we fi­nal­ly got our 3.6 re­lease of Ex­tremeTrans­ac­tions ready, in­clud­ing JAX-WS and SOAP sup­port so that trans­ac­tions can span mul­ti­ple web ser­vices.

While we had sup­port for web ser­vices in the past, this new re­lease now in­cor­po­rates JAX-WS sup­port - mean­ing that you don't have to re­sort to the old­er JAX-RPC any more.

In ad­di­tion, we have made the web ser­vice sup­port in­de­pen­dent of the SOAP stack (any JAX-WS im­ple­men­ta­tion should do).

We have just re­leased 3.5.1 of Ex­tremeTrans­ac­tions. This is an im­por­tant main­te­nance up­date that ba­si­cal­ly in­cludes the im­por­tant fix­es of Trans­ac­tion­sEssen­tials 3.5.3 (see pri­or an­nounce­ment).

This up­grade is rec­om­mend­ed for all sub­scribers.

We have a new re­lease out: 3.5.3 of Trans­ac­tion­sEssen­tials with ma­jor bug fix­es in the con­nec­tion pool­ing as the main fo­cus. This re­lease is rec­om­mend­ed for every­body.