[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete
Hi Prasad, In a previous e-mail exchange with Andrew
regarding Issue 189, I proposed the following paragraph to capture the behavioral
constraints imposed by BPEL on the evaluation of join conditions: "A control link from activity B to
activity C implies a 'control dependency' from B to C. A 'control
dependency' from B to C means that, in any given execution, B (if it is
present) precedes C. In the case where B and C are nested
within a loop, this statement must hold for each iteration of this
loop." Hence, if an activity C is target of two
links, one stemming from activity B and another from activity D, then C must not
start until both B and D have completed, or until it is known that these
activities will be skipped (i.e. until the corresponding link status has been
determined). Otherwise, we could have the situation where C precedes B or D,
thus violating the control dependency. This formulation does allow BPEL
implementations to perform certain types of optimizations such as the one
discussed in the last message of Andrew regarding Issue 189. Perhaps a variant of the above paragraph
would address issue 193? Note that the fragment of sentence "B (if it is
present) precedes C" could be re-formulated in other ways, like for
example "C must not start before B has completed or before it is known
that B will be skipped". BTW, the "private auction" example
is not necessarily the best example for this issue. Indeed, in a private auction
the number of partners from which bids are expected (i.e. what you call 'N' in the
example) is not known at design time, so you wouldn't model this as a fixed
number of branches that converge in a given activity. This example fits much
better Issue 4 (in fact, auctioning is one of the motivating examples for issue
4). Regards, marlon From: Tony Fletcher
[mailto:tony_fletcher@btopenworld.com] This issue has been added to the wsbpel issue list with a
status of "received". The status will be changed to "open"
if the TC accepts it as identifying a bug in the spec or decides it should be
accepted specially. Otherwise it will be closed without further consideration
(but will be marked as "Revisitable") The
issues list is posted as a Technical Committee document to the OASIS WSBPEL TC
pages on a regular basis. The current edition, as a TC document,
is the most recent version of the document entitled in the "Issues"
folder of the WSBPEL TC
document list - the next posting as a TC document will include
this issue. The list editor's working copy, which will normally include an
issue when it is announced, is available at this
constant URL.
Issue 193: Clarify why the spec mandates
that JoinConditions must always be evaluated only after all source activities
complete
Status: received The BPEL
specification currently requires that a joinCondition on a target activity be
evaluated only after all sources activities for the links coming into it are
complete, even for an implicit OR <joinCondition> where the status of
only one of the incoming links needs to be positive. This is a
major constraint that disables straight-forward modeling of a large class of
processes where the target activity needs only one of its source activities to
complete successfully. An example scenario is a private auction, where the
auction tracking activity needs a bid to be placed by only one of the N bidders
possible, to start. The only
text in the specification that speaks to this major constraint is hidden in one
sentence in the text in section 12.5.1: "If an activity that is ready to
start ..., then it does not start until the status *of all its incoming links
has been determined* and the (implicit or explicit) join condition associated
with the activity has been evaluated." Issue 189
called for lifting this constraint but the TC decided to not to address this in
this version of the specification. Different justifications for not
incorporating the change were alluded to by the TC members during the
discussion of issue 189, including increased implementation complexity and the
amount of changes needed to the specification. However
since this is a major constraint, the specification must minimally clarify why
this constraint is imposed by the specification. Best Regards, Tony
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]