How is a web application started? Where is the entry point (if there's one)?

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.

Answer 2

Similar to what OrangeDog mentioned in his answer, there is plenty that goes on when serving these pages Before you even get to your code.

Not only in asp.net mvc, but in asp.net in general there are various pieces that come into play when you're executing a request.

There is code like modules, handlers, etc that again do processing Before it gets to the code of the page. Additionally you can map the same page to be able to process different urls.

The concept of handler in asp.net is important, as there are various handlers that are responsible of processing requests that match extensions and/or http verbs (get, head, post). If you take a look into %systemroot%\Microsoft.NET\Framework64\v4.0.30319\Config\web.config, you can see a section. You can also see the handlers in IIS (these can be changed x site).

For example, the HttpForbiddenHandler is one that just rejects the request. It is configured to be called for special files like the sources "*.cs".

You can define your own handler, that is nothing more than a class that implements an IHttpHandler interface. So it has 2 methods: ProcessRequest and IsReusable. This is more similar to your cgi program, as the implementation is mainly a method that produces HTML or any other type of output based on the information in the request.

Asp.net pages build on top of that, and have plenty of extra features meant to make it easier for you to develop pages. You implement a class that inherits from Page, and there are 2 code files associated to it (.aspx and .cs). The same can be said for asp.net mvc, but it is structured differently. There is much more than it, if you want to take advantage of it you'd need to learn about it.

The downside of those abstractions, is that it makes some developers lose track of the context they're at / about the underlying. The context is still the same, you're producing an application that takes a request and produces an output. The difference is that there is plenty more code in place intended to make it easier.