OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue - 123 - Proposal to Vote

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.



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]