論網(wǎng)格計算與 Web 服務(wù)的應(yīng)用結(jié)合

論網(wǎng)格計算與 Web 服務(wù)的應(yīng)用結(jié)合目前兩項(xiàng)最熱門的技術(shù)就是網(wǎng)格計算和 Web 服務(wù)，但是這兩者是兼容的嗎？本 文將告訴我們這兩個系統(tǒng)實(shí)際上兼容程度是相當(dāng)高的，并描述了在網(wǎng)格應(yīng)用程序 中使用 Web 服務(wù)的好處為了確定網(wǎng)格計算和 Web 服務(wù)是否相互兼容，我們需要研究一下網(wǎng)格計算的工 作方式，看看我們是否真的可以將一個典型的網(wǎng)格系統(tǒng)分解成若干個相對分散的 單元網(wǎng)格計算的架構(gòu)依賴于相當(dāng)基本的原理，即在多臺客戶機(jī)和多臺服務(wù)器之 間傳送簡單的請求食Web服務(wù)依賴于處理從一臺客戶機(jī)發(fā)送到一臺服務(wù)器上 的請求如果您尚未看到這一點(diǎn)是如何適應(yīng)已有的網(wǎng)格結(jié)構(gòu)的，本文將探討兩種最常見的 網(wǎng)格系統(tǒng)：請求架構(gòu)和分發(fā)架構(gòu)請求系統(tǒng)依賴于客戶機(jī)請求工作，而分發(fā)系統(tǒng) 依賴于代理直接給客戶機(jī)提供工作這兩種系統(tǒng)在與 Web 服務(wù)結(jié)合的時候面對 的是不同的問題，這一點(diǎn)我們也會討論到網(wǎng)格通信在網(wǎng)格計算中，基本存在兩種主要的組件類型 —— 服務(wù)器和客戶機(jī)服務(wù)器用 于分發(fā)工作請求及保存有關(guān)構(gòu)成整個工作的獨(dú)立工作單元的信息客戶機(jī)（典型 情況下有多個）負(fù)責(zé)處理獨(dú)立的工作單元這兩者之間的通信方式有多種，但是系統(tǒng)的核心是對工作的分發(fā)再次指出，系 統(tǒng)采用兩種工作方式中的一種，要么是客戶機(jī)管理自己的工作流，并向服務(wù)器請 求新的工作單元，要么是服務(wù)器將工作單元分發(fā)給客戶機(jī)。

通信過程并不是到這 里就停止了；通常還需要額外的服務(wù)器和服務(wù)來支持網(wǎng)格服務(wù)器的基礎(chǔ)設(shè)施，它 們相互之間需要進(jìn)行對話，并交換信息關(guān)鍵的問題在于，通常情況下網(wǎng)格解決方案中交換的是相當(dāng)分散的信息片斷在 客戶機(jī)和服務(wù)器之間交換的是原始的工作單元和處理之后的響應(yīng)甚至在數(shù)據(jù)負(fù) 載相當(dāng)高的情況之下，如進(jìn)行數(shù)據(jù)處理或視頻呈現(xiàn)時，我們依然在交換信息包， 而不是在客戶機(jī)和服務(wù)器元素之間建立完全、雙向、永久的通信新版的 WebSphere 擴(kuò)展包中的網(wǎng)格思想更為激進(jìn)，甚至允許將到 WebSphere 應(yīng) 用程序的 Web 請求通過 WebSphere 服務(wù)器進(jìn)行分發(fā)這個例子也證明了網(wǎng)格管 理與實(shí)際的工作分發(fā)都可以通過相當(dāng)簡單的數(shù)據(jù)交換來完成規(guī)則中當(dāng)然總有例外并不是所有的網(wǎng)格系統(tǒng)都依賴于如此直接的簡單包交換 比如說，資源網(wǎng)格通常依賴于網(wǎng)格提供者（客戶機(jī)）之間相當(dāng)繁重的相互通信， 這樣才能在網(wǎng)格上實(shí)現(xiàn)實(shí)時的存儲請求不過在這些情況下，即便當(dāng)客戶機(jī)之間 直接進(jìn)行通信時，依然是一種基本的信息交換因此，如果我們僅僅在交換信息，當(dāng)然就應(yīng)該用一種標(biāo)準(zhǔn)的方法在服務(wù)器和客戶 機(jī)之間進(jìn)行通信這也就是 Web 服務(wù)的用武之地Web 服務(wù)概覽在我們能夠理解 Web 服務(wù)如何為我們的網(wǎng)格解決方案提供支柱之前，我們需要 理解 Web 服務(wù)的工作方式。

最簡單的方法是將其想像成一種遠(yuǎn)程過程調(diào)用(RPC)，通過這種方式我們可以從一臺計算機(jī)(客戶機(jī))上調(diào)用某個功能，而 代碼和實(shí)際的功能是在另外一臺計算機(jī)(服務(wù)器)上執(zhí)行的各種各樣的 RPC 中不存在新東西一段時間以來，各種不同的平臺上都有不同 的實(shí)現(xiàn)也許最有名的 RPC 實(shí)現(xiàn)是 UNIX 機(jī)上的這一實(shí)現(xiàn)使用了一組復(fù)雜的 函數(shù)，可以使客戶機(jī)與服務(wù)器之間進(jìn)行信息交換，它將一種基本的 C 結(jié)構(gòu)轉(zhuǎn)換 成一種可以在網(wǎng)絡(luò)上廣播的標(biāo)準(zhǔn)化格式，即外部數(shù)據(jù)表示( External Data Represen tat ion, XDR)格式這種方法對數(shù)據(jù)進(jìn)行了序列化和標(biāo)準(zhǔn)化的處理， 轉(zhuǎn)換后的數(shù)據(jù)格式可以被該 RPC 架構(gòu)下的任何客戶機(jī)或服務(wù)器解碼出來最近 Web 的爆炸式發(fā)展意味著，每當(dāng)我們訪問某個 Web 站點(diǎn)的時候，我們很自 然就是在進(jìn)行遠(yuǎn)程過程調(diào)用我們的客戶機(jī)就是瀏覽器，它向一臺服務(wù)器(如 Apache, IIS 等)請求一個文件，然后，處理并顯示得到的信息這是一個簡單 的數(shù)據(jù)交換過程有了公共網(wǎng)關(guān)接口( Common Ga teway In terface, CGI)、JSP、 ASP 這樣的動態(tài)技術(shù)，我們才真正是在調(diào)用遠(yuǎn)程過程。

交換過程是以 HTTP 請求 和 HTML 響應(yīng)的形式進(jìn)行的，但是達(dá)到的效果一樣：我們調(diào)用遠(yuǎn)程機(jī)器上的過程， 然后獲得一個響應(yīng)通過以某種方式標(biāo)準(zhǔn)化信息的交換過程，我們就得到了 Web 服務(wù)請求和響應(yīng) 都以XML編碼從基本相同的技術(shù)派生出兩個變種：XML-RPC的設(shè)計目標(biāo)與它 的縮寫名所暗示的完全一樣 —— 發(fā)送和接收用 XML 格式化的遠(yuǎn)程過程調(diào)用； 簡單對象訪問協(xié)議(Simple Object Access Protocol, SOAP)更加高級SOAP的 核心依然是一種 RPC 技術(shù)，但是這種技術(shù)經(jīng)過增強(qiáng)，可以實(shí)現(xiàn)對一個對象的遠(yuǎn) 程操縱這樣 SOAP 就不是一種簡單的 RPC 調(diào)用，而是可以創(chuàng)建對象、操縱對 象、并用這個對象在服務(wù)器和客戶機(jī)之間進(jìn)行更加確切和格式化的信息交換Web 服務(wù)可以由任何一種 Web 服務(wù)器提供，可以在幾乎所有的支持平臺上用幾 乎所有的語言書寫，其中包括 Perl、 Python、 C/C++、 Java 語言以及 Visual Basic Web 服務(wù)的核心基本上是 Web 服務(wù)器上的一個動態(tài)組件，它能夠正確地 處理 Web 服務(wù)請求和響應(yīng)這意味著，在很多情況下，您可以很容易在您的已有系統(tǒng)中創(chuàng)建一個 Web 服務(wù) 的接口。

您需要做的只是在通常進(jìn)行的常規(guī)系統(tǒng)調(diào)用外圍編寫一個包裝器網(wǎng)格與 Web 服務(wù)之間的界限逐漸模糊到目前為止，我們已經(jīng)探討了通過交換信 息而實(shí)現(xiàn)的網(wǎng)格技術(shù)，這種交換既可以在服務(wù)器和客戶機(jī)之間進(jìn)行，也可以直接 在客戶機(jī)之間進(jìn)行，從而實(shí)現(xiàn)對信息的處理和分發(fā)但是這種交換系統(tǒng)需要借用 某種方式進(jìn)行真正的信息交換這些年來，人們使用了很多種系統(tǒng)，包括 FTP 協(xié) 議和定制的協(xié)議系統(tǒng)目前，在 Web 服務(wù)陣營之中，我們已經(jīng)擁有了一種通用的工具，可以用來在兩 臺機(jī)器之間交換信息，比如說請求執(zhí)行某項(xiàng)特定的功能(如 getnewworkunit())， 或是簡單地在這兩者之間交換信息因?yàn)?Web 服務(wù)是建立在 XML 等其他標(biāo)準(zhǔn)之 上的，因此很容易開發(fā)并擴(kuò)展到各種不同環(huán)境中，并且也容易部署我們擺脫了 不同系統(tǒng)間數(shù)據(jù)交換的所有問題，并且不需要擔(dān)心處理器字節(jié)中的位次序(endian-ness),也不需要將我們傳遞的信息轉(zhuǎn)換成中性格式，因?yàn)閃eb服務(wù) 的標(biāo)準(zhǔn)已經(jīng)替我們做了這些事情因?yàn)槲覀冃枰媚撤N類型的偵聽程序/分發(fā)服務(wù)來處理請求、分發(fā)工作以及收集 結(jié)果，所以Web服務(wù)就是最理想的選擇Web服務(wù)系統(tǒng)帶來的主要益處在于， 因?yàn)樗蕾囉?HTTP 協(xié)議，因此很容易將 Web 服務(wù)集成到已有的 HTTP 平臺、 路由器、防火墻以及其他系統(tǒng)中。

大多數(shù)組織已經(jīng)運(yùn)行了 HTTP 服務(wù)，因此您可 以用已有的技術(shù)和安全系統(tǒng)來支持您的網(wǎng)格系統(tǒng)，而不需要對網(wǎng)絡(luò)進(jìn)行改造，也 不會對網(wǎng)格系統(tǒng)中的設(shè)備造成限制這樣，用 Web 服務(wù)開發(fā)網(wǎng)格系統(tǒng)就具有了 一些無可比擬的優(yōu)勢，其中包括：增強(qiáng)的兼容性增強(qiáng)的靈活性 通過消除數(shù)據(jù)交換的復(fù)雜性，使跨平臺開發(fā)成為可能 很容易部署在已有的 Web 服務(wù)器上很容易通過已有的 HTTP 安全機(jī)制與防火墻的支持來提供安全性 通過 Intranet 或 Internet 訪問網(wǎng)格組件的難度降低，這樣就使得通信變得容 易，可訪問性增強(qiáng)出于所有上面這些理由，以及更多的原因， Web 服務(wù)已經(jīng)逐漸成為新的網(wǎng)格服務(wù) 標(biāo)準(zhǔn) 開放網(wǎng)格服務(wù)架構(gòu)(Open Grid Services Architecture, OGSA)以及與之相伴的開放網(wǎng)格服務(wù)基礎(chǔ)設(shè)施(Open Grid Services Infras true ture, OGSI)—— 的一個組成部分GlobusToolkit3.0 是第一個完全支持 OGSA/OGSI 標(biāo)準(zhǔn)的網(wǎng)格平臺，它支持將 Web 服務(wù)作為數(shù)據(jù)交換的平臺 IBM 作為 OGSA 標(biāo)準(zhǔn)和 Globus 系統(tǒng)的關(guān)鍵參與 者，給 Web 服務(wù)提供了強(qiáng)有力的支持，現(xiàn)在正推薦人們在業(yè)務(wù)開發(fā)平臺中廣泛 使用 Web 服務(wù)。

Globus 支持 SOAP Web 服務(wù)協(xié)議Web 服務(wù)方法還帶來其他一些好處 Web 服務(wù)可以通過多種不同的 Web 服務(wù)目 錄和系統(tǒng)發(fā)布，其中包括像統(tǒng)一描述、發(fā)現(xiàn)與集成(Universal Description、 Discovery and Integration, UDDI)和 Web 服務(wù)描述語言(Web Services Description Language, WSDL)這樣的系統(tǒng)為了讓網(wǎng)格計算能更容易部署，我 們需要通過這樣的目錄和系統(tǒng)來發(fā)布服務(wù)不管您是否選擇Globus Toolki t,都需要考慮如何在您的網(wǎng)格系統(tǒng)中應(yīng)用Web 服務(wù)有兩種 Web 服務(wù)可供使用，它們分別適應(yīng)兩種典型的網(wǎng)格服務(wù)結(jié)構(gòu)：請 求架構(gòu)，在這種架構(gòu)之下客戶機(jī)與一個或者多個中央服務(wù)器進(jìn)行聯(lián)系；分發(fā)架構(gòu)， 服務(wù)器直接與客戶機(jī)聯(lián)系對于每一種架構(gòu)，在網(wǎng)格應(yīng)用程序中使用 Web 服務(wù) 之前您都必須考慮一些問題支持請求架構(gòu)Web 服務(wù)的主要應(yīng)用位置是在分發(fā)和代理的一端，也就是說，點(diǎn)單元被分布到網(wǎng) 格中的客戶機(jī)（提供者）上，這就是一種請求架構(gòu)的例子，其中客戶機(jī)從網(wǎng)格代 理那里請求工作請求架構(gòu)事實(shí)上是可以支持 Web 服務(wù)的最簡單的系統(tǒng)，因?yàn)檫@樣的系統(tǒng)可以像 以前一樣很好地工作：客戶機(jī)向一個可用的服務(wù)器發(fā)送已經(jīng)完成的工作單元，并 從那里請求新的工作。

您需要做的事情只是安裝 Web 服務(wù)和 Web 服務(wù)器，可以 單獨(dú)安裝，也可以直接安裝在代理服務(wù)器上，然后添加代碼以將您的 Web 服務(wù) 連接到代理整個系統(tǒng)的工作情況如圖 1 所示：圖 1. 請求架構(gòu)運(yùn)行圖Globus 對于這種架構(gòu)是一個理想的解決方案，因?yàn)?Web 服務(wù)組件可以很方便地 對系統(tǒng)支持分發(fā)架構(gòu) 分發(fā)架構(gòu)與傳統(tǒng)的網(wǎng)格服務(wù)模型相反，它直接從服務(wù)器向客戶機(jī)分配工作這種 架構(gòu)盡管不常用，但是如果某種環(huán)境中的工作是受到控制的，并可以仔細(xì)地分配 到特定的執(zhí)行單元，并分別監(jiān)控，那么這種架構(gòu)對于分發(fā)工作就是很實(shí)用的方法 然后，由服務(wù)器負(fù)責(zé)單獨(dú)管理和分配每一個單元分發(fā)模型對于時間要求高的任務(wù)分配是一種好辦法，因?yàn)楣ぷ鲉卧梢愿鶕?jù)機(jī)器 的負(fù)載和代理上的服務(wù)器隊(duì)列分配到獨(dú)立的機(jī)器上這種模型特別適合用于 Intranet 和封閉的網(wǎng)絡(luò)中，因?yàn)樵L問和通信都很方便，因此系統(tǒng)的效率也相對 較高這種模型還適用于工作提供者（即客戶機(jī)）完全用來處理網(wǎng)格工作的情況分發(fā)系統(tǒng)惟一的問題是實(shí)現(xiàn)難度比較大這種模型不是由服務(wù)器運(yùn)行 Web 服務(wù) 系統(tǒng)，客戶機(jī)作為 Web 服務(wù)的客戶機(jī)，而是調(diào)了個頭網(wǎng)格提供者（通常應(yīng)該 是“客戶機(jī)”）需要支持一個 Web 服務(wù)的服務(wù)器接口。

這時，代理（通常是“服 務(wù)器”）成為網(wǎng)格提供者的 Web 服務(wù)客戶機(jī)您可以從圖 2 中看到這種模型的 運(yùn)行情況：圖 2. 分發(fā)模式下的 Web 服務(wù)在這里的 Web 服務(wù)機(jī)制的基礎(chǔ)之上還存在以下問題： 代理需要確切知道哪些機(jī)器是網(wǎng)格的一部分，因?yàn)樗枰芊謩e訪問這些客戶機(jī) 每一個客戶機(jī)都必須支持 Web 服務(wù)模型，該模型又依賴于客戶機(jī)提供 HTTP 服 務(wù)每一個客戶機(jī)都必須能夠確定自己的負(fù)載和性能，這樣才能在代理請求的時候?qū)?這些信息提供給它 盡管需要解決上面的每一個問題，分發(fā)架構(gòu)使用起來依然相對簡單然而 Globus Toolkit 目前并不支持這種模型這并不意味著我們不能在其他領(lǐng)域內(nèi)使用Globus Toolkit,但是卻意味著您必須重新考慮客戶機(jī)和代理之 間是如何交換任務(wù)的將網(wǎng)格應(yīng)用程序和 Web 服務(wù)集成實(shí)際上并不像剛開始看上去那么復(fù)雜大多數(shù) 網(wǎng)格應(yīng)用程序的基礎(chǔ)使它們很容易轉(zhuǎn)移到 Web 服務(wù)的架構(gòu)上來,但是您需要考 慮對您的網(wǎng)格應(yīng)用程序設(shè)計的影響,以保證您的后端系統(tǒng)（包括代理、工作單元 管理器以及其他組件）都能與您所期望的客戶機(jī)工作方式兼容。