Re: A slice at a proposal for SOAP features/properties in WSDL

This is a rather belated response to Glen's proposal and Jean-Jacques
followup.  Rather than offering solutions for issues, I want to try to
highlight some of the issues that we've encountered.

A good deal of the material that follows is based on a set of proposals
for an alternative email binding that illustrates the implementation of
pub/sub semantics via the SOAP 1.2 extensibility mechanism.  That
material is wending its way toward a wider audience, and I think its
content is likely to be of interest to those discussing
feature/MEP/protocol description in WSDL, but I am drawing on it largely
as a "lessons learned" pool.

First things first.  SOAP 1.2 defines three extensibility hooks:
features, message exchange patterns, and protocol bindings.  From
creating proposals for one or more of each, here's a description of what
is contained.

A feature, in SOAP 1.2, defines a set of abstract properties.  My
impression is that almost every feature will define such properties. 
The properties are not bound to any storage location (because the
properties, like the features, are abstract).  A feature may *also*
change a message structurally (examples are the web method and MIME,
both of which end up making the message look very different).  This is
an important issue, because it relates to the question of whether
features are inlined/imported in WSDL, or only referenced.  Because it's
easy to do so, most feature specifications will probably contain an
example of the feature implemented as a module (and therefore
establishing one possible storage location for these properties).

A MEP *may* contain properties, but in my experience, it's rare. 
Instead, it will require features (which supply the properties) because
its requirements are shared with other MEPs.  The primary characteristic
of a MEP is that it defines the pattern of message exchange.  A MEP
specification also defines a state machine which describes how those
properties are manipulated (for instance, how a destination address
property is created from available properties in a triggering message,
such as a reply address property and a sender address property). 
Importantly, a MEP still does not define the storage location of the
properties.

A protocol binding, once features and MEPs are defined and described in
separate specifications, is little more than a list of required and
optional features, required and optional MEPs, and recommendations (or
lists of choices) of how the properties may be stored.  For instance, it
may recommend that properties defined by a message addressing feature be
bound to certain protocol headers.  In a few cases, the protocol binding
may mandate the storage location of certain properties (for the example
email binding, this is true of the MIME content feature's properties,
which must be bound to the corresponding MIME/protocol headers).

This leaves the precise location of the storage location of required
(and of optional) properties up to the service description, in most
cases.  So one of the tasks of a WSDL describing a service which employs
the extensibility mechanism of SOAP 1.2 is to define a syntax for doing
so.  That is what I take to be the major task of a proposal addressing
feature/MEP/protocol binding descriptions.  As a bonus, it would be nice
if the proposal could handle equivalent features/MEPs/protocol bindings
that describe other service models than SOAP.

Working backward, then, it seems clear that in order to support WSDL
description of a protocol binding, one needs a separate specification of
the protocol binding for WSDL (that is, the example SOAP 1.2 email
binding example doesn't supply sufficient information to decide on a
syntax for WSDL; a separate email binding WSDL extension specification
is also needed).  That specification might, for instance, describe how
one can bind a property to: a) a protocol header, b) a collection of
protocol headers (there's a need for this in the email binding), c) a
SOAP header, d) protocol meta-information (target address and port, for
instance, when those are not carried within the application packet but
must be extracted from the TCP and IP envelopes), or e) something else. 
Although this binding *might* occur in a portType, it seems more obvious
to place it inside the <binding> element at least, because a single WSDL
might describe multiple services, which might need multiple bindings of
the same property to different protocols.

It isn't clear, though, whether the WSDL protocol binding extension
specification ought to be *in WSDL* or *in XML* at all.  If it were
described so, then it could be included or imported in the WSDL (a
protocol binding definition, with an internal link from the services and
bindings using it).  The primary use of doing this is to allow a WSDL to
be fully descriptive.  One imagines a WSDL processor that is somehow
able to support an additional protocol binding simply by reading the
WSDL protocol binding description.  This seems unlikely (it seems more
likely that each processor would have a certain set of known, supported
protocol bindings in advance), so the specification need only specify
what the property bindings look like, but need not define the protocol
binding itself in XML.

(I hope that's clear.  The question is whether there ought to be a
<protocol url="standard-url"><feature required="true"
url="standard-url"> ... in the WSDL, or whether a binding need only say
<wsdl:protocol url="standard-url" /> inside <binding> or <service> to
indicate the bound protocol--the difference between full description via
import/include, and reference to known entities that may not be
described anywhere in XML form).

Back down the stack to the MEP specification.  It would be nice if a MEP
were identifiable from an attribute, rather than by examining the order
of messages which it contains and matching an internal set of known
exchange patterns.  The result is ultimately the same, though.  The same
sorts of issues arise: in order to support pluggable MEPs, one would
need to provide the import/include mechanism.  To support a set of known
MEPs, one merely needs to provide an unambiguous URI reference.  It is
not likely that a processor could be built that could recognize "new"
MEPs embedded in the WSDL, even given a <MEP><feature
/><pattern><message /></pattern></MEP> sort of construct.  A part of
what the MEP specification provides is the state machine, which is to
say, the manipulation of the associated properties that participate in
the exchange (rather than the data private to the particular
operation).  So again, it seems that perhaps it is more appropriate to
make reference to MEPs, not incorporate an MEP definition into WSDL.  In
the case of MEPs, there may not even be a need for the reference, since
each MEP is defined by its exchange pattern.  Certainly, in current
WSDL, we do not actually identify things.  Different properties might be
available (or required) to be bound, depending upon the MEP, but it is
at least possible that a "MEP reference" is simply a set of input,
output, in particular order.

And once we return to features (the simplest), we find that the
properties, if required by a protocol binding or MEP, should already
have their storage locations defined, as part of the protocol binding
extension specification.  Apart from bindings to SOAP headers, it does
not seem terribly feasible to define bindings (storage locations) for
properties independent of the protocol binding.  This implies, further,
that the abstract properties exposed by a feature cannot be bound except
in the context of a particular protocol binding (which, after all, will
expose certain storage-identification constructs for its own required
features ... and those may be enough to provide support for additional
features).  The story, though, seems to end up the same: it is hard to
imagine a processor supporting a feature simply by examining its
description (<feature uri="standard-uri"><property name="blah"
type="type" required="bool" /></feature>), especially when a feature
(such as web method) significantly changes the content and structure of
one or more messages.  Therefore, one posits that additional features
may be required (or optional) for a particular operation, but that they
need only be referenced by standard URI, and can only be bound in the
context of a defined protocol binding.

I hope that made adequate sense.  If not, please ask for clarification. 
*laugh*  Despite the length, a part of the possible lack of cogency
arises from an attempt to be terse (it's not my strongest virtue; you
may have noticed that, by this time ...).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 22 October 2002 12:43:27 UTC