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


The proposal as currently described requires us to violate an agreement 
that group reached in Germany over a year ago. To whit - we would never 
require anyone to support nested serialized scopes. To be clear, it is 
legal to have a serialized scope that contains within it non-serialized 
scopes. What is illegal is to have two scopes that are both serialized 
nested within each other.

But this proposal depends on the ability to serialize the completion 
condition so as to prevent collisions while it is calculating the value 
of the completion condition. But what happens if the scope that contains 
the flow that contains the completion condition is itself serialized? 
Are we now going to specify that completion conditions cannot be used 
within serialized scopes?

Also, is it just me or does all the possible combinations of branches, 
booleanExpressions, countCompletedBranches and such feel rather 
confusing? I for one wouldn't want to have to describe all of this to 
some poor unsuspecting BPEL user.

I really think we are getting ahead of ourselves here. Completion 
conditions is not an area that is really well understood. It is not an 
area that BPEL's current semantics really led themselves to (witness the 
argument between Ivana and Alex). It is not an area in which there is a 
lot of experience and consensus. Rather than just making something up 
why don't we hold off on taking action, let the market experiment and 
then when a consensus emerges standardize the result?

		Yaron

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]