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


On second thought I agree with Dieter - but it was an intriguing thought while it lasted :-)


 

-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] 
Sent: Monday, September 20, 2004 7:15 AM
To: Frank.Leymann@informatik.uni-stuttgart.de; Satish Thatte
Subject: RE: [wsbpel] Issue 6 - Proposal for vote





Frank and Satish, it seems to me that forcing completion of nested scopes instead of cancelling them creates a mixed situation that might be hard to explain. Some nested scopes would complete successfully (and their compensation handler gets enabled) while other nested activities deal with forcedTermination.
Kind Regards
DK



                                                                           
             "Satish Thatte"                                               
             <satisht@microsof                                             
             t.com>                                                     To 
                                       "Frank Leymann"                     
             20.09.2004 06:43          <Frank.Leymann@informatik.uni-stutt 
                                       gart.de>, "wsbpeltc"                
                                       <wsbpel@lists.oasis-open.org>       
                                                                        cc 
                                                                           
                                                                   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/leave_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/leave_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/leave_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/leave_workgroup.php
.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]