Issue - 123 - Proposal to Vote

-----------------------------------------------------

A reply activity is associated with a receive activity based on the
tuple - partnerLink, operation, and messageExchange. The value defined
in messageExchange is scoped to the combination of partnerLink and
operation. That is, it is legal to use the same messageExchange value
in multiple simultaneously incomplete receive activities so long as the
combination of partnerLink and operation on the receives are all
different from each other. An incomplete receive describes the state of
a BPEL process from the point that a request/response receive activity
starts execution until its associated reply begins execution.

If there should ever be multiple simultaneous incomplete receive
activities which have the same partnerLink, operation and
messageExchange tuple then the bpws:conflictingRequest fault
MUST be thrown within the BPEL process on the conflicting
receive activities subsequent to the execution of the
successful incomplete receive.

If a reply activity cannot be associated with an incomplete
receive
activity by matching the tuples and this error situation is not caught
during static analysis,  then bpws:missingRequest fault MUST be
thrown
within the BPEL process on the reply activity. Because
conflicting requests should have been rejected at the time
<receive> is executed, there cannot be more than one
corresponding <receive> at the time <reply> is executed.

If the messageExchange attribute is not specified on a receive then its
value is taken to be empty. For matching purposes two empty
messageExchange values on receives with the same partnerLink and
operation values are said to match. Empty value does not match with
other non-empty values. 

(Please note: there are existing text paragraphs in the spec, which
enforces
that no
more than one <receive>s are waiting for a message associated
with the same partner link, port type, operation, and correlation sets.
This constraint still exists and will not be affected by the proposal
of Issue 123. This proposal simply add one more constraint to receive,
when <reply> are needed to be associated with <receive>.) 

-----------------------------------------------------