TBTF: nesting

If we consider bindings as 'nestable', it requires us to define them
in more abstract terms; for instance, we can't assume that the entity
encapsulated by the binding is the SOAP envelope when it, in fact,
may be another binding.

This leads to a need for a framework that allows the potential for
nesting to be characterised. 

I've advocated a system whereby a particular, singlar binding in any
one transaction is 'blessed', in that it provides services to and
imposes constraints upon the SOAP application, while any other
binding in use explicitly does not; they only provide encapsulation.
Additionally, the 'blessed' binding MUST be at the 'bottom' of the
stack of bindings, if you conceptualize it that way.

For example, if HTTP and DIME are in use, HTTP provides services and
imposes constraints; DIME does not. Theoretically, if HTTP and SMTP
are in use, one of them has an interface to the 'wire', whilst the
other does not, and therefore the latter does not provide services or
impose constraints.

As such, the 'blessed' binding could be refered to as a transport
binding, whilst any others in use (if others are present) are refered
to as 'encapsulation' bindings.

I don't anticipate this terminology being reflected in the message;
rather, it is to clarify the relationships and possibilities of
nesting in our binding definitions. For example, the HTTP binding
could identify itself as a transport-capable binding, and refer to
its payload as either any encapsulation binding, or a raw SOAP
envelope.

At its heart, I see this as a way to contextualize the availability
of services and the imposition of constraints based on the binding
'stack' composition.

Comments? Is this a useful way to characterize bindings? 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 19 July 2001 19:04:17 UTC