| 李珉, 高級軟件工程師，技術(shù)經(jīng)理, IBM 中國軟件開(kāi)發(fā)實(shí)驗室 SOA設計中心 2005 年 8 月 01 日 本文作為ESB系列文章的第一篇，介紹了面向服務(wù)的體系結構(service-oriented architecture，SOA)和企業(yè)服務(wù)總線(xiàn)(Enterprise Service Bus，ESB)的基本知識，ESB的技術(shù)沿革，以及ESB與SOA之間的關(guān)系。 "一切都在流動(dòng)，沒(méi)有什么是持久的。一切都在融化，沒(méi)有什么是固定不變的" - 赫拉克利特(Heracleitus) 大約在2003年中的時(shí)候，SOA的概念逐漸進(jìn)入人們的視野，一時(shí)間眾人樂(lè )此不疲的發(fā)表各自對SOA的見(jiàn)解。SOA已經(jīng)成為IT業(yè)，尤其是軟件開(kāi)發(fā)及系統集成領(lǐng)域從業(yè)者的熱門(mén)話(huà)題。很多的權威機構也紛紛預測SOA的美妙前景，例如，Gartner 預言，到了 2008 年，至少 60% 的企業(yè)將使用 SOA 作為其IT架構。拋開(kāi)喧囂躁動(dòng)以及隨聲附和，對于軟件開(kāi)發(fā)者而言，經(jīng)過(guò)了一年多的概念灌輸，伴隨著(zhù)不斷增長(cháng)的困惑，更多的人希望能靜下心來(lái)看一看：究竟怎樣的系統架構是符合SOA設計的，而又有哪些技術(shù)可以用來(lái)實(shí)現SOA呢？特別是企業(yè)服務(wù)總線(xiàn)(Enterprise Service Bus, ESB)， 看起來(lái)更是SOA中一個(gè)玄虛的概念，本系列文章將通過(guò)實(shí)際的案例分析來(lái)詳細講解在SOA系統中是怎樣實(shí)施ESB的。 本系列文章將直接面向廣大的軟件開(kāi)發(fā)人員， 首先以直觀(guān)的方式介紹什么是ESB， 然后引入一個(gè)實(shí)際案例，以此為基礎，詳細介紹怎樣一步一步實(shí)現ESB?，F在我們談?wù)揝OA和ESB的時(shí)候都不再是空中樓閣，IBM作為SOA的倡導者，已經(jīng)提供了很好的產(chǎn)品來(lái)實(shí)現我們的設想。我們會(huì )在本系列中的第二、第三部分中分別介紹基于WebSphere 6 和IBM EAI產(chǎn)品的兩種實(shí)現方式， 然后在第四部分中介紹在復雜的企業(yè)應用場(chǎng)景中總線(xiàn)(Bus)怎樣互聯(lián)， 怎樣擴展。希望通過(guò)本系列文章，能讓廣大讀者朋友快速掌握ESB的實(shí)際開(kāi)發(fā)技巧。
關(guān)于SOA的概念，你可以找到很多的文章從不同的角度來(lái)描述它，不同的軟件提供商也有不同的定義方式。BEA有流體計算，微軟有Indigo 和SOA-building， SAP有ESA。 每個(gè)人都可以從不同的視角來(lái)理解SOA，從程序員的角度，SOA是一種全新的開(kāi)發(fā)技術(shù)，新的組件模型，比如說(shuō)Web Service；從架構設計師的角度，SOA就是一種新的設計模式，方法學(xué)；從業(yè)務(wù)分析人員的角度，SOA就是基于標準的業(yè)務(wù)應用服務(wù)。從概念的角度，IBM對SOA的定義是最為全面的，既SOA是一種構造分布式系統的方法，它將業(yè)務(wù)應用功能以服務(wù)的形式提供給最終用戶(hù)應用或其他服務(wù)。SOA包括如下要素: 
本文針對的讀者是軟件開(kāi)發(fā)人員，站在開(kāi)發(fā)人員的角度，往往希望軟件開(kāi)發(fā)能夠滿(mǎn)足對于開(kāi)發(fā)效率、可靠性、易維護性、易管理等多方面的更高要求。讓我們通過(guò)回顧軟件開(kāi)發(fā)的演化過(guò)程來(lái)看一看SOA出現的必然性：
我們注意到，SOA同樣也強調重用(Reuse)， 但是相對于傳統的代碼重用，對象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在于業(yè)務(wù)級的應用，即服務(wù)的重用，這與軟件的發(fā)展規律是相一致的。在軟件發(fā)展的過(guò)程中，軟件重用的對象越來(lái)越接近我們的現實(shí)生活。通過(guò)部件的重用，軟件的開(kāi)發(fā)更具效率，并且開(kāi)始試圖用組件表達業(yè)務(wù)模式。但是，IT人員仍很難對業(yè)務(wù)人員解釋清楚IT結構怎樣映射到業(yè)務(wù)模型上。然而，IT架構與業(yè)務(wù)模型的彌合是不可避免的方向?，F代企業(yè)的業(yè)務(wù)環(huán)境所面臨的最大挑戰就是變化，規則在變，需求在變，而對變化做出最快的反應，盡快地適應變化，成為企業(yè)占得先機，成功運作的關(guān)鍵。很多企業(yè)的業(yè)務(wù)環(huán)境依賴(lài)于他們的IT架構，因此，IT部門(mén)往往直接承載了業(yè)務(wù)變化帶來(lái)的壓力。每一個(gè)具體的業(yè)務(wù)變化，都直接反應到對現有的IT平臺的要求：要么企業(yè)IT架構本身對變化自適應，要么IT架構能夠在短時(shí)間內根據新的業(yè)務(wù)規則做出調整。這就是SOA架構提出的根本原因，我們需要一種更加貼近業(yè)務(wù)的IT架構，能夠直接描繪業(yè)務(wù)，對那些不懂IT技術(shù)的業(yè)務(wù)領(lǐng)域專(zhuān)家來(lái)說(shuō)，業(yè)務(wù)服務(wù)卻是他們最熟悉的，也就是說(shuō)是SOA把軟件重用的對象從IT人員上升到了業(yè)務(wù)人員。因此，我們可以說(shuō)SOA與其它的模式相比，最大的進(jìn)步在于它與業(yè)務(wù)的關(guān)聯(lián)性，"服務(wù)"對應到實(shí)際業(yè)務(wù)。IT通過(guò)"服務(wù)"與業(yè)務(wù)發(fā)生了密切的關(guān)系，業(yè)務(wù)人員和IT人員都可以專(zhuān)注于業(yè)務(wù)邏輯的實(shí)現，而共同的語(yǔ)言就是"服務(wù)"。 但不是什么場(chǎng)合都適用SOA。通常來(lái)講，SOA適用于較為復雜的IT架構，經(jīng)常需要與外部復雜的IT環(huán)境交互，并且需要快速地應對頻繁發(fā)生的業(yè)務(wù)變化。就像你不可能在控制洗衣機的芯片上使用EJB開(kāi)發(fā)一樣，如果你的IT環(huán)境規模很小，足以靈活地應對變化，不需要與其他的異構IT環(huán)境頻繁交互，那么SOA帶來(lái)的好處就不足以抵消它給你帶來(lái)的系統復雜性。但是，即令如此，你也并沒(méi)有被完全排除在SOA的大趨勢之外。SOA是如此地倍受矚目，我們可以預見(jiàn)到它的迅猛發(fā)展，因此即使你的內部IT架構本身并不是基于SOA的，你也還有機會(huì )參與到未來(lái)的SOA架構中去。例如，將你的某個(gè)業(yè)務(wù)以服務(wù)的形式發(fā)布到某個(gè)外部SOA平臺上供別人使用，作為第三方SOA平臺的一個(gè)服務(wù)提供者(Service Provider)存在。 在選擇SOA的實(shí)施方案時(shí)，要記住，軟件的具體實(shí)現技術(shù)諸如Web 服務(wù)與SOA是兩回事，SOA是一個(gè)概念，方法學(xué)， 或者用一個(gè)更時(shí)髦的詞：一種模型。而Web 服務(wù)呢？它是一種具體的實(shí)現技術(shù)，就像EJB一樣。SOA ≠ Web服務(wù)。不過(guò)公平地講，Web 服務(wù)倒確實(shí)是目前最適合實(shí)現SOA的技術(shù)之一，用Web 服務(wù)來(lái)封裝業(yè)務(wù)服務(wù)是個(gè)不錯的選擇。因為Web服務(wù)是標準的，WS-I協(xié)議保證了來(lái)自不同廠(chǎng)商的Web服務(wù)即使運行在不同的平臺上，底層的實(shí)現機理不同也可以順利交互，這是以前的任何一種技術(shù)如CORBA，EJB，或DCOM都不能做到的。而且，Web服務(wù)的定義與實(shí)現是分開(kāi)描述的，即松散耦合，因此，可以很方便地替換服務(wù)的內在實(shí)現而不會(huì )對現有的系統造成任何沖擊，這也極大地促進(jìn)了IT架構的靈活性。 對于SOA更進(jìn)一步的了解，可以參考IBM developerWorks上其他SOA相關(guān)的文章(請參見(jiàn)參考資料)，我們的系列文章將主要討論ESB，因此不再此過(guò)多地論述SOA了。為了使我們下面的論述更順暢，請先牢記典型的SOA架構有哪些基本的要求：
讓我們暫時(shí)回到網(wǎng)絡(luò )技術(shù)不普及的時(shí)代，你怎樣在兩臺機器之間傳遞文件？我還記得為了給實(shí)驗室的每臺機器安裝Borland C++的環(huán)境，猜猜我動(dòng)用了什么：一根"串口線(xiàn)"。不過(guò)，我仍然覺(jué)得慶幸，好在每臺機器都運行同樣的操作系統- DOS(很少有人還記得DOS中有Interlnk這樣一個(gè)命令吧)， 用來(lái)通過(guò)串口線(xiàn)在兩臺機器間傳遞流文件。否則我將不得不用軟盤(pán)來(lái)拷貝所有的安裝文件。我那個(gè)時(shí)候的夢(mèng)想就是，哪一天有這么一個(gè)叫做"網(wǎng)絡(luò )"的東西能夠把實(shí)驗室里面所有機器都連接起來(lái)，而不用我在各機器之間跑來(lái)跑去。 讓我們回歸主題，你現在已經(jīng)基本明白了什么是SOA。假定你已經(jīng)按照SOA的思想提煉出了各種業(yè)務(wù)服務(wù)，公布出來(lái)，同樣，你發(fā)現其他很多人也做了同樣的事情。大家都很振奮，開(kāi)始踴躍的嘗試，我調用你的一個(gè)服務(wù)，你調我的一個(gè)服務(wù)。啊哈！大家都SOA了。且慢，那么這個(gè)SOA給你們帶來(lái)了什么好處呢？Ok，現在我可以在J2EE環(huán)境里調用.Net的組件了，但是原來(lái)沒(méi)有SOA的時(shí)候也可以做到的呀。只要兩個(gè)節點(diǎn)之間互相認可對方的方式，即使不存在公開(kāi)/統一的服務(wù)界面也可以實(shí)現點(diǎn)到點(diǎn)的互聯(lián)。因此我們不得不承認，如果我們只有服務(wù)，而服務(wù)的請求者和服務(wù)的提供者之間仍然需要這種顯式的點(diǎn)到點(diǎn)的調用，那么這就不是一個(gè)典型的SOA架構。請看圖二，服務(wù)的參與雙方都必須建立1對1 的聯(lián)系。這樣一個(gè)結構與我十幾年前的那種互聯(lián)的方式何其相似！但是，還記得我們上面提到的SOA三個(gè)基本要素嗎？顯然第三點(diǎn)沒(méi)有做到。  因此，在SOA中，我們還需要這樣一個(gè)中間層，能夠幫助實(shí)現在SOA架構中不同服務(wù)之間的智能化管理。最容易想到的是這樣一個(gè)HUB-Spoke結構，在SOA架構中的各服務(wù)之間設置一個(gè)類(lèi)似于Hub的中間件，由它充當整個(gè)SOA架構的中央管理器的作用。請看圖三，現在服務(wù)的請求者和提供者之間有了一個(gè)智能的中轉站， 服務(wù)的請求者不再需要了解服務(wù)提供者的細節。不錯！看上去是一個(gè)好的SOA結構。事實(shí)上，傳統的EAI就是通過(guò)這樣一種方式來(lái)試圖解決企業(yè)內部的應用整合問(wèn)題。 EAI的目標是支持對現有IT系統的重新利用，通過(guò)EAI技術(shù)能夠將不同的軟件和系統串聯(lián)起來(lái)，延長(cháng)這些應用系統的生命周期。傳統的EAI，往往使用如CORBA和COM等的消息中間件進(jìn)行分布式，跨平臺的程序交互，修改企業(yè)資源規劃以達到新的目標，使用中間件、XML等方法來(lái)進(jìn)行數據分配。因此，實(shí)際上傳統的EAI是部件級的重用。很不幸的是，基于部件的架構沒(méi)有統一的標準，因此，各個(gè)廠(chǎng)商都有各自不同的EAI解決方案，你會(huì )看到各種各樣的中間件平臺。如果EAI碰到了異構的IT環(huán)境，就必須分別考慮怎樣在各個(gè)不同的中間件之間周旋，來(lái)實(shí)現合理的互聯(lián)方式，你不得不考慮各種復雜的可能性。因此，你所見(jiàn)過(guò)的大多數傳統EAI解決方案都比較笨重。 再回顧一下我們上面介紹過(guò)的SOA的應用場(chǎng)景：復雜的企業(yè)級架構。如果我們選擇Hub的模式來(lái)構建SOA基礎架構，從純粹邏輯的角度，可能會(huì )出現哪些問(wèn)題呢？首先，整個(gè)SOA架構的性能，如果每個(gè)服務(wù)的請求都經(jīng)過(guò)中央Hub的中轉，那么Hub的負擔會(huì )很重，速度會(huì )隨著(zhù)參與者的增多而愈來(lái)愈慢；其次，這樣的系統會(huì )很脆弱，一旦Hub出錯，整個(gè)SOA架構都會(huì )癱瘓；最后，這樣的架構會(huì )破壞SOA的開(kāi)放性原則，參與者運行在一個(gè)相對封閉的環(huán)境中，擴展起來(lái)十分麻煩。因此，這也不是理想的SOA架構。 好了，現在該ESB登場(chǎng)了，請看我們的正解： 它與前面的Hub結構有什么不同呢？首先，它比單一Hub的形式更開(kāi)放，總線(xiàn)結構有無(wú)限擴展的可能；其次，真正體現了SOA的理念， 一切皆為服務(wù)，服務(wù)在總線(xiàn)(BUS)中處于平等的地位。即使我們需要一些Hub，那么它們也是以某種服務(wù)的形式部署在總線(xiàn)上，相比上面的結構要靈活的多。這就是ESB，我們需要給它一個(gè)明確的定義：ESB是一種在松散耦合的服務(wù)和應用之間標準的集成方式。它可以作用于：
很不幸，上面的定義看上去很拗口，我們暫且用一句較通俗的話(huà)來(lái)描述它：ESB就是在SOA架構中實(shí)現服務(wù)間智能化集成與管理的中介。而它與SOA的關(guān)系要相對好理解一些：ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務(wù)集成基礎架構，它提供了服務(wù)管理的方法和在分布式異構環(huán)境中進(jìn)行服務(wù)交互的功能?？梢赃@樣說(shuō)，ESB是特定環(huán)境下(SOA架構中)實(shí)施EAI的方式：首先，在ESB系統中，被集成的對象被明確定義為服務(wù)，而不是傳統EAI中各種各樣的中間件平臺，這樣就極大簡(jiǎn)化了在集成異構性上的考慮，因為不管有怎樣的應用底層實(shí)現，只要是SOA架構中的服務(wù)，它就一定是基于標準的。 其次，ESB明確強調消息(Message)處理在集成過(guò)程中的作用，這里的消息指的是應用環(huán)境中被集成對象之間的溝通。以往傳統的EAI實(shí)施中碰到的最大的問(wèn)題就是被集成者都有自己的方言，即各自的消息格式。作為基礎架構的EAI系統，必須能夠對系統范疇內的任何一種消息進(jìn)行解析。傳統的EAI系統中的消息處理大多是被動(dòng)的，消息的處理需要各自中間件的私有方式支持，例如API的方式。因此盡管消息處理本身很重要，但消息的直接處理不會(huì )是傳統EAI系統的核心。ESB系統由于集成對象統一到服務(wù)，消息在應用服務(wù)之間傳遞時(shí)格式是標準的，直接面向消息的處理方式成為可能。如果ESB能夠在底層支持現有的各種通訊協(xié)議，那么對消息的處理就完全不考慮底層的傳輸細節，而直接通過(guò)消息的標準格式定義來(lái)進(jìn)行。這樣，在ESB中，對消息的處理就會(huì )成為ESB的核心，因為通過(guò)消息處理來(lái)集成服務(wù)是最簡(jiǎn)單可行的方式。這也是ESB中總線(xiàn)(Bus)功能的體現。其實(shí)，總線(xiàn)的概念并不新鮮，傳統的EAI系統中，也曾經(jīng)提出過(guò)信息總線(xiàn)的概念，通過(guò)某種中間件平臺，如CORBA來(lái)連接企業(yè)信息孤島，但是，ESB的概念不僅僅是提供消息交互的通道，更重要的是提供服務(wù)的智能化集成基礎架構。 最后，事件驅動(dòng)成為ESB的重要特征。通常服務(wù)之間傳遞的消息有兩種形式，一種是調用(Call)， 即請求/回應方式，這是常見(jiàn)的同步模式。還有一種我們稱(chēng)之為單路消息(One-way)，它的目的往往是觸發(fā)異步的事件， 發(fā)送者不需要馬上得到回復?？紤]到有些應用服務(wù)是長(cháng)時(shí)間運行的，因此，這種異步服務(wù)之間的消息交互也是ESB必須支持的。除此之外，ESB的很多功能都可以利用這種機制來(lái)實(shí)現，例如，SOA中服務(wù)的性能監控等基礎架構功能，需要通過(guò)ESB來(lái)提供數據，當服務(wù)的請求通過(guò)ESB中轉的時(shí)候，ESB很容易通過(guò)事件驅動(dòng)機制向SOA的基礎架構服務(wù)傳遞信息。
首先，我們來(lái)看一看ESB有哪些基本的功能。既然ESB會(huì )以中介的身份出現，它就必須有兩方面的考慮，首先它必須了解被它中介的兩個(gè)端點(diǎn)：1)服務(wù)的請求者以及請求者對服務(wù)的要求，2)服務(wù)的提供者和它所提供服務(wù)的描述；其次，它必須具有某種機制能夠完成中介的任務(wù)。我們把這兩類(lèi)考慮歸納為ESB的兩個(gè)基本功能：面向服務(wù)的原數據(MetaData)管理功能 和中介(Mediation)功能。 作為SOA的重要構成部分，ESB承擔的重任還包括怎樣將企業(yè)架構中已存在的業(yè)務(wù)服務(wù)連接到總線(xiàn)上來(lái)，我們稱(chēng)之為適配器(Adapter)功能。盡管服務(wù)本身已經(jīng)用公開(kāi)的接口來(lái)描述，但具體的實(shí)現還是運行在不同的環(huán)境中，因此，ESB還應該提供對服務(wù)底層協(xié)議的支持，譬如應用協(xié)議J2ee，.Net， 通訊協(xié)議如Http，JMS等等。除此之外，還需要對具體應用中涉及到的服務(wù)加以管理，如性能，可靠性，安全性等等。 ESB 提供了最基本的功能來(lái)保障SOA系統的運行，這些功能應該包含下列內容：
很多時(shí)候，很難界定哪些功能是應該由SOA的基礎架構(infrastructure)提供的，而哪些應該放在ESB的范疇內來(lái)解決。筆者認為，放大或突出ESB在SOA架構中的地位并不很恰當。比較合理的解釋是：ESB應該構筑在完善的SOA架構上，做它應該做的事-服務(wù)集成。至于怎樣集成，應該根據你的上下文環(huán)境，考慮有哪些SOA的基礎設施可供你使用，然后再基于SOA的基礎架構來(lái)實(shí)現你的ESB設計。 在更高的層次，ESB還提供諸如服務(wù)代理，協(xié)議轉換等等功能，我們稱(chēng)之為ESB的應用模式(ESB usage pattern)。作為SOA架構的服務(wù)集成功能提供者，我們可以總結出的一些比較常用的應用模式，例如： 1）協(xié)議轉換模型，用于當服務(wù)的請求者與服務(wù)提供者基于不同協(xié)議時(shí)的消息轉換情形 2）消息廣播模式，用于事件驅動(dòng)多個(gè)動(dòng)作或者消息廣播的情形 3）服務(wù)匹配模式，用于需要動(dòng)態(tài)選擇服務(wù)提供者的情形，例如可以根據消息的內容，或負載情況，或服務(wù)級別約定(SLA)，來(lái)為服務(wù)請求者選擇合適的服務(wù)。 這里我們只列舉了3個(gè)典型的模式，而這樣的例子實(shí)在太多了，發(fā)揮你的創(chuàng )造性，你還會(huì )想出來(lái)更多的，這也是ESB的魅力所在。但是，在ESB的設計上，注意不能喧賓奪主，ESB的功能在于幫助服務(wù)的集成，而不是參與業(yè)務(wù)邏輯。業(yè)務(wù)邏輯應該封裝在業(yè)務(wù)服務(wù)中，或通過(guò)業(yè)務(wù)編排服務(wù)(Process Service)來(lái)組織。
關(guān)于ESB，目前還沒(méi)有被一致接受的標準。我們可以通過(guò)選擇成熟的EAI 中間件來(lái)實(shí)現服務(wù)的集成與互操作性。這樣做的好處是你的開(kāi)發(fā)過(guò)程會(huì )很順暢，因為它已經(jīng)足夠穩定且有豐富的工具支持。通常這樣的EAI產(chǎn)品在目前階段都還不是基于開(kāi)放的標準，例如IBM的WebSphere MQ5.3，作為IBM EAI實(shí)現ESB的消息平臺，就不是開(kāi)放的標準。如果一定要選擇開(kāi)放標準的ESB實(shí)現方式，Web 服務(wù)加上WS-* 協(xié)議幾乎是我們唯一的選擇，但畢竟SOA、ESB仍處于起步的階段，一方面我們還沒(méi)有很成熟的產(chǎn)品支持所有的WS-*協(xié)議，另一方面這些WS-* 協(xié)議本身還處在頻繁變化的階段。因此當你選擇ESB實(shí)施方案的時(shí)候，最好考慮平衡ESB實(shí)施、開(kāi)發(fā)的工作量。 這里你可能會(huì )有疑問(wèn)，既然SOA架構追求開(kāi)放性，為什么我們要容忍用私有的ESB產(chǎn)品如IBM WBI/MQ來(lái)構建SOA架構的集成環(huán)境？這是一個(gè)好問(wèn)題。SOA始終是我們追求的大目標，開(kāi)放是必然的趨勢，這是毋庸置疑的。但是，請注意ESB的定義，至少到目前為止，還沒(méi)有明確的要求它的實(shí)現一定是開(kāi)放的，每一個(gè)軟件供應商對它都可能有不同的理解和實(shí)現的策略。我們不用懷疑ESB將來(lái)的開(kāi)放之路，但至少在目前階段，我們不能坐下來(lái)等待它的到來(lái)。 其實(shí)，ESB充當的是SOA中的中介角色，因此，即使將來(lái)ESB變化了，對服務(wù)的請求者和服務(wù)的提供者都不會(huì )造成很大的沖擊，因為它本來(lái)就是對用戶(hù)透明的。舉個(gè)例子，J2EE，它的標準一直在變化中，但是大家通常都能接受它的變化，社會(huì )總是要進(jìn)步的，IT也一樣。你不可能因為J2EE 兩年以后要出1.6就不再使用現在的1.4了。 IBM目前可以用于ESB實(shí)施的產(chǎn)品也可以分為兩大陣營(yíng)：
現有的EAI解決方案，可能涉及如下的IBM軟件產(chǎn)品：
WAS6 中提供了嶄新的消息服務(wù)平臺WPM(WebSphere platform messaging)，并基于這一平臺提供了ESB的一個(gè)具體實(shí)現- SIBus(Service Integration Bus) 它可以支持同步和異步的消息通信?？偩€(xiàn)(Bus)通過(guò)互聯(lián)的消息引擎管理消息源。同時(shí)支持基于Web服務(wù)和JMS，MQ格式的消息交互。你可以從WAS6身上看到IBM戰略的變化，SIBus只是IBM加大對于SOA支持的一步，你還會(huì )很快看到更多的變化，例如獨立的ESB產(chǎn)品，ESB的開(kāi)發(fā)工具等等。但是，你完全不必擔心，這些變化都會(huì )保持兼容性，現在SOA的投入，無(wú)論是以哪一種方式，都會(huì )在IBM的SOA整體考慮之中。 上述的兩種方案并不是對立的，你可以選擇基于成熟產(chǎn)品實(shí)現ESB，也可以嘗試一下IBM的最新技術(shù)。這兩種方案甚至可以互聯(lián)，見(jiàn)圖八。我們將在系列的第四部分講解這一較為復雜的場(chǎng)景。 在本系列文章接下來(lái)的三部分中，我們將繼續詳細描述ESB的具體實(shí)現步驟。
本文向您介紹了SOA以及ESB 的基本知識，確定了一些 ESB 實(shí)現中最常見(jiàn)的基本功能，論述了ESB產(chǎn)生的必要性，以及ESB在SOA中的地位。
| |||||||||||||||||||||||||||||
聯(lián)系客服
