架构电子政务总体应用架构设计指南.doc

《架构电子政务总体应用架构设计指南.doc》由会员分享，可在线阅读，更多相关《架构电子政务总体应用架构设计指南.doc（144页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、#*长风联盟电子政务长风联盟电子政务总体应用架构设计指南研究报告总体应用架构设计指南研究报告长风开放标准平台软件联盟二七年五月目目 录录第一章引论 1 1.1 本指南的目的 1 1.2 本指南依据的长风联盟参考文档 1 1.3 什么是 SOA 电子政务总体应用架构 1 1.4 什么是 SOA 电子政务总体应用架构设计 2 1.5 本指南的章节组织 7 1.6 应用架构设计的主要内容 7 1.7 应用架构分解结构与参考架构(RA)7 1.8 应用架构设计环境 8 1.9 应用架构设计干系人 8 1.10 应用架构设计指南与长风联盟其他文档的关系 9 第二章 应用架构设计知识领域、原则和过程组 1

2、0 2.1 应用架构设计知识领域 10 2.1.1 SOA 设计方法学 10 2.1.2 数据建模方法学 10 2.1.3 面向流程设计方法学 11 2.1.4 技术领域架构设计方法学 11 2.1.5 通用架构设计方法学 13#*2.1.6 面向对象设计方法学 19 2.2 服务设计原则 21 2.2.1 显式定义边界 21 2.2.2 自治性 23 2.2.3 服务共享大纲和契约，但不共享类 24 2.2.4 服务兼容性基于策略 25 2.2.5 访问的开放性 26 2.2.6 随时可用 27 2.2.7 粗粒度服务接口 27 2.2.8 服务分级 28 2.2.9 松散耦合 28 2.2

3、.10 可重用的服务及服务接口设计管理 29 2.2.11 标准化的接口 30 2.2.12 支持各种消息模式 30 2.2.13 精确定义服务接口 31 2.3 应用架构设计过程组 31 2.3.1 架构启动过程组 33 2.3.1.1 概述 33 2.3.1.2 业务模型合理性初步分析 34 2.3.1.3 架构范围定义 35 2.3.1.4 功能架构 35 2.3.1.5 业务分类 35 2.3.2 架构分析过程组 36 2.3.2.1 概述 36 2.3.2.2 组织模型分析 38 2.3.2.3 数据模型分析 38 2.3.2.4 流程模型分析 38 2.3.2.5 UI 分析 39

4、 2.3.2.6 外部接口分析 39 2.3.2.7 关键用例分析 39 2.3.2.8 关键技术点分析 40 2.3.2.9 服务定义 40 2.3.2.10 干系人分析 40 2.3.2.11 外部接口设计过程 41 2.3.2.12 服务设计过程 43 2.3.3 架构设计过程组 43 2.3.3.1 概述 43 2.3.3.2 总体架构设计 45 2.3.3.3 框架选择 45 2.3.3.4 数据模型设计 45 2.3.3.5 流程设计 45 2.3.3.6 关键技术点设计 45 2.3.3.7 外部接口设计 46 2.3.3.8 UI 设计 48#*2.3.3.9 服务设计过程 4

5、8 2.3.3.10 质量设计 48 2.3.3.11 设计视图分配 48 2.3.3.12 部署视图设计 48 2.3.3.13 团队开发管理设计 48 2.3.4 架构实现过程组 49 2.3.4.1 概述 49 2.3.4.2 工作绩效信息收集 49 2.3.4.3 架构实现 49 2.3.5 架构测试过程组 49 2.3.5.1 概述 49 2.3.5.2 测试规划 50 2.3.5.3 服务测试 50 2.3.5.4 功能测试 50 2.3.5.5 性能测试 51 2.3.5.6 技术指标测试 51 2.3.5.7 架构优化 51 2.3.6 架构监控过程组 51 2.3.6.1 概

6、述 51 2.3.6.2 业务模型合理性跟踪 51 2.3.6.3 绩效报告 52 2.3.7 架构收尾过程组 52 2.3.7.1 概述 52 2.3.7.2 管理收尾 52 2.3.7.3 架构进化 52 第三章 应用架构分解结构 53 3.1 总体架构 53 3.2 基础支撑层 54 3.2.1 全景图 54 3.2.2 硬件/网络层设计 55 3.2.2.1 主机设计 55 3.2.2.2 网络规划 57 3.2.2.3 存储/备份设计 57 3.2.2.4 其它硬件设备 60 3.2.3 系统软件层设计 60 3.2.3.1 操作系统选型 61 3.2.3.2 应用服务器选型 62

7、3.2.3.3 数据库服务器选型 63 3.2.3.4 其它系统软件选型 64 3.2.4 支撑软件层设计 64 3.2.4.1 技术架构选择 64 3.2.4.2 软件框架设计 67 3.2.4.3 基础构件/服务设计 67 3.2.4.4 其它构件 67#*3.2.5 与架构其它层关系 67 3.2.6 相关规范与标准 67 3.2.7 服务运行、管理和监控环境 67 3.3 政务资源层 68 3.3.1 政务资源层总体架构 68 3.3.1.1 传统资源层面临的问题 68 3.3.1.2 架构目标 69 3.3.1.3 架构总图及描述 69 3.3.1.4 政务资源层应用前景和趋势 70

8、 3.3.2 政务信息资源 70 3.3.2.1 政务信息资源的封装 71 3.3.2.2 政务信息资源的接入 71 3.3.2.3 政务信息资源的管理 72 3.3.2.4 政务信息资源的访问 73 3.3.3 部门业务应用资源 73 3.3.3.1 应用资源的封装 74 3.3.3.2 应用资源的接入 74 3.3.3.3 应用资源的管理 75 3.3.3.4 应用资源的统一访问 75 3.3.4 政务目录资源 76 3.3.4.1 资源元数据描述 77 3.3.4.2 资源编目 79 3.3.4.3 安全管理 79 3.3.4.4 基于目录的资源共享体系 80 3.4 支撑服务层 81

9、3.4.1 全景图 81 3.4.2 描述 81 3.4.3 服务构成 82 3.4.3.1 公共服务 82 3.4.3.2 领域服务 89 3.5 业务应用层 91 3.5.1 全景图 91 3.5.2 描述 91 3.5.3 基于 SOA 业务应用层的业务应用模式 92 3.5.3.1 从软基础设施的视角研究模式分类 93 3.5.3.2 基于 SOA 的资源共享应用模式 95 3.5.3.3 基于 SOA 的业务协同应用模式 96 3.5.3.4 基于 SOA 的不同服务渠道的应用模式 96 3.5.4 与其它各层的关系 97 3.5.4.1 业务应用层对基础支撑层的要求 97 3.5.

10、4.2 业务应用层对展现服务层的支持 98 3.5.4.3 业务应用层对安全保障体系的要求 98 3.6 展现服务层 99 3.6.1 全景图 99#*3.6.2 适配器 100 3.6.3 支撑运行环境 100 3.6.4 具体的展现服务 101 3.6.5 展现服务相关的标准体系、工具集、安全保障体系 101 3.7 工具集 102 3.7.1 全景图 103 3.7.2 开发和部署服务 103 3.7.2.1 服务的体系架构/模型 105 3.7.2.2 体系架构说明 106 3.7.2.3 功能模块概述 106 3.7.2.4 功能模块间关系概述 107 3.7.2.5 功能详细说明

11、107 3.7.2.6 与其他服务关系 110 3.8 标准规范体系 112 3.8.1 全景图 112 3.8.2 基础支撑层 112 3.8.3 政务资源层 116 3.8.4 支撑服务层 118 3.8.5 业务应用层 122 3.8.6 展现服务层 123 3.8.7 安全保障体系 124 3.9 安全保障体系 126 3.9.1.1 全景图126 3.9.1.2 安全在整个 SOA 体系中的作用和位置 128 3.9.1.3 安全保障体系的总体逻辑框架 129 3.9.1.4 安全保障体系中采用的标准规范体系框架图 130 3.9.2 SOA 安全实施要点及方法 131 3.9.2.

12、1 端到端 SOAP 消息交换的安全 131 3.9.2.2 Web 服务策略机制 131 3.9.2.3 令牌转换和信任域 133 3.9.2.4 安全对话 133 3.9.2.5 跨域的互信任操作 134 3.9.2.6 SOA 系统的安全管理制度 135 第四章 应用架构设计路线图 136 4.1 全景图 136 4.2 基础 SOA137 4.3 网络化 SOA138 4.4 流程支撑的 SOA138 附录 A 术语表 141 附录 B 架构设计资料参考 142 附录 C 案例描述 142 #*第一章第一章 引论引论1.1 本指南的目的本指南的目的基本目的是识别 SOA 电子政务领域应

13、用架构设计知识体系普遍公认为良好做法的那一部分。识别，识别，指一般概括性介绍，而非详尽无遗漏的说明。普遍公认普遍公认，指介绍的知识和做法在绝大多数情况下适用于绝大多数的架构设计，其价值和实用性也得到了人们的广泛认同。良好做法良好做法，指一致认为，正确应用这些技能、工具和技术能够增加范围极为广泛的各种不同架构设计成功的机会。良好做法并不是说这些知识和做法一成不变地应用于或应当应用于所有的架构设计：架构设计团队负责架构的裁剪和扩展架构设计团队负责架构的裁剪和扩展。本指南还旨在作为该职业和实践一个共同的术语汇编术语汇编，为讨论、书写和应用架构设计方面的问题提供便利。这种术语汇编是一种职业必不可少的组

14、成部分。本指南还提供了一个参考的电子政务应用架构电子政务应用架构，并结合一个具体案例讲解如何在电子政务领域进行基于 SOA 的应用架构设计。本指南用来指导电子政务领域政务系统建设政务系统建设和政务系统之间的整合政务系统之间的整合任务的架构设计。而附录 B 列出了架构设计资料的其他来源。1.2 本指南依据的长风联盟参考文档本指南依据的长风联盟参考文档SOA-RA-TF 制定的SOA 参考架构白皮书SOA-AP-TF 制定的SOA 电子政务总体技术架构与解决方案1.3 什么是什么是 SOA 电子政务总体应用架构电子政务总体应用架构长风联盟依据国家电子政务总体框架 ，遵循国家电子政务标准，参#*照北

15、京市电子政务总体技术框架 ，结合长风联盟 SOA 电子政务解决方案的实际情况，制定出长风联盟 SOA 总统技术架构。目标是作为长风联盟企业实施 SOA 架构的电子政务系统的标准型、指导性框架，实现未来电子政务系统的互联互通、资源共享，并使联盟企业可以快速、流畅、高效地构建各类政务应用系统,保障以该架构为标准的各类政务应用通畅运行。该架构将成为未来电子政务实施的重要指导。该架构又称为“五横三纵架构” 。1.4 什么是什么是 SOA 电子政务总体应用架构设计电子政务总体应用架构设计SOA 电子政务总体应用架构设计就是把各种知识、技能、手段和技术应用于架构活动中，以达到系统建设和系统整合的要求。架构

16、设计必须权衡质量、时间、范围和费用等方面的要求。质质量量( (非非功功能能需需求求) )范范围围( (功功能能需需求求) )时时间间成成本本其中：非非功功能能需需求求质质量量属属性性 (按按各各种种角角度度分分类类的的属属性性。 譬譬如如: 1按按生生命命周周期期划划分分会会有有设设计计期期，开开发发期期，运运 行行期期，测测试试期期，维维护护期期质质量量 2定定量量属属性性和和定定性性属属性性,可可用用性性、可可修修改改性性、 性性能能、安安全全、有有效效性性、可可测测试试性性、可可监监控控 性性、可可追追溯溯性性、可可升升级级性性、可可扩扩张张性性、可可维维 护护性性、可可管管理理性性、可

17、可复复用用性性、模模块块独独立立交交付付 性性等等)约约束束下面介绍几个通常会在系统设计中涉及的质量属性。1性能性能#*指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等。通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能;也可以通过系统能够处理的交易量(每秒)来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的事情。在较传统的基于 EJB 或者 XML-RPC 的分布

18、式计算模型中，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在 Intranet 的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于 SOA 的架构中使用了很多 Web Service 来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在 Internet 环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于 SOA 的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。2可升级性可升级性指当

19、系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的

20、机器，从而增加系统的整体处理能力。作为一个系统架#*构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。3可靠性可靠性指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那

21、么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或 Web 服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。4可用性可用性指确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机

22、制，虽然一个单独的组件的错误会对系统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服务仍然可用。在基于 SOA 来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持;第二种是通过UDDI 等动态查找匹配方式来支持系统整体的高可用性。在 SOA 架构设计师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的 SOA 系统架构中的关键性业务能具有较高的可用性。#*5可扩展性可扩展性指在不影响现有系统功能的基础上，为系统添加新的功能

23、或修改现有功能的能力。当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素:低耦合，界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为 SOA 架构中的不同服务之间本身就保持了一种无依赖的低耦合关系;服务本身是通过统一的接口定义(可以是 WSDL)语言来描述具体的服务内容，并且很好地封装了底层的具体实现。6可维护性可维护性指在不影响系统其他部分的

24、情况下修改现有系统功能中问题或缺陷的能力。当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务

25、的接口(可以是 WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。7可管理性可管理性指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，#*通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时， SOA 架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架(Framew

26、ork)上。8安全性安全性指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当 SOA 架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业 SOA 架构中的一些服务是由 WebService 实现的，在考虑这些服务安全性的时候也要同时

27、考虑效率的问题，因为 WS-Security 会为 Web Service 带来一定的执行效率损耗。高质量的架构设计还考虑了技术风险应对的因素。应对变化，权衡不变与变化是架构设计永恒的主题。架构设计中还必须考虑 SOA 的独特性,例如：服务分类方法等。1按服务在系统建设中的用途划分：单单个个系系统统内内 部部服服务务系系统统间间集集成成 服服务务对对象象或或构构件件2按服务的功能划分：#*基本服务：数据中心的服务和逻辑中心的服务中介服务：技术网关、适配器、外观、装饰服务以流程为中心的服务公共企业服务：为跨企业集成提供接口，例如 SMS、Email 等另外应用程序前端应用程序前端是 SOA 的激

28、活元素。1.5 本指南的章节组织本指南的章节组织主要分 4 章介绍。第 1 章 引论第 2 章应用架构设计知识领域、设计原则和过程组第 3 章 应用架构分解结构第 4 章 应用架构设计路线图1.6 应用架构设计的主要内容应用架构设计的主要内容依据 SOA-RA-TF 的参考架构，解决电子政务应用领域如何产出一个 SOA应用架构的问题：架构的生命期构成整体架构设计过程组架构分解结构(五横三纵架构)知识领域:服务参考模型架构侧面系(生命周期模型和 4+1 视图)1.7 应用架构分解结构与参考架构应用架构分解结构与参考架构(RA)应用架构分解结构中的基础支撑层中的系统软件尽量按照 RA 标准实现，如

29、不能满足，架构上应考虑松耦合的互连互通，保障符合 RA 标准的服务库和应用系统能够和本应用架构协同。另外 RA 为应用架构分解结构中的服务开发运行体系提供支撑机制，如ESB 等。#*1.8 应用架构设计环境应用架构设计环境本指南假定架构设计在项目环境下进行。 应用架构设计受到一定环境因素的影响和约束，并反过来对这些因素产生 影响： 应用领域标准规范 组织过程资产 公司战略要求 技术环境 项目要求 管理因素架构设计和项目管理和组织日常运作管理是密切相关的，但本指南不涉及 相关内容，请参考相关书籍和文献资料。1.9 应用架构设计干系人应用架构设计干系人架构设计要考虑架构设计干系人的要求。 高层管理

30、人员 项目发起人 项目经理 架构设计师 需求人员 开发人员 测试人员 客户#*1.10 应用架构设计指南与长风联盟其他文档的关系应用架构设计指南与长风联盟其他文档的关系咨咨询询方方法法论论实实施施方方法法论论 (描描述述整整个个软软件件生生命命周周期期)架架构构设设计计指指南南 (只只描描述述与与架架构构设设计计相相关关的的内内容容)参参考考架架构构(SOA-RA)依依据据解解决决方方案案依依据据输输出出(初初步步架架构构)输输出出(实实施施架架构构)依依据据SOA电电子子政政务务总总体体技技术术架架构构 与与解解决决方方案案依依据据应应用用规规范范体体系系总总体体研研究究电电子子政政务务SO

31、A应应用用模模式式研研究究报报告告依依据据依依据据原原型型规规划划依依据据#*第二章第二章 应用架构设计知识领域、原应用架构设计知识领域、原 则和过程组则和过程组2.1 应用架构设计知识领域应用架构设计知识领域S SO OA A电电子子政政务务总总体体应应用用 架架构构设设计计指指南南数数据据建建模模方方法法学学面面向向对对象象设设计计方方法法学学通通用用架架构构设设计计方方法法学学面面向向流流程程设设计计方方法法学学技技术术领领域域架架构构设设计计 方方法法学学( (如如 J J2 2E EE E、. .N Ne et t等等) )S SO OA A电电子子政政务务总总体体应应用用架架构构

32、设设计计知知识识体体系系S SO OA A设设计计方方法法学学2.1.1 SOA 设计方法学设计方法学SOA 设计方法并非全新的方法论，而是继承了传统的面向对象的设计方法以及面向过程的设计方法，同时又增加了 SCA,，SDO，BPEL 等技术，融入了面向服务的设计方法，服务参考模型 OASIS RM 里的内容映射，具体内容包括服务定义、服务设计、服务管理、服务开发、服务测试和服务部署。2.1.2 数据建模方法学数据建模方法学传统的数据建模方法学是面向一个应用系统内部的实体的建模方法学，而在当前数据整合、应用整合的需求下，数据建模还要考虑在不同系统间进行数据交换和数据共享的需求。基于业务效率的考

33、虑，从业务流程出发的思路改变#*了数据模型。只有你从业务流程的角度来看待数据的时候，数据模型才能算真正完成。2.1.3 面向流程设计方法学面向流程设计方法学阐述了一种以实现流程优化的流程系统设计思想。这种设计思想是面向业务流程的，不同于传统 MIS 系统面向部门职能的设计思想。首先把系统设计区分为原理层设计和技术层设计两个层次，然后从业务流程设计、数据模型设计和技术架构设计三个方面论述了原理层设计的基本思想。2.1.4 技术领域架构设计方法学技术领域架构设计方法学大型 IT 系统的设计通常遵循七层架构的设计方法，包括：界面层界面层该层是直接面向用户（包括公众、企业、业务人员、行政管理人员、领导

34、等使用者）的统一的系统界面。界面层利用业界主流的 IT 技术支持多种渠道接入和交互（如互联网、电话、手机短信等接入方式） ，以及统一的身份认证及权限管理。应用层应用层应用层提供所有的信息应用和系统管理的业务逻辑，分解业务请求，通过应用支撑层进行数据处理，并将返回信息组织成所需的格式提供给客户端。应用系统分为四大部分 ：面向公众和企业的外网应用审批门户（网上审批系统前台） ，提供网上申报和反馈查询等在线服务功能；面向公务员的审批服务平台，实现业务审批、监督检察、业务调度、决策支持等功能；面向公务员的政府资源共享平台（数据共享与交换平台） ，实现基于审批业务的数据交换与基于委办局现有信息资源的数据

35、共享使用等功能。面向公务员的开放办公平台，实现基于开放的桌面办公系统，实现对审批过程数据的保存及归档等。#*应用支撑层应用支撑层应用支撑层构建在 J2EE 应用服务器之上，提供了一个应用基础平台 DC-BPIP，并提供大量公共服务和业务构件，提供构件的运行、开发和管理环境，最大限度提高开发效率，降低工程实施、维护的成本和风险。应用支撑层采用了行业应用的先进体系结构，以建立高性能、高可靠性、高扩展性的应用系统，满足客户快速发展的业务需求。信息资源层信息资源层信息资源层是整个系统的信息资源中心，涵盖全市所有与行政审批相关的结构化和非结构化数据。它是企业信息资源的存储和积累，为系统应用提供数据访问服

36、务、备份、存储功能。IT 基础平台层基础平台层IT 基础平台为系统的软硬件以及网络基础平台，分为三个部分：系统软件、硬件支撑平台、和网络支撑平台。其中，系统软件包括中间件、数据库服务器软件等；硬件支撑平台包括：主机、存储、备份等硬件设备；网络支撑为系统运行所依赖的网络环境。它对上层应用起到技术支撑作用支撑体系层支撑体系层系统建设和推广运行仅仅依赖应用系统建设、硬件网络建设是不够的，需要在系统安全方面、标准化方面、以及系统运维三个不同层面的工作来共同支撑。只有这样，才能使系统建设顺利进行，也才能保证系统能顺利推广、稳定运行。法律法规层法律法规层以上各个层面的建设，需要依托于现有的法律、法规及一些

37、规范才可成功运行。系统的分析、设计、实施都必须充分考虑这些因素。只有切实符合这些规范，系统才能与建设单位共同发展，得到各级用户的认可。而利用 RUP 的设计思想，则将架构设计概括为 4+1 视图：逻辑视图逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块“；它们可能是逻辑层、功能模块等。开发视图开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方 SDK 和现成框架、类库，以及开发的系统将运行于其上#*的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。处理视图处理视图

38、。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。物理视图物理视图。物理视图关注“目标程序及其依赖的运行库和系统软件“最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个 IT 系统相互影响的架构视图。场景视图。关注业务的应用

39、场景。2.1.5 通用架构设计方法学通用架构设计方法学架构设计是一种权衡（trade-off） 。一个问题总是有多种的解决方案。而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复杂度。没有一个软件能够满足所有的要求，因为这些要求之间带有天生的互斥性。而我们评价架构设计的好坏的依据，就只能是根据不同要求的轻重缓急，

40、在其间做出权衡的合理性。目标目标我们希望一个好的架构能够：重用：重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。重用是我们不断追求的目标之一，但事实上，做到这一点可没有那么容易。在现实中，人们已经在架构重用上做了很多的工作，工作的成果称为框架（Framework） ，比如说 Windows 的窗口机制、J2EE 平台等。但是在企#*业商业建模方面，有效的框架还非常的少。透明透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把客户需求的接口呈现给客户。这样，具体的实现对客户来说就是透明的。一个具体的例子是我们使用 JSP 的 tag 技术来代替 JSP 的嵌

41、入代码，因为我们的 HTML界面人员更熟悉 tag 的方式。延展：延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一定的延展性，以适应未来可能的变化。可是，如上所说，延展性和稳定性，延展性和简单性都是矛盾的。因此我们需要权衡我们的投入/产出比。以设计出具有适当和延展性的架构。简明简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够在满足目的的情况下尽可能的简单明了。但是简单明了的含义究竟是什么好像并没有一个明确的定义。使用模式能够使设计变得简单，但这是建立在我熟悉设计模式的基础上。对于一个并不懂设计模式的人，他会认为这个架构很复杂。对于这种情况，我只能对他说，去看看设计

42、模式。高效：高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些特定的系统来说尤其重要。例如实时系统、高访问量的网站。这些值的是技术上的高效，有时候我们指的高效是效益上的高效。例如，一个只有几十到一百访问量的信息系统，是不是有必要使用 EJB 技术，这就需要我们综合的评估效益了。安全：安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方面。规则规则为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则：功能分解功能分解顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重用目标就是因为我们编写的程序经常处于一种好像是重复的功能，但又有轻微差别的状态中。我们很多时候就

43、会经不住诱惑，用拷贝粘贴再做少量修改的方式完成一个功能。这种行为在 XP 中是坚决不被允许的。XP 提倡“Onceandonlyonce“，目的就是为了杜绝这种拷贝修改的现象。为了做到这一点，我们通常要把功能分解到细粒度。很多的设计思想都提倡小类，为的就是这个#*目的。所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方法的平均代码却会大大的下降。可是，我们怎么知道这个度应该要如何把握呢，关于这个疑问，并没有明确的答案，要看个人的功力和具体的要求，但是一般来说，我们可以用一个简单的动词短语来命名类或方法的，那就会是比较好的分类方法。我们使用功能分解的规则，有助于提高重用性，因为我们每个

44、类和方法的精度都提高了。这是符合大自然的原则的，我们研究自然的主要的一个方向就是将物质分解。我们的思路同样可以应用在软件开发上。除了重用性，功能分解还能实现透明的目标，因为我们使用了功能分解的规则之后，每个类都有自己的单独功能，这样，我们对一个类的研究就可以集中在这个类本身，而不用牵涉到过多的类。根据实际情况决定不同类间的耦合度根据实际情况决定不同类间的耦合度虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦合度。系统之间不可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度的依据何在呢？简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需

45、求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的） ，因为这样可以提高效率，而且我们还可以使用一些更好的技术来提高效率或简化代码，例如 Java 中的内部类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是一组的类（例如 Beans） 。我们可以借用 Java 中的一句话来概括降低耦合度的思想：“针对接口编程，而不是针对实现编程。设计不同的耦合度有利于实现透明和延展。对于类的

46、客户（调用者）来说，他不需要知道过多的细节（实现） ，他只关心他感兴趣的（接口） 。这样，目标类对客户来说就是一个黑盒子。如果接口是稳定的，那么，实现再怎么扩展，对客户来说也不会有很大的影响。以前那种牵一发而动全身的问题完全可以缓#*解甚至避免。其实，我们仔细的观察 GOF 的 23 种设计模式，没有一种模式的思路不是从增加抽象层次入手来解决问题的。同样，我们去观察 Java 源码的时候，我们也可以发现，Java 源码中存在着大量的抽象层次，初看之下，它们什么都不干，但是它们对系统的设计起着重大的作用。够用就好够用就好我们在上一章中就谈过敏捷方法很看重刚好够用的问题，现在我们结合架构设计来看：

47、在同样都能够满足需要的情况下，一项复杂的设计和一项简单的设计，哪一个更好。从敏捷的观点来看，一定是后者。因为目前的需求只有 10项，而你的设计能够满足 100 项的需求，只能说这是种浪费。你在设计时完全没有考虑成本问题，不考虑成本问题，你就是对开发组织的不负责，对客户的不负责。应用模式应用模式这篇文章的写作思路很多来源于对模式的研究。因此，文章中到处都可以看到模式思想的影子。模式是一种整理、传播思想的非常优秀的途径，我们可以通过模式的方式学习他人的经验。一个好的模式代表了某个问题研究的成果，因此我们把模式应用在架构设计上，能够大大增强架构的稳定性。抽象抽象架构的本质在于其抽象性。它包括两个方面

48、的抽象：业务抽象和技术抽象。架构是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解，然后我们还要能够熟练的应用技术来实现现实世界到模型的映射。因此，我们在对业务或技术理解不够深入的情况下，就很难设计出好的架构。当然，这时候我们发现一个问题：怎样才能算是理解足够深入呢。我认为这没有一个绝对的准则。一次，一位朋友问我：他现在做的系统有很大的变化，原先设计的工作流架构不能满足现在的要求。他很希望能够设计出足够好的工作流架构，以适应不同的变化。但是他发现这样做无异于重新开发一个 lotusnotes。我听了他的疑问之后觉得有两点问题：首先，他的开发团队中并没有工作流领域的专家。他的客户虽

49、然了解自己#*的工作流程，但是缺乏足够的理论知识把工作流提到抽象的地步。显然，他本身虽然有技术方面的才能，但就工作流业务本身，他也没有足够的经验。所以，设计出象 notes 那样的系统的前提条件并不存在。其次，开发一个工作流系统的目的是什么。原先的工作流系统运作的不好，其原因是有变化发生。因此才有改进工作流系统的动机出现。可是，毕竟 notes是为了满足世界上所有的工作流系统而开发的，他目前的应用肯定达不到这个层次。因此，虽然做不到最优的业务抽象，但是我们完全可以在特定目的下，特定范围内做到最优的业务抽象。比如说，我们工作流可能的变化是工组流路径的变化。我们就完全可以把工作流的路径做一个抽象，设计一个可以动态改变路径的工作流架构。有些时候，我们虽然在技术上和业务上都有所欠缺，没有办法设计出好的架构。但是我们完全可以借鉴他人的经验，看看类似的问题别人是如何解决的。这就是我们前面提到的模式。我们不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路。MartinFowler 曾说：“模式和业务组件的区别就在于模式会引发你的思考。 ”在分析模式一书中，MartinFowler 提到了分析和设计的区