To invoke a method on a local or remote stateless session bean without Spring:
To avoid repeated low-level code, many EJB applications use the Service Locator and Business Delegate
As a result:
The Spring approach is to allow the creation and use of proxy objects, normally configured inside a Spring container, which act as codeless business delegates.
The following creates the EJB proxy.
The EJB local home is cached on startup, so there’s only a single JNDI lookup.
Spring simplifies the use of the JMS API and shields the user from differences between the JMS 1.0.2 and 1.1 APIs.
JMS is about the production and consumption of
The JmsTemplate class is used for message production and synchronous message reception.
Asynchronous reception (similar to J2EE's message-driven bean style), is provided by message listener containers that are used to create Message-Driven POJOs (MDPs).
JMS 1.0.2 defined two types of messaging domains, point-to-point (Queues) and publish/subscribe (Topics), but provided parallel class hierarchies.
JMS 1.1 introduced the concept of domain unification that minimized both the functional differences and client API differences between the two domains.
Objectives: 5.1 Configuring JMS Resources with Spring
The JmsTemplate uses the JMS 1.1 API and the subclass JmsTemplate102 uses the JMS 1.0.2 API.
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 (uses default values).
In the JmsTemplate, QOS parameters have been exposed as bean properties to avoid duplication of methods.
Instances of the JmsTemplate class are thread-safe once configured.
JmsTemplate supports the sending of messages to both Queues and Topics.
The JmsTemplate requires a reference to a ConnectionFactory
Destinations, like ConnectionFactories, are JMS administered objects that can be stored and retrieved in JNDI.
JmsTemplate delegates the resolution of a destination name to a JMS destination object to an implementation of
the interface DestinationResolver.
DynamicDestinationResolver is the default implementation used by JmsTemplate and accommodates resolving dynamic destinations.
A JndiDestinationResolver is also provided that acts as a service locator for destinations contained in JNDI and optionally falls back to the behavior contained in DynamicDestinationResolver.
Spring alternative to message-driven beans (MDBs) is message-driven POJOs (MDPs).
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 JMS (Java Message Service) reception and dispatches into the listener for processing.
A message listener container is the intermediary between an MDP and a messaging provider, and takes care of registering to receive messages, participating in transactions, resource acquisition and release and exception conversion.
Creates a fixed number of JMS sessions at startup.
Allow for dynamic adaption to runtime
It is able to participate in externally managed transactions (XA transaction).
Leverages the JMS ServerSessionPool SPI to allow for dynamic management of JMS
Provides dynamic runtime tuning.
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 can also be used with the JtaTransactionManager and an XA-capable JMS ConnectionFactory
for performing distributed transactions.
In a J2EE environment, the ConnectionFactory will pool Connections and Sessions, so those resources are efficiently reused across transactions.
Objectives: 5.2 Sending Messages
Spring's JmsGatewaySupport convenience base class, which provides pre-built bean properties for JMS configuration.
The overloaded methods convertAndSend and receiveAndConvert in JmsTemplate delegate the conversion process to an instance of the MessageConverter interface.
To accommodate the setting of a message's properties, headers, and body that can not be generically encapsulated inside a converter class, the MessagePostProcessor interface gives you access to the message after it has been converted, but before it is sent.
The SessionCallback and ProducerCallback expose the JMS Session and Session / MessageProducer pair respectfully.
Objectives: 5.3 Receiving Messages
JmsTemplate receive() methods are
blocking / synchronous in nature.
This can be a dangerous operation since the calling thread can potentially be blocked indefinitely.
The property receiveTimeout specifies how long the receiver should wait before giving up waiting for a message.
An MDP must implement the javax.jms.MessageListener
POJO that will be receiving messages must be thread-safe.
Define and configure one of the message listener containers
The SessionAwareMessageListener interface is a Spring-specific interface that provides a similar contract the
JMS MessageListener interface.
It can be implemented as an alternative to the MessageListener interface.
It provides the message handling method with access to the JMS Session from which the Message was received.
It allows you to expose almost any class as a MDP.
For JMS 1.0.2 API, use the MessageListenerAdapter102.
The name of the message handling method in a MessageListenerAdapter defaults to 'handleMessage', but can be changed using the "defaultListenerMethod" property.
MessageListenerAdapter can automatically send back a response Message if a handler
method returns a non-void value.
The resulting message will then be sent to the Destination (if one exists) defined in the JMS Reply-To property of the original message, or the default Destination set on the MessageListenerAdapter.
Invoking a message listener within a transaction only requires reconfiguration of the listener container.
Local resource transactions can simply be activated through the sessionTransacted flag on the listener
Sending a response message (via SessionAwareMessageListener) will be part of the same local transaction, but any other resource operations (such as database access) will operate independently.
Use DefaultMessageListenerContainer to participate in externally managed transactions.
Use JtaTransactionManager to participate in XA transactions.
Attributes of the JMS <listener> element
A bean name for the hosting listener container. If not specified, a bean name will be automatically generated.
The destination name for this listener, resolved through the DestinationResolver strategy.
The bean name of the handler object.
The name of the handler method to invoke. If the ref points to a MessageListener or Spring SessionAwareMessageListener, this attribute may be omitted.
The name of the default response destination to send response messages to. This will be applied in case of a request message that does not carry a "JMSReplyTo" field. The type of this destination will be determined by the listener-container's "destination-type" attribute. Note: This only applies to a listener method with a return value, for which each result object will be converted into a response message.
The name of the durable subscription, if any.
An optional message selector for this listener.
Attributes of the JMS <listener-container> element
The type of this listener container. Available options are: default, simple, default102, or simple102 (the default value is 'default').
A reference to the JMS ConnectionFactory bean (the default bean name is 'connectionFactory').
A reference to the Spring TaskExecutor for the JMS listener invokers.
A reference to the DestinationResolver strategy for resolving JMS Destinations.
A reference to the MessageConverter strategy for converting JMS Messages to listener method arguments. Default is a SimpleMessageConverter.
The JMS destination type for this listener: queue, topic or durableTopic. The default is queue.
The JMS client id for this listener container. Needs to be specified when using durable subscriptions.
The cache level for JMS resources: none, connection, session, consumer or auto. By default (auto), the cache level will effectively be "consumer", unless an external transaction manager has been specified - in which case the effective default will be none (assuming J2EE-style transaction management where the given ConnectionFactory is an XA-aware pool).
The native JMS acknowledge mode: auto, client, dups-ok or transacted. A value of transacted activates a locally transacted Session. As an alternative, specify the transaction-manager attribute described below. Default is auto.
A reference to an external PlatformTransactionManager (typically an XA-based transaction coordinator, e.g. Spring's JtaTransactionManager). If not specified, native acknowledging will be used (see "acknowledge" attribute).
The number of concurrent sessions/consumers to start for each listener. Can either be a simple number indicating the maximum number (e.g. "5") or a range indicating the lower as well as the upper limit (e.g. "3-5"). Note that a specified minimum is just a hint and might be ignored at runtime. Default is 1; keep concurrency limited to 1 in case of a topic listener or if queue ordering is important; consider raising it for general queues.
The maximum number of messages to load into a single session. Note that raising this number might lead to starvation of concurrent consumers!