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

[Alex Yiu <alex.yiu@oracle.com>]

Yuzo,

Thanks for catching this naming issue.
I will send out a formal proposal for voting later by using the name 
"conflictingRequest".


Regards,
Alex Yiu


Yuzo Fujishima wrote:

> 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]
>>
>>
>>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>
>