1．概述
5至6月,微软公司在中国北京、上海、广州、西安、大连等大城市巡回举办了一系列关于
MSF(Microsoft Solution Framework:微软软件工程开发准则)的讲座。究竟什么是MFS?它有
什么意义?在实际应用中它如何运作……带着这些问题,记者走访了微软(中国)公司顾问咨
询部经理张彤川先生。
什么是MSF?
MSF是一套大型系统开发指南,它描述了如何用组队模型、过程模型和应用模型来开发
Client/Server结构的应用程序,是在微软的工具和技术的基础上建立并开发分布式企业系统
应用的参考。
张彤川告诉记者,MSF的最大特性是商业化,并自始至终地体现在项目的实施过程中。所谓商
业化意味着客户的商业利益。客户投入多少,得到多少回报,客户要用到哪些最新的技术,最后
如何把项目计划(Project)变成产品(Product)直至产生效益,等等,这些都是MSF要考虑的问
题。
MSF将一个项目中不同阶段的工作人员分为六个角色,通过这六个角色,项目可以得以迅速、
完善地实施。这也体现了项目开发的六个重要质量指标,它们在全球是一致的。这六个角色
分别是:
·产品经理。他了解用户特征,尤其是商业特征,明确用户的需求以及需求的期望值。之所以
强调用户需求的期望值,是因为用户的商业化特征比较强,需求无尽,无法界定到底如何才算
需求得到了满足。而确定了需求期望值后,用户的商业目的就非常明确,实施起来也比较顺
畅。
·程序管理员。他负责制定计划,每天找出完成该计划的风险所在,排除风险,每天交付应该完
成的内容,确保计划按质、按量实施。
·用户教育。设计友好的用户界面,对用户进行培训,确保用户能够并且愿意和喜欢使用开发
出的产品。
·开发。开发者在开发前期就参与用户需求分析和项目计划制定,他最清楚具体的开发过程。
在开发期开始后,他负责进行代码开发,在每一个阶段,交付每一项内容的代码。
·测试。负责开发出的代码的测试。测试者并不是要找到每一个开发者的每一段代码的每
一个错误(bug),而是要找到代码错误之间的关系,解决最根本的错误,掌握错误的状态,从而迅
速排除错误。
·后勤。后勤人员负责将实验室的产品商品化,变成实际可以运行的产品,达到最初制定的商
业目的,取得商业效益。这项工作在以往的项目中可能比较简单,因为实验室的环境可能和实
际环境几乎一致或差别不大。而现在却不同了,实验室环境可能十分简单,而实际环境可能非
常复杂,比如分布式环境、Internet/Intranet环境等,尤其是大企业,实际环境比实验室环境复
杂得多,因而将实验室产品运用到实际环境中是一项非常重要的工作。这项工作没有完成好,
往往使整个项目前功尽弃,功亏一篑。
实施MSF
在项目实施的过程中运用MSF,其效果将是显著的,它能够将技术变成产品,由产品变成效益;
它能够帮助用户少走或不走弯路,从而更快地达到自己的商业目标。
张彤川先生告诉记者,MSF在微软的许多大客户中得以大显身手,比如:瀛海威、中国投资银
行、香港跑马场、香港汇丰银行等。目前,在全国几个大城市举办的MSF巡回讲座,其目的
在于帮助更多的国内公司的领导,尤其是大公司的领导,认识MSF这一思想和原理,并能够在
实际中运用这一思想。微软正计划或已经开始和一些大客户共同实施MSF架构,如方正、用
友等。张彤川先生笑着对记者说,尽管每一位实施MSF项目的微软顾问的收费比较高,但MSF
带来效益足可以使这笔费用微不足道。
由于我国旧的体制往往并不以商业化为主要目标或商业化目的不明确,致使现在仍抱有旧体
制思想的企业在进行项目实施时常常陷入死循环。比如,当一个开发项目即将结束时,由于技
术的发展或业务的发展,客户的需求有所变化(往往是提高了),和最初签定项目实施协议时不
同。抱有旧体制思想的客户通常是拒绝在项目结束协议上签字,而是要求开发商按照变化了
的需求继续进行开发。但是,当按照变化了需求所进行的开发结束时,需求可能又发生了变
化。于是又继续进行开发,如此死循环。而MSF却可以解开这一死循环。当开发项目结束时,
即使需求发生了变化,但仍然可以将已开发出的部分变成产品,把该产品投入商业应用,使它
产生商业效益。至于变化了的需求,则可以开发出下一个版本来满足,甚至不断地开发新版本,
以满足不断变化的需求。
MSF思想正是要解开这一旧体制造成的死循环,从而更好地利用投资,帮助客户实现自己的
商业利益。这也是微软进行MSF巡回讲座、和大公司共同实施MSF思想的主要原因之一。
张彤川先生告诉记者,微软是一个产品提供商和技术提供商,提供平台、产品和技术。而真正
的满足用户实际需求的成千上万的应用要靠合作伙伴来完成。微软提供解决方案架构
(Solution Framework),而不提供具体的解决方案(Solution)。解决方案架构是一种准则或规则,
各个领域内的合作伙伴按照这一准则,以工业化模式制定出具体的解决方案。所谓工业化模
式,是指产品几乎只需要装配一下即可。就像盖房子一样,建筑者只需要把满足一定标准的各
式各样的预制板组装起来,即可建出符合标准的房子。这种模式可以大大提高代码的利用率,
使开发商不必一切从头做起,从而提高开发效率。而MSF是这一切的协调准则。
可喜的是,现在在国内已经有很多MSF应用或MSF思想得到认可的实例。比如,用友公司是
国内最著名的财务软件公司,以往大多是最终使用客户购买用友软件,而现在有很多系统集
成商来购买用友财务软件。这些集成商在用友软件的基础上开发出更能满足不同客户的千
差万别的需求的产品,帮助它们达到自己的商业目的。而用友只需提供财务软件核心,让其它
集成商在此基础上进行再开发。这对用友、集成商和客户都是有利的。此外,其它领域的公
司也有类似情形。MSF将结出越来越多的灿烂的果实。
Admin
2．组队模型
开发大型复杂的软件项目是一项充满风险的工作。统计结果表明大型IT项目的失败比例相当高，失败有很多原因：不断变更的需求，不稳定的或不完善的需求说明书，低质量的编码，过大的应用范围，不合适的组队模式，低效的工作过程，不明确的目标等等。微软解决方案框架结构（MSF）通过其核心模型来解决这些问题。组队模型着重于解决在复杂软件工程项目中如何组建项目组、分配合适的角色、项目组的管理、职责划分和质量控制等问题。虽然组队模型是起源于软件开发过程中的规范和准则，但它也同样被成功的应用于基础信息结构设施的实现过程。
简介
开发大型复杂的软件项目是一项充满风险的工作。统计结果表明大型IT项目的失败比例相当高，失败有很多原因：不断变更的需求，不稳定的或不完善的需求说明书，低质量的编码，过大的应用范围，不合适的组队模式，低效的工作过程，不明确的目标等等。 微软解决方案框架结构（MSF）通过其核心模型来解决这些问题。组队模型着重于解决在复杂软件工程项目中如何组建项目组、分配合适的角色、项目组的管理、职责划分和质量控制等问题。虽然组队模型是起源于软件开发过程中的规范和准则，但它也同样被成功的应用于基础信息结构设施的实现过程。
2．1 MSF 组队模型
--------------------------------------------------------------------------------
高效项目组的特点 一个高效的项目组能够赋予项目组成员权力、并明确他们的责任。明确的责任与权力会消除获得成功过程中的障碍，并使项目组成员专注于自己的工作目标。
高效的项目组能够保证项目的目标和进度可以达到。每个项目组中的成员根据他所负责的任务进行时间、进度的估计和安排。
项目组中的每个成员都需要理解客户和最终使用者的需求，这样他们就能够基于使用者和客户的期望作出良好的决策。
--------------------------------------------------------------------------------
高效项目组的质量目标 高效项目组的质量目标：
满足客户的期望
在项目的限定条件下交付产品
在交付产品之前，确定并解决所有对客户和最终用户来说都很重要的问题
保证使用者知道如何使用这个产品
确保产品的平滑移交与发布
2．2 MSF 组队模型由六个明确定义的角色组成：
开发
测试
系统实施
用户教育
产品管理
程序管理
项目组成员之间无限制的交流是一个潜在的成功因素。
除了系统实施角色外，其他角色在众多的微软产品开发组中都可以见到。对大型企业的IT机构来说，可能还有其它的用于补充项目组的被称为“支持角色”的人员，如：数据库管理员、产品质量监督员等。
图1. MSF组队模型
企业基础信息设施结构实现的项目 类似与软件开发，MSF组队模型同样也可以应用于企业基础信息设施结构实现的过程。在这种情况下，“开发”这种角色的工作将包含技术评估、产品或服务的安装和配置等。
2．3同等关系的组队角色
--------------------------------------------------------------------------------
同等关系的组队角色 MSF组队模型定义了相互依赖、相互协作、同等角色关系的工作模型。每个组中的成员在项目中都有一个明确定义的角色，并且关注于一种特定的任务。这种方法鼓励各个角色的所有感，最终结果是产生更好的产品。每种角色小组的领导者负责管理、指导和协调，小组中的成员专注于执行他们的任务。
基于项目的大小，每个角色被分配给一个人或有人领导的一个小组。同样，一个人也可以承担多种角色。
每个小组成员都要估算他自己的工作量，估算的结果用于作为他们各自角色的项目计划参考，各个角色的项目计划又是项目总体计划的一部分。
在一个成功的项目组中，每个成员都要感觉到对产品的质量负有责任。不能出现由一个小组成员代表另一小组成员对质量负责的情况。类似地，每个小组成员都是客户利益的维护者。
--------------------------------------------------------------------------------
同等关系组队角色的特点 成功的应用同等关系的组队角色模型将有以下特点：
各个角色之间相互依赖、相互协同的工作
每个成员都有明确定义的角色和特定的任务
组长负责管理、指导和协调
每个人都关注于自己任务的执行
交流不受限制
每个人都对交付产品的质量负责
每个工作组成员都在维护客户的利益。
--------------------------------------------------------------------------------
组队模型不是组织结构图 有一个关于MSF组队模型的问题：谁是主管？
MSF组队模型定义了角色和责任，但没有定义项目组的管理模式和结构。项目组可以由一个部门经理负责管理，或根据项目的需要由几个不同的部门成员组成。组织结构图确定出谁是主管，MSF组队模型定义了工作划分和由谁负责完成该项工作。
--------------------------------------------------------------------------------
采用MSF组队模型的优点 项目组的每个成员都为产品的成功作出贡献。
建立了一种鼓励“明确、高效、参与”的企业文化。
增强所有角色的责任感。
鼓励一种面向客户的开发过程。
MSF组队模型的这些优点已经被使用这种模式的组织机构所证实，其中包括微软公司。
--------------------------------------------------------------------------------
实现MSF组队模型的条件 为在企业机构内实现“同等关系的组队模型”，企业机构必须理解以下原则：
应用“同等关系的组队模型”并不需要重新定义企业的组织机构。
每个项目组中的成员，都要感到他们的工作是同样重要和有价值的。
所有项目组中的成员（或至少要求项目组的负责人）要为项目开发的全过程作出贡献。
每个组中的成员都要对产品或服务的质量负责。
产品的质量是由客户的需求或期望确定的。
注: MSF组队模型可能由于文化背景的不同，不能被所有的组织机构或地区采用。成功的关键在于每个MSF组队角色的目标在项目组中都有人负责实现。
2．4 MSF 组队角色
产品管理
--------------------------------------------------------------------------------
产品管理的任务 产品管理负责为产品或服务确定一个方向，获取并量化用户的需求，开发、维护商务关系和商业环境，并管理客户的期望值。
这种角色的目标是确保清晰地表述客户的期望值，并使其为项目组所理解，并使功能规定与客户的业务优先级相吻合。产品管理负责“前景陈述文档”。“前景陈述”表达了要开发产品或要实现服务的关键商业目标，（例如“顾客必须要在60秒或更短的时间内完成退房手续”）。产品管理负责项目的高层次交流和协调，如商务立项、项目费用、合同谈判、演示，以及产品定位。
--------------------------------------------------------------------------------
产品管理所需的技能 产品管理这种角色的成员无须具备开发技能，但是他们应该对技术有深刻地理解并知道技术会给目标客户带来哪些潜在收益。最重要的是，产品管理这种角色应该以用户的语言说话，并具有商业领域应用的经验。目标客户中能够理解自身业务的人将是项目组产品管理角色较合适的人选。
--------------------------------------------------------------------------------
产品管理在软件开发组中所担任的角色 收集项目需求并确定其优先级
将量化后的使用者和客户的需求讲解并提交给项目小组
为产品确定方向
确保功能规定能够体现业务需求
协调项目组与外部的交流，如：
商业立项
给客户群体作演示
将功能特性集成
产品的定位与范围确定
费用和合同的谈判
管理产品中非软件元素的集成与交付（例如，参考卡片、模板等等）
推出一个合格的产品
2．5程序管理
--------------------------------------------------------------------------------
程序管理的任务 程序管理的任务是控制决策的各种因素，以保证在合适的时间推出合适的产品。同时程序管理创建功能规定文档，并将它作为如何实施产品或服务的一种决策工具。最后程序管理将面对，使产品或服务与组织标准和操作目标相一致的日常协调工作。
程序管理是一个关键的交流与协调的角色。基于前景陈述文档，程序管理勾画出并维护功能定义。程序管理负责所有与分析、定义和系统结构相关的活动。在开发人员的配合下，程序管理必须确保功能规定在现有的资源下，技术上是可以实现的。
定义项目如何与外部标准相协调，并使外部群体参与项目的审查过程。
维护与外界的技术合作与交流，这是确保开发小组不受外界干扰，并有效工作的一个关键因素。同样它也会使项目组能够发现并重用其他人的工作。
在特定发布所包含的功能完成后，对功能规定进行修改控制。
合并各个角色小组产生的项目进度，并管理主进度（每一个项目组中的成员都有义务，根据他们的职责在整个项目中安排他们自己的时间进度）。
--------------------------------------------------------------------------------
程序管理所需的技能 程序管理需要具有很强的技术能力，以与开发人员相配合作出关键的决策。他们需要理解项目体系结构的实质，他们常常是项目组中最有经验的成员。程序管理必须跟踪项目的进展。另外，程序管理还需要具有很强的交流和讲解的才能，以便更有效地进行协调和谈判。
--------------------------------------------------------------------------------
程序管理在开发组中所担任的角色 根据其他组的负责人提供的信息创建功能规定：
定义产品如何与外部软件系统及组件互操作。
执行产品规定的技术审核。
对功能规定文档进行修改控制。
在每个项目里程碑处，协调项目组的审核；如有必要对进度和功能进行调整。
跟踪项目进展并管理项目进度。
交付一个合格的产品。
2．6开发
--------------------------------------------------------------------------------
开发的任务 开发的任务是构造或实现一种满足规定和用户期望的产品或服务。
开发这种角色是用于交付一个完全服从讨论过的功能规定的系统。这种角色很重要的一个方面就是积极地参与构建功能规定的过程。与瀑布式过程模型中的开发继承功能规定的方式相反，MSF组队模型中开发组的负责人与程序管理一起工作，共同构建验证结构的演示模型，提供技术解决的方法，探索设计中的各种选择。当功能规定成为基准线后，开发角色开始承担负责开发时间计划的责任。
在软件开发的项目中，开发也负责审查测试计划。开发必须及时改正程序中的错误，对代码的质量负责。
在基础信息设施实现的项目中，软件是购买而不是开发的。开发角色的任务是提供各种选择的技术评估、构造演示环境、配置系统、并集成新的方案到现有的基础信息结构设施中去。
--------------------------------------------------------------------------------
开发所需的技能 客户机—服务器系统的开发，需要熟悉C语言编程、Microsoft Visual Basic编程、网络、通讯、数据库设计和数据库性能调整。尽管一个人不可能在所有这些技术方面都是专家，但是在一个开发组中包含所有这些方面的专长的开发人员非常重要。开发的经理通常是一个有系统结构实现经验的总体设计师，或者是一个在项目的所有技术领域里能够理解和懂得关键问题的开发人员。
--------------------------------------------------------------------------------
开发在开发组中所担任的角色 积极地参与功能规定的创建和复查。
与程序管理一起工作，构建验证概念或结构的演示模型。
创建“自下而上”的开发进度表。
审查测试计划。
开发和构建产品（代码的集成编译可以由测试来执行）。
及时地找出和修改代码错误。
交付一个高质量的产品。
2．7测试
--------------------------------------------------------------------------------
测试的任务 测试的任务是保证产品或服务交付之前，能够发现所有存在的问题。
测试要准备测试计划、测试规定和测试的案例，这些文档用于拓宽测试范围和进行足够的可使用性测试。在软件开发的项目中，测试必须针对所有的接口，包括用户界面和API的每个方面。将新软件集成到现行系统时也必须进行测试。测试人员通常开发自动测试程序，这样开发人员在把代码提交给测试人员以前，就可以使用它们对自己的代码进行测试。
测试要管理错误跟踪数据库，并对错误报告的质量负责。错误数据库对于产生针对进度跟踪项目状态的统计报告来说，是一种重要资源。错误报告也用于确定项目进度中的、关键部分的风险。
测试这种角色必须独立于开发才是真正有效的。联系时间进度，测试需要提供产品质量稳定性的独立验证。
注 重要的是要认识到测试不仅是包含代码上的，测试还应用在功能规定、系统的性能、用户界面和实施计划上。
--------------------------------------------------------------------------------
测试所需的技能 测试组必须由一个熟悉测试过程、统计学和软件开发的人来领导。由于大多数测试组要编写自动测试程序，所以一个好的测试经理必须也是一个有经验的开发者，他必须胜任领导同样大小的一个开发项目。对于客户机—服务器系统来说，测试计划和过程可能很复杂。他们必须考虑到桌面系统的用户配置特性、网络问题、桌面系统连接问题。对于事件驱动的编程、多网络传输协议、不同的服务器、主机或者后台系统互操作问题、数据和数据库管理问题等，测试工作可能会变得更为复杂。测试组必须认识到应用配置之间复杂的相互作用。
--------------------------------------------------------------------------------
测试在开发组中所担任的角色 开发软件测试计划、规定和测试的案例。
测试用户界面、应用程序接口。
开发和维护自动测试程序。
跟踪所有的错误和问题，保证它们在产品提交以前被解决。
构建并管理产品的集成和控制（同样也可以由开发来完成）。
提供给开发组与产品质量、进度和风险相关的测试衡量数据。
交付一个高质量的产品。
--------------------------------------------------------------------------------
测试对比质量保证 测试与质量保证有着重要的区别：测试针对一个项目，包含详细的技术工作，它是项目组的一个核心角色。质量保证通常是公司的一个职能部门，它在一个负责企业质量和标准实施和监督的人领导下工作。质量保证也负责在不同的项目组之间共享最好的实践经验。
2．8用户教育
--------------------------------------------------------------------------------
用户教育的任务 用户教育的任务是通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和服务的价值。用户教育的第二个任务是通过使产品更容易理解和使用，降低系统技术支持的费用。
作为使用者利益的倡导者, 用户教育参与系统和用户界面原型的设计和构造，也包括程序的安装过程。用户教育也开发伴随系统的打印文档或电子联机文档。如果需要的话，用户教育还要准备并交付系统的培训材料。
通过推动和参予产品的可使用性测试，用户教育与程序管理在设计用户界面的过程中有着紧密的联系。用户教育也同程序管理和开发一起工作，确保产品的范围、设计的任何改动，反映在文档的内容中，并相应的调整培训内容。
--------------------------------------------------------------------------------
用户教育所需的技能 用户教育必须熟悉用于编写产品打印文档和联机帮助的工具。他们必须能够理解并实现项目要求的系统方案演示。这包括对现有系统和未来系统的分析，帮助有效地做演示系统的设计。
因为培训是最终产品或服务的一个组成部分，用户教育也必须胜任教学和教学设计的工作。
--------------------------------------------------------------------------------
用户教育在开发组中所担任的角色 设计和开发系统的展示手段，如联机帮助、工作指南、智能帮手等。
进行使用者分析。
编写用户手册。
设计和开发展示、宣传和评估的方法。
参与产品使用性测试。
创建培训计划和相关材料、环境。
培训用户。
交付一个高质量的产品。
注 演示方案在任何产品中都是非常重要的因素。因此在项目初期阶段，用户教育这个角色就必须紧密地加入到项目组工作中去。
2．9系统实施
--------------------------------------------------------------------------------
系统实施的任务 系统实施的任务是确保产品平稳地过渡、安装和移交到产品操作和技术支持组手中。
--------------------------------------------------------------------------------
系统实施在软件开发组中所担任的角色 确保产品从开发到使用操作的平稳移交。
开发系统操作相关的过渡、安装和技术支持计划。
与开发经理一起工作，把系统初始化需要装载的数据打包，便于系统的安装和管理。
与日常操作人员协调工作，考虑：
系统的日常管理，包括局域网和服务器的管理。
灾难恢复计划。
热线技术支持。
用户注册和帐户管理。
系统安装和故障检修。
跟踪系统特性增强的要求和系统故障记录的情况。
适合的软件和文档版本控制策略
交付一个高质量的产品。
--------------------------------------------------------------------------------
项目管理 MSF组队模型不是一张组织机构图，但是大多数业务都要设立一个对开发的产品或服务负有组织责任的“项目经理”。这个经理和MSF组队角色中每组的组长一起工作，共同构成一个项目管理组。通常根据企业的组织结构，项目经理可能是使用系统的商务部门主管或信息电脑主管。项目经理与组队模型中各角色的负责人一起共同承担项目中应用MSF组队模型和过程模型的责任，完成时间进度和资源的安排、风险估计和计划跟踪、监控等等。项目经理是项目的维护者，他将帮助开发小组得到获得成功所需要的资源。但是项目的日常管理工作是各个角色组组长们的责任：
所有的组长都要参与功能规定文档的讨论，对功能规定基准线的任何改变建议都必须为全体组长所接收。
不再是自顶向下强制性地估计出时间表，而是每个主要成员贡献出自己的时间进度估计，共同组成总体的时间表。
作为项目的推进者，每种角色的组长都有责任评估风险，并参与项目决策、权衡的决定。
--------------------------------------------------------------------------------
支持的角色 有些项目或业务可能需要其它的专业人员来扩展组队中的角色。这些辅助支持的角色可能包括：
系统结构设计人员
系统使用性专家
用户接口设计者
科学研究人员
数据库管理员
2．10小组模式
--------------------------------------------------------------------------------
小组模式 MSF组队模型不同于其它的组队方法，非常重要的一点是MSF提倡使用小的工作组。在开发复杂的技术产品时, 大规模的项目组需要非常多的“过程开销”来满足交流的需要。同样项目组应该在同一个地理位置上，智力产品的开发极大地依赖于组内成员之间的高效交流。如果测试组在一个地方，而开发组在另一个地方就很难取得成功。如果用户教育不接近程序管理和开发，那么系统用户教育工作的质量也将得到反向的影响。
MSF组队模型是一个同等关系的组队模型，项目组中的每个人都对产品质量负相同的责任。同样当项目组负责人没有获得作出影响他们成功或失败的关键决定的权力时，项目组也会失败。在软件开发项目中，同等关系的概念也被应用到开发人员/测试人员的比例上。
微软公司中多数开发组在项目开始时，开发人员与测试人员的比例就是1:1。而其他外部的许多项目也许只需要2:1或者3:1的比例（开发人员：测试人员），在开发包含多种复杂接口的复杂的客户机/服务器系统时，开始前的全职测试队伍也要考虑在内。
最后MSF的组队模型假设项目组有权作出获得成功的相应决策。当一个小组人数多于六人的时候，将会有多个人被赋与某些角色。他们可以被组织成共享一个角色的功能小组。
--------------------------------------------------------------------------------
在大型项目中的小组工作模式 大多数情况下每个功能小组（如开发，测试或用户教育）的人数应该在三至七人之间。如果因为问题的复杂性，任意一个角色需要更大的组时，程序管理和开发应该将把问题分解成较小的、容易管理的部分。在微软公司强调模块化、结构化和规定的接口，不仅仅因为它们是好的实践经验，而且也因为它们能使项目更有效地进行管理，从而降低风险。
跨功能的工作小组可以为整个项目的一个子集工作，就象是为独立的产品工作一样，这些小组成为组件小组。
在基础信息结构设施实现的项目中，组件小组可以体现为在不同的地理位置上进行系统实现和产品装配的工作小组。
--------------------------------------------------------------------------------
组件工作组 组件小组通常包含一个程序经理、多个开发人员、测试人员和用户教育人员，他们对开发一个特定产品的功能集负责。每个组件小组都有自己的功能定义和时间进度表，并且严格地执行这个时间进度表，以交付一个完整的产品。如果可能整个组件小组应该在相同的办公地点工作，这样能便于交流和解决与他们工作相关的问题。
大型项目可以从这种模式中受益。当一个项目组被划分成许多组件小组时，组件小组中的成员也是大的职能组的一部分--如开发和测试，这些大的职能组可以共享开发技能和知识、通用的工具和资源。
Figure 2 Component Teams
在小项目中的小组工作模式 每个项目中决定如何构造一个项目开发组，是规划项目过程的一个组成部分。上面描述的六种角色反映出在一个项目组中必须具备的六种职责。然而软件开发准则并不是说，在项目组中必须要有六个成员。在有些情况下，一个小组成员可以承担两个或更多的角色，而这种情况一旦出现，就要认真考虑这些角色安排在这个人身上是否必要。
Figure 3 Combining Roles on a Small Project
组队成功的因素 任何组队方式的成功，都可以由以下的因素体现出来：
有经验的负责人
自我激励的组队成员
组队成员在同一个地理位置
每个组队成员都有权作出决定
制定明确的目标
所有组队成员都胜任自己的工作
--------------------------------------------------------------------------------
小组模式的优点 组织、分配项目的人力资源为多个小组，具有以下几个确保项目成功的主要优点：
降低交流阻塞
降低过程开销
降低管理的费用
更快地进行实现
高质量的产品
2．11外部的协调
--------------------------------------------------------------------------------
项目组外的工作组 产品管理、程序管理、测试、用户教育和系统实施角色都具有重要的外部协调责任，这些责任包括与下列人员的协调：
商务或项目管理
使用者
系统操作和支持
系统标准制定
前台帮助支持
企业总体信息结构策略
质量保证标准制订
3过程模型
在微软解决方案框架结构的词汇定义中，框架（framework）指根据实际问题的映射模型，开发出的应用程序组合。根据当前问题的实际情况和队中成员的技能水平等，在项目进展过程中作适当的调整非常必要。MSF过程模型包含四个主要的里程碑，它们是前景/范围认可（Vision/Scope Approved）里程碑、项目设计认可（Project Plan Approved）里程碑、范围完成/第一次应用（Scope Complete/First Use）里程碑和系统发布（Release）里程碑。这四个里程碑是客户与项目组之间重要的设计、评估和协调的同步点。
3．1MSF过程模型
--------------------------------------------------------------------------------
MSF过程模型 MSF过程模型包含四个主要的里程碑，每个里程碑都是一个阶段的终结点。
预想和构思阶段在“前景/范围核准”里程碑上到达了终结点。一旦一个新的产品（在信息基础设施实现的项目中，这样的产品可能是某项服务）吸引了大家的兴趣并得到了允许构建的批准后，项目组开始集中起来定义产品。前景描述文档清晰地阐明了产品或服务的最终目标，并提供了明确的方向。范围与前景相反：它定义了一个特定版本产品或服务所受的限制，并且认识在未来的版本中将要进行的开发工作。
设计阶段在“项目设计核准”里程碑上到达了终结点。项目设计包含功能规定文档、每种角色职能组的计划组合（如在MSF组队模型中定义的开发、测试、用户教育、系统实施、程序管理和产品管理）和时间进度安排。功能规定提供给项目组足够的细节情况确定需要的资源并作出承诺。在项目设计核准里程碑上，客户和项目组在要交付的内容上及如何进行构建达成一致。这是一个重新评估风险、建立优先级和对时间进度和资源调配情况做最终估计的非常重要的机会。
开发阶段在“范围完成/第一次使用”里程碑上到达了终结点。经过核准的功能规定和相关的项目计划提供了开始开发的基准线。开发组设置了一系列内部交付的里程碑，每个内部里程碑都要经过全部的测试/诊断/排错的过程。在这个里程碑上客户和项目组评估产品的功能，验证产品过渡和支持计划。同样在这个里程碑上，所有新功能的开发都已经结束，推迟开发的功能记录下来作为下一个版本功能的参考。
稳定阶段在“产品发布”里程碑上到达了终结点。测试工作是伴随着代码开发工作进行的，在稳定阶段因为集中注意力于寻找错误和修改错误，所以测试活动成为主要的工作。在产品发布里程碑，产品正式转交给操作和支持组。通常情况下，项目组或者开始下一个版本的产品开发，或者拆散 加入其它的项目开发组。
Figure 1: The MSF Process Model
这四个里程碑是客户与项目组之间重要的设计、评估及协调的时间点。这些里程碑上交付的内容在里程碑代表的阶段结束后，被置于一种可变控制的状态下。可变控制是一种从需要改变到最终稳定的文档或代码，并获得一致同意的过程。这些交付的内容必须被置于可变控制状态下，保证整个项目组在共同的假设、指南和目标基准线情况下工作。
--------------------------------------------------------------------------------
过程模型的定义 过程模型描述的是系统开发的生命周期内各种顺序进行的活动。
3．2MSF过程模型的特点
--------------------------------------------------------------------------------
MSF过程模型的特点 MSF过程模型在下面的许多方面不同于传统的开发模型：
强调“系统前景/范围”，而不是需求。
面向客户的里程碑，而不是面向开发的里程碑。每个里程碑是项目组重新校准客户期望值的同步点。
不同版本方式的发布，而不是第一版就包含全部的功能特色，快速变化的技术会不断增强系统的功能，强化PC使用者的能力。不同版本的发布方式在基于PC的计算环境中是良好的平衡投资的方法。
--------------------------------------------------------------------------------
内部的里程碑 除非交付的整体时间进度少于三个月，否则仅有四个里程碑的项目计划并不能够提供对一个重要项目的控制。在MSF过程模型中，每个组队角色的负责人要在一起讨论和承诺内部的里程碑。通过这种方法达到整个项目组定期了解项目进展中存在问题的目标。
这些内部的里程碑帮助逐渐的构建主要的外部里程碑，它是MSF过程模型的一个关键特色。许多软件开发项目失败的原因是它们没有足够的项目范围的定义。当项目范围太大时，这些项目就象被“黑洞”吸引住了一样，项目开发工作进展的过程中永远没有可见的进展。在一个大的或复杂的项目开始的时候，确实没有办法精确了解真正的项目范围，通过规划和设计的过程逐渐减少了初始范围中不能完成的内容，所以很难有保证使项目完全按计划进行。就象艾森豪威尔说过的话“没有根据计划打赢的战役，但没有战役是在没有计划的情况下打赢的。”
为解决这种局面的方法就是设置经常的检查点，使项目的范围根据用于构建和测试产品的新信息不断地进行重新评估。这样会发现新的或正在发展中的风险，在这些风险失去控制前就能够进行处理。尽早地了解项目存在的重要问题，能够提供给项目组更好的控制项目范围中存在的问题和影响发布日期的风险的能力。
在软件开发项目的开发过程中，内部里程碑是一系列定义明确的功能集代码发布的时间点。每一个这样的发布都将以一个完整产品的发布来看待，每个发布都要经过测试、排错的完整过程。这种过程能够稳定代码，并提供给项目组了解项目进展过程和预定时间进度规划之间关系的可靠信息。在这些内部里程碑上所有的错误被修复非常重要，不能修复的错误代表着对于不明确的范围而做的不完整的工作，这将会造成对任何时间进度估计可靠性的影响。
3．3过程模型
--------------------------------------------------------------------------------
框架对比方法论 在MSF的解释中，框架是由根据反映实际存在问题的模型构建的应用组成的。根据目前手上的问题，项目组成员的技能等做作适当的改变通常是必要的。
方法存在于过程之中，它是针对完成某项任务的详细描述。方法论是一种包含一整套预先规定好的方法的过程。方法论可能会适合或不适合眼前的项目，它们往往具备多于必需的过程。
应用MSF参考模型较传统的方法论比较，提供了更多的弹性。
--------------------------------------------------------------------------------
瀑布式过程模型 在传统的阶段模型中，如软件开发生命周期方法--Software Development Life Cycle (SDLC)，阶段的定义暗示着每种工作的集合必须完成后，下一个阶段才能开始。任务驱动的开发生命周期通常导致具有以下特点的瀑布式的过程模型：
在项目或产品的生命周期内，不同的工作组处理不同阶段的任务。
每个阶段的工作必须详细记录下来，以保证新的工作组能够接管旧工作组离开后的全部工作。
关键的决定必须尽早地确定。
测试仅仅发生在项目快要结束的时候。
在软件开发过程中，组队有效工作的一个关键因素是组队成员间是否能够有效的交流。当不同的工作组管理工作过程的不同部分时，交流的手段被严格地限制在记录文档上，写作和阅读这样文档所花费的时间非常昂贵。在整个过程中重要的信息可能已经丢失或省略，决策的许多内容不能很好地交流。随着项目的一个个连续的过程，项目组距离在项目最初阶段获得的客户需求越来越远。
使用了瀑布式过程模型的大型复杂项目，在时间进度和质量上隐含着许多不确定的因素。开发组可能很长时间内在黑暗中摸索前进，没有任何真正对进展的评估，问题隐藏在代码中。结果导致重要的错误往往在项目即将结束时，才呈现在大家的面前，而这时的修复错误的费用将会最高，这些错误对产品发布的时间影响最大。
最后，瀑布式的过程模型侧重于将精力集中在客户的初始需求上，而不是集中在技术发展能够为使用者提供更佳能力的前景上。这似乎没有什么，但认识到任何方案的最终质量可能依靠最终用户的想象不到的内容，这一点非常重要。一个高质量的解决方案是在明确了解企业商业需要的前提下，选择合适的技术加以匹配的、一系列确定的前景定义的结果。良好的过程模型能够管理超出客户明确定义的使用者需求集合。
--------------------------------------------------------------------------------
存在的问题 开发智力和知识产品会面对特别的挑战。创造性工作从本质上来看更难预料，更难以按时间进度进行。与大多数商业过程不同，高压控制的方法论可能会抑制创造力，产生不良的结果。
相反走另一个极端，拥有太多自由并没有明确责任的过程将会带来其他问题。一个工作组可能失去对重要工作的关注力，而更多地从事他们认为能发挥灵感的项目工作。有时这样做是有益的，但如果这些有创造力的工作总是偏离最重要的目标，项目就会走入歧途。所以一个好的过程应该包含经常的里程碑，来保证项目组集中注意力于正确的任务上。
MSF过程模型与MSF组队模型结合在一起，被设计成为能够最大的提供创造力和项目注意力的模型。
3．4过程模型中的里程碑
前景/范围核准里程碑
--------------------------------------------------------------------------------
定义 前景/范围核准里程碑是客户和项目组就项目的前景和范围达成一致的机会。
--------------------------------------------------------------------------------
Figure 2: The Vision/Scope Approved Milestone
前景对比范围 确定前景和范围是两种对立的活动，但却都是一个成功项目需要的两种活动。前景是对方案是什么的一种扩展观点。范围定义了在当前项目的条件限制下，前景中的哪个部分可以被实现。
--------------------------------------------------------------------------------
交付的内容 前景陈述文档是在组队角色其它成员提供信息的前提下，由产品管理角色组共同创建的。
设计目标文档提供了对产品范围的看法，它可以由程序管理或产品管理来创建。这份文档应该确定在功能规定设计过程开始前，需要解决的问题和征求的意见。
风险评估是随着项目的进展过程更新的动态文档。这个文档确定了可能影响项目进展过程的、将要到来的技术和组织机构上的问题。
项目组织结构文档定义了项目组的管理结构，它勾画出向项目设计认可里程碑前进的结构。
3．5项目设计认可里程碑
--------------------------------------------------------------------------------
定义 项目设计认可里程碑是客户和项目组就交付的内容、构建的优先级和期望值达成一致意见的重要机会。它提供了重新评估风险和重新验证早期对时间进度和资源使用估计的机会。
项目组的每一种角色都提供一份计划和时间进度文档，用于描述如何构建功能规定中的产品。项目计划精炼了前景/范围文档中客户和项目组达成一致意见的部分。所以一份好的项目设计和计划是：
从商业整体目标、使用者分类和每类使用者期望执行的活动中得到的。
将客户的期望分类成一系列的逻辑服务：用户服务、业务规则服务和数据服务。这些服务统称系统的逻辑结构。
明确定义界面设计、功能接口、数据需求、帮助系统和培训过渡活动等。
定义外部接口、交互性目标、性能指标和其它应用到解决方案上的假设和限制。
反映组队角色所有成员一致的承诺。
控制内部的时间进度和外部交流。
Figure 3: The Project Plan Approved Milestone
交付的内容 功能规定描述了交付的产品具有什么样的功能，它是这个里程碑上最重要的交付。
风险评估是由项目组的组长们根据已知的问题不断复查和更新的。
项目计划是每种角色计划的集合。根据功能规定中的任务，将其分组成主要的内部里程碑。项目计划的内容中包括方法、依赖条件、假设、预算和费用信息。
项目时间进度由每种组队角色的时间进度合并而成，所有角色的时间进度都基于开发的时间进度。
3．6范围完成/第一次使用里程碑
--------------------------------------------------------------------------------
定义 当进入全部产品的第一个beta版时，就来到了范围完成/第一次使用里程碑。这个版本的发布紧接着代码的完成和软件开发项目中的一系列测试活动。范围完成/第一次使用允许使用者评估产品，确定需要强调的遗留问题。同样它也是产品的第一次过渡和支持操作过程的测试阶段。
Figure 4: The Scope Complete/First Use Milestone
交付的内容 这个里程碑上交付的主要内容是全功能的代码，这些代码足够稳定可以用于Beta测试。
根据已知的问题，由各种角色的组长复查并更新风险评估。
由用户教育组设计的所有产品演示辅助方案和演示方案原型。
测试规定文档给出了与代码相关的各种测试的各个方面，并定义了特定领域的测试需求。
测试的案例描述出如何测试某一方面的代码，满足测试规定的要求。
在项目设计核准里程碑上给出的可变控制的、基于版本的功能规定，所有的改变都应该反映在功能规定中。
根据风险和已知的变化，复查和更新的时间进度安排。
3．7发布里程碑
--------------------------------------------------------------------------------
定义 当产品或服务发布、移交给系统支持和操作组时，就到达了发布里程碑。
Figure 5: The Release Milestone
交付的内容 可执行代码
发布的注释
不同版本的原代码
培训手册、文档记录和演示辅助工具
问题和错误数据库
安装的平台和工具
软件/数据的安装程序和转换迁移工具
3．8基于里程碑的方法
--------------------------------------------------------------------------------
为什么是四个里程碑？ MSF过程模型中的四个里程碑对应了项目开发的四个方面，当客户和项目组重新定位关系时，这四个里程碑同样代表了一个项目中四个正式的时间点。每个里程碑上交付的内容都是根据它们具有外部可见性而选择的。
基于里程碑的方法是一种重要的设计、评估和协调客户与项目组之间关系的过程。
--------------------------------------------------------------------------------
基于里程碑方法的特点 外部可见性
MSF过程模型中的主要里程碑是整个项目组同步他们交付的内容，满足客户期望的时间点。项目设计和交付的内容可能会根据项目结果不同而不同。当项目开始时不可能了解所有的事情，是项目开发过程中不可避免的。
里程碑是复查点，而不是冻结点
尽管可以通过选择一个特别晚的产品发布日期，达到完整预测项目的目的，但结果几乎所有这样做项目的费用都很高。MSF过程模型中的四个里程碑允许客户和项目组重新确认，或调整项目的范围和使用者的期望。
目标驱动的方法
里程碑上交付的内容包含了每一个阶段的目标。
明确的交流
组队成员间明确的交流是项目成功的潜在因素。
3．9管理风险
--------------------------------------------------------------------------------
风险评估 因为在项目计划时不可能了解所有发生的事情，所以对于开发组来说确定风险就成为一个关键的成功因素。开发和稳定阶段必须使用风险评估的手段，作为时间进度安排的基本设计规划假设。
--------------------------------------------------------------------------------
风险控制的时间进度 风险控制的时间进度安排是指在项目中风险程度高的部分优先开发的方法。无论是软件开发项目还是基础信息设施实现项目，风险控制的时间进度安排都很重要。
Figure 6: Risk-Driven Scheduling in the Developing Phase
风险控制的时间进度安排的好处 鼓励尽早的建立体现概念理解的原型
确定何时完成何种功能特色
根据技术和业务的风险，对工作任务进行优先级划分
在每个里程碑上进行风险复查
风险控制的时间进度安排的一个优势是，在高风险的部分需要比原计划更多的时间时，可以提供更灵活的响应时间。
--------------------------------------------------------------------------------
风险控制的时间进度安排的实现方法 项目组和客户对如下风险的优先级达成一致：
技术风险 - 保证潜在风险的功能尽早完成
商业业务风险 - 保证对商业业务非常重要的那些功能被强调
开发的时间进度将包含一个或多个内部发布
和最终发布一样，每个内部发布中都包含发布的管理和测试。
--------------------------------------------------------------------------------
降低风险 SDD鼓励在到达项目设计认可里程碑前，开发验证概念的模型和原型，这将降低不好的时间进度估计带来的风险，避免项目的失败。
--------------------------------------------------------------------------------
优先级划分的时间进度安排的优点 开发人员积极地工作以满足规定的时间进度，而不是延伸开发工作，以填充考虑风险因素在内工作时间。
错过进度安排中的里程碑，将作为早期的警报提供给项目管理人员，从而作出调整和权衡的准确决定。
客户对项目中出现风险的地方有明确的理解，因此他们的期望能够更贴近实际，更有生产价值。
3．10版本发布
--------------------------------------------------------------------------------
综述 版本发布的概念是过程模型的一个重要部分。它能够帮助项目组响应功能、时间进度和风险等方面的变化，它同样也确立了对版本一这个基准线不断增强的阶段。
MSF过程模型鼓励项目组将正在开发中的项目，想象成为一个产品，将新特色的开发和旧特色的维护作为不同版本的发布。这种概念会影响如何设定期望，以及整个项目如何设计、规划和管理。
--------------------------------------------------------------------------------
定义 第一个版本的发布交付了一系列核心特色。随后的版本发布逐渐增加新的特色，直到完成了产品的全部前景和期望。
Figure 7: Versioned Releases
不同的版本发布不一定需要前后衔接（也就是版本1发布后，版本2才开始）。当项目组成熟后，他们通常会采用重叠的发布方式（在版本1发布前版本2就开始了）。
--------------------------------------------------------------------------------
需要一个跟踪的系统 管理不同版本发布的过程需要一个跟踪系统。这个系统应该包括记录：
排除在当前版本范围之外的、分析设计过程中提出的想法。
在功能规定中确定各种特色的优先级，能够帮助开发组将注意力集中在高优先级的功能特色上。
在当前版本中存在的问题和一些不重要的错误，可以按优先级划分后在下一次发布中解决。
--------------------------------------------------------------------------------
版本发布的优点 版本发布实现方法的主要优点是：
在项目的范围内管理不确定的因素和变化
为项目组所有成员确定明确的和有激励性的目标
强制结束项目中的问题
鼓励连续的和不断补充的功能特色交付
促使更短的时间内交付
3．11质量优化
--------------------------------------------------------------------------------
确定的发布时间想法 一个确定的发布时间想法的实现需要在范围、时间进度和可靠性三个方面作出权衡。
不是每个项目都可以用时间来控制。
不是每个项目都可以用功能特色来控制。
不是每个项目都需要没有任何错误的解决方案。
--------------------------------------------------------------------------------
作出权衡 当一个产品在开发时，在功能特色（范围）、时间进度和错误修复三个方面作出权衡通常是不可避免的。使用不断补充的系统或产品发布方法，允许根据客户的要求作出权衡，实现这些目标间的权衡。当客户的期望满足或超出后，产品质量目标就达到了。
--------------------------------------------------------------------------------
范围的调整 大多数的项目会从确定的发布时间想法中受益。如果发布的时间不断推迟，项目组将很难具有效率。多数情况下，最好一点一点的调整项目的范围，而不是改变发布的时间。版本发布允许项目组在应用项目范围上更具有弹性，而且具有更强的能力提高产品或服务的质量。
4应用模型
微软解决方案框架结构中的应用程序模型，建立了一系列的标准和指南，用于设计分布式的、多层结构的客户机/服务器应用程序，并且通过使用微软基于组件的技术和工具进行实现。这些标准和指南的目标是提供一种通用的方法，实现跨越商业应用程序的组件重用性。
4．1微软解决方案框架结构--应用模型
--------------------------------------------------------------------------------
介绍 本篇介绍微软解决方案框架结构（MSF）应用模型。这个模型建立了设计分布式、多层结构的客户机/服务器应用程序的标准和指南，并通过使用微软基于组件的工具和技术进行实现。这些标准和指南的目标是鼓励使用跨越商业应用程序的重用性组件，构建企业商业应用的通用方法。
MSF提倡使用基于服务的应用模型，设计和实现客户机/服务器的组件和商业方案。基于服务一词意味着应用程序的功能被定义成完成特定消费者需要的、一系列服务的集合。在这个模型中，一个消费者可以是一个使用者或另外一种服务组件。因为反映了正在发展的技术趋势，所以这种模型非常引人注目。客户机和服务器的概念正在向更广义的概念发展--消费者和提供者，同样基于服务的模型也是一种看待商业应用的全新方法，以下的概念反映出微软和其它公司，今天构建核心组件技术的方法。
--------------------------------------------------------------------------------
内容 本篇分为四个部分：
总结使用MSF应用模型的优点。
讨论今天客户机/服务器应用程序设计者面临的一些挑战和应用模型的描述。
介绍MSF应用模型、模型主要准则和在当今多层结构应用程序设计方法中的定位。
深入讨论基于服务应用模型的设计方法，这包括用户服务、业务规则服务、数据服务的定义和如何使用组件技术实现这些服务。
4．2MSF应用模型的优点
--------------------------------------------------------------------------------
重用性、交互性和合作性 通过在企业总体应用程序结构中引入正式的应用模型，企业的项目开发机构可以增加跨越应用的重用性机会。采用基于服务的模型，特别会鼓励透过应用的功能重用。这种跨越功能的透视方法提供了适用性更强的方法，使更多的使用者能够更容易的应用很多应用程序，从而达到增加交互性和合作性的目标。
--------------------------------------------------------------------------------
重要的优点 采用MSF应用模型提供了以下这些重要的优点：
应用程序设计的连续方法 - 应用程序的规定或实现更具一致化，增强了重用的机会，使开发人员侧重于开发而不是重新定义标准。
管理分布式应用设计复杂性的模型 - 开发分化成小的、更容易管理的部分。通过实现严格的结构规定，这些小的部分可以在需要集成的时候集成在一起，提供了并行开发的机会。
应用程序内置的分散应用程序逻辑的能力 - 实现过程中良好的层次间隔，提供了更多的分布服务的机会。
降低开发和维护的费用 - 应用程序有可以提供的组件集成得到，可以降低开发的时间和复杂性。最差的情况下，一个一致的、正式的模型，也可以鼓励设计和规定的重用性。
更具鲁棒性的应用程序 - 在一个组件中封装相关对象的行为，可以帮助隔离问题。一旦一个组件通过测试，方案开发者就可以重用该组件，并可以认为这些服务具有鲁棒性。
平衡特殊的技能和工具 - MSF应用模型中定义的三类服务，紧密的映射了客户机/服务器应用开发的三个同等重要的技能集合。传统的客户机/服务器结构开发方法，通常将数据与使用者的界面和商业事务规则分离。
增强跨越应用程序的一致性和交互性 - 除非存在描述、定义和构建应用的一致模型，否则重用性的机会最多是随机的。通过采用企业范围的应用模型设计和开发商业系统，组件的重用性会更容易实现。
更容易采用新技术 - 分布式的、基于组件的实现方法使新的客户机和服务器技术更容易合并到一起。例如一组新的使用者服务可以应用新的交互技术（如声音识别技术或手写识别技术）进行开发，而不需要对应用程序中的核心商业事务服务进行改造。
提供开发过程中并行开发的能力 - 风险管理：MSF应用模型鼓励将开发工作分成小的、更易管理的部分，需要集成的时候进行集成，这样就提供了并行开发的机会。
MSF应用模型不是与特定的产品包、技术和商业环境结合在一起的，这能保证MSF适用于企业已有的、或设计规划中的“企业应用和技术结构”。
4．3问题和挑战
--------------------------------------------------------------------------------
挑战 一些挑战已经影响了MSF应用模型的开发：
从两层到多层应用程序设计的转移。
Internet和intranets的影响。
不断改变的用户界面设计。
--------------------------------------------------------------------------------
从两层到多层应用程序设计的转移 在过去的三年内，客户机服务器计算领域中已经产生了第二代应用程序设计方法，通常成为三层结构、多层结构或n层结构。这种新方法的目标是克服设计中存在的局限--传统、两层结构的设计方法不能满足大型的、复杂的、关键业务应用的设计（如图一）。多层结构设计的目标是提供给企业应用需要的高适应性、可伸缩性和可管理性，这些企业应用程序共同具有的特点是：必须分布于多个节点，构架在多个物理点之上，强调高可靠性，可以支持传统的联机业务处理系统，并拥有千记数的企业用户。
Figure 1: Design challenges for business applications
从两层结构到多层结构设计的转换，提供给应用开发机构的不仅仅是对构建两层客户机/服务器应用技术的增强。设计和实现分布式的、多层结构的应用，需要对应用到底是什么有新的理解，需要采用更严格的方法进行设计和规划，并且更细致的考虑如何分布应用程序的逻辑组件。
--------------------------------------------------------------------------------
Internet和intranets的影响 现在有非常之多的原因集成Internet的技术到企业的应用中去：
提供给应用程序对传统工作环境跨平台的支持。
为所有的商业应用建立一致的使用者界面风格和操作模型。
在World Wide Web上建立使用和维护的演示。
通过在internet服务器上的中心管理维护的应用程序结构，简化应用的部署和实现。
不止一种技术可以完成上述的目标。现在有很多不同的浏览器、internet服务器和在Internet开发数据库的工具。其中的一些工具提供了多层结构的方法，实现客户机/服务器应用。而其它的应用于传统两层结构的应用。
客户机/服务器计算环境的基本概念和原则非常适合Internet和intranets。成功地采用并融合internet技术到商业应用中去的关键在于，理解如何设计和实现应用程序，以保证不同类型的客户端透明地访问应用程序的核心业务逻辑。
--------------------------------------------------------------------------------
不断改变的用户界面设计 应用开发机构面临着有效设计和开发图形用户界面方面的问题，迅速改变的桌面和移动计算技术预兆着在商业应用中集成新技术的挑战。当企业机构使用的桌面应用不断发展时，使用者的期望也会提高 -- “为什么我们市场销售部门的业务系统，不能提供象我使用的字处理程序和电子表格那样的集成性和易用性呢？”
因为客户机/服务器计算环境已经超越了工作组和部门的范围，使用者的数量也相当大。对于40到50个用户组来说可以接受的用户界面，可能对500到1000的用户群就不适合。当应用程序的使用者数量增加时，使用者会有多种类型，每种类型的使用者都有自己独特的需求，所以设计应用程序必须满足不同的使用者界面或接口，具有相同的商业逻辑标准。
4．4什么是应用程序模型？
--------------------------------------------------------------------------------
强调逻辑设计的对应用程序概念性的观点 一个应用程序模型是一种对应用程序概念性的观点，它建立了组成应用程序的定义、规则和相互关系。它作为应用程序逻辑设计时，互相交换信息的基准线。应用程序模型是增强交流的简化的、直观的方式，重点强调在逻辑上，而不是物理上的。应用程序模型给出了应用程序的组成结构，而不是如何实现它。
举一个简单的例子，帮助理解应用模型的概念。当一些人提到房子时，我们会在不了解任何特殊情况时，首先假设这座房屋会有大门、卧室、浴室、厨房等等。即使特定的房屋与模型不同，模型也作为讨论功能和布局的一个出发点。
同样应用模型也描述了应用程序中包含哪些部分，以及这些部分做什么等通用问题。
--------------------------------------------------------------------------------
对应用模型的需求 MSF企业应用程序结构强调对应用程序模型的需要，这是因为应用程序模型构建了一套一致的理解和用语，用来描述应用程序设计，帮助系统的应用开发采用一致方法。
一个企业机构可以使用不只一个的应用模型，适应开发中的不同类型的应用程序。
4．5MSF应用程序模型
--------------------------------------------------------------------------------
MSF应用程序模型的目标 MSF应用模型是微软推荐的设计分布式、多层结构、客户机/服务器应用程序的方法。它的目标是：
为设计和开发客户机/服务器方式的、internet或intranets应用程序提供一致的方法，建立用于跨越所有客户机/服务器开发项目的开发标准和应用程序接口规定。
在三层结构的应用程序中，提供组成三层结构的应用程序逻辑定义的标准集合。
保证使用组件技术实现分布式的、多层结构的应用程序，使其具有可扩展性、可伸缩性和可管理性，以满足任务重要的、企业级的商业应用程序。
引入系统是由一系列构建于一致组件集合之上的、交互式应用程序构成的概念，这种思想打破了传统上单一的应用程序支持特定商业处理过程的观点和模式。
确定用于构建分布式、多层结构的客户机/服务器应用程序所需要的工具和技术，辅助企业总体技术结构的开发。
在拥有多个项目的应用开发机构中，描述出应用技能和资源的一致的方法。
定义组建项目组并确定所需技能的框架，保证项目的设计和开发过程中不同的工作组可以有效的、并行的工作。
4．6服务模式
--------------------------------------------------------------------------------
MSF应用程序的观点 MSF应用模型介绍了组织应用程序的一种新模式。MSF认为，应用程序是由逻辑网络上的“使用服务”和“提供服务”组成的，这些服务可以分布、跨越物理和功能的边界以支持许多不同的应用程序。
--------------------------------------------------------------------------------
服务的定义 服务是一种应用程序方法，实现某种操作或应用在对象上的功能和变化。服务可以增强商业业务规则，执行数据计算或操作，以及其它的输入、检索、查看或修改信息的可见的功能。
--------------------------------------------------------------------------------
三种服务的类型 为进一步提炼网络服务的分布特色，MSF应用模型定义了组成应用程序的三种类型的服务：
用户服务. 应用程序组成结构中提供接口交互的部分。应用程序的用户可以是一个人或另外一个应用，因此应用程序的接口可以是图形用户界面或者是一组可编程的接口。
业务规则服务. 应用程序组成结构中控制执行次序、增强商业规则和完整操作转换的的部分，业务规则服务通过应用程序中适当的商业规则转换数据为信息。
数据服务. 应用程序组成部分中提供最底层的、可见层次的用于抽象数据操作的部分，数据服务维护企业的连续数据和非连续数据的一致性和可管理性。它们提供创建、读取、更新和删除等服务，以便使业务规则服务（数据服务的消费者）不需要了解数据存放在哪个位置、如何实现的和如何访问的等问题。
Figure 2: A new view of applications
注意 理论上说，层次的概念将导致应用程序组成结构的独立实现，不管是分成两个或三个部分。但如果在多层结构设计中过于追求可伸缩性、可扩展性和可管理性，也往往会使编程工作十分困难。
--------------------------------------------------------------------------------
逻辑网络上的服务 在基于组件技术的实现中，通常不是物理的软件层，而是一系列分布在网络上的互操作组件，它们跨越物理边界提供服务给许多客户机。由于这个原因并防止单一的实现，MSF应用模型使用由用户服务、业务规则服务和数据服务构成的逻辑网络概念，描述应用程序的组成结构。这三种服务可以在任何客户机服务器应用程序中找到，一般情况下我们把它想象成有层次的（见图三）。
Figure 3: Mapping services to tiers
MSF应用模型关注于应用程序的逻辑结构，并没有侧重于将信息表示服务、数据库管理系统和存储管理服务考虑为层次，这些部分我们在企业总体技术结构中作为一个考虑的部分。
这种模型并没有强调功能模块如何跨越网络进行分布，它保留了设计者对服务进行收集、作为组件进行实现，根据物理设计分布在网络上的方法和自由度。
4．7打破传统观点
--------------------------------------------------------------------------------
传统的方法 传统应用程序是根据企业给定的功能要求开发出来的，它们支持特定商业事务流程的功能线。例如，订货处理、产品登记或销售和市场。每个这样的应用程序都独立开发，每个项目都独立地侧重于某一个部门的商业业务观点。
这种方法导致了生产出来的应用程序都是功能隔离的，所以许多应该具备一致功能特色和信息访问接口的业务应用程序，并不能协同工作或外观操作一致。当商业事务规则和信息访问方式改变后，每个遵循这些规则的应用程序都必须改变。
传统上组成系统的多种应用程序共享的部分往往是数据的共享。
Figure 4: Breaking the traditional view of applications
以服务为中心、组件为基础的方法 使用以服务为中心、组件为基础的方法，开发人员可以设计和实现交互操作能力更高的应用程序组成的系统，这些应用程序不仅仅能够共享数据，也能共享商业事务逻辑结构，并且能运行应用服务器上的共享组件和客户端的共享用户界面。
具备中间件技术如远程自动化和分布式COM特性的Microsoft® Visual Basic®、Visual C++®等工具，已经使开发和实现多种客户机应用程序使用的组件更容易。
以服务为中心、组件为基础的方法为开发人员预示了长期的、美好的前景。当应用开发的组织机构使用这种方法构建了更多的应用程序，他们就会发现自己现在可以开发和管理更少的代码。现在可以通过利用不断扩大的组件库集成应用程序，而这些组件会随着商业和技术的发展不断地进行提炼加工和处理。
--------------------------------------------------------------------------------
与业务发展一致 这种新应用程序的观点对应于当今的商业发展趋势，当商业处理过程流水化、上下级关系变得平滑时，每个雇员被要求承担更多的商务活动，新的工作任务超出了传统的功能边界。
信息系统的发展必须适应这种倾向。商业应用程序应该允许使用者在不需要学习更多的应用程序的情况下，从事更多的活动、处理更复杂的交易。例如，使用者查看、检索和修改客户信息的方法，应该在整个系统所有应用程序中一致，这样才能保证雇员们很容易的从一个应用程序转移到另外一个应用程序。
4．8将数据变成信息
--------------------------------------------------------------------------------
不能限制商业处理能力 客户机服务器的应用程序本身并不提供商业处理能力，它提供的是帮助使用者认识和处理商业能力的潜力。如果应用程序的界面很难使用，或者不支持不同用户背景的要求，那么应用程序的潜力就不能被使用者认识--不管应用程序经历过什么样精美的设计。
--------------------------------------------------------------------------------
客户机/服务器计算的优点 1995年Gartner Group进行的调查，根据拥有客户机服务器计算经验企业机构的调查，确定了客户机/服务器计算环境的25个最重要的优点。它们包括：
增加使用者的生产力。
对商业处理过程重组更好的支持。
允许在使用者的办公桌面上集成多种处理过程。
帮助减少数据获取过程中的错误。
允许雇员处理更复杂的交易。
增强访问企业机构数据的能力。
允许为使用者提供更多一致设计的商业处理界面。
增强雇员访问数据和工具的能力。
降低培训的时间。
增强雇员的工作热情并减少新老交替。
前25个优点中10个（40%）归功于客户端的界面--在MSF的结构中是用户服务。定义用户服务、业务规则服务和数据服务的一个原因是将适应性设计进应用程序中，数据服务负责为业务规则服务提供原始的数据，业务规则服务应用商业处理规则和限制到这些数据上并产生信息，用户服务以一种适合特定任务的方式为使用者提供信息。
Figure 5: Turning data into information
信息的内容对比信息的形式 MSF应用程序模型更进一步的阐述了信息内容和信息表现形式间的区别：业务规则服务产生信息的内容，但并没有给出如何显示给使用者的信息表现形式；用户服务根据使用者和任务要求，确定了信息最适合的表现形式。
4．9在应用程序之间共享资源、技能和成果
--------------------------------------------------------------------------------
利用现有的成果 服务同样可以被当作利用应用开发机构现有成果、资源和技能的手段，可以将它们在多个项目中有效地应用。例如，可用性和使用者界面设计的技能通常是宝贵的资源，现在不是把这些人分散在不同的项目中，而是整个开发机构为所有开发中的商业应用程序，选择一个可用性和使用者界面设计组，共享这些项目的责任。
--------------------------------------------------------------------------------
例子 一个保险业的公司有一套财产损失的计算法则，通常情况下这些功能集中在一个电子运算表格中，并将数据存放到数据库中。为保证在整个公司都能一致的使用这些计算法则，它们被作为一套业务规则服务实现，以一个物理组件的方式存放在公司网络上的应用服务器上。在每个客户端上运行Microsoft Excel，使用者应用了这些运行在服务器上的计算规则，访问存储在服务器上的数据库。这种方式不需要在成百上千的工作站上都有这些计算规则的程序代码，管理、实现和升级都非常方便。所以企业只要把这些业务规则的逻辑服务实现在几台有限的应用服务器上就可以，这些服务器会支持网络上的客户端。
4．10分布逻辑服务
--------------------------------------------------------------------------------
应用程序的层次 MSF应用模型包含了由逻辑网络服务组件组成的应用程序层次，而不是应用程序逻辑结构的两个或三个单一的层次。本节通过比较图6中的客户机/服务器应用程序的风格，考察跨越不同硬件平台服务的分布。
--------------------------------------------------------------------------------
胖客户端 胖客户端类型代表了第一代客户机/服务器应用程序。由于使用开发工具的结果，这种类型应用程序的实现是非常紧致的、单一模块的，并运行在客户机上。同时动态结构化查询语言（SQL）和存储过程调用相结合，运行在数据服务器上的数据库中。这种类型的应用程序与设计、定位和数据访问的数据库管理系统类型紧密地结合在一起，对应用程序任何方面的改变，或作为基础的数据库的任何改变，都需要在所有的客户端布置新的程序逻辑结构。考虑到客户端运行应用程序需要的资源和管理维护应用程序需要的费用，这可能是客户机/服务器费用最高的一种形式。反过来因为有丰富的工具支持，它也是一种最容易构建的客户机服务器结构。
Figure 6: Distributing the Logical Services
胖服务器 虽然胖服务器类型仍然是两层的、并与作为基础的DBMS和数据存放的位置紧密地结合在一起，提供更易管理的设计方式，但侧重点是在数据库管理系统的存储过程和触发器中尽可能多的实现业务规则和业务逻辑，使用存储过程从客户端抽象业务逻辑必须要理解依托的数据模型或业务规则的实现方法。
--------------------------------------------------------------------------------
从两层转向多层 在由两层结构转向多层结构时，会有两种情况：
对应用程序逻辑更精确、考虑更成熟的划分。
一种新类型的服务器的引入，通常称为应用服务器。
--------------------------------------------------------------------------------
应用服务器的优点 在应用服务器上布置业务规则服务有以下的优点：
所有的客户端使用服务器上一致的业务逻辑和规则。
增强访问应用程序逻辑不同组成部分的安全性。
在实现业务逻辑方面减少对数据库管理系统技术的依赖性，在服务器平台上提供性能优化的工具和技术。
当服务器新技术出现时提供利用新技术的弹性。
通过事务转换监视器和对象请求转换等技术提高性能、使用性和吞吐能力。
--------------------------------------------------------------------------------
严格的三层 在严格的三层结构类型中，用户服务布置在客户端，业务规则服务布置在应用服务器上，数据服务分布在应用服务器和数据服务器上，这种分布式模型提供了多个层次上的抽象：
数据的设计、定位和实现对于业务规则服务是透明的。
业务规则服务不知道、也不用考虑自身如何与使用者进行交互。
用户服务不需要了解如何实现业务逻辑。
这种严格的三层结构描述不一定适用所有的情况，服务器的角色可能要组合，对于移动应用程序，可能需要在一定程度上将业务规则和数据服务置于客户机。Internet和intranets的发展引入了第三种类型的服务器：internet服务器。
--------------------------------------------------------------------------------
多层的Internet/Intranet 在多层结构的Internet/Intranet类型中，用户服务分布在客户端和服务器上。多层结构设计较两层结构的优点是，一个业务规则服务的集合可以由多个不同的用户服务集使用，这会提供足够的弹性满足不同最终使用者的爱好。通过这种方法，一系列运行于应用服务器上的业务规则服务，可以为网络客户端的图形使用者界面内部访问，同样布置在internet服务器上的一系列用户服务，也可以通过为internet或基于intranet的浏览器动态产生HTML页，提供相同的功能。
--------------------------------------------------------------------------------
注意 严格的三层结构和多层Internet/Intranet结构类型都要使用存储过程和触发器技术，提供数据优化操作并在某些情况下，实现商业业务规则。
4．11多层Internet/Intranet结构--物理分布的模型
--------------------------------------------------------------------------------
在网络上或Intranet上分布 在前一节中描述的客户机/服务器应用程序的不同类型不是互相排斥的，根据性能要求和可以使用的技术，商业应用程序可能会组合这些不同的类型。
图7中显示的是逻辑服务如何被分布在企业网络或Intranet上，客户端可以是运行Microsoft® Windows® version 3.x, Windows® 95 or Windows NT® Workstation等操作系统的计算机，或其它可能的平台，或internet浏览器。
应用、数据和internet服务器运行Microsoft® Windows NT® Server，数据服务器运行Microsoft® SQL Server™，internet服务器运行Microsoft® Internet Information Server™。
远程自动化和分布式COM用于组件交互的标准，网络协议可以是能够运行远程自动化或分布式COM和基于浏览器客户端的HTTP协议。
Figure 7: Multi-tier internet/intranet: Physical Distribution Model
上图右侧是传统方式下多层结构的实现，用户服务在客户端上，业务规则服务在应用服务器上，数据服务既在应用服务器上，又在数据服务器上。这种布置提供了移动和改变数据存储位置的最大弹性，扩展应用服务器可以满足更高的吞吐和更多的用户，在相同的商业逻辑上支持更多的客户端接口。
考虑下面的问题：
应用服务器的功能如何能够提供给支持远程自动化或分布式COM的网络客户端？
通过World Wide Web如何访问应用服务器的功能？
如何集中管理和维护运行在客户端上的规则和用户界面？
--------------------------------------------------------------------------------
Microsoft® Internet Information Server™ Microsoft® Internet Information Server™提供了开发专用应用程序逻辑的能力，请参考internet服务器编程接口（ISAPI）扩展，这些接口可以解释来自任何类型浏览器的Uniform Resource Locator（URL）代码。ISAPI扩展可以接受包含在URL中的请求，并转换为针对一个或多个组件的访问。这些组件位于internet服务器或应用程序服务器上，使用户可以通过远程自动化或分布式COM访问组件。
ISAPI扩展可以发送请求到组件，打包访问结果信息，存放在从本地字典上获得的模板上，然后送回到访问的浏览器。它提供了支持任何internet浏览器的能力。更深一步因为HTTP是公用的协议，这种方式可以应用于intranet和internet的方案。
因为ISAPI扩展获取URL请求，调用适当的业务规则服务以满足请求，产生新的HTML，并下载到浏览器上表示给用户，所以说在本质上特定的ISAPI扩展可以被考虑成用户服务。
--------------------------------------------------------------------------------
HTML页的变化 考虑在HTML页中嵌入ActiveX™ controls、Java® applets或者Visual Basic® script，现在已经可能开发必要的、具有应用程序逻辑的HTML模板，它们用于执行编辑规则、增强与用户的交互，甚至是一些业务规则。这种结构位于服务器上，ISAPI扩展组合了模板及从应用服务器中获取的信息。它发送给客户端HTML结果和script/applets/controls，以便在本地机上运行。如果需要改变规则或修改页面的设计，这些改变将针对某一个HTML模板，然后传送到几个服务器上，而不是数以万计的客户端上。下次用户浏览这一页时，它们会自动的看见这些变化。
不管谁在使用业务规则服务，接口保持不变。如果一个新的业务规则服务在服务器上实现，所有的服务消费者--无论它们是在网络上、intranet或者internet上--都将从这种改变受益。
4．12服务的实现
--------------------------------------------------------------------------------
设计过程 Microsoft® Solutions Framework--组件设计方案（Designing Component Solutions）白皮书描述了基于三个交互阶段的设计过程：概念设计、逻辑设计和物理设计。MSF应用模型用于在整个设计过程中勾画项目观点上的应用程序，在从逻辑设计到物理设计过程中起非常重要的作用。在这个过程中，MSF应用模型能够防止使用者的交互、业务规则和数据的操作逻辑陷入混乱。它使项目侧重于设计和实现维护协同工作的组件。这个过程如图8：
Figure 8: Transition from Logical to Physical Design
最初的组件 为了确定组件的构成和分布的特征，在逻辑设计过程中，首先确定用户、业务规则和数据服务三个层次的对象，它们构成了预定义的组件集合。
这种方法创建了组件的初始集，保留应用模型中的抽象层，并提供了检查附加的、打包和分布问题的、有弹性的出发点。
这些仅仅是最初的组件，它们还没有反映出物理设计中的限制。这种初始的划分提供了在特定物理点上，检查围绕组件定位问题的逻辑基准线。当附加的物理问题被发现并选择了合适的实现技术，这些初始的组件会被修改。
--------------------------------------------------------------------------------
组件的实现 实现组件有多种不同的选择。表一列出了实现不同类型服务组件的不同技术。表中的内容仅为推荐而不是必要的原则。这些推荐构成了MSF应用模型中设计分布式、多层结构的应用程序的原则和指南。
Table 1: Recommended Implementation Technologies for Services
Component Technologies User Services Business Services Data Services
ActiveX™ Control
Component Object
Automation Server
ISAPI Extensions
Custom DLL
Stored Procedures and Triggers
HTML Pages
Visual Basic® Script
Java® Script and Applets
物理设计中的考虑 在物理设计阶段需要考虑的关键问题包括：使用者访问的频度和响应阈值、特殊任务的优先级、前台和后台的容量、网络带宽、容错方法、数据库的大小和安全性。因为物理因素会随技术的发展和商业增长而改变，系统弹性的设计非常重要，基于组件的实现方法更易于平衡负载、分散和应用新的硬件资源。
--------------------------------------------------------------------------------
组件的交互 在物理设计中，分到组件中的单独服务的接口协议是可以扩展的。逻辑设计中的交互标准加入现有的接口协议中，这将提炼出包含物理机制的规定，允许组件互相交流。表2列出了当前使用的不同的组件交互技术。
Table 2: Component Interaction TechnologiesTechnology Description
Remote Automation Enables OLE Automation Servers to communicate over a network connection. Remote Automation (RA) is part of the Microsoft® Visual Basic® version 4.0 programming system.
RA provides location transparency. This means that automation servers can interact with one another using the same interfaces without regard to the location of each server.
RA will eventually be superseded by Distributed COM. However Remote Automation will still have a role to play in enabling 16-bit platforms to interact with distributed automation servers.
Distributed COM Distributed COM (DCOM) is a set of extension to the Microsoft® Component Object Model which enables component objects, including automation servers, to interact with each other over a network connection. DCOM provides the same location transparency that RA offers.
Compared with RA, DCOM provides a richer feature set and enhanced performance. Applications designed to use Remote Automation will work over DCOM with performance improvements anywhere from 30% to 100% in calls per second.
DCOM will be part of Microsoft® Windows NT® version 4.0.
HTTP Hypertext Transfer Protocol (HTTP). This is the method by which clients and servers communicate on the World Wide Web. It is a stateless protocol which means that a client can make several requests of a server. Each request is treated independently. As the server processes each request HTTP provides it with no information (state) of the previous request made by the same client. This statelessness makes it a very fast protocol ideally suited for low bandwidth, high latency networks. This is the protocol used by ISAPI extensions to communicate with browser-based clients.
HTTP is also useful when a server has to support a heterogeneous client base that is not capable of running Remote Automation or Distributed COM.
RPC Remote Procedure Calls (RPC) enable developers to create applications consisting of a number of procedures, some that execute locally and others that execute at some other point on the network (remote).
RPC is a lower level interaction standard that might be used to call procedures in remote DLLs. It does provide the same ease of programming as Remote Automation or DCOM, both of which are built from RPC technology.
TCP/IP Sockets This is another low level protocol that enables components to communicate over a network. It is most often used when an application needs to attain the highest communication performance possible over a network. A good example would be video-conferencing client software that needs to talk to a conferencing server that is supporting multiple clients.
RDO, DAO, ODBC The Remote Data Object (RDO), Data Access Object (DAO) and Open Database Connectivity (ODBC) are three different data access technologies used by components to interact with a database.
For example, a set of data services for talking to a NamedParty database might be implemented as set of methods in an Automation Server with a corresponding set of stored procedures in the NamedParty database. The automation server methods might use any one of DAO, RDO or ODBC to invoke the appropriate stored procedure when the method is called.
ODBC provides the highest performance, followed by RDO and then DAO. Conversely DAO provides the richest set of programmatic interfaces and is the easiest to use, followed by RDO and then ODBC.
--------------------------------------------------------------------------------
分布式系统的物理设计 分布式系统的物理设计可能非常复杂。定义组件交互的模型，需要预先分配组件到不同的网络节点上--可能在工作站上、internet服务器、应用服务器或数据服务器。
如果系统的物理数据存储单元不存在，还需要映射这些物理数据存储单元。物理数据文件的位置、存储媒体的确定和数据访问方式的确定，都需要规定。
使用者界面设计和物理数据库模型的平台，同样也是在物理设计过程中构建的。
4．13服务的细节
什么是服务？
--------------------------------------------------------------------------------
服务的定义 服务是应用在一个对象上的实现操作、功能或改变的一组应用程序的逻辑结构。服务可以用于增强业务规则，执行计算或操作数据，给出输入、搜索、查看或修改信息的功能特色。
--------------------------------------------------------------------------------
服务的类型 服务在逻辑上可能很简单--创建、读取、更新、查看和删除；同样服务在逻辑上也可能很复杂--执行计算或转换，大的服务可能管理一个交易转换、管理与其它服务的交互或监控外部的系统或数据源。下面的表中提供了对于一个称为“客户”的数据集进行操作的不同服务类型：
Table 3: Examples of Services
服务名称 服务描述
创建客户 使用传递给服务的数据创建一个新的的客户，输入的信息是用于创建一个新客户所需要的最小数据集。这种操作可以异步进行，当数据提交成功完成时，应该发送一个通知给客户端。
查询客户 根据预定义的检索条件集合，本服务将确定所有符合特定条件的客户。这种服务的实现通常是检索返回的客户数量，可能还会有其它的从数据集中检索客户的服务，它们共同提供在特定的索引下返回多行数据的能力。
这个服务并不限制搜索客户客人的详细信息，它将支持多种检索方法如：个人详细信息、登记的产品、客户位置和最佳的一次定单。
浏览客户 显示浏览客户详细信息的标准界面，这个服务可能支持不同的视图，或者符合某一请求的特定视图。
支持的视图可能包括：HTML页、电子表单、在数据簿中的数据表、或者文件夹中的图标。
获得信用程度 根据特定的要求调用第三方服务进行信用检查，这个服务负责收集执行检查所需要的最小集合的数据，保证第三方服务的安全性，并负责发出和传送请求。
--------------------------------------------------------------------------------
服务的接口 服务被封装在组件中成为应用程序的组成结构，通过组件的接口提供组件中的服务。
服务模式的中心内容是服务接口所提供的重要功能，通过一致的、通用的、标准的接口，服务提供给它们的使用者，使服务的使用者不必了解服务是如何实现的。
一致的接口是不可变的，当新版本的组件发表后，前一个版本的服务接口仍将被支持，新的或增强的服务会通过新的接口提供。
--------------------------------------------------------------------------------
接口设计 通用的、标准的接口被设计成任何有能力的开发组，都可以通过阅读接口规定了解并使用该服务，实际上没有必要了解服务内部是如何实现的。服务接口的设计是为了满足更大范围的使用者需求，当一个服务是第一次设计时，在设计过程中必须考虑未来服务如何被使用的问题，这个过程的指南是在企业总体结构中的应用程序结构中定义的。
--------------------------------------------------------------------------------
接口协议 一个服务接口的规定，有时称为接口协议，包含的内容如下：
服务名称
输入和输出的参数
存在的前提
使用的条件
能力
依赖性
--------------------------------------------------------------------------------
接口规定所扮演的角色 在设计组件的过程中，接口规定扮演了三个重要的角色：
通过描述如何与服务进行交互，将要求提交给服务的使用者。
确定服务在组件内如何实现，并表达组件的接口。
描述服务的功能和使用的规则。
在确定是否使用组件时，组件接口的使用性是一个关键的因素。一个组件可能很好地提供所有要求的服务功能，但如果在开发应用程序时，它的接口很难使用，那么这个组件本身也很难被采用，在构建可重用性组件或确定即插即用的商业软件的前景时，这是一个关键的概念。
--------------------------------------------------------------------------------
组件中服务的实现 最终确定服务价值的是服务的使用者，而不是服务的提供者。MSF应用模型的一个目标是在不同的应用程序之间，通过使用作为组件的共享服务，增强应用程序交互的程度。因此，服务模式由服务使用者的需求描述确定，并在接口规定中进行表达，最终确定在组件中如何实现。一个服务接口的规定，可以被看成是服务使用者的要求和控制服务使用的规则的表达。
理解服务接口设计的重要性，可以与应用程序使用界面的设计并行进行，一个应用程序可能拥有复杂的、实现很好的功能特色集，但如果它们显示的不好、很难学习、很难改变或很难支持，那么这个应用程序将被视为不好用的，或者根本就不能使用。使用者界面的设计过程不仅仅确定了哪些功能特色是使用者要求的，更重要的是确定了应用程序的功能特色如何提供给使用者。
--------------------------------------------------------------------------------
注意 组件设计方案中更详细地讨论了服务模式系统结构的原则，可用性设计中给出了使用者界面设计的过程。
4．14用户服务
--------------------------------------------------------------------------------
用户服务定义 用户服务是应用程序组成结构中提供接口的部分。一个应用程序的使用者可以是一个人或另外一个应用程序，因此一个应用程序的接口可以是一个图形用户界面或一组可编程的接口。
--------------------------------------------------------------------------------
例子 例如，Microsoft® Excel包含一组很好的图形用户接口，它们使用workbook / worksheet方式来实现。除了它的图形用户界面外，Excel同样提供了复杂的编程接口，在应用OLE自动化接口的方式下，提供出相同的功能和特色。这两种类型的接口逻辑上相仿，都被考虑成为用户服务。
--------------------------------------------------------------------------------
用户服务的角色 应用程序的用户服务负责管理使用者和应用程序之间进行交互的所有方面，为达到这个目标必须理解使用者，他们要执行的活动，以及适合不同使用者和活动间组合的最佳风格。根据使用者界面设计过程中，用户服务在下面的模型中得到了基本的信息：
User Model. 关于不同的使用者与应用程序进行交互的了解，模型化这一类信息会使应用程序，以最适合使用者的方式提供信息和收集的数据。
Activity Model. 关于不同类型使用者要执行哪些不同的活动，应用程序如何支持这些活动，应用程序如何帮助使用者执行单独的活动等等的了解。模型化活动的本质在于商业和应用程序的目标。
Interaction Model. 关于在使用者和应用程序间交互产生的对话的内容。模型化这些信息的目标在于，使用根据给定的行动推断使用者的意向成为可能。
关于用户界面设计过程的详细描述，请参见Designing For Usability.
--------------------------------------------------------------------------------
用户服务是“应用程序” 用户服务构成了从使用者观点看到的“应用程序”，在这样的情况下，用户服务必须：
组织不同的用户服务和业务规则服务为应用程序--用户服务绑定不同的用户服务到一个简单结构中，然后连接这个简单的结构到适合的业务规则服务。用户服务导引着在业务规则服务和应用程序界面间的信息和数据流向，确定信息内容的起源和目标。
控制事件的次序--用户服务保证操作事件的发生不会出现意外的情况，其先后次序符合商业规则的要求。这是通过限制使用者的操作界面，使用户只能选择合适的操作完成的。
提供事件的产生--事件可以由用户服务触发，它们或者是一系列的用户操作，或者是一个业务规则服务的操作请求。这些事件根据应用程序的当前状态或使用者操作的不同情况，代表着不同的事情，用户服务就是确定这些事件的意义，并采取合适的行动。
提供编程的接口--当一个应用程序要为它的功能和特色提供一种可编程的接口时，执行控制的服务将提供这些接口。
提供使用者帮助--帮助可以是联机的帮助或智能助手。总的来说有两种类型的联机帮助，面向内容的和面向任务的。面向内容帮助提供的是关于与使用者交互的对象活动执行信息，面向任务帮助提供的是使用者如何完成一些指定的任务或使用应用程序的活动。智能帮手（如精灵或模板）是这些活动的专家，它能指导使用者完成一种活动或全部地掌握一种活动的进行。
状态管理--. 用户服务管理着使用者执行的、或不同业务规则服务请求操作的不同活动的状态。这种状态信息会协调一个应用程序状态的衔接，它将保证应用程序能够：
处理由于上次使用应用程序没有完成的业务规则服务组成的异步请求。
恢复一个使用者个人独特的操作环境。
恢复应用程序到上次使用的状态。
--------------------------------------------------------------------------------
从应用程序的结构中分离信息查看的方式 MSF应用程序模型鼓励分离两种用户服务，一种是实现使用者界面结构的用户服务，一种是实现在用户界面中不同信息浏览方式的用户服务。
分离的目标是设计使用者界面接口，使其能够将不同的浏览视图嵌入到相同的结构中来。MSF应用程序模型定义使用者的界面结构为组成一个应用程序的一系列窗口、页面和对话框集合，以及使用者如何在这些单元间切换。
Table 4: Examples of User Interface Structures Service Name Description
Projects, Workbooks Workspaces The Microsoft® Press book Microsoft Windows Interface Design Guidelines documents a number of different window management strategies for structuring an application. The traditional strategies for Microsoft® Window version 3.x and Windows NT® version 3.x has been Multiple Document Interfaces (MDI).
With the emergence of the new shell for Windows® 95 and Windows NT® version 4.0, new, more appropriate window management techniques are emerging: Projects, Workbooks Workspaces.
Internet Browser Server-based internet applications, that download HTML pages containing combinations of CGI; forms, Visual Basic® script, Java® and/or ActiveX™ controls do not need custom structures to host the pages. Any internet browser capable of supporting the version of HTML used by the application will do.
Windows Shell The Windows® 95 and Windows NT® version 4.0 shells support a rich set of extensions that allows custom components, implemented as COM objects, to be integrated into the shells explorer, folders and taskbar.
Application Suites Microsoft® Office is a good example of an application suite, which through its implementation of Visual Basic® for Applications and an extensive set of OLE Automation Interfaces, make it very easy to integrate custom pieces of application logic into the application suite. This logic is able to call user services implemented as client side components, or make direct use of business services provided by components resident on an application server.
表4中最后的三个选项不需要任何特定的应用程序结构，在使用者非常熟悉的internet浏览器、Windows 95界面或其它一组用户熟悉的应用程序界面中，集成那些特定的视图结构，这是有效设计用户界面以满足不同查看方式结构的一个关键技术。
--------------------------------------------------------------------------------
查看（视图）服务 指定更多的客户机/服务器应用程序使用以前开发的应用程序结构，这样重点将转移到开发更丰富的信息查看（视图）方式。查看（视图）服务是信息的可见显示方式，它们代表着信息内容展示给使用者的不同形式。例如，一个雇员列表可以显示在一个表格、一个分级纲目中或是一个组织结构图中。下面的列表提供了不同“客户”服务的用户服务和显示它们的查看服务：
Table 5: Examples of user interface views 服务名称 描述
修改客户 这个服务允许使用者修改一个客户的详细情况，这个服务将调用必要的业务规则服务，根据使用者的访问权限，检索修改后的信息。为了帮助使用者查看和修改数据，需要显示一些用户的界面，然后这个服务将根据使用者对数据的修改，调用不同的业务规则服务创建更新的事务转换。
这个服务的实现将包含两个分离的视图：一个对话框窗口中的格式和一个HTML页中的格式。对话框窗口的实现将是客户机端的常用组件。HTML版本格式的实现将是运行在Microsoft® Internet Information Server™上的ISAPI扩展的一部分，这样它将动态地在HTML页中创建格式，通过任何的script语言或控件完成管理使用者和格式间交互的需求。
查找客户 通过Windows 95的开始菜单访问，这种服务调出一个与Windows 95界面中Find Files或Find Computers对话框设计类似的查找对话框，这个对话框将作为一个组件在客户端实现。
对话框中格式设定将代表使用者可能的搜索条件的不同方面。例如可能有根据个人详细情况、产品登记和客户所处位置等方面的格式设定。
这个服务通过对话框获得重要的条件输入，并将它们传递给相应的业务规则服务。根据使用者的请求，这种查看（视图）服务将使用不同的业务规则服务，获得相应的检索结果。
创建快捷方式 调用这个服务将在桌面上或指定的文件夹中，创建一个指定客户的连接图标，当一个使用者想使用这种快捷方式时，程序将调用一个组件，来激活必要的用户服务和业务规则服务，获得需要检索的或显示的信息查看方式。
4．15业务规则服务
--------------------------------------------------------------------------------
业务规则服务定义 业务规则服务是应用程序中控制、执行业务规则逻辑顺序，进行事务交易转换集成操作的组成结构，业务规则服务通过合适的应用程序的规则将数据转换成为信息。
--------------------------------------------------------------------------------
业务规则服务的目标 设计恰当的业务规则服务的目标是隔离业务规则的执行，和从服务的使用者方得到的需要转换数据（用户服务和业务规则服务），以及它所依赖的数据服务。从用户服务和数据服务中隔离业务规则服务有如下的优点：
确定如何和在哪里布置业务规则服务时具有足够的弹性：如组件布置在应用服务器上，存储过程布置在DBMS或在客户端。
在标准的业务规则服务集合前面放置不同的用户服务的能力，例如对一个客户执行操作的业务规则服务集合，可以使用一个单一的组件实现，并置于应用服务器上。组件提供的服务可以在任何下列客户端的情况下使用：在Microsoft Office中运行的宏，使用Microsoft Visual Basic开发的定制应用程序，或者在Microsoft Internet Explorer中运行的HTML页。
通过隔离应用程序中的数据服务和用户服务，增强业务规则的可管理性和总体逻辑结构。
替换业务规则服务实现的能力，例如在业务规则服务集合中的一整套业务规则可能会随着国家和地域的不同而不同，但这些服务的接口将保持不变。
--------------------------------------------------------------------------------
“客户”业务规则服务 下面的表中给出了不同“客户”的业务规则服务。
Table 6: Examples of business services 服务名称 描述
查找客户 根据预先定义的条件，这种服务将选择确定所有符合指定条件的客户。这个服务的实现是通过返回找到的客户数量实现的，这里我们还会有从集合中检索客户的附加服务，这些服务将提供在指定的索引情况下返回多行数据的能力。
这个服务不限制使用者根据客户个人情况进行检索，它将支持多种检索条件如：个人的详细情况、登记产品、位置和最佳的定单。
获得信誉度 对一个特定的个人调用第三方服务进行信誉检查，这个服务将负责收集执行检查的最低条件的数据，安全化第三方服务并传送请求。
新客户 使用传递给服务的数据创建新客户，服务的输入将定义创建一个新客户所需的最小数据集。这个过程有可能是异步进行的，当事务交易成功完成时，客户端将收到一个通知。
4．16数据服务
--------------------------------------------------------------------------------
数据服务定义 数据服务是应用程序中,提供用于操作数据的最底层的、可见层次抽象的程序结构部分。数据服务维护一致性和非一致性数据的可用性和完整性，数据服务还控制并提供数据的存取访问，是业务规则服务不必了解数据存放的位置，及服务如何实现或如何访问。
当我们可能确定与一个客户相关的、分离的用户服务和业务规则服务时，在数据服务层次上，服务将更结构化、模块化。例如，一个系统可能包含“客户”、“雇员”和“代理商”等方面的服务组件，在业务规则服务层次每个服务具有一套独立的属性、服务和规则。但是对数据服务层次来说，它们都是企业机构中组成实体的一部分，因此我们可以使用一个称为“命名实体”的组件，来实现这种数据服务，提供对雇员、代理商和客户的创建、读取、更新、删除、数据反转等功能服务。
--------------------------------------------------------------------------------
数据服务的角色 数据服务实现数据存储，映射业务逻辑到指定的数据存储位置，并维护这种映射关系。数据服务并不仅限于一致的、结构化的数据，当使用定义确切的接口访问和操作数据时，数据服务可以处理任何情况环境。
--------------------------------------------------------------------------------
例子 例如一个过程控制设备中的实时数据采集器，与其说是一个传统关系型数据库表格，不如说是数据服务的一部分。多媒体数据如图象、视频信号和声音信号都可以作为数据服务的对象。数据服务同样也包含不同的数据传送机制如电子邮件、传真、OLE复合文件、Microsoft SQL Server和不同的基于文件系统的存储技术。
--------------------------------------------------------------------------------
数据服务的策略 数据服务设置了对数据访问的限制，支持复杂的数据关系，执行复杂的数据完整性限制。这些特色是业务规则服务结构的一部分，但必须由数据服务来提供。同样数据服务提供数据的安全性，而业务规则服务提供信息的安全性。
数据服务的分类是：
查找和返回
插入、更新和删除
锁定
验证
安全性
--------------------------------------------------------------------------------
查找和返回 查找和返回服务支持由业务规则服务提供的跨越不同数据集的检索，检索和返回服务的任务包括：
在一个可执行的格式中编辑检索请求--不是必须的，依赖使用的检索机制。
优化检索请求：主要的策略是选择合适的索引或检索路径和结构化访问的顺序，目标是最小化检索过程中所经历的数据，这些请求将符合使用关系性选择和合并操作中的创建逻辑。
执行检索请求。
在一定的格式中，构成检索结果集并提供返回结果到请求者的机制。如何处理游标是一个主要的问题。
整个设计过程中确定了业务规则服务需要的检索类型，并选择合适的技术来支持这些检索类型。特别值得注意的是要求的检索条件的类型和需要跨越的不同关系类型。
--------------------------------------------------------------------------------
创建、更新和删除 这些服务允许业务规则服务通过一致的和可靠的方式，请求修改数据状态。我们现在有许多很容易理解的协议支持这个过程。例如ACID协议：
Atomicity（完整性）：转换对状态的改变是完整的，或者全部发生、或者没有发生。
Consistency（一致性）：一个转换是对数据状态的正确转移，一组转换的动作并不违反与状态相关的数据完整性限制，所以要求转换是一个正确的程序。
Isolation（隔离性）：即使转换是并发进行的，每个转换都应该认为其他转换的执行或者在自己之前或之后。
Durability（持续性）：一旦一个转换成功完成（提交后），它对状态的改变就可以经受系统的失败。
理解ACID协议的实现非常必要，在实际设计过程中要保证应用程序不违反协议中的规则。
--------------------------------------------------------------------------------
锁定 锁定服务允许多个用户并发地访问存取数据。检索和返回服务及更新服务都将利用锁定服务。
隔离的程度用于描述锁定设计，根据应用程序要求的恢复和其他相关特色，不同程度的隔离是可能的。
系统结构设计者必须很清楚应用程序要求的隔离程度，才能支持应用程序中要求的不同类型的修改。确定了要求的隔离程度之后，才有可能回到企业的技术结构中，选择合适的数据管理员，提供希望的数据隔离程度。
Table 7: Degrees of isolation for locking schemes Issue Degree 0 Degree 1 Degree 2 Degree 3
Common Name Chaos Browse Cursor stability Isolated, serialized, repeatable reads
Protection Provided Lets others run at higher isolation 0° and no lost updates No lost updates, no dirty reads No lost updates, no dirty reads, repeatable rates
Committed Data Writes, visible immediately Writes, visible at EOT Same as 1o Same as 1o
Dirty data You don't overwrite dirty data 0° and others do not overwrite your dirty data 0° and 1° and you don't read dirty data 0°, 1°, and 2° and others don't dirty the data that you read
--------------------------------------------------------------------------------
数据验证 数据服务支持一系列基本的数据验证特色，它们包括：
域的完整性检查，例如验证现在提供的值是否与前面建立的值一致。
触发器和网观机制，允许在数据提交前检查数据状态。
第二种功能特色类型支持业务规则服务需要的常用规则的执行，业务规则服务将支持两种主要类型的数据验证：
Immediate validation（立即验证）：在触发条件允许的情况下，就开始进行验证。
Deferred validation（推迟验证）：只有在转换即将到达提交点时，才开始验证。
数据验证服务允许实现这些类型的验证。
错误处理是与数据验证服务紧密相连的，如果一种违反规定限制的情况被检测到，当前的操作被取消并返回一个错误值。如果当前的操作是一个转换（例如，有明确开始转换命令的SQL更新命令），整个转换将被取消。如果当前的命令是一个简单的修改命令，只有修改的部分被取消。
和其他的服务一样，实现验证服务的一些技术可能不支持一些功能，如延迟验证。
--------------------------------------------------------------------------------
安全性 安全服务支持下面的定义，包括：
访问的对象。
可以应用到对象上的服务。
使用句柄访问对象的用户组。
将特定应用程序的安全范围考虑成为三维距阵，距阵给出哪个对象可以被访问，被哪个用户访问，使用哪个服务。提供的安全性类型依赖于：
对象安全性的尺度。
可以请求的服务类型。
使用者处理的方式。
对象可以是整个数据库、一个表格、表中的一行、或者一行中的一个属性。服务可以没有安全性（没有服务层次的安全性），标准的插入、更新、删除和数据返回操作，也可能安全性应用于规定的使用者操作（例如限制访问特定类型的存储过程）。
4．17服务和组件
--------------------------------------------------------------------------------
组件是物理设计的基本构建元素 组件是物理设计的基本构建元素，每个组件是由具有接口的一个或多个服务构成。组件可以被想象为“黑匣子”，在组件外部对组件的认识，是组件所提供的服务和这个组件如何与其它组件进行交互，组件内部的构造和实现对于外部世界来说是隐藏的，图9中给出代表组件和它的接口的标准符号。
Figure 9: What is a component: the symbol
组件的特点是：
可重用的构建模块（黑盒子）。
通过如何与其他组件交互给出定义，而不是通过内部的实现进行定义。
抽象、隐藏和保护内部的细节（封装它的服务）。
拥有正式的和明确的接口。
逻辑服务被打包在一起，作为组件实现。组件的方法提供了它所包含的服务，服务的属性、方法参数和事件用于传递数据。目标是在不同的组件间达到松散的结合，在同一个组件内部的服务间达到紧密的结合。
--------------------------------------------------------------------------------
对服务和组件进行打包 根据服务的业务规则内容（客户、定货、产品）、服务的类型（用户服务、业务规则服务或数据服务）以及服务的使用方式，应该将服务打包成为组件。服务的使用方式不应该被忽视，例如一系列与客户相关的用户服务，可能被指定显示电子格式（客户信息格式）或在internet浏览器中显示HTML页（客户页面），客户信息的页面服务组件可以使用一个简单的ISAPI扩展DLL来实现，它放置在Internet Information Server上，并动态下载到浏览器上创建HTML页面，客户信息格式组件的显示将从客户端本机的存储空间中调用。
例外一个例子是：客户业务规则服务的一个子集可能更适合以SQL数据库中一系列触发器的方式实现，并通过远程自动化服务器的方法进行调用。
Figure 10: Packaging services and components
第三个例子与“信用检查请求”业务规则服务相关，这个服务获取目标客户的详细信息。通过调用第三方服务，它获得了当前的信用检查。开始我们可能将它与其它与客户相关的业务规则服务打包在同一个组件中，但是当我们检查这个服务的使用方式特色时，我们发现当客户服务组件安装在分支机构的应用服务器上时，在每个区域的办公地点的应用服务器上，只有一台应用服务器上需要有一个信用检查服务的连接，因此更好的方式是将提供“信用检查请求”服务的组件放置在区域办公地点中的一台应用服务器上。
--------------------------------------------------------------------------------
什么是服务组件？ MSF应用模型定义服务为应用于对象上，执行操作、功能或转换的应用程序逻辑组成结构。这里的关键是“应用于”，一个服务组件并不定义服务操作的对象，例如，一个客户服务组件可能实现在一个客户对象执行的所有业务规则服务，但并不定义客户这个对象是什么。
面向对象方法应用于组件设计，封装一个或多个对象的数据和逻辑结构到一个单独的组件中去。这种方法有一个不利的地方，定义一个客户是什么的属性和操作这些属性的服务在相同的一个组件中，如果客户组件放置在使用它的客户端机器上，这种方法将工作正常，但如果将组件移到一台应用服务器上为多个客户端提供服务时，这种方法旧将失效。
现在每次客户端应用程序都要创建一个客户对象的环境，不管是否将要使用组件中的服务，一个新的环境都将在应用服务器上创建。组件中存放的数据意味着直到客户端应用程序释放组件的引用，否则特定的环境必须被保持是存在的，对于成百上千的客户端来说，复制对象的环境很快将成为超出应用程序服务器负载的情况。
--------------------------------------------------------------------------------
中间件的角色 为了给企业规模的商业应用程序提供更好的可靠性、高吞吐量和可伸缩性，应用服务器应该通过运行特定的中间件程序管理组件服务，这种中间件提供两种关键的服务：
在多个应用服务器上平衡负载。
管理客户端应用程序对服务请求，产生的组件环境池。
当一个客户端应用程序对一个服务组件提出请求时，它并不了解是哪个服务池提供的服务，或者组件服务存在于哪个应用服务器上，这些工作都由中间件的池管理器进行处理。当客户端完成对组件的使用时，组件得到释放并返回原来的组件服务池。为使这种工作有效地进行，组件应该尽可能的做到没有固定归属--也就是，它们在一种到另一种调用的过程中，不应考虑特定内容的信息。
例如，客户端应用程序调用RequestNewCreditLimit方法，将客户的信息作为方法的参数进行传递，这种调用通过为来自组件服务池中的一个适合组件创建环境句柄完成，当方法结束时，句柄返回池中 并被置为清空的状态，它没有保留有关客户信用极限已经超过的任何内容。
--------------------------------------------------------------------------------
Sample Code for Calling a Service Component
Function RequestNewLimit(thisCustomer As Customer,
NewLimit As Currency) As Boolean
Dim srvcCustomer As New CustomerService
Dim fResult As Boolean
fResult =
srvcCustomer.RequestNewCredit
Limit(thisCustomer,
NewLimit)
RequestNewLimit = fResult
End Function
前面的Visual Basic®代码解释了如何使用服务组件。CustomerService类型指存放在应用服务器上的组件，通过使用远程自动化或分布式COM为编程者提供访问的接口，当调用RequestNewCreditLimit方法时，这个组件的一个环境句柄赋予srvcCustomer，thisCustomer变量是客户类型的一个对象，一个放置在客户端的组件实现这种类型。以上例子显示出请求服务操作的对象，如何传递给srvcCustomer代表的客户服务组件环境句柄。随着RequestNewLimit功能完成时，服务组件将重新回到应用中组件服务池，但是thisCustomer代表的客户对象环境句柄将仍然存在。
所以在设计服务组件过程中需要进行的改变包括：
组件并不定义它所包含服务操作的对象，这些应该在客户端上进行定义和维护。
组件提供的服务应该被想象成为一系列相关的远程功能，并且每个功能最好被看成是一个转换。
不要将组件看成是真实世界中的软件实例：定货、客户、发票等。相反它们是操作、功能或转换的具体实现，它们将应用于定货、客户、发票等对象之上。
尽可能排除在方法调用的过程中对数据的保留，当需要保存数据时，看是否可以使用少量的、相关的方法调用，使它们可以组成一个转换。
服务组件有时并不代表数据库中单独的一行 - 它们是通向数据库的渠道，一行数据或多行数据通过这个渠道进行传递。
组件的分布 在选择用于实现服务的技术和交互标准时，另一个重要的因素是考虑服务分布的特点。基于组件的技术为布置应用程序的结构，满足性能和使用的要求，支持更大的交互性，提供了很好的伸缩性。远程自动化和分布式COM提供了放置组件的透明性，使组件的分布可以有多种方式。
远程自动化或分布式COM提供的位置透明性，为在跨越网络不同节点布置组件的应用程序设计方式提供了极大的可伸缩性。为进一步探索不同组件的放置方法，我们来看一下一个由三层应用程序结构组成的应用程序，其中每一层都是物理上的一些分离组件的集合。在第一种安排中，图11显示了一系列用户服务、业务规则服务和数据服务以三个服务组件集合方式进行实现。
Figure 11: Component distribution: a single hardware tier
以上的一种替代方法是将业务规则服务置于服务器上，并检查这种配置中的带宽、可维护性、性能和其它因素。如果设计中采用结构化的方法和二进制的标准（如OLE），这些组件将可以自由移动，不需要代码的改变。否则整个实现过程将需要特殊的机制，例如存储过程等都需要包含在组件设计中去。
另外一个常见的变化发生于一些数据服务既放置在客户端，也放置在数据服务器上。使用本机客户端数据库中的一些数据，也使用服务器上关系型数据库中的应用程序适合这种模型，当远程用户需要在断掉网络连接时，进行连续操作时这种配置经常发生。
--------------------------------------------------------------------------------
两个硬件层，瘦客户端/胖服务器 图13中的安排再次显示了应用程序的布置跨越两个硬件层，但这次是业务规则服务被移向服务器，服务器既承担应用服务器，又是数据服务器，整个配置中为一个客户端和一台服务器。
Figure 13: Component distribution: two Hardware tiers, thin client/fat server
三层硬件结构，应用服务器的复制 在图14中的三层客户机/服务器模型，是最有弹性的配置，支持高可靠性和高性能事务转换的吞吐量，在应用服务器上放置的业务规则服务承担着性能和规模上的巨大弹性。在这样的配置中，三层应用服务器程序层分布于三个硬件层次：客户端、应用服务器和数据服务器，应用服务器和数据服务器将在网络中进行复制。
Figure 14: Component distribution: three hardware tiers, replicated application servers
三个硬件层次，应用服务器的分区 图15中的配置同样使用三层硬件结构，但是不同于将相同的组件配置复制到多个应用服务器上，现在将不同的组件分区配置到多个应用服务器上。
Figure 15: Component distribution: three hardware tiers, partitioned application servers
上面的替代方法是一个实例。通常情况下客户机/服务器应用程序使用不同配置的组合，来满足特定的性能、可靠性和吞吐量的要求。
5．企业总体结构设计
传统上，企业总体结构设计是企业管理负责人（CEO）、信息技术负责人（CIO）、高级信息技术管理者和商业业务执行者最关心的问题。因此，本章内容最适合的对象是企业高级管理人员。企业总体结构设计可以在整个企业的各个层次上提高联络和解决问题的能力。本章的目标也在于提供一种结构框架、过程模型和组队模型，面向企业总体结构的开发问题。企业总体结构设计还可以帮助企业采用新技术，同时在企业内部扩展新技术，获得企业的竞争优势。
注：关于企业总体结构设计的详细介绍将于近期推出。
--------------------------------------------------------------------------------
6．解决方案设计
重用性的设计：“以用户为中心的设计方法”可以保证系统设计过程的交互性。将最终使用者的要求、期望和应用能力加以充分的考虑，补充项目中与商业、技术相关的正式需求。
设计组件结构的方案：在微软解决方案框架结构（MSF）中，它是分布式计算环境中设计并支持一些复杂模型的有效方案。通过提供系统开发的模型，允许处理过程（或功能）和数据的分布。
这些设计方案与MSF的过程模型、组队模型和应用模型，在面向商业解决方案的环境中，紧密的结合在一起。在商业问题和技术实现之间构建出一座桥梁。
注：关于解决方案设计的详细介绍将于近期推出。
7．信息技术基础结构实现
本章介绍如何应用MSF的过程模型和组队模型以及其他MSF方案开发准则（SDD），到信息技术基础结构实现的项目中。本章给出在大型企业的网络计算环境中，建立MSF的准则，管理人员、工作过程和技术实现。
注：关于信息技术基础结构实现的详细介绍将于近期推出。
浙公网安备 33010602011771号