• In Brief

• The Party Line

• A JMX Example

  • MBean

  • Our Example

  • The JMX Agent

In Brief:

JMX is a Java solution for managing software components. Functions and attributes that you need to manage are exposed by wrapping them in special Java objects called Managed Beans or MBeans. These MBeans are registered with a JMX agent which allows for centralized monitoring and management of these MBeans.

The Party Line:

If you plan on working with JMX, you should familiarize yourself with the official Sun JMX homepage.

A JMX Example:

Sometimes the easiest way to understand something is to see an example. This section is an example of what we might use JMX for. This example is does not to explain how JMX works, but more what JMX does. It is the 10,000 foot view.

Let's imagine that we are building a system that includes a persistent data store, like a database. We have a single object whose job it is to write and read form our databases. We would like to manage several aspects of this object:

• Set which database it is accessing: We don't want to have to restart our application to switch to a different database. We would like to be able to do it while live. This would give us failover, especially in cases where we would have a known failover database.

• Set the object to on or off: We would like to be able to tell the object to accept no more requests for now and to return errors. The rest of the application can then fail gracefully quickly, instead of waiting for a slow failure from the object trying to talk to a down database.

• Monitor the failure rate: We would like to watch how many requests are failing, like a counter that gets iterated for each failure.

MBean:
There are many ways to go about this, you could put a small server in your system and connect to it and issue proprietary commands. You could run some sort of web server that would allow you to access these functions via a webpage. You could expose the object over RMI and make a client to control it. But each of these ways is custom and not very extensiable. You could make it accessible via JMX.

To do this, you wrap your persistent data access object in an MBean. You have three types to choose from: Standard, Dynamic, or Model MBeans.

Standard MBeans are the most straight forward. It is a class that implements its MBean interface. For example:

public class DataAcessorController implements DataAcessorControllerMBean

The static interface defines the functions of the MBean.

Dynamic MBeans are not defined by a static interface. They implement a generic interface that has methods used by the JMX agent to dynamically discover the MBean's methods.

Model MBeans are an extension of Dynamic MBeans. They use a generic, configurable template which allows the JMX agent to implement the MBean "on-the-fly". This means that the JMX agent can create and configure MBean resources also "on-the-fly".

MBeans are Beans

No matter what kind of MBean you use, it must adhere to the bean pattern:

• attributes are accessed through get/set methods

• read-only attributes have only a get

• write-only attributes have only a set

• booleans are read with an is method

• all other methods are functions



Our Example:

Lets say we need two MBeans: a DataAcessorControllerMBean and a DataSourceFailoverMBean. DataAccessControllerMBean creates a connection to a database and handles request to write data to that database. DataSourceFailoverMBean would contain a list of possible Url's.



The JMX Agent

Now that we have our MBeans, we need to register them with a JMX agent. The JMX agent is an MBean aggregator, like a spinal cord to nerve cells. The JMX agent serves many functions:

• Registry: You can search the JMX agent for other MBeans.

• Proxy: Instead of accessing an MBean directly, you can have the JMX agent make method calls on your behalf. This is useful for remote access, where you can only access the agent.

• Event Network: A JMX agent can broadcast events from one MBean to all interested clients. For example, if an MBean sends a failure event, a recovery MBean could handle it.

• Infrastructure: You can build a highly configurable, loosely coupled system using an JMX agent aggregate MBeans. Using the previous example of a recovery MBean, you could easy swap out one recovery MBean for another at runtime. Or even add in another to cascade the failure event. In any case, neither the original MBean, or the recovery MBean have to know anything about each other. They only have to agree on the event type.

• Monitor: JMX agents can place regular monitors on attributes of registered MBeans. These monitors can be triggered by such things as when an attribute reaches a defined value, exceeds a range, or a specified period of time has passed. When these monitors go off, they can handle it themselves, or broadcast an event to the agent for another clients to handle. For example, imagine a monitor that sends a LogRotaionEvent when a LogWriterMBean's file size exceeds 10MB.



Continuing the original example of the DataAcessorControllerMBean, we would call the JMX agent and tell it to create a new DataAcessorControllerMBean with the name of OurDomain:name=DataAccessController,seq=1. Take a second to look at the format, all MBeans are named like this. The first part is the domain and the second part is the attributes. The combination must be unique per JMX agent. So you may have another MBean named OurDomain:name=DataAccessController,seq=2, but not seq=1. This particular name has two atrributes: name and seq.

Now we have the JMX set a monitor getFailureCount. When this exceeds a range, it would though a FailureEvent.

Now, we have the agent create a DataSourceFailoverMBean named, OurDomain:name=DataSourceFailover,seq=1. We tell the agent that this MBean listens for FailureEvents. When it catches one, it will:

• Call the DataAcessorControllerMBean.getSource() to find out which database is failing, then mark that as unavailable in its list.

• Call the DataAcessorControllerMBean.stop() method.

• It would look through it's list of Url's to find one that is marked available.

• Call the DataAcessorControllerMBean.setSource(String s) method to give the DataAcessorControllerMBean a new JDBC Url.

• Call the DataAcessorControllerMBean.start() method, which would reset the failure count to 0.



With a few components: a DataAcessorControllerMBean, DataSourceFailoverMBean, and a monitor, we have a runtime configurable database failover system. The example has left out a lot of detail, but it gives you the rough idea of what JMX is and starts you in the direction of what it can do.