Section 7.1. Motivation for WS-Policy


7.1. Motivation for WS-Policy

The need for an interoperable, standardized representation of nonfunctional capabilities and requirements of service endpoints should be clear, in view of the discussion in the previous section. It is necessary, however, that you understand why WS-Policy was created as a separate specification from WSDL, which already provides the basis for functional service descriptions. There are three major reasons for this.

First, there is the benefit of clearly separating concerns, avoiding a single monolithic specification to deal with all the diversity of service description information. WSDL has a clear focus on functional descriptions. Nonfunctional descriptions and quality of service aspects are naturally dealt with in a composeable, reusable specification, such as WS-Policy. Additional service description aspects, such as semantics, are best left to a different description language (such as OWL-S).

Second, the use of policies is not limited to service endpoints, but encompasses a variety of possible subjects, even when considering the service-oriented environment. XML documents, stateful resources of every kind, reliable messaging sessions, and so on can be legitimate subjects on which policies will need to be asserted to ensure interoperability among services. For this reason, WS-Policy strives to provide a flexible, extensible policy attachment mechanism for associating policies with subjects. WSDL is concerned only with service endpoints.

The flexibility of the attachment mechanism satisfies a third requirement that WSDL is not designed to support. That requirement involves representing the incremental addition of capabilities to an existing service. From a development and systems management perspective, it is common to incrementally modify a service offering by endowing it with additional capabilities available within a deployment environment. For example, confidentiality, authentication, support for reliable messaging protocols, and so on might be added to a service without impacting an application. In this way, services can be positioned to offer different qualities of service to different targeted audiences. In those cases, the service description also needs to be updated. WS-Policy Attachments provides support to flexibly add policies to preexisting services.

To fulfill this vision, WS-Policy must be able to encode capabilities and requirements that are derived from any discipline or application domain. Because of this, WS-Policy is intrinsically extensible, relying on discipline-specific assertions to represent discipline-specific properties, such as security policies, transaction policies, and business-specific policies. Domain experts, such as industry or standard groups, will define these domain dialects, which will then be used within the WS-Policy framework, leveraging a common, domain-independent processing model.

The simplicity of assertion expressions does not preclude additional semantics being defined for policy domains through technology such as Resource Description Framework (RDF) and the Web Ontology Language (OWL). The Web services community is interested in adding semantics to WSDL. Semantics for policy domains could also annotate policy assertions, allowing a policy container to aggregate a set of related assertions for a particular endpoint.

Web services policies are relevant in several scenarios. Following are three of particular relevance:

  • Development and deployment of interoperable service requester applications Together with WSDL, WS-Policy provides a declarative description of the requirements that services make on requesters, which guide the development and deployment of those applications.

  • Service discovery and selection WS-Policy descriptions enable service requesters to locate services based on their nonfunctional capabilities in addition to their functional properties. This way, it is possible to locate services that provide a given level of security or support for specific reliability guarantees.

  • Dynamic update of requester configuration Interacting endpoints can exchange policies using the WS-MetadataExchange port types. This way, services can update their configuration at runtime and customize each specific interaction. Requesters then retrieve updated policy information from the service provider and use it to reconfigure their runtime accordingly.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net