JMX

The success of the full open-source J2EE stack lies with the use of JMX. JMX is the best tool for integration of software. It provides a common spine that allows you to integrate modules, containers, and plugins. Figure 2.1 shows the role of JMX as an integration spine, or bus, into which components plug. Components are declared as MBean services that are then loaded into JBoss. The components may subsequently be administered by using JMX.

Figure 2.1. The JBoss JMX integration bus and the standard JBoss components.

An Introduction to JMX

Before we look at how JBoss uses JMX as its component bus, it would help to have a basic overview of what JMX is by touching on some of its key aspects.

JMX components are defined by the JMX instrumentation and agent specification, version 1.2, which is available from the JSR003 web page, at http://jcp.org/en/jsr/detail?id=3. The material in this JMX overview section is derived from the JMX instrumentation specification, with a focus on the aspects most used by JBoss. You can find a more comprehensive discussion of JMX and its application in JMX: Managing J2EE with Java Management Extensions (Sams Publishing).

JMX is a standard for managing and monitoring all varieties of software and hardware components from Java. Further, JMX aims to provide integration with the large number of existing management standards. Figure 2.2 shows examples of components found in a JMX environment and illustrates the relationships between them as well as how they relate to the three levels of the JMX model:

• Instrumentation These are the resources to manage.

• Agents These are the controllers of the instrumentation-level objects.

• Distributed services These are the mechanism by which administration applications interact with agents and their managed objects.

Figure 2.2. The relationships between the components of the JMX architecture.

The JMX Instrumentation Level

The instrumentation level defines the requirements for implementing JMX manageable resources. A JMX manageable resource can be virtually anything, including applications, service components, devices, and so on. The manageable resource exposes a Java object or wrapper that describes its manageable features, which makes the resource instrumented so that it can be managed by JMX-compliant applications.

The user provides the instrumentation of a given resource using one or more managed beans, or MBeans. There are four varieties of MBean implementations: standard, dynamic, model, and open. The differences between the various MBean types are discussed in the section "MBeans," later in this chapter.

The instrumentation level also specifies a notification mechanism. The purpose of the notification mechanism is to allow MBeans to communicate changes with their environment. This is similar to the JavaBean property change notification mechanism, and can be used for attribute change notifications, state change notifications, and so on.

The JMX Agent Level

The JMX agent level defines the requirements for implementing agents. Agents are responsible for controlling and exposing the managed resources that are registered with an agent. By default, management agents are located on the same hosts as their resources. This collocation is not a requirement.

The agent requirements make use of the instrumentation level to define a standard MBeanServer management agent, supporting services, and a communications connector. JBoss provides both an HTML adaptor and an RMI adaptor.

The JMX agent can be located in the hardware that hosts the JMX manageable resources when a Java Virtual Machine (JVM) is available. This is how the JBoss server uses MBeanServer. A JMX agent does not need to know which resources it will serve. JMX manageable resources may use any JMX agent that offers the services they require.

Managers interact with an agent's MBeans through a protocol adaptor or connector, as described in the next section. The agent does not need to know anything about the connectors or management applications that interact with the agent and its MBeans.

The JMX Distributed Services Level

The JMX specification notes that a complete definition of the distributed services level is beyond the scope of the initial version of the JMX specification. This is indicated by the component boxes with the horizontal lines in Figure 2.2. The general purpose of this level is to define the interfaces required for implementing JMX management applications or managers. The following points highlight the intended functionality of the distributed services level, as discussed in the current JMX specification:

• It provides an interface for management applications to interact transparently with an agent and its JMX manageable resources through a connector.

• It exposes a management view of a JMX agent and its MBeans by mapping their semantic meaning into the constructs of a data-rich protocol (for example, HTML, SNMP).

• It distributes management information from high-level management platforms to numerous JMX agents.

• It consolidates management information coming from numerous JMX agents into logical views that are relevant to the end user's business operations.

• It provides security.

The distributed services level components are intended to allow for cooperative management of networks of agents and their resources. These components can be expanded to provide a complete management application.

JMX Component Overview

This section offers an overview of the instrumentation- and agent-level components. The instrumentation-level components include the following:

• MBeans (standard, dynamic, open, and model MBeans)

• Notification model elements

• MBean metadata classes

The agent-level components include the following:

• The MBean server

• Agent services

MBeans

An MBean is a Java object that implements one of the standard MBean interfaces and follows the associated design patterns. The MBean for a resource exposes all necessary information and operations that a management application needs to control the resource.

The scope of the management interface of an MBean includes the following:

• Attribute values that may be accessed by name

• Operations or functions that may be invoked

• Notifications or events that may be emitted

• The constructors for the MBean's Java class

JMX defines four types of MBeans to support different instrumentation needs:

• Standard MBeans These use a simple JavaBean-style naming convention and a statically defined management interface. This is the most common type of MBean used by JBoss.

• Dynamic MBeans These must implement the javax.management.DynamicMBean interface, and they expose their management interface at runtime, when the component is instantiated, for the greatest flexibility. JBoss makes use of Dynamic MBeans in circumstances where the components to be managed are not known until runtime.

• Open MBeans These are an extension of Dynamic MBeans. Open MBeans rely on basic, self-describing, user-friendly data types for universal manageability.

• Model MBeans These are also an extension of Dynamic MBeans. Model MBeans must implement the javax.management.modelmbean.ModelMBean interface. Model MBeans simplify the instrumentation of resources by providing default behavior. JBoss XMBeans are an implementation of Model MBeans.

Later in this chapter, you'll see an example of a Standard MBean and a Model MBean, when we discuss extending JBoss with your own custom services.

The Notification Model

JMX notifications are an extension of the Java event model. Both the MBean server and MBeans can send notifications to provide information. The JMX specification defines the javax.management package Notification event object, NotificationBroadcaster event sender, and NotificationListener event receiver interfaces. The specification also defines the operations on the MBean server that allow for the registration of notification listeners.

MBean Metadata Classes

A collection of metadata classes that describe the management interface of an MBean. Users can obtain a common metadata view of any of the four MBean types by querying the MBean server with which the MBeans are registered. The metadata classes cover an MBean's attributes, operations, notifications, and constructors. For each of these, the metadata includes a name, a description, and its particular characteristics. For example, one characteristic of an attribute is whether it is readable, writable, or both. The metadata for an operation contains the signature of its parameter and return types.

The different types of MBeans extend the metadata classes to be able to provide additional information, as required. This common inheritance makes the standard information available, regardless of the type of MBean. A management application that knows how to access the extended information of a particular type of MBean is able to do so.

The MBean Server

A key component of the agent level is the MBean server. Its functionality is exposed through an instance of javax.management.MBeanServer. An MBean server is a registry for MBeans that makes the MBean management interface available for use by management applications. The MBean server never directly exposes the MBean object itself; rather, an MBean's management interface is exposed through metadata and operations available in the MBean server interface. This provides a loose coupling between management applications and the MBeans they manage.

MBeans can be instantiated and registered with the MBean server by the following:

• Another MBean

• The agent itself

• A remote management application (through the distributed services)

When you register an MBean, you must assign it a unique object name. The object name then becomes the unique handle by which management applications identify the object on which to perform management operations. The operations available on MBeans through the MBean server include the following:

• Discovering the management interfaces of MBeans

• Reading and writing attribute values

• Invoking operations defined by MBeans

• Registering for notifications events

• Querying MBeans based on their object names or their attribute values

Protocol adaptors and connectors are required to access the MBean server from outside the agent's JVM. Each adaptor provides a view via its protocol of all MBeans registered in the MBean server to which the adaptor connects. An example of an adaptor is an HTML adaptor that allows for the inspection and editing of MBeans by using a web browser. As indicated in Figure 2.2, there are no protocol adaptors defined by the current JMX specification. Later versions of the specification will address the need for remote access protocols.

A connector is an interface that management applications use to provide a common API for accessing the MBean server in a manner that is independent of the underlying communication protocol. Each connector type provides the same remote interface over a different protocol. This allows a remote management application to connect to an agent transparently through the network, regardless of the protocol. The specification of the remote management interface will be addressed in a future version of the JMX specification.

Adaptors and connectors make all MBean server operations available to a remote management application. For an agent to be manageable from outside its JVM, it must include at least one protocol adaptor or connector. JBoss currently includes a custom HTML adaptor implementation and a custom JBoss RMI adaptor.

Agent Services

The JMX agent services are objects that support standard operations on the MBeans registered in the MBean server. The inclusion of supporting management services helps you build more powerful management solutions. Agent services are often themselves MBeans, which allow the agent and their functionality to be controlled through the MBean server. The JMX specification defines the following agent services:

• A dynamic class-loading MLet (management applet) service This service allows for the retrieval and instantiation of new classes and native libraries from an arbitrary network location.

• Monitor services These services observe an MBean attribute's numerical or string value and can notify other objects of several types of changes in the target.

• Timer services These services provide a scheduling mechanism based on a onetime alarm-clock notification or on a repeated, periodic notification.

• The relation service This service defines associations between MBeans and enforces consistency on the relationships.

Any JMX-compliant implementation will provide all these agent services. However, JBoss does not rely on any of these standard agent services.