[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]