[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] RE: Issue - 207 - Revised description
There are actually three parts to this issue. 1. The naming of the <compensate/> activity (with no scope name) which violates the statement that a <compensate> action can only be used in an enclosing fault or compensation handler. Easy to fix: rename. 2. The use of <compensate/> in a compensation handler. Here we have exactly the default compensation behavior for a completed scope, no confusion. 3. The use of <compensate/> in a fault handler. Here we have the *partial* default compensation behavior for a non-completed scope, hence confusion. This is the one Yaron is trying to address. Can we defer 3 until I get back? Call it 10.1. Satish -----Original Message----- From: Frank Leymann [mailto:Frank.Leymann@informatik.uni-stuttgart.de] Sent: Saturday, June 18, 2005 6:18 AM To: ygoland@bea.com Cc: wsbpel@lists.oasis-open.org Subject: AW: [wsbpel] RE: Issue - 207 - Revised description Compensation is enabled for completed scopes only. A faulted scope cannot be compensated itself, because it is not completed, i.e. the work done inside of it is only partially performed. But its associated fault handler can try to fix the situation and if it cannot fix, try to semantically undo the partially performed work, e.g. by running the compensation handlers of its nested scopes that have been completed. Why do you think this is confusing? Gruss / Regards Frank Leymann -----Ursprüngliche Nachricht----- Von: Yaron Y. Goland [mailto:ygoland@bea.com] Gesendet: Freitag, 17. Juni 2005 18:52 An: dieterkoenig@de.ibm.com Cc: wsbpel@lists.oasis-open.org Betreff: Re: [wsbpel] RE: Issue - 207 - Revised description The issue is how does one view a default compensation handler. The spec requires that when calling <compensate/> from inside of a fault handler the resulting behavior be exactly, in every possible way, identical to what would happen if the scope had successfully completed, had only a default compensation handler defined on it and that scope was then compensated. What I'm arguing is that the spec's way of describing the issue is hopelessly confusing. I believe it would be much more straight forward to just state that when a scope is created a default compensation handler is placed on that scope. This change in model has, near as I can tell, no change on our actual behavior but it makes everything else we say much clearer. Yaron Dieter Koenig1 wrote: > Sorry, but I am completely lost. I am not clear where the notion of > (a) creating a default compensation handler when a scope is created > (b) invoking a scope's own compensation handler with <compensate/> > have been introduced. > > Can you point me to a corresponding issue resolution? Please ignore this > mail if I missed such a change. > > > Otherwise, corresponding terminology in 207 and the complete issue 217 is > just not applicable and should be removed. > > > The spec currently defines: > > 13.3.3. Invoking a Compensation Handler > "(...) This activity can be used only in the following parts of a business > process: > - In a fault handler of the scope that ***immediately encloses*** the > scope for which compensation is to be performed. > - In the compensation handler of the scope that ***immediately > encloses*** the scope for which compensation is to be performed. > (...) > (...) The <compensate/> form, in which the scope name is omitted in a > compensate activity, causes the default compensation ***behavior*** for the > current scope to be invoked explicitly. (...) 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." > > ==> compensate ***never*** calls the compensation handler of its own scope. > > 13.4.1. Implicit Fault and Compensation Handlers > "(...) Compensation handler: Run all available compensation handlers for > all directly and indirectly enclosed scopes in any order consistent with > the rules for default compensation order defined below. Note that a > compensation handler is available for a scope exactly when that scope has > completed successfully" > > ==> this applies to all compensation handlers -- explicit and implicit -- > there is no language about compensation handlers being created at scope > creation time. > > > I assume we agree that > <compensationHandler> > <compensate/> > </compensationHandler> > means that all installed compensation handlers of directly nested scopes > are executed. Exactly the same behavior applies when <compensate/> appears > in <catch>, <catchAll>, or <terminationHandler>. > > > Kind Regards > DK > > > > > "Yaron Y. Goland" > <ygoland@bea.com> > To > 07.06.2005 00:23 Dieter Koenig1/Germany/IBM@IBMDE > cc > "Furniss, Peter" > Please respond to <Peter.Furniss@choreology.com>, > ygoland wsbpel@lists.oasis-open.org > Subject > Re: [wsbpel] RE: Issue - 207 - > Revised description > > > > > > > > > > > The way I look at it when foo was created so was its default > compensation handler. What was not created was foo's custom compensation > handler (if any). When a fault was thrown this guaranteed that foo's > custom compensation handler (if any) would never be installed. But the > throwing of the fault in foo did nothing to foo's default compensation > handler. > > Once inside of the catchAll the call to <compensate> causes foo's > default compensation handler to be invoked. It is then foo's default > compensation handler which is responsible for calling all of foo's child > scopes (if any) and activating their compensation handlers (if any). > > In my mind there is a fundamental difference between the default and > custom compensation handlers. The former always exists from the instant > the scope is created while the later is only installed if the scope > exits successfully. > > Yaron > > > Dieter Koenig1 wrote: > > I am confused by this one. In your example: > > > > scope name="foo" > > faultHandlers > > catchAll > > compensate > > ... > > > > the compensate activity invokes compensation handlers of scopes nested > > inside of "foo", not the compensation handler of "foo" itself. > > > > In particular, as a fault handler of "foo" is running, the scope "foo" > will > > terminate abnormally and will not even have its compensation handler > > installed. > > > > Kind Regards > > DK > > > > > > > > > > > "Yaron Y. Goland" > > > <ygoland@bea.com> > > > > To > > 23.05.2005 22:47 "Furniss, Peter" > > > <Peter.Furniss@choreology.com> > > > > cc > > Please respond to wsbpel@lists.oasis-open.org > > > ygoland > Subject > > Re: [wsbpel] RE: Issue - 207 - > > > Revised description > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My understanding of BPEL's existing semantics require that fault > > handlers be able to call the default compensation handler of the same > > scope the fault handler is defined on. > > > > scope name="foo" > > faultHandlers > > catchAll > > compensate > > ... > > > > The call to compensate will call "foo"'s default compensation handler. I > > agree, btw, that the spec's existing language make this situation at > > best 'ambiguous'. That's part of the motivation of 207, to make it > > absolutely clear. > > > > But in general your conclusion is the same as mine - whatever the > > resolution to these issues there are clearly ambiguities here. By > > opening the issue we only agree as to the existence of the ambiguities, > > not necessarily their resolution. > > > > Yaron > > > > > > Furniss, Peter wrote: > > > ok, on re-reading very carefully, you aren't quite suggesting what I > > > thought you were - that a handler in scope A could fire the > compensation > > > handler for scope A. Except you are, in the assertion that <compensate > > > /> in a fault handler runs the default compensation handler. And then > > > find yourself in contradiction to the rule that compensation handlers > > > are only installed on successful completion of their scope. > > > > > > This would seem to be more easily coped with by saying that > > > <compensate/> performs the compensations, but does not trigger the > > > default handler - i.e. it is another way of doing the same thing, but > > > isn't the same packaging. > > > > > > But most of the issue is concerned with sorting out what happens if a > > > handler contains a scope, with compensation handler, which I'm not > sure > > > is necessarily the related to <compensate /> in handlers. It might be > > > simpler to deem the handler to be scope in its own right. Or ban inner > > > scopes in handlers ? or handlers in handlers. > > > > > > But these are resolutions of the issue, which hasn't been accepted > yet. > > > I do agree (now) that both cases could be clarified, so I think the > > > issue should be accepted. > > > > > > Peter > > > > > > > > > > -----Original Message----- > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > Sent: 19 May 2005 18:55 > > > > To: Furniss, Peter > > > > Cc: wsbpel@lists.oasis-open.org > > > > Subject: Re: [wsbpel] RE: Issue - 207 - Revised description > > > > > > > > > > > > I'm not sure what you mean. Today it is legal and appropriate > > > > to use the > > > > compensate activity from inside of a fault handler. I've > > > > reviewed this > > > > mail twice and I'm still not clear as to your concern. > > > > > > > > Could you please give a short example of something that you think > is > > > > illegal in the spec today that this issue would now make > > > > legal that is > > > > causing you concern? > > > > > > > > Thanks, > > > > > > > > Yaron > > > > > > > > > > > > Furniss, Peter wrote: > > > > > Looking at the substance of this proposed issue, it seems to be > > > > > proposing a > > > > > rather different model from the existing one. Surely the > > > > existing model is > > > > > that, until a scope exits, anything that it has done but > > > > that will need > > > > > unwinding in the event of fault has to be coped with by the > > > > fault handler; after > > > > > the scope has exited, it is the responsibility of that > > > > scope's compensation handler. > > > > > > > > > > There will be cases where some more sophisticated pattern > > > > might seem > > > > > more > > > > > convenient - if scope B does operation b1, then b2, then > > > > b3, all directly in B, > > > > > then the fault handler may need to know if b2 has been done > > > > to work out if it > > > > > must undo it. The solution of course is to put the > > > > operations each in its own > > > > > scope, in which case B can leave it to the default fault > > > > handler to undo things > > > > > backwards, but only of the things that have finished. > > > > > > > > > > The issue does raise some questions of what happens if a > > > > compensation > > > > > handler > > > > > itself contains a scope. > > > > > > > > > > > > > > > Peter > > > > > > > > > > ----------------------------------- > > > > > Chief Scientist > > > > > Choreology Ltd > > > > > 68 Lombard Street, London EC3V 9LJ, UK > > > > > web: www.choreology.com > > > > > mobile: +44 7951 536168 > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]