- From: Mark Baker <distobj@acm.org>
- Date: Tue, 23 Aug 2005 23:48:08 -0400
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: public-ws-addressing@w3.org
Lucky me, I've got IP until Thursday... On Mon, Aug 22, 2005 at 11:11:17AM -0400, Marc Hadley wrote: > Consider the following scenario: > > SH1 -> H2 -> SH3 -> SH4 > > where: > SH1 is a SOAP/HTTP node, the initial SOAP sender > H2 is a HTTP cache > SH3 is a SOAP/HTTP node, a SOAP intermediary > SH4 is a SOAP/HTTP node, the ultimate SOAP receiver > > Using the current HTTP binding, I'd expect the HTTP request URI for > SH1 -> H2 -> SH3 to be the HTTP URI for SH3 (*not* SH4). I'd expect > the HTTP request URI for SH3 -> SH4 to be the HTTP URI for SH4. I.e. > there would be two different HTTP request URIs for the single SOAP > message path. If WS-Addr were used then I'd expect the value of the > [destination] message addressing property to be the HTTP URI for SH4 > so there'd be a clear difference between the value of [destination] > and the HTTP request URI at SH1. Yes, I understand that to be your (and others) positions. I believe that position is inconsistent with the HTTP specification, and possibly inconsistent with the SOAP specification (per the ambiguity over what ImmediateDestination means). My position, as you summized, is that the SH4 URI goes in the Request-URI, as that's the only interpretation consistent with HTTP semantics; the node identified by the Request-URI provides the response. > >Perhaps an example would help ... > > > >POST http://example.org/order-processor HTTP/1.1 > >Host: example.org > >Content-Type: application/soap+xml > >[blank line] > ><?xml version='1.0' ?> > ><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> > > <env:Body> > > <order xmlns="http://retail.example.org/orders"> > > [order details go here] > > </order> > > </env:Body> > ></env:Envelope> > > > >That message has end-to-end semantics (the method, the Request-URI, > >the > >Content-Type, and the message payload) yet it's produced by the > >SOAP/HTTP binding, which, as you point out, is defined "between two > >adjacent SOAP nodes". If we introduced a SOAP/HTTP firewall > >(a SOAP intermediary), we'd do it by opening a TCP/IP connection to > >some port, and passing that exact same message above across the > >connection. > > > >FWIW, this is all consistent with the part of spec quoted above, even > >the part about using different protocols for different hops. Consider > >what would happen if we changed the Request-URI in the above > >example to > >mailto:order-processor@example.org. That's still end-to-end, but > >the second hop may very well be by SMTP rather than HTTP, something > >that a SOAP/HTTP firewall/proxy may be able to manage for us; HTTP in, > >SMTP out, ultimate destination of "mailto:order-processor@example.org" > >for both hops. > > > >How's that sound? I know it's a different model than the one most > >people have in mind, but IMO it's the only one consistent with both > >the > >SOAP and HTTP specs, hence my enthusiastic attempts to champion it. > > > It sounds like you are suggesting that a SOAP/HTTP intermediary > should be treated as a HTTP proxy (presumably a "non-transparent > proxy") rather than a HTTP gateway as is currently the case with the > SOAP 1.2 HTTP binding ? Sort of ... I disagree that the default HTTP binding assumes a gateway model, but yes, a non-terminating (proxy-like) model is what I have in mind. I should also add though, for clarity and completeness' sake, that SOAP/HTTP gateways can be SOAP intermediaries, and I'm not suggesting those shouldn't be able to be used, except insofar as they must also be the ultimate recipient. Earlier you mentioned a "SOAP level" and an "HTTP level". FWIW, my view is that there is only one level there that both technologies share. > If I followed you correctly then I think that sounds like an > interesting avenue for discussion but (as you note above) it doesn't > match the model most folks have nor (IMO) the current SOAP 1.2 HTTP > binding. Right. I think we can probably agree that there's ambiguity in the default SOAP 1.2 HTTP binding which the WS-Addressing WG interpreted one particular way. My position is that this interpretation is inconsistent (in very significant ways) with Web architecture, yet needn't be if the different interpretation is used. Moreover, with this other interpretation, the WS-Addressing specifications would be significantly simplified. The WS-A WG has already rejected this issue once before[1], so I'm under no delusion that it might pick it up again. When I return from vacation, I'll probably take it up with XMLP WG and see where that leads. The TAG has yet to take action on endPointsRef-47[2] too, which concerns the same issue. [1] http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0001.html [2] http://www.w3.org/2001/tag/issues.html#endPointRefs-47 Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Wednesday, 24 August 2005 03:46:31 UTC