【正文】 目的是指導開發(fā)人員通過一些有效的方式使用 Web 存儲系統(tǒng)設計 KM 解決方案。 如果存在問題，您可以按如下步驟進行性能調(diào)整： 您需要處理您自己應用程序的錯誤，還希望其它應用程序能夠處理它們自己的錯誤。如果兩個應用程序都是基于 Windows 2000 Active Directory 的，就可以直接接合了。 strURL = strCommunityURL amp。使用 WebDAV 將 XML 文檔張貼到 Internet 或 Intranet Web 站點上 如果您沒有使用 BizTalk 服務器而希望將 XML 文檔發(fā)送到另一個 Web 站點，您應當使用 WebDAV。有關 BizTalk Server 2000 的詳細信息，請參考 Microsoft BizTalk 2000：使用 BizTalk Orchestration 建立反向拍賣過程。 2. 用于與其它 LOB 應用程序接合的外部 XML 架構。這種方式基于這樣的事實： Web 存儲系統(tǒng)本身支持 XML 并且非常適合充當與其它 LOB 應用程序之間的基于 XML 的接口。例如，一個 KM 解決方案需要從其它 LOB 應用程序（如人力資源應用程序或制造過程應用程序）中獲取源內(nèi)容和數(shù)據(jù)。 搜索文件夾 搜索文件夾的方法與內(nèi)容類方法相似，只是分類是存儲在搜索文件夾中的。但是，最好留意這種方法的一以下些潛在缺陷： 另一方面，這種方法的缺點包括： 這里我們比較三種方法的優(yōu)點和缺點。這是為了能夠從大多數(shù)非致命錯誤中恢復，同時不丟失服務。網(wǎng)絡負載平衡服務的功能是抓取進入的 TCP/IP 流量，然后將它平均分配到一個負載平衡群集中的各個服務器上。它們相互協(xié)作，從而保證即使其中一臺發(fā)生故障，另一臺能夠隨時接管并繼續(xù)提供服務。顯然，這種在多個服務器間分配負載的功能有助于提升 Exchange 的容量，從而滿足上百萬個用戶的需求。 在設置和管理事務日志和數(shù)據(jù)庫時，建議您遵照下列最佳方法： 此外，對于每個公共文件夾樹來說，Exchange 2000 僅將其復制到各服務器的一個公共文件夾存儲區(qū)中。 有關上述功能的詳細信息，請參考 Exchange 2000 聯(lián)機文檔和以下白皮書： 使用 Windows 2000 Active Directory 滿足安全要求，以便處理集中管理和可靠性的問題。 網(wǎng)絡負載平衡，它代表另一種形式的群集化，注重在多個服務器間分配網(wǎng)絡流量，而不是在發(fā)生服務器故障時確?？稍L問性（象在活動/活動群集中那樣）。 多個存儲區(qū)和存儲組，減少了備份和恢復的時間，并擴展可伸縮性與可靠性。異步事件的功能不如同步事件豐富，但在對資源進行非串行化訪問時，異步事件更有優(yōu)勢。有關詳細信息，請參考 Exchange 2000 SDK 中的“搜索范圍”主題。) WHERE DAV:iscollection = true 盡可能指定多個淺層范圍，而不是執(zhí)行深度遍歷搜索 執(zhí)行多個淺層遍歷搜索比執(zhí)行一個深度遍歷搜索的效率高。HIERARCHICAL TRAVERSAL OF ://myserver/public39。 如果是搜索文件夾，通過指定搜索應使用層次結構而非深度遍歷，應用程序可以提高搜索性能。 SELECT * from scope(39。 只在絕對必要時執(zhí)行“SELECT *”操作 執(zhí)行“SELECT *”操作要求 Web 存儲系統(tǒng)在架構中進行查找被搜索項，以確定要返回哪一組屬性。為屬性一級編制索引只能對在用于搜索的 where 子句中使用已索引屬性的情況下，幫助改善搜索性能。因此，我們建議只有在被搜索數(shù)據(jù)不會頻繁更新的情況下，才應在頻繁進行的查詢中使用搜索文件夾。如果雇員要搜索存儲區(qū)中的文檔，只需要在搜索文件夾中而不是層次結構中進行搜索。由于搜索必須瀏覽的記錄和文件夾的數(shù)量極大，要在整個層次結構中執(zhí)行這些搜索，成本會相當高昂。例如，假設有一個 KM 應用程序，用來跟蹤記錄公司雇員生成的各種項目文檔。 正如上文所述，Web 存儲系統(tǒng)為建立 KM 解決方案提供了強大的功能和高度的靈活性。 定義內(nèi)容安全模型 — 例如，項一級的安全、屬性一級的安全 定義安全策略 用戶 —他們的角色和內(nèi)容訪問需求 角色 SID 是獨立結構的，不包含任何 Windows 2000 的特定安全信息，因此可在多個域中使用。正如上文所述，只要可以對文件夾和項設置 ACL，就可以在 Web 存儲系統(tǒng)中使用角色。這樣，部署在一臺運行 Exchange Server 的計算機上的兩個應用程序不需要使用不同的角色名稱和成員。對應用程序開發(fā)人員來說，安全角色具備兩個明顯的優(yōu)勢： 角色與 Windows 2000 組之間主要的區(qū)別在于 Exchange 安全角色是針對對象本身定義和存儲的。 訪問控制列表 (ACL) 包含一個或多個訪問控制項 (ACE)；每個 ACE 為安全負責人 指定訪問權限。 該描述符以 Exchange 2000 Server 特有的二進制格式進行物理存儲和復制，這種格式內(nèi)部是基于標準的 Windows 2000 描述符格式的。 使用 Microsoft Windows174。除了使用 MAPI 客戶程序（如 Outlook）或 Windows 文件系統(tǒng) API 來控制安全設置外，您還可以使用基于 XML 的安全描述符來控制對某一項及其屬性的訪問。 物理設計考慮因素 到此，我們已經(jīng)討論了設計用戶服務、業(yè)務服務和數(shù)據(jù)服務的最佳方法。 首先，將 SQL 列映射到屬性，將 SQL 表映射到文件夾和內(nèi)容類。表 3 闡釋了 SQL 數(shù)據(jù)庫與 Web 存儲系統(tǒng)的不同之處。 如果需要，將 schemacollectionref (SCR) 屬性指向架構文件夾。相對于給定的數(shù)據(jù)文件夾，schemacollectionref 屬性指示搜索始于哪個架構文件夾。正如上文所述，schemacollectionref 是一個可在數(shù)據(jù)文件夾上設置的屬性，用來指示在查找相關屬性和內(nèi)容類定義時應首先搜索哪個架構文件夾。（這可能在一個單獨的窗體注冊文件夾中。 文件夾結構的示例如下： 通常，特定應用程序的架構定義將置于它們自己的文件夾中。 以下步驟概述了這一過程。通過合理設置不同文件夾的 schemacollectionref 和 baseschema 屬性，您可以將這些定義引入到范圍中來。理解 document 類的應用程序就可以理解 exprensedocument 類的一些屬性。因此，我們創(chuàng)建一個 exprensereport 類來擴展該類。擴展文檔類意味著任何可在文檔類實例上執(zhí)行的代碼或操作都可以在 expensereport 類實例上執(zhí)行。不過，多數(shù)內(nèi)容類都可以擴展（“繼承”）現(xiàn)存的內(nèi)容類。但是，在下一部分中，我們將推薦一組方式，指導您如何組織文件夾結構以及如何確定對一組特定應用程序數(shù)據(jù)應用哪一個架構定義。首先，您需要為應用程序選擇一個文件夾，用來存儲架構信息。 屬性應當是格式正確的 URI。進行屬性定義 Web 存儲系統(tǒng)本身對屬性名稱中可使用哪些字符沒有特殊的限制。這將有助于保證命名空間的唯一性。如果命名空間不以分隔符結尾（如第三個示例），則該命名空間中將創(chuàng)建屬性名，命名空間與屬性名之間有一個符號“”。如果您希望為您的應用程序創(chuàng)建一個類似的命名空間，您可以創(chuàng)建 urn：schemasmypanysdomain:myapplication:。 urn:schemasmicrosoft:exchdata: 架構設計指南 架構設計指南的內(nèi)容如下：使用和定義命名空間 (URN) 使用命名空間定義屬性和內(nèi)容類是一種好辦法。URN 的語法結構保證了 URN 跨多個組織的唯一性。只有 URL 的主機部分是必須的。 URL 開頭帶有一個標識協(xié)議的前綴，接著是一個針對協(xié)議的字符串。 下面我們對一些通用的架構設計指南作一總結。檢查項時可以按名稱發(fā)出請求。 除了定義自定義內(nèi)容類之外，定義自定義屬性是架構設計的另一個重要方面。如果未設置這個屬性，則默認為存儲區(qū)的 non_ipm_subtree/Schema 文件夾，其中包含 Web 存儲系統(tǒng)的默認架構定義項。還需要查看以下兩個屬性來定義架構范圍，這兩個屬性對整體架構設計 — 尤其是文件夾結構 — 也很重要，我們將在下一部分討論這一主題。與某一特定應用程序相關的架構信息是通過文件夾的架構范圍來控制的。Web 存儲系統(tǒng)含有大量預定義的內(nèi)容類和屬性。Web 存儲系統(tǒng)可用于為您的應用程序定義架構。架構設計對整個 KM 解決方案是否成功有直接影響，尤其是在性能和可擴展性方面。這一部分我們將討論 Web 存儲系統(tǒng)架構設計，下一部分討論文件夾結構。 如果出現(xiàn)以下情況，則使用事件接收器： 涉及多用戶和多資源。使用腳本的方法會造成一些困難，如代碼不易維護以及腳本的局限性。設計業(yè)務服務的最佳方法 正如上文所述，業(yè)務服務是一個應用程序邏輯單元，它控制執(zhí)行業(yè)務規(guī)則的先后順序，保證所執(zhí)行操作的事務完整性。 窗體 URL：正在處理或顯示的窗體或模板的 URL；當前 URL 所表示的項（例如：、）。窗體注冊提供一組針對窗體的屬性，如內(nèi)容類、用戶操作、語言、瀏覽器類型、項狀態(tài)和兩個重要屬性： Exchange 接收到來自用戶瀏覽器的 HTTP 請求后，該請求即被傳送給 Microsoft Internet Information 服務 (IIS)?！绷私?Web 存儲系統(tǒng)窗體如何工作是必要的。 適應性強：窗體只需要了解如何處理某一特定語言、瀏覽器或操作。 Web 存儲系統(tǒng)窗體有什么特殊之處呢？Web 存儲系統(tǒng)窗體具有以下特點： Web 存儲系統(tǒng)窗體是在 Web 存儲系統(tǒng)中注冊的 Web 頁面。在頁面的一角可以顯示一個商標或公司標識，在另一角有當前新聞和與內(nèi)部工具的鏈接?？墒褂帽怼⒖蚣芎?iFrame 來安排 Outlook Web Access 的各個部分。 內(nèi)容搜索服務 通過 UI 設計指南定義一致的外觀 定義一組 UI 設計指南是個好方法。Web 部件是可以重復使用的組件，它包括基于 Web 的內(nèi)容（如 XML、 HTML）和腳本，還包括一組標準屬性，用于控制 Web 部件在數(shù)字儀表板中的顯示方式。用戶只需點擊一下，就可使用簡便的工具來自定義數(shù)字儀表板、創(chuàng)建新的 Web 部件或者從 Internet 或本地 Intranet 上的 Web 部件庫中導入 Web 部件。數(shù)字儀表板由 Web 部件（可重復使用的組件，包含任何形式基于 Web 的信息）組成。示例：在設計雇員 KM 入口 Web 站點時，內(nèi)容搜索用戶服務和分類選擇用戶服務可能會在整個 Web 站點中重復利用。其設計活動的中心通常是圖形用戶界面 (GUI) 和/或應用程序編程接口 (API)。 所有小組成員和該項目涉及的其他人員都應當首先了解解決方案和整個系統(tǒng)結構的情況，包括系統(tǒng)中各部分之間的相互聯(lián)系。 一些開發(fā)小組可能傾向于干脆跳過邏輯設計階段而直接進行物理設計。本關系圖源自 ObjectSpace （)（英文）公司的 Craig Larman 所寫的面向?qū)ο蟮姆治龊驮O計材料。這些備選服務/對象奠定了邏輯設計模型的基礎。方案的定義應當根據(jù)業(yè)務問題范圍內(nèi)的環(huán)境來進行，而不是根據(jù)解決方案范圍內(nèi)的環(huán)境來進行。 安全 XML 描述符模板 以下是適用于 KM 設計模型的一般最佳方法或建議。 小組成員 基于 Web 存儲系統(tǒng)的物理架構設計： 允許小組成員通過適當?shù)陌踩Ｐ凸蚕砘虿榭次臋n。 使用工作流引擎實現(xiàn) RFQ 批準過程 最佳方法 表 1. 知識管理解決方案設計模型服務層次概念設計（方案）邏輯設計（對象/服務）物理設計（組件/技術）用戶服務示例方案：建立社區(qū)論壇，通過動態(tài)地、根據(jù)需要添加論壇來實現(xiàn)它的靈活性。 我們