wsbpel message

Subject: Issue 200: Link semantics and control dependencies

From: "Tony Fletcher" <tony_fletcher@btopenworld.com>
To: <wsbpel@lists.oasis-open.org>
Date: Fri, 1 Apr 2005 23:00:02 +0100

Title: Message

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 200: Link semantics and control dependencies

Status: received
Date added: 1 Apr 2005
Categories: State management
Date submitted: 31 March 2005
Submitter: Marlon Dumas
Description: I believe that the following two fragments of the spec. contradict each other:

In Section 12.5.1 (Link Semantics)
"If, during the performance of structured activity S, the semantics of S dictate that activity X nested within S will not be performed as part of the behavior of S, then the status of all outgoing links from X is set to negative. An example is an activity within a branch that is not taken in a switch activity..."

In Section 13.4.2 (Default Compensation Order):
"If an activity A must complete before activity B begins, as a result of the existence of a control path from A to B in the process definition, then we say that B has a control dependency on A. Note that control dependencies may occur due to control links in a <flow> as well as due to constructs like <sequence>."

To illustrate this contradiction, consider the following example:

<flow name="F">
link x1 goes from A1 to A3
link x2 goes from A3 to A4

A1
<switch name="Sw">
   case C1: A2
   case C2: A3
</switch>
A4 [joinCondition = "not x2"]

</flow>

Let's now consider the following execution: Flow F starts, and thus action A1 and switch "Sw" are executed. Note that at this point A4 is ready to start but does not start because its incoming link x2 has not yet been determined. Let's now assume that condition C1 evaluates to true and thus the corresponding branch is taken which results in activity A2 being executed. According to the first quote from the spec. above, the status of link x2 is then set to negative since branch A3 was not taken. The joinCondition at A4 ("not x2") then evaluates to True, and this results in A4 being executed. Note that at this point in time, A1 has not yet completed.

This seems to contradict the second quote above. Indeed, there is a control path from A1 to A4 (i.e. a control link from A1 to A3 and another one from A3 to A4), which means that A4 has a control dependency on A1. Hence A4 cannot start before A1 has completed.
Submitter's proposal: None yet.
Changes: 1 Apr 2005 - new issue

Best Regards,

Tony

	Tony Fletcher Technical Advisor Choreology Ltd. 68, Lombard Street, London EC3V 9L J UK
	Phone:	+44 (0) 1473 729537
	Mobile:	+44 (0) 7801 948219
	Fax:	+44 (0) 870 7390077
	Web:	www.choreology.com
Cohesions™
Business transaction management software for application coordination
Work: tony.fletcher@choreology.com
Home: amfletcher@iee.org