網(wǎng)格通信
Web 服務(wù)概覽
網(wǎng)格與 Web 服務(wù)之間的界限逐漸模糊
支持請求架構
支持分發(fā)架構
結束語(yǔ)
目前兩項最熱門(mén)的技術(shù)就是網(wǎng)格計算和 Web 服務(wù)，但是這兩者是兼容的嗎？在本文中，Martin C. Brown 告訴我們這兩個(gè)系統實(shí)際上兼容程度是相當高的，并描述了在網(wǎng)格應用程序中使用 Web 服務(wù)的好處。為了確定網(wǎng)格計算和 Web 服務(wù)是否相互兼容，我們需要研究一下網(wǎng)格計算的工作方式，看看我們是否真的可以將一個(gè)典型的網(wǎng)格系統分解成若干個(gè)相對分散的單元。網(wǎng)格計算的架構依賴(lài)于相當基本的原理，即在多臺客戶(hù)機和多臺服務(wù)器之間傳送簡(jiǎn)單的請求。 Web 服務(wù)依賴(lài)于處理從一臺客戶(hù)機發(fā)送到一臺服務(wù)器上的請求。
如果您尚未看到這一點(diǎn)是如何適應已有的網(wǎng)格結構的，本文將探討兩種最常見(jiàn)的網(wǎng)格系統：請求架構和分發(fā)架構。請求系統依賴(lài)于客戶(hù)機請求工作，而分發(fā)系統依賴(lài)于代理直接給客戶(hù)機提供工作。這兩種系統在與 Web 服務(wù)結合的時(shí)候面對的是不同的問(wèn)題，這一點(diǎn)我們也會(huì )討論到。
在網(wǎng)格計算中，基本存在兩種主要的組件類(lèi)型 —— 服務(wù)器和客戶(hù)機。服務(wù)器用于分發(fā)工作請求及保存有關(guān)構成整個(gè)工作的獨立工作單元的信息?？蛻?hù)機（典型情況下有多個(gè)）負責處理獨立的工作單元。這兩者之間的通信方式有多種，但是系統的核心是對工作的分發(fā)。再次指出，系統采用兩種工作方式中的一種，要么是客戶(hù)機管理自己的工作流，并向服務(wù)器請求新的工作單元，要么是服務(wù)器將工作單元分發(fā)給客戶(hù)機。
通信過(guò)程并不是到這里就停止了；通常還需要額外的服務(wù)器和服務(wù)來(lái)支持網(wǎng)格服務(wù)器的基礎設施，它們相互之間需要進(jìn)行對話(huà)，并交換信息。關(guān)鍵的問(wèn)題在于，通常情況下網(wǎng)格解決方案中交換的是相當分散的信息片斷。在客戶(hù)機和服務(wù)器之間交換的是原始的工作單元和處理之后的響應。甚至在數據負載相當高的情況之下，如進(jìn)行數據處理或視頻呈現時(shí)，我們依然在交換信息包，而不是在客戶(hù)機和服務(wù)器元素之間建立完全、雙向、永久的通信。
新版的 WebSphere 擴展包中的網(wǎng)格思想更為激進(jìn)，甚至允許將到 WebSphere 應用程序的 Web 請求通過(guò) WebSphere 服務(wù)器進(jìn)行分發(fā)。這個(gè)例子也證明了網(wǎng)格管理與實(shí)際的工作分發(fā)都可以通過(guò)相當簡(jiǎn)單的數據交換來(lái)完成。
規則中當然總有例外。并不是所有的網(wǎng)格系統都依賴(lài)于如此直接的簡(jiǎn)單包交換。比如說(shuō)，資源網(wǎng)格通常依賴(lài)于網(wǎng)格提供者（客戶(hù)機）之間相當繁重的相互通信，這樣才能在網(wǎng)格上實(shí)現實(shí)時(shí)的存儲請求。不過(guò)在這些情況下，即便當客戶(hù)機之間直接進(jìn)行通信時(shí)，依然是一種基本的信息交換。因此，如果我們僅僅在交換信息，當然就應該用一種標準的方法在服務(wù)器和客戶(hù)機之間進(jìn)行通信。這也就是 Web 服務(wù)的用武之地。
在我們能夠理解 Web 服務(wù)如何為我們的網(wǎng)格解決方案提供支柱之前，我們需要理解 Web 服務(wù)的工作方式。最簡(jiǎn)單的方法是將其想像成一種遠程過(guò)程調用（RPC），通過(guò)這種方式我們可以從一臺計算機（客戶(hù)機）上調用某個(gè)功能，而代碼和實(shí)際的功能是在另外一臺計算機（服務(wù)器）上執行的。
各種各樣的 RPC 中不存在新東西。一段時(shí)間以來(lái)，各種不同的平臺上都有不同的實(shí)現。也許最有名的 RPC 實(shí)現是 UNIX 機上的。這一實(shí)現使用了一組復雜的函數，可以使客戶(hù)機與服務(wù)器之間進(jìn)行信息交換，它將一種基本的 C 結構轉換成一種可以在網(wǎng)絡(luò )上廣播的標準化格式，即外部數據表示（External Data Representation, XDR）格式。這種方法對數據進(jìn)行了序列化和標準化的處理，轉換后的數據格式可以被該 RPC 架構下的任何客戶(hù)機或服務(wù)器解碼出來(lái)。
最近 Web 的爆炸式發(fā)展意味著(zhù)，每當我們訪(fǎng)問(wèn)某個(gè) Web 站點(diǎn)的時(shí)候，我們很自然就是在進(jìn)行遠程過(guò)程調用。我們的客戶(hù)機就是瀏覽器，它向一臺服務(wù)器（如 Apache, IIS 等）請求一個(gè)文件，然后，處理并顯示得到的信息。這是一個(gè)簡(jiǎn)單的數據交換過(guò)程。有了公共網(wǎng)關(guān)接口（Common Gateway Interface, CGI）、JSP、ASP 這樣的動(dòng)態(tài)技術(shù)，我們才真正是在調用遠程過(guò)程。交換過(guò)程是以 HTTP 請求和 HTML 響應的形式進(jìn)行的，但是達到的效果一樣：我們調用遠程機器上的過(guò)程，然后獲得一個(gè)響應。
通過(guò)以某種方式標準化信息的交換過(guò)程，我們就得到了 Web 服務(wù)。請求和響應都以 XML 編碼。從基本相同的技術(shù)派生出兩個(gè)變種：XML-RPC 的設計目標與它的縮寫(xiě)名所暗示的完全一樣 —— 發(fā)送和接收用 XML 格式化的遠程過(guò)程調用；簡(jiǎn)單對象訪(fǎng)問(wèn)協(xié)議（Simple Object Access Protocol, SOAP）更加高級。SOAP 的核心依然是一種 RPC 技術(shù)，但是這種技術(shù)經(jīng)過(guò)增強，可以實(shí)現對一個(gè)對象的遠程操縱。這樣 SOAP 就不是一種簡(jiǎn)單的 RPC 調用，而是可以創(chuàng )建對象、操縱對象、并用這個(gè)對象在服務(wù)器和客戶(hù)機之間進(jìn)行更加確切和格式化的信息交換。
Web 服務(wù)可以由任何一種 Web 服務(wù)器提供，可以在幾乎所有的支持平臺上用幾乎所有的語(yǔ)言書(shū)寫(xiě)，其中包括 Perl、Python、C/C++、Java 語(yǔ)言以及 Visual Basic。Web 服務(wù)的核心基本上是 Web 服務(wù)器上的一個(gè)動(dòng)態(tài)組件，它能夠正確地處理 Web 服務(wù)請求和響應。這意味著(zhù)，在很多情況下，您可以很容易在您的已有系統中創(chuàng )建一個(gè) Web 服務(wù)的接口。您需要做的只是在通常進(jìn)行的常規系統調用外圍編寫(xiě)一個(gè)包裝器。
到目前為止，我們已經(jīng)探討了通過(guò)交換信息而實(shí)現的網(wǎng)格技術(shù)，這種交換既可以在服務(wù)器和客戶(hù)機之間進(jìn)行，也可以直接在客戶(hù)機之間進(jìn)行，從而實(shí)現對信息的處理和分發(fā)。但是這種交換系統需要借用某種方式進(jìn)行真正的信息交換。這些年來(lái)，人們使用了很多種系統，包括 FTP 協(xié)議和定制的協(xié)議系統。
目前，在 Web 服務(wù)陣營(yíng)之中，我們已經(jīng)擁有了一種通用的工具，可以用來(lái)在兩臺機器之間交換信息，比如說(shuō)請求執行某項特定的功能（如 getnewworkunit()），或是簡(jiǎn)單地在這兩者之間交換信息。因為 Web 服務(wù)是建立在 XML 等其他標準之上的，因此很容易開(kāi)發(fā)并擴展到各種不同環(huán)境中，并且也容易部署。我們擺脫了不同系統間數據交換的所有問(wèn)題，并且不需要擔心處理器字節中的位次序（endian-ness），也不需要將我們傳遞的信息轉換成中性格式，因為 Web 服務(wù)的標準已經(jīng)替我們做了這些事情。
因為我們需要用某種類(lèi)型的偵聽(tīng)程序/分發(fā)服務(wù)來(lái)處理請求、分發(fā)工作以及收集結果，所以 Web 服務(wù)就是最理想的選擇。Web 服務(wù)系統帶來(lái)的主要益處在于，因為它依賴(lài)于 HTTP 協(xié)議，因此很容易將 Web 服務(wù)集成到已有的 HTTP 平臺、路由器、防火墻以及其他系統中。大多數組織已經(jīng)運行了 HTTP 服務(wù)，因此您可以用已有的技術(shù)和安全系統來(lái)支持您的網(wǎng)格系統，而不需要對網(wǎng)絡(luò )進(jìn)行改造，也不會(huì )對網(wǎng)格系統中的設備造成限制。
這樣，用 Web 服務(wù)開(kāi)發(fā)網(wǎng)格系統就具有了一些無(wú)可比擬的優(yōu)勢，其中包括：
·增強的兼容性。
·增強的靈活性。
·通過(guò)消除數據交換的復雜性，使跨平臺開(kāi)發(fā)成為可能。
·很容易部署在已有的 Web 服務(wù)器上。
·很容易通過(guò)已有的 HTTP 安全機制與防火墻的支持來(lái)提供安全性。
·通過(guò) Intranet 或 Internet 訪(fǎng)問(wèn)網(wǎng)格組件的難度降低，這樣就使得通信變得容易，可訪(fǎng)問(wèn)性增強。
出于所有上面這些理由，以及更多的原因，Web 服務(wù)已經(jīng)逐漸成為新的網(wǎng)格服務(wù)標準 —— 開(kāi)放網(wǎng)格服務(wù)架構（Open Grid Services Architecture, OGSA）以及與之相伴的開(kāi)放網(wǎng)格服務(wù)基礎設施（Open Grid Services Infrastructure, OGSI）—— 的一個(gè)組成部分。Globus Toolkit 3.0 是第一個(gè)完全支持 OGSA/OGSI 標準的網(wǎng)格平臺，它支持將 Web 服務(wù)作為數據交換的平臺。IBM 作為 OGSA 標準和 Globus 系統的關(guān)鍵參與者，給 Web 服務(wù)提供了強有力的支持，現在正推薦人們在業(yè)務(wù)開(kāi)發(fā)平臺中廣泛使用 Web 服務(wù)。Globus 支持 SOAP Web 服務(wù)協(xié)議。
Web 服務(wù)方法還帶來(lái)其他一些好處。Web 服務(wù)可以通過(guò)多種不同的 Web 服務(wù)目錄和系統發(fā)布，其中包括像統一描述、發(fā)現與集成（Universal Description、Discovery and Integration，UDDI）和 Web 服務(wù)描述語(yǔ)言（Web Services Description Language, WSDL）這樣的系統。為了讓網(wǎng)格計算能更容易部署，我們需要通過(guò)這樣的目錄和系統來(lái)發(fā)布服務(wù)。不管您是否選擇 Globus Toolkit，都需要考慮如何在您的網(wǎng)格系統中應用 Web 服務(wù)。有兩種 Web 服務(wù)可供使用，它們分別適應兩種典型的網(wǎng)格服務(wù)結構：請求架構，在這種架構之下客戶(hù)機與一個(gè)或者多個(gè)中央服務(wù)器進(jìn)行聯(lián)系；分發(fā)架構，服務(wù)器直接與客戶(hù)機聯(lián)系。對于每一種架構，在網(wǎng)格應用程序中使用 Web 服務(wù)之前您都必須考慮一些問(wèn)題。下面幾節將詳細討論。
Web 服務(wù)的主要應用位置是在分發(fā)和代理的一端，也就是說(shuō)，點(diǎn)單元被分布到網(wǎng)格中的客戶(hù)機（提供者）上，這就是一種請求架構的例子，其中客戶(hù)機從網(wǎng)格代理那里請求工作。請求架構事實(shí)上是可以支持 Web 服務(wù)的最簡(jiǎn)單的系統，因為這樣的系統可以像以前一樣很好地工作：客戶(hù)機向一個(gè)可用的服務(wù)器發(fā)送已經(jīng)完成的工作單元，并從那里請求新的工作。您需要做的事情只是安裝 Web 服務(wù)和 Web 服務(wù)器，可以單獨安裝，也可以直接安裝在代理服務(wù)器上，然后添加代碼以將您的 Web 服務(wù)連接到代理。整個(gè)系統的工作情況如圖 1 所示：
圖 1. 請求架構運行圖
Globus 對于這種架構是一個(gè)理想的解決方案，因為 Web 服務(wù)組件可以很方便地對系統中的客戶(hù)機和服務(wù)器提供支持。
分發(fā)架構與傳統的網(wǎng)格服務(wù)模型相反，它直接從服務(wù)器向客戶(hù)機分配工作。這種架構盡管不常用，但是如果某種環(huán)境中的工作是受到控制的，并可以仔細地分配到特定的執行單元，并分別監控，那么這種架構對于分發(fā)工作就是很實(shí)用的方法。然后，由服務(wù)器負責單獨管理和分配每一個(gè)單元。
分發(fā)模型對于時(shí)間要求高的任務(wù)分配是一種好辦法，因為工作單元可以根據機器的負載和代理上的服務(wù)器隊列分配到獨立的機器上。這種模型特別適合用于 Intranet 和封閉的網(wǎng)絡(luò )中，因為訪(fǎng)問(wèn)和通信都很方便，因此系統的效率也相對較高。這種模型還適用于工作提供者（即客戶(hù)機）完全用來(lái)處理網(wǎng)格工作的情況。
分發(fā)系統惟一的問(wèn)題是實(shí)現難度比較大。這種模型不是由服務(wù)器運行 Web 服務(wù)系統，客戶(hù)機作為 Web 服務(wù)的客戶(hù)機，而是調了個(gè)頭。網(wǎng)格提供者（通常應該是“客戶(hù)機”）需要支持一個(gè) Web 服務(wù)的服務(wù)器接口。這時(shí)，代理（通常是“服務(wù)器”）成為網(wǎng)格提供者的 Web 服務(wù)客戶(hù)機。您可以從圖 2 中看到這種模型的運行情況：
圖 2. 分發(fā)模式下的 Web 服務(wù)
在這里的 Web 服務(wù)機制的基礎之上還存在以下問(wèn)題：
·代理需要確切知道哪些機器是網(wǎng)格的一部分，因為它需要能分別訪(fǎng)問(wèn)這些客戶(hù)機。
·每一個(gè)客戶(hù)機都必須支持 Web 服務(wù)模型，該模型又依賴(lài)于客戶(hù)機提供 HTTP 服務(wù)。
·每一個(gè)客戶(hù)機都必須能夠確定自己的負載和性能，這樣才能在代理請求的時(shí)候將這些信息提供給它。
盡管需要解決上面的每一個(gè)問(wèn)題，分發(fā)架構使用起來(lái)依然相對簡(jiǎn)單。然而 Globus Toolkit 目前并不支持這種模型。這并不意味著(zhù)我們不能在其他領(lǐng)域內使用 Globus Toolkit，但是卻意味著(zhù)您必須重新考慮客戶(hù)機和代理之間是如何交換任務(wù)的。
將網(wǎng)格應用程序和 Web 服務(wù)集成實(shí)際上并不像剛開(kāi)始看上去那么復雜。大多數網(wǎng)格應用程序的基礎使它們很容易轉移到 Web 服務(wù)的架構上來(lái)，但是您需要考慮對您的網(wǎng)格應用程序設計的影響，以保證您的后端系統（包括代理、工作單元管理器以及其他組件）都能與您所期望的客戶(hù)機工作方式兼容。
關(guān)于作者 Martin C. Brown 以前擔任過(guò) IT 主管，在跨平臺集成方面有豐富的經(jīng)驗。他作為一名目光敏銳的開(kāi)發(fā)人員，一直為特殊的用戶(hù)制作動(dòng)態(tài)站點(diǎn)，并兼任 Foodware.net 的技術(shù)主管?，F在他是一名自由作家和顧問(wèn)。他更出名的地方是作為一名 SME 和微軟公司的緊密合作。此外，他還是 LinuxWorld 雜志的 LAMP 技術(shù)編輯，以及 AnswerSquad.com 團隊的核心成員。他撰寫(xiě)的書(shū)籍有 XML Processing with Perl、Python and PHP 以及 Microsoft IIS 6 Delta Guide，等等。您可以通過(guò) questions@mcslp.com 與 Martin 取得聯(lián)系。
聯(lián)系客服
