J2EE is rapidly becoming an established platform for deploying long-running business-critical applications. As the number of J2EE applications grows and their importance increases, a standard way to manage J2EE servers and applications is becoming a key requirement.

Java Management Extensions (JMX) provide a pure Java management infrastructure that can be used for all Java-based software.

BEA WebLogic's support for JMX comes in not only providing a JMX implementation, but in basing all of its key administration and management features on this standard. The administration and management features of WebLogic are now extensible ­ open to both developers and third-party tool integrations.

There are obvious benefits in improved and extensible administration, but J2EE application developers still face several questions: What exactly does JMX provide and how is it likely to be used? What management features should developers build into J2EE applications? Which management facilities should the application server provide automatically? This first article in a two-part series on WebLogic JMX provides a brief overview of JMX and discusses some of its implications for enterprise Java developers.

JMX and Application Management
An application is instrumented if it provides a well-defined public interface that allows other applications to access its management or administrative functions. The management interface of an application does not generally resemble its public client interface. Instead, it is intended for privileged users, exposing data and functions for monitoring and administration. A component that has been instrumented to provide such a management interface is a manageable resource.

Manageable resources include devices such as printers, network routers, and telephone switches. More generally, any software component that resides on a server or in a distributed environment that is available to service requests is a good candidate for instrumentation. J2EE components fit well into this larger category. Management interfaces for such components include functions for tracking resource use, measuring client volumes, generating error logs, stopping and starting services, and load-balancing.

Developers (when tuning and debugging systems), system administrators (when monitoring applications and intervening when necessary), and other users employ management applications to access instrumented manageable resources. Management applications range from graphical resource-use monitors that run locally to Web-based administrative consoles that can be accessed remotely. Many of these tools use standard protocols to discover and display managed resources and their interfaces dynamically.

JMX is intended to be simple enough to allow developers to rapidly provide a management layer for either new or existing Java applications, and comprehensive enough to be adapted to other standard (non-Java) management protocols. The JMX specification, currently in its 1.0 release, is being developed through the Java Community Process. The JMX reference implementation is available from Sun Microsystems, which also provides a commercial JMX-based product, the Java Dynamic Management Kit (JDMK). A number of J2EE vendors now include JMX implementations in their application servers; WebLogic is one of the more comprehensive of these.

A specification for J2EE-specific management requirements based on JMX is currently under development, as are other specifications that describe how JMX should be adapted to other management protocols.

JMX Architecture
JMX presents a layered architecture, shown in Table 1 and Figure 1. At the two extremes of the JMX levels are the instrumentation level and the management level, representing managed resources and management applications. Between these are the agent and distribution levels, which provide the necessary protocols for applications in the management level to access the manageable resources of the instrumentation level.

Managed Beans, or MBeans, make up the instrumentation level. These objects represent the manageable resources of the system, and are the primary components of the JMX architecture.

An MBean Server is the most essential part of the agent level. It provides a means for creating, registering, and finding MBeans within the system.

The agent level includes several services that are also represented by MBeans.

The distribution level may provide remote access to the agent level through CORBA, RMI, or other means, and may also provide adapters for other protocols. It may provide security as well.

The management level consists of the external applications that can access the MBeans via the APIs exposed through the agent layer, using protocols provided by the distribution layer.

WebLogic goes beyond the JMX 1.0 specification to provide a distribution layer that maps logically onto the underlying agent level. Both local and remote users of JMX can access MBeans through the corresponding MBeanHome, a WebLogic-specific component that provides a client with access to MBeans. WebLogic's MBeanHome components offer some distribution facilities, as well as other features that make them easy to use.

Using JMX
Simple Instrumentation
JMX's instrumentation level provides a variety of Managed Bean types for developers to implement depending on their requirements. It is important to note that MBeans bear no resemblance to Enterprise JavaBeans (EJBs). An MBean is like a regular JavaBean, having a well defined interface, complete with getters and setters. Unlike EJBs, they have no built-in transactional security or distribution facilities.

A Standard MBean, the most basic MBean, is not required to implement a special JMX interface or extend a particular abstract class. To be considered a Standard MBean, a class must simply implement an interface whose name matches that of the class with the additional MBean suffix. The MBean interface defines the management interface for the corresponding MBean class. A simple MyService MBean is shown in Listing 1 (code for this article may be found at www.sys-con.com/weblogic/sourcec.cfm).

Making the MyService MBean available within a JMX agent is straightforward. The examples in Listings 2 and 3 are based on the standard JMX interfaces and can be used with Sun's reference implementation.

Registration of an MBean with the agent layer is carried out using the MBeanServerFactory, MBeanServer, and ObjectName classes, all part of the standard JMX API, found in the javax.management package. The MBeanServer interface provides a rich API for registering and manipulating MBeans; essentially, all management of MBeans is carried out using this interface.

The MBeanServerFactory is a class that provides a broker for the various MBeanServer instances within a system. It is an implementation-neutral way of obtaining references to an MBeanServer. The API provided by the MBeanServerFactory allows for multiple servers to be active within the system.

An MBean is registered under a particular name that is used to uniquely and meaningfully identify it. For most MBeanServer operations, this name is represented by an ObjectName instance. It is a structured piece of data that complies with the JMX naming conventions. MBean names are given by a domain name, followed by a colon, and then by a sequence of one or more property-value pairs. Certain MBeanServer APIs support pattern-matching for MBean names, allowing users to query for a range of MBeans whose names conform to a given object name expression.

As shown in Listing 2, the basic registration process is quite simple. However, additional JMX facilities provide hooks for developers during the registration process, if required. For example, the MBean can implement an additional MBean Registration interface that will give the MBean- event callbacks during registration. These callbacks (preRegsiter, postRegister, deregister, and postDeregister) allow the MBean to obtain a reference to the MBeanServer, allowing the MBean to perform management actions on other MBeans. MBeans are used by invoking their methods through the MBeanServer interface (see Listing 3).

Intermediate and Advanced JMX Use
Standard MBeans are simple, as is the basic API for manipulating the MBeanServer. However, JMX also offers functionality that goes far beyond basic use. Instead of Standard MBeans, implementers of MBeans can choose to build Dynamic MBeans or Model MBeans, and may make use of the JMX Notification framework. The agent level also has other features, including a number of built-in MBean monitors, and services for loading and relating MBeans.

Dynamic MBeans
Dynamic MBeans allow the management API of an MBean to be defined dynamically instead of through a predefined interface. For all MBeans, the agent layer discovers the management interface and exposes it through various APIs. For Standard MBeans, this interface is discovered by inspection of the MBean interface. For Dynamic MBeans, the agent level discovers the management interface by invoking particular methods on the MBean (see Listing 4).

Dynamic MBeans generally require more coding than Standard MBeans, but allow the management interface to change at runtime, and allow the MBean developer to expose more information (such as textual descriptions of the MBean and its operations) through the agent level.

The surprising aspect of DynamicMBeans is that they present essentially the same client view to their users as Standard MBeans. A Dynamic MBean's attributes are displayed and its actions are invoked through MBeanServer methods in the same way as the much simpler Standard MBeans.

Model MBeans
Although a specialized form of Dynamic MBeans, Model MBeans are completely different in how they are built and configured. Essentially, a Model MBean is a generic Dynamic MBean that can be loaded with an object that represents the manageable resource. A JMX Provider is required to provide Model MBean implementations that developers can configure to wrap their resources without creating any MBeans themselves. As a result, Model MBeans require far less coding than Dynamic MBeans. To build a Model MBean, the developer must

• Create an empty Model MBean,
• Provide a managed resource delegate against which all operations will be executed,
• Provide an MBeanInfo object that lists the allowed operations for the MBean,
• Register the Model MBean with the MBeanServer.

JMX Notifications
The JMX Notification framework allows MBeans to notify management applications of changes of state or other events that have occurred in the manageable resources of the system. Various subclasses of javax.management.Notification (which extends java.util.EventObject) can be used by MBeans that implement javax.management.NotificationBroadcaster to signal events to objects that have implemented the javax.management.NotificationListener interface.

MBean Monitors
Instead of relying on MBeans to notify interested parties of changes in their state, management applications can actively track MBean attributes through MBean monitors provided by the agent level. A JMX agent implementation will provide various MBean Monitors. These are used to detect changes in specific MBean attributes. Several monitor types are provided with a JMX agent, including

• CounterMonitor: Checks the value of attributes that act as counters (these are integer types and have nonnegative values)
• StringMonitor: Detects changes in string values
• GaugeMonitor: Observes fluctuations in integer or floating point attributes within a range.

JMX MetaData
One of the key things that JMX provides is a way for managed resources to describe themselves to management applications. This allows management applications to be written independently of the systems they administer, without knowledge of the operations and attributes of the manageable components they will manipulate. The description of manageable resources is carried out through the JMX metadata data classes ­ MBeanInfo, MBeanOperationInfo, MBeanConstructorInfo, MBeanAttributeInfo, and so forth.

Without a metadata infrastructure, management applications would have to rely on the Java reflection API for this discovery process. By providing this framework, JMX avoids the difficulties associated with reflection and provides a standard means of self-description that allows developers to provide more information than is available through reflection.

Roles in JMX
One of the main questions with JMX is not how to use it ­ its architecture and API are straight-forward ­ but when and why to use it. The potential users of JMX technology are best described through a set of illustrative roles (see Table 2).

Java developers will likely find themselves in the roles of application developer, while building manageable applications, and management solutions developer, while creating ways to better manage existing applications. The application developer develops Java applications that provide a runtime management interface. J2EE applications built with technologies such as JSPs, servlets, EJB, JMS, and so on are likely to be the most common manageable applications. This role will use the instrumentation level of JMX.

Management solutions developers will create customized administration and monitoring systems that will function as components in the management layer of JMX. They will be accessing instrumented application components from the agent level through the distribution level. These developers may have to develop additional protocol adapters in the distribution level if they are integrating legacy management systems.

Management tool vendors may build management tools in Java, or may enhance existing tools to use JMX. This may include adapting existing management protocols to JMX.

For both the management solutions developer and the management tool vendor, the end-user of their work is the system administrator. This role uses these tools and solutions to manage the running applications ­ monitoring their behavior, running diagnostic checks, shutting down and starting up services, and doing manual load-balancing as required.

A standalone Java application may provide a complete JMX implementation, but the more common scenario is that the vendors of J2EE servers will also become JMX Providers. The JMX Provider provides an implementation of JMX either as a framework to be incorporated into standalone Java applications, or as part of an application server.

JMX Use in J2EE
The inclusion of JMX in J2EE-based application servers will enable developers to:

• Provide application-specific management interfaces that can be used by in-house and third-party management tools
• Leverage existing application-server instrumentation to create custom reporting and monitoring applications
• Integrate third-party management tools into their J2EE applications.

Perhaps the most significant use of JMX technology by application developers will be in writing interfaces and reporting tools that make use of the instrumentation already provided by the application server. In other words, it is likely that developers will develop more applications at the JMX management layer than building MBeans themselves.

Ideally, integrating JMX into J2EE application servers will make the configuration and administration facilities of such servers extensible, allowing developers to create simplified administration consoles, integrate reporting facilities and statistics-gathering into the server, and tie server and application events to logging facilities or messaging channels.

The more instrumentation provided by the application server, the less need there will be to build JMX interfaces for individual J2EE application components. Instrumentation provided by the application server will be safer than anything built into individual components, and will provide a consistent management view across all deployed applications. Standard J2EE management facilities may include:

• Deployment, undeployment, and redeployment of components
• Server availability and cluster administration
• Security management
• Error logging
• Connector monitors (i.e,. JDBC connection tracking)

Clearly, developers will rely on the J2EE platform to supply more than just a JMX implementation. The platform will use JMX to provide access to built-in administration, management, and monitoring facilities, and ensure that applications deployed on the platform are preinstrumented and ready to be managed through app-server or third-party tools. WebLogic JMX does precisely this, offering a comprehensive set of prebuilt MBeans that provide access to all administration and monitoring features.

JMX Pitfalls
Overuse of JMX is a pitfall that should be avoided. It is not designed to be a general-purpose distributed object system. JMX use should be limited to those aspects of the system that are clearly management-related. Some other areas in which JMX users should proceed with care include:

1.   Mixing JMX directly with EJB: Care must be taken to ensure that JMX code does not violate the security and transactional integrity of the EJBs. An EJB cannot also be an MBean for several reasons:

The EJB life cycle, which allows beans to be pooled, change identity, and be destroyed, does not match that of MBeans, which are treated like normal objects living within the virtual machine;

If an EJB acts as an MBean, the agent layer would have direct access to the bean-instance, bypassing the component interface and violating the transaction-and security-checking code provided by the container;

The EJB deployment, creation, and querying protocols do not match those provided by JMX.

EJB components should not also be MBeans, nor should they expose their underlying bean instance directly to MBeans. It is possible, however, for MBeans to access EJBs through the standard EJB protocols. Unfortunately, MBeans would not be able to access EJBs through the new local interfaces provided by EJB 2.0 since these are restricted to use by other enterprise beans. Consequently, MBeans would have to access EJBs as remote clients, and the operations available to the MBeans would be the same as those exposed through the regular client interfaces.

2.   Distributed JMX use: Lack of details for distribution in the specification puts developers who are trying to create application server­neutral management solutions at a disadvantage. MBeanHomes make up for this by providing a straightforward distribution mechanism.

3.   Relying on Standard J2EE management features: There is no official statement on what management facilities should be present in an application server. The existing management and administration facilities in WebLogic are a good example of the direction in which these specifications are likely to proceed.

Conclusions
JMX provides an incredibly simple and flexible way to make Java applications manageable, and a standard way to build powerful management applications. J2EE application servers have reached a level of maturity where management facilities are a requirement. As these two technologies evolve, developers of J2EE applications will see an increased need to make their applications JMX aware, and will see more JMX-based management tools appear in the application server marketplace. Although JMX is based on well proven management concepts and products, its use in application servers is in its infancy but as with all enterprise Java technology, it is bound to grow up quickly.

In part two of this series, we will look at WebLogic's JMX implementation, and discuss some concrete ways that it can be used to instrument J2EE applications.

References

Sun Microsystems (July 2000). "Java Management Extensions (JMX) Instrumentation and Agent Specification (JSR 3)."
http://jcp.org/jsr/detail/3.jsp.

Sun Microsystems. "J2EE Management (JSR 77)".
http://jcp.org/jsr/detail/077.jsp.

Sun Microsystems. "CORBA Adapter for JMX (JSR 70)."
http://jcp.org/jsr/detail/070.jsp.

Sun Microsystems. "WBEM Services Specification (JSR 48)."
http://jcp.org/jsr/detail/48.jsp

Sun Microsystems (March 2001). "Java Platform Enterprise Edition Specification, v1.3 (proposed final draft 3)."
http://jcp.org/jsr/detail/3.jsp.

Sun Microsystems. "IIOP Protocol Adapter for JMX Specification (JSR 70)."
http://jcp.org/jsr/detail/070.jsp.

Sun Microsystems (2001). "Java Platform Enterprise Edition Specification, v1.3 (proposed final draft 3)."
http://jcp.org/jsr/detail/3.jsp.

Sun Microsystems (April 2001). "Enterprise Java Beans Specification v 2.0 (public final draft 2)."
http://java.sun.com/products/ejb/

Sun Microsystems (June 1999). Java Management Extensions White Paper: "Dynamic Management for the Service Age; Revision 01."
http://java.sun.com/products/JavaManagement/doc.html

BEA Systems (2001). "Using WebLogic Server JMX Services."
http://e-docs.bea.com/wls/docs61/jmx/index.html.

• Figure 1
• Figure 2
• Figure 3
• Source Code (zip file)