Don't Use JmsTemplate in Spring!
JmsTemplate is easy for simple message sending. What if we want to add headers, intercept or transform the message? Then we have to write more code. So, how do we solve this common task with more configurability in lieu of more code? First, lets review JMS in Spring.
Spring JMS Options
- JmsTemplate – either to send and receive messages inline
- Use send()/convertAndSend() methods to send messages
- Use receive()/receiveAndConvert() methods to receive messages. BEWARE: these are blocking methods! If there is no message on the Destination, it will wait until a message is received or times out.
- MessageListenerContainer – Async JMS message receipt by polling JMS Destinations and directing messages to service methods or MDBs
Both JmsTemplate and MessageListenerContainer have been successfully implemented in Spring applications, if we have to do something a little different, we introduce new code. What could possibly go wrong?
Future Extensibility?
On many projects new use-cases arise, such as:
- Route messages to different destinations, based on header values or contents?
- Log the message contents?
- Add header values?
- Buffer the messages?
- Improved response and error handling?
- Make configuration changes without having to recompile?
- and more…
Now we have to refactor code and introduce new code and test cases, run it through QA, etc. etc.
A More Configurable Solution!
It is time to graduate Spring JmsTemplate and play with the big kids. We can easily do this with a Spring Integration flow.
How it is done with Spring Integration
Here we have a diagram illustrating the 3 simple components to Spring Integration replacing the JmsTemplate send.
- Create a Gateway interface – an interface defining method(s) that accept the type of data you wish to send and any optional header values.
- Define a Channel – the pipe connecting our endpoints
- Define an Outbound JMS Adapter – sends the message to your JMS provider (ActiveMQ, RabbitMQ, etc.)
Simply inject this into our service classes and invoke the methods.
Immediate Gains
- Add header & header values via the methods defined in the interface
- Simple invokation of Gateway methods from our service classes
- Multiple Gateway methods
- Configure method level or class level destinations
Future Gains
- Change the JMS Adapter (one-way) to a JMS Gateway (two-way) to processes responses from JMS
- We can change the channel to a queue (buffered) channel
- We can wire in a transformer for message transformation
- We can wire in additional destinations, and wire in a “header (key), header value, or content based” router and add another adapter
- We can wire in other inbound adapters receiving data from another source, such as SMTP, FTP, File, etc.
- Wiretap the channel to send a copy of the message elsewhere
- Change the channel to a logging adapter channel which would provide us with logging of the messages coming through
- Add the “message-history” option to our SI configuration to track the message along its route
- and more…
Optimal JMS Send Solution
The Spring Integration Gateway Interface
Gateway provides a one or two way communication with Spring Integration. If the method returns void, it is inherently one-way.
The interface MyJmsGateway, has one Gateway method declared sendMyMessage(). When this method is invoked by your service class, the first argument will go into a message header field named “myHeaderKey”, the second argument goes into the payload.
Spring Integration Configuration
Because the interface is proxied at runtime, we need to configure in the Gateway via XML.
Sending the Message
Summary
- Simple implementation
- Invoke a method to send a message to JMS – Very SOA eh?
- Flexible configuration
- Reconfigure & restart WITHOUT recompiling – SWEET!