My J06 talk on WS-AT and WS-BA is now on­line here

Thanks to Stephan Janssen, Guy Crets and the rest of the BEJUG crew!

-Guy

Some data­bas­es, like Or­a­cle in par­tic­u­lar, don't seem to al­low you to set the max­i­mum du­ra­tion for trans­ac­tions (hence locks). This im­plies that some ap­pli­ca­tions (those that don't be­have well) can be hold­ing long-lived locks on your data. The re­sult is that some data may be­come un­avail­able (even for days in one par­tic­u­lar case I have seen!!!).

The so­lu­tion? I am not sure about oth­er prod­ucts, but the Atomikos trans­ac­tion li­braries make sure that none of your ap­pli­ca­tions can hold locks longer than the con­fig­ured XA trans­ac­tion time­out. Mean­ing: you get the ben­e­fit of en­sured con­trol and avail­abil­i­ty of your data. It's iron­ic re­al­ly; many peo­ple be­lieve that XA can block your data but as this case shows it is ex­act­ly the op­po­site!

I have been wait­ing for ages to see web ser­vices get ready for SOA. Re­cent­ly, hint­ed by a cus­tomer, I (re)dis­cov­ered JINI. What that mo­ment was like? Well, look­ing at JINI (in com­bi­na­tion with JavaS­paces) I saw a dy­nam­ic lookup plat­form based on in­ter­faces (read: ca­pa­bil­i­ties - not names) and with scal­a­bil­i­ty, self-heal­ing char­ac­ter­is­tics and the per­for­mance of RMI. Java­spaces even adds the best of mes­sag­ing and asyn­chrony. It sounds too good to be true.

To be con­tin­ued...

For my Javapo­lis 2006 talk I de­cid­ed to have a clos­er look at the WS-BA spec­i­fi­ca­tion (then still in draft) and its re­la­tion­ship to BPEL 2.0 (then also still in draft). While I was at it, I also de­cid­ed to use the com­mit­tee's min­utes to clar­i­fy any re­main­ing ques­tions I had. This ex­er­cise took me a few days but the re­sult made clear that the WS-BA pro­to­col has se­ri­ous lim­i­ta­tions that make it not so use­ful as it could be:

The WS-BA pro­to­col is al­most en­tire­ly mod­eled af­ter BPEL. WS-BA par­tic­i­pants map one-to-one to BPEL com­pen­sa­tion scopes. Be­cause BPEL doesn't pro­vide close han­dlers, nei­ther does the WS-BA pro­to­col al­low ap­pli­ca­tion log­ic on close. The im­pli­ca­tion? If you mod­el your ser­vices as WS-BA ser­vices then you re­main 'in-doubt' about every ser­vice in­vo­ca­tion (in the­o­ry, the WS-BA close event would no­ti­fy you that the deal is closed, but you're not sup­posed to do busi­ness log­ic in that call­back so it might as well not be there).

To give an ex­am­ple: if you are an air­line and want to use WS-BA to make seat reser­va­tions trans­ac­tion­al then you would nev­er know whether any reser­va­tion needs to be can­celed or not. More pre­cise­ly: it will al­ways be pos­si­ble for any of your cur­rent reser­va­tions to be com­pen­sat­ed at some lat­er time.

The bot­tom line for you as a ser­vice provider: com­pen­sa­tion is al­ways pos­si­ble. The con­se­quence is far-reach­ing: how do you pro­duce sales re­ports? You can't, un­less you ac­cept that you are deal­ing with tem­po­rary data (that may lat­er be com­pen­sat­ed for). Every sin­gle sale you made can the­o­ret­i­cal­ly still be com­pen­sat­ed.

For­tu­nate­ly, WS-BA and BPEL al­low you to mod­el com­pen­sa­tion as some­thing that costs to the cus­tomer, so your sales re­ports may not suf­fer that much from com­pen­sa­tion af­ter all. But this leads us to an­oth­er prob­lem I have with WS-BA/BPEL: if you mod­el com­pen­sa­tion as some­thing that leaves tan­gi­ble ef­fects (costs?) for the cus­tomer then what good is it for me to have that kind of trans­ac­tion­al guar­an­tee? After all, BPEL also says that com­pen­sa­tion can be trig­gered by the fail­ure of a par­ent task. So my cus­tomer may have to pay for my ser­vice just be­cause some in­ter­me­di­ary task has failed! I am not sure if it is just me, but I think this is a big prob­lem.

One more point I have to make about WS-BA is that it ap­pears pol­lut­ed with work­flow mes­sages that don't re­al­ly con­tribute to the pur­pose of an agreed out­come across ser­vices. For in­stance, the 'Com­plet­ed' mes­sage seems to be there just to in­di­cate whether a par­tic­i­pat­ing ser­vice should be can­celed (leave no ef­fects) or com­pen­sat­ed. But like I ar­gued be­fore, can­ce­la­tion can still lead to com­pen­sa­tion some­where down the call stack so this is an ut­ter­ly use­less pro­to­col mes­sage any­way. It only makes sense in the con­text of BPEL. And since BPEL is work­flow, WS-BA is a work­flow pro­to­col and not a trans­ac­tion ter­mi­na­tion pro­to­col. In terms of ef­fi­cien­cy it isn't ex­act­ly very good ei­ther: there are too many un­nec­es­sary mes­sage rounds in­volved. It could all have been much sim­pler.

My ad­vice: use the Atomikos TCC (Try-Con­firm/Can­cel) par­a­digm if you want re­al­ly re­li­able and com­pen­sa­tion-based web ser­vices. It is faster, bet­ter and leads to real busi­ness-lev­el con­sis­ten­cy across ser­vice in­vo­ca­tions. You will at least know that your sales re­ports are per­ma­nent and cor­rect, and your cus­tomers won't pay for failed busi­ness trans­ac­tions.

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