As Internet services have evolved and gradually become more and more distributed in nature, enterprise messaging has grown into one of the most important parts of Web application infrastructure. Applications can transfer an enormous amount of messages in a short amount of time, and the data being transferred is often very essential to the underlying business processes.

However important the data might be, many enterprise applications aren't fully equipped to recover from common messaging problems. Sure, messages might be persisted to a data store, but systems often lack reliable and adequately flexible mechanisms for monitoring and administration - something as principal as proper handling of failed messages might be overlooked.

In this article I will discuss WebLogic messaging and the Java Message Service (JMS) from an administrative point of view - we will take a look at how to give business-critical messages the attention they deserve and how to implement management tools for ensuring a smooth message flow for your application.

The Enterprise Application Middleman
Enterprise messaging is all about the exchange of data between disparate systems, a form of intercomputer communication that invariably requires special measures for successful operation. Process-to-process communication over networks without some form of intermediary would be extremely difficult to maintain, so we use message-oriented-middleware systems (MOMs), such as WebLogic JMS, to offload the responsibilities of guaranteed delivery, message notifications, and all other complicated inherent issues. Think of MOMs as the postal service of enterprise applications.

WebLogic JMS is a highly reliable service and if it acknowledges a sent message, you can indeed be sure that the message has been received. That is, however, where the guarantees end; the client application (message producer) has no way of knowing if the receiving application (message consumer) has successfully processed the message, not unless you implement your own acknowledgement system.

Problems, What Problems?
Whenever you have two computers communicating with each other, sooner or later something is bound to go wrong. Unavailable subsystems, network failures, message overflows, and deadlocks are just a few common predicaments that you might stumble into. Instead of trying to make sure that nothing ever goes wrong, be sure to prepare for situations when something does go wrong.

The corrective actions for each type of processing failure need to be evaluated separately. Some problems (such as busy subsystems) are easily fixed by automatic retries, while others require manual intervention. Many services also don't support any form of reprocessing or error handling whatsoever, which makes it the responsibility of the client application to recover from failures.

Let's assume that your business model obligates you to take every effort to process a message before giving up and sending a negative acknowledgement back to the client application. If that were the case, then you should probably retry processing automatically a couple of times, and when that doesn't help, someone should be able to manually examine the failing message. Let's take a look at a common way to achieve this in practice.

Message Management, Take One
A very robust message-administration technique is to redirect all failing messages to an error queue and have a consumer save the embodied data and properties to a database. Later, the messages can be investigated by an administrator and optionally re-created and resent. Using a database to store messages gives you very high data integrity and convenience. Here are the main steps required for the implementation:

1. Configure a persistent error queue for your destinations in your config.xml file. Error queues are also known as dead message queues and are regular JMS destinations where failing messages will be sent automatically. Messages are directed to the error queue by adding the ErrorDestination parameter to your active destinations.
2. Configure a consumer for your error queue and make it read the stored data and properties of failed messages by using the accessor methods of the javax.jms.Message class.
3. Save the recovered data together with the name of the original destination of the message to a database table. The original destination can be obtained by the getJMSDestination() method of the Message class.
4. Write methods that read the data from your database, display it, and give the option to resend by re-creating messages from the saved data and sending them to the original destination.

Having done all that, you have a very flexible system for managing messaging problems. The implementation requires quite a lot of work, but is fairly straightforward if you are familiar with JMS and know the basics. This is a very good and often-used solution, but there is another approach that is simpler to implement, doesn't require using a database, and gives you the added benefit of allowing you to peek into the content of any queue at run time.

QueueBrowser for Queue Browsing
The JMS API includes tools that enable full access to queued messages. The tools I'm talking about are the javax.jms.QueueBrowser interface and message selectors. The QueueBrowser is an interface that can retrieve messages from a given queue without consuming them. It can return all messages or, with the help of message selectors, only a subset of the messages.

Our alternative queue-management approach is to use passive error queues for storing failed messages and to use the QueueBrowser for listing them. Single messages can then be selected and resent, copied, or deleted.

Here are the step-by-step instructions for developing a simple queue-management system that handles failed messages:

1. Configure a persistent error queue for your destinations in your config.xml file. You don't need to configure or write any consumers for the error queue.
2. Use the QueueBrowser interface to display all of the messages in your error queue. Browsing through queued messages is very simple and only requires a couple lines of code (see Listing 1).
3. When the user selects a message, you can retrieve it by using its message ID as a criterion for the message selector parameter (see Listing 2). After retrieving it, you can easily redeliver it to its original destination or even to some other passive queue for safekeeping. You can also delete the message by using a QueueReceiver with the same message selector parameter (see Listing 3). You can find a detailed introduction to JMS message selectors in the Sun J2EE API documentation of the javax.jms.Message interface.

In this approach, the application container takes care of persisting the messages for you, which saves you from doing some redundant work. You also avoid a lot of tedious data conversion because you are working with JMS Message objects the whole time.