1、數據交換平臺設計說明書文件編號TH-DEP-TD-01文件狀態 草稿 正式發布 正在修改當前版本1.1修訂歷史記錄 A - 增加 M - 修訂 D - 刪除變更版本號日期變更類型（A*M*D）修改人摘 要目錄1. 引言71.1 編寫目的71.2背景71.3 術語與縮寫解釋81.4 參考資料82. 概要設計82.1 平臺設計與定位82.1.1 概述82.1.2 與現有系統的關系102.2 硬件與網絡122.2.1 核心硬件和網絡122.2.2 外圍硬件與網絡132.2.3 網絡互聯的安全132.2.4 節點部署說明142.2.2 軟件系統152.3 核心軟件系統結構162.3.2 第三方數據源1

2、72.3.2 數據接口層182.3.3 傳輸控制層192.3.4 數據處理層202.3.5 交換數據庫212.3.6 數據展現界面212.3.7 數據應用接口222.3.8 上下級系統數據共享222.3.9 數據交換標準222.4 核心軟件系統設計原則242.4.1 自動化數據交換242.4.2 可定制數據交換242.4.3 多重方式數據的展現與利用252.4.4 數據全生命周期管理252.4.5 數據字段業務標準262.5 數據存儲設計262.6 數據流管理設計273. 技術架構設計283.1 概述283.2 基礎組件293.2.1 Spring Framework293.2.2 Swim

3、Framework303.2.3 Piston遠程數據交換中間件323.3 領域模型和邏輯設計343.3.1 概述343.3.2 任務調度引擎343.3.3 規則處理引擎373.3.4 系統核心功能設計概述433.3.5 數據導入設計433.3.6 數據加工設計513.3.7 數據應用設計583.3.8 數據上傳和下發設計643.3.9 任務監控管理中心設計713.3.10 系統權限設計723.3.11 數據權限設計753.3.12 數據標準設計763.3.13 現有系統集成設計783.3.14 數據使用反饋設計794. 系統功能設計814.1 概述814.2 數據交換部分824.2.1 數據

4、交換流程834.2.2 交換項目設置834.2.3 交換項目調度894.2.4 交換項目的監控894.2.5 數據交換的一些原則914.3 數據加工部分914.3.1 數據加工流程924.3.2自動匹配934.3.3 手工匹配984.3.4手工撤銷匹配994.3.5 數據匹配綜合管理1004.4 數據應用部分1014.4.1 數據字典查詢1024.4.2 交換項目情況查詢1034.4.3 按交換項目的簡單數據查詢1034.4.4 單戶明細信息查詢1044.4.5 數據輸出接口1044.4.6 對于異地數據交換的說明1054.4.7 成果展示1054.4.8數據利用反饋展現1064.5 數據上傳

5、下發1074.5.1 數據上傳1074.5.2 數據下發1084.5.3系統全景圖查詢1084.6 系統設置和管理部分1094.6.1 層級管理1094.6.2 崗位設置1104.6.3 權限管理1114.6.4 代碼表設置1114.6.5 交換項目設置備份和恢復1111. 引言1.1 編寫目的根據江蘇地稅第三方數據交換平臺系統需求思路以及多次需求和技術討論會，特別是3月份和7月份演示討論會后，依據省局領導的意見，形成該三方數據交換平臺的技術設計說明書。該文檔把三方數據交互平臺的技術和功能方面的設計，通過文字和圖表明確的表述出來，以供領導審閱。同時，也依據該設計文檔，進行下一步的設計和開發工作

6、。1.2 背景根據省局關于委托常州地方稅務局開發“第三方數據交換平臺項目”的通知的要求，立足于全省地稅系統應用和管理的實際情況，開發建設具有通用性、適應性強的數據交換平臺。 該平臺是支撐稅源專業改革新模式的重要數據平臺，為風險管理平臺和日常稅源監控及稅收分析提供了強大的第三方信息庫。該平臺的開發立足于第三方信息進得來、管得住、整合得好，為風險平臺的后期數據應用及其它業務需求提供可靠的信息源，為稅源專業化改革的深化推進提供重要的支撐平臺。1.3 術語與縮寫解釋縮寫、術語解 釋ETLExtract,transform and load. 數據處理的三個環節：抽取、轉換與裝載。MVCModel,vi

7、ew and controller. 一種系統設計的常用模式：模型、視圖、控制器。IOCInversion of control. 控制反轉，面向對象設計的一種模式。AOPAspect Oriented Programming. 面向切面編程，軟件設計的一種方法。RPCRemote procedure call. 遠程過程調用，一種協議和程序調用方式，使得遠程程序的調用跟本地程序調用在調用者角度沒有差異。1.4 參考資料江蘇地稅第三方數據交換平臺系統需求思路2. 概要設計2.1 平臺設計與定位2.1.1 概述從核心數據處理功能來講，三方數據交換平臺設計實現為一個數據ETL（Extract Tr

8、ansform Load）平臺，該平臺首先從定義好的第三方數據源抽取（Extract）數據，然后經過轉換（Transform）處理進入平臺系統，最后通過一定的技術手段裝載（Load）為可以直接應用的數據，如下圖所示。數據ETL過程圖三方數據交換平臺是一個專注于數據處理的技術平臺，它將提供豐富的數據導入、處理和應用方式，充分考慮多種應用場合，實現方便的定制功能，使得操作人員在數據處理層面上有多種多樣的選擇方式，可以根據不同數據來源和去向定制各異的數據導入、加工與應用規則。三方數據交換平臺也是一個相對獨立的系統，它與其它系統之間沒有業務上的直接耦合關系，對外它只提供數據的輸入接口和輸出接口，僅僅是

9、數據的采集和提供者。所有的數據業務關系，是通過平臺的使用人員通過不同的數據處理規則去定制實現的。在這種機制下，業務規則不是固化在平臺實現里，從而提供了極大的靈活性，增強了系統的可使用性。下面的三方數據交換平臺示意圖比較直觀的顯示了上述內容。三方數據交換平臺示意圖通俗來講，三方數據交換平臺可以視作一個數據加工廠和數據流橋梁。原始的三方數據相當于原料，原料進工廠（數據導入）以后，經過加工過程（數據加工），成為可以發售的產品（可以應用的數據）。除了數據工廠作用以外，它還是數據流環節中的一個橋梁，通過這個橋梁，數據可以在不同的應用系統之間進行流動。2.1.2 與現有信息系統的關系三方數據交換平臺建設的

10、初衷不是一個孤立的系統，它是為了加工處理數據，進而為其他系統服務的。在現階段，可以預見的跟它有數據關系的系統包括政府公共信息網、省地等級別的相關數據系統（國稅、工商、供電、供水、社保、國土等等）以及地稅內部現存的信息系統，包括大集中系統、風險管理平臺等。三方數據交換平臺系統在這樣一種關系網絡中，處于中間地位，通過該平臺的建設，打通數據在現有的這些系統之間的流動路徑，使得原本孤立的這些信息孤島能夠連成一片，實現信息數據的共享和應用。它是各個系統之間的紐帶，為建設綜合治稅這樣的大概念平臺打下了堅實的基礎。三方數據交換平臺關系示意圖因為現存的系統各種各樣，對外的接口也不盡然相同，所以為了盡可能多的適

11、應當前系統，在對當前系統對外接口不做過多的改變的前提下（事實上，要對現有系統接口做修改在很多情況下沒有太大的可行性），三方數據交換平臺將會提供多種形式的數據輸入接口和輸出接口，這在后續將會詳細講述。因為當前需要接入的系統就很多，業務規則也千差萬別，未來也可能有更多的系統接入，所以三方數據交換平臺不可能一開始就設計好與其它系統之間的業務關系，否則接入一個新的系統，平臺就要做相應修改，這個工作量是不可想象的。所以，三方數據交換平臺設計為和其它系統之間并沒有直接的業務耦合關系，它只是提供了多種多樣的數據處理規則和方式，讓平臺系統的操作人員去動態的定制，這樣間接的實現了業務規則的轉換，從而為多種不同業

12、務系統的接入，提供了可能性。站在其它系統的角度來看，三方數據交換平臺僅僅提供了數據的輸入和輸出接口。從三方數據交換平臺內部來看，它提供了多種多樣的數據處理規則，通過這些規則的靈活定制，實現了數據的業務處理。 2.2 硬件與網絡2.2.1 核心硬件和網絡核心硬件與網絡是指本系統在稅務系統內部的硬件與網絡部分。從宏觀來講，該平臺是一個分布式系統，由地理位置上分離的各個數據交換平臺軟硬件系統節點組成。從單個數據交換平臺軟硬件系統節點來看，它又是一個自成體系的系統。所以，網絡和硬件的設計也必須按照數據交換業務的實際需求來設計，實現互聯和安全訪問。對于部署在不同地理位置的數據交換平臺軟硬件系統，稱之為節

13、點。從上下級關系來看，系統的部署可以分為多個級次，每一級次都是由一個到多個節點組成。例如，在省、市兩級進行部署，省、市分別為部署在本地的數據交換平臺軟件系統準備合適的硬件平臺和網絡環境。另外，在網絡結構上，具有上下級關系的節點之間的能實現相互訪問，而同級節點之間，則不一定需要直接進行相互訪問這樣的功能。在這一級別上，可以采用專網、防火墻等技術實現該平臺所需的分布式網絡。2.2.2 外圍硬件與網絡外圍硬件與網絡是指和第三方數據源直接有干系的硬件和網絡。因為第三方數據源的情況現在并不明朗，只有到具體接入實施的時候，才會知道具體的情況。所以，為了考慮兼容和接入不同的三方數據源，網絡接口的設計也需要具

14、有比較大的靈活性。關于外圍硬件與網絡，需要在幾個不同的方面加以說明。首先，在通信的發起上，分為主動和被動方式。主動方式是指核心網絡主動去訪問第三方數據源，這一形式只能在第三方數據源提供了網絡連接支持，并開放了訪問權限的前提下，才能實現，那么這需要第三方數據源提供接口主機并保證數據安全傳輸的前提下，以專網或公網為傳輸媒介進行通信。被動方式是指在核心網絡的外圍，提供可以訪問的接口主機，提供多種可以訪問的手段，讓第三方數據源主動發起數據通信。其次，在網絡的接口和互聯上可能有多種形式，包括直接互聯走專網的方式以及在公網上間接提供接口主機的形式。那么接口主機可能位于核心網絡，也可能位于第三方數據源，這要

15、看通信由誰發起來決定。2.2.3 網絡互聯的安全因為數據交互牽涉到大量的保密數據的交換，所以在硬件互聯層面上，安全性也是非常核心的一環。在本系統設計和部署的時候，將嚴格按照地稅和相關其它部門的安全規范和規定，確保萬無一失。另外一點就是，本系統只部署在安全網絡環境內，不考慮直接通過Internet和第三方數據源進行交互，系統可以提供間接的方式，例如對外的Web上傳界面，Ftp等，實現數據的采集，采集的數據通過異步方式轉移到核心系統內。2.2.4 節點部署說明如下圖所示，該數據交換平臺系統在宏觀上由部署在不同地理位置的多個節點組成，這些節點位于不同的層級，一個層級對應有一個到多個節點。所謂節點也就

16、是在一定的地理位置實際部署的軟硬件系統。層級分為省級和地市級，所有在地域行政級別相同的節點屬于同一個層級，例如南京市與常州市的市級部署節點它都屬于市一級的三方數據交換平臺系統。節點部署只是一個宏觀的概念，在實際部署中，對于要部署幾層、多少節點，這個根據省局的安排和當地實際業務情況來進行。比如說一個區（縣）可以選擇部署和不部署這樣的數據交換平臺系基于節點的網絡部署圖統。在不部署平臺系統的情況下，它可以直接訪問上級機構部署的節點，實現數據的交換和數據利用。當然這需要有一些前提條件：首先網絡要互聯；另外還需在上級機構的系統里進行用戶設置和訪問權限的設置。2.2.2 軟件系統軟件系統的主要包括操作系統

17、平臺、數據庫管理系統、Web及應用服務器軟件，以及需要接下來設計和開發完成數據導入、處理、應用的核心軟件系統。這些軟件系統根據需求，依據硬件和網絡設置進行分布式部署。操作系統可以為Windows的服務器版本或者Linux的服務器版本，但是本著效率、穩定性等方面的考慮，推薦以Linux相關操作系統版本為主。數據庫軟件以Oracle系列數據庫管理系統來進行構建。Web服務器推薦使用Nginx高性能服務器，另外包括Tomcat等Java應用服務器以及所需要的Ftp服務器。以上的軟件只需部署安裝，按照系統實際運行所需進行相應的配置即可。真正完成數據交換的核心軟件需要接下來開發完成。從宏觀角度來看，它主

18、要由后臺數據自動化處理組件和Web操作控制系統及數據展現應用系統組成。 后臺數據自動化處理組件將會被設計成后臺自動運行的模式，通過提前定義好的標準接口以及標準業務處理規則，完成數據交換、處理以及生成可應用數據接口。在編程實現上，將會充分利用Java企業編程所提供的基礎技術框架結合相關的數據庫開發技術以及充分考慮各種因素，實現最大程度上的數據自動化交換。Web操作控制系統和數據展現系統包含兩部分內容，一部分是對數據交換過程進行操作和控制，它主要完成數據交換的過程管理。另一部分是數據展現應用系統，主要是把獲取和處理好的數據，以各種形式展現出來，提供不同方式的展現形式，支持固定和可定制的信息查詢。另

19、外還提供可編程或非編程方式的數據訪問接口。2.3 核心軟件系統結構核心軟件系統結構圖如上圖所示，以模塊化分層的方式表述了數據交換系統的軟件架構，從大的方面來講，主要包含第三方數據源、數據接口層、傳輸控制層、數據處理層、交換數據庫、數據應用接口和數據展現界面等分層模塊。從2.2所述可以知道，軟件系統由位于不同層級的節點組成。但是從軟件架構上來講，部署在不同層級的軟件系統，除了在上下級系統之間，具有不同的數據流的處理（數據的上傳和下發），除此之外，各個節點的數據交換軟件系統在軟件架構上是一致的。2.3.2 第三方數據源第三方數據源是整個系統所要交換數據的原始采集地，由于各個數據源的情況差別很大，存

20、在很大的不確定性，所以就要求系統要支持多種類別的數據源。在綜合分析以后，確定系統支持以下一些方式的數據源：數據庫直連、FTP方式，手工文本。數據庫直連是信任度最高的一種數據源提供方式。假定第三方機構以某種方式，對其數據庫訪問，提供了一定權限的訪問接口。在這樣一種方式下，系統以事先約定好的訪問規則，去對數據源進行自動訪問，實現數據的采集。FTP方式可能包括兩種類型，一種是在數據接口層提供FTP服務器，以供第三方數據源的相關操作人員或自動運行的程序將所需交換的數據按事先約定好的文本格式，以一定的頻率進行進行文件上傳。另外一種方式是第三方數據源在其網絡接口層提供可以訪問的FTP服務器，本系統根據事先

21、的約定，來完成FTP服務器的定時訪問，獲取到固定格式的文本數據。手工文本方式是指通過其它渠道，以人工方式獲取到的固定格式的第三方數據，它文本方式存儲。在這一層面，需要確定通信和數據采集的一些基本協議。例如，所要采集數據的格式、頻率等。2.3.2 數據接口層數據接口層和第三方數據源示意圖本層主要負責對外接口，提供數據庫訪問程序、FTP數據訪問程序，FTP服務器、WEB操作界面等具體功能來實現和第三方數據源的連接，實現數據的采集。數據庫訪問程序直接連接第三方數據源提供的數據庫訪問接口，按照接口協議，實現數據的直接讀取。FTP服務器提供給第三方機構，使其可以按照訪問協議，上傳本系統所需數據。FTP數

22、據訪問程序連接第三方數據源提供的FTP服務器或者本系統FTP服務器，按照訪問協議，獲取數據并將其解析成可以利用的原始數據。WEB操作界面提供數據導入功能，可以實現格式化數據的導入。除了這些對外的功能性接口以外，本層還負責數據安全傳輸、數據有效性檢測等。2.3.3 傳輸控制層傳輸控制層示意圖傳輸控制層是實現自動化數據采集的關鍵，它根據事先定義好的協議，去自動處理用戶定制的數據采集任務，同時處理數據采集中產生的異常情況，并進行反饋和預警。自動數據采集采用監聽任務腳本的方式去進行處理。首先，用戶通過WEB界面去進行數據采集任務的定制，定制完成以后，會在后臺形成一定格式的任務腳本的描述。其次，傳輸控制

23、層得監聽模塊如果獲取到了新增或修改過的任務描述腳本，則對腳本進行解析，按照腳本描述的規則，去驅動相應的程序模塊進行通信，完成數據的自動化采集。另外，傳輸控制層還會反饋一些預警信息，比如定制的數據采集任務沒有完成或者采集過程中發生了異常，傳輸控制層都會對此過程進行記錄，通過WEB界面把預警信息反饋給用戶。2.3.4 數據處理層數據處理層示意圖數據處理層實現了原始采集數據的存儲以及數據的預處理等環節。原始數據以數據的原始結構進行保存，并記錄操作時間，操作人員等信息。數據的處理包括宏觀數據和微觀數據的處理，宏觀數據直接處理存儲，微觀數據則要和納稅戶信息進行有效的關聯，使其和地稅戶管建立對照表，進行自

24、動匹配以及手工匹配。自動匹配建立在關聯字段信息一致性上，根據一定規則進行匹配，通過程序遍歷，來自動生成匹配數據自動裝載到對照表中，包含的字段有稅務管理碼、納稅人名稱、第三方唯一標識碼、企業名稱、主關聯字段、次關聯字段等。如果部分關聯信息一致或沒有一致的關聯信息，則需要提供界面去進行手工匹配，手工操作后，該部分數據也自動進入對照表。數據處理層除了需要制定完備的數據匹配規則以外，還需進行多重邏輯校驗，實現一定的容錯性，以最大可能來反映數據的準確性。2.3.5 交換數據庫交換數據庫是交換系統所有數據的存儲地，包括系統初始化數據、系統管理數據、原始采集數據、預處理后的正式交換數據等。根據需求，數據庫進

25、行良好的設計。2.3.6 數據展現界面本層主要實現數據的展現，包括各種查詢分析功能。主要有固定查詢、自主定制組合查詢、信息交換統計查詢、單戶明細信息查詢、適用稅種查詢分析、交換數據質量跟蹤監控情況查詢、可利用數據信息查詢等內容。2.3.7 數據應用接口本層提供編程與非編程數據接口，使得交換系統的最終數據，可以為其它系統和部門所用。根據實際的需求情況，可考慮提供各種訪問途徑，例如：數據庫直接訪問方式、FTP文本數據共享、可編程遠程接口、人工導出文本等。2.3.8 上下級系統數據共享本系統除了第三方數據交換功能以外，在級別上有省、市、縣（區）三個級別，所以數據除了從本層第三方數據源進入本層交換系統

26、以外，還可能存在數據的跨級別訪問。比如，上級部門的交換數據可提供給下級部門進行展現和應用，而下級部門的數據交換情況，也可以提供給上級部門查看，比如提供數據交換總覽圖這樣的功能，使得上級部門可以直接獲知數據交換系統各個地方的部署實施情況等。上下級數據的共享可以考慮兩種方式，一種是直接操作上級或下級的交換平臺系統，另外一種是提供數據的上傳或下發，根據用戶的實際需要，會同時提供兩種方式。2.3.9 數據交換標準因為本系統可能會涉及到眾多的第三方數據源，可能包含海量數據的交換處理與存儲，而且數據的交換和處理環節也很多，所以為了更好的對數據進行交換和處理，使得數據最終能得到有效的利用，我們就需要制定各個

27、環節的標準、規范和協議。而標準、規范、協議也是自動化數據處理的一個前提，否則很多環節必須通過人工干預才能進行。首先關于數據源的標準化，也就是本系統都支持哪些類型的數據源，某種特定的數據源都必須要提供哪些參數。比如，如果支持數據庫直連方式，那么就需要確定IP地址、端口、數據庫、表（視圖，存儲過程等）、字段等參數，在用戶進行數據采集任務定制的時候，如果選定了這種方式，那么上述所列的參數就必須提供。其次是數據格式的標準化。只有采集到標準格式的數據，才能被后續環節所自動化處理。在進行數據采集之前，必須要確定數據以什么樣的載體存在，在載體中以什么樣一種格式存在。比如以數據庫直連方式，那么數據應該就是以數

28、據庫表的方式存在。如果是以文本方式，那么就必須確定是什么樣的文本格式：自定義文本格式、csv、excel等。這個還可以繼續延伸下去，比如自定義格式是怎樣的自定義規則，數據字段間以什么樣方式分隔，數據字段的名字采用什么樣的存儲方式等等。最后，是數據源和數據存儲的標準化。因為采集的原始數據可能是多樣性的，而這樣的原始數據是不能為后續的系統例如風險評估系統來應用的，所以在數據的預處理階段必須遵循數據源和數據存儲的標準化，使得處理過的正式數據可以被其它第三方系統所識別，從而成為真正可以利用的數據。系統將根據稅務系統制定的數據源或數據存儲標準，去建立數據源，包括表的命名、字段的命名、字段的類型、字段的含

29、義。因為當前階段標準化工作還在進行中，所以系統的設計上要考慮多種方式的標準化接入。現階段可以預見到的有：標準以文檔的方式提供；標準以可編程接口提供。在數據源建立或數據存儲建立的時候，根據一定的關鍵字去查詢該標準，如果有匹配的標準定義，則遵循標準執行。如果沒有標準，則可以自定義構建。另外，還需要制定詳盡的數據比對規則，只有這樣，才能最大程度的進行數據的自動化匹配，進行有效數據的篩選與存儲。當然，還有很多的處理環節需要標準化，這將會在后續的詳細設計中一一實現。2.4 核心軟件系統設計原則2.4.1 自動化數據交換在數據交換平臺的軟件體系內，處于最核心的部件是數據交換控制組件，該組件自動運行在后臺，

30、依據既定的標準交換協議對數據交換的各個環節進行監聽，一旦監聽到有需要處理的任務，則在后臺自動化的完成數據的處理過程，這一過程不需要人工干預。如果某一過程的處理中，存在問題，則會自動預警。例如，原本定義好每天需要有新的交換文本上傳到FTP進行交換，但是自動化處理過程在自動處理過程中，沒有發現當天需要交換的新文本，則會向系統發一條預警通知，該通知會以某種方式，在WEB操作界面展現出來。2.4.2 可定制數據交換軟件系統將實現數據交換的可定制化。在Web操作控制界面上，具有一定權限的操作人員，可以根據數據交換的需要，在既定的標準交換協議框架之內，實現靈活的的可定制數據交換操作。可以定制數據源、數據采

31、集方式、采集頻率等等。當操作人員按照規則進行了數據交換的可定制操作以后，系統會生成一定的流程描述腳本提供給數據交換控制組件來自動運行。2.4.3 多重方式數據的展現與利用數據交換的最終目的是為了對數據進行管理和應用。那么，經過數據的采集與預處理，得到了可以利用的數據，我們最終需要以某種方式將數據加以展現和利用。本系統中，我們將會以兩種方式來進行數據的展現與利用。對于本系統的最終用戶，系統將會提供基于Web的操作界面，來進行數據的查詢與展現。根據業務需求，將會提供固定條件的數據查詢與展現，以及在一定的業務范疇之內的可定制的數據查詢與展現。當然除了提供Web操作界面提供給最終用戶來進行數據的查詢與

32、展現，還需提供基于不同方式的數據查詢與展現接口以供第三方系統或用戶來對數據進行查詢和應用。那么根據需求，我們可以提供可編程數據訪問接口、數據庫直連、FTP自動交換以及文本導出等不同方式的接口。這個要在保證數據存儲、傳輸的安全條件下，根據具體的需求來確定最終采用哪些方式。2.4.4 數據全生命周期管理本系統的核心著眼點是數據的交換處理和利用，所以對于數據的管理是最核心的一環。基于這一問題，需要設計完備的數據生命周期管理，從數據抽取到系統的第一步起，到數據最終的展現和應用。每個環節，都會提供相應的管理功能和操作界面，供具有權限的操作人員去對數據進行控制和處理。另外，對于數據每個環節的操作和管理，系

33、統都會提供詳盡日志，以供后期分析查詢使用，提供數據交換成果的統計與分析功能。2.4.5 數據字段業務標準本系統自動化成分很高，自動建表，索引，存儲過程等工作都是由系統腳本自動生成。例如在創建數據交換項的時候，數據進入系統采用的數據字段都是要滿足數據標準平臺的標準的，新字段要通過數據標準平臺審核。2.5 數據存儲設計在本系統中，數據存儲的設計包括兩方面的內容，首先是數據庫的部署設計，其次是數據庫表的設計。因為本系統跨地域、跨部門、跨業務，跨上下級關系，所以要實現數據的采集處理和共享，決定了本系統是一個分布式系統。數據庫的部署也必須分地區，分層次，各個地方部署各自的數據庫進行交換數據的存儲。省級的

34、交換數據存儲在省級的數據庫服務器中，市級的交換數據存儲在市級的數據庫服務器中，縣（區）級的交換數據存儲在縣（區）級的數據庫服務中。另外，因為要經過數據的ETL，才能得到可以利用的數據，所以在數據庫的設計上，要考慮到包括原始數據數據表和經過數據轉換和清洗后的正式數據表。關于數據表的設計，要包括系統初始化所需的支撐表、權限控制表以及處于核心的業務數據表等不同類型的數據表。另外，因為系統中存在各地各個級別的數據，所以要設計合理的數據關聯關系，設定一定的訪問控制標志，以保證數據的安全共享與訪問。因為本系統涉及到海量數據的處理，所以要充分發揮分布式存儲和運算技術，利用Oracle數據庫管理技術為中心的各

35、項技術手段，來實現數據的安全存儲，高效處理。2.6 數據流管理設計從宏觀方面講，數據的流向大體有兩個方向。一個是橫向的數據流動，也就是數據從第三方數據源獲取，經過處理后進入本系統數據庫中進行存儲和利用。這是本系統所需處理的核心問題，也就是數據從第三方數據源怎樣進入本系統，并成為有效可利用的數據，并且可以提供給其它系統進行擴展應用。這在前邊基本上已經過闡述。另一個方向是數據的縱向流動，也就是處于行政關系的上下級單位間數據存儲之間的數據流動。主要是上級部門的交換數據，可以共享給下級部門。下級部門的數據交換部署實施情況、數據利用成果等可以共享給上級部門。這里有兩種方案可以選擇：一種是上級（下級）部門

36、的交換數據存儲在上級（下級）部門的數據庫中，給下級（上級）部門開發訪問權限，根據訪問規則，下級（上級）部門可以訪問具有權限的數據。另外一種是上級（下級）部門交換數據下發（上傳）到下級（上級）部門。第一種方式的好處是數據沒有冗余，集中存儲。但是由于要開放下級（上級）訪問接口，這就涉及到這些接口怎么去設計、數據怎樣控制、Web系統通過怎么樣方式的去訪問、怎么樣去部署都提出了一些技術挑戰。另外由于增加了下級（上級）訪問，那么一方面數據庫訪問壓力會增大，另外一方面遠程數據訪問的效率如何，也不得而知。第二種方式的好處是數據本地存儲，這對數據的訪問效率以及減輕上級（下級）部門數據庫的壓力是有很大好處的。但

37、是，這一方式就帶來了海量數據的遠程傳輸控制問題，怎樣保證數據能夠高效安全的傳輸到下級（上級）部門，這是需要首要解決的技術問題。在實際系統的設計和部署中，根據上下級所要交互的數據的類型、規模等因素，同時提供這兩種方式的數據共享和交換方式，用戶可針對不同情況，酌情選擇使用。3. 技術架構設計3.1 概述系統架構示意圖系統以Java和數據庫技術為依托，采用JEE相關技術，以MVC模式為核心，采用分層思想，構建健壯、靈活的Web應用程序。在數據庫訪問層，使用高效的Swim Sql映射框架，實現數據的獲取和持久化。在領域邏輯層，使用Spring框架，通過IOC和AOP,實現業務模塊的可配置和靈活增加、刪

38、減，另外也可以在面的基礎上，對業務實現代碼進行功能增強。在表現層，綜合使用各種Web2.0技術，以Jquery框架為核心，構建具有良好用戶體驗的GUI。3.2 基礎組件3.2.1 Spring Framework【框架描述】Spring為編寫企業應用程序提供了輕量的解決方案，同時仍然支持使用聲明式事務、 用RMI或web service遠程調用、以及使用多種方式來將數據持久化到數據庫。Spring框架包含許多特性，并被很好地組織在下圖所示的六個模塊中。Spring框架架構圖【框架引用目的】1. Spring 的 Core 封裝包Spring 的 Core 封裝包是框架的最基礎部分，提供IoC和

39、依賴注入特性。這里的基礎概念是BeanFactory，它提供對Factory模式的經典實現來消除對程序性單例模式的需要，并真正地允許我們從程序邏輯中分離出依賴關系和配置。2. Spring的 AOP 封裝包Spring的 AOP 封裝包提供了符合 AOP Alliance規范的面向方面的編程（aspect-oriented programming）實現，讓你可以定義，例如方法攔截器（method-interceptors）和切點（pointcuts），從邏輯上講，從而減弱代碼的功能耦合，清晰的被分離開。而且，利用source-level的元數據功能，還可以將各種行為信息合并到你的代碼中。我們主

40、要用于對Java數據庫操作的事務配置、任務異常監控。3. Spring中的 MVC 封裝包Spring中的 MVC 封裝包提供了Web應用的Model-View-Controller（MVC）實現。Spring的MVC框架并不是僅僅提供一種傳統的實現，它提供了一種清晰的分離模型，在領域模型代碼和web form之間。3.2.2 Swim Framework【框架描述】Swim 框架是江蘇同和軟件技術有限公司為了JAVA的數據庫快速編程而開發的一個O/R和sql映射編程框架，它對JDBC進行了非常輕量級的操作封裝，使得JAVA程序員可以方便地使用SQL來操縱數據庫，可以應用在任何可以使用JDBC

41、的場合，既可以在JAVA的客戶端使用，也可以在Servlet/JSP的Web應用中使用。SWIM框架技術架構圖基于Spring和Swim的應用架構圖【框架引用目的】系統與數據庫的交互多而雜，有第三方數據交換平臺自身的數據庫，有第三方數據源的數據庫。Swim框架對于JDBC操作是做過許多優化的，兼容主流的數據庫類型，具有非常高的數據操作效率。對于動態數據源的處理也是Swim框架的強項，用于應對連接不同的第三方數據源。Swim提供的O/R映射能滿足系統領域邏輯模式的設計。3.2.3 Piston遠程數據交換中間件【框架描述】Piston 遠程數據交換中間件 ，為江蘇同和軟件技術有限公司研發的此類中

42、間件的Java版本，在不同的應用系統之間，經常會有數據交換的現象出現，為了讓異構信息系統集成技術平臺實現數據的共享和交換，并且實現高效的通信、安全的數據傳輸和編程的透明性，Piston遠程數據交換中間件是必不可少的高性能中間件。Piston工作原理示意圖該中間件包含了數據交換的服務器端組件和客戶端組件，它在底層實現了數據加密、壓縮、傳輸等系統級的功能，對外提供了一系列的數據遠程交換接口，開發人員只需要根據數據交換的需求，調用相應的編程接口，并把組件和開發的程序正確的部署在需要交換數據的系統中，就可以方便的實現不同地理位置的信息系統之間的數據交互和共享。【框架引用原因】1）Piston采用自定義

43、通信協議，在二進制流上做了高效的數據壓縮。2）Piston采用基于HTTP協議之上的應用協議，為遠程數據的交換提供了方便的通道。3）Piston采用MD5、RSA、Blowfish等多種加密手段，確保數據交換的安全。4）Piston采用類似于數字證書的客戶端驗證機制，保證數據交換的客戶端身份不被偽造。5） Piston支持多客戶端，服務器端使用java編程語言實現，客戶端可以是任何語言實現的組件，只要遵循協議就可。6）Piston提供了web控制臺，可以對服務器端中間件的一些參數進行管理，web控制臺的登錄采用了用戶名、密碼、驗證碼和數字口令碼結合的方式，采用ssl進行通信，確保web控制臺的

44、安全。3.3 領域模型和邏輯設計3.3.1 概述此部分文檔用于說明該平臺相關領域邏輯在技術上的設計，為了方便描述后續的實現機理，首先介紹領域邏輯層核心的兩個組件：任務調度引擎；規則處理引擎。然后講述核心功能（數據導入、數據加工、數據應用）相關主要領域邏輯設計、權限設計、數據上傳和下發設計等。數據交換、數據加工都涉及到了一個任務的概念。為了更好地控制、管理這些任務，我們設計了一套任務調度引擎，負責任務的定時調度、修改、刪除、宕機后任務狀態恢復等。數據加工部分引入了一個規則的概念，我們對規則的第一印象就是量多、相互獨立。應對不同業務需求肯定就需要很多種規則去控制數據匹配的過程，所以系統預定的頂級規

45、則肯定數量不少；每種規則都有自己特有的處理方式，否則也不需要使用多種規則了，所以系統對每一種規則都必須有對應的獨立的處理過程。面對這種復雜的處理要求，我們設計了一套規則處理引擎，負責對用戶定制的規則作出解析，映射出相應的處理程序，再配合任務調度引擎，就能靈活的在平臺中執行復雜的匹配任務。3.3.2 任務調度引擎 概述任務調度引擎工作原理圖本系統為實現自動化的數據采集、匹配，則必然涉及到這個任務可能每天或每周星期二晚上11：30，或許僅僅每個月的最后一天執行。一個自動執行而無須干預的任務在執行過程中如果發生一個嚴重錯誤，應用能夠知到其執行失敗并嘗試重新執行。為了解決這些難題，本系統

46、特引入了任務調度引擎工具的設計，底層開發語言為JAVA，與整個應用無縫連接。整體的工作原理如上圖所示，為了便于理解，圖中主要展現了幾個重要的模塊。整個引擎引入以下幾個概念：1.任務適配器 2.任務管理器 3.任務驅動核心 4.任務線程池。下面我們就分別討論他們的作用。 任務適配器任務適配器是整個任務調度引擎的耳朵，是任務調度引擎的入口。在設計上采用了策略模式。一旦有任務模型請求連接，立即抽取、校驗任務的執行配置信息，獲取到任務實例，需要執行的任務腳本方法名。通過一系列預處理，通知任務管理器做下一步的處理。 任務管理器任務管理器是整個任務調度引擎的大腦，由他來初始化未

47、完成的任務、裝載任務腳本、監控任務線程池、發出異常警告。初始化未完成的任務：在服務器宕機或者服務器重啟的情況下，JAVA進程關閉，服務器內存中所有的任務線程肯定都會丟失。當下一次平臺啟動后為了繼續之前的任務，任務管理器就提供了一個初始化的功能，從數據庫讀取出未完成的任務信息，自動化地啟動所有任務。裝載任務腳本： 由任務適配器傳遞過來的任務模型提供了相應的需要執行的任務腳本，這些腳本定義了具體的任務內容，任務管理器就負責把腳本裝備進任務驅動核心，由任務驅動核心去驅動一個新的任務線程。監控任務線程池：任務線程一旦開啟就必須有一個良好的管理機制，以便于平臺更好的控制任務。這個控制的過程對于用戶是不可

48、見的，由系統去處理。但是會暴露響應的控制接口給用戶，主要功能設定在交換項目的監控功能中，后文會具體介紹。發出異常警告：當任務的執行遇到問題，比如第三方數據源的意外關閉，網閘的重啟等意外情況導致的不能執行數據采集等情況，任務管理器馬上會給平臺一個警告信息，通知平臺做出相應的處理，比如生成異常日志文件，Web操作界面的通知，Email的通知等等機制。 任務驅動核心任務驅動核心接收到任務管理器的指令后，會根據要求生成一條線程或使一條空閑的線程，去執行任務腳本。它擁有多個任務開啟端口，以滿足各種執行方式的任務執行，并且是可擴展的，比如這個任務是周期執行還是延遲執行，是任務管理器識別用戶任

49、務定制信息后，向任務驅動核心命令需要從哪個端口開啟任務線程。 任務線程池任務線程池是整個任務調度引擎的任務清單，上面記載了任務的來源、執行信息等等，并且為每一個任務提供了一個開展作業的場地。每一個任務都將會開啟一個線程去執行，所有的線程組就是我們這里所指的任務線程池，任務線程池在概念上分為內存線程池和外存線程池。內存線程池指的是在服務器內存中的一組隊列數據結構，包含了任務線程的先關信息，便于平臺程序監控；外存線程池指的是持久化到數據庫的任務執行信息，只有形態上與內存線程池有差別，在邏輯上他們是保持一致的。外存線程池可以用來保證在斷電或JAVA進程殺死的情況下保存任務內存信息，以便

50、于系統重啟時任務執行狀態的恢復。3.3.3 規則處理引擎 概述數據規則處理引擎是整個數據匹配加工的核心架構。主要由三個部分組成：規則解析器、規則分發器、規則處理器。規則解析器：負責把操作員在界面配置的信息，轉化成程序可識別的數據描述語言格式；負責把規則描述數據格式（xml或json格式）轉化成操作員可視別的規則參數配置界面。規則分發器：檢查交換項目規則列表的處理器類型，識別出該規則組應該由哪個規則處理器執行，動態加載對應規則處理器，調用并執行。規則處理器：是負責數據匹配加工的實際數據操作程序。解析規則描述數據，針對規則描述的不同，程序自動識別匹配加工條件，完成數據匹配加工處理。3

51、.3.3.1 處理流程圖規則分發器規則處理流程圖 設計原則從系統平臺的穩定、效率、安全、可靠、可維護性的角度出發，設計了一套規則設置和規則處理在功能上完全獨立、在業務邏輯上相聯系的機制 “數據規則處理引擎”。這套機制的主要特點主要體現在：1. 系統平臺對操作員開放的只有規則設置功能和任務時間的設置。所有的加工匹配規則都有程序自動識別規則處理，減少由于人為操作造成的錯誤。2. 操作員對交換項目的設置完成后，只需填寫任務引擎的開啟時間和周期，由“任務調度引擎”（詳細說明見任務調度引擎說明部分）去調用規則處理引擎，無需等待，不耽誤操作員進行平臺其他功能的操作。3. 采用松耦合的設計原則

52、，在以后的項目維護過程中，規則處理器的實現修改不會影響到前臺操作員的操作，同樣有新規則需求擴充時,規則解析器和規則處理器都采用策略匹配設計原則，新增規則時，只需針對新規則添加新的解析器和處理器，不需要對原有代碼結構做任何調整。 規則解析器規則解析器示意圖 為了能讓程序去識別規則，系統必須對每個規則有個預定義的數據描述格式。規則解析器由兩個解析部分組成：正向解析：是程序把操作員填寫輸入的各種參數，根據當前設置的規則類型，按照預定義的數據描述格式，把參數插入到數據格式中，形成規則處理器能識別的規則數據描述。反向解析：是程序根據規則數據描述和預定義的數據描述格式，掃描出規則的各種參數，

53、并把這些參數重新填寫到用戶界面中，讓操作員可以直觀的看懂規則內容。操作員在頁面上設置的規則有各種各樣的參數包括表名、字段、字段值等，這些參數只有單獨的含義，程序是無法通過這些參數自動識別并轉化成數據加工的數據庫條件的，所以我們需要把這些參數先轉換成程序可識別的一種描述語言。針對規則定義一個規則描述格式，參數值預留。在程序獲取用戶輸入參數后，把參數自動填寫進預留位置，形成程序可識別的規則描述。現在比較流行有的有XML和JSON兩種數據描述格式。 規則分發器規則分發器示意圖此功能主要提供根據規則或規則組的處理器類型，分別動態去調用相符合的規則處理器去處理這條規則或規則組。每個交換項目

54、的規則或規則組數量和類型都不會相同，為了靈活適應這種變化，規則分發器提供了一個統一的入口。可以接受任意數量和任意類型的規則或規則組。在規則分發器內部去遍歷傳入的規則組列表，根據規則組的處理類型，動態創建規則處理器的實例，來處理這條規則組。 規則處理器此功能主要負責去識別規則的描述語言格式動態生成sql并完成數據處理部分的功能。規則處理器都是由規則分發器負責實例化，不同類型的規則或規則組都有自己專屬的規則處理器。所有的規則處理器都繼承自同一個父類，每個規則處理器都有自己特定的實現功能。例如新建最終數據表結構規則處理器，根據新建最終數據表規則描述去動態建立最終數據表；數據匹配處理器，

55、根據匹配規則組動態生成sql select、update、insert語句，然后再根據這些sql語句去查詢數據進行匹配。3.3.4 系統核心功能設計概述系統最核心的功能主要分為三個部分：數據導入，數據加工，數據應用。具體流程如下圖所示：系統核心功能圖系統通過這三個部分，可以達到數據進的來，能加工，出的去的過程。下面針對每個環節作出更加詳細的描述。3.3.5 數據導入設計 概述【導入方式分類】導入方式分類圖導入方式根據數據來源的不同可以分為三種：數據庫直連；FTP自動導入；界面手工導入。其中數據庫直連和FTP自動導入屬于自動導入，只需人為設置一次，之后的周期性任務都可由系統自動完成

56、。【導入流程】所有類型的導入流程如下圖所示：數據導入流程圖首先操作人員選擇是何種類型的導入方式，定義導入參數，不同的導入方式需要以不同的參數設置，后續內容會詳細描述。所有的參數都定制完成后系統會生成一條數據導入任務。任務調度引擎的任務適配器會監測到此條任務，此時任務管理器發出指令利用任務驅動核心驅動此條任務，并且推入任務線程池。系統會對任務進行管理和監控。在任務執行的過程中若出現異常（比如第三方數據源突然連接不上，交換平臺本身服務器環境異常等）操作人員在監控中心會得到相應的反饋信息，給出后續操作的建議。關于任務調度引擎以及其內部組件的概念在3.3.2節中已經給出詳細的解釋。執行的任務：根據導入參數的設置，后臺自動建表，該表稱作原始數據表。執行數據導入，將導入的數據存儲在原始數據表中。對于一個定制的導入，只對應一張原始數據表，如果三方數據源涉及多張表達的情況，則需定制多個導入，或者將多張表在導入環節處理成一張表。導入界