2009-05-08 13:34
假如冬夜，一個旅人，要開發(fā)一個美好的Java后臺服務(wù)器。所謂美好，就是要高性能，千萬級的用戶；高可靠性，failover雖死猶生；高擴展性，跟周圍那幫Tuxedo，IBM MQ，WebService的鄰居要好好打交道。這是個毫無個性，幾乎每次都一樣的需求。Java的開源世界為那些心里不安的設(shè)計師們，準(zhǔn)備了MINA、CXF、Mule和JBoss/Geronimo。
1、
MINA 一個優(yōu)秀的NIO框架。ACE式的NIO和線程模型，filter chains機制，IO層與protocol層的分離，設(shè)計師們可以依賴著開發(fā)高性能的自定義協(xié)議TCP/IP服務(wù)器。其他框架：
Grizzly，脫胎于
Glassfish的NIO框架，性能好像比MINA還好一點。
2、
CXF 前身就是XFire，一個完整的Web Service Framework：
HTTP, JMS, and Jabber 的Transports
SOAP, REST and Corba的Binding
JAXB 2.0、 XML Beans、Castor and JiBX的DataBinding
Support JAX-WS2.0、CORBA，SCA與JBI
可以部署在：
Standalone java server
Tomcat or Spring-based 的輕量級容器
Weblogic、WebSphere、JBoss的J2EE容器
ServiceMix，OpenESB的JBI容器
Tuscany的SCA容器
設(shè)計師們可以學(xué)習(xí)它眼花繚亂的機制，從一個Stand alone，ad Hoc協(xié)議的服務(wù)器，開始支持更多更公共的endpoint，也把自己作為一個Module，部署到更大更穩(wěn)健的服務(wù)器之中。
3、
Mule 作為Enterprise Service Bus (ESB) and Messaging broker，能力就夸張了：
可插入的連接方式 such as WebService，JMS , VM (embedded), JDBC, TCP, UDP, multicast, http, servlet, SMTP, POP3, file, XMPP.
同步，異步，request-response的請求模式。
Client/Server, Peer-to-Peer, ESB的拓撲模式。
大量的Routing，Transform選擇
Enterprise Integration Patterns的遵循者。
SEDA processing model的高性能模式。
Spring，
BPM的整合。
面對這樣一個誘人的ESB方案，看起來比前面的CXF模式更加合適，那如何應(yīng)用？和業(yè)界一樣的躊躇。
4、
JBoss /
Geronimo 地球人都知道這是兩個應(yīng)用服務(wù)器，特別在于，它們都有某種良好的插件機制，將EJB Container，Servlet Container，JMS 模塊作為Module部署到服務(wù)器中，成為服務(wù)器的一種能力。 JBoss的每個Service就是一個MBean，配合一個service描述文件。Geronimo更是著名的以GBean作為底層架構(gòu)，跑馬圈地的把開源社區(qū)的方案集合在repository目錄中，玩票式的組成了一個通過J2EE 1.4認證的應(yīng)用服務(wù)器。我們自寫的服務(wù)，可不可以也通過相同的機制，嵌入到JBoss/Geronimo之中，從而直接擁有了應(yīng)用服務(wù)器的其他一切能力，就像把Tomcat建于JBoss MicroKernel之上，擁有JBossJTA，JBoss Cache能力的JBoss Web？ Labourey說：“Microkernel 是JBoss 的心臟?，F(xiàn)在有許多電訊公司使用Microkernel ，用作其服務(wù)器應(yīng)用軟件的基礎(chǔ)”看來自己并沒有發(fā)明創(chuàng)造:( 其他服務(wù)器：
Glassfish5.世界的其他角落
Tuscany SCA 的開源實現(xiàn)，IBM與BEA聯(lián)手貢獻。
Esper Event-Driven Application Servers。
GridGain 開源網(wǎng)格計算平臺，集成Spring,JBoss。
6.小結(jié) MINA提供了工具，Mule/JBoss/Geronimo提供了容器， CXF/Mule提供了模式，而這些都還僅是Java開源社區(qū)的冰山一角，回望那個只有ICE和ACE/TAO的孤寂世界.......
二、開動：
1、入門文檔
MINA Presentation MaterialsCXF Architecture GuideMule Developers Guide、
MuleCon 2007Geronimo ArchitectureThe JBoss 4 Application Server Guide2、閱讀代碼 閱讀只是為了發(fā)掘文檔里沒有描述的架構(gòu)與模式，而其實很多模式在代碼里都很顯眼，來來去去就那幾道斧子，所以有了快速略讀的可能，而不是Apache源碼閱讀式的愚公移山，精衛(wèi)填海。
設(shè)計美好的服務(wù)器系列文章：
設(shè)計一個美好的服務(wù)器--MINA、CXF、Mule、JBoss/Geronimo設(shè)計美好的服務(wù)器II--站在JBoss MicroKernel上輕的，誰都會寫的Service方案--REST與JSON設(shè)計美好的服務(wù)器(4)--Mule ESB筆記Grizzly介紹聲明：任何人轉(zhuǎn)載或引用該問必須保持該文章的鏈接。必須以超鏈接的形式標(biāo)明文章的作者和出處。 聲明：本文參考自
https://grizzly.dev.java.net/presentations/FISL-2007.pdf。
1、介紹Grizzly：Grizzly是一種應(yīng)用程序框架，專門解決編寫成千上萬用戶訪問服務(wù)器時候產(chǎn)生的各種問題。 2、什么是Grizzly？ 使用JAVA NIO作為基礎(chǔ)，并隱藏其編程的復(fù)雜性。容易使用的高性能的API。帶來非阻塞socketd到協(xié)議處理層。利用高性能的緩沖和緩沖管理使用高性能的線程池。3、Grizzly與Mina的性能比較：比較結(jié)果Grizzly比Mina更好。 4、Grizzly的HTTP性能：支持的并發(fā)客戶端：平均響應(yīng)時間：8S 90%時間在3S內(nèi)出錯率在0.1%以下。5、Grizzly的歷史：在GlassFish項目中于2004年誕生。后來為Grizzly 1.0。 Grizzly1.0跟Sun Java System Application Server8.1，8.2和所有的GlassFish版本。用來代替本地的Sun WebServer運行時。開始目的是建構(gòu)一個HTTP Web服務(wù)器，用來代替Tomcat的Coyote連接器和Sun WebServ er6.1。 Grizzly1.0在2006年的時候變得相當(dāng)流行。多數(shù)協(xié)議實現(xiàn)都基于它。但是Grizzly1.0有HTTP協(xié)議的特定實現(xiàn)邏輯包含在傳送層中。主要類SelectorThread包含若干的HTTP的處理，如文件cache，請求監(jiān)控等。為了使用框架，需要擴展SelectorThread，例如JettySelectorThread，SSLSelectorThread。 Grizzly1.0混合了擴展和實現(xiàn)。 雖然如此，但Grizzly1.0仍然是很好的實現(xiàn)，有下面幾個協(xié)議利用了Grizzly1.0： JRuby On Grizzly ；Alaska的HTTP BC組件 ；GlassFishV3的微內(nèi)核 ；Phobos GlassFish的SOAP ； Comet、Cometd ；AsyncWeb ；GlassFishV2 ；Sun Web2.0 Developer pack(REST Http Server) 。Grizzly1.5于2006年開始開發(fā)。Grizzly1.5的目標(biāo)： 1，刪除所有的HTTP或者GlassFish的依賴；2， 所有1.0的應(yīng)用仍能在1.5上工作；3， 支持Grizzly1.0時候的性能優(yōu)化。4， 不依賴于任何的第三方軟件。 2007年2月6日Grizzly開源了。 6、控制器： Controller是主要的進入點，Controller由下面部分構(gòu)成： SelectorHandler； SelectionKeyHandler； ProtocolChainInstanceHandler ；ProtocolChain 。Pipeline 這些組件在Grizzly框架中都是可以配置的。 7、SelectorHandler ： SelectorHandler處理所有的nio。channel。Selector操作?？梢蕴幚?個或多個的Selector。 8、SelectionKeyHandler ：用來處理SelectionKey的生命周期。例如取消，注冊，或者關(guān)閉SelectionKeys由SelectionKeyHandler來處理。 9、InstanceHandler： InstanceHandler用來創(chuàng)建或者緩沖幾個ProtocolChain。 InstanceHandler決定有狀態(tài)或者無狀態(tài)的協(xié)議鏈?zhǔn)欠裥枰粍?chuàng)建。注意：InstanceHandler重命名為ProtocolChainInstanceHandler。 10、Pipeline ：一個接口用來封裝各種線程池。 Grizzly1.5包含了幾個的管道的實現(xiàn)。最佳性能實現(xiàn)的管道是默認配置的管道。 11、ProtocolChain ：協(xié)議鏈實現(xiàn)責(zé)任鏈模式。協(xié)議鏈由若干的協(xié)議過濾器組合成。注意：協(xié)議連的所有者必須調(diào)用postExecute()方法。 12、ProtocolFilter ：協(xié)議過濾器由兩個方法構(gòu)成：execute和postExecute。 Context包含了動態(tài)的計算狀態(tài)。協(xié)議過濾器封裝了一個將要工作的單元。目的是檢查或修改狀態(tài)的改變。 獨立的協(xié)議鏈可以被集成到協(xié)議鏈。 當(dāng)使用默認的協(xié)議鏈的時候，協(xié)議過濾器應(yīng)該設(shè)計成線程安全的。通常，這表示協(xié)議過濾器應(yīng)該不包含維護狀態(tài)信息。 維護狀態(tài)信息應(yīng)該由ProtocolContext來維護，并通過method和postExecute來傳遞。 14、誰在使用Grizzly？—— Jetty ，Alaska ，Tango ，Jruby on Grizzly ，php on Grizzly ，Ning ，Comet、Cometd 。15、誰在尋找或投資Grizzly？—— Sun Java System Message Queue ；Sun JDK ORB； GlassFish ORB； Derby、JavaDB 等。
http://blog.csdn.net/zhangliulin/archive/2007/10/16/1826708.aspx 一個NIO框架——Cindy簡介
Cindy簡介 （作者Blog:
http://spaces.msn.com/members/crmky）
Cindy是一個基于java nio的I/O框架，支持TCP/UDP單播/UDP多播/Pipe，為應(yīng)用程序提供了一個統(tǒng)一的接口去實現(xiàn)異步和同步的網(wǎng)絡(luò)操作。
java io包提供了一個簡單的模型去處理網(wǎng)絡(luò)流，它讀寫均為阻塞操作，在一般的應(yīng)用里，用戶總是開啟一個獨立線程或一個線程池去處理這些IO操作。它非常簡單易用，但在擴展性和效率上存在著一些問題。如果用戶只需要一兩個網(wǎng)絡(luò)連接，開啟幾個獨立線程操作無傷大雅，但是如果面對服務(wù)器端的成百上千個連接，采用java io提供的機制，就需要同時開啟成百上千個線程，即使能夠處理過來，花在線程上下文切換的時間也遠遠多于網(wǎng)絡(luò)操作的用時。
在JDK 1.4中，Java引入了nio包，除開nio提供的一些其他功能外，最吸引人的就是引入了非阻塞IO的實現(xiàn)。但是直接使用nio中非阻塞I/O需要處理眾多異常，維護狀態(tài)，為應(yīng)用帶來不必要的復(fù)雜性。并且JDK 1.4中的nio包只實現(xiàn)了普通TCP/UDP單播/Pipe，JDK 5.0中引入了SSLEngine類，使得基于非阻塞I/O的TCP可以支持SSL和TLS，未來在JDK 6.0才會加入對非阻塞I/O UDP多播的實現(xiàn)。如果應(yīng)用程序只想使用同一個模型去操作網(wǎng)絡(luò)I/O，而不想關(guān)心這些諸多限制，那么Cindy是一個很好的選擇。
目前基于nio的開源I/O框架很多，Cindy并不是唯一的選擇，比較好實現(xiàn)如Netty2、MINA等等。由于是Cindy的作者，對Cindy的了解程度要高于對其他框架的了解程度，這里所做的比較只是基于作者自身的看法，可能會有失偏頗。在你進行選擇之前，你應(yīng)該從你自身應(yīng)用的角度進行仔細的比較。
Netty2具有很好的構(gòu)架，并且該框架非常有名，使用該框架的項目不少，這意味著開發(fā)團隊持續(xù)更新的動力非常大（BTW，剛知道Netty2的開發(fā)已經(jīng)停止了，抱歉）。同時Netty2的文檔非常齊全，并且支持JMX（這是我不熟悉的領(lǐng)域，不做評論）。Netty2的缺點就是實現(xiàn)代碼的質(zhì)量不是非常好，最大的缺點就是只支持普通的TCP。
MINA是Netty2作者的一個新項目，該項目目前實現(xiàn)的版本已經(jīng)支持TCP/UDP/Pipe，并且由它的Roadmap上可得知將來會加入對JMX和容器的支持。我未曾使用過該項目，不過既然是Netty2作者的新項目，應(yīng)該也吸收了Netty2的優(yōu)點，并且對Netty2中的缺點做了改良。從該項目帶的Example來看，使用起來應(yīng)該是非常簡單的。
Cindy起源于Netty2之后，借鑒了Netty2中MessageRecognizer類的設(shè)計，在當(dāng)前的版本中已經(jīng)全面支持普通TCP/Secure TCP/UDP單播/UDP多播/Pipe，可以使用同一個模型進行同步/異步IO處理，并且成功的應(yīng)用在JML項目中（Java Msn Messenger Library，開源項目，目前發(fā)布的版本基于Cindy老的版本），并且在目前公司的項目中也有實際使用。Cindy目前并不打算加入對JMX的支持（不熟悉），也沒有計劃加入對容器的支持（這個應(yīng)該是應(yīng)用做的事情），我想保持Cindy核心的簡潔和高效，最好能夠代替Socket/DatagramSocket的地位（簡單應(yīng)用的話也許還是使用這個更好：））。Cindy目前缺點是文檔相對較少以及應(yīng)用的項目比較少，希望這幾篇文檔能夠稍微彌補以下Cindy在這文檔方面的不足。
Cindy：
http://cindy.sourceforge.netNetty2：
http://gleamynode.net/dev/MINA：
http://www.apache.org/~trustin/mina-20050207/index.html
