專利名稱：分布式操作系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分布式操作系統(tǒng)。操作系統(tǒng)是運行計算機的主控程序。它們是計算機系統(tǒng)的主要組成部分，因為它們?yōu)樵谄渲羞\行的應(yīng)用程序設(shè)定標準。所有程序都必須與操作系統(tǒng)“對話”。
大多數(shù)現(xiàn)代計算機系統(tǒng)的基礎(chǔ)體系結(jié)構(gòu)的中心特征之一在于各操作系統(tǒng)為該系統(tǒng)所管理的數(shù)據(jù)與應(yīng)用定義單一的名字空間。例如，操作系統(tǒng)所定義的名字空間包含用于定位文件的文件系統(tǒng)或目錄結(jié)構(gòu)。用于打開的文件的標識符、公共軟件部件及其它網(wǎng)絡(luò)資源。
在這些系統(tǒng)中，文件是信息的基本存儲單位。特定的文件或者包含數(shù)據(jù)單元或者包含功能(應(yīng)用或軟件部件)。對于數(shù)據(jù)文件，操作系統(tǒng)將適當?shù)膽?yīng)用與各文件關(guān)聯(lián)以便能觀看或更新文件的內(nèi)容。
應(yīng)用是通過集成面向?qū)ο蟮能浖考募辖⒌?。可將這些面向?qū)ο蟮能浖考ㄖ平⒊捎糜谔囟☉?yīng)用，或設(shè)計成供在許多不同的應(yīng)用中用作公共部件。
開發(fā)了復(fù)合文件(Compound file)，從而應(yīng)用內(nèi)的各種面向?qū)ο蟮牟考塥毩⒌刈x與寫單一文件內(nèi)的數(shù)據(jù)。雖然復(fù)合文件是用于存儲構(gòu)成信息單元(文檔)的各種對象(數(shù)據(jù)單元)的有效方式，但在網(wǎng)絡(luò)上分布一個大的復(fù)合文件是困難與費時的。為此，通過將它們分成較小文件的集合來建立因特網(wǎng)(或內(nèi)部網(wǎng))文檔的工業(yè)標準(諸如HTML與Java)正日益普及。
在已知的操作系統(tǒng)內(nèi)沒有用于識別邏輯上相關(guān)的文件的集合的一致方法。這意味著操作系統(tǒng)不能識別或管理跨多個文件的信息集合，諸如一組因特網(wǎng)(或內(nèi)部網(wǎng))文檔，公共軟件部件(包含關(guān)聯(lián)的可執(zhí)行模塊、模板、樣本及相關(guān)文檔)或大型數(shù)據(jù)庫。
利用稱作路徑的物理地址在目錄結(jié)構(gòu)中定位文件。路徑用于兩個相互矛盾的目的定位信息及組織信息。為了在目錄結(jié)構(gòu)內(nèi)重新組織信息必須移動文件，而移動文件改變應(yīng)用程序用來定位信息的路徑。
因為每一操作系統(tǒng)定義單一名字空間，不可能預(yù)測在任何給定時間點上特定的名字將在操作系統(tǒng)內(nèi)使用。這說明與特定系統(tǒng)資源關(guān)聯(lián)的名字將隨時間與位置變化。例如，為大多數(shù)應(yīng)用定義的安裝進程允許最終用戶選擇包含任何相關(guān)文件的目錄。
因為與文件關(guān)聯(lián)的名字沒有特殊含義，操作系統(tǒng)不能理解信息是如何在網(wǎng)絡(luò)上分布的。這意味著必須開發(fā)復(fù)雜的應(yīng)用來管理數(shù)據(jù)、軟件部件與應(yīng)用在網(wǎng)絡(luò)上的分布。
局域網(wǎng)(LAN)將一群計算機上的各個文件系統(tǒng)擴展成包含在多個LAN服務(wù)器的一個上共享的文件系統(tǒng)。從連接在該LAN上的任何計算機都可觀看與更新該LAN服務(wù)器上的文件。隨著LAN將操作系統(tǒng)所定義的名字空間擴展成包含LAN服務(wù)器上的選擇的資源，LAN代表從獨立計算機系統(tǒng)的邏輯發(fā)展步驟。
LAN的基本問題在于連接在LAN上的各計算機定義不同的名字空間。為了將一臺計算機上的資源映射到為另一計算機定義的名字空間中，必須構(gòu)造新的名字。如果各工作站為一組公共的網(wǎng)絡(luò)資源定義了不同的名字，LAN可能非常難于維護，這一問題的解決方案是為LAN工作站的配置定義廣泛的共同標準。維護這些標準包含大量的共同開銷且經(jīng)常困擾最終用戶。LAN的更嚴重限制在于共同標準只能在相對地小的工作組內(nèi)有效地實施。
作為全球通信工具的環(huán)球網(wǎng)(World Wide Web)WWW，其成功歸功于采用基于稱作“服務(wù)器域名”的單一全球唯一的標識符的尋址機制。各服務(wù)器域名為一組因特網(wǎng)(或內(nèi)部網(wǎng))資源定義一個不同的名字空間。服務(wù)器域名提供對由連接在因特網(wǎng)(或內(nèi)部網(wǎng))上的獨立計算機(或LAN)所定義的名字空間的映射。用在因特網(wǎng)(或內(nèi)部網(wǎng))上的尋址機制稱作全球資源定位器(URL)并通過連接服務(wù)器域名與路徑構(gòu)成。
因特網(wǎng)(或內(nèi)部網(wǎng))代表從LAN的邏輯進化步驟，因為它能被定義使用用于命名網(wǎng)絡(luò)資源的一致的全局標準的LAN。如果各信息單元單獨存在于由單一服務(wù)器域名所定義的名字空間中且與各服務(wù)器域名關(guān)聯(lián)的信息是不重新組織的，則URL是信息交換的有效工具。每一個因特網(wǎng)用戶都知道雖然它只用了幾年便已堆滿了過時的鏈接。此外，URL并不提供用于識別在多個服務(wù)器域上復(fù)制的信息的任何機制。與LAN一樣，必須實現(xiàn)復(fù)雜(及專門化)應(yīng)用來管理因特網(wǎng)(或內(nèi)部網(wǎng))上的信息分布。
面向?qū)ο蟮能浖_發(fā)方法的目的之一為定義能夠加以集成來構(gòu)成復(fù)雜的應(yīng)用的一組標準軟件部件。這一概念是為了帶給許多年來軟件產(chǎn)業(yè)已經(jīng)是計算機硬件工業(yè)的基礎(chǔ)的相同種類的模塊化工程規(guī)范。軟件產(chǎn)業(yè)實現(xiàn)這一目標的基本障礙之一是現(xiàn)代操作系統(tǒng)并不采用一致的命名約定這一事實。結(jié)果，有可能不存在在目錄結(jié)構(gòu)內(nèi)找到特定軟件部件的可靠方法。
微軟在Windows 95與Windows NT下對這一問題的解決方案是建立系統(tǒng)登記。在安裝軟件部件時，必須在系統(tǒng)登記中建立各種項以便能定位與激活該部件。當從系統(tǒng)上去掉該部件時也必須去掉系統(tǒng)登記中這些項。對象管理組(Object Management Group-OMG)所定義的公共對象請求代理體系結(jié)構(gòu)(Common Object Request BrokenArchitecture(CORBA))采用類似的方法。當用于建立復(fù)雜的分布式系統(tǒng)時，這一方法具有若干限制。
由于系統(tǒng)登記并不了解它們維護的各種登記項，它必須依靠安裝在該操作系統(tǒng)內(nèi)的各種軟件部件與應(yīng)用的及時更新。雖然這一方法對于保持相對靜態(tài)的配置的操作系統(tǒng)是有效的，對于必須適應(yīng)大型及不斷變化中的網(wǎng)絡(luò)環(huán)境的操作系統(tǒng)，它是不實際的。
Windows 95系統(tǒng)登記采用稱作“CLSID”的單一全局性唯一的標識符來定位公共軟件部件。用在Windows 95系統(tǒng)登記中的CLSID具有下述限制只為軟件部件定義CLSID。由于數(shù)據(jù)文件不能在系統(tǒng)登記中建立或維護項，沒有方法利用系統(tǒng)登記來定位數(shù)據(jù)文件。
系統(tǒng)登記通過將軟件部件的CLSID與操作系統(tǒng)的名字空間內(nèi)的資源名(諸如路徑)關(guān)聯(lián)而作為尋址機構(gòu)工作。對于建立分布式系統(tǒng)，系統(tǒng)登記只有有限的用途，因為它所定義的尋址機制只在各個操作系統(tǒng)的范圍內(nèi)有用。即使能讀取為另一操作系統(tǒng)定義的系統(tǒng)登記中的項目，結(jié)果也是沒有意義的。
CLSID標識軟件部件內(nèi)的頂層對象，以便能實例化該對象的實例。雖然CLSID提供用于定位與實例化部件的方法，它并不標識構(gòu)成該部件的所有資源(大多數(shù)文件)。為此，對于管理跨越網(wǎng)絡(luò)的信息分布，CLSID只有有限用途。
微軟的OLE與Active X協(xié)議是微軟為軟件部件的集成定義的方法。兩種協(xié)議都基于微軟的部件對象模型(稱作“COM”)，OLE協(xié)議已為在單個操作系統(tǒng)內(nèi)操作的函數(shù)及應(yīng)用的開發(fā)而優(yōu)化，而ActiveX已為因特網(wǎng)(或內(nèi)部網(wǎng))址的開發(fā)而優(yōu)化。
OLE與Active X協(xié)議支持兩種基本服務(wù)允許一個應(yīng)用激活軟件部件的一組功能及允許應(yīng)用建立、讀取及更新復(fù)合文件的一組功能。這兩種協(xié)議利用系統(tǒng)登記來定位各個軟件部件，因此受到上述系統(tǒng)登記的限制的制約，并且這些協(xié)議也是非常復(fù)雜的。
OLE與Active X協(xié)議將網(wǎng)絡(luò)的視圖視為大型操作系統(tǒng)的體系結(jié)構(gòu)等效物。微軟的本地/遠程透明度概念主要是用于將一組分布式資源映射到操作系統(tǒng)的名字空間中的方法。COM假設(shè)系統(tǒng)的每一個部件存在于且只存在于網(wǎng)絡(luò)的一個位置上，及應(yīng)用是通過將這些分布的部件連接在一起建立的。
包含Oracle、IBM、Informix及Sybase所提供的在內(nèi)的數(shù)據(jù)庫技術(shù)包含一組文件及公用軟件部分。公用軟件部分實現(xiàn)允許其它應(yīng)用存取已存儲在文件中的信息的特定數(shù)據(jù)庫存取方法。描述數(shù)據(jù)庫的一種方法是作為用于信息集合的封裝的名字空間。關(guān)系數(shù)據(jù)庫的成功很大程度上歸因于關(guān)系存取方法允許存儲在數(shù)據(jù)庫中的每一數(shù)據(jù)可用作其它數(shù)據(jù)的名稱這一事實。
然而，現(xiàn)代數(shù)據(jù)庫技術(shù)具有若干限制，例如在數(shù)據(jù)庫能被使用之前，必須定義數(shù)據(jù)庫結(jié)構(gòu)(數(shù)據(jù)類型及索引)。由于定義數(shù)據(jù)庫結(jié)構(gòu)需要大量時間與專業(yè)技術(shù)知識，它只對于大容量與重復(fù)的企業(yè)活動是物有所值的。同時，由于各數(shù)據(jù)庫定義定制的名字空間，想要使用該數(shù)據(jù)庫者必須首先了解它的結(jié)構(gòu)。
獨立定義的數(shù)據(jù)庫將實現(xiàn)不同的及有可能不兼容的名字空間。為了解決這一問題，鼓勵公司開發(fā)用于信息管理的附加共同標準。
Lotus Notes(最近更名為“Lotus Domino”)網(wǎng)包含Lotus Notes服務(wù)器及若干客戶機。服務(wù)器與客戶機都必須運行專有軟件并可將數(shù)據(jù)庫存儲在客戶機或服務(wù)器機器上。Lotus Notes提供個人群體能互相共享信息的環(huán)境。為了觀看或編輯這一環(huán)境中的文檔，用戶只須指點與點擊。對不是在Notes環(huán)境中建立的文檔的存取只限于支持對象鏈接及嵌入的應(yīng)用。然而，Notes的確提供對某些更公用的數(shù)據(jù)庫的前端，但這一設(shè)施只限于一定的平臺。
Lotus Notes環(huán)境是對團體信息的封閉的、分類的及索引引用的環(huán)境。它允許個人采用對單個文檔及共同編輯設(shè)施的多用戶存取的設(shè)備作為小組的一部分工作。各數(shù)據(jù)庫圖符表示用某一關(guān)鍵字項排序的邏輯上相關(guān)的文檔的集合，這些文檔是愿意與組織內(nèi)的其它用戶共享信息的個人加入的。
對于一個組織內(nèi)的個人與小組，Lotus Notes提供信息的可見性及說明、編輯與更新文檔的機會。它還提供用于邏輯上對文檔分組的設(shè)施。然而，它的確趨向于將用戶限制在組織的網(wǎng)絡(luò)上。
Lotus Notes及大多數(shù)其它工作組系統(tǒng)主要是設(shè)計成支持特定的工作組應(yīng)用套件的數(shù)據(jù)庫技術(shù)。雖然這些工作組應(yīng)用支持大量的特征范圍，它們不能克服它們的基礎(chǔ)數(shù)據(jù)庫技術(shù)的限制大多數(shù)工作組系統(tǒng)的實現(xiàn)與維護是昂貴的。由于相關(guān)的費用，大多數(shù)工作組系統(tǒng)只在支持大容量及重復(fù)的商業(yè)活動中使用才物有所值。
包含Intel公司的LANDesk在內(nèi)的若干現(xiàn)有產(chǎn)品將在LAN(及在某些情況中在WAN)分發(fā)軟件的過程自動化。為了這些系統(tǒng)高效地工作，還要為LAN工作站的配置定義更多的共同標準。然后配置網(wǎng)絡(luò)管理工具來管理包含在共同標準內(nèi)的應(yīng)用的分布。
網(wǎng)絡(luò)管理工具主要自動化本來是勞動密集的訪問各工作站來安裝軟件更新的過程。雖然這些工具減少了與軟件分發(fā)相關(guān)的總費用，它們并不克服傳統(tǒng)軟件分發(fā)過程的其它限制。例如，必須由中心IT支持組安裝與管理網(wǎng)絡(luò)管理工具，而中心支持組必須為連接在LAN上的各工作站維護硬件與軟件清單。由于與中心支持組相關(guān)的費用，網(wǎng)絡(luò)管理工具應(yīng)用只有對在整個公司廣泛地使用的應(yīng)用上成本高效。
網(wǎng)絡(luò)管理工具并不具有關(guān)于它們正在分布的應(yīng)用的任何獨有的知識。這些工具簡單地復(fù)制構(gòu)成該應(yīng)用的所更新的文件，然后對任何有關(guān)配置文件作出有選擇的更新。網(wǎng)絡(luò)管理工具不能支持需要高度定制的分布進程的應(yīng)用。
網(wǎng)絡(luò)管理工具只設(shè)計成分放裝在大量工作站上且在時間上靜態(tài)的信息。網(wǎng)絡(luò)管理工具不能用來分放文檔，因為文檔是在網(wǎng)絡(luò)上不可預(yù)測的地方與時間上建立與更新的。
概言之，已關(guān)于各種應(yīng)用如何定義名字及它們?nèi)绾畏植紨?shù)據(jù)描述了各種應(yīng)用。大多數(shù)現(xiàn)代應(yīng)用通過定義符合特定商業(yè)要求的客戶機名建立自動化孤島。為了集成與協(xié)調(diào)不同應(yīng)用及不同操作系統(tǒng)所定義的各種名字，在現(xiàn)代操作系統(tǒng)上增加了許多層復(fù)雜性。
當前設(shè)想的本發(fā)明提供了用于網(wǎng)絡(luò)的分布式操作系統(tǒng)，包括各存在于某一物理位置上且與不同的專題的實例集合關(guān)聯(lián)的庫集合。各專題是系統(tǒng)資源的封裝集合并具有包含應(yīng)用、數(shù)據(jù)庫、軟件部件、或任何其它邏輯上相關(guān)的文件集合的文件系統(tǒng)。任何給定時間上在任何給定的庫中只能存在專題的一個實例。同一專題的實例可存在在不同庫中。將需要第一與第二全局唯一的標識符的尋址標準應(yīng)用在庫與專題上。第一全局唯一標識符用于標識各庫。第二全局唯一標識符用于標識各專題。不論它在哪一個庫中，專題的每一個實例具有同一專題標識符。通信協(xié)議存在在庫外部來啟動應(yīng)用、軟件部件及作為專題存儲在不同庫中的文檔之間的交互作用。
主要優(yōu)點在于能將獨立生成的諸如文檔與公共軟件部件等信息組合以構(gòu)成集成系統(tǒng)而無需復(fù)雜的地址翻譯。
本發(fā)明還允許隨著信息從一個系統(tǒng)復(fù)制到另一個系統(tǒng)時保持信息的標識。識別信息是如何跨網(wǎng)絡(luò)分布的能力將極大地減少諸如軟件分布與清單控制等網(wǎng)絡(luò)維護活動的復(fù)雜性。本發(fā)明還允許開發(fā)隨著它們的分布而以有用的方式改變的新的應(yīng)用類。
專題可以是文檔。文檔的各實例可包含該文檔的最新版本并有可能包含該文檔的一或多個較老版本。對文檔的各種實例的更新是根據(jù)需要分布的。
專題可以是應(yīng)用(或軟件部件)。應(yīng)用的各實例包含該應(yīng)用的完整復(fù)制品。對各應(yīng)用的實例的更新是根據(jù)需要分布的。
專題可以是論壇(forum)。論壇的一個實例包含該論壇的完整復(fù)制品。其它實例允許最終用戶跨網(wǎng)絡(luò)對論壇評論及增加注釋。
專題可以是數(shù)據(jù)庫。與論壇一樣，專題的一個實例包含數(shù)據(jù)庫的完整復(fù)制品而其它實例允許最終用戶跨網(wǎng)絡(luò)訪問數(shù)據(jù)庫。
專題可以是圖象檔案。專題的各種實例管理一個項目的文檔圖象的收集與分布。根據(jù)需要將增量更新分布到圖象檔案的各實例上。
各應(yīng)用是封裝在專題內(nèi)的。為了使用公共軟件部件，應(yīng)用可利用一組庫服務(wù)來引用在包含該軟件部件的專題內(nèi)的適當資源。如果庫確定引用的專題位于另一庫內(nèi)，則可利用類似的網(wǎng)絡(luò)服務(wù)組將該請求轉(zhuǎn)發(fā)給遠程庫。利用這一過程，應(yīng)用與軟件部件都不需要作出任何特殊規(guī)定來支持遠程專題引用。
由于對于分布式應(yīng)用，專題ID是全局唯一的標識符，應(yīng)用可使庫(或網(wǎng)絡(luò))搜索特定專題ID的實例。如果數(shù)據(jù)庫的實例可在本地庫中獲得，則該本地實例可用來滿足該引用。如果數(shù)據(jù)庫的本地實例不能直接滿足該請求，則該本地實例可作為數(shù)據(jù)庫的遠程實例的代理工作。如果找不到專題的本地實例，則庫可搜索通過全體庫的有序表以找到數(shù)據(jù)庫的適當遠程實例。
可用根專題及后代專題將專題組織成分層結(jié)構(gòu)。庫可將專題組織成任何結(jié)構(gòu)(分層、矩陣等)，因為尋址標準并不依賴于庫結(jié)構(gòu)來定位專題。為了給各種最終用戶提供庫的定制的“視圖”，庫甚至能同時支持多種組織結(jié)構(gòu)。
庫的特定最終用戶的視圖可排除該最終用戶沒有足夠的訪問授權(quán)級別的任何專題?？蔀閷ぶ穼ｎ}及為觀看組織結(jié)構(gòu)定義分開的訪問級別。雖然包含軟件部件的專題有可能不出現(xiàn)在庫的最終用戶視圖中，仍有可能允許該最終用戶使用引用該軟件部件的應(yīng)用。
存在兩種管理版本的基本方法。可通過復(fù)制專題建立版本，或可在專題內(nèi)實現(xiàn)版本控制。當通過復(fù)制專題建立新版本時，可在專題的各種版本之間定義從屬關(guān)系以簡化相關(guān)的協(xié)調(diào)工作。
作為替代，專題可包含帶版本控制的文檔。文檔的特定版本可包含在單個復(fù)合文件或單個子目錄中。隨著該文檔的新版本的建立，可將它們存儲在同一專題內(nèi)的附加復(fù)合文件或子目錄中。也可利用專題來統(tǒng)一與存儲對文檔的各種版本提供的任何注釋。這一專題的分布可建立包含該文檔的最新版本、該文檔的較老版本及任何相關(guān)注釋的新實例(或更新現(xiàn)有的實例)。
可以不同地處理軟件部件的版本控制。可作為生成新專題來包含新軟件部件與應(yīng)用的庫來建立軟件開發(fā)環(huán)境。然后可在各單獨專題內(nèi)支持各軟件部件(或應(yīng)用)的多種版本。這一專題的分布可建立新的實例(或升級現(xiàn)有的實例)來包含該軟件部件(或應(yīng)用)的最新版本。利用這一方法，可將特定軟件部件的所有源代碼、可執(zhí)行模塊、文檔及安裝過程封裝在單個專題中。這一方法簡化了測試環(huán)境的開發(fā)并改進了部件可靠性，因為從其第一次實現(xiàn)直到其分放，與各軟件部件關(guān)聯(lián)的專題ID與名字可以是不變的。
庫可將專題標識為“可信任的專題”或“可疑的專題”。如果專題是從可信任的庫上的可信任的專題分布的則可將其標識為可信任的專題(或否則由授權(quán)的最終用戶將之標識為可信任的專題)。各庫可維護它從中接收的可信任的應(yīng)用與軟件部件的分放的可信任的庫的短列表。庫所定義的可信任的庫的集合便是該庫的可信任的域。不是從可信任的庫上的可信任的專題分放的任何專題被標識為可疑專題。允許可疑專題修改包含在其本身的名字空間內(nèi)及在作為命名從屬列出該可疑專題的任何專題的名字空間內(nèi)的資源。然而，不允許可疑的專題更新包含在任何其它專題中的資源。這些限制有效地減少了惡意的專題對庫或?qū)W(wǎng)絡(luò)作出的破壞。
除了封裝在專題內(nèi)的資源，各專題可實現(xiàn)稱作“方法”(Method)的一組函數(shù)來控制其本身的分布。沒有必要為每一個專題定義所有的專題方法。專題所利用的所有方法與庫服務(wù)都是在該特定專題的上下文內(nèi)執(zhí)行的。專題可從它們的相關(guān)庫中繼承庫函數(shù)(及操作系統(tǒng)函數(shù))。
為了復(fù)制專題，調(diào)用為該專題定義的復(fù)制專題方法(Copy Topicmethod)。復(fù)制專題方法建立新專題及初始化該新專題的內(nèi)容。最后，調(diào)用為該新專題定義的方法來完成初始化過程。
為了在活躍的視圖內(nèi)移動專題，調(diào)用為該專題實現(xiàn)的移動專題方法(Move Topic Method)。移動專題方法消除作為其當前祖先的直接后代的專題并作為第二專題的直接后代安裝該專題。然后為移動的所有專題調(diào)用一種方法。注意當移動一個專題時其所有后代也都移動。
為了刪除專題，調(diào)用為該專題的祖先實現(xiàn)的刪除專題方法(Delete Topic Method)。專題并不刪除它們自己因為許多操作系統(tǒng)不允許一個函數(shù)功能刪除該函數(shù)從其加載的文件。
打開專題方法(Open Topic method)用于激活與一個專題關(guān)聯(lián)的應(yīng)用或軟件部件。
公布專題方法(Public Topic method)用于分布專題到另一個庫。公布專題方法假定該專題的原始實例應(yīng)保留在源庫中并應(yīng)將其復(fù)制品分布到目標庫上。公布專題方法假定已為各命名從屬執(zhí)行過該公布專題方法。公布專題方法將檢驗?zāi)繕藥炜纯词欠褚汛嬖谠搶ｎ}的實例。如果在目標庫上已存在該專題的實例，則調(diào)用為現(xiàn)有的實例實現(xiàn)的公布專題前(Before Publish Topic)方法，并更新現(xiàn)有的專題的內(nèi)容。如果在目標庫上找不到該專題的實例，則在目標庫上增加該專題的實例。
恢復(fù)專題方法(Restore Topic method)等同于公布專題方法，除了它將專題恢復(fù)到前一版本而不是將該專題更新到更新的版本之外?；謴?fù)專題方法是設(shè)計成與公布專題方法一起工作的，以便可以通過“公布”專題給另一庫然后在必要時“恢復(fù)”它們來后備與恢復(fù)專題。例如，如果破壞或刪除了專題的原始實例，可利用恢復(fù)專題方法從公布的實例再生該專題的原始實例。當專題的公布的實例沒有包含足夠的信息來再生原始實例時，將不支持恢復(fù)專題方法。
更新專題方法(Update Topic method)用于控制專題更新的自動分布。當執(zhí)行更新專題方法時，該專題檢驗判定一個更新是否可用于分發(fā)。如果可使用一個更新，便返回包含該更新的專題的實例的位置，以便可執(zhí)行公布專題方法來完成更新過程。
發(fā)送專題方法(Route Topic method)用于分發(fā)專題到另一庫上。發(fā)送專題方法假定應(yīng)將該專題的原始實例移動到目標庫上，并應(yīng)將該專題的復(fù)制品留在源庫上。為了發(fā)送專題，調(diào)用為該專題實現(xiàn)的發(fā)送專題方法。發(fā)送專題方法假定已為各命名從屬執(zhí)行了公布專題方法。發(fā)送專題方法將檢驗?zāi)繕藥靵砼卸ㄊ欠褚汛嬖谠搶ｎ}的實例。如果在目標庫上已存在該專題的實例，則調(diào)用為現(xiàn)有的實例實現(xiàn)的發(fā)送專題以前(Before Route Topic)方法，及更新現(xiàn)有的專題的內(nèi)容。如果在目標庫上找不到該專題的實例，則在目標庫上增加該專題的實例。
將專題的各實例的全局地址定義為庫ID與專題ID的組合。除了這些全局地址之外，可用兩種其它基本格式定義地址相對地址及命名從屬。復(fù)合地址是通過將全局地址、相對地址與命名從屬(NamedDependent)鏈接在一起構(gòu)成的。
專題內(nèi)的各資源具有只在該專題所定義的上下文(或名字空間)中才有效的名字。其它專題中的資源是利用該專題的全局地址(或復(fù)合地址)作為前綴引用的。
專題可用相對地址來識別活躍視圖中其它專題。注意無法為直接后代定義相對地址，因為通常為各專題定義有一個以上直接后代。
一個專題說成是從屬于第二專題，如果該第二專題被第一專題定義為命名從屬的話，其中一個命名從屬為一個名字與一個復(fù)合地址之間的聯(lián)系。標識為命名從屬的復(fù)合地址描述該活躍的專題所從屬的一組專題。與命名從屬關(guān)聯(lián)的名字可用作地址。
一個標簽(Tag)是一個名字與一個短正文短語之間的聯(lián)系?？蔀樗袑ｎ}定義下列標準標簽名字-專題的名字。
<復(fù)合地址>-專題的名字。
作者-制作專題的個人的名字。
地址-作者的郵寄地址。
E-mail地址-作者的電子郵件地址。
公司-開發(fā)專題的公司。
命名文件(Named File)是名字與路徑之間的聯(lián)系。當在傳統(tǒng)系統(tǒng)上面實現(xiàn)本發(fā)明時，可能需要在專題內(nèi)包含一或多個文件而無須實際移動文件。這一方面，命名文件標識封裝在專題內(nèi)但尚未嵌入到該專題的文件系統(tǒng)內(nèi)的文件。在公布或發(fā)送專題時，將任何命名文件的復(fù)制品嵌入該專題的遠程實例中。命名文件也用來為封裝的文件生成HTML鏈接。例如，可為已標識為命名文件的文本文件生成一個HTML鏈接以便可通過因特網(wǎng)或內(nèi)部網(wǎng)觀看或編輯該文件的內(nèi)容。
本發(fā)明的實施例在支持通常是相對短持續(xù)時間的一次性完成(one-off effort)的高價值與關(guān)鍵性項目的自動化中特別有用。這些實施例可包含內(nèi)部網(wǎng)公布工具來支持公司自動獲得外部銷售情況(Outsourcing Sales Effort)及積極性研究(Due DiligenceStudies)。
下面參照附圖描述本發(fā)明的實例，附圖中
圖1為實施本發(fā)明的網(wǎng)絡(luò)的組織圖；圖2為展示庫與專題之間的聯(lián)系的組織圖；圖3為展示分布式專題的組織圖；以及圖4為展示庫的分層視圖的組織圖；首先參見圖1，網(wǎng)絡(luò)1包含若干操作系統(tǒng)或庫2，后者又包含若干封裝的系統(tǒng)資源集合或?qū)ｎ}3。各單獨專題3包含文件系統(tǒng)4，而文件系統(tǒng)4可包含應(yīng)用、數(shù)據(jù)庫、軟件部件或任何其它邏輯上相關(guān)的文件集合5。網(wǎng)絡(luò)1支持一組通信協(xié)議使不同庫2中的專題3能交互作用。庫2所定義的名字空間限制在專題3上。
在任何給定時間點上，各庫2存在于網(wǎng)絡(luò)1上的特定物理位置上并分配有唯一的全局標識符，“庫ID”。這一標識符可能是為因特網(wǎng)(或內(nèi)部網(wǎng))定義的服務(wù)器域名，或者它可能是具有極高概率的唯一的隨機數(shù)(諸如開放軟件基礎(chǔ)的UUIP或微軟的GUID)。
也分配給網(wǎng)絡(luò)上的各不同專題一個全局唯一的標識符，即“專題ID”。出現(xiàn)在一個以上庫中的專題說成是具有多個“實例”。專題的各實例將總是分配相同的專題ID。專題ID可作為UUID或GUID定義，或從在其中建立該專題的第一個實例的庫的庫ID建立。尋址標準是通過連接庫ID與專題ID定義的。
另一種定義尋址標準的方法為將網(wǎng)絡(luò)1描述為兩個不同的集合庫2的集合及專題3的集合，如圖2中所示。網(wǎng)絡(luò)是通過關(guān)聯(lián)專題3的集合與各庫2構(gòu)成的。然后通過將關(guān)聯(lián)的專題2的實例增加到庫中而構(gòu)成各庫2。注意這一方法清楚地示出同一專題的兩個實例不能出現(xiàn)在單一庫中。這是可接受的限制，因為在單一庫中具有一個應(yīng)用、軟件部件或文檔的兩個復(fù)制品實際上沒有意義。同時，可根據(jù)需要通過復(fù)制現(xiàn)有的專題的實例建立新專題。
能容易地定位專題的實例(因為它們?nèi)挤峙溆邢嗤膶ｎ}ID)，并可將它們集成以構(gòu)成分布式應(yīng)用6，如圖3中所示。
應(yīng)指出專題的實例不一定是專題的相同的復(fù)制品。專題的各實例的內(nèi)容與表現(xiàn)對不同的專題有所不同。例如，內(nèi)部網(wǎng)公布工具可包含以下專題·文檔-文檔的各實例包含該文檔的最新版本并有可能包含該文檔的一個或多個較老的版本。對文檔的各種實例的更新是根據(jù)需要分布的。
·應(yīng)用(或軟件部件)-應(yīng)用的各實例包含該應(yīng)用的完整復(fù)制品。對各應(yīng)用的實例的更新是根據(jù)需要分布的。
·論壇-論壇的一個實例包含該論壇的完整復(fù)制品。其它實例允許最終用戶跨網(wǎng)絡(luò)觀察及增加注釋到論壇上。
·數(shù)據(jù)庫-與論壇一樣，專題的一個實例包含數(shù)據(jù)庫的完整復(fù)制品，而其它實例允許最終用戶跨網(wǎng)絡(luò)訪問數(shù)據(jù)庫。
·圖象檔案-專題的各種實例為項目管理文檔圖象的采集與分布。增量更新是根據(jù)需要分布到圖象檔案的各實例上的。
能為各專題定義從屬關(guān)系。例如，利用特定字處理應(yīng)用建立的文檔通常從屬于該字處理應(yīng)用。通過利用從屬關(guān)系，能將安裝在庫中的軟件保持最新的，并根據(jù)需要重新配置成支持最終用戶的活動。
遞增實現(xiàn)庫與專題可作為現(xiàn)有的或“傳統(tǒng)”操作系統(tǒng)與應(yīng)用之上的層建立。起初將應(yīng)用實現(xiàn)為盡可能利用本發(fā)明的特征，以后再利用本發(fā)明實現(xiàn)附加的功能，而減少對傳統(tǒng)系統(tǒng)的依賴性。
作為傳統(tǒng)系統(tǒng)之上的層實現(xiàn)本發(fā)明的實施例的能力是通過將專題定義為系統(tǒng)資源的封裝的集合而成為可能的。事實上本發(fā)明可通過將傳統(tǒng)系統(tǒng)管理的資源分割成專題組來實現(xiàn)。
利用本發(fā)明實現(xiàn)的應(yīng)用將通過利用尋址標準來引用資源。當利用本發(fā)明實現(xiàn)的應(yīng)用需要激活根據(jù)傳統(tǒng)技術(shù)的應(yīng)用或服務(wù)時，必須將地址翻譯回適當傳統(tǒng)系統(tǒng)的名字空間中。例如，存儲在專題內(nèi)的因特網(wǎng)(或內(nèi)部網(wǎng))文檔也作為基礎(chǔ)操作系統(tǒng)的目錄結(jié)構(gòu)內(nèi)的文件存在。
假定可將新地址翻譯回基礎(chǔ)傳統(tǒng)系統(tǒng)的名字空間中這一事實，本發(fā)明看似并未增加任何有價值的東西。這一方面，重要的是記住可將專題或庫隨時移動到不同的物理位置并且可將專題分布到其它庫中。無論專題的特定實例存儲在何處，利用尋址標準建立的用于其封裝的資源的地址是不變的。這使得非常容易建立利用封裝在分布式專題內(nèi)的資源的應(yīng)用。雖然可將新地址翻譯回基礎(chǔ)傳統(tǒng)系統(tǒng)的名字空間中，這些翻譯的結(jié)果是隨時間改變的。
本地/遠程透明性如上所述，用作OLE與Active X協(xié)議的基礎(chǔ)的微軟的部件對象模型(COM)是基于本地/遠程透明性概念的。這一概念是一個應(yīng)用應(yīng)使用一致的方法來集成軟件部件，及不應(yīng)對運行在其它進程內(nèi)或遠程網(wǎng)絡(luò)服務(wù)器上的軟件部件作出任何特殊規(guī)定。微軟通過將遠程軟件部件與“處理器”或“代理”關(guān)聯(lián)來實現(xiàn)本地/遠程透明性概念。雖然從應(yīng)用的觀點這一方法工作得很好，但它使得軟件部件的開發(fā)與安裝相當復(fù)雜。與必須構(gòu)筑進軟件部件中的附加復(fù)雜性關(guān)聯(lián)的成本是合算的，因為軟件部件只開發(fā)一次然后使用許多次。
本發(fā)明采用不同的方法來實現(xiàn)本地/遠程透明性的目標。各應(yīng)用是封裝在專題中的。為了使用公共的軟件部件，應(yīng)用使用一組庫服務(wù)來引用包含該軟件部件的專題內(nèi)的適當資源。如果庫確定所引用的專題位于另一庫內(nèi)，則利用類似的網(wǎng)絡(luò)服務(wù)集合將請求轉(zhuǎn)交給遠程庫。利用這一過程，應(yīng)用與軟件部件都不需要作出任何特殊規(guī)定來支持遠程專題引用。
通過將一個軟件部件的一個實例設(shè)計為作為該軟件部件的另一遠程實例的代理工作，仍有可能在本實施例內(nèi)實現(xiàn)代理與處理器。
事實上，本地/遠程透明性的概念可采取更進一步的步驟。由于專題ID是分布式應(yīng)用的全局唯一標識符，應(yīng)用能令庫(或網(wǎng)絡(luò))搜索特定專題ID的實例。例如，一個應(yīng)用可通過只使用相關(guān)的專題ID引用包含客戶機信息的數(shù)據(jù)庫。如果數(shù)據(jù)庫的實例是可以在本地庫中獲得的，便利用它來滿足該引用。如果數(shù)據(jù)庫的本地實例不能直接滿足該請求，則該本地實例可作為數(shù)據(jù)庫的遠程實例的代理工作。如果找不到專題的本地實例，則該庫能搜索通過全體庫的有序表來找到該數(shù)據(jù)庫的適當遠程實例。
平臺無關(guān)性雖然尋址標準允許任何專題跨全局網(wǎng)引用包含在其它專題內(nèi)的資源，只有在被引用的資源屬于兼容的資源類時這種引用才是有用的?！百Y源類”定義為系統(tǒng)資源的相干與一致的集合，諸如特定的操作系統(tǒng)服務(wù)集合、特定的LAN接口或因特網(wǎng)(或內(nèi)部網(wǎng))文檔集合。本發(fā)明允許單一專題封裝屬于任意資源類的集合的各種資源。
與平臺無關(guān)的資源類的最佳例子之一便是因特網(wǎng)(或內(nèi)部網(wǎng))文檔集合。不論它的開發(fā)平臺是什么，具有適當WWW瀏覽器的任何人都能觀看任何因特網(wǎng)(或內(nèi)部網(wǎng))文檔。WWW的普及性已清楚地展示了與平臺無關(guān)的資源類的價值。
本實施例還為分布專題到實現(xiàn)在不兼容的平臺(在這一方面可將“平臺”描述為集成的資源類的集合)上的庫設(shè)計了許多規(guī)定。一種解決方法是為專題定義與平臺無關(guān)的標準。這一標準是通過將封裝在專題內(nèi)的資源限制在一組與平臺無關(guān)的資源類上定義的。例如，與平臺無關(guān)的標準可能要求專題的所有活躍部件都用Java(與Sun微系統(tǒng)的平臺無關(guān)的語言)開發(fā)。
支持分布專題到不兼容平臺上的另一方法為建立當將專題從一個平臺公布到另一個上時重新配置它們自己。從最終用戶的觀點，這種專題呈現(xiàn)為與平臺無關(guān)的。然而，通過為各種平臺主動地重新配置它們自己，這些專題可為與各平臺關(guān)聯(lián)的唯一資源類優(yōu)化它們的性能。例如，可通過公布大型機庫上的數(shù)據(jù)庫的實例到Windows95庫來建立Windows95網(wǎng)關(guān)。
本發(fā)明還允許將各個專題配置成虛擬機器。這時各庫能支持若干不同類型的虛擬機器有些是與平臺無關(guān)的，而有些是平臺特定的。定義為在與平臺無關(guān)的虛擬機器中運行的專題可跨越異質(zhì)平臺公布或發(fā)送。專題內(nèi)的資源將在所有物理平臺上的一致的虛擬環(huán)境中操作。(用于封裝相關(guān)資源的)專題周圍的邊界將內(nèi)部(虛擬)資源映射到外部(實際)資源上。邊界能將專題的內(nèi)部文件結(jié)構(gòu)映射到平臺的文件結(jié)構(gòu)中，或?qū)ｎ}的內(nèi)部方法映射到一組分布式方法中。例如，打開專題方法被設(shè)計成為可選擇的專題內(nèi)部方法集合提供一個一致的外部入口點。
庫組織如上所述，在大多數(shù)現(xiàn)代操作系統(tǒng)下面的目錄結(jié)構(gòu)是用來定位信息及組織信息的。雖然尋址標準是用于跨越全局網(wǎng)定位與分布信息的有效工具，它并不提供在庫內(nèi)組織專題的任何機制。
設(shè)想成將庫建立成服務(wù)于某種全體上下文內(nèi)的某種目的。與庫關(guān)聯(lián)的目的與全體上下文在任何特定時間點上為包含在庫內(nèi)的專題定義自然的組織結(jié)構(gòu)，但庫的目的與全體上下文兩者都可隨時間變化。這表示對如何在不同的庫上組織專題，或在不同的時間上如何在庫內(nèi)組織專題不應(yīng)有限制。
為此，本發(fā)明允許庫將專題組織到分層結(jié)構(gòu)中，如圖4中所示。分層結(jié)構(gòu)的根7為包含核心部件及用于庫本身的配置文件的專題(這一方面庫只是另一公共軟件部件)。其余的專題8、9、10與11是按照庫的目的與全體上下文組織成根專題(庫)的后代的，如圖6中所示。名詞“祖先”用來標識專題的雙親，而名詞“直接后代”用來描述專題的子女。
原則上，本發(fā)明允許庫將專題組織成任何結(jié)構(gòu)(分層的、矩陣等)，因為尋址標準并不依賴庫結(jié)構(gòu)來定位專題。為了向各種最終用戶提供庫的定制的“視圖”，庫甚至能同時支持多種組織結(jié)構(gòu)。例如，庫的最終用戶視圖可排除該最終用戶對其沒有足夠的訪問授權(quán)級的任何專題。由于尋址標準并不依賴于為庫定義的組織結(jié)構(gòu)，可為尋址專題及觀看組織結(jié)構(gòu)定義獨立的訪問級別。雖然包含軟件部件的專題有可能不出現(xiàn)在庫的最終用戶視圖中，仍有可能允許該最終用戶使用引用該軟件部件的應(yīng)用。
管理版本有兩種用于管理版本的基本方法?？赏ㄟ^復(fù)制專題建立版本，或可在專題內(nèi)實現(xiàn)版本控制。復(fù)制專題來建立新版本的觀念大致相當于復(fù)制文件來建立新版本。和文件一樣，當通過復(fù)制專題建立新版本時，必須付出可觀的工作來協(xié)調(diào)專題的各種版本(或者手動或者通過實現(xiàn)專用應(yīng)用)。如果采用這一方法，可在專題的各種版本之間定義從屬關(guān)系來簡化相關(guān)協(xié)調(diào)工作。
大多數(shù)情況中，較簡單的選擇是在專題內(nèi)實現(xiàn)版本控制。例如，專題可包含帶有版本控制的文檔。該文檔的特定版本包含在單個復(fù)合文件或單個子目錄內(nèi)。建立該文檔的新版本時將它們存儲在同一專題的附加復(fù)合文件或子目錄內(nèi)。專題還用于合并及存儲對該文檔的各種版本提供的任何注釋。這一專題的分布建立包含該文檔的最新版本、該文檔的較老版本及任何有關(guān)注釋的新實例(或更新現(xiàn)有的實例)。
軟件部件的版本控制是不同地處理的。作為生成新專題來包含新的軟件部件與應(yīng)用的庫建立軟件開發(fā)環(huán)境。然后在各單獨專題內(nèi)支持各軟件部件(或應(yīng)用)的多種版本。這一專題的分布建立包含該軟件部件(或應(yīng)用)的最新版本的新實例(或升級現(xiàn)有的實例)。利用這一方法將特定軟件部件的所有源代碼、可執(zhí)行模塊、文檔及安裝過程封裝在單一專題內(nèi)。這一方法簡化了測試環(huán)境的開發(fā)并改進了部件可靠性，因為與各軟件部件關(guān)聯(lián)的專題ID與名字從第一次實現(xiàn)直到其分布是不變的。
網(wǎng)絡(luò)安全性由于大多數(shù)現(xiàn)代操作系統(tǒng)為應(yīng)用定義單一的名字空間，操作系統(tǒng)實際上不可能知道合法應(yīng)用程序與病毒(或其它惡意程序)之間的差別。擴展操作系統(tǒng)的名字空間以包含各種網(wǎng)絡(luò)資源的LAN與其它網(wǎng)絡(luò)的構(gòu)造為惡意程序的傳播提供了額外的機會。這一問題的傳統(tǒng)解決方法是構(gòu)筑堅固的防火墻來仔細地監(jiān)視與控制網(wǎng)絡(luò)的不同部分之間的信息流。防火墻的問題是它們只在限制跨越網(wǎng)絡(luò)邊界的信息流的范圍內(nèi)有效。防火墻強加的限制將不可避免地挫傷終端用戶，使得終端用戶將經(jīng)常避開防火墻而引入惡意程序到任意網(wǎng)絡(luò)的受保護部分中。
Java(與Sun微系統(tǒng)平臺無關(guān)語言)便是在操作系統(tǒng)內(nèi)構(gòu)筑防火墻的因特網(wǎng)(或內(nèi)部網(wǎng))技術(shù)的實例，Java是要求安裝在各平臺上的解釋程序包含安全防火墻的解釋性語言。Java的不斷擴張的普及性顯示出在操作系統(tǒng)內(nèi)實現(xiàn)安全防護如何能方便信息交換。Java的問題在于在Java解釋程序內(nèi)實現(xiàn)的防火墻只對Java應(yīng)用有效。Java防火墻不能用來隔離用其它語言編寫的惡意應(yīng)用程序。
本發(fā)明支持在操作系統(tǒng)內(nèi)實現(xiàn)安全防護的替代方法，該方法對所有種類的應(yīng)用都工作得一樣好。庫可將專題標識為“可信任的專題”或“可疑專題”。如果自可信任的庫上的可信任的專題分布專題則將其標識為可信任的專題(或否則由授權(quán)的最終用戶標識為可信任的專題)。各庫維護它從中接受的可信任的應(yīng)用與軟件部件的分發(fā)的可信任庫的短表。庫所定義的可信任的庫的集合便是該庫的可信任域。不是從可信任的庫上的可信任專題分發(fā)的任何專題都標識為可疑專題。允許可疑專題修改包含在其本身的名字空間及列出該可疑專題為命名從屬的任何專題的名字空間內(nèi)的資源。然而，不允許可疑專題更新包含在任何其它專題內(nèi)的資源。這些限制有效地減少了惡意專題對庫或網(wǎng)絡(luò)作出的破壞。
也可能將某些可信任應(yīng)用標識為可疑專題以在一個應(yīng)用中包含已知的安全性暴露。例如，作為可疑專題實現(xiàn)的WWW瀏覽器能對形成已知的安全性危險的活動部件(Java、Active X等)提供支持。通過指定該WWW瀏覽器為可疑專題，將安全性危險限制在與該WWW瀏覽器關(guān)聯(lián)的名字空間上(如果它受到惡意破壞，很容易刪除與重構(gòu))。
上面概述的網(wǎng)絡(luò)安全性方法極大地消除了對防火墻的需求。因為應(yīng)用與軟件部件是隔離在單獨的專題中的，較少需要限制跨企業(yè)內(nèi)及企業(yè)間邊界的信息流。即使惡意程序在工作站上找到了進入了可信任的專題的方式，其惡意動作將局限在該特定工作站上，因為工作站通常不是任何其它工作站的可信任域的一部分。
基本專題方法(函數(shù))
能集成一個專題的各個實例來構(gòu)成分布式應(yīng)用。一種安裝分布式應(yīng)用的方法為獨立地安裝該專題的各實例，然后配置各個實例來構(gòu)成分布式應(yīng)用。然而，這一手動安裝過程涉及可觀的時間、費用及專業(yè)技術(shù)知識。
自動化構(gòu)造分布式應(yīng)用的能力是通過允許各專題管理其本身的分布達到的。為此，利用傳統(tǒng)的面向?qū)ο蟮姆椒▉砉芾韺ｎ}分布。除了封裝在專題內(nèi)的資源，各專題實現(xiàn)一組函數(shù)(稱作“方法”)來控制其本身的分布。這些函數(shù)管理庫內(nèi)的專題的復(fù)制，及分布專題到其它庫中。為專題實現(xiàn)的方法來對下列基本活動自動化·復(fù)制專題·移動專題·刪除專題·打開專題·公布專題·恢復(fù)專題·更新專題·發(fā)送專題下面的節(jié)中定義實現(xiàn)這些基本活動所需的特定方法。名詞QNID用來描述復(fù)合地址。
沒有必要為每一專題定義所有的該專題方法。例如，特定一個專題的實例可定義設(shè)計成管理一個工作組論壇的分布式應(yīng)用。雖然應(yīng)有可能復(fù)制包含該論壇的專題的實例，但沒有理由復(fù)制只提供論壇的進入點(a point of access)的實例，因為在單個庫中具有同一論壇的兩個進入點沒有意義。
同樣重要的是記住專題所用的所有方法與庫服務(wù)都是在特定專題的上下文內(nèi)執(zhí)行的。起初可能看似多余在一個單獨的專題的上下文內(nèi)執(zhí)行公共的庫函數(shù)(或操作系統(tǒng)函數(shù))。
公共庫函數(shù)可獨立實現(xiàn)為庫方法。這一方法的問題在于一個專題的各種實例是包含在不同的庫中的。如果獨立實現(xiàn)公共庫函數(shù)，則在執(zhí)行一個庫函數(shù)之前該專題的各實例必須識別適當?shù)膸臁＿@將在每一個專題上增加不必要的復(fù)雜度。如果一個應(yīng)用要執(zhí)行與諸如軟件部件等另一專題關(guān)聯(lián)的公共庫函數(shù)，則甚至要求更大的復(fù)雜度。通過允許專題從它們的相關(guān)庫中繼承庫函數(shù)(及操作系統(tǒng)函數(shù))，能避免這種復(fù)雜性的大部分。
復(fù)制專題網(wǎng)絡(luò)中的各專題可作為分布式應(yīng)用的部件工作并管理其本身的分布。由于專題的獨特特征，沒有某種模板，庫便不能建立新專題?！皬?fù)制專題”方法允許將任何現(xiàn)有的專題用作建立新專題的模板。
例如，考慮管理一個特定項目的銷售論壇的專題。該專題從屬于支持許多不同類型的論壇并包含銷售論壇的適當配置參數(shù)組的公共軟件部件。為該銷售論壇實現(xiàn)的復(fù)制專題方法為另一銷售工作生成一個銷售論壇。新銷售論壇也從屬于該公共軟件部件，并從現(xiàn)有的銷售論壇繼承適當?shù)呐渲脜?shù)。
公共軟件部件也能用作一個或多個專題類的模板。由于在單個庫中沒有理由保持一個軟件部件的兩個復(fù)制品，為軟件部件實現(xiàn)的復(fù)制專題方法可用來生成從屬專題。繼續(xù)上述示例，公共軟件部件的復(fù)制專題方法能建立若干不同類的論壇。在執(zhí)行復(fù)制專題方法期間要求終端用戶選擇特定類的論壇。如果終端用戶選擇銷售論壇，則用銷售論壇的默認配置參數(shù)初始化該新專題。
復(fù)制專題方法實現(xiàn)為兩部分BOOL CopyTopic( const char*cQNID，char*cNewQNID，DWORDiSizeofNewQNID)；BOOL InitAfterCopyTopic( const char*cOldQNID)；其中，cQNID為新專題的祖先的QNID，cNewQNID為保持復(fù)制專題方法為新專題生成的QNID的緩沖器，iSizeofNewQNID為cNewQNID緩沖器的長度，而cO1dQNID為原來的專題的QNID。
為了復(fù)制專題，調(diào)用為該專題定義的復(fù)制專題方法。復(fù)制專題方法建立新專題并初始化該新專題的內(nèi)容。最后，調(diào)用為該新專題定義的InitAfterCopyTopic方法來完成初始化過程。
移動專題移動專題方法用來改變與庫關(guān)聯(lián)的分層結(jié)構(gòu)。移動專題方法實現(xiàn)成兩部分BOOL MoveTopic(const char*cQNID)；BOOL UpdateAfterMoveTopic(const char*cOldQNID)；其中cQNID為該專題的新祖先的QNID，而c01dQIND為被移動的專題的QNID。
為了移動專題，調(diào)用為該專題實現(xiàn)的移動專題方法。移動專題方法消除作為其當前祖先的直接后代的專題，并作為用cQNID標識的專題的直接后代安裝該專題。然后為所有被移動的專題調(diào)用UpdateAfterMoveTopic方法。注意在移動專題時，同時移動其所有后代。
刪除專題刪除專題方法用于刪除一個專題及其所有后代。刪除專題方法實現(xiàn)成兩部分BOOL BeforeDeleteTopic( void)；BOOL DeleteTopic( const char*cQNID)；其中cQNID為要刪除的專題的QNID。
為了刪除專題，調(diào)用為該專題的祖先實現(xiàn)的Delete Topic(刪除專題)方法。然后為所有要刪除的專題調(diào)用BeforeDeleteTopic。如果未發(fā)現(xiàn)出錯。隨即刪除該專題及其所有后代。專題不刪除它們自己，因為許多操作系統(tǒng)不允許一個函數(shù)刪除從中加載該函數(shù)的文件。專題在被刪除之前仍使用BoforeDeleteTopie方法執(zhí)行任何要求的處理。通過返回出錯碼，專題也能利用BeforeDeleteTopic方法來阻止其本身的刪除。
打開專題打開專題方法用來激活與一個專題關(guān)聯(lián)的應(yīng)用。例如，用于帶有版本控制的文檔的打開專題方法激活設(shè)計成管理該文檔的各種版本的應(yīng)用。
BOOL OpenTopic( DWORD dwType，QN_LPEOLE_REQeale_req，QN_LPEOLE_INTeole_int)；其中dwType為要用來打開專題的方法，eole_req為描述應(yīng)如何打開該專題的結(jié)構(gòu)(eole_req將根據(jù)iMethod的值變化)，而eole_int為在其中返回指向打開的專題的指針的結(jié)構(gòu)(eole_int將根據(jù)iMethod的值變化)。
公布專題公布專題方法用于分布專題到另一庫中。公布專題方法假定應(yīng)將該專題的原始實例保留在源庫上并應(yīng)將復(fù)制品分布到目標庫上。公布專題方法實際上實現(xiàn)成四部分<pre listing-type="program-listing"><![CDATA[ BOOL BeforePublishTopic( QN_NEW_TOPIC_DATA*)； BOOL PublishTopic( const DWORD iMethod， const char*cLocation， const char*cQNID， TCHAR*cNeLocation， DWORD iSizeofNew Location)； BOOL InitAfterPublishTopic( QN_NEW_TOPIC_DATA*)； BOOL UpdateAfterPublishTopic(QN_NEW_TOPIC_DATA*)；]]></pre>其中iMethod是要用來公布該專題的方法，cLocation為目標庫的位置(cLocation將根據(jù)iMethod的值變化)，cQNID為公布的專題的缺省祖先的QNID，cNewLocation為用PublishTopic(公布專題)方法建立或更新的專題的位置，iSizeofNewLocation為分配給cNewLocation的緩沖器的大小，而QN_NEW_TOPIC_DATA為如下定義的結(jié)構(gòu)
<pre listing-type="program-listing"><![CDATA[ tyedef struct{ DWORD iMethod； charcQNID[QN_QNID_SIZE]； BOOLbExistingTopic； charcName[QN_QNID_SIZE]； charcTargetLocation[QN_DIR_SIZE]； charcSourceLocation[QN_DIR_SIZE]； charcQNIDAncestor[QN_QNID_SIZE]； }QN_NEW_TOPIC_DATA；]]></pre>其中如果在目標庫上存在該專題的一個實例則bExistingTopic為真，如果目標庫上不存在一個實例則其為假，cName為目標庫上的專題名(這一名字可以與原始專題名不同)，cTargetLocation為與目標庫中的專題的實例關(guān)聯(lián)的位置，cSourceLocation為與源庫中的專題的實例關(guān)聯(lián)的位置，而cQNIDAncestor為目標庫上的專題的祖先的QNID(如果iExisting Topic為假這將是默認祖先，如果iExistingTopic為真則是現(xiàn)有實例的祖先)。
為了公布專題，調(diào)用為該專題實現(xiàn)的Publish Topic(公布專題)方法。公布專題方法假定已為各命名從屬執(zhí)行過公布專題方法。然后公布專題方法檢驗?zāi)繕藥炫卸ㄊ欠褚汛嬖谠搶ｎ}的實例。如果在目標庫上已存在該專題的實例，則調(diào)用為該現(xiàn)有的實例實現(xiàn)的BeforePublishTopic方法；更新現(xiàn)有的專題的內(nèi)容；及調(diào)用用于該更新的專題的UpdateAfterPublishTopic方法。
如果在目標庫上找不到該專題的實例，則將該專題的實例加到目標庫上；為該新專題調(diào)用InitAfterPubLishTopic方法；然后調(diào)用UpdateAfterPublishTopic方法。InitAfterPublishTopic函數(shù)用于增加新專題到目標庫上。庫不能直接更新另一庫的配置文件，因為不同的庫可實現(xiàn)在不同平臺上并且它們的配置文件可采用不同的格式。
恢復(fù)專題恢復(fù)專題方法與公布專題方法相同，除了它將專題恢復(fù)到前一版本而不是將專題更新到更新的版本之外?；謴?fù)專題方法是設(shè)計成與公布專題方法一起工作的，以便可通過“公布”專題到另一庫上然后在必要時“恢復(fù)”它們而后備和恢復(fù)專題。例如，如果破壞或刪除了專題的原始實例可利用恢復(fù)專題方法從公布的實例中再生原始實例。當公布的專題實例包含不足以再生原始實例的信息時，將不支持恢復(fù)專題方法?；謴?fù)專題方法實際上實現(xiàn)成四部分<pre listing-type="program-listing"><![CDATA[ BOOL BeforeRestoreTopic( QN_NEW_TOPIC_DATA*)； BOOL RestoreTopic( const DWORD iMethod， const char*cLocation， const char*cQNID， TCHAR*cNewLocation DWORD iSizeofNewLocation)； BOOL InitAfterRestoreTopic( QN_NEW_TOPIC_DATA*)； BOOL UpdateAfterRestoreTopic(QN_NEW_TOPIC_DATA*)；]]></pre>其中iMethod是用來恢復(fù)該專題的方法，cLocation為目標庫的位置(cLocation將根據(jù)iMethod之值變化)，cQNID為恢復(fù)的專題的默認祖先的QNID，cNEWLocation為恢復(fù)專題方法建立或更新的專題的位置，iSizeofNewLocation為分配給cNewLocation的緩沖器的大小，而QN_NEW_TOPIC_DATA為公布專題方法指定的格式中的結(jié)構(gòu)。
更新專題更新專題方法用于控制專題更新的自動分布。當執(zhí)行更新專題方法時，專題檢驗判定是否可獲得更新用于分布。如果更新專題返回真，則iMethod、cLocation及cQNID標識包含該更新的專題的過程實例，從而可執(zhí)行公布專題方法來完成更新進程。更新專題方法實現(xiàn)如下
BOOL UpdateTopic( DWORD*iMethod，char*cLocation，DWORD iSizeofLocation，char*cQNID，DWORD iSizeofQNID)；其中iMethod為用來恢復(fù)專題的方法，cLocation為源庫的位置(cLocation將根據(jù)iMethod之值變化)，iSizeofLocation為分配給cLocation的緩沖器的大小，cQNID為源專題的QNID，而iSizeofQNID為分配給cQNID的緩沖器的大小。
發(fā)送專題發(fā)送專題方法用于分布專題給另一庫。發(fā)送專題方法假設(shè)應(yīng)將該專題的原始實例移動到目標庫，并應(yīng)將專題的復(fù)制品留在源庫上。
<pre listing-type="program-listing"><![CDATA[ BOOL BeforeRouteTopic(QN_NEW_TOPIC_DATA*)； BOOL RouteTopic( const DWORD iMethod， const char*cLocation， const char*cQNID， TCHAR*cNewLocation， DWORD iSizeofNewLocation)； BOOL InitAfterRouteTopic( QN_NEW_TOPIC_DATA*)； BOOL UpdateAfterRouteTopic(QN_NEW_TOPIC_DATA*)；]]></pre>其中iMethod為用于發(fā)送該專題的方法，cLocation為目標庫的位置(cLocation將根據(jù)iMethod之值變化)，cQNID為發(fā)送的專題的默認祖先的QNID，cNewLocation為用發(fā)送專題方法建立或更新的專題的位置，iSizeofNewLocation為分配給cNewLocation的緩沖器的大小，而QN_NEW_TOPIC_DATA為該公布專題方法指定的格式中的結(jié)構(gòu)。
為了發(fā)送專題，調(diào)用為該專題實現(xiàn)的發(fā)送專題方法。發(fā)送專題方法假定已執(zhí)行過用于各命名從屬的公布專題方法。發(fā)送專題方法將檢驗?zāi)繕藥炫卸ㄊ欠褚汛嬖谠搶ｎ}的實例。如果在目標庫上已存在該專題的實例，則調(diào)用為該現(xiàn)有的實例實現(xiàn)的BeforeRouteTopic方法；更新現(xiàn)有的專題的內(nèi)容；及調(diào)用用于該更新的專題的UpdateAfterRouteTopic方法。
如果在目標庫上找不到該專題的實例，則將該專題的實例增加到目標庫上；為該新復(fù)制品調(diào)用InitAfterRouteTopic方法；然后調(diào)用UpdateAfterRouteTopic方法。InitAfterRouteTopc函數(shù)用來增加新專題到目標庫上。庫不能直接更新另一庫的配置文件，因為不同的庫可在不同的平臺上實現(xiàn)，并可為它們的配置文件采用不同的格式。
復(fù)合地址將專題的各實例的全局地址定義為庫ID與專題ID的組合。定義了兩種形式的全局地址其中的庫ID默認為本地庫的相對QNID，及其中明確地陳述庫ID的絕對QNID。除了這兩種全局地址之外，以兩種其它基本格式定義地址相對地址及命名從屬。復(fù)合地址是通過將全局地址、相對地址與命名從屬鏈接在一起構(gòu)成的。
雖然為庫定義的組織結(jié)構(gòu)不應(yīng)用來定位特定資源，但存在著專題必須能標識活躍的視圖中的其它專題的情況?？蓪⑾鄬Φ刂酚糜谶@一目的。
也許相對地址的大多數(shù)普通使用是為了生成因特網(wǎng)(或內(nèi)部網(wǎng))文檔。相對地址能用來生成通過為庫定義的活躍視圖支持終端用戶導(dǎo)航的因特網(wǎng)文檔。為分層視圖定義下列相對地址<專題>-活躍的專題。
<-祖先>-活躍視圖中的該專題的祖先。
<-庫>-活躍視圖的根專題。
注意，沒有方法為直接后代定義相對地址，因為對各專題通常定義有一個以上直接后代。
將一個專題說成是從屬于第二專題，如果該第二專題是由該第一專題定義為命名從屬的話，其中命名從屬為一個名字與一個復(fù)合地址之間的一種聯(lián)系。與命名從屬關(guān)聯(lián)的名字可用作地址。給出了全局地址、相對地址及命名從屬的上述定義，復(fù)合地址可構(gòu)成如下·<復(fù)合地址>＝<全局地址>·<復(fù)合地址>＝<相對地址>
·<復(fù)合地址>＝<命名從屬>·<復(fù)合地址>＝<復(fù)合地址><復(fù)合地址>
當將兩個復(fù)合地址鏈接在一起時，第二復(fù)合地址是在第一復(fù)合地址的上下文內(nèi)計算的。下面的示例幫助說明如何計算復(fù)合地址。
·<專題><祖先>-引用活躍的專題的祖先。
·<命名從屬><祖先>-引用命名從屬的祖先。
·<祖先><命名從屬>-引用由活躍的專題的祖先定義的命名從屬。
對于上面提出的方法，可將任何有效的復(fù)合地址用作QNID。
已將專題定義為系統(tǒng)資源的封裝的集合。專題內(nèi)的各資源具有只在該專題所定義的上下文(或名字空間)內(nèi)才有效的名字。例如，各專題可包含用作其相關(guān)因特網(wǎng)(或內(nèi)部網(wǎng))文檔的入口點的命名為“index.htm”的文件。為了將一個專題鏈接到另一個上，專題引用包含在其它專題中的“index.htm”文件。其它專題內(nèi)的資源是利用該專題的復(fù)合地址作為前綴引用的。例如，對與專題的祖先關(guān)聯(lián)的因特網(wǎng)(或內(nèi)部網(wǎng))文檔的鏈接定義如下<祖先>index.htm。特殊目的資源類對于初始實現(xiàn)定義三個特殊目的資源類命名從屬、標簽及命名文件。
如上所述，命名從屬為名字與復(fù)合地址之間的聯(lián)系。標識為命名從屬的復(fù)合地址描述活躍的專題依賴其上的一組專題。例如，包含文檔的專題通常包含作為命名從屬的字處理系統(tǒng)。
標簽為名字與短正文短語之間的聯(lián)系。標簽主要由應(yīng)用用來定義要插入到為專題生成的因特網(wǎng)(或內(nèi)部網(wǎng))文檔中的短的正文短語。為所有專題定義下列標準標簽·名字-該專題之名稱。
·<復(fù)合地址>-指定的專題之名字。
·作者-制作該專題的個人之名。
·地址-作者的郵寄地址。
·電子郵件地址-作者的電子郵件地址。
·公司一開發(fā)該專題的公司。
命名文件為名字與路徑之間的聯(lián)系。在完整的實現(xiàn)中，與一個專題關(guān)聯(lián)的所有文件都封裝在該專題內(nèi)，對于命名文件則不需要。然而，當將本發(fā)明實現(xiàn)在傳統(tǒng)系統(tǒng)之上時，可能需要包含一或多個文件在專題內(nèi)而無須實際移動這些文件。這一方面，命名文件標識封裝在專題內(nèi)但尚未嵌入該專題的文件系統(tǒng)內(nèi)的文件。當公布或發(fā)送專題時，將任何命名文件的復(fù)制品嵌入該專題的遠程實例中。下面的方法可用來嵌入為專題定義的命名文件BOOL EmbedNamedFiles( void)；名字空間方法在完整的實現(xiàn)中，名字空間管理是相當簡單的事情，因為沒有必要翻譯名字。然而，建立在傳統(tǒng)系統(tǒng)之上的實現(xiàn)需要不斷地將名字從該專題的名字空間轉(zhuǎn)換到一或多個傳統(tǒng)名字空間。甚至使得名字翻譯更復(fù)雜的是，由于傳統(tǒng)名字(諸如基于LAN的目錄結(jié)構(gòu))通常按照特定的最終用戶的工作站配置變化。
對于專題將實現(xiàn)四種方法管理名字<pre listing-type="program-listing"><![CDATA[BOOL GetNamedItem( const char*cRClass， const char*cTopicName， const char*cReferenceName， char*cValue， DWORD iSizeofValue)； BOOL GetFirstNamedItem(const char*cRClass， const char*cReferenceName，char*cTopicName， DWORD iSizeofName， char*cValue， DWORD iSizeofValue)； BOOL GetNextNamedItem(const char*cRClass， const char*cReferenceName， char*cTopicName， DWORD iSizeofName， char*cValue， DWORD iSizeofValue)； BOOL SetNamedItem(const char*cRClass， const char*cTopicName， const char*cValue)；]]></pre>其中cRCLass為特定資源類的名字，cTopicName為在專題的名字空間中定義的資源的名字，iSizeofName是為cTopicName定義的緩沖器的大小，cReferenceName是作為某些名字空間翻譯的參照點所需要的，cValue為與cTopicName關(guān)聯(lián)的值，iSizeofValue是為cValue定義的緩沖器的大小。
對于初始實現(xiàn)，支持下列資源類相對QNID-用在庫內(nèi)的短格式QNID。
絕對QNID-用在網(wǎng)絡(luò)內(nèi)的長格式QNID。
標簽-名字與短正文短語之間的聯(lián)系。
命名從屬-名字與從屬專題之間的聯(lián)系。
直接后代-與專題關(guān)聯(lián)的直接后代。
命名文件-名字與文件之間的聯(lián)系。
相對路徑-相對于參考路徑的文件路徑。
絕對路徑-文件的全稱路徑。
不為專題的直接后代定義GetNamedItem與SetNamedItem方法。同時，不為相對路徑、絕對路徑、相對QNID或絕對QNID定義SetNamedItem方法。至少對于初始實現(xiàn)，GetFirstNamedItem與GetNextNamedItem所返回的項目不包含帶標準名字的項目。例如，GetFirstNamedItem與GetNextNamedItem對于“標簽”資源類別返回的項目將不包含為專題定義的名字。地址、電子郵件地址或任何其它標準標簽。因特網(wǎng)(或內(nèi)部網(wǎng))文檔如上所述，初始實現(xiàn)將包含因特網(wǎng)(或內(nèi)部網(wǎng))文檔集合作為與平臺無關(guān)的資源類。這允許將庫用作與平臺無關(guān)的內(nèi)部網(wǎng)公布工具。這一觀念是沒有關(guān)于內(nèi)部網(wǎng)技術(shù)的專門知識的用戶能作為他們的日常活動的自然副產(chǎn)品制作內(nèi)部網(wǎng)文檔。同時，由于專題能包含任意復(fù)雜的應(yīng)用，該實現(xiàn)不應(yīng)降低這些用戶的生產(chǎn)率。
一種方法是要求各專題制作它本身的因特網(wǎng)(或內(nèi)部網(wǎng))文檔。雖然這一方法永遠是專題的選項，它會在各專題上增加不必要的復(fù)雜程度。此外，利用不同方法在各專題中制作因特網(wǎng)(或內(nèi)部網(wǎng))文檔使得授權(quán)的最終用戶難于改變各專題所制作的因特網(wǎng)(或內(nèi)部網(wǎng))文檔的外觀與感覺。
為了解決這一問題，存在著生成因特網(wǎng)(或內(nèi)部網(wǎng))文檔的默認方法。這一方法要求各專題包含一個格式的集合。格式為包含預(yù)處理器命名的因特網(wǎng)(或內(nèi)部網(wǎng))文檔的集合。各庫包含集成庫組織、專題格式及內(nèi)容來為專題制作一組因特網(wǎng)(或內(nèi)部網(wǎng))文檔的預(yù)處理器。
預(yù)處理器命令定義如下·<XO Tag＝“標簽名字”>-預(yù)處理器用標簽之值替換這一命令。如果“標簽名字”為復(fù)合地址，則用引用的專題名字替換這一命令。
·<XO NamedFile＝“命名文件的名字”>-預(yù)處理器以到命名文件的相對路徑替換這一命令。
·<XO AbsolutePath＝“到文件的路徑”>-用到指定的文件的絕對路徑替換這一命令。“到文件的路徑”可以是對另一專題中的文件的引用(通過使用復(fù)合地址作為前綴)。
·<XO RelativePath＝“到文件的路徑”>-用到指定的文件的相對路徑替換這一命令?！暗轿募穆窂健笨梢允菍α硪粚ｎ}中的文件的引用(通過使用復(fù)合地址作為前綴)。
·<XO Text＝“到文件的路徑”>-這一命令指示應(yīng)將另一文本文件插入格式內(nèi)。這一命令允許應(yīng)用生成大段正文(可包含附加預(yù)處理器命令)供插入到專題格式內(nèi)。
·<XO AllDirectDescendents>-用一系列表項替換這一命令。各表項包含對為該專題定義的直接后代之一的引用。
·<XO AllNamedDependents>-用一系列表項替換這一命令。各表項包含對為該專題定義的命名從屬之一的引用。
·<XO AllNamedFiles>-用一系列表項替換這一命令。各表項包含對為該專題定義的命名文件之一的引用。
初始實現(xiàn)在更新專題的內(nèi)容或改變庫的組織時為各專題自動運行預(yù)處理器。這一方法將產(chǎn)生可在任何時間用現(xiàn)有的因特網(wǎng)(或內(nèi)部網(wǎng))瀏覽器觀看的一組靜態(tài)因特網(wǎng)(或內(nèi)部網(wǎng))文檔。對于初始實現(xiàn)只支持各庫的單一視圖，這是令人滿意的方法。它不可能協(xié)調(diào)支持多個視圖所要求的靜態(tài)因特網(wǎng)(內(nèi)部網(wǎng))文檔的所有不同版本。
一種替代方法支持多視圖。稱作動態(tài)預(yù)處理的一種替代方法，在網(wǎng)絡(luò)上訪問各個文檔時要求運行預(yù)處理器。由于這時該預(yù)處理器在特定視圖的上下文內(nèi)運行，能容易地將因特網(wǎng)(或內(nèi)部網(wǎng))文檔定制到該特定視圖上。
為了支持靜態(tài)因特網(wǎng)(或內(nèi)部網(wǎng))文檔的生成，為各專題實現(xiàn)下列方法BOOL ProcessStyles(void)；BOOL UpdateStyles(void)；BOOL UpdateTemplate(void)；ProcessStyles方法采用已為專題定義的格式并用它們?yōu)樵搶ｎ}生成一組因特網(wǎng)(或內(nèi)部網(wǎng))文檔。UpdateStyles方法用一個專題的類的默認格式替換已為該專題定義的格式。這些默認格式是與用來建立該專題的模板一起存儲的。UpdateTemplate方法用一個專題的類的默認模板替換與該專題關(guān)聯(lián)的模板。這些模板用于通過CopyTopic與PublishTopic方法建立與更新專題。
本發(fā)明允許將專題的格式與模板定制成符合各個作者的特定要求。UpdateStyles及UpdateTemplate方法提供取消這些定制改變的措施。UpdateStyles及UpdateTemplate方法還提供分布增強的格式與模板的措施，否則這些格式與模板是不能通過PublishTopic方法分布的。
雖然已參照較佳實施例描述了本發(fā)明，應(yīng)理解它可以以其它形式實施。例如，本發(fā)明能作為通用企業(yè)網(wǎng)、公用網(wǎng)(其范圍類似于環(huán)球網(wǎng)(WWW))、或低成本動態(tài)配置的工作站(一般稱作“網(wǎng)絡(luò)計算機”)的網(wǎng)絡(luò)實施。
熟悉本技術(shù)的人員會理解對特定實施例中所示的本發(fā)明可進行許多變化與/或修改而不脫離廣泛地描述的發(fā)明精神或范圍。因此，在所有方面都應(yīng)認為本實施例是示例性的而不是限制性的。
權(quán)利要求
1.一種用于網(wǎng)絡(luò)的分布式操作系統(tǒng)，包括一組庫，各庫存在于某一物理位置上并與不同專題的一組實例關(guān)聯(lián)；各專題為封裝的系統(tǒng)資源的集合并具有包含應(yīng)用、文檔、數(shù)據(jù)庫、軟件部件、或任何其它邏輯上相關(guān)的文件集合的文件系統(tǒng)，在任何給定時間上在任何給定的庫中只能存在一個專題的一個實例，但同一專題的多個實例可存在于不同的庫中；其中將需要第一與第二全局唯一的標識符的尋址標準應(yīng)用在該庫與專題上，第一全局唯一的標識符用于標識各庫，而第二全局唯一的標識符用于標識各專題。
2.按照權(quán)利要求1的分布式操作系統(tǒng)，其中專題的每一個實例不論它在哪一庫中，都將具有同樣的專題標識符。
3.按照權(quán)利要求1或2的分布式操作系統(tǒng)，其中的專題是組織成帶有根專題與后代專題的分層結(jié)構(gòu)的，該分層結(jié)構(gòu)只用來定位專題，而全局唯一的標識符是專用于標識專題的。
4.根據(jù)權(quán)利要求1、2或3的分布式操作系統(tǒng)，其中各專題實現(xiàn)一組面向?qū)ο蟮姆椒ㄒ詮?fù)制庫內(nèi)的專題、打開專題、及公布(或發(fā)送)專題到另一庫。
5.按照權(quán)利要求4的分布式操作系統(tǒng)，其中各專題實現(xiàn)附加的面向?qū)ο蠓椒ㄒ詮脑搶ｎ}的一個公布的實例恢復(fù)該專題及控制專題更新的自動化分布。
6.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中存在一致的通信協(xié)議來啟動應(yīng)用、軟件部件及作為不同專題存儲在單一庫中或網(wǎng)絡(luò)上的不同庫中的文檔之間的交互作用。
7.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中通過組合作為獨立專題分布的標準及定制部件的集合建立應(yīng)用與復(fù)合文檔。
8.按照權(quán)利要求4或5的分布式操作系統(tǒng)，其中通過利用各個專題所實現(xiàn)的面向?qū)ο蟮姆椒?gòu)造分布式應(yīng)用以在網(wǎng)絡(luò)上分布數(shù)據(jù)及軟件部件。
9.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中庫內(nèi)的專題是組織成只用來定位專題不用來標識專題的多個視圖的。
10.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中對一個專題的各實例將全局地址定義為庫ID與專題ID的組合。
11.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中專題用相對地址來標識活躍的視圖中的其它專題。
12.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中將一個專題看成是從屬于第二專題的，如果該第一專題將該第二專題定義為命名從屬的話。
13.按照權(quán)利要求10、11或12的分布式操作系統(tǒng)，其中通過將全局地址、相對地址與命名從屬鏈接在一起構(gòu)成復(fù)合地址。
14.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中為各專題定義格式，以便可生成適當?shù)囊蛱鼐W(wǎng)(或內(nèi)部網(wǎng))文檔集合來與一個擴展的工作組共享該專題的內(nèi)容。
15.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中對各個專題的訪問限于授權(quán)的用戶。
16.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中如果一個專題是從包含在可信任的庫中的可信任的專題公布的，則將其標識為可信任的專題，及各庫維護從其接收可信任的應(yīng)用與軟件部件的可信任的庫的列表；不特定地標識為可信任的專題的任何專題認為是可疑專題。
17.按照權(quán)利要求16的分布式操作系統(tǒng)，其中可疑專題只允許修改包含在它們自己的名字空間中及列出該可疑專題為命名從屬的任何專題的名字空間中的資源；可疑專題不允許更新包含在任何其它專題中的資源。
18.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中為各專題定義一個模板，該模板在庫內(nèi)復(fù)制該專題或公布該專題到另一庫時控制如何能以有用方式改變該專題的內(nèi)容與行為。
19.按照權(quán)利要求1、2、3、4或5的分布式操作系統(tǒng)，其中各專題運行在虛擬機器中，及各專題周圍的邊界將內(nèi)部的或虛擬的資源映射到外部的或?qū)嶋H資源上。
全文摘要
一種用于網(wǎng)絡(luò)的分布式操作系統(tǒng),包括一組庫,各庫存在于某一物理位置上并與不同專題的一組實例關(guān)聯(lián)。各專題為系統(tǒng)資源的一個封裝的集合并具有包含應(yīng)用、數(shù)據(jù)庫、軟件部件或任何其它邏輯上相關(guān)的文件集合的文件系統(tǒng)。在任何給定時間上在任何給定的庫中只存在一個專題的一個實例。同一專題的實例可存在于不同的庫中。將要求第一與第二全局唯一的標識符的尋址標準應(yīng)用在庫與專題上。第一全局唯一的標識符用于標識各庫。第二全局唯一的標識符用于標識各專題。專題的每一個實例無論它在哪一個庫中都擁有相同的專題標識符。庫外部存在著通信協(xié)議來啟動應(yīng)用、軟件部件及作為不同的庫中的專題存儲的文檔之間的交互作用。
文檔編號G06F12/00GK1246186SQ97181762
公開日2000年3月1日 申請日期1997年12月10日 優(yōu)先權(quán)日1996年12月12日
發(fā)明者R·布洛庫爾斯特 申請人:量子網(wǎng)絡(luò)私人有限公司