文/陈军

1 概述

1.1 背景介绍

南京金保工程二期管理信息系统的建设涉及公共基础软件、社会保障卡、社会保险、就业与劳动关系、人事人才等相关的十几个子系统，各子系统之间独立应用和数据库，但相互间又存在必然的联系和数据共享联动，笔者结合自身工作经验总体设计规划并实现了统一对内数据交互服务平台和统一对外数据交互服务平台，解决各系统间数据交互的安全性，提升了交换安全性和效率。

1.2 设计思路

定义数据交互技术方案以及三种类型的数据交互模式的对接细则，适用于南京市人社局各业务系统之间及与外部单位的对接。对接前根据子系统的实际情况和外部需求，选择适合业务的数据交互模式。

2 技术实现

2.1 技术实现架构

南京市金保二期信息协同共享分内部共享交换和外部交换。其中内部共享交换是在南京市金保二期专网内部各级横向间的业务办理过程中信息共享，支持行业内基础信息和业务办理信息的统一和协同，实现关联业务的协同办理等；外部交换是与其他部门（或不同网络）之间的信息双向交换，支持各自系统的业务办理，基于实时信息流的及时交互支持各自业务办理信息的核实等。

2.2 内外平台对接

为了满足内外数据的交互需求，提升内部数据的安全，设计统一对内和对外的数据交互服务平台，内外两个平台之间进行数据交互。数据交互服务平台提供三种类型数据的交互，一是实时通信交互，建立数据交互调度服务，通过实时交易模式实现数据实时交互；二是数据库表交互，通过数据库的数据表进行数据交互和共享，主要应用于非实时的批量数据交互，可通过脚本或数据同步工具实现；三是文件服务交互，建立文件服务器，通过FTP的方式实现文件的共享与交换。

2.3 内部交互对接

统一内部数据交互服务平台用于专网内部系统间数据协同和共享，各应用系统除搭建自身应用服务和数据库服务以外，还应建立对外接口服务，各系统的接口服务是南京金保二期系统建设中必不可少的一部分。系统间数据交互统一通过统一对内数据交互服务平台实现。

内部数据交互调度服务作为内部系统间实时交易的总调度服务，是内部系统间数据实时交互的中枢，其核心为内部各应用系统的接口服务提供注册和管理，制订统一的数据交互接口规范，并根据接口规范进行系统间接口服务管理和调度。外部数据交互服务与内部原理相似，使用方式由外部单位和具体情况确定。

2.4 数据对接模式

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 总结

在南京金保二期内、外数据交互上，设计实现并统一对外数据交互服务平台和统一对内数据交互服务平台，内外两个平台对接实现信息的方便快捷交互，从平台架构上实现了金保二期系统数据交换集中统一、安全高效管理。