What Is JMX and Why Would You Want It?

JMX provides both the architecture and the services needed to actively administer, monitor, and manage resources. The WebLogic 8.1 distribution supports JMX version 1.0. Although it's a relatively new API, JMX is quite robust and through the use of JMX management components can be used to monitor and manage most any resource. JMX can even map to any existing management protocol, such as SNMP or HTTP.

What JMX Can Do for You

JMX allows for the administration of all resources in your environment. This is basically done by encapsulating a component in a JMX wrapper object and exposing its attributes and/or methods in a JMX server environment.

JMX provides administration services for both hardware and software components. Let's look at the services JMX provides in a little more detail:

• Hardware monitoring and management— The entire physical infrastructure can be monitored for health, performance, and failure. Such devices may include, but are not limited to, network switches, hubs and routers, Web and application servers, databases, load balancers, modems, and filers. Your JMX components can provide management logic, so that if the load on a server should become too great, you can move some of the load to a backup server. You can also configure event notifications via email or pager.

• Software monitoring and management— As with hardware, your software components can also be monitored for health, performance, and failure. Manageable resources may be EJBs, servlets, Java classes, log files, and databases. JMX components can provide you a variety of management functionality such as logging events, dynamically changing the number of connections available to a connection pool, starting and stopping applications, gathering statistics about transactions, reporting Web page hits, and triggering notifications via email or pager.

Through the use of critical event triggers, JMX can provide the capability to avert failure before it happens. You can program failover logic so that the applications handle themselves, send out pages, or write out data to files for human intervention.

JMX also provides you with the flexibility and control to expose as little or as much of the resource as needed. For instance, you can choose to expose the ability to start and stop a Web server, but not to change configuration settings, or perhaps to expose a single method in an application that sends out a log file of transaction statistics.

WebLogic Server employs JMX for all of its management and monitoring functions. As we cover later in the chapter, the Administration Console and the weblogic.Admin utility use them exclusively.

The Structure of JMX

A Java management system requires a number of basic components configured in adherence to the JMX architecture. To understand the structure of a JMX system, it is first necessary to identify and define a few of these components:

• Managed resource— This is any resource that can be managed or monitored in some way. It might be a physical device, such as a switch or Web server, or it might be an application component or a connection pool.

• MBean— A managed resource is encapsulated into a managed bean, or MBean. Stated another way, an MBean is a Java wrapper class that contains the resource to be managed.

• MBean server— MBeans themselves require management, and this is done through an MBean server. The MBean server provides a registry for looking up MBeans.

• JMX agent— An MBean server requires a container in which to reside—that is provided by the JMX agent. The JMX agent manages the MBean server, creates MBean relationships, loads classes, and provides monitoring services.

• Management application— The management application is used to communicate with a JMX agent. This is the application through which you can interact with your managed resources. It might be a Web application such as WebLogic's Administration Console, a standalone application, or perhaps a command-line utility such as weblogic.Admin.

Now let's take a look at how these components work together in a JMX system.

Suppose that we have an Entity EJB running on an application server that we would like to manage in some way. We would first encapsulate our managed resource (the EJB) into a Java wrapper object (an MBean), and deploy it into WebLogic Server (the JMX agent).

The MBean must be managed by an MBean server, so we'll create an MBean server and configure it through the Administration Console. It's the job of the MBean server to manage a group of MBeans. JMX Agent runs in the WebLogic Server container and manages the MBean servers.

Finally, we create a management application that communicates through the JMX agent to manage and monitor the resource via its associated MBean. The JMX agent provides protocol adapters and connectors that allow communication between the management application and the protocols. The management interface of an MBean is exposed, without exposing a reference to the object itself, through a process called instrumentation.

Now that we've defined the players in a JMX system and given a high-level scenario of the management process, let's take a look at the architecture of a JMX system. The architecture of a JMX system is divided into three layers, as shown in Figure 37.1:

MBean Templates

There are four basic models, or templates, on which MBeans are built:

• Standard— Standard MBeans implement their own interface. The developer creates an MBean interface and the MBean class provides an implementation for its methods.

• Dynamic— Dynamic MBeans implement the javax.management.DynamicMean interface. This interface provides the capability for modifying resource attributes at runtime.

• Open— An Open MBean is really a Dynamic MBean, but one that uses a small set of universal Java types, or basic data types, which expose their functionality. They provide the capability for exposing and managing resources discovered at runtime.

• Model— Model MBeans are also a type of Dynamic MBean. They provide a generic template for managed resources, so users can expose info without creating new MBean classes.

It's important that you don't confuse the four MBean templates with the three functional MBean types defined by BEA: Runtime, Configuration, and Administrative MBeans. These will be covered in the next section.