WS-Policy

WS-Policy is a specification of the W3C as part of the WS-* specifications, which enables the service provider to provide the guidelines for safety, quality and version of its service in the form of machine-readable XML data for the service users. Conversely, the service user 's requirements also specify in the form of XML data. These policies are then inserted at appropriate places in the WSDL description of the service ( or in the BPEL process ) and are considered as minimum guidelines for all in the hierarchy deeper standing elements. Conversely, a service user 's request to a service in the form of policies formulated so that has to be " negotiated " at runtime then, what then is the effective Policy.

Sub-specifications

For WS-Policy includes several sub-specifications:

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 way in which policies can be linked to existing technologies in the field of web services. Optionally, they can be declared directly within the element to which they relate, or are only referenced and also separately.

Development of policies

A policy always consists of one element:

This element always contains a list of alternatives, so for example, could require a bank web service that the transfer has to be done encrypted while offering concrete alternatives DES and AES. A user of the service would therefore have to use the service at all, encrypt the data in each case with one of the two methods. Another method would not be permitted. Each alternative may consist of any number of assertions.

A collection of policy alternatives always consists of an element or an element . The former case means that of all the alternatives contained in exactly one must be true, the latter with means that all the alternatives mentioned therein must be fulfilled. These two elements can be further nested within itself. However, agreement has been reached on a normal form for ease of processing of policies, thus resulting in the following structure:

                           < - List of assertions ->                                < - List of assertions ->                                < - List of assertions ->                   < - any number of other elements of the type wsp: All - >      There is only one alternative, the element can of course be omitted; the same applies to if an alternative would consist of only one assertion.

Types of use

Each assertion has an optional attribute wsp: Usage, indicating how this assertion is to be used. The following possible values ​​it may be:

  • Required: The assertion is applied in each case. If they are violated, an error is raised.
  • Rejected: The assertion is explicitly not supported. Should they still be called, an error is raised.
  • Optional: The assertion must not be used, but it is, if it exists.
  • Observed: the assertion is applied in each case.
  • Ignored: The assertion is processed but ignored, ie, it can be noted, but has no influence on the further processing. Both service providers and users are informed that they will be ignored.

Effective Policy

Both service providers and service users to specify policies. This has the consequence that the effective policy can be negotiated only at run time. Exact algorithms that determine the effective policy on the basis of the two requirements, are still the subject of current research. First of all, it will always act in the effective policy for the " lowest common denominator " of the respective requirements. However, it is still open, as there is also a semantic analysis of the policy is to take place, since WS-Policy defines only the external form of a policy and not about the content says more about how the content should be coded.

Comments

  • A policy can also be empty ( no alternatives included).
  • The alternatives are disordered.
  • Alternatives in a policy can be both very similar and completely different ( ie, the same assertion can occur in several alternatives ).
  • WS-Policy dictates how policies are to be connected by providers and users. The semantics is ignored, for example, the following effective policy would be possible:

          history

  • December 2002 presented by BEA, IBM, Microsoft and SAP
  • Updated May 2003
  • September 2004 updated in collaboration with Sonic and Verisign
  • March 2006 updated again
  • Published September 2007 as a W3C Recommendation
Web Services Description Language Advanced Encryption Standard Sonic Solutions
829652
de