[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
An airline sends in a reservation to a travel agency BPEL process saying "here is the reservation, what group does this belong to?" The travel agency BPEL process is tracking a number of groups and is using correlation sets to do so. When the travel agency BPEL replies to the request it will include the correlation ID of the group the person in the reservation belongs to. In this case the response would contain a correlation set that is both initialized and was not present on the request, something point B would make illegal. The response to a particular request may be joined to a conversation that is already in progress. In that case one wants to be able to place an initialized correlation set, that wasn't on the request, on the reply. B prevents specifying the correlation set, which is why I objected to the language. Thanks, Yaron Satish Thatte wrote: > Yaron, > > The only concern I have with keeping B is not that it will hurt *when understood correctly*, but that it will be misunderstood as having more significance than it does. BPEL4WS is rife with opportunities for "creative interpretation" as you have discovered, and one of the goals we need to have is to "tighten the bolts" if we hope for truly interchangeable process metadata with predictable semantics. Leaving bolts that look like they are holding something together when they are not does not help that cause. > > Satish > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Friday, July 30, 2004 10:05 AM > To: Francisco Curbera > Cc: Satish Thatte; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive> > > +1 > > I think condition B is an unnecessary restriction. > > Predicting the future is a hazardous business and one we should avoid if > at all possible. As you said yourself Satish "A somewhat harmless and > also rather useless freedom." The declaration of it being 'harmless' > means that we won't be hurt by getting rid of B. But the declaration of > 'useless' requires predicting the future. Following the standards > equivalent of 'do not harm' I think we should just get rid of B and that > way allow for future extensions in ways we hadn't thought of. I could > understand keeping B if it hurt other things but again, you said it > yourself, it's harmless. > > Yaron > > Francisco Curbera wrote: > > >> >> >> >>No, I don't care much about how the other side is implemented. But I have >>brought up what looks to me like a very reasonable use case (forwarding a >>previously initialized cset) that is disalowed by the condition B in Yuzo's >>proposal. Since that ocndition does not seem to solve any other problem >>onthe table I think it needs to be dropped. >> >>Paco >> >> >> >> >> >> >> "Satish >>Thatte" >> >> >> <satisht@microsof To: Francisco >>Curbera/Watson/IBM@IBMUS >> >> t.com> cc: "Eckenfels. >>Bernd" <B.Eckenfels@seeburger.de>, <wsbpel@lists.oasis-open.org> >> >> Subject: RE: [wsbpel] >>Issue - 123 - Matching <reply> with <receive> >> >> 07/29/2004 >>01:12 >> >> >> >>PM >> >> >> >> >> >> >> >> >>If you make it a requirement that the sender of a message and the receiver >>mention the same csets then I see your point. There is no such requirement >>in the spec at this point. I guess you are proposing that we clarify that >>it is a requirement? >> >>-----Original Message----- >>From: Francisco Curbera [mailto:curbera@us.ibm.com] >>Sent: Thursday, July 29, 2004 10:04 AM >>To: Satish Thatte >>Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive> >> >> >> >> >> >>The cset is involved in the routing but not of this particular >>receive/reply, which happens to be used to communicate the cset values to >>the endpoint at the other end of the partner link. It is important to state >>that the values are not only encoded in the mesage but constitute the >>(constant) values which need to be used to route successive messages. This >>is important information for the receiver of the reply message. >> >>Just encoding them in the message does not do the trick. >> >>Paco >> >> >> >> >> >> "Satish Thatte" >> >> <satisht@microsof To: Francisco >>Curbera/Watson/IBM@IBMUS >> t.com> cc: "Eckenfels. Bernd" >><B.Eckenfels@seeburger.de>, <wsbpel@lists.oasis-open.org> >> Subject: RE: [wsbpel] Issue >>- 123 - Matching <reply> with <receive> >> 07/29/2004 12:42 >> >> PM >> >> >> >> >> >> >>The question is: if the csets are not involved in routing, why are they >>mentioned as such? The properties can be transmitted without being >>explicitly turned into csets. >> >>-----Original Message----- >>From: Francisco Curbera [mailto:curbera@us.ibm.com] >>Sent: Thursday, July 29, 2004 8:38 AM >>To: Satish Thatte >>Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive> >> >> >> >> >> >>I don't mean a cset that is initiated in the reply but one that was already >>initiated in a prior interaction over another partner link. For example, if >>the BPEL process is a travel agent, a record locator is received from an >>airline when a reservation is made (and the record-locator cset is then >>initialized), then it is forwarded to the traveler with the reply of the >>original receive. So from the process perspective the cset is not initiated >>by the reply, and is not present in the receive. That cset may be sent >>along with others that also appear in the receive but the net is that the >>two sets of (reply-uninitiated) csets don't need to match. >> >>When we consider only one partner link, it is true that csets present on >>the reply have either been used already in the receive or are being >>initiated at that point. When additional parties are involved this is not >>necessarily the case, since initiation (from the process perspective) may >>already have already happened, even if this turns out to be the first usage >>of that cset over a particular partner link. >> >>Paco >> >> >> >> >> "Satish Thatte" >> >> <satisht@microsof To: Francisco >>Curbera/Watson/IBM@IBMUS, "Eckenfels. Bernd" >> t.com> <B.Eckenfels@seeburger.de> >> >> cc: >><wsbpel@lists.oasis-open.org> >> >> 07/29/2004 01:56 Subject: RE: [wsbpel] Issue >>- 123 - Matching <reply> with <receive> >> AM >> >> >> >> >> >> >>If it is a new cset being passed through the reply, then initiate="yes" and >>B does not apply. >> >>The question is, is it possible to do the equivalent of a "replyTo" header >>with the reply using different csets. Or in other words, what is the >>significance of using the "wrong" already initiated csets with a reply >>(i.e., different ones from the corresponding receive)? >> >>Given that the only real significance to BPEL of csets on an outbound >>message are >> >>(1) cset initiation (not applicable here) >>(2) cset verification (primarily for independent sends routed via the cset) >> >> >> >> >>I see B as saying "why are you allowing this since there does not seem to >>be a use case". A somewhat harmless and also rather useless freedom. >> >> >> >>Satish >> >> >> >>-----Original Message----- >>From: Francisco Curbera [mailto:curbera@us.ibm.com] >>Sent: Friday, July 23, 2004 6:50 AM >>To: Eckenfels. Bernd >>Cc: wsbpel@lists.oasis-open.org >>Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive> >> >> >> >> >> >>Maybe I am missing something here, but I don't know what problem B is >>trying to solve. The cset on the reply may have been initialized on a prior >>interaction, maybe over a different partner link, then it is forwarded with >>this reply. The initial receive can use completely unrelated csets. What is >>wrong with that? >> >>Paco >> >> >> >> >> >> "Eckenfels. >> >> Bernd" To: >><wsbpel@lists.oasis-open.org> >> <B.Eckenfels@seeb cc: >> >> urger.de> Subject: RE: [wsbpel] Issue >>- 123 - Matching <reply> with <receive> >> >> 07/22/2004 09:35 >> >> PM >> >> >> >> >> >> >>it is not a requirement to have the same csets, it forbids to have the >>wrong (init=no) ones (i.e. reply has CSets which the receive had not). In >>that case the reply is not compatible with the receive >> >>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: Yaron Y. Goland [mailto:ygoland@bea.com] >>Sent: Friday, July 23, 2004 1:49 AM >>To: Yuzo Fujishima >>Cc: wsbpel@lists.oasis-open.org >>Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive> >> >> >>The proposal says: >> >> A reply and a receive are said to be compatible with each other if (A) >> the same partner link, port type, and operation are specified for both >> and (B) the correlation sets specified for reply with initiate >>attribute >> no are all specified for the receive regardless of the value of the >> initiate attribute there. >> >>Why is B required? Even if one isn't using a message exchange it's >>always possible to match up on partnerLink and operation without having >>to match on correlation sets. >> >>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]