(thing) by elluzion Mon Apr 01 2002 at 21:10:12

Java Management Extensions (JMX) is an API released by SUN Microsystems for the Java Programming Language. This API allows for the management of resources such as other applications, networks, server, etc. Anything that can be accessed through Java code is a candidate for management.

This particular writeup will focus on the lowest level of the API. Perhaps some day I'll get around to writing one for the other levels. Or, maybe some other kind soul will do it. This writeup is the result of an assignment at work. I was asked to evaluate JMX and prepare a presentation on its capabilities. The goal of the writeup is to provide enough detail to adequately inform while witholding enough detail as to not overwhelm.

Lets get some vocabulary established first.

Management Application: An application that will utilize some sort of software tool in order to manage or monitor resources.

Managed Resource: Something that is being managed or monitored. Commonly, other applications, database connections, servers, network user accounts, anything you might want to keep track of.

Metadata: Data about data. Its kind of confusing at first, but Metadata is basically data that describes other data. Ever used COBOL? Sorry to bring up painful memories, but you remember doing the data definitions? Where you would tell the name of a variable (were they even variables?) and then you would give the expected data type, the length, leading characters, leading/trailing zeros, etc. This was all data that provided a context for other data. Metadata.

The Developer: Thats you! Or me, or anyone who is writing the code to utilize JMX.

MBean: Managed Bean. Explained below

setter/getter: You're kidding right? You don't know what these are? Go read about javabeans.

Introspection: Sort of a Java state of Zen. If you are unfamiliar with this, go read here. Damn. That has nothing to do with the topic at hand. *sigh* oh well, another future writeup, I suppose. Try Google for the time being.

Any other words in this writeup you are not familiar with? /msg me. I'll explain them here.

And now, on to the information!

JMX Architecture

The JMX architecture is implemented in 3 levels

The Instrumentation level is the lowest level. Providing information about, and access to managed resources.

The Agent level contains services available to management applications as well as a connection architecture to facilitate communication with the instrumentation objects.

The Management level is not actually specified by JMX yet. It contains the applications that actually access the agent level in order to gain information from the managed resources. Design patterns and best practices for the development of this level are up to the developer.

Instrumentation level:

This level contains MBean objects, which represent entities in the real world, be they other Java objects, applications, servers, etc. Anything that can be accessed or measured by Java code, or modeled by a Java object is a candidate for JMX instrumentation.

Criteria to be an MBean: -Must be a concrete java object. No abstract classes, interfaces or objects with package-level scope -Must have at least one public constructor -Must implement its own MBean interface, or implement DynamicMBean interface -Can implement NotificationListener interface

Standard MBeans:

These MBeans are best for completed, unchanging systems. Their interfaces are "set in stone" and cannot change without significant recompiling of management applications and supporting classes.

A Standard MBean Implements an interface of setters and getters to control its attributes. This interface will also define operation methods in the MBean. These Mbeans are designed with introspection in mind.

There are some rules to follow when writing a Standard MBEan and its interface:

  • The interface name is + "MBean"
    • ex: java class MyClass would implement MyClassMBean
  • The interface may list methods inherited from an MBean superclass.
  • A Standard MBean may inherit management interface from superclass. Or, may implement a new management interface to redefine its management scheme
  • If an MBean defines its own management interface, its superclasses interface is ignored. However, its management interface can inherit from the superclasses management interface.
  • Use standard JavaBean introspection rules for getter/setter methods and attribute names.

Dynamic MBeans:

Dynamic MBeans are another breed of MBean. They are best for incomplete, or evolving systems. These MBeans implement the DynamicMBean interface.

Dynamic MBeans do not expose methods and attributes until runtime. The DynamicMBean interface contains methods that return the information about the object. These methods are used to set and get attributes and invoke the MBean utility methods. This allows the java classes being instrumented to evolve without affecting their management framework.

Dynamic MBeans avoid introspection through the use of MBean metadata classes. The getMBeanInfo() method in the DynamicMBean interface is used to communicate this metadata to a management application or human reader.

The getMBeanInfo() method returns an instance of the MBeanInfo object. This object contains arrays of other descriptive metadata objects, which describe the attributes, operations, constructors and notifications of the MBean. All of this metadata is created in and returned by the dynamic MBean's getMBeanInfo() method, by the developer. It is the developer's responsibility to ensure this metadata accurately describes the MBean. If the metadata is incorrect, the dynamic MBean will not function properly.

Notification

MBeans may register with a notification service in order to broadcast state changes or other meaningful events. Management applications register as listeners to the same service in order to receive these notifications. Through this framework, management applications may implement complex schemes and retain very low-level information about activity within the managed system.

Currently JMX notifications may only be communicated between elements of a single JMX agent. Future specifications will implement functionality for inter-agent transmission of notifications.

Also, all objects registered to the notification service will receive all notifications sent through that service. Only one registration is required in order to receive all notifications.

The notification framework is composed of the following

  • Notification object: May be used directly, or subclassed to provide more detailed information as to the nature of the notification.
  • NotificationBroadcaster interface: MBeans implement this interface in order to communicate notification events to its registered listeners.
  • NotificationListener interface: Implemented by objects, which have a need to be aware of notification events.
  • NotificationFilter interface: This interface allows objects to filter the types of notification that are accepted. Since a registered listener will be alerted for every notification coming through the notification service, this object is useful in specifying which notifications are important to a given object.

There is a predefined Notification subclass AttributeChangeNotification. This class can be used for communicating the change of MBean attributes. In addition to this class, there is a predefined object named AttributeChangeNotificationFilter. This object implements the NotificationFilter interface and is used to filter specific AttributeChangeNotification objects.

Open MBeans

The Open MBean concept has not yet been fully specified and is not yet fully integrated into the JMX architecture. These ideas are subject to change in the future and it is not suggested to integrate Open MBeans into management systems yet.

The idea behind Open MBeans is a mechanism that will allow the use of new MBeans that are discovered at runtime without the need for recompiling or re-linking the management application or supporting objects. Also, Open MBeans should be easily understood through their metadata, a human reader should need no documentation to use and understand them.

An Open MBean will be an MBean that conforms to the following rules:

  • The MBean will be a dynamic MBean
  • The MBean may only use data types from a specific list of allowed data types.
  • The MBean will implement special metadata objects, subclasses of normal MBean metadata objects, which are more descriptive than normal dynamic MBean metadata.
  • All metadata objects must be used and populated with meaningful data. No empty strings allowed.

The allowed Open MBean data types are:

  • java.lang.Void
  • java.lang.Boolean
  • java.lang.Byte
  • java.lang.Character
  • java.lang.String
  • java.lang.Short
  • java.lang.Integer
  • java.lang.Long
  • java.lang.Float
  • java.lang.Double
  • javax.management.Objectname
  • interface javax.management.openmbean.CompositeData
  • interface javax.management.openmbean.TabularData
As with regular Dynamic MBeans, it is the developer's responsibility to ensure the metadata is correct.

Model MBeans

(NOTE: Damn it took me a while to understand why these things are useful)

A Model MBean is another type of Dynamic MBean. Through the ModelMBean interface, an MBean may be instantiated as a façade for accessing other MBeans. This MBean provides additional services not normally available with MBeans. Such services include caching, relocation, persistence and XML access configuration.

Every JMX agent instance is required to contain at least one Model MBean. This MBean must be an instance of javax.management.modelmbean.RequiredModelMBean. This class is used as the default model for management behavior.

A Model MBean is able to implement any services available in its VM. When used to access other MBeans, the Model MBean essentially extends the services of its virtual machine to its target MBean. For instance, an MBean existing in a J2ME VM can be persisted by being the target of a Model MBean in a J2EE VM. Since the J2ME VM does not support persistence, the J2ME MBean gains the service of persistence through the J2EE MBean.

In addition, Model MBeans can be used to configure policies for how MBeans should be treated at runtime. For instance, you might want to do extensive logging while testing an MBean, but do less logging and offer persistence for MBeans after testing is done. You could accomplish this by creating one Model MBean for testing, and another for production use. The testing MBean would define behavior for MBeans that are being tested, and would be used to load those MBeans. After the testing, you would use a different Model MBean in production applications, which would specify a different set of behavior policies for MBeans in a production environment.

The following behavior policies can be defined through Model MBeans:

  • Notification Logging: Assuming the JMX agent supports notification logging, the Model MBean notification level overrides the individual MBean notification level. The notifications are logged to a file specified in the logfile field.
  • Persistence: If the JMX agent does not support persistence, an MBean may be serialized to a flat file. Otherwise, persistence can be based on time interval or attribute update notification.
  • Caching: Attribute value caching may be configured through the use of currencyTimeLimit and lastUpdatedTimeStamp attributes.
  • Protocol Mapping: Model MBean attributes may be mapped to legacy protocols though the use of the ProtocolMap field, which should specify an instance of an object that implements Descriptor and handles the mapping.
  • Export: Multiple JMX agent instances may be used. By specifying a name in the export field, an MBean instance may be made available through a directory or lookup service to any JMX agent that supports directory or lookup services.
  • Visibility: The visibility field may be set to any integer between 1 and 4. This level is used to define at which level the particular MBean is visible. The implementation of visibility levels is up to the developer. The JMX specification does not define their meanings.
  • Presentation: The presentation string is an XML string that is intended to provide hints to a console to aid in user interface development. This feature has not yet been standardized.

This concludes our tour of JMX instrumentation. Check back in the future where you may find such things as JMX Agent architecture or even JMX management applications. If you're really lucky, you might just find something about bea Weblogic JMX implementation, but dont hold your breath.

I like it!