Hi Yaron,
Issue 6.3 tries to address the fundamental question:
- whether a flow branch can be terminated without using the
termination of the whole enclosing scope to make it happen
- it translates into whether we must have a scope-based activity
inside a <flow> where the early-completion is enabled.
We really need that "yes/no" clarification for "partial termination of
a scope". Either "yes" or "no" is fine to me personally. However,
people are having different interpretations of the spec as of this
moment, which is bad. And, of course, if the answer is "yes", we need
to provide supplementary text (as suggested in my email) to explain
what actually happens in the case. if the answer is "no", we need to
clear state that in the spec also.
A past email thread to refresh people's memory:
http://lists.oasis-open.org/archives/wsbpel/200504/msg00061.html
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
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
---------------------------------------------------------------------
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
|