[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
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]