引子

之前我寫過一篇文章，討論了在XML Web Service或者WCF中，多次發起異步調用可能導致的問題，請參考http://www.cnblogs.com/chenxizhang/archive/2010/05/31/1747812.html

在這一片文章中，我介紹了問題的癥狀以及發生的原因，及其解決方法。這篇文章收到了一些反饋，其中有朋友介紹到了Hprose這個產品。我后來也實際用了一下，確實在Hprose中是可以避免這種問題的。(有興趣的朋友，可以參考這里 http://www.cnblogs.com/chenxizhang/archive/2010/05/31/1747812.html#1873774）

本著實踐和求真的精神，我也專門對Hprose這個產品也做了一些深入的探究，包括和他們的開發團隊做了一些交流。同時，因為這個產品是商業開源（與一般的開源還不太一樣），所以也引發了一些對技術和開源的思考。今天整理出來，給大家參考參考

?

什么是Hprose？

Hprose (High Performance Remote Object Service Engine) 是一個商業開源的新型輕量級跨語言跨平臺的面向對象的高性能遠程動態通訊中間件。它支持眾多語言，例如 C++, .NET, Java, Delphi, Objective-C, ActionScript, JavaScript, ASP, PHP, Python, Ruby, Perl 等語言，通過 Hprose 可以在這些語言之間實現方便且高效的互通。

Hprose 是商業開源軟件，在取得 Hprose 商業使用授權后，您可以將它用于您所擁有所有權的商業項目的開發當中，Hprose 商業使用授權沒有開發者人數、服務器CPU數量、授權年限等限制，但對二次分發有一定的特別要求。如果您所開發的項目或產品涉及到對 Hprose 的二次分發，還需要取得相應的二次分發授權。

關于Hprose的詳細介紹和有關資源，請訪問其官方網站： http://www.hprose.com

?

問答Hprose

下面記錄了我和他們的團隊幾次郵件交流討論到的幾個一些問題。取自郵件的原文，比較直白，但是原汁原味。

問：協議層面,我關心的是主要包括兩個層面：Hprose如何支持不同的傳輸協議（例如Http和Tcp或者還有更多的），以及Hprose的數據序列化格式是否有公開的規范書？

答：協議實現方面我們是這樣考慮的，通過uri來區分不同的協議，目前http://、https://開頭的是表示Http客戶端和Https客戶端，他們由HproseClient的子類HproseHttpClient來具體實現。當以后提供tcp、udp等實現后，tcp://、udp://開頭的表示TCP客戶端和UDP客戶端，他們可能會分別由HproseClient的子類HproseTcpClient和HproseUdpClient來分別實現，每個不同類型的客戶端肯定會有他們特有的屬性，并且內部通訊機制也完全不同，所以由不同的子類實現是必要的，但是它們又都是HproseClient的子類，在不需要設置特殊屬性的情況下，可以使用HproseClient來統一訪問，另外，當tcp、udp版本實現之后，我們會給HproseClient類提供一個工廠方法，通過不同協議的uri來創建不同類型的HproseClient對象不需要指定使用哪個子類，這樣就可以將不同協議的實現進行統一管理了。

【我的評論】這個做法也是可以的，采用類似于.NET中WebRequest那種工廠方法模式的設計，也能保證一定的靈活性。雖然與WCF那樣通過配置文件直接就可以改變傳輸協議（其實是所謂的binding)的做法是有些差別的。

而數據序列化協議部分，目前我們沒有公開的數據格式描述文檔，這部分我們以后可能會通過標準或者專利的形式進行發布。格式的公開不是一個簡單的問題，它有多方面的因素所制約，AMF這個格式從最初制定實施到最后公開也是花了5-6年的時間（2002-2006年制定，2007年公開發布），對于Adobe那樣的大廠商尚且如此，對于我們而言也需要慎之又慎啊。

【我的評論】可以理解

?

問：數據傳輸層面，有沒有辦法由用戶決定是否進行加密或者壓縮？

答：可以由用戶來決定加密和壓縮。目前壓縮是通過直接使用http的壓縮方式，服務器端有個IsCompressionEnabled開關，當打開這個開關后，客戶端只需要添加Accept-Encoding: gzip,deflate這個http頭，就可以開始壓縮傳輸了。不過說實話，壓縮開啟之后，數據量不夠大時，數據壓縮之后反而會增大，而且數據壓縮傳輸會對CPU消耗相當嚴重，所以我們是不推薦使用壓縮傳輸的，因此文檔中并沒有提到IsCompressionEnabled開關，也沒有說明客戶端如何開啟壓縮傳輸的方法，這樣可以避免用戶在誤用這個功能后抱怨占用太多CPU。至于用戶自定義加密傳輸，我們現在還沒有提供這個功能，一是因為https本身可以提供加密傳輸，在tcp上也可以通過tcp+ssl實現加密傳輸。因為ssl是標準的，所以要比用戶自定義的方式可靠一些。另一個原因是，加密傳輸要保證安全性需要用到密鑰交換技術，這個同樣占用大量的CPU計算時間，我們在Hprose的前身PHPRPC中提供了這個功能，但是我們發現它帶來的這個問題遠遠大于它所帶來的好處（例如黑客可以通過這一點很輕松的發起DoS攻擊，導致服務器計算資源耗盡而停止正常服務）。另外，密鑰交換本身必須是一個同步調用的過程，在實現遠程異步調用時，又要保證同步，會大大增加實現的復雜度，以及降低異步調用的效率。所以對于自定義加密方式傳輸的功能，我們目前的1.x版本中還不打算加入。當上面所說的幾個問題能夠找到有效的解決方法之后，我們會在Hprose 2.0或者Hprose 3.0中，以插件的方式來提供。

【我的評語】我們樂見這個設計的完善

?

問：是否有考慮過REST方面的支持？

答：REST相對于RPC是另外一種構架模式，Hprose提供了一種序列化機制，同時在這種序列化機制上構建了一個RPC機制。所以如果在Hprose的序列化機制上使用REST方式來構建系統也是完全可以的，但是這時候就完全不需要Hprose提供的客戶端和服務器了，只需要Hprose的IO（序列化反序列化）部分就可以了。但是REST構架最大的問題是，它沒有一個統一的標準，不能向RPC那樣可以保證接口的互通性。而且應用的范圍我認為也不應存在太大的交集，現在很多采用REST方式來提供類似Web服務功能的用法，大多都是對REST的誤用，并沒有發揮出REST本該發揮的優勢。現在的REST已經像當年的XML一樣被當成了萬能靈藥，而實際上，這已經背離了REST的本意。而Hprose既然是為RPC在XML火爆的年代中所犯下的錯誤做出的糾正，就不應該在REST火爆的年代犯下同樣的錯誤。所以即使Hprose的序列化機制確實可以用于真正的REST應用，我們也不會明確的告訴大家Hprose可以做REST服務，因為在大多數人并不能真正認識REST的年代，這樣說就是對用戶的誤導。

【我的評語】基本同意。對于REST，還是可以多從實踐的角度去辯證地看待。

?

問：OnError事件的做法存疑，如果一個client發起了多次請求（方法名也是一樣的），那么怎么區分呢

答：OnError事件確實存在您說的問題，這個問題我們在JavaScript、ActionScript、ASP這些版本中已經提供了在調用中直接提供跟調用綁定的錯誤處理回調的方式來解決了。但是C#、Java等這些版本我們在1.2版本中尚未提供這種解決方案（未提供的主要原因是用戶對這個功能沒有強烈需求）。但這個解決方案我們會在1.3版本中在所有語言中統一的。

【我的評論】這個機制還是需要完善起來，現在有用戶對這個功能有強烈要求了

?

問：身份驗證方面，我看到目前文檔的說明是可以直接改寫Http的頭，添加Authencation這個標頭。

• 我要說的是，這個部分最好有改進。目前這種做法易用性不高，會讓人生畏。ADO.NET Data Service早先就遇到這個問題，后來改進了
• 身份驗證和授權歷來都是很重要的。身份驗證本來就有標準的做法，例如給Client類型添加一個Credentials這個屬性。而授權應該可以結合自定義Attribute或者給予Url的做法可能是較為合適的
• 后續這個方面最好有一些例子

答：對于.NET版本，我們確實提供了如您所說的Credentials屬性，這個屬性我們沒有在手冊中列出（因為他在其它語言中不存在，另外，.NET的某些版本中也不支持這個屬性，例如SilverLight，這跟.NET本身有關），但是在使用時您會發現他確實存在。在服務器端授權方面，我們提供了 OnBeforeInvoke 事件，在該事件中可以對認證授權進行統一處理。我們不使用 Attribute 的原因是，我們認為 Attribute 不是一種松散耦合的解決方案，它對所發布的服務具有侵入性，我們設計的目標是，任何可以直接用于本地的方法都可以直接發布為遠程方法，而不需要對它做任何修改或修飾。這樣才可以保證，對于我們不具有源碼的類也可以無需包裝就作為遠程服務發布，并且還可以對授權做集中控制。

【我的評語】這個設計我認為還是要改進，讓用戶使用起來更加方便一些

?

問：開發工具和服務描述方面的支持

• 這個部分最好有改進。例如我看到，如果直接在瀏覽器中輸入服務的地址，會看到幾個字符。那不是一個友好的設計。你可能主要是從開發者角度看這個問題了，而不是用戶角度。
• 其實這一點可以借鑒WCF或者Web Service的wsdl做法，人家好的東西也可以吸收的

答：WSDL存在的意義在于它是上一代靜態遠程調用機制所必需的中間語言，就如同CORBA的IDL、ICE的Slice一樣。與IDL和Slice不同的是，在.NET中，WSDL是根據服務自動生成的（但是對于PHP、Python這些非.NET上運行的語言，它們無法自動生成WSDL，需要手工編寫，所以在PHP、Python等動態語言中發布WebService是相當痛苦的一件事情）。而Hprose是新一代的動態遠程調用，所以不需要WSDL這樣的中間語言。通過瀏覽器來查看Hprose的服務地址顯示的遠程方法列表雖然對用戶來說不夠友好，但是相比WSDL來說，Hprose的輸出還是簡單易懂的多。所以，我想您所說的WCF和WebService提供的用戶友好的界面應該是指的在線調試界面，而不是WSDL那個頁面吧。針對這個用戶調試界面，我們提供了忘憂草（在線試用版地址：http://www.hprose.com/nepenthes/）這樣的專業調試工具，用戶如果需要調試服務，可以直接在這個調試工具中輸入服務器地址，這樣不管用戶的服務是使用何種語言在何種平臺上發布的，都可以采用同樣的方式進行調試。而且隨著這個調試工具的升級，用戶以后可以用更加友好的界面來調試之前的服務，而不需要連同服務一起更新后才能使用新的調試界面。這都是我們為什么要采用這種分離式調試工具的原因。而您所說的WCF和WebService服務發布后的調試界面是.NET中特有的，如果用其它語言發布WebService服務，并不會得到這樣的調試界面，所以，不同語言下的WebService服務，用戶體驗會有相當大的差別，而且用.NET老版本發布的WebService服務也不可能使用新版本.NET發布WCF服務的調試界面來調試，當然這并不是微軟的錯，而恰恰這是微軟的策略，因為只有這樣才能將用戶牢牢的綁定于.NET平臺之上，并且讓用戶始終追求使用最新版本的.NET平臺開發工具，只有這樣才能保證微軟持續盈利。而我們的出發點恰恰相反，我們是要為所有平臺所有語言的用戶提供統一的用戶體驗，所以我們采用了截然不同的設計方式。

【我的評語】提供類似于WSDL這樣的服務描述（甚至有配套生成客戶端那個接口的工具）肯定是對的做法，讓用戶使用起來更加方便才是目標。統一的用戶體驗固然是沒錯的，但統一的用戶體驗不是說統一的不高的用戶體驗。

?

問：如果服務器端有兩個類，他們擁有同名方法，則它們是無法區分的。看起來是以最后注冊的類為準。這個有沒有什么可能的問題。也就是說，在Client端Invoke的時候，只是提供了functionName，而沒有辦法提供服務類的名稱。

答：你說的這個問題，我們一開始就已經考慮到了。所以我們提供了一個別名機制，如果以類（或對象）為單位發布服務，則可以為每個類（或對象）指定一個服務名成空間（該名稱空間在發布服務時會變為方法前綴），而對于以方法為單位發布服務時，則可以為每一個方法指定一個完整的別名，通過完整的別名，就可以區分在定義時名稱相同的兩個不同方法了。這部分在文檔的后面部分（客戶端部分）有比較詳細的說明。
例如您的這個例子可以這樣改寫：

??? class Program

??? {

??????? static void Main(string[] args)

??????? {

??????????? HproseHttpListenerServer svr = new HproseHttpListenerServer("http://localhost:2010/Hprose/");

??????????? svr.Methods.AddInstanceMethods(new MyService(), "s1");

??????????? svr.Methods.AddInstanceMethods(new MyService2(), "s2");

??????????? svr.Start();

??????????? Console.WriteLine("服務器已經準備就緒");

??????????? Console.Read();

??????? }

??? }

【我的評語】這是不錯的

?

問：對于開源的理解

答：我對開源的認識，大概開始于10年之前第一次接觸Linux吧。那時的Linux發展了已有10年之久，因為其開源，功能又不遜于Unix，因此許多公司都希望藉由Linux操作系統，來取代昂貴的Unix，以便在激烈的競爭中取得有利的地位，這方面的代表是RedHat、SuSE等商業化 Linux 版本。而另外一些個人或組織則為了教育科研的需要而開發了適合自己的Linux版本，這方面的代表是Slackware。還有一部分個人和組織則是為了興趣和自由的理想而開發他們自己的Linux版本，這方面的代表是Debian、Gentoo等。雖然大家做的都是Linux，但是出發點不同，因此各個產品之間當然會出現很多的差異化，以致于想要開發一個可以在所有版本Linux都能運行的程序都是一件很困難的事情。Linux陣營因此而分裂，形成了諸侯割據的局面。各諸侯之間的爭斗一直在繼續，一批死去，一批新的又起來，何時才能統一，不得而知。
而Windows自始至今都是不開源的，也正是因為這樣，Windows才保持了統一的局面，而沒有像Linux那樣四分五裂。盡管Linux陣營常常以Windows不開源為借口來打擊Windows，但是Windows的霸主地位始終沒有絲毫的動搖，相反因為Linux陣營的四分五裂，各個廠商之間各懷鬼胎，雖然勢眾，但并不能團結一致，甚至一些公司為了自己的私利，還跟微軟簽署了合作協議，例如Novell（SuSE和Mono的開發公司）。這就像蘇洵在六國論中指出的“六國破滅，非兵不利，戰不善，弊在賂秦”一樣，Linux照這樣發展下去最終必會敗于Windows系統。
Linux的開源始于對自由理想的追求，但好的理想卻常常會被惡的思想所利用，以致善始而不能善終。

?

我理解的開源是這樣的：
OpenSource != Free != No Charge
開源的目的一般分為以下幾種：
1、以自由作為理想的開源。代表為GPL開源許可。GPL的發起人Stallman是一個理想主義者，他認為軟件是自由的，一個軟件被開發出來之后，人人都可以修改它，人人都可以維護它，任何人都不可以剝奪別人修改軟件的自由。但是他的這個理想常常被人誤認為軟件必須是要免費的。也就是被誤認為 Free == No Charge，但實際上，Stallman并沒有這個意思，而且他自己也確實在通過他的自由軟件所盈利。
2、以打擊競爭對手或者潛在的競爭對手為目的并把開源貢獻者作為免費勞動力的開源，代表為Apache基金會、Mozilla基金會。Apache基金會幕后最大的支持者是IBM，IBM通過贊助Apache基金會來開發一些免費的開源項目，這些開源項目最大的特點是商業友好，也就是說，可以免費的拿來商用且不用繼續開源，Apache的開源項目作為一個試驗田，由眾多小公司拿來免費使用，在使用過程中遇到問題并不能得到任何的商業支持，只能通過自己努力來解決，解決之后在反饋給Apache組織（當然也有大部分人并不會提交自己的努力成果）。而IBM則會拿Apache的那些半成品來經過自己的優化之后，做成高端產品，再以高價賣給高端客戶。這樣，低端客戶有免費的Apache開源項目使用，雖然難用但因為不用花錢，所以就不會選擇收費的其它低端市場定位的同類商業產品，盡管那些商業產品可能要比Apache的開源項目優秀的多。而高端用戶有因為不在乎花錢，所以只買最貴的，因此IBM的產品就成了他們的首選。IBM通過這種方式有效的打擊了低端市場的同類產品，使他們無法成長為可以跟IBM叫板的競爭對手。而Mozilla基金會可以說是一個復仇組織，當它的前身Netscape被微軟的IE消滅之后，Mozilla就把打敗微軟的IE作為了首要目標，因此Mozilla的開源免費完全是為了解決掉微軟的IE。不過螳螂捕蟬，黃雀在后，Mozilla經過這么多年的發展，雖然終于可以爭取到一點IE的市場份額了，沒想到Google的Chrome也進入了瀏覽器競爭市場，面對這兩大高手，Mozilla要翻身恐怕是很難了。
3、為了讓客戶放心使用而開源。代表是微軟和Hprose。微軟現在有很多產品會對某些要求查看源碼的客戶開源，比如某些國家的政府，這種開源僅僅是為了讓客戶放心使用，證明自己沒有留下什么后門。Hprose的開源也是類似的想法，對客戶開源，讓客戶放心使用，當然如果客戶遇到問題，因為手中有源碼，也可以更容易的反饋錯誤，我們就可以更快的完成錯誤修正。所以，這種開源方式是一種雙贏的做法。
4、盲目開源。代表是Sun。他在IBM的慫恿下，把Java開源了，最后IBM搞出了自己的JVM，賺翻了。而Sun自己一分錢沒賺到，最后把自己公司都搭了進去，以致于最后落了個被Oracle收購的下場。

【我的評語】對于開源向來大家理解都不一，上述總結比較中肯。我個人也贊同：開源不等于免費

?

問：那個PHPRPC開源，你怎么評價？

PHPRPC 現在是以GPL形式開源的，也就是說，它也是一個理想主義的產物，任何人都可以得到它，修改它，使用它，卻不能獨自擁有它，不能將它私有化。實際上PHPRPC也是我們的一個產品，但是它只能用于同樣采用GPL發布的項目中，我們對它也提供收費的商業支持，但實際上，你知道的，我們根本不可能在這方面得到一分錢的收入，因為在國內，只有理想是不能養活一個公司的，甚至連個人都不能養活。呵呵。但是既然已經做了，就讓它繼續下去吧，只要它還活著，就代表我們還有理想，我們還在奮斗！

【我的評語】為理想和奮斗者而鼓掌

?

最后，我還是要表達我對Hprose的整體評價：

我對Hprose的構想和設計比較贊許，跨平臺跨語言支持當然是很多程序員乃至CTO們孜孜以求的目標。而Hprose在實踐這樣的目標，這最起碼是值得我們學習并且為之歡欣鼓舞的。希望這個產品能精益求精，做得更好，并且能得到更多人的了解和使用。

對于Hprose團隊的創造性工作和認真態度，我是頗感欣賞的。希望他們能堅持理想，實現理想。對于開源，經常有人感概說，看似很好，但實踐起來卻殊為不易，我自己也深以為然。從這方面而言，更應該贏得我們的敬意和支持。

?

?

【備注】以上言論均代表個人意見，如有雷同，純屬巧合

總結

以上是生活随笔為你收集整理的《实践与思考》系列连载（5）——问答Hprose，以及关于技术与开源的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。