??? 摘? 要： 探討了使用C++部署網格服務的幾種方案，分析了各種可能的框架的調用等待時間、可擴展性和可靠性。使用不同的部署框架得到的最終結果在性能上有很大差異。
??? 關鍵詞： 網格服務? C++? 調用時間? 性能評價

?

??? 網格計算的出現引發了分布式領域的多個計算標準和架構的出現（如Globus、Legion等），它們都致力于為網格應用程序和服務提供一個穩定的環境^[1]。由于Java語言的許多特性非常適合于目標環境，所以大多數架構是基于Java開發的。但是，有些情況下使用Java并不適宜。一個眾所周知的問題就是性能^[2]。此外，還有一個問題是原有的C++程序需要重新編寫才能夠在新的體系結構下運行，由于經常出現程序邏輯和服務部署的語言不一致，所以用Java重寫通常來說不是一個最佳選擇。
??? 本文研究了現有的、允許部署C++程序作為網格服務的所有框架，在每種框架上都部署了一系列簡單的服務并測試了每種情況下的等待時間和可擴展性。試驗結果說明網格服務平臺架構的選擇對于最終網格服務的性能有著很大的影響。
1? 網格體系結構介紹
1.1 網格服務標準
??? OGSA(Open Grid Services Architecture)的創建是為了滿足網格在分布、異構的動態環境下整合服務的需要。OGSA只定義了架構，沒有給出實現。有兩種符合OGSA的實現：OGSI(開放式網格服務基礎結構，Open Grid Service Infrastructure)和更新的WSRF(網絡服務資源框架，Web Service Resource Framework)。OGSI擴展了WSDL（Web Service Definition Language）和XML Schema，使Web Service的狀態可以標準化。WSRF是一個符合OGSA標準的實現，用于取代OGSI并統一Web Service和網格服務世界。
1.2 網格服務體系結構
??? (1)Globus Toolkit。Globus Toolkit把服務隔絕在網格服務容器（Grid Service Container）中，Globus Toolkit在其中發揮作用并向遠程客戶端提供服務。容器運行時管理所有服務相關的工作，如服務創建、調用分發和服務銷毀。
??? (2)OGSI.NET。OGSI.NET是Microsoft .NET平臺上的一個OGSI的實現，由Virginia Grid Computing Group開發。OGSI.NET服務容器的工作機理是通過一個ISAPI過濾器截獲Microsoft IIS請求。容器本身被作為一個Windows服務實現。
??? (3)WSRF.NET。WSRF.NET是一個在Microsoft.NET平臺上開發符合WSRF規范服務的開發包。這個框架中大量使用了標準的Microsoft程序和工具(如IIS，ASP.NET)。有一個專門的ISAPI過濾器用來更正基于EPR(末端參考，EndpointReference）的消息分發，但是并沒有單獨的容器來實現，而是用一個靜態生成的殼（wrapper）使得網格服務作為標準的ASP.NET網絡服務運行。
??? (4)gSOAP。gSOAP是用于創建C/C++網絡服務的軟件開發包。gSOAP應用于科學計算領域和對時間要求嚴格的場合，特別經過速度優化。由于加入的層被C++優化過，所以可視為是一種快速、天然的部署C++服務的方法。gSOAP不支持創建OGSI和WSRF服務，因此不能直接作為網格服務的容器。本文將其加入測試，是為和其他體系結構做對比。
2? 性能對比
2.1 測試方法
??? 為了測試每種體系結構的性能，創建了一個C++類，其包含兩個方法：
??? int Echo(int)：輸入一個整數并返回，不做其他處理。
??? int Matrix(int)：輸入一個整數k，進行一個矩陣乘法運算，由兩個k階的矩陣相乘，這樣每次調用產生一個O(k³)的復雜度運算。返回值是一個整數描述結果的狀態。這兩個方法產生的數據傳輸（參數和返回值）是非常小的。這一點保證了調用這兩個方法時產生的延遲不是由體系結構部署XML parser時產生的。大多數科學計算程序的調用請求都屬于這種少量數據傳輸的方式。
??? 大部分網格架構的測試是通過測量客戶端服務調用的等待時間實現的。為達到這個目的，在每一種體系結構下部署了Echo和Matrix方法。測試客戶端使用Microsoft.NET平臺的C#開發。
??? 選擇沒有負載的服務器測試單純的服務調用等待時間。客戶端每隔50ms調用一次Echo服務，一共調用100次，平均調用等待時間被記錄下來。
2.2 測試配置
??? 服務器端配置兩臺相同的PC機。具體配置為：Intel Pentium IV 2.8 MHz CPU，512MB內存，80GB 7200 rpm HDD和100MB以太網卡。
??? 每臺PC機都重新安裝了操作系統。一臺運行Redhat Linux（Kernel 2.6.9-5.EL），另一臺運行Microsoft Windows XP Service Pack 2。所有的軟件包都使用默認安裝，沒有做任何優化。其結果為默認配置下的結果。
??? 客戶端使用C#編程。客戶端管理程序能夠產生多個客戶端進程作為分開的線程并且收集每個線程的等待時間，此程序在本文中的所有測試中使用。
2.3 測試結果
??? 測試Echo方法調用。創建一個服務實例，順序調用100次Echo。每次調用中間停止50ms，測試結果如圖1、圖2所示。

?

?

??? 測試結果和之前確定的保持一樣的層次結構。gSOAP由于不支持網格服務和服務生命期管理，所以沒有出現在這次測試中。Globus Toolkit盡管等待時間加倍，但仍然是最快的。WSRF.NET的時間不受影響。OGSI.NET的等待時間是778ms。
3? 結? 論
??? 測試結果表明，在考慮等待時間和可擴展性的前提下，最適合部署C++網格服務的體系結構是加了Java殼的Globus Toolkit4.0。WSRF.NET是一個不錯的測試WSRF新標準的平臺。但是，它在等待時間上的表現不如Globus。如果這方面要求非常嚴格，則WSRF.NET不是一個好的選擇。
??? OGSI.NET表現出性能問題，等待時間、可擴展性都不好。
??? gSOAP在等待時間和可擴展性方面的表現十分出色。但gSOAP不支持網格服務，所以很難直接比較。如果服務不需要生存期管理、資源、提醒等網格服務的擴展功能并且性能要求很高，則gSOAP可以做為一個不錯的部署框架。Globus開發小組在Globus Toolkit 4.0中使用gSOAP作為C++服務支持層。從測試結果中可以看出，在不影響網格服務功能的原則下，極大地提高了網格服務的速度。
參考文獻
1?? Foster I，Kesselman C，Nick J et al.The Physiology of the Grid：An Open Grid Services Architecture for Distributed?Systems Integration.Open Grid Service Infrastructure WG，Global Grid Forum，2002
2?? Karatzoglou A.Developing a parallel benchmarking suite for Java Grande applications.Technical Report EPCCSS99-06，Edinburgh Parallel Computing Centre，1999
3?? Gannon D.A Revised Analysis of the Open Grid Services Infrastructure.http：//www.extreme.indiana.edu/~gannon/ogsaAnalysis4.pdf
4?? Tuecke S，Czajkowski K，Foster I et al.Open Grid Services Infrastructure(OGSI) Version 1.0.Global Grid Forum Draft?Recommendation，2003
5?? Czajkowski K，Ferguson D F，Foster I et al.The WSResource Framework Version 1.0.http：//www.globus.org/wsrf/specs/ws-wsrf.pdf
6?? Czajkowski K，Ferguson D，Foster I et al.From Open Grid Services Infrastructure to WS-Resource Framework：Refactoring & Evolution.http：//www.globus.org/wsrf/OGSItoWSRF1.0.pdf
7?? The Globus Alliance. The Globus Toolkit.http：//www.globus.org/toolkit/