Re: TBTF: A small Doodle of an HTTP Binding

Henrik,

Please see my comments below.

Cheers,

Chris

Henrik Frystyk Nielsen wrote:
> 
> Noah,
> 
> Thank you for clarifying your model although it has left me quite
> concerned about the scope of our current enterprise. A few comments
> follow:
> 
> * In your definition of "module" you mention that "(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.)".

I think I concur with this. However, I also think that the authors
of these modules are also responsible for defining the binding
characteristics or requirements of their module, possibly even
developing their own unique binding.

> 
> Unless I am missing something I can't see how this can be true - we do
> not in general have the same mechanisms available for describing
> features *outside* the SOAP envelope as we do *inside* the envelope. For
> example:
> 
> 1) we can't rely on a consistent naming model (in SOAP we have qnames of
> the header entry)
> 
> 2) we can't rely on any processing enforcement (in SOAP we have the
> mustUnderstand attribute)
> 
> 3) we can't rely on support for intermediaries (in SOAP we have the
> actor attribute)
> 
> * I don't think we need the separation between binding specifications
> and binding implementations. Given that we shied away from providing any
> distinction between a SOAP "module" and a SOAP "handler" in the SOAP
> spec terminology, I would encourage us not to attempt doing this within
> the binding framework and rather focus on the implementation independent
> aspects. For the purpose of defining a framework, where would we ever
> want to differentiate between a binding running on Unix or Windows?
> 
> * You state that "Feature interface specifications:  for each core
> feature of SOAP, and for each module, there is an interface
> specification." but I am not sure where the notion of an interface comes
> from in this context nor how it relates to our notion of blocks and SOAP
> extensions.
> 
> Given the current structure of SOAP, I think a more natural separation
> of issues is the following
> 
> A) Features defined *within* the envelope follow the normal SOAP
> processing rules and are generally referred to SOAP extensions or blocks
> 
> B) Features defined *below* the envelope may follow any processing rules
> defined by the environment in which the features are defined. Features
> are generally defined as "properties" and the environment is generally
> defined as a "binding". Bindings may refer to properties in other
> bindings and say that they support them in various ways and bindings may
> be nested with other bindings in order to compose composite bindings.
> 
> In this model (which I described in some detail in [3]) there is no
> notion of interfaces, implementations, or platform specific details. It
> allows one to make bindings that are completely abstract and for other
> bindings to refer to these abstract properties and it allows for
> properties to be propagated through nested bindings.

I think that the abstraction can be carried too far. The "properties"
you describe in [3] are what I would call "characteristics". They
serve a useful purpose in the description, for an application author
to use in selecting an appropriate binding, but they aren't the same
manner of properties that Stuart has suggested in [2] and that I 
believe Noah, Glenn and I (and I am sure others as well:) are
contemplating.

> 
> This leaves us with a model that simply consists of bindings and
> properties - whether you want to have abstract bindings with abstract
> properties or very concrete bindings with concrete properties is
> completely up to the author of the binding.

I disagree. IMO, a "binding" MUST describe precisely and unambiguously
the representation of the "message" on the wire within the constraints of
the bound protocol's specification such that two independent
implementations can be developed such that they can exchange
messages interoperably. A "message" consists of the SOAP envelope
and its contents as well as any "properties" that may not be directly
represented within the SOAP envelope.

> 
> One of the nice properties of this model is that bindings can be
> composed freely. For example, I can define a DIME binding for dealing
> with binary attachments in the following manner:
> 
> * If I know about the SOAP attachment binding, I may want to reuse the
> attachment property defined by that binding as it may cover what I need.

Yes!

> If not then I can define my own property that abstractly talks about
> what it means to have an attachment. I could even define a binding with
> only the abstract notion of an "attachment" and have the DIME use that
> property in its binding.

Agreed.

> 
> * I can use the DIME binding directly over TCP which gives me a binding
> with one set of properties

characteristics, not properties

> 
> * I can use DIME over HTTP which gives me another binding with another
> set of properties

again, I think that you mean characteristics here, not properties. However,
there may of course be a separate set of protocol specific properties
that the binding requires.

> 
> * I can use DIME over SMTP which gives me yet another binding with some
> third set of properties

Again, the way I see it is that the bindings you describe have potentially
different "natural" characteristics that they offer the application.
An HTTP binding provides a "natural" synchronous request/response MEP.
Unless the binding is used in some manner that is incongruous with
the natural nature of the protocol binding, then no explicit MEP
"properties" are needed to be specified by the application.

One could say that the HTTP binding provides by default a set of
properties in the output "infoset" of the binding.  The input "infoset" 
is augmented set of implicit properties including "request-or-response-message" 
and "correlation-id". 

An SMTP binding has a natural characteristc of a one-way asynchronous
message. If used for purposes of exchanging messages with a request/response
MEP, some external properties MUST be defined and represented in the binding
including "request-or-response-message" and "correlation-id". One binding
might use the SOAP extension mechanism to define a module that carries
this information within the SOAP envelope, using the SOAP semantics. Another
might choose to leverage the 822 headers in some creative manner. However,
these are two distinct bindings. The fact that they are both using SMTP is
mere coincidence. The author of the secondary binding may leverage
much from the other SMTP binding for one-way messages. It may be possible
to leverage the first binding entirely and layer something on top that
effects the necessary exchange of MEP related "properties".

> 
> Are there any cases where this is not sufficient?
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
> 
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0139.html
> 
> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> Sent: Friday, August 17, 2001 07:09
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: Re: TBTF: A small Doodle of an HTTP Binding
> 
> 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.
> 
> 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-bin
> ding_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 Tuesday, 21 August 2001 11:37:37 UTC