2019电力企业SOA应用技术标准

SOAapplicationtechnologystandardforpowerDLDL/T1992— 前 服务原语参 服务接口规约信 服务质量测量方 服务注册信息参 DLDL/T1992—DLDL/T1992—本标准规定了面向服务的体系结构（Service-OrientedArchitecture，SOA）SOA应用技术框架、SOA的应用系统开发和信息集成建设、SOASOAGB/T29262— GB/T29263— GB/T32427—2015 信息技术SOA成熟度模型及评估方法GB/T32428—2015 信息技术SOA服务质量模型及测评规范GB/T32429—2015 信息技术SOA应用的生存周期过程GB/T32430—2015 信息技术SOA应用的服务分析与设计GB/T32419.1— SOA1GB/T32419.2— SOA2GB/T32419.3— SOA3GB/T32419.4— SOA4GB/T33846.1— SOA1GB/T33846.2— SOA2GB/T29262—2012、GB/T32427—2015、GB/T32419.2—2016中界定的以及下列术语和定义适用serviceintegrationserviceenterpriseITdomain-drivenserviceserviceinteractiveidentityAPIAPI注：API4API：应用程序编程接口（ApplicationProgrammingInterface）CIM：公共信息模型（CommonInformationModel）DDD：领域驱动设计（DomainDrivenDesign）FTP：文件传输协议（FileTransferProtocol）SLA：服务等级协议（Service-LevelAgreement）GB/T29263—20124SOA求。SOA9个部分：ITSOASOASOAIT资源，这些资源存在于SOASOA资源，6服务实现技术要求；SOASOA7服务交互技术要求；IT系统；SOASOASOASOASOASOASOASOAIT治理安全质量1SOA治理安全质量SOA服务描述能力应满 下要求提供标准的信息模型 接口来描述服务和资源的相 性6.1服务注册与发现能力应满 下要求提供服务注册功能 接口，用以对服务和资源进行注册 和发现提供服务 、变更等消息的主动发布接口 于使用者能够 和发现服务的变化7.2.1服务开发能力应满 下要求应提供构建新服务所需的设计、开发、配置、 、 及运行的环境提供相关 具或环境对服务设 从度、服 合性、服 治性等进 测6.5服务编制能力应满 下要求按逻 序调用一系列服务以形成更 度服务为编 的服务提供运 环境服务 能力应满 下要求基 服务，通过服务流程建模、 的方式，构建满足业务流程的新服务提供流程执行 ，为部署的业务流 本提供解释、执行、控制和管理等功能合相关服务 的具体技术标准，具体要求见本标准7.2.2服务 服务管理能力应满 下要求 施和流程，实现服务的全生命周期管理，见本标准5.3服务生存周期过程；对服务的 进行 监控 和执行 相关管理操作服务交互通信能力应满 下要求7.1.4信息服务应满 下要求提供信 集、编目、发布 等功能展现服务应满 下要求提供一组完整的、支持 人机交互的展现功能身份管理服务应满 下要求提供一组可扩展的组织、人员、 等的管理功能服务应满 下要求基于身份管理服务，提供身 控制功能合相 服务的具体技术标准在实现SOA应用系统的过程中需要 的可以支持SOA应用开发在一定范围内具 的复用性SOA功能性要求外，SOA应 需满 下的质量要求 性 可 性 性功 确性服 度合理性 性 立性 出了SOA应用中服务生存周期过程的要求，并定义了过程的目的和输出，以及完成过程所 动服务生存周期过程按分析设计过程、建过程组装过程运维过程4个过程组进行描述。本节在GB/T32429—2015中5服务生存周期过程的基础上， 过程，共包括14个过程， 2所：2 服务 过程的输出 为服务资 ，包括服务域、服 单和服务概念设计服务规过程包括业务分解、应用分解、数据分解、服务 、服务整理等5个动。具体要求见本标准6.2服务规。服务分析是基于SOA应用的总体需求，以服务资源的服务域和服务单规作为参考据，合 服务分析过程的输出 包括 等7个动。具体要求见本标准6.3服务分析。 服务接口定义 服务接 细规约服务实 设计 意见服务设计和服务需求的一致性和 性对应关系服务设计过程包括服务分类、服务定义、服务接口设计、服务实现方式策、服务设计评等5 动。具体要求见本标准6.4服务设计。服务开发是将已定义的服务接 细规约通过技术开 段变成可部署运行的服务的过程 服务描述 对照服务需求的服 与服务设计的一致性和 性对应关系据服务不同的实现方式策，服务开发方式可分为3种类型，分为新建功能服务、映射已有功能服务和 服务测过程是 服务 录 结评等4个动。具体要求见本标准6.6服务测。服务部署过程是 合服务需求的可部署服务包安 目标运行环境中的过程 运 的服务服务部署过程包括服务部署策略制定、原服务部署、组合服务部署、服务部署确等4个动。具体要求见BT3242—2015中的5.3.3服务部署过程。服务发布过程的输出 包括 服务发布过程包括服务发布合约制定、服务发布明制定和评、服务发布等3个动。具体要求见BT3242—2015中5.3.4服务发布过程。 服务发现过程包括服务配模 服务组合过程是将一组服务按照一定的 进行组合封装，使 共同完成一个特定的功能 服务组合过程包括服务组合模型设计、模型评、服务封装等3个 服务组合模型设计 据功能要求，确定服务的组合 ，并据此设计实现服务组合模型 ：对服务组合模型进行 ， 录 。 对上述模型进行必要的 服务封装：对已有的服务按照组合模型设计进行组合，封装成为一个新的、更 度的服务指将一组服务按照一定的 进 序组合，使 共同完成一个特定的任务或业务流程 服务编过程包括服务编模型设计、模型评、服务发现、服务建、服务定等5个动。具体要求见本标准7.2.2服务编。 服务使用过程包括服务使用请、请核、服务配置等3个动。具体要求见本标准7.2.3服务监管过程是据SOA应用确定的策和机制，对运行的服务和业务流程进行监控和管理，以 服务质 ：据服务需求中确定的策略，对服务的运行 服务测量信 集：对服务的各类质量指标进行测量， 录测量 服 管理：对服务运行过程 生 进 录 ，并形成统计分 服务配置在环境条件发生改变或服务需求变更 况下对服务部署和运行的参数进 配服 见本标准服 过程 服务变更 服务变 分 服务变 核意见服务变更过程包括变更请、变更分析、 分析、可行性核等4个动。 分析：据服务使用 服 过程是服务 使 ，将服务从目标运行环境 载的过程 服 请服 核意见服 服务从目标运行环境 载 5个动。 服 请：制 后，提交服 请服 核：相 系方对服 请进 核，并形 核意见 ，可主动通 SOA成熟度模型3所，提供了一种能够助确评估SOA在组织中的适用性和的框SOASOA规和实施进行测量与评估，并且据SOA成熟度模SOA信息化建设目标。SOAa成熟度级：SOA成熟度模型分为个级，每个成熟度级反映了组织或信息化项目在实施SOA的一个抽状。每个成熟度级基于一个或多个成熟度指标建立，对应一系列成熟度性；SOA基于本标准中的系列维度进行评估。评估维度是有效评SOA成熟度级的必要指标；cSOASOA目标成熟度级的提3SOA1：企业的各部 立开 的软件 有进行数据、流程、标准或者技术的集成制约了部门之间的信息共和业务协同，在 的况下，信息化系统 不能进行集成，数 复 和应用 出2：用技 段 之间进行连接，进行数据和功能的集成构建部门应用的信息化系统成为可能，是并未形成通用性的数据和技术标准，此实现个系统之间的集成，需要在系统之间进行复杂的数据、协议和功能的转换，开发一个新的业务流 大信息化系统 分为组件， 可以配置成一个新的功能将业务功 组件的分析过程存 组件通过定义的接口进行交互，是它 开 组织的业务流程能够基 合的业务流程来构建组合应用服务基于开放标准， 应用技 关IT服务可以在企业 部门使用 合业务功 细的分析，并 分为服务，服务可以在业务 进行交互通过规范的语言明确定义每个服务的功能和 这 段，服务组 开发人员定 来实现，限制了新业务流程的开发通过服务组合语言定义组合服务，实现 立的服务的控制和协同 的、流的、基于动的服务，不需要定制 通 化的间接方式提供服务基础设施进 调 实 理服务调用的映射服 组合服务 合 业 维度集中在业务体系结构以及IT策略 IT能力 组织分配以及能 支持业务 性 治理与组织维度集中在组织或信息化项目 及组织的结构 身的设计，以及SOA治理的有 构建和费 分配IT、业务转换方面的方法和过程，以及围软件和系统开发 具的使用应用维度集中在应用风，应用的结构，应用中功能的可分解性、可复用性、性、可性、可SOA应用实和模式的统一性。架构维度集中在企业的整体信息化实现架构，分为单一架构、基 次的架构、基于组件的架构SOA出现、SOA、支持网化的SOA、 可配置的架构信息维度集中在信息构建、信息建模、组织数据的方法、数据从功能方面的抽性、数据特、数据转换能力、服务和流程定义、处理标、安全、管理、业务信息模型和内管理。基础设施和管理维度集中在组织的基础设施能力、服务管理、IT操作、IT管理和IT IT需要在改进，SOA成熟度模型中的维度和域集相关信息，是策略文、用户需求和目标、EA、关 基于所的业务目标、范围和，评估者在组织或信息化项目人员的协助下确定是需要对本SOA成熟度模型进行或扩展，所需或扩展的维度、成熟度指标、性、映射关系或/和，并明确定义出评估所需的SOA成熟度模型。SOASOA成熟度模型对组织和信息化项目关人员进行调，主要据模型中的评估来进行。据调所的信息，评估者对照SOA成熟度模型确定组织或信息化项目前的SOA成熟度级。SOA评估者对组织或信息化项目关人员从未来目标、业务需求、EA、业务服务和基础设施战略进行调，调SOA成熟度模型的维度和域。据调所SOA来确定目标SOA成熟度 及 本节在GB/T32419.1—2016 出的“信息技术SOA技术实现规范第1部分：服务描述”基础上，对服务描述元素进行了细分，分为5种类型：a基本描述指服务的基本性，应包服务标 、服务称、服务基本说明等性，可包 功能描述指服务的外部和内部功能特性，应包外部功能、消息、实现特性， 包内部 功能描述指服务的服务质量性，可包功能确性、服务度适合性、 用性、可扩展性、互操作性、可用性、可管理性、治性、 性、 立性等 业务特描述指从业务角描述服务所电力行业的特，应包业务领域、业务流程和业 统计特描述指服务运行过程中对服务各种运行性的统计特性，可包服务 次数、 量、成功次数 用户分布 度 间、数 量 性 定的 间 一的 应 行业分 、服务提供 、服务 号等a服务 中文应由数、中文组合，英文应由数 组合， 大，用“服务原语服务业务对”的结构 定的、动的、与用户 ：询、建、 对服务进行描述的一段文本说明，应 服务所有功能，以及服务的应 和能力服务版本的标号，式为“..mmdd号，mmdd为服务发布间（日）。服务提供者 细信息 提供 称、提供者联系信息等服务使用者 细信息 使用 称、使用者联系信息等服务对外提供的功能的称，1对服务功能的一段文本说明，应 服务的应 和能力一个服务功能调用，对外可接的参数、类型、式、说明、度等。输入参数可以是0个、1个，或者多个。输入参数的类型应合服务实现技术相关的类型定义，eMLScema定义的类型。 服务使用者， 的参数、类型、式、说明、度等，输出参数可以是0个、1个，或者多个。输出参数的类型应合服务实现技术相关的类型定义， e服务的输入参数应合MLScema定义的类型。服 调用之前 满足的前提条件服 调用之 生的 服务执行过程中可 生 服务使用者 障，障信息应 障 、 称及描述服务使用者和服务提供者之间 消息的结构， 立于特定的编程语言和运 指服务使用者和服务提供者之间传消息的模式，具体要求见7.1.5对于组合服务而言，其组成服务之间的 、组合和调用过程等服务提供 服务使用者的对外入口。服务使用者可通过服 确定服务的网络位置 服务提供者与服务使用者之间传输消息 协议服务提供功能 次与服务使用者功 次间的 性服务与服务使用者之间的关 度， 现为技 立性、位 明性等服 组合使用 程度服务运 ，在资源变 况下其服务能力 需可变能力服务 提供业务功能的能力服务及其 有效监控的能力服务具 立部署 复的能力服务使用者 于服务提供者的 服务调用 与 上下 关的能力业务领域是指服务 的业 动的 业务流程是指组织中一系 动的组合 动之间 序限定业 是指电力业务的一个过程 过程，包括目标、参与方、操作流程和信息 过程在一 间范围内，服 外部服务使用者调用的次数在单位间（日 等）内，服务外部服务使用者调用的次数 的单 间（日 外部服务使用者调用的最多次数在一 间范围内，服 外部服务使用者成功调用的次数在一 间范围内 用户的分 况 次数在一 间范围内 据服 界定服务 程度 程度应设置目 服务规应按照总体盖、可行的原，以企业架构设计的相关成（包括业务架构、应用架构、数据架构、技术架构等）为指，制定组织范围内SOA服务资的总体建设规和设计，以满足组织全局的业务应用需求，为服务分析与设计提供据，指组织的服务资源建设和服务运外考适度前的原 4所 资 用 资 服务单 服务消息质量能力模型要求 服务消息质量能力模型要求 服务消息质量能力模型要求资 服务消息质量能力模型要求4 服 单： 本组织所有服务资源的基本信息，可作为服务设计、开发和管理的主 据 从应用分解的结 出对应 服务，包括个维度 5所 出 服务进行分类、 、归并、整理， 形成服务资 明确项目目标分解项目从了解组织结构、位职责的业务维度出发，了解前业务部门组织结构和职责，未来业务部门（或业务领域）分和职责界定，并标前或未来业务中会关注的职责，形成服务。主要作包括以下内a了解 明 期可行的组织结构和职责 职责发 服务分业 、理业务流程的角度出发， 与项目目标相关的 业，个前流程和未来优化流程细化流程中的操作要求形 服务主 包括以下分与项目目标相关的 业 期可行的业务流程结合职责建模的职责分析 发 服务 集 ，取数据需求的业务维度出发， 与项目目标相关的 业 ， 资料，取部门、位之间的数据需求形成 集相关 资料结合职责建模的职责分析 协明确期可行的数据需求发 服务 ，总领域、流程、数据建模的结 ，个 分析项目目标相关的 业 形 期可行的业务流程模型总形 期可行的业务组件模型形成业务 服务集从系统的维度出发分析 接口和功能列，发现 对照业务 服务与系统 服务的映射关系发 服务 服务中运用 实现的服务的过程， 服 基于应用需求 服务的需求，服 应 不限于下述 素服务功能：满足企业 范围 企业级、企业级、业务领域级或应用程序级 用度 期 用 期 用或不 用可操作性：全部、部分功能已在应用系统中实现或需 新开发开发技术：全 、部 或 现有技术具支持：现 具全面支持、部分支持或不能支持项目规模：大规模、中等规模 规模服务质量 实现 以实现应从业务的角度出发，包 不限于下 业务流 ：通 理、优化企业业务流程，将业务流程转化为 用、更具 用性分析：结合服务规 ，询服务 服务合约中的技术接口是服务相互调用的基础，服务 合约进行设计服务设计 共同的标准体系，包括数据、安全、交互、通信等服务的功能逻辑应是内聚而完整的，并对实现细节以及所 的资源进行封装服务 身变化（包括功能、数据、过程、技术、运行环境等变化）应不对其它服 服务应具 治性 服务应具 立部署 复的能力 服务使用者不应于服务提供者的状，服务调用结与会上下文务应控制在服务内部完成，多个服务之间 务控制 用流程 的方式来实现 ，一个服务仅实现对一类或一组相关的主 服务分类有助于按照不同的要求对服务资源进行分类管控，更有效进行服务组合和用，并为SOA应用的设计和实现提供据，GB/T32430—2015中出了按照服务的不同性进行分抽的分类方法。可按照应用系统的服务化进行服务的分抽，6所，各类服务特性下：a实体服务：对数据模型的操作逻辑进行封装，统一对数据源的，并数据源实现的多性和复杂性，据数据逻辑模型对应封装实体服务；业务服务：对领域业务逻辑进行封装，实现特定的业务功能，用领域驱动设计的方法进行业务功能的分析和分，进而进行业务服务的封装；引用，提供标准化的API资源服务：应用系统外部6 服务的应 服务定义 作 包括 界，考 定义服务接口，考 、安全需求、能力需求、功能需求等确定服务接口的 服 称、消 式、服务 次、关联关系等 定义服务接口：结合服务功能需求，定义服务基本描述信息，服务 确定交互方式：明确服务消息交换模式可支持的请求应、请求 调、发布订阅、通、确定消息交 式及消息结构，制定消息结构应参 下要求 服务合约，定 、明确的消息结构参照电力行业以及本组织所发布的相关数据模型标准进行制定 CIM模型确定技术实现 ，确定功能需求以及性能、安全 功能性需求 盖范围 的服务接口约，形成服务接口细设计规约，规约信 服务实现方 策应 作 确定服务质量要求，具体要求可见6.8服务实现质量评服务安全的总体策略应包下内a分部署：分离的原分为多个安全域，各域间用进行离，界域的安全，针对不同的安全需求和安全风险取相应的安全施；多：针对不同的安全和安全，用多种施，多次以保，并不同次之间的协同，建立完整、的体系；完管理：完安全的组织体系和制度建设，明确安全的责任与分安全运维和安全计作，据安全风险的变化持改进安全策略，制定应应流程和处理 身监控：服务身应具备有效的和，在限分级和数据分类的基础上，能够对关操作、数据进行，同针对外部和用具备一定的测和能力。服务安全机制应包 下 应制定服 限控制体系 的服 应实现用户管理，包括各类服 用户 、用户的基本信息管理等功能应实现 管理，包括各类服 用户的 分配和管理应实 管理，为不同 制 限应实现用 核，对服 请进 核应实 ，对 用户 限进行 ，对相 限进行调整应实现 用户 ，确 有合法用 相应的服务应支持传 安全协议，安全协议应 消息的完整性 实性、保密性 对服务交互信息数据进 密， 消息的保密性 服务构件是服务的基本单元 7 服务构件包括1个服务实现，是服务功能的一种具体实现，实现业务功能的 的入口，描述服务提供的内，定服务构件包括0个或多个服务性，用于配置服务实现的数据 定，服 服务接口使用，用于描述服务 机制 的其它外部服务、组件或资源引服务定服务性 服务实现可使用传统编程语言 本语言 明性语言进行开发服务实现可定义使用某个特定的框架或运 环境服务实现应支持服务集成开发的接模式、理模式和流程模式，具体要求见本标准7服务交服务实现的过程中应满 性要求服务接口应满 下要求 服 性要求 支持TTP SOAP、FTP、SMTP、M等。 据组合服务构件内部各构件 性合并形成可供外 的公开服 性 据组合服务构件内部各构件的接 新定义形成可供外 的公开服务接口 外部引用，组合服务构件的内部服务定服务定服务性服务性服务性服务定8 开发服务的一种方式，据功能逻辑和服务合约 映射已有功能服务：是在服务注册中心已存在功能服务况下，通过服务发现与定来开发服务的一种方式。用已有功能，可复功能的存在，降低维成本。它的动包括服服务发现过程。服务定应考传输协议、消息式的，可通过引入理机制（服务交互通信单元）来合服务消费者和提供者之间的；c新建组合服务，见本标准服务开发应满 下要求 应准确和完整提供服务描述信息，包括服务的基本描述、功能描述、功能描述、业务特 传输大量数据 用 方式进行传输 在服务的内部 套调用其它发布的服务， 出现服务 环引用服务内部应保 度 化 分组合 用中立的、标准的方式进行定义，立于具体的实现技术，不 服务交互数据的 式 为TF- 用缩处 gip、ip或deflate等方式处理应满 下要求的类应分为技术 和业务 技术 主要是 件、基础软件在技术执行过程 生 信息应包括以下内：信息解释为 理解的信息 的原 信息 a接口可用性测：测服务接口是能接请求文并按期 接口实现测：测接口的实现数量及实现形式，包括方法、参数列等是按照设计要求c消息结构测：通过输入消息结构的请求文进行测，包括消息数据模型 、应结的 a测用应盖全部业务功能和业务规的需求；应通 功能的实现质量是满足需求应通过白 功能的实现逻辑 合设计要求通过归 服务变更修改后的确性 负 服务各项性能指标的变 力 确定服务运行 统能提供的最大服务 的 性能 指标应 下指标 并发用户数指标：指 服务可以 承 调用的用户数开展对服务的用 限 条件、数 密等安全的安全 以下 用 限 ：确保服 有具备对 限的用条件 ：确保服务 条 范 次数间 流量 等条件数 密 ：确保服务对外提供的数 。应 以下要求a应分类分制 测用，包括技术应用部署测环境、模 、准备测应包以下内分类的准确性 信息 性对应 描述 源、细信息的结构进行组织、准确 于理解 软 性 数 性 a测组合服务的业务功能实现；测组合服务的整体可性；测测组合服务内多个服务构件之间的关联度及技术测组合服务的可扩展性，服务运行在资源变化况下其服务的分布式部署 量与服务 的对应线据服务 和服务需求，对服务 进行评估， 录评估 指服务仅在一个主机上部署 9 服务服务服务9指服务在多个主机上部署 10 10指 化资源 机、云 等资源）上的部署 11所11 应对部署 进 ，评估服务部署 以及风险 据服务的部署 进行部署，并有对应的过 录应对部署后的服务进 服务 满足业务需求应通过公共机制来实现服务的 询、定位、路由 理， 服务部署位 明化服务实现质量 是指对服务质量特性的能力进行 。服务实现质量 应满足以下要求 度每 治性、状 性、务 。治性、状 性、务立性评方法可参见附录C，其它评方法具体要求见BT32428—2015；对 进行分析，并针对存在 ，提出改 施与建议 12所 务交互通信等功能单元。功能单元互操作关系见7.1.2服务交互功能单元互操作关系。12服务提供者 明服务描述信息， 服务描述信息注 服务注册中心 服务注册中心： 服务描述信息 注：c7.1.3d7.1.412 服务消费者与服务提供者的互操作关 下服务请求：服务消费者向服务提供者 使用服务的请求消息服务 ：服务提供者向服务消费 服务功能执行的 消息7.1.5服务注册中心应满 下要求应具有服务信息 、修改 询功能应具有服务信息的备份 复功能 所注册的信息发生变 应 服务消费者服务注册中心可支持集中式或分布式的服务信息 方式 服务提供者接入功能应满 下要求 应提 服务提供者的消息处理过程支持为已有服务提供服务 、服 理等功能服务消费者接入功能应满 下要求 应能完成与服务消费者的通信协议适配 应能将服务消费者 服务提供者的消息处理过程对接协议适配功能应满 下要求支 不限于以下传输协议TTPTTPSTTPS1.1协议及支持T、POSTFTPSFTP：支持用户和密 录FTP服务；提供对FTP服务目录操作的 ；提供对FTP服务文件操作的能力，包括上传、下载、SMTPPOP3：支持通过SMTP协议进行件发 M：支持业界主流的MSM中间件 ，至少能够实现elogic、eSpereM、Boss、ActiveM等 的接入能力；提供对MS中的Map、Tet、Btes、Stream和Oect种类型的消息支持；支持eeTopic种消息交互模式；消息件：支持合 BT33605-2017电力系统消息件传输规范的消息件 支 不限于以下消息协议 SOAP1.1SOAP1.2规范，SDL1.1SDL2.0Docmentliteral、Docmentencoded、PCliteral和PCencoded的支持；支持多个 间；支持SDL文件的入；提供对SOAP包的 SO：支持量级的数据交换负载均衡功能应满 下要求应提供对服务提供者一方多服务 的负载监测功能 据服务 的负 的服务 理服务请求负载均衡至少应支持以下策略：环（RoundRobin、机（Random、机 eighted；应支持服务 换 ，服务消费者的请求消息传输 基于确 路由功能基于 解析路由功能基于业务 的 路由功能将消息 多个服务 定，通过SOAP （SOAPheaders、JMS定制 性、MQ消息 （包括XML和 传输功能应满 下要求应具有信息传输机制 传输机制负责在服务消费者与服务提供者之间完成信息 确传输应支持 调用 调用支持不 之间的信息传输对需要传输的信息设置不同的 在服务提供者与服务消费者之间提供消 式和 的转换功能 式转换：应支持SOAP、JSON、XML、HTML、E 进行解析处理，转换为标准的SOAP、JSON等通用消息 消息 转换应提供对数据模型的管理、 功能，实现模型的统一管理应提供对基础标准模型 应提供对数据模型 承、关联等关系的支持能力 式进行转换处理，能够将不同的数据文按照模型进行 过服务交互通信单元，接通过端 13所。参考模型具体描述了SOA支撑功能单元各部分之间的互操作关系。 15所。服务提供者和服务消费者之间需要进行数据量大或者量化的文传输，将数据文通过FTP等传输机制与服务交互消息分流传输， FTP服务并将数据 服务交互通信单元将 消 服务消费者服务消费 据数 从FTP服 GB/T32419.2—2016SOA2部分：服务注册与发现”基础上，对服务发现能力进行了细分，分为主动取服务描述信息、动接服务描述信息种方式，并规定了服务注册、服务发现的具体要求。服务注册与发现参考模型17所。服务注册功能应满 下要求应通过服务注册接口提交服务信息，将服务注 服务注册中心，服务注册信息参见附录 5.1.2、5.1.3章节的相关要求； 服务设计要求、服务提供者运行要求配置服务的安全策略、质量策略本节定义了服务注册流程 18 提交服务注册请 是需要订阅发注册成功通应由服务提供者提出服务注 请应对服务注 请进 通过，服务注册人员应 服务注 服务注册中心不通过，应 服务提供者 的 （包 意见，并结流程服务注册成功后，应向服务提供者 在的服务消费者 注册成功 请。不需要， 服务发现的方式包括主 取服务描述信息方式 动 服务描述信息方式主 取方式应满足以下要求 取：服务消费 据服 接口 询条 询 取服务注册信息的完整 动 方式应满足以下要求 取：服务消费 据服 接 取服务注册信息的完整 据服 配 条件，通过调用服务注册中心的外部接口进行服 服务 功能应满 下要求应基 服务，通过服务流程建模、 的方式，构建满足业务流程的新服务 行、并行、分支、合并、流程 套、环、 、件通 、件等 应提供流程执行 ，为部署的业务流 本提供解释、执行、控制和管理等功能应支持对 服务的多线程处理提供对 的服务进 设置、 及数据 的功能应支 处理模型 处理规来处理 ，使服务实能从 中复执5个动，其的过程发现可用的服务。据业务需求及业务流程，确定业务 及 间的交互模型，以及与流 动对应的服务需求对服务 模型进行 ， 录 。 对上述模型进行必要的 对于所需的服务不存在的况，可通过5.3.3服务建过程，构所需的服 发现 建后，需要与服务 模型中调用服务 动进 定本节定义了服 的流程 19 询，存在服务能够满足消费使用需求， 从业务角度进 核合组织的服务使用策略，形 核意见从技术角度进 核合组织的服务使用策略，形 核意见服务未通 核，应 反 核意见 服务配置：请 请核服务使用请服务调用应满 下要求通 理模式或多 理模式来实API组织 系统间的服务调用， 进 级调用限制应满 下要求应对服 连接有 间进 请求应模式是同交互模型，服务消费者发出服务调用请求后一等服务提供者将最 后进行业务处理。 20所。 交互模型，服务消费者发出服务调用请求后，不必等服务提供者将最 21所服务提供者主动发布信息，服务消费者接信息后， 22所。发布订阅接口具体要求见BT3241.4—2016的4服务数据接口。22 23服务消费者发起服务请求，服务提供者执行目标服务 输出 24 24GB/T32419.3—2016SOA3部分：服务管理的7.1监控基础上，了服务监控功能相关要求，服务交互监控功能应满足下要求：a提供服务运行监控功能：取服务状：服务前的用、中、用的状 取服务运行状：已用服务接服务请求并出应的状，包括：前服务中最大会请求数等量信息、前服务的在线用户数、前服务中会请求的并发数量、服务调用请求的接、、处理、、出等信息、某间段内服务量、服务应的最大间、最间及均间等； 取调用某服务出现的各种等件信息，信息包括信息的类型、间和细内等；对信息进行、总，信息应包括（标信息的）描述（将信息解释为可理解的信息）、源（引发的来源）、细信息（一为的原始信息）。 支 件方式 支 信等方式 提 件 处理功能应支 分类处理，具体包括 处理， 进行人为分析，制定 环处理 处理，设置相应 动处理 ，通 动处理 发 处理 应提供互操作接口，具体要求见BT33846.2—2017的5.2.3 取监信息接口。服务交互通信应提 的交互安全机制，应满足以下要求 应 服务交互通信 意外 意 用 用用 / 方式进行身 可扩展或集成多种身 方式包括 安 和 技术等可支持集成 方身 系统， 过程委 方身 支持不同 有特定 限 对服务信息进行密、解密和完整 支持有效的服 计及服 录 服务提供者应提供身份 功能可主动向服务消费者 身份信息可支 的方式向服务消费者 身份信息身份信息发生变 ，应主动将变化的身份信息 服务消费者 每度每）对基于数据式的数据可交换性、基于用户成功 换性、 性 应成 间、最 量等特性进行 对 进行分析，并针对存在 ，提出改 施与建议注：a的评方法见BT32428—20155.75.8A.1出了用的服务原语

附录A