Peter,
I think you are actually saying that compensate could be useful in all forward work, not just in completion handlers. Am I right?
Satish
-----Original Message-----
From: Furniss, Peter [mailto:]
Sent: Monday, September 20, 2004 4:05 AM
To: Satish Thatte; Frank Leymann; wsbpeltc
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:]
> 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:]
> 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:]
> 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:]
> 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" <>
> 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.
>
>
