9.3 MBean Registration and Lifecycle

Now that you have MBeans for your application, they need to be registered with the MBeanServer. There are several ways that you can do this: having the application register the MBean, having a third party register the MBean, having an adapter register the MBean, and having the MBeanServer register the MBean.

9.3.1 Registration by Application

The managed application or component can instantiate its own MBean and register it with the MBeanServer during initialization of either the application or the component (See Figure 9.6). In this case the MBean runs in the scope of the application. There are pros and cons to this mode of MBean registration. The pros are that the application can always count on the existence of the MBean, and it can keep a reference to the MBean. If an application has a reference to the MBean it has created, updates of attribute values can be done much more efficiently because they don't have to go through the MBeanServer.

Figure 9.6. The Application Creates the MBean Locally and Registers It with an External MBeanServer

graphics/09fig06.gif

One of the cons to this approach is that the MBean exists only if the application is already up. First let's examine the case in which the application always creates a new MBean during initialization and removes the MBean during destruction. Therefore the MBean cannot stop the application without being destroyed , and obviously the MBean cannot start the application. So if you need application lifecycle control with your MBean, this approach won't work. Another consideration is the life of the application's metrics. Often metrics are running counters that should not be reset to 0 every time the application is stopped and restarted. Because the MBean goes away, the metrics will be reset to 0 when the application starts again. One way to avoid this is to persist the MBean's data from time to time, or at least before destruction.

A final consideration against this approach is that there is no way for a management system to query the set of MBeans registered with the MBeanServer and be able to determine which applications are down. It would know only that the application was "down" because the MBean is not registered. A management system would have to compare the list of MBeans that are registered with the list of MBeans that should be registered and declare the missing MBeans as down applications. This means not only that someone has to keep an accurate list of which MBeans or applications should be available in a JVM or system, but also that the assumption that missing applications are down may be an inaccurate conclusion. A generalized management system may not even know to look specifically for the existence of the MBean.

One solution to this lifecycle problem is to have the application create the MBean and not remove it during destruction. The application must only create the MBean on subsequent initializations if there is not already one registered with the MBeanServer. Now the MBean can be used to stop and restart the application, and metrics will continue to accumulate beyond the lifecycle of an instance of the application. However, the initial start of the application must be provided for without the MBean. The application should use the MBeanServer as a factory for instantiating the MBean, as shown in Figure 9.7, instead using the MBean's constructor to instantitate the MBean for reliability reasons. As long as the MBeanServer is not in the scope of the application, you should be all set. Now, the MBean is always listed by the MBeanServer, even if the application is not currently up. The management system does not have to try to guess that the MBean is missing and that this means the application might be down. Don't forget that the application's uninstall() or stop() method must clean up the MBean by deregistering it from the MBeanServer.

Figure 9.7. The Application Creates the MBean within an External MBeanServer

graphics/09fig07.gif

9.3.2 Registration by Third Party

In this approach a separate application is responsible for instantiating the MBean for the application and registering it with the MBeanServer, as shown in Figure 9.8. This is better than the application's instantiating its own MBean because the MBean exists regardless of the availability of the application being managed.

Figure 9.8. A Third-Party Application Creates the Application and the MBean in an External MBeanServer

graphics/09fig08.gif

One common third-party application is a system initialization or startup application that initializes the MBeanServer, applications, and MBeans in the JVM. If the application is distributed in nature, the startup application may also discover the distributed components and create sessions with them.

9.3.3 Registration by Management Adapter

Many management vendors specialize in managing particular types of resources. For example, both Tivoli and BMC have solutions for managing databases. For these solutions, databases themselves have to create any specific management instrumentation. Most of the management is done from "outside" the database. If the database were to be managed through a JMX MBean, Tivoli's MBean and BMC's MBean would probably look nothing alike, especially considering that they compete in the amount and quality of function they provide. Therefore, each vendor would want provide its own MBean to manage the resource. Each vendor would also need to provide its own adapter from JMX to its proprietary management infrastructures . In this case it makes the most sense to have the management system's adapter instantiate its own version of the MBean for the targeted managed resource, as shown in Figure 9.9.

Figure 9.9. A JMX Adapter Creates the MBean

graphics/09fig09.gif

This approach has the advantage that the semantics of the MBean are well understood and supported by its contributing management system. In addition, management systems can dynamically add new management capabilities.

9.3.4 Registration by MBeanServer Bootstrap

In this case the MBeanServer may have a bootstrap mechanism that creates a set of predefined MBeans. Although the JMX specification does not define a bootstrap mechanism, nearly all the decent JMX implementations do, and you should take advantage of it. If you use the bootstrap, when the MBeanServer starts, the application MBeans will be instantiated and registered as well, as shown by Figure 9.10. This is an especially elegant solution for MBeans that need lifecycle control over the application or MBeans whose initialization starts the application itself. Generally, the bootstrap mechanism is driven by configuration files that today are often XML formatted. Other ways to provide bootstrap information are through database access and environment variables .

Figure 9.10. A Bootstrap Program Creates the MBean, Which Starts the Application

graphics/09fig10.gif



Java and JMX. Building Manageable Systems
Javaв„ў and JMX: Building Manageable Systems
ISBN: 0672324083
EAN: 2147483647
Year: 2000
Pages: 115

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net