This article discusses:
IIS Extension points
Building Response Modification Module
Add IIS Manager configuration
Deploying modules
This article uses the following techniques:
IIS 7.0,. NET Framework
The IIS 7.0 WEB platform can support more application framework technologies to host rich applications than any previous version of IIS, and it has the complete functionality to deploy these applications directly. But also note that what you see (in Windows® installation) is not necessarily what you eventually get.
The IIS 7.0 architecture is designed to be extensible from top to bottom, allowing you to replace any part of the built-in feature set with a custom implementation that fits your needs. So instead of providing some patchwork plug-in points, IIS 7.0 achieves the ultimate scalability commitment by implementing all of its own functionality on the top of the public extensible model. This design can be seen throughout the platform, from the module Web server engine itself to the configuration system to the IIS Manager console.
This article will study the IIS 7.0 extensible model, and we will make a brief introduction to the shared Source "Response modification" project, which can dynamically modify the response from the IIS application using configurable response modification rules. First we will build the WEB server module using the server's integrated asp.net extensibility. We will then develop custom configuration segments and create custom administration pages for IIS Manager to adjust the module's deployment and management capabilities.
Extending WEB Servers
The IIS 7.0 module architecture has the functionality of a WEB server that fully customizes the required workloads. This is usually done by simply installing the required functionality of the application and establishing a streamlined WEB server that does not perform any other tasks except for the assignment.
But that's just the beginning. Typically, the required WEB workload requires additional functionality that may not be part of the built-in IIS feature set. Or, in some cases, the application may require a custom set of features because of the lack of flexibility in the built-in functionality. Because all of the functionality of IIS 7.0 is built on a public extensible API, you can replace any part of it with a custom implementation that best suits your needs.
IIS 7.0 provides two options for developing a WEB server module. First, you can use the new C + + module API, which is the basis for most of the built-in features. The module API replaces the ISAPI extension and filters out the APIs provided in previous versions of IIS. This API is a significant improvement over ISAPI because it is rich in content, supports all IIS 7.0 features, and is very easy to program. You can find more information about this API improvement through the following Web site: mvolo.com/blogs/serverside/archive/2006/10/07/10- Reasons-why-server-development-is-better-with-iis7.aspx.
Second, IIS 7.0 is integrated with ASP.net, which allows users to develop IIS 7.0 modules using their familiar ASP.net module APIs. In ASP.net integration mode, these modules are considered a class of members in the IIS request processing pipeline, as shown in Figure 1. This allows the ASP.net module to access IIS intrinsic objects (such as requests and responses) at all stages of processing the request, and it also allows it to handle requests for all resource types-not just those processed by the ASP.net framework.
Figure 1 asp.net module in IIS 7.0 request processing