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

["Satish Thatte" <satisht@microsoft.com>]

Let me try again ;-)

Lack of a syntactic compensation handler implies the use of a default
compensation handler, both for local as well as process scopes.  There
are well-defined internal means for invoking compensation handlers for
all except the process scope.  Maintaining a default compensation
handler for the process scope is an expense for the implementation.
Thus, only in the case of the process scope, there is no way to tell if
anyone intends to use the compensation and whether the expense of
maintaining compensation capability is warranted.  Hence the need for a
flag.

Does that help?



-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Monday, August 11, 2003 1:19 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 25 - Consistent enablement of compensation
handlers

Assume that compensation is not applicable for the instance as a whole. 
Can't I just write a compensation handler with the <empty> activity? Why

do I need a separate flag to essentially do that? And if so, why does 
this flag exists for some scopes and not others?

arkin

Satish Thatte wrote:

>Assaf,
>
>enableInstanceCompensation permits default compensation for the
instance
>as a whole, i.e., for the converse case when no compensation handler is
>specified.
>
>I am having trouble differentiating between "no compensation is
>possible" and "compensation does nothing".  Clearly, in real life,
>compensation is often less than perfect, so making such distinctions
>requires many shades of meaning rather than a binary distinction, which
>we cannot really express.
>
>Satish
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Monday, August 11, 2003 1:03 PM
>To: Satish Thatte
>Cc: wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue - 25 - Consistent enablement of
compensation
>handlers
>
>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
>> 
>>
>>    
>>
>
>
>  
>