做一个自己的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。
     其它：有可能的话加上安全和事务方面的；

评论

11 楼 javatracker 2008-12-31  

donnki 写道

我觉得写这个的唯一目的应该就是为了学习吧 既然是为了学习，尽量少用框架，多自己写。 不需要提供一个通用的服务器，也暂时不需要完整的实现，一步一步累加就好了吧？ 用IOC都可以不考虑框架，自己写个简单的实现，就像用动态代理写AOP一样

是这样的，只所以用框架的目的是先从大的方面把他搭建起来，如果全部自己写太耗时间，搭起来后如果有必要在把内部框架自己来写。另外不准备遵循J2ee规范，太庞大，有些方面，比如Jndi只部分实现就行。

10 楼 javatracker 2008-12-31  

donnki 写道

XML 解析器自己写？ 如果要写一个通用的XML解析组件估计工作量挺大啊~~如果不是通用的话要，解析的配置文件估计有很多。 对内存性能要求不高的话用apache的digester组件挺方便，Struts就是用这个来做解析器的，如果追求性能效率的话，stax应该是不错的选择。 Ioc也可以考虑下JavEE EJB3规范。上文提到的除了spring其它的IOC框架还没怎么接触过。

自己写的意思不是自己写底层，而是自己定义xml的格式，自己解析这些格式。框架还是用的，目前用的是dom4j，用的他的dom方式，sax就不必了，文件不大

9 楼 javatracker 2008-12-31  

donnki 写道

我还没来及看JBOSS源码呢，TOMCAT的就看过。 JBOSS是个完整实现JavaEE规范的东东，估计挺庞大。以前翻过一本《JBoss Administration and Development》，还没看完JBoss JMX Microkernel一章就被别的事情打断了。再加上工作没用JBOSS作服务器，所以暂时还不怎么熟。

JBoss源码我也没看多少，就看了看关键环节，还有很多我的打算是用到的时候在详细去看。《JBoss Administration and Development》我也是囫囵吞枣的看过。很多细节性的东西都没看太多，也钻不进去，所以才做这个，想在用到的时候详细研究。

8 楼 javatracker 2008-12-31  

donnki 写道

很有兴趣~~~ LZ需要打下手的不？

打下手不敢当，看了你的帖子感觉很多方面不如你，有兴趣的话聊聊一起做。

7 楼 donnki 2008-12-29  

我觉得写这个的唯一目的应该就是为了学习吧
既然是为了学习，尽量少用框架，多自己写。

不需要提供一个通用的服务器，也暂时不需要完整的实现，一步一步累加就好了吧？
用IOC都可以不考虑框架，自己写个简单的实现，就像用动态代理写AOP一样

6 楼 donnki 2008-12-29  

XML 解析器自己写？
如果要写一个通用的XML解析组件估计工作量挺大啊~~如果不是通用的话要，解析的配置文件估计有很多。
对内存性能要求不高的话用apache的digester组件挺方便，Struts就是用这个来做解析器的，如果追求性能效率的话，stax应该是不错的选择。

Ioc也可以考虑下JavEE EJB3规范。上文提到的除了spring其它的IOC框架还没怎么接触过。

5 楼 donnki 2008-12-29  

我还没来及看JBOSS源码呢，TOMCAT的就看过。
JBOSS是个完整实现JavaEE规范的东东，估计挺庞大。以前翻过一本《JBoss Administration and Development》，还没看完JBoss JMX Microkernel一章就被别的事情打断了。再加上工作没用JBOSS作服务器，所以暂时还不怎么熟。

4 楼 donnki 2008-12-29  

很有兴趣~~~
LZ需要打下手的不？

3 楼 javatracker 2008-12-21  

fondofbeyond 写道

保持关注中

感谢关注！

2 楼 javatracker 2008-12-20  

mineral 写道

IOC容器,有没有试过guice,这是一个非常轻量、非常强大的IOC container.
引用
其它：有可能的话加上安全和事务方面的； 这个feature倒是比其它的更重要，事务完整性和一致性、系统安全，在任何应用中，都是最重要的。 你的决心和勇气值得佩服。赞。

guice没试过，等下去看下，这个东西涉及的东西太多了，任何一个研究透彻就要花不少时间，我的计划是先做起来，不管用什么，后面东西一点一点的再添加完善，否则就成了纸上谈兵了。

事务和安全性确实是最重要的，但要整个要先把框架搭起来，数据走通了后再加上安全模块。事务模块准备在JDBC封装和数据调用的时候就做起来。

1 楼 mineral 2008-12-20  

IOC容器,有没有试过guice,这是一个非常轻量、非常强大的IOC container.

引用

其它：有可能的话加上安全和事务方面的；

这个feature倒是比其它的更重要，事务完整性和一致性、系统安全，在任何应用中，都是最重要的。

你的决心和勇气值得佩服。赞。