Page History

...

When computing the effective policy for an endpoint or a message, the framework also chooses one of the effective policy's alternatives. Currently, it choses the first alternative that in principle can in which all assertions may be supported either by interceptors (i.e. for which there is a PolicyInterceptorProvider for the assertion type) or by the conduit/destination (if this implements the Assertor interface and via its canAssert method expresses the fact that it can support the assertion type). Note that, even if such an alternative can be found, this does not necessarily mean that the alternative is supported: While an interceptor may in principle be able to support a specific type of assertions, it may not actually support an individual instance of that assertion type.

The choice of alternative is chosen. This choice, along with the set of interceptors (obtained from the PolicyInterceptorProviders in the PolicyInterceptorProviderRegistry), is cached along with the actual effective message or endpoint policy in the form of an EffectivePolicy or EffectiveEndpointPolicy object. In the case of an effective endpoint policy, interceptors are chosen in such a way that the assertions in the chosen alternative of the effective endpoint policy can be supported, but also any assertion in any alternative of any of the operation and message specific policies. This is necessary in situations where the underlying message is not known, for example on the server inbound path: Once an alternative has been chosen for the effective policy of the server's endpoint we know which assertions must definitely be supported, regardless the underlying message/operation. Additional interceptors that are necessary to support the assertions that only appear in specific operation or input message policies are added pre-emptively. Note that this relies on interceptors being coded defensively - good practice anyway but especially so for interceptors returned by PolicyInterceptorProviders!

...

Their main function purpose is to add further interceptors that are required to support the effective policy of the underlying message - even if that policy is not yet known at the point the interceptor executes (because the operation is not yet known).
In case where the effective message policy is known, the assertions of its selected alternative are inserted into the message in the form of an AssertionInfoMap. This is a map, keyed by assertion type name, of collections of AssertionInfo objects, the latter being stateful (asserted/not asserted) representations of Assertion objects.
Where the effective message policy is not known, not only the assertions for the selected alternative in the effective endpoint policy are included in the AssertionInfoMap, but also all assertions in assertion in all alternative of all of the operation and message specific policies. Not all of these will be asserted at the end of the chain, but that is fine if it turns out they do the unasserted assertions apply to operation sayHi when in fact we have been processing a an inbound greetMe request!

Policy Aware Interceptors

...