
ASP.NET底层架构探索之再谈.NET运行时
发布时间:2006-09-09 11:36:05 来源:博客网 网友评论 0 条
在这里我们有一个在ISAPI扩展中活动的,可调用的ISAPIRuntime对象的实例。每次运行时是启动的并运行着的时候(译注:相对的,如果运行时并没有启动,就需要象上一章所说的那样载入运行时),ISAPI的代码调用ISAPIRuntime.ProcessRequest()方法,这个方法是真正的进入ASP.NET管道的入口,这个流程在图4中显示。
记住ISAPI是多线程的,所以请求也会通过AppDomainFactory.Create()(译注:原文为ApplicationDomainFactory,疑有误)函数中返回的引用在多线程环境中被处理.列表1显示了ISAPIRuntime.ProcessRequest()方法中反编译后的代码,这个方法接收一个ISAPI ecb对象和服务类型(WorkerRequestType)作为参数.这个方法是线程安全的, 所以多个ISAPI线程可以同时在这一个被返回的对象实例上安全的调用这个方法。
列表1:ProcessRequest方法接收一个ISAPI Ecb并将其传给工作线程
这里实际的代码并不重要, 记住这是从内部框架代码中反编译出来的, 你不能直接处理它, 它也有可能在将来发生改变.它只是用来揭示在幕后发生了什么.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方法
ISAPIWorkerRequest实现了一个高层次的包装方法, 它调用了低层的核心方法, 负责真正的访问非托管APIs-或称为”服务级别的实现”(service level implementation).这些核心方法在特殊的ISAPIWorkerRequest子类中为它寄宿的环境提供特殊的实现, 这实现了简单的扩展的(pluggable)环境, 这样一来当以后新的Web服务器接口或其他平台成为了ASP.NET的目标时附加的实现类可以在被简单的提供出来。这里还有一个协助类(helper class)System.Web.UnsafeNativeMethods.里面许多对ISAPI ECB结构的操作实现了对ISAPI扩展的非托管操作。
记住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扩展的非托管操作。
推荐阅讯
- 在ASP.NET中跨页面实现多选
- ASP.NET技巧:HTTP性能调优之设置连接失效时
- 用IE的Web服务建立ASP.NET应用程序
- 用ASP.NET写一个发送ICQ信息的程序
- ASP.NET2.0数据操作之创建数据访问层
- C#+ASP.NET开发基于Web的RSS阅读器
- 当ASP.NET撞上JSF之构建应用程序的异同
- ASP.NET底层架构探索之进入ASP.NET
- ASP.NET 2.0页面框架简要慨述
- 业界观察:微软将在.NET上解释PHP?
阅读排行
- 1.用ASP.NET 2.0设计网络在线投票系统
- 2.在ASP.Net 2.0中实现多语言界面的方法
- 3.轻松加密ASP.NET 2.0 Web程序配置信息
- 4.在ASP.NET中使用AJAX的简单方法
- 5..NET 2.0中的企业库异常处理块简述
- 6.面向.NET开发人员的Ajax 技术平台策略
- 7.揭开ASP.NET中Cookie编程的奥秘
- 8.ASP.NET2.0服务器控件之创建自定义控件
- 9.ASP.NET2.0中Gridview中数据操作技巧
- 10.ASP.NET 2.0发送电子邮件全面剖析之二
专题教程
- 大话G游 专题:手机病毒揭密
- ARP攻击防范与解决方案 路由故障处理手册
- Picasa中文版_Picasa教程 专题:清除流氓软件
- Firefox专题 seo搜索引擎优化专区
- 重装Windows必知的事情 装机之必备软件大行动
病毒专杀栏
