This document is also available in these non-normative formats: PDF, PostScript, XML, and plain text.
Copyright © 2006 © 2007 W3C®
(MIT, ERCIM,
Keio), All Rights Reserved.
W3C liability,
trademark
and document
use rules apply.
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 section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This isW3C publishes a
Last CallCandidate Recommendation to indicate that the document is
believed to be stable and to encourage implementation by the
developer community. The Web Services Policy Working
DraftGroup expects to request that the Director advance this
document to Proposed Recommendation once the Working Group has
demonstrated 4 or more interoperable implementations with the
exception of the following: WSDL2.0 attachment, external policy attachment and
UDDI attachment, which
shall require 2 or more implementations. The Working Group does not
plan to request to advance to Proposed Recommendation prior to 30
June 2007.
No features have been identified as "features
at risk" by the Web Services Policy 1.5 - Attachment specification.Working Group. The Last Call period ends 12 January 2007.Working
Group will maintain an implementation
report.
This Working Draft was produced by the members of the Web Services Policy Working Group, which is part of the W3C Web Services Activity. The Working Group expects to advance this Working Draft to Recommendation Status.
A list of changes in this version
of the document and a diff-marked version
against the previous version of this document are available.
Major changes in this version of the document encompass the
additionclarification of a newthe relationship between URI domain expression and
WSDL 1.1 Element Identifiers in sectionSection 3.4.1 URI Domain
Expression and the definition of equivalence of two {policy} properties in section 5.3 Extension to WSDL Component Model.
The Working Group is tracking all comments via Bugzilla and highly prefers to receive comments via this system. If access to Bugzilla is not feasible, you may send your comments to the mailing list public-ws-policy-comments@w3.org mailing list (public archive). Each Bugzilla entry and email message should contain only one comment. All comments on this specification should be made following the Description for Issues of the Working Group.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working DraftCandidate Recommendation 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.
1. Introduction
2. Notations and
Terminology
2.1 Notational Conventions
2.2 XML
Namespaces
2.3 Terminology
2.4 Example
3. Policy Attachment
3.1 Effective
Policy
3.2 Policy Attachment
Mechanisms
3.3 XML
Element Attachment
3.4 External Policy Attachment
3.4.1 URI Domain Expression
3.5 Use of
IRIs in Policy Attachment
4. Attaching Policies Using
WSDL 1.1
4.1 Calculating Effective
Policy in WSDL 1.1
4.1.1 Service Policy Subject
4.1.2 Endpoint Policy Subject
4.1.3 Operation Policy Subject
4.1.4 Message Policy Subject
4.1.5 Example
5. WS-Policy Attachment
for WSDL 2.0
5.1 Example
5.2 Attaching Policy
Expressions
5.3 Extension to WSDL Component
Model
5.4 Effective
Policy
5.4.1 Service Policy Subject
5.4.2 Endpoint Policy Subject
5.4.3 Operation Policy Subject
5.4.4 Message Policy Subject (input
message)
5.4.5 Message Policy Subject (output
message)
5.4.6 Message Policy Subject (input
fault message)
5.4.7 Message Policy Subject
(output fault message)
6. Attaching Policies Using
UDDI
6.1 Calculating
Effective Policy and Element Policy in UDDI
6.1.1 Service Provider Policy
Subject
6.1.2 Service Policy Subject
6.1.3 Endpoint Policy Subject
6.2 Referencing Remote Policy
Expressions
6.3 Registering Reusable Policy
Expressions
6.4 Registering Policies in UDDI
Version 3
7. Security
Considerations
8. Conformance
8.1 External Policy
Attachment Conformance
8.2 WSDL 1.1 Attachment
Conformance
8.3 WSDL 2.0 Attachment
Conformance
A. References
A.1 Normative References
A.2 Other
References
B. UDDI tModel Definitions
B.1 Remote Policy Reference
Category System
B.1.1 Design Goals
B.1.2 tModel Definition
B.1.3 tModel Structure
B.2 Web Services Policy Types Category
System
B.2.1 Design Goals
B.2.2 tModel Definition
B.2.3 tModel Structure
B.3 Local Policy Reference
Category System
B.3.1 Design Goals
B.3.2 tModel Definition
B.3.3 tModel Structure
C. Acknowledgements
(Non-Normative)
D. Changes in this Version of the
Document (Non-Normative)
E. Web Services Policy 1.5 - Attachment
Change Log (Non-Normative)
The Web Services Policy 1.5 - Framework [Web Services Policy Framework] specification defines an abstract model and an XML-based language for expressing policies of entities in a Web services-based system. This specification, Web Services Policy 1.5 - Attachment, defines two general-purpose mechanisms for associating policies with the subjects to which they apply; the policies may be defined as part of existing metadata about the subject or the policies may be defined independently and associated through an external binding to the subject.
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 [WSDL 1.1, WSDL 2.0 Core Language] definitions and UDDI [UDDI API 2.0, UDDI Data Structure 2.0, UDDI 3.0].
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 italics indicate data types instead of literal values.
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 Information Set]. Information items properties are indicated by the style [infoset property].
XML namespace prefixes (see Table 2-1) are used to indicate the namespace of the element or attribute being defined.
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-policyhttp://www.w3.org/ns/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 [XML Schema Structures] descriptions.
This specification uses a number of namespace prefixes throughout; they are listed in Table 2-1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML Namespaces]).
Prefix | XML Namespace | Specification |
---|---|---|
mtom |
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization |
[WS-MTOMPolicy] |
rmp |
http://docs.oasis-open.org/ws-rx/wsrmp/200602 |
[WS-RM Policy] |
sp |
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy |
[WS-SecurityPolicy] |
wsa |
http://www.w3.org/2005/08/addressing |
[WS-Addressing Core] |
wsap |
http://www.w3.org/2006/05/addressing/wsdl |
[WS-Addressing Policy] |
wsdl11 |
http://schemas.xmlsoap.org/wsdl/ |
[WSDL 1.1] |
wsdl20 |
http://www.w3.org/2006/01/wsdl |
[WSDL 2.0 Core Language] |
wsoap12 |
http://schemas.xmlsoap.org/wsdl/soap12/ |
[WSDL 1.1 Binding for SOAP 1.2] |
(none), wsp |
|
This specification |
wsse |
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd |
[WS-Security 2004] |
wsu |
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd |
[WS-Security 2004] |
xs |
http://www.w3.org/2001/XMLSchema |
[XML Schema Structures] |
All information items defined by this specification are
identified by the XML namespace URI [XML
Namespaces] http://www.w3.org/2006/07/ws-policy.http://www.w3.org/ns/ws-policy. A normative XML Schema
[XML Schema Structures,
XML Schema Datatypes]
document can be obtained indirectly by dereferencing the XMLnamespace
document at the WS-Policy 1.5 namespace URI.
In this document reference is made to the wsu:Id
attribute in a utility schema (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd).
The wsu:Id
attribute was added to the utility schema
with the intent that other specifications requiring such an Id
could reference it (as is done here).
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 whenas the specifications transition through Candidate
Recommendation, Proposed Recommendation and Recommendation status.
However, should the specifications revert to Working Draft status,
and 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, the namespace
URI will be changed accordingly.
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 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [IETF RFC 2119].
We introduce the following terms that are used throughout this document:
theThe effective policy, for a given policy subject, is the combination of
relevant policies. The relevant policies are those attached to
policy scopes that contain the
policy subject.
The element policy is the policy attached to the policy subjects associated with the element information item that contains it.
An ignorable policy assertion is an assertion that may be ignored for policy intersection (as defined in 4.5 Policy Intersection).
aA merge consists of serializing each policy as a
policy expression,
replacing their wsp:Policy
element with a
wsp:All
element, and placing each as children of a
wrapper wsp:Policy
element.
A policy is a potentially empty collection of policy alternatives.
A policy alternative is a potentially empty collection of policy assertions.
A policy assertion represents an individuala
requirement, a capability, or other property of a behavior.
A policy attachment is a mechanism for associating policy with one or more policy scopes.
A policy expression is an XML Infoset representation of a policy, either in a normal form or in an equivalent compact form.
A policy scope is a collection of policy subjects to which a policy may apply.
A policy subject is an entity (e.g., an endpoint, message, resource, operation) with which a policy can be associated.
This specification defines several mechanisms for associating policies (Web Services Policy 1.5 - Framework, [Web Services Policy Framework]) with various XML Web service entities. For brevity, we define two sample policy expressions that the remainder of this document references.
Example 2-1 indicates a policy for reliable messaging [WS-RM Policy]. Example 2-2 is a policy for securing messages using X509 certificates [WS-SecurityPolicy].
Example 2-1. Example RM Policy Expression.
(01) <wsp:Policy xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602"xmlns:wsp="http://www.w3.org/2006/07/ws-policy"xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="RmPolicy" > (02) <rmp:RMAssertion> (03) <rmp:InactivityTimeout Milliseconds="600000" /> (04) <rmp:BaseRetransmissionInterval Milliseconds="3000" /> (05) <rmp:ExponentialBackoff /> (06) <rmp:AcknowledgementInterval Milliseconds="200" /> (07) </rmp:RMAssertion> (08) </wsp:Policy>
Example 2-2. Example X509 Security Policy Expression.
(01) <wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"xmlns:wsp="http://www.w3.org/2006/07/ws-policy"xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="X509EndpointPolicy" > (02) <sp:AsymmetricBinding> (03) <wsp:Policy> (04) <sp:RecipientToken> (05) <wsp:Policy> (06) <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never"> (07) <wsp:Policy> (08) <sp:WssX509V3Token10 /> (09) </wsp:Policy> (10) </sp:X509Token> (11) </wsp:Policy> (12) </sp:RecipientToken> (13) <sp:InitiatorToken> (14) <wsp:Policy> (15) <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient" > (16) <wsp:Policy> (17) <sp:WssX509V3Token10 /> (18) </wsp:Policy> (19) </sp:X509Token> (20) </wsp:Policy> (21) </sp:InitiatorToken> (22) <sp:AlgorithmSuite> (23) <wsp:Policy> (24) <sp:Basic256Rsa15 /> (25) </wsp:Policy> (26) </sp:AlgorithmSuite> (27) <sp:Layout> (28) <wsp:Policy> (29) <sp:Lax /> (30) </wsp:Policy> (31) </sp:Layout> (32) <sp:IncludeTimestamp /> (33) <sp:OnlySignEntireHeadersAndBody /> (34) </wsp:Policy> (35) </sp:AsymmetricBinding> (36) </wsp:Policy>
The document containing both of these policy expressions is
assumed to be located at
http://www.example.com/policies
. Per Section
3.2 Policy Identification of Web Services Policy 1.5 -
Framework [Web Services Policy
Framework], the IRIs used for these policy expressions in the remainder of
this document are
http://www.example.com/policies#RmPolicy
and
http://www.example.com/policies#X509EndpointPolicy
,
for the examples in Example 2-1 and Example 2-2, respectively.
This section defines two general-purpose mechanisms for associating policies with one or more policy subjects. The first allows XML-based descriptions of resources (represented as XML elements) to associate policy as part of their intrinsic definition. The second allows policies to be associated with arbitrary policy subjects independently from their definition.
In addition it defines the processing rules for scenarios where multiple policies are attached to a policy subject.
Policies will often be associated with a particular policy subject using multiple policy attachments. For example, there may be attachments at different points in a WSDL description that apply to one policy subject, and other attachments may be made by UDDI and other mechanisms.
When multiple attachments are made, their relevent policies can
be combined. [Definition: theThe effective
policy, for a given policy
subject, is the combination of relevant policies. The relevant
policies are those attached to policy scopes that contain the policy subject.]
This combination can be achieved by:through a merge. [Definition: aA merge
consists of serializing each policy as a policy expression, replacing their
wsp:Policy
element with a wsp:All
element, and placing each as children of a wrapper
wsp:Policy
element.] The resulting policy expression
is considered to represent the combined policy of all of the
attachments to that policy subject.
Such calculated policy expressions have no meaningful IRI of their own.
This section defines two general-purpose mechanisms for associating policies [Web Services Policy Framework] with one or more policy subjects. The first allows XML-based descriptions of resources to associate policy as part of their intrinsic definition. The second allows policies to be associated with arbitrary policy subjects independently from their definition.
The policy scope of an attachment is specific to the policy attachment Mechanism using it. Accordingly, any policy attachment mechanism MUST define the policy scope of the attachment.
It is often desirable to associate policies with Web services policy subjects represented as XML elements (i.e., WSDL 1.1 elements - Section 4. Attaching Policies Using WSDL 1.1 for the specific details of WSDL attachment).
Since policy assertions are strongly typed by the authors, 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 [WSDL 1.1] and Policy.
This specification defines a global attribute that allows
policy expressions to be
attached to an arbitrary XML element. The following is the schema
definition for the wsp:PolicyURIs
attribute:
(01) <xs:schema> (02) <xs:attribute name="PolicyURIs"> (03) <xs:simpleType> (04) <xs:list itemType="xs:anyURI" /> (05) </xs:simpleType> (06) </xs:attribute> (07) </xs:schema>
The namespace URI [XML
Namespaces] for this attribute is
.http://www.w3.org/2006/07/ws-policyhttp://www.w3.org/ns/ws-policy
The wsp:PolicyURIs
attribute contains a white
space-separated list of one or more IRIs [IETF RFC 3987]. When this attribute is used,
each of the values identifies a policy expression as defined by
[Web Services Policy
Framework]. If more than one IRI is specified, the
individual referenced policies need
to be merged together to form a
single element policy
expression. The resultant policy
is then associated with the element information item's element policy
property. [Definition: The element policy is the
policy attached to the policy subjects associated with the
element information item that contains it.]
Note that the policy scopeAn example of element policy through the attachment is specific to the policy attachment Mechanism using it; accordingly, any policy attachment mechanism using this attribute MUST define the policy scope of the attachment. An example of element policy through the use of this global attributeuse of this global
attribute is given below using the sample policies stated in
Section 2.4 Example.
If the policies referenced by the following XML element
(01) <MyElement wsp:PolicyURIs=" (02) http://www.example.com/policies#RmPolicy (03) http://www.example.com/policies#X509EndpointPolicy" />
have been processed and merged, it would result in an element policy whose XML 1.0 representation is listed in Example 3-1:
Example 3-1. Example Merged Policy Expression.
(01) <wsp:Policy xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"xmlns:wsp="http://www.w3.org/2006/07/ws-policy"xmlns:wsp="http://www.w3.org/ns/ws-policy" > (02)<rmp:RMAssertion><wsp:All> (03) <rmp:RMAssertion> (04) <rmp:InactivityTimeout Milliseconds="600000" />(04)(05) <rmp:BaseRetransmissionInterval Milliseconds="3000" />(05)(06) <rmp:ExponentialBackoff />(06)(07) <rmp:AcknowledgementInterval Milliseconds="200" />(07) </rmp:RMAssertion>(08)<sp:AsymmetricBinding></rmp:RMAssertion> (09)<wsp:Policy></wsp:All> (10) <wsp:All> (11) <sp:AsymmetricBinding> (12) <wsp:Policy> (13) <!-- Details omitted for readability -->(11)(14) <sp:IncludeTimestamp />(12)(15) <sp:OnlySignEntireHeadersAndBody />(13)(16) </wsp:Policy>(14)(17) </sp:AsymmetricBinding>(15)(18) </wsp:All> (19) </wsp:Policy>
Note that this element policy has no meaningful IRI.
The presence of the wsp:PolicyURIs
attribute does
not prohibit implementations from using additional mechanisms for
associating policy
expressions with XML-based constructs.
Alternatively, rather than using the global attribute, XML
elements MAY use the
wsp:Policy
or wsp:PolicyReference
elements directly as children, in order to support element policy (Per
Section
4.3.4 Policy References of Web Services Policy 1.5 - Framework
[Web Services Policy
Framework]), and the semantics for this are the same as
for the use of the global attribute. For example, an alternative
way of attaching the policies in the above example, using child
elements, would be as follows:
(01) <MyElement> (02) <wsp:PolicyReference (03) URI="http://www.example.com/policies#RmPolicy" /> (04) <wsp:PolicyReference (05) URI="http://www.example.com/policies#X509EndpointPolicy" /> (06) <MyElement/>
This mechanism allows policies to
be associated with a policy
subject independent of that subject's definition and/or
representation through the use of a
wsp:PolicyAttachment
element.
This element has three components: the policy scope of the attachment, the policy expressions being bound, and optional security information. The policy scope of the attachment is defined using one or more extensible domain expressions that identify policy subjects, typically using IRIs.
Domain expressions identify the domain of the association. That is, the set of policy subjects that will be considered for inclusion in the scope using an extensible domain expression model. Domain expressions identify policy subjects to be included within the policy scope. Domain expressions yield an unordered set of policy subjects for consideration.
For the purposes of attaching policy to a policy
subject through this mechanism, any policy expression contained inside of the
wsp:AppliesTo
element MUST
NOT be considered in scope. For example, an Endpoint
Reference may be used as a domain expression, and it may contain
policy expressions within
it, but this policy
expressions are not considered in scope with respect to the
wsp:PolicyAttachment
element using it.
The following is the pseudo-schema for the
wsp:PolicyAttachment
element:
(01) <wsp:PolicyAttachment … > (02) <wsp:AppliesTo> (03) <x:DomainExpression/> + (04) </wsp:AppliesTo> (05) ( <wsp:Policy>…</wsp:Policy> | (06) <wsp:PolicyReference>…</wsp:PolicyReference> ) + (07) <wsse:Security>…</wsse:Security> ? (08) … (09) </wsp:PolicyAttachment>
The following describes the attributes and elements listed in the pseudo-schema outlined above:
/wsp:PolicyAttachment
This describes an external policy attachment.
/wsp:PolicyAttachment/wsp:AppliesTo
This required element's children describe the policy scope.
/wsp:PolicyAttachment/wsp:AppliesTo/{any}
These child elements MUST specify and/or refine the domain expression(s) that define the policy scope. They MUST NOT contradict the semantics of their root element; if an element is not recognized, it SHOULD be ignored. Domain expressions are XML elements that describe policy subjects within a policy scope. When more than one domain expression is present, the policy scope contains the union of the policy subjects identified by each expression.
/wsp:PolicyAttachment/wsp:Policy
This element is a policy expression representing a policy that is attached to the policy subjects within the policy scope.
/wsp:PolicyAttachment/wsp:PolicyReference
This element references a policy expression to be attached to the policy subjects that are in the policy scope. Refer to Web Services Policy 1.5 - Framework [Web Services Policy Framework] for additional details.
/wsp:PolicyAttachment/wsse:Security
This element is of type
and allows
security information such as signatures to be included. The syntax
of this element is described in WS-Security [WS-Security 2004].xs:booleanwsse:Security
/wsp:PolicyAttachment/@{any}
Additional attributes MAY be specified but MUST NOT contradict the semantics of the [owner element]; if an attribute is not recognized, it SHOULD be ignored.
/wsp:PolicyAttachment/{any}
Other child elements for binding constructs MAY be specified but MUST NOT contradict the semantics of the parent element; if an element is not recognized, it SHOULD be ignored.
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 [WS-Addressing Core]:
(01) <wsp:PolicyAttachment> (02) <wsp:AppliesTo> (03) <wsa:EndpointReference> (04) <wsa:Address>http://www.example.com/acct</wsa:Address> (05) </wsa:EndpointReference> (06) </wsp:AppliesTo> (07) <wsp:PolicyReference (08) URI="http://www.example.com/policies#RmPolicy" /> (09) </wsp:PolicyAttachment>
In this example, the policy expression at
http://www.example.com/policies#RmPolicy
applies to
all interactions with the endpoint at
http://www.example.com/acct
.
This section defines a domain expression for identifying resources as policy subjects for the external attachment mechanism. The following is a pseudo-schema for the URI domain expression:
(01) <wsp:PolicyAttachment … > (02) <wsp:AppliesTo> (03) <wsp:URI … >xs:anyURI</wsp:URI> * (04) </wsp:AppliesTo> (05) … (06) </wsp:PolicyAttachment>
The following describes the URI domain expression element listed in the pseudo-schema outlined above:
/wsp:PolicyAttachment/wsp:AppliesTo/wsp:URI
This element is an absoluteIRI that references a resource as a policy subject. There is no
requirement that the IRI be resolvable; retrieval mechanisms are
beyond the scope of this specification.
/wsp:PolicyReference/wsp:AppliesTo/wsp:URI/@{any}
Additional attributes MAY be specified but MUST NOT contradict the semantics of the [owner element]; if an attribute is not recognized, it SHOULD be ignored.
URI domain expressions are used to identify resources that are identified using IRI or IRI References (such as endpoint, message or operation definitions) with which policies can be associated. For example, URI domain expressions can be used to identify WSDL 1.1 definitions, WSDL 2.0 components, etc. When a URI domain expression identifies multiple resources, i.e. WSDL 1.1 supports multiple operations with the same name (sometimes called operation name overloading), the Policy applies to all the resources that are identified.
IRI References for WSDL 2.0 components are defined in Appendix C of the Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language]. The following example illustrates the use of URI domain expression with a WSDL 2.0 IRI Reference:
(01) <wsp:PolicyAttachment> (02) <wsp:AppliesTo> (03) <wsp:URI>http://example.org/TicketAgent.wsdl20#wsdl.endpoint(TicketAgentService/Endpoint)</wsp:URI> (04) </wsp:AppliesTo> (05) <wsp:PolicyReference URI="http://www.example.com/policies#RmPolicy" /> (06) </wsp:PolicyAttachment>
In this example, the policy expression at
http://www.example.com/policies#RmPolicy
applies to
all interactions with the endpoint at
http://example.org/TicketAgent.wsdl20#wsdl.endpoint(TicketAgentService/Endpoint)
.
Similarly, an XPointer [ XPointer Framework ] can be used as anIRI Reference to identify a descriptionReferences for WSDL 1.1 elements are defined in aWSDL 1.1
Element Identifiers [WSDL11
ElementIds].
The scope of URI domain expressions for WSDL 2.0 components or WSDL 1.1 elements is limited to the subjects defined in Section 5. WS-Policy Attachment for WSDL 2.0 and 4. Attaching Policies Using WSDL 1.1.
Policy attachment mechanisms use IRIs for some identifiers. This
document does not define a base URI but relies on the mechanisms
defined in XML Base [XML BASE]
document.and RFCs 3023 [IETF RFC 3023],
3986 [IETF RFC 3986] and 3987
[IETF RFC 3987] for
establishing a base URI against which relative IRIs can be made
absolute.
This section describes a mechanism for associating policy
expressions with Web service constructs in WSDL 1.1 [WSDL 1.1]. The RECOMMENDED meansmechanism consists of:
A model for attaching policies to WSDL 1.1 constructs. The model defines:
A partitioning of associatingWSDL constructs into service, endpoint,
operation and message policy subjects.
The semantics of attaching a policy to each policy subject
How to combine policies attached to more than one WSDL construct
within a single policy with asubject.
An XML representation of policy subject that has a WSDL 1.1 [expressions attached to WSDL 1.1
] description is to attach a reference to theconstructs.
The annotation of such policy within the WSDL component corresponding toexpressions as required extensions
using the target policy subjectWSDL-defined extensibility flag
@wsdl:required
.
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 [BP
1.1] overrules this restriction and allows element
extensibility everywhere. Therefore, when attaching a reference
directly to the WSDL element the policy reference SHOULD be
attached using wsp:PolicyReference
as child element
unless it is absolutely necessary to maintain the original WSDL 1.1
restriction, in which case the @wsp:PolicyURIs
attribute MAY be used for the following WSDL elements:
wsdl11:portType
wsdl11:portType/wsdl11:operation/wsdl11:input
wsdl11:portType/wsdl11:operation/wsdl11:output
wsdl11:portType/wsdl11:operation/wsdl11:fault
If it is necessary to include the actual policy expressions within the WSDL
description itself, it is RECOMMENDED
that their wsp:Policy
elements be included as children
of the wsdl11:definition
element, and referenced using
the mechanisms just described. Alternatively, the policy expressions MAY be made available through some other means,
such as WS-MetadataExchange [WS-MetadataExchange].
To ensure that consumers of policy-annotated WSDL elements are
capable of processing such policy attachments, attachments using
wsp:PolicyReference
SHOULD be marked as a mandatory extension (e.g.,
with a @wsdl11:required="true"
attribute).
The rest of this section defines how to interpret the policy attachments when they appear within a WSDL description.
Policy attachments in WSDL 1.1 can be used to associate policies with four different types of policy subject, identified as the service policy subject, the endpoint policy subject, the operation policy subject, and the message policy subject. These policy subjects should be considered as nested, due to the hierarchical nature of WSDL.
When attaching a policy to a WSDL element, a policy scope is implied for that attachment. The policy scope only contains the policy subject associated with that element and not those associated with the children of that element. Therefore, it is RECOMMENDED that each policy assertion contained within a WSDL element's element policy should have the correct semantic such that the policy subject for that assertion is that WSDL element. For example, assertions that describe behaviours regarding the manipulation of messages should only be contained within policies attached to WSDL message elements.
Figure 1 represents how the effective policies, with regard to WSDL, are calculated for each of these policy subjects. In the diagram, the dashed boxes represent policy scopes implied by WSDL elements. For a particular policy subject, the effective policy MUST merge the element policy of each element with a policy scope that contains the policy subject.
For abstract WSDL definitions, the element policy is considered an intrinsic part of the definition and applies to all uses of that definition. In particular, it MUST be merged into the effective policy of every implementation of that abstract WSDL definition.
Policies that are attached to a deployed resource (e.g., services or ports) are only considered in the effective policy of that deployed resource itself.
(This graphic is also available in SVG format here.)
When attaching policies at different levels of the WSDL hierarchy, care must be taken. A message exchange with an endpoint MAY be described by the effective policies in all four subject types simultaneously.
For example, in Figure 4-1, for a particular input message to a deployed endpoint, there are four policy subjects involved, each with their own effective policy. There is an effective policy for the message, as well as an effective policy for the parent operation of that message, an effective policy for the deployed endpoint, and the effective policy for the service as a whole. All four effective policies are applicable in relation to that specific input message.
It is RECOMMENDED that, where specific policy assertions associated with one policy subject are only compatible with specific policy assertions on another policy subject in the same hierarchical chain, the policies containing these assertions should be attached within a single WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject type SHOULD be compatible with each of the policy alternatives at each of the policy subjects parent and child policy subjects, such that choices between policy alternatives at each level are independent of each other.
The rest of this section describes these policy subject types, and how the effective policy for each policy subject is calculated.
The following WSDL 1.1 element is considered as the service policy subject:
wsdl11:service
This element MAY have element policy as per Section 3. Policy Attachment, and if present MUST be merged into the effective policy of the WSDL service policy subject.
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:
wsdl11:port
wsdl11:portType
wsdl11:binding
These elements MAY have element policy as per Section 3. Policy Attachment. The policy scope implied by each of these elements contains the endpoint policy subject representing the deployed endpoint.
Since the wsdl11:portType
may be used by more than
one binding, it is RECOMMENDED that
only policies containing abstract (i.e., binding independent)
assertions should be attached to this type of element.
Policies associated with an endpoint policy subject apply to any message exchange made using that endpoint.
The effective policy for a WSDL endpoint policy
subject includes the element policy of the
wsdl11:port
element that defines the endpoint
merged with the element policy of the
referenced wsdl11:binding
element and the element policy of the
referenced wsdl11:portType
element that defines the
interface of the endpoint.
The following WSDL 1.1 elements collectively describe an operation:
wsdl11:portType/wsdl11:operation
wsdl11:binding/wsdl11:operation
These elements MAY have element policy as per Section 3. Policy Attachment.
The policy scope implied by each of these elements contains the operation policy subject representing the specific operation of the endpoint policy subject.
Since the wsdl11:portType/wsdl11:operation
may be
used by more than one binding, it is RECOMMENDED that only policies containing abstract
(i.e., binding independent) assertions should be attached to this
type of element.
Policies associated with an operation policy subject apply to the message exchange described by that operation.
The effective policy for a WSDL operation
policy subject is calculated in relation to a specific port, and
includes the element policy of the
wsdl11:portType/wsdl11:operation
element that defines
the operation merged with that
of the corresponding wsdl11:binding/wsdl11:operation
element.
The following WSDL 1.1 elements are used to describe messages:
wsdl11:message
wsdl11:portType/wsdl11:operation/wsdl11:input
wsdl11:portType/wsdl11:operation/wsdl11:output
wsdl11:portType/wsdl11:operation/wsdl11:fault
wsdl11:binding/wsdl11:operation/wsdl11:input
wsdl11:binding/wsdl11:operation/wsdl11:output
wsdl11:binding/wsdl11:operation/wsdl11:fault
These elements MAY have element policy as per Section 3. Policy Attachment.
The policy scope implied by these elements contains the message policy subject representing the specific input, output, or fault message in relation to the operation policy subject.
Policies associated with a message policy subject apply to that message (i.e. input, output or fault message).
The effective policy for a specific WSDL
message (i.e., input, output, or fault message) is calculated in
relation to a specific port, and includes the element policy of the
wsdl11:message
element that defines the message's type
merged with the element policy of the
wsdl11:binding
and wsdl11:portType
message definitions that describe that message.
For example, the effective policy of a specific input
message for a specific port would be the merge of the
wsdl11:message
element defining the message type, the
wsdl11:portType/wsdl11:operation/wsdl11:input
element,
and the corresponding
wsdl11:binding/wsdl11:operation/wsdl11:input
element
for that message.
Since a wsdl11:message
may be used by more than one
wsdl11:portType
, it is RECOMMENDED that only policies containing abstract
(i.e., binding independent) assertions should be attached to this
type of element.
Since wsdl11:input
, wsdl11:output
, and
wsdl11:fault
elements in a
wsdl11:portType/wsdl11:operation
may be used by
more than one binding, it is RECOMMENDED that only policies containing abstract
(i.e., binding independent) assertions should be attached to these
types of elements.
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 RECOMMENDED that policy alternatives on outbound messages SHOULD be avoided without the use of some form of mutual policy exchange between the parties involved.
As an example of the combination of these policy subjects and effective policy calculation, consider the WSDL type definition in Example 4-1 that references policies.
Example 4-1. Example Policy Attached to WSDL.
(01) <wsdl11:definitions name="StockQuote" targetNamespace="http://www.example.com/stock/binding" xmlns:tns="http://www.example.com/stock/binding" xmlns:fab="http://www.example.com/stock" xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"xmlns:wsp="http://www.w3.org/2006/07/ws-policy"xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" > (02) <wsp:Policy wsu:Id="RmPolicy" > (03) <rmp:RMAssertion> (04) <rmp:InactivityTimeout Milliseconds="600000" /> (05) <rmp:BaseRetransmissionInterval Milliseconds="3000" /> (06) <rmp:ExponentialBackoff /> (07) <rmp:AcknowledgementInterval Milliseconds="200" /> (08) </rmp:RMAssertion> (09) </wsp:Policy> (10) <wsp:Policy wsu:Id="X509EndpointPolicy" > (11) <sp:AsymmetricBinding> (12) <wsp:Policy> <!-- Details omitted for readability --> (13) <sp:IncludeTimestamp /> (14) <sp:OnlySignEntireHeadersAndBody /> (15) </wsp:Policy> (16) </sp:AsymmetricBinding> (17) </wsp:Policy> (18) <wsp:Policy wsu:Id="SecureMessagePolicy" > (19) <sp:SignedParts> (20) <sp:Body /> (21) </sp:SignedParts> (22) <sp:EncryptedParts> (23) <sp:Body /> (24) </sp:EncryptedParts> (25) </wsp:Policy> (26) <wsdl11:import namespace="http://www.example.com/stock" location="http://www.example.com/stock/stock.wsdl" /> (27) <wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" > (28) <wsoap12:binding style="document" (29) transport="http://schemas.xmlsoap.org/soap/http" /> (30) <wsp:PolicyReference URI="#RmPolicy" wsdl11:required="true" /> (31) <wsp:PolicyReference URI="#X509EndpointPolicy" wsdl11:required="true" /> (32) <wsdl11:operation name="GetLastTradePrice" > (33) <wsoap12:operation soapAction="http://www.example.com/stock/Quote/GetLastTradePriceRequest" /> (34) <wsdl11:input> (35) <wsoap12:body use="literal" /> (36) <wsp:PolicyReference URI="#SecureMessagePolicy" wsdl11:required="true" /> (37) </wsdl11:input> (38) <wsdl11:output> (39) <wsoap12:body use="literal" /> (40) <wsp:PolicyReference URI="#SecureMessagePolicy" (41) wsdl11:required="true" /> (42) </wsdl11:output> (43) </wsdl11:operation> (44) </wsdl11:binding> (45) </wsdl11:definitions>
For endpoints bound to StockQuoteSoapBinding
, the
effective
policy of the endpoint is listed in Example
3-1 (above). For the GetLastTradePrice
operation,
an additional message-level effective policy is in effect for the input
message, whose XML 1.0 representation is listed in Example 4-2.
Example 4-2. Example Message Security Policy Expression.
(01) <wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"xmlns:wsp="http://www.w3.org/2006/07/ws-policy"xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecureMessagePolicy" > (02) <sp:SignedParts> (03) <sp:Body /> (04) </sp:SignedParts> (05) <sp:EncryptedParts> (06) <sp:Body /> (07) </sp:EncryptedParts> (08) </wsp:Policy>
This section describes a mechanism for associating policy expressions with Web service constructs in WSDL 2.0. The mechanism consists of:
A model for attaching policies to WSDL 2.0 constructs. The model defines:
A partitioning of WSDL constructs into service, endpoint, operation and message policy subjects.
The semantics of attaching a policy to each policy subject.
How to combine policies attached to more than one WSDL component within a single policy subject.
An XML representation of policy expressions attached to WSDL 2.0
constructs and annotating those.
The annotation of such policy expressions as required extensions
using the WSDL-defined extensibility flag
@wsdl20:required
.
2.2 XML Namespaces lists all the XML Namespaces that are used in this section. (XML elements without a namespace prefix are from the Web Services Policy XML Namespace.)
The example below illustrates the use of WS-Policy Attachment for WSDL 2.0:
Example 5-1. Example Policy Attached to WSDL 2.0
(01) <wsdl20:description> (02) … (03)<Policy<wsp:Policy wsu:Id="common"> (04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/> (05) <wsap:UsingAddressing /> (06)</Policy></wsp:Policy> (07)<Policy<wsp:Policy wsu:Id="secure"> (08)<ExactlyOne><wsp:ExactlyOne> (09) <sp:TransportBinding>…</sp:TransportBinding> (10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding > (11)</ExactlyOne></wsp:ExactlyOne> (12)</Policy></wsp:Policy> (13) <wsdl20:binding name="SecureBinding" (14) interface="tns:RealTimeDataInterface" > (15)<PolicyReference<wsp:PolicyReference URI="#secure" /> (16) <wsdl20:operation name="GetRealQuote" >…</wsdl20:operation> (17) … (18) </wsdl20:binding> (19) <wsdl20:service name="RealTimeDataService" (20) interface="tns:RealTimeDataInterface" > (21) <wsdl20:endpoint name="RealTimeDataPort" (22) binding="tns:SecureBinding"> (23)<PolicyReference<wsp:PolicyReference URI="#common" /> (24) … (25) </wsdl20:endpoint> (26) </wsdl20:service> (27) … (28) </wsdl20:description>
The SecureBinding
WSDL binding description
describes a binding for an interface that provides real-time quotes
and book information on securities. (The prefixes
wsdl20
and tns
are used here to denote
the Web Services Description Language 2.0 XML Namespace and the
target namespace of this WSDL document respectively.) To require
the use of security for these offerings, a policy expression that requires the use of
either transport-level or message-level security is attached to the
binding description. The policy expression applies to any message
exchange associated with any endpoint
that supports
this binding description.
The RealTimeDataPort
WSDL endpoint description
describes an endpoint that supports the SecureBinding
WSDL binding description. To require the use of addressing and
allow the use of optimization (Optimized MIME Serialization as
defined in the MTOM specification [MTOM]), a policy expression that represents the
addressing requirement and optimization capability is attached to
the endpoint description. The policy expression applies to any message
exchange associated with the RealTimeDataPort
endpoint.
In the above example, the #secure
and
#common
policy
expressions attached to the SecureBinding
WSDL
binding and RealTimeDataPort
WSDL endpoint
descriptions collectively apply to any message exchange associated
with the RealTimeDataPort endpoint. The example below represents
the combination of these two policies, that is, the effective policy for the
RealTimeDataPort
endpoint.
Example 5-2. Effective Policy for the RealTimeDataPort endpoint
(01)<Policy><wsp:Policy> (02)<All><wsp:All> (03)<Policy><wsp:Policy> (04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/> (05) <wsap:UsingAddressing /> (06)</Policy></wsp:Policy> (07)<Policy><wsp:Policy> (08)<ExactlyOne><wsp:ExactlyOne> (09) <sp:TransportBinding>…</sp:TransportBinding> (10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding > (11)</ExactlyOne></wsp:ExactlyOne> (12)</Policy></wsp:Policy> (13)</All></wsp:All> (14)</Policy></wsp:Policy>
Policy attachment points in a WSDL 2.0 document are:
wsdl20:service
wsdl20:endpoint
wsdl20:binding
wsdl20:binding/wsdl20:operation
wsdl20:binding/wsdl20:fault
wsdl20:binding/wsdl20:operation/wsdl20:input
wsdl20:binding/wsdl20:operation/wsdl20:output
wsdl20:binding/wsdl20:operation/wsdl20:infault
wsdl20:binding/wsdl20:operation/wsdl20:outfault
wsdl20:interface
wsdl20:interface/wsdl20:operation
wsdl20:interface/wsdl20:fault
wsdl20:interface/wsdl20:operation/wsdl20:input
wsdl20:interface/wsdl20:operation/wsdl20:output
wsdl20:interface/wsdl20:operation/wsdl20:infault
and
wsdl20:interface/wsdl20:operation/wsdl20:outfault.
Any of these elements MAY have one
or more
or Policywsp:Policy
child elements.PolicyReferencewsp:PolicyReference
Policy attachment points in a WSDL document are associated with specific policy subjects as described in the table below. There are four policy subjects in WSDL: the service policy subject, the endpoint policy subject, the operation policy subject and the message policy subject. When a policy expression is attached to a policy subject in a WSDL document, capabilities and requirements represented by the policy expression apply to any message exchange or message associated with (or described by) the policy subject.
Policy Attachment Point in a WSDL document | WSDL Component | Policy Subject |
---|---|---|
wsdl20:service |
Service | Service |
wsdl20:endpoint |
Endpoint | Endpoint |
wsdl20:binding |
Binding | |
wsdl20:interface |
Interface | |
wsdl20:binding/wsdl20:operation |
Binding Operation | Operation |
wsdl20:interface/wsdl20:operation |
Interface Operation | |
wsdl20:binding/wsdl20:operation/
wsdl20:input |
Binding Message Reference | Message for an input message |
wsdl20:interface/wsdl20:operation/wsdl20:input |
Interface Message Reference whose {direction} property is ‘in’ | |
wsdl20:binding/wsdl20:operation/
wsdl20:output |
Binding Message Reference | Message for an output message |
wsdl20:interface/wsdl20:operation/ wsdl20:output |
Interface Message Reference whose {direction} property is ‘out’ | |
wsdl20:binding/wsdl20:fault |
Binding Fault | Message for an input fault message |
wsdl20:binding/wsdl20:operation/
wsdl20:infault |
Binding Fault Reference | |
wsdl20:interface/wsdl20:fault |
Interface Fault | |
wsdl20:interface/wsdl20:operation/wsdl20:infault |
Interface Fault Reference whose {direction} property is ‘in’ | |
wsdl20:binding/wsdl20:fault |
Binding Fault | Message for an output fault message |
wsdl20:binding/wsdl20:operation/wsdl20:outfault |
Binding Fault Reference | |
wsdl20:interface/wsdl20:fault |
Interface Fault | |
wsdl20:interface/wsdl20:operation/wsdl20:outfault |
Interface Fault Reference whose {direction} property is ‘out’ |
For a WSDL component, the attached policy (extension to the WSDL component model is described in 5.3 Extension to WSDL Component Model) is considered an intrinsic part of the WSDL component definition and applies to all uses of that definition. For example, when attached to a WSDL Interface component, capabilities and requirements represented by a policy apply to all the use of this WSDL Interface description. When attached to a WSDL Binding component, capabilities and requirements represented by a policy apply to all the Endpoints that support this binding description.
A policy associated with a service policy subject applies to any message exchange (that is explicitly described by the Interface component in the Service component's {interface} property) using any of the endpoints offered by that service.
Policies associated with an endpoint policy subject apply to any message exchange (that is explicitly described by the Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property) made using that endpoint. Given that a WSDL Interface component may be used by one or more binding descriptions, it is RECOMMENDED that only a policy containing policy assertions that apply to any possible binding description should be attached.
Policies associated with an operation policy subject apply to the message exchange described by that operation. Given that a WSDL Interface Operation component may be used by one or more binding descriptions, it is RECOMMENDED that only a policy containing policy assertions that apply to any possible binding description should be attached.
Policies associated with a message policy subject apply to that message (input, output or fault). Given that a WSDL Interface Message Reference, Interface Fault, Interface Fault Reference components may be used by one or more binding descriptions, it is RECOMMENDED that only a policy containing policy assertions that apply to any possible binding should be attached.
Policies MAY be attached at different levels of the WSDL component hierarchy. A message exchange with an endpoint MAY be described by the policies in all four policy subjects simultaneously.
The common mechanism of associating a policy expression with a policy subject is to attach a reference to
the policy expression to
the policy subject. As
described in the WS-Policy specification [Web Services Policy Framework], a reference
to a policy expression is
represented using the
element. A
policy attachment to a WSDL element is represented by attaching a
PolicyReferencewsp:PolicyReference
element as a child element of the
WSDL element.PolicyReferencewsp:PolicyReference
Policy expressions can
be included within a WSDL document or may reside external to a WSDL
document. If including policy
expressions with a WSDL document is the chosen approach, it is
RECOMMENDED that the
elements are included as children of the
Policywsp:Policywsdl20:description
element after the
wsdl20:types
element and referenced using the
elements.PolicyReferencewsp:PolicyReference
To mandate the processing of a policy expression attached to a policy
attachment point in a WSDL document, the expression MUST be marked as required using the
@wsdl20:required
flag.
If the
elements are included as children
of the Policywsp:Policywsdl20:description
element, these Policy
elements MUST NOT be marked as
required using the @wsdl20:required
. (Note: these
policy expressions may be
included as children of the wsdl20:description
element
and may not be attached to any policy attachment point in a WSDL
document.)
This document adds an optional {policy} property to the following WSDL components:
Service
Endpoint
Binding
Binding Operation
Binding Fault
Binding Message Reference
Binding Fault Reference
Interface
Interface Operation
Interface Fault
Interface Message Reference
Interface Fault Reference
The {policy} property, when present, represents the capabilities and requirements as a policy. The value of the {policy} property is a policy as defined by Section 3 - Policy Model in the WS-Policy specification [Web Services Policy Framework]. The following table describes the mapping from XML representation to the {policy} property.
Component | Value |
---|---|
Service | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:service element. |
Endpoint | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:endpoint element. |
Binding | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:binding element. |
Binding Operation | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:binding/wsdl20:operation element. |
Binding Fault | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:binding/wsdl20:fault element. |
Binding Message Reference | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:binding/wsdl20:operation/wsdl20:input or
wsdl20:binding/wsdl20:operation/wsdl20:output
element. |
Binding Fault Reference | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:binding/wsdl20:operation/wsdl20:infault or
wsdl20:binding/wsdl20:operation/wsdl20:outfault
element. |
Interface | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:interface element. |
Interface Operation | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:interface/wsdl20:operation element, if
any. |
Interface Fault | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:interface/wsdl20:fault element. |
Interface Message Reference | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:interface/wsdl20:operation/wsdl20:input or
wsdl20:interface/wsdl20:operation/wsdl20:output
element. |
Interface Fault Reference | A policy
corresponding to the merge of
or
elements, if any, in the [children] of the
wsdl20:interface/wsdl20:operation/wsdl20:infault or
wsdl20:interface/wsdl20:operation/wsdl20:outfault
element. |
Two {policy} properties are equivalent when they represent policies that contain the same number of policy alternatives, and each policy alternative in the first policy is equivalent to some policy alternative in the second policy, and conversely.
Two policy alternatives are equivalent when each policy assertion in the first policy alternative is equivalent to some policy assertion in the second policy alternative, and conversely. If either policy alternative contains multiple policy assertions of the same type, policy alternative equality is dependent on the semantics of that assertion type.
Two policy assertions are equivalent if they have the same QName, if either policy assertion is an ignorable policy assertion, both assertions must be ignorable policy assertions and, if either policy assertion has a nested policy, both assertions must have a nested policy and the nested policies must be equal. If either assertion contains policy assertion parameters, then the policy assertion parameters SHOULD be compared for equality. Comparing policy assertion parameters for equality is not defined by this document, but policy assertion equality may be further refined by the corresponding policy assertion specification.
The following diagram illustrates the four policy subjects in WSDL and how the effective policy is calculated for each of these policy subjects.
Figure 5-1. Policy Subjects and Effective Policy in WSDL 2.0
If multiple policies are attached to WSDL components that collectively represent a policy subject then the effective policy of these policies applies. (For example, there is a policy attached to an Endpoint component that describes the component and there is a policy attached to the Binding component in the Endpoint component’s {binding} property.) The effective policy is the merge of the policies that are attached to the same policy subject. The rest of this section describes how the effective policy is calculated for each of these policy subjects.
The effective policy of a service policy subject is the policy in the {policy} property of a Service component that describes the service.
The effective policy of an endpoint policy subject is the merge of policies in the {policy} properties of:
An Endpoint component that describes the endpoint,
The Binding component in the Endpoint component’s {binding} property,
The Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property and
The Interface components in the {extended interfaces} property of the Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property.
If the Binding component has an Interface component in the {interface} property, then the effective policy of an operation policy subject MAY be calculated by merging the policies in the {policy} properties of:
The Interface Operation component that describes the operation and
The Binding Operation component (if any) whose {interface operation} property has the Interface Operation component.
If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an operation policy subject MUST be calculated in relation to a specific endpoint, and is the policy in the {policy} property of the Interface Operation component that describes the operation.
If the Binding component has an Interface component in the {interface} property, then the effective policy of an input message MAY be calculated by merging the policies in the {policy} properties of:
The Interface Message Reference component that describes the input message and
The Binding Message Reference component whose {interface message reference} property has the Interface Message Reference component.
If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an input message MUST be calculated in relation to a specific endpoint, and is the policy in the {policy} property of the Interface Message Reference component that describes the input message.
If the Binding component has an Interface component in the {interface} property, then the effective policy of an output message MAY be calculated by merging the policies in the {policy} properties of:
The Interface Message Reference component that describes the output message and
The Binding Message Reference component whose {interface message reference} property has the Interface Message Reference component.
If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an output message MUST be calculated in relation to a specific endpoint, and is the policy in the {policy} property of the Interface Message Reference component that describes the output message.
If the Binding component has an Interface component in the {interface} property, then the effective policy of an input fault message MAY be calculated by merging the policies in the {policy} properties of:
The Interface Fault Reference component that describes the input fault message,
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property,
The Binding Fault Reference component whose {interface fault reference} property has the Interface Fault Reference component and
The Binding Fault component whose {interface fault} property has the Interface Fault component in the Interface Fault Reference component’s {interface fault} property.
If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an input fault message MUST be calculated in relation to a specific endpoint, and is the merge of policies in the {policy} properties of:
The Interface Fault Reference component that describes the input fault message and
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property.
If the Binding component has an Interface component in the {interface} property, then the effective policy of an output fault message MAY be calculated by merging the policies in the {policy} properties of:
The Interface Fault Reference component that describes the output fault message,
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property,
The Binding Fault Reference component whose {interface fault reference} property has the Interface Fault Reference component and
The Binding Fault component whose {interface fault} property has the Interface Fault component in the Interface Fault Reference component’s {interface fault} property for the endpoint.
If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an output fault message MUST be calculated in relation to a specific endpoint, and is the merge of policies in the {policy} properties of:
The Interface Fault Reference component that describes the output fault message and
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property.
This section defines a mechanism for associating policies with policy subjects through the use of UDDI. It defines a minimum level of support for associating policy expressions with entities in a UDDI registry. The calculation of effective policy for UDDI entities is described in Section 6.1 Calculating Effective Policy and Element Policy in UDDI. While the general concept for associating policy expressions with UDDI entities, which is specified in Sections 6.2 Referencing Remote Policy Expressions and 6.3 Registering Reusable Policy Expressions, is based on UDDI Version 2 [UDDI API 2.0, UDDI Data Structure 2.0], the necessary changes with respect to UDDI Version 3 [UDDI 3.0] are explained in Section 6.4 Registering Policies in UDDI Version 3.
There are essentially two approaches for registering policies in UDDI. One approach is to directly reference remotely accessible policy expressions in UDDI entities, the other is to register policy expressions as distinct tModels and then reference these tModels in each UDDI entity that is using the policy expression. While the former approach (see Section 6.2 Referencing Remote Policy Expressions) is expected to be used for policy expressions that are mainly unique for a given Web service, the latter approach (see Section 6.3 Registering Reusable Policy Expressions) is expected to be used for more modular and reusable policy expressions.
When attaching a policy to a UDDI entity a policy scope is implied for that attachment. The policy scope only contains the policy subjects associated with that entity, and not those associated with the children of that entity. This policy is the entity's element policy.
Each policy assertion contained within a UDDI entity's element policy should have the correct semantic such that the policy subject for that assertion is that UDDI entity. For example, assertions that describe behaviours regarding a service provider should only be contained within policies attached to a businessEntity structure.
For UDDI tModels that represent Web service types, the element policy is considered an intrinsic part of the tModel and applies to all uses of that tModel. In particular, it MUST be merged into the effective policy of every bindingTemplate that references that tModel.
Policies that apply to deployed Web services (bindingTemplates) are only considered in the effective policy of that deployed resource itself.
Each of these entities MAY have an element policy per Section 3. Policy Attachment. The remainder of this section defines how that element policy is interpreted to calculate the effective policy.
The following UDDI element is considered as the service provider policy subject:
uddi:businessEntity
This element MAY have element policy as per Section 3. Policy Attachment, and if present MUST be merged into the effective policy of the UDDI businessEntity Subject.
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:
uddi:businessService
This element MAY have element policy as per Section 3. Policy Attachment, and if present MUST be merged into the effective policy of the UDDI businessService Subject.
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:
uddi:bindingTemplate
uddi:tModel
These elements MAY have element policy as per Section 3. Policy Attachment. The policy scope implied by each of these elements contains the endpoint policy subject representing the deployed endpoint.
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 effective policy for a UDDI endpoint
includes the element policy of the
uddi:bindingTemplate
element that defines the endpoint
merged with the element policy of those
uddi:tModel
elements that are referenced in contained
uddi:tModelInstanceInfo
elements.
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 policy with an entity in a UDDI registry.
This new tModel is called the remote policy reference category system and is defined in Appendix B.1 Remote Policy Reference Category System.
UDDI registries MUST use the (UDDI
V2 [UDDI Data Structure
2.0]) tModelKey
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
policy expressions; that
is, when referencing this category system in a
categoryBag
, the corresponding keyValue
of the keyedReference
is the IRI of the policy expression.
Using the remote policy reference category system, one can then
associate a policy
expression with a businessEntity
, a
businessService
, and a tModel using the entity's
categoryBag
. For example, associating the policy expression that is identified
by the IRI http://www.example.com/myservice/policy
with a businessService
is done as follows:
(01) <businessService serviceKey="…" > (02) <name>…</name> (03) <description>…</description> (04) <bindingTemplates>…</bindingTemplates> (05) <categoryBag> (06) <keyedReference (07) keyName="Policy Expression for example's Web services" (08) keyValue="http://www.example.com/myservice/policy" (09) tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /> (10) </categoryBag> (11) </businessService>
The tModelKey
of the keyedReference
MUST match the fixed
tModelKey
from the remote policy reference category
system. The keyValue
MUST
be the IRI that identifies the policy expression.
A different approach has to be taken to associate a policy expression with a
bindingTemplate
, since bindingTemplates do not contain
a categoryBag
in UDDI Version 2. Therefore, the
bindingTemplate
's tModelInstanceInfo
and
instanceParms
MUST be
used as follows:
(01) <bindingTemplate bindingKey="…" > (02) <accessPoint>…</accessPoint> (03) <tModelInstanceDetails> (04) <tModelInstanceInfo (05) tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" > (06) <instanceDetails> (07) <instanceParms> (08) http://www.example.com/myservice/policy (09) </instanceParms> (10) </instanceDetails> (11) </tModelInstanceInfo> (12) </tModelInstanceDetails> (13) </bindingTemplate>
The tModelKey
of the
tModelInstanceInfo
MUST
match the fixed tModelKey
from the remote policy
reference category system as defined above. The
instanceParms
MUST be the
IRI that identifies the policy expression.
In addition to using the approach outlined in the section above, publishers may register a specific policy expression in a UDDI registry as a distinct tModel. To properly categorize tModels as policy expressions, Web Services Policy 1.5 - Attachment pre-defines the Web Services Policy Types category system as a tModel. This tModel is defined in Appendix B.2 Web Services Policy Types Category System.
The following illustrates a tModel for the policy expression identified by the IRI
http://www.example.com/myservice/policy
.
(01) <tModel tModelKey="uuid:04cfa…"> (02) <name>…</name> (03) <description xml:lang="EN"> (04) Policy Expression for example's Web services (05) </description> (06) <overviewDoc> (07) <description xml:lang="EN">Web Services Policy Expression</description> (08) <overviewURL>http://www.example.com/myservice/policy</overviewURL> (09) </overviewDoc> (10) <categoryBag> (11) <keyedReference (12) keyName="Reusable policy Expression" (13) keyValue="policy" (14) tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" /> (15) <keyedReference (16) keyName="Policy Expression for example's Web services" (17) keyValue="http://www.example.com/myservice/policy" (18) tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /> (19) </categoryBag> (20) </tModel>
The first keyedReference
specifies that the tModel
represents a policy
expression — rather than only being associated with one — by
using the Web Services Policy Types category system's built-in
category "policy"
, which is its single valid value.
This is necessary in order to enable UDDI inquiries for policy expressions in general. The
second keyedReference
designates the policy expression the tModel represents by
using the approach from the section above. This is necessary in
order to enable UDDI inquiries for particular policy expressions based on their IRI.
Note that the policy expression IRI is also specified in the tModel's overview URL to indicate that it is a resolvable URL to actually retrieve the policy expression.
Web Services Policy 1.5 - Attachment pre-defines another tModel that is used to associate such a pre-registered, locally available policy expressions with an entity in a UDDI registry
This new tModel is called the local policy reference category system and is defined in Appendix B.3 Local Policy Reference Category System.
UDDI registries MUST use the
tModelKey
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 keyValue
of the
keyedReference
is the tModelKey
of the
tModel that represents the policy expression.
Given the local policy reference category system, one can then
associate a policy
expression tModel with a businessEntity
, a
businessService
, and a tModel using the entity's
categoryBag
. For example, associating the policy expression tModel with the
tModelKey
"uuid:04cfa…"
from above with a
businessService
is done as follows:
(01) <businessService serviceKey="…" > (02) <name>…</name> (03) <description>…</description> (04) <bindingTemplates>…</bindingTemplates> (05) <categoryBag> (06) <keyedReference (07) keyName="Policy Expression for example's Web services" (08) keyValue="uuid:04cfa…" (09) tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" /> (10) </categoryBag> (11) </businessService>
The tModelKey
of the keyedReference
MUST match the fixed
tModelKey
from the local policy reference category
system. The keyValue MUST be the
tModelKey
of the policy expression that is registered with
the UDDI registry.
A different approach has to be taken to associate a policy expression with a
bindingTemplate
, since bindingTemplates do not contain
a categoryBag
in UDDI Version 2. Therefore, the
bindingTemplate
's tModelInstanceInfo
and
instanceParms
MUST be
used as follows:
(01) <bindingTemplate bindingKey="…" > (02) <accessPoint>…</accessPoint> (03) <tModelInstanceDetails> (04) <tModelInstanceInfo (05) tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" > (06) <instanceDetails> (07) <instanceParms>uuid:04cfa…</instanceParms> (08) </instanceDetails> (09) </tModelInstanceInfo> (10) </tModelInstanceDetails> (11) </bindingTemplate>
The tModelKey of the tModelInstanceInfo
MUST match the fixed
tModelKey
from the local policy reference category
system. The instanceParms
MUST be the tModelKey
of the
policy expression that is
registered with the UDDI registry.
UDDI Version 3 [UDDI 3.0] provides a number of enhancements in the areas of modeling and entity keying. Special considerations for UDDI multi-version support are outlined in chapter 10 of [UDDI 3.0]. The changes with respect to the previous sections are as follows.
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 tModelKey
for the remote policy reference
tModel changes from
"uuid:a27078e4-fd38-320a-806f-6749e84f8005"
to
"uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
.
The tModelKey
for the Web Services Policy Types
tModel changes from
"uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993"
to
"uddi:schemas.xmlsoap.org:policytypes:2003_03"
.
The tModelKey
for the local policy reference tModel
changes from
"uuid:a27f7d45-ec90-31f7-a655-efe91433527c"
to
"uddi:schemas.xmlsoap.org:localpolicyreference:2003_03"
.
Second, rather than putting policy expression references in a
bindingTemplate
's tModelInstanceInfo
,
they are added to the bindingTemplate
's
categoryBag
, analogous to the mechanism described for
other UDDI entities. For example, the example
bindingTemplate
from section 6.1 Calculating
Effective Policy and Element Policy in UDDI would be
changed as follows:
(01) <bindingTemplate bindingKey="…" > (02) <accessPoint>…</accessPoint> (03) <tModelInstanceDetails>…</tModelInstanceDetails> (04) <categoryBag> (05) <keyedReference (06) keyName="Policy Expression for example's Web services" (07) keyValue="http://www.example.com/myservice/policy" (08) tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03" (09) /> (10) </categoryBag> (11) </bindingTemplate>
Third, inquiries for reusable policy expression tModels described in
Section 6.3
Registering Reusable Policy Expressions and UDDI tModel
entities that are associated with remote policy expression is enhanced by the
wildcard mechanism for keyValues in keyedReferences. For example,
searching for all policy
expression tModels whose IRI starts with
http://www.example.com/
, the following
find_tModel
API call can be used:
(01) <find_tModel xmlns="urn:uddi-org:api_v3" > (02) <categoryBag> (03) <keyedReference (04) keyValue="http://www.example.com/" (05) tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03" (06) /> (07) </categoryBag> (08) <findQualifiers> (09) <findQualifier>approximateMatch</findQualifier> (10) </findQualifiers> (11) </find_tModel>
Fourth, all UDDI entities may be digitally signed using XML digital signatures [XML-Signature]. Publishers who want to digitally sign their policy expression tModels or policy expression references in UDDI MUST use the Schema-centric canonicalization algorithm [SCC14N].
It is RECOMMENDED that policy attachments be signedintegrity
protected to preventpermit the detection of tampering. This can be done
using a technology such as XML DSig [XML-Signature], SSL/TLS [IETF RFC 2246], or WS-Security 2004
[WS-Security 2004]. This
also provides a mechanism for authenticating policy attachments by determining if the
signer has the right to "speak for" the scope of the policy attachment.
Policies SHOULD NOT be accepted unless they are signed and have an associated security token to specify the signer has the right to "speak for" the scope containing the policy.
A more complete discussion of security considerations can be found in the Security Considerations section of the Web Services Policy 1.5 - Framework document [Web Services Policy Framework].
An element information item whose namespace name is
"http://www.w3.org/2006/07/ws-policy""http://www.w3.org/ns/ws-policy" and whose local part is
PolicyAttachment conforms to this specification if it is valid
according to the XML Schema [XML
Schema Structures] for that element as defined by this
specification ( http://www.w3.org/2006/07/ws-policy.xsdhttp://www.w3.org/2007/02/ws-policy.xsd)
and additionally adheres to all the constraints contained in
Section 3.4 External Policy
Attachment of this specification. Such a conformant element
information item constitutes an external policy attachment.
A WSDL 1.1 [WSDL 1.1] description conforms to this specification when it incorporates one or more element policies and additionally adheres to all the constraints contained in section 4. Attaching Policies Using WSDL 1.1
A WSDL 2.0 [WSDL 2.0 Core Language] description conforms to this specification when it incorporates one or more element policies and additionally adheres to all the constraints contained in section 5. WS-Policy Attachment for WSDL 2.0
This section contains the UDDI tModel definitions for the canonical tModels used in Section 6. Attaching Policies Using UDDI. The tModelKeys shown in the tModel structure sections are valid UDDI Version 2 keys. When using UDDI Version 3, the corresponding derived UDDI Version 2 keys must be used.
This tModel is used to attach a policy to a UDDI entity by referencing the policy's IRI.
Name: | http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference |
---|---|
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 |
(01) <tModel tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" > (02) <name>http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference</name> (03) <description xml:lang="EN">Category system used for UDDI entities to point to an external (04) Web Services Policy Attachment policy expression that describes their characteristics. (05) See Web Services Policy 1.5 - Attachment specification for further details.</description> (06) <categoryBag> (07) <keyedReference (08) keyName="uddi-org:types:categorization" (09) keyValue="categorization" (10) tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" /> (11) </categoryBag> (12) </tModel>
This tModel is used to categorize tModels as representing
policy expressions. There
is only one valid value, namely "policy"
, that
indicates this very fact. It is RECOMMENDED that tModels categorized as
representing policy
expressions reference no more and no less than this very
policy expression using
the remote policy reference category system.
Name: | http://schemas.xmlsoap.org/ws/2003/03/policytypes |
---|---|
Description: | Web services policy types category system used for UDDI tModels to characterize them as Web services policy–based policy expressions. |
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 |
(01) <tModel tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" > (02) <name>http://schemas.xmlsoap.org/ws/2003/03/policytypes</name> (03) <description xml:lang="EN">Web Services Policy Types category system used for UDDI tModels (04) to characterize them as Web Services Policy – based policy expressions.</description> (05) <categoryBag> (06) <keyedReference (07) keyName="uddi-org:types:categorization" (08) keyValue="categorization" (09) tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" /> (10) </categoryBag> (11) </tModel>
This tModel is used to attach a policy expression to a UDDI entity by referencing the UDDI entity that represents this policy expression. The local policy reference category system is based on tModelKeys. It is expected that referenced tModels are registered with the same UDDI registry and are categorized as representing policy expressions using the Web services policy types category system.
Name: | http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference |
---|---|
Description: | Category system used for UDDI entities to point to a Web services policy policy expression tModel that describes their characteristics. See Web Services Policy 1.5 - Attachment specification for further details. |
UDDI Key (V3): |
uddi:schemas.xmlsoap.org:localpolicyreference:2003_03 |
UDDI V1,V2 format key: |
uuid:a27f7d45-ec90-31f7-a655-efe91433527c |
Categorization: | categorization |
Checked: | Yes |
(01) <tModel tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" > (02) <name>http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference</name> (03) <description xml:lang="en">Category system used for UDDI entities to point to a (04) Web Services Policy policy expression tModel that describes their characteristics. (05) See Web Services Policy 1.5 - Attachment specification for further details.</description> (06) <categoryBag> (07) <keyedReference (08) keyName="uddi-org:types:categorization" (09) keyValue="categorization" (10) tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" /> (11) <keyedReference (12) keyName="uddi-org:types:checked" (13) keyValue="checked" (14) tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" /> (15) <keyedReference (16) keyName="uddi-org:entityKeyValues" (17) keyValue="tModelKey" (18) tModelKey="uuid:916b87bf-0756-3919-8eae-97dfa325e5a4" /> (19) </categoryBag> (20) </tModel>
This document is the work of the W3C Web Services Policy Working Group.
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), Symon Chang (BEA Systems, Inc.),
Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic
Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu
Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM
Corporation), William Henry (IONA Technologies, Inc.), Frederick
Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe
Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret
(W3C/MIT), Jong Lee (BEA Systems, Inc.),Mark Little (JBoss Inc.), Ashok Malhotra (Oracle
Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud
Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation),
Dale Moberg (Cyclone Commerce, Inc.),(Axway Software), Anthony Nadalin (IBM Corporation),
Bob Natale (MITRE Corporation), David Orchard (BEA Systems, Inc.),
Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft
Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake
(WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov
Sverdlov (Computer Associates),(CA Inc.), Mark Temple-Raston (Citigroup), Asir Vedamuthu
(Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp
(SAP AG), Prasad Yendluri (webMethods, Inc.).
Previous members of the Working Group were: Jong Lee (BEA
Systems, Inc.), Bijan Parsia (University of Manchester), Seumas
Soltysik (IONA Technologies, Inc.)Inc.).
The people who have contributed to discussions on public-ws-policy@w3.org are also gratefully acknowledged.
A list of substantivemajor editorial changes since the Working Draft dated
0217 November, 2006 is below:
Added a newClarified the relationship between URI domain expression:expression and
WSDL 1.1 Element Identifiers [WSDL11
ElementIds] in Section 3.4.1 URI Domain
Expression.
DefinedExplicitly described the equivalence of two {policy} propertiesinteraction between policy attachment
mechanisms and XML Base in Section 5.3 Extension to WSDL Component Model3.5 Use of IRIs in Policy
Attachment.
Date | Author | Description |
---|---|---|
20060712 | ASV | Updated the list of editors. Completed action items 20 from the Austin F2F. |
20060712 | DBO | Completed action item 12 |
20060718 | DBO | Completed action items Editors to remove extraneous namespace decl in the example at the end of section 3.4 18, RFC2606 for domain names 09 (note: PLH had already done but it didn't show up in the change log) editors to straighten up Note after example 3-1 11 |
20060719 | TIB | Completed action item 22: Linked SVG graphic |
20060721 | ASV | Completed action items 23, 25 and 26 from the Austin F2F. |
20060721 | ASV | Completed action item 29 from the Austin F2F. |
20060726 | ASV | Incorporated the XML namespace URI versioning policy adopted by the WG. |
20060808 | DBO | Completed action items: 15 as early as possible in the doc, use the definition that are defined in the doc. Issue 3545, use of {any} and {@any} in xpath-like expressions not defined in Notational Conventions section |
20060808 | ASV | Implemented the resolution for issue 3543. |
20060809 | DBO | Implemented the resolution for issue 3546: wsdl 2.0 status mention. |
20060809 | ASV | Implemented the resolution for issue 3556 and the resolution for issue 3558. |
20060811 | DBO | Completed action items: 15 remove use if emph/ital terms. Framework: removed emph on conceptually replace and support; attachment: make merge a termdef |
20060813 | ASV | Added a new Section D. Changes in this Version of the Document (that provides a list of substantive chanages since the previous publication). |
20060825 | PY | Implemented the resolution for issue 3544. |
20060827 | TIB | Completed action item: resolution for adding Conformance section. |
20060827 | TIB | Implemented the resolution for issue 3605: typo in example. |
20060829 | ASV | Implemented the resolution for issue 3561: replaced URI with IRI. |
200609006 | DBO | Completed partial resolution for issue 3590. for adding document attribute extensbility of wsp:Policy/@{any} and wsp:Policy/.../wsp:PolicyReference/@{any}, specifically making attribute extensibility for any namespace. |
20060906 | ASV | Implemented the resolution for issue 3557: clarify the use of domain expressions. |
20060924 | TIB | Implemented the resolution for issue 3709: Editorial corrections from UDDI team. |
20060925 | ASV | Created 5. WS-Policy Attachment for WSDL 2.0 per action item 2 from the Bellevue F2F. This section is based on a contribution from BEA, IBM, Microsoft and Oracle. |
20061002 | DBO | Implemented the http://www.w3.org/2005/06/tracker/wspolicy/actions/64 for issue 3559: Conformance Section. |
20061002 | DBO | Implemented the resolution for issue 3712:wsp:PolicyReference can be used in any place where you can use wsp:Policy |
20061008 | MH | Implemented the resolution for issue summary of Action 10 from F2F replaced "subject" instances with "policy subject" |
20061012 | PY | Updated "Changes in this Version" section (Appendix D) |
20061019 | PY | Completed action item: 57 PaulC's comments. |
20061027 | FS | Changed the SVG link and re-formatted the examples in B. UDDI tModel Definitions (these changes were necessary for PDF creation). |
20061030 | DBO | Implemented the resolution titled "Hyperlink terms such as policy expression..." |
20061031 | TIB | Completed action item: 58 to add a pointer to the Security Considerations section of the framwork document. This is a follow-up to closed issue 110 |
20061102 | ASV | Implemented the resolution for Editors' Action 12. |
20061102 | ASV | Reset Section D. Changes in this Version of the Document. |
20061109 | PY | Implemented the resolution for Issue 3894. Editors' Action 71. |
20061109 | TIB | Implemented Editors' Action 74. |
20061109 | ASV | Implemented the resolution for issues 3721 and 3789. |
20061109 | ASV | Implemented the resolution for issues 3599 and 3730. |
20061109 | ASV | Updated Section D. Changes in this Version of the Document. |
20061127 | ASV | Added Frederick and Umit to the list of editors. Editors' action 86. |
20061218 | FJH | Implemented the resolution for issue 4039 to close editors' action 99. |
20070108 | ASV | Applied the missed amendment (re issue 4039) to section 3.5 Use of IRIs in Policy Attachment. |
20070108 | ASV | Reset Section D. Changes in this Version of the Document. |
20070116 | DBO | Completed action item: 116 and 124 Resolution for issue 4211 |
20070117 | FJH | Applied the resolution for issues 4045 and 4127 using first and second parts as outlined in working group resolution. This closes editors actions 139 and 111. |
20070121 | MH | Completed action item: 129 Resolution for issue 4207 |
20070122 | ASV | Implemented the resolution for issue 4230. Editors' action 135. |
20070122 | UY | Implemented the resolution for issue 4209. Editors' action 131. |
20070122 | UY | Implemented the resolution for issue 4226. Editors' action 134. |
20070123 | ASV | Applied missed items (re issue 4045) to section 3.4.1 URI Domain Expression and 5. WS-Policy Attachment for WSDL 2.0. |
20070123 | ASV | Applied a
missed item (re issue 4226) to
section 5. WS-Policy
Attachment for WSDL 2.0: added wsp prefix to Example 5-2 and all
occurrences of Policy and
PolicyReference . |
20070123 | ASV | Fixed a typo in A.2 Other References: "[IETF RFC 3023]IETF "RFC 2246:". |
20070124 | ASV | Updated Section D. Changes in this Version of the Document. |
20070207 | ASV | Implemented the resolution for issue 4306. Editors' action 158. |
20070222 | ASV | Applied a missed item (re issue 4207) to 2.2 XML Namespaces. |