專利名稱：為可由硬件/軟件接口系統(tǒng)管理的信息單元提供同步服務的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及信息存儲和檢索領(lǐng)域，尤其涉及用于組織、搜索和共享計算機化系統(tǒng)中不同類型數(shù)據(jù)的活動存儲平臺。
背景在最近十年中，單個盤的容量每年增長約百分之70(70％)。摩爾(Moore)法則精確地預測了在過去數(shù)年中中央處理單元(CPU)能力的驚人的增長。有線和無線技術(shù)已經(jīng)提供了數(shù)量上巨大的連接和帶寬。假設(shè)當前趨勢持續(xù)，在數(shù)年內(nèi)一般的膝上計算機將具有約萬億字節(jié)(TB)的存儲并包含數(shù)百萬個文件，而5千億字節(jié)(500GB)的驅(qū)動器成為常見的。
消費者使用他們的計算機主要用于通信和組織個人信息，不論它們是傳統(tǒng)的個人信息管理器(PIM)風格的數(shù)據(jù)或如數(shù)字音樂或照片那樣的媒體。數(shù)字內(nèi)容的量和存儲原始字節(jié)的能力已經(jīng)大量地增長；然而消費者可用于組織和統(tǒng)一此數(shù)據(jù)的方法卻跟不上步伐。知識工人花費大量時間來管理和共享信息，某些研究估計，知識工人花費15-25％的時間在與無效信息有關(guān)的活動上。另外研究估計，典型的知識工人每天約花費2.5小時搜索信息。
開發(fā)者與信息技術(shù)(IT)部門投資大量的時間與金錢來構(gòu)建他們自己的用于公用存儲抽象的數(shù)據(jù)存儲，以呈現(xiàn)如人、地方、時間和事件等事項目。這不僅導致重復的工作，還形成公用數(shù)據(jù)的孤島，沒有共同搜索或共享那些數(shù)據(jù)的機制。僅考慮當今在運行Microsoft Windows操作系統(tǒng)的計算機上有多少地址簿。如電子郵件客戶端和個人財務程序那樣的許多應用程序保留各自的地址簿，且在每個那樣的程序分別維護的地址簿應用程序之間只有很少共享。因而，財務程序(如MicrosoftMoney)不與維護在電子郵件聯(lián)系人文件夾(如Microsoft Outlook中的聯(lián)系人文件夾)中的地址共享支付人的地址。確實，許多用戶具有多個設(shè)備，在這些設(shè)備之間和包括到如MSN和AOL等商業(yè)服務的手機電話號碼的各種附加來源之間應該在邏輯上同步它們的個人數(shù)據(jù)；然而共享文檔的協(xié)作大部分是通過將文檔附到電子郵件消息來達到的—這是手動的且低效的。
缺乏協(xié)作的一個原因是組織計算機系統(tǒng)中的信息的傳統(tǒng)方法集中在使用基于文件—文件夾—目錄的系統(tǒng)(“文件系統(tǒng)”)，來基于用于存儲文件的存儲介質(zhì)的物理組織的抽象將多個文件組織到文件夾的目錄分層結(jié)構(gòu)中。在1960年代開發(fā)的Multics操作系統(tǒng)被認為是在操作系統(tǒng)級上使用文件、文件夾和目錄來管理可存儲數(shù)據(jù)單元的先驅(qū)。具體說來，Multics在文件的分層結(jié)構(gòu)中使用符號地址(從而引入文件路徑的概念)，其中文件的物理地址對用戶(應用程序和最終用戶)是不透明的。此文件系統(tǒng)完全不考慮任何單個文件的文件格式，且在文件中及文件之間的關(guān)系在操作系統(tǒng)級上被認為是無關(guān)的(即，與分層結(jié)構(gòu)中文件的位置不同)。由于Multics的出現(xiàn)，在操作系統(tǒng)級上可存儲的數(shù)據(jù)被組織成文件、文件夾和目錄。這些文件一般包括放在由文件系統(tǒng)維護的一特定文件中的文件分層結(jié)構(gòu)本身(“目錄”)。此目錄進而維護對應于該目錄中所有其它文件和那些文件在分層結(jié)構(gòu)(這里指文件夾)中的節(jié)點位置的條目的列表。這是本領(lǐng)域中近40年的狀態(tài)。
然而，雖然提供了駐留在計算機的物理存儲系統(tǒng)中的信息的合理表示，但是文件系統(tǒng)是物理存儲系統(tǒng)的抽象，因而文件的利用需要在用戶處理什么(具有上下文、特征以及與其它單元的關(guān)系的單元)和操作系統(tǒng)提供什么(文件、文件夾和目錄)之間的間接(解釋)層。結(jié)果，用戶(應用程序和/或最終用戶)只好強制把信息單元放入文件系統(tǒng)結(jié)構(gòu)，即使這樣做是低效的、不一致的、或不希望的。此外，現(xiàn)有的文件系統(tǒng)關(guān)于在各個文件中存儲的數(shù)據(jù)的結(jié)構(gòu)知之甚少，因此，大多數(shù)信息在文件中保持封閉，只能被寫那些數(shù)據(jù)的應用程序訪問(和可理解)。因此，缺乏信息的模式描述和管理信息的機制，導致形成數(shù)據(jù)的豎井(silo)，只有很少數(shù)據(jù)能在各豎井之間共享。例如，許多個人計算機(PC)用戶具有5個以上各異的存儲，它們包含有關(guān)他們在某一層上交互的人的信息—如Outlook聯(lián)系人、在線賬戶地址、Windows地址簿、Quicken受款人和即時消息(IM)伙伴列表—因為組織文件向這些PC用戶提出重要的挑戰(zhàn)。由于大多數(shù)現(xiàn)有的文件系統(tǒng)利用嵌套的文件夾隱喻來組織文件和文件夾，因此當文件數(shù)量增加時，為維持靈活且有效的組織模式所必需的努力變得十分驚人。在這些情況下，具有單個文件的多重分類是非常有用的；然而使用現(xiàn)有文件系統(tǒng)中的硬和軟鏈接是麻煩且難以維護的。
過去已作了若干不成功的嘗試來克服文件系統(tǒng)的缺點。這些以前嘗試中的某一些已經(jīng)涉及使用內(nèi)容可定址的存儲器來提供可以通過內(nèi)容而不是通過物理地址來訪問數(shù)據(jù)的機制。然而，這些努力被證明是不成功的，因而雖然內(nèi)容可定址的存儲器對由如高速緩存和存儲器管理單元等設(shè)備的小規(guī)模使用被證明是有用的，但對如物理存儲介質(zhì)等設(shè)備的大規(guī)模使用由于各種原因尚不可能，因此那樣的解決方案簡直不存在。已作出使用面向?qū)ο蟮臄?shù)據(jù)庫(OODB)系統(tǒng)的其它嘗試，但是這些嘗試雖然帶有強烈的數(shù)據(jù)庫的特征，且良好的非文件表示，但在處理文件表示方面并不有效，并不能重現(xiàn)在硬件/軟件接口系統(tǒng)級上基于分層結(jié)構(gòu)的文件及文件夾的速度、效率和簡單性。諸如試圖使用SmallTalk(和其它派生方法)的其它嘗試在處理文件和非文件表示方面被證明相當有效，但缺乏有效地組織和利用在各種數(shù)據(jù)文件之間存在的關(guān)系所必需的數(shù)據(jù)庫特征，因此那種系統(tǒng)的整體有效性是不可接受的。使用BeOS(和其它那樣操作系統(tǒng)研究)的又一種嘗試盡管能夠勝任適當?shù)乇硎疚募耐瑫r又提供某些必要的數(shù)據(jù)庫特征，在處理非文件的表示上被證明是不夠的，這是傳統(tǒng)文件系統(tǒng)同樣的核心缺點。
數(shù)據(jù)庫技術(shù)是存在類似挑戰(zhàn)的另一專業(yè)領(lǐng)域。例如，雖然關(guān)系型數(shù)據(jù)庫模型已取得很大的商業(yè)上的成功，實際上獨立軟件分銷商(ISV)一般運用了關(guān)系型數(shù)據(jù)庫軟件產(chǎn)品(如Microsoft SQL Server)中可得到的功能一小部分。相反，應用程序與那樣產(chǎn)品的大多數(shù)交互是以簡單的“gets”和“puts”的形式。對此雖然有若干容易明白的原因(如作為平臺或數(shù)據(jù)庫的不可知)，一個常被忽略的關(guān)鍵的原因是數(shù)據(jù)庫沒有必要提供主要商業(yè)應用程序分銷商確實需要的精確抽象。例如，雖然真是世界具有如“客戶”或“訂單”等“項目”的概念(以及訂單的嵌入的“行式項目”作為其中的項目和項目本身)，而關(guān)系型數(shù)據(jù)庫只在表和行的方面來談論。結(jié)果，雖然應用程序可能希望具有在項目級上的一致性、鎖定、安全和/或觸發(fā)器的方面(只列出一些)，通常數(shù)據(jù)庫只在表/行級上提供這些特征。盡管若每個項目映射到數(shù)據(jù)庫某個表的單個行也能工作得很好，但在帶多個行式項目的訂單的情況下，存在一個項目實際上要映射到多個表的原因，且在此情況下，單個關(guān)系型數(shù)據(jù)庫系統(tǒng)不能確切地提供正確的抽象。因此，應用程序必須在數(shù)據(jù)庫的頂層構(gòu)建邏輯以提供這些基本抽象。換言之，基本關(guān)系模型不提供在其上容易開發(fā)高級應用程序的存儲數(shù)據(jù)的足夠平臺，因為基本關(guān)系模型需要在應用程序和存儲系統(tǒng)之間的間接層，其中只在某些情況的應用程序中可以看到數(shù)據(jù)的語義結(jié)構(gòu)。盡管某些數(shù)據(jù)庫分銷商正將高級功能構(gòu)建到他們的產(chǎn)品中(如提供對象關(guān)系能力，新的組織模型等)，至今尚沒有哪個提供需要的全面解決方案，其中真正的全面解決方案是為有用的域抽象(如“個人”、“位置”、“事件”等)提供有用的數(shù)據(jù)模型抽象(如“項目”、“擴展”、“關(guān)系”等)的解決方案。
考慮到現(xiàn)有數(shù)據(jù)存儲和數(shù)據(jù)庫技術(shù)中的上述缺點，需要一種新的存儲平臺，它提供了一種改進的能力以便組織、搜索和共享計算機系統(tǒng)中的所有類型的數(shù)據(jù)一一種存儲平臺，它在現(xiàn)有的文件系統(tǒng)和數(shù)據(jù)庫系統(tǒng)之外擴展和擴大了數(shù)據(jù)平臺，并且被設(shè)計為存儲所有類型的數(shù)據(jù)。本發(fā)明以及早先通過引用結(jié)合于此的相關(guān)發(fā)明滿足了這一需求。
概述下面的概述提供了以前面通過參考所結(jié)合的相關(guān)發(fā)明(“相關(guān)發(fā)明”)為背景說明的本發(fā)明的各個方面的總結(jié)。這個概述不旨在提供本發(fā)明的所有重要方面的無遺漏的說明，也不是對本發(fā)明的范圍的限定。而是，這個概述旨在作為下面的詳細說明和附圖的介紹。
相關(guān)發(fā)明共同地涉及用于組織、搜索和共享數(shù)據(jù)的存儲平臺，所述存儲平臺在現(xiàn)有文件系統(tǒng)和數(shù)據(jù)庫系統(tǒng)之外擴展和擴大了數(shù)據(jù)存儲的概念。這個存儲平臺被設(shè)計為存儲所有類型的數(shù)據(jù)，包括結(jié)構(gòu)化的、非結(jié)構(gòu)化的、或半結(jié)構(gòu)化的數(shù)據(jù)。
該存儲平臺包括在數(shù)據(jù)庫引擎上實現(xiàn)的數(shù)據(jù)存儲。所述數(shù)據(jù)庫引擎包括具有對象相關(guān)擴展的關(guān)系型數(shù)據(jù)庫引擎。所述的數(shù)據(jù)存儲實現(xiàn)了一種數(shù)據(jù)模型，它支持數(shù)據(jù)的組織、搜索、共享、同步和安全。以多種模式(schema)聲明了數(shù)據(jù)的具體類型，并且該平臺提供了一種機制，它擴展模式的設(shè)置以便定義新的數(shù)據(jù)類型(主要是，由所述模式提供的基本類型的子類型)。一種同步功能有助于在用戶或系統(tǒng)間共享數(shù)據(jù)。提供了文件系統(tǒng)類的功能，它允許所述數(shù)據(jù)存儲與現(xiàn)有的文件系統(tǒng)的互操作性，而不存在這種傳統(tǒng)文件系統(tǒng)的限制。一種改變跟蹤機制提供了跟蹤數(shù)據(jù)存儲的改變的能力。該存儲平臺還包括一組應用程序接口，它們使得應用程序能夠訪問所述存儲平臺上述的所有功能，并且能夠訪問以模式聲明的數(shù)據(jù)。
由所述數(shù)據(jù)存儲實現(xiàn)的數(shù)據(jù)模型以項目、元素和關(guān)系定義了數(shù)據(jù)存儲的單元。項目是在數(shù)據(jù)存儲中可存儲的數(shù)據(jù)的單元，并且可以包括一個或多個元素和關(guān)系。元素是類型的實例，包括一個或多個字段(此處也被稱為屬性)。關(guān)系是兩個項目之間的連接。(如此處所使用的，這些以及其它特定的術(shù)語可以被大寫，以便將它們從附近所使用的其它術(shù)語分離，然而，并不是旨在區(qū)別對待被大寫的術(shù)語例如“Item”和不被大寫時的同一個術(shù)語，例如“item”，并且不應假設(shè)或暗示這種區(qū)別。)該計算機系統(tǒng)還包括多個項目，其中每個項目包括一可由硬件/軟件接口系統(tǒng)操作的離散的可存儲的信息單元；多個項目文件夾，它們構(gòu)成了所述項目的組織結(jié)構(gòu)；以及用于操作多個項目的硬件/軟件接口系統(tǒng)，并且其中每個項目屬于至少一個項目文件夾，并且可以屬于多于一個的項目文件夾。
與從持久存儲中導出相反，項目或某些項目屬性值可以被動態(tài)地計算。換言之，所述硬件/軟件接口系統(tǒng)不需要項目被存儲，并且支持某些操作，諸如枚舉項目的當前設(shè)置的功能，或是給出項目在存儲平臺上的標識符(在描述應用編程接口或API的部分中被更完整地說明)而檢索項目的能力—例如，項目可以是蜂窩電話的當前位置，或從溫度傳感器讀到的溫度。所述硬件/軟件接口系統(tǒng)可以處理多個項目，并且還可以包括可由所述硬件/軟件接口系統(tǒng)管理的多個關(guān)系互連的項目。
用于該計算機系統(tǒng)的硬件/軟件接口系統(tǒng)還包括核心模式，以便定義所述硬件/軟件接口系統(tǒng)所理解，并且可以一種預先確定的和可預知的方式直接進行處理的一組核心項目。為了處理多個項目，所述計算機系統(tǒng)將項目與多個關(guān)系互連，并且在硬件/軟件接口系統(tǒng)層上管理所述關(guān)系。
該存儲平臺的API為在存儲平臺模式組中定義的每個項目、項目擴展和關(guān)系提供了數(shù)據(jù)類。此外，應用編程接口提供了一組框架類，它們?yōu)樗鰯?shù)據(jù)類定義了一組公共行為，并且與數(shù)據(jù)類一起為存儲平臺API提供了基本的編程模型。所述存儲平臺API提供了簡化的查詢模型，它以將應用程序員從底層數(shù)據(jù)庫引擎的查詢語言的細節(jié)隔離開的方式，使得應用程序員能夠形成基于數(shù)據(jù)存儲中的項目的各種屬性的查詢。存儲平臺API還收集由應用程序?qū)椖孔龀龅母淖?，并且然后將它們組織到實現(xiàn)所述數(shù)據(jù)存儲的數(shù)據(jù)庫引擎(或任何種類的存儲引擎)所需的正確更新中。這使得應用程序員能夠?qū)υ谟洃浿许椖窟M行改變，而將數(shù)據(jù)存儲更新的復雜細節(jié)留給API。
通過它的公共存儲基礎(chǔ)和被模式化的數(shù)據(jù)，本發(fā)明的存儲平臺能夠為消費者、知識工作者和企業(yè)作出更有效的應用程序開發(fā)。它提供了豐富的并且可擴展的應用編程接口，該接口不僅使得它的數(shù)據(jù)模型中所固有的功能可以使用，而且還包含并擴展了現(xiàn)有文件系統(tǒng)和數(shù)據(jù)庫的訪問方法。
作為相互關(guān)連的發(fā)明的這種延及全部的結(jié)構(gòu)(在詳細說明的部分II中詳細說明)的一部分，本發(fā)明特別地針對同步API(在詳細說明的部分III中詳細說明)。通過下面對本發(fā)明的以及附圖的詳細說明，將會明了本發(fā)明的其他特征和優(yōu)點。
附圖的簡要說明當結(jié)合所附的附圖進行閱讀時，可以更好地理解上面的摘要以及下面對本發(fā)明的詳細說明。出于說明本發(fā)明的目的，在附圖中示出了本發(fā)明的各個方面的示例性實施例；然而，本發(fā)明不限于所公開的具體方法和手段。在附圖中

圖1是表示本發(fā)明的方面可以被結(jié)合在其內(nèi)的計算機系統(tǒng)的方框圖；圖2是一個方框圖，示出了被分為3個組件組的計算機系統(tǒng)硬件組件、硬件/軟件系統(tǒng)接口組件和應用程序組件；圖2A示出了用于被分組到基于文件的操作系統(tǒng)中的目錄內(nèi)的文件夾中的文件的傳統(tǒng)的基于樹的分層結(jié)構(gòu)；圖3是示出了一個存儲平臺的方框圖；圖4示出了項目、項目文件夾和種類之間的結(jié)構(gòu)化的關(guān)系；圖5A是示出了項目的結(jié)構(gòu)的方框圖；圖5B是示出了圖5A的項目的復雜屬性類型的方框圖；圖5C是示出了“Location(位置)”項目的方框圖，其中“位置”項目的復雜類型被進一步說明(明確地被列出)；圖6A示出了一個作為基礎(chǔ)模式中的項目的子類型的項目；圖6B是示出了圖6A的子類型項目的方框圖，其中明確地列出了它的繼承的類型(除了它的直接屬性之外)；圖7是示出了基本模式的方框圖，該基本模式包括它的兩個頂層類類型，項目和屬性基礎(chǔ)，以及從其得出的附加基礎(chǔ)模式類型；圖8A是示出了核心模式中的項目的方框圖；圖8B是示出了核心模式中的屬性類型的方框圖；圖9是一個方框圖，示出了項目文件夾、它的成員項目以及項目文件夾和它的成員項目之間的互連關(guān)系；圖10是一個方框圖，示出了種類(它本身也是一個項目)、它的成員項目以及種類和它的成員項目之間的互連關(guān)系；圖11是示出了存儲平臺的數(shù)據(jù)模型的引用類型層次的圖；
圖12是示出了關(guān)系是如何被分類的圖；圖13是示出了通知機制的圖；圖14是示出了一個例子的圖，其中兩個事務都向同一個B樹中插入新的記錄；圖15示出了數(shù)據(jù)改變檢測處理；圖16示出了示例性的目錄樹；圖17示出了一個例子，其中現(xiàn)有的基于目錄的文件系統(tǒng)的文件夾被移動到所述的存儲平臺數(shù)據(jù)存儲中；圖18示出了容納文件夾的概念；圖19示出了存儲平臺API的基本體系結(jié)構(gòu)；圖20示意性地表示了存儲平臺API棧的各個組件；圖21A是示例的聯(lián)系人項目模式的圖形表示；圖21B是圖21A的示例的聯(lián)系人項目模式的元件的圖形表示；圖22示出了存儲平臺API的運行時框架；圖23示出了“FindAll”操作的執(zhí)行；圖24示出了這樣的處理，通過該處理從存儲平臺模式生成存儲平臺API類；圖25示出了這樣的模式，文件(File)API基于該模式；圖26是示出了用于數(shù)據(jù)安全目的的訪問掩碼格式的示意圖；圖27(部分a、b、c)給出了被從現(xiàn)有的安全區(qū)域內(nèi)劃分出來的一個新的被相同地保護的安全區(qū)域；圖28是示出了項目搜索視圖的概念的示意圖；圖29是示出了示例的項目分層的示意圖；圖30A示出了作為管道的接口“接口1”，第一和第二編碼段通過該接口通信；圖30B示出了一個接口，該接口包括接口對象11和12，它使得系統(tǒng)的第一和第二編碼段能夠通過介質(zhì)M通信；圖31A示出了由接口“接口1”提供的功能可以被如何劃分，以便將接口的通信轉(zhuǎn)換到多個接口“接口1A”、“接口1B”、“接口1C”；圖31B示出了由I1提供的功能可以被如何劃分到多個接口I1A、I1B、I1C；圖32A示出了一種情況，其中無意義的參數(shù)precision可以被忽略或被以任意的參數(shù)替換；圖32B示出了一種情況，其中接口被替代接口所替換，所述替代接口被指定用于忽略或向接口添加參數(shù)；圖33A示出了一種情況，其中第一和第二編碼段被合并到包含它們兩者的模塊中；圖33B示出了一種情況，其中接口的一部分或全部可以被嵌入地寫入另一個接口中，以便形成被合并的接口；圖34A示出了中間設(shè)備的一塊或多塊如何可以轉(zhuǎn)換第一接口上的通信以便使它們符合一個或多個不同的接口；圖34B示出了編碼段如何能夠與接口一起引入以便接收來自一個接口的通信并將所述功能傳輸給第二和第三接口；圖35A示出了即時編譯器(JIT)如何可以將來自一個編碼段的通信轉(zhuǎn)換到另一個編碼段；圖35B示出了用于動態(tài)重寫一個或多個接口的JIT方法，它可以被應用于動態(tài)因素或否則改變所述接口；圖36示出了公共數(shù)據(jù)存儲和組件的3個例子以便使它們同步；以及圖37示出了假設(shè)了單獨的適配器的本發(fā)明的一個實施例，所述適配器不知道狀態(tài)如何計算或者其相關(guān)元數(shù)據(jù)如何被交換；
詳細描述目錄I.引言..................................................14A.示例性計算環(huán)境........................................14B.傳統(tǒng)的基于文件的存儲……………………………………………17II.用于組織、搜索和共享數(shù)據(jù)的WINFS存儲平臺..............18A.詞匯表................................................18B.存儲平臺綜述..........................................19C.數(shù)據(jù)模型..............................................201.項目..................................................212.項目標識..............................................243.項目文件夾和類別......................................244.模式..................................................26a)基礎(chǔ)模式..............................................26b)核心模式..............................................265.關(guān)系..................................................28a)關(guān)系聲明..............................................28b)持有關(guān)系..............................................30c)嵌入關(guān)系..............................................31d)引用關(guān)系..............................................31e)規(guī)則和約束............................................32f)關(guān)系的排序............................................326.可擴展性..............................................36a)項目擴展..............................................37b)擴展NestedElement類型.................................40D.數(shù)據(jù)庫引擎............................................411.使用UDT的數(shù)據(jù)存儲實現(xiàn).................................422.項目映射..............................................433.擴展映射..............................................444.嵌套元素映射..........................................445.對象身份..............................................446.SQL對象命名...........................................447.列命名................................................458.搜索視圖..............................................45a)項目..................................................46
(1)主項目搜索視圖.......................................46(2)分類型的項目搜索視圖.................................47b)項目擴展..............................................47(1)主擴展搜索視圖.......................................47(2)分類型的擴展搜索視圖.................................48c)嵌套的元素............................................48d)關(guān)系..................................................48(1)主關(guān)系搜索視圖.......................................48(2)關(guān)系實例搜索視圖.....................................49e)......................................................499.更新..................................................4910.改變跟蹤及墓碑.......................................50a)改變跟蹤..............................................50(1)“主”搜索視圖中的改變跟蹤...........................51(2)“分類型的”搜索視圖中的改變跟蹤.....................52b)墓碑..................................................52(1)項目墓碑.............................................52(2)擴展墓碑.............................................53(3)關(guān)系墓碑.............................................53(4)墓碑清除.............................................5411.助手API和函數(shù)........................................54a)函數(shù)[System.Storage].GetItem..........................54b)函數(shù)[System.Storage].GetExtension.....................54c)函數(shù)[System.Storage].GetRelationship..................5412.元數(shù)據(jù)...............................................54a)模式元數(shù)據(jù)............................................55b)實例元數(shù)據(jù)............................................55E.安全性................................................55F.通知和改變跟蹤........................................55G.傳統(tǒng)文件互操作性......................................56H.存儲平臺API...........................................56III.同步API.............................................61A.同步綜述..............................................611.存儲平臺到存儲平臺的同步..............................62a)同步(Sync)控制應用程序................................63
b)模式注釋...............................................63c)同步配置...............................................64(1)共同體文件夾—映射....................................64(2)概況..................................................65(3)時間表................................................66d)沖突處理...............................................66(1)沖突檢測..............................................66(a)基于知識的沖突........................................66(b)基于約束的沖突........................................67(2)沖突處理..............................................67(a)自動沖突分解..........................................67(b)沖突日志記錄..........................................68(c)沖突檢查和分解........................................68(d)復制品的會聚性及沖突分解的傳播........................692.對非存儲平臺數(shù)據(jù)存儲的同步.............................69a)同步服務...............................................69(1)改變枚舉..............................................70(2)改變應用..............................................70(3)沖突分解..............................................71b)適配器實現(xiàn).............................................713.安全性.................................................714.可管理性...............................................72B.同步API綜述............................................721.一般術(shù)語...............................................722.同步API主體............................................74C.同步API服務............................................751.改變枚舉...............................................762.改變應用...............................................763.示例代碼...............................................774.API同步的方法..........................................81D.同步模式的附加方面.....................................82IV.結(jié)論..................................................83
I.引言本發(fā)明的主題用細節(jié)來描述，以滿足法定的要求。然而，該描述本身不試圖限制本專利的范圍。相反，本發(fā)明者設(shè)想，要求保護的主題也能以其它方式實施，以結(jié)合其它當前和未來的技術(shù)包括類似于本說明描述的不同的步驟或步驟的組合。此外，雖然術(shù)語“步驟”在這里可用于意味著所采用的方法的不同元素，然而該術(shù)語不能被解釋為在這里揭示的各步驟之間隱含特定的次序，除非明確地描述了各個步驟的次序。
A.示例性計算環(huán)境本發(fā)明的許多實施例可在計算機上執(zhí)行。圖1和下面討論旨在提供其中實現(xiàn)本發(fā)明的合適計算環(huán)境的簡要描述。雖然不是必需，本發(fā)明的諸方面能以諸如由如客戶工作站或服務器的計算機上執(zhí)行的程序模塊的計算機可執(zhí)行指令的一般上下文中描述。一般而言，程序模塊包括例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等，它們執(zhí)行特定任務或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型。此外，本發(fā)明可用其它計算機系統(tǒng)配置實現(xiàn)，包括手持設(shè)備、多處理器系統(tǒng)、基于微處理器的系統(tǒng)或可編程消費者電子設(shè)備、網(wǎng)絡(luò)PC、小型機、大型機等。本發(fā)明還能在分布式計算環(huán)境中實現(xiàn)，其中任務由通過通信網(wǎng)絡(luò)鏈接的遠程處理設(shè)備完成。在分布式計算環(huán)境中，程序模塊能位于本地或遠程存儲器存儲設(shè)備中。
如圖1所示，示例性通用計算系統(tǒng)包括傳統(tǒng)的個人計算機20等，它包括處理單元21、系統(tǒng)存儲器22和將包括系統(tǒng)存儲器的各種系統(tǒng)組件耦合到處理單元21的系統(tǒng)總線23。系統(tǒng)總線23可以是若干種總線結(jié)構(gòu)的任一種，包括存儲總線或存儲控制器、外圍總線、以及使用各種總線體系結(jié)構(gòu)的任一種的局部總線。系統(tǒng)存儲器包括只讀存儲器(ROM)24和隨機訪問存儲器(RAM)25?；据斎?輸出系統(tǒng)26(BIOS)包含如在啟動時幫助在個人計算機20的諸元件之間傳輸信息的基本例程，存儲在ROM 24中。個人計算機20還可包括讀寫硬盤(未示出)的硬盤驅(qū)動器27、讀寫可移動磁盤29的磁盤驅(qū)動器28、讀寫如CDROM或其它光介質(zhì)的可移動光盤29的光盤驅(qū)動器30。硬盤驅(qū)動器27、磁盤驅(qū)動器28和光盤驅(qū)動器30分別通過硬盤驅(qū)動器接口32、磁盤驅(qū)動器接口33和光盤驅(qū)動器接口34連接系統(tǒng)總線23。驅(qū)動器及其相關(guān)的計算機可讀介質(zhì)為個人計算機20提供計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊和其它數(shù)據(jù)的非易失存儲。雖然這里描述的示例性環(huán)境采用硬盤、可移動磁盤29和可移動光盤31，本專業(yè)技術(shù)人員理解，在示例性操作環(huán)境中也能使用可存儲能由計算機訪問的數(shù)據(jù)的其它類型計算機可讀介質(zhì)，如盒式磁帶、閃存卡、數(shù)字視頻盤、Bernoulli盒式磁帶、隨機存取存儲器(RAM)、只讀存儲器(ROM)等。類似地，示例環(huán)境還可包括許多類型的監(jiān)視設(shè)備，如熱敏和安全或火警系統(tǒng)，及其它信息來源。
若干程序模塊能存儲在硬盤、磁盤29、光盤31、ROM 24或RAM 25中，包括操作系統(tǒng)35、一個或多個應用程序36、其它程序模塊37和程序數(shù)據(jù)38。用戶能通過如鍵盤40和定位設(shè)備42等輸入設(shè)備將命令和信息輸入到個人計算機20。其它輸入設(shè)備(未示出)可包括麥克風、操縱桿、游戲墊、圓盤式衛(wèi)星天線、掃描儀等。這里和其它輸入設(shè)備常通過耦合到系統(tǒng)總線的串行接口46連接到處理單元21，但也可通過其它接口連接，如并行口、游戲口或通用串行總線(USB)。監(jiān)視器47或其它類型的顯示設(shè)備也通過如視頻適配器48的接口連接到系統(tǒng)總線23。除監(jiān)視器47以外，個人計算機通常包括如話筒和打印機等其它外圍輸出設(shè)備(未示出)。圖1的示例系統(tǒng)還包括主適配器55、小型計算機系統(tǒng)接口(SCSI)總線56和連接到SCSI總線的外部存儲設(shè)備62。
個人計算機20可使用到如遠程計算機49的一個或多個遠程計算機的邏輯連接在網(wǎng)絡(luò)環(huán)境中操作。遠程計算機49可以是另一臺個人計算機、服務器、路由器、網(wǎng)絡(luò)PC、對等設(shè)備或其它公共網(wǎng)絡(luò)節(jié)點，并通常包括以上對個人計算機20描述的許多或所有元件，雖然在圖1中只示出存儲器存儲設(shè)備50。圖1中畫出的邏輯連接包括局域網(wǎng)(LAN)51和廣域網(wǎng)(WAN)52。那樣的網(wǎng)絡(luò)環(huán)境常見于辦公室、企業(yè)范圍計算機網(wǎng)絡(luò)、內(nèi)聯(lián)網(wǎng)和因特網(wǎng)。
在LAN網(wǎng)絡(luò)環(huán)境中使用時，個人計算機20通過網(wǎng)絡(luò)接口或適配器53連接到LAN51。在WAN網(wǎng)絡(luò)環(huán)境中使用時，個人計算機20通常包括調(diào)制解調(diào)器54或用于通過如因特網(wǎng)等廣域網(wǎng)52建立通信的其它裝置。內(nèi)置或外接的調(diào)制解調(diào)器54通過串行端口接口46連接系統(tǒng)總線23。在網(wǎng)絡(luò)環(huán)境中，相對個人計算機20畫出的程序模塊或其部分可存儲在遠程存儲器存儲設(shè)備中?？梢岳斫猓境龅木W(wǎng)絡(luò)連接是示例性的，可使用在計算機之間建立通信鏈路的其它裝置。
如圖2的框圖所示，計算機系統(tǒng)200能被粗略地分成三個組件組硬件組件202、硬件/軟件接口系統(tǒng)組件204、以及應用程序組件206(在這里某些上下文中也稱為“用戶組件”或“軟件組件”)。
回到圖1，在計算機系統(tǒng)的各種實施例中，硬件組件202可包括中央處理單元(CPU)21、存儲器(ROM 24和RAM 25)、基本輸入/輸出系統(tǒng)(BIOS)26、以及各種輸入/輸出(I/O)設(shè)備，如鍵盤40、鼠標42、監(jiān)視器47、和/或打印機(未示出)等。硬件組件202包括計算機系統(tǒng)200的基本物理基礎(chǔ)結(jié)構(gòu)。
應用程序組件206包括各種軟件程序，包括但不限于編譯器、數(shù)據(jù)庫系統(tǒng)、文件處理程序、商業(yè)程序、視頻游戲等。應用程序提供計算機資源用于為各種用戶(機器、其它計算機系統(tǒng)和/或最終用戶)解決問題、提供解決方案和處理數(shù)據(jù)的手段。
硬件/軟件接口系統(tǒng)組件204包括(在某些實施例中可以僅包括)操作系統(tǒng)，在大多數(shù)情況后者本身包括外殼和內(nèi)核?！安僮飨到y(tǒng)”(OS)是啟動擔當在應用程序和計算機硬件之間的中介的特殊程序。硬件/軟件接口系統(tǒng)組件204還可包括虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物、Java虛擬機(JVM)或其功能等效物、或在計算機系統(tǒng)中的操作系統(tǒng)處或操作系統(tǒng)外的其它軟件組件。硬件/軟件接口系統(tǒng)的目的是提供用戶能在其中執(zhí)行應用程序的環(huán)境。任何硬件/軟件接口系統(tǒng)的目標是使計算機系統(tǒng)便于使用，以及以有效的方式利用計算機硬件。
硬件/軟件接口系統(tǒng)一般在啟動時被加載到計算機系統(tǒng)，并隨后管理在計算機系統(tǒng)中所有應用程序。應用程序通過經(jīng)由應用程序接口(API)請求服務來與硬件/軟件接口系統(tǒng)交互。某些應用程序使最終用戶能通過如命令語言或圖形用戶界面(GUI)與硬件/軟件接口系統(tǒng)交互。
硬件/軟件接口系統(tǒng)傳統(tǒng)上執(zhí)行應用程序的各種服務。在多個程序同時運行的多任務硬件/軟件接口系統(tǒng)中，硬件/軟件接口系統(tǒng)確定哪些應用程序以什么次序運行，以及在切換到另一應用程序之前以供輪流對每個應用程允許多少時間。硬件/軟件接口系統(tǒng)還管理在多個應用程序之間內(nèi)部存儲器的共享，并處理來往于如硬盤、打印機和撥號端口等附加的硬件設(shè)備的輸入和輸出。硬件/軟件接口系統(tǒng)還將有關(guān)操作狀態(tài)和可能發(fā)生的任何錯誤的消息發(fā)送到每個應用程序(在某些情況下到最終用戶)。硬件/軟件接口系統(tǒng)也能下傳(offload)批處理作業(yè)(如打印)的管理，使得啟動的應用程序能擺脫此工作并重新開始其它處理和/或操作。在能提供并行處理的計算機上，硬件/軟件接口系統(tǒng)還管理劃分程序，使得它同時在多個處理器上運行。
硬件/軟件接口系統(tǒng)外殼(這里簡稱“外殼”)是到硬件/軟件接口系統(tǒng)的交互式最終用戶界面。(外殼也稱為“命令解釋器”，或在一個操作系統(tǒng)中稱為“操作系統(tǒng)外殼”)。外殼是可直接由應用程序和/或最終用戶訪問的硬件/軟件接口系統(tǒng)的外層。與外殼相反，內(nèi)核是直接與硬件組件交互的硬件/軟件接口系統(tǒng)的最內(nèi)層。
雖然可構(gòu)想本發(fā)明的許多實施例尤其適用于計算機化的系統(tǒng)，然而在本說明中不意味著將本發(fā)明限于那些實施例。相反，這里使用的術(shù)語“計算機系統(tǒng)”旨在包括能存儲和處理信息和/或能使用存儲的信息控制設(shè)備本身的行為或執(zhí)行的任何和所有設(shè)備，而不管那些設(shè)備本質(zhì)上是否為電子的、機械的、邏輯的、或虛擬的。
B.傳統(tǒng)的基于文件的存儲在當今大多數(shù)計算機系統(tǒng)中，“文件”是可存儲信息的單元，它可包括硬件/軟件接口系統(tǒng)和應用程序、數(shù)據(jù)集等。在所有現(xiàn)代硬件/軟件接口系統(tǒng)中(Windows，Unix，Linux，MacOS，虛擬機系統(tǒng)等)，文件是能由硬件/軟件接口系統(tǒng)處理的基本的分立(可存儲和可檢索)信息單元。文件組通常被組織成“文件夾”。在MicrosoftWindows、Macintosh OS和其它硬件/軟件接口系統(tǒng)中，文件夾是能作為單個信息單元被檢索、移動和處理的文件的集合。這些文件夾進而被組織成稱為“目錄”(在后面詳細討論)的基于樹形的分層結(jié)構(gòu)排列。在如Dos、z/OS和大多數(shù)基于Unix的操作系統(tǒng)的其它硬件/軟件接口系統(tǒng)中，術(shù)語“目錄”和/或“文件夾”是可交替使用的，早期的Apple計算機系統(tǒng)(如AppleIIe)使用術(shù)語“類別”來代替目錄；然而在這里使用時所有這些術(shù)語被看成是同義語并可交替使用，并旨在還包括對分層信息存儲結(jié)構(gòu)及其文件夾和文件組件的所有其它等價術(shù)語的引用。
傳統(tǒng)上，目錄(又名文件夾的目錄)是基于樹形的分層結(jié)構(gòu)，其中文件被組合成文件夾，文件夾進而按包括目錄樹的相對節(jié)點位置排列。例如，如圖2A所示，基于DOS的文件系統(tǒng)的基本文件夾(或“根目錄”)212可包括多個文件夾214，其每一個可以還包括另外的文件夾(如特定文件夾的“子文件夾”)216，而這些的每一個又包括另外的文件夾218，直到無限。這些文件夾的每一個可具有一個或多個文件220，雖然在硬件/軟件接口系統(tǒng)級上，文件夾中的各個文件除了它們在樹形分層結(jié)構(gòu)中的位置外沒有什么共同點。不奇怪，將文件組織到文件分層結(jié)構(gòu)的方法間接地反映了用于存儲這些文件的典型存儲介質(zhì)(如硬盤、軟盤、CD-ROM等)的物理組織。
除上述以外，每個文件夾是對其子文件夾和其目錄的容器一即，每個文件夾擁有其子文件夾和文件。例如，當文件夾被硬件/軟件接口系統(tǒng)刪除時，該文件夾的子文件夾和文件也被刪除(在每個子文件夾的情況下還遞歸地包括它自己的子文件夾和文件)。同樣，每個文件一般只由一個文件夾擁有，并且雖然文件能被拷貝且副本位于不同的文件夾，文件的副本本身是不同且獨立單元，它與原始文件無直接連接(如對原始文件的改變在硬件/軟件接口系統(tǒng)級上不反映到副本文件)。因此在這方面，文件和文件夾在本質(zhì)上是“物理的”，因為文件夾類似于物理容器來處理，而文件作為這些容器中不同且獨立的物理元素來處理。
II.用于組織、搜索和共享數(shù)據(jù)的WINFS存儲平臺本發(fā)明結(jié)合通過引用結(jié)合于此的發(fā)明針對用于組織、搜索和共享數(shù)據(jù)的存儲平臺。本發(fā)明的存儲平臺擴展和拓寬了數(shù)據(jù)平臺，超越上文討論的文件系統(tǒng)及數(shù)據(jù)庫系統(tǒng)，并被設(shè)計成存儲所有類型的數(shù)據(jù)，包括稱為項目的新格式的數(shù)據(jù)。
A.詞匯表在這里及在權(quán)利要求書中使用的術(shù)語有下列意義·“項目”是能存儲硬件/軟件接口系統(tǒng)可訪問的信息的單元，不象簡單文件，它是具有由硬件/軟件接口系統(tǒng)外殼展現(xiàn)給最終用戶的所有對象共同支持的基本屬性集的對象。項目還具對所有項目類型共同支持的屬性和關(guān)系，包括允許引入新屬性和關(guān)系的特征(在下面詳細討論)。
·“操作系統(tǒng)”(OS)是扮作應用程序和計算機硬件之間的中介的特殊程序。在大多數(shù)情況下，操作系統(tǒng)包括外殼和內(nèi)核。
·“硬件/軟件接口系統(tǒng)”是軟件、或硬件及軟件的組合，它起著在計算機系統(tǒng)的底層硬件組件和在計算機系統(tǒng)上執(zhí)行的應用程序之間的接口的作用。硬件/軟件接口系統(tǒng)通常包括(在某些實施例中只包括)操作系統(tǒng)。硬件/軟件接口系統(tǒng)還能包括虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物，Java虛擬機(JVM)或其功能等效物、或在計算機系統(tǒng)的操作系統(tǒng)處或除操作系統(tǒng)外的其它軟件組件。硬件/軟件接口系統(tǒng)的目的是提供用戶能執(zhí)行應用程序的環(huán)境。任何硬件/軟件接口系統(tǒng)的目標是使計算機系統(tǒng)便于使用，并以有效方式利用計算機硬件。
B.存儲平臺綜述參考圖3，存儲平臺300包括在數(shù)據(jù)庫引擎314上實現(xiàn)的數(shù)據(jù)存儲302。在一個實施例中，數(shù)據(jù)庫引擎包括帶有對象關(guān)系擴展的關(guān)系型數(shù)據(jù)庫引擎。在一個實施例中，關(guān)系型數(shù)據(jù)庫引擎314包括Microsoft SQL Server關(guān)系型數(shù)據(jù)庫引擎。數(shù)據(jù)存儲302實現(xiàn)支持數(shù)據(jù)的組織、搜索、共享、同步和安全的數(shù)據(jù)模型304。在如模式340等模式中描述特定的數(shù)據(jù)類型，并且存儲平臺300提供用于采用這些模式并用于擴展這些模式的工具346，這在后面詳述。
在數(shù)據(jù)存儲302中實現(xiàn)的改變跟蹤機制306提供跟蹤數(shù)據(jù)存儲的改變的能力。數(shù)據(jù)存儲302還提供安全能力308和升級/降級能力310，均在后文詳述。數(shù)據(jù)存儲302還提供一組應用程序接口312，以向利用該存儲平臺的其它存儲平臺組件和應用程序(如應用程序350a，350b和350c)展現(xiàn)數(shù)據(jù)存儲302的能力。本發(fā)明的存儲平臺還包括應用程序接口(API)322，使如應用程序350a，350b，和350c等應用程序能訪問存儲平臺的所有上述功能并能訪問在模式中描述的數(shù)據(jù)。應用程序能結(jié)合如OLE OB API324和Microsoft Windows Win 32 API 326等其它API來使用存儲平臺API 322。
本發(fā)明的存儲平臺300能向應用程序提供各種服務，包括便于在用戶或系統(tǒng)之間共享數(shù)據(jù)的同步服務330。例如，同步服務330允許與具有與數(shù)據(jù)存儲302相同格式的其它數(shù)據(jù)存儲340的互操作，并訪問具有其它格式的數(shù)據(jù)存儲342。存儲平臺300還提供允許數(shù)據(jù)存儲302與如Windows NTFS文件系統(tǒng)318等現(xiàn)有文件系統(tǒng)的互操作的文件系統(tǒng)能力。在至少某些實施例中，存儲平臺320還能向應用程序提供另外的能力，以允許對數(shù)據(jù)起作用并允許與其它系統(tǒng)的交互。這些能力可體現(xiàn)在如Info Agent服務334和通知服務332等附加服務328的形式中，以及體現(xiàn)在其它實用程序336的形式中。
在至少某些實施例中，存儲平臺以計算機系統(tǒng)的硬件/軟件接口系統(tǒng)來實施，或形成其完整的一部分。例如而非限制，本發(fā)明的存儲平臺能用操作系統(tǒng)、虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物、或Java虛擬機(JVM)或其功能等效物來實施，或形成其完整的一部分。通過其公用的存儲基礎(chǔ)和模式化的數(shù)據(jù)，本發(fā)明的存儲平臺使消費者、知識工人和企業(yè)作能夠更有效地進行應用程序的開發(fā)。它提供了豐富和可擴展的編程表面區(qū)域，不僅可得到內(nèi)含在其數(shù)據(jù)模型中的能力，還能包括和擴展現(xiàn)有文件系統(tǒng)和數(shù)據(jù)庫訪問方法。
在上述描述中及在各種附圖中，本發(fā)明的存儲平臺300可稱作“WinFs”。然而使用此名字指存儲平臺僅是為了描述方便，并不試圖作出如此限制。
C.數(shù)據(jù)模型本發(fā)明的存儲平臺300的數(shù)據(jù)存儲302實現(xiàn)一種數(shù)據(jù)模型，它支持對駐留在數(shù)據(jù)存儲中的數(shù)據(jù)的組織、搜索、共享、同步和安全。在本發(fā)明的數(shù)據(jù)模型中，“項目”是存儲信息的基本單元。該數(shù)據(jù)模型提供一種機制，用于聲明項目和項目的擴展、用于建立在項目之間的關(guān)系、以及用于將項目組織到項目文件夾和類別中，下面將更充分描述。
該數(shù)據(jù)模型依賴于兩個原語機制類型和關(guān)系。類型是提供支配類型的實例的形式的格式的結(jié)構(gòu)。格式被表達成屬性的有序組。屬性是給定類型的值或一組值的名字。例如，USPostalAddress(美國郵政地址)類型具有屬性Street(街道)、City(城市)、Zip(郵編)、State(州)，其中Street、City和State是String類型，而Zip是Int32類型。Street可以是多值(即一組值)，允許地址對Street屬性具有一個以上值。系統(tǒng)定義能在其它類型構(gòu)造中使用的某些原語類型，包括String、Binary、Boolean、Int16、Int32、Int64、Single、Double、Byte、DateTime、Decimal和GUID?？墒褂萌魏卧Z類型(帶有下面注釋的某些限制)或任何構(gòu)造的類型來定義類型的屬性。例如，Location(位置)類型可定義具有屬性Coordinate(座標)和Address(地址)，其中Address屬性是上述類型USPostalAddress。屬性也可以是必需的或可任選的。
關(guān)系可被聲明并表示兩個類型的實例集之間的映射。例如，可以有在Person(個人)類型和Location類型之間聲明的關(guān)系，稱為LivesAt(生活在)，它確定什么人生活在什么位置。關(guān)系具有名和兩個端點，即源端點和目標端點。關(guān)系也可具有屬性的有序集。源端點及目標端點均具有名和類型。例如，LivesAt關(guān)系具有稱為類型Person的Occupant(居民)的源和稱為類型Location的Dwelling(住房)的目標，且此外具有屬性StartDate(起始日期)和EndDate(終止日期)，表示該居民生活在該住房的時間段。注意，隨時間推移，個人能生活在多個住房，且住房可有多個居民，所以放置StartDate和EndDate信息的最可能的地方是在關(guān)系本身處。
關(guān)系定義了在由作為端點類型給出的類型約束的實例之間的映射。例如LivesAt關(guān)系不能是其中Automobile(汽車)是Occupant(居民)的關(guān)系，因為Automobile不是Person。
數(shù)據(jù)模型允許定義類型間的子類型一超類型關(guān)系。也稱為基本類型關(guān)系的子類型一超類系型關(guān)系以如下方式定義，若類型A是類型B的基本類型，則必須是B的每個實例也是A的實例的情況。另一種表達的方法是符合B的每個實例必須符合A。例如，若A具有String類型的屬性Name(名字)，而B具有Int16類型的屬性Age(年齡)，則得出，B的任何實例必須兼有Name和Age。類型的分層結(jié)構(gòu)可被設(shè)想成帶有在根上的單個超類型的樹。根的分枝提供第一級子類型，該級分枝提供第二級子類型，如此等等，直到本身不再具有任何子類型的葉端(1eaf-most)子類型。樹不限于統(tǒng)一深度，但不能包含任何回路。給定的類型可具有零個或許多子類型和零個或一個超類型。給定實例可最多符合一個類型以及該類型的超類型。換言之，對樹中任一級處給定的實例，該實例最多可符合該級上的一個子類型。如果一類型的實例必須也是該類型的子類型的實例，則該類型可說成是抽象。
1.項目項目是可存儲的信息的單元，不象簡單的文件，它是具有由存儲平臺向最終用戶或應用程序展現(xiàn)的所有對象共同支持的基本屬性集的對象。項目也具有所有項目類型共同支持的屬性和關(guān)系，包括如下所述允許引入新的屬性和關(guān)系的特征。
項目是公用操作的對象，如拷貝、刪除、移動、打開、打印、備份、恢復、復制等。項目是能被存儲和檢索的單元，且由存儲平臺處理的可存儲信息的所有形式作為項目、項目的屬性、或項目之間的關(guān)系存在，其每個在下面更詳細討論。
項目旨在表示顯示的且容易理解的數(shù)據(jù)單元，如聯(lián)系人(Contacts)、人(People)、服務(Services)、位置(Locations)、(各種類型的)文檔(Documents)等。圖5A是示出項目的結(jié)構(gòu)的框圖。該項目的不合格的名是“Location”。該項目的合格名是“Core.Location”，它表明，此項目結(jié)構(gòu)被定義成Core(核心)模式中的特定類型的項目(Core模式在下面詳細討論)。
Location項目具有多個屬性，包括EAddress(電子郵件地址)、MetropolitanRegion(都市地區(qū))、Neighborhood(街坊)、和PostalAddress(郵政地址)。每個項目的特定類型屬性緊跟屬性名地表示，并用冒號(“”)與屬性名分開。在類型名的右邊，對該屬性類型允許的值的數(shù)量在方括號(“[]”)之間表示，其中冒號(“”)右邊的星號(“*”)表示未規(guī)定的和/或無限制的數(shù)量(“許多”)。冒號右邊的“1”表明最多一個值。冒號左邊的零(“0”)表明該屬性是可任選的(可以完全沒有值)。冒號左邊的“1”表明必須至少有一個值(該屬性是必須的)。Neighborhood和MetropolitanRegin均是“nvarchar”類型(或等效類型)，它是預定義的數(shù)據(jù)類型或“簡單類型”(這里用缺少大寫來表示)。然而EAddress和PostalAddress分別是類型EAddress和PostalAddress的已定義類型或“復雜類型”(這里用大寫標記)的屬性。復雜類型是從一個或多個簡單數(shù)據(jù)類型和/或從其它復雜類型導出的類型。一個項目的屬性的復雜類型還構(gòu)成”嵌套元素“，因為復雜類型的細節(jié)嵌套入直接項目中以定義其屬性，而屬于這些復雜類型的信息用具有這些屬性的項目來維持(在該項目的邊界內(nèi)，如后面討論)。類型的這些概念是眾知的，且容易被本專業(yè)技術(shù)人員理解。
圖5B是示出復雜屬性類型PostalAddress和EAddress的框圖。PostalAddress屬性類型定義，屬性類型PostalAddress的項目可期望有零個或一個City(城市)值、零個或一個Country Code(國家代碼)值、零個或一個MailStop(國家代碼)值、和任何數(shù)量(零到許多)PostalAddress類型等等。以此方式，定義了一項目中的特定屬性的數(shù)據(jù)的形狀。EAddress屬性類型如所示類似地定義。雖然這里在本申請中可任選地使用，表示在Location項目中復雜類型的另一方法是用其中列出的每個復雜類型的各個屬性得出該項目。圖5C是示出Location項目的框圖，在其中進一步描述其復雜類型。然而應該理解，在此圖5C中Location項目的另一種表示恰是對圖5A中示出的同一個項目。本發(fā)明的存儲平臺還允許子分類(subtyping)，從而一個屬性類能是另一個的子類型(其中一個屬性類繼承另一個父屬性類型的屬性)。
類似于但不同于屬性及它們的屬性類型，項目繼承性地表示其自己的Item(項目)類型，它也是子分類的主題。換言之，本發(fā)明的若干實施例中的存儲平臺允許一個項目是另一個項目的子類型(從而一個項目繼承另一個父項目的屬性)。此外，對本發(fā)明的各種實施例，每個項目是“Item”項目類型的子類型，后者是在基礎(chǔ)模式中找到的第一和基本的項目類型(基礎(chǔ)模式也在后面詳細討論)。圖6A示出一項目(在此實例中為Location項目)為在基礎(chǔ)模式中找到的Item項目類型的子類型。在此圖中，箭頭表示Location項目(如所有其它項目)是Item項目類型的子類型。作為從中導出所有其它項目的基本項目的Item項目類型具有若干如ItemId的重要屬性和各種時間標記，從而定義了操作系統(tǒng)中所有項目的標準屬性。在本圖中，Item項目類型的這些屬性被Location所繼承，并從而成為Location的屬性。
表示從Item項目類型繼承的Location項目中屬性的另一種方法是用來自其中列出的父項目的每個屬性類型的各個屬性得出Location。圖6B是示出Location項目的框圖，其中除了其直接屬性外描述其繼承的類型。應注意和理解，此項目是圖5A中示出的同一項目，雖然在本圖中，Location用所有其屬性示出，包括直接屬性(在本圖及圖5A中示出)和繼承屬性(在本圖中示出但未在圖5A中示出)(而在圖5A中，通過用箭頭示出Location項目是Item項目類型的子類型來引用這些屬性)。
項目是獨立的對象，因而若刪除一項目，也刪除項目的所有直接和繼承的屬性。類似地，當檢索一項目時，檢索的是該項目及其所有直接和繼承的屬性(包括屬于其復雜屬性類型的信息)。本發(fā)明的某些實施例可使人們能在檢索特定項目時請求屬性的子集；然而對許多那樣的實施例默認的是在檢索時向項目提供所有其直接和繼承的屬性。此外，項目的屬性也能通過添加新的屬性到該項目的類型的現(xiàn)有屬性而加以擴展。這些“擴展”其后是該項目的真實屬性，且該項目類型的子類型可自動地包括擴展屬性。
項目的“邊界”由其屬性(包括復雜屬性類型、擴展等)來表示。項目的邊界也表示在項目上執(zhí)行的操作的限制，包括拷貝、刪除、移動、創(chuàng)建等。例如在本發(fā)明的若干實施例中，當拷貝一項目時，在該項目邊界之內(nèi)的所有內(nèi)容也被拷貝。對每個項目，邊界包括下列·項目的項目類型，且若該項目是另一項目的子類型(如在所有項目從基礎(chǔ)模式的單個項目和項目類型導出的本發(fā)明的若干實施例的情況下)，是任何適用的子類型信息(即屬于父項目類型的信息)。若要拷貝的原始項目是另一項目的子類型，該副本也能是該相同項目的子類型。
·項目的復雜類型屬性和擴展(如果有的話)。若原始項目具有復雜類型(原來的或擴展的)的屬性，副本也能具有相同的復雜類型。
·在“所有權(quán)關(guān)系”上的項目的記錄，即，本項目(“擁有項目”)擁有什么其它項目(“目錄項目”)的項目擁有列表。這特別關(guān)系到下面充分討論的項目文件夾和下面說到的所有項目必須至少屬于一個項目文件夾的規(guī)則。此外，關(guān)于嵌入項目(下列更充分討論)，一個嵌入項目被認為是其中嵌入如拷貝、刪除等操作的項目的一部分。
2.項目標識在全局項目空間中用ItemID唯一地標識項目。Base.Item類型定義了存儲該項目身份的類型GUID的字段ItemID。一項目必須在數(shù)據(jù)存儲中準確只有一個身份。
項目引用是包含定位和標識項目的信息的數(shù)據(jù)結(jié)構(gòu)。在該數(shù)據(jù)模型中，定義名為ItemReference的抽象類型，從中導出所有項目引用類型。ItemReference(項目引用)類型定義了名為Resolve(解析)的虛擬方法。Resolve方法解析ItemReference并返回一項目。此方法被ItemReference的具體子類型所覆蓋，后者實現(xiàn)給定一引用時檢索項目的功能。調(diào)用Resolve方法作為存儲平臺API 322的一部分。
ItemIDReference(項目ID引用)是ItemReference的子類型。它定義了Locator(定位器)和ItemID字段。Locator字段命名(即標識)項目的域。它由能將Locator的值解析到項目域的定位器解析方法來處理。ItemID字段是ItemID類型。
ItemPathReference(項目路徑引用)是定義Locator和Path(路徑)字段的ItemReference的特殊化。Locator字段標識一項目域。它由能將Locator的值解析到項目域的定位器解析方法來處理。Path字段包含以由Locator提供的項目域為根的存儲平臺名字空間中的(相對)路徑。
不能在集合運算中使用此類引用。引用一般必須通過路徑解析過程來解析。存儲平臺API 322的Resolve方法提供此功能。
上面討論的引用形式通過圖11示出的引用類型分層結(jié)構(gòu)表示。從這些類型繼承的另外引用類型能在模式中定義。它們能在關(guān)系聲明中用作目標字段的類型。
3.項目文件夾和類別如下面將更充分討論的，項目組能組織成稱為項目文件夾(不要與文件的文件夾混淆)的特殊項目。然而不象大多數(shù)文件系統(tǒng)，一個項目可屬于多個項目文件夾，使得當一個項目在一個項目文件夾中被訪問和修訂時，此修訂的項目隨后能直接從另一項目文件夾訪問。實質(zhì)上，雖然對一個項目的訪問可從不同的項目文件夾發(fā)生，事實上真正訪問的是同一個項目。然而，一個項目文件夾不必擁有其所有成員項目，或簡單地結(jié)合其它文件夾共同擁有項目，使得一個項目文件夾的刪除不必要導致項目的刪除。然而在本發(fā)明的若干實施例中，一個項目必須至少屬于一個項目文件夾，使得如果特定項目的唯一文件夾被刪除，則對某些實施例，該項目被自動被刪除，或在另外實施例中，該項目自動地成為默認項目文件夾的成員(“TrashCan(垃圾箱)”文件夾在概念上類似于在各種基于文件和文件夾的系統(tǒng)中使用的類似名字文件夾。)如下面更充分討論的，項目也可屬于基于共同描述的特征的類別，特征如(a)項目類型(或類型)，(b)特定的直接或繼承的屬性(或?qū)傩?，或(c)對應于項目屬性的特定值(或值)。例如，包括個人聯(lián)系人信息的特定屬性的項目可自動屬于聯(lián)系人(Contact)類別，具有聯(lián)系人信息屬性的任何項目看來也自動屬于此類別。同樣，具有“New York City(紐約市)”值的位置屬性的任何項目可自動屬于紐約市類別。
類別在概念上不同于項目文件夾之處在于，項目文件夾可包括互相無關(guān)的項目(即無共同的描述的特征)，而在類別中的每個項目具有對該類別描述的共同類型、屬性或值(“共同性”)，正是這個共同性形成對它與該類別中其它項目或那些項目之間的關(guān)系的基礎(chǔ)。此外，雖然在特定文件夾中的項目的成員資格基于該項目的任何特定方面不是強制的，然而對某些實施例，具有在分類上與一類別相關(guān)的共同性的所有項目在硬件/軟件接口系統(tǒng)級上可自動地成為該類別的成員。概念上，類別也能看作虛擬項目文件夾，其成員資格基于特定查詢(如在數(shù)據(jù)庫的上下文中)的結(jié)果，而滿足此查詢的條件(由類別的共同性確定)的項目應構(gòu)成該類別的成員資格。
圖4示出在項目、項目文件夾和類別之間的結(jié)構(gòu)關(guān)系。多個項目402、404、406、408、410、412、414、418和420是各個項目文件夾422、424、426、428和430的成員。某些項目屬于一個以上項目文件夾，如項目402屬于項目文件夾422和424。某些項目，如項目402、404、406、408、410和412也是一個或多個類別432、434和436的成員，而其它項目，如項目44，416，418和420可以不屬于任何類別(雖然這大部分不象在某些實施例中，其中具有任何屬性自動暗示類別中的成員資格，因此在那樣實施例中為了不是任何類別的成員，項目應完全地無特征)。與文件夾的分層結(jié)構(gòu)相反，類別和項目文件夾均有更像如所示的有向圖的結(jié)構(gòu)。在任何情況下，項目、項目文件夾和類別都是項目(盡管是不同的項目類型)。
與文件、文件夾和目錄相反，本發(fā)明的項目、項目文件夾和類別的特征在本質(zhì)上不是“物理的”，因為它們不具有物理容器的概念上的等價性，因而項目可存在于一個以上那樣的位置。項目存在于一個以上項目文件位置以及被組織成類別的能力提供了在硬件/軟件接口級上增強和豐富程度的數(shù)據(jù)處理及存儲結(jié)構(gòu)能力，超越了在本領(lǐng)域中當前可得到的能力。
4.模式a)基礎(chǔ)模式為了提供創(chuàng)建和使用項目的通用基礎(chǔ)，本發(fā)明的存儲平臺的各實施例包括建立用于創(chuàng)建和組織項目及屬性的概念性框架的基礎(chǔ)(Base)模式。基礎(chǔ)模式定義了某些特定類型的項目和屬性，以及從中進一步導出子類型的這些特定基本類型的特征。使用此基礎(chǔ)模式使程序員能在概念上將項目(及其各自的類型)與屬性(及其各自的類型)加以區(qū)別。此外，基礎(chǔ)模式列出所有項目可擁有的基本屬性集，因為所有項目(及其對應的項目類型)是從基礎(chǔ)模式的此基本項目(及其對應的項目類型)導出。
如圖7所示，對于本發(fā)明的若干實施例，基礎(chǔ)模式定義三個頂層類型Item(項目)、Extension(擴展)和PropertyBase(屬性基礎(chǔ))。如圖所示，通過此基本“Item”項目類型的屬性定義了項目類型。相反，頂層屬性類型“PropertyBase”沒有預定義的屬性，僅是一個錨位(anchor)，從中導出所有其它屬性，并通過它所有導出的屬性類型互相聯(lián)系(共同從單個屬性類型導出)。Extension類型屬性定義該擴展擴展了哪個項目，并定義將一個擴展與另一個項目相區(qū)別的標識，因為一個項目可具有多個擴展。
ItemFolder(項目文件夾)是Item項目類型的子類型，除了從Item繼承的屬性外，它表征用于建立到其成員(如果有的話)的關(guān)系，盡管Identitykey(身份關(guān)鍵字)和Property(屬性)均是PropertyBase的子類型。CategoryRef(目錄引用)進而是IdentityKey的子類型。
b)核心模式本發(fā)明的存儲平臺的各種實施例還包括為頂層項目類型結(jié)構(gòu)提供概念框架的核心(Core)模式。圖8A是示出核心模式中的項目的框圖，而圖8B是示出核心模式中屬性類型的框圖。在帶不同擴展名(*.com、*.exe、*.bat、*.sys等)的文件和在基于文件和文件夾系統(tǒng)中其它準則之間作出的區(qū)分是類似于核心模式的功能。在基于項目的硬件/軟件接口系統(tǒng)中，核心模式定義了一組核心項目類型，它們直接(按項目類型)或間接地(按項目子類型)將所有項目特征化成基于項目的硬件/軟件接口系統(tǒng)理解并能以預定或可預計的方式直接處理的一個或多個核心模式項目類型。預定的項目類型反映了在基于項目的硬件/軟件接口系統(tǒng)中最常用的項目，且因此通過理解這些包括核心模式的預定項目類型的基于項目的硬件/軟件接口系統(tǒng)獲取有效性級別。
在某些實施例中，核心模式是不可擴展的，即，沒有另外的類型可直接從基礎(chǔ)模式中的項目類型子分類，除非作為核心模式的一部分的特定的預定導出的項目類型。通過禁止對核心模式的擴展(即，通過禁止向核心模式添加新的項目)，存儲平臺托管核心模式項目類型的使用，因為每個后續(xù)的項目類型必須是核心模式項目類型的子類型。此結(jié)構(gòu)允許在保持具有一組預定的核心項目類型的益處的同時在定義另外項目類型時有合理程度的靈活性。
參考圖8A，對本發(fā)明的各種實施例，由核心模式支持的特定項目類型可包括下列的一個或多個·Category(類別)此項目類型(及從中導出的子類型)的項目代表在基于項目的硬件/軟件接口系統(tǒng)中的有效類別。
·Commodity(物品)作為值的可標識事物的項目。
·Device(設(shè)備)具有支持信息處理能力的邏輯結(jié)構(gòu)的項目。
·Document(文檔)具有不能由基于項目的硬件/軟件接口系統(tǒng)解釋而相反由對應于文檔類型的應用程序解釋的內(nèi)容的項目。
·Event(事件)記錄環(huán)境中某些發(fā)生事件的項目。
·Location(位置)代表物理位置(如地理位置)的項目。
·Message(消息)在兩個或更多主體(下面定義)之間通信的項目。
·Principal(主體)具有除ItemId之外的至少一個肯定可驗證身份(如，個人、組織、組、家庭、作者、服務等的標識)的項目。
·Statement(語句)具有關(guān)于環(huán)境的特定信息的項目，包括但不限于政策、預訂、憑證等。
類似地參考圖8B，由核心模式支持的特定屬性類型可包括下列的一個或多個·Certificate(證書)(從基礎(chǔ)模式中的基本PropertyBase類型導出)·PrincipalIdentityKey(主體身份關(guān)鍵字)(從基礎(chǔ)模式中的IdentityKey類型導出)·PostalAddress(郵政地址)(從基礎(chǔ)模式中Property類型導出)·RichText(多信息文本)(從基礎(chǔ)模式中Property類型導出)·EAddress(電子郵件地質(zhì))(從基礎(chǔ)模式中Property類型導出)·IdentitySecnrityPackage(身份安全包)(從基礎(chǔ)模式中Relationship類型導出)·RoleOccupancy(居民角色)(從基礎(chǔ)模式中Relationship類型導出)·BasicPresence(基礎(chǔ)存在)(從基礎(chǔ)模式中Relationship類型導出)這些項目和屬性按在圖8A和圖8B中列出的各自屬性進一步描述。
5.關(guān)系關(guān)系是二元關(guān)系，其中一個項目被指定為源，另一個被指定為目標。源項目和目標項目通過關(guān)系相聯(lián)系。源項目一般控制關(guān)系的生命周期。即，當源項目被刪除，項目之間的關(guān)系也被刪除。
關(guān)系被分類成包含(Containment)和引用(Reference)關(guān)系。包含關(guān)系控制目標項目的生命周期，而引用關(guān)系不提供任何生命周期管理語義。圖12示出關(guān)系分類的方式。
包含關(guān)系又被分類成持有(Holding)和嵌入(Embedding)關(guān)系。當對一個項目的所有持有關(guān)系被移除，該項目被刪除。持有關(guān)系通過引用計數(shù)機制控制目標。嵌入關(guān)系能夠?qū)秃享椖拷?，并能被看作排他的持有關(guān)系。一個項目能是一個或多個持有關(guān)系的目標；但一個項目只能是一個嵌入關(guān)系的目標。作為嵌入關(guān)系的目標的項目不能是任一其它持有或嵌入關(guān)系的目標。
引用關(guān)系不控制目標項目的生命周期。它們可以是搖擺不定的—目標項目可以不存在。引用關(guān)系能用于在全局項目名字空間的任何處(即，包括遠程數(shù)據(jù)存儲)建模對項目的引用。
獲得一項目不自動取得某關(guān)系，應用程序必須明確地請求項目的關(guān)系。此外，修改關(guān)系不修改源或目標項目；類似地，添加關(guān)系不影響源/目標項目。
a)關(guān)系聲明顯式的關(guān)系類型用下列元素定義；·在Name(名字)屬性中指定關(guān)系名
·下列之一的關(guān)系類型持有、嵌入、引用。這是在Type(類型)屬性中指定的。
·源和目標端點。每個端點指定所引用項目的名和類型。
·源端點字段一般是ItemID(項目ID)類型(未聲明)，而必須引用在與關(guān)系實例同一數(shù)據(jù)存儲中的項目。
·對持有和嵌入關(guān)系，目標端點字段必須是ItemIDReference(項目ID引用)類型，且它必須引用在與關(guān)系實例相同存儲中的項目。對引用關(guān)系，目標端點能是任何ItemReference(項目引用)類型，并能引用在其它存儲平臺數(shù)據(jù)存儲中的項目。
·能可任選地聲明標量或PropertyBase(屬性基礎(chǔ))類型的一個或多個字段。這些字段能包含與該關(guān)系相關(guān)聯(lián)的數(shù)據(jù)。
·關(guān)系實例被存儲在全局關(guān)系表中。
·每個關(guān)系實例唯一地由組合(源ItemID、關(guān)系ID)標識。對所有源自給定項目的關(guān)系，在給定的源ItemID中關(guān)系ID是唯一的，而不管它們的類型。
源項目是關(guān)系的擁有者。而被指定為擁有者的項目控制關(guān)系的生命周期，關(guān)系本身和與它們相關(guān)的項目分開。存儲平臺API 322提供用于展現(xiàn)與項目相關(guān)聯(lián)的關(guān)系的機制。
這里是一個關(guān)系聲明的例子。
<Relationship Name＝″Employment″BaseType＝″Reference″>
<Source Name＝″Employee″ItemType＝″Contact.Person″/>
<Target Name＝″Employer″ItemType＝″Contact.Organization″ReferenceType＝″ItemIDReference″/>
<Property Name＝″StartDate″Type＝″the storageplatformTypes.DateTime″/>
<Property Name＝″EndDate″Type＝″the storageplatformTypes.DateTime″/>
<Property Name＝″Office″Type＝″the storageplatformTypes.DateTime″/>
</Relationship>
這是引用關(guān)系的例子。若由源引用所引用的個人項目不存在，則不能創(chuàng)建該關(guān)系。而且若該個人項目被刪除，在個人和組織之間的關(guān)系實例也被刪除。然而若組織項目被刪除，關(guān)系不被刪除，而它是搖擺不定的。
b)持有關(guān)系持有關(guān)系用于基于目標項目的生命周期管理來對引用計數(shù)建模。
一個項目可以是用于對項目的零個或多個關(guān)系的源端點。不是嵌入項目的項目可以是在一個或多個持有關(guān)系中的目標項目。
目標端點引用類型必須是ItemIDReference，且它必須引用在與關(guān)系實例相同的存儲中的項目。
持有關(guān)系實施目標端點的生命周期管理。持有關(guān)系實例和作為目標的項目的創(chuàng)建是原子操作?？梢詣?chuàng)建將同一項目作為目標的另外的持有關(guān)系實例。當具有給定項目作為目標端點的最后一個持有關(guān)系實例被刪除時，該目標項目也被刪除。
在關(guān)系聲明中指定的端點項目的類型一般在創(chuàng)建該關(guān)系的實例時強制。在關(guān)系建立之后端點項目的類型不能改變。
持有關(guān)系在形成項目的名字空間中起著關(guān)鍵作用。它們包含“Name(名字)”屬性，它定義目標項目相對于源項目的名字。對所有源自給定項目的持有關(guān)系，相對名字是唯一的。從根項目開始到給定項目的相對名字的有序類表形成該項目的全名。
持有關(guān)系形成—有向非循環(huán)圖(DAG)。在創(chuàng)建持有關(guān)系時，系統(tǒng)確保不產(chǎn)生回路，從而確保項目的名字空間形成DAG。
雖然持有關(guān)系控制目標項目的生命周期，它不控制目標端點項目的操作的一致性。目標項目在操作上獨立于通過持有關(guān)系擁有它的項目。在作為持有關(guān)系的源的項目上的拷貝、移動、備份和其它操作不影響作為同一關(guān)系的目標的項目—例如，備份文件夾項目不自動地備份該文件夾中所有項目(FolderMember(文件夾成員)關(guān)系中的目標)。
下面是持有關(guān)系的例子<Relationship Name＝″FolderMembers″BaseType＝″Holding″>
<Source Name＝″Folder″ItemType＝″Base.Folder″/>
<Target Name＝″Item″ItemType＝″Base.Item″ReferenceType＝″ItemIDReference″/>
</Relationship>
FolderMember關(guān)系使文件夾的概念成為項目的類屬集合。
c)嵌入關(guān)系嵌入關(guān)系將目標項目的生命周期的排外控制的概念模型化。它們允許合成項目的概念。
嵌入關(guān)系實例和作為目標的項目的創(chuàng)建是原子操作。一個項目能是零個或多個嵌入關(guān)系的源。然而一個項目能是一個且僅是一個嵌入關(guān)系的目標。作為嵌入關(guān)系的目標的項目不能是持有關(guān)系的目標。
目標端點引用類型必須是ItemIDReference，且它必須引用在與關(guān)系實例相同數(shù)據(jù)存儲中的項目。
在關(guān)系聲明中指定的端點項目的類型一般在創(chuàng)建該關(guān)系的實例時強制。在關(guān)系建立之后端點的類型不能改變。
嵌入關(guān)系控制該目標端點的操作一致性。例如，串行化項目的操作可包括串行化所有源自該項目及所有其目標的所有嵌入關(guān)系；拷貝一項目也拷貝所有它的嵌入項目。
下面是示例聲明<Relationship Name＝″ArchiveMembers″BaseType＝″Embedding″>
<Source Name＝″Archive″ItemType＝″Zip.Archive″/>
<Target Name＝″Member″ItemType＝″Base.Item″ReferenceType＝″ItemIDReference″/>
<Property Name＝″ZipSize″Type＝″the storageplatformTypes.bigint″/>
<Property Name＝″SizeReduction″Type＝″the storageplafformTypes.float″/>
</Relationship>
d)引用關(guān)系引用關(guān)系不控制它引用的項目的生命周期。尤其是，引用關(guān)系不保證目標的存在，也不保證目標的類型如關(guān)系聲明中指定的那樣。這意味著引用關(guān)系能是搖擺不定的。而且引用關(guān)系能引用在其它數(shù)據(jù)存儲中的項目。引用關(guān)系能看作類似于網(wǎng)頁上的鏈接的概念。
下面是引用關(guān)系說明的例子<Relationship Name＝″DocumentAuthor″BaseType＝″Reference″>
<Sourc ItemType＝″Document″ItemType＝″Base.Document″/>
<Target ItemType＝″Author″ItemType＝″Base.Author″ReferenceType＝″ItemIDReference″/>
<Property Type＝″Role″Type＝″Core.CategoryRef″/>
<Property Type＝″DisplayName″Type＝″the storageplatformTypes.nvarchar(256)″/>
</Relationship>
在目標的端點允許任何引用類型。參與引用關(guān)系的項目可以是任何項目類型。
引用關(guān)系用于對項目之間的大多數(shù)非生命周期管理關(guān)系建模。因為不強制目標的存在，引用關(guān)系便于對松散耦合的關(guān)系建模。引用關(guān)系能用于在其它存儲，包括在其它計算機上的存儲中的目標項目。
e)規(guī)則和約束下列附加規(guī)則和約束應用于關(guān)系·一個項目必須是(僅一個嵌入關(guān)系)或(一個或多個持有關(guān)系)的目標。一個例外是根項目。一個項目能是零個或多個引用關(guān)系的目標。
·作為嵌入關(guān)系目標的項目不能是持有關(guān)系的源。它能是引用關(guān)系的源。
·一個項目若是從文件升級，則不能是持有關(guān)系的源。它能是嵌入關(guān)系和引用關(guān)系的源。
·一個從文件升級的項目不能是嵌入關(guān)系的目標。
f)關(guān)系的排序在一至少個實施例中，本發(fā)明的存儲平臺支持關(guān)系的排序。通過在基本關(guān)系定義中名為“Order(排序)”的屬性完成排序。在Order字段中無唯一性約束。不保證帶有同一“Order”屬性值的關(guān)系的次序，然而保證，它們能排序在帶較低“Order”值的關(guān)系之后并在帶較高“Order”字段值的關(guān)系之前。
應用程序通過在在組合(SourceItem ID，RelationshipID，Order)上排序得到默認次序的關(guān)系。源自給定項目的所有關(guān)系實例被排序成單個集合，而不管在集合中關(guān)系的類型。然而這保證，給定類型(如，F(xiàn)olderMembers(文件夾成員))的所有關(guān)系是給定項目的關(guān)系集合的已排序子集。
用于處理關(guān)系的數(shù)據(jù)存儲API 312實現(xiàn)一組支持關(guān)系的排序的操作。引入下列術(shù)語幫助解釋那些操作·RelFirst是有序集合中帶次序值OrdFirst的第一個關(guān)系；·RelLast是有序集合帶次序值OrdLast的最后一個關(guān)系；·RelX是集合中帶次序值OrdX的給定關(guān)系；
·RelPrev是集合中最接近于RelX的帶小于OrdX的次序值OrdPrev的關(guān)系；以及·RelNext是集合中最接近于RelX的帶大于OrdX的次序值OrdNext的關(guān)系。
操作包括但不限于·InsertBeforeFirst(SourceItemID，Relationship)插入關(guān)系作為集合中的第一個關(guān)系。新關(guān)系的“Order”屬性的值可小于OrdFirst。
·InsertAfterLast(SourceItemID，Relationship)插入關(guān)系作為集合中的最后一個關(guān)系。新關(guān)系的“Order”屬性的值可大于OrdLast。
·InsertAt(SourceItemID，ord，Relationship)插入帶有對“Order”屬性指定的值的關(guān)系。
·InsertBefore(SourceItemID，ord，Relationship)在帶有給定次序值的關(guān)系之前插入該關(guān)系。新的關(guān)系可被分配“Order”值，它在OrdPrev和ord之間，但不包括這兩個值。
·InsertAfter(SourceItemID，ord，Relationship)在帶有給定次序值的關(guān)系之后插入該關(guān)系。新的關(guān)系可被分配“Order”值，它在ord和OrdNext之間，但不包括這兩個值。
·MoveBefore(SourceItemID，ord，Relationship)將帶給定關(guān)系ID的關(guān)系移動到帶指定“Order”值的關(guān)系之前。關(guān)系可被分配新的“Order”值，它在OrdPrev和ord之間，但不包括這兩個值。
·MoveAfter(SourceItemID，ord，Relationship)將帶給定關(guān)系ID的關(guān)系移動到帶指定“Order”值的關(guān)系之后。該關(guān)系可被分配新的次序值，它在ord和OrdNext之間，但不包括這兩個值。
如前提到，每個項目必須是項目文件夾的成員。按照關(guān)系，每個項目必須與一項目文件夾有一關(guān)系。在本發(fā)明的若干實施例中，某些關(guān)系由在諸項目之間存在的關(guān)系表示。
如對本發(fā)明的各實施例的實現(xiàn)，關(guān)系提供一有向的二元關(guān)系，它由一個項目(源)延伸到另一項目(目標)。關(guān)系由源項目(延伸它的項目)擁有，因此若源被移除則關(guān)系被移除(如在源項目被刪除時關(guān)系被刪除)。此外在某些情況下，關(guān)系可共享(共同擁有的)目標項目的擁有權(quán)，且那樣的擁有權(quán)僅可反映在關(guān)系的IsOwned(被擁有)屬性(或其等效屬性)中(如圖7對關(guān)系屬性類型所示)。在這些實施例中，創(chuàng)建一新的IsOwned關(guān)系自動遞增該目標上的引用計數(shù)，而刪除那樣的關(guān)系可遞減該目標項目上的引用計數(shù)。對這些特定實施例，若項目具有大于0的引用計數(shù)，則繼續(xù)存在，若項目計數(shù)達到0則自動刪除。再一次，項目文件夾是具有(或能具有)與其它項目的一組關(guān)系的項目，這些其它項目包括項目文件夾的成員資格。關(guān)系的其它實際實現(xiàn)是可能的，并由本發(fā)明構(gòu)想來實現(xiàn)這里描述的功能。
不管實際的實現(xiàn)如何，關(guān)系是從一個對象到另一對象的可選擇的連接。一個項目屬于一個以上項目文件夾以及一個或多個類別，而不論這些項目、文件夾和類別是公有的或私有的能力是由給予基于項目的結(jié)構(gòu)中的存在(或缺乏)的意義所確定的。這些邏輯關(guān)系是分配給一組關(guān)系的意義，而不論其專門用來實現(xiàn)這里所述功能的物理實現(xiàn)如何。邏輯關(guān)系是在項目及其文件夾或類別之間建立的(或相反)，因為本質(zhì)上項目文件夾和類別的每一個都是特定類型的項目。因此，能象其它項目一樣地對項目文件夾和類別起作用(拷貝、添加到電子郵件消息中、嵌入文檔等等，而無限制)，而項目文件夾和類別能象其它項目一樣使用相同的機制串行化和解串行化(導入和導出)。(例如在XML中，所有項目可具有串行化的格式，且此格同等地應用于項目文件夾、類別和項目)。
代表項目及其項目文件夾之間的關(guān)系的上述關(guān)系在邏輯上能從項目延伸到項目文件夾、從項目文件夾延伸到項目、或兩者。邏輯上從一項目延伸到項目文件夾的關(guān)系表明該項目文件夾對于該項目是公有的，并與該項目共享其成員資格信息；相反，缺乏從項目到項目文件夾的邏輯關(guān)系表明該項目文件夾對該項目是私有的，且不與該項目共享其成員資格信息。類似地，邏輯上從項目文件夾延伸到項目的關(guān)系表明該項目是公有的，并可與該項目文件夾共享，而缺乏從項目文件夾延伸到項目的邏輯關(guān)系表明該項目是私有的且不能共享。因此，當向其它系統(tǒng)導出項目文件夾時，它是“公有”的項目，它在新的環(huán)境中共享，且當項目搜索其項目文件夾尋找其它可共享的項目時，它是“公有”的項目文件夾，它向該項目提供關(guān)于屬于它的可共享項目的信息。
圖9是示出項目文件夾(它本身也是項目)、其成員項目、和項目文件夾及其成員項目之間互聯(lián)關(guān)系的框圖。項目文件夾900具有多個項目902、904和906作為其成員。項目文件夾900具有從它本身到項目902的關(guān)系912，它表明項目902是公有的，且能與項目文件夾900、其成員904和906、和任何可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享。然而從項目902到項目文件夾項目900沒有關(guān)系，這表明項目文件夾900對項目902是私有的，且不與項目902共享其成員資格信息。另一方面，項目904確實具有從它本身到項目文件夾900的關(guān)系924，這表明項目文件夾900是公有的，且與項目904共享其成員資格信息。然而沒有從項目文件夾900到項目904的關(guān)系，這表明項目904是私有的，且不與項目文件夾900、其另外的成員902、906、及可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享。與其到項目902和904的關(guān)系(或沒有這些關(guān)系)相反，項目文件夾900具有從其本身到項目906的關(guān)系916，且項目906具有回到項目文件夾900的關(guān)系926，一起表明項目906是公有的，且能對文件夾900、其成員902和904、和可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享，且項目文件夾900是公有的，并與項目906共享其成員資格信息。
如前討論，在項目文件夾中的項目不需要共享共同性，因為項目文件夾未被“描述”。另一方面，類別由對所有其成員項目共同的共同性描述。因此，類別的成員資格固有地限于具有所描述的共同性的項目，且在某些實施例中，滿足類別的描述的所有項目自動地成為該類別的成員。因此，盡管項目文件夾允許由其成員資格來表示不重要的類型結(jié)構(gòu)，類別基于定義的共同性來允許成員資格。
當然，類別描述本質(zhì)上是邏輯的，因而類別可通過類型、屬性和/或值的任何邏輯表示來描述。例如，對一類別的邏輯表示可以是其成員資格，以包括具有兩個屬性之一或兩者的項目。若這些對類別描述的屬性是“A”和“B”，則該類別的成員資格可包括具有屬性A而沒有B的項目、具有屬性B而沒有A的項目、及兼有屬性A和B的項目。通過邏輯運算符“OR(或)”來描述屬性的邏輯表示，其中由類別描述成員組是具有屬性A OR B的項目。如本領(lǐng)域的技術(shù)人員所理解的，也能使用類似的邏輯運算符(包括但不限于單獨的“AND(和)”“XOR(異或)”和“NOT(非)”或其組合)來描述類別。
盡管在項目文件夾(未描述)和類別(已描述)之間有區(qū)別，但在本發(fā)明的許多實施例中，原則上到項目的類別關(guān)系及到類別的項目關(guān)系以上面對項目文件夾和項目的同樣方法揭示。
圖10是示出一類別(其本身也是項目)、其成員項目、類別及其成員項目之間的互聯(lián)關(guān)系的框圖。類別1000具有多個項目1002、1004和1006作為成員，所有這些都共享由類別1000描述的共同的屬性、值和類型1008(共同性描述1008’)的某個組合。類別1000具有從其本身到項目1002的關(guān)系，它表明項目1002是公有的，且能與類別1000、其成員1004和1006、以及可訪問類別1000的任何其它類別、項目文件夾、或項目(未示出)共享。然而，沒有從項目1002到類別1000的關(guān)系，這表明類別1000對項目1002是私有的，且不與項目1002共享成員資格信息。另一方面，項目1004的確具有從其本身到類別1000的關(guān)系1024，這表明類別1000是公有的，且與項目1004共享其成員資格信息。然而，不存在從類別1000延伸到項目1004的關(guān)系，這表明項目1004是私有的，且不能與類別1000、它的其它成員1002和1006、以及可訪問類別1000的任何其它類別、項目文件夾、或項目(未示出)共享。與它與項目1002和1004的關(guān)系(或沒有此關(guān)系)相反，類別1000具有從其本身到項目1006的關(guān)系1016，且項目1006具有回到類別1000的關(guān)系1026，這一起表明項目1006是公有的，且能與類別1000、其項目成員1002和1004、以及可訪問類別1000的任何其它類別、項目文件夾、或項目(未示出)共享，且類別1000是公有的，且與項目1006共享其成員資格信息。
最后，由于類別和項目文件夾本身是項目，且項目可以互相關(guān)系，類別可關(guān)系到項目文件夾，反之亦然，且在某些另外實施例中，類別、項目文件夾和項目可分別關(guān)系到其它類別、項目文件夾和項目。然而在各種實施例中，項目文件夾結(jié)構(gòu)和/或類別結(jié)構(gòu)在硬件/軟件接口系統(tǒng)級上禁止包含回路。當項目文件夾和類別結(jié)構(gòu)類似于有向圖時，禁止回路的實施例類似于有向非循環(huán)圖(DAG)，根據(jù)圖論領(lǐng)域的數(shù)學定義，DAG是其中沒有路徑在同一頂點開始與終止的有向圖。
6.可擴展性如上所述，本存儲平臺旨在提供初始模式組340。然而，至少在某些實施例中，該存儲平臺還允許包括獨立軟件分銷商(ISV)等顧客創(chuàng)建新的模式344(即新的項目和嵌套的元素類型)。本節(jié)討論通過擴展在初始模式組340中定義的項目類型和嵌套的元素類型(或簡稱“元素”類型)著眼于創(chuàng)建該模式的機制。
較佳地，項目和嵌套元素類型的初始組的擴展如下約束·允許ISV引入新的項目類型，即子類型Base.Item；·允許ISV引入新的嵌套元素類型，即子類型Base.NestedElement；·允許ISV引入新的擴展，即子類型Base.NestedElement；但·ISV不能子分類由存儲平臺的初始模式組340定義的任何類型(項目、嵌入元素、或擴展類型)。
由于由存儲平臺的初始模式組定義的項目類型或嵌入元素類型可能不精確地匹配ISV應用程序的需要，必須允許ISV定制該類型。這就考慮了擴展的概念。擴展是強類型的實例，但是(a)它們不能獨立存在，以及(b)它們必須附屬于項目或嵌套元素。
除了解決對模式可擴展性的需要之外，擴展還旨在解決“多分類”問題。在某些實施例中，因為存儲平臺可能不支持多繼承性或重疊子類型，應用程序可以使用擴展作為模型化重疊類型實例(如文檔既是合法文檔又是安全文檔)的方法。
a)項目擴展為提供項目的可擴展性，數(shù)據(jù)模型還定義名為Base.Extension的抽象類型。這是擴展類型的分層結(jié)構(gòu)的根類型。應用程序可以子分類Base.Extension，以創(chuàng)建特定的擴展類型。
在基礎(chǔ)模式中如下定義Base.Extension類型<Type Name＝″Base.Extension″IsAbstract＝″True″>
<Propety Name＝″ItemI D″Type＝″the storage platformTypes.uniqueidentified″Nullable＝″false″MultiValued＝″false″/>
<Property Name＝″ExtensionID″Type＝″the storage platformTypes.uniqueidentified″Nullable＝″false″MultiValued＝″false″/>
</Type>
ItemID字段包含與該擴展關(guān)聯(lián)的項目的ItemID。帶此ItemID的項目必須存在。若帶給定ItemID的項目不存在，則不能創(chuàng)建擴展。當項目被刪除，帶同一ItemID的所有擴展被刪除。二元組(ItemID，ExtensionID)唯一地標識了擴展實例。
擴展類型的結(jié)構(gòu)類似于項目類型的結(jié)構(gòu)·擴展類型具有字段；·字段可以是原語或嵌套元素類型；以及·擴展類型可被子分類。
下列限制應用于擴展類型·擴展不能是關(guān)系的源和目標；·擴展類型實例不能獨立于項目存在；以及·擴展類型不能用作在存儲平臺類型定義中的字段類型對能與給定的項目類型關(guān)聯(lián)的擴展的類型沒有約束。任何擴展類型允許擴展任何項目類型。當多個擴展實例被附加到一個項目，它們在結(jié)構(gòu)和行為上彼此獨立。
擴展實例被分別存儲并從項目訪問。所有擴展類型實例可從全局擴展視圖訪問。能組成一有效的查詢，它將返回給定類型的擴展的所有實例，而不管它們關(guān)聯(lián)什么類型的項目。存儲平臺API提供可存儲、檢索和修改項目擴展的編程模型。
擴展類型可是使用存儲平臺的單個繼承模型來子分類的類型。從一個擴展類型導出創(chuàng)建新的擴展類型。一個擴展的結(jié)構(gòu)或行為不能覆蓋或替代項目類型分層結(jié)構(gòu)的結(jié)構(gòu)或行為。類似于項目類型，擴展類型實例能通過與該擴展類型關(guān)聯(lián)的視圖直接訪問。擴展的ItemID表明，它們屬于哪個項目，并能用于從全局項目視圖檢索對應的項目對象。為操作一致性的目的，擴展被考慮成項目的一部分?？截?移動、備份/恢復和存儲平臺定義的其它常用操作可以在作為項目的一部分的擴展上操作。
考慮下述例子。在Windows類型組中定義Contact(聯(lián)系人)類型。
<Type Name＝″Contact″BaseType＝″Base.Item″>
<Property Name＝″Name″Type＝″String″Nullable＝″false″MultiValued＝″false″/>
<Property Name＝″Address″Type＝″Address″Nullable＝″true″MultiValued＝″false″/>
</Type>
CRM(客戶關(guān)系管理)應用程序開發(fā)者喜歡將CRM應用程序擴展附加到存儲在存儲平臺中的聯(lián)系人。應用程序開發(fā)者定義包含應用程序能處理的附加數(shù)據(jù)結(jié)構(gòu)的CRM擴展。
<Type Name＝″CRMExtension″BaseType＝″Base.Extension″>
<Property Name＝″CustomerID″Type＝″String″Nullable＝″false″MultiValued＝″false″/>
...
</Type>
HR應用程序開發(fā)者希望也將附加數(shù)據(jù)附加到聯(lián)系人。此數(shù)據(jù)獨立于CRM應用程序數(shù)據(jù)。應用程序開發(fā)者還可創(chuàng)建—擴展
<Type Name＝″HRExtension″EBaseType＝″Base.Extension″>
<Property Name＝″EmployeeID″Type＝″String″Nullable＝″false″MultiValued＝″false″/>
...
</Type>
CRMExtension和HRExtension是能附加到聯(lián)系人項目的兩個獨立擴展。它們能彼此獨立地創(chuàng)建和訪問。
在上述例子中，CRMExtension類型的字段和方法不能覆蓋聯(lián)系人分層結(jié)構(gòu)的字段和方法。應注意，CRMExtension類型的實例能被附加到不同于聯(lián)系人的項目類型。
在檢索聯(lián)系人項目時，不自動地檢索它的項目擴展。給定聯(lián)系人項目，可通過查詢?nèi)謹U展視圖以尋找?guī)籌temID的擴展來訪問其有關(guān)的項目擴展。
可通過CRMExtension類型視圖來訪問系統(tǒng)中所有的CRMExtension擴展，而不論它們屬于什么項目。一個項目的所有項目擴展共享同一項目id。在上述例子中，聯(lián)系人項目實例和附加的CRMExtension和HRExtension實例共享同一ItemID。
下面的表總結(jié)了在Item(項目)、Extension(擴展)和NestedElement(嵌套元素)類型之間的相似性和差別Item、ItemExtension與NestedElement


b)擴展NestedElement類型嵌套元素類型不用與項目類型相同的機制擴展。嵌套元素的擴展用與嵌套元素類型字段相同的機制存儲和訪問。
數(shù)據(jù)模型定義了名為Element(元素)的嵌套元素類型的根。
<Type Name＝″Element″IsAbstract＝″True″>
<Property Name＝″ElementI D″Type＝″the storage platformTypes.uniqueidentifier″Nullable＝″false″MultiValued＝″false″/>
</Type>
NestedElement類型從此類型繼承。NestedElement元素類型另外定義—字段，它是多組元素。
<Type Name＝″NestedElement″BaseType＝″Base.Element″IsAbstract＝″True″>
<Property Name＝″Extensions″Type＝″Base.Element″Nullable＝″false″MultiValued＝″true″/>
</Type>
NestedElement擴展在下面方面不同于項目擴展·嵌套元素擴展不是擴展類型。它們不屬于以Base.Extension類型為根的擴展類型分層結(jié)構(gòu)。
·嵌套元素擴展與該項目的其它字段一起存儲，且不是全局可訪問的—不能組成檢索給定擴展類型的所有實例的查詢。
·象存儲其它嵌套元素(或項目)一樣地存儲這些擴展。象其它的嵌套組，NestedElement擴展被存在UDT中。它們可通過嵌套元素類型的Extension(擴展)字段來訪問。
·用于訪問多值屬性的集合接口也用于在類型擴展組上的訪問和迭代。下面的表總結(jié)和比較Item擴展和NestedElement擴展。
Item擴展與NestedElement擴展

D.數(shù)據(jù)庫引擎如上提到，數(shù)據(jù)存儲在數(shù)據(jù)庫引擎上實現(xiàn)。在本實施例中，數(shù)據(jù)庫引擎包括諸如Microsoft SQL Server引擎等實現(xiàn)SQL查詢語言、帶有對象關(guān)系擴展的關(guān)系數(shù)據(jù)庫引擎。本節(jié)按照本實施例，描述數(shù)據(jù)存儲實現(xiàn)的數(shù)據(jù)模型到關(guān)系存儲的映射，在邏輯API上提供由存儲平臺的客戶機使用的信息。然而可以理解，當采用不同的數(shù)據(jù)庫引擎時可采用不同的映射。確實，除了在關(guān)系型數(shù)據(jù)庫引擎上實現(xiàn)存儲平臺概念數(shù)據(jù)模型之外，也可在其它類型數(shù)據(jù)庫上實現(xiàn)，如面向?qū)ο蠛蚗ML數(shù)據(jù)庫。
面向?qū)ο?OO)數(shù)據(jù)庫系統(tǒng)為編程語言對象(如C++、Java)提供持續(xù)性和事務?！绊椖俊钡拇鎯ζ脚_概念可很好地映射到面向?qū)ο笙到y(tǒng)中的對象，雖然嵌入的集合必須添加給對象。類似繼承性和嵌套元素類型等其它存儲平臺類型概念也映射到面向?qū)ο箢愋偷南到y(tǒng)。面向?qū)ο笙到y(tǒng)通常已經(jīng)支持對象身份；因此，項目身份可被映射到對象身份。項目的行為(操作)很好地映射到對象方法。然而，面向?qū)ο蟮南到y(tǒng)通常缺乏組織能力并在搜索方面很差。而且，面向?qū)ο蟮南到y(tǒng)不提供對非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的支持。為支持這里描述的完全存儲平臺數(shù)據(jù)模型，象關(guān)系、文件夾和擴展等概念需要添加到對象數(shù)據(jù)模型。此外，需要實現(xiàn)如升級、同步、通知和安全性等機制。
類似于面向?qū)ο蟮南到y(tǒng)，基于XSD(XML模式定義)的XML數(shù)據(jù)庫支持基于單繼承類型的系統(tǒng)。本發(fā)明的項目類型系統(tǒng)可映射到XSD類型模型。XSD也不提供對行為的支持。項目的XSD必須增添項目的行為。XML數(shù)據(jù)庫處理單個XSD文檔并缺乏組織和拓寬搜索能力。如面向?qū)ο髷?shù)據(jù)庫那樣，為支持這里描述的數(shù)據(jù)模型，如關(guān)系和文件夾等其它概念需要被結(jié)合到該XML數(shù)據(jù)庫；而且需要實現(xiàn)如同步、通知和安全性等機制。
關(guān)于下面小節(jié)，提供少量圖示以便于一般的信息揭示圖13是示出通知機制的圖示。圖14是示出兩個事務均將新記錄插入同一B樹的例子的圖示。圖15示出數(shù)據(jù)改變檢測過程。圖16示出示例性目錄樹。圖17示出其中基于目錄的文件系統(tǒng)的現(xiàn)有文件夾被移動到存儲平臺數(shù)據(jù)存儲中。
1.使用UDT的數(shù)據(jù)存儲實現(xiàn)在本實施例中，在一個實施例中包括Microsoft SQL Server引擎的關(guān)系型數(shù)據(jù)庫引擎314支持內(nèi)建的標量類型。內(nèi)建的標量類型是“原生(native)”且“簡單”的。它們是原生的意義是，用戶不能定義他們自己的類型；它們是簡單的意義是，用戶不能封裝復雜的結(jié)構(gòu)。用戶定義的類型(下文稱為UDT)通過使用戶能通過定義復雜的結(jié)構(gòu)化類型來擴展類型系統(tǒng)，提供了一種用于超過或超越原生的標量類型系統(tǒng)的類型可擴展性的機制。一旦由用戶定義，UDT能用于可以使用內(nèi)建標量類型的類型系統(tǒng)中的任何地方。
按本發(fā)明的一個方面，存儲平臺模式被映射到數(shù)據(jù)庫引擎存儲中的UDT類。數(shù)據(jù)存儲項目被映射到從Base.Item類型導出的UDT類。類似于項目，擴展也能映射到UDT類并使用繼承。根擴展類型是Base.Extension，從它導出所有擴展類型。
UDT是CLR類，它具有狀態(tài)(即數(shù)據(jù)字段)和行為(即例程)。使用任何受管語言(c#、VB.NET等)定義UDT。UDT方法和操作符能在T-SQL中針對該類型的實例調(diào)用。UDT能是行中列的類型、T-SQL中例程的參數(shù)的類型、或在T-SQL中變量的類型。
存儲平臺模式到UDT類的映射在高級別上完全是直接的。一般而言，存儲平臺模式被映射到CLR名字空間。存儲平臺類型被映射到CLR類。CLR類的繼承鏡象了存儲平臺類型的繼承，且存儲平臺屬性被映射到CLR類屬性。
2.項目映射為了希望項目能夠被全局地搜索，并在本實施例的關(guān)系型數(shù)據(jù)中支持繼承以及類型可替代性，對在數(shù)據(jù)庫存儲中的項目存儲的一種可能的實現(xiàn)是在帶有類型Base.Item的列的單個表中存儲所有項目。使用類型可替代性，能存儲所有類型的項目，且可按使用Yukon的“is of(類型)”的操作符的項目類型的子類型來過濾搜索。
然而，由于在本實施例中牽涉到與這一方法相關(guān)聯(lián)的額外開銷，由頂級類型將各項目劃分，使得每個類型“家族”的項目存儲到單獨的表中。在此劃分模式中，對每個直接從Base.Item繼承的項目類型創(chuàng)建一個表。如上所述，繼承下面這些的類型使用類型的可替代性存儲在合適的類型家族表中。只有從Base.Item的第一級繼承被專門地處理。
使用一“陰影”表存儲所有項目的全局可搜索屬性的副本。此表可由存儲平臺API的Update()方法維護，通過此方法作出所有數(shù)據(jù)的改變。不象類型家族表，此全局項目表只包含該項目的頂級標量屬性，而不是全UDT項目對象。全局項目表允許通過展現(xiàn)ItemID和TypeID(類型ID)導航到存儲在類型家族表中的項目對象。ItemID通常唯一地標識數(shù)據(jù)存儲中的項目。可使用這里未予描述的元數(shù)據(jù)將TypeID映射到類型名和包含該項目的視圖。由于通過其ItemID尋找項目在全局項目表的上下文及其它情況下都是常用操作，因此給定了項目的ItemId，提供GetItem()函數(shù)來檢索項目對象。
為便于訪問和盡可能地隱藏實現(xiàn)的細節(jié)，項目的所有查詢可以對照在上述項目的表上構(gòu)建的視圖進行。具體說來，對每個項目類型針對合適類型的家族表創(chuàng)建視圖。這些類型視圖可選擇相關(guān)聯(lián)的類型，包括子類型的所有項目。為方便起見，除了UDT對象，視圖能對包括繼承字段的該類型的所有頂級域展現(xiàn)列。
3.擴展映射擴展非常類似于項目，且具有某些相同要求。如支持繼承性的另一根類型，擴展受到存儲中許多同樣的考慮和折衷比較。為此，對擴展應用類似的類型家族映射，而不是單個表方法。當然，在其它實施例中，可使用單個表方法。在本實施例中，擴展通過ItemID僅與一個項目關(guān)聯(lián)，并包含在項目的上下文中唯一的ExtensionID。如同項目一樣，給定包括ItemID和ExtensionID對的身份，可提供一函數(shù)用于檢索擴展。類似于項目類型視圖，對每個擴展類型可創(chuàng)建視圖。
4.嵌套元素映射嵌套元素是可嵌入到項目、擴展、關(guān)系、或其它嵌套元素以形成深嵌套結(jié)構(gòu)的類型。類似于項目和擴展，嵌套元素作為UDT實現(xiàn)，但它們存儲在項目和擴展中。因此，嵌套元素沒有超越它們的項目和擴展容器的映射的存儲映射。換言之，在系統(tǒng)中沒有直接存儲NestedElement類型的實例的表，且沒有專門用于嵌套元素的視圖。
5.對象身份在數(shù)據(jù)模型中的每一實體，即每個項目、擴展和關(guān)系具有唯一的關(guān)鍵字值。一個項目由其ItemId唯一地標識。擴展由合成關(guān)鍵字(ItemId，ExtensionId)唯一地標識。關(guān)系由合成關(guān)鍵字(ItemId，RelationId)標識。ItemId，ExtensionId和RelationshipId均是GUID值。
6.SQL對象命名在數(shù)據(jù)存儲中創(chuàng)建的所有對象可存儲在從存儲平臺模式名字導出的SQL模式名字中。例如，存儲平臺基礎(chǔ)模式(常稱“基礎(chǔ)”)可產(chǎn)生在“[System.Storage]”SQL模式中的類型，如“[System.Storage].Item”。產(chǎn)生的名字可用限定詞加前綴以消除命名的沖突。在合適處可使用驚嘆號(！)作為名字的每個邏輯部分的分割符。下面表概括了在數(shù)據(jù)存儲用于對象的命名習慣。與用于訪問數(shù)據(jù)存儲中的實例的修飾的命名習慣一起列出每個模式元素(項目、擴展、關(guān)系和視圖)。

7.列命名當映射任一對象模型到存儲時，由于與應用程序?qū)ο笠黄鸫鎯Φ母郊有畔?，有可能發(fā)生命名沖突。為避免命名沖突，所有非類型的特定列(不直接映射到類型聲明中的命名的屬性的列)用下劃線字符(_)加前綴。在本實施例中，下劃線字符(_)不允許作為任何標識符屬性的開始字符。此外，為統(tǒng)一在CLR和數(shù)據(jù)存儲之間的命名，存儲平臺類型或模式元素的所有屬性(關(guān)系等)應具有大寫的第一字符。
8.搜索視圖由存儲平臺提供視圖，用于搜索存儲的內(nèi)容。對每個項目和擴展類型提供SQL視圖。此外，提供視圖以支持關(guān)系和視圖(由數(shù)據(jù)模型定義)。所有SQL視圖和在存儲平臺中的底層表是只讀的。下面將更充分描述，使用存儲平臺API的Update()方法可存儲或改變數(shù)據(jù)。
在存儲平臺模式中直接定義的每個視圖(由模式設(shè)計者定義，而非由存儲平臺自動地生成)可由命名的SQL視圖[<schema-name>].[View！<view-name>]訪問。例如，在模式“AcmePublisher.Books”中名為“BookSales”的視圖可使用名字“[AcmePublisher.Books].[View！BookSales]來訪問。因為視圖的輸出格式在每一視圖的基礎(chǔ)上是自定義的(由定義視圖的那一方提供的任意查詢確定的)，列基于模式視圖定義被直接映射。
存儲平臺數(shù)據(jù)存儲中的所有SQL搜索視圖使用列的下述排序習慣·如ItemId、ElementId、RelationshipId等的視圖結(jié)果的邏輯“關(guān)鍵字”列·如TypeId等關(guān)于結(jié)果類型的元數(shù)據(jù)信息。
·改變?nèi)鏑reaeVersion(創(chuàng)建版本)、UpdateVersion(更新版本)等跟蹤列·類型專用的列(聲明的類型的屬性)·類型專用的視圖(家族視圖)也包含返回對象的對象列每個類型家族的成員可使用一系列項目視圖來搜索，在數(shù)據(jù)存儲中每個項目類型有一個視圖。圖28是示出項目搜索視圖的概念的圖示。
a)項目每個項目搜索視圖對特定類型或其子類型的項目的每個實例包含一行。例如，文檔的視圖能返回Document(文檔)、LegalDocument(合法文檔)和ReviewDocument(審閱文檔)的實例。給定此例，能如圖29那樣概念化項目視圖。
(1)主項目搜索視圖存儲平臺數(shù)據(jù)存儲的每個實例定義稱為主項目視圖(Master Item View)的特殊項目視圖。此視圖提供關(guān)于數(shù)據(jù)存儲中每個項目的綜述信息。視圖對每個項目類型屬性提供一列，其中一列描述項目的類型，若干列用于提供改變跟蹤和同步信息。在數(shù)據(jù)存儲中使用名字“[System.Storage].[Master！Item]”來標識主項目視圖。


(2)分類型的項目搜索視圖每個項目類型也具有搜索視圖。類似于根項目視圖，此視圖還提供通過“Item”列對項目對象的訪問。在數(shù)據(jù)存儲中使用名字[schemaName].[itemTypeName]標識每個分類型的項目搜索視圖。例如[AcmeCorp.Dod].[OfficeDoc]。

b)項目擴展WinFs存儲中的所有項目擴展也可使用搜索視圖來訪問。
(1)主擴展搜索視圖數(shù)據(jù)存儲的每個實例定義一稱為主擴展視圖(Master Extension View)的特殊擴展視圖。此視圖提供關(guān)于數(shù)據(jù)存儲中每個擴展的綜述信息。該視圖對每個擴展屬性有一列，其中一列描述擴展的類型，而若干列用于提供改變跟蹤和同步信息。使用名字“[System.Storage].[Master！Extension]”在數(shù)據(jù)存儲中標識主擴展視圖。


(2)分類型的擴展搜索視圖每個擴展類型還具有搜索視圖。類似于主擴展視圖，此視圖還提供通過_Extension列對項目對象的訪問。在數(shù)據(jù)存儲中使用名字[SchemaName].[Extension！extensionTypeName]標識每個分類型的擴展搜索視圖。例如[AcmeCorp.Doc].[Extension！OfficeDocExt]。

c)嵌套的元素所有嵌套的元素存儲在項目、擴展或關(guān)系實例之中。因此，它們能通過查詢合適的項目、擴展或關(guān)系搜索視圖來訪問。
d)關(guān)系如上討論，關(guān)系形成在存儲平臺數(shù)據(jù)存儲中各項目之間鏈接的基本單元。
(1)主關(guān)系搜索視圖每個數(shù)據(jù)存儲提供—主關(guān)系視圖。此視圖提供關(guān)于數(shù)據(jù)存儲中所有關(guān)系實例的信息。在數(shù)據(jù)存儲中使用名字“[System.Storage].[Master！Relationship]”來標識主關(guān)系視圖。


(2)關(guān)系實例搜索視圖每個聲明的關(guān)系也有返回該特定關(guān)系的所有實例的搜索視圖。類似于主關(guān)系視圖，此視圖對該關(guān)系數(shù)據(jù)的每個屬性提供命名的列。在數(shù)據(jù)存儲中使用名字[schemaName].[Relationship！relationshipName]來標識每個關(guān)系實例搜索視圖。例如[AcmeCorp.Doc].[Relationship！DocumentAuthor]。

e)9.更新存儲平臺數(shù)據(jù)存儲中所有視圖是只讀的。為創(chuàng)建數(shù)據(jù)模型元素(項目、擴展或關(guān)系)的新實例，或更新現(xiàn)有的實例，必須使用存儲平臺API的ProcessOperation或ProcessUpdategram方法。ProcessOperation方法是單個存儲的過程，它是由消費細化擬執(zhí)行的動作的“操作”的數(shù)據(jù)存儲定義的。ProcessUpdategram方法是存儲的過程，它采取稱為“更新元素(updategram)”的一組有序的操作，它們共同細化擬執(zhí)行的一組動作。
操作格式是可擴展的，并提供在模式元素上的各種操作。某些公用操作包括1.項目操作a.CreateItem(在嵌入或持有關(guān)系的上下文中創(chuàng)建一新的項目)b.UpdateItem(更新一現(xiàn)有的項目)2.關(guān)系操作a.CreateRelationship(創(chuàng)建引用或持有關(guān)系的實例)b.UpdateRelationship(更新一關(guān)系實例)c.DeleteRelationship(移除一關(guān)系實例)3.擴展操作a.CreateExtension(添加一擴展到現(xiàn)有的項目)b.UpdateExtension(更新一現(xiàn)有的擴展)c.DeleteExtension(刪除一擴展)10.改變跟蹤及墓碑如下面更充分討論，由數(shù)據(jù)存儲提供改變跟蹤和墓碑服務。本節(jié)提供在數(shù)據(jù)存儲中展現(xiàn)的改變跟蹤信息的概述a)改變跟蹤由數(shù)據(jù)存儲提供的每個搜索視圖包含用于提供改變跟蹤信息的列；那些列對所有項目、擴展和關(guān)系視圖是公用的。由模式設(shè)計者明確地定義的存儲平臺模式視圖不自動地提供改變跟蹤信息—該信息是通過在其上構(gòu)建視圖本身的搜索視圖來間接提供的。
對數(shù)據(jù)存儲中的每個元素，可從兩個地方得到改變跟蹤信息“主”元素視圖和“分類型的”元素視圖。例如，可從主項目視圖f“[System.Storage].[Master！Item]”和分類型的項目視圖[AcmeCorp.Document].[Document]中得到關(guān)于AcmeCorp.Document.Document項目類型的改變跟蹤信息。
(1)“主”搜索視圖中的改變跟蹤主搜索視圖中的改變跟蹤信息提供關(guān)于元素的創(chuàng)建和更新版本的信息、關(guān)于哪個同步伙伴創(chuàng)建該元素的信息、關(guān)于哪個同步伙伴最后一次更新該元素的信息、以及來自每個伙伴的用于創(chuàng)建和更新的版本號。用伙伴關(guān)鍵字來標識同步關(guān)系中的伙伴(下面描述)。類型[System.Storge.Store].ChangeTrackingInfo的名為_ChangeTrackingInfo的單個UDT對象包含所有這些信息。在System.Storage模式中定義類型。在項目、擴展和關(guān)系的所有全局搜索視圖中可得到_ChangeTrackingInfo。_ChangeTrackingInfo的類型定義是<Type Name＝″ChangeTrackingInfo″BaseType＝″Base.NestedElement″>
<FieldProperty Name＝″CreationLocalTS″ Type＝″SqlTypes.SqlInt64″Nullable＝″False″/>
<FieldProperty Name＝″CreatingPartnerKey″ Type＝″SqlTypes.SqlInt32″Nullable＝″False″/>
<FieldProperty Name＝″CreatingPartnerTS″ Type＝″SqlTypes.SqlInt64″Nullable＝″False″/>
<FieldProperty Name＝″LastUpdateLocalTS″ Type＝″SqlTypes.SqlInt64″Nullable＝″False″/>
<FieldProperty Name＝″LastUpdatingPartnerKey″ Type＝″SqlTypes.SqlInt32″Nullable＝″False″/>
<FieldProperty Name＝″LastUpdatingPartnerTS″ Type＝″SqlTypes.SqlInt64″Nullable＝″False″/>
</Type>
這些屬性包含下述信息

(2)“分類型的”搜索視圖中的改變跟蹤除了提供與全局搜索視圖相同信息外，每個分類型的搜索視圖提供記錄在同步拓撲中每個元素的同步狀態(tài)的附加信息。

b)墓碑數(shù)據(jù)存儲為項目、擴展和關(guān)系提供墓碑信息。墓碑視圖提供一個地方中有關(guān)活動和墓碑實體兩者(項目、擴展和關(guān)系)的信息。項目和擴展墓碑視圖不提對對應對象的訪問，而關(guān)系墓碑視圖提供對關(guān)系對象的訪問(在墓碑關(guān)系的情況下關(guān)系對象為空)。
(1)項目墓碑通過視圖[System.Storage].[Tombstone！item]從系統(tǒng)檢索項目墓碑。


(2)擴展墓碑使用視圖[System.Storage].[Tombstone！Extension]從系統(tǒng)檢索擴展墓碑。擴展改變跟蹤信息類似于為項目提供的添加了ExtensionId屬性的信息。

(3)關(guān)系墓碑通過視圖[System.Storage].[Tombstone！Relationship]從系統(tǒng)檢索關(guān)系墓碑。關(guān)系墓碑信息類似于對擴展提供的信息。然而，在關(guān)系實例的目標ItemRef上提供附加信息。此外，還選擇關(guān)系對象。


(4)墓碑清除為防止墓碑信息無限制地增長，數(shù)據(jù)存儲提供墓碑清除任務。此任務確定什么時候可以舍棄墓碑信息。該任務計算本地創(chuàng)建/更新版本的界限，并隨后通過舍棄所有更早的墓碑版而截斷墓碑信息。
11.助手API和函數(shù)基礎(chǔ)映射還提供若干助手函數(shù)。提供這些函數(shù)以幫助在該數(shù)據(jù)模型上的公用操作。
a)函數(shù)[System.Storage].GetItem//給定ItemId返回一項目對象Item Getltem(ItemId ItemId)b)函數(shù)[System.Storage].GetExtension//給定ItemId和ExtensionId返回一擴展對象Extension GetExtension(ItemId ItemId，ExtensionId ExtensionId)c)函數(shù)[system.Storage].GetRelationship//給定ItemId和RelationshipId返回—關(guān)系對象Relationship GetRelationship(ItemId ItemId，RelationshipId RelationshipId)12.元數(shù)據(jù)有兩類在存儲中表示的元數(shù)據(jù)實例元數(shù)據(jù)(項目的類型等)，和類型元數(shù)據(jù)。
a)模式元數(shù)據(jù)模式元數(shù)據(jù)作為來自元模式的項目類型的實例存儲在數(shù)據(jù)存儲中。
b)實例元數(shù)據(jù)應用程序使用實例元數(shù)據(jù)來查詢項目的類型，并尋找與項目相關(guān)聯(lián)的擴展。給定項目的ItemId，應用程序可查詢?nèi)猪椖恳晥D，以返回該項目的類型，并使用此值來查詢Meta.Type視圖以返回關(guān)于該項目的聲明的類型的信息。例如，//對給定的項目實例返回元數(shù)據(jù)項目對象SELECT m._Item AS metadatalnfoObjFROM[System.Storage].[Item]i INNER JOIN[Meta].[Type]m ON i._TypeId＝m.ItemIdWHERE i.ItemId＝@ItemIdE.安全性一般而言，所有可保護的對象使用圖26中所示的訪問掩碼格式來安排訪問權(quán)限。在此格式中，低16位用于對象專用的的訪問權(quán)限，接著7位用于應用于大多數(shù)對象類型的標準訪問權(quán)限，高4位用于指定類屬訪問權(quán)限，每個對象類型將其映射到一組標準且對象專用的權(quán)限。ACCESS SYSTEM SECURITY位對應于訪問對象的SACL的權(quán)限。
在圖26的訪問掩碼結(jié)構(gòu)中，項目專用的權(quán)限被放置在對象專用權(quán)限段(低16位)。由于在本實施例中，存儲平臺向管理員安全性展現(xiàn)兩組APIWin32和存儲平臺API，為促進存儲平臺對象專用權(quán)限的設(shè)計，必須考慮文件系統(tǒng)對象專用的權(quán)限。
在通過引用結(jié)合于此的有關(guān)專利中充分描述了用于本發(fā)明的存儲平臺的安全模型。在這點上，圖27(部分a、b和c)畫出按安全模型的一實施例，作為從現(xiàn)有安全區(qū)域開拓出的新的等同地保護的安全區(qū)域。
F.通知和改變跟蹤按本發(fā)明的另一方面，存儲平臺提供允許應用程序跟蹤數(shù)據(jù)改變的通知能力。此特征主要供保持易失狀態(tài)或執(zhí)行數(shù)據(jù)改變事件上的業(yè)務邏輯的應用程序使用。應用程序注冊在項目、項目擴展及項目關(guān)系上的通知。在提交了數(shù)據(jù)改變通知被異步地傳送。應用程序可按項目、擴展和關(guān)系類型以及操作類型來過濾通知。
按一個實施例，存儲平臺API 322為通知提供兩類接口。第一，應用程序注冊由對項目、項目擴展和項目關(guān)系的改變觸發(fā)的簡單數(shù)據(jù)改變事件。第二，應用程序創(chuàng)建“監(jiān)視程序”對象來監(jiān)視項目、項目擴展和項目之間關(guān)系的組。在系統(tǒng)失敗或系統(tǒng)離線超過預定時間之后，可保存和重新創(chuàng)建監(jiān)視程序?qū)ο蟮臓顟B(tài)。單個通知可反映多個更新。
關(guān)于此功能的附加細節(jié)能在先前通過引用結(jié)合于此的有關(guān)專利中找到。
G.傳統(tǒng)文件互操作性如上提到，至少在某些實施例中，本發(fā)明的存儲平臺旨在被實施為計算機系統(tǒng)的硬件/軟件接口系統(tǒng)的整體部分。例如，本發(fā)明的存儲平臺可被實施為如Microsoft Windows家族操作系統(tǒng)的整體部分。在這方面，存儲平臺API成為操作系統(tǒng)API的一部分，應用程序通過它與操作系統(tǒng)交互。因此，存儲平臺成為裝置，應用程序通過它將信息存到操作系統(tǒng)上，且從而基于項目的存儲平臺的數(shù)據(jù)模型替代了這一操作系統(tǒng)的傳統(tǒng)文件系統(tǒng)。例如，當在Microsoft Windows家族操作系統(tǒng)中實施時，存儲平臺可替代在該操作系統(tǒng)中實現(xiàn)的NTFS文件系統(tǒng)。當前，應用程序通過由Windows家族操作系統(tǒng)展現(xiàn)的Win32API來訪問NTFS文件系統(tǒng)的服務。
然而，應認識到，完全用本發(fā)明的存儲平臺替代NTFS文件系統(tǒng)需要重新編碼現(xiàn)有的基于Win32的應用程序，且那樣的重新編碼可能是不合需要的，因此本發(fā)明的存儲平臺提供與如NTFS等現(xiàn)有文件系統(tǒng)的某種互操作性是有益的。從而，在本發(fā)明的一個實施例中，存儲平臺使依賴于Win32編程模型的應用程序能同時訪問存儲平臺的數(shù)據(jù)存儲以及傳統(tǒng)的NTFS文件系統(tǒng)的數(shù)據(jù)存儲的內(nèi)容。為此，存儲平臺使用作為Win32命名習慣的超集(superset)的命名習慣以便于容易的互操作性。此外，存儲平臺支持通過Win32 API訪問存儲在存儲平臺卷中的文件和目錄。
關(guān)于此功能的另外細節(jié)能在先前通過引用結(jié)合于此的有關(guān)專利中找到。
H.存儲平臺API存儲平臺包括API，它使應用程序能訪問上面討論的存儲平臺的特征和能力，并訪問存儲在數(shù)據(jù)存儲中的項目。本節(jié)描述本發(fā)明的存儲平臺的存儲平臺API的一個實施例。關(guān)于此功能的細節(jié)能在通過引用結(jié)合于此的有關(guān)專利中找到，為方便起見在下面總結(jié)此信息的某一些。
參考圖18，包含文件夾是一個項目，它包含與其它項目的持有關(guān)系，且與通常概念的文件系統(tǒng)文件夾等價。每個項目“包含”在至少一個包含文件夾中。
圖19示出按本實施例的存儲平臺API的基本體系結(jié)構(gòu)。存儲平臺API使用SQL客戶機1900與本地數(shù)據(jù)存儲302對話，并還使用SQL客戶機1900與遠程數(shù)存儲(如數(shù)據(jù)存儲340)對話。本地存儲還可使用DQP(分布式查詢處理器)或通過上述的存儲平臺同步服務(“Sync”)與遠程數(shù)據(jù)存儲340對話。存儲平臺API322還擔當數(shù)據(jù)存儲通知的橋接器API，將應用程序的下標傳送到通知引擎，并如上所述將通知路由到應用程序(如應用程序350a、350b或350c)。在一個實施例中，存儲平臺API 322還定義受限制的“提供者”體系結(jié)構(gòu)，使得它能訪問MicrosoftExchange和AD中的數(shù)據(jù)。
圖20示意性地表示存儲平臺API的各種組件。存儲平臺AP包括下列組件(1)數(shù)據(jù)類2002，它代表存儲平臺元素和項目類型；(2)運行庫架構(gòu)2004，它管理對象的持久性并提供支持類2006；以及(3)工具2008，它用于從存儲平臺模式生成CLR類。
從給定模式得出的類的分層結(jié)構(gòu)直接反應了該模式中類型的分層結(jié)構(gòu)。作為例子，考慮在如圖21A和圖21B中所示的聯(lián)系人模式中定義的項目類型。
圖22示出操作中的運行庫架構(gòu)。運行庫架構(gòu)如下操作1.應用程序350a、350b或350c綁定到存儲平臺的項目。
2.架構(gòu)2004創(chuàng)建對應于綁定項目的ItemContext對象2202，并將其返回給應用程序。
3.應用程序提交在此ItemContext(項目上下文)上的Find(尋找)，以得到項目的集合；返回的集合在概念上是對象圖2204(由于關(guān)系)。
4.應用程序改變、刪除和插入數(shù)據(jù)。
5.應用程序通過調(diào)用Update()方法保存改變。
圖23示出“FindAll(尋找所有)”操作的執(zhí)行。
圖24示出從存儲平臺模式生成存儲平臺API類的過程。
圖25示出文件API所基于的模式。存儲平臺API包括處理文件對象的名字空間。該名字空間被稱為System.Storage.Files。System.Storage.Files中的類的數(shù)據(jù)成員直接反映了存儲在存儲平臺存儲中的信息；此信息是從文件系統(tǒng)對象的“升級”或使用Win32API本機地創(chuàng)建。System.Storage.Files名字空間具有兩個類FileItem(文件項目)和DirectoryItem(目錄項目)。這些類的成員及其方法可通過審閱圖25中的模式圖來預測。FileItem和DirectoryItem是從存儲平臺API只讀的。為修改它們，必須使用System.IO中的Win32API或類。
對于API，編程接口(或簡稱之為接口)可以被視為用于令代碼的一個或多個片斷能與由代碼的一個或多個其它片斷提供的功能進行通信或?qū)ζ溥M行訪問的任一機制、過程、協(xié)議?；蛘?，編程接口可以被視為能夠通信地耦合至其它計算機的一個或多個機制、方法、函數(shù)調(diào)用、模塊等的系統(tǒng)的組件的一個或多個機制、方法、函數(shù)調(diào)用、模塊、對象等。上述語句中的術(shù)語“代碼片斷”意在包括代碼的一個或多個指令或代碼行，并包括，如，代碼模塊、對象、子例程、函數(shù)等等，無論應用的術(shù)語是什么、或代碼片斷是否被單獨編譯、或代碼片斷是否被提供為源碼、中間碼或?qū)ο蟠a、代碼片斷是否在運行時系統(tǒng)或進程中使用、或它們是否位于同一或不同機器上或跨多個機器分布、或由代碼片斷表示的功能是否完全由軟件、完全由硬件或硬件和軟件的組合來實現(xiàn)。
概念上，編程接口可以被一般地察看，如圖30A或圖30B所示的。圖30A示出了接口“接口1”為管道，第一和第二代碼片斷通過該管道進行通信。圖30B示出了接口包括接口對象I1和I2(可以是或不是第一和第二代碼片斷的部分)，它們令系統(tǒng)的第一和第二代碼片斷能通過介質(zhì)M進行通信。在圖30B中，可以認為接口對象I1和I2為同一系統(tǒng)的單獨接口，并且也可以認為對象I1和I2加上介質(zhì)M構(gòu)成了接口。盡管圖30A和30B示出了雙向流程以及該流程的每一側(cè)上的接口，某些實現(xiàn)可僅具有一個方向上的信息流(或如下所述沒有信息流)，或僅具有一側(cè)的接口對象。作為示例而非局限，諸如應用編程或程序接口(API)、入口點、方法、函數(shù)、子例程、遠程過程調(diào)用和組件對象模型(COM)接口等術(shù)語包含在編程接口的定義之內(nèi)。
這類編程接口的方面可包括第一代碼片斷向第二代碼片斷發(fā)送信息的方法(其中，“信息”以其最廣泛的意義使用，并包括數(shù)據(jù)、命令、請求等等)；第二代碼片斷接收信息的方法；以及該信息的結(jié)構(gòu)、序列、語法、組織、模式、定時和內(nèi)容。在這一點上，只要信息以接口所定義的方式傳輸，底層傳輸介質(zhì)本身可以對接口的操作不重要，無論該介質(zhì)是有線還是無線，或兩者的組合。在某些情況下，在常規(guī)意義上，當一個代碼片斷僅訪問由第二代碼片斷執(zhí)行的功能時，信息可不在一個或兩個方向上傳輸，因為信息傳輸可以是或者通過另一機制(如，信息被放置在與代碼片斷之間的信息流分離的緩存、文件等中)或者不存在。這些方面的任一個或所有可以在給定的情況下重要，如，取決于代碼片斷是否是松耦合或緊耦合配置的系統(tǒng)的一部分，并且因此該列表應當被認為是說明性的而非限制。
編程接口的這一概念對本領(lǐng)域的技術(shù)人員是已知的，并且可以閱讀上述本發(fā)明的詳細描述而清楚這一概念。然而，有其它方法來實現(xiàn)編程接口，并且除非明顯地排除，這些方法也由所附權(quán)利要求書包含在內(nèi)。這些其它方法看似比圖30A和30B的視圖更精密或復雜，但是它們?nèi)詧?zhí)行類似的功能來完成同一整體結(jié)果?，F(xiàn)在簡要描述編程接口的某些說明性替換實現(xiàn)。
分解可以通過將通信分裂成多個離散通信來間接地實現(xiàn)從一個代碼片斷到另一個的通信。這在圖31A和31B中示意性地描述。如圖所示，可以按照功能的可分組來描述某些接口。由此，可以分解圖30A和30B的接口功能來達到相同的結(jié)果，如同可以在數(shù)學上提供24，或2乘2乘3乘2一樣。因此，如圖31A所示，可以細分由接口“接口1”提供的功能以將該接口的通信變換成多個接口“接口1A”、“接口1B”、“接口1C”等，而達到相同的結(jié)果。如圖31B所示，由接口I1提供的函數(shù)可以被細分成多個接口I1a、I1b、I1c等，而達到相同的結(jié)果。類似地，從第一代碼片斷接收信息的第二代碼片斷的接口I2可以被分解成多個接口I2a、I2b、I2c等。當分解時，包括在第一代碼片斷中的接口的數(shù)量不需要匹配包括在第二代碼片斷中的接口的數(shù)量。在圖31A或31B的任一情況下，接口“接口1”和I1的功能性精神分別與圖30A和30B的保持相同。接口的分解也可遵從聯(lián)合、通信和其它數(shù)學性質(zhì)，使得分解較難識別。例如，命令操作可以是不重要的，并且因此由接口完成的功能可以在達到該接口之前由另一段代碼或接口較好地完成，或者由系統(tǒng)的單獨組件執(zhí)行。此外，編程領(lǐng)域的普通技術(shù)人員可以理解有各種方式來作出不同的函數(shù)調(diào)用而達到相同的結(jié)果。
重定義在某些情況下，可能忽略、添加或重定義編程接口的某些方面(如參數(shù))，而仍達到預期的結(jié)果。這在圖32A和32B中示出。例如，假定圖30A的接口“接口1”包括函數(shù)調(diào)用Square(input，precision，output)(平方)，它包括三個參數(shù)，input(輸入)、precision(精度)和output(輸出)，并且由第一代碼片斷向第二代碼片斷發(fā)布。如果中間參數(shù)precision在給定的情形下無關(guān)緊要，如圖32A所示，它也可以被忽略或甚至由meaningless(無意義)(在這一情況下)參數(shù)來替換。也可以添加無關(guān)緊要的additional(另外)參數(shù)。在任一情況下，只要在輸入由第二代碼片斷平方之后返回輸出，就可以達到square(平方)的功能。Precision也有可能對計算系統(tǒng)的某一下游或其它部分是極有意義的參數(shù)；然而，一旦認識到precision對計算平方這一有限目的不是必需的，它可以被替換或忽略。例如，不是傳遞一個有效的pricision值，而是在不對結(jié)果產(chǎn)生不利影響的情況下傳遞諸如出生日期等無意義的值。類似地，如圖32B所示，接口I1由接口I1′替換，它被重新定義來忽略或向接口添加參數(shù)。接口I2可類似地被重定義為接口I2′，它被重定義來忽略不必要的參數(shù)，或可在別處處理的參數(shù)。此處的要點是在某些情況下，編程接口可包括對某一目的而言所不需要的方面，諸如參數(shù)，因此可以忽略或重定義它們，或在別處處理它們用于其它目的。
內(nèi)嵌代碼合并兩個單獨的代碼模塊的一些或全部功能也是可行的，使得它們之間的“接口”改變形式。例如，圖30A和30B的功能可以被分別轉(zhuǎn)化到圖33A和33B的功能。在圖33A中，圖30A的先前的第一和第二代碼片斷被合并成包含兩者的模塊。在這一情況下，該代碼片斷仍可以彼此通信，但是該接口可以適用于更適合單個模塊的形式。由此，例如，正式的調(diào)用(Call)和返回(Return)語句將不再必需，但是依照接口“接口1”的類似的處理或響應仍是有效的。類似地，如圖33B所示，圖30B的部分(或所有)接口I2可以內(nèi)嵌地寫入接口I1來形成接口I1″。如圖所示，接口I2被劃分成I2a和I2b，并且接口部分I2a內(nèi)嵌在接口I1中書寫代碼來形成接口I1″。對于具體的示例，考慮圖30B的接口1執(zhí)行函數(shù)調(diào)用square(input，output)，它由接口I2接收，在由第二代碼片斷處理傳遞到input的值(對其求平方)之后，它被使用output傳遞回已求平方的結(jié)果。在這一情況下，由第二代碼片斷執(zhí)行的處理(對input求平方)可以由第一代碼片斷在不調(diào)用該接口的情況下執(zhí)行。
脫離可以通過將通信分裂成多個離散的通信來間接地完成從一個代碼片斷到另一個的通信。這在圖34A和34B中示意性地描述。如圖34A所示，提供了中間件的一個或多個片斷(脫離接口(Divorce Interface)，因為它們從原始的接口脫離的功能和/或接口函數(shù))，以轉(zhuǎn)化第一接口“接口1”上的通信，使得它們符合不同的接口，在本情況下為“接口2A”、“接口2B”和“接口2C”。這可以在這樣一種情況中完成，例如，依照“接口1”協(xié)議設(shè)計應用的已安裝基礎(chǔ)與如操作系統(tǒng)進行通信，但是然后改變該操作系統(tǒng)來使用不同的接口，在本情況下為接口“接口2A”、“接口2B”和“接口2C”。要點是改變了由第二代碼片斷使用的原始接口，使得它不再與第一代碼片斷所使用的接口兼容，因此使用中介來令舊接口和新接口兼容。類似地，如圖34B所示，可以使用脫離接口DI1引入第三代碼片斷以從接口I1接收信息，并使用脫離接口DI2引入第三代碼片斷以向例如接口I2a和I2b發(fā)送接口功能，重新設(shè)計接口I2a和I2b以使用DI2，但是提供相同的功能性結(jié)果。類似地，DI1和DI2可共同工作以將圖30B的接口I1和I2的功能轉(zhuǎn)換成一新操作系統(tǒng)，而提供相同或類似的功能性結(jié)果。
重寫再一種可能的變化是動態(tài)地重寫代碼，使用別的東西來替換接口的功能，而仍達到相同的總體結(jié)果。例如，可以有一種系統(tǒng)，其中，向執(zhí)行環(huán)境(如由.Net框架提供的環(huán)境、Java運行時環(huán)境或其它類似的運行時刻類型環(huán)境)中的及時(Just-in-Time)(JIT)編譯器或解釋器提供了中間語言(如Microsoft IL、JavaByteCode等)中呈現(xiàn)的代碼片斷?？梢詴鴮慗IT編譯器以動態(tài)地將通信從第一代碼片斷轉(zhuǎn)化到第二代碼片斷，即，令它們符合第二代碼片斷(原始或不同的第二代碼片斷)所需要的不同接口。這在圖35A和35B中有描述。如圖35A中所看見的，這一方式類似于上述的脫離情形。它可以在這樣一種情況下完成，例如，依照“接口1”協(xié)議設(shè)計應用的已安裝基礎(chǔ)操作系統(tǒng)進行通信，然后改變該操作系統(tǒng)以使用不同的接口。JIT編譯器可以用于令已安裝基礎(chǔ)應用的空中通信符合操作系統(tǒng)的新接口。如圖35B所描述的，可以應用這一動態(tài)重寫接口的方法以進行動態(tài)分解，或者改變接口。
應當注意，上述通過替換實施例實現(xiàn)與接口相同或相似的結(jié)果的情形也可以以各種方式串行、并行或與其它干預代碼組合。由此，上文呈現(xiàn)的替換實施例并非相互窮盡，并且可以被混合、匹配和組合以產(chǎn)生與圖30A和30B中所呈現(xiàn)的一般情形相同或等效的情形。也應當注意，如同大多數(shù)編程構(gòu)造，本發(fā)明可能未描述達到與接口相同或相似的功能的其它類似的方式，但是它們?nèi)杂杀景l(fā)明的精神和范圍來表示，即，應當注意，它至少部分地是由作為接口的值的基礎(chǔ)的接口表示的功能或由其啟用的有利結(jié)果。
III.同步API在基于項目的硬件/軟件接口系統(tǒng)中，有若干種同步方法是可行的。節(jié)A揭示了本發(fā)明的若干實施例，而節(jié)B注重用于同步的API的各實施例。
A.同步綜述對于本發(fā)明的若干實施例，并參考圖3，存儲平臺提供同步服務330，它(I)允許存儲平臺的多個實例(每個有自己的數(shù)據(jù)存儲302)按一組靈活的規(guī)則來同步它們的內(nèi)容的各部分，以及(ii)為第三方提供基礎(chǔ)結(jié)構(gòu)以將本發(fā)明的存儲平臺的數(shù)據(jù)存儲與實現(xiàn)專有協(xié)議的其它數(shù)據(jù)源同步。
存儲平臺到存儲平臺的同步在一組參與的復制品之間發(fā)生。例如參考圖3，希望在多半是在不同的計算機系統(tǒng)上運行的存儲平臺的另一實例的控制下提供在存儲平臺300的數(shù)據(jù)存儲302和另一遠程數(shù)據(jù)存儲338之間的同步。該組的總的成員資格不必在任何給定時間被任何給定復制品知道。
不同的復制可以獨立地(即并發(fā)地)作出改變。將同步過程定義成使每個復制品知道由其它復制品作出的改變。此同步能力本質(zhì)上是多主的(multi-master)。
本發(fā)明的同步能力允許各復制品·確定另一復制品知道什么改變；·請求關(guān)于此復制品不知道的改變的信息；·傳輸關(guān)于其它復制品不知道的改變的信息；·確定兩個改變何時互相沖突；·本地應用改變；·傳輸沖突分解到其它復制品以確保會聚性；以及·基于對沖突分解指定的政策分解沖突。
1.存儲平臺到存儲平臺的同步本發(fā)明的存儲平臺的同步服務300的基本應用是同步存儲平臺(每個帶有它自己的數(shù)據(jù)存儲)的多個實例。同步服務在存儲平臺模式級上操作(而不是在數(shù)據(jù)庫引擎314的底層表中)。因此，例如“范圍(Scope)”用于定義下面討論的同步組。
同步服務按“純改變(net change)”的原則操作。不是記錄和發(fā)送各個操作(如事務復制)，同步服務而是發(fā)送這些操作的最終結(jié)果，因此常將多個操作的結(jié)果合并成單個最終結(jié)果。
同步服務通常不考慮事務邊界。換言之，若在單個事務中對存儲平臺數(shù)據(jù)存儲作出兩個改變，不保證這些改變原子地應用到所有其它復制品上一可以示出一個改變而不示出其它改變。此原則的例外是，若在同一事務中對同一項目作出兩個改變，則這些改變保證被原子地發(fā)送和應用到其它復制。因此，項目是同步服務的一致性單元。
a)同步(Sync)控制應用程序任一應用程序可連接到同步服務并啟動sync(同步)操作。那樣的應用程序提供執(zhí)行同步(見下面同步概況)所需的所有參數(shù)。那樣的應用程序在這里被稱為同步控制應用程序(SCA)。
在同步兩個存儲平臺實例時，在一側(cè)由SCA啟動同步。該SCA通知本地同步服務與遠程伙伴同步。在另一側(cè)，同步服務通過由來自發(fā)起機器的同步服務發(fā)出的消息喚醒。它基于在目標機器上存在的持久配置信息(見下文的映射)作出響應。同步服務能按時間表或響應于事件運行。在這些情況下，實現(xiàn)時間表的同步服務成為SCA。
為啟用同步，需要采取兩個步驟。首先，模式設(shè)計者必須用合適的同步語義注釋存儲平臺模式(如下文所述的指定改變單元)。其次，同步必須在具有參與同步的存儲平臺的實例的所有機器上正確地配置(如下所述)。
b)模式注釋同步服務的基本概念是改變單元(Change Unit)的概念。改變單元是由存儲平臺個別地跟蹤的最小的模式片段。對每個改變單元，同步服務能確定自從最后一次同步以來它是被改變還是未被改變。
指定模式中的改變單元達到若干目的。首先，它確定了在線的同步服務如何羅嗦。當在改變單元內(nèi)作出改變時，整個改變單元被發(fā)送到其它復制品，因為同步服務不知道改變單元的哪部分被改變。其次，它確定了沖突檢測的粒度。當對同一改變單元作出兩個并發(fā)的改變(這些術(shù)語在后繼章節(jié)中詳細定義)，同步服務引起沖突；另一方面，若對不同改變單元作出并發(fā)改變，則無沖突發(fā)生，且改變被自動地合并。第三，它嚴重地影響了由系統(tǒng)保持的元數(shù)據(jù)的量。對每個改變單元保持許多同步服務元數(shù)據(jù)；因此，使改變單元更小會增加同步的額外開銷。
定義改變單元需要找出正確的折衷。為此，同步服務允許模式設(shè)計者參與此過程。
在一個實施例中，同步服務不支持大于一個元素的改變單元。然而，它支持讓模式設(shè)計者指定比一個元素更小的改變單元的能力—即將一個元素的多個屬性組合到單獨的改變單元中。在該實施例中，這是使用下述句法實現(xiàn)的<Type Name＝″Appointment″MajorVersion＝″1″MinorVersion＝″0″ExtendsType＝″Base.Item″FxtendsVersion＝″1″>
<Field Name＝″MeetingStatus″Type＝″the storage platformTypes.uniqueidentifierNullable＝″False″/>
<Fileld Name＝″OrganizerName″Type＝″the storage platformTypes nvarchar(512)″Nullable＝″False″/>
<Filed Name＝″OrganizerEmail″Type＝″the storage platformTypes.nvarchar(512)"TypeMajorVersion＝"1″ MultiValued＝″True″/>
...
<ChangeUnit Name＝″CU Status″><Field Name＝″MeetingStatus″/>
</ChangeU nit>
<ChangeUnit Name＝″CU_Organizer″/><Field Name＝″OrganizerName″/><Field Name＝″OrganizerEmail″/>
</ChangeU n it>
...</Type>
c)同步配置希望保持它們數(shù)據(jù)的某些部分同步的一組存儲平臺伙伴被稱為同步共同體。雖然共同體的成員希望保持同步，它們不需要以完全相同的方式表示數(shù)據(jù)；換言之，同步伙伴可轉(zhuǎn)換他們正在同步的數(shù)據(jù)。
在對等情況下，讓對等方對所有它們的伙伴維持轉(zhuǎn)換映射是不現(xiàn)實的。取代地，同步服務采取定義“共同體文件夾”的方法。共同體文件夾是代表所有共同體成員正在與之同步的假設(shè)的“共享文件夾”的抽象。
此概念最好用一例子說明。若Joe希望保持他的若干計算機的My Documents(我的文檔)文件夾同步，Joe定義一共同體文件夾，如稱為JoeDocuments。隨后在每臺計算機上，Joe在假設(shè)的JoeDocuments文件夾和本地My Documents文件夾之間配置一映射。從這點出發(fā)，當Joe的計算機彼此同步時，它們借助JoeDocuments中的文檔而不是它們的本地項目來交談。以此方法，所有Joe的計算機互相理解，而不必知道其它人是誰—共同體文件夾成為同步共同體的通用語。
配置同步服務包括三個步驟(1)定義在本地文件夾和共同體文件夾之間的映射；(2)定義確定哪個得到同步的同步概況(如與誰同步，以及哪個子集應當被發(fā)送、哪個被接收)；以及(3)定義不同的同步概況應當運行的時間表，或手動運行它們。
(1)共同體文件夾—映射共同體文件夾映射作為XML配置文件被存儲在個別機器上。每個映射具有以下模式/mappings/communityFolder
此元素命名映射的共同體文件夾。名字遵循文件夾的句法規(guī)則。/mappings/localFolder此元素命名映射所轉(zhuǎn)換到的本地文件夾。此名字遵循文件夾的句法規(guī)則。為了映射有效，文件夾必須已存在。此文件夾中的項目被看作對每一此映射的同步。/mappings/transformations此元素定義如何將項目從共同體文件夾轉(zhuǎn)換到本地文件夾以及如何反向轉(zhuǎn)換。若缺少或為空，不執(zhí)行轉(zhuǎn)換。具體說來，這意味著無ID被映射。此配置主要用于創(chuàng)建文件夾的高速緩存。/mappings/transformations/mapIDs此元素請求新生成的本地ID被賦予所有從共同體文件夾映射的項目，而不是重新使用共同體ID。同步運行庫維護ID映射，以來回轉(zhuǎn)換項目。/mappings/transformations/localRoot此元素請求共同體文件夾中的所有根項目作為指定根的子項目。/mappings/runAs此元素控制，在誰的授權(quán)下處理針對此映射的請求。若不存在，則假設(shè)發(fā)送者。/mappings/runAs/sender存在此元素表明，對此映射的消息發(fā)送者必須是人格化的，且在他的憑證下處理請求。
(2)概況同步概況是分離同步所需的總的參數(shù)組。由SCA將其提供給同步運行庫以啟動同步。存儲平臺到存儲平臺的同步的同步概況包含以下信息·本地文件夾，用作改變的源和目標；·與之同步的遠程文件夾名—此文件夾必須通過如上定義的映射從遠程伙伴發(fā)布；·方向—同步服務支持只發(fā)送、只接收以及發(fā)送—接收同步；·本地過濾器—選擇發(fā)送什么本地信息到遠程伙伴。表示成本地文件夾上的存儲平臺查詢；·遠程過濾器—選擇從遠程伙伴接收什么遠程信息—表示成共同體文件夾上的存儲平臺查詢；·轉(zhuǎn)換—定義如何在項目和本地格式間轉(zhuǎn)換；·本地安全性—指定是在遠程端點(人格化)的許可下應用從遠程端點檢索的改變，還是用戶在本地啟動同步；以及·沖突分解政策—指定沖突是否應被拒絕、記入日志或自動分解—在后一種情況下，指定使用哪個沖突分解器以及它的配置參數(shù)。
同步服務提供允許簡單構(gòu)建同步概況的運行時CLR類。概況可被串行化成XML文件或從XML文件串行化，以便容易存儲(常與時間表一起)。然而，在存儲平臺中沒有存儲所有概況的標準地方；歡迎SCA在不必永久保持的點上構(gòu)建概況。注意，不需要具有本地映射來啟動同步。能在概況中指定所有同步信息。然而為響應于由遠程方啟動的同步請求，需要映射。
(3)時間表在一個實施例中，同步服務不提供它自己的調(diào)度基礎(chǔ)結(jié)構(gòu)。相反，它依賴于另一組件來完成此任務—在Microsoft Windows操作系統(tǒng)中可得到的WindowsScheduler。同步服務包括命令行實用程序，它擔當SCA并基于保存在XML文件中的同步概況觸發(fā)同步。該實用程序使得按時間表或者響應于如用戶登錄或登出等事件來配置Windows Scheduler變得非常容易。
d)沖突處理同步服務中的沖突處理被劃分成三個階段(1)發(fā)生在改變應用時的沖突檢測—此步驟判斷是否可安全地應用改變；(2)自動沖突分解并記入日志—在此步驟(發(fā)生在緊接著沖突檢測之后)資訊自動沖突分解器，以查看沖突是否能被分解—若不能，可任選地將沖突記入日志；以及(3)沖突檢查與分解—若某些沖突已被記入日志，且發(fā)生在同步會話之外，則采取此步驟—此時，被記入日志的沖突能被分解并從日志中移除。
(1)沖突檢測在本實施例中，同步服務檢測兩類沖突基于知識和基于約束的。
(a)基于知識的沖突當兩個復制品對同—改變單元作出獨立的改變時，發(fā)生基于知識的沖突。兩個改變?nèi)羰撬鼈冊诨ハ嗖恢赖那闆r作出的，則稱為獨立的—換言之，第一個的版本不被第二個的知識所覆蓋，反之亦然。同步服務基于上述復制品的知識自動檢測所有那些沖突。
將沖突想成在改變單元的版本歷史中的分叉有時是有益的。若在改變單元的生命中不發(fā)生沖突，其版本歷史是簡單的鏈—每個發(fā)生在前一個之后。在基于知識的沖突的情況下，兩個改變并行發(fā)生，導致鏈分裂，成為版本樹。
(b)基于約束的沖突存在獨立的改變在一起應用時破壞完整性約束的情況。例如，在同一目錄中用同樣的名字創(chuàng)建一個文件的兩個復制品能導致發(fā)生那樣的沖突。
基于約束的沖突牽涉到兩個獨立的改變(就象基于知識的沖突)，但它們不影響同一改變單元。相反，它們影響不同的改變單元，但在它們之間存在約束。
同步服務檢測在改變應用時的約束破壞，并自動引起基于約束的沖突。分解基于約束的沖突通常需要自定義代碼，它以不破壞約束的方式修改那些改變；同步服務不提供這樣做的通用機制。
(2)沖突處理在檢測到?jīng)_突時，同步服務可采取三個動作之一(由同步概況中的同步啟動者選擇)(1)拒絕該改變，將其返回到發(fā)送者；(2)將沖突記入到?jīng)_突日志；或(3)自動分解沖突。
若改變被拒絕，同步服務如同該改變沒有到達該復制品那樣地運作。否定確認被發(fā)回到發(fā)起者。此分解政策主要在無領(lǐng)導的復制品(如文件服務器)上有用，在那里將沖突記入日志是不可行的。相反，那些復制品通過拒絕它們來強迫其它復制品處理那些沖突。
同步啟動者在它們的同步概況中配置沖突分解。同步服務支持在單個概況中以下列方式組合多個沖突分解器—首先通過指定沖突分解器的列表，一個接著一個地嘗試分解，直到其中一個成功；第二，通過將沖突分解器與沖突類型相關(guān)聯(lián)，如引導更新—更新基于知識的沖突到一個分解器，但所有其它沖突記入日志。
(a)自動沖突分解同步服務提供若干默認的沖突分解器。其列表包括·本地贏若與本地存儲的數(shù)據(jù)沖突，則不予處理進入的改變；·遠程贏若與進入的改變沖突，則不予處理本地數(shù)據(jù)；
·最后寫贏基于改變的時間標記挑選每個改變單元的本地贏或遠程贏(注意，同步服務一般不依賴于時鐘值；此沖突分解器是該規(guī)則的唯—例外)；·確定的以保證在所有復制品上相同，但在其它情況下無意義的方式挑選贏者—同步服務的一個實施例使用伙伴ID的字典式比較來實現(xiàn)此特征。
此外，ISV能實現(xiàn)并安裝它們自己的沖突分解器。自定義沖突分解器可接受配置參數(shù)；那些參數(shù)必須由SCA在同步概況中的沖突分解段中指定在沖突分解器處理沖突時，它向運行庫返回需要執(zhí)行的操作(替代沖突改變)的列表。然后同步服務應用這些操作，其具有正確地調(diào)整的遠程指示，以包括沖突處理器所考慮的所有內(nèi)容。
在應用分解的同時可能檢測到另外沖突。在那樣情況下，新的沖突必須在原先處理重新開始之前被分解。
將沖突考慮成項目的版本歷史中的分枝時，沖突分解可看成合并—組合兩個分枝以形成單個點。因此，沖突分解將版本歷史轉(zhuǎn)到DAG。
(b)沖突日志記錄一種非常特定類型的沖突分解器是沖突日志記錄器。同步服務將沖突記入日志作為ConflictRecord(沖突記錄)的項目。這些記錄反過來與沖突中的項目有關(guān)(除非項目本身已被刪除)。每個沖突記錄包括導致沖突的進入的改變；沖突的類型；更新—更新、更新—刪除、刪除—更新、插入—插入或約束；以及進入的改變的版本和發(fā)送它的復制品的知識。記入日志的沖突可用于下面所述的檢查和分解。
(c)沖突檢查和分解同步服務對應用程序提供API，以檢查沖突日志并建議其中的沖突分解。該API允許應用程序枚舉所有沖突，或與給定項目有關(guān)的沖突。還允許那些應用程序以下列三種方法之一分解記入日志的沖突(1)遠程贏—接受記入日志的改變并覆寫沖突的本地改變；(2)本地贏—忽略記入日志的改變的沖突部分；以及(3)建議新的改變—其中，應用程序提議一合并，以它的觀點，該合并分解沖突。一旦由應用程序分解了沖突，同步服務將它們從日志中移除。
(d)復制品的會聚性及沖突分解的傳播在復雜同步的情況下，在多個復制品中能檢測到同一沖突。若發(fā)生此情況，發(fā)生若干事情(1)在一個復制品上能分解沖突，并將分解送到其它復制品；(2)沖突在兩個復制品上被自動分解；以及(3)在兩個復制品上手動分解沖突(通過分解檢查API)。
為保證會聚性，同步服務將沖突分解轉(zhuǎn)發(fā)到其它復制品。當分解沖突的改變到達復制品時，同步服務自動地在日志中尋找由此更新分解的任何沖突，并消除它們。在此情況下，一個復制品上的沖突分解被綁定到所有其它復制品。
若不同的復制品對同一沖突選擇了不同的贏者，則同步服務應用綁定沖突分解的原則，并自動地挑選兩個分解中一個勝過另一個。以確定性的方式挑選贏者以保證在所有時刻都產(chǎn)生同樣的結(jié)果(一個實施例使用復制品ID字典式比較)。
若不同復制對同一沖突建議不同的“新改變”，則同步服務將此新沖突處理成特殊沖突，并使用沖突日志記錄器來防止它傳播到其它復制品。那樣情況常在手動沖突分解時發(fā)生。
2.對非存儲平臺數(shù)據(jù)存儲的同步按本發(fā)明的存儲平臺的另一方面，存儲平臺提供ISV用于實現(xiàn)同步適配器的體系結(jié)構(gòu)，同步適配器使存儲平臺能與如Microsoft Exchange、AD、Hotmail等傳統(tǒng)系統(tǒng)同步。同步適配器得益于由下述同步服務提供的許多同步服務。
不管其名稱如何，同步適配器不需要作為某個存儲平臺體系結(jié)構(gòu)的插件來實現(xiàn)。在需要時，“同步適配器”能簡單地是利用同步服務運行庫接口來獲得如改變枚舉和應用等服務的任何應用程序。
為了使其他人能更容易地配置和運行到給定后端(backend)的同步，鼓勵同步適配器的編寫者展現(xiàn)標準同步適配器接口，它在給定上述的同步概況時運行同步。概況提供配置信息給適配器，某些適配器傳送到同步運行庫以控制運行庫服務(如，要同步的文件夾)。
a)同步服務同步服務向適配器編寫者提供若干同步服務。在本節(jié)余下部分，方便地將存儲平臺在其上做同步的機器稱為“客戶機”，而適配器正與其對話的非存儲平臺后端稱為“服務器”。
(1)改變枚舉基于由同步服務維持的改變跟蹤數(shù)據(jù)，改變枚舉允許同步適配器容易地枚舉自從最后一次與該伙伴試圖作出同步以來對數(shù)據(jù)存儲文件夾發(fā)生的改變。
基于“錨位(anchor)”的概念來枚舉改變—這是表示有關(guān)最后一次同步的信息的不透明的結(jié)構(gòu)。如以前章節(jié)所述，錨位采取存儲平臺知識的形式。利用改變枚舉服務的同步適配器落入兩大類別使用“存儲的錨位”的適配器和使用“提供的錨位”的適配器。
區(qū)別基于關(guān)于最后一次同步的信息存儲在哪里—在客戶機上或在服務器上。適配器常常容易地存儲此信息在客戶機上—后端往往不能容易地存儲此信息。另一方面，若多個客戶機與同一后端同步，則將此信息存儲在客戶機上是低效且在某些情況下是不正確的—這使一個客戶機不知道其它客戶機已推到服務器的改變。若適配器希望使用服務器存儲的錨位，則適配器需要在改變枚舉時將其送回到存儲平臺。
為了讓存儲平臺維護錨位(用于本地或遠程存儲)，存儲平臺需要知道成功地應用在服務器上的改變。這些且只有這些改變能包括在錨位中。在改變枚舉期間，同步適配器使用確認(Acknowledgement)接口，以報告哪個改變已被成功地應用。在同步結(jié)束時，使用提供的錨位的適配器必須讀出新錨位(它集合所有成功應用的改變)并將其發(fā)送到它們的后端。
各適配器常常需要存儲適配器專用數(shù)據(jù)以及插入到存儲平臺數(shù)據(jù)存儲中的各項目。該數(shù)據(jù)存儲的常見例子是遠程ID和遠程版本(時間標記)。同步服務提供用于存儲此數(shù)據(jù)的機制，而改變枚舉提供接收此額外數(shù)據(jù)以及要返回的改變的機制。在大多數(shù)情況下，這消除了適配器重新查詢數(shù)據(jù)庫的需求。
(2)改變應用改變應用允許同步適配器將從它們的后端接收的改變應用到本地存儲平臺。期望適配器將改變轉(zhuǎn)換到存儲平臺模式。圖24示出從存儲平臺模式生成存儲平臺API類的過程。
改變應用的主要功能是自動檢測沖突。如在存儲平臺到存儲平臺同步的情況下，沖突被定義成在互相不知道時作出的兩個重疊的改變。當適配器使用改變應用時，它們必須指定對其執(zhí)行沖突檢測的錨位。若檢測到未被適配器的知識覆蓋的重疊的本地改變，則改變應用引起沖突。類似于改變枚舉，適配器可使用存儲的或提供的錨位。改變應用支持適配器專用元數(shù)據(jù)的有效存儲。那樣的數(shù)據(jù)可由適配器將其附加到要應用的改變上，且可被同步服務存儲。數(shù)據(jù)可在下次改變枚舉時返回。
(3)沖突分解以下在IV中描述的沖突分解機制(包括記入日志和自動分解選項)也對同步適配器可用。在應用改變時，同步適配器能指定用于沖突分解的政策。若指定了，沖突可被傳遞到指定的沖突處理程序并予以分解(若可能)。沖突也能被記入日志。當試圖將本地改變應用到后端時，適配器有可能檢測沖突。在那樣情況下，適配器仍可以將沖突傳遞到同步運行庫，以按政策分解。此外，同步適配器可請求任何由同步服務檢測的沖突發(fā)回給它們以便處理。在后端能存儲或分解沖突的情況這特別方便。
b)適配器實現(xiàn)雖然某些“適配器”簡單地是利用運行庫接口的應用程序，然而鼓勵適配器實現(xiàn)標準的適配器接口。這些接口允許同步控制應用程序請求適配器按給定的同步概況執(zhí)行同步；取消正進行的同步；以及接收關(guān)于正進行同步的進展報告(完成百分比)。
3.安全性同步服務努力將盡可能少的同步引入到由存儲平臺實現(xiàn)的安全模式。不是去定義對同步新的權(quán)限，而是使用現(xiàn)有的權(quán)限。具體地，·能讀數(shù)據(jù)存儲項目的任何人可枚舉對那個項目的改變；·能寫到數(shù)據(jù)存儲項目的任何人可應用改變到該項目；以及·能擴展數(shù)據(jù)存儲項目的任何人可將同步元數(shù)據(jù)與該項目關(guān)聯(lián)。
同步服務不維護安全授權(quán)信息。當在復制品A由用戶U作出改變，且將其轉(zhuǎn)發(fā)到復制品B時，該改變最初在A處(由U)作出的事實丟失了。若B將此改變轉(zhuǎn)發(fā)到復制品C，則這是在B的授權(quán)而不是在A的授權(quán)下完成的。這就導致下述限制若不信任一個復制品對一個項目作出它自己的改變，它不能轉(zhuǎn)發(fā)由其它復制品作出的改變。
在啟動同步服務時，由同步控制應用程序完成。同步服務人格化SCA的身份，并在該身份下完成所有操作(本地的和遠程的)。作為說明，觀察到用戶U不能使本地同步服務從遠程存儲平臺檢索對用戶U不具有讀訪問的項目的改變。
4.可管理性監(jiān)視復制品的分布式共同體是復雜的問題。同步服務可使用“掃描(sweep)”算法來收集和分發(fā)關(guān)于該復制品的狀態(tài)的信息。掃描算法的屬性確保關(guān)于所有所配置的復制品的信息最終被收集，且檢測到該失敗(無響應)的復制品。
在每個復制品上可得到共同體范圍的監(jiān)視信息?？稍谌我膺x取的復制品上運行監(jiān)視工具，以檢查此監(jiān)視信息并作出管理決策。在受影響的復制品上必須直接作出配置改變。
B.同步API綜述在越來越多地分布式的、數(shù)字的世界中，個體和工作站常常將信息和數(shù)據(jù)存儲在多種不同的設(shè)備和位置中。這就推動了數(shù)據(jù)同步服務的發(fā)展，在最小限度的用戶干預的情況下，所述數(shù)據(jù)同步服務可以將所述信息保存在這些單獨的、常常完全各不相同的在所有時間上都被同步了的數(shù)據(jù)存儲中。
本發(fā)明的同步平臺，作為此處的節(jié)II(又稱，“WinFS”)中所描述的豐富的存儲平臺的一部分，解決了3個主要任務·允許應用和服務有效地同步不同“WinFS”的存儲之間的數(shù)據(jù)。
·允許開發(fā)者創(chuàng)建用于同步“WinFS”和非“WinFS”存儲之間的數(shù)據(jù)的富有成果的方法。
·為開發(fā)者提供適當?shù)慕涌谝员愣ㄖ仆接脩艚?jīng)歷。
1.一般術(shù)語在此，下面是與后面的討論此處是節(jié)III.B有關(guān)的一些進一步規(guī)定的定義和關(guān)鍵概念同步復制品大多數(shù)應用只對跟蹤、枚舉和同步用于WinFS存儲內(nèi)的項目的給定子集的改變。將參與同步操作的項目的集合稱為同步復制品。復制品是用被包含在給定的WinFS包含層內(nèi)的項目(通常是作為位于文件夾項目上的根)來定義的。所有同步服務都在給定的復制品的環(huán)境內(nèi)實現(xiàn)。WinFS同步提供了規(guī)定、管理和清除復制品的機制。各個復制品具有唯一地標識給定WinFS存儲內(nèi)的復制品的GUID標識符。
同步伙伴同步伙伴被規(guī)定為能夠影響在WinFS項目、擴展和關(guān)系上的改變的實體。因此，各個WinFS存儲可以被稱為同步伙伴。當與非WinFS存儲同步時，外部數(shù)據(jù)源(EDS)也被稱作同步伙伴。各個伙伴具有唯一地標識它的GUID標識符。
同步共同體同步共同體被規(guī)定為復制品的集合，采用對等同步操作的方式，同步地保存所述復制品的集合。這些復制品可以全部都是位于相同的WinFS存儲、不同的WinFS存儲中，或者甚至將它們清楚表示為非WinFS存儲上的虛擬復制品。特別地如果共同體中只有同步操作是通過WinFS同步服務(WinFS適配器)的，則WinFS同步并不指定或委托用于所述共同體的任何專用拓撲。同步適配器(下面規(guī)定的)可以引入其自己的拓撲約束。
改變跟蹤、改變單元和版本各個WinFS存儲跟蹤對所有本地WinFS項目、擴展和關(guān)系的改變。在所述模式中所規(guī)定的改變單位粒度(granularity)的等級上，跟蹤改變。采用作為一個頂級字段的最小粒度，任何項目、擴展和關(guān)系類型的項級字段可以由模式設(shè)計者子劃分為改變單元。為了改變跟蹤的目的，每個改變單元被分配一個版本，其中版本是一對同步伙伴Id和版本號(所述版本號是伙伴專用的單調(diào)增加的數(shù)字)。按照本地發(fā)生在所述存儲中的或者按照它們從其它復制品中獲得的改變，更新版本。
同步知識知識表示在任意時間給出同步復制品的狀態(tài)，即它封裝與給定的復制品本地知道的或者是從其它復制品中知道的所有改變有關(guān)的元數(shù)據(jù)。WinFS同步保存并且更新用于跨同步操作的同步復制品的知識。要注意的重要的事情是，知識表示允許它相對整個共同體進行解釋而不是只相對于與知識被存儲的特定復制品進行解釋。
同步適配器同步適配器是受管理的編碼應用，它通過同步例程API訪問WinFS同步服務，并且使WinFS數(shù)據(jù)與非WinFS數(shù)據(jù)存儲同步。依賴于情況的需要，關(guān)于WinFS數(shù)據(jù)的哪個子集和什么WinFS數(shù)據(jù)類型進行同步，取決于適配器開發(fā)者。所述適配器負責與EDS進行通信、向和從支持模式的EDS傳送WinFS模式、以及規(guī)定并管理其自己的配置和元數(shù)據(jù)。強烈鼓勵適配器實現(xiàn)WinFS同步適配器，以便具有普通配置和控制用于由WinFS同步組所提供的適配器的底層結(jié)構(gòu)的優(yōu)點。對于更多的細節(jié)，請參見WinFS同步適配器API?？痆SADP]和WinFS同步控制器API[SCTRL]?？?。
對于使WinFS數(shù)據(jù)與外部的非WinFS存儲同步并且不能以WinFS格式產(chǎn)生或保存知識的適配器，WinFS同步提供了保存遠程知識的服務，所述遠程知識能夠被用于后來的改變枚舉或應用操作。依賴于后端存儲的能力，所述適配器可以希望在所述后端上或者在本地WinFS存儲上存儲這種遠程知識。
為簡單起見，同步“復制品”是一種結(jié)構(gòu)，它表示“WinFS”存儲中存在于單個本地位置中的一組數(shù)據(jù)，然而，非WinFS存儲上的數(shù)據(jù)被稱作“數(shù)據(jù)源”，并且一般要求使用適配器。
遠程知識當給定的同步復制品希望獲得來自另一個復制品的改變時，它提供其自己的知識作為一種基線，根據(jù)基線，其它復制品枚舉改變。類似地，當給定的復制品希望將改變發(fā)送給另一個復制品時，它提供其自己的知識作為基線，所述基線可以由遠程復制品用于檢測沖突。在同步改變枚舉和應用期間提供的與其它復制品有關(guān)的這種知識被稱為遠程知識。
2.同步API主體對于某些實施例，所述同步API分割成兩部分同步配置API和同步控制器API。同步配置API允許應用配置同步，并且指定參數(shù)用于兩個復制品之間的特定同步會話。對于給定的同步會話，配置參數(shù)包括將被同步的項目的集合、同步的類型(單向或雙向)、與遠程數(shù)據(jù)源有關(guān)的信息、以及沖突分解策略。同步控制器API啟動同步會話，取消同步，以及接收處理和與正在進行的同步有關(guān)的錯誤信息。還有，對于特定的實施例，其中同步需要根據(jù)預定的調(diào)度執(zhí)行，這種系統(tǒng)可以包括調(diào)度定制調(diào)度表的機制。
本發(fā)明的多個實施例使用同步適配器以便同步“WinFS”和非“WinFS”數(shù)據(jù)源之間的信息。適配器的例子包括同步“WinFS”沖突文件夾和非WinFS郵箱之間的地址簿信息的適配器。在這些情況下，為了開發(fā)“WinFS”模式和非“WinFS”數(shù)據(jù)源模式之間的模式轉(zhuǎn)換編碼，適配器開發(fā)者可以使用此處所描述的“WinFS”同步核心服務API以便訪問由“WinFS”同步平臺所提供的服務。此外，適配器開發(fā)者提供了用于將改變與非“WinFS”數(shù)據(jù)源進行通信的協(xié)議支持。通過使用同步控制器API調(diào)用并控制同步適配器，并且使用這種API報告進度和錯誤。
然而，對于本發(fā)明的某些實施例，當“WinFS”數(shù)據(jù)存儲與另一個“WinFS”數(shù)據(jù)存儲同步時，如果“WinFS”對“WinFS”同步服務被集成在硬件/軟件接口系統(tǒng)內(nèi)，則同步適配器可以不是必需的。在任何情況下，多個這樣的實施例提供了用于“WinFS”對“WinFS”以及同步適配器方法兩者的一組同步服務，所述同步適配器方法包括·對“WinFS”項目、擴展和關(guān)系的改變的跟蹤。
·用于自給定的過去的狀態(tài)開始的有效遞增的改變枚舉的支持。
·對“WinFS”的外部改變的應用。
·在改變應用期間的沖突處理。
參見圖36，示出了普通數(shù)據(jù)存儲和用于同步它們的組件的3個實例。第一系統(tǒng)3602具有WinFS數(shù)據(jù)存儲3612，所述WinFS數(shù)據(jù)存儲3612包括WinFS對WinFS同步服務3622和核心同步服務3624，用于WinFS對非WinFS同步，它公開了3646用于使用的同步API 3652。類似于第一系統(tǒng)3602，第二系統(tǒng)3604具有WinFS數(shù)據(jù)存儲3614，所述WinFS數(shù)據(jù)存儲3614包括WinFS對WinFS同步服務3632和核心同步服務3634，用于WinFS對非WinFS同步，它公開了3646用于使用的同步API 3652。第一系統(tǒng)3602和第二系統(tǒng)3604通過其各自的WinFS對WinFS同步服務3622和3632進行同步3642。第三系統(tǒng)3606，不是WinFS系統(tǒng)，它具有用于使用WinFS同步3666將數(shù)據(jù)源保存在具有WinFS復制品的同步共同體中的應用。這種應用可以使用WinFS同步配置/控制服務3664，以便通過WinFS對WinFS同步服務3622(如果它能將自身虛擬化為WinFS數(shù)據(jù)存儲)，或者通過提供與同步API 3652的接口3648的同步適配器3662，直接提供與WinFS數(shù)據(jù)存儲3612的接口3644。
如在此圖中所示的，第一系統(tǒng)3602知道并且直接同步第二系統(tǒng)3604和第三系統(tǒng)3606。然而，第二系統(tǒng)3604和第三系統(tǒng)3606彼此并不知道，并且因此，并不直接彼此同步它們的改變，但是，相反，一個系統(tǒng)上發(fā)生的改變必須通過第一系統(tǒng)3602傳播。
C.同步API服務本發(fā)明的多個實施例被指向同步服務，所述同步服務包括兩個基礎(chǔ)服務改變枚舉和改變應用。
1.改變枚舉如此處較早之前討論的，改變枚舉允許同步適配器很容易地枚舉改變，所述改變是，自基于由同步服務所保存的改變跟蹤數(shù)據(jù)，企圖與這個伙伴的同步的最后時刻開始的數(shù)據(jù)存儲文件夾上已經(jīng)發(fā)生的改變。就改變枚舉而言，針對本發(fā)明的多個實施例對給定復制品中與被指定的知識實例有關(guān)的項目、擴展和關(guān)系的改變的有效枚舉。
·在被指定于WinFS模式中的改變單元粒度的等級上的改變的枚舉·依據(jù)復合項目的被枚舉的改變的組。復合項目包括項目、所有其擴展、與所述項目的所有保持關(guān)系、以及對應于其被嵌入的項目的所有復合項目。引用項目之間的關(guān)系的改變可以被分別枚舉。
·與改變枚舉有關(guān)的分類。所述分類的粒度是復合項目或者關(guān)系改變(用于引用關(guān)系)。
·在改變枚舉期間對復制品中的項目的過濾的指定，例如所述復制品包括給定文件夾中的所有項目，但是對于這種特殊的改變枚舉，所述應用愿意只枚舉對所有聯(lián)系項目的改變，其中第一名稱以“A”開始(這種支持將被添加至B-里程碑)。
·用于被枚舉的改變的遠程知識的使用，具有將個別改變單元(或者整個項目、擴展或關(guān)系)記錄為在知識上同步失敗的能力，以便下一次重新枚舉時具有它們。
·改進的適配器的使用，所述改進的適配器也許能夠通過在改變枚舉期間隨著改變一起返回元數(shù)據(jù)，了解WinFS同步元數(shù)據(jù)。
2.改變應用如此處較早所討論的，改變應用允許同步適配器將從它們的后端接收到的改變應用到本地存儲平臺，因為希望所述適配器將所述改變轉(zhuǎn)換成存儲平臺模式。就改變應用而言，本發(fā)明的多個實施例被指導·具有對應于WinFS改變元數(shù)據(jù)的更新的來自其它復制品(或非WinFS存儲)中的遞增的改變的應用。
·在改變單元粒度上的與改變應用有關(guān)的沖突檢測。
·在改變應用上的個別改變單元級上成功、失敗以及沖突的報告，以便應用(包括適配器和同步控制應用)可以使用要處理的那些信息、錯誤和狀態(tài)報告，并且用于更新它們的后端狀態(tài)，如果有的話。
·在改變應用期間遠程知識的更新，以便防止在下一個改變枚舉操作期間被提供改變的應用的“沖突”。
·改進的適配器的使用，所述改進的適配器可以隨著改變一起了解并提供WinFS同步元數(shù)據(jù)。
3.示例代碼下面是用于FOO同步適配器如何可以與同步例程進行交互的編碼示例(其中采用FOO作為所有適配器的專用函數(shù)的前綴)<pre listing-type="program-listing"><![CDATA[　　ItemContext ctx＝new ItemContext(“\.\System\UserData\dshah\MyContacts”，true)；　　//從概況獲得復制品項目id和遠程伙伴id　　//大多數(shù)適配器從同步概況獲得此信息　　Guid replicaItemId＝FOO_GetReplicaId()；　　Guid remotePartnerId＝FOO_Get_RemotePartnerId()；　　//　　//使用如上所述的storedKnowledgeId查找存儲中所儲存的知識.　　//　　ReplicaKnowledge remoteKnowledge＝...；　　//　　//初始化ReplicaSynchronizer　　//　　ctx.ReplicaSynchronizer＝new ReplicaSynchronizer(replicaItemId，remotePartnerId)；　　ctx.ReplicaSynchronizer.RemoteKnowledge＝remoteKnowledge；ChangeReader reader＝ctx.ReplicaSynchronizer.GetChangeReader()；　　//　　//枚舉改變并處理它們　　//　　bool bChangesToRead＝true；　　while(bChangesToRead)　　{　　ChangeCollection＜object＞changes＝null；　　bChangesToRead＝reader.ReadChanges(10，out changes)；　　foreach(object change in changes)　　{　　//處理所枚舉的對象，適配器完成其自己的模式轉(zhuǎn)換以及ID映射　　//它甚至可為此目的從Ctx檢索附加對象，　　//并在向遠程存儲應用改變之后修改適配器元數(shù)據(jù)　　//　　ChangeStatus status＝FOOProcessAndApplyToRemoteStore(change)；　　//用狀態(tài)更新獲知的知識　　reader.AcknowledgeChange(changeStatus)；　　}　　}　　remoteKnowledge＝　　ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge()；　　reader.Close()；　　////保存更新的知識和適配器元數(shù)據(jù)(如果有的話)　　//　　ctx.Update()；　　//　　//改變應用的示例，首先使用如上所述的storedKnowledgeId　　//初始化遠程知識　　//　　remoteKnowledge＝...；　　ctx.ReplicaSynchronizer.ConflictPolicy＝conflictPolicy；　　ctx.ReplicaSynchronizer.RemotePartnerId＝remotePartnerId；　　ctx.ReplicaSynchronizer.RemoteKnowledge＝remoteKnowledge；　　ctx.ReplicaSynchronizer.ChangeStatusEvent +＝　　FOO_OnChangeStatusEvent；　　//　　//從遠程存儲獲得改變。適配器負責從存儲檢索其后端專用元數(shù)據(jù)?！　?/這可以是在復制品上的擴展　　//　　//　　object remoteAnchor＝FOO_GetRemoteAnchorFromStore()；　　FOO_RemoteChangeCollection remoteChanges＝　　FOO_GetRemoteChanges(remoteAnchor)；　　//　　//填充改變集合　　//　　foreach(FOO_RemoteChange change in remoteChanges)　　{//適配器負責完成ID映射　　Guid localId＝FOO_MapRemoteId(change)；　　//可以認為正在同步個人對象　　ItemSearcher searcher＝Person.GetSearcher(ctx)；　　searcher.Filters.Add(“PersonId＝@localld”)；　　searcher.Parameters[“PersonId”]＝localId；　　Person person＝searcher.FindOne()；　　//　　//適配器將遠程改變轉(zhuǎn)換成對個人對象的修改　　//作為其一部分，適配器甚至可對遠程對象的　　//項目級后端專用元數(shù)據(jù)作出改變?！　?/　　FOO_TransformRemoteToLocal(remoteChange，person)；}ctx.Update()；////保存新的錨位(這可以是復制品的擴展)//FOO_SaveRemoteAnchor()；////這是自從遠程知識未同步以來常規(guī)的WinFS API保存//remoteKnowledge＝ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge()；ctx.Update()；ctx.Close()；//　　//適配器回叫以處理應用程序狀態(tài)回叫　　//　　void FOO_OnEntitySaved(object sender，ChangeStatusEventArgs args)　　{　　 remoteAnchor.AcceptChange(args.ChangeStatus)；　　}]]></pre>4.API同步的方法在本發(fā)明的一個實施例中，通過由基于WinFS的硬件/軟件接口系統(tǒng)所公開的同步API，可以實現(xiàn)WinFS存儲和非WinFS存儲之間的同步。
在一個實施例中，要求所有同步適配器實現(xiàn)同步適配器API、由API管理的公共語言運行庫(CLR)，以便它們可以被一致使用、啟動和控制。所述適配器API提供·用于隨著硬件/軟件接口系統(tǒng)同步框架的寄存適配器的標準機制。
·用于適配器表示它們的性能和啟動所述適配器所需的配置信息的類型的標準機制。
·用于將啟動信息傳遞給所述適配器的標準機制。
·用于適配器將過程狀態(tài)報告回調(diào)用應用的應用的機制。
·報告在同步期間發(fā)生的任何錯誤的機制。
·請求正在進行的同步操作的取消的機制。
根據(jù)情況的需要，存在兩種可能的用于適配器的處理模型。所述適配器可以在與調(diào)用應用的應用相同的處理空間中或者全部在它本身單獨的處理中執(zhí)行。為了在其自己單獨的處理中執(zhí)行，所述適配器規(guī)定了其自己的工廠(factory)類，所述工廠類被用于例示所述適配器。所述工廠可以在與調(diào)用應用相同的處理中返回所述適配器的實例，或者在不同的Microsoft公共語言例程應用范圍或處理中返回所述適配器的遠程實例。默認的工廠實現(xiàn)被提供有在相同處理中哪個例示所述適配器。實際上，許多適配器將在與調(diào)用應用相同的處理中運行。出于以下原因中的一個或兩個，通常要求有處理模型的輸出
·安全目的。所述適配器必須在某個處理或服務的過程空間中運行。
·所述適配器必須處理來自其它源的請求——例如，收入網(wǎng)絡(luò)請求——除了處理來自調(diào)用應用的請求之外。
參見圖37，本發(fā)明的一個實施例假設(shè)了一個簡單的適配器，它不知道如何計算狀態(tài)或者如何交換其相關(guān)元數(shù)據(jù)。在這個實施例中，就想要同步的數(shù)據(jù)源而言，首先，在步驟3702，確定自它與所述數(shù)據(jù)源最后同步開始哪些改變已經(jīng)發(fā)生，通過所述復制品實現(xiàn)同步，并且然后所述復制品基于其當前狀態(tài)信息傳輸自這個最后的同步開始已經(jīng)發(fā)生的遞增的改變，并且這種當前狀態(tài)信息和遞增的改變通過所述適配器傳輸給所述數(shù)據(jù)源。在步驟3704，所述適配器，一旦在之前步驟中接收到來自所述復制品的改變，就盡可能多地實現(xiàn)對數(shù)據(jù)源的改變，跟蹤哪些改變成功了并且哪些失敗了，并且將所述成功和失敗信息傳輸回(所述復制品的)WinFS。在步驟3706，所述復制品(WinFS)的硬件/軟件接口系統(tǒng)一旦從所述復制品中接收到成功和失敗信息，就為所述數(shù)據(jù)源計算新的狀態(tài)信息，存儲這種信息以供將來由其復制品使用，并且將這種新的狀態(tài)傳輸回所述數(shù)據(jù)源，也就是，傳輸給用于存儲的適配器并且以后由所述適配器使用。
D.同步模式的附加方面下面是用于本發(fā)明的各個實施例的同步模式的附加(或更特殊的)方面。
·每一復制品是來自整個數(shù)據(jù)存儲的數(shù)據(jù)的定義的同步子集—具有多個實例的一段數(shù)據(jù)。
·沖突分解政策由每一復制品(以及適配器/數(shù)據(jù)源組合)個別地處理—即，每一復制品能夠基于其自己的標準和沖突分解模式來分解沖突。
此外，盡管數(shù)據(jù)存儲的每一實例的差異可獲得并導致附加的將來的沖突，然而更新的狀態(tài)信息中反映的遞增且順序的沖突枚舉對于接收該更新的狀態(tài)信息的其他復制品是不可見的。
·在同步模式的根上，是具有定義具有唯一ID的根文件夾(事實上，是根項目)的基礎(chǔ)類型的復制品，ID用于同步它是其成員的共同體，并且任何過濾器和其它元素對于特定復制品都是必須或期望的。
·每一復制品的“映射”被維持在所述復制品中，并且因而，用于任何特定復制品的映射被限定在這個復制品知道的其它復制品上。雖然這種映射可以只包括整個同步共同體的子集，但是通過公共地共享的復制品，所述復制品的改變將仍被傳播給整個同步共同體(盡管任何特定的復制品不知道與未知的復制品公共地共享哪些其他復制品)。
·同步模式包括對所有復制品可用的多個預定義的沖突處理器，以及用于用戶/開發(fā)者定義的自定義沖突處理器的能力。模式也可包括三個特殊的“沖突分解器”(a)沖突“過濾器”，它基于例如(i)當同一改變單元在兩個地方改變時如何處理，(ii)當改變單元在一個地方改變而在另一地方刪除時如何處理，以及(iii)當兩個不同的改變單元在兩個不同的位置具有同一名字時如何處理，來以不同的方法分解沖突；(b)沖突“處理器列表”，其中列表的每一元素指定了在沖突被成功分解之前要按順序嘗試的一系列行動；以及(c)“什么也不做”日志，它跟蹤沖突，但是在沒有用戶干預的情況下不采取進一步的行動。
·同步模式和復制品的使用允許真正的分布式對等多標準同步共同體。還有，不存在同步共同體類型，但是同步共同體簡單地作為復制品本身的共同體字段中的一個值存在。
·每一復制品具有其自己的元數(shù)據(jù)，以便跟蹤遞增的改變枚舉并且存儲同步共同體中已知的其它復制品的狀態(tài)信息。
·改變單元具有其自己的元數(shù)據(jù)，包括版本，包括伙伴關(guān)鍵字加上伙伴改變號；每一改變單元的項目/擴展/關(guān)系版本；與復制品已經(jīng)從同步共同體中看到的/接收到的改變有關(guān)的知識；GUID和本地ID配置；以及被存儲在引用關(guān)系上的用于清除的GUID。
IV.結(jié)論如之前所示，本發(fā)明針對用于組織、搜索以及共享數(shù)據(jù)的存儲平臺。本發(fā)明的存儲平臺擴展并且擴大了現(xiàn)有文件系統(tǒng)和數(shù)據(jù)庫系統(tǒng)之外的數(shù)據(jù)存儲的概念，并且被設(shè)計為用于所有類型的數(shù)據(jù)的存儲，包括結(jié)構(gòu)化的、非結(jié)構(gòu)化的、或者半結(jié)構(gòu)化的數(shù)據(jù)例如關(guān)系(表列)數(shù)據(jù)、XML，以及一種被稱作項目的新形式的數(shù)據(jù)。通過其共同存儲函數(shù)和模式化的數(shù)據(jù)，本發(fā)明的存儲平臺允許用于客戶、知識工作者以及企業(yè)的更有效的應用開發(fā)。它提供了豐富的并且可擴展的應用編程接口，所述接口不僅可以使用其數(shù)據(jù)模型中固有的性能，而且包含并擴展了現(xiàn)有文件系統(tǒng)和數(shù)據(jù)庫訪問方法。可以理解，在不脫離其寬泛的發(fā)明概念的情況下，可以對以上所述的實施例進行的改變。因此，本發(fā)明并不限于所公開的特殊實施例，而是旨在由所附權(quán)利要求所規(guī)定的覆蓋本發(fā)明的精神和范圍內(nèi)的所有改變。
如根據(jù)以上所述變得很明顯的，本發(fā)明的各種系統(tǒng)、方法、以及方面的所有或者一部分可以以程序代碼(即，指令)的形式來體現(xiàn)。這種程序代碼可以被存儲在計算機可讀介質(zhì)上，例如磁的、電的或者光的存儲介質(zhì)，在非限定情況下包括軟盤、CD-ROM、CD-RW、DVD-ROM、DVD-RAM、磁帶、閃存、硬盤驅(qū)動器、或者其它機器可讀存儲介質(zhì)，其中當程序代碼被載入到機器例如計算機或服務器中并由機器執(zhí)行時，所述機器就變成用于實施本發(fā)明的裝置。本發(fā)明還可以以在一些傳輸介質(zhì)上被傳輸?shù)某绦虼a的形式來體現(xiàn)，在傳輸介質(zhì)上例如在電線或者電纜上、通過光纖、在網(wǎng)絡(luò)上，包括因特網(wǎng)或內(nèi)部網(wǎng)，或者通過任何其它形式的傳輸，其中，當程序代碼被接收并且被載入到機器例如計算機中并且由機器執(zhí)行時，所述機器就變成用于實施本發(fā)明的裝置。當在通用處理器上被實現(xiàn)時，所述程序代碼與處理器相結(jié)合，以便提供類似于特定邏輯電路的操作的唯一裝置。
權(quán)利要求
1.一種用于硬件/軟件接口系統(tǒng)(例如，WinFS)的存儲平臺系統(tǒng)，所述存儲平臺系統(tǒng)包括存儲平臺的多個實例；對所述硬件/軟件接口系統(tǒng)本機的同步子系統(tǒng)，它使所述系統(tǒng)同步所述存儲平臺的多個實例。
2.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述同步子系統(tǒng)在一同步操作中僅同步所述數(shù)據(jù)存儲的全部數(shù)據(jù)中的一個數(shù)據(jù)子集。
3.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述存儲平臺的第一實例是運行在具有所述同步子系統(tǒng)的硬件/軟件接口系統(tǒng)(例如，WinFS)上的復制品，并且所述存儲平臺的第二實例是運行在不具有所述同步子系統(tǒng)的硬件/軟件接口系統(tǒng)(例如，非WinFS)上的數(shù)據(jù)源。
4.如權(quán)利要求3所述的系統(tǒng)，其特征在于，所述復制品和所述數(shù)據(jù)源之間的同步通過一同步適配器來促進，所述同步適配器通過與所述復制品的硬件/軟件接口系統(tǒng)的應用編程接口(API)接口來虛擬化所述數(shù)據(jù)源。
5.如權(quán)利要求1所述的系統(tǒng)，其特征在于，第一對實例與第二對實例無關(guān)地同步改變，并且其中，所述第一對實例和所述第二對實例都是一公共同步共同體的一部分。
6.如權(quán)利要求1所述的系統(tǒng)，其特征在于，同步中的沖突基于預定義的可確定標準被自動檢測和分解。
7.如權(quán)利要求6所述的系統(tǒng)，其特征在于，某些所述沖突通過被記入日志以供終端用戶的手動分解來分解。
8.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述同步子系統(tǒng)跟蹤與一同步伙伴的先前的同步的狀態(tài)，并由此僅與該伙伴同步自從最后一次同步以來改變的改變(即，凈改變)。
9.一種用于同步硬件/軟件接口系統(tǒng)(例如，WinFS)的存儲平臺的多個實例的方法，所述方法包括將所述存儲平臺劃分成粒度的基本單元(例如，改變單元)；在每一改變單元的基礎(chǔ)上順序地枚舉改變并跟蹤所述改變；對于每一實例，跟蹤該實例的改變狀態(tài)，以及同步共同體中多個其它已知實例(同步伙伴)的改變狀態(tài)；以及對于同步，通過將特定實例的所枚舉的改變與該實例的改變狀態(tài)進行比較，來識別新改變。
10.如權(quán)利要求9所述的方法，其特征在于，第一實例，即復制品在直接支持基于項目的同步的硬件/軟件接口系統(tǒng)(WinFS)上例示，并且其中，第二實例，即數(shù)據(jù)源在不直接支持基于項目的同步的硬件/軟件接口系統(tǒng)(非WinFS)上例示，所述方法還包括使用一適配器經(jīng)由同步應用編程接口來虛擬化所述非WinFS實例。
11.如權(quán)利要求10所述的方法，其特征在于，還包括在改變單元粒度級上檢測同步?jīng)_突。
12.如權(quán)利要求10所述的方法，其特征在于，還包括實例報告改變應用的個別改變單元級上的成功、失敗和/或沖突(同步數(shù)據(jù))；以及應用程序(包括但不限于適配器和其它同步控制應用程序)使用同步數(shù)據(jù)來更新后端狀態(tài)。
13.一種用于將復制品與數(shù)據(jù)源(每一個都是一同步伙伴)同步的方法，其中，所述復制品和所述數(shù)據(jù)源都具有由每一同步伙伴維護的改變狀態(tài)信息，并且其中，所述數(shù)據(jù)源(非WinFS)使用一適配器來與所述復制品的硬件/軟件接口系統(tǒng)(WinFS)接口，所述方法包括所述復制品向所述適配器發(fā)送所述復制品的經(jīng)更新的狀態(tài)信息，所述經(jīng)更新的狀態(tài)信息基于所述數(shù)據(jù)源的最后一個狀態(tài)信息反映了自從如所述數(shù)據(jù)源的所述最后一個狀態(tài)信息中反映的最后一次同步以來作出的改變(“新改變”)；以及所述適配器在接收了所述復制品的所述經(jīng)更新的狀態(tài)信息以及所述新改變之后，對數(shù)據(jù)源實現(xiàn)盡可能多的改變，并在逐個改變單元的基礎(chǔ)上跟蹤每一改變的成功或失敗。
14.如權(quán)利要求13所述的方法，其特征在于，還包括所述適配器基于在逐個改變單元的基礎(chǔ)上每一改變的成功或失敗計算所述數(shù)據(jù)源的新狀態(tài)、儲存該新狀態(tài)信息、以及將該新狀態(tài)信息發(fā)送到所述復制品的硬件/軟件接口系統(tǒng)(WinFS)；所述復制品的硬件/軟件接口系統(tǒng)(WinFS)儲存所述數(shù)據(jù)源的所述新狀態(tài)信息，以供所述復制品將來使用。
15.如權(quán)利要求13所述的方法，其特征在于，還包括所述適配器在逐個改變單元的基礎(chǔ)上向所述復制品的硬件/軟件接口系統(tǒng)(WinFS)發(fā)送每一改變的成功或失?。凰鰪椭破返挠布?軟件接口系統(tǒng)(WinFS)基于在逐個改變單元的基礎(chǔ)上對所述數(shù)據(jù)源的每一改變的成功或失敗計算所述數(shù)據(jù)源的新狀態(tài)信息；所述復制品的硬件/軟件接口系統(tǒng)(WinFS)向所述適配器發(fā)送所述新狀態(tài)信息，并儲存所述新狀態(tài)信息以供所述復制品將來使用；以及所述適配器接收并儲存所述新狀態(tài)信息。
16.一種包括計算機可讀指令的計算機可讀介質(zhì)，所述計算機可讀指令用于硬件/軟件接口系統(tǒng)(例如，WinFS)上的存儲平臺系統(tǒng)，所述存儲系統(tǒng)包括用于同步存儲平臺的多個實例中的一本地實例的指令。
17.如權(quán)利要求16所述的系統(tǒng)，其特征在于，所述同步子系統(tǒng)在一同步操作中僅同步所述數(shù)據(jù)存儲的全部數(shù)據(jù)中的一個數(shù)據(jù)子集。
18.如權(quán)利要求16所述的計算機可讀指令，其特征在于，所述存儲平臺的第一實例是運行在具有同步子系統(tǒng)的硬件/軟件接口系統(tǒng)(例如，WinFS)上的復制品，并且所述存儲平臺的第二實例是運行在不具有同步子系統(tǒng)的硬件/軟件接口系統(tǒng)(例如，非WinFS)上的數(shù)據(jù)源。
19.如權(quán)利要求18所述的計算機可讀指令，其特征在于，所述復制品和所述數(shù)據(jù)源之間的同步通過一同步適配器來促進，所述同步適配器通過與所述第一實例的硬件/軟件接口系統(tǒng)的應用編程接口(API)接口來虛擬化所述第二實例。
20.如權(quán)利要求16所述的計算機可讀指令，其特征在于，第一對實例與第二對實例無關(guān)地同步改變，并且其中，第一對實例和第二對實例都是一公共同步共同體的一部分。
21.如權(quán)利要求16所述的計算機可讀指令，其特征在于，同步中的沖突基于預定義的可確定標準被自動檢測和分解。
22.如權(quán)利要求21所述的計算機可讀指令，其特征在于，某些所述沖突通過被記入日志以供終端用戶的手動分解來分解。
23.如權(quán)利要求16所述的計算機可讀指令，其特征在于，所述同步子系統(tǒng)跟蹤與一同步伙伴的先前的同步的狀態(tài)，并由此僅與該伙伴同步自從最后一次同步以來改變的改變單元(即，“凈改變”)。
24.一種包括計算機可讀指令的計算機可讀介質(zhì)，所述計算機可讀指令用于同步硬件/軟件接口系統(tǒng)的存儲平臺(例如，WinFS)的多個實例，所述計算機可讀指令包括指令，用于將所述存儲平臺劃分成粒度的基本單元(例如，改變單元)；在每一改變單元的基礎(chǔ)上順序地枚舉改變并跟蹤所述改變；對每一實例，跟蹤該實例的改變狀態(tài)，以及所述同步共同體中多個其它已知實例(同步伙伴)的改變狀態(tài)；以及對于同步，通過將一特定實例的所枚舉改變與該實例的改變狀態(tài)進行比較，來識別新改變。
25.如權(quán)利要求24所述的計算機可讀指令，其特征在于，還包括指令，其中，第一實例，即復制品在直接支持基于項目的同步的硬件/軟件接口系統(tǒng)(WinFS)上例示，并且其中，第二實例，即數(shù)據(jù)源在不直接支持基于項目的同步的硬件/軟件接口系統(tǒng)(非WinFS)上例示，所述方法還包括使用一適配器經(jīng)由同步應用編程接口來虛擬化所述非WinFS實例。
26.如權(quán)利要求25所述的計算機可讀指令，其特征在于，還包括在改變單元粒度級上檢測同步?jīng)_突。
27.如權(quán)利要求25所述的計算機可讀指令，其特征在于，還包括實例報告改變應用的個別改變單元級上的成功、失敗和/或沖突(同步數(shù)據(jù))；以及應用程序(包括但不限于適配器和其它同步控制應用程序)使用同步數(shù)據(jù)來更新后端狀態(tài)。
28.一種包括計算機可讀指令的計算機可讀介質(zhì)，所述計算機可讀指令用于將一復制品與一數(shù)據(jù)源(每一個都是一同步伙伴)同步，所述復制品和所述數(shù)據(jù)源都具有由每一同步伙伴維護的改變狀態(tài)信息，并且其中，所述數(shù)據(jù)源(非WinFS)使用一適配器來與所述復制品的硬件/軟件接口系統(tǒng)(WinFS)接口，所述計算機可讀指令包括所述復制品用于向所述適配器發(fā)送所述復制品的已更新狀態(tài)信息的指令，所述已更新狀態(tài)信息基于所述數(shù)據(jù)源的最后一個更新信息反映了如在所述數(shù)據(jù)源的最后一個狀態(tài)信息中反映的最后一次同步以來作出的改變(“新改變”)，使得所述適配器在接收到所述復制品的已更新狀態(tài)信息以及所述新改變之后，可對所述數(shù)據(jù)源實現(xiàn)盡可能多的改變，并在逐個改變單元的基礎(chǔ)上跟蹤每一改變的成功或失敗。
29.如權(quán)利要求28所述的計算機可讀指令，其特征在于，還包括指令，用于，倘若所述適配器基于在逐個改變單元的基礎(chǔ)上每一改變的成功或失敗計算了所述數(shù)據(jù)源的新狀態(tài)，并具有該新狀態(tài)信息并將該新狀態(tài)信息發(fā)送到所述復制品的硬件/軟件接口系統(tǒng)(WinFS)，則所述復制品的硬件/軟件接口系統(tǒng)(WinFS)儲存所述數(shù)據(jù)源的新狀態(tài)信息以供所述復制品將來使用。
30.如權(quán)利要求28所述的計算機可讀指令，其特征在于，所述適配器按改變單元的基礎(chǔ)向所述復制品的硬件/軟件接口系統(tǒng)(WinFS)改變單元上每一改變的成功或失敗，還包括指令，用于所述復制品的硬件/軟件接口系統(tǒng)(WinFS)基于在逐個改變單元的基礎(chǔ)上對所述數(shù)據(jù)源的每一改變的成功或失敗計算所述數(shù)據(jù)源的新狀態(tài)信息；所述復制品的硬件/軟件接口系統(tǒng)(WinFS)將所述新狀態(tài)信息發(fā)送到所述適配器，并儲存所述新狀態(tài)以供所述復制品將來使用，使得所述適配器能夠接收并儲存所述新狀態(tài)信息。
全文摘要
本發(fā)明的若干實施例采用了同步適配器來同步“WinFS”和非“WinFS”數(shù)據(jù)源(圖36，3622/3666)之間的信息。適配器的示例包括同步“WinFS”聯(lián)系人文件夾和非WinFS郵箱之間的地址簿信息(圖36，3642)的適配器。在這些實例中，適配器開發(fā)者可使用本發(fā)明所描述的“WinFS”同步核心服務API來訪問由“WinFS”(圖36，3612)同步平臺提供的服務，以開發(fā)“WinFS”(圖36，3612)模式和非“WinFS”數(shù)據(jù)源模式(圖36，3624)之間的模式變換代碼。另外，適配器開發(fā)者提供了用于與非“WinFS”數(shù)據(jù)源傳遞改變的協(xié)議支持。同步適配器(圖36，3662)通過使用同步控制器API來調(diào)用和控制，并使用該API(圖36，3652)來報告進展和錯誤。
文檔編號G06F17/00GK1739107SQ200480002216
公開日2006年2月22日 申請日期2004年7月29日 優(yōu)先權(quán)日2003年8月21日
發(fā)明者A·沙阿, D·A·沙阿, I·胡迪斯, L·諾維克, V·J·嘉弗瑞, W·C·吳, M·E·迪姆, E·G·謝帕德, 方黎江, J·李, M·B·泰勒 申請人:微軟公司