Re: Protocol Bindings

On Fri, Jul 06, 2001 at 02:58:30PM +0100, Eamon O'Tuathail wrote:
> 
> I would argue that the "binding" should be a thin veneer between the
> messaging layer and the application protocol layer, and nothing else. If we
> stick to this rule then we *do* get obvious layering, which will give us a
> much cleaner architecture.

If you have a hammer...

A simple model will certainly be easier to understand, and layering
is all about abstracting out things that you don't care about. I
think the current debate is whether layering is an accurate and
useful model for what SOAP does.


> > ALL of these things can be provided by underlying protocols,
> > in-message SOAP blocks, pre-arranged convention, voodoo or a
> > combination of these sources
> 
> If we skip the voodoo, ignore pre-arranged conventions as they usually cause
> problems - especially with wide deployment, 

Interesting - Akamai uses pre-arranged conventions (distributed,
out-of-band state) to configure somewhere around 10,000
intermediaries in a global deployment... what's you're definition of
'wide'? ;)


> I would question whether SOAP blocks can gives us the above (note I
> specifically excluded SOAP aspects in above), so we are left with
> 'underlying protocols'. A transport protocol such as TCP carries
> the bits, so something above that, an application protocol,
> provides this functionality... which is precisely my point.

There are already proposals for routing and endpoint identification
(SOAP-RP), authentication (XML Digital Signatures), caching
("Optimising Web Services with Intermediaries"), and discussion of
others, including explicit correlation. All of these are expressed in
SOAP blocks.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Friday, 6 July 2001 20:31:05 UTC