MSA 企业设计
在考虑个别情景的详细要求之前，我们必须了解一些企业体系结构设计方案。这些设计方案按照应用程序可用性、安全性、可伸缩性和性能等几个方面来表述。另外，了解任何技术要求的业务需求也非常重要。一旦确立了业务需求，我们就可以设计和部署能够支持应用程序指定服务等级的应用程序基础结构。
以下章节详细说明了业务需求，以及如何构建应用程序基础结构来支持最普通的应用程序体系结构模型。此外，本节还介绍了具体的基础结构实例和相应的应用程序部署的更详细信息。
本页内容
业务需求
企业应用程序的开发、部署和操作需要雄厚的应用程序基础结构。这种基础结构必须满足信息技术（IT）组织对于可用性、安全性、可伸缩性和可管理性的要求，并提供各种工具以使应用程序能够满足这些要求。这些工具包括：
| • |
执行应用程序组件的托管环境。 |
| • |
应用程序组件之间通信的分派机制。 |
| • |
支持服务等级监控和问题诊断的管理规范。 |
| • |
同时针对结构化和非结构化数据的数据存储设备。 |
应用程序基础结构需要提供能够水平和垂直伸缩的元素，以支持不断增长的需求。例如，随着组织的电子商务站点变得越来越受欢迎，其客户数量不断增加，应用程序基础结构应能够相应扩展以满足不断增长的需求。基础结构元素应高度可用、可伸缩，并能支持为其所指定的服务等级。这些元素还必须为应用程序提供高度的灵活性以满足其服务要求，其中可能包括提供诸如分区和集群等机制。
根据应用程序的复杂性和大小，如果没有在模拟生产环境的实验室中进行广泛测试而贸然改变生产环境，可能存在极大风险。应用程序基础结构必须能够支持一个独立的集成、过渡环境；应用程序可以在部署到生产服务器之前在这个环境中进行全功能测试。过渡环境在规模上可能与生产环境不同，但应拥有生产环境的所有关键元素。
安全性（是任何组织的基本要求）从应用程序基础结构角度来看也非常重要，因为外部客户端以及内部客户端会访问某些元素。组织通常维护着许多敏感和机密的数据，如：员工数据等。组织无论付出多大代价都要保证这些数据不被损坏。违反安全性可能影响这些数据，从而影响关键业务应用程序服务，并导致巨大的收入损失。因此应用程序基础结构必须能够应对任何预测的或实实在在的安全风险，并能在发生灾难时做出正确的应变措施，这一点非常重要。
体系结构定义
MSA 2.0 环境提供了以下来自 Microsoft 的应用程序基础结构元素，每个元素都有助于为部署和操作关键任务应用程序建立一个坚实的基础：
| • |
WindowsServer 2003 操作系统： 提供一个安全、可管理和灵活的平台。 |
| • |
.NET Framework： 提供了一个安全、可管理的应用程序代码执行环境，以及使应用程序组件能够像 Web 服务一样可用的方法。这种支持基于 Web 的应用程序组件的能力在异构计算环境中提供了更高的互操作性。此外，.NET Framework 提供了通用语言运行时（Common Language Runtime，CLR）。CLR 支持面向对象的多语言程序设计和丰富的类库集合，用于构建 Web 和瘦客户端应用程序。 |
| • |
Internet 信息服务（Internet Information Services，IIS）： 提供可靠、高性能和可配置的 HTTP 请求分派服务，作为处理传统 Web 请求（如：超文本标记语言（Hypertext Markup Language，HTML）、活动服务器页（Active Server Pages，ASP）和通用网关接口（Common Gateway Interface，CGI）脚本）和 .NET 远程处理和 Web 服务请求的基础。IIS 还提供简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）和文件传输协议（File Transfer Protocol，FTP）工具。) |
| • |
COM+： 提供强大的和高度规范化的组件托管环境，可促进高效地组件执行、故障隔离和管理。 |
| • |
消息队列（Message Queuing，又称为 MSMQ）： 提供结合可靠消息递送的异步消息队列服务。 |
如下图所示，这些应用程序基础结构元素需要低级软件、硬件和网络服务支持。该图描述了网络、硬件和应用程序基础结构的不同典型组件如何在一起工作来运行企业应用程序。应用程序（如：Microsoft SQL Server?、BizTalk? server、Commerce Server、Content Management Server 和定制应用程序）使用运行在 Windows Server 2003 上的应用程序基础结构元素（如：IIS、COM+、消息队列和 UDDI）的核心服务。此外，应用程序和应用程序基础结构元素使用了网络基础结构来提供基本传输功能，用于信息传输。
服务蓝图 指南中的“Web 应用程序服务”、“中间件服务（Middleware Services）”和“数据服务”章节中提供了有关应用程序基础结构服务的更详细指导。欲了解基于应用程序分层和部署层概念来设计和部署应用程序的指导，请参阅在以下 URL（统一资源定位符）的 “.NET 应用程序体系结构：设计应用程序和服务”文档：
msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp
应用程序基础体系结构概念和术语
本章概括介绍了结合使用以提供核心应用程序服务的各种应用程序基础结构元素。本章旨在帮助系统管理员大致了解某些常用的应用程序体系结构，从而使他们能够更好地了解自己企业中所支持的应用程序的基础结构需求。本章没有讨论如何设计应用程序的细节。欲了解有关应用程序设计的信息，请访问 Microsoft 模型和实践 Web 站点，URL 如下：
当设计应用程序基础体系结构时，我们有必要参考一个应用程序的体系结构元素。本章使用了规范的应用程序体系结构概念和术语，这些概念和术语列在 Microsoft TechNet “.NET 应用程序体系结构”文档中，URL 地址参见上一节。TechNet 定义了在本章中广泛使用的与应用程序体系结构相关的大量术语，如：组件、层、级和汇编组件。为了方便起见，在此重复给出这些术语的定义。
“组件” 指一个逻辑软件模块，如：.NET 或 COM 组件。组件的集合构成了应用程序。这些应用程序可能进一步分组成不同类型的组件，从而决定了每个组件所属于的 “层”。
“层” 是指应用的一个逻辑分区。该分区包括给定类型的组件。根据每个层的组件类型所执行的应用程序责任，所采用的模型将应用程序分区成三层。这三层分别是：
| • |
表达层： 组件类型包括用户接口（User Interface，UI）和 UI 进程（UI Process）组件等，主要负责创建 UI 元素，封装处理该用户的 UI 导航的逻辑。 |
| • |
业务层： 组件类型包括业务工作流（Business Workflow）、业务组件（Business Component，BC）、业务实体（Business Entity）和服务接口（Service Interface，SI）等，负责封装组成应用程序核心的业务进程和规则。 |
| • |
数据层： 组件类型包括数据访问逻辑（Data Access logic，DA）和服务代理（Service Agent，SA）组件等，分别负责封装处理对特定数据源（DS）和 Web 服务的数据访问的复杂性。 |
“级” 是一个逻辑实体，包含一个或多个物理主机或设备，逻辑层就被部署在这些级中。有时，物理级直接对应逻辑层（例如，Web 级对表达层，应用程序级对业务层，数据级对数据层)；有时，多个层被部署到一个单一级。
下图描述了一个假设情景。其中，表达层被部署到 Web 级，业务和数据层被部署到应用程序级。
图 2：应用程序层和物理级
汇编组件是 .NET Framework 所使用的构建模块，用于解决动态链接库（DLL）版本管理和部署问题。这些问题通常称为“DLL 地狱（DLL hell）”。在许多方面，汇编模块等同于 COM 环境中的 DLL。在本质上，汇编模块是“逻辑 DLL”，因为它们在 COM 中没有完全对应的术语，虽然它们非常类似于 COM 服务器模块（ .exe 或 . dll 文件）。欲了解有关汇编组件的更多信息，请参阅本指南中的“中间件服务”章节。
在本章中，尤其在描述具体情景的设计方案的示意图中，对每层组件的参考都可以被当成是对该层本身的暗示参考。例如，对 BC 和/或 SI 组件的参考暗示了对业务层的参考，而对 UI 组件的参考则暗示了对表达层的参考。
本章主要阐述这些应用程序层如何与应用程序基础结构元素相关联，并阐述了推动部署选择的设计选择。
.NET 和 COM 组件模型
Windows Server 2003 环境支持为 .NET 和 COM 组件模型开发的应用程序的共存和彼此之间的互操作。
这两种组件模型在许多方面不尽相同。然而，大部分应用程序基础结构问题产生自组件模型的以下方面：
| • |
组件注册，使组件能够在运行时被发现 |
| • |
上下文环境，其中于组件对应于客户端上下文而运行 |
| • |
组件的执行托管环境 |
为了在运行时被参考，COM 和 .NET 组件都必须能够对其各自的运行时服务“可见”。对于 COM 组件，这意味着注册这些组件，从而也就意味着在注册表中记录它们的相关位置信息。对于 .NET 组件，这意味着将这些组件放到 .NET 运行时被设定去寻找组件的几个位置之一。
组件必须运行在托管环境之中。例如，COM+ 可能为 COM 组件提供组件执行托管环境，而 .NET 运行时为 .NET 组件提供组件执行托管环境。这两种执行托管环境都可配置，并适合于所部署的基础结构；本指南的“中间件服务”章节提供了每种环境的详细配置信息。
欲了解 COM 组件模型的详细信息，请参阅位于以下 URL 的“Microsoft 组件服务”文档。
www.microsoft.com/com/wpaper/compsvcs.asp
欲了解 .NET 组件模型的详细信息，请参阅本文档集合中的“服务蓝图”指南中的“中间件服务”章节。
使用远程处理和代理需要考虑的其它事项，在以下章节中说明。
组件间通信
在每一种组件模型中，如果组件运行在其调用程序的执行上下文环境之外－－例如，在不同计算机上运行，或在相同计算机上的不同执行空间（过程）中运行－－其调用程序将把该组件视为“远程”运行。对于 COM，组件运行所在的执行上下文环境或容器被称为单元（apartment）；而对于 .NET，组件的执行上下文环境被称为应用程序域（AppDomain）。当运行在不同执行上下文环境中的两个组件彼此进行通信时，它们需要应用程序基础结构的服务以完成通信。这可能涉及跨计算机、网络甚至地理边界的通信。在 COM 中，这可能采取分布式 COM（Distributed COM，DCOM）的形式；而在 .NET 中，这可能采取 .NET 远程处理或 Web 服务的形式。在每种情况中，都需要在客户端计算机和服务器上进行某种类型的应用程序配置。配置类型将因为应用程序的不同而有所差异。在 .NET-connected 应用程序的情况下，配置信息可能采取可扩展标记语言（extensible markup language，XML）文件的形式，使用应用程序（如：web.config 文件）进行分配；而 DCOM 则可能使用配置工具（如： Dcomcnfg.exe ）或从 COM+ 导出的安装程序来完成。
欲了解有关 .NET 中远程处理的详细信息，请参阅“服务蓝图”指南中的“中间件服务”章节中的“.NET Framework”小节。有关 COM 中的远程处理和代理的详细信息可以在以前参考的 “Microsoft 组件服务” 文档中找到：
www.microsoft.com/com/wpaper/compsvcs.asp
欲了解有关 .NET 应用程序域的更多信息，请访问：
msdn.microsoft.com/library/en-us/cpguide/html/cpconapplicationdomains.asp
应用程序的需求以及基础结构如何来满足这些需求
总体上，应用程序都会有以下基本要求：
| • |
能够与其客户端进行交互，无论是交互式客户端还是软件客户端（例如，使用 Web 服务）。 |
| • |
提供一个地点，以执行由其客户端所请求的处理。 |
| • |
能够作为可调用服务，与其它应用程序进行程序化交互。 |
| • |
提供一个地点，以存储永久数据。 |
与客户端的交互涉及接收请求，把请求分派到应用程序代码的正确部分，将应用程序的回复路由回客户端。对于基于 Web 的应用程序（包括使用浏览器客户端和使用 Web 服务客户端的应用程序），IIS 提供了与客户端进行交互的能力。对于为 COM 客户端提供服务的应用程序，COM+ 提供了这种能力。
请求分派与请求处理之间的基础结构边界往往模糊不清。例如，IIS 提供了客户端交互能力（交互式客户端和软件客户端）和多个支持请求处理的模型。其中某些模型委托 COM+ 和 .NET Framework 工具来承担这一具体责任。总体上，.NET Framework 和 COM+ 可以被视为进行请求处理的地方；更准确的描述需要进一步详细了解这些基础结构工具。
根据两种应用程序实施的相似程度，应用程序可以进行彼此交互。外部系统互操作性问题可以通过多种解决方案技术加以解决，包括正在快速涌现的、基于使用 Web 服务协议的方法。.NET Framework 通过 Web 服务提供对于应用程序功能的使用和显示的广泛支持。然而，目前还存在其它一些外部系统可操作性技术－－例如，使用 Host Integration Server 2000 与 IBM 系统（如 S/390 和 AS/400）进行互操作。
注意，这些原理都适用于同步和异步请求处理。在异步处理时，请求处理不再与提交请求的客户端进行交互。
以下部分将详细说明具体的 Microsoft 技术。
Internet 信息服务
IIS 在应用程序基础体系结构中发挥多种作用，并执行以下功能：
| • |
向 UI 客户端提供静态内容。 |
| • |
分配对动态内容（ASP/ASP.NET、CGI 和 ISAPI）的请求。 |
| • |
托管.NET 远程组件的执行。 |
| • |
分配 Web 服务请求（ASMX）。 |
欲了解有关 IIS 的更多信息，请参阅本文档集合中的“服务蓝图”指南的“Web 应用程序服务”章节。
.NET Framework
.NET Framework 指管理应用程序代码执行和 .NET Framework 类库（应用程序调用它们来完成通用程序设计服务，如：数据处理、通信、线程和数据访问）的通用程序运行时（Common Language Runtime，CLR）。此外，.NET 定义了跨语言的面向对象的程序设计模型，以及使可用应用程序功能作为 Web 服务的固有功能。
欲了解有关 .NET Framework 的更多信息，请参阅本文档集合中的“服务蓝图” 指南中的“中间件服务”章节。
COM+
COM+ 提供了一个执行环境，组件可以在其中运行。另外，还提供了一组对于扩展应用程序以支持大量用户至关重要的服务，其中包括：
| • |
分布式事务处理协调，可确保数据库的完整性。 |
| • |
列队组件，可提供异步执行并能够帮助应用程序处理网络故障。 |
| • |
对象池，使应用程序能够支持数量比原来更多的用户。 |
COM+ 将“COM+ 应用程序”概念定义为已部署的 .NET 和传统 COM 组件所属的管理单元。在指定计算机上可能有一个或多个 COM+ 应用程序，每个应用程序可能包括一个或多个组件。一个指定组件不可能属于多个 COM+ 应用程序，除非 COM+ 分区已经启用。欲了解有关 COM+ 分区的更多信息，请参阅以下 URL 的 “COM+ 分区”：
msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_partitions_1gdb.asp
组件执行环境的某些特性是其所属的 COM+ 应用程序的属性（例如安全上下文环境），而其它特性则是组件本身的属性（例如，事务处理和池化能力）。欲了解有关不同 COM+ 服务的更多信息，请访问：
msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_partitions_1gdb.asp
消息队列
消息队列（又称为MSMQ）提供异步队列服务，使应用程序能够以时间分离（time-decoupling）的方式交换消息。消息队列的典型应用包括：
| • |
COM+ 列队组件工具，使用消息队列来提供异步组件方法执行。 |
| • |
对执行长期运行报告生成等任务的请求执行时间分离。 |
| • |
分离环境中的请求处理（例如，与移动客户端有关的间歇连接）。 |
| • |
分离环境中可靠的事务型数据转发。 |
欲了解有关消息队列的更多信息，请参阅“消息队列概述”文档：
msdn.microsoft.com/library/en-us/msmq/msmq_about_overview_1p9z.asp
体系结构设计
应用程序基础体系结构的设计必须满足几个同等类型的要求。诸如可用性、安全性、可伸缩性和可管理性等问题必须得到解决，同时还要满足应用程序部署和事务处理的前提条件。满足一部分要求的设计选择可能无法满足另一部分的要求，并往往会影响到应用程序设计。例如，提高应用程序可用性或可伸缩性的某些技术必需在多个群集节点上复制应用程序层。然而，实施复制可能导致安全问题，并增加管理已部署应用程序的复杂性。
对于应用程序基础结构的大部分要求－－包括其应用程序元素（代码、配置数据、应用程序数据和架构）的安装、配置和部署－－都产生自应用程序运用基础结构的方式，以及应用程序所基于的特殊体系结构模式。此外，还需要考虑应用程序所支持的客户端类型。最后，如何在应用程序中管理事务和以何种方式开发应用程序等特性也可能影响应用程序基础体系结构。这些考虑事项将在以下章节中予以说明。
应用程序部署考虑事项
应用程序部署需要高度的灵活性，以满足可用性（可执行负载平衡和故障转移的群集)、安全性（物理级隔离、防火墙/信任区域）、可伸缩性（负载平衡群集）和可管理性（COM+ 分区、IIS 应用程序池）的要求。这些要求给多数应用程序基础结构的安装和配置带来了挑战。
应用程序可以采用许多方式进行部署。通常，差异由数量较少的不同情景组成；这些情景显示了如何结合可选干涉信任区域边界（经常由防火墙服务支持）将应用程序层部署到物理级（可能已群集）。应用程序部署通常采用两类群集：
| • |
负载平衡群集： 指在可由单一虚拟 IP 地址访问的 2n 个节点上复制“只读”应用程序层（例如，包括 UI 组件的应用程序层）。此类群集提供了外扩能力，并改善了可用性。在负载平衡群集中，当请求正在一个指定节点上进行处理时，该节点出现故障，则该请求不能被确定，虽然进一步的请求将不会到达该故障节点，而将被发送到其它正常工作的节点上。 |
| • |
故障转移群集： 指可提供高可用性的“读写”应用程序层的群集（例如，包含数据库的应用程序层）。在故障转移群集中，当请求正在一个指定节点上进行处理时，该节点出现故障，则请求处理终止，事务被返回。 |
信任区域（或安全区域）指由防火墙限定边界的计算机网络；防火墙只允许有限几种通信协议（通常是 HTTP/HTTPS）通过。这些区域提供了防止可能危害代码和数据安全性的攻击的边界，通常由组织的安全人员进行定义。大部分企业情景都属于三种信任区域：
| • |
周边信任区域 |
| • |
内部信任区域 |
| • |
部门信任区域 |
周边和内部信任区域非常容易理解，部门信任区域的概念适用于许多情况，如对内部信任区域屏蔽敏感的部门数据（典型例子：人力资源数据）或法律/监管要求需要对内部网络屏蔽某些类型的数据。在任何情况下，术语“部门信任区域”都是指包含在内部信任区域中的一个信任区域。欲了解有关信任区域的更多信息，请参阅本指南中的“MSA 安全体系结构”章节。
无论实施面向公众的 Internet 站点、内部企业应用程序、受限制的访问部门应用程序，还是包含来自上述项目的元素的应用程序，在物理应用程序基础结构上部署应用程序体系结构层的方法通常都可归纳为三种类别：
| • |
物理隔离级： 在此类中，邻近的应用程序体系结构层被部署在物理隔离级上，包括由防火墙隔离物理级的情况。这种方法带来了大量应用程序基础结构配置问题。如果各级都在相同的信任区域内，问题往往较为简单；如果在不同信任区域内，则中间的防火墙将提出有关安全性和远程处理的要求，应用程序设计人员和网络管理员必须合力解决这些要求。另外，如果不同的信任区域不相邻近（例如，周边和部门信任区域），当设计应用程序时，必须考虑到流量跨越多个信任区域的路由。 |
| • |
群集级： 在此类中，应用程序层被部署到针对负载平衡或故障转移而群集的级上。例如，业务层的组件被部署到正在提供组件负载平衡的应用程序服务器上。这种方法在管理组件和限制它们可保持的状态方面带来了挑战。 |
| • |
合并级： 在此类中，多个层被部署到相同的物理级上。这包括在指定物理级上部署多个应用程序的选项，称为“服务器合并”。无论该级是否群集，这种方法都给这些应用程序的管理、安全性和性能优化带来了问题。 |
假设部署应用程序的这些机制（如：群集和区域）和方法已经确定，您还需要考虑大量应用程序部署情景。这些情景产生自您在物理部署应用程序体系结构层时所做出的不同选择。这些情景将拥有不同的特性，包括：
| • |
应用程序是面向外部、内部，还是受限制的内部访问。 |
| • |
应用程序是不是作为交互式客户端和/或程序设计客户端（参阅“应用程序客户端类型”章节）。 |
| • |
应用程序要求支持独立伸缩的层隔离、故障隔离，还是网络流量隔离。 |
这些场景还反映了关于某些在相同或不同服务器上运行的邻近应用程序体系结构层的选择，以及邻近服务器是否由防火墙进行隔离。欲了解有关该主题的更多信息，请参阅以下 URL 上的“.NET 应用程序体系结构”文档的“物理部署和操作要求”章节：
msdn.microsoft.com/library/en-us/dnbda/html/AppArchCh4.asp
应用程序客户端类型
运行在企业数据中心内的应用程序可由各种类型的客户端所访问。应用程序设计人员在决定使用何种类型的客户端的时候，需要考虑业务要求和基础结构要求（如：安全性和连接性）。安全性考虑事项包括诸如身份验证机制（例如，匿名、集成 Windows、通行证、基于 ASP.NET 的表格和用户数据库）等标准，以及客户端将要运行的位置（如：内部信任区域或 Internet）。连接考虑事项包括客户端可用的网络带宽等标准；例如，在分支机构的客户端可能拥有比从内部企业网络连接的客户端速度更慢的广域网（WAN）连接。
您可以考虑几种客户端类型，每一种都可能影响应用程序基础体系结构。主要的客户端类型有：
| • |
瘦客户端（Web 浏览器），应用程序逻辑和数据位于服务器上。 |
| • |
胖客户端，不同的应用程序逻辑部分（和可能的数据）位于客户端上。例如，这可能包括 UI 相关逻辑和某些用户首选数据。 |
| • |
访问 Web 服务接口的软件客户端（应用程序在此提供了一个程序可调用的接口，供其它软件使用）（服务器未提供任何 UI）。 |
当客户端向应用程序发出请求时，无论在 Web 浏览器上的交互式客户端还是服务客户端，该请求都可以被同步处理，并将响应返回客户端；或被异步处理，并向客户端返回通知，承认已经接受请求。异步请求在被应用程序所接受后，可以随时进行处理。
瘦客户端
在瘦客户端情况下，客户端计算机从 Web 浏览器访问应用程序。浏览器从本质上表达 HTTP/HTTPS 请求，并向 Web 服务器（例如，IIS）发送这些请求，然后提交服务器响应该请求发送给它的 UI。Web 服务器作为 HTTP/HTTPS 请求分派工具，这意味着它把请求路由到应用程序代码的正确部分，并将应用程序的响应路由回正确的客户端。处理这些 HTTP/HTTPS 请求的应用程序代码可能是 ISAPI 扩展名或过滤器（ .dll ）、传统 ASP 页（ .asp ）、ASP.NET 页（ .aspx ），或一个 Web 服务处理程序（ .asmx ）。在任何情况下，HTTP/HTTPS 请求的这些初始处理程序通常被称为表达层。除了管理用户接口之外，该层还把业务归纳的处理委托给业务层的组件。业务层组件实际上可能在其调用程序的环境中运行，或是在独立的计算机上运行。在每一种情况下，数据层通常都在一组独立的故障转移群集服务器上运行。
胖客户端
在胖客户端情况下，表达层以及业务和数据层的某些部分可能运行在客户端计算机上的客户端进程中。胖客户端实施要求某种类型的客户端安装。.NET Framework 的推出极大地简化了向用户的台式计算机部署胖客户端应用程序的难度，同时降低了相关的风险。欲了解有关 .NET-connected 胖客户端应用程序的更多信息，请参阅“服务蓝图”指南中的“中间件服务”章节。
Web 服务客户端
在访问 Web 服务接口的软件客户端情况下，客户端表达了使用简单对象访问协议（SOAP）的 Web 服务请求，将其发送到 Web 服务，然后等待响应。Web 服务包含一个瘦客户端层，该层通常在 IIS 下运行，并把请求处理委托给提供 Web 服务功能的业务层中的组件。Web 服务在本质上提供通过 HTTP 访问应用程序组件的功能；Web 服务客户端的范围可能包括由 Web 浏览器连接的 Web 应用程序、胖客户端应用程序和不含用户接口的服务器应用程序。
事务
事务包括将单独的数据库操作组合在一起，以保证基本数据的完整性。例如，将钱从一个银行帐户转到另一个银行帐户的过程包括两次数据库更新－－从一个帐户的借款和到另一个银行帐户的贷款－－两者必须作为一个整体同时成功或失败。如果借款成功而贷款失败，资金将会受损失而使客户不满。相反，如果贷款成功而借款失败，将产生资金，可能会使银行不高兴。
应用程序处理事务的方式将影响所用的应用程序基础结构元素的选择。例如，COM+ 事务服务（Transaction Service）会影响组件管理事务（可能更新一个或多个数据库）的行为。
这种事务概念还适用于必须在一个工作单元中更新多个资源的情况。例如，应用程序必须在一个事务中更新数据库的某些部分，发送消息队列信息，以及通过 COMTI 与现有事务进行通信的情况。该事务将跨越三个单独的资源管理程序：SQL Server、消息队列（Message Queuing）和 IMS。在 Windows Server 2003 环境中，Microsoft 分布式事务协调程序（Microsoft Distributed Transaction Coordinator，MSDTC）提供跨资源的事务协调，确保了该分布式工作单元的完整性。跨越计算机边界使用 MSDTC 要求 MSDTC 可用并且在事务中涉及的所有计算机上运行。此外，某些 TCP/IP 端口必须予以配置，以使 MSDTC 能够与正确的资源管理器进行通信。欲了解有关配置 MSDTC 以便跨越防火墙进行工作的详细信息，请参阅 Microsoft 知识库文章 250367，地址：
support.microsoft.com/default.aspx?scid=KB;EN-US;250367
在 Web 服务中，处理与 Web 服务有关的事务工作的 WS-事务（WS-Transaction）机制正在成为标准。欲了解有关 WS-事务的更多信息，请参阅：
msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transaction.asp
维护大量记录需要以高效方式来访问和更新记录。因为某些数据可能包括敏感信息，所以需要使用安全方法。此外，数据服务应高度可用，以满足应用程序对持续数据访问的需求。欲了解更多信息，请参阅本文档集合中的“服务蓝图”指南中的“数据服务”章节。
支持开发生命周期的应用程序基础结构
在大型 IT 组织中的应用程序开发、部署和托管通常会涉及多支独立的开发团队以并行方式处理大量应用程序，以便将其部署到共享托管环境中。此类动态环境需要一个有秩序的过程，以便将应用程序元素从初始开发阶段推进到高度稳定和紧密管理的生产环境中。
应用程序在其生命周期和部署计划的不同阶段所经历的方式需要应用程序的多种不同的并行实例。这些实例或环境在不同的组织中拥有许多名称，但以下名称最为常用：
| • |
开发环境 是进行单元级开发的场所。因此，软件和数据结构在这个环境中趋向于可变。开发人员可以在这里随意修改处于开发阶段和在其测试环境中的应用程序模块，以适应单元级开发需求。在这个环境中，开发人员通常在开发工作站（他们通常在此拥有全部管理权限）上单独工作。开发环境是一个“沙箱（sandbox）”环境，开发人员可在此不受限制（例如在其它环境中可能存在的安全限制）地随意使用不同的应用程序基础结构元素。这使得开发人员能够集中全力构建应用程序逻辑，并了解如何最好地使用各种可用的应用程序基础结构元素，而不受环境的限制。 |
| • |
集成环境 是应用程序单元（软件模块、数据计划和数据内容）首先进行组装，然后作为集成套件进行测试的地点。该环境也是可变的，但是比开发环境稳定的多。此处的目标是在独立开发的模块或计划中强制执行统一标准。通常在此环境中，开发人员没有像在开发环境中那样的全部权限。因此，他们第一次需要解决对于最终的目标基础结构的安装、配置和安全性要求等问题。 |
| • |
测试环境 是通过测试实践运行应用程序的“候选版”级版本的地方。它与生产环境一样进行严格控制，并且可变程度比集成环境低得多。此处的目标是假定已集成应用程序相对稳定，测试其稳定性、正确性和性能。此环境通常去除了对开发人员的限制。在此环境中部署和更新应用程序由测试团队进行控制，并且往往是由构建或基础结构团队的一名成员来完成。 |
| • |
过渡环境 是应用程序在经过测试环境中的完全测试后所驻留的地方。它为将应用程序部署到最终生产环境提供了一个非常方便的场所。由于过渡环境往往被用于执行最终测试和检查应用程序功能，其应尽可能近似于生产环境。例如，过渡环境不仅应拥有与生产计算机相同的操作系统和应用程序，还应拥有类似的网络拓朴结构（测试环境可能没有）。通常，过渡网络环境在所有方面都模仿生产环境，除了它是一个缩小版之外（例如，它可能拥有比您的生产服务器更少的群集成员或更少的处理器）。 |
| • |
生产环境 是组织实际使用应用程序的地方；它是最不可变、控制最严格的地方。 |
由于成本限制，每个 IT 组织可能不具有上述全部环境，但是每个环境所发挥的单独作用对于所有应用程序开发和部署活动都是通用的。
取决于个别应用程序的不同需求，应用程序基础结构的配置和部署将有所差异。您应该考虑的其它元素还包括；
| • |
防火墙： 即使您没有在非生产环境中部署防火墙，您也应该在测试环境中进行测试时，提前计划和考虑通信的端口限制和方向。模仿防火墙的软件产品目前是可用的，并且是对测试环境的一个良好补充。应用程序设计人员和网络管理员应与其安全管理员进行讨论，以决定可能实施的限制。 |
| • |
网络拓朴结构： 您的过渡环境可能比生产环境小，但是您应该与网络管理员协作，以获得与生产环境尽可能一致的网络拓朴结构，从而确保网络通信按计划运作。 |
| • |
处理器数量： 如果您的目标环境拥有多个处理器，您应该在多个处理器上测试应用程序，以确保多线程代码能够按计划运作。 |
| • |
负载平衡群集： 如果您的目标环境具有负载平衡群集功能, 您应该在一个具有负载平衡群集功能的环境中测试您的应用程序。 |
| • |
故障转移群集： 如果您的目标环境拥有故障转移群集，您应该在拥有故障转移群集的环境中测试应用程序。 |
本地设计
如前所述，应用程序部署必须非常灵活，以满足可用性、安全性、可伸缩性和可管理性的要求。不同程度的部署灵活性将导致应用程序基础结构安装和配置的不同选择。因为应用程序被设计、开发和部署用于满足每个企业的特定业务和基础结构要求，可能的应用程序部署组合数量非常庞大。本节说明了某些常用的部署配置，以便为讨论前面所述的元素提供一个基础。
就像由于您的特定要求，部署应用程序有许多方法一样，确保应用程序的安全性也有许多方法。下面的插图描述了各种常用的通信机制，包括常用的端口。欲了解有关 .NET 应用程序安全性的具体信息，我们强烈推荐您参阅 “构建安全的 ASP.NET 应用程序：身份验证、授权和安全通信” 文档：
msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp
设计方案 1－－纯内部二级设计
在纯内部二级设计中，整个应用程序运行在一个单一的信任区域内（具体说，是内部信任区域）。表达层和业务层运行在单一级上（即相同的计算机或群集上）；该级是一个组合的 Web/应用程序级。这种设计适用于客户端位于公司内部的应用程序，尽管应用程序本身可能允许内部信任区域访问外部服务，如：Web 服务。
优点
在纯内部二级设计中，应用程序的大部分元素都在单一级上运行（数据库除外）。因此，所有跨级和跨防火墙问题都得到了解决，从而实现了以下优点：
| • |
不存在跨服务器的远程处理问题。 |
| • |
简化了部署。 |
| • |
可以更简单地决定可用性。 |
缺点：
在纯内部二级设计中，在同一级上运行表达层和业务层的缺点包括：
| • |
层不能独立伸缩。 |
| • |
层不能独立可用。 |
设计方案 2－－纯内部三级设计
在纯内部三级设计中，整个应用程序在内部信任区域中运行，但是表达层和业务层分别运行在单独的 Web 和应用程序级上。这种设计支持两个层的独立伸缩。然而，在不同级上运行两个层要求在这两个级之间配置 .NET 远程处理。
优点
纯内部三级设计方案的优点包括：
| • |
表达层和业务层可以进行独立伸缩。 |
| • |
在表达层与业务层之间提供了故障与资源的隔离和绝缘。 |
| • |
允许表达层和业务层独立可用。 |
缺点
纯内部三级选项的缺点包括：
| • |
需要在 UI 和 BL层之间进行远程处理配置。 |
| • |
需要在表达层和业务层之间进行安全性配置。 |
| • |
网络延迟将会影响性能（因为在表达层和业务层之间需要进行调用）。 |
| • |
问题诊断变得更加复杂。 |
设计方案 3－－外部二级设计（数据源内部）
在外部二级（数据源内部）设计中，表达层和业务层在组合 Web/应用程序级（连接到在内部信任区域中运行的数据源）上的周边信任区域内运行。这要求开放端口，以支持周边信任区域和内部信任区域之间的防火墙中的 SQL Server 和 DTC。
优点
外部二级（数据源内部）设计方案的优点包括：
| • |
在方案 1 中确定的让表达层和业务层在同一级上运行的优点。 |
| • |
防火墙在不可信安全性区域和数据源之间提供了额外的安全屏障。 |
缺点
外部二级（数据源内部）设计方案的缺点包括：
| • |
在方案 1 中确定的让表达层和业务层在同一级上运行的缺点： |
| • |
需要为访问数据库配置防火墙。 |
| • |
由于中间的防火墙，应用程序部署更加复杂。 |
设计方案 4－－外部三级（数据源内部）
在外部三级（数据源内部）设计中，表达层和业务层在单独的 Web 和应用程序级上的周边信任区域内运行；Web 和应用程序级连接到在内部信任区域中运行的数据源。
优点
在运行在不同级上的表达层和业务层方面，外部三级（数据源内部） 设计方案具有与选项 2 相同的优点。
缺点
外部三级（数据源内部）设计方案的缺点包括：
| • |
需要在表达层和业务层之间进行远程处理配置。 |
| • |
需要组件托管选择（IIS 或自定义）。 |
| • |
需要在表达层和业务层之间进行安全配置。 |
| • |
由于表达层和业务层之间、以及周边和内部信任区域（来自表达层或业务层）之间的网络延迟，性能会受到影响。 |
| • |
问题诊断变得更加复杂。 |
| • |
由于中间的防火墙，应用程序部署变得更加复杂。 |
设计方案 5－－外部三级（应用程序和数据源内部）设计
在外部三级（应用程序和数据源内部）设计中，表达层运行在周边信任区域中的 Web 级上；业务层运行在内部信任区域中的应用程序级上；数据源也在内部信任区域中。这种方案可能适用于面向公众的 Web 站点或服务。Web 站点或服务在周边网络中运行表达层或业务层，然而出于安全原因，其仍然需要在内部网络上运行业务层组件。
优点
外部三级（应用程序和数据源内部）设计方案的优点包括：
| • |
支持表达层和业务层的独立伸缩。 |
| • |
在表达层和业务层之间提供故障与资源的隔离和绝缘。 |
| • |
允许表达层和业务层独立可用。 |
| • |
以更安全的设置维护业务逻辑和敏感的元数据（例如：数据库连接串）。 |
缺点
外部三级（应用程序和数据源内部）设计方案的缺点包括：
| • |
需要在表达层和业务层之间进行远程处理配置。 |
| • |
需要在表达层和业务层之间进行安全性配置。 |
| • |
中间的防火墙在表达层和业务层之间的安全性方面实施了额外的限制，从而导致层与层之间缺乏域信任。 |
| • |
由于网络延迟，性能会受到影响。 |
| • |
问题诊断变得更加复杂。 |
设计方案 6－－内部二级（部门数据源）设计
内部二级（部门数据源）设计方案是设计方案 1 的变体。在此设计方案中，应用程序在内部信任区域中运行，并通过防火墙访问部门数据源（访问部门数据源受到限制），例如一个允许用户看到自己经过过滤的版本，否则限制访问人力资源数据的内部应用程序。此方案与其它方案（应用程序必须通过防火墙访问数据源）没有明显不同。
优点
内部二级（部门数据源）设计方案的优点类似于设计方案 1 的优点。此外，此设计方案支持应用程序访问敏感的部门设计，而不允许用户直接访问数据。
缺点
内部二级（部门数据源）设计方案与设计方案 1 的缺点相同。
设计方案 7－－外部三级（部门数据源）设计
在外部三级（部门数据源）设计中，表达层运行在周边信任区域中的 Web 级上，而至少一个必须被访问的数据源是在部门信任区域中。应用程序可以通过两种方法访问数据源：部分应用程序代码必须通过两个防火墙（周边->内部和内部->部门）；或者它们必须使用在内部信任区域中运行的组件，而这需要周边与内部信任区域之间的远程处理和内部与部门信任区域之间的数据源访问。
优点
外部三级（部门数据源）设计方案与设计方案 6 的优点相同。
缺点
外部三级（部门数据源）设计方案的主要缺点在于增加了从周边信任区域中的级到部门信任区域中的级的寻址难度。
设计方案 8－－部门二级设计
在部门二级设计中，部门专用的应用程序完全运行在部门信任区域中。这与内部二级设计没有明显不同。
优点
部门二级设计方案与设计方案 6 的优点相同。
缺点
部门二级设计方案与设计方案 6 的缺点相同。
设计方案 9－－部门二级（内部数据源）设计
部门二级（内部数据源）设计方案在某种程度上与设计方案 6 正好相反，不会暴露任何其它信息。
优点
部门二级（内部数据源）设计方案与设计方案 6 的优点相同。
缺点
部门二级（内部数据源）设计方案与设计方案 6 的缺点相同。
设计方案 10－－对外部/公共 Web 服务的任何信任区域
从信任区域（周边、内部或部门）到公共 Web 服务要求应用程序（特别是服务代理（Service Agent，SA）组件）通过代理访问公共 Internet。此外，为充分确保 Web 服务的安全性，应用程序要求访问证书库（certificate repository）以便确保与 Web 服务通信的安全性。
优点
对外部/公共 Web 服务的任何信任区域设计方案的主要优点是允许监控和限制出站流量。
缺点
对外部/公共 Web 服务的任何信任区域设计方案的主要缺点是可能要求应用程序获取证书以通过代理（取决于代理的自身性质）。
体系结构依存关系
应用程序基础结构的目标是为用户提供应用程序服务。在 MSA 2.0 中定义的 5 个体系结构共同提供了一个适用于关键任务企业应用程序的 IT 环境。应用程序基础体系结构使用其它体系结构提供的服务（如：网络和管理），来提供对于应用程序基础体系结构的供应至关重要的服务。
服务依存关系
下表列出了应用程序基础体系结构与其所依赖的服务之间的关系。可以不使用所有这些服务而实施一个体系结构，尽管得到的体系结构将在范围或规模上相对缩小。
|
服务依存关系 |
服务的具体要求 |
|
.NET Framework |
提供支持 .NET 代码的通用语言运行时和类库。 |
|
COM+ |
支持 COM 组件以及由 .NET 服务组件托管和安全性 |
|
消息队列 |
支持已列队组件以及通用异步消息队列 |
|
Web 应用程序服务 |
针对 ASP.NET 页面的 .NET 远程处理组件（除了 .NET 服务组件之外）托管、Web 服务托管 |
|
数据服务 |
应用程序数据和某些应用程序元数据 |
|
文件服务 |
至少对配置文件是必需的（例如： global.asax 和 Web.config ） |
|
网络服务 |
提供各级之间以及客户端与服务之间的连接 |
|
证书服务 |
使用经过验证的身份、授权、证书和加密 |
|
基础结构管理服务 |
用于支持已部署内容和应用程序的管理 |
表 1：应用程序基础体系结构服务依存关系
标准和指导方针
应用程序使用多个与通信、数据表示、数据存储和访问、以及程序设计结构（如：美国国家标准协会（ANSI）库）有关的标准。欲了解应用程序如何使用这些标准的详细信息，请参阅“服务蓝图”指南中的“Web 应用程序服务”和“中间件服务”章节。
| • |
网络标准 （欲了解更多相关信息，请参阅“服务蓝图”指南中的“网络服务”章节。
|
||||||||
| • |
Web 标准 （欲了解更多相关信息，请参阅“服务蓝图”指南中的“Web 应用程序服务”章节。
|
||||||||
| • |
RDBMS 标准 （欲了解更多相关信息，请参阅“服务蓝图”指南中的“数据库服务”章节。
|
硬件要求
某些类型的服务器能够比其它设备更适用于执行特定任务，以及为不同的产品和技术提供主机服务。硬件要求取决于每组用户的具体应用模型，包括 Web 客户、应用程序管理员和软件工程师。例如，Web 服务器通常是具有大容量内存和强大处理能力的计算机。然而，它们不要求具有稳定的存储能力（如：独立磁盘冗余阵列（RAID）镜像），因为大部分数据均以更稳定的方式存储在其它位置。然而，Web 服务器应采取冗余配置并进行群集，以防止服务器过载或某一个服务器可能发生故障。
欲了解有关个别应用程序组件的硬件要求的更多信息，请参阅本文档集合中的“服务蓝图”指南中的以下章节：
| • |
“数据服务” |
| • |
“Web 应用程序服务” |
| • |
“中间件服务” |
可用性
应用程序只能在它们的元素可用的范围内可用。一个应用程序的可用性可以通过把其关键组件与其它可能发生故障的计算机和组件在物理上隔离而得到改善。例如，长时间运行的业务过程可以在群集服务器的独立级上实施，从而 Web 群（farm）中的服务器故障不会妨碍业务过程的完成。
应用程序可用性很难衡量，因为应用程序通常是由许多逻辑层组成，并能够部署到多个物理级上，有时在它们之间还部署了防火墙。例如，通过向 Web 站点发送一个简单的 HTTP 请求并通知获得了适当响应，可以获得衡量 Web 站点可用性的简化方法。然而，这个请求/响应交互将不会使用应用程序的所有元素。衡量应用程序可用性的一个更好方法是独立“ping”应用程序的层/级，并等待适当的响应。然而，即使这种方法也不能真正衡量可用性，因为应用程序故障往往发生在软件特定部分的交互之外。例如，一个指定的应用程序组件可能正确地响应由测试设备（harness）（用于驱动应用程序层以衡量工作状态）表达的特定请求，但是它可能无法响应由应用程序的其它层发出的请求，因为诸如软件版本不匹配、数据条件、安全性上下文环境和负载因素等问题。
欲了解有关如何使个别应用程序服务高度可用的更多信息，请参阅“服务蓝图”指南中的以下章节：
| • |
“数据服务” |
| • |
“Web 应用程序服务” |
| • |
“中间件服务” |
安全性
安全性是构建分布式应用程序－－特别是由防火墙隔离的跨多个物理级的应用程序－－的主要挑战之一。虽然在本指南中的“MSA 安全体系结构”章节中深入探讨了安全问题，但是我们还要在此说明一下有关应用程序体系结构的特定问题。
应用程序基础结构除了由传统基础结构安全组件（如：防火墙、代理和虚拟专用网（VPN））提供的安全机制之外，往往还实施其它安全性机制。例子包括限制只对被许可的客户端执行代码的应用程序，或对被传送到组件的数据进行加密的应用程序。当设计应用程序时，设计人员必须考虑的事项包括他们的代码将以何种身份执行、用于建立该身份（如果有）所使用的身份验证方法、在任何防火墙上需要开放的必要端口以及在客户端和服务器上运行所需的必要服务。
安全性概念在应用程序的上下文环境中分成许多方面，包括：
| • |
身份验证（如：凭证检查和基于证书的不可否认性） |
| • |
受限制的网络流量，包括关闭防火墙上的端口和在代理中的过滤功能。 |
| • |
限制对数据源（如：SQL Server）的访问。 |
| • |
限制对文件系统对象的访问（即 NTFS 安全性）。 |
| • |
通过使用安全通道和签名信息来保持数据完整性。 |
| • |
通过使用安全通道、通过虚拟专用网（VPN）的用户访问以及加密的消息传递，保持数据的机密性。 |
.NET Framework 提供了一个基于代码的安全模型，其中，运行一部分代码的特权是基于其调用程序向 CLR 提供的证据。这个安全模型允许应用程序将特定模型的调用程序限定为提供充足证据的调用程序（例如，从许可位置载入的数字签名）。此安全模型的详细信息在“服务蓝图”指南的“中间件服务”章节中有所提供。
安全性设计
每种应用程序基础结构设计都有独特的安全要求，这些要求由应用程序的业务要求、用户受众的特性、以及应用程序需要跨越的边界划分所驱动。
用户的物理位置以及业务要求可能限制了对某些用户的访问，或者要求在身份验证方法和应用程序类型（如：Web、Windows 或 Web 服务）上扩大某种类型的个性化规定。身份验证是指确定用户是其所声称的身份的过程。有多种方法可验证用户的身份，这取决于应用程序的类型以及将如何管理用户证书。例如，应用程序可能必须提供审计用户行为的能力，在此情况下，所选择的身份验证方法必须提供一个方法来跨越所有应用程序层跟踪用户。另一方面，没有审计要求的应用程序可能选择在表达层对用户进行身份验证，然后使用普通用户（或基于角色的系统中的用户）进行对业务层和数据层的所有访问。虽然对于网络设计人员或系统设计人员来说，应用程序级的详细信息可能并不重要而需要他们了解，但是他们需要知道与以下方面有关的某些元素：
| • |
身份验证方法是否要求访问在 Active Directory 目录服务中的用户证书，从而应用程序可能需要能够使用 LDAP 访问 Active Directory。 |
| • |
应用程序设计人员可能选择实施某种类型的基于规则的安全性，在这个过程中，他们将考虑不同的方案，其中部分方案可能涉及管理任务。例如，.NET 基于角色的安全性在本质上是 一种定制方法，但它往往依赖于在 Windows 域、Active Directory 或存储在数据库（如：SQL Server）中的定制计划中使用用户和群组。设计人员可能还选择使用 Windows Server 2003 企业版中所包括的新的 Authorization Manager（授权管理器）。 |
| • |
Windows 访问控制列表（Windows Access Control List，ACL）可以被用于为 ASP.NET 授权在特定应用程序文件上创建文件系统权限。如果授权依赖于 ACL 的使用，那么将需要确定和设置适当的权限。欲了解有关 ACL 的更多信息，请访问以下 URL 地址： msdn.microsoft.com/library/en-s/security/security/access_control_lists.asp |
| • |
根据应用程序的设计，在防火墙上需要打开的端口。 |
| • |
需要设置和分布以支持管理 .NET 代码的具体运行时安全政策。 |
| • |
应用程序需要运行的 Windows 服务和特性。计算机应采取能够减少攻击风险的方法来进行配置。这意味着不需要的特性和服务应被禁用或删除。因此，许多应用程序在从开发环境移植到更安全的环境（如测试、过渡和最终的生产环境）时将会失败，除非系统管理员知道所需要的相关服务。 |
另一方面，网络设计人员和系统设计人员需要通知应用程序设计人员可能影响其安全性计划的各种因素，如：
| • |
是否存在防火墙，以及由防火墙隔离的两个域之间的信任关系状态。 |
| • |
将被允许在防火墙上打开的端口中的限制。 |
| • |
是否存在组策略（Group Policy）限制。管理员使用组策略来定义具体的 Windows 配置并将这些配置关联到由 Active Directory 管理的特殊用户和计算机。应用程序设计人员在设计、开发和测试其应用程序时，需要考虑到这些限制。 |
下面列表中提供了一些例子，说明了边界如何影响安全性。这些边界中有一部分可以通过将多个应用程序合并到单一服务器上加以消除。
| • |
进程和 AppDomain 边界： 驻留在相同进程或 AppDomain 边界中的组件之间的通信受 .NET 提供的安全工具的影响。当应用程序组件必须跨进程（COM/.NET）或 AppDomain（.NET）边界进行通信时，边界安全性必须经过配置以支持这项操作。 |
| • |
级边界： 两个邻近应用程序层之间的级边界（即服务器边界）的引入，在应用程序必须满足远程处理安全性要求的意义上来说，将会影响应用程序的安全性。 |
| • |
层边界： 两个邻近应用程序层之间的防火墙的引入，可能以多种方式影响应用程序的安全性。最重要的是，出于安全原因，防火墙可能不被配置为允许域信任关系跨越其边界。这意味着当可以获得信任时，组件远程处理技术不能使用现成的默认安全模式进行操作。 |
| • |
群集边界： 当应用程序层在被群集的级上运行时，群集的安全性应以适合于应用程序安全性的方式进行配置。 |
| • |
在单一服务器上进行合并： 当多个应用程序在单一服务器上共存时，运行在该服务器上的其它应用程序可能以不适合该应用程序的安全级运行。例如，其它应用程序的用户可能没有访问正在讨论中的应用程序的授权。您需要特别关注，以确保运行在相同服务器上的所有应用程序拥有在同一安全区域内运行的权限。 |
欲了解有关 Authorization Manager（授权管理器）的更多信息，请访问以下 URL： www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/authm_topnode.asp
欲了解有关安全性的详细信息，请参阅本指南中的“MSA 安全体系结构”章节。欲了解与 .NET 有关的安全问题的详细信息，请参阅本文档集合中的“服务蓝图”指南中的“中间件服务”章节。
安全防范
安全防范可以通过组策略来实施。组策略提供了基于目录的桌面配置管理。组策略可以定义用户和计算机组的配置。使用组策略可以规定基于注册表的策略、安全性、软件安装、脚本、文件夹重定向和远程安装服务的设置。
组策略设置包含在组策略对象（Group Policy object，GPO）中，并能够通过关联 GPO 与 Active Directory 容量（用户和计算机驻留在此）而应用到用户和计算机。例如，一个组织可能规定，应用程序服务器（运行 .NET Framework）将不托管 Web 服务，并使用组策略来禁用在这些服务器上的 IIS 服务。
此外，某些安全防范可能在不同的应用程序基础结构元素中运用，以防止随意部署应用程序。这些安全防范必须超越使用管理工具来管理成功部署应用程序（如：IIS、.NET 和 COM+）所需要的各种基础结构元素。欲了解更多信息，请参阅本文档集合中的“服务蓝图”指南中的“Web 应用程序服务”和“中间件服务”章节。
可伸缩性
实现可伸缩性的一般方法是将应用程序分区成体系结构层。体系结构层可部署用于隔离物理级（可独立外扩）。实际上，在应用程序登陆点（如：表达层）的应用程序负载与针对给定调用路径位于应用程序中的后续下游层上的负载之间通常存在一对一的关系。
当确定瓶颈时，必须考虑到整个体系结构。例如，即使数据库服务器有充足的容量来处理两倍的高峰负载，整个系统也可能因为应用程序的某些特定方面而出现瓶颈，如线程争用或网络接口。通过预先计划可伸缩性，您就有可能避免存在于应用程序中的这些瓶颈。
欲了解有关可伸缩性的更多信息，请参阅“服务蓝图”指南中的相关章节：
| • |
Web 级： 请参阅“Web 应用程序服务”章节。 |
| • |
应用程序级： 请参阅“中间件服务”章节。 |
| • |
数据级： 请参阅“数据服务”章节。 |
可管理性
应用程序的可管理性对于确保其可用性和性能必不可少，并且在极大程度上取决于以下一些因素：
| • |
给予托管应用程序的元素（如：COM+、IIS 和 .NET Framework）的服务何种支持，以提供有关应用程序和服务精细控制的详细信息。 |
| • |
给予应用程序何种支持，以提供有关其健康状况的连续信息。 |
| • |
如何对应用程序的层进行分区，以实现应用程序的精细监控和控制。 |
| • |
管理（操作）基础结构的可用性。 |
应用程序管理基础结构的设计必须确保，当负责管理的应用程序出现错误行为时，该基础结构不受影响。操作人员应能够获得信息，以便管理应用程序的工作状态，满足服务等级协议（SLA）的要求，进行上扩或外扩以管理容量。欲了解有关向应用程序添加规范的详细指导方针，请参阅 MSDN 文章 “.NET 分布式应用程序设计中的监控”，地址：
msdn.microsoft.com/library/en-us/dnbda/html/monitordotnet.asp?frame=true
欲了解有关如何管理个别应用程序服务的更多信息，请参阅“服务蓝图”指南中的以下章节：
| • |
“数据服务” |
| • |
“Web 应用程序服务” |
| • |
“中间件服务” |
欲了解有关应用程序基础体系结构管理和操作的详细信息，请参阅“服务蓝图”指南中的“基础结构管理服务”章节。
性能
应用程序的性能通常按处理典型请求所用的时间进行大致衡量。这个时间可以从客户端的角度进行衡量，或从应用程序层（级部署在该层上）中的不同登陆点进行衡量。这种测量方法不同于衡量应用程序能够多有效地处理请求（在应用程序占用资源方面，如：中央处理单元（CPU）、随机存取存储器（RAM）、磁盘空间、网络带宽等等）。
通过调整应用程序设计和使用额外的基础结构进行外扩，应用程序的性能可以得到改善。欲了解更多信息，请参阅“服务蓝图”指南中的以下章节：
| • |
“数据服务” |
| • |
“Web 应用程序服务” |
| • |
“中间件服务” |
可支持性
应用程序的可支持性取决于应用程序基础结构（例如，.NET Framework 或 COM+）提供的诊断工具，以及应用程序在多大程度上设计用于提供支持功能，如：错误处理和诊断捕获。欲了解更多信息，请参阅“服务蓝图”指南中的以下章节：
| • |
“数据服务” |
| • |
“Web 应用程序服务” |
| • |
“中间件服务” |
合并
应用程序合并涉及在一个级（包括在负载平衡群集的节点中复制的级）上的两个或多个应用程序的连续部分。例如，假定已经部署了典型 Web 应用程序，因此其表达层是在一个运行 IIS 的级（一个负载平衡群集）上运行；其业务层在另一个级（另一个负载平衡群集）上运行；其数据库在第三个级（故障转移群集）上运行。如果在相同级上部署了隔离但采用相似设计的应用程序的各个层，在基础结构方面将产生一组截然不同的难题，包括：
| • |
一个应用程序无法利用其它应用程序的资源。 |
| • |
需要考虑每个应用程序的资源使用情况。 |
| • |
诊断问题（因为诊断实践不能影响在相同机器上运行的其它应用程序）。 |
| • |
基础结构变化管理。例如，如果您为一个应用程序而改变了 Microsoft ActiveX Data Objects（ADO）的版本，您就已经对所有应用程序改变了版本，从而要求应用程序之间更紧密的协调以支持基础结构变化。这还可能包括以应用程序框架的形式存在的“应用程序基础结构”（例如，共享或通用类库）。 |
互操作性
应用程序互操作性包括向外部系统发送程序设计调用和从外部系统接受程序设计调用。Web 服务是可供选择的一种新兴技术，尽管其它几种技术得到了广泛使用，其中包括：
| • |
支持企业对企业通信的电子数据交换（Electronic Data Interchange，EDI）。 |
| • |
支持与传统大型机应用程序相集成的 SNA（LU6.2/APPC、LU2/3270、X/5250）。 |
| • |
支持促进 WAN 连接性的 X.25。 |
无论使用何种集成技术，您都必须克服以下难题，包括：
| • |
网格化安全模型（例如，获取特定于系统的证书以通过外部系统）。 |
| • |
支持在外部系统数据表达式之间进行转换的配置（例如，EBCDIC 和 S/390 的各种数字格式，big-endian/little-endian 编码），包括地区和位置数据表达式的转换（例如，IBM 系统上的代码页）。 |
| • |
配置通信路径，如：TCP/IP、SNA 网络协议和 X.25。 |
| • |
处理跨平台问题，如：诊断日志记录和警报监控。 |
将 Microsoft Windows 作为集成环境
虽然有许多充分的理由要求企业快速和完全移植到 Windows Server 2003 环境，但是一些组织还是可能随时间推移分阶段进行移植，或限制在某些领域和服务上的移植。无论采用这两种方法中的任何一种，Windows Server 2003 都需要与组成其现有计算环境的不同系统、应用程序和平台相集成。Microsoft 提供了广泛的互操作性解决方案，使组织能够享受到 Windows Server 2003 环境带来的众多益处，同时保护了现有的 IT 投资。组织的基础结构无论基于 UNIX 并采用 IBM 大型机，还是完全处于 Mac 环境，都可以成功地集成 Windows Server 2003 并获得这两种技术的最佳特性。
作为支持混合计算环境的一个全面的互操作性解决方案，Windows Server 2003 能够：
| • |
使用常用协议与其它操作系统进行通信。例如，一个基于 Windows Server 2003 的服务器能够通过局域网（LAN）和 Internet 与 UNIX 设备进行通信。 |
| • |
访问在其它平台上共享的文件和打印机。Windows Server 2003 提供的服务支持在 Macintosh 系统上的文件和打印共享。它还支持附加服务，提供了与 UNIX 和 IBM 系统的文件和打印共享。 |
| • |
将新的应用程序与数据源相集成。Windows Server 2003 包括多种技术，能够促进新旧应用程序之间的数据和软件代码共享。 |
| • |
减轻管理多个系统的负担。例如，组织可以使用 Windows Server 2003 中包括的 Microsoft Active Directory 服务来统一和管理在大部分公司网络上所能找到的多个目录。 |
除了 Windows Server 2003 内建的互操作性特性之外，Microsoft 还提供了额外的服务和产品，来帮助 Windows Server 2003 与其它系统相集成。支持 UNIX 3.0 和 Host Integration Server 的服务可以分别帮助 Windows Server 2003 与基于 UNIX 和 IBM 的系统相集成。此外，Microsoft Windows Services for UNIX（结合了符合 Interix POSIX 标准的子系统）使其能够在 Windows Server 2003 上运行基于 UNIX 的应用程序和脚本。
下图说明了 Windows Server 2003 如何使用基于标准的协议支持和附属的 Microsoft 产品，来提供与非 Microsoft 系统的互操作性。圆圈的内环（灰色）表示 Windows Server 2003 基于标准的协议支持。外环表示使 Windows Server 2003 能够与其它平台和服务互操作的各种附属技术。这些附属技术的实例列在圆圈外面。
如图所示，Windows Server 2003 互操作性的核心是对大量常用通信和安全性协议的支持。这些协议包括：TCP/IP、轻型目录访问协议（Lightweight Directory Access Protocol，LDAP）、动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）、域名系统（Domain Name System，DNS）协议和 Kerberos Version 5 身份验证协议。通过这种支持，Windows 2003 应用程序能够与以下操作系统、服务和平台通信：
| • |
操作系统：Macintosh、HP-UX、Solaris、IBM AIX 和 Linux。 |
| • |
基于目录的服务：Novell NDS、Lotus Notes、Exchange；基于 LDAP 的目录。 |
| • |
数据库平台：如来自 IBM、Informix 和 Oracle 的平台。 |
除了 Windows Server 2003 内建的广泛协议支持，Microsoft 还提供了许多技术来帮助 Windows Server 2003 与其它操作系统相集成。下表列出了主要的操作系统平台，并确定了附属的 Microsoft 技术为这些平台提供互操作性的领域。
|
平台 |
网络 |
数据 |
应用程序 |
|
UNIX |
支持 UNIX 的服务 |
支持 UNIX 的服务，Microsoft Interix |
Microsoft Interix |
|
IBM |
Host Integration Server |
Host Integration Server |
Host Integration Server |
|
Macintosh |
支持 Macintosh 的服务 |
支持 Macintosh 的服务 |
无 |
表 2：Microsoft 提供的平台集成技术
大型组织通常已经拥有现成的计算基础，其中的现有应用程序运行在多种平台上，包括：IBM S/390（MVS/IMS/CICS/DB2 和 VM/CMS/SQLDS）、IBM AS/400、IBM S/36-38 和几种 UNIX 同类产品。运行在 Windows Server 2003 上的应用程序将需要与运行在这些平台上的应用程序相集成。Microsoft Host Integration Server 2000 提供了多种工具，来帮助在数据级（由 OLE/DB 提供商提供）和应用程序级（通过 COMTI）上集成系统。需要注意的是，在这些平台上集成应用程序和数据可能涉及使用除 TCP/IP 以外的协议，包括 IBM 的系统网络体系结构（System Network Architecture，SNA）协议，如 LU2（3270）和 LU6.2（APPC/APPN）。欲了解有关网络配置和应用程序的更多信息，请参阅 Host Integration Server 2000 文档。
互操作性－－Web 服务
Windows Server 2003 为使用和托管 Web 服务提供了广泛支持。Web Services Enhancements（WSE）提供了路由、提名、检查、安全性、事务、附件及其它工具，以支持在企业中实施 Web 所必不可少的广大功能。Windows Server 2003 提供了革命性的应用程序环境，用于构建、部署和运行 XML Web 服务，使应用程序能够充分利用 Internet 计算松散连接的原理。
|
特性 |
说明 |
|
固有 XML Web 服务支持 |
Windows Server 2003 提供了对 XML Web 服务标准的内在支持，包括 XML、SOAP、通用描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）以及 Web 服务描述语言（Web Services Description Language，WSDL）。 |
|
企业 UDDI |
Windows Server 2003 包括企业 UDDI 服务，后者是一个支持 XML Web 服务的动态和灵活的基础结构。这一特性使公司能够运行自己的支持 intranet 或 extranet 的内部 UDDI 服务。开发人员可以轻松和快速地发现和重复使用组织内部可用的 Web 服务，IT 管理员能够分类和管理在其网络中的可编程资源。使用 UDDI 服务，公司能够构建和部署更加智能、更加可靠的应用程序。 |
|
对现有服务的支持 |
XML Web 服务深入集成到 Windows Server 2003 之中；现有服务（如：COM+ 和消息队列）可以随时利用它们。管理员可以允许仅通过选中配置复选框，使用 XML/SOAP 来调用现有的 COM+ 应用程序。消息队列也可以使用 SOAP 和 XML 来允许松散连接的应用程序与广泛的系统进行互操作。 |
|
联合基础结构 |
XML Web 服务为应用程序集成提供了基础和体系结构。联合基础结构是促进服务器和服务跨越信任边界进行互操作的基础。 |
表 3：Windows Server 2003 的 Web 服务特性
以前的服务版本
所有 .NET 应用程序都可以使用“.NET Framework”的“并行执行”能力与为以前版本的 .NET Framework 编写的应用程序进行互操作。此外，.NET 应用程序还可以使用 .NET-COM 互操作能力与基于 COM 的应用程序进行互操作。有关该能力的详细信息在“服务蓝图”指南的“中间件服务”章节中提供。此外，新编写的 .NET 应用程序可以通过 Web 服务协议，与以前编写的基于 COM 的应用程序进行互操作。这些协议运用了 IIS 6.0 功能，以使 COM 组件能够作为 Web 服务使用。
浙公网安备 33010602011771号