重新带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的聪明，一定会想到这个问题。