做一个自己的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。
其它：有可能的话加上安全和事务方面的；
你的决心和勇气值得佩服。赞。
5 楼 donnki 2008-12-29 我还没来及看JBOSS源码呢，TOMCAT的就看过。
JBOSS是个完整实现JavaEE规范的东东，估计挺庞大。以前翻过一本《JBoss Administration and Development》，还没看完JBoss JMX Microkernel一章就被别的事情打断了。再加上工作没用JBOSS作服务器，所以暂时还不怎么熟。 6 楼 donnki 2008-12-29 XML 解析器自己写？
如果要写一个通用的XML解析组件估计工作量挺大啊~~如果不是通用的话要，解析的配置文件估计有很多。
对内存性能要求不高的话用apache的digester组件挺方便，Struts就是用这个来做解析器的，如果追求性能效率的话，stax应该是不错的选择。
Ioc也可以考虑下JavEE EJB3规范。上文提到的除了spring其它的IOC框架还没怎么接触过。 7 楼 donnki 2008-12-29 我觉得写这个的唯一目的应该就是为了学习吧
既然是为了学习，尽量少用框架，多自己写。
不需要提供一个通用的服务器，也暂时不需要完整的实现，一步一步累加就好了吧？
用IOC都可以不考虑框架，自己写个简单的实现，就像用动态代理写AOP一样 8 楼 javatracker 2008-12-31 donnki 写道
很有兴趣~~~ LZ需要打下手的不？
打下手不敢当，看了你的帖子感觉很多方面不如你，有兴趣的话聊聊一起做。 9 楼 javatracker 2008-12-31 donnki 写道
我还没来及看JBOSS源码呢，TOMCAT的就看过。 JBOSS是个完整实现JavaEE规范的东东，估计挺庞大。以前翻过一本《JBoss Administration and Development》，还没看完JBoss JMX Microkernel一章就被别的事情打断了。再加上工作没用JBOSS作服务器，所以暂时还不怎么熟。
JBoss源码我也没看多少，就看了看关键环节，还有很多我的打算是用到的时候在详细去看。《JBoss Administration and Development》我也是囫囵吞枣的看过。很多细节性的东西都没看太多，也钻不进去，所以才做这个，想在用到的时候详细研究。 10 楼 javatracker 2008-12-31 donnki 写道
XML 解析器自己写？ 如果要写一个通用的XML解析组件估计工作量挺大啊~~如果不是通用的话要，解析的配置文件估计有很多。 对内存性能要求不高的话用apache的digester组件挺方便，Struts就是用这个来做解析器的，如果追求性能效率的话，stax应该是不错的选择。 Ioc也可以考虑下JavEE EJB3规范。上文提到的除了spring其它的IOC框架还没怎么接触过。
自己写的意思不是自己写底层，而是自己定义xml的格式，自己解析这些格式。框架还是用的，目前用的是dom4j，用的他的dom方式，sax就不必了，文件不大 11 楼 javatracker 2008-12-31 donnki 写道
我觉得写这个的唯一目的应该就是为了学习吧 既然是为了学习，尽量少用框架，多自己写。 不需要提供一个通用的服务器，也暂时不需要完整的实现，一步一步累加就好了吧？ 用IOC都可以不考虑框架，自己写个简单的实现，就像用动态代理写AOP一样
是这样的，只所以用框架的目的是先从大的方面把他搭建起来，如果全部自己写太耗时间，搭起来后如果有必要在把内部框架自己来写。另外不准备遵循J2ee规范，太庞大，有些方面，比如Jndi只部分实现就行。