Easily implement asynchronous messaging with spring JMS

Asynchronous process communication is an important component of service-oriented architecture (SOA), because many system communications in the enterprise, especially communication with external organizations, are essentially asynchronous. Java Messaging Service (JMS) is an API for writing JEE applications that use asynchronous messaging. Traditional messaging implementations using the JMS APIs include several steps, such as Jndi query queues connecting factories and queue resources, and creating a JMS session before actually sending and receiving messages.

The spring framework simplifies the task of using the JEE component (including JMS). It provides a template mechanism that hides the specifics of a typical JMS implementation, so that developers can focus on the actual work of handling messages without having to worry about creating, accessing, or clearing JMS resources.

This article outlines the spring JMS API and describes how to use the Spring JMS API to process (send and receive) messages asynchronously, using a Web routine running on the JBoss MQ server. I'll show you how simple and flexible it is to use spring JMS for a comparison between the traditional JMS implementation and the spring JMS implementation.

Asynchronous messaging and service-oriented architecture

In reality, most Web requests are handled synchronously. For example, when a user wants to log into a Web site, first enter the username and password, and then the server verifies the login legality. If the validation succeeds, the program will allow the user to enter the site. Here, the login request is processed immediately after receiving it from the client. Credit card Verification is another example of synchronous processing; only the server confirms that the credit card number entered is valid, and the customer is allowed to continue with sufficient savings on the account. But let's think about the payment settlement steps on the sequential processing system. Once the system confirms that the user's credit card information is accurate and has sufficient funds in the account, there is no need to wait for all payment details to be fulfilled and the transfer completed. The payment settlement can be done asynchronously so that the customer can proceed with the verification operation.

A request that takes longer than a typical synchronization request can be used with asynchronous processing. Another example of asynchronous processing is the credit request processing process that is submitted to the automated Underwriting System (AUS) in a local loan processing program. When a borrower submits a loan application, the mortgage company sends a request to AUS to obtain a credit history. Because this request requires comprehensive and detailed credit reports, including current and past debit accounts, recent payments and other financial information, the server takes a long time (hours or sometimes even days) to respond to these requests. It is pointless for a client program (application) to connect to the server and spend so much time waiting for results. Communication should therefore occur asynchronously, that is, once the request is committed, it is placed in the queue and the client is disconnected from the server. The AUS service then selects the request for processing from the specified queue and places the processed message in another message queue. Finally, the client program selects the processing result from this queue, and then processes the credit history data.

Jms

If you have used JMS code, you will find that it is similar to JDBC or JCA. It contains sample code creation or JMS resource object backtracking, which makes it more code intensive and repeatable each time you need to write a new class to send and receive messages. The following sequence shows the steps included in the traditional JMS implementation:

Creates a Jndi initial context.

Gets a queue connection factory from the Jndi context.

Gets a quene from the queue connection factory.

Creates a session object.

Creates a sender (sender) or recipient (receiver) object.

Send or receive messages using the sender or recipient object that you created in step 5.

When the message is processed, all JMS resources are closed.

As you can see, step 6 is the only place to process messages. The other steps are simply to manage the JMS resources that are not related to the actual business requirements, but developers must write and maintain the code for these additional steps.