[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
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. 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]