公司內(nèi)外的不同應(yīng)用間需要進行相互通信。企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）已經(jīng)被視為支持應(yīng)用集成的工具。但是ESB是什么呢？什么時候使用集成套件（integration suite）更為合適呢？下一個項目最合適的產(chǎn)品是什么？本文將會講述為什么沒有銀彈（silver bullet）以及為何有時ESB可能也是錯誤的選擇。對于項目的成功來講，選擇合適的產(chǎn)品是至關(guān)重要的。
眾多來自不同供應(yīng)商的產(chǎn)品都包含了“企業(yè)服務(wù)總線”的名字。令人遺憾的是，這個術(shù)語并沒有標(biāo)準(zhǔn)的定義。因此，這些產(chǎn)品提供了很多不同的特性。在使用之前，ESB這個術(shù)語應(yīng)該進行清晰地定義。在后文中，ESB可以定義為幫助開發(fā)人員進行應(yīng)用集成的軟件產(chǎn)品，因此它會提供必要的基礎(chǔ)設(shè)施來實現(xiàn)路由、轉(zhuǎn)換以及其他的集成設(shè)施。按照集成的復(fù)雜性路徑，ESB通常會位于框架和套件之間，會作為應(yīng)用集成的可選方案，如下圖所示：
框架會幫助實現(xiàn)企業(yè)集成模式（Enterprise Integration Patterns，EIP, http://www.eaipatterns.com），如Splitter或基于內(nèi)容的路由（Content Based Router）,從而能夠以標(biāo)準(zhǔn)的方式進行應(yīng)用集成。使用標(biāo)準(zhǔn)的API來集成產(chǎn)品可以明顯地減少實現(xiàn)所付出的努力并且源碼能夠更容易被其他開發(fā)人員理解。框架可以很好地基于不同的協(xié)議和技術(shù)來集成不同的應(yīng)用，像端點（endpoint）、生產(chǎn)者（producer）、消費者（consumer）以及EIP這樣的理念可以用來創(chuàng)建集成邏輯。即便背后的支持性測試也使用了相同的理念。
框架包含了一些通用的庫因此可以與任何開發(fā)環(huán)境兼容，即便是傳統(tǒng)的文本編輯器也是可以的。
在Java環(huán)境中知名的框架樣例是Apache Camel以及Spring Integration，在.NET中則是NServiceBus。
使用框架的話，開發(fā)團隊要或多或少全權(quán)負責(zé)項目的成功。通常不會有商業(yè)上的支持。工具一般也只會部分可用，并且不一定適合“關(guān)鍵任務(wù)”（mission-critical）的部署。因此本文剩余的內(nèi)容將會關(guān)注ESB以及對應(yīng)的套件，通常來說它們是比框架更好的選擇。
類似于框架，ESB也用來集成應(yīng)用。ESB在幕后會基于框架。但是，它是更為強大的產(chǎn)品。相對于框架來講，除了應(yīng)用集成的基本功能以外，ESB還提供了強大的工具來支持部署、管理以及運行時的監(jiān)控。另外，圖形化的編輯器可以用于實現(xiàn)各種集成場景。集成邏輯可以使用“拖拽操作”來建模，對應(yīng)的代碼將會自動生成。ESB會包含商業(yè)化的支持。
相對于單純地使用框架，ESB的巨大優(yōu)勢在于更好的工具，它會明顯地降低成本和復(fù)雜性?？梢栽诟叩某橄蟮燃壗鉀Q集成的問題。
套件提供了ESB的所有特性。另外，還會包含很多其他的功能，如業(yè)務(wù)流程管理（Business Process Management，BPM）、業(yè)務(wù)活動監(jiān)控（Business Activity Monitoring）、主數(shù)據(jù)管理（Master Data Management）或倉庫（Repository）。如果除了單純的集成還需要某些附加的特性，那么建議使用套件。借助一個軟件棧（software stack）就能實現(xiàn)全部的集成。
希望你現(xiàn)在已經(jīng)明白了框架、ESB以及套件的區(qū)別。接下來會介紹如何選擇合適的ESB或套件。
注意：我們不會提供按照各種標(biāo)準(zhǔn)比較所有產(chǎn)品的矩陣。以筆者看來，創(chuàng)建一個良好且有用的矩陣幾乎是不可能的，因為這些產(chǎn)品提供了如此之多的（通常還是不同的）功能和理念。除此之外，在IT世界中，所列的特性實際上每天都在發(fā)生著變化。
因此，建議你預(yù)先定義自己的需求，然后評估哪一個產(chǎn)品是最合適的。專有的解決方案通常是類似的，而最經(jīng)常使用的開源競爭對手也提供了類似的特征。因此，在開始的時候，要考慮專有的還是開源的解決方案中，哪一個是更好的選擇。
為了做出決策，你應(yīng)該使用以下的指標(biāo)：
表1比較了專有的和開源的ESB以及套件之間的優(yōu)勢和劣勢（綠色=良好，紅色=居中，紅色=較差）?？紤]到差異，所得到的結(jié)論如下：專有的解決方案通常提供了更多的特性以及“強大”的支持。但是，存在的問題在于，“它們是真的是需要的嗎？”要記住的是，它們所要付出的努力、復(fù)雜性以及成本都會隨之增高。開源產(chǎn)品會在使用便利性、更強的靈活性、易于擴展以及低成本方面得分。
| 指標(biāo) | 專有產(chǎn)品 | 開源產(chǎn)品 |
| 易用性 | 安裝很復(fù)雜（需要咨詢顧問??？），“工具地獄（tool hell）” | 一鍵點擊安裝（很多場景下對Mac也是如此），幾分鐘后就可以開始使用，統(tǒng)一的平臺 |
| 可維護性與監(jiān)控 | 強大的工具（例如，用于管理和監(jiān)控）、不必分析源碼，通過GUI進行重構(gòu) | 工具的強大性稍差（例如，用于管理和監(jiān)控，有時候需要進一步集成其他廠商的產(chǎn)品），不必分析源碼，通過GUI進行重構(gòu) |
| 社區(qū) | 購買支持、論壇（但是沒有真正提供幫助的社區(qū)） | 基于開源的項目，以及自己的社區(qū) |
| 企業(yè)級支持 | 24/7企業(yè)級支持、按需的服務(wù)等級協(xié)議（SLA）、上千臺服務(wù)器的部署 | 24/7企業(yè)級支持、比專有產(chǎn)品支持的保障性稍差、要確認本地的咨詢和支持 |
| 功能性 | 集成特性+眾多其他特性（業(yè)務(wù)活動監(jiān)控Business Activity Monitoring BAM、復(fù)雜事件處理Complex Event Processing CEP、電子設(shè)計自動化Electronic Design Automation EDA等等） | 集成特性+一些其他特性 |
| 靈活性 | （發(fā)出變更請求+長時間等待+支付）或者（支付巨資+快速得到響應(yīng)） | 開源，按照需求進行變化 |
| 可擴展性 | 自己做（很難）或者付費 | 基于標(biāo)準(zhǔn)，事實標(biāo)準(zhǔn) |
| 連接器 | 對技術(shù)和業(yè)務(wù)產(chǎn)品的適配器 | 對技術(shù)和業(yè)務(wù)產(chǎn)品的適配器 |
| 成本 | 高（甚至非常高） | 較低 |
| 許可證 | 復(fù)雜的報價列表、要為一切付費（升級、遷移至虛擬機、“各種名義（you-name-it））” | 定制收費、包括升級、可預(yù)測的成本、可能允許降級 |
表1：專有和開源產(chǎn)品的優(yōu)勢與劣勢
在描述完專有產(chǎn)品和開源產(chǎn)品的主要不同之后，下面介紹一些相關(guān)的產(chǎn)品。因此，我將會給出各種可行方案的概要介紹以及簡短實用的分析。
幾乎每家專有集成產(chǎn)品的廠商都提供了包含所有功能的解決方案，如IBM和Oracle。至于開源的可選方案，尤其值得一提的是Talend的統(tǒng)一平臺（Unified Platform）以及WSO2平臺，它們也提供了完備的套件。除此之外，還有一些可選方案只專注于ESB，這方面可能最重要的開源提供者是Mule ESB以及Fuse ESB。
Oracle服務(wù)總線是Oracle目前的ESB。它是Oracle Fusion中間件（Oracle Fusion Middleware，OFM）軟件棧的一個組件，它符合本文中對集成套件的定義。其中還包含了很多其他的產(chǎn)品，如SOA套件（SOA Suite）、Coherence、復(fù)雜事件處理（Complex Event Processing）、BPEL處理管理器（BPEL Process Manager）、企業(yè)信息服務(wù)（Enterprise Messaging Service）、服務(wù)注冊中心（Service Registry）等等。
很難找到Oracle套件所沒有提供的功能。工具非常強大和穩(wěn)定。對于大多數(shù)的產(chǎn)品都有圖形化編輯器。對于能夠想到的服務(wù)等級協(xié)議都能得到服務(wù)支持。如果這些強大的功能和SLA真的是你需要的，那么你可以選擇Oracle。這種強大當(dāng)然也是要付出一定成本的。不應(yīng)低估產(chǎn)品的高度復(fù)雜性。另外，你還要注意許可證和支持的高昂成本以及不透明的定價模式。
OFM是基于標(biāo)準(zhǔn)的，如Java EE、BPEL、SOAP以及SCA。產(chǎn)品是專有的，它們來源于Oracle在過去的多次收購。因此，使用了不同的代碼基，不同的產(chǎn)品通常會使用不同的開發(fā)工具。下載的總量能夠迅速到達20Gb。安裝是非常耗時的，偶爾會需要幾天的時間——即便只是在筆記本上的簡單安裝也可能如此。產(chǎn)品是相當(dāng)重量級的。運行時的資源要求也很高。
另外，你可以將“Oracle”替換為“IBM”并將“Fusion中間件”替換為“WebSphere”，本節(jié)所討論的內(nèi)容依然成立——值得一提的是，IBM在其產(chǎn)品組合中有三個不同的ESB：Message Broker、ESB以及DataPower SOA Appliances。Tobco、Microsoft以及SAP在專有ESB和集成套件市場上也扮演著重要的角色。
因此，這一部分的結(jié)論可以這樣說，專有的集成套件幾乎可以提供所有需要的功能并涵蓋所有的SLA。但是，在大多數(shù)的項目中，很多功能和SLA并不是必需的。在這種情況下，一定也要評估一下開源的替代方案。它們中最重要的產(chǎn)品在接下來的小節(jié)中進行了描述。
Mule ESB是最早成功的開源ESB之一。它具備前面所提到的開源ESB的很多通用特征。這包括非常簡單（“一鍵點擊”）的安裝以及直觀的、基于Eclipse的工具。通常，開源的ESB是非常輕量級和可擴展的解決方案。除了開源的免費版本，還有商用的企業(yè)級版本。這會為產(chǎn)品提供額外的功能和支持。
對于那些還沒有了解的人來說，需要提及的一點是“開源”并不意味著“免費”。開源軟件的廠商必須要掙錢，因此不能免費地開發(fā)軟件和提供支持。但是，對顧客來說價格會友好得多，同時也不會像專有產(chǎn)品那樣基于晦澀難懂的價格列表。不過，開源版本可以用在任何環(huán)境（甚至是生產(chǎn)環(huán)境）下，并沒有許可證的成本。但通常，開源版本只是用來了解的，并為稍后升級到企業(yè)級版本提供可行的證明，企業(yè)級版本會有額外的特性和支持。
正如其名字所示，Mule ESB是純粹的ESB。相對于Apache Camel和Spring Integration這樣的框架，其重要的優(yōu)勢在于能夠高效實現(xiàn)集成場景的圖形化編輯器，以及為SAP或Salesforce這樣的B2B產(chǎn)品所提供的連接器。但是，在Mule ESB中會缺少套件的功能。為了應(yīng)對這樣的使用場景，ESB必須要與其他廠商的產(chǎn)品聯(lián)合使用。Mule ESB的不利因素在于較小的社區(qū)、限制性的許可證模型并且可獲取的源碼有限。它的競爭對手在這方面有明顯的優(yōu)勢。
Fuse ESB類似于Mule ESB也是一個純粹的ESB，而不是套件。它基于集成環(huán)境中的事實標(biāo)準(zhǔn)如Apache CXF以及Apache Camel。這樣它一開始就擁有了強大的社區(qū)。它的開發(fā)環(huán)境是基于Eclipse的，并且非常直觀。
Fuse ESB是FuseSource的一部分。但是，F(xiàn)useSource最近被Red Hat收購了，現(xiàn)在它屬于JBoss部門。Fuse ESB包含在當(dāng)前的Roadmap之中并將會得到持續(xù)的支持。它將會集成到JBoss企業(yè)級SOA平臺（JBoss Enterprise SOA Platform）之中——就像它收購的BPM解決方案Polymita一樣。到形成統(tǒng)一的套件還有很長的路要走，因為集成FuseSource和Polymita依然需要幾個月的時間，并且JBoss ESB、Switchyard和Fuse ESB這三個ESB產(chǎn)品要合并為一個。在這方面，其他的廠商已經(jīng)獲得了更好的效果。
Talend ESB是Talend套件的一部分。Talend ESB可以獨立使用，也可以與Talend統(tǒng)一平臺的其他組件聯(lián)合使用。所有的組件都是開源的并且可以免費得到。企業(yè)級的版本提供了更多的功能和支持。與專有產(chǎn)品的不同之處在于，所有的組成組件都是基于相同的代碼基而且同一個工具可以用在各個地方。在不同領(lǐng)域如ESB、BPM、ETL、MDM，都可以很順暢地完成——它本身不是單獨的集成項目。
Talend套件的所有工具都是基于Eclipse的。使用Eclipse的類似“外觀和體驗”以及直觀性依然得到了保存。Talend為所有的產(chǎn)品提供了一個可視化的設(shè)計器，并使用“零編碼”（zero-coding）的方式。這樣就能高效地實現(xiàn)集成的場景。當(dāng)然，你依然可以編寫和集成自定義的邏輯到項目之中，例如通過Java類（POJO）或不同的腳本語言。
類似于Fuse ESB，Talend ESB也基于多個集成環(huán)境中的事實標(biāo)準(zhǔn)，如Apache Camel、Apache CXF、Apache Karaf以及Apache Zookeeper。除了能夠使用Apache Camel為JMS、HTTP以及FTP這些技術(shù)所提供的連接器以外，還有很多的B2B適配器是可用的，如為Alfresco、Jasper、SAP、Salesforce以及主機系統(tǒng)所提供的適配器。默認會包含所有的500個以上的連接器。這樣所造成的結(jié)果就是Talend的IDE比其競爭對手有更高的硬件需求。你不能在太差的筆記本上安裝Talend。另外一個不足是缺失SOA管理功能（SOA governance feature）。這計劃在下一版中進行添加。
相對來說，WSO2是一個不太知名的廠商。但是WSO2提供了完整的套件組件，包括業(yè)務(wù)流程服務(wù)器（Business Process Server）、業(yè)務(wù)規(guī)則服務(wù)器（Business Rules Server）、業(yè)務(wù)活動監(jiān)控（Business Activity Monitor）以及注冊表管理（Governance Registry）。完整的WSO2平臺可以很容易地進行安裝，它并且提供了輕量級的、基于Eclipse的開發(fā)studio。類似于Talend和FuseSource，WSO2也將主要的開源項目納為其組件，如Apache Synapse（輕量級ESB）、Axis（Web Service實現(xiàn)）以及ODE（業(yè)務(wù)流程引擎）。
除了Talend以外，WSO2是唯一一個所提供的套件基于單一代碼基和單一開發(fā)環(huán)境的廠商。因此，沒有什么會阻礙迭代式的開發(fā)過程，例如開始的時候只有幾個小的特性，然后一步步添加更多的功能。弱點在于圖形化的工具。它能夠支持平臺上的所有組件，但是不像其競爭對手的工具那樣直觀。
警告性的結(jié)論：如果聯(lián)合使用多個框架和產(chǎn)品來構(gòu)建自己的自定義集成套件，通常會遇到不必要的高昂成本并會遇到很多額外的陷阱。鑒于已經(jīng)有多種方案，所以強烈不建議通過各種拼湊來創(chuàng)建自己的方案。如果這樣做的話，需要編寫“粘合代碼”（glue code）、進行測試和缺陷修正，同時一旦遇到問題時，沒有明確的協(xié)議。供應(yīng)商通常會歸咎于另一方，例如，如果你想將ESB與其他廠商的BPM方案結(jié)合在一起，當(dāng)遇到問題的時候，你該找誰呢？所以，你為什么要去關(guān)注那些別人已經(jīng)關(guān)注過的問題呢，而且現(xiàn)在已經(jīng)可以獲取完整的產(chǎn)品棧（同時也有開源的）？
解決集成的問題方面并沒有銀彈。首先，必須要做出決策框架的功能是否足夠。要注意的是，使用框架大多數(shù)的源碼要自己編寫，同時工具和支持都很有限。否則的話，ESB就是更好的選擇。但是，如果稍后會用到套件中的額外功能，那么最好在開始的時候就使用集成套件中的ESB。這可以保證持續(xù)性，不會遇到聯(lián)合使用多個產(chǎn)品的問題和額外成本。
如果要使用ESB或集成套件，必要要決定專有產(chǎn)品還是開源產(chǎn)品更合適。專有的解決方案提供了所有可能的特性以及強大的支持。但是，這也會導(dǎo)致更高的成本和更高的復(fù)雜性。與此相對的是，開源解決方案會有更低的成本、便于使用且具備靈活性。一旦這個問題解決了，就可以創(chuàng)建一個候選列表來詳細地評估備選方案。強烈建議在做出最終決策前做出證明。確保你的團隊實現(xiàn)了原型（從第一次安裝到最終部署和監(jiān)控），而不是只聽從于廠商的顧問所言。將來你的團隊將會獨自安裝產(chǎn)品并解決集成的問題，此時可能并沒有可咨詢的顧問。
本文的英文原文有很多有價值的討論，建議讀者移步一觀。——譯者注
