Jolokia的结构完全不同于JSR-160连接器，其中最明显的差异就是Jolokia的typeless approach（无类型访问）。
JSR-160, 于2003发布, 与Jolokia的实际目的不同.是一个客户端可以透明的调用MBean的标准， 不论MBean是mbean驻留在本地还是远程MBeanServer。 API中虽然为Java客户端提供了很好的解决方案，但同样存在风险，应为他隐藏了远程的JMX调用。 这里有许多小问题，性能就是其中之一. 无论是本地还是远程调用，调用者必须会发生什么以及会有什么结果。 另外， 这是一种显式地远程调用方式, 以让调用者知道要调用的潜在昂贵的远程调用的编程模式。 这可能是RMI（默认协议栈JSR - 160连接器）在显式的远程协议方面失去的市场份额的主要原因。
JSR-160的一个问题是它的隐式依赖于RMI并且需要对一个完整的(Java)对象进行序列化机制来通过连接床底管理信息。但这意味着对非Java(或更确切地说，JVM)关上了大门。Jolokia使用typeless approach(无类型访问)某种轻量级的序列化JSON的方式(在双向上，他的功能是不对称的)。当然，这种方法也有一些缺点，但也颇有一定的优势。至少，它在JMX世界是唯一的;-)。
2.1. Agent 模式
图 2.1, “Jolokia 架构”说明了Jolokia的工作环境. 前端基于JSON通过HTTP协议桥接来调用本地JMX MBean获取代理出口。此架构在JSR-160空间以外，因此需要不同的设置。有多种技术可用于输出协议，可以通过HTTP。最突出的是将Agent部署到一个servlet容器中。这可能是一个轻量级的，如Tomcat或Jetty或者其他完全成熟的JEE服务器。由于它的作用就像一个通常的Web应用程序来部署Agent, 对任何一位会用Java Web应用程序的开发人员来说没有门槛。
但也有更多的选择。专业化的Agent可以使用OSGi HTTPService或嵌入式Jetty服务器中的Mule Agent的方式。 JVM Agent使用的HTTP-Server包括所有版本的Oracle JVM 6，并且可以动态地附加到任何正在运行的Java进程。有关Agent的详细描述，请参照Chapter 3,Agent。
Jolokia可以很容易地集成到自己的应用程序中。joloki核心库（被打成JAR包），其中包括一个servlet，它可以很容易地添加到自定义应用程序。 Section 3.1.3, “Jolokia Agent的servlet的编程使用” 包含更多信息。
2.2. Proxy 模式
如果不能在目标平台上部署Jolokia agent， 那么Proxy模式将是一种解决方案。这种模式下，访问目标服务器的唯一先决条件是一个JSR-160连接。在大多数情况下，出于策略性原因，根本就不允许部署额外的软件或这样做需要一个漫长的审批过程。另一个原因可能是目标服务器通过JSR-160已经提供JMX，你应该避免额外的步骤部署agent。
承载jolokia.war需要一个专门的proxy servlet服务器，默认情况下支持agent模式和proxy模式。一个轻量级的容器，如Tomcat或Jetty这样的设置是一个完美的选择。
图 图 2.2, “Jolokia JMX代理服务器” 描述了一个典型的proxy模式设置。通常客户端发送Jolokia请求，其中包含一个额外的部分来指定要访问的目标。所有路由信息都包含在请求本身，因此 代理可以普遍地使用，而不需要特定的配置。
说了这么多，proxy模式也有一定的局限性，详情 Chapter 5, Proxy 模式 .
总结，代理模式应仅在需要时使用。 agent Servlet与proxy模式相比，是更强大的，因为它消除了额外的层，增加了整体复杂性和性能。此外，在代理模式下不提供的一些功能，如合并MBeanServers。