That should be the ques­tion, but most of the time it is not.

Many peo­ple don't seem to re­al­ize when and why they need JTA/XA trans­ac­tions. I re­al­ly think you should look into this tech­nol­o­gy, be­cause of a num­ber of very good rea­sons. Let this blog post be your guide...

...and not some­thing you buy!

If you only re­mem­ber one thing from the BEJUG work­shop on SOA then it should be this. And if you didn't go to this work­shop: make sure you can go next time, be­cause it was worth it:-)

But se­ri­ous­ly, all too of­ten do peo­ple buy a prod­uct and then start to look at how to use it, say, to build a SOA (Ser­vice Ori­ent­ed Ar­chi­tec­ture). This is like buy­ing a car: would you get a rolls royce first, and then pick the road to dri­ve it on? Or would you rather look at the road first, and then choose the best car for it? I would do the lat­ter...

Best

Did you hear about Spring? In my opin­ion, it is go­ing to play a big role in J2EE and sim­pli­fy­ing Java pro­gram­ming. At least when it comes to trans­ac­tion­al ap­pli­ca­tions, things are much sim­pler than with EJB.

Have a look for your­self: TSS was kind enough to pub­lish my pre­sen­ta­tion on Spring.

Ru­mors had been around for a while that this might hap­pen, and it did: the WS-Trans­ac­tion specs (pro­pri­etary work un­til re­cent­ly) are now un­der the cus­tody of the OASIS stan­dards body: http://www.oa­sis-open.org/com­mit­tees/tc_home.php?wg_ab­brev=ws-tx

Ven­dors sup­port­ing the WS-TX ini­tia­tive in­clude BEA Sys­tems, IBM, Mi­crosoft, Or­a­cle, SAP and TIBCO. This sounds like the kind of in­dus­try mo­men­tum need­ed to push ac­cep­tance in the mar­ket:-)

The new stan­dard­iza­tion com­mit­tee is open to any­body - I would par­tic­i­pate too if it weren't for the strict IPR poli­cies used by OASIS...

With the fi­nal­iza­tion and pub­li­ca­tion of Web Ser­vices Ad­dress­ing 1.0 - Core (WS-A) the world of web ser­vices has changed dras­ti­cal­ly (or will do so in the near fu­ture).

The idea be­hind ad­dress­ing is to al­low non-HTTP trans­ports as well as HTTP trans­ports, and even a chain of trans­ports be­fore a mes­sage fi­nal­ly gets to its des­ti­na­tion. This would mean that a SOAP re­quest can be rout­ed via dif­fer­ent plat­forms (JMS, HTTP, SMTP to name a few) and still make it to its des­ti­na­tion. This goes hand in hand with asyn­chro­nous SOAP... Another ma­jor idea in WS-A is to al­low ac­knowl­edge­ments, replies and faults to be re­turned to oth­er ad­dress­es dif­fer­ent from the orig­i­nal sender of a SOAP re­quest.

A ma­jor con­se­quence is that once again, the JAX-RPC pro­cess­ing mod­el has to be stretched to ac­co­mo­date this new stan­dard. To see why, let's con­sid­er what hap­pens in a typ­i­cal JAX-RPC ser­vice end­point:

1. An in­com­ing re­quest mes­sage is re­ceived via HTTP.
2. One or more han­dlers (in­ter­me­di­aries) are al­lowed to pre-process the mes­sage (main­ly its head­ers).
3. The ser­vice im­ple­men­ta­tion gets the mes­sage to do the real (busi­ness) part of the job and gen­er­ates a re­ponse (if ap­plic­a­ble).
4. One or more han­dlers get to post-process the re­sponse.
5. The HTTP con­ver­sa­tion is ter­mi­nat­ed by send­ing an ac­knowl­edge­ment (with or with­out a re­sponse mes­sage).

This is al­most in­her­ent­ly a syn­chro­nous re­quest/re­ply par­a­digm, and things like re­turn­ing a re­ply to a dif­fer­ent ad­dress be­come very cum­ber­some: this has to be done in a han­dler that short­cuts the re­ponse chain and sends the SOAP mes­sage some­where else in­stead...