架构电子政务总体应用架构设计指引

1、长风联盟电子政务总体应用架构设计指南研究报告长风开放标准平台软件联盟二。七年五月目录第一章引论1L1本指南的目的1本指南依据的长风联盟参考文档1什么是SOA电子政务总体应用架构1L4什么是SOA电子政务总体应用架构设计2本指南的章节组织7L6应用架构设计的主要内容7应用架构分解结构与参考架构(RA)7应用架构设计环境8应用架构设计干系人8L10应用架构设计指南与长风联盟其他文档的关系9 第二章应用架构设计知识领域、原则和过程组10应用架构设计知识领域10SOA设计方法学10数据建模方法学10面向流程设计方法学11技术领域架构设计方法学11通用架构设计方法学13向对象设计方法学19服务设计原则2

2、1显式定义边界21自治性23服务共享大纲和契约，但不共享类24服务兼容性基于策略25访问的开放性26随时可用26I 27服务分级28松散耦合282210可重用的服务及服务接I I设计管理29标准化的接I I 29支持各种消息模式30精确定义服务接I I 30应用架构设计过程组31架构启动过程组33述33务模型合理性初步分析34231.3架构范围定义35功能架构35业务分类35架构分析过程组36.2概述36组织模型分析37数据模型分析38流程模型分析385 分析 39外部接I I分析392.327关键用例分析392.328关键技术点分析402.329服务定义40.10干系人分析402.3211外

3、部接I I设计过程412.3212服务设计过程42架构设计过程组422.3.3概述42233.2总体架构设计442.333框架选择442.334数据模型设计442.335流程设计44技术点设计442.337外部接I I设计45UI 设计 462.339服务设计过程46质量设计46设计视图分配462.3312部署视图设计462.3313团队开发管理设计47架构实现过程组47.4概述47工作绩效信息收集47架构实现47235架构测试过程组47概述472.352测试规划482.353服务测试482.354功能测试482.355性能测试492.356技术指标测试492.357架构优化49架构监控过程组

4、49.6概述492.362业务模型合理性跟踪492.363绩效报告50237架构收尾过程组50.7概述50管理收尾50架构进化50第三章应用架构分解结构50总体架构50基础支撑层51全景图51硬件/网络层设计52主机设计53网络规划55存储/备份设计55其它硬件设备583.2.3系统软件层设计58操作系统选型58应用服务器选型59数据库服务器选型60其它系统软件选型613.2.4支撑软件层设计61技术架构选择61软件框架设计64基础构件/服务设计64A其它构件64与架构其它层关系64相关规范与标准65务运行、管理和监控环境653.3政务资源层65政务资源层总体架构65统资源层面临的问题65架构

5、目标66架构总图及描述66务资源层应用前景和趋势67政务信息资源68政务信息资源的封装68政务信息资源的接入69政务信息资源的管理69政务信息资源的访问703.3.3部门业务应用资源71应用资源的封装71333.2应用资源的接入723.333应用资源的管理723.334应用资源的统一访问73政务目录资源733.3.4资源元数据描述74334.2资源编目76334.3安全管理773.344基于目赢资源共享体系773.4支撑服务层79全景图79描述 79服务构成803.4.3公共服务80343.2领域服务873.5业务应用层89全景图89描述 89基于SOA业务应用层的业务应用模式90从软基础设施

6、的视角研究模式分类91基于SOA的资源共享应用模式933.533基于SOA的业务协同应用模式94基于SOA的不同服务渠道的应用模式943.5.4与其它各层的关系95354.1业务应用层对基础支撑层的要求953.542业务应用层对展现服务层的支持963.543业务应用层对安全保障体系的要求96展现服务层97全景图97362适配器98363支撑运行环境98具体的展现服务99365展现服务相关的标准体系、工具集、安全保障体系99工具集100全景图1012开发和部署服务1013.721服务的体系架构/模型1033.722体系架构说明1043.723功能模块概述1043.724功能模块间关系概述1053

7、.725功能详细说明1053.726与其他服务关系108标准规范体系110全景图110基础支撑层110政务资源层113支撑服务层114业务应用层118展现服务层118安全保障体系119安全保障体系121 全景图121391.2安全在整个SOA体系中的作用和位置1233.9.L3安全保障体系的总体逻辑框架124391.4安全保障体系中采用的标准规范体系框架图1253.9.2 SOA安全实施要点及方法125392.1端到端SOAP消息交换的安全1253.922 Web服务策略机制126392.3令牌转换和信任域1273.924安全对话128392.5跨域的互信任操作1293.926 SOA系统的安

8、全管理制度130第四章 应用架构设计路线图130全景图130基础 SOA132网络化SOA132流程支撑的SOA133附录A术语表136附录B架构设计资料参考137附录C案例描述-137 -第一章引论本指南的目的基本目的是识别SOA电子政务领域应用架构设计知识体系普遍公认为 良好做法的那一部分。识别,指一般概括性介绍，而非详尽无遗漏的说明。哥遇公认，指介绍的知识和做法在绝大多数情况下适用于绝大多数的架 构设计，其价值和实用性也得到了人们的广泛认同。良好做法指一致认为,正确应用这些技能、工具和技术能够增加范围 极为广泛的各种不同架构设计成功的机会。良好做法并不是说这些知识和做 法一成不变地应用于

9、或应当应用于所有的架构设计：架构设计团队负责架构的裁剪和扩展。本指南还旨在作为该职业和实践一个共同的求通匚编，为讨论、书写和 应用架构设计方面的问题提供便利。这种术语汇编是一种职业必不可少的组 成部分。本指南还提供了一个参考的电子政务应用架痴并结合一个具体案例讲 解如何在电子政务领域进行基于SOA的应用架构设计。本指南用来指导电子政务领域政务系统建设和政务系统之间的整合任务 的架构设计。而附录B列出了架构设计资料的其他来源。本指南依据的长风联盟参考文档SOA-RA-TF制定的SOA参考架构白皮书SOA-AP-TF制定的SOA电子政务总体技术架构与解决方案什么是SOA电子政务总体应用架构长风联盟

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

11、。其中:质量属性（按各种角度分类的属性。譬如：1按生命周期划分会有设计期，开发期，运 （行期，测试期，维护期质量非功能需求2定量属性和定性属性，可用性、可修改性、 性能、安全、有效性、可测试性、可监控 性、可追溯性、可升级性、可扩张性、可维 护性、可管理性、可复用性、模块独立交付 性等）约束卜面介绍几个通常会在系统设计中涉及的质量属性。.性能指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统 反应时间以及处理交易量的能力等。通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能；也 可以通过系统能够处理的交易量（每秒）来衡量系统的性能。对于架构设计师 来说，无论采取哪种衡量系统

12、性能的方法来构建系统架构，这些对于性能的 考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构 性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的 事情。在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提 供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和 服务器来回很多次的远程函数调用才能完成。在Intranet的环境下，这些 调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在 基于SOA的架构中使用了很多Web Service来作为服务提供点的话,我们 就需要考虑性能的影响，尤其是在Internet环境下，这

13、些往往是决定整个 系统是否能正常工作的一个关键决定因素。因此在基于SOA的系统中，推 荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息 交换。这样做可以在一定程度上提高系统的整体性能。.可升级性指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个 系统的架构。当基于SOA的系统中负荷增大时，如果系统的响应时间仍能够在可接 受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可 升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在 保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用 户数量。如果系统运转时已经不能在可接受时间范

14、围内反应，那么这个系统 已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你 必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级 包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新 的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计出 来的架构必须能够处理对硬件的垂直或者水平升级。基于SOA的系统架构 可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经 被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之 下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整 体的架构。.可靠性指确保各应用及其

15、相关的所有交易的完整性和一致性的能力。当系统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够 象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限 制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际 上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠 的系统。在基于SOA来构建系统架构的时候，可靠性也是必须要着重考虑 的问题。要在基于SOA架构的系统中保证一定的系统可靠性，就必须要首 先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由 其部署的应用服务器或Web服务器来保证。只有确保每一个SOA系统中的 服务都具有较高的可靠

16、性，我们才能保证系统整体的可靠性能够得以保障。 4.可用性指确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不 一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽 然一个单独的组件的错误会对系统的可靠性产生不良的影响，但由于系统冗 余的存在，使得整个系统服务仍然可用。在基于SOA来构建系统架构的时 候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的 技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架 的容错或者冗余机制来实现对服务可用性的支持;第二种是通过UDDI等动态 查找匹配方式来支持系统

17、整体的高可用性。在SOA架构设计师构建企业系 统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的SOA系 统架构中的关键性业务能具有较高的可用性。.可扩展性指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功 能的能力。当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须 去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展 性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性, 都应该考虑下面几个要素:低耦合，界面(mteifaces)以及封装。当架构设计师 基于SOA来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方 面的要素。

18、这是因为SOA架构中的不同服务之间本身就保持了一种无依赖 的低耦合关系;服务本身是通过统一的接口定义(可以是WSDL)语言来描述 具体的服务内容，并且很好地封装了底层的具体实现。.可维护性指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能 力。当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护 性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面 几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已 经提到了 SOA架构能为系统中暴露出来的各个子功能模块也就是服务带 来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文 档外，

19、基于SOA的系统还会引用到许多系统外部的由第三方提供的服务， 因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整 个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关 的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、 具体性能测试结果等各种相关文档。基于这些文档，就可以为SOA架构设 计师构建企业SOA架构提供很好的文档参考和支持。.可管理性指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全 性的能力。具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，通 过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系

20、统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配 置管理的功能。在对复杂系统进行系统架构建模时，SOA架构设计师应该 尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架 (Fiamewoik)_t。.安全性指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅 要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝 (Denial-of-Service)攻击。这就要求当SOA架构设计师在构建一个架构时， 应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块 暴露为外部用户可见的服务的时候，要围绕各个子模块构

21、建各自的安全区， 这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也 可以保证其他模块相对安全。如果企业SOA架构中的一些服务是由 WebSemce实现的，在考虑这些服务安全性的时候也要同时考虑效率的问 题，因为WS-Secunty会为Web Seivice带来一定的执行效率损耗。高质量的架构设计还考虑了技术风险应对的因素。应对变化，权衡不变与变化是架构设计永恒的主题。架构设计中还必须考虑SOA的独特性,例如：服务分类方法等。臼按服务在系统建设中的用途划分：2按服务的功能划分：服务：数据中心的服务和逻辑中心的服务服务：技术网关、适配器、外观、装饰服务程为中心的服务企业服务：为跨

22、企业集成提供接口，例如SMS、Email等 员外应用程序前端是SOA的激活元素。本指南的章节组织主要分4章介绍。第1章引论第2章应用架构设计知识领域、设计原则和过程组第3章应用架构分解结构第4章 应用架构设计路线图应用架构设计的主要内容依据SOA-RA-TF的参考架构，解决电子政务应用领域如何产出一个SOA 应用架构的问题：架构的生命期构成整体架构设计过程组架构分解结构（五横三纵架构）知识领域:服务参考模型架构侧面系（生命周期模型和4+1视图）应用架构分解结构与参考架构（RA）应用架构分解结构中的基础支撑层中的系统软件尽量按照RA标准实现，如 不能满足，架构上应考虑松耦合的互连互通，保障符合R

23、A标准的服务库和应用 系统能够和本应用架构协同。另外RA为应用架构分解结构中的服务开发运行体系提供支撑机制，如ESB 等。应用架构设计环境本指南假定架构设计在项目环境下进行。应用架构设计受到一定环境因素的影响和约束，并反过来对这些因素产生影 响：应用领域标准规范组织过程资产公司战略要求技术环境项目要求管理因素架构设计和项目管理和组织日常运作管理是密切相关的，但本指南不涉及相 关内容，请参考相关书籍和文献资料。应用架构设计干系人架构设计要考虑架构设计干系人的要求。高层管理人员项目发起人项目经理架构设计师需求人员开发人员测试人员客户1.10应用架构设计指南与长风联盟其他文档的关系第二章应用架构设计

24、知识领域、原则 和过程组应用架构设计知识领域SOA设计方法学SOA设计方法并非全新的方法论，而是继承了传统的面向对象的设计方法 以及面向过程的设计方法，同时乂增加了 SCA, SDO, BPEL等技术，融入了 面向服务的设计方法，服务参考模型OASIS RM里的内容映射，具体内容包括 服务定义、服务设计、服务管理、服务开发、服务测试和服务部署。数据建模方法学传统的数据建模方法学是面向一个应用系统内部的实体的建模方法学，而在 当前数据整合、应用整合的需求下，数据建模还要考虑在不同系统间进行数据交 换和数据共享的需求。基于业务效率的考虑，从业务流程出发的思路改变了数据模型。只有你从业务流程的角度来

25、看待数据的时候，数据模型才能算真正完成。面向流程设计方法学阐述了一种以实现流程优化的流程系统设计思想。这种设计思想是面向业务 流程的，不同于传统MIS系统面向部门职能的设计思想。首先把系统设计区分 为原理层设计和技术层设计两个层次，然后从业务流程设计、数据模型设计和技 术架构设计三个方面论述了原理层设计的基本思想。技术领域架构设计方法学大型IT系统的设计通常遵循七层架构的设计方法，包括：界面层该层是直接面向用户（包括公众、企业、业务人员、行政管理人员、领导 等使用者）的统一的系统界面。界面层利用业界主流的IT技术支持多种渠道接 入和交互（如互联网、电话、手机短信等接入方式），以及统一的身份认证

26、及权 限管理。应用层应用层提供所有的信息应用和系统管理的业务逻辑，分解业务请求，通过 应用支撑层进行数据处理，并将返回信息组织成所需的格式提供给客户端。应 用系统分为四大部分： 面向公众和企业的外网应用一一审批门户（网上审批系统前台），提供 网上申报和反馈查询等在线服务功能；面向公务员的审批服务平台，实现业务审批、监督检察、业务调度、决 策支持等功能；面向公务员的政府资源共享平台（数据共享与交换平台），实现基于审 批业务的数据交换与基于委办局现有信息资源的数据共享使用等功能。面向公务员的开放办公平台，实现基于开放的桌面办公系统，实现对审 批过程数据的保存及归档等。应用支撑层应用支撑层构建在J2

27、EE应用服务器之上，提供了一个应用基础平台DC-BPIP,并提供大量公共服务和业务构件，提供构件的运行、开发和管理环境, 最大限度提高开发效率，降低工程实施、维护的成本和风险。应用支撑层采用了 行业应用的先进体系结构，以建立高性能、高可靠性、高扩展性的应用系统，满 足客户快速发展的业务需求。信息资源层信息资源层是整个系统的信息资源中心，涵盖全市所有与行政审批相关的 结构化和非结构化数据。它是企业信息资源的存储和积累，为系统应用提供数 据访问服务、备份、存储功能。IT基础平台层IT基础平台为系统的软硬件以及网络基础平台，分为三个部分：系统软件、 硬件支撑平台、和网络支撑平台。其中，系统软件包括中

28、间件、数据库服务器软 件等；硬件支撑平台包括：主机、存储、备份等硬件设备；网络支撑为系统运行 所依赖的网络环境。它对上层应用起到技术支撑作用 支撑体系层系统建设和推广运行仅仅依赖应用系统建设、硬件网络建设是不够的，需要 在系统安全方面、标准化方面、以及系统运维三个不同层面的工作来共同支撑。 只有这样，才能使系统建设顺利进行，也才能保证系统能顺利推广、稳定运行。 法律法规层以上各个层面的建设，需要依托于现有的法律、法规及一些规范才可成功运 行。系统的分析、设计、实施都必须充分考虑这些因素。只有切实符合这些规范, 系统才能与建设单位共同发展，得到各级用户的认可。而利用RUP的设计思想，则将架构设计

29、概括为4+1视图：逻辑视图逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用 户功能而必须提供的”辅助功能模块”；它们可能是逻辑层、功能模块等。 开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直 接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的 系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比 如逻辑层一般会映射到多个程序包等。处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、 同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包 在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、 进

30、程，处理视图比较关注的正是这些运行时单元的交互问题。物理视图。物理视图关注”目标程序及其依赖的运行库和系统软件”最终如何 安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠 性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标 程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图 是综合考虑软件系统和整个IT系统相互影响的架构视图。场景视图。关注业务的应用场景。通用架构设计方法学架构设计是一种权衡(ade-off)。一个问题总是有多种的解决方案。而 我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之 间做出一个权衡。我们在设计的过程总是

31、可以看到很多的矛盾体：开放和整 合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对 软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影 响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计 的复杂度。没有一个软件能够满足所有的要求，因为这些要求之间带有天生 的互斥性。而我们评价架构设计的好坏的依据，就只能是根据不同要求的轻 重缓急，在其间做出权衡的合理性。目标我们希望一个好的架构能够：重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、 之前的设计。重用是我们不断追求的目标之一，但事实上，做到这一点可没有那 么容易。在现实中，人们已经

32、在架构重用上做了很多的工作，工作的成果称为框 架(Frame work),比如说Windows的窗口机制、J2EE平台等。但是在企业商业 建模方面，有效的框架还非常的少。透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把客户需 求的接口呈现给客户。这样，具体的实现对客户来说就是透明的。一个具体的例 子是我们使用JSP的tag技术来代替JSP的嵌入代码，因为我们的HTML界面人 员更熟悉tag的方式。延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一定的延 展性，以适应未来可能的变化。可是，如上所说，延展性和稳定性，延展性和简 单性都是矛盾的。因此我们需要权衡我们的投入/产出

33、比。以设计出具有适当和 延展性的架构。简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够 在满足目的的情况下尽可能的简单明了。但是简单明了的含义究竟是什么好像并 没有一个明确的定义。使用模式能够使设计变得简单，但这是建立在我熟悉设计 模式的基础上。对于一个并不懂设计模式的人，他会认为这个架构很复杂。对于 这种情况，我只能对他说，去看看设计模式。高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些特定的 系统来说尤其重要。例如实时系统、高访问量的网站。这些值的是技术上的高效, 有时候我们指的高效是效益上的高效。例如，一个只有几十到一百访问量的信息 系统，是不是有必要使用E

34、JB技术，这就需要我们综合的评估效益了。安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方面。 规则为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则：功能分解顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重用目标 就是因为我们编写的程序经常处于一种好像是重复的功能，但乂有轻微差别的状 态中。我们很多时候就会经不住诱惑，用拷贝粘贴再做少量修改的方式完成一个 功能。这种行为在XP中是坚决不被允许的。XP提倡“Onceandonlyonce”，目的 就是为了杜绝这种拷贝修改的现象。为了做到这一点，我们通常要把功能分解到 细粒度。很多的设计思想都提倡小类，为的就是这个

35、目的。所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方法的平 均代码却会大大的下降。可是，我们怎么知道这个度应该要如何把握呢，关于这 个疑问，并没有明确的答案，要看个人的功力和具体的要求，但是一般来说，我 们可以用一个简单的动词短语来命名类或方法的，那就会是比较好的分类方法。我们使用功能分解的规则，有助于提高重用性，因为我们每个类和方法的精 度都提高了。这是符合大自然的原则的，我们研究自然的主要的一个方向就是将 物质分解。我们的思路同样可以应用在软件开发上。除了重用性，功能分解还能 实现透明的目标，因为我们使用了功能分解的规则之后，每个类都有自己的单独 功能，这样，我们对一个类的研

36、究就可以集中在这个类本身，而不用牵涉到过多 的类。根据实际情况决定不同类间的耦合度虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦合度。 系统之间不可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度 的依据何在呢？简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳 定性高的需求，不容易发生变化的需求，我们完全可以把各类设计成紧耦合的（我 们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的）, 因为这样可以提高效率，而且我们还可以使用一些更好的技术来提高效率或简化 代码，例如Java中的内部类技术。可是，如果需求极有可能变化，我们就需要 充分的考虑

37、类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度， 但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具 体的类，也可以是接口，或是一组的类（例如Beans）。我们可以借用Java中的 一句话来概括降低耦合度的思想：”针对接口编程，而不是针对实现编程。设计不同的耦合度有利于实现透明和延展。对于类的客户（调用者）来说， 他不需要知道过多的细节（实现），他只关心他感兴趣的（接口）。这样，目标类 对客户来说就是一个黑盒子。如果接口是稳定的，那么，实现再怎么扩展，对客 户来说也不会有很大的影响。以前那种牵一发而动全身的问题完全可以缓解共至 避免。其实，我们仔细的观察GOF的

38、23种设计模式，没有一种模式的思路不是从 增加抽象层次入手来解决问题的。同样，我们去观察Java源码的时候，我们也 可以发现，Java源码中存在着大量的抽象层次，初看之下，它们什么都不干，但 是它们对系统的设计起着重大的作用。够用就好我们在上一章中就谈过敏捷方法很看重刚好够用的问题，现在我们结合架构 设计来看：在同样都能够满足需要的情况下，一项复杂的设计和一项简单的设计, 哪一个更好。从敏捷的观点来看，一定是后者。因为目前的需求只有10项，而 你的设计能够满足100项的需求，只能说这是种浪费。你在设计时完全没有考虑 成本问题，不考虑成本问题，你就是对开发组织的不负责，对客户的不负责。应用模式这

39、篇文章的写作思路很多来源于对模式的研究。因此，文章中到处都可以看 到模式思想的影子。模式是一种整理、传播思想的非常优秀的途径，我们可以通 过模式的方式学习他人的经验。一个好的模式代表了某个问题研究的成果，因此 我们把模式应用在架构设计上，能够大大增强架构的稳定性。抽象架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。 架构是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解， 然后我们还要能够熟练的应用技术来实现现实世界到模型的映射。因此，我们在 对业务或技术理解不够深入的情况下，就很难设计出好的架构。当然，这时候我 们发现一个问题：怎样才能算是理解足够深入呢。我认

40、为这没有一个绝对的准则。一次，一位朋友问我：他现在做的系统有很大的变化，原先设计的工作流架 构不能满足现在的要求。他很希望能够设计出足够好的工作流架构，以适应不同 的变化。但是他发现这样做无异于重新开发一个lotusnotes。我听了他的疑问之 后觉得有两点问题：首先，他的开发团队中并没有工作流领域的专家。他的客户虽然了解自己的 工作流程，但是缺乏足够的理论知识把工作流提到抽象的地步。显然，他本身虽 然有技术方面的才能，但就工作流业务本身，他也没有足够的经验。所以，设计 出象notes那样的系统的前提条件并不存在。其次，开发一个工作流系统的目的是什么。原先的工作流系统运作的不好， 其原因是有变

41、化发生。因此才有改进工作流系统的动机出现。可是，毕竟notes 是为了满足世界上所有的工作流系统而开发的，他目前的应用肯定达不到这个层 次。因此，虽然做不到最优的业务抽象，但是我们完全可以在特定目的下，特定 范围内做到最优的业务抽象。比如说，我们工作流可能的变化是工组流路径的变 化。我们就完全可以把工作流的路径做一个抽象，设计一个可以动态改变路径的 工作流架构。有些时候，我们虽然在技术上和业务上都有所欠缺，没有办法设计出好的架 构。但是我们完全可以借鉴他人的经验，看看类似的问题别人是如何解决的。这 就是我们前面提到的模式。我们不要把模式看成是一个硬性的解决方法，它只是 一种解决问题的思路。Ma

42、rtinFowlei-曾说：“模式和业务组件的区别就在于模式 会引发你的思考。”在分析模式一书中，MaihnFowle提到了分析和设计的区别。分析并不 仅仅只是用用例列出所有的需求，分析还应该深入到表面需求的的背后，以得到 关于问题本质的MentalModel。然后，他引出了概念模型的概念。概念模型就类 似于我们在讨论的抽象。MartinFowle提到了一个有趣的例子，如果要开发一套 软件来模拟桌球游戏，那么，用用例来描述各种的需求，可能会导致大量的运动 轨迹的出现。如果你没有了解表面现象之后隐藏的运动定律的本质，你可能永远 无法开发出这样一个系统。关于架构和抽象的问题，在后面的文章中有一个测

43、量模式的案例可以很形象 的说明这个问题。架构的一些误解我们花了一些篇幅来介绍架构的一些知识。现在回到我们的另一个主题上 来。对于一个敏捷开发过程，架构意味着什么，我们该如何面对架构。这里我们 首先要澄清一些误解：误解L架构设计需要很强的技术能力。从某种程度来说，这句话并没有很 大的错误。毕竟，你的能力越强，设计出优秀架构的几率也会上升。但是能力和 架构设计之间并没有一个很强的联系。即使是普通的编程人员，他一样有能力设 计出能实现目标的架构。误解2：架构由专门的设计师来设计，设计出的蓝图交由程序员来实现。我 们之所以会认为架构是设计师的工作，是因为我们喜欢把软件开发和建筑工程做 类比。但是，这两

44、者实际上是有着很大的区别的。关键之处在于，建筑设计已经 有很长的历史，已经发展出完善的理论，可以通过某些理论（如力学原理）来验 证设计蓝图。可是，对软件开发而言，验证架构设计的正确性，只能够通过写代 码来验证。因此，很多看似完美的架构，往往在实现时会出现问题。误解3：在一开始就要设计出完善的架构。这种方式是最传统的前期设计方 式。这也是为XP所摒弃的一种设计方式。主要的原因是，在一开始设计出完美 的架构根本就是在自欺欺人。因为这样做的基本假设就是需求的不变性。但需求 是没有不变的（关于需求的细节讨论，请参看拙作需求的实践）。这样做的坏 处是，我们一开始就限制了整个的软件的形状。而到实现时，我们

45、虽然发现原来 的设计有失误之处，但却不愿意面对现实。这使得软件畸形的生长。原本一些简 单的问题，却因为别扭的架构，变得非常的复杂。这种例子我们经常可以看到， 例如为兼容前个版本而导致的软件复杂性。而2000年问题，TCP/IP网络的安全 性问题也从一个侧面反映了这个问题的严重性。误解4：架构蓝图交给程序员之后，架构设计师的任务就完成了。和误解2 一样，我们借鉴了建筑工程的经验。我们看到建筑设计师把设计好的蓝图交给施 工人员，施工人员就会按照图纸建造出和图纸一模一样的大厦。于是，我们也企 图在软件开发中使用这种模式。这是非常要命的。软件开发中缺乏一种通用的语 言，能够充分的消除设计师和程序员的沟

46、通隔阂。有人说，UML不可以吗？ UML 的设计理念是好的，可以减轻沟通障碍问题。可是要想完全解决这个问题，UML 还做不到。首先，程序员都具有个性化的思维，他会以自己的思维方式去理解设 计，因为从设计到实现并不是一项机械的劳动，还是属于一项知识性的劳动（这 和施工人员的工作是不同的）。此外，对于程序员来说，他还极有可能按照自己 的想法对设计图进行一定的修改，这是非常正常的一项举动。更糟的是，程序员 往往都比较自负，他们会潜意识的排斥那些未经过自己认同的设计。架构设计的过程模式通常我们认为模式都是用在软件开发、架构设计上的。其实，这只是模式的 一个方面。模式的定义告诉我们，模式描述了一个特定环

47、境的解决方法，这个特 定环境往往重复出现，制定出一个较好的解决方法有利于我们在未来能有效的解 决类似的问题。其实，在管理学上，也存在这种类似的这种思维。称为结构性问 题的程序化解决方法。所以呢，我们完全可以把模式的思想用在其它的方面，而 目前最佳的运用就是过程模式和组织模式。在我们的文章中，我们仅限于讨论过 程模式。我们讨论的过程仅限于面向对象的软件开发过程。我们称之为OOSP (object-onentedsoftwarepiocess)。因为我们的过程需要面向对象特性的支持。当 然，我们的很多做法一样可以用在非OO的开发过程中，但是为了达到最佳的效 果，我建议您使用OO技术。面向对象设计方

48、法学面向对象方法(Obj ect-Onented Method)是一种把面向对象的思想应用于 软件开发过程中，指导开发活动的系统方法，简称OO(Object-O口ented)方法, 是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的 封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一 组对象。而每继承性是对具有层次关系的类的属性和操作进行共享的一种方 式。所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机 制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。面向对象方法作为一种新型的独具优越性的新方法正引起全世界越来 越广泛的关注和高度的重视，

49、它被誉为”研究高技术的好方法”，更是当前计 算机界关心的重点。十多年来，在对OO方法如火如荼的研究热潮中，许多 专家和学者预言：正像70年代结构化方法对计算机技术应用所产生的巨大 影响和促进那样，90年代OO方法会强烈地影响、推动和促进一系列高技术 的发展和多学科的综合。用计算机解决问题需要用程序设计语言对问题求解加以描述(即编程), 实质上，软件是问题求解的一种表述形式。显然，假如软件能直接表现人求 解问题的思维路径(即求解问题的方法)，那么软件不仅容易被人理解，而 且易于维护和修改，从而会保证软件的可靠性和可维护性，并能提高公共问 题域中的软件模块和模块重用的可靠性。面向对象的机能念和机制

50、恰好可以 使得按照人们通常的思维方式来建立问题域的模型，设计出尽可能自然地表 现求解方法的软件。面向对象的基本概念：对象：对象是要研究的任何事物。从一本书到一家图书馆，单的整数到 整数列庞大的数据库、极其复杂的自动化工厂、航天飞机都可看作对象，它 不仅能表示有形的实体，也能表示无形的（抽象的）规则、计划或事件。对 象由数据（描述事物的属性）和作用于数据的操作（体现事物的行为）构成 一独立整体。从程序设计者来看，对象是一个程序模块，从用户来看，对象 为他们提供所希望的行为。在对内的操作通常称为方法。类：类是对象的模板。即类是对一组有相同数据和相同操作的对象的定 义，一个类所包含的方法和数据描述一

51、组对象的共同属性和行为。类是在对 象之上的抽象，对象则是类的具体化，是类的实例。类可有其子类，也可有 其它类，形成类层次结构。消息：消息是对象之间进行通信的一种规格说明。一般它由三部分组成: 接收消息的对象、消息名及实际变元。面向对象主要特征：封装性：封装是一种信息隐蔽技术，它体现于类的说明，是对象的重要 特性。封装使数据和加工该数据的方法（函数）封装为一个整体，以实现独 立性很强的模块，使得用户只能见到对象的外特性（对象能接受哪些消息， 具有那些处理能力），而对象的内特性（保存内部状态的私有数据和实现加 工能力的算法）对用户是隐蔽的。封装的目的在于把对象的设计者和对象者 的使用分开，使用者不

52、必知晓行为实现的细节，只须用设计者提供的消息来 访问该对象。继承性：继承性是子类自动共享父类之间数据和方法的机制。它由类的 派生功能体现。一个类直接继职其它类的全部描述，同时可修改和扩充。继职具有传达室递性。继职分为单继承（一个子类只有一父类）和多重 继承（一个类有多个父类）。类的对象是各自封闭的，如果没继承性机制， 则类对象中数据、方法就会出现大量重复。继承不仅支持系统的可重用性， 而且还促进系统的可扩充性。多态性：对象根据所接收的消息而做出动作。同一消息为不同的对象接 受时可产生完全不同的行动，这种现象称为多态性。利用多态性用户可发送 一个通用的信息，而将所有的实现细节都留给接受消息的对象

53、自行决定，如 是，同一消息即可调用不同的方法。例如：Punt消息被发送给一图或表时调 用的打印方法与将同样的Print消息发送给一正文文件而调用的打印方法会 完全不同。多态性的实现受到继承性的支持，利用类继承的层次关系，把具 有通用功能的协议存放在类层次中尽可能高的地方，而将实现这一功能的不 同方法置于较低层次，这样，在这些低层次上生成的对象就能给通用消息以 不同的响应。在OOPL中可通过在派生类中重定义基类函数（定义为重载函 数或虚函数）来实现多态性。综上可知，在OO方法中，对象和传递消息分别表现事物及事物间相互 联系的概念。类和继承是是适应人们一般思维方式的描述范式。方法是允许 作用于该类

54、对象上的各种操作。这种对象、类、消息和方法的程序设计范式 的基本点在于对象的封装性和类的继承性。通过封装能将对象的定义和对象 的实现分开，通过继承能体现类与类之间的关系，以及由此带来的动态联编 和实体的多态性，从而构成了面向对象的基本特征。服务设计原则显式定义边界通过跨越定义明确的边界进行显式消息传递，服务得以彼此交互。有时 候，跨越服务边界可能要耗费很大的成本，这要视地理、信任或执行因素而 定。边界是指服务的公共接口与其内部专用实现之间的界线。服务的边界通 过WSDL发布，可能包括说明特定服务之期望的声明。跨越边界的代价是 高吊的因为：目标服务的物理位置可能是未知的因素。安全和信任模型可能会

55、在每次跨越边界时发生改变。在服务的公共表示和专用表示之间封送和转换数据可能需要依赖额外 的资源：其中一些资源可能在服务之外。服务的构建要考量持久性，而服务配置的构建则要考量变化性。这一事 实暗示着：由于网络重新配置或者迁移到另一个物理位置，可靠的服务的性 能可能会突然降低。服务的使用者通常不知道专用的内部过程是如何实现的。特定服务的使用者对正使用的服务的性能只能进行有限的控制。服务调用可能会受到网络滞后、网络故障和分布式系统故障的影响，而 本地实现则不会。要预先考虑使用远程对象接口的影响，就必须编写大量的 错误检测和更正逻辑。尽管跨越边界是代价高昂的过程，但在部署用于将此 类边界跨越减至最少的

56、本地方法时，还是要格外谨慎。实现单一性本地方法 和对象的系统可能会获得性能的改善，但功能性却与先前定义的服务完全一 样。弄清边界。服务提供一个契约来定义其提供的公共接口。与服务的 所有交互都通过公共接口进行。接口由公共进程和公共数据表示组成。公共 进程是通向服务内部的入口点，而公共数据表示则是指该进程使用的消息。 如果我们使用WSDL代表一个简单的契约，则message代表公共数据, 而vportType代表公共进程。文章”外部数据与内部数据”（英文）更详细 地研究了这些问题。服务应易于使用。设计服务时，开发人员应使其易于其他开发人员 使用。设计的服务接口（契约）也应允许服务在不中断与现有使用

57、者之间的 契约的情况下进一步发展。（这一主题将在本系列的后续文章中更详细地讨 论。）避免使用RPC接口。应采用显式消息传递，而避免使用RPC之类 的模型。这种方法将使用者与服务实现的内部隔离开来，使开发人员可以集 中精力改进他们的服务，同时将对服务使用者的影响降至最低（使用公共消 息而不是公用的方法进行封装）。尽量减小服务的表面积。服务的公共接口越多，就越难以使用和维 护。应当少提供服务的定义明确的公共接口。这些接口应该相对简单，主要 用于接受定义明确的输入消息并以同样定义明确的输出消息进行响应。这些 接口一旦定义，即应保持不变。这些接口提供服务必须支持的“恒定不变” 的设计要求，为服务专用的

58、内部实现充当门面。内部（专用）实现的细节不应泄露到服务边界之外。如果将实现细 节泄露到服务边界，很可能会使服务与服务使用者之间的耦合更加紧密。服 务使用者不应当获知服务实现的内部情况，因为这样会使服务的版本更新或 升级受到限制。2.2.2自治性服务是独立进行部署、版本控制和管理的实体。开发人员应避免对服务 边界之间的空间进行假设，因为此空间比边界本身更容易改变。例如，服务 边界应当是不变的，只有这样才能将版本更新对使用者的影响降至最低。虽 然服务边界是相当稳定的，但策略、物理位置或网络拓扑等服务部署选项却 很可能发生改变。服务可以通过URI动态寻址，使其底层位置和部署拓扑可以在几乎不 影响服务

59、本身的情况下改变或演化（服务的通信通道也是如此）。尽管这些 更改对服务没什么影响，但它们对使用服务的应用程序却有着破坏性的影 响。如果您今天使用的服务明天被移动到新西兰，将会怎样呢？响应时间的 改变可能会对服务的使用者造成计划之外或意料之外的影响。服务设计者对 于服务的使用方式应当采取谨慎的态度：服务将失败，其相关的行为（服务 级别）可能会被更改。适当级别的例外处理和补偿逻辑必须与任何服务调用 相关联。此外，服务使用者可能需要修改其策略，以声明要使用的最短服务 响应时间。例如，服务使用者可以对安全、性能、事务及许多其他因素请求 不同的服务级别。可配置的策略允许单个服务支持多个有关服务调用的 S

60、LA （而其他策略可能主要关注版本更新、本地化及其他问题）。服务级的 通信性能期望始终是自治，因为服务彼此之间不需要熟悉对方的内部实现。不止是服务使用者应该对性能采取谨慎的态度：服务提供者在预测其服 务的使用方式时也应同样谨慎。应该预料到服务使用者有时候会失败，却乂 不通知服务本身。服务提供者也不能信任使用者总是“为所应为”。例如，使 用者可能会尝试使用不正常的/恶意的消息进行通信，或者尝试违反成功实现 服务交互所必需的其他策略。无论用户意图如何，服务内部都必须尝试对此 类不恰当的使用进行补偿。虽然服务是自治的，但任何服务都不是孤岛。基于SOA的解决方案是 不规则的，由许多为特定解决方案配置的