李珉, 高級(jí)軟件工程師，技術(shù)經(jīng)理, IBM 中國軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心

2005 年 8 月 01 日

本文作為ESB系列文章的第一篇，介紹了面向服務(wù)的體系結(jié)構(gòu)(service-oriented architecture，SOA)和企業(yè)服務(wù)總線(Enterprise Service Bus，ESB)的基本知識(shí)，ESB的技術(shù)沿革，以及ESB與SOA之間的關(guān)系。

引言

"一切都在流動(dòng)，沒有什么是持久的。一切都在融化，沒有什么是固定不變的" - 赫拉克利特(Heracleitus)

大約在2003年中的時(shí)候，SOA的概念逐漸進(jìn)入人們的視野，一時(shí)間眾人樂此不疲的發(fā)表各自對(duì)SOA的見解。SOA已經(jīng)成為IT業(yè)，尤其是軟件開發(fā)及系統(tǒng)集成領(lǐng)域從業(yè)者的熱門話題。很多的權(quán)威機(jī)構(gòu)也紛紛預(yù)測SOA的美妙前景，例如，Gartner 預(yù)言，到了 2008 年，至少 60% 的企業(yè)將使用 SOA 作為其IT架構(gòu)。拋開喧囂躁動(dòng)以及隨聲附和，對(duì)于軟件開發(fā)者而言，經(jīng)過了一年多的概念灌輸，伴隨著不斷增長的困惑，更多的人希望能靜下心來看一看：究竟怎樣的系統(tǒng)架構(gòu)是符合SOA設(shè)計(jì)的，而又有哪些技術(shù)可以用來實(shí)現(xiàn)SOA呢？特別是企業(yè)服務(wù)總線(Enterprise Service Bus, ESB)， 看起來更是SOA中一個(gè)玄虛的概念，本系列文章將通過實(shí)際的案例分析來詳細(xì)講解在SOA系統(tǒng)中是怎樣實(shí)施ESB的。

本系列文章將直接面向廣大的軟件開發(fā)人員， 首先以直觀的方式介紹什么是ESB， 然后引入一個(gè)實(shí)際案例，以此為基礎(chǔ)，詳細(xì)介紹怎樣一步一步實(shí)現(xiàn)ESB。現(xiàn)在我們談?wù)揝OA和ESB的時(shí)候都不再是空中樓閣，IBM作為SOA的倡導(dǎo)者，已經(jīng)提供了很好的產(chǎn)品來實(shí)現(xiàn)我們的設(shè)想。我們會(huì)在本系列中的第二、第三部分中分別介紹基于WebSphere 6 和IBM EAI產(chǎn)品的兩種實(shí)現(xiàn)方式， 然后在第四部分中介紹在復(fù)雜的企業(yè)應(yīng)用場景中總線(Bus)怎樣互聯(lián)， 怎樣擴(kuò)展。希望通過本系列文章，能讓廣大讀者朋友快速掌握ESB的實(shí)際開發(fā)技巧。

關(guān)于SOA

關(guān)于SOA的概念，你可以找到很多的文章從不同的角度來描述它，不同的軟件提供商也有不同的定義方式。BEA有流體計(jì)算，微軟有Indigo 和SOA-building， SAP有ESA。 每個(gè)人都可以從不同的視角來理解SOA，從程序員的角度，SOA是一種全新的開發(fā)技術(shù)，新的組件模型，比如說Web Service；從架構(gòu)設(shè)計(jì)師的角度，SOA就是一種新的設(shè)計(jì)模式，方法學(xué)；從業(yè)務(wù)分析人員的角度，SOA就是基于標(biāo)準(zhǔn)的業(yè)務(wù)應(yīng)用服務(wù)。從概念的角度，IBM對(duì)SOA的定義是最為全面的，既SOA是一種構(gòu)造分布式系統(tǒng)的方法，它將業(yè)務(wù)應(yīng)用功能以服務(wù)的形式提供給最終用戶應(yīng)用或其他服務(wù)。SOA包括如下要素:

• 一個(gè)體系架構(gòu)，用開放的標(biāo)準(zhǔn)將軟件資產(chǎn)(Asset)化為服務(wù)
• 提供標(biāo)準(zhǔn)的方法來表示軟件資產(chǎn)及其交互
• 單獨(dú)的軟件資產(chǎn)作為構(gòu)造單元，被重復(fù)使用來開發(fā)其他應(yīng)用
• 將關(guān)注點(diǎn)從細(xì)節(jié)實(shí)現(xiàn)轉(zhuǎn)移到應(yīng)用(application)組裝
• 整合企業(yè)外部的應(yīng)用（B2B）的方式
• 開發(fā)（現(xiàn)在）和整合（未來）的統(tǒng)一

本文針對(duì)的讀者是軟件開發(fā)人員，站在開發(fā)人員的角度，往往希望軟件開發(fā)能夠滿足對(duì)于開發(fā)效率、可靠性、易維護(hù)性、易管理等多方面的更高要求。讓我們通過回顧軟件開發(fā)的演化過程來看一看SOA出現(xiàn)的必然性：

• 面向機(jī)器語言(Monolithic)的開發(fā)模式：需要根據(jù)不同平臺(tái)的機(jī)器語言來開發(fā)代碼。
• 面向過程(Procedure)的開發(fā)模式：獨(dú)立于機(jī)器的程序語言(C, Pascal等)使開發(fā)過程變得簡單了，用過程來代表一個(gè)抽象的代碼集合，包裝重用現(xiàn)成的代碼。
• 面向?qū)ο?Object)的開發(fā)模式：用更接近現(xiàn)實(shí)的對(duì)象來表述一個(gè)相對(duì)完整的事物。面向?qū)ο蟮恼Z言(Smalltalk，Java等)，提供了更抽象的封裝和重用模式。面向?qū)ο蟮拈_發(fā)強(qiáng)調(diào)從現(xiàn)實(shí)世界問題域到軟件程序的直接映射，更接近人類的自然思維方式。
• 面向組件(Component)的模式：隨著軟件開發(fā)規(guī)模的擴(kuò)大，在涉及分布式、異構(gòu)等復(fù)雜特征的環(huán)境中，代碼級(jí)別的重用性差，可維護(hù)性差，效率低的弱點(diǎn)是不可逾越的，因此人們以架構(gòu)運(yùn)行環(huán)境(如.Net，J2ee等)來提供完善的支撐平臺(tái)，從而把開發(fā)者解放出來，更專注于業(yè)務(wù)核心的開發(fā)。而這些業(yè)務(wù)功能(Business Function) 以組件的形式(DCOM， EJB等)發(fā)布運(yùn)行在架構(gòu)運(yùn)行環(huán)境中。軟件開發(fā)的重用模式也上升到業(yè)務(wù)組件的級(jí)別。
• 面向服務(wù)(SOA)的模式：當(dāng)軟件的使用范圍擴(kuò)展到更廣闊的范圍，往往會(huì)面對(duì)更加復(fù)雜的IT環(huán)境和更加靈活多變的需求。服務(wù)(Service)的概念出現(xiàn)了，人們將應(yīng)用(Application)以業(yè)務(wù)服務(wù)(Business Service)的形式公布出來供別人使用，而完全不需要去考慮這些業(yè)務(wù)服務(wù)運(yùn)行在哪一個(gè)架構(gòu)體系上，因?yàn)樗械姆?wù)都講著同樣的語言。SOA考慮了業(yè)務(wù)發(fā)展的長期性，體現(xiàn)了"變化就是永恒"的思想。SOA的核心體現(xiàn)在企業(yè)應(yīng)用或者業(yè)務(wù)功能上的"重用"和"互操作"，而不再把IT與業(yè)務(wù)對(duì)立起來，這可以被視為在IT驅(qū)動(dòng)業(yè)務(wù)的方向上邁出的重要一步。

我們注意到，SOA同樣也強(qiáng)調(diào)重用(Reuse)， 但是相對(duì)于傳統(tǒng)的代碼重用，對(duì)象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在于業(yè)務(wù)級(jí)的應(yīng)用，即服務(wù)的重用，這與軟件的發(fā)展規(guī)律是相一致的。在軟件發(fā)展的過程中，軟件重用的對(duì)象越來越接近我們的現(xiàn)實(shí)生活。通過部件的重用，軟件的開發(fā)更具效率，并且開始試圖用組件表達(dá)業(yè)務(wù)模式。但是，IT人員仍很難對(duì)業(yè)務(wù)人員解釋清楚IT結(jié)構(gòu)怎樣映射到業(yè)務(wù)模型上。然而，IT架構(gòu)與業(yè)務(wù)模型的彌合是不可避免的方向?，F(xiàn)代企業(yè)的業(yè)務(wù)環(huán)境所面臨的最大挑戰(zhàn)就是變化，規(guī)則在變，需求在變，而對(duì)變化做出最快的反應(yīng)，盡快地適應(yīng)變化，成為企業(yè)占得先機(jī)，成功運(yùn)作的關(guān)鍵。很多企業(yè)的業(yè)務(wù)環(huán)境依賴于他們的IT架構(gòu)，因此，IT部門往往直接承載了業(yè)務(wù)變化帶來的壓力。每一個(gè)具體的業(yè)務(wù)變化，都直接反應(yīng)到對(duì)現(xiàn)有的IT平臺(tái)的要求：要么企業(yè)IT架構(gòu)本身對(duì)變化自適應(yīng)，要么IT架構(gòu)能夠在短時(shí)間內(nèi)根據(jù)新的業(yè)務(wù)規(guī)則做出調(diào)整。這就是SOA架構(gòu)提出的根本原因，我們需要一種更加貼近業(yè)務(wù)的IT架構(gòu)，能夠直接描繪業(yè)務(wù)，對(duì)那些不懂IT技術(shù)的業(yè)務(wù)領(lǐng)域?qū)＜襾碚f，業(yè)務(wù)服務(wù)卻是他們最熟悉的，也就是說是SOA把軟件重用的對(duì)象從IT人員上升到了業(yè)務(wù)人員。因此，我們可以說SOA與其它的模式相比，最大的進(jìn)步在于它與業(yè)務(wù)的關(guān)聯(lián)性，"服務(wù)"對(duì)應(yīng)到實(shí)際業(yè)務(wù)。IT通過"服務(wù)"與業(yè)務(wù)發(fā)生了密切的關(guān)系，業(yè)務(wù)人員和IT人員都可以專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，而共同的語言就是"服務(wù)"。

但不是什么場合都適用SOA。通常來講，SOA適用于較為復(fù)雜的IT架構(gòu)，經(jīng)常需要與外部復(fù)雜的IT環(huán)境交互，并且需要快速地應(yīng)對(duì)頻繁發(fā)生的業(yè)務(wù)變化。就像你不可能在控制洗衣機(jī)的芯片上使用EJB開發(fā)一樣，如果你的IT環(huán)境規(guī)模很小，足以靈活地應(yīng)對(duì)變化，不需要與其他的異構(gòu)IT環(huán)境頻繁交互，那么SOA帶來的好處就不足以抵消它給你帶來的系統(tǒng)復(fù)雜性。但是，即令如此，你也并沒有被完全排除在SOA的大趨勢之外。SOA是如此地倍受矚目，我們可以預(yù)見到它的迅猛發(fā)展，因此即使你的內(nèi)部IT架構(gòu)本身并不是基于SOA的，你也還有機(jī)會(huì)參與到未來的SOA架構(gòu)中去。例如，將你的某個(gè)業(yè)務(wù)以服務(wù)的形式發(fā)布到某個(gè)外部SOA平臺(tái)上供別人使用，作為第三方SOA平臺(tái)的一個(gè)服務(wù)提供者(Service Provider)存在。

在選擇SOA的實(shí)施方案時(shí)，要記住，軟件的具體實(shí)現(xiàn)技術(shù)諸如Web 服務(wù)與SOA是兩回事，SOA是一個(gè)概念，方法學(xué)， 或者用一個(gè)更時(shí)髦的詞：一種模型。而Web 服務(wù)呢？它是一種具體的實(shí)現(xiàn)技術(shù)，就像EJB一樣。SOA ≠ Web服務(wù)。不過公平地講，Web 服務(wù)倒確實(shí)是目前最適合實(shí)現(xiàn)SOA的技術(shù)之一，用Web 服務(wù)來封裝業(yè)務(wù)服務(wù)是個(gè)不錯(cuò)的選擇。因?yàn)閃eb服務(wù)是標(biāo)準(zhǔn)的，WS-I協(xié)議保證了來自不同廠商的Web服務(wù)即使運(yùn)行在不同的平臺(tái)上，底層的實(shí)現(xiàn)機(jī)理不同也可以順利交互，這是以前的任何一種技術(shù)如CORBA，EJB，或DCOM都不能做到的。而且，Web服務(wù)的定義與實(shí)現(xiàn)是分開描述的，即松散耦合，因此，可以很方便地替換服務(wù)的內(nèi)在實(shí)現(xiàn)而不會(huì)對(duì)現(xiàn)有的系統(tǒng)造成任何沖擊，這也極大地促進(jìn)了IT架構(gòu)的靈活性。

對(duì)于SOA更進(jìn)一步的了解，可以參考IBM developerWorks上其他SOA相關(guān)的文章(請參見參考資料)，我們的系列文章將主要討論ESB，因此不再此過多地論述SOA了。為了使我們下面的論述更順暢，請先牢記典型的SOA架構(gòu)有哪些基本的要求：

1. SOA在相對(duì)較粗的粒度上對(duì)應(yīng)用服務(wù)或業(yè)務(wù)模塊進(jìn)行封裝與重用；
2. 服務(wù)間保持松散耦合，基于開放的標(biāo)準(zhǔn)， 服務(wù)的接口描述與具體實(shí)現(xiàn)無關(guān)；
3. 靈活的架構(gòu) -服務(wù)的實(shí)現(xiàn)細(xì)節(jié)，服務(wù)的位置乃至服務(wù)請求的底層協(xié)議都應(yīng)該透明；

ESB

讓我們暫時(shí)回到網(wǎng)絡(luò)技術(shù)不普及的時(shí)代，你怎樣在兩臺(tái)機(jī)器之間傳遞文件？我還記得為了給實(shí)驗(yàn)室的每臺(tái)機(jī)器安裝Borland C++的環(huán)境，猜猜我動(dòng)用了什么：一根"串口線"。不過，我仍然覺得慶幸，好在每臺(tái)機(jī)器都運(yùn)行同樣的操作系統(tǒng)- DOS(很少有人還記得DOS中有Interlnk這樣一個(gè)命令吧)， 用來通過串口線在兩臺(tái)機(jī)器間傳遞流文件。否則我將不得不用軟盤來拷貝所有的安裝文件。我那個(gè)時(shí)候的夢想就是，哪一天有這么一個(gè)叫做"網(wǎng)絡(luò)"的東西能夠把實(shí)驗(yàn)室里面所有機(jī)器都連接起來，而不用我在各機(jī)器之間跑來跑去。

讓我們回歸主題，你現(xiàn)在已經(jīng)基本明白了什么是SOA。假定你已經(jīng)按照SOA的思想提煉出了各種業(yè)務(wù)服務(wù)，公布出來，同樣，你發(fā)現(xiàn)其他很多人也做了同樣的事情。大家都很振奮，開始踴躍的嘗試，我調(diào)用你的一個(gè)服務(wù)，你調(diào)我的一個(gè)服務(wù)。啊哈！大家都SOA了。且慢，那么這個(gè)SOA給你們帶來了什么好處呢？Ok，現(xiàn)在我可以在J2EE環(huán)境里調(diào)用.Net的組件了，但是原來沒有SOA的時(shí)候也可以做到的呀。只要兩個(gè)節(jié)點(diǎn)之間互相認(rèn)可對(duì)方的方式，即使不存在公開/統(tǒng)一的服務(wù)界面也可以實(shí)現(xiàn)點(diǎn)到點(diǎn)的互聯(lián)。因此我們不得不承認(rèn)，如果我們只有服務(wù)，而服務(wù)的請求者和服務(wù)的提供者之間仍然需要這種顯式的點(diǎn)到點(diǎn)的調(diào)用，那么這就不是一個(gè)典型的SOA架構(gòu)。請看圖二，服務(wù)的參與雙方都必須建立1對(duì)1 的聯(lián)系。這樣一個(gè)結(jié)構(gòu)與我十幾年前的那種互聯(lián)的方式何其相似！但是，還記得我們上面提到的SOA三個(gè)基本要素嗎？顯然第三點(diǎn)沒有做到。

因此，在SOA中，我們還需要這樣一個(gè)中間層，能夠幫助實(shí)現(xiàn)在SOA架構(gòu)中不同服務(wù)之間的智能化管理。最容易想到的是這樣一個(gè)HUB-Spoke結(jié)構(gòu)，在SOA架構(gòu)中的各服務(wù)之間設(shè)置一個(gè)類似于Hub的中間件，由它充當(dāng)整個(gè)SOA架構(gòu)的中央管理器的作用。請看圖三，現(xiàn)在服務(wù)的請求者和提供者之間有了一個(gè)智能的中轉(zhuǎn)站， 服務(wù)的請求者不再需要了解服務(wù)提供者的細(xì)節(jié)。不錯(cuò)！看上去是一個(gè)好的SOA結(jié)構(gòu)。事實(shí)上，傳統(tǒng)的EAI就是通過這樣一種方式來試圖解決企業(yè)內(nèi)部的應(yīng)用整合問題。

EAI的目標(biāo)是支持對(duì)現(xiàn)有IT系統(tǒng)的重新利用，通過EAI技術(shù)能夠?qū)⒉煌能浖拖到y(tǒng)串聯(lián)起來，延長這些應(yīng)用系統(tǒng)的生命周期。傳統(tǒng)的EAI，往往使用如CORBA和COM等的消息中間件進(jìn)行分布式，跨平臺(tái)的程序交互，修改企業(yè)資源規(guī)劃以達(dá)到新的目標(biāo)，使用中間件、XML等方法來進(jìn)行數(shù)據(jù)分配。因此，實(shí)際上傳統(tǒng)的EAI是部件級(jí)的重用。很不幸的是，基于部件的架構(gòu)沒有統(tǒng)一的標(biāo)準(zhǔn)，因此，各個(gè)廠商都有各自不同的EAI解決方案，你會(huì)看到各種各樣的中間件平臺(tái)。如果EAI碰到了異構(gòu)的IT環(huán)境，就必須分別考慮怎樣在各個(gè)不同的中間件之間周旋，來實(shí)現(xiàn)合理的互聯(lián)方式，你不得不考慮各種復(fù)雜的可能性。因此，你所見過的大多數(shù)傳統(tǒng)EAI解決方案都比較笨重。

再回顧一下我們上面介紹過的SOA的應(yīng)用場景：復(fù)雜的企業(yè)級(jí)架構(gòu)。如果我們選擇Hub的模式來構(gòu)建SOA基礎(chǔ)架構(gòu)，從純粹邏輯的角度，可能會(huì)出現(xiàn)哪些問題呢？首先，整個(gè)SOA架構(gòu)的性能，如果每個(gè)服務(wù)的請求都經(jīng)過中央Hub的中轉(zhuǎn)，那么Hub的負(fù)擔(dān)會(huì)很重，速度會(huì)隨著參與者的增多而愈來愈慢；其次，這樣的系統(tǒng)會(huì)很脆弱，一旦Hub出錯(cuò)，整個(gè)SOA架構(gòu)都會(huì)癱瘓；最后，這樣的架構(gòu)會(huì)破壞SOA的開放性原則，參與者運(yùn)行在一個(gè)相對(duì)封閉的環(huán)境中，擴(kuò)展起來十分麻煩。因此，這也不是理想的SOA架構(gòu)。

好了，現(xiàn)在該ESB登場了，請看我們的正解：

它與前面的Hub結(jié)構(gòu)有什么不同呢？首先，它比單一Hub的形式更開放，總線結(jié)構(gòu)有無限擴(kuò)展的可能；其次，真正體現(xiàn)了SOA的理念， 一切皆為服務(wù)，服務(wù)在總線(BUS)中處于平等的地位。即使我們需要一些Hub，那么它們也是以某種服務(wù)的形式部署在總線上，相比上面的結(jié)構(gòu)要靈活的多。這就是ESB，我們需要給它一個(gè)明確的定義：ESB是一種在松散耦合的服務(wù)和應(yīng)用之間標(biāo)準(zhǔn)的集成方式。它可以作用于：

• 面向服務(wù)的架構(gòu) -分布式的應(yīng)用由可重用的服務(wù)組成
• 面向消息的架構(gòu) - 應(yīng)用之間通過ESB發(fā)送和接受消息
• 事件驅(qū)動(dòng)的架構(gòu) - 應(yīng)用之間異步地產(chǎn)生和接收消息

很不幸，上面的定義看上去很拗口，我們暫且用一句較通俗的話來描述它：ESB就是在SOA架構(gòu)中實(shí)現(xiàn)服務(wù)間智能化集成與管理的中介。而它與SOA的關(guān)系要相對(duì)好理解一些：ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務(wù)集成基礎(chǔ)架構(gòu)，它提供了服務(wù)管理的方法和在分布式異構(gòu)環(huán)境中進(jìn)行服務(wù)交互的功能?？梢赃@樣說，ESB是特定環(huán)境下(SOA架構(gòu)中)實(shí)施EAI的方式：首先，在ESB系統(tǒng)中，被集成的對(duì)象被明確定義為服務(wù)，而不是傳統(tǒng)EAI中各種各樣的中間件平臺(tái)，這樣就極大簡化了在集成異構(gòu)性上的考慮，因?yàn)椴还苡性鯓拥膽?yīng)用底層實(shí)現(xiàn)，只要是SOA架構(gòu)中的服務(wù)，它就一定是基于標(biāo)準(zhǔn)的。

其次，ESB明確強(qiáng)調(diào)消息(Message)處理在集成過程中的作用，這里的消息指的是應(yīng)用環(huán)境中被集成對(duì)象之間的溝通。以往傳統(tǒng)的EAI實(shí)施中碰到的最大的問題就是被集成者都有自己的方言，即各自的消息格式。作為基礎(chǔ)架構(gòu)的EAI系統(tǒng)，必須能夠?qū)ο到y(tǒng)范疇內(nèi)的任何一種消息進(jìn)行解析。傳統(tǒng)的EAI系統(tǒng)中的消息處理大多是被動(dòng)的，消息的處理需要各自中間件的私有方式支持，例如API的方式。因此盡管消息處理本身很重要，但消息的直接處理不會(huì)是傳統(tǒng)EAI系統(tǒng)的核心。ESB系統(tǒng)由于集成對(duì)象統(tǒng)一到服務(wù)，消息在應(yīng)用服務(wù)之間傳遞時(shí)格式是標(biāo)準(zhǔn)的，直接面向消息的處理方式成為可能。如果ESB能夠在底層支持現(xiàn)有的各種通訊協(xié)議，那么對(duì)消息的處理就完全不考慮底層的傳輸細(xì)節(jié)，而直接通過消息的標(biāo)準(zhǔn)格式定義來進(jìn)行。這樣，在ESB中，對(duì)消息的處理就會(huì)成為ESB的核心，因?yàn)橥ㄟ^消息處理來集成服務(wù)是最簡單可行的方式。這也是ESB中總線(Bus)功能的體現(xiàn)。其實(shí)，總線的概念并不新鮮，傳統(tǒng)的EAI系統(tǒng)中，也曾經(jīng)提出過信息總線的概念，通過某種中間件平臺(tái)，如CORBA來連接企業(yè)信息孤島，但是，ESB的概念不僅僅是提供消息交互的通道，更重要的是提供服務(wù)的智能化集成基礎(chǔ)架構(gòu)。

最后，事件驅(qū)動(dòng)成為ESB的重要特征。通常服務(wù)之間傳遞的消息有兩種形式，一種是調(diào)用(Call)， 即請求/回應(yīng)方式，這是常見的同步模式。還有一種我們稱之為單路消息(One-way)，它的目的往往是觸發(fā)異步的事件， 發(fā)送者不需要馬上得到回復(fù)?？紤]到有些應(yīng)用服務(wù)是長時(shí)間運(yùn)行的，因此，這種異步服務(wù)之間的消息交互也是ESB必須支持的。除此之外，ESB的很多功能都可以利用這種機(jī)制來實(shí)現(xiàn)，例如，SOA中服務(wù)的性能監(jiān)控等基礎(chǔ)架構(gòu)功能，需要通過ESB來提供數(shù)據(jù)，當(dāng)服務(wù)的請求通過ESB中轉(zhuǎn)的時(shí)候，ESB很容易通過事件驅(qū)動(dòng)機(jī)制向SOA的基礎(chǔ)架構(gòu)服務(wù)傳遞信息。

ESB的適用場景及要素

首先，我們來看一看ESB有哪些基本的功能。既然ESB會(huì)以中介的身份出現(xiàn)，它就必須有兩方面的考慮，首先它必須了解被它中介的兩個(gè)端點(diǎn)：1)服務(wù)的請求者以及請求者對(duì)服務(wù)的要求，2)服務(wù)的提供者和它所提供服務(wù)的描述；其次，它必須具有某種機(jī)制能夠完成中介的任務(wù)。我們把這兩類考慮歸納為ESB的兩個(gè)基本功能：面向服務(wù)的原數(shù)據(jù)(MetaData)管理功能 和中介(Mediation)功能。 作為SOA的重要構(gòu)成部分，ESB承擔(dān)的重任還包括怎樣將企業(yè)架構(gòu)中已存在的業(yè)務(wù)服務(wù)連接到總線上來，我們稱之為適配器(Adapter)功能。盡管服務(wù)本身已經(jīng)用公開的接口來描述，但具體的實(shí)現(xiàn)還是運(yùn)行在不同的環(huán)境中，因此，ESB還應(yīng)該提供對(duì)服務(wù)底層協(xié)議的支持，譬如應(yīng)用協(xié)議J2ee，.Net， 通訊協(xié)議如Http，JMS等等。除此之外，還需要對(duì)具體應(yīng)用中涉及到的服務(wù)加以管理，如性能，可靠性，安全性等等。

ESB 提供了最基本的功能來保障SOA系統(tǒng)的運(yùn)行，這些功能應(yīng)該包含下列內(nèi)容：

• 在總線范疇內(nèi)對(duì)服務(wù)的注冊命名及尋址管理功能 - 服務(wù)的Meta-data管理
• 面向服務(wù)的中介功能
  • 提供位置透明性的服務(wù)路由和定位服務(wù)
  • 多種消息傳遞型式(請求/響應(yīng)，單路請求，發(fā)布/訂閱等等)
  • 支持廣泛使用的傳輸協(xié)議(Http，JMS，MQ等等)
• 支持多種服務(wù)集成方式，比如 JCA、Web 服務(wù)、Messaging、Adaptor
• 對(duì)服務(wù)管理的支持，如服務(wù)調(diào)用的記錄、測量和監(jiān)控?cái)?shù)據(jù)的提供

很多時(shí)候，很難界定哪些功能是應(yīng)該由SOA的基礎(chǔ)架構(gòu)(infrastructure)提供的，而哪些應(yīng)該放在ESB的范疇內(nèi)來解決。筆者認(rèn)為，放大或突出ESB在SOA架構(gòu)中的地位并不很恰當(dāng)。比較合理的解釋是：ESB應(yīng)該構(gòu)筑在完善的SOA架構(gòu)上，做它應(yīng)該做的事-服務(wù)集成。至于怎樣集成，應(yīng)該根據(jù)你的上下文環(huán)境，考慮有哪些SOA的基礎(chǔ)設(shè)施可供你使用，然后再基于SOA的基礎(chǔ)架構(gòu)來實(shí)現(xiàn)你的ESB設(shè)計(jì)。

在更高的層次，ESB還提供諸如服務(wù)代理，協(xié)議轉(zhuǎn)換等等功能，我們稱之為ESB的應(yīng)用模式(ESB usage pattern)。作為SOA架構(gòu)的服務(wù)集成功能提供者，我們可以總結(jié)出的一些比較常用的應(yīng)用模式，例如：

1）協(xié)議轉(zhuǎn)換模型，用于當(dāng)服務(wù)的請求者與服務(wù)提供者基于不同協(xié)議時(shí)的消息轉(zhuǎn)換情形

2）消息廣播模式，用于事件驅(qū)動(dòng)多個(gè)動(dòng)作或者消息廣播的情形

3）服務(wù)匹配模式，用于需要?jiǎng)討B(tài)選擇服務(wù)提供者的情形，例如可以根據(jù)消息的內(nèi)容，或負(fù)載情況，或服務(wù)級(jí)別約定(SLA)，來為服務(wù)請求者選擇合適的服務(wù)。

這里我們只列舉了3個(gè)典型的模式，而這樣的例子實(shí)在太多了，發(fā)揮你的創(chuàng)造性，你還會(huì)想出來更多的，這也是ESB的魅力所在。但是，在ESB的設(shè)計(jì)上，注意不能喧賓奪主，ESB的功能在于幫助服務(wù)的集成，而不是參與業(yè)務(wù)邏輯。業(yè)務(wù)邏輯應(yīng)該封裝在業(yè)務(wù)服務(wù)中，或通過業(yè)務(wù)編排服務(wù)(Process Service)來組織。

實(shí)戰(zhàn)

關(guān)于ESB，目前還沒有被一致接受的標(biāo)準(zhǔn)。我們可以通過選擇成熟的EAI 中間件來實(shí)現(xiàn)服務(wù)的集成與互操作性。這樣做的好處是你的開發(fā)過程會(huì)很順暢，因?yàn)樗呀?jīng)足夠穩(wěn)定且有豐富的工具支持。通常這樣的EAI產(chǎn)品在目前階段都還不是基于開放的標(biāo)準(zhǔn)，例如IBM的WebSphere MQ5.3，作為IBM EAI實(shí)現(xiàn)ESB的消息平臺(tái)，就不是開放的標(biāo)準(zhǔn)。如果一定要選擇開放標(biāo)準(zhǔn)的ESB實(shí)現(xiàn)方式，Web 服務(wù)加上WS-* 協(xié)議幾乎是我們唯一的選擇，但畢竟SOA、ESB仍處于起步的階段，一方面我們還沒有很成熟的產(chǎn)品支持所有的WS-*協(xié)議，另一方面這些WS-* 協(xié)議本身還處在頻繁變化的階段。因此當(dāng)你選擇ESB實(shí)施方案的時(shí)候，最好考慮平衡ESB實(shí)施、開發(fā)的工作量。

這里你可能會(huì)有疑問，既然SOA架構(gòu)追求開放性，為什么我們要容忍用私有的ESB產(chǎn)品如IBM WBI/MQ來構(gòu)建SOA架構(gòu)的集成環(huán)境？這是一個(gè)好問題。SOA始終是我們追求的大目標(biāo)，開放是必然的趨勢，這是毋庸置疑的。但是，請注意ESB的定義，至少到目前為止，還沒有明確的要求它的實(shí)現(xiàn)一定是開放的，每一個(gè)軟件供應(yīng)商對(duì)它都可能有不同的理解和實(shí)現(xiàn)的策略。我們不用懷疑ESB將來的開放之路，但至少在目前階段，我們不能坐下來等待它的到來。 其實(shí)，ESB充當(dāng)?shù)氖荢OA中的中介角色，因此，即使將來ESB變化了，對(duì)服務(wù)的請求者和服務(wù)的提供者都不會(huì)造成很大的沖擊，因?yàn)樗緛砭褪菍?duì)用戶透明的。舉個(gè)例子，J2EE，它的標(biāo)準(zhǔn)一直在變化中，但是大家通常都能接受它的變化，社會(huì)總是要進(jìn)步的，IT也一樣。你不可能因?yàn)镴2EE 兩年以后要出1.6就不再使用現(xiàn)在的1.4了。

IBM目前可以用于ESB實(shí)施的產(chǎn)品也可以分為兩大陣營：

1. 以目前穩(wěn)定的產(chǎn)品如WS MQ，WBI Message Broker，Tivoli等為代表的EAI解決方案。
2. 以WAS6 SIBUS為代表的專用ESB平臺(tái)。

現(xiàn)有的EAI解決方案，可能涉及如下的IBM軟件產(chǎn)品：

• WebSphere BI Message Broker用于提供ESB的message 中介功能(Mediation)
• WebSphere MQ / JMS 用于消息傳輸服務(wù)
• WebSphere Process Choreographer 用于實(shí)現(xiàn)服務(wù)流程
• WebSphere Adaptor用于連接遺留系統(tǒng)
• Web Service Gateway用于實(shí)現(xiàn)Web服務(wù) Proxy，屏蔽企業(yè)內(nèi)部/外部Web服務(wù)的實(shí)現(xiàn)細(xì)節(jié)

WAS6 中提供了嶄新的消息服務(wù)平臺(tái)WPM(WebSphere platform messaging)，并基于這一平臺(tái)提供了ESB的一個(gè)具體實(shí)現(xiàn)- SIBus(Service Integration Bus) 它可以支持同步和異步的消息通信?？偩€(Bus)通過互聯(lián)的消息引擎管理消息源。同時(shí)支持基于Web服務(wù)和JMS，MQ格式的消息交互。你可以從WAS6身上看到IBM戰(zhàn)略的變化，SIBus只是IBM加大對(duì)于SOA支持的一步，你還會(huì)很快看到更多的變化，例如獨(dú)立的ESB產(chǎn)品，ESB的開發(fā)工具等等。但是，你完全不必?fù)?dān)心，這些變化都會(huì)保持兼容性，現(xiàn)在SOA的投入，無論是以哪一種方式，都會(huì)在IBM的SOA整體考慮之中。

上述的兩種方案并不是對(duì)立的，你可以選擇基于成熟產(chǎn)品實(shí)現(xiàn)ESB，也可以嘗試一下IBM的最新技術(shù)。這兩種方案甚至可以互聯(lián)，見圖八。我們將在系列的第四部分講解這一較為復(fù)雜的場景。

在本系列文章接下來的三部分中，我們將繼續(xù)詳細(xì)描述ESB的具體實(shí)現(xiàn)步驟。

回頁首

結(jié)束語

本文向您介紹了SOA以及ESB 的基本知識(shí)，確定了一些 ESB 實(shí)現(xiàn)中最常見的基本功能，論述了ESB產(chǎn)生的必要性，以及ESB在SOA中的地位。

回頁首

參考資料

• Patterns: Service-oriented Architecture and Web Services紅皮書，SG24-6303-00，2004 年 4 月，作者 Endrei M。 等。
• "理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場景和解決方案，第 1 部分"(developerWorks，2003 年 12 月)作者 Rick Robinson。
• Patterns: Implementing an SOA using an Enterprise Service Bus，SG24-6346-00，作者 Martin Keen 等。
• Enterprise service bus - making SOA real作者 Beth Hutchison， Peter Lambros， Rob Phippen， Marc-Thoms Schimdt

回頁首

回頁首

關(guān)于作者

		IBM中國軟件開發(fā)實(shí)驗(yàn)室SOA設(shè)計(jì)中心 是IBM全球四個(gè)SOA設(shè)計(jì)中心中最大的一個(gè)，成立一年多來，已經(jīng)取得了可喜的成就。我們已經(jīng)在全球范圍內(nèi)成功地實(shí)施了多個(gè) SOA 應(yīng)用項(xiàng)目，為多個(gè)行業(yè)的客戶成功地提供了 SOA 解決方案。我們正在實(shí)施的 SOA 項(xiàng)目涵蓋了很多的重要行業(yè)，包括零售業(yè)、航運(yùn)業(yè)、電力、銀行、保險(xiǎn)等等。通過這些不斷增長的成功案例，我們不僅深入地推廣了 SOA 的理念，樹立了 SOA 成功實(shí)施的范例，也為我們的隊(duì)伍積累了經(jīng)驗(yàn)，培養(yǎng)了人才。與此同時(shí)，我們還是 IBM 開發(fā) SOA 的軟件平臺(tái) -- SOA Integration Framework -- 的主力軍。該產(chǎn)品基于模型驅(qū)動(dòng)的思想，旨在最大化地重用軟件資產(chǎn)，它為 SOA 項(xiàng)目的實(shí)施提供了一整套源自成功實(shí)踐的方法論，設(shè)計(jì)范式和工具集。它的出現(xiàn)將極大地方便 SOA 系統(tǒng)架構(gòu)師、設(shè)計(jì)人員、開發(fā)人員快速地開發(fā)基于SOA的應(yīng)用項(xiàng)目。 參與本系列撰寫的主要技術(shù)人員包括： 毛新生 IBM 中國軟件開發(fā)實(shí)驗(yàn)室 資深經(jīng)理， SOA計(jì)中心中國區(qū) 首席架構(gòu)師 李珉 IBM 中國軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 高級(jí)軟件工程師，技術(shù)經(jīng)理 周志榮 IBM 中國軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 軟件工程師 張柯 IBM 中國軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 軟件工程師 金戈 IBM 中國軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 資深軟件工程師，技術(shù)經(jīng)理