InfoQ已發佈了Tijs Rademakers和Jos Dirksen所著新書《Open Source ESBs In Action》的樣章，藉此機會，我們對作者在現實項目中使用開源ESB的經驗進行了採訪。
InfoQ：鑑於開源ESB目前的狀態，您認爲能夠把它們看作是商業產品相當的替代品麼？
Tijs Rademakers (TJ)：我曾經有幸使用過商業產品（非開源）和開源ESB。在使用Mule ESB時我有一個驚人發現，即它讓企業集成和麪向服務這些個複雜工作變得容易。使用商業ESB就意味着，前期鉅額的許可費用，繁重的安裝過程，不得不學習新的IDE，必須從可用文檔和售後諮詢那裏學習。在你處理完這些前期成本後，著名的非開源ESB產品，諸如WebSphere，Tibco，Sonic 等，才能盡其所能。至於開源ESB，你一開始得把它先下載下來，10分鐘後，你就擁有了一個攜帶可用範例的ESB環境。接着，看一看範例的配置文件，你就能相當容易地實現你自己的集成解決方案。實現一項定製功能意味着：寫一個Java類和使用Mule ESB Java API。這對於Java開發人員是很容易理解的。而且要是你有什麼不知道的，還有活躍的大型社區可以讓你在郵件列表中進行提問。
Jos Dirksen (JD)：我認爲，從核心的ESB功能看，目前開源社區中的領先者當然能夠看作是商業產品相當的替代者。例如路由，轉換和連通性是開源ESB能夠替代或者比許多商業產品表現更好的方面。同時，在易用性方面，我認爲，開源ESB比許多商業產品表現的更好。
TJ: 有一點可能會令人驚訝，開源ESB的功能跟它的商業替代品非常類似。同時更驚人的是，由於簡單的配置機制和乾淨的API，集成解決方案的配置和開發顯得更加友好。商業產品通常會提供一個IDE，在其中你可以進行拖拽和單擊你的集成解決方案，順便說一句，這樣做很好，但是要實現那些不支持拖拽的功能可就要痛苦的多。所以，簡而言之，爲你的組織選擇ESB時，你真的應該考慮開源ESB。
InfoQ：您認爲ESB在SOA中充當了什麼樣的角色？它應該是中心，聯絡點或者活躍在邊緣地帶？
JD：視情況而定。通常，你會聽到每個SOA架構都應該在其核心有一個ESB，但是我其實認爲這不是必須的。如果你已經有一個現代化的（比如面向Web服務）架構，你就不需要引入ESB。在這樣的場景下，如果你引入一個註冊庫，就能創建一個非常好的、優雅的面向服務架構。要是你身處一個相當複雜的環境（比如，很多的遺留系統，.net和Java結合，大型主機），你可能就需要一個更加‘智能’的集成層，以面向服務的方式暴露這些應用。在這樣的場景下，我想，ESB就應該是SOA的中心點了。
TJ：有些人宣稱SOA已死，所以我當然不願意把ESB放在這個列表中。:-)在我看來，SOA跟僅僅用ESB集成遺留系統和提供服務相比是一個相當大的課題。SOA擁有業務視角和技術視角，而ESB主要還是技術相關的。因此，ESB是用來實現SOA的一個小的但很重要的部分。ESB是提供諸如路由，轉換，安全和協議轉換這些功能的重要組成部分，這些功能有助於服務彼此之間的通信，並實現（BPEL）流程跟服務的通信。
InfoQ：您認爲開源SOA解決方案最需要改進的地方是什麼，您遺漏了什麼重點嗎？
JD：我遺漏了什麼……有趣的問題。我個人認爲最大的遺漏就是一個真正好的集成解決方案。當我們用開源工具進行SOA項目時，我們通常不僅僅使用ESB，比如我們還需要一個BPM引擎。當前，儘管有所提升，但是BPM引擎，規則引擎和ESB之間的集成還不是很完美。因此，我們通常需要自己寫這些組件間的集成代碼。我認爲，這一點是需要極大提升的地方。
TJ：實際上，在開源SOA項目領域有很多活動。他們是ESB項目（Mule，ServiceMix，Synapse，Open ESB等），BPM項目（JBoss jBPM，Apache ODE，Open ESB BPEL組件等），服務註冊（Mule Galaxy，WSO2註冊等），業務規則引擎（Drools/JBoss Rules）。因此有很多好的現成SOA項目。但是，在我看來在這些組件的集成方面還有很大的提升空間。商業或者非開源SOA產品在這一點走在了前面，因爲他們提供了一套完整的SOA工具。但是缺點當然就是廠商鎖定嘍。
JD：在我看來，開源ESB需要提升的地方在於管理和圖形化的支持。當你看到商業的ESB時，它們的管理支持做得比較好，同時在支持工具領域也是如此，對於開發工具，開源ESB有很多地方需要改進。但是，我認爲後者對於高水平使用者不太重要，因爲他們對ESB的深入瞭解，使其不受限於那些圖形化工具。對於我個人，我希望看到一個好的集成解決方案，提供BPM，業務規則和好的服務存儲庫。
InfoQ：您能分享一些來自案例的非功能的統計數據麼？
TJ：好尖銳問題！非功能性統計數據通常很難界定，在ESB環境下，當然也差不多。 但是我們完成了一個工程，在Mule ESB上用JORM作爲消息引擎每秒處理多條消息。
JD：目前，我正在從事的項目是處理城市住戶和地方當局之間的互動。這是一個基於Mule的系統，其中有800,000名市民籍由一個.net前臺跟一系列後臺服務打交道。服務間的交互是基於Mule的。Mule也把一系列舊的後臺應用暴露成Web服務。
InfoQ：您認爲，對於MuleESB和ServiceMix，它們各自的優缺點是什麼？在使用時有何建議？
JD：二者都有優缺點。我喜歡ServiceMix的模型，它讓熱部署新的集成流程變得容易，並且事實上它是基於標準的。儘管JBI標準沒有獲得太多的青睞，但它是一個相當不錯的規範，當你理解JBI時，它會讓你對ServiceMix很容易上手。我很喜歡有可熱插拔的集成組件，特別是它們是可以熱部署的。包含 Camel也是ServiceMix的一個亮點。我真的喜歡可以用DSL去開發集成流程。ServiceMix的不足之處跟它的優點是有關聯的。JBI規範確實引入了另一個困難級別，對XML的關注並不見得總是適合你在集成領域中遇到的需求。另一方面，Mule讓集成流程的創建變得容易和簡單。它有非常廣泛的路由器，易於擴展，並有很多可選的開箱即用的連通性、路由和轉換。使用Mule，使你能夠在數分鐘內讓相當複雜的集成流程啓動並運轉起來。然而，Mule也有缺點。儘管不是很大，但是對我個人而言，它的一個最大的缺點就是沒法熱部署新的集成流程。如果Mule集成OSGi或者其他方法，就能很容易的更新集成流程，這將是一個大大的加分點。
TJ：當前，ServiceMix被分成了兩個項目，ServiceMix 3.2.x/3.3.x和ServiceMix 4。我們書中使用ServiceMix 3.2.x（基於JBI），但我們對ServiceMix 4（基於OSGi，支持JBI）也有一個簡短的介紹。因此，ServiceMix和Mule ESB之間的主要不同點就是，ServiceMix是基於JBI，而Mule ESB實現了基於Java的定製模型。但是這些ESB間還有很多共同點（支持Spring，通過CXF支持Web服務，XML配置）。但是，讓我們着重談談不同點。
Mule ESB是一個以Java爲中心的ESB，這讓Java開發者能很容易地上手。它擁有強大的XML模式集合，它們創建了一個真正清潔可讀的XML配置並提供了代碼補全支持。當你想實現一項轉換邏輯或者路由邏輯時，你能夠很輕易地開發出一個簡單的Java類/Spring bean/腳本文件，把它引入到XML配置中。如果必須要指出Mule的一個不足之處，那就是缺乏對於熱部署的支持。
ServiceMix是一個以JBI爲中心的ESB，它提供了大量的JBI組件，比如JMS，Web服務，Camel以及BPEL組件。當然，你也可以使用來自其它基於JBI的ESB的JBI組件，諸如PEtALS和我們書中介紹的Open ESB。ServiceMix爲每個JBI組件都提供了一個簡易的XML配置語言，爲部署你的集成解決方案提供了熱部署功能。ServiceMix的一個缺點是進入JBI的學習曲線。因此，問題實際就是：在Mule和ServiceMix之間，你更願意選擇哪一個？。ServiceMix提供了JBI支持，BPEL集成，關注XML消息和熱部署功能。Mule提供了以Java爲中心的模型，支持jBPM，支持消息無關，沒有熱部署功能。
JD：選擇使用哪一個，其實取決於你的需求。當你面臨的是關注XML標準的集成場景時，ServiceMix就是個不錯的選擇。如果你需要低級別的集成，Mule可能是個好的選擇。這兩個ESB都是不錯的開源集成解決方案，對於大多數集成問題都能很好地解決。
InfoQ：爲什麼你們最終選擇了ServiceMix和Mule，而不是其他選擇？對Apache Synapse或者Spring集成（Spring Integration）有何建議？
TJ：ServiceMix和Mule是活躍社區中成熟開源ESB的絕佳範例，它們代表了基於JBI的ESB和以Java爲中心的ESB的方法。我們還會考慮其他替代方法，Apache Synapse就是最主要的替代者。順便說一句，在本書中，我們已經包含了Apache Synapse以及Spring集成的例子。Apache Synapse是面向Web服務的ESB的典範，它是基於Apache Axis2的。當你一門心思想要獲得WS-*支持和Rest支持時，Synapse顯然是一個你需要考慮的ESB。我發現Spring集成是個不錯的框架，可以跟Apache Camel相媲美。它們都對Hohpe和Woolf描述的企業集成模式提供了支持，這樣無需單獨的集成容器，你就能很輕易地將你的Java應用程序集成進來。因此，在不需要引入中心ESB容器，在應用程序級別實現集成功能情況下，這些框架非常有用。
JD：我個人沒有過多接觸Spring集成，爲了體驗它，我們正在用它做一個很小的項目。目前爲止，我們對它印象還不錯。它是相當輕量級的解決方案，可以輕易地與我們編寫的其餘Spring應用程序相結合。在我們開始寫這本書時，開源ESB社區還不如現在成熟，而且現在有了更成熟的解決方案。
TJ：一定要關注開源ESB社區，這裏有許多活動和項目以及活躍的社區可供選擇！
InfoQ：非常感謝！
