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