IIS6在Windows 2003和Windows XP SP2中存在，应用程序池作为一个运行时容器来寄宿应用程序。这允许对启动和关闭的控制，在每一个进程的基础上进行身份认证和回收服务。它原本就提供了跨应用程序的进程隔离功能，这个功能带来了很大的可信赖性。总的来说进程管理是由应用程序池架构处理的。
IIS7在Windows Vista和Windows Server 2008 中存在，进程管理已经实现对多种协议支持并移植到WAS中。ASP.NET也扩展来支持进程激活和WAS中的服务寄宿。
图片7.4 描述了在WAS架构上的IIS7.
在IIS7中寄宿一个服务的三个最小的步骤在第一章描述了。简短的说，你必须创建一个IIS虚拟应用，创建一个SVC文件来定义服务实现，在web.config中添加<system.serviceModel>部分。
为了在IIS中寄宿一个WCF服务，你首先需要定义一个虚拟应用。一个IIS中的虚拟应用由一个站点，一个协议监听器和进程激活组成。站点是一个存储文件的虚拟目录。监听器进程是IIS的w3svc并为网络I/O分发http.sys。进程激活为代码维护运行时环境并在IIS中定义为一个AppPool.
图片7.4 在WAS中实现IIS
在虚拟应用定义好了以后，你必须在虚拟目录中放置一个SVC文件和一个web.config文件。SVC文件包含了对服务实现的引用而web.config定义了终结点的地址，绑定和契约以及服务的行为。
SVC文件将会在三个地方查找服务实现: 首先是SVC文件本身，然后是虚拟目录的/bin文件夹，最后在机器的GAC中。SVC文件类似IIS6中的ASMX文件。
web.config文件定义了服务和终结点，WCF的ABCs,一个地址，一个绑定和一个契约。因为服务由IIS寄宿，而IIS只知道HTTP协议(相对于TCP或者MSMQ)，web.config文件的终结点必须使用一个绑定将HTTP确定为传输协议。三个内建的标准绑定，basicHttpBinding,wsHttpBinding和wsDualHttpBinding,使用这个传输协议，所以这些可以由IIS寄宿的服务的终结点使用。如果你定义了一个使用一个基于不同传输协议的终结点，比如TCP或者MSMQ(netTcpBinding)当服务收下你激活时会抛出一个运行时异常。地址应该是一个相对地址因为服务的基地址由协议绑定和SVC文件的虚拟目录定义了。
让我们考虑一下当一个虚拟应用创建后会发生什么，当第一个HTTP请求抵达应用以后，顺序请求是如何处理的。
当你使用IIS管理器创建一个虚拟应用，虚拟应用的关联URL由IIS(w3svc)注册。在那个点，所有由HTTP协议监听适配器接收的请求都被发送去处理。HTTP协议监听适配器是HTTP.SYS， 这是一个系统驱动。监听适配器架构在本章节的"在Windows 进程激活管理服务中寄宿一个服务"部分描述。
当对一个特殊SVC文件的第一个请求从协议监听器到达时，IIS调用WAS来启动工作进程w3wp.exe,如果它还没有启动的话。工作进程被那个虚拟应用的AppPool委派。ASP.NET 应用程序管理器在工作进程中负责接收IIS/WAS发来的请求并载入WCF寄宿模块和处理模块。WCF寄宿层在web.config中的<servicemodel>部分寻找并使用一个ServiceHostFactory来为那个类创建一个<Service>元素指示的ServiceHost。然后添加web.config中<service>部分定义的ServiceHost到终结点。最后，它调用ServiceHost.Open以便于服务客气启动监听进入的请求。当服务启动时，它使用协议监听器来注册终结点地址以便于顺序请求直接从协议监听器发送到服务本身。