寫了幾個月的通訊中間件，再次帶領一個J2EE項目，使用WebWork、Spring、Hibernate，感覺寫J2EE項目就像在休假，要考慮的事情少之又少，無論是效率、異常處理、線程調度、架構模式，一切都不再那么重要，無需考慮那么多，只要語義清晰，溝通流暢就好了。
想起一周前跟Jerry聊天，說起因為Unixware下JDK1.3的notify語義的不穩(wěn)定問題而一天內重新編寫了三次通訊框架，最后采用了完全非框架的過程化寫法，Jerry說應該先寫出一個實現(xiàn)，然后在之上重構，就像爬山一樣，不可能一下子攀登到頂峰，當時雖然心里感覺不是這樣，但竟一時語塞，不知從何說起，再次回到J2EE開發(fā)，才恍然明白那天的感覺，框架開發(fā)和業(yè)務開發(fā)的不同就在于，很難重構，尤其是通訊框架，架構通常決定了它的幾個重要指標。
架構模式不同于設計模式，設計模式的問題可以通過重構解決，而架構模式幾乎只能重新做（當然也有例外），架構一旦確定，很多東西就無法再加入，所以為什么很多開源的J2EE框架在大版本升級后不得不拋棄向后兼容。這也是為什么國產通訊框架Cindy的作者想在其中加入FilterChain，而最終放棄的原因，因為這對基礎庫的改動實在太大。
而MINA的架構就足夠靈活，它屏蔽了不同通訊方式和通訊底層事件機制的差異，就像在如同Cindy和Netty2這種基于NIO的reactor模式之上的框架，要想重構到BIO，就幾乎要全部重寫，不過Netty2要好一些，畢竟有Netty1作為鋪墊，所以在NIO的reactor的路上走的不是很遠（NIO的reactor實現(xiàn)真是的不咋個），而MINA則只需要在SocketIoProcessor中使用Helf Sync/Helf Async模式替換掉reactor之上的事件處理即可，當然，最好還要提供線程池以便進行overload shield，在向Apache LDAP團隊提交了MINA的JDK1.3核心庫時也曾想提起該問題，可惜后太忙，忘記了。不過我想以Trustin的聰明，一定會想到這個問題。