NetKerne實現(xiàn)REST風格的ESB研究

【摘要】在過去幾年中，ESB逐漸發(fā)展壯大，現(xiàn)在提供了更為廣泛的功能，ESB是一種應用集成工具，在很多關鍵領域提供了靈活廣泛的功能，像連接、消息轉換、處理中介等。NetKernel是一個軟件系統(tǒng)，它將REST和Unix的基本屬性組裝成一個叫做面向資源計算的強大的抽象集。通過基于NetKerne實現(xiàn)REST風格的ESB技術，顯示了ESB強大的魯棒性、易用性。

【關鍵詞】ESB；NetKerne；中間件；傳輸器

1.引言

SOA可以通過很多不同的模式和技術來實現(xiàn)。傳統(tǒng)方式是選擇WS-*規(guī)范中所列出的模式，而且可以從Apache ServiceMix這樣的開源解決方案或Cape Clear 和Sonic Software商業(yè)套件等廣泛的技術產(chǎn)品中任意選擇一種。不幸的是，WS-*規(guī)范仍處于不停的修改中，并且開發(fā)人員不得不消化1300頁的文檔來得到技術細節(jié)，這足以讓許多人望而卻步。

市場上的商業(yè)ESB套件都已經(jīng)獲得各方的評估，由于這個IT團隊相對較小，最終團隊決定尋找這樣一個解決方案：這個解決方案最終在各系統(tǒng)間引起的矛盾或沖突要??；它所需要的創(chuàng)新要在這個較小的IT團隊人力資源所能承受的范圍之內(nèi)；它不應該迫使團隊使用依賴于唯一供應商的中央服務集權式模型。大學的領域是極具流動性的，擁有多變的流程、多變的應用、以及多變的集成，因而，它所需要的是能反映大學正真的自然特性的一個總體構架和策略。

由于消息請求在之前已作為跨大學的中心傳輸機制，團隊決定選擇REST類型或面向資源（Resource-Oriented）的方式來實現(xiàn)SOA。REST基于一組較小的被廣泛接受的標準，比如HTTP和XML，這些標準不需要很多開發(fā)步驟、不需要很多工具箱和執(zhí)行引擎。采用REST類型的方式來實現(xiàn)SOA的有三個最主要的優(yōu)點：較低的開銷、投入市場較快、靈活的架構。面向資源的方式在REST風格方式的基礎上提供了更廣泛的擴展和獨立通信基礎。REST設計模式提倡使用HTTP，而面向資源的架構則支持將服務連接到HTTP以及諸如JMS或SMTP這樣的通信協(xié)議上。

盡管有一些像Codehaus Mule那樣的ESB實現(xiàn)支持REST，但只有1060 NetKernel是建立在在面向資源的計算平臺2（Resource-Oriented Computing Platform，“ROC”）之上的。面向資源計算的核心是將信息（資源）的邏輯請求從發(fā)送請求的物理機制（代碼）中分離出來。使用ROC建立的服務被證實是小巧、簡單、靈活的，并且和傳統(tǒng)方式相比較需要實現(xiàn)的代碼更少。這些優(yōu)點決定了它是創(chuàng)建技術平臺理想的技術選擇。

2.面向資源的企業(yè)服務總線（ESB）

面向資源的企業(yè)服務總線（ESB）是使用NetKernel來實現(xiàn)的。NetKernel的中心是一個REST風格或面向資源的微核，專門負責為物理代碼解析邏輯URI請求并在空閑的CPU上安排執(zhí)行請求。邏輯地址和物理代碼的映射在應用結構中定義，實際的邏輯地址和物理代碼的捆綁僅在請求處理的過程中發(fā)生，之后該捆綁被會自動廢棄。

由于每個發(fā)送給微核的請求都會建立新的捆綁，所以系統(tǒng)管理人員可以在系統(tǒng)運行并激活了類似實時代碼更新功能的環(huán)境下自由地修改邏輯地址和物理代碼之間的關聯(lián)。實際的性能似乎不會因為這樣的迂回和捆綁而降低，但是當把URI地址作為NetKernel內(nèi)部緩存的主鍵時確實可以提高性能。如果有資源被再次請求，并且依賴性沒有受到任何修改的話，那么緩存的資源表示會直接被返回，系統(tǒng)無須再重新對其進行計算[1]。

使用面向資源微核有幾個主要的優(yōu)點。首先，服務間交互在邏輯層而非物理層進行，這決定了松散的耦合交互，也因此減小了在物理層實現(xiàn)所做的修改對客戶和服務供應方之間的影響。其次，請求結果是被緩存的，因而可以減低合成服務和編制的總體開銷。比如，如果一組編制好的服務依賴于同一個服務，那么該服務背后的物理代碼將很少被執(zhí)行。最后，所有向微核發(fā)送的內(nèi)部請求都是異步的，因此隨著主機服務器CPU個數(shù)的增加，其處理能力也會線性增長。

ESB主要負責服務的供應和安全性。服務供應包括將面向資源的服務通過HTTP或JMS等傳輸協(xié)議公布給用戶。傳輸層負責將外部URI和訪問方法映射到一個內(nèi)部的面向資源的服務和動作。略去傳輸不看，以XML文檔或JSON對象形式構建的請求體會作為名為“param”的參數(shù)傳遞。帶來的結果是，面向資源的服務從傳輸特定邏輯的細節(jié)中解耦，實際上，在任何時候添加額外的協(xié)議都不會影響到現(xiàn)存的代碼。

面向資源的服務依次去委托一組定制的基礎服務和NetKernel提供的核心服務。Net-Kernel可以提供大量的核心服務，比如一些核心服務可以處理XML和SOAP，CRON任務調(diào)度以及SMTP交互。核心服務可以極大地減少實現(xiàn)一個面向資源的服務所需要的代碼量。定制基礎服務則可以用來服務于高等教育領域。

每個向ESB發(fā)送的請求首先會加以認證（如圖1所示），然后授權，有時候還需經(jīng)過審計。傳輸器基于用戶名密碼組合認證一個輸入請求，然后再將認證和審計委托給安全服務[2]。授權的過程涉及到驗證經(jīng)過確認的用戶擁有正確的權限，每個權限都包含一個相對URI和動作。舉例來說，一個用戶可以擁有讀的權限，但沒有更新和刪除可以通過相對URI /domain/student/identifier/profile來標識的學生檔案資源的權限[3]。未授權的請求可以自動被審計，基于已認證用戶或權限的審計也是有選項的。帳號、權限和審計信息存儲于一個嵌入式Hypersonic數(shù)據(jù)庫中。

3.總結

實現(xiàn)ESB所用到的中間件是任何SOA成功的必要條件。如果沒有ESB，機構只能單純地通過使用web服務不斷地添加P2P交互。然而對于ESB的組成和目的方面有很多不同意見，但得到大部分人肯定的是它的一組核心功能，包括服務尋址、消息轉換和消息路由。使用NetKernel中間件實現(xiàn)的ESB不僅能夠提供這些功能，還能提供一些像服務注冊和服務編制等高級功能。

NetKernel產(chǎn)品使得大學能夠?qū)崿F(xiàn)一個面向資源的ESB。面向資源的ESB本質(zhì)上來說是一個開放的基于標準的企業(yè)集成框架。該框架使得企業(yè)能夠降低或者避免P2P交互的代價，減少向市場引入新功能的時間。再進一步來看，該框架比傳統(tǒng)的基于WS-*標準的企業(yè)集成框架所需要的啟動資金要少的多[4]。此外，由于NetKernel和ROC提供的集成以每個服務為基礎單位，該大學因此可以將集成功能推到網(wǎng)絡邊緣（比如URI），使其能夠轉化為更好的服務管理和更好的擴展性。簡單來說，該框架為組織機構提供了史無前例的靈活的企業(yè)架構。

參考文獻

[1]李凌.軟件項目管理中的進度控制問題研究[J].中國科技信息，2005，（17）.

[2]劉國亮，王東，王勇.基于項目管理視角的科技論文網(wǎng)絡發(fā)表學術質(zhì)量控制研究[J].情報雜志，2008（5）.

[3]季成健，王建軍.煤炭企業(yè)信息化與信息集成[J].電腦知識與技術，2011（06）.

[4]劉麗靜.綜合信息管理系統(tǒng)在煤炭生產(chǎn)集團中的應用[J].工礦自動化，2011（10）.

作者簡介：張聰慧（1987—），男，山西忻州人，碩士，研究方向：煤礦企業(yè)信息化集成與業(yè)務應用。