前言

JMX 是 Java 环境下系统管理的标准解决方案，从 jdk 1.5 开始，JMX 在所有 JVM 中都可用，企业级应用服务器中甚至通过 JVM 进行管理。JMX 是一个精心设计的规范，在其它 EJB 规范轰轰烈烈的失败的时候创建。在创建之后十年，JMX 仍然是 Java 环境下唯一的管理解决方案。JMX 丰富的 MBeans 实现方式和层次是它设计的亮点，从简单的 标准 MBean 到非常灵活的开放 MBeans 和 MXBeans

然而，JMX 里的一些概念直到过时也没有被正式使用，比如 JSR-77 没有达到发布标准，JSR-160 被设计用于远程访问 JMX，希望能够隐藏通信细节，让远程和本地访问 JMX 没有却别，但不幸的是 RMI 协议和编程模型以 Java 为中心，导致在 Java 环境外并不适用。这就是 Jolokia 的切入点，它是基于 Agent 的，与 JSR-160 并存，但是它使用更加开放的 HTPP 协议，通过 Json 协议序列化数据内容。这为 非 Java 环境的客户端打开了崭新的世界。在协议之外，Jolokia 也为 远程 JMX 带来了新特性：一次通信完成多个 JMX 操作；只允许某些 JMX 操作的安全机制，其它一些特性比如 代理模式和历史跟踪对于 Jolokia 也是定制的。

这篇参考手册详细介绍了 Jolokia，第二章 介绍 Jolokia 的整体架构，第三章介绍 安装和配置不同的 Jolokia 客户，接下来的两章介绍安全机制和代理模式。在第六章介绍了 Jolokia 客户端实现者最感兴趣的协议定义。Jolikia 预置的 MBeans 列表在第七章介绍，第八章列举了可用的 Jolokia 客户端。

第二章 - 架构

Jolokia 的架构与 JSR-160 的连接器有所不同，其中最厉害的是 Jolokia 无类型的连接方式。JSR-160 是2003年释放，其设计目标是定义一个客户端标准，可以以透明的方式调用远程或本地的 MBeanServer 中的Mbean。这给 JMX 客户端提供了方便，但同时隐藏远程调用细节也存在一定风险。调用者应该至少了解调用过程。同时，RMI 传递实体类型，所以调用者需要明确知道实体结构，这增大了开发成本，所以在远程调用方面，RMI 渐渐失去了市场。

JSR-160 的问题是依赖于 RMI，需要完成的 Java 对象序列化／反序列化机制，限制了客户端必须使用 Java 环境。Jolokia 是采用无类型、轻量级的 Json 传输数据。尽管这种方式也有弊端，但利大于弊。

Agent 模式

下图展示了 Jolokia 的 Agent 模式，Agent 可以调用本地的 MBeanServer 暴露 json 接口供外部调用，在客户端上可以应用不同的技术来展示通过 Http 获取的 JMX 数据。Agent 可以放到一个轻量级的 Servlet 容器中，像 Tomcat、Jetty 之类的，它和普通的 Web 应用的行为一致，所以对于 Web 应用开发人员来讲非常熟悉。

除了放到 Servlet 容器之外，Jolokia 也可以定义特殊的 Agent，比如实现 OSGi 或者内置 Jetty 服务器。Agent 的详细内容在第三章中描述。

Jolokia 也可以集成到 Web 应用中，jolokia-core 库作为一个 Jar 包，提供一个 Servlet，加入到 Web 应用中之后就可以访问。

代理模式

代理模式为了解决不能向目标应用加入 Agent 的情况，可能由于不能改变目标应用，或者目标应用已经暴露了 JMX 调用。一个专用的 Servlet 代理服务器来部署 jolokia.war， Tomcat 或 Jetty 是非常好的选择。

下图展示了代理模式，客户端发送标准的 Jolokia 请求给 代理，请求中包含了路由信息，所以代理服务器中也不需要额外进行配置。

综上，代理模式应该仅在必要时使用，Agent 模式比代理模式更为高效，因为代理模式增加了一次中间转发，增加了复杂性，而且有些功能，比如合并 MBeanServers 在代理模式下不能使用。

第三章 - Agents

Jolokia 是基于 Agent 访问 JMX 的方式，需要安装 agent 来访问 JMX，agent 可以安装到目标应用上，也可以安装到独立的 Servlet 容器中，作为代理，访问目标应用。一共有四种不同类型的 agents.

War Agent: 以 War 包的形式分发和部署

OSGi Agent

Mule Agent

JVM Agent

应用集成 Jolokia Agent：通过加入 jolokia-core 可以将 Agent 集成到 web 应用中，方便使用