The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: November 20, 2007.
News: Cover StoriesPrevious News ItemNext News Item

W3C Web Services Policy 1.5 Primer and Guidelines for Policy Assertion Authors.

Contents

W3C has announced the publication of Web Services Policy 1.5 - Primer and Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, complementing the two W3C WS-Policy specification Recommendations issued in September 2007.

The W3C Web Services Policy Working Group was chartered "to standardize a general policy framework for expressing Web service capabilities and requirements. The framework consists of a policy data model for expressing capabilities and requirements of a Web Service, a processing model for combining and comparing Web service capabilities and requirements and an XML Information Set representation for the policy data model."

W3C recently announced the publication of two key Web Services Policy 1.5 deliverables from the WS-Policy Working Group as Recommendations: Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment. Contributing organizations included Adobe Systems Inc; Axway Software; BEA Systems, Inc; CA; Fujitsu Limited; IBM; IONA Technologies, Inc.; JBoss Inc.; Layer 7 Technologies; Microsoft Corporation; Nokia; Nortel Networks; Oracle Corporation; SAP AG; Sonic Software; Sun Microsystems, Inc.; webMethods, Inc.; and WSO2.

The Web Services Policy 1.5 Framework Recommendation "defines a framework and a model for expressing policies that refer to domain-specific capabilities, requirements, and general characteristics of entities in a Web services-based system. A policy is a collection of policy alternatives. A policy alternative is a collection of policy assertions. A policy assertion represents a requirement, capability, or other property of a behavior. A policy expression is an XML Infoset representation of its policy, either in a normal form or in its equivalent compact form. Some policy assertions specify traditional requirements and capabilities that will manifest themselves in the messages exchanged (e.g., authentication scheme, transport protocol selection).

The Web Services Policy 1.5 Attachment Recommendation "defines two general-purpose mechanisms for associating policies, as defined in Web Services Policy 1.5 Framework, with the subjects to which they apply. The specification also defines how these general-purpose mechanisms may be used to associate policies with WSDL and UDDI descriptions. The Framework Recommendation itself does not cover discovery of policy, policy scopes and subjects, or their respective attachment mechanisms. A policy attachment is a mechanism for associating policy with one or more policy scopes. A policy scope is a collection of policy subjects to which a policy applies. A policy subject is an entity (e.g., an endpoint, message, resource, interaction) with which a policy can be associated. The Attachment document defines policy attachment mechanisms, especially for associating policy with arbitrary XML elements (XML 1.0), WSDL artifacts, and UDDI elements. Other specifications are free to define either extensions or additional mechanisms for purposes of associating policy with policy scopes and subjects.

The Web Services Policy 1.5 Primer document provides an introductory description of the Web Services Policy language. It should be read alongside the formal descriptions contained in the WS-Policy and WS-PolicyAttachment specifications. This document is designed (1) for policy expression authors who need to understand the syntax of the language and understand how to build consistent policy expressions; (2) for policy implementers whose software modules read and write policy expressions, and (3) for policy assertion authors who need to know the features of the language and understand the requirements for describing policy assertions. It assumes a basic understanding of XML 1.0, Namespaces in XML, WSDL 1.1, and SOAP.

The Primer "Section 2 Basic Concepts: Policy Expression" covers the basic mechanisms of Web Services Policy; it describes how to declare and combine capabilities and requirements of a Web service as policy expressions, attach policy expressions to WSDL constructs such as endpoint and message, and re-use policy expressions. Section "3 Advanced Concepts: Policy Expression" provides more in-depth materials for policy implementers and assertion authors; it explains the basics of normalizing policy expressions, merging policies, determining the compatibility (intersection) of policies, the policy data model, the policy expression and the extensibility points built into the Web Services Policy language. Section "4 Versioning Policy Language" provides examples and best practices on versioning of the policy language itself, mostly intended for policy implementers.

The Web Services Policy 1.5 Guidelines for Policy Assertion Authors document is intended to provide guidance for Assertion Authors that will work with the Web Services Policy 1.5 Framework and Attachment Recommendations. It provides best practices and patterns to follow as well as illustrates the care needed in using WS-Policy to achieve the best possible results for interoperability. It is a complementary guide to using the WS-Policy specifications.

"WS-Policy Assertions communicate the requirements and capabilities of a web service by adhering to the specification, WS-Policy Framework. To enable interoperability of web services different sets of WS-Policy Assertions need to be defined by different communities based upon domain-specific requirements of the web service. An assertion is a piece of metadata that describes a capability related to a specific domain that has chosen to express their capabilities via the WS-Policy expressions. Sets of domain-specific assertions are typically defined in a dedicated specification that describes their semantics, applicability and scoping requirements as well as their data type definition using XML Schema. Policy assertions representing shared and visible behaviors are useful pieces of metadata to enable interoperability and tooling for automation. The key to understanding when to design policy assertions is to have clarity on the characteristics of a behavior represented by a policy assertion."

"As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy relies on the QName of a policy assertion being an XML element but allows Assertion Authors to optionally provide additional semantics through nesting assertions, or specifying assertion parameters."

WS-Policy specifications (WS-Policy, WS-PolicyAttachment, WS-PolicyAssertions) were initially published by BEA, IBM, Microsoft, and SAP in 2002. The Framework and Attachment specifications were contributed to W3C as a Member Submission on April 13, 2006 and were published on April 26, 2006.

Bibliographic Information

WS-Policy Primer and Guidelines

Web Services Policy 1.5: Framework and Attachment

Announcement for Web Services Policy 1.5

From the press release:

On 4-September-2007 the World Wide Web Consortium issued a critical Web standard for extending the features of Web services and Service Oriented Architecture (SOA) applications. Building on the fundamental open Web services standards from W3C, Web Services Policy enables developers to meet requirements for secure transactions, reliable messaging, addressing metadata, and other scenarios, in modular fashion.

With Web Services Policy 1.5, SOA developers can enable extensions to a service without disruption or requiring changes to lower level service descriptions. The extensions themselves (consisting of what are called "policy assertions") are defined by other specifications.

Web Services Policy 1.5 Based on Industry Needs, Experience

Years of customer experience with commercial Web services applications have made clear the need for a modular approach for describing required and optional extensions used by a service. Without this capability, it can be costly to rewrite an entire service whenever application needs change. Web Services Policy 1.5 can reduce this cost. It connects the core Web services standards — SOAP 1.2, WSDL 2.0, and XML Schema — to a growing set of extensions that reflect industry needs and experience.

The W3C Web Services Policy Working Group invited implementers to demonstrate interoperability by evaluating software against the group's test suite. Ten implementations of Web Services Policy 1.5 helped confirm the maturity of the specification. The tests focused on security assertions, one of the most important use cases cited by industry.

Another use case, addressing metadata, is the focus of W3C's WS-Addressing Working Group. The two W3C Working Groups have collaborated to ensure that the Addressing Metadata Specification is aligned with the policy framework.

The W3C Web Services Policy Working Group also secured review from several OASIS Web Services Technical Committees (UDDI, WS-RX, WS-TX, and WS-SX) to ensure that Web Services Policy 1.5 would satisfy their use cases.

Web Services Working Group Brings Together Industry Leaders

The Web Services Policy Working Group brings together leaders from across the software industry including Adobe Systems Inc; Axway Software; BEA Systems, Inc; CA; Fujitsu Limited; IBM; IONA Technologies, Inc.; JBoss Inc.; Layer 7 Technologies; Microsoft Corporation; Nokia; Nortel Networks; Oracle Corporation; SAP AG; Sonic Software; Sun Microsystems, Inc.; webMethods, Inc.; and WSO2.

Many of the group participants have made commitments to support the specification in products, as indicated by the testimonials.

From the W3C Web Services Policy Working Group Charter

The Web Services Policy Working Group, co-chaired by Paul Cotton (Microsoft) and Chris Ferris (IBM), part of the Web Services Activity, was chartered to produce W3C Recommendations for Web Services Policy by refining the WS-Policy Member Submission, addressing implementation experience and interoperability feedback from the specifications, maximizing compatibility with existing policy assertions (as defined in the Scope section), and considering composition with other components in the Web services architecture.

Web Services Policy defines a flexible policy data model and an extensible grammar for expressing the capabilities, requirements and general characteristics of a Web service, and defines mechanisms for associating policies with Web service constructs. Web Services Policy is used to convey the conditions for an interaction between a Web service requester and a Web service provider.

Existing policy assertions are broadly deployed, and many more are under development. Web Services Policy enables Web services to recognize and act on the conditions for an interaction, and is required by other standardization efforts.

Scope:

The Web Services Policy Working Group is chartered to standardize a general policy framework for expressing Web service capabilities and requirements. The framework consists of a policy data model for expressing capabilities and requirements of a Web Service, a processing model for combining and comparing Web service capabilities and requirements and an XML Information Set representation for the policy data model. The parts of the framework are described as follows:

  1. A policy data model to allow the expression of consistent combinations of capabilities and requirements of a Web service. The policy data model defines a policy comprised of zero or more policy alternatives. Each policy alternative is comprised of zero or more policy assertions. Each policy assertion has a type and is comprised of nested policy, and parameters. A policy with zero policy alternatives has no admissible capabilities or requirements. A policy alternative with zero policy assertions has no capabilities or requirements.
  2. A processing model for combining and comparing Web service capabilities and requirements. The processing model operates on the policy data model and defines merging and intersecting policies, policy alternatives, and policy assertion types and nested policies. The processing model does not define combining or comparing of policy assertion parameters.
  3. An XML Information Set representation (also known as policy expression) of the policy data model defining:
    1. A representation for operators (All and ExactlyOne) to denote consistent combinations of policy assertions, a normal form that maps directly to the policy data model, arbitrary nesting of the operators, and an algorithm to convert arbitrary nesting into the normal form.
    2. A mechanism to denote that a policy assertion is optional and an algorithm to convert this into the normal form.
    3. A representation for policy assertion type and nested policy; there should be no constraints on the Information Set for policy assertion parameters.
    4. A means to identify policy expressions.
    5. A means to include one policy expression within another policy expression.
  4. The policy data model, processing model and policy expression shall be designed to be independent of any attachment mechanism.

The Web Services Policy Working Group is also chartered to standardize mechanisms for associating policy expressions with Web Service constructs. These mechanisms consist of items 5-9 below. The Web Services Policy Working Group may choose to vary the number of specification documents and their titles for these mechanisms for associating policy expressions with Web service constructs.

  1. A model for attaching policies to WSDL 1.1 and WSDL 2.0 constructs. The model defines:
    1. A partitioning of WSDL constructs into message, operation, endpoint, and service policy subjects.
    2. The semantics of attaching a policy to each policy subject.
    3. How to combine policies attached to more than one WSDL component within a single policy subject.
  2. An XML representation of policy expressions attached to WSDL 1.1 and WSDL 2.0 constructs and annotating those policy expressions as required extensions using the WSDL-defined extensibility flag @wsdl:required.
  3. A model for attaching policies to UDDI v2 and UDDI v3 entities. The model defines:
    1. A partitioning of UDDI constructs into service provider, service, and endpoint policy subjects.
    2. The semantics of attaching a policy to each policy subject.
    3. How to combine policies attached to more than one UDDI entity within a policy subject.
  4. A set of tModels for referencing and registering policy expressions in UDDI v2 and UDDI v3.
  5. A general-purpose mechanism for external policy attachment.

Web Services Policy should remain compatible with existing policy assertions and offer a smooth migration path for these assertions (where applicable). Existing policy assertions (in specifications that have been submitted to other standards groups) are Web Services Reliable Messaging Policy, Web Services Security Policy, Web Services Atomic Transaction, and Web Services Business Activity Framework.

The Web Services Policy Working Group will use the latest versions of Web Services Policy Framework and Web Services Policy Attachment as the basis for its deliverables.

Principal References
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2007-11-20-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org