RE: [wsbpel] Issue 6 - Proposal for vote

["Satish Thatte" <satisht@microsoft.com>]

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:Peter.Furniss@choreology.com] 
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: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.
> 
>