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