This chapter is from the book
This chapter is from the book
This chapter is from the book
2.5 JMX Overview
In its instrumentation and agent specification, the JMX architecture consists of four components (see Figure 2.4) that map to the management system components discussed earlier:
Managed resources and management beans (MBeans) that expose the management interfaces that make up the instrumentation level.
Agents, including MBeanServers and the monitoring, timing, relation, and class-loading services, that constitute the agent level.
Adapters that translate between JMX capabilities and APIs, and between their respective management systems.
Adapter tools that generate the files required by the management system through JMX APIs. Examples of these file types are Tivoli's AMS file,43 SNMP's MIB file,44 and CIM's MOF file.45
)
Figure
2.4 JMX Architecture
Let's take a closer look at each of these elements.
2.5.1 JMX-Managed Resources
JMX-managed resources are instrumented with management beans (MBeans). You, the application developer, use MBeans to expose the management interface of the managed resource. The management interface of a resource consists of the attributes, operations, and notifications that are used to manage it.
2.5.2 MBeans
JMX specifies four types of MBeans: standard MBean, dynamic MBean, open MBean, and model MBean. Each MBean has metadata in MBeanInfo. MBeanInfo defines the attributes, operations, and notifications supported by the MBean.
2.5.2.1 Standard MBeans
A standard MBean can be any JavaBean or JavaBean-style program that has been registered with the MBeanServer. You, the application developer, define these MBeans and their management interfaces at development time. The only requirement is that your MBean class must implement a Java interface named classnameMBean that you must define for them. For example, an MBean class named CatalogManager would implement an interface called CatalogManagerMBean. This interface defines the management interface for the MBean. The interface might include all or just a subset of the methods in the actual MBean class.
When your MBean is registered with the MBeanServer, the MBeanServer will create an MBeanInfo metadata object for it by introspecting the classnameMBean interface. It will create attributes and operations in the MBean by looking for the JavaBean pattern. Each getAttributeName() method with a matching setAttributeName(attributeValue) method will create an attribute for the MBean. All other public methods will create operations for the MBean. The MBeanServer will use MBeanInfo to make sure only the attributes and operations you have exposed are invoked on your MBean.
Standard MBeans can be useful if your application already has management-oriented classes to support its own manager. You can simply register these instances with the MBeanServer after minor modifications to add "implements MBean." Chapter 3 explains standard MBeans thoroughly.
2.5.2.2 Dynamic MBeans
Dynamic MBeans allow your application or domain-specific manager to define or generate the management interface for your resource at runtime. This provides a simple way for you to wrap existing nonbean-style or even non-Java resources.
A dynamic MBean can be any Java class that implements the dynamic MBean interface. The dynamic MBean interface is similar to the CORBA Dynamic Invocation Interface (DII).46 The most important thing to remember about dynamic MBeans is that they must provide their own management interfaces during runtime by maintaining their own MBeanInfo objects. The MBeanServer requests MBeanInfo from your dynamic MBean whenever it needs that information. This means that a classnameMBean interface is not used by the MBeanServer to create an MBeanInfo object. Your dynamic MBean is also responsible for implementing and validating correct invocation of the interfaces it defines in MBeanInfo. The MBeanServer delegates invocations of getAttribute(), setAttribute(), and invoke() directly to your dynamic MBean. Your dynamic MBean satisfies the request and returns it to the MBeanServer.
You can develop dynamic MBean implementations for your applications directly, have them generated, or allow a management application developer to create them. You can also develop an MBean service that will instantiate or generate the dynamic MBeans.
The next two types of MBeans we will look at are standardized types of dynamic MBeans: open MBeans and model MBeans. However, the fact that JMX defines standard types of dynamic MBeans does not mean that you cannot write your own dynamic MBeans, nor does it in any way restrict how you implement them. See Chapter 3 for a more detailed discussion of diagnostic MBeans.
2.5.2.3 Open MBeans
Open MBeans are dynamic MBeans that are restricted to accepting and returning a limited number of data types. If you use open MBeans and these basic data types, you eliminate the need for class loading. Removing the need for class loading can make it easier for you to deploy the MBean and support a highly distributed system. However, it does not remove the need for your application or a management application to understand the semantics of the data to be passed or returned. The open Mbean data types that are allowed are
Primitive data types: int, boolean, float, double, and so on
Class wrappers for primitive data types: Integer, Boolean, Float, Double, String, and so on
Table: An array of rows of the same type
Composite: An object that can be decomposed into other open data types
Your open MBeans must return an OpenMBeanInfo object from the getMBeanInfo() method. OpenMBeanInfo extends MBeanInfo, adding some additional metadata that you may supply, such as legal values, and default values. The open MBean support is optional in JMX 1.0, and the classes are not available in the current Sun JMX 1.0 Reference Implementation. See Chapter 3 for an explanation of open MBeans.
2.5.2.4 Model MBeans
A model MBean is an extension of a dynamic MBean. However, where you must write all of a dynamic MBean, you don't have to implement the model MBean. A model MBean is more than a set of interfaces; it is a customizable, standardized, dynamic MBean implementation. An implementation class of a model MBean named RequiredModelMBean must come with the JMX agent. This model MBean instance is immediately useful because your application can instantiate and customize a RequiredModelMBean instance with its own management interface information. This reuse of an existing implementation drastically reduces the amount of code you need to write to achieve manageability, and it protects your resource from JVM version and JMX agent implementation variances. Using RequiredModelMBean instances can allow your managed resources to be installed in a range of JVMs, from embedded environments to enterprise environments, without affecting your instrumentation.
The MBeanServer functions as a factory and delegator for RequiredModelMBean instances. Because RequiredModelMBean instances are created and maintained by the JMX agent, the RequiredModelMBean class implementation can vary, depending on the needs of the environment and the JVM in which the JMX agent is installed. An application that requests the instantiation of a RequiredModelMBean object does not have to be aware of the implementation specifics of a RequiredModelMBean class. The RequiredModelMbean class is responsible for implementing and managing the implementation differences between JMX and JVM environments internally. These differences may include persistence, transactional behavior, caching, performance requirements, location transparency, and remotability.
Because the RequiredModelMBean model MBean implementation is provided by the JMX agent, your application does not have to implement RequiredModelMBean; it just needs to instantiate it, customize it, and use it. Your instrumentation code is consistent and minimal. Your application gains the benefit of support for and default policies concerning logging events, data persistence, data caching, and notification handling. Your application initializes its RequiredModelMBean's ModelMBeanInfo with its identity, management interface, and policy overrides.
You can add custom attributes to the model MBean during execution. Your application-specific information can be modified without interruption during runtime. The RequiredModelMBean instance then sets the behavior interface for the MBean and does any setup necessary for event logging and handling, data persistence and currency, and monitoring for your application's model MBean instance. The model MBean default behavior and simple APIs will satisfy the management needs of most applications, but they will also allow complex application management scenarios. More details on the model MBean are given in Chapter 4.
2.5.3 JMX Agents
Your managed resources will communicate data and events to management systems with their MBeans through the JMX agent. JMX agents consist of an MBeanServer and a set of service MBeans.
2.5.3.1 The MBeanServer
The MBeanServer runs in the JVM local to the managed resources' MBeans. The MBeanServer is a registry for MBeans. It is also a repository of the current set of MBean names and references, but it is not necessarily a repository for your MBeans. The MBeanServer provides a query service for the MBeans. Upon a query, it returns the names of the MBeans, not the references. Because only names are returned, all operations on all MBeans must go through the MBeanServer. The MBeanServer acts as a delegator to the MBeans, returning the results to the requester.
The MBeanServer can be a factory for any MBean, even those you create. You have the option of instantiating MBeans directly and then registering them, or having the MBeanServer return an instance of the MBean to your application. The MBeanServer should always be a factory for RequiredModelMBean instances. The MBeanServer also provides access to the metadata about the MBeans in the MBeanInfo instance. The metadata includes the attributes, operations, and notifications provided by the MBean. The MBeanServer provides notification registration and forwarding support to MBeans representing adapters, services, and resources. The MBeanServer is discussed thoroughly in Chapter 5.
2.5.3.2 Required Services
The JMX agent includes a set of required services: the monitoring service, the timer service, the relation service, and the MBean class loader. Services are MBeans registered with the MBeanServer that provide some generic functionality that can be used by MBeanServers, MBeans, and adapters. Additional management services can be added dynamically as service MBeans by applications or management systems, making the JMX agent flexible and extensible.
The monitoring service runs monitoring MBeans on a scheduled basis. It must support basic monitoring MBeans, including Gauge, Counter, StringMatch, and StateChange. Additional or specialized monitoring MBeans can also be developed and used.
The timer service executes an operation on a timed basis. It is used by the monitoring service.
The relation service supports relationship MBeans. Relationship MBeans contain the names of a set of MBeans that are related in some way. Some kinds of possible relationships include "contains" and "depends on."
The MLet (management applet) service is an MBean class-loading service that loads an MBean across a network when an MLET tag in an HTML page is encountered.
These services are covered in more detail in Chapter 7.
2.5.4 JMX Adapters
Adapters communicate between the JMX agent and their corresponding management systems. The adapter is responsible for translating from JMX MBean types to its manager's types and taking care of any remoteness issues. Because the adapter can be implemented to mimic the manager's supported agent technology, the management system may not even be aware that JMX is in the picture. Generally, there is at least one specific adapter for each management protocol or technology required to support different management systems.
Adapters are also MBeans, and they are registered with the MBeanServer. Given that this is the case, it is possible to find out all of the adapters that are currently registered with an MBeanServer. Because adapters are MBeans, they can register for JMX notifications from the MBeanServer or other MBeans. In this case the adapter would have to implement the NotificationListener interface, and it might provide a filter to limit the notifications it receives.
Because the MBeanServer returns only names of MBeans and not instances, adapters invoke methods on MBeans only through the MBeanServer. The type of MBean that represents the resource does not affect how the adapter invokes operations on the MBean. The type of MBean does affect how much data is available to the adapter in MBeanInfo. Adapters use the MBeanServer's interface directly. Adapters are responsible for "translating" JMX management information to their native representation of the management information, so JMX provides some hints on how to do that translation using ProtocolMap instances for attributes in model MBeans. Common, though nonstandard, adapters are RMI,47 HTTP,48 and SNMP.49 CIM and IIOP adapters are in the process of standardization. Adapters are discussed in depth in Chapter 5.
2.5.5 Adapter Tools
Adapter tools typically accompany a particular adapter for a particular management system. Adapter tools will interact with the MBeanServer to create any files to represent the available management data in the MBeans in a format that the management system can consume. For example, an SNMP adapter tool might create a MIB file from the available MBeanInfo instance. This MIB file would be used by an SNMP management system to represent the management data on its console.