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: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>

your suggestion looks good to me.

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.


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


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]

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