RE: TBTF: Ed Note Section 5.1 - An attempt to clarify

So I'll throw my 0.2p's worth in (what's that in Euro?)...

[I have move the proposal to the front - I wrote it at the end - and have
then followed with the Rationale that led to the proposed text. This is so
you don't have to wade through the rationale to get to the proposal :-)]

Original text as quoted in Highlands message:

> >The combination of the SOAP extensibility model and the SOAP binding
> >framework provides some flexibility in the way that particular features
can
> >be expressed: they can be expressed entirely within the SOAP envelope (as
> >blocks), outside the envelope (typically in a manner that is specific to
the
> >underlying protocol), or as a combination of such expressions. It is up
to
> >the communicating nodes to decide how best to express particular
features;
> >often when a binding-level implementation for a particular feature is
> >available, utilizing it when appropriate will provide for optimized
> >processing.


Proposal:
---------

"The combination of the SOAP extensibility model and the SOAP binding
framework provide some flexibility in the way that particular features can
be expressed . Features expressed within the SOAP envelope MUST be expressed
in accordance with the relevant SOAP Module specification. Features
expressed outside of the SOAP Envelope (typically in a manner that is
specific to the underlying protocol) MUST be expressed in accordance with
the relevant protocol binding specification. In cases where, for a given
message exchange, a given feature is made available by more than one SOAP
module and/or protocol binding, a SOAP node has complete discretion over
which particular SOAP module or protocol binding it delegates provison of
the given feature for the given message exchange. The particular choice may
be influenced by the combination of features require by the message exchange
and any other local factors, such as application preferences."

Possible addition constraining the behaviour of a protocol binding:

"A SOAP binding is required to convey an XML infoset representing a SOAP
envelope and its contents between peer SOAP nodes without modification. An
instance of a SOAP binding MAY inspect, but nota alter, the XML infosets
being exchange."


Rationale:
----------
I think of four *logical* entities, and I stress logical to emphasis that
this is *not* prescriptive of implementation structure but intended to
enable the structuring of a  description (a specification being a particular
kind of description).

From the top:

	- SOAP Users (or application entities) that makes use of SOAP.

	- SOAP Providers (that provides the services of SOAP to and SOAP
User).

	- SOAP Modules (logically modular extensions to SOAP providers 
	  that extend the functionality made available to SOAP Users).

	- SOAP Bindings (instances) with which provide/expose transport 
	  provided MEPs and feature to SOAP Providers.

The SOAP 1.2 spec. should cover the genric behaviour of SOAP providers, and
the framework for both Modules and Protocol Bindings - thats part 1. Part 2
goes on to provide at least one concrete binding specification based, cast
in terms of properties and features as conceived in the binding framework -
with concrete definintion of one feature... the single-request-response MEP.

So with that as setup... it is my view that both SOAP modules and SOAP
bindings can provide functionality abstracted as features and properties
that are made available to a SOAP provider which inturn can expose those to
SOAP Users.

The specification of a SOAP module should describe (perhaps in
property/feature terms) how the functionality provided by that module
becomes expressed within a SOAP envelope. Parties that support that module
support it in a way that exactly conforms to the relevant module spec. (of
which we perhaps have no good examples).

Likewise the specification of a protocol binding should describe how
instances of that binding uses the underlying protocol to provide the
functionality they claim to support (declared as a list of features that the
binding supports).

So... a binding specification defines how a binding provides features that
the binding supports and an module specification describes how module
provides the features that a module supports.

Now... the question we are facing is about features that may be sourced
either by a binding or by a module.

In my opinion (from a descriptive point-of-view) it is the SOAP provider
which, faced with a number of alternatives to source a given feature, makes
the choice of which features to delegate to the binding and which features
to delegate to a module (and hence the envelope).

The second, perhaps grayer question, is whether a binding can recognise the
elements with the envelope that provide a feature that the binding itself is
capable of supporting and having recognised such elements, remove them from
the envelope and substitute it's own mechanisms for providing the *same*
functionality - after all... who would know? 

My own answer to that question is NO. The SOAP provider has made the choice
of which provider of a feature to use, Module or Binding (indeed possibly
selected between many modules and many bindings that provide overlapping
functionality). Having made that choice, it is not possible for the binding
to know whether the elements it snoops on were introduced by the SOAP
provider or whether they originate from the SOAP User. Basically, I believe
that the role of the binding is to convey an XML Infoset representing the
SOAP enevlope and its contents from one binding peer to another without
altering the content of that infoset (there are unresolved questions about
infoset equivalence concerning the lexical devices such as ns prefixes and
lexical representation of schema datatypes of equivalent value, let alone
issues related to signatures and encryption).

Sorry this has gone on a bit... but I think that the early framing IS
important in articulating my point-of-view. I know that some to not share
the view of a logical separtation between SOAP user and SOAP provider and
would rather see the two as some homogenous lump of SOAP... however, I am
not trying to assert an implementation architecture. Actually, as it turns
out, I have not needed to introduce the distinction into the proposed
text... nevertheless it is how I think of things.

Hope this helps us get closer.

Best regards

Stuart
   
> -----Original Message-----
> From: Marc Hadley [mailto:marc.hadley@sun.com]
> Sent: 23 January 2002 10:43
> To: Mountain, Highland M
> Cc: Christopher Ferris (E-mail); David Fallside (E-mail); Glen Daniels
> (E-mail); Henrik Nielsen (E-mail); Hugo Haas (E-mail); Mark A. Jones
> (E-mail) (E-mail); Noah Mendelsohn (E-mail); Oisin Ohurley (E-mail);
> Stuart' 'Williams (E-mail); Yves Lafon (E-mail); 'www-archive@w3.org'
> Subject: Re: TBTF: Ed Note Section 5.1 - An attempt to clarify
> 
> 
> 
> 
> Mountain, Highland M wrote:
> 
> >All,
> >
> >The statements below are my attempt to reconcile the ongoing conflict
within
> >the TBTF surrounding section Part 1, 5.1.  The statement preserves the
> >modular layered approach while being more specific as to the
responsibility
> >and definition of features expressed as SOAP Headers.
> >
> >
> >Current text:
> >
> >It is up to the communicating nodes to decide how best to express
particular
> >features; often when a binding-level implementation for a particular
feature
> >is available, utilizing it when appropriate will provide for optimized
> >processing.
> >
> >Suggested change (which keeps the spirit of what we initially tried to
state
> >(Glen, Stuart and Henrik's position) but clarifies the balance of
> >responsibility such that readers are not left with a vague notion of
where
> >SOAP Header features should be defined):
> >
> >It is up to the application developer to decide how best to express
> >particular features. If a particular feature is not available at the
> >transport binding-level, or will not be appropriate in the given
end-to-end
> >messaging scenario, it is up to the application developer to capture the
> >requirement for features expressed in the envelope via WSDL or some other
> >construct outside the transport binding specification.  The communicating
> >nodes must then understand the representation and requirements of such
> >features to facilitate interoperability.
> >
> Can we replace "it is up to" with "it is the responsibility of" ? I 
> don't think we should mention WSDL. The text still sounds a little 
> muddled to me, instead how about:
> 
> When a particular feature set is required, it is the responsibility of 
> the application developer to choose a suitable combination of binding 
> and in-the-envelope expressed features. Often when a particular feature 
> is implemented in the binding, utilizing it in preference to an 
> in-the-envelope representation will provide for optimised processing.
> 
> Marc.
> 
> >
> >Are we getting closer to a compromise?
> >
> >Thanks,
> >
> >Highland
> >
> >....................Spec content and ed note of current WD
> >
> >The combination of the SOAP extensibility model and the SOAP binding
> >framework provides some flexibility in the way that particular features
can
> >be expressed: they can be expressed entirely within the SOAP envelope (as
> >blocks), outside the envelope (typically in a manner that is specific to
the
> >underlying protocol), or as a combination of such expressions. It is up
to
> >the communicating nodes to decide how best to express particular
features;
> >often when a binding-level implementation for a particular feature is
> >available, utilizing it when appropriate will provide for optimized
> >processing.
> >
> >
> >
> >Editorial note: HFN	20011201	
> >Some discussion continues on how best to represent the balance of
> >responsibility between binding specifications in particular, vs. other
> >software at the SOAP node, when dealing with features that are
represented
> >entirely within the SOAP envelope. The paragraph above may need some
> >additional work to clarify	
> >
> >
> >Highland Mary Mountain
> >
> >Intel Corporation
> >Distributed Systems Lab (DSL - CTG)
> >(480) 552 - 3817
> >
> >highland.m.mountain@intel.com
> >
> >
> 
>

Received on Wednesday, 23 January 2002 08:18:18 UTC