上文说到一个WEB请求被HTTP.SYS转发到了WEB应用程序池。顾名思义，WEB应用程序池就是一个WEB应用程序的容器。那么这个WEB请求在WEB应用程序池中又有着怎样的经历呢，这不得不引出另外两个IIS6.0的核心组件：工作进程(WORKER PROGESS)和WEB管理器（WEB ADMIN SERVICE），这也就是本文重点所讲述的。
在表述这两个组件之前，先来看一下它们的图示：
我先来说说WWW Service，也就是WAS。WAS是一个管理和监视工作进程的组件，它宿主在SveHost.exe中，运行在用户模式下。WAS负责同MetaBase进行交互以获取其配置数据信息，这些配置信息会通过WAS注册到HTTP.SYS中。同时WAS还负责监视管理工作进程。一旦工作进程出现故障，WAS会为其创建新的工作进程以响应Web请求。
当运行IIS的InetInfo.exe服务启动后，WAS服务(SvcHost.exe)也随之启动。此时WAS从InetInfo的MeteBase中读取配置信息并且初始化HTTP.SYS中的Namespace路由表(Namespace mapper)，HTTP.SYS通过路由表中的数据条目来判定Web请求的URL所对应的应用程序池。此时，HTTP.SYS就会向WEB应用程序池发出启动工作进程的指令。当我们添加或删除一个应用程序池时，WAS会处理相应的变更信息，包括从HTTP.SYS中添加或删除该应用程序池的消息队列。WAS也会监听和处理来自应用程序池回收的配置变更信息。
WAS还负责管理管理工作进程，包括启动工作进程和维护正在运行的工作进程。并判定何时启动工作进程，何时回收工作进程以及何时重新启动处于阻塞状态或不能处理更多WEB请求的工作进程。在工作进程隔离模式下，WAS负责健康管理和维护，包括应用程序池的健康监视，工作进程的回收以及对工作进程异常的迅速保护。
以上是对WAS的简述，接下来我着重说说工作进程（Worker Progress），在讲工作进程之前，我来大致说说WAS、WEB应用程序池、工作进程以及WEB应用程序它们之间的关系。如果把WEB应用程序池比作一个小区的话，那么工作进程（W3WP.exe）就相当于管理这个小区的物业，而web应用程序相当于这个小区的住户，WAS(SvcHost.exe)就相当于管理这个小区旁边的派出所。下面我把工作进程（W3WP.EXE）图放大，如下图：
工作进程(W3WP.EXE)是一个用户模式下负责处理WEB请求的程序，比如处理返回静态页的请求，调用ISAPI扩展或ISAPI筛选器，运行CGI(Common Gateway Interface)。工作进程接收来自HTTP.SYS的WEB请求和向HTTP.SYS发送该请求的WEB响应。同时也会运行WEB应用程序代码，比如Asp.net Application和XML Web Service。工作进程主要通过程序集W3Core.DLL来实现所有WEB请求的处理逻辑。
一个应用程序池中可包含多个工作进程，工作进程间是相互隔离的，直接和内核模式下的HTTP.SYS进行交互，互不影响。也就是说一个工作进程出现故障并不会影响其它的工作进程的正常运行。
从上图我们看到工作进程包括如下两个程序)：ISAPI扩展和ISAPI过滤器。ISAPI的全称是Internet Service Application Interface。通过ISAPI可以访问IIS提供的所有功能，比如通过它调用ASP.DLL对动态网页(aspx,ascx,asmx等)进行处理。而ISAPI过滤器可以修改和过滤来自客户端的WEB请求等，为什么要修改它的URL或HEADERS呢，这就涉及到CookieLess，即无Cookie验证，自己想想？！具体功能如下：
修改来自客户端的请求(URL或Headers)，
控制物理文件到URL的映射
验证完成后修改或分析请求
修改客户端返回的响应
对“访问被拒绝”的响应运行自定义处理
当请求结束后执行相应的处理
同客户端的连接关闭后执行相应处理
记录日志和跟踪分析
执行自定义的身份验证
加密压缩等功能。
可见一个WEB请求要想顺利到达WEB应用程序是多么地不容易。好了，说了这么多自己脑袋都懵了，还是捋一下WEB请求的思路吧。一个WEB请求经HTTP.SYS转发到WEB应用程序池对应的工作进程，如果该进程没启动则通过WAS来启动，没有找到相应的工作进程则创建，注意启动工作进程时会加载相应的Asp.net ISAPI动态库，然后加载CLR。这个请求通过ISAPI过滤器和ISAPI扩展的种种考验，最终就会来的WEB应用程序的面前。我还是用图例来描述一下这个WEB请求现在走到哪里了吧，此时还WEB请求的旅程并没有走完，我会通过本系列下一篇进行介绍。欢迎拍砖交流。
