Using the Java

...

Message Service (JMS)

CXF provides a transport plug-in that enables endpoints to use Java Messaging System Message Service (JMS) queues and topics. CXF's JMS transport plug-in uses the Java Naming and Directory Interface (JNDI) to locate and obtain references to the JMS provider that brokers for the JMS destinations. Once CXF has established a connection to a JMS provider, CXF supports the passing of messages packaged as either a JMS ObjectMessage or a JMS TextMessage.

JMS Namespaces

WSDL Namespace

The WSDL extensions for defining a JMS endpoint are defined in the namespace http://cxf.apache.org/transports/jmsImage Removed. In order to use the JMS extensions you will need to add the line shown below to the definitions element of your contract.

xmlns:jms="http://cxf.apache.org/transports/jms"

Configuration Namespaces

The CXF JMS endpoint configuration properties are specified under two namespaces:

• http://cxf.apache.org/transports/jmscontainsImage Removed the elements used to define the basic JMS port configuration.
• http://cxf.apache.org/transports/jms/jms-confImage Removed contains element used for configuring the runtime components of the JMS transport.

In order to use the JMS configuration properties you will need to add the lines shown below to the beans element of your configuration.

xmlns:jms="http://cxf.apache.org/transports/jms"
xmlns:jms-conf="http://cxf.apache.org/transports/jms/jms-conf"

Basic Endpoint Configuration

JMS endpoints need to know certain basic information about how to establish a connection to the proper destination. This information can be provided in one of two places:

• WSDL
• Configuration

Using WSDL

The JMS destination information is provided using the jms:address element and its child, the jms:JMSNamingProperties element. The jms:address element's attributes specify the information needed to identify the JMS broker and the destination. The jms:JMSNamingProperties element specifies the Java properties used to connect to the JNDI service.

The address element

The basic configuration for a JMS endpoint is done by using a jms:address element as the child of your service's port element. The jms:address element uses the attributes described below to configure the connection to the JMS broker.

The JMSNamingProperties element

To increase interoperability with JMS and JNDI providers, the jms:address element has a child element, jms:JMSNamingProperties, that allows you to specify the values used to populate the properties used when connecting to the JNDI provider. The jms:JMSNamingProperties element has two attributes: name and value. The name attribute specifies the name of the property to set. The value attribute specifies the value for the specified property. The jms:JMSNamingProperties element can also be used for specification of provider specific properties.
The following is a list of common JNDI properties that can be set:

1. java.naming.factory.initial
2. java.naming.provider.url
3. java.naming.factory.object
4. java.naming.factory.state
5. java.naming.factory.url.pkgs
6. java.naming.dns.url
7. java.naming.authoritative
8. java.naming.batchsize
9. java.naming.referral
10. java.naming.security.protocol
11. java.naming.security.authentication
12. java.naming.security.principal
13. java.naming.security.credentials
14. java.naming.language
15. java.naming.applet

For more details on what information to use in these attributes, check your JNDI provider's documentation and consult the Java API reference material.

Using a named reply destination

By default, CXF endpoints using JMS create a temporary queue for sending replies back and forth. You can change this behavior by setting the jndiReplyDestinationName attribute in the endpoint's contract. A client endpoint will listen for replies on the specified destination and it will specify the value of the attribute in the ReplyTo field of all outgoing requests. A service endpoint will use the value of the jndiReplyDestinationName attribute as the location for placing replies if there is no destination specified in the request's ReplyTo field.
The following example shows an example of a JMS WSDL port specification.

<service name="JMSService">
  <port binding="tns:Greeter_SOAPBinding" name="SoapPort">
    <jms:address jndiConnectionFactoryName="ConnectionFactory"
                 jndiDestinationName="dynamicQueues/test.Celtix.jmstransport">
      <jms:JMSNamingProperty name="java.naming.factory.initial"
                             value="org.activemq.jndi.ActiveMQInitialContextFactory" />
      <jms:JMSNamingProperty name="java.naming.provider.url"
                             value="tcp://localhost:61616" />
    </jms:address>
  </port>
</service>

Using Configuration

In addition to using the WSDL file to specify the connection information for a JMS endpoint, you can supply it in the endpoint's configuration file. The information in the configuration file will override the information in the endpoint's WSDL file.

Configuration beans

You use the org.apache.cxf.transport.jms.base.JMSTransportBaseConfigBean bean class to specify the address for a JMS endpoint. The value if the configuration bean's id attribute determines if you are configuring a consumer endpoint or a service endpoint. The id values will take one of the following forms:

• {WSDLNamespace}WSDLPortName.jms-conduit-base specifies that a consumer endpoint is being configured
• {WSDLNamespace}WSDLPortName.jms-destination-base specifies that a service endpoint is being configured

The addressPolicy property

JMS connection information is specified using the addressPolicy property. The addressPolicy property has a single value: jms:address. It is identical to the jms:address element used in the WSDL file.
Like the jms:address element in the WSDL file, the jms:address configuration element also has a jms:JMSNamingProperties child element that is used to specify additional information used to connect to a JNDI provider.
The addressPolicy property can be specified in either the client base configuration bean or the service base configuration bean.
The following example shows a CXF configuration entry for configuring the addressing information for a JMS consumer endpoint.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ct="http://cxf.apache.org/configuration/types"
       xmlns:jms="http://cxf.apache.org/transports/jms"
       xmlns:jms-conf="http://cxf.apache.org/transports/jms/jms-conf"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-conduit-base"
      class="org.apache.cxf.transport.jms.base.JMSTransportBaseConfigBean">
  <property name="addressPolicy">
    <value>
      <jms:address destinationStyle="queue"
                   jndiConnectionFactoryName="myConnectionFactory"
                   jndiDestinationName="myDestination"
                   jndiReplyDestinationName="myReplyDestination"
                   connectionUserName="testUser"
                   connectionPassword="testPassword">
        <jms:JMSNamingProperty name="java.naming.factory.initial"
                               value="org.apache.cxf.transport.jms.MyInitialContextFactory"/>
        <jms:JMSNamingProperty name="java.naming.provider.url"
                               value="tcp://localhost:61616"/>
      </jms:address>
    </value>
  </property>
</bean>
</beans>

Consumer Endpoint Configuration

JMS consumer endpoints specify the type of messages they use. JMS consumer endpoint can use either a JMS ObjectMessage or a JMS TextMessage. When using an ObjectMessage the consumer endpoint uses a byte[] as the method for storing data into and retrieving data from the JMS message body. When messages are sent, the message data, including any formating information, is packaged into a byte[]
and placed into the JMS message body before it is placed on the wire. When messages are received, the consumer endpoint will attempt to unmarshall the data stored in the JMS body as if it were packed in a byte[].
When using a TextMessage, the consumer endpoint uses a string as the method for storing and retrieving data from the JMS message body. When messages are sent, the message information, including any format-specific information, is converted into a string and placed into the JMS message body. When messages are received the consumer endpoint will attempt to unmashall the data stored in the JMS message body as if it were packed into a string.
When native JMS applications interact with CXF consumers, the JMS application is responsible for interpreting the message and the formatting information. For example, if the CXF contract specifies that the binding used for a JMS endpoint is SOAP, and the messages are packaged as TextMessage, the receiving JMS application will get a text message containing all of the SOAP envelope information.
Consumer endpoint can be configured in one of two ways:

• Configuration
• WSDL

Using Configuration

Specifying the message type

Consumer endpoint configuration is specified using org.apache.cxf.transport.jms.conduit.JMSConduitConfigBean as the class for the configuration bean. Using this configuration bean, you specify the message type supported by the consumer endpoint using the client property. It has a single value, jms:client, that has a single attribute:

• messageType – Specifies how the message data will be packaged as a JMS message. text specifies that the data will be packaged as a TextMessage. binary specifies that the data will be packaged as an ObjectMessage.

The following example shows a configuration entry for configuring a JMS consumer endpoint.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ct="http://cxf.apache.org/configuration/types"
       xmlns:jms="http://cxf.apache.org/transports/jms"
       xmlns:jms-conf="http://cxf.apache.org/transports/jms/jms-conf"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
...
<bean id="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-conduit"
      class="org.apache.cxf.transport.jms.conduit.JMSConduitConfigBean">
  <property name="client">
    <value>
      <jms:client messageType="binary"/>
    </value>
  </property>
...
</bean>
...
</beans>

Specifying address information

The addressing information for a JMS consumer endpoint is set using a configuration bean with a class of org.apache.cxf.transort.jms.base.JMSTransportBaseConfigBean and an id in the form of {WSDLNamespace}WSDLPortName.jms-conduit-base.

Using WSDL

The type of messages accepted by a JMS consumer endpoint is configured using the optional jms:client element. The jms:client element is a child of the WSDL port element and has one attribute:

• messageType – Specifies how the message data will be packaged as a JMS message. text specifies that the data will be packaged as a TextMessage. binary specifies that the data will be packaged as an ObjectMessage.

Service Endpoint Configuration

JMS service endpoints have a number of behaviors that are configurable in the contract. These include:

• how messages are correlated
• the use of durable subscriptions
• if the service uses local JMS transactions
• the message selectors used by the endpoint

Service endpoints can be configure in one of two ways:

• Configuration
• WSDL

Using Configuration

Specifying configuration data

Service endpoints are configured using the org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean} class for the configuration bean. Using this configuration bean class, you can specify the service endpoint's behaviors using the {{server property. It has a single element, jms:server, that has a the following attributes:

The following example shows a CXF configuration entry for configuring a JMS service endpoint.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ct="http://cxf.apache.org/configuration/types"
       xmlns:jms="http://cxf.apache.org/transports/jms"
       xmlns:jms-conf="http://cxf.apache.org/transports/jms/jms-conf"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
...
<bean id="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-destination"
      class="org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean">
  <property name="server">
    <value>
      <jms:server messageSelector="cxf_message_selector"
                  useMessageIDAsCorrelationID="true"
                  transactional="true"
                  durableSubscriberName="cxf_subscriber" />
    </value>
  </property>
</bean>
...
</beans>

Adding address information

The addressing information for a JMS service endpoint is set using a configuration bean with a class of org.apache.cxf.transort.jms.base.JMSTransportBaseConfigBean and an id in the form of {WSDLNamespace}WSDLPortName.jms-destination-base.

Using WSDL

Service endpoint behaviors are configured using the optional jms:server element. The jms:server element is a child of the WSDL port element and has the following attributes:

JMS Runtime Configuration

In addition to configuring the externally visible aspects of your JMS endpoint, you can also configure aspects of its internal runtime behavior. There are three types of runtime configuration:

• Base configuration
• Consumer specific configuration
• Service specific configuration

Base Runtime Configuration

The JMS base configuration allows you to specify the number of JMS sessions an endpoint will keep in a pool. This property is specified using the same configuration bean as the endpoint's address configuration.

Configuration bean

You use the org.apache.cxf.transport.jms.base.JMSTransportBaseConfigBean bean class to specify the session pool configuration for a JMS endpoint. The value if the configuration bean's id attribute determines if you are configuring a consumer endpoint or a service endpoint. The id values will take one of the following forms:

• {WSDLNamespace}WSDLPortName.jms-conduit-base specifies that a consumer endpoint is being configured.
• {WSDLNamespace}WSDLPortName.jms-destination-base specifies that a service endpoint is being configured.

Session pool configuration

You configure an endpoint's JMS session pool using the sessionPoolConfig property. This property allows you to set a high and low water mark for the number of JMS sessions an endpoint will keep pooled. The endpoint is guaranteed to maintain a pool of sessions equal to the low water mark and to never pool more sessions than specified by the high water mark.
The sessionPoolConfig property takes a single jms-conf:sessionPoolConfig element. The jms-conf:sessionPoolConfig element's attributes, listed below, specify the high and low water marks for the endpoint's JMS session pool.

The following example shows an example of configuring the session pool for a CXF JMS service endpoint.

<bean id="{http://cxf.apache.org/jms_endpit}HelloWorldJMSPort.jms-destination-base"
      class="org.apache.cxf.transport.jms.base.JMSTransportBaseConfigBean">
...
  <property name="sessionPoolConfig">
    <value>
      <jms-conf:sessionPoolConfig lowWaterMark="10"
                                  highWaterMark="5000" />
    </value>
  </property>
</bean>

Consumer Specific Runtime Configuration

The JMS consumer configuration allows you to specify two runtime behaviors:

• the number of milliseconds the consumer will wait for a response.
• the number of milliseconds a request will exist before the JMS broker can remove it.

Configuration bean

You configure consumer runtime behavior using the org.apache.cxf.transport.jms.conduit.JMSConduitConfigBean configuration bean class.

Configuration property

You use the clientConfig property to set JMS consumer runtime behavior. This property has a single element called jms-conf:clientConfig. This element's attributes, listed in the following table, specify the configuration values for consumer runtime behavior.

The following example shows a configuraiton fragment that sets the consumer endpoint's request lifetime to 500 milliseconds and its timeout value to 500 milliseconds.

<bean id="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-conduit"
      class="org.apache.cxf.transport.jms.conduit.JMSConduitConfigBean">
...
  <property name="clientConfig">
    <value>
      <jms-conf:clientConfig clientReceiveTimeout="500"
                             messageTimeToLive="500" />
    </value>
  </property>
</bean>

Service Specific Runtime Configuration

The JMS service configuration allows you to specify to runtime behaviors:

• the amount of time a response message can remain unreceived be fore the JMS broker can delete it.
• the client identifier used when creating and accessing durable subscriptions.

Configuration bean

You configure JMS service runtime behavior using the org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean configuration bean class.

Configuration property

The serverConfig property is used to specify the service runtime configuration. It takes a single jms-conf:serverConfig element. This element's attributes, listed below, specify the configuration values that control the service's runtime behavior.

The following example shows a configuration fragment that sets the service endpoint's response lifetime to 500 milliseconds and its durable subscription client identifier to jms-test-id.

...

...

JMS transport also supports the SOAP over JMS specification. See SOAP over JMS 1.0 support for more information.

Configuration styles

• SOAP / JMS spec compliant configuration - recommended style for CXF 3
• JMSConfiguration style - works in CXF 2 and 3 but is deprecated for CXF 3
• CXF 2.x JMS configuration - removed in CXF 3

Advanced examples (CXF >= 3)

• Performance and pooling
• JMS transactions

Reconnect functionality

The JMS transport automatically reconnects when any JMS exceptions happen. The first exception will be logged with "Exception on JMS connection. Trying to reconnect" and the exception details.
Then CXF will try to reconnect every 5 seconds and log "Exception on reconnect. Trying again, attempt num x".

In conduits every exception when sending a message will be thrown to the caller. The conduit then closes the connection and will start a new one when sending the next message.

In CXF 2.x the JMS server must be present before JMS endpoints are started. In CXF 3 the endpoint will start and periodically reconnect like in the case of an exception while running.