[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 6 - Proposal for vote
Well, you could use <compensate/> in a completion handler to ensure exactly N of M by compensating nested scopes when there was a dead heat for the N'th place. More commonly, you could use <compensate/> if the completion criterion was something like "least number of offers with aggregate of 100 widgets" - or, more generally, where there are nested scopes that are good, but then the winning nested scope (or scopes) are better. Peter > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: 20 September 2004 05:44 > To: Frank Leymann; wsbpeltc > Subject: RE: [wsbpel] Issue 6 - Proposal for vote > > > Frank, > > Forcing completion of nested scopes as opposed to cancelling > them is an interesting thought -- we should consider it as a > possible amendment. > > I did not expect to allow completion handlers to use > <compensate/> since compensation is "reverse work". Do you > have a scenario in mind? > > Satish > > > -----Original Message----- > From: Frank Leymann > [mailto:Frank.Leymann@informatik.uni-stuttgart.de] > Sent: Sunday, September 19, 2004 2:03 AM > To: 'wsbpeltc' > Subject: AW: [wsbpel] Issue 6 - Proposal for vote > > Satish, > > In fact, this helped a lot - I have to admit that I was > interpreting too much into what you suggested not reading > your mail carefully enough. In drawing the analogy to > forcedTermation I was assuming that we are also going inbound > into a scope to be completed "forcing completion" of nested > scopes too, in addition to going up the stack. > > Any restrictions on custom completion handler, especially may > a custom completion handler use <compensate/>? > > Gruss / Regards > Frank Leymann > > > -----Ursprüngliche Nachricht----- > Von: Satish Thatte [mailto:satisht@microsoft.com] > Gesendet: Sonntag, 19. September 2004 09:58 > An: Frank Leymann > Cc: wsbpeltc > Betreff: RE: [wsbpel] Issue 6 - Proposal for vote > > Frank, > > The wording I am familiar with is "enclosing scope" for a > scope that surrounds the point of enclosure. I have not > heard the phrase "enclosed scope" before -- so I am not sure > what you have in mind. I suspect you don't mean "nested scope". > > All "active" (started but not yet completed) activities are > actually cancelled hence are not completed successfully. > This has been the approach of all the flow related proposals > as well. Not yet run activites are of course not run. The > only activities that are prematurely completed are the > enclosing scopes as stated below. > > By dead activities you must mean activities that experience a > join fault that is suppressed. But we have no special > semantics for this. They are simply activities that had a > surrounding scope that faulted before they were started, and > hence they were not executed. > > As I wrote below the completion handler is proposed to be a > part of the "forward work" hence actual completion of a scope > follows the execution of the completion handler. Yes, the > fault and compensation mechanics operate as usual during the > execution of the completion handler. > > Does that help? > > Satish > > ________________________________ > > From: Frank Leymann [mailto:LEY1@de.ibm.com] > Sent: Sat 9/18/2004 11:33 PM > To: Satish Thatte > Cc: wsbpeltc > Subject: Re: [wsbpel] Issue 6 - Proposal for vote > > > > > > > > Satish, > > I guess ENCLOSING in the phrase "...will cause premature but > successful completion of all ENCLOSING scopes..." has to be > changed into ENCLOSED scopes, correct? > > We have to specify which activities within the nested scopes > are set to "completed" state because this is important for > compensation: I assume all "active" activities as well as all > "not yet run" activities are set to "completed. What about > "skipped" (i.e. "dead") activities? We further have to > specify when that state change occurs in case of a > non-default completion handler - i.e. does the state change > happen before or after we enter the completion handler? > > The completion handler runs in the context of the scope it is > associated with. When it fails, I assume the standard fault- > and compensation mechanics applies - how are the completed > activities of the completion handler treated? > > Regards, > Frank > > > > > > > To: "wsbpeltc" <wsbpel@lists.oasis-open.org> > cc: > 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 > . > > > > > > > > > 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. > > > > > > 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. > > > 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]