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