SJMS

SJMS Component

Available as of Camel 2.11

The SJMS Component is a JMS client API for use with Camel. It is based purely on the JMS API and as such does not rely on any third party messaging implementations keeping it light and flexible. It is scheduled to be released as part of Camel 2.11 with the following functionality:

• Standard Queue and Topic Support (Durable & Non-Durable)
• InOnly & InOut MEP Support
• Asynchronous Producer and Consumer Processing
• Internal JMS Transaction Support

Additional key features include:

• Plugable Connection Resource Management
• Session, Consumer, & Producer Pooling & Caching Management
• Transacted Batch Consumers & Producers
• Support for Customizable Transaction Commit Strategies (Local JMS Transactions only)

Maven users will need to add the following dependency to their pom.xml for this component:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-sjms</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

URI format

sjms:[queue:|topic:]destinationName[?options]

Where destinationName is a JMS queue or topic name. By default, the destinationName is interpreted as a queue name. For example, to connect to the queue, FOO.BAR use:

sjms:FOO.BAR

You can include the optional queue: prefix, if you prefer:

sjms:queue:FOO.BAR

To connect to a topic, you must include the topic: prefix. For example, to connect to the topic, Stocks.Prices, use:

sjms:topic:Stocks.Prices

You append query options to the URI using the following format, ?option=value&option=value&...

Usage Notes

As stated above SJMS Component uses a JMS client API that was written from the ground up for use in Camel. As such there are some key behaviors and features that deserve noting.

Plugable Connection Resource Management

Coming soon ...

Session, Consumer, & Producer Pooling & Caching Management

Coming soon ...

Transacted Batch Consumers & Producers

Coming soon ...

Customizable Transaction Commit Strategies (Local JMS Transactions only)

Coming soon ...

Component Options and Configurations

The SJMS Component supports the following configuration options:

Below is an example of how to configure the SjmsComponent with its required ConnectionFactory provider. It will create a single connection by default and store it using the components internal pooling APIs to ensure that it is able to service Session creation requests in a thread safe manner.

SjmsComponent component = new SjmsComponent();
component.setConnectionFactory(new ActiveMQConnectionFactory("tcp://localhost:61616"));
getContext().addComponent("sjms", component);

For a SjmsComponent that is required to support a durable subscription, you can override the default ConnectionFactoryResource instance and set the clientId property.

ConnectionFactoryResource connectionResource = new ConnectionFactoryResource();
connectionResource.setConnectionFactory(new ActiveMQConnectionFactory("tcp://localhost:61616"));
connectionResource.setClientId("myclient-id");

SjmsComponent component = new SjmsComponent();
component.setConnectionResource(connectionResource);
component.setMaxConnections(1);

Producer Configuration Options

The SjmsProducer Endpoint supports the following properties:

Consumers Configuration Options

The SjmsConsumer Endpoint supports the following properties:

Usage Notes

Message Header Format

The SJMS Component uses the same header format strategy that is used in the Camel JMS Component. This plugable strategy ensures that messages sent over the wire conform to the JMS Message spec.

For the exchange.in.header the following rules apply for the header keys:

Keys starting with JMS or JMSX are reserved.
exchange.in.headers keys must be literals and all be valid Java identifiers (do not use dots in the key name).
Camel replaces dots & hyphens and the reverse when when consuming JMS messages:
. is replaced by DOT and the reverse replacement when Camel consumes the message.

• is replaced by HYPHEN and the reverse replacement when Camel consumes the message.
  See also the option jmsKeyFormatStrategy, which allows use of your own custom strategy for formatting keys.

For the exchange.in.header, the following rules apply for the header values:

Message Content

To deliver content over the wire we must ensure that the body of the message that is being delivered adheres to the JMS Message Specification. Therefore, all that are produced must either be primitives or their counter objects (such as Integer, Long, Character). The types, String, CharSequence, Date, BigDecimal and BigInteger are all converted to their toString() representation. All other types are dropped.

Example Usage

InOnly Producer - (Default)

The InOnly Producer is the default behavior of the SJMS Producer Endpoint.

from("direct:start")
    .to("sjms:queue:bar");

InOut Producer

To enable InOut behavior append the exchangePattern attribute to the URI. By default it will use a dedicated TemporaryQueue for each consumer.

from("direct:start")
    .to("sjms:queue:bar?exchangePattern=InOut");

You can specify a namedReplyTo though which can provide a better monitor point.

from("direct:start")
    .to("sjms:queue:bar?exchangePattern=InOut&namedReplyTo=my.reply.to.queue");

Additional Notes

Does Springless Mean I Can't Use Spring?

Not at all. Below is an example of the SJMS component using the Spring DSL:

<route
    id="inout.named.reply.to.producer.route">
    <from
        uri="direct:invoke.named.reply.to.queue" />
    <to
        uri="sjms:queue:named.reply.to.queue?namedReplyTo=my.response.queue&amp;exchangePattern=InOut" />
</route>

Springless refers to moving away from the dependency on the Spring JMS API. A new JMS client API is being developed from the ground up to power SJMS.

Clustering

When using InOut with SJMS in a clustered environment you must either use TemporaryQueue destinations or use a unique named reply to destination per InOut producer endpoint. Message correlation is handled by the endpoint, not with message selectors at the broker. The InOut Producer Endpoint uses Java Concurrency Exchangers cached by the Message JMSCorrelationID. This provides a nice performance increase while reducing the overhead on the broker since all the messages are consumed from the destination in the order they are produced by the interested consumer.

Currently the only correlation strategy is to use the JMSCorrelationId. The InOut Consumer uses this strategy as well ensuring that all responses messages to the included JMSReplyTo destination also have the JMSCorrelationId copied from the request as well.

">Transaction Support

SJMS currently only supports the use of internal JMS Transactions. There is no support for the Camel Transaction Processor or the Java Transaction API (JTA).