RE: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete

["Dumas, Marlon" <marlon.dumas@sap.com>]

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