[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 6.2 - Updated Proposal For Vote
Hi Chris, Alex,
#1: Yes. That is the right behavior.
#3: Or we may clarify that in case of flow and parallel forEach the termination could be the outcome of an early completion as well.
#4: OK
Thanks,
Ivana
-----Original Message-----
From: Alex Yiu
To: chris.keller@active-endpoints.com
Cc: Trickovic, Ivana; wsbpel@lists.oasis-open.org; Alex Yiu
Sent: 14.09.2005 20:18
Subject: Re: [wsbpel] Issue 6.2 - Updated Proposal For Vote
Hi, Chris and Ivana,
For #1, I now understand what you mean ...
Yes, I agree with you ... +1 to that clarification:
The target number of branches from <branches> condition will be
calculated only before execution of any enclosed activities. The target
number of branches will not be changed even underlying variables or
state of expression used in <branches> change.
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
Hi Ivana,
#1: What I mean is the count of branches is calculated only once and
won't
change as the result of the flow execution. For example:
<completionCondition>
<branches>$myN</branches>
</completionCondition>
The expression $myN is calculated at the start of the flow/pfe. And the
count of completed activities is tested against this count after each
activity completion within the flow/pfe.
#3: I think the text I am referring to is the stuff about "termination
handlers not being able to rethrow since the parent of the scope is
already
faulting..." that is no longer the case since this termination is being
done
not because of a fault but a completion. So for example if a child of
the
flow is a scope that didn't complete and the completion condition is
reached
then it will be terminated. Therefore it's termination handler will
execute
if the termination handler faults what should happen. The current text
in
13.4.4 is at least misleading.
#4: Let me think some more about it.
Thanks,
Chris
-----Original Message-----
From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com
<mailto:ivana.trickovic@sap.com> ]
Sent: Wednesday, September 14, 2005 1:56 PM
To: Chris Keller ; wsbpel@lists.oasis-open.org
<mailto:wsbpel@lists.oasis-open.org>
Cc: alex.yiu@oracle.com <mailto:alex.yiu@oracle.com>
Subject: RE: [wsbpel] Issue 6.2 - Updated Proposal For Vote
Hi Chris,
#1: How about to add in (5) the following:
"... a completionCondition
element the completion condition is evaluated each time AFTER a directly
enclosed activity completes."
It would seem better if the expression was evaluated once prior to the
flow executing.
What does is mean "prior to the flow executing"? How does that work
because
multiple activities are started in parallel.
#2: You are right. How about the following:
"If all directly enclosed activities have been completed
but the completion condition evaluates to false the
"bpws:completionConditionFailure" MUST be thrown by the flow/parallel
forEach activity."
#3: The current proposal is inline with section 13.4.4. But we may
discuss
this on the call and you may propose an amendment. Would that be ok for
you?
#4: Any suggestion?
Thanks,
Ivana
-----Original Message-----
From: Chris Keller
To: Trickovic, Ivana; wsbpel@lists.oasis-open.org
<mailto:wsbpel@lists.oasis-open.org>
Cc: alex.yiu@oracle.com <mailto:alex.yiu@oracle.com>
Sent: 14.09.2005 18:14
Subject: RE: [wsbpel] Issue 6.2 - Updated Proposal For Vote
Hi Ivana,
Some questions/comments:
1. Is the branches expression evaluated each time a directly enclosed
activity completes or is the test evaluated each time? It is unclear in
your description below. It would seem better if the expression was
evaluated once prior to the flow executing.
2. What happens if the flow or parallel forEach completes, but the
completion condition is not met?
3. If this is adopted we would also have to change section 13.4.4
Semantics of Activity Termination from:
"However, a termination handler cannot throw any fault. Even if an
uncaught fault occurs during its behavior, it is not rethrown to the
next enclosing scope. This is because the enclosing scope has already
either faulted or is in the process of being terminated, which is what
is causing the forced termination of the nested scope."
to just:
"However, a termination handler cannot throw any fault. Even if an
uncaught fault occurs during its behavior, it is not rethrown to the
next enclosing scope."
4. Is branches the most suitable name for the element name?
Regards,
Chris Keller
Regards,
Chris
_____
From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com
<mailto:ivana.trickovic@sap.com> ]
Sent: Wednesday, September 14, 2005 3:15 AM
To: wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>
Cc: alex.yiu@oracle.com <mailto:alex.yiu@oracle.com>
Subject: [wsbpel] Issue 6.2 - Updated Proposal For Vote
Below please find an updated proposal for issue 6.2.
Kind regards,
Ivana
Issue 6.2: Updated proposal:
Last modified: Sept 13, 2005 - 23:30 PDT
Motivation
===========
The current semantics of the flow activity is that it completes when all
its (directly) enclosed activities have completed, either successfully
or unsuccessfully. However, there are scenarios where it is necessary to
have ability to (successfully) complete the flow activity before all its
directly enclosed activities complete in order to speed up the process
execution.
The completion condition may have different flavors:
(1) Wait for N out of M nested activities to complete
(2) Wait until after boolean condition C evaluates to true
This updated proposal is restricted to case (1).
The completion condition is interesting for the flow activity and for
the parallel forEach activity.
Proposal
=========
Syntax:
<flow standard-attributes>
standard-elements
<links>?
<link name="ncname">+
</links>
<completionCondition>?
activity+
</flow>
<forEach counterName="ncname" ...>
standard-elements
<iterator>
<startCounterValue expressionLanguage="anyURI">
...
</startCounterValue>?
<finalCounterValue expressionLanguage="anyURI">
...
</finalCounterValue>?
</iterator>
<completionCondition>?
Scope
</foreach>
<completionCondition extension-attribute>
extension-element
<branches expressionLanguage="URI"?
countCompletedBranchesOnly="yes|no"?>
an-integer-expression
</branches>
</completionCondition>
Semantics:
(1) The completionCondition element is an optional element of the flow
activity and the parallel forEach activity. Default behavior of the flow
activity and the parallel forEach activity is they wait for all their
directly enclosed activities to complete. Optional <completionCondition>
is applicable to parallel forEach only, and not serial forEach. This
restriction MUST be enforced by static analysis.
(2) <branches> is 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 directly enclosed activity. This condition has "at least N out
of M" semantics. (The exact N out of M condition semantics involve
resolving racing condition among directly enclosed activities.)
(3) If the integer value is larger than the number of directly enclosed
activities, 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. (For example, when the branches
expression is a constant.)
(4) Element <branches> 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.
(5) If flow/parallel forEach activity specifies a completionCondition
element the completion condition is evaluated each time a directly
enclosed activity completes. If the completion condition evaluates to
true the flow/parallel forEach activity completes successfully. All
still running directly enclosed activities will be terminated. This
means that the flow/parallel forEach activity begins implicitly
terminating the directly enclosed activities that are still active.
(6) Standard BPEL termination semantics applies to running directly
enclosed 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).
(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
<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
<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]