Alex,
I like
the <completeCondition> idea. It solves the issue 6 problem more
naturally. And I also agree that it will work for dynamic
parallelism.
Axel,s
proposal of introducing the "immediate" semantics
for <joinCondition> is a powerful enhancement to BPEL. It quite
possibly supports other usecases not supported by <completeCondition>
approach. Axel, I would suggest that you introduce your proposal as
a separate issue. Though given the timeline there would be higher
threshold to cross for getting the issue in.
regards,
-Vinky
-----Original Message-----
From: Alex Yiu
[mailto:]
Sent: Friday, September 10, 2004 5:49
PM
To: Axel Martens
Cc: ''; Trickovic,
Ivana; ''; ''; Alex
Yiu
Subject: Re: [wsbpel] Issue 6 - Rough draft of proposal for
vote
Hi, Axel,
Thanks for liking parts of my
proposal so far.
Actually, the idea of my proposal is borrowed from a part
of presentation from Ivana and Dieter Roller in March F2F. I just generalize
it to apply to <flow> also.
About using links or not:
I don't have a huge opposition to Axel's proposal which enriches the
semantics of joinCondition evaluation. However, it is not that difficult for
people to make mistakes in joinCondition. Look at the 2-out-of-3 example. The
join condition already gets so complicated. If people make a mistake in their
joinCondition, the whole flow can get struck for no good reasons. (The
completeCondition approach will less likely to have the whole flow struck.
Because, it does not introduce a new parallel activity in the flow). But, if
this is what Petri-net-oriented and control-link-oriented audience really
want, I can accept it in a sense, as long as this is not the only way to
achieve similar business logic.
About static vs dynamic
parallelism:
Static parallelism is basically <flow> construct in
BPEL. Dynamic parallelism is "parallel forEach" or "bundle". Issue 4 and 147
are related issues.
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue4
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue147
About
"Terminating still running tasks versus proceeding in control flow while those
tasks are
still running":
I am not 100% that I understand your
question. Let me try to answer it anyway. The completeCondition is about
triggering termination of still-running tasks. The "proceeding in control
flow" (if I understand you correctly) will be handled by an outter flow. [I
guess it is related to (hotel and (train or plane)) flow??]
About
changes of "forcedTermination" fault handler:
If you got a chance to
see some recent emails on Issue 135, Satish has recently suggested to remove
the notion "forcedTermination" fault and replace its fault handler with
cancelHandler. Frank, Yaron, Edwin and I all agree with this direction.
Because, overloading fault with the concept of "forcedTermination" is a "false
economy" and it creates quite a bit of unnecessary confusion.
I don't
think we should go back to this route or even further overload the
"forcedTermination" fault handler semantics. Because, fault handling is way
too generic and the changes you mentioned will create even more confusion.
(e.g. Will this change of marking as "completed" apply to all
"forcedTermination" fault handler / cancel handler of all scopes? )
I
guess most of us agree that we should have a new mechanism to kill / do an
early completion of a flow in a nice and clean way. However, overloading a
standard fault handler does not seem to be the best one. I would rather
introduce a construct which is very specific to <flow> or
parallel-forEach. For example, this <completeCondition> construct or
maybe a new activity called <completeFlow />. I will send out more
emails on joint thinking of both Issue 6 and Issue 135. Please stay
tuned.
Thanks!
Regards,
Alex Yiu
Axel
Martens wrote:
Hi,
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">
...
<flow>
<link
name="linkA"/>
<link name="linkB"/>
<scope name="scopeA">
...
<invoke name="A"
...>
<source linkName="linkA" ...>
</invoke>
</scope>
<scope name="scopeB">
...
<invoke name="B"
...>
<source linkName="linkB" ...>
</invoke>
</scope>
<throw name="C"
faultName="bpws:forcedCompletion"
joinCondition="linkA OR
linkB" joinEvaluation="immediate">
<target linkName="linkA"
...>
<target linkName="linkB" ...>
</throw>
</flow>
</scope>
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.
----------------------------------------
Axel Martens
Post
Doc Researcher
Component Systems Group
IBM TJ Watson Research Center
Hawthorne, NY (USA)
Phone: (914) 784-7480
E-mail:
Alex Yiu <>
09/10/2004 12:10 AM
To
Alex Yiu <>
cc
"Trickovic, Ivana"
<>,
Axel Martens/Watson/IBM@IBMUS, "''" <>,
"''"
<>,
"''"
<>,
Alex Yiu <>
Subject
Re: [wsbpel] Issue 6
- Rough draft of proposal for
vote
Hi,
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:
<flow>
<completeCondition branch="1" />
<invoke name="CheckAirlineA" ... />
<invoke
name="CheckAirlineB" ... />
<invoke
name="CheckAirlineC" ... />
</flow>
(B) "Select two
out of three" example:
<flow>
<completeCondition branch="2" />
<invoke name="AskRefereeA" ... />
<invoke
name="AskRefereeB" ... />
<invoke name="AskRefereeC"
... />
</flow>
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">
<completeCondition>
fn:planeOK(planeResult) or fn:trainOK(trainResult)
</completeCondition>
<invoke
name="CheckPlane" outputVariable="planeResult" ... />
<invoke name="CheckTrain" outputVariable="trainResult" ... />
</flow>
<invoke
name="checkHotel" />
</flow>
<switch
name="bookingSwitch">
<case>
<condition>
(fn:planeOK(planeResult) or fn:trainOK(trainResult)) and
fn:hotelOK(hotelResult)
</condition>
<invoke
name="invokeBooking" ... />
</case>
<otherwise>
<invoke
name="writeInformation" ... />
</otherwise>
</switch>
Please note
that regardless whether we pick a link-oriented approach or
completeCondition approach:
The initialization of result variables are needed because
of potential cancellation of one of the invoke between train and
plane
The "fn:*()" represents the logic to determine whether a
traveling resource is available. They are used in either the
transitionCondition of links or the condition of switch/case.
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.
Thanks!!!
Regards,
Alex
Yiu
Alex Yiu wrote:
Hi,
+1 to what Ivana said in general.
Few points to
add:
Axel's proposed enhancement to control links evaluation
works to an extent for static parallelism (e.g. <flow>).
However, control links do not work well in dynamic parallelism (e.g.
"parallel forEach" or "bundle"). I think the notion of completeCondition
(borrowed from Ivana and DK) is general enough and it should be applied to
both static and dynamic parallelism. A general completeCondition mechanism
will be easier for BPEL users to learn.
Even in a pure static parallelism case, completeCondition
has much better code clarity. It is more declarative and easier for BPEL
users to understand. It will eliminate significant amount of joinCondition
programming, which may be error prone. (I will send another email later to
show how completeCondition can be used to express the same semantics of
Axel's example).
In one of my previous emails, I also tried to use a
"macro" way to illustrate how outstanding running flows can be cancelled
by throwing a fault within a scope. The illustration has the same
compensation handler installation problem that Ivana has pointed out. The
"illustraction macro" does NOT carry a desirable and intended semantics.
We need to create / describe a new mechanism to cancel parallel flow
without throwing a fault. (That was discussed briefly between Edwin and me
at Oracle).
Thanks!
Regards,
Alex Yiu
Trickovic,
Ivana wrote:
Axel,
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.
Regards,
Ivana
[stuff deleted]
