[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 229 - Fault handling and compensation handling allows selective compensation of child scopes
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]