1 緒論

1.1 企業應用整合的概念及重要性

隨著計算機軟體技術的發展和企業資訊化的不斷髮展，企業使用的軟體，如：ERP、財務管理，MIS和CRM等應用和管理系統也越來越多。雖然這些系統是應用在不同的領域，管理著不同的物件，但是它們之間也有很多相互交叉，甚至重複的資訊和資料。而各個應用系統又是相互獨立執行，因此企業內部的這些系統相當於一個個“資訊孤島”，相互之間沒有暢通的資訊交流與共享。這樣的後果是在企業中經常會出現資訊和資料的更新不同步甚至不一致，從而造成各個部門之間的矛盾，給企業中不同部門的人員在進行交流時帶來很多問題，給客戶也經常提供一些前後不一致的資訊，使客戶無所適從，嚴重影響企業的形象和信譽。另一方面是企業間的交流與合作的日益增加，協同商務和各種新的製造模式（如：敏捷製造，虛擬企業，信貸物流管理等）的需要和建立自己的企業資訊門戶等要求企業的應用系統是一個基於B/S

企業要解決這些矛盾，一種辦法是對現有系統推倒重來：將企業的各個資訊系統全部更新成一個統一的管理系統，各個部門都在這個統一的系統上工作，但考慮到成本、實施週期和難度因素，這不是一種切實可行的解決方案。另一種辦法是企業從整體來考慮企業的整個資訊系統，根據實際需要，對各個應用系統進行總體規劃，選擇一個合適的整合平臺，把企業的各個“資訊孤島”有機的整合起來。這種解決方案不管是從實施難度，還是從實施成本、週期和技術上考慮都是切實可行的。

EAI (enterprise application integration)

1.2 國內外研究現狀

在企業應用整合（Enterprise Application Integration，EAI）領域，企業一直面臨著削減成本和最大限度地利用現有技術的難題，在當前激烈競爭的環境下，一個成功的企業在IT構建上需要解決下列問題：

如何讓已有的多種應用系統無縫的整合起來，實現應用系統的快速構建，遷移和伸縮，以滿足不斷變化的市場需求。

與此相對應，EAI技術也在不斷的向前發展。EAI技術的發展歷史，可以從EAI產品的體系結構來說明。

定製連線，兩兩互連

最早期的EAI解決方案就是將企業中需要互通訊息，共享資料的系統兩兩橋接起來。橋接的技術也是為兩個特定系統專門定製通訊鏈路來轉換這兩個系統的介面，協議以及資料格式等差異，使用硬編碼來實現系統之間的點對點連線。這種方式，在有些特定情況下（比如很小規模的整合系統）可能會得到相對較高的效能。但整合規模稍複雜，這種方式程式碼量大，不可靠，無法維護等缺點就會顯露無疑。另外，全部使用專門為兩個特定系統定製的連線，在企業系統眾多的情況下連線急劇增加，難以開發，後期維護更加困難。由於這些專用連線完全互相獨立，其只能滿足系統兩兩互連通訊的需求，無法實現涉及多個應用系統的複雜業務流程。

中心——輻條（hub-spoke）式體系結構

中心——輻條（hub-spoke）式體系結構如圖1.1所示，該方式提供一個應用整合中心（hub），這個中心具有自己的連線協議，所有需要整合的系統（spoke）都和該中心相連。原來使用者每整合一個系統，都要考慮改系統和其他所有系統的點對點連線的協議，資料結構的轉換，而在中心——輻條結構下，使用者只需要考慮系統和整合中心的點對點連線上轉換。這樣，原來n個系統之間的nx(n-1)/2個點對點連線減少為n個連線。

一般整合中心和各個系統的連線及相應的轉換使用整合中心中介面卡來完成。同時，這種方式也使的集中管理以及流程整合成為可能。另外，體系結構中開始出現集中式的資源中心（Repository）。資源中心將原來分散的各種資源（介面卡，元件，執行資訊等）集中管理起來，這為使用者設計，開發，部署和維護管理EAI系統提供了很大的便利。但是集中式的結構容易造成效率瓶頸，同時存在單點失效的問題。

圖1.1中心——輻條（hub-spoke）式體系結構

隨著IT技術的發展，企業服務匯流排（Enterprise Service Bus）的體系結構逐漸浮出水面。這種體系結構繼承了中心——輻條（hub-spoke）式體系結構將各個系統點對點連線轉化為多個系統對中心的連線的理念。但在這種體系結構中，整合中心被擴充套件成可以分佈在多個物理節點上的匯流排，從而有效解決了中心——輻條模式的單點失效和效率問題。 

圖1.2 企業服務匯流排體系結構

ESB技術並不僅僅是簡單的將整合中心被擴充套件成匯流排。企業服務匯流排本身提供各種訊息路由，資料轉換等各種EAI模式的支援。這種匯流排一般以成熟的訊息中介軟體作為其物理訊息傳遞背板，保證訊息在分散式環境下可靠高效的傳輸。同時，企業服務匯流排作為應用整合系統的基礎框架，大多數採用面向元件的技術，這實際上是SOA的雛形。

圖1.3是Gartner Group在2002年對EAI技術趨勢的預測^[2]

圖1.3 EAI技術趨勢預測

1.3 本課題研究的價值及現實意義

面向服務的體系架構（Service Oriented Architecture）是目前EAI領域最先進的體系結構。實際上，SOA的提出在很大程度上就是為了更好的滿足企業應用整合的需求。SOA強調複用和鬆偶合，注重介面及其標準化描述，這些都為企業應用整合規劃了非常好的框架體系結構。除了具有前面ESB結構的優點之外，基於SOA的應用整合系統具有更好的可擴充套件性和靈活性，使用者可以在對已有系統影響最小的情況下開發應用新的業務模組（服務）或修改已有模組，從而快速滿足業務需求的變化。SOA的體系結構一般來說也需要企業服務匯流排的支撐，只是它對總線上的服務和匯流排本身的作用和位置有著更加明確的要求。

如何把SOA應用到企業自身的EAI建設之中，已經成為當前的一個研究熱點。

本課題介紹了目前業界比較流行的企業服務匯流排產品，研究瞭如何使用SOA架構下的企業服務匯流排來替代傳統的EAI方式實現企業應用的整合，並結合實際專案開發，給出了成功的案例，使得本課題的提出具備相當的理論意義和實用價值。

1.4 本文的主要內容及組織

本文主要內容包括對國內外多種ESB產品的研究，深入介紹了ESB產品概念、特點以及各個功能模組的作用。

第一章介紹EAI的背景，概念和國內外研究現狀；然後，提出用面向服務架構下的EAI替代傳統的EAI，從而指出了本課題研究的價值和現實意義。

第二章 介紹企業服務匯流排的支撐平臺和理論基礎，包括面向服務架構（SOA）、企業服務匯流排（ESB）、WEB服務、可擴充套件樣式轉換語言（XSLT）和系統開發的基礎平臺、框架及其工具簡介。

第三章 介紹企業服務匯流排的相關技術，包括服務註冊和發現、JAXR、JNDI、JMS、Digester和log4j。

2 企業服務匯流排系統的支撐平臺與理論基礎

2.1 面向服務架構(SOA)

面向服務的體系結構（Service-Oriented Architecture，SOA，也叫面向服務架構）是指為了解決在Internet環境下業務整合的需要，通過連線能完成特定任務的獨立功能實體實現的一種軟體系統架構。SOA是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。

傳統的Web（HTML/HTTP）技術有效的解決了人與資訊系統的互動和溝通問題，極大的促進了B2C模式的發展。WEB服務(XML/SOAP/WSDL）技術則是要有效的解決資訊系統之間的互動和溝通問題，促進B2B/EAI/CB2C的發展。SOA則是採用面向服務的商業建模技術和WEB服務技術，實現系統之間的鬆耦合，實現系統之間的整合與協同。WEB服務和SOA的本質思路在於使得資訊系統個體在能夠溝通的基礎上形成協同工作。

對於面向同步和非同步應用的，基於請求/響應模式的分散式計算來說，SOA是一場革命。一個應用程式的業務邏輯（Business Logic）或某些單獨的功能被模組化並作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的鬆耦合特性。例如，服務的介面和實現相獨立。應用開發人員或者系統整合者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來說，一個服務可以用.NET或J2EE來實現，而使用該服務的應用程式可以在不同的平臺之上，使用的語言也可以不同。^[3]

l獨立的功能實體

在Internet這樣鬆散的使用環境中，任何訪問請求都有可能出錯，因此任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的元件技術，如.NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體；當這些宿主執行結束時這些元件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上執行的其它應用服務就會受到影響。

SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction)，訊息佇列(Message Queue)，冗餘部署(Redundant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。

l大資料量低頻率訪問

對於.NET Remoting，EJB或者XML-RPC這些傳統的分散式計算模型而言，他們的服務提供都是通過函式呼叫的方式進行的，一個功能的完成往往需要通過客戶端和伺服器來回很多次函式呼叫才能完成。在Intranet的環境下，這些呼叫給系統的響應速度和穩定性帶來的影響都可以忽略不計，但是在Internet環境下這些因素往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此SOA系統推薦採用大資料量的方式一次性進行資訊交換。

l基於文字的訊息傳遞

由於Internet中大量異構系統的存在決定了SOA系統必須採用基於文字而非二進位制的訊息傳遞方式。在COM、CORBA這些傳統的元件模型中，從伺服器端傳往客戶端的是一個二進位制編碼的物件，在客戶端通過呼叫這個物件的方法來完成某些功能；但是在Internet環境下，不同語言，不同平臺對資料、甚至是一些基本資料型別定義不同，給不同的服務之間傳遞物件帶來的很大困難。由於基於文字的訊息本身是不包含任何處理邏輯和資料型別的，因此服務間只傳遞文字，對資料的處理依賴於接收端的方式可以幫忙繞過相容性這個的大泥坑。

此外，對於一個服務來說，Internet與區域網最大的一個區別就是在Internet上的版本管理極其困難，傳統軟體採用的升級方式在這種鬆散的分散式環境中幾乎無法進行。採用基於文字的訊息傳遞方式，資料處理端可以只選擇性的處理自己理解的那部分資料，而忽略其它的資料，從而得到的非常理想的相容性。^[4]

Web服務是技術規範，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的介面定義標準：這是 Web服務和SOA的根本聯絡.下面讓我們看看Web Service中的各種協議是如何互相工作來滿足SOA所需的特點的：

·獨立的功能實體：通過UDDI的目錄查詢，我們可以動態改變一個服務的提供方而無需影響客戶端的應用程式配置。所有的訪問都通過SOAP訪問進行，只要WSDL介面封裝良好，外界客戶端是根本沒有辦法直接訪問伺服器端的資料的。

·大資料量低頻率訪問：通過使用WSDL和基於文字(Literal)的SOAP請求，我們可以實現能一次性接收大量資料的介面。這裡需要著重指出的是SOAP請求分文字方式和遠端呼叫(RPC)兩種方式，正如上文已經提到的，採用遠端呼叫方式的SOAP請求並不符合這點要求。但是令人遺憾的是現有的大多數SOAP請求採用的仍然是遠端呼叫(RPC)方式，在某些平臺上，例如IBM WebSphere的早期版本，甚至沒有提供文字方式的SOAP支援。

·基於文字的訊息傳遞：Web Service所有的通訊是通過SOAP進行的，而SOAP是基於XML的，不同版本之間可以使用不同的DTD或者XML Schema加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕鬆實現版本控制的目標。^[5]

複雜性降低：基於標準的相容性，與點到點的整合相比降低了複雜性。重用增加：通過重用以前開發和部署的共享服務，實現了更有效的應用程式 / 專案開發和交付。遺留整合：用作可重用服務的遺留應用程式降低了維護和整合的成本。如今的服務驅動型企業都在體驗著開發的高效率，服務的高可靠性和服務的高質量，以最大限度獲得業務機會所帶來的這些好處。^[6]

2.2 企業服務匯流排(ESB)

2.2.1傳統EAI

Integrator產品利用傳統的EAI技術開發的EAI整合平臺。它遮蔽了所有銀行渠道的差異性以及後臺服務系統的差異性。提供更高階的服務訪問介面，向分行提供功能更強大的業務整合能力。從業務上解決了複雜的外圍系統，快速變化的業務邏輯以及巨大的業務量的壓力。從技術上又提供了靈活及高效能的架構，快速的開發測試和部署平臺。圖2.1是Integrator的體系結構圖，圖2.2是Integrator的功能模型圖。^[7]

圖2.1 Integrator體系結構圖

通訊模組

1 利用系統層通訊協議和系統進行通訊，包括TCP/IP,SNA/LUO,TUXEDO等通訊方式

2 外部系統約定的通訊方式的實現，包括如何進行通訊連線，如何進行通訊應答，如何進行資料傳輸，如何約定通訊報文的大小，如何確定資料傳輸是否完畢，如何處理通訊錯誤，如何關閉通訊連線，如何處理通訊層資料完整性校驗等。

3 識別外部系統型別

4 多通訊連線的併發處理

圖2.2 Integrator功能模型圖

資料交換模組

從功能上講，資料交換要解決的是兩個問題，一是定義資料標準的問題，二是解決非標準資料和標準資料之間的轉換問題。

服務整合模組：

1 完成對原子服務的呼叫。

2 完成對服務呼叫流程的控制

3 實現了對服務執行過程中資料一致性的保證。

4 實現對不同型別服務的服務總量控制。

5 完成對服務的動態載入和動態起停。

產品關鍵特性

1 相容新老系統

2 分層設計、層次之間介面明確，耦合度小

3 各個關鍵部分使用介面設計，提供了各個層次擴充套件系統的機制

4 配置驅動方式，輔以少量的程式碼，保證對業務變化的快速反應。

5 核心模組（資料交換，流程管理）使用底層JAVA程式碼實現，以確保系統的效能。

缺點:

1 面向元件開發,沒有真正的面向服務,複用度差;

2 服務請求者和服務提供者之間位置不透明;

3 所有元件的實現基於靜態配置檔案, 複雜度高,缺乏靈活性;

4 報文處理缺少標準技術的支援;

在企業基於SOA實施EAI、B2B和BMP的過程中，如果採用點對點的整合方式存在著複雜度高，可管理性差，複用度差、系統脆弱等問題。企業服務匯流排（Enterprise Service Bus，簡稱ESB）技術在這種背景下產生，其思想是提供一種標準的軟體底層架構，各種程式元件能夠以服務單元的方式“插入”到該平臺上執行，並且元件之間能夠以標準的訊息通訊方式來進行互動。它的定義通常如下：企業服務匯流排是由中介軟體技術實現的支援面向服務架構的基礎軟體平臺，支援異構環境中的服務以基於訊息和事件驅動模式的互動，並且具有適當的服務質量（Qos）和可管理性。

圖2.3 ESB示意圖

如圖2.3所示ESB本質上是以中介軟體形式支援服務單元之間進行互動的軟體平臺。各種程式元件以標準的方式連線在該“匯流排”上，並元件之間能夠以格式統一的訊息通訊的方式來進行互動。一個典型的在ESB環境中元件之間的互動過程是：首先由服務請求者觸發一次互動過程，產生一個服務請求訊息，並將該訊息按照ESB的要求標準化，然後標準化的訊息被髮送給服務匯流排。ESB根據請求訊息中的服務名或者介面名進行目的元件查詢，將訊息轉發至目的元件，並最終將處理結果逆向返回給服務請求者。這種互動過程不再是點對點的直接互動模式，而是由事件驅動的訊息互動模式。通過這種方式，ESB最大限度上解耦了元件之間的依賴關係，降低了軟體系統互連的複雜性。連線在總線上的元件無需瞭解其他元件和應用系統的位置和互動協議，只需要向服務匯流排發出請求訊息即可獲得所需服務。服務匯流排事實上實現了元件和應用系統的位置透明和協議透明。技術人員可以通過開發符合ESB標準的元件（介面卡）將外部應用連線至服務匯流排，實現與其他系統的互操作。同時，ESB以中介軟體的方式，提供服務容錯、負載均衡、Qos保障和可管理功能。^[8]

ESB的核心功能包括：1）提供位置透明性的訊息路由和定址服務 2）提供服務註冊和命名的管理功能 3）支援多種的訊息傳遞範型（例如，請求/響應、釋出/訂閱等等） 4）支援多種可以廣泛使用的傳輸協議5）支援多種資料格式及其相互轉換6）提供日誌和監控功能。

由於採用了基於標準的互連技術，ESB使得企業內部以及外部系統之間可以很容易地進行非同步或同步互動。它採用的面向服務的架構為系統提供了易擴充套件性和靈活性，在提高整合應用的開發效率的同時降低了成本。ESB技術克服了傳統應用整合技術的缺陷，能夠對各種技術和應用系統提供支援，具有很強的靈活性和可擴充套件性，可以說是目前理想的EAI、B2B應用系統整合支撐平臺。

ESB本身為EAI提供了良好的支援平臺。但是，作為最終的企業使用者需要的則是包含業務整合軟體基礎平臺、各種預製服務元件、整合應用開發、部署、管理和監控工具為一體的EAI環境。因此，作為軟體廠商則是以ESB中介軟體為基礎軟體平臺，為使用者提供整套立體的完善的企業應用軟體整合平臺。^[9]

ESB是特定環境下(SOA架構中)實施EAI的方式：首先，在ESB系統中，被整合的物件被明確定義為服務，而不是傳統EAI中各種各樣的中介軟體平臺，這樣就極大簡化了在整合異構性上的考慮，因為不管有怎樣的應用底層實現，只要是SOA架構中的服務，它就一定是基於標準的。

其次，ESB明確強調訊息(Message)處理在整合過程中的作用，這裡的訊息指的是應用環境中被整合物件之間的溝通。以往傳統的EAI實施中碰到的最大的問題就是被整合者都有自己的方言，即各自的訊息格式。作為基礎架構的EAI系統，必須能夠對系統範疇內的任何一種訊息進行解析。傳統的EAI系統中的訊息處理大多是被動的，訊息的處理需要各自中介軟體的私有方式支援，例如API的方式。因此儘管訊息處理本身很重要，但訊息的直接處理不會是傳統EAI系統的核心。ESB系統由於整合物件統一到服務，訊息在應用服務之間傳遞時格式是標準的，直接面向訊息的處理方式成為可能。如果ESB能夠在底層支援現有的各種通訊協議，那麼對訊息的處理就完全不考慮底層的傳輸細節，而直接通過訊息的標準格式定義來進行。這樣，在ESB中，對訊息的處理就會成為ESB的核心，因為通過訊息處理來整合服務是最簡單可行的方式。這也是ESB中匯流排(Bus)功能的體現。其實，匯流排的概念並不新鮮，傳統的EAI系統中，也曾經提出過資訊匯流排的概念，通過某種中介軟體平臺，如CO