Re: Protocol Bindings

> I think we are confusing two quite different things here. For a while
> now I've been uncomfortable with the notion that "everything is a
> binding" such that e.g. SOAP with attachments (MIME) is treated the same
> way as HTTP.

From the SOAP message's viewpoint, all that it knows is that something is
below it. It may provide services or impose restrictions, but both are made
to the application using SOAP, not the message itself. Whether it just
encapsulates or transports, from SOAP's point of view, there is no impact on
the message itself, just the use of the message.

That having been said, I agree that it may be useful, for the benefit of
user guidance, to distinguish between bindings that impose restrictions
and/or provide services, and those that do not.

> IMO we have two separate concepts:
>
> (i) Packaging Format
> In this category I would put MIME (SOAPwA), DIME, ...
>
> (ii) Transport.
> In this category I would put HTTP, SMTP, BEEP, TCP, ...
>
> The key difference I think is that transports provide for actual message
> movement and hence require discusssion of things like endpoint address
> format, message exchange pattern, connection/channel management, ...
> Packaging formats are completely agnostic in all of these areas
>
> In many case we will want to combine things from both categories and in
> this case the following rules seem to apply:
>
> (a) Packaging formats can be nested in any given message exchange. e.g.
> one could put SOAP in MIME in DIME.
> (b) 1 (and only 1) transport can be used in any given message exchange.
> i.e. it makes no sense to nest one transport in another. I'm ignoring
> protocol tunneling here since this is transparent to transport clients.
> (c) If we are thinking in terms of nesting then the transport must be
> the "outer" layer.

Agree very much - had the same thoughts. 'rules' may be too strong, though.


> I think that mixing up packaging and transport under the single
> umberalla of "binding" only makes things more complex for us. There are
> real substantial differences between packaging and transport and we
> should recognise and make use of them.

That's why I proposed the subclassing -
Binding    ---> "something underneath" from SOAP's point of view
EncapsulationBinding(Binding)   ---> just provides packaging
ProtocolBinding(Binding)   ---> incurrs protocol semantics as well

I think these can be made to align quite easily.

Received on Thursday, 5 July 2001 14:53:17 UTC