ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Asynchronous Messaging Made Easy With Spring JMS
Pages: 1, 2, 3, 4, 5

JMSTemplate

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

Method Name Function
send Send a message to the default or specified destination. JmsTemplate contains send methods that specify the destination using a javax.jms.Destination object or using JNDI lookup.
receive Receive a message from the default or specified destination, but only wait until a specified time for delivery. We specify the timeout via the receiveTimeout attribute.
convertAndSend This method delegates the conversion process to an instance of MessageConverter interface and then sends the message to the specified destination.
receiveAndConvert 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.

The 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. SimpleMessageConverter (and SimpleMessageConverter102) are default implementations of MessageConverter. They are used to convert a String to a JMS TextMessage, a byte array (byte[]) to a JMS BytesMessage, a 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.

Sample Application

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:

  1. 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).
  2. 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:

  1. The user enters loan details on the loan application web page and submits the loan application.
  2. 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 CreditRequestSendQueue.
  3. The AUS system picks up loan details from the queue and uses loan parameters to retrieve credit history information from its database.
  4. Then AUS creates a new message with its findings on the borrower's credit history and sends it to a new message queue called CreditRequestReceiveQueue.
  5. 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.

Thumbnail; click for full-size image.
Figure 1. Sequence diagram of the loan processing application (Click the screen shot to open a full-size view)

Pages: 1, 2, 3, 4, 5

Next Pagearrow