在web service服務(wù)的基礎(chǔ)上提出了“網(wǎng)格服務(wù)”的概念，它定義了一組接口，這些接口的定義明確并遵守特定的慣例，用于解決服務(wù)器發(fā)現(xiàn)，動態(tài)服務(wù)創(chuàng)建、服務(wù)生命周期管理、通知等與服務(wù)生命周期有關(guān)的問題。網(wǎng)格服務(wù)標(biāo)記語言(Grid Service Markup Language, 簡稱GSML)是一種基于XML的網(wǎng)格應(yīng)用編程（描述）語言，支持網(wǎng)格環(huán)境中用戶端的"按需"編程，通過基于可復(fù)用組件和事件驅(qū)動的方式來描述網(wǎng)格應(yīng)用靈活多變的處理邏輯和協(xié)同工作機(jī)制。GSML項目包括GSML語言和相關(guān)工具集。

　　GSML語言中的概念 Pipe, Event, EventSet啟發(fā)自pi演算，通過它們用戶能夠以統(tǒng)一的異步事件通信機(jī)制來描述用戶端各種軟件組件和網(wǎng)格資源之間的交互關(guān)系。GSML相關(guān)工具集包括瀏覽器和編輯器（）。瀏覽器運行由GSML語言編寫的應(yīng)用程序；編輯器被用來編寫GSML程序。GSML的目標(biāo)是成為一種簡單易用的網(wǎng)格編程語言,能夠靈活、有效地整合網(wǎng)格資源,而且提供網(wǎng)格 資源、應(yīng)用和用戶進(jìn)行協(xié)同工作的基礎(chǔ)設(shè)施。

　　C++這個詞在中國大陸的程序員圈子中通常被讀做“C加加”，而西方的程序員通常讀做“C plus plus”，“CPP”。 它是一種使用非常廣泛的計算機(jī)編程語言。C++是一種靜態(tài)數(shù)據(jù)類型檢查的，支持多重編程范式的通用程序設(shè)計語言。它支持過程化程序設(shè)計、數(shù)據(jù)抽象、面向?qū)ο蟪绦蛟O(shè)計、制作圖標(biāo)等等泛型程序設(shè)計等多種程序設(shè)計風(fēng)格。

　　1  網(wǎng)格體系結(jié)構(gòu)介紹

　　1.1 網(wǎng)格服務(wù)標(biāo)準(zhǔn)

　　OGSA(Open Grid Services Architecture)的創(chuàng)建是為了滿足網(wǎng)格在分布、異構(gòu)的動態(tài)環(huán)境下整合服務(wù)的需要。OGSA只定義了架構(gòu)，沒有給出實現(xiàn)。有兩種符合OGSA的實現(xiàn)：OGSI(開放式網(wǎng)格服務(wù)基礎(chǔ)結(jié)構(gòu)，Open Grid Service Infrastructure)和更新的WSRF(網(wǎng)絡(luò)服務(wù)資源框架，Web Service Resource Framework)。OGSI擴(kuò)展了WSDL（Web Service Definition Language）和XML Schema，使Web Service的狀態(tài)可以標(biāo)準(zhǔn)化。WSRF是一個符合OGSA標(biāo)準(zhǔn)的實現(xiàn)，用于取代OGSI并統(tǒng)一Web Service和網(wǎng)格服務(wù)世界。

　　1.2 網(wǎng)格服務(wù)體系結(jié)構(gòu)

　　(1)Globus Toolkit。Globus Toolkit把服務(wù)隔絕在網(wǎng)格服務(wù)容器（Grid Service Container）中，Globus Toolkit在其中發(fā)揮作用并向遠(yuǎn)程客戶端提供服務(wù)。容器運行時管理所有服務(wù)相關(guān)的工作，如服務(wù)創(chuàng)建、調(diào)用分發(fā)和服務(wù)銷毀。

　　(2)OGSI.NET。OGSI.NET是Microsoft .NET平臺上的一個OGSI的實現(xiàn)，由Virginia Grid Computing Group開發(fā)。OGSI.NET服務(wù)容器的工作機(jī)理是通過一個ISAPI過濾器截獲Microsoft IIS請求。容器本身被作為一個Windows服務(wù)實現(xiàn)。

　　(3)WSRF.NET。WSRF.NET是一個在Microsoft.NET平臺上開發(fā)符合WSRF規(guī)范服務(wù)的開發(fā)包。這個框架中大量使用了標(biāo)準(zhǔn)的Microsoft程序和工具(如IIS，ASP.NET)。有一個專門的ISAPI過濾器用來更正基于EPR(末端參考，EndpointReference）的消息分發(fā)，但是并沒有單獨的容器來實現(xiàn)，而是用一個靜態(tài)生成的殼（wrapper）使得網(wǎng)格服務(wù)作為標(biāo)準(zhǔn)的ASP.NET網(wǎng)絡(luò)服務(wù)運行。

　　(4)gSOAP。gSOAP是用于創(chuàng)建C/C++網(wǎng)絡(luò)服務(wù)的軟件開發(fā)包。gSOAP應(yīng)用于科學(xué)計算領(lǐng)域和對時間要求嚴(yán)格的場合，特別經(jīng)過速度優(yōu)化。由于加入的層被C++優(yōu)化過，所以可視為是一種快速、天然的部署C++服務(wù)的方法。gSOAP不支持創(chuàng)建OGSI和WSRF服務(wù)，因此不能直接作為網(wǎng)格服務(wù)的容器。本文將其加入測試，是為和其他體系結(jié)構(gòu)做對比。

　　2  性能對比

　　2.1 測試方法

　　為了測試每種體系結(jié)構(gòu)的性能，創(chuàng)建了一個C++類，其包含兩個方法：

　　int Echo(int)：輸入一個整數(shù)并返回，不做其他處理。

　　int Matrix(int)：輸入一個整數(shù)k，進(jìn)行一個矩陣乘法運算，由兩個k階的矩陣相乘，這樣每次調(diào)用產(chǎn)生一個O(k3)的復(fù)雜度運算。返回值是一個整數(shù)描述結(jié)果的狀態(tài)。這兩個方法產(chǎn)生的數(shù)據(jù)傳輸（參數(shù)和返回值）是非常小的。這一點保證了調(diào)用這兩個方法時產(chǎn)生的延遲不是由體系結(jié)構(gòu)部署XML parser時產(chǎn)生的。大多數(shù)科學(xué)計算程序的調(diào)用請求都屬于這種少量數(shù)據(jù)傳輸?shù)姆绞健?/P>

　　大部分網(wǎng)格架構(gòu)的測試是通過測量客戶端服務(wù)調(diào)用的等待時間實現(xiàn)的。為達(dá)到這個目的，在每一種體系結(jié)構(gòu)下部署了Echo和Matrix方法。測試客戶端使用Microsoft.NET平臺的C#開發(fā)。

　　選擇沒有負(fù)載的服務(wù)器測試單純的服務(wù)調(diào)用等待時間?？蛻舳嗣扛?0ms調(diào)用Echo服務(wù)，一共調(diào)用100次，平均調(diào)用等待時間被記錄下來。

　　2.2 測試配置

　　服務(wù)器端配置兩臺相同的PC機(jī)。具體配置為：Intel Pentium IV 2.8 MHz CPU，512MB內(nèi)存，80GB 7200 rpm HDD和100MB以太網(wǎng)卡。

　　每臺PC機(jī)都重新安裝了操作系統(tǒng)。一臺運行Redhat Linux（Kernel 2.6.9-5.EL），另一臺運行Microsoft Windows XP Service Pack 2。所有的軟件包都使用默認(rèn)安裝，沒有做任何優(yōu)化。其結(jié)果為默認(rèn)配置下的結(jié)果。

　　客戶端使用C#編程?？蛻舳斯芾沓绦蚰軌虍a(chǎn)生多個客戶端進(jìn)程作為分開的線程并且收集每個線程的等待時間，此程序在本文中的所有測試中使用。

　　2.3 測試結(jié)果

　　測試Echo方法調(diào)用。創(chuàng)建一個服務(wù)實例，順序調(diào)用100次Echo。每次調(diào)用中間停止50ms，測試結(jié)果如圖1、圖2所示。

　　圖1是創(chuàng)建一個服務(wù)實例，顯示出調(diào)用100次Echo的測試結(jié)果。Globus Toolkit是網(wǎng)格服務(wù)框架中等待時間短的，gSOAP由于只支持Web Service，速度比Globus Toolkit還要快。

　　圖2與圖1相同，但是包含了OGSI.NET的測試結(jié)果。OGSI.NET的調(diào)用時間非常長。

　　GT4.0C代表Globus Toolkit4.0下被Java包裹的C服務(wù)，GT4.0Java代表Globus Toolkit4.0下的純Java服務(wù)。gSOAP是平均等待時間短的，為3.2ms。網(wǎng)格服務(wù)架構(gòu)中，Globus Toolkit4.0快，為6ms。Java wrapper沒有產(chǎn)生明顯的性能延遲，C和Java服務(wù)有非常接近的測試結(jié)果。

　　WSRF.NET 的調(diào)用等待時間是23.5ms，OGSI.NET在這項測試中表現(xiàn)非常不好。接下來的測試同樣證明了OGSI.NET存在嚴(yán)重的性能缺陷。

　　圖3的測試是一個單獨的客戶端調(diào)用100次Echo的結(jié)果，每次調(diào)用間隔50ms。不同之處在于服務(wù)生命期管理功能用于為Echo調(diào)用創(chuàng)建服務(wù)實例。第二次調(diào)用Echo前實例被銷毀。從圖3可看出，Globus Toolkit的調(diào)用時間較之前加倍，WSRF.NET的速度基本沒變。

　　測試結(jié)果和之前確定的保持一樣的層次結(jié)構(gòu)。gSOAP由于不支持網(wǎng)格服務(wù)和服務(wù)生命期管理，所以沒有出現(xiàn)在這次測試中。Globus Toolkit盡管等待時間加倍，但仍然是快的。WSRF.NET的時間不受影響。OGSI.NET的等待時間是778ms。

　　3  結(jié)  論

　　測試結(jié)果表明，在考慮等待時間和可擴(kuò)展性的前提下，適合部署C++網(wǎng)格服務(wù)的體系結(jié)構(gòu)是加了Java殼的Globus Toolkit4.0。

　　WSRF.NET是一個不錯的測試WSRF新標(biāo)準(zhǔn)的平臺。但是，它在等待時間上的表現(xiàn)不如Globus。如果這方面要求非常嚴(yán)格，則WSRF.NET不是一個好的選擇。

　　OGSI.NET表現(xiàn)出性能問題，等待時間、可擴(kuò)展性都不好。

　　gSOAP在等待時間和可擴(kuò)展性方面的表現(xiàn)十分出色。但gSOAP不支持網(wǎng)格服務(wù)，所以很難直接比較。如果服務(wù)不需要生存期管理、資源、提醒等網(wǎng)格服務(wù)的擴(kuò)展功能并且性能要求很高，則gSOAP可以做為一個不錯的部署框架。Globus開發(fā)小組在Globus Toolkit 4.0中使用gSOAP作為C++服務(wù)支持層。從測試結(jié)果中可以看出，在不影響網(wǎng)格服務(wù)功能的原則下，極大地提高了網(wǎng)格服務(wù)的速度。