9.1 MBeanServer Deployment Patterns

This section discusses three JMX deployment models that we have identified: daemon, component, and driver. In the daemon model, the MBeanServer owns its own JVM separate from the application. In the component model, the MBeanServer runs in the JVM owned by the application. In the driver model, the MBeanServer owns the JVM and the application runs within the scope of the MBeanServer.

These models can be applied in a broad spectrum of environments ranging from traditional daemon-based " agents " to pervasive device applications. It is important to be aware of this spectrum when you're thinking about products and tools that take advantage of JMX technology. In all these deployment patterns, the JMX agent, or MBeanServer, functions in the agent role of the manager-agent management architecture. This section discusses some options for deploying the MBeanServer in your application, middleware, JVM, or system.

9.1.1 Daemon

The daemon deployment model for JMX is the most familiar from a traditional manager-agent systems management model, in which a management agent runs in its own process. The manager role is generally filled by a remote console and specifies data to be collected or actions to be taken by an agent. The agent runs as a separate process, or daemon, on a managed system. The agent is responsible for monitoring and acting on the local system-level resources (devices, processes, and so on) as directed by its manager.

The JMX incarnation of this model is illustrated in Figure 9.1. A platform-specific daemon process loads a Java Virtual Machine (JVM). One or more JMX agents are then instantiated by the JVM. In the JMX specification a JMX agent is defined as being " composed of an MBean server, a set of MBeans representing managed resources, a minimum number for agent services implemented as MBeans, and typically at least one protocol adaptor or connector." When we talk about instantiating an MBeanServer, we assume that the services and adapters are instantiated with it. There is no net difference between a JMX agent and an MBeanServer.

Figure 9.1. The Daemon MBeanServer

In the daemon model there are MBeans responsible for monitoring and/or managing specific system-level resources. The manager connects to the MBeanServer(s) via the available adapters. In fact, the MBeanServer must have adapters to handle remote communications to both manager and possibly managed resources. The local MBeans that represent the remote resources may use the adapters to communicate with their resources. Managed applications must use an adapter to communicate with the MBeanServer ”that is, create, update, invoke, and remove MBeans. If the application is written in Java, then an RMI adapter is most commonly used. Unfortunately, at this time the JMX adapters are not standardized and RMI adapters may have different interfaces between MBeanServers. Hopefully some common adapters for RMI and HTTP will be standardized as part of the ongoing JCP (Java Community Process) for JMX.

Advantages of a JMX daemon over traditional native daemons include portability, dynamic loading, and standardization. Because the JMX agent is written in Java, it runs unchanged on most platforms. Only the JMX daemon, a much simpler piece of code, needs to be ported. The MLet service allows MBeans for resources on the managed node to be loaded by the JMX agent as needed. In addition, local management services that act as a proxy for the remote manager can also be loaded dynamically. Finally, JMX provides a standard model for both the instrumentation MBeans and the MBeanServer they communicate with.

Having just one MBeanServer in a system, or one MBeanServer serving several JVMs and applications, can be more efficient in terms of system resources and interaction complexity. There is just one list of MBeans to get from one MBeanServer (or at least fewer MBeanServers). There is only one instance of each type of adapter. This reduction of complexity can be a big benefit because adapters that perform object model and protocol conversion sometimes have a very large footprint and resource requirement. This arrangement can be simpler for management systems as well because they have just one, or fewer, connections to the managed system to work with. Applications using external MBeanServers have a smaller footprint and use fewer system resources. The overhead of the managers interacting with the MBeanServer does not add to the resources used by the application.

Using a daemon JMX agent also means that the MBeanServer exists outside of the scope of the application and can therefore be used to control the lifecycle of the application ”that is, start, stop, monitor availability, and recover.

However, using a daemon JMX agent is a bit trickier for applications. Applications in other JVMs (or not in any JVM at all) using daemon JMX agents must be able to find the MBeanServer, use the MBeanServer through an adapter, and handle remoteness issues.

9.1.1.1 Adapters

Because JMX adapters are not standardized, the application's choice of an adapter may depend on the JMX implementation it uses. The application may either use one that's already provided or install its own into the JMX agent when it is installed.

9.1.1.2 Discovery

MBeanServer and adapter discovery has also not been standardized for JMX. The JSR 160 expert group for JMX is working on this area as well. In the meantime there are several ways to find a daemon MBeanServer:

• The MBeanServer's RMI stub reference can be saved in an environment variable

• A JNDI name for finding the MBeanServer's reference can be saved in the application's configuration during installation or deployment

• A "well-known" name for looking up an MBeanServer using a directory lookup (like JNDI). Of course, this well-known name is not yet standardized either and will apply only for the application, domain, or enterprise.

9.1.1.3 Remoteness

Because the MBeanServer is remote, the managed applications must be able to deal with the failures and delays due to MBeanServer remoteness. The applications must be programmed to handle the situation in which the MBeanServer doesn't exist or is suddenly unavailable. The managed application cannot just create another one to use. It will have to store updates for later or remember its MBean's state so that it can reset it when the MBeanServer is available again. In fact, these same requirements are true for managers of the remote MBeanServer as well.

9.1.2 Component

In the JMX component deployment model the MBeanServer is embedded in the application being managed as illustrated in Figure 9.2. Here the MBeanServer is actually a component of the application and is responsible for providing the application's management interface.

Figure 9.2. The Component MBeanServer

Making the MBeanServer and application MBeans part of the application provides access to much finer-grained instrumentation. More extensive control of the application by the manager is also possible with this model; instead of just starting and stopping the application, the manager can tune it dynamically at runtime via the attributes and operations of the application resource MBeans registered with the MBean server. As more applications become JMX enabled, we expect this model to become more common.

One advantage of this approach is that the application is in complete control of instantiating the MBeanServer. The application can count on an MBeanServer being there when it needs it. If the MBeanServer is not there, the application can create one without concern for duplication. Containing its own MBeanServer also means that the application is more easily portable to other systems that may or may not have a suitable MBeanServer available. These types of applications have fewer installation requirements on their target systems.

One of the challenges of supporting this model is finding a way to federate JMX agents. A single machine may run multiple JMX-enabled applications, each of which may have an embedded JMX agent. Those agents need to be organized ”federated ”in some way so that they appear as a single agent in a management console. We will look at ways to federate JMX agents later in this chapter (see Section 9.4.5).

9.1.3 Driver

The driver deployment model for JMX is similar to the component model. In the driver case, the JMX agent becomes the core of the application rather than a component of an application. The MBeanServer is used to start and own the JVM. The application actually runs within the MBeanServer's JVM. Because the MBeanServer owns the JVM, it will always be available. Therefore, any applications running in the JVM can always count on the MBeanServer being available. The driver model is illustrated in Figure 9.3.

Figure 9.3. The Driver MBeanServer

The application is designed and constructed as a set of cooperating MBeans that are loaded at startup. Therefore, the MBeanServer used in the driver model must have a bootstrap service. This service is responsible for loading and configuring the application components when the MBeanServer is instantiated. The application's configuration information could come from a variety of sources ”for example, a directory service or some device firmware. Either the bootstrap service can start the MBeans that in turn start the application they manage, or it can start the application components that in turn instantiate their MBeans.

In either case, the MBeans can be designed so that they control the lifecycle of the application they are associated with. Instantiating MBeans that start the application components is straightforward. You should create the MBean in the MBeanServer using the MBeanServer as a factory or by the MBeanServer bootstrap. If you choose to instantiate application components that create the MBeans, then you must decide if you are going to remove the MBean when the application is stopped. If you remove the MBean, you will not be able to do lifecycle control (start and stop of the application) with it. If you let the MBean continue after the application is stopped , then the application must be careful not to try to create a new one when one exists, and always interact with it through the MBeanServer. MBeans that continue to exist can be used to stop and restart applications, but another strategy must be used for the initial start of the application.

The driver style is the most reliable strategy, but the JMX support must be designed into the application from the beginning, and it is very hard, if not impossible , to use for existing applications without causing a major overhaul of the application. The component strategy has less impact on the existing application than the driver style, but the application will still require modification in order to add JMX manageability. The daemon style is a more traditional style and allows management of existing applications without requiring that the applications be recompiled. The daemon style requires that discovery and remote access be provided for, which the component and driver styles do not do. However, the daemon style can be used to manage non-Java applications and existing Java applications with less impact.