OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]