[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
Danny, First, conclusions: I admit "pattern" may introduce more trouble than benefit, if any. I would like to remove the pattern attribute from the resolution idea. Then, any way, the explanation: I think pattern has four possible values: in-out, out-in, in, and out. in-out: outside-originated request-response out-in: inside(process)-originated request-response in: receiving notification. out: sending notification. For <reply>, only "in-out" applies. But for <receive>, "in-out" or "in" can be valid. in-out: receiving request. in: receiving notification. Similarly, for <invoke>, "out-in" or "out" can be valid. out-in: sending request and receiving response. out: sending notification. By specifying "in" for a <receive>, we can express that writing a <reply> for this <receive> is invalid (without consulting WSDL). For <invoke>, specifying pattern is probably just redundant, because it can be known from the existence of outputVariable attribute. So, I think pattern attribute is not very useful. Sorry for the confusion. Yuzo Fujishima NEC Corporation Danny van der Rijn wrote: > i like your R1 solution, and that it can be omitted if it is not necessary > for disambiguation, but think that the "pattern" attribute has no place > here. how would it be validated? what exactly is it for? > > danny > > ----- Original Message ----- > From: "Yuzo Fujishima" <fujishima@bc.jp.nec.com> > To: <wsbpel@lists.oasis-open.org> > Sent: Tuesday, June 29, 2004 6:59 PM > 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 >> >>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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]