[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 229 - Fault handling and compensation handlingallows selective compensation of child scopes
Satish, I stand informed, and glad. The price of absence. Alastair Satish Thatte wrote: > Alastair, > > In your example it would seem that the forward work was also done in > parallel since the apps were using a message bus and had no > dependencies. In that case the default compensation is indeed parallel, > not in reverse order of actual completion, per resolution of 10. The > only order enforced is logical order based on control dependencies. > > Satish > > -----Original Message----- > From: Alastair Green [mailto:alastair.green@choreology.com] > Sent: Wednesday, October 19, 2005 8:45 AM > To: chris.keller@active-endpoints.com > Cc: 'Alex Yiu'; 'Alexandre Alves'; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 229 - Fault handling and compensation > handling allows selective compensation of child scopes > > Hi Chris, > > Not sure. Currently, I can either be lazy or get very energetic. Is it > worth complicating matters by allowing me to have a burst of enthusiasm > followed by a bout of laziness? > > What would the semantic of <compensate [the rest]/> be? The remainder in > > reverse order of initial execution (each targeted <compensate/> pulls > the scope concerned out of the available compensatable children list)? > > The optimization I would really like to see is <compensate > order=undefined/>, which would allow an implementation to fire off all > child compensation handlers asynchronously (assume no > interdependencies). > > We had a POC where the process, on receiving a "cancelled" from one > system, would cancel (via our distributed transaction system) three > others, none of whom cared about or shared data with the others (they > were all hanging of a message bus as subscribers for their app traffic, > and had no hardwired knowledge of each other). We then fired out a > cancel to all concerned, which our engine did "simultaneously". The > systems (deal entry, credit check, back office, and exchange broker) all > > pulled back, irrespective of who failed -- their "compensation" order > was completely irrelevant. I think this case is not atypical of real > world business processes, and the nesting capability allows any amount > of fine-grained control if needed. > > If such a feature were available then specific ordered compensations > followed by "do the rest unordered" would perhaps have more functional > relevance (not just be a programming economy). > > Alastair > > Chris Keller wrote: > >> Ok, then I think you agree on Alex's proposal to adopt options 3 and >> 4. Thus allowing <compensate/> after using <compensate scope="..."/>. >> Since currently if one changes some part of the compensate order >> (perhaps to interleave other invokes, etc.) they can't just say ok, >> now compensate the rest. Which would change the following text in >> section 13.3.3: >> >> "Note that the <compensate/> activity in a fault or compensation >> handler attached to scope S causes the default-order invocation of >> compensation handlers for completed scopes directly nested within S. >> The use of this activity can be mixed with any other user-specified >> behavior except the explicit invocation of <compensate scope="Sx"/> >> for scope Sx nested directly within S. Explicit invocation of >> compensation for such a scope nested within S disables the >> availability of default-order compensation, as expected." >> >> Also we should say somewhere if a user defined fault handler or >> compensation handler is called no child scopes will be compensated >> unless the user explicitly uses the compensate activity. And I agree >> with you no matter what ends up with this issue design tools can warn >> users when scopes have been created which don't compensate or only >> partially compensate child scopes. >> >> - Chris >> >> >> > ------------------------------------------------------------------------ > >> *From:* Alastair Green [mailto:alastair.green@choreology.com] >> *Sent:* Wednesday, October 19, 2005 3:39 AM >> *To:* Alex Yiu >> *Cc:* Alexandre Alves; wsbpel@lists.oasis-open.org; >> chris.keller@active-endpoints.com >> *Subject:* Re: [wsbpel] Issue - 229 - Fault handling and compensation >> handling allows selective compensation of child scopes >> >> Alex, Alexandre, Chris: >> >> I guess it is not clear to me what is broken. >> >> There seems to be agreement that the reverse order default is >> reasonable, and that the ability must be present to compensate in a >> different order, or partially/selectively. This is the status quo, is >> it not? >> >> The premise of opening the issue was to question allowing users to >> specify custom compensation logic on the grounds that it was too hard >> to program. I disagree with this premise. I must be missing something >> -- either we need the override (which is what I am reading in Alex and >> > > >> Alexandre's comments) or we don't. I am not seeing contributions which >> > > >> justify the original premise. >> >> If an implementation chooses to compiler warn (or even block) the >> compensate named scope activity, then that is surely an implementation >> > > >> issue. >> >> I have been inactive in this group for a long time, so I repeat -- I >> may be missing something basic in what's being discussed, but for now >> -- I don't get it. >> >> Alastair >> >> Alex Yiu wrote: >> >> >> Hi, Alexandre and others, >> >> I do support opening this issue. >> >> On the other hand, I am not sure an error needs to be raised when >> reverse order invariant is not observed. The reverse order is the >> *default *compensation order, NOT the only compensation order. >> Instead, we can issue a warning (both compile time and runtime). >> >> Even though we decided not to add a "reversable" flag to <scope> >> construct in Issue 10 for simplicity, scopes are often introduced to a >> > > >> process definition in reality which actually have not significance in >> the context of compensation (e.g. just to introduce local partnerLink, >> > > >> perform some non-business tasks that cannot and need not be be >> compensated). Those scopes should be safe to be ignore in the context >> of compensation. >> >> Also, while there may be a logical order of dependence of forward-work >> > > >> among scopes, a logical order may not necessarily exist in the >> backward-work among scopes. For example, scope-A has two sub-scopes: >> one for PO creation, one for ShippingOrder creation. Creation of >> ShippingOrder depends on the PO-id from PO creation. However, when we >> want to cancellation of both PO and SO during compensation, the >> cancellation of PO does not necessarily depend on the cancellation of >> SO (depending on the argreed procotols among customer and vendors and >> shippers). In fact, one may cancel PO and SO in parallel. >> >> >> Thanks! >> >> >> Regards, >> Alex Yiu >> >> >> >> >> Alexandre Alves wrote: >> >> Hi Alastair, >> >> Isn't it already possible to break this reverse order invariant by >> having the user explicitly compensate named scopes: >> >> <scope name="root"> >> <faultHandlers> >> <catchAll> >> <compensate scope="a"> >> <compensate scope="b"> <!-- does not follow reverse order >> > --> > >> </catchAll> >> </faultHandlers> >> <compensationHandler> >> <compensate scope="a"> >> </compensationHandler> >> <sequence> >> <scope name="a"> >> ... >> </scope> >> <scope name="b"> >> ... >> </scope> >> <scope name="c"> >> ... >> </scope> >> </sequence> >> >> If so, it seems to me that parameterized compensation handlers are >> already needed. And this scenario is not very different from the >> proposed solution n. 4: >> >> <catchAll> >> <compensate scope="a"> >> <compensate /> <!-- default compensation --> >> </catchAll> >> >> I do think we should open this issue. >> >> I would volunteer that one possible solution to this problem could be >> > to > >> (conditionally) raise a fault if the reverse order invariant is >> > broken. > >> >> Best regards, >> Alexandre >> >> -----Original Message----- >> From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] >> Sent: Tuesday, September 27, 2005 10:48 AM >> To: chris.keller@active-endpoints.com >> > <mailto:chris.keller@active-endpoints.com>; Yuzo Fujishima; > >> wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org> >> Subject: RE: [wsbpel] Issue - 229 - Fault handling and compensation >> handling allows selective compensation of child scopes >> >> I think I disagree with the premise of this issue, that a change is >> needed in this area. >> >> The default behaviour, as I recall, is that the compensation handlers >> > of > >> children will be processed in reverse order of scope processing. >> >> This facility allows an override, to permit selective and partial >> reversals. >> >> If this is removed then the process designer is forced to create >> > shared > >> state to parameterize compensation handlers such that they know the >> context in which they have been called, which is more fragile, >> error-prone and difficult to code than allowing parental dictation. >> >> Unless I am missing something, there is no compulsion to use this >> feature. It seems like a useful facility, and a case of caveat emptor. >> >> Alastair >> >> -----Original Message----- >> From: Chris Keller [mailto:chris.keller@active-endpoints.com] >> Sent: 27 September 2005 16:45 >> To: 'Yuzo Fujishima'; wsbpel@lists.oasis-open.org >> > <mailto:wsbpel@lists.oasis-open.org> > >> Subject: RE: [wsbpel] Issue - 229 - Fault handling and compensation >> handling allows selective compensation of child scopes >> >> Hi Yuzo, >> >> Interesting suggestion. >> >> I have one question on your option. If a user creates a catch block >> > for > >> a >> fault or a compensation handler that doesn't use <compensate/> will >> compensation handling of child scopes be done before or after the >> > user's > >> code or not at all? >> >> One disadvantage of the suggestion is that if you have invokes not in >> > a > >> scope of their own (or declaring a compensation handler of its own) >> > then > >> the >> user may need to interleave its compensation with that of child >> > scopes. > >> That >> requires the user to dictate the order of compensation which would be >> prohibited by this option. Of course we could say the user must add a >> compensation handler directly to the invoke itself for appropriate >> interleaving with child scopes, which is probably the lesser of evils. >> >> - Chris >> >> -----Original Message----- >> From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] >> Sent: Monday, September 26, 2005 9:32 PM >> To: wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org> >> Subject: Re: [wsbpel] Issue - 229 - Fault handling and compensation >> handling >> allows selective compensation of child scopes >> >> Chris, >> >> I would like to propose the fifth option: >> >> 5. Disallow specifying the target scope for the compensate activity. >> I.e., legal: <compensate/> >> illegal: <compensate scope="...*/> >> Have the compensation handler of the scope, not the caller, >> decide whether the compensation should be done. >> >> Rationale: >> >> I think the source of the problem is that >> the current specification makes the caller of the compensation >> > handlers > >> decide which scopes should be compensated while only each scope's >> compensation handler knows how and if compensation needs to be done. >> >> Yuzo >> >> ws-bpel issues list editor wrote: >> >> >>> This issue has been added to the wsbpel issue list with a status of >>> "received". The status will be changed to "open" if a motion to open >>> >>> >> the >> >> >>> issue is proposed and that motion is approved by the TC. A motion >>> >>> >> could >> >> >>> also be proposed to close it without further consideration. Otherwise >>> >>> >> it >> >> >>> will remain as "received". >>> >>> The issues list is posted as a Technical Committee document to the >>> >>> >> OASIS >> >> >>> WSBPEL TC pages <http://www.oasis-open.org/apps/org/workgroup/wsbpel> >>> >>> >> on >> >> >>> a regular basis. The current edition, as a TC document, is the most >>> recent version of the document entitled ** in the "Issues" folder of >>> >>> >> the >> >> >>> WSBPEL TC document list >>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - >>> > > >>> the next posting as a TC document will include this issue. The list >>> editor's working copy, which will normally include an issue when it >>> > is > >>> >>> >> >> >> >>> announced, is available at this constant URL >>> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. >>> >>> >>> Issue - 229 - Fault handling and compensation handling allows >>> selective compensation of child scopes >>> >>> *Status:* received >>> *Date added:* 26 Sep 2005 >>> *Categories:* Compensation <#category_compensation> >>> *Date submitted:* 21 September 2005 >>> *Submitter:* Chris Keller <mailto:chris.keller@active-endpoints.com> >>> *Description:* Currently fault handling and compensation handling >>> >>> >> allows >> >> >>> users to selectively compensate work done by child scopes. This can >>> >>> >> lead >> >> >>> to errors in the process especially as users change their processes >>> >>> >> over >> >> >>> time. In addition it does not seem to be in the spirit of the BPEL >>> >>> >> fault >> >> >>> handling and compensation handling model in general (as well as good >>> modular programming practice). Take the following example: >>> >>> <scope name="root"> >>> <faultHandlers> >>> <catchAll> >>> <compensate scope="a"> >>> </catchAll> >>> </faultHandlers> >>> <compensationHandler> >>> <compensate scope="a"> >>> </compensationHandler> >>> <sequence> >>> <scope name="a"> >>> ... >>> </scope> >>> <scope name="b"> >>> ... >>> </scope> >>> <scope name="c"> >>> ... >>> </scope> >>> </sequence> >>> >>> If a fault is caused by scope "c" the catchAll will only compensate >>> >>> >> "a" >> >> >>> leaving "b" uncompensated. Let's assume programmer 1 created the >>> >>> >> process >> >> >>> and didn't bother to compensate "b" since "b" at that time didn't do >>> >>> >> any >> >> >>> real work. Now programmer 2 picks up that process later and adds real >>> > > >>> work and a compensation handler for it to scope "b" not realizing >>> > that > >>> >>> >> >> >> >>> the catchAll will not compensate "b" and that the work will not be >>> compensated. >>> >>> Additionally if the real work added to scope "b" was accomplished by >>> programmer 2 by adding a child scope "b1" to "b". Programmer 2 >>> > looking > >>> >>> >> >> >> >>> at scope "b" may think that default compensation handling is in place >>> > > >>> and feel safe that their new work will be compensated. Not realizing >>> that the scope "root" has selectively chosen not to compensate "b" >>> > and > >>> >>> >> >> >> >>> thereby "b1" in the process. >>> >>> Possible solutions: >>> >>> 1. After user defined fault handling and compensation handling is >>> executed default handling will execute to compensate all other >>> completed child scopes left uncompensated. >>> 2. If after user defined fault handling and compensation handling >>> >>> >> is >> >> >>> executed there remains child scopes that have not been >>> >>> >> compensated >> >> >>> throw an bpws:missingCompensation exception. >>> 3. Do nothing and say selective compensation is legal and good. >>> > And > >>> add a note that users should take care when changing business >>> processes to ensure that user defined fault handling and >>> compensation handling call compensate on the child scopes >>> >>> >> correctly. >> >> >>> 4. Same as 3 with one exception after a user calls <compensate >>> name="..."> allow them to call <compensate/> which will >>> >>> >> compensate >> >> >>> all remaining child scopes in the default order. This would >>> require changing the following text at the end of section >>> >>> >> 13.3.3: >> >> >>> "Note that the <compensate/> activity in a fault or >>> > compensation > >>> handler attached to scope S causes the default-order invocation >>> >>> >> of >> >> >>> compensation handlers for completed scopes directly nested >>> >>> >> within >> >> >>> S. The use of this activity can be mixed with any other >>> user-specified behavior except the explicit invocation of >>> <compensate scope="Sx"/> for scope Sx nested directly within S. >>> Explicit invocation of compensation for such a scope nested >>> >>> >> within >> >> >>> S disables the availability of default-order compensation, as >>> expected." >>> >>> >>> *Changes:* 26 Sep 2005 - new issue >>> >>> To comment on this issue (including whether it should be accepted), >>> please follow-up to this announcement on the >>> >>> >> wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org> >> >> >>> list (replying to this message should automatically send your message >>> >>> >> to >> >> >>> that list), or ensure the subject line as you send it *starts* "Issue >>> >>> >> - >> >> >>> 229 - [anything]" or is a reply to such a message. If you want to >>> formally propose a resolution to an open issue, please start the >>> >>> >> subject >> >> >>> line "Issue - 229 - Proposed resolution", without any Re: or similar. >>> >>> To add a new issue, see the issues procedures document (but the >>> >>> >> address >> >> >>> for new issue submission is the sender of this announcement). >>> >>> Choreology Anti virus scan completed >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> > OASIS > >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > >> >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]