RE: Thoughts about path and intermediaries

>I'm sorry, I still don't get it. I can't see how soap:actor
>works. How does putting a URI on a part of the message help me
>if I don't get to stipulate that the message has to go via
>that URI?

It works the exact same way as the ultimate destination which is also not
mentioned in the SOAP message :)

>I think that you are treating the HTTP case and the
>XML Protocol/SOAP case as though they are one and the same (
>or at least very similar ) and I don't think they are one and the same.

No, in fact I am deliberately excluding everything that is not directly within
the SOAP message. HTTP really has no impact on the message path of the SOAP
message.

>I don't think your example above ( A to D ) holds; I can
>easily forsee a situation where XML Protocol is inherently
>single hop ( A to D ) while still supporting caching, load
>balancing etc at a lower level. XML Protocol doesn't need to
>be aware that those things are happening, it's just moving a
>message from A to D, if some system puts B and C in between A
>and D thats fine, they can do their caching thing or whatever
>without needing to do anything to the XML Protocol message. I
>can also see a need to define how transport mapping happens (
>HTTP<-->SMTP for example ), but again from the XML Protocol
>layer point of view it doesn't affect the content of the message.

But what I think you are saying here is that there are XML Protocol
aware nodes in the system that can change the message, redirect it, and
cache it without the two parties communicating having any possibility of
affecting it. In order to do something like caching for example the two
ends have to be able to affect the caching model. This means that there has to
be some mechanism for talking to the cache.

>Things that probably will require extra stuff in the message (
>e.g. authentication ) will either need to be single-hop (
>sender sends message with auth info, receiver checks it ) OR
>we define a path model for XML Protocol that allows us to
>target particular bits of a message at particular software
>entities *AND* make sure the message goes via those entities.

You are absolutely right that targeting and some form of routing is
necessary in order to actually exchange the message. There is no magic
here! My point is slightly different: how can we do the *absolutely
minimum* for supporting the various message path models well-knowing
that it is necessary but not sufficient. This is the same trade-off that
we have made with security and a variety of other functionalities that
we know are important but that we are not going to define because of
time constraints.

Henrik

Received on Wednesday, 14 February 2001 13:53:24 UTC