Java Management Extensions (JMX) has been in development at Sun Microsystems for several years, formerly named JMAPI, and lately has been increasingly associated with the management of the J2EE platform as an underlying architecture for J2EE servers.
JMX allows a centralized management of managed beans, or MBeans, which act as wrappers for applications, components, or resources in a distributed network. This functionality is provided by a MBean server, which serves as a registry for all MBeans, exposing interfaces for manipulating them. In addition, JMX contains the m-let service which allows dynamic loading of MBeans over the network. In the JMX architectural model, the MBean server becomes the spine of the server where all server components plug in and discover other MBeans via the MBean server notification mechanism.
The MBean server itself is extremely lightweight. Thus even some of the most fundamental pieces of the server infrastructure are modeled as MBeans and plugged into the MBean server core, for example, protocol adapters. Implemented as MBeans, they are capable of receiving requests across the network from clients operating in different network protocols, like SNMP and WBEM, enabling JMX-based servers to be managed with tools written in any programming language. The result is an extremely modular server architecture, and a server easily managed and configured remotely using a number of different types of tools.
As an enterprise Java developer you might be wondering how and where JMX fits into the enterprise. JMX and MBeans are technologies to aid server development. As such they have little effect on other developers. However, there are good reasons why you might create your own managed beans. Let's look first at server customization and startup classes.
Each application server provides a different, proprietary interface for adding custom classes to it. Sometimes called "startup" classes, they can be used to perform tasks on the server not directly supported by the J2EE model: initialization of resources; adding maintenance or monitoring functionality; invoking and scheduling batch operations. The problem with server classes is they all use a proprietary interface to attach themselves to the server's startup sequence, which ties your application directly to the vendor's J2EE implementation. Your application is coupled with the server components and startup classes, and you have lost J2EE's portable components benefit. Changing your application server has become more expensive and more difficult.
The JMX architecture offers a clean solution to this problem. Since the MBean server and registry is defined by the JMX specification, any compliant MBean is able to plug in to any compliant MBean server. Now an application server, which implements JMX, a standard extensibility interface. Since MBeans are portable, JMX-enabled application servers greatly increase your application's portability. You longer need to rely on proprietary server interfaces.
Another JMX-based server benefit is the management of custom components at runtime, which means taking advantage of generic administration tools, including those provided by your application server vendor. You don't have to drown in a constantly expanding pool of unmanageable property files.
Consider an application that must collect summary information from a database and send it to a predetermined e-mail address once a day. Since the J2EE model does not define a timer, and does not allow components to manage system resources such as threads, a programmer must include this functionality in custom classes which are attached to the server. To make sure the application is still portable, the programmer creates an MBean for the task, using the JMX MBean server to plug the component in.
The standard MBean exposes manageable attributes and operations. In our example there could be an operation for setting the summary collection and e-mail notification interval to some value. By exposing this operation in the MBean's interface the developer has made it possible for the administrator to change the interval setting at run-time. There's no need to edit cumbersome, difficult property files, nor is there a need to restart the server for the changes to take effect.
The attributes and operations of standard MBeans have similar naming convention to JavaBeans, facilitating the development of generic administrative interfaces, Each exposed attribute and operation can be displayed and invoked by the administrator via a web browser, for example. The JMX reference implementation provided by Sun includes exactly such a web client interface. As you add new custom components to your server, as it contines to run, they become automatically available in the client interface, as long as the developer of the MBean exposes the operations and attributes used for management. This is a very powerful feature.
Work is currently under way to define a standard model for J2EE management in the Sun Community Process (JSR77). One of the objectives of the expert group is to enable a single management tool to manage multiple vendor implementations of the J2EE platform. JMX is one way to fill that requirement.
The J2EE platform is based on services. Many APIs in the J2EE realm are adaptations of CORBA services. It seems natural to integrate and manage all of a platform's services within a JMX server. For example, if you need fast container response times or small footprints in an embedded application, you can install non-passivating caches or switch the persistence engine. If you need in an ASP app to configure the containers on demand, based on the client login and the application they are using, you can do this by using the m-let dynamic component loading service.
Most commercial developers face the daunting task of developing and integrating all the pieces of J2EE. Some servers, like WebLogic, do so in a monolithic way. JBoss, an open source server, has taken a different approach and is integrating different modules as JMX MBeans in the server. It thus becomes easy to assemble a J2EE in a mix-and-match style by bringing together independent modules. JBoss' development as a platform is harnessed with JMX semantics and provides the full J2EE platform via JMX integration. MBeans wrap the most common J2EE services: Servlet, JSP, EJB, O/R, Naming, JTS/JTA, JMS, SOAP and other 3rd party modules.
Instead of restricting the use of JMX to management only, JBoss uses JMX as a means to provide automated open source integration. By being fully modular, JBoss pioneers the next generation JMX architectures of the J2EE servers. For other vendors to achieve the same ease of use and dynamic configurability, they will need to follow suit as JMX is more than just a management interface. It is a natural architecture for service-based frameworks and the only way to cleanly manage the different parts of it both at run-time and in development.
Modularity in open source is not just a good idea. Modularity is the only way a project can mature. Successful open source projects are usually measured by the number of people that participate in the development. It is common for very successful teams to have a tightly knit core team of developers working on core functionality, but the key to growing the codebase is to enable lots of of developers to work on modules around the core.
JBoss 1.0 near completion when the core developers came to a simple conclusion: it was too hard for the casual developer to come in and contribute over the course of a week. One would have to spend at least a week to understand the code before making any contribution. The situation was typical of second generation open source projects: lots of people wanted to participate but very few could actually do so.
For the third iteration, JBoss embraced JMX. Within a week, an alternate SOAP-based invocation layer was submitted to the JBoss group. Modularity is needed for open source development and management. JMX is a natural way to enforce modularity in a design. The increased productivity and the ease of component integration to the server has made JBoss and JMX a success.
Marc Fleury , Ph.D., is CEO of JBossGroup, LLC. and founder of the JBoss open-source project.
Juha Lindfors is a computer scientist at the University of Helsinki.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.