RE: Thoughts about path and intermediaries

>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. If the sender doesn't specify a path
>then it will need to have a-priori knowledge (or just faith)
>that the initial intermediary will "do the right thing" with
>the message to ensure that all headers targeted at
>intermediaries located on other nodes are processed. If the
>sender doesn't know which intermediaries will be visited
>beyond those located at the first node then why would it
>bother to insert headers targeted at intermediaries not located there ?

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?

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.

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.

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.

If you look at the evolution of HTTP/1.0 back in 1994 then this was
exactly the problem that faced HTTP. HTTP was eventually made into a
multi-hop protocol but it had a huge impact on the flexibility and
capability that one could put into intermediaries.

This is why we baked it into SOAP and let the "actor" mechanism show up in two
places: for targeting and for identifying who generated a fault.

Henrik

Received on Wednesday, 14 February 2001 12:10:59 UTC