iweroulsdjf

企業服務總線（Enterprise Service Bus，ESB）體系結構模式支持在面向服務的體系結構 (SOA) 中虛擬化服務交互并對其進行管理。它使得交互可以在服務提供者和服務請求者之間進行，并且可以使用各種中間件技術和編程模型加以實現。它對本系列的前一篇文章中介紹的 SOA 編程模型進行了擴展。

引言

SOA 提供了一種靈活的、可擴展且可組合的方法來重用和擴展現有應用程序以及構造新的應用程序。服務聲明它們實現的或期望其他服務實現的接口，并且聲明控制潛在伙伴交互的策略，從而公布各種功能（包括提供的和請求的）。Web 服務描述語言（Web Services Description Language，WSDL）和其他 Web 服務標準（如 WS-Policy）提供了用于這些聲明的詞匯。（請參閱參考資料，以獲得指向 WSDL Version 2.0 Part 0: Primer 的鏈接。）

業務功能的虛擬化（SOA 的一個主要目標）是通過將服務的定義和使用與服務的實現分離開來而實現的。我們可以使用各種技術實現服務，這些技術包括 IBM WebSphere? MQ、IBM CICS? 或 IBM IMS?、Java? 2 Platform Enterprise Edition (J2EE) Enterprise JavaBeans (EJB)、Java 類、IBM DB2? 查詢、Java 消息服務 (JMS) 或 Microsoft? .NET。服務請求者將請求發送到提供其所需功能的服務提供者，而不必考慮它如何實現。

ESB 是一種體系結構模式，支持虛擬化通信參與方之間的服務交互并對其進行管理。它提供服務提供者和請求者之間的連接，即使它們并非完全匹配，也能夠使它們進行交互。此模式可以使用各種中間件技術和編程模型實現。

本文將定義 ESB 模式和它在 SOA 內的角色。后續文章將詳細描述其使用場景、使用目前的技術實現 ESB 模式的方法，以及 ESB 技術未來的發展方向。

什么是 ESB？

在 ESB 模式中，服務交互的參與方并不直接交互，而是通過一個總線交互，該總線提供虛擬化和管理功能來實現和擴展 SOA 的核心定義。IBM ESB 模式提供以下幾方面的虛擬化：

• 位置和標識：參與方不需要知道其他參與方的位置或標識。例如，請求者不需要知道請求是否可以由某個提供者提供服務。您可以隨意添加或刪除服務提供者，而不會帶來任何干擾。
• 交互協議：參與方不需要采用相同的通信協議或交互方式。表達為 SOAP/HTTP 的請求可能由僅理解 Java 遠程方法調用 (RMI) 的提供者提供服務。
• 接口：請求者和提供者不需要就公共接口達成協議。ESB 可以通過將請求消息轉換為提供者所期望的格式來處理此類差異。
• （交互）服務質量 (QoS)：參與方聲明其 QoS 要求，包括性能和可靠性、請求的授權、消息內容的加密/解密、服務交互的自動審核以及如何對請求進行路由（如根據工作負載分布標準將請求路由到可用的實現）。描述請求者和提供者的 QoS 要求和功能的策略可以由服務自己實現或者由進行不匹配補償的 ESB 實現。

因此 ESB 模式使請求者不用了解服務提供者的物理實現——從應用程序開發人員和部署人員的角度來看均是如此。總線負責將請求交付給提供所需功能和 QoS 的服務提供者。提供者接收他們要響應的請求，而不知道消息的來源。ESB 本身對使用它的服務請求者和提供者均不可見。應用程序邏輯可以使用各種編程模型和技術調用或交付服務，而無需考慮是直接連接還是通過 ESB 傳遞的。連接到 ESB 是部署決策；應用程序源代碼不會受到影響。

ESB 支持許多交互類型，包括單向、請求/響應、異步、同步和發布/訂閱。它還支持復雜事件處理（在復雜事件處理中，可能會觀測到一系列事件），以產生一個事件作為該系列中的關系的結果。

圖 1 對基本 ESB 模式進行了描述。消息流過將各個通信參與方相互連接在一起的總線。某些參與方會調用其他參與方提供的服務；而其他參與方則會向感興趣的使用者發布信息。端點與 ESB 交互的位置稱為服務交互點 (SIP)。例如，SIP 可以是 Web 服務端點、WebSphere MQ 隊列或 RMI 遠程對象的代理。服務注冊表將捕獲描述以下內容的元數據：SIP 的要求和功能（例如，提供或需要的接口）、它們希望與其他 SIP 的交互方式（例如，同步或異步，通過 HTTP 或 JMS）、它們的 QoS 要求（例如，首選的安全、可靠交互）以及支持與其他 SIP 交互的其他信息（例如，語義注釋）。

圖 1. 基本 ESB 模式

將總線插入參與方之間，提供了將它們的交互通過稱為中介 的構造進行協調的機會。中介對請求者和提供者之間動態傳遞的消息進行操作。對于復雜的交互，可以按順序將中介連在一起。中介模式部分討論了實現這些虛擬化、QoS 和管理概念的常用中介模式。

ESB 模式為 SOA 實現提供了靈活且易于管理的方法。總線透明地插入端點之間，可以提高服務質量，可以促進請求者和提供者間的交互（而不受協議、交互模式或服務功能不匹配的影響），還可以支持監視和管理。

SOA 用戶角色及其任務

通過研究創建和管理 SOA 解決方案的用戶的角色及任務，可以進一步深入了解 ESB 模式。ESB 工具和運行時將 SOA 解決方案的生命周期劃分為四個階段：

• 發現與描述：對可以在整個 ESB 中進行互連的 SIP 進行標識和描述。這包括創建新的服務、發現現有服務、以及描述其接口、要求和功能。
• 建模與構建：通過新建的或現有的中介進行 SIP 互連，以描述解決方案的端到端交互。
• 配置與部署：針對特定的運行時拓撲配置解決方案的抽象聲明，并對其進行部署，同時創建必要的運行時構件。
• 監視與管理：通過 SIP 和中介的行為監視和管理解決方案。此階段將使用 ESB 運行時中的檢測和控制點、以及觀測和響應消息流的中介。

對于 ESB 中間件，最重要的 SOA 解決方案開發角色是集成開發人員和解決方案管理員，但其中也涉及到業務分析人員、解決方案架構師、實現人員、適配器開發人員和操作人員。（這些角色都是概念性的；一個人可以擔任其中的多個角色。）圖 2 顯示了這些角色交互的方式。

業務分析人員確定業務需求，并檢查業務流程。他們將概括出解決方案的目標、涉及的業務流程、監視解決方案的運行狀況和狀態的關鍵指標，以及 IT 系統需要提供的業務服務的類型。

解決方案架構師確定哪些業務需求可以通過對現有 IT 資產進行重用、修改或組合得到滿足，哪些需要編寫或購買新的 IT 資產。他們定義 IT 資產間的交互，包括消息交換的內容。

開發工作在三個角色中分配。實現人員編寫新的應用程序代碼，這些代碼將通過服務接口調用。適配器開發人員構建包裝現有或新采購的應用程序和軟件包的服務，從而為其他服務提供可訪問性。集成開發人員使用 ESB 的相關工具和技術構建邏輯，以控制請求在這些服務間路由的方式。

圖 2. 用戶角色

解決方案管理員部署新的 IT 資產并將其服務定義導入到服務注冊表中，從而使新的 IT 資產可用。當解決方案就緒后，操作人員將監視其執行，根據需要啟動和停止 IT 系統，并給解決方案管理員提供建議（后者可能將據此調整解決方案配置）。

ESB 模式

集成開發人員和解決方案管理員會使用一組模式對 SOA 解決方案進行設計和部署。

圖 3. 基本 ESB 模式的元素

基本 ESB 模式將應用程序組件抽象為一個服務集，這些服務通過總線進行交互（而不是通過直接的點到點通信交互）。某個給定的服務既可以是提供者，也可以是請求者，或者同時兼有兩個角色。任何 SOA 實現都會支持基本虛擬化，允許在不影響依賴請求者的情況下替換等效提供者實現。ESB 模式通過其對請求者/提供者交互的顯式管理提高了此基本 SOA 功能。只要能提供與請求者所需的功能相似的功能，且 ESB 能對其進行協調，任何提供者都可以由另一個提供者替代。

ESB 提供了交互點，服務可以在此將消息放到總線上或從總線取走。它會對動態消息應用中介，并保證這些托管交互的 QoS。

從 ESB 的角度來看，所有的服務交互端點都是類似的，因為它們都發送或處理請求/事件；它們都要求特定的 QoS；它們可能都需要交互協助。ESB 模式允許集成開發人員以與處理新業務邏輯、流程編排組件或外部 Web 服務同樣（面向服務）的方式對待與用戶交互的請求者或提供者。

用于構建基于 ESB 的解決方案的模式分為以下幾類：

• 交互模式：允許服務交互點將消息發送到總線或從總線接收消息。
• 中介模式：允許對消息交換進行操作。
• 部署模式：支持將解決方案部署到聯合基礎設施中。

交互模式

ESB 允許端點通過總線以其本機交互模式進行交互。它支持各種端點協議和交互方式。交互模式的例子包括：

• 請求/響應：處理端點間的請求/響應方式的交互。此 ESB 基于消息傳遞模型，因此由兩個相關的單向消息流對請求/響應交互進行處理，一個用于請求，一個用于響應。
• 請求/多響應：上述類型的變體，可以發送多個響應。
• 事件傳播：事件可以匿名分發到由 ESB 管理的相關方列表。服務可以將自身添加到該列表中。

圖 4. 交互模式

中介模式

中介模式處理總線上的動態消息（請求或事件）。由請求者發出的消息會轉換為稍微有些不兼容的提供者（從潛在的端點集中選擇）能夠理解的消息。

這些中介操作單向消息而不是請求/響應對，因為 ESB 將交互模式放在中介模式上。

圖 5. 中介模式

中介有多種基本模式；更為復雜的模式可以通過組合簡單模式構建：

• 協議變換：允許服務請求者使用各種交互協議或 API（如 SOAP/HTTP、JMS 和 MQ Integrator——MQI）發送其消息。將請求代碼轉換為目標服務提供者的格式。可以應用到交互的請求者端或提供者端，或同時應用到兩端或兩者之間的任何位置。
• 轉換：將消息的有效負載（內容）從請求者的模式轉換為提供者的模式。可以包含包封、反包封或加密。
• 充實：通過添加來自外部數據源的信息（如由中介定義的自定義參數或者來自數據庫查詢的自定義參數）來增加消息的有效負載。
• 路由：更改消息的路由，可從支持請求者的意圖的服務提供者中選擇。選擇標準中可以包含消息內容和上下文、以及目標服務提供者的功能。
• 分發：將消息分發到一組相關方，通常由訂閱者的相關概要驅動。
• 監視：在信息通過中介時觀測其是否發生改變。可以用于監視服務水平；幫助確定問題或對用戶進行后續支付使用的貨幣單位；或記錄企業級事件（如價值超過一定數額的購買行為）。還可以用于將消息記入日志，以供審核和后續數據挖掘之用。
• 相關：從消息或事件流中派生復雜事件。包括模式標識規則和響應模式發現的規則（例如，通過生成派生自觸發事件流的內容的復雜事件）。

可以在解決方案中顯式地配置中介。例如，集成開發人員可以配置一個 enrich 中介來修改消息內容。解決方案管理員可以配置一個 route 中介來允許其將某個服務提供者切換到脫機狀態。

其他中介由 ESB 設置，以滿足服務請求者和服務提供者的 QoS 要求。例如，如果服務提供者的安全策略聲明要求使用加密消息，則 ESB 可以自動配置一個 encryption 中介。

策略同樣也是服務的屬性，解決方案管理員可以為交互（或交互集）設置策略。例如，為了將要發送到特定外部提供者或交易值超過 1 百萬美元的所有消息記錄到日志中。ESB 將通過配置中介（在本例中為monitor 中介）來實現策略。

復雜模式

圖 6. 復雜模式

中介模式和交互模式可以進行組合，以實現更為復雜的模式。

例如，在協議變換后轉換格式可以實現規范化適配器 模式，在這種模式中，所有相關方使用的消息和業務對象集都標準化為規范的格式。規范化適配器模式將端點的本機總線附加協議轉換為標準協議，實現有效負載規范化，并在交付時進行這些轉換的反向轉換。

另一種常見的復雜中介是轉換、記錄和路由 模式。

網關 模式是一個復雜的協議變換變體。它可以合并轉換和監視中介，以提供加密、日志記錄或審核等功能。它還可以對一對多關系中的消息進行聚合和反聚合。服務門戶是此類模式的代表，它為多個服務提供單一聯系點，并隱藏內部服務的細節。

部署模式

解決方案管理可以選擇多種 ESB 拓撲。下面是一些常見的例子：

• 全局 ESB：所有服務共享一個名稱空間，每個服務提供者對環境（異構、集中管理但分布在多個地理位置）中所有服務請求者均可見。供部門或小型企業使用，其中，所有服務都可能在整個組織中應用。
• 直接連接的 ESB：公共服務注冊中心使幾個獨立的 ESB 安裝中的所有服務均可見。用于由業務部門提供和管理服務但整個企業中均可使用這些服務的場合。
• 代理 ESB：橋接服務有選擇地將請求者或提供者公開給其他域中的合作伙伴，從而控制多個 ESB 安裝（每個安裝都管理自己的名稱空間）間的共享。ESB 間的服務交互通過實現橋接服務的公共代理進行。供各個部門使用，這些部門開發和管理自己的服務，但共享其中部分服務或者有選擇地訪問企業提供的服務。
• 聯合 ESB：將多個依賴 ESB 聯合到其中的主 ESB。服務使用者和提供者連接到主 ESB 或某個依賴 ESB，以訪問整個網絡中的服務。供希望在一個監管部門的保護下聯合有適度自治權的部門的組織使用。

圖 7. ESB 部署模式

結束語

ESB 模式擴展了 SOA 的虛擬化功能。可以由標準功能單元組成中介，然后進行部署，以幫助不匹配的請求者和提供者進行交互。ESB 還提供了用于部署和管理服務的通用模型。ESB 概念允許根據用戶角色單獨進行考慮，從而減少了單個工作人員的概念上的負擔，并改進了體系結構的可用性。ESB 的綜合編程模型、組件化工具以及基礎設施極大地支持了 SOA 原則的提前實現。