Developing Manageable Applications with JMX
Several viable JMX design patterns and deployment options can make your application more manageable. The following sections describe BEA best practices for designing manageable applications. The last section, Additional Design Considerations on page 3-6, provides alternatives to some BEA recommendations and discusses additional design considerations.
javax.management.MBeanServerConnection.createMBean()method and passing your management interface in the method's parameter.
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
StandardMBean in the J2SE 5.0 API Specification.
BEA recommends that you register custom MBeans in the WebLogic Server Runtime MBean Server. (Each WebLogic Server instance contains its own instance of the Runtime MBean Server. See MBean Servers in Developing Custom Management Utilities with JMX.) With this option:
The WebLogic Server Runtime MBean Server registers its
javax.management.MBeanServer interface in the JNDI tree. See Make Local Connections to the Runtime MBean Server in Developing Custom Management Utilities with JMX.
Your local processes can register custom MBeans in this MBean server, but the custom MBeans will not be protected by the WebLogic Server security framework and JMX clients must connect to multiple MBean servers to monitor your application's MBeans and WebLogic Server MBeans. 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, you can configure the runtime MBean server to be the JVM platform MBean server. See Registering MBeans in the JVM Platform MBean Server on page 3-7.
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.
weblogic.application.ApplicationLifecycleListener. Then implement the
ApplicationLifecycleListener.postStartmethod to create and register your MBean in the MBean server. The class invokes your
postStart()method only after it receives a
postStartnotification from the deployment service. See Programming Application Lifecycle Events in Developing Applications with WebLogic Server.
If you do not want to use proprietary WebLogic Server classes and deployment descriptors to register application MBeans, see Registering Application MBeans by Using Only JDK Classes on page 3-7.
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 information on implementing the
preStop method, see Register the MBean.
If you want to expose management attributes or operations for any type of EJB (session, entity, message-driven) 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.
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.
If a 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 j
avax.management.openmbean.OpenType. All JVMs have access to these basic types. See
OpenType in the J2SE 5.0 API Specification.
Instead of configuring your MBeans to emit notifications each time its attributes change, BEA recommends that you use monitor MBeans to poll your custom MBeans periodically 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.
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, you can configure the runtime MBean server to be the JVM platform MBean server. With this option:
Warning: With this local access, there are no WebLogic Server security checks to make sure that only authorized users can access WebLogic Server MBeans. Any application that is running in the JVM can access any of the WebLogic Server MBeans in the Runtime MBean Server or JDK platform MBean Server. Do not use this configuration if you cannot control or cannot trust the applications that are running within a JVM.
Remote access to the platform MBean server can be secured only by standard JDK 1.5 security features (see http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#remote). If you have configured the WebLogic Server Runtime MBean Server to be the platform MBean server, enabling remote access to the platform MBean server creates an access path to WebLogic Server MBeans that is not secured through the WebLogic Server security framework.
To configure the WebLogic Runtime MBean Server to be the JDK platform MBean server, set the WebLogic
PlatformMBeanServerEnabled attribute to true and restart the servers in the domain. See
JMXMBean in the WebLogic Server MBean Reference.
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:
javax.servlet.Filterthat creates and registers your MBean when a servlet calls a specific method or when the servlet itself is instantiated. See
Filterin the J2SE 5.0 API Specification.
For an EJB, implement its
javax.ejb.EntityBean.ejbActivate() method to create and register your MBean. For a session EJB whose instances share a single MBean instance, include logic that creates and registers your MBean only if it does not already exist. See
EntityBean in the J2SE 5.0 API Specification.
While you might design one managed object for each business object, there is no requirement for how your management objects should relate to your business objects. One management object could aggregate information from multiple business objects or conversely, you could split information from one business object into multiple managed objects.
The organization that you choose depends on the number of MBeans you want to provide to the system administrator or operations staff contrasted with the difficulty of maintaining a complex management architecture.
If you package your management classes in an application's
APP-INF directory, all other classes in the application can access them. If you package the classes in a module's archive file, then only the module can access the management classes.
For example, consider an application that contains multiple Web applications, each of which contains its own copy of a session EJB named EJB1. If you want one MBean to collect information for all instances of the session EJB across all applications, you must package the MBean's classes in the
APP-INF directory. If you want each Web application's copy of the EJB to maintain its own copy of the MBean, then package the MBean's classes in the EJB's JAR file. (If you package the classes in the EJB's JAR, then you distribute the MBean classes to each Web application when you copy the JAR to the Web application.)