作爲構建SOA項目的基礎架構，ESB正在受到各大廠商的追捧。但是人們往往片面地看待ESB本身，以及它在SOA項目中的作用，其實ESB並不是那樣。
集成技術和SOA的結合
談到ESB，人們會自然想到兩個關鍵詞:集成和SOA。是的，ESB正是集成技術和SOA思想結合的產物。
分佈式時代的集成技術
從集成技術的發展歷史來看，最早是簡單地點對點集成，兩個應用通過各自的接口來實現通信。這種接口固化在應用當中的緊密耦合方式，使得系統毫無靈活性可言，應用本身的每次變化都會要求其相應接口的重新定製。
於是發展出基於消息的中間件，接口被消息代理所取代，應用與應用之間不再是通過其本身的接口互聯，而是通過獨立的消息代理來通信，這使得應用與應用之間耦合更鬆，應用的變化影響的只是消息代理，而不需要其他應用改變。但是它仍然是點對點集成的一種方式，路由邏輯和業務邏輯沒有分離，系統基本沒有擴展性，部署上還是網狀結構。
這種點對點的集成方式應付少量應用的整合還差強人意，對於大規模的集成，在EAI時代，逐漸發展出“集線器”模式。通過把所有的系統都連接到中央交換中心，這種模式巧妙地把集成邏輯和業務邏輯分離開來，大大增加了系統彈性。但是這種中央控制的方式使得管理相當複雜，同時中央又往往成爲集成的瓶頸所在。
分佈式時代的到來對於集成的方式提出了巨大的挑戰，這時候ESB就應運而生。通過採用輕量級的分佈式體系，ESB將更多的處理邏輯分配到多個的端點上，中央服務器不復存在，業務邏輯處理能力及系統壓力可靈活調配。
“總線對於Hub進行了拓展，拓撲的模式還是那樣，但是這個單一的物理中心被虛擬化，分散到了整個網絡上，負載和靈活性都大大增加了。”IBM的毛新生這樣解釋ESB，他認爲ESB真正實現了系統間的鬆耦合，從而能夠應對大規模的集成。
“ESB就是EAI在SOA時代下的一種形態。”金蝶中間件ESB產品項目經理倪曉兵說，“區別於傳統的EAI技術，ESB不僅支持高度的分佈式部署，同時支持異步消息的交互，強調面向的對象是符合標準的服務。”
另外，ESB在集成的過程中，更強調一種“統一消息”的概念。這種“統一消息”的格式，是可以被在ESB中所集成的各個服務都認可的。例如，IBM提出的SDO這樣的一種統一的數據格式。
SOA時代下的產物
在SOA時代下，ESB爲SOA的實施提供了底層架構的技術支持。SOA從根本上來說就是要解決兩個問題:重用和異構，但是作爲信息化系統建設永遠要面對的兩個難題，解決的方法卻並不簡單，所以SOA的體系龐大而複雜。
另外，SOA從根本上來說是一種軟件架構的思想和方法論，它必須有相應的技術來幫助它落地，應用在具體的項目當中，而ESB則提供了實施SOA、簡化SOA的技術手段。“ESB的意義在於讓SOA有了一個可實現的基礎設施。”IONA公司大中國區高級架構師陸飛舟這樣說。
對於SOA要解決的兩個難題，ESB從底層架構上都進行了技術支持。對於服務的重用，ESB提供了服務倉庫和消息的路由，來實現服務之間的彼此調用。一個應用如果需要調用一個服務，它根本不用知道這個服務在什麼地方，如何調用等，而只需要發送一個調用的請求，ESB就會幫助它找到那個服務，並進行綁定和消息的路由。“ESB爲服務提供者和服務消費者之間的集成提供了一個平臺。”倪曉兵說。
更重要的是ESB爲分散服務提供了交互、組合和治理的基礎架構。有了它，SOA才能釋放自己的最大價值。
而對於異構環境的連接，這是ESB天生就具備的能力，因爲集成技術一開始就是面向異構環境的。不同的數據、消息遵循不同的協議，採用不同的格式，爲了完成它們之間的交互，ESB就必須提供轉換的能力。同時作爲EAI在SOA下的一種形態，ESB更具開放性，尤其是對Web服務的支持。
IBM爲ESB定義了四個必備的功能:“路由器”——根據信息內容，在不同應用和服務之間進行信息傳輸和路由;“轉換器”——進行應用之間的通信協議轉換;“翻譯機”——進行應用之間的消息格式轉換;“收發室”——處理來自不同渠道的業務事件(同步傳輸，異步傳輸，發佈/訂閱等方式)。
其中“路由器”和“收發室”都是針對服務的重用而設計的，而“轉換器”和“翻譯機”則專門用來解決異構的通信問題。
針對重用和異構這兩個難題，倪曉兵認爲ESB提供了兩個核心的功能，服務的管理和數據的轉換。
那麼ESB到底是什麼呢?業內對ESB的定義是:它是由中間件技術實現並支持SOA的一組基礎架構，支持異構環境中的服務、消息以及基於事件的交互，並且具有適當的服務級別和可管理性。
ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務集成基礎架構，它提供了服務管理的方法和在分佈式異構環境中進行服務交互的功能。
ESB不僅僅是連通
連通是最基礎的能力
不管是應對集成還是支持SOA落地，連通性都是ESB要解決的首要問題，數據和消息的傳輸和轉換是SOA實現的基礎。作爲SOA架構的信息傳輸龍骨，ESB爲SOA提供一種連通性基礎架構，用以連接SOA中的服務。
IBM WebSphere軟件全球副總裁Sandy Carter女士介紹說，“ESB是SOA中的消息框架，即消息相互交換和通信的方式，是業界標準與客戶消息框架的整合。”
“IT系統如果是一個人體的話，血液就是數據，心臟和血管就是ESB，大腦等器官就是應用，這樣一個整體就是SOA。”毛新生這樣比喻。
ESB要做到還很多
但是ESB的作用絕不僅限於連接。“企業需要不受限制的ESB。這是因爲SOA不僅僅需要ESB來解決連通性問題，而且還需要ESB與附加產品的運行環境一起得到擴展，以便形成一個可以充分整合併有效連通的解決方案。”Sandy Carter說。
BEA公司中國區技術經理劉汩春說:“SOA的‘服務’不僅僅是可重用，而且必須是可組裝編排;可快速註冊發佈; 質量可監控;生命週期可管理的。這樣SOA才能在整個IT範圍內實現服務治理和優化，從而直接推動業務的優化。”
倪曉兵介紹，金蝶中間件推出的Apusic ESB不僅包含了數據連通的功能，還涵蓋了智能網絡、服務倉庫、業務重組和管理工具。
首先，分佈式部署和集中控制是ESB的典型特徵。ESB服務器在物理上可能相隔很遠，但是通過集中管理，這些服務器組成了一個ESB網絡，在邏輯上形成完整的企業服務總線。
在Apusic ESB的智能網絡中，不要求網絡中的各個服務器都必須明確地和其他所有的服務器建立連接關係，只要一個節點不是孤立節點，那麼這個節點就可以和Apusic ESB網絡中的任意非孤立節點通信。並且，在通信過程中的路徑選擇上，Apusic ESB 網絡會根據網絡連接狀況的實際情況，作出智能調整，自動選擇最優路徑。
其次服務的註冊、發佈和編排也是SOA實現服務重用性的基礎。在Apusic ESB的服務倉庫中，任何符合標準的服務都可以在其中註冊，從而被其他服務調用。而消費服務也無需知道被調用服務的具體特徵，只需要發送相應地請求即可找到相應的服務，並進行綁定和數據的傳輸。
此外，Apusic ESB在引擎級別將BPEL規範的細節進行了包裝，對用戶來說，只需要關心流程中的一個服務即可，無須再去關心BPEL的具體技術細節。
最後，所有的調用、轉換都必須有一個良好的管理工具來幫助實施，並進行監控。Apusic ESB則提供了一體化的管理工具，通過這些工具，您可以非常方便的對Apusic ESB進行集中式管理、可視化的流程設計，以及運行期的實時監控等功能。
ESB其實只是技術
SOA項目不應從ESB開始
ESB在SOA中的重要作用，使得各個SOA廠商紛紛推出自己的ESB產品，並在具體的SOA實施中，利用ESB來作爲切入點，並簡化SOA的複雜性。
但是這種對ESB的重視正在使SOA的實施進入迷途。因爲ESB只是技術手段，而SOA的目標則是業務價值。對技術手段的過分重視往往使人們忽略了SOA的最終目標，陷入在技術的泥潭當中不能自拔。同時ESB的簡化掩蓋了SOA的複雜性，使大家對SOA的實施過分盲目樂觀，忽略了除了技術以外其他很多更重要的因素。
針對這種錯誤傾向，IBM WebSphere SOA與J2EE顧問Bobby Woolf最近寫了一篇文章《以ESB爲中心的架構是實施SOA錯誤的途徑》來質疑這種把ESB當作SOA的實現基礎的做法。Bobby Woolf在文章中提到，很多客戶在開始建設SOA時要求先爲他們建立一個ESB，他們拋棄了SOA的理念而只對ESB感興趣。“這些客戶在ESB和SOA之間劃了一個等號，或者更準確地說建設SOA就必須建設ESB。”毛新生指出了這種錯誤的根源所在。
因此以ESB來啓動一個SOA項目是有害的，它將陷入技術的怪圈中，而無法產生最大的業務價值。毛新生認爲業務才應該是SOA開始的起點和最終的目標。“你首先要在業務上進行服務的分解，然後才把他們映射到技術實現中。”毛新生說。
SOA項目的實施必須從業務需求的分析開始，而不是從構建ESB來開始。倪曉兵對這種觀點也表示支持，“SOA框架體系下的軟件開發，應該是從業務流程分析開始的，用一些組件化的業務建模方法，對實際的業務場景進行分析。在這個基礎上建立業務用例，並根據這些業務用例構造業務流程模型。”
倪曉兵同時強調:“ESB不過工具和技術而已，關鍵上集成業務如何做?業務邏輯如何編制?如何實施?金蝶不僅提供產品,還能提供一套實施方法論。針對簡單集成業務，提供標準知識集，也就是工具包，SI馬上就可以用，針對複雜業務，我們提供一套方法論，金蝶的六步實施法，可以加速實施過程”。
引入ESB的最佳時機
我們既然不能從ESB來開始一個SOA項目，那麼應該在項目的什麼時候引進這個重要的工具呢?Accenture首席技術官Don Rippert認爲激活SOA的全部潛力需要通過四個階段，依次是使用XML，以更標準的方式使用應用程序接口;捕獲一些業務過程，並將它們轉化成爲Web服務;引入並全面使用企業服務總線;產生業務過程執行語言(Business Process Execution Language，BPEL)，它可由業務過程建模工具完成。
在這四個階段，ESB的採用則位於第三階段中。同時他認爲當前大多數的企業還只是處於第一個階段，因此ESB實際上對於他們來說並不是迫切需要的。
Burton Group的分析師Anne Thomas Manes的觀點與Rippert相似，他認爲要採用ESB，必須首先實現啓動SOA的基本組件，這些組件是一個或多個服務平臺(如.NET，Java EE應用服務器等)，SOA管理解決方案，註冊表，另外如果服務要被暴露在防火牆之外，那麼需要XML網關。
她說:“如果缺少我推薦啓動SOA的‘基本組件’，ESB將不會列在我的清單中。事實上，我並不鼓勵人們由ESB開始。ESB並不會鼓勵好的SOA行爲。ESB本質上是集成系統，而非SOA系統。”並且她認爲ESB應該在後期購買。
毛新生認爲，做SOA的事情不要先上來建立一個大而全的ESB，相反是關注你的業務問題，找到用SOA的方法來解決業務上的需求，在解決這個問題的過程當中，你會看到一系列的業務服務。這些業務服務是會產生業務價值的。它可以靈活地組裝，動態地解決你變化的業務需求。這是它的價值，只有這樣才能使你的業務敏捷起來，隨需應變起來。而在服務的組裝過程中，你再去考慮利用ESB來把他們連接起來。
需要注意的是，這並不是否認ESB的價值。ESB是好的，單純的ESB項目是壞的。讓架構圍繞服務，而非總線。
同時爲了滿足具體的業務需求，不同的服務需要被組裝在一起形成新的應用系統。Apusic ESB引入了工作流流程的概念，引入自主實現且基於業界標準的，具有條件分支和合並並行流轉功能的BPEL4WS流程引擎，從而實現綜合的、複雜的業務邏輯編排。這個流程引擎支持子流程、條件腳本、路由節點等功能。通過靈活的流程定義，按照即時的業務需求，將單個離散服務有機的組合起來，達到服務重組的目的，完成集成的業務需求。