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