RE: TBTF: nature of transport bindings

>* Bindings are expansive and exclusive - there is a 1:1 relationship
>  between bindings and what is bound to. E.g., there is an
>  authoritative 'HTTP' binding, and all SOAP messages sent across an
>  HTTP connection (as identified by URI scheme, port, protocol
>  header, etc.) are presumed to use it.
>
>  This implies that use of protocol-specific features (e.g.,
>  authentication, correlation, status codes, etc.) is specified
>  externally (e.g., by WSDL), and that the transport binding is
>  'loose'.

This approach is valuable in that it significantly aids developers
addressing the challenge of interoperable SOAP-using entities. It will
mean that there is no particular requirement to negotiate binding
idiosyncrasies because the binding is standardized and this is also
a good thing. Another good thing is that a normative description of
the binding is then a testable compliance point that can be used
as a basis for a third-party test suite.

>* Bindings are specific and non-exclusive - there can be a number of
>  bindings for a particular transport, each with different features
>  (e.g., MEP, correlation, use of status codes, etc.). The nature of
>  the SOAP interaction over the binding is determined by the identity
>  of the binding.
>
>  This implies that a means of communicating the identity of the
>  binding in use will be developed, and may engender a proliferation
>  of binding definitions. Bindings would be 'tight', and XMLP WG's
>  output would most likely be an HTTP binding optimised for RPC
>  (reflecting current use).

This is good for developers that have a fixed set of semantics in mind
for a particular application. It is also good for developers that
may want to implement only a part of a normative HTTP binding for reasons
of constrained environment, etc. It could also be the basis for a
new suite of difficulties in interoperability and it brings in the
need to standardize the interchange of binding details. Which in
turn needs a binding :)

>Both approaches seem to have their good and bad sides. I'd note that
>in either case, we seem to have a requirement to have a way to
>communicate the features in use; it's just a question of whether it's
>better to do this with a single token (option two) or with a set of
>metadata (option one).
>
>These options can also be viewed as a continuum, or a grab bag (e.g.,
>an expansive-and-exclusive approach with tightly defined permissable
>status codes). I'd be interested to hear where people presently sit,
>if this is felt to be a useful way to frame the problem.

I come from the land of (option one) where there is a set interoperable
binding or equivalent, so I am comfortable with a requirement for that
approach. But I am also aware of the fact that this can be very constraining
in some cases and would be willing to support (option two) provided there
is a default (option one) style behaviour that can be used as a baseline.

In terms of compliance (possibilities):
  . a compliant implementation must support the normative binding for
    at least one protocol (should this be 'any'?)
  . a compliant implementation must support the basic binding exchange
    protocol at level 0 (i.e. I don't know how to exchange bindings, sorry).
  . a compliant implementation may support the basic binding exchange
    protocol at level 1 (can fully converse to negotiate bindings)

 --oh

Received on Thursday, 19 July 2001 08:11:31 UTC