7.4 JMX Connectors

The current JMX specification is scoped to define a management infrastructure that exists in a single JVM. The specification only hints at how remote programs can access these agent services and request that operations be performed on managed resources from outside of the agent's JVM. The mechanism described in the JMX specification is a connector object that exposes an interface similar to the MBeanServer interface for remote invocation and delegates requests received from remote processes to the agent's MBeanServer instance.

JMX connectors typically expose a subset of the whole MBeanServer interface to remote clients because a few of MBeanServer 's methods are not appropriate for invocation by remote processes. For example, the instantiate() methods return java.lang.Object references that are intended for use in the agent's JVM, not in a remote client JVM. Connectors typically do not convert the semantics of the JMX MBeanServer interface into a different semantic protocol. Mechanisms that provide both remote access to JMX agent functionality and translation of standard MBeanServer semantics to some other semantics (SNMP, for example), are commonly referred to as JMX adapters rather than connectors.

Through connectors and adapters, remote MBeanServers can be integrated with a wide variety of different management systems. Connectors for RMI and SNMP are very common. Connectors that use SOAP over different protocols are becoming more available in products. Connectors can be used to bridge JMX to telecommunication protocols, peer-to-peer protocols, Web services protocols, and messaging system protocols. By decoupling the communication channel aspect from the core management services, JMX provides a flexible and powerful architecture.

The standardization of JMX connectors is under way through the Java Community Process (JCP), in the JSR 160 ("Java Management Extensions [JMX] Remoting 1.2") effort. At the time of this writing, this JSR was just organized and getting under way. Because the definition of this standard is not far enough along at the time of this writing, we have included the basic concepts of the JMX connector in this chapter based on several implementations of products in the field.

Implementations of a JMX connector involve at least two components: an MBean registered in the MBeanServer that represents the server-side portion of the connector logic, and a remote proxy for that connector MBean that contains the client-side logic for packaging requests to be sent to and received from the server component. Figure 7.4 illustrates this relationship. The following sections examine these connector components. For some of these components we will look at some sample interfaces from IBM's WebSphere Application Server 5.0 (more information is available at http://www-3.ibm.com/software/webservers/appserv) to illustrate the concept.

Figure 7.4. JMX Connector Structure

7.4.1 Connector MBean

The MBean that represents the server portion of a JMX connector is registered with the MBeanServer that it exposes to remote clients. The purpose of this MBean is to receive requests from remote clients over a communication protocol, unmarshall these requests, delegate the requests to the local MBeanServer, and return the result of the request to the client.

At present there is no specification for what the JMX connector MBean interface should look like. Some implementations expose an interface identical to the underlying MBeanServer interface; other implementations expose only a single invoke() method. The interface for the MBean representing the MBeanServer is not as important as the interface of the client-side proxy with which the remote management application must interact.

The important thing about the connector MBean is that it is the server-side logic for the communication channel that receives requests from outside of the JVM and hands those requests to the local MBeanServer for the real processing. In this sense, the connector MBean can also act as a request interceptor that provides additional services, such as authorization, before delegating the request to the MBeanServer. The WebSphere implementation does just this, checking that the caller is actually authorized to perform the request before passing it on to the local MBeanServer.

7.4.2 Connector Client Proxy

The client portion of the JMX connector presents an interface to the client program that is very similar to the MBeanServer interface. A simple implementation could present methods to the client program that expose the details of the communications protocol and the marshalling logic used to send requests to the connector MBean on the server. A more sophisticated product would anticipate supporting multiple protocols for remote access and present a common API to the client, thus hiding the details of the transport mechanism beneath this common interface.

For instance, the WebSphere 5.0 JMX connector is exposed through the AdminClient interface. As shown in the code example that follows , the AdminClient interface looks very similar to the standard MBeanServer interface, except that it is missing the deserialize () , registerMBean() , createMBean() , and instantiate() methods. Those methods are oriented toward operations that are to be performed by local MBeanServer clients.

 package com.ibm.websphere.management;  import java.util.Set; import javax.management.*; import com.ibm.websphere.management.exception.ConnectorException; import com.ibm.websphere.management.exception.ConnectorNotAvailableException; public interface AdminClient {      public Set queryNames(ObjectName name, QueryExp query) throws    ConnectorException ;      public Integer getMBeanCount()  throws ConnectorException ;      public String getDomainName() throws ConnectorException ;      public String getDefaultDomain() throws ConnectorException ;      public MBeanInfo getMBeanInfo(ObjectName name)         throws InstanceNotFoundException,                IntrospectionException                ReflectionException,                ConnectorException ;      public boolean isInstanceOf(ObjectName name, String className)                throws InstanceNotFoundException,                       ConnectorException ;      public boolean isRegistered(ObjectName name) throws    ConnectorException ;      public Object getAttribute(ObjectName name, String attribute)                throws MBeanException,                       AttributeNotFoundException,                       InstanceNotFoundException,                       ReflectionException,                       ConnectorException ;      public AttributeList getAttributes(ObjectName name,           String[] attributes)                throws InstanceNotFoundException,                       ReflectionException,                       ConnectorException ;      public void setAttribute(ObjectName name,     Attribute attribute)                throws InstanceNotFoundException,                       AttributeNotFoundException,                       InvalidAttributeValueException,                       MBeanException,                       ReflectionException,                       ConnectorException ;      public AttributeList setAttributes( ObjectName name,           AttributeList attributes)                throws InstanceNotFoundException,                       ReflectionException,                       ConnectorException ;      public Object invoke(ObjectName name,                           String operationName,                           Object params[],                           String signature[])                throws InstanceNotFoundException,                       MBeanException,                       ReflectionException,                       ConnectorException ;     public void addNotificationListener(ObjectName name,          NotificationListener listener, NotificationFilter filter,         Object handback)                throws InstanceNotFoundException,                       ConnectorException;     public void addNotificationListenerExtended(ObjectName name,          NotificationListener listener, NotificationFilter filter,         Object handback)                throws ConnectorException;     public void removeNotificationListener(ObjectName name,          NotificationListener listener)                throws InstanceNotFoundException,                       ListenerNotFoundException,                       ConnectorException;     public void removeNotificationListenerExtended(          NotificationListener listener)                throws ListenerNotFoundException,                       ConnectorException;     public String getType();     public java.util.Properties getConnectorProperties();     public ObjectName getServerMBean() throws ConnectorException;          public Session isAlive() throws ConnectorException ; } 

Notice that in many cases the only difference between an AdminClient method and the corresponding MBeanServer method is the set of exceptions in the throws clause. Because it is a remote proxy for MBeanServer , AdminClient must throw exceptions that are remotable.

Some methods in the AdminClient interface have no analog in the standard MBeanServer interface. These methods ( getType() , getConnectorProperties() , getServerMBean() , isAlive() ) provide information about the connection to the server for the caller of the AdminClient interface to use to test the health of the connection to the server. Even though many JMX connector implementations do not supply such optional methods, the methods can be handy if the client supports logic for dynamic diagnosis of the connector.

7.4.2.1 Connector Client Factory

In a typical implementation, the client proxy is obtained via a factory object that abstracts the details of how to establish the connection between processes and initialize the client proxy. For instance, we obtain the WebSphere client proxy by calling the AdminClientFactory static method to getAdminClient() :

 package com.ibm.websphere.management;  import java.util.*; import com.ibm.websphere.management.exception.InvalidAdminClientTypeException; import com.ibm.websphere.management.exception.ConnectorException; public abstract class AdminClientFactory {     public static AdminClient createAdminClient(Properties props)                throws ConnectorException     {     } } 

This factory allows many different protocols to be supported by JMX connectors with a common interface. Regardless of the details of the underlying protocol and communications semantics, AdminClientFactory always returns an object that implements the AdminClient interface. The values in the Properties object passed to the factory may specify a connector that communicates using SOAP over HTTP, RMI/IIOP, or any number of other protocols. But the client of the JMX connector is shielded from those details and has to interact only with the common connector interface.

7.4.2.2 Security

Because management channels typically represent sensitive capabilities for the managed system, it is reasonable and often desirable to protect the connectors by forcing the connector client to authenticate before proceeding with the request. Such authentication is usually limited by the constraints of the underlying communications channel. For instance, RMI/IIOP connectors are likely to offer more support for authentication than SOAP/HTTP connectors because more time has been devoted to developing RMI/IIOP security measures and authentication schemes, although this situation is changing because a lot of effort is going into Web services security. But as each new JMX connector protocol is introduced, the various authentication mechanisms (such as basic authentication, credential-based authentication, or trust association authentication) have to be ported to the new protocol before the connector can be considered complete for production environments.

Regardless of the authentication mechanism used, the authentication data identifying the user has to be passed to the connector so that the connector can use it when establishing a connection to the server. In WebSphere, the initialization properties passed to AdminClientFactory contain the authentication data needed by the connector client proxy. Other implementations use system properties or security property files to pass the data to the connector so that it can establish an identity with the server.