Re: Capturing Noah's Goal - Framework Description for Nov 5

> Thanks for your feedback.  Please clarify, are you implying that a
Transport
> Binding will only specify features and properties satisfied by the
> underlying protocol?

No - see my third paragraph below (the one starting with "an underlying
protocol"), case (c).

>                       This would imply the need for application-level
> requirement specs covering a message exchange, if that message exchange is
> not satisfied by an underlying protocol?

If the binding (not the underlying protocol, because we can't see the
underlying protocol directly, just the binding) doesn't supply a required
feature, it would have to be satisfied by a module.  There is some question
as to whether you'd call that "application-level", since you could envision
scenarios where the SOAP node decides to activate the module (middleware),
and others where the application (i.e. the thing which engages the SOAP
node) explicitly handles inserting the module's headers itself.

> If so, would you agree that if the underlying protocol did satisfy the
MEP,
> there would be no need for such an application-level requirement
> spec(because the transport binding would cover it)?

This is correct IF the MEP in question is exposed as a feature by the
binding.  For instance, we could imagine an HTTP binding which said nothing
about the inherent request-response nature of HTTP and how it maps to the
SOAP-level request-response MEP.  If that were the case, then according to
our framework there would be no guidance which the SOAP engine writer could
use to conclusively determine that a "response" per a SOAP req-resp MEP is
contained within the HTTP response and therefore no correlation module needs
to engage.  So not only must the underlying protocol support a given MEP,
but it must be described as such in the spec.

> This would imply that the "application-level requirement bar" and the
> "binding-level requirement bar" are dynamic and determined by the native
> feature set of the transport protocol.  Correct?  If so, then the merging
of
> your last sentence with my suggested text does not fit:

It is certainly true that the feature sets of various underlying protocols,
the bindings which utilize them, and the available modules will be varied.

Perhaps part of the problem here may be that we keep trying to limit the
scope of what we're doing to be JUST the bindings, whereas I think in
reality it's a bit larger than that.  Part of what I think we're doing is
laying some usable structure on top of the idea that different parts of a
SOAP node (modules, bindings) may be used to satisfy requirements in a given
message exchange.  Some of what is interesting about that involves the
writers of different specifications (modules and bindings) being able to
describe the functionality of those pieces in such a way that we can
conclusively say that yes, module A provides the SAME
semantics/functionality as binding B with respect to a particular feature.

> > Any binding specification has a set of messaging requirements.  Some of
> these requirements could be satisfied by the underlying protocol's native
> feature set.  Other requirements may need to be provided outside of the
> underlying protocol. The requirements not provided natively by the
> underlying protocol of choice will need to be expressed in the resulting
> binding specification <here is where the problem is, where do such
> requirements belong>.  These requirements will be expressed as features
and
> associated properties.  SOAP nodes will have to determine which resident
> modules satisfy the features outside the scope of the selected binding in
> order to be compliant with the application-level requirements for the
> message exchange.
>
> Thoughts?
>
> Highland
>
> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: Friday, November 02, 2001 4:23 PM
> To: Mountain, Highland M; David Fallside (E-mail)
> Cc: 'Oisin Hurley'; 'Hugo Haas'; Chris.Ferris@sun.com;
> marc.hadley@sun.com; 'Mark Nottingham'; 'Noah Mendelsohn';
> ylafon@w3.org; 'Mark A. Jones (E-mail)'; www-archive@w3.org; Stuart'
> 'Williams (E-mail); Henrik Nielsen (E-mail)
> Subject: Re: Capturing Noah's Goal - Framework Description for Nov 5
>
>
>
> Hm.
>
> The last sentence, as written, I don't think I agree with.  It seems to
> imply that modules can be used to satisfy binding-level requirements,
which
> I don't believe is really the right way to look at it.  Let me try first
to
> make a general statement about the framework, and then to rephrase some of
> what the original paragraph says in a way that I hope may help.
>
> The binding framework does two things for us - first, it allows binding
> authors to specify the features their binding provides in a way that
allows
> the authors of other specifications (bindings or modules) to provide those
> same features.   Second, by virtue of the fact that both bindings and
> modules can use the same specification language to talk about Features, we
> enable the software at a SOAP node to be written such that it can make
> decisions about which modules (and perhaps bindings) to engage for a
> particular message exchange based on an abstract set of desired
> Features/Properties.
>
> An underlying protocol will have a certain set of semantics and
behaviours.
> The author of a binding utilizing a particular protocol will have the
option
> to a) completely ignore any underlying protocol semantics (i.e. the
binding
> is "opaque"; the underlying protocol still has all its behaviour, but the
> SOAP node doesn't know about any of it), b) express some or all of the
> semantics provided by the underlying protocol as Features/Propertes, thus
> enabling the larger SOAP environment to see and make decisions based on
> these, or c) specify semantics which go BEYOND those of the underlying
> protocol, and perhaps expose some of those semantics as
Features/Properties.
> An example of the latter would be a binding that implements
request-response
> over UDP in a particular fashion, or a binding that uses the MIME
> specification to describe its data packaging over a bytestream underlying
> protocol.
>
> In other words, a binding is a black box to the SOAP node.  The only
> connection points we have to the black box are the Features and Properties
> which are exposed in the binding specification, and we have no way of
> knowing which of those Features are directly supported/supplied by the
> underlying protocol, and which are part of the binding specification.
This
> is as it should be.
>
> The end result of all this is that the only connection between the modules
> and the bindings is that they both expose particular Features/Properties
in
> their specifications.  So the last sentence below is almost right, except
> that I would say it's "SOAP nodes will have to determine which resident
> modules satisfy the features outside the scope of the selected binding in
> order to be compliant with the application-level requirements for the
> message exchange".
>
> Hope this made some sense.
>
> --Glen
>
> > Any binding specification has a set of messaging requirements.  Some of
> > these requirements could be satisfied by the underlying protocol's
native
> > feature set.  Other requirements may need to be provided outside of the
> > underlying protocol. The requirements not provided natively by the
> > underlying protocol of choice will need to be expressed in the resulting
> > binding specification.  These requirements will be expressed as features
> and
> > associated properties.  SOAP nodes will have to determine which resident
> > modules satisfy the features outside the scope of the underlying
protocol,
> > in order to be compliant with a given binding specification.
> >
> > The last statement is where we need to arrive at a common understanding.
> >
> >
> > Talk to you Monday.
> >
> > Highland
> >
> >
>

Received on Monday, 5 November 2001 08:34:32 UTC