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

Rich,

On Wed, Aug 24, 2005 at 12:21:26AM -0400, Rich Salz wrote:
> On Tue, 23 Aug 2005, Mark Baker wrote:
> > 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.
> 
> As you well know, SOAP treats HTTP as a transport protocol, not an
> application protocol.

That's incorrect.  As an example of how the binding doesn't treat HTTP
as a transport protocol, consider that SOAP faults are returned using
HTTP error codes.  In fact, other than the ambiguous definition of the
ImmediateDestination property, I challenge you to point out a single
part of the specification which supports your claim that the binding is
a transport binding.

>So the justification for your interpretation
> here is just being obstinate. :)  Until WS-Addressing came along,
> SOAP had no end-to-end for defining the target.

You don't think that's odd?  That a Request-Response MEP had no
means of actually identifying the thing that provides the response?
That's either a massive oversight, or else something else is going on
here.

Consider the issue you guys had over how one knew whether WS-Addressing
was active for a given message; an issue that completely vanishes with
my interpretation of the spec.

>As far as the SOAP
> processing model went, each hop explicitly addressed the next hop.
> For example, if the ultimate recipient is to be delivered via SMTP,
> nobody expects the intermediate nodes to see a mailto URL.  Yes,
> you've said there's no reason why this can't be done (too tired
> to track down the email links).  But it is not what anyone in this
> community expects.

I think there's more than one community here.

> > 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.
> 
> That is not the way SOAP works.  You know this.

No, Rich, I don't.  That's how you, and some others interpret it to
work.  Web nuts like myself, and I expect Henrik too, see it as I
described.  I'd even go (way) out on a limb and suggest that Dave
Orchard may now see things this way.  And IIRC, Stuart Williams and
Noah Mendelsohn thought along these lines during the development of
XMLP.  I don't know if they still do, of course, but I'd bet you that
I'm not the only person here who holds this view.

> > 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.
> 
> That is not the way SOAP works.  You know this.

If it worked this way, I would have objected, strenously, during its
development.  And it's not like I was trepidacious about raising
objections during that time, if you recall. 8-)

> "Pretending" that it does work this way, or claiming to view things
> as if it did work that way, only confuses newcomers, and wastes
> other people's time as they try to "teach" you.  Enough Socratic
> games, okay?

I don't have time to waste on games, Rich, and I resent your suggestion
that I do.

> There is no ambiguity; there are just those who want it to be
> something other than what it is.

So how do you explain the value of the ImmediateDestination being
described as "An identifier (URI) that denotes the responding SOAP
node"?  If that's a typo, as Chris suggested, is it just a coincidence
that it's a typo completely consistent with my view?

In short, my interpretation of the spec is at least as consistent with
the SOAP 1.2 spec-as-written than yours, possibly more so.  Moreover,
it's consistent with the HTTP specification and Web architecture, unlike
your interpretation.

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 13:45:13 UTC