【原文地址】IIS 7.0
【原文发表日期】 Monday, April 02, 2007 11:10 PM
IIS 7.0是我的团队今年稍后将推出的最让我激动不已的产品之一。它是自IIS 1.0之后我们所做过的最重大的web服务器发布,它将为管理人员和开发人员引入不计其数的改进。
IIS开发团队的Mike Volodarsky为MSDN杂志的2007年3月期撰写了一篇精彩的文章 (英文版),总结了IIS 7.0的一些主要改进。我强烈建议你去这里 (英文版)阅读一下他的精彩文章,以对这些改进有个简短了解。
IIS 7.0是包括在Windows Vista客户机上的,该操作系统的家庭版本也带有IIS 7.0(而不象IIS 5.1,只有在XP Professional上才有)。服务器的IIS 7.0版本将在今年稍后随Windows Longhorn服务器发布,将添加一堆额外的部署特性,包括更加丰富的主机支持,安全的FTP支持,以及内置的web farm部署支持等。
Web farm支持将是特别地酷,它将允许你在一个包含了运行一个服务器所需的所有编码,配置,内容和密钥的文件共享上部署你的web应用。然后你可以添加任意数目的无状态,无配置的web服务器到一个web farm上,只需将它们指向那个文件共享,来动态装载它们的配置设置(包括绑定,虚拟目录,应用池设置等等)和应用内容即可。这使得在多个机器上扩缩一个应用简直是小菜一碟,可避免使用复制方法来做配置和应用部署(只要把文件拷贝到文件共享上,web farm里的所有机器就会马上装载变动过的文件)。
即将推出Windows Longhorn服务器的Beta3版本将会支持go-live许可,所以你不久就能利用这个功能。我们已经在用IIS 7.0集群运行 www.Microsoft.com 了,所以你不会寂寞的!(【译注:在本文的中文版发表之前,Windows Longhorn服务器的Beta3版本已经发布】)
在早期的IIS版本中,开发人员需要编写ISAPI扩展/过滤器来扩展服务器的功能。除了写起来非常痛苦外,ISAPI在如何接入服务器以及允许开发人员定制方面也是非常有限。譬如,你无法在ISAPI扩展中实现URL重写代码(注:ASP.NET是以ISAPI扩展的方式实现的)。假如你把运行时间长的代码编写成ISAPI过滤器的话,结果是你将占用web服务器的I/O线程(这就是我们不让托管代码在请求的过滤器执行阶段运行的原因)。
我们在IIS7中对核心IIS处理引擎做的一个重大的架构级变动是通过一个新的模块化的请求管道架构来促成极其丰富的扩展性。你现在可以通过与web服务器注册一个HTTP扩展性模块(HTTP Extensibility Module),在任意一个HTTP请求的生命周期的任何地方编写代码。这些扩展性模块可以使用native的C++代码或.NET托管代码来编写(你可以使用现有的ASP.NET System.Web.IHttpModule接口来实现)。
所有“内置”的IIS7功能(认证,授权,静态文件供应,目录清单支持,经典的ASP,记录日志等),现在都是使用这个公开的模块化的管道API来实现的。这意味着你可以除去这些IIS7“内置”功能的任意一个,而以你自己的实现来替换/扩展这些功能。
IIS 7.0上的ASP.NET本身也从以ISAPI的实现形式变成直接接入IIS7管道的模块:
这带来诸多好处:
1) 你现在可以对服务器的所有请求(譬如, .htm,.php,.jsp文件)使用ASP.NET表单认证,成员/角色,以及任何其他特性。
2) 你现在可以轻松地重写任何web请求的URL或者以种种有趣的方式对请求做改动。
3) 你可以使用VB或C#替换或扩展任何现有的IIS特性(譬如,你可以除去内置的目录清单模块,接入你自己的模块)。
这确实给.NET开发人员带来了无穷多的扩展性机会。
为帮助开发人员共享他们编写的扩展性模块和其他add-in,IIS开发团队最近在www.iis.net上发起了一个 “下载中心”,这允许开发人员浏览/下载以及上传和共享IIS的模块扩展。你可以在这里查看一下。
注意,除了让你编写托管的HTTP模块的扩展性功能外,IIS7现在也允许你编写托管的管理工具的UI扩展(管理工具本身是使用 Windows Forms编写的),以及使用.NET的System.Configuration 命名空间来管理IIS7配置系统。
除了IIS 7.0提供的既酷又新的扩展性选项外,还有ASP.NET开发人员将会非常欣赏的成堆的大大小小的改进。我将在接下来的几个星期/月份里在博客里讨论一系列的改进,指出你能利用的一些非常酷的东西。
我也强烈建议你订阅IIS 7开发团队在这里的博客feed。
希望本文对你有所帮助,