Re: Thoughts about path and intermediaries

On Wed, Feb 14, 2001 at 05:26:11PM -0000, Martin Gudgin wrote:
> > 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.

Gudge,

Just because you can't force a path doesn't mean you're neccessarily
unaware of what it will be. The most obvious example is a message
sent as a response on the same connection; the request's receiver
becomes the response's sender, and keeps state about where the
request has been, and possibly the capabilities of devices on that
path.

Also, implementors can and will use lower-layer constructs, like DNS,
interception, and client configuration to force an intermediary path.

This is all in addition to an XMLP routing module that will, in all
likelyhood, be specified.


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

Caching, etc. having very reduced functionality if they are relegated
to a lower level; indeed, I think caching would be nearly useless in
all but a few very specialized and inflexible applications. Access
into the application semantics is precisely why intermediaries need
to be full-blown XMLP processors, just as the end-points are.

Even if these functions were excluded from XMLP, there would still
need to be some bridge between lower-layer semantics (e.g., HTTP
cacheability) and the application semantics.


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

Why must it all be defined by this WG? If someone doesn't want this
processing to take place, they don't have to use processing
intermediaries. If they do, there are a number of message-external
mechanisms available, as discussed. If those aren't good enough, a
module which allows in-message routing can be developed and used to
this effect.

One of the most common aspects of intermediaries is that they are
often deployed without the explicit knowledge of the client. While
this may present a problem for extensions which the client requires
to be processed, it does not for those which are advisory (like
caching).

Cheers,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Wednesday, 14 February 2001 13:55:21 UTC