Accept Bernd’s proposal to resolve by clarifying the wording in the spec. His proposed wording is included below. Based on a straw poll at the f2f (24 yes (unamimous among attendees, 1 abstention due to phone line noise) your support for this ballot is recommended. See associated link to minutes for more information.
Specific text from Bernd's email:
"The editing team is aksed to include an explanation, that processing of messages with legal outstanding correlations may be received after the correlation set is instantiated but before the actual receive is activated. Modellers can asume, that it is safe to rely on this (since there is no bpel onstruct to implement it otherwise)."
We agreed to not add a definition in which case it is legal/required for the engine to to look ahead and what timeouts to asume. Therefore it is not possible to include samples like "receive or a callback in a seuqnece directly after the invoke". I have also worded the recommendation to adress the modellers expectations and not to explicitely define requirements to the engine, since we are not yet down that conformance definition road in other places.
There are other places where the bpel spec does not require a specific timing (e.g. invoke and receive in parallel in a flow), where the same expectations of the modeller should be acknolwledged. |
