JMX (Java Management Extensions) is the standard management solution in the Java world. Since JDK 1.5 it is available in every Java Virtual Machine and especially JavaEE / JakartaEE application servers use JMX for their management business.
I love JMX. It is a well crafted specification, created in times where other concepts like EJBs failed spectacularly. Even more than twenty years after its incubation it is still the one-and-only when it comes to management in the Java world. Especially the various levels of sophistications for implementing MBeans, starting with dead simple Standard MBeans and ending in very flexible Open MBeans and MXBeans, are impressive.
However, some of the advanced JMX concepts didn’t really appeal to the public and are now effectively obsolete. Add-on standards like JSR-77 didn’t receive the adoption level they deserved. And then there is JSR-160, JMX remoting (which was incorporated into JSR-3, JMX 1.4). This specification is designed for ease of usage and has the ambition to transparently hide the technical details behind the remote communication so that is makes (nearly) no difference, whether MBeans are invoked locally or remotely. Unfortunately, the underlying transport protocol (RMI) and programing model is very Java centric and is not usable outside the Java world.
This is where Jolokia steps in. It is an agent based approach, living side by side with JSR-160, but uses the much more open HTTP for its transport business where the data payload is serialized in JSON. This opens a whole new world for different, non-Java clients. Beside this protocol switch, Jolokia provides new features for JMX remoting, which are not available in JSR-160 connectors: Bulk requests allow for multiple JMX operations with a single remote server roundtrip. A fine grained security mechanism can restrict the JMX access on specific JMX operations. Other features like the JSR-160 proxy mode or history tracking are specific to Jolokia, too.
Technically, JMX specification defines a JMX agent:
A JMX agent is a management entity that runs in a Java Virtual Machine (JVM) and acts as the liaison between the MBeans and the management application. A JMX agent is composed of an MBean server, a set of MBeans representing managed resources, a minimum number of agent services implemented as MBeans, and typically at least one protocol adaptor or connector.
And then defines the methods of accessing the JMX agent:
connectors which expose the MBeanServer through a remote interface accessible by the client. The remote interface represents the managed, remote MBeanServer
protocol adaptors which provide access to MBeanServer using protocol-specific messages.
JMX specification mentions SNMP as the protocol. Jolokia uses HTTP and thus can be viewed as JMX protocol adaptor.
This reference manual explains the details of Jolokia. After an overview of Jolokia’s architecture in Architecture, installation and configuration of the various Jolokia agents are described in Agents. Jolokia’s security policy mechanism (Security) and proxy mode (Proxy Mode) are covered in the following chapters. For implementors of Jolokia client bindings the protocol definition is probably the most interesting part (Jolokia Protocol). Jolokia itself comes with the preregistered MBeans listed in Jolokia MBeans. The available client bindings are described in Clients.