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