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 概念，例如服務編排、目錄、轉換等等。
•  按需操作環境需求，比如管理與自治功能以及基礎架構智能功能。
•  跨越具有不同所有權的多個網絡、多個協議以及多個域的真正意義上的異步操作。