JMX Overview

JMX is the subject of JSR-3. It is a specifically created by an expert group with decades of network and system-management experience. The idea was to create a model and an API that facilitates the large-scale monitoring and management of Java-based systems and components. The specification addresses software components and services, as well as embedded devices using Java internally.

JSR-3 not only covers devices and services being controlled by an external entity but also the model and API enable the creation of network-management systems or enterprise-management systems using the Java programming language. Detailed attention is paid to backward compatibility with existing devices and services, as well as existing network-management systems. JMX is compatible with (and can work concurrently with) established network-management protocols, including Simple Network Management Protocol (SNMP) and the Common Information Model (CIM).

The JMX Levels

The model described in JSR-3 consists of three distinct layers. Each of these layers is the subject of a different specification. Figure 7-1 illustrates the JMX levels.

Figure 7-1: JMX levels

In Figure 7-1, the bottommost layer is the Instrumentation level, which is discussed next.

Instrumentation Level

The JMX model on the Instrumentation level describes how devices and software components can expose attributes and operations for management. It defines a set of standard Java interfaces that enable a manager (from the Agent level) to monitor, manage, and/or control the device or component. Management attributes are exposed by the device or component via the creation of Managed Beans (MBeans), which are JavaBeans that represent the resources being managed.

Each MBean can expose attributes for management. These attributes are equivalent to JavaBean properties; their value may be read or written to by the management agent. For example, a message queue MBean may want to expose the number of messages as an attribute. MBeans can also expose operations, which are equivalent to method invocations. For example, an MBean for a server may expose an operation named reboot to enable an agent to reboot the server. Last, but not least, MBeans can also choose to fire notification events. For example, a disk device with Java-based controller software may fire a notification if it is 80 percent full.

Even though MBeans are always accessed through components in the Agent level, they have no special knowledge of these components. The Instrumentation level is separate from, and not dependent on, the Agent-level components.

Agent Level

MBeans are aggregated at the Agent level by an MBean server. An MBean server provides the link between the MBeans and external management applications or higher-level distributed services. The MBeans themselves are not aware of interactions with external agents. Instead, the MBean server is responsible for providing the API to locate and retrieve the MBeans.

The MBean server is free to use either the MBean’s interface and expose that to the next level or choose to expose its own interface and then perform operations on the aggregated interfaces of the MBeans. As an example, an MBean server performing a cluster shutdown operation on behalf of a management application may implement the shutdown operation by iterating through the administration MBeans from every Geronimo server in a cluster and shutting it down. Figure 7-2 shows the composition of the JMX Agent level.

Figure 7-2: JMX Agent level

By having an Agent level, the development of MBeans in the Instrumentation level can be made completely independent of the development of network management systems. This clean decoupling allows instrumentation and management tools development to proceed at their own pace. For example, all of the GBeans in a Geronimo server are instrumented for management (MBeans are available), and this is all done without the need to know what management tool may be used to access the MBeans.

Also at the Agent level is connector code that enables concurrent access to the aggregated MBeans by multiple incoming requests. Requests coming into the MBean server may actually be from different network-management applications using different network-management protocols. This will require the service of protocol adapters and converters; these protocol converting components also live at the Agent level. For example, a protocol adapter may enable a Geronimo server to be monitored and managed by an SNMP-based management system.

Last, but not least, the Agent layer also contains a well-defined set of agent services that can be used by any developers writing value-added logic at the Agent level. For example, a timer service is available for one-shot timing, and a monitoring service is available for monitoring changes to an MBean attribute.

Distributed Services Level

Distributed Services in JMX represent the highest-level networked services that communicate with the agents at the Agent level to perform network-management tasks. Typically, large network-management systems have services running on a network. For example, a distributed service may monitor a set of MBean servers for exception conditions with the MBeans that they aggregate.

The specification at the Distributed Services level will describe the API and model for creating distributed network-management applications. As of this writing, the specification for the Distributed Services level of JMX is not yet available.