使用 Internet 信息服务进行承载

　　在 IIS 上的 Web 服务开发长期以来一直是 ASP.NET 的领地。ASP.NET 1.0 发布后，Web 服务框架成为它的一部分。Microsoft 利用 ASP.NET HTTP 管道使 Web 服务在 Windows 平台上成为现实。遗憾的是，ASP.NET 和 Web 服务之间的这种紧密耦合在面向服务的世界中产生了几个限制，对 HTTP 的依赖性是主要原因。在不同宿主上运行 ASP.NET HTTP 管道很困难，因此很少采用这种方案。甚至在此后，ASP.NET Web 服务(也称为 ASMX 服务)在部署方案和配置依赖性方面一直是非常面向 Web 的。Microsoft 最初发布了几个版本的 Web 服务增强 (WSE)，以弥补 ASP.NET Web 服务的某些局限，尤其是消除在实现 WS-* 协议方面的限制。但是，WSE 非常依赖于 ASP.NET Web 服务实现。

　　在以前几章中介绍过，WCF 服务采用了完全不同的途径来实现面向服务。WCF 的统一编程模型基于严格分层的模型，以分解面向 Web 的范例，并使服务模型和通道层与受支持的传输方式断开连接。此模型允许 WCF 支持几个不同的宿主，其中 IIS 是最重要的。

　　构建 WCF 是为了支持 Windows XP、Windows Server 2003、Windows Vista 和 Windows Server 2007。自从 IIS 5.1(与 Windows XP 一起发布)以来，有了很多变化。但是，Microsoft 仍然继续支持旧版上的 WCF。这可能是因为 Microsoft .NET Framework 和 CLR 提供的功能所导致的，该功能是构建 WCF 的基础。在以下几节中，将介绍不同 IIS 版本的进程模型之间的差异和 WCF 服务的结果。

　　IIS 5.1 和 IIS 6.0 核心功能

　　为了能够解释这些差异，我们首先必须解释 IIS 的核心功能。IIS 长期以来一直支持在一个计算机上运行多个站点和多个应用程序。为了做到这一点，IIS 引入了公用地址模型，该模型分为三个主要区域：

　　•站点(注意：与 Windows XP 一起发布的 IIS 5.1 只支持一个站点。)

　　•应用程序

　　•虚拟目录

　　站点绑定到特定方案、网络地址和端口组合。IIS 不仅支持 HTTP，而且依据版本还支持 FTP、NNTP 和 SMTP。可以在相同站点下和在相同方案、网络和端口组合下运行多个应用程序。应用程序的典型 URI 是 http://localhost/MyApplication。虚拟目录只是映射到站点网络空间的文件夹，它可以是文件系统中的其他某处。这样，就可以使应用程序的实际内容或代码与作为相同站点组成部分的其他应用程序分隔开来。

　　在 IIS 6.0 中，Microsoft 对 IIS 进程模型做了一些重要更改。IIS 进程模型被拆分成可以由站点和应用程序共享的应用程序池，在这里，每个应用程序都运行在它自己的应用程序域中。“应用程序池”是称为 W3wp.exe 的单独 Windows 工作进程，并且只在它需要启动时才会启动。换句话说，IIS 带有应用程序激活模型，它允许 IIS 在它收到与应用程序池绑定的特定应用程序的请求时启动该应用程序池。这样，IIS 就能在一个服务器上承载数千个应用程序，而不必一直运行数千个进程。IIS 的激活体系结构在服务世界中是有趣的模型，本章的“Windows 激活服务”节将对此进行介绍。

　　图 5-9 显示在 HTTP 协议堆栈底部的 IIS 6.0 核心体系结构以及在其顶部的至少四个不同进程。

　　图 5-9. IIS 6.0 核心体系结构