Re: infoset and bindings

Mark,

	Date: Mon, 9 Jul 2001 16:36:45 -0700
	From: Mark Nottingham <mnot@mnot.net>
	To: Mark Jones <jones@research.att.com>
	Cc: xml-dist-app@w3.org
	Subject: Re: infoset and bindings

	Mark,

	To make sure I get it; would this be a reasonably accurate summary of
	your proposal:

	  Bindings must define an Infoset representation of the services that
	  they provide and the restrictions that they impose on the uses of
	  SOAP messages. These representations should be able to be
	  serialized into SOAP Header Blocks.

	Cheers,

I think of sending the message from the sender's perspective in the
following way:

 1) The sender knows the basic content to be delivered and any
    ancillary sender-specified services.  (Delivery paths may
    also invisibly provide other "services" en route that are
    transparent to the sender.)

 2) The sender also determines an overall messaging pattern
    (fire-and-forget, request-response, etc.) from its
    perspective.

 3) The sender must also construct some delivery plan that is
    consistent with 1) and 2).  The sender may be hardwired or use
    meta-data (obtained via some unspecified mechanism) to determine
    this delivery plan.  The sender may completely determine the
    routing path, protocols, etc., for all hops or its plan may
    include the delegation of some of these decisions to routing
    intermediaries, but nonetheless it has a delivery plan.  (In
    particular, the next hop of the plan must be concretely determined
    at the sender and each intermediary.)

An infoset representation of the message at any given point along
the message path includes all of the above information that is still
required for subsequent delivery and processing.

Abstractly, I think of a "binding" as functionality that can properly
execute the next step in the delivery plan given an infoset
representation of the message.  This involves the choice of an
appropriate set of transport/transfer/encapsulation protocols
(serialization, etc.) for the next hop in such a way that the receiver
at the end of the hop can continue to maintain the invariant -- to
preserve the message infoset necessary for the remaining delivery and
processing.

Although a particular binding will typically specify a principal
transport protocol (HTTP, SMTP, BEEP, etc.), I think we should reserve
the term "binding" for the functionality that maps the message infoset
into as many protocol layers as may be required.  (I'm also a
"layerist" in terms of the implementation; a binding is a
plan/rules/method for mapping a message infoset to the appropriate
layers.)

Senders (or other nodes that take an active part in determining a
delivery plan) will, of course, be well advised to select paths that
support bindings with suitable functionality for the message at hand.

As an example, suppose that a sender S could obtain service either
from recipient R1 using binding B1 or from recipient R2 using binding
B2.  Furthermore, let's assume that the (abstract) message infoset
includes a sizeable chunk of non-XML data, and that binding B1
supports a MIME-encapsulation layer, but B2 does not (with B2, the data
might need to be base64 encoded and placed inside the envelope).
(Assume that both B1 and B2 specify the same underlying transport
protocol such as HTTP.)  The sender may intelligently use such
considerations to prefer a delivery plan that incorporates binding B1
to R1 instead of B2 to R2.

The above example could have as easily picked on other services such
as security that may be better supported via some bindings/paths than
others, perhaps because the associated protocols provide better
support native for those services.  A truly extensible infrastructure
would allow the (dymanic) constuction of delivery plans that take into
account any (open-ended) set of service parameters.

--mark

Received on Monday, 16 July 2001 15:29:15 UTC