This Tech Tip reprinted with permission by java.sun.com
Java Management Extensions (JMX) technology offers programmers the ability to add monitoring and management to their Java applications. In effect, these APIs allow you to locally or remotely manage anything Java-enabled, from web servers to network devices to web phones. JMX technology is defined by two closely related specifications developed through the Java Community Process (JCP): Java Specification Request (JSR) 3: Java Management Extensions (JMX) Specification and JSR 160: Java Management Extensions (JMX) Remote API 1.0. This tech tip introduces you to the JMX architecture, and shows you how to create a simple Managed Bean.
With JMX technology, an application, device, or service on one machine (called a resource), can be controlled remotely through the use of one or more custom JavaBean objects known as Managed Beans (MBeans). These MBeans are then registered in a core-managed object server (an MBean server). The MBean server acts as a management agent to any remote managers that want to access the resource.
The JMX Environment
The JMX specification defines an architecture in three distinct tiers. The first two levels shown are the instrumentation and agent tiers, which are defined by JSR 3:
- Instrumentation Tier. Resources, such as applications, devices, or services, are instrumented using Java objects called Managed Beans (MBeans). MBeans expose their management interfaces, composed of attributes and operations, through a JMX agent for remote management and monitoring.
- Agent Tier. The main component of a JMX agent is the MBean server. This is a core managed object server in which MBeans are registered. A JMX agent also includes a set of services for handling MBeans. JMX agents directly control resources and make them available for management.
The remote management level, the third tier, is partly defined by JSR 160:
- Remote Management Tier. This tier defines protocol adaptors and connectors that make a JMX agent accessible from remote management applications outside the agent's Java Virtual Machine (JVM)*. (Note that JSR 160 defines connectors only.) Connectors are used when the remote client is JMX-aware, and sees the same JMX API as a local client would. Adaptors are used when the remote client is using a generic management protocol such as Simple Network Management Protocol (SNMP) or Common Information Model and Web Based Enterprise Management (CIM/WBEM).
There are generally three types of developers who use JMX, although one person might exercise all three roles:
- A developer that writes MBeans to manage resources. Here, JMX technology defines the interfaces exposed for management. The developer is responsible for the "glue" between the MBean and the resource itself.
- A developer that creates and deploys the agent. This person typically performs a number of tasks, including:
- Creating an MBean server, or using the one supplied by the platform.
- Registering the MBeans that represent the resources using MBean naming conventions.
- Configuring the connectors and protocol adaptors supplied by the platform (RMI and SNMP), or adding custom connectors or adaptors if the resources are to be accessed remotely.
- A developer that writes the remote manager. This person chooses the connector or protocol adaptors to interact with the JMX agent, and builds views of the resources managed remotely through the exposed MBeans.
There are four types of MBeans, as defined by the JMX specification:
- Standard MBeans: Standard MBeans are management interfaces that are described by their method names. The methods are then exposed through introspection of the interface. Standard MBeans are the most common type of MBean. Most developers do not need to create any other MBean types.
- Dynamic MBeans: A dynamic MBean implements its management interface programmatically with the javax.management. DynamicMBean interface, instead of through introspection of method names. To do this, it relies on informational classes that represent the attributes and operations exposed for management. Dynamic MBeans are often used when the management interface of an MBean is not known at compile time -- for example, if it is determined by parsing an XML file.
- Model MBeans: A model MBean is a generic, configurable MBean that applications can use to instrument any resource dynamically. Essentially, it is a dynamic MBean that has been implemented so that its management interface and its actual resource can be set programmatically. This enables any manager connected to a Java dynamic management agent to instantiate and configure a model MBean dynamically.
- Open MBean: Open MBeans are dynamic MBeans, with specific constraints on their data types, that allow management applications and their human administrators to understand and use new managed objects as they are discovered at runtime. Open MBeans provide a flexible means of instrumenting resources that need to be open to a wide range of applications compliant with the Java Management Extensions (JMX) specification.
The typical process used in creating a JMX-compliant management interface involves at least two steps. The first step is to create an MBean interface, as well as an agent to register that MBean with the MBean server. The next step is to manage the MBean using a remote management application. The JMX specification defines a standard set of connectors that allow you to access JMX agents from remote management applications. This is useful because JMX connectors using different protocols provide the same management interface. This enables a management application to manage resources transparently, regardless of the communication protocol used. JMX agents can also be used by systems or applications that are not compliant with the JMX specification, but which support JMX agents.
Creating a Standard MBean Interface
Let's create an MBean for a hypothetical thermometer device. You can follow along by looking at the source code in the sample archive that accompanies this tip (ttfeb2005jmx.jar). The first thing you must do is "instrument" the resource by creating an MBean interface. In other words, you must create an MBean to implement the access to the instrumentation of resources. Here is an example of a simple MBean:
The interface of an MBean typically consists of named and typed attributes that can be read, written (or both), and named and typed operations that can be invoked.
JMX technology also defines a generic notification model based on the Java event model. JMX agents and MBeans can use this notification model to send critical information to interested parties such as management applications or other MBeans. However, this example does not use notifications.
The next step is to create an implementation of the MBean interface. This is fairly straightforward. Here, we simply create a class called Thermometer that calls a hypothetical static singleton accessor. The accessor obtains a reference to the object that holds the temperature data. For standard MBeans, the name of the implementing class must be the same as the MBean interface, except that the "MBean" at the end is dropped (for example, ThermometerMBean becomes Thermometer).
Creating a JMX Agent
After a resource has been instrumented by MBeans, the resource can then be managed through a JMX agent. MBeans do not require any knowledge of the JMX agent that they work with. This allows developers of applications, systems, and networks to make their products manageable in a standard way without having to understand or invest in complex management systems. This way, existing resources can be made manageable with minimum effort.
Agents get help from services that are located on the server. Agent services are objects that can perform management operations on the MBeans registered in the MBean server. By including management intelligence in the agent, JMX technology allows for more powerful management applications.
The core component of a JMX agent is the MBean server. This is a managed object server in which MBeans are registered. A JMX agent also includes a set of services to manage MBeans, and at least one communications connector to allow access by a management application. Here is the source code for a simple agent:
Running the Example
You will need J2SE 1.5 to run the example.
- Download the sample archive (ttfeb2005jmx.jar) for the this tech tip.
- Change to the directory where you downloaded the sample archive. Uncompress the JAR file for the sample archive as follows:
- Compile the classes using the standard javac compiler.
- Run the agent class using the following command:
- In a new shell or command prompt, start the jconsole tool (this is located in the J2SE bin directory).
- Connect to the JMX agent. Click on the MBeans tab, then select the Thermometer MBean of the ThermometerAgent entry in the tree to the left. If it's not already chosen, click the Attributes tab. You should then see the thermometer attributes for maximum temperature, minimum temperature, and current temperature.
- Click the Operations tab. You should see the resetMaxAndMin() button.
jar xvf ttfeb2005jmx.jar
This will expose the source code for the example.
java -Dcom.sun.management.jmxremote ThermometerAgent
If the agent is registered, you should see a screen similar to the following:
This tech tip has only begun to scratch the surface of JMX technology. For more information, see the article Getting Started with Java Management Extensions (JMX): Developing Management and Monitoring Solutions. The article creates a similar example as shown in this tip, but goes into more detail on using connectors. Also see the JMX technology page. And be sure to follow JSR 255 to watch the development of the JMX Specification, version 2.0.
Copyright (c) 2004-2005 Sun Microsystems, Inc.
All Rights Reserved.