Versions Compared

Old Version 1

changes.mady.by.user Andrea Smyth

Saved on

compared with

New Version 2

changes.mady.by.user Andrea Smyth

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
h1. WS-Addressing Configuration

In order to use WS-Addressing in a message exchange, two things are necessary:
# The addressing interceptors (

Using WS-Reliable Messaging

In order for a client/server to communicate reliably with its target endpoint/its clients, the CXF WS-Reliable Messaging interceptors need to be in the interceptor chain for inbound and oubound messages and faults. Also, because WS-Reliable Messaging depends on WS-Addressing, the CXF WS-Addressing interceptors need to be on these interceptor chains.
In the case of WS-Addressing, this means two interceptors on each of chains, see WS-Addressing Configuration.
The WS-Reliable Messaging implementation consists of 4 interceptors in total, and not all of them appear in all chain types. In a wsdl first approach however you need not be aware of these details if you use the WS-Policy Framework implementation and ensure that a Policy with an RMAssertion element is attached to the wsdl:service element (or any other wsdl element that according to the rules for WS-Policy Attachment is an attachment point for Policy or PolicyReference elements):

Enabling WS-Reliable Messaging using the WS-Policy Framework

You need to ensure that the CXF's policy engine is enabled:

Code Block
xmlxml

    <bean id="org.apache.cxf.ws.policy.PolicyEngine" class="addressing.MAPAggregator and org.apache.cxf.ws.policyaddressing.spring.InitializingPolicyEngine">
        <property name="bus" ref="cxf"/>
        <property name="enabled" value="true"/>
    </bean>

The attachment of a <wsp:Policy> element containing an <wsrmp:RMAssertion> element (or a <wsp:PolicyReference element referencing such an element) is then sufficient to enable the use of Reliable Messaging, i.e. it causes the Reliable Messaging interceptors to be added to the appropriate interceptor chains.
While an empty <RMAssertion> element is enough to trigger the use of reliable Messaging. Any child elements, such as an <wsrmp:BaseRetransmissionInterval> element, will take effect only for the endpoint to which the enclosing <wsp:Policy> od <wsp:PolicyReference> element applies.

Note that the <wsp:Policy> or <wsp:PolicyReference> elements need not be necessarily be attached to wsdl elements but can also appear in the form of external attachments, see WS-Policy - How it Works.

Enabling WS-Reliable Messaging using the WS-Policies Feature

The PolicyEngine can also be enabled by using the WS-Policies Feature - that way you need not be aware of the policy engine's implementation class and its relation to the bus:

{:pcode:xml}
<jaxws:endpoint ...>
<jaxws:features>
<p:policies/>
</jaxws:features>
</bean>

Code Block


Also, <wsp:Policy> or <wsp:PolicyReference> element can appear as child elements of the policies feature, having the same effect as if they were soap.MAPCodec) need to be on the nbound and outbound interceptor chains, and
# The use of WS-Addressing is indicated by one of the following:
## A {http://www.w3.org/2005/02/addressing/wsdl}UsingAddressing element is attached to the wsdl:element representing the endpoint:

{code:xml}
    <jaxws:endpoint ...>
        <jaxws:features>
            <p:policies xmlns:p=">
                <wsp:Policy xmlns:wsp="port, wsdl:service or wsdl:binding element.
## The (chosen alternative for the) effective policy of the message contains a {http://www.w3.org/2007/200602/07/ws-policy">
                   <wsp:All>
                      <wsam:Addressing xmlns:wsam="addressing/metadata}Addressing assertion or a UsingAddressing assertion from either one of the following three namespaces: http://schemas.xmlsoap.org/ws/2004/08/addressing/policy, http://www.w3.org/20072005/02/addressing/metadata">
                          <wsp:Policy/>
                      </wsam:Addressing>
                      <wsrmp:RMAssertion xmlns:wsrmpwsdl, http://www.w3.org/2006/05/addressing/wsdl. 
## Property org.apache.cxf.ws.addressing.using in the message context is set to Boolean.TRUE.

Note that for 2.2 to take effect, CXF's policy engine must be enabled, see [WS-Policy Framework Configuration|WSPConfiguration].

h2. Adding the Addressing Interceptors using the Addressing Feature

For an individual endpoint:

{code:xml}
<beans ... xmlns:wsa="http://schemascxf.xmlsoapapache.org/ws/2005/02/rm/policy"addressing" ...>
    <jaxws:endpoint ...>
        <jaxws:features>
             <wsrmp:BaseRetransmissionInterval Milliseconds="30000"<wsa:addressing/>
                      </wsrmpjaxws:RMAssertion>features>
                   </wsp:All>
                </wsp:Policy>                
            <p:/policies>
        </jaxws:features>
    </bean>

Enabling and Configuring WS-Reliable Messaging using the WS-Reliable Messaging Feature

TODO

Enabling and Configuring WS-Reliable Messaging using Beans

To ensure that the Reliable Messaging interceptors are added to the appropriate interceptor chains, e.g. for all client and server endpoints:

Code Block
xmlxml

    <bean id="rmLogicalOut</bean>
</beans>
{code}

h2. Adding the Addressing Interceptors Manually

org.apache.cxf.ws.addressing.MAPAggregator and org.apache.cxf.ws.addressing.soap.MAPCodec must be added to the interceptor chain for inbound and outbound messages and faults. On a global level, i.e. applicable to all client and server endpoints, this can be done as follows (see also [Bus Configuration|Bus-Configuration]):

{code:xml}
<bean id="mapAggregator" class="org.apache.cxf.ws.rm.RMOutInterceptor">
        <property name="bus" ref="cxfaddressing.MAPAggregator"/>
    </bean>
    <bean id="rmLogicalInmapCodec" class="org.apache.cxf.ws.rm.RMInInterceptor">
        <property name="bus" ref="cxf"/>
    </bean>
    <bean id="rmCodec" class="org.apache.cxf.ws.rm.soap.RMSoapInterceptoraddressing.soap.MAPCodec"/>

    <cxf:bus ...>bus>
        <cxf:inInterceptors>
            <ref bean="rmLogicalInmapAggregator"/>
            <ref bean="rmCodecmapCodec"/>
        </cxf:inInterceptors>
        <cxf:inFaultInterceptors>
            <ref bean="rmLogicalInmapAggregator"/>
            <ref bean="rmCodecmapCodec"/>
        </cxf:inFaultInterceptors>
        <cxf:outInterceptors>
            <ref bean="rmLogicalOutmapAggregator"/>
            <ref bean="rmCodecmapCodec"/>
        </cxf:outInterceptors>
        <cxf:outFaultInterceptors>
            <ref bean="rmLogicalOutmapAggregator"/>
            <ref bean="rmCodecmapCodec"/>
        <cxf</cxf:outFaultInterceptors>
    </cxf:bus>

The RetransmissionIntercepor will be added on the fly by the RMOutInterceptor so need not appear in your configuration file.

To configure properties of the RM Manager, you can use the rmManager element from the http://cxf.apache.org/ws/rm/managerImage Removed namespace. It supports the following child elements:

Element

Value

sourcePolicy

...

destinationpolicy

...

rmAssertion

...

store

The RM store. This must be a bean or a reference to a bean that implements the org.apache.cxf.ws.rm.persistence.RMStore.

To enable persistence, you must specify the class implementing the persistent store for RM. You can develop your own, or use the JDBC based store that comes with CXF (class org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore that is). In that case, you may need to configure the driver class and connection parameters:

Property Name

Type

Default

driverClassName

String

org.apache.derby.jdbc.EmbeddedDriver

userName

String

null

passWord

String

null

url

String

jdbc:derby:rmdb;create=true

Example:

...

<bean class="org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore">
<property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver"/>
<property name="url" value="jdbc:derby://localhost:1527/rmdb;create=true"/>
<property name="password" value="password"/>
</bean>

<wsrm-mgr:rmManager xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager">
<property name="store" ref="org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore"/>
</wsrm-mgr:rmManager>

xml
Code Block
xml

h2. Configuring the Addressing Interceptors

TBD