Re: Thoughts about path and intermediaries

----- Original Message -----
From: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
<SNIP> Stuff from Mark Hadley</SNIP>

> I think it would be beneficial to try and think of this from the other
> way round: given that we have some sender sending a message to some
> other recipient then how will that be able to work through an
> intermediary put in place for administrative or value added services?
> Unless we believe that such intermediaries will never have an impact on
> the XML Protocol itself then how can they be supported?
>
> In order to answer this, I think it is important to look at the
> fundamental difference in what I call the "default targeting" of a
> multi-hop path vs. a single-hop path. In the example below, the default
> targeting for a multi-hop path is from A to D:
>
>     A --> B --> C--> D
>
> But in a single-hop path, the default targeting is from A to B. Using a
> single-hop model makes it hard to introduce an intermediary later on
> that can handle caching, requires authentication etc. because the client
> has no mechanism to say that the message is not really for B but for D.
>
> In effect I can think of three ways this can be done:
>
> a) break XML protocol 1.0 and define 2.0
>
> b) require that there always be some outer envelope that can deal with B
> and C and that there never is any interaction between the XML protocol
> message and B and C. The question then it what that envelope should look
> like and how it relates to the XML protocol envelope.
>
> c) use a mandatory flag. However, if we do that then there is no way to
> deal with faults from B or C as there is no way to define where they
> come from. And we make it impossible to introduce optional features like
> caching because all extensions by definition are breaking because of the
> mandatory flag.
>
> If you look at the evolution of HTTP/1.0 back in 1994 then this was
> exactly the problem that faced HTTP. HTTP was eventually made into a
> multi-hop protocol but it had a huge impact on the flexibility and
> capability that one could put into intermediaries.
>
> This is why we baked it into SOAP and let the "actor" mechanism show up in
two
> places: for targeting and for identifying who generated a fault.

I'm sorry, I still don't get it. I can't see how soap:actor works. How does
putting a URI on a part of the message help me if I don't get to stipulate
that the message has to go via that URI? I think that you are treating the
HTTP case and the XML Protocol/SOAP case as though they are one and the same
( or at least very similar ) and I don't think they are one and the same.

I don't think your example above ( A to D ) holds; I can easily forsee a
situation where XML Protocol is inherently single hop ( A to D ) while still
supporting caching, load balancing etc at a lower level. XML Protocol
doesn't need to be aware that those things are happening, it's just moving a
message from A to D, if some system puts B and C in between A and D thats
fine, they can do their caching thing or whatever without needing to do
anything to the XML Protocol message. I can also see a need to define how
transport mapping happens ( HTTP<-->SMTP for example ), but again from the
XML Protocol layer point of view it doesn't affect the content of the
message.

I can't see why any of these scenarios ( caching, load balancing etc )
require anything to go in the XML Protocol message and therefore I can't see
what they have to do with XML Protocol with respect to the routing and
targetting of messages.

Things that probably will require extra stuff in the message ( e.g.
authentication ) will either need to be single-hop ( sender sends message
with auth info, receiver checks it ) OR we define a path model for XML
Protocol that allows us to target particular bits of a message at particular
software entities *AND* make sure the message goes via those entities.

Gudge

Received on Wednesday, 14 February 2001 12:27:24 UTC