Public Comment

[comment-form@oasis-open.org]

Comment from: m.dumas@qut.edu.au

Re: [wsbpel] Issue 189: Eliminate JoinConditions always evaluating only 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)
</switch>

A4
</sequence>

</flow>

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 bpws:joinFailure."

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
m.dumas@qut.edu.au

Research Fellow
SAP Research Centre Brisbane
marlon.dumas@sap.com