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

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

Assaf,

Assaf Arkin wrote:
> Yuzo Fujishima wrote:
> 
>> (To: Asaaf
         ===== Sorry for the misspell here.

>> Please reply to this message because the previous one have not
>> reached the wsbpel mailing list.)
>>
>> Do you think the message to be sent by <reply> must contain
>> the message properties that match the specified correlation set(s)?
> 
> 
>>
>> If the answer is yes, we don't need any new mechanisms.
>>
>> My guess is that we want to say no, for example, to
>> accommodate simple yes/no reply message. Then we need
>> a new mechanism.
> 
> 
> Are you talking about generic request/response, or the case where you 
> have two (or more) outstanding requests on the same 
> partnerLink/operation? The correlation set only affects the latter. So 

I am talking about the latter. My assumption is that we need to
specify only as many correlation sets as necessary to disambiguate
the receive-reply correspondence.

> the simple case remains simple, and I would hate for it to become more 
> complicated, but I don't see a clear need for a referencing mechanism. 
> As for two outstanding on same partnerLink/operation, in all the use 
> cases I could imagine for doing this, I would use message properties in 
> the response.

OK. I think I understand your position. Let me confirm it.
Suppose two receives with the same partner link, port type,
operation but different correlation sets are outstanding.
Following your rule, then the messages to be sent by two reply's must
contain the message properties that are referenced by the correlation
sets used for disambiguation. Do I understand you correctly?

Further suppose that the above two request-response are performed
synchronously using two connections, for example, via plain SOAP
invocation. I think this is a very common case.
Then the client sides don't need any message properties for correlation,
because the responses are sent back in the same connections as for requests.
Do you think it is OK to request the reply messages contain message properties
in this case?

Yuzo Fujishima
NEC Corporation

> 
> Assaf
> 
>>
>> Yuzo Fujishima
>> NEC Corporation
>>
>>
>> Assaf Arkin wrote:
>>
>> > Let's say that the spec was writting with this rule:
>> > ".... the reply has to reference the same correlation set (name and 
>> scope) as the receive, if the receive has multiple correlation sets 
>> the reply only needs to reference one of them"
>> > To me this seems to be identical to R1 in that it proposes a naming 
>> mechanism that links the receive to the reply, and at first read it 
>> seems identical to the MEP idea.
>> >
>> > I'm leaning towards an understanding that the spec allows for a 
>> supserset of this behavior, but without precluding this usage. Of 
>> course, it all depends on how you read it. But if our concern is to 
>> make the simple case simple, I think that the spec currently allows us 
>> to do that, it's just not written to highlight the simple case.
>> >
>> > Assaf
>> >
>> > Yuzo Fujishima wrote:
>> >
>> >> Hi,
>> >>
>> >> The following are
>> >>   the summary of our discussion at the F2F and
>> >>   a few new ideas
>> >> on "Issue 123: Matching <reply> with <receive>".
>> >>
>> >> Please let me know what you think.
>> >>
>> >> ==== Resolution Ideas ====
>> >>
>> >> We currently have four kinds of resolutions for Issue 123:
>> >>
>> >> R1: Explicit disambiguation through ID and REF (Bernd, Yaron)
>> >> R2: Restrict the use of correlation sets (Paco)
>> >> R3: Resolution-only correlation sets (Yuzo)
>> >> R4: Pattern attribute for reply correlation sets (Chris)
>> >>
>> >> For R1, R2, R3, please refer to 20040622-issue123.ppt, which is
>> >> available at the document page of the WSBPEL web site, in addition to
>> >> the email messages regarding Issue 123.
>> >>
>> >> R4 was proposed by Chris at the F2F. The idea is that we specify 
>> pattern=
>> >> "in" for a correlation set specified for a <reply> to indicate that 
>> the
>> >> correlation set is actually for the incoming message, that is, the 
>> message
>> >> received by <receive>, rather than the outgoing one to be sent by the
>> >> <reply>. This way we can specify as many correlations sets for 
>> <reply> as
>> >> necessary for disambiguation, while not requiring the reply message to
>> >> contain the correlation sets properties. R4 is similar to R3, but 
>> seems
>> >> to be better-aligned with the current BPEL specification.
>> >>
>> >> After all the discussion at the F2F, I still feel R1 or similar is
>> >> preferable to the rest because I guess that when writing 
>> <activity>, the
>> >> process designer should have <receive>(s) in mind, rather than the
>> >> correlation set(s).
>> >>
>> >> Accordingly, I elaborate only on R1 below. If you prefer R2, R3, 
>> R4, or
>> >> something else, please elaborate on your choice and share the idea.
>> >>
>> >> ==== Elaboration on R1 ====
>> >>
>> >> In a personal conversation, Satish has suggested that we should 
>> give an
>> >> ID to a MEP instance rather than to a <receive>. I think it is a 
>> good idea.
>> >> It can naturally handle the cases where multiple <receive>s and 
>> <reply>s
>> >> are written in the process definition for a single message exchange 
>> pattern.
>> >> (At run-time, only one of each is executed.) I try to materialize the
>> >> suggestion below.
>> >>
>> >> 1. Introduce <messageExchanges> element.
>> >>
>> >> <scope or process>
>> >>   <messageExchanges>?
>> >>     <messageExchange name pattern?/>*
>> >>   </messageExchanges>
>> >> </scope or process>
>> >>
>> >> 2. Introduce messageExchange attribute.
>> >>
>> >> <receive messageExchange? ...>
>> >> <onMessage messageExchange? ...>
>> >> <onEvent messageExchange? ...>
>> >>
>> >> 3. Define the receive-reply matching rule as follows.
>> >>
>> >> Correlation sets of <reply> are not considered in matching at all.
>> >>
>> >> If messageExchange attribute is specified for <reply>, outstanding
>> >> <receive>s (or <onMessage>s or <onEvent>s) that make reference to 
>> the same
>> >> messageExchange are searched.
>> >>
>> >> If messageExchange attribute is NOT specified, outstanding 
>> <receive>s that
>> >> have matching partnerLink, portType, and operation are searched.
>> >>
>> >> If there is only one such <receive>  (or <onMessage> or <onEvent>) 
>> and it
>> >> has matching partnerLink, portType, and operation, then the <reply> is
>> >> matched to it. If not, a conflictingRequest fault is thrown. (Note: 
>> We may
>> >> want to introduce another fault for zero <receive> case.)
>> >>
>> >> 4. Example
>> >>
>> >> <scope or process>
>> >>   <messageExchanges>
>> >>     <messageExchange name="rfq-quote" pattern="in-out"/>
>> >>   </messageExchanges>
>> >>
>> >>   ...
>> >>   <switch>
>> >>     <case>
>> >>       ...
>> >>       <receive messageExchange="rfq-quote" ...>
>> >>       ...
>> >>     </case>
>> >>     <otherwise>
>> >>       ...
>> >>       <receive messageExchange="rfq-quote" ...>
>> >>       ...
>> >>     </otherwise>
>> >>     ...
>> >>   </switch>
>> >>   ...
>> >>   <reply messageExchange="rfq-quote">
>> >>     ...
>> >>   </reply>
>> >>   ...
>> >> </scope or process>
>> >>
>> >> 5. Discussion
>> >>
>> >> I am not sure whether we really need the pattern attribute. It may be
>> >> useful for validation, but may be cumbersome to specify. Hence I 
>> make it
>> >> an optional attribute.
>> >>
>> >> As pointed in 3, we may want to introduce a new fault for matching 
>> failure.
>> >>
>> >> ==== onMessage and onEvent ====
>> >>
>> >> As I already did above, I think onMessage and onEvent must be 
>> modified such
>> >> that it can have messageExchange attribute if necessary.
>> >>
>> >> ==== multiple receives in a loop ====
>> >>
>> >> During the F2F discussion, it was pointed out that we currently 
>> have no
>> >> means to express the correspondence between <receive>s in a loop and
>> >> <reply>s outside of the loop.
>> >>
>> >> <while>
>> >>   ...
>> >>   <receive ...>
>> >> </while>
>> >>
>> >> <while>
>> >>   ...
>> >>   <reply ...>
>> >> </while>
>> >>
>> >> I think this is an important problem but too big to discuss in 
>> Issue 123.
>> >> We may need to introduce arrays of partner links, for example. Hence I
>> >> would like to consider it a separate issue.
>> >>
>> >> Yuzo Fujishima
>> >> NEC Corporation
>> >>
>> >> 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. 
>>
>>
>>
>>
>>
>> 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. 
>>
>>
> 
>