你可能是一家集團企業的CIO，爲了維持企業業務正常運轉，你已經部署了幾個，十幾個，甚至是幾十個不同的IT系統。這些IT系統在運行初期，爲提升企業的執行效率發揮了很大的作用，但隨着業務內容的不斷深入，你發覺這些業務系統之間是離散的，是孤立的，你希望將這些系統進行整合。更進一步的，你盼望有一種神奇的魔力，不僅能夠有效整合遺留系統，新建的IT系統也能夠在這種魔力下獲得一體化的支持，而你所掌管的IT系統能真正做到隨需應變，按需擴充。
你也可能是一家IT公司的CTO，你所帶領的團隊正在開發一種新的IT應用，你渴望用SOA理念來指導這個新應用的架構設計，但你又不知如何才能使SOA落地；你被灌輸了太多的SCA、SDO、BPEL等等的標準與規範，但你卻不知道這些標準與規範又該如何運用到具體的項目；你也同樣希望有一種神奇的魔力，能夠讓你的團隊多年積累下來的業務邏輯形成跨基礎架構、跨技術平臺的真正可重用的組件庫，而這些組件庫在流程編排下形成具體的功能模塊，解決具體的業務場景。
那麼，你找到問題的解決方案了嗎？我有個主意，它叫ESB，它能讓你的SOA真正落地。
真是這樣的嗎？別急，先讓我們來了解一下ESB的前世今生......
真是這樣的嗎？別急，先讓我們來了解一下ESB的前世今生......
企業集成軟件的發展史
在企業信息化進程的最初，一個應用軟件的使用範圍可能僅限於某一個部門或某一種業務，由此而導致的情況是：一個大型的企業可能存在多個大小不一且支撐技術不同的應用軟件系統，這些系統可能基於不同的編程語言，運行在不同的硬件上，有着不同的系統平臺。但隨着企業的壯大，業務的發展，部門和部門之間的關鍵路徑和業務接口逐漸增多，各個應用軟件之間的信息交互也越發頻繁，同時，企業與上下游合作伙伴之間，數據共享、流程整合的需求也不斷催生，在這樣的背景下，企業應用集成軟件應運而生。至今爲止，企業集成軟件的發展，可以分爲三個階段：
基於標準協議的代碼定製
這是最初出現的集成軟件。一個業務系統和另一個業務系統直接通話，業務接口採取定製代碼的方式，通過一些標準的協議，例如Http、Ftp等，緊密的集成在一起。這種集成方式的缺陷不言而喻：缺乏可靠的數據傳輸保障；系統毫無彈性可言；數據交換時雙方必須同時在線；部署模型是非常複雜混亂的網狀結構等等。
基於消息的代碼定製
基於消息的異步編程模型，則爲企業集成提供了一種新穎的解決方案。傳統的消息中間件，能夠有效解決數據傳輸的可靠性、穩定性與安全性，並且，消息提供的異步編程模型，避免了集成雙方必須同時在線的問題，於是，人們在原先方式中的數據載體由通過標準協議，換成基於消息，大大提高了數據的可靠性，以及部署上的分佈性。但是缺點還是同樣明顯：路由邏輯和業務邏輯沒有分離，系統基本沒有擴展性，部署上還是網狀結構等等。
集線器模式
集線器模式在基於消息的基礎上，引入了“前置機-服務器”的概念，使用一種集線器/插頭（hub-and-spoke）的架構，將消息路由信息的管理和維護從前置機遷移到了服務器上，巧妙的把集成邏輯和業務邏輯分離開來，大大增加了系統彈性。由於前置機和服務器之間不再直接通信，每個前置機只通過消息和服務器之間通信，將複雜的網狀結構變成了簡單的星型結構。
集線器模式在企業集成的過程中取得了很大的成功，但是集線器模式的模型自身存在不足：中央服務器的存在導致部署上無法分佈開來，同時，中央服務器承擔了太多的工作和責任，往往會帶來壓力瓶頸以及硬件投資上的鉅額付出。隨着基於集線器模式的EAI系統的廣泛使用，更多的不足逐漸暴露出來：
1、 集成的各方之間，依然是一種緊密耦合的方式，一方所暴露的業務接口，只能在當前的集成環境下使用，無法提供可複用的業務價值。
2、 業務系統之間的協議都是基於消息的，有時候很難跨越企業的防火牆。
3、 當集成的需求越來越多的時候，不斷添加的功能使得集成系統日趨龐大，缺乏靈活性且難於管理。
那麼有沒有一種更好的架構可以解決這些問題，並且能夠在完成企業集成的同時，帶來更大的業務價值？
下一代的企業集成解決方案：Enterprise Service Bus
當人們正在爲集線器模式的企業集成架構所表現的不足尋求解決方案時，SOA的思想被提出來了。
劃時代的體系思想：SOA
SOA（Service-Oriented Architecture），指的是面向服務的架構，意指將軟件按照功能設計成一個個獨立封裝、支持異步處理的服務，這些服務用標準的方式定義接口，並可以通過標準的協議進行調用。重要的一點是，SOA所定義的接口和調用方式是獨立於編程語言和運行平臺的。
服務
SOA
SOA的思想試圖定義一個業界都“認可”、都“遵循”的法則，大家都使用同樣的方法來進行互通互聯，從而實現***限的“聯通”和最大可能的複用。
SOA是一個具有非常意義的體系思想，是所有軟件人員的一個夢想：將中間層再進行抽象，通過一個跨技術架構的元數據和業務邏輯，也就是服務，使之成爲可跨企業使用、能夠長期積累、並不斷豐富的企業業務庫和信息資產。誇張一點說，如果所有軟件開發都遵循SOA，那麼世界軟件業將會發生徹底的改變。
但是，SOA思想誕生時，它並不是一個技術標準，也沒有相關規範。如何在技術體系上實現SOA？Web服務在這個恰當的時候恰當的出現了。Web服務使業務邏輯能夠以標準化的接口（WSDL）提供，並可基於標準化傳輸方式（HTTP、Message等）、採用標準化協議（SOAP）進行調用。這爲SOA的實現提供了可能。
向ESB發展
ESB（Enterprise Service Bus），企業服務總線，作爲下一代的企業集成技術，巧妙的將總線集成和SOA思想結合起來。ESB 是一項允許開發人員集成異構系統的技術，同時ESB不再面向定製出來的業務接口，它面向的是公共服務。ESB爲服務提供者和服務消費者之間的集成提供了一個平臺，相對集線器模式的集成系統，具有更有效、更靈活的內部體系結構。
ESB是面向服務的，而服務是基於標準的，例如Web服務，這使得ESB具有屏蔽異構系統平臺差異的能力。由於服務本身的獨立封裝、可以隨意插拔，各式各樣不同的服務可隨時註冊到總線中，形成面向服務的組件庫，所以，ESB天然就具備很好的擴展性。同時ESB採用了輕量級的分佈式體系，可以將更多的處理邏輯分配到多個的端點上，中央服務器不復存在，業務邏輯處理能力及系統壓力可靈活調配。
ESB是服務提供者和服務消費者之間的橋樑，同時也是服務提供者和服務消費者之間的中介代理，可以提供多種不同的增值服務，帶來更多的業務價值。
ESB支持數據處理流程，這些數據處理流程可以是一些簡單的路由規則，也可以是功能強大的流程引擎，例如BPEL。這些流程的作用域在邏輯上可以是一個部門內，也可以是多個夥伴企業之間，而在物理拓撲上，可以是跨區、跨國、跨洲，甚至可以是休斯敦和阿波羅飛船之間。
ESB支持數據轉換，它已經屏蔽了異構系統之間的平臺差別，同時還能屏蔽異構系統之間的同種語義的數據差別，就象翻譯能把中文翻譯成英文一樣，ESB可以把一個系統的業務數據根據規則翻譯成另一個系統能夠識別的業務數據。
幾種集成方式之間的比較
從圖中可以看到，ESB處於最右上方，一個 ESB 架構形成了一個消息集線器和集成服務的互通網格，具有一個徹底分佈的集成網絡的功能性和智能性。