Re: INT: Re: Intermediary Discussion

On Wed, Feb 07, 2001 at 08:38:21AM -0000, Martin Gudgin wrote:

> > > 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.
> 
> [MJG]
> I guess I should have said 'Can XP Intermediaries also sit...' rather than
> 'Do XP Intermediaries also sit...'. MY point being that if we allow for the
> possibility then we need to have a design that supports that possibility.

I agree. However, the design shouldn't address this in the 'core'
intermediary definition - it's too dependent on the transport binding
and influenced by the application.

So, in our case it should be characterised in the HTTP binding and
possibly referenced in the RPC section as well. This would also be
appropriate for the transport binding / message exchange pattern
abstract model.

This is one of the reasons I think it's a good idea to split out the
RPC application and HTTP binding into separate documents, as they
confuse the issues.


> > 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.
> 
> [MJG]
> One of the things the Stuart Williams, John Ibbotson and I have discussed is
> the idea of defining an abstract model for transport bindings; what are the
> properties of bindings in general. Then of course we need to provide
> mappings onto concrete transports.

Very much agree. I'd be happy to help if you need it.


> > 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.
> 
> [MJG]
> The last sentence seems to argue against intermediaries in the 'XP Layer'
> and for intermediaries at a higher layer. Was this your intent?

No; was just a bit tired, I think :) I meant that the behaviour
exhibited by a particular module is highly specific to its function,
and also may be influenced by external criteria. 


> > > 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.
> 
> [MJG]
> I think I would argue that if an intermediary cannot be 'addressed' from
> within an XP message then that intermediary *must* be above the 'XP layer'
> and therefore our spec will have little ( if anything ) so say about it.

I think I agree - they need to be addressed, but probably not in the
'core' protocol, which defines the message semantics, etc. There
might be a need to at least reference it in an intermediary model.


Cheers,

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

Received on Wednesday, 7 February 2001 14:20:32 UTC