Web Applications
兩種主要方式存在因使用WSS的中央管理的應用程序或Stsadm.exe命令行實用程序Web應用程序。首先，您可以通過轉換現有IIS網站Web應用程序。或者，您可以從頭開始創建新的Web應用程序，讓WSS的創建新的IIS Web站點爲您在幕後。在任何情況下，WSS的配置，加入一個IIS應用程序映射和創建多個虛擬目錄所產生的IIS網站。 WSS還拷貝一個Global.asax文件和Web.config文件的存取IIS Web站點的根目錄。
WSS的必須添加一個IIS應用程序映射到每個Web應用程序，以確保每一個最初傳入的請求路由到ASP.NET運行。請記住，ASP.NET的唯一的註冊與著名ASP.NET文件擴展名，如應用程序映射請求的默認配置的。aspx，ascx，。ashx的，和。asmx文件。所以，WSS的配置主機的IIS應用程序映射通配符路由網站所有傳入請求，包括那些與非的請求，如ASP.NET擴展到Aspnet_isapi.dll.doc和.docx文檔和.pdf。
由於針對每個請求一個Web應用程序是通過aspnet_isapi.dll的路由，請求得到充分ASP.NET中初始化。此外，它的處理行爲是可以控制使用自定義HttpApplication對象和配置元素添加到Web.config文件。在WSS團隊使用標準的ASP.NET技術，以延長使用多種自定義組件的HTTP請求管道，如下圖所示：
首先，你可以看到，WSS的配置，每個使用SPHttpApplication類的自定義HttpApplication對象Web應用程序。請注意，這個類是在WSS的系統組裝Microsoft.SharePoint.dll的部署。 WSS的集成通過創建自定義的global.asax在Web應用程序，從SPHttpApplication繼承根文件此自定義應用程序類。
<@Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" >
除了包括自定義HttpApplication對象，在WSS建築使用自定義的HttpHandler和自定義HTTP模塊。這兩個WSS的特定組件集成到HTTP請求管道爲Web應用程序使用標準的條目在web.config文件中。檢查下面的XML片段，它是從標準的web.config採取文件通過一個WSS 3.0 Web應用程序使用。
<configuration>
<system.web>
<httpHandlers>
<remove verb="GET,HEAD,POST" path="*" />
<add verb="GET,HEAD,POST" path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, ..." />
</httpHandlers>
<httpModules>
<clear />
<add name="SPRequest" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, ..." />
<!-- other standard ASP.NET httpModules added back in -->
</httpModules>
</system.web>
</configuration>
在WSS團隊成員創造了他們自己的HttpModule名爲SPRequestModule初始化的WSS運行環境的各個方面。你可以看到標準的WSS的web.config文件配置SPRequestModule，以便它是第一個響應HTTP模塊應用在HTTP請求管道的ASP.NET級別活動。如果您檢查了一個WSS Web應用程序的web.config文件，你會發現WSS的加回在從ASP.NET框架標準的HttpModule組件幾個處理的事情，如輸出緩存和各種類型的身份驗證。標準WSS的web.config文件也註冊一個HttpHandler名爲SPHttpHandler並配置與路徑“*它”。這使WSS來提供，作爲所有傳入請求單一的端點SPHttpHandler類。正如你所看到的，WSS的架構是透過HTTP請求延長管道。這使得WSS來充分地利用ASP.NET框架的基本能力，同時還對每個請求所針對的是Web應用程序的監控。
Standard web.config File for a Web Application
在本章上一節中，你看到了一個Web應用程序的Web.config文件包含標準的ASP.NET配置元素。然而，WSS的更進一步擴展標準的ASP.NET web.config中的自定義SharePoint部分文件格式。檢查下面的XML片段，顯示在configSections元素由ASP.NET擴展的需要配置信息的web.config文件共享點段和元素。
<configuration>
<configSections>
<sectionGroup name="SharePoint">
<section name="SafeControls" type="..." />
<section name="RuntimeFilter" type="..." />
<section name="WebPartLimits" type="..." />
<section name="WebPartCache" type="..." />
<section name="WebPartWorkItem" type="..." />
<section name="WebPartControls" type="..." />
<section name="SafeMode" type="..." />
<section name="MergedActions" type="..." />
<section name="PeoplePickerWildcards" type="..." />
</sectionGroup>
</configSections>
<SharePoint>
<SafeMode />
<WebPartLimits />
<WebPartCache />
<WebPartControls />
<SafeControls />
<PeoplePickerWildcards />
<MergedActions />
<BlobCache />
<RuntimeFilter />
</SharePoint>
</configuration>
是的配置在SharePoint部分嵌套是由各個組成部分WSS的運行時讀取的元素。在SharePoint內每個元素嵌套節，有一個的configSections元素定義了配置類部分元素用於閱讀本在運行時的信息。這可以使運行的WSS的各個組成部分閱讀本WSS的具體配置信息，在處理請求。您會看到整本書的幾個發展技術，要求增加或改變在Web.config文件的共享點部分元素。
SPVirtualPathProvider
超過ASP.NET WSS的優勢之一是它能夠提供和定製網站的網頁內，無需進行任何正面的本地文件系統前端Web服務器的變化。這種WSS的能力，提供和定製網頁是通過存儲成爲可能定製的版本。裏面的內容數據庫aspx文件和。主文件和檢索時，需要處理傳入的頁面請求他們的需求。
考慮一個簡單的例子是如何工作的頁面定製在WSS。假設你想修改的主頁（Default.aspx的特定網站）通過使用Microsoft Office SharePoint設計HTML佈局。當您修改和保存網頁使用SharePoint Designer中，WSS的寫到自定義網頁的全部內容定義的內容數據庫。這一點後，當相同的頁面被請求時，WSS的必須檢索本從內容數據庫自定義頁面定義的內容，並通過它傳遞給瞭解析ASP.NET運行。我們現在解釋的建築細節，使這成爲可能。
ASP.NET 2.0中引入一種新的可插拔組件類型作爲一個虛擬路徑提供衆所周知的。背後的虛擬路徑提供者的想法是，它抽象的詳細資料，網頁文件存放在遠離ASP.NET運行庫。通過創建自定義虛擬路徑提供者，開發人員可以編寫一個自定義組件，檢索ASP.NET文件類型，如。aspx和。主文件，從遠程位置，如Microsoft SQL Server數據庫。一旦虛擬路徑提供檢索的。aspx頁的內容，可以通過它傳遞給瞭解析ASP.NET運行。
在WSS團隊創建了一個虛擬路徑提供名爲SPVirtualPathProvider即到每一個Web應用程序集成。該SPVirtualPathProvider類是集成到ASP.NET處理的SPRequestModule基礎設施的要求。更具體地說，SPRequestModule組件包含代碼，以註冊使用ASP.NET框架，正如它的工作SPVirtualPathProvider類初始化一個Web應用程序。圖2-6顯示了圖，描繪了SPVirtualPathProvider作用。
正如你所看到的，SPVirtualPathProvider可以檢索從ASP.NET頁的內容，如數據庫的Default.aspx，文件，然後它傳遞到ASP.NET頁分析器。該SPVirtualPathProvider類作品連同其他類命名SPPageParserFilter提供處理指示ASP.NET頁分析器。例如，SPPageParserFilter組件控制是否ASP.NET頁分析器編譯成一個程序集DLL中的ASP.NET頁或是否工序，不編譯模式下使用ASP.NET 2.0中引入的頁面。在下一章中，您將看到如何添加到web.config文件，告訴SPPageParserFilter如何處理進入的網頁。
在SPVirtualPathProvider組件起着WSS的整體架構的重要作用。正如你所看到的，它提供的頁面定製支持的基礎。它也支持一個重要的優化，頁面重影，這是一個允許一個WSS農場規模出網頁上的一個農場內的所有網站數以萬計的關鍵因素衆所周知的。讓我提供了一個快速的例子來說明頁面鬼影工作。
假設你剛剛創建的100個新的WSS的空白網站從網站模板。如果這些網站都需要有其主頁（Default.aspx的）定製版本，將它仍然是有意義的複製到數據庫中的內容完全相同的頁面定義文件100倍？對這個問題的答案顯然是否定的。幸運的是，在一個WSS站點的網頁，例如Default.aspx的是基於網頁模板，在前面的文件系統前端Web服務器現場。頁面模板使用在一個網站的背景下，提供網頁的實例，例如網頁是通過像http://litwareinc.com/default.aspx特定URL訪問。
當一個頁面實例最初是從一個頁面模板置備，WSS的不需要的內容存儲在數據庫中的副本，因爲WSS的可以加載頁面模板從Web服務器的文件系統，並用它來處理任何請求非自定義頁面的一個實例。因此，可以說該網頁鬼影描述了使用頁面模板處理對非自定義頁面的請求採取行動，例如加載到內存，從前面的文件系統前端Web服務器。
Page ghosting是有價值的，因爲它無需轉讓從SQL Server與數據庫的內容，前端的電腦頁面定義文件的內容Web服務器計算機。Page ghosting還能夠處理使用單頁模板被編譯到一個程序集加載DLL和在IIS工作進程到內存中只有一次每個Web應用程序的不同地點的成千上萬的網頁上。這些優化都是在高流量環境中運行的數以千計或數以萬計的網站WSS的可擴展性的關鍵因素。
當您修改網頁並保存它的一個內容數據庫中的自定義版本使用SharePoint Designer，您消除頁面重影的可能性。相反，必須提供SPVirtualPathProvider檢索內容數據庫頁面的定製版本，如圖2-6所示。爲此，自定義頁面有時被稱爲unghosted的網頁。
現在，您知道如何WSS的過程爲幻像和unghosted網頁的請求，您應該遵守的重要作用，是由SPVirtualPathProvider作用。這是SPVirtualPathProvider，決定是否被請求的網頁已被定製。該SPVirtualPathProvider作出決定是否要處理的頁面作爲幻影或unghosted頁面。此外，所有的網頁鬼影方面unghosting是隱藏的ASP.NET運行時，代表着增值WSS的層面。