[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 25 - Consistent enablement of compensation handlers
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: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 >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org >For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]