Re: [wsbpel] Link semantics and control dependencies

[Assaf Arkin <arkin@intalio.com>]

Since A3 is allowed to begin (when selected) before A1 completes (in 
fact, A1 must complete after A3), a link dependency cannot be etablished 
between A1 and A3, so the link is invalid. Perhaps, we should be more 
clear about this in the spec, though I believe it says something about 
links not being valid when they contradict ordering of activities (e.g. 
links that reverse order of sequence):

It is illegal to declare a link if a control dependency cannot be 
established between the source activity and target activity, for 
example, if the target activity is nested within the source activity 
(and vice versa), and therefore must complete before the source activity 
has completed.

Assaf

Satish Thatte wrote:

>Marlon,
>
>I am trying to fathom the link from A1 to A3.  Do you mean that A1 is
>the switch activity and A3 is a nested case within the switch and there
>is a link from A1 to A3?  If so then this is pathological.  I realize
>that we probably don't ban it today explicitly but there is no way to
>have A3 execute in this case, regardless of the A4 conundrum.
>
>Satish
>
>-----Original Message-----
>From: Dumas, Marlon [mailto:marlon.dumas@sap.com] 
>Sent: Thursday, March 31, 2005 1:30 AM
>To: wsbpel@lists.oasis-open.org
>Subject: [wsbpel] Link semantics and control dependencies
>
>Hi,
>
>I believe that the following two fragments of the spec. contradict each
>other and I would like to gather second opinions about it:
>
>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.
>
>Does anybody find any flaws in my reasoning?
>
>Thanks
>
>marlon
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>  
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature