Apply JMX Best Practices
Learn five key best practices for using JMX to build more management-ready applications
by Chris Peltz and Pankaj Kumar

December 10, 2004

Java applications are being built with many complex, distributed components. Nearly all applications today interface with legacy systems or other IT resources. The distributed nature of these applications provides an incredible challenge for IT, which carries the burden of maintaining the application, and all its dependencies, once it's been developed.

The problem is further complicated as organizations begin to adopt Service-Oriented Architectures (SOAs). SOA introduces a design style where applications are exposed as services connected in a loosely coupled fashion. In an SOA approach, application components are often developed with different programming languages and platforms. In some cases the connection between a client and a service provider is not determined until runtime.

Organizations looking to leverage SOA now require a better way to manage their distributed applications and services. Use of well-established, low-level management technologies such as SNMP is no longer sufficient to handle the heterogeneous and dynamic nature of today's applications. A service-oriented style of management is needed—META Group refers to this as a Service-Oriented Management Architecture or (SOMA). (see Resources.)

SOMA allows for the peaceful coexistence of heterogeneous, managed systems and management applications. A service-oriented style to management can eliminate the artificial barriers that exist today because of dependence on specific management APIs on specific platforms. Let's take a closer look at how SOMA can be realized in Java through the Java Management Extension (JMX) API.

In addition to allowing better integration among management products, SOMA can make it easier to develop custom management applications. While organizations often rely on out-of-box management solutions, there also may be a need to build customized dashboards for monitoring specific subsets of management data. An SOA style to management would enable a team to quickly build a management application using data fed from Web services, a common technology used in SOA implementations.

SOMA Says
It's important to make a distinction between a management interface and a management implementation. The design principles outlined in a SOMA are concerned mostly with the interfaces between a managed system and the applications being managed. SOMA says nothing about the underlying implementation used in exposing a managed resource. An application might be instrumented with a particular API and exposed with a different management interface. For example, Java developers might use JMX to add manageability in their application. JMX enables developers to instrument their applications with JMX MBeans so that a JMX MBean server can discover and access these managed resources.

JMX is more than just a programming API; it defines an architecture consisting of monitoring and management services and a distributed layer consisting of connectors and adapters. A developer could use a standard RMI connector to expose the management interface externally. However, using an RMI connector may not be the best approach if you are looking to expose more of a service-oriented management interface.

Several management standards have already been proposed to address SOMA. Early work done by Hewlett-Packard (HP) led to one of the first SOA-based management standards: Web Services Management Framework (WSMF). HP contributed WSMF to the Web Services Distributed Management (WSDM), an OASIS technical committee created to define specifications for Web services interfaces for manageable resources.

It is our belief that the industry will develop WSDM protocol adapters for JMX and other SOA-based management standards. The general concept is that a WSDM protocol adapter would enable a WSDM client or management application to interface with JMX MBeans using Web services protocols (see Figure 1).

If developers are looking to JMX for manageability, how do they get to a SOMA? Luckily, there are a number of good proof points demonstrating mapping JMX to an SOA-style of management. For example, HP released the HP OpenView Smart Plug-In (SPI) that manages and monitors business processes in WebLogic Integration (see Resources). The SPI had to include a bridge between the JMX MBeans exposed by BEA Weblogic Integration and WSMF-based interfaces.

From our own experience, we have identified several obstacles in mapping JMX to Web services. Overcoming these challenges required us to think in terms of services and loosely coupled architectures. Design principles such as simplicity, modularity, and interoperability had to be applied.

For example, a typical JMX MBean assumes a fairly tight coupling with a client, exposing many low-level details about a manageable resource. A JMX MBean might map to a Java class or Enterprise JavaBean (EJB). We would not want to map this MBean to a single Web services end point. Instead, SOA requires a more coarse-grained approach for exposing manageability.

Interoperability between datatypes used by Java and Web services is also a key challenge that must be solved. We discovered that the datatypes used by a JMX interface cannot be translated automatically into Web services datatypes. Additionally, a JMX MBean could return a remote reference to a Java object, which has no counterpart in the Web services world.

Management Challenge
As we studied the programming model and architecture defined by JMX, we saw a clear distinction between a programming interface and a management model. JMX provides a very flexible and powerful API for instrumenting applications for manageability, but using JMX alone does not define or impose any particular management model.

Well-established management models are essential to feature-rich management applications. Without such management models, it becomes a challenge to consistently extract and process management data across applications.

Finally, several important management abstractions are defined in the emerging Web services management specifications that are not fully supported in JMX. For example, the WSDM Management Using Web Services (MUWS) includes a wire-level specification for exchanging management information based on Web services technologies. This specification models management capabilities for Metrics, ResourceState, and Relationships (see Figure 2).

JMX fails to adequately model many of these capabilities. For example, although JMX defines a Relation service for relationships among MBeans, it can be quite complex to use and is rarely implemented in practice. Capabilities such as Metrics and State are also not directly supported by JMX. For example, there are no predefined classes in JMX to represent different kinds of metrics.

These shortcomings make automated conversion of manageability interfaces from JMX to SOA quite a challenge. To help you overcome some of these challenges, we present a series of five best practices for JMX development in preparation for WSDM. We believe the incorporation of these practices would result in a better-managed application, independent of whether or not you plan to use WSDM.

Best practice 1: start with a management model. A management model defines the management information exchanged and the underlying semantics of that information. Using management models is essential to ensuring that managed resources are easy to discover, identify, and monitor for health and availability. Management models are also important for ensuring that applications can be uniformly configured and controlled at run time.

Applications do not exist in isolation; they have dependencies on other applications, systems, and network components. Application manageability, even when focused on a single application, must account for these dependencies. A management model should capture these dependencies and relationships.

Creating a management model requires you to think about manageability requirements early in the software life cycle. All too often, manageability is an afterthought for a developer. To truly succeed in building a SOMA, you must consider manageability and a management model from the very beginning. In fact, a good management model pays off irrespective of what technology you use to expose the manageability. In developing the management model, you should ask these questions: What are the managed resources? What are the states for the managed resource, and how will it be controlled? Are there relationships among the managed resources? What specific business or performance metrics do you need to keep track of? What additional management attributes and operations should be exposed? What event or message notifications are of interest to the managed resource?

Defining the Model
Understanding the answers to these questions can help you define a management model that can be leveraged across your IT infrastructure. You should also look at the management model from the perspective of the operator who must manage the application once it has been deployed.

Keep in mind that the management model exposed by an application is not the same thing as its internal structure. The goal of the former is to allow an external management system to effectively monitor, configure, and control the application; the goal of the latter is to implement the business functionality.

To illustrate, let's consider a Web application server that allows multiple Web applications or Web modules to be deployed, with each Web module consisting of one or more servlets (see Figure 3 for a highly simplified management model of this system).

This model defines states, notifications, metrics, attributes, and operations for each manageable resource. We will leverage this simplistic model to apply additional best practices around usage of JMX for manageability in a SOMA. Additionally, we developed the complete source code realizing this model.

Best practice 2: design for interoperability. Having a well-defined management model is the first step to SOMA. The Java community has recognized this need and has defined management models for both the J2SE and J2EE platforms through JSRs 77 and 174.

JSR 174, now a part of the J2SE 5.0 specification, provides a way to expose a management model for the Java Virtual Machine (JVM). It introduces the concept of platform MXBeans, which are specialized JMX MBeans modeled to represent certain JVM health indicators. These MXBeans can be used for monitoring memory usage, thread-contention issues, class-loading behavior, and garbage-collection frequency.

All MXBeans are implemented as OpenMBeans, a JMX MBean type that provides for an increased level of interoperability. OpenMBeans restrict the use of certain datatypes in the MBean interface. This restriction minimizes the client requirements for accessing the MBean, which further ensures that XML can be used to easily access and operate on these MBeans without resorting to specific marshalling and unmarshalling logic.

All MXBean operations and attributes must conform to a specific set of datatypes, called open types, which include primitive types (int, long, and boolean), enumerations, CompositeData types, and Map and List types. Listing 1 shows an example of a ServletMXBean interface that complies with these datatype requirements.

Note that J2SE 5 does not support the mapping of user-defined MXBeans to Open MBeans natively, meaning you can't introduce your own MXBeans and expect it to behave like platform MXBeans. It is possible to develop a generic set of classes to support registration of user-defined MXBeans to an MBeanServer as Open MBeans, and we hope that such classes will become available through the JCP process.

Even if you aren't directly using platform MXBeans, you can still design your JMX MBeans to conform to the Open MBean model. The end result will be a more interoperable JMX interface that can meet the needs of SOMA.

Complementing JMX
Best practice 3: leverage J2EE management mechanisms. JSR 77 proposes a management model for exposing management information for the J2EE platform. The model supports the ability to manage a number of J2EE resources, including EJBs, Web containers, JMS, and JDBC connections. The model can be used to gather, monitor, and control run-time information about the application server. This common model allows a management tool to easily manage multiple vendor implementations of J2EE.

JSR 77 defines a number of abstractions to complement JMX in handling performance statistics, application state, and relationships. It defines the Statistic interface, which is used to model performance data for J2EE components. For example, the model defines an EJBStats interface that specifies statistics for all EJB components. This interface exposes basic CountStatistics for tracking the number of objects created and removed:

public interface EJBStats extends 
	Stats {
	CountStatistic getCreateCount();
	CountStatistic getRemoveCount();

An object's state can be managed through the StateManageable interface. You can query for the state of a resource, and start and stop specific components. Additionally, JSR 77 defines a basic convention for representing relationships in the model. A containment relationship can be defined in which a specified container maintains an array of managed objects.

We can apply many of these design principles to our management model example (see Figure 4). We show how the MXBeans can be enhanced to support the capabilities of state management, events, metrics, and containment. Referring back to the source code in Listing 1, you will find that the Servlet MXBean interface defines the manageability interface of the Servlet Managed object as per the model described previously.

The use of metrics, statistics, state management, and relationships are important aspects of SOMA. Without these capabilities, it can be difficult to offer a consistent management interface for monitoring and managing your Java applications. Look to use some of these J2EE management mechanisms in your own development projects.

Best practice 4: use JMX notifications for communication. JMX defines an event model for managed objects that you would use to receive or generate events. An event mechanism is essential for handling critical events generated by a managed resource and for monitoring state change. Events can also be used to monitor service-level violations for a managed resource. The JMX notification mechanism allows MBeans to send notifications to other MBeans or other management applications. The design principles around notifications can be applied to our sample management model. For example, we may need to generate notifications whenever an attribute changes or a new module is added.

Listing 2 shows the implementation of the WebAppServerMXBean class, which includes an addWebModule() method that is called any time a new WebModule is added to the application server. Notice the creation of a Notification object and the call to sendNotification(). This method, inherited from the base class, uses a utility class (javax.management.NotificationBroadcasterSupport) for sending notifications.

Use of JMX notifications is a key design principle for SOMA. In a service-oriented design, you want the ability for the managed resources to easily communicate with the management system. JMX notifications allow you to more easily generate application events to be processed. Additionally, using a notification mechanism properly can alleviate potential performance problems by having the management system frequently poll the application for changes.

Time to Party
Best practice 5: separate management and business concerns. It is a good design practice to separate the business objects that need to be managed from the management interfaces that manage them. Many current JMX best practices do not make this separation explicit, leading to the development of applications that combine the business layer with the JMX interfaces.

Mixing these two aspects may have some serious consequences, such as the need to register a JMX MBean for each instance of a class. On the other hand, separating the management and business concerns allows the management interface to change independently of the business objects being defined.

You can apply a series of well-established design patterns to assist in modeling your management layer (see Resources). For example, the SeparateMBean pattern (see Figure 5) describes the creation of an MBean that is a separate object from the business object that must be managed. As business objects are created, they maintain a reference to a separate MBean object that acts as their management party.

Although our example doesn't include a real implementation of ServletMXBean, an implementation could use the SeparateMBean pattern, in which the MXBean is updated by the Servlet object.

Other design patterns can be helpful in achieving the right level of granularity in the Web services management interface. Because each MBean has costs associated with registration and lookup, designing too many MBeans will impact performance. By using facade patterns, you can minimize this performance impact and provide more coarse-grained interfaces to a management application.

It is also important to view the JMX management interface as a repository of management data, rather than as a repository of management logic. When you need to monitor the application for certain threshold violations, place this logic in the management system rather than in the managed application. Doing so provides more flexibility to update service-level monitoring after the application has been deployed.

As increasingly complex and distributed architectures are deployed, IT will need a more flexible, open architecture for managing the components of an SOA. Management technologies such as JMX provide solid solutions for instrumenting J2EE applications for manageability, but they are not sufficient.

To achieve SOMA, you must apply SOA principles to management, and that requires considering each application's requirements for manageability. Management capabilities then form the management model for a resource. Having a set of common management models is key to building standard management interfaces across vendor implementations.

Experience with Web services technologies emphasizes the importance of interoperability in the design, and your use of JMX technology should take care in selecting the right datatypes to alleviate these concerns. Additionally, you can look toward features provided in JSR 77 to help you build management capabilities into your application. However, using JMX takes more than just instrumenting your application with JMX. It requires careful planning around your manageability needs and also requires careful separation of management and business concerns to maximize your design's flexibility.

The recently introduced JSR 255 aims to update the JMX and JMX Remote APIs to improve the existing interfaces from a usability standpoint (see Resources). Our hope is that the revised specification will either incorporate or make it easier to use the best practices outlined here. We also are aware of efforts to introduce a separate JSR to explore possible approaches to bridging from JMX to Web services standards such as SOAP.

By incorporating the approaches to the JMX technology discussed here, you can more efficiently expose your JMX-instrumented applications with WSDM or some other management interface. In the end, you will have designed more management-aware applications that can meet the needs of the business.

For more information on JMX technology, visit HP's Dev Resource Central, where you can find a number of technical resources, articles, and tutorials on the subject (see Resources).

About the Author
Chris Peltz is a software technologist at Hewlett-Packard who has written several technical articles on application management solutions and has researched Web services and SOAs. Pankaj Kumar is a software architect at Hewlett-Packard who is responsible for management solutions based on WSDM and associated enablement efforts with partners. He is the author of (Prentice Hall PTR, 2003). Contact Chris at , and contact Pankaj at .