+1 to Lei's point. Intermediary has info
that says one-way, such as a portion of wsdl. Then any other spec that comes
along can "pollute" the backchannel, like ReplyTo/FaultTo=anon or
AcksTo or the next wonderful WS-* spec with a *To that might use the
backchannel. The intermediary is coupled to each and every spec that could
require the backchannel stay open. Using Chris's style, the problems is that the
INTERMEDIARY is REQUIRED to understand every protocol-level contract that MAY respond
with a SOAP envelope in the response where there IS a one-way specified, and
that is hardly "composable" or "well-factored".
Now if there other more loosely coupled
solution, like a spec for a soap header that said
"KeepBackChannelOpen" and every *To was required to set this to True
if it was using Anonymous, then there'd be only one spec to be coupled with and
the problem would be more tractable for the intermediary. But that might be
seen as "architecture", which is obviously wasteful and so we are
left with these tricky problems.
Cheers,
Dave
From: Lei Jin
Sent: Wednesday, January 25, 2006
10:10 AM
To: Christopher B Ferris
Cc: Doug Davis;
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i061 proposal
/ directions
Comments inline.
Lei
From:
Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Wednesday, January 25, 2006
2:42 AM
To: Lei Jin
Cc: Doug Davis;
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i061 proposal
/ directions
Lei,
The
WSDL is an application-level, not a protocol-level contract. As for SOAP1.2,
the current
SOAP/HTTP
binding actually REQUIRES a SOAP envelope in the response. We are making that
optional
to accomodate use cases where there IS no SOAP-level response for whatever
reason.
However, there is NO association between the WSDL operation signature and
the binding
that
should be derived.
Are
your intermediaries inspecting the SOAP headers for wsa:ReplyTo so as to
determine
whether
or not there is a reply expected from the ultimate recipient? If so, why not
also inspect
for
the presence of wsrm:Sequence header and assume that there MAY be a SOAP
envelope
in
the response.
<ljin>No. The intermediary has
the WSDL and knows the operation that is to be invoked is oneway. This is
just given as an example. The point is, I don't control every
intermediary that I might use, and I certainly can't make sure they all
understand RM and will inspect the presence of wsrm:Sequence header.
</ljin>
Frankly, unless the intermediary is a true store and
forward intermediary, it has no business
sending
a HTTP 202 before receiving anything from the ultimate recipient because the
ultimate
recipient
has NOT accepted the message for processing.
Cheers,
Christopher
Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Lei
Jin" <ljin@bea.com> wrote on 01/24/2006 08:39:35 PM:
> For example, in an ESB implementation, an
intermediary can hold a
> bunch of WSDLs for a number of backend
services that it routes
> messages to. The intermediary will actually
process a message to
> figure out the WSDL MEP and then forward it
on. In this case, the
> ESB intermediary can know a message is
oneway, and, mistakenly or
> not, not wait for the following node to
respond before it sends back a 202.
>
> Lei
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Tuesday, January 24, 2006 1:20 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i061 proposal /
directions
>
> Thinking more about this - how does the
intermediary know if the
> message is part of a one-way or
request/response? Per WSA the
> presence of a wsa:ReplyTo doesn't mean that
its a request/response -
> in the latest WSA spec it looks like the
absence of a wsa:ReplyTo
> doesn't mean its a one-way either - and even
if it could figure it
> out there's no guarantee that a fault will
not be sent back on the
> http response flow (a fault can always be
thrown before the WSA
> processing). So, going to DaveO's
question about whether or not an
> intermediary MUST wait for the following node
to respond before it
> can send back a 202 - I'm leaning towards yes
even w/o RM in the
> picture - and unless there's a some
out-of-band communication I
> would question how an intermediary could
possible know the MEP being
> used for each message. And, if someone
claims that the environment
> is that connected that they do know then I
would think they would
> probably all support (or not support) RM
equally.
> -Doug
>
>
> __________________
>
>
>
> I can't help but think that in the situation
your talking about that
> a couple of things would probably happen:
> 1 - RMS may know what the intermediaries
support and could therefore
> could choose to use the anon acksTo based on
that.
> 2 - If it doesn't know, and they don't support
it, then the acks
> will be lost on their way back
> 3 - The RMS would eventually send an
AckRequested to the RMD. Now,
> is this a req/res or a one-way? That's not
clear to me.
> 4 - If its a req/res then the RMS will have
to continue to use
> AckRequested to get the acks
> 5 - If its a one-way then it would get a 202
back instead of the
> Acks and know that its hossed.
> 6 - The RMS would then have to send a Close
to shut things down and
> get the true ack state on the response, per
the spec.
> 7 - The RMS would never use those
intermediaries again for RM :-)
>
> This actually isn't very different from one
of the use-cases we
> talked about for adding Close - the bogus
AcksTo EPR. The spec
> currently says:
>
> Implementations
MUST NOT use an endpoint reference in the
> AcksTo element that would prevent the sending
of Sequence
> Acknowledgements back to the RM Source.
>
> I guess the question is whether this one line
is enough or whether
> we need to enumerate some specific instances
for people to look out
> for. I think this line is enough - and
when you add the additional
> text I proposed in i061 (that IMO goes into
annoying detail about
> how the message flows are expected to change
when anon is used) I
> think it makes it clear that there's
something people need to watch
> out for here. I'm against the notion of
discouraging the use of
> anonymous AcksTo (we have too many customers
that want it), but
> modifying the text in i061 to be even more
clear is an option.
> Perhaps someone (you? Gil?) could suggest
some changes that would
> reduce your concerns.
>
> One additional comment from Gil's latest
note, he said:
> I don't
think anybody's customers would be pleased to hear
> that may or may not have to upgrade some or
all of their SOAP stacks
> if they want to use WS-RM.
> When it comes to the RMS and RMD I don't see
how you can use RM w/o
> upgrading - you have to get the code somehow.
Now for
> intermediaries, that's different.
>
> thanks,
> -Doug
>
>
>
> "Lei Jin" <ljin@bea.com>
>
> 01/24/2006 03:25 PM
>
> To
>
> Christopher B Ferris/Waltham/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
>
> cc
>
> Subject
>
> RE: [ws-rx] i061 proposal / directions
>
>
>
>
>
>
> Chris and Doug:
>
> If I understand you correctly,
you are saying if an RMS
> implements RM, then it can be reasonably
expected to check for
> backchannel even in case of oneway, otherwise,
it should not ever
> send an anonymous AcksTo on sequence
creation. By the same
> reasoning, if an RMD implements RM, then it
can be reasonably
> expected to send ack through a backchannel
even if it's oneway,
> otherwise, it could've rejected the sequence
creation request. I
> think these are reasonable assumptions.
>
> However, my problem with this is with
intermediaries. You cannot
> expect all intermediaries that carry your
message will support RM
> and understand how to handle backchannel
correctly. In the real
> world, there will be intermediaries that
conform to BP1.1 (despite
> how you think it's wrong) and not allow a
SOAP envelope to come back
> on a oneway http invocation. Again, I'm
not arguing whether that's
> the right approach, but just that I think
it's rather likely that
> this is going to happen given how confused
even we, as spec authors,
> are over this issue. Thus, I contend
it's useful to point out this
> potential problem and advise accordingly in
the spec.
>
> Lei
>
>
>
>
> From: Christopher B Ferris
[mailto:chrisfer@us.ibm.com]
> Sent: Tuesday, January 24, 2006 5:43 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i061 proposal /
directions
>
>
> Gil,
>
> Please see my response below.
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry
Architecture
> email: chrisfer@us.ibm.com
> blog:
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "Gilbert Pilz" <Gilbert.Pilz@bea.com>
wrote on 01/23/2006 06:41:27 PM:
>
> > [text sizes changed to make them
readable]
> >
> > Doug said:
> > If an RMS uses it then it knows how to
handle the http backchannel
> > for acks. If the RMD accepts it
then it knows how to use it
> > too. If neither side faults on its use
then I don't see the issue.
> > As Chris said, the RMD is always free to
fault on its use and an
> > RMS is always free to use a
non-anonymous URI. Both sides actually
> > have a lot of control here. My
proposal simply states what both
> > sides can expect if it is used - if they
don't like it they don't
> > have to use it - but at least its
written down what people should
> > expect.
> > I'm a little confused by this statement.
In my mental model of this
> > issue, the use of the anonymous URI in
the AcksTo EPR is only a
> > problem in cases where the AS/RMS
subsequently "uses the sequence to
> > engage in"* message exchanges for
which there is no backchannel (e.
> > g. one-way operations using a SOAP/HTTP
implementation which does
> > not put SOAP envelopes in the HTTP
response). If the AS/RMS uses the
> > sequence for messages conforming to a
synchronous "send a SOAP
> > request over HTTP, wait for the SOAP
reply in the HTTP response"
> > pattern there is no problem because
there is a backchannel for
> > acknowledgements to return upon. Thus it
seems unnecessarily
> > restrictive for an RMS to forgo all uses
of the anonymous URI for
> > the AcksTo EPR simply because it
"knows" that, in some cases, there
> > is no SOAP backchannel.
>
> Who says there's no backchannel? I think that
you presume that the
> WS-I BP constraint that there be no SOAP
envelope in the entity
> body of the HTTP response message to a oneway
WSDL will live to see
> tomorrow? I certainly hope not. IMO, that
would be a horrendous
> mistake.
>
> >
> > * Note; when I say "uses the
sequence to engage in" I am implying
> > that every message that carries a SOAP
header with the same <wsrm:
> > Identifier> is part of some logical
application-level abstraction
> > and that all the messages with that
identifier will conform to the
>
> Why must they conform to the same interaction
pattern? That seems
> unnecessarily restrictive.
>
> > same interaction pattern. I know that
this does not match your model
> > of independent, intermediary RMS/RMD
pairs that carry all "traffic
> > that is to be transmitted reliably"
between two clusters of services.
> >
> >
> >
> > All of this still begs the question of
how someone implementing an
> > RMS or an RMD "knows" that the
use of the anonymous URI in the
> > AcksTo EPR might be problematic? The
only thing we say about the
>
> It knows whether IT can receive messages on
the "backchannel". That's
> all it needs to know. If the RMD can't handle
that, it will fault on
> Sequence creation.
>
> > AcksTo EPR in the current spec is (lines
262-264 of wsrm-1.1-spec-cd-02) is:
> > Implementations MUST NOT use an endpoint
reference in the AcksTo
> > element that would prevent the sending
of Sequence Acknowledgements
> > back to the RM Source. For example,
using the WS-Addressing "none"
> > IRI would make it impossible for the RM
Destination to ever send
> > Sequence Acknowledgements.
> > The proposal listed here
(http://docs.oasis-open.org/ws-
> >
rx/issues/ReliableMessagingIssues.xml#i061) does not mention the
> > possibility that there may not be a SOAP
backchannel for the
> > acknowledgements to flow back on. I'm
wondering how we expect a
>
> Can we get over this inane restriction of the
WS-I BP already?
>
> As I have said repeatedly, the use of the
HTTP response flow to
> carry SeqAcks is AN IMPORTANT USE CASE FOR
MANY CUSTOMERS, certainly
> many whom I have spoken to. Why on earth would
we NOT seek to satisfy
> such an important requirement? The WS-I BP
MADE A MISTAKE when they
> said that the HTTP response to a oneway WSDL
could not carry a SOAP
> envelope. It's that simple. They didn't
(despite my protestations)
> anticipate the advent of SOAP extensions such
as WS-RM.
>
> > developer to know precisely when and
where the use of the anonymous
> > URI in the AcksTo EPR might be
problematic when our spec says
> > nothing about the subject?
> >
> > - g
> >
|