Java Management Extensions (JMX) Motivation & API Survey S V Ramu (2002-02-24, 2002-03-07)
 What is JMX?
JMX, Java Management Extension, is an API (set of commonly accepted Classes and Interfaces) for managing. Managing what? The idea is to manage any devices or applications, which has a wrapper conforming to the specification as defined in JMX standard. In much simpler terms, if you want something (any device or application) to be managed in the JMX model, you have to implement few interfaces, or follow some JavaBean like naming patterns. After this you might be registering it with some JMX implementations. Then, you can write an application which can query the JMX Server (or some such thing) and talk to it in a standard way. But how can you control different devices and applications with a just one api? Won't each device have their own controls, indicators, and signals? The JMX model
A device is a nice simile for a JMX enabled resource. Of course even an application could be one (JBoss is the foremost example). A managed resource is provided an interface by JMX. All resources to be managed are abstracted as Attributes (indicators? maybe a modifiable indicator), Operations (Controls), Notifications (output signals), and some Descriptors. Also Constructors. In a sense, JMX is just a glorified and abstracted Reflection. Where Attributes are like Variables, Operations are like Methods/Procedures, Notifications are like Events, and Descriptors are just Name-Value pairs. The resource that is willing to be managed, exposes a set of Attributes, Operations and Notifications, to a central server, and thus being transparent to the managing applications, otherwise. Though much of the JMX API is concentrating on the reflection-like part alone, some other parts are concerned with abstracting variables which perform the activities like counters, gauges (analog-ish), and Strings comparators. Apart from this, there are classes for time (or period) triggers, and for specifying the relation between various management adapters. The MBean
The MBean is the central concept for this whole api, although there is no class or
Interface called MBean as such. Any class that we write (say, MyClass), implementing an
interface (MyClassMBean), either with same name suffixed with
...Concepts and classes of open MBeans presented in this
chapter are still subject to change.
Hence, compliance to open MBeans is not required, and in fact, compliance to open
MBeans is impossible to claim in this phase of the specification. Open MBeans are
intended to be fully defined and to become mandatory in the next release.
The Glorified Reflection
In a way JMX treats any MBean (just a special wrapper class for a thing we want to measure) as having Attributes, performing some Operations and emitting some Notifications. This in a way is a form of reflection. In fact, the Standard MBean is identified purely by reflection. The term used for this process of finding whether a class is Standard MBean, or DynamicMBean, or Open MBean or a Model MBean is (poetically) called as Introspection. So, JMX introspects using reflection!
How would you define an Attribute of a MBean? Ask, what is a Attribute for a class
(because a MBean is a class). The JavaBean model lends a hand here, and hence, any JavaBean
style getter and setter together constitute an Attribute (hence you can imagine read-only
or write only attributes). Of course one more condition is that, these methods should be there in
the
By including the operation signature, the dynamic MBean implementation may verify that the
mapping is consistent between the requested operation and that which is exposed.
It seems that this is an attempt to offset the non-availability of type checking due to
this highly flexible definition of a Java method. As always, type checking is the cost we pay
for abstraction and flexibility that we get. But does this requirement of having signature
(the class type) needed? I doubt it, because the rising of Exception for mismatch of
parameters is anyway done by the actual invocation. (Any special situation in question?
Oh yeah! How else the server can resolve between two operations with the same name but
different signatures, in case of overloaded methods? No! even then, the number of params
and their types known by reflection, can do the job; so we don't need signature?).
Notification, in the spirit of the Swing event model, is realized through Listeners.
A MBean is considered to have Notifications, if and only if it implements the
Any type of MBean may implement the NotificationBroadcaster interface.
This may lead to a special case of a standard MBean, which has an empty
management interface: its role as a manageable resource is to be a broadcaster of
notifications. It must be a concrete class with a public constructor, and it must
implement an MBean interface, which in this case defines no methods. The only
methods in its class are those implementing the NotificationBroadcaster
interface. This MBean may be registered in a JMX agent, and its management
interface only contains the list of notifications that it may send.
Notification uses a partial Memento (GoF) pattern, to aid in the proper resolution of
the
An opaque handback object to be sent back to the listener when a notification is
emitted. This object cannot be used by the Notification broadcaster object. It should be
resent unchanged with the notification to the listener.
void handleNotification(Notification notification, Object handback)
An opaque object which helps the listener to associate information regarding the MBean
emitter. This object is passed to the MBean during the addListener call and resent, without
modification, to the listener. The MBean object should not use or modify the object.
I call this partial Memento in the sense that the Broadcaster (Caretaker) is not at all
using the handback (Memento) in any form whatsoever, but to keep it as an opaque object to
be given back.
Apart from AON, we also have constructors, which completes the correspondence of an MBean with any class.
An MBean may have any number of constructors, provided at least one is declared
public, in order to allow an agent to do an instantiation. An MBean may also have
any number of public constructors, all of which are available to a management
application through a JMX agent which can instantiate this MBean class.
For now, there are 6 packages (few more are on cards for the next release). The classes and
interfaces follow a highly OOed design, where anything and everything is an object.
16 Interfaces, 35 Classes and 16 Exceptions.
Have ever wondered of using extreme OO where you express even the smallest thing as a class?
How about expressions like say, ( Epilogue
For the fear of being a photo copy of the well-written specs, I'm only giving my views and understanding of the API, along with some interesting or crucial snippets from the original. The key goal is to wear the hat of the JMX designers, and thus provide the motivations behind the classes and methods. For all useful details, you have to consult the pdf spec and the accompanying html javadocs. Of course, if my experience is any indicator, thinking in the above lines will help you in fully appreciating the meticulous wordings of the spec itself. While studying the specs, do remember few terminologies,
As far a I have seen, the spec is really very lean in its content, and hence highly recommended for any distributed nexus between any two modules of an application, like in JBoss,
Our goal is to provide the full J2EE stack in the free/open world. We are already there
and the reason for our success lies on JMX. JMX or Java Management eXtension is the best
weapon we have found for integration of software. It provides a common spine in which we
plug in modules, containers and plugins (JTS/JTA, Security, Data Sources, Remote
Management, EJB, DBs, JSP and JMS).
While we provide JBoss implementations for many of these services you are free to include
your favorite implementation in the JMX enabled base and therefore "dropping" your own
transaction or persistence service in JBoss, all dynamically. Marc Fluery of JBoss has rightly pointed out that,
Then we really surprised the industry when we introduced Java Management eXtensions (JMX)
as the base of our servers. Others, mostly BEA, have been quick to adopt this SUN standard
but not as profoundly and un-conventionally as we did. They use it, for "management;" we
use it as the standard base for our modularity and a clear, clean way to load, startup,
configure and also manage all of our server. We introduced this a year and a half ago, in
early 2000, and the rest of the industry is still scratching their heads to figure out what
this really means. Some follow suit, (BEA/IBM), others just give up. But we keep on trail
blazing tech-wise.
References
|
 | |
|
|