Re: Thoughts about path and intermediaries

On Sun, Feb 11, 2001 at 04:02:12PM -0000, Martin Gudgin wrote:

> > Imagine that you have a stock quote Web Service (i.e., RPC using
> > XMLP) that is popular. The URI for the service is
[...]
> 
> 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.

There are a number of aspects in which it would be useful to target
the intermediary. The request sender may not be aware that they're
using one, but the response sender certainly will be; for example, if
it wants the response message cached, it will need to target the
intermediary on the way back.

Another example; let's say you've got a desktop scheduling/
calendaring program which uses XMLP to talk to some centralized
servers, and you use intermediaries to distribute the service and
provide some performance benefits though geographic locality as well
as improve reliability. The software that you distribute may very
well know about the intermediaries, while routing is still done
through the URI as above.

The most important thing that targeting gives you, though, is the
ability of processors, including the ultimate receiver, to identify
extensions that they shouldn't process. 

I agree that the line here between functionality invoked at the "XP
layer" and the "service layer" above it is fuzzy; however, I think
it's fuzzy for the same reasons that it is in XMLP as a whole; the
protocol is being designed to give applications hooks (through the
headers) into the transport layer, by defining a processing model for
messages. Targeting gives this another dimension.


> > Imagine that you run an enterprise firewall (my condolences ;).
[...]

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

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

Yes.

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

True in the case of the request sender for the caching scenario, but
not the response sender. Invert for this scenario.


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

The idea in this *particular* case was that the only way to
sucessfully route to the ultimate receiver, because of network
configuration, is through the intermediary. I should have said
authorization, not authentication - apologies. I.e., the idea is that
users need to prove that they're allowed to use the service to the
intermediary before being let through.


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

Gives enough determinism for what? I know that some applications will
need in-message routing, and therefore the concept of message path,
to make intermediaries useful, but I doubt all do. Some people will
use XMLP in the ways I've described; others will need an explicit,
in-message path, in which case they'll have to wait for the
'in-message routing' extension to be developed.

XMLP shouldn't be build to fit a particular application's
requirements; rather, our it should be a generic toolset that can be
used for many different purposes. It's not just for RPC, distributed
objects, etc; hopefully, it will be the first choice of anyone who
needs to shove XML across a wire in some fashion, whether they're
developing an application or a protocol. That's how I've been
thinking, at least.

Does anyone else have something to say about this? I think both
Martin's and my heads are starting to hurt ;) 


Cheers,

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

Received on Monday, 12 February 2001 00:27:44 UTC