Google Git
Sign in
apache / cxf-site / refs/heads/asf-staging / . / content / docs / how-it-works.html
blob: 5e82553a67c19ed8dbcf465979a3b7d0cee07c66 [file] [log] [blame]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<html>
<head>
<link type="text/css" rel="stylesheet" href="/resources/site.css">
<script src='/resources/space.js'></script>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
<meta name="keywords" content="business integration, EAI, SOA, Service Oriented Architecture, web services, SOAP, JBI, JMS, WSDL, XML, EDI, Electronic Data Interchange, standards support, integration standards, application integration, middleware, software, solutions, services, CXF, open source">
<meta name="description" content="Apache CXF, Services Framework - How It Works">
<link type="text/css" rel="stylesheet" href="/resources/highlighter/styles/shCoreCXF.css">
<link type="text/css" rel="stylesheet" href="/resources/highlighter/styles/shThemeCXF.css">
<script src='/resources/highlighter/scripts/shCore.js'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
</script>
<title>
Apache CXF -- How It Works
</title>
</head>
<body onload="init()">
<table width="100%" cellpadding="0" cellspacing="0">
<tr>
<td id="cell-0-0" colspan="2">&nbsp;</td>
<td id="cell-0-1">&nbsp;</td>
<td id="cell-0-2" colspan="2">&nbsp;</td>
</tr>
<tr>
<td id="cell-1-0">&nbsp;</td>
<td id="cell-1-1">&nbsp;</td>
<td id="cell-1-2">
<!-- Banner -->
<div class="banner" id="banner"><div><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td align="left" colspan="1" nowrap>
<a shape="rect" href="http://cxf.apache.org/" title="Apache CXF"><span style="font-weight: bold; font-size: 170%; color: white">Apache CXF</span></a>
</td><td align="right" colspan="1" nowrap>
<a shape="rect" href="http://www.apache.org/" title="The Apache Sofware Foundation"><img border="0" alt="ASF Logo" src="http://cxf.apache.org/images/asf-logo.png"></a>
</td></tr></table></div></div>
<!-- Banner -->
<div id="top-menu">
<table border="0" cellpadding="1" cellspacing="0" width="100%">
<tr>
<td>
<div align="left">
<!-- Breadcrumbs -->
<a href="index.html">Index</a>&nbsp;&gt;&nbsp;<a href="ws-support.html">WS-* Support</a>&nbsp;&gt;&nbsp;<a href="ws-policy.html">WS-Policy</a>&nbsp;&gt;&nbsp;<a href="how-it-works.html">How It Works</a>
<!-- Breadcrumbs -->
</div>
</td>
<td>
<div align="right">
<!-- Quicklinks -->
<div id="quicklinks"><p><a shape="rect" href="http://cxf.apache.org/download.html">Download</a> | <a shape="rect" href="http://cxf.apache.org/docs/index.html">Documentation</a></p></div>
<!-- Quicklinks -->
</div>
</td>
</tr>
</table>
</div>
</td>
<td id="cell-1-3">&nbsp;</td>
<td id="cell-1-4">&nbsp;</td>
</tr>
<tr>
<td id="cell-2-0" colspan="2">&nbsp;</td>
<td id="cell-2-1">
<table>
<tr valign="top">
<td height="100%">
<div id="wrapper-menu-page-right">
<div id="wrapper-menu-page-top">
<div id="wrapper-menu-page-bottom">
<div id="menu-page">
<!-- NavigationBar -->
<div id="navigation"><ul class="alternate"><li><a shape="rect" href="overview.html">Overview</a></li><li><a shape="rect" href="how-tos.html">How-Tos</a></li><li><a shape="rect" href="frontends.html">Frontends</a></li><li><a shape="rect" href="databindings.html">DataBindings</a></li><li><a shape="rect" href="transports.html">Transports</a></li><li><a shape="rect" href="configuration.html">Configuration</a></li><li><a shape="rect" href="debugging-and-logging.html">Debugging and Logging</a></li><li><a shape="rect" href="tools.html">Tools</a></li><li><a shape="rect" href="restful-services.html">RESTful Services</a></li><li><a shape="rect" href="wsdl-bindings.html">WSDL Bindings</a></li><li><a shape="rect" href="service-routing.html">Service Routing</a></li><li><a shape="rect" href="dynamic-languages.html">Dynamic Languages</a></li><li><a shape="rect" href="ws-support.html">WS-* Support</a></li><li><a shape="rect" href="advanced-integration.html">Advanced Integration</a></li><li><a shape="rect" href="deployment.html">Deployment</a></li><li><a shape="rect" href="schemas-and-namespaces.html">Use of Schemas and Namespaces</a></li></ul><hr><ul class="alternate"><li><p>Search</p></li></ul><form enctype="application/x-www-form-urlencoded" method="get" id="cse-search-box" action="http://www.google.com/cse">
<div>
<input type="hidden" name="cx" value="002890367768291051730:o99qiwa09y4">
<input type="hidden" name="ie" value="UTF-8">
<input type="text" name="q" size="21">
<input type="submit" name="sa" value="Search">
</div>
</form>
<script type="text/javascript" src="http://www.google.com/cse/brand?form=cse-search-box&amp;lang=en"></script><hr><ul class="alternate"><li><a shape="rect" href="http://cxf.apache.org/javadoc/latest/">API 3.2.x (Javadoc)</a></li><li><a shape="rect" href="http://cxf.apache.org/javadoc/latest-3.1.x/">API 3.1.x (Javadoc)</a></li><li><a shape="rect" href="http://cxf.apache.org/">CXF Website</a></li></ul><p>&#160;</p><p><a shape="rect" class="external-link" href="http://www.apache.org/events/current-event.html"><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image confluence-external-resource" src="http://www.apache.org/events/current-event-125x125.png" data-image-src="http://www.apache.org/events/current-event-125x125.png"></span></a></p></div>
<!-- NavigationBar -->
</div>
</div>
</div>
</div>
</td>
<td height="100%">
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><h2 id="HowItWorks-RetrievalofPolicies">Retrieval of Policies</h2>
<p>Policies are associated with policy subjects. In the web services context, there are four different subjects:</p>
<ul><li>Service</li><li>Endpoint</li><li>Operation</li><li>Message</li></ul>
<p>Using WSDL 1.1, the policy-subject association usually takes the form of <strong>xml element attachment</strong>: A wsp:Policy element (the wsp prefix denotes the <a shape="rect" class="external-link" href="http://www.w3.org/2006/07/ws-policy" rel="nofollow">http://www.w3.org/2006/07/ws-policy</a> namespace) is attached to a WSDL element such as wsdl:port. Alternatively, a wsp:PolicyReference elements is attached to a wsdl element. In that case, the actual wsp:Policy element can reside outside of the wsdl. <br clear="none">
Note that subjects do not correspond to wsdl elements directly. Rather, they map to a set of wsdl elements (see below). For example wsdl:port, wsdl:portType and wsdl:binding elements together describe the endpoint as a subject.</p>
<p>Another form of associating policies with policy subjects is <strong>external attachment</strong>: wsp:PolicyAttachment elements, which can reside in arbitrary locations, explicitly specify the subject(s) they apply to in their AppliesTo child element.</p>
<p>In CXF, elements attached to a wsdl element are available as extensors in the service model representation of that wsdl element. wsp:Policy or wsp:PolicyReference elements can be obtained as extensors of type UnknownExtensibilityElement in which the element name matches that of the wsp:Policy or wsp:PolicyReference element. Note that these attached elements are not parsed when the service model is built.<br clear="none">
With xml element attachment in WSDL 1.1, given a Message object, wsp:Policy elements attached to the endpoint or message subject can therefore be obtained by navigating the service model starting with the OperationInfo and/or EndpointInfo object stored in the message (or in the exchange).</p>
<p>The location of documents containing PolicyAttachment documents on the other hand needs to be made known to the framework. This can easily be achieved through configuration, see <a shape="rect" href="wspconfiguration.html">Specifying the Location of External Attachments</a>.</p>
<p>PolicyAttachments are flexible w.r.t. the type of domain expressions. Domain expressions are used to identify entities such as endpoints, operations or messages with which a policy can be associated:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default">
&lt;wsp:PolicyAttachment&gt;
&lt;wsp:AppliesTo&gt;
&lt;x:DomainExpression/&gt; +
&lt;/wsp:AppliesTo&gt;
(&lt;wsp:Policy&gt;...&lt;/wsp:Policy&gt; |
&lt;wsp:PolicyReference&gt;...&lt;/wsp:PolicyReference&gt;)
&lt;/wsp:PolicyAttachment&gt;
</pre>
</div></div>
<p>Currently, CXF supports only domain expressions of type wsa:EndpointReferenceType: They allow to associate the policies or policy references in an attachment with an endpoint (by means of matching the endpoint's address with that in the EndpointReferenceType element). It is not possible however to associate a Policy with an operation or a message this way.<br clear="none">
Support for other types of domain expressions can be plugged in by implementing the DomainExpressionBuilder interface and adding a corresponding bean to your configuration file (all DomainExpressionBuilder instances loaded that way will automatically register with the DomainExpressionBuilder and thus be considered in the process of parsing PolicyAttachment elements).</p>
<p>Once that the framework knows where to look for wsp:Policy elements, it can parses these elements and creates runtime presentations for them. This is where AssertionBuilders come into play: All child elements of a wsp:Policy element that are not in the wsp namespace are considered to be assertions. The framework will use its AssertionBuilderRegistry to find an AssertionBuilder registered for the element type in question and, if it finds one, proceed to build an Assertion object from that element (or else throw a PolicyException).</p>
<h2 id="HowItWorks-ComputationofEffectivePolicies">Computation of Effective Policies</h2>
<p>As mentioned above, policies are associated with policy subjects. With WSDL 1.1, the effective policy for a subject is the aggregation, or the <strong>merge</strong>, of the policies attached to the wsdl elments representing that subject: <br clear="none">
The effective policy for a service subject is the merge of all policies applying to the wsdl:service element.<br clear="none">
The effective policy for an endpoint subject is the merge of all policies applying to the wsdl:port, wsdl:portType and wsdl:binding elements.<br clear="none">
The effective policy for an operation subject is the merge of all policies applying to the wsdl:portType/wsdl:operation and wsdl:binding/wsdl:operation elements.<br clear="none">
The effective policy for a (input | output | fault) message subject is the merge of all policies applying to the wsdl:message, (wsdl:portType/wsdl:operation/wsdl:input | wsdl:portType/wsdl:operation/wsdl:output | wsdl:portType/wsdl:operation/wsdl:fault) and (wsdl:binding/wsdl:operation/wsdl:input | wsdl:binding/wsdl:operation/wsdl:output | wsdl:binding/wsdl:operation/wsdl:fault).</p>
<p>Additional aggregation takes place to determine the effective policy of an endpoint: <br clear="none">
The effective policy for a service is the effective policy for the service subject.<br clear="none">
The effective policy for an endpoint is the merge of the effective policies for the service subject and the endpoint subject.<br clear="none">
The effective policy for an operation is the merge of the effective policies for the service subject, the endpoint subject and the operation subject.<br clear="none">
The effective policy for a (input | output | fault) message is the merge of the effective policies for the service subject, the endpoint subject, the operation subject and the message subject.</p>
<p><img class="emoticon emoticon-information" src="https://cwiki.apache.org/confluence/s/9h3cbz/8703/189cb2l/_/images/icons/emoticons/information.svg" data-emoticon-name="information" alt="(info)"> <strong>Multiple sources</strong> can be used to apply policies to the same subject. In the case of an endpoint subject for example, its associated wsdl:port element can have multiple wsp:Policy child elements. Also, a separate document can contain wsp:PolicyAttachment elements in which the AppliesTo children identify the endpoint in question as the target subject. Both the Policies attached to the port element as well as those in the matching PolicyAttachment elements will then contribute to the effective policy of the endpoint subject.</p>
<p><img class="emoticon emoticon-information" src="https://cwiki.apache.org/confluence/s/9h3cbz/8703/189cb2l/_/images/icons/emoticons/information.svg" data-emoticon-name="information" alt="(info)"> It is also important to keep in mind that the aggregation process described above makes it possible for an effective policy to have <strong>multiple assertion elements of the same type in one alternative</strong> (although this would not be considered the normal case). Different assertions of the same type within the same alternative do <strong><em>not</em></strong> overwrite each other. In fact, if used inappropriately, they may contradict each other. But it is also possible that they complement each other. Either way, the framewwork does not remove such duplicates and instead leaves it to the interceptors (or other Assertors) involved in the assertion process to decide if they can meaningfully deal with multiple assertions of the same type.</p>
<p>It is obvious that the above aggregation process can be quite resource intense. Effective policies for messages and endpoints are therefore cached by the framework for future reference. The entity that manages the cache of effective policies is the PolicyEngine. </p>
<p>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 in which all assertions <strong><em>may</em></strong> be supported, either by interceptors (i.e. there is a PolicyInterceptorProvider for the assertion type) or by the conduit/destination (if this implements the Assertor interface and through its canAssert method confirms that it can support the assertion type). However, even if such an alternative can be found, the chosen alternative is not necessarily supported: An interceptor may in principle be able to support a specific type of assertions, but it may not actually be able to support an individual instance of that assertion type.</p>
<p>The choice of alternative, 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 generally requires interceptors to be coded defensively - good practice anyway but especially so for interceptors returned by PolicyInterceptorProviders!</p>
<h2 id="HowItWorks-On-the-flyProvisionofInterceptors">On-the-fly Provision of Interceptors</h2>
<p>The policy framework, when activated (by loading the PolicyEngine and setting its "enabled" attribute to true), installs a couple of interceptors at bus level which execute early on in their respective interceptor chains:</p>
<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p> Role </p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Chain</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Phase </p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Interceptor </p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Effective Subject Policies Known </p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Client </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Out </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> SETUP </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> ClientPolicyOutInterceptor </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Service, Endpoint, Operation, (Input) Message </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Client </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> In </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> RECEIVE </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> ClientPolicyInInterceptor </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Service, Endpoint </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Client </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> InFault </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> RECEIVE </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> ClientPolicyInFaultInterceptor </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Service, Endpoint </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Server</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> In </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> RECEIVE </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> ServerPolicyInInterceptor </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Service, Endpoint </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Server</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> OutFault </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> SETUP</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> ServerPolicyOutFaultInterceptor </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Service, Endpoint, Operation, (Fault) Message </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Server</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Out </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> SETUP</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> ServerPolicyOutInterceptor </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Service, Endpoint, Operation, (Out) Message </p></td></tr></tbody></table></div>
<p>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).<br clear="none">
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. <br clear="none">
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!</p>
<p>You can see how it designed on the following figure:</p>
<p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="how-it-works.data/cxf-ws-policies.jpg"></span></p>
<p>Briefly, policy interceptors make following steps:</p>
<ol><li>Check message property <em>PolicyConstants.POLICY_OVERRIDE</em>.</li><li>If <em>PolicyConstants.POLICY_OVERRIDE</em> contains policy, it will be taken for further processing.</li><li>If property is empty, policy will be asked from ServiceModel. Here CXF loads policies attached to WSDL or provided via Spring configuration.</li><li>If any policy on step 2 or step 3 is found, <em>EffectivePolicy</em> will be created. Appropriate WS-policies will be merged for the current message and built into Neethi <em>Policy</em> object.</li><li>All interceptors registered for result policy assertions will be added to message interceptor chain.</li></ol>
<h2 id="HowItWorks-PolicyAwareInterceptors">Policy Aware Interceptors</h2>
<p>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 specific behaviour. They can also express whether or not they could support these assertions. <br clear="none">
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 assert one, but not the other. 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. <br clear="none">
Typically the interceptor would strive at supporting as many of these assertions as possible however, and to do so it may avail of the AssertionBuilder's capability to compute a compatible assertion. For example, by scheduling an acknowledgement to be sent in 3 seconds, an RM interceptor would support both of the following RMAssertions:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default">
&lt;wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"&gt;
&lt;wsrmp:AcknowledgementInterval Milliseconds="30000"/&gt;
&lt;/wsrmp:RMAssertion&gt;
&lt;wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"&gt;
&lt;wsrmp:AcknowledgementInterval Milliseconds="50000"/&gt;
&lt;/wsrmp:RMAssertion&gt;
</pre>
</div></div>
<h2 id="HowItWorks-Verification">Verification</h2>
<p>Another set of interceptors installed by the policy framework is responsible for verifying that one of the alternatives in the effective policy of the underlying message is indeed supported. These interceptors are:</p>
<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p> Chain</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Phase </p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Interceptor </p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> Out, OutFault </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> POST_STREAM </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> PolicyVerificationOutInterceptor </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> In </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> PRE_INVOKE </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> PolicyVerificationInInterceptor </p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> InFault </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> PRE_INVOKE </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> PolicyVerificationInFaultInterceptor </p></td></tr></tbody></table></div>
<p>Their behaviour is symmetric on client and server side. <br clear="none">
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. As the map was built exclusively from the Assertion objects that are part of the chosen alternative of the effective message policy, all of them must be supported. In other words, all of the AssertionInfo objects need to be in the asserted state. If one of them is not, the interceptor throws a Fault (wrapping a PolicyException). </p>
<p>On the inbound paths a little bit more 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. If the message is not a fault message, knowing the underlying operation we 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 alternatives is supported, the policy verification interceptors then simply check if for each of its assertions the associated AssertionInfo object in the map is in the asserted state. If no alternative is supported, the interceptor throws a Fault (wrapping a PolicyException).</p>
<p>One thing worth noting is that - both on outbound and inbound chains - there may be assertions that only the conduit or destination can support. Although conduit or destination could access Assertion objects and tailor their behaviour when sending or receiving the current message, it is not knoan at this point whether this "tailoring" actually succeeded for the underlying message, i.e. whether the assertions in questions could actually be supported. For this reason, the policy verification interceptors check if the conduit or destination implements the Assertor interface. It it does, they pass it the Message object so they confirn their support (or the lack thereof) for these assertions. The above described traveral of the AssertionInfo map only takes place after the conduit or destination had a chance to m ake their contribution. </p></div>
</div>
<!-- Content -->
</td>
</tr>
</table>
</td>
<td id="cell-2-2" colspan="2">&nbsp;</td>
</tr>
<tr>
<td id="cell-3-0">&nbsp;</td>
<td id="cell-3-1">&nbsp;</td>
<td id="cell-3-2">
<div id="footer">
<!-- Footer -->
<div id="site-footer">
<a href="http://cxf.apache.org/privacy-policy.html">Privacy Policy</a> -
(<a href="https://cwiki.apache.org/confluence/pages/editpage.action?pageId=51375">edit page</a>)
(<a href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51375&amp;showComments=true&amp;showCommentArea=true#addcomment">add comment</a>)<br>
Apache CXF, CXF, Apache, the Apache feather logo are trademarks of The Apache Software Foundation.<br>
All other marks mentioned may be trademarks or registered trademarks of their respective owners.
</div>
<!-- Footer -->
</div>
</td>
<td id="cell-3-3">&nbsp;</td>
<td id="cell-3-4">&nbsp;</td>
</tr>
<tr>
<td id="cell-4-0" colspan="2">&nbsp;</td>
<td id="cell-4-1">&nbsp;</td>
<td id="cell-4-2" colspan="2">&nbsp;</td>
</tr>
</table>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-4458903-1");
pageTracker._trackPageview();
} catch(err) {}</script>
</body>
</html>