ESB是企業服務總線(Enterprise Service Bus)的縮寫,是中間件技術與Web Service等技術結合的產物,也是SOA系統中的核心基礎設施。ESB就是一個服務的中介,造成服務使用者->ESB服務Proxy->服務提供者的生物鏈,中介的做用在不一樣應用中各有不一樣:
html
從上面能夠看到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 功能
通訊 |
集成 |
|
|
服務交互 |
|
|
|
請注意這些最低功能並不須要使用特別的技術,好比 EAI 中間件、Web 服務、J2EE 或 XML。這些技術的使用很是接近也很是符合需求,可是沒必要強制要求使用它們。相反,最低功能幾乎只需簡單地使用 SOAP/HTTP 和 WSDL 就能夠實現(固然不是全部的狀況都這樣):
然而,這些 SOAP/HTTP 和 WSDL 的基本應用只是點到點(point-to-point)的集成,並不能實現一些 ESB 須要的關鍵功能:
固然,在許多甚至是大多數情形中每每須要其餘的功能,而且這種須要變得愈來愈常見。特別地,不論是如今仍是之後,下面的需求類型可能會致使更復雜高級的技術的使用: