Extending Spring JMX support

The Spring framework minimizes architectural dependencies and externalizes composition in your applications, but applications also need to be managed. Fortunately, Spring 1.2 includes sophisticated JMX integration support -- and JMX delivers a practical management infrastructure for your applications. In this article, Claude Duguay takes Spring JMX a step further, showing you how to add notification events to methods and attributes transparently. The resulting code lets you monitor state changes without cluttering up your Java™ objects.

While the Spring framework's JMX management infrastructure is solid right out of the box, it does allow room for customization, particularly as you get into the higher level functionality afforded by Model MBeans. In this article, I use a relatively simple exercise -- adding notification events to Spring-based application methods and attributes -- to help you get comfortable with customizing Spring JMX. After following my example from start to finish, you'll be on the path to fine-tuning Spring's JMX management infrastructure for your application needs.

I'll start with a high-level overview of the JMX API, the Spring framework, and Spring JMX, and then move on to developing the extensions. My first extension lets me configure MBean metadata using an external XML format, which (like Hibernate mapping files) can be stored in the classpath alongside Java objects. My second extension adds a simple naming convention to the ModelMBean class to transparently configure customized notification messages. The new notification messages are triggered when attributes change or either before or after specific methods are called.

I conclude the article with a working example based on a mockup service object with both start and stop methods and a read-write attribute to be managed. I test the implementation with a small client/server application designed for that purpose. The application server is a standard Java 5.0 MBeanServer supplemented with an HTTP adaptor from the MX4J open source project. See Download for the article source and Resources for technology downloads.

Overview of JMX

Java Management Extensions (JMX) is the Java-based standard for managing and monitoring services on the network. At the heart of the JMX API are manageable beans, or MBeans. MBeans provide the instrumentation layer for manageable resources like applications, services, and devices. In a nutshell, MBeans provide a flexible, adaptor-based architecture for exposing the attributes and operations of Java-based (or Java-wrapped) resources. Once exposed, these resources can be monitored and managed using a browser and an HTTP connection or through protocols such as SMTP or SOAP.

Written and deployed MBeans are exposed via MBeanServer instances to bring interactivity to various application views. MBeanServer instances can also be combined into arbitrary federated relationships to form more complex, distributed environments.

The JMX standard offers four MBean variants:

• Standard MBeans directly implement the methods used to manage an object, either by implementing a programmer-defined interface that has a class name ending in "MBean" or by using a Standard MBean instance, which takes a class as a constructor argument, along with an optional interface class specification. The interface can be used to expose a subset of the object's methods for use in management.
  
  
• Dynamic MBeans dynamically access properties using attribute accessors and invoke methods using a generalized invoke() method. Available methods are specified in an MBeanInfo instance. This approach is more flexible but not as type-safe as Standard MBeans. Coupling is dramatically reduced and manageable POJOs (plain old Java objects) do not need to implement specific interfaces.
  
  
• Model MBeans provide an improved layer of abstraction and extend the Dynamic MBean model to further remove dependencies on a given implementation. This is helpful when multiple versions of the JVM might be at play or when third-party classes need to be managed with looser coupling. The main difference between Dynamic MBeans and Model MBeans is the additional metadata available in Model MBeans.
  
  
• Open MBeans are a restricted version of Model MBeans that reduce types to a fixed set to maximize portability. By restricting data types, more adaptors can be applied and technologies such as SMTP can more easily accommodate the management of Java applications. This variant also specifies standard structures such as arrays and tables for improved compound object management.

Standard MBeans are the easiest variant to implement if you control both the client and the server. They have the advantage of being typed but lose some flexibility when applied in more generalized management console environments. If you plan to use Dynamic MBeans, you may as well make the leap to Model MBeans, which in most cases will improve the abstraction layer with virtually no additional complexity. Open MBeans are the most portable variant and the only way to go if you need to expose compound objects. Unfortunately, the amount of code required to expose compound structures in Open MBeans is prohibitive and only warranted if you require a sophisticated commercial management solution.

JMX also supports notification using an event model with filters and broadcasters. For this to work, Standard MBeans require the declaration of an MBeanInfo metadata description. Standard MBean implementations often construct these internally but they are never seen directly by the developer. Later in this article, you'll see how to use an XML descriptor format for Model MBean metadata and Spring's JMX support to make configuration virtually transparent.