系统对接方案.docx

系统对接设计 对接方式 系统与外部系统的对接方式以 web service 方式进行。系统接口标准： 本系统采纳 SOA体系架构， 通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成， 因此 SOA体系标准就是我们采纳的接口核心标准。主要包括： 服务目录标准： 服务目录 API 接口格式参考国家以及关于服务目录的元数据指导规 范，对于 W3C UDDI v2 API 结构规范，实行 UDDI v2 的 API 的模型，定义 UDDI的查询和发布服务接口， 定制基于 Java 和 SOAP的访问接口。 除了基于 SOAP1.2的 WebService 接口方式，对于基于消息的接口采纳 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 or JMS and RMI/IIOP 接口。 业务流程标准：使用没有扩展的标准的 BPEL4W，S 对于业务流程以 SOAP服务形式进行访问，业务流程之间的调用通过 SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过 IP 白名单、 SSL 认证等方式保证集成互访的合法性与安全性。 数据交换标准： 制定适合双方系统统一的数据交换数据标准， 支持对增量的数据自动进行数据同步，避开人工重复录入的工作。 接口规范性设计 系统平台中的接口众多， 依靠关系复杂， 通过接口交换的数据与接口调用必需遵循统一的接口模型进行设计。 接口模型除了遵循工程统一的数据标准和接口 规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安 规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安 全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。 接口定义约定 客户端与系统平台以及系统平台间的接口消息协议采纳基于 HTTP 协议的 REST风格接口实现，协议栈如图 4-2 所示。 业务消息 会话数据 HTTP/ HTTPS TCP/IP 底层承载 图表错误！文档中没有指定样式的文字。 - 接口消息协议栈示意图 系统在 http 协议中传输的应用数据采纳具有自说明、自包含特征的 JSON 数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。 在接口协议中， 包含接口的版本信息， 通过协议版本约束服务功能规范， 支持服务平台间接口协作的升级和扩展。 一个服务供应者可通过版本区分同时支持 多个版本的客户端， 从而使得组件服务的供应者和使用者依据实际的需要， 独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。 业务消息约定 恳求消息 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-8。 应答消息根节点为“response ”，每个响应包含固定的两个属性节点： “ status ” 和“ message”。它们分别表示操作的返回值和返回消息描述， 其他的同级子节点 为业务返回对象属性，依据业务类型的不同，有不同的属性名称。 当客户端支持数据压缩传输时， 需要在恳求的消息头的“Accept-Encoding ” 字段中指定压缩方式 (gzip) ，如消息可以被压缩传输则平台将应答的数据报文进 行压缩作为应答数据返回， Content-Length 为压缩后的数据长度。具体参见HTTP/1.1 RFC2616。 响应码规则约定 响应结果码在响应消息的 “status ”属性中， 相应的说明信息在响应消息的“ message”属性中。说明消息为终端用户可读的消