SOA嫁接網格 優勢互補

SOA可以為網格應用提供一種基于標準的資源描述方式，使之能支持更廣泛的平臺和環境，擴展網格應用的使用范圍；而網格可以為基于SOA的應用提供一種虛擬化的基礎設施服務，提供資源虛擬化、服務水平管理、計費管理等功能。

近年來，SOA和網格成為了IT技術發展的熱點，許多企業都在研究和評估SOA和網格技術。有些喜歡先進技術的用戶已經開始試用將非關鍵業務系統部署在基于SOA的網格服務上，率先地享受了SOA的靈活優勢。

作者簡介：朱明先生在IT業已有25年的深厚經驗，繼最初5年在惠普公司之后，1986年進入IBM位于達拉斯的開放系統中心擔任顧問工程師，隨后的20年一直在IBM不同的部門為各行業的客戶服務。

企業的兩大傳統局限

在互聯網時代，企業的傳統應用具有兩大局限性。其一為無法有效利用現代互聯網技術，其二為無法編寫互聯網應用。這兩大局限使得互聯網的優勢無法被傳統應用充分利用。

SOA的體系架構正是為了突破這兩大局限而產生的。SOA將應用程序的不同功能單元封裝，能夠在互聯網上運行與被呼叫的獨立功能模塊。這種“互聯網上”的模塊被稱之為“互聯網服務（Web Service）”或“網格服務(Grid Service)”。

當這些“服務”被基于業務流程而被連成“流程”時，我們仍將它叫作“網格服務”。服務間通過基于標準的接口和協議連接。這種服務間的接口能夠獨立于實現服務的硬件平臺、操作系統和編程語言，因此可以采用統一和通用的方式進行信息交換。

由于這是一種松耦合的集成方式，所以可以保證應用的最大靈活性，以滿足在不斷變化的環境中客戶應用的需求，實現一種隨需應變（On Demand）的業務模式。

面向服務的體系架構并不是一個新鮮事物，面向對象（Object-Oriented）的概念早在二十多年前就誕生了，分布式對象技術也在近十余年來得到了廣泛的發展，如CORBA，EJB等。

SOA的主要不同點是采用了網格服務標準來描述應用接口，由于網格服務都是基于開放標準的，在其定義中就保證了體系結構和平臺的無關性，因此基于SOA的應用程序可以部署到各種平臺上，可以極大地簡化基于SOA應用程序的部署和分布。

此外，除了服務描述以外，在SOA中還需要定義整個應用程序如何在服務之間執行其工作流，將業務的商業流程與具體實現的技術流程聯系起來。

“虛擬化”分布的IT資源

網格計算是分布式網絡發展的下一代產物，它可以讓我們分享分散的計算系統資源。有了網格計算技術，用戶可以將服務器、存儲系統和網絡聯合在一起，組成一個大的系統，從而為用戶提供功能強大的多系統資源來處理特定的任務，解決一些以前由于工作量太大而在一臺計算機上很難處理的問題。

簡而言之，網格是一種將分布的IT資源“虛擬化”的技術。

由于網格要利用很多技術組件，并需要在構成網格的多個功能域之間進行交互，因此標準就在網格的持續擴展中扮演了一個至關重要的角色。它們可以規范不同組件之間的交互操作，讓供應商集中精力在自己的應用實現中提供更高的價值。

如果沒有網格解決方案框架中的標準，用戶就不可能利用一種模塊化和協調的方法來為自己的網格環境持續增加能力。

目前，網格正在向網格服務架構發展，首先是Globus采用開放網格標準基礎設施（OGSI），然后是新發布的Globus工具包Globus Toolkit 4.0（GT4）對網格服務資源框架Web Services Resource Framework（WSRF）的支持，可以看到網格標準和網格服務正在走向統一（如圖1）。

SOA可以為網格應用提供一種基于標準的資源描述方式，使之能支持更廣泛的平臺和環境，擴展網格應用的使用范圍；而網格可以為基于SOA的應用提供一種虛擬化的基礎設施服務（Infrastructure Services），提供資源虛擬化、服務水平管理、計費管理等功能。

用戶可以方便地添加IT資源來擴展應用的處理能力和提高服務質量，由此簡化SOA的部署，降低系統運作和管理成本。通過企業服務總線（ESB），兩者可以有機結合，為企業提供一個隨需應變的運作環境（On Demand Operating Environment）（如圖2）。

基于SOA的網格程序和傳統的網格應用相比，可以分解為一系列獨立的互聯網服務功能組件，并且可以在不同平臺上運行，提供了更大的靈活性；同時，依賴于網格服務的描述和發布機制，可以實現網格資源的自動發現和配送，能大大提高網格的自治性。

但真正將網格應用移植到SOA平臺上，有兩點問題需要考慮：

1.應用程序能否劃分成更小的、互相獨立的功能模塊

在系統設計時，應該盡量避免采用不可分的單塊程序架構，而是采用一種“搭積木”的思路來考慮問題。

2.功能模塊是否能獨立運行

在模塊運行時，應盡量避免對物理資源的長期占有。當需要使用共享的資源時（如數據庫連接），應盡量采用Web服務的方式來進行所需的操作，并在操作完成后迅速釋放資源。

對于企業來說，將整個基礎架構遷移到SOA，這一過程應該是一個進化，而不是一個改革。用戶需要和選定的技術合作伙伴一起，制定一個良好的分步實施方案，避免可能的風險，并在每個步驟都獲得良好的投資回報。

以下幾點是這一遷移過程能否成功的關鍵因素：

◆ 技能：用戶自身技術人員或合作伙伴對網格服務和SOA的掌握程度，對于應用架構向SOA的平滑過渡至關重要；

◆ 應用：現有應用是否需要作大幅度的修改，對應用程序的執行效率會不會有影響等。一般會先選擇一些合適的應用作為試點；

◆ 業務：在遷移過程中可能涉及對業務模式和業務流程的優化，因此對業務流程的熟悉程度和相關行業的實施經驗和IT同樣重要。

◆ 基礎設施：現有的基礎設施能否被重用？基礎設施能否提供足夠的靈活性來支持未來的擴展？基礎設施是不是具有部署SOA所需的虛擬化能力？

將網格應用移植到SOA平臺上，能夠提高資源的利用效率，簡化資源的管理，進一步地推動企業范圍內的協作?？梢灶A見到，網格技術將在企業架構的SOA發展之路中起重要作用。這種技術終將使企業的應用在未來能充分的發揮互聯網的優勢。

應用實例

我們以一個實際的客戶應用案例，來說明SOA向網絡服務遷移的這一過程，該用戶是美國的激光干涉儀引力波探測實驗室（Laser Interferometer Gravitational Wave Observatory，LIGO）。這是一個由美國國家科學基金委員會支持的項目，目標是觀測和驗證由愛因斯坦提出的引力波理論。

目前這一項目覆蓋了十個不同地點和數以百計的科學家，需要處理150TB規模的數據，而且這些數據還以每天1TB的速度在增加。

客戶以前在每個地點都采用了專用的網格產品和架構，用戶只能在本地提交作業。由于數據和存儲能力是分散在不同地點的，用戶需要手工地將數據在不同地點間進行移動。這樣不僅使用不便，不利于科學家之間的合作，而且也造成了IT資源的利用效率不高（如圖3）。

隨著Globus 4.0的發布及其對距聯網服務標準的支持，用戶希望將他們的基礎設施遷移到SOA的架構上去。因此，他們在現有的環境基礎上添加了新的網格服務中間件，并且采用面向服務的方式對現有的業務流程進行了封裝，具體說明參看圖4。

通過上面的例子可以看到，用戶并不需要對現有的IT基礎設施作太大的改變。通過將現有的網格平臺封裝為網格服務，并添加新的工作流管理和數據管理組件，用戶可以實現統一的面向服務的網格架構（或SOA網格），而現有的網格資源也為這一SOA的架構提供了必要的基礎設施。這一架構也同樣適用于許多分布的企業中。

1 首先定義了通用的數據服務和工作流管理服務，用戶通過元數據（Metadata）來定義和提交作業。

2 工作流管理服務通過查詢元數據判斷作業對數據的需求。

3 元數據將用戶數據需求映射為邏輯文件名 。

4 通過網格服務中間件提供的RLS（位置復制服務）將邏輯文件名映射為分布在不同地點的物理文件名。

5 通過網格服務中間件提供的RFT（可靠的文件傳輸服務），將需要移動的數據傳遞到作業執行地點。

6 工作流管理服務將數據文件和計算作業結合在一起。

7 工作流管理服務將整合的作業提交到工作流執行服務。

8 通過網格服務中間件提供的GRAM（網格資源分配和管理）組件將作業提交到已有的網格平臺上。

9 執行作業。