1、使用Web存儲系統設計知識管理解決方案 Walson Lee Microsoft Corporation 2000年10月 摘要：本文概述了使用 Web存儲系統開發高效的知識管理解決方案的設計過程。 目錄 簡介 Microsoft ? Exchange 2000 Server 是引入一種新的稱為 Web 存儲系統的存儲技術的第一個 Microsoft 產品。 Microsoft 的 Web 存儲系統提供許多新的開發功能，例如 Web 存儲系統事件與窗體、 工作流引擎、 內容索引以及搜索文件夾。 這些功能特別適用于知識管理 (KM)解決方案。但是，KM解決方案的開發人員 開始時需要經過一個學習過

2、程， 才能理解這些功能， 并逐個理清 Web 存儲系統提供的許多個設計選項的作 用。本文著重講解了有關開發 KM 解決方案的設計方面的知識，并討論了最佳方法、設計模式以及設計過 程中的考慮因素。其中展示了基于服務的應用程序模型和基于 Microsoft 解決方案框架 (MSF) 的設計過 程。這個設計過程是專為使用 Web 存儲系統建立 KM 解決方案量身定做的。 設計過程包含了概念設計模型、 邏輯設計模型以及物理設計模型。本文重點講述針對 Web 存儲系統的物理設計模型的設計考慮因素： ? 用戶服務 數字儀表板和 Web 存儲系統窗體 ? 業務服務 工作流和事件設計 ? 數據服務 存儲架構設

3、計 ? 安全模型 ? 性能 ? 可伸縮性與可用性 ? 分類的實現 ? 與業務范圍 (LOB) 應用程序集成 本文旨在提供一種設計基于 Web 存儲管理系統技術的 KM 解決方案的正確方法。 它所面向的讀者是 KM 解 決方案的構建或設計人員。其他開發人員也能從本文闡述的基本設計概念中獲益。 Web 存儲系統用作開發平臺 Web 存儲系統是 Microsoft 為體現它的 “不受限制的知識工作者” 理念而宣布的四項創意之一。 這些創意 的主要目的是消除當今知識工作者面臨的妨礙相互協作的障礙。Web 存儲系統將文件系統、 Web 以及協作 服務器的功能組合到一個位置，以便存儲、訪問、管理信息以及建

4、立和運行應用程序。Web 存儲系統中的 每一項都是可用 URL 尋址的，并且完全支持半結構化數據，如文檔、聯系人、消息、報告、 HTML 文件以 及 Active Server Pages (ASP)。 Web 存儲系統提供與 Microsoft Office 2000 的高性能集成。它為信息 管理(包括一致搜索和數據分類)建立了一個平臺。 圖 1 闡釋了 Web 存儲系統的編程模型。從圖中可看出它支持不同的協議、數據訪問方式和事件模型。對 Web 存儲系統的數據訪問包括對 OLE DB 和 ActiveX ? Data Objects (ADO)的支持。 Web 存儲系統還提供 通過 HTT

5、P 協議進行訪問的功能。(英文)增強了這一功能，使它可支持另一組協議命令。此外，該存儲 系統本身還支持可擴展標記語言 (XML) 。 Web 存儲系統還包括一些新的功能，如 Outlook ?Web 訪問、 Web 存儲系統窗體、事件、工作流、內容索 引、搜索文件夾以及即時消息傳送。這些功能為開發人員建立 KM 解決方案帶來了很大的靈活性，也更容 易實現。有關 Web 存儲系統的詳細資料，請參見 Exchange 2000 SDK 以及(英文)。 圖1. Web存儲系統編程模型 建立KM解決方案 對企業中的每一個業務問題，知識管理（KM）通過選擇解決問題的正確模塊而不斷更新。根據不同的組織 方

6、式和技術，每一模塊都有自己的特性。下面列岀了一些典型特性： 擴充客戶/合作伙伴/雇員的知識 快速學習并重復利用知識 提高知識產權的價值 為產品和服務提供特別的附加值 建立新知識 共享工作過程和質量革新的知識 A Intranet 圖2. KM啟用模塊 有兩項技術是所有KM系統的基礎：完全Intranet和消息傳送及協作。這些技術構建的基礎結構支持對 信息進行有效傳輸、架構、訪問和協同管理。 其余的KM啟用模塊把這一基礎結構擴展成一個復雜的KM系統，該系統包含各種服務（如內容管理、各 種信息傳遞以及數據分析等）。其它服務（如數據跟蹤、工作流過程）也包含在該系統和這些模塊中。 實現KM啟用模塊可以

7、是即插即用的。雖然某些模塊得益于先前某一模塊的實現，仍可按與要開發的特定 業務案例之間的相對順序選擇它們。例如，象視頻會議這樣的實時協作服務，可以很容易地包含在必備技 術的上層，但要通過內容管理模塊中提供的元數據服務才能得以增強。 鼻糾m . Aft 3 % 時入口 軸比L具 1:工 時a 業勞轉褪1 - 圖3.可能的知識管理平臺分層結構 Microsoft 當前的 KM 平臺是 Microsoft BackOffice ? 系列。它提供的服務能夠：建立 KM 先決條件（消 息傳送及協作和完全 Intranet ），通過實現所有的 KM 啟用模塊（內容管理、團體和組、入口和搜索、數 據分析以及

8、實時協作） 將它們擴展成 KM 解決方案。除了這些服務， BackOffice 還提供與先前信息或知識 源集成和連接的接口。 在未來的幾個月內， Microsoft 將發布 .NET Enterprise Server ，它包含 SQL Server ? 2000 、 BizTalk ? Server 、 Commerce Server 2000、 Host Integration Server 2000、 Internet Security 當前URL所表示的項（例如：ExpenseForm.htm、 ECOform.ASP）。 處理從 HTTP 請求報頭讀取的信息， 并與存儲在 Brows

9、ecap.ini 中瀏覽器的信息相比較， 就可以得到瀏覽 器的功能信息。 ISAPI DLL 使用與窗體注冊表信息最佳匹配的比較來確定顯示哪一個窗體。 有關 Web 存儲系統窗體的詳細信息，請參考 Exchange 2000 SDK 。 設計業務服務的最佳方法 正如上文所述，業務服務是一個應用程序邏輯單元，它控制執行業務規則的先后順序，保證所執行操作的 事務完整性。以下是一組使用 Web 存儲系統設計業務服務的最佳方法： 通過使用方案確定關鍵業務過程 在邏輯設計階段，開發小組應檢查他們在概念設計階段收集的方案以確定業務過程，如文檔批準過程或內 容變換過程。 確定實現機制 在物理設計階段，開發小

10、組需要確定這些業務過程最合適的實現機制。有四個基本選項：工作流引擎、事 件接收器、 COM+ 組件和腳本（客戶端或服務器端腳本）。使用腳本的方法會造成一些困難，如代碼不易 維護以及腳本的局限性。因此，我們建議采用前三種方法。以下是確定實現方法的一組指南： ? 如果業務過程符合以下情況，則使用工作流： ? 涉及多用戶和多資源。 具有復雜過程，如批準或業務驗證過程 如果岀現以下情況，則使用事件接收器: ? 只涉及少量的用戶或資源。 ? 驗證過程簡單。 ? 具有整個存儲區范圍內的事件。 ? 具有定時器事件。 如果使用 Web存儲系統進行的大多是讀取操作而不是更新操作，且不涉及工作流，則使用COM+

11、組件。 設計數據服務架構的最佳方法 正如上文所述，數據服務是提供最低提取可見級別的應用程序邏輯單元，用于操作數據。數據服務維護作 為公司資產的永久和非永久數據的可用性和完整性。這一部分我們將討論 Web存儲系統架構設計，下一部 分討論文件夾結構。 首先，什么是架構？對于建立在 Web存儲系統技術基礎上的整個物理設計模型來說，為什么架構設計 至關 重要？架構一詞指的是一種定義和組織數據（有時稱為元數據）的方法。在結構化查詢語言（SQL）關系型 數據庫中，架構包括所有的表定義和列定義，以及其它信息（如索引和觸發器）。對于存儲區，我們將架 構設計的重心放在內容類及與其相關聯的屬性集方面。架構設計對整

12、個KM解決方案是否成功有直接影響， 尤其是在性能和可擴展性方面。架構設計通常是定義數據服務模型的第一步。許多設計的考慮因素和決策 都要依賴架構設計。下面一段是對Web存儲系統架構的簡要介紹。 Web存儲系統可用于為您的應用程序定義架構。Web存儲系統架構是以內容類為中心的。內容類為存儲區 中的項/實例定義架構類，是屬性集的邏輯容器。 為您的應用程序創建架構定義時，要定義自定義內容類及 相關的屬性。Web存儲系統含有大量預定義的內容類和屬性。定義自己的自定義內容類時，您可以使用或 擴展（子類）某一預定義內容類。其中包括（但不僅限于）表2.所列的內容類。 表2.內容類 內容類 說明 urn:con

13、tent-classes:item 存儲區中各項的基類 urn:content-classes:message 消息的基類 urn:content-classes:calendarmessage 會議請求和響應的基類 urn:content-classes:appointment 約會的基類 urn:content-classes:person 聯系人項的基類 urn:content-classes:folder 文件夾的基類 urn:content-classes:document Microsoft Office 文檔的基類 Web存儲系統架構的一個長處是它們為架構感知的應用程序和工具提供

14、了一種方法，可用來查找出適用于 某一特定應用程序的內容類和屬性的名稱。 與某一特定應用程序相關的架構信息是通過文件夾的架構范圍來控制的。文件夾的架構范圍是一組按某特 定順序遍歷的文件夾，它們包含架構定義項。通過在Web存儲系統(其中存儲您的架構信息)中定義文件 夾的列表，你可以逐個文件夾地擴展架構。范圍可以很簡單，只包含全局架構文件夾；也可以比較復雜， 包含一個很大的文件夾 URL的列表。 還需要查看以下兩個屬性來定義架構范圍，這兩個屬性對整體架構設計一尤其是文件夾結構 一也很重 要，我們將在下一部分討論這一主題。 ? schema-collection-ref (SCR):這一屬性是一個文件

15、夾的 URL，將在該文件夾中查找內容類和屬 性定義。這是搜索架構定義項的第一個文件夾，并且總是文件夾架構范圍中的第一個文件夾。如 果未設置這個屬性，則默認為存儲區的non_ipm_subtree/Schema 文件夾，其中包含 Web存儲系 統的默認架構定義項。 ? Baseschema :這一屬性是個多值字符串，包含一個或多個文件夾的URL。通過確定包含架構定 義項的其它文件夾，可以擴展某文件夾的架構范圍。 除了定義自定義內容類之外，定義自定義屬性是架構設計的另一個重要方面。雖然Web存儲系統提供許多 預定義的屬性，您可以為每一項存儲任意數量的其它屬性；這些屬性就稱為自定義屬性。您還可以對每

16、一 項定義一組不同的自定義屬性。 自定義屬性與它的關聯項一起保存。檢查項時可以按名稱發出請求。如果使用Exchange OLEDB提供程序 或ADO直接綁定到項上，或通過HTTP/WebDAV協議發出一個0深度的PROPFIND命令，Web存儲系統將 返回該項的所有自定義屬性。對于所有深度為1的項屬性，自定義屬性對 SQL “SELECT *”語句或 PROPFIND命令都是不可見的，除非這些屬性被定義為項的內容類的一部分。因此，要使架構感知的應用程 序能識別您的屬性，必須把屬性和內容類的定義添加到應用程序文件夾的架構范圍中。 下面我們對一些通用的架構設計指南作一總結。如果您不熟悉URN、UR

17、I和URL這些詞，在繼續之前建議 您看一看下面的定義。 URI、URN 和 URL 統一資源標識符(URI)就是一個采用一定格式的字符串，它可用來唯一地標識一個資源。URI可以是一個 統一資源定位符(URL)或一個統一資源名稱(URN)。 ? URL對定位所標識資源所需的底層協議進行編碼。 ? 而URN則與位置無關，而且與定位所標識資源要使用的協議或機制也毫無關系。 HTTP URL，語法如下: URL開頭帶有一個標識協議的前綴，接著是一個針對協議的字符串。對于 http:/ : ? 是服務器的 IP 地址， 是服務器偵聽的 TCP 端口號， 是在 HTTP 請求中作 為請求 URI 傳遞的絕

18、對 URI 。可選的 對應于查詢字符串后綴，即用 & 分隔的關鍵字 / 值對的 列表。只有 URL 的主機部分是必須的。如果未指定端口，默認為端口 80 ；如果未指定路徑，請求 URI 將 為“/ ”。 URN對建立現代的、適宜Internet的應用程序是至關重要的，但人們對它還遠遠不夠熟悉。目前還沒有 一種通用的方式來間接訪問URN以查找它所標識的資源。URN的語法結構保證了 URN跨多個組織的唯一 性。其語法如下所示： urn: : 是命名空間標識符， 是命名空間特定的字符串。如果要標識與位置無關的內容，建議您使 用 URN 機制。對于還需要包含位置信息的標識符，則建議使用 URL 機制。

19、 架構設計指南 架構設計指南的內容如下： 使用和定義命名空間 (URN) 使用命名空間定義屬性和內容類是一種好辦法。命名空間的作用包括： ? 有助于確保屬性和類的名稱是全局唯一的；即，解決識別和沖突的問題。如果您有多個應用程序 在同一時間部署， 或者獨立軟件開發商 (ISV) 在一個大型組織中部署他們的應用程序時， 這一點 都是特別重要的。 ? 指示“擁有”屬性或類定義的個體或組織。 在隨 Exchange 2000 提供的預定義屬性和類中，您會發現有許多不同類型的命名空間： ? urn:schemas:httpmail: ? urn:schemas-microsoft-com:exch-da

20、ta: ? urn:schemas-microsoft-com:office:office ? 第一個示例是一種通用的廣為接受的命名空間，目的是為了增強各種架構感知應用程序間的互操作性。 urn ： 接下來的兩個是專用 URNo如果您希望為您的應用程序創建一個類似的命名空間，您可以創建 schemas-mycompanysdomain-com:myapplication:。 第二個和第三個命名空間的差別就在于：第二個命名空間的結尾有一個命名空間分隔符而第三個命名空間 沒有。如果命名空間以分隔符“ :”或“ / ”結尾，將創建屬性或內容類名稱，且屬性名附于命名空間后。 例如，第二個命名空間中的一

21、個屬性是 urn ： schemas-microsoft-com:exch-data:ismultivalued 。 如果命名空間不以分隔符結尾（如第三個示例），則該命名空間中將創建屬性名，命名空間與屬性名之間 有一個符號“ #”。例如，第三個命名空間中的一個屬性是urn ： schemas-microsoft-com:office:office#Author 。 最后一個命名空間示例顯示如何將 URL 用作命名空間。您應當從您擁有或已注冊的 URL 中選擇基于 URL 的命名空間。這將有助于保證命名空間的唯一性。 URL 用作命名空間時，最后一個分隔符為字符“ / ”。 不應向您不擁有的命名

22、空間中添加屬性或內容類。例如，向 或 DAV: 命名空間添加屬性就不好，而應當 為您的內容類和屬性創建自己的命名空間。 進行屬性定義 Web 存儲系統本身對屬性名稱中可使用哪些字符沒有特殊的限制。但是，最好還是遵守以下一些約定： ? 應當使用命名空間來創建屬性并加上一個標識符（如上文所述）。例如， urn:schemas-sample-com:engineering:eco. ? 屬性應當是格式正確的 URI 。 ? 屬性名稱中不應有空格，因為 XML 不支持在元素名稱中使用空格，因此HTTP-DAV 也不支持。 定義自定義內容類 在定義了這些自定義屬性之后，下一步就是定義您的自定義內容類。首

23、先，您需要為應用程序選擇一個文 件夾，用來存儲架構信息。您可以將這些信息存儲在您的應用程序數據所在的同一文件夾中，但我們強烈 建議您使用一個不同的子文件夾，我們稱之為架構文件夾。如果您在正定義的架構不是針對某一個應用程 序的，您可以在相關的公共存儲區里的高層架構文件夾中定義它。 存儲架構定義的位置和組織架構定義的方式由您決定。但是，在下一部分中，我們將推薦一組方式，指導 您如何組織文件夾結構以及如何確定對一組特定應用程序數據應用哪一個架構定義。 下面的關系圖闡釋了使用一個 Exchange 2000 SDK 工具（即： Web 存儲系統架構設計器）來自定義內容類 的一個示例。我們建議您使用該工

24、具或類似工具來定義自定義內容類的定義和屬性定義。 圖7.示例：架構設計 考慮內容類的繼承性 您當然可以從頭開始定義一個全新的內容類。不過，多數內容類都可以擴展（“繼承”）現存的內容類。 擴展內容類意味著 已擴展的（派生的）內容類實例的所有屬性也存在于擴展中的（基本的）內容類實例中 這一概念與C+這樣的面向對象（00）的編程語言中類繼承的概念相似。 圖10顯示一個簡單的繼承方案。擴展文檔類意味著任何可在文檔類實例上執行的代碼或操作都可以在 expensereport 類實例上執行。 圖8.簡單內容類繼承 圖9.帶有多個繼承關系的內容類 內容類也可擴展為多個內容類。在圖11中，我們還能看到一個ex

25、pensereport 類，它具有totalcost 和 approvastate兩種屬性。但在這一方案中我們希望有作為文檔的一個特定類的費用報告和作為消息的一 個特定類的費用報告。因此，我們創建一個exprensereport 類來擴展該類。然后創建一個 exprensemessage 類和一個 exprensedocument類，它們自己沒有其它屬性。Expensemessage 擴 展了 expensereport 和 message ，而 exprensedocument 擴展了 exprensereport 和 document 。 現在，理解message 類的應用程序就可以理解

26、expensemessage類的一些屬性，而把其余屬性當作自 定義屬性。理解 document 類的應用程序就可以理解exprensedocument類的一些屬性。 有關架構設計的詳細信息，請參考Exchange 2000 SDK以及白皮書“ Web存儲系統架構：使用和最佳方法 指南。” Web存儲系統文件夾結構的最佳方法 Web存儲系統為設計文件夾結構提供了很大的靈活性。架構定義項可置于特定存儲區內的任一文件夾中， 并用于為您的應用程序定義架構。通過合理設置不同文件夾的schema-collection-ref 和baseschema屬 性，您可以將這些定義引入到范圍中來。 為了避免設計和管

27、理應用程序架構太過復雜，應規劃并組織好您的架構信息。例如，可以選擇在您指定為 架構文件夾的應用程序文件夾的頂層下創建文件夾。設計文件夾結構有許多種方式。以下步驟概述了這一 過程。 考慮以下各項： ?邏輯模型的復雜程度：正如上文所述，設計存儲區的架構有許多方式。在作岀最終設計決定前應 當考察所有相關的信息和設計選項。 ?物理模型的復雜程度：您應當考慮到維護復雜文件夾結構的困難程度。 ?性能影響：將在以后的部分中討論。 重復使用和共享架構。 將架構文件夾與其它類型的文件夾區分開來，例如： ? 應用程序文件夾：包括 ASP 頁面、 HTML 頁面、 Web 存儲系統窗體等等。 ? 數據（內容）文件夾

28、：包括數據項或文檔。 ? 窗體注冊文件夾：包括窗體注冊項。 通常，特定應用程序的架構定義將置于它們自己的文件夾中。將應用程序文件夾和數據文件夾分開也是一 種好方法。正如上文所述，特定文件夾的 schema-collection-ref （SCR） 和 baseschema 屬性確定架構范 圍。設計文件夾結構有許多靈活的方式。 文件夾結構的示例如下： ? 一個簡單的應用程序可以有一個包含應用程序文件（ASP、HTML 頁面）和數據項的文件夾，以及 一個架構文件夾。 ? 稍微復雜點的應用程序可以分別有單獨的應用程序文件夾、數據文件夾和架構文件夾。 ? 架構文件夾可以有不同的級別，如頂級架構文件夾包

29、含在同一根下運行的所有應用程序。也可以 采用一系列架構文件夾，每個架構文件夾通過 SCR 引用另一個架構文件夾。 定義架構文件夾。 ? 定義常用的內容類和屬性定義。 ? 定義窗體注冊。（這可能在一個單獨的窗體注冊文件夾中。） 創建架構文件夾時，您必須確定這些文件夾的范圍。即，某一給定的架構文件夾適用于哪些數據文件夾？ 任意數量的數據文件夾可以使用一個架構文件夾。反之，在多個架構文件夾中定義的架構可以應用于一個 數據文件夾。 正如上文所述， schema-collection-ref 是一個可在數據文件夾上設置的屬性，用來指示在查找相關屬性 和內容類定義時應首先搜索哪個架構文件夾。 basesc

30、hema 屬性則形成一個架構文件夾的樹形結構來搜索 架構定義。 在這個架構文件夾的邏輯樹中， 每個節點都可有許多子節點。 這個架構文件夾的邏輯樹可以 （并 且通常會）與存儲區中文件夾的物理布局不同。相對于給定的數據文件夾， schema-collection-ref 屬性 指示搜索始于哪個架構文件夾。 定義應用程序和數據文件夾。 ? 如果需要，將 schema-collection-ref （SCR） 屬性指向架構文件夾。 ? 使用 baseclass 和 expected-content-class 。 SQL 與 Web 存儲系統 這一部分我們考察 SQL 關系型數據庫和 Web 存儲系統

31、間的主要差別；討論何時使用 SQL 以及何時使用 Web 存儲系統；并提供一套指南，用于從已有的 SQL 數據庫向 Web 存儲系統移植數據。 表3闡釋了 SQL數據庫與 Web存儲系統的不同之處。注意 SQL數據庫與基于 Web存儲系統的 Microsoft 產品（如 Exchange 2000 ）有一組相同的服務。 表3. SQL數據庫和 Web存儲系統 SQL數據庫 Web存儲系統 關系型數據庫 類似于對象數據庫 結構化數據 半結構化數據 表 文件夾（以及內容類） 列 內容類和屬性 固定行 不固定行 集中于業務智能 協作 以事務為中心 以文檔為中心 數據完整性：主鍵/外鍵 無主鍵/外鍵

32、矩形數據 非矩形 觸發器 事件接收 存儲過程 無可比實體（與之類似的是事件） 如果現有的KM解決方案正在從SQL關系型數據庫中讀取數據，而這些數據是典型的非矩形半結構化數 據，您最好考慮將這些數據從 SQL移植到Web存儲系統。 請參照以下指南，將數據從 SQL移植到Web存儲系統： ? 首先，將SQL列映射到屬性，將SQL表映射到文件夾和內容類。 ? 確定表的主鍵和外鍵。根據邏輯設計模型查找與之對應的內容類。 ? 通過確定一組能生成項的唯一實例的屬性來模擬主鍵。 ? 考慮內容類的繼承性。 物理設計考慮因素 到此，我們已經討論了設計用戶服務、業務服務和數據服務的最佳方法。這一部分我們將集中討論

33、物理設 計階段針對Web存儲系統的設計考慮因素。 對每個設計考慮因素主題，我們都將介紹一些重要的概念、討論一些您可以采取的折衷措施，并列出一張 清單，供您在考慮各種選項時參考。 安全模型 這一部分中概述了 Web 存儲系統安全模型。除了使用 MAPI 客戶程序(如 Outlook )或 Windows 文件系 統 API 來控制安全設置外，您還可以使用基于 XML 的安全描述符來控制對某一項及其屬性的訪問。使用 Web 存儲系統安全描述符，您可以： ? 既可將對某一項及其屬性的訪問權授予受托者(具有憑證、正在訪問該項的人)，也可以拒絕該 受托者進行訪問。 ? 使用 Microsoft Wind

34、ows? 安全標識符 (SID) 標識受托者。 ? 設置、檢索和修改 XML 格式的描述符。 ? 使用 Microsoft Exchange OLE DB (ExOLEDB) 提供程序和 XML 格式的 HTTP/WebDAV 協議訪問描 述符。 每一項的安全描述符都通過該項的 屬性訪問。這個屬性是項的 XML 格式的描述符。 該描述符以 Exchange 2000 Server 特有的二進制格式進行物理存儲和復制，這種格式內部是基于標準的 Windows 2000 描述符 格式的。如果文件夾中的某項沒有特定的安全描述符，其父文件夾中指定的默認權限將被應用于該項。 安全描述符是一種數據結構，它

35、包含以下內容(以及其它未列出的內容)： ? 一個所有者字段，其中包含對象所有者的安全標識符 (SID) ，該對象與安全描述符相關聯。 ? 一個任意訪問控制列表 (DACL) 字段，指定誰對該對象字段具有訪問權。 ? 一個系統訪問控制列表 (SACL) ，指定系統可以審計哪些操作。 訪問控制列表 (ACL) 包含一個或多個訪問控制項 (ACE) ；每個 ACE 為安全負責人 指定訪問權限。 Windows 2000 中的安全負責人可以是一個用戶或一組用戶。 Exchange 2000 定義了一個新的安全負責人， 叫做 角色 。 角色是一個具有名稱的安全負責人(用戶或組)的集合，它可在 ACL 里

36、的 ACE 中引用。角色與 Windows 2000 組之間主要的區別在于 Exchange 安全角色是針對對象本身定義和存儲的。 也就是說不需要進行具備 特權的目錄服務操作，就可以創建這些角色，并填入成員。 對于不需要具備特定 Windows 2000 組就可以部署的應用程序，這一功能是非常重要的。安全角色在 Web 存儲系統中創建和存儲，而與 Windows 2000 目錄服務無關。對應用程序開發人員來說，安全角色具備兩 個明顯的優勢： ? 創建角色不需要使用特權的 Active Directory ? 操作 而這是分部門方案的一個關鍵要求。 ? 因為角色的作用范圍是特定的文件夾(或按文件

37、夾層次結構組織的應用程序)，因此只在文件夾 范圍內要求角色的名稱唯一。這樣，部署在一臺運行 Exchange Server 的計算機上的兩個應用程 序不需要使用不同的角色名稱和成員。 因為角色只在應用程序的設計階段才被 引用，所以它們在應用程序中只是存在，而不產生影響。程序運行 時將 評估 它們，所以應用程序開發人員可以等到部署應用程序時才加入這些角色。這樣程序開發人員就不 必為每次部署而重新編譯應用程序。正如上文所述，只要可以對文件夾和項設置 ACL,就可以在Web存儲 系統中使用角色。 在用戶對某項或文件夾（對象或父對象）定義的“角色成員”屬性中填入一個安全負責人（用戶、組或角 色）列表，

38、就可以實現安全角色。具體說來，該列表包含安全標識符（SID） ，這些 SID 代表了安全負責人 并為給定角色形成成員列表。角色 SID 與 Windows 2000 SID 不同， Exchange Server （而不是 Windows ） 擁有對它的安全控制。角色 SID 是獨立結構的，不包含任何 Windows 2000 的特定安全信息，因此可在多 個域中使用。角色 SID 將為兩種信息進行編碼： ? 屬性：角色屬性包含 SID 列表， ACE 就應用于這些 SID 。這一列表中的 SID 既可以是 Windows 2000 SID ，也可以是角色 SID 。 ? 范圍 ：該信息指示讀取

39、角色屬性的位置。 有關安全角色的詳細信息，請參考（英文）。 使用 Web 存儲系統設計 KM 解決方案的安全模型時，您應當考慮以下列出的內容： 通過概念設計模型和邏輯設計模型確定安全需求 ? 用戶 他們的角色和內容訪問需求 ? 業務需求，例如隱私和其它有關法律的需求 ? 外部訪問 “角色”一詞這里表示業務角色，而不是我們前面討論的 Exchange 角色。即在您開始定義安全模型前應 收集盡可能多的信息。 定義安全策略 ? 根據業務需求將用戶分組 ? 定義用戶角色 ? 定義應用程序安全模型 例如，誰可以創建事件或工作流 ? 定義內容安全模型 例如，項一級的安全、屬性一級的安全 ? 定義外部訪問

40、例如，防火墻和與公共密鑰基礎結構 （PKI） 的集成 性能 KM 解決方案的性能特征通常與聯機事務解決方案有顯著區別。它不是快速計算數字， 而是注重以下性能特 征： 返回搜索結果或定位具體內容的響應時間 ? 創建、分類和檢索內容的響應時間。 ? 處理業務過程（例如批準過程）的響應時間。 正如上文所述， Web 存儲系統為建立 KM 解決方案提供了強大的功能和高度的靈活性。要充分利用這些功 能，您需要注意數據訪問和處理方式對性能的影響。 要獲得最佳性能，請遵循以下指南： 頻繁執行深度遍歷搜索時使用搜索文件夾 如果您有一個分層文件夾結構，并且您的應用程序必須執行對該層次結構的深度遍歷搜索，使用搜索

41、文件 夾可以極大提高應用程序的性能。設置搜索文件夾還可以用來將大文件夾分割成較小的文件夾（根據邏輯 關系）。 例如，假設有一個 KM 應用程序，用來跟蹤記錄公司雇員生成的各種項目文檔。一開始，有成千上萬個文 檔需要跟蹤記錄， 這些文檔是按照主題在分層結構中組織的。 每一天系統中的文檔都會被頻繁添加或刪除。 在一個正常工作日中，雇員需要頻繁搜索存儲區中的所有文檔才能找到由某些作者編寫的文檔。由于搜索 必須瀏覽的記錄和文件夾的數量極大，要在整個層次結構中執行這些搜索，成本會相當高昂。在這種情況 下，這種成本高昂的、對全部記錄進行的搜索只需要執行一次，其結果可以添加到一個搜索文件夾中。 這個搜索文件

42、夾現在包含存儲區中這些作者編寫的所有文檔。 如果某些文檔被添加到存儲區 （和層次結構） 或從中刪除， Web 存儲系統會在必要的時候更新搜索文件夾。如果雇員要搜索存儲區中的文檔，只需要在 搜索文件夾中而不是層次結構中進行搜索。這樣可以搜索到所有相關記錄，但不必瀏覽整個層次結構。 使用搜索文件夾可能造成添加 / 更新/ 刪除那些用于創建該搜索文件夾的、在查詢范圍內的項時，性能會稍 有下降。這種延遲是因為每次進行這樣的操作后都必須更新搜索文件夾。因此，我們建議只有在被搜索數 據不會頻繁更新的情況下，才應在頻繁進行的查詢中使用搜索文件夾。 頻繁搜索地索引屬性 為屬性一級編制索引是為頻繁執行的搜索提高

43、性能的最好方式。如果改變用于計算那個利用了已索引屬性 的 where 子句的表達式的成本， 就可以將顯著改善搜索性能。 有關創建索引的信息， 請參考 Exchange 2000 SDK 中的“屬性索引”主題。 為屬性一級編制索引只能對在用于搜索的 where 子句中使用已索引屬性的情況下， 幫助改善搜索性能。 使 用屬性一級的索引時，應用程序從已創建索引的文件夾中執行插入 /更新/ 刪除項的操作時時，將出現輕微 的性能下降（大約每個索引 1%）。發生這種性能降低的原因是需要更新文件夾索引信息以反映更新操作。 由于存在這一問題，為了盡可能優化應用程序的性能，只應對頻繁搜索的屬性創建索引。 只在絕

44、對必要時執行“ SELECT *”操作 執行“ SELECT* ”操作要求 Web 存儲系統在架構中進行查找被搜索項，以確定要返回哪一組屬性。架構計 算的成本可能很高，而且最終成為搜索請求的總成本中很大的一部分。如果只請求需要的列，應用程序可 以避免這部分的額外成本開支。 例如，如果某項有一個關聯的自定義架構，它包含屬性 “ DAV:displayname ” 和 “DAV:lastmodified ” 下面的第一個搜索執行起來將比第二個快得多，盡管它們返回的數據相同。 ? SELECT DAV:displayname, DAV:lastmodified from scope(SHALLOW

45、TRAVERSAL OF ) ? SELECT * from scope(SHALLOW TRAVERSAL OF ) ? 只搜索文件夾時執行層次結構的遍歷。 如果是搜索文件夾，通過指定搜索應使用層次結構而非深度遍歷，應用程序可以提高搜索性能。例如，下 面的兩個搜索將返回相同的資源，但與第二個搜索相比，第一個搜索的返回速度更快，而且使用的服務器 資源也較少。 ? SELECT DAV:displayname from scope(HIERARCHICAL TRAVERSAL OF ) ? SELECT DAV:displayname from scope(DEEP TRAVERSAL OF )

46、 WHERE DAV:iscollection = true 盡可能指定多個淺層范圍，而不是執行深度遍歷搜索 執行多個淺層遍歷搜索比執行一個深度遍歷搜索的效率高。 深度遍歷搜索要求 Web 存儲系統鎖定待搜索的 層次結構(避免執行搜索時層次結構發生變化)，但是淺層遍歷搜索沒有這一限制。構建搜索請求時，可 以在查詢中指定多個范圍。所有列出的范圍必須是相同類型的范圍(即，都是深度的或都是淺層的)。有 關詳細信息，請參考 Exchange 2000 SDK 中的“搜索范圍”主題。 保守使用同步事件 創建 Web 存儲系統應用程序時， 同步事件是一個強有力的工具， 但它們也可能給性能帶來嚴重影響。如果

47、 正在執行的同步事件使用某給定資源，所有要使用該資源的其它操作都將被阻塞，直到該同步事件完成為 止。因此，應盡可能使用異步事件。異步事件的功能不如同步事件豐富，但在對資源進行非串行化訪問時， 異步事件更有優勢。 對與事件一同使用的 COM+ 組件進行性能調整 使用 COM+ 組件實施事件時，應遵循調整 COM+ 組件的正規操作方式。 可伸縮性與可用性 Exchange 2000 相對于 Exchange Server 的以前版本在可伸縮性與可用性方面有很大的改進。 Exchange 2000 中有助于改善應用程序可伸縮性與可靠性的功能包括： 多個存儲區和存儲組，減少了備份和恢復的時間，并擴展可

48、伸縮性與可靠性。 ? 活動 / 活動群集，注重提高 KM 應用程序的可靠性和可訪問性。 ? 網絡負載平衡，它代表另一種形式的群集化，注重在多個服務器間分配網絡流量，而不是在發生 服務器故障時確保可訪問性（象在活動 / 活動群集中那樣）。 ? 分布式前臺 / 后臺服務器配置結構， 從而可以在多個服務器上劃分服務分區， 并且在此過程中允許 Exchange 擴展到能夠滿足大規模的企業、 ISP 以及 ASP 的需要。 ? 使用 Windows 2000 Active Directory滿足安全要求，以便處理集中管理和可靠性的問題。 ? Web 存儲系統依靠存儲組、 多數據庫、 群集以及自身 MIM

49、E 存儲，不僅可以與 IIS 集成和快速傳 遞流媒體文件，并且提供可伸縮性與可靠性。除此之外， Exchange 還負責存儲區的 復制 ，以便在 需要時還可以使用這部分存儲區。 有關上述功能的詳細信息，請參考 Exchange 2000 聯機文檔和以下白皮書： ? （英文） ? （英文） ? （英文） 指南回顧 概括起來，以下是使用 Exchange 2000/Web 存儲系統設計 KM 解決方案的指南的列表： 對不同應用程序創建和劃分多個存儲區 現在，Exchange 2000支持包含多個公共文件夾樹，或稱為頂級層次結構（TLH）的功能。此外，對于每 個公共文件夾樹來說， Exchange

50、2000 僅將其復制到各服務器的一個公共文件夾存儲區中。由于這種復制 帶有更多的限制， 管理人員現在可以將選定的幾組公共文件夾分別限定在各個服務器上，這樣更容易控制， 還可以提高在這些存儲區上運行的應用程序的可用性。 在單獨的驅動器上安裝并保護事務日志 為了保證容錯性，以及即使服務器發生故障后仍能恢復存儲區，Exchange 2000 與它以前的版本一樣都要 依靠于事務日志文件中的事務記錄。事務日志充當內存與磁盤上數據庫之間的防錯中介。在設置和管理事 務日志和數據庫時，建議您遵照下列最佳方法： ? 通過諸如磁盤鏡象 （RAID） 這樣的方式保護驅動器，防止可能的硬件故障造成的損失。 ? 在單獨

51、的驅動器上保存事務日志和數據庫（存儲區）。 ? 保持每個服務器上事務日志驅動程序的數量與存儲組的數量相等，以及將每個事務日志設置在不 同的位置上，以使性能達到最佳。 始終將文件系統格式化為符合 NTFS 的要求 關閉循環日志記錄功能 設置前臺服務器以處理接收的協議請求，設置后臺服務器用作 Web 存儲區 在這種配置形式中，前臺服務器可專用于處理接收的客戶連接和協議請求。后臺服務器可專用于管理數據 庫（存儲區）。顯然，這種在多個服務器間分配負載的功能有助于提升 Exchange 的容量，從而滿足上百 萬個用戶的需求。此外，將這些操作分開也有利于提高整個系統的可靠性。重要的組件不再被固定到幾個 服

52、務器中的某一個上。 為提高可用性使用群集和網絡負載平衡服務 正如上文所述， 群集是將服務器分組的一種方式 即使這些服務器是獨立的、 分離的計算機 對網絡而 言它們是一體的。 它們相互協作， 從而保證即使其中一臺發生故障， 另一臺能夠隨時接管并繼續提供服務。 在 Exchange 2000 中， 群集是活動 / 活動的，即 Exchange 服務可在群集中的所有服務器上同時運行。如 果其中一臺出現故障，另一臺能夠接管故障服務器的職能，同時還能繼續處理自己的任務。 注意： 群集要求 Windows 2000 Advanced Server或 Windows 2000 Datacenter Serv

53、er。 Windows 2000 的網絡負載平衡服務與其它類型的基于硬件的解決方案相比，基本上是一種基于軟件的負載 平衡解決方案。網絡負載平衡服務的功能是抓取進入的 TCP/IP 流量，然后將它平均分配到一個負載平衡 群集中的各個服務器上。 為群集指定一個 IP 地址 （如果主機是歸屬于多個系統的， 即連接到多個網絡上， 則指定一組地址） 。如果主機發生故障或脫機，負載平衡服務能將網絡流量重新引導到正常工作的主機上， 因為連接中斷后客戶機會重試， 最終用戶最多只會感到一兩秒的延遲， 就可接到正常工作的服務器的響應。 設計事件和工作流過程時要注意可用性 為適應應用程序可用性的需求 使應用程序在發

54、生非致命錯誤的情況下仍保持運行 您應當注意錯誤 的處理，特別是事件接收器、COM+組件和工作流方面的錯誤。這是為了能夠從大多數非致命錯誤中恢復， 同時不丟失服務。 分類的實現 管理和實現 分類是 KM 解決方案需要成功完成的關鍵任務之一。分類一詞指劃分和組織內容的方法，它通 常是 KM 解決方案內容管理模塊中的一個核心服務。 使用 Web 存儲系統實現分類有多種方法。這里我們比較三種方法的優點和缺點。 Active Directory 你可以擴展 Active Directory 架構以包含分類，如與用戶或雇員相關的內容信息以及組織和地域信息。 如果內容信息不常更新， 這種方法會很有效， 它通

55、常適用于整個企業。 它也能從使用 Active Directory 基 礎結構中獲益。另一方面，這種方法的缺點包括： 如果內容信息時常更新，或在處理不適用于整個企業的特定信息時，效果不佳。 ? 如果分類發生改變，管理 Active Directory架構擴展將比較困難。 ? 要復制整個企業范圍內的 Active Directory架構擴展，還需要額外的開銷。 文件夾以及內容類 如果采用這種方法，您要定義內容類及適當的文件夾結構（上文所述的分層結構或單層文件夾結構均可） 來存儲內容信息。這種方法適用于內容信息時常更新的情況。但是，最好留意這種方法的一以下些潛在缺 陷： ? 在“性能”部分我們已經

56、討論過，檢索內容信息的性能在很大程度上依賴于您為自定義屬性編制 索引的方式以及您設計的 SQL查詢的方式。 ? 在某些情況下，改變分類或用新的分類替代它可能比較困難，需要改變文件夾結構。 搜索文件夾 搜索文件夾的方法與內容類方法相似，只是分類是存儲在搜索文件夾中的。正如上文所述，搜索文件夾是 動態的，它們的內容時常被 Web存儲系統重新評估并更新。換言之，搜索文件夾包括指向物理對象的指針 （類似于符號鏈接）。 與業務范圍應用程序的集成 現實的KM解決方案必須與其它業務范圍 （LOB）應用程序集成。例如，一個KM解決方案需要從其它 LOB 應用程序（如人力資源應用程序或制造過程應用程序）中獲取源內容和數據。在另一種情況下，KM解決方