[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] AnonURI and Offer and WS-Addressing
A value of "http://www.w3.org/2005/08/addressing/anonymous" for the [destination] property implies no additional semantics beyond those resulting from the rules defined below and as described in Web Services Addressing 1.0 - Core[WS-Addressing-Core]. In particular, note that Web Services Addressing 1.0 - Core[WS-Addressing-Core], section 3.4 requires such a value in messages sent to a response endpoint whose [address] is "http://www.w3.org/2005/08/addressing/anonymous".
5.1.1 SOAP 1.1/HTTP
When "http://www.w3.org/2005/08/addressing/anonymous" is specified for the response endpoint then there is no change to the SOAP 1.1/ HTTP binding.
5.1.2 SOAP 1.2
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].
I think that it is critical that the semantic of anon
URI for a response
endpoint be precisely what it says above in the context
of either the
SOAP1.2 or SOAP1.2 HTTP binding regardless of what
other SOAP headers
are present.
>
> 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
Why? Let's be clear here. We can define what anon
means in the
context of an EPR that we define such as wsrm:AcksTo,
but WS-RM cannot
arbitrarily change or override the semantic of an
EPR(s) defined by the
WS-A spec (such as reply and fault endpoints). That
would violate
the whole premise of composability.
> 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.
Well, I for one am in complete disagreement with this
interpretaton.
>
> 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
Sez who?
> retransmitting. I don’t see the difficulty. I don’t see how out
only
> applies in this discussion though.
This isn't a matter of difficulty, it is a matter
of architectural
coherence and separation of concerns.
>
> 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
The problem with this is that it makes a number of
(IMO) false assumptions.
You are making the assumption that the HTTP exchanges
are being made
over a single TCP/IP connection. Where is this constraint
specified
anywhere? Explain to me how this works if the endpoint
that establishes
the HTTP connection chooses to use a separate connection
for each exchange?
I'll grant it isn't the most efficient approach, but
it isn't out of the
question. Conversely, I could have a clustered environment
in which
there are separate HTTP connections all working on
the same Sequence.
explain to me how this would work without resorting
to the kinds of
exceptional handling that Doug outlined.
> 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 it doesn't scale beyond the specific
case
implemented in a specific (yet unspecified) manner.
>
> 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
>
> Paul Fremantle <paul@wso2.com>
> 03/09/2006 06:53 PM
>
>
>
> To
>
> wsrx <ws-rx@lists.oasis-open.org>
>
> 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
> 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]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]