[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
Yaron, I admit that adding messageExchanges element seems a bit overkill, especially after we remove the pattern attribute from messagExchange element. I think we should do something here. Dropping the element is a viable option. But I still think giving an ID to a message exchange is better than giving an ID to a receive, because the former can better handle the cases where more than two receives exist for a reply, (for example, two receives in a switch). If you don't mind giving the same ID to two receives, I think we are proposing effectively the same thing, i.e., what you call receive ID = what I call message exchange ID. The only difference is in the conceptual models, i.e., reply references receive vs. reply and receive belong to a same message exchange instance. PS Defining messageExchanges element has an advantage of making the scope and the lifetime of the MEP instance clearer. (with significant overhead, I admit.) Yuzo Fujishima NEC Corporation Yaron Y. Goland wrote: > To me it seems rather intuitive that I would slap an ID on a receive and > then put the same ID on a reply. I am having trouble, however, seeing > the value in adding yet another entity, messageExchange, to BPEL adds > value over just using IDs? I do, however, see how it will make things > more complex as now, rather than just declaring an ID on the receive and > using it on the reply, the programmer first has to declare a > messageExchange first. > > So I'd have to throw my support behind the original R1 proposal without > the introduction of messageExchange. But I'm happy to be educated. > > Thanks, > > Yaron > > Yuzo Fujishima wrote: > >> >> >> 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. >> >> >> >> 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]