ASP.NET底层架构探索之再谈.NET运行时(二)

在这里我们有一个在ISAPI扩展中活动的,可调用的ISAPIRuntime对象的实例。每次运行时是启动的并运行着的时候(译注:相对的,如果运行时并没有启动,就需要象上一章所说的那样载入运行时),ISAPI的代码调用ISAPIRuntime.ProcessRequest()方法,这个方法是真正的进入ASP.NET管道的入口,这个流程在图4中显示。

  记住ISAPI是多线程的,所以请求也会通过AppDomainFactory.Create()(译注:原文为ApplicationDomainFactory,疑有误)函数中返回的引用在多线程环境中被处理.列表1显示了ISAPIRuntime.ProcessRequest()方法中反编译后的代码,这个方法接收一个ISAPI ecb对象和服务类型(WorkerRequestType)作为参数.这个方法是线程安全的, 所以多个ISAPI线程可以同时在这一个被返回的对象实例上安全的调用这个方法。

  列表1:ProcessRequest方法接收一个ISAPI Ecb并将其传给工作线程

public int ProcessRequest(IntPtr ecb, int iWRType)
{
 HttpWorkerRequest request1 = ISAPIWorkerRequest.CreateWorkerRequest(ecb,  iWRType);
 string text1 = request1.GetAppPathTranslated();
 string text2 = HttpRuntime.AppDomainAppPathInternal;
 if (((text2 == null) || text1.Equals(".")) ||
  (string.Compare(text1, text2, true, CultureInfo.InvariantCulture) == 0))
 {
  HttpRuntime.ProcessRequest(request1);
  return 0;
 }
 HttpRuntime.ShutdownAppDomain("Physical application path changed from " +text2 + " to " + text1);
 return 1;
}

  这里实际的代码并不重要, 记住这是从内部框架代码中反编译出来的, 你不能直接处理它, 它也有可能在将来发生改变.它只是用来揭示在幕后发生了什么.ProcessRequest方法接收非托管的ECB引用并将它传送给ISAPIWorkerRequest对象, 此对象负责为当前请求创建创建请求上下文.在列表2中显示了这个过程.

  System.Web.Hosting.ISAPIWorkerRequest类是HttpWorkerRequest类的一个抽象子类(译注:HttpWorkerRequest和ISAPIWorkerRequest都是抽象类, 并且ISAPIWorkerRequest继承自HttpWorkerRequest),它的工作是构建一个作为Web应用输入的输入输出的抽象视角。注意这里有另一个工厂方法:CreateWorkerRequest, 通过判断接受到的第二个参数来创建对应的WorkerRequest对象.有三个不同的版本:ISAPIWorkerRequestInProc,ISAPIWorkerRequestInProcForIIS6, ISAPIWorkerRequestOutOfProc.每次有请求进入,这个对象被创建并作为请求和响应对象的基础,它会接收它们的数据和由WorkerRequest提供的数据流.

  抽象的HttpWorkerRequest类在低层接口上提供一个高层的抽象,这样就封装了数据是从哪里来的,可以是一个CGI Web服务器,Web浏览器控件或者是一些你用来给HTTP运行时”喂”数据的自定义的机制.关键是ASP.NET能用统一的方法来接收信息。

  在使用IIS的情况下, 这个抽象是建立在ISAPI ECB块周围.在我们的请求处理过程中, ISAPIWorkerRequest挂起ISAPI ECB并根据需要从它那里取出信息.列表2显示了请求字符串值(query string value)是如何被取出来的.

  列表2:使用非托管数据的ISAPIWorkerRequest方法

// *** Implemented in ISAPIWorkerRequest

public override byte[] GetQueryStringRawBytes()
{
 byte[] buffer1 = new byte[this._queryStringLength];
 if (this._queryStringLength > 0)
 {
  int num1 = this.GetQueryStringRawBytesCore(buffer1, this._queryStringLength);
  if (num1 != 1)
  {
   throw new HttpException( "Cannot_get_query_string_bytes");
  }
 }
 return buffer1;
}
// *** Implemented in a specific implementation class ISAPIWorkerRequestInProcIIS6

internal override int GetQueryStringCore(int encode,StringBuilder buffer, int size)
{
 if (this._ecb == IntPtr.Zero)
 {
  return 0;
 }
 return UnsafeNativeMethods.EcbGetQueryString(this._ecb,encode,buffer,size);
}

 

  ISAPIWorkerRequest实现了一个高层次的包装方法, 它调用了低层的核心方法, 负责真正的访问非托管APIs-或称为”服务级别的实现”(service level implementation).这些核心方法在特殊的ISAPIWorkerRequest子类中为它寄宿的环境提供特殊的实现, 这实现了简单的扩展的(pluggable)环境, 这样一来当以后新的Web服务器接口或其他平台成为了ASP.NET的目标时附加的实现类可以在被简单的提供出来。这里还有一个协助类(helper class)System.Web.UnsafeNativeMethods.里面许多对ISAPI ECB结构的操作实现了对ISAPI扩展的非托管操作。

时间: 2024-09-12 16:07:59

ASP.NET底层架构探索之再谈.NET运行时(二)的相关文章

ASP.NET底层架构探索之再谈.NET运行时(一)

本文将重点讲解如何为特定的硬件设备自定义ASP.NET Web移动程序,以及使用模板自定义Form和Panel等控件.通过属性重写这个特性,使ASP.NET Web移动程序可以根据移动设备的硬件功能,为特定的硬件指定其控件的属性值.例如,应用程序可能需要一个Label控件在一些设备上显示较长的文本,而在另一些设备上显示较简短的文本.这就需要我们为每个控件都提供一组属性,应用程序可以针对各个设备重写这些属性.所有的ASP.NET移动控件都具有默认的外观和布局.对于ASP.NET移动控件,你可通过设

ASP.NET底层架构探索之再谈.NET运行时

在这里我们有一个在ISAPI扩展中活动的,可调用的ISAPIRuntime对象的实例.每次运行时是启动的并运行着的时候(译注:相对的,如果运行时并没有启动,就需要象上一章所说的那样载入运行时),ISAPI的代码调用ISAPIRuntime.ProcessRequest()方法,这个方法是真正的进入ASP.NET管道的入口,这个流程在图4中显示. 记住ISAPI是多线程的,所以请求也会通过AppDomainFactory.Create()(译注:原文为ApplicationDomainFactor

ASP.NET底层架构探索之进入ASP.NET

asp.net|架构 ASP.NET是一个非常强大的构建Web应用的平台,它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用.绝大多数的人只熟悉高层的框架如WebForms和WebServices-这些都在ASP.NET层次结构在最高层.在这篇文章中我将会讨论ASP.NET的底层机制并解释请求(request)是怎么从Web服务器传送到ASP.NET运行时然后如何通过ASP.NET管道来处理请求. 对我而言了解平台的内幕通常会带来满足感和舒适感,深入了解也能帮助我写出更好的应用.

ASP.NET底层架构探索之进入.NET运行时

进入.NET运行时的真正的入口发生在一些没有被文档记载的类和接口中(译著:当然,你可以用Reflector来查看J).除了微软,很少人知道这些接口,微软的家伙们也并不热衷于谈论这些细节,他们认为这些实现细节对于使用ASP.NET开发应用的开发人员并没有什么用处. 工作进程(IIS5中是ASPNET_WP.EXE,IIS6中是W3WP.EXE)寄宿.NET运行时和ISAPI DLL,它(工作进程)通过调用COM对象的一个小的非托管接口最终将调用发送到ISAPIRuntime类的一个实例上(译注:原

ASP.NET底层架构探索之IE6的革新

asp.net|架构 IIS 5 和6以不同的方式工作 当一个请求来到时,IIS检查脚本映射(扩展名映射)然后把请求路由到aspnet_isapi.dll.这个DLL的操作和请求如何进入ASP.NET运行时在IIS5和6中是不同的.图2显示了这个流程的一个粗略概览. 在IIS5中,aspnet_isapi.dll直接寄宿在inetinfo.exe进程中,如果你设置了Web站点或虚拟目录的隔离度为中或高,则会寄宿在IIS单独的(被隔离的)工作进程中.当第一个ASP.NET请求来到,DLL(aspn

ASP.NET底层架构探索之HttpHandlers

asp.net|架构 模块是相当底层的,而且对每个来到ASP.NET应用程序的请求都会被触发.Http处理器更加的专注并处理映射到这个处理器上的请求. Http处理器需要实现的东西非常简单,但是通过访问HttpContext对象它可以变得非常强大.Http处理器通过实现一个非常简单的IHttpHandler接口(或是它的异步版本,IHttpAsyncHandler),这个接口甚至只含有一个方法-ProcessRequest()-和一个属性IsReusable.关键部分是ProcessReques

ASP.NET底层架构探索之处理请求

asp.net|架构|请求 当一个请求到来时,它被路由到ISAPIRuntime.ProcessRequest()方法.这个方法调用HttpRuntime.ProcessRequest方法,它作一些重要的事情(用Reflector查看System.Web.HttpRuntime.ProcessRequestInternal方法): ·为请求创建一个新的HttpContext实例 ·获取一个HttpApplication实例 ·调用HttpApplication.Init()方法来设置管道的事件

ASP.NET底层架构探索之ASP.NET管道

asp.net|架构 HttpApplication触发事件来通知你的程序有事发生,以此来负责请求流转.这作为HttpApplication.Init()函数的一部分发生(用Reflector查看System.Web.HttpApplication.InitInternal()方法和HttpApplication.ResumeSteps()方法来了解更多详情),连续设置并启动一系列事件,包括执行所有的处理器(handler).这些事件处理器映射到global.asax中自动生成的哪些事件中,同时

了解ASP.NET底层架构

asp.net|架构 了解ASP.NET底层架构 进入底层 这篇文章以非常底层的视角讲述了Web请求(request)在ASP.NET框架中是如何流转的,从Web服务器,通过ISAPI直到请求处理器(handler)和你的代码.看看在幕后都发生了些什么,不要再把ASP.NET看成一个黑盒了.   ASP.NET是一个非常强大的构建Web应用的平台,它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用.绝大多数的人只熟悉高层的框架如WebForms和WebServices-这些都在A