(1)5    (2)6
   (3)6    (4)5
   (5)1    (6)13

在如图1所示的项目计划网络图中，根据表1所给定的各项工作持续时间，顺着箭线方向可以逐项计算出各项工作的最早开始时间和最早完成时间。对于“编程与测试”工作的前面工作有两项(即“需求调研”工作和“系统分析”工作)，该工作的最早开始时间等于各个紧前工作的最早完成时间的最大值，即“需求调研”工作的最早完成时间(5个月)；或者是该工作的最早开始时间等于本工作的最早完成时间减去工作持续时间(即12-7=5个月)。
   某工作的总时差等于该工作最迟完成时间与最早完成时间之差，或该工作最迟开始时间与最早开始时间之差。例如，在图1中，“编程与测试”工作的总时差为6-5=1个月。
   在如图1所示的项目计划网络图中，从网络计划的终止节点，逆着箭线方向可以逐项计算出各项工作的最迟开始时间和最迟完成时间。某工作的最迟完成时间等于该工作的最早完成时间加上其总时差之和。例如，在图1中，“编程与测试”工作的最迟完成时间为12+1=13个月。
   某工作的最迟开始时间等于该工作的最早开始时间加上其总时差之和。例如，在图1中，“硬件方案及配置”工作最迟开始时间为0+6=6个月。
   对于有紧后工作的工作，其自由时差等于该工作的紧后工作最早开始时间减去本工作最早完成时间所得之差的最小值。例如，在图1中，“硬件方案及配置”工作的紧后工作仅有“集成与试运行”工作，其自由时差为13-7=6个月。

根据图1中各项工作的最早开始时间及其持续时间，可以画出如下图所示的该项目甘特图。在如下图所示的甘特图中，横轴表示时间，纵轴表示要安排的活动，线条表示在该图生命周期中计划的(或实际的)活动完成情况。该甘特图直观地表明了任务计划在什么时间开始和什么时间结束。
   

(1)17    (2)13
   (3)10    (4)5
   (5)3    (6)9
   (7)7
   (8)12

根据上图所示的甘特图中各项工作的最早开始时间，结合表2每项任务每月人员的需求数量，可以得到如表3所示的每月人员需求数量。

表3　每月人员需求数量计算表
ID	任务名称	2011年												2012年
		1	2	3	4	5	6	7	8	9	10	11	12	1	2	3	4	5	6	7	8	9	10
1	需求调研	8	8	8	8	8
2	系统分析	4	4	4
3	系统设计						3	3	3	3	3	3	3	3
4	编程与测试						2	2	2	2	2	2	2
5	硬件方案及配 置	5	5	5	5	5	5	5
6	集成与试运行														9	9	9	9
7	培训与验收																		7	7	7	7	7
每月人工需求量小 计		17	17	17	13	13	10	10	5	5	5	5	5	3	9	9	9	9	7	7	7	7	7

在如图1所示的项目计划网络图中，关键路径为：开始→需求调研→系统设计→集成与试运行→培训与验收。为了考查该项目每月所需的最少人数，可以先安排关键路径上各项工作的人数，再优化调整具有自由时差的工作的启动时间。关键路径上各项工作的启动时间及人数的安排是确定的，在保证关键路径上作业及其紧前作业按时完成的情况下，“系统分析”、“编程与测试”、“硬件方案及配置”3个工作启动时间的安排就需要综合考虑平衡每个月所需的人数。表4给出了该项目每月人员需求数量优化配置的一种方案。该方案综合考虑到“硬件方案及配置”工作具有6个月的自由时差，将其安排在第7个月初开始，第13个月末结束。当然，在保证关键路径上作业及其紧前作业按时完成的情况下，在表4中“系统分析”、“编程与测试”、“硬件方案及配置”3个工作启动时间的安排还可以有多种组合排列方式，但是不管何种组合排列方式，该项目工作优化配置后每个月所需的最多人员数量至少为12人。

表4　该项目每月人员需求数量优化配置方案之一
ID	任务名称	2011年												2012年
		1	2	3	4	5	6	7	8	9	10	11	12	1	2	3	4	5	6	7	8	9	10
1	需求调研	8	8	8	8	8
2	系统分析	4	4	4
3	系统设计						3	3	3	3	3	3	3	3
4	编程与测试						2	2	2	2	2	2	2
5	硬件方案及配 置							5	5	5	5	5	5	5
6	集成与试运行														9	9	9	9
7	培训与验收																		7	7	7	7	7
每月人工需求量小 计		12	12	12	8	8	5	10	10	10	10	10	10	8	9	9	9	9	7	7	7	7	7

①特点：近期的工作计划较详细，远期的工作计划较粗略。
   ②依据：根据项目的规模、复杂度及项目生命周期的长短来确定。
   ③滚动周期：1周、2周，或1～2周的时间周。

滚动波浪式计划是项目渐进明细的一种表现形式，其特点是近期的工作计划得细一些，远期的工作计划得相对粗略一些。换言之，近期要完成的工作为工作分解结构(WBS)的最下层详细计划，而计划在远期完成的工作为工作分解结构的较高层计划。最近一两个报告期要进行的工作应在本期接近完成前更为详细地规划。
   滚动波浪式计划中的滚动周期应根据项目的规模、复杂度及项目生命周期的长短来确定。项目生命周期中有3个与时间相关的重要概念，即检查点(Checkpoint)、里程碑(Milestone)和基线(Baseline)。它们一起描述了在什么时候对项目进行什么样的控制。其中，检查点是指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个固定间隔的“采样”时间点，而时间间隔根据项目周期长短的不同而不同。若频度太小会失去意义，而频度过大会增加管理成本。常见的间隔是每周一次，项目经理需要召开周例会并上交周报告。
   在本案例中，该信息系统项目是对一个大型超市、涉及软硬件集成工作的较大型及复杂的项目，滚动波浪式计划中的滚动周期可确定为1周(或2周，或1～2周的时间周期)。

阶段                                目标
   定义领域范围                        确定领域应用需要满足的用户需求
   定义领域特定的元素                  制订领域字典和领域术语的同义词词典(或识别领域中各种应用间的共同性和差异性)
   定义领域特定的设计和实现需求约束    描述解空间中的特性，识别约束并记录其对设计和实现决定造成的后果，
                                       以及记录对处理这些问题时产生的所有问题的讨论

   定义领域模型和构架                  产生该领域的参考架构，并说明构件的语法和语义
   产生和搜集可复用产品                为DSSA增加构件，为问题域实现新应用提供支持。

领域分析是分析和研究某个应用领域特性的活动，它是识别、收集、组织和描述一个领域相关信息，发现和记录领域中的共性和差异的过程，是系统化、形式化、有效复用的关键。通过领域分析，类似系统的公共特性将被提取，使用于该领域所有公共的、基本的对象及操作被标志出来，并且通过定义模型来描述他们之间的关系。领域分析的本质是以复用为目的，对具有若干共同特性的一群应用系统进行分析，对共同的部分开发出一系列公用的组件，对不同的部分进行参数化。
   按照Will Tracz的说法，特定领域软件架构(DSSA)就是一个特定的问题领域中由领域模型、参考需求和参考架构等组成的开发基础架构，其目标就是支持一个特定领域中多个应用的生成。DSSA的基本活动包括领域分析、领域设计和领域实现。领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间的共同需求，即领域需求；领域设计的主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；领域实现的主要目标是依据领域模型和DSSA开发、组织可重用信息。
   在最高的级别上，DSSA方法共有5个阶段，每个阶段可以进一步划分为一些步骤或子阶段，每个阶段包括一组需要回答的问题、一组需要的输入。该方法的领域工程过程是并发的、递归的和反复的，或者可以说，它是螺旋型的，完成该过程可能需要对每个阶段经历几遍，每次增加更多的细节。该领域工程过程的5个阶段如下。
   (1)定义领域范围：重点是确定领域中包含哪些元素及领域工程过程到何时结束。这一阶段的一个主要输出是领域中的应用需要满足的一系列用户的需求。
   (2)定义领域特定的元素：目标是制订领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层次块图中增加更多的细节，特别是识别领域中各种应用间的共同性和差异性。
   (3)定义领域特定的设计和实现需求约束：目标是描述空间中的特性，不仅要识别约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。
   (4)定义领域模型和构架：目标是产生DSSA，并说明构成它的模块或构件的语法、语义。
   (5)产生和搜集可复用的产品：目标是为DSSA增加构件，使得它可以被用来产生问题域中的新应用。
   从软件实践上看，面对特定领域的系统开发，迫切需要一种好的开发方法来有效地支持软件重用性，而DSSA方法已经在实践中被证明是有效的，能显著加大重用的粒度，从而缩短整体开发周期，在提高产品品质的同时降低开发费用。

公共信息管理模块和系统管理维护模块应该在具体的配置和使用上通过配置文件(或数据文件)加载建设方的相关信息，从而使这些公共功能模块易被其他电子政务项目所复用。
   资质管理模块、企业信息管理模块和系统扩展接口模块等与建设方密切相关的功能模块，虽然在实现上无法完全和建设方信息分开，但要尽力降低和建设方的耦合度，使得今后复用时的代价最小化。在具体实现上，应该充分采用在市场上广泛使用的技术与产品(诸如Web服务器、中间件(J2EE应用服务器等)、电子邮件系统、数据库系统、信息门户和系统安全解决方案等)，同时采用CMM模型(或CASE工具等)来辅助、指导这些功能模块的软件开发工作。

在电子政务的建设过程中，应充分利用领域分析和软件复用的知识，采用基于可复用的软件开发方式，注重采用领域分析的方法，建立领域模型。例如，在领域分析时使用国际上通用的统一建模语言(UML)作为建模工具。在电子政务的建设过程中，应建立系统工程，建立行业范围内的一些标准，以利于确定复用的方案，使开发的系统可靠性高、成本低。
   根据题干关键信息，并结合从事系统架构设计的历史经验，大致可以分析该系统5大功能模块中，公共信息管理模块是Internet网络上的一个应用系统，这部分主要包括系统网站的相关功能，例如信息发布和浏览、资质等级标准查询、企业资质查询、网上调查、意见箱管理、问题解答，以及下载文档管理等。系统管理维护模块主要是系统管理员用户用来设置或设定系统的参数，管理和维护系统最基本的数据。主要功能包括用户及权限管理、工作流管理、企业管理、信息发布管理、系统维护、文档管理和基础数据管理等。对于这两个功能模块应该在具体的配置和使用上通过配置文件(或数据文件)把建设方的相关信息加入进来，从而使这些公共功能模块容易地被其他电子政务项目所复用。
   根据行业经验，资质管理模块通常包括企业资质的网上申请、审批、年审、动态管理、变更、备案、资质证书管理，以及相关资质申请审批工作处理情况的查询、资质标准和等级的管理、分析统计等。企业信息管理模块主要是对具体企业信息的维护，包括企业相关信息的输入、输出、修改、删除、查询和打印等功能。其中，人员管理还包括人员的调离、年龄控制等。系统扩展接口模块用于本系统与其他信息系统的数据交换，保证了建设方的管理系统与其他行业部门已有或待建信息化系统的无缝链接等。对于这些与建设方密切相关的功能模块，即使在实现上无法完全和建设方的相关信息分开，也要尽力降低和建设方的耦合度，以便使得今后复用时的代价最小化。
   在具体的实现上，应该充分采用在市场上广泛使用的技术与产品。例如，Web服务器、J2EE应用服务器、电子邮件系统、数据库系统、信息门户和系统安全解决方案等，建议使用已有的软件产品而不是自行开发。同时采用CMM模型或者CASE工具等指导所承接的软件系统的开发，以便高质量地完成项目的建设工作，使得所建成的软件系统具有良好的可复用性。

有用性：构件必须提供有用的功能。
   可用性：构件必须易于理解和使用。
   质量：构件及其变形必须能正确工作。
   适应性：构件应该易于通过参数化等方式在不同语境中进行配餐。
   可移植性：构件应能在不同的硬件运行平台和软件环境中工作。
   可变性(Variability)：构件应能针对不同的应用系统，只需对其可变部分进行适当的调节等。

构件(Component)是指应用系统中可以明确辨识的构成成分。它是软件系统可替换的、物理的组成部分，它封装了实现体(实现某个职能)，并提供了一组接口的实现方法。而可复用构件(Reusable Component)是指具有相对独立的功能和可复用价值的构件。软件构件技术是软件复用的核心技术。它是基于面向对象的，以即插即用型构件概念为中心，通过构件组合来建立应用的体系。其主要研究内容包括构件获取、构件模型、构件描述语言、构件分类与检索、构件复合组装和构件标准化。
   可复用构件应具备以下属性。
   (1)有用性(Usefulness)，构件必须提供有用的功能。
   (2)可用性(Usability)，构件必须易于理解和使用。
   (3)质量(Quality)，构件及其变形必须能正确工作。
   (4)适应性(Adaptability)，构件应该易于通过参数化等方式在不同语境中进行配置。
   (5)可移植性(Portability)，构件应能在不同的硬件运行平台和软件环境中工作。
   (6)可变性(Variability)，构件除了向复用者提供一些公共“特性”外，还要提供可变的“特性”。针对不同的应用系统，只需对其可变部分进行适当的调节，复用者要根据复用的具体需要，改造构件的可变“特性”，即进行“客户化”工作等。

(1)将现有系统看做抽象的服务提供者，集成方法统一明确。
   (2)不同层次的集成方法关注点不同，功能组合方面能力较弱。
   (3)强调功能的暴露与服务的组合，便于提供增值服务。
   (4)一般为中心辐射型，系统的耦合程度较高。
   (5)基于总线结构的体系结构，系统的耦合度低。
   (6)集成系统具有模块化、松耦合的特点，可扩展性较强。

应用集成是指两个或多个应用系统根据业务逻辑的需要而进行的功能之间的相互调用和互操作。应用集成需要在数据集成的基础上完成。应用集成在底层的网络集成和数据集成的基础上实现异构应用系统之间语用层次上的互操作。它们共同构成了实现企业集成化运行最顶层会聚集成所需要的、技术层次上的基础支持。应用集成模式包括集成适配器、集成信使、集成面板和集成代理4种，每种应用集成模式都是对具有业务功能依赖关系的多个应用之间互操作实现方法的总结。在具体应用中，集成模式可能以某种变形(这是一种扩展集成模式的主要方式)的形式出现，这些变形可能不仅仅只是一种模式的实例化，也可能是一种具有广泛适用性的集成方式。
   通常情况下，应用集成主要采用点对点的紧耦合方式。这种集成方式虽然不需要对应用系统做较大的改动，但用这种方式集成的系统缺乏必要的柔性，不能适应业务系统快速重构的需求。随着应用软件系统设计和实现过程中标准化程度的不断提高，系统的开放性(可配置性、可扩展性)越来越好，组件化的系统实现及松散耦合的应用集成方式逐渐成为构建企业业务处理系统的主流。其中，松散耦合是实现系统柔性的基础。
   在陈工建议的集成方案中，Web Service是一种可以接收从Internet或Intranet上传送的请求、轻量级的独立的通信技术，它允许网络上的所有系统相互间进行交互。Web Service的3个基本技术分别是UDDI、WSDL和SOAP，它们都是以XML为基础定义的。在Web服务体系中，使用WSDL来描述服务，UDDI来发布和查找服务，而SOAP用来执行服务调用。
   面向服务架构体系结构(SOA)的几个关键特性是：它是一种粗粒度、松耦合的服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。SOA可以根据需求通过网络对松耦合、粗粒度的应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
   SOA技术将应用程序的不同功能单元通过一些良好定义的接口联系起来，并且接口采用中立的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这样可以使得构建的服务以一种统一和通用的方式进行交互。
   企业服务总线(ESB)是对消息中间件的发展，采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用程序之间在消息、事件和服务的级别上动态地互连互通。ESB的基本核心功能包括：①提供位置透明性的消息路由和寻址服务；②提供服务注册和命名的管理功能；③支持多种消息传递范型；④传输协议转换；⑤支持多种数据格式及其相互转换；⑥提供日志和监控功能等。
   ESB所提供的基于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB中这种中介转化过程可能简单到什么也没有，也可能需要很复杂的中介服务支持，包括动态地查找和选择一个服务，以及消息的传递、路由和转换、协议的转换。这种中介过程是ESB借助于服务注册管理及问题域相关的知识(如业务方面的一些规则等)自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础，使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。
   如果企业只是进行小规模或较浅层次的“战术”级应用集成，采用传统的集成方式即可较好的完成任务。但是如果企业想从集成系统的灵活性和可扩展角度考虑，能够持续地集成已有信息系统，并进行“战略”意义上的长远规划，那么面向服务的架构无疑是一种更加优越的方法。采用SOA架构思想进行应用集成，企业现有的应用系统都可以看做广义上的服务提供者，因此(1)空缺处应该填写“将现有系统看做抽象的服务提供者，集成方法统一明确”。
   传统的应用集成方式往往采用分层的方式对待整个集成活动，因此在(2)空缺处应该填写“不同层次的集成方法的关注点不同，功能组合方面能力较弱”。而采用SOA架构的应用集成方案中，(3)空缺处应该填写“强调功能的暴露与服务的组合，便于提供增值服务”。
   对于(4)空缺处，传统的集成方式大多会采用中心辐射型的集成架构，系统的耦合程度较高。而对于(5)空缺处，SOA架构的ESB采用总线结构模式，简化了应用之间的集成拓扑，系统的耦合度较低。
   采用SOA架构的应用集成方案通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得解决方案是一个松散耦合、灵活的架构。因此在(6)空缺处应该填写“集成系统具有模块化、松耦合的特点，可扩展性较强”。
   整理以上分析内容，可得到两种集成方案各自的优点和不足，如下表所示。
   

(1)联邦服务：提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持XML数据等非关系型数据，所有的数据仍然按照自己本身的方式管理。
   (2)复制服务：提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本，本地数据和数据源在技术实现上可以是独立的。
   (3)转换服务：用于数据源格式到目标格式的转换，可以是批量的或者是基于记录的。
   (4)搜索服务：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持PDF等非结构化数据。

企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生，用于提供对分布式数据和异构数据的透明访问。以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务。
   (1)联邦服务(Federation Service)：提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持XML数据、文本数据和内容数据等非关系型数据。同时，所有的数据仍然按照自己本身的方式管理。
   (2)复制服务(Replication Service)：提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
   (3)转换服务(Transformation Service)：用于数据源格式到目标格式的转换，可以是批量的或者是基于记录的。
   (4)搜索服务(Search Service)：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持如PDF等非结构化数据。

①对服务粒度的控制。通常情况下，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口用于企业系统架构的内部，使用业务流程(BPEL)来创建由细粒度操作组成的业务流程的粗粒度的服务接口。
   ②对无状态服务的设计。架构中的具体服务应该都是独立的、自包含的请求(或是无状态的服务)，当某一个服务需要依赖时，可将它定义成具体的业务流程(BPEL)。

当基于SOA来构建一个企业级的系统架构时，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。而关于系统中最重要的元素，也就是SOA系统中服务的构建有两点需要特别注意的地方：①是对于服务粒度的控制：②是对于无状态服务的设计。
   SOA系统中服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。虽然细粒度的接口能为服务请求者提供更加细化和更多的灵活性，但同时也意味着引入较难控制的交互模式易变性，也就是说服务的交互模式可能随着不同的服务请求者而不同。如果暴露这些易于变化的服务接口给系统的外部用户，就可能造成外部服务请求者难以支持不断变化的服务提供者所暴露的细粒度服务接口；而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。虽然SOA并不强制要求一定要使用粗粒度的服务接口，但是建议使用它们作为外部集成的接口。通常情况下，可以使用业务流程(BPEL)来创建由细粒度操作组成的业务流程的粗粒度的服务接口。
   SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，最好把它定义成具体的业务流程(BPEIL)。在服务的具体实现机制上，可以通过使用EJB组件来实现粗粒度的服务。通常情况下，可以利用无状态的Session Bean来实现具体的服务，如果基于Web Service技术，就可以将无状态的Session Bean暴露为外部用户可以调用到的Web服务，也就是把传统的Session Facade模型转化为EJB的Web服务端点。这样就可以向Web服务客户提供粗粒度的服务。
   如果要在J2EE的环境下(基于Web Sphere)构建Web服务，Web服务客户可以通过两种方式访问J2EE应用程序。客户可以访问用JAX-RPC API创建的Web服务(使用Servlet来实现)；Web服务客户也可以通过EJB的服务端点接口访问无状态的Session Bean，但Web服务客户不能访问其他类型的企业Bean，如有状态的Session Bean、实体Bean和消息驱动Bean。对于后一种访问方式(公开无状态EJB组件作为Web服务)的优势在于：基于已有的EJB组件，可以利用现有的业务逻辑和流程。在许多企业中，现有的业务逻辑可能已经使用EJB组件编写，通过Web服务公开它可能是实现从外界访问这些服务的最佳选择。EJB端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。另外，EJB容器会自动提供对并发的支持，作为无状态Session Bean实现的EJB服务端点不必担心多线程访问，因为EJB容器必须串行化对无状态会话Bean任何特定实例的请求。由于EJB容器都会提供对于Security和Transaction的支持，因此Bean的开发人员可以无须编写安全代码及事务处理代码。性能问题对于Web服务来说一直都是一个问题，由于几乎所有EJB容器都提供了对无状态会话Bean群集的支持，以及对无状态Session Bean池与资源管理的支持，因此当负载增加时，可以向集群中增加服务器数目。Web服务请求可以定向到这些不同的服务器，同时由于无状态Session Bean池改进了资源利用和内存管理，使Web服务能够有效地响应多个客户请求。由此可以看到，通过把Web服务模型化为EJB端点，可以使服务具有更强的可伸缩性，并增强了系统整体的可靠性。

功能单元(包含但不限于以下内容)：
   ①贷款申请；②信用审查；③信贷员审批；④风险检查；⑤电子邮件传送等。
   采用SOA架构的优点(包含但不限于以下内容)：
   ①复用银行的各种应用资源。
   ②增强银行各个业务的集成性和灵活性。
   ③业务流程变更时便于快速构建应用系统。

面向服务架构体系结构(Service-Oriented Architecture, SOA)作为一种架构模型，它将应用程序的不同功能单元(称为服务)通过服务之间的接口(和契约)联系起来。接口独立于实现服务的硬件平台、操作系统和编程语言。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言，使得构建的服务可以以一种统一的和通用的方式进行交互。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点：①灵活性；②当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而与此相对，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
   通过题干中关于网上银行贷款业务的说明不难找出相对独立的功能单元。这些功能单元为SOA中的“服务”。由题干中给出的关键信息“(1)客户在网上填写姓名等信息，提交贷款申请”可知，该网上贷款业务流程中需要涉及“贷款申请”这一功能单元。
   由题干中给出的关键信息“(3)银行根据客户提交的信息……同时需要从第三方获得客户的信用审查信息”可知，该网上贷款业务流程中涉及“信用审查”这一第三方功能单元。
   由题干中给出的关键信息“(4)由信贷员对该项贷款申请业务进行审批，然后由风险检查系统评估该项贷款的风险程度”可知，该网上贷款业务流程中涉及“信贷员审批”和“风险检查(或风险评估)”这两个功能单元。其中，功能单元“信贷员审批”也可从题干中给出的关键信息“(6)除了信贷员审批环节需要人机交互外，业务是自动进行的”获得启发。
   由题干中给出的关键信息“(5)无论批准或者拒绝，结果都会通过邮件系统递交给客户”可知，该网上贷款业务流程中涉及“电子邮件传送”这一功能单元。
   从技术角度而言，SOA带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库(甚至不一定绑定到特定的基础设施)。正是得益于这个松散耦合特性，才能够将服务组合为各种应用程序。这样不仅大幅度提高了代码重用率，而且业务变更时业务系统更加灵活和便利，还可以在增加功能的同时减少工作量。SOA还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的服务，远胜于以往管理单个应用的方式。通过分析服务间的交互，SOA可以帮助企业了解何时及什么业务逻辑被切实执行了，使得管理员能够有针对性地优化业务流程。
   采用SOA将本项目的相关功能单元有机地集成在一起，可以快速、经济、方便地构建出网上银行贷款业务系统。具体优点表现在：①可以复用银行的各种应用资源；②可以增强银行各个业务的集成性和灵活性；③业务流程变更时便于快速构建应用系统。

(1)服务注册：应用开发者(或服务提供者)向注册表公布他们的功能，包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。实现SOA治理的有效方法之一，是限制哪类新服务可以向主注册表发布、由谁发布，以及谁批准和根据什么条件批准。
   (2)服务位置：服务应用开发者帮助他们查询注册服务，寻找符合自身要求的服务，注册表让服务的消费者检索服务合同。对谁可以访问注册表，以及什么服务属性通过注册表暴露的控制，是另一些有效的SOA治理手段。
   (3)服务绑定：服务消费者利用检索到的服务合同来开发代码，再将代码与注册的服务绑定、调用注册的服务，以及与它们实现互动。工具驱动对服务绑定的控制，有效地管理服务在ESB上的互动。

虽然服务注册表(Service Registry)常常具有运行时段的功能，但它主要是在SOA设计时段使用。注册表支持驱动SOA治理的服务合同、策略和元数据的开发、发布和管理，因此它提供一个主控制点，也称为策略执行点(Policy Enforcement Point, PEP)。在这个点上，服务可以在SOA中注册和被发现。
   注册表可以包括有关服务和相关软件组件的配置、遵从性和约束配置文件。任何帮助注册、发现和检索服务合同、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。UDDI(通用描述、发现与集成)标准定义了SOA的一种主要注册环境。
   大多数商用服务注册产品支持以下SOA治理功能。
   (1)服务注册：应用开发者(也称为服务提供者)向注册表公布他们的功能，包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。实现SOA治理最有效的方法之一，是限制哪类新服务可以向主注册表发布、由谁发布，以及谁批准和根据什么条件批准。此外，许多注册表包含开发向注册表发布服务可能需要的说明性服务模板。
   (2)服务位置：服务应用开发者帮助他们查询注册服务，寻找符合自身要求的服务。注册表让服务的消费者检索服务合同。对谁可以访问注册表，以及什么服务属性通过注册表暴露的控制，是另一些有效的SOA治理手段，注册表产品一般都支持此类功能。
   (3)服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发的代码将与注册的服务绑定、调用注册的服务，以及与它们实现互动。开发者常常利用集成的开发环境自动将新开发的服务与不同的新协议、方案和程序间通信所需的其他接口绑在一起。工具驱动对服务绑定的控制，有效地管理服务在企业服务总线(ESB)上的互动。

①验证(系统有关角色的身份识别)。
   ②签名(创建及验证类似手写签名的电子签名)。
   ③授权(如信贷员是否具有审批权)。
   ④完整性(发送的数据与接收到的数据是否一致)。
   ⑤机密性(与业务无关的人员不能读取事务中的数据)。
   ⑥审查或审计(把所有事务记录下来，以便事后验证)。
   ⑦不可否认性或防抵赖(由第三方求证事务中发送及收到的是否为同一数据)。
   ⑧威胁预防。

在进行SOA的集成时，用户身份识别、数据完整性等安全问题是需要重点解决的问题。该网上贷款系统必须满足以下安全方面的需求。
   (1)利用用户身份验证技术对该网上贷款系统的有关角色进行身份识别。
   (2)利用公钥密钥机制等技术创建及验证类似手写签名的电子签名。
   (3)采用授权机制审查系统中信贷员是否具有相应的审批权。
   (4)利用数据完整性机制验证发送的数据与接收到的数据是否一致。
   (5)采用机密性机制使与业务无关的人员不能读取事务中的数据。
   (6)采用审查机制(例如，日志记录)把所有事务记录下来，以便事后验证。
   (7)利用防否认机制，由第三方求证事务中发送及收到的是否是同一数据。
   (8)利用威胁预防机制，防止间谍程序登录和攻击系统。

(2)Tourist网站接收请求，将请求分解为对多个网站的数据请求调用，并为发起调用进行准备。
   (3)调用P网站提供的Web编程接口，给出(提供)用户的位置信息，请求地图信息。
   (5)调用Q网站的内容信息获取接口，给出(提供)用户地理信息，请求用户周边的交通信息。
   (7)Tourist网站根据用户的请求信息进行数据内容聚合。

Mashup程序从架构上是由客户机的Web浏览器、Mashup网站和API/内容提供者等3个不同的部分组成的，它们在逻辑上和物理上都是相互脱离的(可能由网络和组织边界分隔)。Mashup的主要工作流程是：当移动用户向Mashup网站发起一个请求时，通过GPS系统附带自身的位置信息：Mashup网站接收请求，并将请求分解为对多个服务网站的数据请求调用，并为发起调用进行准备；针对不同服务网站的调用接口，采用不同的调用方式；最终在Mashup站点将请求信息进行数据内容聚合，并将用户所处位置的整合信息返回。针对题中图，具体而言tourist.com公司进行Mashup的工作流程如下。
   (1)用户向Tourist网站请求服务，请求页面提供用户的位置信息。
   (2)Tourist网站接收请求，将请求分解为对多个网站的数据请求调用，并为发起调用进行准备。
   (3)调用P网站提供的Web编程接口，给出(提供)用户位置信息，请求地图信息。
   (4)P网站向Tourist网站返回用户所处位置周边的地图信息。
   (5)调用Q网站的内容信息获取接口，给出(提供)用户地理信息，清求用户周边的交通信息。
   (6)Q网站向Tourist网站返回用户所处位置周边的交通信息。
   (7)调用R网站的内容信息获取接口，给出(提供)用户地理信息，请求用户周边的住宿信息。
   (8)R网站向Tourist网站返回用户所处位置周边的住宿信息。
   (9)调用S网站的内容信息获取接口，给出(提供)用户地理信息，请求用户周边的餐饮信息。
   (10)S网站向Tourist网站返回用户所处位置周边的餐饮信息。
   (11)Tourist网站根据用户的请求信息对相关的地理位置、交通、住宿和餐饮等信息进行数据内容聚合。
   (12)Tourist网站向用户返回用户所处位置周边整合的旅游信息。

(1)仅需要使用现有Web应用程序公开的、基于Web的API(或Web服务)构建应用程序，集成过程相对简单。
   (2)直接使用Mashup技术集成两个或者更多的Web API，创建新的特性与功能。
   (3)大多采用静态展现技术，当客户端发送请求时，往往需要刷新整个网页。
   (4)使用Ajax技术调用基于Web的API，浏览器客户端无须在每次与服务器通信时都重新加载整个页面，动态特性强。
   (5)采用SOA思想集成底层系统，强调功能暴露与服务组合，以服务形式集成并暴露现有系统的能力。

本问题主要考查传统的应用集成方案和基于Web 2.0、Mashup技术的集成方式的比较和差异。传统的企业应用集成方案一般需要现有系统平台API层的支持，如Java平台、J2EE和.NET等，集成过程涉及面较广，相对复杂。而基于Web的应用与数据集成时，仅需要使用由现有Web应用程序(如Google Maps)公开的基于Web的API(或者Web服务)来构建应用程序，避免了复杂的集成过程。因此，(1)空缺处应该填写“仅需要使用现有Web应用程序公开的，基于Web的API(或Web服务)构建应用程序，集成过程相对简单”。
   基于Web 2.0和Mashup技术，可以直接使用Mashup技术集成两个或者更多的Web API，以创建某种新的特性与功能，因此在(2)空缺处应该填写“直接使用Mashup技术集成两个或者更多的Web API，创建新的特性与功能”。
   对于(3)空缺处，传统集成方式下的表现层大多采用静态展现技术，当客户端发送请求时，往往需要刷新整个网页。
   对于(4)空缺处，使用Ajax技术调用基于Web的API，浏览器客户端无须在每次与服务器通信时都重新加载整个页面，动态特性强。
   对于(5)空缺处，基于Web 2.0和Mashup技术的集成方案使用SOA的思想集成底层系统，强调功能暴露与服务组合，以服务的形式集成并暴露现有系统的能力。
   整理以上分析内容，可得到如下表所示的两种集成方案各自的考虑因素。
   

核心思想是以下几种现有技术的组合。
   (1)XHTML和CSS。
   (2)使用文档对象模型(Document Object Model)进行动态显示和交互。
   (3)使用XML和XSLT进行数据交互和操作。
   (4)使用XMLHttp Request进行异步数据接收。
   (5)使用JavaScript将它们绑定在一起。
   需要关注的效率问题：
   (1)替换部分而不是全部HTML网页。
   (2)不要在没有必要的情况下使用轮询计时器。
   (3)根据不同的情况，考虑传递不同格式的数据(JavaScript、XMIL、HTML和XHTML等)。
   (4)充分利用客户端的动态特性和计算能力减轻服务端负载。

Web 2.0是目前Internet上Web应用的新模式，其概念由Tim O'Reilly于2003年首次提出。目前Internet上已经有很多基于Web 2.0的Web应用系统。基于Web 2.0的Web应用十分强调用户的体验与感受，Ajax是目前广泛使用的表现层技术。事实上，Ajax并不是一种全新的技术，而是以下几种现有技术的组合。
   (1)XHTML和CSS。
   (2)使用文档对象模型(Document Object Model)进行动态显示和交互。
   (3)使用XML和XSLT进行数据交互和操作。
   (4)使用XMLHttp Request进行异步数据接收。
   (5)使用JavaScript将它们绑定在一起。
   针对这些技术的特点，在使用Ajax时，从性能方面考虑，需要注意以下几个问题。
   (1)替换部分而不是全部HTML网页(这是Ajax核心思想的体现)。
   (2)不要在没有必要的情况下使用轮询计时器。由于JavaScript是单线程的语言，不恰当的使用轮询计时器会大大降低程序的运行效率。
   (3)根据不同的情况，考虑传递不同格式的数据(JavaScript、XML、HTML和XHTML等)。
   (4)充分利用客户端的动态特性和计算能力减轻服务端负载。