做一个自己的AppServer－JDStream(二) 选型

JBoss4及其以前的版本主要是用JMX做为系统总线来管理插件，好处是显而易见的，可是随着IOC的发展，JMX作为容器插件也有很多不足，比如JMX作为容器过于复杂，与业务程序耦合过多，不够POJO，所以JBoss5有所改进，它用JBoss Microcontainer作为IOC插件容器，同时通过JMXKernel将JBoss4的内核连接进来，把本属于JMX管理的bean的生命周期委托给Microcontainer管理，但由于JBoss过于庞大，并没有从根本上解决问题，Microcontainer虽然从内在上管理了Bean的生命周期，但很多插件外壳还是由JMX来管理的，需要构建mbean，和Jboss过于耦合。
所以JDStream采用IOC完全管理插件，但又不像Spring那样托管所有Bean，它只需要管理插件入口的Bean，方便拆卸同时又不会产生很多烦人的配置，另外还需要管理业务代码中的一些Bean。JMX作为插件和业务模块的配置和监控容器，尽量减少它的使用。
由此IOC框架和JMX实现作为两个最基础的框架需要优先考虑，此次构建JDStream的最大目的在于磨练技术，不需要一切从头来，这两个框架都采用开源的，在需要的时候对他们进行扩展甚至修改。
IOC框架可供选择的大概有下面几个：Spring、Jboss MicroContainer、PicoContainer和JFox。
Spring过于庞大，更适合做外层框架，不太适合将它集成到别的程序里面；
JBoss MicroContainer从使用上来说是个比较不错的IOC容器，轻量且有多级生命周期策略，控制比较细致，但作为单独的IOC容器，在06年的时候已经停止开发维护了，JBoss5嵌入的MicroContainer在原先的基础上有了很大的扩展，同时和JBoss5的程序耦合在了一起，很难分离出来，所以不太合适；
JFox的IOC容器同样和框架耦合在了一起，同时也过于简单，用起来可能要做很多扩展；
PicoContainer短小精悍，生命周期虽然只有start、stop和dispose，但基本够用，如真不够使用可随时扩展，最新的版本增加了monitor，可实现对bean的监控，唯一问题是它没有XML解析器；
综上所述，决定采用PicoContainer作为IOC容器，XML解析器自己写。
JMX实现比较了JBoss的实现、JFox实现和MX4J后决定用MX4J，这个主要是前两个很多实现是为自己的框架定做的，而MX4J作为一个独立的JMX实现比较符合需要。
两个基础框架定下来后下面就是要集成的插件了：
JNDI：自己实现，以便于集群；
AOP：自己用动态代理和CGLib写个简单点的；
数据源模块：自己封装JDBC，支持事务；
socket：集成mina；
JMS：用JCA集成Activemq，支持事务；
Webservice：集成axis2或xfire，没想好呢；
cache：集成memcached java客户端和BerkeleyDB java版；
任务调度：集成quartz；
rmi：修改公司的rmi异步调用框架，提供同步和异步RMI工厂，支持JRMP和IIOP；
监控：集成telnet监控，通过telnet来和JDStream交互，了解服务器运行状况；
httpServer:集成tomcat或jetty；
camel：还没了解太清除，有可能的话也集成；
集群：用JGroups，关联到JNDI、socket、JMS、webService、cache和rmi插件，也是个基础插件；
线程池：鉴于业务模块的热部署，线程将被集中管理；
业务模块部署器:实现业务模块的动态加载，Annotation解析；
Annotation解析器：支持自定义Annotation。
其它：有可能的话加上安全和事务方面的；