使用-Web-存儲系統(tǒng)設(shè)計知識管理解決方案_第1頁
使用-Web-存儲系統(tǒng)設(shè)計知識管理解決方案_第2頁
使用-Web-存儲系統(tǒng)設(shè)計知識管理解決方案_第3頁
使用-Web-存儲系統(tǒng)設(shè)計知識管理解決方案_第4頁
使用-Web-存儲系統(tǒng)設(shè)計知識管理解決方案_第5頁
已閱讀5頁,還剩13頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

運用Web存儲系統(tǒng)設(shè)計學(xué)問管理解決方案WalsonLee

MicrosoftCorporation

2000年10月摘要:本文概述了運用Web存儲系統(tǒng)開發(fā)高效的學(xué)問管理解決方案的設(shè)計過程。書目簡介Web存儲系統(tǒng)用作開發(fā)平臺建立KM解決方案Microsoft解決方案框架:基于服務(wù)的應(yīng)用程序模型MSF設(shè)計過程KM解決方案設(shè)計模型設(shè)計用戶服務(wù)的最佳方法設(shè)計業(yè)務(wù)服務(wù)的最佳方法設(shè)計數(shù)據(jù)服務(wù)架構(gòu)的最佳方法Web存儲系統(tǒng)文件夾結(jié)構(gòu)的最佳方法SQL與Web存儲系統(tǒng)物理設(shè)計考慮因素平安模型性能可伸縮性與可用性指南回顧分類的實現(xiàn)與業(yè)務(wù)范圍應(yīng)用程序的集成結(jié)論

簡介Microsoft?Exchange2000Server是引入一種新的稱為Web存儲系統(tǒng)的存儲技術(shù)的第一個Microsoft產(chǎn)品。Microsoft的Web存儲系統(tǒng)供應(yīng)很多新的開發(fā)功能,例如Web存儲系統(tǒng)事務(wù)與窗體、工作流引擎、內(nèi)容索引以及搜尋文件夾。這些功能特殊適用于學(xué)問管理(KM)解決方案。但是,KM解決方案的開發(fā)人員起先時須要經(jīng)過一個學(xué)習過程,才能理解這些功能,并逐個理清Web存儲系統(tǒng)供應(yīng)的很多個設(shè)計選項的作用。本文著重講解了有關(guān)開發(fā)KM解決方案的設(shè)計方面的學(xué)問,并探討了最佳方法、設(shè)計模式以及設(shè)計過程中的考慮因素。其中展示了基于服務(wù)的應(yīng)用程序模型和基于Microsoft解決方案框架(MSF)的設(shè)計過程。這個設(shè)計過程是專為運用Web存儲系統(tǒng)建立KM解決方案量身定做的。設(shè)計過程包含了概念設(shè)計模型、邏輯設(shè)計模型以及物理設(shè)計模型。本文重點講解并描述針對Web存儲系統(tǒng)的物理設(shè)計模型的設(shè)計考慮因素:用戶服務(wù)—數(shù)字儀表板和Web存儲系統(tǒng)窗體業(yè)務(wù)服務(wù)—工作流和事務(wù)設(shè)計數(shù)據(jù)服務(wù)—存儲架構(gòu)設(shè)計平安模型性能可伸縮性與可用性分類的實現(xiàn)與業(yè)務(wù)范圍(LOB)應(yīng)用程序集成本文旨在供應(yīng)一種設(shè)計基于Web存儲管理系統(tǒng)技術(shù)的KM解決方案的正確方法。它所面對的讀者是KM解決方案的構(gòu)建或設(shè)計人員。其他開發(fā)人員也能從本文闡述的基本設(shè)計概念中獲益。

Web存儲系統(tǒng)用作開發(fā)平臺Web存儲系統(tǒng)是Microsoft為體現(xiàn)它的“不受限制的學(xué)問工作者”理念而宣布的四項創(chuàng)意之一。這些創(chuàng)意的主要目的是消退當今學(xué)問工作者面臨的阻礙相互協(xié)作的障礙。Web存儲系統(tǒng)將文件系統(tǒng)、Web以及協(xié)作服務(wù)器的功能組合到一個位置,以便存儲、訪問、管理信息以及建立和運行應(yīng)用程序。Web存儲系統(tǒng)中的每一項都是可用URL尋址的,并且完全支持半結(jié)構(gòu)化數(shù)據(jù),如文檔、聯(lián)系人、消息、報告、HTML文件以及ActiveServerPages(ASP)。Web存儲系統(tǒng)供應(yīng)與MicrosoftOffice2000的高性能集成。它為信息管理(包括一樣搜尋和數(shù)據(jù)分類)建立了一個平臺。圖1闡釋了Web存儲系統(tǒng)的編程模型。從圖中可看出它支持不同的協(xié)議、數(shù)據(jù)訪問方式和事務(wù)模型。對Web存儲系統(tǒng)的數(shù)據(jù)訪問包括對OLEDB和ActiveX?DataObjects(ADO)的支持。Web存儲系統(tǒng)還供應(yīng)通過協(xié)議進行訪問的功能。WebDAV規(guī)范(英文)增加了這一功能,使它可支持另一組協(xié)議吩咐。此外,該存儲系統(tǒng)本身還支持可擴展標記語言(XML)。Web存儲系統(tǒng)還包括一些新的功能,如Outlook?Web訪問、Web存儲系統(tǒng)窗體、事務(wù)、工作流、內(nèi)容索引、搜尋文件夾以及即時消息傳送。這些功能為開發(fā)人員建立KM解決方案帶來了很大的敏捷性,也更簡潔實現(xiàn)。有關(guān)Web存儲系統(tǒng)的具體資料,請參見Exchange2000SDK以及MSDNExchangeServer開發(fā)人員中心(英文)。圖1.Web存儲系統(tǒng)編程模型

建立KM解決方案對企業(yè)中的每一個業(yè)務(wù)問題,學(xué)問管理(KM)通過選擇解決問題的正確模塊而不斷更新。依據(jù)不同的組織方式和技術(shù),每一模塊都有自己的特性。下面列出了一些典型特性:擴充客戶/合作伙伴/雇員的學(xué)問快速學(xué)習并重復(fù)利用學(xué)問提高學(xué)問產(chǎn)權(quán)的價值為產(chǎn)品和服務(wù)供應(yīng)特殊的附加值建立新學(xué)問共享工作過程和質(zhì)量革新的學(xué)問圖2.KM啟用模塊有兩項技術(shù)是全部KM系統(tǒng)的基礎(chǔ):完全Intranet和消息傳送及協(xié)作。這些技術(shù)構(gòu)建的基礎(chǔ)結(jié)構(gòu)支持對信息進行有效傳輸、架構(gòu)、訪問和協(xié)同管理。其余的KM啟用模塊把這一基礎(chǔ)結(jié)構(gòu)擴展成一個困難的KM系統(tǒng),該系統(tǒng)包含各種服務(wù)(如內(nèi)容管理、各種信息傳遞以及數(shù)據(jù)分析等)。其它服務(wù)(如數(shù)據(jù)跟蹤、工作流過程)也包含在該系統(tǒng)和這些模塊中。實現(xiàn)KM啟用模塊可以是即插即用的。雖然某些模塊得益于從前某一模塊的實現(xiàn),仍可按與要開發(fā)的特定業(yè)務(wù)案例之間的相對依次選擇它們。例如,象視頻會議這樣的實時協(xié)作服務(wù),可以很簡潔地包含在必備技術(shù)的上層,但要通過內(nèi)容管理模塊中供應(yīng)的元數(shù)據(jù)服務(wù)才能得以增加。圖3.可能的學(xué)問管理平臺分層結(jié)構(gòu)Microsoft當前的KM平臺是MicrosoftBackOffice?系列。它供應(yīng)的服務(wù)能夠:建立KM先決條件(消息傳送及協(xié)作和完全Intranet),通過實現(xiàn)全部的KM啟用模塊(內(nèi)容管理、團體和組、入口和搜尋、數(shù)據(jù)分析以及實時協(xié)作)將它們擴展成KM解決方案。除了這些服務(wù),BackOffice還供應(yīng)與從前信息或?qū)W問源集成和連接的接口。在將來的幾個月內(nèi),Microsoft將發(fā)布.NETEnterpriseServer,它包含SQLServer?2000、BizTalk?Server、CommerceServer2000、HostIntegrationServer2000、InternetSecurity&AccelerationServer2000、Exchange2000Server以及ApplicationCenter2000。設(shè)計這些組件的目的是通過它們的緊密協(xié)作來建立下一代的Web應(yīng)用程序。本文的重點是Web存儲系統(tǒng),它是Exchange2000以及Microsoft將來產(chǎn)品的基礎(chǔ)存儲技術(shù)。Web存儲系統(tǒng)是建立和供應(yīng)以下關(guān)鍵學(xué)問服務(wù)所需的一個開發(fā)平臺:搜尋與傳遞協(xié)作文檔管理跟蹤和工作流有關(guān)具體信息,請參考建立學(xué)問管理解決方案白皮書(英文)。

Microsoft解決方案框架:基于服務(wù)的應(yīng)用程序模型為了奠定一個基礎(chǔ),以便您駕馭下面關(guān)于如何設(shè)計KM解決方案的探討,我們將依據(jù)Microsoft解決方案框架(MSF)白皮書,簡要概括MSF的基于服務(wù)的應(yīng)用程序模型。有關(guān)具體信息,請參考Microsoft解決方案框架白皮書(英文)。MSF提倡運用基于服務(wù)的應(yīng)用程序模型來設(shè)計和實現(xiàn)分布式組件和業(yè)務(wù)解決方案?!盎诜?wù)的應(yīng)用程序模型”是指應(yīng)用程序的功能定義為一組服務(wù)集合。依據(jù)MSF的觀點,一個應(yīng)用程序是由服務(wù)的運用者與供應(yīng)者組成的邏輯網(wǎng)絡(luò)構(gòu)成的。在這一模型中,運用者可以是一個用戶或另一個服務(wù)組件。這些服務(wù)可以跨越物理和功能的邊界,滿足各種不同應(yīng)用程序的需求。什么是服務(wù)?服務(wù)就是一組應(yīng)用程序邏輯,它針對對象實現(xiàn)操作、功能或轉(zhuǎn)換。服務(wù)可以執(zhí)行業(yè)務(wù)規(guī)則,計算或管理數(shù)據(jù),供應(yīng)輸入、檢索、查看或修改信息等功能。為進一步精確說明服務(wù)網(wǎng)絡(luò)的分布特性,MSF應(yīng)用程序模型定義了組成一個應(yīng)用程序的三類服務(wù):用戶服務(wù)是供應(yīng)應(yīng)用程序接口的應(yīng)用程序邏輯單元。應(yīng)用程序的用戶可以是一個用戶或另一個應(yīng)用程序。因此,應(yīng)用程序的接口可以是圖形用戶界面(GUI)和/或應(yīng)用程序編程接口(API)。業(yè)務(wù)服務(wù)這種應(yīng)用程序邏輯單元用于限制業(yè)務(wù)規(guī)則的先后依次和執(zhí)行,并且可以保證所執(zhí)行操作的事務(wù)完整性。通過應(yīng)用恰當?shù)臉I(yè)務(wù)規(guī)則,業(yè)務(wù)服務(wù)可將數(shù)據(jù)轉(zhuǎn)換成信息。數(shù)據(jù)服務(wù)是供應(yīng)最低提取可見級別的應(yīng)用程序邏輯單元,用于操作數(shù)據(jù)。數(shù)據(jù)服務(wù)維護作為公司資產(chǎn)的永久和非永久數(shù)據(jù)的可用性和完整性。它們供應(yīng)創(chuàng)建、讀取、更新和刪除服務(wù),這樣業(yè)務(wù)服務(wù)(數(shù)據(jù)服務(wù)的運用者)就不須要了解數(shù)據(jù)的位置、實現(xiàn)方式和訪問方式了。

MSF設(shè)計過程設(shè)計業(yè)務(wù)解決方案的過程可與設(shè)計建立一座建筑物相比。好的建筑師只有了解了客戶的需求才真正了解了客戶。在系統(tǒng)設(shè)計中,可有多個視角描述最終產(chǎn)品,這與建筑是一樣的。每一個視角都是為不同的受眾打算的,它們的具體程度也不盡相同。KM解決方案的設(shè)計也是這樣—應(yīng)用程序有不同的重點和技巧。設(shè)計人員專注于用戶界面、業(yè)務(wù)過程或數(shù)據(jù)庫問題,我們須要為他們供應(yīng)一種途徑來協(xié)調(diào)和同步他們的工作,使他們能高效地、有組織地利用他們的專業(yè)技能完成全面平衡的設(shè)計。MSF設(shè)計過程分三個階段:概念設(shè)計邏輯設(shè)計物理設(shè)計概念設(shè)計概念設(shè)計是指準確了解要解決的問題,然后以管理方和用戶都能理解的方式構(gòu)架出問題的解決方案。與單純收集需求相比,它的范圍要廣得多。這個階段還須要依據(jù)具體環(huán)境來處理這些需求,從而合理決策。概念設(shè)計提取出要執(zhí)行業(yè)務(wù)活動所需的本質(zhì)任務(wù)和信息,從而依據(jù)既緊密圍繞過程,又以用戶為中心的方式看待解決方案。在MSF中,方案是概念設(shè)計過程的關(guān)鍵結(jié)果。一個方案描述在某種業(yè)務(wù)環(huán)境中用戶執(zhí)行的與行為相關(guān)的一系列任務(wù)或事務(wù)。方案必需依據(jù)負責這項工作的用戶的須要(以用戶為中心)來提取業(yè)務(wù)解決方案的需求(圍繞過程)。邏輯設(shè)計邏輯設(shè)計是指通過定義系統(tǒng)各部分及它們間相互作用的方式來描述解決方案的過程。這一過程組織新系統(tǒng)的邏輯結(jié)構(gòu)并闡釋該系統(tǒng)的組成方式以及它與外部世界的接口。在邏輯設(shè)計過程中,必需加深項目組對系統(tǒng)的相識。這是確定設(shè)計的具體程度的主要考慮因素。邏輯設(shè)計供應(yīng)的組織和結(jié)構(gòu)規(guī)則必需滿足各個獨立的組成員同時高效工作的要求,還要奠定與外部項目和構(gòu)架進行協(xié)作的基礎(chǔ)。邏輯設(shè)計供應(yīng)了評價各種物理設(shè)計選項的基礎(chǔ)。通過不同的物理設(shè)計都可能實現(xiàn)對邏輯元素的組織。在一個反復(fù)的過程中,進行邏輯設(shè)計會與進行物理設(shè)計有部分相重疊。這樣整個小組才能夠逐步優(yōu)化系統(tǒng)。邏輯設(shè)計旨在列出系統(tǒng)中的各部分、描述它們的相互聯(lián)系并定義運用這些部分可以達到什么目的。請記住概念設(shè)計與邏輯設(shè)計是緊密相關(guān)的。邏輯設(shè)計描述系統(tǒng)如何協(xié)作每一個概念設(shè)計方案。設(shè)計組可以從定義系統(tǒng)的主要模塊起先邏輯設(shè)計過程。模塊表示協(xié)同工作完成某項任務(wù)的一些過程的集合。設(shè)計組必需確定每一個元素、每個元素的職能以及每個元素如何與其它元素相互作用。這個階段的結(jié)果包括:核心的功能區(qū)域或元素這些區(qū)域的活動或功能區(qū)域間聯(lián)系物理設(shè)計物理設(shè)計是從開發(fā)小組的角度描述解決方案的組件、服務(wù)以及技術(shù)的過程。物理設(shè)計旨在依據(jù)現(xiàn)實的技術(shù)局限性分析邏輯模型,包括實現(xiàn)狀況和性能方面的考慮。物理設(shè)計過程的結(jié)果是一組組件、特定平臺的用戶界面設(shè)計以及物理數(shù)據(jù)庫設(shè)計。物理設(shè)計為功能規(guī)格供應(yīng)基礎(chǔ)。開發(fā)小組、測試小組以及部署小組都可運用這一功能規(guī)格作為質(zhì)量保證的基礎(chǔ)。物理設(shè)計過程包含幾個步驟:探討、分析、合理化以及規(guī)范化:物理設(shè)計的探討步驟包括確定基本結(jié)構(gòu)的物理局限性以及解決方案的物理需求,并處理物理局限性與需求之間可能產(chǎn)生的沖突。物理設(shè)計的分析步驟包括選擇備選的實現(xiàn)技術(shù)并草擬由網(wǎng)絡(luò)、數(shù)據(jù)、組件拓撲結(jié)構(gòu)組成的初步部署模型。物理設(shè)計的合理化步驟包含確定打包方式和分布策略、將對象分解成基于服務(wù)的組件、在拓撲結(jié)構(gòu)中分布組件以及進一步改進打包和分布方式。物理設(shè)計的規(guī)范化步驟包括確定編程模型、指定組件接口和了解組件結(jié)構(gòu)的考慮因素。

KM解決方案設(shè)計模型到此,我們已經(jīng)分析了建立KM解決方案、MSF應(yīng)用程序模型和設(shè)計過程的關(guān)鍵概念。現(xiàn)在該將它們綜合起來集中學(xué)習如何依據(jù)MSF設(shè)計過程設(shè)計KM解決方案了。我們將運用MSF基于服務(wù)的應(yīng)用程序模型作為以下論述的基本方針。設(shè)計典型的KM解決方案時,我們必需細致考慮以下問題:我們設(shè)計的目的是什么?我們是否定義了獲得用戶和業(yè)務(wù)需求的方案?我們是否有足夠的信息來定義一組服務(wù)以及它們的接口?一旦我們確定了實現(xiàn)技術(shù),基本結(jié)構(gòu)和技術(shù)方面將存在哪些局限性?我們是否定義了對象模型?下表闡釋了一個KM解決方案設(shè)計模型的示例,它是基于一個虛構(gòu)的Exchange2000示例應(yīng)用程序的。表1.學(xué)問管理解決方案設(shè)計模型服務(wù)

層次概念設(shè)計

(方案)邏輯設(shè)計

(對象/服務(wù))物理設(shè)計

(組件/技術(shù))用戶服務(wù)示例方案:建立社區(qū)論壇,通過動態(tài)地、依據(jù)須要添加論壇來實現(xiàn)它的敏捷性。一個基于Web的虛擬社區(qū),包括以下服務(wù):業(yè)界新聞協(xié)作最佳方法共享聯(lián)系人易于查找的信息一個基于Exchange2000的數(shù)字版面,它包含不同的Web部件,與邏輯設(shè)計中定義的服務(wù)相對應(yīng)。業(yè)務(wù)服務(wù)示例方案:要求引導(dǎo)(RFQ)文檔綜述和批準過程。生成RFQ服務(wù)在BizTalk框架的基礎(chǔ)上將RFQ轉(zhuǎn)換成XML文檔RFQ批準過程生成并驗證RFQ的屬性的事務(wù)接收器運用工作流引擎實現(xiàn)RFQ批準過程運用ServerXML、XMLDOM、XSLT實現(xiàn)RFQ轉(zhuǎn)換過程數(shù)據(jù)服務(wù)示例方案:一個中心信息庫,用來容納全部相關(guān)項目文檔以及與工程組織相關(guān)的設(shè)計文檔。允許小組成員通過適當?shù)钠桨材P凸蚕砘虿榭次臋n。以下對象的邏輯架構(gòu)設(shè)計:項目文檔小組成員基于Web存儲系統(tǒng)的物理架構(gòu)設(shè)計:文件夾結(jié)構(gòu)架構(gòu)文件夾自定義內(nèi)容類及屬性平安XML描述符模板以下是適用于KM設(shè)計模型的一般最佳方法或建議。在下面的部分我們將探討具體的主題。在概念設(shè)計階段,重點是定義能把握業(yè)務(wù)過程和需求的方案。方案的定義應(yīng)當依據(jù)業(yè)務(wù)問題范圍內(nèi)的環(huán)境來進行,而不是依據(jù)解決方案范圍內(nèi)的環(huán)境來進行。

在從概念設(shè)計到邏輯設(shè)計的過渡階段中,開發(fā)小組可審核整套方案以應(yīng)用適當?shù)拿鎸ο?OO)的設(shè)計技術(shù)(例如用戶案例分析),來確定備選服務(wù)和/或?qū)ο?。這些備選服務(wù)/對象奠定了邏輯設(shè)計模型的基礎(chǔ)。這通常是個反復(fù)的過程,即須要往復(fù)幾次才能完成。圖6是一個基于MicrosoftVisio?2000聯(lián)機文檔的示例用戶案例關(guān)系圖。本關(guān)系圖源自O(shè)bjectSpace(://objectspace)(英文)公司的CraigLarman所寫的面對對象的分析和設(shè)計材料。圖4.用戶案例關(guān)系圖示例在邏輯設(shè)計階段,小組應(yīng)專注于設(shè)計業(yè)務(wù)和對象,而不考慮技術(shù)和平臺的因素。對多數(shù)開發(fā)人員來說,做到這一點比較困難。一些開發(fā)小組可能傾向于干脆跳過邏輯設(shè)計階段而干脆進行物理設(shè)計。這肯定不是一個好方法。邏輯設(shè)計模型有很多優(yōu)點,如:為各個單獨的小組成員同時高效工作供應(yīng)必需的組織和結(jié)構(gòu)規(guī)則。充當與外部項目和設(shè)計人員協(xié)作的基礎(chǔ)。降低困難性。供應(yīng)依據(jù)用戶需求(即方案)優(yōu)化設(shè)計的機會。在從邏輯設(shè)計到物理設(shè)計的過渡階段中,開發(fā)小組可以運用邏輯設(shè)計階段定義的服務(wù)和對象草稿起先物理設(shè)計。全部小組成員和該項目涉及的其他人員都應(yīng)當首先了解解決方案和整個系統(tǒng)結(jié)構(gòu)的狀況,包括系統(tǒng)中各部分之間的相互聯(lián)系。運用統(tǒng)一建模語言(UML)中定義的相互作用關(guān)系圖(依次關(guān)系圖)來獲得系統(tǒng)的動態(tài)相互作用關(guān)系是一個較好的方法。圖7是一個示例依次關(guān)系圖,摘自MicrosoftVisio2000聯(lián)機文檔。本關(guān)系圖源自O(shè)bjectSpace(://objectspace)(英文)公司的CraigLarman所寫的面對對象的分析和設(shè)計材料。在物理設(shè)計階段,開發(fā)小組應(yīng)專注于能優(yōu)化或改進設(shè)計模型的設(shè)計因素。本文其余部分將集中探討適用于運用Web存儲系統(tǒng)進行設(shè)計須要留意的最佳方法。圖5.依次關(guān)系圖示例

用戶服務(wù)設(shè)計的最佳方法正如上文所述,用戶服務(wù)是供應(yīng)應(yīng)用程序界面的應(yīng)用程序邏輯單元。其設(shè)計活動的中心通常是圖形用戶界面(GUI)和/或應(yīng)用程序編程接口(API)。以下是運用Web存儲系統(tǒng)設(shè)計用戶服務(wù)的一組最佳方法:通過考察關(guān)鍵運用方案確定一般用戶服務(wù)在邏輯設(shè)計階段,小組要考察各種運用方案,尤其是與用戶(或UML中的“操作者”)相互作用的狀況。多數(shù)狀況下,從方案中確定用戶服務(wù)會特別簡潔。但是,要找到可重復(fù)利用的用戶服務(wù)就須要額外的精力和閱歷了。示例:在設(shè)計雇員KM入口Web站點時,內(nèi)容搜尋用戶服務(wù)和分類選擇用戶服務(wù)可能會在整個Web站點中重復(fù)利用。運用新的數(shù)字儀表板框架數(shù)字儀表板概述:數(shù)字儀表板是學(xué)問工作者的自定義解決方案,它將個人、小組、公司以及外部的信息綜合在一起,并很簡潔運用分析和協(xié)作工具。運用數(shù)字儀表板資源工具包(DDRK)2.0(英文),公司很快就能夠建立并部署自定義的數(shù)字儀表板解決方案。DDRK中包含全部必需的工具和文檔、示例儀表板以及可馬上用于各種數(shù)字儀表板的組件。數(shù)字儀表板由Web部件(可重復(fù)運用的組件,包含任何形式基于Web的信息)組成。生成Web部件很簡潔;最終用戶可在儀表板中創(chuàng)建簡潔的Web部件。開發(fā)人員運用Web部件生成器可以創(chuàng)建更加困難的Web部件。通常數(shù)字儀表板應(yīng)用程序有一個增加的用戶界面,它將常見的MicrosoftOffice功能與易用的Web閱讀器風格的控件相結(jié)合。用戶只需點擊一下,就可運用簡便的工具來自定義數(shù)字儀表板、創(chuàng)建新的Web部件或者從Internet或本地Intranet上的Web部件庫中導(dǎo)入Web部件。圖8顯示一個名為AdventureWorks的虛構(gòu)的公司的數(shù)字儀表板。這個數(shù)字儀表板包含的Web部件顯示用戶收件箱、MSNMessengerService、日歷以及有關(guān)該公司的關(guān)鍵信息。圖6.數(shù)字儀表板示例實現(xiàn)用作Web部件的一般用戶服務(wù)數(shù)字儀表板的核心是Web部件。Web部件是可以重復(fù)運用的組件,它包括基于Web的內(nèi)容(如XML、HTML)和腳本,還包括一組標準屬性,用于限制Web部件在數(shù)字儀表板中的顯示方式。這些屬性使Web部件和儀表板成為中立的存儲空間并且完全可以重復(fù)運用。因為Web部件遵守一般標準,您可以把它們存儲在庫中,從這個庫中您可以提取Web部件來組成您的組織中的全部數(shù)字儀表板。很多Web部件和儀表板都具有用戶專用的屬性,但假如您是管理員,可以限制用戶能夠更改Web部件或儀表板的程度。通過UI設(shè)計指南定義一樣的外觀定義一組UI設(shè)計指南是個好方法。這樣能夠保證KM解決方案有一樣的外觀。例如,為了運用戶對您的KM入口Web站點更加滿足,就要為一般KM用戶服務(wù)設(shè)計一樣的UI,這些服務(wù)包括:導(dǎo)航服務(wù)內(nèi)容搜尋服務(wù)分類選擇服務(wù)內(nèi)容表示服務(wù)盡量運用OutlookWebAccess只須要重復(fù)運用OutlookWebAccess中的某些部分,您就可創(chuàng)建自定義的Web頁面。這些部分可以嵌入到Web頁面中。可運用表、框架和iFrame來支配OutlookWebAccess的各個部分。OutlookWebAccess為每天的任務(wù)供應(yīng)了默認視圖—例如,查看收件箱和發(fā)件箱。通過指定其它參數(shù)可以操作默認視圖。例如,Web頁面可以包含用戶的收件箱和組日歷。在頁面的一角可以顯示一個商標或公司標識,在另一角有當前新聞和與內(nèi)部工具的鏈接。因為運用OutlookWebAccess可以在很大程度上減輕您的開發(fā)工作,您應(yīng)當盡可能地運用它。為自定義的內(nèi)容類和屬性運用Web存儲系統(tǒng)窗體假如已經(jīng)設(shè)計了自定義的內(nèi)容類和屬性,您應(yīng)當考慮運用Web存儲系統(tǒng)窗體。Web存儲系統(tǒng)窗體是一種基于Web的窗體技術(shù),它建立在Internet標準之上。Web存儲系統(tǒng)窗體是在Web存儲系統(tǒng)中注冊的Web頁面。注冊本身就是Web存儲系統(tǒng)數(shù)據(jù)存儲區(qū)中的一條記錄。Web存儲系統(tǒng)窗體被設(shè)計為能夠與符合HTML3.2標準的閱讀器一同工作。支持那些功能的閱讀器包括MicrosoftInternetExplorer3.0或更高版本以及NetscapeNavigator3或更高版本。Web存儲系統(tǒng)窗體有什么特殊之處呢?Web存儲系統(tǒng)窗體具有以下特點:以數(shù)據(jù)為中心:閱讀器懇求存儲區(qū)中某一項的URL。存儲區(qū)執(zhí)行與所懇求的項相對應(yīng)的窗體。適應(yīng)性強:窗體只須要了解如何處理某一特定語言、閱讀器或操作。存儲區(qū)能夠與懇求相適應(yīng)以保證執(zhí)行正確的窗體。原委什么是窗體?它是一個相當寬泛的詞匯,通常與通過協(xié)議與存儲區(qū)中數(shù)據(jù)綁定的HTML頁面相關(guān)。依據(jù)MicrosoftExchange產(chǎn)品組的編程經(jīng)理JamieCool的說法,更正式的定義為“一個過程,它運用通信,可通過HTML與用戶進行交互并操作數(shù)據(jù),從而響應(yīng)用戶的操作。”了解Web存儲系統(tǒng)窗體如何工作是必要的。Web存儲系統(tǒng)中的全部內(nèi)容都是可用URL尋址的。從Web進行訪問時,OutlookWebAccess為Web存儲系統(tǒng)中的全部項供應(yīng)默認的顯示方式。窗體注冊表允許開發(fā)人員覆蓋OutlookWebAccess中的默認顯示方式。Exchange接收到來自用戶閱讀器的懇求后,該懇求即被傳送給MicrosoftInternetInformation服務(wù)(IIS)。IIS調(diào)用ISAPIDLL。這與Web存儲系統(tǒng)用來處理全部/DAV懇求所運用的DLL相同。ISAPIDLL檢查窗體注冊表的窗體注冊。窗體注冊供應(yīng)一組針對窗體的屬性,如內(nèi)容類、用戶操作、語言、閱讀器類型、項狀態(tài)和兩個重要屬性:執(zhí)行URL:執(zhí)行該URL將顯示窗體。它可能是一個ISAPI篩選器(例如:/exchweb/bin/exwform.dll)或一個ASP頁面(例如:process.asp)。窗體URL:正在處理或顯示的窗體或模板的URL;當前URL所表示的項(例如:ExpenseForm.htm、ECOform.ASP)。處理從懇求報頭讀取的信息,并與存儲在Browsecap.ini中閱讀器的信息相比較,就可以得到閱讀器的功能信息。ISAPIDLL運用與窗體注冊表信息最佳匹配的比較來確定顯示哪一個窗體。有關(guān)Web存儲系統(tǒng)窗體的具體信息,請參考Exchange2000SDK。

設(shè)計業(yè)務(wù)服務(wù)的最佳方法正如上文所述,業(yè)務(wù)服務(wù)是一個應(yīng)用程序邏輯單元,它限制執(zhí)行業(yè)務(wù)規(guī)則的先后依次,保證所執(zhí)行操作的事務(wù)完整性。以下是一組運用Web存儲系統(tǒng)設(shè)計業(yè)務(wù)服務(wù)的最佳方法:通過運用方案確定關(guān)鍵業(yè)務(wù)過程在邏輯設(shè)計階段,開發(fā)小組應(yīng)檢查他們在概念設(shè)計階段收集的方案以確定業(yè)務(wù)過程,如文檔批準過程或內(nèi)容變換過程。確定實現(xiàn)機制在物理設(shè)計階段,開發(fā)小組須要確定這些業(yè)務(wù)過程最合適的實現(xiàn)機制。有四個基本選項:工作流引擎、事務(wù)接收器、COM+組件和腳本(客戶端或服務(wù)器端腳本)。運用腳本的方法會造成一些困難,如代碼不易維護以及腳本的局限性。因此,我們建議采納前三種方法。以下是確定實現(xiàn)方法的一組指南:假如業(yè)務(wù)過程符合以下狀況,則運用工作流:涉及多用戶和多資源。具有困難過程,如批準或業(yè)務(wù)驗證過程。假如出現(xiàn)以下狀況,則運用事務(wù)接收器:只涉及少量的用戶或資源。驗證過程簡潔。具有整個存儲區(qū)范圍內(nèi)的事務(wù)。具有定時器事務(wù)。假如運用Web存儲系統(tǒng)進行的大多是讀取操作而不是更新操作,且不涉及工作流,則運用COM+組件。

設(shè)計數(shù)據(jù)服務(wù)架構(gòu)的最佳方法正如上文所述,數(shù)據(jù)服務(wù)是供應(yīng)最低提取可見級別的應(yīng)用程序邏輯單元,用于操作數(shù)據(jù)。數(shù)據(jù)服務(wù)維護作為公司資產(chǎn)的永久和非永久數(shù)據(jù)的可用性和完整性。這一部分我們將探討Web存儲系統(tǒng)架構(gòu)設(shè)計,下一部分探討文件夾結(jié)構(gòu)。首先,什么是架構(gòu)?對于建立在Web存儲系統(tǒng)技術(shù)基礎(chǔ)上的整個物理設(shè)計模型來說,為什么架構(gòu)設(shè)計至關(guān)重要?架構(gòu)一詞指的是一種定義和組織數(shù)據(jù)(有時稱為元數(shù)據(jù))的方法。在結(jié)構(gòu)化查詢語言(SQL)關(guān)系型數(shù)據(jù)庫中,架構(gòu)包括全部的表定義和列定義,以及其它信息(如索引和觸發(fā)器)。對于存儲區(qū),我們將架構(gòu)設(shè)計的重心放在內(nèi)容類及與其相關(guān)聯(lián)的屬性集方面。架構(gòu)設(shè)計對整個KM解決方案是否勝利有干脆影響,尤其是在性能和可擴展性方面。架構(gòu)設(shè)計通常是定義數(shù)據(jù)服務(wù)模型的第一步。很多設(shè)計的考慮因素和決策都要依靠架構(gòu)設(shè)計。下面一段是對Web存儲系統(tǒng)架構(gòu)的簡要介紹。Web存儲系統(tǒng)可用于為您的應(yīng)用程序定義架構(gòu)。Web存儲系統(tǒng)架構(gòu)是以內(nèi)容類為中心的。內(nèi)容類為存儲區(qū)中的項/實例定義架構(gòu)類,是屬性集的邏輯容器。為您的應(yīng)用程序創(chuàng)建架構(gòu)定義時,要定義自定義內(nèi)容類及相關(guān)的屬性。Web存儲系統(tǒng)含有大量預(yù)定義的內(nèi)容類和屬性。定義自己的自定義內(nèi)容類時,您可以運用或擴展(子類)某一預(yù)定義內(nèi)容類。其中包括(但不僅限于)表2.所列的內(nèi)容類。表2.內(nèi)容類內(nèi)容類說明urn:content-classes:item存儲區(qū)中各項的基類urn:content-classes:message消息的基類urn:content-classes:calendarmessage會議懇求和響應(yīng)的基類urn:content-classes:appointment約會的基類urn:content-classes:person聯(lián)系人項的基類urn:content-classes:folder文件夾的基類urn:content-classes:documentMicrosoftOffice文檔的基類Web存儲系統(tǒng)架構(gòu)的一個特長是它們?yōu)榧軜?gòu)感知的應(yīng)用程序和工具供應(yīng)了一種方法,可用來查找出適用于某一特定應(yīng)用程序的內(nèi)容類和屬性的名稱。與某一特定應(yīng)用程序相關(guān)的架構(gòu)信息是通過文件夾的架構(gòu)范圍來限制的。文件夾的架構(gòu)范圍是一組按某特定依次遍歷的文件夾,它們包含架構(gòu)定義項。通過在Web存儲系統(tǒng)(其中存儲您的架構(gòu)信息)中定義文件夾的列表,你可以逐個文件夾地擴展架構(gòu)。范圍可以很簡潔,只包含全局架構(gòu)文件夾;也可以比較困難,包含一個很大的文件夾URL的列表。還須要查看以下兩個屬性來定義架構(gòu)范圍,這兩個屬性對整體架構(gòu)設(shè)計—尤其是文件夾結(jié)構(gòu)—也很重要,我們將在下一部分探討這一主題。schema-collection-ref(SCR):這一屬性是一個文件夾的URL,將在該文件夾中查找內(nèi)容類和屬性定義。這是搜尋架構(gòu)定義項的第一個文件夾,并且總是文件夾架構(gòu)范圍中的第一個文件夾。假如未設(shè)置這個屬性,則默認為存儲區(qū)的non_ipm_subtree/Schema文件夾,其中包含Web存儲系統(tǒng)的默認架構(gòu)定義項。Baseschema:這一屬性是個多值字符串,包含一個或多個文件夾的URL。通過確定包含架構(gòu)定義項的其它文件夾,可以擴展某文件夾的架構(gòu)范圍。除了定義自定義內(nèi)容類之外,定義自定義屬性是架構(gòu)設(shè)計的另一個重要方面。雖然Web存儲系統(tǒng)供應(yīng)很多預(yù)定義的屬性,您可以為每一項存儲隨意數(shù)量的其它屬性;這些屬性就稱為自定義屬性。您還可以對每一項定義一組不同的自定義屬性。自定義屬性與它的關(guān)聯(lián)項一起保存。檢查項時可以按名稱發(fā)出懇求。假如運用ExchangeOLEDB供應(yīng)程序或ADO干脆綁定到項上,或通過/WebDAV協(xié)議發(fā)出一個0深度的PROPFIND吩咐,Web存儲系統(tǒng)將返回該項的全部自定義屬性。對于全部深度為1的項屬性,自定義屬性對SQL“SELECT*”語句或PROPFIND吩咐都是不行見的,除非這些屬性被定義為項的內(nèi)容類的一部分。因此,要使架構(gòu)感知的應(yīng)用程序能識別您的屬性,必需把屬性和內(nèi)容類的定義添加到應(yīng)用程序文件夾的架構(gòu)范圍中。下面我們對一些通用的架構(gòu)設(shè)計指南作一總結(jié)。假如您不熟識URN、URI和URL這些詞,在接著之前建議您看一看下面的定義。URI、URN和URL統(tǒng)一資源標識符(URI)就是一個采納肯定格式的字符串,它可用來唯一地標識一個資源。URI可以是一個統(tǒng)一資源定位符(URL)或一個統(tǒng)一資源名稱(URN)。URL對定位所標識資源所需的底層協(xié)議進行編碼。而URN則與位置無關(guān),而且與定位所標識資源要運用的協(xié)議或機制也毫無關(guān)系。URL開頭帶有一個標識協(xié)議的前綴,接著是一個針對協(xié)議的字符串。對于URL,語法如下:"://"<host>[":"<port>][<path>["?"<query>]]<host>是服務(wù)器的IP地址,<port>是服務(wù)器偵聽的TCP端口號,<path>是在懇求中作為懇求URI傳遞的肯定URI??蛇x的<query>對應(yīng)于查詢字符串后綴,即用&分隔的關(guān)鍵字/值對的列表。只有URL的主機部分是必需的。假如未指定端口,默認為端口80;假如未指定路徑,懇求URI將為“/”。URN對建立現(xiàn)代的、相宜Internet的應(yīng)用程序是至關(guān)重要的,但人們對它還遠遠不夠熟識。目前還沒有一種通用的方式來間接訪問URN以查找它所標識的資源。URN的語法結(jié)構(gòu)保證了URN跨多個組織的唯一性。其語法如下所示:"urn:"<NID>":"<NSS><NID>是命名空間標識符,<NSS>是命名空間特定的字符串。假如要標識與位置無關(guān)的內(nèi)容,建議您運用URN機制。對于還須要包含位置信息的標識符,則建議運用URL機制。架構(gòu)設(shè)計指南架構(gòu)設(shè)計指南的內(nèi)容如下:運用和定義命名空間(URN)運用命名空間定義屬性和內(nèi)容類是一種好方法。命名空間的作用包括:有助于確保屬性和類的名稱是全局唯一的;即,解決識別和沖突的問題。假如您有多個應(yīng)用程序在同一時間部署,或者獨立軟件開發(fā)商(ISV)在一個大型組織中部署他們的應(yīng)用程序時,這一點都是特殊重要的。指示“擁有”屬性或類定義的個體或組織。在隨Exchange2000供應(yīng)的預(yù)定義屬性和類中,您會發(fā)覺有很多不同類型的命名空間:urn:schemas:mail:urn:schemas-microsoft-com:exch-data:urn:schemas-microsoft-com:office:office第一個示例是一種通用的廣為接受的命名空間,目的是為了增加各種架構(gòu)感知應(yīng)用程序間的互操作性。接下來的兩個是專用URN。假如您希望為您的應(yīng)用程序創(chuàng)建一個類似的命名空間,您可以創(chuàng)建urn:schemas-mycompanysdomain-com:myapplication:。其次個和第三個命名空間的差別就在于:其次個命名空間的結(jié)尾有一個命名空間分隔符而第三個命名空間沒有。假如命名空間以分隔符“:”或“/”結(jié)尾,將創(chuàng)建屬性或內(nèi)容類名稱,且屬性名附于命名空間后。例如,其次個命名空間中的一個屬性是urn:schemas-microsoft-com:exch-data:ismultivalued。假如命名空間不以分隔符結(jié)尾(如第三個示例),則該命名空間中將創(chuàng)建屬性名,命名空間與屬性名之間有一個符號“#”。例如,第三個命名空間中的一個屬性是urn:schemas-microsoft-com:office:office#Author。最終一個命名空間示例顯示如何將URL用作命名空間。您應(yīng)當從您擁有或已注冊的URL中選擇基于URL的命名空間。這將有助于保證命名空間的唯一性。URL用作命名空間時,最終一個分隔符為字符“/”。不應(yīng)向您不擁有的命名空間中添加屬性或內(nèi)容類。例如,向://schemas.microsoft/exchange/或DAV:命名空間添加屬性就不好,而應(yīng)當為您的內(nèi)容類和屬性創(chuàng)建自己的命名空間。進行屬性定義Web存儲系統(tǒng)本身對屬性名稱中可運用哪些字符沒有特殊的限制。但是,最好還是遵守以下一些約定:應(yīng)當運用命名空間來創(chuàng)建屬性并加上一個標識符(如上文所述)。例如,urn:schemas-sample-com:engineering:eco.屬性應(yīng)當是格式正確的URI。屬性名稱中不應(yīng)有空格,因為XML不支持在元素名稱中運用空格,因此-DAV也不支持。定義自定義內(nèi)容類在定義了這些自定義屬性之后,下一步就是定義您的自定義內(nèi)容類。首先,您須要為應(yīng)用程序選擇一個文件夾,用來存儲架構(gòu)信息。您可以將這些信息存儲在您的應(yīng)用程序數(shù)據(jù)所在的同一文件夾中,但我們劇烈建議您運用一個不同的子文件夾,我們稱之為架構(gòu)文件夾。假如您在正定義的架構(gòu)不是針對某一個應(yīng)用程序的,您可以在相關(guān)的公共存儲區(qū)里的高層架構(gòu)文件夾中定義它。存儲架構(gòu)定義的位置和組織架構(gòu)定義的方式由您確定。但是,在下一部分中,我們將舉薦一組方式,指導(dǎo)您如何組織文件夾結(jié)構(gòu)以及如何確定對一組特定應(yīng)用程序數(shù)據(jù)應(yīng)用哪一個架構(gòu)定義。下面的關(guān)系圖闡釋了運用一個Exchange2000SDK工具(即:Web存儲系統(tǒng)架構(gòu)設(shè)計器)來自定義內(nèi)容類的一個示例。我們建議您運用該工具或類似工具來定義自定義內(nèi)容類的定義和屬性定義。圖7.示例:架構(gòu)設(shè)計考慮內(nèi)容類的繼承性您當然可以從頭起先定義一個全新的內(nèi)容類。不過,多數(shù)內(nèi)容類都可以擴展(“繼承”)現(xiàn)存的內(nèi)容類。擴展內(nèi)容類意味著已擴展的(派生的)內(nèi)容類實例的全部屬性也存在于擴展中的(基本的)內(nèi)容類實例中。這一概念與C++這樣的面對對象(OO)的編程語言中類繼承的概念相像。圖10顯示一個簡潔的繼承方案。擴展文檔類意味著任何可在文檔類實例上執(zhí)行的代碼或操作都可以在expensereport類實例上執(zhí)行。圖8.簡潔內(nèi)容類繼承圖9.帶有多個繼承關(guān)系的內(nèi)容類內(nèi)容類也可擴展為多個內(nèi)容類。在圖11中,我們還能看到一個expensereport類,它具有totalcost和approvastate兩種屬性。但在這一方案中我們希望有作為文檔的一個特定類的費用報告和作為消息的一個特定類的費用報告。因此,我們創(chuàng)建一個exprensereport類來擴展該類。然后創(chuàng)建一個exprensemessage類和一個exprensedocument類,它們自己沒有其它屬性。Expensemessage擴展了expensereport和message,而exprensedocument擴展了exprensereport和document?,F(xiàn)在,理解message類的應(yīng)用程序就可以理解expensemessage類的一些屬性,而把其余屬性當作自定義屬性。理解document類的應(yīng)用程序就可以理解exprensedocument類的一些屬性。有關(guān)架構(gòu)設(shè)計的具體信息,請參考Exchange2000SDK以及白皮書“Web存儲系統(tǒng)架構(gòu):運用和最佳方法指南?!?/p>

Web存儲系統(tǒng)文件夾結(jié)構(gòu)的最佳方法Web存儲系統(tǒng)為設(shè)計文件夾結(jié)構(gòu)供應(yīng)了很大的敏捷性。架構(gòu)定義項可置于特定存儲區(qū)內(nèi)的任一文件夾中,并用于為您的應(yīng)用程序定義架構(gòu)。通過合理設(shè)置不同文件夾的schema-collection-ref和baseschema屬性,您可以將這些定義引入到范圍中來。為了避開設(shè)計和管理應(yīng)用程序架構(gòu)太過困難,應(yīng)規(guī)劃并組織好您的架構(gòu)信息。例如,可以選擇在您指定為架構(gòu)文件夾的應(yīng)用程序文件夾的頂層下創(chuàng)建文件夾。設(shè)計文件夾結(jié)構(gòu)有很多種方式。以下步驟概述了這一過程??紤]以下各項:邏輯模型的困難程度:正如上文所述,設(shè)計存儲區(qū)的架構(gòu)有很多方式。在作出最終設(shè)計確定前應(yīng)當考察全部相關(guān)的信息和設(shè)計選項。物理模型的困難程度:您應(yīng)當考慮到維護困難文件夾結(jié)構(gòu)的困難程度。性能影響:將在以后的部分中探討。重復(fù)運用和共享架構(gòu)。將架構(gòu)文件夾與其它類型的文件夾區(qū)分開來,例如:應(yīng)用程序文件夾:包括ASP頁面、HTML頁面、Web存儲系統(tǒng)窗體等等。數(shù)據(jù)(內(nèi)容)文件夾:包括數(shù)據(jù)項或文檔。窗體注冊文件夾:包括窗體注冊項。通常,特定應(yīng)用程序的架構(gòu)定義將置于它們自己的文件夾中。將應(yīng)用程序文件夾和數(shù)據(jù)文件夾分開也是一種好方法。正如上文所述,特定文件夾的schema-collection-ref(SCR)和baseschema屬性確定架構(gòu)范圍。設(shè)計文件夾結(jié)構(gòu)有很多敏捷的方式。文件夾結(jié)構(gòu)的示例如下:一個簡潔的應(yīng)用程序可以有一個包含應(yīng)用程序文件(ASP、HTML頁面)和數(shù)據(jù)項的文件夾,以及一個架構(gòu)文件夾。略微困難點的應(yīng)用程序可以分別有單獨的應(yīng)用程序文件夾、數(shù)據(jù)文件夾和架構(gòu)文件夾。架構(gòu)文件夾可以有不同的級別,如頂級架構(gòu)文件夾包含在同一根下運行的全部應(yīng)用程序。也可以采納一系列架構(gòu)文件夾,每個架構(gòu)文件夾通過SCR引用另一個架構(gòu)文件夾。定義架構(gòu)文件夾。定義常用的內(nèi)容類和屬性定義。定義窗體注冊。(這可能在一個單獨的窗體注冊文件夾中。)創(chuàng)建架構(gòu)文件夾時,您必需確定這些文件夾的范圍。即,某一給定的架構(gòu)文件夾適用于哪些數(shù)據(jù)文件夾?隨意數(shù)量的數(shù)據(jù)文件夾可以運用一個架構(gòu)文件夾。反之,在多個架構(gòu)文件夾中定義的架構(gòu)可以應(yīng)用于一個數(shù)據(jù)文件夾。正如上文所述,schema-collection-ref是一個可在數(shù)據(jù)文件夾上設(shè)置的屬性,用來指示在查找相關(guān)屬性和內(nèi)容類定義時應(yīng)首先搜尋哪個架構(gòu)文件夾。baseschema屬性則形成一個架構(gòu)文件夾的樹形結(jié)構(gòu)來搜尋架構(gòu)定義。在這個架構(gòu)文件夾的邏輯樹中,每個節(jié)點都可有很多子節(jié)點。這個架構(gòu)文件夾的邏輯樹可以(并且通常會)與存儲區(qū)中文件夾的物理布局不同。相對于給定的數(shù)據(jù)文件夾,schema-collection-ref屬性指示搜尋始于哪個架構(gòu)文件夾。定義應(yīng)用程序和數(shù)據(jù)文件夾。假如須要,將schema-collection-ref(SCR)屬性指向架構(gòu)文件夾。運用baseclass和expected-content-class。

SQL與Web存儲系統(tǒng)這一部分我們考察SQL關(guān)系型數(shù)據(jù)庫和Web存儲系統(tǒng)間的主要差別;探討何時運用SQL以及何時運用Web存儲系統(tǒng);并供應(yīng)一套指南,用于從已有的SQL數(shù)據(jù)庫向Web存儲系統(tǒng)移植數(shù)據(jù)。表3闡釋了SQL數(shù)據(jù)庫與Web存儲系統(tǒng)的不同之處。留意SQL數(shù)據(jù)庫與基于Web存儲系統(tǒng)的Microsoft產(chǎn)品(如Exchange2000)有一組相同的服務(wù)。表3.SQL數(shù)據(jù)庫和Web存儲系統(tǒng)SQL數(shù)據(jù)庫Web存儲系統(tǒng)關(guān)系型數(shù)據(jù)庫類似于對象數(shù)據(jù)庫結(jié)構(gòu)化數(shù)據(jù)半結(jié)構(gòu)化數(shù)據(jù)表文件夾(以及內(nèi)容類)列內(nèi)容類和屬性固定行不固定行集中于業(yè)務(wù)智能協(xié)作以事務(wù)為中心以文檔為中心數(shù)據(jù)完整性:主鍵/外鍵無主鍵/外鍵矩形數(shù)據(jù)非矩形觸發(fā)器事務(wù)接收存儲過程無可比實體(與之類似的是事務(wù))假如現(xiàn)有的KM解決方案正在從SQL關(guān)系型數(shù)據(jù)庫中讀取數(shù)據(jù),而這些數(shù)據(jù)是典型的非矩形半結(jié)構(gòu)化數(shù)據(jù),您最好考慮將這些數(shù)據(jù)從SQL移植到Web存儲系統(tǒng)。請參照以下指南,將數(shù)據(jù)從SQL移植到Web存儲系統(tǒng):首先,將SQL列映射到屬性,將SQL表映射到文件夾和內(nèi)容類。確定表的主鍵和外鍵。依據(jù)邏輯設(shè)計模型查找與之對應(yīng)的內(nèi)容類。通過確定一組能生成項的唯一實例的屬性來模擬主鍵??紤]內(nèi)容類的繼承性。

物理設(shè)計考慮因素到此,我們已經(jīng)探討了設(shè)計用戶服務(wù)、業(yè)務(wù)服務(wù)和數(shù)據(jù)服務(wù)的最佳方法。這一部分我們將集中探討物理設(shè)計階段針對Web存儲系統(tǒng)的設(shè)計考慮因素。對每個設(shè)計考慮因素主題,我們都將介紹一些重要的概念、探討一些您可以實行的折衷措施,并列出一張清單,供您在考慮各種選項時參考。

平安模型這一部分中概述了Web存儲系統(tǒng)平安模型。除了運用MAPI客戶程序(如Outlook)或Windows文件系統(tǒng)API來限制平安設(shè)置外,您還可以運用基于XML的平安描述符來限制對某一項及其屬性的訪問。運用Web存儲系統(tǒng)平安描述符,您可以:既可將對某一項及其屬性的訪問權(quán)授予受托者(具有憑證、正在訪問該項的人),也可以拒絕該受托者進行訪問。運用MicrosoftWindows?平安標識符(SID)標識受托者。設(shè)置、檢索和修改XML格式的描述符。運用MicrosoftExchangeOLEDB(ExOLEDB)供應(yīng)程序和XML格式的/WebDAV協(xié)議訪問描述符。每一項的平安描述符都通過該項的://schemas.microsoft/exchange/security/descriptor屬性訪問。這個屬性是項的XML格式的描述符。該描述符以Exchange2000Server特有的二進制格式進行物理存儲和復(fù)制,這種格式內(nèi)部是基于標準的Windows2000描述符格式的。假如文件夾中的某項沒有特定的平安描述符,其父文件夾中指定的默認權(quán)限將被應(yīng)用于該項。平安描述符是一種數(shù)據(jù)結(jié)構(gòu),它包含以下內(nèi)容(以及其它未列出的內(nèi)容):一個全部者字段,其中包含對象全部者的平安標識符(SID),該對象與平安描述符相關(guān)聯(lián)。一個隨意訪問限制列表(DACL)字段,指定誰對該對象字段具有訪問權(quán)。一個系統(tǒng)訪問限制列表(SACL),指定系統(tǒng)可以審計哪些操作。訪問限制列表(ACL)包含一個或多個訪問限制項(ACE);每個ACE為平安負責人指定訪問權(quán)限。Windows2000中的平安負責人可以是一個用戶或一組用戶。Exchange2000定義了一個新的平安負責人,叫做角色。角色是一個具出名稱的平安負責人(用戶或組)的集合,它可在ACL里的ACE中引用。角色與Windows2000組之間主要的區(qū)分在于Exchange平安角色是針對對象本身定義和存儲的。也就是說不須要進行具備特權(quán)的書目服務(wù)操作,就可以創(chuàng)建這些角色,并填入成員。對于不須要具備特定Windows2000組就可以部署的應(yīng)用程序,這一功能是特別重要的。平安角色在Web存儲系統(tǒng)中創(chuàng)建和存儲,而與Windows2000書目服務(wù)無關(guān)。對應(yīng)用程序開發(fā)人員來說,平安角色具備兩個明顯的優(yōu)勢:創(chuàng)建角色不須要運用特權(quán)的ActiveDirectory?操作—而這是分部門方案的一個關(guān)鍵要求。因為角色的作用范圍是特定的文件夾(或按文件夾層次結(jié)構(gòu)組織的應(yīng)用程序),因此只在文件夾范圍內(nèi)要求角色的名稱唯一。這樣,部署在一臺運行ExchangeServer的計算機上的兩個應(yīng)用程序不須要運用不同的角色名稱和成員。因為角色只在應(yīng)用程序的設(shè)計階段才被引用,所以它們在應(yīng)用程序中只是存在,而不產(chǎn)生影響。程序運行時將評估它們,所以應(yīng)用程序開發(fā)人員可以等到部署應(yīng)用程序時才加入這些角色。這樣程序開發(fā)人員就不必為每次部署而重新編譯應(yīng)用程序。正如上文所述,只要可以對文件夾和項設(shè)置ACL,就可以在Web存儲系統(tǒng)中運用角色。在用戶對某項或文件夾(對象或父對象)定義的“角色成員”屬性中填入一個平安負責人(用戶、組或角色)列表,就可以實現(xiàn)平安角色。具體說來,該列表包含平安標識符(SID),這些SID代表了平安負責人并為給定角色形成成員列表。角色SID與Windows2000SID不同,ExchangeServer(而不是Windows)擁有對它的平安限制。角色SID是獨立結(jié)構(gòu)的,不包含任何Windows2000的特定平安信息,因此可在多個域中運用。角色SID將為兩種信息進行編碼:屬性:角色屬性包含SID列表,ACE就應(yīng)用于這些SID。這一列表中的SID既可以是Windows2000SID,也可以是角色SID。范圍:該信息指示讀取角色屬性的位置。有關(guān)平安角色的具體信息,請參考Web存儲系統(tǒng)平安角色(英文)。運用Web存儲系統(tǒng)設(shè)計KM解決方案的平安模型時,您應(yīng)當考慮以下列出的內(nèi)容:通過概念設(shè)計模型和邏輯設(shè)計模型確定平安需求用戶—他們的角色和內(nèi)容訪問需求業(yè)務(wù)需求,例如隱私和其它有關(guān)法律的需求外部訪問“角色”一詞這里表示業(yè)務(wù)角色,而不是我們前面探討的Exchange角色。即在您起先定義平安模型前應(yīng)收集盡可能多的信息。定義平安策略依據(jù)業(yè)務(wù)需求將用戶分組定義用戶角色定義應(yīng)用程序平安模型—例如,誰可以創(chuàng)建事務(wù)或工作流定義內(nèi)容平安模型—例如,項一級的平安、屬性一級的平安定義外部訪問—例如,防火墻和與公共密鑰基礎(chǔ)結(jié)構(gòu)(PKI)的集成

性能KM解決方案的性能特征通常與聯(lián)機事務(wù)解決方案有顯著區(qū)分。它不是快速計算數(shù)字,而是留意以下性能特征:返回搜尋結(jié)果或定位具體內(nèi)容的響應(yīng)時間。創(chuàng)建、分類和檢索內(nèi)容的響應(yīng)時間。處理業(yè)務(wù)過程(例如批準過程)的響應(yīng)時間。正如上文所述,Web存儲系統(tǒng)為建立KM解決方案供應(yīng)了強大的功能和高度的敏捷性。要充分利用這些功能,您須要留意數(shù)據(jù)訪問和處理方式對性能的影響。要獲得最佳性能,請遵循以下指南:頻繁執(zhí)行深度遍歷搜尋時運用搜尋文件夾假如您有一個分層文件夾結(jié)構(gòu),并且您的應(yīng)用程序必需執(zhí)行對該層次結(jié)構(gòu)的深度遍歷搜尋,運用搜尋文件夾可以極大提高應(yīng)用程序的性能。設(shè)置搜尋文件夾還可以用來將大文件夾分割成較小的文件夾(依據(jù)邏輯關(guān)系)。例如,假設(shè)有一個KM應(yīng)用程序,用來跟蹤記錄公司雇員生成的各種項目文檔。一起先,有成千上萬個文檔須要跟蹤記錄,這些文檔是依據(jù)主題在分層結(jié)構(gòu)中組織的。每一天系統(tǒng)中的文檔都會被頻繁添加或刪除。在一個正常工作日中,雇員須要頻繁搜尋存儲區(qū)中的全部文檔才能找到由某些作者編寫的文檔。由于搜尋必需閱讀的記錄和文件夾的數(shù)量極大,要在整個層次結(jié)構(gòu)中執(zhí)行這些搜尋,成本會相當昂揚。在這種狀況下,這種成本昂揚的、對全部記錄進行的搜尋只須要執(zhí)行一次,其結(jié)果可以添加到一個搜尋文件夾中。這個搜尋文件夾現(xiàn)在包含存儲區(qū)中這些作者編寫的全部文檔。假如某些文檔被添加到存儲區(qū)(和層次結(jié)構(gòu))或從中刪除,Web存儲系統(tǒng)會在必要的時候更新搜尋文件夾。假如雇員要搜尋存儲區(qū)中的文檔,只須要在搜尋文件夾中而不是層次結(jié)構(gòu)中進行搜尋。這樣可以搜尋到全部相關(guān)記錄,但不必閱讀整個層次結(jié)構(gòu)。運用搜尋文件夾可能造成添加/更新/刪除那些用于創(chuàng)建該搜尋文件夾的、在查詢范圍內(nèi)的項時,性能會稍有下降。這種延遲是因為每次進行這樣的操作后都必需更新搜尋文件夾。因此,我們建議只有在被搜尋數(shù)據(jù)不會頻繁更新的狀況下,才應(yīng)在頻繁進行的查詢中運用搜尋文件夾。頻繁搜尋地索引屬性為屬性一級編制索引是為頻繁執(zhí)行的搜尋提高性能的最好方式。假如變更用于計算那個利用了已索引屬性的where子句的表達式的成本,就可以將顯著改善搜尋性能。有關(guān)創(chuàng)建索引的信息,請參考Exchange2000SDK中的“屬性索引”主題。為屬性一級編制索引只能對在用于搜尋的where子句中運用已索引屬性的狀況下,幫助改善搜尋性能。運用屬性一級的索引時,應(yīng)用程序從已創(chuàng)建索引的文件夾中執(zhí)行插入/更新/刪除項的操作時時,將出現(xiàn)稍微的性能下降(大約每個索引1%)。發(fā)生這種性能降低的緣由是須要更新文件夾索引信息以反映更新操作。由于存在這一問題,為了盡可能優(yōu)化應(yīng)用程序的性能,只應(yīng)對頻繁搜尋的屬性創(chuàng)建索引。只在肯定必要時執(zhí)行“SELECT*”操作執(zhí)行“SELECT*”操作要求Web存儲系統(tǒng)在架構(gòu)中進行查找被搜尋項,以確定要返回哪一組屬性。架構(gòu)計算的成本可能很高,而且最終成為搜尋懇求的總成本中很大的一部分。假如只懇求須要的列,應(yīng)用程序可以避開這部分的額外成本開支。例如,假如某項有一個關(guān)聯(lián)的自定義架構(gòu),它包含屬性“DAV:displayname”和“DAV:lastmodified”,下面的第一個搜尋執(zhí)行起來將比其次個快得多,盡管它們返回的數(shù)據(jù)相同。"SELECT"DAV:displayname","DAV:lastmodified"fromscope('SHALLOWTRAVERSALOF"://myserver/public"')"SELECT*fromscope('SHALLOWTRAVERSALOF"://myserver/public"')"只搜尋文件夾時執(zhí)行層次結(jié)構(gòu)的遍歷。假如是搜尋文件夾,通過指定搜尋應(yīng)運用層次結(jié)構(gòu)而非深度遍歷,應(yīng)用程序可以提高搜尋性能。例如,下面的兩個搜尋將返回相同的資源,但與其次個搜尋相比,第一個搜尋的返回速度更快,而且運用的服務(wù)器資源也較少。"SELECT"DAV:displayname"fromscope('HIERARCHICALTRAVERSALOF"://myserver/public"')"SELECT"DAV:displayname"fromscope('DEEPTRAVERSALOF"://myserver/public"')WHERE"DAV:iscollection"=true盡可能指定多個淺層范圍,而不是執(zhí)行深度遍歷搜尋執(zhí)行多個淺層遍歷搜尋比執(zhí)行一個深度遍歷搜尋的效率高。深度遍歷搜尋要求Web存儲系統(tǒng)鎖定待搜尋的層次結(jié)構(gòu)(避開執(zhí)行搜尋時層次結(jié)構(gòu)發(fā)生變更),但是淺層遍歷搜尋沒有這一限制。構(gòu)建搜尋懇求時,可以在查詢中指定多個范圍。全部列出的范圍必需是相同類型的范圍(即,都是深度的或都是淺層的)。有關(guān)具體信息,請參考Exchange2000SDK中的“搜尋范圍”主題。保守運用同步事務(wù)創(chuàng)建Web存儲系統(tǒng)應(yīng)用程序時,同步事務(wù)是一個強有力的工具,但它們也可能給性能帶來嚴峻影響。假如正在執(zhí)行的同步事務(wù)運用某給定資源,全部要運用該資源的其它操作都將被堵塞,直到該同步事務(wù)完成為止。因此,應(yīng)盡可能運用異步事務(wù)。異步事務(wù)的功能不猶如步事務(wù)豐富,但在對資源進行非串行化訪問時,異步事務(wù)更有優(yōu)勢。對與事務(wù)一同運用的COM+組件進行性能調(diào)整運用COM+組件實施事務(wù)時,應(yīng)遵循調(diào)整COM+組件的正規(guī)操作方式。

可伸縮性與可用性Exchange2000相對于ExchangeServer的以前版本在可伸縮性與可用性方面有很大的改進。Exchange2000中有助于改善應(yīng)用程序可伸縮性與牢靠性的功能包括:多個存儲區(qū)和存儲組,削減了備份和復(fù)原的時間,并擴展可伸縮性與牢靠性?;顒?活動群集,留意提高KM應(yīng)用程序的牢靠性和可訪問性。網(wǎng)絡(luò)負載平衡,它代表另一種形式的群集化,留意在多個服務(wù)器間安排網(wǎng)絡(luò)流量,而不是在發(fā)生服務(wù)器故障時確??稍L問性(象在活動/活動群集中那樣)。分布式前臺/后臺服務(wù)器配置結(jié)構(gòu),從而可以在多個服務(wù)器上劃分服務(wù)分區(qū),并且在此過程中允許Exchange擴展到能夠滿足大規(guī)模的企業(yè)、ISP以及ASP的須要。運用Windows2000ActiveDirectory滿足平安要求,以便處理集中管理和牢靠性的問題。Web存儲系統(tǒng)依靠存儲組、多數(shù)據(jù)庫、群集以及自身MIME存儲,不僅可以與IIS集成和快速傳遞流媒體文件,并且供應(yīng)可伸縮性與牢靠性。除此之外,Exchange還負責存儲區(qū)的復(fù)制,以便在須要時還可以運用這部分存儲區(qū)。有關(guān)上述功能的具體信息,請參考Exchange2000聯(lián)機文檔和以下白皮書:MicrosoftExchange2000群集(英文)Exchange2000前臺和后臺拓撲結(jié)構(gòu)(英文)開發(fā)ASP主機的ExchangeService的最佳方法(英文)

指南回顧概括起來,以下是運用Exchange2000/Web存儲系統(tǒng)設(shè)計KM解決方案的指南的列表:對不同應(yīng)用程序創(chuàng)建和劃分多個存儲區(qū)現(xiàn)在,Exchange2000支持包含多個公共文件夾樹,或稱為頂級層次結(jié)構(gòu)(TLH)的功能。此外,對于每個公共文件夾樹來說,Exchange2000僅將其復(fù)制到各服務(wù)器的一個公共文件夾存儲區(qū)中。由于這種復(fù)制帶有更多的限制,管理人員現(xiàn)在可以將選定的幾組公共文件夾分別限定在各個服務(wù)器上,這樣更簡潔限制,還可以提高在這些存儲區(qū)上運行的應(yīng)用程序的可用性。在單獨的驅(qū)動器上安裝并愛護事務(wù)日志為了保證容錯性,以及即使服務(wù)器發(fā)生故障后仍能復(fù)原存儲區(qū),Exchange2000與它以前的版本一樣都要依靠于事務(wù)日志文件中的事務(wù)記錄。事務(wù)日志充當內(nèi)存與磁盤上數(shù)據(jù)庫之間的防錯中介。在設(shè)置和管理事務(wù)日志和數(shù)據(jù)庫時,建議您遵照下列最佳方法:通過諸如磁盤鏡象(RAID)這樣的方式愛護驅(qū)動器,防止可能的硬件故障造成的損失。在單獨的驅(qū)動器上保存事務(wù)日志和數(shù)據(jù)庫(存儲區(qū))。保持每個服務(wù)器上事務(wù)日志驅(qū)動程序的數(shù)量與存儲組的數(shù)量相等,以及將每個事務(wù)日志設(shè)置在不同的位置上,以使性能達到最佳。始終將文件系統(tǒng)格式化為符合NTFS的要求。關(guān)閉循環(huán)日志記錄功能。設(shè)置前臺服務(wù)器以處理接收的協(xié)議懇求,設(shè)置后臺服務(wù)器用作Web存儲區(qū)在這種配置形式中,前臺服務(wù)器可專用于處理接收的客戶連接和協(xié)議懇求。后臺服務(wù)器可專用于管理數(shù)據(jù)庫(存儲區(qū))。明顯,這種在多個服務(wù)器間安排負載的功能有助于提升Exchange的容量,從而滿足上百萬個用戶的需求。此外,將這些操作分開也有利于提高整個系統(tǒng)的牢靠性。重要的組件不再被固定到幾個服務(wù)器中的某一個上。為提高可用性運用群集和網(wǎng)絡(luò)負載平衡服務(wù)正如上文所述,群集是將服務(wù)器分組的一種方式—即使這些服務(wù)器是獨立的、分別的計算機—對網(wǎng)絡(luò)而言它們是一體的。它們相互協(xié)作,從而保證即使其中一臺發(fā)生故障,另一臺能夠隨時接管并接著供應(yīng)服務(wù)。在Exchange2000中,群集是活動/活動的,即Exchange服務(wù)可在群集中的全部服務(wù)器上同時運行。假如其中一臺出現(xiàn)故障,另一臺能夠接管故障服務(wù)器的職能,同時還能接著處理自己的任務(wù)。留意:

群集要求Windows2000AdvancedServer或Windows2000DatacenterServer。Windows2000的網(wǎng)絡(luò)負載平衡服務(wù)與其它類型的基于硬件的解決方案相比,基本上是一種基于軟件的負載平衡解決方案。網(wǎng)絡(luò)負載平衡服務(wù)的功能是抓取進入的TCP/IP流量,然后將它平均安排到一個負載平衡群集中的各個服務(wù)器上。為群集指定一個IP地址(假如主機是歸屬于多個系統(tǒng)的,即連接到多個網(wǎng)絡(luò)上,則指定一組地址)。假如主機發(fā)生故障或脫機,負載平衡服務(wù)能將網(wǎng)絡(luò)流量重新引導(dǎo)到正常工作的主機上,因為連接中斷后客戶機會重試,最終用戶最多只會感到一兩秒的延遲,就可接到正常工作的服務(wù)器的響應(yīng)。設(shè)計事務(wù)和工作流過程時要留意可用性為適應(yīng)應(yīng)用程序可用性的需求—使應(yīng)用程序在發(fā)生非致命錯誤的狀況下仍保持運行—您應(yīng)當留意錯誤的處理,特殊是事務(wù)接收器、COM+組件和工作流方面的錯誤。這是為了能夠從大多

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論