Re: TBTF: Proposal for a binding framework

> You consider a combination of bindings (e.g. SMTP+RPC) as a new
> binding requiring a new identifier.
> 
> Once people have come up with lots of different nested bindings
> (attachments, RPC, maybe compression, etc), the number of
> combinations will be fairly high, and a URI for each of them might
> become unworkable.
> 
> Presumably, the binding (and unbinding) of the SOAP message will
> have to be an ordered operation: e.g. XML Infoset -> XML
> serialization -> MIME multipart -> SMTP.
> 
> What about an ordered list of URIs for a combination of bindings?


This touches on something that I've been wanting to expand upon for
some time.

What a 'binding is' has encompassed several things during the
lifetime of the TF:

- underlying protocols (e.g., HTTP, SMTP, TCP, BEEP, etc.)
- underlying protocol features (encryption, authentication, etc.)
- message exchange pattern in use (one-way, request/response, etc.)
- attachment scheme in use (MIME, DIME, etc.)
- 'higher' (business) protocol constraints (RPC, etc.)

Although it looks like everyone agrees that a binding should be
identified by a URI, it appears that we haven't yet reached consensus
in this group (or maybe I just missed it) regarding what that
implies, in these terms.

As we do define them, I have these preferences;

- The potential pool of binding identifiers should not be needlessly
  large. 

  It's tempting to identify every permutation of these features with
  a different URI, but I question what purpose this serves; it only
  pushes the problem to a different place, requiring implementations
  to be able to know all of the binding URIs they support, as well as 
  requiring a system for generating binding URIs in a sensible
  fashion.

  A binding identity effectively becomes an alias for a group of
  properties in such cases; rather than saying "(HTTP, auth, SSL,
  request/response)" - in some syntax - we say "FooBindingID".

  Recent proposals that I've seen have moved towards supporting
  multiple MEPs and property optionality in one binding definition,
  which I like.

- We explicitly consider the uses of binding identifiers in resolving
  what their scope is.
 
  So far, I haven't seen any directed effort to architect what a
  binding identity is, based on the use cases; most of the motivation
  seems to be coming from "how to make it easy to describe a
  binding". I freely admit this may be due to inattention or lack of
  comprehension on my part.

  How do we plan BI's (new acronym, heh) to be used? Will they be
  transported in the message, in the underlying protocol, in WSDL and
  other descriptions? What constraints and requirements do the
  potential uses place on the identifier?

I also have a concern;

- Binding properties (which seem to include a number of the items
  above) have their own identifiers, so that they can be refered to. 
  This notion seems to be predicated on the idea that they will be
  able to be reused; i.e., if we refer to "FooProperty" in one
  binding, it might be possible to refer to the same "FooProperty"
  elsewhere, introducing efficiency, code reuse, etc.

  I'm nervous about this, as the semantics of a particular property,
  if 'punched through' from an underlying protocol, are often quite
  specific to that protocol. For example, while it's tempting to
  refer to the authentication supplied by RFC2617 as
  "authentication", this isn't too useful, as the operational aspect
  of 2617 authentication is somewhat more complex, and has
  implications, like the security of the authentication mechanism. 
  The same is true for other things, like message exchange pattern
  (there are timing issues with HTTP), encryption (cryptosystems are
  notoriously variable in their operational aspects), etc.

  What utility is provided by abstracting these things out to
  'properties' with identifiers if they do not fully describe their
  operational semantics, as to make them interchangable?

  It seems like I'm not getting something here; I'd be appreciative
  of any help.

Cheers,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Thursday, 16 August 2001 20:40:16 UTC