Next in thread →
Next in month →
Re: [wsbpel] request to open sub issue 6.3 and 6.4
Hi Yaron, Issue 6.3 tries to address the fundamental question: whether a flow branch can be terminated without using the termination of the whole enclosing scope to make it happen it translates into whether we must have a scope-based activity inside a <flow> where the early-completion is enabled. We really need that "yes/no" clarification for "partial termination of a scope". Either "yes" or "no" is fine to me personally. However, people are having different interpretations of the spec as of this moment, which is bad. And, of course, if the answer is "yes", we need to provide supplementary text (as suggested in my email) to explain what actually happens in the case. if the answer is "no", we need to clear state that in the spec also. A past email thread to refresh people's memory: http://lists.oasis-open.org/archives/wsbpel/200504/msg00061.html Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: I must admit that I am unclear as to what problem issue 6.3 is addressing. Yaron Alex Yiu wrote: Hi, all, We discovered two "groundwork" issues that we need to resolve no matter whether we want to standardize "early completion" features in the spec. Those issues already exist in the spec as of today. Here I request to open two sub-issues: * Issue 6.3 - "Partial Termination of a Scope" o One question was highlighted when we were discussing whether an early-completion-enabled <flow> must use <scope>-based activities as branch activities. That question can be translated into whether we actually allow a "partial termination of a scope". The spec does not have a clear "yes" or "no" answer as of this moment. Regardless of whether we standardize early completion features or how early completion features look like, we must answer that "yes/no" question and add clarification accordingly. * Issue 6.4 - "Concurrency and Expression Evaluation" o During discussion of Issue 6.*, someone expressed the concern of potential racing condition situation for <completionConditon>. Yes, there would be potential racing conditions. However, by thinking it deeper, racing condition actually apply to ALL expressions evaluation under a <flow>, whenever data underlying expressions are mutable. Racing-related expressions include any boolean condition (e.g. a <while> or if-then-else boolean condition). The more interesting case is transition conditions of control links, which actually can be used to emulate some of <completionCondition> functionality in some cases and face a similar racing condition problem. The suggested changes in attached document will serve as proposals to Issue 6.3 and 6.4. Thanks! Regards, Alex Yiu ------------------------------------------------------------------------ "Groundwork" Issues related to Early Completion Last modified: May 31, 2005 - 11 am PDT We discovered two "groundwork" issues that we need to resolve no matter whether we want to standardize "early completion" features in the spec. Those issues already exist in the spec as of today. [I] Partial Termination of a Scope Summary One question was highlighted when we were discussing whether an early-completion-enabled <flow> must use <scope>-based activities as branch activities. That question can be translated into whether we actually allow a "partial termination of a scope". The spec does not have a clear "yes" or "no" answer as of this moment. Regardless of whether we standardize early completion features or how early completion features look like, we must answer that "yes/no" question and add clarification accordingly. Actual Changes [a] Assuming we take Satish's interpretation of the spec which allows the "partial termination of scope". In Section "13.4.4. Semantics of Activity Termination" After the paragraphs of scope-termination description: ------------------------- Scopes provide the ability to control the semantics of forced termination to some degree. ... ... Forced termination of nested scopes occurs in innermost-first order as a result of the rule (stated above) that the termination handler is run after terminating all activities (including scope activities) directly enclosed within its associated scope that are currently active. ------------------------- ADD the following paragraphs: ------------------------- An activity is typically terminated through its directly enclosing scope resulted from executing the fault handler of an ancestor scope. It is noteworthy that WS-BPEL DOES allow that an activity is terminated directly without going through its directly enclosing scope. This enable a finer-grain process logic termination through either a business process managment tool (outside of the scope of this specification) or a programmatic construct applied to WS-BPEL code (e.g. an early completion mechanism.) This termination situation is termed as "partial termination of a scope". When such a situation happens, the termination handler of the scope will NOT be necessarily triggered. If there are still other active concurrent activities running within the enclosing scope, the termination handler of the scope would NOT be triggered. Vice versa, if the activity being terminated is an activity of the last / only active flow within the enclosing scope, the termination handler of the scope would be triggered. ------------------------- [AYIU: Side note: even though we mention the term "early completion", it does not have any implication whether we pass Issue 6.2 or not.] [b] If we do not want to allow "partial termination of a scope", we will ADD the following paragraph instead: ------------------------- An activity can ONLY be terminated through its directly enclosing scope (typically resulted from executing the fault handler of an ancestor scope). An individual non-scope-based activity cannot be terminated without having its enclosing scope being faulted or terminated. ------------------------- [II] Concurrency and Expression Evaluation Summary: During discussion of Issue 6.*, someone expressed the concern of potential racing condition situation for <completionConditon>. Yes, there would be potential racing conditions. However, by thinking it deeper, racing condition actually apply to ALL expressions evaluation under a <flow>, whenever data underlying expressions are mutable. Racing-related expressions include any boolean condition (e.g. a <while> or if-then-else boolean condition). The more interesting case is transition conditions of control links, which actually can be used to emulate some of <completionCondition> functionality in some cases and face a similar racing condition problem. Hence, this racing condition problem is actually a generic one that we need to solve regardless whether we have early completion features. I propose to extend the semantics of Issue 166 from just covering <assign> to expression evaluation as well: http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue166 Rationale: The rationale is the same as Issue 166. Consider this example: <flow name="f1"> <scope name="s1" isolated="yes"> <flow name="f2"> <while name="loop1"> <condition> ($creditLine > $poAmt and pf:creditScore($buyerID) > 600) or $poAmt < 10000 </condition> ... </while> <while name="loop2"> ... </while> </flow> </scope> <scope name="s2" isolated="yes"> ... </scope> </flow> If we don't apply the requirement of "as-if-only-logic-being-executed" to expression evaluation, we may face a situation where the boolean condition of <while> is evaluated in an interweaved fashion. The evaluation is based more than parts of more than one versions of snapshot along the timeline. The evaluation may not be true at all at any particular points of timeline. Given the restriction of nested isolated scopes, we do not have appropriate tools to avoid such a situation without extending Issue 166 here. Actual Changes: Change the title of Section 14.3: FROM: --------------------- 14.3. Assignment --------------------- TO: --------------------- 14.3. Assignment and Execution of Expression and Query --------------------- After the following paragraph in Section 14.3: ------------------------- The second extension defines the behavior of assignment in the presence of failure during execution. The assign activity is treated as if it were atomic. This means that the assign activity MUST be executed as if, for the duration of its execution, it was the only activity in the process being executed. The mechanisms used to implement the previous requirement are implementation dependent.An important characteristic of assignment in BPEL4WSWS-BPEL is that assignment activities are atomic. If there is any fault during the execution of an assignment activity, the destination variables are left unchanged as they were at the start of the activity. This applies regardless of the number of assignment elements within the overall assignment activity. ------------------------- ADD a new paragraph: ------------------------- Similar to an assign activity, the expression or query used in a WS-BPEL activity (e.g. the boolean condition expression in <while>) MUST be executed, as if, for the duration of execution of expression or query, it was the only piece of logic in the WS-BPEL process being executed. ------------------------- END ------------------------------------------------------------------------ --------------------------------------------------------------------- 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
Next in thread →
Next in month →