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>


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


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