引言
隨著企業(yè)信息化的發(fā)展，企業(yè)對異構系統(tǒng)之間數(shù)據(jù)整合要求越來越高，傳統(tǒng)的整合方案，已日益不能滿足其復雜的需求。為了提升異構系統(tǒng)間數(shù)據(jù)交互與信息共享功能，提出一種SOA—ESB企業(yè)整合架構。傳統(tǒng)點對點的整合技術，通過互連異構系統(tǒng)接口進行通信，但隨著業(yè)務系統(tǒng)的增加，其接口數(shù)目的不斷增長，整個系統(tǒng)維護變得越來越困難：在隨后出現(xiàn)的CORBA、DCOM、MOM等中間件整合技術，能夠對系統(tǒng)進行無縫集成，但由于其要求服務客戶端與系統(tǒng)提供的服務本身之間必須進行緊耦合，導致了整合系統(tǒng)的整體性能下降。面向服務架構(service-orientedarchitecture，SOA)使異構系統(tǒng)之間保持一種實時、一致的、松耦合的集成，在統(tǒng)一的技術規(guī)范下開發(fā)標準的服務，根據(jù)需求將異構業(yè)務封裝為服務，發(fā)布到企業(yè)服務總線上(entERPrise servicebus，ESB)，ESB根據(jù)業(yè)務流程的定義，對服務進行綜合管理，保證服務在總線上安全的進行交互通信，從而保證了數(shù)據(jù)交互的高效性。本文提出的SOAESB企業(yè)整合架構降低了系統(tǒng)間的耦合度，提高了系統(tǒng)的高重用性，為各類企業(yè)的業(yè)務整合奠定了實現(xiàn)基礎。
1 SOA-ESB企業(yè)整合架構的原理及優(yōu)勢
1．1 SOA-ESB企業(yè)整合架構的原理
SOA是一種策略、框架，為企業(yè)的數(shù)據(jù)整合提供一種思想。針對異構系統(tǒng)中的不同單元封裝為服務，通過定義統(tǒng)一的接口和契約將這些服務聯(lián)系起來，使得異構系統(tǒng)中的服務可以以一種統(tǒng)一的方式進行交互，并降低系統(tǒng)間的耦合度啪。在此平臺下，通過ESB對服務進行集中管理、整合，對外提供統(tǒng)一開放接口，方便了其整合已有服務功能以及可為新增業(yè)務提供良好的通信接口。因此將ESB和SOA結合可有效解決企業(yè)業(yè)務數(shù)據(jù)整合問題.SOA．ESB企業(yè)整合架構能根據(jù)業(yè)務需求將定義好的服務發(fā)布到總線上，總線融合了WebServices和XML等技術，定義了數(shù)據(jù)交互的標準協(xié)議和統(tǒng)一數(shù)據(jù)規(guī)范，使新增服務或已有服務以其標準橋接到總線上，進而保證服務之間通信的一致性嘞。ESB將相互通信的服務轉換為統(tǒng)一交互格式，根據(jù)定義的業(yè)務流程，配置路由機制分析服務的SOAP消息，提取目的地址，為服務請求者找到匹配的服務提供者，完成服務的相互操作，實現(xiàn)異構系統(tǒng)通信的目的。
1．2 SOA-ESB企業(yè)整合架構的優(yōu)勢
SOA．ESB企業(yè)整合架構從整體設計上滿足SOA一切為服務的理念，它與其他ESB架構相比具有如下優(yōu)勢：
(1)ESB擴展性。真正體現(xiàn)SOA價值，服務在總線上處于平等地位，應用組件能以服務形式根據(jù)標準的接口部署在總線上，相比以前Hub形式的整合架構，此架構更靈活，更易擴展。
(2)路由更靈活。普遍的ESB只支持靜態(tài)的路由，通過一個靜態(tài)配置文件來確定路由，但由于業(yè)務的多樣化發(fā)展，路由路徑并不是一對一，多個服務可能同時滿足服務請求者的接口定義要求。基于內容的路由，服務的請求者可以根據(jù)功能總列表中所有提供者的功能信息選擇滿足要求的服務者，使得請求者的選擇更加靈活。
(3)安全性。為請求者設置用戶權限，從消息的發(fā)出至消息的接收通過安全屬性以及加密機制來確保消息的準確性和完整性。
(4)ESB中間件的高可移植性。在SOA．ESB企業(yè)整合架構中ESB總線支持標準的接口和規(guī)范的通信，使其與系統(tǒng)無關。本文總線層的設計除了滿足電力系統(tǒng)要求外，還可以移植到其他行業(yè)適合的系統(tǒng)邏輯，以便提高系統(tǒng)的開發(fā)效率。
2 SOA-ESB企業(yè)整合架構的研究及關鍵技術
SOA-ESB企業(yè)整合架構的設計原則：
(1)架構化。它是軟件平臺開發(fā)和管理的基礎；
(2)技術標準化。可增強框架的通用性；
(3)開放性、擴展性。使不同業(yè)務標準的應用系統(tǒng)快速的“插入”總線。
2．1 SOA-ESB企業(yè)整合架構
SOA-ESB企業(yè)整合架構共包含三層：服務實現(xiàn)層，ESB總線層，業(yè)務流程層。其核心是總線層的傳輸適配轉換模塊、路由模塊以及安全模塊，如圖1所示。
(1)服務實現(xiàn)層：為ESB提供服務，通過WebServices技術，將不同大小的應用組件封裝成粗細粒度不等的Web服務嘲，對服務進行WSDL描述，將WSDL描述文檔注冊到服務注冊中心，以統(tǒng)一的標準暴露接口，便于遺留系統(tǒng)的重用：
(2)ESB總線層：對服務進行控制和管理的中心。由傳輸適配轉換模塊、路由模塊、注冊中心以及安全管理模塊組成，通過ESB總線保證發(fā)布和調用服務的規(guī)范化，基于內容的路由使請求信息能得到快速的響應：
(3)業(yè)務流程層：定義基于業(yè)務標準的流程，流程定義了某些應用需要的服務總和，向ESB發(fā)出訂閱／請求信號等。
2．2 SOA．ESB企業(yè)整合架構的核心模塊
為使不同異構應用組件能相互服務，選擇服務協(xié)議和消息格式作為融合交叉點，配合基于內容的路由機制以及可靠的安全機制，使服務互相操作的主要支點得以實現(xiàn)。
2．2．1傳輸適配轉換模塊
該模塊由消息協(xié)議轉換和數(shù)據(jù)格式轉換兩個子模塊組成。
(1)協(xié)議轉換模塊。由于異構源所采用的底層協(xié)議不同，它們之間要進行消息的交互、信息的共享，必須使用轉換機制將其轉換為任意一方認可的協(xié)議，才能訪問相應的Web服務。一次協(xié)議的轉換需經(jīng)過請求目標轉換和目標應答轉換兩個步驟。請求目標轉換是將請求調用服務的協(xié)議轉換成被調用的Web服務的協(xié)議，目標應答轉換是將被調用的服務發(fā)布的方式轉換為請求調用服務的協(xié)議方式。這兩個過程是互逆的，原理相同。每個轉換過程都經(jīng)過源協(xié)議分析器／生成器、目標協(xié)議分析器／生成器、節(jié)點映射器、內容映射器、編碼轉換器組成。
以請求調用服務轉換為例。首先將調用協(xié)議通過源協(xié)議分析器，分析WSDL配置文件，讀取配置文件中的配置項來初始化節(jié)點映射器以及內容映射器。初始完后，將源請求消息轉換為目標協(xié)議的請求消息，產(chǎn)生相應的應答消息。轉換的具體執(zhí)行步驟如圖2所示。
(2)數(shù)據(jù)格式轉換模塊。鑒于XML的結構化、自描述性、可擴展性等特征，在總線上選取XML作為數(shù)據(jù)交換格式，并使用XMLSchemall．0標準。數(shù)據(jù)的轉換通常有XML到XML、XML到數(shù)據(jù)庫、XML到操作系統(tǒng)等類型，本模塊實現(xiàn)XML與XML之間的轉換。轉換首先為ESB中數(shù)據(jù)信息建立公共的接口，即ESB上標準的XML規(guī)范，作為各應用進行數(shù)據(jù)格式轉換的標準；其次，建立各異構數(shù)據(jù)源XML到總線上XML之間的映射，包括文檔格式、類型、時間日期等映射。使用XSLT樣式表建立規(guī)范與映射，實現(xiàn)總線上XML之間的轉換，消除了添加、刪除等信息后，重新編譯和部署代碼的麻煩。
圖1 SOA-ESB企業(yè)整合架構
圖2傳輸協(xié)議轉換
2．2．2路由模塊
傳統(tǒng)的路由機制使用的是點對點的通信方式，在其請求消息頭文件中指定網(wǎng)絡地址，以致限制了路由的靈活性。基于內容的路由，根據(jù)消息內容動態(tài)的選擇相應服務提供者，提高了路由的靈活性。因此，本文選擇基于內容的路由。
基于內容的路由分為兩種情況處理：①服務無變更。各服務組件首先通過XML文檔將功能存放到功能總列表，作為找到相應服務的基礎，系統(tǒng)運行時，路由表根據(jù)消息的內容查詢功能總列表，明確服務提供者并且獲取其地址信息存入到該表中，進而找到路由的目的地：②當服務發(fā)生變更時，相應的服務功能會發(fā)生變化，影響到功能總列表中的功能信息。如果直接修改功能總列表，對于整個路由的維護將變的困難，在不影響其他非變更的服務正常路由的情況下，重新建立一個隊列，從此隊列中將服務變更內容刷新到功能總列表，保證服務的可用性，供路由表進行查詢，找到最匹配的服務消息傳遞路徑。
2．2．3安全模塊
系統(tǒng)從服務消息的發(fā)送端到接收端進行安全檢測。發(fā)送端，為消息設置一系列的安全屬性，如發(fā)送者、接收者、身份認證、時間戳、到期時間等，利用XML加密技術以及簽名技術對消息進行加密和簽名，其中服務公鑰基礎設施PKI中密鑰的注冊碼遵循XKMS規(guī)范；接收端，收到消息后檢查安全屬性，看是否匹配，消息接收時間是否過期，再通過XML解密技術對加密的消息進行解密，對于密鑰管理同樣遵循XKMS規(guī)范。另外對發(fā)送請求消息的用戶進行權限的驗證，使保證接入ESB的消息服務是合法的、完整的。
SOA-ESB企業(yè)整合架構的應用電力企業(yè)的信息管理系統(tǒng)發(fā)展較快，業(yè)務整合是必然的趨勢，要求整合的數(shù)據(jù)既能安全又能高效的進行交互。電力企業(yè)的物資管理、設備管理、財務管理等是SOA．ESB的原型系統(tǒng)，現(xiàn)已廣泛的應用于中小型電力企業(yè)。基于SOA．ESB企業(yè)整合架構的電力企業(yè)信息管理系統(tǒng)采用J2EE應用服務器Gomnimo，在Eclipse平臺下進行開發(fā)，選擇JAVA作為開發(fā)語言，總線上服務之間的調用使用簡單對象訪問協(xié)議SOAP、XML作為規(guī)范標準，通過傳輸適配、內容路由等關鍵技術，從體系結構的層次來低耦合企業(yè)應用系統(tǒng)，從而為企業(yè)業(yè)務整合提供有力的支持。
基于SOA-ESB企業(yè)整合架構的電力企業(yè)信息管理系統(tǒng)結構如圖3所示。
圖3基于SOA．ESB企業(yè)整合架構的電力企業(yè)信息管理系統(tǒng)結構
首先電力企業(yè)根據(jù)各自業(yè)務需求將各系統(tǒng)內部進行細粒度劃分，或根據(jù)整合業(yè)務進行服務組合，如可將物資管理的訂購和儲備封裝成Web服務，通過編寫XML文檔將訂購和儲備的功能存儲到功能總列表，同時將各Web服務的WSDL描述文檔(接口信息等)發(fā)布到注冊中心。當物資采購發(fā)出請求時，ESB根據(jù)消息內容找到相應傳輸適配進行協(xié)議和格式的轉換，并進行消息的安全檢查，其次路由表即可根據(jù)請求內容查詢功能總列表，獲取符合條件的服務信息，從而完成正確的路由。以下將闡述核心部分實現(xiàn)。
3．1非規(guī)范XML到規(guī)范XML
創(chuàng)建XSLT樣式表，行為的所有規(guī)則存儲于XML文檔中。通過樣式表的模板規(guī)則元素來確定XSLT如何轉換文檔中滿足規(guī)范的節(jié)點。在模板規(guī)則中，創(chuàng)建一個頂級元素用于指定哪些節(jié)點包含規(guī)則，在match特性中使用恰當?shù)腦Path表達式，可以把匹配XPath表達式的每個節(jié)點作為環(huán)境節(jié)點來訪問。為獲取被轉文檔中的XML元素，可以使用<value,>的select特性，特性中包含另一個XPath表達式，其值就是所選節(jié)點。輸出時，由于XSLT默認輸出是HTML格式，需把樣式表的XML文檔中<output>元素的method屬性設置為xml。創(chuàng)建樣式表后，即可通過編碼實現(xiàn)文檔轉換。
平臺采用Java語言開發(fā)，XSLT包含在JAXP(Java API forXML processing)API中，選用JAXP來實現(xiàn)。其轉換部分代碼如下：
首先創(chuàng)建Transformer對象，把XSLT樣式表加載到Transformer中，然后把源XML加載到StreamSource對象中進行轉換。為了實現(xiàn)輸出XML的中文支持，設置輸出的編碼格式為GB2312。創(chuàng)建一個File對象，把轉換結果寫到磁盤。Transformer執(zhí)行XSLT處理，得到最終符合平臺規(guī)范的XML。
3．2內容路由
以財務管理系統(tǒng)向物資管理系統(tǒng)發(fā)出請求服務為例。首先初始化功能總列表，將服務提供者物資管理的所有功能用XML進行描述，存儲到功能總列表中，其中service為提供服務的名稱，add為服務地址，content為功能名稱，number為功能標記號：路由用route：--<business，service>表示，其中business為業(yè)務流程名稱，service為服務的相關信息。在初始情況下，路由中服務add為空。初始完功能總列表后，路由根據(jù)消息的內容查詢功能總列表，確定服務提供者信息，檢索出服務的add信息并覆蓋到路由表服務信息中，如圖4所示。
根據(jù)消息的內容來確定路由的目的地，改變了傳統(tǒng)的一對一的靜態(tài)模式，使整個服務的操作變的更加靈活。
3．3安全處理
在發(fā)出的SOAP請求消息中，進行消息的數(shù)字簽名和加密。構造一個簽字元素security，再構造元素中的引用元素，指向要簽字的對象，如安全屬性元素等，再將與消息安全有關的XML信息放入security的子元素deal中，依據(jù)XML數(shù)據(jù)簽名規(guī)范分別對簽字元素進行規(guī)范化，計算出摘要值和簽字值：構造加密數(shù)據(jù)元素，設置相應的加密算法、加密對象引用等，根據(jù)XML加密規(guī)范對加密對象進行加密，加密后的值放入加密密鑰元素，再將其作為SOAP頭中security的子元素。以下是進行安全處理部分的代碼：
進行簽名時，得到封裝SOAP消息的信封，獲得用戶驗證信息并且產(chǎn)生簽名對象，用此簽名對象對消息進行簽名，從被簽名的信封中產(chǎn)生新的SOAP消息；同理，首先獲得加密前的SOAP信封。然后獲得用戶驗證信息并且產(chǎn)生加密對象，對獲得的SOAP信息加密，根據(jù)加密后的消息產(chǎn)生新的SOAP消息。從消息的發(fā)送至接收進行安全檢測，使服務的請求者和Web應用能安全可靠的進行通信。
圖4 功能總列表與路由
4 結束語
本文在遵循企業(yè)整合架構設計原則上，提出了一種輕量級的SOA-ESB企業(yè)整合架構，重點分析了架構中ESB總線層的傳輸實拍、內容路由、消息安全等關鍵技術，實現(xiàn)了整合系統(tǒng)數(shù)據(jù)交互的統(tǒng)一性、靈活性、可靠性等特點。經(jīng)時間證明，采用該整合架構的系統(tǒng)，能夠松散耦合得把異構系統(tǒng)連接到ESB總線上，提高其系統(tǒng)的重用性和數(shù)據(jù)交互的能力，為企業(yè)的發(fā)展帶來更高的效益，同時也為系統(tǒng)開發(fā)人員帶來便利。
轉載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/
本文網(wǎng)址：http://m.hanmeixuan.com/html/consultation/1083938131.html
相關文章
