I would point out
that the definition of anonymous uri is:
“Some endpoints
cannot be located with a meaningful IRI; this URI is used to allow such
endpoints to send and receive messages. The precise meaning of this URI is
defined by the binding of Addressing to a specific protocol and/or the context
in which the EPR is used.”
The section you quote
below is from section 5.1 Use of Anonymous Address in SOAP Response Endpoints.
The SOAP 1.2 binding text you quote does not cover RM, rather it covers a
vanilla SOAP 1.2 endpoint only. WS-A leaves us the flexibility to clarify any
points on its use when RM is in use.
I’m still surprised to
see suggestions to the effect that anon can not be used with RM followed by
suggestions that amount to defining our own anon uri (essential anonymous uri
redux). I think it makes far more sense to clarify any points on the use of
anon when the RM protocol is being used rather than forbid its use as it seems
the WS-A WG left us the latitude to do so. So I disagree with your points 1, 2
and 5 below.
On point 3 I see that
as being different only if you’ve only been looking at this from a point of
view of 1 way messages exclusively. If you get an ack for a request you sent
without the corresponding response you obviously still have the request
available for retransmitting. I don’t see the difficulty. I don’t see how out
only applies in this discussion though.
On point 4 you seem
to have an async response in mind. In a synchronous req/resp MEP the ack for
the request message would be on the response message. The thing we’re
discussing is what to do when that response message is lost and the ack is
detected in a ack range on a subsequent response message to the client. It
helps to think of this without complications. Imagine that the request comes in
and the response (with the ack) is lost. The client hasn’t sent any other
requests. What does it do? Why it resends the request. The service should be
prepared for this as it never got an ack for the response either. Just extend
that model and it is easy to see that when the client sees an ack on a response
to another message that contains an ack for a request it never got a response
from it can resend the request to get the unacknowledged response. What is the
problem?
Finally I’d like to
point out that this and many other recent posts conflates i090 and i089
together. I don’t understand why so much emphasis is being placed on the use of
anonymous with an Offered sequence to simultaneously justify removing Offer and
prove that anonymous should be forbidden when using WS-RM because of perceived
problems when used with Offer.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, March 13, 2006 6:03
AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] AnonURI and
Offer and WS-Addressing
Paul,
please see: http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#anonaddress
which
is the latest editor's copy of WSA, and in particular:
When "http://www.w3.org/2005/08/addressing/anonymous" is specified
for the response endpoint and the message is the
http://www.w3.org/2003/05/soap/mep/InboundMessage property of a SOAP
request-response MEP [SOAP 1.2 Part 2:
Adjuncts], then any response MUST be the
http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same
instance of the SOAP request-response MEP [SOAP 1.2 Part 2:
Adjuncts].
They've
added quite a bit of clarifying text since the submitted version. I think
the "same instance" part makes it clear that the response MUST flow
over the same http connection as the request.
Perhaps
it would help if we summarized the list of options:
1
- prohibit anon replyTo if the response is expected to be sent using RM
2
- prohibit the use of RM when the wsa:To is anonymous - or said another way,
when replyTo is anon the response is not sent using RM
3
- resend request until response is delivered/acked even if the request is acked
4
- don't ack a request until the response is sent
5
- define a new URI that allows a polling flow like Paul described in his
previous note
Here
are some comments on each:
1
and 2 might actually be the same thing but my intention was to say that in '1'
you can't use anon replyTo if the response is sent reliably - so perhaps a
Fault is generated. In '2', if the replyTo is anon then no matter what
the wsdl/policy... says, RM needs to be turned off for the response - it can
still be sent but just not as part of an RM sequence. Slightly different.
'3'
is a change to what I believe is most people current view of the RM processing
model because we'll resend ACKed messages. It also will only work for
one-req/one-res MEPs. Out-only, or single-req/multiple-res may have
issues.
'4'
is a change to the RM processing model because the RMD will not ACK a message
even if it is received. Depending on how you view things this could mean
that the RMD needs to lie about what it has and could cause messages to be
resent because the RMD is waiting for a response before it will ACK the
request. Now, since the RMD gets to choose when it ACKs (meaning is it
simply 'I got it' or something else it up to it), so to some this may not be
lying but just a change to the ACK model of that RMD.
'5'
doesn't require a change to the RM processing model but heads in the direction
of ws-polling and can work w/o a change to the RM processing model and can work
for all MEPs. Even if we did pick this option we'd still need to say
something in the RM spec about what should happen when anon replyTo is used
(I'm guessing 1 or 2).
Are
there any other options people think we need to add to the list? Having
all of the known choices in front of us might help focus the discussions.
thanks,
-Doug
|
Paul Fremantle <paul@wso2.com>
03/12/2006 04:43 AM
|
|
To
|
Bob Freund-Hitachi
<bob.freund@hitachisoftware.com>
|
|
cc
|
Doug Davis/Raleigh/IBM@IBMUS, wsrx
<ws-rx@lists.oasis-open.org>
|
|
Subject
|
[ws-rx] AnonURI and Offer and WS-Addressing
|
|
Bob et al.
I've attached a document that outlines the flow and shows message exchanges for
a given interaction. The key question is whether the interaction:
RMD.AckRequested_EmptyBody -> EchoResponse_World_ackSeq_1_2_3
breaks the WS-Addressing spec.
Paul
Bob Freund-Hitachi wrote:
Just another log for the fire…
In reading HTTP 1.1, I do not see anything that specifies
that the response entity cannot be interpreted prior to its completion.
In principle, it seems to me that both ack and response could be sent on
the same connection backchannel provided that it was not closed prematurely.
Is this how the implementations that work do it?
Thanks
-bob
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, March 10, 2006 1:36 AM
To: Paul Fremantle
Cc: wsrx
Subject: Re: [ws-rx] An alternative approach to make anon reply-to
and sync rm work
Paul,
I think there are some problems with this - I still think this violates WSA. There's
a reason anon replyTo means, in essence, the http response flow of the request
message. The connection becomes the correlator between the request and
the response - meaning if several anon requests come in the only way the server
knows which client gets which response is thru the http connection. In
your scenario if there are two anon requests sent to the server using the same
sequence and no responses sent, when the third connection is made (to carry the
ackReq) how does the server know which client is initiating the request. It
can not simply assume that just because they shared the same sequence that they
also share WSA state and that any response can be sent to any client. The
correlation is now lost.
thanks,
-Doug
The biggest issue with the two way reliable HTTP + anonURI case is the
requirement to replay request messages to get responses.
Why is this a problem? Because it means that the client has to store
requests (if and only if the interaction is two-way) beyond getting an ack
for that request.
This means that the RMS has to "know" if this particular message
interaction is one-way or two way. This means that for example, a dumb
gateway can't do it without looking at WSDLs etc.
Why do we need to do this: because WSA states:
"For instance, the SOAP 1.2
HTTP binding puts the reply message in the HTTP response."
So I agree we should not put an application reply to message A in an
HTTP response to application message B.
However, if we added the following text to our spec:
"In the case where an offered sequence is used, the RMS may send an
<wsrm:AckRequested> header together with an empty SOAP body. A valid
response to this message MAY either contain an empty SOAP body, or MAY
contain a message for the *offered* sequence".
The result of this would be that the response message on the HTTP reply
would be a valid reply to the request message and therefore would not break the
WS-Addressing text above. Effectively WSRM would be defining what
the SOAP request/reply would be, and therefore "making it right"
with respect to the HTTP binding.
So, when things are going well the HTTP reply to any given request message
would be the
correct response message. But in the case that this message got lost or
delayed, the RMS would have a choice. If it still had the message, and it
"knew" that the MEP was two-way, it could choose to resend the
original request OR it could send an empty body with an ackRequested
header.
This also gives the offered sequence a message onto which to
piggyback Close and TerminateSequence requests, solving another problem.
More importantly it removes the need for
the RMS to "know" the MEP, because by the repeated application of
empty-body ackRequests,
the RMS can get the offered sequence into a decent state.
The only compulsory implementation change I see is that the RMD would
have to be coded to know what this empty body + ackrequest means.
From the RMS I see this as optional. It is completely up to the RMS
whether it initiates a CS with Offer+AnonURI. So if an implementation doesn't
support this,
it will never initiate such a channel. And if the RMS does initiate such
a channel, it will "know" it is in this mode, that it needs to send
occasional empty ackrequests until it can close down the offered sequence.
In addition we would have to remove the words that say Offer is simply an
optimization,
because this usage makes a specific correlation between a sequence and offered
sequence.
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com[attachment
"AnonURI+Offer.doc" deleted by Doug Davis/Raleigh/IBM]