[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete
Hi Andrew, > I feel the WS-BPEL specification would be strengthened > and many time wasting debates avoided, if the authors > of key passages stated their intent and if a well understood > design philosophy existed. In the specific case of issue 193, the "authors" have previously stated the purpose of the constraints on joinCondition evaluation (though for some reason this explanation did not make its way into the spec). Specifically, in pages 143-144 of their book "Production Workflow", Leymann and Roller write: "For a better control in synchronous work, a join activity has a join condition associated to it. [...] To perform a join activity: (1) The transition conditions [called "link status" in BPEL] of all its incoming control connectors [called control links in BPEL] must have been evaluated [i.e. determined] before the truth value of the join condition is computed, and (2) Its associated join condition must be true. The purpose of (1) is twofold. It ensures that parallel work is really synchronized at the join nodes: work along paths which could finally reach a join node must be completed before the join node can be started. Second, it ensures that a join condition can be evaluated." In order to address issue 193, the last paragraph of this quote (with some re-wording) could be included in the spec. An interesting point about the above formulation is that, while it precludes the activity after the join condition to be started before all incoming links have been determined, it does not preclude a BPEL engine from determining to "skip" the activity after the join condition and to propagate false values along its outgoing links, as soon as it can be determined that the truth condition will evaluate to FALSE no matter what. In the last paragraph of your e-mail dated 15 February Re: issue 189, you suggested that this latter "optimization" is okay. I insist that the question is to determine whether this "optimization" should be allowed or not. If it is allowed, then the above formulation is OK (or the formulation that I suggested in my previous e-mail as well). If this optimization is not allowed, then the above formulation should be expanded to preclude it. Cheers marlon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]