[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. This restriction MUST be enforced by static analysis. (2) <branches> is 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 directly enclosed activity. This condition has "at least N out of M" semantics. (The exact N out of M condition semantics involve resolving racing condition among directly enclosed activities.) (3) If the integer value is larger than the number of directly enclosed activities, 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) ---------------- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]