This paper will focus on the similarities and differences between two technologies: Features and Properties, developed by the W3C Web Services activity, and WS-Policy, developed by an independent set of companies including Microsoft and IBM.
The Features and Properties architecture was originated during
the SOAP 1.2 work within the W3C. It was clear that the SOAP
extensibility model allows almost unlimited flexibility in terms of
what can be accomplished using SOAP headers, and also clear that
some of the same semantics which can be implemented with headers
are natively available in particular protocol bindings. For
instance, a "request-response" message exchange pattern (MEP) could
be implemented by using one-way transports and a
"<reply-to>" SOAP header, and it could also be
suppported natively by using HTTP's built-in response framing to
carry the SOAP response. We introduced the term "Feature" to refer
to these arbitrary semantics, and noted that a given abstract
Feature (such as "reliability" or "request-response") might be
implemented by either a binding or an extension using SOAP headers
(a SOAP module). In order to allow description of the
individual pieces of data involved in the operation of a Feature,
we also introduced a technique of using properties, typed
data named with URIs, to allow precise references to these bits of
data. Note that some properties are user-settable (such as the
desired QoS on a "reliability" feature), and some are not (such as
the time of day in a "timeout" feature).
The WSDL group integrated Features and properties into WSDL 2.0 first in order to support the SOAP-specific concepts, and then further expanded the architecture in order to allow Features to be more abstract.
An example problem solved by WSDL integration of F&P was that SOAP module specifications can and do sometimes contain very complex or difficult-to-codify rules which determine which headers are actually sent in a given message. A simple exmple would be a module that involved several different headers depending on some context, such as the time of day or the state of an ongoing conversation. Once it became possible to indicate support of a SOAP module by module URI, we could then simply require (or announce support for) the entire module by name, rather than the more limited WSDL-1.1-style vocabulary which only allowed requiring individual headers.
WS-Policy was originally written by Microsoft, IBM, and SAP and first published in 2002. It provides a framework and a syntax for expressing the capabilities and requirements of entities in a Web service world. WS-Policy allows associating policies with design time artifacts like WSDL documents as well as with messages on the wire during runtime.
The policy specs are separated into the framework, which defines the general syntax for expressing policy, and PolicyAttachments, which defines how to actually put policy assertions into WSDL, UDDI, and SOAP contexts. Assertions are combined using simple <all> and <exactlyOnce> operators which essentially give us logical AND and XOR.
With the assumption that several other papers will delve fairly deeply into WS-Policy, we will leave our description brief and spend the rest of the paper on comparing the technologies, an example using F&P, and our thoughts on the future.
In many ways, Features and WS-Policy serve to accomplish a similar purpose - machine-readable metadata to describe extension semantics and their configuration data. Much of the difference between the two, at least for their usage in WSDL descriptions, is simply syntax. Each contains the central idea of tags (either URIs or QNames) representing pieces of semantic metadata - "do this optional thing", "use this runtime value in your work", etc. A few of the salient differences follow:
In the next section, we'll cover using Features and Properties in order to implement the use case in the workshop call for papers with WSDL 2.0. Under the assumption that other authors will present the scenario using WS-Policy, we will not do so here. Afterwards, we'll draw a few conclusions and make some recommendations for the future.
To accommodate the scenario, we wil posit that a SOAP module is defined by "sampleco.com" which wraps the current WS-Security specification (note - since WS-Security as provided by OASIS does contain a SOAP 1.2 binding, we strongly believe the authors should have followed the SOAP extensibility framework as described in the Recommendation, and themselves given WS-Security a module URI. However, this example does serve to point out that even specs that do not precisely follow the SOAP 1.2 extensiblity model can easily be described by others as modules with properties). The module URI is "http://sampleco.com/WSSecurity". We will not define the whole module here, but we assume it exposes these two properties:
We also posit that an abstract reliability Feature has been defined, again by sampleco. This Feature defines reliable messaging in terms of the results, and leaves it to particular technologies (such as WS-ReliableMessaging or perhaps an MQ protocol binding) to bind the semantic into a particular form. The abstract Feature exposes several settable properties which affect the behavior of any concrete instantation of the Feature.
A schema such as this is declared in the WSDL for our service:
<schema targetNamespace="http://services.org/">
<simpleType name="tokenConstraint">
<restriction base="string">
<enumeration value="X509"/>
<enumeration value="userName"/>
</restriction>
</simpleType>
</schema>
This type definition will allow us to constrain the value space of the "token" property in the security Feature, achieving the "X.509 or user name security token" requirement of the example.
Our WSDL 2.0 service element might then look like this:
<service name="myService">
<-- A specific SOAP module -->
<soap:module uri="http://sampleco.com/WSSecurity" required="true"/>
<property uri="http://sampleco.com/WSSecurity/token"
xmlns:svc="http://services.org/">
<constraint qname="svc:tokenConstraint"/>
</property>
<property uri="http://sampleco.com/WSSecurity/xpath">
<value>{xpath to header}</value>
</property>
<-- A required abstract Feature, which must be implemented by some module
or binding -->
<Feature uri="http://sampleco.com/reliability" required="true"/>
<property uri="http://sampleco.com/reliability/qos">
<value>EXACTLY-ONCE</value>
</property>
<-- Using WSDL extensibility -->
<p3p:policyLocation xmlns:p3p="http://sampleco.com/p3p/">
{url to P3P policy document}
</p3p:policyLocation>
</service>
Note that the generic syntax, though certainly comprehensible, can also be condensed by defining "syntactic sugar", WSDL extensions whose definitions themselves indicate how to set appropriate Properties. An example is given as the last element above - the author of a P3P Feature has defined an extensibility element which contains a URL value and whose function is to set a Property in an (assumed) P3P Feature.
It's fairly easy to map URIs such as those used for Features and properties into XML infosets, and vice versa. Therefore, it should be relatively short work to use either Policy or F&P syntax, and to write guidelines describing how to map assertions in one vocabulary into the other.
The real meat of Features and properties is the idea that specification writers should design their extensions according to the SOAP 1.2 extensibility model. We believe this model also easily backports to SOAP 1.1/WSDL 1.1, since it's really just about how you give things names. We believe that characterizing parts of the Web services stack as abstract Features, SOAP modules, and bindings is a highly valuable mechanism for managing extensibility and composability. We also believe this is in no way incompatible with WS-Policy, and would like to see the W3C eventually recommend both a) best practices for spec writers and b) a single interoperable syntax for expressing capabilities and requirements.
Despite the enormity of the general problem of machine-assisted agreements, we believe that a good 80/20 solution exists, and that the W3C is the correct venue in which to standardize such a solution for Web services. Such a solution should take into account, during its development, the potential interactions with (and lessons from) related technologies, including in particular the Semantic Web; and should represent the best parts of both WS-Policy and the F&P framework.