Hi, Ivana,
Sorry for replying you a bit late.
Because, I am trying to sort out another related issue at the same time
- issue 135.
After looking into Issue 135 and the email from Axel Martens, I think
"earlyCompletionFault" should be replaced by "forcedTermination" or its
equivalent concept (depending on Issue 135). [ I guess that is a part
of my thinking-out-loud process :-) ]
I also agree with you in the sense that. We can and should leverage the
existing fault handler semantics that you mentioned. Quoted
from Section 13.4:
"The
behavior of a fault
handler for scope C begins by implicitly terminating all activities
that are
currently active and directly enclosed within C (see Semantics
of Activity Termination). "
Here is an example for illustration:
[Please
don't consider the following as
the formal description of semantics of completeCondition for now.]
The
completeCondition construct below:
<flow>
<completeCondition>someCondition</completeCondition>
<scope-A/>
<activity-B/>
</flow>
would have a similar (but maybe not identical) effect of the following
code:
<scope name="flowScope">
<catch faultName="forcedTermination">
<!-- this faulthandler may be
renamed to
cancelHandler from Issue 135 -->
<empty
/>
</catch>
<flow>
<sequence>
<scope-A>
<!--
The completeCondition logic happens here:
If completeConditon is true,
then we will trigger the "cancel" mechanism.
-->
</sequence>
<sequence>
<activity-B/>
<!--
The same completeCondition logic happens here again.
-->
</sequence>
</flow>
</flow>
Note:
The
"cancellation" effect of the flow does not go beyond the enclosing
"flowScope".
The
code pattern is similar to the one from Axen. The difference is just
that it does not involve links.
And,
this completeCondition concept is basically borrowed from the
"Bundles_Requirement_F2F.ppt" made by Ivana and Dieter Roller in March
F2F. I think we should generaliize the same concept from
"bundle"/"parallel-forEach" to any parallel flow construct - including
<flow>.
Thanks!
Regards,
Alex Yiu
Trickovic, Ivana wrote:
Alex,
Regarding the proposed semantics:
Would you elaborate how the fault (bpws:earlyCompletionFault) will be signaled to other incomplete
flow activities? Those activities are enclosed within the flow
activity. If I understand the fault handling model correctly there is
no possibility to communicate faults to nested activities/scopes except
canceling the enclosing activity (in this case, the flow activity).
Regards,
Ivana
-----Original Message-----
From: Alex Yiu [mailto:]
Sent: Mittwoch, 1. September 2004 04:28
To: Satish Thatte
Cc: ; ; Alex Yiu
Subject: Re: [wsbpel] Issue 6 - Rough draft of proposal for
vote
Hi, Yaron and others,
I agree with the concern of Edwin and Satish. We should define a
general mechansim to express early completion condition. Then, define
the "orJoin" attribute or other syntax as a macro/special syntax short
cut.
If you guys don't mind, I can supplement some alternative ideas to this
issue. I am in the thinking-out-loud mode again. That means, I need to
verify whether this idea makes sense to other people at Oracle. [ But,
as Ron said, this thinking-out-loud mode has worked quite well for me
in the past. ;-) ]
We should allow a <completeCondition> subelement attached to
parallel-flow-starter activity (e.g. <flow> or future potential
parallel <forEach>).
Syntax of completeCondition:
It has two forms:
(1) <completeCondition>a_boolean_expr</completeCondition>
(2) <completeCondition minFlow="a_number" />
... or ...
<completeCondition
countMinFlow="yes">a_number_expr</completeCondition>
The first form is the most generic form of completion condition.
The second form provides a convienent shorthand to achieves the N out
of M semantics.
The suggested orJoin="yes" is equivalent to:
<flow>
<completeCondition minFlow="1" />
...
</flow>
Semantics of completeCondition:
The complete condition will be evaluated at the completion of each
flow. If the condition is true, a standard fault
bpws:earlyCompletionFault will be signaled to other incomplete flow
activities. Each incomplete flow activity can potentially be
compensated if each flow is a scope activity. (Potentially, we can add
static analysis to enforce that when a completionCondition is used in
<flow>, <scope> must be used as activities within the
flow.)
The completeCondition itself is executed in the same scope context of
the <flow> activity. [ And, the completeCondition should be
executed serially, to avoid racing condition among flows (?)]
I hope this rough draft of ideas serves as a good base of discussion
for this issue.
Thanks!
Regards,
Alex Yiu
Satish Thatte wrote:
I echo
Edwin's second question. Yaron, your proposal clearly doesn't address
the intent of 6. It seems too narrow to just address this corner case
of completion of one among many (corner case from my perspective).
Satish
From: Edwin Khodabakchian [mailto:]
Sent: Friday, August 27, 2004
5:38 PM
To:
Subject: RE:
[wsbpel] Issue 6 - Rough draft of proposal for vote
Hi Yaron,
2 questions:
1) are we sure that
termination is the desired behavior for the non completed activity?
2) what happens if the
join rule is: "the first search result which is non empty or includes
at least 3 entries with more than 85% accuracy"? The point here is that
a lot of join patterns might have logic in them. I know that in the
past we talked about having something like <break> for flow.
(This is something that a lot of our customers are asking us and might
address the same us case is a more flexible way specially if the
<break> can be configure to tell the engine to compensate or
terminate).
Best,
Edwin
