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