[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
I think it's important that BPEL be consistent. If we are going to ban initialized correlation sets on replies that are not necessary for correlating the reply with the receive then I believe we must outright ban the use of initialized correlation sets on invokes since they are not needed for any functionality within BPEL itself. Personally I think we should just get rid of part B but if we are going to keep it then we need to be consistent. Yaron Satish Thatte wrote: > > > 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. > > > > > > > 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]