WSDL should accommodate a graceful migration of information from
human-oriented documentation to the WSD. Constraints and
capabilities
are one example.
Static specification of constraints and capabilities is more
important to address than dynamic negotiation.
It
is more important to standardize WSDL "compiletime extensions" than
"runtime extensions", so that toolkits can make use of the WSD.
A lot can be done with WSDL's
ability to distinguish between required
and optional
extensions.
The ability to express a disjunction or choice adds a lot of
power, and probably fills the bulk of the
need for specifying constraints and capabilities.
Status of This Document
This document expresses the personal opinions of the author, and has no
official status. Comments are welcome.
As WS tools mature, more information will migrate from
human-oriented application
semantics documentation into machine-processable form, so that tools
can automate
more of the process of realizing requester and provider agents.
Constraints and capabilities are one example. It
would be nice if each example of this migration didn't need to invent
its own language. And it would be nice if it could all be
understood in a common semantic framework.
Expressing policy information statically (in WSDL, for example)
is a different problem from two agents dynamically negotiating a
mutually
agreeable policy. (But static info can be used for dynamic
negotiation.) The static case is more important to address.
It is more important to standardize WSDL "compiletime extensions"
than "runtime extensions" because if compiletime extensions are not
standardized, then toolkits cannot make use of the WSD.
A little can go a long way. A lot can be done with WSDL's
existing extension mechanisms, and the ability to distinguish between
required and optional extensions.
The ability to express a disjunction or choice between alternate
features ("You MUST support either A or B or C") is quite powerful, and
probably fulfills the most pressing
need for specifying constraints and capabilities.
The first two points above are not further explained; the last three
are demonstrated and further explained in solutions #1, #2 and #3 of
the workshop use case below.
Use Cases
I am restricting my attention to use cases in which a provider toolkit
(i.e., the WSDL toolkit that is used to realize the provider agent)
wishes to statically indicate, via the WSD, the particular combinations
of features that are either required
or optional for that Web
service. Examples of such features might include particular
security protocols, compression mechanisms, auditing mechanisms,
reliable messaging protocols, localization features, etc.
A Web
service wishes to stipulate that clients are required support a
reliable messaging protocol, and encrypt a specific header with
WS-Security using a X.509 or user name security token in order to send
an acceptable request message. Furthermore, the service has a P3P
policy associated with its operations. Such constraints and
capabilities might be associated with the Web service via a SOAP header
or a WSDL file.
The requirements for this use case can be summarized as:
The requester agent MUST engage the Acme reliable messaging
protocol. (In this case, I am assuming that the Web service is
stipulating a specific reliable messaging protocol (Acme) that the
requester agent MUST engage. If the intent of this use case was
to permit the requester agent to choose
a reliable messaging protocol from a supported set, then the same
approach as described for security (below) can be used instead.)
The requester agent MUST encrypt a specific header with
WS-Security, using an acceptable security mechanism that we will call a
"class X" security mechanism. (At present, I am assuming that
each acceptable security mechanism indicates which specific header must
be encrypted, i.e., that the choice of header cannot be specified
independently. If, instead, the choice of header needs to be
specified independently, then it can simply be treated as an additional
"MUST" requirement.)
The requester agent MAY use X.509 as a class X WS-Security
mechanism.
The requester agent MAY use user name security token as a class X
WS-Security mechanism.
The Web service has a P3P policy, which the requester agent MAY
use. Explanation: A P3P policy by its
nature is a declaration that is made by the service for the benefit of
the users. The user of the Web service (the "requester
entity") is free to either use or ignore the information, as it sees
fit. Thus, the requester entity's use of the P3P policy is
OPTIONAL: the requester entity MAY
use the P3P information if it desires.
Workshop Use Case
Solution #1
The solution below makes use of the existing extension mechanisms in
WSDL 2.0. WSDL 2.0 offers two extension
mechanisms: Features and Properties (F&P);
and an open content model. Either one can be used to
implement this use case. The solution
below is agnostic about which is chosen.
The approach below relies on the use of both required and optional extensions. A required extension is one that is
marked with
wsdl:required='true'; an optional
extension is one that is
NOT marked with
wsdl:required='true'. The general approach to supporting the
requirements of the given use case is:
An individual "MUST" requirement is expressed as a required extension.
A "MAY" requirement is expressed as an optional extension.
A disjunction that MUST be engaged (such as "A or B MUST be
engaged") is expressed as follows:
The "MUST" requirement of the disjunction itself is expressed
as a required extension; and
Each alternative is expressed as an optional extension.
Each extension is identified by a URI.
Any parameters to an extension are specified either as XML data
nested inside the extension element (if the open content model is used
as the extension mechanism), or as a Property value (if F&P is used
as the extension mechanism).
Here is how this approach can be applied to each of the requirements
from the use case above.
The requester agent MUST engage
a reliable messaging
protocol.
This use case requirement can be expressed using a required WSDL 2.0 extension named http://www.w3.org/2004/06/dbooth-cc/cc.html#Acme_Reliable_Messaging
, which identifies the Acme reliable messaging protocol, as described below. In this
case, the name of the extension itself identifies the
particular reliable messaging protocol that is required, so the
extension does not require any parameters. It is enough just to
specify this extension in the WSD as a required extension.
The requester agent MUST
encrypt a specific header with
WS-Security, using an acceptable security mechanism that we will call a
"class X" security mechanism.
This use case requirement can be expressed using a required WSDL 2.0 extension named http://www.w3.org/2004/06/dbooth-cc/cc.html#Class_X_WS_Security
, which indicates that one of the class X security mechanisms must be
engaged, as described below.
There are a few ways this extension could be defined. In this
example it does not require any parameters. However, Solution #2
describes a variation of this approach in which the
#Class_X_WS_Security extension contains parameters that indicate which
security mechanisms are supported by the Web service.
The requester agent MAY use
X.509 as a class X WS-Security
mechanism.
This use case requirement can be expressed using an optional WSDL 2.0 extension named http://www.w3.org/2004/06/dbooth-cc/cc.html#X_509 ,
which identifies the X.509 security mechanism, as described
below.
The Web service has a P3P
policy, which the requester agent MAY
use.
This use case requirement can be expressed using an optional WSDL 2.0
extension named http://www.w3.org/2004/06/dbooth-cc/cc.html#P3P_Policy
, which is used to indicate the Web service's P3P policy.
The specific P3P policy is specified in a child extension element, or
in an associated F&P Property, depending on which kind of WSDL 2.0
extension is used.
Extension URIs
Here are the URI references for the extensions mentioned above.
Each one defines the meaning of a particular extension. I have
included them here so that they can be dereferenced as real URI
references.
[Note: The current WSDL 2.0 spec says that Features and Properties are
identified by URIs, rather than URI references.
I consider this to be a bug in the spec, and have submitted a Last Call
comment to this effect. In any case, the difference is immaterial
to this approach. Either could have been used.]
This URI
reference is
used to illustrate the use of a WSDL 2.0
extension that is identified by the URI. If the extension is
specified in a WSDL 2.0 document with
wsdl:required='true', then it MUST be engaged by the requester agent;
otherwise, it MAY be
engaged, at the option of the requester agent.
#Class_X_WS_Security
http://www.w3.org/2004/06/dbooth-cc/cc.html#Class_X_WS_Security
In the example above, this URI reference identifies a class X of WS
security
protocols that are considered equivalent for some purpose,
i.e., any one of them is considered to offer adequate security for
the purpose at hand.
If this extension is engaged, then one of the following reliable
messaging protocols MUST be used when the requester agent communicates
with the provider agent:
[Note that the list above includes a security mechanism,
#Security_mechanism_foo_39, that is not supported by the Web service
described in the scenario above. This is to illustrate the fact
that this list may be a standard list used and understood by many Web
services -- not custom-defined for this particular Web service.]
This URI
reference is
used to illustrate the use of a WSDL 2.0
extension that is identified by this URI reference. It should be
specified as a required
extension (i.e., with
wsdl:required='true').
This URI
reference is
used to illustrate the use of a WSDL 2.0
extension that is identified by this URI reference. If the
extension is
specified in a WSDL 2.0 document with
wsdl:required='true', then it MUST be engaged by the requester agent;
otherwise, it MAY be
engaged, at the option of the requester agent.
This URI
reference is
used to illustrate the use of a WSDL 2.0
extension that is identified by this URI reference. If the
extension is
specified in a WSDL 2.0 document with
wsdl:required='true', then it MUST be engaged by the requester agent;
otherwise, it MAY be
engaged, at the option of the requester agent.
#Security_mechanism_foo_39
http://www.w3.org/2004/06/dbooth-cc/cc.html#Security_mechanism_foo_39
In the above example, this URI identifies some security protocol
(foo_39). This is included as an additional example in order to
illustrate the fact that #Class_X_WS_Security may be a standard
list of security mechanisms, which may include mechanisms that are not
supported by the particular Web services in the use case illustrated.
#P3P_Policy
http://www.w3.org/2004/06/dbooth-cc/cc.html#P3P_Policy
In the above example, this URI indicates that the Web service offers a
particular P3P policy. The particular P3P policy is either
contained in body of the XML extension, or as the value of the
associated Property, depending on which kind of extension mechanism is
used. This could also have been done using a WSDL
extension attribute, as described in Handling
Privacy in WSDL 2.0.
Use in SOAP
I'm of the opinion that we should focus on the static use of
constraints and capabilities (i.e., in conjunction with WSDL), and
leave dynamic negotiation to reuse whatever is used in the static
case. In this case, that means transmitting WSDL documents or
portions of WSDL documents.
Interoperability
To evaluate the interoperability potential of the above solution, it's
helpful to distinguish two kinds of WSDL extensions:
A runtime extension is
one
that requires runtime support in the requester and provider
agents.
A compiletime extension is
one that does not require runtime support, i.e., it is only used to
communicate information to the WSDL toolkit that is used to realize a
requester or provider agent.
These lead to two kinds of interoperability:
Agent
interoperability is achieved when the requester agent
supports all runtime extensions that the provider
agent requires in a WSD, and vice versa.
Toolkit interoperability
is achieved when the requester toolkit supports all compiletime
extensions that the provider toolkit requires in a WSD, and vice versa.
The URI for each runtime extension does not necessarily need to be
standardized by a standards
body. If a requester agent does not support a particular runtime
extension that the provider agent requires, then that requester agent
will not be able to use the Web service that the provider agent
realizes. This failure to interoperate is intrinsic, and there
isn't much that can be done about it: the requester agent
either needs to use a different Web service, or it needs to be modified
to support the extensions that the provider agent requires.
On the other hand, the URI for each compiletime extension does need
to be standardized, because compiletime extensions are used to
communicate between one
toolkit and another. If they are not standardized, then both
toolkits may have the intrinsic ability to create interoperable agents,
but without toolkit interoperabiltiy they won't know that they can, so the value of
expressing the information in WSDL is lost.
Pros and Cons of Solution
#1
On the positive side, this approach is very simple, relying on the
existing extension
mechanisms of WSDL 2.0. The only extension that would need to be
standardized would be the #Class_X_WS_Security
extension, in order to achieve toolkit interoperability, because it is
a required compiletime extension. (It is an artifact of the
technique that is used to indicate what other extensions are needed,
rather than being manifested at runtime in the requester and provider
agents themselves.) This approach can also be extended to handle
other kinds of standard classes of features, such as reliable messaging
systems.
On the negative side, this approach is not very flexible, because it
requires each class of features (such as security mechanisms or
reliable messaging mechanisms) to be defined and standardized.
Workshop Use Case
Solution #2
This is a variation of Solution #1, in which the security mechanisms
that are supported by the Web service are indicated as child extension
elements. The following extension would be used instead of
#Class_X_WS_Security.
#Class_X_WS_Security2
http://www.w3.org/2004/06/dbooth-cc/cc.html#Class_X_WS_Security2
This extension is similar to #Class_X_WS_Security, except
that #Class_X_WS_Security2 requires parameters to indicate which
specific security mechanisms are supported by the Web service.
The
parameters are specified as child extension elements. If the open
content model is used to specify this extension, then the child
extension elements indicate which security mechanisms are supported by
the Web service. Otherwise, if F&P are used, then the
associated Property is used to specify the child extension elements.
Pros and Cons of Solution
#2
This solution provides a more logical grouping of the security
protocols that are actually supported by the Web service, because they
are physically grouped into the #Class_X_WS_Security2 extension or
associated Property.
Workshop Use Case
Solution #3
This is a variation of Solution #2, but instead of the
#Class_X_WS_Security2 extension indicating that some security mechanism
is required (and the requester agent may choose which of the supported
mechanisms to use), a #Choose extension generically indicates that the
requester agent may choose one from among several extensions. The
#Choose extension could be defined as follows.
#Choose
http://www.w3.org/2004/06/dbooth-cc/cc.html#Choose
The extension identified by this URI reference
indicates that the requester agent has a choice of extensions that MUST
be supported. The choices are specified as child extension
elements. The #Choose extension indicates that any one of the
choices
will fulfill the need that the Web service is expressing, and the
requester agent may select one at will.
The #Choice extension itself must be specified as a required extension, and each choice
should be specified as an optional
extension. Therefore, the #Choose extension slightly modifies the
WSDL required/optional
semantics of its
child extension elements, because normally an optional extension can be safely
ignored by the requester toolkit. But in the context of a
#Choose, the WSDL processor MUST choose one of them to support.
Pros and Cons of Solution
#3
As with solutions #1 and #2, the #Choose extension is the only
compiletime feature that needs to be standardized to achieve toolkit
interop in this example. However, the #Choose extension is much
more flexible than the #Class_X_WS_Security2 extension of solution #2
or #1, because it is decoupled from the type of extension. (I.e.,
it is not tied to security, or reliable messaging, or whatever.)
This is a substantial advantage, because it means that a single #Choose
extension could be standardized, rather than standardizing various
classes of security extensions, reliable messaging extensions,
etc.
This approach is similar to that used by WS-Policy, although WS-Policy
is more sophisticated. For example, WS-Policy further permits
each choice to be annotated with a numeric preference rating, and
WS-Policy further distinguishes between AtLeastOne semantics and
ExactlyOne semantics.
Conclusions
WSDL should accommodate a graceful migration of information from
human-oriented documentation to the WSD. Constraints and
capabilities are one example.
Static specification of constraints and capabilities is more
important to address than dynamic negotiation.
It
is more important to standardize WSDL "compiletime extensions" than
"runtime extensions", so that toolkits can make use of the WSD.
A lot can be done with WSDL's
ability to distinguish between required
and optional
extensions.
The ability to express a disjunction or choice adds a lot of
power, and probably fills the bulk of the
need for specifying constraints and capabilities.