SharePoint基礎之七- SharePoint基礎架構與ASP.NET的整合

隨著你慢慢的建立WSS跟ASP.NET如何整合到一起的理解, 你就會明白WSS的高層次設計的目標了, 那就是為ASP.NET架構增加實用價值. WSS在ASP.NET之上, 為經常地, 持續地建立, 更新,刪除網站這樣的環境, 增加了重要的實用價值. WSS還在ASP.NET上, 增加了網站元素建立的一個維度, 允許網站管理員在網站的上下文中, 很快地建立頁面, 列表, 還有文件庫.

 

WSS在IIS網站的層次上與ASP.NET進行整合. 每個你想要用它來寄存WSS網站的IIS網站都必須經過一次轉換過程, 在這次轉換過程中, IIS網站將會被設定為一個用WSS術語說叫做Web Application的東西. 這個轉換過程涉及到在IIS metabase中添加入口, 還要添加一個WSS相關的web.config檔案到IIS網站的根目錄下. 一旦轉換過程完成, WSS就擴充了IIS和ASP.NET的路由架構, 擴充的方式是使用WSS運行時來對請求進行合適的路由操作.

我們接下來要討論WSS應用程式是如何被配置的. 然而, 在你深入這些細節之前, 我們希望你能夠做一個重要的觀察. 特別地, 從可管理能力和可衡量能力的角度, 我們希望你考慮一下Web Applicaiton是如何作為一個整體嵌入到WSS架構中的.

 

WSS Web Application的建立是一項重要的需要場級管理員權限的管理工作. 建立一個web application需要在每一個web前端伺服器上進行一系列重要的對檔案系統和IIS metabase的更改. 在web場環境下, 這些修改會由WSS運行時來自動地鏡像到場中其他的web前端伺服器上. 建立Web application的步驟僅在初始安裝和配置WSS的時候才需要.

 

一旦一個Web application建立完畢, 那麼在就沒必要在建立, 更新, 刪除網站和網站集的時候再去觸碰前端伺服器上的檔案系統和IIS的metabase了. WSS架構使得僅僅通過在Configuration database(設定資料庫)和Content database(內容資料庫)中添加一些資料就可以簡單地建立新的網站和網站整合為可能. 就是WSS架構的這個方面讓WSS在易管理性和易建立性上遠遠地超出了ASP.NET. 這裡添加的易管理性的優勢在Web場環境下更是特別明顯.

 

Web Applications

===============

建立Web Application有兩條主要的途徑, 一個是通過WSS Central Administration(WSS管理中心),  另一個是通過運行STSADM.EXE命令列工具. 首先, 你通過轉換一個已經存在的IIS網站來建立一個web application. 你還可以從頭建立一個新的web application, 讓WSS來為你在後台建立新的IIS網站. 任何一種情況下, WSS都會在IIS網站下添加一個IIS應用程式對應, 還要添加一些虛擬目錄. WSS還會拷貝global.asax檔案和web.config檔案到IIS網站的根目錄下.

 

WSS必須為每一個web application添加IIS應用程式對應, 目的是為了讓所有的, 任何一個到來的請求都會初始經過ASP.NET的路由. 記住, 預設的ASP.NET的配置僅僅註冊了針對大家都熟悉的ASP.NET的檔案尾碼名(.aspx, ascx, .ashx, 和.asmx)的應用程式對應. 所以, WSS配置使用一個*號萬用字元來配置宿主IIS網站, 來讓所有的請求都經過aspnet_isapi.dll的處理, 這樣就把非ASP的檔案尾碼諸如.doc, .docx, 和.pdf也都讓ASP.NET來處理了.

 

因為所有的指向web application的請求都被路由經過aspnet_isapi.dll, 所以請求就會完全地用ASP.NET上下文來初始化. 進一步, 請求的處理行為可以被WSS定義的HttpApplication對象來控制, 並且配置元素也添加到了web.config檔案中. WSS團隊使用標準的ASP.NET技術, 通過使用幾個自訂的組件, 如, 擴充了HTTP Request Pipeline.

首先, 你能看到WSS配置每一個web application, 通過使用SPHttpApplication類, 設定了自訂的HttpApplication對象. 注意這個類是在WSS系統的程式集Microsoft.SharePoint.dll中部署的. WSS通過在Web Application的根目錄下建立自訂的global.asax檔案, 來整合這個自訂的應用程式類, web application類繼承自SPHttpApplication.

<%@ Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

 

除了包括自訂的HttpApplication對象, WSS架構還試用了一個自訂的HttpHandler和一個自訂的HttpModule. 這兩個WSS相關的組件通過在web.config檔案中添加標準的入口而被整合到HTTP Request Pipeline 當中. 檢查下面的xml片段吧, 它是從WSS3.0 Web Application使用的標準web.config中截取的.

<?xml version="1.0" encoding="utf-8" ?><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, 所以, 它是第一個在ASP.NET的HTTP Request Pipeline中的響應應用程式層事件的HttpModule了.  如果你檢查WSS web application的web.config檔案, 你會看到WSS在後面還添加了許多ASP.NET架構中的標準HttpModule, 用來處理如輸出緩衝和認證方式的module.

 

標準的WSS web.config 檔案還註冊了一個叫做SPHttpHandler的HttpHandler, 並且給它配了一個"*"作為路徑. 這允許的WSS使用SPHttpHandler作為所有到來的請求的唯一終點.

 

Web application的標準web.config檔案

===============

前面的部分裡, 你看到了包括標準ASP.NET配置元素的用於web application的web.config檔案. 然而, WSS在擴充標準ASP.NET的web.config檔案上還做了很多, 它還添加了自訂的SharePoint的section. 檢查下面的XML片段, 它展示出了web.config檔案的SharePoint部分, 還有在configSection中被ASP.NET

需求的用於擴充配置資訊的元素.

<?xml version="1.0" encoding="utf-8" ?><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特定的配置資訊的讀取成為可能.

 

SPVirtualPathProvider

==================

WSS強於ASP.NET的一個方面在於它能夠在網站中建立和定製化頁面, 而不需要對Web前端伺服器上的本地檔案系統做任何改變. WSS的這個建立和修改頁面的能力是通過兩方面實現的: 1. 在內容資料庫中儲存定製化的版本的aspx檔案和master檔案; 2. 在他們被進來的請求索要的時候拿到這些檔案.

 

考慮一個簡單的WSS中的頁面定製化是如何工作的吧. 想象你需要在Microsoft Office SharePoint Designer中修改某個網站的首頁(default.aspx)的HTML布局. 當你使用SharePoint Designer修改並儲存頁面的時候, WSS將整個的定製化了的頁面的內容寫入到內容資料庫中. 在那之後, 當同樣的頁面被請求時, WSS必須從內容資料庫中得到這個被定製化過的頁面的定義, 然後交給ASP.NET運行時去解析. 我們現在解釋一下始這個過程成為可能的架構細節.

 

ASP.NET 2.0引入了一個可插入的組件, 叫做virtual path provider. 在virtual path provider背後的想法是讓它把頁面儲存在什麼地方從ASP.NET運行時中抽象出來. 建立一個自訂的virtual path provider, 研發人員就可以書寫一個自訂的組件來從遠端地址(比如說Microsoft SQL Server資料庫)獲得ASP.NET的檔案類型(比如aspx和master檔案). 一旦一個virtual path provider 得到了一個aspx頁面的內容, 他就把內容傳遞給ASP.NET運行時去解析.

 

WSS團隊建立了一個叫做SPVirtualPathProvider的virtual path provider, 並把它整合到每一個web application當中. SPVirtualPathProvider 類通過SPRequestModule整合到ASP.NET的請求處理基礎架構中. 更具體地說, SPRequestModule組件中包含代碼用來將SPVirtualPathProvider註冊到ASP.NET架構中, 因為這是SPRequestModule在初始化Web application時候的工作. 展示了SPVirtualPathProvider的角色.

 

正如你所看到的, SPVirtualPathProvider能夠從內容資料庫中取到一個ASP.NET的分頁檔, 然後傳遞它給ASP.NET的頁面分析器.  SPVirtualPathProvider與另一個叫做SPPageParserFilter的類一起工作, 為ASP.NET頁面分析器提供處理指示. 比方說, SPPageParserFilter 組件能夠控制ASP.NET頁面分析器是否將ASP.NET頁面編譯成程式集DLL, 要麼就是用ASP.NET 2.0引入的非編譯模式. 以後, 你將會看到如何在web.config中添加入口來告訴SPPageParserFilter去如何處理頁面.

 

SPVirtualPathProvider組件在整個WSS架構中扮演著的一個關鍵的角色. 正如你看到的, 它為支援頁面定製化提供支援. 它還支援一個重要的叫做page ghosting的最佳化, 這個page ghosting是允許WSS場向外擴充出成千上萬個頁面的關鍵因素. 讓我提供一個快速的例子, 來說明page ghosting是如何工作的吧.

 

想象你剛剛用空白網站模板建立了100個新的WSS網站. 如果這些網站中沒有一個需要自訂版本的首頁(default.aspx), 那麼你拷貝這些頁面的精準定義到內容資料庫中100次還是合理的麼? 這個問題的答案顯然是No. 幸運地, WSS中的頁面如default.aspx是基於存在於web前端伺服器的檔案系統中的頁面模板的. 頁面模板被用來在網站的上下文中建立頁面的執行個體, 比如說通過某個特定URL訪問的頁面, 就像http://litwareinc.com/default.aspx.

 

當一個頁面執行個體被從頁面模板中建立出來的時候, WSS不需要在內容資料庫中儲存這個頁面的一個拷貝, 因為WSS可以從WEB前端伺服器上的檔案系統中載入起頁面模板, 然後使用這個模板來處理任何指向未被自訂的頁面執行個體的請求. 所以, 你可以說page ghosting描述了一種處理指向未被定製化的頁面的請求的行動, 該行動通過在前端伺服器上把頁面模板載入到記憶體中來完成.

 

Page ghosting是有價值的, 因為它減少了從SQL Server電腦的內容資料庫中拿到檔案定義的內容, 再傳遞給Web前端伺服器的需求. page ghosting還使得使用一個編譯為DLL的並載入到IIS工作者進程的記憶體中的頁面模板來處理上千個不同網站的首頁的處理過程成為可能, 並且每一個Web application來說只用處理一次. 這兩種最佳化在運行成千上萬個網站的高負載環境下, 對於提高WSS的可擴充性都是重要的關鍵因素.

 

當你使用SharePoint Designer修改一個頁面, 然後儲存定製化版本的頁面到內容資料庫中的時候, 你就消除了使用page ghosting的可能性. 作為替代, 提供給你的SPVirtualPathProvider 必須從內容資料庫中取回自訂版本的分頁檔, 就如同展示的一樣. 就衝著這個原因, 定製化過的頁面有時候也叫做unghosted pages.

 

現在既然你已經理解了WSS是如何處理請求ghosted和非ghosted的page的了, 那麼你應該觀察一下SPVirtualPathProvider扮演的角色了. 是SPVirtualPathProvider決定請求的頁面是否是被定製化過的. SPVirtualPathProvider做出決定, 是否按照處理ghosted page的方式來處理請求. 更進一步地, 所有的page ghosting 和unghosting都對ASP.NET運行時隱藏了, 表現為WSS的附加價值的一個維度.

 

 

學友文章後記: 這是本系列中最最重要的一片文章. 對於理解SharePoint的架構至關重要, 請要瞭解SharePoint的讀者仔細閱讀. MSDN上有部分文字(英文的)的節選, 作為介紹SharePoint基礎架構的文章.