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