使用多重面向服務的體系結構（Service-Oriented Architectures，SOA）可以消除企業系統之間的差異。Judith M. Myerson 向您展示了四種場景，它們將 Web 服務結合到復合應用程序中，該應用程序由獨立 SOA、多重 SOA、具備多重 EAI 應用程序的獨立 SOA 以及具備 EAI 應用程序的多重 SOA 復合而成。然而仍舊要考慮各種權衡，確定系統可以攜帶的 SOA 的最大數目可以使您避免 SOA 的超載。
引言
在服務級協議（Service-Level Agreements，SLA）系列的第三篇文章（“在 Web 服務上下文中使用 SLA”，請見參考資料）中，我談論了 Web 服務是如何作為 EAI 限制來補充 Enterprise Application Integration（EAI）應用程序的。我進一步討論了使用 SOA 來消除企業系統之間的差異的場景，向您展示了如何執行獲取 EAI 應用程序所有權的 Web 服務的業務邏輯。我向您展示了如何復用以數據為中心的 Web 服務以及來源于一個或更多 SOA 的業務邏輯并將它們結合進復合應用程序中。
EAI 差異
我重在研究 EAI 解決方案的三個主要的局限：所有權、有限的集成以及缺少開放行業標準。在公司的 EAI 應用程序之間存在信息傳遞的差異，例如：
- 客戶關系管理（Customer relationship management，CRM）
- 投資關系管理（Investor relationship management，IRM）
- 供應鏈管理（Supply-chain management，SCM）
- 企業資源規劃（Enterprise resource planning，ERP）
EAI 應用程序的所有權性質受到公司應用于 EAI 應用程序中的業務流程類型和公司經營的業務類型的限制。EAI 解決方案限制了使用外部應用程序來集成 EAI 系統的范圍。對于在 EAI 系統及外部應用程序之間映射業務邏輯的計劃的定制是浪費時間并且代價昂貴的。
實現 EAI 的標準事實上是不存在的。沒有標準，在互聯網上整合多商家的 EAI 應用程序是非常困難的。與 EAI 不同，Web 服務提供了廣泛的標準，為應用程序與外部的服務提供者之間搭建了橋梁。然而，EAI 比 Web 服務更加安全，IT 行業聯合起來創建并改善了現有的標準（WS-Security）為 Web 服務提供了更加安全的機制。
消除差異
各種窗體的中間件技術已經被用于消除 EAI 差異。Web 服務是使得 EAI 應用程序能夠互相傳遞信息的最好的中間件。它們提供了開放的行業標準，為獨立平臺的 EAI 系統搭建了橋梁。一些附加的 EAI 應用程序承擔了開放行業業務流程的提供者或客戶的職責，EAI 應用程序不能在封閉環境下采用該流程。
事實上，在獨立 SOA 中不是所有 Web 服務都可用。您可以將 Web 服務與基本功能相結合形成復合的 Web 服務應用程序。相反，您可以將這些應用程序同其它的 Web 服務或其它 SOA 中的復合業務相結合來建立新的或更高級的業務服務。這意味著您可以使用多重 SOA 來消除 EAI 應用程序之間的或系統之間的差異。
編制 Web 服務
在 SOA 中，使用一系列高級業務服務的業務流程來編制多重 Web 服務的執行。以數據為中心的 Web 服務很少自我執行。編制的目標是使得 Web 服務能夠消除 EAI 的差異，以便具有所有權的 EAI 應用程序可以通過整合的集線器來互相交流。
在編制過程中，您可以擴大或縮小編制的范圍和性質，通過復用代碼來改變復合應用程序的業務流程邏輯。基于個人提出的功能，SOA 中的 Web 服務可被復用并結合到高級服務的復合應用程序中來創建新的業務服務，反之，該業務服務可被復用并結合到另一個 SOA 的業務服務的高級復合應用程序中。
避免錯誤
我想到了當開發 Web 服務或將 Web 服務結合進復合應用程序時可能發生的四個錯誤，您應當避免：
- 簡單對象訪問協議（Simple Object Access Protocol，SOAP）的開銷
- SOAP 互用性問題
- 緊密結合的業務服務
- 處理繁重事務的環境。
在每個地方都建立 Web 服務并且將它們結合到所有 Web 服務的應用程序中是不太實際的，即使 Web 服務是基于日益擴大的開放行業標準的（EAI 應用程序缺少這些標準）。當處理 Web 服務時企業可能會產生大量的 SOAP 開銷，這樣就減慢了完成業務流程的速度。
企業也可能遇到 Web 服務中的 SOAP 互用性的問題。雖然已經完成了大量的工作，使 SOAP 的互用性得到了提高，但是還沒有實現行業級的完全互用。
一些具備所有權的 EAI 應用程序可以在緊耦合的環境下很好地執行某些業務功能，在復合應用程序中的 Web 服務不能在松耦合的環境下很好地執行。一個緊耦合的業務服務的實例是客戶將卡插入讀卡機中，確認卡的金額，指定取出的現金并收到自動地從他的帳戶中取款的確認。
在短時間內一些 Web 服務連同其它的 Web 服務（包括長期運行的基于一套復合業務規則的應用程序）一起完成了業務流程，在整合這樣的 Web 服務的過程中您可能會發現問題。Web 服務非常適合于短時間運行的應用程序，而不適合于處理繁重事務的環境，因為在這樣的環境下需要很長時間才能完成業務流程。
獨立的 SOA 場景
現在我們來看一下您怎樣才能使 Web 服務同基本功能相結合來構建復合的 Web 服務應用程序，假設裝載的性能是令人滿意的。考慮下面的 Web 服務，每個都來自于完全互用的系統：
- 零售商的標識符
- 零售商的名稱
- 零售商的地址
- 定購的數量
- 價格
- 稅務
如圖 1 所示，前四種 Web 服務僅包含基本功能的數據，而最后兩個主要使用業務邏輯來達到向零售商發送帳單的目的。我將所有的都結合到復合的具備帳單功能的應用程序中，也就是在結帳應用程序中進行處理。
圖 1. 獨立 SOA 的場景
我使用零售商標識符的 Web 服務來啟動流程，該服務向零售商名稱的 Web 服務發出請求來獲得與零售商標識符相匹配的名稱。當確認信息的時候，零售商名稱的 Web 服務與零售商地址的 Web 服務、定購數量的 Web 服務、價格的 Web 服務和稅務的 Web 服務相結合來建立具備零售商帳單功能的復合應用程序。隨后，在基于服務的業務邏輯的結帳應用程序中處理了該復合應用程序。
多重 SOA 的場景
我們假設小公司缺乏內部的 Tax Service 部門。對于更新、維護的業務有外來的稅務服務并且管理外來稅務的 Web 服務。對于該公司，我將第一個場景中的前五種 Web 服務結合進具有帳單功能的復合應用程序中，同時假設裝載流程的性能是令人滿意的。
我們假設 Web 服務發出了請求——將第二個 SOA 中外來的 Web 服務與第一個 SOA 中的復合應用程序相結合。如果接受并實現了該請求，那么在基于價格和稅務服務的業務邏輯的結帳應用程序中將處理高級的復合應用程序。如圖 2 所示，第二個 SOA 與第一個 SOA 交疊，該交疊的部分可能包含 SOA 中普遍的 Web 服務和非 Web 服務。
圖 2. 多重 SOA 的場景
獨立 SOA 調用 EAI 應用程序
重在關聯、鏈式管理，資源規劃的 Web 服務有不同的整合規則（或虛擬的整合集線器），即使它們在整合企業之間的應用程序的過程中可以互相合作。相反，EAI 系統的組件可以通過中間件技術的整合集線器來互相傳遞信息使得 EAI 應用程序能夠同遺留系統、數據庫、Web 服務及非 Web 服務進行交互。
我們將 SOA 作為實現多重 EAI 應用程序（在防火墻內部及防火墻外部）的業務功能的主要的中間件技術。為了避免 SOAP 開銷，限制 Web 服務的數量。同時，避免降低裝載由 Web 服務調用的 EAI 應用程序的速度。
在獨立 SOA 調用多重 EAI 應用程序的場景中，零售商標識符的 Web 服務首先調用了 Retail Management System（請見圖 3）。在成功地裝載了所應調用的應用程序之后，Web 服務發出了將標識符與名稱及地址相鏈接的請求。
圖 3. 調用多重 EAI 應用程序的獨立 SOA
然后 EAI 應用程序在數據庫中搜索請求的項目。如果找到了名稱及地址，那么它就向 SOA 發出信息來將定購數量及價格的 Web 服務添加到復合應用程序中。同時卸載 Retail Management System 來為今后調用其它 EAI 應用程序提供空間。
接下來，復合應用程序調用了 Finance Management System，該系統維護 Tax Service 流程規則的數據庫。在成功地裝載了該 EAI 應用程序之后，定購的數量及價格的應用程序與其相連。高級復合帳單功能就形成了。同時卸載 Finance Management System。
多重 SOA 調用 EAI 應用程序
現在，我們假設需要兩個 SOA 連接兩個 EAI 應用程序。在該場景中，我將 Order Quantity 和 Order Description Web Services 結合到第一個 SOA 中。我重復了第三個場景中的流程，調用并裝載了零售商標識符的 Web 服務，并且向 Retail Management System（請見圖 4）發出搜索請求。在成功搜索完之后，該 EAI 應用程序向 SOA 發出信息來將其添加到復合應用程序中。
圖 4. 多重 SOA 調用多重 EAI 應用程序
接下來，復合應用程序調用并向 Order Management System 發出請求來搜索 Pricing Policies 數據庫。在成功搜索之后，Order Management System 將其本身與第二個 SOA 中的稅務 Web 服務相連接。然后，稅務 Web 服務被并入了第一個 SOA 的復合帳單功能中。所有裝載及卸載的流程都成功地完成了，沒有出現 SOAP 開銷問題。
有多少 SOA？
您用于鏈接 EAI 應用程序的可用的 SOA 的數量依賴于對項目的復雜性、互用性問題、業務流程及裝載性能問題的權衡。同您避免 SOAP 的開銷一樣，您需確保在整個開發周期中不會出現 SOA 超載問題。您應當在開發的每個階段都進行超載測試。
結束語
使用 SOA 來消除企業系統之間的差異需要提前規劃，設置需開發的 SOA 的數量限制。您應當同業務分析師及 IT 專家小組對于各種性能問題進行交流。您會發現使用 SOA 來消除 EAI 差異這種方法使您開發應用程序的工作變得更加容易。您可以將來源于一個或更多 SOA 的 Web 服務的業務邏輯結合成一個或更多的復合應用程序。分析師將會發現消除差異使得他們設計及分析 SOA 系統的工作變得更加容易。他們可以確定結合哪些 Web 服務能夠達到最佳的性能，并且不會發生 SOAP 超載的問題。