Extend Spring's JMX support

The Spring framework minimizes architectural dependencies and materializes the components in the application, but the application is still managed. Fortunately, Spring 1.2 includes advanced JMX integration support, and JMX provides a practical management infrastructure for applications. In this article, Claude Duguay further from Spring JMX, showing you how to transparently increase notification events for methods and properties. The resulting code allows you to monitor state changes without messing with Java? Object.

While the default configuration of the Spring framework's JMX management infrastructure is good, there is still room for customization, especially when it comes to higher-level features provided by Model MBean. In this article, I used a relatively simple operation-increasing notification events for methods and properties of spring based applications-to help you familiarize yourself with the custom of spring JMX. After completing my example from beginning to end, you will be able to tailor the Spring JMX management infrastructure to your application's needs.

I'll start with a simple review of the JMX API, Spring Framework, and spring JMX, and then move on to the development extension. The first extension allows me to configure MBean metadata in an external XML format, which, like Hibernate mapping files, can be stored with Java objects in the classpath. My second extension adds a simple naming convention for the Modelmbean class to transparently configure custom notification messages. A new notification message is triggered either before or after the property changes or when a particular method is invoked.

The end of the article is a practical example based on the Mockup service object, which needs to manage its startup and stopping methods and read-write properties. I tested this implementation with a small client/server application designed specifically for this purpose. The application server is a standard Java 5.0 Mbeanserver and complements the HTTP adapters originating from the mx4j Open source project.

JMX Overview

Java Management Extensions (JMX) is a java-based standard for managing and monitoring services on your network. The core of the JMX API is the managed bean, the MBean. MBean provides a facility layer for managed resources such as applications, services, and devices. In short, MBean provides a flexible, adapter-based architecture for opening properties and operations of java-based (or Java-packaged) resources. Once opened, you can use browsers and HTTP connections or monitor and manage these resources through protocols such as SMTP or SOAP.

The MBean that is written and deployed is open through the Mbeanserver interface to make the different application views interactive. Mbeanserver instances can also be combined into arbitrary federated relationships to form more complex distributed environments.

The JMX standard provides four different Mbean:standard MBean implementations for managing objects directly, either by implementing a programmer-defined interface that ends with the class name "MBean" or by using a Standard that takes a class as a constructor parameter An MBean instance, plus an optional interface class specification. This interface can be open to some of the object methods used for administration.

Dynamic MBean uses property accessors to dynamically access properties and calls methods with a generalized invoke () method. The available methods are specified in the Mbeaninfo interface. This approach is more flexible, but does not have type security like the Standard MBean. It dramatically reduces coupling, and manageable POJO (purely old-fashioned Java objects) do not need to implement specific interfaces.

The model MBean provides an improved abstraction layer and expands the Dynamic MBean model to further reduce the dependency on a given implementation. This can be useful for scenarios where multiple versions of the JVM may be used or where there is a need for loosely coupled management of third-party classes. The main difference between the Dynamic Mbean and the model Mbean is that there is additional metadata in the model Mbean.

The Open MBean is a restricted Model MBean, which restricts the type to a fixed set of types for maximum portability. By restricting data types, you can use more adapters, and technologies such as SMTP can be more easily adapted to the management of Java applications. This variant also specifies standard structures such as arrays and tables to improve the management of composite objects.

If you want to control both the client and the server, then the Standard MBean is one of the easiest variants to implement. The benefits are of a type, but there is a lack of flexibility if used in a more generalized management console environment. If you plan to use a Dynamic Mbean, you can also use the Model MBean more often, and in most cases it will improve the abstraction layer with little added complexity. The open MBean is the most portable variant and is the only way to open a composite object. Unfortunately, the amount of code required to open a composite structure in an open MBean is too large to be cost-effective only if you need a high-level business management solution.

JMX also supports notification of the use of event models with filters and broadcasters. For this purpose, the Standard MBean needs to declare a mbeaninfo metadata description. Standard MBean implementations typically construct these internally, and developers cannot see them directly. Later in this article, you'll see how to use the XML descriptor format of Model MBean metadata and Spring's JMX support for a virtually transparent configuration.