test

Getting Started with the Java Dynamic Management Kit 5.0

Communication Components

Connectors and protocol adaptors interact with the Java communication objects such as sockets to establish connections and respond to requests from other host machines. Connectors and protocol adaptors enable agents to be accessed and managed by remote management applications.

An agent can contain any number of connectors or protocol adaptors, enabling it to be managed simultaneously by several managers, through different protocols. The agent application is responsible for coordinating all the ports on which it intends to receive requests.

Connectors

Connectors establish a point-to-point connection between an agent and a management application, each running in a separate Java virtual machine. The Java DMK provides connectors for the HTTP/TCP, HTTP/SSL, and RMI protocols. Every connector provides the same remote API, which frees management applications from any protocol dependency.

A connector is composed of two parts:

Therefore, a Java application that instantiates a connector client can perform all management operations that are available through the agent's MBean server.

In the client-server model, it is the connector client that initiates all connections and all management requests. An agent is identified by an address that contains the agent's hostname and port number. The target agent must contain an active connector server for the desired protocol. The address object is protocol-specific and can contain additional information needed for a given protocol.

The connector client uses this address to establish a connection with its corresponding connector server. A connector client can establish only one connection at a time. This implies that a manager instantiates one connector client for each agent it contacts. The management application must wait for the connector to be online, meaning that a connection is established and ready to send requests.

Management applications can then invoke one of the methods of the connector client to issue a request. These methods have parameters that define the object name of the MBean and the attribute or operation name to which the request applies. If the request has a response, it will be returned to the caller.

A connector hides all the details of the protocol encoding from the Java applications. Agent and manager exchange management requests and responses based on the JMX architecture. The underlying encoding is hidden and is not accessible to the applications.

Connector Heartbeat

All connectors provided in the Java DMK implement a heartbeat mechanism. The heartbeat enables both the agent and manager applications to detect when a connection is lost, either because the communication channel is interrupted or because one of the applications has been stopped.

The connector client and connector server components exchange heartbeat messages periodically. When a heartbeat is not returned or an expected heartbeat is not received, both components begin a retry and timeout period. If the connection is not reestablished, both the connector client and the connector server free the resources allocated for that connection.

The heartbeat mechanism is only configurable on the manager side, the connector server simply replies to heartbeats. The manager application can set the retry policy as determined by the heartbeat period and the number of retries. The manager application can also register for heartbeat notifications that are sent whenever a connection is established, retried, reestablished, lost, or terminated.

Proxy MBeans

A proxy MBean is an object that represents a specific MBean instance and that makes it easier to access that MBean. A management application instantiates a proxy so that it has a simple handle on a registered MBean, instead of needing to access the MBean server.

The manager can access MBeans by invoking the methods of their proxy object. The proxy formulates the corresponding management request to the MBean server. The operations are those that are possible on an MBean:

Because dynamic MBeans expose their management interface only at runtime, they cannot have a specific proxy MBean. Instead they have a generic proxy whose methods have an extra parameter to specify the attribute or operation name. Figure 2–1 shows management components interacting with both standard and dynamic MBeans through both standard and generic proxies. Notice that a generic proxy can also represent a standard MBean.

Figure 2–1 Binding Proxy MBeans to Local and Remote Servers

Binding proxy MBeans to Local and Remote Servers

Figure 2–1 also shows that proxies can be instantiated either locally in the agent or remotely in the manager. Since the MBean server and the connector client have the same API, management requests to either of them are identical. This creates a symmetry so that the same management components can be instantiated either in the agent or in the manager application. This feature contributes to the scalability of Java dynamic management applications.

A standard proxy is generated from a standard MBean using the proxygen compiler, supplied with the Java DMK. The resulting class then needs to be loaded wherever the proxy will be instantiated. Generic proxies provide less of an abstraction but do not need to be generated. They are part of the Java DMK libraries and are thus always available.

MBean 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 interceptors enable you to intercept operations on MBeans and handle them arbitrarily. Handling them 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.

Protocol Adaptors

Protocol adaptors have only a server component and provide a view of an agent and its MBeans through a different protocol. They can also translate requests 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 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. There is no guarantee that this mapping is complete or fully accurate. However, specification efforts are currently under way to define fully and standardize the mappings between the JMX architecture and the most widespread management protocols such as SNMP, CORBA, TMN, and CIM/WBEM. For more details, see the Java Community ProcessSM web site at:

http://java.sun.com/aboutJava/communityprocess/