Using Spring JMS
1 JmsTemplate:-
We use The JmsTemplate class is the central class in the JMS core package. It simplifies the use of JMS since it handles the creation and release of resources when sending or synchronously receiving messages.
Code that uses the JmsTemplate only needs to implement callback interfaces giving them a clearly defined high level contract. The MessageCreator callback interface creates a message given a Session provided by the calling code in JmsTemplate. In order to allow for more complex usage of the JMS API, the callback SessionCallback provides the user with the JMS session and the callback ProducerCallback exposes a Session and MessageProducer pair.
The JMS API exposes two types of send methods, one that takes
delivery mode, priority, and time-to-live as Quality of Service (QOS)
parameters and one that takes no QOS parameters which uses default values.
JmsTemplate also exposes a basic request-reply operation that allows to send a
message and wait for a reply on a temporary queue that is created as part of the
operation.
2 Connections:-
The JmsTemplate requires a reference to a ConnectionFactory.
The ConnectionFactory is part of the JMS specification and serves as the entry
point for working with JMS. It is used by the client application as a factory to
create connections with the JMS provider and encapsulates various configuration
parameters, many of which are vendor specific such as SSL configuration options.
Caching Messaging Resources:
The standard API involves creating many intermediate objects. To send a message
the following API walk is performed
ConnectionFactory->Connection->Session->MessageProducer->send
SingleConnectionFactory:
Spring provides an implementation of the ConnectionFactory interface,
SingleConnectionFactory, that will return the same Connection on all
createConnection() calls and ignore calls to close(). This is useful for
testing and standalone environments so that the same connection can be used for
multiple JmsTemplate calls that may span any number of transactions.
CachingConnectionFactory:
The CachingConnectionFactory extends the functionality of
SingleConnectionFactory and adds the caching of Sessions, MessageProducers,
and MessageConsumers. The initial cache size is set to 1, use the
property SessionCacheSize to increase the number of cached sessions. Note
that the number of actual cached sessions will be more than that number as
sessions are cached based on their acknowledgment mode, so there can be
up to 4 cached session instances when SessionCacheSize is set to one, one for
each AcknowledgementMode.
3 Destination Management:-
Destinations, like ConnectionFactories, are JMS administered
objects that can be stored and retrieved in JNDI. When configuring a Spring
application context you can use the JNDI factory class JndiObjectFactoryBean
/ <jee:jndi-lookup> to perform dependency injection on your object’s
references to JMS destinations. However, often this strategy is cumbersome if
there are a large number of destinations in the application or if there are
advanced destination management features unique to the JMS provider.
4 Message Listener Containers:-
One of the most common uses of JMS messages in the EJB world is to
drive message-driven beans (MDBs). Spring offers a solution to create
message-driven POJOs (MDPs) in a way that does not tie a user to an EJB
container.A message listener container is used to receive messages from a JMS
message queue and drive the MessageListener that is injected into it. The
listener container is responsible for all threading of message reception and
dispatches into the listener for processing.
There are two standard JMS message listener containers packaged with Spring,
each with its specialised feature set.
1 SimpleMessageListenerContainer:
This message listener container is the simpler of the two standard flavors. It
creates a fixed number of JMS sessions and consumers at startup, registers the
listener using the standard JMS MessageConsumer.setMessageListener()
method, and leaves it up the JMS provider to perform listener callbacks.
2 DefaultMessageListenerContainer:
This message listener container is the one used in most cases. In contrast to
SimpleMessageListenerContainer, this container variant does allow for dynamic
adaption to runtime demands and is able to participate in externally managed
transactions. Each received message is registered with an XA transaction when
configured with a JtaTransactionManager; so processing may take advantage
of XA transaction semantics.
5 Transaction management:-
Spring provides a JmsTransactionManager that manages transactions for a single JMS ConnectionFactory. The JmsTransactionManager performs local resource transactions, binding a JMS Connection/Session pair from the specified ConnectionFactory to the thread. JmsTemplate automatically detects such transactional resources and operates on them accordingly.
In a Java EE environment, the ConnectionFactory will pool Connections and Sessions, so those resources are efficiently reused across transactions. In a standalone environment, using Spring’s SingleConnectionFactory will result in a shared JMS Connection, with each transaction having its own independent Session. Alternatively, consider the use of a provider-specific pooling adapter such as ActiveMQ’s PooledConnectionFactory class.