ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i061 proposal / directions
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Tue, 24 Jan 2006 16:19:36 -0500
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
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]