ISAPI applications were often called ISAPI extensions because they “extended” the functionality of the However, Microsoft recommended using ISAPI wherever possible because of its greater scalability and better performance. In this scenario, the client sends an HTTP request that’s received by the It receives a response and forwards this response to the Figure 2-1: The in-process execution model of IIS 1, 2, and 3. An ISAPI filter is an ISAPI DLL that receives an HTTP request, processes it in some fashion, and then forwards it to the World Wide Web Publishing Service (Alternatively, ISAPI applications could be written to enable database lookups from web pages. For example, ISAPI filters could be used to preprocess HTTP requests from web browser clients to perform functions such as customized authentication, access control, and logging. On the whole, ISAPI was a terrific idea and made IIS a powerful platform on which to develop dynamic web applications. Another advantage is that the overhead of constantly switching between processes (a problem with the CGI model) is eliminated, because IIS also allowed ISAPI DLLs to be loaded into memory at server runtime. This means that ISAPI applications are more scalable because they use memory more efficiently than CGI does. Unlike CGI, however, a single ISAPI DLL can satisfy requests from multiple clients simultaneously (in the CGI model, a new CGI process must be started to handle each client request). Like CGI, these ISAPI DLLs can be loaded into memory when needed and unloaded when no longer required. In-process means that an ISAPI DLL runs within the main web server process inetinfo.exe, not within its own separate process as in the CGI model.
The process of creating and destroying CGI processes also consumes processor and memory resources, further degrading performance and limiting CGI’s ability to scale.īecause CGI scaled so poorly, Microsoft developed the ISAPI approach based on in-process execution as an alternative. So, if a site with a form is experiencing heavy traffic, it is possible that a dozen or more instances of the same CGI process might be simultaneously running on the server, each consuming its own memory resources.
Inetinfo service code#
While CGI works well enough for simple applications like form handlers (the code that handles information submitted from a form on a web page), performance is usually poor because each time a CGI application is invoked, a new instance of the CGI application is started on the web server. CGI uses an out-of-process execution model whereby a CGI application (typically a Perl script) runs within its own CGI process, separate from the web server process or Httpd daemon.
Inetinfo service windows#
ISAPI was developed for IIS 1 as the Windows NT alternative to the Common Gateway Interface (CGI) of UNIX web servers. This was very different from the original UNIX web server model, as you’ll see next. These DLLs would then be loaded into the main IIS web server process (inetinfo.exe) and run within that process. In other words, a developer who wanted to write a web application would typically use Microsoft’s Internet Services Application Programming Interface (ISAPI) and the C programming language to write DLLs that would add dynamic functionality to their website. The original architecture of IIS could best be described as monolithic: everything was based on in-process execution. I touched on some of the new architectural features of IIS 6 in the previous chapter and will now cover them in detail.
It will help you understand the enhancements and new features of the current version IIS 6 if we trace the evolution of IIS architecture from the early days to today. In fact, the internals of IIS have undergone significant redesign several times. The inner workings of IIS have evolved a great deal since the initial version IIS 1 was released in February 1996.
Understanding this information is crucial to being able to effectively deploy, configure, manage, monitor, maintain, and troubleshoot IIS web applications in the real world. This chapter complements the previous one by providing an in-depth examination of the internal workings or architecture of IIS. These enhancements are intended to increase the security, reliability, scalability, performance, and manageability of the platform. In the previous chapter, we looked at the new features and enhancements Microsoft has incorporated into their latest version of IIS.