![]() |
|||
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
| ||
Chapter 4Legacy Connectors and Related FeaturesSeveral 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 ConnectorsJava 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 ConnectorsAlthough 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 MechanismAll 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 ConnectorsThis 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 ![]() 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 MBeansGenerating 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 ConnectorsThe 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. | ||
| ||
![]() |