Page History

...

On the inbound paths a little bit more wotk work 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).

One thing worth noting is that - both on outbound and inbound chains - there may be AssertionInfo elements in the map whose assertions can only be supported by the conduit or destination. Although conduit or destination had the opportunity to access Assertion objects and tailor their behaviour when sending or receiving the current message, we don't know at this point of this "tailoring" actually succeeded, i.e. whether or not the assertions that were considered could actually be supported. For this reason, the policy verification interceptors check if the conduit (on the client side) or the destination (on the server side) implement the Assertor interface, and if so, pass them the Message object so they can record the outcome in the corresponding AssertionInfo objects in the AssertionInfoMap. Only after this has happened will the state information contained in the AssertionInfoMap be processed as described above.