随笔 - 59, 文章 - 4, 评论 - 184, 引用 - 7
数据加载中……

重新带J2EE项目-兼谈架构模式的影响

 

写了几个月的通讯中间件,再次带领一个J2EE项目,使用WebWork、Spring、Hibernate,感觉写J2EE项目就像在休假,要考虑的事情少之又少,无论是效率、异常处理、线程调度、架构模式,一切都不再那么重要,无需考虑那么多,只要语义清晰,沟通流畅就好了。
想起一周前跟Jerry聊天,说起因为Unixware下JDK1.3的notify语义的不稳定问题而一天内重新编写了三次通讯框架,最后采用了完全非框架的过程化写法,Jerry说应该先写出一个实现,然后在之上重构,就像爬山一样,不可能一下子攀登到顶峰,当时虽然心里感觉不是这样,但竟一时语塞,不知从何说起,再次回到J2EE开发,才恍然明白那天的感觉,框架开发和业务开发的不同就在于,很难重构,尤其是通讯框架,架构通常决定了它的几个重要指标。

架构模式不同于设计模式,设计模式的问题可以通过重构解决,而架构模式几乎只能重新做(当然也有例外),架构一旦确定,很多东西就无法再加入,所以为什么很多开源的J2EE框架在大版本升级后不得不抛弃向后兼容。这也是为什么国产通讯框架Cindy的作者想在其中加入FilterChain,而最终放弃的原因,因为这对基础库的改动实在太大。

而MINA的架构就足够灵活,它屏蔽了不同通讯方式和通讯底层事件机制的差异,就像在如同Cindy和Netty2这种基于NIO的reactor模式之上的框架,要想重构到BIO,就几乎要全部重写,不过Netty2要好一些,毕竟有Netty1作为铺垫,所以在NIO的reactor的路上走的不是很远(NIO的reactor实现真是的不咋个),而MINA则只需要在SocketIoProcessor中使用Helf Sync/Helf Async模式替换掉reactor之上的事件处理即可,当然,最好还要提供线程池以便进行overload shield,在向Apache LDAP团队提交了MINA的JDK1.3核心库时也曾想提起该问题,可惜后太忙,忘记了。不过我想以Trustin的聪明,一定会想到这个问题。

posted on 2005-09-21 17:47 fisher 阅读(1492) 评论(3)  编辑  收藏 所属分类: Programing

评论

# re: 重新带J2EE项目-兼谈架构模式的影响  回复  更多评论   

呵呵,我同意你的说法,架构层次和我聊天时说的那个先实现再重构确实不太一样,架构设计中需要考虑系统的核心目标,根据此目标做出骨架式的架构设计,架构设计一旦出问题整个系统可以说已经决定了后果了,重构一般都是层次实现级的,而不是架构级
2005-09-21 19:47 | Programmer's Life

# re: 重新带J2EE项目-兼谈架构模式的影响  回复  更多评论   

本来是想说最近很轻松的,说着说着就跑题了:)
2005-09-21 20:02 | flyingbug

# re: 重新带J2EE项目-兼谈架构模式的影响  回复  更多评论   

博主,可否请教你一个问题:
我在测试中连续发大量请求,mina做的server端会出现只created连接,但之后卡在那里不继续运行,这样的问题如何解决?
[SocketAcceptorIoProcessor-0.0] INFO handler.CommunicatorServerSessionHandler - [/192.168.0.166:40775] CREATED
[SocketAcceptorIoProcessor-0.0] INFO handler.CommunicatorServerSessionHandler - [/192.168.0.166:40776] CREATED
2007-05-23 16:04 | itVincent

只有注册用户登录后才能发表评论。


网站导航: