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

Bindings : a quick cut at an abstract definition

From: Glen Daniels <gdaniels@macromedia.com>
Date: Mon, 30 Jul 2001 07:50:48 -0400
Message-ID: <012301c118ed$e036fb60$0b00a8c0@gamebox>
To: <xml-dist-app@w3.org>
This is a quick take at what a high-level "binding" abstraction might
look like.  I start off by presenting a little context, then take a
stab at a (very small) abstract binding framework.

A couple of things to note first:

The message infoset is an entirely abstract notion, and the actual
representation of the infoset in memory or on the wire is entirely up to
the application.  An example: we may define an infoset item which
indicates that a given message is an RPC request.  One possible
implementation might actually insert a block into the message which
carries this information.  Another implementation may implicitly "know"
that this information is "virtually" in the message by virtue of the
fact that an API such as "call(method, arguments)" was invoked in the
execution path.

To send or receive a SOAP message, a binding must be selected.  Therefore,
it seems likely that the binding name itself is an item in the message's

Bindings supply "facets".  Some of these facets may be entirely internal
to the binding in question, and in this case they do not need to be
specified in any particular way.  Some facets, however, may be expressed
in terms of the message infoset - doing this allows the definition of
concepts that are shared or referenced across multiple bindings or other

OK, so a proposal for a binding framework might look as simple as this:

A binding should include:

1. A name (URI) for the binding

2. A specification of the binding's "private" facets.  This would be
any binding features/behaviors which do not have a well-defined
normative representation in the SOAP infoset, but still must be
clearly specified so that multiple implementations of the binding may
interoperate.  An example might be "this binding uses TCP port 4999".

3. A specification of the binding's "public" SOAP facets.  These would
be descriptions of how the binding generates, consumes, or in some
other way relates to particular normatively defined pieces of the
message infoset or other extensions/bindings.  This might include
message exchange patterns, security, or anything else that has been
defined by the WG or by extension writers.

... and that might be it.

I am still unsure about how to characterize the difference between
"encapsulation" bindings and "transport" bindings, and so have left this
intentionally vague in that respect.

Item 3 certainly could/should be expanded into more detail.  I also
note that it seems to me that the difference between a binding and
any other SOAP extension becomes somewhat unclear if we head down this
road - bindings, I think, are the only extensions allowed to specify
"private" patterns as in item 2, but aside from that it's very similar.
This may be a good thing or not.

Glen Daniels
                                Building cool stuff for web developers
Received on Monday, 30 July 2001 07:52:41 UTC

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