[ Index ] [ Individual Project ] [ Placement Presentation ] [ Timetable ]

Java Management Extensions Instrument and Agent Specification

Last Updated: 18th December 2001

Introduction

The Java Management Extensions (JMX) defines an architecture, design patterns, APIs, and services for application and network management in the Java programming language.

It is divided into three different layers:

Instrumentation Level (MBeans)
Agent Level
Distributed Services Level

The JMX architecture

Section 1 - Beans

The instrumentation level is composed of a resource that is managed by one or more Managed Beans, or MBeans. There are several different types of MBeans, aimed at making the system practical to use by given a developer the largest choice of how to implement instrumentation of his or her components. The different type of MBeans are:

Standard MBeans
Dynamic MBeans
Open MBeans
Model MBeans

MBeans have several aspects in common. There is a naming convention (normally implemented only by standard mbeans since the other types are for classes that were not built with management in mind. The management interface is exposed through MBean metadata classes, either explicitly for implicitly. There is a notification and broadcast model that all mbeans follow.

Standard MBeans

These are the beans of choice when a new component is written. It explicitly defines its management interface. The interface is what attributes of the component are exposed for management. The management interface is defined through a java Interface named MyClassMBean, which the class then implements. Since the management interface is defined in this manner there is no need to create the regular MBean metadata classes as the system can infer what they should contain.

Dynamic MBeans

While standard MBeans are useful when the management interface is know ahead of time, dynamic MBeans are useful when the interface changes. A dynamic mbean exposes its interface through a MBeanInfo object. A dynamic mbean can be created through implementing the DynamicMBean Interface. Since the management interface is determined by calling the getMBeanInfo method on the mbean, it can be altered dynamically at runtime.

Notification Model

Since different parts of the system may need to react to changes in state, the JMX architecture provides a notification model. It allows mbeans to broadcast notifications and, other objects can register as listeners to the broadcaster.

Unlike the Java event model, Notification is the only class that can be sent as a notification, i.e. it does not use sub-classes as a way to interpret what type the notification was. The Notification class has a type field which contains the the type of the notification in standard 'dot-separated component' notation, e.g. jmx.mbean.registered. Other interfaces exist to all listeners to filter the types of notifications they receive.

N.B How notifications are transmitted to remote management applications is not covered in this phase of the specification.

Open MBeans

These MBeans are aimed to be used by the widest range of management applications, not just an MBean server. This is achieved by restricted what basic types each MBean can have and the structure of their more complex types.

The full specification of Open MBeans is not part of the JMX 1.0 specification. So it is unlikely that an implementations will contain the classes necessary to generate these types of MBeans.

Model MBeans

A model mbean is a type of dynamic mbean designed to allow any resource to be instrumented quickly. It is part of the JMX specification hence all conforming implementations will be able to use them.

Given that this project will most likely design a mbean to instrument a library jar, model mbeans are unlikely to be useful. Their concept may prove a useful base to design a generic dynamic mbean to allow the tool to be used with existed java libraries.

Section 2 - Agent

The JMX agent is a management entity that runs in the JVM and acts as a liaison between the mbeans and the management application. It is composed of:

JMX server
MBeans representing the managed resources
A minimum set of agent services, which are also mbeans
At least one protocol adapter or connector

Keys Concepts of the JMX Agent Architecture

The mbean server acts as the central registry for all the mbeans. All the management operations that are applied to the mbeans need to go through the server.

The services provided by the agent can either be the services specified in the JMX specification or those that are provided by third parties. The ones defined by the specification are:

Dynamic loading
Monitoring
Timer
Relation

For an agent to be JMX compliant it needs to provide all of the above components (in addition to the server).

A protocol adapter is to allow management applications that use a different protocol to manage these resources by providing a management view.

Connectors are used to allow remote JMX-enabled management applications to use the mbeans. The application would be developed using the JMX distributed services. The connector server will provide a remote interface to the mbean server. A connector is specific to a particular protocol, but the application can use any connector indifferently because they all provide the same remote interface.

N.B. Protocol adaptors and connectors are not covered in this phase of these specification, they are described here to provide a more complete overview of the agent's architecture.

The JMX architecture allows objects (agent-side or remote application) to perform the following operations on a JMX agent:

Manage existing mbeans by:
- Getting their attribute values
- Changing their attribute values
- Invoking operations on them
Getting notifications emitted by any mbean
Instantiate and register new mbeans from:
- Java classes already loaded into the agent JVM
- New classes downloaded from the local machine or from the network
Use the agent services to implement management policies involving existing mbeans

All these operations are performed, either directly or indirectly through the mbean server.

MBean Server

The mbean server is part of the agent. It is the component that acts as the registry for all the mbeans, and provides the services to manipulate them. All management operations are done through the MBeanServer interface. An agent can have one or more servers and it provides a static factory to create them.

The key responsibility of the mbean server is to registry mbeans. It can achieve this by instantiating a new one and registering it immediately, or by registering an existing mbean. Once registered, the mbean server can perform the following operations on the mbean:

Retrieve a specific mbean by its object name.
Retrieve a collection of mbeans by pattern matching and optionally filters using the query language.
Get one or more attributes on an mbean.
Invoke an operation on an mbean.
Discover the management interface (attributes and operations) or an mbean, this is known as introspection.
Register to receive notifications from a given mbean.

When an mbean is registered or deleted from the server a notification is broadcasted.

The remote interface for invoking operations on the mbean server have not been defined in this stage of the JMX specification. This will cause some sort of problems since it will force everything to be in the same JVM. Need to look at various implementations of JMX so far to see if they provide their own implementation of this important feature.

The MBeanServer provides methods for querying what mbeans are available. Details and examples can be found on pages 122-126 of the JMX specification.

Advanced Dynamic Loading (m-let service)

This service allows a JMX agent to retrieve and instantiate mbeans from a remote server. The dynamic loading is performed by the m-let service.

To use the service you must provide a url to a m-let text file, which describes the various mbeans on the remote server. The syntax of this file is described on pages 128-130.

Monitor Service

There exists a family of mbeans known as monitor mbeans, whose sole purpose is to monitor attributes of another mbeans in the system. The monitors can trigger notifications when certain monitor conditions have been met.

There are three provided monitor types, which are all derived from the same abstract Monitor class.

CounterMonitor
GaugeMonitor
StringMonitor

Counter Monitor This type of monitor emits a notification when a certain threshold value for an attribute has been reached or exceeded. When the threshold has been met you can also make the monitor roll over (e.g. go back to zero) or add an offset (notify at every 10).

Gauge Monitor This monitor type is used on numeric attributes. It has two threshold values, high and low. It can be configured to emit a notification when ever an attribute goes above the high value or below the low value.

String Monitor This monitors attributes of the type String. This monitor emits a notification when the attribute matches or differs from the monitor value. N.B. notifications are sent out over time so it is not just a one off monitor that always returns the notification.

Timer Service

This is just a service that can send out notifications are specified times or at a constant interval. It can be started and stopped.

Relation Service

This service allows relations between to be modeled by objects. The relation is user-defined, n-ary association with named roles. The relation service will then ensure the consistency of the relation when the mbeans are updated/created/deleted. The service also allows mbeans in a relation to perform queries to locate related mbeans.

Miles Barr <miles@milesbarr.com>