You are here: Blog » Vision » BPEL and compensation
Is BPEL a good tool for im­ple­ment­ing com­pen­sa­tion? It re­al­ly de­pends, and you re­al­ly have to know what you are do­ing - which (with all re­spect) doesn't seem the case for most peo­ple (not even BPEL spe­cial­ists). So if not even those ex­perts know, how can we ex­pect the rest of us to know? Hence this blog en­try.

For in­stance, on re­peat­ed oc­ca­sions I have heard renowned BPEL and work­flow ex­perts men­tion that com­pen­sat­ing trans­ac­tions are "per­haps" best mod­eled at the busi­ness log­ic lev­el. This, by the way, in­cludes Bill Burke in the case of JBoss/jBPM - see here. Note that I em­pha­sized the word "per­haps": this in­di­cates the shade of mis­un­der­stand­ing usu­al­ly present in the ar­gu­ments.

I have been say­ing this here and there in the past (and in fine de­tail in this ar­ti­cle), but I want to re­peat it again: BPEL, nor work­flow nor WS-BA are ide­al for com­pen­sa­tion un­less the com­pen­sat­ing par­ty doesn't care whether it needs to com­pen­sate even­tu­al­ly. In oth­er words, if the com­pen­sa­tion is busi­ness as usu­al to the provider of the com­pen­sa­t­able ser­vice then BPEL might be OK (though cer­tain­ly not de­sir­able - see be­low).

Why is that? Put your­self in the place of a ser­vice that is asked to com­pen­sate by a BPEL en­gine some­where. Also sup­pose that you are in a B2B ecosys­tem where you don't nec­es­sar­i­ly trust the par­ty that owns the BPEL en­gine. Now what would you rather do: trust the BPEL to com­pen­sate - even­tu­al­ly (which might be nev­er!) or rather deal with com­pen­sa­tion your­self, say af­ter a time­out? I would def­i­nite­ly choose the lat­ter. I don't want some­one else to de­cide when I need to com­pen­sate. I want to de­cide for my­self, and the Atomikos TCC mod­el al­lows for that. BPEL and jBPM don't.

So BPEL is ruled out for me - at least as far as com­pen­sa­tion goes. What about WS-BA? It is a step in the right di­rec­tion, but un­for­tu­nate­ly it is a bloat­ed pro­to­col, very in­ef­fi­cient and loaded with ap­pli­ca­tion-lev­el mes­sages that pol­lute the com­pen­sat­ing part. Even worse, it also suf­fers in a large part from the lack of time­out and de­pends on the BPEL to at least trig­ger com­pen­sa­tion.

Also, WS-BA doesn't al­low for ap­pli­ca­tion log­ic on close - I won't go and both­er you with the en­tire spec de­tails but it is like a try..catch...fi­nal­ly where the ex­cep­tion is raised by the client (ugly!) and where the fi­nal­ly block can only be emp­ty! Again, Atomikos TCC is far su­pe­ri­or, more ef­fi­cient and more el­e­gant. It is also more nat­ur­al for com­pen­sa­tion than any BPEL en­gine will ever be.

One last note on BPEL and this sup­posed "mod­el­ing the com­pen­sa­tion in the busi­ness process": I was talk­ing to an IBM ar­chi­tect the oth­er day. He said that they were do­ing a large tel­co project with BPEL to co-or­di­nate things. One of the things he com­plained about was ex­act­ly this: they have to mod­el the com­pen­sa­tion and er­ror log­ic as ex­plic­it work­flow paths, and it was lit­er­al­ly over­load­ing every­thing with com­plex­i­ty. More­over, this com­plex­i­ty is hard to test. As he cor­rect­ly put it, they were im­ple­ment­ing a trans­ac­tion man­ag­er at the busi­ness log­ic (BPEL) lev­el, over and again in every process mod­el. In ad­di­tion, this was also hard to test he said and that it was vir­tu­al­ly killing the project - es­pe­cial­ly if there were change re­quests to con­sid­er. I be­lieve him:-) I gave him the URL to our TCC ar­ti­cle above.

Atomikos and TCC al­low you to fo­cus on the hap­py path of your work­flow mod­els. We take care of the rest. Now imag­ine what a re­duc­tion in com­plex­i­ty that is, and how much more re­li­able things get! So no, com­pen­sa­tion should NOT be mod­eled at the busi­ness lev­el. Ex­cept on rare oc­ca­sions maybe.

RSS

Comments

Corporate Information

Atomikos Corporate Headquarters
Hoveniersstraat, 39/1, 2800
Mechelen, Belgium

Contact Us

Copyright 2026 Atomikos BVBA | Our Privacy Policy
By using this site you agree to our cookies. More info. That's Fine