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