test

Java Dynamic Management Kit 5.1 Getting Started Guide

2.3.1 Connectors

Connectors establish a point-to-point connection between an agent and a management application, each running in a separate Java virtual machine.

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.

The Java DMK 5.1 provides the three standard connectors that are defined by the JMX Remote API 1.0 (JSR 160) specification. The standard connectors are based on RMI, RMI/IIOP, and JMX Messaging Protocol (JMXMP) which uses Java serialization over TCP.

The Java DMK 5.1 also provides connectors for the HTTP/TCP, HTTP/SSL, and RMI protocols. These “legacy” connectors were included in previous versions of the product, and are deprecated in version 5.1, now that standard connectors are available. Java DMK 5.1 provides a mechanism to wrap legacy connectors so that they can be created in the same way as the new connectors. Use of the legacy connectors is discouraged, although the use of the legacy HTTP(S) connector is acceptable as long as no native standard HTTP connectors are present.

Every standard connector provides the same remote API, which frees management applications from protocol dependencies. The API provided by standard connectors is similar to that provided by legacy connectors, but they are not interchangeable. In particular, the address format used by standard connectors is different from that used by legacy connectors.

The addresses of the new connectors are instances of the JMX Remote API interface JMXServiceURL. The address must adhere to the following syntax.


service:jmx:protocol:sap

Here, protocol is the transport protocol to be used to connect to the connector server, and sap is the address at which the connector server is found. The following is an example JMX service URL.


service:jmx:jmxmp://localhost:5555

In this example, the transport protocol is JMXMP and it is found at port 5555 of the local host. See the API documentation for the JmxServiceURL interface for more information about the syntax of these addresses.

2.3.1.1 RMI Connectors

The RMI connector is specified by the JMX Remote API. User code uses the same generic factories to create a client or server as it would to create any other kind of connector. Every connection to an RMI connector is implemented by means of a separate RMI object, which is destroyed when the connection is closed. Communication is always from client to server, even for notifications, which simplifies configuration and firewall use.

The RMI connector works over both JRMP, (the native Java transport for RMI) and IIOP. The same remote interfaces are used in both cases. Only the way in which these interfaces are exported differs. Because of class-loading issues, the RMI/IIOP connector cannot easily be used to interact with clients or servers that are not written in the Java language.

2.3.1.2 JMXMP Connectors

The JMX Remote API specifies an optional connector using a custom protocol called JMXMP, that is based on Java serialization running over TCP connections. JMXMP can optional use one or both of SSL and the Simple Authentication and Security Layer (SASL) for security.

Communication between a given client and the server happens over a single TCP connection. Every message is a serialized Java object. Coomunication is conceptually in two independent streams of messages, from client to server and from server to client. Thus, there can be many concurrent client requests over the connection at any given time. Replies do not have to arrive in the same order as the corresponding requests.

Notifications are handled in the same way as for the RMI connector. A message from client to server asks for notifications, and a reply message from server to client supplies them.

2.3.1.3 Monitoring Standard Connectors Using the Heartbeat Mechanism

All connectors provided in the Java DMK implement a heartbeat mechanism. This is true for both legacy connectors and the new standard connectors. This section outlines the heartbeat mechanism used for standard connectors. For information on the heartbeat mechanism used for legacy connectors, see 4.1.2 Monitoring Legacy Connectors Using the Heartbeat Mechanism.

The heartbeat mechanism monitors the connection between a manager and an agent, and automates the cleanup procedure when the connection is lost. This allows both the manager and the agent to free resources that were allocated for maintaining the connection.

The mechanism is entirely contained in the connector client and connector server components. No additional objects are involved. In addition, connector clients and servers send notifications that the manager application can receive to be aware of changes in the status of a connection.

The connector client generates a periodic heartbeat, by performing an innocuous operation on the server. If any beat fails because of a communication failure, the connection is considered to be dead. The server does not need to know that the heartbeat exists. The innocuous beat operations look like any other client operation.

Furthermore, client death is not detected by heartbeat. Instead, connectors are defined in such a way that there is no permanent client state on the server. Thus, the server can close client connections after a specified idle time. If the client is still alive, it will establish another connection. This is essentially an implicit lease mechanism.

2.3.1.4 Generating Proxies

Java DMK supports the notion of proxies. Proxies simplify the interactions between an application and the MBeans the application wants to manage. The purpose of a proxy is to invoke the methods that access the attributes and operations of an MBean, through its MBean server. The proxy performs the task of constructing the method calls at every invocation, on behalf of the caller:

Conceptually, a proxy instance makes the MBean server and, optionally, a protocol connector completely transparent. With the exception of MBean registration and connector connection phases, all management requests on MBeans can be fully served through proxies, with identical results, apart from some details concerning exceptions. However, all functionality of the Java DMK is available without using proxies, so their use is never mandatory.

Figure 2–1 shows management components interacting with an MBean through a proxy.

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.

In Java DMK 5.0, proxies were generated using the proxygen tool, supplied with Java DMK 5.1 but now deprecated. This tool is still needed if proxies are required for legacy connectors. However, Java DMK 5.1 provides a useful enchancement for generating proxies. Because Java DMK 5.1 is an implementation of JMX 1.2, you can generate a proxy object at runtime given just its Java interface, using the dynamic proxies provided with the J2SE platform (java.lang.reflect.Proxy). These proxies cannot be used with the legacy connectors.