Enabling Component Architectures with JMX
by Marc Fleury
and Juha Lindfors
02/01/2001
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.
Why JMX is important for Enterprise Java developers
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.
Ease of use for administrators
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 benefits of modular server architecture
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 increases open source productivity
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.
