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


I like the simplicity of the syntax of Alex's proposal. Although,
for me it is quite easy to model in terms of links and join
conditions, and I want to keep my proposal alive (because of the
minimal changes to BPEL's syntax and semantics), it looks like a
nice macro to provide more convenience to the customers.

Alex, could you shortly explain to me, what do you mean by static
and dynamic parallelism? How do you handle the two different cases
after evaluating the completeCondition: Terminating still running
tasks versus proceeding in control flow while those tasks are
still running (Sorry, I missed your previous emails)?

I agree to Alex's opinion, that we need a mechanism to kill
parallel flow nice and clean. This could be done either by a new
mechanism which does not throw a fault or by changing the way
fault are handled. I have discussed already an example of the
second case with Ivana, and I like to tell you, what I have in
mind. Look at the following example:

<scope name="scopeFlow">
    <link name="linkA"/>
    <link name="linkB"/>

    <scope name="scopeA">
      <invoke name="A" ...>
        <source linkName="linkA" ...>

    <scope name="scopeB">
      <invoke name="B" ...>
        <source linkName="linkB" ...>

    <throw name="C" faultName="bpws:forcedCompletion"
           joinCondition="linkA OR linkB" joinEvaluation="immediate">
        <target linkName="linkA" ...>
        <target linkName="linkB" ...>


First, I explain the situation: In the example above, activity C
will be executed if one of the two activities A and B was
successfully completed. Activity C throws the fault
"forcedCompletion". Like each other fault, this forces the scope
"scopeFlow" to terminate still running activities. Assume, there
was a fault handler defined in this scope which catches the fault
"forcedCompletion" (omitted in here), the process continues after
scope "scopeFlow". A problem arises, if scope "scopeFlow" should
be compensated. Because it was exited from a fault handler, no
compensation handler was installed.

Now, I explain my solution: In the example, I have chosen a new
"standard" fault name: "forcedCompletion". The only necessary
change is to allow a fault handler that catches this fault to
install a compensation handler for the same scope, i.e. to mark
the scope "scopeFlow" as "completed" instead of "exited".

The standard compensation mechanism will only undo those
("scoped") activities within the scope, which actually have been
successfully completed, i.e. scopeA or scopeB or may be both.

Axel Martens

Post Doc Researcher
Component Systems Group
IBM TJ Watson Research Center
Hawthorne, NY (USA)
Phone: (914) 784-7480
E-mail: amarten@us.ibm.com

Alex Yiu <alex.yiu@oracle.com>

09/10/2004 12:10 AM

Alex Yiu <alex.yiu@oracle.com>
"Trickovic, Ivana" <ivana.trickovic@sap.com>, Axel Martens/Watson/IBM@IBMUS, "'edwink@collaxa.com'" <edwink@collaxa.com>, "'satisht@microsoft.com'" <satisht@microsoft.com>, "'wsbpel@lists.oasis-open.org'" <wsbpel@lists.oasis-open.org>, Alex Yiu <alex.yiu@oracle.com>
Re: [wsbpel] Issue 6 - Rough draft of proposal for vote


Here are some examples how to use completeCondition to express similar business logic in Axel's previous email:

(A) "Select one out of three" example:
   <completeCondition branch="1" />
   <invoke name="CheckAirlineA" ... />
   <invoke name="CheckAirlineB" ... />
   <invoke name="CheckAirlineC" ... />

(B) "Select two out of three" example:
   <completeCondition branch="2" />
   <invoke name="AskRefereeA" ... />
   <invoke name="AskRefereeB" ... />
   <invoke name="AskRefereeC" ... />

As you guys can see, the completeCondition declaration is very straight forward and simple. No complicated links and joinCondition usage.

(C) "(Plane or Train) and Hotel" example: It would become two flow constructed (nested).

<assign> ... <to variable="planeResult"></assign>
  <!-- initialize "planeResult" with NOT-OK value -->
<assign> ... <to variable="trainResult"></assign>
  <!-- initialize "trainResult" with NOT-OK value -->
<flow name="checkIterinary">

   <flow name="PlaneOrPlane">
           fn:planeOK(planeResult) or fn:trainOK(trainResult)
      <invoke name="CheckPlane" outputVariable="planeResult" ... />
      <invoke name="CheckTrain" outputVariable="trainResult" ... />
   <invoke name="checkHotel" />
<switch name="bookingSwitch">

       (fn:planeOK(planeResult) or fn:trainOK(trainResult)) and fn:hotelOK(hotelResult)
       <invoke name="invokeBooking" ... />
         <invoke name="writeInformation" ... />

Please note that regardless whether we pick a link-oriented approach or completeCondition approach:
As you guys see, we don't need declare to six links. The completeCondition and case-condition are much simpler and easier to understand.

I attach a diagram to illustrate the above flows.

I guess we can still more time in terms of refiniment of joinCondition evaluation. However, I don't think that should be the only approach to achieve complete condition related logic.


Alex Yiu

Alex Yiu wrote:


+1 to what Ivana said in general.

Few points to add:


Alex Yiu

Trickovic, Ivana wrote:

I find the idea interesting. In fact, I was discussing the completion condition issue with Dieter Koenig during the last f2f meeting and his suggestion was also to try to resolve this issue using links. And we identified that several changes need to be done, including removing restriction for jonCondition, that "the join condition is evaluated as soon as all incoming links of the activity are determined" - so definitely "immediate" semantics needs to be introduced.
I have the following comments on your proposal.
1. In your proposal you are using a fault (bpws:forcedTermination) to terminate all active parallel branches. But this changes the outcome of the flow activity. It will always end abnormally and compensation handler (if it is defined) will never be installed. Although completion condition has evaluated to true and needed activities have completed the enclosing flow activity will end abnormally. Is this really intended semantics?
2. Your proposal does not address some pain points. For example, in case of "N out of M", N<M there many possible "variations":
(A) One enclosed activity may experience problems but the <flow> activity may succeed
(B) One of enclosed activities may experience a severe error, which may have impact on the <flow> activity
The question is what to do with running activities? In the latter case, reasonable behavior would be: if one enclosed activity does not succeed other running activities should be cancelled and the flow activity should try to recover. In the former case, we should allow active parallel activities to complete their work. This is not supported in your proposal.


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