email article printer friendly get the code more resources

Remote Access for Managed Applications
The simplicity of JMX Remote APIs gives you every reason to add distributed management to your server apps
by Daniel F. Savarese

Posted June 14, 2004

At the time I wrote "JMX for Managing Java Applications" (Java Pro, October 2003) the Java Management Extensions (JMX) Remote API specification had not completed its public review phase. Past experience with moving targets in the JCP like Java Architecture for XML Binding (JAXB) and Java API for XML Messaging (JAXM) has taught me to not write about an API before its final version is released. Otherwise, readers are encouraged to adopt an API before it is fully developed, and my example code doesn't work anymore by the time it is published.

Readers may get stuck waiting a year or more before they can count on vendor-provided implementations of an API or versions whose licensing terms allow redistribution with an application. Therefore, I did not mention JMX Remote in the column and indicated that there was not yet a standard distributed services layer for JMX. Well, lo and behold, by the time the column was published, Java Remote had sped through its final specification stages and was released. Some of you may have thought my column was misleading, being unaware of when it was written. Now that the JMX Remote API has been finalized, I'd like to correct any misimpressions by exploring this extremely useful and important component of the JMX.

I'm not the only one who thinks JMX is extraordinarily useful. Application servers like JBoss and Geronimo use JMX MBeans as fundamental building blocks in their software architecture. Not only do MBeans expose the innards of an application to management software, but they encourage a loose coupling between application components that offers great flexibility. This loose coupling makes MBeans attractive for use in container-based applications even though JMX was designed with monitoring in mind. With the addition of the JMX Remote API, any application based on MBeans can instantly gain the ability to distribute its components across multiple computers with minimal code changes.

Another API
With RMI, Jini, JMS, JAXM, JAX-RPC, JXTA, EJB, and a few other acronyms I left out, why does Java need another distribution API? One answer is that each serves a particular purpose and is designed to do a particular job well. The JMX Remote API hides the details of network communication, providing a protocol-independent and transparent API for accessing remote JMX MBeans. It is not designed to be a general-purpose distributed computing API, even though it can be co-opted for that purpose. It helps to remember that the transport layer and programming interface of a distributed communication system are separate. For example, RMI provides a single API and two transport layers (RMI and IIOP). JAX-RPC is able to present an RMI programming interface on top of SOAP messages and a network transport like HTTP or SMTP.

The JMX Remote API adds a couple of classes to allow the JMX programming interface to be used on top of any transport layer. The reference implementation provides a mandatory RMI transport layer implementation and an optional TCP socket-based transport called the JMX Messaging Protocol (JMXMP). The API also provides the means to implement any transport mechanism while your MBeans remain oblivious to the underlying communication system.

The JMX specification was to include originally a distributed services layer for exposing managed resources to a network. However, it was decided to split off that aspect into a separate specification effort, which resulted in the JMX Remote API. Given that the design of JMX already had distributed access in mind, it included some concepts that facilitated the development of JMX Remote without requiring JMX applications to change. The javax.management.MBeanServerConnection interface is the key abstraction that makes the Java Remote API work transparently. The MBeanServer interface extends MBeanServerConnection and provides local access to an MBean server. The MBeanServerConnection interface hides whether an MBean server is local or remote. If you write all of your server interaction code in terms of MBeanServerConnection, you will not have to change your code to work with remote servers.

To make an MBean server remotely accessible, you need to define a way to locate it. You can do this by specifying a URL. The javax.management.remote.JMXServiceURL class provides the means to define such a URL. JMXServiceURL requires a protocol name, a host name, and a port number. The RMI protocol is always supported, but the optional JMXMP protocol is also implemented by the reference implementation. The example in Listing 1 uses JMXMP to save you the trouble of starting an RMI registry server to run the code example. If you wanted to use RMI, you would specify "rmi" as the protocol argument to the JMXServiceURL constructor and the RMI registry port number as the port argument. The host can be null if you want to bind to the default host name, or you can specify a specific interface such as localhost.