ESB在SOA體系中的功能定位

企業服務總線（Enterprise Service Bus，ESB）在現代IT領域可以說一個炙手可熱的名詞。随着SOA程序的推進與落地，ESB的關鍵性更進一步的得到了廣泛的認可。廠商，媒體從各種角度對其進行诠釋。各個商業軟體廠商以及開源社群也紛紛推出各自的ESB産品。然而我們發現，廠商，媒體對ESB的解釋，以及具體ESB産品的功能定位有着相當大的差異。這種現象在某種程度上困惑着IT人士：ESB的核心功能，尤其是其在SOA體系中應當扮演的角色是什麼？

在本文中，我願意和大家分享交流我們作為SOA支撐産品提供者和SOA解決方案提供者對于在SOA體系中ESB的功能定位的了解。

本文第一和第二部分着重描述在SOA體系中，ESB這一概念層次應有的功能定位，第三部分結合目前業界相關ESB産品的功能，介紹這些産品的功能和SOA中ESB層的功能定位的關系。

1、ESB核心功能——中介代理

在SOA體系中，ESB被當作一個內建平台來将企業各種各樣的軟體資産服務化。這種服務化即将各種各樣的私有技術以現代開放，标準的形式暴露為服務供SOA體系中的更高層次（如業務流程管理BPM）使用。

本質上說，SOA需要ESB為服務提供者和消費者之間提供中介服務。ESB作為服務提供者和消費者之間的中介，能夠對服務消費者屏蔽提供者位置，協定等技術細節，進而在有多方參與的企業應用內建場景下能夠更加靈活并能适應變化的內建服務的調用方與提供方，比如，提供者位置（end point）變化時對服務消費者完全透明。而且，ESB也常常充當服務內建的統一平台，在其上統一多個被內建方的調用協定，通訊方式以及消息語義（統一消息模型），使得其上層（North bound）服務調用者如BPM流程可以以單一且一緻的語言與下層（South bound）實作各種各樣的會話。

圍繞這中介代理這一核心功能，ESB應該具備的具體能力有：

    (1)完善的服務元件模型，包括服務元件的程式設計模型

   ESB應該提供定義統一，明确的服務元件模型，所有軟體功能都被封裝成服務元件。隻有這樣才能夠實作服務之間的松耦合組裝。

    (2)松耦合連結服務調用者與提供者的組裝模型

   ESB應該提供獨立的服務調用者與提供者的松耦合組裝模型。這裡“獨立”，“松耦合”指服務調用者與提供者的連接配接關系完全由組裝模型定義，對于調用者與提供者的内部實作邏輯完全透明。

 為了實作調用者與提供者的具體連接配接關系對服務實作透明，消息路由，服務提供者尋址（包括分布式服務尋址），以及必要的資料轉換，資料填充，同步/異步通訊模式轉換等中介功能需要由ESB的組裝模型提供而不需要調用者與提供者實作邏輯關心。

    (3)支援多種接入方式，通訊協定轉換。

  包括對服務調用者提供多種調用協定，以及能夠連接配接使用各種私有傳統接口的服務提供者。

2、ESB擴充功能

作為SOA體系的支撐平台，ESB将成為整個架構中核心的服務使能者（Service Enabler）。是以需要ESB在提供核心中介服務的基礎上，具備下面的擴充功能特性：

(1)安全——ESB需要提供認證，授權，加密等安全功能保證ESB上的服務被安全的調用，以及ESB可以以服務提供者需要的安全機制調用提供者。

(2)與服務注冊庫的無縫內建——可以有效的使用服務注冊庫提供的服務管理功能。

(3)簡化開發，部署的能力——如提供圖形化的開發工具，集中的提供分布式部署能力的部署工具等。

(4)監控與管理——提供必須的ESB運作時監控與管理能力。

(5)高性能，高可靠性——ESB需要是一個高性能服務中介引擎，同時必須提供足夠的高可靠性保障機制。

3、ESB産品的服務編排與EAI

最後一點想要說明的是，從ESB的發展曆史看，ESB并不是天生和SOA密切相關的，他反而更多的是由企業應用內建（Enterprise Application Integration，EAI）的需求發展而來。從EAI的角度來看，将各個軟體功能通過ESB的中介封裝成服務顯然是不夠的，它一般還需要将這些服務按照一定的業務邏輯編排起來進而實作完整的EAI功能，如資料的整合，交換功能等。是以，我們看到，目前相當一部分的ESB産品同時提供（和BPM相比相對簡單但高效的）服務編排功能，為松耦合但需短時間自動執行的服務編排流程提供了技術實作方案。

ESB産品提供更多的功能當然是好事。但我們想要指出的是，具體ESB産品的功能範圍不應該影響SOA對ESB本質功能需求的了解，進而混淆ESB在SOA中的定位。從SOA體系的層次結構來看，我們願意給ESB設定一個相對狹義的功能範疇，即ESB隻為SOA上層構件提供透明的，标準的下層功能實體的服務化封裝。而将封裝好的服務進行業務編排進而實作各種業務內建功能是SOA體系中ESB之上的構件實作的，其中可以是BPM，各個ESB産品的服務編排功能等等。

雖然如前所述，對服務進行編排實作各種業務內建功能從層次上來說不建議是SOA中的ESB的功能要求，但在這裡不妨補充說明一下這種業務內建功能的具體實作方式。

理論上說，基于ESB封裝的服務的編排可以以任何方式實作。實際應用中，我們看到大緻有三種實作方式，即使用業務流程管理（BPM）引擎實作，使用某些ESB産品自身的編排能力，以及使用自定制的方式編排內建流程。

BPM方式的優勢在于：在業務服務已經被封裝并能被業務人員了解的前提下，BPM提供業務人員可以了解駕馭的圖形化模組化手段來編排各種業務服務構成新的标準化的業務流程。BPM的引入可以有效的提升業務人員對IT系統的參與，進而實作業務主導的內建應用快速開發和随需應變。同時，BPM實作目前已經有成熟的标準支援，使用BPM實作的內建功能實作對具體産品的依賴相對較低。是以，BPM是業務層面應用內建的有力支撐技術之一，在有人工介入的長時間流程方面，其更是唯一的選擇。但另外一方面，BPM實作的內建應用在運作效率方面則不如另外兩種編排方式。

使用ESB産品服務編排功能的方式的優勢在于可以提供短時間自動執行的服務編排流程的高效執行，但這種編排功能往往是各種ESB産品自己的特有功能，缺乏标準的支援，是以基于ESB産品內建功能實作會比較依賴于具體的ESB産品。這種方式實際上自定制實作方式的一種特例，差别是編排功能不是由應用內建系統的建構者提供而是由ESB産品供應商提供。

自定制實作方式能最直接，高效的精确實作業務內建流程，但其缺點也是顯而易見的：定制開發的複雜度，難以持續功能擴充，随需應變。是以僅适用于特殊的內建需求的場景。