ESB是企業服務匯流排（Enterprise Service Bus）的縮寫，是中介軟體技術與Web Service等技術結合的產物，也是SOA系統中的核心基礎設施。ESB就是一個服務的中介，形成服務使用者->ESB服務Proxy->服務提供者的生物鏈，中介的作用在不同應用中各有不同：

解耦中介 ：客戶對實際服務提供者的身份、物理位置、傳輸協議和介面定義都是不知道也不關心的，互動整合程式碼提取到了業務邏輯之外，由ESB平臺進行中央的宣告式定義。ESB平臺實現協議轉換 (WebService，Http，JMS…)，訊息轉換 (轉換、充實、過濾)，訊息路由 (同步/非同步、釋出/訂閱、基於內容路由、分支與聚合…)。
服務中介 ：ESB平臺作為中介提供服務互動中的基礎服務。ESB平臺實現SLA (可靠性保證，負載均衡，流量控制，快取，事務控制，加密傳輸)，服務管理監控 (異常處理，服務呼叫及訊息資料記錄，系統及服務的狀態監控，ESB配置管理)，統一安全管理 (這個有點理想主義)。
服務編排 ：多個服務進行編排形成新的服務。ESB支援一個直觀的形式定義新組合服務的流程(工作流、BPEL 或 程式碼級編排)。
從上面可以看到ESB的基本功能仍然是資料傳輸，訊息協議轉化，路由三大核心功能。有這三大核心功能也可以看到在進行異構系統的整合時候往往根據需要ESB提供這些功能。沒有ESB時候也可以實現SOA，比如藉助SCA和BPEL來實現SOA，當時卻很難實現訊息協議轉化和動態路由。

ESB在發展過程中有從原有的訊息中介軟體轉化為ESB產品的，這類訊息中介軟體和資料匯流排產品在原有的EAI企業應用整合中應用比較多。而SOA根據強調了基於服務的整合，以Web Service服務為基本的管理單元。一個服務的定位是關於如何把業務邏輯表現成為一組相互獨立的，自描述的且能互操作的實體。

對於SOA關注的是服務全生命週期，通過服務實現業務價值。而ESB關注的是服務中介和服務的整合，是SOA的基礎設施。SOA有兩個核心元件，一個是ESB，一個是BPEL，而ESB是基礎設施，BPEL是業務流程驅動下服務的整合和整合。離開了SOA，ESB將失去它所連線的服務，而僅僅是一個匯流排，同時也將變得毫無價值。Bobby做了一個比喻：路是沒有任何價值的，除非你利用它把一個東西從一個地方移到另外一個地方。而離開SOA，ESB就像一個沒人使用的道路。

做SOA的事情不要先上來建立一個大而全的ESB，相反是關注你的業務問題，找到用SOA的方法來解決業務上的需求，在解決這個問題的過程當中，你會看到一系列的業務服務。這些業務服務是會產生業務價值的。它可以靈活地組裝，動態地解決你變化的業務需求。這是它的價值，只有這樣才能使你的業務敏捷起來，隨需應變起來。而在服務的組裝過程中，你再去考慮利用ESB來把他們連線起來。

ESB 需要某種形式的服務路由目錄（service routing directory）來路由服務請求。然而，SOA 可能還有單獨的業務服務目錄（business service directory），其最基本的形式可能是設計時服務目錄，用於在組織的整個開發活動中實現服務的重用。Web 服務遠景在業務服務目錄和服務路由目錄的角色中都放置了一個 UDDI 目錄，因而使得可以動態發現和呼叫服務。這樣的目錄可以視為 ESB 的一部分；然而，在這樣的解決方案變得普遍之前，業務服務目錄可能與 ESB 是分離的。
標準的 ESB 功能

上面的許多功能既可以使用專有技術實現，也可以通過利用開放標準實現。然而，使用不同的技術來實現 ESB 可能會使它們的效能、可伸縮性和可靠性這些特性顯著不同，同時 ESB 功能和所支援的開放標準也會有所不同。由於這些原因，再加上最近制訂和正在興起的一些相關標準，當今實現 ESB 的許多關鍵決策都涉及到成熟的專有技術和不成熟的開放標準之間的權衡。
支援 SOA 的最低功能的 ESB 實現
如果在前面確定的功能中只有一部分和大多數 SOA 場景相關，我們可能會問：實現 ESB 所需的一組最低功能由什麼構成？為此，考慮最被普遍認同的 ESB 定義的原理：
ESB 是一種邏輯體系結構元件，它提供與 SOA 的原則保持一致的整合基礎架構。
SOA 原則需要使用與實現無關的的介面、強調位置透明性和可互操作性的通訊協議、相對粗粒度和封裝可重用功能的服務定義。
ESB 可以作為分散式的異構基礎架構進行實現。
ESB 提供了管理服務基礎架構的方法和在分散式異構環境中進行操作的功能。
重點內容最低的 ESB 功能

請注意這些最低功能並不需要使用特別的技術，比如 EAI 中介軟體、Web 服務、J2EE 或 XML。這些技術的使用非常接近也非常符合需求，但是不必強制要求使用它們。相反，最低功能幾乎只需簡單地使用 SOAP/HTTP 和 WSDL 就可以實現（當然不是所有的情況都這樣）：

URL 定址和現有的 HTTP 和 DNS 基礎架構提供了一個具有路由服務和位置透明性的“匯流排（bus）”。
SOAP/HTTP 支援請求-響應（Request-Response）通訊規範。
HTTP 傳輸協議被廣泛地使用。
SOAP 和 WSDL 是開放、與實現無關的服務通訊和連線模型。

然而，這些 SOAP/HTTP 和 WSDL 的基本應用只是點到點（point-to-point）的整合，並不能實現一些 ESB 需要的關鍵功能：
目前還沒有用於控制服務定址和命名的管理功能。服務名稱通過每個介面卡單獨進行控制的，服務路由控制則分散在由服務客戶端呼叫的地址、HTTP 基礎架構和分配給介面卡的服務名稱之間。
雖然這種方法依賴於實現細節，但是它往往並不能使服務實現的替代變得簡單；服務請求者程式碼（也可能是開發工具生成的）通常通過特定地址 的特定協議直接繫結到具體的服務提供者實現。如果想要用另一個服務實現來替代原來的服務實現，就需要修改應用程式程式碼並重新部署這些程式碼。

當然，在許多甚至是大多數情形中往往需要其他的功能，並且這種需要變得越來越常見。特別地，不管是現在還是以後，下面的需求型別可能會導致更復雜高階的技術的使用：

服務質量和服務級別功能。
高階 SOA 概念，例如服務編排、目錄、轉換等等。
按需操作環境需求，比如管理與自治功能以及基礎架構智慧功能。
跨越具有不同所有權的多個網路、多個協議以及多個域的真正意義上的非同步操作。