In classic ASP, the ASP processor is implemented as an Internet Server Application Programming Interface (ISAPI) extension called asp.dll. ISAPI is a programming interface that can be used to extend IIS. asp.dll is simply a COM object that supports specific interfaces and types in order to be an ISAPI extension. ISAPI extensions are associated in IIS with specific file types. For asp.dll the associated file type is .asp.
When IIS receives an HTTP-Request, it looks in its metabase to determine which ISAPI extension is registered to handle this type of file. IIS then routes the HTTP-Request to the appropriate ISAPI extension which is responsible for handling the request. For .asp files, asp.dll is responsible for handling the request: asp.dll loads the file into memory, parses it, and based on the language directive at the top of the file, loads the appropriate Active scripting engine. The Active scripting engine runs the parsed script and the asp.dll sends the result back to the browser in a return string. This is illustrated below:
Nonetheless, the classic ASP model did suffer from some limitations and problems:
Performance
The pages are scripted and not compiled code. This has a negative impact on
performance
Maintainability
ASP pages are usually a mixture of HTML and server-side script, and
occasionally, client-side script as well. The pages can get rather complex and
difficult to maintain with all these sections intermingled throughout the
document.
State Management
There were four issues with respect to managing state in the Application
and Session objects:
Use of COM
Anything outside the scope of VBScirpt or JScript was done using COM. This
approach suffers from configuration, deployment, and performance problems.
The following figure shows where ASP.NET fits in the .NET Framework:
ASP.NET is much more extensible than classic ASP because of its rich object model:
An HTTP Module is an assembly that implement the IHttpModule and handles events. Implementing the IHttpModule interface allows you to include custom events that participate in every request made to your application. ASP.NET includes a number of out-of-the-box HTTP Modules such as the SessionStateModule to supply session state services to an application. ASP.NET also allows non-C++ developers to create powerful applications that take advantage of preprocessing Web page requests and responses. For example, you can create an HTTP Module that intercepts a request for a Web page and does some validation. HTTP Modules are the .NET equivalent of ISAPI filters.
An HTTP Handler is a class that implements the IHttpHandler and IHttpAsyncHandler interfaces. Implementing the IHttpHandler interface gives you the means of interacting with the low level request and response services of the IIS web server and provides functionality much like ISAPI extensions. ASP.NET maps HTTP Requests to HTTP Handlers. Each individual HTTP Handler enables processing of individual URLs or groups of URL extensions within an application.You can also create HTTP Handlers that handle different file extensions - you could create your own type of Web Service with the a custom extension if required. Of course, you will be responsible for writing all the plumbing to handle requests, invoke objects, and so on.
When a request is made for an .aspx file (Win Forms) or .asmx file (Web Services), IIS checks its metabase and determines that the ASP.NET ISAPI extension xspisapi.dll is responsible for handling that request. IIS funnels the request to the unmanaged xspisapi.dll which in turn calls the managed xsp.exe to parse and handle the request. This begins a chain of calls that send the HTTP-Request through many layers of code (called HTTP Modules) until your Web Service or Web Forms file is executed. Note that HTTP Modules are similar to ISAPI filters. The following figure provides an overview of the layers and the sequence of events in the life of Web Service's execution:
The first time the .asmx file is called, it must be compiled to run within ASP.NET Runtime as managed code. After the Web Service has been compiled, the HTTP-Request can be sent through a pipeline to the appropriate HTTP Handler for final processing. The pipeline consists of multiple HTTP Modules that perform various functions on the HTTP-Request. Out-of-the-box modules include functionality for logging, authentication, authorization, and session state. The modules can be replaced by your own code if necessary, and you can add new ones.
Additionally, you can create your own HTTP Handlers to add more flexibility and power. You could create your own HTTP Handlers to provide special monitoring and authorization functions as a means of managing your Web Services.
Eventually, the WebServiceHandlerFactory class in System.Web.Services.Protocols is called. This class performs several functions including derserializing the SOAP message and running your code to perform the logic you developed in the Web Service. Like most items in ASP.NET, the Web Services HTTP Handler can be configured in web.config file.
After the code has finished processing the HTTP-Request, it serializes the return value into a SOAP message and sends back up the chain of HTTP Modules, and then back to IIS and the consumer of the Web Service.
A Web Service or Web Forms file must be compiled to run within the CLR. Compilation can be implicit or explicit. Although you could explicitly call the appropriate compiler to compile your Web Service or Web Forms files, it is easier to allow the file to be complied implicitly. Implicit compilation occurs when you request the .asmx via HTTP-SOAP, HTTP-GET, or HTTP-POST. The parser (xsp.exe) determines whether a current version of the assembly resides in memory or in the disk. If it cannot use an existing version, the parser makes the appropriate call to the respective compiler (as you designated in the Class property of the .asmx page).
When the Web Service (or Web Forms page) is implicitly compiled, it is actually compiled twice. On the first pass, it is compiled into IL. On the second pass, the Web Service (now an assembly in IL) is compiled into machine language. This process is called Just-In-Time JIT compilation because it does not occurs until the assembly is on the target machine. The reason you do not compile it ahead of time is so that the specific JITter for your OS and processor type can be used. As a result, the assembly is compiled into the fastest possible machine language code, optimized and enhanced for your specific configuration. It also enables you to compile once and then run on any number of operating systems.