|
7.1. Motivation for WS-PolicyThe 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:
|
|