思考：
1.ESB的定義到底是什么？是一款產品還是一種架構模式？
2.ESB有何實際用處？
定義ESB
對於企業服務總線（Enterprise Service Bus），目前還沒有公認的定義，根據供應商和來源的不同，有很多種不同的定義，其中包含如下定義：
一種集成架構樣式，支持提供者和服務用戶之間通過由各種點對點連接構成的公共通信總線進行通信”
“企業用來集成應用程序環境中服務的基礎架構。”
“一種架構模式，使用面向服務支持異構環境之間的互操作性。”（圖 1）
圖 1：ESB 架構模式分成這幾個主要系統架構
ESB 用於服務虛擬化，通常管理更大的服務集且位於內聯網內部。
何時使用ESB？
有沒有確定何時應使用ESB實現的最佳實踐，需要集成三個或更多的應用程序或服務時，可以考慮使用ESB。連接兩個應用程序時，點對點集成非常簡單而且更經濟划算。如果要從企業無法控制的外部服務提供者獲取服務，也可以考慮使用ESB。然后，可以使用ESB監視外部提供者保證的服務級別協議。可進一步將服務合同調整的影響控制到最小，因為ESB對消息進行必要更改的同時將繼續提供一個穩定的接口。
如果使用多種不同協議（如果：http、SQAP和FTP）並將它們標准化成一個協議（如SOAP），ESB可以執行必要的協議轉換。如果始終需要將服務合並成一個架構才能接收、處理和生成消息，那么使用ESB也比較合適。如果需要訪問一組預定義的組件和適配器，ESB也同樣使用，這將支持以標准化方式集成各種協議和原有應用程序。如果需要安全、可靠地處理消息，ESB可以簡化兩個異構事務性數據源之間事務性消息流的實現。
如果需要通過總線將大量數據作為大量獨立消息進行發送，那么使用 ESB 可能存在一些問題。ESB 絕不應取代傳統數據集成，比如 ETC 工具。將數據從一個數據庫復制到另一個數據時，使用數據集成可能更高效，因為該操作只會不必要地增加 ESB 的負擔。
如果需要實現長期業務流程，ESB 應支持無狀態的消息流。長期運行的業務流程是有狀態的，最好使用 BPEL 和/或 BPMN 實現。這些流程通常無法通過 ESB 實現，但可以通過業務流程管理系統 (BPMS) 實現。
ESB 藍圖
由於缺乏標准化，ESB 市場相當混亂。很多產品自稱是 ESB，但是提供的解決方案卻大相徑庭，而且基於不同的架構。為了更有效地評估 ESB 產品，我們將分配給 ESB 的各種功能組織成了一個藍圖（圖 2）。
圖 2：企業服務總線藍圖
ESB 藍圖不包括“編排”或“流程編排”組件，因為這被視作 BPMS 類別的一部分。它們為長期運行的、有狀態的業務流程提供專用的運行時環境，這些流程為此進行了優化，支持 BPMN 或 BPEL 之類的語言。ESB 應該是無狀態的，並且應配置為盡可能高效地處理消息。
操作和管理模塊
該模塊中的以下功能組件支持可靠的企業服務總線操作和管理。統計信息與狀態 提供服務的 ESB 統計信息，如錯誤數量、最小和最大響應時間以及處理的消息數。警報 提供一個發送警報消息的機制，可通過各種通道發送，因此也可以集成到現有監視環境中。SLA 規則 是在統計信息與狀態 功能組件的信息基礎上定義的規則。支持度量和監視 SLA。可以使用警報 組件通知任何 SLA 侵權。
消息跟蹤 可以在 ESB 中輕松跟蹤消息，應在需要時激活，以便將相關開銷降至最低。消息重新傳遞 確保在預定義時間后自動重新發送未及時處理的消息。可以配置嘗試次數以及它們之間的時間間隔。該組件主要適用於僅持續一段時間的技術錯誤，如臨時網絡中斷。端點故障切換 可以指定一個備用服務提供者，在主服務提供者不可用時自動調用。
負載平衡 可以列出一個邏輯服務提供者端點的幾個服務端點。它使用冗余服務實現，根據定義的策略交替調用每個請求，可以循環調用，也可根據消息優先級和負載依賴關系進行調用。
消息限制 可以定義應被發送到服務提供者的服務端點的每單元時間內的最大消息數。它通過緩沖 ESB 隊列中超過閾值范圍的消息來防止服務提供者在高峰時段重載。消息限制 還支持消息優先級，這樣可以確保始終先處理高優先級的消息。記錄與報告 支持記錄消息，方便以后顯示。它還提供功能審計。
配置管理 支持在操作系統上安全地調整 ESB 配置，同時始終維護配置的完整性。可在操作過程中調整和替換構件和屬性。還可以保存變更歷史記錄，這樣 ESB 服務可以隨時回滾到早期狀態。服務注冊表 可以在 ESB 上注冊和管理服務。高可用性 確保 ESB 提供的服務是故障安全的，與運行這些服務的服務器的狀態無關。
錯誤醫院 是那些經過多次重新傳遞嘗試仍無法處理的消息的目的地，可以在這里查看、更正（如果需要的話）以及重新處理這些消息。部署 可在 ESB 上自動安裝服務。特定於環境的參數（如端點 URI）通常是由該組件重寫的。服務使用情況 支持記錄服務使用情況並向用戶收取費用。
調節模塊
調節模塊包含用於實現 ESB 服務消息流的功能組件。消息路由 支持根據消息的內容將消息其轉發至特定服務端點。如果使用的協議或消息格式支持與消息正文無關的消息頭區域，轉發標准可能源於消息正文或消息頭。
根據消息頭進行路由可能是一個極具吸引力的選擇，可提高服務性能和可擴展性，因為直接訪問消息頭比解析來自消息正文的路由信息更高效。這對於大型消息來說尤其重要。
消息轉換 支持從一種消息格式轉換為另一種適用於文本和二進制消息的格式以及 XML 格式。此外，還可以從文本（如 CSV 格式）轉換為 XML，或者從 XML 轉換為文本（如 CSV 格式）。XML 轉換使用著名的 XSLT 標准，XSLT 支持對轉換進行聲明性描述，並且擁有帶拖放功能的圖形資源以實現創建目的。
XSLT 轉換的主要缺點是，如果處理大型文檔，內存使用量過高，這可能會限制解決方案的可擴展性。如果 ESB 提供支持 XML 流轉換的選項（比如，通過 XQuery），那就更好了。
服務調出 可以在 ESB 中訪問消息流中的其他服務，比如增強一條消息。服務可能是一個 Web 服務，但 ESB 可以如您所願地支持直接調用 ESB 中本地安裝的程序代碼（如 Java 類方法）。可靠的消息傳遞 支持使用隊列或 WS* 標准（如 WS-ReliableMessaging）可靠地傳遞消息。
協議轉換 意味着無需任何編程工作即可從某個通信協議切換到另一個協議，比如，從 TCP/IP 切換到 HTTP。消息驗證 確保消息是有效的。在 XML 中，這意味着消息包含規范定義的 XML 並對應於特定的 XML 模式或 WSDL。不過，ESB 還提供了其他驗證方法，如 Schematron 或規則引擎。
消息交換模式 (MEP) 支持消息交換模式，如同步和異步請求/應答、單向調用以及發布/訂閱。結果緩存 可以在緩存中保存服務調用結果，這樣返回同樣結果的后續調用可從緩存獲得應答，無需再次調用服務。如果數據是靜態的或者需要零星或少許的改動，此功能尤為適合。可大大減少像訪問原有系統這樣的開銷可能較大的操作。
事務 支持 ESB 通過消息處理提供事務完整性。ESB 用於支持可靠消息傳遞 的持久隊列通常作為事務數據源，因此可參與異構事務。此外，ESB 還提供了一個分布式事務管理器，可使用兩階段提交協議通過異構數據源協調分布式事務。
消息重新排序 使屬於一個整體但順序不對的消息流可以重新排序。在並行處理消息的面向消息的解決方案中，消息進入 ESB 的順序可能會丟失。如果順序對於服務提供者很重要，消息重新排序 可以合並到消息流中。重新排序器包含一個內部緩沖區，緩沖區對消息進行處理，直至排序完成且可發送。
直通式消息傳遞 可以令 ESB 高效轉發 ESB 消息。如果要將 ESB 用於服務虛擬化，並且將消息從服務使用者原樣轉發至服務提供者，這將非常有用。在這種情況下，如果 ESB 不接觸消息，只是簡單地按原樣傳遞，該功能非常適用。
安全模塊
該模塊使用大量組件支持傳輸級和消息級安全性。當服務使用者訪問 ESB 中的服務時，身份驗證 驗證其身份，並驗證針對服務提供者的 ESB 身份驗證。授權 為服務提供了一個授權系統，通常可通過 XACML 對這些服務進行配置，以便分配給用戶或角色。
安全調節 支持交互，通過將一個域的憑證轉換成另一個域的相應憑證在安全域之外進行通信。加密/解密 支持消息內容的加密和解密。
適配器/傳輸模塊
該模塊包括的適配器可通過服務托管模塊連接 ESB 提供的服務。假設 ESB 從無到有提供一組適配器，客戶或第三方開發人員還可以開發其他適配器以滿足具體的用戶需求。
服務托管模塊
該模塊支持在 ESB 上直接安裝和操作服務，如果 ESB 基於應用服務器，該模塊通常是必需的。服務容器 提供一個或多個容器，在其中安裝服務和管理生命周期。它提供可訪問技術橫截面功能（如事務和安全性）的服務。
組件模型 提供了一個抽象的組件模型（如 Java EJB、Java Spring Framework 或 Microsoft COM+），在此基礎上創建服務。
ESB 的實際應用場景
圖 3 所示的符號用於以圖形化方式描述各種場景，無需參考產品或工具。這些符號來自於 [1]，根據 ESB 功能不斷添加。
圖 3：ESB 符號
場景 1 — 服務虛擬化
服務使用者往往更喜歡硬連接實際服務端點，特別是在 BPEL 流程中，因為使用提供的工具可輕松執行。然而，在運行時對服務器地址的改動絕對不能產生需要在服務客戶端進行重新部署的改動。這個問題的一個非常好的解決 方案是使用 ESB 虛擬化端點。圖 4 展示了這個場景，服務提供者提供的 Web 服務接口不再由服使用者直接使用，而是通過 ESB 來使用。ESB 可以完全按照為潛在的服務使用者提供接口那樣提供接口。
圖 4：使用額外的監視攔截器虛擬化服務
在 ESB 配置過程中可以輕松實現需要對端點地址進行的任何改動，因此服務使用者可以像以前一樣繼續運行。然而，ESB 需要能夠合並到現有消息流中。服務虛擬化還支持使用擴展到服務統計信息的 ESB 監視功能，以便檢查 SLA 合規性，如果不合規的話，則配置適當的操作。如果服務提供者對服務合同進行了更改但不想影響服務使用者，可以執行服務虛擬化。在這種情況下，對交換的消息 進行簡單的轉換即可解決此問題。
場景 2 — 服務支持
當納入具有功能接口的服務時，通常會出現的情況是，服務使用者和服務提供者在協議級別使用不同的語言。圖 5 介紹了兩個服務提供者，從技術上來說它們提供的是相同的服務，一個提供的是 SQL 接口，另一個提供的是 FTP 接口。可以將企業服務總線用作協議轉換器以保持接口不變，因為它提供的方法可確保使用定義的接口。
圖 5：服務支持
與場景 1 類似，如果通信協議將來發生變化，ESB 可確保服務使用者或服務提供者端無需后續更改。
場景 3 — 安全的消息處理
ESB 還能支持傳統集成場景，主要目的是將消息從一個系統轉發到另一個系統。在圖 6 所示的場景中，ESB 使用來自外部隊列的消息，使用對一個 Web 服務的服務調出來豐富這些消息，然后通過數據庫適配器將消息發送到目標系統。
圖 6：安全的消息處理
ESB 中的處理是事務性的，意味着將消息流配置為像其他參與者一樣參與分布式 XA 事務。使用隊列中的消息時將啟動事務，事務還包含數據庫適配器執行的數據庫操作。如果消息流成功完成，緊接着會提交分布式事務。
場景 4 — 服務版本控制
服務往往隨着時間而改變，通常需要引入一個新的不兼容版本。在這些情況下，可以使用 ESB 執行從“舊”接口到“新”接口的轉換。在圖 7 所示的場景中，服務提供者引入了服務的 2.0 版本，服務使用者 B 立即安裝了該版本。服務使用者 A 一直使用接口 1.0，不想切換到 2.0 版本，因為不會給業務帶來任何附加值。然而，服務提供者不想讓這兩個版本並行運行。同時運行兩個接口可能比較困難，甚至在技術上不可行，而且會導致不必要 的資源消耗。
圖 7：服務版本控制
如果 ESB 通過直通式傳遞（類似於場景 1）直接提供 2.0 版本，情況可能比較簡單。同時，在適應現有消息流的同時必須提供接口 1.0 版本，這樣將不再從服務提供者處調用 1.0 版本。相反，消息是從 1.0 版本轉換到 2.0，然后發送給新服務。這種轉換可能相對比較復雜，具體取決於兩個版本之間的差異有多大。為了提供調用 2.0 版本所需的所有信息，可能需要額外豐富 1.0 版本消息。
需要維護 ESB 中的轉換和接口 1.0，直至沒有服務使用者使用舊接口。之所以在 ESB 中執行這種轉換而不是在服務提供者中從版本 1.0 映射到 2.0，具體原因如下：
- 映射是技術問題，與業務相關問題無關
- 不會影響外部服務提供者。
- ESB 使舊接口的使用透明。
- 當所有服務使用者都改用接口 2.0 后，無需更改服務提供者。
總結
ESB 是一個中間件解決方案，使用面向服務的模型來促進和支持異構環境之間的互操作性。沒有規范准確定義了什么是 ESB 或者它應該提供什么功能。雖然 ESB 主要與“調節”和“集成”這類概念相關，但它還適合作為一個平台以類似於應用服務器的方式提供服務。ESB 代表被稱作“集成”和“應用服務器”的產品類別的整合。
ESB 的一個關鍵特性是服務虛擬化。本文提出的 ESB 藍圖提供了各種功能的有序排列，構成了評估 ESB 產品的基礎。
要點
- 企業服務總線應被視為一個架構樣式或模式，而不是一款產品。
- ESB 沒有定義或規范，因此也沒有標准。
- ESB 可幫助實現系統間的松散耦合。
- ESB 上的服務是無狀態的。長期運行的流程不屬於 ESB，但是在使用 BPEL 和 BPMN 之類語言的 BPM 系統中受支持。
- “誤用”ESB 來執行批處理時應小心謹慎，因為可能會對性能產生負面影響。
參考資料
[REF-1] http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html