企業級服務總線的定義
來自不同廠商的大量產品都包含了“企業服務總線”名稱。不幸地是，這個詞彙並沒有一個標準的定義。產品因此也提供許多不同的特性。在ESB被使用之前首先應該有個清晰的定義。在下面的內容中，ESB是被定義爲一種協助開發者的應用集成軟件產品，並且提供必要的基礎設施去實現路由，轉譯和一些其他的集成工具。在集成的複雜路徑，ESB通常介於框架和套件作爲應用集成的替代，正如以下圖片所示：
圖片1：替代應用集成
在ESB被定義之後，下一節解釋什麼時候ESB應該被考慮，並且什麼時候集成框架或者集成套件是一個更好的選擇
集成架構
集成架構以標準化的方式集成應用，提供了各種企業集成模式（EIP，Enterprise Integration Patterns）的具體實現，如分離器、基於內容的路由等等。使用標準API來集成產品在顯著地降低實施成本的同時，也能夠使代碼清晰易懂。集成架構十分適合於集成使用不同技術開發、通過各種不同協議進行交互的各類應用，並且能很好地支持用於描述集成邏輯的各類概念，如端點、生產者、消費者和各類企業集成模式等等，這些概念也間接的支持了測試自動化。集成架構包含一系列通用的類庫，可適應各類開發環境，即使最普通的文本編輯器也行。
知名的集成架構包括Java方面的 Apache Camel和 Spring Integration，以及.Net方面的 NServiceBus。
使用這些集成架構後，研發團隊將多多少少地爲項目的成敗擔負起更重大的責任，一般這些集成架構沒有相應的商業支持，工具支持也不夠完備，尤其對於關鍵的部署工作更是缺乏支持。本文接下來的部分將用於介紹ESB和相關的套件，那將是比集成架構更好的選擇。
企業服務總線
就像一個框架一樣，ESB用於集成應用程序。ESB是基於某一框架的隱式實現。然而，它是一種更爲強大的產品。與框架相比，除了最基本的框架功能之外，ESB爲應用程序在發佈，管理和在運行時的監控提供了強壯的工具支持。另外，對於各類集成場景的實現提供了圖形化編輯。集成邏輯能以“拖放”的方式建模，對應的源代碼會自動生成。商業對ESB完全支持。
ESB相比於純框架的最大優勢在於有最好的工具，這些工具將大大降低成本和複雜度。集成問題在一個高度的抽象水平得以解決。
集成套件
套件會提供ESB所有的功能特性，除此之外，還會提供許多另外的功能如業務流程管理（BPM）、業務活動監控（BAM）、主數據管理（MDM）等等，還可以包含一個服務註冊庫。如果在純粹的集成需求外還需要此類功能特性，集成套件將會很有用處。使用簡單的軟件棧可以使得整個集成過程清晰明瞭。
希望現在已經搞清楚集成架構、ESB和集成套件直接的區別了，接下來將介紹如何正確選擇ESB或集成套件。
評估標準
注意，我們並不提供一個評估表並要求所有產品都符合上面列出的各種標準。就筆者的觀點，這些產品提供的功能和包含的概念數量衆多，之間的差異也同樣多，因此幾乎不可能提供出一個有效的評估表。還有，在當今的IT界，這些功能列表幾乎天天在變。
因此，建議先預先定義好你的需求，然後再來評估哪些產品是最合適的。定製化的解決方案一般都很類似，而最常用的開源軟件替代方案也都提供類似的特性。所以，合理的做法是在開始就確定好是使用定製化方案還是採用開源方案。
爲做出最終選擇，你可以參考以下評估標準：
- 易用性：安裝過程是否複雜？需要使用多少工具軟件？開發環境是否直觀？
- 可維護性：系統管理員將如何管理產品的運行？監控服務是否有圖形化界面？
- 社區支持：產品是否有活躍的公共論壇或郵件組？是否有足夠數量的文檔、教程或視頻？是否有多家公司提供售後服務？
- 商業支持：能提供哪些選擇（響應時間，7×24在線支持、郵件支持或現場支持？）所需的服務水平如何得到保障？是否能提供你首選語言的支持
- 功能：所需要的功能都能滿足麼？
- 靈活性：是否能定製產品功能以符合實際需求？
- 可擴展性：產品如何進行擴展？其接口是否符合標準協議？
- 連通性：各類交換技術對應的適配器是否都具備？是否有針對B2B產品的適配器，如SAP或Salesforce？創建自己的適配器是否方便？
- 成本：使用該產品的總體成本是多少？需包含維護、所需的配套產品、連接器等等
- 許可：採用何種許可和付費模式？如果發生變化時如何處置（如增加服務器、增加CPU或遷移到虛擬機運行等等）？免費升級麼？是否可降級？價格表包含所有可預計成本了麼，甚至說價格表清晰可懂麼？
下表對比了商業的和開源的ESB產品及套件的長處和不足。總體來說商業產品和開源產品之間的差異在於：商業產品提供更多的功能和“強有力”的售後支持。然而，問題是“這些真的是必須的麼？”必須記住的是所需的付出、系統的複雜性以及費用都會相應變得更高。開源產品在易用性、靈活性、擴展性和費用方面都更有競爭力。
|
標準 |
商業產品 |
開源產品 |
|
易用性 |
安裝過程相當複雜(需要廠商的顧問來安裝!?)，"工具的地域" |
一鍵安裝 (有時在Mac上也能實現)，安裝後幾分鐘即可使用，統一的操作平臺 |
|
運維和監控 |
強大的工具支持（如運行管理和監控），無需關心源碼，可通過圖形界面進行定製 |
工具支持較弱（如運行管理、監控、和其他廠商的產品進行集成），無需關心源碼，可通過圖形界面進行定製 |
|
社區支持 |
購買服務，有論壇（但不是能獲得幫助的真正的社區）
|
開源項目有對應社區，同時產品也有自身的社區 |
|
商業支持 |
7×24商業支持，SLA任你選擇， 無數的服務商 |
7×24商業支持，但選擇面更小，需要去尋找本地的顧問和支持 |
|
功能性 |
集成功能再加上很多其他的功能（BAM, CEP, EDA,等等等等等） |
集成功能在加上少許其他功能 |
|
靈活性 |
提交變更申請、再等上很久、然後等來一個付款要求，或者，付上一大筆錢、然後馬上就給你搞定 |
開源、想做啥都行 |
|
擴展性 |
自己做（很難很難）或付錢購買服務 |
擴展基於標準，或事實標準 |
|
連通性 |
提供各類技術和商業產品的連接適配器 |
提供各類技術和商業產品的連接適配器 |
|
費用 |
高（十分高） |
較少 |
|
許可 |
複雜的價格條款，什麼東西都要付費（升級、遷移到虛擬機、隨便其他什麼。。。） |
訂閱付費模式、可免費升級、成本可預見、可降級 |
候選產品
解釋完商業產品和開源產品之間的主要差異，接下來將特別介紹幾個產品，將分別對這些候選產品做一個概覽，包括少許實用性方面的意見。
幾乎所有的商業集成產品廠商，如IBM和Oracle，提供的解決方案都包含應有盡有的功能。在開源軟件方面，特別值得一提的是拓藍統一平臺和WSO2平臺，因爲這兩家開源廠商同樣提供完整的套件。此外，還有一些僅提供ESB產品，其中最終於的莫過於Mule ESB和Fuse ESB。
Oracle Service Bus / Fusion Middleware
Oracle Service Bus是Oracle目前的ESB產品，它是Oracle Fusion中間件系列（就是本文定義的套件）的一個組成部分，Fusion中間件套件還包含很多其他產品，例如，SOA套件、Coherence（分佈式緩存）、CEP（複雜事件處理）、BPEL過程管理、企業消息服務（MQ）、服務註冊管理等等。
幾乎沒什麼功能是Oracle的套件無法提供的，各類工具都很強大而穩定，絕大多數產品都有圖形化的編輯界面，各種可想像到的商業服務等級應有盡有。如果這些都是你真正需要的，那麼選擇Oracle絕對沒錯。但這些強大的套件代價不菲，並且也不要低估這些產品帶來的複雜性，此外，你還必須注意不那麼透明的定價模式下高級許可和支持的花費。
OFM基於Java EE、BPEL、SOAP和SCA等標準，這些產品是Oracle自行開發或不斷收購來的，因此，這些產品也基於不同的代碼庫，並且往往需要使用不同的開發工具。下載這些產品和工具的總量會很快會超過20G。安裝過程相當繁瑣，往往要搞上幾天，哪怕你只是將在你的筆記本上簡單裝下也是如此。這些產品都相當重，運行會需要相當高的資源配置。
順便說下，你只要把Oracle替換成IBM、把Fusion中間件替換成WebSphere，以上一切仍然成立，僅有的區別是IBM官方提供3個ESB產品：Message Broker、WebSphere ESB和DataPower SOA設備（一個盒子）。同樣，Tibco、微軟和SAP在商業ESB和集成套件市場上也扮演着重要的角色。
總的來說，商業集成套件能夠提供應有盡有的功能和服務等級，然而，很多功能和服務等級在多數項目裏並用不上。在此種情況下，有必要評估下開源產品，接下來將介紹幾個最重要的產品。
Mule ESB
Mule ESB是第一個成功地開源ESB。它與之前提及到的開源ESB產品有很多共同的特性。包括非常簡單的一鍵安裝("one click")和直觀的基於Eclipse的工具。通常，開源ESB是非常輕量級的和可擴展的解決方案。除了免費的開源版本和紫外，商業的企業版本是可獲得的。這將就對產品提供了額外的功能和支持。
對於這些仍然不清楚的，應該知道“開源”並不意味着“免費”。即使是開原供應商也必須賺錢，免費的話將無法開發產品和提供支持。然而，對於客戶的價格是非常優惠的，也沒有像私有產品供應商那樣，建立在一張模糊的價格單上。雖然開源產品版本能在沒有授權成本的情況下使用(即使在產品中)。然而，時常開源版本只用於做實驗或做一個概念證明，以後升級到企業版額外的功能和支持。
作爲相同的建議，Mule ESB是純ESB。相對於像Apache Camel或Spring 集成框架，對於集成場景提供了優秀的圖形化編輯實現，如SAP或Salesforce的B2B產品提供可用的連接。然而，套件的功能在Mule ESB中卻丟失了。對於這種情況，ESB必須和其他供應商的產品相結合。Mule ESB的短板是開發社區小，嚴格的licensing 模型和悠閒的源代碼。在這一點，其競爭對手有明顯的優勢。
Fuse ESB
Fuse ESB就像Mule ESB一樣，是沒有套件的純ESB。它是基於如 Apache CXF和Apache Camel這樣的集成環境中的實際的標準。因此，一個偉大的社區，由此從小到大的建立起來。開發環境是基於Eclipse，並且非常直觀。
Fuse ESB是FuseSource的一部分。然而，FuseSource最近被Red Hat收購，屬於JBoss的一部分了。 Fuse ESB當前被列在路線圖中，並會繼續得到支持。它將會被集成到JBoss企業版SOA平臺-就像還收購了BPM解決方案Polymita。要成爲一套統一的套件還有很長的路要走，因此 FuseSource和Polymita的集成還需要一段時間，JBoss ESB, Switchyard 和Fuse ESB等現在又三種ESB產品需要合併到一起。到這裏，其餘的開源供應商已經得到最好的結果。Talend ESB/統一平臺
Talend ESB是Talend套件的一部分。Talend ESB可以被獨立使用，或者與Talend統一平臺的其他組件組合使用。所有組件均免費且開源。其企業版提供額外的功能和技術支持。與之前提到的產品不同的是，Talend所有的組件都基於相同的基礎代碼之上開發，使用相同的工具。 因而可以有機地結合成爲一個整體項目，無縫地應用到不同領域，如ESB，BPM，ETL，MDM等。
Talend套件的所有工具都基於Eclipse構建，並保留了Eclipse中熟悉的外觀和使用習慣。Talend使用“零編碼”方式，爲所有的產品部件提供了可視化設計器。 從而在各種集成場景中可以更有效地進行實現。當然，你依然可以自己編寫業務邏輯代碼來自定義地集成你的項目，比如通過Java(POJOs)或者其他的腳本語言。
像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對硬件有更高的要求，不應該安裝到一臺性能不太強的筆記本上。另外一個不足就是缺少了SOA治理功能。這一功能會在以後的發佈版本中添加。
WSO2 ESB / Platform
WSO2是一個相對陌生的供應商。然而，WSO2提供了一套組件所包括的整個範圍，包括Business Process Server，Business Rules Server, Business Activity Monitor或者Governance Registry。完整地WSO2平臺非常容易安裝，提供了一個輕量級的，基於Eclipse的開發工具。像Talend和FuseSource，WSO2同樣將一些開源項目，如Apache Synapse（輕量級ESB），Axis（Web服務實現）或者 ODE（業務處理引擎）加入到它的組件中。
除了Talend之外，WSO2是唯一一個供應商，提供了一組完整套件，該套件基於單一代碼和單一開發環境。因此，在迭代開發過程中沒有什麼表示，剛開始一個小功能，後來一步步的增加更多的功能。它的弱點是圖形化工具不足。它支持平臺的所有組件，但它在使用上，沒有它的競爭對手錶現的那樣直觀。
DIY自己的集成套件？
嚴重警告不要自行用集成框架和產品來構建自己的集成套件，這往往代價高昂，並會遇到數不盡的坑。既然已有成熟的解決方案，我們不建議自己在創建一個。你會需要寫很多膠水代碼來組合這些產品，需要測試並修復缺陷，在遇到問題時也找不到幫助。比如你想把不同廠商的ESB和BPM產品整合在一起，那出問題的時候你去找那個廠商獲取支持呢？產品廠商往往會說是其他廠商的產品有問題。因此，既然已經有人仔細的考慮過如何將框架和產品集成爲套件之類的問題，並且提供出了完整的解決方案（也包括開源的），你爲何還要自己再去研究一般同樣的問題呢？
總結
沒有解決集成問題的銀彈。
首先，需要評估下是否集成框架就足夠解決問題了。需要注意的是選擇了集成框架，大部分代碼都要自己寫了，工具和支持也都是沒有的。如果不是，那麼ESB就是更好的選擇。而且，如果後續將使用某個套件中的產品，那麼最好一開始就使用這個套件中的ESB產品。這可以保證在組合這些產品時避免發生問題或產生費用。
如果要使用ESB或集成套件，那邊必須考慮是用商業產品還是開源產品。商業解決方案可提供所有可能的功能特性，並有強大的售後支持，然而同時也會帶來更高的開銷，同時也會導致系統的高複雜性。與之相對的是，開源產品一般花費較小，同時更加易用和靈活。一旦確定後就可以列出一個備選列表並進行細節方面的評估。強烈建議在確定最終方案前做個POC，並確保是由你的團隊而不是廠商的顧問來實現原型，因爲你的團隊將來需要在廠商顧問無法到位的情況下獨自安裝產品和解決問題。
