JmsTemplate provides several helper methods to perform basic operations. To get started using
JmsTemplate you will need to know which JMS specification is supported by the JMS provider. JBoss AS 4.0.2 and WebLogic 8.1 servers support the JMS 1.0.2 specification. WebLogic Server 9.0 includes support for the JMS 1.1 specification. JMS 1.1 unifies the programming interfaces for Point-to-Point (PTP) and Publish/Subscribe (Pub/Sub) domains. As result of this change, developers can create a transacted session, then receive a message from a
Queue (PTP) and send another message to a
Topic (Pub/Sub) within the same JMS transaction. JMS 1.1 is backwards-compatible with JMS 1.0 so the code written for the JMS 1.0 specification should still work with version 1.1.
JmsTemplate provides various methods to send and receive the messages. Table 2 shows a list of some of these methods.
Table 2. JMS template methods
||Send a message to the default or specified destination.
||Receive a message from the default or specified destination, but only wait until a specified time for delivery. We specify the timeout via the
||This method delegates the conversion process to an instance of
||Receive a message from the default or specified destination and convert the message to Java object.|
Destinations are stored and retrieved using a JNDI context. When configuring a Spring application context, we use the
JndiObjectFactoryBean class to get references to JMS destinations. The
DestinationResolver interface is used to resolve a destination name to a JMS destination, which is helpful when the application has lot of destinations.
DynamicDestinationResolver (a default implementation of
DestinationResolver) is used to resolve dynamic destinations.
MessageConverter interface defines a contract to convert Java objects into JMS messages. By using the converter, application code can focus on the business objects and not bother with the inner details of how it's represented as a JMS message.
SimpleMessageConverter102) are default implementations of
MessageConverter. They are used to convert a
String to a JMS
TextMessage, a byte array (
byte) to a JMS
Map to a JMS
MapMessage, and a
Serializable object to a JMS
ObjectMessage, respectively. You can also write your own custom implementations of
MessageConverter to convert XML documents into a
TextMessage object using an XML binding framework such as JAXB, Castor, Commons Digester, XMLBeans, or XStream.
I will use a sample loan application processing system (called LoanProc) to demonstrate how to use Spring in a JMS application. As part of the loan processing, LoanProc sends loan details (loan ID, borrower name, borrower's SSN, loan expiration date, and loan amount) to request the credit history details from the AUS system. To keep it simple, we will get credit history details based on two loan parameters: credit score (also known as FICO score) and loan amount. Let's assume that the business rules for processing a credit check request are as follows:
- If the loan amount is equal to or less than $500,000, then the borrower must have at least a "Good" credit (i.e., the borrower's FICO score is between 680-699).
- If the loan amount is greater than $500,000, the borrower must have a "Very Good" credit, meaning his/her credit score is more than 700.
Loan Application Use Case
The use case for the credit request process consists of the following steps:
- The user enters loan details on the loan application web page and submits the loan application.
- Then the program sends loan details to the AUS system to get credit history details. This is done by sending the request to a message queue called
- The AUS system picks up loan details from the queue and uses loan parameters to retrieve credit history information from its database.
- Then AUS creates a new message with its findings on the borrower's credit history and sends it to a new message queue called
- Finally, LoanProc picks up the response message from receive queue and processes the loan application to determine if the application can be approved or denied.
In the sample application, both message queues are configured in the same JBoss MQ server. The use case is represented in the Sequence Diagram in Figure 1.