Question

I am using IIS to develop some web applications. I used to believe that every application should have a entry point. But it seems a web application doesn’t have one.

I have read many books and articles addressing how to build an ASP.NET application under IIS, but they are just not addressing the most obvious and basic thing that I want to know.

So could anyone tell me how is a web application started? What’s the difference between a traditional desktop application and a web application in terms of their working paradigm, such as the starting and terminating logic.

Many thanks.

Update – 1 – 23:14 2011/1/4

My current understanding is:

When some request arrives, the URL contained in the request will be extracted by the IIS. I guess IIS must have maintained some kind of a internal table which maps a URL to corresponding physical directory on disk. Let’s take the following URL as an example:

http://myhost/webapp/page1.aspx

With the help of the aforementioned internal table, IIS will locate the page1.aspx file on disk. And then this file is checked and the code-behind code file is located. And then proper page class instance will be contructed and its methods defined in the code-behind file will be invoked in a pre-defined order. The output of the series of method invoking will be the response sent to the client.

Update – 2 – 23:32 2011/1/4

The URL is nothing but an identifier that serves as an index into the aforementioned internal table. With this index, IIS (or any kind of web server technology) could find the physical location of the resource. Then with some hint (such as file extension name like *.aspx), the web server knows what handler (such as the asp.net ISAPI handler) should be used to process that resource. That chosen handler will know how to parse and execute the resource file.

So this also explains why a web server should be extensible.

Answer 1

It depends what language and framework you are using, but broadly there are a number of entry points that will be bound to HTTP requests (e.g. by URL). When the server receives a request that matches one of these bindings, the bound code is executed.

There may also be various filter chains and interceptors that are executed based on other conditions of the request. There will probably also be some set-up code that the server executes when it starts up. Ultimately, there is still a single entry-point – the main() function of the server – but from the web application’s perspective it is the request bindings that matter.

Edit in response to question edits

I have never used IIS, but I would assume there is no "lookup table", but instead some lookup rules. I shall talk you through the invocation of a .jsp page on an Apache server, which should be basically the same process.

1. The webapp is written and placed in the file system – e.g. C:/www/mywebapp
2. The web server is given a configuration rule telling it that the URL path /webapp/ should be mapped to C:/www/mywebapp
3. The web server is also configured to recognise .jsp files as being JSP servlets
4. The web server receives a request for /webapp/page1.jsp, this is dispatched to a worker thread
5. The web server uses its mapping rules to locate C:/www/mywebapp/page1.jsp
6. The web server wraps the code in the JSP file in a class with method serveRequest(request, response) and compiles it (if not already done so)
7. The web server calls the serveRequest function, which is now the entry point of the user code
8. When the user code is finished, the web server sends the response to the client, and the worker thread terminates

This is the most basic system – resource-based servlets (i.e. .jsp or .aspx files). The binding rules become much more complicated when using technologies like MVC frameworks, but the essential concepts are the same.