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] Issue 6.2 - Proposal For Vote


Requiring that all the children of the flows be scopes is just bizarre. 
If such contortions are needed to make this proposal work then I would 
humbly suggest that this proposal is not ready for approval.

		Yaron

Alex Yiu wrote:
> Hi all,
> 
> Ivana and I were still discussing an open technical issue about this 6.2 
> proposal. That is: whether branches of <flow> should be restricted to a 
> scope-based only when <completionCondition> / earlyCompletion is used.
> 
> However, since there is a Apr 1st deadline for proposal submission, it may be 
> better to submit the proposal on what was drafted so far without waiting to 
> resolve this open issue. And, let other people comment on this open issue.
> 
> Here is my detailed viewpoints and analysis we need a scoped-only restriction 
> when early completion is used:
> 
> ========================================================
> 
> Scope-based-only branches restriction for early completion is needed, because:
> 
>     * early completion mechanics does not change fundamentally regardless
>       whether we are using <complete> activity or <completionCondition>
>     * we need a scope to encapsulate activities of branch as _"units of work"_
>       to minimize the need of defining <completionHandler>
>     * a partial termination of a scope is NOT well-defined in BPEL, while
>       termination of the whole scope is already well-defined in BPEL spec.
> 
> 
> *_How termination mechanism works in BPEL: _*
> Here is my understanding of how the termination mechanism in BPEL works:  When a 
> scope is sent with a termination signal, the targeted scope will: (1) cascade 
> the termination signal inner child scopes (2) stop all the inner activities 
> within the targeted scope (3) execute the termination handler. Then, done.
> 
> As of now, the termination signal MUST alway go through a scope to other 
> NON-scope activity. And, the termination Handler of the corresponding scope MUST 
> got activated.
> 
> Hence, termination of the whole scope is well defined. However, a partial 
> termination of a scope is NOT well-defined. That is we have not defined:
> 
>     * what should happen if some branches got terminated, while some branches
>       are completed.
>     * what should happen if the termination signal to sent to NON-scope
>       activities without going through a <scope>.
> 
> 
> *_Example #1_*
> 
> Consider the following, a flow with two sequence as branches, which is NOT 
> scope-based.
> 
> <scope name="A">
>     <flow>
>        <completionCondition> ... </completionCondition>
>        <sequence name="B1">
>            ...
>            <scope name="B1SS1"> ... </scope>
>            <receive name="B1R2" ... />
>            ...
>        </sequence>
>        <sequence name="B2">
>            ...
>            <scope name="B2SS1"> ... </scope>
>            <receive name="B2R2" ... />
>            ...
>        </sequence>
>     </flow>
> </scope>
> 
> Say, sequence "B2" finishes. The completionCondition is fulfilled.  Sequence 
> "B1" is being terminated when it is waiting a message at the receive "B1R2". 
> Now, we  got the following  questions _unanswered, if we don't want to invent a 
> brand variation of termination mechanism_:
> 
>     * Will the terminationHandler of scope "A" be activated?
>     * Should the compensation handler of scope "B1SS1" be invoked? Which
>       "handler" logic is responsible to determine that?
> 
> 
> Ok. Let's change it into scope-based branches.
> 
> <scope name="A">
>     <flow>
>        <completionCondition> ... </completionCondition>
>        <scope name="B1">
>            <terminationHandler> ... </terminationHandler>
>            <sequence>
>                ...
>                <scope name="B1SS1"> ... </scope>
>                <receive name="B1R2" ... />
>                ...
>            </sequence>
>        </scope>
>        <scope name="B2">
>            <terminationHandler> ... </terminationHandler>
>            <sequence>
>                ...
>                <scope name="B2SS1"> ... </scope>
>                <receive name="B2R2" ... />
>                ...
>            </sequence>
>        </scope>
>     </flow>
> </scope>
> 
> The above questions got _answered clearly, with reusing the current termination 
> mechanism easily_:
> 
>     * Will the terminationHandler of scope "A" be activated?
>           o No.
>     * Should the compensation handler of scope "B1SS1" be invoked? Which
>       "handler" logic is responsible to determine that?
>           o It is up to the terminationHandler to decide whether to invoke the
>             compensation handler of scope "B1SS1". By default, the
>             terminationHandler of scope "B1" will invoke that compensation handler.
> 
> 
> Hence, we minimize the need of "completionHandler". I hope I have refreshed your 
> memory on why we come up with this scope-based branches. (Regardless we use 
> <complete> activity or not).
> 
> 
> *_Example #2_*
> 
> One important to remember: <flow> only controls the parallelism of execution. It 
> does not interfere the compensation and termination structure of a process.
> 
> Without scope-based-branch only restriction, the net effect of a <flow> is just 
> a parallellized execution of activities inside the flow in an undeterministic 
> order. So, in one extreme case of this undeterministic order, one inner branch 
> got completed first and then the other inner branch got executed. Hence, one 
> extreme case of <flow> is equivalent to the following nested sequence pattern in 
> the context of compensation and termination. (I replace <flow> in exmple #1 with 
> an outter <sequence> ... You can also think of one control-link is used from 
> sequence "EX2B1" to "EX2B2").
> 
> --------------------------------
> <scope name="EX2A">
>     <sequence>
>        <sequence name="EX2B1">
>            ...
>            <scope name="EX2B1SS1"> ... </scope>
>            <receive name="EX2B1R2" ... />
>            ...
>        </sequence>
>        <sequence name="EX2B2">
>            ...
>            <scope name="EX2B2SS1"> ... </scope>
>            <receive name="EX2B2R2" ... />
>            ...
>        </sequence>
>     </sequence>
> </scope>
> --------------------------------
> 
> Say, the execution is waiting at receive "EX2B2R2". Now due to early completion, 
> we need to do this "partial" termination magic. We don't have a well-defined way 
> to terminate sequence "EX2B2" without affecting sequence "EX2B1". Similarly, we 
> don't have a well-defined way to terminate sequence "EX2B2" without affecting 
> "EX2B2SS1"
> 
> Now think again, if we have scope-based-only branches, all activities are 
> separated in units-of-work. Now those branches have independent compensation and 
> termination structure now.
> 
> Last not least, if we map this early completion idea to transaction world, it 
> does not seem like a good idea to allow partial transaction-work rollback 
> (mapped to termination & compensation) without any units-of-work boundary marker 
> or checkpoints (mapped to <scope>).
> 
> ========================================================
> 
> 
> 
> Thanks!!!
> Thank you so much for reading this long email!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> Trickovic, Ivana wrote:
> 
>>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 
>>
>>  
>>
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]