[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive>
If message validation is all you are thinking of that is absolutely valid. In "normal" usage, the expectation is that the corresponding receive on the other side will use the same non-initiated correlation sets that the send (or reply) mentions. That would not apply here. I think we have thrashed this sufficiently. We are all on the same page as far as the details go. Now (as often) it is a matter of taste. -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Monday, August 09, 2004 10:43 AM To: Satish Thatte Cc: Francisco Curbera; Eckenfels. Bernd; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive> As has been discussed in the group previously the use of initialized correlation sets on outgoing messages can serve a validation function. It makes sure that the outgoing message looks the way the programmer intended. If this were not the case then there would be no need to put initialized correlation sets on invokes. If a programmer is sending a reply such that the reply message is being joined to an existing conversation then it is reasonable for the programmer to want to validate their behavior by including the appropriate correlation set. That is the behavior I describe below and that is the behavior that point B would ban. Yaron Satish Thatte wrote: > > > There are two separate parts to what you are doing with the reply. > > A. Explicitly use assignment to copy the group ID into the reply > *message* in some well-known place. This is needed regardless of > everything else. > > B. Associate the correlation set represented by the ID with the reply > *activity*. I am questioning why this is meaningful. > > I don't get the sense that you are separating these two aspects. Am I > wrong? > > Satish > > > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Tuesday, August 03, 2004 4:23 PM > To: Satish Thatte > Cc: Francisco Curbera; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > 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. > > >> > > > > > > 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]