email article printer friendly more resources

Design Patterns, JMX for Manageability
Consider the manageability needs of your application during the design phase
by Justin Murray

February 17, 2005

The Java Management Extensions (JMX) technology is a key part of both the Java 2 Platform's Standard Edition (J2SE) 5 and Enterprise Edition (J2EE). Support for this standard is now required in J2EE-compliant application servers, some of which use JMX MBeans as the base infrastructure. Design patterns have been popular since they were introduced (see Resources), and we can apply design ideas to the manageability part of an application.

We'll describe a set of design patterns for making applications easier to manage in production by combining them with the use of JMX and logging, while making policies external to the code. This part of the application is important to the architect because most of the application's life cycle will be in its deployment phase. Controls and visibility are necessary for operations people to monitor and manage the application well. Monitoring and managing applications are best done today by instrumenting the application with JMX for certain dynamic requirements continuing to use the more traditional logging for other purposes.

You can build your own custom MBeans to be used alongside the application server-supplied or Java Virtual Machine (JVM)-supplied MBeans. This assembly is best done when the manageability requirements of the application's internal workings demand higher visibility to the application's internal objects and attributes. Logging messages to files or other destinations from the application is a common technique that gives the operations personnel some degree of monitoring the running product. Logging messages is an effective method for tracking exceptions or static error conditions (from informational to fatal) that occur within the application. Logging is essential for letting operations know what is happening inside the application.

However, for rapidly changing application performance data—that is, data for measured quantities in the overall performance of the application—log files do not make a good fit. It is not a good idea, for example, to put a new log message out as a counter for each user that logs into a system, when that number can change each second or more frequently.

Data Capture
It makes better sense to collect that rapidly changing data in an object—a JMX MBean—and gather values periodically from that MBean into a management tool. This technique can be used to capture the number of transactions in progress in the system, for example, or the length of a queue that contains requests waiting to be processed. Comparing the number of business transactions being processed with the number waiting to be processed in the queues may give us a good picture of how well the application is behaving.

Using MBeans in this manner is one of the best practices for using JMX. MBeans are good objects for counting quantities that need to be made visible to the management of the application. These items may be graphed over time when they are eventually collected from the MBean to show relative performance, or to show one of the application's other business metrics. JMX MBeans may be used for quantities that are unchanging, such as a warning, exception, or error message, but that is not their best use.