[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 6.2 - Proposal For Vote
What is the intended meaning of completed activity? Suppose the activity nested in a <flow> is a <scope> and the <scope> internally faults but the fault is caught and supppressed, i.e., from the <flow> point of view the <scope> activity completed. Does it count? What I am trying to get at is that completion is almost always a fairly subtle concept. There are examples that involve measures rather than branch counting -- for imnstance I got enough supplies committed (adding up the supplies committed in each "completed" branch) which is a different kind of counting. I am sceptical that a specialized branch counting feature is worth the trouble of adding it. ________________________________ From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Tue 5/31/2005 9:12 PM To: dieterkoenig@de.ibm.com Cc: Trickovic, Ivana; wsbpel@lists.oasis-open.org; Alex Yiu Subject: Re: [wsbpel] Issue 6.2 - Proposal For Vote Hi DK, Thank you for your feedback on this proposal. [1] I just remind people that we should try to tackle 6.3 and 6.4 first before proceeding to 6.2. Because those new two subissues are necessary foundation and clarification for early completion. [2] Few explanatory notes on the current proposal: * When I was designing the 6.2 together with Ivana, I intentionally added the "countCompletedBranchesOnly" attribute to differentiate a successfully completed <scope> branch vs a faulted-then-exited <scope> branch. (Using that to achieve similar goals of <ignoreFault> idea from Ivana) * That implies, I personally still expect that all branches are scope-based when <branches> condition is used, even after we say "yes" to "partial termination of a scope" in 6.3. That needs static analysis reinforcement. * **If** we want to change from <branch> construct to a number-based XPath function, we should have two versions of functions as well to keep differentiation feature. [ e.g. bpws:countCompletedBranches() vs bpws:countFinishedBranches() ]. And, we need to detect usage of those branch-counting functions within any XPath expression and: * ban any usage outside completion condition (... ? ... to avoid the ambiguity in the case of nested early-completion <flow> ) * when used within completion condition, we need to enforce all branches are scope-based. * However, I have some hesitation moving from a BPEL <branches> construct to an XPath function. Because: * Currently, we enforce both static time analysis and runtime error checking of bpws:invalidBranchCondition Say, we have 5 branch in total and varX = 10: <completionConditon> bpws:countCompletedBranches() > $varX </completionCondition> The above XPath problematic expression would be tougher for us to detect. It can be detected only when we can intercept the ">" or ">=" execution in XPath. Also, people may try to use those XPath functions in a funky way. <completionConditon> not (foo:bar(bpws:countCompletedBranches())) </completionCondition> These cases make the above error detection much more difficult. * Currently the <branches> semantics are AT-LEAST N branches, NOT EXACTLY N branches. People may misuse the XPath function as follows (saying we have 5 branch in total): <completionConditon> bpws:countCompletedBranches() = 3 </completionCondition> This condition may be able to be evaluated to true at runtime, if people are lucky enough. And, if it is evaluated to true at runtime, it may give users a false impression that we are having an EXACT-N-branch semantics. I guess this is the classical trade-off between flexibility of features and whether we can trust users would not screw themselves up. Even though I have hestitation, it would be good to hear more discussion on this trade-off during F2F. Thanks! Regards, Alex Yiu Dieter Koenig1 wrote: 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 DK =============================================== 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> <completionCondition expressionLanguage="anyURI"?> ... boolean-expression ... </completionCondition>? <links>?</flow> 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. Example: <completionCondition> bpws:getTerminatedActivities() >= 3 </completionCondition>? "Trickovic, Ivana" <ivana.trickovic@ To sap.com> <wsbpel@lists.oasis-open.org> <mailto:wsbpel@lists.oasis-open.org> cc 01.04.2005 22:07 Subject [wsbpel] Issue 6.2 - Proposal For Vote Motivation =========== 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). Proposal ========= Syntax: <flow standard-attributes> standard-elements <links>? <link name="ncname">+ </links> <completionCondition>? activity+ </flow> <completionCondition> <branches expressionLanguage="URI"? countCompletedBranchesOnly="yes|no"?> an-integer-expression </branches>? <booleanExpression expressionLanguage="URI"?> a-boolean-expression </booleanExpression>? </completionCondition> Semantics: (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 activity. 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 constant.) (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 only. (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 terminated. (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 Termination). (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. (end) ---------------- Ivana --------------------------------------------------------------------- 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 OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- 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 OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]