公共數據交換解決方案
要實現的目標：
l 爲整個項目系統提供統一的數據交換標準、規範及開發平臺；
l 爲各個系統之間、異構數據庫之間、不同網絡系統之間的信息提供整合手段；
l 與外界系統提供統一的、安全的、可靠的連接手段。
1 數據交換的需求分析
l 基本功能：數據的發送與接收。
l 數據交換的語義識別：數據格式、語法所描述的信息應該有效，各種系統在傳遞、讀出、解析和使用文檔中的信息不會產生二意性。
l 傳輸的要求：數據格式易於傳輸，能夠實現各個應用系統之間的同步、異步信息交換。格式技術兼容各種網絡系統和通訊協議。
l 安全方面的要求：交換的數據文檔需要基於應用系統之間約定的規則進行驗證，要能建立數據格式、數據內容、網絡傳輸等不同層面的安全防護機制。
l 提供應用整合功能：自動分發或者觸發相應處理程序處理所傳輸的數據。
l 斷點續傳功能：不重傳、漏傳、斷點續傳，實現高效傳輸。（使用JMS重新傳送，保證傳送的完整性）。
l 非功能性要求：格式穩定性高，易於管理，有良好的可擴展性和可增長性。使用該格式可降低人力運作。
2 數據交換的原理
2.1 數據交換的模型
數據交換通過網絡進行的，而網絡信息交換有國際公認的OSI七層模型，而電子政務的數據交換隻注重應用層、表示層。如下圖：
圖1 OSI七層模型
在此模型中，應用系統之間按應用層協議進行通訊，應用系統內部依靠接口提供服務。而在網絡中，爲了保證應用系統能理解數據傳輸的要求，在傳輸者、接收者之間是以XML作爲媒介。
2.2 數據交換結構
從OSI七層網絡模型分析數據交換平臺主要是解決應用層和表示層的內容。爲了確定設計交換平臺的功能，把表示層按功能劃分爲：內容管理層、數據交換層、數據傳輸層。由於本業務應用系統都處在應用層，所以應用層層也就是OSI中的應用層。
OSI中的表示層在層次上分爲：內容管理、數據交換。
1）內容交換（表示層）
內容管理層是指內容的表示（存儲）、操作（傳送）和授權管理等功能。
一個標準的數據交換平臺的任務可以分爲兩個方面：一個是對遺留業務系統的數據進行整合，爲交換和共享做準備；另一個是通過規範化的方式對業務系統提供統一的數據訪問支持。這就要求標準數據交換平臺遵從統一的數據表示方式，採用標準的XML表示數據，XML的DTD可根據業務不同而定義。
內容管理層在工作的過程中，如果有需要跟遠端的其他數據交換點進行互操作的時候，通過數據交換層來完成。
在內容管理層提供簡單易用的界面方面用戶輕鬆定義各種類型的XML格式文件和二進制文本格式文件。然後該功能模塊會生成對應格式的Schema（DTD）和模式文件。此外，提供驗證機制用於檢驗所建立數據格式模型的正確性。
2）數據交換（表示層 信息服務的支持）
數據交換層的任務是完成不同數據交換點之間的互操作，官能上應該包括數據的定位和數據包封裝。數據的封裝和解封與操作命令一樣，是一個標準數據交換平臺的規範性的重要體現。所有在節點之間傳送的數據，寶座操作命令本身，都要按照規定的格式進行編排，這樣才能保證數據交換節點之間的互操作性，以屏蔽底層的物理特性的多樣性。所以必須解決以下問題：
l 信息的統一封裝，即信息的打包和信封的書寫功能
l 統一編址，應支持一套統一的、簡單易用、易擴展的地址編碼體系
l 信息的可靠傳輸
l 傳輸的效率
l 可管理性，要對傳輸的過程進行全程監控，提供日誌、審計、會話管理、傳輸優先級設定、流量負荷分析。
3）安全的數據傳輸（表示層）
數據傳輸層用於實現數據交換結點之間的數據傳輸。在軟件層面，重要的一點就是要採用成熟的傳輸協議，如HTTP或者SOAP。
l HTTP協議具有簡單、完備、輕量級、擴展能力強等特點。較小的傳輸開銷可以保證較強的傳輸性能，完備的協議規程可以保證傳輸的穩定性。同時，通過適當的擴展，可以提高可靠性和完全性。
l 安全性可以通過引入基於PKI（Public Key Infrastucture，公鑰體系）的CA（Certificate Authority，認證中心）體系來解決。
3 數據交換中心的設計
3.1 信息的統一表示
要實現信息共享，實現異構系統之間的互連互通，信息的統一表示是關鍵，信息的表示獨立於系統、平臺。爲了實現這一目標，在進行平臺開發、應用系統開發時要制定或遵循六個方面的信息標準：
1）元語言標準
元語言是描述其它語言的語言。電子政務的信息表示語言採用XML元語言標準。該標準用來對政務信息的語言的語法、編碼、令名進行行式化描述。該標準可採用W3C制定的XML元語言標準，設計者應根據電子政務中的信息表示的需求進行裁剪。
2）信息編碼標準
該項標準對字符的編碼、字符集定義、字符引用、字體的表示進行了規定。一般採用W3C制訂的XML1。0爲基礎，以GB13000爲缺省的字符集，同時也能支持GB18030字符集標準。
4）元數據標準
元數據是描述電子數據的數據，制定該標準是爲了方便政府信息資源有效的保存、查詢、再利用。在XML標準中，元數據的表示採用了“詞彙表”、“命名空間”、“文檔類型定義（DTD）”、XML Schema等方式實現。
在異構關係數據庫之間還可通過建立元模型統一數據的語義。
5） 顯示標準
在業務應用系統中，要將數據和數據的顯示分開。這樣就把數據的加工同不同的輸出、顯示分開處理，而不會造成HTML中文檔結構的複雜性。顯示在不同設備上，但內容只有一個。顯示標準一般採用W3C推薦的層疊式樣單CSS、可擴充式樣單語言XSL。
6） 解析、轉換和封裝標準
要實時共享交換的各種信息，必須具備效率高的數據結構封裝、解析、轉換的功能，因此必須有相應的標準。
3.2 完整的消息服務能力
數據交換平臺是一箇中間件軟件，它在信息交換過程中要進行頻繁的信息封裝、控制信息的同步/異步交換、排隊處理等。所以它要有好的信息服務機制，這就必須解決以下的問題：
l 信息的統一封裝：信息的打包和信封的書寫功能
l 統一編址：應支持一套統一的、簡單易用、易擴展、易管理的地址編碼體系
l 信息的可靠傳輸：將信息可靠的傳輸到目的地
l 路由管理：在多個信息交換節點時，實現信息的準確傳遞。
l 傳輸的效率：採用信息的表示與交換分開、專用的交換設備、信息壓縮等方法提高傳輸的速度。
l 可管理性：要對傳輸的過程進行全程監控，提供日誌、審計、會話管理、傳輸優先級設定、流量負荷分析
3.3數據交換平臺的體系結構
實現信息的交換根據環境的不同有三種方式：
1）具有相同數據庫管理系統（DBMS）的分佈式系統的數據交換，可直接用相應系統的有關功能：
l 在ORACLE系統中，可以利用快照技術實現表數據的交換
l 在DB2系統中，可以利用複製服務器實現數據的交換；
2） 利用已有的消息中間件服務器：IBM的MQSerries、BEA MESSAGE()以及JAVA的消息服務JMS來實現。
在本系統設計中，採用JAVA的消息服務JMS。
4 基於XML的JMS數據交換設計
4.1交換系統層次結構
圖2 交換系統層次結構
4.2數據交換系統邏輯
圖3 數據交換邏輯
4.3 源數據的封裝
從數據庫中讀取需要交換的數據，封裝成XML文件中，如圖4。
l 使用SQL存儲過程從DB2檢索SQL結果集；
l 將SQL結果集格式化成XML數據文件。
圖4 數據庫數據到頁面數據的轉化
對於把數據封裝成爲XML文件，DB2 支持多種爲 XML 抽取數據的方法：
l 使用 DB2 XML 擴展器（extender）和用戶定義的函數
l 使用 XML UDF（用戶自定義函數）來將存儲過程結果集轉換成 XML 文檔
雖然在 XML 存儲過程而不是 SQL 存儲過程中聲明遊標，可以完全消除了對 SQL 存儲過程的需求，並且再也不需要返回結果集。然而，讓 SQL 和 XML 存儲過程保持分離的一個原因是：可以通過直接調用 SQL 存儲過程以 SQL 格式檢索數據，或者通過調用封裝器 XML 存儲過程以 XML 格式檢索數據。
而將XML數據如何格式化成爲HTML文件則不在本方案考慮的範圍之內。
4.4 MQ數據發送
4.4.1 MQ的簡單介紹
JMS是Java API, 允許應用程序來建立、接收和讀取消息。程序依靠這些API, 在運行時需要一個JMS實現接口，來提供管理和控制，這被稱爲JMS provider, 現在有幾種不同的JMS Provider; 在JBoss中的JMS叫做JbossMQ。
當我們發送一個消息，不能直接發送到對此消息感興趣的接受者。而是發送到一個目的地。對此消息感興趣的接受者必須連接到目的地，得到此消息或在目的地設置訂閱。這樣，就實現根本上的異步性和安全性。
4.4.2 基本流程
（1）訂閱發佈式的MQ
將封裝好的XML文件以字節流的方式通過MQ中間件，採用持久性的發佈訂閱方式，把消息發佈到應用服務器上（如JBOSS）。當消息訂閱者與此服務器相連接時，如果有發佈給自己的消息，就會取走。如果不是所有的消息訂閱者都訂閱到此消息，JBOSS服務期將始終保存此消息，同時，訂閱過的訂閱者將不會重複訂閱此消息。在此過程中，不要求發佈者和訂閱者同時連接中間服務器，而且此消息可以存放到服務器的文件或者數據庫中，即使系統崩潰，也不會丟失，能夠恢復。所以具有能簡單靈活地集成各個數據庫子系統並自動實現數據採集和分發的功能。
（2）點對點式的MQ
如果採用PTP（Point-To-Point）的MQ消息傳遞方式，同訂閱發佈式類似，不同的是MQ負責把每一個消息傳遞給一個特定的消息消費者，一旦此消費者消費了此消息，其他的消費者將不會得到這個消息。
4.4.3 MQ的獨特優勢
MQ提供了強有力的消息處理機制，支持事務、持久性、可靠性的訂閱措施以及消息的選擇和分類。
（1）MQ與傳統方式的比較：
圖5 MQ與傳統方式的比較
（2）時間獨立性，即異步性：
圖6 MQ的異步性
（3）提高應用開發的速度和質量：
圖7 MQ的高速度、高質量
（4）增強系統的可維護性：
圖8 MQ的可維護性
（5）訂閱發佈式的優點：
圖9 MQ訂閱發佈式處理消息
點對點式（PTP）消息處理：
圖10 PTP消息處理
4.5 目的數據的解析
因爲是符合標準的XML格式文件，所以使用一般的解析XML組件或者中間件即可轉化爲自己所需的格式數據。
4.6 交換系統的特點
l 數據交換與應用處理相互獨立：交換系統真正做到了在數據傳輸時與數據的內容、形式無關；
l 事務處理：MQ可以與事務很好的結合在一起，保證了消息的可靠性。
l 與應用系統的良好接口機制：爲應用系統提供封裝適度的API接口；
l 中間件產品帶來的所有優點：數據傳輸的安全性、可靠性、與網絡環境的無關性、跨平臺性。
備註
本文章中大部分內容來至IBM官方網站以及其他網上文章，但是其來源已經不祥，爲此對原作者表示歉意。本人只是將其組合，加上一些自己的觀點。