Java Theory and Practice: using JMX to detect applications

How many times have you ever looked at a running application and asked yourself: "What the hell is it doing?" Why did it take so long? "At these moments, you might think it would be nice if you built more monitoring capabilities in your application." For example, in a server application, you can view the number and type of tasks queued for processing, the tasks currently being processed, throughput statistics in the past minute or hour, average task processing time, and so on. These statistics are easy to collect, but when data is needed, these values are less useful if there is no non-invasive data retrieval mechanism.

Operational data can be exported in many ways-you can write periodic statistics snapshots to log files, create Swing GUIs, use an embedded HTTP server to display statistics on a Web page, or publish Web services that you can use to query applications. But in the absence of a monitoring and data-publishing infrastructure, most application developers are not doing this, resulting in a much less-than-expected understanding of how the application works.

Jmx

In Java 5.0, class libraries and JVMs provide a comprehensive management and monitoring infrastructure--jmx. JMX is a standard measure for providing a managed interface that can be accessed remotely, and a simple way to add a flexible and powerful management interface to an application. A JMX component called a managed bean (MBean) is a JavaBean that provides accessors and business methods related to the management of an entity. Each managed entity (possibly a service in an entire application or application) instantiates an MBean and registers it with a readable name. JMX-enabled applications rely on Mbeanserver, which acts as a container for MBean, providing remote access, namespace management, and security services. On the client side, the Jconsole tool can act as a unified JMX client. Combining both, platform support for JMX greatly reduces the work and effort required to enable applications to support external management interfaces.

In addition to providing a mbeanserver implementation, Java SE 5.0 provides a JVM to make it easier to understand the state of memory management, class loading, active threads, logs, and platform configurations. The monitoring and management of most platform services is turned on by default (minimal performance impact), so just connect the application to the JMX client. Figure 1 shows a jconsole JMX client (part of the JDK) that displays one of the memory management views-heap usage over time. The Perform GC button proves that JMX provides the ability to initialize operations beyond the view of operational statistics.

Figure 1. View heap usage with Jconsole

Transport and security

JMX specifies the protocol used to communicate between Mbeanserver and JMX customers, and protocols can be run on a variety of transport mechanisms. You can use built-in transmissions for local connections and remote transmissions via RMI, sockets, or SSL (you can create new transports via the JMX Connector API). Authentication is performed by the transport, where the local transport allows the same user ID to be connected to the JVM running on the local system, and remote transmissions can be authenticated with a password or certificate. Local transport is enabled by default under Java 6. To enable it under Java 5.0, you need to define system attribute Com.sun.management.jmxremote when the JVM starts. The "Monitoring and Management using JMX" document (see Resources) describes the configuration steps for enabling and configuring transports.

Detecting WEB Servers

It is easy to detect applications to use JMX. Like many other remote invocation frameworks (RMI, EJB, and Jax-RPC), JMX is also based on interfaces. To create an administrative service, you need to create an MBean interface that specifies the administrative method. You can then create an MBean to implement this interface, instantiate it, and register it with Mbeanserver.

Listing 1 shows the MBean Interface for network services, such as WEB servers. It provides a getter for retrieving configuration information, such as port numbers, and operational information, such as whether a service is started. It also includes the getter and setter to view and modify configurable parameters, such as the current log level, and methods for invoking administrative operations such as Start () and stop ().

Listing 1. An MBean interface for a WEB server

public interface WebServerMBean {
　　 public int getPort();
　　 public String getLogLevel();
　　 public void setLogLevel(String level);
　　 public boolean isStarted();
　　 public void stop();
　　 public void start();
}

Implementing an Mbean class is generally straightforward, because the Mbean interface reflects the properties and administrative actions of an existing entity or service. For example, the Getloglevel () and Setloglevel () methods in the MBean are forwarded directly to the Getlevel () and Setlevel () methods on the Logger used by the WEB server. JMX has made some naming restrictions. For example, the Mbean interface name must end with an Mbean, and the Mbean class for the Foombean interface must be called Foo. (You can use the more advanced JMX feature-dynamic MBean to remove this limitation.) It is also easy to register the MBean with the default Mbeanserver, as shown in Listing 2:

Listing 2. Implementing a registered MBean with a built-in JMX

public class WebServer implements WebServerMBean { ... }
　 ...
　 WebServer ws = new WebServer(...);
　 MBeanServer server = ManagementFactory.getPlatformMBeanServer ();
　 server.registerMBean(ws, new ObjectName ("myapp:type=webserver,name=Port 8080"));