[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Link semantics and control dependencies
Hi Satish,
What I meant in my example is that there is a flow with three branches: A1 is one branch, the switch activity is another branch, and A4 is the third branch of the flow. To avoid further confusion, let me re-write the example more precisely:
<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>
When branch A3 of the switch is NOT taken, then a violation of the control dependency between A1 and A4 can occur (given the current wording in section 12.5.1). Casted in general terms, such violation can occur when during the performance of a structured activity S, the semantics of S dictates that activity X nested within S will not be performed as part of the behavior of S AND in addition activity X has an outgoing link leading another activity outside activity S. This may occur when the activity S in question is either a Switch (as in the above case), a Pick (which for the purposes of this example is the same as a Switch), or a Scope that is "forcefully" halted due to a fault or an explicit termination action (i.e. an "exit").
The idea of forbidding such control links seems to be a little bit radical (although it is a possibility indeed). The idea of re-formulating things in terms of control links proposed by Andrew works fine for Switches (which can be re-formulated in terms of links), but not for Picks and especially not for Scopes that are forcefully terminated. I think that the issue can be better addressed by modifying the paragraph in section 12.5.1 as follows:
"If, during the performance of structured activity S, the semantics of S dictates 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, or activities that were not completed in a scope in which processing was halted due to a fault, including a bpws:joinFailure (see Scopes and Compensation Handlers)"
The key is not to throw negative tokens along the outgoing links of X as soon as it is determined that X will not be executed as part of the behaviour of S. Instead, it is necessary to wait until the status of all incoming links of X has been determined.
In any case, I just wanted in a first instance to gather preliminary opinions. I'll now move to proposing an issue so that we can continue the discussion in the context of that issue.
Kind regards
marlon
-----Original Message-----
From: Satish Thatte
To: Assaf Arkin
Cc: Dumas, Marlon; wsbpel@lists.oasis-open.org
Sent: 4/5/2005 8:21 AM
Subject: RE: [wsbpel] Link semantics and control dependencies
Is there a case other than a link targeting an activity sourced at a
parent activity in the nesting structure? IOW is this an example or the
only case?
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, April 04, 2005 7:40 PM
To: Satish Thatte
Cc: Dumas, Marlon; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Link semantics and control dependencies
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
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]