When de­sign­ing a cor­po­rate SOA ar­chi­tec­ture you are of­ten faced with a tough choice: do you rely on a com­mon data­base (cen­tral­ized) or do you im­ple­ment repli­ca­tion in­stead?

Let me ex­plain what I mean. The idea in SOA is that you de­fine more or less in­de­pen­dent ser­vices that cor­re­spond (hope­ful­ly) to clear­ly de­fined and busi­ness-re­lat­ed ac­tiv­i­ties. For in­stance, you could have a cus­tomer man­age­ment ser­vice and a pay­ment/in­voic­ing ser­vice. The cus­tomer man­age­ment ser­vice be­longs to CRM, the in­voic­ing to the billing de­part­ment. How­ev­er, both of these ser­vices might need the same cus­tomer data. Now what do you do? Ba­si­cal­ly, you have the fol­low­ing op­tions:

1. Use the same cen­tral­ized cus­tomer data­base. This gives you the ben­e­fit of easy main­te­nance be­cause there is only one copy. How­ev­er, this also means that you are cou­pling your ser­vices into the same data­base schema, and up­dates to the schema are like­ly to af­fect more than one ser­vice.
2. Repli­cate the cus­tomer data­base, by iden­ti­fy­ing one mas­ter (the CRM?) that reg­u­lar­ly push­es or pub­lish­es up­dates (in an XML feed, for in­stance). While you lose the ben­e­fit of easy main­te­nance, this does give you loose cou­pling: as long as the XML for­mat is the same, you can change DBMS schemas as much as you like - with­out af­fect­ing oth­er ser­vices.
3. Merge the cus­tomer and in­voic­ing ser­vices into one. How­ev­er, this may not al­ways be pos­si­ble or de­sir­able, and may even de­feat the pur­pose of ser­vice-ori­ten­ta­tion al­to­geth­er.
4. Have the in­voic­ing query the cus­tomer ser­vice for each pay­ment. Thi seems to in­cur a lot of de­pen­den­cies and net­work traf­fic.

So what do you do? My pref­er­ence tends to go to the sec­ond op­tion. How­ev­er, it means that re­al­is­tic SOA ar­chi­tec­tures are like­ly to have an event-dri­ven na­ture.

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.

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