Re: wsa:To -> SOAP1.2's ImmediateDestination

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