Re: Thoughts about path and intermediaries

----- Original Message -----
From: "Mark Nottingham" <mnot@akamai.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: <xml-dist-app@w3.org>
Sent: Friday, February 09, 2001 7:17 PM
Subject: Re: Thoughts about path and intermediaries


>
> Don't give up hope! ;)
>
> I'll try and illustrate with a couple of scenarios.
>
> Imagine that you have a stock quote Web Service (i.e., RPC using
> XMLP) that is popular. The URI for the service is
>   http://soap.yourcompany.com/stockquote
>
> Your server can't handle the load, so you use intermediaries
> (deployed either by yourself or someone else) to cache the responses
> for a small amount of time. (This assumes the use of a caching module
> that is yet to be developed).
>
> To point clients at the intermediary, you have a choice;
>
>   a) change the reference that they point to to reflect a shared
>      intermediary address
>
>   b) point the authority for the URI (i.e., the DNS name) at the
>      intermediaries
>
> In either case, the intermediaries will need to be configured to
> forward messages to your actual server, as the request won't contain
> routing information to your server. This is similar to surrogates
> (aka "reverse proxies") in HTTP, which are used in so-called "Content
> Delivery Networks".
>
> So, the intermediaries will need to be addressable (to activate the
> caching module, or other services that can be distributed) without
> explicit routing in the message.

But surely in this case the sender is just sending a message to a piece of
software at the machine A. That piece of software happens to talk to another
piece of software on machine B. The sender is not aware of this second step.
Neither is XML Protocol. It's purely external to XML Protocol. There is
*nothing* in the message the sender sends that identifies B. There is
nothing in the message that requires any special processing at A before
being passed to B as far as the sender is concerned.

>
>  -- or --
>
> Imagine that you run an enterprise firewall (my condolences ;). Users
> inside want to use XMLP services, but you need to have some mechanism
> to control them. So, you require that they use a proxy to access any
> services, just as with HTTP. If you also require in-message user
> authentication, or provide any other services on the proxy, it needs
> to be adddressable, but routing to it is taken care of by clients in
> the transport binding (e.g., in HTTP, using a proxy doesn't change the
> request-uri in the message; in SMTP, the message contains the
> ultimate destination.)

[MJG]
I'm not entirely clear what's happening here so let me lay out two
possibilities

1.    There is nothing here that the sender is requesting. The initial
message doesn't contain any request for authentication that's just a layered
in service that the sender knows nothing about.

2.    The sender is the party requesting that the message be authenticated
and the proxy provides that authentication service. The sender now needs to
make sure the message goes to the proxy before going to the ultimate
destination.

As far as I can see in the caching scenario and case 1 above the sender
never puts anything in the message that must be processed at any node other
than the ultimate recipient. i.e. as far as the sender is concerned XML
Protocol is single hop, everything happens at the ultimate destination.

If this is the case then I *think* we may be in violent agreement;

a.    Routing in the message is unnecessary because at the XML Protocol
layer everything is single hop.

b.    Parts of a message are targetted at different software modules at the
ultimate recipient of the message.

c.    There is no way for the sender to target parts of a message at any
node other than the ultimate destination of the message.

In case 2 things are a bit different. The sender has to make sure the
message goes to the node the authentication service is running on ( let's
call it X ) *and* it needs to target part of the message at the
authentication service. The sender can either explicitly send the message to
X and provide information that the message should ultimately go somewhere
else. Or the sender can rely on configuration information to get the message
to X. This latter case worries me. The sender wants something to happen (
authentication of the message ) but it can't *ensure* the message goes via
the authentication service. If the system isn't configured correctly the
message will just be delivered to the ultimate recipient, what happens then?
The ultimate recipient will ignore the authentication request because it is
not targeted at it... sounds broken to me...

I still maintain that either a,b and c above hold or XML protocol supports
the explicit notion of path allowing a sender to specify a route for the
message. If we go this latter route then we can support processing
intermediaries en route to the ultimate recipient. I can't see how we can
support them otherwise because I don't thing implicit, configuration based
routes give enough determinism.

Note that going with the a, b and c approach does *not* preclude
intermediate nodes that map between transports ( e.g. HTTP<-->SMTP ) as such
nodes will not change the message the sender sent. It only precludes
intermediate nodes that modify or otherwise process the message the sender
sent.

>
> [ Interesting - is is perhaps a requirement for protocol bindings that
> they carry the identity (e.g., URI) of the ultimate recipient? ]

If we decide to support multi-hop then I think this is definately a
requirement...

Gudge

Received on Sunday, 11 February 2001 11:03:10 UTC