Java Management Extensions (JMX)
What is JMX ?
Java Management Extensions(JMX) is the standard recommended way of managing and monitoring anything with java enabled. It’s a part of core Java SE since Java 5. It is an API, an architecture and a specification or a standard. There are two main JSRs and they are JSR 3 (original JMX) and JSR 160 (Remote JMX). JMX is very lightweight and you do not need MIBs or understand SNMP or require any proprietary software and just Java SE will do those work.
What you can do with JMX
Most of the java-based devices and applications need monitoring and management. JMX is the recommended way of doing this monitoring and managing. A very trivial application like “Hello World” is also needed to be monitoring and managing. Typically a Java application has business logic which implements the application’s functionality. But any non-trivial application also needs to be monitored, started and stopped, have configuration changed dynamically, monitored for performance and faults, etc.
JMX can also be the cornerstone of your application and all your services can themselves be MBeans leading to a highly modular, pluggable design. They manage resources like your server, OS, virtual machine or whatever you are managing are MBeans. The services like security, transactions also can be implemented as Mbeans. For a highly modular pluggable design, you can keep whatever the services you want and you can deactivate the ones you are not interested in just like removing. It’s also easy to replace some other service.
Comparison of JMX with other technologies
Whenever management client running remotely and management resources are running somewhere else, you need some remote technology to connect the tool. RMI, CORBA, SOAP and other IPC(Inter-Process Communication) technologies can be used to connect the tool.
EJB (Business Logic) — EJB implements the business logic but it has to be managed (life cycle management) inside the application server. EJBs can be managed with JMX.
Jini and JNDI — They are typically used for discovery. The remote client wants to discover the agent to talk and then a URL can be specified.
RMI — RMI can be used for remote connection from the management client to the JMX agent. It’s a lower-level technology.
Web Services — It’s another technology that could be used to connect JMX clients to agents.
JMS — It can be used for sending events from JMX agents to remote clients. A JMS queue or other resource from JMX also can be managed.
Comparison of JMX with SNMP
SNMP(Simple Network Management Protocol) is the de facto standard for network management of switches, routers, etc. However, if Someone wants to do more than network management (a combination of hardware and application management), JMX may be a better fit to do the task. SNMP exposes the management interface through a static MIB (Management Interface Base) while JMX relies on introspection of the Mbean Java classes for the interface. Structural changes to the agent are not visible to the SNMP client but in JMX with certain kinds of Mbeans,if you make structural changes in the agent, those could be visible to the remote client. Both SNMP and JMX support events through the traps and notifications. JMX can support richer data types than SNMP. A special tool kit is needed to implement the agent for the defined MIB in SNMP.
JMX Architecture
JMX architecture has three main levels.
1. Probe Level (Instrumentation Level) — contains the probes(MBeans) instrumenting resources
2. Agent Level (Mbean Server) — the core of JMX. It acts as an intermediary between Mbeans and Applications.
3. Remote Management Level — enables remote applications to access the Mbean server through connectors and adaptors. A connector provides full remote access to MBeanServer API using various communication (RMI, IIOP, JMS, WS- …), while an adaptor adapts the API to another protocol (SNMP, …) or to Web-based GUI (HTML/HTTP, WML/HTTP, …). Java comes with the RMI connector.
Applications can be generic consoles(such as Jconsole and MC4j) or domain-specific(monitoring) applications.
Probe/Instrumentation Level
MBean is the fundamental entity in the instrumentation level. Functionality/resource you want to manage is exposed through a managed bean (MBean) that confirms to the JMX specification. An MBean has named and typed attributes (read and/or write), named and typed operations that can be invoked and notifications it can limit.
There are several kinds of Mbeans.
• Standard Mbean
• Dynamic Mbean
• Model Mbean
• Mxbean
• Open Mbean
Standard MBeans and MxBeans
A standard Mbean is defined by writing a java interface called SomethingMbean and a Java class called Something that implements that interface and provides the functionality of the instrumented resource. Every method in the interface defines either an attribute (get, set, …) or an operation(clear, …) in the Mbean. Operations can take arguments. In an attribute, you can return user-defined types as well. If you are doing that with Standard Mbean, the client needs to be aware of that class (Structure of the class). By default, every method defines an operation. Attributes and operations are methods that follow certain design patterns. A standard Mbean is composed of a Mbean interface and a class.
Java 6 allows you to create your own Mbeans. They are called MxBeans and you can define your user-defined classes. The remote client does not need to know about them as long as your custom class follows some basic rules. It basically needs to be converted and the framework should be able to convert your custom class into one of the standard types (Open types) as defined in the “java.management.openbean” package. The custom type class can either specify @ConstructorProperties annotation or add a static form (CompositeData) to reconstruct the custom type instance from an Open type (usually CompositeData) instance.
Notifications
To generate notifications, an MBean must implement the interface NotificationEmitter or extend NotificationBroadcasterSupport. To send a notification, you need to construct an instance of the class javax.management.Notification or a subclass (such as AttributeChangedNotification) and pass the instance to NotificationBroadcasterSupport.sendNotification . To receive a notification, a client has a notification handler which implements the NotificationListener (which has one method: handleNotification) which listens for specific notifications from Mbeans. The handler will get notifications emitted by the Mbeans which it is listening. Good design practice is to add a Notification hub that clients listen.
Agent Level
The central component of the agent level is the Mbean Server which is a registry of Mbeans and describes the management interface of each MBean. The MBean Server isolates the managed resources(Mbeans) from the management client therefore all operations go through the Mbean Server. ObjectName is used to register an MBean with the Mbean Server and clients use the ObjectName to get a reference to a Mbean. ObjectName is unique within an Mbean Server and it is of the form {DomainName]:property=value,[property=value]* .
Agent Level also has a set of agent services which are themselves registered as Mbeans with the Mbean Server. Standard mandatory services are M-let, Timer, Monitoring, Relation, etc.
Remote Management Level
Protocol connectors and/or adaptors allow remote management clients to access the managed resources. In the case of connectors, a specific transport protocol (e.g: RMI) is used to connect the client piece of the connector(on the management side) to the server piece of the connector(on the agent side). The management application understands JMX and accesses the Mbeans via a remote interface to the Mbean Server. In the case of protocol adaptors, the management application is connecting to a protocol adaptor that adapts/maps the Mbean interface into a different protocol’s interface (e.g: SNMP adaptor, HTTP adaptor, Web services adaptor). The advantage is that is this case the management application does not need to understand JMX or even Java.
How to manage a resource with JMX
First of all, a resource (application, device, service, etc) should be selected that has been developed in Java or has a Java wrapper. Then functionality you want to manage through a Mbean that conforms to the JMX specification should be exposed. An MBean has named and typed attributes (read and/or write), named and typed operations that can be invoked and notifications that it can emit. Then your Mbeans should be registered with a Mbean Server that is part of a JMX agent. Then Mbeans are accessed through the connectors or protocol adaptors remotely to manage the resource from your management client.
