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

Your reasoning looks sound to me, but I'm not sure what other flaw 
you're pointing out.  If the point of the your case is to point out that 
the language in the spec is flawed, then I would ask what you would want 
to change it to.  If the point of your case is to point out a bug in 
some other part of the spec, then I'd be much more interested.

Dumas, Marlon wrote:

>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
><switch name="Sw">
>   case C1: A2
>   case C2: A3
>A4 [joinCondition = "not x2"]
>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?
>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

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