GB/T 32430-2015 信息技术 SOA 应用的服务分析与设计

　　ICS 35. 100. 05 L 79

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 32430—2015

　　信息技术 SOA应用的服务分析与设计

　　Information technology—Serviceanalysisanddesign ofSOA application

　　2015-12-31发布 2017-01-01实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　发

　　布

　　GB/T 32430—2015

　　GB/T 32430—2015

　　前 言

　　本标准按照 GB/T 1. 1—2009给出的规则起草 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别这些专利的责任 。

　　本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归 口 。

　　本标准起草单位 : 中国人民解放军后勤学院 、中国电子技术标准化研究院 、北京航空航天大学 、山东浪潮齐鲁软件产业股份有限公司 、北京东方通科技股份有限公司 、山东中创软件商用中间件股份有限公司 、上海宝信软件股份有限公司 。

　　本标准主要起草人 :杨云 、刘志 、王志东 、张雷 、王力猛 、任杰 、袁媛 、王潮阳 、赵永望 、贾德星 、徐宝新 、马亮 、周明 。

　　引 言

　　本标准的制定旨在将 SOA应用的服务分析与设计过程的各环节进行规范化 , 为用户在组织实施基于 SOA 的信息化项目中发现 、标识 、划分 、抽取服务提供参考方法 , 为技术开发人员开展服务分类 、定义 、建模 、设计等提供指导和依据 , 同时 ,为用户和技术人员合作开展服务分析和设计建立统一的沟通桥梁 。

　　信息技术 SOA应用的服务分析与设计

　　1 范围

　　本标准规定了 SOA应用的服务分析与设计的过程模型 、服务分析要求及服务设计要求 。

　　本标准适用于 SOA项目实施过程中的服务分析与设计 ,可为用户单位及系统集成商 、独立软件提供商 、咨询厂商 、服务提供商等承建单位规划和实施基于 SOA 的信息化项目提供基础技术指导 。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的 。凡是注 日期的引用文件 ,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件 ,其最新版本(包括所有的修改单)适用于本文件 。

　　GB/T 29262 信息技术 面向服务的体系结构(SOA) 术语

　　GB/T 32428—2015 信息技术 SOA服务质量模型及测评规范

　　3 术语和定义

　　GB/T 29262中界定的术语和定义适用于本文件 。

　　4 总则

　　SOA应用的服务分析与设计应符合如下要求 :

　　a) 明确 目标 。服务分析与设计最终都是为了实现项 目 目标 ,所以服务的发现 、甄别及实现应围绕这一中心任务展开 ;

　　b) 螺旋迭代 。 围绕服务的分析与设计迭代展开 ,应注重每轮迭代产生的服务和价值 ;

　　c) 过程管理 。服务分析与设计过程中的每个阶段都有明确的工作内容和验收标准 ;

　　d) 软件建模 。运用服务建模的方法手段 ,促进用户和技术人员的沟通和交流 。

　　5 服务分析与设计过程模型

　　服务分析与设计过程模型由 8个子过程组成 ,依次为 : 目标建模 、职责建模 、流程建模 、数据建模 、业务维服务分析 、系统维服务分析 、服务识别与筛选 、服务设计 ,如图 1所示 。其中前 7个子过程均为服务分析过程 、第 8个子过程为服务设计过程 。

　　图 1 SOA应用的服务分析与设计过程模型

　　服务分析与设计过程模型的主要原理及应用如下 :

　　a) 目标建模 。任何信息系统项目建设的出发点一定是解决业务中存在的问题 , 以期达到建设目标 ,所以应将分析业务问题 、确定项 目 目标作为服务分析的起点 。 由于项 目 目标常由组织的整体信息化建设目标决定 ,所以 SOA项目建设时 ,需将项目建设目标纳入整个信息化顶层设计的背景中考虑 ,确保准确到位 ;

　　b) 职责 、流程 、数据建模 。 围绕与达成项 目 目标密切相关的关键业务场景 ,通过职责建模了解组织结构 、清晰岗位职责 ,通过流程建模区分业务场景 、梳理业务流程 ,通过数据建模收集单证报表 、获取数据需求 ;

　　c) 业务维服务分析 。在汇总和分析项 目 目标 、业务建模 、流程建模 、数据建模的基础上 ,分别描述当前业务 、探讨未来业务 。分析重点在 “业务 ”层面 , 主要关注业务当前的组织结构情况 、流程执行情况 、单证传输情况 ,并探讨未来业务模式和所需的业务服务集 。 为保证分析效果 ,讨论可一次围绕一个特定业务场景展开 ,应提前草拟好业务流程图和业务组件图 ,并邀请高层管理人员参加 。对于短期内无法决策的问题 ,应标识出几种可能的变化情况 , 以便为后续的服务设计提供应考虑适应的变化点 ;

　　d) 系统维服务分析 。 已有系统为组织的重要信息化资源 ,通常包含组织的核心业务和数据 。通过梳理当前已有系统的情况 ,可从系统的视角补充查找和分析服务 ;

　　e) 服务识别与筛选 。业务流程 、功能及数据中部分内容不适合通过服务中去实现 。本阶段重点是围绕项 目 目标 ,在考虑系统维服务分析结果的约束下 ,筛选业务维服务分析结果 ,协商确定当前阶段待开发的服 务 集 。 最 终 形 成 服 务 集 是 一 个 迭 代 的 过 程 , 可 根 据 项 目 情 况 不 断 滚 动扩展 ;

　　f) 服务设计 。本阶段主要是分类 、管理识别出的服务集 ,逐个定义服务 ,形成服务规格说明(包括服务接口及服务接口详细规约)及服务实现矩阵 。本阶段工作成果可为具体的服务开发提供完备的文档规格说明 。

　　6 服务分析要求

　　6. 1 目标建模

　　目标建模宜从分析业务问题 、明确项 目 目标的角度出发 ,识别与项 目 目标相关的职责 、流程及数据 ,为下一步职责 、流程及数据建模锁定分析范围 。 主要工作宜包括以下内容 :

　　a) 分析业务问题 ;

　　b) 明确项 目 目标 ;

　　c) 识别与项目相关的职责 、流程及数据 ;

　　d) 分解项目子目标 ,建立职责 、流程及数据与其的对应关系 。

　　6.2 职责建模

　　职责建模宜从了解组织结构 ,清晰岗位职责的业务维度出发 , 了解当前业务部门组织结构和职责 ,探讨未来业务部门(或业务领域)划分和职责界定 ,并标识当前或未来业务中会重点关注的热点职责 ,形成候选服务 。 主要工作宜包括以下内容 ,分析结果如图 2所示 :

　　a) 了解当前组织结构和职责 ;

　　b) 探讨未来可能的组织结构和职责 ;

　　c) 协商明确近期可行的组织结构和职责 ;

　　d) 标识重点职责 ;

　　e) 发现候选服务 。

　　图 2 SOA职责建模示意图

　　6.3 流程建模

　　流程建模宜从区分业务场景 、梳理业务流程的角度出发 , 围绕与项 目 目标相关的关键业务场景 ,逐个场景地分析 、探讨当前流程和未来优化流程 ,细化流程中的操作要求 ,形成候选服务 。如图 3所示 ,主要工作宜包括以下内容 :

　　a) 区分与项 目 目标相关的关键业务场景 ;

　　b) 逐个场景地梳理近期可行的业务流程 ;

　　c) 结合职责建模的职责分析结果 ,细化业务操作 ;

　　d) 发现候选服务 。

　　图 3 SOA流程建模过程示意图

　　6.4 数据建模

　　数据建模宜从收集单证报表 ,获取数据需求的业务维度出发 , 围绕与项 目 目标相关的关键业务场景 ,逐个场景地收集相关单证报表资料 ,获取部门 、岗位之间的数据需求 ,形成候选服务 。 主要工作宜包括以下内容 :

　　a) 区分与项 目 目标相关的关键业务场景 ;

　　b) 逐个场景地收集相关单证 、报表资料 ;

　　c) 结合职责建模的职责分析结果 ,协商明确近期可行的数据需求 ;

　　d) 发现候选服务 。

　　6.5 业务维服务分析

　　业务维服务分析宜围绕与项 目 目标相关的关键业务场景 ,汇总领域 、流程 、数据建模的结果 ,逐个场景地形成业务流程模型和业务组件模型 ,最终形成候选服务集 。 主要工作宜包括以下内容 :

　　a) 重点分析项 目 目标相关的关键业务场景 ;

　　b) 逐个场景地协商形成近期可行的业务流程模型 ;

　　c) 汇总形成近期可行的业务组件模型 ;

　　d) 形成业务维候选服务集 。

　　6.6 系统维服务分析

　　系统维服务分析宜从系统的维度出发 ,分析识别已有系统 、以及系统之间的访问接口和功能列表 ,发现候选服务的过程 。 主要工作宜包括以下内容 :

　　a) 分析梳理已有系统及其技术架构风格 ;

　　b) 识别已有系统之间相互访问接 口 ;

　　c) 识别并抽取已有系统已对外提供的接 口 ;

　　d) 对照业务维候选服务与系统维候选服务的映射关系 ;

　　e) 发现候选服务 。

　　6.7 服务筛选

　　服务筛选宜从候选服务中 ,运用校验 、评估等方法从候选服务中逐步筛选并得到待暴露(实现)的服务的过程 。其主要工作内容包括 : 确定服务评估的指标 、对服务进行打分评估并形成候选服务集 。 如图 4所示 。

　　图 4 服务评估示意图

　　常见服务评估指标如下 :

　　a) 范围(衡量一个服务在企业中潜在的适用范围) ;

　　b) 可复用性(衡量一个服务潜在的可复用水平) ;

　　c) 可扩展性(衡量一个服务可扩展的能力水平) ;

　　d) 服务粒度适合性(衡量一个服务对于企业制定的目标的适合程度) ;

　　e) 可管理性(衡量一个服务的可管理水平) ;

　　f) 敏捷度(衡量一个服务适应变化的能力水平) ;

　　g) 项目影响(衡量为了实现共享服务对当前一些开发项目的影响) ;

　　h) 可行性(衡量为了实现共享服务已具备的条件以及一些可能的困难和风险) 。

　　指标 b) 、c) 、d) 、e)的具体评价方法参见 GB/T 32428—2015。

　　基于 6. 1~ 6. 6所描述的服务分析方法 ,可形成服务分析的工作产品为候选服务列表 ,其模板参见A. 1。候选服务列表宜包括如下元素 :

　　a) 服务名称 ;

　　b) 服务功能描述 ;

　　c) 服务来源 ;

　　d) 服务使用者 ;

　　e) 服务提供者 ;

　　f) 所属流程信息 。

　　7 服务设计要求

　　7. 1 综述

　　服务设计时宜对服 务 分 析 过 程 中 得 到 的 服 务 进 行 分 类 、定 义 、接 口 设 计 、实 现 方 式 决 策 , 如 图 5所示 。

　　图 5 服务设计要素示意图

　　7.2 服务分类

　　为了有助于服务组合和分层 ,对不同服务实施不同的管控 ,并为逻辑设计提供依据 ,从而提高服务可管理性 ,宜按照服务的不同属性进行分层抽象划分 、提取 。服务分类示意如图 6所示 。

　　图 6 服务分类示意图

　　各类服务特性如下 :

　　a) 流程服务 ,根据业务需求编排自动化服务和人工服务 ;

　　b) 任务服务 ,通常由实体服务 、功能服务和业务规则组合而成 ,处理面向业务的特定功能 , 重用性低 ;

　　c) 实体服务 ,提供对企业业务对象的相关操作 ,屏蔽了后台数据来源的多样性和复杂性 ,独立于流程和应用 ,重用性高 ;

　　d) 功能服务 ,提供基础的技术功能 ,提供细颗粒度的处理 ,重用性很高 ;

　　e) 接口服务 ,通过服务封装了已有系统接 口 ;

　　f) 信息资源服务 , 由已有系统提供并已发布的服务 。

　　7.3 服务定义

　　服务定义流程如图 7所示 。

　　图 7 服务定义示意图

　　服务定义的主要工作宜包括以下内容 :

　　a) 确定服务边界 ,宜主要考虑以下影响因素 :

　　1) 不同的需求范围 ;

　　2) 不同的安全策略 ;

　　3) 消息交换模式 ;

　　4) 服务质量要求 。

　　b) 定义服务接口过程 ,宜主要考虑以下影响因素 :

　　1) 服务功能 ;

　　2) 操作约束 ;

　　3) 安全需求 ;

　　4) 能力需求 ;

　　5) 非功能性需求 。

　　c) 确定服务接口内容 , 即服务名称 、消息格式 、服务间层次 、关联关系等 ,宜包括以下元素 :

　　1) 服务名称 ;

　　2) 服务调用方式 ;

　　3) 依赖的服务 ;

　　4) 响应时间 ;

　　5) 服务安全要求 ;

　　6) 允许调用的角色 ;

　　7) 服务操作 ;

　　8) 消息格式 。

　　d) 工作产品的模版参见 A. 2。

　　7.4 服务接口设计

　　服务接口设计的主要工作宜包括以下内容 :

　　a) 定义服务接 口 ;

　　b) 确定服务的调用方式 ;

　　c) 确定覆盖功能与非功能需求 ;

　　d) 工作产品为服务接口详细规约 ,模版参见 A. 3。服务接口设计的流程如图 8所示 。

　　图 8 服务接口设计示意图

　　7.5 服务实现方式决策

　　服务实现方式决策的主要工作宜包括以下内容 :

　　a) 确定服务质量要求 ;

　　b) 确定业务服务在技术上的实现方式 ;

　　c) 工作产品为服务实现矩阵 ,模板参见 A. 4。

　　附 录 A (资料性附录)成果模板示例

　　A. 1 候选服务列表

　　候选服务列表见表 A. 1。

　　表 A. 1 候选服务列表

　　A.2 服务接口列表

　　服务接口列表见表 A. 2。

　　表 A.2 服务接口列表

　　A.3 服务接口详细规约

　　服务接口详细规约见表 A. 3。

　　表 A.3 服务接口详细规约

　　A.4 服务实现矩阵

　　服务实现矩阵见表 A. 4。

　　表 A.4 服务实现矩阵