淺談基于SOA 的數據交換中心的設計和實現論文
一、背景概況
在學校進行了長期的信息化建設的過程中，數據交互領域的建設一直是核心工作，這也是在取得了一定的收獲的信息化校園建設過程中，所反映出的基本問題所決定的。原有的學校各部門，在進行相應的信息化建設過程中是屬于無須也無標準的，這樣，各部門之間的數據聯通是相應比較困難的，而各個信息系統所謂的封閉和異構，使得學校完整的信息化建設無法得到很好的發展，這也是我們提出該研究方案的初衷。現在各類設計類型很多，但是基本的實施模式就有點對點和集中式的兩種，以下就這兩類的異同進行說明。
1)模式一：點對點構架，在各部門不同的服務器和軟件上要進行數據交換，就必須單個個體間進行點對點的連接，協議在這個過程中是一臺機器到另一臺機器，這樣的交換方式叫點對點方式，這個方式有優點在于，不需要過多的復雜機構和硬件，只需要機器，機構相對比較容易實現也簡單，不需要依賴其他產品，任何一個節點的錯誤對其他的整體或者節點不會造成什么影響。但是，這樣的連接方式也會有缺點，就是機器到機器之間的連線是一對一的，這樣當機器成倍增長，這樣的連接也會飛躍式的增長，其次，建立連接的雙方必須同時在線，這樣使得使用起來變得非常不方便。
2)模式二：集中式架構，在機器與機器交換之間會有一個交換機制來進行管理，機器要對另外機器進行連接，必須先對中間交換機制連接，從而找到對方的地址，才能和對方進行通信，這樣的方式有優點，就是連接數并不會增長太快，機器和機器連接不一定要隨時都在線，當然，這樣也對設備的類型有要求，并且負載量是較大的，類似總線型的傳輸會有瓶頸。
模式二的方式其實更有可操作性，當然這樣的架構往往先從數據中心開始，才向外圍進行其他中心的建設。我們需要的整合確是從原有的很多不同系統中進行的整合�，F在要說的方式是通過現有的B/S 結構加上不同數據整合形成的一類后期建設的數據交換中心。
二、SOA的概念及數據交換理論基礎
(一) SOA的概念
在整個軟件設計分析演化過程中，從面相過程到面相對象，直至現在的面向服務，是由人們需求逐步提升的一個過程，而現在提到的SOA就是面向服務的軟件系統構建方法。
SOA是分布式軟件系統構造方法和環境的新發展階段，是包含運行環境、編程模型、架構風格和相關方法論等在內的一整套的分布式軟件系統構造方法和環境，涵蓋服務的整個生命周期：建模一開發一整合一部署一運行一管理”。
SOA((Service—Oriented Architecture，面向服務的體系架構))，對于業務集成的過程來說，設計者往往都會考慮到一個企業化的架構的原型化事物，就其體系架構而言，分為以下幾個部分：
既然是面向服務的架構體系，那么服務作為一個核心，必然成為了各個業務手段的抽象對象，在這樣的過程中，各項業務成為了相對獨立的個體，各個個體之間相互成為了可以分布成為個體的每個細節業務邏輯。這個時候，服務就不單純是服務，而可以定義與業務之間的相應聯系，就像一些規則要求的約束，在這個環境就有了響應的處理機制。
這使得構建在不同系統中的服務可以以統一的!通用的方式進行交互" 除了這種不依賴于特定技術的中立特性，其通過服務注冊庫(ServiceRegistry) 加上企業服務總線(EnterpriseServiceBus，ESB)來支持動態查詢、定位、路由和中介(Mediation) 的能力，使得服務之間的交互是動態的，位置是透明的。
所以，SOA的意義就是利用一種廣泛互用標準，成為各個不同架構細節的統一安排者，它更多的是研究各個細節個體的裝配，不需要重視底層的編碼等情況。
(二) Web Service 技術
Web Service 技術在一開始初期就有人進行了定義，其在于規范了一種組件，使得通過Web 調用的各項內容可以通過這樣的規范組織在一起，WebService 從現今的發展來看，已經是基于瘦客戶端的必然組成模式了。
WebService 構成主要有以下幾點：
1) Service：Service 是一種應用程序，提供者將它公布到Internet 上提供服務。
2) WebServiCeProvider：從架構面來看Service Provider，它是提供服務及服務本身的執行環境
3) WebServieeRequester：某種Client 或應用程序，在Internet上搜尋，使用WebServiee。
4) WebService Registry (Broker)：是一種儲存webServiee信息的環境，讓ServiceProvider 注冊公布ServiCe 的信息，讓ServieeRequester 搜尋服務，并取得和WebServiee 溝通的相關信息。
三、數據交換中心的設計
(一) 數據交換中心體系架構
數據交換中心采用分布式的思想，可以使得在模式二基礎上進行真正的數據交換應用，也真正讓不同部門的機器聯系在了一起。
(二) 物理結構
部門服務器都通過數據交換中心進行連接，進行數據交換的操作。這樣，作為中間節點的路由器，就成為了整個交換過程中的一員，通過路由器和數據交換中心服務器之間的這樣結構，可以把模式二很好的實現。
(三) 數據交換中心的層次結構設計
通過設計的數據交換中心物理架構，可以對其進行層次結構的設計，這樣把數據，實際交換和適配過程由不同層來處理，可以提供更好的數據異構，也更好的可以把數據標準后的格式進行轉換，從而實現各項消息服務，數據上傳下載，數據交換等功能。
(四) 數據庫的設計
數據交換中心原本就是為了完成不同系統之間各類數據的交換，并且可以提供一系列接口服務，用來拓展整個系統。在這種情況下，可以把數據庫分為以下幾類：
其一：數據儲存類，就是可以把需要進行交換的數據進行儲存的一類信息，可以通過XML語言進行標識。
其二：數據交換類，可以進行存儲過程并可以進行實際執行的這類規則語句，可以進行各類數據的實際交換。
其三：數據管理類，存儲管理數據交換中心并是得整個系統有序。
(五) 數據交換協議的設計
協議作為兩個不同機制系統的連接基礎，需要是標準而規范的，采用什么平臺，什么規范，才能夠將一個數據轉移到另一個數據集群中，數據是有可讀性的，這樣，在學校的這個可能會范圍擴大的地方也需要有很強的擴展性。在這一基礎之下，我們的系統平臺，采用了XML語言，這樣標準化語言就可以支持很多不同服務器在不同的環境下使用了。
1.數據范式協議
在定義中，我們既然使用了XML語言，那么我們的實際范式也需要規范，我們系統的交換中心數據范式規定者以下三個部分的不同要求，其一是數據頭部，頭部就記錄著發送機器、發送者和明文字段等相應交換必須的數據，其次是數據主要的部分，這個地方就包含著相應實際的數據內容，最后是一些其他內容所可能占用的數據位置。
2.服務器地址分配規則
在多臺服務器同時出現于一個環境中，我們現在采用了負載均衡算法，進行實際的服務器地址分配，從而將服務器地址有規律的進行實際分配，形成可以定義的服務器地址分配規則。
四、數據交換中心的實現
本系統使用J2EE 的基本架構，使用Web2.0 技術，在任何一類終端都可以使用，而數據庫使用Oracle，可以對接其他多種數據庫。
(一) 主要的一些模塊
我們將實際系統分為主要的幾個模塊：用戶管理模塊，數據管理模塊，服務模塊，系統監控及維護模塊，接口調度模塊。
用戶管理模塊：就是確定用戶權限和用戶添加、刪除、修改、查詢的模塊;
數據管理模塊：就是數據在整個過程中上傳、下載、查詢等實際監控管理的模塊;
服務模塊：就是進行隊列管理等相應的交換設置的模塊;
系統監控及維護模塊：就是對系統進行監控及維護，可以進行內核調整的模塊;
接口調度模塊：就是制作接口，并且使接口可以和其他系統對接的模塊。
(二) 安全設置等相應問題
數據交換，但是不能引起數據不安全，所以這樣一來，我們就要對最基本的XML進行一些設置，由于XML的常規默認規則，是得大部分可以被直接閱讀，減低的安全性，這樣的情況我們就需要采取以下措施：
1)用戶認證機制
2)信息保存和恢復機制
3)機密分級機制
在使用過程中實際人為也會造成一些影響，對認為影響我們有以下方法：
1)建立內部網絡，使用獨立域或者是VPN;
2)建立身份認證機制及認證中心，是整個數據的流動有用戶操作可查;
3)進行密文加密和協議加密。
五、結束語
數據交換中心在半年的設計過程中，進行了反復論證及探討，最終成為了一套實際運行有效的系統，在學校的長時間發展中，我們也需要進一步了解系統的整個運行過程和方法，使得在以后的使用中數據交換中心發揮出其更加有意義的地方。
【淺談基于SOA 的數據交換中心的設計和實現論文】相關文章：
淺談基于Openstack 的網絡攻防實驗平臺設計與實現論文02-20
淺談問題設計論文02-24
淺談組件機制和操作系統的實現11-30
論文提綱范文：系統設計與實現05-27
淺談基于條碼技術的庫存管理系統設計11-17
淺談基于CDIO的云計算專業導論改革論文03-19
綜合評價系統設計與實現論文提綱11-18
個人網站的設計與實現論文開題報告02-20