Spring.net 学习笔记之ASP.NET底层架构(4)

ASP.NET2.0中的变化

ASP.NET2.0并没有对底层架构做很多改变.主要的新特性是HttpApplication对象有了一系列新的事件-大部分是预处理和后处理事件钩子-这使得应用程序事件管道变得更加的颗粒状了.ASP.NET2.0也支持新的ISAPI功能- HSE_REQ_EXEC_URL-这允许在ASP.NET处理的内部重定向到另外的URL上.这使得ASP.NET可以在IIS中设置一个通配符扩展,并处理所有的请求,其中一部分被HTTP处理器(handler)处理,另一部分被新的DefaultHttpHandler对象处理. DefaultHttpHandler会在内部调用ISAPI来定位到原始的URL上.这允许ASP.NET可以在其他的页面,如ASP,被调用前处理认证和登录等事情.

域的主人:HttpApplication

每个请求都被路由到一个HttpApplication对象上.HttpApplicationFactory类根据应用程序的负载为你的ASP.NET应用创建一个HttpApplication对象池并为每个请求分发HttpApplication对象的引用.对象池的大小受machine.config文件中ProcessModel键中的MaxWorkerThreads设置限制,默认是20个(译注:此处可能有误,根据Reflector反编译的代码,池的大小应该是100个,如果池大小小于100,HttpApplicationFactory会创建满100个,但是考虑到会有多个线程同时创建HttpApplication的情况,实际情况下有可能会超过100个).

对象池以一个更小的数字开始; 通常是一个然后增长到和同时发生的需要被处理的请求数量一样.对象池被监视,这样在大负载下它可能会增加到最大的实例数量,当负载降低时会变回一个更小的数字.

HttpApplication是你的Web程序的外部包装器,而且它被映射到在Global.asax里面定义的类上.它是进入HttpRuntime的第一个入口点.如果你查看Global.asax(或者对应的代码类)你会发现这个类直接继承自HttpApplication:

publicclass Global : System.Web.HttpApplication

HttpApplication的主要职责是作为Http管道的事件控制器,所以它的接口主要包含的是事件.事件挂接是非常广泛的,包括以下这些:

l BeginRequest 
l AuthenticateRequest 
l AuthorizeRequest 
l ResolveRequestCache 
l AquireRequestState 
l PreRequestHandlerExecute 
l …Handler Execution… 
l PostRequestHandlerExecute 
l ReleaseRequestState 
l UpdateRequestCache 
l EndRequest 

每个事件在Global.assx文件中以Application_前缀开头的空事件作为实现.例如, Application_BeginRequest(), Application_AuthorizeRequest()..这些处理器为了便于使用而提供因为它们是在程序中经常被使用的,这样你就不用显式的创建这些事件处理委托了.

理解每个ASP.NET虚拟目录在它自己的应用程序域中运行,而且在应用程序域中有多个从ASP.NET管理的池中返回的HttpApplication实例同时运行,是非常重要的.这是多个请求可以被同时处理而不互相妨碍的原因.

查看列表4来获得应用程序域,线程和HttpApplication之间的关系.

列表4-显示应用程序域,线程和HttpApplication实例之间的关系

privatevoid Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
this.ApplicationId = ((HowAspNetWorks.Global) 
HttpContext.Current.ApplicationInstance).ApplicationId ; 
this.ThreadId = AppDomain.GetCurrentThreadId(); 
this.DomainId = AppDomain.CurrentDomain.FriendlyName; 
this.ThreadInfo = "ThreadPool Thread: " + 
System.Threading.Thread.CurrentThread.IsThreadPoolThread.ToString() +
"
Thread Apartment: " + 
System.Threading.Thread.CurrentThread.ApartmentState.ToString(); 
// *** Simulate a slow request so we can see multiple
// requests side by side.
System.Threading.Thread.Sleep(3000); 

}

这是随sample提供的demo的一部分,运行的结果在图5中显示.运行两个浏览器,打开这个演示页面可以看到不同的ID.

你可以通过同时运行多个浏览器来简单的查看应用程序域,应用程序池实例和请求线程是如何交互的.当多个请求同时发起,你可以看到线程ID和应用程序ID变化了,但是应用程序域还是同一个.

你可能注意到在大多数请求上,当线程和HttpApplication ID变化时应用程序域ID却保持不变,虽然它们也可能重复(指线程和HttpApplication ID).HttpApplication是从一个集合中取出,在随后到来的请求中可以被复用的,所以它的ID有时是会重复的.注意Application实例并不和特定的线程绑定-确切的说它们是被指定给当前请求的活动线程.

线程是由.NET的线程池管理的,默认是多线程套间(MTA)线程.你可以在ASP.NET的页面上通过指定@Page指令的属性ASPCOMPAT=”true”来覆盖套间属性.ASPCOMPAT意味着为COM组件提供一个安全的执行环境,指定了这个属性,就会为这些请求使用特殊的单线程套间(STA).STA线程被存放在单独的线程池中,因为它们需要特殊的处理.

这些HttpApplication对象全部在同一个应用程序域中运行的事实是非常重要的.这是为什么ASP.NET可以保证对web.config文件或者单独的ASP.NET页面的修改可以在整个应用程序域中生效.改变web.config中的一个值导致应用程序域被关闭并重启.这可以保证所有的HttpApplication可以”看到”这个修改,因为当应用程序域重载入的时候,所做的修改(译注:即被修改的文件)会在启动的时候被重新读入.所有的静态引用也会被重载,所以如果程序通过App Configuration settings读取值,这些值也会被刷新.

为了在sample中看到这点,点击ApplicationPoolsAndThreads.aspx页面并记下应用程序域ID.然后打开并修改web.config(加入一个空格并保存).然后重新载入页面.你会发现一个新的应用程序域已经被创建了.

本质上当上面的情况发生时,Web应用/虚拟目录是完整的”重启”了.所有已经在管道中被处理得请求会继续在现存的管道中被处理,当任何一个新的请求来到时,它会被路由到新的应用程序域中.为了处理”被挂起的请求”,ASP.NET在请求已超时而它(指请求)还在等待时强制关闭应用程序域.所有事实上是可能出现一个应用程序对应两个应用程序域,此时旧的那个正在关闭而新的正在启动.两个应用程序域都继续为它们的客户服务,直到老的那个处理玩正在等待处理的请求并关闭,此时只有一个应用程序域在运行.

“流过”ASP.NET管道

HttpApplication触发事件来通知你的程序有事发生,以此来负责请求流转.这作为HttpApplication.Init()函数的一部分发生(用Reflector查看System.Web.HttpApplication.InitInternal()方法和HttpApplication.ResumeSteps()方法来了解更多详情),连续设置并启动一系列事件,包括执行所有的处理器(handler).这些事件处理器映射到global.asax中自动生成的哪些事件中,同时它们也映射到所有附加的HttpModule(它们本质上是HttpApplication对外发布的额外的事件接收器(sink)).

HttpModule和HttpHandler两者都是根据Web.config中对应的配置被动态载入并附加到事件处理链中.HttpModule实际上是事件处理器,附加到特殊的HttpApplication事件上,然而HttpHandler是用来处理”应用级请求处理”的终点.

HttpModule和HttpHandler两者都是在HttpApplication.Init()函数调用的一部分中被载入并附加到调用链上.图6显示了不同的事件,它们是何时发生的以及它们影响管道的哪一部分.

事件在ASP.NET http管道中流转的过程.HttpApplication对象的事件驱动请求在管道中流转.Http Module可以拦截这些事件并覆盖或者扩展现有的功能.

HttpContext, HttpModules 和 HttpHandlers

httpApplication它本身对发送给应用程序的数据一无所知-它只是一个通过事件来通讯的消息对象.它触发事件并通过HttpContext对象来向被调用函数传递消息.实际的当前请求的状态数据由前面提到的HttpContext对象维护.它提供了所有请求专有的数据并从进入管道开始到结束一直跟随请求.图7显示了ASP.NET管道中的流程.注意上下文对象(即HttpContext),这个从请求开始到结束一直都是你”朋友”的对象,可以在一个事件处理函数中保存信息并在以后的事件处理函数中取出.

一旦管道被启动,HttpApplication开始象图六那样一个个的触发事件.每个事件处理器被触发,如果事件被挂接,这些处理器将执行它们自己的任务.这个处理的主要任务是最终调用挂接到此特定请求的HttpHandler.处理器(handler)是ASP.NET请求的核心处理机制,通常也是所有应用程序级别的代码被执行的地方.记住ASP.NET页面和Web服务框架都是作为HttpHandler实现,这里也是处理请求的的核心之处.模块(module)趋向于成为一个传递给处理器(handler)的上下文的预处理或后处理器.ASP.NET中典型的默认处理器包括预处理的认证,缓存以及后处理中各种不同的编码机制.

有很多关于HttpHandler和HttpModule的可用信息,所以为了保持这篇文章在一个合理的长度,我将提供一个关于处理器的概要介绍.