Developers are capitalizing on Java's open and dynamic properties to use the technology for seemingly limitless applications across the computing spectrum. To ensure that developers and businesses optimize Java performance in a variety of deployments, organizations must use an organized, standardized approach to looking inside - and sometimes even modifying - Java-based devices or processes.

Java Management Extensions (JMX) is a relatively new Java standard that provides developers with a standard template and process for viewing the performance of Java components.

Originally part of the Java 2 Platform, Enterprise Edition (J2EE) 2.0 standards maintained by the Java Community Process (www.jcp.org), JMX grew via the Java Service Request (JSR-3) standard into a separate specification in its own right: JMX 1.0. Several Java-based development environments and runtime components contain support for JMX. For instance, IBM's WebSphere Application Server version 5.0 implements JMX.

Using the JMX specification as a guide, Java programmers can more easily integrate their software with management protocols, platforms, and tools. More broadly, the specification describes the JMX architecture, provides template software on which Java programmers can model their code to become JMX-compliant, spells out the JMX application programming interfaces (APIs), and explains the application and network management services that JMX-enabled software can use.

JMX is particularly well suited to mission-critical business process software. For a Java application that automates a business function - as opposed to some other type of Java-based entity, such as a network router or mobile phone - you might think of JMX as an interface between the application and a management/monitoring software tool.

Architecture Overview
The JMX specification developed by the Java Community Process defines a framework, a set of APIs, and a collection of services for managing JMX-enabled devices and applications. Even more formally, JMX's architecture contains an Instrumentation Level, an Agent Level, and a Distributed Services Level.

The JMX Instrumentation Level, or application level, ties a Java-based computing resource to the JMX framework. Within the application, managed bean (also called MBean) components expose application-specific data for management and monitoring purposes. Software designers and programmers specify which information the MBeans make available to the outside world. MBeans, which are similar to JavaBeans, can reveal internal software structures, disclose operational statistics, announce the progress of various internal application functions, and even accept control input that can modify the application's behavior. For instance, through a dashboard entry you might be able to pause, shut down, or temporarily disable some internal functions within an application. Alternatively, if you deem it necessary, you might be able to throttle the application's forward progress.

The Agent Level describes how to instrument a Java resource with the sensors mentioned earlier and link the result to a management/monitoring tool. The Distributed Services Level, which is the most recent section of the JMX specification and the one perhaps most subject to change, discusses JMX in the context of existing network management standards. This article will focus on the JMX Instrumentation Level.

JMX Coding 101
The following examples illustrate interfacing an application with JMX. The examples underscore the simplicity of the JMX APIs. You can judge from these two simple examples how application programmers incorporate JMX into their software.

import javax.management.*;
import com.sun.jdmk.comm.*;
public interface ServiceMBean {
Public void serviceMethod();
}
pubic class Service implements ServiceMBean {
public Service() {}
public void serviceMethod() {}
}

This code snippet shows a few lines of Java programming language statements a programmer could use to JMX-enable an application. To the Service Class shown in the example, the programmer would add whatever Java statements are required to enumerate those data items he or she wants to expose via JMX. The following code snippet depicts Java programming statements for creating and registering JMX objects.

MBeanServer MBS = MBeanServerFactory.createMBeanServer("AppAgent");
MBS.registerMBean(Object, ObjectName);

Instrumentation Level Details
A Java-based device, such as a network router or switch, can use JMX to "instrument" itself with sensor-like behaviors. Via JMX, such a device could, for example, respond to Simple Network Management Protocol (SNMP) requests. SNMP is a pervasive protocol that network operations people use to monitor network devices. A business application can also use JMX to instrument itself for network management and monitoring. It can also offer control interfaces through which administrators can alter its behavior.

A majority of Java runtime environments contain or will soon include JMX implementations you can leverage. For example, to provide core control and basic management services, J2EE application server vendors - such as IBM in its WebSphere Application Server - are enthusiastically incorporating JMX in their products. JMX is becoming an essential building block within Java application servers, and JMX support will be mandatory in J2EE 1.4.

Developers and programmers JMX-enable a business application by inserting some specific programming statements in their Java programs, as shown in the Architecture Overview section. Alternatively, programmers can dynamically inject JMX code into their applications in a declarative fashion. A separate monitoring tool works with the Java runtime system to monitor the JMX-enabled application.

MBeans essentially turn the application into a managed Java entity. As noted, MBeans are similar to session beans and entity beans (i.e., Enterprise JavaBeans), which a WebSphere application already contains.

These statements are relatively harmless from a performance or development standpoint. The MBean programming statements identify and enumerate the application data structures and data variables the application's designers and programmers want to expose. A monitoring tool interfaces with JMX to observe the application and reveal the exposed application data. When a JMX-enabled application runs in the presence of a JMX-based monitoring tool, the tool can show capacity planners, administrators, troubleshooters, and developers application characteristics and even let them modify its behavior.

JMX Costs and Benefits
Because WebSphere already supports JMX, the incremental development cost of enabling JMX is nominal. The cost of becoming familiar with JMX concepts and techniques is far from exorbitant. Java programmers with intermediate skills typically find that a day or two of JMX familiarization makes them quite proficient.

Administering the JMX aspects of an application requires only a part-time effort. During development, programmers or a team's librarian might perform the few administrative chores, while later in production a network administrator might assume those duties. The monitoring tool you select should be robust, reliable, JMX-compliant, scalable, responsive, and flexible. It will become your company's window into the behavior and performance of the application. The cost of the tool will in all cases be far less than the cost of the ad hoc, do-it-yourself approach that many companies had to take in the past.

JMX alternatives lack the organization, standardization, and simplicity of JMX. For instance, developers who cobble together after-the-fact debugging code to display an application's intermediate results via the application's user interface are notorious for leaving their code in the application. Programmer oversight is so notorious that, in many cases, organizations simply overlook and ignore the extraneous displays. In rare cases, organizations may grow so tired of asking the developers to remove the extraneous displays that users may insert notes in the application documentation instructing new hires on which display output to ignore or automatically "click through."

The cost of using troubleshooting experts to analyze and solve an application performance problem can be exorbitant. The cost of the experts typically grows as efforts to solve a problem fail time and time again. Such costs are never budgeted at the outset of an application development project, but rather occur as a nasty surprise late in the development cycle or soon after the application is delivered to the business community.

Conclusion
JMX provides a means of controlling costs, ensuring application reliability, and preserving application integrity while still providing developers, troubleshooters, and IT managers with the information they require to solve performance and availability problems. The JMX-related costs for development resources, administration, and a good-quality, third-party monitoring and management tool pale in comparison to JMX's benefits and the overall expenses you incur in the development, operation, and administration of a significant, mission-critical business automation application.

By embracing JMX, developers, troubleshooters, and IT managers can access an application's internal structure and observe its status at any given point in time. Examining an application's current operations provides developers and IT managers with the information required to determine whether the application is behaving correctly and whether it is consuming excessive computing resources.

Software management and monitoring tools are a natural addition to the JMX architecture. In fact, you might consider a WebSphere application without an accompanying JMX monitoring tool to be like a car without a dashboard instrument panel.