使用NetKerne實現REST風格的ESB

新英格蘭大學啟動了一個為期多年的基礎建設現代化項目，這個項目的目的在於逐步取代已經過時的系統，並在盡量實現所有IT投資的回報最大化的同時提供儘可能多的IT功能項。這個項目牽涉到硬體升級、購買新軟體、開發培訓和操作團隊的培訓等等。這個現代化的戰略性項目的中心在於實現一個面向服務架構（Service Oriented Architecture－SOA）。

SOA是著重於分布式應用設計的總體平台架構方式，而非注重於特定技術。SOA的關鍵的在於軟體服務的定義和實現，不管服務的位置如何、所有權歸誰，這些服務都直接映射到一個系統或若干業務過程服務，包括在運行時管理它們的介面和策略。SOA的優點包括：相互影響的系統和平台之間的鬆散耦合、無處不在的基於企業標準的整合機制、支援按需（on-demand）建立複合服務、以及在提高操作效率的同時充分利用已有資產的能力。

圖1 面向服務架構

從傳統應用的開發部署到基於服務方法的轉變是巨大的，不可能在一夜之間就能完成。新英格蘭大學的IT部門與凱捷諮詢公司通力合作，描繪出了增量採用SOA 的路線圖。增量方式的一個優點是能夠立馬看到投資的回報，並且可以有目的地選擇轉換的順序來最好地適應學校的短期和長期目標。本文將在下面的章節中向大家描述這個為期6個月的項目是如何利用1060 Research公司的NetKernel通過實現面向資源的企業服務匯流排（Resource Oriented Enterprise Service Bus）來啟動SOA的採用過程的。

問題領域

高等教育機構不斷承受著來自學生、員工以及校友的壓力，他們要求高校提供各種各樣的線上服務來適應這些使用者人群逐漸養成的生活習慣，比如通過直觀的使用者介面和自動處理流程來提供即時的7*24小時的資訊訪問。同時，來自管理部門、督導委員會（steering committees）和控制開銷的理事會的壓力也越來越大。因此，像大學這樣的高等教育機構的IT部門在對新功能進行投資時就必須更加機敏、更加註重實效。

大學IT部門支援的應用內容非常廣泛，有PeopleSoft這樣的非定製商業化（Commercial off the Shelf——COTS）產品、有建立於客戶資訊控制系統（Customer Information Control System——CICS）之上的大型主機遺留系統、以及使用Oracle應用伺服器Portal構建的現代J2EE Web應用。另外，這些應用軟體中有很多都與第三方應用服務供應商（ASP）互動，以此向資料倉儲（DW）提供曆史資料。在這個項目中，所有這些應用都必須與新的SOA方法進行整合和協調。

該大學之前曾經通過使用IBM MQ和FTP來整合業務系統。這些傳統方式導致的結果是大量的點對點（P2P）整合，所有這些P2P整合在維護時需要付出很大的代價，並且導致客戶和供應商緊密耦合。然而，現有環境已經使用了輕量級的訊息交換狀態傳輸（ message exchange state transfer——MEST）的方式，這給以後的進一步革新留出了空間。企業服務匯流排（ESB）是訊息匯流排構架的一個子類型，它提供更解耦的環境，但在它的前期部署費用相對較高，ESB的價值按時間呈指數增長，而擴充系統所需的花銷卻保持線性增長並且是可以預期的1。

該大學的IT部門有一個由專門的架構師和軟體工程師組成的開發小組，他們中很多人都通過自己的職務成為了在高等教育領域專家。由於這個開發小組比較小，每個成員常常不得不在開發的過程中扮演多個角色，包括對軟體的支援和管理。基於這個緣由，IT部門急切需要一個可以實現以下要點的解決方案：

• 通過利用可複用服務和複合應用來滿足日益增長的客戶需求
• 減少或避免P2P整合
• 充分利用現有資源和技術來提高操作效率

解決方案1. 總覽

SOA可以通過很多不同的模式和技術來實現。傳統方式是選擇WS-*規範中所列出的模式，而且可以從Apache ServiceMix這樣的開源解決方案或Cape Clear 和Sonic Software商業套件等廣泛的技術產品中任意選擇一種。不幸的是， WS-*規範仍處於不停的修改中，並且開發人員不得不消化1300頁的文檔來得到技術細節，這足以讓許多人望而卻步。比如說，如果完全堅持遵循所有規範的話，實現一個SOAP服務需要以下這些步驟：

1. 使用商務程序建模符號（BPMN）來對流程進行建模。
2. 使用WSDL來定義服務介面，使用UDDI（Universal Description，Discovery and Integration——統一的描述、發現和整合）庫來註冊服務。
3. 使用從服務註冊訪問服務的BPMN來產生商務程序執行語言（BPEL）。
4. 使用WS-Policy來定義訪問服務的管理原則。

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

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

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

2. 技術平台

NetKernel是面向資源的中介軟體，它提供企業服務匯流排（ESB）核心功能：定址、路由和資料轉換，而且能夠像服務註冊編製（orchestration）引擎那樣工作。NetKernel能夠提供很多特性，它能提供一些諸如XML轉化、緩衝管理、多執行緒和包括HTTP和 JMS在內的多種傳輸協議等進階功能，而SOAP引擎使它能夠提供傳統的web服務。NetKernel是異質企業整合的堅實基礎。

從概念上來說，NetKernel提供訪問的資源是按統一資源識別項（URI）地址進行識別的。所有URI地址在一個邏輯地址空間中統一管理。基於 REST的微核負責處理所有的資源請求，從地址空間中解析URI地址，並且返回該資源的表示。向微核發送的請求也可以被用來建立新的資源、更新或刪除現存資源。

從物理上來說，NetKernel系統是由模組組成的，這些模組通過URI地址暴露出公用服務介面和資源。和Java EAR類似，每個模組都包含原始碼和資源配置。模組可以從邏輯上引入另一個模組的公用服務和資源，將它們包含到地址空間中。由於引入需要指出模組的邏輯名字並能夠辨別出版本號碼，因此多個版本能夠在同一個系統中運行和更新。服務要求通過傳輸器注入到NetKernel中，這些傳輸器是位於系統邊緣的事件偵測器。服務的客戶可以通過任何可支援的傳輸器，比如HTTP或JMS來發送請求。

圖2 技術平台

HTTP是無狀態請求/回複應用協議。request訊息結構包括一個命令、頭部和體部。response訊息則由狀態、頭部和體部組成。客戶和伺服器間使用TCP socket交換這些資訊。客戶/伺服器傳輸層可以通過使用SSL協議對兩者間的互動進行安全保護，而訊息本身可以使用加密和數位簽章來確保安全。最後，客戶可以通過使用HTTP-Basic或HTTP-Digest的鑒別機制3來進行鑒別。

JMS API為平台提供了實現非同步服務的平台。然而，該API需要提供者，在這個案例中，這個供應商是IBM WebSphere MQ。IBM MQ是面向訊息的中介軟體（MOM），它在各應用軟體間提供基於隊列的通訊通道。通道的使用點對點或Hub & Spoke拓撲來實現。除了傳輸訊息，MQ還能夠處理工作流程、流程自動化、資料轉換、監控和管理。

3. 基於資源的服務

基於資源的服務提供與傳輸無關的無狀態的資源訪問。資源是資訊的抽象。例如，一個學生的註冊是可以用web頁面、XML文檔或PDF檔案方式來表示的抽象。服務使用資源標識符（resource identifier）或地址來表示每個資源。資源標識符實際上是相對於統一資源識別項（URI）的。每個URI包含兩部分：機制（比如HTTP和 FTP）和地址。URI的第二個部分是相對的。地址/domain/account/45322是相對的，除非它直接關聯到一個機制，比如http，http://domain/account45322。

圖3 面向資源的服務概念性模型

服務定義了一系列在資源上可能發生的動作：建立、讀取、更新和刪除。此外，還有一些特定的動作可能會觸發規則或者商務邏輯。當資源被請求的的時候，一個物理的、無法被修改的該資源的抽象表示會被返回。基於商務邏輯，比如客戶的類型，返回的資源表示類型會因條件各異。比如，大部分後端處理需要XML文檔，而前端處理則可能要求JSON對象。服務也能夠接收到關於建立資源或更新現有資源的表示。最後，服務也能夠接收刪除資源的請求。

圖4 面向資源的服務互動模型

傳輸通常存在於系統邊界，當它偵測到事件發生的時候，它會發送一個對應的內部請求。例如，HTTP傳輸監聽來自客戶請求的URL，該URL會明確訪問方式（比如，GET、PUT、POST和DELETE）。URL會被轉換成內部相對URI，而訪問方式則會被解析為一個動作。在通過JMS傳輸請求的情況下，URI和動作被當作訊息頭參數傳遞。另外，如果一個資源表示需要被返回，在回複的訊息頭部中會申明一個返回隊列參數。

在REST風格的系統中，對資源的訪問是無狀態的，也就是說每個請求必須能夠將內容作為元資訊（meta-information）傳遞。總體來說，傳輸定義了一個包含頭部和體部的訊息結構。頭部被用來傳遞元資訊，而體部則被用來傳遞資源的表示。例如，如果一個面向資源的服務通過HTTP公布，那麼鑒別資訊可以在頭部中傳遞；如果服務通過JMS來公布的話，那麼同樣的資訊則可以作為加密的頭參數來傳遞。

面向資源的服務可以使用Maven4來構建，作為NetKernel模組來打包。Maven是用來在一個“項目”的範疇內構建和管理軟體的工具。Maven項目由項目物件模型（POM）XML定義。POM定義了軟體的依賴性、構建流程和部署結構（比如JAR、WAR、EAR）。另外，Maven項目還能夠被用來產生項目的網站和部署軟體。在這種情況下，Maven在NetKernel模組中將服務打包，並將這些服務的相關資訊發布到註冊項中。

圖5 面向資源的服務開發

4. 面向資源的企業服務匯流排（ESB）

面向資源的企業服務匯流排（ESB）是使用NetKernel來實現的。NetKernel的中心是一個REST風格或面向資源的微核，專門負責為物理代碼解析邏輯URI請求並在閒置CPU上安排執行請求。邏輯地址和物理代碼的映射在應用結構中定義，實際的邏輯地址和物理代碼的捆綁僅在請求處理的過程中發生，之後該捆綁被會自動廢棄。

由於每個發送給微核的請求都會建立新的捆綁，所以系統管理人員可以在系統運行並啟用了類似即時代碼更新功能的環境下自由地修改邏輯地址和物理代碼之間的關聯。實際的效能似乎不會因為這樣的迂迴和捆綁而降低，但是當把URI地址作為NetKernel內部緩衝的主鍵時確實可以提高效能。如果有資源被再次請求，並且依賴性沒有受到任何修改的話，那麼緩衝的資源表示會直接被返回，系統無須再重新對其進行計算。

使用面向資源微核有幾個主要的優點。首先，服務間互動在邏輯層而非物理層進行，這決定了鬆散的耦合互動，也因此減小了在物理層實現所做的修改對客戶和服務供應方之間的影響。其次，請求結果是被緩衝的，因而可以減低合成服務和編製的總體開銷。比如，如果一組編製好的服務依賴於同一個服務，那麼該服務背後的物理代碼將很少被執行。最後，所有向微核發送的內部請求都是非同步，因此隨著主機伺服器CPU個數的增加，其處理能力也會線性增長。

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

圖6 面向資源的服務供應

面向資源的服務依次去委託一組定製的基礎服務和NetKernel提供的核心服務。NetKernel可以提供大量的核心服務，比如一些核心服務可以處理 XML和SOAP，CRON任務調度以及SMTP互動。核心服務可以極大地減少實現一個面向資源的服務所需要的代碼量。定製基礎服務則可以用來服務於高等教育領域。

每個向ESB發送的請求首先會加以認證，然後授權，有時候還需經過審計。傳輸器基於使用者名稱密碼組合認證一個輸入請求，然後再將認證和審計委託給安全服務。授權的過程涉及到驗證經過確認的使用者擁有正確的許可權，每個許可權都包含一個相對URI和動作。舉例來說，一個使用者可以擁有讀的許可權，但沒有更新和刪除可以通過相對URI /domain/student/identifier/profile來標識的學生檔案資源的許可權。未授權的請求可以自動被審計，基於已認證使用者或許可權的審計也是有選項的。帳號、許可權和審計資訊儲存於一個嵌入式Hypersonic資料庫中。

圖7 面向資源的服務安全

總結

和Actional或ManagedMethods等運行時服務管理解決方案不同的是，實現ESB所用到的中介軟體是任何SOA成功的必要條件。如果沒有 ESB，機構只能單純地通過使用web服務不斷地添加P2P互動。然而對於ESB的組成和目的方面有很多不同意見，但得到大部分人肯定的是它的一組核心功能，包括服務定址、訊息轉換和訊息路由。使用NetKernel中介軟體實現的ESB不僅能夠提供這些功能，還能提供一些像服務註冊和服務編製等進階功能。

NetKernel產品使得大學能夠實現一個面向資源的ESB。面向資源的ESB本質上來說是一個開放的基於標準的企業整合架構。該架構使得企業能夠降低或者避免P2P互動的代價，減少向市場引入新功能的時間。再進一步來看，該架構比傳統的基於WS-*標準的企業整合架構所需要的啟動資金要少的多。此外，由於NetKernel和ROC提供的整合以每個服務為基礎單位，該大學因此可以將整合功能推到網路邊緣（比如URI），使其能夠轉化為更好的服務管理和更好的擴充性。簡單來說，該架構為組織機構提供了史無前例的靈活的企業架構。

在六個月之內，由三個軟體構架師組成的團隊實現了一個面向資源的ESB，以及一些使用NetKernel中介軟體的初始面向資源服務。這個成功的ESB實現為大學啟動了向SOA轉化的步伐。面向資源的方式使得整個團隊能夠充分利用了現存的資源和技術。今後，該大學的IT部門已經有能力通過利用可複用服務和組合應用來應付日益增長的使用者需要，同時也減少或避免了P2P的整合。