Improve Application Management With JMX
Leverage JMX technology and existing tools to boost the operations management capabilities of your business applications.
by Borislav Iordanov

Posted March 15, 2004

The explosion of enterprise computing in the last decade has led to the proliferation of large-scale, server-based applications, many of which are deployed within a complex mixture of software and hardware components. As the scope and complexity of applications grow, capabilities for efficient and flexible management of their proper operation become increasingly essential to the success of business activities. On one hand, systems administrators face the challenge of managing a diverse amalgam of system- and application-specific components, each with its own set of administration facilities. On the other hand, managers and decision makers seeking to improve business processes need appropriate tools for business activity monitoring (BAM).

The development of custom application management software follows a common pattern, but it's nontrivial and it usually requires considerable effort. Moreover, it leads to inconsistent, incompatible, and platform-dependent solutions that put an unnecessary burden on both application developers and system operators. These and similar considerations have led to the development of the Java Management Extensions (JMX) API, a Java Community Process (JCP) specification geared toward the simplification and standardization of the runtime management infrastructure of enterprise Java applications.

I'll first examine the concepts and architecture behind JMX technology, then outline several informal examples of JMX use. Finally, I'll present a concrete programming example to show how you can combine JMX with aspect-oriented programming (AOP) technology to instrument your application without disrupting core business logic.

JMX Concepts and Architecture
JMX is conceptually simple, yet bears the fruit of years of domain experience and research. In a nutshell, JMX defines a standard means for applications to expose management functionality, a process called instrumentation, and a standard management middle tier, the JMX agent, which acts as a single point of entry to management components. So, application management in JMX is architecturally divided into three levels (see Figure 1):

• Instrumentation level: The level at which applications expose their management functionality. Application instrumentation relies on a few naming conventions and Java interfaces, and is completely independent of the particular JMX agent or management application operating it.
• Agent level: A container of instrumented entities and a set of standard management services. The agent is the core of a JMX implementation. In addition to delivering the services mandated by the specification, implementations can provide extensions, most notably in the form of protocol adaptors and connectors for remote access.
• Management level: The client level, encompassing various management applications. These include generic tools providing direct access to one or several distributed JMX agents, application-specific solutions that rely on particular domain knowledge, and scripting environments for management automation.

All three levels revolve around the core concept in the JMX model—a managed bean, or MBean for short. An application is instrumented through managed beans. A managed bean is simply a concrete Java class that obeys certain rules, making objects of that class manageable by the JMX agent (or other MBean-aware agents) in a uniform way. A managed bean provides three types of instrumentation:

• Access to information through exposed attributes (readable, writable, or both).
• Reactive behavior through arbitrary published operations.
• Proactive behavior through notifications to registered listeners.

The main idea behind the MBean concept is the ability to expose dynamic management functionality for a runtime resource. Note, however, that an MBean can be a purely management object that handles the management of several related resources in concert. A programmer creates an MBean either by statically declaring the exposed attributes or operations in a conventional Java interface, or by implementing the special-purpose DynamicMBean interface. The two ways yield functionally equivalent results and, in both cases, the JMX agent and management applications have access to complete metadata about the MBean.

The JMX agent's most important role is providing MBean storage. Its core functionality is embodied in an instance of the MBeanServer interface through which managed beans are registered, created, removed, and searched. To facilitate global management solutions and the integration of disparate application components, a comprehensive naming scheme enables the agent and management applications to uniquely identify MBeans within the MBean server. In addition, management applications can rely on several advanced services the JMX agent provides, such as monitoring attributes' changes, timers, and MBean dynamic loading.

Apply the Technology
Given JMX technology's generality and flexibility, you can leverage it in a myriad of ways. Let me briefly outline some possible applications:

• Monitoring: Monitoring application and business activity is one of the most basic aspects of application management. You want to know how an application operates: Are there any faults? Is it performing well? What types of resources are insufficient or allocated in excess? Are resources properly released? What kinds of things do users do? By encapsulating such information into managed beans, developers can provide administrators with runtime notifications of suspicious activity, a standard interface to performance statistics, summaries of user activity, details on the state of the system (such as the number of jobs running), and more.
• Administration: Many applications come with a supporting administration interface. Administrative requirements are specific to the application, but usually fall into several common patterns such as managing user permissions, creating and removing various persistent business objects (such as a forum in an online community or a product listing in an e-commerce application), or managing the lifecycle of various components and services. By using JMX, you can simply expose this type of functionality as MBeans and access it through a common management console, or access it remotely without requiring the programmer to implement an admin user interface or any special-purpose admin services.
• Management automation: Managing deployed, mission-critical applications is a core business process. Automating this process translates into reliability, effectiveness, reduced costs, and predictability. JMX allows the transformation of any business object into a manageable service through a standard Java programming interface, so you can leverage existing scripting environments to automate repetitive management tasks.
• Dynamic service configuration: Usually a service is configured as part of the deployment process and the configuration cannot change at run time. JMX allows you to implement an on-the-fly service reconfiguration as part of its management interface. Common configuration examples are tracing level, resource pool size, an operation's timeout parameter, and some functionality's enable/disable flag. Exposing configuration parameters as writable MBean attributes automatically provides administrators with dynamic configuration capability.

A common thread in these scenarios is that instrumenting an application is the only task left to the programmer within the JMX infrastructure. As with any other aspect of application development, the instrumentation process requires proper planning and design. However, the clean decoupling of core business logic from management logic through the use of MBeans greatly facilitates the incorporation of instrumentation even at a later development stage. In the next section, I'll show a concrete programming example of how you can instrument an existing application without disrupting its main code.

Instrument Your Application
Assume this common situation: You have an existing application configured at startup time through a configuration file. The configuration is represented at run time by a single instance of your AppConfig class, which has methods for working with the configuration file and parameters. Many of your business objects rely on this singleton to get configuration parameters. Reconfiguring the application requires an administrator to know the configuration file well (format, location, and so on) in order to change it, and it also requires a server restart.

To remedy the situation, you could develop a proprietary administration console for your application and make it dynamically manageable—but you'd be in for a serious development ride. Or you could simply expose the AppConfig instance as a managed bean and be done with it. The exposed MBean attributes and operations will be automatically available to off-the-shelf management consoles, remote applications, and scripting environments.

Look at a sample AppConfig class (see Listing 1). The class has some general methods to read a property file, along with set and get individual properties. It could serve as part of a utility package you could reuse in different applications; you could directly expose those methods for management. However, this would not be helpful to administrators. Also, perhaps you can safely change only some of the configuration properties at run time. You're better off defining a management interface that directly reflects this application's particular configuration parameters.

As I explained, you can expose a management interface either from a conventional Java interface or by implementing the DynamicMBean generic interface. For simplicity, I use the former. With this approach, JMX mandates that you call the management interface AppConfigMBean and that the AppConfig class implements it. The AppConfigMBean interface exposes a few properties for management (see Listing 2).

Now, by using aspect-oriented programming (AOP) technology (see "Make Your Applications Operations Friendly With AOP"), you can integrate the instrumentation without interfering with the main application code. Check out the AspectJ source code that weaves the MBean interface implementation into the AppConfig class (see Listing 3). You can easily extend the code to support, for example, notifications on property changes and registration with the MBean server. No modifications—and with recent AOP tools, no recompilation—of the AppConfig class are needed.

By combining JMX and AOP, you can enhance your application's management abilities with only a few lines of code. Moreover, the MBean operations can embed "management intelligence" about the various configuration properties and guard against administrative mistakes. For instance, a URL property containing a service's address that your application needs might be changed to an invalid value. The MBean could perform a check and detect the error before committing the change to the application, which remains decoupled from all management activity.

Monitoring is another example where JMX and AOP play nicely. You can define aspects to monitor operations of interest and log the activity into managed beans that make all information available through a common management console—again without touching the core application.

Note that I've barely scratched the surface of JMX capabilities (for more information on JMX and AOP, see Resources). JMX is a fairly mature technology. The first final release of the standard came out nearly four years ago, and research started in 1995 during Java's early days. JMX is the outgrowth of the pioneering Java Management API (JMAPI) technology (1995) and the later Java Dynamic Management Kit. Today, nearly all J2EE application servers implement or use the technology, and many tools—such as management consoles, adaptors for legacy standards, and tools that automate instrumentation—have been developed in both open-source and commercial varieties.

About the Author
Borislav Iordanov is chief architect at Kobrix Software, a maker of rapid application development (RAD) tools for thin-client development.