The main architectural components

MBeans

This is the more common name for Managed Beans. As explained above, these are objects that can be stored in the repository (which is the MBean Server, as described elsewhere). After an MBean is stored in a repository, other Java classes can access specific methods and descriptions within the MBean. Making an MBean is not as simple as implementing an MBean interface (there is no class or interface named MBean in a JMX implementation). I'll describe how to make MBeans of the different types latter.

MBeanServer

The repository for accessing, creating, registering, removing MBeans. (Registering and Removing MBeans is how you have the MBeanServer manage or stop managing them). MBeanServers make MBeans available to the running JVM, they do not write them to permanent storage. If you destroy an MBeanServer, you will lose all of the MBeans that were in it (this would happen, of course, if your JVM process died). For this reason and many others, you probably want to encapsulate control of your MBeanServer instance in an Agent as described elsewhere. You will get your MBeanServer object from a factory (i.e., you will not implement your own).

The MBeanServer is normally accessed through its MBeanServerConnection interface, which works both locally and remotely. (The exception to this is the Agent, which accesses it as an MBeanServer).

JMX Client

I am stipulating this term because the JMX specification docs fail to differentiate between Agents and other local JMX programs, and then call remote all JMX programs "remote clients". It's all very turbid.

A JMX Client is any class that uses an MBean object directly (by directly I mean, not through a non-JMX facade). In order to do this, the class must be given (or instantiate) an MBean, MBeanServer or MBeanServerConnection, and must have the JMX Implementation jar(s) in its classpath. A JMX Client doesn't invoke methods on MBeans like mbeanobject.methodname(), but rather like mbeanServerConnection.invoke(mbeanID, "methodname",...), mbeanServerConnection.getAttribute(mbeanID, "attname") , etc.

Unlike the MBeanServer, JMX Clients do not normally come with the JMX Implementation. There are very few open reusable, open source JMX Clients out there, so, for now, you'll be implementing your own.

In general, when JMX Clients use an MBeanServer instance, they should use the MBeanServerConnection interface whenever possible, because code that uses MBeanServerConnection is portable (i.e. will work as-is either locally or remotely).

The three types of JMX Client

Local JMX Client

A Local JMX Client runs in the same JVM as the MBeanServer.

Agent

The Agent is the Local JMX Client that instantiates and contains the MBeanServer. Other Local JMX Clients can get references to the MBeanServer to work with, but the Agent has primary reponsibility for it. The Agent instantiates, configures, initializes and controls an MBeanServer.

Some Agent responsibilites

• Load some MBeans upon startup.

• Load and initialize Connector(s) (Connectors are described elsewhere).

• Load and initialize Protocol Adaptor(s) (Protocol Adaptors are described elsewhere).

• Store MBeans to permanant storage so that they can be restored when the JVM is restarted.

• Initialize and manage Agent services such as dynamic class loading, monitors, timers, relation services.

Remote JMX Client

A Remote JMX Client is just like a Local JMX Client except that it must instantiate a Connector client and connect it up to a Connector server to get a MBeanServerConnection. It then uses the MBeanServerConnection in the same way as a Local JMX Client.

Management Client

A client program used for managing MBeans. The management client is usually not a JMX Client, but could be. The essential point is that it is an end-user program that somehow initiates commands that end up invoking MBean methods or services. One example is a web browser connected to a HTML Protocol Adaptor (Protocol Adaptors are explained below). Another example is an existing SNMP Management Gui which can send SNMP commands to a SNMP Protocol Adaptor. In these typical cases, the Management Client programs, the browser and the SNMP Management Gui, know nothing about JMX. Alternatively, you could make a custom Management Client Gui that is a Local or Remote JMX Client.

Connector

A connector lets classes in remote JVMs (i.e., Remote JMX Clients use MBeans and the MBeanServer via JMX as if they were local. There is a Connector client side piece and a Connector server side piece for every Connector connection. A JMX Agent sets up and configures Connector servers. Remote JMX Clients set up and configure Connector clients.

One Connector object could use the Corba protocol to connect a remote JMX Client to a MBeanServer, for example. Compliant Connector implementations must follow the JMX protocol-specific rules for how to exchange data. In this way, in theory, any Connector client supporing protocol X should be able to connect to any Connector server that supports protocol X.

Protocol Adaptor

A protocol adaptor is just a JMX Client that is written to enable non-JMX programs to interface to your Agent.

The name is unfortunate, because it describes a Connector better than a Protocol Adaptor Protocol Adaptors have nothing to do with protocols, but Connectors do. The purpose of a Protocol Adaptor is to serve some type of client(s). The adaptor can support any (non-JMX) interface(s) whatsoever-- for example, by stdin/stdout. (If you call the interface mechanism a "protocol", then every program in the world is a Protocol Adaptor.) The sole purpose, on the other hand, of a Connector, is to serve a stated protocol according to the spec (as soon as the JMX use for that protocol has been standardized).

It is very easy to differentiate between Connectors and Protocol Adaptors. The server side of both are connected to a MBeanServer, but Connectors have a client piece and Protocol Adaptors do not. The client of a Connector is a Remote JMX Client using a Connector client. The client of a Protocol Adaptor has no JMX code-- it is just any program that can connect to the Protocol Adaptor in any (non-JMX) way that the Protocol Adapter makes available.

To exemplify how Protocol Adaptors are misnamed... I may want to access my Agent both from an existing management web interface, and from a new, dedicated web interface. This would call for two Protocol Adaptors, each one creating HTML appropriate for each user application: One protocol but two Protocol Adaptors that communicate to the external program however they want to over that protocol. But if you use a Connector so that two client programs of any type can access your Agent over, say, a TLS TCP socket, the server runs only one Connector because there is only one network protocol, and the way that data is transmitted over the TLS TCP socket is mandated by the spec.