![]() |
|||
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
| ||
2.3.2 MBean Server InterceptorsAs 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 AdaptorsProtocol 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.
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 ModelThe 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 ListenersIn 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 ![]() 2.4.2 Remote Notification ListenersThe 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 ![]() 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 ServicesTo 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 FilteringQuerying 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.
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 LoadingDynamic 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 MonitoringThe 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.
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. | ||
| ||
![]() |