I must agree with Doug.
Definition of Anonymous URI within the context of WS-A
defined message addressing properties is a result of a long debate in WS-A. We
must not simply change the semantics of the anonymous URI and WS-A the message
headers just because we would like to extend/change the semantics. Redefining
something in a different context really hurts composibility :-(.
There are other avenues to explore. Just to name
two:
-- For specifying different semantics, defining a new URI
is an option.
-- Defining new WS-RX specific message properties/headers
using Anonymous URI is another option.
--umit
From: Doug Davis [mailto:]
Sent: Tuesday, Mar 14, 2006 1:31 PM
To: Marc
Goodner
Cc:
Subject: RE:
[ws-rx] AnonURI and Offer and WS-Addressing
MG says: ...that is a very biased characterization of
the severity of the problem...I expect to be able to make a proposal shortly
that should address these problems that have been introduced by some of the
new features in the specification.
LOL So, let's see, the issue should be closed with no
action (I assume because its just so obvious given what's in the spec today)
but at the same time we've been waiting for weeks for you to share some
proposal with us on how all of this is supposed to work. You crack me
up.
As Chris mentioned on the call
last week - something is broken. WSAddr is what it is and just because
we may not like what it says for anon replyTo the RM spec can not change it.
I just don't see the latitude that you see in the spec. Show me
where it says that some other spec can change the semantics of what WSA
defines that anon replyTo means. The latitude that I think you're
referring to in the WSA spec allows other specs to define what anon means for
their own EPRs not WSAddressing's EPRs - I believe they even added that part
(in part) because of our anon AcksTo EPR issue. Whether this is
"tantamount to saying that there are fundamental flaws in WS-A", I dunno -
what I do know is that there is something flawed when trying to use RM (as
currently spec'd) with anon replyTo. Not all features of all specs will
be available when they're composed with other specs. Anon replyTo is
what it is. If someone doesn't like the semantics that WSA defines for
it then people are free to define their own URI and give it whatever semantics
they want. That's a lot of flexibility - but I can also see the
constraints it imposes.
The "out
only", or any other non-1-req/1-res MEP discussion, is important because I'd
like RM to be used in more than the most trivial of use-cases. You keep
not wanting to hear what I'm saying about this. The issues with these
other MEPs is that there is no mechanism for the RMS to resend messages at
will to an unreachable endpoint. You seem to focus just on the one case
of single-request/single-response and how the requestor can resend the request
to get a response resent. That's an interesting scenario but it does
nothing for the other MEPs which you seem to want to ignore. For
example, the non-RM-request/RM-response case is a very interesting one in that
there is no reason what so ever why the request would be resent and yet
somehow the response needs to somehow get retransmitted if the initial attempt
fails. I'm really hoping that this proposal you keep teasing us with
will explain those too.
Just to be
clear, the problems around this issue are NOT just about the new features like
Close or TerminateResponse - this unreachable endpoint problem has always been
in the RM spec and that's why it was NEVER part of any interop workshop we
held during the development of the spec. If the solution was as obvious
as you claim we would have included it.
BTW - I'm not writing off the relevance of the unreachable client
use-case. I find it amusing that you would think,of all people, I would
do that given ws-polling's main use-case is this exact scenario. I'm
just not comfortable with violating WSA to make it happen. For a long time now
I've been advocating that WSA attack this issue but given their time
constraints it wasn't possible. So we have to live with what they've
produced. If you don't like what WSA says then I suggest you talk with
your WSA folks.
thanks
-Doug
"Marc Goodner"
<>
03/14/2006 03:05 PM
To
Doug
Davis/Raleigh/IBM@IBMUS
cc
<>
Subject
RE: [ws-rx] AnonURI
and Offer and WS-Addressing
Yes Doug, anonymous is clearly defined in
WS-A. Here is a rather key line, “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.” In the SOAP binding part of WS-A it only talks of SOAP
1.1 and 1.2, it does not speak to any other protocols that may be within the
context of a specific EPR. Your interpretation as I understand it from your
suggestions that we define our own anonymous uri is that we refrain from
composing fully with WS-A. To me that is tantamount to saying that there are
fundamental flaws in WS-A. I for one don’t believe that. Lets just focus on
what if anything needs to be clarified regarding the use of composing WS-RM
properly with WS-A including anonymous uri. That would be a better use of our
time rather than trying to justify defining our own uri with the same
semantics.
I’d also like to point out that
the default value for ReplyTo is anonymous, particularly if it is not present.
So your proposal to forbid the use of anonymous is that only directly
addressable clients will be able to use WS-RM. I think WS-RM is particularly
relevant to clients on unreliable networks. A characteristic of many clients
on such networks is that they are unlikely to be directly addressable. I don’t
find it to be an acceptable solution to write off that class of clients from
using WS-RM. Your proposal to me seems to contradict one of the fundamental
motivating use cases for WS-RM.
Finally
through all of this I still maintain that i089 should be closed with no
action. I still have not heard anything that needs to be said in the spec
about the overall use of anonymous.
CIL.
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis
[mailto:]
Sent: Tuesday, March 14, 2006 10:38
AM
To: Marc Goodner
Cc:
Subject: RE: [ws-rx] AnonURI and Offer
and WS-Addressing
The WSA spec is very clear what anon
replyTo means - this is a contract that both the client and server need to
follow. This means that (for anon replyTo + HTTP) the server MUST
send it back on 'this http response' and that the client MUST look for it on
'this http response'. Sending it back on some other http connection, or
looking for it on some other http connection is not compliant with WSA's
defintion of what anon ReplyTo means. Composing RM into the picture can
not change what WSA says - RM can cause the messages to be resent but for any
individual message exchange the WSA rules must be adhered to.
I
believe all of the options I listed are valid - spec wise. You can
dislike some of them but I believe that are all compliant with
WSA.
Marc said: 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.
You 'obviously still have
the request' only until the request is acked. After that point the RM
spec does not manadate anything - so replaying an ACked message, as I said, is
something I believe is new to most people. 'Out only' applies because
I'd like our RM to be used in more than the most simple of
use-cases.
MG: New but hardly confusing.
I still don’t understand how out only applies in this discussion. In fact you
don’t identify any issues yourself. If you aren’t aware of any issues then why
are you suggesting there are any? I suggest it isn’t relevant until you
actually identify an issue with it.
Marc said: 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?
The
problem is that the RMS MUST know about the MEP - something we haven't
required up to now, and it links the request and response sequences -
something, again, we haven't done. Once we head down this path I don't
see how we can't be required then to examine how the lifecycle of the two
sequences might be linked. Again, as I've said many times, no one has
been able to explain how the full RM protocol works - for example, how a Close
or Terminate can be sent from the RMD back to the RMS. Or how RM can be
used in one direction but not the other - e.g. non-RM-request/RM-response.
The longer we talk about this the more questions we get.
MG: I’m sorry Doug but that is a very biased characterization of the
severity of the problem. This worked fine with the spec before Close was added
or TS was changed to add the response leg. I don’t think either are
insurmountable problems. As many other things have been clarified recently in
this discussion around Offer I expect to be able to make a proposal shortly
that should address these problems that have been introduced by some of the
new features in the specification.
thanks,
-Doug
"Marc Goodner"
<>
03/14/2006 12:50 PM
To
Doug
Davis/Raleigh/IBM@IBMUS,
<>
cc
Subject
RE: [ws-rx] AnonURI
and Offer and WS-Addressing
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.
Marc
Goodner
Technical Diplomat
Microsoft
Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis
[mailto:]
Sent: Monday, March 13, 2006 6:03
AM
To:
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
<>
03/12/2006 04:43 AM
To
Bob
Freund-Hitachi <>
cc
Doug
Davis/Raleigh/IBM@IBMUS, wsrx
<>
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:]
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
Paul Fremantle
<>
03/09/2006 06:53 PM
To
wsrx
<>
cc
Subject
[ws-rx] An alternative
approach to make anon reply-to and sync rm
work
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
"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
"Oxygenating the Web Service Platform", www.wso2.com[attachment "AnonURI+Offer.doc" deleted by Doug Davis/Raleigh/IBM]
