Re: [wsbpel] Issue - 25 - Consistent enablement of compensation handlers

[Assaf Arkin <arkin@intalio.com>]

Satish Thatte wrote:

>There appear to be two parts to this issue.
>
>Part 1:  What are the semantics of a compensation handler specified for
>the business process as a whole when the enableInstanceCompensation
>attribute is set to "no"? If instance compensation is not enabled then
>it should be an error to define a compensation handler. This should be
>clarified.
>  
>
>SRT:  Agreed.  This is a statically detectable error.
>  
>
So what real purpose does enableInstanceCompensation serve?


>Part 2:  If the intent is to disable default compensation when no
>compensation handler is defined then another alternative is to assume
>that no compensation is possible if no compensation handler is defined
>(and the same for scopes).
>
>SRT:  This is not the intent. Rather, the intent is dual: that "no
>compensation is possible" needs to be expressed explicitly using the
>following compensation handler
>
><compensationHandler>
>  <empty/>
></compensationHandler>
>
If a compensation handler is defined then compensation is possible and 
can be invoked using the <compensate> activity. So this example does not 
mean "no compensation is possible", but rather "no work will be done 
during compensation".

In real life we find two different cases. One is where no work needs to 
be done during compensation, in particular because no state was changed, 
e.g. after an RFQ. So if you have such a scope and for some reason you 
need to use the <compensate> activity from a compenstion/fault handler, 
you know not to bother doing it.

The other is when compensation is not possible, or not possible as 
written in the scope. The scope may perform some work which causes a 
state change, but there is not way to compensate, and the process should 
be structured accordingly, e.g. by performing that activity as the last 
one (assuming all others can be compensated or require no compensation).

arkin

> 
>
>Satish
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>