企業服務總線（Enterprise Service Bus，ESB）的概念是從面向服務體系架構(Service Oriented Architecture， SOA)發展而來的。SOA描述了一種IT基礎設施的應用內建模型；其中的軟構件集是以一種定義清晰的階層化結構互相耦合。一個ESB是一個預先組裝的SOA實作，它包含了實作SOA分層目标所必需的基礎功能部件。
在企業計算領域，企業服務總線是指由中間件基礎設施産品技術實作的、 通過事件驅動和基于XML消息引擎，為更複雜的面向服務的架構提供的軟體架構的構造物。企業服務總線通常在企業消息系統上提供一個抽象層，使得內建架構師能夠不用編碼而是利用消息的價值完成內建工作。
企業服務總線提供可靠消息傳輸，服務接入，協定轉換，資料格式轉換，基于内容的路由等功能，屏蔽了服務的實體位置，協定和資料格式。
面向服務的體系結構（Service-Oriented Architecture，SOA）是一個元件模型，它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得建構在各種這樣的系統中的服務可以一種統一和通用的方式進行互動。
實作SOA架構的常用技術有Web Services，JMS和BPEL等。
ESB技術。企業服務總線（Enterprise ServiceBus，ESB）是建構基于SOA解決方案時所使用基礎架構的關鍵部分，是由中間件技術實作并支援SOA的一組基礎架構功能。它是一種為進 行連接配接服務提供的标準化的通信基礎結構。基于開放的标準，為應用提供了一個可靠的、可度量的和高度安全的環境，并可幫助企業對業務流程進行設計和模拟。對 每個業務流程實施控制和跟蹤、分析并改進流程和性能。目前各大IT公司都推出了基于自己的平台工具的ESB産品，如IBM的WebSphere ESB、BEA的AqusLogic Service Bus等。除此之外，也出現了衆多的開源ESB産品，如Mule、ServiceMix和Apache Synapse等。
web Services技術。Web Services主要是為了使原來各孤立的站點之間的資訊能夠互相通信、共享而提出的一種接口。該接口隐藏了服務實作的細節，允許通過獨立于服務實作、獨 立于硬體或軟體平台、獨立于編寫服務所使用的程式設計語言的方式使用該服務。Web Services可以通過HTTP、SOAP（XML）、SMTP等協定的組合被通路，利用标準網絡協定和XML資料進行通信，具有良好的普适性和靈活 性，這使得基于web Services的應用程式具備松散耦合、面向元件和跨技術實作的特點例5。Web Services技術的主要目标是在各種異構平台的基礎之上建構一個同樣的、與平台與語言無關的技術層，各種應用都可以靠這個技術層來實施彼此的連接配接和內建。
JMS技 術。Java消息服務（Java Message Ser．vice，JMS）是通路企業消息系統的标準API，是Sun公司提出的Java消息服務規範，是用于通路消息系統的不依賴于某個具體廠商的 API，它提供給應用程式建立、發送、接受和渎取消息的接口，具體實作可以不同。JMS技術采用異步通信模式，發送消息者将需要變更的資料消息送出到消息 平台後，就完成了自己的任務，就可以進行其他的操作。不需要等待伺服器端的消息處理結果。這時即使網絡出現故障甚至伺服器崩潰也不會造成資料的丢失或不一 緻，消息會儲存在消息隊列中直到被最終接收。
從下面的圖中來看SOA是實作架構：
圖：SOA部署環境圖
我們從下向上看：
Business Systems：最下邊也就是我們的業務系統，可以是ERP，可以是CRM也可以是OA等我們正在使用的業務系統。
Low Level Services：低層次服務，就是我們直接暴露出來并沒有經過加工處理的服務，比如說一個資料的抽取、一個業務子產品的管理，也就是比較細粒度的服務。
Composite Services：綜合服務，可以了解成更高層次的服務，因為接口暴露出來後并不是直接給應用程式調用或者是給其它服務使用，當然那樣也是可以的。我們對低層次的服務進行必要的封裝，形成高層次的服務，好處是顯而易見的，安全性、應用邏輯的封裝，必要的負載，也就是說，更高層次隻需要關心他需要的接口，至于如何實作，通過多少細粒度的服務完成這個不是它所關心的東西。
Orchestrated Business Processes：業務流程，也就是我們常說的BPM，有了上邊的解釋，這一部分就很清晰了，對于使用者來說，比如他通過網際網路交話費，他隻需要确認自己已經交成功就可以了，也就是說，頁面上有了相應的提示，OK，他就可以去做其它事情了，而下邊需要如何處理，怎樣走流程，就是按照BPM中設計好的流程執行。
ESB：從圖上看ESB放在了最左邊，也就是上面幾個應用的左邊，而且全部包含在内，那麼也就是說，ESB處理的就是各個層次之間的通信，包括路由、協定轉換和消息傳遞等。
Presentation Services：表示層服務，其實這個就很容易了解了，也就是我們對外暴露的接口或者服務内容，可以是一個jms、一個webservice調用、甚至是一個頁面。
當你的應用像下面一樣時，這個時候就需要考慮使用ESB了，如圖：
圖：未使用ESB的應用架構
各個應用系統之間的調用形成了一張網，沒有邏輯，随着業務的增加，維護簡直就是一場惡夢。
圖：使用ESB中介和代理之後
各個應用的邏輯很清晰，每個應用都隻需要關心如何暴露自己的服務，而調用的應用隻需要知道如何調用服務，至于怎麼做，去找誰，則完全交給ESB來完成。
以下是幾個比較流行且好用的開源的esb：
Mule ESB：MuleSoft是Mule ESB建立者。Mule ESB是一種廣泛的開源ESB下載下傳。
WSO2 ESB：WSO2 ESB旨在極端輕量型和可擴充性。它包括服務互動圖形編輯和XML支援。
Apache ServiceMix ESB：Apache Service Mix ESB以Java業務內建為标準為基礎，支援Spring。
所有的ESB産品都應該可以建構和部署服務。包括對遺留系統的整理、消息的路由、消息格式的轉換、執行協定的調解等。
首先我們要看ESB是否具有以下特性：
互通性
抽象化
資源位置的虛拟化
擴充能力和管理服務
是否具有平台無關性，即跨平台
松耦合
等。
上面列出的往往很評估，但是ESB本身具有的特性往往更容易識别和評估。
ESB所必須具備的功能：
路由
協定橋接
消息轉換
服務代理托管
擴充的功能有：
資源擴充卡
可靠的消息傳遞
事件處理
交易的完整性管理
消息格式調解
負載均衡
消息驗證
能力調解
其實，對于如何選擇本身就是一個跟業務相關的問題，以确定你是否選擇ESB以及選擇什麼樣的esb來滿足你的應用需求。
你選要內建三個或者更多的應用或服務嗎？如果你需要在兩個應用間通信，使用點對點內建更容易。
未來你真的需要插入更多的應用嗎？如果是需要的，那麼你可以選擇使用ESB。
你是否需要使用不止一種類型的通信協定？如果是多種協定，那麼可以選擇使用ESB。
你需要象分叉和聚集消息流或者基于内容的路由的消息路由功能嗎？許多應用不需要這些擴充。
你需要通過其他應用為消費釋出服務嗎？如果需要可以考慮選擇ESB。
你擁有多于10個的應用要內建嗎？如果需要可以考慮選擇ESB。
你真的需要ESB的可擴充性嗎？如果需要可以考慮選擇ESB。
以上僅僅是列出了想到的一些問題，具體的情況還需要根據具體的需求進行分析和處理，如果簡單的業務其實不必“大炮打蚊子”，畢竟合适才是最好的！
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)