2005新趋向：微容器和对象的易管理性

几个问题不太明白：
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

我又仔细考虑了一下3dwizard的疑问，重用组件是否需要带个微容器？

我的思考历程是这样：开始我认为只要做个框架就可以，可以重用一些功能，这也是JdonSD框架的最初样子，但是，当我将更多功能加入这个框架，特别是Cache功能，框架中因此有一些状态，也就是说，框架已经深入融合在应用系统的运行中了，这时我要注意状态的管理，这不是一件容易的事情，使用有生命周期的微容器则是个好的解决方式，这是促使我引入微容器的原因之一。

还有一个重要原因，现在各种框架平台很多，如何保持我的业务核心脱离不依赖这些框架平台，那么只有一个办法，就是让我的业务核心依赖我自己设计的框架和容器，这样随着技术发展，我只要更新我的框架/容器即可，而保护了业务核心的修改。

想一想，如果你使用Spring容器，那么你的业务核心或多或少和Spring相关，当然，我的容器是基于Picocontainer，那么也就是形成对picocontainer依赖了，是的，我认为这个依赖是在我可控制范围的，因为picocontainer代码很少，我基本能搞明白，Spring因为整入东西太多，比较琐碎。当然我这里体现了所谓微、轻量的最本质的目的。

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

这是要点所在，我当时在NanoContainer CVS上看到WilmaImpl代码也感到奇怪，为什么没有standard Mbean接口？我觉得不会有问题，就是这样的。

我开始明白banq的意思了，我先去下载nano看看。
BTW：spring也已经可以支持整合jmx了，只是现在的jmx相关代码只能从cvs上得到，正式release要等到1.2版本正式发布。
相关的连接
由上面的资料看来，spring的jmx整合功能对业务组件几乎无侵入，这正式我希望的。

我开始明白banq的意思了，我先去下载nano看看。
BTW：spring也已经可以支持整合jmx了，只是现在的jmx相关代码只能从cvs上得到，正式release要等到1.2版本正式发布。
相关的连接
由上面的资料看来，spring的jmx整合功能对业务组件几乎无侵入，这正式我希望的。

spring+jmx相关的链接：http://opensource.atlassian.com/confluence/spring/display/DOC/Spring+JMX

看了banq的解释很有收获，对一些框架和模式的应用好像又有一些更深刻的看法，JMX和AOP都实现了分散关注模式，或者说他们目的是一样的，只是应用的范围不一致，我十分赞成。很多人使用AOP很习惯脱离业务的需求导致使用AOP的出现一些好像更麻烦或更难控制了，可读性更差了，这是因为没有真正的认识到AOP的是已经比IOC,JMX从根本上就天生具有了广度的抽象。个人认为使用AOP技术可以认为它是SOA的关键实现技术，而JMX是实现中间件或MDA还有构件编程关键技术，例如可以使用AOP的特点可以把业务功能包封装层接口，然后业务的钳套还有业务的切入进行AOP的过程，同时如果要使用JMX或IOC的技术那么他们可以应用到每一个功能包的类里面。如果这一种场景就可以比较好的处理在系统的作用域了。当然并不是就一定要这样做，但是个人经历过失败的经验觉得这是比较合理的安排。如果有什么不对请指出。

JMX的MBean据我了解有不少架构选择，因为除了EJB之外就没有可管理的组件框架选择了，所以，对于特殊要求，EJB不能完成的，大家只能去选择JMX架构，我曾经大力抨击过，但是自己也一下提不出方案。

现在好了，Ioc出来后，picocontainer、Spring /Jdon Framework都能够弥补这种缺失。Ioc容器和JMX结合可以产生除EJB以外更灵活的组件架构选择。

下面这个案例就是这样一个架构设计案例：
JBOSS 做项目时的问题 有关Jboss, Mbean, Session bean 求助:

http://www.jdon.com/jive/thread.jsp?forum=16&thread=24362