專利名稱：通過中介文件系統或設備同步計算機系統的系統和方法
技術領域：
本發明一般涉及同步，尤其涉及使用公用存儲平臺(例如，WinFS)、但通過一不同的中介文件系統應用程序編程接口(API)可訪問文件共享或其他存儲設備(例如，Win32文件共享或其它API可訪問存儲設備)在兩臺或多臺計算機之間同步，以支持數據共享、最終擁護漫游(包括但不限于漫游最終擁護概況及其等效物)和其它同步目的。
背景在最近十年中，單個盤的容量每年增長約百分之70(70％)。摩爾(Moore)法則精確地預測了在過去數年中中央處理單元(CPU)能力的驚人的增長。有線和無線技術已經提供了數量上巨大的連接和帶寬。假設當前趨勢持續，在數年內一般的膝上計算機將具有約萬億字節(TB)的存儲并包含數百萬個文件，而5千億字節(500GB)的驅動器成為常見的。
消費者使用他們的計算機主要用于通信和組織個人信息，不論它們是傳統的個人信息管理器(PIM)風格的數據或如數字音樂或照片那樣的媒體。數字內容的量和存儲原始字節的能力已經大量地增長；然而消費者可用于組織和統一此數據的方法卻跟不上步伐。知識工人花費大量時間來管理和共享信息，某些研究估計，知識工人花費15-25％的時間在與無效信息有關的活動上。另外研究估計，典型的知識工人每天約花費2.5小時搜索信息。
開發者與信息技術(IT)部門投資大量的時間與金錢來構建他們自己的用于公用存儲抽象的數據存儲，以呈現如人、地方、時間和事件等事項目。這不僅導致重復的工作，還形成公用數據的孤島，沒有共同搜索或共享那些數據的機制。僅考慮當今在運行Microsoft Windows操作系統的計算機上有多少地址簿。如電子郵件客戶端和個人財務程序那樣的許多應用程序保留各自的地址簿，且在每個那樣的程序分別維護的地址簿應用程序之間只有很少共享。因而，財務程序(如MicrosoftMoney)不與維護在電子郵件聯系人文件夾(如Microsoft Outlook中的聯系人文件夾)中的地址共享支付人的地址。確實，許多用戶具有多個設備，在這些設備之間和包括到如MSN和AOL等商業服務的手機電話號碼的各種附加來源之間應該在邏輯上同步它們的個人數據；然而共享文檔的協作大部分是通過將文檔附到電子郵件消息來達到的—這是手動的且低效的。
缺乏協作的一個原因是組織計算機系統中的信息的傳統方法集中在使用基于文件—文件夾—目錄的系統(“文件系統”)，來基于用于存儲文件的存儲介質的物理組織的抽象將多個文件組織到文件夾的目錄分層結構中。在1960年代開發的Multics操作系統被認為是在操作系統級上使用文件、文件夾和目錄來管理可存儲數據單元的先驅。具體說來，Multics在文件的分層結構中使用符號地址(從而引入文件路徑的概念)，其中文件的物理地址對用戶(應用程序和最終用戶)是不透明的。此文件系統完全不考慮任何單個文件的文件格式，且在文件中及文件之間的關系在操作系統級上被認為是無關的(即，與分層結構中文件的位置不同)。由于Multics的出現，在操作系統級上可存儲的數據被組織成文件、文件夾和目錄。這些文件一般包括放在由文件系統維護的一特定文件中的文件分層結構本身(“目錄”)。此目錄進而維護對應于該目錄中所有其它文件和那些文件在分層結構(這里指文件夾)中的節點位置的條目的列表。這是本領域中近40年的狀態。
然而，雖然提供了駐留在計算機的物理存儲系統中的信息的合理表示，但是文件系統是物理存儲系統的抽象，因而文件的利用需要在用戶處理什么(具有上下文、特征以及與其它單元的關系的單元)和操作系統提供什么(文件、文件夾和目錄)之間的間接(解釋)層。結果，用戶(應用程序和/或最終用戶)只好強制把信息單元放入文件系統結構，即使這樣做是低效的、不一致的、或不希望的。此外，現有的文件系統關于在各個文件中存儲的數據的結構知之甚少，因此，大多數信息在文件中保持封閉，只能被寫那些數據的應用程序訪問(和可理解)。因此，缺乏信息的模式描述和管理信息的機制，導致形成數據的豎井(silo)，只有很少數據能在各豎井之間共享。例如，許多個人計算機(PC)用戶具有5個以上各異的存儲，它們包含有關他們在某一層上交互的人的信息—如Outlook聯系人、在線賬戶地址、Windows地址簿、Quicken受款人和即時消息(IM)伙伴列表—因為組織文件向這些PC用戶提出重要的挑戰。由于大多數現有的文件系統利用嵌套的文件夾隱喻來組織文件和文件夾，因此當文件數量增加時，為維持靈活且有效的組織模式所必需的努力變得十分驚人。在這些情況下，具有單個文件的多重分類是非常有用的；然而使用現有文件系統中的硬和軟鏈接是麻煩且難以維護的。
過去已作了若干不成功的嘗試來克服文件系統的缺點。這些以前嘗試中的某一些已經涉及使用內容可定址的存儲器來提供可以通過內容而不是通過物理地址來訪問數據的機制。然而，這些努力被證明是不成功的，因而雖然內容可定址的存儲器對由如高速緩存和存儲器管理單元等設備的小規模使用被證明是有用的，但對如物理存儲介質等設備的大規模使用由于各種原因尚不可能，因此那樣的解決方案簡直不存在。已作出使用面向對象的數據庫(OODB)系統的其它嘗試，但是這些嘗試雖然帶有強烈的數據庫的特征，且良好的非文件表示，但在處理文件表示方面并不有效，并不能重現在硬件/軟件接口系統級上基于分層結構的文件及文件夾的速度、效率和簡單性。諸如試圖使用SmallTalk(和其它派生方法)的其它嘗試在處理文件和非文件表示方面被證明相當有效，但缺乏有效地組織和利用在各種數據文件之間存在的關系所必需的數據庫特征，因此那種系統的整體有效性是不可接受的。使用BeOS(和其它那樣操作系統研究)的又一種嘗試盡管能夠勝任適當地表示文件的同時又提供某些必要的數據庫特征，在處理非文件的表示上被證明是不夠的，這是傳統文件系統同樣的核心缺點。
數據庫技術是存在類似挑戰的另一專業領域。例如，雖然關系型數據庫模型已取得很大的商業上的成功，實際上獨立軟件分銷商(ISV)一般運用了關系型數據庫軟件產品(如Microsoft SQL Server)中可得到的功能一小部分。相反，應用程序與那樣產品的大多數交互是以簡單的“gets”和“puts”的形式。對此雖然有若干容易明白的原因(如作為平臺或數據庫的不可知)，一個常被忽略的關鍵的原因是數據庫沒有必要提供主要商業應用程序分銷商確實需要的精確抽象。例如，雖然真是世界具有如“客戶”或“訂單”等“項目”的概念(以及訂單的嵌入的“行式項目”作為其中的項目和項目本身)，而關系型數據庫只在表和行的方面來談論。結果，雖然應用程序可能希望具有在項目級上的一致性、鎖定、安全和/或觸發器的方面(只列出一些)，通常數據庫只在表/行級上提供這些特征。盡管若每個項目映射到數據庫某個表的單個行也能工作得很好，但在帶多個行式項目的訂單的情況下，存在一個項目實際上要映射到多個表的原因，且在此情況下，單個關系型數據庫系統不能確切地提供正確的抽象。因此，應用程序必須在數據庫的頂層構建邏輯以提供這些基本抽象。換言之，基本關系模型不提供在其上容易開發高級應用程序的存儲數據的足夠平臺，因為基本關系模型需要在應用程序和存儲系統之間的間接層，其中只在某些情況的應用程序中可以看到數據的語義結構。盡管某些數據庫分銷商正將高級功能構建到他們的產品中(如提供對象關系能力，新的組織模型等)，至今尚沒有哪個提供需要的全面解決方案，其中真正的全面解決方案是為有用的域抽象(如“個人”、“位置”、“事件”等)提供有用的數據模型抽象(如“項目”、“擴展”、“關系”等)的解決方案。
考慮到現有數據存儲和數據庫技術中的上述缺點，需要一種新的存儲平臺，它提供了一種改進的能力以便組織、搜索和共享計算機系統中的所有類型的數據-一種存儲平臺，它在現有的文件系統和數據庫系統之外擴展和擴大了數據平臺，并且被設計為存儲所有類型的數據。2003年8月21日提交的，名為“STORAGEPLATFORM FOR ORGANIZING，SEARCHING，AND SHARING DATA(用于組織、搜索和共享數據的存儲平臺)”的美國專利申請第10/66,646號(代理案卷號MSFT-2734)中揭示的發明滿足這一需求。用于該存儲平臺(包括沖突分解方法)的同步服務也在由2003年10月24日提交的，名為“SYSTEMS AND METHODSFOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATIONSERVICES FOR UNITS OF INFORMATION MANAGEABLE BY AHARDWARE/SOFTWARE INTERFACE SYSTEM(用于向可由硬件/軟件接口系統管理的信息單元提供關系和分層同步服務的系統和方法)”的美國專利申請第10/646,646(代理案卷號MSFT-2745)，以及2004年6月30日提交的，名為“SYSTEMS AND METHODS FOR PROVIDING CONFLICT HANDLING FORPEER-TO-PEER SYNCHRONIZATION OF UNITS OF INFORMATIONMANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM(用于為可由硬件/軟件接口系統管理的信息單元的對等同步提供沖突處理的系統和方法)”的美國專利申請第(未分配)號(代理案卷號MSFT-2854/306955.01)所揭示的發明中提供。
當然，最初采用這些相關專利申請中描述的新存儲平臺，具有包括各種個別計算機系統的同步網絡的企業將具有一種混合，其中某些個別計算機系統將使用新存儲平臺，而其它個別計算機系統將繼續使用傳統存儲平臺。因此，使用新存儲平臺的兩臺計算機系統(“客戶機”)可能有必要通過使用傳統平臺的計算機系統(“中介”)同步。例如，某些客戶機可能使用諸如漫游擁護概況(RUP)或具有客戶機方高速緩存(CSC)的文件夾重定向等軟件在傳統漫游服務中登記。由于用于這些傳統存儲平臺的傳統漫游軟件不支持用于新存儲平臺的漫游數據，因此用于新存儲平臺的新漫游服務是必需的。本發明的各實施例針對用于通過中介的客戶機同步的系統和方法。
概述下面的概述提供了以前面通過參考所結合的相關發明(“相關發明”)為背景說明的本發明的各個方面的總結。這個概述不旨在提供本發明的所有重要方面的無遺漏的說明，也不是對本發明的范圍的限定。而是，這個概述旨在作為下面的詳細說明和附圖的介紹。
相關發明共同地涉及用于組織、搜索和共享數據的存儲平臺，所述存儲平臺在現有文件系統和數據庫系統之外擴展和擴大了數據存儲的概念。這個存儲平臺被設計為存儲所有類型的數據，包括結構化的、非結構化的、或半結構化的數據。
該存儲平臺包括在數據庫引擎上實現的數據存儲。所述數據庫引擎包括具有對象相關擴展的關系型數據庫引擎。所述的數據存儲實現了一種數據模型，它支持數據的組織、搜索、共享、同步和安全。以多種模式(schema)聲明了數據的具體類型，并且該平臺提供了一種機制，它擴展模式的設置以便定義新的數據類型(主要是，由所述模式提供的基本類型的子類型)。一種同步功能有助于在用戶或系統間共享數據。提供了文件系統類的功能，它允許所述數據存儲與現有的文件系統的互操作性，而不存在這種傳統文件系統的限制。一種改變跟蹤機制提供了跟蹤數據存儲的改變的能力。該存儲平臺還包括一組應用程序接口，它們使得應用程序能夠訪問所述存儲平臺上述的所有功能，并且能夠訪問以模式聲明的數據。
由所述數據存儲實現的數據模型以項目、元素和關系定義了數據存儲的單元。項目是在數據存儲中可存儲的數據的單元，并且可以包括一個或多個元素和關系。元素是類型的實例，包括一個或多個字段(此處也被稱為屬性)。關系是兩個項目之間的連接。(如此處所使用的，這些以及其它特定的術語可以被大寫，以便將它們從附近所使用的其它術語分離，然而，并不是旨在區別對待被大寫的術語例如“Item”和不被大寫時的同一個術語，例如“item”，并且不應假設或暗示這種區別。)該計算機系統還包括多個項目，其中每個項目包括一可由硬件/軟件接口系統操作的離散的可存儲的信息單元；多個項目文件夾，它們構成了所述項目的組織結構；以及用于操作多個項目的硬件/軟件接口系統，并且其中每個項目屬于至少一個項目文件夾，并且可以屬于多于一個的項目文件夾。
與從持久存儲中導出相反，項目或某些項目屬性值可以被動態地計算。換言之，所述硬件/軟件接口系統不需要項目被存儲，并且支持某些操作，諸如枚舉項目的當前設置的功能，或是給出項目在存儲平臺上的標識符(在描述應用編程接口或API的部分中被更完整地說明)而檢索項目的能力—例如，項目可以是蜂窩電話的當前位置，或從溫度傳感器讀到的溫度。所述硬件/軟件接口系統可以處理多個項目，并且還可以包括可由所述硬件/軟件接口系統管理的多個關系互連的項目。
用于該計算機系統的硬件/軟件接口系統還包括核心模式，以便定義所述硬件/軟件接口系統所理解，并且可以一種預先確定的和可預知的方式直接進行處理的一組核心項目。為了處理多個項目，所述計算機系統將項目與多個關系互連，并且在硬件/軟件接口系統層上管理所述關系。
該存儲平臺的API為在存儲平臺模式組中定義的每個項目、項目擴展和關系提供了數據類。此外，應用編程接口提供了一組框架類，它們為所述數據類定義了一組公共行為，并且與數據類一起為存儲平臺API提供了基本的編程模型。所述存儲平臺API提供了簡化的查詢模型，它以將應用程序員從底層數據庫引擎的查詢語言的細節隔離開的方式，使得應用程序員能夠形成基于數據存儲中的項目的各種屬性的查詢。存儲平臺API還收集由應用程序對項目做出的改變，并且然后將它們組織到實現所述數據存儲的數據庫引擎(或任何種類的存儲引擎)所需的正確更新中。這使得應用程序員能夠對在記憶中項目進行改變，而將數據存儲更新的復雜細節留給API。
通過它的公共存儲基礎和被模式化的數據，本發明的存儲平臺能夠為消費者、知識工作者和企業作出更有效的應用程序開發。它提供了豐富的并且可擴展的應用編程接口，該接口不僅使得它的數據模型中所固有的功能可以使用，而且還包含并擴展了現有文件系統和數據庫的訪問方法。
作為相互關連的發明的這種延及全部的結構(在詳細描述的第II節中詳細描述)的一部分，某些相關發明特別地針對同步API(在詳細描述的第III節中詳細描述)，它進而描述了該存儲平臺的廣泛的同步能力。可以預期本發明的若干實施例將與這些同步能力結合，以處理在對等同步過程中引發的沖突。正確和有效地處理沖突的能力最小化了數據丟失，同時保留了較好的可用性并減少了同步過程中對用戶干預的需求。為此，詳細描述的第III節也包括相關發明的各實施例的詳細描述，這些相關發明針對用于處理包括但不限于相關發明的存儲平臺的同步系統的對等同步系統中的沖突的系統和方法。
鑒于以上內容，本發明的各實施例針對用于同步使用公用存儲平臺(例如，相關發明的新存儲平臺)的兩臺客戶機，以通過不使用同一公用存儲平臺(例如，作為替代，使用本身不支持新存儲平臺的同步的傳統存儲平臺)的中介來同步。總體上，本發明的各實施例采用了使用中介的現有能力來同步數據，但是其中保存了客戶機的數據結構的方法。各實施例使用了“適配器”使得客戶機能夠與中介交互，其中，所述適配器有效地補償了中介的無力，以保存客戶機的新存儲平臺固有的數據結構元素。本發明的各實施例針對將數據從客戶機上傳同步(upload-sync)到中介，以及將數據從中介下載同步(download-sync)到客戶機。另外，某些實施例還針對中介上的數據的壓縮。
通過閱讀以下本發明的詳細描述和附圖，可以清楚本發明自身以及與相關發明相結合的具體特征和優點。
附圖的簡要說明當結合所附的附圖進行閱讀時，可以更好地理解上面的摘要以及下面對本發明的詳細說明。出于說明本發明的目的，在附圖中示出了本發明的各個方面的示例性實施例；然而，本發明不限于所公開的具體方法和手段。在附圖中

圖1是表示本發明的方面可以被結合在其內的計算機系統的方框圖；圖2是一個方框圖，示出了被分為3個組件組的計算機系統硬件組件、硬件/軟件系統接口組件和應用程序組件；圖2A示出了用于被分組到基于文件的操作系統中的目錄內的文件夾中的文件的傳統的基于樹的分層結構；
圖3是示出了一個存儲平臺的方框圖；圖4示出了項目、項目文件夾和種類之間的結構化的關系；圖5A是示出了項目的結構的方框圖；圖5B是示出了圖5A的項目的復雜屬性類型的方框圖；圖5C是示出了“Location(位置)”項目的方框圖，其中“位置”項目的復雜類型被進一步說明(明確地被列出)；圖6A示出了一個作為基礎模式中的項目的子類型的項目；圖6B是示出了圖6A的子類型項目的方框圖，其中明確地列出了它的繼承的類型(除了它的直接屬性之外)；圖7是示出了基本模式的方框圖，該基本模式包括它的兩個頂層類類型，項目和屬性基礎，以及從其得出的附加基礎模式類型；圖8A是示出了核心模式中的項目的方框圖；圖8B是示出了核心模式中的屬性類型的方框圖；圖9是一個方框圖，示出了項目文件夾、它的成員項目以及項目文件夾和它的成員項目之間的互連關系；圖10是一個方框圖，示出了種類(它本身也是一個項目)、它的成員項目以及種類和它的成員項目之間的互連關系；圖11是示出了存儲平臺的數據模型的引用類型層次的圖；圖12是示出了關系是如何被分類的圖；圖13是示出了通知機制的圖；圖14是示出了一個例子的圖，其中兩個事務都向同一個B樹中插入新的記錄；圖15示出了數據改變檢測處理；圖16示出了示例性的目錄樹；圖17示出了一個例子，其中現有的基于目錄的文件系統的文件夾被移動到所述的存儲平臺數據存儲中；圖18示出了容納文件夾的概念；圖19示出了存儲平臺API的基本體系結構；圖20示意性地表示了存儲平臺API棧的各個組件；圖21A是示例的聯系人項目模式的圖形表示；圖21B是圖21A的示例的聯系人項目模式的元件的圖形表示；圖22示出了存儲平臺API的運行時框架；
圖23示出了“FindAll”操作的執行；圖24示出了這樣的處理，通過該處理從存儲平臺模式生成存儲平臺API類；圖25示出了這樣的模式，文件(File)API基于該模式；圖26是示出了用于數據安全目的的訪問掩碼格式的示意圖；圖27(部分a、b、c)給出了被從現有的安全區域內劃分出來的一個新的被相同地保護的安全區域；圖28是示出了項目搜索視圖的概念的示意圖；圖29是示出了示例的項目分層的示意圖；圖30A示出了作為管道的接口“接口1”，第一和第二編碼段通過該接口通信；圖30B示出了一個接口，該接口包括接口對象I1和I2，它使得系統的第一和第二編碼段能夠通過介質M通信；圖31A示出了由接口“接口1”提供的功能可以被如何劃分，以便將接口的通信轉換到多個接口“接口1A”、“接口1B”、“接口1C”；圖31B示出了由I1提供的功能可以被如何劃分到多個接口I1A、I1B、I1C；圖32A示出了一種情況，其中無意義的參數precision可以被忽略或被以任意的參數替換；圖32B示出了一種情況，其中接口被替代接口所替換，所述替代接口被指定用于忽略或向接口添加參數；圖33A示出了一種情況，其中第一和第二編碼段被合并到包含它們兩者的模塊中；圖33B示出了一種情況，其中接口的一部分或全部可以被嵌入地寫入另一個接口中，以便形成被合并的接口；圖34A示出了中間設備的一塊或多塊如何可以轉換第一接口上的通信以便使它們符合一個或多個不同的接口；圖34B示出了編碼段如何能夠與接口一起引入以便接收來自一個接口的通信并將所述功能傳輸給第二和第三接口；圖35A示出了即時編譯器(JIT)如何可以將來自一個編碼段的通信轉換到另一個編碼段；圖35B示出了用于動態重寫一個或多個接口的JIT方法，它可以被應用于動態因素或否則改變所述接口；
圖36示出了公共數據存儲和組件的3個例子以便使它們同步；以及圖37示出了包括相關發明的系統，假定了不知道狀態如何被計算或其相關聯的元數據如何被交換的簡單適配器；圖38A-D示出了如何使用順序改變枚舉方法來跟蹤、枚舉和同步改變，以強調對改變的期望和解決方案；圖39A示出了沖突處理管道；圖39B所示是圖39A所示的管道的邏輯遍歷的流程圖；以及圖40所示是其中沖突項目與目標項目的副本一起記入日志的示例的框圖；圖41所示是其中兩臺客戶機必須通過中介同步的情形的框圖；圖42所示是客戶機通過STI適配器向中介發送改變數據(“發送同步”操作)的步驟的流程圖；圖43所示是客戶機通過STI適配器從中介接收改變數據(“接收同步”操作)的步驟的流程圖；以及圖44所示是STI適配器(即，與可進行發送同步和接收同步兩者的客戶機相關聯的STI適配器)對中介上的共同體文件夾中的數據執行壓縮操作(“壓縮”操作)的步驟的流程圖。
詳細描述I.引言本發明的主題用細節來描述，以滿足法定的要求。然而，該描述本身不試圖限制本專利的范圍。相反，本發明者設想，要求保護的主題也能以其它方式實施，以結合其它當前和未來的技術包括類似于本說明描述的不同的步驟或步驟的組合。此外，雖然術語“步驟”在這里可用于意味著所采用的方法的不同元素，然而該術語不能被解釋為在這里揭示的各步驟之間隱含特定的次序，除非明確地描述了各個步驟的次序。
A.示例性計算環境本發明的許多實施例可在計算機上執行。圖1和下面討論旨在提供其中實現本發明的合適計算環境的簡要描述。雖然不是必需，本發明的諸方面能以諸如由如客戶工作站或服務器的計算機上執行的程序模塊的計算機可執行指令的一般上下文中描述。一般而言，程序模塊包括例程、程序、對象、組件、數據結構等，它們執行特定任務或實現特定抽象數據類型。此外，本發明可用其它計算機系統配置實現，包括手持設備、多處理器系統、基于微處理器的系統或可編程消費者電子設備、網絡PC、小型機、大型機等。本發明還能在分布式計算環境中實現，其中任務由通過通信網絡鏈接的遠程處理設備完成。在分布式計算環境中，程序模塊能位于本地或遠程存儲器存儲設備中。
如圖1所示，示例性通用計算系統包括傳統的個人計算機20等，它包括處理單元21、系統存儲器22和將包括系統存儲器的各種系統組件耦合到處理單元21的系統總線23。系統總線23可以是若干種總線結構的任一種，包括存儲總線或存儲控制器、外圍總線、以及使用各種總線體系結構的任一種的局部總線。系統存儲器包括只讀存儲器(ROM)24和隨機訪問存儲器(RAM)25。基本輸入/輸出系統26(BIOS)包含如在啟動時幫助在個人計算機20的諸元件之間傳輸信息的基本例程，存儲在ROM 24中。個人計算機20還可包括讀寫硬盤(未示出)的硬盤驅動器27、讀寫可移動磁盤29的磁盤驅動器28、讀寫如CDROM或其它光介質的可移動光盤29的光盤驅動器30。硬盤驅動器27、磁盤驅動器28和光盤驅動器30分別通過硬盤驅動器接口32、磁盤驅動器接口33和光盤驅動器接口34連接系統總線23。驅動器及其相關的計算機可讀介質為個人計算機20提供計算機可讀指令、數據結構、程序模塊和其它數據的非易失存儲。雖然這里描述的示例性環境采用硬盤、可移動磁盤29和可移動光盤31，本專業技術人員理解，在示例性操作環境中也能使用可存儲能由計算機訪問的數據的其它類型計算機可讀介質，如盒式磁帶、閃存卡、數字視頻盤、Bernoulli盒式磁帶、隨機存取存儲器(RAM)、只讀存儲器(ROM)等。類似地，示例環境還可包括許多類型的監視設備，如熱敏和安全或火警系統，及其它信息來源。
若干程序模塊能存儲在硬盤、磁盤29、光盤31、ROM 24或RAM 25中，包括操作系統35、一個或多個應用程序36、其它程序模塊37和程序數據38。用戶能通過如鍵盤40和定位設備42等輸入設備將命令和信息輸入到個人計算機20。其它輸入設備(未示出)可包括麥克風、操縱桿、游戲墊、圓盤式衛星天線、掃描儀等。這里和其它輸入設備常通過耦合到系統總線的串行接口46連接到處理單元21，但也可通過其它接口連接，如并行口、游戲口或通用串行總線(USB)。監視器47或其它類型的顯示設備也通過如視頻適配器48的接口連接到系統總線23。除監視器47以外，個人計算機通常包括如話筒和打印機等其它外圍輸出設備(未示出)。圖1的示例系統還包括主適配器55、小型計算機系統接口(SCSI)總線56和連接到SCSI總線的外部存儲設備62。
個人計算機20可使用到如遠程計算機49的一個或多個遠程計算機的邏輯連接在網絡環境中操作。遠程計算機49可以是另一臺個人計算機、服務器、路由器、網絡PC、對等設備或其它公共網絡節點，并通常包括以上對個人計算機20描述的許多或所有元件，雖然在圖1中只示出存儲器存儲設備50。圖1中畫出的邏輯連接包括局域網(LAN)51和廣域網(WAN)52。那樣的網絡環境常見于辦公室、企業范圍計算機網絡、內聯網和因特網。
在LAN網絡環境中使用時，個人計算機20通過網絡接口或適配器53連接到LAN51。在WAN網絡環境中使用時，個人計算機20通常包括調制解調器54或用于通過如因特網等廣域網52建立通信的其它裝置。內置或外接的調制解調器54通過串行端口接口46連接系統總線23。在網絡環境中，相對個人計算機20畫出的程序模塊或其部分可存儲在遠程存儲器存儲設備中。可以理解，示出的網絡連接是示例性的，可使用在計算機之間建立通信鏈路的其它裝置。
如圖2的框圖所示，計算機系統200能被粗略地分成三個組件組硬件組件202、硬件/軟件接口系統組件204、以及應用程序組件206(在這里某些上下文中也稱為“用戶組件”或“軟件組件”)。
回到圖1，在計算機系統的各種實施例中，硬件組件202可包括中央處理單元(CPU)21、存儲器(ROM 24和RAM 25)、基本輸入/輸出系統(BIOS)26、以及各種輸入/輸出(I/O)設備，如鍵盤40、鼠標42、監視器47、和/或打印機(未示出)等。硬件組件202包括計算機系統200的基本物理基礎結構。
應用程序組件206包括各種軟件程序，包括但不限于編譯器、數據庫系統、文件處理程序、商業程序、視頻游戲等。應用程序提供計算機資源用于為各種用戶(機器、其它計算機系統和/或最終用戶)解決問題、提供解決方案和處理數據的手段。
硬件/軟件接口系統組件204包括(在某些實施例中可以僅包括)操作系統，在大多數情況后者本身包括外殼和內核。“操作系統”(OS)是啟動擔當在應用程序和計算機硬件之間的中介的特殊程序。硬件/軟件接口系統組件204還可包括虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物、Java虛擬機(JVM)或其功能等效物、或在計算機系統中的操作系統處或操作系統外的其它軟件組件。硬件/軟件接口系統的目的是提供用戶能在其中執行應用程序的環境。任何硬件/軟件接口系統的目標是使計算機系統便于使用，以及以有效的方式利用計算機硬件。
硬件/軟件接口系統一般在啟動時被加載到計算機系統，并隨后管理在計算機系統中所有應用程序。應用程序通過經由應用程序接口(API)請求服務來與硬件/軟件接口系統交互。某些應用程序使最終用戶能通過如命令語言或圖形用戶界面(GUI)與硬件/軟件接口系統交互。
硬件/軟件接口系統傳統上執行應用程序的各種服務。在多個程序同時運行的多任務硬件/軟件接口系統中，硬件/軟件接口系統確定哪些應用程序以什么次序運行，以及在切換到另一應用程序之前以供輪流對每個應用程允許多少時間。硬件/軟件接口系統還管理在多個應用程序之間內部存儲器的共享，并處理來往于如硬盤、打印機和撥號端口等附加的硬件設備的輸入和輸出。硬件/軟件接口系統還將有關操作狀態和可能發生的任何錯誤的消息發送到每個應用程序(在某些情況下到最終用戶)。硬件/軟件接口系統也能下傳(offload)批處理作業(如打印)的管理，使得啟動的應用程序能擺脫此工作并重新開始其它處理和/或操作。在能提供并行處理的計算機上，硬件/軟件接口系統還管理劃分程序，使得它同時在多個處理器上運行。
硬件/軟件接口系統外殼(這里簡稱“外殼”)是到硬件/軟件接口系統的交互式最終用戶界面。(外殼也稱為“命令解釋器”，或在一個操作系統中稱為“操作系統外殼”)。外殼是可直接由應用程序和/或最終用戶訪問的硬件/軟件接口系統的外層。與外殼相反，內核是直接與硬件組件交互的硬件/軟件接口系統的最內層。
雖然可構想本發明的許多實施例尤其適用于計算機化的系統，然而在本說明中不意味著將本發明限于那些實施例。相反，這里使用的術語“計算機系統”旨在包括能存儲和處理信息和/或能使用存儲的信息控制設備本身的行為或執行的任何和所有設備，而不管那些設備本質上是否為電子的、機械的、邏輯的、或虛擬的。
B.傳統的基于文件的存儲在當今大多數計算機系統中，“文件”是可存儲信息的單元，它可包括硬件/軟件接口系統和應用程序、數據集等。在所有現代硬件/軟件接口系統中(Windows，Unix，Linux，MacOS，虛擬機系統等)，文件是能由硬件/軟件接口系統處理的基本的分立(可存儲和可檢索)信息單元。文件組通常被組織成“文件夾”。在MicrosoftWindows、Macintosh OS和其它硬件/軟件接口系統中，文件夾是能作為單個信息單元被檢索、移動和處理的文件的集合。這些文件夾進而被組織成稱為“目錄”(在后面詳細討論)的基于樹形的分層結構排列。在如Dos、z/OS和大多數基于Unix的操作系統的其它硬件/軟件接口系統中，術語“目錄”和/或“文件夾”是可交替使用的，早期的Apple計算機系統(如Apple IIe)使用術語“類別”來代替目錄；然而在這里使用時所有這些術語被看成是同義語并可交替使用，并旨在還包括對分層信息存儲結構及其文件夾和文件組件的所有其它等價術語的引用。
傳統上，目錄(又名文件夾的目錄)是基于樹形的分層結構，其中文件被組合成文件夾，文件夾進而按包括目錄樹的相對節點位置排列。例如，如圖2A所示，基于DOS的文件系統的基本文件夾(或“根目錄”)212可包括多個文件夾214，其每一個可以還包括另外的文件夾(如特定文件夾的“子文件夾”)216，而這些的每一個又包括另外的文件夾218，直到無限。這些文件夾的每一個可具有一個或多個文件220，雖然在硬件/軟件接口系統級上，文件夾中的各個文件除了它們在樹形分層結構中的位置外沒有什么共同點。不奇怪，將文件組織到文件分層結構的方法間接地反映了用于存儲這些文件的典型存儲介質(如硬盤、軟盤、CD-ROM等)的物理組織。
除上述以外，每個文件夾是對其子文件夾和其目錄的容器—即，每個文件夾擁有其子文件夾和文件。例如，當文件夾被硬件/軟件接口系統刪除時，該文件夾的子文件夾和文件也被刪除(在每個子文件夾的情況下還遞歸地包括它自己的子文件夾和文件)。同樣，每個文件一般只由一個文件夾擁有，并且雖然文件能被拷貝且副本位于不同的文件夾，文件的副本本身是不同且獨立單元，它與原始文件無直接連接(如對原始文件的改變在硬件/軟件接口系統級上不反映到副本文件)。因此在這方面，文件和文件夾在本質上是“物理的”，因為文件夾類似于物理容器來處理，而文件作為這些容器中不同且獨立的物理元素來處理。
II.用于組織、搜索和共享數據的WINFS存儲平臺本發明結合通過引用結合于此的發明針對用于組織、搜索和共享數據的存儲平臺。本發明的存儲平臺擴展和拓寬了數據平臺，超越上文討論的文件系統及數據庫系統，并被設計成存儲所有類型的數據，包括稱為項目的新格式的數據。
A.詞匯表在這里及在權利要求書中使用的術語有下列意義·“項目”是能存儲硬件/軟件接口系統可訪問的信息的單元，不象簡單文件，它是具有由硬件/軟件接口系統外殼展現給最終用戶的所有對象共同支持的基本屬性集的對象。項目還具對所有項目類型共同支持的屬性和關系，包括允許引入新屬性和關系的特征(在下面詳細討論)。
·“操作系統”(OS)是扮作應用程序和計算機硬件之間的中介的特殊程序。在大多數情況下，操作系統包括外殼和內核。
·“硬件/軟件接口系統”是軟件、或硬件及軟件的組合，它起著在計算機系統的底層硬件組件和在計算機系統上執行的應用程序之間的接口的作用。硬件/軟件接口系統通常包括(在某些實施例中只包括)操作系統。硬件/軟件接口系統還能包括虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物，Java虛擬機(JVM)或其功能等效物、或在計算機系統的操作系統處或除操作系統外的其它軟件組件。硬件/軟件接口系統的目的是提供用戶能執行應用程序的環境。任何硬件/軟件接口系統的目標是使計算機系統便于使用，并以有效方式利用計算機硬件。
B.存儲平臺綜述參考圖3，存儲平臺300包括在數據庫引擎314上實現的數據存儲302。在一個實施例中，數據庫引擎包括帶有對象關系擴展的關系型數據庫引擎。在一個實施例中，關系型數據庫引擎314包括Microsoft SQL Server關系型數據庫引擎。數據存儲302實現支持數據的組織、搜索、共享、同步和安全的數據模型304。在如模式340等模式中描述特定的數據類型，并且存儲平臺300提供用于采用這些模式并用于擴展這些模式的工具346，這在后面詳述。
在數據存儲302中實現的改變跟蹤機制306提供跟蹤數據存儲的改變的能力。數據存儲302還提供安全能力308和升級/降級能力310，均在后文詳述。數據存儲302還提供一組應用程序接口312，以向利用該存儲平臺的其它存儲平臺組件和應用程序(如應用程序350a，350b和350c)展現數據存儲302的能力。本發明的存儲平臺還包括應用程序接口(API)322，使如應用程序350a，350b，和350c等應用程序能訪問存儲平臺的所有上述功能并能訪問在模式中描述的數據。應用程序能結合如OLE OB API 324和Microsoft Windows Win 32 API 326等其它API來使用存儲平臺API 322。
本發明的存儲平臺300能向應用程序提供各種服務，包括便于在用戶或系統之間共享數據的同步服務330。例如，同步服務330允許與具有與數據存儲302相同格式的其它數據存儲340的互操作，并訪問具有其它格式的數據存儲342。存儲平臺300還提供允許數據存儲302與如Windows NTFS文件系統318等現有文件系統的互操作的文件系統能力。在至少某些實施例中，存儲平臺320還能向應用程序提供另外的能力，以允許對數據起作用并允許與其它系統的交互。這些能力可體現在如Info Agent服務334和通知服務332等附加服務328的形式中，以及體現在其它實用程序336的形式中。
在至少某些實施例中，存儲平臺以計算機系統的硬件/軟件接口系統來實施，或形成其完整的一部分。例如而非限制，本發明的存儲平臺能用操作系統、虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物、或Java虛擬機(JVM)或其功能等效物來實施，或形成其完整的一部分。通過其公用的存儲基礎和模式化的數據，本發明的存儲平臺使消費者、知識工人和企業作能夠更有效地進行應用程序的開發。它提供了豐富和可擴展的編程表面區域，不僅可得到內含在其數據模型中的能力，還能包括和擴展現有文件系統和數據庫訪問方法。
在上述描述中及在各種附圖中，本發明的存儲平臺300可稱作“WinFs”。然而使用此名字指存儲平臺僅是為了描述方便，并不試圖作出如此限制。
C.數據模型本發明的存儲平臺300的數據存儲302實現一種數據模型，它支持對駐留在數據存儲中的數據的組織、搜索、共享、同步和安全。在本發明的數據模型中，“項目”是存儲信息的基本單元。該數據模型提供一種機制，用于聲明項目和項目的擴展、用于建立在項目之間的關系、以及用于將項目組織到項目文件夾和類別中，下面將更充分描述。
該數據模型依賴于兩個原語機制類型和關系。類型是提供支配類型的實例的形式的格式的結構。格式被表達成屬性的有序組。屬性是給定類型的值或一組值的名字。例如，USPostalAddress(美國郵政地址)類型具有屬性Street(街道)、City(城市)、Zip(郵編)、State(州)，其中Street、City和State是String類型，而Zip是Int32類型。Street可以是多值(即一組值)，允許地址對Street屬性具有一個以上值。系統定義能在其它類型構造中使用的某些原語類型，包括String、Binary、Boolean、Int16、Int32、Int64、Single、Double、Byte、DateTime、Decimal和GUID。可使用任何原語類型(帶有下面注釋的某些限制)或任何構造的類型來定義類型的屬性。例如，Location(位置)類型可定義具有屬性Coordinate(座標)和Addess(地址)，其中Address屬性是上述類型USPostalAddress。屬性也可以是必需的或可任選的。
關系可被聲明并表示兩個類型的實例集之間的映射。例如，可以有在Person(個人)類型和Location類型之間聲明的關系，稱為LivesAt(生活在)，它確定什么人生活在什么位置。關系具有名和兩個端點，即源端點和目標端點。關系也可具有屬性的有序集。源端點及目標端點均具有名和類型。例如，LivesAt關系具有稱為類型Person的Occupant(居民)的源和稱為類型Location的Dwelling(住房)的目標，且此外具有屬性StartDate(起始日期)和EndDate(終止日期)，表示該居民生活在該住房的時間段。注意，隨時間推移，個人能生活在多個住房，且住房可有多個居民，所以放置StartDate和EndDate信息的最可能的地方是在關系本身處。
關系定義了在由作為端點類型給出的類型約束的實例之間的映射。例如LivesAt關系不能是其中Automobile(汽車)是Occupant(居民)的關系，因為Automobile不是Person。
數據模型允許定義類型間的子類型-超類型關系。也稱為基本類型關系的子類型—超類系型關系以如下方式定義，若類型A是類型B的基本類型，則必須是B的每個實例也是A的實例的情況。另一種表達的方法是符合B的每個實例必須符合A。例如，若A具有String類型的屬性Name(名字)，而B具有Int16類型的屬性Age(年齡)，則得出，B的任何實例必須兼有Name和Age。類型的分層結構可被設想成帶有在根上的單個超類型的樹。根的分枝提供第一級子類型，該級分枝提供第二級子類型，如此等等，直到本身不再具有任何子類型的葉端(leaf-most)子類型。樹不限于統一深度，但不能包含任何回路。給定的類型可具有零個或許多子類型和零個或一個超類型。給定實例可最多符合一個類型以及該類型的超類型。換言之，對樹中任一級處給定的實例，該實例最多可符合該級上的一個子類型。如果一類型的實例必須也是該類型的子類型的實例，則該類型可說成是抽象。
1.項目項目是可存儲的信息的單元，不象簡單的文件，它是具有由存儲平臺向最終用戶或應用程序展現的所有對象共同支持的基本屬性集的對象。項目也具有所有項目類型共同支持的屬性和關系，包括如下所述允許引入新的屬性和關系的特征。
項目是公用操作的對象，如拷貝、刪除、移動、打開、打印、備份、恢復、復制等。項目是能被存儲和檢索的單元，且由存儲平臺處理的可存儲信息的所有形式作為項目、項目的屬性、或項目之間的關系存在，其每個在下面更詳細討論。
項目旨在表示顯示的且容易理解的數據單元，如聯系人(Contacts)、人(People)、服務(Services)、位置(Locations)、(各種類型的)文檔(Documents)等。圖5A是示出項目的結構的框圖。該項目的不合格的名是“Location”。該項目的合格名是“Core.Location”，它表明，此項目結構被定義成Core(核心)模式中的特定類型的項目(Core模式在下面詳細討論)。
Location項目具有多個屬性，包括EAddress(電子郵件地址)、MetropolitanRegion(都市地區)、Neighborhood(街坊)、和PostalAddress(郵政地址)。每個項目的特定類型屬性緊跟屬性名地表示，并用冒號(“”)與屬性名分開。在類型名的右邊，對該屬性類型允許的值的數量在方括號(“[]”)之間表示，其中冒號(“”)右邊的星號(“*”)表示未規定的和/或無限制的數量(“許多”)。冒號右邊的“1”表明最多一個值。冒號左邊的零(“0”)表明該屬性是可任選的(可以完全沒有值)。冒號左邊的“1”表明必須至少有一個值(該屬性是必須的)。Neighborhood和MetropolitanRegin均是“nvarchar”類型(或等效類型)，它是預定義的數據類型或“簡單類型”(這里用缺少大寫來表示)。然而EAddress和PostalAddress分別是類型EAddress和PostalAddress的已定義類型或“復雜類型”(這里用大寫標記)的屬性。復雜類型是從一個或多個簡單數據類型和/或從其它復雜類型導出的類型。一個項目的屬性的復雜類型還構成”嵌套元素“，因為復雜類型的細節嵌套入直接項目中以定義其屬性，而屬于這些復雜類型的信息用具有這些屬性的項目來維持(在該項目的邊界內，如后面討論)。類型的這些概念是眾知的，且容易被本專業技術人員理解。
圖5B是示出復雜屬性類型PostalAddress和EAddress的框圖。PostalAddress屬性類型定義，屬性類型PostalAddress的項目可期望有零個或一個City(城市)值、零個或一個Country Code(國家代碼)值、零個或一個MailStop(國家代碼)值、和任何數量(零到許多)PostalAddress類型等等。以此方式，定義了一項目中的特定屬性的數據的形狀。EAddress屬性類型如所示類似地定義。雖然這里在本申請中可任選地使用，表示在Location項目中復雜類型的另一方法是用其中列出的每個復雜類型的各個屬性得出該項目。圖5C是示出Location項目的框圖，在其中進一步描述其復雜類型。然而應該理解，在此圖5C中Location項目的另一種表示恰是對圖5A中示出的同一個項目。本發明的存儲平臺還允許子分類(subtyping)，從而一個屬性類能是另一個的子類型(其中一個屬性類繼承另一個父屬性類型的屬性)。
類似于但不同于屬性及它們的屬性類型，項目繼承性地表示其自己的Item(項目)類型，它也是子分類的主題。換言之，本發明的若干實施例中的存儲平臺允許一個項目是另一個項目的子類型(從而一個項目繼承另一個父項目的屬性)。此外，對本發明的各種實施例，每個項目是“Item”項目類型的子類型，后者是在基礎模式中找到的第一和基本的項目類型(基礎模式也在后面詳細討論)。圖6A示出一項目(在此實例中為Location項目)為在基礎模式中找到的Item項目類型的子類型。在此圖中，箭頭表示Location項目(如所有其它項目)是Item項目類型的子類型。作為從中導出所有其它項目的基本項目的Item項目類型具有若干如ItemId的重要屬性和各種時間標記，從而定義了操作系統中所有項目的標準屬性。在本圖中，Item項目類型的這些屬性被Location所繼承，并從而成為Location的屬性。
表示從Item項目類型繼承的Location項目中屬性的另一種方法是用來自其中列出的父項目的每個屬性類型的各個屬性得出Location。圖6B是示出Location項目的框圖，其中除了其直接屬性外描述其繼承的類型。應注意和理解，此項目是圖5A中示出的同一項目，雖然在本圖中，Location用所有其屬性示出，包括直接屬性(在本圖及圖5A中示出)和繼承屬性(在本圖中示出但未在圖5A中示出)(而在圖5A中，通過用箭頭示出Location項目是Item項目類型的子類型來引用這些屬性)。
項目是獨立的對象，因而若刪除一項目，也刪除項目的所有直接和繼承的屬性。類似地，當檢索一項目時，檢索的是該項目及其所有直接和繼承的屬性(包括屬于其復雜屬性類型的信息)。本發明的某些實施例可使人們能在檢索特定項目時請求屬性的子集；然而對許多那樣的實施例默認的是在檢索時向項目提供所有其直接和繼承的屬性。此外，項目的屬性也能通過添加新的屬性到該項目的類型的現有屬性而加以擴展。這些“擴展”其后是該項目的真實屬性，且該項目類型的子類型可自動地包括擴展屬性。
項目的“邊界”由其屬性(包括復雜屬性類型、擴展等)來表示。項目的邊界也表示在項目上執行的操作的限制，包括拷貝、刪除、移動、創建等。例如在本發明的若干實施例中，當拷貝一項目時，在該項目邊界之內的所有內容也被拷貝。對每個項目，邊界包括下列·項目的項目類型，且若該項目是另一項目的子類型(如在所有項目從基礎模式的單個項目和項目類型導出的本發明的若干實施例的情況下)，是任何適用的子類型信息(即屬于父項目類型的信息)。若要拷貝的原始項目是另一項目的子類型，該副本也能是該相同項目的子類型。
·項目的復雜類型屬性和擴展(如果有的話)。若原始項目具有復雜類型(原來的或擴展的)的屬性，副本也能具有相同的復雜類型。
·在“所有權關系”上的項目的記錄，即，本項目(“擁有項目”)擁有什么其它項目(“目錄項目”)的項目擁有列表。這特別關系到下面充分討論的項目文件夾和下面說到的所有項目必須至少屬于一個項目文件夾的規則。此外，關于嵌入項目(下列更充分討論)，一個嵌入項目被認為是其中嵌入如拷貝、刪除等操作的項目的一部分。
2.項目標識在全局項目空間中用ItemID唯一地標識項目。Base.Item類型定義了存儲該項目身份的類型GUID的字段ItemID。一項目必須在數據存儲中準確只有一個身份。
項目引用是包含定位和標識項目的信息的數據結構。在該數據模型中，定義名為ItemReference的抽象類型，從中導出所有項目引用類型。ItemReference(項目引用)類型定義了名為Resolve(解析)的虛擬方法。Resolve方法解析ItemReference并返回一項目。此方法被ItemReference的具體子類型所覆蓋，后者實現給定一引用時檢索項目的功能。調用Resolve方法作為存儲平臺API 322的一部分。
ItemIDReference(項目ID引用)是ItemReference的子類型。它定義了Locator(定位器)和ItemID字段。Locator字段命名(即標識)項目的域。它由能將Locator的值解析到項目域的定位器解析方法來處理。ItemID字段是ItemID類型。
ItemPathReference(項目路徑引用)是定義Locator和Path(路徑)字段的ItemReference的特殊化。Locator字段標識一項目域。它由能將Locator的值解析到項目域的定位器解析方法來處理。Path字段包含以由Locator提供的項目域為根的存儲平臺名字空間中的(相對)路徑。
不能在集合運算中使用此類引用。引用一般必須通過路徑解析過程來解析。存儲平臺API 322的Resolve方法提供此功能。
上面討論的引用形式通過圖11示出的引用類型分層結構表示。從這些類型繼承的另外引用類型能在模式中定義。它們能在關系聲明中用作目標字段的類型。
3.項目文件夾和類別如下面將更充分討論的，項目組能組織成稱為項目文件夾(不要與文件的文件夾混淆)的特殊項目。然而不象大多數文件系統，一個項目可屬于多個項目文件夾，使得當一個項目在一個項目文件夾中被訪問和修訂時，此修訂的項目隨后能直接從另一項目文件夾訪問。實質上，雖然對一個項目的訪問可從不同的項目文件夾發生，事實上真正訪問的是同一個項目。然而，一個項目文件夾不必擁有其所有成員項目，或簡單地結合其它文件夾共同擁有項目，使得一個項目文件夾的刪除不必要導致項目的刪除。然而在本發明的若干實施例中，一個項目必須至少屬于一個項目文件夾，使得如果特定項目的唯一文件夾被刪除，則對某些實施例，該項目被自動被刪除，或在另外實施例中，該項目自動地成為默認項目文件夾的成員(“TrashCan(垃圾箱)”文件夾在概念上類似于在各種基于文件和文件夾的系統中使用的類似名字文件夾。)如下面更充分討論的，項目也可屬于基于共同描述的特征的類別，特征如(a)項目類型(或類型)，(b)特定的直接或繼承的屬性(或屬性)，或(c)對應于項目屬性的特定值(或值)。例如，包括個人聯系人信息的特定屬性的項目可自動屬于聯系人(Contact)類別，具有聯系人信息屬性的任何項目看來也自動屬于此類別。同樣，具有“New York City(紐約市)”值的位置屬性的任何項目可自動屬于紐約市類別。
類別在概念上不同于項目文件夾之處在于，項目文件夾可包括互相無關的項目(即無共同的描述的特征)，而在類別中的每個項目具有對該類別描述的共同類型、屬性或值(“共同性”)，正是這個共同性形成對它與該類別中其它項目或那些項目之間的關系的基礎。此外，雖然在特定文件夾中的項目的成員資格基于該項目的任何特定方面不是強制的，然而對某些實施例，具有在分類上與一類別相關的共同性的所有項目在硬件/軟件接口系統級上可自動地成為該類別的成員。概念上，類別也能看作虛擬項目文件夾，其成員資格基于特定查詢(如在數據庫的上下文中)的結果，而滿足此查詢的條件(由類別的共同性確定)的項目應構成該類別的成員資格。
圖4示出在項目、項目文件夾和類別之間的結構關系。多個項目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可以不屬于任何類別(雖然這大部分不象在某些實施例中，其中具有任何屬性自動暗示類別中的成員資格，因此在那樣實施例中為了不是任何類別的成員，項目應完全地無特征)。與文件夾的分層結構相反，類別和項目文件夾均有更像如所示的有向圖的結構。在任何情況下，項目、項目文件夾和類別都是項目(盡管是不同的項目類型)。
與文件、文件夾和目錄相反，本發明的項目、項目文件夾和類別的特征在本質上不是“物理的”，因為它們不具有物理容器的概念上的等價性，因而項目可存在于一個以上那樣的位置。項目存在于一個以上項目文件位置以及被組織成類別的能力提供了在硬件/軟件接口級上增強和豐富程度的數據處理及存儲結構能力，超越了在本領域中當前可得到的能力。
4.模式a)基礎模式為了提供創建和使用項目的通用基礎，本發明的存儲平臺的各實施例包括建立用于創建和組織項目及屬性的概念性框架的基礎(Base)模式。基礎模式定義了某些特定類型的項目和屬性，以及從中進一步導出子類型的這些特定基本類型的特征。使用此基礎模式使程序員能在概念上將項目(及其各自的類型)與屬性(及其各自的類型)加以區別。此外，基礎模式列出所有項目可擁有的基本屬性集，因為所有項目(及其對應的項目類型)是從基礎模式的此基本項目(及其對應的項目類型)導出。
如圖7所示，對于本發明的若干實施例，基礎模式定義三個頂層類型Item(項目)、Extension(擴展)和PropertyBase(屬性基礎)。如圖所示，通過此基本“Item”項目類型的屬性定義了項目類型。相反，頂層屬性類型“PropertyBase”沒有預定義的屬性，僅是一個錨位(anchor)，從中導出所有其它屬性，并通過它所有導出的屬性類型互相聯系(共同從單個屬性類型導出)。Extension類型屬性定義該擴展擴展了哪個項目，并定義將一個擴展與另一個項目相區別的標識，因為一個項目可具有多個擴展。
ItemFolder(項目文件夾)是Item項目類型的子類型，除了從Item繼承的屬性外，它表征用于建立到其成員(如果有的話)的關系，盡管Identitykey(身份關鍵字)和Property(屬性)均是PropertyBase的子類型。CategoryRef(目錄引用)進而是IdentityKey的子類型。
b)核心模式本發明的存儲平臺的各種實施例還包括為頂層項目類型結構提供概念框架的核心(Core)模式。圖8A是示出核心模式中的項目的框圖，而圖8B是示出核心模式中屬性類型的框圖。在帶不同擴展名(*.com、*.exe、*.bat、*.sys等)的文件和在基于文件和文件夾系統中其它準則之間作出的區分是類似于核心模式的功能。在基于項目的硬件/軟件接口系統中，核心模式定義了一組核心項目類型，它們直接(按項目類型)或間接地(按項目子類型)將所有項目特征化成基于項目的硬件/軟件接口系統理解并能以預定或可預計的方式直接處理的一個或多個核心模式項目類型。預定的項目類型反映了在基于項目的硬件/軟件接口系統中最常用的項目，且因此通過理解這些包括核心模式的預定項目類型的基于項目的硬件/軟件接口系統獲取有效性級別。
在某些實施例中，核心模式是不可擴展的，即，沒有另外的類型可直接從基礎模式中的項目類型子分類，除非作為核心模式的一部分的特定的預定導出的項目類型。通過禁止對核心模式的擴展(即，通過禁止向核心模式添加新的項目)，存儲平臺托管核心模式項目類型的使用，因為每個后續的項目類型必須是核心模式項目類型的子類型。此結構允許在保持具有一組預定的核心項目類型的益處的同時在定義另外項目類型時有合理程度的靈活性。
參考圖8A，對本發明的各種實施例，由核心模式支持的特定項目類型可包括下列的一個或多個·Category(類別)此項目類型(及從中導出的子類型)的項目代表在基于項目的硬件/軟件接口系統中的有效類別。
·Commodity(物品)作為值的可標識事物的項目。
·Device(設備)具有支持信息處理能力的邏輯結構的項目。
·Document(文檔)具有不能由基于項目的硬件/軟件接口系統解釋而相反由對應于文檔類型的應用程序解釋的內容的項目。
·Event(事件)記錄環境中某些發生事件的項目。
·Location(位置)代表物理位置(如地理位置)的項目。
·Message(消息)在兩個或更多主體(下面定義)之間通信的項目。
·Principal(主體)具有除ItemId之外的至少一個肯定可驗證身份(如，個人、組織、組、家庭、作者、服務等的標識)的項目。
·Statement(語句)具有關于環境的特定信息的項目，包括但不限于政策、預訂、憑證等。
類似地參考圖8B，由核心模式支持的特定屬性類型可包括下列的一個或多個
·Certificate(證書)(從基礎模式中的基本PropertyBase類型導出)·PrincipalIdentityKey(主體身份關鍵字)(從基礎模式中的IdentityKey類型導出)·PostalAddress(郵政地址)(從基礎模式中Property類型導出)·RichText(多信息文本)(從基礎模式中Property類型導出)·EAddress(電子郵件地質)(從基礎模式中Property類型導出)·IdentitySecnrityPackage(身份安全包)(從基礎模式中Relationship類型導出)·RoleOccupancy(居民角色)(從基礎模式中Relationship類型導出)·BasicPresence(基礎存在)(從基礎模式中Relationship類型導出)這些項目和屬性按在圖8A和圖8B中列出的各自屬性進一步描述。
5.關系關系是二元關系，其中一個項目被指定為源，另一個被指定為目標。源項目和目標項目通過關系相聯系。源項目一般控制關系的生命周期。即，當源項目被刪除，項目之間的關系也被刪除。
關系被分類成包含(Containment)和引用(Reference)關系。包含關系控制目標項目的生命周期，而引用關系不提供任何生命周期管理語義。圖12示出關系分類的方式。
包含關系又被分類成持有(Holding)和嵌入(Embedding)關系。當對一個項目的所有持有關系被移除，該項目被刪除。持有關系通過引用計數機制控制目標。嵌入關系能夠對復合項目建模，并能被看作排他的持有關系。一個項目能是一個或多個持有關系的目標；但一個項目只能是一個嵌入關系的目標。作為嵌入關系的目標的項目不能是任一其它持有或嵌入關系的目標。
引用關系不控制目標項目的生命周期。它們可以是搖擺不定的—目標項目可以不存在。引用關系能用于在全局項目名字空間的任何處(即，包括遠程數據存儲)建模對項目的引用。
獲得一項目不自動取得某關系，應用程序必須明確地請求項目的關系。此外，修改關系不修改源或目標項目；類似地，添加關系不影響源/目標項目。
a)關系聲明顯式的關系類型用下列元素定義；·在Name(名字)屬性中指定關系名·下列之一的關系類型持有、嵌入、引用。這是在Type(類型)屬性中指定的。
·源和目標端點。每個端點指定所引用項目的名和類型。
·源端點字段一般是ItemID(項目ID)類型(未聲明)，而必須引用在與關系實例同一數據存儲中的項目。
·對持有和嵌入關系，目標端點字段必須是ItemIDReference(項目ID引用)類型，且它必須引用在與關系實例相同存儲中的項目。對引用關系，目標端點能是任何ItemReference(項目引用)類型，并能引用在其它存儲平臺數據存儲中的項目。
·能可任選地聲明標量或PropertyBase(屬性基礎)類型的一個或多個字段。這些字段能包含與該關系相關聯的數據。
·關系實例被存儲在全局關系表中。
·每個關系實例唯一地由組合(源ItemID、關系ID)標識。對所有源自給定項目的關系，在給定的源ItemID中關系ID是唯一的，而不管它們的類型。
源項目是關系的擁有者。而被指定為擁有者的項目控制關系的生命周期，關系本身和與它們相關的項目分開。存儲平臺API322提供用于展現與項目相關聯的關系的機制。
這里是一個關系聲明的例子。
<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>
這是引用關系的例子。若由源引用所引用的個人項目不存在，則不能創建該關系。而且若該個人項目被刪除，在個人和組織之間的關系實例也被刪除。然而若組織項目被刪除，關系不被刪除，而它是搖擺不定的。
b)持有關系持有關系用于基于目標項目的生命周期管理來對引用計數建模。
一個項目可以是用于對項目的零個或多個關系的源端點。不是嵌入項目的項目可以是在一個或多個持有關系中的目標項目。
目標端點引用類型必須是ItemIDReference，且它必須引用在與關系實例相同的存儲中的項目。
持有關系實施目標端點的生命周期管理。持有關系實例和作為目標的項目的創建是原子操作。可以創建將同一項目作為目標的另外的持有關系實例。當具有給定項目作為目標端點的最后一個持有關系實例被刪除時，該目標項目也被刪除。
在關系聲明中指定的端點項目的類型一般在創建該關系的實例時強制。在關系建立之后端點項目的類型不能改變。
持有關系在形成項目的名字空間中起著關鍵作用。它們包含“Name(名字)”屬性，它定義目標項目相對于源項目的名字。對所有源自給定項目的持有關系，相對名字是唯一的。從根項目開始到給定項目的相對名字的有序類表形成該項目的全名。
持有關系形成一有向非循環圖(DAG)。在創建持有關系時，系統確保不產生回路，從而確保項目的名字空間形成DAG。
雖然持有關系控制目標項目的生命周期，它不控制目標端點項目的操作的一致性。目標項目在操作上獨立于通過持有關系擁有它的項目。在作為持有關系的源的項目上的拷貝、移動、備份和其它操作不影響作為同一關系的目標的項目-例如，備份文件夾項目不自動地備份該文件夾中所有項目(FolderMember(文件夾成員)關系中的目標)。
下面是持有關系的例子<Relationship Name＝″FolderMembers″BaseType＝″Holding”>
<Source Name＝″Folder″ItemType＝″Base.Folder″/>
<Target Name＝″Item″ItemType＝″Base.Item″ReferenceType＝″ItemIDReference″/>
</Relationship>
FolderMember關系使文件夾的概念成為項目的類屬集合。
e)嵌入關系嵌入關系將目標項目的生命周期的排外控制的概念模型化。它們允許合成項目的概念。
嵌入關系實例和作為目標的項目的創建是原子操作。一個項目能是零個或多個嵌入關系的源。然而一個項目能是一個且僅是一個嵌入關系的目標。作為嵌入關系的目標的項目不能是持有關系的目標。
目標端點引用類型必須是ItemIDReference，且它必須引用在與關系實例相同數據存儲中的項目。
在關系聲明中指定的端點項目的類型一般在創建該關系的實例時強制。在關系建立之后端點的類型不能改變。
嵌入關系控制該目標端點的操作一致性。例如，串行化項目的操作可包括串行化所有源自該項目及所有其目標的所有嵌入關系；拷貝一項目也拷貝所有它的嵌入項目。
下面是示例聲明<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 storageplatformTypes.float″/>
</Relationship>
d)引用關系引用關系不控制它引用的項目的生命周期。尤其是，引用關系不保證目標的存在，也不保證目標的類型如關系聲明中指定的那樣。這意味著引用關系能是搖擺不定的。而且引用關系能引用在其它數據存儲中的項目。引用關系能看作類似于網頁上的鏈接的概念。
下面是引用關系說明的例子<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>
在目標的端點允許任何引用類型。參與引用關系的項目可以是任何項目類型。
引用關系用于對項目之間的大多數非生命周期管理關系建模。因為不強制目標的存在，引用關系便于對松散耦合的關系建模。引用關系能用于在其它存儲，包括在其它計算機上的存儲中的目標項目。
e)規則和約束下列附加規則和約束應用于關系·一個項目必須是(僅一個嵌入關系)或(一個或多個持有關系)的目標。一個例外是根項目。一個項目能是零個或多個引用關系的目標。
·作為嵌入關系目標的項目不能是持有關系的源。它能是引用關系的源。
·一個項目若是從文件升級，則不能是持有關系的源。它能是嵌入關系和引用關系的源。
·一個從文件升級的項目不能是嵌入關系的目標。
f)關系的排序在一至少個實施例中，本發明的存儲平臺支持關系的排序。通過在基本關系定義中名為“Order(排序)”的屬性完成排序。在Order字段中無唯一性約束。不保證帶有同一“Order”屬性值的關系的次序，然而保證，它們能排序在帶較低“Order”值的關系之后并在帶較高“Order”字段值的關系之前。
應用程序通過在在組合(SourceItemID，RelationshipID，Order)上排序得到默認次序的關系。源自給定項目的所有關系實例被排序成單個集合，而不管在集合中關系的類型。然而這保證，給定類型(如，FolderMembers(文件夾成員))的所有關系是給定項目的關系集合的已排序子集。
用于處理關系的數據存儲API312實現一組支持關系的排序的操作。引入下列術語幫助解釋那些操作
·RelFirst是有序集合中帶次序值OrdFirst的第一個關系；·RelLast是有序集合帶次序值OrdLast的最后一個關系；·RelX是集合中帶次序值OrdX的給定關系；·RelPrev是集合中最接近于RelX的帶小于OrdX的次序值OrdPrev的關系；以及·RelNext是集合中最接近于RelX的帶大于OrdX的次序值OrdNext的關系。
操作包括但不限于·InsertBeforeFirst(SourceItemID，Relationship)插入關系作為集合中的第一個關系。新關系的“Order”屬性的值可小于OrdFirst。
·InsertAfterLast(SourceItemID，Relationship)插入關系作為集合中的最后一個關系。新關系的“Order”屬性的值可大于OrdLast。
·InsertAt(SourceItemID，ord，Relationship)插入帶有對“Order”屬性指定的值的關系。
·InsertBefore(SourceItemID，ord，Relationship)在帶有給定次序值的關系之前插入該關系。新的關系可被分配“Order”值，它在OrdPrev和ord之間，但不包括這兩個值。
·InsertAfter(SourceItemID，ord，Relationship)在帶有給定次序值的關系之后插入該關系。新的關系可被分配“Order”值，它在ord和OrdNext之間，但不包括這兩個值。
·MoveBefore(SourceItemID，ord，Relationship)將帶給定關系ID的關系移動到帶指定“Order”值的關系之前。關系可被分配新的“Order”值，它在OrdPrev和ord之間，但不包括這兩個值。
·MoveAfter(SourceItemID，ord，Relationship)將帶給定關系ID的關系移動到帶指定“Order”值的關系之后。該關系可被分配新的次序值，它在ord和OrdNext之間，但不包括這兩個值。
如前提到，每個項目必須是項目文件夾的成員。按照關系，每個項目必須與一項目文件夾有一關系。在本發明的若干實施例中，某些關系由在諸項目之間存在的關系表示。
如對本發明的各實施例的實現，關系提供一有向的二元關系，它由一個項目(源)延伸到另一項目(目標)。關系由源項目(延伸它的項目)擁有，因此若源被移除則關系被移除(如在源項目被刪除時關系被刪除)。此外在某些情況下，關系可共享(共同擁有的)目標項目的擁有權，且那樣的擁有權僅可反映在關系的IsOwned(被擁有)屬性(或其等效屬性)中(如圖7對關系屬性類型所示)。在這些實施例中，創建一新的IsOwned關系自動遞增該目標上的引用計數，而刪除那樣的關系可遞減該目標項目上的引用計數。對這些特定實施例，若項目具有大于0的引用計數，則繼續存在，若項目計數達到0則自動刪除。再一次，項目文件夾是具有(或能具有)與其它項目的一組關系的項目，這些其它項目包括項目文件夾的成員資格。關系的其它實際實現是可能的，并由本發明構想來實現這里描述的功能。
不管實際的實現如何，關系是從一個對象到另一對象的可選擇的連接。一個項目屬于一個以上項目文件夾以及一個或多個類別，而不論這些項目、文件夾和類別是公有的或私有的能力是由給予基于項目的結構中的存在(或缺乏)的意義所確定的。這些邏輯關系是分配給一組關系的意義，而不論其專門用來實現這里所述功能的物理實現如何。邏輯關系是在項目及其文件夾或類別之間建立的(或相反)，因為本質上項目文件夾和類別的每一個都是特定類型的項目。因此，能象其它項目一樣地對項目文件夾和類別起作用(拷貝、添加到電子郵件消息中、嵌入文檔等等，而無限制)，而項目文件夾和類別能象其它項目一樣使用相同的機制串行化和解串行化(導入和導出)。(例如在XML中，所有項目可具有串行化的格式，且此格同等地應用于項目文件夾、類別和項目)。
代表項目及其項目文件夾之間的關系的上述關系在邏輯上能從項目延伸到項目文件夾、從項目文件夾延伸到項目、或兩者。邏輯上從一項目延伸到項目文件夾的關系表明該項目文件夾對于該項目是公有的，并與該項目共享其成員資格信息；相反，缺乏從項目到項目文件夾的邏輯關系表明該項目文件夾對該項目是私有的，且不與該項目共享其成員資格信息。類似地，邏輯上從項目文件夾延伸到項目的關系表明該項目是公有的，并可與該項目文件夾共享，而缺乏從項目文件夾延伸到項目的邏輯關系表明該項目是私有的且不能共享。因此，當向其它系統導出項目文件夾時，它是“公有”的項目，它在新的環境中共享，且當項目搜索其項目文件夾尋找其它可共享的項目時，它是“公有”的項目文件夾，它向該項目提供關于屬于它的可共享項目的信息。
圖9是示出項目文件夾(它本身也是項目)、其成員項目、和項目文件夾及其成員項目之間互聯關系的框圖。項目文件夾900具有多個項目902、904和906作為其成員。項目文件夾900具有從它本身到項目902的關系912，它表明項目902是公有的，且能與項目文件夾900、其成員904和906、和任何可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享。然而從項目902到項目文件夾項目900沒有關系，這表明項目文件夾900對項目902是私有的，且不與項目902共享其成員資格信息。另一方面，項目904確實具有從它本身到項目文件夾900的關系924，這表明項目文件夾900是公有的，且與項目904共享其成員資格信息。然而沒有從項目文件夾900到項目904的關系，這表明項目904是私有的，且不與項目文件夾900、其另外的成員902、906、及可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享。與其到項目902和904的關系(或沒有這些關系)相反，項目文件夾900具有從其本身到項目906的關系916，且項目906具有回到項目文件夾900的關系926，一起表明項目906是公有的，且能對文件夾900、其成員902和904、和可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享，且項目文件夾900是公有的，并與項目906共享其成員資格信息。
如前討論，在項目文件夾中的項目不需要共享共同性，因為項目文件夾未被“描述”。另一方面，類別由對所有其成員項目共同的共同性描述。因此，類別的成員資格固有地限于具有所描述的共同性的項目，且在某些實施例中，滿足類別的描述的所有項目自動地成為該類別的成員。因此，盡管項目文件夾允許由其成員資格來表示不重要的類型結構，類別基于定義的共同性來允許成員資格。
當然，類別描述本質上是邏輯的，因而類別可通過類型、屬性和/或值的任何邏輯表示來描述。例如，對一類別的邏輯表示可以是其成員資格，以包括具有兩個屬性之一或兩者的項目。若這些對類別描述的屬性是“A”和“B”，則該類別的成員資格可包括具有屬性A而沒有B的項目、具有屬性B而沒有A的項目、及兼有屬性A和B的項目。通過邏輯運算符“OR(或)”來描述屬性的邏輯表示，其中由類別描述成員組是具有屬性A OR B的項目。如本領域的技術人員所理解的，也能使用類似的邏輯運算符(包括但不限于單獨的“AND(和)”“XOR(異或)”和“NOT(非)”或其組合)來描述類別。
盡管在項目文件夾(未描述)和類別(已描述)之間有區別，但在本發明的許多實施例中，原則上到項目的類別關系及到類別的項目關系以上面對項目文件夾和項目的同樣方法揭示。
圖10是示出一類別(其本身也是項目)、其成員項目、類別及其成員項目之間的互聯關系的框圖。類別1000具有多個項目1002、1004和1006作為成員，所有這些都共享由類別1000描述的共同的屬性、值和類型1008(共同性描述1008’)的某個組合。類別1000具有從其本身到項目1002的關系，它表明項目1002是公有的，且能與類別1000、其成員1004和1006、以及可訪問類別1000的任何其它類別、項目文件夾、或項目(未示出)共享。然而，沒有從項目1002到類別1000的關系，這表明類別1000對項目1002是私有的，且不與項目1002共享成員資格信息。另一方面，項目1004的確具有從其本身到類別1000的關系1024，這表明類別1000是公有的，且與項目1004共享其成員資格信息。然而，不存在從類別1000延伸到項目1004的關系，這表明項目1004是私有的，且不能與類別1000、它的其它成員1002和1006、以及可訪問類別1000的任何其它類別、項目文件夾、或項目(未示出)共享。與它與項目1002和1004的關系(或沒有此關系)相反，類別1000具有從其本身到項目1006的關系1016，且項目1006具有回到類別1000的關系1026，這一起表明項目1006是公有的，且能與類別1000、其項目成員1002和1004、以及可訪問類別1000的任何其它類別、項目文件夾、或項目(未示出)共享，且類別1000是公有的，且與項目1006共享其成員資格信息。
最后，由于類別和項目文件夾本身是項目，且項目可以互相關系，類別可關系到項目文件夾，反之亦然，且在某些另外實施例中，類別、項目文件夾和項目可分別關系到其它類別、項目文件夾和項目。然而在各種實施例中，項目文件夾結構和/或類別結構在硬件/軟件接口系統級上禁止包含回路。當項目文件夾和類別結構類似于有向圖時，禁止回路的實施例類似于有向非循環圖(DAG)，根據圖論領域的數學定義，DAG是其中沒有路徑在同一頂點開始與終止的有向圖。
6.可擴展性如上所述，本存儲平臺旨在提供初始模式組340。然而，至少在某些實施例中，該存儲平臺還允許包括獨立軟件分銷商(ISV)等顧客創建新的模式344(即新的項目和嵌套的元素類型)。本節討論通過擴展在初始模式組340中定義的項目類型和嵌套的元素類型(或簡稱“元素”類型)著眼于創建該模式的機制。
較佳地，項目和嵌套元素類型的初始組的擴展如下約束·允許ISV引入新的項目類型，即子類型Base.Item；·允許ISV引入新的嵌套元素類型，即子類型Base.NestedElement；
·允許ISV引入新的擴展，即子類型Base.NestedElement；但·ISV不能子分類由存儲平臺的初始模式組340定義的任何類型(項目、嵌入元素、或擴展類型)。
由于由存儲平臺的初始模式組定義的項目類型或嵌入元素類型可能不精確地匹配ISV應用程序的需要，必須允許ISV定制該類型。這就考慮了擴展的概念。擴展是強類型的實例，但是(a)它們不能獨立存在，以及(b)它們必須附屬于項目或嵌套元素。
除了解決對模式可擴展性的需要之外，擴展還旨在解決“多分類”問題。在某些實施例中，因為存儲平臺可能不支持多繼承性或重疊子類型，應用程序可以使用擴展作為模型化重疊類型實例(如文檔既是合法文檔又是安全文檔)的方法。
a)項目擴展為提供項目的可擴展性，數據模型還定義名為Base.Extension的抽象類型。這是擴展類型的分層結構的根類型。應用程序可以子分類Base.Extension，以創建特定的擴展類型。
在基礎模式中如下定義Base.Extension類型<Type Name＝″Base.Extension″IsAbstract＝″True″>
<Propety Name＝″ItemID″Type＝″the storage platformTypes.uniqueidentified″Nullable＝″false″MultiValued＝″false″/>
<Property Name＝″ExtensionID″Type＝″the storage platformTypes.uniqueidentified″Nullable＝″false″MultiValued＝″false″/>
</Type>
ItemID字段包含與該擴展關聯的項目的ItemID。帶此ItemID的項目必須存在。若帶給定ItemID的項目不存在，則不能創建擴展。當項目被刪除，帶同一ItemID的所有擴展被刪除。二元組(ItemID，ExtensionID)唯一地標識了擴展實例。
擴展類型的結構類似于項目類型的結構·擴展類型具有字段；·字段可以是原語或嵌套元素類型；以及·擴展類型可被子分類。
下列限制應用于擴展類型
·擴展不能是關系的源和目標；·擴展類型實例不能獨立于項目存在；以及·擴展類型不能用作在存儲平臺類型定義中的字段類型對能與給定的項目類型關聯的擴展的類型沒有約束。任何擴展類型允許擴展任何項目類型。當多個擴展實例被附加到一個項目，它們在結構和行為上彼此獨立。
擴展實例被分別存儲并從項目訪問。所有擴展類型實例可從全局擴展視圖訪問。能組成一有效的查詢，它將返回給定類型的擴展的所有實例，而不管它們關聯什么類型的項目。存儲平臺API提供可存儲、檢索和修改項目擴展的編程模型。
擴展類型可是使用存儲平臺的單個繼承模型來子分類的類型。從一個擴展類型導出創建新的擴展類型。一個擴展的結構或行為不能覆蓋或替代項目類型分層結構的結構或行為。類似于項目類型，擴展類型實例能通過與該擴展類型關聯的視圖直接訪問。擴展的ItemID表明，它們屬于哪個項目，并能用于從全局項目視圖檢索對應的項目對象。為操作一致性的目的，擴展被考慮成項目的一部分。拷貝/移動、備份/恢復和存儲平臺定義的其它常用操作可以在作為項目的一部分的擴展上操作。
考慮下述例子。在Windows類型組中定義Contact(聯系人)類型。
<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(客戶關系管理)應用程序開發者喜歡將CRM應用程序擴展附加到存儲在存儲平臺中的聯系人。應用程序開發者定義包含應用程序能處理的附加數據結構的CRM擴展。
<Type Name＝″CRMExtension″BaseType＝″Base.Extension″>
<Property Name＝″CustomerID″Type＝″String″Nullable＝″false″MultiValued＝″false″/>
…</Type>
HR應用程序開發者希望也將附加數據附加到聯系人。此數據獨立于CRM應用程序數據。應用程序開發者還可創建—擴展<Type Name＝″HRExtension″EBaseType＝″Base.Extension″>
<Property Name＝″EmployeeID″Type＝″String″Nullable＝″false″MultiValued＝″false″/>
…</Type>
CRMExtension和HRExtension是能附加到聯系人項目的兩個獨立擴展。它們能彼此獨立地創建和訪問。
在上述例子中，CRMExtension類型的字段和方法不能覆蓋聯系人分層結構的字段和方法。應注意，CRMExtension類型的實例能被附加到不同于聯系人的項目類型。
在檢索聯系人項目時，不自動地檢索它的項目擴展。給定聯系人項目，可通過查詢全局擴展視圖以尋找帶同一ItemID的擴展來訪問其有關的項目擴展。
可通過CRMExtension類型視圖來訪問系統中所有的CRMExtension擴展，而不論它們屬于什么項目。一個項目的所有項目擴展共享同一項目id。在上述例子中，聯系人項目實例和附加的CRMExtension和HRExtension實例共享同一ItemID。
下面的表總結了在Item(項目)、Extension(擴展)和NestedElement(嵌套元素)類型之間的相似性和差別Item、ItemExtension與NestedElement
b)擴展NestedElement類型嵌套元素類型不用與項目類型相同的機制擴展。嵌套元素的擴展用與嵌套元素類型字段相同的機制存儲和訪問。
數據模型定義了名為Element(元素)的嵌套元素類型的根。
<Type Name＝″Element″IsAbstract＝″True″>
<Property Name＝″ElementID″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類型為根的擴展類型分層結構。
·嵌套元素擴展與該項目的其它字段一起存儲，且不是全局可訪問的—不能組成檢索給定擴展類型的所有實例的查詢。
·象存儲其它嵌套元素(或項目)一樣地存儲這些擴展。象其它的嵌套組，NestedElement擴展被存在UDT中。它們可通過嵌套元素類型的Extension(擴展)字段來訪問。
·用于訪問多值屬性的集合接口也用于在類型擴展組上的訪問和迭代。
下面的表總結和比較Item擴展和NestedElement擴展。
Item擴展與NestedElement擴展
D.數據庫引擎如上提到，數據存儲在數據庫引擎上實現。在本實施例中，數據庫引擎包括諸如Microsoft SQL Server引擎等實現SQL查詢語言、帶有對象關系擴展的關系數據庫引擎。本節按照本實施例，描述數據存儲實現的數據模型到關系存儲的映射，在邏輯API上提供由存儲平臺的客戶機使用的信息。然而可以理解，當采用不同的數據庫引擎時可采用不同的映射。確實，除了在關系型數據庫引擎上實現存儲平臺概念數據模型之外，也可在其它類型數據庫上實現，如面向對象和XML數據庫。
面向對象(OO)數據庫系統為編程語言對象(如C++、Java)提供持續性和事務。“項目”的存儲平臺概念可很好地映射到面向對象系統中的對象，雖然嵌入的集合必須添加給對象。類似繼承性和嵌套元素類型等其它存儲平臺類型概念也映射到面向對象類型的系統。面向對象系統通常已經支持對象身份；因此，項目身份可被映射到對象身份。項目的行為(操作)很好地映射到對象方法。然而，面向對象的系統通常缺乏組織能力并在搜索方面很差。而且，面向對象的系統不提供對非結構化和半結構化數據的支持。為支持這里描述的完全存儲平臺數據模型，象關系、文件夾和擴展等概念需要添加到對象數據模型。此外，需要實現如升級、同步、通知和安全性等機制。
類似于面向對象的系統，基于XSD(XML模式定義)的XML數據庫支持基于單繼承類型的系統。本發明的項目類型系統可映射到XSD類型模型。XSD也不提供對行為的支持。項目的XSD必須增添項目的行為。XML數據庫處理單個XSD文檔并缺乏組織和拓寬搜索能力。如面向對象數據庫那樣，為支持這里描述的數據模型，如關系和文件夾等其它概念需要被結合到該XML數據庫；而且需要實現如同步、通知和安全性等機制。
關于下面小節，提供少量圖示以便于一般的信息揭示圖13是示出通知機制的圖示。圖14是示出兩個事務均將新記錄插入同一B樹的例子的圖示。圖15示出數據改變檢測過程。圖16示出示例性目錄樹。圖17示出其中基于目錄的文件系統的現有文件夾被移動到存儲平臺數據存儲中。
1.使用UDT的數據存儲實現在本實施例中，在一個實施例中包括Microsoft SQL Server引擎的關系型數據庫引擎314支持內建的標量類型。內建的標量類型是“原生(native)”且“簡單”的。它們是原生的意義是，用戶不能定義他們自己的類型；它們是簡單的意義是，用戶不能封裝復雜的結構。用戶定義的類型(下文稱為UDT)通過使用戶能通過定義復雜的結構化類型來擴展類型系統，提供了一種用于超過或超越原生的標量類型系統的類型可擴展性的機制。一旦由用戶定義，UDT能用于可以使用內建標量類型的類型系統中的任何地方。
按本發明的一個方面，存儲平臺模式被映射到數據庫引擎存儲中的UDT類。數據存儲項目被映射到從Base.Item類型導出的UDT類。類似于項目，擴展也能映射到UDT類并使用繼承。根擴展類型是Base.Extension，從它導出所有擴展類型。
UDT是CLR類，它具有狀態(即數據字段)和行為(即例程)。使用任何受管語言(c#、VB.NET等)定義UDT。UDT方法和操作符能在T-SQL中針對該類型的實例調用。UDT能是行中列的類型、T-SQL中例程的參數的類型、或在T-SQL中變量的類型。
存儲平臺模式到UDT類的映射在高級別上完全是直接的。一般而言，存儲平臺模式被映射到CLR名字空間。存儲平臺類型被映射到CLR類。CLR類的繼承鏡象了存儲平臺類型的繼承，且存儲平臺屬性被映射到CLR類屬性。
2.項目映射為了希望項目能夠被全局地搜索，并在本實施例的關系型數據中支持繼承以及類型可替代性，對在數據庫存儲中的項目存儲的一種可能的實現是在帶有類型Base.Item的列的單個表中存儲所有項目。使用類型可替代性，能存儲所有類型的項目，且可按使用Yukon的“is of(類型)”的操作符的項目類型的子類型來過濾搜索。
然而，由于在本實施例中牽涉到與這一方法相關聯的額外開銷，由頂級類型將各項目劃分，使得每個類型“家族”的項目存儲到單獨的表中。在此劃分模式中，對每個直接從Base.Item繼承的項目類型創建一個表。如上所述，繼承下面這些的類型使用類型的可替代性存儲在合適的類型家族表中。只有從Base.Item的第一級繼承被專門地處理。
使用一“陰影”表存儲所有項目的全局可搜索屬性的副本。此表可由存儲平臺API的Update()方法維護，通過此方法作出所有數據的改變。不象類型家族表，此全局項目表只包含該項目的項級標量屬性，而不是全UDT項目對象。全局項目表允許通過展現ItemID和TypeID(類型ID)導航到存儲在類型家族表中的項目對象。ItemID通常唯一地標識數據存儲中的項目。可使用這里未予描述的元數據將TypeID映射到類型名和包含該項目的視圖。由于通過其ItemID尋找項目在全局項目表的上下文及其它情況下都是常用操作，因此給定了項目的ItemId，提供GetItem()函數來檢索項目對象。
為便于訪問和盡可能地隱藏實現的細節，項目的所有查詢可以對照在上述項目的表上構建的視圖進行。具體說來，對每個項目類型針對合適類型的家族表創建視圖。這些類型視圖可選擇相關聯的類型，包括子類型的所有項目。為方便起見，除了UDT對象，視圖能對包括繼承字段的該類型的所有頂級域展現列。
3.擴展映射擴展非常類似于項目，且具有某些相同要求。如支持繼承性的另一根類型，擴展受到存儲中許多同樣的考慮和折衷比較。為此，對擴展應用類似的類型家族映射，而不是單個表方法。當然，在其它實施例中，可使用單個表方法。在本實施例中，擴展通過ItemID僅與一個項目關聯，并包含在項目的上下文中唯一的ExtensionID。如同項目一樣，給定包括ItemID和ExtensionID對的身份，可提供一函數用于檢索擴展。類似于項目類型視圖，對每個擴展類型可創建視圖。
4.嵌套元素映射嵌套元素是可嵌入到項目、擴展、關系、或其它嵌套元素以形成深嵌套結構的類型。類似于項目和擴展，嵌套元素作為UDT實現，但它們存儲在項目和擴展中。因此，嵌套元素沒有超越它們的項目和擴展容器的映射的存儲映射。換言之，在系統中沒有直接存儲NestedElement類型的實例的表，且沒有專門用于嵌套元素的視圖。
5.對象身份在數據模型中的每一實體，即每個項目、擴展和關系具有唯一的關鍵字值。一個項目由其ItemId唯一地標識。擴展由合成關鍵字(ItemId，ExtensionId)唯一地標識。關系由合成關鍵字(ItemId，RelationId)標識。ItemId，ExtensionId和RelationshipId均是GUID值。
6.SQL對象命名在數據存儲中創建的所有對象可存儲在從存儲平臺模式名字導出的SQL模式名字中。例如，存儲平臺基礎模式(常稱“基礎”)可產生在“[System.Storage]”SQL模式中的類型，如“[System.Storage].Item”。產生的名字可用限定詞加前綴以消除命名的沖突。在合適處可使用驚嘆號(！)作為名字的每個邏輯部分的分割符。下面表概括了在數據存儲用于對象的命名習慣。與用于訪問數據存儲中的實例的修飾的命名習慣一起列出每個模式元素(項目、擴展、關系和視圖)。
7.列命名當映射任一對象模型到存儲時，由于與應用程序對象一起存儲的附加信息，有可能發生命名沖突。為避免命名沖突，所有非類型的特定列(不直接映射到類型聲明中的命名的屬性的列)用下劃線字符(_)加前綴。在本實施例中，下劃線字符(_)不允許作為任何標識符屬性的開始字符。此外，為統一在CLR和數據存儲之間的命名，存儲平臺類型或模式元素的所有屬性(關系等)應具有大寫的第一字符。
8.搜索視圖由存儲平臺提供視圖，用于搜索存儲的內容。對每個項目和擴展類型提供SQL視圖。此外，提供視圖以支持關系和視圖(由數據模型定義)。所有SQL視圖和在存儲平臺中的底層表是只讀的。下面將更充分描述，使用存儲平臺API的Update()方法可存儲或改變數據。
在存儲平臺模式中直接定義的每個視圖(由模式設計者定義，而非由存儲平臺自動地生成)可由命名的SQL視圖[<schema-name>].[View！<view-name>]訪問。例如，在模式“AcmePublisher.Books”中名為“BookSales”的視圖可使用名字“[AcmePublisher.Books].[View！BookSales]來訪問。因為視圖的輸出格式在每一視圖的基礎上是自定義的(由定義視圖的那一方提供的任意查詢確定的)，列基于模式視圖定義被直接映射。
存儲平臺數據存儲中的所有SQL搜索視圖使用列的下述排序習慣·如ItemId、ElementId、RelationshipId等的視圖結果的邏輯“關鍵字”列·如TypeId等關于結果類型的元數據信息。
·改變如CreateVersion(創建版本)、UpdateVersion(更新版本)等跟蹤列·類型專用的列(聲明的類型的屬性)·類型專用的視圖(家族視圖)也包含返回對象的對象列每個類型家族的成員可使用一系列項目視圖來搜索，在數據存儲中每個項目類型有一個視圖。圖28是示出項目搜索視圖的概念的圖示。
a)項目每個項目搜索視圖對特定類型或其子類型的項目的每個實例包含一行。例如，文檔的視圖能返回Document(文檔)、LegalDocument(合法文檔)和ReviewDoeument(審閱文檔)的實例。給定此例，能如圖29那樣概念化項目視圖。
(1)主項目搜索視圖存儲平臺數據存儲的每個實例定義稱為主項目視圖(Master Item View)的特殊項目視圖。此視圖提供關于數據存儲中每個項目的綜述信息。視圖對每個項目類型屬性提供一列，其中一列描述項目的類型，若干列用于提供改變跟蹤和同步信息。在數據存儲中使用名字“[System.Storage].[Master！Item]”來標識主項目視圖。
(2)分類型的項目搜索視圖每個項目類型也具有搜索視圖。類似于根項目視圖，此視圖還提供通過“Item”列對項目對象的訪問。在數據存儲中使用名字[schemaName].[itemTypeName]標識每個分類型的項目搜索視圖。例如[AcmeCorp.Dod].[OfficeDoc]。
9.
a)項目擴展WinFs存儲中的所有項目擴展也可使用搜索視圖來訪問。
(1)主擴展搜索視圖數據存儲的每個實例定義一稱為主擴展視圖(Master Extension View)的特殊擴展視圖。此視圖提供關于數據存儲中每個擴展的綜述信息。該視圖對每個擴展屬性有一列，其中一列描述擴展的類型，而若干列用于提供改變跟蹤和同步信息。使用名字“[System.Storage].[Master！Extension]”在數據存儲中標識主擴展視圖。
10.
(1)分類型的擴展搜索視圖每個擴展類型還具有搜索視圖。類似于主擴展視圖，此視圖還提供通過_Extension列對項目對象的訪問。在數據存儲中使用名字[SchemaName].[Extension！extensionTypeName]標識每個分類型的擴展搜索視圖。例如[AcmeCorp.Doc].[Extension！OfficeDocExt]。
b)嵌套的元素所有嵌套的元素存儲在項目、擴展或關系實例之中。因此，它們能通過查詢合適的項目、擴展或關系搜索視圖來訪問。
c)關系如上討論，關系形成在存儲平臺數據存儲中各項目之間鏈接的基本單元。
(1)主關系搜索視圖每個數據存儲提供—主關系視圖。此視圖提供關于數據存儲中所有關系實例的信息。在數據存儲中使用名字“[System.Storage].[Master！Relationship]”來標識主關系視圖。
(2)關系實例搜索視圖每個聲明的關系也有返回該特定關系的所有實例的搜索視圖。類似于主關系視圖，此視圖對該關系數據的每個屬性提供命名的列。在數據存儲中使用名字[schemaName].[Relationship！relationshipName]來標識每個關系實例搜索視圖。例如[AcmeCorp.Doc].[Relationship！DocumentAuthor]。
d)11.更新存儲平臺數據存儲中所有視圖是只讀的。為創建數據模型元素(項目、擴展或關系)的新實例，或更新現有的實例，必須使用存儲平臺API的ProcessOperation或ProcessUpdategram方法。ProcessOperation方法是單個存儲的過程，它是由消費細化擬執行的動作的“操作”的數據存儲定義的。ProcessUpdategram方法是存儲的過程，它采取稱為“更新元素(updategram)”的一組有序的操作，它們共同細化擬執行的一組動作。
操作格式是可擴展的，并提供在模式元素上的各種操作。某些公用操作包括1.項目操作a.CreateItem(在嵌入或持有關系的上下文中創建一新的項目)b.UpdateItem(更新一現有的項目)2.關系操作a.CreateRelationship(創建引用或持有關系的實例)b.UpdateRelationship(更新一關系實例)c.DeleteRelationship(移除一關系實例)3.擴展操作a.CreateExtension(添加一擴展到現有的項目)b.UpdateExtension(更新一現有的擴展)c.DeleteExtension(刪除一擴展)12.改變跟蹤及墓碑如下面更充分討論，由數據存儲提供改變跟蹤和墓碑服務。本節提供在數據存儲中展現的改變跟蹤信息的概述a)改變跟蹤由數據存儲提供的每個搜索視圖包含用于提供改變跟蹤信息的列；那些列對所有項目、擴展和關系視圖是公用的。由模式設計者明確地定義的存儲平臺模式視圖不自動地提供改變跟蹤信息—該信息是通過在其上構建視圖本身的搜索視圖來間接提供的。
對數據存儲中的每個元素，可從兩個地方得到改變跟蹤信息“主”元素視圖和“分類型的”元素視圖。例如，可從主項目視圖“[System.Storage].[Master！Item]”和分類型的項目視圖[AcmeCorp.Document].[Document]中得到關于AcmeCorp.Document.Document項目類型的改變跟蹤信息。
(1)“主”搜索視圖中的改變跟蹤主搜索視圖中的改變跟蹤信息提供關于元素的創建和更新版本的信息、關于哪個同步伙伴創建該元素的信息、關于哪個同步伙伴最后一次更新該元素的信息、以及來自每個伙伴的用于創建和更新的版本號。用伙伴關鍵字來標識同步關系中的伙伴(下面描述)。類型[System.Storge.Store].ChangeTrackingInfo的名為_ChangeTrackingInfo的單個UDT對象包含所有這些信息。在System.Storage模式中定義類型。在項目、擴展和關系的所有全局搜索視圖中可得到_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)“分類型的”搜索視圖中的改變跟蹤除了提供與全局搜索視圖相同信息外，每個分類型的搜索視圖提供記錄在同步拓撲中每個元素的同步狀態的附加信息。
b)墓碑數據存儲為項目、擴展和關系提供墓碑信息。墓碑視圖提供一個地方中有關活動和墓碑實體兩者(項目、擴展和關系)的信息。項目和擴展墓碑視圖不提對對應對象的訪問，而關系墓碑視圖提供對關系對象的訪問(在墓碑關系的情況下關系對象為空)。
(1)項目墓碑通過視圖[System.Storage].[Tombstone！item]從系統檢索項目墓碑。
(2)擴展墓碑使用視圖[System.Storage].[Tombstone！Extension]從系統檢索擴展墓碑。擴展改變跟蹤信息類似于為項目提供的添加了ExtensionId屬性的信息。
(3)關系墓碑通過視圖[System.Storage].[Tombstone！Relationship]從系統檢索關系墓碑。關系墓碑信息類似于對擴展提供的信息。然而，在關系實例的目標ItemRef上提供附加信息。此外，還選擇關系對象。
(4)墓碑清除為防止墓碑信息無限制地增長，數據存儲提供墓碑清除任務。此任務確定什么時候可以舍棄墓碑信息。該任務計算本地創建/更新版本的界限，并隨后通過舍棄所有更早的墓碑版而截斷墓碑信息。
13.助手API和函數基礎映射還提供若干助手函數。提供這些函數以幫助在該數據模型上的公用操作。
a)函數[system.Storage].GetItem∥給定ItemId返回一項目對象Item GetItem(ItemId ItemId)b)函數[System.Storage].GetExtension∥給定ItemId和ExtensionId返回一擴展對象Extension GetExtension(ItemId ItemId，ExtensionId ExtensionId)c)函數[System.Storage].GetRelationship∥給定ItemId和RelationshipId返回—關系對象
Relationship GetRelationship(ItemId ItemId，RelationshipId RelationshipId)14.元數據有兩類在存儲中表示的元數據實例元數據(項目的類型等)，和類型元數據。
a)模式元數據模式元數據作為來自元模式的項目類型的實例存儲在數據存儲中。
b)實例元數據應用程序使用實例元數據來查詢項目的類型，并尋找與項目相關聯的擴展。給定項目的ItemId，應用程序可查詢全局項目視圖，以返回該項目的類型，并使用此值來查詢Meta.Type視圖以返回關于該項目的聲明的類型的信息。例如，∥對給定的項目實例返回元數據項目對象SELECT m.Item AS metadataInfoObjFROM[System.Storage].[Item]i INNER JOIN[Meta].[Type]m ON i._TypeId＝m.ItemIdWHERE i.ItemId＝@ItemIdE.安全性一般而言，所有可保護的對象使用圖26中所示的訪問掩碼格式來安排訪問權限。在此格式中，低16位用于對象專用的的訪問權限，接著7位用于應用于大多數對象類型的標準訪問權限，高4位用于指定類屬訪問權限，每個對象類型將其映射到一組標準且對象專用的權限。ACCESS SYSTEM SECURITY位對應于訪問對象的SACL的權限。
在圖26的訪問掩碼結構中，項目專用的權限被放置在對象專用權限段(低16位)。由于在本實施例中，存儲平臺向管理員安全性展現兩組APIWin32和存儲平臺API，為促進存儲平臺對象專用權限的設計，必須考慮文件系統對象專用的權限。
在通過引用結合于此的有關專利中充分描述了用于本發明的存儲平臺的安全模型。在這點上，圖27(部分a、b和c)畫出按安全模型的一實施例，作為從現有安全區域開拓出的新的等同地保護的安全區域。
F.通知和改變跟蹤按本發明的另一方面，存儲平臺提供允許應用程序跟蹤數據改變的通知能力。此特征主要供保持易失狀態或執行數據改變事件上的業務邏輯的應用程序使用。應用程序注冊在項目、項目擴展及項目關系上的通知。在提交了數據改變通知被異步地傳送。應用程序可按項目、擴展和關系類型以及操作類型來過濾通知。
按一個實施例，存儲平臺API 322為通知提供兩類接口。第一，應用程序注冊由對項目、項目擴展和項目關系的改變觸發的簡單數據改變事件。第二，應用程序創建“監視程序”對象來監視項目、項目擴展和項目之間關系的組。在系統失敗或系統離線超過預定時間之后，可保存和重新創建監視程序對象的狀態。單個通知可反映多個更新。
關于此功能的附加細節能在先前通過引用結合于此的有關專利中找到。
G.傳統文件互操作性如上提到，至少在某些實施例中，本發明的存儲平臺旨在被實施為計算機系統的硬件/軟件接口系統的整體部分。例如，本發明的存儲平臺可被實施為如Microsoft Windows家族操作系統的整體部分。在這方面，存儲平臺API成為操作系統API的一部分，應用程序通過它與操作系統交互。因此，存儲平臺成為裝置，應用程序通過它將信息存到操作系統上，且從而基于項目的存儲平臺的數據模型替代了這一操作系統的傳統文件系統。例如，當在Microsoft Windows家族操作系統中實施時，存儲平臺可替代在該操作系統中實現的NTFS文件系統。當前，應用程序通過由Windows家族操作系統展現的Win32 API來訪問NTFS文件系統的服務。
然而，應認識到，完全用本發明的存儲平臺替代NTFS文件系統需要重新編碼現有的基于Win32的應用程序，且那樣的重新編碼可能是不合需要的，因此本發明的存儲平臺提供與如NFS等現有文件系統的某種互操作性是有益的。從而，在本發明的一個實施例中，存儲平臺使依賴于Win32編程模型的應用程序能同時訪問存儲平臺的數據存儲以及傳統的NTFS文件系統的數據存儲的內容。為此，存儲平臺使用作為Win32命名習慣的超集(superset)的命名習慣以便于容易的互操作性。此外，存儲平臺支持通過Win32 API訪問存儲在存儲平臺卷中的文件和目錄。
關于此功能的另外細節能在先前通過引用結合于此的有關專利中找到。
H.存儲平臺API存儲平臺包括API，它使應用程序能訪問上面討論的存儲平臺的特征和能力，并訪問存儲在數據存儲中的項目。本節描述本發明的存儲平臺的存儲平臺API的一個實施例。關于此功能的細節能在通過引用結合于此的有關專利中找到，為方便起見在下面總結此信息的某一些。
參考圖18，包含文件夾是一個項目，它包含與其它項目的持有關系，且與通常概念的文件系統文件夾等價。每個項目“包含”在至少一個包含文件夾中。
圖19示出按本實施例的存儲平臺API的基本體系結構。存儲平臺API使用SQL客戶機1900與本地數據存儲302對話，并還使用SQL客戶機1900與遠程數存儲(如數據存儲340)對話。本地存儲還可使用DQP(分布式查詢處理器)或通過上述的存儲平臺同步服務(“Sync”)與遠程數據存儲340對話。存儲平臺API322還擔當數據存儲通知的橋接器API，將應用程序的下標傳送到通知引擎，并如上所述將通知路由到應用程序(如應用程序350a、350b或350c)。在一個實施例中，存儲平臺API 322還定義受限制的“提供者”體系結構，使得它能訪問MicrosoftExchange和AD中的數據。
圖20示意性地表示存儲平臺API的各種組件。存儲平臺AP包括下列組件(1)數據類2002，它代表存儲平臺元素和項目類型；(2)運行庫架構2004，它管理對象的持久性并提供支持類2006；以及(3)工具2008，它用于從存儲平臺模式生成CLR類。
從給定模式得出的類的分層結構直接反應了該模式中類型的分層結構。作為例子，考慮在如圖21A和圖21B中所示的聯系人模式中定義的項目類型。
圖22示出操作中的運行庫架構。運行庫架構如下操作1.應用程序350a、350b或350c綁定到存儲平臺的項目。
2.架構2004創建對應于綁定項目的ItemContext對象2202，并將其返回給應用程序。
3.應用程序提交在此ItemContext(項目上下文)上的Find(尋找)，以得到項目的集合；返回的集合在概念上是對象圖2204(由于關系)。
4.應用程序改變、刪除和插入數據。
5.應用程序通過調用Update()方法保存改變。
圖23示出“FindAll(尋找所有)”操作的執行。
圖24示出從存儲平臺模式生成存儲平臺API類的過程。
圖25示出文件API所基于的模式。存儲平臺API包括處理文件對象的名字空間。該名字空間被稱為System.Storage.Files。System.Storage.Files中的類的數據成員直接反映了存儲在存儲平臺存儲中的信息；此信息是從文件系統對象的“升級”或使用Win32 API本機地創建。System.Storage.Files名字空間具有兩個類FileItem(文件項目)和DirectoryItem(目錄項目)。這些類的成員及其方法可通過審閱圖25中的模式圖來預測。FileItem和DirectoryItem是從存儲平臺API只讀的。為修改它們，必須使用System.IO中的Win32 API或類。
對于API，編程接口(或簡稱之為接口)可以被視為用于令代碼的一個或多個片斷能與由代碼的一個或多個其它片斷提供的功能進行通信或對其進行訪問的任一機制、過程、協議。或者，編程接口可以被視為能夠通信地耦合至其它計算機的一個或多個機制、方法、函數調用、模塊等的系統的組件的一個或多個機制、方法、函數調用、模塊、對象等。上述語句中的術語“代碼片斷”意在包括代碼的一個或多個指令或代碼行，并包括，如，代碼模塊、對象、子例程、函數等等，無論應用的術語是什么、或代碼片斷是否被單獨編譯、或代碼片斷是否被提供為源碼、中間碼或對象代碼、代碼片斷是否在運行時系統或進程中使用、或它們是否位于同一或不同機器上或跨多個機器分布、或由代碼片斷表示的功能是否完全由軟件、完全由硬件或硬件和軟件的組合來實現。
概念上，編程接口可以被一般地察看，如圖30A或圖30B所示的。圖30A示出了接口“接口1”為管道，第一和第二代碼片斷通過該管道進行通信。圖30B示出了接口包括接口對象I1和I2(可以是或不是第一和第二代碼片斷的部分)，它們令系統的第一和第二代碼片斷能通過介質M進行通信。在圖30B中，可以認為接口對象I1和I2為同一系統的單獨接口，并且也可以認為對象I1和I2加上介質M構成了接口。盡管圖30A和30B示出了雙向流程以及該流程的每一側上的接口，某些實現可僅具有一個方向上的信息流(或如下所述沒有信息流)，或僅具有一側的接口對象。作為示例而非局限，諸如應用編程或程序接口(API)、入口點、方法、函數、子例程、遠程過程調用和組件對象模型(COM)接口等術語包含在編程接口的定義之內。
這類編程接口的方面可包括第一代碼片斷向第二代碼片斷發送信息的方法(其中，“信息”以其最廣泛的意義使用，并包括數據、命令、請求等等)；第二代碼片斷接收信息的方法；以及該信息的結構、序列、語法、組織、模式、定時和內容。在這一點上，只要信息以接口所定義的方式傳輸，底層傳輸介質本身可以對接口的操作不重要，無論該介質是有線還是無線，或兩者的組合。在某些情況下，在常規意義上，當一個代碼片斷僅訪問由第二代碼片斷執行的功能時，信息可不在一個或兩個方向上傳輸，因為信息傳輸可以是或者通過另一機制(如，信息被放置在與代碼片斷之間的信息流分離的緩存、文件等中)或者不存在。這些方面的任一個或所有可以在給定的情況下重要，如，取決于代碼片斷是否是松耦合或緊耦合配置的系統的一部分，并且因此該列表應當被認為是說明性的而非限制。
編程接口的這一概念對本領域的技術人員是已知的，并且可以閱讀上述本發明的詳細描述而清楚這一概念。然而，有其它方法來實現編程接口，并且除非明顯地排除，這些方法也由所附權利要求書包含在內。這些其它方法看似比圖30A和30B的視圖更精密或復雜，但是它們仍執行類似的功能來完成同一整體結果。現在簡要描述編程接口的某些說明性替換實現。
分解可以通過將通信分裂成多個離散通信來間接地實現從一個代碼片斷到另一個的通信。這在圖31A和31B中示意性地描述。如圖所示，可以按照功能的可分組來描述某些接口。由此，可以分解圖30A和30B的接口功能來達到相同的結果，如同可以在數學上提供24，或2乘2乘3乘2一樣。因此，如圖31A所示，可以細分由接口“接口1”提供的功能以將該接口的通信變換成多個接口“接口1A”、“接口1B”、“接口1C”等，而達到相同的結果。如圖31B所示，由接口I1提供的函數可以被細分成多個接口I1a、I1b、I1c等，而達到相同的結果。類似地，從第一代碼片斷接收信息的第二代碼片斷的接口I2可以被分解成多個接口I2a、I2b、I2c等。當分解時，包括在第一代碼片斷中的接口的數量不需要匹配包括在第二代碼片斷中的接口的數量。在圖31A或31B的任一情況下，接口“接口1”和I1的功能性精神分別與圖30A和30B的保持相同。接口的分解也可遵從聯合、通信和其它數學性質，使得分解較難識別。例如，命令操作可以是不重要的，并且因此由接口完成的功能可以在達到該接口之前由另一段代碼或接口較好地完成，或者由系統的單獨組件執行。此外，編程領域的普通技術人員可以理解有各種方式來作出不同的函數調用而達到相同的結果。
重定義在某些情況下，可能忽略、添加或重定義編程接口的某些方面(如參數)，而仍達到預期的結果。這在圖32A和32B中示出。例如，假定圖30A的接口“接口1”包括函數調用Square(input，precision，output)(平方)，它包括三個參數，input(輸入)、precision(精度)和output(輸出)，并且由第一代碼片斷向第二代碼片斷發布。如果中間參數precision在給定的情形下無關緊要，如圖32A所示，它也可以被忽略或甚至由meaningless(無意義)(在這一情況下)參數來替換。也可以添加無關緊要的additional(另外)參數。在任一情況下，只要在輸入由第二代碼片斷平方之后返回輸出，就可以達到square(平方)的功能。Precision也有可能對計算系統的某一下游或其它部分是極有意義的參數；然而，一旦認識到precision對計算平方這一有限目的不是必需的，它可以被替換或忽略。例如，不是傳遞一個有效的pricision值，而是在不對結果產生不利影響的情況下傳遞諸如出生日期等無意義的值。類似地，如圖32B所示，接口I1由接口I1′替換，它被重新定義來忽略或向接口添加參數。接口I2可類似地被重定義為接口I2′，它被重定義來忽略不必要的參數，或可在別處處理的參數。此處的要點是在某些情況下，編程接口可包括對某一目的而言所不需要的方面，諸如參數，因此可以忽略或重定義它們，或在別處處理它們用于其它目的。
內嵌代碼合并兩個單獨的代碼模塊的一些或全部功能也是可行的，使得它們之間的“接口”改變形式。例如，圖30A和30B的功能可以被分別轉化到圖33A和33B的功能。在圖33A中，圖30A的先前的第一和第二代碼片斷被合并成包含兩者的模塊。在這一情況下，該代碼片斷仍可以彼此通信，但是該接口可以適用于更適合單個模塊的形式。由此，例如，正式的調用(Call)和返回(Return)語句將不再必需，但是依照接口“接口1”的類似的處理或響應仍是有效的。類似地，如圖33B所示，圖30B的部分(或所有)接口I2可以內嵌地寫入接口I1來形成接口I1″。如圖所示，接口I2被劃分成I2a和I2b，并且接口部分I2a內嵌在接口I1中書寫代碼來形成接口I1″。對于具體的示例，考慮圖30B的接口1執行函數調用square(input，output)，它由接口I2接收，在由第二代碼片斷處理傳遞到input的值(對其求平方)之后，它被使用output傳遞回已求平方的結果。在這一情況下，由第二代碼片斷執行的處理(對input求平方)可以由第一代碼片斷在不調用該接口的情況下執行。
脫離可以通過將通信分裂成多個離散的通信來間接地完成從一個代碼片斷到另一個的通信。這在圖34A和34B中示意性地描述。如圖34A所示，提供了中間件的一個或多個片斷(脫離接口(Divorce Interface)，因為它們從原始的接口脫離的功能和/或接口函數)，以轉化第一接口“接口1”上的通信，使得它們符合不同的接口，在本情況下為“接口2A”、“接口2B”和“接口2C”。這可以在這樣一種情況中完成，例如，依照“接口1”協議設計應用的已安裝基礎與如操作系統進行通信，但是然后改變該操作系統來使用不同的接口，在本情況下為接口“接口2A”、“接口2B”和“接口2C”。要點是改變了由第二代碼片斷使用的原始接口，使得它不再與第一代碼片斷所使用的接口兼容，因此使用中介來令舊接口和新接口兼容。類似地，如圖34B所示，可以使用脫離接口DI1引入第三代碼片斷以從接口I1接收信息，并使用脫離接口DI2引入第三代碼片斷以向例如接口I2a和I2b發送接口功能，重新設計接口I2a和I2b以使用DI2，但是提供相同的功能性結果。類似地，DI1和DI2可共同工作以將圖30B的接口I1和I2的功能轉換成一新操作系統，而提供相同或類似的功能性結果。
重寫再一種可能的變化是動態地重寫代碼，使用別的東西來替換接口的功能，而仍達到相同的總體結果。例如，可以有一種系統，其中，向執行環境(如由.Net框架提供的環境、Java運行時環境或其它類似的運行時刻類型環境)中的及時(Just-in-Time)(JIT)編譯器或解釋器提供了中間語言(如Microsoft IL、JavaByteCode等)中呈現的代碼片斷。可以書寫JIT編譯器以動態地將通信從第一代碼片斷轉化到第二代碼片斷，即，令它們符合第二代碼片斷(原始或不同的第二代碼片斷)所需要的不同接口。這在圖35A和35B中有描述。如圖35A中所看見的，這一方式類似于上述的脫離情形。它可以在這樣一種情況下完成，例如，依照“接口1”協議設計應用的已安裝基礎操作系統進行通信，然后改變該操作系統以使用不同的接口。JIT編譯器可以用于令已安裝基礎應用的空中通信符合操作系統的新接口。如圖35B所描述的，可以應用這一動態重寫接口的方法以進行動態分解，或者改變接口。
應當注意，上述通過替換實施例實現與接口相同或相似的結果的情形也可以以各種方式串行、并行或與其它干預代碼組合。由此，上文呈現的替換實施例并非相互窮盡，并且可以被混合、匹配和組合以產生與圖30A和30B中所呈現的一般情形相同或等效的情形。也應當注意，如同大多數編程構造，本發明可能未描述達到與接口相同或相似的功能的其它類似的方式，但是它們仍由本發明的精神和范圍來表示，即，應當注意，它至少部分地是由作為接口的值的基礎的接口表示的功能或由其啟用的有利結果。
III.同步API在基于項目的硬件/軟件接口系統中，有若干種同步方法是可行的。
A.同步綜述對于本發明的若干實施例，并參考圖3，存儲平臺提供同步服務330，它(I)允許存儲平臺的多個實例(每個有自己的數據存儲302)按一組靈活的規則來同步它們的內容的各部分，以及(ii)為第三方提供基礎結構以將本發明的存儲平臺的數據存儲與實現專有協議的其它數據源同步。
存儲平臺到存儲平臺的同步在一組參與的復制品之間發生。例如參考圖3，希望在多半是在不同的計算機系統上運行的存儲平臺的另一實例的控制下提供在存儲平臺300的數據存儲302和另一遠程數據存儲338之間的同步。該組的總的成員資格不必在任何給定時間被任何給定復制品知道。
不同的復制可以獨立地(即并發地)作出改變。將同步過程定義成使每個復制品知道由其它復制品作出的改變。此同步能力本質上是多主的(multi-master)(即，對等的)。
本發明的同步能力允許各復制品·確定另一復制品知道什么改變；·請求關于此復制品不知道的改變的信息；·傳輸關于其它復制品不知道的改變的信息；·確定兩個改變何時互相沖突；·本地應用改變；·傳輸沖突分解到其它復制品以確保會聚性；以及·基于對沖突分解指定的政策分解沖突。
1.存儲平臺到存儲平臺的同步本發明的存儲平臺的同步服務300的基本應用是同步存儲平臺(每個帶有它自己的數據存儲)的多個實例。同步服務在存儲平臺模式級上操作(而不是在數據庫引擎314的底層表中)。因此，例如“范圍(Scope)”用于定義下面討論的同步組。
同步服務按“純改變(net change)”的原則操作。不是記錄和發送各個操作(如事務復制)，同步服務而是發送這些操作的最終結果，因此常將多個操作的結果合并成單個最終結果。
同步服務通常不考慮事務邊界。換言之，若在單個事務中對存儲平臺數據存儲作出兩個改變，不保證這些改變原子地應用到所有其它復制品上—可以示出一個改變而不示出其它改變。此原則的例外是，若在同一事務中對同一項目作出兩個改變，則這些改變保證被原子地發送和應用到其它復制。因此，項目是同步服務的一致性單元。
a)同步(Sync)控制應用程序任一應用程序可連接到同步服務并啟動sync(同步)操作。那樣的應用程序提供執行同步(見下面同步概況)所需的所有參數。那樣的應用程序在這里被稱為同步控制應用程序(SCA)。
在同步兩個存儲平臺實例時，在一側由SCA啟動同步。該SCA通知本地同步服務與遠程伙伴同步。在另一側，同步服務通過由來自發起機器的同步服務發出的消息喚醒。它基于在目標機器上存在的持久配置信息(見下文的映射)作出響應。同步服務能按時間表或響應于事件運行。在這些情況下，實現時間表的同步服務成為SCA。
為啟用同步，需要采取兩個步驟。首先，模式設計者必須用合適的同步語義注釋存儲平臺模式(如下文所述的指定改變單元)。其次，同步必須在具有參與同步的存儲平臺的實例的所有機器上正確地配置(如下所述)。
b)模式注釋同步服務的基本概念是改變單元(Change Unit)的概念。改變單元是由存儲平臺個別地跟蹤的最小的模式片段。對每個改變單元，同步服務能確定自從最后一次同步以來它是被改變還是未被改變。
指定模式中的改變單元達到若干目的。首先，它確定了在線的同步服務如何羅嗦。當在改變單元內作出改變時，整個改變單元被發送到其它復制品，因為同步服務不知道改變單元的哪部分被改變。其次，它確定了沖突檢測的粒度。當對同一改變單元作出兩個并發的改變(這些術語在后繼章節中詳細定義)，同步服務引起沖突；另一方面，若對不同改變單元作出并發改變，則無沖突發生，且改變被自動地合并。第三，它嚴重地影響了由系統保持的元數據的量。對每個改變單元保持許多同步服務元數據；因此，使改變單元更小會增加同步的額外開銷。
定義改變單元需要找出正確的折衷。為此，同步服務允許模式設計者參與此過程。
在一個實施例中，同步服務不支持大于一個元素的改變單元。然而，它支持讓模式設計者指定比一個元素更小的改變單元的能力—即將一個元素的多個屬性組合到單獨的改變單元中。在該實施例中，這是使用下述句法實現的<Type Name＝″Appointment″MajorVersion＝″1″MinorVersion＝″0″ExtendsType＝″Base.Item″ExtendsVersion＝″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＝″1MultiValued＝″True″/>
…<ChangeUnit Name＝″CU_Status″>
<Field Name＝″MeetingStatus″/>
</ChangeUnit>
<ChangeUnit Name＝″CU_Organizer″/>
<Field Name＝″OrganizerName″/>
<Field Name＝″OrganizerEmail″/>
</ChangeUnit>
…</Type>
c)同步配置希望保持它們數據的某些部分同步的一組存儲平臺伙伴被稱為同步共同體。雖然共同體的成員希望保持同步，它們不需要以完全相同的方式表示數據；換言之，同步伙伴可轉換他們正在同步的數據。
在對等情況下，讓對等方對所有它們的伙伴維持轉換映射是不現實的。取代地，同步服務采取定義“共同體文件夾”的方法。共同體文件夾是代表所有共同體成員正在與之同步的假設的“共享文件夾”的抽象。
此概念最好用一例子說明。若Joe希望保持他的若干計算機的My Documents(我的文檔)文件夾同步，Joe定義一共同體文件夾，如稱為JoeDocuments。隨后在每臺計算機上，Joe在假設的JoeDocuments文件夾和本地My Documents文件夾之間配置一映射。從這點出發，當Joe的計算機彼此同步時，它們借助JoeDocuments中的文檔而不是它們的本地項目來交談。以此方法，所有Joe的計算機互相理解，而不必知道其它人是誰—共同體文件夾成為同步共同體的通用語。
配置同步服務包括三個步驟(1)定義在本地文件夾和共同體文件夾之間的映射；(2)定義確定哪個得到同步的同步概況(如與誰同步，以及哪個子集應當被發送、哪個被接收)；以及(3)定義不同的同步概況應當運行的時間表，或手動運行它們。
(1)共同體文件夾—映射共同體文件夾映射作為XML配置文件被存儲在個別機器上。每個映射具有以下模式/mappings/communityFolder此元素命名映射的共同體文件夾。名字遵循文件夾的句法規則。
/mappings/localFolder此元素命名映射所轉換到的本地文件夾。此名字遵循文件夾的句法規則。為了映射有效，文件夾必須已存在。此文件夾中的項目被看作對每一此映射的同步。
/mappings/transformations此元素定義如何將項目從共同體文件夾轉換到本地文件夾以及如何反向轉換。若缺少或為空，不執行轉換。具體說來，這意味著無ID被映射。此配置主要用于創建文件夾的高速緩存。
/mappings/transformations/mapIDs此元素請求新生成的本地ID被賦予所有從共同體文件夾映射的項目，而不是重新使用共同體ID。同步運行庫維護ID映射，以來回轉換項目。
/mappings/transformations/localRoot此元素請求共同體文件夾中的所有根項目作為指定根的子項目。
/mappings/runAs此元素控制，在誰的授權下處理針對此映射的請求。若不存在，則假設發送者。
/mappings/runAs/sender存在此元素表明，對此映射的消息發送者必須是人格化的，且在他的憑證下處理請求。
(2)概況同步概況是分離同步所需的總的參數組。由SCA將其提供給同步運行庫以啟動同步。存儲平臺到存儲平臺的同步的同步概況包含以下信息·本地文件夾，用作改變的源和目標；·與之同步的遠程文件夾名一此文件夾必須通過如上定義的映射從遠程伙伴發布；·方向—同步服務支持只發送、只接收以及發送—接收同步；·本地過濾器—選擇發送什么本地信息到遠程伙伴。表示成本地文件夾上的存儲平臺查詢；·遠程過濾器—選擇從遠程伙伴接收什么遠程信息—表示成共同體文件夾上的存儲平臺查詢；·轉換—定義如何在項目和本地格式間轉換；·本地安全性—指定是在遠程端點(人格化)的許可下應用從遠程端點檢索的改變，還是用戶在本地啟動同步；以及·沖突分解政策—指定沖突是否應被拒絕、記入日志或自動分解—在后一種情況下，指定使用哪個沖突分解器以及它的配置參數。
同步服務提供允許簡單構建同步概況的運行時CLR類。概況可被串行化成XML文件或從XML文件串行化，以便容易存儲(常與時間表一起)。然而，在存儲平臺中沒有存儲所有概況的標準地方；歡迎SCA在不必永久保持的點上構建概況。注意，不需要具有本地映射來啟動同步。能在概況中指定所有同步信息。然而為響應于由遠程方啟動的同步請求，需要映射。
(3)時間表在一個實施例中，同步服務不提供它自己的調度基礎結構。相反，它依賴于另一組件來完成此任務—在Microsoft Windows操作系統中可得到的WindowsScheduler。同步服務包括命令行實用程序，它擔當SCA并基于保存在XML文件中的同步概況觸發同步。該實用程序使得按時間表或者響應于如用戶登錄或登出等事件來配置Windows Scheduler變得非常容易。
d)沖突處理同步服務中的沖突處理被劃分成三個階段(1)發生在改變應用時的沖突檢測—此步驟判斷是否可安全地應用改變；(2)自動沖突分解并記入日志—在此步驟(發生在緊接著沖突檢測之后)資訊自動沖突分解器)(或“沖突處理器”)，以查看沖突是否能被分解—若不能，可任選地將沖突記入日志；以及(3)沖突檢查與分解—若某些沖突已被記入日志，且發生在同步會話之外，則采取此步驟一此時，被記入日志的沖突能被分解并從日志中移除。針對沖突處理的本發明的各實施例將在后文第III節中更詳細地討論。
2.對非存儲平臺數據存儲的同步按本發明的存儲平臺的另一方面，存儲平臺提供ISV用于實現同步適配器的體系結構，同步適配器使存儲平臺能與如Microsoft Exchange、AD、Hotmail等傳統系統同步。同步適配器得益于由下述同步服務提供的許多同步服務。
不管其名稱如何，同步適配器不需要作為某個存儲平臺體系結構的插件來實現。在需要時，“同步適配器”能簡單地是利用同步服務運行庫接口來獲得如改變枚舉和應用等服務的任何應用程序。
為了使其他人能更容易地配置和運行到給定后端(backend)的同步，鼓勵同步適配器的編寫者展現標準同步適配器接口，它在給定上述的同步概況時運行同步。概況提供配置信息給適配器，某些適配器傳送到同步運行庫以控制運行庫服務(如，要同步的文件夾)。
a)同步服務同步服務向適配器編寫者提供若干同步服務。在本節余下部分，方便地將存儲平臺在其上做同步的機器稱為“客戶機”，而適配器正與其對話的非存儲平臺后端稱為“服務器”。
(1)改變枚舉基于由同步服務維持的改變跟蹤數據，改變枚舉允許同步適配器容易地枚舉自從最后一次與該伙伴試圖作出同步以來對數據存儲文件夾發生的改變。
基于“錨位(anchor)”的概念來枚舉改變—這是表示有關最后一次同步的信息的不透明的結構。如以前章節所述，錨位采取存儲平臺知識的形式。利用改變枚舉服務的同步適配器落入兩大類別使用“存儲的錨位”的適配器和使用“提供的錨位”的適配器。
區別基于關于最后一次同步的信息存儲在哪里—在客戶機上或在服務器上。適配器常常容易地存儲此信息在客戶機上—后端往往不能容易地存儲此信息。另一方面，若多個客戶機與同一后端同步，則將此信息存儲在客戶機上是低效且在某些情況下是不正確的—這使一個客戶機不知道其它客戶機已推到服務器的改變。若適配器希望使用服務器存儲的錨位，則適配器需要在改變枚舉時將其送回到存儲平臺。
為了讓存儲平臺維護錨位(用于本地或遠程存儲)，存儲平臺需要知道成功地應用在服務器上的改變。這些且只有這些改變能包括在錨位中。在改變枚舉期間，同步適配器使用確認(Acknowledgement)接口，以報告哪個改變已被成功地應用。在同步結束時，使用提供的錨位的適配器必須讀出新錨位(它集合所有成功應用的改變)并將其發送到它們的后端。
各適配器常常需要存儲適配器專用數據以及插入到存儲平臺數據存儲中的各項目。該數據存儲的常見例子是遠程ID和遠程版本(時間標記)。同步服務提供用于存儲此數據的機制，而改變枚舉提供接收此額外數據以及要返回的改變的機制。在大多數情況下，這消除了適配器重新查詢數據庫的需求。
(2)改變應用改變應用允許同步適配器將從它們的后端接收的改變應用到本地存儲平臺。期望適配器將改變轉換到存儲平臺模式。圖24示出從存儲平臺模式生成存儲平臺API類的過程。
改變應用的主要功能是自動檢測沖突。如在存儲平臺到存儲平臺同步的情況下，沖突被定義成在互相不知道時作出的兩個重疊的改變。當適配器使用改變應用時，它們必須指定對其執行沖突檢測的錨位。若檢測到未被適配器的知識覆蓋的重疊的本地改變，則改變應用引起沖突。類似于改變枚舉，適配器可使用存儲的或提供的錨位。改變應用支持適配器專用元數據的有效存儲。那樣的數據可由適配器將其附加到要應用的改變上，且可被同步服務存儲。數據可在下次改變枚舉時返回。
(3)沖突分解以下在IV中描述的沖突分解機制(包括記入日志和自動分解選項)也對同步適配器可用。在應用改變時，同步適配器能指定用于沖突分解的政策。若指定了，沖突可被傳遞到指定的沖突處理程序并予以分解(若可能)。沖突也能被記入日志。當試圖將本地改變應用到后端時，適配器有可能檢測沖突。在那樣情況下，適配器仍可以將沖突傳遞到同步運行庫，以按政策分解。此外，同步適配器可請求任何由同步服務檢測的沖突發回給它們以便處理。在后端能存儲或分解沖突的情況這特別方便。
b)適配器實現雖然某些“適配器”簡單地是利用運行庫接口的應用程序，然而鼓勵適配器實現標準的適配器接口。這些接口允許同步控制應用程序請求適配器按給定的同步概況執行同步；取消正進行的同步；以及接收關于正進行同步的進展報告(完成百分比)。
3.安全性同步服務努力將盡可能少的同步引入到由存儲平臺實現的安全模式。不是去定義對同步新的權限，而是使用現有的權限。具體地，·能讀數據存儲項目的任何人可枚舉對那個項目的改變；·能寫到數據存儲項目的任何人可應用改變到該項目；以及·能擴展數據存儲項目的任何人可將同步元數據與該項目關聯。
同步服務不維護安全授權信息。當在復制品A由用戶U作出改變，且將其轉發到復制品B時，該改變最初在A處(由U)作出的事實丟失了。若B將此改變轉發到復制品C，則這是在B的授權而不是在A的授權下完成的。這就導致下述限制若不信任一個復制品對一個項目作出它自己的改變，它不能轉發由其它復制品作出的改變。
在啟動同步服務時，由同步控制應用程序完成。同步服務人格化SCA的身份，并在該身份下完成所有操作(本地的和遠程的)。作為說明，觀察到用戶U不能使本地同步服務從遠程存儲平臺檢索對用戶U不具有讀訪問的項目的改變。
4.可管理性監視復制品的分布式共同體是復雜的問題。同步服務可使用“掃描(sweep)”算法來收集和分發關于該復制品的狀態的信息。掃描算法的屬性確保關于所有所配置的復制品的信息最終被收集，且檢測到該失敗(無響應)的復制品。
在每個復制品上可得到共同體范圍的監視信息。可在任意選取的復制品上運行監視工具，以檢查此監視信息并作出管理決策。在受影響的復制品上必須直接作出配置改變。
B.同步API綜述在越來越多地分布式的、數字的世界中，個體和工作站常常將信息和數據存儲在多種不同的設備和位置中。這就推動了數據同步服務的發展，在最小限度的用戶干預的情況下，所述數據同步服務可以將所述信息保存在這些單獨的、常常完全各不相同的在所有時間上都被同步了的數據存儲中。
本發明的同步平臺，作為此處的節II(又稱，“WinFS”)中所描述的豐富的存儲平臺的一部分，解決了3個主要任務·允許應用和服務有效地同步不同“WinFS”的存儲之間的數據。
·允許開發者創建用于同步“WinFS”和非“WinFS”存儲之間的數據的富有成果的方法。
·為開發者提供適當的接口以便定制同步用戶經歷。
1.一般術語在此，下面是與后面的討論此處是節III.B有關的一些進一步規定的定義和關鍵概念同步復制品大多數應用只對跟蹤、枚舉和同步用于WinFS存儲內的項目的給定子集的改變。將參與同步操作的項目的集合稱為同步復制品。復制品是用被包含在給定的WinFS包含層內的項目(通常是作為位于文件夾項目上的根)來定義的。所有同步服務都在給定的復制品的環境內實現。WinFS同步提供了規定、管理和清除復制品的機制。各個復制品具有唯一地標識給定WinFS存儲內的復制品的GUID標識符。
同步伙伴同步伙伴被規定為能夠影響在WinFS項目、擴展和關系上的改變的實體。因此，各個WinFS存儲可以被稱為同步伙伴。當與非WinFS存儲同步時，外部數據源(EDS)也被稱作同步伙伴。各個伙伴具有唯一地標識它的GUID標識符。
同步共同體同步共同體被規定為復制品的集合，采用對等同步操作的方式，同步地保存所述復制品的集合。這些復制品可以全部都是位于相同的WinFS存儲、不同的WinFS存儲中，或者甚至將它們清楚表示為非WinFS存儲上的虛擬復制品。特別地如果共同體中只有同步操作是通過WinFS同步服務(WinFS適配器)的，則WinFS同步并不指定或委托用于所述共同體的任何專用拓撲。同步適配器(下面規定的)可以引入其自己的拓撲約束。
改變跟蹤、改變單元和版本各個WinFS存儲跟蹤對所有本地WinFS項目、擴展和關系的改變。在所述模式中所規定的改變單位粒度(granularity)的等級上，跟蹤改變。采用作為一個頂級字段的最小粒度，任何項目、擴展和關系類型的頂級字段可以由模式設計者子劃分為改變單元。為了改變跟蹤的目的，每個改變單元被分配一個版本，其中版本是一對同步伙伴Id和版本號(所述版本號是伙伴專用的單調增加的數字)。按照本地發生在所述存儲中的或者按照它們從其它復制品中獲得的改變，更新版本。
同步知識知識表示在任意時間給出同步復制品的狀態，即它封裝與給定的復制品本地知道的或者是從其它復制品中知道的所有改變有關的元數據。WinFS同步保存并且更新用于跨同步操作的同步復制品的知識。要注意的重要的事情是，知識表示允許它相對整個共同體進行解釋而不是只相對于與知識被存儲的特定復制品進行解釋。
同步適配器同步適配器是受管理的編碼應用，它通過同步例程API訪問WinFS同步服務，并且使WinFS數據與非WinFS數據存儲同步。依賴于情況的需要，關于WinFS數據的哪個子集和什么WinFS數據類型進行同步，取決于適配器開發者。所述適配器負責與EDS進行通信、向和從支持模式的EDS傳送WinFS模式、以及規定并管理其自己的配置和元數據。強烈鼓勵適配器實現WinFS同步適配器，以便具有普通配置和控制用于由WinFS同步組所提供的適配器的底層結構的優點。對于更多的細節，請參見WinFS同步適配器API專刊[SADP]和WinFS同步控制器API[SCTRL]專刊。
對于使WinFS數據與外部的非WinFS存儲同步并且不能以WinFS格式產生或保存知識的適配器，WinFS同步提供了保存遠程知識的服務，所述遠程知識能夠被用于后來的改變枚舉或應用操作。依賴于后端存儲的能力，所述適配器可以希望在所述后端上或者在本地WinFS存儲上存儲這種遠程知識。
為簡單起見，同步“復制品”是一種結構，它表示“WinFS”存儲中存在于單個本地位置中的一組數據，然而，非WinFS存儲上的數據被稱作“數據源”，并且一般要求使用適配器。
遠程知識當給定的同步復制品希望獲得來自另一個復制品的改變時，它提供其自己的知識作為一種基線，根據基線，其它復制品枚舉改變。類似地，當給定的復制品希望將改變發送給另一個復制品時，它提供其自己的知識作為基線，所述基線可以由遠程復制品用于檢測沖突。在同步改變枚舉和應用期間提供的與其它復制品有關的這種知識被稱為遠程知識。
2.同步API主體對于某些實施例，所述同步API分割成兩部分同步配置API和同步控制器API。同步配置API允許應用配置同步，并且指定參數用于兩個復制品之間的特定同步會話。對于給定的同步會話，配置參數包括將被同步的項目的集合、同步的類型(單向或雙向)、與遠程數據源有關的信息、以及沖突分解策略。同步控制器API啟動同步會話，取消同步，以及接收處理和與正在進行的同步有關的錯誤信息。還有，對于特定的實施例，其中同步需要根據預定的調度執行，這種系統可以包括調度定制調度表的機制。
本發明的多個實施例使用同步適配器以便同步“WinFS”和非“WinFS”數據源之間的信息。適配器的例子包括同步“WinFS”沖突文件夾和非WinFS郵箱之間的地址簿信息的適配器。在這些情況下，為了開發“WinFS”模式和非“WinFS”數據源模式之間的模式轉換編碼，適配器開發者可以使用此處所描述的“WinFS”同步核心服務API以便訪問由“WinFS”同步平臺所提供的服務。此外，適配器開發者提供了用于將改變與非“WinFS”數據源進行通信的協議支持。通過使用同步控制器API調用并控制同步適配器，并且使用這種API報告進度和錯誤。
然而，對于本發明的某些實施例，當“WinFS”數據存儲與另一個“WinFS”數據存儲同步時，如果“WinFS”對“WinFS”同步服務被集成在硬件/軟件接口系統內，則同步適配器可以不是必需的。在任何情況下，多個這樣的實施例提供了用于“WinFS”對“WinFS”以及同步適配器方法兩者的一組同步服務，所述同步適配器方法包括·對“WinFS”項目、擴展和關系的改變的跟蹤。
·用于自給定的過去的狀態開始的有效遞增的改變枚舉的支持。
·對“WinFS”的外部改變的應用。
·在改變應用期間的沖突處理。
參見圖36，示出了普通數據存儲和用于同步它們的組件的3個實例。第一系統3602具有WinFS數據存儲3612，所述WinFS數據存儲3612包括WinFS對WinFS同步服務3622和核心同步服務3624，用于WinFS對非WinFS同步，它公開了3646用于使用的同步API3652。類似于第一系統3602，第二系統3604具有WinFS數據存儲3614，所述WinFS數據存儲3614包括WinFS對WinFS同步服務3632和核心同步服務3634，用于WinFS對非WinFS同步，它公開了3646用于使用的同步API3652。第一系統3602和第二系統3604通過其各自的WinFS對WinFS同步服務3622和3632進行同步3642。第三系統3606，不是WinFS系統，它具有用于使用WinFS同步3666將數據源保存在具有WinFS復制品的同步共同體中的應用。這種應用可以使用WinFS同步配置/控制服務3664，以便通過WinFS對WinFS同步服務3622(如果它能將自身虛擬化為WinFS數據存儲)，或者通過提供與同步API3652的接口3648的同步適配器3662，直接提供與WinFS數據存儲3612的接口3644。
如在此圖中所示的，第一系統3602知道并且直接同步第二系統3604和第三系統3606。然而，第二系統3604和第三系統3606彼此并不知道，并且因此，并不直接彼此同步它們的改變，但是，相反，一個系統上發生的改變必須通過第一系統3602傳播。
C.同步API服務本發明的多個實施例被指向同步服務，所述同步服務包括兩個基礎服務改變枚舉和改變應用。
1.改變枚舉如此處較早之前討論的，改變枚舉允許同步適配器很容易地枚舉改變，所述改變是，自基于由同步服務所保存的改變跟蹤數據，企圖與這個伙伴的同步的最后時刻開始的數據存儲文件夾上已經發生的改變。就改變枚舉而言，針對本發明的多個實施例對給定復制品中與被指定的知識實例有關的項目、擴展和關系的改變的有效枚舉。
·在被指定于WinFS模式中的改變單元粒度的等級上的改變的枚舉·依據復合項目的被枚舉的改變的組。復合項目包括項目、所有其擴展、與所述項目的所有保持關系、以及對應于其被嵌入的項目的所有復合項目。引用項目之間的關系的改變可以被分別枚舉。
·與改變枚舉有關的分類。所述分類的粒度是復合項目或者關系改變(用于引用關系)。
·在改變枚舉期間對復制品中的項目的過濾的指定，例如所述復制品包括給定文件夾中的所有項目，但是對于這種特殊的改變枚舉，所述應用愿意只枚舉對所有聯系項目的改變，其中第一名稱以“A”開始(這種支持將被添加至B-里程碑)。
·用于被枚舉的改變的遠程知識的使用，具有將個別改變單元(或者整個項目、擴展或關系)記錄為在知識上同步失敗的能力，以便下一次重新枚舉時具有它們。
·改進的適配器的使用，所述改進的適配器也許能夠通過在改變枚舉期間隨著改變一起返回元數據，了解WinFS同步元數據。
2.改變應用如此處較早所討論的，改變應用允許同步適配器將從它們的后端接收到的改變應用到本地存儲平臺，因為希望所述適配器將所述改變轉換成存儲平臺模式。就改變應用而言，本發明的多個實施例被指導·具有對應于WinFS改變元數據的更新的來自其它復制品(或非WinFS存儲)中的遞增的改變的應用。
·在改變單元粒度上的與改變應用有關的沖突檢測。
·在改變應用上的個別改變單元級上成功、失敗以及沖突的報告，以便應用(包括適配器和同步控制應用)可以使用要處理的那些信息、錯誤和狀態報告，并且用于更新它們的后端狀態，如果有的話。
·在改變應用期間遠程知識的更新，以便防止在下一個改變枚舉操作期間被提供改變的應用的“沖突”。
·改進的適配器的使用，所述改進的適配器可以隨著改變一起了解并提供WinFS同步元數據。
3.示例代碼下面是用于FOO同步適配器如何可以與同步例程進行交互的編碼示例(其中采用FOO作為所有適配器的專用函數的前綴)ItemContext ctx＝new ItemContext(“\.\System\UserData\dshah\MyContacts”，true)；∥從概況獲得復制品項目id和遠程伙伴id
∥大多數適配器從同步概況獲得此信息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){∥處理所枚舉的對象，適配器完成其自己的模式轉換以及ID映射
∥它甚至可為此目的從Ctx檢索附加對象，∥并在向遠程存儲應用改變之后修改適配器元數據∥ChangeStatus status＝FOOProcessAndApplyToRemoteStore(change)；∥用狀態更新獲知的知識reader.AcknowledgeChange(changeStatus)；}}remoteKnowledge＝ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge()；reader.Close()；∥∥保存更新的知識和適配器元數據(如果有的話)∥ctx.Update()；∥∥改變應用的示例，首先使用如上所述的storedKnowledgeId∥初始化遠程知識∥remoteKnowledge＝...；ctx.ReplicaSynchronizer.ConflictPolicy＝conflictPolicy；ctx.ReplicaSynchronizer.RemotePartnerId＝remotePartnerId；ctx.ReplicaSynchronizer.RemoteKnowledge＝remoteKnowledge；ctx.ReplicaSynchronizer.ChangeStatusEvent+＝FOO_OnChangeStatusEvent；
∥∥從遠程存儲獲得改變。適配器負責從存儲檢索其后端專用元數據。
∥這可以是在復制品上的擴展∥∥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＝@localId”)；searcher.Parameters[“PersonId”]＝localId；Person person＝searcher.FindOne()；∥∥適配器將遠程改變轉換成對個人對象的修改∥作為其一部分，適配器甚至可對遠程對象的∥項目級后端專用元數據作出改變。
∥FOO_TransformRemoteToLocal(remoteChange，person)；
}ctx.Update()；∥∥保存新的錨位(這可以是復制品的擴展)∥FOO_SaveRemoteAnchor()；∥∥這是自從遠程知識未同步以來常規的WinFS API保存∥remoteKnowledge＝ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge()；ctx.Update()；ctx.Close()；∥∥適配器回叫以處理應用程序狀態回叫∥void FOO_OnEntitySaved(object sender，ChangeStatusEventArgs args){remoteAnchor.AcceptChange(args.ChangeStatus)；}4.API同步的方法在本發明的一個實施例中，通過由基于WinFS的硬件/軟件接口系統所公開的同步API，可以實現WinFS存儲和非WinFS存儲之間的同步。
在一個實施例中，要求所有同步適配器實現同步適配器API、由API管理的公共語言運行庫(CLR)，以便它們可以被一致使用、啟動和控制。所述適配器API提供·用于隨著硬件/軟件接口系統同步框架的寄存適配器的標準機制。
·用于適配器表示它們的性能和啟動所述適配器所需的配置信息的類型的標準機制。
·用于將啟動信息傳遞給所述適配器的標準機制。
·用于適配器將過程狀態報告回調用應用的應用的機制。
·報告在同步期間發生的任何錯誤的機制。
·請求正在進行的同步操作的取消的機制。
根據情況的需要，存在兩種可能的用于適配器的處理模型。所述適配器可以在與調用應用的應用相同的處理空間中或者全部在它本身單獨的處理中執行。為了在其自己單獨的處理中執行，所述適配器規定了其自己的工廠(factory)類，所述工廠類被用于例示所述適配器。所述工廠可以在與調用應用相同的處理中返回所述適配器的實例，或者在不同的Microsoft公共語言例程應用范圍或處理中返回所述適配器的遠程實例。默認的工廠實現被提供有在相同處理中哪個例示所述適配器。實際上，許多適配器將在與調用應用相同的處理中運行。出于以下原因中的一個或兩個，通常要求有處理模型的輸出·安全目的。所述適配器必須在某個處理或服務的過程空間中運行。
·所述適配器必須處理來自其它源的請求——例如，收入網絡請求——除了處理來自調用應用的請求之外。
參見圖37，本發明的一個實施例假設了一個簡單的適配器，它不知道如何計算狀態或者如何交換其相關元數據。在這個實施例中，就想要同步的數據源而言，首先，在步驟3702，確定自它與所述數據源最后同步開始哪些改變已經發生，通過所述復制品實現同步，并且然后所述復制品基于其當前狀態信息傳輸自這個最后的同步開始已經發生的遞增的改變，并且這種當前狀態信息和遞增的改變通過所述適配器傳輸給所述數據源。在步驟3704，所述適配器，一旦在之前步驟中接收到來自所述復制品的改變，就盡可能多地實現對數據源的改變，跟蹤哪些改變成功了并且哪些失敗了，并且將所述成功和失敗信息傳輸回(所述復制品的)WinFS。在步驟3706，所述復制品(WinFS)的硬件/軟件接口系統一旦從所述復制品中接收到成功和失敗信息，就為所述數據源計算新的狀態信息，存儲這種信息以供將來由其復制品使用，并且將這種新的狀態傳輸回所述數據源，也就是，傳輸給用于存儲的適配器并且以后由所述適配器使用。
D.同步層次如此處較早所討論的，根據每一個這種被分配對應的遞增的順序的改變號(即，第一個改變是1，第二個改變是2，第三個改變是3，等等依此類推)，每個復制品保存其改變的遞增的并且順序的枚舉。還有，每個復制品還保存用于用于其同步共同體中的其它已知復制品(同步伙伴)的狀態信息，以便跟蹤它已經從這些其它復制品中接收了哪些改變。通過知道應用給來自第二個復制品的第一個復制品的最后的改變的改變號，然后第一復制品可以使用這個編號來只對大于這個最后被應用的改變的編號的那些改變進行請求、接收、或者處理。圖38A-D示出了如何使用這種順序的改變枚舉方法來跟蹤、枚舉、以及同步改變。
在圖38A中，同步伙伴A和B公共同步共同體中的復制品，并且以其父狀態示出，因為還沒有進行改變，所以對于各個復制品，所述父狀態等于改變號0—-例如對于各個復制品分別為A0和B0。(在這個實施例中，使用唯一的改變號反映初始狀態。)各個復制品知道其自己的狀態并且跟蹤其同步伙伴的狀態，在如此處所示的它的“向量”(如所示，向量列出了復制品自己的狀態，第一個后面是其伙伴的每一個的最后的已知狀態，基于最后的同步或者在這種情況下的啟動，)中，各個復制品反映這種信息。用于復制品A的初始向量是“[A0，B0]”，并且用于復制品B的初始向量是“[B0，A0]”，并且兩個復制品目前是完全同步的。
在圖38B中，復制品A進行改變并且為那個改變分配唯一的遞增的改變號A1(該改變號包括用于復制品本身的唯一標識“A”，以及用于在那個復制品上的改變的唯一的遞增的號碼“1”)。另一方面，復制品B進行2個改變，并且為那些改變分別分配唯一的遞增的改變號B1和B2。在這一點上，并且在下一次同步之前，所述復制品現在沒有同步，并且用于復制品A的向量現在是[A1，B0]，且用于復制品B的向量是[B2，A0](再者，該向量反映了已知的最后改變。)在圖38C中，通過向復制品B發送其當前向量以便請求改變，復制品A與復制品B同步(步驟1)。一接收到復制品A的向量，復制品B就計算它需要發送給復制品A的兩個改變B1和B2，并且因此繼續這么做(步驟2)。復制品A接收被標識為B1和B2的復制品B的改變(也就是，改變單元)，應用它們，并且將其自己的向量更新為[A1，B2](步驟3)。
在如圖38D中所示的可替換實施例中，隨著計算并向復制品A發送正確的改變(步驟2)，復制品B還基于復制品A的向量確定已經對復制品A進行了改變而尚未對復制品B進行改變，并且因此復制品B還將其自己的向量以及用于改變的請求發送給復制品A(步驟2’)。然后，當復制品A接收到復制品B的改變時，應用它們，并且將其自己的向量為[A1，B2](在步驟3期間)，它還計算其哪個改變要發送給復制品B并且同樣傳輸它們(步驟3’)。一旦接收到這個信息，復制品B就進行所述改變并且將它的向量更新為[B2，A1](步驟4)。
關于之前所述的例子，可能在許多情況下會引發沖突。例如，A1和B2也許已經對相同的改變單元進行了改變，或者A1會對B2正在修正的相同的改變單元進行刪除。雖然使用此處較早所討論的沖突分解選項可以分解這些沖突中的一些，但是某些沖突提供了顯著不同的難題，并且在此下面根據當前的例子討論這些難題及其分解方法。
1.同步早先的“范圍外”的改變在本發明的某些實施例中，復制品的范圍可以不是靜態的。因此，采用在位于復制品A的范圍內的項目和不在其范圍內的項目之間創建新的關系的改變，復制品A可以有效地增加其范圍。然而，假設用于范圍外的項目的改變單元尚未被同步于復制品A和B之間(因為它已經位于用于這些復制品的同步范圍之外)，就用于特定項目的版本路徑而言，可能會造成同步不一致。解決這個問題的方法是隨著創建復制品A中范圍內的項目和范圍外的項目之間的關系的特定改變，對于復制品A向復制品B發送已經對范圍外的項目進行了的所有改變。
2.同步父—子無序化在本發明的某些實施例中，對于同步而言，父項目總是在子項目之間被發送(例如，如果作為孩子的項目K被嵌入在作為父親的項目J中，則項目K不能在傳輸項目J之前被傳輸)，這是一般的原理。然而，對于復制品A而言，這是可能的，在同步之間，項目J和K被改變，但是其中孩子項目K具有比孩子項目J小的分類號(基于，例如，其標識號的順序的優先地位)，并且因此一般會被首先傳輸。在本發明的各個實施例中，用于解決同步的問題的一種方法是，將所述改變分成兩組，一組只反映對項目K進行的改變，而第二組只反映對項目J進行的改變，并且以恰當的順序發送它們(也就是，在發送了用于父項目J的改變的組之后，發送用于子項目K的改變的組)。
3.墓碑傳播如在此較早所討論的，出于同步的目的，墓碑被用于標記已經被刪除的改變單元。然而，由于對于同步共同體中的多個向量而言同步是非同步的，所以這些墓碑可以在整個數據平臺上傳播。問題是，在沒有說明墓碑傳播的情況下，復制品A可以創建一個項目，并且在與復制品B同步期間，將那個項目發送給復制品B。然后，復制品A可以刪除所述項目，并且在與復制品C同步期間，它不發送與所述項目有關的任何信息，因為沒有要發送的信息(因為所述項目被刪除了)。接著，當復制品B和復制品C試圖同步時，復制品C可以從復制品B中接收所述項目，并且在B上持續。
對于本發明的各個實施例而言，解決這個問題的方法是，對于復制品A采用墓碑標記被刪除的項目。接著，當復制品A刪除所述項目時，在與復制品C同步期間，它將所述墓碑發送給復制品B。當復制品B和復制品C接著試圖同步時，復制品B同樣接收所述墓碑，并且所述項目現在完全從所述同步共同體中被刪去了。
4.根墓碑傳播在P1中，如果項目X具有多個被嵌入項目A、B、C、D和E，那么當P1首先刪除這些子項目并且其次刪除同步之間的父項目X時(即，刪除A、刪除B、刪除C、刪除D、刪除E和刪除X，作為6個改變)，引發一種有意思的情況，因為相同的最終結果可能已經發生，P1已經簡單地刪除了父親X(1個改變)，在這種情況下，被嵌入的項目可能也會被自動地刪除。在這方面，本發明的多個實施例，一旦同步，就通過確認刪除X可能事實上與6個單獨的刪除事件是等效的，獲得功效，并且因此P1可能只向P2發送對應于X的刪除的改變單元，并且允許這種刪除，以便自然地傳播給P2中的X的被嵌入的項目。
5.關系名稱交換如之前所討論的，關系具有名稱，并且因此對于一個復制品(P1)可以通過使用臨時名稱元素(X)來交換用于兩個關系(R1和R2)的名稱——也就是，R1的名稱被復制給X，R2的名稱接著被復制給R1，接著X被復制給R2，并且最后刪除X。然而，因為伙伴復制品(P2)不知道臨時名稱元素X，所以在同步期間將會造成錯誤，因為確認R1具有新名稱，P2試圖改變這個名稱，導致錯誤地為R1和R2使用相同的名稱。對于本發明的各個實施例，解決這個問題的一種方法是，一旦接收到或者確認這種相同名稱錯誤，就假設一種可行的名稱交換情況，并且自動地創建其自己的臨時名稱元素(X)，并且如果連續的改變的確解決了將R2重命名為X中的名稱，那么它就完成了這種交換(否則，它產生所述情況作為常規沖突事件)。
6.引用關系對于復制品P1(在WinFS系統上運行)和數據源P2(在非WinFS系統上運行)之間的同步，引發一個問題，在搖擺關系(被WinFS支持)情況中，不被非WinFS系統支持。當兩個項目A和B具有在P1上的關系R，并且P1以A(P1-21)然后R(作為改變單元P1-22)然后B(作為改變單元P1-23)的順序創建它們時，會引發這個問題。當創建R(P1-22)時，R是搖擺關系，所以當P2順序地應用這些改變時，會導致不允許的搖擺關系錯誤。對于本發明的多個實施例而言，解決這個問題的方法是，改為重新排序所述改變，以便在所有其它改變從P1被發送到P2之后，可以發送所有的引用關系(例如，R)，并且因此，通過首先創建項目A和B并且然后采用R將它們彼此相關，共同避免了這個問題。
E.同步—沖突處理如在此較早所提及的，同步服務中的沖突處理被劃分為3個階段(1)沖突檢測，發生在改變應用的時候——這個步驟確定改變是否已經被安全地應用；(2)自動的沖突分解和記錄——在這個步驟期間(檢測到沖突之后立刻進行)考慮自動的沖突處理器以便明白所述沖突是否已經被分解——如果沒有，則可以可選擇地記錄所述沖突；以及(3)沖突檢查和分解——如果一些沖突已經被記錄則進行這個步驟，并且發生在同步會話的環境之外——此時，被記錄的沖突可以被分解并從所述記錄中刪除。
本發明的各個實施例尤其被指向對發生在對等同步系統(例如，用于在此以上所述的同步系統)中的沖突的沖突處理。準確地并且有效地處理沖突的能力最小化數據丟失，而保留了好的使用性，并且減少了在同步期間對用戶干預的需要。本發明的多個實施例被指向沖突處理模式，包括以下沖突處理元素中的一個或多個(a)沖突的模式化表示；(b)沖突的檢測；(c)沖突向永久存儲中的記錄；(d)按照靈活的并且可配置的沖突分解策略的沖突的自動分解；(e)可包括且可擴展到過濾器并分解沖突的沖突處理器；(f)自動檢測和已廢棄沖突的移除；以及(g)有計劃的沖突分解。還有，脫開沖突處理模式，這些沖突處理元素中的每一個本身都是本發明的有代表性的附加實施例。
1.沖突類型通常，無論何時不能在同步操作期間同步數據(“改變應用失敗”)，就會引起沖突。這些失敗可以是因為許多原因而造成的，盡管一般沖突可以被劃分為兩類約束沖突和知識沖突。
a)基于知識的沖突當兩個復制品對同一改變單元進行獨立的改變時，會造成基于知識的沖突。如果兩個改變是在彼此沒有知識的情況下進行的，則這兩個改變被稱作為是獨立的——換言之，第一個的版本沒有被第二個的知識覆蓋，反之亦然。基于如以上所述的復制品的知識，所述同步服務自動地檢測所有的這種沖突，并且處理這些沖突，在此如下面所述。一些特定類型的知識沖突包括更新—刪除、刪除—更新以及更新—更新沖突(其中每個名稱是指依次是本地動作和遠程動作；例如，更新—刪除沖突是由于對同一數據的本地更新和遠程刪除)。
有時，將沖突認為是改變單元的版本歷史中的分叉是有幫助的。如果在改變單元的生命中沒有沖突發生，則其版本歷史就是一個簡單的鏈——每個改變都在之前的一個后面發生。在基于知識的沖突的情況中，兩個改變并行發生，使得所述鏈分裂并且變成版本樹。
總體上，知識沖突按照知識和版本處理的結果發生。當應用具有與被存儲在數據庫中的信息相沖突的版本的改變時，由WinFS同步創建知識。所述沖突需要包括沖突改變信息，以及版本信息。大多數對知識沖突的要求也是對約束沖突的要求。然而，在同步版本和知識的基礎上，知識沖突可以被單獨地檢測。
b)基于約束的沖突存在一些情況，在這些情況下，當一起被應用時，獨立的改變妨礙了完整性約束。例如，在相同目錄中創建具有相同名稱的文件的兩個復制品會使得這樣的沖突發生，其中系統中的約束(例如，文件夾中唯一的項目名稱的施加)導致了這種類型的基于約束的沖突。
一般地，基于約束的沖突包括兩個獨立的改變，正如用于基于知識的沖突；然而，基于約束的沖突包括不影響相同改變單元但相反影響不同改變單元的在它們之間存在約束的改變。基于約束的沖突可以從單個改變中引發，例如當兩個不同類型的類型之間同步其中一個具有約束而另一個沒有時。例如，如果一個系統具有最大文件名長度是八個(8個)字符長的約束，并且如果那個系統接收到來自另一個不具有這種約束的對文件的改變，其中所述改變是針對文件名使得文件名比8個字符長更長，就導致了約束沖突(從一個單個機器中的單個改變中發生)特殊類型的約束沖突包括但并不限于·插入—插入沖突當兩個同步伙伴的每一個都創建具有相同邏輯標識符的對象例如具有相同名稱的文件時發生。
·無父沖突當要創建的引入對象的父親不存在時發生。一個例子是當在文件的父文件夾之前接收一個文件時。
·未規定類型的沖突當引入對象的模式沒有被示出從而防止創建所述對象時發生。
總之，約束沖突是通過由于各種原因應用改變的錯誤引發的。如果采用最終導致減小的分解方法的形式，能夠有針對性地被處理，或者如果它們能夠被記錄以用于最終通過用戶交互分解，則這種錯誤被稱為約束沖突。不能被有針對性地處理而是被報告的錯誤簡稱為改變應用錯誤。對于某些實施例，所有改變應用錯誤都被看作是錯誤——也就是，沒有被承認的約束沖突。而對于某些實施例，由于期望在下一次接收同步時表示知識沖突，所以在發送同步期間發生的所有沖突可以被忽略。(導致沒有減小的其它錯誤也可以被忽略。)2.沖突檢測所述同步服務在改變應用時檢測約束違規，并且自動地引發基于約束的沖突。分解基于約束的沖突通常要求自定義碼采用與沒有違反所述約束的方式修正所述改變，并且同步服務可以或可以不提供用于這么做的通用機制。
對于本發明的各個實施例，通過檢驗本地知識是否知道遠程版本并且反之亦然，每個改變單元檢測沖突。對于基于知識的沖突，在此有4種沖突檢測情形1.知道遠程版本的本地知識，知道本地版本的遠程知識這意味著引入的改變是已廢棄的，并且因此進行被丟棄。
2.不知道遠程版本的本地知識，知道本地版本的遠程知識這意味著引入的改變比本地版本更新，并且因此接受。
3.知道遠程版本的本地知識，知道本地版本的遠程知識。這可能只發生在如果兩個版本等效的時候，并且因此沒有改變被應用。
4.不知道遠程版本的本地知識，不知道本地版本的遠程知識。這意味著本地和遠程版本相沖突，并且因此引發沖突。
3.沖突處理沖突可能發生在發送或者接收同步期間；然而，如果在單向同步操作中兩個伙伴類似(例如，在WinFS存儲中兩者被類似地配置)，則情況是相對稱的，并且通過自動分解所述同步上的沖突或者記錄所述沖突以供異步分解(自動或人工)，在接收端，是最容易被處理的。
當然，存在發送伙伴可能需要處理例如在WinFS對非WinFS同步中的沖突的情況。在這種情況下，在順序的接收同步中，約束沖突可能不會傳播回所述發送伙伴。還有，接收伙伴可能不具有沖突記錄，或者可能需要使用發送者的沖突記錄以易于管理。在這種情況下，改變可能會被一起拒絕，以便迫使發送這分解所述沖突(此處下面進行討論)。
同步啟動器配置其同步概況中的沖突分解。所述同步服務支持在單個概況中聯合多個沖突處理器。因為沖突處理機制是可擴展的，所以存在多種方式聯合多個沖突處理器。一種特定的方法包括指定沖突處理器的列表一個接一個地進行嘗試，直到其中一個成功為止(此處如下面所述)。另一種方法包括將沖突處理器與沖突類型相關聯，例如，將更新—更新基于知識的沖突指向一個沖突處理器，而將所有其它沖突指向記錄。
當檢測到沖突時，同步服務可以采取3個動作中的一個(由同步概況中的同步啟動器選擇)(1)拒絕改變；(2)自動分解沖突；或者(3)將沖突記錄到沖突記錄中。
a)拒絕改變如果拒絕改變，那么如果改變沒有到達所述復制品并且否定的應答被發送回啟動器，則同步服務起作用。這種分解策略簡單地用在沒有標題的復制品(例如文件服務器)上，其中記錄沖突是不可行的。相反，這種復制品向其它的復制品通過拒絕處理所述沖突。
b)自動沖突分解自動沖突分解是按照所指定的策略分解同步上的沖突的過程。在WinFS同步操作中，可以獨立地指定策略，以便發送操作和接收操作。自動沖突分解策略可以通過同步概況來指定。所引發的沖突被傳遞給所述概況中指定的頂級沖突處理器。這種沖突處理器可以分解所述沖突、記錄它、或者將所述沖突傳遞給另一個沖突處理器，以便進一步隨著沖突處理流水線進行處理。
圖39A示出了用于本發明的多個實施例的沖突處理流水線。在此圖中，當沖突發生時，沖突處理器列表(或者“列表”)3910接收沖突項目3902，并且在所述流水線的第一路徑上將所述沖突傳遞給第一處理器3912，在這種情況下，第一處理器是過濾器。所述過濾器3912是監視定時器(watchdog)，它估計所述沖突3902，并且讓它傳遞給下一個處理器3914或者拒絕回所述列表3910，然后，列表3910將它傳遞回列表3912，依次，將它傳遞回位于所述流水線上的下一個路徑的第一處理器3922。如果由第一過濾器3912將所述沖突3902傳遞給第二處理器3914，在這種情況下，是分解器，那么如果可能的話所述沖突被分解器3914分解，或者如果不可能，則將所述沖突拒絕回第一處理器3922。接著，所述沖突繼續通過流水線進行處理，直到(a)由流水線中的處理器中的一個分解了為止，(b)通過特定的沖突處理器熟稱“記錄器”明確地記錄到沖突記錄上，所述記錄器例如記錄器3936(也就是，如果沖突使它傳遞給過濾器3934)為止，或者(c)完全被傳遞回流水線外部，并且默認地被發送回沖突記錄(用虛線邏輯地示為記錄器3944)。
圖39B是示出了圖39A中所示的流水線的邏輯移動的流程圖。在圖39B中，并且還參照圖39A，在步驟3950，沖突3902進入沖突處理器列表3910上的流水線，并且在步驟3952被初始發送給過濾器3912。如果在步驟3954，沖突3902傳遞給此過濾器3912，那么在步驟3956所述沖突3902進行到分解器3914，在步驟3958，所述分解器3914試圖分解所述沖突3902。如果成功，則在步驟3998，處理返回；否則，在步驟3960沖突進行到分解器3922，在步驟3962，分解器3922試圖分解沖突3902。如果成功，在步驟3998，處理返回；否則，在步驟3964，沖突進行到列表3932，并且在步驟3966，從這里到過濾器3934，并且如果在步驟3968，沖突傳遞給此過濾器3934，在步驟3972，那么在步驟3970，由記錄器3936將沖突記錄到沖突記錄(未示出)中，并且，在步驟3998，處理返回；否則在步驟3972，沖突3902被發送給過濾器3938，并且如果在步驟3974沖突3902傳遞給此過濾器3938，那么在步驟3976，沖突3902進行到分解器3940，在步驟3982，分解器試圖分解沖突3902。如果成功，在步驟3998，處理返回；否則，在步驟3984，由分解器3936將沖突3902記錄到沖突記錄(未示出)中，并且在步驟3998，處理返回。
盡管在圖39A和39B中沒有示出，但是應當注意，連續的沖突分解器的路徑也可以構造，其中，如果沖突不可能被一個分解器分解，則將沖突傳遞給下一個分解器，然后力圖分解所述沖突，等等，依此類推。如果沖突持續未被分解恰好在路徑的結尾處，那么沿著所述路徑將沖突傳遞回列表，以便繼續下一條路徑。類似地，一旦用于列表的所有路徑都已用盡，并且沖突仍未分解，那么列表沿著其路徑傳遞沖突，直到它到達下一個列表，等等，依此類推。
也很重要的是注意，流水線不必以列表開始；相反，它可以以任何類型的沖突處理器諸如，例如過濾器開始。然而，無論如何，如果沿著路徑將沖突傳遞回流水線中的第一沖突處理器，并且那個沖突處理器沒有另外的路徑用以嘗試(可能只是用于沖突處理器列表的情況，其中所有路徑都沒有嘗試)，那么沖突傳遞到流水線的外部，并且自動地并且默認地被記錄到沖突記錄。
ConflictHandler類型是用于沖突處理器的基本類型，包括沖突處理器列表、沖突記錄、以及沖突過濾器、以及其它類型的沖突處理器。此外，所述同步服務也可以提供許多默認的沖突處理器，包括但并不限于·本地優勝通過選擇本地存儲的數據作為對引入數據的優勝者，分解沖突·遠程優勝通過選擇引入數據作為對本地存儲的數據的優勝者，分解沖突；·最后寫入者優勝基于改變單元的時間戳，挑選本地優勝者或者遠程優勝者(注意，通常同步服務不依賴于時間值；這種沖突分解器對于那個規則是惟一例外)；·確定性的以保證在所有復制品上相同的方式，挑選優勝者，但不是另外的有意義的——同步服務的一個實施例可能使用伙伴ID的字典編輯上的對照來實現這個特征。
例如，沖突處理器可以規定，對于更新—刪除沖突，應當應用本地優勝者分解方法，而對于所有其它沖突，應當應用最后寫入者優勝者分解方法，如下<conflictHandlerListxmlns＝”http∥schemas.microsott.com/winfs.2003/10/conficts”>
<conflictFilterxmlns＝”http∥schemas.microsoft.com/winfs.2003/10/conflicts”>
<conflictType>UpdateDeleteConflict</conflictType><conflictResolver><ResolutionType>LocalWins</ResolutionType></conflictResolver>
</conflictFilter><conflictResolver><ResolutionType>LastWriterWins</ResolutionType></conflictResolver>
</conflictHandlerList>
當然，如果沒有指定沖突處理器，或者如果沒有通過任何被指定的沖突處理器處理沖突，那么沖突就被放置在沖突記錄中。對于某些實施例，沖突記錄也是沖突處理器。
對于本發明的各個實施例，ISV可以實現并且建立其自己的沖突處理器。客戶沖突處理器可以接受配置參數，盡管這種參數必須由同步概況的沖突分解部分中的SCA來指定。
當沖突分解器處理沖突時，它將需要執行的操作的列表(代替沖突改變)返回給所述例程。然后，所述同步服務應用這些操作，適當地調整遠程知識，以便包括沖突處理器已經考慮過的信息。
可能在應用所述方法的同時檢測到了另一個沖突。在這種情況下，在重新進行初始處理之前，新的沖突必須被分解或被記錄。
當將沖突看作項目的版本歷史中的分支時，沖突分解可以被看作接點——聯合兩個分支以便形成單獨的點。因此，沖突分解將版本歷史成為有向無回路圖形(DAG)。
c)沖突日志記錄雖然被報告的沖突可以使用自動沖突分解來同步地分解，但是其它的沖突可能被記錄日志以供以后有計劃的分解。沖突日志記錄允許沖突分解處理同步地進行——也就是，沖突不必在它們被刪除的時候才能分解，而是可以被記錄日志以供將來分解。例如，沖突觀察器應用可以允許用戶檢查并且在是事實之后人工地分解被記錄日志的沖突。
對于本發明的多個實施例，非常特殊的類型的沖突處理器是沖突日志記錄器(或者，更簡單地，“日志記錄器”)。所述同步服務將沖突記錄在沖突日志中作為類型ConflictRecord的項目(或者，在替換實施例中，簡單地作為類型Confict)。這些日志返回來與沖突中的項目有關(除非所述項目本身已經被刪除)。對于某些實施例，各個沖突日志包含引發沖突的引入改變；沖突的類型(例如，更新—更新、更新—刪除、刪除—更新、插入—插入，或者約束)；以及引入改變的版本和發送它的復制品的知識。對于本發明的某些可替換實施例，每一個這種沖突項目都包含沖突改變數據和元數據、沖突的說明以及其它環境信息例如改變應用器信息、建立數據、以及遠程伙伴名稱。此外，以不能被用于應用所述改變的方式，存儲所述改變數據。還有，對于本發明的各個實施例，從沖突中派生出的各個類型可以添加與那個類型的沖突有關的新的字段。例如，InsertInsertConflict添加引起違反唯一性約束的項目的項目ID。
對于本發明的多個實施例，要被記錄日志的沖突項目還將包括目標項目的復制，作為對沖突項目的擴展，或者僅僅作為也被存儲在沖突記錄中、具有它和沖突項目本身之間所規定的關系、或者可替換地作為沖突項目本身的一部分(例如一組屬性值對)。作為沖突日志中的沖突項目的一部分或者與沖突項目一起被存儲(被保存在永久數據存儲上)的這個目標項目，將反映特定的改變引發了第一位置中的沖突。圖40是示出了使用示例性聯系項目的這種方法的方塊圖。在這個例子中，聯系項目4002(“目標項目”)包括名稱字段4004，名稱字段4004最初被設置為“John”，作為最后成功的同步的名稱。這個字段4004接著本地地被本地系統改變為“Bob”。在隨后的同步期間，如果將這個名稱字段4004改變為“Jane”的企圖引起了沖突，因為本地系統不可能查明應當應用哪個名稱改變“Bob”或者“Jane”，那么本地改變(“Bob”)被保留，而隨著沖突項目4002’的復制一起，沖突4006被記錄在沖突日志4008中，沖突項目4002’反映了導致沖突的改變的應用(“Jane”)。以這種方式，沖突日志包括引發沖突的完整目標項目，并且這個特定的目標項目被更新，以便反映試圖在導致沖突的項目上進行的改變。
為了將沖突添加到沖突日志，首先搜索日志，以便確定在相同的改變單元(多個)上是否存在其它沖突。如果在相同的改變單元上存在任何現有的沖突，則檢查它們以便可以移除。如果改變知道的現有沖突被改變知道的新的沖突包含，則移除現有的沖突。另一方面，如果改變知道的新的改變被改變知道的現有被記錄日志的沖突包含，則刪除新的沖突，反之亦然(也就是，如果它知道的被知道的存儲包含，例如當所述存儲接受并且成功地應用了包含知道的沖突的改變時，沖突也被變為已廢棄的)。在第三種情況下，其中兩個改變知道中的任何一個包含另一個，則新的沖突被添加到所述日志，并且對應于相同的改變單元的兩個沖突存在于所述日志中，直到后來被人工地或者自動地分解為止。
d)沖突檢查和分解所述同步服務提供用于應用的API，以便檢查所述沖突日志，并且建議其中的所述沖突的分解方法。API允許應用枚舉所有沖突或者與給定的項目有關的沖突。它還允許這些應用以3種方式中的一種方式分解被記錄日志的沖突(1)遠程優勝——接受被記錄日志的改變并且覆蓋所述相沖突的本地改變；(2)本地優勝——忽略所述被記錄日志的改變的沖突部分；以及(3)建議新的改變——其中所述應用建議一種兼并(merge)，在其看法中，分解所述沖突。一旦由應用分解了沖突，所述同步服務就將它們從日志中刪除。
e)復制品的減小和沖突分解的傳播在復雜的同步情形中，在多個復制品上可以刪除相同的沖突。如果發生了這種情形，則許多事情都可能發生(1)在一個復制品上可以分解所述沖突，而所述分解方法被發送給另一個；(2)在兩個復制品上自動分解了所述沖突；或者(3)在兩個復制品上人工地分解了所述沖突(通過沖突檢查API)。
為了確保減小，所述同步服務將沖突分解方法傳遞給其它復制品。當分解沖突的改變到達復制品時，所述同步服務自動地找到所述日志中的通過這種更新分解了的任意沖突記錄，并且刪除它們。在這種情況下，一個復制品上的沖突分解方法將捆綁在所有其它復制品上。
如果對于相同的沖突，由不同的復制品選擇不同的優勝者，則所述同步服務應用捆綁沖突分解方法的原理，并且自動地挑選兩種分解方法中優于另一種的一種分解方法。以確定的方式，挑選出所述優勝者，以保證在所有的時候都生成相同的結果(一個實施例使用復制品ID詞典編輯上的對照)。
如果對相同的沖突，不同的復制品建議不同的“新改變”，則所述同步服務將這種新的沖突看作特殊的沖突，并且使用沖突日志記錄器來防止它傳播到其它復制品。這種分解方法通常會引起人工的沖突分解方法。
D.同步模式和沖突處理模式的附加方面下面是用于本發明的各個實施例的同步模式的附加(或更特殊的)方面。
·每一復制品是來自整個數據存儲的數據的定義的同步子集一具有多個實例的一段數據。
·在同步模式的根上，是具有定義具有唯一ID的根文件夾(事實上，是根項目)的基礎類型的復制品，ID用于同步它是其成員的共同體，并且任何過濾器和其它元素對于特定復制品都是必須或期望的。
·每一復制品的“映射”被維持在所述復制品中，并且因而，用于任何特定復制品的映射被限定在這個復制品知道的其它復制品上。雖然這種映射可以只包括整個同步共同體的子集，但是通過公共地共享的復制品，所述復制品的改變將仍被傳播給整個同步共同體(盡管任何特定的復制品不知道與未知的復制品公共地共享哪些其他復制品)。
·同步模式和復制品的使用允許真正的分布式對等多標準同步共同體。還有，不存在同步共同體類型，但是同步共同體簡單地作為復制品本身的共同體字段中的一個值存在。
·每一復制品具有其自己的元數據，以便跟蹤遞增的改變枚舉并且存儲同步共同體中已知的其它復制品的狀態信息。
·改變單元具有其自己的元數據，包括版本，包括伙伴關鍵字加上伙伴改變號；每一改變單元的項目/擴展/關系版本；與復制品已經從同步共同體中看到的/接收到的改變有關的知識；GUID和本地ID配置；以及被存儲在引用關系上的用于清除的GUID。
下面是用于本發明的各個實施例的沖突處理模式的其它方面。
·由各個復制品(以及適配器/數據源地組合)各自地處理沖突分解策略——也就是，各個復制品能夠基于其自己的標準和沖突分解模式分解沖突。還有，雖然數據存儲的各個實例中的區別可能得出并且導致附加的未來沖突，但是對于接收到那種被更新的狀態信息的其它復制品而言，如被更新狀態信息中所反映的沖突的遞增且連續的列表是不可見的。
·同步模式包括可以用于所有復制品的多個預定沖突處理器，以及用于用戶/開發者規定的客戶沖突處理器的能力。所述模式還可以包括3個特殊的“沖突處理器”(a)沖突“過濾器”，以不同的方式分解分解不同的沖突，所述分解是基于，例如(i)當在兩個位置中改變了相同的改變單元時，如何處理，(ii)當在一個位置中改變了改變單元而在另一個中進行了刪除時，如何處理；以及(iii)當在兩個不同的位置中兩個不同的改變單元具有相同的名稱時，如何處理；(b)沖突“處理器列表”，其中列表的各個元素指定一系列動作以便輪流嘗試，直到成功地分解了所述沖突為止；以及(c)“什么都沒做”的記錄，跟蹤所述沖突，但是在沒有用戶干預的情況下不采取進一步的動作。
IV.通過中介同步最初采用此處描述的新存儲平臺，具有包括各種個別計算機系統的同步網絡的企業將具有一種混合，其中某些個別計算機系統將使用新存儲平臺，而其它個別計算機系統將繼續使用傳統存儲平臺。這在其中兩臺客戶機包括新存儲平臺，但服務器包括傳統存儲平臺的任何客戶機-服務器結構中尤其重要。因此，在這些情況下，使用新存儲平臺的兩臺計算機系統(“客戶機”)可能有必要通過使用傳統平臺的計算機系統(“中介”)同步。例如，某些客戶機可能使用諸如漫游擁護概況(RUP)或具有客戶機方高速緩存(CSC)的文件夾重定向等軟件在傳統漫游服務中登記。由于用于這些傳統存儲平臺的傳統漫游軟件不支持用于新存儲平臺的漫游數據，因此用于新存儲平臺的新漫游服務是必需的。本發明的各實施例針對一種系統和方法，用于通過中介同步使用公用存儲平臺(例如，相關發明的新存儲平臺)的客戶機，而中介不使用同一公用存儲平臺(例如，作為替代，使用本身不支持新存儲平臺的同步的傳統存儲平臺)。
A.中介的數據結構本發明的若干實施例針對在復制品客戶機和非復制品中介之間存在和操作的“通過中介同步”(STI)適配器。對于這些實施例，STI適配器被設計成將來自復制品客戶機的改變枚舉的結果串行化到非復制品中介，以及將來自非復制品中介的這些改變結果反串行化到復制品客戶機。
圖41所示是其中兩臺客戶機必需通過中介同步的情形的框圖。圖中，使用傳統存儲平臺(例如，Win32)的中介計算機系統連接到都使用新存儲平臺(例如，此處描述的相關發明的實施例，為方便起見，后文稱為“WinLH”，WinLH包括此處所稱的WinFS文件系統，如圖所示)的客戶機A 4112和客戶機B 4114兩者。中介4102可以被認為僅僅是從客戶機A 4112同步到客戶機B 4114以及從客戶機B 4114同步到客戶機A 4112的改變的“通過”。由此，中介4102本身不為其自身的目的而與客戶機A 4112或客戶機B 4114同步，并且因此不直接使用它從客戶機A 4112或客戶機B 4114接收到的任何改變數據。為此，使用本文中先前所使用的術語，中介4102不是復制品，盡管作為復制品的客戶機A 4112和客戶機B都如同中介4102是復制品那樣通過“通過中介同步”(STI)適配器與其交互。
客戶機A 4112和客戶機B 4114分別通過STI適配器4122和4124與中介4102接口，所述STI適配器被特別地定制以在客戶機4112和4114的新存儲平臺和中介4102的特定傳統平臺之間接口。本發明的若干替換實施例針對對應于中介可能需要與其同步的若干傳統存儲平臺的若干特定STI適配器。這使得客戶機4112和4114仍能夠如同中介4102是復制品那樣邏輯上與其同步(通過STI適配器4122和4114)，盡管實際上使得同步成功的是對客戶機本地的STI適配器。
對于將改變枚舉的結果從復制品客戶機串行化到非復制品中介，每一串行化對應于被被到要寫入中介的文件的三元組中的一批改變。對于某些實施例，這些文件被寫入對應于特定同步共同體的特定文件夾(“共同體文件夾”)，并且不同的同步共同體將具有不同的共同體文件夾。上述文件的三元組包括改變數據文件(CDF)、先決條件知識文件(PKF)、以及已獲知知識文件(LKF)。CDF包含涉及在改變單元級對于WinFS項目的特定改變的信息。PKF指定了同步對等體必須已經知道什么以應用相關聯的改變。另一方面，LKF指定了如果同步對等體應用相關聯的改變，則它必須獲知什么。為了效率起見，且類似于對等同步，STI適配器僅串行化改變單元信息(“改變的部分”及其相關聯的元數據)，且對于若干實施例，該數據可能僅包含(對于項目的特定改變)項目類型、項目版本號、改變單元版本以及所改變的屬性的值。對于各實施例，文件的三元組使用基于串行化的消息序列的順序命名約定寫入中介中(為了后文所討論的原因)；例如，第一串行化可包含儲存為中介上的1.PKF(PKF文件)、1.CDF(CDF文件)和1.LKF(LKF)文件的三個文件，第二串行化可包括2.PKF、2.CDF和2.LKF，依此類推。
B.STI適配器進程對于本發明的若干實施例，STI適配器包括三個核心操作發送同步、接收同步和數據壓縮。
1.發送同步操作圖42所示是客戶機通過STI適配器向中介發送改變數據(“發送同步”操作)的步驟的流程圖。在步驟4202，STI適配器首先確認中介上是否存在對應于客戶機的同步共同體的共同體文件夾。如果是，則在步驟4204，STI適配器然后掃描和反串行化中介的共同體文件夾中的LKF的所有內容，以確定對于該同步共同體的中介的本地知識(ILK)的當前狀態。另一方面，如果沒有共同體文件夾，則在步驟4206ILK被認為是空的，并且在中介上創建一共同體文件夾。
在步驟4208，STI適配器并發地獲取中介的共同體文件夾上的“寫模式”進程鎖(通過中介的文件系統)，以通過防止其它客戶機(或其它對等體或進程)在發送同步操作過程中讀取或寫入共同體文件夾來保持數據的完整性。在步驟4210，STI適配器然后將ILK傳遞到客戶機。基于IKL及其自己的客戶機本地知識(CLK)，在步驟4212，客戶機確定是否有ILK沒有傳達的任何改變，如果否，則過程跳至步驟4220。另一方面，如果客戶機確定存在ILK沒有傳達的改變，則在步驟4214，客戶機準備ILK沒有傳達的所枚舉的改變，并將它們傳遞到STI適配器。在步驟4216，STI適配器串行化每一批改變信息(改變數據和知識)，并且在步驟4218，當順序地遞增如上所述的文件的三元組時，STI適配器然后將串行化的批量改變寫入中介的共同體文件夾中。一旦所有的串行化的批量改變被寫入中介中，在步驟4220，STI適配器然后釋放“寫模式”進程鎖，以允許其它客戶機(或其它對等體或進程)檢查中介上更新的內容。
盡管完成了發送同步操作，應當注意，STI適配器儲存了寫入中介中的最后一個且最高的順序遞增的改變三元組(HCT)的身份(或參考號)以供以后參考(下文討論)。也應當注意，沒有執行沖突處理作為發送同步操作的一部分。最后，對于其中客戶機僅“拉”數據(并且因此客戶機不啟動發送同步操作)的對等實施例，并假定中介沒有用于啟動它本身的功能，則STI適配器可代表中介主動啟動發送同步操作。
2.接收同步操作對于另一方向上的同步，圖43所示是客戶機通過STI適配器從中介接收改變數據(“接收同步”操作)的步驟的流程圖。在步驟4302，STI適配器首先接收客戶機本地知識(CLK)，對于本發明的若干實施例，這在客戶機通過STI適配器向中介發送同步請求時發生，所述同步請求內在地包括本文先前所討論的每一對等同步模式的CLK。在步驟4304，STI適配器然后獲取中介的共同體文件夾上的“讀模式”進程鎖(通過中介的文件系統)，以通過防止其它客戶機(或其它對等體或進程)在接收同步操作過程中寫入(但是對于某些實施例，并非讀取)共同體文件夾來保持數據的完整性。對于某些實施例，“讀模式”可以被優化成鎖定每一三元組而非整個目錄，以達到更好的并發性。
在步驟4306，對于由STI適配器為該中介儲存的HCT(例如，可以從先前討論的發送同步操作中獲得)，STI適配器掃描中介上的共同體文件夾，以找出下一較高的改變三元組，該三元組(a)順序上比HCT高，(b)對于該改變三元組，CLK(客戶機本地知識)多于先決條件知識(來自PKF)，以及(c)對于該改變三元組，CLK少于已獲知知識(來自LKF)。(這一改變三元組此處被稱為“適用改變三元組”或“ACT”)。如果在步驟4308存在這樣一個改變三元組(ACT)，則在步驟4310，同步適配器將該改變三元組(ACT)的內容反串行化到復制品可理解的所枚舉的改變中，并且在步驟4312，將改變發送到客戶機以供處理。過程然后返回到步驟4306，以處理下一個ACT，并且該過程繼續，直到沒有剩下的ACT，此時STI適配器在步驟4314解鎖讀模式，該過程結束。
3.中介文件數據壓縮/壓緊對于本發明的各實施例，常規地壓縮由STI適配器創建的串行化數據和知識文件是必需的；否則越來越多的改變三元組將填滿中介上的所有可用空間。在這一點上，數據壓縮的目標是確保數據和知識文件的增長在中介上被適當地界定。本發明的若干實施例采用的一種方法是在允許存在于共享文件系統上的改變分組的數據上設置“上限閾值”，一旦超過該閾值，要求能夠進行壓縮的下溢STI適配器通過壓縮操作壓縮共享的文件系統(共同體文件夾中的文件)。壓縮操作通過以下步驟減少了儲存在共享文件系統中的數據量(a)壓縮個別現有對象的改變歷史，以及(b)移除已被刪除(通過沖突分解明確地刪除，或作為墓碑清除的結果刪除)的對象的改變廣播。然而，壓縮僅可以由剛執行了接收同步且能夠立即執行“全”發送同步(即，如同中介上沒有共同體文件夾那樣不帶零基線的全改變枚舉)的客戶機的STI適配器來實現。由此，壓縮不能由僅與中介完成發送同步或接收同步的客戶機執行。
圖44所示是STI適配器(即，與可以進行發送同步和接收同步兩者的客戶機相關聯的STI適配器)為中介上的共同體文件夾中的數據執行壓縮操作(“壓縮”操作)的步驟的流程圖。在圖中，緊接著步驟4402處STI適配器的客戶機的成功接收同步操作之后，但是在釋放“讀模式”進程鎖之前(即，緊接著圖43的步驟4312之后，但在步驟4314之前)，在步驟4404，STI適配器核查中介上的共同體文件夾，來看是否超過了上限閾值；如果否，則過程結束(通過接收過程通過釋放鎖等來完成)。然而，如果超過了上限閾值，則在步驟4406，STI適配器刪除中介的共同體文件夾中所有的改變三元組文件，然后在步驟4408，STI適配器通過向客戶機指示中介的知識不為空(在刪除之后，情況的確如此)著手啟動客戶機和中介之間的全讀同步操作(包括寫模式進程鎖定)。結果，僅對應于客戶機整個狀態的最小的一組三元組文件被上傳到中介且存在于中介上。
對于其中“讀模式”被優化成鎖定每一三元組而非整個目錄以達到更好的并發性的那些實施例，且對于使用標準“讀模式”的本發明的其它替換事實，該過程有略微的不同，其中，STI適配器在STI適配器獲得中介共同體文件夾上的“讀模式”進程鎖(通過中介的文件系統)(在圖43的步驟4304)之前檢查是否需要壓縮，如果需要壓縮，則使用標準(非優化)的“讀模式”以通過防止其它客戶機(或其它對等體或進程)在接收同步操作過程中寫入(但是對于某些實施例，并非讀取)共同體文件夾來保持數據的完整性。
對于某些替換實施例，中介上的數據在客戶機通過從第一個現有改變三元組開始蓋寫現有改變三元組來上傳所有改變三元組之前不被刪除，一旦上傳了所有的改變三元組(且重寫了舊的改變三元組)，則序列號高于全讀同步過程中最后一個上傳的改變三元組的所有剩余的改變三元組被刪除。
最后，某些實施例也在完成了完整的讀同步操作(包括釋放讀模式進程鎖)之后開始壓縮。對于這類實施例，該過程從獲得寫模式進程鎖開始，然后繼續執行先前提到的所有步驟。
C.STI和下級客戶機支持除上述以外，本發明的若干實施例針對先前所描述的通過中介同步技術的變體。某些實施例針對還包括也運行傳統存儲平臺的客戶機的系統，其中所述“傳統客戶機”也可以訪問所有的數據文件。也預期某些傳統客戶機和其它應用程序和進程能夠為其它目的而訪問這些數據文件。例如，對于基于創建時間或某些其它固有文件特征同步文件的傳統客戶機。另一示例是直接訪問任一或所有文件(例如，*.CDK文件)并復制它們的傳統客戶機。在許多方面，傳統客戶機可以在與直接與第一中介直接通信(可能使用傳統同步技術)的第二中介相同的觀點來考慮，并且由此，多中介同步是可能的，且如此揭示。
IV.結論如之前所示，本發明針對用于組織、搜索以及共享數據的存儲平臺。本發明的存儲平臺擴展并且擴大了現有文件系統和數據庫系統之外的數據存儲的概念，并且被設計為用于所有類型的數據的存儲，包括結構化的、非結構化的、或者半結構化的數據例如關系(表列)數據、XML，以及一種被稱作項目的新形式的數據。通過其共同存儲函數和模式化的數據，本發明的存儲平臺允許用于客戶、知識工作者以及企業的更有效的應用開發。它提供了豐富的并且可擴展的應用編程接口，所述接口不僅可以使用其數據模型中固有的性能，而且包含并擴展了現有文件系統和數據庫訪問方法。可以理解，在不脫離其寬泛的發明概念的情況下，可以對以上所述的實施例進行的改變。因此，本發明并不限于所公開的特殊實施例，而是旨在由所附權利要求所規定的覆蓋本發明的精神和范圍內的所有改變。
如根據以上所述變得很明顯的，本發明的各種系統、方法、以及方面的所有或者一部分可以以程序代碼(即，指令)的形式來體現。這種程序代碼可以被存儲在計算機可讀介質上，例如磁的、電的或者光的存儲介質，在非限定情況下包括軟盤、CD-ROM、CD-RW、DVD-ROM、DVD-RAM、磁帶、閃速存儲器、硬盤驅動器、或者其它機器可讀存儲介質，其中當程序代碼被載入到機器例如計算機或服務器中并由機器執行時，所述機器就變成用于實施本發明的裝置。本發明還可以以在一些傳輸介質上被傳輸的程序代碼的形式來體現，在傳輸介質上例如在電線或者電纜上、通過光纖、在網絡上，包括因特網或內部網，或者通過任何其它形式的傳輸，其中，當程序代碼被接收并且被載入到機器例如計算機中并且由機器執行時，所述機器就變成用于實施本發明的裝置。當在通用處理器上被實現時，所述程序代碼與處理器相結合，以便提供類似于特定邏輯電路的操作的唯一裝置。
權利要求
1.一種用于通過具有一不同存儲平臺(例如Win32)的中介計算機系統(“中介”)同步使用—公用存儲平臺(例如WinFS)的至少兩個計算機系統(每一個為“客戶機”)的方法，所述方法包括對駐留在每個客戶機上、并且將每個客戶機與所述中介接口的通過中介同步(STI)適配器的利用。
2.如權利要求1所述的方法，其特征在于，利用所述同步以支持數據共享操作。
3.如權利要求1所述的方法，其特征在于，利用所述同步以支持最終用戶漫游。
4.如權利要求1所述的方法，其特征在于，所述公用存儲平臺是基于項目的存儲平臺。
5.如權利要求4所述的方法，其特征在于，客戶機的改變枚舉被串行化為存儲在所述中介上的至少一個文件。
6.如權利要求5所述的方法，其特征在于，對于單個串行化，所述至少一個文件包括以下的至少一個或多個用于改變數據(CD)的改變數據文件(CDF)、用于先決條件知識(PK)的先決條件知識文件(PKF)、以及用于已獲知知識(LK)的已獲知知識文件(LKF)。
7.如權利要求5所述的方法，其特征在于，所述同步包括第一客戶機和所述中介之間的發送同步操作，所述發送同步操作包括確定所述中介的已獲知知識；如果所述第一客戶機具有未反映在所述中介的已獲知知識中的改變，則為所述中介準備一組必要的改變；串行化所述必要的改變，并將所述改變寫到所述中介；以及
8.如權利要求7所述的方法，其特征在于，所述發送同步操作還包括獲得寫模式進程鎖；以及釋放寫模式進程鎖。
9.如權利要求5所述的方法，其特征在于，所述同步包括第一客戶機和所述中介之間的接收同步操作，所述接收同步操作包括從所述中介反串行化一組必要的改變，并且將所述改變應用于所述客戶機。
10.如權利要求9所述的方法，其特征在于，所述接收同步操作還包括獲得讀模式進程鎖；以及釋放讀模式進程鎖。
11.如權利要求5所述的方法，其特征在于，所述同步包括第一客戶機和所述中介之間的壓縮操作，所述壓縮操作包括執行一成功的接收同步操作，而不釋放所述讀模式進程鎖；刪除所有同步文件；以及執行一全發送同步操作。
12.一種通過具有一不同存儲平臺(例如Win32)的中介計算機系統(“中介”)同步使用一公用存儲平臺(例如WinFS)的至少兩個計算機系統(每一個為“客戶機”)的系統，所述系統包括利用駐留在每個客戶機上、并且將每個客戶機與所述中介接口的通過中介同步(STI)適配器的至少一個子系統。
13.如權利要求12所述的系統，其特征在于，還包括至少一個子系統，其中，利用所述同步以支持數據共享操作。
14.如權利要12所述的系統，其特征在于，還包括至少一個子系統，其中，利用所述同步以支持最終用戶漫游。
15.如權利要求12所述的系統，其特征在于，還包括至少一個子系統，其中，每一所述公用存儲平臺是基于項目的存儲平臺。
16.如權利要求15所述的方法，其特征在于，還包括至少一個子系統，其中，客戶機的改變枚舉被串行化為存儲在所述中介上的至少一個文件(每一個為“同步文件”)。
17.如權利要求16所述的系統，其特征在于，還包括至少一個子系統，其中，對于單個串行化，所述至少一個文件包括以下的至少一個或多個用于改變數據(CD)的改變數據文件(CDF)、用于先決條件知識(PK)的先決條件知識文件(PKF)、以及用于已獲知知識(LK)的已獲知知識文件(LKF)。
18.如權利要求16所述的系統，其特征在于，還包括至少一個子系統，其中，所述同步包括第一客戶機和所述中介之間的發送同步操作，所述發送同步操作包括確定所述中介的已獲知知識；如果所述第一客戶機具有未在所述中介的已獲知知識中反映的改變，則為所述中介準備一組必要的改變。串行化所述一組必要的改變，并將所述改變寫到所述中介；以及
19.如權利要求18所述的系統，其特征在于，還包括至少一個子系統，其中，所述發送同步操作還包括獲得寫模式進程鎖；以及釋放寫模式進程鎖。
20.如權利要求16所述的系統，其特征在于，還包括至少一個子系統，其中，所述同步包括第一客戶機和所述中介之間的接收同步操作，所述接收同步操作包括從所述中介反串行化一組必要的改變，并且將所述改變應用于所述客戶機。
21.如權利要求20所述的系統，其特征在于，還包括至少一個子系統，其中，所述接收同步操作還包括獲得讀模式進程鎖；以及釋放讀模式進程鎖。
22.如權利要求16所述的系統，其特征在于，還包括至少一個子系統，其中，所述同步包括第一客戶機和所述中介之間的壓縮操作，所述壓縮操作包括執行一成功的接收同步操作，而不釋放所述讀模式進程鎖；刪除所有同步文件；以及執行一全發送同步操作。
23.一種包含計算機可讀指令的計算機可讀介質，所述指令用于通過具有一不同存儲平臺(例如Win32)的中介計算機系統(“中介”)同步使用—公用存儲平臺(例如WinFS)的至少兩個計算機系統(每一個為“客戶機”)，所述計算機可讀指令包括利用駐留在每個客戶機上、并將每個客戶機與所述中介接口的通過中介同步(STI)適配器的指令。
24.如權利要求23所述的計算機可讀指令，其特征在于，還包括指令，其中，利用同步以支持數據共享操作。
25.如權利要求23所述的計算機可讀指令，其特征在于，還包括指令，其中，利用同步以支持最終用戶漫游。
26.如權利要求23所述的計算機可讀指令，其特征在于，還包括指令，其中，所述公用存儲平臺是基于項目的存儲平臺。
27.如權利要求26所述的計算機可讀指令，其特征在于，還包括指令，其中，客戶機的改變枚舉被串行化為存儲在所述中介上的至少一個文件(每一個為“同步文件”)。
28.如權利要求27所述的計算機可讀指令，其特征在于，還包括指令，其中，對單個串行化，所述至少一個文件包括以下的至少一個或多個用于改變數據(CD)的改變數據文件(CDF)、用于先決條件知識(PK)的先決條件知識文件(PKF)、以及用于已獲知知識(LK)的已獲知知識文件(LKF)。
29.如權利要求27所述的計算機可讀指令，其特征在于，還包括指令，其中，所述同步包括第一客戶機和所述中介之間的發送同步操作，所述發送同步操作包括確定所述中介的已獲知知識；如果所述第一客戶機具有未在所述中介的已獲知知識中反映的改變，則為所述中介準備一組必要的改變；串行化所述必要的改變，并且將所述改變寫到所述中介；以及
30.如權利要求29所述的計算機可讀指令，其特征在于，還包括指令，其中，所述發送同步操作還包括獲得寫模式進程鎖；以及釋放寫模式進程鎖。
31.如權利要求27所述的計算機可讀指令，其特征在于，還包括指令，其中，所述同步包括第一客戶機和所述中介之間的接收同步操作，所述接收同步操作包括從所述中介反串行化一組必要的改變，并且將所述改變應用于到所述客戶機。
32.如權利要求31所述的計算機可讀指令，其特征在于，還包括指令，其中，所述接收同步操作還包括獲得讀模式進程鎖；以及釋放讀模式進程鎖。
33.如權利要求27所述的計算機可讀指令，其特征在于，還包括指令，其中，所述同步包括第一客戶機和所述中介之間的壓縮操作，所述壓縮操作包括執行一成功的接收同步操作，而不釋放所述讀模式進程鎖；刪除所有同步文件；以及執行一全發送同步操作。
34.一種用于通過具有一不同存儲平臺(例如Win32)的中介計算機系統(“中介”)同步使用一公用存儲平臺(例如WinFS)的至少兩個計算機系統(每一個為“客戶機”)的硬件控制設備，所述硬件控制設備包括利用駐留在每個客戶機上、并將每個客戶機與所述中介接口的通過中介同步(STI)適配器的裝置。
35.如權利要求34所述的硬件控制設備，其特征在于，還包括裝置，其中，利用所述同步以支持數據共享操作。
36.如權利要求34所述的硬件控制設備，其特征在于，還包括裝置，其中，利用所述同步以支持最終用戶漫游。
37.如權利要求34所述的硬件控制設備，其特征在于，還包括裝置，其中，所述公用存儲平臺是基于項目的存儲平臺。
38.如權利要求37所述的硬件控制設備，其特征在于，還包括裝置，其中，客戶機的改變枚舉被串行化為存儲在所述中介上的至少一個文件(每一個為“同步文件”)。
39.如權利要求38所述的硬件控制設備，其特征在于，還包括裝置，其中，對于單個串行化，所述至少一個文件包括以下的至少一個或多個用于改變數據(CD)的改變數據文件(CDF)、用于先決條件知識(PK)的先決條件知識文件(PKF)、以及用于已獲知知識(LK)的已獲知知識文件(LKF)。
40.如權利要求38所述的硬件控制設備，其特征在于，還包括裝置，其中，所述同步包括第一客戶機和所述中介之間的發送同步操作，所述發送同步操作包括確定所述中介的已獲知知識；如果所述第一客戶機具有未在所述中介的已獲知知識中反映的改變，則為所述中介準備一組必要的改變；串行化所述必要的改變，并且將所述改變寫到所述中介；以及
41.如權利要求40所述的硬件控制設備，其特征在于，還包括裝置，其中，所述發送同步操作還包括獲得寫模式進程鎖；以及釋放寫模式進程鎖。
42.如權利要求38所述的硬件控制設備，其特征在于，還包括裝置，其中，所述同步包括第一客戶機和所述中介之間的接收同步操作，所述接收同步操作包括從所述中介反串行化一組必要的改變，并且將所述改變應用于所述客戶機。
43.如權利要求42所述的硬件控制設備，其特征在于，還包括裝置，其中，所述接收同步操作還包括獲得讀模式進程鎖；以及釋放讀模式進程鎖。
44.如權利要求38所述的硬件控制裝置，其特征在于，還包括裝置，其中，所述同步包括第一客戶機和所述中介之間的壓縮操作，所述壓縮操作包括執行一成功的接收同步操作，而不釋放所述的讀模式進程鎖；刪除所有同步文件；以及執行一全發送同步操作。
全文摘要
本發明針對同步使用公用存儲平臺(例如，相關發明的新存儲平臺)的兩臺客戶機，以通過不使用同一公用存儲平臺(例如，作為替代使用本身不支持新存儲平臺的同步的傳統存儲平臺)的中介來同步的系統和方法。數據使用中介的現有能力來同步，但是其中保持了客戶機的數據結構。使用了一“適配器”通過補償中介的無力來保持客戶機存儲平臺固有的數據結構元素，使得客戶機能夠與中介交互。特定的實施例針對將數據從客戶機上傳同步到中介和/或將數據從中介下載同步到客戶機。某些附加實施例還針對壓縮中介上的數據。
文檔編號H04L29/08GK1781096SQ200480003285
公開日2006年5月31日 申請日期2004年7月29日 優先權日2003年8月21日
發明者D·沙, L·諾威科, M·W·托瑪斯, N·H·珀爾曼, O·埃齊魯 申請人:微軟公司