系统对接方案

页眉内容

系统对接设计

1.1.1

对接方式

系统与外部系统的对接方式以

web service

方式进行。

系统接口标准：

本系统采用

SOA

体系架构，通过服务总线技术实现数据交换以及实现各业务子系 统间、外部业务

系统之间的信息共享和集成，因此

SOA

体系标准就是我们采用的接口 核心标准。主要包括：

服务目录标准：服务目录

API

接口格式参考国家以及关于服务目录的元数拯指导规 范，对于

W3CUDDIv2 API

结构规范，采取

UDDIv2

的

API

的模型，左义

UDDI

的査询和 发布服务接口，泄制基

于

Java

和

SOAP

的访问接口。除了基于

SOAP1.2

的

Web Service

接口方式，对于基于消息的接口采用

JMS

或者

MQ

的方式。

交换标准：基于服务的交换，采用

HTTP/HTTPS

作为传输协议，而其消息体存放基 于

SOAP1.2

协

议的

SOAP

消息格式。

SOAP

的消息体包括服务数据以及服务操作，服务 数据和服务操作采用

WSDL

进

行描述。

Web

服务标准：用

WSDL

描述业务服务，将

WSDL

发布到

UDDI

用以设计/创建服务,

SOAP/HTTP

服务遵循

WS-I Basic Profile 1.0,

利用

J2EE Session EJBs

实现新的业务服务， 根据需求提

供

SOAP/HTTP orJMS and RMI/IIOP

接口。

业务流程标准：使用没有扩展的标准的

BPEL4WS,

对于业务流程以

SOAP

服务形式 进行访问，业

务流程之间的调用通过

SOAPo

数据交换安全：与外部系统对接需考虑外部访问的安全性，通过

IP

白名单、

SSL

认证等方式保证集

成互访的合法性与安全性。

数据交换标准：制左适合双方系统统一的数据交换数拯标准，支持对增量的数据自

动进行数据同步，避免人工重复录入的工作。

页脚虫-

10

页眉内容

1.1.2

接口规范性设计

系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必 须

遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口 规范

标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安 全、接

口的访问效率、性能以及可扩展性多个方面设计接口规格。

1. 1.2. 1

接口定义约定

客户端与系统平台以及系统平台间的接口消息协议釆用基于

HTTP

协议的

REST

风格接口实现，协议栈如图

4-2

所示。

业务消息

会话数抵

HTTP/

HTTPS

TCP/IP

底层承我

图表

Error! No text of specified style in document.-

接口消息协议栈

示意图

系统在

http

协议中传输的应用数据釆用具有自解释、自包含特征的

JSON

数据

格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包 的编码

和解码。

在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支 持

服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持 多个

版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要，独立 演进，降

低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。

页脚虫-

10

页眉内容

1. 1.2.2

业务消息约定

请求消息

URI

中的参数采用

UTF-8

编码并经过

URLEncode

编码。

请求接口

URL

格式：

{http|https}://{host}: {port}/

{app name}/{business component name}/{action}；

其中：

/协议：

HTTP REST

形式接口

/host：

应用支撑平台交互通信服务的

IP

地址或域名

/ port：

应用支撑平台交互通信服务的端口

/ app name：

应用支撑平台交互通信服务部署的应用名称

/ business component name：

业务组件名称

/ action：

业务操作请求的接口名称，接口名字可配置

应答的消息体采用

JSON

数据格式编码，字符编码采用

UTF-8o

应答消息根节点为“

response",

每个响应包含固定的两个属性节点：

“status”

和

“message”

。它们分别表示操作的返回值和返回消息描述，其他的 同

级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。

当客户端支持数据圧缩传输时，需要在请求的消息头的

“Accept-Encoding”

字段中指定压缩方式

(gzip)

，如消息可以被压缩传输则平台将应答的数据报文进 行

压缩作为应答数据返回，

Content-Length

为压缩后的数据长度。详细参见

HTTP/1.

1 RFC2616

。

1. 1- 2. 3

响应码规则约定

响应结果码在响应消息的

“status”

属性中，相应的解释信息在响应消息的

“message”

属性中。解释消息为终端用户可读的消息，终端应用不需要解析可 直

接呈现给最终用户。响应结果码为

6

位数字串。根据响应类型，包括以下儿类 响应

码。如表

4-1

中的定义。

表

4-1

响应码对应表

页脚

0

、.

10

页眉内容

响应码 描述

成功

系统错误

输入参数不合法错误

应用级返回码，定义应用级的异常返回。

正常的应用级返回码，定义特定场景的应用级返回说明。

0

1XXXXX

2XXXXX

3XXXXX

4XXXXX

1. 1. 2. 4

数据管理

1.1. 2. 4.1

业务数据检查

接口应提供业务数据检查功能，即对接收的数据进行合法性检查，对非法数 据

和错误数据则拒绝接收，以防止外来数据非法入侵，减轻应用支撑平台系统主 机处

理负荷。

对于接口，其业务数据检查的主要内容有以下儿个方面：

・数据格式的合法性：如接收到非预期格式的数据。包括接收的数据长度, 类型，

开始结束标志等。

・数据来源的合法性：如接收到非授权接口的数据。

・业务类型的合法性：如接收到接口指定业务类型外的接入请求。

对于业务数据检查中解析出非法数据应提供以下儿种处理方式：

・事件报警：在出现异常情况时自动报警，以便系统管理员及时进行处理。

・分析原因：在出现异常悄况时，可自动分析其出错原因。如是数据来源 非法

和业务类型非法，本地记录并做后续管理，如是数据格式非法，分析网络传 输原因或

对端数据处理原因，并做相应处理。

・统计分析：定期对所有的非法记录做统计分析，分析非法数据的各种来 源是

否具有恶意，并做相应处理。

1. 1. 2. 4. 2

数据压缩/解压

页脚虫-

10

页眉内容

接口根据具体的需求应提供数据压缩/解压功能，以减轻网络传输压力，提 高传

输效率，从而使整个系统能够快速响应并发请求，高效率运行。

在使用数据压缩/解压功能时，应具体分析每一类业务的传输过程、处理过 程、

传输的网络介质、处理的主机系统和该类业务的并发量、峰值及对于所有业 务的比

例关系等，从而确定该类业务是否需要压缩/解圧处理。对于传输文件的 业务，必须

压缩后传输，以减轻网络压力，提高传输速度。

在接口中所使用的压缩工具必须基于通用无损压缩技术，压缩算法的模型和 编

码必须符合标准且高效，压缩算法的工具函数必须是面向流的函数，并且提供 校验

检查功能。

1. 1. 2. 5

完整性管理

根据业务处理和接口服务的特点，应用系统的业务主要为实时请求业务和批 量

传输业务。两类业务的特点分别如下：

1.

实时请求业务：

(1)

(2)

(3)

(4)

(5)

采用基于事务处理机制实现

业务传输以数据包的方式进行

对传输和处理的实时性要求很高

对数据的一致性和完整性有很高的要求

应保证高效地处理大量并发的请求

2.

批量传输业务：

(1)

(2)

(3)

业务传输主要是数据文件的形式

业务接收点可并发处理大量传输，可适应高峰期的传输和处理

要求传输的可靠性高

根据上述特点，完整性管理对于实时交易业务，要保证交易的完整性；对于 批

量传输业务，要保证数据传输的完整性。

贞脚内容

10

页眉内容

1.1.3

接口双方责任

1. 1- 3. 1

消息发送方

遵循本接口规范中规定的验证规则，对接口数据提供相关的验证功能，保证 数

据的完整性、准确性；

消息发起的平台支持超时重发机制，重发次数和重发间隔可配置。

提供接口元数据信息，包括接口数据结构、实体间依赖关系、计算关系、关 联

关系及接口数据传输过程中的各类管理规则等信息；

提供对敬感数据的加密功能；

及时解决接口数据提供过程中数据提供方一侧出现的问题；

1. 1.3.2

消息响应方

遵循本接口规范中规定的验证规则，对接收的数据进行验证，保证数据的完 整

性、准确性。

及时按照消息发送方提供的变更说明进行本系统的相关改造。

及时响应并解决接口数据接收过程中出现的问题。

1. 1. 3. 3

异常处理

对接口流程调用过程中发生的异常情况，如流程异常、数据异常、会话传输 异

常、重发异常等，进行相应的异常处理，包括：

/对产生异常的记录生成异常记录文件。

/针对可以回收处理的异常记录，进行自动或者人工的回收处理。

/记录有关异常事件的日志，包含异常类别、发生时间、异常描述

等信息。

/当接口调用异常时，根据预先配置的规则进行相关异常处理，并 进行

页脚虫-

10

页眉内容

自动告警。

1.1.4

接口的可扩展性规划与设计

各个系统间的通信接口版本信息限定了各个系统平台间交互的数据协议类 型、

特定版本发布的系统接口功能特征、特定功能的访问参数等接口规格。通过 接口协

议的版本划分，为客户端升级、其他被集成系统的升级、以及系统的部署 提供了较高

的自由度和灵活性。

系统可根据接口请求中包含的接口协议版本实现对接口的向下兼容。系统平 台

可根据系统的集群策略，按协议版本分别部署，也可多版本并存部署。山于系 统平台

可同时支持多版本的外部系统及客户端应用访问系统，特别是新版本客户 端发布时，

不要求用户强制升级，也可降低强制升级安装包发布的儿率。从而支 持系统的客户

端与系统平台分离的持续演进。

1.1.5

接口安全性设计

为了保证系统平台的安全运行，各种集成的外部系统都应该保证其接入的安 全

性。

接口的安全是平台系统安全的一个重要组成部分。保证接口的自身安全，通 过

接口实现技术上的安全控制，做到对安全事件的“可知、可控、可预测”，是 实现系

统安全的一个重要基础。

根据接口连接特点与业务特色，制定专门的安全技术实施策略，保证接口的 数

据传输和数据处理的安全性。

系统应在接口的接入点的网络边界实施接口安全控制。

接口的安全控制在逻辑上包括：安全评估、访问控制、入侵检测、口令认证、 安

全审计、防（毒）恶意代码、加密等内容。

1. 1. 5. 1

安全评估

安全管理人员利用网络扫描器定期（每周）/不定期（当发现新的安全漏洞时）

页脚虫-

10

页眉内容

地进行接口的漏洞扫描与风险评估。扫描对象包括接口通信服务器本身以及与之 关

联的交换机、防火墙等，要求通过扫描器的扫描和评佔，发现能被入侵者利用 的网络

漏洞，并给出检测到漏洞的全面信息，包括位置、详细描述和建议改进方 案，以便及

时完善安全策略，降低安全风险。

安全管理人员利用系统扫描器对接口通信服务器操作系统定期（每周）/不定 期

（当发现新的安全漏洞时）地进行安全漏洞扫描和风险评估。在接口通信服务器 操

作系统上，通过依附于服务器上的扫描器代理侦测服务器内部的漏洞，包括缺 少安

全补丁、词典中可猜中的口令、不适当的用户权限、不正确的系统登录权限、 操作系

统内部是否有黑客程序驻留，安全服务配置等。系统扫描器的应用除了实 现操作系

统级的安全扫描和风险评估之外还需要实现文件基线控制。

接口的配置文件包括接口服务间相互协调作业的配置文件、系统平台与接口 对

端系统之间协调作业的配置文件，对接口服务应用的配置文件进行严格控制， 并且

配置文件中不应岀现口令明文，对系统权限配置限制到能满足要求的最小权 限，关

键配置文件加密保存。为了防止对配置文件的非法修改或删除，要求对配 置文件进

行文件级的基线控制。

1. 1.5.2

访问控制

访问控制主要通过防火墙控制接口对端系统与应用支撑平台之间的相互访 问，

避免系统间非正常访问，保证接口交互信息的可用性、完整性和保密性。访 问控制除

了保证接口本身的安全之外，还进一步保证应用支撑平台的安全。

为了有效抵御威胁，应釆用异构的双防火墙结构，提高对防火墙安全访问控 制

机制的破坏难度。双防火墙在选型上釆用异构方式，即采用不同生产厂家不同 品牌

的完全异构防火墙。同时，双防火墙中的至少一个应具有与实时入侵检测系 统可进

行互动的能力。当发生攻击事件或不正当访问时，实时入侵检测系统检测 到相关信

息，及时通知防火墙，防火墙能够自动进行动态配置，在定义的时间段

内自动阻断源地址的正常访问。

系统对接口被集成系统只开放应用定义的特定端口。

页脚虫-

10

页眉内容

采用防火墙的地址翻译功能，隐藏系统内部网络，向代理系统捉供翻译后的 接

口通信服务器地址及端口，禁止接口对端系统对其它地址及端口的访问。

对通过/未通过防火墙的所有访问记录日志。

1. 1. 5. 3

入侵检测

接口安全机制应具有入侵检测

(IDS)

功能，实时监控可疑连接和非法访问等 安全

事件。一旦发现对网络或主机的入侵行为，应报警并采取相应安全措施，包 括自动阻

断通信连接或者执行用户自定义的安全策略。

实施基于网络和主机的入侵检测。检测攻击行为和非法访问行为，自动中断 其

连接，并通知防火墙在指定时间段内阻断源地址的访问，记录日志并按不同级 别报

警，对重要系统文件实施自动恢复策略。

1. 1.5.4

口令认证

对于需经接口安全控制系统对相关集成系统进行业务操作的请求，实行一次 性

口令认证。

为保证接口的自身安全，对接口通信服务器和其它设备的操作和管理要求采 用

强口令的认证机制，即采用动态的口令认证机制。

1. 1.5.5

安全审计

为了保证接口的安全，要求对接口通信服务器的系统日志、接口应用服务器 的

应用日志进行实时收集、整理和统计分析，釆用不同的介质存档。

1. 1- 5. 6

防恶意代码或病毒

由于

Internet

为客户提

WEB

服务,因此,对于

Internet

接口要在网络分界 点

建立一个功能强大的防恶意代码系统，该系统能实时地进行基于网络的恶意代

码过滤。建立集中的防恶意代码系统控制管理中心。

1. 1.5.7

加密

页脚

0

、.

10

页眉内容

为了提髙接口通信信息的保密性，同时保证应用支撑平台的安全性，可以对系统平台与接口 集成系统间的相

关通信实施链路加密、网络加密或应用加密，保证无关人员以及无关应用不 能通过网络链路监听获得关键业

务信息，充分保证业务信息的安全。

10