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


On Fri, Aug 19, 2005 at 03:32:26PM -0400, Marc Hadley wrote:
> On Aug 19, 2005, at 11:10 AM, Mark Baker wrote:
> >>>
> >>wsa:To gives the value of the ultimate recipient, but the SOAP
> >>binding is hop-by-hop so ImmediateDestination could be the address of
> >>a SOAP intermediary instead of the ultimate recipient.
> >
> >Sorry, I don't follow.  I don't know what it means for the WS-A SOAP
> >binding to be hop-by-hop, since the SOAP processing model is end-to- 
> >end.
> >
> See the SOAP 1.2 Rec[1]:
> <quote>
> The SOAP Processing Model enables SOAP nodes that include the  
> mechanisms necessary to implement one or more features to express  
> such features within the SOAP envelope as SOAP header blocks (see 2.4  
> Understanding SOAP Header Blocks). Such header blocks can be intended  
> for any SOAP node or nodes along a SOAP message path (see 2.3  
> Targeting SOAP Header Blocks). The combined syntax and semantics of  
> SOAP header blocks are known as a SOAP module, and are specified  
> according to the rules in 3.3 SOAP Modules.
> In contrast, a SOAP protocol binding operates between two adjacent  
> SOAP nodes along a SOAP message path. There is no requirement that  
> the same underlying protocol is used for all hops along a SOAP  
> message path...
> Certain features might require end-to-end as opposed to hop-by-hop  
> processing semantics. Although the SOAP Protocol Binding Framework  
> allows end-to-end features to be expressed outside the SOAP envelope,  
> no standard mechanism is provided for the processing by  
> intermediaries of the resulting messages...
> </quote>

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.

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.

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.

Perhaps an example would help ...

Content-Type: application/soap+xml
[blank line]
<?xml version='1.0' ?>
<env:Envelope xmlns:env=""> 
  <order xmlns="">
    [order details go here]

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

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

BTW, I should mention that I'm heading off on vacation in a few hours,
and will likely be without email access for a couple of weeks, so feel
free to take your time mulling this over.


Mark Baker.  Ottawa, Ontario, CANADA.
Coactus; Web-inspired integration strategies

Received on Saturday, 20 August 2005 03:37:45 UTC