[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
For me the issue is the overhead. I think that introducing a messageExchange element introduces an unnecessary amount of overhead. Also, I have no problem using the same ID on two receives. Yaron Yuzo Fujishima wrote: > > > 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. > > > > > > > > > > > > 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]