test

Getting Started with the Java Dynamic Management Kit 5.0

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.