本文首先介紹了企業級應用程序的發展以及 ESB 的定義；隨后，分析了 ESB 在 SOA 解決方案中所起的作用，并比較介紹了三款 ESB 產品在支持實現一個 ESB 解決方案中所起的作用。
企業應用的發展概述
在介紹企業服務總線之前，有必要花一些筆墨來介紹企業應用架構的發展和變遷。企業級應用架構的發展經歷了以下幾個階段：
- 獨立應用系統
- EAI 階段
- SOA 階段
獨立應用階段
20 世紀 60 到 70 年代，企業應用處于獨立應用系統階段，當時的企業應用是一種用來替代重復性勞動的簡單設計，其目的是用計算機代替孤立的，體力性質的工作環節，將相關聯的企業信息或數據管理起來。這些系統大部分是獨立的系統——有獨立的數據庫、應用服務器、用戶界面。因此有時候這類應用也叫“豎井型”的應用。
但是，隨著業務和信息的不斷擴展，獨立應用系統漸漸不能滿足企業對 IT 的需求，表現在大量的信息冗余，因為在建立一個新的應用的時候需要重新建立一套數據庫；功能的重新設計，相似的功能存在于多個系統中；例如，客戶信息在一個公司中可能有多個拷貝分別存在于多個數據庫中，不同時期建立的應用系統所使用的技術也會不同。對于獲取客戶資料這樣的功能，必然存在于多個系統中，而且在不同的系統中其實現方式可能是 Java/J2EE、Delphi、C/C++。
EAI 階段
20 世紀 80 到 90 年代，一些公司或集成商意識到應用集成的價值和必要性。EAI 是一種將多個不同平臺、用不同方案建立的異構的應用集成的一種技術和方法。它的目標包括以下幾個方面：各個分離的系統間的相互通訊，消除信息孤島，實現信息的共享。從功能的角度來看，EAI 包括信息接收、轉換、翻譯、路由、傳播和業務流程管理。從架構上看有兩種方式：Hub/Spoke 方式和 Bus 方式。
圖 1 所示的 Hub/Spoke 結構使用一個中心代理（Hub）和多個適配器（Spoke）將 Hub 和應用連接起來。適配器負責將應用的數據格式轉換成 Hub 可以理解的格式，Hub 將數據再轉換成目標系統可以理解的格式，并執行消息的路由。Hub/Spoke 方式的弊端在于只有一個代理中心，當連接的應用種類增加或者消息量增大時，代理中心的性能將成為整個系統的瓶頸，在可擴展性方面也存在著一定的問題。
圖 1 . Hub/Spoke 結構的 EAI 集成 
圖 2 所示的 Bus 結構使用一個中心總線，應用程序通過 Adapter 將消息發送給總線，總線負責消息的路由，接受方的應用程序也有自己的 Adapter 來轉換接受到的消息。Bus 結構和 Hub/Spoke 結構的最大區別在于在 Bus 結構中，Adapter 位于應用程序中，而 Hub/Spoke 結構中，Adapter 由 Hub 來統一管理。這樣在 Bus 結構中，加入一個新的應用變得很簡單，可擴展性得到了很大的提高，但是應用程序方的負擔加重了。
圖 2. Bus 結構的 EAI 集成 
SOA 階段
SOA 將應用資源看成一個個獨立的，自包含并良好定義的服務，通過這些服務的組裝，編排可以產生新的應用。每一個服務可以完成一個獨立業務功能，并且不依賴于業務上下文或者其他服務的狀態。服務的定義是標準的且被廣泛支持的，比如 Web Service。在 SOA 的架構中，人們都用標準的方式來封裝自己的服務，使得任何一個客戶端程序都可以容易的和后臺系統實施連接。而 ESB 是 SOA 架構中的一個核心基石，在幾乎所有的 SOA 架構中，都將 ESB 放在核心的位置。圖 3 是 IBM SOA Reference architecture，從中我們可以看出 ESB 在一個 SOA 架構中的地位，對該圖的詳細解釋不在本文介紹范圍之內，有興趣的讀者可以參考一下 IBM SOA 專區的相關文章。
圖 3. IBM 的 SOA 參考架構 
下面我們來介紹一下 ESB。
什么是 ESB?
什么是 ESB？ESB 嚴格來說不是某一個產品，而是一種框架，設計模式。不同的提供商對 ESB 的理解也各有不同。
“ESBs are essentially integration systems, not SOA systems. SOA is about tearing down application silos, but integration systems reinforce those silos. [...] an ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure”
----Anne Thomas Manes, Research Director with Burton Group
“An Enterprise Service Bus (ESB) is a distributed middleware system for integrating enterprise IT assets using a service-oriented approach.”
----Ron Ten-Hove , Sun Microsystems and JBI Spec Lead
“A Web-services-capable infrastructure that supports intelligently directed communication and mediated relationships among loosely coupled and decoupled business components.”
--Gartner
IBM 對 ESB 是這樣描述的：
“An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond. The ESB is not a new software product — it's a new way of looking at how to integrate applications, coordinate resources and manipulate information ”
從 IBM 的立場來說，ESB 不僅僅是一個概念，而是一種中間件模式；它不是某個產品，而是一種全新的集成應用，協調資源和操縱信息的框架。
下面來介紹 ESB 或可以稱為 ESB 的中間件產品保護一些特征，有些是必須的，有些是可選的：
- 連接性
ESB 必須提供一種支持服務交互的橋梁，它必須支持多協議 (protocol) 之間的連接。不僅要提供對消息和面向事件的中間件的支持，還要提供和現有 EAI 技術的連接。連接性是 ESB 不可缺少的特征之一。
- 服務交互
服務交互可以理解為 ESB 的一個目的之一，ESB 作為 SOA 架構的核心，必然要支持服務的交互，要在服務的請求者和提供者架起一個堅實的橋梁，讓服務的請求者和提供者只需要關心各自的業務邏輯，而不需要在發布和消費服務的環節花很大力氣。服務交互也是 ESB 的必備特征。
- 集成
集成的概念是對于系統而言的，ESB 不僅要能集成那些很容易封裝服務的系統，也要集成不能方便地封裝服務的系統，例如 SAP, ERP, CRM, Siebel 等 EAI 系統、遺留系統。集成也是 ESB 的核心特征之一。
- 消息處理
在集成的過程中，必須要面對的是消息處理，在不同的應用系統中，消息的描述格式是不一樣的。在集成環境中，必須要提供一種統一的格式來處理系統間的交互，從 ASBO(Application Specific Business Object ) 到 GBO(Generic Business Object) 之間的互轉是 ESB 的核心特征之一。
- 管理
對于一個具有 ESB 特征的產品，管理也是一個重要的方面。例如，當一個服務從一個地址切換到另一個地址，在結構等不發生任何改變的時候，ESB 產品應該提供一個方便的途徑適應這種改變。
- QoS
對于服務交互來說，QoS 也是一個重要的特征，比如針對不同的服務請求者提供不同質量的服務響應。有些服務的請求需要在事務中完成，有些服務的交互需要保證其可靠性。一個 ESB 產品應該提供給開發者定義 QoS 的接口。
- 安全
安全的必要性不言而喻，系統和系統之間的交互必然需要認證，授權，加密，簽名等安全性。一個優秀的 ESB 產品應該提供可靠的，可靈活配置的安全支持。
IBM 有三款 ESB 產品：WebSphere ESB (WESB)，WebSphere Message Broker(WMB)，DataPower。這三款 ESB 產品都提供了 ESB 所必備的特征，但是它們各有側重，WESB 主要構建與 WebSphere Application Server 之上，側重于對標準協議和消息的支持，更適合于 J2EE，Web-Service 為主要特征的集成環境；WMB 提供了一個高級的 ESB，它構建于 WebSphere Message Queue 之上，提供了百種以上協議的連接和數據格式的轉換機制。Datapower 是一款比較新的 ESB 產品，除了提供必備的 ESB 的特性之外，Datapower 更側重于安全。眾所周知，在 XML 的環境中，安全對于性能的影響是巨大的，Datapower 給企業 ESB 提供了強大的安全保障。下面分別介紹這三款 ESB 產品。
WebSphere ESB
從圖 4 中可以看出 ESB 構建與 WAS ND 之上，它使用了 WAS ND 及 WAS 對于安全，用戶注冊表，事務，消息引擎的支持，在其之上增加了對服務集成、消息流處理、建模以及 ESB 編程模型的支持等等。從圖中還可以看出 WebSphere Process Server 是構建與 WESB 之上，并擴展了服務編排和流程管理方面的支持。
圖 4. WESB 在 WAS 產品線的位置 
下面介紹在 WESB 上實現一個 SOA ESB 解決方案上的以下九個方面的特點，這九個方面的特點來源于上文中介紹的 ESB 的特性，或者特性的細化：
- 消息轉換
WESB 所處理的消息為 XML 格式的數據，對于非 XML 結構的數據 WESB 不能處理。對于 XML 結構的數據，在 WESB 的消息流中數據以 SMO(IBM 對 SDO 的擴展，參見參考資料部分了解 SDO 的規范 ) 形式存在，WESB 可以對 XML 消息樹的內容進行修改，包括改變某個節點的內容，增加新的節點以及刪除某個節點等等。
- 支持的協議
WESB 支持符合 SOA 標準的協議，比如 SOAP/HTTP、SOAP/JMS、WSDL V1.1、UDDI V3.0，WebSphere MQ 等。也就是說 WESB 目前只支持 SOAP 方式來描述服務，傳輸協議可以是 HTTP、JMS 記憶原生的 WebSphere MQ 的連接。對于多傳輸協議的基礎，建議使用 MB 來做 ESB 的解決方案，參考 MB 的介紹部分。
- 消息路由
消息的路由在 WESB 中有良好的支持，開發環境 WID 中提供了一個節點專門來負責消息路由，WID 也提供了良好的對路由規則定義的開發支持，開發人員可以很容易的定制負責的路由規則。若要實現動態路由的功能，則需要和一個服務的存儲單元中來動態的查找服務，目前 WSRR 是一款優秀的提供該功能的工具（參見參考資料部分了解 WSRR）。WESB 從 V6.1 開始提供了 Endpoint lookup 節點來支持 WSRR 的集成，簡化了開發過程。如果要實現簡單的動態服務路由的功能，則可把服務的定義存放在數據庫中，在 WESB 中通過 DB lookup 來查找服務的 Endpoint, 然后注入到消息流中，WESB V6.1 之前的版本就已經支持與數據庫的集成。
- 對 Web Service 的支持
WESB 天生運行在 J2EE 的環境里面，對 Web Service 有著天然的支持。
- 事件處理
在消息流中，我們需要跟蹤消息各節點的狀態，以滿足統計和出錯處理的要求，在 WESB 中，通過 CEI 機制來處理消息。（CEI 的介紹請參見參考資料部分）
- 與遺留系統的集成
WESB 通過 Adapter 與遺留系統進行集成，支持 IBM Websphere Adapter 和 JCA Adapter，通過 JCA 我們就可以將遺留系統里面的服務和數據通過標準（SCA/SDO）的形式整合到集成環境中。
- 安全方面的支持
WESB 沒有對安全做特殊的處理，使用 WAS 的安全支持來實現 ESB 的安全。
- 性能
WESB 是一個純 Java 的應用，運行效率上有些限制，同時可以處理的消息流的數量級為幾十到幾百之間。
- 開發和部署
開發工具是 WID，一個 ESB 的消息流在 WID 中被稱為 Mediation Module，它是一個 J2EE 應用，開發和部署工作無異于普通的企業級應用。
Message Broker
WMB 是 IBM 的應用整合中間件，是 IBM ESB 架構重要的產品組成部分之一，用于企業應用整合領域。WMB 目前的版本是 6.1.2，它的前身是 MQSeries Integrator。本質上看，WMB 是 MQ 的衍生產品，它使用 MQ 作為內部通信的機制。然后，WMB 提供的接入方式遠不止 MQ 一種，包括 JMS、HTTP(S)、SCADA 等常見的新一代接口規范。在消息轉化過程中，WMB 能夠識別 XML、C 結構、SOAP 等各種自定義的消息格式。
如圖 5 所示，WMB 可以分為開發環境和運行環境兩大部分。其中開發環境由開發工具（Toolkit）和調試環境（Rational Agent Controller）組成，運行環境是 WMB 核心，也叫 Broker Domain，由三部分組成，配置管理器（Configuration Manager）、用戶名服務器（User Name Server）和代理（Broker）。
圖 5. WMB 組件 
- 代理（Broker）：消息代理是 WMB 的消息處理引擎，它提供 WMB 的所有運行服務，在 Windows 系統上它是一個系統服務，在 Unix 平臺上表現為一個后臺進程。應用系統利用與 MQ 的連接和隊列將消息發送到消息代理。代理與代理之間，代理與配置管理器之間通過普通的 MQ 發生和接受類型的消息通道進行通信。在一個主機上我們可以創建一個或者多個 Broker，每個 Broker 會關聯一個數據庫，利用數據庫存儲 Broker 需要和相關的信息，每個 Broker 還需要一個隊列管理器，多個 Broker 之間不能共享同一個隊列管理器，每個 Broker 必須有自己特定的、唯一的隊列管理器。每個 Broker 只能被一個配置管理器控制。
- 配置管理器（Configuration Manager）：配置管理器是整個 WMB 運行環境中的控制中心，它維護整個 Broker Domain 的配置信息，配置和管理所有代理，增、刪、啟動、停止消息流，所有的開發工具也是通過配置管理器來部署編譯結果的。配置管理器也負責與用戶名服務器聯系，配置和管理各種用戶權限。配置管理器和其他各個部件之間的接口是 MQ，所以配置管理器也必須是基于 MQ 隊列管理器而運行的。
- 用戶名服務器（User Name Server）：用戶名服務器是 WMB 運行環境中的可選部分，它可以提供應用程序的接入認證以及訂閱主題的訪問控制服務。用戶名服務器本身是不需要數據庫，但必須依賴于隊列管理器與其他組件通信。用戶名服務器中的用戶信息來自認證數據文件。
- 開發工具（Toolkit）：開發工具是基于 Eclipse 3.0 的集成開發環境，我們可以在其中開發消息流、消息集、ESQL 代碼、Java 代碼、映射規則等。通過內置的 MQ Client 與配置管理器連接，并將開發好的執行組件部署到相關的代理中。Eclipse 環境由不同的視圖（Perspective）組成，我們在 WMB 中常用的有代理開發視圖、代理管理視圖等。
- 調試工具（Rational Agent Controller）：這是 IBM Rational 開發工具標準的調試工具。一般安裝在代理所在的服務器一邊，開發工具可以連接 RAC，通過它來控制和調試消息流的運行。需要注意的是，Toolkit 可以并行開發，但是對于同一個執行組不能并行調試，因 RAC 的調試過程是排他的。在 WMB6.0 之后 RAC 不需要再單獨安裝。
下面從九個方面來介紹 WMB 在實現一個 SOA ESB 解決方案上的支持的特點：
- 消息轉換
WMB 在消息處理方面功能非常強大，對 XML 格式的消息或非 XML 格式的消息，如 C Header，COBOL 等都有很好的支持。實際上，通過開發消息對應的消息集（Message Set），可以在消息流中對任意格式的消息進行修改。WMB 提供了內置的 mapping 和 database 節點，用戶可以通過圖形化的方式方便的實現消息的轉換或與數據庫的交互。
- 支持的協議
WMB 支持所有 WESB 支持的傳輸協議，除了常用的 HTTP、JMS 等，還對 FTP、Socket、Mobile、Telemetry、Biztalk 和 Tuxedo 等有良好的支持。WMB 與 MQ 有著緊密的聯系，對 MQ 的支持不在話下。WMB 內置的功能節點對這些協議提供了很好的支持，僅需配置即可，如圖 6 所示。
圖 6. Message Broker 的內置開發節點
- 消息路由
WMB 提供了很多功能強大的內置節點支持消息的路由，如 Filter 節點、Label 節點等，在新版本的 WMB 中又引入了 Router 節點，該節點幾乎和 WESB 中的 Router 節點一樣。若需要實現動態路由，可以使用 WSRR 作為服務的存儲，WMB 和 WSRR 有很好的集成，通過 RegistryLookup 和 EndpointLookup 我們可以在消息流中實現動態路由。另外需要指出的是，WMB 可以提供一個消息輸入，多個消息輸出的功能，可以實現一個消息同時路由到多個輸出端。
- 對 Web Service 的支持
在 WMB 中，消息流可以作為 Web Service 暴露出去供外部調用，也可以作為客戶端調用外部提供的 Web Service。WMB 不僅提供了內置的 SOAPRequest、SOAPInput 等節點實現對 Web Service 的支持，而且對 WS 擴展，如 WS-Security 和 WS-Addressing 也有良好的支持。
- 事件處理
在 WMB 中我們可以通過 Trace Service 來記錄所發生的事件。Trace 分兩種，一種是 User Trace 記錄消息流級別的事件，另一種是 Service Trace，可以記錄整個 WMB 的事件，如 Broker 的部署執行。WMB 提供了 Trace 內置節點，可以實時的記錄流程中消息內容的變化。
- 與遺留系統的集成
WMB 對遺留系統有良好的支持。對 SAP，PeopleSoft 等大型的 EIS 系統，直接提供了內置的節點，通過 JCA Adapter 配置的方式和 EIS 系統交互。對于比較特別的遺留系統，如 CICS、VSAM 等，WMB 提供了豐富的 SupportPacs，客戶可以下載并安裝。
- 安全方面的支持
WMB 本身提供了兩個層次上的安裝，一個是部署時安全性，管理部署 bar 文件到 Broker 以及運行 WMB 管理命令的權限控制；另一個是運行時安全，涉及的權限控制包括發送消息到相應的消息流，以及消息流可以訪問哪些 MQ 資源和非 MQ 資源，如數據庫系統。
- 性能
WMB 底層是使用 C++ 開發的，在性能上相對于 WESB 有很大的提高。同時可以處理的消息數量級為幾千到幾萬之間。
- 開發和部署
開發工具是 WMB Toolkit，我們開發的消息流和消息集被打成 bar 文件通過配置管理器部署到 Broker 中。
總的來說，WMB 是 IBM 久經考驗的一款消息中間件產品，為異構的 IT 環境提供了統一的連接和轉化，其優勢如下：
- 利用 WebSphere MQ 作為企業消息傳遞主干，提供了很好的并發性和可靠性
- 不僅支持各種標準協議，而且支持和 WebSphere 企業應用程序適配器進行集成
- 支持多種數據格式之間的轉換，包括 XML、遺留系統、行業標準和自定義消息格式
- 針對大量數據處理進行了優化，極大提高了處理速度。
Datapower
DataPower 是一個硬件產品，看起來像一個盒子。目前 IBM 有三款 Datapower 產品供用戶選擇。按照進入市場的先后次序，它們分別是：Datapower Accelerator XA35，Datapower Security Gateway XS40， Datapower Integration Appliance XI50，見圖 7。
圖 7. IBM 的 Datapower 產品線
- XA35 的主要側重點是 XML 加速，眾所周知，在 SOA 的環境中，XML 是應用最廣泛的，而對 XML 的解析，加密，解密這些操作讓應用服務器來做的話，這是一個很大性能開銷，而 XA35 就是要替應用服務器的分擔這些 XML 相關的工作，讓應用服務器專注于處理業務邏輯；
- XS40 的主要側重點是安全，即負責提供安全的企業網關，及對 XML 攻擊的防范。
- XI50，從名字上看，主要側重點是集成功能，是一款高級 ESB 產品，提供了多種協議和數據格式的路由和解析的功能。
雖然三款產品各有側重，但是三款產品的功能也具有包含關系，XS40 包含 XA35 的功能，XI50 包含 XS40 的功能。
我們依然從以下九個方面來介紹 Datapower 在實現 ESB 解決方案中的特點。
- 消息轉換
Datapower 對 XML 消息有強大的支持，但是 Datapower 絕不僅僅支持 XML，我們可以在 Policy 中使用 Transformation 節點來對消息進行任意我們需要的轉換，其原理是使用 XSLT 來實現的，開發人員定義自己 XSLT Stylesheet 并在 Transformation 節點中指定，Datapower 負責轉換。
- 支持的協議
Datapower 支持和以下傳輸協議，HTTP，HTTS，WebSphere MQ
WebSphere JMS，TIBICO EMS，FTP Poller, FTP Server, NFS 等等。 Datapower 的 MPGW 就是一個處理不同協議的應用系統的互聯的服務對象。
- 消息路由
Datapower 支持對服務和消息的路由，根據消息流中的上下文連接將消息動態的分發到不同的消息提供者。但是 Datapower 的動態路由和 WESB 以及 MB 的動態路由還是有區別的，Datapower 的動態路由需要由開發者定義路由的 Map，而 WESB 和 MB 支持在消息頭的屬性里動態的設置 Endpoint 的地址。目前 Datapower 可以和 WSRR 集成來定義 WS-Proxy（Datapower 中的一種服務對象），但不支持直接和 WSRR 聯合實現動態訪問 Endpoint 的功能。
- 對 Web Service 的支持
Datapower 的 XMlFirewall 和 WS-Proxy 提供了強大的對 Web Service 的支持，而且 datapower 提供了細粒度的對 Web Service 的控制，可以從服務級 (Service)，端口級 (port)，綁定級 (binding)，操作級 (operation) 來對消息體進行控制。此外，對 WS-Security 也提供了強大的支持。
- 事件處理
Datapower 中可以通過 Probe 的方式來跟蹤消息流的中間狀態，在 Probe 中，可以看到消息流的每個節點的消息內容。Probe 一般用于開發調試過程，在生產模式下一般不使用，因為使能 Probe 會犧牲一定的效率。Datapower 不支持與 CEI 類似將消息發送到其他應用系統的機制。
- 與遺留系統的集成
Datapower 不支持和 Adapter 的連接，若要與遺留系統的集成，則需要通過其他中間件轉換在遺留系統和 Datapower 之間做而橋梁來連接。
- 安全方面的支持
Datapower 的強大之處在于其對安全方面的強有力的支持，它提供對 XML-attack 的原生支持（關于 XML-attack 的知識參見參考資料）；此外，Datapower 可以對 Web Service 提供細粒度的安全支持，包括加密 (Encryption)，解密 (Decryption)，簽名 (Sign) 和確認 (Verify)，以及 HTTS 方面的支持。這些支持在 Datapower 上開發起來都異常簡單。
- 性能
Datapower 無疑是三款 ESB 產品中性能最高的，對 XML 的處理速度達到線速，下圖是一組測試結果。如果去處網絡傳輸在其中的比例，對 XML 的處理性能所提高的倍數可達到上百倍。
| Software Solution |
DP Solution |
| Avg. response time ( TimeP / N ) |
XML processing time ( TimeX ) |
Avg. response time ( TimeP / N ) |
XML processing time ( TimeX ) |
| 106 ms |
96 ms |
19 ms |
11ms |
- 開發和部署
Datapower 的沒有相應的開發工具，但是提供了 Web GUI 的管理控制臺和 CLI 方式的管理支持。我們在 Web GUI 下開發消息流，開發即部署。
高速的 XML 處理能力和強大的安全支持，是 Datapower 作為 SOA 應用中的 ESB 的重要特色，這個特點使得 Datapower 成為一款舉足輕重的 ESB 產品。
從上面的介紹我們可以看出，三款產品都提供了 ESB 的必須的功能，但各有側重：
- WESB 是一個輕量級的 ESB，側重于標準協議，SOAP,JMS 等應用的基礎，構建于 WASND 基礎之上，提供了和 J2EE 應用很好的集成功能；同時由于 WESB 是一個純 Java 的應用服務器，在性能上也是相對較差一點的 ESB，可并發執行的 Mediation Flow 的數量級在幾十個左右。WESB 適合使用于對性能要求不是很高，且遵循標準協議的 SOA 整合環境中。WESB 的優勢是提供了和流程服務器 WPS 以及 J2EE 服務器 WAS 良好的整合。WESB 的應用場景見圖 8：
圖 8. WESB 的應用場景 
- WMB 是一款高級的 ESB，提供了比 WESB 多很多的傳輸協議，數據格式的支持，它所支持幾乎大部分常用的數據格式和協議。并且 WMB 提供了良好的擴展功能，開發人員可以在 WMB 基礎上開發自己的數據格式解析的節點。WMB 使用 C/C++ 編寫，在處理性能上比 ESB 也要高出很多倍，可并發執行的流可以達到上百個或上千個。從圖 9 可以看出 WESB 和 WMB 在支持的協議上的區別。
圖 9. WESB 和 WMB 的比較 
WMB 應用于對性能要求相對較高，多種復雜協議存在的集成環境中。另外，WMB 構建于 WebSphere Message Queue（WMQ）之上。 WMQ 提供了對異步消息提供了可靠的傳送機制，比較適合于信息傳輸量較大，信息交互頻繁的場景中。如圖 10 所示：
圖 10. WMB 的使用場景
- Datapower 是 SOA 中的又一重要的 ESB，在 WESB 和 WMB 中都是用軟件來實現 XML 解析和安全支持的，而 Datapower 使用硬件的 XML 解析和加速器，在性能上有了很大的提高。在很多 SOA 的環境里，安全和性能是天平的兩端，增加安全勢必要犧牲性能；而提高性能則需要犧牲安全。所以在安全和性能要求都比較高的環境中，Datapower 是一首選 ESB，因為 Datapower 可以在實現高性能的同時也保證安全。圖 11 是一種 Datapower 的應用場景：
圖 11. Datapower 的使用場景 
基于上文對三款產品做了詳細的比較，我們可以做如下總結，WESB 適用于 J2EE 環境下，對性能要求不是很高的，標遵循標準協議的 SOA 集成；WMB 應用更復雜的集成環境，表現為數據格式多種，傳輸協議多樣，性能要求很高；而在安全和性能要求都很高的應用場景下，選擇 Datapower 無疑是最好的選擇。下面的圖表再次對文中的描述進行總結。
| ESB 功能特點 |
WESB 的支持 |
MB 的支持 |
Datapower |
| 消息轉換 |
XML |
XML、非 XML |
XML、非 XML |
| 支持的協議 |
HTTP,JMS, WMQ 等 |
多達上百種 |
介于前二者之間 |
| 消息路由 |
強大，靈活 |
功能強大，靈活 |
靈活度比前二者稍弱 |
| Web Service |
強大的支持 |
支持 WS 擴展 |
強大的支持 |
| 事件處理 |
CEI，可以和外部事件消費系統監控 |
Trace Service |
用于調試 Probe |
| 遺留系統的集成 |
Adapter |
豐富的 SupportPac |
特定的遺留系統 |
| 安全 |
依賴 WAS 的安全 |
部署和運行時兩個級別的安全 |
超強的安全支持 |
| 性能 |
幾十到幾百每秒 |
幾千到幾萬每秒 |
達到線速 |
| 開發和部署 |
WID 集成開發環境 |
WMB Toolkit |
WebGUI |
在本文的第 2 部分中，我們將用一個簡化的實際案例來描述三款 ESB 產品在實現上的差異。
學習
獲得產品和技術
討論