wsbpel message

Subject: Issue 200: Link semantics does not preserve control dependencies

From: "Tony Fletcher" <tony_fletcher@btopenworld.com>
To: <wsbpel@lists.oasis-open.org>
Date: Tue, 5 Apr 2005 18:29:07 +0100

Title: Message

Please note that this "received" issue is being re-announced with a slightly different title and a different issue description and submitter's proposal.

Please reply to this announcement to comment further on this issue, or at least put Issue 200 at the beginning of the subject line (preceding Re: or Fw: are fine) so that the issue scripts pick up contributions ion this issue automatically. Thank you.

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 does not preserve control dependencies

Status: received
Date added: 5 Apr 2005
Categories: State management
Date submitted: 5 April 2005
Submitter: Marlon Dumas
Description:
In the current version of the specification, the link semantics defined in section 12.5.1 does not preserve the notion of control dependency defined in Section 13.4.2. Specifically, it is possible to build processes where there is a chain of control links going from an activity A to an activity B, and yet activity B is started before activity A completes. Such violations of control dependencies happen when there is a link emanating from: (i) an activity nested inside a branch of a switch that is not taken; or (ii) an activity that is not completed in a scope beacause this scope is halted due to a fault or an explicit termination of the scope. An example of such violation is the following: To illustrate this issue, consider the following example:

<flow name="F">
<someActivity name="A1">
  <sources>
   <source linkName="x1"/>
  </sources>
</someActivity>
<switch name="Sw">
   <case>
     <condition> C1 </condition>
     <someActivity name="A2"/>
   </case>
   <case> 
     <condition> C2 </condition> 
     <someActivity name="A3">
       <targets>
          <target linkName="x1"/>
       </targets>
       <sources>
         <source linkName="x2"/>
       </sources>
     </someActivity>
   </case>
</switch>
<someActivity name = "A4"> 
  <targets> 
   <joinCondition> 
     not(getLinkStatus("x2"))
   </joinCondition>
   <target linkName="x2">
  </targets>
</someActivity>
</flow>

Let's consider the following execution: Flow F starts, and thus activity 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 the current definition of links semantics in section 12.5.1 of the spec., 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. So there is a control dependency from A1 to A4 established by the two control links x1 and x2, and yet A4 can start before A1 completes.

Submitter's proposal:
To replace the following paragraph 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..."

With the following one:
"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 as soon as all the incoming control links to X are determined, 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..."

Note:This issue was initially received 31 March 2005 and announced on 1 April 2005 with the title 'Link semantics and control dependencies'. The issue statement was revised at the request of the submitter, Marlon Dumas, and re-announced on 5 April 2005.

Links: Prior discussion Marlon Dumas, 31 Mar 2005 Danny van der Rijn, 31 Mar 2005 Andrew Francis, 1 Apr 2005 Satish Thatte, 1 Apr 2005 Original Announcement, 1 Apr 2005
Changes: 1 Apr 2005 - new issue; 1 Apr 2005 - fields: Links; 5 Apr 2005 - fields: Links

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