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