DL∕T 1992-2019 电力企业SOA应用技术标准(电力).pdf

ICS 27.100 F 20 备案号：63143-2018 中华人民共和国电力行业标准 DL / T 1992 2019 电力企业 SOA 应用技术标准 SOA application technology standard for power enterprises 2019-06-04发布 2019-10-01实施 国家能源局 发 布 DL / T 1992 2019 I 目 次 前 言 .IIII 1 范围.3 2 规范性引用文件.3 3 术语和定义.3 4 缩略语.4 5 SOA 应用技术框架 .4 6 服务实现技术要求.17 7 服务交互技术要求.33 附录 A（资料性附录） 服务原语参考.47 附录 B（资料性附录） 服务接口规约信息.48 附录 C（资料性附录） 服务质量测量方法.50 附录 D（资料性附录） 服务注册信息参考.52 DL / T 1992 2019 II 前 言 为规范SOA应用技术框架、服务实现技术要求以及服务交互技术要求，制定本标准。 本标准由中国电力企业联合会标准化管理中心提出并负责解释。 本标准由电力行业信息标准化技术委员会归口。 本标准起草单位：中国南方电网有限责任公司、鼎信信息科技有限责任公司、云南电网有限责任公司、云南云电同方科技有限责任公司。 本标准主要起草人：王志英、衡星辰、董灿、张诗军、董召杰、周兴东、吴波、胡永华、张羿、张建文、徐兵元、邓安明、方俊霆、段福亮、黄载瑜、邰璐璐、曹巍、刘莉。 本标准首次发布。 本标准在执行过程中的意见或意见反馈至中国电力企业联合会标准化管理中心 （北京市白广路二条一号，100761） 。 DL / T 1992 2019 3 电力企业 SOA 应用技术标准 1 范围 本标准规定了面向服务的体系结构（Service-Oriented Architecture，SOA）的 SOA 应用技术框架、服务实现技术要求以及服务交互技术要求。 本标准适用于电力企业基于 SOA 的应用系统开发和信息集成建设、SOA 项目咨询和 SOA 项目监理。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。 凡是注日期的引用文件， 仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 292622012 信息技术面向服务的体系结构（SOA）术语 GB/T 292632012 信息技术面向服务的体系结构（SOA）应用的总体技术要求 GB/T 324272015 信息技术 SOA 成熟度模型及评估方法 GB/T 324282015 信息技术 SOA 服务质量模型及测评规范 GB/T 324292015 信息技术 SOA 应用的生存周期过程 GB/T 324302015 信息技术 SOA 应用的服务分析与设计 GB/T 32419.12016 信息技术 SOA 技术实现规范第 1 部分：服务描述 GB/T 32419.22016 信息技术 SOA 技术实现规范第 2 部分：服务注册与发现 GB/T 32419.32016 信息技术 SOA 技术实现规范第 3 部分：服务管理 GB/T 32419.42016 信息技术 SOA 技术实现规范第 4 部分：基于发布订阅的数据服务接口 GB/T 33846.12017 信息技术 SOA 支撑功能单元互操作第 1 部分：总体框架 GB/T 33846.22017 信息技术 SOA 支撑功能单元互操作第 2 部分：技术要求 3 术语和定义 GB/T 292622012、GB/T 324272015、GB/T 32419.22016 中界定的以及下列术语和定义适用于本文件。 3.1 服务集成开发 service integration development 对多个服务按照某种模式进行组合调用，形成满足特定业务需求的新服务的行为。 3.2 服务原语 service primitive 服务逻辑处理的动作，以服务使用者的角度进行描述。 3.3 企业架构 enterprise architecture 国际上各个大型组织通行的、 用来促进业务与信息化融合， 在快速变革中驾驭全局， 优化投资结构，降低变革成本，控制变革风险的一套行之有效的方法。它是包括企业战略、组织、职能、业务流程、IT系统、数据、网络部署等的完整、一体化描述，反映了企业业务的状况、体现了业务与 IT 的映射关系，DL / T 1992 2019 4 能够明确各类 IT 设施对业务的支撑关系。 3.4 领域驱动设计 domain-driven design 一种通过将软件实现与核心业务概念的演进紧密相连从而实现复杂需求的软件开发方法。 3.5 服务实例 service instance 可对外提供服务能力的程序集。 3.6 服务交互通信 service interactive communication 在服务请求者与服务消费者之间提供接入、负载均衡、传输、路由及转换的功能单元，在实际交互过程中，服务交互通信的实现方式包括企业服务总线、服务网关等。 3.7 身份同步 identity synchronization 使同一个实体在不同信息系统中的身份数据保持一致的相对关系。 3.8 集成 integration 将一些孤立的信息或元素通过某种方式集中在一起，建立联系，并且构成一个有机整体的过程。 3.9 API 网关 API gateway 提供 API 托管服务，涵盖 API 发布、管理、运维、售卖的全生命周期管理。辅助用户简单、快速、低成本、低风险的实现微服务聚合、前后端分离、系统集成，向合作伙伴、开发者开放功能和数据。 注：API 缩略语说明见本标准 4 缩略语。 4 缩略语 API：应用程序编程接口（Application Programming Interface） CIM：公共信息模型（Common Information Model） DDD：领域驱动设计（Domain Driven Design） FTP：文件传输协议（File Transfer Protocol） SLA：服务等级协议（Service-Level Agreement） 5 SOA 应用技术框架 5.1 SOA 应用概念模型 见 GB/T 292632012 第 4 章 SOA 应用概念模型。 5.2 SOA 应用技术参考模型 5.2.1 总述 DL / T 1992 2019 5 SOA 应用技术参考模型适用于 SOA 应用的构建、 运行和管理过程， 本节见 GB/T 292632012 中 4 SOA 应用技术参考模型， 在原参考模型基础上细化了 SOA 应用技术参考模型中每个实线部分的技术要求。SOA 应用技术参考模型主要包括 9 个部分： a) IT 基础设施是承载 SOA 应用的已有运行环境以及未来可配置和扩展的基础环境； b) SOA 资源是实现 SOA 应用所需的应用系统、数据以及现存服务等 IT 资源，这些资源存在于企业、 政府部门以及其它组织机构内， 作为 SOA 应用建设中服务的初始来源； 基于 SOA 资源，可通过封装、抽取等过程形成服务，具体要求见本标准 6 服务实现技术要求； c) SOA 支撑技术和服务是支撑 SOA 应用的基础技术能力及基础技术服务的总称； d) 业务公共服务是一系列面向行业/领域应用的、可复用的、具有一定业务功能的服务，服务之间可以基于 SOA 支撑技术和服务所提供的功能和能力进行交互，并以此实现更丰富的业务逻辑，有关服务交互的技术要求见本标准 7 服务交互技术要求； e) 电力行业应用是面向用户的、基于电力行业“发、输、变、配、用”等各环节以及具体业务领域需求的 IT 系统； f) 用户是使用 SOA 应用的人、系统、设备及其它服务的总称； g) 质量是指 SOA 应用满足用户需求或期望的程度； h) 安全是为保障 SOA 应用安全运行的机制和策略的总称； i) 治理是针对 SOA 应用所制定的管控策略和机制，涵盖 SOA 应用的整个生命周期。 SOA支撑技术和服务SOA资源质量安全治理数据资源服务资源服务描述信息服务应用系统资源电力行业应用IT基础设施业务公共服务服务交互通信用户展现服务身份管理服务授权服务服务注册与发现服务开发服务编制服务编排服务管理图 1 SOA 应用技术参考模型 5.2.2 SOA 应用的支撑技术和服务要求 DL / T 1992 2019 6 5.2.2.1 服务描述能力要求 服务描述能力应满足如下要求： a) 提供标准的信息模型和访问接口来描述服务和资源的相关属性； b) 符合相关服务描述的具体技术标准，具体要求见本标准 6.1 服务描述。 5.2.2.2 服务注册和发现能力要求 服务注册与发现能力应满足如下要求： a) 提供服务注册功能及访问接口，用以对服务和资源进行注册、检索和发现； b) 提供服务新增、变更等消息的主动发布接口，便于使用者能够及时感知和发现服务的变化； c) 符合相关服务注册与发现的具体技术标准，具体要求见本标准 7.2.1 服务注册与发现。 5.2.2.3 服务开发能力要求 服务开发能力应满足如下要求： a) 应提供构建新服务所需的设计、开发、配置、调试、测试及运行的环境； b) 应支持已有应用系统或数据资源的服务化封装； c) 宜提供相关的工具或环境对服务设计遵从度、服务耦合性、服务自治性等进行检测； d) 符合相关服务开发的具体技术标准，具体要求见本标准 6.5 服务开发。 5.2.2.4 服务编制能力要求 服务编制能力应满足如下要求： a) 按逻辑顺序调用一系列服务以形成更大粒度服务； b) 为编制好的服务提供运行时的容器环境； c) 符合相关服务编制的具体技术标准。 5.2.2.5 服务编排能力要求 服务编排能力应满足如下要求： a) 基于若干其他服务，通过服务流程建模、编排的方式，构建满足业务流程的新服务； b) 提供流程执行引擎，为部署的业务流程脚本提供解释、执行、控制和管理等功能； c) 符合相关服务编排的具体技术标准，具体要求见本标准 7.2.2 服务编排。 5.2.2.6 服务管理能力要求 服务管理能力应满足如下要求： a) 提供对服务设计、服务开发、服务测试、服务部署、服务发布、服务使用、服务变更、服务退役等过程的管理措施和流程，实现服务的全生命周期管理，见本标准 5.3 服务生存周期过程； b) 对服务的状态进行实时监控、预警和执行其他相关管理操作； c) 符合相关服务管理的具体技术标准。 5.2.2.7 服务交互通信能力要求 服务交互通信能力应满足如下要求： a) 提供服务的接入、路由、负载均衡、消息转换、传输等功能； b) 具有与服务管理的整合能力； c) 提供服务间交互的机制及质量保障； d) 符合相关服务交互通信的具体技术标准，具体要求见本标准 7.1.4 服务交互通信单元。 5.2.2.8 信息服务要求 DL / T 1992 2019 7 信息服务应满足如下要求： a) 提供信息采集、编目、发布和检索等功能； b) 符合相关信息服务的具体技术标准。 5.2.2.9 展现服务要求 展现服务应满足如下要求： a) 提供一组完整的、支持多渠道人机交互的展现功能； b) 符合相关展现服务的具体技术标准。 5.2.2.10 身份管理服务要求 身份管理服务应满足如下要求： a) 提供一组可扩展的组织、人员、角色、认证等的管理功能； b) 符合相关用户管理服务的具体技术标准。 5.2.2.11 授权服务要求 授权服务应满足如下要求： a) 基于身份管理服务，提供身份鉴别及访问控制功能； b) 符合相关授权服务的具体技术标准。 5.2.2.12 SOA 应用的业务公共服务要求 在实现 SOA 应用系统的过程中， 需要逐步积累形成具有电力行业特征的、 可以支持 SOA 应用开发特性的业务公共服务。业务公共服务应满足下列要求： a) 满足服务的各项要素，并能实现一定的电力行业业务功能； b) 在一定范围内具有较强的复用性； c) 符合电力行业及领域的标准或规范。 5.2.3 SOA 应用质量要求 5.2.3.1 一般性要求 除功能性要求外，SOA 应用还需满足如下的质量要求： a) 可靠性； b) 易用性； c) 效率； d) 可维护性； e) 可移植性； f) 平台独立性。 5.2.3.2 服务质量要求 服务质量应至少满足下列要求： a) 功能正确性； b) 服务粒度合理性； c) 松耦合性； d) 可复用性； e) 可扩展性； f) 互操作性； g) 自治性； DL / T 1992 2019 8 h) 无状态性； i) 事务独立性。 5.3 服务生存周期过程 5.3.1 总述 本节给出了 SOA 应用中服务生存周期过程的要求，并定义了过程的目的和输出，以及完成过程所必需的活动。 服务生存周期过程按分析设计过程、 创建过程、 组装过程、 运维过程 4 个过程组进行描述。本节在 GB/T 324292015 中 5 服务生存周期过程的基础上，增加了服务规划过程、服务使用过程、服务变更过程和服务编排过程，共包括 14 个过程，如图 2 所示： 分析设计过程服务规划过程服务分析过程服务设计过程创建过程服务开发过程服务测试过程服务部署过程服务发布过程组装过程服务发现过程服务组合过程运维过程服务监管过程服务使用过程服务变更过程服务退役过程服务编排过程 图 2 服务生存周期过程 5.3.2 服务分析与设计过程 5.3.2.1 服务规划过程 5.3.2.1.1 目的 服务规划是承接组织的顶层设计和规划，站在全局的角度，面向组织的整体性和前瞻性信息需求，对组织的服务资源所做的总体筹划和优化设计， 形成组织的服务资源库规划， 并以此作为服务设计和开发的主要依据。 5.3.2.1.2 输出 服务规划过程的输出结果为服务资源库规划，包括服务域、服务清单和服务概念设计。 5.3.2.1.3 活动和任务 服务规划过程包括业务分解、应用分解、数据分解、服务识别、服务整理等5个活动。具体要求见本标准6.2服务规划。 DL / T 1992 2019 9 5.3.2.2 服务分析过程 5.3.2.2.1 目的 服务分析是基于SOA应用的总体需求，以服务资源库的服务域和服务清单规划作为参考依据，综合运用多种方法手段，多维度逐步发现、甄别服务的过程。 5.3.2.2.2 输出 服务分析过程的输出结果包括： a) 候选服务列表：包含服务名称、功能描述、服务来源、服务消费者、服务提供者、服务流程信息等服务需求信息； b) 服务需求和业务需求的一致性和可追溯性对应关系； c) 服务需求的正确性和可测试性等分析结果。 5.3.2.2.3 活动和任务 服务分析过程包括目标分析、领域分析、流程分析、数据分析、业务维服务分析、系统维服务分析、服务识别与筛选等7个活动。具体要求见本标准6.3服务分析。 5.3.2.3 服务设计过程 5.3.2.3.1 目的 服务设计是以服务资源库的服务概念设计作为参考依据，对服务分析过程中得到的服务进行分类、定义（规约）、管理等一系列活动。 5.3.2.3.2 输出 服务设计过程的输出结果包括： a) 服务分类； b) 服务接口定义列表； c) 服务接口详细规约； d) 服务实现矩阵； e) 设计评审意见； f) 服务设计和服务需求的一致性和可追溯性对应关系。 5.3.2.3.3 活动和任务 服务设计过程包括服务分类、服务定义、服务接口设计、服务实现方式决策、服务设计评审等 5个活动。具体要求见本标准 6.4 服务设计。 5.3.3 服务创建过程 5.3.3.1 服务开发过程 5.3.3.1.1 目的 服务开发是将已定义的服务接口详细规约通过技术开发手段变成可部署运行的服务的过程。 5.3.3.1.2 输出 服务开发过程的输出结果包括： a) 可部署的服务包； DL / T 1992 2019 10 b) 服务描述文档； c) 对照服务需求的服务验证准则； d) 与服务设计的一致性和可追溯性对应关系。 5.3.3.1.3 活动和任务 依据服务不同的实现方式决策，服务开发方式可分为3种类型，分别为新建功能服务、映射已有功能服务和构造组合服务。对应的服务开发过程包括新建功能服务、映射已有功能服务、新建组合服务等活动。具体要求见本标准6.5服务开发。 5.3.3.2 服务测试过程 5.3.3.2.1 目的 服务测试过程是验证服务开发过程输出的可部署服务包在功能和质量上是否符合服务需求和服务设计要求的过程。 5.3.3.2.2 输出 服务测试过程的输出结果包括： a) 服务测试准则； b) 服务测试结果记录。 5.3.3.2.3 活动和任务 服务测试过程包括服务测试准则制定与评价、服务接口测试、服务集成测试、服务一致性测试、测试结果评价等4个活动。具体要求见本标准6.6服务测试。 5.3.3.3 服务部署过程 5.3.3.3.1 目的 服务部署过程是将符合服务需求的可部署服务包安装到目标运行环境中的过程。 5.3.3.3.2 输出 服务部署过程的输出结果包括： a) 服务部署策略； b) 运行态的服务； c) 更新的服务描述信息。 5.3.3.3.3 活动和任务 服务部署过程包括服务部署策略制定、原子服务部署、组合服务部署、服务部署确认等4个活动。具体要求见GB/T 324292015中的5.3.3服务部署过程。 5.3.3.4 服务发布过程 5.3.3.4.1 目的 服务发布过程是将已部署的服务通过在服务注册中心注册等方式对外公开的过程。 5.3.3.4.2 输出 服务发布过程的输出结果包括： a) 与服务注册中心的服务发布合约； DL / T 1992 2019 11 b) 符合服务发布的服务描述文档； c) 服务对外公开发布。 5.3.3.4.3 活动和任务 服务发布过程包括服务发布合约制定、服务发布声明制定和评价、服务发布等3个活动。具体要求见GB/T 324292015中5.3.4服务发布过程。 5.3.4 服务组装过程 5.3.4.1 服务发现过程 5.3.4.1.1 目的 服务发现是指服务使用者依据服务描述， 查找并获取可以满足特定需求的服务的过程。 它涉及到功能和服务质量指标及匹配。服务发现一般通过服务注册中心来完成。 5.3.4.1.2 输出 服务发现过程的输出结果包括： a) 服务匹配模板； b) 被发现服务的列表及描述文档； c) 服务评估结果记录。 5.3.4.1.3 活动和任务 服务发现过程包括服务匹配模板制定、服务搜索、服务评估与选择等3个活动。具体要求见本标准7.2.1.3服务发现。 5.3.4.2 服务组合过程 5.3.4.2.1 目的 服务组合过程是将一组服务按照一定的规则进行组合封装，使它们共同完成一个特定的功能。 5.3.4.2.2 输出 服务组合过程的输出结果包括： a) 服务组合模型； b) 模型评价结果； c) 组合服务。 5.3.4.2.3 活动和任务 服务组合过程包括服务组合模型设计、模型评价、服务封装等3个活动。 a) 服务组合模型设计：依据功能要求，确定服务的组合构造，并据此设计实现服务组合； b) 模型评价：对服务组合模型进行评价，并记录评价结果。同时对上述模型进行必要的修正； c) 服务封装：对已有的服务按照组合模型设计进行组合，封装成为一个新的、更大粒度的服务。 5.3.4.3 服务编排过程 5.3.4.3.1 目的 指将一组服务按照一定的规则进行排序组合，使它们共同完成一个特定的任务或业务流程。 5.3.4.3.2 输出 DL / T 1992 2019 12 服务编排过程的输出结果包括： a) 服务编排模型； b) 模型评价结果； c) 服务绑定。 5.3.4.3.3 活动和任务 服务编排过程包括服务编排模型设计、模型评价、服务发现、服务创建、服务绑定等5个活动。具体要求见本标准7.2.2服务编排。 5.3.5 服务运维过程 5.3.5.1 服务使用过程 5.3.5.1.1 目的 服务使用是对服务消费者提出的服务使用申请进行审核， 并对服务进行配置， 以使其具备使用条件的过程。 5.3.5.1.2 输出 服务使用过程的输出结果包括： a) 服务使用申请； b) 服务使用审核意见； c) 服务配置清单。 5.3.5.1.3 活动和任务 服务使用过程包括服务使用申请、申请审核、服务配置等3个活动。具体要求见本标准7.2.3服务访问。 5.3.5.2 服务监管过程 5.3.5.2.1 目的 服务监管过程是依据SOA应用确定的决策和机制，对运行时的服务和业务流程进行监控和管理，以保证服务正常运行的一系列过程。 5.3.5.2.2 输出 服务监管过程的输出结果包括： a) 服务测量信息； b) 服务管理记录； c) 服务质量报告。 5.3.5.2.3 活动和任务 服务监管过程包括服务监视、服务测量信息收集、服务异常管理、服务配置、服务更新、服务退役等活动。 a) 服务监视：依据服务需求中确定的策略，对服务的运行情况进行实时监视，并在异常情况下进行告警； b) 服务测量信息收集：对服务的各类质量指标进行测量，并记录测量结果； c) 服务异常管理：对服务运行过程中产生的异常进行记录、跟踪，并形成统计分析报告； d) 服务配置： 在环境条件发生改变或服务需求变更等情况下， 对服务部署和运行的参数进行重配； DL / T 1992 2019 13 e) 服务更新：在服务需求变更后，将服务更新为新的版本。服务更新应保持更新前后系统的一致性； f) 服务退役见本标准 5.3.5.4 服务退役过程。 5.3.5.3 服务变更过程 5.3.5.3.1 目的 服务变更过程是在服务运行维护过程中， 由于需求或运行环境发生变化导致在用服务无法满足业务要求而需要进行修改、优化或功能新增的一系列过程。 5.3.5.3.2 输出 服务变更过程的输出结果包括： a) 服务变更申请； b) 服务变更方案； c) 服务变更影响分析报告； d) 服务变更审核意见。 5.3.5.3.3 活动和任务 服务变更过程包括变更申请、变更分析、影响分析、可行性审核等4个活动。 a) 变更申请：提出服务变更申请，包括变更原因、变更内容等； b) 变更分析：对变更需求进行分析，确定变更方案，针对服务变更方式（服务改造、现有服务组合、新增服务）进行决策； c) 影响分析：根据服务使用情况及变更方案，分析评估服务变更实施的影响范围和潜在风险，形成服务变更影响分析报告。 d) 可行性审核： 相关干系方根据变更影响分析报告对服务变更方案的可行性进行审核， 并形成审核意见。 5.3.5.4 服务退役过程 5.3.5.4.1 目的 服务退役过程是服务不再使用时，将服务从目标运行环境中卸载的过程。 5.3.5.4.2 输出 服务退役过程的输出结果包括： a) 服务退役计划； b) 服务退役申请； c) 服务退役审核意见； d) 服务退役公告； e) 服务从目标运行环境中卸载。 5.3.5.4.3 活动和任务 服务退役过程包括服务退役计划制定、服务退役申请、服务退役审核、服务退役公布、服务卸载等5个活动。 a) 服务退役计划制定：制定服务退役的过程和策略，可包括后续服务技术支持的安排、服务及文档的规定、后续遗留问题的职责划分、向新服务迁移的策略等； b) 服务退役申请：制定退役计划后，提交服务退役申请； DL / T 1992 2019 14 c) 服务退役审核：相关干系方对服务退役申请进行审核，并形成审核意见； d) 服务退役公布：公布服务退役计划。可通过公开信息发布渠道进行服务退役公告，也可主动通知服务消费者，向其公布退役计划； e) 服务卸载： 将服务从目标运行环境中卸载。 对于服务退役和新服务部署重叠的情况， 应保证新、旧服务更替的平滑过渡。同时应根据服务需求，确保服务相关数据和记录及可访问性。 5.4 SOA 成熟度模型 5.4.1 总述 SOA 成熟度模型如图 3 所示， 提供了一种能够帮助正确地评估 SOA 在组织中的适用性和收益的框架。建立 SOA 成熟度模型的目标是对 SOA 规划和实施价值进行测量与评估，并且根据 SOA 成熟度模型设定 SOA 信息化建设目标。SOA 成熟度模型包括“成熟度级别” 、 “评估维度”及“评估方法”三个要素： a) 成熟度级别：SOA 成熟度模型分为七个级别，每个成熟度级别反映了组织或信息化项目在实施或应用 SOA 的一个抽象状态。 每个成熟度级别基于一个或多个成熟度指标建立， 对应一系列成熟度属性； b) 评估维度： 一个组织或信息化项目的 SOA 成熟度级别宜基于本标准中的系列维度进行评估。 评估维度是有效评价 SOA 成熟度级别的必要指标； c) 评估方法： 使用 SOA 成熟度模型及评估方法可评估组织或信息化项目的当前 SOA 实施、 应用的成熟度， 确定目标成熟度级别及相关能力要求， 以及为组织或信息化项目提供从当前成熟度级别到目标成熟度级别的提升指南。 图 3 SOA 成熟度模型 5.4.2 成熟度级别 5.4.2.1 级别 1：竖井 a) 企业的各部门独立开发自己的软件，没有进行数据、流程、标准或者技术的集成； b) 严重制约了部门之间的信息共享和业务协同，在没有较强人工干预的情况下，信息化系统之DL / T 1992 2019 15 间就不能进行集成，数据重复存贮和应用的情况比较突出。 5.4.2.2 级别 2：集成 a) 采用技术手段在竖井之间进行连接，进行数据和功能的集成； b) 构建跨部门应用的信息化系统成为可能，但是并未形成通用性的数据和技术标准，因此实现两个系统之间的集成，需要在系统之间进行较复杂的数据、协议和功能的转换，开发一个新的业务流程难度仍然很大。 5.4.2.3 级别 3：组件化 a) 信息化系统可拆分为组件，它们可以配置成一个新的功能； b) 将业务功能到组件的分析过程存在困难； c) 虽然组件通过定义的接口进行交互，但是它们仍旧不是松耦合的，这也就限制了不同系统间的敏捷性和可交互性； d) 很难开发跨组织的业务流程。 5.4.2.4 级别 4：服务化 a) 能够基于松散耦合的业务流程来构建组合应用； b) 服务基于开放标准，与底层应用技术无关； c) IT 基础设施支持多种协议、安全机制、数据转换和服务管理； d) 服务可以在企业内跨部门使用，符合 SLA； e) 业务功能经过详细的分析，并且拆分为服务，服务可以在业务级别进行交互； f) 通过规范的语言明确定义每个服务的功能和内容； g) 这个阶段，服务组合仍然靠开发人员定制代码来实现，限制了新业务流程的开发。 5.4.2.5 级别 5：组合服务 a) 通过服务组合语言定义组合服务，实现对独立的服务的控制和协同； b) 组合服务包括静态的、流畅的、基于活动的服务，不需要定制代码就可以将服务组合成为一个业务流程，开发人员可以在业务分析师的指导下敏捷的进行组合服务的设计和开发。 5.4.2.6 级别 6：虚拟化服务 a) 通过虚拟化的间接方式提供服务； b) 基础设施进行虚拟调用到实际物理服务调用的映射； c) 虚拟服务让组合服务变得更加松耦合。 5.4.2.7 级别 7：动态可配置服务 这个级别之前，业务流程可以通过开发人员在设计期通过合适的工具进行开发。而这个级别下，组合服务和流程可以动态地创建和执行。 5.4.3 评估维度 5.4.3.1 业务视图 业务视图维度集中在业务体系结构以及 IT 策略， 可表达 IT 能力的价值如何跨越组织分配， 以及 IT能力如何支持业务的灵活性、敏捷和 SLA。 5.4.3.2 治理与组织 治理与组织维度集中在组织或信息化项目所涉及组织的结构、自身的设计，以及 SOA 治理的有效DL / T 1992 2019 16 性评估。组织方面包括组织的结构、关系、角色和对采用面向服务策略的授权。治理与正式管理流程相关，以保持 IT 活动、服务能力以及 SOA 应用与业务需求一致。治理可指导其它成熟度维度，包括管理如何构建和费用如何分配。 5.4.3.3 方法 方法维度集中在组织或信息化项目在 IT、业务转换方面的方法和过程，以及围绕软件和系统开发生存周期的成熟度，涉及需求管理、技术评估、项目管理、质量保证过程、设计方法论和技术、设计解决方案工具的使用。 5.4.3.4 应用 应用维度集中在应用风格，应用的结构，应用中功能的可分解性、可复用性、灵活性、可靠性、可扩展性，应用的可理解性，以及在不同业务部门的 SOA 应用实践和模式的统一性。 5.4.3.5 架构 架构维度集中在企业的整体信息化实现架构，分为单一架构、基于层次的架构、基于组件的架构、SOA 出现、SOA、支持网格化的 SOA、动态可配置的架构。 5.4.3.6 信息 信息维度集中在信息如何被构建、信息如何被建模、访问组织数据的方法、数据从功能方面访问的抽象性、数据特征、数据转换能力、服务和流程定义、处理标识符、安全证书、知识管理、业务信息模型和内容管理。 5.4.3.7 基础设施和管理 基础设施和管理维度集中在组织的基础设施能力、服务管理、IT 操作、IT 管理和 IT 经营、服务级别协定如何达到、监控如何执行以及所提供的集成平台类型。 5.4.4 评估方法 5.4.4.1 识别业务目标、范围和问题 组织和信息化项目负责人提出相关的业务目标、 涉及的范围以及业务、 组织和 IT 需要在哪里改进，评估者基于 SOA 成熟度模型中的维度和域收集相关信息，重点是策略文档、用户需求和目标、EA、关键问题列表。 5.4.4.2 定义 SOA 成熟度模型 基于所识别的业务目标、 范围和问题， 评估者在组织或信息化项目人员的协助下确定是否需要对本标准提出的 SOA 成熟度模型进行裁剪或扩展，所需裁剪或扩展的维度、成熟度指标、属性、映射关系或/和权重，并明确定义出评估所需的 SOA 成熟度模型。 5.4.4.3 确定当前 SOA 成熟度级别 评估者使用所确定的 SOA 成熟度模型对组织和信息化项目关键人员进行调研，主要依据模型中的评估问题来进行。根据调研所获得的信息，评估者对照 SOA 成熟度模型确定组织或信息化项目当前的SOA 成熟度级别。 5.4.4.4 确定目标 SOA 成熟度级别 评估者对组织或信息化项目关键人员从未来目标、业务需求、EA、业务服务和基础设施战略进行调研，调研可基于 SOA 成熟度模型的维度和域。根据调研所获得的信息，评估者对照 SOA 成熟度模型DL / T 1992 2019 17 来确定目标 SOA 成熟度级别及状态。 5.4.4.5 确定迁移建议、形成评估报告 评估者根据前面步骤的结果， 确定当前和未来成熟度级别的差异， 提出组织或信息化项目从当前状态迁移到目标状态的路线图和建议，并通过规范的文档格式编写完成评估报告。 6 服务实现技术要求 6.1 服务描述 6.1.1 服务描述元素分类 本节在 GB/T 32419.12016 给出的“信息技术 SOA 技术实现规范第 1 部分：服务描述”基础上，对服务描述元素进行了细分，分为 5 种类型： a) 基本描述:指服务的基本属性，应包含服务标识符、服务名称、服务基本说明等属性，可包含服务版本号、服务提供者信息、服务使用者信息等属性； b) 功能描述:指服务的外部和内部功能特性，应包含外部功能、消息、实现特性，也宜包含内部特性，具体使用时可对服务的功能描述进行扩展； c) 非功能描述:指服务的服务质量属性，可包含功能正确性、服务粒度适合性、松耦合性、可复用性、可扩展性、互操作性、可用性、可管理性、自治性、无状态性、事务独立性等关键质量属性； d) 业务特征描述:指从业务视角描述服务所属电力行业的特征，应包含业务领域、业务流程和业务场景等属性； e) 统计特征描述:指服务运行过程中对服务各种运行属性的统计特性，可包含服务的访问次数、访问频率、最高访问量、成功次数、访问用户分布、活跃度、响应时间、数据吞吐量等属性。 6.1.2 基本描述 6.1.2.1 服务标识符 在给定的命名空间中唯一的标识，用以确定一个服务。服务标识符应包含行业分类代码、业务域代码、服务提供者代码、服务流水号等。 6.1.2.2 服务名称 a) 服务名称应包含一定的意义，能够从服务名称中了解服务的作用或者功能； b) 服务名称应包含中文名和英文名： 1) 中文名应由数字、中文组合，采用“服务原语+服务业务对象”的结构； 2) 英文名应由数字、字母组合，首字母大写，采用“服务原语+服务业务对象”的结构。 c) 服务原语应确定服务的基本行为特征，服务的行为应限定在固定的、自动的、与用户无关的功能逻辑的语义范围内，例如：查询、创建、删除等，参见附录A； d) 服务的业务对象是在业务过程产生的数据集合，是对客观实体或信息的一种映射。业务对象应有明确的业务含义和特定目标，例如停电计划、审批意见等。 6.1.2.3 服务基本说明 对服务进行描述的一段文本说明，应包含服务所有功能，以及服务的应用场景和能力。 6.1.2.4 服务版本号 DL / T 1992 2019 18 服务版本的标识号，格式为“x.y.z_yyyymmdd”，其中x为主版本号，y为次版本号，z为修订版本号，yyyymmdd为服务发布时间（年月日）。 6.1.2.5 服务提供者信息 服务提供者的详细信息，宜包含提供者名称、提供者联系信息等。 6.1.2.6 服务使用者信息 服务使用者的详细信息，宜包含使用者名称、使用者联系信息等。 6.1.3 功能描述 6.1.3.1 外部功能 6.1.3.1.1 服务功能名称 服务对外提供的功能的名称，1个服务对外可提供多个功能(接口)。 6.1.3.1.2 服务功能说明 对服务功能的一段文本说明，应包含服务的应用场景和能力。 6.1.3.1.3 输入参数 一个服务功能被调用时，对外可接受的参数、类型、格式、说明、长度等。输入参数可以是0个、1个，或者多个。输入参数的类型应符合服务实现技术相关的类型定义，如Web服务的输入参数应符合XML Schema 定义的类型。 6.1.3.1.4 输出参数 服务返回给服务使用者时，返回的参数、类型、格式、说明、长度等，输出参数可以是0个、1个，或者多个。输出参数的类型应符合服务实现技术相关的类型定义，如Web服务的输入参数应符合XML Schema 定义的类型。 6.1.3.1.5 前置条件 服务被调用之前必须满足的前提条件。 6.1.3.1.6 后置结果 服务被调用之后产生的结果。 6.1.3.1.7 故障 服务执行过程中可能产生并返回给服务使用者的故障， 故障信息应包含故障编码、 故障名称及描述。 6.1.3.2 消息 6.1.3.2.1 消息结构 服务使用者和服务提供者之间传递消息的结构，需独立于特定的编程语言和运行平台。 6.1.3.2.2 消息交换模式 指服务使用者和服务提供者之间传递消息的模式，具体要求见7.1.5服务交互模式。 DL / T 1992 2019 19 6.1.3.3 内部特性 6.1.3.3.1 内部结构 对于组合服务而言，其组成服务之间的关联关系。 6.1.3.3.2 内部过程 对于组合服务而言，其组成服务之间的编排、组合和调用过程等。 6.1.3.4 实现特性 6.1.3.4.1 服务访问地址 服务提供者暴露给服务使用者的对外入口。服务使用者可通过服务访问地址确定服务的网络位置。 6.1.3.4.2 绑定消息协议 服务提供者的特定端口类型的具体协议， 以及服务提供者与服务使用者之间交换的数据格式规范的绑定。 6.1.3.4.3 绑定传输协议 服务提供者与服务使用者之间传输消息的底层通讯协议。 6.1.4 非功能描述 6.1.4.1 服务粒度适合性 服务提供功能的层次与服务使用者功能层次间的相近性。 6.1.4.2 松耦合性 服务与服务使用者之间的关联强度，通常表现为技术独立性、位置透明性等。 6.1.4.3 可复用性 服务被组合使用的难易程度。 6.1.4.4 可扩展性 服务运行时，在资源变化情况下其服务能力的随需可变能力。 6