ESB企業服務總線

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 功能

通訊	服務交互
路由 尋址 通訊技術、協議和標準（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS） 發佈/訂閱 響應/請求 Fire-and-Forget，事件 同步和異步消息傳遞	服務接口定義（例如，Web 服務描述語言（Web Services Description Language，WSDL）） 支持替代服務實現 通訊和集成所需的服務消息傳遞模型（例如 SOAP 或企業應用程序集成 (EAI) 中間件模型） 服務目錄和發現
集成	服務質量
數據庫 服務聚合 遺留系統和應用程序適配器 EAI 中間件的鏈接性 服務映射 協議轉換 應用程序服務器環境（例如 J2EE 和 .NET） 服務調用的語言接口（例如 Java 和 C/C++/C#）	事務（原子事務、補償、Web 服務事務（WS-Transaction）） 各類肯定的傳遞範例（例如 Web 服務可靠消息傳遞（WS-ReliableMessaging）或對 EAI 中間件的支持）
安全性	服務級別
身份驗證 受權 不可抵賴性 機密性 安全標準（例如 Kerberos 和 Web 服務安全性（WS-Security））	性能 吞吐量 可用性 其餘能夠構成契約或協定的持久評估方法
消息處理	管理和自治
編碼的邏輯 基於內容的邏輯 消息和數據轉換 有效性 中介 對象標識映射 數據壓縮	服務預置和註冊 記錄、測量和監控 發現 系統管理和管理工具的集成 自監控和自管理
建模	基礎架構智能
對象建模 通用業務對象建模 數據格式庫 B2B 集成的公共與私有模型 開發和部署工具	業務規則 策略驅動的行爲，特別是對於服務級別、服務功能的安全和質量（例如 Web 服務策略（WS-Policy）） 模式識別

上面的許多功能既可使用專有技術實現，也能夠經過利用開放標準實現。然而，使用不一樣的技術來實現 ESB 可能會使它們的性能、可伸縮性和可靠性這些特性顯著不一樣，同時 ESB 功能和所支持的開放標準也會有所不一樣。因爲這些緣由，再加上最近制訂和正在興起的一些相關標準，當今實現 ESB 的許多關鍵決策都涉及到成熟的專有技術和不成熟的開放標準之間的權衡。

支持 SOA 的最低功能的 ESB 實現

若是在前面肯定的功能中只有一部分和大多數 SOA 場景相關，咱們可能會問：實現 ESB 所需的一組最低功能由什麼構成？爲此，考慮最被廣泛認同的 ESB 定義的原理：

•  

   

   

   ESB 是一種邏輯體系結構組件，它提供與 SOA 的原則保持一致的集成基礎架構。

•  

   

   

   SOA 原則須要使用與實現無關的的接口、強調位置透明性和可互操做性的通訊協議、相對粗粒度和封裝可重用功能的服務定義。

•  

   

   

   ESB 能夠做爲分佈式的異構基礎架構進行實現。

•  

   

   

   ESB 提供了管理服務基礎架構的方法和在分佈式異構環境中進行操做的功能。

最低的 ESB 功能

通訊	集成
提供位置透明性的路由和尋址服務 控制服務尋址和命名的管理功能 至少一種形式的消息傳遞範型（例如，請求/響應、發佈/訂閱等等） 支持至少一種能夠普遍使用的傳輸協議	支持服務提供的多種集成方式，好比 Java 2 鏈接器、Web 服務、異步通訊、適配器等等
服務交互
一個開放且與實現無關的服務消息傳遞與接口模型，它應該將應用程序代碼從路由服務和傳輸協議中分離出來，並容許替代服務的實現。

請注意這些最低功能並不須要使用特別的技術，好比 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 概念，例如服務編排、目錄、轉換等等。

•  

  按需操做環境需求，好比管理與自治功能以及基礎架構智能功能。

•  

  跨越具備不一樣全部權的多個網絡、多個協議以及多個域的真正意義上的異步操做。