Web Services Policy 1.5 - Attachment

Editors' copy $Date: 2007/02/22 21:50:02 $ @@ @@@@ @@@@

This version:

ws-policy-attachment.html

Latest version:

http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;charset=utf-8

Previous version:

http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117

Editors:

Asir S Vedamuthu, Microsoft Corporation

David Orchard, BEA Systems, Inc.

Frederick Hirsch, Nokia

Maryann Hondo, IBM Corporation

Prasad Yendluri, webMethods, Inc.

Toufic Boubez, Layer 7 Technologies

Ümit Yalçinalp, SAP AG.

Copyright © @@@@ W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

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.

Status of this Document

This document is an editors' copy that has no official standing.

Table of Contents

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

Appendices

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)

1. Introduction

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].

2. Notations and Terminology

This section specifies the notations, namespaces, and terminology used in this specification.

2.1 Notational Conventions

2.2 XML Namespaces

3. Policy Attachment

This section defines two general-purpose mechanisms for associating policies with one or more policy subjects.

4. Attaching Policies Using WSDL 1.1

 

 

5. WS-Policy Attachment for WSDL 2.0

·          

6. Attaching Policies Using UDDI

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.

6.1 Calculating Effective Policy and Element Policy in UDDI

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.

6.1.1 Service Provider Policy Subject

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.

6.1.2 Service Policy Subject

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.

6.1.3 Endpoint Policy Subject

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.

6.2 Referencing Remote Policy Expressions

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:c89e98b4-868c-3abf-a683-89071af807c6uuid: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:c89e98b4-868c-3abf-a683-89071af807c6uuid: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:c89e98b4-868c-3abf-a683-89071af807c6uuid: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.

6.3 Registering Reusable Policy Expressions

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:78003262-1ea8-3ae5-95cb-67cc900b6b59uuid: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:c89e98b4-868c-3abf-a683-89071af807c6uuid: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:9e9bfbe9-2212-3c9c-a170-381e702a9946uuid: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:9e9bfbe9-2212-3c9c-a170-381e702a9946uuid: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:9e9bfbe9-2212-3c9c-a170-381e702a9946uuid: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.

6.4 Registering Policies in UDDI Version 3

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:c89e98b4-868c-3abf-a683-89071af807c6uuid:a27078e4-fd38-320a-806f-6749e84f8005" to "uddi:w3c.org:ws-policy:v1.5:attachment:remotepolicyreference uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03".

The tModelKey for the Web Services Policy Types tModel changes from " uuid:78003262-1ea8-3ae5-95cb-67cc900b6b59uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" to "uddi:w3c.org:ws-policy:v1.5:attachment:policytypesuddi:schemas.xmlsoap.org:policytypes:2003_03".

The tModelKey for the local policy reference tModel changes from "uuid:9e9bfbe9-2212-3c9c-a170-381e702a9946uuid:a27f7d45-ec90-31f7-a655-efe91433527c" to "uddi:w3c.org:ws-policy:v1.5:attachment:localpolicyreference 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:w3c.org:ws-policy:v1.5:attachment:remotepolicyreference 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:w3c.org:ws-policy:v1.5:attachment:remotepolicyreference 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].

7. Security Considerations

It is RECOMMENDED that policy attachments be integrity protected to permit 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].

8. Conformance

8.1 External Policy Attachment Conformance

An element information item whose namespace name is "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/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.

8.2 WSDL 1.1 Attachment Conformance

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

8.3 WSDL 2.0 Attachment Conformance

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

A. References

A.1 Normative References

[BP 1.1]

Basic Profile Version 1.1, K. Ballinger, et al, Editors. The Web Services-Interoperability Organization, 10 June 2006. This version of the Basic Profile Version 1.1 is http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html. The latest version of the Basic Profile Version 1.1 is available at http://www.ws-i.org/Profiles/BasicProfile-1.1.html

[IETF RFC 3023]  

B. UDDI tModel Definitions

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.

B.1 Remote Policy Reference Category System

B.1.1 Design Goals

This tModel is used to attach a policy to a UDDI entity by referencing the policy's IRI.

B.1.2 tModel Definition

Name:

http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference

http://www.w3.org/ns/ws-policy/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:w3c.org:ws-policy:v1.5:attachment:remotepolicyreference

UDDI V1,V2 format key:

uuid:a27078e4-fd38-320a-806f-6749e84f8005

uuid:c89e98b4-868c-3abf-a683-89071af807c6

Categorization:

categorization

Checked:

No

B.1.3 tModel Structure

B.2 Web Services Policy Types Category System

B.2.1 Design Goals

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.

B.2.2 tModel Definition

Name:

http://schemas.xmlsoap.org/ws/2003/03/policytypes

http://www.w3.org/ns/ws-policy/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:w3c.org:ws-policy:v1.5:attachment:policytypes

UDDI V1,V2 format key:

uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993

uuid:78003262-1ea8-3ae5-95cb-67cc900b6b59

Categorization:

categorization

Checked:

No

B.2.3 tModel Structure

B.3 Local Policy Reference Category System

B.3.1 Design Goals

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.

B.3.2 tModel Definition

Name:

http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference

http://www.w3.org/ns/ws-policy/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:w3c.org:ws-policy:v1.5:attachment:localpolicyreference

UDDI V1,V2 format key:

uuid:a27f7d45-ec90-31f7-a655-efe91433527c

uuid:9e9bfbe9-2212-3c9c-a170-381e702a9946

Categorization:

categorization

Checked:

Yes

B.3.3 tModel Structure

(01) <tModel tModelKey="uuid:9e9bfbe9-2212-3c9c-a170-381e702a9946uuid: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> 

C. Acknowledgements (Non-Normative)

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), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (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 (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.).

The people who have contributed to discussions on public-ws-policy@w3.org are also gratefully acknowledged.