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

长风联盟电子政务

总体应用架构设计指南研究报告

长风开放标准平台软件联盟

二。o七年五月

目录

第一章引论1

L1本指南的目的1

1.2本指南依据的长风联盟参考文档1

1.3什么是SOA电子政务总体应用架构1

L4什么是SOA电子政务总体应用架构设计2

1.5本指南的章节组织7

L6应用架构设计的主要内容7

1.7应用架构分解结构与参考架构(RA)7

1.8应用架构设计环境8

1.9应用架构设计干系人8

L10应用架构设计指南与长风联盟其他文档的关系9第二章应用架构设计知识

领域、原则和过程组10

2.1应用架构设计知识领域10

2.1.1SOA设计方法学。

2.1.2数据建模方法学数

2.1.3面向流程设计方法学11

2.1.4技术领域架构设计方法学11

2.1.5通用架构设计方法学13

2.1.6向对象设计方法学19

2.2服务设计原则21

2,2.1显式定义边界21

222自治性

2.2.3服务共享大纲和契约，但不共享类24

2.2.4服务兼容性基于策略27-

2.2.5访问的开放性26

2.2.6随时可用26

2.2.7127

228服务分级28

2.2.9松散耦合28

2210可重用的服务及服务接II设计管理29

2.2.11标准化的接II29

2212支持各种消息模式30

2.2.13精确定义服务接II30

2.3应用架构设计过程组31

2.3,1架构启动过程组33

述_33

231.2务模型合理性初步分析34

231.3架构范围定义35

功能架构35

231.5业务分类35

2.3.2架构分析过程组36

1.1.2」概述荻"

2.322组织模型分析37

2.323数据模型分析38

2.324流程模型分析38

2.3255分析39

2.326外部接II分析39

2.327关键用例分析用

2.328关键技术点分析40

2.329服务定义40

2.327.10干系人分析40

2.3211外部接11设计过程41

2.3212月艮务设计过程42

2.3.3架构设计过程组42

2.3.3」概述4厂

233.2总体架构设计44

2.333框架选择44

2.334数据模型设计44

2.335流程设计44

技术点设计44

2.337外部接II设计45

UI设计46

2.339服务设计过程46

LL1.10质量设计46

1设计视图分配46

2.3312部署视图设计46

2.3313团队开发管理设计47

2.3.4架构实现过程组47

L1.4」概述万-

1.2工作绩效信息收集47

L3架构实现47

235架构测试过程组47

2.3.5」概述E

2.352测试规划48

2.353服务测试48

2.354功能测试48

2.355性能测试49

2.356技术指标测试49

2.357架构优化49

2.3.6架构监控过程组49

1.1.6」概述49

2.362业务模型合理性跟踪49

2.363绩效报告50

237架构收尾过程组50

1.2.7」概述

1.3钟理收-50

1.4架构进化50

第三章应用架构分解结构50

3.1总体架须0

3.2基础支撑层51

3.2.1全景图51

3.2.2硬件/网络层设计52

3.221主机设计53

3.222网络规划55

3.223存储/备份设计55

3.224其它硬件设备58

3.2.3系统软件层设计58

323.1操作系统选型58

323.2应用服务器选型59

323.3数据库服务器选型60

323.4其它系统软件选型61

324支撑软件层设计61

3.2.4」技术架构选择61

3.2.5软件框架设计64

3.2.6基础构件/服务设计64

3.2.74其它构件64

3.2.8与架构其它层关系64

3.2.9相关规范与标准65

3.2.10务运行、管理和监控环境65

3.3政务资源层65

3.3.1政务资源层总体架构65

统资源层面临的问题65

3.3.L2~架构目标66

331.3架构总图及描述66

务资源层应用前景和趋势67

3.3.2政务信息资源68

3.321政务信息资源的封装68

3.322政务信息资源的接入69

3.323政务信息资源的管理69

3.324政务信息资源的访问70

3.3.3部门业务应用资源71

3.3.3」应用资源的封装71

333.2应用资源的接入72

3.333应用资源的管理72

3.334应用资源的统一访问73

3.3.4政务目录资源73

334」资源元数据描述74

334.2资源编目76

334.3安全管理77

3.344基于目赢资源共享体系77

3.4支撑服务层79

3.4.1全景图79

3.4.2描述79

3.4.3服务构成80

3.4.3」公共服务80

343.2领域服务87

3.5业务应用层89

3.5.1全景图89

3.5.2描述89

3.5.3基于SOA业务应用层的业务应用模式90

353.1从软基础设施的视角研究模式分类91

353.2基于SOA的资源共享应用模式93—

3.533基于SOA的业务协同应用模式94

353.4基于SOA的不同服务渠道的应用模式94

3.5.4与其它各层的关系95

354.1业务应用层对基础支撑层的要求95

3.542业务应用层对展现服务层的支持96

3.543业务应用层对安全保障体系的要求96

3.6展现服务层97

3.6.1全景图97

362适酉己器98

363支撑运行环境98

3.6.4具体的展现服务99

365展现服务相关的标准体系、工具集、安全保障体系99

3.7工具集100

3.71全景图101

3.722开发和部署服务101

3.721服务的体系架构/模型103

3.722体系架构说明体4

3.723功能模块概述104

3.724功能模块间关系概述105

3.725功能详细说明105

3.726与其他服务关系108

3.8标准规范体系110

3.8.1全景图110

3.8.2基础支撑层110

3.8.3政务资源层113

3.8.4支撑服务层114

3.8.5业务应用层118

3.8.6展现服务层118

3.8.7安全保障体系119

3.9安全保障体系121

［全景图］121

391.2安全在整个SOA体系中的作用和位置123

3.9.L3安全保障体系的总体逻辑框架124

391.4安全保障体系中采用的标准规范体系框架图125

3.9.2SOA安全实施要点及方法125

392.1端到端SOAP消息交换的安全125

3.922Web服务策略机制服1

392.3令牌转换和信任域127

3.924安全对话128

392.5跨域的互信任操作129

3.926SOA系统的安全管理制度130

第四章应用架构设计路线图130

4.1全景图130

4.2基础SOA132

4.3网络化SOA132

4.4流程支撑的SOA133

附录A术语表136

附录B架构设计资料参考137

附录C案例描述-137-

第一章引论

1.1本指南的目的

基本目的是识别SOA电子政务领域应用架构设计知识体系普遍公认为良好

做法的那一部分。

深阅指一般概括性介绍，而非详尽无遗漏的说明。

哥遇公认，指介绍的知识和做法在绝大多数情况下适用于绝大多数的架构设

计，其价值和实用性也得到了人们的广泛认同。

良好做法指一致认为,正确应用这些技能、工具和技术能够增加范围极为广泛

的各种不同架构设计成功的机会。良好做法并不是说这些知识和做法一成不变地

应用于或应当应用于所有的架构设计：

架构设计团队负责架构的裁剪和扩展。

本指南还旨在作为该职业和实践一个共同的求通匚编，为讨论、书写和应用

架构设计方面的问题提供便利。这种术语汇编是一种职业必不可少的组成部分。

本指南还提供了一个参考的电子政务应用架痴并结合一个具体案例讲解如何

在电子政务领域进行基于SOA的应用架构设计。

本指南用来指导电子政务领域政务系统建设和政务系统之间的整合任务的架

构设计。

而附录B列出了架构设计资料的其他来源。

1.2本指南依据的长风联盟参考文档

・SOA-RA-TF制定的《SOA参考架构白皮书》

•SOA-AP-TF制定的《SOA电子政务总体技术架构与解决方案》

1.3什么是SOA电子政务总体应用架构

长风联盟依据《国家电子政务总体框架》，遵循国家电子政务标准，参照

《北京市电子政务总体技术框架》，结合长风联盟SOA电子政务解决方案的实

际情况，制定出长风联盟SOA总统技术架构。目标是作为长风联盟企业实施SOA

架构的电子政务系统的标准型、指导性框架，实现未来电子政务系统的互联互通、

资源共享，并使联盟企业可以快速、流畅、高效地构建各类政务应用系统,保障以

该架构为标准的各类政务应用通畅运行。该架构将成为未来电子政务实施的重要

指导。该架构乂称为“五横三纵架构”。

1.4什么是SOA电子政务总体应用架构设计

SOA电子政务总体应用架构设计就是把各种知识、技能、手段和技术应用于

架构活动中，以达到系统建设和系统整合的要求。

•架构设计必须权衡质量、时间、范围和费用等方面的要求。

其中：

质量属性

（按各种角度分类的属性。

譬如：

[1]按生命周期划分会有设计期，开发期，运（行期，测试期，

维护期质量

[2]定量属性和定性属性，可用性、可修改性、性能、安全、

有效性、可测试性、可监控性、可追溯性、可升级性、可扩张性、可维护性、可管理

非功能.求性、可复用性、模块独立交付性等）

约束

卜面介绍几个通常会在系统设计中涉及的质量属性。

1.性能

指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间

以及处理交易量的能力等。

通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能；也可以通

过系统能够处理的交易量（每秒）来衡量系统的性能。对于架构设计师来说，无论采

取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人

员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的

工作，而不是系统设计开发人员应该关注的事情。

在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提供都

是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很

多次的远程函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和

稳定性带来的影响都可以忽略不计，但如果我们在基于SOA的架构中使用了很多Web

Service来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在Internet环境

下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于SOA

的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行

信息交换。这样做可以在一定程度上提高系统的整体性能。

2.可升级性

指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架

构。

当基于SOA的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度

内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须

首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，

所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在

可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已

达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的

方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环

境中添置新的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计

出来的架构必须能够处理对硬件的垂直或者水平升级。基于SOA的系统架构可以很

好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的

服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统

的水平升级还是垂直升级，都不会影响到系统整体的架构。

3.可靠性

指确保各应用及其相关的所有交易的完整性和一致性的能力。

当系统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够象负荷未

增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。

如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级

性。因此，一个真正可升级的系统必须是可靠的系统。在基于SOA来构建系统架构

的时候，可靠性也是必须要着重考虑的问题。要在基于SOA架构的系统中保证一定

的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的

可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个SOA

系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。

4.可用性

指确保一项服务或者资源应该总是可被访问到的。

可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不一定会影

响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件

的错误会对系统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服

务仍然可用。在基于SOA来构建系统架构的时候，对于关键性的服务需要更多地考

虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具

体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持;第二

种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。在SOA架构设计

师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的

SOA系统架构中的关键性业务能具有较高的可用性。

5.可扩展性

指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。

当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系

统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设

计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素:低

耦合，界面(mteifaces)以及封装。当架构设计师基于SOA来构建企业系统架构时，就

已经隐含地解决了这几个可扩展性方面的要素。这是因为SOA架构中的不同服务之

间本身就保持了一种无依赖的低耦合关系；服务本身是通过统一的接口定义(可以是

WSDL)语言来描述具体的服务内容，并且很好地封装了底层的具体实现。

6.可维护性

指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。

当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创

建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、

模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了SOA架构能为系

统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统

文档纪录，除了底层子系统的相关文档外，基于SOA的系统还会引用到许多系统外

部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员

来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理,

这些相关的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、

具体性能测试结果等各种相关文档。基于这些文档，就可以为SOA架构设计师构建

企业SOA架构提供很好的文档参考和支持。

7.可管理性

指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。

具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，通过改变

系统的配置从而可以动态地改善服务质量，而不用改变整体系统架

构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管

理的功能。在对复杂系统进行系统架构建模时，SOA架构设计师应该尽量考虑利

用将系统整体架构构建在已有的成熟的底层系统框架(Fiamewoik)_to

8.安全性

指确保系统安全不会被危及的能力。

目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求

确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-

Service)攻击。这就要求当SOA架构设计师在构建一个架构时，应该把整体系统

架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见

的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统

架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。

如果企业SOA架构中的一些服务是由WebSemce实现的，在考虑这些服务安全性

的时候也要同时考虑效率的问题，因为WS-Secunty会为WebSeivice带来一定的

执行效率损耗。

•高质量的架构设计还考虑了技术风险应对的因素。

•应对变化，权衡不变与变化是架构设计永恒的主题。

•架构设计中还必须考虑SOA的独特性,例如：服务分类方法等。

臼按服务在系统建设中的用途划分：

⑵按服务的功能划分：

1.1服务：数据中心的服务和逻辑中心的服务

1.2服务：技术网关、适配器、外观、装饰服务

1.3程为中心的服务

1.4企业服务：为跨企业集成提供接口，例如SMS、Email等员外应

用程序前端是SON的激活元素。

1.5本指南的章节组织

主要分4章介绍。

第1章引论

第2章应用架构设计知识领域、设计原则和过程组

第3章应用架构分解结构

第4章应用架构设计路线图

1.6应用架构设计的主要内容

依据SOA-RA-TF的参考架构，解决电子政务应用领域如何产出一个SOA应用

架构的问题：

•架构的生命期构成

•整体架构设计过程组

­架构分解结构（五横三纵架构）

・知识领域:服务参考模型

­架构侧面系（生命周期模型和4+1视图）

1.7应用架构分解结构与参考架构（RA）

应用架构分解结构中的基础支撑层中的系统软件尽量按照RA标准实现，如不能

满足，架构上应考虑松耦合的互连互通，保障符合RA标准的服务库和应用系统能够

和本应用架构协同。

另外RA为应用架构分解结构中的服务开发运行体系提供支撑机制，如ESB

等。

1.8应用架构设计环境

本指南假定架构设计在项目环境下进行。

应用架构设计受到一定环境因素的影响和约束，并反过来对这些因素产生影响:

•应用领域标准规范

•组织过程资产

•公司战略要求

•技术环境

•项目要求

•管理因素

架构设计和项目管理和组织日常运作管理是密切相关的，但本指南不涉及相关

内容，请参考相关书籍和文献资料。

1.9应用架构设计干系人

架构设计要考虑架构设计干系人的要求。

•高层管理人员

•项目发起人

•项目经理

•架构设计师

•需求人员

•开发人员

・测试人员

・客户

1.10应用架构设计指南与长风联盟其他文档的关系

第二章应用架构设计知识领域、原则和过

程组

2.1应用架构设计知识领域

2.1.1SOA设计方法学

SOA设计方法并非全新的方法论，而是继承了传统的面向对象的设计方法以及

面向过程的设计方法，同时乂增加了SCA,,SDO,BPEL等技术，融入了面向服务的

设计方法，服务参考模型OASISRM里的内容映射，具体内容包括服务定义、服务设

计、服务管理、服务开发、服务测试和服务部署。

2.1.2数据建模方法学

传统的数据建模方法学是面向一个应用系统内部的实体的建模方法学，而在当前

数据整合、应用整合的需求下,数据建模还要考虑在不同系统间进行数据交换和数据

共享的需求。基于业务效率的考虑，从业务流程出发的思路改变了数据

模型。只有你从业务流程的角度来看待数据的时候，数据模型才能算真正完成。

2.1.3面向流程设计方法学

阐述了一种以实现流程优化的流程系统设计思想。这种设计思想是面向业务流程

的，不同于传统MIS系统面向部门职能的设计思想。首先把系统设计区分为原理层设

计和技术层设计两个层次，然后从业务流程设计、数据模型设计和技术架构设计三个

方面论述了原理层设计的基本思想。

2.1.4技术领域架构设计方法学

大型IT系统的设计通常遵循七层架构的设计方法，包括：

界面层

该层是直接面向用户（包括公众、企业、业务人员、行政管理人员、领导等使

用者）的统一的系统界面。界面层利用业界主流的IT技术支持多种渠道接入和交互

（如互联网、电话、手机短信等接入方式），以及统一的身份认证及权限管理。

应用层

应用层提供所有的信息应用和系统管理的业务逻辑，分解业务请求，通过应用

支撑层进行数据处理，并将返回信息组织成所需的格式提供给客户端。应用系统分

为四大部分：

＞面向公众和企业的外网应用一一审批门户（网上审批系统前台），提供网上

申报和反馈查询等在线服务功能；

＞面向公务员的审批服务平台，实现业务审批、监督检察、业务调度、决策支持

等功能；

＞面向公务员的政府资源共享平台（数据共享与交换平台），实现基于审批业务

的数据交换与基于委办局现有信息资源的数据共享使用等功能。

＞面向公务员的开放办公平台，实现基于开放的桌面办公系统，实现对审批过程

数据的保存及归档等。

应用支撑层

应用支撑层构建在J2EE应用服务器之上，提供了一个应用基础平台

DC-BPIP,并提供大量公共服务和业务构件，提供构件的运行、开发和管理环境，最大

限度提高开发效率，降低工程实施、维护的成本和风险。应用支撑层采用了行业应用

的先进体系结构，以建立高性能、高可靠性、高扩展性的应用系统，满足客户快速发

展的业务需求。

信息资源层

信息资源层是整个系统的信息资源中心，涵盖全市所有与行政审批相关的结构

化和非结构化数据。它是企业信息资源的存储和积累，为系统应用提供数据访问服

务、备份、存储功能。

IT基础平台层

IT基础平台为系统的软硬件以及网络基础平台，分为三个部分：系统软件、硬件

支撑平台、和网络支撑平台。其中，系统软件包括中间件、数据库服务器软件等；硬

件支撑平台包括：主机、存储、备份等硬件设备；网络支撑为系统运行所依赖的网络

环境。它对上层应用起到技术支撑作用支撑体系层

系统建设和推广运行仅仅依赖应用系统建设、硬件网络建设是不够的，需要在系

统安全方面、标准化方面、以及系统运维三个不同层面的工作来共同支撑。只有这样，

才能使系统建设顺利进行，也才能保证系统能顺利推广、稳定运行。法律法规层

以上各个层面的建设，需要依托于现有的法律、法规及一些规范才可成功运行。

系统的分析、设计、实施都必须充分考虑这些因素。只有切实符合这些规范，系统才能

与建设单位共同发展，得到各级用户的认可。

而利用RUP的设计思想，则将架构设计概括为4+1视图：

逻辑视图逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能

而必须提供的”辅助功能模块”；它们可能是逻辑层、功能模块等。开发视图。

开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方

SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开

发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个

程序包等。

处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同

步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期

的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比

较关注的正是这些运行时单元的交互问题。

物理视图。物理视图关注”目标程序及其依赖的运行库和系统软件”最终如何安

装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸

缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执

行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系

统和整个IT系统相互影响的架构视图。

场景视图。关注业务的应用场景。

2.1.5通用架构设计方法学

架构设计是一种权衡("ade-off)。一个问题总是有多种的解决方案。而我们要

确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个

权衡。我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特

殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可

是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的

期望。我们希望软件简单明了，却增加了我们设计的复杂度。没有一个软件能够

满足所有的要求，因为这些要求之间带有天生的互斥性。而我们评价架构设计的

好坏的依据，就只能是根据不同要求的轻重缓急，在其间做出权衡的合理性。

目标

我们希望一个好的架构能够：

重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前

的设计。重用是我们不断追求的目标之一，但事实上，做到这一点可没有那么容易。

在现实中，人们已经在架构重用上做了很多的工作，工作的成果称为框架(Framework),

比如说Windows的窗口机制、J2EE平台等。但是在企业商业建模方面，有效的框架

还非常的少。

透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把客户需求的

接口呈现给客户。这样，具体的实现对客户来说就是透明的。一个具体的例子是我们

使用JSP的tag技术来代替JSP的嵌入代码，因为我们的HTML界面人员更熟悉tag

的方式。

延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一定的延展性，

以适应未来可能的变化。可是，如上所说，延展性和稳定性，延展性和简单性都是矛

盾的。因此我们需要权衡我们的投入/产出比。以设计出具有适当和延展性的架构。

简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够在满

足目的的情况下尽可能的简单明了。但是简单明了的含义究竟是什么好像并没有一个

明确的定义。使用模式能够使设计变得简单，但这是建立在我熟悉设计模式的基础上。

对于一个并不懂设计模式的人，他会认为这个架构很复杂。对于这种情况，我只能对

他说，去看看设计模式。

高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些特定的系统

来说尤其重要。例如实时系统、高访问量的网站。这些值的是技术上的高效，有时候我

们指的高效是效益上的高效。例如，一个只有几十到一百访问量的信息系统，是不是

有必要使用EJB技术，这就需要我们综合的评估效益了。

安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方面。规则

为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则：

功能分解

顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重用目标就是

因为我们编写的程序经常处于一种好像是重复的功能，但乂有轻微差别的状态中。我

们很多时候就会经不住诱惑，用拷贝粘贴再做少量修改的方式完成一个功能。这种行

为在XP中是坚决不被允许的。XP提倡“Onceandonlyonce”,目的就是为了杜绝这种

拷贝修改的现象。为了做到这一点，我们通常要把功能分解到细粒度。很多的设计思

想都提倡小类，为的就是这个目的。

所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方法的平均代

码却会大大的下降。可是，我们怎么知道这个度应该要如何把握呢，关于这个疑问，

并没有明确的答案，要看个人的功力和具体的要求，但是一般来说，我们可以用一个

简单的动词短语来命名类或方法的，那就会是比较好的分类方法。

我们使用功能分解的规则，有助于提高重用性，因为我们每个类和方法的精度都

提高了。这是符合大自然的原则的，我们研究自然的主要的一个方向就是将物质分解。

我们的思路同样可以应用在软件开发上。除了重用性，功能分解还能实现透明的目标，

因为我们使用了功能分解的规则之后，每个类都有自己的单独功能，这样，我们对一

个类的研究就可以集中在这个类本身，而不用牵涉到过多的类。

根据实际情况决定不同类间的耦合度

虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦合度。系统

之间不可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度的依据何

在呢？简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，

不容易发生变化的需求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间

的耦合度，但其实功能块、模块、包之间的耦合度也是一样的），因为这样可以提高效

率，而且我们还可以使用一些更好的技术来提高效率或简化代码，例如Java中的内部

类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题,

我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层

次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是一组的类（例

如Beans）。我们可以借用Java中的一句话来概括降低耦合度的思想：”针对接口编

程，而不是针对实现编程。

设计不同的耦合度有利于实现透明和延展。对于类的客户（调用者）来说，他不

需要知道过多的细节（实现），他只关心他感兴趣的（接口）。这样，目标类对客户

来说就是一个黑盒子。如果接口是稳定的，那么，实现再怎么扩展，对客户来说也不

会有很大的影响。以前那种牵一发而动全身的问题完全可以缓解共至避免。

其实，我们仔细的观察GOF的23种设计模式，没有一种模式的思路不是从增加

抽象层次入手来解决问题的。同样，我们去观察Java源码的时候，我们也可以发现,

Java源码中存在着大量的抽象层次，初看之下，它们什么都不干，但是它们对系统的

设计起着重大的作用。

够用就好

我们在上一章中就谈过敏捷方法很看重刚好够用的问题，现在我们结合架构设计

来看：在同样都能够满足需要的情况下，一项复杂的设计和一项简单的设计，哪一个

更好。从敏捷的观点来看，一定是后者。因为目前的需求只有10项，而你的设计能够

满足100项的需求，只能说这是种浪费。你在设计时完全没有考虑成本问题，不考虑

成本问题，你就是对开发组织的不负责，对客户的不负责。

应用模式

这篇文章的写作思路很多来源于对模式的研究。因此，文章中到处都可以看到模

式思想的影子。模式是一种整理、传播思想的非常优秀的途径，我们可以通过模式的

方式学习他人的经验。一个好的模式代表了某个问题研究的成果，因此我们把模式应

用在架构设计上，能够大大增强架构的稳定性。

抽象

架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。架构

是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解，然后我们

还要能够熟练的应用技术来实现现实世界到模型的映射。因此，我们在对业务或技术

理解不够深入的情况下，就很难设计出好的架构。当然，这时候我们发现一个问题:

怎样才能算是理解足够深入呢。我认为这没有一个绝对的准则。

一次，一位朋友问我：他现在做的系统有很大的变化，原先设计的工作流架构不

能满足现在的要求。他很希望能够设计出足够好的工作流架构，以适应不同的变化。

但是他发现这样做无异于重新开发一个lotusnotes。我听了他的疑问之后觉得有两点

问题：

首先，他的开发团队中并没有工作流领域的专家。他的客户虽然了解自己的工作

流程，但是缺乏足够的理论知识把工作流提到抽象的地步。显然，他本身虽然有技术

方面的才能，但就工作流业务本身，他也没有足够的经验。所以，设计出象notes那

样的系统的前提条件并不存在。

其次，开发一个工作流系统的目的是什么。原先的工作流系统运作的不好，其原

因是有变化发生。因此才有改进工作流系统的动机出现。可是，毕竟notes是为了满足

世界上所有的工作流系统而开发的，他目前的应用肯定达不到这个层次。

因此，虽然做不到最优的业务抽象，但是我们完全可以在特定目的下，特定范围

内做到最优的业务抽象。比如说，我们工作流可能的变化是工组流路径的变化。我们

就完全可以把工作流的路径做一个抽象，设计一个可以动态改变路径的工作流架构。

有些时候，我们虽然在技术上和业务上都有所欠缺，没有办法设计出好的架构。

但是我们完全可以借鉴他人的经验，看看类似的问题别人是如何解决的。这就是我们

前面提到的模式。我们不要把模式看成是一个硬性的解决方法，它只是一种解决问题

的思路。MartinFowlei-曾说：“模式和业务组件的区别就在于模式会引发你的思考。”

在《分析模式》一书中，MaihnFowle［提到了分析和设计的区别。分析并不仅仅

只是用用例列出所有的需求，分析还应该深入到表面需求的的背后，以得到关于问题

本质的MentalModel。然后，他引出了概念模型的概念。概念模型就类似于我们在讨

论的抽象。MartinFowle［提到了一个有趣的例子，如果要开发一套软件来模拟桌球游

戏，那么，用用例来描述各种的需求，可能会导致大量的运动轨迹的出现。如果你没

有了解表面现象之后隐藏的运动定律的本质，你可能永远无法开发出这样一个系统。

关于架构和抽象的问题，在后面的文章中有一个测量模式的案例可以很形象的说

明这个问题。

架构的一些误解

我们花了一些篇幅来介绍架构的一些知识。现在回到我们的另一个主题上来。对

于一个敏捷开发过程，架构意味着什么，我们该如何面对架构。这里我们首先要澄清

一些误解：

误解L架构设计需要很强的技术能力。从某种程度来说，这句话并没有很大的错

误。毕竟，你的能力越强，设计出优秀架构的几率也会上升。但是能力和架构设计之

间并没有一个很强的联系。即使是普通的编程人员，他一样有能力设计出能实现目标

的架构。

误解2：架构由专门的设计师来设计，设计出的蓝图交由程序员来实现。我们之

所以会认为架构是设计师的工作，是因为我们喜欢把软件开发和建筑工程做类比。但

是，这两者实际上是有着很大的区别的。关键之处在于，建筑设计已经有很长的历史，

已经发展出完善的理论，可以通过某些理论（如力学原理）来验证设计蓝图。可是,

对软件开发而言，验证架构设计的正确性，只能够通过写代码来验证。因此，很多看

似完美的架构，往往在实现时会出现问题。

误解3：在一开始就要设计出完善的架构。这种方式是最传统的前期设计方式。

这也是为XP所摒弃的一种设计方式。主要的原因是，在一开始设计出完美的架构根

本就是在自欺欺人。因为这样做的基本假设就是需求的不变性。但需求是没有不变的

（关于需求的细节讨论，请参看拙作『需求的实践」）。这样做的坏处是，我们一开

始就限制了整个的软件的形状。而到实现时，我们虽然发现原来的设计有失误之处,

但却不愿意面对现实。这使得软件畸形的生长。原本一些简单的问题，却因为别扭的

架构，变得非常的复杂。这种例子我们经常可以看到，例如为兼容前个版本而导致的

软件复杂性。而2000年问题，TCP/IP网络的安全性问题也从一个侧面反映了这个问

题的严重性。

误解4：架构蓝图交给程序员之后，架构设计师的任务就完成了。和误解2一样，

我们借鉴了建筑工程的经验。我们看到建筑设计师把设计好的蓝图交给施工人员，施

工人员就会按照图纸建造出和图纸一模一样的大厦。于是，我们也企图在软件开发中

使用这种模式。这是非常要命的。软件开发中缺乏一种通用的语言，能够充分的消除

设计师和程序员的沟通隔阂。有人说，UML不可以吗？UML的设计理念是好的，可

以减轻沟通障碍问题。可是要想完全解决这个问题，UML还做不到。首先，程序员都

具有个性化的思维，他会以自己的思维方式去理解设计，因为从设计到实现并不是一

项机械的劳动，还是属于一项知识性的劳动(这和施工人员的工作是不同的)。此外，

对于程序员来说，他还极有可能按照自己的想法对设计图进行一定的修改，这是非常

正常的一项举动。更糟的是，程序员往往都比较自负，他们会潜意识的排斥那些未经

过自己认同的设计。

架构设计的过程模式

通常我们认为模式都是用在软件开发、架构设计上的。其实，这只是模式的一个

方面。模式的定义告诉我们，模式描述了一个特定环境的解决方法，这个特定环境往

往重复出现，制定出一个较好的解决方法有利于我们在未来能有效的解决类似的问题。

其实，在管理学上，也存在这种类似的这种思维。称为结构性问题的程序化解决方法。

所以呢，我们完全可以把模式的思想用在其它的方面，而目前最佳的运用就是过程模

式和组织模式。在我们的文章中，我们仅限于讨论过程模式。

我们讨论的过程仅限于面向对象的软件开发过程。我们称之为OOSP(object-

onentedsoftwarepiocess)o因为我们的过程需要面向对象特性的支持。当然，我们的很

多做法一样可以用在非00的开发过程中，但是为了达到最佳的效果，我建议您使用

00技术。

2.1.6面向对象设计方法学

面向对象方法(Object-OnentedMethod)是一种把面向对象的思想应用于软

件开发过程中，指导开发活动的系统方法，简称00(0bject-0口ented)方法，是

建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体,

与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。而每

继承性是对具有层次关系的类的属性和操作进行共享的一种方式。所谓面向对象

就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻

画客观世界和设计、构建相应的软件系统。

面向对象方法作为一种新型的独具优越性的新方法正引起全世界越来越广泛

的关注和高度的重视，它被誉为”研究高技术的好方法”，更是当前计算机界关

心的重点。十多年来，在对00方法如火如荼的研究热潮中，许多专家和学者预

言：正像70年代结构化方法对计算机技术应用所产生的巨大影响和促进那样，90

年代00方法会强烈地影响、推动和促进一系列高技术的发展和多学科的综合。

用计算机解决问题需要用程序设计语言对问题求解加以描述（即编程），实质

上，软件是问题求解的一种表述形式。显然，假如软件能直接表现人求解问题的

思维路径（即求解问题的方法），那么软件不仅容易被人理解，而且易于维护和修

改，从而会保证软件的可靠性和可维护性，并能提高公共问题域中的软件模块和

模块重用的可靠性。面向对象的机能念和机制恰好可以使得按照人们通常的思维

方式来建立问题域的模型，设计出尽可能自然地表现求解方法的软件。

面向对象的基本概念：

对象：对象是要研究的任何事物。从一本书到一家图书馆，单的整数到整数

列庞大的数据库、极其复杂的自动化工厂、航天飞机都可看作对象，它不仅能表

示有形的实体，也能表示无形的（抽象的）规则、计划或事件。对象由数据（描

述事物的属性）和作用于数据的操作（体现事物的行为）构成一独立整体。从程

序设计者来看，对象是一个程序模块，从用户来看，对象为他们提供所希望的行

为。在对内的操作通常称为方法。

类：类是对象的模板。即类是对一组有相同数据和相同操作的对象的定义,

一个类所包含的方法和数据描述一组对象的共同属性和行为。类是在对象之上的

抽象，对象则是类的具体化，是类的实例。类可有其子类，也可有其它类，形成

类层次结构。

消息：消息是对象之间进行通信的一种规格说明。一般它由三部分组成：接

收消息的对象、消息名及实际变元。

面向对象主要特征：

封装性：封装是一种信息隐蔽技术，它体现于类的说明，是对象的重要特性。

封装使数据和加工该数据的方法（函数）封装为一个整体，以实现独立性很强的

模块，使得用户只能见到对象的外特性（对象能接受哪些消息，具有那些处理能

力），而对象的内特性（保存内部状态的私有数据和实现加工能力的算法）对用

户是隐蔽的。封装的目的在于把对象的设计者和对象者的使用分开，使用者不必

知晓行为实现的细节，只须用设计者提供的消息来访问该对象。

继承性：继承性是子类自动共享父类之间数据和方法的机制。它由类的派生

功能体现。一个类直接继职其它类的全部描述，同时可修改和扩充。

继职具有传达室递性。继职分为单继承（一个子类只有一父类）和多重继承

（一个类有多个父类）。类的对象是各自封闭的，如果没继承性机制，则类对象

中数据、方法就会出现大量重复。继承不仅支持系统的可重用性，而且还促进系

统的可扩充性。

多态性：对象根据所接收的消息而做出动作。同一消息为不同的对象接受时

可产生完全不同的行动，这种现象称为多态性。利用多态性用户可发送一个通用

的信息，而将所有的实现细节都留给接受消息的对象自行决定，如是，同一消息

即可调用不同的方法。例如：Punt消息被发送给一图或表时调用的打印方法与将

同样的Print消息发送给一正文文件而调用的打印方法会完全不同。多态性的实

现受到继承性的支持，利用类继承的层次关系，把具有通用功能的协议存放在类

层次中尽可能高的地方，而将实现这一功能的不同方法置于较低层次，这样，在

这些低层次上生成的对象就能给通用消息以不同的响应。在OOPL中可通过在派

生类中重定义基类函数（定义为重载函数或虚函数）来实现多态性。

综上可知，在00方法中，对象和传递消息分别表现事物及事物间相互联系

的概念。类和继承是是适应人们一般思维方式的描述范式。方法是允许作用于该

类对象上的各种操作。这种对象、类、消息和方法的程序设计范式的基本点在于

对象的封装性和类的继承性。通过封装能将对象的定义和对象的实现分开，通过

继承能体现类与类之间的关系，以及由此带来的动态联编和实体的多态性，从而

构成了面向对象的基本特征。

2.2服务设计原则

2.2.1显式定义边界

通过跨越定义明确的边界进行显式消息传递，服务得以彼此交互。有时候,

跨越服务边界可能要耗费很大的成本，这要视地理、信任或执行因素而定。边界

是指服务的公共接口与其内部专用实现之间的界线。服务的边界通过WSDL发

布，可能包括说明特定服务之期望的声明。跨越边界的代价是高吊的因为：

目标服务的物理位置可能是未知的因素。

安全和信任模型可能会在每次跨越边界时发生改变。

在服务的公共表示和专用表示之间封送和转换数据可能需要依赖额外的资

源：其中一些资源可能在服务之外。

服务的构建要考量持久性，而服务配置的构建则要考量变化性。这一事实暗

示着：由于网络重新配置或者迁移到另一个物理位置，可靠的服务的性能可能会

突然降低。

服务的使用者通常不知道专用的内部过程是如何实现的。特定服务的使

用者对正使用的服务的性能只能进行有限的控制。

服务调用可能会受到网络滞后、网络故障和分布式系统故障的影响，而本地

实现则不会。要预先考虑使用远程对象接口的影响，就必须编写大量的错误检测

和更正逻辑。尽管跨越边界是代价高昂的过程，但在部署用于将此类边界跨越减

至最少的本地方法时，还是要格外谨慎。实现单一性本地方法和对象的系统可能

会获得性能的改善，但功能性却与先前定义的服务完全一样。

•弄清边界。服务提供一个契约来定义其提供的公共接口。与服务的所有

交互都通过公共接口进行。接口由公共进程和公共数据表示组成。公共进程是通

向服务内部的入口点，而公共数据表示则是指该进程使用的消息。如果我们使用

WSDL代表一个简单的契约，则＜message〉代表公共数据，而vportType〉代表

公共进程。文章”外部数据与内部数据”（英文）更详细地研究了这些问题。

•服务应易于使用。设计服务时，开发人员应使其易于其他开发人员使用。

设计的服务接口（契约）也应允许服务在不中断与现有使用者之间的契约的情况

下进一步发展。（这一主题将在本系列的后续文章中更详细地讨论。）

•避免使用RPC接口。应采用显式消息传递，而避免使用RPC之类的模

型。这种方法将使用者与服务实现的内部隔离开来，使开发人员可以集中精力改

进他们的服务，同时将对服务使用者的影响降至最低（使用公共消息而不是公用

的方法进行封装）。

•尽量减小服务的表面积。服务的公共接口越多，就越难以使用和维护。

应当少提供服务的定义明确的公共接口。这些接口应该相对简单，主要用于接受

定义明确的输入消息并以同样定义明确的输出消息进行响应。这些接口一旦定义,

即应保持不变。这些接口提供服务必须支持的“恒定不变”的设计要求，为服务

专用的内部实现充当门面。

•内部（专用）实现的细节不应泄露到服务边界之外。如果将实现细节泄

露到服务边界，很可能会使服务与服务使用者之间的耦合更加紧密。服务使用者

不应当获知服务实现的内部情况，因为这样会使服务的版本更新或升级受到限制。

2.2.2自治性

服务是独立进行部署、版本控制和管理的实体。开发人员应避免对服务边界

之间的空间进行假设，因为此空间比边界本身更容易改变。例如，服务边界应当

是不变的，只有这样才能将版本更新对使用者的影响降至最低。虽然服务边界是

相当稳定的，但策略、物理位置或网络拓扑等服务部署选项却很可能发生改变。

服务可以通过URI