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 allow agents to be accessed and managed by remote management applications.
An agent may contain any number of connectors or protocol adaptors, enabling it to be managed simultaneously by several managers, through different protocols. It is up to the agent application to coordinate all of the port numbers on which it intends to receive requests.
Connectors establish a point-to-point connection between an agent and a management application, each running in a separate Java VM. The Java Dynamic Management Kit 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:
A connector server which interacts with the MBean server in an agent
A connector client which exposes a manager-side interface that is identical to the MBean server interface.
Therefore, a Java application which instantiates a connector client may perform all management operations which are available through the agent's MBean server.
In the client-server model, it is the connector client which initiates all connections and all management request. An agent is identified by an address which 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 may 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 only establish one connection at a time. This implies that a manager instantiates one connector client for each agent it wishes to contact. 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 which 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 manger exchange management requests and responses based on the JMX architecture. The underlying encoding is hidden and not accessible to the applications.
All connectors provided in the Java Dynamic Management Kit implement a heartbeat mechanism. The heartbeat allows 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 will 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 may also register for heartbeat notifications which are sent whenever a connection is established, retrying, reestablished, lost, or terminated.
A proxy MBean is an object which represents a specific MBean instance and 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 may 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 which are possible on an MBean:
Getting or setting attributes
Invoking operations
Registering or deregistering for notifications
Because dynamic MBeans only expose their management interface 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. The following diagram shows management components interacting with both standard and dynamic MBeans through both standard and generic proxies. Notice that a generic proxy may also represent a standard MBean.

This diagram also shows that proxies may 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 request to either of them are identical. This creates a symmetry that allows the same management components to 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 by using the proxygen compiler, supplied with the Java Dynamic Management Kit. 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 Dynamic Management Kit libraries and are thus always available.
Protocol adaptors only have a server component and provide a view of an agent and its MBeans through a different protocol. They may also translate requests formulated in this protocol into management request on the JMX agent. The view of the agent and the range of possible requests depends upon the given protocol.
For example, the Java Dynamic Management Kit provides an HTML adaptor which presents the agent and its MBeans as HTML pages viewable in any web browser. Because the HTML protocol is text based, only data types which have a string representation may 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:
Not all data types are necessarily supported.
Not all management requests are necessarily supported, as some requests may rely on unsupported data types.
Notifications from a broadcaster MBean may not be supported.
A given protocol adaptor may require private data structures or helper MBeans in order to respond to requests.
The SNMP adaptor provided in the Java Dynamic Management Kit is limited by the constraints of SNMP. The richness of the JMX architecture cannot be translated into SNMP, but all of 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 underway to fully define and standardize the mappings between the JMX architecture and the most widespread management protocols such as SNMP, CORBA, and TMN. Please see the Java Community ProcessSM web site (http://java.sun.com/aboutJava/communityprocess/) for more details.