[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
good point, if that was your intention. i only saw you calling out that reply MUST reference a receive's correlation, and i had a knee-jerk reaction. withdrawn. ----- Original Message ----- From: "Assaf Arkin" <arkin@intalio.com> To: "Danny van der Rijn" <dannyv@tibco.com> Cc: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; <wsbpel@lists.oasis-open.org> Sent: Thursday, July 01, 2004 12:47 PM Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive> > Danny van der Rijn wrote: > > >this would not work for <receive>s that have no correlation. i realize that > >this is bringing other issues in (as to whether such <receive>s are useful), > >but it should be noted nonetheless. > > > > > As the spec currently stands you cannot have two outstanding receive > activities on the same operation/partnerLink without the use of > correlation. If they are for different operation/partnerLink, these two > can be use to disambiguate the receive and match it to the reply. > > Assaf > > > >danny > > > >----- Original Message ----- > >From: "Assaf Arkin" <arkin@intalio.com> > >To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com> > >Cc: <wsbpel@lists.oasis-open.org> > >Sent: Thursday, July 01, 2004 11:19 AM > >Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive> > > > > > > > > > >>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. > > > > > >>> > >>> > >>-- > >>"Those who can, do; those who can't, make screenshots" > >> > >>---------------------------------------------------------------------- > >>Assaf Arkin arkin@intalio.com > >>Intalio Inc. www.intalio.com > >>The Business Process Management Company (650) 577 4700 > >> > >> > >>This message is intended only for the use of the Addressee and > >>may contain information that is PRIVILEGED and CONFIDENTIAL. > >>If you are not the intended recipient, dissemination of this > >>communication is prohibited. If you have received this communication > >>in error, please erase all copies of the message and its attachments > >>and notify us immediately. > >> > >> > >> > >> > > > > > > > > > -- > "Those who can, do; those who can't, make screenshots" > > ---------------------------------------------------------------------- > Assaf Arkin arkin@intalio.com > Intalio Inc. www.intalio.com > The Business Process Management Company (650) 577 4700 > > > This message is intended only for the use of the Addressee and > may contain information that is PRIVILEGED and CONFIDENTIAL. > If you are not the intended recipient, dissemination of this > communication is prohibited. If you have received this communication > in error, please erase all copies of the message and its attachments > and notify us immediately. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]