To ensure that everything works optimally, remember to configure appropriate redelivery limits and redelivery delays in your config.xml file by using the RedeliveryLimit and RedeliveryDelayOverride parameters, respectively.

In addition to developing a message-management system, you should also consider building suitable monitoring tools that keep an eye on your destinations for you. The WebLogic console gives you most of the statistics you need, but there are many good reasons to make that data available from your own management system as well - you have more control that way and access to the console of a production system is usually restricted.

Reading server statistics is remarkably straightforward through the Java Management Extensions (JMX) framework. By using JMX, you will always know what's going on inside your server, and JMS is just one of the many services that are easily monitored with it.

Using JMX for monitoring JMS destinations
JMX is fully supported by the WebLogic Server, which means that almost all WebLogic functionality can be monitored through it. If you haven't done so yet, print a listing of all the MBeans (JMX objects representing managed resources) residing in your server and you will be amazed by the wealth of information available to you. It is a good idea to have a separate process polling all of the most critical MBeans and comparing the values against predefined warning levels.

For retrieving JMS statistics, you first need to acquire JMS MBeans such as the weblogic.management.configuration.JMSQueueMBean and the weblogic.management.runtime.JMSDestinationRuntimeMBean for the destination you want to monitor. These two classes contain several accessor methods for looking up JMS statistics from the server. For instance, you can get the total number of bytes received by a destination or current number of bytes queued, just to name a few things. See the WebLogic documentation for details on how to acquire and use MBeans.

Conclusion
Enterprise messaging has become ubiquitous; whatever kind of service you are building, it is very likely that before long, you will need to share data between other services or simply between processes within your cluster. JMS is the de facto industry standard for the task, and if you still aren't convinced of all its benefits, take a look at my previous article in the Jan/Feb edition of WLDJ entitled "Distributing Tasks in a Clustered Environment Using JMS," and you will see that JMS is about much more than asynchronous data transfer. It is available on the WLDJ Web site under the Archives section (Vol: 4 Iss: 1).

Whatever your usage of enterprise messaging is, you need to prepare for complications. If you have strict requirements for data integrity, make sure you have proper monitoring in place and that you have a carefully thought out strategy for handling messaging problems, such as message processing failures. Appropriate tools are readily available and they are easy to use, so there is no excuse for being unprepared when you find yourself in a messaging mess.

References

• Yochem, A., Carlson, D., and Stephens, T. (2004). J2EE Applications and BEA WebLogic Server. Prentice-Hall.
• Programming WebLogic JMS: http://e-docs.bea.com/wls/docs90/jms/index.html
• Developing Custom Management Utilities with JMX: http://e-docs.bea.com/wls/docs90/jmx/index.html