本文首先介紹了企業(yè)級應(yīng)用程序的發(fā)展以及 ESB 的定義;隨后,分析了 ESB 在 SOA 解決方案中所起的作用,并比較介紹了三款 ESB 產(chǎn)品在支持實現(xiàn)一個 ESB 解決方案中所起的作用。
企業(yè)應(yīng)用的發(fā)展概述
在介紹企業(yè)服務(wù)總線之前,有必要花一些筆墨來介紹企業(yè)應(yīng)用架構(gòu)的發(fā)展和變遷。企業(yè)級應(yīng)用架構(gòu)的發(fā)展經(jīng)歷了以下幾個階段:
- 獨立應(yīng)用系統(tǒng)
- EAI 階段
- SOA 階段
獨立應(yīng)用階段
20 世紀 60 到 70 年代,企業(yè)應(yīng)用處于獨立應(yīng)用系統(tǒng)階段,當時的企業(yè)應(yīng)用是一種用來替代重復(fù)性勞動的簡單設(shè)計,其目的是用計算機代替孤立的,體力性質(zhì)的工作環(huán)節(jié),將相關(guān)聯(lián)的企業(yè)信息或數(shù)據(jù)管理起來。這些系統(tǒng)大部分是獨立的系統(tǒng)——有獨立的數(shù)據(jù)庫、應(yīng)用服務(wù)器、用戶界面。因此有時候這類應(yīng)用也叫“豎井型”的應(yīng)用。
但是,隨著業(yè)務(wù)和信息的不斷擴展,獨立應(yīng)用系統(tǒng)漸漸不能滿足企業(yè)對 IT 的需求,表現(xiàn)在大量的信息冗余,因為在建立一個新的應(yīng)用的時候需要重新建立一套數(shù)據(jù)庫;功能的重新設(shè)計,相似的功能存在于多個系統(tǒng)中;例如,客戶信息在一個公司中可能有多個拷貝分別存在于多個數(shù)據(jù)庫中,不同時期建立的應(yīng)用系統(tǒng)所使用的技術(shù)也會不同。對于獲取客戶資料這樣的功能,必然存在于多個系統(tǒng)中,而且在不同的系統(tǒng)中其實現(xiàn)方式可能是 Java/J2EE、Delphi、C/C++。
EAI 階段
20 世紀 80 到 90 年代,一些公司或集成商意識到應(yīng)用集成的價值和必要性。EAI 是一種將多個不同平臺、用不同方案建立的異構(gòu)的應(yīng)用集成的一種技術(shù)和方法。它的目標包括以下幾個方面:各個分離的系統(tǒng)間的相互通訊,消除信息孤島,實現(xiàn)信息的共享。從功能的角度來看,EAI 包括信息接收、轉(zhuǎn)換、翻譯、路由、傳播和業(yè)務(wù)流程管理。從架構(gòu)上看有兩種方式:Hub/Spoke 方式和 Bus 方式。
圖 1 所示的 Hub/Spoke 結(jié)構(gòu)使用一個中心代理(Hub)和多個適配器(Spoke)將 Hub 和應(yīng)用連接起來。適配器負責將應(yīng)用的數(shù)據(jù)格式轉(zhuǎn)換成 Hub 可以理解的格式,Hub 將數(shù)據(jù)再轉(zhuǎn)換成目標系統(tǒng)可以理解的格式,并執(zhí)行消息的路由。Hub/Spoke 方式的弊端在于只有一個代理中心,當連接的應(yīng)用種類增加或者消息量增大時,代理中心的性能將成為整個系統(tǒng)的瓶頸,在可擴展性方面也存在著一定的問題。
圖 1 . Hub/Spoke 結(jié)構(gòu)的 EAI 集成
圖 2 所示的 Bus 結(jié)構(gòu)使用一個中心總線,應(yīng)用程序通過 Adapter 將消息發(fā)送給總線,總線負責消息的路由,接受方的應(yīng)用程序也有自己的 Adapter 來轉(zhuǎn)換接受到的消息。Bus 結(jié)構(gòu)和 Hub/Spoke 結(jié)構(gòu)的最大區(qū)別在于在 Bus 結(jié)構(gòu)中,Adapter 位于應(yīng)用程序中,而 Hub/Spoke 結(jié)構(gòu)中,Adapter 由 Hub 來統(tǒng)一管理。這樣在 Bus 結(jié)構(gòu)中,加入一個新的應(yīng)用變得很簡單,可擴展性得到了很大的提高,但是應(yīng)用程序方的負擔加重了。
圖 2. Bus 結(jié)構(gòu)的 EAI 集成
SOA 階段
SOA 將應(yīng)用資源看成一個個獨立的,自包含并良好定義的服務(wù),通過這些服務(wù)的組裝,編排可以產(chǎn)生新的應(yīng)用。每一個服務(wù)可以完成一個獨立業(yè)務(wù)功能,并且不依賴于業(yè)務(wù)上下文或者其他服務(wù)的狀態(tài)。服務(wù)的定義是標準的且被廣泛支持的,比如 Web Service。在 SOA 的架構(gòu)中,人們都用標準的方式來封裝自己的服務(wù),使得任何一個客戶端程序都可以容易的和后臺系統(tǒng)實施連接。而 ESB 是 SOA 架構(gòu)中的一個核心基石,在幾乎所有的 SOA 架構(gòu)中,都將 ESB 放在核心的位置。圖 3 是 IBM SOA Reference architecture,從中我們可以看出 ESB 在一個 SOA 架構(gòu)中的地位,對該圖的詳細解釋不在本文介紹范圍之內(nèi),有興趣的讀者可以參考一下 IBM SOA 專區(qū)的相關(guān)文章。
圖 3. IBM 的 SOA 參考架構(gòu)
下面我們來介紹一下 ESB。
什么是 ESB?
什么是 ESB?ESB 嚴格來說不是某一個產(chǎn)品,而是一種框架,設(shè)計模式。不同的提供商對 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 不僅僅是一個概念,而是一種中間件模式;它不是某個產(chǎn)品,而是一種全新的集成應(yīng)用,協(xié)調(diào)資源和操縱信息的框架。
下面來介紹 ESB 或可以稱為 ESB 的中間件產(chǎn)品保護一些特征,有些是必須的,有些是可選的:
- 連接性
ESB 必須提供一種支持服務(wù)交互的橋梁,它必須支持多協(xié)議 (protocol) 之間的連接。不僅要提供對消息和面向事件的中間件的支持,還要提供和現(xiàn)有 EAI 技術(shù)的連接。連接性是 ESB 不可缺少的特征之一。
- 服務(wù)交互
服務(wù)交互可以理解為 ESB 的一個目的之一,ESB 作為 SOA 架構(gòu)的核心,必然要支持服務(wù)的交互,要在服務(wù)的請求者和提供者架起一個堅實的橋梁,讓服務(wù)的請求者和提供者只需要關(guān)心各自的業(yè)務(wù)邏輯,而不需要在發(fā)布和消費服務(wù)的環(huán)節(jié)花很大力氣。服務(wù)交互也是 ESB 的必備特征。
- 集成
集成的概念是對于系統(tǒng)而言的,ESB 不僅要能集成那些很容易封裝服務(wù)的系統(tǒng),也要集成不能方便地封裝服務(wù)的系統(tǒng),例如 SAP, ERP, CRM, Siebel 等 EAI 系統(tǒng)、遺留系統(tǒng)。集成也是 ESB 的核心特征之一。
- 消息處理
在集成的過程中,必須要面對的是消息處理,在不同的應(yīng)用系統(tǒng)中,消息的描述格式是不一樣的。在集成環(huán)境中,必須要提供一種統(tǒng)一的格式來處理系統(tǒng)間的交互,從 ASBO(Application Specific Business Object ) 到 GBO(Generic Business Object) 之間的互轉(zhuǎn)是 ESB 的核心特征之一。
- 管理
對于一個具有 ESB 特征的產(chǎn)品,管理也是一個重要的方面。例如,當一個服務(wù)從一個地址切換到另一個地址,在結(jié)構(gòu)等不發(fā)生任何改變的時候,ESB 產(chǎn)品應(yīng)該提供一個方便的途徑適應(yīng)這種改變。
- QoS
對于服務(wù)交互來說,QoS 也是一個重要的特征,比如針對不同的服務(wù)請求者提供不同質(zhì)量的服務(wù)響應(yīng)。有些服務(wù)的請求需要在事務(wù)中完成,有些服務(wù)的交互需要保證其可靠性。一個 ESB 產(chǎn)品應(yīng)該提供給開發(fā)者定義 QoS 的接口。
- 安全
安全的必要性不言而喻,系統(tǒng)和系統(tǒng)之間的交互必然需要認證,授權(quán),加密,簽名等安全性。一個優(yōu)秀的 ESB 產(chǎn)品應(yīng)該提供可靠的,可靈活配置的安全支持。
IBM 有三款 ESB 產(chǎn)品:WebSphere ESB (WESB),WebSphere Message Broker(WMB),DataPower。這三款 ESB 產(chǎn)品都提供了 ESB 所必備的特征,但是它們各有側(cè)重,WESB 主要構(gòu)建與 WebSphere Application Server 之上,側(cè)重于對標準協(xié)議和消息的支持,更適合于 J2EE,Web-Service 為主要特征的集成環(huán)境;WMB 提供了一個高級的 ESB,它構(gòu)建于 WebSphere Message Queue 之上,提供了百種以上協(xié)議的連接和數(shù)據(jù)格式的轉(zhuǎn)換機制。Datapower 是一款比較新的 ESB 產(chǎn)品,除了提供必備的 ESB 的特性之外,Datapower 更側(cè)重于安全。眾所周知,在 XML 的環(huán)境中,安全對于性能的影響是巨大的,Datapower 給企業(yè) ESB 提供了強大的安全保障。下面分別介紹這三款 ESB 產(chǎn)品。
WebSphere ESB
從圖 4 中可以看出 ESB 構(gòu)建與 WAS ND 之上,它使用了 WAS ND 及 WAS 對于安全,用戶注冊表,事務(wù),消息引擎的支持,在其之上增加了對服務(wù)集成、消息流處理、建模以及 ESB 編程模型的支持等等。從圖中還可以看出 WebSphere Process Server 是構(gòu)建與 WESB 之上,并擴展了服務(wù)編排和流程管理方面的支持。
圖 4. WESB 在 WAS 產(chǎn)品線的位置
下面介紹在 WESB 上實現(xiàn)一個 SOA ESB 解決方案上的以下九個方面的特點,這九個方面的特點來源于上文中介紹的 ESB 的特性,或者特性的細化:
- 消息轉(zhuǎn)換
WESB 所處理的消息為 XML 格式的數(shù)據(jù),對于非 XML 結(jié)構(gòu)的數(shù)據(jù) WESB 不能處理。對于 XML 結(jié)構(gòu)的數(shù)據(jù),在 WESB 的消息流中數(shù)據(jù)以 SMO(IBM 對 SDO 的擴展,參見參考資料部分了解 SDO 的規(guī)范 ) 形式存在,WESB 可以對 XML 消息樹的內(nèi)容進行修改,包括改變某個節(jié)點的內(nèi)容,增加新的節(jié)點以及刪除某個節(jié)點等等。
- 支持的協(xié)議
WESB 支持符合 SOA 標準的協(xié)議,比如 SOAP/HTTP、SOAP/JMS、WSDL V1.1、UDDI V3.0,WebSphere MQ 等。也就是說 WESB 目前只支持 SOAP 方式來描述服務(wù),傳輸協(xié)議可以是 HTTP、JMS 記憶原生的 WebSphere MQ 的連接。對于多傳輸協(xié)議的基礎(chǔ),建議使用 MB 來做 ESB 的解決方案,參考 MB 的介紹部分。
- 消息路由
消息的路由在 WESB 中有良好的支持,開發(fā)環(huán)境 WID 中提供了一個節(jié)點專門來負責消息路由,WID 也提供了良好的對路由規(guī)則定義的開發(fā)支持,開發(fā)人員可以很容易的定制負責的路由規(guī)則。若要實現(xiàn)動態(tài)路由的功能,則需要和一個服務(wù)的存儲單元中來動態(tài)的查找服務(wù),目前 WSRR 是一款優(yōu)秀的提供該功能的工具(參見參考資料部分了解 WSRR)。WESB 從 V6.1 開始提供了 Endpoint lookup 節(jié)點來支持 WSRR 的集成,簡化了開發(fā)過程。如果要實現(xiàn)簡單的動態(tài)服務(wù)路由的功能,則可把服務(wù)的定義存放在數(shù)據(jù)庫中,在 WESB 中通過 DB lookup 來查找服務(wù)的 Endpoint, 然后注入到消息流中,WESB V6.1 之前的版本就已經(jīng)支持與數(shù)據(jù)庫的集成。
- 對 Web Service 的支持
WESB 天生運行在 J2EE 的環(huán)境里面,對 Web Service 有著天然的支持。
- 事件處理
在消息流中,我們需要跟蹤消息各節(jié)點的狀態(tài),以滿足統(tǒng)計和出錯處理的要求,在 WESB 中,通過 CEI 機制來處理消息。(CEI 的介紹請參見參考資料部分)
- 與遺留系統(tǒng)的集成
WESB 通過 Adapter 與遺留系統(tǒng)進行集成,支持 IBM Websphere Adapter 和 JCA Adapter,通過 JCA 我們就可以將遺留系統(tǒng)里面的服務(wù)和數(shù)據(jù)通過標準(SCA/SDO)的形式整合到集成環(huán)境中。
- 安全方面的支持
WESB 沒有對安全做特殊的處理,使用 WAS 的安全支持來實現(xiàn) ESB 的安全。
- 性能
WESB 是一個純 Java 的應(yīng)用,運行效率上有些限制,同時可以處理的消息流的數(shù)量級為幾十到幾百之間。
- 開發(fā)和部署
開發(fā)工具是 WID,一個 ESB 的消息流在 WID 中被稱為 Mediation Module,它是一個 J2EE 應(yīng)用,開發(fā)和部署工作無異于普通的企業(yè)級應(yīng)用。
Message Broker
WMB 是 IBM 的應(yīng)用整合中間件,是 IBM ESB 架構(gòu)重要的產(chǎn)品組成部分之一,用于企業(yè)應(yīng)用整合領(lǐng)域。WMB 目前的版本是 6.1.2,它的前身是 MQSeries Integrator。本質(zhì)上看,WMB 是 MQ 的衍生產(chǎn)品,它使用 MQ 作為內(nèi)部通信的機制。然后,WMB 提供的接入方式遠不止 MQ 一種,包括 JMS、HTTP(S)、SCADA 等常見的新一代接口規(guī)范。在消息轉(zhuǎn)化過程中,WMB 能夠識別 XML、C 結(jié)構(gòu)、SOAP 等各種自定義的消息格式。
如圖 5 所示,WMB 可以分為開發(fā)環(huán)境和運行環(huán)境兩大部分。其中開發(fā)環(huán)境由開發(fā)工具(Toolkit)和調(diào)試環(huán)境(Rational Agent Controller)組成,運行環(huán)境是 WMB 核心,也叫 Broker Domain,由三部分組成,配置管理器(Configuration Manager)、用戶名服務(wù)器(User Name Server)和代理(Broker)。
圖 5. WMB 組件
- 代理(Broker):消息代理是 WMB 的消息處理引擎,它提供 WMB 的所有運行服務(wù),在 Windows 系統(tǒng)上它是一個系統(tǒng)服務(wù),在 Unix 平臺上表現(xiàn)為一個后臺進程。應(yīng)用系統(tǒng)利用與 MQ 的連接和隊列將消息發(fā)送到消息代理。代理與代理之間,代理與配置管理器之間通過普通的 MQ 發(fā)生和接受類型的消息通道進行通信。在一個主機上我們可以創(chuàng)建一個或者多個 Broker,每個 Broker 會關(guān)聯(lián)一個數(shù)據(jù)庫,利用數(shù)據(jù)庫存儲 Broker 需要和相關(guān)的信息,每個 Broker 還需要一個隊列管理器,多個 Broker 之間不能共享同一個隊列管理器,每個 Broker 必須有自己特定的、唯一的隊列管理器。每個 Broker 只能被一個配置管理器控制。
- 配置管理器(Configuration Manager):配置管理器是整個 WMB 運行環(huán)境中的控制中心,它維護整個 Broker Domain 的配置信息,配置和管理所有代理,增、刪、啟動、停止消息流,所有的開發(fā)工具也是通過配置管理器來部署編譯結(jié)果的。配置管理器也負責與用戶名服務(wù)器聯(lián)系,配置和管理各種用戶權(quán)限。配置管理器和其他各個部件之間的接口是 MQ,所以配置管理器也必須是基于 MQ 隊列管理器而運行的。
- 用戶名服務(wù)器(User Name Server):用戶名服務(wù)器是 WMB 運行環(huán)境中的可選部分,它可以提供應(yīng)用程序的接入認證以及訂閱主題的訪問控制服務(wù)。用戶名服務(wù)器本身是不需要數(shù)據(jù)庫,但必須依賴于隊列管理器與其他組件通信。用戶名服務(wù)器中的用戶信息來自認證數(shù)據(jù)文件。
- 開發(fā)工具(Toolkit):開發(fā)工具是基于 Eclipse 3.0 的集成開發(fā)環(huán)境,我們可以在其中開發(fā)消息流、消息集、ESQL 代碼、Java 代碼、映射規(guī)則等。通過內(nèi)置的 MQ Client 與配置管理器連接,并將開發(fā)好的執(zhí)行組件部署到相關(guān)的代理中。Eclipse 環(huán)境由不同的視圖(Perspective)組成,我們在 WMB 中常用的有代理開發(fā)視圖、代理管理視圖等。
- 調(diào)試工具(Rational Agent Controller):這是 IBM Rational 開發(fā)工具標準的調(diào)試工具。一般安裝在代理所在的服務(wù)器一邊,開發(fā)工具可以連接 RAC,通過它來控制和調(diào)試消息流的運行。需要注意的是,Toolkit 可以并行開發(fā),但是對于同一個執(zhí)行組不能并行調(diào)試,因 RAC 的調(diào)試過程是排他的。在 WMB6.0 之后 RAC 不需要再單獨安裝。
下面從九個方面來介紹 WMB 在實現(xiàn)一個 SOA ESB 解決方案上的支持的特點:
- 消息轉(zhuǎn)換
WMB 在消息處理方面功能非常強大,對 XML 格式的消息或非 XML 格式的消息,如 C Header,COBOL 等都有很好的支持。實際上,通過開發(fā)消息對應(yīng)的消息集(Message Set),可以在消息流中對任意格式的消息進行修改。WMB 提供了內(nèi)置的 mapping 和 database 節(jié)點,用戶可以通過圖形化的方式方便的實現(xiàn)消息的轉(zhuǎn)換或與數(shù)據(jù)庫的交互。
- 支持的協(xié)議
WMB 支持所有 WESB 支持的傳輸協(xié)議,除了常用的 HTTP、JMS 等,還對 FTP、Socket、Mobile、Telemetry、Biztalk 和 Tuxedo 等有良好的支持。WMB 與 MQ 有著緊密的聯(lián)系,對 MQ 的支持不在話下。WMB 內(nèi)置的功能節(jié)點對這些協(xié)議提供了很好的支持,僅需配置即可,如圖 6 所示。
圖 6. Message Broker 的內(nèi)置開發(fā)節(jié)點
- 消息路由
WMB 提供了很多功能強大的內(nèi)置節(jié)點支持消息的路由,如 Filter 節(jié)點、Label 節(jié)點等,在新版本的 WMB 中又引入了 Router 節(jié)點,該節(jié)點幾乎和 WESB 中的 Router 節(jié)點一樣。若需要實現(xiàn)動態(tài)路由,可以使用 WSRR 作為服務(wù)的存儲,WMB 和 WSRR 有很好的集成,通過 RegistryLookup 和 EndpointLookup 我們可以在消息流中實現(xiàn)動態(tài)路由。另外需要指出的是,WMB 可以提供一個消息輸入,多個消息輸出的功能,可以實現(xiàn)一個消息同時路由到多個輸出端。
- 對 Web Service 的支持
在 WMB 中,消息流可以作為 Web Service 暴露出去供外部調(diào)用,也可以作為客戶端調(diào)用外部提供的 Web Service。WMB 不僅提供了內(nèi)置的 SOAPRequest、SOAPInput 等節(jié)點實現(xiàn)對 Web Service 的支持,而且對 WS 擴展,如 WS-Security 和 WS-Addressing 也有良好的支持。
- 事件處理
在 WMB 中我們可以通過 Trace Service 來記錄所發(fā)生的事件。Trace 分兩種,一種是 User Trace 記錄消息流級別的事件,另一種是 Service Trace,可以記錄整個 WMB 的事件,如 Broker 的部署執(zhí)行。WMB 提供了 Trace 內(nèi)置節(jié)點,可以實時的記錄流程中消息內(nèi)容的變化。
- 與遺留系統(tǒng)的集成
WMB 對遺留系統(tǒng)有良好的支持。對 SAP,PeopleSoft 等大型的 EIS 系統(tǒng),直接提供了內(nèi)置的節(jié)點,通過 JCA Adapter 配置的方式和 EIS 系統(tǒng)交互。對于比較特別的遺留系統(tǒng),如 CICS、VSAM 等,WMB 提供了豐富的 SupportPacs,客戶可以下載并安裝。
- 安全方面的支持
WMB 本身提供了兩個層次上的安裝,一個是部署時安全性,管理部署 bar 文件到 Broker 以及運行 WMB 管理命令的權(quán)限控制;另一個是運行時安全,涉及的權(quán)限控制包括發(fā)送消息到相應(yīng)的消息流,以及消息流可以訪問哪些 MQ 資源和非 MQ 資源,如數(shù)據(jù)庫系統(tǒng)。
- 性能
WMB 底層是使用 C++ 開發(fā)的,在性能上相對于 WESB 有很大的提高。同時可以處理的消息數(shù)量級為幾千到幾萬之間。
- 開發(fā)和部署
開發(fā)工具是 WMB Toolkit,我們開發(fā)的消息流和消息集被打成 bar 文件通過配置管理器部署到 Broker 中。
總的來說,WMB 是 IBM 久經(jīng)考驗的一款消息中間件產(chǎn)品,為異構(gòu)的 IT 環(huán)境提供了統(tǒng)一的連接和轉(zhuǎn)化,其優(yōu)勢如下:
- 利用 WebSphere MQ 作為企業(yè)消息傳遞主干,提供了很好的并發(fā)性和可靠性
- 不僅支持各種標準協(xié)議,而且支持和 WebSphere 企業(yè)應(yīng)用程序適配器進行集成
- 支持多種數(shù)據(jù)格式之間的轉(zhuǎn)換,包括 XML、遺留系統(tǒng)、行業(yè)標準和自定義消息格式
- 針對大量數(shù)據(jù)處理進行了優(yōu)化,極大提高了處理速度。
Datapower
DataPower 是一個硬件產(chǎn)品,看起來像一個盒子。目前 IBM 有三款 Datapower 產(chǎn)品供用戶選擇。按照進入市場的先后次序,它們分別是:Datapower Accelerator XA35,Datapower Security Gateway XS40, Datapower Integration Appliance XI50,見圖 7。
圖 7. IBM 的 Datapower 產(chǎn)品線
- XA35 的主要側(cè)重點是 XML 加速,眾所周知,在 SOA 的環(huán)境中,XML 是應(yīng)用最廣泛的,而對 XML 的解析,加密,解密這些操作讓應(yīng)用服務(wù)器來做的話,這是一個很大性能開銷,而 XA35 就是要替應(yīng)用服務(wù)器的分擔這些 XML 相關(guān)的工作,讓應(yīng)用服務(wù)器專注于處理業(yè)務(wù)邏輯;
- XS40 的主要側(cè)重點是安全,即負責提供安全的企業(yè)網(wǎng)關(guān),及對 XML 攻擊的防范。
- XI50,從名字上看,主要側(cè)重點是集成功能,是一款高級 ESB 產(chǎn)品,提供了多種協(xié)議和數(shù)據(jù)格式的路由和解析的功能。
雖然三款產(chǎn)品各有側(cè)重,但是三款產(chǎn)品的功能也具有包含關(guān)系,XS40 包含 XA35 的功能,XI50 包含 XS40 的功能。
我們依然從以下九個方面來介紹 Datapower 在實現(xiàn) ESB 解決方案中的特點。
- 消息轉(zhuǎn)換
Datapower 對 XML 消息有強大的支持,但是 Datapower 絕不僅僅支持 XML,我們可以在 Policy 中使用 Transformation 節(jié)點來對消息進行任意我們需要的轉(zhuǎn)換,其原理是使用 XSLT 來實現(xiàn)的,開發(fā)人員定義自己 XSLT Stylesheet 并在 Transformation 節(jié)點中指定,Datapower 負責轉(zhuǎn)換。
- 支持的協(xié)議
Datapower 支持和以下傳輸協(xié)議,HTTP,HTTS,WebSphere MQ
WebSphere JMS,TIBICO EMS,F(xiàn)TP Poller, FTP Server, NFS 等等。 Datapower 的 MPGW 就是一個處理不同協(xié)議的應(yīng)用系統(tǒng)的互聯(lián)的服務(wù)對象。
- 消息路由
Datapower 支持對服務(wù)和消息的路由,根據(jù)消息流中的上下文連接將消息動態(tài)的分發(fā)到不同的消息提供者。但是 Datapower 的動態(tài)路由和 WESB 以及 MB 的動態(tài)路由還是有區(qū)別的,Datapower 的動態(tài)路由需要由開發(fā)者定義路由的 Map,而 WESB 和 MB 支持在消息頭的屬性里動態(tài)的設(shè)置 Endpoint 的地址。目前 Datapower 可以和 WSRR 集成來定義 WS-Proxy(Datapower 中的一種服務(wù)對象),但不支持直接和 WSRR 聯(lián)合實現(xiàn)動態(tài)訪問 Endpoint 的功能。
- 對 Web Service 的支持
Datapower 的 XMlFirewall 和 WS-Proxy 提供了強大的對 Web Service 的支持,而且 datapower 提供了細粒度的對 Web Service 的控制,可以從服務(wù)級 (Service),端口級 (port),綁定級 (binding),操作級 (operation) 來對消息體進行控制。此外,對 WS-Security 也提供了強大的支持。
- 事件處理
Datapower 中可以通過 Probe 的方式來跟蹤消息流的中間狀態(tài),在 Probe 中,可以看到消息流的每個節(jié)點的消息內(nèi)容。Probe 一般用于開發(fā)調(diào)試過程,在生產(chǎn)模式下一般不使用,因為使能 Probe 會犧牲一定的效率。Datapower 不支持與 CEI 類似將消息發(fā)送到其他應(yīng)用系統(tǒng)的機制。
- 與遺留系統(tǒng)的集成
Datapower 不支持和 Adapter 的連接,若要與遺留系統(tǒng)的集成,則需要通過其他中間件轉(zhuǎn)換在遺留系統(tǒng)和 Datapower 之間做而橋梁來連接。
- 安全方面的支持
Datapower 的強大之處在于其對安全方面的強有力的支持,它提供對 XML-attack 的原生支持(關(guān)于 XML-attack 的知識參見參考資料);此外,Datapower 可以對 Web Service 提供細粒度的安全支持,包括加密 (Encryption),解密 (Decryption),簽名 (Sign) 和確認 (Verify),以及 HTTS 方面的支持。這些支持在 Datapower 上開發(fā)起來都異常簡單。
- 性能
Datapower 無疑是三款 ESB 產(chǎn)品中性能最高的,對 XML 的處理速度達到線速,下圖是一組測試結(jié)果。如果去處網(wǎng)絡(luò)傳輸在其中的比例,對 XML 的處理性能所提高的倍數(shù)可達到上百倍。
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 |
- 開發(fā)和部署
Datapower 的沒有相應(yīng)的開發(fā)工具,但是提供了 Web GUI 的管理控制臺和 CLI 方式的管理支持。我們在 Web GUI 下開發(fā)消息流,開發(fā)即部署。
高速的 XML 處理能力和強大的安全支持,是 Datapower 作為 SOA 應(yīng)用中的 ESB 的重要特色,這個特點使得 Datapower 成為一款舉足輕重的 ESB 產(chǎn)品。
從上面的介紹我們可以看出,三款產(chǎn)品都提供了 ESB 的必須的功能,但各有側(cè)重:
- WESB 是一個輕量級的 ESB,側(cè)重于標準協(xié)議,SOAP,JMS 等應(yīng)用的基礎(chǔ),構(gòu)建于 WASND 基礎(chǔ)之上,提供了和 J2EE 應(yīng)用很好的集成功能;同時由于 WESB 是一個純 Java 的應(yīng)用服務(wù)器,在性能上也是相對較差一點的 ESB,可并發(fā)執(zhí)行的 Mediation Flow 的數(shù)量級在幾十個左右。WESB 適合使用于對性能要求不是很高,且遵循標準協(xié)議的 SOA 整合環(huán)境中。WESB 的優(yōu)勢是提供了和流程服務(wù)器 WPS 以及 J2EE 服務(wù)器 WAS 良好的整合。WESB 的應(yīng)用場景見圖 8:
圖 8. WESB 的應(yīng)用場景
- WMB 是一款高級的 ESB,提供了比 WESB 多很多的傳輸協(xié)議,數(shù)據(jù)格式的支持,它所支持幾乎大部分常用的數(shù)據(jù)格式和協(xié)議。并且 WMB 提供了良好的擴展功能,開發(fā)人員可以在 WMB 基礎(chǔ)上開發(fā)自己的數(shù)據(jù)格式解析的節(jié)點。WMB 使用 C/C++ 編寫,在處理性能上比 ESB 也要高出很多倍,可并發(fā)執(zhí)行的流可以達到上百個或上千個。從圖 9 可以看出 WESB 和 WMB 在支持的協(xié)議上的區(qū)別。
圖 9. WESB 和 WMB 的比較
WMB 應(yīng)用于對性能要求相對較高,多種復(fù)雜協(xié)議存在的集成環(huán)境中。另外,WMB 構(gòu)建于 WebSphere Message Queue(WMQ)之上。 WMQ 提供了對異步消息提供了可靠的傳送機制,比較適合于信息傳輸量較大,信息交互頻繁的場景中。如圖 10 所示:
圖 10. WMB 的使用場景
- Datapower 是 SOA 中的又一重要的 ESB,在 WESB 和 WMB 中都是用軟件來實現(xiàn) XML 解析和安全支持的,而 Datapower 使用硬件的 XML 解析和加速器,在性能上有了很大的提高。在很多 SOA 的環(huán)境里,安全和性能是天平的兩端,增加安全勢必要犧牲性能;而提高性能則需要犧牲安全。所以在安全和性能要求都比較高的環(huán)境中,Datapower 是一首選 ESB,因為 Datapower 可以在實現(xiàn)高性能的同時也保證安全。圖 11 是一種 Datapower 的應(yīng)用場景:
圖 11. Datapower 的使用場景
基于上文對三款產(chǎn)品做了詳細的比較,我們可以做如下總結(jié),WESB 適用于 J2EE 環(huán)境下,對性能要求不是很高的,標遵循標準協(xié)議的 SOA 集成;WMB 應(yīng)用更復(fù)雜的集成環(huán)境,表現(xiàn)為數(shù)據(jù)格式多種,傳輸協(xié)議多樣,性能要求很高;而在安全和性能要求都很高的應(yīng)用場景下,選擇 Datapower 無疑是最好的選擇。下面的圖表再次對文中的描述進行總結(jié)。
ESB 功能特點 |
WESB 的支持 |
MB 的支持 |
Datapower |
消息轉(zhuǎn)換 |
XML |
XML、非 XML |
XML、非 XML |
支持的協(xié)議 |
HTTP,JMS, WMQ 等 |
多達上百種 |
介于前二者之間 |
消息路由 |
強大,靈活 |
功能強大,靈活 |
靈活度比前二者稍弱 |
Web Service |
強大的支持 |
支持 WS 擴展 |
強大的支持 |
事件處理 |
CEI,可以和外部事件消費系統(tǒng)監(jiān)控 |
Trace Service |
用于調(diào)試 Probe |
遺留系統(tǒng)的集成 |
Adapter |
豐富的 SupportPac |
特定的遺留系統(tǒng) |
安全 |
依賴 WAS 的安全 |
部署和運行時兩個級別的安全 |
超強的安全支持 |
性能 |
幾十到幾百每秒 |
幾千到幾萬每秒 |
達到線速 |
開發(fā)和部署 |
WID 集成開發(fā)環(huán)境 |
WMB Toolkit |
WebGUI |
在本文的第 2 部分中,我們將用一個簡化的實際案例來描述三款 ESB 產(chǎn)品在實現(xiàn)上的差異。
學(xué)習(xí)
獲得產(chǎn)品和技術(shù)
- 使用 IBM 試用軟件 開發(fā)您的下一個項目,可下載或索取 DVD 光盤。
討論