Re: TBTF: nesting

Mark,

I see things somewhat similarly, but there are still problems with
characterizing the lowest level binding as the only one that
provides services or imposes constraints. For instance, I
think that it would be difficult to characterize a binding
to HTTPR [1] because technically, it is a nested binding
of http->httpr->httpr-payload-message->?

Also, consider the case of HTTP/SSL. Techically, HTTP is bound to
SSL yet both provide services. (actually, one could argue that
the full stack would be HTTP/SSL/TCP/IP each of these provides
some level of service;-)

In my proposal, I suggest that an 'encapsulation'
binding (mechanism is the term I've used) is identified by its
MIME media type. In the HTTP binding case, the Content-Type header
identifies the encapsulation binding, with the default binding being
none or as you cite, the raw binding which is expressed as the
MIME media type designated for a SOAP envelope, or text/xml.

I also provide for an encapsulation negotiation mechanism using
the Accept request header which provides for the client to
express to the server the encapsulation bindings it is capable
of supporting.

Thus, an encapsulation binding for SOAP Messages with Attachments
would be expressed by its media type expression:

	Content-Type: multipart/related; type="text/xml"; 
	start="cid:..."; boundary="..."

and a DIME encapsulation binding as:

	Content-Type: application/dime; type="text/xml"

<aside mode="rant">
Of course, I would REALLY like to see a formally declared/defined/registered
media type for a SOAP envelope (such as application/soap+xml) as this
would allow for a more precise representation. e.g.

	Content-Type: multipart/related; type="application/soap+xml"

there's no doubt as to the representation that this is a multipart/related
encapsulation binding for a SOAP envelope with attachments.

Regardless of the arguments that the media type alone is inadequate to express
the details of the namespaces used in the SOAP envelope... It *is*,
above all else, a SOAP envelope which has its own processing semantics above 
any semantics carried within in the namespace qualified blocks. It isn't just
any XML document and it certainly isn't text in the sense that a SOAP envelope
constitutes text that is meant to be read by an end user. 
</aside>

Note that both multipart/related and application/dime encapsulations
are also providing services as they provide for the ability to
add attachments to the message.

I will admit that my proposed approach also runs into difficulties when you
consider that an encapsulation such as multipart/related could easily
have multiple interpretations or binding definitions (e.g. I can conceive 
of a case where something other than a SOAP envelope was the "start" body 
part such as a nested encapsulation or some other entity with the SOAP envelope
represented elsewhere in the multipart/related entity).

Cheers,

Chris

[1] http://www-106.ibm.com/developerworks/webservices/library/ws-phtt/

Mark Nottingham wrote:
> 
> 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 20:31:12 UTC