Java Management Extensions:
http://javaboutique.internet.com/tutorials/JavaManagementExtensions/
Introduction:
Imagine a system that has pluggable modules included into it, that you could expand on as needed. Add to that the capability of integrating seamlessly with existing applications and leveraging on their power. All the ideas above and much more form the gist of what JMX or Java Management Extensions wishes to bring to the Java world.
In technical terms the Java Management Extensions provides an architecture and API for application management and network management using the Java programming language. It allows Integrators to integrate independent Java agent modules into existing systems.
Architecture
The two most important components of the JMX specifications are the Instrument Level and the Agent Level. The instrumentation level is a specification that defines the implementation of JMX manageable resources. A JMX manageable resource can be an application, a service or a device. The only condition is that the resource needs to be written in Java or should have a Java wrapper. It also should have been instrumented so that it can be managed by JMX complaint applications. The instrumentation is provided by Managed beans or MBeans. The instrumentation layer creates resources so that they can be managed by Management agents. The MBeans are designed to be generic, flexible and easy to implement. They do not require the user to know the JMX agents they would operate on. Apart from these, the instrumentation specification provides a mechanism to notify events, this allows MBeans to generate and notify other components of events.
The agent level defines the specification for implementing Management agents. Management agents or MBeans control the resources and make them available to the other applications. This level acts as an interface to the instrumentation layer by providing a standardized agent to manage the JMX resources. An agent consists of an MBean server and a set of services to handle MBeans. JMX agents provide the infrastructure and API for developers to use MBeans or resources provided by the MBean server. They need not know about the internal implementation of these resources or MBeans. The instrumentation specification and the agent specification are discussed in more detail below.
Instrumentation Layer:
The main components of the instrumentation layer are the MBeans, the Notification model and the MBean metadata classes.
MBeans: An MBean is a concrete Java class that includes the implementation of its own MBean interface or an implementation of the DynamicMBean interface. It can also optionally implement the NotificationBroadcaster interface.
A class that implements its own MBean interface is referred to as a standard MBean. This is the simplest type of instrumentation available when developing new JMX manageable resources. An MBean that implements the DynamicMBean interface is known as a dynamic MBean, because certain elements of its instrumentation can be controlled at runtime. The type of MBean determines how the MBean is deployed on the MBean Server but it has no effect on how the bean is managed. JMX agents are designed to shield the type of MBean and provide a standard interface. The end user is transparent to the type of bean.
A standard MBean consists of attributes and operations. The attributes can be accessed using getter and setter methods. The operations are static methods in the MBean interface and are visible to JMX agents using introspection. The Dynamic MBean allows manipulations on its methods through generic invocation methods. The method could take the name of the attribute or the operation as a parameter.
Notification Model: Usually management applications need to react to state changes or to specific conditions when they occur in an underlying resource. The Notification Model defines a model that allows MBeans to broadcast such management events, called notifications. Management applications and other objects register as listeners with the broadcaster MBean. The MBean Notification Model of JMX enables a listener to register only once and still receive all the different events that might occur in the broadcaster.
The JMX Notification Model uses a generic class called Notification to define an event type. This class may be sub- classed to represent specific types of events. The generic event type allows a single listener to receive numerous notifications from different types of notification types. Objects desiring to receive notifications sent by MBeans must implement the NotificationListener interface. MBeans that want to broadcast notifications have to implement the NotificationBroadcaster interface, so that it can allow listeners to register themselves with the MBean to receive notifications. Any type of MBean, standard or dynamic, can be either a notification broadcaster, a notification listener, or both at the same time.
MBean Metadata Classes: The MBean metadata defines the classes that describe an MBean. These classes are used both for the introspection of standard MBeans and for the self description of all dynamic MBeans. These classes describe the management interface of an MBean in terms of its attributes, operations, constructors and notifications. The JMX agent exposes all its MBeans, regardless of their type, through the MBean metadata classes. All clients, whether management applications or other local MBeans viewing the management interface of an MBean, need to be able to interpret these objects and their constructs.
Important MBean Metadata classes are described below:
MBeanInfo class: This class is used to fully describe an MBean: its attributes, operations, constructors, and the notification types it can send. It describes the MBean's overall purpose or functionality.
MBeanFeatureinfo class: This class is the parent of all the other component metadata classes. It contains two methods getName() and getDescription() which return the name and a readable string description of the component.
MBeanAttributeInfo class: The MBeanAttributeInfo class describes an attribute in the MBean's management interface. An attribute is characterized by its type and how it is accessed. This type of an attribute is the Java class that is used to represent it when calling its getter or setter methods. The getType() method returns a string containing the fully qualified name of this class.
MBeanOperationInfo class: The MBeanOperationInfo class describes an individual operation of an MBean. An operation is defined by its signature, return type, and its impact.
MBeanParameterInfo class: The MBeanParameterInfo class is used to describe a parameter of an operation or a constructor.
MBeanNotificationInfo class: The MBeanNotificationInfo class is used to describe the notifications that are sent by an MBean. The getNotifTypes method returns an array of strings containing the notification types that the MBean can emit.
Agent Layer:
A JMX agent is a management entity that runs in a Java Virtual Machine (JVM) and acts as the bridge between the MBeans and the management application. A JMX agent is composed of an MBean server, a set of MBeans representing managed resources, a minimum number of agent services implemented as MBeans, and typically at least one protocol adaptor or connector.
The key components in the JMX agent architecture can be further defined as follows: The MBean server and Agent services can either be components defined in this specification or services developed by third parties.
The agent service MBeans defined by the JMX specification further provide dynamic loading services that allow the agent to instantiate MBeans using Java classes and native libraries dynamically downloaded from the network. These include monitoring capabilities for attribute values in MBeans, a timer service that can send notifications at predetermined intervals and act as a scheduler, and a relation service that defines associations between MBeans and maintains the consistency of the relation
MBean Server: The Managed Bean server, or MBean server is the core component of the Java Management Extensions (JMX) agent infrastructure. The MBean server is a registry for MBeans in the agent. The MBean server is the component that provides the services for manipulating MBeans. All management operations performed on the MBeans are done through the MBeanServer interface.
In general the MBean server registers MBeans that represent resources used for management purposes or Mbeans that add management functionality to the agent. Some components of the infrastructure, such as the connector clients and protocol adaptors, can be implemented as MBeans. This allows such components to benefit from the dynamic management infrastructure.
A JMX agent has a factory class for finding or creating an MBean server through the factory's static methods. This allows more flexible agent applications and possibly more than one MBean server in an agent.
MBeans can be registered either by the agent application, or by other MBeans. The interface of the MBeanServer class allows two different kinds of registration. The first one is the instantiation of a new MBean and registration of this MBean in a single operation. The second is the registration of an already existing MBean instance.
Agent Services:
Advanced Dynamic Loading: Dynamic loading is usually performed by the management applet (m-let) service that is used to instantiate MBeans. These MBeans are obtained from a remote URL on the network. The Java Management Extensions (JMX) specification also defines lower-level mechanisms for class loading. These allow developers to extend the functionality of the m-let service or to load classes without it.
The m-let service allows you to instantiate and register one or more MBeans from a remote URL, in the MBean server. The m-let service does this by loading an m-let text file, that specifies information on the MBeans to be obtained. The information on each MBean is specified in a tag similar to those used in XML, called the MLET tag. The location of the m-let text file is specified by a URL. When an m-let text file is loaded, all classes specified in MLET tags are downloaded, and an instance of each MBean specified in the file is created and registered.
The m-let service is itself implemented as an MBean and registered in the MBean server. This way it can be used by other MBeans, by the agent application, or by remote management applications.
Monitoring :
The JMX specification allows using a monitoring service to monitor the observed attribute of one or more other MBeans at intervals specified by the granularity period. For each observed MBean, the monitor derives a value from this observation, called the derived gauge. This derived gauge is either the exact value of the observed attribute, or optionally, the difference between two consecutive observed values of a numeric attribute.
A specific notification type is sent by each of the monitoring services when the value of the derived gauge satisfies one of a set of conditions. The conditions are specified when the monitor is initialized, or dynamically through the monitor MBean's management interface. Monitors can also send notifications when certain error cases are encountered while monitoring an attribute value.
Timer Service:
The timer service triggers notifications at specific dates and times. It can also trigger notifications repeatedly at a constant interval. The notifications are sent to all objects registered to receive notifications emitted by the timer. The timer service is an MBean that can be managed, allowing applications to set up a configurable scheduler.
Conceptually, the Timer class manages a list of dated notifications that are sent when their date and time arrives. Methods of this class are provided to add and remove notifications from the list. In fact, the notification type is provided by the user, along with the date and optionally a period and the number of repetitions. The timer service always sends the notification instances of its specific TimerNotification class.
Relation Service:
As part of the agent specification, the Java Management Extensions (JMX) specification also defines a model for relations between MBeans. A relation is a user defined, n-ary association between MBeans in named roles. The JMX specification defines the classes that are used to construct an object representing a relation. It also defines the relation service that centralizes all operations on relations in an agent. All relations are defined by a relation type that provides information about the roles it contains, such as their multiplicity, and the class name of MBeans that satisfy the role. Through the relation service, users create new types and then create, update, or remove relations that satisfy these types. The relation service also performs queries among all relations to find related MBeans.
The relation service maintains the consistency of relations, checking all operations and all MBean deregistrations to ensure that a relation always conforms to its relation type. If a relation is no longer valid, it is removed from the relation service, though its member MBeans continue to exist otherwise.
Conclusion
Most application servers in the market today either implement the JMX specification or have them on their agenda. However the specification has not been in popular use. It might take some time for the developer community to embrace JMX and use them for real time applications. This article should have introduced the reader to the basic concept of JMX and the important aspects of it. For more information please refer to the JMX 1.2 Specification found on the Java site and the accompanying reference implementation.
References:
The JMX Specification
No comments:
Post a Comment