Skip navigation.

Developing Manageable Applications with JMX

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Designing Manageable Applications

Within JMX, there are several viable design patterns and deployment options that you can use to make your application manageable. BEA's recommended design patterns assume that the instrumentation of your Java classes should:

The following sections describe designing manageable applications:


Best Practices

The following sections describe BEA's recommendations for designing manageable applications:

Use Standard MBeans

Of the many design patterns that JMX defines, BEA recommends that you use standard MBeans, which are the easiest to code. In the simplest design pattern for standard MBeans, you do the following:

  1. Create an interface for the management properties and operations that you want to expose.
  2. Implement the interface in your Java class.
  3. Invoke the method and pass your management interface in the method's parameter.

The MBean server introspects your interface, finds the implementation, and registers the interface and implementation as an MBean.

In this design pattern, the management interface and its implementation must follow strict naming conventions so that the MBean server can introspect your interface. You can circumvent the naming requirements by having your Java class extend See StandardMBean in the J2SE 5.0 API Specification.

Use the Runtime MBean Server

A JVM can contain multiple MBean servers, and another significant design decision is whether to register your MBeans in the JVM's platform MBean server or the WebLogic Server Runtime MBean Server.

As of JDK 1.5, processes within a JVM (local processes) can instantiate a platform MBean server, which is provided by the JDK and contains MBeans for monitoring the JVM itself. Local classes can also register MBeans in this MBean server.

In addition to the platform MBean server, the JVM for any WebLogic Server instance also contains a Runtime MBean Server. (The Administration Server also contains a Domain Runtime MBean Server and an Edit MBean Server, but the Runtime MBean Server is the only one that allows the registration of custom MBeans. See MBean Servers in Developing Custom Management Utilities with JMX).

BEA recommends that you register custom MBeans in its Runtime MBean Server. With this option:

The Runtime MBean Server registers its interface in the JNDI tree. See Make Local Connections to the Runtime MBean Server in Developing Custom Management Utilities with JMX.

Using the JVM Platform MBean Server

If it is essential that JMX clients be able to monitor your custom MBeans, WebLogic Server MBeans, and the JVM's platform MBeans through a single MBean server, then you can configure the Runtime MBean Server to be the platform MBean server. With this option:

To configure the WebLogic Runtime MBean Server to be the JDK platform MBean Server, set the WebLogic JMXMBean PlatformMBeanServerEnabled attribute to true and restart the servers in the domain. See JMXMBean in the WebLogic Server MBean Reference.

Use ApplicationLifecycleListener to Register Application MBeans

If you are creating MBeans for EJBs, servlets within Web Applications, or other modules that are deployed, and if you want your MBeans to be available as soon as you deploy your application, listen for notifications from the deployment service. When you deploy an application (and when you start a server on which you have already deployed an application), the WebLogic Server deployment service emits notifications at specific stages of the deployment process. When you receive a notification that the application has been deployed, you can create and register your MBeans.

There are two steps for listening to deployment notifications with ApplicationLifecycleListener:

  1. Create a class that extends weblogic.application.ApplicationLifecycleListener. Then implement the ApplicationLifecycleListener.postStart method to create and register your MBean in the MBean server. The class will invoke your postStart() method only after it receives a postStart notification from the deployment service. See Programming Application Lifecycle Events in Developing Applications with WebLogic Server.
  2. In the weblogic-application.xml deployment descriptor, register your class as an application listener class.

For an example of this technique, see the MedRec example server.

Alternatives That Use Only JDK Classes

Using BEA's ApplicationLifecycleListener is the easiest technique for making an MBean share the life cycle of its parent application. If you do not want to use proprietary WebLogic Server classes and deployment descriptor elements for managing a servlet or an EJB, you can do the following:

Unregister Application MBeans When Applications Are Undeployed

Regardless of how you create your MBeans, BEA recommends that you unregister your MBeans whenever you receive a deployment notification that your application has been undeployed. Failure to do so introduces a potential memory leak.

If you create a class that extends ApplicationLifecycleListener, you can implement the ApplicationLifecycleListener.preStop method to unregister your MBeans.

For EJBs and Servlets Place Management Logic in a Delegate Class

If you want to expose management attributes or operations for any type of EJB (session, entity, message) or servlet, BEA recommends that you implement the management attributes and operations in a separate, delegate class so that your EJB or servlet implementation classes contain only business logic, and so that their business interfaces present only business logic. See Figure 3-1.

Figure 3-1 Place Management Properties and Operations in a Delegate Class

Place Management Properties and Operations in a Delegate Class


In Figure 3-1, business methods in the EJB push their data to the delegate class. For example, each time a specific business method is invoked, the method increments a counter in the delegate class, and the MBean interface exposes the counter value as an attribute. For an example of this technique, see the MedRec example server.

This separation of business logic from management logic might be less efficient than combining the logic into the same class, especially if the counter in the delegate class is incremented frequently. However, in practice, most JVMs can optimize the method calls so that the potential inefficiency is negligible.

If this negligible difference is not acceptable for your application, your business class in the EJB can contain the management value and the delegate class can retrieve the value whenever a JMX client requests it.

Use Open MBean Data Types

If remote JMX client will access your custom MBeans, BEA recommends that you limit the data types of your MBean attributes and the data types that your operations return to those defined in All JVMs have access to these basic types. See OpenType in the J2SE 5.0 API Specification.

If your MBeans expose other data types, the types must be serializable and the remote JMX clients must include your types on their class paths.

Emit Notifications Only When Necessary

Each time an MBean emits a notification, it uses memory and network resources. For MBean attributes whose values change frequently, such memory and resource uses might be unacceptable.

Instead of configuring your MBeans to emit notifications each time its attributes change, BEA recommends that you use monitor MBeans to periodically poll your custom MBeans to determine whether attributes have changed. You can configure the monitor MBean to emit a notification only after an attribute changes in a specific way or reaches a specific threshold.

For more information, see Best Practices: Listening Directly Compared to Monitoring in Developing Custom Management Utilities with JMX.


Additional Design Considerations

In addition to BEA's best practices, consider the following:


Skip navigation bar  Back to Top Previous Next