Page History

...

Policy-aware interceptors extract the collection of AssertionInfo objects for the assertion types they understand from the AssertionInfoMap in the message. They can then use the wrapped Assertion objects to fine tune their behaviour, possibly exhibiting message type specific behaviour, and finally express whether or not they could support these assertions. Given an assertion type that has attributes, and assuming there are two instances of assertions of this type, it is possible that the interceptor can assrt one, but not the other assertion. In any case, inability to support all assertions understood by the interceptor does not necessarily indicate a failure. As mentioned above in relation to pre-emptive interceptor installation, it is possible that the ones that cannot be supported do not in fact apply to the underlying message at all.
Typically the interceptor would strive at supporting as many of these assertions as possible however, and for that purpose it may avail of the AssertionBuilder's capability to compute a compatible policy. For example, by scheduling an acknowledgement to be sent in 3 seconds, an RM interceptor would support both of the following RMAssertions:

<wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
    <wsrmp:AcknowledgementInterval Milliseconds="30000"/>
</wsrmp:RMAssertion>
<wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
    <wsrmp:AcknowledgementInterval Milliseconds="50000"/>
</wsrmp:RMAssertion>

Verification

Another set if of interceptors installed by the policy framework are respoisble is responsible for verifying that one of the alternatives in the effective policy of the underlying message could is indeed be supported. These are:

Their behaviour is (if applicable at all) symmetric on client and server side.
On the outbound chain the effective message policy was known by the time the policy interceptor executing in the SETUP phase had inserted the AssertionInfoMap into the message. Asthis was built exclusively from the Assertion objects that form part of the chosen alternative for the effective message policy, all of them must be supported. In other words, all of the AssertionInfo objects in the need to be in the asserted state. If one of them is not, the interceptor throws a Fault (wrapping a PolicyException).

On the inbound paths a little bit more wotk is necessary: If the message is a fault, we know by now what type of fault it is and what operation it applies to, otherwise we know the underlying operation and can, from the location of the interceptor (client or server side) infer the message subject (input or output message). Either way, all information is now available to obtain the effective message policy. To check if any of is alternative is supported, the policy verification interceptors simply verify that for each of the assertions in the alternative under test the associated AssertionInfo object is in the assrted state. If it turns out that no alternative is supported, the interceptor throws a Fault (wrapping a PolicyException).