從偶然架構到一個全球規模的統一的集成基礎設施可能是像一個使人畏縮的任務。 把一切都準備就緒，然后再象扳動一下開關那樣將所有的應用都一下子轉移到新的基礎設施之上是不現實的。這已經是組織為什么老是要不斷添加偶然架構方案作為權益解決之計的一個主要的理由，甚至他們確實知道這樣使相關的問題永垂不朽也是如此。
ESB 提供了能力來幫助減輕所介紹的痛苦。 第 9 章將通過一個案例來介紹如何遠離一個完全建立在 FTP 和每夜批處理作業之上的早以存在的集成解決方案。
讓我們現在重新回到對偶然架構的討論。 在圖 2-6中，實線、虛線、點劃線代表用于集成的不同類型的連接技術和通信協議。注意其中有一個用集成Broker表達的已存在的 “集成孤島”，以及POS應用和財務應用之間的連接是使用FTP 文件傳輸。在POS應用和ERP應用之間先前已經升級來使用HTTP 之上的SOAP協議，正如銷售自動化應用 (SFA) 和客戶關系管理 (CRM) 之間的聯結。
圖表 2?6 使用SOAP通信、 FTP 、手工插座（Socket）、而且包括一個集成Broker的代表性的偶然架構
ESB 可以在一個部門級的層次或在一個項目的基礎上被引入。 在項目層次采用 ESB 允許你能夠習慣于使用 ESB 服務容器進行基于標準的集成，并且完全可以堅信該項目能夠集成到一個更大的集成網絡之中，并且與企業級的公司的集成策略目標相一致。
我們采用ESB的例子中的第一個步驟是要集成前端應用（FrontOffice）。在圖 2-7 中，前端的CRM、財務和SFA 通過“服務容器”連接到ESB 之中。這些容器是 ESB 架構的主要組件，我們將在第 6 章詳細解釋。 經過 ESB 服務容器進行的集成的特性可能會不同。 容器和應用之間的接口可以通過使用第三方的應用適配器來完成；容器可以暴露使用WSDL描述的XML數據；或者它可能被實現為完全用戶定制的代碼。
圖表 2?7 ESB 可以在不打破原有點對點路徑的前提下，在單個項目基礎上采用
但是也許更有趣的不是那些已經集成到ESB 之內的東西，而是還沒有集成進去的東西。圖 2-7 表示了已有的 FTP 和SOAP協議之間的通信線，原來是連接到前端應用的，現在直接連接到那些特別配制來使用那些協議進行通信的ESB組件。應用仍然處于總線“之外”，Pos應用和伙伴CRM應用可以與集成到ESB總線“之內”的前端應用進行通信而不需要做任何修改，對他們如何參與ESB基礎設施也不需要知道任何東西。注意，現在POS應用是連接到ESB 上的一個 FTP 橋接器，而且伙伴CRM應用則是連接到配置為總線的一部分的Web Services端點。
ESB 已經被引入了，但是對這些配備了ESB能力的應用以前所連接的點對點通信組合區沒有產生任何影響。被插入總線的應用如今轉而使用連接到ESB 集成容器的一個單一接口， 而且已經省卻了對它們先前所有其他類型的通信連接的管理和維護。
我們將會在第 9 章中看到，即使是總線域中最新集成的應用也可以就地將他們轉移到完全的ESB方式，并且與它們各自的項目開發時間線相一致。
在我們的ESB采用的例子得下一階段中，POS應用將在每一個遠端實現ESB能力，并且去除對不可靠的 FTP 聯結上的依賴。 這可能會簡單如在每一個遠端安裝一個ESB容器，并且插入到總部的ESB之中，或者涉及到在每一個遠端的多個應用之間的一個“迷你”的集成環境。那么二個 ESB節點就可以通過一個基于可靠消息的安全連接進行通信(圖 2-8)
圖表 2?8 在各個地點分立安裝的ESB可以安全和可靠地連接在一起
此外，遠端位置仍然可以在他們自己的分離集成環境里面運行，并且可以按照需要有選擇地共享數據。例如，遠端位置可以獨立地擁有并且運作一個屬于集體特許經營的零售店鋪。它們沒有必須共享關于它們的日常運作的信息，但是的確需要共享諸如價格更新和庫存信息之類的數據。遠程ESB 節點可以連接到位于總部的 ESB 網絡，有選擇地暴露消息通道以共享價格變動之類的數據。
我們的ESB 采用示例項目的第三階段涉及到橋接進進一個已經部分地與一個集線器-和-插頭 EAI Broker集成在一起的部門。我們先前提醒過，采用 ESB 不是一個全有或全無的概念。如圖 2-9 所示， ESB 允許IT部門通過將一個已存在的 EAI Broker橋接到ESB之內來保護它里面的IT資產。
圖表 2?9 “保留-和-分層”方式允許將ESB橋接到EAI Broker安裝之內
橋接 EAI Broker可以一多種方式進行。比如，它可以通過使用一個Web Services接口來完成，或者綁定到下層的消息通道。依賴于ESB和 EAI Broker 的實現，ESB 更加可以建立在EAI Broker下面的消息隊列基礎設施之上，因此部分地替換EAI Broker的功能仍然可以保留較低層的、消息通道。
我們的 ESB 采用示例項目的最后步驟是解決和業務伙伴集成的問題。如圖 2-10 所示，這可能包括原樣保留SOAP聯結，以及在每個伙伴端安裝一個 ESB 節點。決定采用哪一種方法完全依賴于你的組織和伙伴之間的關系，以及業務伙伴是否允許你在其地點安裝軟件，或者他們已經有能夠連接到你的ESB之上的ESB。
圖表 2?10 ESB 可以個別地管理與業務伙伴的SOAP聯結, 或者可以連接到另一個地點的ESB節點
插入到一個 ESB 擴展的分層的服務能夠管理對伙伴的連接的后勤保障。例如，一個特殊的伙伴經理者服務可以在每一個伙伴的基礎上管理與伙伴之間的正在進行的協作的細節。這些細節可能包括正在使用哪一個更高層次的業務協議(比如， ebXML、RosettaNet 等)、以及對話的狀態，比如消息交換的當前狀態、是否收到一個期望的應答消息、以及從業務伙伴接收到一個業務響應所能夠接受多長的時延。
本章包含下列主題：
- 對更廣泛的、更通用的集成基礎設施的需要的各種驅動因素
- 偶然架構是今天所使用的主要集成設計。 在這種系統中，當前的企業完全沒有很好地聯通的。
- 只有 10% 的應用被聯接。
- 而這些之中，只有 15%的使用了某種類型中間件。
- 到目前為止，分布式計算技術加重了，而不是解決了，偶然架構的問題。
- 集線器-和- 插頭EAI Broker已經有了一定程度的成功。然而，它們:
- 大部分是專有技術
- 沒有為組織提供一個標準化的、可以在企業內通用使用的集成平臺。
- ESB 借鑒了在 EAI Broker技術方面學習的經驗的價值。
- 集成作為是一個部門層面和公司文化的問題，和它作為一個技術上問題同樣重要。
- ESB 允許逐漸增加的采用，以符合各個部門單獨的開發時間表。