Java Management Extensions

What is JMX?

The Java Management Extensions (JMX) is an API used for managing or monitoring various resources such as applications, devices, services and of course the JVM. Developed through the Java Community Process (JCP), the JMX technology was built as Java Specification Request 3.

The JMX technology provides with remote access, therefore the management of an application can be achieved from a remote machine. The usages of the JMX are vast and include the following:

• making changes in the application configuration, or just simply checking a current configuration (useful when we’re dealing with a remote machine).
• extracting and accumulating data to be used in statistical analysis of the resource usage or in application behavior monitoring
• notifications regarding state changes or detected errors

The JVM resources are instrumented by a series of Java objects called Managed Beans or simply MBeans. These beans are registered in a managed object server (MBean Server). This server can run on most devices enabled for Java Programing language and acts as management agent. A JMX agent is what we use to manage the instrumented resources. An agent is consisted of a MBean Server (the place of MBeans registration) and the services that provide the means of handling the MBeans. The management infrastructure does not interfere with the way resources are instrumented and vice versa, so the resources can be managed the same regardless of the implementation of their managing applications.

The JMX technology is a standard and flexible way of implementing Java agents, instrument Java code, create managing applications and managing middleware. The JMX Connectors are the link that allows programmers to access the JMX agents from remote applications. JMX connectors provide the same management interface regardless of the communication protocol they use. Therefore a managing application can manage resources in a transparent manner without taking note of the communication protocol used.

The JMX Architecture

The JMX technology is defined by two specifications, Java Specification Request 3 and Java Specification Request 160, both developed through the Java Community Process. You can think of the architecture as the following 3 levels:

• Instrumentation: resources are instrumented through the ManagedBeans, that expose their management interfaces through a JMX agent.
• Agent: it’s main component is the MBean Server. An agent provides a set of services used for handling Mbeans and is the component that controls directly resources and makes resources available to remote management.
• Remote Management: a JMX agent is made accessible from outside it’s JVM through protocol adapters and standard connectors.

Managing resources through the JMX technology requires to firstly instrument the resources in the Java programing language. This means it is required to use the Java MBeans to implement the access to the resource instrumentation. The standardized manner of the JMX makes it easy for developers to create manageable applications without having to know and understand complex management systems.

Although not a requirement, the JMX agents usually reside on the same machine as the managed application. It isn’t aware of the resources it manages because of the way the instrumentation is done. Any resource that is instrumented respecting the JMX specification can use any JMX agent that offers the services that the resource requires. The same way the JMX agent shouldn’t be aware of the management application accessing it. This ensures a high degree of independence between the components.

There are many ways of accessing the JMX API instrumentation. Access can be provided through existing protocols such as SNMP (Simple Network Management Protocol), or through proprietary protocols. The connection is routed through protocol adapters and connectors on which the MBeans Server relies and makes the JMX agent accessible from outside it’s JVM. Each adapter provides a view of all MBeans registered in the MBeans Server. All connectors provide the same interface for remote management.

The JMX technology is a standardized way of exporting JMX API, based on RMI (Remote Method Invocation), it also provides with a protocol based on TCP sockets, the JMX Messaging Protocol (JMXMP). Unfortunalety not all implementations of the JMX Remote API support the second, TCP socked based protocol, for example it isn’t included in the Java SE platform.

What are MBeans?

The MBeans are the Java objects that implement the resource instrumentation. They must respect the JMX specifications in order to provide the instrumentation in a standard way. A resource can be instrumented by one or more MBeans that can be dynamic or standard. The standard beans are objects that besides respecting the JMX specification they follow the JavaBeans(TM) component model, while the dynamic beans respect a specific interface in order to provide with more runtime flexibility.

The management interface of an MBean consists of the following:

• Named and typed attributes that can be read an/or written
• Name and typed operations that can be invoked
• Type notifications that can be emitted by the Mbean

A standard Java MBean class exposes the managed resource through its operations and attributes. Attributes are exposed themselves through getters and setters. The JMX agent uses introspection to determine the operations that are offered by the MBeans, making it very easy and straight forward to manage new resources. The JVM itself is instrumented out of the box and JMX agents can easily be loaded in a dynamic way enabling the remote managing and monitoring of the JVM.

Introducing MXBeans

An interface is an MXBean if one of the following requirements are met:

• it is marked with the @MXBean annotation to explicitly specify the fact that the interface represents a MXBean
• it is not marked with the @MXBean(false) annotation to specify that the interface is not a MXBean
• its name ends with MXBean

The MXBean is a concept that provides an easy way of programming MBeans that only reference the predefined set of types defined in javax.management.openmbean. This ensures that the MBeans will be usable by any client even if the client doesn’t have access to model specific classes of the MBean. The concepts will be presented as a comparison to the standard MBean.

All MXBean method parameters and return values must be described using Open Types, because the MXBean is a kind on Open MBean. For every Java type J, the MXBean mapping is described by the following:

• the corresponding Open Type of the type J, opentype(J)
• the mapped Java type, opendata(J)
• the way a value is converted from J to and from opendata(J)

The Java type J can be the type of a method parameter or return value in an MXBean only if the is a mapping to derive opentype(J) from J. J is reconstructible if there is a way of converting opendata(J) back to J. All method parameters must be reconstructible for a Mbean to be a MXBean, because at a method invocation time, the the MXBean framework converts the parameters from opendata(J) to J.

The MXBeans that come along with the Java platform are the following: ClassLoadingMXBean, CompilationMXBean, MemoryMXBean, ThreadMXBean, OperatingSystemMXBean, GarbageCollectorMXBean, MemoryManagerMXBean, MemoryPoolMXBean.

The Dynamic MBeans define their management interface at runtime. For example a database MBean would determine the types and names of it’s attributes that it exposes after reading data from a database. Any Java object implementing DynamicMBean is a Dynamic MBean.

The Open MBeans are a kind of Dynamic MBeans. Defined by the Java package javax.management.openmbean, the Open MBeans ease the operation with remote management application, in the way that the management applications are not required to be aware of application specific types. All the method parameters and return values of an Open MBean are types of a small Java types subset called Open Types.

Another kind of Dynamic MBeans are the the Model MBeans. Defined by the Java package javax.management.modelmbean, these MBeans act as a bridge between the managed resource and the management interface. The management interface and the resource are specified as Java objects. These MBeans are useful in providing common functionality (the can be used for any number of times for different resources) for different managed resources.

Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on! Want to write for the blog? We are looking for contributors to fill all 24 slot and would love to have your contribution! Contact Attila Balazs to contribute!

Author: gpanther