A low-level Look at the ASP.NET Architecture - 0 views
-
Most people are familiar only with the high level frameworks like WebForms and WebServices which sit at the very top level of the ASP.NET hierarchy.
-
WebForms are definitely the easiest way to build most Web interfaces, but if you’re building custom content handlers, or have special needs for processing the incoming or outgoing content, or you need to build a custom application server interface to another application, using these lower level handlers or modules can provide better performance and more control over the actual request process. With all the power that the high level implementations of WebForms and WebServices provide they also add quite a bit of overhead to requests that you can bypass by working at a lower level.
-
ASP.NET is a sophisticated engine using Managed Code for front to back processing of Web Requests.
- ...56 more annotations...
-
It takes an incoming request and passes it through its internal pipeline to an end point where you as a developer can attach code to process that request. This engine is actually completely separated from HTTP or the Web Server. In fact, the HTTP Runtime is a component that you can host in your own applications outside of IIS or any server side application altogether
-
ASP.NET is a request processing engine.
-
Through this mechanism it’s possible to hook into very low level interfaces such as the caching, authentication and authorization
-
The entire ASP.NET engine was completely built in managed code and all extensibility is provided via managed code extensions.
-
the most impressive part of ASP.NET is the thoughtful design that makes the architecture easy to work with, yet provides hooks into just about any part of the request processing.
-
ISAPI is a low level Win32 style API that had a very meager interface and was very difficult to work for sophisticated applications.
-
ASP.NET on Microsoft platforms interfaces with IIS through an ISAPI extension that hosts .NET and through it the ASP.NET runtime. ISAPI provides the core interface from the Web Server and ASP.NET uses the unmanaged ISAPI code to retrieve input and send output back to the client. The content that ISAPI provides is available via common objects like HttpRequest and HttpResponse that expose the unmanaged data as managed objects with a nice and accessible interface.
-
At the lowest level ASP.NET interfaces with IIS through an ISAPI extension.
-
All of these HttpHandlers are mapped to point at the ASP.NET ISAPI extension in IIS, and configured in web.config to get routed to a specific HTTP Handler implementation.
-
an extension is the basic mapping mechanism that ASP.NET uses to receive a request from ISAPI and then route it to a specific handler that processes the request.
-
ISAPI is very low level it’s not well suited for building application level code
-
ISAPI tends to be used primarily as a bridge interface to provide Application Server type functionality to higher level tools
-
In ASP and ASP.NET, the engines abstract the information provided by the ISAPI interface in the form of objects like Request and Response that read their content out of the ISAPI request information.
-
The HttpContext object also contains a very useful Items collection that you can use to store data that is request specific. The context object gets created at the begging of the request cycle and released when the request finishes, so data stored there in the Items collection is specific only to the current request.
-
Extensions are a request handling interface and provide the logic to handle input and output with the Web Server – it’s essentially a transaction interface. ASP and ASP.NET are implemented as ISAPI extensions. ISAPI filters are hook interfaces that allow the ability to look at EVERY request that comes into IIS and to modify the content or change the behavior of functionalities like Authentication. Incidentally ASP.NET maps ISAPI-like functionality via two concepts: Http Handlers (extensions) and Http Modules (filters)
-
Instead IIS 6 always creates a separate worker process – an Application Pool – and all processing occurs inside of this process, including execution of the ISAPI dll.
-
Application Pools are a big improvement for IIS 6, as they allow very granular control over what executes in a given process. Application Pools can be configured for every virtual directory or the entire Web site, so you can isolate every Web application easily into its own process that will be completely isolated from any other Web application running on the same machine. If one process dies it will not affect any others at least from the Web processing perspective.
-
Because Application Pools are external executables these executables can also be easily monitored and managed
-
ISAPI extensions run in the Application Pool worker process. The .NET Runtime also runs in this same process, so communication between the ISAPI extension and the .NET runtime happens in-process which is inherently more efficient than the named pipe interface that IIS 5 must use
-
The first entry point to the runtime is the undocumented ISAPIRuntime class which exposes the IISAPIRuntime interface via COM to a caller.
-
The IISAPIRuntime interface acts as the interface point between the unmanaged code coming from the ISAPI extension (directly in IIS 6 and indirectly via the Named Pipe handler in IIS 5)
-
The ecb parameter is the ISAPI Extension Control Block (ECB) which is passed as an unmanaged resource to ProcessRequest.
-
To create the ISAPIRuntime instance the System.Web.Hosting.AppDomainFactory.Create() method is called when the first request for a specific virtual directory is requested
-
When a request hits, it is routed to the ISAPIRuntime.ProcessRequest() method.
-
This method in turn calls
-
HttpRuntime.ProcessRequest that does several important things (look at System.Web.HttpRuntime.ProcessRequestInternal with Reflector): Create a new HttpContext instance for the request Retrieves an HttpApplication Instance Calls HttpApplication.Init() to set up Pipeline Events Init() fires HttpApplication.ResumeProcessing() which starts the ASP.NET pipeline processing
-
All the heavy lifting and processing, and even the request thread management happens inside of the ASP.NET engine and your code.
-
HttpContext object represents the context of the currently active request as it contains references to all of the vital objects you typically access during the request lifetime: Request, Response, Application, Server, Cache. At any time during request processing HttpContext.Current gives you access to all of these object.
-
First a new HttpContext object is created and it is passed the ISAPIWorkerRequest that wrappers the ISAPI ECB
-
The HttpApplication is like a master of ceremonies – it is where the processing action starts
-
Each request is routed to an HttpApplication object.
-
It’s the first entry point into the HTTP Runtime that you actually see on a regular basis in your applications.
-
HttpApplication is the outer container for your specific Web application and it maps to the class that is defined in Global.asax.
-
HttpApplication’s primary purpose is to act as the event controller of the Http Pipeline and so its interface consists primarily of events.
-
It’s important to understand that each ASP.NET virtual application runs in its own AppDomain and that there inside of the AppDomain multiple HttpApplication instances running simultaneously, fed out of a pool that ASP.NET manages. This is so that multiple requests can process at the same time without interfering with each other.
-
AppDomain ID stays steady while thread and HttpApplication Ids change on most requests
-
HttpApplications are running out of a collection and are reused for subsequent requests so the ids repeat at times.
-
Threads are served from the .NET ThreadPool and by default are Multithreaded Apartment (MTA) style threads
-
The fact that these HttpApplication objects are all running in the same AppDomain is very important. This is how ASP.NET can guarantee that changes to web.config or individual ASP.NET pages get recognized throughout the AppDomain. Making a change to a value in web.config causes the AppDomain to be shut down and restarted. This makes sure that all instances of HttpApplication see the changes made because when the AppDomain reloads the changes from ASP.NET are re-read at startup. Any static references are also reloaded when the AppDomain so if the application reads values from App Configuration settings these values also get refreshed.
-
In essence the Web Application/Virtual completely ‘restarts’ when this happens. Any requests that are already in the pipeline processing will continue running through the existing pipeline, while any new requests coming in are routed to the new AppDomain. In order to deal with ‘hung requests’ ASP.NET forcefully shuts down the AppDomain after the request timeout period is up even if requests are still pending. So it’s actually possible that two AppDomains exist for the same HttpApplication at a given point in time as the old one’s shutting down and the new one is ramping up. Both AppDomains continue to serve their clients until the old one has run out its pending requests and shuts down leaving just the new AppDomain running.
-
The HttpApplication is responsible for the request flow by firing events that signal your application that things are happening.
-
Both HttpModules and HttpHandlers are loaded dynamically via entries in Web.config and attached to the event chain. HttpModules are actual event handlers that hook specific HttpApplication events, while HttpHandlers are an end point that gets called to handle ‘application level request processing’.
-
The HttpApplication itself knows nothing about the data being sent to the application – it is a merely messaging object that communicates via events. It fires events and passes information via the HttpContext object to the called methods
-
ASP.NET Page and Web Service frameworks are implemented as HTTPHandlers and that’s where all the core processing of the request is handled
-
Modules allow you look at each incoming Web request and perform an action based on the events that fire. Modules are great to modify request or response content, to provide custom authentication or otherwise provide pre or post processing to every request that occurs against ASP.NET in a particular application.
-
hile HttpModules feel similar to ISAPI Filters in that they look at every request in that comes through an ASP.NET Application, they are limited to looking at requests mapped to a single specific ASP.NET application or virtual directory and then only against requests that are mapped to ASP.NET. Thus you can look at all ASPX pages or any of the other custom extensions that are mapped to this application. You cannot however look at standard .HTM or image files unless you explicitly map the extension to the ASP.NET ISAPI dll by adding an extension as shown
-
Watch out for one important gotcha with HttpModules and HttpApplication events: Response.End() or HttpApplication.CompleteRequest() will shortcut the HttpApplication and Module event chain.
-
Modules are fairly low level and fire against every inbound request to the ASP.NET application. Http Handlers are more focused and operate on a specific request mapping, usually a page extension that is mapped to the handler.
-
WebForms and WebServices are both implemented as Http Handlers, so there’s a lot of power wrapped up in this seemingly simplistic interface.
-
Because the Context object is available to you, you get access to the Request, Response, Session and Cache objects, so you have all the key features of an ASP.NET request at your disposal to figure out what users submitted and return content you generate back to the client.
-
Remember the Context object – it’s your friend throughout the lifetime of an ASP.NET request!
-
Behind the scenes the ISAPIWorkerRequest manages sending the OutputStream back into the ISAPI ecb.WriteClient method that actually performs the IIS output generation.
-
-
So handlers are more efficient. Handlers also can do things that aren’t possible with WebForms such as the ability to process requests without the need to have a physical file on disk, which is known as a virtual Url
-
To do this make sure you turn off ‘Check that file exists’ checkbox in the Application Extension dialog shown in Figure 1.
-
IIS gets the request Looks up a script map extension and maps to aspnet_isapi.dll Code hits the worker process (aspnet_wp.exe in IIS5 or w3wp.exe in IIS6) .NET runtime is loaded IsapiRuntime.ProcessRequest() called by non-managed code IsapiWorkerRequest created once per request HttpRuntime.ProcessRequest() called with Worker Request HttpContext Object created by passing Worker Request as input HttpApplication.GetApplicationInstance() called with Context to retrieve instance from pool HttpApplication.Init() called to start pipeline event sequence and hook up modules and handlers HttpApplicaton.ProcessRequest called to start processing Pipeline events fire Handlers are called and ProcessRequest method are fired Control returns to pipeline and post request events fire
Cached
