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: WG: [wsbpel] Issue 189: Eliminate JoinConditions always evaluatingonly after all source activities are complete

This message from Marlon Dumas did not reach the TC mailing list (because Marlon is still not a member of the TC). So, I am forwarding it to the list.  



-----Ursprüngliche Nachricht-----
Von: Marlon Dumas [mailto:m.dumas@qut.edu.au] 
Gesendet: Dienstag, 15. Februar 2005 10:04
An: wsbpel@lists.oasis-open.org
Cc: Rania Khalaf; ygoland@bea.com; dannyv@tibco.com; Trickovic, Ivana
Betreff: [wsbpel] Issue 189: Eliminate JoinConditions always evaluatingonly after all source activities are complete 

I would like to point out that the question of "short-circuited 
evaluation of join conditions" raised by issue 189 is related to another 
question that has not yet been considered and that I would like to term: 
"synchronization for garbage token collection". To introduce and 
illustrate this latter question, consider the following example (I use a 
pseudo-BPEL notation to avoid cluttering the presentation with 
unnecessary details):

<flow name="F">
A1 (activity A1 is source of a link named l1)

<sequence name="Seq">
<switch name="Sw">
   case C1: A2
   case C2: A3 (activity A3 is target of link l1)



Let's assume that the flow activity F starts, thereby starting 
activities A1, Seq, and Sw. Now, let's assume that condition C1 
evaluates to true, thereby starting activity A2. Now assume that 
activity A2 completes (but A1 is still ongoing). The question is: Should 
activity Sw be considered to be completed at this point (which would 
result in activity A4 being started), or should we wait until link l1 is 
determined so that the join condition defined at A3 can be evaluated? 
(Note that the evaluation of the join condition at A3 is irrelevant, 
since the branch of the switch in which A3 is located was not chosen and 
thus A3 is not executed and negative tokens are thrown along any links 
leaving A3). If the answer to this question is that Sw is considered to 
be completed, and thus A4 is started, then we see that A4 can be 
executed even though A1 has not completed, which contradicts the 
principle that "a control-link implies a control dependency".

Generally speaking, it is important to note that a switch activity Sw, 
such that there is a link leading to a sub-activity of Sw (whether a 
direct sub-activity of Sw, or a sub-activity nested deep inside Sw), 
potentially implies a garbage collection of the true/false token that 
will transit through this link. The question is: "Should this garbage 
token collection be completed before the switch activity is considered 
to be completed?" I term this question "synchronization for garbage 
token collection".

The question of synchronization for garbage token collection is related 
to that of short-circuited evaluation of join conditions. Indeed, if we 
follow the principle that "a control link implies a control dependency", 
then: (i) short-circuited evaluation of join conditions is NOT possible; 
and (ii) all "garbage tokens" that are expected to transit through links 
leading into branches of a switch or pick that are not taken (or into 
scopes that have been halted due to an event or fault), must be 
collected before the switch/pick/scope activity is considered to be 
completed. In the example above, this second condition would prevent A4 
from being started before A1 has completed.

On the other hand, if it is decided that "a control-link does not imply 
a control dependency", then the space of design choices is open and four 
alternative design choices are possible depending on the answers to the 
two questions: (i) is short-circuited evaluation of join conditions 
allowed (yes or no)? and (ii) should synchronization for garbage token 
collection always occur (yes or no)? (Note that since links are not 
allowed to cross the boundaries of serializable scopes and loops, the 
question of garbage token collection does not apply to them).

These considerations illustrate the importance of carefully answering 
the question: "Do control links imply control-flow dependencies?" The 
implications of a negative answer to this question are more far-reaching 
than just allowing for short-circuited evaluation of join-conditions, 
which was the primary focus of the discussions leading to issue 189.

Also, issue 189 may have strong impact on the following sentence of the 
current spec:

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, or activities that were not completed in a scope 
in which processing was halted due to a fault, including a 

A question to be considered here is: Should the status of the outgoing 
links from X be set to negative (and thus the activity that is the 
target of X possibly allowed to proceed) even though there may be links 
whose target is X that have not yet been determined at this point? If 
so, this breaks the principle that "a control link implies a control 
dependency", since the activities that "precede X" (i.e. they are source 
of a link leading to X) may not yet be completed.

Note that this latter question may need to be treated separately from 
the above.

Marlon Dumas
Senior Lecturer
Queensland University of Technology

Research Fellow
SAP Research Centre Brisbane

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