RE: Thoughts about path and intermediaries

Hi Mark, Martin,

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

Well, I guess I have a few thoughts too... the extracts are in order from
Mark's message included in full below.

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

It is my hope that users of XMLP (developers, applications...) ideally have
no knowledge whatsoever of the protocols operating beneath XP. Whilst, I
would not prevent them from 'finding' out about features of the underlying
protocols, it seems to fly in the face of any notion of abstraction and
layering to perculate all the fine-grain detail and rich variety of
underlying protocols upward and expose them to the application. IP runs over
X.25, 802.x, ATM, SONET, Satelite Links, phone wires and carrier pidgeon
(there is an Avian Carrier binding in the RFC collection [1,1a]). I know of
very few circumstances in which the user of IP needs to be exposed to the
details of the underlying link protocols. In the same way, I would hope that
we can shield the user of XP from *having* to know the details of HTTP,
SMTP, BXXP... and whatever other underlying protocol we might create
bindings for.

I think this is some of what Noah was talking about in [2,3].

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

Enough determinism so that either... someone can look at a given
installation from outside and figure out what its going to do in a given
circumstance. Anything less is just complete chaos. A next level of
determinism is where the sender of a message (an application or the
developer of an application) rather than the all seing eye, can predetermine
what will become of a message they choose to send.

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

For XMLP to be "...the first choice of anyone who needs to shovel XML across
a wire in some fashion..." XMLP needs to present them with a mental model
that is easy to grasp and it needs ot be independent of particular bindings.
It needs to have some firmness about the heart of what it does. If it can be
all things to all people, we will have a hard time defining what it is in
particular.

Regards

Stuart

[1] ftp://ftp.isi.edu/in-notes/rfc1149.txt
[1a] ftp://ftp.isi.edu/in-notes/rfc2549.txt
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0055.html
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0065.html

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@akamai.com]
> Sent: 12 February 2001 05:27
> To: Martin Gudgin
> Cc: xml-dist-app@w3.org
> Subject: 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 05:33:39 UTC