Implementing a Typical JMX Application
In the instrumentation layer you first define a managed bean (MBean). MBeans are Java objects that encapsulate a manageable resource and expose it for monitoring and management purposes. A manageable resource
is any resource that can be accessed in the J2EE server.
After creating the MBean, you need to make it available for any client that needs to access it. You do this by registering the MBean in a JMX agent such as MBeanServer. MBeanServer is the registry for all MBeans in the server, and all management operations go through MBeanServer. You can use MBeanServer to find registered MBeans, get the list of operations available for a specific MBean, and determine the return data type of each operation).
Finally, from the distributed layer, you will use an adapter (usually an HTML adapter) to communicate with your agent to access all registered MBeans, view their readable attributes, update the writable attributes, and invoke their operations (methods).
Multiple Java Specification Requests (JSRs) relate to JMX technology. Table 1 summarizes the various JSRs currently listed on the JCP Web site.
Table 1. JSR Requests related to JMX and Application Management
||Java Management Extensions (JMX) Specification
||The JMX specification will provide a management architecture, APIs and services for building Web-based, distributed, dynamic and modular solutions to manage Java enabled resources.
||IIOP Protocol Adapter for JMX Specification
||This specification will establish an IIOP-based adapter for the JMX specification to allow CORBA clients access JMX agents.
||This JSR specifies the interoperability between the Telecommunication Management Network (TMN) standards and JMX.
||Provide server vendors and tool vendors with a standard model for managing the J2EE Platform. J2EE Management will be defined using standard management information formats and protocols, such as JMX, WBEM, and SNMP, in such a way as to provide information that can be managed by standard system management applications.
||WBEM Services: JMX Provider Protocol Adapter
||Define the architecture and API for WBEM support for Java. This specification will define how JMX instrumentation can be mapped to CIM and the definition of a JMX Provider Protocol Adapter for WBEM Services.
||Java Management Extensions (JMX) Remote API
||Extend the Java Management Extensions (JMX) 1.0 specification, by adding the Client APIs. These APIs provide to any Java Manager discovery and access to JMX Agents abstracting the underlying protocol.
||Monitoring and Management for the JVM machine
||A specification for APIs for monitoring and management of the Java virtual machine. These APIs will provide Java applications, system management tools and RAS-related tools with the ability to monitor the health of the Java virtual machine as well as manage certain run-time controls such as Class load/unload, Memory allocation and Garbage collection statistics, Thread details, and Object info (object count in the Java heap).
Web site provides links to products using JMX technology. Another
link on the site lists open source and commercial implementations of the JMX specification.
Some popular implementations of JMX technology are JBoss
, WebLogic Server
, Tomcat 5
, and MX4J
. All WebLogic server resources such as JMS servers and JDBC connection pools are managed through the JMX-based services. You can also build your own management utilities that use these JMX services to manage WebLogic Server resources and applications.
There are four types of MBeans:
JMX Support in Tomcat 5
- Standard MBeans: These MBeans are the simplest to design and implement. The management interface consists of method names (getters and setters), used to store static management information where the structure of the managed component is well defined and is not likely to change.
- Dynamic MBeans: These MBeans expose a more flexible management interface at runtime via generic methods such as getAttribute, setAttribute, and invoke. They must implement the DynamicMBean interface. Dynamic MBeans are useful when the management interface is changing.
- Open MBeans: These are dynamic MBeans that use a subset of universal Java types. They have a specific set of metadata classes to manage the resource.
- Model MBeans: These are special highly dynamic MBeans that are configurable at runtime. Model MBeans are self contained, self described, and are configurable. You provide the required metadata information about the classes that are being managed (as opposed to those managed classes implementing interfaces as in the case of Standard MBeans). These MBeans allow instrumentation of resources where you might not be able to modify or enhance the existing code to weave in the instrumentation logic.
JMX support was available in Tomcat 4.1 release, but has been enhanced in Tomcat 5 to provide a comprehensive server monitoring and administration using JMX. JMX is now a core part of Catalina, Tomcat's servlet implementation. Tomcat 5 uses JMX MBeans for implementing the manageability of Tomcat. You can now manage all Tomcat internalssuch as Service, Engine, Host etc.using JMX technology. Also, the Tomcat server itself can be launched as an embedded server using JMX.
Tomcat uses the JMX open source framework MX4J to implement JMX support. You don't need to install MX4J separately to start using JMX; the Tomcat 5 installation package includes MX4J as part of the bundle. The JAR file for the MX4J API is located in the TOMCAT_HOME/bin
directory (in the file jmx.jar
, which also includes the core JMX API).
Here's a short list of the various types of managed resources available in Tomcat 5 server:
- Architectural components: Server, Service, Connector, Engine, Host, Context, Default Context, and Cluster.
- Nested components: Realm, Logger, Loader, Valve, and Manager.
- Runtime Data Objects: User Database, User, Group, and Role.
- Resource Objects: Naming Resources, Environment, Resource, Resource Link, WebModule, Request Processor, Cache, and Thread Pool.
The book Professional Apache Tomcat 5
contains a very good discussion on all these components. It provides a list of the attributes for all the manageable components listed above.
Tomcat provides two ways to access these manageable components: the JMX Proxy Servlet provided as part of the Manager application (this is based on the HTTP protocol adapter) and the RMI connector (this adapter is implemented using MX4J framework). Visit the MBeans home page on the Tomcat 5 Web site for more details on Tomcat's MBean support.
The sample Web application described in this article uses the JMX API to manage a Tomcat cluster. The Model MBeans approach shown here gives you a great deal of flexibility in instantiating managed beans for cluster elements. Model MBeans are:
- Generic, flexible, and extensible
- Able to use a common template for different MBeans
- Configurable at run-time
- Rapidly instrumentable
The sample code
uses the Jakarta Commons-Modeler framework to simplify the tasks of instantiating the model MBeans and accessing the components in the cluster.
The Jakarta Commons-Modeler Framework
The Jakarta group created the Commons-Modeler Framework to provide a flexible way of working with MBeans. This framework is based on Model MBeans which let you define MBeans for many different components without having to write a specific implementation for each MBean. You can use the Commons-Modeler API to simplify setting up metadata about a managed component (Java class) such as its constructor, attributes, and methods. You supply the required runtime metadata information in an XML MBean descriptor file (The XML file must conform to the DTD supplied with the Modeler installation package). Using an XML file to describe the Model MBean details is powerful and extensible, and a much better approach than hardcoding the information.
|Figure 1. Tomcat Cluster Hierarchy: The figure shows the hierarchy of server components in a Tomcat cluster.|
The Commons-Modeler framework also provides a registry and a base Model MBean to work with, which makes accessing the manageable components relatively simple. Tomcat 5 uses this framework extensively to simplify its JMX implementation. Every Tomcat MBean component has an attribute called modelerType
that describes the component's MBean type.
Figure 1 shows the hierarchy of the server components in a Tomcat cluster.
The theoretical Tomcat cluster setup described here consists of four instances of Tomcat server. One Tomcat instance serves as a load balancer and the other three instances are part of the cluster. The cluster was set up with a vertical scaling method (multiple Tomcat server instances running on a single machine) in which one server group and two clones were configured in the cluster. The clones were configured with the identical Web application directory structure and contents as the server group to optimize session replication.