RE: Protocol Bindings

> I would be cautious applying too much of a layered view -
> especially as SOAP can be used in combination with a
> variety of underlying protocols that traditionally are
> seen as belonging to different layers.

Hmmm ... Is this really correct?

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.

We should be aiming for a stack such as:

+-------------------------------------
|
| XMLP/SOAP (Messaging layer - describes the soap envelopes, etc.)
|
+---------- <---- (binding describes this interface only, not below it)
|
| BEEP or HTTP or Custom or ... (Application protocol layer - describes
|                        how apps exchange messages)
|
+-------------------------------------
| TCP or SCTP or ... (Transport layer - how the bits are carried)
+-------------------------------------

The problem with the current situation is that "binding" can mean anything -
and this gives rise to the 'super'-binding for TCP which actually defines a
mini-application protocol just for SOAP inside the binding. I think we
should acknowledge that this exists, give it a name (one may be chosen that
does not offend anyone - 'custom', 'dedicated', 'SOAP-specific', etc.), and
when examining the options for carrying SOAP envelopes we can compare "BEEP
over TCP" vs. "Custom over TCP"  vs. "HTTP over TCP" and we get clean
layering.

I should say I don't see a problem with having a dedicated application
protocol for SOAP (it might make sense in some situations), but I do see a
problem trying to hide it within the binding.

> ... different underlying protocols provided different service
> abstractions ... and that some bindings may be thin and others thick

Obviously different bindings will not be all of the same size, but the
problem with having such a thick binding (that includes an application
protocol) is that it breaks the clean layering.

>> If the underlying protocol merely transports the bits (e.g. TCP) - who
>> describes ... session establishment (where to connect to), how transport
>> security is provisioned, what are the rules for authentication, what
>> support is there for intermediaries (e.g. to get through firewalls -
>> [not talking about SOAP intermediaries here]), how errors are
>> reported (of the underlying protocol - not SOAP Faults) etc., etc.

> 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, 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.

Eamon

Received on Friday, 6 July 2001 09:55:28 UTC