几个问题不太明白：

1）既然已经有了spring，pico这样的container，我为什么还需要jmx进行管理呢？spring，pico也提供了一些生命周期的管理啊。jmx提供了哪些额外的功能么？

2）jmx要求业务组件要实现一些jmx相关的接口，Standard MBean, DynamicMBean 或者 ModelMBean 。这个是不是相当于对业务组件的一种侵入？那组件的移植性，可测试怎么处理？

3）对于生命周期的管理上，“工厂模式可能有很多类，这些类都没有被约束或被管理的，因此移植起来很麻烦”这句话怎么理解？移植是指什么的移植？

4）“而微容器有自己的疆界，可以实现服务端的对象约束和管理，移植方便：提起容器就走”，同上，移植是指被管理对象的移植么？如是，那什么叫提起容器就走呢？要走也不是容器走啊？

呵呵，几个愚蠢的问题，见笑。

这些问题非常好，我也准备再写文章谈与AOP关系，首先，JMX和AOP都实现了分散关注模式，或者说他们目的是一样的，只是应用的范围不一致。

JMX比较基础底层，它是JVM级别的，可以对JVM线程和内存等方面监控，而AOP则则重应用面，可以制造人为的观察方面。

画图如下：

AOP

|

|

container (J2EE)

|

|

JMX (J2SE)

正因为JMX是底层方面的，是基于J2SE的，所以第2个问题关键是对业务组件的侵入这个概念是怎么理解，例如，由于JBoss Weblogic服务器是基于JMX，你可以做一个业务组件的MBean，和这个J2EE服务器其它底层组件同时运行，当然你也可以做一个POJO在J2EE服务器的Web上或EJB上运行，前者突破了J2EE界限。

为了保证我们的应用在J2SE J2EE等各种平台运行，如果我们的应用基于微容器，在J2SE平台配以JMX（当然J2EE也可以）；在J2EE平台配以AOP等，可以实现我们业务组件自由移植；注意，业务组件是与JMX的管理组件分离的，是保存在由微容器管理的。

后面两个问题也可以自然理解了，因为业务组件是由微容器管理的，在J2SE、J2EE WEB或J2EE EJB中移植时，只要将微容器相关组件移植即可，其具体细节可从其配置文件中明确获知；而工厂模式有相关很多接口；很多工厂类实现以及围绕这些具体实现的庞大的类群，如何把这些类在J2EE WEB或EJB等平台移植，我想是一个麻烦的事情，当然，你有一个文本说明，记录工厂模式涉及的所有类，但是这个文本没有容器配置文件准确，因为它不参与运行，信息的一致性和可靠性无法确证。

所以，如果要移植微容器，只要提起微容器就可以走，在具体运行部署时，方便地在不同平台或应用系统中发布，这里走的含义是部署的概念。

谢谢banq的指点，

"注意，业务组件是与JMX的管理组件分离的，是保存在由微容器管理的"

业务组件怎么和jmx管理组件分离?我的业务组件要被jmx管理,是不是要实现一些jmx相关的接口?比如DynamicMBean,这样的化业务组件

怎么能移植到非jmx(微容器)的环境下呢?我的移植性是指业务组件(不是微容器)能否在不同的环境下运行,包括在容器里

和非容器环境,我更关注这个，应为我觉得要重用一个业务组件还要带上一个微容器及其一些无关的组件这样的代价是不是太大了?

您那篇文章中的业务组件WilmaImpl ,实现的接口是不是有点问题,根据后面的参考文献,如果是standard Mbean,要求接口以Mbean结尾.

业务组件和JMX的关系是在Groovy脚本实现的，而不是对业务组件要求这个就是要点所在，Groovy脚本是在外部编写的。

这段代码是NanoContainer上下载的，你可下载仔细研究，一起在这里讨论，前几天碰到李维先生，他在Borland 2005产品发布会上讲了JMX，我说很巧合，我在深入研究微容器，他说在台湾很多人在讨论这个，2005是对象易管理年，我比较赞同。

还有一个叫windjp的，在这里插话给删除了，删除依据是：非本主题相关；二涉及发言人本身。给他转贴到灌水版块:

http://www.jdon.com/jive/thread.jsp?forum=106&thread=18257