[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
I appreciate the desire to not add new syntax and to re-use existing mechanisms but we risk overloading those mechanisms to the point where users become hopelessly confused about what to do when. What makes the receive/reply correlation fundamentally different than what correlation sets normally do is that receive/reply correlation is 'inward facing' (e.g. is something that is strictly internal to the process) and correlation sets are 'outward facing' (e.g. have to do with the process's relationship with other processes). So I think it's fine to use two different mechanisms to cover two largely unrelated use cases. I suspect the simplest possible solution is to provide for some kind of dedicated ID attribute that can be placed on receives and replies that need to be correlated internally. Just my two cents, Yaron Yuzo Fujishima wrote: > > > Paco, > > Should we make it a rule that the message sent by <reply> > must contain the correlation set(s) specified? > > In my opinion, the rule is too restrictive because > the client may not require correlation sets embedded > in the message, especially in synchronous request/response > cases; there's no ambiguity for the client. > > Currently, there are two overloaded usages for reply c-set: > U1: To identify corresponding receive. > U2: To enable message correlation. > > I am afraid sometimes the two usages conflict with each other. > I think this overload is (a part of) the source of the > difficulty. > > In my view, Bernd's proposal is one way to resolve the overload. > Another may be introducing a new attribute for correlation set > to express that the c-set is only for request disambiguation > and not for message properties restriction, e.g., > > <correlation set="cs1" type="requestResolution"> > > Yuzo Fujishima > NEC Corporation > > > Francisco Curbera wrote: > > > > > > > > > I think Yuzo's question #1 is the same as issue 26. I suggest we > close 26 > > as it is contained in 123. > > > > I don't like Bernd's proposal of limiting to one the number of > replies per > > receive; the loss of expressiveness is too great. I happen to agree with > > the view that correlation sets should be used to disambiguate replies, > > since we already use correlation sets to disambiguate receives. I also > > agree that if there are no conflicting receives there should be no > > restriction of course. > > > > The only problem is how to define a match and keep all the > flexibility. For > > example, I would like to have one synchronous receive-reply pair > which does > > not need correlation, as long a other conflicting pairs can be matched > > based on one or more sets. The initial pair matches then on the "empty" > > set. However, I may also want to use the reply of the synch pair to > > transmit a correlation value back to the invoker (the cset could have > been > > initialized in a prior interaction with a different partner for > example). > > In that case we have an ambiguous match since this time the reply has an > > empty match with more than one receive. Likewise, a reply may match two > > different subsets of its csets with two different receives. > > > > I think the only way out is to restrict the use of correlation sets > on the > > conflicting receive/reply pairs; after all, the case of conflicting > > receives is possibly an uncommon one. Introducing additional syntax to > > match receive and replies is also an option if the restrictions seem > unduly > > severe, but I'd prefer to avoid new syntax if possible. > > > > A possible restriction is this: in the presence of conflicting receives, > > every reply activity must include at least one cset that matches a cset > > present in one of the conflicting receives, and it may not contain csets > > matching more than one of them. We can extend this rule by allowing one > > receive and one or more matching replies that carry no correlation > set at > > all; this allows simple synchronous interactions but limits the > ambiguity > > of the "empty" set match. > > > > I guess other variations are possible; the difficult part is keeping the > > rule simple while avoiding ambiguity. > > > > Paco > > > > > > > > > > > > > > > "Eckenfels. > > > > Bernd" To: > <wsbpel@lists.oasis-open.org> > > > > <B.Eckenfels@seeb > cc: > > > > urger.de> Subject: [wsbpel] > Issue - 123 - Matching <reply> with <receive> > > > > > > > 05/18/2004 > 10:37 > > > > > AM > > > > > > > > > > > > > > > > Hello Satish, > > > > yes, exactly. as i said this is a bit less flexible as the current > > sematics, but a lot less confusing. Basically it forces the modeller to > > explicitely model every possible execution path which can lead to a > result. > > I think this is a good restriction. > > > > It better captures the intend of a process description. > > > > Another possible option would be to make a receive operation for an > two-way > > request an container, which returns the result on leaving this > container. > > Thats another way of strictly binding and even more structures the > process, > > but it also is even more inflexible, I think it fails short for > concurrent > > processing. > > > > <sequence> > > <receive pl="pl" pt="pt" op="op" id="123" variable="request" /> > > ... > > <reply ref="#123" variable="response" /> > > </sequence> > > > > > > In fact I think it is quite uncommon to have different possible recieves > > terminated with the same reply. > > > > Mit freundlichen Grüßen > > Bernd Eckenfels > > Chief Architect > > -- > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > mailto:b.eckenfels@seeburger.de - http://www.seeburger.de > > > > > > -----Original Message----- > > From: Satish Thatte [mailto:satisht@microsoft.com] > > Sent: Tuesday, May 18, 2004 12:45 AM > > To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Q: Matching <reply> with <receive> > > > > > > I don't see how id/ref is generally usable. Are you assuming that a > reply > > is always bound to a syntactically unique receive? > > > > -----Original Message----- > > From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] > > Sent: Monday, May 17, 2004 3:22 AM > > To: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Q: Matching <reply> with <receive> > > > > Personally I like a tighter binding of the reply to the receive. For > > example using a id/idref scheme. That way not all the currently legal > reply > > stuff is possible, but on the other hand, it is much cleaner to > implement, > > and perhaps even to understand. > > > > Mit freundlichen Grüßen > > Bernd Eckenfels > > Chief Architect > > -- > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > mailto:b.eckenfels@seeburger.de - http://www.seeburger.de > > > > > > -----Original Message----- > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > Sent: Thursday, May 13, 2004 8:26 PM > > To: Satish Thatte; Yuzo Fujishima; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Q: Matching <reply> with <receive> > > > > > > I would assume that it should be fine as long as the reply has enough CS > > information to disambiguate. So, in Yuzo's example, > > > > reply name="rep1" partnerLink="pl" portType="pt" operation="op" > > correlation set="cs3" initiate="no" > > > > should be acceptable. > > > > If, on the other hand, the reply does not have enough CS information to > > disambiguate, "the semantics of the process is undefined", the same way > > it happens when two identical receive's are outstanding (so that we > > don't know which one to respond to). > > > > Ugo > > > > > >>-----Original Message----- > >>From: Satish Thatte [mailto:satisht@microsoft.com] > >>Sent: Thursday, May 13, 2004 9:22 AM > >>To: Yuzo Fujishima; wsbpel@lists.oasis-open.org > >>Subject: RE: [wsbpel] Q: Matching <reply> with <receive> > >> > >> > >>Yuzo, > >> > >>Synchronous reply does not need correlation unless there is a > >>problem of disambiguating the matching receive. This I > >>believe answers your second question. > >> > >>Your first question is interesting in that we have not > >>clearly stated what the minimum requirements for > >>disambiguation are. Thus having the two outstanding receives > >>you showed is legal because they are differentiated by csets. > >> But what is needed in a reply if, for instance, both > >>receives correspond to synchronous operations? The easy > >>answer is that it should be one of the csets that is not > >>common with the others. But what if the reply message does > >>not contain the corresponding properties? We need to think > >>about this more. > >> > >>Thanks for bringing it up. > >> > >>Satish > >> > >>-----Original Message----- > >>From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] > >>Sent: Thursday, May 13, 2004 12:51 AM > >>To: wsbpel@lists.oasis-open.org > >>Subject: [wsbpel] Q: Matching <reply> with <receive> > >> > >>Hi, > >> > >>I have a few questions about the rule of matching <reply> > >>with <receive>. > >> > >> > >>[Q1] Must <reply> always specify all the correlation sets > >>specified by the corresponding <receive>? > >> > >>For example, if there are two <receive>'s outstanding as follows, > >> > >> receive name="rec1" partnerLink="pl" portType="pt" operation="op" > >> correlation set="cs1" initiate="no" > >> correlation set="cs2" initiate="no" > >> correlation set="cs3" initiate="yes" > >> correlation set="cs4" initiate="yes" > >> > >> receive name="rec2" partnerLink="pl" portType="pt" operation="op" > >> correlation set="cs1" initiate="no" > >> correlation set="cs2" initiate="no" > >> correlation set="cs5" initiate="yes" > >> correlation set="cs6" initiate="yes" > >> > >>Must a <reply> specify all of the corresponding <receive>'s > >>CS's? That is, for rec1, > >> reply name="rep1" partnerLink="pl" portType="pt" operation="op" > >> correlation set="cs1" initiate="no" > >> correlation set="cs2" initiate="no" > >> correlation set="cs3" initiate="no" > >> correlation set="cs4" initiate="no" > >> > >>Or only as many as necessary to disambiguate the matching? > >> reply name="rep1" partnerLink="pl" portType="pt" operation="op" > >> correlation set="cs3" initiate="no" > >> > >>[Q2] Does it follow that if a <receive> specify a correlation > >>set, the corresponding reply can only send a message that > >>contains the correlation set? > >> > >>If it does, then the rule seems to be too restrictive. For > >>example, the following process will be illegal. > >> > >>1. receive a Purchase Order and initialize correlation set > >>CS-PO. 2. synchronously reply with an acknowledge message not > >>containing CS-PO. > >> <- Illegal > >>3. receive and/or invoke using CS-PO to perform the rest of > >>the PO process. > >> > >>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/le > > > > ave_workgr > > oup.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_workgr > > oup.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. > > > > > > > > > > > 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]