Microsoft.Web.Administration API 是访问自定义 .NET 服务器模块内部的自定义配置和 IIS 管理器工具的 UI 插件的基础。有关端到端服务器包的示例,包括用于增强 Web 服务器和相关配置及管理组件的图像版权处理程序,请参阅 iis.net/default.aspx?tabid=2&subtabid=25&i=1076。
在 Windows Server“Longhorn”时间范围内,IIS 团队将为添加自定义管理对象或扩展现有管理对象而创建统一的可扩展模型,这些模型将使自定义管理功能通过不同管理功能(包括脚本和 Microsoft.Web.Administration API)自动公开。当您无法添加或扩展 Windows Vista 中的管理对象时,可以使用 Microsoft.Web.Administration 和其他 API,就像现有 IIS 配置部分一样,访问和管理自定义配置部分。
构建 Web 服务器功能
IIS 7.0 使您能够根据您的需要塑造服务器,允许您添加或替换服务器中的任何功能,以便提供您需要的功能。此功能的核心是全新的 Web 服务器可扩展 API,所有现有 IIS 7.0 HTTP 功能都建立在它之上。此 API 是公用的,这意味着您可以实现 IIS 7.0 附带的任何功能。这对 IIS 是第一次,并且是对以前的有限 ISAPI 可扩展模型的根本改进。
新的可扩展 API 是一组直观的 C++ 类,这些类定义了 Web 服务器对象模型,并使一个模块能够在 IIS 上提供请求处理服务。这些类被定义在 Windows Vista SDK 中的 \inc\httpserv.h 头文件中。
开发人员还将受益于经过改进的内存和状态管理模式。大多数 IIS 7.0 服务器 API 都使用服务器托管内存来存储它们返回的数据,而不是像 ISAPI 和大多数现有 Win32® API 那样需要您分配和管理缓冲区。过去,这一直是 ISAPI 开发中最容易产生错误也是最令人厌烦的方面。新的 API 还简化了很多复杂的请求处理任务,例如,响应缓冲、身份验证和为客户端准备响应数据。几个月以前,我开始发表我的一系列博客文章,以解释新编程模型中的重大改进和模式。如果您正在考虑针对 IIS 的 C++ 开发,可通过访问以下网址参考相关内容:mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx。
IIS 7.0 还为扩展服务器提供了完全集成的 .NET Framework API。此外,这与自从 Windows 2000 上的 ASP.NET 1.0 发布以来 ASP.NET 提供的用于构建 ASP.NET 模块和处理程序的 API 是相同的。但两者有区别,人们熟悉的 ASP.NET 模型允许现有 ASP.NET 模块和处理程序继续工作在 IIS 7.0 服务器上,但实际上它已完全不同于以前的旧技术。
在 IIS 7.0 中,ASP.NET 有两个版本:经典模式和集成模式。经典模式的工作方式与它在以前版本的 IIS 中完全相同。集成模式是新的平台默认设置,它使用全新的引擎来提供与 IIS Web 服务器前所未有的集成。在集成模式下,可以用 ASP.NET API 开发 IIS 7.0 模块,这样的模块可以直接与 Web 服务器集成,并且能够提供用基本 C++ API 即可实现的几乎所有服务。
这基本上是两个方面的最佳结合:像成员身份和角色管理这样的 .NET Framework 和 ASP.NET 2.0 应用程序服务所具有的熟悉的接口和方便性,以及以前只对基于 C 的 ISAPI 组件可用的扩展服务器的原始能力。
除了能够编写新的 ASP.NET 模块(建立在集成模式的特定优势之上)之外,只需通过在 web.config 文件中更改少量配置选项,就可以使很多原有 ASP.NET 模块变得更为强大。
ASP.NET 集成
使用 IIS 7.0,ASP.NET 2.0 不止是建立动态应用程序的优秀框架。它还成为扩展 IIS Web 服务器的平台,这使得 ASP.NET 组件成为 IIS 请求处理管道的完整成员。下面介绍它的工作原理。
在直到 6.0 版的 IIS 版本中,ASP.NET 均作为独立的应用程序框架连接到 Web 服务器。它负责处理向它注册的请求扩展(通常是 .aspx 和少量其他扩展名),并且它还为这些请求提供强大的功能,如窗体身份验证、响应输出缓存以及其他功能,包括由自定义 ASP.NET 模块提供的服务。因此,只有向 ASP.NET 注册的内容类型才能受益于这些服务。包括 ASP 页、PHP 页、图像和 CGI 应用程序在内的其他类型则无法受益。此外,由于运行库限制,即使对于 ASP.NET 资源,也无法在 ASP.NET 中实现某些 Web 服务器功能。例如,它不能检查传出 HTTP 响应标头集并在发送到客户端之前修改它们。
当 ASP.NET 模块在 IIS 7.0 中以集成模式运行时,将与本机 C++ IIS 模块并排运行在统一请求处理管道中(参见图 5)。这意味着现有 ASP.NET 服务(如输出缓存、URL 重写和由自定义 ASP.NET 模块提供的任何其他服务)现在可以应用于任何内容类型。更好的运行库集成还使 ASP.NET 模块能够访问以前不可用的服务器功能,这样,在大多数情况下,不再需要编写本机 IIS 可扩展功能。
通常,现有应用程序可以利用集成模式,而不需要使用特定于集成模式的功能的新 ASP.NET 模块。只需通过更改配置,应用程序就可以执行诸如以下操作:使用 ASP.NET 窗体身份验证和 URL 授权通过用户安全机制保护整个网站,或使用 ASP.NET URL 映射在应用程序中重写 URL 等。如需查看利用集成模式阻止 Web Leech 热链接到站点图像的示例,请参阅实现这一点的示例 ASP.NET 模块:mvolo.com/2006/11/10/stopping-hotlinking-with-iis-and-aspnet.aspx。该示例很好地说明了如何通过在集成模式中使用现有第三方 ASP.NET 模块来更好地利用它们。
除了核心安全性改进以外,IIS 7.0 还提供了大量安全功能,通过使用它们,可以进一步在服务器上锁定和部署安全应用程序。IIS 一直在为通过身份验证保护应用程序内容提供强大支持。现在,利用 ASP.NET 集成模式,您可以使用流行的 ASP.NET 安全功能(例如,窗体身份验证、成员身份和登录控制)来为整个应用程序提供完整的身份验证和访问控制解决方案。通常,可以在几分钟内完成此设置,而不必编写任何代码。
新的 URL 授权功能从 ASP.NET URL 授权功能发展而来,可以用于为整个应用程序配置声明性访问控制规则。利用这些访问规则可以根据用户名和角色允许或拒绝对应用程序中对 URL 的访问。URL 授权与 ASP.NET 2.0 成员身份和角色管理功能无缝集成在一起,可以有效地与 ASP.NET 窗体身份验证和登录控制一起使用,以快速启用应用程序的用户安全机制。
在 Windows、IIS 7.0 和 Web 应用程序所支持的所有新功能中,Web 服务器是通常需要投入大量精力进行故障排除的非常复杂的系统。IIS 7.0 引入了大量新功能,可帮助您监视服务器的运行情况并调试应用程序的问题。
首先,IIS 7.0 允许您深入查看服务器的实时状态。此功能称为运行库状态和控制 API,或 RSCA(读作“reeska”),它可以公开站点和应用程序池的活动状态、运行中的工作进程,甚至允许您查看当前正在服务器上执行的请求。它还使您能够控制服务器的状态,例如,启动和停止站点,或回收应用程序池。在 Windows Vista 中,可以在 IIS 管理器中、通过 appcmd.exe 命令行工具或使用 Microsoft.Web.Administration API 以编程方式访问此信息。
详细的错误遵从类似于 ASP.NET 详细错误的安全方案。默认情况下,您只有在从本地计算机浏览网站时才能获得详细信息。像以前一样,还可以为不同的错误代码配置自定义错误页,或重定向到自定义 URL。详细的错误页现在也已本地化,如果安装了相应语言的语言包,就可以按客户端的首选语言提供错误描述。
诊断错误而无需调试
如果您遇到的错误情况是未知的,或者是由多个 Web 服务器组件的复杂叠加而导致的,则会怎么样?不用担心,IIS 7.0 提供了全面的跟踪机制,它可以为每个请求生成详细的书面跟踪记录,以便能够快速跟踪问题。
Windows Server 2003 Service Pack 1 (SP1) 中向 IIS 6.0 中添加了 Windows 事件跟踪 (ETW) 事件,在此事件的基础上,IIS 7.0 添加了更多信息性事件。这些事件包含有关服务器处理的每个阶段的有用信息,通过检查这些信息可以反向跟踪请求执行过程,查明出错位置。可以将这些事件路由到 Windows 跟踪基础结构,后者允许多个 Windows 组件(包括 ASP.NET 和 SQL Server™)将其跟踪信息链接到该请求的单个逻辑执行跟踪。
还可以将它们路由到新的失败请求跟踪功能(又称为 FREB),后者会将跟踪日志保存到 XML 日志文件中,然后可以用提供的 XSLT 样式表查看这些文件(参见图 8),或以编程方式使用它们。
基本跟踪基础结构通过服务器可扩展模型向 IIS 模块公开,从而允许所有服务器组件(无论它们是 IIS 附带的,还是第三方开发的)在请求处理期间发出详细跟踪信息。通过 System.Diagnostics API 和 ASP.NET 页跟踪,IIS 7.0 跟踪功能与 ASP.NET 跟踪功能集成在一起,从而允许托管模块利用统一跟踪模型。若要更进一步,可以编写自己的跟踪模块,为处理和输出跟踪信息提供新的方式。例如,您可以成为编写模块以便将 IIS 跟踪信息保存到 SQL Server 或文本文件中的第一个人。
经过改进的性能
虽然 Windows Vista 是客户端操作系统,并不针对高吞吐量的生产部署(Windows Vista 上的 IIS 受限于每次 10 个并发请求),但它的确体现了一些旨在大幅提高 Web 应用程序性能的重要体系结构改进。通过与我们正在 Windows Server“Longhorn”时间范围内所进行的广泛的性能改进工作相结合,这些改进将帮助 IIS 7.0 提高服务器性能。
当然,第一项改进是组件化。服务器的模块化性质允许管理员删除不需要的服务器功能,从而在请求处理期间节省内存和 CPU 使用量。这会导致计算机的吞吐量和容量得到重大改进。在只有站点的某些部分需要特定功能的情况下,以粒度方式启用功能的能力(针对服务器上的每个应用程序打开和关闭相应功能)将进一步提高应用程序的性能。
在 IIS 7.0 中,另一个值得注意的性能特性是新的 IIS 输出缓存。此特性为在服务器上重复利用对高成本动态页面的响应提供了支持,从而缓解了对执行高成本的显示处理和数据库事务以便将响应返回客户端的需要。IIS 输出缓存是对 ASP.NET 中现有的丰富输出缓存功能的速度更快的替代方案,它可以支持一组更小的缓存功能,但能以增强性能的方式为缓存动态内容提供足够的灵活性。
通过将动态内容进行输出缓存,无论它是 ASP.NET 页、PHP 脚本还是 CGI 应用程序,您都可以获得 5-10 倍的性能提升,同时大大降低对磁盘和数据库的负载。
向后兼容
IIS 7.0 应当能够运行大多数现有应用程序,而不需要修改。考虑到在此版本中支持创新所需要的体系结构的更改范围,这是一项巨大成功。配置系统已经过最大更改,从集中的松散类型化配置存储转变为委派的 XML 配置文件层次结构。配置信息的结构和存储都完全不同于 IIS 6.0 元数据库,并且不支持通过原有配置 API 进行访问。
与集成模式存在运行库不兼容情况的少数 ASP.NET 应用程序可能必须移动到运行于经典模式的应用程序池中。在这种情况下,通过将多个应用程序放在单独的应用程序池中,可以在相同服务器上以两种模式并排运行这些应用程序。如需 IIS 7.0 上的 ASP.NET 重大更改和常规 ASP.NET 兼容性信息的完整列表,请参阅 ASP.NET 兼容性白皮书:iis.net/default.aspx?tabid=2&subtabid=25&i=1223。
总结
在 Windows Vista 中发布的 IIS 7.0 旨在为下一代 Web 应用程序平台提供最佳体系结构基础,其重点是用于 Web 服务器的正确核心体系结构、可扩展性和管理平台。Windows Vista 使您能够在 Windows Vista 服务器版本发布时用于部署应用程序的相同服务器平台上开发和测试这些应用程序。
由于 IIS 7.0 是在 Windows Vista 中发布的,因此 Web 平台和工具团队的工作重点转移到使 Web 服务器为生产环境做好准备以及为生产方案提高稳定和性能这些方面。但是,Windows Vista 中附带的核心开发和管理功能将保持不变,而且,当 IIS 7.0 的服务器版本完成时,预计将通过 Service Pack 将其改进提供给 Windows Vista。那时,您的客户端和服务器计算机将再次运行完全相同的 IIS 版本,这样,您就可以继续在运行 Windows Vista 的桌面机上开发和测试 Web 应用程序了。