Java JMX

From HaFrWiki
Jump to: navigation, search


The JMX technology provides a simple, standard way of managing resources such as applications, devices, and services. Because the JMX technology is dynamic, you can use it to monitor and manage resources as they are created, installed and implemented. You can also use the JMX technology to monitor and manage the Java Virtual Machine (Java VM).

The JMX specification defines the architecture, design patterns, APIs, and services in the Java programming language for management and monitoring of applications and networks.

Using the JMX technology, a given resource is instrumented by one or more Java objects known as Managed Beans, or MBeans. These MBeans are registered in a core-managed object server, known as an MBean server. The MBean server acts as a management agent and can run on most devices that have been enabled for the Java programming language.

The specifications define JMX agents that you use to manage any resources that have been correctly configured for management. A JMX agent consists of an MBean server, in which MBeans are registered, and a set of services for handling the MBeans. In this way, JMX agents directly control resources and make them available to remote management applications.

The way in which resources are instrumented is completely independent from the management infrastructure. Resources can therefore be rendered manageable regardless of how their management applications are implemented.

The JMX technology defines standard connectors (known as JMX connectors) that enable you to access JMX agents from remote management applications. JMX connectors using different protocols provide the same management interface. Consequently, a management application can 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, as long as those systems or applications support JMX agents.

Java Version

JMX can be used in Java 1.4 when adding the correct jar files:

  • adminclient.jar
  • jmxremote.jar
  • jmxremote_optional.jar
  • jmxri.jar
  • jmxtools.jar
  • rmissl.jar
  • xstream-1.1.2.jar

In later version of Java the is embedded.


The JMX technology can be divided into three levels, as follows:

  • Instrumentation,
    To manage resources using the JMX technology, you must first instrument the resources in the Java programming language (MBeans and MXBeans].
  • JMX agent,
    A JMX technology-based agent (JMX agent) is a standard management agent that directly controls resources and makes them available to remote management applications. The core is the MBean server.
  • Remote management,
    JMX technology instrumentation can be accessed in many different ways, either through existing management protocols such as the Simple Network Management Protocol (SNMP) or through proprietary protocols. The MBean server relies on protocol adaptors and connectors to make a JMX agent accessible from management applications outside the agent's Java Virtual Machine (Java VM).


An MBean is a managed Java object, similar to a JavaBeans component, that follows the design patterns set forth in the JMX specification. An MBean can represent a device, an application, or any resource that needs to be managed. MBeans expose a management interface that consists of the following:

  • A set of readable or writable attributes, or both.
  • A set of invokable operations.
  • A self-description.

The management interface does not change throughout the life of an MBean instance. MBeans can also emit notifications when certain predefined events occur.

The JMX specification defines five types of MBean:

  • Standard MBeans
  • Dynamic MBeans
  • Open MBeans
  • Model MBeans
  • MXBeans

Standard MBean

A standard MBean is defined by writing a Java interface called SomethingMBean and a Java class called Something that implements that interface. Every method in the interface defines either an attribute or an operation in the MBean. By default, every method defines an operation. Attributes and operations are methods that follow certain design patterns. A standard MBean is composed of an MBean interface and a class. The MBean interface lists the methods for all exposed attributes and operations. The class implements this interface and provides the functionality of the instrumented resource.

Hello example

The Hello example consists of


package com.example; 
public interface HelloMBean { 
    public void sayHello(); 
    public int add(int x, int y); 
    public String getName(); 
    public int getCacheSize(); 
    public void setCacheSize(int size); 


The, the implementation of the MBean.

package com.example; 
public class Hello [...] implements HelloMBean { 
    public void sayHello() { 
	System.out.println("hello, world"); 
    public int add(int x, int y) { 
	return x + y; 
    public String getName() { 
    public int getCacheSize() { 
	return this.cacheSize; 
    public synchronized void setCacheSize(int size) {
	this.cacheSize = size; 
	System.out.println("Cache size now " + this.cacheSize); 
    private final String name = "Reginald"; 
    private int cacheSize = DEFAULT_CACHE_SIZE; 
    private static final int DEFAULT_CACHE_SIZE = 200; 


Once a resource has been instrumented by MBeans, the management of that resource is performed by a JMX agent.

The core component of a JMX agent is the MBean server. An MBean server is a managed object server in which MBeans are registered. A JMX agent also includes a set of services to manage MBeans. See the API documentation for the MBeanServer interface for details of the MBean server implementation.

The Main class that follows represents a basic JMX agent: The agent implementation:

package com.example; 
public class Main { 
   public static void main(String[] args) throws Exception { 
      MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); 
      ObjectName name = new ObjectName("com.example:type=Hello"); 
      Hello mbean = new Hello(); 
      mbs.registerMBean(mbean, name); 
      System.out.println("Waiting forever..."); 

The JMX agent Main begins by obtaining an  MBean server   that has been created and initialized by the platform, by calling the getPlatformMBeanServer() method of the class. If no MBean server has been created by the platform already, then getPlatformMBeanServer() creates an MBean server automatically by calling the JMX method MBeanServerFactory.createMBeanServer(). The MBeanServer instance obtained by Main is named mbs.

Next, Main defines an object name for the MBean instance that it will create. Every JMX MBean must have an object name. The object name is an instance of the JMX class ObjectName and must conform to the syntax defined by the JMX specification. Namely, the object name must contain a domain and a list of key-properties. In the object name defined by Main, the domain is com.example (the package in which the example MBean is contained). In addition, the key-property declares that this object is of the type Hello.

An instance of a Hello object, named mbean, is created. The Hello object named mbean is then registered as an MBean in the MBean server mbs with the object name name, by passing the object and the object name into a call to the JMX method MBeanServer.registerMBean().

With the Hello MBean registered in the MBean server, Main simply waits for management operations to be performed on Hello. In this example, these management operations are invoking sayHello() and add(), and getting and setting the attribute values.


The JMX API defines a mechanism to enable MBeans to generate notifications, for example, to signal a state change, a detected event, or a problem. To generate notifications, an MBean must:


To send a notification, you need to construct:


Every notification has:

  • a source. The source is the object name of the MBean that generated the notification.
  • a sequence number. This number can be used to order notifications coming from the same source when order matters and there is a risk of the notifications being handled in the wrong order. The sequence number can be zero, but preferably the number increments for each notification from a given MBean.

See also