[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] request to open sub issue 6.3 and 6.4
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]