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


>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

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.



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.


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