IIS服務器管道進行隔離一些局限與不足
在使用過IIS服務器的過程中，我們來講解下IIS服務器的知識。IIS服務器 5.x和IIS服務器 6.0下把兩個管道進行隔離至少帶來了下面一些局限與不足，例如相同操作的重復執行：IIS服務器與ASP.NET之間具有一些重復的操作，比如身份驗證。
動態文件與靜態文件處理的不一致：因為只有基于ASP.NET的動態文件（比如.aspx、.asmx、.svc等等）的HTTP請求才能通過ASP.NET ISAPI進入ASP.NET管道，而對于一些靜態文件（比如.html、.xml、.img等）的請求，則由IIS服務器直接響應，那么ASP.NET管道中的一些功能將不能用于這些基于靜態文件的請求，比如，我們希望通過Forms認證應用于基于圖片文件的請求。
IIS服務器難以擴展：對于IIS服務器的擴展基本上就體現在自定義ISAPI，但是對于大部分人來說，這不是一件容易的事情。因為ISAPI是基于Win32的非托管的API，并非一種面向應用的編程接口。
通常我們希望的是諸如定義ASP.NET的HttpModule和HttpHandler一樣，通過托管代碼的方式來擴展IIS。 對于Windows平臺下的IIS來講，ASP.NET無疑是一等公民，它們之間不應該是“井水不犯河水”的關系，而應該是“你中有我，我中有你”的關系。
為此，在IIS服務器 7.0中，實現了兩者的集成。對于集成模式下的IIS服務器 7.0，我們獲得如下的好處。
允許我們通過本地代碼（Native Code）和托管代碼（Managed Code）兩種方式定義IIS Module，這些IIS Module注冊到IIS中形成一個通用的請求處理管道。由這些IIS Module組成的這個管道能夠處理所有的請求，不論請求基于怎樣的資源類型。
比如，IIS服務器可以將FormsAuthenticationModule提供的Forms認證應用到基于.aspx，CGI和靜態文件的請求。 將ASP.NET提供的一些強大的功能應用到原來難以企及的地方，比如將ASP.NET的URL重寫功能置于身份驗證之前。采用相同的方式去實現、配置、檢測和支持一些服務器特性（Feature），比如Module、Handler映射、錯誤定制配置（Custom Error Configuration）等。
【編輯推薦】
