GB/T32430-2015

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

Informationtechnology—ServiceanalysisanddesignofSOAapplication

本文分享国家标准信息技术SOA应用的服务分析与设计的全文阅读和高清PDF的下载,信息技术SOA应用的服务分析与设计的编号:GB/T32430-2015。信息技术SOA应用的服务分析与设计共有15页,发布于2017-01-01
  • 中国标准分类号(CCS)L79
  • 国际标准分类号(ICS)35.100.05
  • 实施日期2017-01-01
  • 文件格式PDF
  • 文本页数15页
  • 文件大小431.56KB

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


国家标准 GB/T324302015 SOA应用的服务分析与设计 信息技术 nformationtechnology一SeieeamalysisanmddesignofsoAapplieaton 2015-12-31发布 2017-01-01实施 中毕人民共和国国家质量监督检验检疫总局 发布 中 国国家标准化管厘委员会国家标准
GB/T32430一2015 目 次 前言 引言 范围 规范性引用文件 术语和定义 总则 服务分析与设计过程模型 服务分析要求 6.1目标建模 6.2职责建模 6.3流程建模 6.4数据建模 6.5业务维服务分析 6.6系统维服务分析 6了服务简选 服务设计要求 7.1综述 7.2服务分类 7.3服务定义 7.4服务接口设计 7.5服务实现方式决策 附录A(资料性附录)成果模板示例
GB/T32430一2015 前 言 本标准按照GB/T1.1一2009给出的规则起草 请注意本文件的某些内容可能涉及专利 本文件的发布机构不承担识别这些专利的责任 本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口 本标准起草单位;人民解放军后勤学院、电子技术标准化研究院、北京航空航天大学,山东 浪潮齐鲁软件产业股份有限公司、北京东方通科技股份有限公司、山东中创软件商用中间件股份有限公 司、上海宝信软件股份有限公司 本标准主要起草人;杨云、,刘志、王志东,张雷,王力猛、任杰,袁媛、王潮阳,赵永望,贾德星、徐宝新、 马亮、周明
GB/T32430一2015 引 言 本标准的制定旨在将sOA应用的服务分析与设计过程的各环节进行规范化,为用户在组织实施 基于sOA的信息化项目中发现、标识、划分、抽取服务提供参考方法,为技术开发人员开展服务分类、 定义,建模,设计等提供指导和依据,同时,为用户和技术人员合作开展服务分析和设计建立统一的沟通 桥梁 I
GB/T32430一2015 信息技术SoA应用的服务分析与设计 范围 本标准规定了soA应用的服务分析与设计的过程模型、服务分析要求及服务设计要求 本标准适用于sOA项目实施过程中的服务分析与设计,可为用户单位及系统集成商、独立软件提 供商、咨询厂商、服务提供商等承建单位规划和实施基于sOA的信息化项目提供基础技术指导 规范性引用文件 下列文件对于本文件的应用是必不可少的 凡是注日期的引用文件,仅注日期的版本适用于本文 件 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 GB/T29262信息技术面向服务的体系结构(SOA术语 GB/T32428一2015信息技术SOA服务质量模型及测评规范 术语和定义 GB/T29262中界定的术语和定义适用于本文件 总则 sOA应用的服务分析与设计应符合如下要求: 明确目标 服务分析与设计最终都是为了实现项目目标,所以服务的发现、甄别及实现应围绕 a 这一中心任务展开; b 螺旋迭代 围绕服务的分析与设计迭代展开,应注重每轮迭代产生的服务和价值; 过程管理 服务分析与设计过程中的每个阶段都有明确的工作内容和验收标准 c d 软件建模 运用服务建模的方法手段,促进用户和技术人员的沟通和交流 服务分析与设计过程模型 服务分析与设计过程模型由8个子过程组成.依次为目标建模、职责建模,流程建模、数据建模,业 务维服务分析,系统维服务分析、服务识别与筛选、服务设计,如图1所示 其中前7个子过程均为服务 分析过程.第8个子过程为服务设计过程
GB/T32430一2015 职责建模 了解组织结构 清渐岗取责 流程建校 标建 业务维服务分析 区分业务场景梳 分析业务问题 描述当前业务 逐个场景迭代 确定项目标 理业务流程 探讨未来业务 服务识别与师选 服务没计 数据建模 围绕项目目标 服务分类与定义 筛选识别服务 形成规格说明 收集单证报表 获取数据需求 系统维服务分析 分析已有系统 明确限制条件 图1soA应用的服务分析与设计过程模型 服务分析与设计过程模型的主要原理及应用如下 目标建模 任何信息系统项目建设的出发点一定是解决业务中存在的问题,以期达到建设目 标,所以应将分析业务问题、确定项目目标作为服务分析的起点 由于项目目标常由组织的整 体信息化建设目标决定,所以sO)A项目建设时,需将项目建设目标纳人整个信息化顶层设计 的背景中考虑,确保准确到位; b 职责、流程、数据建模 围绕与达成项目目标密切相关的关键业务场景,通过职责建模了解组 织结构、清晰岗位职责,通过流程建模区分业务场景、梳理业务流程,通过数据建模收集单证报 表,获取数据需求; 业务维服务分析 在汇总和分析项目目标,业务建模,流程建模、数据建模的基础上,分别描述 当前业务,探讨未来业务 分析重点在“业务”层面,主要关注业务当前的组织结构情况流程 执行情况、单证传输情况,并探讨未来业务模式和所需的业务服务集 为保证分析效果,讨论 可 一次围绕一个特定业务场景展开,应提前草拟好业务流程图和业务组件图,并邀请高层管理 人员参加 对于短期内无法决策的问题,应标识出几种可能的变化情况,以便为后续的服务设 计提供应考虑适应的变化点 系统维服务分析 已有系统为组织的重要信息化资源,通常包含组织的核心业务和数据 通 过梳理当前已有系统的情况,可从系统的视角补充查找和分析服务; 服务识别与筛选 业务流程,功能及数据中部分内容不适合通过服务中去实现 本阶段重点 是围绕项目目标,在考虑系统维服务分析结果的约束下,筛选业务维服务分析结果,协商确定 当前阶段待开发的服务集 最终形成服务集是一个迭代的过程,可根据项目情况不断滚动 扩展; 服务设计 本阶段主要是分类、管理识别出的服务集,逐个定义服务,形成服务规格说明(包括 服务接口及服务接口详细规约)及服务实现矩阵 本阶段工作成果可为具体的服务开发提供 完备的文档规格说明 服务分析要求 目标建模 6.1 目标建模宜从分析业务问题、明确项目目标的角度出发,识别与项目目标相关的职责、流程及数据, 为下一步职责、流程及数据建模锁定分析范围 主要工作宜包括以下内容:
GB/T32430一2015 a)分析业务问题, b) 明确项目目标 e识别与项目相关的职责、流程及数据 d)分解项目子目标,建立职责,流程及数据与其的对应关系 6.2职责建模 职责建模宜从了解组织结构,清晰岗位职责的业务维度出发,了解当前业务部门组织结构和职责, 探讨未来业务部门(或业务领域)划分和职责界定,并标识当前或未来业务中会重点关注的热点职责,形 成候选服务 主要工作宜包括以下内容,分析结果如图2所示: a)了解当前组织结构和职责; b 探讨未来可能的组织结构和职责; c 协商明确近期可行的组织结构和职责 d)标识重点职责; 发现候选服务 业务领域 业务领域1 业务领域2 业务领域3 业务领域4 业务! 业务2 业务1 业务2 业务1 业务1 业务2 业务2 总部 业务3 业务3 业务4 业务3 业务4 层次 业务1 业务1 业务2 业务2 业务1 业务2 业务2 业务1 部门 业务3 业务4 业务3 业务4 层次 业务6 业务5 业务1 业务1 业务2 业务1 业务1 业务2 岗位 层次 图2soA职责建模示意图 6.3流程建模 流程建模宜从区分业务场景,梳理业务流程的角度出发,围绕与项目目标相关的关键业务场景,逐 个场景地分析、探讨当前流程和未来优化流程,细化流程中的操作要求,形成候选服务 如图3所示,主 要工作宜包括以下内容 区分与项目目标相关的关键业务场景; a b逐个场景地梳理近期可行的业务流程; 结合职责建模的职责分析结果,细化业务操作 d)发现候选服务
GB/T32430一2015 业务流程 业务操作 候选服务 图3soA流程建模过程示意图 6.4数据建模 数据建模宜从收集单证报表,获取数据需求的业务维度出发,围绕与项目目标相关的关键业务场 景,逐个场景地收集相关单证报表资料,获取部门岗位之间的数据需求,形成候选服务 主要工作宜包 括以下内容: a 区分与项目目标相关的关键业务场景 逐个场景地收集相关单证,报表资料 b e结合职责建模的职责分析结果,协商明确近期可行的数据需求 D 发现候选服务 6.5业务维服务分析 业务维服务分析宜围绕与项目目标相关的关键业务场景,汇总领域、流程、数据建模的结果,逐个场 景地形成业务流程模型和业务组件模型,最终形成候选服务集 主要工作宜包括以下内容 重点分析项目目标相关的关键业务场景, a b)逐个场景地协商形成近期可行的业务流程模型; e)汇总形成近期可行的业务组件模型 形成业务维候选服务集 D 6.6系统维服务分析 系统维服务分析宜从系统的维度出发,分析识别已有系统、以及系统之间的访问接口和功能列表, 发现候选服务的过程 主要工作宜包括以下内容 a)分析梳理已有系统及其技术架构风格 b) 识别已有系统之间相互访问接口; e)识别并抽取已有系统已对外提供的接口; d)对照业务维候选服务与系统维候选服务的映射关系 发现候选服务 6.7服务筛选 服务筛选宜从候选服务中,运用校验,评估等方法从候选服务中逐步筛选并得到待暴露(实现)的服 务的过程 其主要工作内容包括:确定服务评估的指标、对服务进行打分评估并形成候选服务集 如 图4所示
GB/T32430一2015 服务候选评估 架构师 服务打分 综合评估 服务候选评估 服务识别结束 Outtput" 服务候选列表 图4服务评估示意图 常见服务评估指标如下: 范围(衡量一个服务在企业中潜在的适用范围); b 可复用性(衡量一个服务潜在的可复用水平); 可扩展性(衡量一个服务可扩展的能力水平); c 服务粒度适合性(衡量一个服务对于企业制定的目标的适合程度; 可管理性(衡量一个服务的可管理水平) 敏捷度(衡量一个服务适应变化的能力水平) 因项目影响(衡量为了实现共享服务对当前一些开发项目的影响) h可行性(衡量为了实现共享服务已具备的条件以及一些可能的困难和风险》 指标b).,c).d e)的具体评价方法参见GB/T32428- 2015 基于6.1一6.6所描述的服务分析方法,可形成服务分析的工作产品为候选服务列表,其模板参见 A.1 候选服务列表宜包括如下元素 a)服务名称; b) 服务功能描述 e)服务来源, d)服务使用者 e)服务提供者; f 所属流程信息 服务设计要求 7.1综述 服务设计时宜对服务分析过程中得到的服务进行分类、定义、接口设计、实现方式决策,如图5 所示
GB/T32430一2015 服务设计 服务实现 服务接口 服务分类 服务定义 设计 方式决策 图5服务设计要素示意图 7.2服务分类 为了有助于服务组合和分层,对不同服务实施不同的管控,并为逻辑设计提供依据,从而提高服务 可管理性,宜按照服务的不同属性进行分层抽象划分、提取 服务分类示意如图6所示 流程 实体 服务 功能 服务 图6服务分类示意图 各类服务特性如下 流程服务,根据业务需求编排自动化服务和人工服务 a 任务服务,通常由实体服务,功能服务和业务规则组合而成,处理面向业务的特定功能,重用 b 性低; 实体服务,提供对企业业务对象的相关操作,屏蔽了后台数据来源的多样性和复杂性,独立于 流程和应用,重用性高; d)功能服务,提供基础的技术功能,提供细颗粒度的处理,重用性很高; 接口服务,通过服务封装了已有系统接口 e 信息资源服务,由已有系统提供并已发布的服务 7.3服务定义 服务定义流程如图7所示
GB/T32430一2015 通过服务依赖组合需求 通过分类定义服务边界 循环识别服务边界 过范定义服务边界 创建服务规约 附加需求规约 通过多重企业应用定义服务边界 附加特定粘围的外部规约 通过服务质量定义服务边界 光R的 规约发布 图7服务定义示意图 服务定义的主要工作宜包括以下内容 确定服务边界,宜主要考虑以下影响因素 a 不同的需求范围; 1 2)不同的安全策略 3)消息交换模式; 服务质量要求 4 b)定义服务接口过程,宜主要考虑以下影响因素 服务功能 1) 2) 操作约束 3) 安全需求; 4) 能力需求 非功能性需求 57 确定服务接口内容,即服务名称,消息格式,服务间层次,关联关系等,宜包括以下元素 服务名称 1) 27 服务调用方式; 37 依赖的服务; 4 响应时间; s 服务安全要求; 6)允许调用的角色 7服务操作; 8)消息格式 工作产品的模版参见A.2 dD 服务接口设计 7.4 服务接口设计的主要工作宜包括以下内容 a)定义服务接口; b确定服务的调用方式; e)确定覆盖功能与非功能需求;
GB/T32430一2015 d)工作产品为服务接口详细规约,模版参见A.3 服务接口设计的流程如图8所示 知成牌在的客网 设计消息结构 确定接风格 交叉检验服务结构 确定接口传输协议 交义检服务契约 我讲服务米作桃 预览s0A主导下的接口设计 确定消息交换格式 设计服务的物理接口 发布服务接口 确定实现技术方案 图8服务接口设计示意图 7.5服务实现方式决策 服务实现方式决策的主要工作宜包括以下内容 确定服务质量要求 a b)确定业务服务在技术上的实现方式 工作产品为服务实现矩阵,模板参见A.4 C
GB/T32430一2015 附录 A 资料性附录 成果模板示例 A.1候选服务列表 候选服务列表见表A.! 表A.1候选服务列表 服务提供者 服务使用者 服务来源 服务名称 服务功能描述 所属流程信息 工业企业提供工 工业生产计划业月度生产计划 制 定 商 业 工业企业 商业企业 工业生产计划 信息 信息服务,商业企 计划 业调用获取数据 A.2服务接口列表 服务接口列表见表A.2 表A.2服务接口列表 消息 服务 服务调依赖的 响应 服务安 允许调用 服务 输人 输出 名称 用方式 服务 时间 全要求 的角色 操作 名称类型 名称 描述 Project Query 2 查询合同 是 nputStringOutput 同步返回 Object Manager Contract Purchase P(O Object 更新采购单状态异步返回 是 POManager POObject OrderConfirm ResultCodBoolean 接收商业采 购单信息 查询商业销售 生成采购单 查询商业库存信息 获取合同信息
GB/T32430一2015 A.3服务接口详细规约 服务接口详细规约见表A.3 表A.3服务接口详细规约 服务标识 CS_IND_INF_MonProdPlan 服务提供者 工业企业 服务使用者 商业企业 服务管理者 国家局信息中心 服务描述 工业企业提供工业月度生产计划信息服务,商业企业调用获取数据 方法1 方法名称 getMonProdPlanm 功能描述 商业企业获取工业企业月度生产计划数据 适用场景 朋明 参数名称 参数类型 说 输人参数 indCode 工业企业编砂 C.30 D6 month 月份,格式;YYYYMM 说 参数名称 参数类型 明 输出参数 prodPlan 参见prodPlan样例 参见ECsIND_INF_MonProdPlan.wsdl WSDL 参数prodPlan样例 eb2312" xmlversion=".0" encoding 6901028310727500 6901028310728500GB/T32430一2015 表A.4服务实现矩阵 实现决策 服务组件 服务实现 功能及技术组件 原因 生成采购单 合同 采购 Bild定期获取开 合同管理是在网 获得合同列表 合同 保存合同信息,并上交易系统中实现 创建所需的服务 的,对外的接口是私 获得合同信息 有的AP

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

随着信息技术的不断发展,企业需要更加高效、可靠地开发和管理软件系统。面向服务架构(SOA)作为一种解决方案,逐渐成为了企业中广泛使用的架构模式。其中,服务分析与设计是实施SOA的重要环节之一。针对这一问题,国家标准化管理委员会制定了GB/T32430-2015标准,指导企业在SOA应用中进行服务分析与设计。

服务分析是指对企业IT系统中存在的业务需求进行识别、整理和分类等工作,以确定IT系统中各个服务的功能和性能要求。在服务分析的过程中,需要考虑的因素包括服务的接口、数据传输方式、安全性、可靠性等,以确保服务的高质量。

服务设计是指根据服务分析的结果,根据标准化的方法和技巧来定义服务。它通常包括服务接口、数据传输格式、安全机制、可靠性要求等方面。服务设计的目标是提供高质量的服务,并满足企业的需求。

GB/T32430-2015标准规定了SOA应用中服务分析与设计的具体步骤和方法,包括服务识别、服务分类、服务描述、服务功能分解、服务接口定义、服务实现方式和服务测试等。其中,服务描述是服务分析与设计的核心环节之一,它需要详细说明服务的功能、输入输出参数、数据类型等信息。

在SOA应用中,服务分析与设计的质量对整个IT系统的稳定性和可靠性起着至关重要的作用。因此,企业需要遵循GB/T32430-2015标准,采用标准化的方法和技巧进行服务分析与设计,以确保服务的高质量和IT系统的可靠性。

和信息技术SOA应用的服务分析与设计类似的标准

信息技术SOA治理

信息技术SOA应用的生存周期过程
上一篇 本文分享国家标准信息技术SOA应用的生存周期过程的全文阅读和高清PDF的下载,信息技术SOA应用的生存周期过程的编号:GB/T32429-2015。信息技术SOA应用的生存周期过程共有20页,发布于2017-01-01
信息技术SOA服务交付保障规范
本文分享国家标准信息技术SOA服务交付保障规范的全文阅读和高清PDF的下载,信息技术SOA服务交付保障规范的编号:GB/T32431-2015。信息技术SOA服务交付保障规范共有18页,发布于2017-01-01 下一篇
相关推荐