By John-Axel Stråhlman | Article Rating: |
|
October 8, 2005 03:00 PM EDT | Reads: |
18,980 |
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:
- 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.
- 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.
- 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.
- 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.
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:
- 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.
- 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).
- 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.
Published October 8, 2005 Reads 18,980
Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By John-Axel Stråhlman
John-Axel Stråhlman is the founder and CEO of Sanda Interactive Ltd (www.stc-interactive.com), a software consulting company based in Espoo, Finland. He is a distributed systems specialist and has been working as a consultant for his clients' projects for more than five years.
![]() |
John-Axel Strahlman 11/01/05 08:45:37 AM EST | |||
You are right Neil, the amount of MBeans is breathtaking. However, they are very thoroughly and conveniently documented in the WLS 8.1 API Reference, which can be found here: http://e-docs.bea.com/wls/docs81/javadocs/index.html Look under the weblogic.management.runtime package for MBeans that are most suitable for monitoring. For instance, the JMSDestinationRuntimeMBean is very useful for monitoring JMS destinations. John-Axel |
![]() |
Neil Hornbeck 10/27/05 08:32:34 AM EDT | |||
This is all excellent advice. The only catch is that there are so many MBeans in WebLogic that is almost impossible to determine which MBeans are critical to monitor, and which attributes of these MBeans tell you what you need to know. Just dumping the MBean list is overwhelming. BEA should publish a guide to the top 50 or so beans and just what exactly they can tell us. |
Apr. 26, 2018 12:45 PM EDT Reads: 403 |
By Yeshim Deniz ![]() Apr. 26, 2018 12:00 PM EDT Reads: 5,328 |
By Elizabeth White ![]() Apr. 26, 2018 11:45 AM EDT Reads: 7,320 |
By Yeshim Deniz Apr. 26, 2018 11:15 AM EDT Reads: 988 |
By Liz McMillan ![]() Apr. 26, 2018 11:15 AM EDT Reads: 7,420 |
By Yeshim Deniz Apr. 26, 2018 11:00 AM EDT Reads: 1,253 |
By Liz McMillan ![]() Apr. 26, 2018 11:00 AM EDT Reads: 10,011 |
By Elizabeth White Apr. 26, 2018 11:00 AM EDT Reads: 1,961 |
By Elizabeth White ![]() Apr. 26, 2018 09:45 AM EDT Reads: 6,724 |
By Pat Romanski ![]() Apr. 26, 2018 08:45 AM EDT Reads: 8,917 |
By Liz McMillan ![]() Apr. 26, 2018 06:45 AM EDT Reads: 6,676 |
By Elizabeth White ![]() Apr. 26, 2018 05:15 AM EDT Reads: 6,206 |
By Elizabeth White ![]() Apr. 26, 2018 04:45 AM EDT Reads: 8,909 |
By Yeshim Deniz Apr. 26, 2018 03:00 AM EDT Reads: 3,265 |
By Elizabeth White Apr. 25, 2018 11:45 PM EDT Reads: 7,122 |
By Elizabeth White ![]() Apr. 25, 2018 11:00 PM EDT Reads: 6,598 |
By Yeshim Deniz Apr. 25, 2018 11:00 PM EDT Reads: 2,757 |
By Yeshim Deniz ![]() Apr. 25, 2018 10:00 PM EDT Reads: 6,973 |
By Liz McMillan ![]() Apr. 25, 2018 09:15 PM EDT Reads: 17,662 |
By Pat Romanski ![]() Apr. 25, 2018 09:15 PM EDT Reads: 4,327 |