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 outbound messages and faults. Also, because WS-Reliable Messaging depends on WS-Addressing, the CXF WS-Addressing interceptors need to be on these interceptor chains also.
The WS-Reliable Messaging implementation consists of 4 interceptors in total, but depending on which of the approaches oulined below you choose to enable the use of reliable messaging, you need not know what they are and which interceptor chain they should be added to.

It is important to note at this point that the presence of these interceptors alone will take care of exchanging the RM protocol messages when necessary. For example. upon processing the first application message on the outbound interceptor chain, the RM interceptors will ensure that a CreateSequence request is sent and not proceed with processing the original application message until the CreateSequenceResponse was received. Furthermore, the RM interceptors are responsible for adding the Sequence headers to the application messages and, on the destination side, extracting them from the message.
No changes to application code are required to make the message exchange reliable! And while by default, CXF attempts to maximize the lifetime of a sequence, thus reducing the overhead incurred by the RM protocol messages, you can control the behavior of these interceptors by setting their sequence termination policies (e.g. the maximum sequence length), and acknowledgment policies (e.g. send an out-of-band acknowledgment if no application messages was received in the last n seconds).To make a message exchange between two endpoints reliable, you need to ensure that the RM interceptors and (as WS-Reliable messaging has a dependency on WS-Addressing) the addressing interceptors are added to the interceptor chains. This can be achieved in one of the following ways:

Using the RMAssertion and the CXF WS-Policy Framework

...

the RM interceptors will be automatically added to their respective interceptor chains by the policy framework. The assertion attributes can be used configure control the behavior of the source/destination.

For example, to enable the WS-Policy Framework on the server side, you configuration file could look like this:

<jaxws:endpoint ...>
    <jaxws:features>
        <p:policies/>
    </jaxws:features>
</jaswsjaxws:endpoint>

and your wsdl:

<wsp:Policy wsu:Id="="RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata">
        <wsp:Policy/>
    </wsam:Addressing>
    <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
        <wsrmp:BaseRetransmissionInterval Milliseconds="10000"/> 
    </wsrmp:RMAssertion>
</wsp:Policy>
...
<wsdl:service name="ReliableGreeterService">
    <wsdl:port binding="tns:GreeterSOAPBinding" name="GreeterPort">
        <soap:address location="http://localhost:9020/SoapContext/GreeterPort"/>
        <wsp:PolicyReference URI="#RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy"/>        
    </wsdl:port>
</wsdl:service>

Instead of having attaching the PolicyReference attached to a the wsdl:port element, you can also specify it as a child element of the policies features, e,.g, . for the server endpoint:

<wsp:Policy wsu:Id="="RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy" ...>
</wsp:Policy>

<jaxws:endpoint ...>
    <jaxws:features>
        <p:policies>
            <wsp:PolicyReference URI="#RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy"/>
        </p:policies>
    </jaxws:features>
</jaxws:endpoint>

As of CXF 3.0.0 both the older WS-ReliableMessagingPolicy 1.0 (submission version) and the official WS-ReliableMessagingPolicy 1.2 are supported. WS-ReliableMessagingPolicy 1.2 must be used in the policy if you want WS-ReliableMessaging 1.2 support at runtime.

Using the Reliable Messaging Feature

If you don't want to involve the WS-Policy Framework, or want to configure additional parameters such as the sequence termination policy or the persistent store, you can you can use the reliableMessaging feature. It is defined in namespace http://cxf.apache.org/ws/rm/manager^{Image Removed} and supports the following child elements:

For details about the element types used in this namespace please refer to the schemas for the http://cxf.apache.org/ws/rm/manager^{Image Removed} namespace (http://cxf.apache.org/schemas/configuration/wsrm-manager.xsd^{Image Removed} and http://cxf.apache.org/schemas/configuration/wsrm-manager-types.xsd^{Image Removed}). The jbdcStore element type is described below.

Example (feature applied at bus level):

<cxf:bus>
    <cxf:features>
        <wsa:addressing/>
        <wsrm-mgr:reliableMessaging>
            <wsrm-policy:RMAssertion>
                <wsrm-policy:BaseRetransmissionInterval Milliseconds="4000"/>           
                <wsrm-policy:AcknowledgementInterval Milliseconds="2000"/>          
            </wsrm-policy:RMAssertion> 
            <wsrm-mgr:sourcePolicy>
                <wsrm-mgr:sequenceTerminationPolicy maxLength="5"/>                    
            </wsrm-mgr:sourcePolicy>     
            <wsrm-mgr:destinationPolicy acceptOffers="false">            
            <wsrm:store>
               <ref bean="myStore"/>
            </wsrm:store>
        </wsrm-mgr:reliableMessaging>
    </cxf:features>
</cxf:bus>

Configuring the Reliable Messaging Store

To enable persistence, you must specify the object 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). You can configure the latter using a custom jdbcStore bean (namespace http://cxf.apache.org/ws/rm/manager^{Image Removed}). It ) inside the wsrm-mgr:reliableMessaging element. The jdbcStore bean supports the attributes:

Example:

<wsrm<wsrm-mgr:jdbcStore xmlns:wsrm-mgr:jdbStore="http://cxf.apache.org/ws/rm/manager" id="myStore"
    driverClassName="org.apache.derby.jdbc.ClientDriver"/>
    url="jdbc:derby://localhost:1527/rmdb;create=true"/>
    password="password"/>

See the jdbcStore element definition in the RM Manager schema for more details of the attribute usages.

Adding the Reliable Messaging Interceptors Manually

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

<bean id="rmLogicalOut" class="org.apache.cxf.ws.rm.RMOutInterceptor">
        <property name="bus" ref="cxf"/>
    </bean>
    <bean id="rmLogicalIn" class="org.apache.cxf.ws.rm.RMInInterceptor">
        <property name="bus" ref="cxf"/>
    </bean>
    <bean id="rmCodec" class="org.apache.cxf.ws.rm.soap.RMSoapInterceptor"/>

    <cxf:bus ...>
        <cxf:inInterceptors>
            <ref bean="rmLogicalIn"/>
            <ref bean="rmCodec"/>
        </cxf:inInterceptors>
        <cxf:inFaultInterceptors>
            <ref bean="rmLogicalIn"/>
            <ref bean="rmCodec"/>
        </cxf:inFaultInterceptors>
        <cxf:outInterceptors>
            <ref bean="rmLogicalOut"/>
            <ref bean="rmCodec"/>
        </cxf:outInterceptors>
        <cxf:outFaultInterceptors>
            <ref bean="rmLogicalOut"/>
            <ref bean="rmCodec"/>
        <cxf:outFaultInterceptors>
    </cxf:bus>

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

Configuring the Reliable Messaging Manager Manually

To configure properties of the RM Manager, you can use the rmManager element from the http://cxf.apache.org/ws/rm/manager^{Image Removed} namespace. It supports the same child elements as the reliableMessaging feature element above. For example, without using features, you can determine that seuences should have a maximum length of 5 as follows:

<wsrm-mgr:rmManager xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager">

...

    <wsrm-mgr:sourcePolicy>

...

        <wsrm-mgr:sequenceTerminationPolicy maxLength="5"/>

...

                    
    </wsrm-mgr:sourcePolicy>

...

</wsrm-mgr:rmManager>

...