iweroulsdjf

這是一系列文章的第二部分。這一系列文章旨在幫助您更好地理解面向服務的體系結構（SOA）的價值，制訂出一個實際的計劃來評估您現在的基礎架構，并把它轉變成一個真正的面向服務的體系結構。其目的在于，當您讀完本文時，您將理解為什么聲稱 SOA 是把現有資產帶到未來的最好的平臺，同時也使得迅速而正確地開發未來的程序成為可能。另外，您將對在計劃這樣一次遷移的過程中主要考慮的事項有更好的理解。這一系列文章的第一部分描述了推動考慮 SOA 的動力和這樣的一個體系結構的需求。現在，第二部分將繼續討論服務和接口。

服務的性質

什么是服務？如前所述，在一個典型的業務環境里，服務意味著業務函數、業務事務和系統服務。業務函數可能是 getStockQuote、getCustomerAddress 或 checkCreditRating。業務事務可能是 commitInventory、sellCoveredOption 或 scheduleDelivery。系統服務可能是 logMessageIn、getTimeStamp 或 openFile。請注意各種類型服務之間的區別。從應用程序的角度來看，業務函數實際上是原子的非系統函數。業務事務很像是調用應用程序的簡單函數，但是它們可能是作為自己的事務的上下文所包含的復合函數來實現的。它們可能包括多個底層函數，這些底層函數對調用者來說是透明的。系統函數是能夠從諸如 Windows 或者 Linux 這樣的特定平臺中抽象出來的廣義函數。應用程序框架可能提供像 openFile 這樣的廣義函數來有效地虛擬化數據源，從而可以在不考慮真實數據源的類型和位置的情況下使用這類函數。

這看起來像人為地規定服務之間的區別；您可以從應用程序的角度斷言，所有的服務都是原子的，而與它是業務服務還是系統服務無關。做出這樣的區別僅僅是為了引入粒度這個重要的概念。將業務程序分解成服務不僅僅是一個抽象的過程；它具有非常真實的現實含義。根據定義，服務可能是低級（細粒度的）函數，也可能是復雜的高級（粗粒度的）函數，并且在性能、靈活性、可維護性和可重用性方面都有很現實的折衷選擇。定義服務的過程通常是在更大的作用域（應用程序框架的作用域）內完成的。這才是必須做的實際工作：也就是開發基于組件的應用程序框架，其中，服務定義為一組可重用的組件，而這些組件又可以用來構建新的應用程序或集成現有的軟件資產。

現在，可以獲得很多這樣的框架；在 IBM，一些像 EWA、JADE 和 Struts （來自 Jakarta）的這樣的框架正用在客戶集成場景中。以 EWA （讀作“Eva”）為例（它來自 IBM Software Group Advanced Technology Solutions 組），在一個較高的層次上，框架看起來如 圖 1 所示。在這個框架中，配置定義了一個應用程序，描述了該應用程序的組件以及它們調用的順序和方法。以源中立的方式接收輸入并將其傳送到應用程序。因此，舉例來說，用現有的 ATM 訪問將因特網連接添加到一個銀行應用程序，對應用程序邏輯來說是透明的。前端設備和協議處理程序使其成為可能。核心提供系統級服務，而特定用途的使得能夠連接后端企業應用程序，這樣它們就可以保持原來的狀態，或者在一段時間以后進行遷移。雖然 EWA 是完全遵循 J2EE，但是它可以連接到外部基于 DCOM 或 CORBA 組件的系統。

現在，EWA 包括超過 1500 個的常規和特定用途的組件，從而大大地減少了編寫新的應用程序所需的代碼數量。本系列的另一篇文章將詳細地研究應用程序框架以及用戶在開發這樣一個應用程序框架的過程中需要什么。

解決前面的問題

現在，讓我們回到討論第一個集成場景，尋找一個將所需的接口數量減到最少的 Scheme，如 圖 2 所示。

這張圖看起來可能過于簡化，但是現在可以很清楚地看出，在像 EWA 這樣的框架中，這張圖是一個起點。現在，添加屬于體系結構概念范圍的服務總線（Service Bus）（在 圖 3 中用深色的中線表示）和服務或流管理器來連接服務和提供服務請求的路徑。流管理器處理定義好的執行序列或服務流，它們將按照適當的順序調用所需的服務來產生最后的結果。業務流程執行語言（Business Process Execution Language，BPEL）就是這種將流程定義為一組服務調用的技術的例子。

在這里，您需要確定如何調用服務，因而您將添加應用程序配置。接著，虛擬化輸入和輸出。最后，提供到后端流程的連接，以便使它們可以按“僅此狀態”運行，并且還可以在將來進行遷移。現在，這個高層次的圖至少在結構上是完整的了，如 圖 4 所示。

這張圖與 EWA 框圖有一些類同之處是毫不奇怪的；在最高的層次上，任何健壯的應用程序框架都必須提供這些功能。然而，從現在起，真正的工作開始了——構建 1500 個組件來豐富這個骨架。這就是為什么很多 IT 架構師選擇在一個現有的框架中進行實現的原因；把現有的應用程序分解成用于框架的組件就夠了，而不必重新開發所有其他已知將要用到的通用用途組件和系統組件。無論您如何使用它，您都可以使用現有的技術和框架來實現該體系結構，所以您繞了一整圈，現在又回到了開始的地方，在這里，流程首先分析必須解決的業務問題。如果您敢肯定您的體系結構事實上是可實現的，您現在就可以這樣做。

體系結構中的集成需求

討論至此，集成已限定為通過基于組件的服務進行的應用程序的集成，但是集成這個主題比這要寬泛得多。在估計一個體系結構的需求時，必須考慮一些集成的類型或“方式”。您必須考慮如下幾方面：

• 應用程序集成
• 終端用戶界面集成
• 應用程序連接
• 流程集成
• 信息集成
• 構建集成開發模型。

終端用戶界面集成涉及如何集成特定用戶訪問的全部應用程序和服務來提供可用、高效、一致的界面。它是一個正在發展的主題，而新的發展在近期將主要取決于 Portal 服務器使用方面的進展。雖然 Portlet 已經可以通過 Web 服務調用本地服務組件，但是新技術（比如用戶遠程 Portlet 的 Web 服務）將使內容和應用程序提供者能夠創建交互式服務，這些服務在因特網上可以通過 Portal 即插即用，從而為很多新的集成提供了可能。

應用程序連接是一種集成方式，它涉及體系結構必須支持的所有類型的連接。在一個層次上，這意味著數據的同步和異步通信、路由、轉換和高速分布、以及網關和協議轉換器等等。而在另一個層次上，它還與輸入和輸出或源（sources）和匯（sinks）的虛擬化有關，正如您在 EWA 的通道（Channel）和協議轉換程序（Protocol Handlers）中所看到的。這里的問題在于數據移入、移出以及在實現體系結構的框架中移動的方式。

流程集成涉及開發映射到業務流程和為業務流程提供解決方案的計算流程、將應用程序集成到流程以及集成一些流程與其他一些流程。雖然第一項需求可能看起來似乎無關緊要，不過就是體系結構提供一個模擬基本業務問題的環境，但是，如果在這一層中不進行充分的分析，體系結構的任何實現注定都將失敗，不管它采用的技術是多么的巧妙。將應用程序集成到流程可能包括企業中的應用程序，也可能涉及調用遠程系統中的應用程序或服務，而這些遠程系統多半屬于業務合作伙伴。同樣地，流程層集成可能涉及整個流程的集成而不僅僅是來自外部源的單個服務，比如供應鏈管理或金融服務這樣橫跨多個機構的流程。為了滿足這樣的應用程序和流程的集成需求，可以使用像 BPEL4WS 這樣的技術，而應用程序框架也可以使用程序配置 Scheme（比如在 EWA 中看到的）。實際上，可以在底層使用 BPEL4WS 來構造一個高層配置 Scheme，然后通過一個引擎來驅動，這個引擎不僅提供流管理，而且還提供其他功能。然而，在構建這一切之前，您應該首先了解體系結構方面的需求，然后，再構建合適的基礎架構。

信息集成是一個流程，其作用在于為所有需要它的應用程序提供對企業中全部數據的一致訪問，而不管這些應用程序是以什么形式需要它，也不受數據的格式、來源或位置的限制。在實現時，這項需求可能包括 適配器和轉換引擎，不過它通常要比這復雜。而關鍵的概念往往是數據的虛擬化，這可能包括 數據總線（Data Bus）的開發，企業中的所有應用程序都通過標準服務或接口從數據總線中請求數據。因此，不管數據是來自電子數據表、本地文件、SQL 或 DL/I 數據庫，還是來自內存中的數據存儲，都可以將數據提供給應用程序。永久存儲中的數據格式可能還不為應用程序所知。應用程序更不知道管理數據的操作系統，因而訪問 AIX 或 Linux 系統中的本地文件的方式與這些文件放在 Windows、OS/2、ZOS 或其他系統中時訪問它們的方式相同。同樣地，數據的位置也是透明的；由于它是由共同的服務提供的，所以是由訪問服務而不是由應用程序來負責查詢數據（無論是本地的還是遠程的），然后按照請求的格式提供數據。

應用程序開發環境的最后一項需求是，必須考慮可能在企業中實現的集成的所有方式和層次，并且為它們的開發和部署做好準備。要想真正做到健壯，開發環境必須包括（和執行）一種方法來明確地規定如何設計和構建服務和組件，以便促進重用、消除冗余和簡化測試、部署和維護。

上面列出的所有集成方式在任何企業中都有一定程度的體現，盡管在某些情況下它們可能是簡化的，或者沒有明確地進行定義；因而，在著手設計新的體系結構框架時，您必須全面的考慮它們。特定的 IT 環境可能只有很少的數據源類型，因此，消息集成可能會很簡單。同樣地，應用程序連接的作用域可能也很有限。雖然如此，如果希望框架能夠隨著企業的成長和變化成功地繼續得以保持，則框架中的集成功能仍然必須由服務提供，而不是由特定的應用程序來完成。

部署面向服務的體系結構的好處

面向服務的體系結構可以基于現有的系統投資來發展，而不需要徹底重新創建系統。如果組織將開發力量集中在創建服務、利用現有的技術、結合基于組件的方法來開發軟件上，將獲得如下幾方面好處：

• 利用現有資產 —— 這是首要的需求。通過使用適當的 SOA 框架并使其可用于整個企業，可以將業務服務構造成現有組件的集合。使用這種新的服務只需要知道它的接口和名稱。服務的內部細節以及在組成服務的組件之間傳送的數據的復雜性都對外界隱藏了。這種組件的匿名性使組織能夠利用現有的投資，從而可以通過合并構建在不同的機器上、運行在不同的操作系統中、用不同的編程語言開發的組件來創建服務。遺留系統可以通過 Web 服務接口來封裝和訪問。
  
• 商品化基礎架構 —— 在所有不同的企業應用程序之間，基礎架構的開發和部署將變得更加一致。現有的組件、新開發的組件和從廠商購買的組件可以合并在一個定義良好的 SOA 框架內。這樣的組件集合將被作為服務部署在現有的基礎構架中，從而使得可以更多地將基礎架構作為一種商品化元素來加以考慮
  
• 更快的產品上市速度 —— 組織的 Web 服務庫將成為采用 SOA 框架的組織的核心資產。使用這些 Web 服務庫來構建和部署服務將顯著地加快產品的上市速度，因為對現有服務和組件的新的創造性重用縮短了設計、開發、測試和部署產品的時間。
  
• 減少成本 —— 隨著業務需求的發展和新的需求的引入，通過采用 SOA 框架和服務庫，為現有的和新的應用程序增強和創建新的服務的成本大大地減少了。同樣，開發團隊的學習難讀也降低了，因為他們可能已經熟悉了現有的組件。
  
• 降低風險 —— 重用現有的組件降低了在增強或創建新的業務服務的過程中帶來的風險。如前所述，這也減少了維護和管理支持服務的基礎架構的風險。
  
• 持續改進業務過程 —— SOA 允許清晰地表示流程流，這些流程流通過在特定業務服務中使用的組件的順序來標識。這給商業用戶提供了監視業務操作的理想環境。業務建模反映在業務服務中。流程操縱是以一定的模式重組部件（構成業務服務的組件）來實現的。這將進一步允許更改流程流，而同時監視產生的結果，因此促進了持續改進。
  
• 以流程為中心的體系結構—— 現有的體系結構模型和實踐往往是以程序為中心的。應用程序是為了程序員的便利而開發的。通常，流程信息在組件之間傳播。應用程序很像一個黑匣子，沒有粒度可用于外部。重用需要復制代碼、合并共享庫或繼承對象。在以流程為中心的體系結構中，應用程序是為過程開發的。流程可以分解成一系列的步驟，每一個步驟表示一個業務服務。實際上，每個過程服務或組件功能都相當于一個子應用程序。將這些子應用程序鏈接在一起可以創建能夠滿足業務需求的流程流。這種粒度允許利用和重用整個組織中的子應用程序。

未來 —— 新模型，新需求

到目前為止，討論集中在滿足現有業務的需求、更好地利用和重用資源以及集成現有的和新的應用程序的相關概念上。但是，一個全新的應用程序模型究竟是什么樣的呢？面向服務的體系結構的觀念是否仍然有意義或者是必不可少的呢？實際上，兩種新的概念已經開始實現了：網格計算（Grid Computing）和按需計算（On-demand Computing）。雖然這兩個模型是截然不同的，并且是獨立開發的，但是它們之間的關系又是非常的緊密，而每個模型都使 SOA 的發展更加勢在必行。

網格計算

深入討論網格計算超出了本文的范圍，但是有幾個要點值得提及的。其一，網格計算不僅是使用擁有大量 MIPS 的應用程序來進行計算的解決方案，它還涉及包括硬件、應用程序和數據在內的所有系統資源的虛擬化，因此，在網格中，無論在什么地方，用什么方法，只要需要就可以利用這些資源。其二，前面的章節已經討論了虛擬化數據源和將應用程序分解成基于組件的服務的重要性，所以很容易理解在網格環境中，一個真正的 SOA 應該更好地獲得最多的資源。

按需計算

On-demand 也不在我們討論的范圍之內，但是如果在這里不簡要地介紹一下 On-demand 和 SOA 之間的關系，那將是不負責任的。Web 服務是實現 SOA 的技術，而 SOA 是實現 On-demand 應用程序的體系結構。應用程序必需運行在 SOA 框架內，以便獲得 on-demand 的好處。

On-demand Web 服務 On-demand 是涵蓋寬譜系的 On-demand 消息的一部分。譜系的一端集中于應用程序環境，而另一端則集中于包括像基礎架構和自主計算在內的操作環境。業務轉換利用應用程序和操作環境來創建 On-demand 業務。On-demand 業務最核心的是 On-demand Web 服務，應用程序層的服務可以按照準時制（just-in-time）集成能力的要求來發現、重構、裝配和交付。

Web 服務作為一項切實可行的技術的希望在于，它將通過提供諸如按需服務這樣的能力提高業務價值，并且隨著時間的推移將轉變 IT 組織開發軟件的方式。它甚至完全有可能通過 Web 轉變在利益共同體（包括貿易合作伙伴、客戶和其他類型的合作關系）中經營業務以及提供產品和服務的方式。如果您所有的應用程序共享相同的傳輸層協議？如果它們都理解相同的接口？如果它們能夠參與并理解相同的事務模型？如果您的伙伴也一樣？當這一些都實現的時候，展現在您面前的將是什么樣的場景呢？相信到那時，您將擁有應用程序和基礎架構來支持不斷變化的業務情況；您將獲得 On-demand 。而 Web 服務和 SOA 會使這一切對應用程序成為可能。

總結

面向服務的體系結構是下一步應用程序開發的重點。服務和面向服務的體系結構都是關于使用異構網絡可尋址的軟件組件來設計和構建系統的。面向服務的體系結構是一種具有特殊性質的體系結構，它由強調互操作性和位置透明度的組件互連而成。它常常是在現有系統投資的基礎上發展起來的，并不需要徹底重新開發全部的系統；它通過利用當前的資源（包括開發人員、軟件語言、硬件平臺、數據庫和應用程序）來利用組織現有的投資，從而在提高生產力的同時降低成本和風險。這種可適應的、靈活的體系結構類型為在開發和維護中縮短產品上市時間以及降低成本和風險提供了基礎。Web 服務是一些實現 SOA 的技術，而 SOA 正在成為開發響應性好、可適應的新型應用程序所選擇的體系結構。