THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Role | Chain | Phase | Interceptor | Effective Subject Policies Known |
|---|---|---|---|---|
Client | Out | SETUP | ClientPolicyOutInterceptor | Service, Endpoint, Operation, (Input) Message |
Client | In | RECEIVE | ClientPolicyInInterceptor | Service, Endpoint |
Client | InFault | RECEIVE | ClientPolicyInFaultInterceptor | Service, Endpoint |
Server | In | RECEIVE | ServerPolicyInInterceptor | Service, Endpoint |
Server | OutFault | SETUP | ServerPolicyOutFaultInterceptor | Service, Endpoint, Operation, (Fault) Message |
Server | Out | SETUP | ServerPolicyOutInterceptor | Service, Endpoint, Operation, (Out) Message |
You can see how it designed on the following figure:
The main purpose of these policy interceptors 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 time the policy interceptor executes (because the operation is not yet known at that time).
If 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.
When 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 all alternatives 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 the unasserted assertions apply to operation sayHi when in fact the chain has been processing the message for a greetMe request!
You can see how it designed on the following figure:
Briefly, policy interceptors make following steps:
...