系统对接方案.docx

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

1、系统对接方案系统对接设计1.1.1对接方式系统与外部系统的对接方式以web service方式进行。系统接口标准：本系统采用SoA体系架构，通过服务总线技术实现数据 交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括：服务目录标准：服务目录APl接口格式参考国家以及关 于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2 的APl的模型，定义UDDl的查询和发布服务接口，定制基于JaVa和SOAP的访问接口。除了基于SOAPI.2的WebService接口方式，对于基于消息的接口采用JMS或

2、者MQ的方式。交换标准：基于服务的交换，采用HTTP/HTTPS作为传 输和谈，而其消息体存放基于SOAPl.2协议的SOAP消息格式。SOAP的消息体包 括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。Web服务标准：用WSDL描述业务服务，将WSDL发布 到UDDl用以设计/创建服务，SOAP/HTTP 服务遵循 WS-I Basic Profile 1.0,利用 J2EE SeSSiOnEJBS实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP 接口。业务流程标准：利用没有扩大的标准的BPEL4WS,对于 业务流程以SOAP服务形式进

3、行拜候，业务流程之间的调用通过SoAP。数据交换安全：与外部系统对接需考虑外部访问的安全性, 通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。数据交换标准：制定适合双方系统统一的数据交换数据标 准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。1.1.2接口规范性设想系统平台中的接口众多，依赖关系复杂，通过接换的数据 与接口调用必须遵循统一的接口模型进行设计。接口模型除了 遵循工程统一的数据标准和接口研究参考规范标准，实现接口规范定义的功能外，需要从数据管理、 完整性管理、接口安全、接口的访问效率、性能以及可扩展性 多个方面设计接口规格。接口定义约定客户端与系统平台以

4、及系统平台间的接口消息协议采用基 于HTTP协议的REST风格接口实现，协议栈如图4-2所示。业务消息会话数据HTTP/HTTPSTCP/IP底层承载图表错误!文档中没有指定样式的文字。接口消息协议栈 示意图系统在http和谈中传输的使用数据采用具有自解释、自 包罗特征的JSON数据格式，通过配置数据对象的序列化和反 序列化的完成组件来完成通信数据包的编码息争码。在接口和谈中，包罗接口的版本信息，通过和谈版本束缚 服务功能规范，支持服务平台间接口协作的晋级和扩大。一个 服务提供者可通过版本区别同时支持多个版本的客户端，从而 使得组件服务的提供者和利用者根据实际的需要，独立演进， 降低系统晋级的

5、庞大度，保证系统具有灵活的扩大和持续演进 的能力。业务消息约定请求消息URI中的参数采用UTF-8编码并经过 URLEnCOde 编码。请求接口 URL 格式：httphttps:/host:port/app name !/business component name action； 其中：J和谈：HTTPREST形式接口/host：应用支撑平台交互通信服务的IP地址或域名研究参考/port：应用支撑平台交互通信服务的端口appname:使用支撑平台交互通信服务摆设的使用名称/business component name： 业务组件名称 action：业务操作请求的接口名称，接口名字可配置

6、应对的消息体采用JSe)N数据格式编码，字符编码采用 UTF-8o应答消息根节点为“response，每个响应包含固定的两个 属性节点：“status”和“message”。它们分别表示操作的返回值 和返回消息描述，其他的同级子节点为业务返回对象属性，根 据业务类型的不同，有不同的属性名称。当客户端支持数据压缩传输时，需要在请求的消息头的 “Accept-Encoding”字段中指定压缩方式(gzip),如消息可以被 压缩传输则平台将应对的数据报文进行压缩作为应对数据返回, Content-Length为压缩后的数据长度。详细参见HTTP/1.1 RFC2616o响应码规则约定响应结果码在响应

7、消息的“status”属性中，相应的解释信 息在响应消息的“message”属性中。解释消息为终端用户可读 的消息，终端使用不需要解析可直接呈现给最终用户。响应结 果码为6位数字串。根据响应类型，包括以下几类响应码。如 表4-1中的定义。表4-1响应码对应表响应码IXXXXX2XXXXX3XXXXX4XXXXX描绘胜利系统错误输入参数不合法错误应用级返回码，定义应用级的异常返回。正常的使用级返回码，定义特定场景的使用级返回说明。业务数据检查数据管理接口应提供业务数据检查功能，即对接收的数据进行合法 性检查，对非法数研究参考据和错误数据则回绝接收，以防止外来数据非法入侵，减 轻使用支撑平台系统主

8、机处理负荷。对于接口，其业务数据检查的主要内容有以下几个 方面： 数据格式的合法性：如接收到非预期格式的数据。 包括接收的数据长度，类型，开始结束标志等。 数据起原的合法性：如接收到非授权接口的数据。 业务类型的合法性：如接收到接口指定业务类型外的接 入请求。对于业务数据检查中解析出非法数据应提供以下几种处理 方式：非法和业务类型非法，本地记录并做后续管理，如是数据 格式非法，分析网络传输原因或对端数据处理原因，并做相应 处理。 统计分析：定期对所有的非法记录做统计分析，分析非 法数据的各种来源是不是具有恶意，并做相应处理。数据压缩/解压接口根据具体的需求应提供数据压缩/解压功能，以减轻 网络

9、传输压力，提高传输效率，从而使整个系统能够快速响应 并发请求，高效率运行。在利用数据压缩/解压功能时，应具体分析每类业务的传 输过程、处理过程、传输的网络介质、处理的主机系统和该类 业务的并发量、峰值及对于所有业务的比例关系等，从而确定 该类业务是不是需要压缩/解压处理。对于传输文件的业务， 必须压缩后传输，以减轻网络压力，提高传输速度。在接口中所利用的压缩工具必须基于通用无损压缩技术， 压缩算法的模子和编码必须符合标准且高效，压缩算法的工具 函数必须是面向流的函数，并且提供校验检查功能。研究参考完整性管理根据业务处理和接口服务的特点，使用系统的业务主要为 实时请求业务和批量传输业务。两类业务

10、的特点分别以下：1.实时请求业务：(1)(2)(3)(4)(5)采用基于事务处理机制实现业务传输以数据包的方式进行对传输和处理的实时性要求很高对数据的同等性和完整性有很高的要求应保证高效地处理大量并发的请求2.批量传输业务：(1)(2)(3)业务传输主要是数据文件的形式业务接收点可并发处理大量传输，可适应高峰期的传输和 处理要求传输的可靠性高根据上述特点，完整性管理对于实时交易业务，要保证交 易的完整性；对于批量传输业务，要保证数据传输的完整性。1.1.3接口双方责任消息发送方遵循本接口规范中规定的考证规则，对接口数据提供相关 的考证功能，保证数据的完整性、准确性;消息发起的平台支持超时重发机

11、制，重发次数和重发间隔 可配置。提供接口元数据信息，包括接口数据结构、实体间依赖关 系、计算关系、关联关系及接口数据传输过程中的各类管理规 则等信息；提供对敏感数据的加密功能；研究参考及时解决接口数据提供过程中数据提供方一侧出现的问题;消息响应方遵循本接口规范中规定的考证规则，对接收的数据进行考 证，保证数据的完整性、准确性。及时按照消息发送方提供的变更说明进行本系统的相关改 造。及时响应并办理接口数据接收过程中出现的问题。异常处理对接口流程调用过程中发生的异常情况，如流程异常、数 据异常、会话传输异常、重发异常等，进行相应的异常处理， 包括：/对产生反常的记实生成反常记实文件。/针对可以回收

12、处理的反常记实，进行自动大概野生的回 收处理。/记实有关反常事件的日志，包罗反常类别、产生时间、 反常描绘等信息。J当接口调用异常时，根据预先配置的规则进行相关异常 处理，并进行自动告警。LL4接口的可扩展性规划与设计各个系统间的通信接口版本信息限定了各个系统平台间交 互的数据和谈类型、特定版本公布的系统接口功能特征、特定 功能的拜候参数等接口规格。通过接口和谈的版本划分，为客 户端晋级、其他被集成系统的晋级、和系统的摆设提供了较高 的自由度和灵活性。系统可根据接口请求中包罗的接口和谈版本完成对接口的 向下兼容。系统平台可根据系统的集群策略，按和谈版本分别 摆设，也可多版本并存摆设。由于系统平

13、台可同时支持多版本 的内部系统及客户端使用拜候系统，特别是新版本客户端公布 时，不要求用户强制晋级，也可降低强制晋级安装包公布的几 率。从而支研究参考持系统的客户端与系统平台分离的持续演进。1.1.5接口安全性设计为了保证系统平台的安全运行，各种集成的外部系统都应 该保证其接入的安全性。接口的安全是平台系统安全的一个重要组成部分。保证接 口的自身安全，通过接口实现技术上的安全控制，做到对安全 事件的“可知、可控、可预测”，是实现系统安全的一个重要基 础。根据接口连接特点与业务特色，制定专门的安全技术实施 策略，保证接口的数据传输和数据处理的安全性。系统应在接口的接入点的网络边界实施接口安全掌握

14、。接口的安全控制在逻辑上包括：安全评估、访问控制、入 侵检测、口令认证、安全审计、防（毒）恶意代码、加密等内容。安全评价安全管理人员利用网络扫描器定期（每周）/不定期（当发现 新的安全漏洞时）地进行接口的漏洞扫描与风险评估。扫描对 象包括接口通信服务器本身以及与之关联的交换机、防火墙等, 要求通过扫描器的扫描和评估，发现能被入侵者利用的网络漏洞，并给出检测到漏洞的全面信息，包括位置、详细描述和建 议改进方案，以便及时完善安全策略，降低安全风险。安全管理人员利用系统扫描器对接口通信服务器操作系统 定期（每周）/不定期（当发现新的安全漏洞时）地进行安全漏洞扫 描和风险评价。在接口通信服务器操作系统

15、上，通过依附于服 务器上的扫描器代理侦测服务器内部的漏洞，包括缺少安全补 丁、词典中可猜中的口令、不适当的用户权限、不正确的系统 登录权限、操作系统内部是不是有黑客程序驻留，安全服务配 置等。系统扫描器的使用除了完成操作系统级的安全扫描和风 险评价之外还需要完成文件基线掌握。接口的配置文件包括接口服务间相互协调作业的配置文件、 系统平台与接口研究参考对端系统之间协调作业的配置文件，对接口服务应用的配 置文件进行严格控制，并且配置文件中不应出现口令明文，对 系统权限配置限制到能满足要求的最小权限，关键配置文件加 密保存。为了防止对配置文件的非法修改或删除，要求对配置 文件进行文件级的基线控制。拜候掌握访问控制主要通过防火墙控制接口对端系统与应用支撑平 台之间的相互访问，避免系统间非正常访问，保证接互信息的 可用性、完整性和保密性。访问控制除了保证接口本身的安全 之外，还进一步保证应用支撑平台的安全。为了有效抵御威胁，应采用异构的双防火墙结构，提高对 防火墙安全访问控制机制的破坏难度。双防火墙在选型上采用 异构方式，即采用不同生产厂家不同品牌的