企業服務總線

面向服務的體系結構已經逐漸成為IT集成的主流技術。面向服務的體系結構(service-oriented architecture，SOA)是一種軟件系統設計方法，通過已經發布的和可發現的接口為終端用户應用程序或其它服務提供服務。

SOA把IT架構分為組件層、Web服務層、業務流程層等。組件層包括各種應用組件，它們通常是技術相關的具體實現，各種具體的分佈式組件技術(CORBA、COM/DCOM、J2EE)都可以用於實現組件層的應用組件。通常複雜的IT環境中的組件層都同時使用了多種分佈式組件技術，而不同實現技術之間的互聯性障礙給應用集成帶來了極大的困難，進而形成了一個個信息孤島。SOA引入了Web服務層來解決此種情況下的應用集成問題。Web服務是獨立於各種分佈式組件技術的，它使用標準的基於XML的服務描述語言(Web Service Description Language，WSDL)來定義和封裝離散的業務功能，各種支持Web服務的分佈式組件技術能夠將其上的業務組件發佈成Web服務併產生相應的WSDL文檔，並且只需要依據WSDL描述的信息就能夠調用Web服務，即WSDL所描述的業務功能。Web服務在系統集成方面得到了廣泛的應用。在SOA中，需要進入系統集成環節的業務組件都被映射為Web服務，形成了Web服務層。業務流程層則處於Web服務層之上，通過對Web服務的流程編排來實現商業流程。業務流程層通過Web服務層能夠調用到基於各種分佈式組件技術實現的業務組件，實現了複雜IT系統環境的應用集成。

在SOA的組件層、Web服務層、業務流程層三層模型中，組件層使用具體的分佈式組件技術實現業務功能，Web服務層則為組件層提供了一種技術無關的通用訪問方式，屏蔽組件層具體技術之間的差異，突出業務邏輯的封裝性。組件層中的業務組件和Web服務層的Web服務構成了企業IT架構的主要可重用部件，它們應該保持相對的穩定，業務流程層則通過對服務進行編排，來適應業務需求的變化。將組件層的業務組件映射為Web服務層的服務是成功實現SOA的關鍵步驟，目前對於特定的業務組件，業界廣泛使用具體於分佈式組件技術內建的支持Web服務的功能來實現組件與服務的映射。這種映射方法高度依賴於具體分佈式組件技術本身，並且在使用和定製的過程中缺乏靈活性，當某個Web服務的實現需要多個分佈式組件技術中的業務組件實現時，這種映射方法就會無法支持 ^[1]  。

企業服務總線(EnterpriseServiceBus，ESB)是構建基於面向服務體系結構(SOA)解決方案時所使用基礎架構的關鍵部分，是由中間件技術實現並支持SOA的一組基礎架構功能。ESB支持異構環境中的服務、消息，以及基於事件的交互，並且具有適當的服務級別和可管理性。簡而言之，ESB提供了連接企業內部及跨企業間新的和現有軟件應用程序的功能，以一組豐富的功能啓用管理和監控應用程序之間的交互。在SOA分層模型中，ESB用於組件層以及服務層之間，它能夠通過多種通信協議連接並集成不同平台上的組件將其映射成服務層的服務。

作為SOA基礎架構的關鍵部分，ESB的功能主要體現在通信、服務交互、應用集成、服務質量、安全性以及管理和監控等方面。在通信方面，ESB能夠支持消息路由/尋址，支持多種通信技術、通信協議(如JMS、HTTP)，支持發佈/訂閲的通信模式，能夠處理請求/響應、同步以及異步的消息傳遞方式，並且要求以可靠的方式傳遞消息。服務交互方面，ESB上所發佈的服務是以當前標準的Web服務描述語言(WebServicesDescriptionLanguage)來定義Web服務的，並且ESB上通常配備有服務目錄和發現機制。ESB的重要功能就是集成不同的系統，必須能夠支持多種接入ESB的方式(例如將ESB、WebService、CORBA以及使用Socket等方式訪問的遺留系統接入到ESB系統)，將接入的系統映射成Web服務。在集成不同系統的同時，必須考慮服務質量方面的問題，如事務性和消息傳遞的可靠性。對於關鍵的Web服務，ESB需要以加密的方式進行消息傳遞，並且必須驗證訪問者的權限。ESB軟件作為SOA基礎架構的一個複雜子系統，還必須配有相應的管理和監控功能，用於ESB軟件自身的系統管理、日誌記錄、測量和監控等。目前國內外對企業服務總線的研究都比較積極，IBM的ISV、BEA的AquaLogicServiceBus、開源的Mule、Sun領導的JBI規範草案等，都是企業服務總線的具體實現。但是這些公司的ESB實現都更關注於對自有品牌產品的支持，對如何集成更多分佈式組件技術考慮得不夠。

企業連接框架是企業服務總線的一種具體實現。該框架的首要目標是使用標準的開放的協議以及經過驗證的企業應用集成模式，將不同的應用程序系統集成起來。ESB連接框架定義了一系列構建，用於處理在集成不同系統時所涉及的通信、路由、服務交互等方面的任務。企業連接框架體系展示了使用該框架集成2個端對端的應用程序的連接方式。企業連接框架包含以下幾個部分：適配器，前置路由器，後置路由器，應用組件等。

適配器等價於EIP中的ChannelAdapter(通道銜接器)，用於連接應用組建與外部應用程序。適配器包括連接器、消息接收器/消息發送器、消息轉換器3個部分。消息接收器/消息發送器用於接收和發送消息，消息轉換器用於消息與組件所識別數據類型之間的數據轉換，連接器則用於維護外部應用程序與應用組件之間通信的會話。連接器是適配器的核心，用於管理消息接收器/消息發送器以及消息轉換器。對於消息接收器和消息發送器，連接器可以在其上定義接收端點和發送端點，用於指定該消息從哪兒接收或者發送到何處，如JMS的隊列名稱、HTTP的URL地址、pop3/smtp協議的郵件地址。同時，連接器使用消息轉換器將接收來的消息或者即將發送的數據進行轉換。企業連接框架對不同的通信協議提供相應的適配器，如HTTP適配器、JMS適配器、郵件服務適配器、TCP/IPsocket適配器，CORBA適配器、EJB適配器、COM/DCOM適配器、HTTP/SOAP(Web服務)適配器等。種類豐富的適配器確保企業連接框架能夠集成基於不同分佈式組件技術的業務組件。

路由器分為前置路由器以及後置路由器2種，分別用於應用組件處理消息前的接收路由和應用組件處理消息後的發送路由。通過前置路由器，應用組件可以接收來自不同適配器或者同一適配器不同接收端點的消息；通過後置路由器，應用組件可以將其處理結果發送到不同適配器或者同一適配器的不同端點上。路由器可以實現動態的、聲明性的、基於內容的以及基於規則的消息路由。通過消息路由，可以順序、選擇或者串聯地調用應用組件，實現EnterpriseIntegrationPattern中的消息路由模式。

應用組件是基於某種具體分佈式技術實現的業務邏輯模塊。通過路由器和適配器的連接，應用組件可以與其它應用組件或者外部應用程序交互。

外部應用程序可以是任何類型的應用程序，如Web應用程序、辦公自動化系統、應用程序服務器、業務流程執行引擎等。

使用企業連接框架能夠輕易地實現應用系統的集成，並可以將已有應用系統的功能作為應用組件，通過消息適配器和消息路由將應用組件自由組合形成Web服務，從而實現組件與Web服務的映射。使用企業連接框架進行組件與服務的映射可以加快開發速度，更好地重用已有系統的功能，同時能夠獲得更好的靈活性，降低系統維護的複雜度。根據業務需要，應用組件可以通過如下方式映射成Web服務：簡單映射，路由映射，複雜映射和鏡像映射等。

將一個組件映射成對應的Web服務：這是實現組件與Web服務之間映射的最簡單的一種方式。業務組件的接口正好與Web服務的接口相一致，直接為此組件配置HTTP/SOAP(Web服務)適配器，將其映射為Web服務(如圖1所示)。

通過路由機制，將多個組件通過路由組合成一個Web服務。對於某些Web服務，其業務功能的實現可能需要多個應用組件協作完成，如圖2所示。適配器使服務總線具備連接不同技術標準組件的能力，路由器則增強了這種連接的靈活性。通過路由器，各種應用組件可以靈活地組合起來，協同完成某項業務功能。路由器有前置路由器及後置路由器2類。前置路由器有：

後置路由器有：

1、總線基礎服務框架：提供系統一致性、安全性、可靠性，以及性能和擴展能力保障的基礎技術手段。

2、集成服務：提供基礎的集成服務與用户定製的應用服務；支持多種集成服務模式；支持服務的封裝、重用、服務組合、服務調度。

3、公用服務：提供內置的各種公用服務。例如，渠道認證服務，日誌服務等公用服務。

4、服務管理和服務標準：提供服務配置管理的前台工具集合，並提供行業的服務規約標準。

5、系統監控：提供多角度的系統實時監控與交易報表，提供用户定製的告警。

6、安全體系：提供多種安全機制並支持和第三方安全系統的有效集成，提供有效的安全監控機制。

1、可用性和可靠性

支持羣集物理部署來保證系統的高可用性，支持系統的長期穩定運行。

2、性能和可伸縮性

支持在達到系統性能指標峯值要求的同時，系統處理能力還能夠留有足夠的餘量。

3、擴展性和靈活性

支持系統擴展部署和多個邏輯單元的分離部署。提供對系統的維護與參數配置的管理功能。

4、安全性

提供安全認證和授權機制，提供不可否認和機密性，支持安全標準。

從理論上講，集中式 ESB 有可能標準化和大幅簡化整個企業中服務的通信及集成。 硬件和軟件成本可以共享，只需供應服務器一次，還可以指派單支專家團隊（必要時進行培訓）來開發和維護集成。

開發人員可使用單個協議與 ESB“對話”，併發出命令來指導服務間的交互，然後交給 ESB 轉換這些命令、路由消息並根據需要變換數據以便順利執行這些命令。 這樣，開發人員就不需要將大量時間用於集成，而是將更多的時間用於配置和改進應用程序。 由於能夠在不同項目之間複用這些集成，因此可以提高生產力並節省下游成本。

雖然有不少組織成功部署了 ESB，但在許多其他組織中，ESB 被視為 SOA 部署的瓶頸。 更改或增強某個集成通常會干擾到其他集成。 ESB 中間件更新通常會影響現有集成。 由於 ESB 是集中管理的，因此應用程序團隊很快就發現需要排隊等待集成。 隨着集成量的增長，ESB 服務器實現高可用性和災難恢復的成本變得更高。 作為跨企業項目，ESB 籌集資金較為困難，因而加大了相關技術難題的解決難度。

最終，維護、更新和擴展集中式 ESB 變得十分複雜且代價昂貴，以至於 ESB 經常會造成自身和 SOA 預期可得到的生產力效益遲遲無法實現，從而使期待鋭意創新的業務團隊感到挫敗。 ^[2]