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

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

Alex,

Just a minor comment: As a fault name, conflictingSomething
sounds more aligned with other fault names than conflictSomething
to me.

Yuzo Fujishima
NEC Corporation.

Alex Yiu wrote:
> 
> Hi, Danny and others,
> 
> Just want to wrap up this issue:
> I guess I still kind of prefer my original wording. Because, the phrase 
> of "cause the overall state to become illegal" is too subtle ... on 
> which receive operation get faulted.
> 
> I guess the original wording is kind of better:
> _the conflicting receive activities subsequent to the execution of __the 
> first incomplete receive_.
> 
> Upon retrospection, the word "first" can be interpreted in a strange 
> way. Here I suggest to change wordings to:
> _the conflicting receive activities subsequent to the execution of 
> __*the successful *incomplete receive_.
> 
> If it sounds good to people, I will make a formal proposal to vote.
> 
> 
> Thanks!
> 
> 
> Regards,
> Alex Yiu
> 
> Danny van der Rijn wrote:
> 
>> would it be consistent with your proposal to word (b) : any receive 
>> which, if executed, would cause the overall state to become illegal.
>>
>> Alex Yiu wrote:
>>
>>>
>>> Hi, all,
>>>
>>> After thinking about the situation mentioned by Yuzo more, I would 
>>> like to mention a few points:
>>>
>>>     * I can see the "conflictReceive" fault conditon in the terms of
>>>       matching receive-reply is quite different from in terms of
>>>       "conflictReceive" fault condition in terms of the maintaining
>>>       the uniqueness of partnerLink, operation, CS in the existing
>>>       spec text. Hence, I would agree with Yuzo's previoius
>>>       suggestiont to use "*conflictRequest*" in the context of Issue
>>>       123 to avoid further confusion.
>>>     * Regarding to whether we can enforce that fault "MUST be  thrown
>>>       within the BPEL process on all the conflicting receive
>>>       activities", I would agree with with Yuzo again. The
>>>       "*conflictRequest*" fault can be detected only at runtime. By
>>>       the time when the second duplicated receive is executed, the
>>>       first receive is finished already. It just needs a reply
>>>       activity to complete the request-reply pattern.
>>>
>>>       It can be confusing to users, if we fault the flow/thread which
>>>       has executed the <receive> activity. Moreover, it is possible
>>>       to have a <receive> activity in one flow and its matched
>>>       <reply> activity in the other flow. (Though this is a very
>>>       minority design pattern.)
>>>
>>> Therefore, I suggest two minor changes in this proposal:
>>> (a) "conflictReceive" => "conflictRequest"
>>> (b) "all the conflicting receive activities" => "the conflicting 
>>> receive activities subsequent to the execution of the first 
>>> incomplete receive."
>>>
>>> I know the wordings in (b) is kind of clumsy. If someone find a more 
>>> elegant way to express the same semantics, please feel free to 
>>> re-word it. :-)
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Regards,
>>> Alex Yiu
>>>
>>>
>>>
>>> Here is the updated version of the proposal according to my suggestion:
>>> -----------------------------------------------------
>>> 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 first 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>.)
>>> -----------------------------------------------------
>>>
>>>
> [stuff deleted]
> 
> 
>