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
-----Original Message-----
From: Axel Martens
[mailto:]
Sent: Mittwoch, 1. September 2004
19:25
To: Trickovic, Ivana
Cc: '';
''; '';
''
Subject: RE: [wsbpel] Issue 6 - Rough
draft of proposal for vote
Dear all:
I'd like to
participate in your discussion with a proposal that
comes with minimal changes to the current BPEL
specification but
is able to handle
the mentioned use cases, and even more.
First, I'd like to introduce myself. I am a post-doc researcher
at
IBM Watson, working in the group of
Paco Curbera. In my PhD thesis
I have
dealt with Web service based business processes and Petri
nets. Hence, I know the discussion on the mismatch
between BPEL
and the workflow pattern
à la van der Aalst quite well.
I
completely agree on searching for a general solution to the
request of issue 6 rather than fixing distinguished
cases. The
problem (or restriction) of
BPEL is that you can't enable or
disable an activity easily w.r.t. to the complex context, like
you
can do modeling with Petri nets or
related methods. The deferred
evaluation of the join condition (all incoming links has to be
signaled first) is one of the mayor reasons
for it. Hence, our
group proposes to
allow an immediate evaluation of the join
condition, too. This feature was already covered by IBM's Flow
Definition Language (FDL) and Web Service
Flow Language (WSFL).
The next
paragraph explains the proposed change to syntax and
semantics. Afterwards I show three examples to
demonstrate the
expressive power of
this changes.
Syntax &
semantics:
The changes to syntax
are minimal. Each activity gets a new
standard attribute "joinEvaluation" - of course, this attribute
has only influence on activities that are
target of at least two
links. The
attribute can have the values "deferred" (the default
value) and "immediate".
As a kind of syntactical sugar, each flow or the whole
process
might redefine the default
value for all its child activities
through the additional attribute "defaultJoinEvaluation". But,
we
do not insist on this
change.
In case, the attribute was
set to "deferred", the join behavior
stays untouched. If the attribute was set to "immediate", the
join
condition is evaluated each time
one of the incoming links has
changed
its value. Some examples:
"true" and "yet undefined" yields "yet undefined"
"false" and "yet undefined" yields
"false"
"true" or "yet
undefined" yields "true"
"false" or "yet undefined" yields "yet undefined"
This evaluation may yield "yet undefined", than nothing
happens.
If the join condition could
be evaluated to "true" or "false", the
activity is executed or skipped, and further changes to the link
values are ignored.
Because links are not allowed to cross the borders of a
while loop
and each time a while loop
is entered, its internal link value
should be cleared, there can't be any confusion.
Examples:
This changes together with the already existing concepts of
scope
and fault handling allow an
strait forward mapping of the missing
pattern.
One-out-of-Many
First, we
take a look on a selection of one result out of three,
where the not chosen alternatives are allowed to finish
normally.
The following figure shows
the example of contacting three
airlines and booking the first available (for reasons of
clarity,
the bpel-code is not fully
specified).
Because of the immediate evaluation of the join
condition, the
activity
"InvokeBooking" is started directly after the termination
of one preceding activity. Whereas the flow is exited
only if all
its child activities are
terminated. In case, the customer should
be informed as soon as possible, the reply activity should be
moved into the flow in sequence to
"InvokeBooking".
N-out-of-M
The second example shows two new aspects.
First, the join requires
at least two
of the three referees to have finished the review.
This is done by a modified join condition. Second,
after two
results are available, still
running activities of the flow are
explicitly terminated. This is modeled by help of a scope around
the flow with an empty fault handler that
catches the
"forcedTemination"
fault.
These mechanisms already exit. Hence, no further
changes to the
language itself are
necessary. Of course, a user should be
supported, e.g. by generating such structures automatically on
demand, but this is a task of tooling rather
than language design.
More complex
relations
Finally, the join
condition can specify precisely which
combination of link values is needed to proceed, instead of just
the number. The last figure shows an example
employing this
feature: For booking a
trip, it is necessary to find an available
hotel and at least on kind of transportation.
This
example mixes all concepts. In case, no hotel or no
transportation is available, an information for the
customer is
generated ("assign") and
the flow is terminated ("throw").
Otherwise, the trip is booked ("InvokeBooking") and still
running
activities are allowed to
terminate on their own before the
customer is informed.
Summary
A minimal change to
BPEL's syntax and an easy to implement change
to its operational semantics enrich the expressive power
enormously, such that more useful modeling
pattern could be mapped
into this
language. To increase the convenience of usage, tools
may provide predefined macros or generate necessary
structures
automatically on
demand.
Regards, Axel.
----------------------------------------
Axel Martens
Post
Doc Researcher
Component Systems Group
IBM TJ Watson Research Center
Hawthorne, NY (USA)
Phone: (914) 784-7480
E-mail:
"Trickovic, Ivana"
<>
09/01/2004 10:32 AM
To
"''" <>
cc
"''" <>,
"''" <>,
"''"
<>
Subject
RE: [wsbpel] Issue 6 -
Rough draft of proposal for vote
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
