test

Getting Started with the Java Dynamic Management Kit 4.1

Key Concepts

Figure 1-1 below shows the key concepts for the Java Dynamic Management Kit 4.1.

The five keywords are MBean server, MBeans, protocol adaptors, connectors, and proxy MBeans.

Figure 1-1 Key Concepts for the Java Dynamic Management Kit 4.1

Graphic

MBean Server

The MBean server, referred to as the framework in Java Dynamic Management Kit 3.x versions versions, is a registry for JMX manageable resources which are exposed to management operations in an agent. It provides a management framework with services for manipulating JMX manageable resources that is protocol-independent and information model-independent. All management operations performed on these resources are done through the MBean server management interface. You can create and manage objects by registering them within the MBean server, thus, making them visible to management applications. The MBean server includes a library of reusable core agent services in the form of manageable objects, as specified by Java Management extensions (JMX). These services include mlet, timer, monitoring and filtering.

You can register objects in the MBean server through:

Any JMX manageable resource that you want to access for management operations must be registered in the MBean server. This MBean needs to be assigned a unique object name. The manager and the agent then use this object name to identify the object on which it is to perform a management operation. If you do not specify the object name explicitly, the MBean implementation may itself provide a name by default. It is possible to have multiple MBean servers within the same Java Virtual Machine (JVM)..

MBeans

JMX's instrumentation level provides standards for implementing JMX manageable resources. The instrumentation of a given manageable resource is provided by one or more Managed Beans, or MBeans (previously written m-beans). An MBean is a Java object that conforms to certain design patterns for exposing attributes and operations. These attributes and operations enable any Java Dynamic Management agent to recognize and manage the MBean. The design patterns for MBeans give the developer explicit control over how a resource, device or application will be managed. For example, attribute patterns enable you to make the distinction between a read-only and a read-write property in an MBean. The set of all attributes and operations exposed to management through the design patterns is called the management interface of an MBean. Any object that you want to make accessible through the MBean server must be represented as an MBean, including the resources you want an agent to manage, and any services that you want to provide to manage these resources. MBeans can both generate and propagate notification events to remote management applications. For more information regarding managing MBeans remotely, please refer to "Proxy MBeans" and Figure 1-5. MBeans must be developed according to the rules specified by Java Management extensions (JMX).

The JMX architecture enables you to carry out certain operations on a particular agent, by going through that agent's MBean server. These operations are as follows:

You can manage a new MBean as soon as it is registered within the MBean server. An MBean can be created and registered by:

MBeans can also be downloaded from a Web server and plugged into an agent at any time, in response to a demand from the management application. This is called dynamic class loading and means that future services and applications can be loaded on-the-fly and without downtime once they have been deployed on the network. For example, dynamic class loading can be used to provide rapid, low-cost delivery of end-user applications across very large bases of Java technology-enabled devices, such as desktop PC's or Web phones.

The management services supplied with the Java Dynamic Management Kit are implemented as MBeans. You can also write the MBeans representing objects you wish to manage. These objects could include the actual resources you want to manage and the value-added services provided to help manage resources. The Java Dynamic Management Kit 4.1 does not impose any restrictions on where compiled MBean classes are stored. They can be stored at any location specified in the CLASSPATH environment variable of the agent, or at a remote site.

You can develop two types of MBeans:

Standard MBeans

Standard MBeans are Java objects that conform to certain design patterns derived from the JavaBeans component model. Standard MBeans allow you to define your management interface as a Java Interface and this interface, in turn, defines the handles of that particular resource that are exposed to management. The methods for reading and writing the MBean's attributes and for invoking its operations are described in this management interface. Standard MBeans are defined statically, in that the elements of their management interface are defined at compilation time and cannot be controlled or altered at runtime. They are the quickest and easiest type of MBeans to implement when you want to create new MBeans for new manageable resources and where their data structure is defined in advance and is unlikely to change often.

Dynamic MBeans

Dynamic MBeans allow your application or domain specific manager to define the management interface for a resource at run time. This provides a simple way to wrap existing non-MBean style or even non-JavaTM technology based resources and offers greater flexibility than standard MBeans. Dynamic MBeans are more suited to management structures that change over time and are, hence, dynamic. Dynamic MBeans allow manageable resources to be flexible because they have a pre-defined interface which allows attributes and operations to be exposed only at run time.

Proxy MBeans

A proxy MBean (referred to as a client bean or c-bean in Java Dynamic Management Kit 3.x versions versions) represents the manager view of the managed MBean, where the manager has been developed using the remote MBean server interface. This interface makes the functionality of the MBean server available in the remote management application (also referred to as the manager) and lets the manager interact directly with the MBean server of the agent, or instantiate proxy MBeans to manipulate remote MBeans transparently.

The manager accesses an MBean by performing operations on the proxy MBean, which are then propagated to the MBean. These operations are:

A Proxy MBean is generated from an MBean by using the proxygen compiler, supplied with the Java Dynamic Management Kit 4.1. A proxy MBean can only be generated from a standard MBean and is created to mirror an existing MBean. Proxy MBeans are ideal when the management interface does not need to change over time, hence, where the attributes and operations available are stable.

Generic Proxy MBeans

A generic proxy MBean acts in the same manner as a proxy MBean. However, you do not generate generic proxy MBeans using the proxygen compiler as with proxy MBeans, but simply by creating a new instance of a generic proxy MBean. Generic proxy MBeans are ideal when you want to perform operations on one MBean and when you know that the attributes and operations of that MBean will change. For example, sometimes you may have write permissions on an attribute and other times you may only be able to read the attribute. This makes generic proxy MBeans the perfect solution for dynamic management systems, where an MBean's properties are likely to change at run time. Generic proxy MBeans can be used to manage either standard MBeans or dynamic MBeans, thus, can mirror both types of MBeans.

Connectors And Protocol Adaptors

Connectors and Protocol Adaptors allow agents to be accessed and managed by remote custom management applications. These applications could be outside the agent's Java Virtual Machine (JVM). This is illustrated in Figure 1-1 .

Connectors (referred to as adaptors in Java Dynamic Management Kit 3.x versions) connect the MBean server to management applications and enable MBeans to be instantiated and managed remotely. Every connector provides the same remote management interface, but through a different protocol, which allows remote management applications to connect to agents transparently through the network, regardless of the specific protocol. One or more connector clients can be connected to the MBean server, providing views through specific protocols of the MBeans instantiated and registered with the MBean server. The Java Dynamic Management Kit provides connectors for most major internet protocols (for example, HTTP/TCP, HTTP/SSL and RMI) .

A connector is composed of two parts:

The interface of the remote MBean server is implemented by the connector client. Connectors allow management applications to be ported onto a manager site, offering the same level of functionality at both the agent and manager side while ensuring seamless, transparent connectivity.

Protocol Adaptors only have a server component and provide connection between a remote management application and an agent, via a specific network protocol. From a manager side, you can view and manage all MBeans registered in the MBean server. This can be achieved by directly accessing the MBean server's interface through a given protocol. For example, a web browser accesses the HTML protocol adaptor directly and, therefore, a client of the HTML protocol adaptor is an HTML browser. Similarly, an SNMP manager accesses the SNMP adaptor directly. Therefore, a client of the SNMP adaptor is an SNMP manager.

In addition, the Java Dynamic Management Kit provides an SNMP toolkit that allows you to generate MBeans that support standard or proprietary MIB's, enabling new Java technology-based agents to be integrated into existing network infrastructures, including most SNMP-based management products.

Connectors and protocol adaptors enable management applications to:

For an agent to be managed remotely, it must include at least one connector or protocol adaptor. However, an agent can include any number of connectors or protocol adaptors, enabling it to be managed remotely by many managers, through different protocols. Proxy MBeans, at the manager side, are used to perform management operations on the corresponding MBeans at the agent side. These MBeans are registered with the MBean server in a manner that is protocol-independent. You need to call the start method to start connectors and protocol adaptors. This allows you to specify the port number before you start them.

JMX MBean Notification Model

The management interface of an MBean allows an MBean's agent to perform control and configuration operations on the managed resources. The JMX MBean notification model allows MBeans to broadcast management notifications. Management applications and other objects register as listeners with the broadcaster MBean. The JMX MBean notification model enables a listener to register only once and still receive all different notifications that may occur in the broadcast.

Adding a local Notification Listener at the agent side

If you want to add a Notifcation Listener at the agent side, you need to call the addNotificationListener method on the MBean server. The MBean server calls the addNotificationListener on the MBean. This is illustrated in Figure 1-2.

Figure 1-2 Adding local listeners at the agent side

Graphic

Adding remote Notification Listener at the manager side

You can also add a Notification Listener, addNotificationListener remotely, on the manager side. You can add a notification listener on a proxy MBean, as illustrated in Figure 1-3.

To add a listener to the manager side, call the appropriate addNotificationListener operation from proxy MBean A. This will transmit a call to the agent side and a local listener will be created internally to represent the remote listener (internal listener 1 in Figure 1-3). This local listener will then be created in the MBean server. This local listener in turn will receive and forward all notifications to the remote, internal listener. This is a protocol-dependent listener and is handled by the connector server. It is in charge of sending notifications throughout the network, from the agent side to the manager side.

Figure 1-3 Adding remote listeners at the manager side 1

Graphic

You can also add a listener to the manager side directly, through the interface of the connector client. To do this, call the addNotificationListener operation from the connector client interface.

Figure 1-4 Adding remote listeners at the manager side 2

Graphic

Remote Notification Mechanism

The ClientNotificationHandler public interface specifies the methods for a connector to allow a notification listener to receive notifications from a remote MBean in an agent. The ClientNotificationHandler interface is implemented by HTTP and RMI connector clients at the manager side. To forward a notification from the agent to the connector client you can configure the connector to use either push or pull mode. In pull mode, the connector server on the agent side buffers all notifications until the connector client requests, or pulls, them. The forwarding period can be set to control the frequency with which notifications are pulled from the connector server. In push mode, the connector server forwards every notification to the connector client as it is received. In the Java Dynamic Management Kit 4.1 the forwarding period is not used in push mode, notifications are forwarded immediately. Figure 1-5 illustrates this process in terms of the Pull mechanism and the Push mechanism.

The Push Mechanism

You can choose to use the Push Mechanism to push notifications from an agent to a manager. When the connectors run the Push Mechanism , the connector server forwards the notifications to the connector client as soon as they are emitted by the MBeans. For example, you can register an object at the manager side as a listener for notifications emitted by MBean A. Thus, when MBean A, at the agent side, emits a notification, the HTTP, HTTP/SSL or RMI connector forwards this notification to the connector client at the manager side.

The Pull Mechanism

You can choose to use the Pull Mechanism to forward notifications from an agent to a manager. This is useful, for instance, when the agent is unable to connect to a manager. For example, if there is a fire-wall in place between the agent side and the manager side. You can use the Pull Mechanism to pull notifications from the agent side to the manager side. When you create the remote MBean server you need to set the mechanism mode and the pull period. The pull period is the time period between pulls. Pulls occur when the HTTP, HTTP/SSL or RMI connector server at the agent side is instructed by the manager to attempt to pull notifications. Thus, the manager decides when, and how often, it wants to retrieve notifications . For example, the pull frequency could be set to try to get notifications every thirty seconds or every minute.

Figure 1-5 Remote Notification Mechanism

Graphic