ESB 在企業體系結構中的角色和價值

　　面向服務的體系結構（Service Oriented ArchitectureSOA）提供了靈活可擴展且可組合的方法來重用及擴展現有應用程序和構造新應用程序SOA 最為重要的特征是其靈活性其中將業務流程和底層 IT 基礎設施作為安全的標准化服務對待可供重用和組裝以處理不斷變化的業務需求SOA 中的服務具有定義良好的接口此接口由消息接收和發送的一組消息定義而且接口的實現在部署之後將綁定到所記錄的服務端口

　　企業服務總線（Enterprise Service BusESB）是一種體系結構模式支持通信各方間的服務交互的虛擬化和管理它充當 SOA 中服務提供者和請求者之間的連接服務的中間層它是一個靈活的連接框架可促進可靠而安全的系統集成並同時減少應用程序接口的數量大小和復雜度

　　其中的服務不直接交互而是通過服務連接框架 (ESB) 進行通信此框架提供實現和擴展 SOA 核心定義的虛擬化和管理功能ESB 模式提供以下方面的虛擬化

　　位置和標識ESB 標識消息並在交互服務之間路由這些消息這些服務不需要知道通信中的其他方的位置或標識例如請求方不需要知道多個提供者中是否有提供者可以處理請求您可以向正在工作的 ESB 添加其他服務提供者從而允許將消息路由到這些提供者而且不會對請求者造成干擾

　　通信協議ESB 允許消息在服務請求者和服務提供者之間來回傳遞的過程中跨不同的傳輸協議或交互樣式中傳遞例如以 SOAP/HTTP 格式表示的請求可能送到僅接收 JMS 輸入的提供者

　　接口服務的請求者和提供者不需要就單一接口達成一致ESB 可以對請求者發出的消息進行轉換和充實來得到提供者預期的格式從而協調差異

　　您可以使用各種中間件產品（硬件和軟件）編程模型和交互樣式實現 ESB 模式ESB

　　標識消息並在應用程序和服務間路由這些消息

　　允許消息在服務請求者和服務提供者之間來回傳遞的過程中跨不同的傳輸協議傳遞

　　在請求者和服務之間轉換消息格式

　　識別和區分不同源之間的業務事件

　　提供可靠而安全的通信

　　創建基於可插入組件的可擴展體系結構

　　提供智能路由和獨立於位置的處理

　　通過元數據管理消息及其格式的描述和定義

　　集成所有類型的資產以滿足您企業的需求

　　很多 ESB 實現都利用了服務連接性標准如 XML 和 Web 服務此類標准封裝了行業對 ESB 定義的統一認識不過沒有必要將 ESB 限制為僅使用這些標准可以對 ESB 體系結構模式進行擴展以支持現有 IT 投資此類投資包括大型機資產打包應用程序傳感器和設備以及文件和不基於任何公用標准的自定義協議ESB 應該支持企業的所有連接性需求

　　ESB 應該支持不同類型的服務交互單向消息及請求/響應異步調用及同步調用和發布/訂閱模型以及復雜事件處理（在其中可能會觀察或使用一系列事件來產生一個事件將其作為系列事件中的關系的結果）

　　建立 ESB 是組織中建立 SOA 的過程中一項十分關鍵的基礎投資組織可通過其實現以下目標

　　簡化減少接口的數量大小和復雜度

　　減少風險和成本提高 IT 對業務需求變更的響應能力

　　促進重用提高數據和業務邏輯的可用性使應用程序更易於啟用服務

　　支持動態實時事件驅動的 SOA替代了呆板無響應能力或采用批處理方式更新的 IT 系統

用戶角色和任務

　　SOA 和任何 IT 活動一樣都依賴於技術人員和流程ESB 采用過程中的一項關鍵的成功因素是ESB 技術必須能夠在治理框架內進行管理以便為組織帶來價值

　　很多組織發現SOA 卓越中心（SOA Center of ExcellenceCOE）價值很大能促進 SOA 技術的采用COE 必須涵蓋整個組織內的團隊以分享經驗提供培訓提出流程改進建議和確保 SOA 環境的成熟度COE 需要幫助 SOA 治理委員會處理 SOA 出現的問題如版本控制服務共享和安全性等SOA COE 是整個組織范圍內的 IT 團隊負責指導 SOA 遠景和戰略所確定的戰略共享 IT 解決方案的 IT 投資涉及決策和實現COE 可幫助處理一系列問題如

　　治理

　　在組織內為 SOA 提供信息傳播機制

　　在定義 SOA 治理和管理流程方面為 SOA 治理委員會提供支持

　　實現 SOA 治理和管理流程

　　充當思想領袖並進行遠景規劃充當 SOA 治理和管理流程的思想帶頭人

　　提供專業 SOA 技能和資源

　　演示資產收集過程中的知識管理

　　進行整個 IT 團隊內及與組織的其他部門的溝通

　　下面以圖形方式說明了 COE 所充當的很多角色

　　

技術選擇標准

交互樣式

　　為了完全支持全面的 SOA 中所需的各種集成模式（如請求/響應發布/訂閱和事件等）ESB 應該最好能在一個基礎設施中支持三個主要企業集成樣式

　　SOA其中應用程序通過具有定義良好的顯式接口的可重用服務進行通信面向服務的交互將充分利用底層消息傳遞和事件通信模型

　　消息驅動的體系結構其中應用程序通過 ESB 發送消息以調用其他應用程序

　　事件驅動的體系結構其中應用程序以彼此獨立的方式生成和使用消息

　　使用者可以采用不同的方式實現服務調用從使用者的角度而言差異在於

　　同步使用者使用單線程來調用服務線程發送請求會在服務運行時阻塞等待響應

　　異步使用者使用兩個線程來調用服務一個線程發送請求然後另一個線程偵聽並接收響應

　　發布/訂閱服務將消息發布到特定的主題多個服務（訂閱者）可以訂閱此主題並接收發布的消息

　　對於單個服務ESB 可以提供這些調用模型的任意組合讓使用者選擇首選調用模型

　　交互樣式可能影響 ESB 實現IBM® WebSphere® Message Broker 特別適合基本流范式為異步或偽異步方式的體系結構

有狀態性

　　某些情況可能需要 ESB 在消息通過其中時維護狀態從最後適用的消息的上下文信息中選擇特定的服務端點就是這方面的簡單示例而在更為復雜的示例中可以通過檢測涉及上下文敏感的消息和事件組合（語義上下文時間上下文空間時間上下文）的復雜情況來擴展 ESB 范式在應用到來自多個事件源的輸入處理時此功能極為強大從不同上下文中的業務應用程序或基礎設施的角度而言均是如此例如此類場景可能涉及到服務水平協議 (Service Level Agreement) 警報和適用於安全財務銀行和保險行業的遵從性檢查

　　硬件 ESB 實現通常並不支持有狀態交互這就使得有狀態性成為了軟件 ESB 實現的一個標准WebSphere Message Broker 以獨特的方式在產品中直接實現了復雜的消息處理使其最適合需要此功能的用例

端點標准和協議

端點是通過 ESB 交互的使用者和服務

　　采用標准技術和協議（如 Web 服務）的端點在 ESB 技術選擇方面提供了最大的靈活性不過將端點限制為存在大量遺留投資的標准的做法經常不實際或不經濟高效類似地雖然可以使用專用 API 集成打包應用程序但將這個集成工作委托給中介供應商完成的做法通常很有用為了處理這些顧慮出現了能極大簡化集成的適配器

　　適配器的使用會對 ESB 產品選擇造成影響因為適配器需要軟件運行時（在硬件 ESB 實現上並不支持適配器）而且各種適配器的先決條件各不相同

基於策略的交互管理和動態服務選擇

　　在一項新興的 ESB 技術中采用了動態端點選擇其選擇以服務器使用率和運行狀況等基於代理的統計數據為基礎在某些 IBM ESB 產品通過與 IBM Tivoli Composite Application Manager 的集成提供了對此的現成支持

消息量大小和類型

　　ESB 產品具有不同的可伸縮性特征通常基於硬件的實現可以很好地擴展而且具有很好的行業標准數據格式支持不過他們並不提供軟件實現的通用性WebSphere Message Broker 性能優良提供了豐富的 ESB 功能而且可以使用自定義組件和適配器進行擴展WebSphere ESB 具有豐富的行業標准格式Java 和 Web Services 標准支持可以使用自定義組件和適配器進行擴展

可靠性可用性和可服務性（Reliability availability and serviceabilityRAS）

　　ESB 產品具有不同的操作特征它們通過不同的機制和體系結構規模（例如應用服務區集群和操作系統級別的集群）來實現可伸縮性和高可用性必須對此加以考慮而且所得到的解決方案體系結構必須在 RAS 考慮事項和現有預算組織內的技能以及操作復雜性方面求得平衡

　　所需的中介

　　ESB 產品在不采用自定義編程的情況下處理中介的能力方面存在差異最值得注意的是WebSphere Message Broker 提供了對各種標准數據格式（如 ACORDSWIFT 和 COBOL Copybook）的廣泛支持如果數據格式是 XML 和 Web Services則最適合使用 Websphere DataPower® SOA Appliances此產品可提供非常高的性能

　　IBM ESB 產品

　　很多產品都可以用於創建企業服務總線（Enterprise Service BusESB）IBM 提供了創建 ESB 的多個選項這就允許客戶根據其具體的需求選擇 ESB 技術在很多大型組織中由於地理位置技術或其他原因可能會使用多項 ESB 技術來創建混合 ESB當兩個大型部門各自以獨立的方式開始 SOA 然後又發現需要彼此進行互操作時可能采用混合 ESB

　　IBM 的三個主要 ESB 產品是 WebSphere Message BrokerWebSphere ESB 和 WebSphere DataPower SOA Appliances

WebSphere Message Broker

　　WebSphere Message Broker 提供了很多客戶用於創建其 ESB（或混合解決方案中的中央 ESB）的功能WebSphere Message Broker 源自 WebSphere MQ 消息傳遞領域特別適合 MQ 消息傳遞的環境該產品提供 WSDL 和其他消息格式的接口定義通過消息流提供中介功能並支持各種通信格式包括 WMQ 和 HTTPWebSphere Message Broker 還基於發布/訂閱交互和托管主題空間提供內容

　　WebSphere Message Broker 支持各種服務交互端點的中介模式實現它支持各種行業標准消息集（當然只有其中一部分使用 XML 編碼）支持添加對其他用戶定義的消息格式的支持以下典型客戶需求非常適合使用 WebSphere Message Broker 解決方案加以處理

　　事務

　　發布/訂閱

　　ACORDSWIFT 或 COBOL Copybook 標准格式

　　采用 XML 格式的數據

　　符合 WS* 標准

　　WebSphere MQ 消息傳遞

　　復雜轉換

　　復雜事件處理

　　WebSphere Message Broker 提供了多個 ESB 連接選項和任意格式間的數據轉換通過這樣遺留應用程序和不符合標准的應用程序就可以連接到 ESB

WebSphere ESB

　　WebSphere ESB 是 ESB 的 JEE 實例化成果WebSphere ESB 在 IBM WebSphere Application Server 內的 JEE 容器中運行該產品非常適合基於 JEE 和 WS* 標准的應用程序特別是只需要與其他應用服務器通信的應用程序另外該產品可作為進入 SOA 世界的敲門磚允許將基本 Web 服務作為進入更為可靠的 SOA 環境的墊腳石加以利用

　　WebSphere ESB 提供基於標准的 Web Services 連接性JMS 消息傳遞和面向服務的集成用於端到端和發布/訂閱消息傳遞的 JMS 應用程序和面向 JAXRPC 服務的應用程序可以直接連接到 WebSphere ESB或者可以通過各種傳輸協議（包括 WMQSOAP/HTTP 和 SOAP/JMS）將消息交付到 WebSphere ESBWebSphere ESB 實現了 Web 服務網關此網關可以在基於 SOAP/HTTP 和 SOAP/JMS 的應用程序之間進行中介最後它還提供了統一描述發現和集成（Universal Description Discovery and IntegrationUDDI）的實現以下典型客戶需求非常適合使用 WebSphere ESB 解決方案加以處理

　　JEE 實現

　　Web Services 接口

　　SOAP/HTTP

WebSphere DataPower SOA Appliance

　　WebSphere DataPower SOA Appliance 是同時包含硬件和軟件的產品提供了大量的重要功能XML 加速安全措施執行和 ESB 功能DataPower 具有多個重要特征

　　經過優化的硬件固件和嵌入式操作系統

　　確保配置鎖定的高級保證措施

　　減少安全漏洞

　　加密密鑰的硬件存儲和鎖定的審核日志

　　沒有硬盤CD ROM 或 USB 端口

　　篡改防護機箱在機箱打開的情況下機器將變為不可用狀態

　　降低操作復雜性真正的 SOA 設備通過 DataPower能以最快的速度實現 SOA 入門而且同時還能提供增強的安全環境

　　以下典型客戶需求非常適合使用 DataPower 解決方案加以處理

　　安全網關

　　XML 防火牆解析和驗證

　　基本路由

　　基於內容的路由

　　協議橋接（HTTPWebSphere MQ 客戶機FTPODBC 等）

　　輔助技術

　　除了上面討論的 ESB 技術外以下補充產品還可以進一步加快或擴展 ESB 實現

　　WebSphere MQ 為多種不同平台提供可靠消息很多公司都使用 WebSphere MQ 作為消息傳遞中樞

　　WebSphere Service Registry and Repository 提供了集成的服務元數據存儲庫來治理服務和管理服務生命周期它可促進服務可見性一致性還將減少 SOA 中的服務冗余

　　WebSphere Transformation Extender 提供了通用轉換功能非常適合滿足極為復雜的需求或快速變化的需求如 EDI 等

　　WebSphere Adapters 是外接程序可幫助為打包應用程序或其他遺留資產啟用服務以便參與到 SOA 中來其中提供的適配器允許將各種遺留信息系統和技術包含到 ESB 中來

　　WebSphere Process Server 提供流程工作流功能並包括 WebSphere ESB有些情況需要對來自很多個系統的服務調用和響應進行協調而此解決方案提供了在此情況下編排復雜 ESB 交互的功能

　　IBM Tivoli Composite Application Management for SOA 是專門針對 SOA 環境的 Tivoli 監視產品通過 IBM Tivoli Composite Application Manager for SOA可充分利用現有系統管理工具提供了 SOA 環境的全面操作視圖

　　WebSphere Business Services Fabric 是用於進行組合業務服務的建模組裝部署管理和治理的端到端 SOA 平台WebSphere Business Services Fabric 可幫助創建業務級別的服務以供組裝為擴展的跨企業業務流程和解決方案而且可以基於服務請求的業務上下文對這些流程和解決方案進行動態個性化和交付

WebSphere Service Registry and Repository

　　WebSphere Service Registry and Repository 提供了基本 UDDI 服務目錄所不提供的很多功能事實上很多組織發現由於 UDDI 規范尚不完全明確不同提供商實現該規范的方式也不一樣WebSphere Service Registry and Repository 不僅提供了關於存在哪些服務的注冊中心而且還提供了工具來向 ESB 提供這些服務和允許開發人員搜索現有服務供使用WebSphere Service Registry and Repository 包括

　　包含關於服務的信息（如服務接口其操作及參數）的服務注冊中心

　　具有可靠框架和適合各種服務使用方法特征的可擴展性的元數據存儲庫

　　WebSphere Service Registry and Repository 幾乎可以和 SOA 生命周期的所有部分進行交互

　　通過標准資產管理解決方案與服務開發生命周期交互

　　在進行服務的變更和發布管理流程的過程中跟蹤服務生命周期階段

　　提供對運行時工具的優化訪問

　　通過操作系統管理實用工具共享關於服務和服務元數據的信息

　　WebSphere Service Registry and Repository 提供關於何時何人對哪個服務進行了何種操作的信息此功能將在下面的案例研究中進行討論

基本 ESB 模式

　　下面部分將介紹核心 ESB 中介功能的通用語言這些模式可以非常方便地幫助在上下文中說明 ESB可以用於表述與最佳實踐和所得到的經驗教訓相符的可重復中介模式ESB 用例可以表示為這些核心模式的組裝

　　

　　協議切換

支持服務請求者使用各種交互協議或 API（如 SOAP/HTTPJMS 和 MQ Integrator (MQI)）來發送其消息
將請求轉換為目標服務提供者的格式
可以在交互的請求者和/或提供者端或兩者間的任何位置應用
此模式的中介通常在格式和彼此關系有明確定義的情況下自動創建

　　修飾符

在不更改上下文信息的情況下更新消息的有效負載 轉換子模式
消息有效負載從一個格式（模式）轉換為另一個格式從而將請求者的消息定義與提供者的消息定義匹配
包括封裝和取消封裝即將采用一個網絡格式的消息放入另一個網絡傳輸所需的格式信封或對應的刪除信封的過程
包括加密

　　
 

充實子模式
通過添加來自外部數據源的信息（如中介的自定義參數或數據庫查詢）來更新消息有效負載

　　
 

　　路由器 (Router)

更改消息的既定路由在與中介關聯的服務提供者之間進行選擇
示例從金牌客戶到備用的高級 SLA 提供者間

　　
 

　　發現

查詢 ESB 注冊中心以發現匹配請求者需求的一組服務提供者選擇其中一個然後將消息路由到該提供者
路由模式的增強
可能的服務提供者集不是在中介預先配置的
提供者匹配請求者的消息格式所需的 QOS 或從中介到可能的提供者所支持的協議
示例數據中心故障轉移場景在不更新每個中介的配置的情況下將數據中心上線注冊服務將通信流量路由到對應服務

　　
 

　　分發

將消息分發到一組相關方通常由訂閱者的興趣概要驅動

　　
 

　　監視

用於在消息通過 ESB 的規程中觀察消息不過不會以任何方式更改這些消息示例
監視服務級別
提供用於進行問題確定的數據
退款測定
記錄業務級別事件（超過特定收益值的交易）
記錄消息供審核

　　
 

　　相關（復雜事件處理）

從消息或事件流派生復雜事件包含模式標識規則和響應模式發現規則例如通過生成從觸發事件流的內容派生的復雜事件

　　
 

　　可以對這些基本模式進行聚合以得到更為復雜的模式

　　

　　規范適配器

所有各方使用的消息和業務對象集規范化為規范格式規范適配器模式可以將端點的本機總線附加協議轉換為標准協議對有效負載進行規范化並在交付時進行反向轉換此模式是協議切換和轉換模式聚合後得到的

　　
 

　　轉換記錄路由

這是一個常見的 ESB 聚合模式轉換傳入消息（轉換）對其進行記錄（監視）並路由到相應的端點

　　
 

　　代理或網關模式

路由或協議切換模式的變體其中將對服務端點進行映射並可能提供安全功能（授權和訪問控制）和日志記錄或審核功能
可能包含轉換和監視中介以提供加密和日志記錄或審核還可能會采用一對多關系對消息進行聚合和取消聚合

　　示例充當多個服務的單個接觸點並隱藏內部服務的服務門戶

　　
 

復雜 ESB 模式

　　這些模式從更為現實的角度說明了如何使用 ESB 來實現所需的豐富服務虛擬化在很多大型組織或沒有 SOA 合作伙伴的組織中經常會需要多個 ESB很多原因都會導致此需求的出現包括

　　安全性

　　性能

　　可說明性/可審核性

　　資源控制

　　以下模式供演示之用絕不能視為全面的敘述其中很多模式都可以彼此進行結合具體取決於特定項目的需求

全局 ESB

　　全局 ESB 為所有服務請求者提供對一個注冊中心的訪問每個服務對每個服務請求者都可見此模式雖然可能適合小型系統測試環境但可能不適合在生產環境中使用這個適用性討論所指的是沒有其他 ESB 的全局 ESB也就是說采用的是非混合方法混合方法將在此部分稍後進行討論

　　在集中管理但地理位置分散的整個異類環境中所有服務共享一個命名空間而且每個服務提供者對每個服務請求者都可見

　　供所有服務可能適用於整個組織的部門或小型企業使用

　　

　　對於全局 ESB 的情況有兩個主要 ESB 技術選項WebSphere Message Broker 和 WebSphere ESBWebSphere ESB 是首選技術其整個環境都基於 JEE 和相關標准存在與非 JEE 系統的復雜轉換和交互時WebSphere Message Broker 可能更為適用大型組織可能會發現同時運行這兩個產品的做法更為合適在此方法中按照下一個示例聯合 ESB 中所討論的方式根據消息類型和目的地對消息進行路由

ESB 網關

　　ESB 網關模式提供內部和外部域邊界間的受控制的安全服務交互

　　

　　ESB 網關模式經常使用 DataPower 設備進行實例化因為這樣可以在提

　　供所需的網關功能之外提供 XML 防火牆DataPower 非常適合用於網絡邊界因為它使用的是嵌入式操作系統和軟件實現因此能減少設置操作系統環境所固有的風險

聯合 ESB

　　聯合 ESB 提供了使用多個服務注冊中心和管理域的功能並同時將異類注冊中心映射為服務聯合集聯合 ESB 可促進采用多個 ESB 實現時的服務交互聯合 ESB 經常用於提供適用於整個企業的服務子集

　　多個從 ESB 聯合到一個主 ESB 中

　　服務使用者和提供者連接到主 ESB 或從 ESB以訪問整個網絡中的服務

　　供希望將一系列具有適度自主控制的部門聯合到一個監管部門之下的組織使用

　　

　　對於聯合 ESB核心ESB 可能為 WebSphere Message Broker而非核心 ESB 可以為 WebSphere ESB或者對於小型遠程辦公室的情況可以使用 DataPower 設備在此模式中每個站點都有自己的服務注冊中心在聯合 ESB 模式中最佳實踐是在網絡邊界使用 DataPower 設備以執行授權和身份驗證以及在提交給內部系統前解析和驗證 XML通過這樣DataPower 設備可以加快事務處理速度和降低 ESB 服務器的 CPU 使用率

代理 ESB

　　代理 ESB 用於在以下情況下支持多個注冊中心即服務子集適用於整個組織但其中不存在單個服務的多個實現

　　對選擇性地將請求者或提供者向其他 ESB 域中的合作伙伴公開的服務進行橋接

　　每個 ESB 管理自己的命名空間

　　ESB 間的服務交互通過實現橋接服務的公用代理來加以促進

　　如果各個部門開發和管理自己的服務但共享其中的部分服務或選擇性地訪問整個企業中提供的服務則可使用此模式

　　

　　代理 ESB 模式與聯合 ESB 模式非常相似不過代理 ESB 充當執行點和服務路由器

　　JBI 標准 (JSR ) 的討論中經常提到聯合 ESB到目前為止IBM 已經放棄了 JBI 規范因為此規范並沒有在客戶已經能實現的工作之上有足夠的發展很多技術和開放規范都提供了更為有競爭力的互操作性和更好的組件組合機制IBM 首先關注的是支持最廣泛的產品應用程序和現有業務資產集成

ESB 場景 ABC Hotel

　　ABC Hotel 是一家全球性的酒店與休閒企業該公司擁有多個品牌提供豪華與高檔全面服務的酒店這包括超過 家全資托管或特許經營酒店房間總數超過 間

　　ABC 開始了一個持續多年的大型 IT 項目將其基於大型機的大型獨立中央預訂系統（Central Reservations SystemCRS）替換為作為分布式 JEE 服務實現的系統進行此項目的推動因素是要減少成本（替換大型機）和提高業務靈活性該項目被普遍認為是將采用 SOA 的概念和理論的項目服務要部署在兩個分布在不同地方的數據中心中將為各個服務部署多個實例以促進系統吞吐能力和可用性

　　值得注意的是CRS 項目最初並沒有考慮通用 ESB 框架隨著項目的逐漸成熟服務集成的復雜性達到了不可接受的程度這給架構師開發人員和操作帶來了極大的負擔成為了成功完成 CRS 項目的阻礙因素因此作出了進行重構來包含 ESB 的決策ABC 進行了相關評估以選擇合適的行動方案

　　向 IBM 提出的 ESB 需求的摘要

　　請求路由和工作負載管理在基礎設施內為各個服務部署多個副本以提高可靠性可服務性和可用性ESB 應該將客戶機請求路由到所請求服務相應的版本和實例ESB 還應該進行一些工作負載管理的部署將請求分發到相同的服務實例這可以為簡單的負載分布算法但該公司對更為主動性的端點驅動的負載工作負載管理有著很強烈的興趣

　　注冊中心集成ABC 采用了基於 UDDI 的服務注冊中心處理構建時服務目錄沒有部署更為主動的運行時服務注冊中心但支持此類注冊中心的需求得到了公司的認可

　　中介ABC 希望使用 ESB 來在客戶機和服務之間進行中介服務數據以 WSDL / XML 格式表示因此不需要處理更為深奧的數據格式消息驗證（WSI 和 XSD）以及對性能/轉換加速的支持是主要的推動因素

　　事務管理ABC 具有某些特殊的用例此類用戶將需要對提交的服務請求進行補償和回滾（組合服務中的分布式事務支持）他們需要支持基於規則流程驅動的原子事務

　　服務編排和工作流復雜工作流支持是服務交互的小子集的一項需求最好在這些情況下有 BPEL 支持最好還支持業務狀態機交互的計劃和安排事件相關和涉及人工交互的工作流

　　能夠促進與後端系統的集成希望有直接與 Siebel 及其他後端系統集成的能力

　　高性能/低延遲ESB 應該對總體性能和延遲的負面影響最小

　　監視管理維護總的說來在服務級別監視收集標准和自定義標准錯誤檢查根源分享報告和歷史分析方面存在各種廣泛的需求自動操作員警告和通知工具非常關鍵

　　安全性需要與 Tivoli Access ManagerLDAP 和其他第三方安全產品實現集成憑據和密鑰管理功能基於標准的身份驗證訪問控制加密/解密SSL 加速SarbanesOxley (SOX) 控制和 DMZ 部署的適合性都需要考慮

　　SDLCABC 使用基於 Eclipse 的 Rational Application Developer 和 Rational Software Architect最好能使用適合其現有環境的 ESB 開發工具

　　快速部署ABC 在選擇重構來包含 ESB 之前已經進行了大量的投資部署的成本和速度是非常關鍵的考慮事項

　　減少操作復雜性減少風險和復雜性是推動 ABC 進行重構以獲得基於 ESB 的體系結構的重要因素ABC 非常希望得到了高效且復雜度低的解決方案

示例用例

調用後端服務的業務合作伙伴

　　ABC 定期與業務合作伙伴通信以獲得房間可用性和預訂請求需要使用 DMZ 部署模式實現後端服務調用的虛擬化必須對客戶進行身份驗證和授權另外必須監視和記錄所有活動

　　

　　將來可能會需要按客戶機請求類型或其他信息對通信流量進行劃分

　　

調用後端服務的酒店屬性

　　各個屬性都具有本地屬性管理系統（Property Management SystemPMS）

　　而這些系統必須通過接口與 CRS 連接一個場景是更新房間和清算可租房間總量的屬性CRS 必須注意可租房間總量的變化屬性使用 XML over MQ 通過接口與 CRS 連接而 CRS 服務可能使用其他連接協議（如 SOAP/HTTP）部署

　　

　　類似地可以對此模式進行擴展添加按端點使用率統計數據進行路由的能力

　　

　　上面兩個用例一起處理了所有 ESB 通信流量中的大部分流量

　　復雜恢復錯誤場景

　　在此場景中假定在從屬性滿足客戶機請求時在組合服務交互中出現錯誤從錯誤恢復非常重要需要可能包括人工任務的工作流核心 ESB 模式並不會更改不過執行體系結構將包括額外的組件以支持這個功能

　　包含後端集成的復雜工作流

　　在此場景中一個創建客戶的請求進入了首選客戶跟蹤系統業務用戶希望將此信息中的各個部分輸入到作為中介的一部分 Siebel 中 ESB 充當現有服務的標准中介而同時還包括對 ISV 後端系統的更新這裡適用傳輸監視路由 ESB 聚合模式但執行體系結構將利用多個 IT 組件來處理服務請求

解決方案體系結構概述

　　IBM 建議采用混合 ESB 體系結構其中既包括硬件 ESB 實現也包括軟件 ESB 實現每個實現的 ESB 功能方面存在不同的優缺點

　　設備

　　經過優化可提供很高的性能而且處理延遲非常小

　　配置部署和操作最簡單

　　安全篡改防護

　　從通用平台分流開銷大的處理負載

　　軟件

　　應用程序承載支持工作流支持和復雜中介

　　通過適配器進行應用程序集成

　　支持業務活動監視

　　IBM 希望廣大客戶都部署可充分利用這兩個方法的優勢的混合體系結構在混合體系結構中增加了 SOA 服務注冊中心和管理功能

　　解決方案組件

DataPower XI（硬件 ESB）
WebSphere Process Server（包括 WebSphere ESB）
WebSphere Business Integration Adapter（與後端系統集成）
IBM Tivoli Composite Application Management for SOA（服務監視和管理）
WebSphere Service Registry and Repository（服務注冊中心）

　　以下系統上下文關系圖說明了這些組件的交互

　　

　　DataPower XI 在此體系結構中充當兩個角色服務網關（在 DMZ 中）和通用硬件 ESB（在受信任區域中）需要軟件 ESB 實現的任務（如使用 Siebel Adapter 或涉及人工交互的復雜錯誤恢復）分流到 WebSphere Process Server（其中包括核心組件 WebSphere ESB）

　　DataPower 處理 ABC 的大部分 ESB 通信請求可保證非常高的性能WebSphere Process Server 和 WebSphere ESB 對 DataPower 的功能進行補充以支持在體系結構中實現最大的靈活性

　　IBM Tivoli Composite Application Management 產品支持對 ESB 及與其交互的組件進行監視和管理監視代理收集的信息可以支持復雜的 ESB 充實和路由模式如動態服務選擇（根據監視代理收集的承載服務器負載之類的信息選擇目標服務）

　　WebSphere Service Registry and Repository 支持服務的完整生命周期管理在支持 ESB 中的動態服務選擇方面扮演著重要的角色正如上面所述僅僅 UDDI 並不足以處理這些任務

　　此體系結構旨在在性能和靈活性方面取得較好的平衡

ESB 場景 XYZ Insurance

　　XYZ Insurance 是一家醫療保險提供商該公司為數百萬客戶提供保險服務必須與客戶提供商第三方代理和其他實體進行交互此示例是多個實際保險項目的組合

　　XYZ 決定開始 SOA 項目以實現其信息技術的現代化並充分利用在使用 COBOLAssembler 和 PL/I 編寫的大型機 (z/OS) 應用程序方面的大量投資這些系統適用 DB 和 IMS 數據庫與最終用戶的大量通信都是通過客戶信息控制系統（Customer Information Control SystemCICS）進行的IBM 的 WebSphere MQ 提供了應用程序內和應用程序間的消息傳遞中樞的大部分功能其中有一個主數據中心該數據中心連接到多個外圍數據中心和第三方系統

　　XYZ 決定使用面向服務的體系結構 (SOA) 來構建新呼叫中心環境（Call Center EnvironmentCCE）和構建新的索賠處理應用程序（Claims Processing ApplicationCPA）還有很多其他應用程序和更改但我們將重點關注這兩個主要系統

　　IBM 和 XYZ 用於定義體系結構的總體項目需求包括

　　在無需重新編寫代碼的情況下利用遺留應用程序

　　利用大型機系統並同時在為該應用程序所選的平台上創建新服務

　　支持多通信協議（SOAP/HTTMWebSphere MQ 等）

　　安全地支持與外部組織的 SOA 交互

　　在包含分散在不同位置的多個數據中心的環境中操作

　　提供實時監視和根據所需的服務級別路由事務的能力

　　其 ESB 需求與 ABC 案例研究類似不過需要更為復雜的中介另外

　　由於很多法律法規的要求其安全性和可審核性必須比 ABC 案例研究中更為可靠

　　示例用例

調用主數據中心服務的遠程數據中心

　　遠程數據中心之一頻繁調用主數據中心以支持呼叫中心環境 (CCE)雖然這是在組織內進行但這種情況下仍然使用了網關來確保滿足應用程序安全性和審核要求

　　在本例中對主數據中心的單個服務調用可能會導致遺留應用程序內出現多次服務調用從而需要服務編排和工作流組件將所得到的信息組裝為單個服務響應

　　服務交互的遠程數據中心端如下所示

　　

　　服務交互的主數據中心端如下所示請注意為了清楚起見並沒有在關系圖中給出網關和監視組件不過它們當然是解決方案中至關重要的組件

　　

主數據中心調用遠程數據中心服務

　　主數據中心將頻繁調用遠程數據中心之一以確認最新的呼叫中心環境 (CCE) 活動這就要求遠程數據中心具有完整的 SOA 環境並具有與主數據中心完全相同的安全性和審核功能

　　服務交互的主數據中心端如下所示

　　

主數據中心調用第三方服務進行地址驗證

　　在接受地址並將其存儲在 XYZ 的數據中之前主數據中心將調用第三方服務來驗證地址是否有效

　　

外部代理對遺留應用程序服務進行服務調用

　　雖然外部第三方應用程序將沒有必要知道所調用的服務是遺留應用程序但此用例在體系結構的角度非常有意義

　　服務交互的遠程數據中心端如下所示

　　

　　服務交互的主數據中心端如下所示請注意為了清楚起見並沒有在關系圖中給出網關和監視組件不過它們當然是解決方案中至關重要的組件

　　

基於服務調用模式的欺詐檢測

　　基於服務調用模式的欺詐檢測是較為復雜的情況不僅需要監視調用的數量還要監視進行調用的實體以及調用的時間在本例中如果獲知某個特定用戶涉嫌對一個使用者或提供者進行異常的大量調用將臨時禁止用戶的訪問權限並通知 XYZ 調查此異常行為這個監視記錄相關和安全系統集成存在著極大的挑戰不過可以使用現有 ESB 技術並結合其他 SOA 技術來加以處理

解決方案體系結構概述

　　IBM 和 XYZ 合作創建了包含硬件和軟件 ESB 組件的混合 ESB 體系結構在本例中應用了所有三項 IBM 的 ESB 技術來提供所需的功能對遺留集成服務編排和基本工作流的需求推動了關於使用這組技術的體系結構決策

　　以下系統上下文關系圖說明了這些組件的交互

　　

　　和 ABC 示例中的情況一樣DataPower XI 扮演著兩個角色DMZ 中的安全防火牆和受信任區域中的 ESBWebSphere Process Server/ESB 用於對復雜服務交互進行編排負責從數據結構獲取數據並將其組合為更為復雜的業務服務響應WebSphere Message Broker 用於處理與遺留系統交互所需的復雜消息轉換此示例說明了在一個設計中使用所有三個 IBM ESB 解決方案的價值其中的每個解決方案都得到了充分的利用體現了各自最重要的功能

　　IBM 認識到很多組織將具有與 XYZ 類似的復雜需求這些需求將對多項技術的使用起到促進作用從而提供最為恰當的功能滿足可用性性能和安全性需求

解決方案組件

　　XYZ 使用的解決方案包括

　　DataPower XI（硬件 ESBXML 安全網關）

　　WebSphere Process Server（包括 WebSphere ESB 和復雜服務交互的流程編排）

　　WebSphere Message Broker（支持復雜消息轉換和非標准消息傳遞的軟件 ESB）

結束語

　　本文提供了 ESB 使用的概念和實際示例文中討論了創建 ESB 的技術選項以及哪些產品最適合各個特定情況和任何技術主題一樣使用本指南時應該結合有經驗的專業人員的經驗來設計最適合特定情況的解決方案

致謝

　　作者要感謝 MarcThomas SchmidtKyle Brown 和 Rachel Reinitz 所做的工作他們的工作為大部分 IBM SOA 活動提供了基礎尤其在 ESB 領域特別重要

 關於作者

　　Victor Grund 是 IBM 的一位 WebSphere 技術銷售經理負責 WebSphere 產品在 New England 及北部 New York 地區的銷售他擁有 年的 IT 專業從業背景其中至少有 年在 IBM 工作他曾擔任過經理軟件架構師首席 SOA 架構師IT 專家和顧問等眾多職務他在設計和實現企業應用程序和集成解決方案方面有豐富的經驗您可以通過 與 Victor 聯系

　　Chuck Rexroad 是 IBM 在 New England 及北部 New York 地區的首席軟件 IT 架構師他於 年加入 IBM擔任 Tivoli 品牌的技術專家在系統管理的所有方面都有著豐富的經驗多年來他一直在從事 SOA 項目和技術相關的工作幫助大中型組織客戶實現其 SOA 環境您可以通過 與 Chuck 聯系

From:http://tw.wingwit.com/Article/program/net/201311/11432.html