Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

2.3.2 MBean Server Interceptors

As stated previously, the Java DMK does not require every MBean in a Java DMK agent to be represented by a Java object in that agent. MBean Server interceptors enable you to intercept operations on MBeans and handle them arbitrarily. Handling the operations can involve handing the request to other interceptors, possibly after logging or authenticating them for security. Alternatively, handling can involve processing the request directly. For example, with very volatile MBeans, direct handling avoids having to keep up with the creation and deletion of objects. Instead, the managed object is effectively synthesized when there is a request on it, which for volatile objects happens much less often than creation and deletion.


Note - In Java DMK version 5.1, it is necessary to use the new JdmkMBeanServerBuilder class to add interceptor functionality. This can be done by specifying a Java system property. See the Java Dynamic Management Kit 5.1 Tutorial for details.


2.3.3 Protocol Adaptors

Protocol adaptors have only a server component and provide a view of an agent and its MBeans through a different protocol. Protocol adaptors can also translate requests that are formulated in this protocol into management requests on the JMX agent. The view of the agent and the range of possible requests depends upon the given protocol.

For example, Java DMK provides an HTML adaptor that presents the agent and its MBeans as HTML pages that are viewable in any web browser. Because the HTML protocol is text based, only data types that have a string representation can be viewed through the HTML adaptor. However, this is sufficient to access most MBeans, view their attributes, and invoke their operations.

Due to limitations of the chosen protocol, adaptors have the following limitations.

  • Not all data types are necessarily supported

  • Not all management requests are necessarily supported, because some requests might rely on unsupported data types

  • Notifications from a broadcaster MBean might not be supported

  • A given protocol adaptor might require private data structures or helper MBeans for responding to requests

The SNMP adaptor provided in the Java DMK is limited by the constraints of SNMP. The richness of the JMX architecture cannot be translated into SNMP, but all the operations of SNMP can be imitated by methods of the MBean server. This translation requires a structure of MBeans that imitates the MIB. While an SNMP manager cannot access the full potential of the JMX agent, the MBeans representing the MIB are available for other managers to access and incorporate into their management systems.

In general, a protocol adaptor tries to map the elements of the JMX architecture into the structures provided by the given protocol. However, the completeness or accuracy of this mapping is not guaranteed.

2.4 The Notification Model

The JMX architecture defines a notification model that enables MBeans to broadcast notifications. Management applications and other objects register as listeners with the broadcaster MBean. In this way, MBeans can signal asynchronous events to any interested parties.

The JMX notification model enables a listener to register only once and still receive all the various notifications that an MBean can broadcast. A listener object can also register with any number of broadcasters, but it must then sort all notifications it receives according to their source.

2.4.1 Local Notification Listeners

In the simplest case, listeners are objects in the same application as the broadcaster MBean. The listener is registered by calling the addNotificationListener method on the MBean. The MBean server exposes the same method so that listeners can also be added to an MBean identified by its symbolic name.

In Figure 2-2, one listener has registered directly with the MBean and another has registered through the MBean server. The end result is the same, and both listeners receive the same notifications directly from the broadcaster MBean.

Figure 2-2 Adding Local Listeners on the Agent Side

Adding Local Listeners on the Agent Side

2.4.2 Remote Notification Listeners

The connector client interface also exposes the addNotificationListener method so that notifications can be received in remote management applications. Standard proxies expose this method as well and transmit any listener registrations through the connector client.

Listeners do not need to be aware that they are remote. The connector transmits registration requests and forwards notifications back to the listeners. The whole process is transparent to the listener and to the management components.

As shown in Figure 2-3, the connector components implement a complex mechanism for registering remote listeners and forwarding notifications. Because notifications are based on the Java event model, broadcasters cannot send notifications outside their Java virtual machine. So, the connector server instantiates local listeners that receive all notifications and places them in a cache buffer, to wait to be sent to the manager application. This enables the connector to avoid saturating the communication layer in case of a burst of notifications.

Figure 2-3 Adding Remote Listeners on the Manager Side

Adding Remote Listeners on the Manager Side

Notifications in the new RMI and JMXMP connectors are pulled periodically at the client's request. The pull mechanism is used to group notifications and reduce bandwidth usage. The connector client acts as a broadcaster and sends the notifications to their intended listeners.

Notifications in the legacy RMI and HTTP connectors are pulled in the same way as the new connectors. However, the legacy connector notifications can also can be pushed from the agent to the connector client as they are received.

2.5 Agent Services

To simplify the development of agents for network, system, application, and service management, the Java DMK supplies a set of agent services. These services are implemented as MBeans that perform some operations on the other MBeans in an agent. All the provided agent services are briefly explained in this section.

2.5.1 Querying and Filtering

Querying and filtering are performed by the MBean server, not by a separate MBean. This ensures that such critical services are always available. Queries and filters are performed in a single operation, whose goal is to select the MBeans on which management operations are performed.

Usually, a management application performs a query to find the MBeans that are the target of its management requests. To select MBeans, applications can specify the following.

  • An object name filter, which is a possibly incomplete object name that the MBean server tries to match with the object names of all registered MBeans. All MBeans whose names match the filter pattern are selected. Filters can contain wildcards to select sets of MBeans, or a filter can be a complete object name that must be matched exactly. Filter rules are explained in detail in the JMX specification.

  • A query expression, which is an object that represents a set of constraints applied to the attribute of an MBean. For each MBean that passes the filter, the MBean server determines if the current state of the MBean satisfies the query expression. Queries usually test for attribute values or MBean class names.

For example, a filter could select all the MBeans whose object names contain MyMBeans and for which the attribute named color is currently equal to red.

The result of a query operation is a list of MBean object names, which can then be used in other management requests.

2.5.2 Dynamic Loading

Dynamic class loading is performed by loading management applets or m-lets containing MBeans. This service loads classes from an arbitrary network location and creates the MBeans that they represent. The m-let service is defined by the JMX specification. The m-let service makes it possible to create dynamically extensible agents.

A management applet is an HTML-like tag called <MLET> that specifies information about the MBeans to be loaded. It resembles the <APPLET> tag, except that it loads only MBean classes. The tag contains information for downloading the class, such as the classname and the location of its class file. You can also specify any arguments to the constructor that is used to instantiate the MBean.

The m-let service loads a URL that identifies the file containing <MLET> tags, one for each MBean to be instantiated. The service uses a class loader to load the class files into the application's Java virtual machine. It then instantiates these classes and registers them as MBeans in the MBean server.

The m-let service is implemented as an MBean and instantiated and registered in the MBean server. Thus, the m-let service can be used either by other MBeans or by management applications. For example, an application could make new MBean classes available at a location, generate the m-let file, and instruct the m-let service in an agent to load the new MBeans.

Dynamic loading effectively pushes new functionality into agents, allowing management applications to deploy upgrades and to implement new resources in their agents.

2.5.3 Monitoring

The monitoring service complies with the JMX specification and provides a polling mechanism based on the value of MBean attributes. The monitoring service contains three monitor MBeans, one MBean for counter attributes, another MBean for gauge-like attributes, and a third MBean for strings. These monitors send notifications when the observed attribute meets certain conditions, mainly equaling or exceeding a threshold.

Monitor MBeans observe the variation of an MBean attribute's value over time. All monitors have a configurable granularity period that determines how often the attribute is polled. Each monitor has specific settings for the type of the observed attribute, as follows.

  • Counter monitor, which observes an attribute of the integer type (byte, integer, short or long) that is monotonically increasing. The counter monitor has a threshold value and an offset value to detect counting intervals. The counter monitor resets the threshold if the counter rolls over.

  • Gauge monitor, which observes an attribute of integer (byte, integer, short, or long) or floating-point (float or double) types that fluctuates within a given range. The gauge monitor has both a high and low threshold, each of which can trigger a distinct notification. The two thresholds can also be used to avoid repeated triggering when an attribute oscillates around a threshold.

  • String monitor - Observes an attribute of type String. The string monitor performs a full string comparison between the observed attribute and its match string. A string monitor sends notifications both when the string matches and when it differs at the observation time. Repeated notifications are not sent, meaning that only one notification is sent the first time the string matches or differs.

Monitor notifications contain the name of the observed MBean, the name of the observed attribute, and the value that triggered the event, as well as the previous value for comparison. This information allows listeners to know which MBean triggered an event. The listeners do not need to access the MBean before taking the appropriate action.

Monitor MBeans can also send notifications when certain error cases are encountered during an observation.

Previous Previous     Contents     Index     Next Next