Re: INT: Re: Intermediary Discussion

On Tue, Feb 06, 2001 at 10:16:30PM -0000, Martin Gudgin wrote:
> After reading these posts I think we are still some way from consensus on
> *exactly* what an XP intermediary is but we do seem to have broad
> agreement that;
> 
> 1.    XP Intermediaries sit between the sender of a request and the
> ultimate recipient of that request.
> 
> 2.    XP Intermediaries perform some processing of the request
> message.
> 
> 3.    Exactly what processing occurs at an intermediary is defined
> by extension blocks.
> 
> 4.    There needs to be a way of addressing intermediaries from
> within an XP message.
> 
> 5.    There may be multiple intermediaries between the sender and
> the receiver.

Agree.


> Open questions/issues...
> 
> Do XP Intermediaries also sit between the sender of the response
> and the ultimate receiver of that response? And hence also process
> the response message assuming one exists.

I think it depends very much on the transport binding, the message
exchange pattern, and the nature of the intermediary. Some will
require both messages to pass through the intemediary (e.g., HTTP
requires request/response), while it's conceivable that another
MEP/transport binding could do asymetric routing.

I think this is why I'd like to see formalized requirements for
transport bindings as a class, and a detailed description of the
constraints they put on XP and the higher-level application,
especially thorugh the message exchange pattern(s) implied by the
binding. A lot of it will be obvious, but some won't.

Whether or not the messages will be processed on both the request and
response is yet another issue; some will do just requests, some just
responses, some both. Some may choose not to modify the message at
all, based on its semantics, the time of day, phase of moon, etc.
Seems more of an Web Service-level issue than XP.


> If a given intermediary is the 'target' for more than one extension
> block in an XP message does a processing order need to be defined
> and is so how do we define it?

I think so. Good question ;)


> 1.    Taken from Hugo's mail ( thanks Hugo! )

I like this one the best.


> 2.    Slight amendment to the above to add notion of addressability

It can be addressable, but this implies that it must be. An
intermediary may need/want to perform processing that isn't
explicitly triggered in the message.


> 3.   Slight amendent to 3 to make the possibility of multiple
> intermediaries more explicit

"towards" in #1 implies multiple intermediaries, but I see your
point.


Cheers,

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

Received on Tuesday, 6 February 2001 19:14:11 UTC