ESB簡介
ESB(Enterprise Service Bus)是支持系統間連接(Control & Service Flow Coordination), Messaging(Connection), 轉換/路由(Mediation), Web Service等的標準的接口，是構成SOA的解決方案。
系統除去了應用程序間直接的Point-to-Point式連接關係，通過ESB來構建應用程序間間接的連接關係並確保了Service Broker，即最小化了因各個應用程序變動所帶來的影響。但是在此過程中，服務呼叫會帶來一些性能的低下。但是在這裏這種問題得以解決，即在同一平臺上通過服務接口公開服務而在實際服務的構建時是通過Micro Flow來組合了組建或者單位模塊。ESB爲了分散服務組建的集成，與Process Manager傳送遵循自身標準的消息並支持基於流程的整合管理。
提供這些功能，ESB成了SOA構架上的中間層即構建Service Orchestration Layer的核心因素，模仿ESB的諸多相關產品涌入市場。Forrester根據這些供應商的設立和產品信息分爲ESB專業供應商、基於EAI的供應商、基於平臺的供應商等。ESB專業供應商提供的產品忠誠於Web Service或者ESB的原本功能和標準，是最初邁出ESB市場的供應商。基於EAI的供應商不僅提供之前EAI(Enterprise Application Integrator)供應商整合中心的BPM中心的產品還提供ESB功能。基於平臺的供應商以自家公司平臺解決方案爲中心的BPM解決方案並應用與ESB或者進行另外的產品化的供應商。
ESB的特點
要支持SOA，ESB需要具備幾個特點。遵循標準接口的消息傳送和應用程序間的關聯較小的(LooselyCoupled)狀態下，可以進行聯動並利用獨立的應用程序來開始、停止、重新啓動流程。UpRight的UPESB則在支持SOA的構架上接軌高性能的引擎構造並支持各種流程模式，具有優秀的擴展性。
ESB的應用範圍
SOA和ESB是持續發展的領域。因此可對ESB的定義和應用範圍產生混亂或者誤解。隨着ESB的應用範圍越加廣泛，越來越難以真正理解ESB。例如，ESB的作用不僅是目前的EAI，之後還會包含BPM的部分領域，在服務管理方面等會添加比目前想象的更多功能。
下圖展示着從傳統的EAI通過ESB擴展到BPM的發展方向。
如果一個系統的業務速度並不重要而且編成的修改量又少，則SOA的引進則無太大意義。即不需要引進SOA並對企業業務的所有功能進行服務化。
在這裏可以提到一個問題，引進SOA是否所有的服務都要通過ESB來進行呼叫。ESB是在互不相同的環境下以標準方式提供可複用的環境，保證系統的擴展性、安全性、可用性。SOA的使用就是從ESB開始的。如果服務前端(front-end)直接呼叫特定服務，則不能嚴格保證ESB所提供的標準化、可複用性、擴展性、安全性、可用性等。同時，ESB還整合管理各服務的接口。如果一些服務是通過ESB呼叫而另一些服務是直接被呼叫，則服務前端提問服務的位置信息的目的地爲多個並且服務的物理位置包含與代碼，因此每次服務位置有變動時都要修改編成代碼。
概括來說ESB承擔整個服務的有關管理和Orchestration，纔算正確構建SOA。在Business Process Layer上運行的BPM也需要能與ESB整合的構造，這與Service Orchestration Layer上運行的ESB不同。原因是因爲BPM和ESB都重複使用基於流程的技術，如此分離的構造會伴隨着功能上的問題。
在ESB平臺上引進BPM解決方案並支持各種服務、BPM、EAI、BPM、EAI、規則、Web Service 是有效率的。