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.2 - Proposal For Vote

Hi Ivana, I would like to propose a simplification of this resolution
proposal for 6.2 (as shown below; this basically folds the "branches"
element into the completion condition as well). This could be considered an
amendment (hopefully friendly :-) of your proposal.
Kind Regards


In this proposal, just an optional completionCondition element is added to
a flow. It contains a boolean expression. The boolean expression is
evaluated each time a directly nested activity finishes. If the boolean
expression evaluates to true, the remaining running activities in the flow
are terminated (as described in 13.4.4. Semantics of Activity Termination).

<flow standard-attributes>    standard-elements
    <completionCondition expressionLanguage="anyURI"?>
        ... boolean-expression ...
    <links>?        <link name="ncname">+    </links>    activity+

In order to provide the "N out of M" termination semantics, the boolean
condition may use the XPath extension function
bpws:getTerminatedActivities() to determine the number of directly nested
activities that have already terminated.

        bpws:getTerminatedActivities() >= 3

             <ivana.trickovic@                                          To
             sap.com>                  <wsbpel@lists.oasis-open.org>   
             01.04.2005 22:07                                          
                                       [wsbpel] Issue 6.2 - Proposal For

The current semantics of the flow activity is that it completes when all
its (directly) nested activities have completed, either successfully or
unsuccessfully. However, there are scenarios where it is necessary to
have ability to complete the flow activity before all its nested
activities complete in order to speed up the process execution. For
example, a process waits in parallel for 3 reviews of a paper. If 2
positive reviews are received the process may continue with the
execution without waiting for the last, third response.

The completion condition of may have the following flavors:
* Wait for N out of M nested activities to complete
* Wait until after boolean condition C evaluates to true

The completion condition is interesting for a flow activity enclosing
identical nested activities and for the parallel for-each activity
(still under discussion).



<flow standard-attributes>
         <link name="ncname">+

      <branches expressionLanguage="URI"?
      <booleanExpression expressionLanguage="URI"?>


(1) The completionCondition element is an optional element of the flow
activity. Default behavior of the flow activity is that it waits for all
its nested activities to complete.

(2) There are two kinds of completion condition:
A> <booleanExpression>: A boolean condition operating upon process
variables. It is evaluated at the end of execution of each nested
B> <branches>: An integer value expression which is used to define
condition of flavor N out of M. It is evaluated at the end of execution
of each nested activity. This condition has "at least N out of M"
semantics. (The exact N out of M condition semantics involve resolving
racing condition among nested activities.)

(3) Both conditions (<branches> and <booleanExpression>) may be
specified at the same time. They will be evaluated at the end of
execution of each nested activity. If at least one condition evaluates
to true the <flow> activity completes successfully terminating all
remaining running nested activities. If both conditions are specified,
the <branches> will be evaluated first. If the boolean condition is
specified the evaluation of the condition is done in a serialized
fashion with respect to the nested activities directly enclosed in the
flow activity.

(4) If the integer value evaluated from the <branches> expression is
larger than the number of nested activities in the <flow>, 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. (E.g. when the branches expression is a

(5) <branches> expression 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

(6) If flow activity specifies a completionCondition element the
completion condition is evaluated each time a nested activity completes.
If the completion condition evaluates to true the flow activity
completes successfully. All still running nested activities will be

(7) Standard BPEL termination semantics applies to running nested
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

(8) If all nested activities of the flow activity have been completed
but the completion condition evaluates to false the
"bpws:completionConditionFailure" MUST be thrown by the flow activity.



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in

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