WG: [wsbpel] Issue 189: Eliminate JoinConditions always evaluatingonly after all source activities are complete

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

[This message from Marlon Dumas did not reach the TC mailing list]

-----Ursprüngliche Nachricht-----
Von: Dumas, Marlon 
Gesendet: Mittwoch, 16. Februar 2005 04:08
An: andrew.francis@mail.mcgill.ca; Danny van der Rijn
Cc: wsbpel@lists.oasis-open.org; m.dumas@qut.edu.au; Trickovic, Ivana
Betreff: RE: [wsbpel] Issue 189: Eliminate JoinConditions always evaluatingonly after all source activities are complete


Dear Andrew,

I think that we agree, and your formulation of the problem is much simpler. The central question of the example is whether A4 will be pending (i.e. not started) until A1 has completed. By expanding the example in terms of control links you show that, given the current spec., this is the case and thus we fully agree on this point.

Then, the comment that you make in the last paragraph adds more information about the semantics of control links: 

> I suppose a smart BPEL runtime with good dependency graph support
> could ignore A3 and start A4 after switch made a decision and no harm
> done.

This suggests that the behavior of control-links in terms of traces could be captured by the following statement:

"A control link from activity B to activity C implies a 'control dependency' from B to C. A 'control dependency' from B to C means that, in any given execution trace, B (if it is present) precedes C. In the case where B and C are nested within a loop, this statement must hold for each iteration of this loop."

In this interpretation, A4 can start immediately after A2 has completed, simply because A3 will not be executed anyway (and thus the situation where A4 appears before A3 in the trace cannot occur). Interestingly, the above definition of "control dependency" is not transitive. In the working example (formulated using control-links) there is a link from A1 to A3, and a link from A3 to A4, and yet there is no control dependency from A1 to A4 since A4 may complete before A1 completes (assuming a "smart BPEL engine with good dependency graph support").

If the current spec. was "refined" by incorporating the above statement, it would resolve issue 189 (if the issue was opened). By the same token, it would allow for the type of optimizations pointed up by the above example, and it would provide a good reference point for BPEL implementations. Of course, an alternative way of proceeding with issue 189 would be to lift the restriction that "a control link implies a control dependency", and then the semantics of control links in terms of traces would likely be more complicated.

In any case, thanks for answering my question with such precision.

marlon

-----Original Message-----
From: andrew.francis@mail.mcgill.ca [mailto:andrew.francis@mail.mcgill.ca] 
Sent: Wednesday, 16 February 2005 7:17 AM
To: Trickovic, Ivana
Cc: wsbpel@lists.oasis-open.org; m.dumas@qut.edu.au
Subject: Re: WG: [wsbpel] Issue 189: Eliminate JoinConditions always evaluatingonly after all source activities are complete

Hello:

>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".
I do not believe there is a contradiction. This is because
I believe your scenario does not properly describe the
behaviour. I feel your scenario can be described in a 
fashion consistent with link semantics and dead path
elimination. It is just that constructs like sequence and
switch are fundamentally syntatic sugar that sometimes hides
howlink semantics and DPE works. I feel this can cause
trouble in analysing cases.

An illustration:

Lets re-write your BPEL fragment into simpler,
linked based BPEL fragment. I believe this linked
based model describes the behaviour of the higher
level fragment that uses switch and sequence. I am
using the links to preserve the logical ordering.
I use the appropriate transition conditions and
joinConditions to ensure the intended activities
internal behaviour is executed according to link
semantics.

The BPEL fragment is represented in table form.
Activities in the left column are dependent on
activities on the right. The rules of section 12
apply.  For brevity I have not included sequence.
Also the joinCondition fault is surpressed. Pending
refers to an activity waiting for all its incoming
(target) links to have a value before the joinCondition
is evaluated.

links:

envToA1
envToSw
a1Toa3
swToA2
swToA3
a2ToA4
a3ToA4

switch | env
A1     | env
A2     | switch
A3     | A1, switch
A4     | A2, A3

1) switch and A1 execute in parallel.

2) Depending on switch's internal computation it will
   set the transition conditions on swToA2 and swToA3.
   In this case, sw sets swToA2 to true and swToA3 to false.

3) A2's joinCondition is getLinkStatus(swToA2) = True.
   A2 can execute.

4) A3's joinCondition is getLinkStatus(swToA3) = True AND
   getLinkStatus(a1ToA3) = True. Since A1 has not finished,
   A3 is pending.

5) A2 finished. A4's joinCondition is TRUE (Danny in
   regards to 188, take note) Since A3 is pending,
   A4 is pending.

6) A1 finishes and sets a1ToA3 to true.

7) Now A3 can evaluate its joinCondition. Since
   getLinkStatus(swToA3) is false, the joinCondition
   evaluates to false. DPE now kicks in, A3's internal
   action is skipped and A3 sets A3toA4 to false.

8) A4 now can evaluate its joinCondition. Since
   the joinCondition is always true, it executes.

This I believe describes the proper behaviour. To me
what is important is that the logical ordering or trace
is preserved and the programmer's intended activities
are executed. In this case, A2 and A3's execution are
mutually exclusive, and A4 can only execute after
either A2 or A3 finishes. I do not see how things
like "synchronization of garbage token collection"
add to the fundamental understanding of how WS-BPEL's
scheduling works.

That said, I think it is okay if an implementation
decides to perform an optimization as long as the
fundamental behaviour is preserved. Language compilers
and VLSI tools do this all the time. In your case, I
suppose a smart BPEL runtime with good dependency graph
support could ignore A3 and start A4 after switch made
a decision and no harm done. The problem here
understanding the proper behaviour.

Cheers,
Andrew