主題數據平臺分析論文

導語：主題數據平臺分析論文一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

摘要本文在解決遠程開放教育系統的信息孤島問題的基礎上，總結出了一個通用的主題數據平臺架構。并進一步針對它在不同的環境、采用不同的策略，給出了實現框架。

關鍵詞SOA；數據平臺；信息暴露

1引言

本課題來源于中央廣播電視大學教務管理系統的后續開發。隨著中央電大在開放式教育思想指導下的教學改革的展開，系統業務量急劇猛增，原有的教學管理系統已經逐漸的滿足不了應用需求。所以新一代教學管理系統正在開發中，同時由于教育業務本身的連貫性，導致了新舊系統并行的局面出現。但是由于新舊系統間缺少關聯和通信以及必要的規范，導致信息“孤島”現象嚴重，而舊系統又恰恰是電大不可放棄的重要投資。同時由于各個系統集成度不足，運行業務的數據庫和應用程序也是在不同時期部署的，它們來自不同的供應商，使用各不相同的定制技術。從而面臨著如何構建一個強壯的、可靠的，將新舊系統中的分散功能組織成可共用的標準服務來滿足業務要求的平臺，成為我們需要研究的難點。

通過實踐我們可以發現，應用程序始終都與數據有關，企業級的服務程序更是如此。今天，企業應用程序開發中有高達70％的時間都是用于訪問不同的數據。因此，對企業信息和數據按業務邏輯進行梳理和抽取，形成企業數據的統一表現實體，該實體可以在全企業范圍內得到一致性的使用，是邁向面向服務的體系架構的第一步。因此我們提出了主題數據平臺的概念。

2主題數據平臺結構

主題數據平臺結構見圖1。主題數據平臺由：主題數據服務層、數據處理構件、數據處理管道、適配器構件組成。

圖1數據主題平臺的設計構架

主題數據服務層：是底層接口與上層應用的中間層，用于屏蔽底層接口，向上提供統一的服務。有兩種角色：一種角色是數據中轉站，用于保存臨時數據，并等數據傳輸完整之后，進一步對數據進行分析和處理；另一種角色是主題數據服務層角色，用于保存數據處理的最終結果：主題數據。

數據處理構件：是數據處理的基礎構件，每一個數據處理構件都封裝了一部分相對獨立的數據處理邏輯，包括刪除不需要的數據、補充缺少的數據、對數據進行簡單的四則運算、代碼轉換和按主題建立新的數據結構等功能。

數據處理管道：是由多個數據處理構件組成，它合理的組合和安排這些數據處理構件，從而完成復雜的數據處理邏輯。

適配器構件：用于實現異構數據庫與數據處理管道的無縫連接，從而能夠方便的從異構數據庫中抽取或插入數據。

3基于局域網的主題數據平臺的實現方案

基于局域網的主題數據平臺的實現方案見圖2。

圖2基于局域網的數據主題平臺的實現方案

由于局域網有著：網絡傳輸速度快、網絡故障率低、即時性強、服務器固定等優點。所以我們采用：DTS技術、Nmake技術、臨時庫等技術來解決基于局域網的主題數據平臺的實現問題。

3.1DTS技術的應用

采用DTS技術可以實現在局域網中從異構的數據庫中提取或插入數據，并能對數據進行簡單的邏輯操作。它可以把相對獨立的數據處理邏輯封裝在對應的DTS包中，從而把公用的數據處理邏輯從數據處理業務中提煉了出來，以備復用。并提供了工作流支持，保證了DTS包中數據處理業務的事務性和完整性。

⑴適配器構件

適配器構件只是一個數據處理通道和異構數據源的連接器，它負責從異構數據源中抽取或者插入數據并將數據轉移到數據處理通道中。每一個數據源對應一個或多個適配器構件，每個適配器構件包含在對應的DTS包中。整個DTS包中包含一個原數據源、一個目標數據源和一個數據對應轉換任務。將整個數據轉換邏輯封裝為一個構件，有利于適配器構件的復用。

⑵數據處理構件

數據處理構件封裝了數據處理邏輯，這些處理邏輯由數據業務驅動，包括刪除不需要的數據、從不同的數據來源補齊缺少的數據、對數據進行簡單的四則運算、不同信息系統之間的代碼轉換等功能。數據處理邏輯按其獨立性和公用性被封裝在不同的DTS包中，增強了數據處理構件的可變性和復用性。DTS包提供了驗證機制這既可以保證數據處理邏輯的正確性，又可以保證數據處理邏輯的事務性。DTS包內包含工作流，可以針對不同的情況做出不同的處理，極大地提高了數據處理構件的復用性，并可對業務性錯誤做出必要的處理。

3.2Nmake技術的應用

Microsoft程序維護實用工具Nmake是一個32位基于說明文件中包含的命令生成項目的工具。NMake具有豐富的選項，可以完成復雜的處理操作，并有樹狀文件任務處理結構，并且易于編寫，結構清晰，對于實現復雜的數據處理業務提供了很大的方便。采用Nmake技術可以有效的將結構松散的、相對獨立的數據處理構件聚合起來，從而能夠處理復雜的數據處理業務。

數據處理管道

數據處理管道是將數據處理構件有機的組合起來并封裝好，對主題數據服務層提供統一的訪問接口，從而把數據服務邏輯與數據處理邏輯分割開來。數據處理管道可以極大地提高數據處理構件的復用率，并把復雜的數據處理邏輯從數據處理構件中抽離了出來，當數據處理業務變動的時候不需要修改構件只要按著業務需求，重新組織構件即可解決問題。Nmake可以按著業務需求輕松地把數據處理構件組合起來形成帶有業務邏輯關系的數據處理管道，并且Nmake提供了業務流功能，針對不同的業務需求可以提供不同的業務流支持，從而極大的提高業務本身的靈活性。當業務需求變動時，Nmake可以通過重新組合數據處理構件來完成業務，而不需修改或者重新編寫數據處理構件，從而提高數據處理構件的可復用性。

4基于互聯網的主題數據平臺的解決方案

基于互聯網的主題數據平臺面臨的主要問題是如何通過遠程數據傳輸將互聯網的異地、異構的數據源中的數據傳輸到主題數據服務層中。數據一旦進入主題數據平臺的主題數據服務層，就可以使用和基于局域網的解決方案相同的技術對數據進行整理。通過遠程數據傳輸將互聯網的異構數據傳輸到主題數據服務層之后的功能與基于局域網的數據轉換接口的功能相同。

中央廣播電視大學遠程開放教育的教務管理系統是一個跨越44個省面向全國的開放式教育體系結構。該系統包含四級平臺、五種角色，由于其獨特性中央電大教務管理系統基于互聯網的主題數據平臺的搭建有如下4方面需求：

1）中央電大各個系統之間、中央電大教務管理系統各級平臺之間需要能進行靈活的數據交換。

2）每次交換數據的數據量可能達到GB級。

3）部分數據交換有實時性要求，在規定時間內客戶端必須收到響應，不能因為數據傳輸而推遲業務進度。

4）需要在網絡狀況不穩定的情況下完成數據交換，因為中央電大教務系統是跨越44個省的開放式教育系統，所以中央電大需要同44所省電大交換數據，在這種情況下網絡狀況不可預知、穩定性難以保證，但傳輸仍然需要進行。

4.1SOAP協議與Hessian協議的比較

目前，Web服務技術是解決異構平臺系統的集成及互操作問題的主流技術[1]。它所基于的XML已經是Internet上交換數據的實際標準，基于通用的進程間通信協議和網絡傳輸協議屏蔽平臺的差異，可以將各種異構環境下的通信及調用請求均統一為標準的Web服務格式[3]。

但是由于SOAP協議的結構問題會使封裝的數據膨脹數倍。當傳輸數據量比較小時，問題不是那么明顯，但是當進行大數據量傳輸時就會導致Web服務的傳輸性能在實際運用中降低了很多。這對于經常有大數據量數據交換的應用系統來說是不適用的。

CauchoTechnology公司制定的HBWSP（HessianBinaryWebServiceProtocol）[2]在這方面的有所突破。Hessian協議和webservice常用的SOAP協議類似，也是將協議報文封裝在HTTP封包中，通過HTTP信道進行傳輸的。因此Hessian協議具有與SOAP協議同樣的優點，即傳輸不受防火墻的限制（防火墻通常不限制HTTP信道）。Hessian協議的優勢在于：它把本地格式的數據編碼為二進制數據，僅用一個字符作為結構化標記，HBWSP封裝后的數據增量明顯小于SOAP封裝后的數據增量。并且相對于SOAP，Hessian協議的外部數據表示有3個顯著的優勢：

1）采用簡單的結構化標記。簡單的結構化標記減少了編碼、解碼操作對內存的占用量。編碼時，只需寫少量的數據，就可以標記結構；解碼時，只需讀少量的數據就可以確定結構。而且，簡單的結構化標記減少了編碼后的數據增量。

2）采用定長的字節記錄值。用定長的字節記錄值，解碼時，就可以使用位操作從固定長度的位獲得值。這樣不僅操作簡單，而且可以獲得較高的性能。

3）采用引用取代重復遇到的對象。使用引用取代重復遇到的對象可以避免對重復對象的編碼，而且也減少了編碼后的數據量。

因此使用Hessian協議傳輸數據量比SOAP協議要小得多。實踐證明，傳輸同樣的對象Hessian協議傳輸的數據量比SOAP協議低一個數量級。因此Hessian協議比SOAP協議更適用于分布式應用系統間大數據量的數據交換。

4.2Hessian協議的實現構架

Hessian協議的實現構架如圖3所示：為了實現Hessian構架，設計了下列組件：編碼組件、解碼組件、通信組件、報告故障組件、組件、調用服務過程組件。

圖3Hessian協議的實現構架

首先客戶端發出本地請求，組件響應請求依據服務接口，生成客戶端存根，并調用編碼組件對本地請求進行基于HessianBinaryWebServiceProtocol標準的二進制編碼。然后調用通信組件將請求發送給服務器端。服務器端通信組件接收到請求后把請求轉發給調用服務過程組件，調用服務過程組件會首先調用解碼組件，得到過程標識，將過程標識轉給服務器端存根，并依據部署文件和客戶端的請求加載服務過程的實現類。然后根據過程標識、過程參數調用服務過程。最后調用編碼組件將響應結果進行編碼并通過通信組件返回給客戶端。

當數據傳輸、通信發生錯誤的時候就需要啟用報告故障組件，它可以以異常的形式，報告發送端、接收端、或者網絡連接發生的故障，并把錯誤記錄以日志的方式記錄下來保存在文件中，以備日后查閱。

4.3實現結構

針對教務管理系統互聯網傳輸存在的一系列問題，基于互聯網的主體數據平臺采用基于HBWSP的輕量級跨平臺通信技術實現數據交換，如圖4所示。在客戶端，應用服務器從主題數據服務層中抽取數據，并按著HBWSP的外部數據表示對本地格式數據進行編碼。然后通過internet網進行傳輸，在服務器端，數據交換的服務負責按照HBWSP的外部數據表示對接收到的數據進行解碼，然后再對數據進行分析、處理后把數據插入到服務器端的主題數據服務層中。

圖4非持久同步方式的數據交換解決方案

該解決方案的主要特點包括：

1）采用了HBWSP的二進制編碼方式解決了異地、異構平臺系統的通信問題，并使數據交互具有了一定的實時性。

2）由于HBWSP簡潔的編碼方式以及編碼、解碼性能高等特點使數據交換具有交換GB級數據的能力。

3）采用了HBWSP的二進制編碼方式有助于縮短整個數據交換所需要的時間。其編碼性能高的特點，有助于提高編碼速度，減少發送方編碼本地數據的時間。其解碼性能高的特點，可以減少接收方解碼、重構本地數據的時間。從而減少了數據交換的響應時間。

4）采用了HBWSP的二進制編碼方式和數據分批傳送技術有助于充分利用網絡狀況良好的時段。可以在網絡狀況良好的時段盡可能多的完成數據交換。

5）采用了斷點續傳技術，保證了當網絡斷連或響應超時導致正在進行的數據交換被中斷，在故障修復后仍然可以從中斷處開始，繼續完成上次沒有完成的數據交換的能力。斷點的粒度可以調節，可以是一條數據，也可以是多條數據。

6）采用了事務保護機制，把每批要傳輸的數據定義為一個事務，本批要傳輸的數據的事務完整性不依賴于已經完成的各批數據，本批數據傳輸發生錯誤也不會對已經完成的各批數據造成影響。采用這種方法，可以在數據交換過程被中斷的情況下保證數據交換事務的完整性。

5總結和展望

本文在SOA理論的基礎上提出了一個主題數據平臺的概念，力圖把異地、異構的數據綜合起來，組成一個強壯的、高可靠性的、可共用的標準數據服務平臺。從而解決中央電大新舊教學管理系統數據“孤島”的問題。我們再進一步針對現實環境：局域網和互聯網兩種情況進行了分析，并給出了實現框架和技術細節。

但是如何在信息暴露的基礎上，對業務應用進行進一步的梳理、劃分、整合，從而封裝成用戶可以隨意組合、使用的標準服務，從而實現真正的SOA，是需要我們進一步研究的內容。

參考文獻

[1]GeorgeCoulouris，JeanDollimore，TimKindberg.DistributedSystemsConceptsandDesign.金蓓弘.第3版.機械工業出版社，2003：134-150

[2]CauchoTechnology，inc.Hessian1.0.1Specification.http：///hessian/hessian-draft-spec.xtp

[3]RameshNagappan，RobertSkoczylas，RimaPatelSriganesh.DevelopingJavaWebServicesarchitectinganddevelopingSecureWebServicesUsingJava.龐太剛，陶程.清華大學出版社，2004：17-18