[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]