Personally, I would rather see that as being a property of the service
interface or the endpoint. That way, I can use a service that does not
necessarily have a BPEL associated with it and determine whether it
supports compensation at design time or run-time. A coordination
protocol can provide a feature or policy that can be used to that
effect. But if the only case where you want to determine/control is when
using BPEL, then it makes sense that this feature is part of the BPEL
language.
Do you think there's a case for services that do not have an associated
BPEL abstract, but still want to expose/control that aspect of their
behavior?
arkin
Satish Thatte wrote:
>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:]
>Sent: Monday, August 11, 2003 1:19 PM
>To: Satish Thatte
>Cc:
>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:]
>>Sent: Monday, August 11, 2003 1:03 PM
>>To: Satish Thatte
>>Cc:
>>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:
>>>For additional commands, e-mail:
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>
>
