This specification, Web Services Policy 1.5 - Attachment, defines two general-purpose mechanisms for associating policies, as defined in Web Services Policy 1.5 - Framework, with the subjects to which they apply. This specification also defines how these general-purpose mechanisms may be used to associate policies with WSDL and UDDI descriptions.
This is an updated Public Working Draft of the Web Services Policy 1.5 - Attachment specification for review
by W3C members and other interested parties. It has been produced by
the
Discussion of this document takes place on the public
This document was produced by a group operating under the
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Last Modified: $Date: 2006/09/26 13:16:10 $
The Web Services Policy 1.5 - Framework [
To enable Web Services Policy to be used with existing Web
service technologies, this specification describes the use of
these general-purpose mechanisms with WSDL [
This section specifies the notations, namespaces, and terminology used in this specification.
This specification uses the following syntax within normative outlines:
The syntax appears as an XML instance, but values in
Characters are appended to elements and attributes to indicate cardinality:
"?" (0 or 1) "*" (0 or more) "+" (1 or more)
The character "|" is used to indicate a choice between alternatives.
The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
This document relies on the XML Information Set [
XML namespace prefixes (see
The ellipses characters "…" are used to indicate a point of extensibility that allows other Element or Attribute Information Items.
Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this syntax:
An element extensibility point is referred to using {any} in place of the element name. This indicates that any element name can be used, from any namespace other than the http://www.w3.org/2006/07/ws-policy namespace.
An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace. namespace.
Normative text within this specification takes precedence over
normative outlines, which in turn take precedence over the XML Schema
[
This specification uses a number of namespace prefixes throughout; they are
listed in
Prefix | XML Namespace | Specification |
---|---|---|
rmp |
http://docs.oasis-open.org/ws-rx/wsrmp/200602 |
[ |
sp |
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy |
[ |
wsa |
http://www.w3.org/2005/08/addressing |
[ |
wsdl11 |
http://schemas.xmlsoap.org/wsdl/ |
[ |
wsdl20 |
http://www.w3.org/2006/01/wsdl |
[ |
wsoap12 |
http://schemas.xmlsoap.org/wsdl/soap12/ |
[ |
wsp |
http://www.w3.org/2006/07/ws-policy |
This specification |
wsse |
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd |
[ |
wsu |
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd |
[ |
xs |
http://www.w3.org/2001/XMLSchema |
[ |
All information items defined by this specification
are identified by the XML namespace URI [
In this document reference is made to the
It is the intent of the W3C Web Services Policy Working Group that the Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment XML namespace URI will not change arbitrarily with each subsequent revision of the corresponding XML Schema documents but rather change only when a subsequent revision, published as a WD, CR or PR draft results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification.
Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new XML namespace URI:
Addition of new global element, attribute, complexType and simpleType definitions.
Addition of new elements or attributes in locations covered by a previously specified wildcard.
Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid.
Modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule.
The keywords "
We introduce the following terms that are used throughout this document:
the
The
a
A
A
A
A
A
A
A
This specification defines several mechanisms for
associating policies (Web Services Policy 1.5 - Framework, [
The example in
The document containing both of these policy expressions is
assumed to be located at
http://www.example.com/policies
. Per Section
http://www.example.com/policies#RmPolicy
and
http://www.example.com/policies#X509EndpointPolicy
,
for the examples in
This section defines two general-purpose mechanisms for
associating
In addition it defines the processing rules for scenarios where multiple policies are attached to a policy subject.
When multiple attachments are made,
This combination can be achieved by:
Such calculated policy expressions have no meaningful IRI of their own.
This section defines two general-purpose mechanisms for
associating policies [
It is often desirable to associate policies with the XML
elements describing a subject; this allows description formats
such as WSDL to be easily used with the Web Services Policy
Framework (see Section
The precise
semantics of how element policy is to be processed once
discovered is domain-specific; however, implementations are
likely to follow the precedent specified in the section below
on WSDL [
This specification defines a global attribute that allows
The namespace URI [http://www.w3.org/2006/07/ws-policy
.
The
Note that the
An example of
If the
have been processed and
Note that this
The presence of the
Alternatively, rather than using the global attribute, XML elements
may use the
This mechanism allows
This element has three components: the
Domain expressions identify the domain of the association. That is,
the set of
For the purposes of attaching
The following is the pseudo-schema for the
The following describes the attributes and elements listed in the pseudo-schema outlined above:
This describes an external
This required element's children describe the
These child elements
This element is a
This element references a
This optional element allows security information such as
signatures to be included. The syntax of this element is described in
WS-Security [
Additional attributes
Other child elements for binding constructs
Domain expressions are used to identify entities such as endpoints, messages or resources with which a policy can be associated. For example, domain expressions may be used to refer to WSDL 1.1 definitions, WSDL 2.0 components, endpoint references, etc.
The following example illustrates the use of this mechanism with an
EndpointReference domain expression for a deployed endpoint as defined
in Web Services Addressing [
In this example, the http://www.example.com/policies#RmPolicy
applies to all
interactions with the endpoint at
http://www.example.com/acct
.
The
WSDL 1.1 disallows the use of extensibility elements on certain
elements and the use of extensibility attributes on others. However,
the WS-I Basic Profile 1.1 [
If it is necessary to include the actual
To ensure that consumers of policy-annotated WSDL elements are
capable of processing such @wsdl11:required="true"
attribute).
The rest of this section defines how to interpret the
When attaching a
Figure 1 represents how the
For abstract WSDL definitions, the
Policies that are attached to a deployed resource (e.g., services
or ports) are only considered in the
(This graphic is also available in SVG format
When attaching policies at different levels of the WSDL hierarchy, care must be taken.
A message exchange with an endpoint
For example, in
It is
For any given port, the
The rest of this section describes these
The following WSDL 1.1 element is considered as the service policy subject:
This element
A policy associated with a service policy subject applies to any message exchange using any of the endpoints offered by that service.
The following WSDL 1.1 elements collectively describe an endpoint:
These elements
Since the
Policies associated with an endpoint policy subject apply to any message exchange made using that endpoint.
The
The following WSDL 1.1 elements collectively describe an operation:
These elements
The
Since the
Policies associated with an operation policy subject apply to the message exchange described by that operation.
The
The following WSDL 1.1 elements are used to describe messages:
These elements
The
Policies associated with a message policy subject apply to that message (i.e. input, output or fault message).
The
For example, the
Since a
Since
Care should be taken when attaching policies to outbound messages
as the result may not be what is expected. For example, expressing a
choice on a service's outbound message without a mechanism for a
requester of that service to communicate its choice to the service
before the outbound message is sent may not result in the desired
behaviours. It is therefore
As an example of the combination of these
For endpoints bound to StockQuoteSoapBinding
, the GetLastTradePrice
operation, an additional
message-level
This section defines a mechanism for associating policies with
There are essentially two approaches for registering policies in
UDDI. One approach is to directly reference remotely accessible
When attaching a
Each
For UDDI tModels that represent Web service types, the
Policies that apply to deployed Web services (bindingTemplates) are
only considered in the
Each of these entities
The following UDDI element is considered as the service provider policy subject:
This element
Policy attached to the service provider policy subject applies to behaviors or aspects of the service provider as a whole, irrespective of interactions over any particular service. This includes — but is not limited to — acting as a service consumer or a service provider in general.
The following UDDI element is considered as the service policy subject:
This element
Policy attached to the service policy subject applies to behaviors or aspects of the service as a whole, irrespective of interactions over any particular endpoint. This includes — but is not limited to — acting as a consumer or a provider of the service.
The following UDDI elements collectively describe an endpoint:
These elements
An endpoint policy subject applies to behaviours associated with an entire endpoint of the service, irrespective of any message exchange made. This includes — but is not limited to — aspects of communicating with or instantiating the endpoint.
The
UDDI tModels provide a generic mechanism for associating arbitrary
metadata with services and other entities in a UDDI registry. To
properly integrate Web Services Policy into the UDDI model, Web Services Policy 1.5 - Attachment
pre-defines one tModel that is used to associate a remotely accessible
This new tModel is called the remote policy reference category
system and is defined in Appendix
UDDI registries uuid:a27078e4-fd38-320a-806f-6749e84f8005
to uniquely identify this
tModel so that UDDI registry users can expect the same behavior across
different UDDI registries.
The tModel's valid values are those IRIs that identify external
Using the remote policy reference category system, one can then
associate a http://www.example.com/myservice/policy
with a
The
A different approach has to be taken to associate a
The
In addition to using the approach outlined in the section above,
publishers may register a specific
The following illustrates a tModel for the http://www.example.com/myservice/policy
.
The first "policy"
, which is its single valid value. This is necessary
in order to enable UDDI inquiries for
Note that the
Web Services Policy 1.5 - Attachment pre-defines another tModel that is used to
associate such a pre-registered, locally available
This new tModel is called the local policy reference category
system and is defined in Appendix
UDDI registries uuid:a27f7d45-ec90-31f7-a655-efe91433527c
to uniquely identify this
tModel so that UDDI registry users can expect the same behavior across
different UDDI registries.
The local policy reference category system is based on tModelKeys. The valid values of this category system are those tModelKeys identifying tModels that
exist in the same UDDI registry
and are categorized as "policy"
using the Web Services Policy Types category system.
That is, when referencing this category system in a category bag,
the corresponding
Given the local policy reference category system, one can then
associate a "uuid:04cfa…"
from above with a
The
A different approach has to be taken to associate a
The tModelKey of the
UDDI Version 3 [
First, the tModelKeys of the pre-defined tModels are migrated to domain-based keys. The migration is unique since the Version 2 keys introduced in this specification are already programmatically derived from the Version 3 keys given below.
The "uuid:a27078e4-fd38-320a-806f-6749e84f8005"
to
"uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
.
The "uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993"
to "uddi:schemas.xmlsoap.org:policytypes:2003_03"
.
The "uuid:a27f7d45-ec90-31f7-a655-efe91433527c"
to "uddi:schemas.xmlsoap.org:localpolicyreference:2003_03"
.
Second, rather than putting
Third, inquiries for reusable http://www.example.com/
, the following find_tModel
API call can
be used:
Fourth, all UDDI entities may be digitally signed using XML digital
signatures [
It is
Policies
This section contains the UDDI tModel definitions for the canonical
tModels used in Section
This tModel is used to attach a
Name: | |
---|---|
Description: | Category system used for UDDI entities to point to an external Web services policy attachment policy that describes their characteristics. See Web Services Policy 1.5 - Attachment specification for further details. |
UDDI Key (V3): | uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03 |
UDDI V1,V2 format key: | uuid:a27078e4-fd38-320a-806f-6749e84f8005 |
Categorization: | categorization |
Checked: | No |
This tModel is used to categorize tModels as representing "policy"
, that
indicates this very fact. It is
Name: | |
---|---|
Description: | Web services policy types category system used for UDDI tModels to
characterize them as Web services policy–based |
UDDI Key (V3): | uddi:schemas.xmlsoap.org:policytypes:2003_03 |
UDDI V1,V2 format key: | uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993 |
Categorization: | categorization |
Checked: | No |
This tModel is used to attach a
Name: | |
---|---|
Description: | Category system used for UDDI entities to point to a Web services
policy |
UDDI Key (V3): | uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03 |
UDDI V1,V2 format key: | uuid:a27f7d45-ec90-31f7-a655-efe91433527c |
Categorization: | categorization |
Checked: | Yes |
This document is the work of the
Members of the Working Group are (at the time of writing, and by alphabetical order): Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
The people who have contributed to
A list of substantive changes since the Working Draft dated 31 July 2006 is below:
Added an empty conformance section.
Replaced URI with IRI.
Date | Author | Description |
---|---|---|
20060712 | ASV | Updated the list of editors. Completed action items
|
20060712 | DBO | Completed action item |
20060718 | DBO | Completed action items
Editors to remove extraneous namespace decl in the example at the end of section 3.4 |
20060719 | TIB | Completed action item |
20060721 | ASV | Completed action items
|
20060721 | ASV | Completed action item
|
20060726 | ASV | Incorporated the
|
20060808 | DBO | Completed action items: |
20060808 | ASV | Implemented the
|
20060809 | DBO | Implemented the
|
20060809 | ASV | Implemented the
|
20060811 | DBO | Completed action items: |
20060813 | ASV | Added a new Section |
20060825 | PY | Implemented the
|
20060827 | TIB | Completed action item:
|
20060827 | TIB | Implemented the
|
20060829 | ASV | Implemented the
|
200609006 | DBO | Completed partial resolution for issue
|
20060906 | ASV | Implemented the
|