Re: TBTF: A small Doodle of an HTTP Binding

+1

Some comments below.

Cheers,

Chris

Noah_Mendelsohn@lotus.com wrote:
> 
> I like the general direction signaled by the combination of Mountain's original summary of our
> small group meeting [1] and Stuart's model for the HTTP binding [2].  I would change some of the
> structure and formalism a bit (see below), but reading between the lines I think we are on the
> right track.  Here are a few specific suggestions (that are also a very partial response to
> Henrik's note [3].  Henrik's note deserves a more careful response, which I will try to get to
> before the call.)
> 
> Let me clarify how I would suggest we use certain terminology, at least for purposes of this
> e-mail thread (we can fine-tune the terminology as we write the actual specification):
> 
> Module:  a specification for an optional function not included in the core SOAP specification.
>  Examples include security of various sorts, transactions, but also conceivably facilities that
> make sense only on one or another particular transport (e.g. there might be an extension to let
> you choose GET vs. POST or REQUEST for HTTP...that wouldn't make much sense on MQ).   (Note:  I am
> intentionally not distinguishing modules which are specified in terms of a fixed set of "headers"
> vs. those that might have other properties outside the envelope...in my view, the same tools and
> abstractions (such as the ability to define properties) are available to those who write
> specifications for modules as we have in defining core SOAP features.)
> 
> Binding specifications vs. binding implementations:  I believe we can all agree to distinguish the
> two.   An HTTP binding specifications says: "here is how we will represent a one-hop request on
> the wire using HTTP".  A particular binding implementation is a piece of code which one can, in
> principle, test for conformance with that specification.  So, there might be an implementation for
> Windows and another for UNIX. I will try to use the two terms carefully below.
> 
> Feature interface specifications:  for each core feature of SOAP, and for each module, there is an
> interface specification.  The specification consists of the set of named properties used to model
> data, and a set of rules that implement the logic of the feature.  These rules can provide for
> checking and update of data found in the properties, for constructing and transmitting SOAP
> messages from data found in the properties, or for updating properties based on information
> received from a SOAP message.

I also think that the binding specification should identify computed or derived
properties. e.g it may augmnent or change the set of properties that it takes as
input in the output set of properties.

> 
> Properties:  Properties model the data used to specify a SOAP core feature or module.
> 
> Note: I have a concern with Henrik's suggestion that "A binding [binding specification?...NRM] may
> define a set of properties." [4]  In my opinion, the properties are defined by our specification
> (for core functions) and by the specifications for various modules (e.g. security) and message
> patterns.  This is a very fundamental distinction.  Particular binding specifications undertake to
> meet the contract(s) implied by the core and module specifications.   In other words, they agree
> to support those sets of properties along with the logic mandated for their use.   Reason:  the
> whole point of our framework is to show how multiple binding specifications can be developed to
> meet the same interface.  For example, we hope that both HTTP and MQ bindings can achieve
> request/response semantics that are similar enough that the applications can view the two
> transparently.  It is the common set of data at th! e input and output interfaces that are modeled
> as properties.  Therefore, the set of properties and the required logic associated with them are a
> contract which each binding specification (and thus each implementation of such specification)
> must implement.
> 
> Now, to be fair, it is perfectly reasonable to have individual extensions/modules which are
> binding-specification specific.  For example, if we decided to let the application have direct
> control over the SOAPAction http header, there would be nothing wrong with introducing a
> particular binding-specific property:
> 
>         httpbinding.SOAPAction="...."
> 
> I think it would be a big mistake to conclude that, in general, properties are defined by binding
> specifications.  I think it is a special case of the rule that "properties are (the data part of)
> the interface specification for core SOAP functions and extensions (modules?  what's our temr
> 
> Binding specifications and binding implementations: I like the start that Stewart has made [2],
> but I have a suggestion for making it more rigorous.  I think we need to split those aspects of
> the specification that are common across binding specifications, from those that are
> HTTP-specific.  So, there should be a specification for request/response in general that says
> something along the lines of:  "There is a property called 'mep.isRequestorResponse".  If the
> message to be sent is marked "Response" then the binding specification must...{rules go here for
> what the binding must do in sending a response.  Presumably this would include rules along the
> lines of:  'attempt to deliver the response envelope to the SOAP note that sent the original
> request'}"
> 
> With that as a base, the HTTP binding specification in particular can say:  when HTTP REQUEST
> messages are received, the connection back to the requester must be kept open.  This specification
> meets the need for addressing responses by sending them over that open connection.  (An MQ
> implementation might do this differently, but the application would see a common service.)
> 
> Thus, each part of the specification is layered into a contract definition that comes from either
> core SOAP or the module, and a means of implementing that contract provided in each binding
> specification.
> 
> I have written this in some haste in the hopes that at least one or two readers may get to it
> before the call.  Also, as some of you know, I do use speech recognition software when writing
> long notes.  That tends to result in particularly laughable "typos" which I try to catch with
> careful proofreading .  When I am rushing as I am now, mistakes tend to get through.  Apologies in
> advance if I have missed any.
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0093.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0157.html (earlier W3C member-only
> copy at http://lists.w3.org/Archives/Member/w3c-archive/2001Aug/0063.html)
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0139.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/att-0139/01-binding_framework.htm
> 
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------

Received on Friday, 17 August 2001 11:22:43 UTC