[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 6 - Proposal for vote
On trying to work out an example, maybe it is less of a problem than I'd thought. But it requires some careful coding. If the nested scope that issues the <complete ../> is itself prematurely completed (cancelled), then it's own cancelHandler will be run, just like those of its "unsuccessful" (and still running) siblings. So the cancelHandler must avoid undoing anything that the nested scope has done as a result of its success. And obviously the nested scope can't do anything after <complete ../>. I now think the while .. break case is unlikely to be a problem, because there is only one nested scope (the i'th iteration of the while body) running at a time, and there is no special reason for it to have a cancelHandler. A parallel case (but using existing flow and copy-paste) might be: <scope name="findSomething"> <flow> <sequence name="one"> <cancelHandler> <invoke partnerLink="one" operation="stopLooking" ... /> </cancelHandler> <invoke partnerLink="one" operation="lookForThing" ... > <receive partnerLink="one operation="thingIsHere" inputVariable="answerone" ...> ... if answerone positive ... <assign> <copy> <from partnerLink="one" endpointReference="partnerRole"/> <to partnerLink="thingsHome" endpointReference="partnerRole"/> </copy> </assign> <complete scope="findSomething"> </sequence> .. similar sequence for two, three etc </flow> </scope> <!-- apologies for errors and any use of obsoleted constructs --> which probably works, assuming stopLooking can be sent (and will be ignored) if the answer thingIsHere has been received. Otherwise the cancelHandler has got to check. If the forward operations actually did something significant (like placing a reservation) that had to be undone in the cancelHandler of the unsuccessful attempts, it becomes even more important for the cancelHandler to know if it is supposed to be really undoing the work of this particular nested scope. Although it wasn't my intention when I started this, I seem to have produced a case where business Transaction management is needed - and cohesive transactions too. A BTM protocol would delegate the cancellation and sort out the collision cases. But not in this edition of BPEL. Peter > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: 20 September 2004 21:39 > To: Furniss, Peter; wsbpeltc > Subject: RE: [wsbpel] Issue 6 - Proposal for vote > > > Not sure I am following you. Perhaps a more detailed example > (or more than one) would help. > > -----Original Message----- > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > Sent: Monday, September 20, 2004 11:01 AM > To: Satish Thatte; wsbpeltc > Subject: RE: [wsbpel] Issue 6 - Proposal for vote > > Hmm. Doesn't prematurely completing the scope that fires > <complete ../> mean that > a typical while - break pattern that looped until it got the > right answer would have to make the successful iteration come > to a normal end, and then issue <complete > scope="scopeEnclosingWhile"> on the *next* iteration ? > > Works fine for continue. > > I'm not sure how to make N of M work > > Peter > > > > -----Original Message----- > > From: Satish Thatte [mailto:satisht@microsoft.com] > > Sent: 20 September 2004 16:25 > > To: Furniss, Peter; wsbpeltc > > Subject: RE: [wsbpel] Issue 6 - Proposal for vote > > > > > > Peter, > > > > Yes to the semantics of "cancelled". > > > > The scope that fires <complete ../> is the first to be prematurely > > completed, and in fact the only one when the minimal form > > <complete/> is used (scope name omitted). > > > > Satish > > > > > > -----Original Message----- > > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > > Sent: Monday, September 20, 2004 4:05 AM > > To: Satish Thatte; wsbpeltc > > Subject: RE: [wsbpel] Issue 6 - Proposal for vote > > > > I think I like this. > > > > But isn't the nested scope that fires the <complete > > scope="ancestralScope"> still itself incomplete ? So it will get > > caught in the cancellation. Or is it specially protected > > - so "all concurrently running activities in that scope will > > be cancelled" should have added something like "except for > > the nested scope which generated the completion (at any depth > > of nesting)". Otherwise the successful nested scope will get > > cancelled just like its unsuccessful siblings. > > > > (I'm assuming "cancelled" is following the rough consensus emerging > > on issue 135 as a rename of forcibly terminated) > > > > Peter > > > > > -----Original Message----- > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > Sent: 17 September 2004 18:20 > > > To: wsbpeltc > > > Subject: [wsbpel] Issue 6 - Proposal for vote > > > > > > > > > Please note that this proposal also subsumes Issue 142 as > > the examples > > > > > show. Also note that everyone involved in the discussion > of Issue 6 > > > has not had time to comment on the merits of this proposal > > relative to > > > > > alternatives. I am putting it up so that we can discuss > it at the > > > F2F. Early comments are always welcome. > > > > > > Proposal for resolution of both Issues 6 and 142. > > > > > > Define a new activity of the form <complete > > scope="ScopeName"?>. The > > > execution of this activity will cause premature but successful > > > completion of all enclosing scopes upto and including the > > scope named > > > in the optional scope attribute. In case the attribute > is omitted, > > > the default value of the attribute is the name of the nearest > > > enclosing scope. > > > > > > In case of premature but successful completion of a scope, all > > > concurrently running activities in that scope will be > cancelled. A > > > scope may optionally have a completion handler. A completion > > > handler is syntactically similar to a compensation handler (no > > > parameters). In case of premature but successful completion of a > > > scope the completion handler is run if > > present. The > > > default completion handler does nothing. The completion > > handler is run > > > > > in the context of the scope it is attached to, hence may > > use variables > > > > > and partnerLinks defined within that scope. > > > > > > The behavior of the completionHandler is treated as part of the > > > "forward work" of the scope. Thus all fault handlers for a > > scope are > > > still available while the completion handler for that scope is > > > running. In case of a fault in a completion handler, the > > behavior is > > > identical to the occurrence of a fault in the main body of > > the scope. > > > > > > Question: can the <complete/> activity be used in a > > completionHandler? > > > > > Or perhaps only in the named (final) one in a completion process? > > > > > > Rationale: This proposal defines a "break-like" feature > > following the > > > > > patterns of the rest of our interrupt machinery, e.g., fault and > > > cancel handlers. It is possible to use this to build declarative > > > macros for a variety of purposes including the various flow-based > > > features that were proposed. > > > > > > Examples: > > > > > > Break: > > > > > > Wrap a while loop with a scope S and use <complete scope="S"/> to > > > break from the loop. > > > > > > Continue: > > > > > > Wrap the body of a while loop with a scope S and use <complete > > > scope="S"/> to continue with the next iteration of the loop. > > > > > > At least N of M activities in a flow: > > > > > > <scope name="N-of-M"> > > > <completionHandler> > > > </completionHandler> > > > <flow> > > > .. > > > <sequence> > > > <original "activity that counts"> > > > <update completion count variable V> > > > <switch> > > > <case using V, N out of M done?> > > > <complete scope="N-of-M"/> > > > </case> > > > </switch> > > > </sequence> > > > ..other activities in flow > > > </flow> > > > </scope> > > > > > > Can we do exactly N of M using an isolation scope for the switch? > > > > > > Satish > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster > > > of the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > > > ave_workgroup.php. > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]