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] 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]