You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The WS-Policy framework in CXF provides infrastructure and APIs that allows CXF users and developers to use WS-Policy. It is compliant with the November 2006 draft publications of the Web Services Policy 1.5 - Framework and
Web Services Policy 1.5 - Attachment specifications.

Core

The framework consists of a core which is responsible for:

  • retrieval of policies from different sources (wsdl documents, external attachment documents)
  • computation of effective policies for service, endpoint, operation and message subjects
  • on-the-fly provision of interceptors based on the effective policies for a particular message
  • verification that one of the effective policy's alternative is indeed supported.

The core uses Apache Neethi to provide the functionality of policy merging and normalisation, but comes with its own implementation of policy intersection.

APIs

The framework also defines APIs that allow developers to add pluggable support for their own domain assertions. These are:

AssertionBuilder

The AssertionBuilder API is a concept from Neethi, slightly modified so as to avoid the dependency on the Axis object model and extended in order to support domain specific behaviour of intersecting and comparing such assertions.

public interface AssertionBuilder {
   // build an Assertion object from a given xml element
   Assertion build(Element element);
  // return the schema type names of assertions understood by this builder
  Collection<QName> getSupportedTypes();
  // return an Assertion object that is compatible with the specified assertions
  Assertion buildCompatible(Assertion a, Assertion b);
}

AssertionBuilder implementations are loaded dynamically and register themselves with the AssertionBuilderRegistry, which is available as a Bus extension.

PolicyInterceptorProvider

This API is used to automatically engage interceptors required to support domain specific assertions at runtime, thus simplifying interceptor configuration a lot.

public interface PolicyInterceptorProvider extends InterceptorProvider {
  // return the schema types of the asssertions that can be supported
  Collection<QName> getAssertionTypes()
}

In addition, there is an API to refine domain expression(s) (xml elements describing policy subjects within a policy scope) in policy attachments.

Interaction with Other Components

A component's interaction with the policy framework typically consists in

  1. retrieving the assertions pertaining to the underlying message (i.e. the ones known to the component) so the component can operate on the message accordingly
  2. confirmation that the assertions pertaining to the underlying message could indeed be supported by component.
    The framework itself is, as most CXF features, interceptor based. Thus, most interaction with the framework is indirect through the Message object: Policy interceptors make AssertionInfo ojects available to subsequently executing, policy-aware interceptors such as the WS-Addressing and WS-RM interceptors. These interceptors extract the AssertionInfo from the Message, retrieve the wrapped Assertion object and express the fact they they do (or don't) support that Assertion in the AssertionInfo object.

Some components needs to integrate more tightly with the policy framework however: this is the case when a conduit or a destination want to participate in the assertion process. An example for this is the HTTP conduit and destination, which support assertions of element type HTTPClientPolicy and HTTPServerPolicy. These obtain the Assertion information pertaining to the current message exchange from the PolicyEngine (which is also available as a bus extension), to perform step 1.

  • No labels