test

Java Dynamic Management Kit 5.1 Getting Started Guide

Chapter 4 Legacy Connectors and Related Features

Several features from previous releases of Java Dynamic Management Kit (Java DMK) have been deprecated in version 5.1. This is mostly due to the support of the Java Management Extensions specification (JMX) version 1.2 and the JMX Remote API that were added in Java DMK 5.1. Although these legacy features are now marked as “deprecated”, they have been retained for reasons of backwards compatibility.

4.1 Legacy Connectors

Java DMK 5.1 includes three legacy connectors, in addition to the standard connectors described in 2.3.1 Connectors. The legacy connectors are deprecated in favor of the standard ones.

The legacy connector protocols are based on RMI, HTTP, and HTTP/S. The HTTP and HTTP/S connectors are identical except for the security details of connection establishment. For more information on security for legacy connectors, see 4.4 Security Mechanisms for Legacy Connectors.

A legacy 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.

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

4.1.1 Wrapping of Legacy Connectors

Although it is recommended that you use the new RMI and JMXMP connector protocols defined by the JMX Remote API, it is possible for you to continue to use your existing legacy connectors alongside the new ones. This is achieved by wrapping the legacy connector so that it appears in a form that is compatible with the new standard connectors. Wrapping your Java DMK 5.0 RMI and HTTP(S) connectors allows applications created using Java DMK 5.1 to interoperate with existing Java DMK applications.

4.1.2 Monitoring Legacy Connectors Using the Heartbeat Mechanism

All connectors provided in the Java DMK implement a heartbeat mechanism. This is true for both standard connectors and legacy connectors. This section describes the heartbeat mechanism used for legacy RMI, HTTP, and HTTPS connections. For information on the heartbeat mechanism used for standard connectors, see 2.3.1.3 Monitoring Standard Connectors Using the 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.

4.1.3 Generating Proxies for Legacy Connectors

This section outlines how to generate proxies for MBeans accessed through legacy RMI, HTTP and HTTPS connectors.

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:

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

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

Binding proxy MBeans to Local and Remote Servers

Figure 4–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 tool, 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.

Note –

The proxygen tool must only be used to create proxies for MBeans accessed through legacy Java DMK connectors. It is not for use with standard connectors.

4.2 Generating Proxy MBeans

Generating proxy objects for your MBeans is an optional step that depends on the design of your management application. As discussed earlier in this guide, a proxy is an object that represents an MBean in a remote agent. The manager accesses an MBean by performing operations on the proxy MBean.

Proxy objects simplify the design of your management application because they provide an abstraction of remote resources. Your architecture can assume that resources are local because they appear to be, even if they are not. Of course, proxies have greater response times than local resources, but the difference is usually negligible.

Using proxies also simplifies the code of your application. Through the connector client, the proxy object handles all communication details. Your code invokes a method that returns a value, and the complete mechanism of performing the remote management request is hidden. This object-oriented design of having a local object represent a remote resource is fully in the spirit of the Java programming language.

Assuming that a management application has already established the connection to an agent, the overhead of a proxy object is minimal, both in terms of resource usage and required setup. However, it is common sense to instantiate proxies only for resources that will be accessed often or that are long-lived.

The method used to generate proxies has changed in Java DMK 5.1. The proxygen tool is now marked as deprecated. Use the proxygen tool only if you require proxies for legacy remote method invocation (RMI), hypertext transfer protocol (HTTP), and secure HTTP (HTTP/S) connectors. For new RMI, RMI/IIOP and Java Management Extensions messaging protocol (JMXMP) connectors that comply with the JMX 1.2 and JMX Remote API 1.0 specifications, you can generate a proxy object at runtime, given just its Java interface, using the dynamic proxies defined by the Java 2 Platform, Standard Edition (J2SE) java.lang.reflect.Proxy interface. These dynamic proxies cannot be used with the legacy connectors.

In an advanced management solution where resources are discovered only at runtime, the proxy class can be loaded dynamically in the manager. For example, the resource might expose an attribute called ProxyURL from which a class loader can retrieve the proxy object.

4.3 Cascading Service for Legacy Connectors

The cascading service for legacy connectors is an MBean that establishes a connection to one subagent. For each of the subagent's MBeans, the cascading service instantiates a mirror MBean that is registered in the master agent. The cascading service also defines a filter and query expression that together determine the set of MBeans in the subagent that is mirrored.

The mirror MBean is a sort of proxy that is specific to the cascading service. A mirror MBean exposes the same management interface as its corresponding MBean. All attributes, operations, and notifications can be accessed through the mirror MBean, which forwards all management requests through the cascading service to the corresponding MBean in the subagent.

You can define hierarchies of agents of arbitrary complexity and depth. Because mirrored MBeans are registered MBeans, they can be mirrored again in a higher master agent. The cascading service is dynamic, meaning that mirrored MBeans are added or removed as MBeans in a subagent are added or removed.

The cascading mechanism works only in one direction. While master agents can manipulate objects in their subagents, subagents have no visibility of their master agent and are not even aware of their master agent.

The cascading service relies on connector components internally and can therefore be used with the RMI, HTTP, or HTTPS protocols. The user specifies the protocol and the subagent's address when configuring the cascading service.

4.4 Security Mechanisms for Legacy Connectors

The legacy RMI and HTTP-based connectors implemented different security mechanisms to those implemented by the new RMI and JMXMP connectors. These legacy mechanisms are now deprecated, and are presented here for reasons of backwards compatibility.

4.4.1 Password Protection

Password-based protection restricts client access to agent applications. All HTTP-based communication provides login- and password- based authentication, as does the SNMP protocol adaptor.

Password protection can be used to associate managers with a set of privileges that determine access right to agents. The user is free to implement whatever access policy is needed on top of the password authentication mechanism. The SNMP protocols also provide password protection to agent applications. See 2.7.5 SNMPv1 and SNMPv2 Security and 2.7.6 SNMPv3 Security.

4.4.1.1 HTTP Connectors

Both HTTP and HTTPS connectors provide login and password-based authentication. The server component contains the list of allowed login identifiers and their passwords. Management applications must specify the login and password information in the address object when establishing a connection.

If the list of recognized clients is empty, the default behavior is to perform no authentication and grant access to all clients.

4.4.1.2 HTML Protocol Adaptor

Because the HTML protocol adaptor relies on HTTP messaging, it also implements password protection. The agent application specifies the list of allowed login identifiers and their passwords when creating the HTML adaptor. When password protection is enabled in HTML, the web browser usually displays a dialog box for users to enter their login and passwords.

In general, the security mechanisms of a protocol adaptor depend on the security features of the underlying protocol. The ability to use security mechanisms also depends on the functionality of the management console. If your web browser does not support the password dialog, you cannot access a password-protected HTML adaptor.

4.4.2 Context Checking

Whereas password protection grants all-or-nothing access, context checking enables the agent application to filter each management request individually. Context checking can be associated with password protection to provide multiple levels of security.

All management requests that arrive through a connector or HTML protocol adaptor are inspected by the agent application to determine if they are authorized. The management application filters requests based on the type of request, the MBean for which they are intended, or the values that are provided in the operation.

For example, context checking could allow an agent to implement a read-only policy that refuses attribute set operations, all operation invocation, and does not allow MBean registration or unregistration. A more selective filter could just ensure that the agent cannot be disconnected: it would disallow MBean unregistrations, stop operations, and invocations that contain null parameters, but only when applied to connector servers or protocol adaptor MBeans.

In addition, requests through connector clients can be filtered by an operation context field, which could be a password or any other identifying data. The context object is provided by the management application, and it will be sent to the connector server along with each request. The agent can verify this context and potentially reject the request if the context is considered invalid or inappropriate for the operation.

To make this context checking possible, the agent provides:

Figure 4–2 Context Checking Using Stackable MBean Server Objects

Context Checking Using Stackable MBean Server Objects

In Figure 4–2, a context checker object has been inserted between the connector and the MBean server. Because a context checker object implements the MBeanServer interface, the connector interacts with it in exactly the same way as it did with the MBean server. This stacked object retains a reference to the real MBean server, to which it forwards all requests that are allowed. The context checker can also perform any other action, such as log all filtered requests and trigger a notification when an invalid request is received.

For security reasons, only the agent application can insert or remove stackable MBean server objects. This operation is not exposed to management applications, which cannot even detect whether requests are being filtered. However, the context checker might respond with an exception message that explains why a request was denied.

4.4.3 Data Encryption

The last link in the security chain is the integrity of data that is exchanged between agent and managers. Two issues need to be considered simultaneously:

Authentication:

Both agent and manager must be certain of the other's identity.

Privacy:

The data of a management request should be tamper-proof and undecipherable to nontrusted parties.

These issues are usually resolved by a combination of electronic signatures and data encryption. Again, the implementation is protocol-dependent.

The SNMP protocols also provide password protection to agent applications. See 2.7.5 SNMPv1 and SNMPv2 Security and 2.7.6 SNMPv3 Security.

The HTTPS connector enables Java managers to access a Java dynamic management agent using HTTP over Secure Socket Layer (SSL). SSL security is implemented in the Java 2 platform. The HTTP/SSL connector provides identity authentication based on the Challenge-Response Authentication Mechanism using MD5 (CRAM-MD5). The HTTPS connector server requires client identification by default.

The behavior of the HTTP/SSL connector is governed by the particular SSL implementation used in your applications. For data encryption, the default cipher suites of the SSL implementation are used. The SSL implementation must be compliant with the SSL Standard Extension API.

4.4.4 Secure Dynamic Loading

The m-let service downloads Java classes from arbitrary locations over the network. If you want to do so, you can enable code signing to ensure that only trusted classes can be downloaded. Secure loading relies on code signing.

On the Java 2 platform, the java.lang.SecurityManager property determines if code signing is enforced. When this security is enabled, again only class files signed by a trusted party will be loaded. On the Java 2 platform, users invoke the keytool, jarsigner, and policytool utilities to define their security policies.

4.5 Tracing

The implementation of Java DMK 5.1 has changed with regard to the production of tracing and debugging information:

When java.util.logging is not present, it is still possible to activate the traces by specifying -DLEVEL_DEBUG or -DLEVEL_TRACE on the Java command line.