ESB企業(yè)服務(wù)總線解決方案剖析

1、關(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 對 soa 的定義是最為全面的，既 soa 是一種構(gòu)造分布式系統(tǒng)的方法，它將業(yè)務(wù)應(yīng)用功能以服務(wù)的形式提供給最終用戶應(yīng)用或其

2、他服務(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)一本文針對的讀者是軟件開發(fā)人員， 站在開發(fā)人員的角度， 往往希望軟件開發(fā)能夠滿足對于開發(fā)效率、可靠性、易維護(hù)性、易管理等多方面的更高要求。讓我們通過回顧軟件開發(fā)的演化過程來看一看 soa 出現(xiàn)的必然性：面向機(jī)器語言 (monolithic) 的開發(fā)模式：需要根據(jù)不同平臺的機(jī)器語言來開發(fā)代碼。

3、面向過程 (procedure) 的開發(fā)模式：獨(dú)立于機(jī)器的程序語言(c, pascal等 )使開發(fā)過程變得簡單了，用過程來代表一個(gè)抽象的代碼集合，包裝重用現(xiàn)成的代碼。面向?qū)ο?object)的開發(fā)模式：用更接近現(xiàn)實(shí)的對象來表述一個(gè)相對完整的事物。面向?qū)ο蟮恼Z言 (smalltalk ，java 等 )，提供了更抽象的封裝和重用模式。域到軟件程序的直接映射，更接近人類的自然思維方式。面向?qū)ο蟮拈_發(fā)強(qiáng)調(diào)從現(xiàn)實(shí)世界問題面向組件 (component)的模式：隨著軟件開發(fā)規(guī)模的擴(kuò)大，在涉及分布式、異構(gòu)等復(fù)雜特征的環(huán)境中，代碼級別的重用性差，可維護(hù)性差，效率低的弱點(diǎn)是不可逾越的，因此人們以架構(gòu)運(yùn)行環(huán)境(

4、如 .net ，j2ee 等 )來提供完善的支撐平臺，從而把開發(fā)者解放出來，更專注于業(yè)務(wù)核心的開發(fā)。而這些業(yè)務(wù)功能 (business function)以組件的形式 (dcom ， ejb 等 )發(fā)布運(yùn)行在架構(gòu)運(yùn)行環(huán)境中。軟件開發(fā)的重用模式也上升到業(yè)務(wù)組件的級別。面向服務(wù) (soa) 的模式：當(dāng)軟件的使用范圍擴(kuò)展到更廣闊的范圍，往往會面對更加復(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ù)都

5、講著同樣的語言。soa 考慮了業(yè)務(wù)發(fā)展的長期性，體現(xiàn)了"變化就是永恒 "的思想。 soa 的核心體現(xiàn)在企業(yè)應(yīng)用或者業(yè)務(wù)功能上的"重用 "和 "互操作 "，而不再把 it 與業(yè)務(wù)對立起來，這可以被視為在it 驅(qū)動(dòng)業(yè)務(wù)的方向上邁出的重要一步。我們注意到， soa 同樣也強(qiáng)調(diào)重用 (reuse) ， 但是相對于傳統(tǒng)的代碼重用，對象重用，和部件重用， soa 的重用粒度更粗。soa 的重用在于業(yè)務(wù)級的應(yīng)用，即服務(wù)的重用，這與軟件的發(fā)展規(guī)律是相一致的。在軟件發(fā)展的過程中，軟件重用的對象越來越接近我們的現(xiàn)實(shí)生活。通過部件的重用，軟件的開發(fā)更具效率

6、，并且開始試圖用組件表達(dá)業(yè)務(wù)模式。但是， it 人員仍很難對業(yè)務(wù)人員解釋清楚 it 結(jié)構(gòu)怎樣映射到業(yè)務(wù)模型上。然而，it 架構(gòu)與業(yè)務(wù)模型的彌合是不可避免的方向?，F(xiàn)代企業(yè)的業(yè)務(wù)環(huán)境所面臨的最大挑戰(zhàn)就是變化，規(guī)則在變，需求在變，而對變化做出最快的反應(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)到對現(xiàn)有的 it 平臺的要求：要么企業(yè)it 架構(gòu)本身對變化自適應(yīng)，要么it 架構(gòu)能夠在短時(shí)間內(nèi)根據(jù)新的業(yè)務(wù)規(guī)則做出調(diào)整。這就是soa 架構(gòu)提出的根本原因，我們需要一種更加貼近業(yè)

7、務(wù)的it 架構(gòu)，能夠直接描繪業(yè)務(wù)，對那些不懂it 技術(shù)的業(yè)務(wù)領(lǐng)域?qū)＜襾碚f，業(yè)務(wù)服務(wù)卻是他們最熟悉的，也就是說是 soa 把軟件重用的對象從it 人員上升到了業(yè)務(wù)人員。因此，我們可以說soa 與其它的模式相比，最大的進(jìn)步在于它與業(yè)務(wù)的關(guān)聯(lián)性，" 服務(wù) " 對應(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)對頻繁發(fā)生的業(yè)

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

9、，要記住，軟件的具體實(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)行在不同的平臺上，底層的實(shí)現(xiàn)機(jī)理不同也可以順利交互，這是以前的任何一種技術(shù)如corba ， ejb ，或 dcom 都不能做到的。而且，web 服務(wù)的定義與實(shí)現(xiàn)是分開描述的，即松散耦合， 因此，可以很

10、方便地替換服務(wù)的內(nèi)在實(shí)現(xiàn)而不會對現(xiàn)有的系統(tǒng)造成任何沖擊，這也極大地促進(jìn)了it 架構(gòu)的靈活性。對于 soa 更進(jìn)一步的了解，可以參考ibm developerworks上其他 soa 相關(guān)的文章 (請參見參考資料 )，我們的系列文章將主要討論esb ，因此不再此過多地論述soa 了。為了使我們下面的論述更順暢，請先牢記典型的soa 架構(gòu)有哪些基本的要求：soa 在相對較粗的粒度上對應(yīng)用服務(wù)或業(yè)務(wù)模塊進(jìn)行封裝與重用；服務(wù)間保持松散耦合，基于開放的標(biāo)準(zhǔn)，服務(wù)的接口描述與具體實(shí)現(xiàn)無關(guān)；靈活的架構(gòu)- 服務(wù)的實(shí)現(xiàn)細(xì)節(jié)，服務(wù)的位置乃至服務(wù)請求的底層協(xié)議都應(yīng)該透明；esb讓我們暫時(shí)回到網(wǎng)絡(luò)技術(shù)不普及的時(shí)代，你

11、怎樣在兩臺機(jī)器之間傳遞文件？我還記得為了給實(shí)驗(yàn)室的每臺機(jī)器安裝 borland c+的環(huán)境，猜猜我動(dòng)用了什么：一根"串口線 "。不過，我仍然覺得慶幸，好在每臺機(jī)器都運(yùn)行同樣的操作系統(tǒng)- dos( 很少有人還記得dos 中有 interlnk 這樣一個(gè)命令吧 )， 用來通過串口線在兩臺機(jī)器間傳遞流文件。否則我將不得不用軟盤來拷貝所有的安裝文件。我那個(gè)時(shí)候的夢想就是，哪一天有這么一個(gè)叫做"網(wǎng)絡(luò) " 的東西能夠把實(shí)驗(yàn)室里面所有機(jī)器都連接起來，而不用我在各機(jī)器之間跑來跑去。讓我們回歸主題， 你現(xiàn)在已經(jīng)基本明白了什么是soa 。假定你已經(jīng)按照soa 的思想提煉出了

12、各種業(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)可對方的方式，即使不存在公開/統(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 對 1的聯(lián)系。這樣一個(gè)結(jié)構(gòu)與

13、我十幾年前的那種互聯(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)是支持對

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

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

16、ub 結(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)生和接收消息很不幸，上面的定義看上去很拗口，我們暫且用一句較通俗的話來描

17、述它：esb 就是在 soa架構(gòu)中實(shí)現(xiàn)服務(wù)間智能化集成與管理的中介。而它與soa 的關(guān)系要相對好理解一些： 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)中，被集成的對象被明確定義為服務(wù)，而不是傳統(tǒng)eai 中各種各樣的中間件平臺，這樣就極大簡化了在集成異構(gòu)性上的考慮，因?yàn)椴还苡性鯓拥膽?yīng)用底層實(shí)現(xiàn)，只要是soa 架構(gòu)中的服務(wù)，它就一定是基于標(biāo)準(zhǔn)的。其次， esb 明確強(qiáng)調(diào)消息 (message) 處理在集成過程

18、中的作用， 這里的消息指的是應(yīng)用環(huán)境中被集成對象之間的溝通。以往傳統(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 的方式。因此盡管消息處理本身很重要，但消息的直接處理不會是傳統(tǒng)eai 系統(tǒng)的核心。 esb系統(tǒng)由于集成對象統(tǒng)一到服務(wù)，消息在應(yīng)用服務(wù)之間傳遞時(shí)格式是標(biāo)準(zhǔn)的，直接面向消息的處理方式成為可能。如果esb 能夠在底層支持現(xiàn)有的各種通訊協(xié)議，那么對消息的處理就完全不考慮底層的傳輸細(xì)節(jié)，而直接

19、通過消息的標(biāo)準(zhǔn)格式定義來進(jìn)行。這樣，在esb 中，對消息的處理就會成為 esb 的核心，因?yàn)橥ㄟ^消息處理來集成服務(wù)是最簡單可行的方式。這也是esb 中總線 (bus) 功能的體現(xiàn)。其實(shí)，總線的概念并不新鮮，傳統(tǒng)的eai 系統(tǒng)中，也曾經(jīng)提出過信息總線的概念，通過某種中間件平臺，如corba來連接企業(yè)信息孤島，但是，esb 的概念不僅僅是提供消息交互的通道，更重要的是提供服務(wù)的智能化集成基礎(chǔ)架構(gòu)。最后，事件驅(qū)動(dòng)成為 esb 的重要特征。通常服務(wù)之間傳遞的消息有兩種形式，一種是調(diào)用 (call) ，即請求 /回應(yīng)方式，這是常見的同步模式。還有一種我們稱之為單路消息(one-way) ，它的目的往往是

20、觸發(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 會以中介的身份出現(xiàn)，它就必須有兩方面的考慮，首先它必須了解被它中介的兩個(gè)端點(diǎn)：1) 服務(wù)的請求者以及請求者對服務(wù)的要求，2)服務(wù)的提供者和它所提供服務(wù)

21、的描述；其次，它必須具有某種機(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)該提供對服務(wù)底層協(xié)議的支持，譬如應(yīng)用協(xié)議 j2ee ，.net ， 通訊協(xié)議如 http ，jms 等等。除此之外，還需要對具體應(yīng)用中涉及到的服務(wù)加以管理，如性能，可靠性

22、，安全性等等。esb提供了最基本的功能來保障soa系統(tǒng)的運(yùn)行，這些功能應(yīng)該包含下列內(nèi)容：在總線范疇內(nèi)對服務(wù)的注冊命名及尋址管理功能- 服務(wù)的meta-data管理面向服務(wù)的中介功能提供位置透明性的服務(wù)路由和定位服務(wù)多種消息傳遞型式(請求 /響應(yīng)，單路請求，發(fā)布/ 訂閱等等 )支持廣泛使用的傳輸協(xié)議(http ， jms ， mq 等等 )支持多種服務(wù)集成方式，比如jca 、 web服務(wù)、 messaging 、 adaptor對服務(wù)管理的支持，如服務(wù)調(diào)用的記錄、測量和監(jiān)控?cái)?shù)據(jù)的提供很多時(shí)候， 很難界定哪些功能是應(yīng)該由soa 的基礎(chǔ)架構(gòu) (infrastructure)提供的， 而哪些應(yīng)該放在

23、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）消息

24、廣播模式，用于事件驅(qū)動(dòng)多個(gè)動(dòng)作或者消息廣播的情形3）服務(wù)匹配模式，用于需要?jiǎng)討B(tài)選擇服務(wù)提供者的情形，例如可以根據(jù)消息的內(nèi)容，或負(fù)載情況，或服務(wù)級別約定 (sla) ，來為服務(wù)請求者選擇合適的服務(wù)。這里我們只列舉了 3 個(gè)典型的模式， 而這樣的例子實(shí)在太多了， 發(fā)揮你的創(chuàng)造性， 你還會想出來更多的，這也是 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

25、 中間件來實(shí)現(xiàn)服務(wù)的集成與互操作性。這樣做的好處是你的開發(fā)過程會很順暢，因?yàn)樗呀?jīng)足夠穩(wěn)定且有豐富的工具支持。通常這樣的eai 產(chǎn)品在目前階段都還不是基于開放的標(biāo)準(zhǔn)，例如 ibm 的 websphere mq5.3，作為 ibm eai 實(shí)現(xiàn) esb 的消息平臺，就不是開放的標(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ā)的工作

26、量。這里你可能會有疑問， 既然 soa 架構(gòu)追求開放性， 為什么我們要容忍用私有的esb 產(chǎn)品如 ibmwbi/mq 來構(gòu)建 soa 架構(gòu)的集成環(huán)境？這是一個(gè)好問題。soa 始終是我們追求的大目標(biāo)， 開放是必然的趨勢，這是毋庸置疑的。但是，請注意esb 的定義，至少到目前為止，還沒有明確的要求它的實(shí)現(xiàn)一定是開放的， 每一個(gè)軟件供應(yīng)商對它都可能有不同的理解和實(shí)現(xiàn)的策略。我們不用懷疑esb 將來的開放之路，但至少在目前階段，我們不能坐下來等待它的到來。其實(shí)， esb 充當(dāng)?shù)氖莝oa 中的中介角色，因此，即使將來esb 變化了，對服務(wù)的請求者和服務(wù)的提供者都不會造成很大的沖擊，因?yàn)樗緛砭褪菍τ脩敉该鞯?。舉個(gè)例子，j2ee ，它的標(biāo)準(zhǔn)一直在變化中，但是大家通常都能接受