RE: Thoughts about path and intermediaries

On Wed, 14 Feb 2001, Henrik Frystyk Nielsen wrote:

> >I remain confused as to why a sender would want to include
> >headers targeted for a given intermediary without being able
> >to specify a path to ensure that the nodes hosting each
> >intermediary are visited.
> 
> I think it would be beneficial to try and think of this from the other
> way round: given that we have some sender sending a message to some
> other recipient then how will that be able to work through an
> intermediary put in place for administrative or value added services?
> Unless we believe that such intermediaries will never have an impact on
> the XML Protocol itself then how can they be supported?
> 
There are two kinds of intermediary here, those that the client is aware
of and those that it is not. More on this distinction below.

> In order to answer this, I think it is important to look at the
> fundamental difference in what I call the "default targeting" of a
> multi-hop path vs. a single-hop path. In the example below, the default
> targeting for a multi-hop path is from A to D:
> 
>     A --> B --> C--> D
> 
> But in a single-hop path, the default targeting is from A to B. Using a
> single-hop model makes it hard to introduce an intermediary later on
> that can handle caching, requires authentication etc. because the client
> has no mechanism to say that the message is not really for B but for D.
> 
It seems to me that we have three options:

1) Implicit routing. In this mode of operation the XMLP layer at A is
configured to send all messages destined for some set of recipients (D in
this case) via B. The XMLP layer at B would be similiarly configured to send
messages via C. In this case, the sender (and here I mean the client
application) is unaware of the route and hence would not add blocks targetted
for handlers at B or C. I think
this sort of matches your (b) below and is useful for intermediaries that
the client is unaware of (e.g. firewall proxy). This would just require
targetting support in XMLP

2) Explicit routing. In this mode of operation the sender specifies that the
message must go via nodes B and C. In this case, the sender might include
blocks targeted at handlers hosted at B and C in order to make use of services
they provide. This form of routing is useful for intermediaries that the 
client is aware of. This would require routing and targeting support in XMLP.

3) A combination of 1 and 2.

> In effect I can think of three ways this can be done:
> 
> a) break XML protocol 1.0 and define 2.0
> 
> b) require that there always be some outer envelope that can deal with B
> and C and that there never is any interaction between the XML protocol
> message and B and C. The question then it what that envelope should look
> like and how it relates to the XML protocol envelope.
> 
I don't see why you need an outer envelope ? I can see you needing 
final and intermediate destination entries in the envelope, but not
an outer envelope as such.

> c) use a mandatory flag. However, if we do that then there is no way to
> deal with faults from B or C as there is no way to define where they
> come from. And we make it impossible to introduce optional features like
> caching because all extensions by definition are breaking because of the
> mandatory flag.
> 
Could you explain (c) in more detail, I don't grok your meaning.

Thanks,
Marc.

-- 
Marc Hadley <marc.hadley@uk.sun.com>

Received on Wednesday, 14 February 2001 13:12:12 UTC