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: "Gilbert Pilz" <Gilbert.Pilz@bea.com>
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>, <ws-rx@lists.oasis-open.org>
- Date: Tue, 24 Jan 2006 11:44:27 -0800
Responses inline . .
[stuff
removed]
"Gilbert
Pilz" <Gilbert.Pilz@bea.com> wrote on 01/23/2006 06:41:27 PM:
[ stuff removed
]
> 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.
<gp> Whether or not WS-I BP "lives to see
tomorrow" is completely besides the point. The fact is that every
current specification that discusses the use of SOAP 1.1 one-way
operations over HTTP specifically states that the HTTP response body must
be empty. Unless each and every SOAP implementer has ignored all of these specs,
this means that there are SOAP implementations out there that do not provide a
backchannel for one-way operations.
>
> *
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.
<gp> Sorry, this was poor phrasing on my part.
What I'm trying to say is that the RMS and RMD cannot tell ahead of time whether
a particular sequence will or will not have an available backchannel
since neither can tell if the application will be engaging in two-way or
one-way message interactions.
> 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.
<gp> But IT (the RMS or RMD) can't determine
whether or not there will be a backchannel unless it knows two things: (a) does
the underlying SOAP implementations (it's underlying SOAP implementation and the
SOAP implementation of every SOAP intermediary on the path between it and
it's correspond RM node) support a backchannel for one-way operations?; (b) will
the application be engaging in two-way or one-way operations? I maintain that
(a) is unknowable given our current technology and that, although you can make
some good guesses about (b), this requires nasty things like inspecting the
message which may have certain parts encrypted at the time the RM node has
access to it.
> 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.
<gp> Just to be clear, I am
100% behind using the HTTP response flow to carry acknowledgements. All I'm
saying is that there may be cases where the only way this will work is if
the application forgoes the use of asynchronous communications. I don't
care if WS-I BP made a mistake. BP 1.0 and BP 1.1 are both out there
and there are no specifications that contradict them on this
matter. Whether they are right or wrong is completely
irrelevant. Specifications do not exist in a vacuum. We have to take
into account the current state of affairs with regards to SOAP implementations.
Insisting that WS-RM will only work with SOAP implementations that
have ignored all the specifications on the use of one-way SOAP/HTTP
operations is irresponsible. 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.
> 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]