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 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete

Title: Message

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).






From: Tony Fletcher [mailto:tony_fletcher@btopenworld.com]
Sent: Monday, 28 February 2005 7:50 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete


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
Date added: 27 Feb 2005
Categories: State management
Date submitted: 26 February 2005
Submitter: Prasad Yendluri
Document: WS-BPEL Working Draft, December, 2004
Description: This is a follow on to issue 189 which we classified as a new feature request.

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.
Submitter's proposal: I request that text be added to section 12.5.1 around the area where this constraint is specified.
Changes: 27 Feb 2005 - new issue

 Best Regards,


Tony Fletcher

Technical Advisor
Choreology Ltd.
68, Lombard Street, London EC3V 9L
J   UK


+44 (0) 1473 729537


+44 (0) 7801 948219


+44 (0) 870 7390077




Business transaction management software for application coordination

Work: tony.fletcher@choreology.com

Home: amfletcher@iee.org


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