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


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
.









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