Part of the reason I
haven’t gotten a proposal together yet is trying to determine what is
going to be the most satisfactory. I think the two proposal I made are
acceptable (to me) but are to minimal to be acceptable to everyone. This
message to me indicates you and I are closer rather than further apart in
thought.
I’ll make sure
the resend of the acked request to provide the response a channel to be resent
is described in what I put together. I disagree that it isn’t consistent with
the current spec though it isn’t described there. Yes my next proposal
should also cover the close, TS stuff. I’m going to shut off my email
client and go work on this now. Hopefully I’ll get this out before this
weeks call.
Can you explain why
is Paul’s proposal for effectively polling the RMD with ackRequested to provide
the response a communication channel contrary to WS-A? Please provide the
relevant text from WS-A that supports your opinion on this. I don’t see
it.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Tuesday, March 14, 2006 3:58
PM
To: Marc Goodner
Cc: Yalcinalp, Umit;
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] AnonURI and
Offer and WS-Addressing
Marc,
I'm totally lost as to what you're arguing for. Are you advocating Paul's
polling idea? I believe his proposal for returning the response on
something other than the same http connection that carried the request violates
WSA's defining of what anon replyTo means.
If you're advocating the notion of resending a request until the response is
acked (some flavor of #3 in the option list I sent earlier) then I think that's
valid w.r.t. WSA. However, it is not consistent with the current RM spec.
I have a feeling you want the latter - in which case we (you, Umit and I) don't
need to discuss what WSA says or doesn't say because resending a request is
WSA-legal. That doesn't remove the need to talk with Paul about his idea
w.r.t. being WSA-legal but that's something else ;-)
Assuming that you're not interested in Paul's polling idea... the reason RM
needs to say something about anonymous replyTo is because it is not clear how
it can be supported. The proposal I put forward for i089 is just one idea
- and it basically says we're claiming defeat - we have no idea of how to
support anon replyTo with RM. You believe differently. You're
claiming that anon replyTo + RM can work with (or without) additional RM spec
changes, and if you produce this mystery proposal that explains it then perhaps
we can adapt that proposal over my "we give up" one. But, as
I've said and will continue to say, I'd like a proposal that deals with all of
the issues around this (various MEPs, Close, Terminate, RM in one direction but
not the other....) because if we can't satisfy ourselves that we know how its
supposed to work then how can we possibly expect implementers interop on it.
thanks,
-Doug
|
"Marc Goodner"
<mgoodner@microsoft.com>
03/14/2006 04:59 PM
|
|
To
|
"Yalcinalp, Umit"
<umit.yalcinalp@sap.com>, Doug Davis/Raleigh/IBM@IBMUS
|
|
cc
|
<ws-rx@lists.oasis-open.org>
|
|
Subject
|
RE: [ws-rx] AnonURI and Offer and
WS-Addressing
|
|
I still remain unconvinced that
anything needs to be specified about anonymous uri in WS-RM at all. I never
suggested to change the meaning of any WS-A headers. My point, and WS-A backs
me up here, is that the definition of anonymous is not precise. It says right
in the spec that the precise definition if from binding of addressing to a
specific protocol. My point is that addressing has provided us with the
flexibility to clarify the use of anonymous uri when addressing is used with
WS-RM if we need to. Again I am still not convinced that there is anything we
need to say at this point. Restricting the default value from use in To and
ReplyTo when WS-RM is used that would be applicable for a large number of uses
of the protocol does not seem to be a good direction to pursue.
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html?content-type=text/html;%20charset=utf-8#eprinfomodel
2.1 Information Model for Endpoint References
|
http://www.w3.org/2005/08/addressing/anonymous"
|
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.
|
3.1 Abstract Property Definitions
[destination]
: IRI (1..1)
An absolute IRI representing
the address of the intended receiver of this message.
3.2 XML Infoset Representation of Message Addressing Properties
/wsa:To
This OPTIONAL element (whose
content is of type xs:anyURI) provides the value for the [destination]
property. If this element is NOT present then the value of the [destination]
property is "http://www.w3.org/2005/08/addressing/anonymous".
…
/wsa:ReplyTo
This OPTIONAL element (of type
wsa:EndpointReferenceType) provides the value for the [reply endpoint]
property. If this element is NOT present then the value of the [address]
property of the [reply endpoint] EPR is
"http://www.w3.org/2005/08/addressing/anonymous".
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Yalcinalp, Umit
[mailto:umit.yalcinalp@sap.com]
Sent: Tuesday, March 14, 2006 1:44 PM
To: Doug Davis; Marc Goodner
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] AnonURI and Offer and WS-Addressing
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:dug@us.ibm.com]
Sent: Tuesday, Mar 14, 2006 1:31 PM
To: Marc Goodner
Cc: ws-rx@lists.oasis-open.org
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"
<mgoodner@microsoft.com>
03/14/2006 03:05 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS
|
|
cc
|
<ws-rx@lists.oasis-open.org>
|
|
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:dug@us.ibm.com]
Sent: Tuesday, March 14, 2006 10:38 AM
To: Marc Goodner
Cc: ws-rx@lists.oasis-open.org
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"
<mgoodner@microsoft.com>
03/14/2006 12:50 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
|
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: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]