while i like the simplicity, i am concerned that in WSFL 1.0, the
"immediate" value was not allowed:|
"V1.0 remark: deferred is the only valid value for the when attribute
in Version 1.0."
can you comment on the reasons that it was not included in 1.0? i
imagine that there were complexities introduced that were not desirable
for a 1.0 spec. i wonder if those concerns are also relevant for BPEL.
Axel Martens wrote:
I'd like to participate in your
with a proposal that
comes with minimal changes to the
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
the mismatch between BPEL
and the workflow pattern à la van
Aalst quite well.
I completely agree on searching for
a general solution to the
request of issue 6 rather than
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
methods. The deferred
evaluation of the join condition
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
covered by IBM's Flow
Definition Language (FDL) and Web
Flow Language (WSFL).
The next paragraph explains the
change to syntax and
semantics. Afterwards I show three
to demonstrate the
expressive power of this changes.
Syntax & semantics:
The changes to syntax are minimal.
activity gets a new
standard attribute "joinEvaluation"
- of course, this attribute
has only influence on activities
are target of at least two
links. The attribute can have the
"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
do not insist on this change.
In case, the attribute was set to
the join behavior
stays untouched. If the attribute
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
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
the borders of a while loop
and each time a while loop is
its internal link value
should be cleared, there can't be
This changes together with the
existing concepts of scope
and fault handling allow an strait
mapping of the missing
First, we take a look on a selection
of one result out of three,
where the not chosen alternatives
allowed to finish normally.
The following figure shows the
of contacting three
airlines and booking the first
(for reasons of clarity,
the bpel-code is not fully
Because of the immediate evaluation
of the join condition, the
activity "InvokeBooking" is
started directly after the termination
of one preceding activity. Whereas
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
The second example shows two new
First, the join requires
at least two of the three referees
have finished the review.
This is done by a modified join
Second, after two
results are available, still running
activities of the flow are
explicitly terminated. This is
by help of a scope around
the flow with an empty fault handler
that catches the
These mechanisms already exit.
no further changes to the
language itself are necessary. Of
a user should be
supported, e.g. by generating such
demand, but this is a task of
rather than language design.
More complex relations
Finally, the join condition can
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
to find an available
hotel and at least on kind of
This example mixes all concepts. In
case, no hotel or no
transportation is available, an
for the customer is
generated ("assign") and the
flow is terminated ("throw").
Otherwise, the trip is booked
and still running
activities are allowed to terminate
on their own before the
customer is informed.
A minimal change to BPEL's syntax
an easy to implement change
to its operational semantics enrich
the expressive power
enormously, such that more useful
pattern could be mapped
into this language. To increase the
convenience of usage, tools
may provide predefined macros or
automatically on demand.
Post Doc Researcher
Component Systems Group
IBM TJ Watson Research Center
Hawthorne, NY (USA)
Phone: (914) 784-7480
Regarding the proposed
Would you elaborate how the fault (bpws:earlyCompletionFault) will be
to other incomplete flow activities? Those activities are enclosed
the flow activity. If I understand the fault handling model correctly
is no possibility to communicate faults to nested activities/scopes
canceling the enclosing activity (in this case, the flow activity).
From: Alex Yiu [mailto:firstname.lastname@example.org]
Sent: Mittwoch, 1. September 2004 04:28
To: Satish Thatte
Cc: email@example.com; firstname.lastname@example.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
mechansim to express early completion condition. Then, define the
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
activity (e.g. <flow> or future potential parallel
Syntax of completeCondition:
It has two forms:
(2) <completeCondition minFlow="a_number" />
... or ...
The first form is the most generic form of completion condition.
The second form provides a convienent shorthand to achieves the N out
The suggested orJoin="yes" is equivalent to:
<completeCondition minFlow="1" />
Semantics of completeCondition:
The complete condition will be evaluated at the completion of each
If the condition is true, a standard fault bpws:earlyCompletionFault
be signaled to other incomplete flow activities. Each incomplete flow
can potentially be compensated if each flow is a scope activity.
we can add static analysis to enforce that when a completionCondition
used in <flow>, <scope> must be used as activities within
The completeCondition itself is executed in the same scope context of
<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
Satish Thatte wrote:
I echo Edwin's second
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:email@example.com]
Sent: Friday, August 27, 2004 5:38 PM
Subject: RE: [wsbpel] Issue 6 - Rough draft of proposal for vote
1) are we sure that termination is the
behavior for the non completed activity?
2) what happens if the join rule is:
first search result which is non empty or includes at least 3 entries
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
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
flexible way specially if the <break> can be configure to tell
engine to compensate or terminate).