系统对接方案.docx

系统对接方案.docx

《系统对接方案.docx》由会员分享，可在线阅读，更多相关《系统对接方案.docx（9页珍藏版）》请在冰豆网上搜索。

系统对接方案

系统对接设计

1.1.1对接方式

系统与外部系统的对接方式以webservice方式进行、

系统接口标准:

本系统采纳SOA体系架构,通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成,因此SOＡ体系标准就是我们采纳的接口核心标准。

主要包括:

服务目录标准:

服务目录APＩ接口格式参考国家以及关于服务目录的元数据指导规范,关于W3CＵDＤＩ　v2APＩ结构规范,采取ＵDDIv2的ＡPI的模型,定义UDDI的查询和公布服务接口,定制基于Ｊaｖa和SＯAＰ的访问接口。

除了基于SOAＰ１。

2的Wｅb　Serviｃe接口方式,关于基于消息的接口采纳JMS或者MＱ的方式。

交换标准:

基于服务的交换,采纳/Ｓ作为传输协议,而其消息体存放基于SOAＰ1。

２协议的SOAＰ消息格式、SOAP的消息体包括服务数据以及服务操作,服务数据和服务操作采纳WＳDＬ进行描述。

Ｗeb服务标准:

用WSＤL描述业务服务,将ＷSDL公布到UDDI用以设计/创建服务,SOAP/服务遵循WS—IBaｓic　Pro,利用J2EＥSeｓsiｏn　EJBｓ实现新的业务服务,依照需求提供SOAP/ｏrJMSandＲＭI/IＩOP接口、

业务流程标准:

使用没有扩展的标准的BＰEL4WS,关于业务流程以ＳOＡP服务形式进行访问,业务流程之间的调用通过SOAP。

数据交换安全:

与外部系统对接需考虑外部访问的安全性,通过ＩP白名单、SＳL认证等方式保证集成互访的合法性与安全性、

数据交换标准:

制定适合双方系统统一的数据交换数据标准,支持对增量的数据自动进行数据同步,幸免人工重复录入的工作、

1.1.2接口规范性设计

系统平台中的接口众多,依赖关系复杂,通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。

接口模型除了遵循工程统一的数据标准和接口规范标准,实现接口规范定义的功能外,需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格、

1.1.2.1接口定义约定

客户端与系统平台以及系统平台间的接口消息协议采纳基于协议的ＲEST风格接口实现,协议栈如图4—２所示、

图表４2接口消息协议栈示意图

系统在协议中传输的应用数据采纳具有自解释、自包含特征的JSON数据格式,通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。

在接口协议中,包含接口的版本信息,通过协议版本约束服务功能规范,支持服务平台间接口协作的升级和扩展。

一个服务提供者可通过版本区别同时支持多个版本的客户端,从而使得组件服务的提供者和使用者依照实际的需要,独立演进,降低系统升级的复杂度,保证系统具备灵活的扩展和持续演进的能力。

1.1.2.2业务消息约定

请求消息UＲI中的参数采纳ＵTF—8编码并经过ＵRＬＥncode编码。

请求接口ＵRL格式:

{|s}:

//｛hosｔ｝:

{port｝/

｛appnａme}／{ｂuｓiｎesｓpｏneｎｔnａmｅ}/｛actioｎ｝;其中:

✓协议:

　ＲEＳT形式接口

✓host:

应用支撑平台交互通信服务的IP地址或域名

✓pｏｒt:

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

✓appnａｍe:

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

✓buｓｉneｓsｐoｎenｔnaｍe:

业务组件名称

✓action:

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

应答的消息体采纳JＳON数据格式编码,字符编码采纳ＵTF－8。

应答消息根节点为“respoｎse",每个响应包含固定的两个属性节点:

“status”和“ｍeｓsage”。

它们分别表示操作的返回值和返回消息描述,其他的同级子节点为业务返回对象属性,依照业务类型的不同,有不同的属性名称、

当客户端支持数据压缩传输时,需要在请求的消息头的“Ａcｃept-Ｅｎｃoding”字段中指定压缩方式（ｇｚip）,如消息能够被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回,Ｃｏntent—Length为压缩后的数据长度。

详细参见/１、1ＲFＣ261６。

1.1.2.3响应码规则约定

响应结果码在响应消息的“ｓtatus”属性中,相应的解释信息在响应消息的“meｓsａge”属性中。

解释消息为终端用户可读的消息,终端应用不需要解析可直接呈现给最终用户。

响应结果码为6位数字串。

依照响应类型,包括以下几类响应码。

如表4—1中的定义。

表４－１响应码对应表

响应码

描述

0

成功

1XXＸXX

系统错误

2ＸXＸXX

输入参数不合法错误

3XＸXXＸ

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

４XＸXXX

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

1.1.2.4数据管理

1.1.2.4.1业务数据检查

接口应提供业务数据检查功能,即对接收的数据进行合法性检查,对非法数据和错误数据则拒绝接收,以防止外来数据非法入侵,减轻应用支撑平台系统主机处理负荷、

关于接口,其业务数据检查的主要内容有以下几个方面:

•ﻩ数据格式的合法性:

如接收到非预期格式的数据、包括接收的数据长度,类型,开始结束标志等。

•ﻩ数据来源的合法性:

如接收到非授权接口的数据、

•ﻩ业务类型的合法性:

如接收到接口指定业务类型外的接入请求。

关于业务数据检查中解析出非法数据应提供以下几种处理方式:

•ﻩ事件报警:

在出现异常情况时自动报警,以便系统管理员及时进行处理、

•分析原因:

在出现异常情况时,可自动分析其出错原因。

如是数据来源非法和业务类型非法,本地记录并做后续管理,如是数据格式非法,分析网络传输原因或对端数据处理原因,并做相应处理、

•统计分析:

定期对所有的非法记录做统计分析,分析非法数据的各种来源是否具有恶意,并做相应处理。

1.1.2.4.2数据压缩／解压

接口依照具体的需求应提供数据压缩/解压功能,以减轻网络传输压力,提高传输效率,从而使整个系统能够快速响应并发请求,高效率运行。

在使用数据压缩/解压功能时,应具体分析每一类业务的传输过程、处理过程、传输的网络介质、处理的主机系统和该类业务的并发量、峰值及关于所有业务的比例关系等,从而确定该类业务是否需要压缩/解压处理。

关于传输文件的业务,必须压缩后传输,以减轻网络压力,提高传输速度、

在接口中所使用的压缩工具必须基于通用无损压缩技术,压缩算法的模型和编码必须符合标准且高效,压缩算法的工具函数必须是面向流的函数,同时提供校验检查功能。

1.1.2.5完整性管理

依照业务处理和接口服务的特点,应用系统的业务主要为实时请求业务和批量传输业务。

两类业务的特点分别如下:

1、实时请求业务:

（1）采纳基于事务处理机制实现

（2）ﻩ业务传输以数据包的方式进行

（３）ﻩ对传输和处理的实时性要求特别高

（4）对数据的一致性和完整性有特别高的要求

（5）ﻩ应保证高效地处理大量并发的请求

2、批量传输业务:

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

（2）ﻩ业务接收点可并发处理大量传输,可习惯高峰期的传输和处理

（3）要求传输的可靠性高

依照上述特点,完整性管理关于实时交易业务,要保证交易的完整性;关于批量传输业务,要保证数据传输的完整性。

1.1.3接口双方责任

1.1.3.1消息发送方

遵循本接口规范中规定的验证规则,对接口数据提供相关的验证功能,保证数据的完整性、准确性;

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

提供接口元数据信息,包括接口数据结构、实体间依赖关系、计算关系、关联关系及接口数据传输过程中的各类管理规则等信息;

提供对敏感数据的加密功能;

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

1.1.3.2消息响应方

遵循本接口规范中规定的验证规则,对接收的数据进行验证,保证数据的完整性、准确性。

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

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

1.1.3.3异常处理

对接口流程调用过程中发生的异常情况,如流程异常、数据异常、会话传输异常、重发异常等,进行相应的异常处理,包括:

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

✓针对能够回收处理的异常记录,进行自动或者人工的回收处理。

✓记录有关异常事件的日志,包含异常类别、发生时间、异常描述等信息。

✓当接口调用异常时,依照预先配置的规则进行相关异常处理,并进行自动告警。

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

各个系统间的通信接口版本信息限定了各个系统平台间交互的数据协议类型、特定版本公布的系统接口功能特征、特定功能的访问参数等接口规格、通过接口协议的版本划分,为客户端升级、其他被集成系统的升级、以及系统的部署提供了较高的自由度和灵活性。

系统可依照接口请求中包含的接口协议版本实现对接口的向下兼容。

系统平台可依照系统的集群策略,按协议版本分别部署,也可多版本并存部署。

由于系统平台可同时支持多版本的外部系统及客户端应用访问系统,特别是新版本客户端公布时,不要求用户强制升级,也可降低强制升级安装包公布的几率。

从而支持系统的客户端与系统平台分离的持续演进。

1.1.5接口安全性设计

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

接口的安全是平台系统安全的一个重要组成部分。

保证接口的自身安全,通过接口实现技术上的安全控制,做到对安全事件的“可知、可控、可预测”,是实现系统安全的一个重要基础。

依照接口连接特点与业务特色,制定专门的安全技术实施策略,保证接口的数据传输和数据处理的安全性。

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

接口的安全控制在逻辑上包括:

安全评估、访问控制、入侵检测、口令认证、安全审计、防（毒）恶意代码、加密等内容、

1.1.5.1安全评估

安全管理人员利用网络扫描器定期（每周）/不定期（当发现新的安全漏洞时）地进行接口的漏洞扫描与风险评估。

扫描对象包括接口通信服务器本身以及与之关联的交换机、防火墙等,要求通过扫描器的扫描和评估,发现能被入侵者利用的网络漏洞,并给出检测到漏洞的全面信息,包括位置、详细描述和建议改进方案,以便及时完善安全策略,降低安全风险。

安全管理人员利用系统扫描器对接口通信服务器操作系统定期（每周）/不定期（当发现新的安全漏洞时）地进行安全漏洞扫描和风险评估、在接口通信服务器操作系统上,通过依附于服务器上的扫描器代理侦测服务器内部的漏洞,包括缺少安全补丁、词典中可猜中的口令、不适当的用户权限、不正确的系统登录权限、操作系统内部是否有黑客程序驻留,安全服务配置等。

系统扫描器的应用除了实现操作系统级的安全扫描和风险评估之外还需要实现文件基线控制、

接口的配置文件包括接口服务间相互协调作业的配置文件、系统平台与接口对端系统之间协调作业的配置文件,对接口服务应用的配置文件进行严格控制,同时配置文件中不应出现口令明文,对系统权限配置限制到能满足要求的最小权限,关键配置文件加密保存。

为了防止对配置文件的非法修改或删除,要求对配置文件进行文件级的基线控制。

1.1.5.2访问控制

访问控制主要通过防火墙控制接口对端系统与应用支撑平台之间的相互访问,幸免系统间非正常访问,保证接口交互信息的可用性、完整性和保密性。

访问控制除了保证接口本身的安全之外,还进一步保证应用支撑平台的安全、

为了有效抵御威胁,应采纳异构的双防火墙结构,提高对防火墙安全访问控制机制的破坏难度。

双防火墙在选型上采纳异构方式,即采纳不同生产厂家不同品牌的完全异构防火墙。

同时,双防火墙中的至少一个应具有与实时入侵检测系统可进行互动的能力。

当发生攻击事件或不正当访问时,实时入侵检测系统检测到相关信息,及时通知防火墙,防火墙能够自动进行动态配置,在定义的时间段内自动阻断源地址的正常访问。

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

采纳防火墙的地址翻译功能,隐藏系统内部网络,向代理系统提供翻译后的接口通信服务器地址及端口,禁止接口对端系统对其它地址及端口的访问。

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

1.1.5.3入侵检测

接口安全机制应具有入侵检测（ＩDＳ）功能,实时监控可疑连接和非法访问等安全事件。

一旦发现对网络或主机的入侵行为,应报警并采取相应安全措施,包括自动阻断通信连接或者执行用户自定义的安全策略。

实施基于网络和主机的入侵检测。

检测攻击行为和非法访问行为,自动中断其连接,并通知防火墙在指定时间段内阻断源地址的访问,记录日志并按不同级别报警,对重要系统文件实施自动恢复策略。

1.1.5.4口令认证

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

为保证接口的自身安全,对接口通信服务器和其它设备的操作和管理要求采纳强口令的认证机制,即采纳动态的口令认证机制。

1.1.5.5安全审计

为了保证接口的安全,要求对接口通信服务器的系统日志、接口应用服务器的应用日志进行实时收集、整理和统计分析,采纳不同的介质存档。

1.1.5.6防恶意代码或病毒

由于Inｔerｎet为客户提WEB服务,因此,关于Intｅrnｅｔ接口要在网络分界点建立一个功能强大的防恶意代码系统,该系统能实时地进行基于网络的恶意代码过滤。

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

1.1.5.7加密

为了提高接口通信信息的保密性,同时保证应用支撑平台的安全性,能够对系统平台与接口集成系统间的相关通信实施链路加密、网络加密或应用加密,保证无关人员以及无关应用不能通过网络链路监听获得关键业务信息,充分保证业务信息的安全。