W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

TBTF: nature of transport bindings

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 18 Jul 2001 15:09:15 -0700
To: XML Distributed Applications List <xml-dist-app@w3.org>
Message-ID: <20010718150911.B26107@mnot.net>
As mentioned on the call today, I think one of the decisions we need
to make in defining bindings is their scope.

I can identify two approaches:

* 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

* 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).

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.

Mark Nottingham
Received on Wednesday, 18 July 2001 18:09:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC