[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]