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

On Aug 23, 2005, at 11:48 PM, Mark Baker wrote:
>
> 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).
>
Its not so much that its my position, its just what the spec says  
right now. I know you've pointed out an ambiguity in one part of the  
spec but I quoted several other parts where that ambiguity is not  
present and reflects the interpretation I describe above.

> 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.
>
Right, as I said, you think that the SOAP/HTTP binding should treat a  
SOAP *intermediary* as a non-transparent proxy (BTW, I think there's  
some merit to this idea). The SOAP ultimate destination could either  
be an HTTP gateway or origin server as there's no real difference in  
the HTTP protocol between those two.

IMO, the SOAP 1.2 HTTP binding clearly treats intermediaries as HTTP  
gateways, I agree that there's ambiguity in the text you point to but  
your desired interpretation is not borne out by the rest of the  
specification.

> 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.
>
Understood.

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

I think that is understating the case. Its not just the WS-Addressing  
WG that interpreted the SOAP 1.2 HTTP binding one particular way,  
rather I'd posit that the interpretation I described at the top of  
this note is the commonly accepted one - the definition of the  
ImmediateDestination property is pretty crisp even with the slight  
ambiguity later in the spec that you pointed out.

>   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.
>
Understood, though more than a different interpretation is needed  
(IMO), the SOAP 1.2 binding would need to be changed.

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

That sounds like a sensible course of action given that is where the  
binding is defined.

Marc.

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

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