本文將 ESB(企業服務總線) 描述為由中間件技術實現并支持 SOA 的一組基礎架構功能。ESB 支持異構環境中的服務、消息，以及基于事件的交互，并且具有適當的服務級別和可管理性。為了達到此目的，需要將多種功能集中起來并加以分類。然而，并不是 ESB 能夠傳遞值的每一種情形都需要所有的功能。
IBM認為，為了實現 SOA，應用程序和基礎架構都必須支持 SOA 原則。啟用 SOA 應用程序涉及到創建服務接口，服務接口可以直接也可以間接地通過使用適配器用于現有的或新的功能。從最基本的級別來看，啟用該基礎架構涉及到規劃功能來將服務請求路由和傳遞給正確的服務提供者。然而，基礎架構支持在不影響服務的客戶端的情況下由另一個服務實現替代原有的服務實現也是至關重要的。這不僅需要根據 SOA 原則指定服務接口，而且需要基礎架構允許客戶端代碼以獨立于所涉及的服務位置和通信協議的方式來調用服務。這樣的服務路由和替代是 ESB 的許多功能中的一部分。
ESB 支持這些服務交互功能，并通過提供集成的通信、消息傳遞以及事件基礎架構來支持這些功能。因此，它將當今正在使用的主要企業集成模式組合成一個實體。ESB 為 SOA 提供與企業需要保持一致的基礎架構，從而提供合適的服務級別和可管理性、以及異構環境中的操作。
本文剩余部分將討論 ESB 在 SOA 中的角色，包括除了基本的路由和傳輸以外，它所提供的的功能，如下面的 ESB 功能模型部分中所述。
ESB 結構ESB 有時被描述為分布式基礎架構，這與其他的解決方案形成了對比，比如消息代理技術一般被描述為中心輻射型（hub-and-spoke）。然而，這并不是真正的差別。有兩個不同的問題正被研究：控制的集中和基礎架構的分布。ESB 和中心輻射型（hub-and-spoke）解決方案都集中控制配置，比如服務交互的路由、服務命名等等。同樣，這兩個解決方案可能部署在簡單的集中式基礎架構中，也可能采用更復雜的分布式方式進行部署。
毫無疑問，不同的技術對它們所支持的物理部署模式有不同的約束--有些可能適合于非常廣泛的分布，以支持在很大的地理范圍內進行的集成，而其他的可能更適合于部署在本地群集中，以支持高可用性和擴展性。使物理分布需求與候選技術的功能相匹配是 ESB 設計的一個重要方面。另外的一種能力也是非常重要的，就是以增量方式擴展最初的部署來反映不斷變化的需求、集成附加的系統或擴展基礎架構的物理范圍。
還應該在 SOA 基礎架構中 定位ESB 與其他組件之間的關系，特別是與 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 這些組件之間的關系。由于上述 SOA 原則對這些組件并沒有嚴格的要求，所以可以將它們視為可選組件。
ESB 需要某種形式的服務路由目錄（service routing directory）來路由服務請求。然而，SOA 可能還有單獨的業務服務目錄（business service directory），其最基本的形式可能是設計時（design-time）服務目錄，用于在組織的整個開發活動中實現服務的重用。Web 服務遠景在業務服務目錄和服務路由目錄的角色中都放置了一個 UDDI 目錄，因而使得可以動態發現和調用服務。這樣的目錄可以視為 ESB 的一部分；然而，在這樣的解決方案變得普遍之前，業務服務目錄可能與 ESB 是分離的。
Business Service Choreographer 的作用是通過若干業務服務來組合業務流程；因此，它將通過 ESB 調用服務，然后再次通過 ESB 將業務流程公開為客戶端可用的其他服務。然而，Business Service Choreographer 在編排業務流程和服務中所扮演的角色確定了這種業務工作流技術是一種與基礎架構技術 ESB 分離的技術。
最后，B2B Gateway 組件的作用是使兩個或多個組織的服務在受控且安全的方式下對彼此可用。這有助于查看這些連接到 ESB 的組件，但它們并不是 ESB 的一部分。雖然有一些網關技術可以提供適合于實現 B2B Gateway 組件和 ESB 的功能，但是 B2B Gateway 組件的用途是將其與 ESB 分離。事實上，這種用途可能需要附加的功能（如合作伙伴關系管理），這些功能不是 ESB 的一部分，并且不一定受到 ESB 技術的支持。 |