Issue - 123 - Proposal to Vote

["Yaron Y. Goland" <ygoland@bea.com>]

I propose that we close issue 123 with no action.

The logic for this proposal is that anytime there is a conflict between 
receives it can be resolved by introducing new partnerLinks. Hence we 
can resolve the problem without having to add any features to the spec.

	Thanks,

		Yaron

Alex Yiu wrote:

> 
> -----------------------------------------------------
> 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>.)
> -----------------------------------------------------
>