IIS7.0特性

IIS 7.0可以與ASP.NET框架高度集成，而且提供了完整的API，從而能夠爲平臺提供完整的可擴展能力和管理接口。還提供了配置委託和完整的診斷套件，診斷套件能夠對需求進行跟蹤，還提供了高級日誌功能。IIS 7.0將ASP.NET與請求管道進行了集成，這也許是IIS 7.0所作出的最爲重大的改變。
IIS 7.0的模塊化設計還有利於咱們開發定製模塊，並且附加功能也更容易實現。從而有利於將內部開發的功能與IIS更好地結合，還有利於將第三方資源與IIS更好地結合，甚至有利於微軟公司開發的功能與IIS更好地結合。這是由於：不管什麼時候，在無需修改操做系統核心功能的狀況下，這些模塊和附加程序均可以做爲IIS的插件進行工做，所以微軟公司的IIS開發團隊能夠在微軟公司的標準service pack過程以外發布功能模塊。

集成的請求管道
IIS 7.0最大的變化之一是它能夠與ASP.NET及ASP.NET進程進行緊密集成。IIS 7.0提供了統一的事件管道，該管道將現有的兩種獨立管道----即IIS管道和ASP.NET管道進行了合併，這兩種管道是IIS 6.0以及先前版本的IIS提供的。ASP.NET的HTTP模塊原先僅偵聽ASP.NET管道的事件，如今能夠監放任何請求。爲了向後兼容，IIS 7.0還提供了Classic管道模式，Classic管道模式能夠模擬IIS 6.0的IIS管道，也能夠模擬IIS 6.0的ASP.NET管道。

IIS 7.0提供了一個單獨的統一管道。ASP.NET提供的Forms身份驗證和角色管理是身份驗證和受權過程的組成部分，所以對一個請求僅驗證一次。在IIS 7.0中，全部的請求都要通過ASP.NET的Forms身份驗證模塊進行處理，而不只僅是那些具備.ASPX擴展名的文件才須要由ASP.NET的Forms身份驗證模塊進行處理。例如，對 www.domain1.com/images/myimage.gif 的請求首先要傳遞給ASP.NET的Forms身份驗證進程，若是web.config文件中的某種身份驗證方式拒絕訪問該文件或文件夾，那麼缺乏權限的用戶將沒法觀察或下載該圖像。如今將請求傳遞給管道並退出，而後再傳遞給發出請求的瀏覽器，所以無須再傳遞給ASP.NET等ISAPI進程。考慮到兼容性問題，儘管ISAPI處理程序退出時須要返回一個退出編碼，可是實際上請求並無在ISAPI中進行處理，若是咱們不須要考慮遺留代碼的兼容性，咱們甚至不須要加載ISAPI處理程序。

在 IIS 7.0管道內部，每一個進程都由一個單獨的組件進行處理。須要使用這些組件的網站能夠單獨加載這些組件，若是網站或應用程序不須要在管道中使用這些組件，那麼就無須加載這些組件。在應用程序級、網站級和服務器級，這些組件都是可配置的，並且，咱們能夠在上述任何一個級別中委託組件的配置功能。此外，咱們還能夠將自定義的組件插入管道，甚至能夠將管道中組件的執行順序從新進行排序。例如，當請求開始執行時，能夠觸發一個日誌跟蹤操做，而且當請求結束處理後，將日誌跟蹤寫入一個文件。組件的執行順序就是各個組件在配置文件中所處的順序。

可配置性
IIS 7.0的另外一個變化是：IIS的配置過程已經集成到ASP.NET應用程序的配置過程當中，這個變化是一個至關顯著的變化。如今咱們無須再使用IIS註冊表設置，而原先做爲IIS配置庫的metabase已經被基於XML的配置文件所取代，這個基於XML的配置文件中同時保存了IIS設置和ASP.NET設置。這樣，不只消除了ASP.NET應用程序和應用服務器之間的界限，同時還提升了IIS的可配置性，簡化了網站和應用程序的部署過程。同時，在web farm中的多系統上部署應用程序也更爲方便，而且改善了配置的可擴展性。IIS 7.0引入了共享配置的概念，在這個概念中，多個web服務器可使用同一個物理文件做爲各自的配置文件，這樣若是咱們對web farm的配置進行修改，那麼修改的內容能夠立刻生效。
如今，IIS 7.0使用一個名爲applicationHost.config的文件保存設置，此外，針對一個獨立的Web網站或Web應用程序，IIS 7.0的配置選項也能夠隨着ASP.NET的設置一同保存在web.config文件中，固然，IIS 7.0的配置選項保存在該文件的system.webServer一節中。

1.使用applicationHost.config配置文件

IIS 7.0使用文件applicationHost.config爲Web 服務器和集成模型保存IIS配置，如今，全局配置保存在%windir%\system32\inetsrv\config 目錄下的applicationHost.config文件中，該文件包括兩個主要的部分：

（1）system.applicationHost 這部份內容保存了網站、應用程序、虛擬目錄和應用程序池的配置信息。

（2）system.webServer 這部分保存了其餘設置及全局默認設置。

對URL位置所進行的配置既能夠保存在applicationHost.config文件中，也能夠保存在web.config中。這樣，管理員能夠設置服務器上的默認設置，而開發人員能夠在必要的狀況下從新定義這些設置。這些設置能夠由web.config文件在根級和應用程序級進行繼承。在對設置進行委託時，這一點很是重要，由於IIS管理員能夠容許開發人員在應用程序級以很細的粒度對設置進行控制，同時，IIS管理員還可以在網站級對設置進行控制。

2.可擴展的配置架構

利用新的配置模型，能夠很容易對 IIS 7.0配置進行擴展。如今，假定咱們須要爲 IIS 建立一個新的模塊。此時，須要在 applicationHost.config 文件的 <globalModules>一節指出模塊對應的 DLL 文件，而後，在 applicationHost.config 文件中或適當的 web.config 文件中聲明該模塊。爲新模塊擴展配置架構與在系統的 inetsrv\config\schema 目錄中建立架構文件同樣簡單。經過在 applicationHost.config 文件的<configSections>配置節中添加一節內容，就能夠完成這項工做。

組件化IIS 7.0的可擴展性不只表如今配置過程。由於 IIS 7.0對請求處理管道進行了修改，經過使用本機代碼和託管代碼，核心服務器自己也獲得了擴展。這種擴展性來源於 IIS 核心功能的組件化。此時不須要再使用 ISAPI 過濾器來修改請求過程，咱們能夠將自行開發的組件直接注入處處理管道中。自行開發的組件既能夠是咱們本身開發的組件，也能夠是第三方工具或組件，還能夠是微軟公司提供的現有核心組件。因此，若是不喜歡 Windows 身份驗證過程，那麼不只能夠對全部的文件使用 forms 身份驗證過程，並且還能夠選擇忽略全部內置的身份驗證過程，而採用咱們開發的身份驗證過程。這還意味着：若是不須要處理傳統的 ASP 文件，那麼只要再也不加載對應的組件就能夠了。在先前的 IIS 版本中，每一個組件須要看成一個單獨的 DLL 加載到內存中，如今再也不須要加載無關的內容，從而減小了 IIS 7.0的開銷。