1、#*长风联盟电子政务总体应用架构设计指南研究报告长风开放标准平台软件联盟二七年五月目 录第一章引论 11.1 本指南的目的 11.2 本指南依据的长风联盟参考文档 11.3 什么是 SOA 电子政务总体应用架构 11.4 什么是 SOA 电子政务总体应用架构设计 21.5 本指南的章节组织 71.6 应用架构设计的主要内容 71.7 应用架构分解结构与参考架构(RA)71.8 应用架构设计环境 81.9 应用架构设计干系人 81.10 应用架构设计指南与长风联盟其他文档的关系 9第二章 应用架构设计知识领域、原则和过程组 102.1 应用架构设计知识领域 102.1.1 SOA 设计方法学 1
2、02.1.2 数据建模方法学 102.1.3 面向流程设计方法学 112.1.4 技术领域架构设计方法学 112.1.5 通用架构设计方法学 13#*2.1.6 面向对象设计方法学 192.2 服务设计原则 212.2.1 显式定义边界 212.2.2 自治性 232.2.3 服务共享大纲和契约，但不共享类 242.2.4 服务兼容性基于策略 252.2.5 访问的开放性 262.2.6 随时可用 272.2.7 粗粒度服务接口 272.2.8 服务分级 282.2.9 松散耦合 282.2.10 可重用的服务及服务接口设计管理 292.2.11 标准化的接口 302.2.12 支持各种消息模
3、式 302.2.13 精确定义服务接口 312.3 应用架构设计过程组 312.3.1 架构启动过程组 332.3.1.1 概述 332.3.1.2 业务模型合理性初步分析 342.3.1.3 架构范围定义 352.3.1.4 功能架构 352.3.1.5 业务分类 352.3.2 架构分析过程组 362.3.2.1 概述 362.3.2.2 组织模型分析 382.3.2.3 数据模型分析 382.3.2.4 流程模型分析 382.3.2.5 UI 分析 392.3.2.6 外部接口分析 392.3.2.7 关键用例分析 392.3.2.8 关键技术点分析 402.3.2.9 服务定义 402
4、.3.2.10 干系人分析 402.3.2.11 外部接口设计过程 412.3.2.12 服务设计过程 432.3.3 架构设计过程组 432.3.3.1 概述 432.3.3.2 总体架构设计 452.3.3.3 框架选择 452.3.3.4 数据模型设计 452.3.3.5 流程设计 452.3.3.6 关键技术点设计 452.3.3.7 外部接口设计 462.3.3.8 UI 设计 48#*2.3.3.9 服务设计过程 482.3.3.10 质量设计 482.3.3.11 设计视图分配 482.3.3.12 部署视图设计 482.3.3.13 团队开发管理设计 482.3.4 架构实现过
5、程组 492.3.4.1 概述 492.3.4.2 工作绩效信息收集 492.3.4.3 架构实现 492.3.5 架构测试过程组 492.3.5.1 概述 492.3.5.2 测试规划 502.3.5.3 服务测试 502.3.5.4 功能测试 502.3.5.5 性能测试 512.3.5.6 技术指标测试 512.3.5.7 架构优化 512.3.6 架构监控过程组 512.3.6.1 概述 512.3.6.2 业务模型合理性跟踪 512.3.6.3 绩效报告 522.3.7 架构收尾过程组 522.3.7.1 概述 522.3.7.2 管理收尾 522.3.7.3 架构进化 52第三章
6、应用架构分解结构 533.1 总体架构 533.2 基础支撑层 543.2.1 全景图 543.2.2 硬件/网络层设计 553.2.2.1 主机设计 553.2.2.2 网络规划 573.2.2.3 存储/备份设计 573.2.2.4 其它硬件设备 603.2.3 系统软件层设计 603.2.3.1 操作系统选型 613.2.3.2 应用服务器选型 623.2.3.3 数据库服务器选型 633.2.3.4 其它系统软件选型 643.2.4 支撑软件层设计 643.2.4.1 技术架构选择 643.2.4.2 软件框架设计 673.2.4.3 基础构件/服务设计 673.2.4.4 其它构件
7、67#*3.2.5 与架构其它层关系 673.2.6 相关规范与标准 673.2.7 服务运行、管理和监控环境 673.3 政务资源层 683.3.1 政务资源层总体架构 683.3.1.1 传统资源层面临的问题 683.3.1.2 架构目标 693.3.1.3 架构总图及描述 693.3.1.4 政务资源层应用前景和趋势 703.3.2 政务信息资源 703.3.2.1 政务信息资源的封装 713.3.2.2 政务信息资源的接入 713.3.2.3 政务信息资源的管理 723.3.2.4 政务信息资源的访问 733.3.3 部门业务应用资源 733.3.3.1 应用资源的封装 743.3.3
8、.2 应用资源的接入 743.3.3.3 应用资源的管理 753.3.3.4 应用资源的统一访问 753.3.4 政务目录资源 763.3.4.1 资源元数据描述 773.3.4.2 资源编目 793.3.4.3 安全管理 793.3.4.4 基于目录的资源共享体系 803.4 支撑服务层 813.4.1 全景图 813.4.2 描述 813.4.3 服务构成 823.4.3.1 公共服务 823.4.3.2 领域服务 893.5 业务应用层 913.5.1 全景图 913.5.2 描述 913.5.3 基于 SOA 业务应用层的业务应用模式 923.5.3.1 从软基础设施的视角研究模式分类
9、 933.5.3.2 基于 SOA 的资源共享应用模式 953.5.3.3 基于 SOA 的业务协同应用模式 963.5.3.4 基于 SOA 的不同服务渠道的应用模式 963.5.4 与其它各层的关系 973.5.4.1 业务应用层对基础支撑层的要求 973.5.4.2 业务应用层对展现服务层的支持 983.5.4.3 业务应用层对安全保障体系的要求 983.6 展现服务层 993.6.1 全景图 99#*3.6.2 适配器 1003.6.3 支撑运行环境 1003.6.4 具体的展现服务 1013.6.5 展现服务相关的标准体系、工具集、安全保障体系 1013.7 工具集 1023.7.1
10、 全景图 1033.7.2 开发和部署服务 1033.7.2.1 服务的体系架构/模型 1053.7.2.2 体系架构说明 1063.7.2.3 功能模块概述 1063.7.2.4 功能模块间关系概述 1073.7.2.5 功能详细说明 1073.7.2.6 与其他服务关系 1103.8 标准规范体系 1123.8.1 全景图 1123.8.2 基础支撑层 1123.8.3 政务资源层 1163.8.4 支撑服务层 1183.8.5 业务应用层 1223.8.6 展现服务层 1233.8.7 安全保障体系 1243.9 安全保障体系 1263.9.1.1 全景图1263.9.1.2 安全在整个
11、 SOA 体系中的作用和位置 1283.9.1.3 安全保障体系的总体逻辑框架 1293.9.1.4 安全保障体系中采用的标准规范体系框架图 1303.9.2 SOA 安全实施要点及方法 1313.9.2.1 端到端 SOAP 消息交换的安全 1313.9.2.2 Web 服务策略机制 1313.9.2.3 令牌转换和信任域 1333.9.2.4 安全对话 1333.9.2.5 跨域的互信任操作 1343.9.2.6 SOA 系统的安全管理制度 135第四章 应用架构设计路线图 1364.1 全景图 1364.2 基础 SOA1374.3 网络化 SOA1384.4 流程支撑的 SOA138附
12、录 A 术语表 141附录 B 架构设计资料参考 142附录 C 案例描述 142 #*第一章 引论1.1 本指南的目的基本目的是识别 SOA 电子政务领域应用架构设计知识体系普遍公认为良好做法的那一部分。识别， 指一般概括性介绍，而非详尽无遗漏的说明。普遍公认 ，指介绍的知识和做法在绝大多数情况下适用于绝大多数的架构设计，其价值和实用性也得到了人们的广泛认同。良好做法 ，指一致认为，正确应用这些技能、工具和技术能够增加范围极为广泛的各种不同架构设计成功的机会。良好做法并不是说这些知识和做法一成不变地应用于或应当应用于所有的架构设计：架构设计团队负责架构的裁剪和扩展。本指南还旨在作为该职业和实
13、践一个共同的 术语汇编 ，为讨论、书写和应用架构设计方面的问题提供便利。这种术语汇编是一种职业必不可少的组成部分。本指南还提供了一个参考的 电子政务应用架构 ，并结合一个具体案例讲解如何在电子政务领域进行基于 SOA 的应用架构设计。本指南用来指导电子政务领域政务系统建设和政务系统之间的整合任务的架构设计。而附录 B 列出了架构设计资料的其他来源。1.2 本指南依据的长风联盟参考文档 SOA-RA-TF 制定的SOA 参考架构白皮书 SOA-AP-TF 制定的 SOA 电子政务总体技术架构与解决方案 1.3 什么是 SOA 电子政务总体应用架构长风联盟依据国家电子政务总体框架 ，遵循国家电子政
14、务标准，参#*照北京市电子政务总体技术框架 ，结合长风联盟 SOA 电子政务解决方案的实际情况，制定出长风联盟 SOA 总统技术架构。目标是作为长风联盟企业实施 SOA 架构的电子政务系统的标准型、指导性框架，实现未来电子政务系统的互联互通、资源共享，并使联盟企业可以快速、流畅、高效地构建各类政务应用系统,保障以该架构为标准的各类政务应用通畅运行。该架构将成为未来电子政务实施的重要指导。该架构又称为“五横三纵架构” 。1.4 什么是 SOA 电子政务总体应用架构设计SOA 电子政务总体应用架构设计就是把各种知识、技能、手段和技术应用于架构活动中，以达到系统建设和系统整合的要求。 架构设计必须权
15、衡质量、时间、范围和费用等方面的要求。质 量 ( 非 功 能 需 求 )范 围 ( 功 能 需 求 )时 间成 本其中：非 功 能 需 求质 量 属 性( 按 各 种 角 度 分 类 的 属 性 。譬 如 : 1 按 生 命 周 期 划 分 会 有 设 计 期 ， 开 发 期 ， 运行 期 ， 测 试 期 ， 维 护 期 质 量 2 定 量 属 性 和 定 性 属 性 , 可 用 性 、 可 修 改 性 、性 能 、 安 全 、 有 效 性 、 可 测 试 性 、 可 监 控性 、 可 追 溯 性 、 可 升 级 性 、 可 扩 张 性 、 可 维护 性 、 可 管 理 性 、 可 复 用 性
16、 、 模 块 独 立 交 付性 等 )约 束下面介绍几个通常会在系统设计中涉及的质量属性。1性能#*指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等。通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能;也可以通过系统能够处理的交易量(每秒)来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的事情。在较传统的基于 EJB 或者 XML-RPC 的分布式计算模型中，它们的
17、服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在 Intranet 的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于 SOA 的架构中使用了很多 Web Service 来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在 Internet 环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于 SOA 的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。2可升级性指当系统负荷加大时，仍能够确保所
18、需的服务质量，而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器，从而增加系统的整体处理
19、能力。作为一个系统架#*构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。3可靠性指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性
20、。因此，一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或 Web 服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。4可用性指确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件的错误会对系统的可
21、靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服务仍然可用。在基于 SOA 来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持;第二种是通过UDDI 等动态查找匹配方式来支持系统整体的高可用性。在 SOA 架构设计师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的 SOA 系统架构中的关键性业务能具有较高的可用性。#*5可扩展性指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。当系统刚配置好的时候，你很
22、难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素:低耦合，界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为 SOA 架构中的不同服务之间本身就保持了一种无依赖的低耦合关系;服务本身是通过统一的接口定义 (可以是 WSDL)语言来描述具体的服务内容，并且很好地封装了底层的具体实现。6可维护性指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。当系统刚被部
23、署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口(可以是 WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。7可管理性指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，
