在本文中，我將談論如何將 Web 服務及非 Web 服務的多重 SOA 合并成三維的整合中心來連接各種后端企業主機系統，包括：
- 企業資源規劃（Enterprise Resource Planning，ERP）
- 客戶關系管理（Customer Relationship Management，CRM）
- 供應鏈管理（Supply Chain Management，SCM）
- 其它企業應用程序集成（Enterprise Application Integration，EAI）的應用程序
- 虛擬的數據庫管理系統
我也將討論中心如何接受輸入數據——事件和數據——來源于各種資源。我使用 X、Y 和 Z 軸在三維空間中展示圖片。
什么是 SOA 整合中心？
SOA 整合中心是 Web 服務與非 Web 服務的合并的 SOA 與后端企業系統的集成。它使得 Web 服務及非 Web 服務能夠與運行在不同平臺上的服務器、主機和微機上的企業系統交互。
然而，SOA 整合中心不同于面向服務的整合（service-oriented integration，SOI）。SOI 將 Web 服務與運行在不同平臺上的主機系統相整合。它使得 Web 服務能夠通過網關與主機交互。您需要 ASP.Net 或其它技術獲取網關來執行普通的 Web 服務。
SOA 是基于一套業務流程的 Web 服務的交互的體系結構。您可以在第一個 SOA 中獲取 Web 服務來在第二個 SOA 中復用代表 Web 服務的服務。Web 服務可能由一些小的 Web 服務組成，它們將服務傳遞給客戶。
您使用描述語言（例如，SOAP）或其它描述交互的方法（例如，REST）來定義交互。每個交互都是獨立且松耦合的，以便每個交互都能獨立于任何其它交互。這與依賴網關來與 Web 服務集成的緊耦合的主機系統形成對照。
SOA 層
我們看一下二維空間中的 SOA 層。之后，我將向您展示為何三維的整合中心是更好的選擇。
SOA 的 IBM 版本的前五層（請見參考資料）是（從下至上）：
- 操作系統
- 基于組件的（系統）
- 服務
- 業務流程
- 表示層
第六層是集成體系結構（也作為企業集成總線（Enterprise Integration Bus）），它垂直覆蓋了前五層。下一層是服務質量、安全、管理及監控層。
顯而易見，操作層由 EAI 打包的應用程序、遺留、老式的面向對象及商業智能應用程序組成。它們都可以通過使用 SOI（在項目級或企業級）來同第二層的基于組件的系統相集成。然后，將組件結合或集成到復合應用程序中來提供第三層的服務。
第四層向您展示了那些服務是如何根據一套業務流程從一個流向另一個的。更高一層通過遠程門戶網站 Web 服務（Web Services for Remote Portlet，WSRP）標準或其它面向人的表示層的方法來將 Web 服務應用于應用程序接口中。
二維靜態的 SOA 可能是有問題的。幸好，整合中心的發展意味著 SOA 將變成三維動態的。
可復用的體系結構
我們假設該 Web 服務需要在 .Net 平臺上或隨后的 WebSphere 平臺上運行前從主機系統獲取信息。您需要將 Web 服務與執行普通 Web 服務的主機網關相整合。
所有 Web 服務彼此以 XML 傳遞信息——多個 SOA 中的業務流程應當如何整合及其在提供的服務中如何實現。雖然在多個 SOA 中 Web 服務是可復用的，但是我進一步將 SOA 處理成可復用的體系結構。
我有多個實例，它們關于將可復用的 SOA 合并成與主機系統相連的整合中心，我提出如下四步來創建中心：
- 將作為可復用的體系結構的 SOA 數組劃分成兩個模塊。第一模塊主要包括整合 Web 服務的機制，而第二個模塊重在服務交互。
- 為了獲得最佳的速度及可靠性，將每個 SOA 優化成更緊湊的形式。檢查可能影響性能的磁盤碎片空間。
- 將 SOA 按照重要性及復用頻率區分優先次序。檢查用戶對于更改 SOA 優先權的需求。
- 將 SOA 合并成連接到一個或更多主機系統的整合中心，這些主機系統運行在不同的平臺上。檢查先前沒有被提出的互用性問題。
模塊化的 SOA 庫
您可以開發模塊化的和優化的 SOA 庫，這些 SOA 被分成了不同類別的層次。每個類別可以通過層次最低級別的 Web 服務被進一步劃分成 SOA 的子組。
您可以將庫用作到 Web 服務應用程序的動態鏈接。當應用程序需要訪問模塊化的 SOA 時，它將自己鏈接到庫中。當它不再需要檢索到的 SOA 時，將從庫中釋放自己，當提高速度及性能時節省磁盤空間。
下列是庫中模塊化的 SOA 的一些實例：
- 衛生保健 SOA
- 零售管理 SOA
- 物流 SOA
- 無線射頻識別（Radio Frequency Identification，RFID）SOA
庫用例
假設您使用在庫中使用最后三個 SOA（零售管理、物流和 RFID）來開發整合中心并將它們連接到主機網關中。今后，用戶的需求改變了——取消零售管理 SOA 并以衛生保健 SOA 代替它。
同時，用新版本更新物流 SOA 使其迎合用戶的需求。在 RFID SOA 中包含新的子組之后，將所有子組區分優先次序并將它們優化。
二維非共享的 SOA
我們看一下 Blue Repository 中的三個模塊化的 SOA（零售管理、物流和 RFID）的二維中心（請見圖 1）。所有都連接到主機網關中。例如，如果您使用 ASP.Net，那么您可以通過網關來執行普通的 Web 服務。
圖 1. 非共享的 SOA 的二維中心
如您所見，SOA 不是共享的。您可以將這三者結合成復合應用程序以減少到主機網關的連接器的數目。
二維共享的 SOA
如圖 2 所示，RFID SOA 與物流 SOA 在一邊相交疊。交疊區域用黃色帶黑色斜線來顯示。它包含 SOA 用于生成一個或兩個服務的資源。
圖 2. 共享的 SOA 的二維中心
代表三維空間中的中心
您怎樣在二維計算機屏幕上設想三維的中心？處理該問題的一種方法是在二維平面中畫出整合中心的 X、Y 和 Z 軸。另一種方法是使用軟件簡單地將 2D 圖片轉換成 3D 的版本。
在三維的中心，您可以在不改變 SOA 的情況下將現有的主機替換成新樣式或另一供應商的樣式。另外，您可以重新配置或更改 SOA 的優先權以適合新的或已更新的主機系統對于更改用戶及組織的需求的響應。
第一個三維中心
考慮如圖 3 所示的三維空間中的整合中心。如您所見，RFID SOA 中部分位于物流 SOA 之后。RFID SOA 的隱藏部分用到物流 SOA 的藍色線畫出。
圖 3. 第一個共享的 SOA 的三維中心
如您所見，連接器從 RFID SOA 通過（而不是環繞）物流 SOA 到主機網關。這意味著從 RFID SOA 而來的連接器與物流 SOA 共享了一些資源。
第二個三維中心
設想 RFID SOA 的重疊部分在物流 SOA 的前面，但是不是從任一側，如圖 4 所示。這給了 RFID SOA 更多的選擇來共享物流 SOA 中的大量資源。
圖 4. 第二個共享的 SOA 的三維中心
如您所見，連接器從 RFID SOA 通過物流 SOA。
有多少共享的 SOA？
在三維中心中您可以共享的 SOA 的數目依賴于項目復雜性、合并問題及業務流程中的利弊。向您避免 SOA 的過量開銷一樣，您需要確保在開發的整個生命周期中不會在三維空間中發生中心超負荷的問題。您應當在周期的每個時刻都測試超負荷。
結束語
在三維中心中合并 SOA 需要預先規劃來設置開發和共享的 SOA 的數目限制。您應當同業務分析師開發組交流有關各種合并問題的信息。您將發現解決合并問題會使您開發三維中心的工作變得非常容易。您可以開發在中心可復用和共享的 SOA。分析師將發現解決該問題會使他們的設計和分析三維空間的中心的工作變得非常容易。他們可以確定在不會導致中心超負荷的前提下哪個主機系統可以連接到中心。