Alex,
Please
see my response to Axel's proposal. The same comments apply
here.
Regards,
Ivana
-----Original Message-----
From: Alex Yiu
[mailto:]
Sent: Samstag, 4. September 2004
00:08
To: Trickovic, Ivana
Cc: '';
''; ''; Alex
Yiu
Subject: Re: [wsbpel] Issue 6 - Rough draft of proposal for
vote
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
