JMX心得

JMX作为Java中管理各种资源的框架，提供了一整套的企业级的资源管理和整合方案的平台。它将企业中的各种资源，以一种广义的概念加以描述并提供了一系列有效的管理架构。通过设计良好的JMX架构实现，企业可以对各种资源（当然都要抽象为Java类或者接口）进行添加、删除、发送通告、监控等操作。

在企业级平台和企业级业务整合方案中，JMX都在扮演着一个非常重要的角色。特别是在计算平台中，JMX通过有效地管理各种资源和组件，在系统中发挥了“内核”的重要角色。而且JMX的管理不只限于对本地的资源管理，通过提供网络协议适配器和连接器，远程的客户可以对服务端的资源进行在安全范围内的查询、访问、调用等相应操作。那我们下面就具体的讨论一下JMX在计算平台中的作用吧，而这将以JBoss为例子来说明。

在计算平台的整体架构够，JMX一般是起到一个内核的作用或者总线的作用。它负责管理那些部署在平台上的功能性组件。这些组件以暴露其管理接口的方式注册到JMX Server中，并通过资源的ObjectName来定位和获取其实例。就相当于一个插排，各个组件就像插头一样插到插排上，之后就能马上投入使用，而一拔掉就可以立即脱离平台，却不影响平台中的其他组件。

通过这样非常灵活的方式，就可以以一种高度可扩展的架构来设计系统。通过设计良好的资源接口，JMX Server就可以获取到足够的管理各资源的信息。这些信息包括：接口的操作。一般的企业计算平台或者应服务器（限于Java）一般是通过配置文件的形式来描述平台中的各个功能性组件。例如JBoss中，使用jboss-service.xml配置文件来描述部署到特定服务器中的组件。在这里我就不具体将这个配置文件的内容了，但我还是要提到一些关键的配置文件信息，以便于大家的理解。

在这个配置文件中，将各个组件（资源）都包装在各个mbean元素中，这个对应于JMX中的Model MBean。在这个配置文件中包含很多信息，但是最基本的也是最重要的是attribute、operation、constructor等Java类的基本描述信息。其余的像descriptors（描述相应持久化策略、缓存策略等内容）对于一般开发者而言比较少能接触到。

通过这样方式的优势在于你不要写代码，就可以创建一个组件，并部署到JMX Server中。通过在这个配置文件中写出组件相应的属性、构造函数信息、操作等信息，系统就可以在运行时自动地构造出相应的组件，并部署到服务器中。其中这些mbean元素的name属性都是对应了相应的MBean的ObjectName。

服务器通过启动对应的扫描线程，对服务器的主配置文件和部署区（deploy）进行“监控”。一旦发现了改动，就自动地将组件部署到服务器中或从服务器中移除。

 

l         JNDI和JMX

刚开始学JMX时，老是不明白两者之间有什么区别。后来特地对比了一下两者的架构规范以及研究了一下JBoss中关于两者的具体实现，才有了些“开窍”。下面就分为几个方面展开进行讨论。

Ø         整体架构：JMX是一个服务器端的技术，它只设计了服务器端管理各种资源的架构，当然也包括各种API。而JNDI是一个客户端的API，当然实现中也要有服务器端的支持，但这在JNDI规范中并没有要求。

Ø         操作对象：JMX和JNDI都可以对Java类和对象进行查找和定位（JMX中还支持对MBean的查找，并有特定的Query类）。但是在实际应用中，JMX一般用于系统重要的功能性组件；JNDI用对部署到服务器中的各个应用程序中的资源，例如servlet、EJB和POJO等，并会为每个应用程序建立独立的隔离的Context。各个Context中，只能定位在这个Context中的资源。

Ø         作用：JMX被用来对各个组件进行管理，其中包括启动、关闭、部署和移除等，当然还包括其他的一些功能，但“管理”各个组件的生命周期是其主要出发点；JNDI为了获取相应的资源或者类，来调用这个组件所提供的功能，一般是业务功能。

 

JMX中关键的地方不在JMX技术本身的使用，而在如何对系统或者平台中资源进行建模、分析和抽象，并设计出资源的Java接口视图。当然这个视图中，各个资源不是自闭的，资源之间会发生关系，例如消息的传递，资源之间的引用等。那么这要求的是软件开发或者系统开发的内功，需要长时间的历练了。