網格和面向服務架構（SOA）是兩個似乎相互沖突的系統。SOA 是構建離散服務的標準，它可能要跨越多臺機器，這些機器可以進行合并以構建一個應用程序，從而降低集成成本。大部分現代網格都采用了類似于 SOA 的 Web 服務，但是在這兩個系統之間實際上有更多東西可以進行合并，而不僅僅是采用幾個 Web 服務。您還必須調整網格解決方案的體系結構。本文將簡要介紹 SOA 幕后的一些概念，以及在將網格應用程序遷移到 SOA 模型時應該考慮的問題。
遷移到 SOA 和網格
網格應用程序的一個永恒的問題是，使其足夠靈活，以在各種平臺和環境中使用。盡管早期的網格使用了專用的解決方案，其中采用的是嚴格受控的硬件和環境，但是最近的發展已經清楚地表明，將網格應用程序放到更為廣泛的平臺上運行，這樣您只需要添加一些機器就可以很容易地擴展網格的范圍和處理能力。
然而，平臺之間微小的差異可能會導致非常令人頭疼的事情。例如，Windows? 不同版本之間的改變，甚至是 Windows NT 和 Windows 2000 之間的差異，也都會導致那些網格環境中通常經過嚴格設計和優化了的應用程序出現問題。一個顯然的解決方案是去掉那些高度與平臺相關的元素，并切換到一個更加通用的環境中。
SOA 幕后的準則遵守一些基本的規則。SOA 是一個用來構建應用程序的基于組件的模型，可以將應用程序劃分為很多離散的服務，這些服務各自執行某個特定的功能，但是可以將它們組合在一起構成更大的應用程序。
SOA 的基本原理現在已經并不新鮮了。面向對象的概念已經出現了很多年，分布式對象也已經在很多技術中存在很多年了，例如 CORBA。主要的區別在于，SOA 是基于面向對象和 Web 服務兩個概念的組合，并在一個用來描述可用接口的開放系統中采用了這種結構。通過使得 Web 服務可以更容易發現和識別，SOA 可以極大地簡化基于 SOA 應用程序的部署和分布。由于 Web 服務都是基于開放標準的，在其定義中就保證了體系結構和平臺的無關性，因此基于 SOA 的應用程序可以部署到各種平臺上。
簡而言之，SOA 是一種對外提供服務的方法，讓計算機可以彼此進行交談，并共享自己的處理能力和功能。網格正在慢慢地朝 Web 服務架構發展，首先是 Globus 采用開放網格標準基礎設施（OGSI），然后是發布 Globus Toolkit 4.0（GT4）。SOA 和網格技術正基于諸如 Web Services Resource Framework（WSRF）以及其他的一些解決方案，朝 Web Standards Interoperability 技術方向發展。
您還可以看到 SOA 和網格都可以為對方提供很多東西。這并不是網格技術利用 SOA 準則的情況，或者反之。從 SOA 的觀點來說，網格為信息和資源的分布提供了一個異常模型，這是 SOA 模型的一個關鍵特性。從網格的觀點來看，SOA 為調整網格解決方案的架構以及促進其透明性和更好地支持廣泛的平臺和環境，提供了一些可選的而又非常靈活的方法。
下面讓我們來了解一下傳統的網格模型，然后介紹一下基于 SOA 的網格模型，從而比較二者之間的區別，以及如何開始將網格和 SOA 應用程序作為一個單一的資源進行考慮。
傳統的網格模型
為了全面地理解 SOA 如何才能改進網格服務，以及需要如何修改應用程序，下面讓我們來看一個基于傳統的網格技術的典型網格服務，包括基本的 Web 服務。這個服務的基本結構非常簡單。
在圖 1 中您可以看到一個典型的網格環境的結構圖。其中我故意沒有說明網格軟件的類型，因為大部分網格軟件都可以根據相同的原理進行工作。
圖 1. 網格模型結構圖
總體上來看，這個結構相當簡單。我們有一個網格協調者負責分發信息并與各個節點進行工作。這個協調者（它還有很多別的名字，包括分發和管理節點）的職責就是運行網格。協調者與工作節點之間的通信可能在很多解決方案中都存在，不過大部分系統（包括 Globus）都是依賴于 Web 服務的。此處使用的模型通常都稱為級聯服務，因為信息和工作請求都是通過服務進行級聯，從而將其從某個地方分發到各個節點上。
然而，不管采用哪種通信系統，其方法大體上是相同的：
- 嚴格結構的意思是說，節點都是使用一個特定的 Web 服務或 Web 服務接口與某個軟件的特定部分進行聯系的，從而處理來自節點協調者的請求。
- 任務提交是通過協調者進行處理的，它分布在各個節點上，通常使用一個 Web 服務來提交任務。在工作節點上，有一個類似的客戶機將完成的任務發回給網格協調者。
- 網格節點所需要的其他信息（例如大型的數據結構或引用材料）可以在網絡上通過另外一個服務進行訪問，Web 服務可能支持，也可能不支持。例如，有些網格使用一個集中的 SQL 數據庫來存儲節點不通過 Web 服務接口而是直接訪問的信息。
總體來說，大部分網格服務（直到最近）都是基于大型的單一代碼基礎的，它使用了一些私有的方法來進行通信和共享信息。這使得 Web 服務模型也正在發生改變，但是即使采用了 Web 服務標準之后，很多解決方案也都可以對原有的單一應用程序使用一個 Web 服務接口。例如，從上面這個傳統的模型中我們可以看出，將任務提交到一個節點是通過一個 Web 服務接口提交給網格節點的，這實際上會將面向 Web 服務的接口暴露給原來的應用程序。
這種單塊方法存在一個問題，即使使用 Web 服務，它也會限制擴展和增長的能力。采用這種單塊風格，將應用程序移植到其他平臺和環境就會變得更加復雜。如果您的系統不是基于 Web 服務的，那么問題可能就更加嚴重。增長之所以會受到限制是因為它依賴于單個協調系統來負責在網絡間分發信息。如果您的客戶機也是一個單塊接口（即使它同時還使用 Web 服務來提供接口），那么將網格應用程序部署到很多機器上也會變得更加困難。
SOA 應用程序模型
SOA 并不是使用 Web 服務來集成應用程序不同部分并在其間進行通信的另外一個簡單術語。SOA 要走得更遠，它定義了一種方法來部署應用程序，這樣可以將注意力從由多個函數和對象組成的單個應用程序轉移到一種將整個應用程序劃分為多個單一服務的結構上來。例如，考慮一個記帳程序，它有一些組件負責開具發票并提供一種方法進行支付。除了傳統的組件應用程序模型之外，您還可能會希望為這兩個任務定義一些對象和相關方法。
在一個簡單的 Web 服務環境中，您要為對象和方法構建一個接口來允許訪問需要遠程訪問的內容。例如，開具發票這個任務可能需要您通過網絡連接進行訪問。在所有的可能性中，Web 服務都會在一臺專用的機器上有一個專用的接口，為其構建一個接口需要了解這臺服務器上都在運行什么服務，以及為其提供接口需要的詳細信息。
在一個 SOA 中，這個記帳應用程序中的每個功能從技術上來說都可以作為一個 Web 服務。每個服務都會在網絡上廣播自己的存在，您可以在任何經過適當授權的機器上執行任何操作。而且，由于每個服務都是自己可以控制的一個組件，因此它們可以存在于網絡上的任何地方。我們不再需要一臺專用的服務器來處理請求。例如，我們可以使用一個服務器農場，由于服務會廣播自己的存在，因此我們不必擔心如何發現這些服務。
從上面的介紹中，我們可以確定 SOA 的主要元素是：
- 可以作為一個單獨的服務使用 —— 所提供的服務質量的級別還需要作為一項標準確定。例如，我們還不知道是否要提供一個可以處理多個操作和多個服務的單一發票服務，每個都支持不同的操作，例如開具發票、支付發票或修改發票。
- 獨立性 —— 我們并不關心它們是如何來實現我們請求的任務的。它們只要實現這個功能就好了。類似地，服務也并不關心如何來達到這個結果。
- 服務會廣播自己的存在。
因此從理論上來說，應該可以將一個應用程序劃分為更小的組件，然后可以將其連接在一起（通過相互調用），從而構成最終的應用程序。由于這些單元也可能會擴展到多臺機器上，因此我們需要從這種單塊、級聯結構切換到一種更加靈活的分布式、自由通信的結構。在圖 2 中您可以看到一個 SOA 結構的例子。
圖 2. SOA 網格模型的一個例子
SOA 網格模型
從上面對于 SOA 模型的介紹以及目前網格技術朝著 Web 服務結構發展的趨勢可以清楚地看出，二者正在不斷融合。使用簡單的術語來說，網格是一個共享資源的分布式系統，而 SOA 則是一個分布式體系結構，后者最關注的是服務的相互操作能力、易于集成、簡單性、可擴展性以及安全訪問的特性。這兩個系統有一些共同的問題，包括延時、并發和局部故障等問題。
二者都使用了 Web 服務，圖 3 給出了一個可以在 SOA 和網格環境中使用的簡單布局。二者都大量地采用了 SOAP、XML Web 服務標準以及相關的安全性、管理和其他系統。
圖 3. SOA 操作模型
不管現有的應用程序是否使用 Web 服務，您都可以看到在圖 3 中詳細介紹的開放標準構成了 SOA 標準的主體。總之，SOA 利用了以下的技術：
- 使用 XML 來構成所有標準的核心部分，從用來交換信息的 SOAP 協議到用來共享描述信息的方法。例如， WSDL（一種基于 XML 的描述語言）就用來描述潛在的客戶機可以使用的服務。
- SOAP 為交換對象和調用方法提供了一些基本的方法。底層的傳輸協議是高度不相關的，不過很可能會使用 HTTP。
- 很多擴展用來為服務之間的交互操作提供關鍵的服務。例如，WS-Reliability 和 WS-Resource 就用來幫助提高通信的可靠性。
- 后臺標準，例如 WS-Security 和新的 WS-Distributed Management 標準，用來幫助提供安全的通信和管理遠程服務。
這些準則和技術早已在 Globus Toolkit 中得到了采用，并深入網格標準和應用程序之中。
要在自己的應用程序中采用這些技術，需要改變一下開發應用程序的方法。例如，要在網格應用程序中采用 SOA 的準則，您需要：
- 將應用程序遷移到服務模型。如果您還沒有這樣做，就必須考慮一下應用程序中的每個操作。稍后我們會更詳細地介紹這個問題。
- 將應用程序劃分成更小的、離散的組件。例如，不采用一個帶有 Web 服務接口的單塊程序，而是將應用程序劃分成單個基于 Web 服務的組件。您可以將為網格節點提供服務的應用程序劃分成單個服務來接受任務、返回任務和匯報統計信息。
- 確保節點和控制器可以獨立工作。不要依賴于對數據庫服務器或其他資源的持久連接。
反之，要在 SOA 應用程序中采用網格的概念，您需要：
- 從應用程序中刪除那些依賴于單一主機或環境進行操作的部分。
- 將統計信息和監視信息集成到 SOA 服務中，從而確定典型的網格負載信息，例如 CPU 和存儲資源。
這兩種情況中的結果應該是可以構建一個更加靈活而且實際可用的應用程序。
遷移應用程序
修改現有的應用程序是修改網格或 SOA 應用程序最困難的方法，因為您需要找到一種方法來修改應用程序，卻不要極大地改變應用程序工作的方法和現有的服務。
主要的問題是要確定應用程序的組織。建立要執行的操作列表，網格中的組件和節點之間通信是如何操作的，以及各個步驟的編譯次序。例如，您可能會希望制作一個提交次序的模型：當提交作業時會發生什么，當發回響應時會發生什么，當需要有關某個給定資源的狀態信息時又會發生什么。有了這些信息，就可以構建一個支持這些操作所需要的服務清單了。
現在您需要考慮如何實現這些服務。SOA 和基于網格的服務方法之間有一點區別：SOA 組件被認為是無狀態的，而網格則是有狀態的。二者并不需要是互斥的。您可以開發一個無狀態的應用程序來提供有狀態的信息，這樣就可以包含一個方法來記錄可以匯報的服務的狀態。
記住，即使是在遷移到新的 SOA 模型時，應用程序中的關鍵部分也是相同的。例如在 CPU 敏感的網格中，網格中執行實際工作的核心的計算函數都是相同的，訪問數據結構和信息的代碼也都是相同的。例如，如果您考慮一個圖像呈現網格，構成原始圖像描述的數據以及將這些向量數據轉換成最終圖像的代碼（函數或應用程序）都是相同的。只有各個節點之間進行通信和發送請求的方式會發生變化。
最后，具備這些信息之后，就可以開始將應用程序遷移到新的基于組件的模型了。不幸的是，并沒有什么簡單的方法可以產生這些信息，現在也沒有什么工具可以對此進行簡化。您需要確定的很多信息都依賴于應用程序和轉換應用程序時的源環境。
結束語
即使對于一個偶然的觀察者來說，SOA 和網格都具有類似的目標：簡化應用程序，擴充其功能和所支持的平臺，可以將任務更容易地分發到多臺機器上。它們當然會采用很多相同的基本組件 —— Web 服務和 XML —— 但是這些方法稍有不同。您還可以看到每種解決方案可以給另外一種解決方案提供很多優點，足以值得考慮利用這種技術。例如，網格技術的獨立特性對于部署基于 SOA 的應用程序就非常有益。SOA 的靈活特性和異構特性對于網格擴充自己的平臺基礎來說則十分理想。
采用基于 SOA 的網格，我們可以獲得很多優點。單塊模型消失了。現在不再采用一個單一的網格協調者來控制各個任務單元在網格上的執行，任務可以提交到任意的節點上。當任務進行分發時，如果節點不能及時處理這些任務，各個節點應該可以將任務直接發送到其他節點上。這種自治體系結構是可能的，因為各個組件可以彼此進行交互。