Issue 6.2 - Updated Proposal For Vote

Below please find an updated proposal for issue 
6.2.

 

Kind regards,

 

Ivana

 

 

 

Issue 6.2: Updated proposal: 
Last modified: Sept 13, 2005 - 23:30 PDT 

Motivation 
===========

The current semantics of the flow 
activity is that it completes when all
its (directly) enclosed activities 
have completed, either successfully
or unsuccessfully. However, there are 
scenarios where it is necessary to
have ability to (successfully) complete 
the flow activity before all its
directly enclosed activities complete in 
order to speed up the process
execution. 

The completion condition may 
have different flavors:
(1) Wait for N out of M nested activities to 
complete
(2) Wait until after boolean condition C evaluates to 
true

This updated proposal is restricted to case (1). 

The 
completion condition is interesting for the flow activity and for
the 
parallel forEach activity.

Proposal 

=========

Syntax:

<flow 
standard-attributes>
	standard-elements
      
<links>?
         <link 
name="ncname">+
      
</links>
      
<completionCondition>?
      
activity+
</flow>

<forEach counterName="ncname" 
...>
     
standard-elements
     
<iterator>
        
<startCounterValue 
expressionLanguage="anyURI">
           
...
        
</startCounterValue>?
        
<finalCounterValue 
expressionLanguage="anyURI">
           
...
        
</finalCounterValue>?
     
</iterator>
     
<completionCondition>?
     
Scope
</foreach>

<completionCondition extension-attribute>      extension-element      <branches 
expressionLanguage="URI"?
		countCompletedBranchesOnly="yes|no"?>
          
an-integer-expression
      
</branches>
</completionCondition>

Semantics:

(1) 
The completionCondition element is an optional element of the flow
activity 
and the parallel forEach activity. Default behavior of the flow
activity and 
the parallel forEach activity is they wait for all their
directly enclosed 
activities to complete. Optional <completionCondition>
is applicable to parallel forEach only, and not serial 
forEach. Thisrestriction MUST be enforced by static analysis. 
(2) <branches> is an integer value expression 
which is used to definecondition of flavor N out of M. It is evaluated at the 
end of executionof each directly enclosed activity. This condition has 
"at least N outof M" semantics. (The exact N out of M condition 
semantics involveresolving racing condition among directly enclosed 
activities.)(3) If the integer 
value is larger than the number of directly enclosedactivities, then bpws:invalidBranchCondition fault 
MUST be thrown. Note
that the number of branches may be known only during 
runtime in some
cases. Static analysis should be encouraged to detect this 
erroneous
situation at design time when possible. (For example, when the 
branches
expression is a constant.)

(4) Element <branches> has 
an optional attribute
"countCompletedBranchesOnly". Its default value is 
"no". If
countCompletedBranchesOnly is "no", it means the BPEL processor 
will
count branches which have completed (either successfully 
or
unsuccessfully). If countCompletedBranchesOnly is "yes", it means 
the
BPEL processor will count branches which have completed 
successfully
only.

(5) If flow/parallel forEach activity specifies a 
completionCondition
element the completion condition is evaluated each time a 
directly
enclosed activity completes. If the completion condition evaluates 
to
true the flow/parallel forEach activity completes successfully. 
All
still running directly enclosed activities will be terminated. 
This
means that the flow/parallel forEach activity begins 
implicitly
terminating the directly enclosed activities that are still 
active.

(6) Standard BPEL termination semantics applies to running 
directly
enclosed activities when the completion condition is met. 
The
termination of running nested activities follows the 
termination
semantics defined in the specification (see section 13.4.4 
Semantics of
Activity Termination). 

(end)
----------------