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