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

On Aug 19, 2005, at 11:39 PM, Mark Baker wrote:
>
> So correct me if I'm wrong, but when you called the WS-A SOAP binding
> "hop by hop", you were using it to refer to the part above that says
> "a SOAP protocol binding operates between two adjacent SOAP nodes  
> along
> a SOAP message path", correct?  I'll assume so.
>
Yes, exactly.

> I thought you were using it to refer to the semantics of messages
> (produced by the binding), which in my experience is the more common
> use.  If you weren't, that's ok, at least we're on the same page now.
>
> The important point to be made here though, is those two things we're
> using the term to refer to are orthogonal; that it's possible to  
> define
> a protocol binding which yields a message with semantics that reach
> beyond the path between the two nodes.  And that's what the default  
> HTTP
> binding does, because HTTP has both end-to-end and hop-by-hop  
> features.
> The Request-URI, for example, is end-to-end, hence my concern about  
> the
> overlap with wsa:To, which is also end-to-end as you say.
>
I'm not sure I understand, but to clarify I think that with the  
current HTTP binding, the HTTP request URI *is* end-to-end at the  
HTTP level but not at the SOAP level - at least in the general case  
where SOAP intermediaries are in place, see the example below.

> Another way to look at this is the "second node" in the default SOAP
> 1.2 HTTP binding isn't the one identified by the Request-URI, it's the
> one where the HTTP connection terminates, commonly a firewall or  
> cache.
>
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.

> 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 ?

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.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.