- Application Management
- Java Management Extensions (JMX)
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Java Management Extensions (JMX)
JMX has become a standard for managing java resources. It exposes the application's management information, and management systems can use JMX APIs to generate analysis reports based on this information. JMX enables applications to be monitored and controlled while shielding the application from management protocols.
The architecture that JMX follows is a variation of the architectural pattern called Manager-Agent. The basic components of this architectural pattern are the managed resource, agent, and management system. A managed resource is the application that needs to be managed by exposing appropriate data for use by a management system. For example, if a remote call takes more than five seconds to execute, which is beyond the acceptable limits of performance, the managed application can trigger a notification using JMX. The management system can then interpret it and send a pager message to the appropriate party about the event. A management Agent communicates both with the management system and the application. The Agent is responsible for sending events to the management system and executing commands from the management system onto the application. The management system is responsible for providing the infrastructure to mange the applications. HP OpenView is an example of a management system.
Figure 1 shows the relationship between components of JMX Architecture from Sun Microsystem's JMX 1.2 specification.
)
Figure
1 Relationship between components of JMX from Sun Microsystems' JMX 1.2
specification
The important layers of the JMX architecture are as follows (described in the following sections):
Instrumentation Level
Agent Level
Distributed Services Level
Instrumentation Layer
The Instrumentation Layer provides the specification for implementing manageable resources by any arbitrary management system. Resources that conform to this level are called manageable resources. JMX managed resources are provided by Managed Beans (MBeans). Instrumentation Layer components are shown in Figure 2.
)
Figure
2 Instrumentation Layer components.
The components of the instrumentation layer are
Managed Beans
Notification Model
MBean Metadata Classes
Each of these components is briefly described below.
Managed Beans (MBeans)
JMX-enabled managed resources are provided by MBeans. MBeans come in four flavors: Standard Mbeans, Dynamic Mbeans, Open Mbeans, and Model Mbeans.
Standard MBeans
A Standard MBean explicitly defines its management interface following a lexical design pattern (in other words, a naming convention). The lexical design patterns are used to distinguish MBean attributes from MBean operations. For example, an attribute is identified by the following pattern:
//Attribute Getter
public AttributeType getAttributeName() {...}
//Attribute Setter
public void setAttributeName(AttributeType someValue){...}
The AttributeType is any Java Type and AttributeName is case-sensitive. If only a getter for an attribute is present, it implies that the attribute is read-only; if only a setter is present, it implies that the attribute is write-only. If both a getter and setter are present for an attribute, it is read and write. If the AttributeType is Boolean, the read-only (that is, getter) can be defined as follows:
public boolean isAttributeName(){..}
OR
public boolean getAttributeName() {..}
Note that one form of read-only is allowed for a Boolean attribute, not both.
The management interface contains the attributes that are exposed through getters and setters, public only constructors, operations, and notification objects that the MBean broadcasts. Operations are those methods defined in the MBean interface that do not match any of the attribute design patterns. Using Standard MBeans is the quickest and easiest way to build instrumentation for manageable resources, and is best-suited when the management information that needs to be exposed is well-defined and unlikely to change over time.
This series presents an example scenario of collecting application metrics in real-time using the Standard MBeans for exposing the management information. The use case is this: A management system records the application performance metrics that is the hostname of the server hosting the application and the response time of a method in an application. This data would be displayed in OpenView Performance Manager/OpenView Performance Insight (OVPM/OVPI). As a developer, you would develop a management interface and write User-Defined Metrics (UDM). A UDM is an XML configuration file that defines the JMX MBeans that will be collected by OVPM. The next article will discuss what is needed to integrate WebLogic Application Server with Hp OVPM. The same steps are applicable to integrating with OVPI. For now, the following is the code for the MBean interface and the standard MBean that will be deployed in WebLogic Application Server.
//The management interface
public interface PerformanceMetricsMBean {
/**
* Return the name of the server hosting the JVM that this MBean is deployed in.
* @return the local host name
*/
public String getHostName();
/**
* Return the measured response time
* @return the measured response time
*/
public String getResponseTime();
}
//The MBean Class
public class PerformanceMetrics implements PerformanceMetricsMBean {
private String hostName;
private String responseTime;
public String getHostName() {
return hostName;
}
public String getResponseTime() {
return responseTime;
}
public void setHostName(String value){
hostName = value;
}
public void setResponseTime(String value){
responseTime = value;
}
}
The MBean developed above is registered with the MBean Server using a startup servlet.
The following sections give a brief overview of other types of MBeans, but do not have the same detailed overview as that furnished for Standard MBeans. Refer to the References section at the end of this article to learn more.
Dynamic MBeans
When resources are likely to change often over time, Dynamic MBeans are recommended over Standard MBeans because they provide flexibility such as being dynamically determined at runtime.
Dynamic MBeans are resources that are instrumented through a predefined interface that exposes the attributes and operations only at runtime.
Following the JMX 1.2 specification, a Dynamic MBean should implement the interface javax.management.DynamicMBean. The DynamicMBean interface exposes the management information of a resource by using a javax.managemen.MBeanInfo class. The MBeanInfo class describes the set of attributes exposed and operations that can be performed on the managed resource.
Open MBeans
Open MBeans are dynamic MBeans with restricted data types for their attributes, constructors, and operations to Java primitive types. Using these limited basic types enables serialization, and removes the need for class loading and proxy coordination between the MBeanServer and users of the MBeans.
Model MBeans
A model MBean is a fully customizable dynamic MBean. The Model MBean is defined by javax.management.modelmbean.RequiredModelMBean. The RequiredModelMBean class, which implements the ModelMBean interface, is guaranteed to exist on every JMX Agent. A model MBean implements the ModelMBean interface that extends other interfaces, including DynamicMBean, PersistentMBean, and ModelMBeanNotificationBroadcaster.
Notification Model
The JMX Notification Model, which is based on the Java Event Model, lets your MBeans speak to other objects, applications, and other MBean instances. An MBean can send a notification by implementing the JMX NotificationBroadcaster interface, and an MBean can receive notifications by implementing the JMX NotificationListener interface (it must register for notifications). The current version of the JMX specification leaves the process of how the distribution of the notification model is achieved to a future version of the JMX specification.
MBean Metadata Classes
The MBean Metadata classes are used to describe the management interface of an MBean. The metadata classes contain the structures to the attributes, operations, notifications, and constructors of a managed resource. For each of these, the metadata includes a name, a description, and particular characteristics. The different types of Mbeans extend the metadata classes to provide additional information. These classes are used both for the introspection of standard MBeans and for the self-description of all dynamic MBeans.
Agent Level
The Agent Level provides management Agents to control the managed resources exposed by the application. An Agent can run on the same server that hosts the application or on a remote server. A JMX Agent is composed of an MBean Server, a set of MBeans representing the managed resources, agent services implemented as MBeans, and at least one protocol adaptor or connector.
The MBean Server, the core component of the Agent Layer, allows for MBean registration and manipulation. Agent Services are objects (usually Mbeans) that allow themselves to be controlled through the MbeanServer. The Agent Service MBeans provide the following:
Dynamic class loading that allows retrieval and instantiation of new classes from an arbitrary location on the network called an m-let service. The m-let service does this by loading an m-let text file that specifies information on the MBeans needed. The information on each MBean is specified using a tag called an MLET tag. The location of the m-let text file is specified by a URL; when loaded, all the classes specified in MLET tags are downloaded, and an instance of each MBean is created and registered.
Monitors watch for changes on a target's attributes and can notify about other objects of interest.
The Timer Service provides a mechanism to emit user-defined notifications at specific times.
The Relation Service defines n-ary associations between MBeans based on predefined relation types.
Connectors and Protocol Adapters make the Agent accessible from remote management systems. Connectors are used to connect an Agent with a JMX-enabled management application. A Protocol Adaptor provides a management view of the JMX Agent through a given protocol. The JMX reference implementation comes with an HTTP adaptor.
Figure 3 depicts the HTML adaptor view, showing the registration of the PerfomanceMetrics MBean developed for this article.
)
Figure
3 HTML adaptor view.
Distributed Services Layer
The Distributed Services Layer provides the interfaces for implementing JMX managers. (JMX Specification 1.2 leaves the detailed definition of the Distributed Services Layer to a future version of the JMX specification.) This level defines management interfaces and components that can operate on Agents or hierarchies of Agents. These components can
Provide security.
Provide transparent interaction between an Agent and manageable resources through a connector.
Provide the distribution of management information from management platforms to JMX Agents.
Provide a management view of a JMX Agent and the MBeans registered in the MBean Server by using Hypertext Mark-Up Language (HTML) or Simple Network Management Protocol (SNMP).
Provide logical views by gathering management information from JMX Agents.
Management components interact with one another across the network to provide distributed scalable management capabilities. These components can be used to deploy a management application with customized Java-based management capabilities.