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