JR∕T 0159-2018 证券期货业机构内部企业服务总线实施规范(金融).pdf

ICS 03.060 A11 JR 中 华 人 民 共 和 国 金 融 行 业 标 准 JR/T 01592018 证券期货业机构内部企业服务总线实施规范 Specification for enterprise service bus implementation in securities and futures industry internal institution 2018 - 09 - 27 发布 2018 - 09 - 27 实施 中国证券监督管理委员会 发 布 JR/T 01592018 I 目 次 前言 . III 引言 . IV 1 范围 . 1 2 术语和定义 . 1 3 概述 . 2 4 组织 . 2 5 总线 . 3 5.1 概述 . 3 5.2 架构 . 4 5.2.1 概述 . 4 5.2.2 基础架构组件 . 4 5.2.3 接入组件 . 5 5.2.4 服务组件 . 6 5.3 协议 . 6 5.3.1 概述 . 6 5.3.2 报文协议 . 6 5.3.3 通讯协议 . 9 5.4 交互模式 . 10 5.4.1 概述 . 10 5.4.2 请求应答（同步） . 10 5.4.3 请求回调（异步） . 11 5.4.4 发布订阅 . 11 5.5 安全 . 12 5.5.1 概述 . 12 5.5.2 通讯级安全 . 12 5.5.3 消息级安全 . 13 5.5.4 应用级安全 . 13 6 服务 . 13 6.1 服务生命管理 . 13 6.1.1 概述 . 13 6.1.2 服务生命周期管理意义 . 13 6.1.3 完整服务生命周期 . 14 6.2 服务识别 . 14 6.2.1 概述 . 14 6.2.2 流程 . 14 JR/T 01592018 II 6.2.3 要点 . 15 6.2.4 输出 . 16 6.3 服务设计 . 16 6.3.1 概述 . 16 6.3.2 流程 . 16 6.3.3 要点 . 17 6.3.4 输出 . 18 6.4 服务开发与测试 . 19 6.4.1 概述 . 19 6.4.2 流程 . 19 6.4.3 输出 . 20 6.5 服务上线与发布 . 20 6.5.1 概述 . 20 6.5.2 流程 . 21 6.5.3 输出 . 21 6.6 服务访问 . 22 6.6.1 概述 . 22 6.6.2 流程 . 22 6.6.3 输出 . 23 6.7 服务运营 . 23 6.7.1 概述 . 23 6.7.2 流程 . 23 6.7.3 输出 . 24 6.8 服务变更 . 24 6.8.1 概述 . 24 6.8.2 流程 . 24 6.9 服务撤销 . 26 6.9.1 概述 . 26 6.9.2 流程 . 26 6.9.3 输出 . 27 附录 A（规范性附录） 典型 SOA 集成场景 . 28 附录 B（规范性附录） 证券公司 ESB 典型服务目录. 42 附录 C（规范性附录） 期货公司 ESB 典型服务目录. 52 参考文献 . 58 JR/T 01592018 III 前 言 本标准依据GB/T 1.1-2009给出的规则起草。 本标准由全国金融标准化技术委员会证券分技术委员会(SAC/TC 180/SC4)提出。 本标准由全国金融标准化技术委员会(SAC/TC 180)归口。 本标准起草单位： 中国证券监督管理委员会信息中心、 中国证券监督管理委员会证券基金机构监管部、兴业证券股份有限公司、中国银河证券股份有限公司、东兴证券股份有限公司、国信证券股份有限公司。 本标准主要起草人：张野、刘铁斌、周云晖、刘叶青、高红洁、曹雷、郭郛、刘斌、唐沛来、彭湘林、刘汉西、蒋剑飞、林伟洁、池烨、唐硕、邱杰、王作敬、周健、贾淑芳、汪照辉、龚大平。 JR/T 01592018 IV 引 言 证券期货业机构对信息技术高度依赖， 伴随着创新业务的推出及新业务模式的变革， 行业信息化建设呈爆发式增长。然而，随着信息建设的逐步深入，各机构内部传统的信息技术架构大多面临着如下难题：信息系统数量众多，各系统数据及技术异构，缺乏统一标准，资源共享难度大；各信息系统模块之间、系统之间耦合度高，结构复杂，变更修改成本昂贵，运维风险高居不下；信息技术架构相对落后，缺乏统一的IT规划，不能有效利用IT的价值；面对业务的变更与创新，信息系统难以对业务需求实现灵活应对、快速响应。 为解决以上问题， 行业围绕企业内部信息技术架构进行了深入研究， 推荐采用基于企业服务总线的面向服务架构，该架构改变系统间两两网状交互现状，将内部各系统之间的数据交互包装成服务，统一在企业服务总线注册，供其他系统调用。大量具体实践经验表明，行业机构实施基于企业服务总线的面向服务架构符合行业业务及技术现状，具备可行性，同时，建成的统一、规范、高效的机构内部数据交互平台， 可快速实现异构系统间的资源共享， 有利于缩短业务创新的技术准备周期， 降低系统运行风险，提高行业整体信息技术水平，具备行业推广的意义和价值。 本标准结合行业已有实施经验，规定了ESB实施的组织架构、总线原理与结构、服务生命周期管理等主要内容，为行业各机构实施企业服务总线，实现面向服务架构提供指导性规范。 JR/T 01592018 1 证券期货业机构内部企业服务总线实施规范 1 范围 本标准规定了企业服务总线的技术结构与组成、 服务生命周期以及项目组织管理， 并给出了企业服务总线的典型应用场景。 本标准适用于证券期货业机构内部企业服务总线的实施。 2 术语和定义 下列术语和定义用于本文件。 2.1 企业服务总线 enterprise service bus;ESB 对企业内部信息系统间的数据交互进行集中管理的总线型平台。 2.2 面向服务架构 service-oriented architecture;SOA 以业务为中心将业务分解为相互连接的、可重复的服务，服务之间通过标准接口进行通讯的IT架构方法。 2.3 可扩展标记语言 eXtensible markup language;XML 计算机所能理解的信息符号组成的标记语言。 2.4 Java 消息服务规范 java message service;JMS 面向消息中间件（Message Oriented Middleware，MOM）在两个应用程序之间，或分布式系统中发送消息进行异步通信的应用程序编程接口（Application Programming Interface，API）规范。 2.5 Web 服务 web service;WS 基于可编程的平台独立、低耦合、自包含的web应用程序。 2.6 网络服务描述语言 web service description language;WSDL 包含一系列描述某个WS定义的语言。 2.7 通用描述、发现与集成服务 universal description discovery and integration;UDDI 提供基于Web Service的注册和发现机制，对 Web services 进行注册和搜索的目录服务。 2.8 命名空间 namespace 规定对象命名范围的唯一识别的一套名字。 2.9 简单对象访问协议 simple object access protocol;SOAP JR/T 01592018 2 在web上交换结构化、固化信息数据的轻量、简单、基于XML的数据交换协议规范。 2.10 服务生产者 service provider 面向服务架构中，负责将某项自有业务功能封装成服务，供其他应用调用访问的提供方。 2.11 服务消费者 service consumer 面向服务架构中，负责调用已有服务来实现业务需求的应用方。 2.12 关键时刻服务 moment of truth;MOT 能够显著提升客户满意度的为客户提供服务的关键服务时间点。 2.13 文档对象模型 document object model;DOM 提供对HTML、XML文档结构化表述，定义可从程序中对该结构进行访问，从而改变文档结构、样式和内容的编程接口。 2.14 XML 简单 API Simple API for XML;SAX 事件驱动式解析XML文档的公开标准，对文档进行流式的顺序扫描，当扫描到文档开始与结束、元素开始与结束等地方时通知事件处理函数，由事件处理函数进行相应操作，然后继续同样的扫描，直至文档结束。 2.15 金融信息交换协议 financial information eXchange;FIX 由国际FIX协会组织提供的开放式协议，在实时证券等金融电子交易的各类参与者之间建立的实时电子化通讯协议。 3 概述 面向服务架构（SOA），在传统的业务层和技术层中增加一个服务层，通过统一的协议和规范将应用逻辑从技术层抽出来封装为相互连接的、 可重复使用的服务。 这些服务能够根据业务层需求灵活组合，与各系统通过企业服务总线（ESB）的标准接口进行通讯，实现信息交换和功能重用，达成系统间的松耦合结构。在SOA下，业务逻辑不依赖于任何特定的技术平台，从而屏蔽不同应用系统硬件平台、操作系统和编程语言的差异，以更迅速、可靠、更具重用性的技术架构重构整个业务系统，从而提升对业务变化的响应效率。典型的SOA集成场景详见附录A。 ESB是企业实现SOA的重要基础，在SOA中实现信息系统间数据交互的集中管理。不同应用将可提供的服务按照规定格式集中发布在ESB上供其他系统调用， ESB对外提供标准的交互方式， 对内实现协议及消息的转换以适配目标系统，消除不同系统间的技术差异，实现交互过程的复用。 本标准围绕ESB的项目组织管理、原理与构成、服务生命周期管理等主要内容，为行业各机构实施ESB项目，建设SOA提供指导规范。 4 组织 SOA解决多系统之间的集成与整合问题，应在IT组织层面加强IT架构统筹规划，跨业务领域、跨IT系统推进ESB项目建设，从企业级别的业务视角，推动IT架构的解耦合与可复用。 JR/T 01592018 3 参考SOA实践指南：分布式系统设计的艺术“角色和组织”章节的典型SOA建设组织架构，综合考虑证券期货机构信息技术现状与实践经验，建议采用下图1所示组织形式。 业务部门业务部门业务部门服务消费开发组ESB运营组（数据库、网络管理、服务运营等）业务功能IT/业务混合功能IT功能IT基础功能IT架构组架构组业务流程架构师系统架构师数据架构师服务生产开发组服务消费开发组服务生产开发组服务生产开发组ESB领导组服务消费开发组ESB实施组（ESB需求小组、ESB开发小组、ESB测试小组） 图1 ESB 项目组织架构 各参与方职责如下： a) 业务部门：根据业务发展向 IT 部门提出业务需求。 b) 服务消费开发组：需求阶段，对口业务部门收集业务需求，提出服务提议。开发阶段，接入ESB 调用 SOA 服务，完成应用系统功能开发。 c) 服务生产开发组：配合实施组提供服务所需的接口及数据。 d) ESB 实施组：运用 SOA 理念分析服务消费开发组提出的服务需求，进行服务设计，按照设计完成服务开发、测试，分为 ESB 需求小组、ESB 开发小组和 ESB 测试小组。 e) IT 架构组：在企业 SOA 建设过程中，负责协调 SOA 全局战略实施步骤，建议规范 SOA 推进过程，包括数据架构师、业务流程架构师、系统架构师。 f) ESB 运营组：负责数据库、网络、安全、系统管理等基础运维，为服务开发提供支持。服务管理方面，负责服务的上线、发布、访问相关的审批与实施，负责服务日常运行情况的监测。 g) ESB 领导组：协调指导 SOA/ESB 建设。 5 总线 5.1 概述 JR/T 01592018 4 ESB是一个具有标准接口、实现了互连通信、服务路由等功能的基础平台，是实现SOA的重要技术基础。它以开放标准为基础来支持应用之间消息、事件和服务级别上动态的互连互通，是一种在松散耦合的服务和应用之间标准的集成方式，简化了整个企业信息系统的复杂性，提高信息系统架构的灵活性，降低企业内部信息共享的成本。 ESB的关键职责是协议转换与服务路由，同时还包括服务标准化、安全性、可靠性及可管理性等。这些特性使SOA的高互操作性成为可能， 使得异构系统间能够实现服务调用。 ESB消除了不同应用之间的技术差异，让不同的应用服务协调运作，实现不同系统之间的通信与整合。它支持基于内容的路由和过滤， 具备了复杂数据的传输与转换能力， 并可以提供一系列的标准接口。 ESB的建设应遵循SOA总体规划。总线可以不只一条，可根据服务性质、数量、性能要求的不同，分区域、分业务、分级别设计多条总线的建设方案。 5.2 架构 5.2.1 概述 ESB架构主要包含基础架构组件（消息总线、协议转换、服务目录、服务路由、日志组件、监控组件等）、接入组件（访问管理、适配接口等）和服务组件，见图2所示。服务生产者与服务消费者直接与ESB平台对接。 ESB应用应用平台平台服务生产者服务生产者服务生产者服务生产者服务生产者服务消费者服务消费者服务消费者服务消费者服务消费者消息总线适配接口（SOAP、REST、SOCKET、HTTP/S、JMS、SMTP、JDBC等）访问管理(身份认证、权限、过滤等)服务组件（服务封装、服务编排与组合、服务、服务消息转换、错误与异常处理等）协议转换日志组件监控组件服务目录服务路由 图2 ESB 内部架构 5.2.2 基础架构组件 5.2.2.1 消息总线 消息总线是ESB中所有消息流转的核心组件， 绝大多数消息总线均支持JMS规范。 支持点到点与发布/订阅传输模型、同步与异步消息发送、消息优先级、消息过滤、安全性与可靠性等特性。在ESB中，消息总线存储消息直到它被服务程序处理，消息总线以下述方式工作： a) 接入层将消息放入指定的消息队列； JR/T 01592018 5 b) 路由组件取出消息，并将它放到被调用服务的队列中； c) 被调用服务从它的队列中读取消息，处理消息，并将处理结果放回调用方队列。 5.2.2.2 协议转换 服务消费者与服务生产者的数据格式通常并不一致，ESB作为两者之间的中间层，需要实现消息内容映射与消息格式转换功能，这是ESB的核心功能之一。不同的业务系统可能会使用不同的协议传递消息， ESB平台提供不同的接口类型以适应不同的入口协议或者出口， 协议的转换在ESB平台的内部封装完成。一方面，将服务消费者的请求消息转换为服务生产者所能接受的格式；另一方面，将服务生产者的应答消息转换为服务消费者所要求的格式。 5.2.2.3 服务目录 ESB发布的服务统一注册到服务目录中，服务消费者可以通过服务目录查询所需的服务接口定义等信息。服务目录组件负责服务的注册、变更、撤销、查询等，一般采用UDDI协议实现。 5.2.2.4 服务路由 服务路由组件负责从服务消费者向服务生产者发起服务调用，然后再从服务生产者把应答传递回来。 该组件可以实现基于内容的路由， 即根据消息优先级或内容等的不同进行不同的处理或发送给不同的服务生产者。服务路由组件是实现组合服务的基础。 5.2.2.5 日志组件 日志组件通过良好定义的日志结构和行为，为ESB内部的各个服务提供统一、标准的日志功能。记录服务调用情况、服务出错异常信息等内容，提供日志查看和对日志信息进行审计分析的界面。 5.2.2.6 监控组件 监控组件用于监测ESB主要可能发生的异常，对异常进行归类，辨别发生异常的问题出在哪，如消息解析异常， 权限校验异常， 路由检索异常， 消息路由传输异常等等。 定义统一的异常消息结构和行为，为该平台内部的各个服务提供统一、标准的异常处理功能。 异常发生时， 除记录异常信息到日志数据库和本地磁盘文件外， 还可以根据配置的规则进行进一步的处理，如发送邮件、短信给系统管理员或相关的管理人员，及时跟踪排除问题。 5.2.3 接入组件 5.2.3.1 访问管理 访问管理组件提供ESB的接入功能，外部应用系统访问ESB的服务时，统一通过访问管理组件进行。接入协议方面，ESB为各渠道提供多种接入协议，如HTTP、JMS等。HTTP主要面向同步接入请求；JMS则主要面向异步接入请求。功能方面，访问管理组件作为ESB的门户和唯一访问入口，实现下面的功能： a) 身份认证（Authentication）：在访问时，外部应用系统应提供系统身份标识和密码，供访问管理组件进行身份认证； b) 权限校验（Authorization）：访问管理组件根据外部应用系统的身份，进行权限校验，以确保外部应用系统有权限访问所请求的 ESB 服务和操作。权限校验以服务操作为最小控制单元； c) 过滤（Filtering）：ESB 可以根据设定的过滤条件过滤一些不合规则的服务请求。不同接入方式的数据报文采用相同的数据标准， 该组件对传输报文进行数据逻辑校验， 验证报文格式是否有效，如校验数据项的数据类型、格式、长度、以及是否允许为空等。 JR/T 01592018 6 d) 路由（Routing）：ESB 可以根据服务请求的内容把请求路由到相应的服务生产者。如：账户服务请求由 ESB 自动路由到账户系统，产品服务请求由 ESB 自动路由到产品系统。 5.2.3.2 适配接口 ESB需要支持许多不同的方式将系统集成在一起。集成的一个关键元素是适配器的使用。适配接口对接服务生产者所提供的服务的封装方式。 a) 通用接口：使用标准的通讯协议，如 HTTP、JMS，其接入方式较为固定，可以在 ESB 的开发模板中实现，在开发业务服务时可以直接调用，无需再次开发。 b) 定制接口：使用的其他类型通讯协议，如 SOCKET、API 库等，采用定制开发的接口，根据具体的协议来实现。 c) 适配器：适配器是针对特定系统或技术封装的接口，如 LDAP 适配器、文件适配器、EJB 适配器等。 有现成适配器产品的应用系统能够直接与该平台中的业务进行交互， 还可以通过适配器开发包（Adapter SDK）开发专用的适配器，实现专用系统的接入。 5.2.4 服务组件 服务组件负责与各业务系统（主要是服务生产者）进行交互，对业务系统的功能进行封装，由该平台通过统一的服务接口发布，供其他系统使用。设计业务服务时是根据业务需求确定响应时间、系统吞吐量（Transaction processing systems,TPS）等性能指标，作为开发和测试的标准。 服务组件主要实现以下功能： a) 服务封装：与后端业务系统进行交互，将业务系统的功能或数据包装成业务服务，供其他系统使用。根据业务功能的复杂程度，存在单次调用、多次调用、组合调用等多种形式； b) 服务编排与组合：对现有的原子服务或其他组合服务进行编排、组合生成新的组合服务，使得服务消费者可以在更高层次上使用经过整合的业务功能； c) 服务：实现服务的业务处理逻辑； d) 服务消息转换： 前端系统（服务消费者）与后端系统（服务生产者）的数据格式通常并不一致，业务服务作为两者之间的中间层，需要实现消息内容映射与消息格式转换的功能。一方面，将前端系统的请求消息转换为后端系统所能接受的格式； 另一方面， 将后端系统的应答消息转换为前端系统所要求的格式； e) 错误与异常处理：业务服务访问后端系统时，可能会遇到各种错误和异常情况，如网络中断、服务器故障、 数据错误等， 业务服务应捕获这些错误和异常并向服务消费者返回对应的错误信息； 5.3 协议 5.3.1 概述 ESB既支持开放的标准协议，如SOAP over HTTP、SOAP over JMS、JSON over REST（Representational State Transfer，表述性状态转移）等，也支持定制接口：Socket、API开发包等，也可以采用适配器（Adapter）来实现，如数据库适配器、文件适配器等。 ESB协议主要包括报文协议以及通讯协议。 5.3.2 报文协议 5.3.2.1 概述 ESB的报文协议可以使用文本协议或者二进制协议。建议采用如下报文协议： JR/T 01592018 7 a) SOAP 是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化和固化的信息。SOAP 可以和现存的许多互联网协议和格式结合使用，包括超文本传输协议 HTTP、简单邮件传输协议 SMTP 及多用途网际邮件扩充协议 MIME。它还支持从消息系统到远程过程调用 RPC等大量的应用程序。 b) JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，易于人阅读和编写，同时也易于机器解析和生成。在数据的表达上，JSON 采用“名称/值对”的方式，同时支持数组的表示。JSON 格式的数据同样具有良好的通用性和移植性。在数据的解析上，JSON 提供了整体的数据解析方案，即数据解析只有在获得全部数据包后才能进行；而 XML 同时支持 DOM 和SAX 两种解析方案，既可以在获得全部数据包后进行解析，也可以在获得部分数据包时即进行解析，这种 XML 特有的逐步解析方案对于大量数据的处理非常合适。 c) FIX 协议是由国际 FIX 协会组织提供的一个开放式协议， 在国际贸易电子化的各类参与者之间建立起实时的电子化通讯协议。对性能要求较高的交易相关服务建议使用 FIX 协议。 报文由报文头和报文体组成， 报文头又分为请求头与应答头， 报文体由不同的服务提供方自行定义。 5.3.2.2 标准请求头 标准请求头字段相关说明如表1所示： 表1 标准请求头字段说明 字段名称字段名称 必要必要/可选可选 数据类型数据类型 说明说明 TransactionID 必要 string 唯一的 ESB 服务序列号。每次调用 ESB 服务时需要产生一个新的序列号。当 ESB 服务应答消息时，此字段值将保留在应答头，也就是说，此字段值请求与应答应该相同。 TrackingID 可选 string 唯一的追踪序列号。在 ESB 服务再次调用 ESB 服务时，此值将不会改变，能够将多个请求关联起来，用于追踪端到端（End to End）所有参与的消息。当 ESB 服务应答消息时，此字段值将保留在应答头，也就是说，此字段值请求与应答应该相同。 CorrelationID 可选 string ESB 服务的关联序列号，用以关联 ESB 服务的请求消息与异步应答消息。当 ESB 服务应答消息时，此字段值将保留在应答头，也就是说，此字段的值请求与应答应该相同。 Source 可选 string 调用 ESB 服务的源头。在 ESB 服务再次调用 ESB 服务时，此值将不会改变已用于追踪最原始的源头。 Caller 可选 string 调用 ESB 服务的父亲调用者（Parent，Caller）。 Timestamp 必要 dateTime 调用 ESB 服务的当时时间。 Destination 可选 string 服务的目的名称，用于路由使用。 SessionControl 可选 element 主要用于保存用户的各种信息， 包括 SessionKey 和 SessionData两个子元素。 各字段的具体用法： a) TransactionID： 由 ESB 客户端在发起请求时设置， 其规则由客户端维护， 应保证 ID 是唯一的。 b) TrackingID：由 ESB 客户端在发起请求时设置，其规则由客户端维护，应保证 ID 是唯一的。 JR/T 01592018 8 c) CorrelationID：ESB 的客户端无需设置该字段。该字段主要用于服务端返回异步应答消息时。ESB 服务在应答客户端请求时，将请求消息的 TransactionID 置入。客户端在接收到应答消息后，由此字段识别是哪一次请求的应答消息。 d) Source：初次发起该调用的客户端识别号。 e) Caller：当 ESB 服务再次调用其他的 ESB 服务时，由 ESB 进行填入，表明调用者的身份。ESB的客户端无需设置该字段。 f) Timestamp：由客户端在发起请求时设置，为调用时的系统时间，例如：2015-10-29T14:38:57.246+08:00。 g) Destination：由 ESB 服务使用，客户端无需设置。 h) SessionControl：用于有状态的 Web 服务，能够在会话所包含多个请求间内共享状态信息，此时服务端会在 SessionControl 中放入 Session 信息。 客户端在接收到应答后， 应检查该字段。若有内容，则应在后续属于同一 Session 的请求中，同时传递该 Session 信息。 5.3.2.3 标准应答头 标准应答头字段相关说明如表2所示： 表2 标准应答头字段说明 字段名称字段名称 必要必要/可选可选 数据类型数据类型 说明说明 TransactionID 必要 string 唯一的 ESB 服务序列号。每次调用 ESB 服务时需要产生一个新的序列号。当 ESB 服务应答消息时，此字段值将保留在应答头，也就是说，此字段值请求与应答应该相同。 TrackingID 可选 string 唯一的追踪序列号。在 ESB 服务再次调用 ESB 服务时，此值将不会改变，能够将多个请求关联起来，用于追踪端到端（End to End）所有参与的消息。当 ESB 服务应答消息时，此字段值将保留在应答头，也就是说，此字段值请求与应答应该相同。 CorrelationID 可选 string ESB 服务的关联序列号，用以关联 ESB 服务的请求消息与异步应答消息。当 ESB 服务应答消息时，此字段值将保留在应答头，也就是说，此字段的值请求与应答应该相同。 Timestamp 必要 dateTime 应答 ESB 服务的当时时间。 StatusCode 必要 integer ESB 服务执行的状态：0 代表执行成功，1 代表执行失败，并且此应答消息含有 Error 元素。 通常，该错误代表在 ESB 之中的运行状态（如消息格式错误、调用超时等），并不表示调用生产者时的其业务执行结果（如交易成功或失败）。 SessionControl 可选 element 主要用于保存用户的各种信息，包括 SessionKey 和 SessionData两个子元素。 Error 可选 element ESB 之中执行失败的详细错误消息。 各字段的具体用法： a) TransactionID：由 ESB 客户端在发起请求时设置，其规则由客户端维护。服务端在返回应答消息时，在该字段置入请求消息的 TransactionID。 JR/T 01592018 9 b) TrackingID：由 ESB 客户端在发起请求时设置，其规则由客户端维护。服务端在返回应答消息时，在该字段置入请求消息的 TrackingID。 c) CorrelationID：该字段主要用于服务端返回异步应答消息时。ESB 服务在应答客户端请求时，将请求消息的 TransactionID 置入。 客户端在接收到应答消息后， 由此字段识别是哪一次请求的应答消息。 d) Timestamp：由服务器在返回应答时设置，为返回时的系统时间。 e) StatusCode 元素，用于存储 ESB 调用出栈消息的状态码，目前设计固定值有两个，分别为：0、1，表示服务应答的两种状态：正确处理、出现错误。客户端在接收到应答后，应首先处理该元素。 f) SessionControl：用于有状态的 Web 服务，能够在会话所包含多个请求间内共享状态信息，此时服务端会在 SessionControl 中放入 Session 信息。 客户端在接收到应答后， 应检查该字段。若有内容，则应在后续属于同一 Session 的请求中，同时传递该 Session 信息。 Error 元素的各字段说明如表 3 所示： 表3 标准应答头 Error 字段说明 字段名称字段名称 必要必要/可选可选 数据类型数据类型 说明说明 ErrorType 必要 string 错误类型为： SYSTEM：系统错误 VALIDATION：字段校验错误 MEDIATION：转换错误 PROVIDER：服务生产者错误 BUSINESS：业务错误 COMPOSITE：组合错误 ErrorCode 必要 string 特定的错误代码，如调用服务生产者超时。 Timestamp 可选 dateTime 错误发生的当时时间。 ErrorMessage 可选 string 错误描述。 ErrorContext 可选 string 错误的上下文消息以便于除错。 ErrorActor 可选 string 谁引发这个错误。 5.3.2.4 报文体 报文体是业务数据的载体， 其结构与某一项具体业务相关， 不同的业务场景报文体的结构是不同的。报文体的设计应基于企业的公共数据模型， 定义出每个服务操作的输入输出字段的名称、 类型及数据限制等，并通过接口WSDL文件等形式发布出来。报文体设计时应遵循统一的命名规范。 公共数据模型（Common Data Model，CDM）是能够在不同的业务服务间共享和重用的数据结构，也是企业内不同系统间进行信息交互的标准“语言”。通过数据规划形成公共数据模型是SOA/ESB建设实施过程的重要方面，直接影响业务对象的标准化和重用，进而影响到整个架构的合理性、灵活性等方面。 5.3.3 通讯协议 5.3.3.1 概述 JR/T 01592018 10 ESB使用多种公认、成熟和可靠的通信协议，来支撑上层报文数据传输，如HTTP协议、JMS协议、TCP定制协议等。 5.3.3.2 HTTP 协议 HTTP协议是目前互联网上使用最广泛的协议，同时也是Web服务中默认的通讯协议，实现简单快速。HTTP协议的消息交换是同步的，采用了请求应答的模型。 5.3.3.3 JMS 协议 JMS协议是Java消息服务标准协议，是与具体平台无关的规范协议。通过JMS协议与消息中间件交互是一种高效的消息传递机制，而且目前使用也比较广泛，大多数Web服务框架都支持。 5.3.3.4 SOCKET 定制协议 ESB对接各类信息系统， 考虑到某些系统不一定支持上述的标准通讯协议， 可以使用TCP/UDP作为消息通讯协议与ESB交互。采用该种方式，客户端必须自行管理SOCKET连接，实现消息的收发，以及消息的解析。 交互的消息格式建议采用基于SOAP的消息格式，以提供更好的通用性和移植的便利性；如果业务系统不支持SOAP消息格式， 也可以直接采用业务系统的消息格式 （通常为原始的SOCKET字节流格式） ，此时需要在ESB端进行SOCKET消息的解析，系统的通用性和移植性会受到影响。 5.4 交互模式 5.4.1 概述 ESB在信息系统间交换数据，根据交换消息的不同方式进行分类，从而形成不同的信息交互模式。ESB一般应支持如下几种交互模式： a) 请求应答（同步）； b) 请求回调（异步）； c) 发布订阅。 5.4.2 请求应答（同步） 此模式中服务消费者发送一个请求，进入阻塞状态，直到接收到服务生产者发出应答消息。如下所示交互图3： 服务消费者ESB服务生产者发送请求路由请求发送应答应答路由处理请求阻塞 图3 请求-应答交互模式 JR/T 01592018 11 5.4.3 请求回调（异步） 消费者发送一个请求之后不需要一直阻塞进程等待生产端的应答才能继续后续的工作， 当消费请求发送完毕后， 就可以处理其他的事情； 而生产端处理完毕后， 通过另一个进程将反馈结果发送到消费端，类似于回调机制。如下所示交互图4： 服务消费者服务生产者(回调接口)ESB服务生产者系统AESB系统B发送请求(进程A)请求路由处理请求发送应答(新的请求)路由应答(进程B)处理响应非阻塞 图4 请求-回调交互模式 该模式下， 服务端应在应答消息的CorrelationID字段中填入请求消息的TransactionID， 客户端在接收到应答消息后，由此识别是哪一次的请求。 从应用场景来看，请求回调适合于流程的处理。通常流程处理过程中，某个任务节点的审核可能需要几个小时甚至更长的时间， 而客户端不可能一直处于等待状态， 但是最终又需要得到最终的反馈以处理后续流程，此时采用请求回调模式比较适合。例如呼叫中心的客户服务记录，客户的服务请求提交后需要等待审核， 该审核过程可能需要花费比较长的时间， 而当审核完毕后可以以异步的方式通知到其他消费方，此时消费方就可以继续处理后续流程。 5.4.4 发布订阅 发布订阅模式是一种事件通知模型，类似于消息的广播，它可以有一个或多个接收端。ESB一般使用消息中间件来实现发布订阅模式，即多个接收端订阅某个主题（Topic），事件源将消息发送到这个主题上， 所有订阅了此主题的接收端能同时收到发布的消息。 通过消息中间件可以保证消息的不丢失，并以松散耦合的方式通知到消息接收端。如下所示交互图5： JR/T 01592018 12 对象2事件源ESB事件处理回调接口事件通知事件处理事件路由 图5 通过 ESB 服务调用进行发布-订阅 5.5 安全 5.5.1 概述 ESB的安全问题涵盖认证、授权、机密性、完整性、可用性、日志、审计，涉及到网络传输、通讯协议、数据、应用交互这些不同层面。在ESB实施中，需要通过在不同级别采用不同技术来实现ESB平台的安全要求： a) 可以利用操作系统及安全证书来实现通讯级别的安全； b) ESB 平台本身，则提供了消息级别和应用级别的安全能力。 具体如下表4所示： 表4 ESB 的安全级别及安全措施 安全级别安全级别 安全措施安全措施 通讯级安全 IP 层安全：利用操作系统级别的 IPSec 协议 传输层安全：采用 SSL 技术，ESB 中支持 HTTPS 及在 JMS 协议中使用证书；可以采用内部 OpenSSL 生成的证书，也可用权威 CA 机构颁发的证书 消息级安全 利用 WS-Security 框架及相关 WS 协议族： 对 XML 数据进行加密/解密实现保密性（Confidentiality） 对 XML 数据进行数字签名实现完整性（Integrity） 采用支持数字签名、加密/解密的 WS-Security Policy 能将 Security Policy 作为可操作的单元加载到 SOAP 请求、应答、Fault 等对象 支持对消息有效期限的限制（TimeOut） 采用 PGP 协议实现轻量级的消息加密 应用级安全 强化 XML 解析引擎的功能防范 XML 拒绝访问攻击（XML，DoS） 优化 BS 结构的应用，禁止用户注入 SQL 实施攻击 5.5.2 通讯级安全 通讯级安全关注网络传输过程中的安全性问题，可以从两方面来实现： a) IP 层安全 JR/T 01592018 13 IPSec是IP层的安全机制，通过在IP层上对数据包进行高强度的安全处理来提供数据源验证、无连接数据完整性、 数据机密性等安全服务， 一般在操作系统级别实现。 对于使用IPSec的Web服务来说， 应在进行Web服务调用之前创建IPSec通讯会话。 企业内部各应用系统运行在内网，可以不采用IPSec技术。若存在企业外部系统的访问要求，或异地的互联网访问，可以根据安全要求决定是否采用IPSec技术，并对该段传输进行安全控制。 b) 传输层安全 传输层安全通常是由SSL/TLS提供的，例如HTTPS。传输层安全可以在网络应用程序，而不是操作系统中实现，而Web服务只需要求使用HTTPS或者支持证书的JMS作为传输协议便可直接使用。 企业内部各应用系统运行在内网，可以不采用SSL技术。若存在企业外部系统的访问要求，或异地的互联网访问，可以根据安全要求决定是否采用SSL技术。采用SSL技术时，应在ESB中提供统一的接入模块，对远程的应用进行安全控制。 SSL证书方面， 可以采用工具 （例如OpenSSL） 来生成证书， 其根证书是企业自身签发 （Self-signed）的，用于认证、授权、完整性、加密等