Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>

[Yuzo Fujishima <fujishima@bc.jp.nec.com>]

Hi,

I don't understand how the following will be enforced:

 > If there should ever be multiple simultaneous incomplete receive
 > activities which have the same partnerLink, operation and
 > messageExchange tuple then the *bpws:conflictingReceive* fault MUST be
 > thrown _within the BPEL process_ on all the conflicting receive activities.

By the time the second of the conflicting receive activities is executed,
the first one could have received a message and completed. How could
a fault be thrown for the first one?

Example:
1. Receive activity A starts.
2. A message is delivered to A. A completes. Note that
    A is still incomplete because no reply has been sent yet.
3. The control reaches receive activity B.
    It turns out that B is conflicting with A.
4. B throws a fault.
    But what must/can be done for A, which has been completed
    already?

We might want to modify the rule such that the second
and later conflicting receives throw a fault while the
first one survives.

Yuzo Fujishima
NEC Corporation

Alex Yiu wrote:

> 
> Hi, all,
> 
> Here is the draft proposal for Issue 123. It is based on Yaron's text 
> sent out few days ago.
> It contains a terminology change: (i) from "usage" to "messageExchange" 
> (as some people agree with the general idea of this proposal but don't 
> like the terminology) and (ii) from "triple" to "tuple" (that is my 
> personal preference).
> 
> Bernd and Yuzo had some further input and clarification requests, which 
> I have incorporated. They are marked with underline here.
> 
> -----------------------------------------------------
> 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:conflictingReceive* fault MUST be 
> thrown _within the BPEL process_ on all the conflicting receive activities.
> 
> _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>.)
> -----------------------------------------------------
> 
> 
> Thanks!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
>