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 - 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:


would have a similar (but maybe not identical) effect of the following code:

<scope name="flowScope">
    <catch faultName="
    <!-- this faulthandler may be renamed to
         cancelHandler from Issue 135 -->
       <empty />
                The completeCondition logic happens here:
                If completeConditon is true,
                then we will trigger the "cancel" mechanism.
                 The same completeCondition logic happens here again.

  • 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>.


Alex Yiu

Trickovic, Ivana wrote:


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).



-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Mittwoch, 1. September 2004 04:28
To: Satish Thatte
Cc: edwink@collaxa.com; wsbpel@lists.oasis-open.org; 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:
    <completeCondition minFlow="1" />

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.


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).


From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Friday, August 27, 2004 5:38 PM
To: wsbpel@lists.oasis-open.org
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).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]