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.

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


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




On Fri, Feb 09, 2001 at 06:39:27PM -0000, Martin Gudgin wrote:
> 
> Mark Nottingham converged some electrons...
> >
> > I agree with Henrik (although strangely, I haven't received his
> > message yet).
> >
> > Targeting without in-message routing is perfectly plausable; routing
> > can be supplied by the transport (through the URI, client
> > configuration of a proxy, etc.), by the application service layer
> > above the XMLP layer, an in-message routing convention that can be
> > specified later, as a Module, or combinations of them for multi-hop
> > intermediaries.
> 
> I'm obviously being especially dense right now but to me this seems like the
> worst of both worlds. A sender creates a message with some parts targeted at
> intermediary processors en-route and has no way of specifying that route...
> I don't get it...
> 
> I can see how a sender could target parts of the message at different
> software modules at the ultimate destination of the message because the
> sender gets to say 'send this message to that destination over there'.
> 
> I just can't see how the sender gets to target parts of the message at
> software modules at an intermediary if it has no control over which
> intermediary nodes the message goes via.
> 
> Please, please, please help me see what I am missing...
> 
> Yours desperately,
> 
> Gudge

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

Received on Friday, 9 February 2001 14:17:54 UTC