文/陳軍
南京金保工程二期管理信息系統的建設涉及公共基礎軟件、社會保障卡、社會保險、就業與勞動關系、人事人才等相關的十幾個子系統,各子系統之間獨立應用和數據庫,但相互間又存在必然的聯系和數據共享聯動,筆者結合自身工作經驗總體設計規劃并實現了統一對內數據交互服務平臺和統一對外數據交互服務平臺,解決各系統間數據交互的安全性,提升了交換安全性和效率。
定義數據交互技術方案以及三種類型的數據交互模式的對接細則,適用于南京市人社局各業務系統之間及與外部單位的對接。對接前根據子系統的實際情況和外部需求,選擇適合業務的數據交互模式。
南京市金保二期信息協同共享分內部共享交換和外部交換。其中內部共享交換是在南京市金保二期專網內部各級橫向間的業務辦理過程中信息共享,支持行業內基礎信息和業務辦理信息的統一和協同,實現關聯業務的協同辦理等;外部交換是與其他部門(或不同網絡)之間的信息雙向交換,支持各自系統的業務辦理,基于實時信息流的及時交互支持各自業務辦理信息的核實等。
為了滿足內外數據的交互需求,提升內部數據的安全,設計統一對內和對外的數據交互服務平臺,內外兩個平臺之間進行數據交互。數據交互服務平臺提供三種類型數據的交互,一是實時通信交互,建立數據交互調度服務,通過實時交易模式實現數據實時交互;二是數據庫表交互,通過數據庫的數據表進行數據交互和共享,主要應用于非實時的批量數據交互,可通過腳本或數據同步工具實現;三是文件服務交互,建立文件服務器,通過FTP的方式實現文件的共享與交換。
統一內部數據交互服務平臺用于專網內部系統間數據協同和共享,各應用系統除搭建自身應用服務和數據庫服務以外,還應建立對外接口服務,各系統的接口服務是南京金保二期系統建設中必不可少的一部分。系統間數據交互統一通過統一對內數據交互服務平臺實現。
內部數據交互調度服務作為內部系統間實時交易的總調度服務,是內部系統間數據實時交互的中樞,其核心為內部各應用系統的接口服務提供注冊和管理,制訂統一的數據交互接口規范,并根據接口規范進行系統間接口服務管理和調度。外部數據交互服務與內部原理相似,使用方式由外部單位和具體情況確定。
2.4.1 實時通信模式
通訊采用TCP/IP協議,可選支持Socket、WebService兩種通訊方式(同一類業務僅允許選擇一種通訊方式),通訊時采用短連接,當一筆交易完成后,雙方友好斷開連接,待下一筆交易發起時再建立連接;各子系統建立對應的監聽,提供對應業務接口服務;由數據交互服務平臺建立服務監聽,外部系統提供接口服務。此模式應用于對于數據實時性較高的業務場景。如讀寫基礎信息庫數據。
2.4.2 數據庫表交互模式
在數據庫交互中,設計內部共享交換庫和外部交換庫,內部共享交換庫按照系統類別分別建立數據庫實例或用戶,交換庫和共享庫分庫,共享庫用于內部系統間數據實時共享,交換庫用于內部交換和對外交換;外部交換庫按照部省交換庫、委辦單位交換庫、特殊單位交換庫和互聯網服務交換庫四類,分別應用于不同的業務場景,不同系統與外部不同單位進行數據庫交換時,可采用不用數據庫實例或用戶進行分隔。同時,各交換庫中可按照數據的傳輸方向,分為上行數據表和下行數據表。使用兩個數據庫(或實例或用戶)的數據表進行數據交互,可建立DBLink編寫腳本或通過數據同步工具實現數據的共享和交換。一般應用于數據更新實時性要求不高且數據使用量較高的業務需求,如外網的個人賬戶信息查詢,考試成績查詢等。
2.4.3 實時通信交互
對于想避免被XML解析器解析的元素信息,必須定義以CDATA段進行數據存儲;例如一些轉義字符、文件等。在XML元素中,"<"和"&"是非法的。"<"會產生錯誤,因為解析器會把該字符解釋為新元素的開始。"&"也會產生錯誤,因為解析器會把該字符解釋為字符實體的開始。CDATA部分由""結束,CDATA部分中的所有內容都會被解析器忽略。假設有一節點 2.4.4 業務要素 業務要素是消息體的基本組成元素。它對應于業務操作中的一個元素。每一個業務要素都有其XML Tag、業務含義、數據類型和取值范圍。在消息中,根據不同的XML Tag來確定不同業務要素。業務要素的數據類型決定了其取值類型,它的取值范圍可以是一個集合,任何在此集合外的取值被認為是非法取值。數據字典部分詳細定義了取值范圍。業務要素可能是一個簡單的元素,也可能是一個復雜的業務組件。 2.4.5 數據類型 筆者規定兩種數值類:整形數值和浮點類數值,整形數值最大長度18位,浮點總長度和精度不限,由接口雙方約定;對于規定兩類數值不滿足的情況下,允許接口雙方擴展數值組件。規定三類時間日期:日期、時間以及日期時間格式;日期格式只存儲年月日,時間格式只存儲時分秒,日期時間存儲年月日時分秒;對于需要更高精度的日期時間,允許接口雙方擴展日期時間組件。其它為明確定義的日期時間格式采用文本或者自定義XML Tag表示,格式由各業務系統執行協商約定。消息頭,消息頭格式,消息頭要素,版本:消息體版本號,目前為1.0.0。 2.4.6 報文標識 從技術上標識一筆報文,用于異常處理使用,與具體業務無關,業務可以選擇采用其作為重復處理控制。具體組成規則如下:發送業務系統(XXXXXX)+日期(YYYYMMDD)+8位序列號,例如“I90001201309220000000001”代表編碼為I90001的業務系統于2013年9月22日發起的第1筆交易報文。接收方應原樣返回該字段內容。接口類別:標識交互平臺注冊的接口功能,一個業務系統可以在交互平臺注冊多于一個接口,但是需要分別申請接口類別,需向交互平臺申請代碼;固定6個字符組成:接口網絡域(1)+序列號(5)。 2.4.7 接口代碼 標識具體的業務功能,每個接口內部不重復,由接口雙方協商確定。交易發起方:區分交易發起方所在的網絡域,例如:內網還是外網系統。分頁定義:為提供一致的分頁格式,對分頁組件進行定義;分頁組件以dataSet作為節點名稱,組件內固定部分包含“當前頁碼”、“分頁大小”、“末頁標志”以及業務相關的“數據集”組成,其中“數據集”以rowSet作為節點名稱,內部包含各業務行,每行以row作為節點名稱,row內部包含由業務定義的業務組件。 2.4.8 數字簽名域 為保證傳輸報文的完整性與安全性,發送方發送報文之前,需使用私鑰按照指定的算法對傳輸報文生成簽名,記為“數字簽名A”,傳輸時將“數字簽名A”附加到報文最后一起發送;接收方接收到報文后,使用公鑰按照相同的算法對報文與數字簽名進行驗簽;只要數字簽名校驗不通過,直接退回交易;約定,以交易消息的消息體域為關鍵信息,數字摘要的生成參照“數字簽名”。為了數據傳輸的安全性,可以選擇將關鍵信息加密傳輸;此時數據簽名以加密后的數據作為基礎數據簽名。要求做數字簽名的接口統一采用非對稱加密算法進行簽名和驗簽。 2.4.9 異常處理 為了解決交易超時問題,對接口雙方做如下要求:要求接口提供者提供“交易狀態查詢”、“交易重發”最少二選一支持。要求接口調用者對于經辦類交易發生超時或者未知錯誤后,優先采用“交易狀態查詢”、“交易重發”來解決問題;對于采用交易重發方案時,重發次數由接口雙方協商確定。交互平臺不處理交易重發,重發由交易接口雙方處理。 在南京金保二期內、外數據交互上,設計實現并統一對外數據交互服務平臺和統一對內數據交互服務平臺,內外兩個平臺對接實現信息的方便快捷交互,從平臺架構上實現了金保二期系統數據交換集中統一、安全高效管理。3 總結