Many power users, not just developers, are familiar with the basic meaning of the expression "Web site". At this level of abstraction, a Web site is the place where you go following a few links. So, abstracting, a Web site is the repository of a number of HTTP-based endpoints. Overall, this definition is correct, but it doesn't shine as far as precision is concerned.
Up to Windows Internet Information Services (IIS) 6, you could have used the following as a more precise definition for what a Web site actually is: a collection of virtual directories. However, the truth is that you can even call that "a virtual directory", but what it actually does is much more. It is, in fact, more akin to a virtual application than just a plain directory under a segment of a Web site. With IIS 7, the naming conventions around the official documentation have made it clearer. So at the end of the day, under IIS we have three concepts that form a hierarchy:
- A Web site is a collection of virtual applications
- A virtual application is a collection of virtual directories
- And finally a virtual directories contains resources that can physically invoked from the users.
While this definition works great for people looking for a simple but not simplistic explanation, it leaves room for a lot of details. So let's expand on.
A Web site is essentially a container for applications and virtual directories. A site is associated with protocols such as HTTP and HTTPS and binding information including IP address and ports. The list of binding protocols is not limited to HTTP and HTTPS; in IIS 7, in fact, the component known as the Windows Activation Service (WAS) enables the use of additional protocols thus decoupling IIS from HTTP.
Within a Web site, you find a collection of virtual applications. Each site must have at least one (default) application. A virtual application is identified by its absolute virtual path attached to the Web site name. For each virtual application, the WAS registers a list of URLs in the HTTP listener service (http.sys). Each application can support a number of protocols and is not limited to HTTP. A virtual application must belong to an application pool. An application pool is a pool of virtual applications run under the aegis of the same instance of the IIS worker process. Pooled applications share the same security account and IIS settings such as process recycling, debug, idle time, Web gardens. All requests directed at the application, except those for static resources not otherwise configured, are served within the pool.
A virtual directory is just a container of files and at least one virtual directory must be present in any virtual application. The directory is said to be virtual because it doesn't necessarily map 1:1 to a physical directory in the Web server disk. You typically use a virtual directory to logically import in the site structure -- without moving -- content that physically belongs to other paths in the server machine. Up until IIS 6, the concept of a virtual application and that of a virtual directory were kind of blurred.
Virtual applications and virtual directories have been clearly defined as distinct objects in IIS 7. As a result, you now have a clear hierarchy that begins with the site object and ends with a virtual directory. This hierarchy also shows up nicely in the schema of the configuration file.