RE: Thoughts about path and intermediaries

>* There have been suggestions to move back to a single hop 
>protocol, putting all path-like notions at a higher level, and 
>Henrik suggests (I
>think) to do about what SOAP does today.  My view:  if path is 
>application level, then I'm not sure why SOAP-ENV:actor isn't 
>as well.  Given that SOAP deals at the level of naming 
>intermediaries and targeting headers to them, that's very 
>close to the level at which you worry about getting to the 
>intermediaries in the wrong order.  It feels to me as if actor 
>and header-path come more or less together.

Functionally speaking, the actual processing of a protocol message is
independent of how a message arrived at the processor. Traditional
protocol gateways are a good example of that. One can for example access
FTP through an HTTP gateway. Note that this is independent of whether
the receiving processor is an intermediary or the ultimate destination.

To me the most important argument for why we particularly in XML
protocol want to separate the two from each other is that we want to
support multiple path models. If we have to decide on one, then what
should it be? One-way, two-way, request/response, long-running dialogs,
store and forward, multicast, all of the above?

If we don't support targeting then we effectively say that there always
is some other envelope around our protocol that defines multi-hop
message paths as XML Protocol itself can't describe them. As this outer
envelope can't look into the XML Protocol message (because it can't be
an XML processor) then we effectively can't provide services like
caching or distributed services within the framework of XML Protocol.
IMO this effectively limits the use of the protocol to RPC style
interactions.

SOAP takes the approach of defining targeting but not the path itself.
This allows us to support all of the above message path models directly
within the SOAP processing model but it doesn't actually require any of
them to be used. This enables us to bound SOAP to as diverse protocols
like HTTP, SMTP, TCP, UDP, etc. 

>I'm not 100% sure whether I prefer to see all this in the core 
>or layered. Having a core point-to-point single hop protocol 
>has always had a certain minimalist appeal, but you can get a 
>lot richer routing and decision making if partial orders are 
>visible to the routing software.
>
>In either case, maybe it's as simple as having a mustFollow 
>header attribute that indicates (don't process me until you've 
>processed (idref of other header)?  If the attribute is 
>missing, no order is required.  (we have to think about cycles, etc.)

To me the possible space here seems to be quite large: it would seem to
span from a simple linear ordering to logic constructs and constraint
based processing of headers. If we take advantage of the implicit
ordering and put forward some constraints on not to reorganize the
header entries then migth this be suffient for layering more complex
rules on top by adding these before the headers for which they dicatate
the rules?

Thanks,

Henrik

Received on Wednesday, 14 February 2001 01:18:38 UTC