使用JMX开发组件体系结构

Sun开发Java管理扩展(JMX)已经有几个年头了，以前被称作JMAPI,近来随着和J2EE管理平台的结合，已经成为J2EE服务器的一个基本构架。
   JMX 允许集中管理那些被管理的beans又称MBeans,这些beans可以是分布式网络里的应用程序，组件，资源等。这个功能是由一个称作MBean服务 器提供的，所有的MBeans都通过这个服务器来注册，并且开放被管理的接口。另外，JMX还包含了一个叫做m-let的服务，此服务还允许通过网络动态 加载Mbeans。在JMX的体系模型中，MBean服务器是所有插入服务组件的核心，而且可以通过Mbean服务器的通知机制来发现其他的 MBeans.
    MBean服务器本身是轻量的，因此一些最主要的基本服务器结构被作为MBeans模型，加入到Mbean服务器的核心， 比如：协议适配器就是Mbeans的一个实现，他们可以通过网络，接收来自不同网络协议(象SNMP,WBEM）的客户端请求，也可以使用工具来管理基于 JMX的服务器，这些工具可以用任何编程语言来开发。所以这是一个及其模块化的服务器体系，并且通过一些不同类型的工具，很容易来管理和配置这样的服务 器。

为什么JMX对应企业级的java开发者来说，那么重要？

    作为一个企 业级的java开发者， 你可能很好奇企业应该怎样使用以及在那里应用JMX。JMX和MBeans技术有助于服务器的开发，从这个角度看，他们对开发者的影响比较少。但是还是有 很多理由让你来创建你自己的MBeans.让我们先看看服务器定制和启动的类。
   每类应用服务器都会提供了一个不同的私有接口，以方便加入自定义的类，有时候又称“启动类”，在服务器还没有进入到J2EE模式的时候，他们常常被用来执行一些任务：
资 源的初始化；增加维护和监视的功能；调用和安排批处理等。这种服务器类的问题是他们完全使用私有接口把自身加载到服务器的启动序列里边，这样使你的应用直 接和特定J2EE厂商绑定在一起了。这种应用和服务器启动类的高耦合让你丧失了J2EE可移植行的好处，如果要改变你的应用服务器，将变得更昂贵，更困 难。
    对于上述问题，JMX体系提供了一个清晰解决方法。既然MBean服务器和注册已经被JMX的规范定义，那么任何兼容的MBean 都 可以注册到兼容的MBean服务器。这样对于一个实现了JMX及其标准的扩展接口的应用服务器来说，既然MBeans是可移植的，那么基于JMX的应用服 务器也增加了你应用的可移植行，你将也不需要再依赖于私有的服务器接口了。

使管理更加容易
    基于JMX服务器的另一个好处是可以在运行时管理自定义的组件，那意味着你可以利用通用的管理工具的优势，也包括应用服务器提供商所提供的那些。这样你再也不用被淹没在不断增长的很难管理的配置文件当中了。
    假设一个应用必须每天收集数据库的总结信息，并且把信息发送到预定的email地址去，由于J2EE模型没有定义定时器，并且不允许组件去管理系统资源如 线程等，作为程序员只能使用附属于此服务器的自定义类来完成这样的功能。为了能够使应用依旧能够移植，程序员可以为这个应用创建一个MBean，并且加入 到JMX MBean服务器中。
   标准的MBean阐述那些可管理的属性和操作(方法).例如上面的例子，可能就有一个操作来设置数据库总 结 和e-mail通知间隔的信息。通过在MBean的接口里暴露这样的操作，开发者才有可能让管理员在运行时改变通知的间隔。再也不需要编辑累赘的，难懂的 配置文件，也不需要为了使修改生效而重新启动服务器。
   为了便于开发通用的可管理接口，标准的MBeans的属性和操作有和 JavaBeans相似的命名习惯。管理员可以显示和调用被暴露出来的操作和属性通过web浏览器。例如Sun的JMX 参考实现就实现了一个web客户 端接口。在管理方面，只要MBean的开发者暴露出可被使用的属性和操作，那么当你添加新的自定义组件到你的服务器，当他可以运行时，
那些组件就会在客户接口中自动有效。这是一项很有用的特征。
   目前正在进行的工作是在Sun社区去定义一个J2EE管理的标准模型(JSR77).这些专家的目标之一就是有一个单一的管理工具来管理多个实现J2EE平台的厂商。JMX使满足这个需求的一个途径。

组件式服务器体系的好处

    J2EE 平台是基于服务的。在J2EE领域里有许多API是为了适配CORBA服务的。看起来使用JMX服务器集成和管理所有的平台服务是很自然的事。比如：如果 你需要在嵌入式应用中加快容器的响应时间或小范围覆盖区(small footprints)，你可以安装非钝化的缓存或开启持久引擎。如果你象要通过一 个ASP应用来按照要求配置容器，并且客户自己登录来配置，那么你可以通过使用m-let动态组件来加载服务。
   大多数的商业开发者面对令 人 畏惧的开发和集成所有J2EE所有部件的任务，一些服务器，如Weblogic就是采用这种单块式的做法(monolithic way).JBoss作 为开源的服务器，采用的式另外一种不同的做法，是在服务器端把不同模块作为JMX MBeans集成起来。这样很容易通过混合匹配的方式把J2EE装配起 来，即使是相互独立的模块。
JBoss作为一个开发平台充分利用了JMX的语义，并且通过JMX的集成提供一个完整的J2EE平台。MBeans包装了最基本的J2EE服务：Servlet,JSP,EJB,O/R,Naming,JTS/JTA,JMS,SOAP和其他第三方的模块。
   JBoss并没有把JMX限制在管理方面，他还把JMX作为自动集成开源工具的一种手段。
通 过完全的模块化，JBoss开拓了下一代J2EE服务器的JMX体系结构。对其他的J2EE厂商想要做到同样易用，动态配置，他们也必须按照JMX体系来 做，而不是仅仅提供一个管理接口。对基于服务的框架来说，JMX是一种自然的体系结构，而且也是唯一能够在运行和开发提供明确管理的手段。

模块化在开源产品中不断增长
     模块化在开源中不仅仅是一个好的主意，而且也是项目成熟的一种方法。成功的开源项目通常由大量的参与者来测量 (measured).一般来说紧密团结的核心团队开发核心的功能，但是随着基础代码的增长，也允许大量的开发者在核心模块基础上开发。
   JBoss1.0 快要完成的时候，核心的开发人员很快就得出这样一个结论：对于一个偶然（陌生）的开发者来说，很难参与进来，并且没有一个周的培训，很难有所作为的。一个 人参与开发之前，将不得不花费至少一个周的时间来熟悉代码。这种状态是第二代开源项目的特征：大量的开发人员象参与，但是只要极少数的人能作一些实质的事 情。
    在第三次的迭代中，JBoss采用了JMX。在一个周之内，一个基于SOAP调用接口就被提交到了JBoss开发组。开源的开发 和管理需要模块化。JMX是在设计时考虑实施模块化的一种自然方式。从产品的增长和服务组件的易集成来看，JBoss和JMX是成功的。

 http://blog.csdn.net/lovec/archive/2004/07/14/37658.aspx