WS-Policy

from Wikipedia, the free encyclopedia

WS-Policy is a specification of the W3C within the framework of the WS- * specifications, which enables the service provider to provide the service user with the guidelines regarding the security, quality and version of his service in the form of machine-readable XML data. Conversely, the service user can also specify his requirements in the form of XML data. These policies are then inserted at the appropriate points in the WSDL description of the service (or in the BPEL process) and apply as minimum guidelines also for all elements lower in the hierarchy. Conversely, a service user can also formulate his requirements for a service in the form of policies, so that what will become the effective policy must then be “negotiated” at runtime.

Sub-specifications

There are several sub-specifications associated with WS-Policy:

WS-Policy Assertions

WS-Policy Assertions describes a set of standard guidelines that can be used within a policy.

WS-Policy Attachment

WS-Policy Attachment describes the form in which policies can be linked to existing technologies from the field of web services . Optionally, they can be declared directly within the element to which they refer, or they can also be declared separately and only referenced.

Structure of policies

A policy always consists of one element: 

<wsp:Policy xmlns:wsp="someURI">

This element always contains a list of alternatives, for example a bank web service could stipulate that the transmission must be encrypted and offer the specific alternatives DES and AES . A user of the service would therefore have to encrypt the data with one of the two methods in order to be able to use the service at all. No other procedure would be permitted. Each alternative can consist of any number of assertions. A list of policy alternatives always consists of one element <wsp:ExactlyOne>or one element <wsp:All>. The first case means that exactly one of all the alternatives contained therein must apply, the second means that all the alternatives mentioned therein must be fulfilled. These two elements can also be further nested within themselves. However, a normal form has been agreed for easier processing of policies, resulting in the following structure: 

<wsp:Policy>
    <wsp:ExactlyOne>
        <wsp:All>
            <!--Liste von Assertions-->
        </wsp:All>
        <wsp:All>
            <!--Liste von Assertions-->
        </wsp:All>
        <wsp:All>
            <!--Liste von Assertions-->
        </wsp:All>
        <!--beliebig viele weitere Elemente vom Typ wsp:All-->
    </wsp:ExactlyOne>
</wsp:Policy>

If there is only one alternative, the element can of <wsp:ExactlyOne>course be omitted; the same applies <wsp:All>if an alternative would only consist of an assertion.

Types of use

Each assertion has an optional attribute wsp:Usagethat indicates how that assertion should be used. A distinction is made between the following possible values:

  • Required: The assertion is used in any case. If it is violated, an error is triggered.
  • Rejected: The assertion is explicitly not supported. If it is requested anyway, an error is triggered.
  • Optional: The assertion does not need to be used, but it will if it is present.
  • Observed: The assertion is used in any case.
  • Ignored: The assertion is processed but ignored, i.e. In other words, it can be specified, but has no influence on further processing. Both service providers and users are informed that it will be ignored.

Effective policy

Both service providers and service users can specify policies. As a result, the effective policy can only be negotiated at runtime. More precise algorithms that determine the effective policy based on the two requirements are still the subject of current research. First of all, the effective policy will always be the "lowest common denominator" of the respective requirements. However, it is still unclear how a semantic evaluation of the policy should take place, since WS-Policy only defines the external form of a policy and says nothing about the content or how the content should be coded.

Remarks

  • A policy can also be empty (no alternatives included).
  • The alternatives are disorganized.
  • Alternatives in a policy can be both very similar and completely different (i.e. the same assertion can occur in several alternatives).
  • WS-Policy prescribes how policies from provider and user should be linked. However, the semantics are ignored, e.g. the following effective policy would be possible:
<wsp:Policy>
    <SomeAssertion apply="true"/>
    <SomeAssertion apply="false"/>
</wsp:Policy>

history

  • December 2002 presented by BEA , IBM , Microsoft and SAP
  • Updated May 2003
  • Updated September 2004 with the collaboration of Sonic and Verisign
  • March 2006 updated again
  • Submitted to W3C April 2006 so that a working group could be set up
  • Published September 2007 as a W3C Recommendation

Web links