Page History

...

It gets more complicated when we consider operation or even message policies. As we have determined the operation (and its parts) only after unmarshalling, we can calculate the effective policy for the operation/message also only at this point. On the other hand, at this point we must have already executed some of the policy related interceptors, i.e. all those that read headers like the addressing and RM SOAP interceptors. Another complicating factor is that in the case of multiple policy alternatives the server has no direct knowledge about which alternative was actually chosen by the client.
The first problem can be worked around by preemptively adding the interceptors for all AssertionBuilders for the policy vocabulary used by the endpoint are added to the chain: Generalizing the definitions in the WS-Policy specification we can define the vocabulary of an endpoint to be the merged vocabulary of the policies of its operations. Example: the RM interceptors would be added to the chain even if only some of the operations on the endpoint should be reliable, and these interceptors should be made robust w.r.t. to the absence of associated headers (respective changes required in the currently implemented addressing and RM interceptors are trivial) - they simply pass the message through.
We can weaken this to initially only add such interceptors if they belong to one of the pre-MARSHALLING phases, e.g. in that case the RMSoapInterceptor. Other interceptors can be added at a later stage, [once the operation is known and according to policy vocabulary used for that operation or message.
Finally, we can only determine which requirements have been asserted at the end of the interceptor chain: the execution of an interceptor alone is not enough, nor is the presence of specific headers (although for well designed policies this should be enough). It is possible that we have to look at the header (or even message) content to check for a specific assertion. So, in order to decide at the end of the chain if everything that should have been asserted actually was asserted, we need to keep track of what was asserted by the individual interceptors. How can we do this?
At the end of the inbound chain, a PolicyVerificationInterceptor first of all computes the effective policy for that operation/message. It then iterates backwards over all interceptors executed thus far and checks which of them implement the AssertionBuilder interface, and thus can decide if the requirement for a particular assertion has been met. The candidates get then passed the set of assertions of the types known to them and return the subset of these assertions that they can assert. Now, the PolicyVerificationInterceptor can decide if all required assertions for any of the effective policy's alternatives are supported. If this is not the case, the interceptor throws an Exception.
This process can be sped up by initialising a message property with an empty list of AssertionBuilders, to which each interceptor that wants to participate in the final decision process can contribute itself (avoiding the instanceof AssertionBuilder).
The transport may be included in this decision process if it also implements the AssertionBuilder interface (see discussions on cxf-dev on class #1/class #2 assertions) (here the type check cannot be avoided though). h.2

Supported Versions

There are several versions of the WS-Policy Framework and WS-Policy Attachment specifications out there at the moment, not sure which one(s) CXF should aim to support:

...

Version 1.2 is the one supported by Neethi. Version 1.5 covers attachment in WSDL 2.0.h.2

APIs

The following are tentative suggestions for the APIs as part of the CXF policy framework.h.3

AssertionBuilder

The AssertionBuilder API is a concept from Neethi (slightly modified below as):

...

AssertionBuilder implementations are loaded by the <Spring container> and register themselves with the AssertionBuilderRegistry, which is a Bus extension. h.3

Assertor

public interface Assertor {
  // return the subset of assertions that this assertor can assert
   List<Assertion> assert(List<Assertion> candidates);
}

This API would be used in the PolicyVerificationInterceptor to check which of the assertions have been asserted in order to decide if any of the policy alternatives of the effective policy is supported.
Interceptors like the RM interceptor would implement this interface, but also perhaps some transports.h.4

AssertionInterceptorProvider

This is simply an extension of the InterceptorProvder interface:

...