JP4394644B2 - データの編成、検索、および共有のためのストレージプラットフォーム - Google Patents

データの編成、検索、および共有のためのストレージプラットフォーム Download PDF

Info

Publication number
JP4394644B2
JP4394644B2 JP2005509111A JP2005509111A JP4394644B2 JP 4394644 B2 JP4394644 B2 JP 4394644B2 JP 2005509111 A JP2005509111 A JP 2005509111A JP 2005509111 A JP2005509111 A JP 2005509111A JP 4394644 B2 JP4394644 B2 JP 4394644B2
Authority
JP
Japan
Prior art keywords
item
items
relationship
type
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005509111A
Other languages
English (en)
Other versions
JP2007521537A (ja
Inventor
ジェイ．クラーク クェンティン
ケイ．ノリ アニル
セリス ペドロ
エム．スピロ ピーター
ジー．キャンベル デイビッド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2007521537A publication Critical patent/JP2007521537A/ja
Application granted granted Critical
Publication of JP4394644B2 publication Critical patent/JP4394644B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は一般に、情報の格納および取り出しの分野に関し、より具体的には、コンピュータ化されたシステムにおいて様々な型のデータを編成し、検索し、かつ共有するためのアクティブストレージプラットフォームに関する。
個々のディスク容量は、最近１０年間に、ほぼ年７０％の割合で増大してきている。ムーアの法則は、長年にわたって続いている中央演算処理装置（ＣＰＵ）パワーの途方もない増大を正確に予測した。有線および無線技術は、驚異的な接続性および帯域幅をもたらした。現在のトレンドが続くと仮定すると、数年以内に、平均的なラップトップコンピュータでおおよそ１テラバイト（ＴＢ）のストレージを備え、数百万個のファイルを格納するようになり、５００ギガバイト（ＧＢ）ドライブがあたりまえになることであろう。
消費者は、コンピュータを主に通信と個人情報の編成に使用しており、これは、従来の個人情報管理（Personal Information Manager）スタイルのデータであるか、デジタル音楽または写真などの媒体であるかを問わない。デジタルコンテンツの量、および未加工のバイトを格納する能力は、途方もなく増大してきているが、消費者がこのようなデータの編成および統合に使用できる方法は対応できていない。知識労働者は、情報の管理および共有に膨大な時間を費やしており、ある調査では、知識労働者は非生産的情報関連の活動に全時間の１５〜２５％を費やしていると推定している。また他の調査では、標準的な知識労働者は情報の検索に毎日約２．５時間を費やしている推定している。
開発者および情報技術（ＩＴ）部門は、人々、場所、時間、および出来事などを表す共通ストレージ抽象化（common storage abstractions）のための、彼ら自身のデータストアを構築することに相当の時間と資金を費やしている。この結果、作業を重複させるだけでなく、データの共通の検索または共有のためのメカニズムのない、共通データの孤島をいくつも生み出している。今日、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムが稼働するコンピュータ上に、いったいいくつのアドレス帳が存在しうるか考えてみよう。電子メールクライアントおよびパーソナルファイナンスプログラムなどの多くのアプリケーションは、個々にアドレス帳を保存し、そのようなそれぞれのプログラムが個別に保持するアドレス帳データのアプリケーション間の共有はほとんどない。その結果、ファイナンスプログラム（Ｍｉｃｒｏｓｏｆｔ Ｍｏｎｅｙ（登録商標）のようなプログラム）は、受取人のアドレスを、電子メール連絡先フォルダ（Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（登録商標）が備えているようなフォルダ）に保持されているアドレスと共有しない。実際、多くのユーザは、複数のデバイスを持ち、論理的に、そのパーソナルデータをそれら自体の間で同期させ、また携帯電話からＭＳＮおよびＡＯＬなどの商業サービスに至るまで、様々な追加ソースにまたがって同期させなければならないが、共有されているドキュメントのコラボレーションは、電子メールメッセージにドキュメントを添付することにより大半が行われている、つまり、手作業で、しかも非効率的に行われている。
このようなコラボレーションの欠落の理由の１つは、コンピュータシステム内に情報を編成する伝統的なアプローチが、ファイル−フォルダ／ディレクトリベースのシステム（「ファイルシステム」）を使用し、複数のファイルを格納するために使用される記憶媒体の物理的編成の抽象化に基づいて、複数のファイルをフォルダのディレクトリ階層に編成することを中心に機能していることである。１９６０年代に開発されたＭｕｌｔｉｃｓオペレーティングシステムは初めて、ファイル、フォルダ、およびディレクトリを使用して、オペレーティングシステムレベルにおいてデータの格納可能ユニットを管理したことで高い評価を得ている。特に、Ｍｕｌｔｉｃｓは、ファイルの階層内で記号アドレスを使用し（それによってファイルパスという概念を導入）、ファイルの物理的アドレスはユーザ（アプリケーションおよびエンドユーザ）に対し透過的でなかった。このファイルシステムは、全体として、どの個別ファイルのファイル形式についても意識しておらず、ファイル間の関係は、オペレーティングシステムレベル（つまり、階層内のファイルの場所以外）においては重要でないとみなされていた。Ｍｕｌｔｉｃｓの出現以来、格納可能なデータは、オペレーティングシステムレベルにおいてファイル、フォルダ、およびディレクトリに編成されてきた。これらのファイルは、一般に、ファイルシステムにより保持されている特殊ファイルにおいて具現化されたファイル階層自体（「ディレクトリ」）を含む。このディレクトリは、次に、ディレクトリ内のその他のファイルおよび階層内のそのようなファイルの位置（nodal location）のすべてに対応するエントリのリストを保持する（ここでは、フォルダと呼ぶ）。このようなシステムが、約４０年間にわたって最先端技術であった。
しかし、コンピュータの物理的ストレージシステム内に置かれている情報の十分妥当な表現を実現しているにもかかわらず、ファイルシステムは、その物理的ストレージシステムの抽象化であり、それらのファイルの利用には、ユーザの操作内容（コンテクストを持つユニット、特徴、および他のユニットとの関係）とオペレーティングシステムが備える内容（ファイル、フォルダ、およびディレクトリ）との間のあるレベルの指示（解釈）を必要とする。したがって、ユーザ（アプリケーションおよび／またはエンドユーザ）には、そうすることが非効率であり、不整合であり、または他の何らかの形で望ましくない場合でも、情報のユニットにファイルシステム構造を強いる以外に選択肢がない。さらに、既存のファイルシステムは、個別ファイルに格納されているデータの構造についてはほとんど関知しないため、情報のほとんどは、それらを書いたアプリケーションにしかアクセス（理解）できないファイル内にロックアップされたままとなる。その結果、このように情報のスキマティック（schematic）な記述、および情報を管理するためのメカニズムを欠いているため、個別の保管場所の間でほとんどデータを共有しないままデータの保管場所を作成することになる。例えば、多くのパーソナルコンピュータ（ＰＣ）ユーザは、ファイル編成はＰＣユーザにとってかなり難しい作業であるため、あるレベル−例えば、Ｏｕｔｌｏｏｋ Ｃｏｎｔａｃｔｓ、オンライン口座アドレス、Ｗｉｎｄｏｗｓ（登録商標）Ａｄｄｒｅｓｓ Ｂｏｏｋ、Ｑｕｉｃｋｅｎ Ｐａｙｅｅｓ、およびインスタントメッセージング（ＩＭ）の仲間リスト−においてやり取りする人々に関する情報を格納する５つを超える異なるストアを持つ。ほとんどの既存のファイルシステムではファイルおよびフォルダの編成にネストされたフォルダメタファを使用しているため、ファイルの個数が増えると、柔軟で効率的な編成方式を維持するために要する労力はかなり大変なものとなる。このような状況では、単一ファイルの複数の分類があると非常に有益であるが、既存ファイルシステム内のハードまたはソフトリンクを使用することは厄介であり、維持も困難である。
過去には、ファイルシステムの欠点をなくそうとする試みが何回かあったがうまくいかなかった。それらの以前の試みのうちいくつかは、連想メモリ（content addressable memory）を利用し、データに物理アドレスではなく内容でアクセスできるメカニズムを実現しようとした。しかし、連想メモリはキャッシュおよびメモリ管理ユニットなどのデバイスによる小規模な利用については有用であることが実証されたが、物理的記憶媒体などのデバイスでの大規模な利用は様々な理由からまだ可能でないため、こうした努力は成功しておらず、したがって、このような解決策はただ単に存在していない。オブジェクト指向データベース（ＯＯＤＢ）システムを使用した他の試みもなされているが、これらの試みは、強いデータベース特性とよい非ファイル表現を特徴とする一方、ファイル表現の取り扱いにおいては効果的でなく、ハードウェア／ソフトウェアインターフェースのシステムレベルでの階層構造に基づくファイルおよびフォルダの速度、効率、および簡潔さを再現することもできない。ＳｍａｌｌＴａｌｋ（およびその派生言語）を使用する試みなどの他の取り組みは、ファイルおよび非ファイル表現の取り扱いでは極めて効果的であることが実証されたが、様々なデータファイルの間に存在する関係を効率よく編成し、利用するために必要なデータベース機能を欠いており、したがって、そのようなシステムの全体的効率は許容できないものであった。さらにＢｅＯＳを使用する他の試み（および他のそのようなオペレーティングシステム研究）は、必要なデータベース機能をいくつか備えておりファイルを適切に表現できるにもかかわらず、非ファイル表現を取り扱うのには不適当であること−従来のファイルシステムの中心的な欠点と同じ欠点−を実証した。
データベース技術は、同様の難題が存在するもう１つの技術分野である。例えば、リレーショナルデータベースモデルは大きな商業的成功を収めたが、実際には、独立系ソフトウェアベンダ（ＩＳＶ）は、一般に、リレーショナルデータベースのソフトウェア製品（Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒなど）に用意されている機能のわずかな部分を利用している。その代わりに、そのような製品とのアプリケーションの相互作用のほとんどは、単純な「読み取る」と「書き込む」の形態である。これに対しすぐにわかる理由−プラットフォームまたはデータベースがわからないなど−が多数占めるが、気づかれないことが多い重要な理由の１つは、データベースは、必ずしも、大手ビジネスアプリケーションベンダが本当に必要とする的確な抽象化を行わないということである。例えば、現実世界には、「顧客」または「注文」（それら自身の中のアイテム、またそれら自身のアイテムとして注文の埋め込まれた「ラインアイテム」とともに）「アイテム」という概念があるが、リレーショナルデータベースはテーブルおよび行に関してしか認識しない。その結果、アプリケーションは、（例えば）アイテムレベルでの整合性、ロッキング、セキュリティ、および／またはトリガの側面を持つことが望ましいかもしれないが、一般的には、データベースはこれらの機能をテーブル／行のレベルでしか備えていない。これは、それぞれのアイテムがデータベースのあるテーブル内の単一行にマッピングされる場合にうまく機能する可能性があるが、複数のラインアイテムの注文の場合、アイテムが実際に複数のテーブルにマッピングされる理由がありえ、それがその場合であれば、単純なリレーショナルデータベースシステムではまったく正しい抽象化を行わない。その結果、アプリケーションは、それらの基本的抽象化を実現するためにデータベースの上にロジックを構築しなければならない。つまり、基本的リレーショナルモデルは、アプリケーションとストレージシステムとの間にあるレベルの間接性を必要とし、その場合データの意味構造は、特定の場合にしかアプリケーション内では見えない場合があるため、基本的リレーショナルモデルは、高水準のアプリケーションを容易に開発可能であるデータを格納するために十分なプラットフォームを提供しない。いくつかのデータベースベンダが、高水準の機能をその製品に組み込んでいる−オブジェクトリレーショナル機能、新しい組織化可能モデルなどを備える−が、どれも、必要な種類の包括的ソリューションを実現していない。というのも、本当に包括的なソリューションとは、有用なドメイン抽象化（「Ｐｅｒｓｏｎｓ」、「Ｌｏｃａｔｉｏｎｓ」、「Ｅｖｅｎｔｓ」など）に対し両方とも有用なデータモデル抽象化（「Ｉｔｅｍ」、「Ｅｘｔｅｎｓｉｏｎｓ」、「Ｒｅｌａｔｉｏｎｓｈｉｐｓ」など）を実現するものだからである。
既存のデータストレージおよびデータベース技術における前記の欠点に関して、コンピュータシステム内のデータのすべての型を編成し、検索し、共有する能力を高めた新しいストレージプラットフォーム−既存のファイルシステムおよびデータベースシステムを超えてデータプラットフォームを拡張し拡大する、すべての型のデータを格納するように設計されているストレージプラットフォーム−が必要である。本発明は、この要求条件を満たす。
以下の説明では、本発明の様々な態様の概要を述べる。この説明は、本発明の重要な態様のすべてを網羅的に説明することも、また本発明の範囲を定めることも意図していない。むしろ、この説明は、以下の詳細な説明および図面の導入部として使用されることを意図している。
本発明は、データの編成、検索、および共有のためのストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、既存のファイルシステムおよびデータベースシステムを超えるデータストレージの概念を拡張し、広げるものであり、構造化、非構造化、または半構造化データを含むすべての型のデータ用のストアとなるように設計されている。
本発明の一態様によれば、本発明のストレージプラットフォームは、データベースエンジン上に実装されたデータストアを含む。本発明の様々な実施形態では、データベースエンジンは、オブジェクトリレーショナルの拡張機能を備えるリレーショナルデータベースエンジンを含む。データストアは、データの編成、検索、共有、同期、およびセキュリティをサポートするデータモデルを実装する。特定の型のデータがスキーマ内に記述されており、プラットフォームは新しい型のデータ（本質的に、スキーマにより実現される基本型の子型（subtype））を定義するためスキーマの集合を拡張するメカニズムを備える。同期処理機能は、ユーザまたはシステム間のデータの共有を円滑にする。ファイルシステム風の機能が用意され、これにより、そのような従来のファイルシステムの制限のない既存のファイルシステムとのデータストアの相互運用性を実現できる。変更追跡メカニズムは、データストアに対する変更追跡の機能を備える。ストレージプラットフォームは、さらに、アプリケーションからストレージプラットフォームの前記の機能のすべてにアクセスし、スキーマで記述されているデータにアクセスするための一組のアプリケーションプログラムインターフェースを備える。
本発明の他の態様によれば、データストアにより実装されるデータモデルは、アイテム、要素、および関係に関してデータストレージのユニットを定義する。アイテムは、データストアに格納可能なデータの１つのユニットであり、１つまたは複数の要素および関係を含むことができる。要素は、１つまたは複数のフィールドを含む型のインスタンスである（ここではプロパティとも呼ばれる）。関係は、２つのアイテムの間のリンクである。（本明細書で使用されているように、これらの用語および他の特定の用語は、極めて密接に使用される他の用語から分けるため原文の英語では先頭文字が大文字にされている場合があるが、何であれ英語で先頭が大文字の用語は例えば「Ｉｔｅｍ」とし、英語で大文字でないときの同じ用語、例えば、「ｉｔｅｍ」は日本語に訳してアイテムとするが、区別する意図はなく、そのような区別は想定されるべきでも、暗黙のうちに含まれるべきでもない）。
本発明の他の態様によれば、コンピュータシステムは、それぞれのＩｔｅｍがハードウェア／ソフトウェアインターフェースシステムにより操作することができる情報の離散的（discrete）格納可能ユニットを構成する複数のＩｔｅｍ、前記Ｉｔｅｍに対する組織構造を構成する複数のＩｔｅｍ Ｆｏｌｄｅｒ、およびそれぞれのＩｔｅｍが少なくとも１つのＩｔｅｍ Ｆｏｌｄｅｒに属し、複数のＩｔｅｍ Ｆｏｌｄｅｒに属す場合もある、複数のＩｔｅｍを操作するためのハードウェア／ソフトウェアインターフェースシステムを備える。
本発明の他の態様によれば、コンピュータシステムは、複数のＩｔｅｍを備え、それぞれのＩｔｅｍは、ハードウェア／ソフトウェアインターフェースシステムにより操作することができる離散的情報ユニットを構成し、ＩｔｅｍまたはＩｔｅｍのプロパティ値のいくつかは、永続的ストアから求められるのとは反対に動的に計算される。つまり、ハードウェア／ソフトウェアインターフェースシステムは、Ｉｔｅｍを格納する必要はなく、Ｉｔｅｍの現在の集合を列挙する機能またはストレージプラットフォームの識別子（アプリケーションプログラミングインターフェースつまりＡＰＩを説明する節でさらに詳しく説明する）が与えられた場合のＩｔｅｍを取り出す機能などのいくつかのオペレーションがサポートされる−例えば、Ｉｔｅｍは、携帯電話の現在位置または温度センサ上の温度読み取り値とすることが可能である。
本発明の他の態様によれば、複数のＩｔｅｍを操作する、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムは、さらに、ハードウェア／ソフトウェアインターフェースシステムにより管理される複数のＲｅｌａｔｉｏｎｓｈｉｐにより相互接続されるＩｔｅｍを含む。本発明の他の態様によれば、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムは、前記ハードウェア／ソフトウェアインターフェースシステムにより理解可能なプロパティを持つ複数の離散的情報ユニットを操作する、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムである。本発明の他の態様によれば、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムは、前記ハードウェア／ソフトウェアインターフェースシステムが理解し、所定の予測可能な方法で直接処理することができるコアＩｔｅｍの集合を定義するコアスキーマを備える。本発明の他の態様によれば、前記Ｉｔｅｍと複数のＲｅｌａｔｉｏｎｓｈｉｐとを相互接続し、ハードウェア／ソフトウェアインターフェースシステムレベルで前記Ｒｅｌａｔｉｏｎｓｈｉｐを管理することを含む、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムの複数の離散的情報ユニット（「Ｉｔｅｍ」）を操作する方法が開示される。
本発明の他の特徴によれば、ストレージプラットフォームのＡＰＩは、ストレージプラットフォームスキーマの集合で定義されているそれぞれのアイテム、アイテム拡張、および関係に対するデータクラスを用意する。さらに、アプリケーションプログラミングインターフェースは、データクラスに対するビヘイビア（behaviors）の共通の集合を定義し、データクラスとともに、ストレージプラットフォームＡＰＩの基本プログラミングモデルを提供するフレームワーククラスの集合を実現する。本発明の他の特徴によれば、ストレージプラットフォームＡＰＩは、アプリケーションプログラマを基礎のデータベースエンジンのクエリ言語の詳細から分離する形で、データストア内のアイテムの様々なプロパティに基づいてアプリケーションプログラマがクエリを形成するために使用できる簡略化されたクエリモデルを備える。本発明のストレージプラットフォームＡＰＩのさらに他の態様によれば、このＡＰＩは、アプリケーションプログラムによりアイテムに加えられた変更を集めてから、それらをデータストアが実装されているデータベースエンジン（または何らかの種類のストレージエンジン）により要求される正しい更新に編成する。これにより、アプリケーションプログラマは、データストア更新の複雑な部分をＡＰＩに任せつつ、メモリ中のアイテムに変更を加えることができる。
本発明のストレージプラットフォームでは、共通のストレージ基盤および図式化されたデータを通じて、より効率的なアプリケーション開発を消費者、知識労働者、および企業向けに行うことができる。これは、データモデルに固有の機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法も包含し、拡張する機能豊富な拡張可能アプリケーションプログラミングインターフェースを備える。
本発明の他の特徴および利点は、本発明の以下の詳細な説明および付属の図面から明白になるであろう。
前述の概要は、本発明の以下の詳細な説明とともに、付属の図面を参照しつつ読むとよく理解できる。本発明を例示する目的のために、図面には、本発明の様々な態様の実施例が示されているが、本発明は、開示されている特定の方法および手段に限定されない。図面は以下で説明される。
目次
Ｉ．序論
Ａ．例示的なコンピューティング環境
Ｂ．従来のファイルベースのストレージ
ＩＩ．データの編成、検索、および共有のための新しいストレージプラットフォーム
Ａ．用語解説
Ｂ．ストレージプラットフォームの概要
Ｃ．データモデル
１．Ｉｔｅｍｓ
２．Ｉｔｅｍの識別
ａ）アイテム参照
（１）ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅ
（２）ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅ
ｂ）参照型階層
３．Ｉｔｅｍ ＦｏｌｄｅｒｓおよびＣａｔｅｇｏｒｉｅｓ
４．Ｓｃｈｅｍａｓ
ａ）Ｂａｓｅ Ｓｃｈｅｍａ
ｂ）Ｃｏｒｅ Ｓｃｈｅｍａ
５．関係
ａ）関係の宣言
ｂ）保持Ｒｅｌａｔｉｏｎｓｈｉｐ
ｃ）埋め込み関係
ｄ）参照関係
ｅ）規則と制約条件
ｆ）関係の順序付け
６．拡張性
ａ）アイテム拡張
ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔ型の拡張
Ｄ．データベースエンジン
１．ＵＤＴを使用したデータストアの実装
２．アイテムのマッピング
３．拡張マッピング
４．ネストされている要素のマッピング
５．オブジェクト識別
６．ＳＱＬオブジェクトの命名規則
７．列の命名規則
８．検索ビュー
ａ）アイテム
（１）マスターアイテム検索ビュー
（２）型付きアイテム検索ビュー
ｂ）アイテム拡張
（１）マスター拡張検索ビュー
（２）型付き拡張検索ビュー
ｃ）ネストされている要素
ｄ）関係
（１）マスター関係検索ビュー
（２）関係インスタンス検索ビュー
９．更新
１０．変更追跡＆ツームストーン
ａ）変更追跡
（１）「マスター」検索ビューでの変更追跡
（２）「型付き」検索ビューでの変更追跡
ｂ）ツームストーン
（１）アイテムツームストーン
（２）拡張ツームストーン
（３）関係ツームストーン
（４）ツームストーンのクリーンアップ
１１．ヘルパＡＰＩおよび関数
ａ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＩｔｅｍ
ｂ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＥｘｔｅｎｓｉｏｎ
ｃ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＲｅｌａｔｉｏｎｓｈｉｐ
１２．メタデータ
ａ）スキーマメタデータ
ｂ）インスタンスメタデータ
Ｅ．セキュリティ
１．概要
２．セキュリティモデルの詳細な説明
ａ）セキュリティ記述子構造
（１）アクセスマスク形式
（２）汎用アクセス権
（３）標準アクセス権
ｂ）アイテム特有の権利
（１）ファイルおよびディレクトリオブジェクト特有の権利
（２）ＷｉｎＦＳＩｔｅｍＲｅａｄ
（３）ＷｉｎＦＳＩｔｅｍＲｅａｄＡｔｔｒｉｂｕｔｅｓ
（４）ＷｉｎＦＳＩｔｅｍＷｒｉｔｅＡｔｔｒｉｂｕｔｅｓ
（５）ＷｉｎＦＳＩｔｅｍＷｒｉｔｅ
（６）ＷｉｎＦＳＩｔｅｍＡｄｄＬｉｎｋ
（７）ＷｉｎＦＳＩｔｅｍＤｅｌｅｔｅＬｉｎｋ
（８）アイテムを削除する権利
（９）アイテムをコピーする権利
（１０）アイテムを移動する権利
（１１）アイテム上のセキュリティポリシーを表示する権利
（１２）アイテム上のセキュリティポリシーを変更する権利
（１３）直接の等価物を持たない権利
３．実装
ａ）コンテナ内に新しいアイテムを作成する
ｂ）明示的なＡＣＬをアイテムに追加する
ｃ）保持Ｒｅｌａｔｉｏｎｓｈｉｐをアイテムに追加する
ｄ）保持Ｒｅｌａｔｉｏｎｓｈｉｐをアイテムから削除する
ｅ）明示的なＡＣＬをアイテムから削除する
ｆ）アイテムに関連付けられているＡＣＬを修正する
Ｆ．通知および変更追跡
１．ストレージ変更イベント
ａ）イベント
ｂ）ウォッチャ（Watchers）
２．変更追跡および通知生成メカニズム
ａ）変更追跡
ｂ）タイムスタンプ管理
ｃ）データ変更検出−イベント検出
Ｇ．同期
１．ストレージプラットフォームとストレージプラットフォームとの間の同期処理
ａ）同期（Ｓｙｎｃ）制御アプリケーション
ｂ）スキーマ注釈
ｃ）同期設定
（１）コミュニティフォルダ−マッピング
（２）プロファイル
（３）スケジュール
ｄ）競合回避処理
（１）競合検出
（ａ）知識ベースの競合
（ｂ）制約ベースの競合
（２）競合処理
（ａ）自動競合解決
（ｂ）競合ログ作成
（ｃ）競合の検査および解決
（ｄ）レプリカの収束および競合解決の伝搬
２．非ストレージプラットフォームデータストアの同期処理
ａ）同期処理サービス
（１）Ｃｈａｎｇｅ Ｅｎｕｍｅｒａｔｉｏｎ
（２）Ｃｈａｎｇｅ Ａｐｐｌｉｃａｔｉｏｎ
（３）Ｃｏｎｆｌｉｃｔ Ｒｅｓｏｌｕｔｉｏｎ
ｂ）アダプタの実装
３．セキュリティ
４．管理容易性
Ｈ．従来のファイルシステムの相互運用性
１．相互運用性のためのモデル
２．データストアの機能
ａ）ボリュームではない
ｂ）ストア構造
ｃ）すべてのファイルが移動（migrated）されるわけではない
ｄ）ＮＴＦＳ名前空間でのストレージプラットフォームファイルへのアクセス
ｅ）予期される名前空間／ドライブ文字（letters）
Ｉ．ストレージプラットフォームＡＰＩ
１．概要
２．命名およびスコープ
３．ストレージプラットフォームＡＰＩコンポーネント
４．データクラス
５．ランタイムフレームワーク
ａ）ランタイムフレームワーククラス
（１）ＩｔｅｍＣｏｎｔｅｘｔ
（２）ＩｔｅｍＳｅａｒｃｈｅｒ
（ａ）ターゲット型
（ｂ）フィルタ
（ｃ）検索の準備
（ｄ）検索オプション
（３）アイテム結果ストリーム（「ＦｉｎｄＲｅｓｕｌｔ」）
ｂ）動作中のランタイムフレームワーク
ｃ）共通プログラミングパターン
（１）ＩｔｅｍＣｏｎｔｅｘｔオブジェクトを開く、閉じる
（２）オブジェクトの検索
（ａ）検索オプション
（ｂ）ＦｉｎｄＯｎｅおよびＦｉｎｄＯｎｌｙ
（ｃ）ＩｔｅｍＣｏｎｔｅｘｔ上のショートカットを検索する
（ｄ）ＩＤまたはパスによって検索する
（ｅ）ＧｅｔＳｅａｒｃｈｅｒパターン
（３）ストアの更新
６．セキュリティ
７．関係についてのサポート
ａ）基本関係型
（１）関係クラス
（２）ＩｔｅｍＲｅｆｅｒｅｎｃｅクラス
（３）ＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅクラス
（４）ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅクラス
（５）ＲｅｌａｔｉｏｎｓｈｉｐＩｄ構造体
（６）ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎクラス
ｂ）生成された関係型
（１）生成された関係型
（２）ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅクラス
（３）ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅＣｏｌｌｅｃｔｉｏｎ
クラス
ｃ）Ｉｔｅｍクラス内の関係サポート
（１）Ｉｔｅｍクラス
（２）ＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎクラス
ｄ）検索式の中の関係サポート
（１）アイテムから関係へのトラバース
（２）関係からアイテムへのトラバース
（３）関係トラバースの組合せ
ｅ）関係サポートの使用例
（１）関係の検索
（２）関係からソースおよびターゲットアイテムへのナビゲート
（３）ソースアイテムから関係へのナビゲート
（４）関係（およびアイテム）の作成
（５）関係（およびアイテム）の削除
８．ストレージプラットフォームＡＰＩの「拡張」
ａ）ドメインビヘイビア
ｂ）付加価値ビヘイビア
ｃ）サービスプロバイダとしての付加価値ビヘイビア
９．デザインタイムフレームワーク
１０．クエリ形式（formalism）
ａ）フィルタの基本事項
ｂ）型変換
ｃ）フィルタ構文
１１．リモーティング
ａ）ＡＰＩにおけるローカル／リモート透過性
ｂ）リモーティングのストレージプラットフォーム実装
ｃ）非ストレージプラットフォームストアへのアクセス
ｄ）ＤＦＳとの関係
ｅ）ＧＸＡ／Ｉｎｄｉｇｏとの関係
１２．制約条件
１３．共有
ａ）共有の表現
ｂ）共有の管理
ｃ）共有のアクセス
ｄ）発見可能性
１４．Ｆｉｎｄの意味
１５．ストレージプラットフォームＣｏｎｔａｃｔｓ ＡＰＩ
ａ）Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｎｔａｃｔの概要
ｂ）ドメインビヘイビア
１６．ストレージプラットフォームＦｉｌｅ ＡＰＩ
ａ）序論
（１）ストレージプラットフォーム内でのＮＴＦＳボリュームの反映
（２）ストレージプラットフォーム名前空間内でのファイルおよび
ディレクトリの作成
ｂ）Ｆｉｌｅスキーマ
ｃ）Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓの概要
ｄ）コード例
（１）ファイルを開き書き込む
（２）クエリの使用
ｅ）ドメインビヘイビア
Ｊ．まとめ
Ｉ．序論
本発明の主題は、法的要件を満たすように特異性（specificity）とともに説明されている。しかし、説明自体は、本発明の範囲を制限することを意図されていない。むしろ、発明者は、主張されている主題は、他の現在または将来の技術とともに、本明細書で説明されているステップと類似しているが異なるステップまたはステップの組合せを含むように、他の方法でも具現化されうることを考察した。さらに、「ステップ」という用語は、本明細書では、採用されている方法の異なる要素を暗示するために使用される場合があるが、この用語は、個々のステップの順序が明示的に説明されている場合を除き、本明細書で開示されている様々なステップ間の特定の順序を示唆するものとして解釈すべきではない。
Ａ．例示的なコンピューティング環境
本発明の数多くの実施形態は、コンピュータ上で実行することができる。図１および以下の説明は、本発明を実施できる適当なコンピューティング環境について簡潔に述べた一般的な説明となることを意図している。必要というわけではないが、本発明の様々な態様は、クライアントワークステーションまたはサーバなどのコンピュータにより実行される、プログラムモジュールなどの、コンピュータ実行可能命令の一般的文脈において説明することができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、他のコンピュータシステム構成を使用して実施できる。また、本発明は、通信ネットワークを通じてリンクされているリモート処理装置によりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶デバイス内に配置されうる。
図１に示されているように、例示的な汎用コンピューティングシステムは、処理ユニット２１、システムメモリ２２、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット２１に結合するシステムバス２３を備える、従来のパーソナルコンピュータ２０を含む。システムバス２３は、メモリバスまたはメモリコントローラ、ペリフェラルバス、および様々なバスアーキテクチャを使用するローカルバスを含む数種類のバス構造のうちのいずれでもよい。システムメモリは、読み取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動時などにパーソナルコンピュータ２０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４に格納される。パーソナルコンピュータ２０は、さらに、図に示されていないハードディスクへの読み書きを行うためのハードディスクドライブ２７、取外し可能な磁気ディスク２９への読み書きを行うための磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたはその他の光媒体などの取外し可能な光ディスク３１への読み書きを行うための光ディスクドライブ３０を備える。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ディスクドライブインターフェース３４によりそれぞれシステムバス２３に接続される。ドライブおよび関連するコンピュータ読取り可能記憶媒体は、パーソナルコンピュータ２０用のコンピュータ読取り可能命令、データ構造体、プログラムモジュール、およびその他のデータを格納する不揮発性記憶装置を実現する。本発明で説明されている環境例ではハードディスク、取外し可能な磁気ディスク２９、および取外し可能な光ディスク３１を使用しているが、当業者であれば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、複数のランダムアクセスメモリ（ＲＡＭ）、複数の読み取り専用メモリ（ＲＯＭ）などのコンピュータからアクセス可能なデータを格納できるその他のタイプのコンピュータ読取り可能媒体もこの例示的な動作環境で使用できることを理解するであろう。同様に、この例示的な環境は、さらに、熱感知器およびセキュリティまたは火災警報装置などの様々なタイプの監視デバイス、およびその他の情報源を含むことができる。
オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、その他のプログラムモジュール３７、およびプログラムデータ３８を含む、多くのプログラムモジュールは、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に格納されることができる。ユーザはキーボード４０およびポインティングデバイス４２などの入力デバイスを通じてパーソナルコンピュータ２０にコマンドおよび情報を入力することができる。その他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているシリアルポートインターフェース４６を介して処理ユニット２１に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースにより接続することもできる。モニタ４７またはその他の種類の表示デバイスも、ビデオアダプタ４８などのインターフェースを介してシステムバス２３に接続される。パーソナルコンピュータは、通常、モニタ４７の他に、スピーカおよびプリンタなど、その他の周辺出力装置（図に示されていない）を備える。図１の例示的なシステムは、さらに、ホストアダプタ５５、ＳＣＳＩ（Small Computer System Interface）バス５６、およびＳＣＳＩバス５６に接続された外部記憶デバイス６２も含む。
パーソナルコンピュータ２０は、リモートコンピュータ４９などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ４９は、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードでもよく、通常は、パーソナルコンピュータ２０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス５０だけが図１に示されている。図１で説明されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１とワイドエリアネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。
ＬＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２０は、ネットワークインターフェースまたはアダプタ５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２０は、通常、モデム５４またはインターネットなどのワイドエリアネットワーク５２上で通信を確立するためのその他の手段を備える。モデム５４は、内蔵でも外付けでもよいが、シリアルポートインターフェース４６を介してシステムバス２３に接続される。ネットワーク接続環境では、パーソナルコンピュータ２０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶デバイスに格納されうる。図に示されているネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立するために他の手段が使用可能であることは理解されるであろう。
図２のブロック図に例示されているように、コンピュータシステム２００は、大まかに言って、ハードウェアコンポーネント２０２、ハードウェア／ソフトウェアインターフェースシステムコンポーネント２０４、およびアプリケーションプログラムコンポーネント２０６（本明細書では状況に応じて「ユーザコンポーネント」または「ソフトウェアコンポーネント」とも呼ぶ）の３つのコンポーネントグループに分けることができる。
コンピュータシステム２００の様々な実施形態において、図１を再び参照すると、ハードウェアコンポーネント２０２は、処理ユニット（ＣＰＵ）２１、メモリ（ＲＯＭ２４およびＲＡＭ２５の両方）、基本入出力システム（ＢＩＯＳ）２６、およびキーボード４０、マウス４２、モニタ４７、および／またはプリンタ（図に示されていない）などの様々な入出力（Ｉ／Ｏ）デバイスを備えることができる。ハードウェアコンポーネント２０２は、コンピュータシステム２００用の基本的な物理的インフラストラクチャを備える。
アプリケーションプログラムコンポーネント２０６は、限定はしないが、コンパイラ、データベースシステム、ワードプロセッサ、ビジネスプログラム、ビデオゲームなどを含む、様々なソフトウェアプログラムを備える。アプリケーションプログラムは、様々なユーザ（マシン、他のコンピュータシステム、および／またはエンドユーザ）のために問題を解決し、解決策を提供し、データを処理するため、コンピュータ資源を利用するための手段を備える。
ハードウェア／ソフトウェアインターフェースシステムコンポーネント２０４は、それ自体、ほとんどの場合、シェルおよびカーネルを含むオペレーティングシステムを備える（および、いくつかの実施形態では、そのようなオペレーティングシステムのみで構成することができる）。「オペレーティングシステム」（ＯＳ）は、アプリケーションプログラムとコンピュータハードウェアとの間の媒介として動作する特別なプログラムである。ハードウェア／ソフトウェアインターフェースシステムコンポーネント２０４は、さらに、仮想マシンマネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的等価物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的等価物、またはコンピュータシステム内のオペレーティングシステムの代わりとなる、またはそれへの追加となる他のそのようなソフトウェアコンポーネントを含むこともできる。ハードウェア／ソフトウェアインターフェースシステムの目的は、ユーザがアプリケーションプログラムを実行できるような環境を用意することである。ハードウェア／ソフトウェアインターフェースシステムの目標は、コンピュータシステムを使いやすくするだけでなく、コンピュータハードウェアを効率的な方法で利用できるようにすることである。
ハードウェア／ソフトウェアインターフェースシステムは、一般に、起動時にコンピュータシステムにロードされ、それ以降、コンピュータシステム内のすべてのアプリケーションプログラムを管理する。アプリケーションプログラムは、アプリケーションプログラムインターフェース（ＡＰＩ）を介してサービスを要求することによりハードウェア／ソフトウェアインターフェースシステムとやり取りをする。一部のアプリケーションプログラムでは、エンドユーザはコマンド言語またはグラフィカルユーザインターフェース（ＧＵＩ）などのユーザインターフェースを介してハードウェア／ソフトウェアインターフェースシステムとやり取りすることができる。
ハードウェア／ソフトウェアインターフェースシステムは、従来、アプリケーションに対し様々なサービスを実行するものである。複数のプログラムを同時に実行できるマルチタスクのハードウェア／ソフトウェアインターフェースシステムにおいて、ハードウェア／ソフトウェアインターフェースシステムは、どのアプリケーションをどのような順序で実行し、それぞれのアプリケーションについて次のアプリケーションに切り換えるまでにどれだけの時間を許すべきかを決定する。ハードウェア／ソフトウェアインターフェースシステムは、さらに、複数のアプリケーション間で内部メモリの共有を管理し、さらに、ハードディスク、プリンタ、およびダイアルアップポートなどの接続されているハードウェアデバイスへの入力およびそこからの出力を処理する。ハードウェア／ソフトウェアインターフェースシステムは、さらに、オペレーションのステータスおよび発生した可能性のあるエラーに関するメッセージをそれぞれのアプリケーション（および、場合によってはエンドユーザ）に送信する。ハードウェア／ソフトウェアインターフェースシステムは、さらに、バッチジョブ（例えば、印刷）の管理の負担を取り除き、開始アプリケーションがこのような作業から解放され、他の処理および／またはオペレーションを再開できるようにすることもできる。並列処理機能を備えることができるコンピュータでは、ハードウェア／ソフトウェアインターフェースシステムは、さらに、プログラムを分割して一度に複数のプロセッサ上で実行させることも管理する。
ハードウェア／ソフトウェアインターフェースシステムのシェル（本明細書では単に「シェル」と呼ぶ）は、ハードウェア／ソフトウェアインターフェースシステムとの対話型エンドユーザインターフェースである。（シェルは、「コマンドインタプリタ」と呼ばれたり、オペレーティングシステムでは、「オペレーティングシステムシェル」と呼ばれたりもする。）シェルは、アプリケーションプログラムおよび／またはエンドユーザにより直接アクセス可能なハードウェア／ソフトウェアインターフェースシステムの外側の層である。シェルとは対照的に、カーネルはハードウェアコンポーネントと直接やり取りするハードウェア／ソフトウェアインターフェースシステムの一番内側の層である。
本発明の多数の実施形態は、コンピュータ化されたシステムに特によく適していると考えられるが、本明細書では、本発明をそのような実施形態に限定することを一切意図していない。それどころか、本明細書で使用されているように、「コンピュータシステム」という用語は、情報を格納し処理することができ、および／または格納されている情報を使用してデバイス自体のビヘイビアまたは実行を、そのようなデバイスがその性質上電子デバイスであろうと、機械デバイスであろうと、論理デバイスであろうと、仮想デバイスであろうと、関係なく、制御できることができるありとあらゆるデバイスを包含することが意図されている。
Ｂ．従来のファイルベースのストレージ
ほとんどの今日のコンピュータシステムでは、「ファイル」は、ハードウェア／ソフトウェアインターフェースシステムだけでなくアプリケーションプログラム、データセットなどをも含むことができる格納可能な情報のユニットである。現代的なすべてのハードウェア／ソフトウェアインターフェースシステム（Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ、ＭａｃＯＳ、仮想マシンシステムなど）では、ファイルは、ハードウェア／ソフトウェアインターフェースシステムにより操作可能な情報（例えば、データ、プログラムなど）の基本的な個別の（格納可能および取り出し可能な）ユニットである。ファイルのグループは、「フォルダ」単位で一般的には編成される。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃｉｎｔｏｓｈ ＯＳ、およびその他のハードウェア／ソフトウェアインターフェースシステムでは、フォルダとは、取り出し可能、移動可能、そして単一の情報ユニットとして他の何らかの手段により操作できるファイルのコレクションのことである。これらのフォルダは、次に、「ディレクトリ」（以下で詳述する）と呼ばれるツリーベースの階層型配列で編成される。ＤＯＳ、ｚ／ＯＳ、およびほとんどのＵｎｉｘ（登録商標）ベースのオペレーティングシステムなど他のいくつかのハードウェア／ソフトウェアインターフェースシステムでは、「ディレクトリ」および／または「フォルダ」という用語は交換して使用することができ、また以前のＡｐｐｌｅコンピュータシステム（例えば、Ａｐｐｌｅ ＩＩｅ）ではディレクトリの代わりに「カタログ」という用語を使用していたが、本明細書で使用されているように、これらの用語はすべて、同義語であり交換可能であるとみなし、階層型情報記憶構造およびそのフォルダおよびファイルコンポーネントに対する他のすべての相当する用語および参照を含むことを意図している。
従来、ディレクトリ（別名、フォルダのディレクトリ）は、ツリーベースの階層構造であり、ファイルは複数のフォルダにグループ化され、フォルダは、さらに、ディレクトリツリーを含む相対的ノード位置に応じて配列される。例えば、図２Ａに例示されているように、ＤＯＳベースのファイルシステムのベースフォルダ（または「ルートディレクトリ」）２１２は、複数のフォルダ２１４を含むことができ、それぞれのフォルダは、さらに、追加フォルダ（その特定のフォルダの「サブフォルダ」として）２１６を含むことができ、それぞれ、さらに、追加フォルダを含むことができ、というように無限に続けることができる。これらのフォルダはそれぞれ、１つまたは複数のファイル２２０を保持できるが、ハードウェア／ソフトウェアインターフェースシステムレベルでは、フォルダ内の個々のファイルは、ツリー階層内のその位置以外共通するものは何も持たない。ファイルをフォルダ階層に編成するこのアプローチは、ファイルを格納するために使用される標準的な記憶媒体（例えば、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理的構成を間接的に反映することは驚くことではない。
前記に加えて、それぞれのフォルダは、そのサブフォルダおよびそのファイル用のコンテナである。つまり、それぞれのフォルダはそのサブフォルダおよびファイルを所有するということである。例えば、フォルダがハードウェア／ソフトウェアインターフェースシステムにより削除されると、そのフォルダのサブフォルダおよびファイルも削除される（それぞれのサブフォルダの場合、さらにその所有するサブフォルダおよびファイルを再帰的に含む）。同様に、それぞれのファイルは、一般的に、１つのフォルダのみにより所有される。ファイルはコピーされ、そのコピーは異なるフォルダに配置されることができるが、ファイルのコピーはそれ自体、オリジナルとの直接の関連を持たない、異なる別のユニットである（例えば、オリジナルのファイルに変更を加えても、ハードウェア／ソフトウェアインターフェースシステムレベルではそのコピーファイルに反映されない）。この点に関して、ファイルおよびフォルダは、本質的に特徴として「物理的」である。それは、フォルダは物理的コンテナのように取り扱われ、ファイルはそれらのコンテナ内の離散的な別々の物理的要素として取り扱われるからである。
ＩＩ．データの編成、検索、および共有のための新しいストレージプラットフォーム
本発明は、データの編成、検索、および共有のためのストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、上述の種類の既存のファイルシステムおよびデータベースシステムを超えてデータプラットフォームの概念を拡張し、広げるものであり、Ｉｔｅｍと呼ばれるデータの新しい形態を含む、すべての型のデータ用のストアとなるように設計されている。
Ａ．用語解説
本明細書で使用されているように、また請求項で使用されているように、以下の用語は以下の意味を持つ。
「Ｉｔｅｍ」は、単純ファイルとは異なり、ハードウェア／ソフトウェアインターフェースシステムシェルによりエンドユーザに対し公開されるすべてのオブジェクトにわたって一般的にサポートされるプロパティの基本集合を持つオブジェクトであるハードウェア／ソフトウェアインターフェースシステムにアクセスできる格納可能情報のユニットである。Ｉｔｅｍは、さらに、新しいプロパティおよび関係を導入することができる機能を含むすべてのＩｔｅｍ型にわたって一般的にサポートされるプロパティおよび関係も有する（本明細書の後のほうで詳述する）。
「オペレーティングシステム」（ＯＳ）は、アプリケーションプログラムとコンピュータハードウェアとの間の媒介として動作する特別なプログラムである。オペレーティングシステムは、ほとんどの場合、シェルおよびカーネルを備える。
「ハードウェア／ソフトウェアインターフェースシステム」は、コンピュータシステム上で実行されるコンピュータシステムおよびアプリケーションの基礎となるハードウェアコンポーネント間のインターフェースとして使用される、ソフトウェア、またはハードウェアとソフトウェアとの組合せである。ハードウェア／ソフトウェアインターフェースシステムは、通常、オペレーティングシステムを備える（いくつかの実施形態では、オペレーティングシステムのみからなる）。ハードウェア／ソフトウェアインターフェースシステムは、さらに、仮想マシンマネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的等価物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的等価物、またはコンピュータシステム内のオペレーティングシステムの代わりとなる、またはそれへの追加となる他のそのようなソフトウェアコンポーネントを含むこともできる。ハードウェア／ソフトウェアインターフェースシステムの目的は、ユーザがアプリケーションプログラムを実行できるような環境を用意することである。ハードウェア／ソフトウェアインターフェースシステムの目標は、コンピュータシステムを使いやすくするだけでなく、コンピュータハードウェアを効率的な方法で利用できるようにすることである。
Ｂ．ストレージプラットフォームの概要
図３を参照すると、本発明によるストレージプラットフォーム３００は、データベースエンジン３１４上に実装されたデータストア３０２を備える。一実施形態では、データベースエンジンは、オブジェクトリレーショナルの拡張機能を備えるリレーショナルデータベースエンジンを含む。一実施形態では、リレーショナルデータベースエンジン３１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒリレーショナルデータベースエンジンを含む。
データストア３０２は、データの編成、検索、共有、同期、およびセキュリティをサポートするデータモデル３０４を実装する。データの特定の型は、スキーマ３４０などのスキーマで記述され、ストレージプラットフォーム３００は、以下で詳しく説明するように、それらのスキーマを展開するとともに、それらのスキーマを拡張するためのツール３４６を備える。
データストア３０２内に実装された変更追跡メカニズム３０６は、データストアへの変更を追跡する機能を備える。データストア３０２は、さらに、セキュリティ機能３０８および格上げ（promotion）／格下げ（demotion）機能３１０も備え、両方とも以下で詳述する。データストア３０２は、さらに、一組のアプリケーションプログラミングインターフェース３１２を備え、データストア３０２の機能を他のストレージプラットフォームコンポーネントおよびそのストレージプラットフォームを利用するアプリケーションプログラム（例えば、アプリケーションプログラム３５０ａ、３５０ｂ、および３５０ｃ）に公開する。
本発明のストレージプラットフォームは、さらに、アプリケーションプログラム３５０ａ、３５０ｂ、および３５０ｃなどのアプリケーションプログラムを、ストレージプラットフォームの前記の機能すべてにアクセスできるようにし、スキーマで記述されたデータにアクセスできるようにするアプリケーションプログラミングインターフェース（ＡＰＩ）３２２を備える。ストレージプラットフォームＡＰＩ３２２は、アプリケーションプログラムにより、ＯＬＥ ＤＢ ＡＰＩ３２４およびＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎ３２ ＡＰＩ３２６などの他のＡＰＩと併用することができる。
本発明のストレージプラットフォーム３００は、ユーザまたはシステム間でのデータの共有を円滑にする同期処理サービス３３０を含む、様々なサービス３２８をアプリケーションプログラムに提供することができる。例えば、同期処理サービス３３０では、データストア３０２と同じ形式を持つ他のデータストアとの相互運用性とともに、他の形式を持つデータストアへのアクセスをも可能にすることができる。ストレージプラットフォーム３００は、さらに、データストア３０２とＷｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイルシステム３１８などの既存のファイルシステムとの相互運用を可能にするファイルシステムの機能をも備える。
少なくとも一部の実施形態では、ストレージプラットフォーム３００は、さらに、データへの操作を可能にし、また他のシステムとのやり取りを可能にするための追加機能をアプリケーションプログラミングに付加することもできる。これらの機能は、Ｉｎｆｏ Ａｇｅｎｔサービス３３４および通知サービス３３２などの追加サービスの形態だけでなく、他のユーティリティ３３６の形態で具現化することができる。
少なくとも一部の実施形態では、ストレージプラットフォームは、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステム内に具現化されるか、またはそのなくてはならない一部を形成する。例えば、限定はしないが、本発明のストレージプラットフォームは、オペレーティングシステム、仮想マシンマネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的等価物、またはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的等価物で具現化されるか、またはそのなくてはならない一部を形成することができる。
本発明のストレージプラットフォームは、共通のストレージ基盤および図式化された（schematized）データを通じて、消費者、知識労働者、および企業に、より効率的なアプリケーション開発を行わせることができる。これは、データモデルに固有の機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法も包含し、拡張する機能豊富な拡張可能プログラミングサーフェスエリア（programming surface area）を提供する。
以下の説明、および様々な図において、本発明のストレージプラットフォーム３００は、「ＷｉｎＦＳ」と呼ぶことができる。しかし、この名称を使用してストレージプラットフォームを指すのは、説明の便宜上のことにすぎず、決して限定することを意図していない。
Ｃ．データモデル
本発明のストレージプラットフォーム３００のデータストア３０２は、ストア内に置かれているデータの編成、検索、共有、同期、およびセキュリティをサポートするデータモデルを実装する。本発明のデータモデルでは、「Ｉｔｅｍ」は、ストレージ情報の基本ユニットである。このデータモデルは、以下で詳述するが、ＩｔｅｍおよびＩｔｅｍ拡張を宣言し、Ｉｔｅｍ間の関係を確立し、Ｉｔｅｍ ＦｏｌｄｅｒｓとＣａｔｅｇｏｒｉｅｓ内にＩｔｅｍを編成するためのメカニズムを備える。
データモデルは、ＴｙｐｅｓとＲｅｌａｔｉｏｎｓｈｉｐｓという２つのプリミティブなメカニズムに依存している。Ｔｙｐｅｓは、Ｔｙｐｅのインスタンスの形態を制御する形式を定める構造である。その形式は、Ｐｒｏｐｅｒｔｉｅｓの順序集合として表される。Ｐｒｏｐｅｒｔｙは、与えられたＴｙｐｅの値または値の集合に対する名前である。例えば、ＵＳＰｏｓｔａｌＡｄｄｒｅｓｓ型は、プロパティＳｔｒｅｅｔ、Ｃｉｔｙ、Ｚｉｐ、Ｓｔａｔｅを持つことができ、その中で、Ｓｔｒｅｅｔ、Ｃｉｔｙ、ＳｔａｔｅはＳｔｒｉｎｇ型であり、ＺｉｐはＴｙｐｅ Ｉｎｔ３２である。Ｓｔｒｅｅｔプロパティに対しアドレスは複数の値をとりうるので、Ｓｔｒｅｅｔは、多値（つまり、値の集合）とすることができる。システムでは、他の型の構成で使用できるいくつかのプリミティブ型を定義している−これらは、Ｓｔｒｉｎｇ、Ｂｉｎａｒｙ、Ｂｏｏｌｅａｎ、Ｉｎｔ１６、Ｉｎｔ３２、Ｉｎｔ６４、Ｓｉｎｇｌｅ、Ｄｏｕｂｌｅ、Ｂｙｔｅ、ＤａｔｅＴｉｍｅ、Ｄｅｃｉｍａｌ、およびＧＵＩＤを含む。ＴｙｐｅのＰｒｏｐｅｒｔｉｅｓは、プリミティブ型のどれか、または（下記のいくつかの制約があるが）構成された型のどれかを使用して定義することができる。例えば、Ｐｒｏｐｅｒｔｉｅｓ ＣｏｏｒｄｉｎａｔｅとＡｄｄｒｅｓｓを持つＬｏｃａｔｉｏｎ Ｔｙｐｅが定義されうるが、Ａｄｄｒｅｓｓ Ｐｒｏｐｅｒｔｙは上述のようにＴｙｐｅ ＵＳＰｏｓｔａｌＡｄｄｒｅｓｓである。Ｐｒｏｐｅｒｔｉｅｓは、さらに、必須またはオプションとすることもできる。
Ｒｅｌａｔｉｏｎｓｈｉｐｓは、２つの型のインスタンスの集合の間のマッピングとして宣言され、それを表すことができる。例えば、Ｐｅｒｓｏｎ Ｔｙｐｅと、どの人々がどの場所に住んでいるかを定義するＬｉｖｅｓＡｔと呼ばれるＬｏｃａｔｉｏｎ Ｔｙｐｅとの間のＲｅｌａｔｉｏｎｓｈｉｐを宣言することができる。Ｒｅｌａｔｉｏｎｓｈｉｐは、１つの名前、２つの終点、つまり、ソース終点とターゲット終点を持つ。Ｒｅｌａｔｉｏｎｓｈｉｐｓは、さらに、プロパティの順序集合を持つこともできる。ＳｏｕｒｃｅとＴａｒｇｅｔの終点は両方ともＮａｍｅとＴｙｐｅを持つ。例えば、ＬｉｖｅｓＡｔ Ｒｅｌａｔｉｏｎｓｈｉｐは、Ｔｙｐｅ ＰｅｒｓｏｎのＯｃｃｕｐａｎｔと呼ばれるＳｏｕｒｃｅ、およびＴｙｐｅ ＬｏｃａｔｉｏｎのＤｗｅｌｌｉｎｇと呼ばれるＴａｒｇｅｔを持ち、さらに、居住者（occupant）がその住居（dwelling）に住んでいた期間を示すプロパティＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅを持つ。Ｐｅｒｓｏｎは、長い目で見ると複数の住居に居住する可能性があり、また住居には複数の住人がいる場合もあるので、ＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅ情報を入れるために最も適した場所は、関係（relationship）自体であることに注意されたい。
Ｒｅｌａｔｉｏｎｓｈｉｐｓは、終点の型として与えられた型により制約されるインスタンス間のマッピングを定義する。例えば、ＬｉｖｅｓＡｔ Ｒｅｌａｔｉｏｎｓｈｉｐは、ＡｕｔｏｍｏｂｉｌｅがＯｃｃｕｐａｎｔである関係とはなりえない。というのも、ＡｕｔｏｍｏｂｉｌｅはＰｅｒｓｏｎではないからである。
データモデルは、型の間の子型−親型関係（subtype-supertype relationship）の定義を許容する。ＢａｓｅＴｙｐｅ関係とも呼ばれる子型−親型関係は、Ｔｙｐｅ ＡがＴｙｐｅ Ｂに対しＢａｓｅＴｙｐｅならば、Ｂのすべてのインスタンスは、Ａのインスタンスでもあるというように定義される。これを表現するもう１つの方法は、Ｂに適合するすべてのインスタンスが、さらにＡにも適合しなければならないとするものである。例えば、ＡがＴｙｐｅ ＳｔｒｉｎｇのプロパティＮａｍｅを持つが、ＢはＴｙｐｅ Ｉｎｔ１６のプロパティＡｇｅを持つ場合、Ｂのインスタンスはどれも、ＮａｍｅとＡｇｅの両方を持たなければならないということになる。型階層は、ルートに一つの親型（supertype）を有するツリーと考えることができる。ルートからの分岐は、第１レベルの子型（subtype）を定め、このレベルの分岐は、第２レベルの子型を定め、というように、それ自体子型を持たない最も先端の葉である子型へ進む。ツリーは、均一な深さとなるように制約されないが、循環を含むことはできない。与えられたＴｙｐｅは、０個またはそれ以上の子型と０個または１個の親型を持つことができる。与えられたインスタンスは、その型の親型とともに１つの型に適合することができる。別の言い方をすると、ツリー内の任意のレベルにおいて与えられたインスタンスについて、そのインスタンスはそのレベルにおいて１つの子型に適合することができるということである。
型は、型のインスタンスがさらにその型の子型のインスタンスでもなければならない場合にＡｂｓｔｒａｃｔという。
１．Ｉｔｅｍｓ
Ｉｔｅｍは、単純ファイルとは異なり、ストレージプラットフォームによりエンドユーザまたはアプリケーションプログラムに対し公開されるすべてのオブジェクトにわたって一般的にサポートされるプロパティの基本集合を持つオブジェクトである格納可能情報のユニットである。Ｉｔｅｍは、さらに、以下で説明するように、新しいプロパティおよび関係を導入することができる機能を含むすべてのＩｔｅｍ型にわたって一般的にサポートされるプロパティおよび関係も有する。
Ｉｔｅｍは、コピー、削除、移動、開く、印刷、バックアップ、リストア、複製などの共通オペレーション用のオブジェクトである。Ｉｔｅｍは、格納し、取り出すことのできるユニットであり、ストレージプラットフォームにより操作される格納可能情報のすべての形態が、Ｉｔｅｍ、Ｉｔｅｍのプロパティ、またはＩｔｅｍ間のＲｅｌａｔｉｏｎｓｈｉｐｓとして存在し、それぞれについては以下で詳述される。
Ｉｔｅｍは、（あらゆる種類の）Ｃｏｎｔａｃｔｓ、Ｐｅｏｐｌｅ、Ｓｅｒｖｉｃｅｓ、Ｌｏｃａｔｉｏｎｓ、Ｄｏｃｕｍｅｎｔｓなどの現実世界の容易に理解できるデータのユニットを表すことを意図されている。図５Ａは、Ｉｔｅｍの構造を例示するブロック図である。Ｉｔｅｍの未修飾の名前は「Ｌｏｃａｔｉｏｎ」である。Ｉｔｅｍの修飾名は「Ｃｏｒｅ．Ｌｏｃａｔｉｏｎ」であり、これは、このＩｔｅｍ構造がＣｏｒｅ Ｓｃｈｅｍａ内のＩｔｅｍの特定の型として定義されることを示している。（Ｃｏｒｅ Ｓｃｈｅｍａについては、本明細書の後のほうで詳しく説明する。）
Ｌｏｃａｔｉｏｎ Ｉｔｅｍは、ＥＡｄｄｒｅｓｓｅｓ、ＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎ、Ｎｅｉｇｈｂｏｒｈｏｏｄ、およびＰｏｓｔａｌＡｄｄｒｅｓｓｅｓを含む複数のプロパティを持つ。それぞれに対するプロパティの特定の型は、プロパティ名の直後に示され、コロン（「：」）でプロパティ名と区切られる。型名の右には、そのプロパティ型について許された値の個数があり、これは角括弧（「［ ］」）の間に示され、コロン（「：」）の右にあるアスタリスク（「＊」）は、未指定および／または無制限の数（「ｍａｎｙ」）を示す。コロンの右にある「１」は、１つの値がありえることを示す。コロンの左にあるゼロ（「０」）はプロパティがオプションであることを示す（値がまったくない場合もある）。コロンの左にある「１」は、少なくとも１つの値がなければならないことを示す（プロパティは必須である）。ＮｅｉｇｈｂｏｒｈｏｏｄおよびＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎは、両方とも、定義済みのデータ型または「単純型」（また、本明細書では大文字使用でないことにより表される）である、型「ｎｖａｒｃｈａｒ」（または同等の型）である。しかし、ＥＡｄｄｒｅｓｓｅｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓｅｓは、それぞれ型ＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓの定義済み型または「複合型」（本明細書では大文字使用で表される）のプロパティである。複合型は、１つまたは複数の単純データ型および／または他の複合型から派生した型である。Ｉｔｅｍのプロパティに対する複合型は、さらに、複合型の詳細はそのプロパティを定義するためにイミディエイトＩｔｅｍ内にネストされるため「ネストされた要素」も構成し、それらの複合型に関係する情報は、（本明細書な後のほうで説明するように、Ｉｔｅｍの境界内の）それらのプロパティを持つＩｔｅｍとともに保持される。型付け（typing）のこれらの概念は、よく知られており、当業者であれば容易に理解できる。
図５Ｂは、複合プロパティ型ＰｏｓｔａｌＡｄｄｒｅｓｓおよびＥＡｄｄｒｅｓｓを例示するブロック図である。ＰｏｓｔａｌＡｄｄｒｅｓｓプロパティ型は、プロパティ型ＰｏｓｔａｌＡｄｄｒｅｓｓのＩｔｅｍが０または１つのＣｉｔｙ値、０または１つのＣｏｕｎｔｒｙＣｏｄｅ値、０または１つのＭａｉｌＳｔｏｐ値、および任意の数（０から多数）のＰｏｓｔａｌＡｄｄｒｅｓｓＴｙｐｅｓなどを持つことを予想できるものとして定義する。このようにして、Ｉｔｅｍ内の特定のプロパティに対するデータの形状が定義される。ＥＡｄｄｒｅｓｓプロパティ型も、同様に、示されているように定義される。このＡｐｐｌｉｃａｔｉｏｎにおいてオプションにより使用されるが、Ｌｏｃａｔｉｏｎ Ｉｔｅｍ内の複合型を表すもう１つの方法は、Ｉｔｅｍをそこにリストされている複合型の個々のプロパティで描画することである。図５Ｃは、複合型がさらに記述されるＬｏｃａｔｉｏｎ Ｉｔｅｍを例示するブロック図である。しかし、この図５Ｃ内のＬｏｃａｔｉｏｎ Ｉｔｅｍのこの代替表現は、図５Ａに例示されているものとまったく同じＩｔｅｍに対するものであると理解すべきである。本発明のストレージプラットフォームでは、さらに、サブタイプ化も可能であり、それによって、一方のプロパティ型を他方の子型とすることができる（ただし、一方のプロパティ型は他方の親のプロパティ型のプロパティを継承する）。
プロパティおよびそのプロパティ型と同様のＩｔｅｍは、本質的に、サブタイプ化の対象ともなりうる自Ｉｔｅｍ Ｔｙｐｅｓを表す。つまり、本発明のいくつかの実施形態におけるストレージプラットフォームでは、Ｉｔｅｍを他のＩｔｅｍの子型とすることができるということである（それによって、一方のＩｔｅｍは他方の親Ｉｔｅｍのプロパティを継承する）。さらに、本発明の様々な実施形態について、すべてのＩｔｅｍはＢａｓｅ Ｓｃｈｅｍａに見られる第１の、基礎的なＩｔｅｍ型である「Ｉｔｅｍ」Ｉｔｅｍ型の子型である。（Ｂａｓｅ Ｓｃｈｅｍａは、さらに、本明細書の後のほうで詳しく説明される。）図６Ａは、Ｉｔｅｍ、つまりこのＩｎｓｔａｎｃｅのＬｏｃａｔｉｏｎ ＩｔｅｍをＢａｓｅ ＳｃｈｅｍａにあるＩｔｅｍ Ｉｔｅｍ型の子型であるとして例示している。この図面では、矢印は、（他のすべてのＩｔｅｍのような）Ｌｏｃａｔｉｏｎ Ｉｔｅｍが、Ｉｔｅｍ Ｉｔｅｍ型の子型であることを示している。Ｉｔｅｍ Ｉｔｅｍ型は、他のすべてのＩｔｅｍの派生元である基礎的なＩｔｅｍとして、ＩｔｅｍＩｄおよび様々なタイムスタンプなどの重要なプロパティを多数持ち、それによって、オペレーティングシステムにおいて、すべてのＩｔｅｍの標準プロパティを定義する。この図では、Ｉｔｅｍ Ｉｔｅｍ型のこれらのプロパティは、Ｌｏｃａｔｉｏｎにより継承され、それによって、Ｌｏｃａｔｉｏｎのプロパティになる。
Ｉｔｅｍ Ｉｔｅｍ型から継承されたＬｏｃａｔｉｏｎ Ｉｔｅｍにおいてプロパティを表す他の方法は、そこにリストされている親Ｉｔｅｍから各プロパティ型の個々のプロパティでＬｏｃａｔｉｏｎを描画することである。図６Ｂは、イミディエイトプロパティに加えて継承型が記述されるＬｏｃａｔｉｏｎ Ｉｔｅｍを例示するブロック図である。このＩｔｅｍは図５Ａに例示されているのと同じＩｔｅｍであるが、この図では、Ｌｏｃａｔｉｏｎはそのプロパティのすべてとともに例示されており、両方ともイミディエイトであり−この図と図５Ａの両方に示されている−および継承される−この図に示されているが、図５Ａには示されていない−ことに注意し、理解されたい（しかし、図５Ａでは、Ｌｏｃａｔｉｏｎ ＩｔｅｍがＩｔｅｍ Ｉｔｅｍ型の子型であることを矢印で示すことによりそれらのプロパティが参照されている）。
Ｉｔｅｍは、スタンドアロンのオブジェクトであり、そのため、Ｉｔｅｍを削除すると、それらのＩｔｅｍのイミディエイトおよび継承プロパティもすべて削除される。同様に、Ｉｔｅｍを取り出した場合に受け取る内容は、Ｉｔｅｍおよびそのイミディエイトおよび継承プロパティのすべて（複合プロパティ型に関係する情報を含む）である。本発明のいくつかの実施形態では、特定のＩｔｅｍを取り出す際にプロパティの部分集合を要求することが可能であるが、そのような実施形態の多くの既定（default）として、取り出したときにイミディエイトおよび継承プロパティのすべてをＩｔｅｍに供給する。さらに、Ｉｔｅｍのプロパティは、新しいプロパティをそのＩｔｅｍの型の既存のプロパティに追加することにより拡張することもできる。これらの「拡張」は、これ以降、Ｉｔｅｍの本物のプロパティであり、そのＩｔｅｍ型の子型は、自動的に、拡張プロパティを含むことができる。
Ｉｔｅｍの「境界」は、そのプロパティ（複合プロパティ型、拡張などを含む）により表される。Ｉｔｅｍの境界は、さらに、コピー、削除、移動、作成などのＩｔｅｍに対し実行されるオペレーションの限界も表す。例えば、本発明のいくつかの実施形態では、Ｉｔｅｍがコピーされる場合、そのＩｔｅｍの境界内にあるものもすべてコピーされる。Ｉｔｅｍ毎に、境界は以下を包含する。
・ ＩｔｅｍのＩｔｅｍ Ｔｙｐｅ、およびＩｔｅｍが他のＩｔｅｍの子型の場合（すべてのＩｔｅｍがＢａｓｅ Ｓｃｈｅｍａ内の単一ＩｔｅｍおよびＩｔｅｍ Ｔｙｐｅから派生する本発明のいくつかの実施形態の場合のように）は、任意の適用可能な子型情報（つまり、親Ｉｔｅｍ Ｔｙｐｅに関係する情報）。コピー元のオリジナルのＩｔｅｍが他のＩｔｅｍの子型の場合、そのコピーも、その同じＩｔｅｍの子型ともなりうる。
・ もしあればＩｔｅｍの複合型プロパティおよび拡張。オリジナルのＩｔｅｍが複合型のプロパティ（ネイティブまたは拡張）を持つ場合、そのコピーも同じ複合型を持ちうる。
・ 「所有関係」に関するＩｔｅｍのレコード、つまり、このＩｔｅｍ（「Ｏｗｎｉｎｇ Ｉｔｅｍ」）によって所有される他のＩｔｅｍ（「Ｔａｒｇｅｔ Ｉｔｅｍ」）のＩｔｅｍ自身のリスト。これは、特に、以下で詳しく説明する、Ｉｔｅｍ Ｆｏｌｄｅｒｓに関して特に適切であり、規則では、すべてのＩｔｅｍは少なくとも１つのＩｔｅｍ Ｆｏｌｄｅｒに属していなければならないことを以下で規定している。さらに、埋め込まれているアイテム−以下でさらに詳しく説明する−に関しては、埋め込みアイテムは、コピー、削除などのオペレーションに対して埋め込まれているＩｔｅｍの一部と考えられる。
２．Ｉｔｅｍの識別
Ｉｔｅｍは、ＩｔｅｍＩＤを持つ大域的アイテム空間（global items space）内で一意に識別される。Ｂａｓｅ．Ｉｔｅｍ型は、ＩｔｅｍのＩＤを格納する型ＧＵＩＤのフィールドＩｔｅｍＩＤを定義する。Ｉｔｅｍは、データストア３０２内にちょうど１つのＩＤを持たなければならない。
ａ）アイテム参照
アイテム参照は、Ｉｔｅｍを特定し、識別するための情報を格納するデータ構造体である。データモデルでは、抽象型は、すべてのアイテム参照型の派生元のＩｔｅｍＲｅｆｅｒｅｎｃｅという名前を持つものとして定義される。ＩｔｅｍＲｅｆｅｒｅｎｃｅ型は、Ｒｅｓｏｌｖｅという名前の仮想メソッドを定義する。Ｒｅｓｏｌｖｅメソッドは、ＩｔｅｍＲｅｆｅｒｅｎｃｅを解決して、Ｉｔｅｍを返す。このメソッドは、参照が与えられているＩｔｅｍを取り出す関数を実装するＩｔｅｍＲｅｆｅｒｅｎｃｅの具体的な子型によりオーバーライドされる。Ｒｅｓｏｌｖｅメソッドは、ストレージプラットフォームＡＰＩ３２２の一部として呼び出される。
（１）ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅ
ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅはＩｔｅｍＲｅｆｅｒｅｎｃｅの子型である。これは、ＬｏｃａｔｏｒおよびＩｔｅｍＩＤフィールドを定義する。Ｌｏｃａｔｏｒフィールドは、アイテム領域（domain）に名前を付ける（つまり、識別する）。これは、Ｌｏｃａｔｏｒの値をアイテム領域に解決することができるロケータ解決メソッドにより処理される。ＩｔｅｍＩＤフィールドは、ＩｔｅｍＩＤ型である。
（２）ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅ
ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅは、ＬｏｃａｔｏｒおよびＰａｔｈフィールドを定義するＩｔｅｍＲｅｆｅｒｅｎｃｅの特殊化（specializaiton）である。Ｌｏｃａｔｏｒフィールドは、アイテム領域を識別する。これは、Ｌｏｃａｔｏｒの値をアイテム領域に解決することができるロケータ解決メソッドにより処理される。Ｐａｔｈフィールドは、Ｌｏｃａｔｏｒにより与えられるアイテム領域をルートとするストレージプラットフォーム名前空間内の（相対）パスを含む。
この型の参照は、ｓｅｔオペレーションで使用することはできない。参照は、一般に、パス解決プロセスを通じて解決されなければならない。ストレージプラットフォームＡＰＩ３２２のＲｅｓｏｌｖｅメソッドは、この機能を備える。
ｂ）参照型階層
上述の参照形態は、図１１に例示されている参照型階層を通じて表される。これらの型から継承する追加参照型は、スキーマで定義することができる。それらは、ターゲットフィールドの型として関係宣言の中で使用することができる。
３．Ｉｔｅｍ ＦｏｌｄｅｒｓおよびＣａｔｅｇｏｒｉｅｓ
以下で詳しく説明するが、Ｉｔｅｍのグループは、Ｉｔｅｍ Ｆｏｌｄｅｒｓ（ファイルフォルダと混同すべきでない）と呼ばれる特別なＩｔｅｍに編成されることができる。しかし、大半のファイルシステムとは異なり、Ｉｔｅｍは、複数のＩｔｅｍ Ｆｏｌｄｅｒに属すことができ、そのため、Ｉｔｅｍが一方のＩｔｅｍ Ｆｏｌｄｅｒでアクセスされ改訂された場合、この改訂されたＩｔｅｍは、他方のＩｔｅｍフォルダから直接アクセスすることができる。本質的に、Ｉｔｅｍへのアクセスは異なるＩｔｅｍ Ｆｏｌｄｅｒｓから発生しうるが、実際にアクセスされる内容は、事実、まったく同じＩｔｅｍである。しかし、Ｉｔｅｍ Ｆｏｌｄｅｒは、必ずしも、そのメンバＩｔｅｍのすべてを所有するわけではなく、または単に、他のフォルダとともにＩｔｅｍを共同所有することができ、Ｉｔｅｍ Ｆｏｌｄｅｒを削除しても、その結果Ｉｔｅｍの削除も必ずしも行われるわけではない。しかしながら、本発明のいくつかの実施形態では、Ｉｔｅｍは、少なくとも１つのＩｔｅｍ Ｆｏｌｄｅｒに属していなければならず、したがって、特定のＩｔｅｍに対する単独のＩｔｅｍ Ｆｏｌｄｅｒが削除されると、ある実施形態では、Ｉｔｅｍは自動的に削除されるか、または他の実施形態では、Ｉｔｅｍは自動的に、既定のＩｔｅｍ Ｆｏｌｄｅｒ（例えば、様々なファイル−フォルダベースのシステムで使用される類似名フォルダと概念上類似の「Ｔｒａｓｈ Ｃａｎ」Ｉｔｅｍ Ｆｏｌｄｅｒ）のメンバとなる。
また以下で詳述するが、Ｉｔｅｍは、さらに、（ａ）Ｉｔｅｍ Ｔｙｐｅ（またはＴｙｐｅｓ）、（ｂ）特定のイミディエイトまたは継承プロパティ（または複数のプロパティ）、または（ｃ）Ｉｔｅｍプロパティに対応する特定の値（または複数の値）などの共通の記述されている特性に基づいてＣａｔｅｇｏｒｉｅｓに属している場合がある。例えば、個人連絡情報の特定のプロパティを含むＩｔｅｍは、自動的にＣｏｎｔａｃｔ Ｃａｔｅｇｏｒｙに属すことがあり、そうすれば連絡先情報プロパティを含むＩｔｅｍも同様に、自動的にこのＣａｔｅｇｏｒｙに属するのである。同様に、値「Ｎｅｗ Ｙｏｒｋ Ｃｉｔｙ」を持つ位置プロパティが設定されているＩｔｅｍであれば、自動的にＮｅｗ Ｙｏｒｋ Ｃｉｔｙ Ｃａｔｅｇｏｒｙに属すことが可能である。
Ｉｔｅｍ Ｆｏｌｄｅｒｓは相互関連性のない（つまり、共通の記述された特性を持たない）Ｉｔｅｍを含むことができるが、Ｃａｔｅｇｏｒｙ内のそれぞれのＩｔｅｍは、そのＣａｔｅｇｏｒｙについて記述された共通の型、プロパティ、または値（「共通性」）を持ち、Ｃａｔｅｇｏｒｙ内の他のＩｔｅｍとの関係、および他のＩｔｅｍ同士の間の関係の基礎をなすことがこの共通性であるという点において、Ｃａｔｅｇｏｒｉｅｓは、Ｉｔｅｍ Ｆｏｌｄｅｒｓと概念上異なる。さらに、特定のＦｏｌｄｅｒへのＩｔｅｍの帰属関係（membership）は、そのＩｔｅｍの特定の態様に基づく強制的なものではないが、いくつかの実施形態では、共通性がカテゴリについてＣａｔｅｇｏｒｙに関係しているすべてのＩｔｅｍは、ハードウェア／ソフトウェアインターフェースシステムレベルにおいてＣａｔｅｇｏｒｙのメンバに自動的になることが可能である。概念上、Ｃａｔｅｇｏｒｉｅｓは、帰属関係が特定のクエリの結果に基づく（データベースを背景とした場合のように）仮想Ｉｔｅｍ Ｆｏｌｄｅｒｓと考えることもでき、また（Ｃａｔｅｇｏｒｙの共通性により定義された）このクエリの条件を満たすＩｔｅｍは、Ｃａｔｅｇｏｒｙの帰属関係を含むであろう。
図４は、本発明の様々な実施形態におけるＩｔｅｍ、Ｉｔｅｍ Ｆｏｌｄｅｒ、およびＣａｔｅｇｏｒｙ間の構造的関係を例示する。複数のＩｔｅｍ４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、および４２０は、様々なＩｔｅｍ Ｆｏｌｄｅｒｓ４２２、４２４、４２６、４２８、および４３０のメンバである。複数のＩｔｅｍ Ｆｏｌｄｅｒに属すＩｔｅｍもあり、例えば、Ｉｔｅｍ４０２はＩｔｅｍ Ｆｏｌｄｅｒｓ４２２および４２４に属している。いくつかのＩｔｅｍ、例えば、Ｉｔｅｍ４０２、４０４、４０６、４０８、４１０、および４１２は、１つまたは複数のＣａｔｅｇｏｒｉｅｓ４３２、４３４、および４３６のメンバでもあるが、例えば、Ｉｔｅｍ４１４、４１６、４１８、および４２０はどのＣａｔｅｇｏｒｉｅｓにも属しえない（ただし、これはプロパティの所有が自動的にＣａｔｅｇｏｒｙへの帰属を意味するいくつかの実施形態ではほとんどありえず、Ｉｔｅｍは、そのような実施形態におけるカテゴリのメンバとならないためには完全に無特徴でなければならないであろう）。フォルダの階層構造と対照的に、ＣａｔｅｇｏｒｉｅｓとＩｔｅｍ Ｆｏｌｄｅｒｓは両方とも、図に示されているように有向グラフに比較的類似している。いずれにせよ、Ｉｔｅｍ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、およびＣａｔｅｇｏｒｉｅｓは、（異なるＩｔｅｍ Ｔｙｐｅｓであるにもかかわらず）すべてＩｔｅｍである。
ファイル、フォルダ、およびディレクトリとは対照的に、本発明のＩｔｅｍ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、およびＣａｔｅｇｏｒｉｅｓについては、物理的コンテナに相当する概念がなく、したがって、Ｉｔｅｍはそのような複数の場所に存在する可能性があるため、本質的に「物理的」という特徴を持たない。Ｉｔｅｍが複数のＩｔｅｍ Ｆｏｌｄｅｒロケーションで存在できることとともに、Ｃａｔｅｇｏｒｉｅｓに編成されることにより、当業で現在利用できるレベルを超える、ハードウェア／ソフトウェアインターフェースレベルにおいて、データ操作およびストレージ構造の機能が高められ、豊富になっている。
４．Ｓｃｈｅｍａｓ
ａ）Ｂａｓｅ Ｓｃｈｅｍａ
Ｉｔｅｍの作成および使用に普遍的基盤を用意するため、本発明のストレージプラットフォームの様々な実施形態は、Ｉｔｅｍおよびプロパティの作成および編成に使用する概念フレームワークを確立するＢａｓｅ Ｓｃｈｅｍａを備える。Ｂａｓｅ Ｓｃｈｅｍａは、Ｉｔｅｍおよびプロパティのいくつかの特殊な型、および子型をさらに派生することができる派生元のこれらの特別な基礎型の特徴を定義する。このＢａｓｅ Ｓｃｈｅｍａを使用することにより、プログラマは、Ｉｔｅｍ（およびそれぞれの型）をプロパティ（およびそれぞれの型）から概念的に区別することができる。さらに、Ｂａｓｅ Ｓｃｈｅｍａでは、すべてのＩｔｅｍ（およびその対応するＩｔｅｍ Ｔｙｐｅｓ）がＢａｓｅ Ｓｃｈｅｍａ内のこの基礎的なＩｔｅｍ（およびその対応するＩｔｅｍ Ｔｙｐｅ）から派生するときにすべてのＩｔｅｍが所有することができるプロパティの基礎的な集合を規定する。
図７に例示されているように、また本発明のいくつかの実施形態に関して、Ｂａｓｅ Ｓｃｈｅｍａは、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＰｒｏｐｅｒｔｙＢａｓｅという３つの最上位の型を定義する。図に示されているように、Ｉｔｅｍ型は、この基礎的な「Ｉｔｅｍ」Ｉｔｅｍ型のプロパティにより定義される。対照的に、最上位レベルのプロパティ型「ＰｒｏｐｅｒｔｙＢａｓｅ」は、定義済みプロパティを持たず、他のすべてのプロパティ型の派生元となる、すべての派生プロパティ型が相互に関係付けられる際の単なるアンカーにすぎない（通常は単一のプロパティ型から派生する）。Ｅｘｔｅｎｓｉｏｎ型プロパティは、Ｉｔｅｍが複数の拡張を持つ可能性があるときに、拡張でどのＩｔｅｍが拡張されるかを定義するとともに、一方の拡張を他方の拡張から区別するための識別をも定義する。
ＩｔｅｍＦｏｌｄｅｒは、Ｉｔｅｍから継承されたプロパティに加えて、（もしあれば）メンバへのリンクを確立するＲｅｌａｔｉｏｎｓｈｉｐを特徴とするＩｔｅｍ Ｉｔｅｍ型の子型であるが、ＩｄｅｎｔｉｔｙＫｅｙとＰｒｏｐｅｒｔｙは両方とも、ＰｒｏｐｅｒｔｙＢａｓｅの子型である。同様に、ＣａｔｅｇｏｒｙＲｅｆは、ＩｄｅｎｔｉｔｙＫｅｙの子型である。
ｂ）Ｃｏｒｅ Ｓｃｈｅｍａ
本発明のストレージプラットフォームの様々な実施形態は、さらに、最上位レベルのＩｔｅｍ型構造の概念フレームワークを提供するＣｏｒｅ Ｓｃｈｅｍａを含む。図８Ａは、Ｃｏｒｅ Ｓｃｈｅｍａ内のＩｔｅｍを例示するブロック図であり、図８Ｂは、Ｃｏｒｅ Ｓｃｈｅｍａ内のプロパティ型を例示するブロック図である。異なる拡張子（＊．ｃｏｍ、＊．ｅｘｅ、＊．ｂａｔ、＊．ｓｙｓなど）を持つファイルとファイル−フォルダベースのシステムのそのような他の基準を持つファイルとの区別は、Ｃｏｒｅ Ｓｃｈｅｍａの関数に類似している。Ｃｏｒｅ Ｓｃｈｅｍａが、Ｉｔｅｍベースのハードウェア／ソフトウェアインターフェースシステムでは、直接的に（Ｉｔｅｍ型により）または間接的に（Ｉｔｅｍ子型により）、すべてのＩｔｅｍを、Ｉｔｅｍベースのハードウェア／ソフトウェアインターフェースシステムが理解し、所定の予測可能な方法で直接処理できる１つまたは複数のＣｏｒｅ Ｓｃｈｅｍａ Ｉｔｅｍ型に特徴付ける、コアＩｔｅｍ型の集合を定義する。定義済みＩｔｅｍ型は、Ｉｔｅｍベースのハードウェア／ソフトウェアインターフェースシステム内の最も一般的なＩｔｅｍを反映し、したがって、一定レベルの効率が、Ｃｏｒｅ Ｓｃｈｅｍａを含む定義済みＩｔｅｍ型を認識するＩｔｅｍベースのハードウェア／ソフトウェアインターフェースシステムにより得られる。
いくつかの実施形態では、Ｃｏｒｅ Ｓｃｈｅｍａは拡張可能でない−つまり、Ｃｏｒｅ Ｓｃｈｅｍａの一部である特定の定義済み派生Ｉｔｅｍ型を除き、追加Ｉｔｅｍ型を直接、Ｂａｓｅ ＳｃｈｅｍａのＩｔｅｍ型からサブタイプ化することはできない。後続のすべてのＩｔｅｍ型が必ずＣｏｒｅ Ｓｃｈｅｍａ Ｉｔｅｍ型の子型であるため、Ｃｏｒｅ Ｓｃｈｅｍａへの拡張を禁止することにより（つまり、新しいＩｔｅｍをＣｏｒｅ Ｓｃｈｅｍａに追加することを禁止することにより）、ストレージプラットフォームはＣｏｒｅ Ｓｃｈｅｍａ Ｉｔｅｍ型の使用を必須とする。この構造により、コアＩｔｅｍ型の定義済み集合を持つ利点も維持しながら、追加Ｉｔｅｍ型を定義する自由度も十分に高められる。
本発明の様々な実施形態について、図８Ａを参照すると、Ｃｏｒｅ Ｓｃｈｅｍａによってサポートされている特定のＩｔｅｍ型は以下のうちの１つまたは複数を含むことができる。
・ Ｃａｔｅｇｏｒｉｅｓ：このＩｔｅｍ Ｔｙｐｅ（およびそれから派生した子型）のＩｔｅｍは、Ｉｔｅｍベースのハードウェア／ソフトウェアインターフェースシステムの有効なＣａｔｅｇｏｒｉｅｓを表す。
・ Ｃｏｍｍｏｄｉｔｉｅｓ：価値を有する識別可能なものであるＩｔｅｍ。
・ Ｄｅｖｉｃｅｓ：情報処理機能をサポートする論理構造を備えるＩｔｅｍ。
・ Ｄｏｃｕｍｅｎｔｓ：Ｉｔｅｍベースのハードウェア／ソフトウェアインターフェースシステムにより解釈されないが、代わりにドキュメント型に対応するアプリケーションプログラムにより解釈されるコンテンツを持つＩｔｅｍ。
・ Ｅｖｅｎｔｓ：環境内で生じた何らかの出来事を記録するＩｔｅｍ。
・ Ｌｏｃａｔｉｏｎｓ：物理的場所を表すＩｔｅｍ（例えば、地理的場所）。
・ Ｍｅｓｓａｇｅｓ：２つ以上のプリンシパルの間の通信のＩｔｅｍ（以下に定義する）。
・ Ｐｒｉｎｃｉｐａｌｓ：ＩｔｅｍＩＤだけでなく少なくとも１つの決定的に証明可能なＩＤを持つＩｔｅｍ（例えば、人、組織、グループ、世帯、機関、サービスなどの識別）。
・ Ｓｔａｔｅｍｅｎｔｓ：限定はしないが、ポリシー、サブスクリプション、信用（credentials）などを含む環境に関する特別な情報を持つＩｔｅｍ。
同様に、図８Ｂを参照すると、Ｃｏｒｅ Ｓｃｈｅｍａによってサポートされている特定のプロパティ型は以下のうちの１つまたは複数を含むことができる。
・ Ｃｅｒｔｉｆｉｃａｔｅｓ（Ｂａｓｅ Ｓｃｈｅｍａ内の基礎的なＰｒｏｐｅｒｔｙＢａｓｅ型から派生）
・ Ｐｒｉｎｃｉｐａｌ Ｉｄｅｎｔｉｔｙ Ｋｅｙｓ（Ｂａｓｅ Ｓｃｈｅｍａ内のＩｄｅｎｔｉｔｙＫｅｙ型から派生）
・ Ｐｏｓｔａｌ Ａｄｄｒｅｓｓ（Ｂａｓｅ Ｓｃｈｅｍａ内のＰｒｏｐｅｒｔｙ型から派生）
・ Ｒｉｃｈ Ｔｅｘｔ（Ｂａｓｅ Ｓｃｈｅｍａ内のＰｒｏｐｅｒｔｙ型から派生）
・ ＥＡｄｄｒｅｓｓ（Ｂａｓｅ Ｓｃｈｅｍａ内のＰｒｏｐｅｒｔｙ型から派生）
・ ＩｄｅｎｔｉｔｙＳｅｃｕｒｉｔｙＰａｃｋａｇｅ（Ｂａｓｅ Ｓｃｈｅｍａ内のＲｅｌａｔｉｏｎｓｈｉｐ型から派生）
・ ＲｏｌｅＯｃｃｕｐａｎｃｙ（Ｂａｓｅ Ｓｃｈｅｍａ内のＲｅｌａｔｉｏｎｓｈｉｐ型から派生）
・ ＢａｓｉｃＰｒｅｓｅｎｃｅ（Ｂａｓｅ Ｓｃｈｅｍａ内のＲｅｌａｔｉｏｎｓｈｉｐ型から派生）
これらのＩｔｅｍおよびＰｒｏｐｅｒｔｉｅｓは、さらに、図８Ａおよび図８Ｂで述べられているそれぞれのプロパティにより記述される。
５．関係
Ｒｅｌａｔｉｏｎｓｈｉｐｓは、一方のＩｔｅｍがソースとして指定され、他方のＩｔｅｍがターゲットとして指定されている２項関係である。ソースＩｔｅｍおよびターゲットＩｔｅｍは、この関係によって関連付けられる。ソースＩｔｅｍは、一般に、関係の存続期間を制御する。つまり、ソースＩｔｅｍが削除されるとそれらのＩｔｅｍ間の関係も削除されるということである。
Ｒｅｌａｔｉｏｎｓｈｉｐｓは、包含関係Ｃｏｎｔａｉｎｍｅｎｔと参照関係Ｒｅｆｅｒｅｎｃｅに分類される。包含関係は、ターゲットＩｔｅｍの存続期間を制御するが、参照関係は、存続期間管理の意味を持たない。図１２は、関係が分類される仕方を例示している。
Ｃｏｎｔａｉｎｍｅｎｔ関係型は、さらに、保持関係Ｈｏｌｄｉｎｇと埋め込み関係Ｅｍｂｅｄｄｉｎｇに分類される。Ｉｔｅｍに対するすべての保持関係が削除されると、そのＩｔｅｍも削除される。保持関係は、参照カウントメカニズムを使ってターゲットの存続期間を制御する。埋め込み関係を使用すると、複合Ｉｔｅｍのモデル化が可能になり、これは排他的保持関係と考えることができる。Ｉｔｅｍは、１つまたは複数の保持関係のターゲットとすることができるが、Ｉｔｅｍは、正確に１つの埋め込み関係のターゲットとすることができる。埋め込み関係のターゲットであるＩｔｅｍは、その他の保持または埋め込み関係のターゲットとすることはできない。
参照関係は、ターゲットＩｔｅｍの存続期間を制御しない。これらは、宙ぶらりんになっていることがある−ターゲットＩｔｅｍが存在しない場合がある。参照関係は、大域的Ｉｔｅｍ名前空間（つまり、リモートデータストアを含む）内のどこかにあるＩｔｅｍへの参照をモデル化するために使用できる。
Ｉｔｅｍをフェッチしても、その関係は自動的にフェッチされない。アプリケーション側で、Ｉｔｅｍの関係を明示的に要求しなければならない。さらに、関係を修正しても、ソースまたはターゲットＩｔｅｍは修正されず、同様に、関係を追加しても、ソース／ターゲットＩｔｅｍに影響は及ばない。
ａ）関係の宣言
明示的関係型は、以下の要素により定義される。
・ 関係名は、Ｎａｍｅ属性で指定される。
・ 関係型として、Ｈｏｌｄｉｎｇ、Ｅｍｂｅｄｄｉｎｇ、Ｒｅｆｅｒｅｎｃｅのうちの１つ。これは、Ｔｙｐｅ属性において指定される。
・ ソースおよびターゲット終点。それぞれの終点は、参照されているＩｔｅｍの名前および型を指定する。
・ ソース終点フィールドは、一般的に、ＩｔｅｍＩＤ型（宣言されない）であり、関係インスタンスと同じデータストア内のＩｔｅｍを参照しなければならない。
・ ＨｏｌｄｉｎｇおよびＥｍｂｅｄｄｉｎｇ関係については、ターゲット終点フィールドは、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅ型でなければならず、関係インスタンスと同じストア内のＩｔｅｍを参照しなければならない。Ｒｅｆｅｒｅｎｃｅ関係については、ターゲット終点は任意のＩｔｅｍＲｅｆｅｒｅｎｃｅ型でよく、その他のストレージプラットフォームのデータストア内のＩｔｅｍを参照することができる。
・ オプションにより、スカラーまたはＰｒｏｐｅｒｔｙＢａｓｅ型の１つまたは複数のフィールドを宣言することができる。これらのフィールドは、関係に関連付けられたデータを格納することができる。
・ 関係インスタンスは、大域的関係テーブル内に格納される。
・ すべての関係インスタンスは、組合せ（ソースＩｔｅｍＩＤ、関係ＩＤ）により一意に識別される。関係ＩＤは、その型に関係なく与えられたＩｔｅｍをソースとするすべての関係について、与えられたソースＩｔｅｍＩＤ内で一意である。
ソースＩｔｅｍは、関係の所有者である。所有者として指定されているＩｔｅｍは関係の存続期間を制御するが、関係自体はそれが関係するＩｔｅｍとは別である。ストレージプラットフォームＡＰＩ３２２は、Ｉｔｅｍと関連する関係を公開するメカニズムを提供する。
関係宣言の一実施例を以下に示す。
Figure 0004394644
これは、Ｒｅｆｅｒｅｎｃｅ関係の一実施例である。この関係は、ソース参照によって参照された人の（ｐｅｒｓｏｎ）Ｉｔｅｍが存在しない場合には作成することはできない。さらに、人の（ｐｅｒｓｏｎ）Ｉｔｅｍが削除された場合、人（ｐｅｒｓｏｎ）と組織（ｏｒｇａｎｉｚａｔｉｏｎ）との間の関係インスタンスが削除される。しかし、Ｏｒｇａｎｉｚａｔｉｏｎ Ｉｔｅｍが削除された場合、関係は削除されず、宙ぶらりんになる。
ｂ）保持（Ｈｏｌｄｉｎｇ）Ｒｅｌａｔｉｏｎｓｈｉｐ
保持関係は、ターゲットＩｔｅｍの参照カウントベースの存続期間管理をモデル化するために使用される。
Ｉｔｅｍは、Ｉｔｅｍとの０またはそれ以上の関係に対するソース終点とすることができる。埋め込まれたＩｔｅｍではないＩｔｅｍは、１つまたは複数の保持関係におけるターゲットとすることができる。
ターゲット終点参照型は、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅでなければならず、また関係インスタンスと同じストア内のＩｔｅｍを参照しなければならない。
保持関係は、ターゲット終点の存続期間管理を行う。保持関係インスタンスおよびそれがターゲットとしているＩｔｅｍの作成は、アトミックオペレーションである。同じＩｔｅｍをターゲットとしている追加保持関係インスタンスの作成が可能である。与えられたＩｔｅｍをターゲット終点として持つ最後の保持関係インスタンスが削除されると、ターゲットＩｔｅｍも削除される。
関係宣言内で指定される終点Ｉｔｅｍの型は、一般的に、関係のインスタンスが作成されるときに強制される。関係が確立された後では、終点Ｉｔｅｍの型は変更できない。
保持関係は、Ｉｔｅｍ名前空間を形成する際に重要な役割を果たす。これらは、ソースＩｔｅｍに相対的にターゲットＩｔｅｍの名前を定義する「Ｎａｍｅ」プロパティを含む。この相対名は、与えられたＩｔｅｍから生じるすべての保持関係について一意である。ルートＩｔｅｍから始まり与えられたＩｔｅｍに至るこの相対名の順序付けされたリストは、Ｉｔｅｍに対するフルネームを形成する。
保持関係は、非循環有向グラフ（ＤＡＧ）を形成する。保持関係が作成されると、システムは、サイクルが作成されないことを保証し、Ｉｔｅｍ名前空間がＤＡＧを必ず形成する。
保持関係はターゲットＩｔｅｍの存続期間を制御するが、ターゲット終点Ｉｔｅｍの動作の整合性を制御しない。ターゲットＩｔｅｍは、保持関係を通じてそれを所有するＩｔｅｍから、動作に関して独立している。保持関係のソースであるＩｔｅｍに対するＣｏｐｙ、Ｍｏｖｅ、Ｂａｃｋｕｐ、およびその他のオペレーションは、同じ関係のターゲットであるＩｔｅｍに影響を及ぼさない−例えば、つまり、Ｆｏｌｄｅｒ Ｉｔｅｍをバックアップしても、すべてのＩｔｅｍをフォルダ（ＦｏｌｄｅｒＭｅｍｂｅｒ関係のターゲット）内に自動的にバックアップするわけではない。
以下は、保持関係の一実施例である。
Figure 0004394644
ＦｏｌｄｅｒＭｅｍｂｅｒｓ関係は、Ｆｏｌｄｅｒの概念をＩｔｅｍのジェネリックコレクションとして使用可能にする。
ｃ）埋め込み（Ｅｍｂｅｄｄｉｎｇ）関係
埋め込み関係は、ターゲットＩｔｅｍの存続期間の排他的制御という概念をモデル化する。これらは、複合Ｉｔｅｍの概念を有効にする。
埋め込み関係インスタンスおよびそれがターゲットとしているＩｔｅｍの作成は、アトミックオペレーションである。Ｉｔｅｍは、０またはそれ以上の埋め込み関係のソースとすることができる。しかし、Ｉｔｅｍは、唯一の埋め込み関係のターゲットとすることができる。埋め込み関係のターゲットであるＩｔｅｍは、保持関係のターゲットとすることはできない。
ターゲット終点参照型は、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅでなければならず、また関係インスタンスと同じデータストア内のＩｔｅｍを参照しなければならない。
関係宣言内で指定される終点Ｉｔｅｍの型は、一般的に、関係のインスタンスが作成されるときに強制される。関係が確立された後では、終点Ｉｔｅｍの型は変更できない。
埋め込み関係は、ターゲット終点の動作の整合性を制御する。例えば、Ｉｔｅｍをシリアライズするオペレーションは、そのＩｔｅｍをソースとするすべての埋め込み関係だけでなく、そのターゲットのすべてのシリアライズをも含むことができ、Ｉｔｅｍをコピーすることで、そのすべての埋め込まれているＩｔｅｍもコピーされる。
以下は、宣言例である。
Figure 0004394644
ｄ）参照関係
参照関係は、参照するＩｔｅｍの存続期間を制御しない。さらには、参照関係は、ターゲットの存在を保証せず、また関係宣言内で指定された通りにターゲットの型を保証するわけでもない。これは、参照関係が宙ぶらりんになる可能性のあることを意味している。また、参照関係は、他のデータストア内のＩｔｅｍを参照することができる。参照関係は、Ｗｅｂページ内のリンクに類似の概念として考えることができる。
参照関係宣言の一例を以下に示す。
Figure 0004394644
参照型は、ターゲット終点において使用できる。参照関係に関わるＩｔｅｍは、任意のＩｔｅｍ型とすることができる。
参照関係は、Ｉｔｅｍ間のほとんどの非存続期間管理関係をモデル化するために使用される。ターゲットの存在は強制されないので、参照関係は、疎結合関係をモデル化するために都合がよい。参照関係は、他のコンピュータ上のストアを含む他のデータストア内のＩｔｅｍをターゲットとするために使用することができる。
ｅ）規則と制約条件
以下の追加規則および制約条件を関係について適用する。
１．Ｉｔｅｍは、（ちょうど１つの埋め込み関係）または（１つまたは複数の保持関係）のターゲットでなければならない。例外の１つは、ルートＩｔｅｍである。Ｉｔｅｍは、０またはそれ以上の参照関係のターゲットとすることができる。
２．埋め込み関係のターゲットであるＩｔｅｍは、保持関係のソースとすることはできない。これは、参照関係のソースとすることができる。
３．Ｉｔｅｍはファイルから格上げされた場合、保持関係のソースとすることはできない。これは、埋め込み関係および参照関係のソースとすることができる。
４．ファイルから格上げされたＩｔｅｍは、埋め込み関係のターゲットとすることはできない。
ｆ）関係の順序付け
少なくとも一実施形態では、本発明のストレージプラットフォームは、関係の順序付けをサポートする。順序付けは、基本関係定義の中で「Ｏｒｄｅｒ」という名前のプロパティを通じて実行される。Ｏｒｄｅｒフィールド上には一意性制約条件はない。同じ「順序」プロパティ値を持つ関係の順序は保証されないが、低い「順序」の値を持つ関係の後、および高い「順序」フィールド値を持つ関係の前に、順序付けできることが保証される。
アプリケーションは、組合せ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ、Ｏｒｄｅｒ）の順序付けによって既定の順序で関係を取得することができる。与えられたＩｔｅｍをソースとするすべての関係インスタンスは、単一のコレクションとして、そのコレクション内の関係の型と関係なく、順序付けされる。しかし、これは、与えられた型（例えば、ＦｏｌｄｅｒＭｅｍｂｅｒｓ）のすべての関係が、与えられたＩｔｅｍに対する関係コレクションの順序付き部分集合であることを保証する。
関係を操作するデータストアＡＰＩ３１２は、関係の順序付けをサポートするオペレーションの集合を実装している。以下の用語は、オペレーションを説明する補助として導入される。
ＲｅｌＦｉｒｓｔは、順序値ＯｒｄＦｉｒｓｔを持つ順序付きコレクション内の最初の関係である。
ＲｅｌＬａｓｔは、順序値ＯｒｄＬａｓｔを持つ順序付きコレクション内の最後の関係である。
ＲｅｌＸは、順序値ＯｒｄＸを持つコレクション内の与えられた関係である。
ＲｅｌＰｒｅｖは、順序値ＯｒｄＰｒｅｖがＯｒｄＸよりも小さい、コレクション内のＲｅｌＸとの最も近い関係である。
ＲｅｌＮｅｘｔは、順序値ＯｒｄＮｅｘｔがＯｒｄＸよりも大きい、コレクション内のＲｅｌＸとの最も近い関係である。
InsertBeforeFirst (SourceItemID, Relationship)
関係を第１の関係としてコレクション内に挿入する。新しい関係の「Ｏｒｄｅｒ」プロパティの値はＯｒｄＦｉｒｓｔよりも小さい場合がある。
InsertAfterLast (SourceItemID, Relationship)
関係を最後の関係としてコレクション内に挿入する。新しい関係の「Ｏｒｄｅｒ」プロパティの値はＯｒｄＬａｓｔよりも大きい場合がある。
InsertAt (SourceItemID, ord, Relationship)
「Ｏｒｄｅｒ」プロパティに対する指定された値を持つ関係を挿入する。
InsertBefore (SourceItemID, ord, Relationship)
与えられた順序値を持つ関係の前に関係を挿入する。新しい関係には、ＯｒｄＰｒｅｖとｏｒｄの間の、しかもそれを含まない、「Ｏｒｄｅｒ」値を割り当てることができる。
InsertAfter (SourceItemID, ord, Relationship)
与えられた順序値を持つ関係の後に関係を挿入する。新しい関係には、ｏｒｄとＯｒｄＮｅｘｔの間の、しかもそれを含まない、「Ｏｒｄｅｒ」値を割り当てることができる。
MoveBefore (SourceItemID, ord, RelationshipID)
与えられた関係ＩＤを持つ関係を指定された「Ｏｒｄｅｒ」値を持つ関係の前に移動する。この関係には、ＯｒｄＰｒｅｖとｏｒｄの間の、しかもそれを含まない、新しい「Ｏｒｄｅｒ」値を割り当てることができる。
MoveAfter (SourceItemID, ord, RelationshipID)
与えられた関係ＩＤを持つ関係を指定された「Ｏｒｄｅｒ」値を持つ関係の後に移動する。この関係には、ｏｒｄとＯｒｄＮｅｘｔの間の、しかもそれを含まない、新しい順序値を割り当てることができる。
すでに述べたように、すべてのＩｔｅｍはＩｔｅｍ Ｆｏｌｄｅｒのメンバでなければならない。Ｒｅｌａｔｉｏｎｓｈｉｐｓに関して、すべてのＩｔｅｍはＩｔｅｍ Ｆｏｌｄｅｒと関係を持っていなければならない。本発明のいくつかの実施形態では、Ｉｔｅｍ間に存在するＲｅｌａｔｉｏｎｓｈｉｐｓにより特定の関係が表される。
本発明の様々な実施形態で実装されているように、Ｒｅｌａｔｉｏｎｓｈｉｐは一方のＩｔｅｍ（ソース）により他方のＩｔｅｍ（ターゲット）に「拡張」される有向２項関係を実現する。Ｒｅｌａｔｉｏｎｓｈｉｐは、ソースＩｔｅｍ（それを拡張したＩｔｅｍ）により所有され、したがってＲｅｌａｔｉｏｎｓｈｉｐは、ソースが削除されると削除される（例えば、Ｒｅｌａｔｉｏｎｓｈｉｐは、ソースＩｔｅｍが削除されると削除される）。さらに、いくつかのインスタンスでは、Ｒｅｌａｔｉｏｎｓｈｉｐは、ターゲットＩｔｅｍの所有権を共有（共同所有）することができ、そのような所有権は、ＲｅｌａｔｉｏｎｓｈｉｐのＩｓＯｗｎｅｄプロパティ（またはその等価物）内に反映されることが可能である（図７に、Ｒｅｌａｔｉｏｎｓｈｉｐプロパティ型について示されているように）。これらの実施形態では、新しいＩｓＯｗｎｅｄ Ｒｅｌａｔｉｏｎｓｈｉｐを作成すると、自動的にターゲットＩｔｅｍの参照カウントがインクリメントされ、そのようなＲｅｌａｔｉｏｎｓｈｉｐを削除すると、ターゲットＩｔｅｍの参照カウントがデクリメントされる。これらの特定の実施形態では、Ｉｔｅｍは、参照カウントが０よりも大きければ存在し続け、カウントが０になった場合に自動的に削除される。ここでもまた、Ｉｔｅｍ Ｆｏｌｄｅｒは、他のＩｔｅｍとのＲｅｌａｔｉｏｎｓｈｉｐｓの集合を持つ（または持つことができる）Ｉｔｅｍであり、それらの他のＩｔｅｍは、Ｉｔｅｍ Ｆｏｌｄｅｒの帰属関係を含む。Ｒｅｌａｔｉｏｎｓｈｉｐｓの他の実際の実装も可能であり、本発明により本明細書で説明されている機能を実現することが予想される。
実際の実装に関係なく、Ｒｅｌａｔｉｏｎｓｈｉｐは、一方のオブジェクトから他方のオブジェクトへの選択可能な接続である。Ｉｔｅｍが複数のＩｔｅｍ Ｆｏｌｄｅｒに属すことができることとともに、１つまたは複数のＣａｔｅｇｏｒｉｅｓに属すことができること、さらに、これらのＩｔｅｍ、Ｆｏｌｄｅｒｓ、およびＣａｔｅｇｏｒｉｅｓがパブリックであるかプライベートであるかは、Ｉｔｅｍベースの構造内で存在すること（または存在しないこと）に対し与えられた意味により決定される。これらの論理的Ｒｅｌａｔｉｏｎｓｈｉｐｓは、本明細書で説明されている機能を実現するために特に採用されている、物理的実装に関係ない、Ｒｅｌａｔｉｏｎｓｈｉｐｓの集合に割り当てられた意味である。論理的Ｒｅｌａｔｉｏｎｓｈｉｐｓは、ＩｔｅｍとそのＩｔｅｍ Ｆｏｌｄｅｒ（ｓ）またはＣａｔｅｇｏｒｉｅｓとの間で確立されている（およびその逆に）が、それは、本質的にＩｔｅｍ ＦｏｌｄｅｒｓおよびＣａｔｅｇｏｒｉｅｓはそれぞれＩｔｅｍの特殊な型であるからである。したがって、Ｉｔｅｍ ＦｏｌｄｅｒｓおよびＣａｔｅｇｏｒｉｅｓは、他のＩｔｅｍと同じようにして作用−限定はしないが、コピー、電子メールメッセージへの追加、ドキュメントへの埋め込み、など−を受けることができ、Ｉｔｅｍ ＦｏｌｄｅｒｓおよびＣａｔｅｇｏｒｉｅｓに対して、他のＩｔｅｍの場合と同じメカニズムを使用してシリアライズおよびデシリアライズ（インポートおよびエクスポート）を行うことができる。（例えば、ＸＭＬでは、すべてのＩｔｅｍは、シリアライズ形式を持つことができ、この形式はＩｔｅｍ Ｆｏｌｄｅｒｓ、Ｃａｔｅｇｏｒｉｅｓ、およびＩｔｅｍにも等しく適用される。）
前述のＲｅｌａｔｉｏｎｓｈｉｐｓは、ＩｔｅｍとそれのＩｔｅｍ Ｆｏｌｄｅｒ（ｓ）と間の関係を表すが、ＩｔｅｍからＩｔｅｍ Ｆｏｌｄｅｒに、Ｉｔｅｍ ＦｏｌｄｅｒからＩｔｅｍに、またはその両方に論理的に拡張することができる。論理的にＩｔｅｍからＩｔｅｍ Ｆｏｌｄｅｒに拡張するＲｅｌａｔｉｏｎｓｈｉｐは、Ｉｔｅｍ ＦｏｌｄｅｒがそのＩｔｅｍに対しパブリックであることを表し、そのＩｔｅｍとの帰属関係情報を共有するが、逆に、ＩｔｅｍからＩｔｅｍ Ｆｏｌｄｅｒへの論理的Ｒｅｌａｔｉｏｎｓｈｉｐが存在しないことは、Ｉｔｅｍ ＦｏｌｄｅｒがそのＩｔｅｍに対しプライベートであり、そのＩｔｅｍとの帰属関係情報を共有しないことを表す。同様に、Ｉｔｅｍ ＦｏｌｄｅｒからＩｔｅｍに論理的に拡張するＲｅｌａｔｉｏｎｓｈｉｐは、ＩｔｅｍがそのＩｔｅｍ Ｆｏｌｄｅｒに対しパブリックであり共有可能であることを表すが、Ｉｔｅｍ ＦｏｌｄｅｒからＩｔｅｍへの論理的Ｒｅｌａｔｉｏｎｓｈｉｐが存在しないことは、Ｉｔｅｍがプライベートであり、非共有可能であることを表す。したがって、Ｉｔｅｍ Ｆｏｌｄｅｒは、他のシステムにエクスポートされる場合、新しい文脈で共有される「パブリック」Ｉｔｅｍであり、ＩｔｅｍがそのＩｔｅｍ Ｆｏｌｄｅｒｓ内で他の共有可能なＩｔｅｍを検索する場合、それは属する共有可能Ｉｔｅｍに関する情報をＩｔｅｍに供給する「パブリック」Ｉｔｅｍ Ｆｏｌｄｅｒｓである。
図９は、Ｉｔｅｍ Ｆｏｌｄｅｒ（これもまた、Ｉｔｅｍ自体である）、そのメンバＩｔｅｍ、およびＩｔｅｍ ＦｏｌｄｅｒとそのメンバＩｔｅｍとの間の相互接続Ｒｅｌａｔｉｏｎｓｈｉｐｓを例示するブロック図である。Ｉｔｅｍ Ｆｏｌｄｅｒ ９００は、複数のＩｔｅｍ ９０２、９０４、および９０６をメンバとして持つ。Ｉｔｅｍ Ｆｏｌｄｅｒ ９００は、Ｉｔｅｍ ９０２がパブリックでありＩｔｅｍ Ｆｏｌｄｅｒ ９００、そのメンバ９０４および９０６、およびＩｔｅｍ Ｆｏｌｄｅｒ ９００にアクセスする可能性のある他のＩｔｅｍ Ｆｏｌｄｅｒｓ、Ｃａｔｅｇｏｒｉｅｓ、またはＩｔｅｍ（図に示されていない）に対し共有可能であることを表す、それ自体からＩｔｅｍ ９０２へのＲｅｌａｔｉｏｎｓｈｉｐ ９１２を持つ。しかし、Ｉｔｅｍ Ｆｏｌｄｅｒ ９００がＩｔｅｍ ９０２に対しプライベートであり、Ｉｔｅｍ ９０２と帰属関係情報を共有しないことを表す、Ｉｔｅｍ ９０２からＩｔｅｍ Ｆｏｌｄｅｒ ９００へのＲｅｌａｔｉｏｎｓｈｉｐはない。他方、Ｉｔｅｍ ９０４は、Ｉｔｅｍ Ｆｏｌｄｅｒ ９００がパブリックであり、Ｉｔｅｍ ９０４と帰属関係情報を共有することを表す、それ自体からＩｔｅｍ Ｆｏｌｄｅｒ ９００へのＲｅｌａｔｉｏｎｓｈｉｐ ９２４を持つ。しかし、Ｉｔｅｍ ９０４がプライベートであり、Ｉｔｅｍ Ｆｏｌｄｅｒ ９００、それの他のメンバ９０２および９０６、およびＩｔｅｍ Ｆｏｌｄｅｒ ９００にアクセスする可能性のある他のＩｔｅｍ Ｆｏｌｄｅｒｓ、Ｃａｔｅｇｏｒｉｅｓ、またはＩｔｅｍ（図に示されていない）に対し共有可能でないことを表す、Ｉｔｅｍ Ｆｏｌｄｅｒ ９００からＩｔｅｍ ９０４へのＲｅｌａｔｉｏｎｓｈｉｐはない。Ｉｔｅｍ ９０２および９０４に対するそのＲｅｌａｔｉｏｎｓｈｉｐｓ（またはそれが存在しないこと）とは対照的に、Ｉｔｅｍ Ｆｏｌｄｅｒ ９００はそれ自体からＩｔｅｍ ９０６へのＲｅｌａｔｉｏｎｓｈｉｐ ９１６を持ち、Ｉｔｅｍ ９０６はＩｔｅｍ Ｆｏｌｄｅｒ ９００に戻るＲｅｌａｔｉｏｎｓｈｉｐ ９２６を持ち、これらは併せて、Ｉｔｅｍ ９０６がパブリックであり、Ｉｔｅｍ Ｆｏｌｄｅｒ ９００、それのメンバ９０２および９０４、およびＩｔｅｍ Ｆｏｌｄｅｒ ９００にアクセスする可能性のある他のＩｔｅｍ Ｆｏｌｄｅｒｓ、Ｃａｔｅｇｏｒｉｅｓ、またはＩｔｅｍ（図に示されていない）に対し共有可能であること、およびＩｔｅｍ Ｆｏｌｄｅｒ ９００がパブリックであり、Ｉｔｅｍ ９０６と帰属関係情報を共有することを表す。
すでに説明したように、Ｉｔｅｍ Ｆｏｌｄｅｒ内のＩｔｅｍは、Ｉｔｅｍ Ｆｏｌｄｅｒｓが「記述」されていないため共通性を共有する必要はない。他方、Ｃａｔｅｇｏｒｉｅｓは、そのメンバＩｔｅｍのすべてに共通である共通性により記述される。したがって、Ｃａｔｅｇｏｒｙの帰属関係は、本質的に、記述されている共通性を持つＩｔｅｍに制限され、いくつかの実施形態では、Ｃａｔｅｇｏｒｙの記述を満たすすべてのＩｔｅｍは自動的にＣａｔｅｇｏｒｙのメンバにされる。したがって、Ｉｔｅｍ Ｆｏｌｄｅｒｓでは自明な型構造をその帰属関係により表すことができるが、Ｃａｔｅｇｏｒｉｅｓでは、帰属関係は定義済み共通性に基づくようにできる。
もちろん、Ｃａｔｅｇｏｒｙ記述は、その性質上論理的であり、したがって、Ｃａｔｅｇｏｒｙは、型、プロパティ、および／または値の論理表現により記述することができる。例えば、Ｃａｔｅｇｏｒｙの論理表現は、Ｉｔｅｍを含む帰属関係が２つのプロパティのうちの一方または両方を持つものとすることができる。Ｃａｔｅｇｏｒｙに対するこれらの記述されたプロパティが「Ａ」および「Ｂ」の場合、Ｃａｔｅｇｏｒｉｅｓ帰属関係は、プロパティＡを持つがＢを持たないＩｔｅｍ、プロパティＢを持つがＡを持たないＩｔｅｍ、およびプロパティＡおよびＢの両方を持つＩｔｅｍを含むことができる。プロパティのこの論理表現は、論理演算子「ＯＲ」により記述され、Ｃａｔｅｇｏｒｙにより記述されるメンバの集合はプロパティＡ ＯＲ Ｂを持つＩｔｅｍとなる。類似の論理オペランド（限定はしないが、「ＡＮＤ」、「ＸＯＲ」、および「ＮＯＴ」を単独で、または組み合わせて含む）も、カテゴリを記述するために使用することができることは、当業者であれば理解するであろう。
Ｉｔｅｍ Ｆｏｌｄｅｒｓ（記述されていない）とＣａｔｅｇｏｒｉｅｓ（記述されている）との区別にもかかわらず、Ｃａｔｅｇｏｒｉｅｓ Ｒｅｌａｔｉｏｎｓｈｉｐ対ＩｔｅｍとＩｔｅｍ Ｒｅｌａｔｉｏｎｓｈｉｐ対Ｃａｔｅｇｏｒｉｅｓは、本発明の多くの実施形態におけるＩｔｅｍ ＦｏｌｄｅｒｓおよびＩｔｅｍについて本明細書でこれまでに開示されたものと本質的に同じものである。
図１０は、Ｃａｔｅｇｏｒｙ（ここでも、Ｉｔｅｍ自体である）、そのメンバＩｔｅｍ、およびＣａｔｅｇｏｒｙとそのメンバＩｔｅｍとの間の相互接続のＲｅｌａｔｉｏｎｓｈｉｐｓを例示するブロック図である。Ｃａｔｅｇｏｒｙ １０００は、複数のＩｔｅｍ １００２、１００４、および１００６をメンバとして持ち、それらはすべて、Ｃａｔｅｇｏｒｙ １０００により記述されているように（共通性記述１００８’）共通のプロパティ、値、または型１００８の何らかの組合せを共有する。Ｃａｔｅｇｏｒｙ １０００は、Ｉｔｅｍ １００２がパブリックであり、Ｃａｔｅｇｏｒｙ １０００、そのメンバ１００４および１００６、およびＣａｔｅｇｏｒｙ １０００にアクセスする可能性のある他のＣａｔｅｇｏｒｉｅｓ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、またはＩｔｅｍ（図に示されていない）に対し共有可能であることを表す、それ自体からＩｔｅｍ １００２へのＲｅｌａｔｉｏｎｓｈｉｐ １０１２を持つ。しかし、Ｃａｔｅｇｏｒｙ １０００がＩｔｅｍ １００２に対しプライベートであり、Ｉｔｅｍ １００２と帰属関係情報を共有しないことを表す、Ｉｔｅｍ １００２からＣａｔｅｇｏｒｙ １０００へのＲｅｌａｔｉｏｎｓｈｉｐはない。他方、Ｉｔｅｍ １００４は、Ｃａｔｅｇｏｒｙ １０００がパブリックであり、Ｉｔｅｍ １００４と帰属関係情報を共有することを表す、それ自体からＣａｔｅｇｏｒｙ １０００へのＲｅｌａｔｉｏｎｓｈｉｐ １０２４を持つ。しかし、Ｉｔｅｍ １００４がプライベートであり、Ｃａｔｅｇｏｒｙ １０００、それの他のメンバ１００２および１００６、およびＣａｔｅｇｏｒｙ １０００にアクセスする可能性のある他のＣａｔｅｇｏｒｉｅｓ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、またはＩｔｅｍ（図に示されていない）に対し共有可能でないことを表す、Ｃａｔｅｇｏｒｙ １０００からＩｔｅｍ １００４へのＲｅｌａｔｉｏｎｓｈｉｐはない。Ｉｔｅｍ １００２および１００４に対するそのＲｅｌａｔｉｏｎｓｈｉｐｓ（またはそれが存在しないこと）とは対照的に、Ｃａｔｅｇｏｒｙ １０００はそれ自体からＩｔｅｍ １００６へのＲｅｌａｔｉｏｎｓｈｉｐ １０１６を持ち、Ｉｔｅｍ １００６はＣａｔｅｇｏｒｙ １０００に戻るＲｅｌａｔｉｏｎｓｈｉｐ １０２６を持ち、これらは併せて、Ｉｔｅｍ １００６がパブリックであり、Ｃａｔｅｇｏｒｙ １０００、それのＩｔｅｍメンバ１００２および１００４、およびＣａｔｅｇｏｒｙ １０００にアクセスする可能性のある他のＣａｔｅｇｏｒｉｅｓ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、またはＩｔｅｍ（図に示されていない）に対し共有可能であること、およびＣａｔｅｇｏｒｙ １０００がパブリックであり、Ｉｔｅｍ １００６と帰属関係情報を共有することを表す。
最後に、他のいくつかの実施形態では、ＣａｔｅｇｏｒｉｅｓおよびＩｔｅｍ Ｆｏｌｄｅｒｓは、それ自体Ｉｔｅｍであるので、Ｉｔｅｍは互いとのＲｅｌａｔｉｏｎｓｈｉｐを、ＣａｔｅｇｏｒｉｅｓはＩｔｅｍ ＦｏｌｄｅｒｓへのＲｅｌａｔｉｏｎｓｈｉｐ およびその逆を持ち、Ｃａｔｅｇｏｒｉｅｓ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、およびＩｔｅｍはそれぞれ他のＣａｔｅｇｏｒｉｅｓ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、およびＩｔｅｍに対するＲｅｌａｔｉｏｎｓｈｉｐを持つことができる。しかし、様々な実施形態では、Ｉｔｅｍ Ｆｏｌｄｅｒ構造および／またはＣａｔｅｇｏｒｙ構造は、ハードウェア／ソフトウェアインターフェースシステムレベルでサイクルを含むことが禁止されている。Ｉｔｅｍ ＦｏｌｄｅｒおよびＣａｔｅｇｏｒｙ構造は、有効グラフに似ており、サイクルを禁止する実施形態は、グラフ理論の分野の数学的定義により、どのような経路も同じ頂点から始まり、終わるということのない有向グラフである、非循環有向グラフ（ＤＡＧｓ）に似ている。
６．拡張性
ストレージプラットフォームに対して、上述のように、スキーマの初期集合（プラットフォームスキーマ）３４０を与えることが意図されている。しかし、それに加えて、少なくともいくつかの実施形態では、ストレージプラットフォームにより、独立系ソフトウェアベンダ（ＩＳＶ）を含む顧客は、新しいスキーマ３４４（つまり、新しいＩｔｅｍおよびＮｅｓｔｅｄ Ｅｌｅｍｅｎｔ型）を作成することができる。この節では、スキーマの初期集合（プラットフォームスキーマ）３４０内で定義されているＩｔｅｍ型およびＮｅｓｔｅｄ Ｅｌｅｍｅｎｔ型（または単純に、「Ｅｌｅｍｅｎｔ」型）を拡張することによりそのようなスキーマを作成するためのメカニズムを取りあげる。
ＩｔｅｍおよびＮｅｓｔｅｄ Ｅｌｅｍｅｎｔ型の初期集合の拡張は、以下のように制約されるのが好ましい。
ＩＳＶは新しいＩｔｅｍ型、つまり、子型Ｂａｓｅ．Ｉｔｅｍを導入することが許される。
ＩＳＶは新しいＮｅｓｔｅｄ Ｅｌｅｍｅｎｔ型、つまり、子型Ｂａｓｅ．ＮｅｓｔｅｄＥｌｅｍｅｎｔを導入することが許される。
ＩＳＶは新しい拡張、つまり、子型Ｂａｓｅ．ＮｅｓｔｅｄＥｌｅｍｅｎｔを導入することが許される。しかし、
ＩＳＶは、ストレージプラットフォームのスキーマの初期集合（プラットフォームスキーマ）３４０により定義されている型（Ｉｔｅｍ、Ｎｅｓｔｅｄ Ｅｌｅｍｅｎｔ、またはＥｘｔｅｎｓｉｏｎ型）をサブタイプ化することはできない。
ストレージプラットフォームスキーマの初期集合により定義されているＩｔｅｍ型またはＮｅｓｔｅｄ Ｅｌｅｍｅｎｔ型は、ＩＳＶアプリケーションの要求条件に正確に一致しない場合があるので、ＩＳＶ側で型をカスタマイズできるようにする必要がある。これは、Ｅｘｔｅｎｓｉｏｎｓという概念で可能になる。Ｅｘｔｅｎｓｉｏｎｓは、強く型付けされたインスタンスであるが、（ａ）それらは独立して存在することはできず、（ｂ）ＩｔｅｍまたはＮｅｓｔｅｄ Ｅｌｅｍｅｎｔに付随しなければならない。
スキーマの拡張性の必要性に応える他に、Ｅｘｔｅｎｓｉｏｎｓは、「多重型付け」問題を解消することも意図されている。いくつかの実施形態では、ストレージプラットフォームは、多重継承または重複子型をサポートしていない場合があるため、アプリケーション側でＥｘｔｅｎｓｉｏｎｓを重複型のインスタンスをモデル化する一手段として使用することができる（例えば、Ｄｏｃｕｍｅｎｔは、法律文書であるとともにセキュリティに関する文書でもある）。
ａ）アイテム拡張
Ｉｔｅｍ拡張を行うために、データモデルは、さらに、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎという名前の抽象型を定義する。これは、拡張型の階層に対するルート型である。アプリケーションでは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎをサブタイプ化して、特定の拡張型を作成することができる。
Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎ型は、以下のようにＢａｓｅ ｓｃｈｅｍａで定義される。
Figure 0004394644
ＩｔｅｍＩＤフィールドは、拡張子が関連付けられているアイテムのＩｔｅｍＩＤを含む。このＩｔｅｍＩＤを持つＩｔｅｍは存在していなければならない。拡張は、与えられたＩｔｅｍＩＤを持つアイテムが存在しない場合には、作成することができない。Ｉｔｅｍが削除されると、同じＩｔｅｍＩＤを持つ拡張はすべて削除される。タプル（ＩｔｅｍＩＤ，ＥｘｔｅｎｓｉｏｎＩＤ）は拡張インスタンスを一意に識別する。
拡張型の構造は、アイテム型の構造と類似している。
拡張型はフィールドを持つ。
フィールドは、プリミティブまたはネスト要素型とすることができる。
拡張型は、サブタイプ化することができる。
以下の制約が、拡張型に対し適用される。
拡張は、関係のソースおよびターゲットとすることはできない。
拡張型インスタンスは、アイテムから独立しては存在し得ない。
拡張型は、ストレージプラットフォームの型定義でのフィールド型として使用することはできない。
与えられたＩｔｅｍ型に関連付けられる拡張の型には制約はない。どのような拡張型も、アイテム型の拡張に使用することができる。複数の拡張インスタンスがアイテムに付随する場合、それらは、構造とビヘイビアの両面で互いに独立している。
複数の拡張インスタンスは、格納され、アイテムから別々にアクセスされる。すべての拡張型インスタンスは大域的拡張ビューからアクセス可能である。関連するアイテムの型がどうであれ、与えられた拡張の型のすべてのインスタンスを返す効率的なクエリを作成することができる。ストレージプラットフォームＡＰＩは、アイテム上の拡張の格納、取り出し、および修正を行うことができるプログラミングモデルを提供する。
拡張型は、ストレージプラットフォームの単一継承モデルを使用してサブタイプ化された型とすることができる。拡張型からの派生は、新しい拡張型を生み出す。拡張の構造またはビヘイビアは、アイテム型階層の構造またはビヘイビアをオーバーライドまたは置き換えることができない。
Ｉｔｅｍ型と同様に、Ｅｘｔｅｎｓｉｏｎ型インスタンスは、拡張型に関連付けられているビューを通じて直接アクセスされることが可能である。拡張のＩｔｅｍＩＤは、どのアイテムに属しているかを示し、これを使用して、大域的Ｉｔｅｍビューから対応するＩｔｅｍオブジェクトを取り出すことができる。
拡張は、動作の整合性のためにアイテムの一部と考えられる。ストレージプラットフォームが定義するＣｏｐｙ／Ｍｏｖｅ、Ｂａｃｋｕｐ／Ｒｅｓｔｏｒｅ、およびその他の共通オペレーションは、そのアイテムの一部として拡張上で動作することができる。
以下の例を考察する。Ｃｏｎｔａｃｔ型は、Ｗｉｎｄｏｗｓ（登録商標）Ｔｙｐｅ設定において定義される。
Figure 0004394644
ＣＲＭアプリケーション開発者は、ＣＲＭアプリケーション拡張をストレージプラットフォームに格納されている連絡先に付随させたい。アプリケーション開発者は、アプリケーション側で操作することができる追加データ構造を含むＣＲＭ拡張を定義する。
Figure 0004394644
ＨＲアプリケーション開発者は、Ｃｏｎｔａｃｔに追加データを付随させたいとも考えている。このデータは、ＣＲＭアプリケーションデータと無関係である。ここでもまた、このアプリケーション開発者は拡張を作成することができる。
Figure 0004394644
ＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは、Ｃｏｎｔａｃｔアイテムに付随させることができる２つの独立の拡張である。これらは、互いに独立に作成されアクセスされる。
上記の例では、ＣＲＭＥｘｔｅｎｓｉｏｎ型のフィールドおよびメソッドは、Ｃｏｎｔａｃｔ階層のフィールドまたはメソッドをオーバーライドすることができない。ＣＲＭＥｘｔｅｎｓｉｏｎ型のインスタンスは、Ｃｏｎｔａｃｔ以外のＩｔｅｍ型に付随させることができる。
Ｃｏｎｔａｃｔアイテムが取り出される場合、そのアイテム拡張は自動的に取り出されはしない。Ｃｏｎｔａｃｔアイテムが与えられた場合、関連するアイテム拡張は、同じＩｔｅｍＩｄで拡張の大域的拡張ビューにクエリを実行することによりアクセスすることが可能である。
システム内のすべてのＣＲＭＥｘｔｅｎｓｉｏｎ拡張は、どのアイテムに属しているか関係なく、ＣＲＭＥｘｔｅｎｓｉｏｎ型ビューを通じてアクセスすることができる。アイテムのすべてのアイテム拡張は、同じアイテムｉｄを共有する。上記の例では、Ｃｏｎｔａｃｔアイテムインスタンスおよび付随するＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは同じＩｔｅｍＩＤをインスタンス化する。
以下のテーブルは、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＮｅｓｔｅｄＥｌｅｍｅｎｔ型の間の類似点と相違点をまとめたものである。
Figure 0004394644
ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔ型の拡張
ＮｅｓｔｅｄＥｌｅｍｅｎｔ型は、Ｉｔｅｍ型と同じメカニズムで拡張されない。ネストされた要素の拡張は、ネストされた要素型のフィールドと同じメカニズムにより格納され、アクセスされる。
データモデルは、Ｅｌｅｍｅｎｔという名前のネストされた要素型のルートを定義する。
Figure 0004394644
ＮｅｓｔｅｄＥｌｅｍｅｎｔ型はこの型から継承する。ＮｅｓｔｅｄＥｌｅｍｅｎｔ要素型は、さらに、Ｅｌｅｍｅｎｔｓの多重集合であるフィールドを定義する。
Figure 0004394644
ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張は、以下の点でアイテム拡張と異なる。
ネストされた要素拡張は、拡張型ではない。それらは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎ型をルートとする拡張型階層に属さない。
ネストされた要素拡張は、アイテムの他のフィールドとともに格納され、大域的にはアクセス可能でない−与えられた拡張型のすべてのインスタンスを取り出すクエリを作成できない。
これらの拡張は、他の（アイテムの）ネストされた要素が格納されるのと同じ方法で格納される。他のネストされた集合のように、ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張はＵＤＴに格納される。これらは、ネストされた要素型のＥｘｔｅｎｓｉｏｎｓフィールドを通じてアクセス可能である。
多値（multi-valued）プロパティにアクセスするために使用されるコレクションインターフェースも、型拡張の集合についてアクセスおよび反復するために使用される。
以下の表は、Ｉｔｅｍ ＥｘｔｅｎｓｉｏｎｓおよびＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張のまとめと比較である。
Figure 0004394644
Ｄ．データベースエンジン
上述のように、データストアは、データベースエンジン上に実装される。本発明では、データベースエンジンは、オブジェクトリレーショナル拡張とともに、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒなどの、ＳＱＬクエリ言語を実装するリレーショナルデータベースエンジンを含む。この節では、データストアが実装するデータモデルのリレーショナルストアへのマッピングについて説明し、また本発明によるストレージプラットフォームクライアントによって使われる論理ＡＰＩに関する情報も掲載する。しかし、異なるデータベースエンジンが使用される場合に、異なるマッピングを採用できることは理解されるであろう。実際、ストレージプラットフォームの概念データモデルをリレーショナルデータベースエンジン上に実装することに加えて、さらに、他のタイプのデータベース、例えば、オブジェクト指向およびＸＭＬデータベース上に実装されることも可能である。
オブジェクト指向（ＯＯ）データベースシステムは、プログラミング言語オブジェクト（例えば、Ｃ＋＋、Ｊａｖａ（登録商標））に対する永続性およびトランザクションを提供する。ストレージプラットフォームにおける「アイテム」の概念は、オブジェクト指向システムにおける「Ｏｂｊｅｃｔ」にうまくマッピングされるが、ただし、埋め込まれたコレクションはＯｂｊｅｃｔに追加されなければならないであろう。継承およびネストされた要素型のような他のストレージプラットフォームの型概念も、オブジェクト指向型システムをマッピングする。オブジェクト指向システムでは、通常、オブジェクト識別をすでにサポートしており、したがって、アイテム識別は、オブジェクト識別にマッピングすることができる。アイテムビヘイビア（オペレーション）は、オブジェクトメソッドにうまくマッピングされる。しかし、オブジェクト指向システムは、通常、編成に関する機能を欠いており、検索能力が劣る。また、オブジェクト指向システムは、非構造化および半構造化データのサポートも行わない。本明細書で説明されている完全なストレージプラットフォームデータモデルをサポートするため、関係、フォルダ、および拡張などの概念は、オブジェクトデータモデルに追加される必要があるであろう。さらに、格上げ（promotions）、同期、通知、およびセキュリティなどのメカニズムも、実装される必要があるであろう。
オブジェクト指向システムと同様に、ＸＭＬデータベースは、ＸＳＤ（ＸＭＬスキーマ定義）に基づいており、単一継承ベースの型システムをサポートする。本発明のアイテム型システムは、ＸＳＤ型モデルにマッピングされることも可能である。また、ＸＳＤは、ビヘイビアをサポートしない。アイテムに対するＸＳＤは、アイテムビヘイビアにより増強されなければならないであろう。ＸＭＬデータベースでは、単一のＸＳＤドキュメントを取り扱い、編成および広範な検索機能を欠いている。オブジェクト指向データベースの場合と同様、本明細書で説明されているデータモデルをサポートするため、関係、およびフォルダなどの他の概念は、そのようなＸＭＬデータベースに組み込まれる必要があり、また、同期、通知、およびセキュリティなどのメカニズムも実装される必要がある。
１．ＵＤＴを使用したデータストアの実装
本発明の実施形態では、一実施形態においてＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンを含むリレーショナルデータベースエンジン３１４は、組み込みスカラー型をサポートする。組み込みスカラー型は「ネイティブ」と「単純（simple）」である。それらは、ユーザが独自の型を定義することはできないという点でネイティブであり、複合構造をカプセル化できないという点で単純である。ユーザ定義型（User-defined types）（これ以降、ＵＤＴ）は、複合構造型を定義することによりユーザが型システムを拡張できるようにすることによりネイティブのスカラー型システムの上の、またそれを超える、型拡張性のためのメカニズムを提供する。ＵＤＴは、ユーザにより定義された後、型システムにおいて組み込みスカラー型が使用できる場所であればどこででも使用することができる。
本発明の一態様によれば、ストレージプラットフォームスキーマは、データベースエンジンストア内のＵＤＴクラスにマッピングされる。データストアＩｔｅｍは、Ｂａｓｅ．Ｉｔｅｍ型から派生するＵＤＴクラスにマッピングされる。Ｉｔｅｍのように、ＥｘｔｅｎｓｉｏｎｓもＵＤＴクラスにマッピングされ、継承を使用する。ルートＥｘｔｅｎｓｉｏｎ型は、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎであり、そこからすべてのＥｘｔｅｎｓｉｏｎ型が派生する。
ＵＤＴはＣＬＲクラスである−これは状態（つまり、データフィールド）とビヘイビア（つまり、ルーチン）を持つ。ＵＤＴは、マネージド言語−Ｃ＃、ＶＢ．ＮＥＴなどを使用して定義される。ＵＤＴメソッドおよび演算子は、その型のインスタンスに対してＴ−ＳＱＬで呼び出すことができる。ＵＤＴは、１行の中の１列の型、Ｔ−ＳＱＬのルーチンのパラメータの型、またはＴ−ＳＱＬの変数の型とすることができる。
以下の実施例は、ＵＤＴの基本事項を例示している。ＭａｐＬｉｂ．ｄｌｌがＭａｐＬｉｂというアセンブリを持つと仮定する。このアセンブリでは、名前空間ＢａｓｅＴｙｐｅｓの下に、Ｐｏｉｎｔと呼ばれるクラスがある。
Figure 0004394644
以下のＴ−ＳＱＬコードは、クラスＰｏｉｎｔをＰｏｉｎｔと呼ばれるＳＱＬ Ｓｅｒｖｅｒ ＵＤＴにバインドする。第１のステップでは、「ＣｒｅａｔｅＡｓｓｅｍｂｌｙ」を呼び出すが、これは、ＭａｐＬｉｂアセンブリをデータベース内にロードする。第２のステップでは、「Ｃｒｅａｔｅ Ｔｙｐｅ」を呼び出して、ユーザ定義型「Ｐｏｉｎｔ」を作成し、マネージド型ＢａｓｅＴｙｐｅｓ．Ｐｏｉｎｔにバインドする。
Figure 0004394644
作成された後、「Ｐｏｉｎｔ」ＵＤＴは、テーブル内の列として使用することができ、メソッドは、以下に示されているようにＴ−ＳＱＬで呼び出すことができる。
Figure 0004394644
ストレージプラットフォームスキーマをＵＤＴクラスにマッピングすることは、高いレベルにおいてかなり容易である。一般に、ストレージプラットフォームＳｃｈｅｍａは、ＣＬＲ名前空間にマッピングされる。ストレージプラットフォームＴｙｐｅは、ＣＬＲクラスにマッピングされる。ＣＬＲクラス継承は、ストレージプラットフォームＴｙｐｅ継承を反映し、ストレージプラットフォームＰｒｏｐｅｒｔｙは、ＣＬＲクラスプロパティにマッピングされる。
図２９に例示されているＩｔｅｍ階層は、本明細書では一実施例として使用されている。これは、すべてのＩｔｅｍ型の派生元となるＢａｓｅ．Ｉｔｅｍ型を、派生Ｉｔｅｍ型の集合（例えば、Ｃｏｎｔａｃｔ．ＰｅｒｓｏｎおよびＣｏｎｔａｃｔ．Ｅｍｐｌｏｙｅｅ）とともに示しており、継承は矢印で示されている。
２．アイテムのマッピング
Ｉｔｅｍが大域的に検索可能であることが望ましく、継承および型代替可能性に対する本発明のリレーショナルデータベースでのサポートがあれば、データベースストア内のＩｔｅｍストレージの１つの可能な実装は、すべてのＩｔｅｍを型Ｂａｓｅ．Ｉｔｅｍの列を含む単一テーブルに格納することである。型代替可能性を使用すると、すべての型のＩｔｅｍを格納することが可能になり、またＹｕｋｏｎの「ｉｓ ｏｆ（Ｔｙｐｅ）」演算子を使用してＩｔｅｍ型と子型により検索をフィルタ処理することが可能になる。
しかし、本発明においては、そのようなアプローチに関連するオーバーヘッドに関する心配から、Ｉｔｅｍは、最上位の型により分割され、それぞれの型の「族（family）」のＩｔｅｍが別々のテーブルに格納される。このパーティション分割スキームに従って、Ｂａｓｅ．Ｉｔｅｍから直接継承するＩｔｅｍ型毎に１つのテーブルが作成される。これらの下の型継承は、上述のように、型代替え可能性を使用して適切な型族テーブルに格納される。Ｂａｓｅ．Ｉｔｅｍからの継承の第１のレベルのみが特別に処理される。例えば、図２９に示されているＩｔｅｍ階層では、この結果、以下の型族テーブルが得られる。
Figure 0004394644
すべてのＩｔｅｍに対する大域的に検索可能なプロパティのコピーを格納するために「シャドウ」テーブルが使用される。このテーブルは、すべてのデータ変更が行われる際に使用される、ストレージプラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドにより保持することできる。型族テーブルと異なり、大域的Ｉｔｅｍテーブルは、完全なＵＤＴ Ｉｔｅｍオブジェクトではなく、Ｉｔｅｍの最上位スカラープロパティのみを含む。大域的Ｉｔｅｍテーブルの構造は以下の通りである。
Figure 0004394644
大域的Ｉｔｅｍテーブルでは、ＩｔｅｍＩＤおよびＴｙｐｅＩＤを公開することにより型族テーブルに格納されているＩｔｅｍオブジェクトにナビゲートすることができる。ＩｔｅｍＩＤは、一般に、データストア内のＩｔｅｍを一意に識別する。ＴｙｐｅＩＤは、ここでは説明しないメタデータを使用して、型名およびＩｔｅｍを含むビューにマッピングすることができる。
ＩｔｅｍをそのＩｔｅｍＩＤにより見つけることはごく普通のオペレーションといえるので、大域的Ｉｔｅｍテーブルおよび他の何らかの手段の両方の文脈において、ＩｔｅｍのＩｔｅｍＩＤを指定するとＩｔｅｍオブジェクトを取り出すＧｅｔＩｔｅｍ（）関数が用意されている。この関数は以下の宣言を持つ。
Base.Item Base.GetItem (uniqueidentifier ItemID)
アクセスを簡単に、実装の詳細をできる限り隠すために、Ｉｔｅｍのすべてのクエリは、上述のＩｔｅｍテーブル上に構築されたビューに対して行われるようにできる。特に、ビューは、該当する型族テーブルと突き合わせてＩｔｅｍ型毎に作成されうる。これらの型ビューでは、子型を含む、関連付けられた型のすべてのＩｔｅｍを選択することができる。便宜のため、ＵＤＴオブジェクトに加えて、それらのビューは、継承されたフィールドを含む、その型の最上位レベルのフィールドのすべてに対する列を公開することができる。図２９に示されているＩｔｅｍ階層例のビューは以下の通りである。
Figure 0004394644
完全を期すため、大域的Ｉｔｅｍテーブルの上にビューも作成することができる。このビューは、最初に、そのテーブルと同じ列を公開することができる。
Figure 0004394644
３．拡張マッピング
Ｅｘｔｅｎｓｉｏｎｓは、Ｉｔｅｍに非常によく似ており、同じ要求条件のうちいくつかを持つ。継承をサポートする他のルート型として、Ｅｘｔｅｎｓｉｏｎｓはストレージに対する同じ考慮事項とトレードオフの関係の多くの影響を受ける。このため、類似の型族マッピングは、単一テーブルアプローチではなく、むしろ、Ｅｘｔｅｎｓｉｏｎｓに適用される。もちろん、他の実施形態では、単一テーブルアプローチを使用することが可能である。
本発明の実施形態では、ＥｘｔｅｎｓｉｏｎはＩｔｅｍＩＤによりちょうど１つのＩｔｅｍに関連付けられ、Ｉｔｅｍの文脈において一意であるＥｘｔｅｎｓｉｏｎＩＤを含む。Ｅｘｔｅｎｓｉｏｎテーブルは、以下の定義を持つ。
Figure 0004394644
Ｉｔｅｍの場合と同様に、ＩｔｅｍＩＤとＥｘｔｅｎｓｉｏｎＩＤのペアからなる、識別を与えられたＥｘｔｅｎｓｉｏｎを取り出す関数を用意することが可能である。この関数は以下の宣言を持つ。
Figure 0004394644
Ｖｉｅｗは、Ｅｘｔｅｎｓｉｏｎ型毎に作成され、Ｉｔｅｍ型ビューに類似している。Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎ、Ｃｏｎｔａｃｔ．ＰｅｒｓｏｎＥｘｔｅｎｓｉｏｎ、Ｃｏｎｔａｃｔ．ＥｍｐｌｏｙｅｅＥｘｔｅｎｓｉｏｎの型を持つ、Ｉｔｅｍ階層例と並行するＥｘｔｅｎｓｉｏｎ階層を仮定する。以下のビューを作成できる。
Figure 0004394644
４．ネストされている要素のマッピング
Ｎｅｓｔｅｄ Ｅｌｅｍｅｎｔｓは、深くネストされた構造を形成するためにＩｔｅｍ、Ｅｘｔｅｎｓｉｏｎｓ、Ｒｅｌａｔｉｏｎｓｈｉｐｓ、または他のＮｅｓｔｅｄ Ｅｌｅｍｅｎｔｓ内に埋め込むことができる型である。ＩｔｅｍおよびＥｘｔｅｎｓｉｏｎｓのように、Ｎｅｓｔｅｄ Ｅｌｅｍｅｎｔｓは、ＵＤＴとして実装されるが、ＩｔｅｍとＥｘｔｅｎｓｉｏｎｓ内に格納される。したがって、Ｎｅｓｔｅｄ Ｅｌｅｍｅｎｔｓは、そのＩｔｅｍおよびＥｘｔｅｎｓｉｏｎコンテナを超えるストレージマッピングを持たない。つまり、ＮｅｓｔｅｄＥｌｅｍｅｎｔ型のインスタンスを直接格納するテーブルはシステムにはなく、Ｎｅｓｔｅｄ Ｅｌｅｍｅｎｔｓ専用のビューもない。
５．オブジェクト識別（Ｉｄｅｎｔｉｔｙ）
データモデル内の各エンティティ、つまり、各Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＲｅｌａｔｉｏｎｓｈｉｐは一意のキー値を持つ。Ｉｔｅｍは、ＩｔｅｍＩＤにより一意に識別される。Ｅｘｔｅｎｓｉｏｎは、（ＩｔｅｍＩｄ，ＥｘｔｅｎｓｉｏｎＩｄ）の複合キーにより一意に識別される。Ｒｅｌａｔｉｏｎｓｈｉｐは、複合キー（ＩｔｅｍＩｄ，ＲｅｌａｔｉｏｎｓｈｉｐＩｄ）により識別される。ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ、およびＲｅｌａｔｉｏｎｓｈｉｐＩｄはＧＵＩＤ値である。
６．ＳＱＬオブジェクトの命名規則
データストア内に作成されたすべてのオブジェクトは、ストレージプラットフォームスキーマ名から派生されたＳＱＬスキーマ名で格納することができる。例えば、ストレージプラットフォームＢａｓｅスキーマ（「Ｂａｓｅ」と呼ばれることが多い）は、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．Ｉｔｅｍ」などの「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］」ＳＱＬスキーマで型を生成することができる。生成された名前は、命名の競合をなくすため、修飾子が先頭に付けられる。適宜、感嘆符（！）が、名前の各論理部分の仕切りとして使用される。以下の表は、データストア内のオブジェクトに使用される命名規則の概要である。それぞれのスキーマ要素（Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、Ｒｅｌａｔｉｏｎｓｈｉｐ、およびＶｉｅｗ）は、データストア内のインスタンスにアクセスするために使用される装飾された命名規則とともに一覧にされている。
Figure 0004394644
７．列の命名規則
オブジェクトモデルをストアにマッピングする場合、アプリケーションオブジェクトとともに追加情報が格納されているため、命名競合が発生する可能性がある。命名競合を回避するため、すべての非型固有列（non-type specific columns）（型宣言で名前付きＰｒｏｐｅｒｔｙに直接マッピングされない列）の先頭に、下線（＿）文字を付ける。本発明の実施形態では、下線（＿）文字は、識別子プロパティの先頭文字としては禁止されている。さらに、ＣＬＲとデータストアとの間の命名法の統一のため、ストレージプラットフォームの型またはスキーマ要素（関係など）のすべてのプロパティは、先頭文字を大文字にしていなければならない。
８．検索ビュー
ビューは、格納されているコンテンツを検索するためストレージプラットフォームにより用意される。ＳＱＬビューは、各ＩｔｅｍおよびＥｘｔｅｎｓｉｏｎ型について用意されている。さらに、ビューは、ＲｅｌａｔｉｏｎｓｈｉｐｓとＶｉｅｗｓをサポートするためにも用意されている（Ｄａｔａ Ｍｏｄｅｌでの定義に従って）。ストレージプラットフォーム内のすべてのＳＱＬビューおよび基礎のテーブルは読み取り専用である。データは、以下に詳述するように、ストレージプラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドを使用して格納または変更することができる。
ストレージプラットフォームスキーマで明示的に定義されているそれぞれのビューは（スキーマデザイナにより定義され、ストレージプラットフォームにより自動的には生成されない）は、名前付きＳＱＬビュー［＜ｓｃｈｅｍａ−ｎａｍｅ＞］．［Ｖｉｅｗ！＜ｖｉｅｗ−ｎａｍｅ＞］によりアクセス可能である。例えば、スキーマ「ＡｃｍｅＰｕｂｌｉｓｈｅｒ．Ｂｏｏｋｓ」内の「ＢｏｏｋＳａｌｅｓ」という名前のビューは、名前「［ＡｃｍｅＰｕｂｌｉｓｈｅｒ．Ｂｏｏｋｓ］．［Ｖｉｅｗ！ＢｏｏｋＳａｌｅｓ］」を使用するとアクセス可能である。ビューの出力形式はビュー毎に変更できるので（ビューを定義する当事者により与えられる任意のクエリにより定義される）、列は、スキーマビュー定義に基づいて直接マッピングされる。
ストレージプラットフォームのデータストア内のすべてのＳＱＬ検索ビューは、列に対し以下の順序付け規則を使用する。
１．ＩｔｅｍＩｄ、ＥｌｅｍｅｎｔＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄ、．．．などのビュー結果の（複数の）論理「ｋｅｙ」列。
２．ＴｙｐｅＩｄなどの結果の型に関するメタデータ情報。
３．ＣｒｅａｔｅＶｅｒｓｉｏｎ、ＵｐｄａｔｅＶｅｒｓｉｏｎ、．．．などの変更追跡列。
４．（複数の）型特有の列（宣言された型のＰｒｏｐｅｒｔｉｅｓ）
５．型特有のビュー（族ビュー）も、オブジェクトを返すオブジェクト列を含む。
各型族のメンバは、一連のＩｔｅｍビューを使用して検索可能であり、データストア内にＩｔｅｍ型毎に１つのビューがある。
ａ）アイテム
各Ｉｔｅｍ検索ビューは、特定の型またはその子型のＩｔｅｍの各インスタンスに対する１つの行を含む。例えば、Ｄｏｃｕｍｅｎｔに対するビューは、Ｄｏｃｕｍｅｎｔ、ＬｅｇａｌＤｏｃｕｍｅｎｔ、およびＲｅｖｉｅｗＤｏｃｕｍｅｎｔのインスタンスを返すことができる。この例では、Ｉｔｅｍビューは、図２８に示されているように概念化することができる。
（１）マスターアイテム検索ビュー
ストレージプラットフォームのデータストアのそれぞれのインスタンスは、マスターアイテムビューという特別なＩｔｅｍビューを定義する。このビューは、データストア内のそれぞれのＩｔｅｍに関する概要情報を示す。ビューは、Ｉｔｅｍ型プロパティ毎に１つの列を示し、列は、変更追跡および同期情報を供給するために使用されるＩｔｅｍおよび複数の列の型を記述している。マスターアイテムビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」を使用してデータストア内で識別される。
Figure 0004394644
（２）型付きアイテム検索ビュー
各Ｉｔｅｍ型は、さらに、検索ビューを持つ。ルートＩｔｅｍビューに似ているが、このビューは、さらに、「＿Ｉｔｅｍ」列を介してＩｔｅｍオブジェクトにアクセスできる。各型付きアイテム検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［ｉｔｅｍＴｙｐｅＮａｍｅ］を使用してデータストア内で識別される。例えば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［ＯｆｆｉｃｅＤｏｃ］。
Figure 0004394644
ｂ）アイテム拡張
ＷｉｎＦＳ Ｓｔｏｒｅ内のすべてのＩｔｅｍ Ｅｘｔｅｎｓｉｏｎｓは、検索ビューを使用してアクセスすることもできる。
（１）マスター拡張検索ビュー
データストアのそれぞれのインスタンスは、マスター拡張ビュー（Ｍａｓｔｅｒ Ｅｘｔｅｎｓｉｏｎ Ｖｉｅｗ）という特別なＥｘｔｅｎｓｉｏｎビューを定義する。このビューは、データストア内のそれぞれのＥｘｔｅｎｓｉｏｎに関する概要情報を示す。ビューは、Ｅｘｔｅｎｓｉｏｎプロパティ毎に１つの列を持ち、列は、変更追跡および同期情報を供給するために使用されるＥｘｔｅｎｓｉｏｎおよび複数の列の型を記述している。マスター拡張ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｅｘｔｅｎｓｉｏｎ］」を使用してデータストア内で識別される。
Figure 0004394644
（２）型付き拡張検索ビュー
各Ｅｘｔｅｎｓｉｏｎ型は、さらに、検索ビューを持つ。マスター拡張ビューに似ているが、このビューは、さらに、＿Ｅｘｔｅｎｓｉｏｎ列を介してＩｔｅｍオブジェクトにアクセスできる。各型付き拡張検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［Ｅｘｔｅｎｓｉｏｎ！ｅｘｔｅｎｓｉｏｎＴｙｐｅＮａｍｅ］を使用してデータストア内で識別される。例えば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｅｘｔｅｎｓｉｏｎ！ＯｆｆｉｃｅＤｏｃＥｘｔ］。
Figure 0004394644
ｃ）ネストされている要素
すべてのネストされている要素は、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎｓ、またはＲｅｌａｔｉｏｎｓｈｉｐｓインスタンス内に格納される。したがって、該当するＩｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、またはＲｅｌａｔｉｏｎｓｈｉｐ検察ビューにクエリを行うことで、これらはアクセスされる。
ｄ）関係
上述のように、Ｒｅｌａｔｉｏｎｓｈｉｐｓは、ストレージプラットフォームのデータストア内にＩｔｅｍ間のリンキングの基本ユニットを形成する。
（１）マスター関係検索ビュー
それぞれのデータストアは、Ｍａｓｔｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｖｉｅｗを与える。このビューは、データストア内のすべての関係インスタンスに関する情報を示す。マスター関係ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｒｅｌａｔｉｏｎｓｈｉｐ］」を使用してデータストア内で識別される。
Figure 0004394644
（２）関係インスタンス検索ビュー
それぞれの宣言されたＲｅｌａｔｉｏｎｓｈｉｐは、さらに、特定の関係のすべてのインスタンスを返す検索ビューを持つ。マスター関係ビューに似ているが、このビューは、さらに、関係データのプロパティ毎に名前付き列を示す。各関係インスタンス検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ｒｅｌａｔｉｏｎｓｈｉｐＮａｍｅ］を使用してデータストア内で識別される。例えば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ］。
Figure 0004394644
９．更新
ストレージプラットフォームのデータストア内のすべてのビューは読み取り専用である。データモデル要素（アイテム、拡張、または関係）の新しいインスタンスを作成する、または既存のインスタンスを更新するには、ストレージプラットフォームＡＰＩのＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎまたはＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドが使用されなければならない。ＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎメソッドは、実行されるアクションの詳細を決める「オペレーション」を消費するデータストアにより定義された単一のストアドプロシージャである。ＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドは、実行されるアクションの集合の詳細を包括的に決める、「アップデートグラム」と呼ばれる、オペレーションの順序付き集合を受け取るストアドプロシージャである。
オペレーション形式は、拡張可能であり、スキーマ要素に対する様々なオペレーションを用意している。共通オペレーションとしては以下のものがある。
１．Ｉｔｅｍオペレーション：
ａ．ＣｒｅａｔｅＩｔｅｍ（埋め込みまたは保持関係の文脈において新しいアイテムを作成する）
ｂ．ＵｐｄａｔｅＩｔｅｍ（既存のＩｔｅｍを更新する）
２．Ｒｅｌａｔｉｏｎｓｈｉｐオペレーション：
ａ．ＣｒｅａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（参照または保持関係のインスタンスを作成する）
ｂ．ＵｐｄａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（関係インスタンスを更新する）
ｃ．ＤｅｌｅｔｅＲｅｌａｔｉｏｎｓｈｉｐ（関係インスタンスを削除する）
３．Ｅｘｔｅｎｓｉｏｎオペレーション：
ａ．ＣｒｅａｔｅＥｘｔｅｎｓｉｏｎ（既存のＩｔｅｍに拡張を追加する）
ｂ．ＵｐｄａｔｅＥｘｔｅｎｓｉｏｎ（既存の拡張を更新する）
ｃ．ＤｅｌｅｔｅＥｘｔｅｎｓｉｏｎ（拡張を削除する）
１０．変更追跡＆ツームストーン
変更追跡およびツームストーンサービスは、以下で詳述するように、データストアにより提供される。このセクションでは、データストア内に公開された変更追跡情報の概要を述べる。
ａ）変更追跡
データストアによって与えられるそれぞれの検索ビューは、変更追跡情報を供給するために使用される列を含み、それらの列は、すべてのＩｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＲｅｌａｔｉｏｎｓｈｉｐビュー間で共通である。ストレージプラットフォームのＳｃｈｅｍａ Ｖｉｅｗｓは、スキーマデザイナにより明示的に定義され、変更追跡情報を自動的に供給することはしない−そのような情報は、ビュー自体が構築される検索ビューを通じて間接的に供給される。
データストア内の要素毎に、変更追跡情報は２つの場所−「マスター」要素ビューと「型付き」要素ビューから利用できる。例えば、ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ．Ｄｏｃｕｍｅｎｔ Ｉｔｅｍ型に関する変更追跡情報は、マスターアイテムビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」および型付きアイテム検索ビュー［ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ］．［Ｄｏｃｕｍｅｎｔ］から利用できる。
（１）「マスター」検索ビューでの変更追跡
マスター検索ビュー内の変更追跡情報は、要素の作成および更新バージョンに関する情報、要素を作成した同期パートナに関する情報、要素を最後に更新した同期パートナに関する情報、および作成および更新に関する各パートナからのバージョン番号を示す。同期関係にあるパートナ（後述）は、パートナキーにより識別される。型［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓｔｏｒｅ］．ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏの＿ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏという名前の単一のＵＤＴオブジェクトがこの情報を格納する。この型は、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅスキーマで定義される。＿ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏは、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＲｅｌａｔｉｏｎｓｈｉｐについてすべての大域的検索デビューで利用可能である。ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏの型定義は以下の通りである。
Figure 0004394644
これらのプロパティは、以下の情報を含む。
Figure 0004394644
（２）「型付き」検索ビューでの変更追跡
大域的検索ビューと同じ情報を供給することに加えて、それぞれの型付き検索ビューは、同期トポロジ内の各要素の同期状態を記録した追加情報を供給する。
Figure 0004394644
ｂ）ツームストーン
データストアは、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎｓ、およびＲｅｌａｔｉｏｎｓｈｉｐｓのツームストーン情報を与える。ツームストーンビューは、ある場所にあるライブ状態のエンティティとツームストーン状態のエンティティ（ｌｉｖｅ ａｎｄ ｔｏｍｂｓｔｏｎｅｄ ｅｎｔｉｔｉｅｓ）（アイテム、拡張、および関係）の両方に関する情報を示す。アイテムおよび拡張ツームストーンビューは、対応するオブジェクトへのアクセスを行えないが、関係ツームストーンビューは、関係オブジェクトへのアクセスを行える（関係オブジェクトは、ツームストーン状態の関係の場合にはＮＵＬＬである）。
（１）アイテムツームストーン
アイテムツームストーンは、ビュー［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｉｔｅｍ］を介してシステムから取り出される。
Figure 0004394644
（２）拡張ツームストーン
拡張ツームストーンは、ビュー［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｅｘｔｅｎｓｉｏｎ］を使用してシステムから取り出される。拡張変更追跡情報は、ＥｘｔｅｎｓｉｏｎＩｄプロパティの追加を含むＩｔｅｍについて与えられる情報と類似している。
Figure 0004394644
（３）関係ツームストーン
関係ツームストーンは、ビュー［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｒｅｌａｔｉｏｎｓｈｉｐ］を介してシステムから取り出される。関係ツームストーン情報は、Ｅｘｔｅｎｓｉｏｎｓについて与えられる情報と類似している。しかし、追加情報は、関係インスタンスのターゲットＩｔｅｍＲｅｆ上で与えられる。さらに、関係オブジェクトも選択される。
Figure 0004394644
（４）ツームストーンのクリーンアップ
ツームストーン情報の際限のない増殖を防ぐために、データストアは、ツームストーンのクリーンアップタスクを用意している。このタスクは、ツームストーン情報をいつ破棄できるかを決定する。このタスクは、ローカルの作成／更新バージョンに対する限界を計算し、その後、旧いすべてのツームストーンバージョンを破棄することによりツームストーン情報を切り詰める。
１１．ヘルパＡＰＩおよび関数
Ｂａｓｅマッピングは、さらに、多数のヘルパ関数も備える。これらの関数は、データモデルに対する共通のオペレーションを補助するために用意されている。
ａ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＩｔｅｍ
ＩｔｅｍＩｄを与えられたＩｔｅｍオブジェクトを返す。
//
Item GetItem (ItemId ItemId)
ｂ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＥｘｔｅｎｓｉｏｎ
//ＩｔｅｍＩｄおよびＥｘｔｅｎｓｉｏｎＩｄを与えられた拡張オブジェクトを返す。
//
Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId)
ｃ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＲｅｌａｔｉｏｎｓｈｉｐ
//ＩｔｅｍＩｄおよびＲｅｌａｔｉｏｎｓｈｉｐＩｄを与えられた関係オブジェクトを返す。
//
Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)
１２．メタデータ
ストアで表されるメタデータは、インスタンスメタデータ（Ｉｔｅｍの型など）および型メタデータの２種類がある。
ａ）スキーマメタデータ
スキーマメタデータは、ＭｅｔａスキーマからのＩｔｅｍ型のインスタンスとしてデータストア内に格納される。
ｂ）インスタンスメタデータ
インスタンスメタデータは、Ｉｔｅｍの型についてクエリを実行するためにアプリケーションによって使用され、これによりＩｔｅｍに関連付けられている拡張を見つける。Ｉｔｅｍに対するＩｔｅｍＩｄが与えられれば、アプリケーションは、大域的アイテムビューにクエリを実行して、Ｉｔｅｍの型を返し、この値を使用して、Ｍｅｔａ．Ｔｙｐｅビューにクエリを実行し、Ｉｔｅｍの宣言された型に関する情報を返す。例えば、以下のようになる。
Figure 0004394644
Ｅ．セキュリティ
この節では、一実施形態による、本発明のストレージプラットフォームのセキュリティモデルを説明する。
１．概要
本発明の実施形態により、ストレージプラットフォームのセキュリティポリシーが指定され強制される精度は、与えられたデータストア内のアイテムに対する様々なオペレーションのレベルにあり、全体とは別にアイテムの一部分をセキュリティ保護する機能はない。セキュリティモデルでは、アクセス制御リスト（ＡＣＬ）を通じてそれらのオペレーションをアイテムに対し実行するため誰かにアクセス権を付与し、または誰かを拒絶することができるプリンシパルの集まりを指定する。それぞれのＡＣＬは、アクセス制御エントリ（ＡＣＥ）の順序付きコレクションである。
アイテムのセキュリティポリシーは、自由裁量的アクセス制御ポリシーおよびシステムアクセス制御ポリシーにより完全に記述することができる。これらはそれぞれＡＣＬの集合である。第１の集合（ＤＡＣＬ）は、アイテムの所有者により様々なプリンシパルに付与される自由裁量的アクセス権を記述するが、ＡＣＬの第２の集合は、ＳＡＣＬ（システムアクセス制御リスト）と呼ばれ、オブジェクトがいくつかの方法で操作される場合にシステム監査がどのように実行されるかを指定する。これらに加えて、データストア内のそれぞれのアイテムは、アイテムの所有者に対応するＳＩＤ（Ｏｗｎｅｒ ＳＩＤ）に関連付けられる。
ストレージプラットフォームのデータストア内にアイテムを編成する一次メカニズムは、包含階層のメカニズムである。包含階層は、アイテム間の保持関係を使用して実現される。「ＡはＢを含む」として表される２つのアイテムＡとＢとの間の保持関係により、アイテムＡはアイテムＢの存続期間に影響を及ぼすことができる。一般に、データストア内のアイテムは、他のアイテムからそのアイテムへの保持関係がある間、存在しえない。保持関係は、アイテムの存続期間を制御することに加えて、アイテムのセキュリティポリシーを伝搬する必要なメカニズムも備える。
それぞれのアイテムについて指定されたセキュリティポリシーは、そのアイテムについて明示的に指定された部分とデータストア内のアイテムの親から継承される部分の２つの部分からなる。アイテムに対する明示的に定義されたセキュリティポリシーは、考慮対象のアイテムへのアクセスを管理する部分と包含階層内のすべての子孫により継承されるセキュリティポリシーに影響を及ぼす部分の２つの部分からなる。子孫により継承されるセキュリティポリシーは、明示的に定義されているポリシーおよび継承されたポリシーに応じて変わる。
セキュリティポリシーは保持関係を通じて伝搬され、任意のアイテムのところでオーバーライドされうるので、アイテムに対する有効なセキュリティポリシーがどのように決定されるかを指定する必要がある。本発明の実施形態では、データストアの包含階層内のアイテムは、ストアのルートからそのアイテムまでのすべてのパスにそってＡＣＬを継承する。
与えられたパスについて継承されたＡＣＬ内で、ＡＣＬ内の様々なＡＣＥの順序付けにより、強制される最終的なセキュリティポリシーが決定される。以下の注釈を使用して、ＡＣＬ内のＡＣＥの順序付けを記述する。アイテムにより継承されるＡＣＬ内のＡＣＥの順序付けは、以下の２つの規則により決定される。
第１の規則は、包含階層のルートからアイテムＩへのパス内の様々なアイテムから継承されるＡＣＥを階層化する。近いコンテナから継承されたＡＣＥは、遠いコンテナから継承されるエントリに優先する。直観的には、これにより、管理者は、包含階層内のさらに遠くから上に継承されるＡＣＥをオーバーライドすることができる。この規則は、次の通りである。
アイテムＩ上の継承されるすべてのＡＣＬのＬについて
すべてのアイテムＩ１、Ｉ２について
Ｌ内のすべてのＡＣＥのＡ１およびＡ２について
Ｉ１はＩ２の祖先であり、
Ｉ２はＩ３の祖先であり、
Ａ１はＩ１から継承されたＡＣＥであり、
Ａ２はＩ２から継承されたＡＣＥである
ことが成り立てば、
Ａ２はＬ内のＡ１に先行する
第２の規則は、アイテムへのアクセスを拒絶するＡＣＥをアイテムへのアクセスを許可するＡＣＥより先になるように順序付ける。
アイテムＩ上の継承されるすべてのＡＣＬのＬについて
すべてのアイテムＩ１について
Ｌ内のすべてのＡＣＥのＡ１およびＡ２について
Ｉ１はＩ２の祖先であり、
Ａ１はＩ１から継承されたＡＣＣＥＳＳ＿ＤＥＮＩＥＤ＿ＡＣＥであり、
Ａ２はＩ１から継承されたＡＣＣＥＳＳ＿ＧＲＡＮＴＥＤ＿ＡＣＥである
ことが成り立てば、
Ａ１はＬ内のＡ２に先行する
包含階層がツリーの場合、ツリーのルートからアイテムへのパスはちょうど１つあり、そのアイテムは、ちょうど１つの継承されたＡＣＬを持つ。これらの状況の下で、アイテムにより継承されるＡＣＬは、中に含まれるＡＣＥの相対的順序付けに関して既存のＷｉｎｄｏｗｓ（登録商標）セキュリティモデルでのファイル（アイテム）により継承されるＡＣＬとマッチングする。
しかし、データストア内の包含階層は、複数の保持関係がアイテムに対し許可されるため非循環有向グラフ（ＤＡＧ）である。これらの条件の下で、包含階層のルートからアイテムへの複数のパスがある。アイテムは、すべてのパスにそってＡＣＬを継承するので、それぞれのアイテムは、単一のＡＣＬではなく、ＡＣＬのコレクションと関連付けられる。これは、従来のファイルシステムモデルとは異なり、ちょうど１つのＡＣＬが１つのファイルまたはフォルダに関連付けられることに注意されたい。
ツリーとは反対に、包含階層がＤＡＧである場合には、詳細にする必要のある態様が２つある。親から複数のＡＣＬを継承する場合にアイテムに対する有効なセキュリティポリシーをどのように計算するかについての説明が必要であり、また編成および表現の仕方は、ストレージプラットフォームのデータストアのセキュリティモデルの管理に直接影響を及ぼす。
以下のアルゴリズムでは、与えられたアイテムに対する与えられたプリンシパルのアクセス権を評価する。本明細書全体を通して、以下の表記を使用して、アイテムに関連付けられているＡＣＬを説明する。
Ｉｎｈｅｒｉｔｅｄ＿ＡＣＬｓ（ＩｔｅｍＩｄ）−アイテムＩＤがストア内の親からのＩｔｅｍＩｄであるアイテムにより継承されるＡＣＬの集合。
Ｅｘｐｌｉｃｉｔ＿ＡＣＬ（ＩｔｅｍＩｄ）−ＩＤがＩｔｅｍＩｄであるアイテムについて明示的に定義されているＡＣＬ。
Figure 0004394644
上記ルーチンは、所望のアクセスが明示的に拒絶されなかった場合にＳＴＡＴＵＳ＿ＳＵＣＣＥＳＳを返し、ｐＧｒａｎｔｅｄＡｃｃｅｓｓは、ユーザが望む権利のうちのどれが指定されたＡＣＬにより付与されたかを決定する。所望のアクセス権が明示的に拒絶された場合、ルーチンはＳＴＡＴＵＳ＿ＡＣＣＥＳＳ＿ＤＥＮＩＥＤを返す。
Figure 0004394644
任意のアイテムで定義されているセキュリティポリシーの影響範囲は、データストア上で定義されている包含階層内のアイテムのすべての子孫を含む。明示的ポリシーが定義されているすべてのアイテムについて、ここでは事実上、包含階層内のすべての子孫により継承されるポリシーを定義している。すべての子孫により継承される有効なＡＣＬは、アイテムにより継承されるＡＣＬのそれぞれを受け取り、明示的なＡＣＬ内の継承可能なＡＣＥをＡＣＬの先頭に追加することにより得られる。これは、そのアイテムに関連付けられた継承可能なＡＣＬの集合と呼ばれる。
フォルダアイテムをルートとする包含階層内のセキュリティの明示的指定がない場合、そのフォルダのセキュリティ指定は、包含階層内のそのアイテムのすべての子孫に適用される。そのため、明示的なセキュリティポリシー指定が与えられるすべてのアイテムは、まったく同じように保護されているアイテムの領域を定義し、その領域内のすべてのアイテムに対する有効なＡＣＬは、そのアイテムに対する継承可能なＡＣＬの集合である。これは、ツリーである包含階層の場合に領域を完全に定義する。それぞれの領域に番号が関連付けられるとすれば、アイテムが属する領域をそのアイテムとともに単に含むだけで十分であろう。
しかし、ＤＡＧである包含階層では、有効なセキュリティポリシーが変化する包含階層のポイントは、２種類のアイテムにより決定される。第１は、明示的なＡＣＬが指定されているアイテムである。通常、これらは、管理者が明示的にＡＣＬを指定した包含階層内のポイントである。第２は、複数の親を持つアイテムであり、親は、それらに関連付けられている異なるセキュリティポリシーを持つ。通常、これらは、ボリュームについて指定されたセキュリティポリシーの合流点であるアイテムであり、新しいセキュリティポリシーの開始を示す。
この定義により、データストア内のすべてのアイテムは、２つのカテゴリまったく同じように保護されているセキュリティ領域のルートであるカテゴリとそうでないカテゴリのうちの１つに分類される。セキュリティ領域を定義しないアイテムは、ちょうど１つのセキュリティ領域に属する。ツリーの場合のように、アイテムに対する有効なセキュリティは、アイテムが属す領域をそのアイテムとともに指定することにより指定できる。これにより、ストア内の様々なまったく同じように保護されている領域に基づいてストレージプラットフォームのデータストアのセキュリティを管理する簡単なモデルが得られる。
２．セキュリティモデルの詳細な説明
この節では、セキュリティ記述子内の個々の権利および含まれるＡＣＬが様々なオペレーションにどのように影響を及ぼすかを記述することによりアイテムのセキュリティ保護方法の詳細を示す。
ａ）セキュリティ記述子構造
セキュリティモデルの詳細を説明する前に、セキュリティ記述子の基本事項を説明すると有益である。セキュリティ記述子は、セキュリティ設定可能なオブジェクトに関連付けられたセキュリティ情報を含む。セキュリティ記述子は、ＳＥＣＵＲＩＴＹ＿ＤＥＳＣＲＩＰＴＯＲ構造体およびその関連付けられたセキュリティ情報からなる。セキュリティ記述子は、以下のセキュリティ情報を含むことができる。
１．オブジェクトの所有者および一次グループに対するＳＩＤ。
２．特定のユーザまたはグループに対して許可または拒絶されるアクセス権を指定するＤＡＣＬ。
３．オブジェクトに対する監査レコードを生成するアクセスの試行の型を指定するＳＡＣＬ。
４．セキュリティ記述子またはその個別のメンバの意味を限定する制御ビットの集合。
アプリケーションは、セキュリティ記述子の内容を直接操作できないのが好ましい。オブジェクトのセキュリティ記述子内のセキュリティ情報の設定および取り出しを行う関数がある。さらに、新しいオブジェクトのセキュリティ記述子を作成し初期化する関数がある。
自由裁量的アクセス制御リスト（ＤＡＣＬ）は、セキュリティ設定可能なオブジェクトへのアクセスを許可または拒絶される受託者を識別する。プロセスがセキュリティ設定可能なオブジェクトにアクセスしようとした場合、システムでは、オブジェクトのＤＡＣＬ内のＡＣＥをチェックして、それにアクセス権を付与するかどうかを決定する。オブジェクトがＤＡＣＬを持たない場合、システムは、全員に完全なアクセス権を付与する。オブジェクトのＤＡＣＬがＡＣＥを持たない場合、システムは、ＤＡＣＬがアクセス権を許可しないためオブジェクトにアクセスするすべての試みを拒絶する。システムは、要求されたすべてのアクセス権を許可する１つまたは複数のＡＣＥを見つけるか、または要求されたアクセス権のどれかが拒絶されるまで、順番にＡＣＥをチェックしてゆく。
システムアクセス制御リスト（ＳＡＣＬ）により、管理者は、セキュリティ保護されたオブジェクトにアクセスする試みをログに記録することができる。それぞれのＡＣＥは、システムにセキュリティイベントログ内への記録生成を行わせる指定された受託者によるアクセス試行の型を指定する。ＳＡＣＬ内のＡＣＥは、アクセス試行が失敗した場合、成功した場合、またはその両方の場合に、監査レコードを生成することができる。ＳＡＣＬは、さらに、無許可ユーザがオブジェクトへのアクセス権を獲得しようとした場合にアラームを発生することもできる。
すべての型のＡＣＥは、以下のアクセス制御情報を含む。
１．ＡＣＥが適用される受託者を識別するセキュリティ識別子（ＳＩＤ）。
２．ＡＣＥにより制御されるアクセス権を指定するアクセスマスク。
３．ＡＣＥの型を示すフラグ。
４．子コンテナまたはオブジェクトが、ＡＣＬがアタッチされる一次オブジェクトからＡＣＥを継承することができるかどうかを決定するビットフラグの集合。
以下の表は、すべてのセキュリティ設定可能なオブジェクトによりサポートされる３つのＡＣＥの型をまとめたものである。
Figure 0004394644
（１）アクセスマスク形式
すべてのセキュリティ設定可能なオブジェクトは、図２６に示されているアクセスマスク形式を使用してそのアクセス権を設定する。この形式では、下位１６ビットはオブジェクト特有のアクセス権に、次の７ビットは標準アクセス権に使用され、これは、オブジェクトのほとんどの型に適用され、上位４ビットは各オブジェクト型で標準およびオブジェクト特有の権利の集合にマッピングできる汎用アクセス権を指定するために使用される。ＡＣＣＥＳＳ＿ＳＹＳＴＥＭ＿ＳＥＣＵＲＩＴＹビットは、オブジェクトのＳＡＣＬにアクセスする権利に対応する。
（２）汎用アクセス権
汎用アクセス権は、マスク内で上位４ビットで指定される。各タイプのセキュリティ設定可能なオブジェクトは、これらのビットをその標準およびオブジェクト特有のアクセス権の集合にマッピングする。例えば、ファイルオブジェクトは、ＧＥＮＥＲＩＣ＿ＲＥＡＤビットをＲＥＡＤ＿ＣＯＮＴＲＯＬおよびＳＹＮＣＨＲＯＮＩＺＥ標準アクセス権、およびＦＩＬＥ＿ＲＥＡＤ＿ＤＡＴＡ、ＦＩＬＥ＿ＲＥＡＤ＿ＥＡ、およびＦＩＬＥ＿ＲＥＡＤ＿ＡＴＴＲＩＢＵＴＥＳオブジェクト特有のアクセス権にマッピングする。他のタイプのオブジェクトは、ＧＥＮＥＲＩＣ＿ＲＥＡＤビットをそのタイプのオブジェクトに適したアクセス権の集合にマッピングする。
汎用アクセス権は、オブジェクトのハンドルを開く場合に必要なアクセスのタイプを指定するために使用することができる。これは、対応するすべての標準および特定の権利を指定するのよりも単純であるのが普通である。以下の表は、汎用アクセス権について定義された定数をまとめたものである。
Figure 0004394644
（３）標準アクセス権
それぞれのタイプのセキュリティ設定可能なオブジェクトは、そのタイプのオブジェクトに特有のオペレーションに対応するアクセス権の集合を持つ。それらのオブジェクト特有のアクセス権に加えて、ほとんどのタイプのセキュリティ設定可能なオブジェクトに共通のオペレーションに対応する標準アクセス権の集合がある。以下の表は、標準アクセス権について定義された定数をまとめたものである。
Figure 0004394644
ｂ）アイテム特有の権利
図２６のアクセスマスク構造では、アイテム特有の権利は「Ｏｂｊｅｃｔ Ｓｐｅｃｉｆｉｃ Ｒｉｇｈｔｓ」セクション（下位１６ビット）に置かれる。本発明の実施形態では、ストレージプラットフォームは、セキュリティを管理する２組のＡＰＩ−Ｗｉｎ３２およびストレージプラットフォームＡＰＩ−を公開しているため、ファイルシステムオブジェクト特有の権利は、ストレージプラットフォーム特有の権利の設計の動機付けをするために考慮されなければならない。
（１）ファイルおよびディレクトリオブジェクト特有の権利
以下の表を考察する。
Figure 0004394644
前記の表を参照しつつ、ファイルシステムでは、基本的に、ファイルとディレクトリとを区別することに注意すべきであるが、それは、ファイルおよびディレクトリの権利が同じビット上でオーバーラップしているからである。ファイルシステムでは、アプリケーションがそれらのオブジェクト上のビヘイビアを制御できるようにする、非常に精度の高い権利を定義する。例えば、これらにより、アプリケーションは、属性（Ａｔｔｒｉｂｕｔｅｓ）（ＦＩＬＥ＿ＲＥＡＤ／ＷＲＩＴＥ＿ＡＴＴＲＩＢＵＴＥＳ）、拡張属性（Ｅｘｔｅｎｄｅｄ Ａｔｔｒｉｂｕｔｅｓ）、およびファイルに関連付けられたＤＡＴＡストリームを区別することができる。
本発明のストレージプラットフォームのセキュリティモデルの目標は、データストアアイテム（Ｃｏｎｔａｃｔｓ、Ｅｍａｉｌｓなど）に作用するアプリケーションが一般に、例えば属性、拡張属性、およびデータストリームを区別する必要がないように、権利割り当てモデルを簡素化することである。しかし、ファイルおよびフォルダの場合、細かいＷｉｎ３２権利は保持され、ストレージプラットフォームを介したアクセスの意味は、Ｗｉｎ３２アプリケーションとの互換性が実現可能なように定義される。このマッピングについては、以下で指定されたアイテム権利のそれぞれとともに説明される。
以下のアイテム権利は、関連付けられている許可可能なオペレーションとともに指定される。これらのアイテム権利のそれぞれを裏付ける同等のＷｉｎ３２権利も提供される。
（２）ＷｉｎＦＳＩｔｅｍＲｅａｄ
この権利を使用すると、埋め込まれた関係を介してアイテムにリンクされているアイテムを含むアイテムのすべての要素への読み込みアクセスが可能になる。また、保持関係を介してこのアイテムにリンクされているアイテムの列挙も可能である（ディレクトリリスティングともいう）。これは、参照関係を介してリンクされたアイテムの名前を含む。この権利は以下のようにマッピングされる。
ファイル：
(FILE_READ_DATA|SYNCHRONIZE)
フォルダ：
(FILE_LIST_DIRECTORY|SYNCHRONIZE)
これは、セキュリティアプリケーションが、ＷｉｎＦＳＩｔｅｍＲｅａｄＤａｔａを設定し、権利マスクを上で指定したファイル権利の組合せとして指定することが可能であることを意味する。
（３）ＷｉｎＦＳＩｔｅｍＲｅａｄＡｔｔｒｉｂｕｔｅｓ
この権利は、ファイルシステムが基本ファイル属性とデータストリームとを区別するのと同様に、Ｉｔｅｍの基本属性への読み込みアクセスを可能にする。これらの基本属性は、すべてのアイテムの派生元となる基本アイテム内に配置される属性であるのが好ましい。この権利は以下のようにマッピングされる。
ファイル：
(FILE_READ_ATTRIBUTES)
フォルダ：
(FILE_READ_ATTRIBUTES)
（４）ＷｉｎＦＳＩｔｅｍＷｒｉｔｅＡｔｔｒｉｂｕｔｅｓ
この権利は、ファイルシステムが基本ファイル属性とデータストリームとを区別するのと同様に、Ｉｔｅｍの基本属性への書き込みアクセスを可能にする。これらの基本属性は、すべてのアイテムの派生元となる基本アイテム内に配置されるのが好ましい。この権利は以下のようにマッピングされる。
ファイル：
(FILE_WRITE_ATTRIBUTES)
フォルダ：
(FILE_WRITE_ATTRIBUTES)
（５）ＷｉｎＦＳＩｔｅｍＷｒｉｔｅ
この権利を使用すると、埋め込まれた関係を介してアイテムにリンクされているアイテムを含むアイテムのすべての要素への書き込みアクセスを実行できるようになる。この権利を使用すると、さらに、埋め込まれた関係を他のアイテムに追加または削除することもできるようになる。この権利は以下のようにマッピングされる。
ファイル：
(FILE_WRITE_DATA)
フォルダ：
(FILE_ADD_FILE)
ストレージプラットフォームのデータストアでは、アイテムとフォルダとの間に違いはなく、アイテムはデータストア内の他のアイテムとの保持Ｒｅｌａｔｉｏｎｓｈｉｐも持つことができる。したがって、ＦＩＬＥ＿ＡＤＤ＿ＳＵＢＤＩＲＥＣＴＯＲＹ（またはＦＩＬＥ＿ＡＰＰＥＮＤ＿ＤＡＴＡ）権利がある場合、アイテムを他のアイテムとのＲｅｌａｔｉｏｎｓｈｉｐｓのソースにすることができる。
（６）ＷｉｎＦＳＩｔｅｍＡｄｄＬｉｎｋ
この権利を使用すると、ストア内のアイテムに保持Ｒｅｌａｔｉｏｎｓｈｉｐを追加することができるようになる。複数の保持Ｒｅｌａｔｉｏｎｓｈｉｐのセキュリティモデルはアイテム上のセキュリティを変更し、それらの変更は階層内の上位のポイントから来る場合にＷＲＩＴＥ＿ＤＡＣをバイパスすることができるので、それとのＲｅｌａｔｉｏｎｓｈｉｐを作成できるようにするためにＷＲＩＴＥ＿ＤＡＣはデスティネーションアイテム上に必要であることに留意されたい。この権利は以下のようにマッピングされる。
ファイル：
(FILE_APPEND_DATA)
フォルダ：
(FILE_ADD_SUBDIRECTORY)
（７）ＷｉｎＦＳＩｔｅｍＤｅｌｅｔｅＬｉｎｋ
この権利により、アイテムに対する保持Ｒｅｌａｔｉｏｎｓｈｉｐを削除する機能は、そのアイテムを削除する権利がプリンシパルに付与されていないとしても使用可能になる。これは、ファイルシステムモデルと整合しており、パージに役立つ。この権利は以下のようにマッピングされる。
ファイル：
(FILE_DELETE_CHILD)−ファイルシステムは、この権利に相当するファイルを持たないが、アイテムは他のアイテムとの保持Ｒｅｌａｔｉｏｎｓｈｉｐを持つという概念はあり、したがって、非フォルダに対しても同様にこの権利を伝えられる。
フォルダ：
(FILE_DELETE_CHILD)
（８）アイテムを削除する権利
アイテムとの最後の保持Ｒｅｌａｔｉｏｎｓｈｉｐが消えると、アイテムは削除される。アイテムを削除するという明示的な概念はない。アイテムとのすべての保持Ｒｅｌａｔｉｏｎｓｈｉｐを削除するが、高水準の機能であってシステムプリミティブではないパージオペレーションがある。
パスを使用して指定されたアイテムのリンクを解除できるのは、（１）そのパスにそった親アイテムがその対象への書き込みアクセスを付与するか、または（２）アイテム自体の標準の権利がＤＥＬＥＴＥを付与するかの２つの条件のうちのいずれか一方が満たされている場合である。最後のＲｅｌａｔｉｏｎｓｈｉｐが削除されると、アイテムはシステムから消える。ＩｔｅｍＩＤを使用して指定されたアイテムのリンクを解除できるのは、アイテム自体の標準の権利がＤＥＬＥＴＥを付与する場合である。
（９）アイテムをコピーする権利
アイテムは、対象がアイテムに対するＷｉｎＦＳＩｔｅｍＲｅａｄおよびデスティネーションフォルダに対するＷｉｎＦＳＩｔｅｍＷｒｉｔｅを付与された場合に、ソースからデスティネーションフォルダにコピーすることができる。
（１０）アイテムを移動する権利
ファイルシステム内のファイル移動は、デスティネーション上でＡＣＬを保持するので、ソースファイルに対するＤＥＬＥＴＥ権利およびデスティネーションディレクトリに対するＦＩＬＥ＿ＡＤＤ＿ＦＩＬＥだけを必要とする。しかし、フラグは、クロスボリューム移動（ｃｒｏｓｓ−ｖｏｌｕｍｅ ｍｏｖｅ）の場合にＣｏｐｙＦｉｌｅの意味を許容できることをアプリケーションに指定させるＭｏｖｅＦｉｌｅＥｘ呼び出し（ＭＯＶＥＦＩＬＥ＿ＣＯＰＹ＿ＡＬＬＯＷＥＤ）で指定することができる。移動するとセキュリティ記述子に何が生じるかについて可能な４つの選択肢がある。
１．ＡＣＬ全体をファイルとともに搬送する−既定のイントラボリューム移動（ｉｎｔｒａ−ｖｏｌｕｍｅ ｍｏｖｅ）の意味。
２．ＡＣＬ全体をファイルとともに搬送し、保護されているというマークをＡＣＬに付ける。
３．デスティネーション間で明示的なＡＣＥだけを搬送し、デスティネーション上で再継承する。
４．何も搬送せず、デスティネーション上で再継承する−既定のインターボリューム移動の意味−ファイルのコピーと同じ。
本発明のセキュリティモデルでは、アプリケーション側でＭＯＶＥＦＩＬＥ＿ＣＯＰＹ＿ＡＬＬＯＷＥＤフラグを指定した場合、インターボリュームとイントラボリュームの両方の場合について第４のオプションが実行される。このフラグが指定されない場合、第２のオプションは、デスティネーションがさらに同じセキュリティ領域（つまり、同じ継承の意味）内にない限り実行される。ストレージプラットフォームレベルの移動では、第４の選択肢も実装し、コピーの場合と同様に、ソース上のＲＥＡＤ＿ＤＡＴＡを必要とする。
（１１）アイテム上のセキュリティポリシーを表示する権利
アイテムのセキュリティは、そのアイテムが標準の権利ＲＥＡＤ＿ＣＯＮＴＲＯＬを対象に付与する場合に表示できる。
（１２）アイテム上のセキュリティポリシーを変更する権利
アイテムのセキュリティは、そのアイテムが標準の権利ＷＲＩＴＥ＿ＤＡＣを対象に付与する場合に変更できる。しかし、データストアは暗黙の継承を提供するので、これは、階層上でのセキュリティの変更方法に密接に関係している。階層のルートがＷＲＩＴＥ＿ＤＡＣを付与する場合、セキュリティポリシーは、階層（またはＤＡＧ）内の特定のアイテムがＷＲＩＴＥ＿ＤＡＣを対象に付与するかどうかに関係なく階層全体で変更されるというのが規則である。
（１３）直接の等価物を持たない権利
本発明の実施形態では、ＦＩＬＥ＿ＥＸＥＣＵＴＥ（ディレクトリのＦＩＬＥ＿ＴＲＡＶＥＲＳＥ）はストレージプラットフォーム内に直接の等価物を持たない。モデルは、Ｗｉｎ３２との互換性のためこれらを保持しているが、それらの権利に基づいてアイテムに対しアクセス決定が下されることはない。ＦＩＬＥ＿ＲＥＡＤ／ＷＲＩＴＥ＿ＥＡの場合のように、データストアアイテムは、拡張属性の概念を持たないため、このビットに対する意味は用意されていない。しかし、このビットは、Ｗｉｎ３２の互換性のために残されている。
３．実装
まったく同じように保護されている領域を定義するすべてのアイテムは、セキュリティテーブル内でそれらに関連付けられたエントリを持つ。セキュリティテーブルは、次のように定義される。
Figure 0004394644
Ｉｔｅｍ Ｉｄｅｎｔｉｔｙエントリは、まったく同じように保護されているセキュリティ領域のルートのアイテム識別である。Ｉｔｅｍ Ｏｒｄｐａｔｈエントリは、まったく同じように保護されているセキュリティ領域のルートに関連付けられているｏｒｄｐａｔｈである。Ｅｘｐｌｉｃｉｔ Ｉｔｅｍ ＡＣＬエントリは、まったく同じように保護されているセキュリティ領域のルートについて定義された明示的ＡＣＬである。場合によっては、これは、例えば、アイテムが異なる領域に属する複数の親を持つため新しいセキュリティ領域が定義される場合に、ＮＵＬＬとすることができる。Ｐａｔｈ ＡＣＬｓエントリは、アイテムにより継承されるＡＣＬの集合であり、Ｒｅｇｉｏｎ ＡＣＬｓエントリは、アイテムに関連付けられているまったく同じように保護されているセキュリティ領域について定義されているＡＣＬの集合である。
与えられたストア内のアイテムに対する有効セキュリティの計算には、このテーブルを利用する。アイテムに関連付けられたセキュリティポリシーを決定するために、アイテムに関連付けられたセキュリティ領域が得られ、その領域に関連付けられたＡＣＬが取り出される。
アイテムに関連付けられたセキュリティポリシーは、明示的なＡＣＬを直接追加するか、または新しいセキュリティ領域を形成することになる保持Ｒｅｌａｔｉｏｎｓｈｉｐを追加することにより間接的に変更されるので、アイテムの有効なセキュリティを決定する上記のアルゴリズムが必ず有効なアルゴリズムであるようにするためセキュリティテーブルは最新状態に維持される。
ストアに対する様々な変更およびセキュリティテーブルを維持する随伴するアルゴリズムは以下の通りである。
ａ）コンテナ内に新しいアイテムを作成する
アイテムがコンテナ内に新たに作成されると、これは、コンテナに関連付けられたすべてのＡＣＬを継承する。新たに作成されたアイテムは、ちょうど１つの親を持つので、その親と同じ領域に属す。したがって、新しいエントリをセキュリティテーブル内に作成する必要はない。
ｂ）明示的なＡＣＬをアイテムに追加する
ＡＣＬがアイテムに追加された場合、これは、与えられたアイテム自体と同じセキュリティ領域に属す包含階層内のすべての子孫に対し新しいセキュリティ領域を定義する。他のセキュリティ領域に属しているが包含階層内の与えられたアイテムの子孫ではないすべてのアイテムについて、セキュリティ領域は、変更されないが、その領域に関連付けられている有効なＡＣＬは、新しいＡＣＬの追加を反映するように変更される。
この新しいセキュリティ領域の導入は、旧いセキュリティ領域と新しく定義されたセキュリティ領域とをまたにかける祖先との複数の保持Ｒｅｌａｔｉｏｎｓｈｉｐｓを持つすべてのアイテムに対しさらに領域定義を行うきっかけとなりうる。このようなすべてのアイテムについて、新しいセキュリティ領域を定義する必要があり、手順が繰り返される。
図２７（ａ）、（ｂ）、および（ｃ）は、新しい明示的なＡＣＬを導入することにより、既存のセキュリティ領域から切り出される新しいまったく同じように保護されているセキュリティ領域を示している。これは、２というマークが付けられているノードにより示される。しかし、この新しい領域を導入した結果、アイテムが複数の保持Ｒｅｌａｔｉｏｎｓｈｉｐを持つことから追加領域３が作成される。
セキュリティテーブルでの以下の一連の更新は、まったく同じように保護されるセキュリティ領域の因数分解を反映する。
ｃ）保持Ｒｅｌａｔｉｏｎｓｈｉｐをアイテムに追加する
保持Ｒｅｌａｔｉｏｎｓｈｉｐがアイテムに追加されると、３つの可能性のうちの１つが生じる。保持Ｒｅｌａｔｉｏｎｓｈｉｐのターゲット、つまり、考察対象のアイテムがセキュリティ領域のルートである場合、その領域に関連付けられる有効なＡＣＬは変更され、セキュリティテーブルにさらに修正を加える必要はない。新しい保持Ｒｅｌａｔｉｏｎｓｈｉｐのソースのセキュリティ領域がアイテムの既存の親のセキュリティ領域と同じである場合、変更は不要である。しかし、アイテムが異なるセキュリティ領域に属する親を持たないようになれば、新しいセキュリティ領域が形成され、与えられたアイテムをセキュリティ領域のルートとして持つ。この変更は、そのアイテムに関連付けられているセキュリティ領域を修正することにより包含階層内のすべてのアイテムに伝搬される。考察対象のアイテムと同じセキュリティ領域に属するすべてのアイテムおよび包含階層内のその子孫は、変更される必要がある。変更が行われた後、複数の保持Ｒｅｌａｔｉｏｎｓｈｉｐを持つすべてのアイテムは、さらに変更が必要かを判定するために調べられなければならない。これらのアイテムのどれかが異なるセキュリティ領域の親を持つ場合には、さらに変更が必要になることがある。
ｄ）保持Ｒｅｌａｔｉｏｎｓｈｉｐをアイテムから削除する
保持Ｒｅｌａｔｉｏｎｓｈｉｐがアイテムから削除された場合、いくつかの条件が満たされていれば、セキュリティ領域をその親領域とともに縮小することが可能である。より正確に言うと、これは、（１）保持Ｒｅｌａｔｉｏｎｓｈｉｐを削除すると１つの親を持つアイテムが生じ、そのアイテムについて明示的なＡＣＬが指定されていない、（２）保持Ｒｅｌａｔｉｏｎｓｈｉｐを削除すると親がすべて同じセキュリティ領域内にあるアイテムが生じ、そのアイテムについて明示的なＡＣＬが定義されていないという条件の下で実行することができる。これらの状況の下で、セキュリティ領域は、親と同じになるようにマーキングすることができる。このマーキングは、セキュリティ領域が縮小される領域に対応するすべてのアイテムに適用する必要がある。
ｅ）明示的なＡＣＬをアイテムから削除する
明示的なＡＣＬがアイテムから削除された場合、その親の領域とともにそのアイテムをルートとするセキュリティ領域を縮小することが可能である。より正確に言うと、これは、明示的なＡＣＬを削除すると包含階層内の親が同じセキュリティ領域に属しているアイテムが生じる場合に実行できる。これらの状況の下で、セキュリティ領域は、親と同じになるようにマーキングすることができ、変更は、セキュリティ領域が縮小される領域に対応するすべてのアイテムに適用される。
ｆ）アイテムに関連付けられているＡＣＬを修正する
このシナリオでは、セキュリティテーブルに新しい追加を行う必要はない。その領域に関連付けられている有効なＡＣＬは更新され、新しいＡＣＬの変更がそれの影響を受けるセキュリティ領域に伝搬される。
Ｆ．通知および変更追跡
本発明の他の態様によれば、ストレージプラットフォームは、データ変更をアプリケーションで追跡できるようにする通知機能を備える。この機能は、主に、揮発性状態を維持するか、またはデータ変更イベントに関するビジネスロジックを実行するアプリケーション向けである。アプリケーションは、アイテム、アイテム拡張、およびアイテム関係に関する通知を登録する。通知は、データ変更がコミットされた後に非同期に送り出される。アプリケーション側では、アイテム、拡張、および関係型さらにオペレーションの種類により、通知をフィルタ処理することができる。
一実施形態により、ストレージプラットフォームＡＰＩ ３２２は、２種類のインターフェースを通知用に用意している。第１に、アプリケーションはアイテム、アイテム拡張、およびアイテム関係への変更によりトリガされた単純データ変更イベントを登録する。第２に、アプリケーションは、アイテム、アイテム拡張、およびアイテム間の関係の集まりを監視する「ウォッチャ」オブジェクトを作成する。ウォッチャオブジェクトの状態は、システム障害の後、またはシステムが長時間オフライン状態になってしまった後に、保存され、再作成されるようにできる。単一の通知で、複数の更新を反映する場合がある。
１．ストレージ変更イベント
この節では、ストレージプラットフォームＡＰＩ ３２２により提供される通知インターフェースのいくつかの使用例を取りあげる。
ａ）イベント
Ｉｔｅｍ、ＩｔｅｍＥｘｔｅｎｓｉｏｎｓ、およびＩｔｅｍＲｅｌａｔｉｏｎｓｈｉｐｓは、データ変更通知の登録のためアプリケーションにより使用されるデータ変更イベントを公開する。以下のコードサンプルは、基本Ｉｔｅｍクラス上のＩｔｅｍＭｏｄｉｆｉｅｄおよびＩｔｅｍＲｅｍｏｖｅｄイベントハンドラの定義を示している。
Figure 0004394644
すべての通知は、変更されたアイテムをデータストアから取り出すのに十分なデータを搬送できる。以下のコードサンプルは、Ｉｔｅｍ、ＩｔｅｍＥｘｔｅｎｓｉｏｎ、またはＩｔｅｍＲｅｌａｔｉｏｎｓｈｉｐ上でイベントを登録する方法を示している。
Figure 0004394644
本発明の実施形態では、ストレージプラットフォームは、最後に通知を配送した以降にそれぞれのアイテムが修正または削除された場合、またはデータストアから最後にフェッチされた以降に新しい登録があった場合にアプリケーションが通知を受けることを保証する。
ｂ）ウォッチャ（Watchers）
本発明の実施形態では、ストレージプラットフォームは、（１）フォルダまたはフォルダ階層、（２）アイテムコンテクスト、または（３）特定のアイテムに関連付けられているオブジェクトを監視するウォッチャクラスを定義する。３つのカテゴリのそれぞれについて、ストレージプラットフォームは、関連付けられているアイテム、アイテム拡張、またはアイテム関係を監視する特定のウォッチャクラスを提供し、例えばストレージプラットフォームは、それぞれのＦｏｌｄｅｒＩｔｅｍＷａｔｃｈｅｒ、ＦｏｌｄｅｒＲｅｌａｔｉｏｎｓｈｉｐＷａｔｃｈｅｒ、およびＦｏｌｄｅｒＥｘｔｅｎｓｉｏｎＷａｔｃｈｅｒクラスを提供する。
ウォッチャを作成するときに、アプリケーションは、事前に存在するアイテム、つまり、アイテム、拡張、または関係の通知を要求することができる。このオプションは、ほとんど、プライベートアイテムキャッシュを維持するアプリケーション用である。要求されない場合、アプリケーションは、ウォッチャオブジェクトが作成された後に生じるすべての更新の通知を受信する。
通知を配送することとともに、ストレージプラットフォームは、「ＷａｔｃｈｅｒＳｔａｔｅ」オブジェクトを供給する。ＷａｔｃｈｅｒＳｔａｔｅをシリアライズして、ディスク上に保存することができる。その後、失敗した後、またはオフラインになってから再接続するときにウォッチャ状態を使用してそれぞれのウォッチャを再作成することができる。新しく再作成されたウォッチャは、未受領確認通知を再生成する。アプリケーションは、通知への参照を供給するそれぞれのウォッチャ状態で「Ｅｘｃｌｕｄｅ」メソッドを呼び出すことにより通知の配送を示す。
ストレージプラットフォームは、ウォッチャ状態の別々のコピーをそれぞれのイベントハンドラに配送する。同じイベントハンドラの後の呼び出しで受信されたウォッチャ状態では、すでに受信されたすべての通知の配送を想定する。
例えば、以下のコードサンプルは、ＦｏｌｄｅｒＩｔｅｍＷａｔｃｈｅｒの定義を示す。
Figure 0004394644
以下のコードサンプルは、フォルダの内容を監視するフォルダウォッチャオブジェクトを作成する方法を示している。ウォッチャは、新しい音楽アイテムが追加されるか、または既存の音楽アイテムが更新されるかまたは削除されたときに、通知、つまり、イベントを生成する。フォルダウォッチャは、フォルダ階層内の特定のフォルダまたはすべてのフォルダを監視する。
Figure 0004394644
２．変更追跡および通知生成メカニズム
ストレージプラットフォームは、データ変更を追跡し、通知を生成する単純ではあるが効率的なメカニズムを備える。クライアントは、データを取り出すために使用されるのと同じ接続で通知を取り出す。このため、セキュリティチェックが大幅に簡素化され、可能なネットワーク構成に対する待ち時間および制約条件が排除される。通知は、ｓｅｌｅｃｔステートメントを発行することにより取り出される。ポーリングを行わないようにするために、クライアントは、データベースエンジン３１４が備える「ｗａｉｔｆｏｒ」機能を使用することができる。図１３は、基本的なストレージプラットフォーム通知概念を示している。このｗａｉｔｆｏｒクエリは、同期して実行される場合、呼び出し側スレッドは、結果が得られるまでブロックされ、非同期に実行される場合、スレッドはブロックされず、結果は用意されれば、別のスレッドで返される。
通知ロックをそれぞれのデータ範囲に設定することにより変更を監視できるので、「ｗａｉｔｆｏｒ」と「ｓｅｌｅｃｔ」の組合せは、特定のデータ範囲に収まるデータ変更を監視するのに魅力的である。これは、多くの共通のストレージプラットフォームシナリオについて成り立つ。個々のアイテムに対する変更は、通知ロックをそれぞれのデータ範囲に設定することにより効率よく監視することができる。フォルダおよびフォルダツリーに対する変更は、通知ロックをパス範囲に設定することにより監視できる。型およびその子型に対する変更は、通知ロックを型範囲に設定することにより監視できる。
一般に、通知の処理には、（１）データ変更または均等検出、（２）サブスクリプションマッチング（subscription matching）、および（３）通知配送の３つの異なるフェーズが関連する。同期通知配送、つまり、データ変更を実行するトランザクションの一部としての通知配送を除き、ストレージプラットフォームは以下の２つの形態の通知配送を実装することができる。
１）即時イベント検出：イベント検出およびサブスクリプションマッチングは、更新トランザクションの一部として実行される。通知は、サブスクライバにより監視されるテーブル内に挿入される。
２）遅延イベント検出：イベント検出およびサブスクリプションマッチングは、更新トランザクションがコミットされた後に実行される。その後、実際のサブスクライバまたは媒介物がイベントを検出し、通知を生成する。
即時イベント検出では、追加コードを更新オペレーションの一部として実行する必要がある。これにより、相対的な状態変更を示すイベントを含む注目するすべてのイベントを取り込むことができる。
遅延イベント検出では、追加コードを更新オペレーションに加える必要がなくなる。イベント検出は、最終的なサブスクライバにより実行される。遅延イベント検出では、当然ながら、イベント検出およびイベント配送をバッチ処理し、データベースエンジン３１４（例えば、ＳＱＬサーバ）のクエリ実行インフラストラクチャにうまく適合する。
遅延イベント検出は、更新オペレーションによって残されたログまたはトレースに依存する。ストレージプラットフォームは、削除されたデータアイテムに対するツームストーンとともに論理的タイムスタンプの集合を維持する。データストアをスキャンし、変更がないか調べるときに、クライアントは、変更を検出するための低ウォーターマークを定義するタイムスタンプおよび重複通知を防止するためのタイムスタンプの集合を供給する。アプリケーションは、その低ウォーターマークにより示される時刻以降に発生したすべての変更の通知を受信する。
コアビューにアクセスできる高度なアプリケーションでは、さらに、プライベートパラメータおよび重複フィルタテーブルを作成することにより潜在的に大きくなりうるアイテムの集合を監視するために必要なＳＱＬステートメントの数を最適化し、低減することができる。リッチビューをサポートしなければならないような特別なニーズのあるアプリケーションでは、利用可能な変更追跡フレームワークを使用してデータ変更を監視し、そのプライベートスナップショットをリフレッシュすることができる。
したがって、一実施形態では、ストレージプラットフォームは、以下でさらに詳しく説明するように、遅延イベント検出アプローチを実装するのが好ましい。
ａ）変更追跡
すべてのアイテム、拡張、およびアイテム関係定義は、一意的な識別子を伝える。変更追跡では、すべてのデータアイテムの作成、更新、および削除時刻を記録する論理的タイムスタンプの集合を維持する。ツームストーンエントリを使用して、削除済みデータアイテムを表す。
アプリケーションではその情報を使用して、アプリケーションが最後にデータストアにアクセスした以降に特定のアイテム、アイテム拡張、またはアイテム関係が新しく追加されたか、更新されたか、または削除されたかどうかを効率よく監視する。以下の実施例は、このメカニズムを例示している。
Figure 0004394644
削除されたすべてのアイテム、アイテム拡張、および関係は、対応するツームストーンテーブル内に記録される。テンプレートを以下に示す。
Figure 0004394644
効率上の理由からストレージプラットフォームは、アイテム、アイテム拡張、関係、およびパス名の大域的テーブルの集合を維持する。これらの大域的ルックアップテーブルは、データ範囲を効率よく監視し、割り当てられているタイムスタンプおよび型情報を取り出すためにアプリケーションによって使用することができる。
ｂ）タイムスタンプ管理
論理的タイムスタンプは、データベースに対し「ローカル」である、つまり、ストレージプラットフォームボリュームである。タイムスタンプは、単調増加の６４ビット値である。単一のタイムスタンプを保持することは、ストレージプラットフォームボリュームに最後に接続した後データ変更が発生したかどうかを検出するのに十分であることが多い。しかし、最も現実的なシナリオでは、重複のチェックのためさらにいくつかのタイムスタンプを保持する必要がある。理由について以下で説明する。
リレーショナルデータベーステーブルは、物理的データ構造の集合、つまり、Ｂ−Ｔｒｅｅ、ヒープなどの上に構築される論理的抽象化である。タイムスタンプを新しく作成されたまたは更新されたレコードに割り当てることは、アトミックアクションではない。そのレコードを基礎をなすデータ構造体内に挿入することは、異なる時間に発生することがありえ、したがって、アプリケーションには、レコードが順不同に来るように見える。
図１４は、２つのトランザクションが両方とも新しいレコードを同じＢ−Ｔｒｅｅ内に挿入することを示している。トランザクションＴ３は、トランザクションＴ２の挿入がスケジュールされる前にレコードを挿入するので、Ｂ−Ｔｒｅｅをスキャンするアプリケーションは、Ｔ２により挿入されたレコードの前にトランザクションＴ３により挿入されたレコードを見る可能性がある。したがって、リーダーは、時刻「１０」まで作成されたすべてのレコードを見たと誤って仮定しうる。この問題を解決するために、データベースエンジン３１４は、すべての更新がコミットし、それぞれの基礎のデータ構造体内に挿入された低ウォーターマークまでを返す関数を提供する。上記の実施例では、返された低ウォーターマークは「５」となり、リーダーはトランザクションＴ２がコミットされる前に開始したと仮定する。データベースエンジン３１４により与えられる低ウォーターマークにより、アプリケーションは、データ変更についてデータベースまたはデータ範囲をスキャンするときにどのアイテムを無視するかを効率よく決定できる。一般に、ＡＣＩＤトランザクションは、非常に短い時間の間続くと想定され、低ウォーターマークは、一番最近に分配されたタイムスタンプに非常に近いと予期される。長く続いているトランザクションが存在する場合、アプリケーションは、重複を検出し破棄するために個々のタイムスタンプを保持していなければならない可能性がある。
ｃ）データ変更検出−イベント検出
データストアのクエリを実行するときに、アプリケーションは低ウォーターマークを取得する。その後、アプリケーションはそのウォーターマークを使用して、作成、更新、または削除タイムスタンプが返された低ウォーターマークよりも大きいエントリがないかデータストアをスキャンする。図１５は、このプロセスを例示している。
重複する通知を防止するために、アプリケーションでは、返された低ウォーターマークよりも大きいタイムスタンプを記憶しておき、それらを使用して重複を除去する。アプリケーションは、セッションレベルの一時テーブルを作成して、重複タイムスタンプの大きな集合を効率よく取り扱う。以下に示すように、ｓｅｌｅｃｔステートメントを発行する前に、アプリケーションは、すでに返されているすべての重複タイムスタンプを挿入し、返された最後の低ウォーターマークよりも古いものを削除する。
Figure 0004394644
Ｇ．同期
本発明の別の態様によれば、ストレージプラットフォームは、（ｉ）ストレージプラットフォーム（それぞれ自データストア３０２を備える）の複数のインスタンスが柔軟な規則の集まりに従ってその内容の部分の同期をとれるようにし、（ｉｉ）本発明のストレージプラットフォームのデータストアと専用プロトコルを実装する他のデータソースとの同期をとるサードパーティ用のインフラストラクチャを備える同期サービス３３０を提供する。
ストレージプラットフォーム間の同期は、参加レプリカのグループのうちで実行される。例えば、図３を参照すると、おそらく異なるコンピュータシステム上で稼働しているであろう、ストレージプラットフォームの他のインスタンスの制御の下で、ストレージプラットフォーム３００のデータストア３０２と他のリモートデータストア３３８との同期をとることが望ましい場合がある。このグループの全体的な帰属関係は、必ずしも、与えられた時刻与えられたレプリカに知られているわけではない。
異なるレプリカは、変更を独立して行うことができる（つまり、同時に）。同期処理のプロセスは、他のレプリカによって行われる変更をすべてのレプリカに気づかせることとして定義される。この同期処理機能は、本質的に、マルチマスターである。
本発明の同期機能では、レプリカは以下のようにできる。
・ 他のレプリカがどの変更を認識するかを決定する。
・ このレプリカが認識しない変更に関する情報を要求する。
・ 他のレプリカが認識しない変更に関する情報を伝達する。
・ ２つの変更がいつ互いに競合するかを決定する。
・ 変更をローカルで適用する。
・ 競合する解決を他のレプリカに伝達し、収束を保証する。
・ 競合する解決に対する指定されたポリシーに基づき競合状態を解決する。
１．ストレージプラットフォームとストレージプラットフォームとの間の同期処理
本発明のストレージプラットフォームの同期処理サービス３３０の主要な適用は、ストレージプラットフォームの複数のインスタンスの同期をとることである（それぞれ、自データストアを有する）。同期処理サービスは、ストレージプラットフォームのスキーマレベルで動作する（データベースエンジン３１４の基礎のテーブルではなく）。したがって、例えば、「Ｓｃｏｐｅｓ」は、後述のように同期を定義するために使用される。
同期処理サービスは、「純変化」の原理に基づいて動作する。同期処理サービスでは、個別のオペレーションを（トランザクション複製などにより）記録し、送信するのではなく、それらのオペレーションの最終結果を送り、それによって、複数のオペレーションの結果を得られた単一の変更に統合することが多い。
同期処理サービスは、一般的にはトランザクション境界を考慮しない。つまり、単一のトランザクションでストレージプラットフォームのデータストアに２つの変更が加えられた場合、それらの変更が他のすべてのレプリカに最小単位として適用されることは保証されない−一方が他方なしで現れることがある。この原理の例外は、同じトランザクションで２つの変更が同じＩｔｅｍに加えられた場合に、それらの変更は送信され、他のレプリカに最小単位として適用されることが保証されるという点である。したがって、Ｉｔｅｍは、同期処理サービスの整合性ユニットである。
ａ）同期（Ｓｙｎｃ）制御アプリケーション
どのアプリケーションも、同期処理サービスに接続し、同期処理オペレーションを開始することができる。そのようなアプリケーションは、同期処理を実行するために必要なすべてのパラメータを用意する（以下のｓｙｎｃプロファイルを参照）。このようなアプリケーションは、本明細書では、同期制御アプリケーション（ＳＣＡ）と呼ばれる。
２つのストレージプラットフォームインスタンスの同期をとる場合、ｓｙｎｃはＳＣＡにより片方の側で開始される。そのＳＣＡは、リモートパートナと同期することをローカル同期処理サービスに通知する。他方の側では、同期処理サービスは、発信側マシンから同期処理サービスにより送られるメッセージによって目覚める。これは、送信先マシン上に存在する永続的構成情報（以下のマッピングを参照）に基づいて応答する。同期処理サービスは、スケジュールに従って実行されるか、またはイベントに対する応答として実行されることが可能である。これらの場合に、スケジュールを実行する同期処理サービスがＳＣＡとなる。
同期処理を有効にするには、２つのステップが実行される必要がある。第１に、スキーマデザイナが適切なｓｙｎｃの意味をストレージプラットフォームスキーマに注釈として入れなければならない（後述のようにＣｈａｎｇｅ Ｕｎｉｔｓを指定する）。第２に、同期処理は、同期処理に関わるストレージプラットフォームのインスタンスを持つすべてのマシン上で適切に構成されなければならない（後述のように）。
ｂ）スキーマ注釈（annotation）
同期処理サービスの基本概念は、Ｃｈａｎｇｅ Ｕｎｉｔの概念である。Ｃｈａｎｇｅ Ｕｎｉｔは、ストレージプラットフォームにより個別に追跡されるスキーマの最小断片である。すべてのＣｈａｎｇｅ Ｕｎｉｔについて、同期処理サービスは、最後のｓｙｎｃ以降に変化したか、変化しなかったかを判別することができる。
スキーマでのＣｈａｎｇｅ Ｕｎｉｔｓの指定は、複数の目的に使用される。第１に、これは、同期処理サービスが回線上でどれだけ混雑しているかを判別する。Ｃｈａｎｇｅ Ｕｎｉｔ内で変更が加えられた場合、同期処理サービスはＣｈａｎｇｅ Ｕｎｉｔのどの部分が変更されたかを認識していないので、Ｃｈａｎｇｅ Ｕｎｉｔ全体が他のレプリカに送信される。第２に、これは、競合検出の精度を決定する。２つの同時変更（これらの用語は、後のセクションで詳しく定義される）が同じ変更ユニットに対し加えられた場合、同期処理サービスは競合の通知を発し、その一方で、同時変更が異なる変更ユニットに加えられた場合、競合の通知は発せず、変更は自動的にマージされる。第３に、これは、システムによって保持されているメタデータの量に強い影響を及ぼす。同期処理サービスのメタデータの多くは、Ｃｈａｎｇｅ Ｕｎｉｔ毎に保持され、そのため、Ｃｈａｎｇｅ Ｕｎｉｔｓを小さくすれば、ｓｙｎｃのオーバーヘッドが大きくなる。
Ｃｈａｎｇｅ Ｕｎｉｔｓを定義するには、正しいトレードオフを見つける必要がある。そのような理由から、同期処理サービスを使用すると、スキーマデザイナはそのプロセスに関与することができる。
一実施形態では、同期処理サービスは、要素よりも大きなＣｈａｎｇｅ Ｕｎｉｔｓをサポートしていない。しかし、スキーマデザイナが要素よりも小さい変更ユニットを指定すること−つまり、要素の複数の属性を１つの独立したＣｈａｎｇｅ Ｕｎｉｔにグループ化すること−はサポートしている。その実施形態では、これは、以下の構文を使用して行われる。
Figure 0004394644
ｃ）同期設定
データの特定の部分の同期を維持したいストレージプラットフォームパートナのグループは、ｓｙｎｃコミュニティと呼ばれる。コミュニティのメンバが同期を維持したい場合、必ずしも、まったく同じ方法でデータを表すわけではない、つまり、ｓｙｎｃパートナは、同期処理をしているデータを変換することができる。
ピアツーピアのシナリオでは、ピアがそのパートナのすべてについて変換マッピングを維持することは実際的ではない。そうする代わりに、同期処理サービスは、「コミュニティフォルダ」を定義するアプローチをとる。コミュニティフォルダは、すべてのコミュニティメンバが同期をとる仮想「共有フォルダ」を表す抽象化である。
この概念は、例を使うと最もよくわかる。Ｊｏｅが複数のコンピュータのＭｙ Ｄｏｃｕｍｅｎｔｓフォルダの同期をとりたい場合、Ｊｏｅは、例えば、ＪｏｅｓＤｏｃｕｍｅｎｔｓというコミュニティフォルダを定義する。次に、すべてのコンピュータ上で、Ｊｏｅは仮想ＪｏｅｓＤｏｃｕｍｅｎｔｓフォルダとローカルのＭｙ Ｄｏｃｕｍｅｎｔｓフォルダとの間のマッピングを構成する。この時点以降、Ｊｏｅのコンピュータが互いに同期した場合、そのローカルアイテムではなく、ＪｏｅｓＤｏｃｕｍｅｎｔｓ内のドキュメントに関してやり取りすることになる。このようにして、すべてのＪｏｅのコンピュータは相手が誰であるかを知らなくても互いを理解しあう−そのコミュニティフォルダが同期コミュニティの共通語となるのである。
同期処理サービスの構成は、（１）ローカルフォルダとコミュニティフォルダとの間のマッピングを定義するステップ、（２）何が同期されるか（例えば、同期する相手、送信すべき部分集合、および受信すべきもの）を決定するｓｙｎｃプロファイルを定義するステップ、および（３）異なるｓｙｎｃプロファイルが実行されるスケジュールを定義する、または手動で実行するステップの３つのステップからなる。
（１）コミュニティフォルダ−マッピング
コミュニティフォルダマッピングは、個々のマシン上にＸＭＬ構成ファイルとして格納される。それぞれのマッピングは、以下のスキーマを持つ。
/mappings/communityFolder
この要素は、このマッピングの対象となるコミュニティフォルダの名前を指定する。名前はフォルダの構文規則に従う。
/mappings/localFolder
この要素は、このマッピングの変換先のローカルフォルダの名前を指定する。名前はフォルダの構文規則に従う。フォルダは、マッピングが有効であるためにすでに存在していなければならない。このフォルダ内のアイテムは、このマッピングに従って同期対象とみなされる。
/mappings/transformations
この要素は、アイテムをコミュニティフォルダからローカルフォルダに、またその逆方向に変換する方法を定義する。存在しないか、または空の場合、変換は実行されない。特に、これは、ＩＤがマッピングされないことを意味する。この構成は、主に、Ｆｏｌｄｅｒのキャッシュを作成する際に使用される。
/mappings/transformations/mapIDs
この要素は、コミュニティＩＤを再利用するのではなく、新しく生成されたローカルＩＤがコミュニティフォルダからマッピングされたアイテムのすべてに割り当てられることを要求する。Ｓｙｎｃ Ｒｕｎｔｉｍｅは、アイテムの変換、逆変換を行うＩＤマッピングを保持する。
/mappings/transformations/localRoot
この要素は、コミュニティフォルダ内のすべてのルートアイテムが指定されたルートの子にされることを要求する。
/mappings/runAs
この要素は、このマッピングに対する要求が処理される際の権限を制御する。存在しない場合、送信者が想定される。
/mappings/runAs/sender
この要素が存在すると、このマッピングへのメッセージの送信者は、偽装され、要求はその信用証明書に従って処理されなければならない。
（２）プロファイル
同期プロファイル（Sync Profile）は、同期をキックオフするために必要なパラメータ一式である。これは、ＳＣＡにより、同期処理を開始するためＳｙｎｃ Ｒｕｎｔｉｍｅに供給される。ストレージプラットフォーム同士の同期をとるための同期プロファイルは、以下の情報を含む。
・ Ｌｏｃａｌ Ｆｏｌｄｅｒ、変更の送り元および送り先として使用される。
・ 同期をとるＲｅｍｏｔｅ Ｆｏｌｄｅｒ名−このＦｏｌｄｅｒは、上で定義された通りにマッピングを使用してリモートパートナからパブリッシュされなければならない。
・ Ｄｉｒｅｃｔｉｏｎ−同期処理サービスは、送信のみ、受信のみ、および送受信同期をサポートする。
・ Ｌｏｃａｌ Ｆｉｌｔｅｒ−リモートパートナに送信するローカル情報を選択する。ローカルフォルダに対するストレージプラットフォームクエリとして表される。
・ Ｒｅｍｏｔｅ Ｆｉｌｔｅｒ−リモートパートナから取り出すリモート情報を選択する−コミュニティフォルダに対するストレージプラットフォームクエリとして表される。
・ Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ−ローカル形式のアイテムの変換方法を定義する。
・ ローカルセキュリティ−リモート終点から取り出された変更がリモート終点（偽装）の許可を得て適用するか、またはローカルで同期を開始したユーザの許可を得て適用するかを指定する。
・ 競合解決ポリシー−競合が拒絶されるか、ログに記録されるか、または自動的に解決されるかを指定する−後者の場合、使用する競合リゾルバとともにそれに対する構成パラメータを指定する。
同期処理サービスは、同期プロファイルの単純構築を可能にするランタイムＣＬＲクラスを提供する。プロファイルは、さらに、格納を簡単に行えるようにＸＭＬファイルとの間のシリアライズも行える（スケジュールと一緒であるのが多い）。しかし、すべてのプロファイルが格納されるストレージプラットフォーム内の標準的な場所はなく、ＳＣＡは、それを永続せずにその場でプロファイルを構築できるため願ってもないものである。同期を開始するためにローカルマッピングを用意する必要がないことに注意されたい。すべての同期情報は、プロファイル内に指定することができる。しかし、マッピングは、リモート側で開始された同期要求に応答するために必要である。
（３）スケジュール
一実施形態では、同期処理サービスは、それ専用のスケジューリングインフラストラクチャを用意しない。その代わりに、このタスクを実行するために他のコンポーネントに頼る−Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムに付属するＷｉｎｄｏｗｓ（登録商標）Ｓｃｈｅｄｕｌｅｒを使用する。同期処理サービスは、ＳＣＡとして動作し、ＸＭＬファイルに保存されている同期プロファイルに基づいて同期をトリガするコマンドラインユーティリティを備える。このユーティリティを使用すると、スケジュールに従って、またはユーザがログオンまたはログオフするなどのイベントへの応答として同期処理を実行するようにＷｉｎｄｏｗｓ（登録商標）Ｓｃｈｅｄｕｌｅｒを非常に簡単に構成できる。
ｄ）競合回避処理（Conflict Handling）
同期処理サービスにおける競合回避処理は、（１）変更適用時に実行される、競合検出−このステップでは、変更が安全に適用可能か判別する、（２）自動競合解決およびログ記録−このステップでは（競合が検出された直後に実行される）、競合を解決できるか自動競合リゾルバに問い合わせがゆき、できなればオプションで競合をログに記録できる、および（３）競合検査および解決−このステップは、何らかの競合がログに記録されている場合に実行され、同期セッションの状況の外部で実行されるが、このときに、ログに記録された競合は解決され、ログから削除されるようにできる−の３つの段階に分けられる。
（１）競合検出
本発明の実施形態では、同期処理サービスは、知識ベースと制約ベースの２種類の競合を検出する。
（ａ）知識ベースの競合
知識ベースの競合は、２つのレプリカが同じＣｈａｎｇｅ Ｕｎｉｔに対し独立の変更を加えたときに発生する。２つの変更は、それらが互いの変更を関知せずに行われる場合に独立して呼び出される−つまり、第１のバージョンは、第２のバージョンについての知識の対象とならず、またその逆もいえる。同期処理サービスは、上述のように、レプリカの知識に基づいてそのようなすべての競合を自動的に検出する。
競合を変更ユニットのバージョン履歴における分岐点と考えると役立つ場合がある。変更ユニットの存続期間中に競合が発生しない場合、そのバージョン履歴は単純連鎖−それぞれの変更は前の変更の後に発生する−である。知識ベースの競合の場合、２つの変更は並行して発生し、そのため、連鎖は分割され、バージョンツリーとなる。
（ｂ）制約ベースの競合
一緒に適用された場合に独立の変更が完全性制約に違反する場合がある。例えば、２つのレプリカが同じディレクトリ内に同じ名前を持つファイルを作成しようとすると、そのような競合が発生するおそれがある。
制約ベースの競合は、２つの独立した変更を伴うが（知識ベースの競合とまったく同様に）、同じ変更ユニットには影響を及ぼさない。むしろ、異なる変更ユニットに影響を及ぼすが、制約がそれらの間に存在する。
同期処理サービスは、変更適用時に制約違反を検出し、制約ベースの競合の通知を自動的に発する。制約ベースの競合を解決するには、通常、制約に違反しないような方法で変更を修正するカスタムコードを必要とするが、同期処理サービスは、そのようなことを行うための汎用メカニズムを備えていない。
（２）競合処理（Conflict Processing）
競合が検出されると、同期処理サービスは、（１）変更を拒絶し、それを送信者に送り返すアクション、（２）競合を競合ログに記録するアクション、または（３）競合を自動的に解決する３つのアクションのうちの１つ（同期プロファイル内の同期イニシエータにより選択される）を実行することができる。
変更が拒絶された場合、同期処理サービスは、変更がレプリカに届かなかったかのように動作する。否定応答が発信者側に送り返される。この解決ポリシーは、主に、競合のログ記録が可能でないヘッドレスレプリカ（ファイルサーバなど）で使用することができる。その代わりに、そのようなレプリカは拒絶することにより競合を処理するように他のレプリカを強制する。
同期イニシエータは、同期プロファイルで競合解決を構成する。同期処理サービスは、以下のようにして単一プロファイル内の複数の競合リゾルバの組合せをサポートする−第１に、どれか１つが成功するまで次々に試みられる競合リゾルバのリストを指定し、第２に、競合リゾルバを競合のタイプに関連付ける、例えば、更新と更新との間の知識ベースの競合を１つのリゾルバに振り向け、他の競合をすべてログに振り向ける。
（ａ）自動競合解決
同期処理サービスは、多数の既定の競合リゾルバを備える。このリストは以下のものを含む。
・ ｌｏｃａｌ−ｗｉｎｓ：ローカルに格納されているデータとの競合がある場合に受け取った変更を破棄する。
・ ｒｅｍｏｔｅ−ｗｉｎｓ：受け取った変更との競合がある場合にローカルデータを破棄する。
・ ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ：変更のタイムスタンプに基づき変更ユニットに従ってｌｏｃａｌ−ｗｉｎｓまたはｒｅｍｏｔｅ−ｗｉｎｓのいずれかを選択する（同期処理サービスは、一般に、クロック値に依存しないことに注意されたい。この競合リゾルバはその規則に対する唯一の例外である）。
・ Ｄｅｔｅｒｍｉｎｉｓｔｉｃ：すべてのレプリカ上で同じであることを保証される方法で勝利者を選択するが、他の方法では意味がない−同期処理サービスの一実施形態では、この機能を実装するためにパートナＩＤの辞書式比較を使用する。
さらに、ＩＳＶは、独自の競合リゾルバを実装し、インストールすることができる。カスタム競合リゾルバは、構成パラメータを受け付けることができ、そのようなパラメータは、同期プロファイルのＣｏｎｆｌｉｃｔ ＲｅｓｏｌｕｔｉｏｎセクションにあるＳＣＡにより指定されなければならない。
競合リゾルバが競合を処理すると、これは、（競合変更の代わりに）実行される必要のあるオペレーションのリストをランタイムに返す。その後、同期処理サービスは、競合ハンドラ側で考慮していた内容を含むようにリモート知識を適切に調整してから、それらのオペレーションを適用する。
解決を適用している間に他の競合が検出される可能性がある。このような場合、新しい競合は、元の処理が再開する前に解決されなければならない。
競合をアイテムのバージョン履歴内の分岐として考えた場合、競合解決は、結合−２つの分岐を組み合わせて１つのポイントを形成すること−であるとみなすことができる。したがって、競合解決は、バージョン履歴をＤＡＧに変える。
（ｂ）競合ログ作成（Conflict Logging）
非常に特殊な競合リゾルバとして、Ｃｏｎｆｌｉｃｔ Ｌｏｇｇｅｒがある。同期処理サービスは、競合を型ＣｏｎｆｌｉｃｔＲｅｃｏｒｄのＩｔｅｍとしてログに記録する。これらの記録は、競合が生じているアイテムに再び関係する（アイテム自体が削除されていない限り）。それぞれの競合記録は、競合を引き起こした受け取った変更、競合のタイプ、更新−更新、更新−削除、削除−更新、挿入−挿入、または制約、および受け取った変更のバージョンとそれを送信するレプリカの知識を含む。ログに記録された競合は、後述のように、検査および解決のために使用できる。
（ｃ）競合の検査および解決
同期処理サービスは、アプリケーション側で競合ログを調べ、その中の競合の解決を提案するためのＡＰＩを備えている。このＡＰＩにより、アプリケーションは、すべての競合、または与えられたＩｔｅｍに関係する競合を列挙することができる。これにより、さらに、そのようなアプリケーションは、ログに記録された競合を解決するために、（１）ｒｅｍｏｔｅ ｗｉｎｓ−ログに記録された変更を受け入れ、競合しているローカルの変更を上書きする、（２）ｌｏｃａｌ ｗｉｎｓ−ログに記録された変更の競合部分を無視する、および（３）ｓｕｇｇｅｓｔ ｎｅｗ ｃｈａｎｇｅ−アプリケーションが、オプションにより、競合を解決するマージを提案する場合、の３つの方法のうちの１つを使用することができる。アプリケーションにより競合が解決された後、同期処理サービスはそれらをログから削除する。
（ｄ）レプリカの収束および競合解決の伝搬
複雑な同期シナリオでは、同じ競合が複数のレプリカで検出される場合がある。このような状況が生じた場合、以下のイベントが発生する。（１）競合が一方のレプリカで解決され、その解決が他方のレプリカに送られるようにすることができるか、または（２）競合が両方のレプリカ上で自動的に解決されるか、または（３）競合が両方のレプリカで手動で解決される（競合検査ＡＰＩを通じて）。
必ず収束するように、同期処理サービスは、競合解決を他のレプリカに転送する。競合を解決する変更がレプリカに届くと、同期処理サービスは、この更新により解決されるログに含まれる競合記録を自動的に見つけ出し、それらを削除する。この意味で、一方のレプリカでの競合解決は他方のすべてのレプリカ上でのバインディングになる。
同じ競合について異なるレプリカにより異なる勝利者が選択された場合、同期処理サービスは競合解決をバインドする原理を適用し、２つの解決のうちの１つを選び、自動的に他方を獲得する。勝利者は、いつでも同じ結果が得られるように保証される決定論的方法で選ばれる（一実施形態ではレプリカＩＤ辞書式比較を使用する）。
同じ競合について異なるレプリカにより異なる「新しい変更」が提案された場合、同期処理サービスは、この新しい競合を特別な競合として取り扱い、Ｃｏｎｆｌｉｃｔ Ｌｏｇｇｅｒを使用して、それが他のレプリカに伝搬しないようにする。そのような状況は、一般に、手動による競合解決において生じる。
２．非ストレージプラットフォームデータストアの同期処理
本発明のストレージプラットフォームの他の態様によれば、ストレージプラットフォームは、ＩＳＶが、ストレージプラットフォームとＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ＡＤ、Ｈｏｔｍａｉｌなどの従来システムとを同期させるＳｙｎｃ Ａｄａｐｔｅｒｓを実装するためのアーキテクチャを備える。Ｓｙｎｃ Ａｄａｐｔｅｒｓは、後述のように、同期処理サービスにより提供される多くのＳｙｎｃ Ｓｅｒｖｉｃｅを利用する。
その名にもかかわらず、Ｓｙｎｃ Ａｄａｐｔｅｒｓは、何らかのストレージプラットフォームアーキテクチャにプラグインとして実装する必要はない。そうしたければ、「ｓｙｎｃ ａｄａｐｔｅｒ」は、単に、変更列挙およびアプリケーションなどのサービスを取得するために同期処理サービスランタイムインターフェースを利用するアプリケーションとすることもできる。
与えられたバックエンドとの同期を他から構成し、実行することを簡単にするために、Ｓｙｎｃ Ａｄａｐｔｅｒ作成者は、上述のように同期プロファイルが与えられた場合に同期処理を実行する標準のＳｙｎｃ Ａｄａｐｔｅｒインターフェースを公開するよう奨励される。このプロファイルで、構成情報をアダプタに伝えるが、アダプタは、その一部をランタイムサービス（例えば、同期をとるＦｏｌｄｅｒ）を制御するＳｙｎｃ Ｒｕｎｔｉｍｅに受け渡す。
ａ）同期処理サービス
同期処理サービスは、多数の同期処理サービスをアダプタ作成者に提供する。このセクションの残り部分では、ストレージプラットフォームが同期処理を実行しているマシンを「クライアント」と呼び、アダプタの通信先の非ストレージプラットフォームバックエンドを「サーバ」と呼ぶと都合がよい。
（１）Ｃｈａｎｇｅ Ｅｎｕｍｅｒａｔｉｏｎ
Ｃｈａｎｇｅ Ｅｎｕｍｅｒａｔｉｏｎを使用すると、同期処理サービスにより保持されている変更追跡データに基づき、同期処理アダプタは、データストアＦｏｌｄｅｒに対しこのパートナとの同期が最後に試みられた以降に発生した変更を簡単に列挙することができる。
変更は、「アンカー」−最後の同期に関する情報を表す隠蔽型構造−という概念に基づいて列挙される。アンカーは、前のセクションで説明されているように、ストレージプラットフォームの知識という形をとる。変更列挙サービスを使用する同期処理アダプタは、「ストアドアンカー」を使用するものと「サプライドアンカー」を使用するものという２つの広いカテゴリに分類される。
この区別は、最後の同期に関する情報が格納されている場所−クライアントか、それともサーバか−に基づく。アダプタはこの情報をクライアント上に格納するのが簡単である場合が多い−バックエンドは、この情報を簡単に格納できない場合が多い。その一方で、複数のクライアントが同じバックエンドと同期をとる場合、この情報をクライアント上に格納するのは非効率であり、場合によっては正しくない−一方のクライアントが他方のクライアントがすでにサーバにプッシュアップしている変更に気づかない。アダプタ側でサーバストアドアンカーを使用したい場合、そのアダプタは、変更列挙時にストレージプラットフォームへ送り返す必要がある。
ストレージプラットフォームがアンカー（ローカルストレージまたはリモートストレージのいずれかの）を保持するために、ストレージプラットフォームに対し、サーバ側で正常に適用された変更を認識させる必要がある。これらの変更およびこれらの変更のみをアンカーに含めることができる。変更列挙の際にＳｙｎｃ Ａｄａｐｔｅｒｓは、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔインターフェースを使用して、正常に適用された変更を報告する。同期の終了時に、サプライドアンカーを使用するアダプタは、新しいアンカー（正常に適用された変更すべてを組み込んだ）を読み込み、それをバックエンドに送る必要がある。
多くの場合、Ａｄａｐｔｅｒｓは、ストレージプラットフォームのデータストア内に挿入するアイテムとともにアダプタ特有のデータを格納する必要がある。このようなデータの一般的な例として、リモートＩＤおよびリモートバージョン（タイムスタンプ）がある。同期処理サービスは、このデータを格納するメカニズムを備えており、Ｃｈａｎｇｅ Ｅｎｕｍｅｒａｔｉｏｎは、返される変更とともにこの付加データを受け取るためのメカニズムを備える。これにより、ほとんどの場合に、アダプタ側がデータベースに対し再度クエリを実行する必要がなくなる。
（２）Ｃｈａｎｇｅ Ａｐｐｌｉｃａｔｉｏｎ
Ｃｈａｎｇｅ Ａｐｐｌｉｃａｔｉｏｎを使用すると、Ｓｙｎｃ Ａｄａｐｔｅｒｓ側でバックエンドから受け取った変更をローカルストレージプラットフォームに適用することができる。アダプタは、変更をストレージプラットフォームスキーマに変換することが期待される。
変更適用の主な機能は、競合を自動的に検出することである。ストレージプラットフォームとストレージプラットフォームとの同期の場合のように、競合は、お互いについての知識なしで２つの重なり合う変更が行われることと定義される。アダプタは、Ｃｈａｎｇｅ Ａｐｐｌｉｃａｔｉｏｎを使用する場合、どの競合検出が実行されるかについてアンカーを指定しなければならない。Ｃｈａｎｇｅ Ａｐｐｌｉｃａｔｉｏｎは、アダプタの知識の対象とならない重なり合うローカル変更が検出された場合に競合の通知を発する。Ｃｈａｎｇｅ Ｅｎｕｍｅｒａｔｉｏｎと同様に、アダプタは、ストアドアンカーまたはサプライドアンカーのいずれかを使用することができる。Ｃｈａｎｇｅ Ａｐｐｌｉｃａｔｉｏｎでは、アダプタ特有のメタデータの効率的格納をサポートする。このようなデータは、アダプタにより、適用される変更に付随させることができ、また同時処理サービスにより格納することも可能である。データは、次の変更列挙のときに返すことができるであろう。
（３）Ｃｏｎｆｌｉｃｔ Ｒｅｓｏｌｕｔｉｏｎ
上述のＣｏｎｆｌｉｃｔ Ｒｅｓｏｌｕｔｉｏｎメカニズム（ログ記録および自動解決オプション）も、同期処理アダプタで利用できる。同期処理アダプタは、変更を適用する場合に競合解決のポリシーを指定することができる。指定した場合、競合は、指定された競合ハンドラに受け渡され、解決されるようにできる（可能ならば）。競合をログに記録することもできる。アダプタは、ローカル変更をバックエンドに適用しようと試みる際に競合を検出する可能性がある。このような場合、アダプタは、それでも、Ｓｙｎｃ Ｒｕｎｔｉｍｅにその競合を受け渡し、ポリシーに従って解決することができる。さらに、同期処理アダプタは、同時処理サービスにより検出された競合が処理のため送り返されるように要求することもできる。これは、バックエンドが競合を格納または解決することができる場合に便利である。
ｂ）アダプタの実装
いくつかの「アダプタ」が単に、ランタイムインターフェースを使用するアプリケーションである場合には、アダプタ側で標準アダプターインターフェースを実装することが奨励される。これらのインターフェースを使用することにより、Ｓｙｎｃ Ｃｏｎｔｒｏｌｌｉｎｇ Ａｐｐｌｉｃａｔｉｏｎｓは、与えられた同期プロファイルに従ってアダプタが同期処理を実行するよう要求し、進行中の同期処理をキャンセルし、進行中の同期に関する進行中報告（完了率）を受け取ることができる。
３．セキュリティ
同期処理サービスは、ストレージプラットフォームにより実装されたセキュリティモデルに導入するものをできるだけ少なくしようとする。同期処理のための新しい権利を定義するのではなく、既存の権利が使用される。特に、
・ データストアのＩｔｅｍを読み込める人は誰でも、そのアイテムへの変更を列挙することができ、
・ データストアのＩｔｅｍに書き込める人は誰でも、そのアイテムに変更を適用することができ、
・ データストアのＩｔｅｍを拡張できる人は誰でも、そのアイテムに同期メタデータを関連付けることができるということである。
同期処理サービスでは、セキュリティで保護された著作権情報を保持しない。ユーザＵによりレプリカＡで変更が加えられ、レプリカＢに転送された場合、変更が元々Ａで（またはＵにより）行われたという事実は失われる。Ｂがこの変更をレプリカＣに転送した場合、これは、Ａの権限ではなくＢの権限の下で実行される。このため、レプリカがアイテムに対し独自の変更を加えることについて信頼されていない場合、他者により加えられた変更を転送することはできないという制限が生じる。
同期処理サービスは、開始されると、Ｓｙｎｃ Ｃｏｎｔｒｏｌｌｉｎｇ Ａｐｐｌｉｃａｔｉｏｎによって実行される。同期処理サービスは、ＳＣＡの識別を偽装し、その識別の下ですべてのオペレーション（ローカルとリモートの両方）を実行する。説明のため、ユーザＵは、ローカル同期処理サービスに、ユーザＵが読み取りアクセス権を持たないアイテムについてリモートストレージプラットフォームから変更を取り出させることはできないことを観察する。
４．管理容易性
レプリカの分散コミュニティの監視は複雑な問題である。同期処理サービスは、「スイープ」アルゴリズムを使用して、レプリカのステータスに関する情報を収集し分配することができる。スイープアルゴリズムの特性は、構成されたすべてのレプリカに関する情報は、最終的に回収されること、および失敗（非応答）レプリカが検出されることを保証する。
このコミュニティ規模の監視情報は、すべてのレプリカで利用可能になっている。監視ツールを、任意に選択されたレプリカで実行し、この監視情報を調べて、管理上の決定を下すことができる。構成変更は、影響を受けるレプリカにおいて直接行われなければならない。
Ｈ．従来のファイルシステムの相互運用性
上述のように、本発明のストレージプラットフォームは、少なくとも一部の実施形態では、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムのなくてはならない一部として具現化されることを意図されている。例えば、本発明のストレージプラットフォームは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ファミリのオペレーティングシステムなどのオペレーティングシステムの重要な一部として具現化されることができる。その適応力において、ストレージプラットフォームＡＰＩは、アプリケーションプログラムがオペレーティングシステムとやり取りするために使用するオペレーティングシステムＡＰＩの一部となる。そのため、ストレージプラットフォームは、アプリケーションプログラムがオペレーティングシステムに関する情報を格納するために使用する手段となり、したがって、ストレージプラットフォームのＩｔｅｍベースのデータモデルは、そのようなオペレーティングシステムの従来のファイルシステムの代替えとなる。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ファミリのオペレーティングシステムで具現化されているように、ストレージプラットフォームでは、そのオペレーティングシステムで実装されているＮＴＦＳファイルシステムを置き換えることも可能である。今のところ、アプリケーションプログラムは、Ｗｉｎｄｏｗｓ（登録商標）ファミリのオペレーティングシステムにより公開されているＷｉｎ３２ ＡＰＩを通じてＮＴＦＳファイルシステムのサービスにアクセスする。
しかし、ＮＴＦＳファイルシステムを本発明のストレージプラットフォームで完全に置き換えるには、既存のＷｉｎ３２ベースのアプリケーションプログラムをコーディングし直す必要があること、またそのようなコーディングし直しは望ましくないことを理解したうえで、本発明のストレージプラットフォームでＮＴＦＳなどの既存のファイルシステムとの何らかの相互運用性を実現することが有益であろう。したがって、本発明の一実施形態では、ストレージプラットフォームにおいて、Ｗｉｎ３２プログラミングモデルに依存するアプリケーションプログラムはストレージプラットフォームのデータストアと従来のＮＴＦＳファイルシステムの両方の内容にアクセスすることができる。この目的のために、ストレージプラットフォームでは、簡単な相互運用性を高めるＷｉｎ３２の命名規則の上位集合となる命名規則を使用する。さらに、ストレージプラットフォームでは、Ｗｉｎ３２ ＡＰＩを通じてストレージプラットフォームボリューム内に格納されているファイルおよびディレクトリのアクセスをサポートする。
１．相互運用性のためのモデル
本発明のこの態様によれば、上述の例示的な実施形態において、ストレージプラットフォームは、非ファイルアイテムおよびファイルアイテムを編成できる１つの名前空間を実装する。このモデルを使用すると、以下の利点が得られる。
１．データストア内のフォルダは、ファイルアイテムおよび非ファイルアイテムの両方を含むことができ、それにより、ファイルおよび図式化されたデータの単一の名前空間を提示できる。さらに、すべてのユーザデータに対する一様なセキュリティ、共有、および管理モデルも実現する。
２．ファイルおよび非ファイルアイテムは両方ともストレージプラットフォームＡＰＩを使用してアクセス可能であり、このアプローチではファイルに対し特別な規則は何も適用されず、アプリケーション開発者がかかわるよりきれいなプログラミングモデルを提示する。
３．すべての名前空間オペレーションは、ストレージプラットフォームを通過し、したがって、同期的に取り扱われる。深いプロパティ格上げ（deep property promotion）（ファイルコンテンツから追い出される）はまだ非同期に発生するが、同期オペレーションではユーザおよびアプリケーションにとってかなり予測可能な環境が得られることに注意することが重要である。
このモデルの結果として、本発明の実施形態では、ストレージプラットフォームのデータストア内にマイグレートされないデータソースに対する検索機能を用意することができない。これは、取り外し可能媒体、リモートサーバ、およびローカルディスク上のファイルを含む。外部ファイルシステム内に常駐するアイテムについてストレージプラットフォーム内のプロキシアイテム（ショートカット＋格上げされたメタデータ）を明らかにする同期アダプタが用意される。プロキシアイテムは、データソースの名前空間階層またはセキュリティに関してファイルを模倣しようとしない。
ファイルと非ファイルコンテンツとの間の名前空間およびプログラミングモデル上に実現される対称性により、時間の経過とともにアプリケーションがファイルシステムからコンテンツをストレージプラットフォームのデータストア内のより構造化されたアイテムにマイグレートするより優れたパスが得られる。ストレージプラットフォームのデータストアでネイティブファイルアイテム型を実現することにより、アプリケーションプログラムは、Ｗｉｎ３２を介してこのデータを操作できる一方でファイルデータをストレージプラットフォーム内に移行することができる。最終的に、アプリケーションプログラムは、ストレージプラットフォームＡＰＩに完全に移行し、ファイルではなくストレージプラットフォームのＩｔｅｍに関してそれらのデータを構造化することが可能になるであろう。
２．データストアの機能
望むレベルの相互運用性を実現するために、一実施形態では、ストレージプラットフォームの以下のデータストア機能が実装される。
ａ）ボリュームではない
ストレージプラットフォームのデータストアは、独立したファイルシステムボリュームとして公開されない。ストレージプラットフォームでは、ＮＴＦＳ上で直接ホスティングされるＦＩＬＥＳＴＲＥＡＭを利用する。そのため、ディスク上フォーマットに変更はなく、それにより、ストレージプラットフォームをボリュームレベルで新しいファイルシステムとして公開する必要がなくなる。
その代わりに、データストア（名前空間）がＮＴＦＳボリュームに対応する形で構築される。名前空間のこの部分を補助するデータベースおよびＦＩＬＥＳＴＲＥＡＭは、ストレージプラットフォームのデータストアが関連付けられるＮＴＦＳボリューム上に配置される。システムボリュームに対応するデータストアも用意される。
ｂ）ストア構造
ストアの構造は、実施例を見ると最もよくわかる。例えば、図１６に例示されているような、ＨｏｍｅＭａｃｈｉｎｅという名前のマシンのシステムボリューム上のディレクトリツリーを考える。本発明のファイルシステム相互運用性機能により、ｃ：＼ドライブに対応して、例えば、「ＷｉｎＦＳＯｎＣ」と呼ばれる、ＵＮＣ共有を介してＷｉｎ３２ ＡＰＩに公開されるストレージプラットフォームのデータストアがある。これにより、ＵＮＣ名＼＼ＨｏｍｅＭａｃｈｉｎｅ＼ＷｉｎＦＳＯｎＣを介して関連付けられたデータストアにアクセスできるようになる。
この実施形態では、ファイルおよび／またはフォルダは、ＮＴＦＳからストレージプラットフォームに明示的にマイグレートする必要がある。したがって、ユーザがストレージプラットフォームに備えられているすべての付加的検索／分類機能を利用するためにＭｙ Ｄｏｃｕｍｅｎｔｓフォルダをストレージプラットフォームのデータストア内に移動したい場合、階層は、図１７に示されているように見えるであろう。これらのフォルダは、この実施例では、実際に移動されることに注意することが重要である。他の注意すべき点として、名前空間はストレージプラットフォーム内に移動され、実際のストリームはＦＩＬＥＳＴＲＥＡＭとリネームされ、適切なポインタがストレージプラットフォーム内で結び付けられることが挙げられる。
ｃ）すべてのファイルがマイグレートされるわけではない
ユーザデータに対応する、またはストレージプラットフォームが備える検索および分類機能を必要とするファイルは、ストレージプラットフォームのデータストアにマイグレートすべき対象候補となる。アプリケーションプログラムとストレージプラットフォームとの互換性の問題を限定するために、本発明のストレージプラットフォームにマイグレートされるファイルの集合は、Ｍｉｃｒｏｓｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムが使用されている状況では、Ｄｏｃｕｍｅｎｔｓ ａｎｄ Ｓｅｔｔｉｎｇｓディレクトリ内のＭｙＤｏｃｕｍｅｎｔｓフォルダ、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（ＩＥ）Ｆａｖｏｒｉｔｅｓ、ＩＥ Ｈｉｓｔｏｒｙ、およびＤｅｓｋｔｏｐ．ｉｎｉファイル内のファイルに限定されるのが好ましい。Ｗｉｎｄｏｗｓ（登録商標）システムファイルのマイグレートは許されないことが好ましい。
ｄ）ＮＴＦＳ名前空間でのストレージプラットフォームファイルへのアクセス
本明細書で説明されている実施形態では、ストレージプラットフォームにマイグレートされたファイルは、実線のファイルストリームがＮＴＦＳに格納されるとしても、ＮＴＦＳ名前空間を介してアクセスされないことが望ましい。こうすることで、多角的な実装から生じる考慮すべきロックおよびセキュリティの複雑な問題が回避される。
ｅ）予期される名前空間／ドライブ文字
ストレージプラットフォーム内のファイルおよびフォルダへのアクセスは、＼＼＜マシン名＞＼＜ＷｉｎｆｓＳｈａｒｅＮａｍｅ＞の形式のＵＮＣ名を介して実行される。オペレーションにドライブ文字を必要とするアプリケーションのクラスについては、ドライブ文字をこのＵＮＣ名にマッピングすることができる。
Ｉ．ストレージプラットフォームＡＰＩ
上述のように、ストレージプラットフォームは、アプリケーションプログラム側で上述のストレージプラットフォームの機能および能力にアクセスし、データストアに格納されているアイテムにアクセスするために使用できるＡＰＩを備える。このセクションでは、本発明のストレージプラットフォームのストレージプラットフォームＡＰＩの一実施形態について説明する。
図１９は、本発明の一実施形態による、ストレージプラットフォームＡＰＩの基本アーキテクチャを例示する。ストレージプラットフォームＡＰＩでは、ＳＱＬＣＩｉｅｎｔ１９００を使用してローカルデータストア３０２とやり取りし、またＳＱＬＣｌｉｅｎｔ１９００を使用してリモートデータストア（例えば、データストア３３８）とやり取りすることができる。ローカルストア３０２は、さらに、ＤＱＰ（分散クエリプロセッサ）を使用するか、または上述のストレージプラットフォーム同期サービス（「Ｓｙｎｃ」）を通じて、リモートデータストア３３８ともやり取りできる。ストレージプラットフォームＡＰＩ３２２は、さらに、データストア通知用のブリッジＡＰＩとして機能し、上述のように、アプリケーションのサブスクリプションを通知エンジン３３２に受け渡し、通知をアプリケーション（例えば、アプリケーション３５０ａ、３５０ｂ、または３５０ｃ）にルーティングする。一実施形態では、ストレージプラットフォームＡＰＩ ３２２は、さらに、Ｍｉｃｒｏｓｏｆｔ ＥｘｃｈａｎｇｅおよびＡＤでデータにアクセスできるように制限された「プロバイダ」アーキテクチャを定義することもできる。
１．概要
本発明のストレージプラットフォームＡＰＩのこの実施形態のデータアクセスメカニズムでは、クエリ、ナビゲーション、アクション、イベントの４つの領域を取り扱う。
クエリ
一実施形態では、ストレージプラットフォームのデータストアは、リレーショナルデータベースエンジン３１４上に実装され、その結果、ＳＱＬ言語の完全な表現力がストレージプラットフォームに内在する。より高い水準のクエリオブジェクトにより、ストアへのクエリを実行する簡素化されたモデルが実現されるが、ストレージの完全な表現力をカプセル化することはできない。
ナビゲーション
ストレージプラットフォームデータモデルは、基礎となるデータベース抽象化の上にリッチな拡張可能型システムを構築する。開発者にとっては、ストレージプラットフォームデータはクモの巣状に巡らされたアイテムである。ストレージプラットフォームＡＰＩを使用することにより、フィルタ処理、関係、フォルダなどを介してアイテムからアイテムへのナビゲーションが可能になる。これは、基本ＳＱＬクエリよりも高い水準の抽象化であり、それと同時に、リッチなフィルタ処理およびナビゲーション機能をおなじみのＣＬＲコーディングパターンとともに使用することができる。
アクション
ストレージプラットフォームＡＰＩは、すべてのアイテムに対する共通アクション−Ｃｒｅａｔｅ、Ｄｅｌｅｔｅ、Ｕｐｄａｔｅ−を公開し、これらは、オブジェクト上のメソッドとして公開される。さらに、ＳｅｎｄＭａｉｌ、ＣｈｅｃｋＦｒｅｅＢｕｓｙなどのドメイン固有のアクションもメソッドとして利用可能である。ＡＰＩフレームワークでは、追加アクションを定義することにより値を加えるためにＩＳＶで使用できる適切に定義されたパターンを使用する。
イベント
ストレージプラットフォーム内のデータは、動的である。ストア内のデータが変更されたときにアプリケーションに反応させるために、このＡＰＩではリッチイベンティング、サブスクリプション、および通知機能を開発者に公開する。
２．命名およびスコープ
名前空間と命名とを区別すると好都合である。名前空間という用語は、通常使用されている用法では、あるシステム内で使用可能なすべての名前の集合を指す。このシステムは、ＸＭＬスキーマ、プログラム、Ｗｅｂ、すべてのｆｔｐサイト（およびそのコンテンツ）の集合などとすることが可能である。命名は、名前空間内の注目するすべてのエンティティに一意的な名前を割り当てるために使用されるプロセスまたはアルゴリズムである。したがって、命名は、名前空間内の与えられたユニットを明確に参照することが望ましいため重要である。したがって、本明細書で使用されているように用語「名前空間」は、ユニバース内のすべてのストレージプラットフォームのインスタンスで使用可能なすべての名前の集合を指す。アイテムは、ストレージプラットフォーム名前空間内の名前付きエンティティである。ＵＮＣ命名規約を使用して、アイテム名の一意性を保証する。ユニバース内のすべてのストレージプラットフォームのデータストアの中のすべてのアイテムは、ＵＮＣ名でアドレス指定することが可能である。
ストレージプラットフォーム名前空間内の最高の組織レベルは、１つのサービスであり、これは単なるストレージプラットフォームのインスタンスである。組織の次のレベルは、ボリュームである。ボリュームは、アイテムの最大の自律的コンテナである。それぞれのストレージプラットフォームのインスタンスは、１つまたは複数のボリュームを含む。ボリューム内にはアイテムがある。アイテムは、ストレージプラットフォーム内のデータアトムである。
現実世界のデータは、ほぼ常に、与えられたドメイン内で意味を持つ何らかのシステムに従って編成される。このようなすべてのデータ編成スキームの基礎にあるのが、われわれのデータのユニバースを複数の名前付きグループに分割するという概念である。上述のように、この概念は、Ｆｏｌｄｅｒの概念によりストレージプラットフォーム内にモデル化される。Ｆｏｌｄｅｒは、特別な型のＩｔｅｍであり、Ｃｏｎｔａｉｎｍｅｎｔ ＦｏｌｄｅｒとＶｉｒｔｕａｌ Ｆｏｌｄｅｒの２種類のＦｏｌｄｅｒがある。
図１８を参照すると、Ｃｏｎｔａｉｎｍｅｎｔ Ｆｏｌｄｅｒは他のＩｔｅｍとの保持Ｒｅｌａｔｉｏｎｓｈｉｐｓを含むアイテムであり、ファイルシステムのフォルダの共通概念の等価物である。それぞれのＩｔｅｍは少なくとも１つの包含フォルダ内に「含まれる」。
Ｖｉｒｔｕａｌ Ｆｏｌｄｅｒは、Ｉｔｅｍのコレクションを編成するより動的な方法であり、Ｉｔｅｍの集合が与えられた単なる名前である−この集合は、クエリにより明示的に列挙されるか、または指定される。Ｖｉｒｔｕａｌ Ｆｏｌｄｅｒは、それ自体、Ｉｔｅｍであり、Ｉｔｅｍの集合との（非保持）Ｒｅｌａｔｉｏｎｓｈｉｐｓを表すものと考えられる。
ときには、包含というより緊密な概念をモデル化する必要があり、例えば、電子メールメッセージ内に埋め込まれたＷｏｒｄドキュメントは、ある意味で、例えば、フォルダ内に格納されたファイルに比べて、コンテナに緊密にバインドされている。この概念は、Ｅｍｂｅｄｄｅｄ Ｉｔｅｍの概念により表される。Ｅｍｂｅｄｄｅｄ Ｉｔｅｍは、他のＩｔｅｍを参照する特別な種類の関係を持ち、参照される側のＩｔｅｍは、包含する側のＩｔｅｍのコンテクスト内でのみバインドまたは他の何らかの方法で操作されうる。
最後に、ストレージプラットフォームは、カテゴリの概念をＩｔｅｍおよびＥｌｅｍｅｎｔｓの分類方法として実現する。ストレージプラットフォーム内のすべてのＩｔｅｍまたはＥｌｅｍｅｎｔは、１つまたは複数のカテゴリと関連付けることができる。カテゴリは、本質的に、Ｉｔｅｍ／Ｅｌｅｍｅｎｔにタグ付けされた単なる名前である。この名前は、検索で使用することができる。ストレージプラットフォームのデータモデルにより、カテゴリの階層を定義することができ、したがって、データをツリー形式で分類することができる。
アイテムの曖昧さのない名前は、３つ組み（＜ｓｅｒｖｉｃｅＮａｍｅ＞，＜ｖｏｌｕｍｅＩＤ＞，＜ＩｔｅｍＩＤ＞）である。いくつかのアイテム（特に、ＦｏｌｄｅｒｓおよびＶｉｒｔｕａｌ Ｆｏｌｄｅｒｓ）は、他のアイテムのコレクションである。これにより、アイテムを識別する代替え手段が得られる（＜ｓｅｒｖｉｃｅＮａｍｅ＞，＜ｖｏｌｕｍｅＩＤ＞，＜ｉｔｅｍＰａｔｈ＞）。
ストレージプラットフォーム名は、サービスコンテクストの概念を含み、サービスコンテクストは、ペア（＜ｖｏｌｕｍｅＮａｍｅ＞，＜ｐａｔｈ＞）にマッピングされる名前である。これは、アイテムまたはアイテムの集合−例えば、フォルダ、仮想フォルダなど−を識別する。サービスコンテクストの概念を使用することにより、ストレージプラットフォーム名前空間内のアイテムに対するＵＮＣ名は、＼＼＜ｓｅｒｖｉｃｅＮａｍｅ＞＼＜ｓｅｒｖｉｃｅＣｏｎｔｅｘｔ＞＼＜ｉｔｅｍＰａｔｈ＞となる。
ユーザは、サービスコンテクストの作成および削除を実行できる。また、それぞれのボリューム内のルートディレクトリは、事前定義されたコンテクストｖｏｌｕｍｅ−ｎａｍｅ＄を持つ。
ＩｔｅｍＣｏｎｔｅｘｔは、指定されたパス内に存続するＩｔｅｍに返される結果を制限することによりクエリ（例えば、Ｆｉｎｄオペレーション）のスコープを設定する。
３．ストレージプラットフォームＡＰＩコンポーネント
図２０は、本発明のこの実施形態による、ストレージプラットフォームＡＰＩの様々なコンポーネントの概略を表している。ストレージプラットフォームＡＰＩは、（１）ストレージプラットフォーム要素およびアイテム型を表す、データクラス２００２、（２）オブジェクト永続性を管理し、サポートクラス２００６を提供する、ランタイムフレームワーク２００４、および（３）ストレージプラットフォームスキーマからＣＬＲクラスを生成するために使用される、ツール２００８の各コンポーネントからなる。
本発明の一態様によれば、設計時に、スキーマ作成者は、ドメインメソッド２０１２のスキーマドキュメント２０１０およびコードをストレージプラットフォームＡＰＩ設計時ツール２００８の集合にサブミットする。これらのツールは、クライアントサイドデータクラス２００２およびストアスキーマ２０１４を生成し、そのスキーマに対応するクラス定義２０１６を格納する。「ドメイン」は、特定のスキーマを指し、例えば、Ｃｏｎｔａｃｔｓスキーマ内のクラスに対するドメインメソッドなどを意味する。これらのデータクラス２００２は、ストレージプラットフォームデータを操作するために、ストレージプラットフォームＡＰＩランタイムフレームワーククラス２００６に呼応して、アプリケーション開発者により実行時に使用される。
本発明のストレージプラットフォームＡＰＩの様々な態様を例示することを目的として、例示的なＣｏｎｔａｃｔｓスキーマに基づき実施例を提示する。この例示的なスキーマの図式表現が図２１Ａおよび２１Ｂに示されている。
４．データクラス
本発明の一態様によれば、ストレージプラットフォームのデータストア内のそれぞれのＩｔｅｍ、Ｉｔｅｍ Ｅｘｔｅｎｓｉｏｎ、およびＥｌｅｍｅｎｔ型は、それぞれのＲｅｌａｔｉｏｎｓｈｉｐとともに、ストレージプラットフォームＡＰＩ内に対応するクラスを持つ。おおざっぱに言うと、その型のフィールドは、そのクラスのフィールドにマッピングされるということである。ストレージプラットフォーム内のそれぞれのアイテム、アイテム拡張、および要素は、ストレージプラットフォームＡＰＩ内の対応するクラスのオブジェクトとして使用することができる。開発者は、それらのオブジェクトに対するクエリ、作成、修正、または削除を行うことができる。
ストレージプラットフォームは、スキーマの初期集合を含む。それぞれのスキーマは、ＩｔｅｍおよびＥｌｅｍｅｎｔ型の集合、およびＲｅｌａｔｉｏｎｓｈｉｐｓの集合を定義する。以下は、これらのスキーマエンティティからデータクラスを生成するアルゴリズムの一実施形態である。
それぞれのスキーマＳについて、
Ｓ内のそれぞれのＩｔｅｍ Ｉについて、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓ．Ｉという名前のクラスが生成される。このクラスは以下のメンバを持つ。
・ 新しいアイテムの初期フォルダおよび名前を指定するために使用されるコンストラクタを含む、オーバーロードされたコンストラクタ。
・ Ｉ内のそれぞれのフィールドのプロパティ。フィールドが多値の場合、プロパティは、対応するＥｌｅｍｅｎｔ型のコレクションになる。
・ フィルタとマッチする複数のアイテムを見つけるオーバーロードされた静的メソッド（例えば、「ＦｉｎｄＡｌｌ」という名前のメソッド）。
・ フィルタとマッチする単一のアイテムを見つけるオーバーロードされた静的メソッド（例えば、「ＦｉｎｄＯｎｅ」という名前のメソッド）。
・ ｉｄを与えられたアイテムを見つける静的メソッド（例えば、「ＦｉｎｄＢｙＩＤ」という名前のメソッド）。
・ ＩｔｅｍＣｏｎｔｅｘｔに関して名前を与えられたアイテムを見つける静的メソッド（例えば、「ＦｉｎｄＢｙＮａｍｅ」という名前のメソッド）。
・ アイテムへの変更を保存するメソッド（例えば、「Ｕｐｄａｔｅ」という名前のメソッド）。
・ アイテムの新しいインスタンスを作成するオーバーロードされた静的なＣｒｅａｔｅメソッド。これらのメソッドを使用することにより、アイテムの初期フォルダを様々な方法で指定することができる。
Ｓ内のそれぞれのＥｌｅｍｅｎｔ Ｅについて、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓ．Ｅという名前のクラスが生成される。このクラスは以下のメンバを持つ。
・ Ｅ内のそれぞれのフィールドのプロパティ。フィールドが多値の場合、プロパティは、対応するＥｌｅｍｅｎｔ型のコレクションになる。
Ｓ内のそれぞれのＥｌｅｍｅｎｔ Ｅについて、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓ．ＥＣｏｌｌｅｃｔｉｏｎという名前のクラスが生成される。このクラスは、強く型付けされているコレクションクラスについての一般的な．ＮＥＴ Ｆｒａｍｅｗｏｒｋガイドラインに従う。Ｒｅｌａｔｉｏｎｓｈｉｐベースの要素型について、このクラスは、さらに、以下のメンバも含む。
・ コレクションがソースロール内に出現するアイテムを暗黙のうちに含むフィルタにマッチする複数のＩｔｅｍオブジェクトを見つけるオーバーロードされたメソッド。これらのオーバーロードは、Ｉｔｅｍ子型に基づいてフィルタ処理を行えるものを含む（例えば、「ＦｉｎｄＡｌｌＴａｒｇｅｔＩｔｅｍ」という名前のメソッド）。
・ コレクションがソースロール内に出現するアイテムを暗黙のうちに含むフィルタにマッチする単一のＩｔｅｍオブジェクトを見つけるオーバーロードされたメソッド。これらのオーバーロードは、Ｉｔｅｍ子型に基づいてフィルタ処理を行えるものを含む（例えば、「ＦｉｎｄＯｎｅＴａｒｇｅｔＩｔｅｍ」という名前のメソッド）。
・ コレクションがソースロール内に出現するアイテムを暗黙のうちに含むフィルタにマッチするネストされた要素型のオブジェクトを見つけるオーバーロードされたメソッド（例えば、「ＦｉｎｄＡｌｌＲｅｌａｔｉｏｎｓｈｉｐｓ」という名前のメソッド）。
・ コレクションがソースロール内に出現するアイテムを暗黙のうちに含むフィルタにマッチするネストされた要素型のオブジェクトを見つけるオーバーロードされたメソッド（例えば、「ＦｉｎｄＡｌＩＲｅｌａｔｉｏｎｓｈｉｐｓＦｏｒＴａｒｇｅｔ」という名前のメソッド）。
・ コレクションがソースロール内に出現するアイテムを暗黙のうちに含むフィルタにマッチするネストされた要素型の単一オブジェクトを見つけるオーバーロードされたメソッド（例えば、「ＦｉｎｄＯｎｅＲｅｌａｔｉｏｎｓｈｉｐ」という名前のメソッド）。
・ コレクションがソースロール内に出現するアイテムを暗黙のうちに含むフィルタにマッチするネストされた要素型の単一オブジェクトを見つけるオーバーロードされたメソッド（例えば、「ＦｉｎｄＯｎｅＲｅｌａｔｉｏｎｓｈｉｐＦｏｒＴａｒｇｅｔ」という名前のメソッド）。
Ｓ内のＲｅｌａｔｉｏｎｓｈｉｐ Ｒについて、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓ．Ｒという名前のクラスが生成される。このクラスは、一方または両方の関係ロールで１つの終点フィールドを指定するかどうかに応じて、１つまたは２つのサブクラスを持つ。
クラスは、さらに、作成されたそれぞれのＩｔｅｍ Ｅｘｔｅｎｓｉｏｎについてもこのようにして生成される。
データクラスは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．＜ｓｃｈｅｍａＮａｍｅ＞名前空間内に存在するが、ただし、＜ｓｃｈｅｍａＮａｍｅ＞は、Ｃｏｎｔａｃｔｓ、Ｆｉｌｅｓなどの対応するスキーマの名前である。例えば、Ｃｏｎｔａｃｔｓスキーマに対応するすべてのクラスは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｎｔａｃｔｓ名前空間内にある。
例えば、図２１Ａおよび２１Ｂを参照すると、Ｃｏｎｔａｃｔｓスキーマにより、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｎｔａｃｔ名前空間に含まれる以下のクラスが得られることがわかる。
・ Ｉｔｅｍ：Ｉｔｅｍ、Ｆｏｌｄｅｒ、ＷｅｌｌＫｎｏｗｎＦｏｌｄｅｒ、ＬｏｃａｌＭａｃｈｉｎｅＤａｔａＦｏｌｄｅｒ、ＵｓｅｒＤａｔａＦｏｌｄｅｒ、Ｐｒｉｎｃｉｐａｌ、Ｓｅｒｖｉｃｅ、ＧｒｏｕｐＳｅｒｖｉｃｅ、ＰｅｒｓｏｎＳｅｒｖｉｃｅ、ＰｒｅｓｅｎｃｅＳｅｒｖｉｃｅ、ＣｏｎｔａｃｔＳｅｒｖｉｃｅ、ＡＤＳｅｒｖｉｃｅ、Ｐｅｒｓｏｎ、Ｕｓｅｒ、Ｇｒｏｕｐ、Ｏｒｇａｎｉｚａｔｉｏｎ、ＨｏｕｓｅＨｏｌｄ
・ Ｅｌｅｍｅｎｔｓ：ＮｅｓｔｅｄＥｌｅｍｅｎｔＢａｓｅ、ＮｅｓｔｅｄＥｌｅｍｅｎｔ、ＩｄｅｎｔｉｔｙＫｅｙ、ＳｅｃｕｒｉｔｙＩＤ、ＥＡｄｄｒｅｓｓ、ＣｏｎｔａｃｔＥＡｄｄｒｅｓｓ、ＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒ、ＳＭＴＰＥＡｄｄｒｅｓｓ、ＩｎｓｔａｎｔＭｅｓｓａｇｉｎｇＡｄｄｒｅｓｓ、Ｔｅｍｐｌａｔｅ、Ｐｒｏｆｉｌｅ、ＦｕｌｌＮａｍｅ、ＦａｍｉｌｙＥｖｅｎｔ、ＢａｓｉｃＰｒｅｓｅｎｃｅ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｒｅｓｅｎｃｅ、Ｒｅｌａｔｉｏｎｓｈｉｐ、ＴｅｍｐｌａｔｅＲｅｌａｔｉｏｎｓｈｉｐ、ＬｏｃａｔｉｏｎＲｅｌａｔｉｏｎｓｈｉｐ、ＦａｍｉｌｙＥｖｅｎｔＬｏｃａｔｉｏｎＲｅｌａｔｉｏｎｓｈｉｐ、ＨｏｕｓｅＨｏｌｄＬｏｃａｔｉｏｎＲｅｌａｔｉｏｎｓｈｉｐ、ＲｏｌｅＯｃｃｕｐａｎｃｙ、ＥｍｐｌｏｙｅｅＤａｔａ、ＧｒｏｕｐＭｅｍｂｅｒＳｈｉｐ、ＯｒｇａｎｉｚａｔｉｏｎＬｏｃａｔｉｏｎＲｅｌａｔｉｏｎｓｈｉｐ、ＨｏｕｓｅＨｏｌｄＭｅｍｂｅｒＤａｔａ、ＦａｍｉｌｙＤａｔａ、ＳｐｏｕｓｅＤａｔａ、ＣｈｉｌｄＤａｔａ
さらに例えば、Ｃｏｎｔａｃｔｓスキーマで定義されているような、Ｐｅｒｓｏｎ型の詳細構造体は、以下のＸＭＬで示されている。
Figure 0004394644
この型により、以下のクラスが得られる（パブリックメンバのみが示されている）。
Figure 0004394644
Figure 0004394644
さらに他の実施例では、Ｃｏｎｔａｃｔｓスキーマで定義されているような、ＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒ型の詳細構造体は、以下のＸＭＬで示されている。
Figure 0004394644
この型により、以下のクラスが得られる（パブリックメンバのみが示されている）。
Figure 0004394644
与えられたスキーマから生じるクラスの階層は、直接、そのスキーマ内の型の階層を反映する。例えば、Ｃｏｎｔａｃｔｓスキーマで定義されているＩｔｅｍ型を考察する（図２１Ａおよび図２１Ｂを参照）。ストレージプラットフォームＡＰＩにおいてこれに対応するクラス階層は以下の通りであろう。
Figure 0004394644
さらに他のスキーマ、つまりシステム内のすべてのオーディオ／ビデオ媒体（リッピングされたオーディオファイル、オーディオＣＤ、ＤＶＤ、ホームビデオなど）を表すことができるスキーマにより、ユーザ／アプリケーションは様々な種類のオーディオ／ビデオ媒体の格納、編成、検索、および操作を行うことができる。この基本媒体ドキュメントスキーマは、任意の媒体を表せる十分な汎用性を持ち、この基本スキーマの拡張は、オーディオおよびビデオ媒体について別々にドメイン特有のプロパティを扱うように設計されている。このスキーマ、および他の多くのものは、Ｃｏｒｅ Ｓｃｈｅｍａの下で直接的または間接的に動作するように想定されている。
５．ランタイムフレームワーク
基本ストレージプラットフォームＡＰＩプログラミングモデルはオブジェクト永続性である。アプリケーションプログラム（または「アプリケーション」）は、ストア上で検索を実行し、ストア内のデータを表すオブジェクトを取り出す。アプリケーションは、取り出されたオブジェクトを修正するか、または新しいオブジェクトを作成し、その後、その変更をストア内に伝搬させる。このプロセスは、ＩｔｅｍＣｏｎｔｅｘｔオブジェクトにより管理される。検索は、ＩｔｅｍＳｅａｒｃｈｅｒオブジェクトを使用して実行され、検索結果は、ＦｉｎｄＲｅｓｕｌｔオブジェクトを介してアクセス可能である。
ａ）ランタイムフレームワーククラス
ストレージプラットフォームＡＰＩの発明の他の態様によれば、ランタイムフレームワークは、データクラスのオペレーションをサポートする多数のクラスを実装する。これらのフレームワーククラスは、データクラスに対するビヘイビアの共通の集合を定義し、データクラスとあわせて、ストレージプラットフォームＡＰＩの基本プログラミングモデルを実現する。ランタイムフレームワーク内のクラスは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ名前空間に属す。この実施形態では、フレームワーククラスは、主要クラスとしてＩｔｅｍＣｏｎｔｅｘｔ、ＩｔｅｍＳｅａｒｃｈｅｒ、およびＦｉｎｄＲｅｓｕｌｔを含む。他の小さなクラス、ｅｎｕｍ値、およびデリゲートも提供することができる。
（１）ＩｔｅｍＣｏｎｔｅｘｔ
ＩｔｅｍＣｏｎｔｅｘｔオブジェクトは、（ｉ）アプリケーションプログラムで検索したいアイテムドメインの集合を表し、（ｉｉ）ストレージプラットフォームから取り出されたデータの状態を表すそれぞれのオブジェクトの状態情報を保持し、（ｉｉｉ）ストレージプラットフォームとやり取りするときに使用されるトランザクションおよびストレージプラットフォームと相互運用可能なファイルシステムを管理する。
ＩｔｅｍＣｏｎｔｅｘｔは、オブジェクト永続性エンジンとして、以下のサービスを提供する。
１．ストアから読み込まれたデータを複数のオブジェクト内に逆シリアライズする。
２．オブジェクトＩＤを保持する（アイテムが与えられた場合にそのアイテムがクエリの結果に何回含まれていようと同じオブジェクトを使用してそのアイテムを表す）。
３．オブジェクト状態を追跡する。
ＩｔｅｍＣｏｎｔｅｘｔは、さらに、ストレージプラットフォームに固有の多数のサービスを実行する。
１．変更を永続するために必要なストレージプラットフォーム更新グラムオペレーションを生成し、実行する。
２．必要に応じて複数のデータストアへの接続を作成し、参照関係の継ぎ目のないナビゲーションを可能にし、複数ドメイン検索から取り出されたオブジェクトを修正し、保存するようにできる。
３．ファイルで裏付けされたアイテムは、そのアイテムを表す（複数の）オブジェクトへの変更が保存されるときに適切に更新されることを保証する。
４．複数のストレージプラットフォーム接続にまたがるトランザクション、およびファイルで裏付けされたアイテム内に格納されているデータおよびファイルストリームプロパティを更新するときには、トランザクションが行われるファイルシステムを管理する。
５．ストレージプラットフォームの関係の意味、ファイルで裏付けされたアイテム、およびストリーム型付けプロパティを考慮するアイテム作成、コピー、移動、および削除オペレーションを実行する。
付録Ａに、一実施形態による、ＩｔｅｍＣｏｎｔｅｘｔクラスのソースコードリスティングを掲載する。
（２）ＩｔｅｍＳｅａｒｃｈｅｒ
ＩｔｅｍＳｅａｒｃｈｅｒクラスは、単純な検索をサポートし、Ｉｔｅｍオブジェクト全体、Ｉｔｅｍオブジェクトのストリーム、またはＩｔｅｍから射影された値のストリームを返す。ＩｔｅｍＳｅａｒｃｈｅｒは、これらすべてに共通のコア機能、つまりターゲット型およびそのターゲット型に適用されるパラメータ化されたフィルタの概念をカプセル化したものである。また、ＩｔｅｍＳｅａｒｃｈｅｒを使用することにより、同じ検索が複数の型で実行される場合にサーチャーを、最適化として、プリコンパイルする、つまり準備しておくことができる。付録Ｂには、一実施形態による、ＩｔｅｍＳｅａｒｃｈｅｒクラスおよび複数の密接に関係するクラスのソースコードリスティングを掲載する。
（ａ）ターゲット型
検索ターゲット型は、ＩｔｅｍＳｅａｒｃｈｅｒを構築するときに設定される。ターゲット型は、データストアによりクエリ可能なエクステントにマッピングされる。特に、これは、スキーマ化されたビューとともにアイテム、関係、およびアイテム拡張型にマッピングされるＣＬＲ型である。
ＩｔｅｍＣｏｎｔｅｘｔ．ＧｅｔＳｅａｒｃｈｅｒメソッドを使用してサーチャーを取り出す場合、サーチャーのターゲット型は、パラメータとして指定される。アイテム、関係、またはアイテム拡張型（Ｐｅｒｓｏｎ．ＧｅｔＳｅａｒｃｈｅｒ）に対し静的なＧｅｔＳｅａｒｃｈｅｒメソッドが呼び出される場合、ターゲット型は、そのアイテム、関係、またはアイテム拡張型である。
ＩｔｅｍＳｅａｒｃｈｅｒで与えられる検索式（例えば、「ｓｅａｒｃｈ ｆｉｌｔｅｒ ａｎｄ ｔｈｒｏｕｇｈ ｆｉｎｄ」オプションまたは射影定義）は、常に、その検索ターゲット型に関係する。これらの式は、ターゲット型のプロパティ（ネストされた要素のプロパティを含む）を指定することができ、また他のところで説明されているような関係およびアイテム拡張への結合を指定することができる。
検索ターゲット型は、読み取り専用プロパティ（例えば、ＩｔｅｍＳｅａｒｃｈｅｒ．Ｔｙｐｅプロパティ）を介して使用可能にされる。
（ｂ）フィルタ
ＩｔｅｍＳｅａｒｃｈｅｒは、検索で使用されるフィルタを定義するフィルタを指定するプロパティ（例えば、ＳｅａｒｃｈＥｘｐｒｅｓｓｉｏｎオブジェクトのコレクションとして「Ｆｉｌｔｅｒｓ」という名前が付けられているプロパティ）を含む。このコレクション内のすべてのフィルタは、検索が実行されるときに、論理および演算子を使用して結合される。フィルタは、パラメータ参照を含むことができる。パラメータ値は、Ｐａｒａｍｅｔｅｒｓプロパティを通じて指定される。
（ｃ）検索の準備
同じ検索が、場合によってはパラメータ変更のみで、繰り返し実行される状況では、検索をプリコンパイルする、つまり準備しておくことにより、パフォーマンスをある程度改善することが可能である。これは、ＩｔｅｍＳｅａｒｃｈｅｒ上のｐｒｅｐａｒｅメソッドの集合で実行される（例えば、たぶん「ＰｒｅｐａｒｅＦｉｎｄ」という名前の１つまたは複数のＩｔｅｍを返すＦｉｎｄを準備するメソッド、およびたぶん「ＰｒｅｐａｒｅＰｒｏｊｅｃｔ」という名前の射影を返すＦｉｎｄを準備するメソッド）。例えば、次のようである。
Figure 0004394644
（ｄ）検索オプション
単純検索に適用することができるオプションは多数ある。これらは、例えば、ＦｉｎｄＯｐｔｉｏｎｓオブジェクトで指定し、Ｆｉｎｄメソッドに渡すことができる。例えば、次のようである。
Figure 0004394644
都合のよいことに、並べ替えオプションも、Ｆｉｎｄメソッドに直接渡すことができる。
Figure 0004394644
ＤｅｌａｙＬｏａｄオプションは、検索結果が取り出されるときに大きなバイナリプロパティの値がロードされるか、または参照されるまでロードが遅らされるかを決定する。ＭａｘＲｅｓｕｌｔｓオプションは、返される結果の最大数を決定する。これは、ＳＱＬクエリでＴＯＰを指定することに相当する。並べ替えとともに使用するのが最も多い。
一連のＳｏｒｔＯｐｔｉｏｎオブジェクトを指定することができる（例えば、ＦｉｎｄＯｐｔｉｏｎｓ．ＳｏｒｔＯｐｔｉｏｎｓプロパティを使用する）。検索結果は、第１のＳｏｒｔＯｐｔｉｏｎオブジェクトにより指定された通りに並べ替えられ、その後、第２のＳｏｒｔＯｐｔｉｏｎオブジェクトにより指定された通りに並べ替えられ、というように続く。ＳｏｒｔＯｐｔｉｏｎでは、並べ替えに使用されるプロパティを示す検索式を指定する。この式は、以下のうちの１つを指定する。
１．検索ターゲット型のスカラープロパティ、
２．単一値プロパティをトラバースすることにより検索ターゲット型から到達可能なネストされた要素内のスカラープロパティ、または
３．有効な引数を持つ集計関数の結果（例えば、多値プロパティまたは関係をトラバースすることにより検索ターゲット型から到達可能なネストされた要素内のスカラープロパティに適用されるＭａｘ）。
例えば、検索ターゲット型がＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｎｔａｃｔ．Ｐｅｒｓｏｎであると仮定すると、
１．「Birthdate」−有効、ｂｉｒｔｈｄａｔｅはＰｅｒｓｏｎ型のスカラープロパティである。
２．「PersonalNames.Surname」−無効、ＰｅｒｓｏｎａｌＮａｍｅｓは多値プロパティであり、集計関数は使用されていない。
３．「Count(PersonalNames)」−有効、ＰｅｒｓｏｎａｌＮａｍｅｓのカウント。
４．「Case(Contact.MemberOfHousehold).Household.HouseholdEAddresses.StartDate」−無効、集計関数なしで関係および多値プロパティを使用する。
５．「Max(Cast(Contact.MemberOfHousehold).Household.HouseholdEAddresses.StartDate)」−有効、一番最近の家庭の電子メールアドレス開始日。
（３）アイテム結果ストリーム（「ＦｉｎｄＲｅｓｕｌｔ」）
ＩｔｅｍＳｅａｒｃｈｅｒは（例えば、ＦｉｎｄＡｌｌメソッドを通じて）、検索（例えば、「ＦｉｎｄＲｅｓｕｌｔ」オブジェクト）により返されるオブジェクトにアクセスするために使用することができるオブジェクトを返す。付録Ｃには、一実施形態による、ＦｉｎｄＲｅｓｕｌｔクラスおよび複数の密接に関係するクラスのソースコードリスティングを掲載する。
ＦｉｎｄＲｅｓｕｌｔオブジェクトから結果を得るには、ＩＯｂｊｅｃｔＲｅａｄｅｒ（およびＩＡｓｙｎｃＯｂｊｅｃｔＲｅａｄｅｒ）により定義されたリーダーパターンを使用することと、ＩＥｎｕｍｅｒａｂｌｅおよびＩＥｎｕｍｅｒａｔｏｒにより定義されたような列挙子パターンを使用することの２つ異なる方法がある。列挙子パターンは、ＣＬＲでは標準であり、Ｃ＃のｆｏｒｅａｃｈのような言語構文をサポートする。例えば、次のようである。
Figure 0004394644
リーダーパターンがサポートされているのは、これにより、場合によってはデータコピーをなくすことで結果の処理効率を高めることができるからである。例えば、次のようである。
Figure 0004394644
さらに、リーダーパターンは、非同期オペレーションをサポートする。
Figure 0004394644
この実施形態では、必要なくなったらＦｉｎｄＲｅｓｕｌｔを閉じなければならない。これは、Ｃｌｏｓｅメソッドを呼び出すか、またはステートメントを使用するＣ＃などの言語構文を使用することにより実行できる。例えば、次のようである。
Figure 0004394644
ｂ）動作中のランタイムフレームワーク
図２２は、動作中のランタイムフレームワークを例示している。ランタイムフレームワークは以下のように動作する。
１．アプリケーション３５０ａ、３５０ｂ、または３５０ｃは、ストレージプラットフォーム内のアイテムにバインドする。
２．フレームワーク２００４は、バインドされたアイテムに対応するＩｔｅｍＣｏｎｔｅｘｔオブジェクト２２０２を作成し、アプリケーションに返す。
３．アプリケーションは、このＩｔｅｍＣｏｎｔｅｘｔ上でＦｉｎｄをサブミットして、Ｉｔｅｍのコレクションを取得し、返されるコレクションは、概念上オブジェクトグラフ２２０４となる（関係により）。
４．アプリケーションは、データを変更、削除、および挿入する。
５．アプリケーションは、Ｕｐｄａｔｅ（）メソッドを呼び出して変更を保存する。
ｃ）共通プログラミングパターン
この節では、ストレージプラットフォームＡＰＩフレームワーククラスを使用してデータストア内のアイテムを操作する方法の様々な実施例を取りあげる。
（１）ＩｔｅｍＣｏｎｔｅｘｔオブジェクトを開く、閉じる
アプリケーションは、例えば、静的なＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎを呼び出し、ＩｔｅｍＣｏｎｔｅｘｔに関連付けられるアイテムドメインを識別する１つまたは複数のパスを供給することにより、データストアを対話操作するために使用するＩｔｅｍＣｏｎｔｅｘｔオブジェクトを取得する。アイテムドメインは、ＩｔｅｍＣｏｎｔｅｘｔを使用して実行される検索をスコープに設定し、そのドメインアイテムおよびそのアイテムに含まれるアイテムのみが検索対象になるようにする。実施例は、以下の通りである。
ローカルコンピュータ上のＤｅｆａｕｌｔＳｔｏｒｅストレージプラットフォーム共有を使用してＩｔｅｍＣｏｎｔｅｘｔを開く
Figure 0004394644
 与えられたストレージプラットフォーム共有を使用してＩｔｅｍＣｏｎｔｅｘｔを開く
Figure 0004394644
 ストレージプラットフォーム共有の下のアイテムを使用してＩｔｅｍＣｏｎｔｅｘｔを開く
Figure 0004394644
 複数のアイテムドメインを使用してＩｔｅｍＣｏｎｔｅｘｔを開く
Figure 0004394644
ＩｔｅｍＣｏｎｔｅｘｔは、必要なくなったら、閉じなければならない。
ＩｔｅｍＣｏｎｔｅｘｔを明示的に閉じる
Figure 0004394644
 ＩｔｅｍＣｏｎｔｅｘｔを使用してｕｓｉｎｇステートメントを閉じる
Figure 0004394644
（２）オブジェクトの検索
本発明の他の態様によれば、ストレージプラットフォームＡＰＩは、アプリケーションプログラマが基礎のデータベースエンジンのクエリ言語の詳細を気にせずに、データストア内のアイテムの様々なプロパティに基づいて、クエリを形成するために使用できるようにする簡略化されたクエリモデルを備える。
アプリケーションは、ＩｔｅｍＣｏｎｔｅｘｔ．ＧｅｔＳｅａｒｃｈｅｒメソッドによって返されるＩｔｅｍＳｅａｒｃｈｅｒオブジェクトを使用してＩｔｅｍＣｏｎｔｅｘｔが開かれたときに指定されたドメイン間で検索を実行することができる。検索結果にアクセスするには、ＦｉｎｄＲｅｓｕｌｔオブジェクトを使用する。以下の実施例では以下の宣言を仮定する。
Figure 0004394644
基本検索パターンは、ＧｅｔＳｅａｒｃｈｅｒメソッドを呼び出すことによりＩｔｅｍＣｏｎｔｅｘｔから取り出されたＩｔｅｍＳｅａｒｃｈｅｒオブジェクトを使用することを伴う。
与えられた型のすべてのアイテムを検索する
Figure 0004394644
 フィルタ条件を満たす与えられた型のアイテムを検索する
Figure 0004394644
 フィルタ文字列内でパラメータを使用する
Figure 0004394644
 与えられた型を持ち、フィルタ条件を満たす関係を検索する
Figure 0004394644
 与えられた型を持ち、フィルタ条件を満たす関係を持つアイテムを検索する
Figure 0004394644
 与えられた型を持ち、フィルタ条件を満たすアイテム拡張を検索する
Figure 0004394644
 与えられた型を持ち、フィルタ条件を満たすアイテム拡張を持つアイテムを検索する
Figure 0004394644
（ａ）検索オプション
検索を実行する際に、並べ替え、遅延ロード、および結果の数の制限を含む、様々なオプションを指定することができる。
検索結果を並べ替える
Figure 0004394644
 結果カウントを制限する
Figure 0004394644
（ｂ）ＦｉｎｄＯｎｅおよびＦｉｎｄＯｎｌｙ
ときには第１の結果のみを取り出すことが有用な場合があり、特に並べ替え条件を指定する場合である。さらに、ある種の検索は、ただ１つのオブジェクト返すことが予期され、オブジェクトをまったく返さないことは予期されない。
１つのオブジェクトを検索する
Figure 0004394644
 常に存在することが予期される単一オブジェクトを検索する
Figure 0004394644
（ｃ）ＩｔｅｍＣｏｎｔｅｘｔのショートカットを検索する
単純検索の実行をできる限り簡単にするＩｔｅｍＣｏｎｔｅｘｔ上のショートカットメソッドも多数ある。
ＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＡｌｌショートカットを使用して検索する
Figure 0004394644
 ＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＯｎｅショートカットを使用して検索する
Figure 0004394644
（ｄ）ＩＤまたはパスで検索する
さらに、アイテム、関係、およびアイテム拡張は、その（複数の）ｉｄを与えることにより取り出すことができる。アイテムは、さらに、パスによっても取り出せる。
（複数の）ｉｄを与えてアイテム、関係、およびアイテム拡張を取得する
Figure 0004394644
 パスを与えてアイテムを取得する
Figure 0004394644
（ｅ）ＧｅｔＳｅａｒｃｈｅｒパターン
他のオブジェクトのコンテクストで、または特定のパラメータとともに、検索を実行するヘルパメソッドを用意することが望ましい場所がストレージプラットフォームＡＰＩ内に多数ある。ＧｅｔＳｅａｒｃｈｅｒパターンを使用することで、これらのシナリオが可能になる。ＡＰＩには多数のＧｅｔＳｅａｒｃｈｅｒメソッドが用意されている。それぞれ、与えられた検索を実行するように事前に構成されたＩｔｅｍＳｅａｒｃｈｅｒを返す。例えば、次のようである。
Figure 0004394644
 検索を実行する前に追加フィルタを付加することができる。
Figure 0004394644
 結果をどのような形で望むかを選択することができる。
Figure 0004394644
（３）ストアの更新
オブジェクトは、検索により取り出された後、必要に応じてアプリケーションにより修正することができる。新しいオブジェクトも作成し、既存のオブジェクトに関連付けることもできる。アプリケーションは、論理グループを形成するすべての変更を加えた後に、ＩｔｅｍＣｏｎｔｅｘｔ．Ｕｐｄａｔｅを呼び出して、ストアへの変更を永続的にする。本発明のストレージプラットフォームＡＰＩのさらに他の態様によれば、このＡＰＩは、アプリケーションプログラムによりアイテムに加えられた変更を集めてから、それらをデータストアが実装されているデータベースエンジン（または何らかの種類のストレージエンジン）により要求される正しい更新に編成する。これにより、アプリケーションプログラマは、データストア更新の複雑な部分をＡＰＩに任せつつ、メモリ中のアイテムに変更を加えることができる。
単一アイテムへの変更を保存する
Figure 0004394644
 複数アイテムへの変更を保存する
Figure 0004394644
 新しいアイテムを作成する
Figure 0004394644
 関係（および可能ならターゲットアイテム）を削除する
Figure 0004394644
 アイテム拡張を追加する
Figure 0004394644
 アイテム拡張を削除する
Figure 0004394644
６．セキュリティ
上の節ＩＩ．Ｅ（セキュリティ）を参照すると、ストレージプラットフォームＡＰＩのこの実施形態では、ストア内のアイテムに関連付けられているセキュリティポリシーの取り出しおよび修正を行うためにＩｔｅｍ Ｃｏｎｔｅｘｔ上で使用可能なメソッドが５つある。これらは以下の通りである。
１．ＧｅｔＩｔｅｍＳｅｃｕｒｉｔｙ、
２．ＳｅｔＩｔｅｍＳｅｃｕｒｉｔｙ、
３．ＧｅｔＰａｔｈＳｅｃｕｒｉｔｙ、
４．ＳｅｔＰａｔｈＳｅｃｕｒｉｔｙ、
５．ＧｅｔＥｆｆｅｃｔｉｖｅＩｔｅｍＳｅｃｕｒｉｔｙ。
ＧｅｔＩｔｅｍＳｅｃｕｒｉｔｙおよびＳｅｔＩｔｅｍＳｅｃｕｒｉｔｙは、アイテムに関連付けられた明示的なＡＣＬを取り出し、修正するメカニズムを備える。このＡＣＬは、アイテムへの存在するパスとは無関係であり、このアイテムをターゲットとして持つ保持関係とは無関係に動作する。このため、管理者は、そうしたい場合にアイテムへの存在するパスとは無関係にアイテムセキュリティについて推論することができる。
ＧｅｔＰａｔｈＳｅｃｕｒｉｔｙおよびＳｅｔＰａｔｈＳｅｃｕｒｉｔｙは、他のフォルダからの保持関係があるため、アイテム上に存在するＡＣＬを取り出し、修正するメカニズムを備える。このＡＣＬは、考察対象のパスにそってそのアイテムへの様々な祖先のＡＣＬから、そのパスについて用意されている場合に明示的なＡＣＬとともに構成される。このＡＣＬと前の場合のＡＣＬとの違いは、このＡＣＬは、明示的なアイテムＡＣＬがアイテムに対する保持関係とは無関係でありながら対応する保持関係が存在している限りにおいて動作する点である。
ＳｅｔＩｔｅｍＳｅｃｕｒｉｔｙおよびＳｅｔＰａｔｈＳｅｃｕｒｉｔｙでアイテム上に設定できるＡＣＬは、継承可能な、オブジェクト特有のＡＣＥに制約される。これらは、継承としてマークされているＡＣＥを含むことはできない。
ＧｅｔＥｆｆｅｃｔｉｖｅＩｔｅｍＳｅｃｕｒｉｔｙは、様々なパスベースのＡＣＬだけでなく、アイテム上の明示的なＡＣＬをも取り出す。これは、与えられたアイテムに影響を及ぼす許可ポリシーを反映する。
７．関係のサポート
上述のように、ストレージプラットフォームのデータモデルは、アイテムを互いに関係付けられる「関係」を定義する。スキーマのデータクラスが生成されるときに、関係の型毎に以下のクラスが生成される。
１．関係自体を表すクラス。このクラスは、Ｒｅｌａｔｉｏｎｓｈｉｐクラスから派生され、その関係型に特有のメンバを含む。
２．強く型付けされた「仮想」コレクションクラス。このクラスは、ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎから派生され、これにより、関係インスタンスの作成および削除を実行することができる。
この節では、ストレージプラットフォームＡＰＩ内の関係のサポートについて説明する。
ａ）基本関係型
ストレージプラットフォームＡＰＩは、関係ＡＰＩの基礎を形成するＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ名前空間内に多数の型を提供する。これらは以下の通りである。
１．Ｒｅｌａｔｉｏｎｓｈｉｐ−すべての関係クラスの基本型
２．ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎ−すべての関係コレクションの基本型
３．ＩｔｅｍＲｅｆｅｒｅｎｃｅ、ＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅ、ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅ−アイテム参照型を表し、それらの型の間の関係は図１１に例示されている。
（１）関係クラス
以下は、関係クラスの基本クラスである。
public abstract class Relationship : StoreObject
{
//既定値で作成する。
protected Relationship (ItemIDReference targetItemReference);
//関係コレクションに追加されたことを関係に通知する。オブジェクトは、コレクションに問い合わせを行い、ソースアイテム、アイテムコンテクストなどを決定する。
internal AddedToCollection (VirtualRelationshipCollection collection);
//関係のｉｄ。
public RelationshipId RelationshipId {get;}
//ソースアイテムのｉｄ。
public ItemId SourceItemId {get;}
//ソースアイテムを取得する。
public Item SourceItem {get;}
//ターゲットアイテムへの参照。
public ItemIdReference TargetItemReference {get;}
//ターゲットアイテムを取得する（ＴａｒｇｅｔＩｔｅｍＲｅｆｅｒｅｎｃｅ．ＧｅｔＩｔｅｍ（）を呼び出す）。
public Item TargetItem {get;}
//ＩｔｅｍＣｏｎｔｅｘｔがすでにターゲットアイテムのドメインとの接続を持っているか判定する（ＴａｒｇｅｔＩｔｅｍＲｅｆｅｒｅｎｃｅ．ＩｓＤｏｍａｉｎＣｏｎｎｅｃｔｅｄを呼び出す）。
public bool IsTargetDomainConnected {get;}
//名前空間内のターゲットアイテムの名前。名前は、すべてのソースアイテムの保持関係にわたって一意的でなければならない。
public OptionalValue<string> Name {get; set;}
//これは保持関係または参照関係かを決定する。
public OptionalValue<bool> IsOwned {get; set;}
（２）ＩｔｅｍＲｅｆｅｒｅｎｃｅクラス
以下は、アイテム参照型の基本クラスである。
public abstract class ItemReference : NestedElement
{
//既定値で作成する。
protected ItemReference();
//参照されているアイテムを返す。
public virtual Item GetItem ();
//参照されたアイテムのドメインへの接続が確立されたかどうかを判定する。
public virtual bool IsDomainConnected ();
}
ＩｔｅｍＲｅｆｅｒｅｎｃｅオブジェクトは、アイテム参照自体が置かれているストアと異なるストア内に存在するアイテムを識別することができる。それぞれの派生型は、リモートストアへの参照の構築および使用方法を指定する。派生クラスにおけるＧｅｔＩｔｅｍおよびＩｓＤｏｍａｉｎＣｏｎｎｅｃｔｅｄの実装では、ＩｔｅｍＣｏｎｔｅｘｔの複数ドメインサポートを使用して、必要なドメインからアイテムをロードし、ドメインとの接続がすでに確立されているかどうかを判定する。
（３）ＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅクラス
以下は、ＩｔｅｍＩｄＲｅｆｒｅｎｃｅクラス−ターゲットアイテムを識別するためにアイテムｉｄを使用するＩｔｅｍ参照−である。
public class ItemIdReference : ItemReference
{
//既定値で新しいＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅを構築する。
public ItemIdReference ();
//指定されたアイテムへの新しいＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅを構築する。Ｉｔｅｍに関連付けられているドメインは、ロケータとして使用される。
public ItemIdReference (Item item);
//ＮＵＬＬロケータと与えられたターゲットアイテムｉｄを使用して新しいＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅを構築する。
public ItemIdReference (Itemld itemId);
//与えられたロケータとアイテムｉｄ値を使用して新しいＩｔｅｍＩｄＲｅｆｅｒｅｎｃｅを構築する。
public ItemIdReference (string locator, ItemId itemId);
//ターゲットアイテムのｉｄ。
public ItemId ItemId {get; set;}
//ドメイン内にターゲットアイテムを含むそのＷｉｎＦＳアイテムを識別するパス。ＮＵＬＬの場合、そのアイテムを含むドメインは知られていない。
public OptionalValue<string> Locator {get; set;}
//参照されたアイテムのドメインへの接続が確立されたかどうかを判定する。
public override bool IsDomainConnected();
//参照されているアイテムを取り出す。
public override Item Getitem ();
}
ＧｅｔＩｔｅｍおよびＩｓＤｏｍａｉｎＣｏｎｎｅｃｔｅｄでは、ＩｔｅｍＣｏｎｔｅｘｔの複数ドメインサポートを使用して、必要なドメインからアイテムをロードし、ドメインとの接続がすでに確立されているかどうかを判定する。この機能は、まだ実装されていない。
（４）ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅクラス
ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅクラスは、パスを使用してターゲットアイテムを識別するアイテム参照である。このクラスに対するコードは以下の通りである。
public class ItemPathReference : ItemReference
{
//既定値でアイテムパス参照を構築する。
public ItemPathReference ();
//ロケータなしで、与えられたパスを付けて、アイテムパス参照を構築する。
public ItemPathReference (string path);
//与えられたロケータおよびパスを付けて、アイテムパス参照を構築する。
public ItemPathReference (string locator, string path);
//ドメイン内にターゲットアイテムを含むそのＷｉｎＦＳアイテムを識別するパス。
public OptionalValue<string> Locator {get; set;}
//ロケータにより指定されたアイテムドメインに関するターゲットアイテムのパス。
public string Path {get; set;}
//参照されたアイテムのドメインへの接続が確立されたかどうかを判定する。
public override bool IsDomainConnected();
//参照されているアイテムを取り出す。
public override Item GetItem();
}
ＧｅｔＩｔｅｍおよびＩｓＤｏｍａｉｎＣｏｎｎｅｃｔｅｄでは、ＩｔｅｍＣｏｎｔｅｘｔの複数ドメインサポートを使用して、必要なドメインからアイテムをロードし、ドメインとの接続がすでに確立されているかどうかを判定する。
（５）ＲｅｌａｔｉｏｎｓｈｉｐＩｄ構造体
ＲｅｌａｔｉｏｎｓｈｉｐＩｄ構造体は、関係ｉｄ ＧＵＩＤをカプセル化する。
public class RelationshipId
{
//新しい関係ｉｄ ＧＵＩＤを生成する。
public static RelationshipId NewRelationshipId ();
//新しい関係ｉｄ ＧＵＩＤで初期化する。
public RelationshipId();
//指定されたＧＵＩＤで初期化する。
public RelationshipId (Guid id);
//ＧＵＩＤの文字列表現で初期化する。
public RelationshipId (string id);
//関係ｉｄ ＧＵＩＤの文字列表現を返す。
public override string ToString ();
//Ｓｙｓｔｅｍ．ＧｕｉｄインスタンスをＲｅｌａｔｉｏｎｓｈｉｐＩｄインスタンスに変換する。
public static implicit operator RelationshipId (Guid guid);
//ＲｅｌａｔｉｏｎｓｈｉｐＩｄインスタンスをＳｙｓｔｅｍ．Ｇｕｉｄインスタンスに変換する。
public static implicit operator Guid (RelationshipId relationshipId);
}
この値型は、パラメータおよびプロパティが関係ｉｄとして強く型付けできるようにｇｕｉｄをラップする。関係ｉｄがＮＵＬＬ可能な場合には、ＯｐｔｉｏｎａｌＶａｌｕｅ＜ＲｅｌａｔｉｏｎｓｈｉｐＩｄ＞を使用しなければならない。Ｓｙｓｔｅｍ．Ｇｕｉｄ．Ｅｍｐｔｙにより与えられるような空値は公開されない。ＲｅｌａｔｉｏｎｓｈｉｐＩｄは、空の値では構築できない。既定のコンストラクタを使用してＲｅｌａｔｉｏｎｓｈｉｐＩｄを作成する場合、新しいＧＵＩＤが作成される。
（６）ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎクラス
ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎクラスは、データストアからのオブジェクト、それに加えて、コレクションに追加された新しいオブジェクトを含むが、ただし、ストアから削除されたオブジェクトを含まない、関係オブジェクトのコレクションを実装する。与えられたソースアイテムｉｄを持つ指定された関係型のオブジェクトは、コレクションに含まれる。
これは、それぞれの関係型について生成される関係コレクションクラスの基本クラスである。そのクラスは、与えられたアイテムの関係にアクセスし、その関係を操作しやすくするため、ソースアイテム型においてプロパティの型として使用することができる。
ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎの内容を列挙するには、潜在的に多数の関係オブジェクトをストアからロードする必要がある。アプリケーションでは、コレクションの内容を列挙する前に関係をいくつロードできるかを決定するためにＣｏｕｎｔプロパティを使用すべきである。コレクションへのオブジェクトの追加およびコレクションからのオブジェクトの削除では、関係をストアからロードする必要がない。
効率を高めるため、ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎオブジェクトを使用してアイテムの関係すべてを列挙する代わりに特定の基準条件を満たす関係をアプリケーション側で検索することが好ましい。関係オブジェクトをコレクションに追加すると、ＩｔｅｍＣｏｎｔｅｘｔ．Ｕｐｄａｔｅが呼び出されたときに表現されている関係がストア内に作成される。関係オブジェクトをコレクションから削除すると、ＩｔｅｍＣｏｎｔｅｘｔ．Ｕｐｄａｔｅが呼び出されたときに表現されている関係がストア内で削除される。仮想コレクションは、そのアイテム上のＩｔｅｍ．Ｒｅｌａｔｉｏｎｓｈｉｐｓコレクションまたは他の関係コレクションを通じて関係オブジェクトが追加／削除されるかどうかに関係なくオブジェクトの正しい集合を含む。
以下のコードは、ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎクラスを定義する。
public abstract class VirtualRelationshipCollection : ICollection
{
//コレクションは、ｉｔｅｍＩｄにより識別されたアイテムにより所有される指定された型の関係を含む。
protected VirtualRelationshipCollection (ItemContext itemContext, ItemId itemId, Type relationshipType);
//列挙子は、状態Ｉｎｓｅｒｔｅｄを持つオブジェクトに加えて状態Ｄｅｌｅｔｅｄを持つオブジェクトを除くストアからに取り出されたすべてのオブジェクトを返す。
public IEnumerator GetEnumerator ();
//列挙子により返されるであろう関係オブジェクトの数のカウントを返す。このカウントは、ストアからすべてのオブジェクトを取り出さなくても計算される。
public int Count {get;}
//常にｆａｌｓｅを返す。
public bool ICollection.lsSynchronized () {get;}
//常にこのオブジェクトを返す。
public object ICollection.SyncRoot {get;}
//ストア内で必要なオブジェクトを検索する。
public void Refresh ();
//指定された関係をコレクションに追加する。オブジェクトは、状態ＣｏｎｓｔｒｕｃｔｅｄまたはＲｅｍｏｖｅｄを持たなければならない。状態がＣｏｎｓｔｒｕｃｔｅｄであれば、状態はＡｄｄｅｄに変更される。状態がＲｅｍｏｖｅｄであれば、状態は適宜ＲｅｔｒｉｅｖｅｄまたはＭｏｄｉｆｉｅｄに変更される。この関係のソースアイテムｉｄは、コレクションが構築されたときに与えられたソースアイテムｉｄと同じでなければならない。
protected void Add (Relationship relationship);
//指定された関係をコレクションから削除する。オブジェクトの状態は、Ａｄｄｅｄ、Ｒｅｔｒｉｅｖｅｄ、またはＭｏｄｉｆｉｅｄでなければならない。オブジェクトの状態がＡｄｄｅｄの場合、これは、Ｃｏｎｓｔｒｕｃｔｅｄに設定される。オブジェクトの状態がＲｅｔｒｉｅｖｅｄまたはＭｏｄｉｆｉｅｄの場合、これはＲｅｍｏｖｅｄに設定される。この関係のソースアイテムｉｄは、コレクションが構築されたときに与えられたソースアイテムｉｄと同じでなければならない。
protected void Remove (Relationship relationship);
//コレクションから削除されたオブジェクト。
public ICollection RemovedRelationships {get;}
//コレクションに追加されたオブジェクト。
public ICollection AddedRelationships {get;}
//ストアから取り出されたオブジェクト。このコレクションは、ＶｉｒｔｕａｌＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎが列挙されるか、Ｒｅｆｒｅｓｈが呼び出されるまで空である（このプロパティの値を取得してもコレクションは書き込まれない）。
public ICollection StoredRelationships {get;}
//非同期メソッド。
public IAsyncResult BeginGetCount(IAsyncCallback callback, object state);
public int EndGetCount(IAsyncResult asyncResult);
public IAsyncResult BeginRefresh(IAsyncCallback callback, object state);
public void EndRefresh(IAsyncResult asyncResult);
}
ｂ）生成された関係型
ストレージプラットフォームスキーマのクラスを生成する場合、関係宣言毎に１つのクラスが生成される。関係自体を表すクラスに加えて、関係コレクションクラスも、それぞれの関係について生成される。これらのクラスは、関係のソースまたはターゲットアイテムクラス内のプロパティの型として使用される。
この節では、多数の「プロトタイプ」クラスを使用して生成されるクラスを説明する。つまり、指定された関係宣言が与えられた場合に、生成されるクラスについて説明する。プロトタイプクラスで使用されるクラス、型、および終点名は、その関係についてスキーマで指定された名前のプレースホルダであり、文字通りに解釈すべきではないことに注意されたい。
（１）生成された関係型
この節では、それぞれの関係型について生成されるクラスを説明する。例えば、次のようである。
Figure 0004394644
この関係定義が与えられると、ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅおよびＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅＣｏｌｌｅｃｔｉｏｎクラスが生成される。ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅクラスは、関係自体を表す。ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅＣｏｌｌｅｃｔｉｏｎクラスでは、ソース終点として指定されたアイテムを持つＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅインスタンスにアクセスできる。
（２）ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅクラス
これは、「ＨｏｌｄｉｎｇＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅ」という名前の保持関係に対するプロトタイプ関係クラスであり、ソース終点は「Ｈｅａｄ」という名前を持ち、「Ｆｏｏ」アイテム型を指定し、ターゲット終点は「Ｔａｉｌ」という名前を持ち、「Ｂａｒ」アイテム型を指定する。これは以下のように定義される。
Figure 0004394644
 （３）ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅＣｏｌｌｅｃｔｉｏｎクラス
これは、指定されたアイテムにより所有されるＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅ関係インスタンスのコレクションを保持する、ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅクラスで生成された、プロトタイプクラスである。これは以下のように定義される。
Figure 0004394644
ｃ）Ｉｔｅｍクラス内の関係サポート
Ｉｔｅｍクラスは、そのアイテムが関係のソースである関係にアクセスできるようにするＲｅｌａｔｉｏｎｓｈｉｐｓプロパティを含む。Ｒｅｌａｔｉｏｎｓｈｉｐｓプロパティは、型ＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎを持つ。
（１）Ｉｔｅｍクラス
以下のコードは、Ｉｔｅｍクラスの関係コンテクストプロパティを示している。
Figure 0004394644
（２）ＲｅｌａｔｉｏｎｓｈｉｐＣｏｌｌｅｃｔｉｏｎクラス
このクラスを使用すると、与えられたアイテムが関係のソースである関係インスタンスにアクセスできる。これは以下のように定義される。
Figure 0004394644
ｄ）検索式の中の関係サポート
検索式の中で、関係と関係づけられているアイテムとの間の結合のトラバースを指定することが可能である。
（１）アイテムから関係へのトラバース
検索式の現在のコンテクストがアイテムの集合である場合、アイテムがソースであるアイテムと関係インスタンスとの間の結合は、Ｉｔｅｍ．Ｒｅｌａｔｉｏｎｓｈｉｐｓプロパティを使用して実行できる。特定の型の関係への結合は、検索式Ｃａｓｔ演算子を使用して指定することができる。
強く型付けされた関係コレクション（例えば、Ｆｏｌｄｅｒ．ＭｅｍｂｅｒＲｅｌａｔｉｏｎｓｈｉｐｓ）も、検索式の中で使用することができる。関係型への型変換は暗黙のうちに行われる。
関係の集合が確立された後、その関係のプロパティは、述語の中で使用するか、または射影のターゲットとして使用することができる。射影のターゲットを指定するために使用される場合、関係の集合が返される。例えば、以下のステートメントでは、関係のＳｔａｒｔＤａｔｅプロパティが「１／１／２０００」以上の値を持っていた組織に関係するすべての人物を見つける。
Figure 0004394644
Ｐｅｒｓｏｎ型が型ＥｍｐｌｏｙｅｅＳｉｄｅＥｍｐｌｏｙｅｒＥｍｐｌｏｙｅｅＲｅｌａｔｉｏｎｓｈｉｐｓ（ＥｍｐｌｏｙｅｅＥｍｐｌｏｙｅｒ関係型について生成されるような）のプロパティＥｍｐｌｏｙｅｒＣｏｎｔｅｘｔを持っていた場合、これは以下のように書けるであろう。
Figure 0004394644
（２）関係からアイテムへのトラバース
検索式の現在のコンテクストが関係の集合である場合、関係から関係のいずれかの終点への結合は、終点の名前を指定することによりトラバースすることができる。関係アイテムの集合が確立された後、それらのアイテムのプロパティは、述語の中で使用するか、または射影のターゲットとして使用することができる。射影のターゲットを指定するために使用される場合、アイテムの集合が返される。例えば、以下のステートメントは、従業員のラストネームが「Ｓｍｉｔｈ」であるすべてのＥｍｐｌｏｙｅｅＯｆＯｒｇａｎｉｚａｔｉｏｎ関係（組織に関係なく）を見つける。
Figure 0004394644
検索式Ｃａｓｔ演算子を使用して、終点アイテムの型をフィルタ処理することができる。例えば、メンバが姓「Ｓｍｉｔｈ」を持つＰｅｒｓｏｎアイテムであるすべてのＭｅｍｂｅｒＯｆＦｏｌｄｅｒ関係インスタンスを見つけるために以下のようにする。
Figure 0004394644
（３）関係トラバースの組合せ
アイテムから関係へ、関係からアイテムへトラバースする前の２つのパターンを組み合わせて、いくらでも複雑なトラバースを得ることができる。例えば、姓が「Ｓｍｉｔｈ」である従業員が含まれるすべての組織を見つけるには、以下のようにする。
Figure 0004394644
以下の実施例では、「Ｎｅｗ Ｙｏｒｋ」エリア内に居住する世帯の一員を表すすべてのＰｅｒｓｏｎアイテムを見つける（ＴＯＤＯ：これは、サポートされなくなっている．．．代替え）。
Figure 0004394644
ｅ）関係サポートの使用例
以下は、関係を操作するためのストレージプラットフォームＡＰＩ内の関係サポートの使用例を示す。以下の実施例では、以下の宣言を仮定する。
Figure 0004394644
（１）関係の検索
ソースまたはターゲット関係を検索することが可能である。フィルタを使用することにより、指定された型を持ちプロパティ値を与えた関係を選択することができる。また、フィルタを使用することにより、関係ベースの関係するアイテム型またはプロパティ値を選択することができる。例えば、以下の検索を実行できる。
与えられたアイテムがソースであるすべての関係
Figure 0004394644
 与えられたアイテムが「Ａ％」とマッチする名前を持つソースであるすべての関係
Figure 0004394644
 与えられたアイテムがソースであるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係
Figure 0004394644
 与えられたアイテムがソースであり、名前が「Ａ％」のような名前であるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係
Figure 0004394644
 ターゲットアイテムがＰｅｒｓｏｎであるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係
Figure 0004394644
 ターゲットアイテムが姓「Ｓｍｉｔｈ」を持つＰｅｒｓｏｎであるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係
Figure 0004394644
上に示されているＧｅｔＳｅａｒｃｈｅｒ ＡＰＩに加えて、それぞれの関係クラスでは、静的なＦｉｎｄＡｌｌ、ＦｉｎｄＯｎｅ、およびＦｉｎｄＯｎｌｙ ＡＰＩをサポートする。さらに、関係型は、ＩｔｅｍＣｏｎｔｅｘｔ．ＧｅｔＳｅａｒｃｈｅｒ、ＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＡｌｌ、ＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＯｎｅ、またはＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＯｎｌｙを呼び出すときに指定できる。
（２）関係からソースおよびターゲットアイテムへのナビゲート
検索を通じて関係オブジェクトが取り出された後、ターゲットまたはソースアイテムに「ナビゲート」することが可能である。基本関係クラスは、Ｉｔｅｍオブジェクトを返すＳｏｕｒｃｅＩｔｅｍおよびＴａｒｇｅｔＩｔｅｍプロパティを備える。生成された関係クラスは、等価な強く型付けられた、名前付きプロパティ（例えば、ＦｏｌｄｅｒＭｅｍｂｅｒ．ＦｏｌｄｅｒＩｔｅｍおよびＦｏｌｄｅｒＭｅｍｂｅｒ．ＭｅｍｂｅｒＩｔｅｍ）を備える。例えば、次のようである。
名前「Ｆｏｏ」を持つ関係に対するソースおよびターゲットアイテムにナビゲートする
Figure 0004394644
 ターゲットアイテムにナビゲートする
Figure 0004394644
関係が見つかったドメイン内にターゲットアイテムがない場合でもターゲットアイテムへのナビゲートは機能する。このような場合、ストレージプラットフォームＡＰＩは、必要に応じてターゲットドメインへの接続を開く。アプリケーションは、ターゲットアイテムを取り出す前に接続が必要かどうかを判定することができる。
未接続ドメイン内のターゲットアイテムをチェックする
Figure 0004394644
（３）ソースアイテムから関係へのナビゲート
アイテムオブジェクトが与えられると、明示的検索を実行せずに、そのアイテムがソースである関係にナビゲートすることが可能である。これは、Ｆｏｌｄｅｒ．ＭｅｍｂｅｒＲｅｌａｔｉｏｎｓｈｉｐｓなどのＩｔｅｍ．Ｒｅｌａｔｉｏｎｓｈｉｐｓコレクションプロパティまたは強く型付けされたコレクションプロパティを使用して実行される。関係から、ターゲットアイテムにナビゲートすることが可能である。このようなナビゲーションは、ターゲットアイテムがターゲットアイテムと同じストア内にない場合を含む、ターゲットアイテムがソースアイテムのＩｔｅｍＣｏｎｔｅｘｔに関連付けられたアイテムドメイン内にない場合でも、機能する。例えば、次のようである。
ソースアイテムからターゲットアイテムへの関係にナビゲートする
Figure 0004394644
 ＦｏｌｄｅｒアイテムからターゲットアイテムへのＦｏｌｄｅｒｍｅｍｂｅｒ関係にナビゲートする
Figure 0004394644
アイテムは、多数の関係を持つことができ、したがって、アプリケーションでは、関係コレクションを列挙する場合に注意する必要がある。一般に、検索は、コレクション全体を列挙するのではなく、注目する特定の関係を識別するために使用すべきである。さらに、関係に対するコレクションベースのプログラミングモデルを持つことは、十分価値あることであり、多数の関係が十分に希なアイテムがあり、開発者による誤用のリスクは正当化される。アプリケーションは、コレクション内の関係の個数をチェックし、必要ならば異なるプログラミングモデルを使用することができる。例えば、次のようである。
関係コレクションのサイズをチェックする
Figure 0004394644
アプリケーションがコレクションを列挙しようとしない限り、それぞれの関係を表すオブジェクトが実際には初期値として埋め込まれないという意味で上述の関係コレクションは、「仮想的」である。コレクションが列挙される場合、結果はストア内にあるものに加えて、アプリケーションによって追加されたが、まだ保存されていないものを反映するが、アプリケーションによって削除されたが保存されていない関係については反映しない。
（４）関係（およびアイテム）の作成
新しい関係は、関係オブジェクトを作成し、それをソースアイテム内の関係に追加し、ＩｔｅｍＣｏｎｔｅｘｔを更新することにより作成される。新しいアイテムを作成するには、保持または埋め込み関係を作成しなければならない。例えば、次のようである。
新しいアイテムを既存のフォルダに追加する
Figure 0004394644
 既存のアイテムを既存のフォルダに追加する
Figure 0004394644
 既存のアイテムを新しいフォルダに追加する
Figure 0004394644
 新しいアイテムを新しいフォルダに追加する
Figure 0004394644
（５）関係（およびアイテム）の削除
保持関係を削除する
Figure 0004394644
８．ストレージプラットフォームＡＰＩの「拡張」
上述のように、すべてのストレージプラットフォームスキーマの結果、クラスの集合が得られる。これらのクラスは、Ｆｉｎｄ＊などの標準的なメソッドを備え、さらに、フィールド値を取得および設定するプロパティも用意する。これらのクラスおよび関連付けられたメソッドは、ストレージプラットフォームＡＰＩの基礎を形成する。
ａ）ドメインビヘイビア
これらの標準的メソッドに加えて、すべてのスキーマは、それに対するドメイン特有のメソッドの集合を持つ。これらをドメインビヘイビアと呼ぶ。例えば、Ｃｏｎｔａｃｔｓスキーマ内のドメインビヘイビアの一例として以下のようなものがある。
・ 電子メールアドレスは有効か？
・ フォルダが与えられた場合、そのフォルダのすべてのメンバのコレクションを取得する。
・ アイテムＩＤが与えられた場合、このアイテムを表すオブジェクトを取得する。
・ Ｐｅｒｓｏｎが与えられた場合、そのオンラインステータスを取得する。
・ 新しい連絡先または一時的連絡先を作成するヘルパ機能。
・ その他。
「標準的」ビヘイビア（Ｆｉｎｄ＊など）とドメインビヘイビアとを区別しているが、これらはプログラマには単にメソッドとして現れることに注意することが重要である。これらのメソッドの間の区別は、ドメインビヘイビアはハードコーディングされるが、標準的ビヘイビアは、ストレージプラットフォームＡＰＩ設計時ツールによりスキーマファイルから自動的に生成されるという事実にある。
その性質上、それらのドメインビヘイビアは手作りでなければならない。このため、Ｃ＃の初期バージョンでは、クラスの実装全体を１つのファイル内に収める必要があるという実用上の問題が生じる。したがって、このことにより、ドメインビヘイビアを追加するために、自動生成されたクラスファイルは強制的に、編集されなければならない。自ずから、これは問題になりうる。
部分クラスと呼ばれる機能は、そのような問題のために、Ｃ＃に導入された。基本的に、部分クラスを使用することにより、クラス実装は複数のファイルにまたがることができる。部分クラスは、キーワードｐａｒｔｉａｌが宣言の前に付くことを除き、正規のクラスと同じである。
Figure 0004394644
そこで、Ｐｅｒｓｏｎに対するドメインビヘイビアは、このように異なるファイルに入れることができる。
Figure 0004394644
ｂ）付加価値ビヘイビア
ドメインビヘイビアを持つデータクラスは、アプリケーション開発者が足場とする基礎を形成する。しかし、データクラスがそのデータに関係する考えられるすべてのビヘイビアを公開することは可能でも、望ましいことでもない。ストレージプラットフォームでは、開発者はストレージプラットフォームＡＰＩにより提供される基本機能を足場とすることができる。ここで基本パターンは、メソッドがストレージプラットフォームデータクラスのうちの１つまたは複数をパラメータとしてとるクラスを作成することである。例えば、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ使用するか、またはＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）メッセンジャを使用して電子メールを送信するための付加価値クラスは以下の通りとすることができる。
Figure 0004394644
これらの付加価値クラスは、ストレージプラットフォームに登録することができる。登録データは、ストレージプラットフォームがすべてのインストールされているストレージプラットフォーム型について維持するスキーマメタデータに関連付けられる。このメタデータは、ストレージプラットフォームアイテムとして格納され、これに対しクエリを実行できる。
付加価値クラスの登録は、強力な機能であり、例えば、これにより、Ｓｈｅｌｌ ｅｘｐｌｏｒｅｒ内のＰｅｒｓｏｎオブジェクトを右クリックすると、許容されるアクションの集合を、Ｐｅｒｓｏｎについて登録されている付加価値クラスから派生させることが可能になる、というシナリオが得られる。
ｃ）サービスプロバイダとしての付加価値ビヘイビア
本発明の実施形態では、ストレージプラットフォームＡＰＩは、与えられた型について付加価値クラスを「サービス」として登録できるメカニズムを備える。これにより、アプリケーションは、与えられた型のサービスプロバイダ（＝付加価値クラス）を設定、取得することができる。このメカニズムの使用を望む付加価値クラスは、よく知られているインターフェースを実装すべきであり、例えば、以下の通りである。
Figure 0004394644
すべてのストレージプラットフォームＡＰＩデータクラスは、ＩＣａｃｈｅｄＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒインターフェースを実装する。このインターフェースは、以下のようにＳｙｓｔｅｍ．ＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒインターフェースを拡張する。
Figure 0004394644
このインターフェースを使用することで、アプリケーションは、サービスプロバイダインスタンスを設定する他に、特定の型のサービスプロバイダを要求することができる。
このインターフェースをサポートするために、ストレージプラットフォームデータクラスは、型をキーとするサービスプロバイダのハッシュテーブルを保持する。サービスプロバイダが要求されると、この実装は、最初に、ハッシュテーブル内を見て、指定された型のサービスプロバイダが設定されているかどうかを調べる。設定されていなければ、登録されているサービスプロバイダインフラストラクチャを使用して、指定された型のサービスプロバイダを識別する。その後、このプロバイダのインスタンスが作成され、ハッシュテーブルに追加され、返される。また、データクラス上の共有メソッドがサービスプロバイダを要求し、オペレーションをそのプロバイダに転送することも可能であることに注意されたい。例えば、これは、ユーザにより指定された電子メールシステムを使用するメールメッセージクラス上のＳｅｎｄメソッドを提供するために使用することも可能である。
９．デザインタイムフレームワーク
この節では、本発明の実施形態により、ストレージプラットフォームのＳｃｈｅｍａがクライアント上のストレージプラットフォームＡＰＩクラスおよびサーバ上のＵＤＴクラスにどのように変わるかを説明する。図２４の図は、関わっているコンポーネントを示している。
図２４を参照すると、スキーマ内の型は、ＸＭＬファイルに含まれる（ボックス１）。このファイルは、さらに、スキーマに関連付けられたフィールドレベルおよびアイテムレベル制約も含む。ストレージプラットフォームＣｌａｓｓジェネレータ（ｘｆｓ２ｃｓ．ｅｘｅ−ボックス２）は、このファイルを取り、ストアＵＤＴに対する部分クラス（ボックス５）およびクライアントクラスに対する部分クラス（ボックス３）を生成する。スキーマドメイン毎に、追加メソッドが存在し、これをドメインビヘイビアと呼ぶ。ストア（ボックス７）、クライアント（ボックス６）、および両方の場所（ボックス４）で意味のあるドメインビヘイビアがある。ボックス４、６、および７内のコードは、手書き（自動生成でない）である。ボックス３、４、および６内の部分クラスはあわせて、ストレージプラットフォームＡＰＩドメインクラスの完全なクラス実装を形成する。ボックス３、４、および６は、コンパイルされ（ボックス８）、ストレージプラットフォームＡＰＩクラス−ボックス１１を形成する（実際には、ストレージプラットフォームＡＰＩは、すべての初期スキーマドメインから得られるボックス３、４、および６をコンパイルした結果である）。ドメインクラスに加えて、さらに、付加価値ビヘイビアを実装する追加クラスも存在する。これらのクラスは、１つまたは複数のスキーマドメイン内で１つまたは複数のクラスを使用する。これは、ボックス１０により表される。ボックス４、５、および７内の部分クラスはあわせて、サーバＵＤＴクラスの完全なクラス実装を形成する。ボックス４、５、および７は、コンパイルされ（ボックス９）、サーバサイドＵＤＴ アセンブリ−ボックス１２を形成する（実際には、サーバサイドＵＤＴアセンブリは、すべての初期スキーマドメインから得られるボックス４、５、および７をコンパイラプラス（ｃｏｍｐｉｌｅｒ−ｐｌｕｓ−ｉｎｇ）した結果である）。ＤＤＬコマンドジェネレータモジュール（ボックス１３）は、ＵＤＴアセンブリ（ボックス１２）、およびＳｃｈｅｍａファイル（ボックス１）を取り、データストア上に格納する。このプロセスは、とりわけ、それぞれのスキーマ内の型に対するテーブルおよびビューの生成を伴う。
１０．クエリ形式主義（Formalism）
基本に帰着させた場合、アプリケーションのパターンは、ストレージプラットフォームＡＰＩを使用した場合、ＩｔｅｍＣｏｎｔｅｘｔを開く、フィルタ条件付きでＦｉｎｄを使用し、所望のオブジェクトを取り出す、オブジェクトに演算を実行する、および変更をストアに送り返す、というものである。この節は、フィルタ文字列に入るものの構文に関する。
ストレージプラットフォームデータオブジェクトを見つけるときに提供されるフィルタ文字列は、オブジェクトのプロパティが、返されるために満たさなければならない条件を記述する。ストレージプラットフォームＡＰＩで使用される構文は、型変換および関係トラバースをサポートする。
ａ）フィルタの基本事項
フィルタ文字列は、空であり、指定された型のすべてのオブジェクトが返されることを示すか、またはそれぞれの返されるオブジェクトが満たさなければならない論理式である。この式は、オブジェクトプロパティを参照する。ストレージプラットフォームＡＰＩランタイムは、どのようにこれらのプロパティ名がストレージプラットフォームの型フィールド名にマッピングされ、最終的に、ストレージプラットフォームストアにより保持されるＳＱＬビューにマッピングされるかについて関知している。
以下の実施例を考察する。
Figure 0004394644
ネストされたオブジェクトのプロパティもフィルタ内で使用できる。例えば、次のようである。
Figure 0004394644
コレクションについては、角括弧内の条件を使用してメンバのフィルタ処理を行うことが可能である。例えば、次のようである。
Figure 0004394644
以下の実施例は、１２／３１／１９９９以降に生まれたすべての人々のリストを作成する。
Figure 0004394644
１行目で、ローカルコンピュータのストレージプラットフォーム共有上の「Ｗｏｒｋ Ｃｏｎｔａｃｔｓ」にアクセスする新しいＩｔｅｍＣｏｎｔｅｘｔオブジェクトを作成する。３行目と４行目で、式「Ｂｉｒｔｈｄａｔｅ＞‘１２／３１／１９９９’」により指定されているように、Ｂｉｒｔｈｄａｔｅプロパティが１２／３１／１９９９よりも最近の日付を指定するＰｅｒｓｏｎオブジェクトのコレクションを取得する。このＦｉｎｄＡｌｌオペレーションの実行は、図２３に示されている。
ｂ）型変換（Type Casts）
プロパティに格納されている値の型がプロパティ宣言型から派生されることはよくあることである。例えば、Ｐｅｒｓｏｎ内のＰｅｒｓｏｎａｌＥＡｄｄｒｅｓｓｅｓプロパティは、ＥＭａｉｌＡｄｄｒｅｓｓおよびＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒなどのＥＡｄｄｒｅｓｓから派生された型のコレクションを含む。電話市外局番に基づいてフィルタ処理するには、ＥＡｄｄｒｅｓｓ型からＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒ型に型変換する必要がある。
Figure 0004394644
ｃ）フィルタ構文
以下では、一実施形態による、ストレージプラットフォームＡＰＩによりサポートされているフィルタ構文を説明する。
Figure 0004394644
１１．リモーティング
ａ）ＡＰＩにおけるローカル／リモート透過性
ストレージプラットフォームのデータアクセスは、ローカルストレージプラットフォームインスタンスをターゲットとしている。ローカルインスタンスは、クエリ（またはその一部）がリモートデータを参照している場合にルータとして使用される。そのため、ＡＰＩレイヤは、ローカル／リモート透過性を備え、ローカルデータアクセスとリモートデータアクセスとの間でＡＰＩの構造的な違いはない。これは、純粋に、要求されたスコープの機能である。
ストレージプラットフォームのデータストアは、さらに、分散クエリを実装するので、ローカルストレージプラットフォームのインスタンスに接続し、一方がローカルストア上にあり、他方がリモートストア上にある異なるボリュームからのアイテムを含むクエリを実行することが可能である。ストアは、結果を合併し、それはアプリケーションに提示する。ストレージプラットフォームＡＰＩ（したがって、アプリケーション開発者）の観点からは、任意のリモートアクセスは完全に継ぎ目なく、透過的である。
ストレージプラットフォームＡＰＩを使用することにより、アプリケーション側で、与えられたＩｔｅｍＣｏｎｔｅｘｔオブジェクト（ＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎメソッドにより返されるような）がＩｓＲｅｍｏｔｅプロパティ−これは、ＩｔｅｍＣｏｎｔｅｘｔオブジェクト上のプロパティである−を使用してローカルまたはリモート接続を表すかどうかを決定することができる。とりわけ、アプリケーションは、パフォーマンス、信頼性などに対するユーザの期待を設定しやすくするために視覚的フィードバックを与えたい場合がある。
ｂ）リモーティングのストレージプラットフォーム実装
ストレージプラットフォームのデータストアは、ＨＴＴＰ上で実行される特別なＯＬＥＤＢプロバイダを使用して互いに対話する（既定のＯＬＥＤＢプロバイダはＴＤＳを使用する）。一実施形態では、分散クエリは、リレーショナルデータベースエンジンの既定のＯＰＥＮＲＯＷＳＥＴ機能を適用される。特別なユーザ定義関数（ＵＤＦ）、ＤｏＲｅｍｏｔｅＱｕｅｒｙ（ｓｅｒｖｅｒ，ｑｕｅｒｙＴｅｘｔ）が用意され、実際のリモーティングを実行する。
ｃ）非ストレージプラットフォームストアへのアクセス
本発明のストレージプラットフォームの一実施形態では、ストアがストレージプラットフォームのデータアクセスに加わることを許す汎用プロバイダアーキテクチャはない。しかし、Ｍｉｃｒｏｓｏｆｔ ＥｘｃｈａｎｇｅおよびＭｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）の特定の場合に対する制限されたプロバイダアーキテクチャが提供される。これは、開発者が、ちょうどストレージプラットフォーム内にはあるように、ストレージプラットフォームＡＰＩを使用し、ＡＤおよびＥｘｃｈａｎｇｅ内のデータにアクセスできることを意味するが、アクセスできるデータは、ストレージプラットフォームのスキーマ化された型に制限されることを意味する。したがって、アドレス帳（＝ストレージプラットフォームのＰｅｒｓｏｎ型のコレクション）は、ＡＤでサポートされ、メール、カレンダー、および連絡先は、Ｅｘｃｈａｎｇｅ用にサポートされる。
ｄ）ＤＦＳとの関係
ストレージプラットフォームのプロパティプロモータ（ｐｒｏｐｅｒｔｙ ｐｒｏｍｏｔｅｒ）は、過去のマウントポイントを格上げしない。名前空間がマウントポイントを通じてアクセスするのに十分リッチであるとしても、クエリはそれらを通過しない。ストレージプラットフォームボリュームは、ＤＦＳツリー内の葉ノードとして現れることができる。
ｅ）ＧＸＡ／Ｉｎｄｉｇｏとの関係
開発者は、ストレージプラットフォームＡＰＩを使用して、データストアの上に「ＧＸＡ ｈｅａｄ」を公開することができる。概念的には、これは、他のＷｅｂサービスを作成するのと異ならない。ストレージプラットフォームＡＰＩは、ＧＸＡを使用してストレージプラットフォームデータストアと対話しない。上述のように、ＡＰＩは、ＴＤＳを使用してローカルストアと対話し、どのリモーティングも、同期サービスを使用してローカルストアにより処理される。
１２．制約条件
ストレージプラットフォームデータモデルでは、型に対する値制約条件を持つことができる。それらの制約条件は、ストア上で自動的に評価され、このプロセスは、ユーザにとって透過的である。制約条件は、サーバ側でチェックされることに注意されたい。このことに注意すると、ときには、サーバへの往復やり取りのオーバーヘッドを被ることなく、入力データが制約条件を満たすことを確認できる融通性を開発者に対し与えることが望ましい。これは、本質的に、エンドユーザがオブジェクトに埋めるために使用されるデータを入力する対話的アプリケーションで有用である。ストレージプラットフォームＡＰＩはこの機能を実現している。
スキーマを表す適切なデータベースオブジェクトを生成するためにストレージプラットフォームにより使用される、ストレージプラットフォームＳｃｈｅｍａは、ＸＭＬファイルで指定されることに注意されたい。これは、クラスを自動生成するためにストレージプラットフォームＡＰＩの設計時フレームワークによっても使用される。
Ｃｏｎｔａｃｔｓスキーマを生成するために使用されるＸＭＬファイルの部分リスティングを以下に示す。
Figure 0004394644
上記のＸＭＬ内のＣｈｅｃｋタグは、Ｐｅｒｓｏｎ型に対する制約を指定する。複数のチェックタグがありうる。上記の制約条件は、一般にストア内でチェックされる。制約条件がさらにアプリケーションにより明示的にチェックできることを指定するために、上記ＸＭＬは以下のように修正される。
Figure 0004394644
ｔｒｕｅに設定される＜Ｃｈｅｃｋ＞要素上の新しい「ＩｎＡｐｐｌｉｃａｔｉｏｎ」属性に注意されたい。これにより、ストレージプラットフォームＡＰＩは、Ｖａｌｉｄａｔｅ（）と呼ばれるＰｅｒｓｏｎクラス上のインスタンスメソッドを通じてＡＰＩにおける制約を明らかにする。アプリケーションは、オブジェクト上でこのメソッドを呼び出して、データが有効であることを確認し、サーバとの間の潜在的に無用なやり取りをなくすことができる。これは、バリデーションの結果を示すブール値を返す。値制約条件は、クライアントが＜ｏｂｊｅｃｔ＞．Ｖａｌｉｄａｔｅ（）メソッドを呼び出すかどうかに関係なくそのままサーバに適用されることに注意されたい。以下にＶａｌｉｄａｔｅの使用例を示す。
Figure 0004394644
ストレージプラットフォームストアへのアクセスパスは複数存在する−ストレージプラットフォームＡＰＩ、ＡＤＯ．ＮＥＴ、ＯＤＢＣ、ＯＬＥＤＢ、およびＡＤＯである。このため、信頼できる制約条件チェックであるかどうかの疑問が生じる−つまり、例えばＯＤＢＣから書かれたデータに、ストレージプラットフォームＡＰＩから書かれたデータと同じデータ完全性制約条件が適用されることをどのように保証できるのか。すべての制約条件はストア側でチェックされるため、制約条件は信頼できるものとなる。ストアに達するためにどのようなＡＰＩパスを使用するかに関係なく、ストアへの書き込みはすべて、ストアでの制約条件チェックを通じてフィルタ処理される。
１３．共有
ストレージプラットフォームの共有は、
Figure 0004394644
 の形式であり、ただし、＜ＤＮＳ Ｎａｍｅ＞はマシンのＤＮＳ名、＜Ｃｏｎｔｅｘｔ Ｓｅｒｖｉｃｅ＞は、そのマシン上の包含フォルダ、仮想フォルダ、またはボリューム内のアイテムである。例えば、マシン「Ｊｏｈｎｓ＿Ｄｅｓｋｔｏｐ」は、Ｊｏｈｎｓ＿Ｉｎｆｏｒｍａｔｉｏｎというボリュームを持ち、このボリューム内には、Ｃｏｎｔａｃｔｓ＿Ｃａｔｅｇｏｒｉｅｓというフォルダが存在し、このフォルダは、Ｗｏｒｋというフォルダを含み、これには、Ｊｏｈｎの仕事用連絡先
Figure 0004394644
 が入っている。これは、「ＷｏｒｋＣｏｎｔａｃｔｓ」として共有することができる。この共有の定義では、＼＼Ｊｏｈｎｓ＿Ｄｅｓｋｔｏｐ＼ＷｏｒｋＣｏｎｔａｃｔｓ＼ＪａｎｅＳｍｉｔｈは、有効なストレージプラットフォーム名であり、ＰｅｒｓｏｎアイテムＪａｎｅＳｍｉｔｈを識別する。
ａ）共有の表現
共有アイテム型は、共有名、および共有ターゲット（これは、非保持リンクであってよい）のプロパティを持つ。例えば、上述の共有の名前は、ＷｏｒｋＣｏｎｔａｃｔｓであり、ターゲットは、ボリュームＪｏｈｎｓ＿Ｉｎｆｏｒｍａｔｉｏｎ上のＣｏｎｔａｃｔｓ＿Ｃａｔｅｇｏｒｉｅｓ＼Ｗｏｒｋである。以下に、Ｓｈａｒｅ型のスキーマ断片を示す。
Figure 0004394644
ｂ）共有の管理
共有はアイテムであるため、共有は他のアイテムとまったく同様に管理できる。共有は、作成、削除、および修正が可能である。共有は、さらに、他のストレージプラットフォームアイテムと同じようにしてセキュリティ設定される。
ｃ）共有のアクセス
アプリケーションは、ＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎ（）メソッド呼び出しで共有名（例えば、＼＼Ｊｏｈｎｓ＿Ｄｅｓｋｔｏｐ＼ＷｏｒｋＣｏｎｔａｃｔｓ）をストレージプラットフォームＡＰＩに渡すことによりリモートストレージプラットフォーム共有にアクセスする。ＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎは、ＩｔｅｍＣｏｎｔｅｘｔオブジェクトインスタンスを返す。その後、ストレージプラットフォームＡＰＩは、ローカルストレージプラットフォームサービスと対話する（リモートストレージプラットフォーム共有へのアクセスは、ローカルストレージプラットフォームを介して行われることに注意されたい）。次に、ローカルストレージプラットフォームサービスは、与えられた共有名（例えば、ＷｏｒｋＣｏｎｔａｃｔｓ）を使用してリモートストレージプラットフォームサービス（例えば、マシンＪｏｈｎｓ＿Ｄｅｓｋｔｏｐ上の）と対話する。その後、リモートストレージプラットフォームサービスは、ＷｏｒｋＣｏｎｔａｃｔｓをＣｏｎｔａｃｔｓ＿Ｃａｔｅｇｏｒｉｅｓ＼Ｗｏｒｋに翻訳して、それを開く。その後、クエリおよびその他のオペレーションが他のスコープとまったく同様に実行される。
ｄ）発見可能性
一実施形態では、アプリケーションプログラムは、以下のようにして、与えられた＜ＤＮＳ Ｎａｍｅ＞上で使用可能な共有を発見することができる。第１の方法により、ストレージプラットフォームＡＰＩはＤＮＳ名（例えば、Ｊｏｈｎｓ＿Ｄｅｓｋｔｏｐ）をＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎ（）メソッドのスコープパラメータとして受け付ける。ストレージプラットフォームＡＰＩは、次に、このＤＮＳ名を接続文字列の一部として使用しストレージプラットフォームストアに接続する。この接続では、アプリケーションが唯一できることは、ＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＡｌｌ（ｔｙｐｅｏｆ（Ｓｈａｒｅ））を呼び出すことである。その後、ストレージプラットフォームサービスは、接続されているすべてのボリューム上のすべての共有を合併し、共有のコレクションを返す。第２の方法により、ローカルマシン上で、管理者はＦｉｎｄＡｌｌ（ｔｙｐｅｏｆ（Ｓｈａｒｅ））により特定のボリューム上の、またはＦｉｎｄＡｌｌ（ｔｙｐｅｏｆ（Ｓｈａｒｅ），“Ｔａｒｇｅｔ（ＳｈａｒｅＤｅｓｔｉｎａｔｉｏｎ）．Ｉｄ＝ｆｏｌｄｅｒＩｄ”）により特定のフォルダ上の共有を容易に発見することができる。
１４．Ｆｉｎｄの意味
Ｆｉｎｄ＊メソッド（ＩｔｅｍＣｏｎｔｅｘｔオブジェクトで呼び出されようと、個々のアイテム上で呼び出されようと関係なく）は、一般に、与えられたコンテクスト内のＩｔｅｍ（埋め込まれたアイテムを含む）に適用される。ネストされた要素は、Ｆｉｎｄを持たない−包含Ｉｔｅｍと無関係に検索することはできない。これは、ネストされた要素が包含アイテムからその「アイデンティティ」を派生させる、ストレージプラットフォームデータモデルで望ましい意味と一致する。この概念をより明確にするために、以下に、有効なｆｉｎｄオペレーションと無効なｆｉｎｄオペレーションの実施例を示す。
ａ）市外局番２０６を持つシステム内のすべての電話番号を表示する？
無効、ｆｉｎｄはアイテムを参照せずに電話番号−要素−に対し実行されるため。
ｂ）市外局番２０６を持つすべてのＰｅｒｓｏｎｓ内のすべての電話番号を表示する？
無効、Ｐｅｒｓｏｎ（＝アイテム）が参照されるとしても、検索条件はそのアイテムを含まない。
ｃ）市外局番２０６を持つすべてのＭｕｒａｌｉ（＝１人）のすべての電話番号を表示する？
有効、Ｉｔｅｍに対し検索条件があるため（「Ｍｕｒａｌｉ」という名前のＰｅｒｓｏｎ）。
この規則の例外は、Ｂａｓｅ．Ｒｅｌａｔｉｏｎｓｈｉｐ型から直接的または間接的に派生されるネストされた要素型についてのものである。これらの型は、関係クラスを通じて個別にクエリを実行できる。このようなクエリをサポートできるのは、ストレージプラットフォーム実装では、アイテムＵＤＴ内に埋め込む代わりに、「マスタリンクテーブル」を使用してＲｅｌａｔｉｏｎｓｈｉｐ要素を格納するからである。
１５．ストレージプラットフォームＣｏｎｔａｃｔｓ ＡＰＩ
この節では、ストレージプラットフォームＣｏｎｔａｃｔｓ ＡＰＩの概要を述べる。Ｃｏｎｔａｃｔｓ ＡＰＩの背後にあるスキーマは、図２１Ａおよび２１Ｂに示されている。
ａ）Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｎｔａｃｔの概要
ストレージプラットフォームＡＰＩは、Ｃｏｎｔａｃｔｓスキーマ内のアイテムおよび要素を取り扱うための名前空間を含む。この名前空間は、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｃｏｎｔａｃｔと呼ばれる。
このスキーマは、例えば、以下のクラスを持つ。
・ Ｉｔｅｍ：ＵｓｅｒＤａｔａＦｏｌｄｅｒ、Ｕｓｅｒ、Ｐｅｒｓｏｎ、ＡＤＳｅｒｖｉｃｅ、Ｓｅｒｖｉｃｅ、Ｇｒｏｕｐ、Ｏｒｇａｎｉｚａｔｉｏｎ、Ｐｒｉｎｃｉｐａｌ、Ｌｏｃａｔｉｏｎ
・ Ｅｌｅｍｅｎｔｓ：Ｐｒｏｆｉｌｅ、ＰｏｓｔａｌＡｄｄｒｅｓｓ、ＥｍａｉｌＡｄｄｒｅｓｓ、ＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒ、ＲｅａｌＴｉｍｅＡｄｄｒｅｓｓ、ＥＡｄｄｒｅｓｓ、ＦｕｌｌＮａｍｅ、ＢａｓｉｃＰｒｅｓｅｎｃｅ、ＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐ、ＲｏｌｅＯｃｃｕｐａｎｃｙ
ｂ）ドメインビヘイビア
以下に、Ｃｏｎｔａｃｔｓスキーマのドメインビヘイビアのリストを示す。十分に高いレベルから見た場合、ドメインビヘイビアは、以下の適切に認識可能なカテゴリに分類される。
・ 静的ヘルパ、例えば、新しい個人連絡先を作成するためのＰｅｒｓｏｎ．ＣｒｅａｔｅＰｅｒｓｏｎａｌＣｏｎｔａｃｔ（）、
・ インスタンスヘルパ、例えば、ユーザ（Ｕｓｅｒクラスのインスタンス）を自動ログインのマークが付けられているすべてのプロファイルにログインさせるｕｓｅｒ．ＡｕｔｏＬｏｇｉｎＴｏＡｌｌＰｒｏｆｉｌｅｓ（）、
・ カテゴリＧＵＩＤｓ、例えば、Ｃａｔｅｇｏｒｙ．Ｈｏｍｅ、Ｃａｔｅｇｏｒｙ．Ｗｏｒｋなど、
・ 派生プロパティ、例えば、ｅｍａｉｌＡｄｄｒｅｓｓ．Ａｄｄｒｅｓｓ（）−与えられたｅｍａｉｌＡｄｄｒｅｓｓ（＝ＥｍａｉｌＡｄｄｒｅｓｓクラスのインスタンス）のユーザ名およびドメインフィールドを組み合わせた文字列を返す、派生コレクション、例えば、ｐｅｒｓｏｎ．ＰｅｒｓｏｎａｌＥｍａｉｌＡｄｄｒｅｓｓｅｓ−Ｐｅｒｓｏｎクラスのインスタンスが与えられた場合、その個人電子メールアドレスを取得する。
以下の表は、ドメインビヘイビアを持つＣｏｎｔａｃｔｓ内のクラス毎に、それらのメソッドおよびそれらが属すカテゴリのリストをまとめたものである。
Figure 0004394644
１６．ストレージプラットフォームＦｉｌｅ ＡＰＩ
この節では、本発明の一態様による、ストレージプラットフォームＦｉｌｅ ＡＰＩの概要を説明する。
ａ）序論
（１）ストレージプラットフォーム内でのＮＴＦＳボリュームの反映
ストレージプラットフォームは、既存のＮＴＦＳボリューム内の内容の上にインデックス作成を行う手段を備える。これは、ＮＴＦＳ内のそれぞれのファイルストリームまたはディレクトリからプロパティを抽出（「格上げ」）し、それらのプロパティをストレージプラットフォーム内にＩｔｅｍとして格納することにより実行される。
ストレージプラットフォームＦｉｌｅスキーマは、格上げされたファイルシステムエンティティを格納するために２つのアイテム型−ＦｉｌｅおよびＤｉｒｅｃｔｏｒｙ−を定義する。Ｄｉｒｅｃｔｏｒｙ型は、Ｆｏｌｄｅｒ型の子型であり、他のＤｉｒｅｃｔｏｒｙアイテムまたはＦｉｌｅアイテムを含む包含フォルダである。
Ｄｉｒｅｃｔｏｒｙアイテムは、ＤｉｒｅｃｔｏｒｙおよびＦｉｌｅアイテムを含むことができるが、他のどのような型のアイテムも含むことができない。ストレージプラットフォームに関する限り、ＤｉｒｅｃｔｏｒｙおよびＦｉｌｅアイテムは、データアクセスＡＰＩのどれからも読み取り専用である。Ｆｉｌｅ Ｓｙｓｔｅｍ Ｐｒｏｍｏｔｉｏｎ Ｍａｎａｇｅｒ（ＦＳＰＭ）サービスは、変更されたプロパティをストレージプラットフォーム内に非同期に格上げする。ＦｉｌｅおよびＤｉｒｅｃｔｏｒｙアイテムのプロパティは、Ｗｉｎ３２ ＡＰＩにより変更できる。ストレージプラットフォームＡＰＩは、Ｆｉｌｅアイテムに関連付けられたストリームを含む、それらのアイテムのプロパティを読む込むために使用することができる。
（２）ストレージプラットフォーム名前空間内でのファイルおよびディレクトリの作成
ＮＴＦＳボリュームがストレージプラットフォームボリュームに格上げされると、その中のすべてのファイルおよびディレクトリは、そのボリュームの特定の一部となる。この領域は、ストレージプラットフォームの観点から読み取り専用であり、ＦＳＰＭは新しいディレクトリおよびファイルを作成し、および／または既存のアイテムのプロパティを変更することができる。
このボリュームの名前空間の残り部分は、通常範囲のストレージプラットフォームアイテム型−Ｐｒｉｎｃｉｐａｌ、Ｏｒｇａｎｉｚａｔｉｏｎ、Ｄｏｃｕｍｅｎｔ、Ｆｏｌｄｅｒなど−を含むことができる。ストレージプラットフォームでは、さらに、ストレージプラットフォーム名前空間の一部に複数のＦｉｌｅおよびＤｉｒｅｃｔｏｒｙを作成することができる。これらの「ネイティブ」のＦｉｌｅおよびＤｉｒｅｃｔｏｒｙは、ＮＴＦＳファイルシステム側に対応するものを持たず、ストレージプラットフォーム内に丸ごと格納される。さらに、プロパティへの変更は即座に現れる。
しかし、プログラミングモデルは同じままである、つまり、ストレージプラットフォームデータアクセスＡＰＩに関する限り、読み取り専用であるということである。「ネイティブ」のＦｉｌｅおよびＤｉｒｅｃｔｏｒｙは、Ｗｉｎ３２ ＡＰＩを使用して更新されなければならない。これにより、開発者のメンタルモデルが簡素化され、以下のようになる。
１．名前空間内のどこでもストレージプラットフォームアイテム型を作成できる（もちろん、パーミッションにより禁止されていない限り）。
２．ストレージプラットフォームアイテム型は、ストレージプラットフォームＡＰＩを使用して読み込むことができる。
３．すべてのストレージプラットフォームアイテム型は、ＦｉｌｅおよびＤｉｒｅｃｔｏｒｙを除いて、ストレージプラットフォームＡＰＩを使用して書き込むことが可能である。
４．名前空間内のどこにあるかに関係なくＦｉｌｅおよびＤｉｒｅｃｔｏｒｙアイテムに書き込みを行うために、Ｗｉｎ３２ ＡＰＩを使用する。
５．「格上げされた」名前空間内のＦｉｌｅ／Ｄｉｒｅｃｔｏｒｙへの変更は、ストレージプラットフォーム内に即座に現れないことがあるが、「格上げされない」名前空間内では、変更は、ストレージプラットフォーム内に即座に反映される。
ｂ）Ｆｉｌｅスキーマ
図２５は、Ｆｉｌｅ ＡＰＩが基づくスキーマを例示している。
ｃ）Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓの概要
ストレージプラットフォームＡＰＩは、ファイルオブジェクトを取り扱うための名前空間を含む。この名前空間は、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓと呼ばれる。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓのクラスのデータメンバは、ストレージプラットフォームストアに格納されている情報を直接反映し、この情報は、ファイルシステムオブジェクトから「格上げ」されるか、またはＷｉｎ３２ ＡＰＩを使用してネイティブな形で作成することができる。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓ名前空間は、ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍの２つのクラスを持つ。これらのクラスおよびそのメソッドのメンバは、図２５のスキーマ図を見ると容易に推測できる。ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍは、ストレージプラットフォームＡＰＩからは読み取り専用である。それらを修正するためには、Ｗｉｎ３２ ＡＰＩを使用するか、またはＳｙｓｔｅｍ．ＩＯのクラスを使用する必要がある。
ｄ）コード例
この節では、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓ内でのクラスの使用を例示する３つのコード例を取りあげる。
（１）ファイルを開き書き込む
この実施例は、「従来」のファイル操作の仕方を示している。
Figure 0004394644
３行目では、ＦｉｎｄＢｙＰａｔｈメソッドを使用してファイルを開く。７行目は、格上げされたプロパティＩｓＲｅａｄＯｎｌｙを使用して、ファイルが書き込み可能かどうかをチェックすることを示している。書き込み可能であれば、９行目で、ＦｉｌｅＩｔｅｍオブジェクト上でＯｐｅｎＷｒｉｔｅ（）を使用して、ファイルストリームを取得する。
（２）クエリの使用
ストレージプラットフォームストアは、ファイルシステムから格上げされたプロパティを保持するので、ファイルに対しリッチなクエリを容易に実行することが可能である。この実施例では、過去３日以内に修正されたすべてのファイルの一覧が表示される。
Figure 0004394644
以下に、クエリのもう１つの使用例を示す−これは、ある型（＝拡張）のすべての書き込み可能なファイルを見つける。
Figure 0004394644
ｅ）ドメインビヘイビア
一実施形態では、ファイルクラスは、標準のプロパティおよびメソッドに加えて、さらに、ドメインビヘイビア（手書きコーディングのプロパティおよびメソッド）を持つ。これらのビヘイビアは、一般に、対応するＳｙｓｔｅｍ．ＩＯクラス内のメソッドに基づく。
Ｊ．まとめ
これまでに例示したように、本発明は、データの編成、検索、および共有のためのストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、既存のファイルシステムおよびデータベースシステムを超えてデータストレージの概念を拡張し、広げるものであり、リレーショナル（表形式）データ、ＸＭＬ、およびＩｔｅｍと呼ばれる新しいデータ形態などの、構造化、非構造化、または半構造化データを含むすべての型のデータ用のストアとなるように設計されている。本発明のストレージプラットフォームでは、共通のストレージ基盤および図式化されたデータを通じて、より効率的なアプリケーション開発を消費者、知識労働者、および企業向けに行うことができる。これは、データモデルに固有の機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法も包含し、拡張する機能豊富な拡張可能アプリケーションプログラミングインターフェースを備える。本発明の広範な概念から逸脱することなく、上述の実施形態に対し変更を加えられることは理解される。したがって、本発明は、開示されている特定の実施形態に限定されず、付属の請求項の定義に従って本発明の趣旨および範囲内にあるすべての修正形態を対象とすることを意図されている。
上述の内容から明らかなように、本発明の様々なシステム、方法、および態様の全部または一部は、プログラムコード（つまり、命令）の形で具現化できる。このプログラムコードは、限定はしないが、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ハードディスクドライブ、またはその他のマシン可読記憶媒体を含む、磁気、電気、または光記憶媒体などのコンピュータ可読媒体上に格納することができ、プログラムコードがコンピュータまたはサーバなどのマシン内にロードされ実行されると、マシンは本発明を実践するための装置となる。本発明は、さらに、電気配線またはケーブル配線、光ファイバの使用、インターネットまたはイントラネットを含むネットワークなどの何らかの伝送媒体で、または他の形態の伝送を介して、伝送されるプログラムコードの形態で具現化されることも可能であり、プログラムコードがコンピュータなどのマシンにより受信され、読み込まれ、実行されると、マシンは本発明を実施するための装置となる。汎用プロセッサ上に実装された場合、プログラムコードはプロセッサとの組合せで、特定のロジック回路と類似の動作をする独自の装置を実現する。
付録Ａ
Figure 0004394644
 ＩｔｅｍＣｏｎｔｅｘｔ作成および管理メンバ
//アプリケーションは、ＩｔｅｍＣｏｎｔｅｘｔオブジェクトを直接作成できず、またＩｔｅｍＣｏｎｔｅｘｔからクラスを派生させることもできない。
interal ItemContext();
//指定されたパス、またはパスが指定されていない場合には、ローカルコンピュータ上の既定のストアを検索するために使用できるＩｔｅｍＣｏｎｔｅｘｔを作成する。
public static ItemContext Open();
public static ItemContext Open(string path);
public static ItemContext Open(params string[] paths);
//ＩｔｅｍＣｏｎｔｅｘｔが作成された場合に指定されたパスを返す。
public string[] GetOpenPaths();
//このＩｔｅｍＣｏｎｔｅｘｔのコピーを作成する。コピーは、独立のトランザクション、キャッシュ、および更新状態を持つ。キャッシュは、最初は空になる。クローン作成されたＩｔｅｍＣｏｎｔｅｘｔを使用することは、同じ（複数の）アイテムドメインを使用して新しいＩｔｅｍＣｏｎｔｅｘｔを開くことよりも効率的であると予想される。
public ItemContext Clone();
//ＩｔｅｍＣｏｎｔｅｘｔを閉じる。閉じられた後にＩｔｅｍＣｏｎｔｅｘｔを使用しようとすると、ＯｂｊｅｃｔＤｉｓｐｏｓｅｄＥｘｃｅｐｔｉｏｎが発生する。
public void Close();
void IDisposable.Dispose();
//ＩｔｅｍＣｏｎｔｅｘｔが開かれたときに指定されたドメインがリモートコンピュータに解決する場合にＴｒｕｅ。
public bool IsRemote {get;}
//要求されたサービス型を供給することができるオブジェクトを返す。要求されたサービスを提供できない場合にはＮＵＬＬを返す。ＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒパターンを使用すると、通常は使用されない、また使用すれば開発者を混乱させる可能性のあるＡＰＩをＩｔｅｍＣｏｎｔｅｘｔクラスから取り除くことができる。ＩｔｅｍＣｏｎｔｅｘｔは、サービスＩＩｔｅｍＳｅｒｉａｌｉｚａｔｉｏｎ、ＩＳｔｏｒｅＯｂｊｅｃｔＣａｃｈｅを提供することができる。
public object GetService(Type serviceType);
関係するメンバを更新する
//修正されたすべてのオブジェクトおよびＭａｒｋＦｏｒＣｒｅａｔｅまたはＭａｒｋＦｏｒＤｅｌｅｔｅに渡されるすべてのオブジェクトにより表される変更を保存する。更新競合が検出された場合にはＵｐｄａｔｅＣｏｌｌｉｓｉｏｎＥｘｃｅｐｔｉｏｎをスローすることがある。
public void Update();
//指定されたオブジェクトにより表される変更を保存する。オブジェクトは、修正されたか、またはＭａｒｋＦｏｒＣｒｅａｔｅまたはＭａｒｋＦｏｒＤｅｌｅｔｅに渡されていなければならないが、そうでなければＡｒｇｕｍｅｎｔ−Ｅｘｃｅｐｔｉｏｎがスローされる。更新競合が検出された場合にはＵｐｄａｔｅＣｏｌｌｉｓｉｏｎＥｘｃｅｐｔｉｏｎをスローすることがある。
public void Update(object objectToUpdate);
public void Update(IEnumerable objectsToUpdate);
//ストアからの指定されたオブジェクトの内容をリフレッシュする。オブジェクトが修正されている場合、変更は上書きされ、オブジェクトはもはや修正されたとみなされない。アイテム、アイテム拡張、または関係オブジェクト以外のものが指定されている場合、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public void Refresh(object objectToRefresh);
public void Refresh(IEnumerable objectsToRefresh);
//修正されたオブジェクトが取り出されたときから、それを保存しようとしたときまでの間にストア内でデータが変更されたことを更新で検出した場合に発生する。イベントハンドラが登録されていないない場合、更新は例外をスローする。イベントハンドラが登録されている場合、例外をスローし、更新を中断することができ、それにより、修正されたオブジェクトはストア内のデータを上書きするか、またはストアおよびオブジェクト内で加えられた変更をマージする。
public event ChangeCollisionEventHandler UpdateCollision;
//更新処理中の様々な時点において発生し、更新進捗情報を供給する。
public event UpdateProgressEventhandler UpdateProgress;
//Ｕｐｄａｔｅの非同期バージョン
public IAsyncResult BeginUpdate(IAsyncCallback callback, object state);
public IAsyncResult BeginUpdate(object objectToUpdate, IAsyncCallback callback, object state);
public IAsyncResult BeginUpdate(IEnumerable objectsToUpdate, IAsyncCallback callback, object state);
public void EndUpdate(IAsyncResult result);
//Ｒｅｆｒｅｓｈの非同期バージョン
public IAsyncResult BeginRefresh(object objectToRefresh, IAsyncCallback callback, object state);
public IAsyncResult BeginRefresh(IEnumerable objectsToRefresh, IAsyncCallback callback, object state);
public void EndRefresh(IAsyncResult result);
関係メンバのトランザクション処理
//指定された孤立レベルを持つトランザクションを開始する。既定の孤立レベルはＲｅａｄＣｏｍｍｉｔｅｄである。すべての場合において、分散トランザクションが開始されるが、それは、変更ストリーム型付きアイテムプロパティを包含しなければならない場合があるからである。
public Transaction BeginTransaction();
public Transaction BeginTransaction(System.Data.IsolationLevel isolationLevel);
関係メンバを検索する
//指定された型のオブジェクトについてこのアイテムコンテクスト内で検索するＩｔｅｍＳｅａｒｃｈｅｒを作成する。アイテム、関係、またはアイテム拡張以外の型が指定されている場合、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public ItemSearcher GetSearcher(Type type);
//ｉｄを与えられているアイテムを見つける。
public Item FindItemById(ItemId itemId);
//パスを与えられているアイテムを見つける。パスは絶対パスでも相対パスでもよい。相対パスであれば、ＩｔｅｍＣｏｎｔｅｘｔが開かれたときに複数のアイテムドメインが指定されている場合、ＮｏｔＳｕｐｐｏｒｔｅｄＥｘｃｅｐｔｉｏｎがスローされる。そのようなアイテムが存在しない場合には、ＮＵＬＬを返す。アイテムを取り出すために＼＼ｍａｃｈｉｎｅ＼ｓｈａｒｅへの接続をドメインの一部として作成する。アイテムは、そのドメインに関連付けられる。
public Item FindItemByPath(string path);
//パスを与えられているアイテムを見つける。パスは、指定されたアイテムドメインに相対的である。アイテムを取り出すために指定されたドメインへの接続を作成する。アイテムは、そのドメインに関連付けられる。そのようなアイテムが存在しない場合には、ＮＵＬＬを返す。
public Item FindItemByPath (string domain, string path);
//パスを与えられているアイテムの集合を見つける。パスは、ＩｔｅｍＣｏｎｔｅｘｔが開かれたときに指定されたアイテムドメインに相対的である。そのようなアイテムが存在しない場合には、空を返す。
public FindResult FindAllItemsByPath(string path);
//ｉｄを与えられている関係を見つける。
public Relatioinship FindRelationshipById(ItemId itemID, RelationshipId relationshipId);
//ｉｄを与えられているアイテム拡張を見つける。
public ItemExtension FindItemExtensionById(ItemId itemId, ItemExtensionId itemExtensionId);
//与えられたフィルタ条件をオプションにより満たす指定された型のすべてのアイテム、関係、またはアイテム拡張を見つける。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public FindResult FindAll(Type type);
public FindResult FindAll(Type type, string filter);
//与えられたフィルタ条件を満たす指定された型の任意のアイテム、関係、またはアイテム拡張を見つける。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。そのようなオブジェクトが見つからない場合、ＮＵＬＬを返す。
public object FindOne(Type type, string filter);
//与えられたフィルタ条件を満たす指定された型のアイテム、関係、またはアイテム拡張を見つける。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。そのようなオブジェクトが見つからない場合、ＯｂｊｅｃｔＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。複数のオブジェクトが見つからなかった場合、ＭｕｌｔｉｐｌｅＯｂｊｅｃｔｓＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。
public object FindOnly(Type type, string filter);
//与えられたフィルタ条件を満たす指定された型のアイテム、関係、またはアイテム拡張が存在する場合、ｔｒｕｅを返す。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public bool Exists(Type type, string filter);
//検索により返されるオブジェクトがＩｔｅｍＣｏｎｔｅｘｔにより保持されるオブジェクト識別マップにどのように関係するかを指定する。
public SearchCollisionMode SearchCollisionMode {get; set;}
//ＲｅｓｕｌｔＭａｐｐｉｎｇについてＰｒｅｓｅｒｖｅＭｏｄｉｆｉｅｄＯｂｊｅｃｔｓが指定されている場合に発生する。このイベントにより、アプリケーションは、検索により取り出されたデータとともに修正されたオブジェクトを選択的に更新することができる。
public event ChangeCollisionEventHandler SearchCollision;
//他のＩｔｅｍＣｏｎｔｅｘｔからのオブジェクトをこのアイテムコンテクストに組み込む。同じアイテム、関係、アイテム拡張を表すオブジェクトがすでに存在しているわけではない場合、このＩｔｅｍＣｏｎｔｅｘｔの識別マップ、オブジェクトのクローンが作成され、マップに追加される。オブジェクトが存在する場合、これは、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎＭｏｄｅと一致する方法で指定されたオブジェクトの状態および内容とともに更新される。
public Item IncorporateItem(Item item);
public Relationship IncorporateRelationship(Relationship relationship);
public ItemExtension IncorporateItemExtension(ItemExtension itemExtension);
}
//ＩｔｅｍＣｏｎｔｅｘｔ．ＵｐｄａｔｅＣｏｌｌｉｓｉｏｎおよびＩｔｅｍＳｅａｒｃｈｅｒ．ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントのハンドラ。
public delegate void ChangeCollisionEventHandler(object source, ChangeCollisionEventArgs args);
//ＣｈａｎｇｅＣｏｌｌｉｓｉｏｎＥｖｅｎｔＨａｎｄｌｅｒデリゲートの引数。
public class ChangeCollisionEventArgs : EventArgs
{
//修正されたアイテム、アイテム拡張、または関係オブジェクト。
public object ModifiedObject {get;}
//ストアからのプロパティ。
public IDictionary StoredProperties {get;}
}
//ＩｔｅｍＣｏｎｔｅｘｔ．ＵｐｄａｔｅＰｒｏｇｒｅｓｓのハンドラ。
public delegate void UpdateProgressEventHandler(ItemContext itemContext, UpdateProgressEventArgs args);
//ＵｐｄａｔｅＰｒｏｇｒｅｓｓＥｖｅｎｔＨａｎｄｌｅｒデリゲートの引数。
public class ChangeCollisionEventArgs : EventArgs
{
//現在の更新オペレーション。
public UpdateOperation CurrentOperation {get;}
//現在更新中のオブジェクト。
public object CurrentObject {get;}
}
//検索により返されるオブジェクトがＩｔｅｍＣｏｎｔｅｘｔにより保持されるオブジェクト識別マップにどのように関係するかを指定する。
public enum SearchCollisionMode
{
//新しいオブジェクトを作成し、返さなければならないことを示す。識別マップ内の同じアイテム、アイテム拡張、または関係を表すオブジェクトは無視される。このオプションが指定されている場合、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントは発生しない。
DoNotMapSearchResults,
//識別マップからのオブジェクトを返さなければならないことを示す。オブジェクトの内容がアプリケーションにより修正された場合、修正されたオブジェクトの内容は保存される。オブジェクトが修正されていなかった場合、その内容は検索により返されたデータとともに更新される。Ａｐｐｌｉｃａｔｉｏｎは、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントに対するハンドラを用意し、必要に応じてオブジェクトを選択的に更新することができる。
PreserveModifiedObjects,
//識別マップからのオブジェクトを返さなければならないことを示す。オブジェクトの内容は、そのオブジェクトがアプリケーションにより修正されていたとしても、検索により返されたデータとともに更新される。このオプションが指定されている場合、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントは発生しない。
OverwriteModifiedObjects
}
//現在の更新オペレーション。
public enum UpdateOperation
{
//Ｕｐｄａｔｅが最初に呼び出されたときに与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔはｎｕｌｌとなる。
OverallUpdateStarting,
//更新が成功した後、Ｕｐｄａｔｅが戻る直前に与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔはＮＵＬＬとなる。
OverallUpdateCompletedSucessfully,
//Ｕｐｄａｔｅが例外をスローする直前に与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔは、例外オブジェクトとなる。
OverallUpdateCompletedUnsuccessfully,
//オブジェクトの更新が開始したときに与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔは、更新に使用されるオブジェクトを参照する。
ObjectUpdateStarting,
//新しい接続が必要な場合に与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔは、ＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎに渡されるようなアイテムドメインを識別するパスを含む文字列となる。関係のＬｏｃａｔｉｏｎフィールドから開くか、または取り出す。
OpeningConnection
}
}
付録Ｂ
namespace System.Storage
{
//アイテムコンテクスト内の特定の型について検索を実行する。
public class ItemSearcher
{
コンストラクタ
Figure 0004394644
 プロパティ
//マッチするオブジェクトを識別するために使用されるフィルタ。
public SearchExpressionCollection Filters {get;}
//検索されるドメインを指定するＩｔｅｍＣｏｎｔｅｘｔ。
public ItemContext ItemContext {get; set;}
//検索パラメータコレクション。
public ParameterCollection Parameters {get;}
//サーチャーが動作する型。単純検索では、これは、返されるオブジェクトの型である。
public Type TargetType {get; set;}
検索メソッド
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅのオブジェクトを見つける。そのようなオブジェクトが存在しない場合には、空のＦｉｎｄＲｅｓｕｌｔを返す。
public FindResult FindAll();
public FindResult FindAll(FindOptions findOptions);
public FindResult FindAll(params SortOption[] sortOptions);
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅの１つのオブジェクトを見つける。
//そのようなオブジェクトが存在しない場合、ＮＵＬＬを返す。
public object FindOne();
public object FindOne(FindOptions findOptions);
public object FindOne(params SortOption[] sortOptions);
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅのオブジェクトを見つける。
//そのようなオブジェクトが見つからない場合、ＯｂｊｅｃｔＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。複数のオブジェクトが見つからなかった場合、ＭｕｌｔｉｐｌｅＯｂｊｅｃｔｓＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。
public object FindOnly();
public object FindOnly(FindOptions findOptions);
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅのオブジェクトが存在するかどうかを判別する。
public bool Exists();
//同じ検索を繰り返し効率よく実行するために使用することができるオブジェクトを作成する。
public PreparedFind PrepareFind();
Figure 0004394644
Figure 0004394644
Figure 0004394644
Figure 0004394644
付録Ｃ
namespace System.Storage
{
public abstract class FindResult : IAsyncObjectReader
{
public FindResult ();
//ＦｉｎｄＲｅｓｕｌｔを結果の中の次の位置に移動する。
public bool Read ();
public IAsyncResult BeginRead(AsyncCallback callback, object state);
public bool EndRead(IAsyncResult asyncResult);
//現在のオブジェクト。
public object Current {get;}
//ＦｉｎｄＲｅｓｕｌｔがオブジェクトを含むかどうかを返す。
public bool HasResults {get;}
//ＦｉｎｄＲｅｓｕｌｔが閉じられているかどうかを返す。
public bool IsClosed {get;}
//このＦｉｎｄＲｅｓｕｌｔ内のアイテムの型を返す。
public Type ObjectType {get;}
//ＦｉｎｄＲｅｓｕｌｔを閉じる。
public void Close();
void IDisposable.Dispose();
//現在位置から始まる、ＦｉｎｄＲｅｓｕｌｔ上の列挙子を返す。ＦｉｎｄＲｅｓｕｌｔ上の列挙子を進めることで、すべての列挙子が進むだけでなく、ＦｉｎｄＲｅｓｕｌｔ自体も進む。
IEnumerator IEnumerable.GetEnumerator();
public FindResultEnumerator GetEnumerator();
}
public abstract class FindResultEnumerator : IEnumerator, IDisposable
{
public abstract object Current {get;}
public abstract bool MoveNext();
public abstract void Reset();
public abstract void Close();
void IDisposable.Dispose();
}
}
namespace System
{
//オブジェクト上で繰り返すための共通インターフェース
public interface IObjectReader : IEnumerable, IDisposable
Figure 0004394644
本発明の複数の態様が組み込まれうるコンピュータシステムを表すブロック図である。 ３つのコンポーネントグループであるハードウェアコンポーネント、ハードウェア／ソフトウェアインターフェースシステムコンポーネント、およびアプリケーションプログラムコンポーネントに分割されたコンピュータシステムを例示するブロック図である。 ファイルベースのオペレーティングシステムにおけるディレクトリ内の複数のフォルダにグループ化されているファイルの従来のツリーベースの階層構造を例示する図である。 本発明によるストレージプラットフォームを例示するブロック図である。 本発明の様々な実施形態におけるＩｔｅｍ、Ｉｔｅｍ Ｆｏｌｄｅｒｓ、およびＣａｔｅｇｏｒｉｅｓ間の構造的関係を例示する図である。 Ｉｔｅｍの構造を例示するブロック図である。 図５ＡのＩｔｅｍの複合プロパティ型を例示するブロック図である。 複合型がさらに記述されている（明示的にリストされている）「Ｌｏｃａｔｉｏｎ」Ｉｔｅｍを例示するブロック図である。 Ｂａｓｅ ＳｃｈｅｍａにあるＩｔｅｍの子型としてＩｔｅｍを例示する図である。 継承型が明示的にリストされている（イミディエイトプロパティの他に）図６Ａの子型Ｉｔｅｍを例示するブロック図である。 ２つの最上位レベルのクラス型を含むＢａｓｅ Ｓｃｈｅｍａ、ＩｔｅｍおよびＰｒｏｐｅｒｔｙＢａｓｅ、およびそれから派生した追加Ｂａｓｅ Ｓｃｈｅｍａ型を例示するブロック図である。 Ｃｏｒｅ Ｓｃｈｅｍａ内のＩｔｅｍを例示するブロック図である。 Ｃｏｒｅ Ｓｃｈｅｍａ内のプロパティ型を例示するブロック図である。 Ｉｔｅｍ Ｆｏｌｄｅｒ、そのメンバＩｔｅｍ、およびＩｔｅｍ ＦｏｌｄｅｒとそのメンバＩｔｅｍとの間の相互接続のＲｅｌａｔｉｏｎｓｈｉｐｓを例示するブロック図である。 Ｃａｔｅｇｏｒｙ（またも、Ｉｔｅｍ自体である）、そのメンバＩｔｅｍ、およびＣａｔｅｇｏｒｙとそのメンバＩｔｅｍとの間の相互接続のＲｅｌａｔｉｏｎｓｈｉｐｓを例示するブロック図である。 本発明による、ストレージプラットフォームのデータモデルの参照型階層を例示する図である。 本発明の一実施形態により、関係を分類する方法を例示する図である。 本発明の一実施形態により、通知メカニズムを例示する図である。 ２つのトランザクションが両方とも新しいレコードを同じＢ−Ｔｒｅｅ内に挿入する実施例を示す図である。 本発明の一実施形態により、データ変更検出プロセスを例示する図である。 例示的なディレクトリツリーを示す図である。 本発明の一態様によりディレクトリベースのファイルシステムの既存のフォルダがストレージプラットフォームのデータストアに移動される実施例を示す図である。 本発明の一態様によるＣｏｎｔａｉｎｍｅｎｔ Ｆｏｌｄｅｒｓの概念を示す図である。 ストレージプラットフォームＡＰＩの基本アーキテクチャを例示する図である。 ストレージプラットフォームＡＰＩスタックの様々なコンポーネントを表す概略図である。 例示的なＣｏｎｔａｃｔｓスキーマ（ＩｔｅｍとＥｌｅｍｅｎｔｓ）の関係図である。 例示的なＣｏｎｔａｃｔｓスキーマ（ＩｔｅｍとＥｌｅｍｅｎｔｓ）の関係図である。 本発明の一態様によるストレージプラットフォームＡＰＩのランタイムフレームワークを示す図である。 本発明の一実施形態による、ＦｉｎｄＡｌｌオペレーションの実行を例示する図である。 本発明の一態様により、ストレージプラットフォームのＳｃｈｅｍａからストレージプラットフォームＡＰＩクラスを生成するプロセスを例示する図である。 本発明の他の態様による、Ｆｉｌｅ ＡＰＩが基づくスキーマを例示する図である。 本発明の一実施形態により、データセキュリティの目的に使用されるアクセスマスク形式を例示する図である。 本発明の一態様の一実施形態による、既存のセキュリティ領域から切り出される新しいまったく同じように保護されているセキュリティ領域を示す図である。 本発明の一態様の一実施形態による、Ｉｔｅｍ検索ビューの概念を例示する図である。 本発明の一実施形態による、例示的なＩｔｅｍ階層を例示する図である。

Claims (16)

  1. ストレージプラットフォームを提供するためのコンピュータシステムであって、
    既存のファイルシステムを含むデータベースエンジンと、
    データを格納するために前記データベースエンジン上に実装されるデータストアであって、当該データストア内のデータは、型がスキーマで記述されている、データストアと、
    異なる型のアイテム、要素、および関係を定義するスキーマの集合と、
    アプリケーションプログラムが、前記ストレージプラットフォームのサービスおよび機能にアクセスすること、および前記データストア内の型がスキーマで記述されているデータにアクセスすることを可能にする、アプリケーションプログラミングインターフェースと
    を備え、
    前記データストア内のデータは、アイテム、要素、および関係について定義され、各アイテムは、前記データストア内に格納されるデータの基本ユニットであり、１つまたは複数の要素を含み、各要素は、１つまたは複数のフィールドを含む型のインスタンスであり、関係は、少なくとも２つのアイテムの間のリンクであり、
    前記アプリケーションプログラミングインターフェースは、前記スキーマの集合で定義された前記異なる型のアイテム、要素、および関係のそれぞれに対するクラスを含むことによって、アプリケーションが、前記データストア内の前記型がスキーマで記述されているデータにアクセスすることを可能にし、
    前記データストアは、アプリケーションプログラムによる前記データに対する変更を示す通知を受け取り、変更を追跡するための機能を備えたことを特徴とするコンピュータシステム。
  2. データは、既存の型のアイテムの拡張であるアイテム拡張として前記データストアに格納され、前記アプリケーションプログラミングインターフェースは、それぞれの異なるアイテム拡張に対するクラスを含むことを特徴とする請求項１に記載のコンピュータシステム。
  3. アイテム、要素、および関係のそれぞれの型に対する前記クラスは、アイテム、要素、および関係のそれぞれの型を定義する前記スキーマの集合に基づき自動的に生成されることを特徴とする請求項１に記載のコンピュータシステム。
  4. アイテム、要素、および関係のそれぞれの型に対する前記クラスは、データクラスの集合を定義し、前記アプリケーションプログラミングインターフェースは、前記データクラスに対するビヘイビアの共通集合を定義するクラスの第２の集合をさらに含むことを特徴とする請求項１に記載のコンピュータシステム。
  5. クラスの前記第２の集合は、ストレージプラットフォームスコープを表し、前記データストアに対するクエリのコンテクストを提供する第１のクラス、および前記データストアに対するクエリの結果を表す第２のクラスを含むことを特徴とする請求項４に記載のコンピュータシステム。
  6. 前記データストア内の前記異なる型のアイテム、要素、および関係は、ユーザ定義型として前記データベースエンジン内に実装されることを特徴とする請求項１に記載のコンピュータシステム。
  7. 前記アプリケーションプログラミングインターフェースは、前記データストア内の前記アイテムに含まれる１つまたは複数の要素に基づいて、クエリを形成するためのクエリモデルを提供することを特徴とする請求項６に記載のコンピュータシステム。
  8. 前記データストア内の複数のアイテムは、Ｉｔｅｍ Ｆｏｌｄｅｒ、および前記Ｉｔｅｍ Ｆｏｌｄｅｒのメンバである少なくとも１つの他のアイテムを含むことができることを特徴とする請求項１に記載のコンピュータシステム。
  9. 前記データストア内の複数のアイテムは、Ｃａｔｅｇｏｒｙ、および前記Ｃａｔｅｇｏｒｙのメンバである少なくとも１つの他のアイテムを含むことができることを特徴とする請求項１に記載のコンピュータシステム。
  10. ２つのアイテムの間の関係は、当該コンピュータシステムと当該コンピューティングシステム上で実行される任意のアプリケーションとの間のインターフェースとして機能するハードウェア／ソフトウェアインターフェースシステムによって、自動的に確立されることを特徴とする請求項１に記載のコンピュータシステム。
  11. 関係は、要素を含むことを特徴とする請求項１に記載のコンピュータシステム。
  12. スキーマの前記集合は、ストレージプラットフォームが所定の、予測可能な方法でＣｏｒｅ Ｉｔｅｍの前記集合を理解し、直接処理する際に使用するＣｏｒｅ Ｉｔｅｍの集合を定義するＣｏｒｅ Ｓｃｈｅｍａを含むことを特徴とする請求項１に記載のコンピュータシステム。
  13. Ｃｏｒｅ Ｉｔｅｍの前記集合内で定義されたアイテムのそれぞれの型は、単一の共通基本アイテムから派生することを特徴とする請求項１２に記載のコンピュータシステム。
  14. 前記単一の共通基本アイテムは、基本スキーマ内の基礎的なアイテムであることを特徴とする請求項１３に記載のコンピュータシステム。
  15. 前記データベースエンジンは、リレーショナルデータベースエンジンを含むことを特徴とする請求項１に記載のコンピュータシステム。
  16. 前記リレーショナルデータベースエンジンは、オブジェクトリレーショナル拡張を有するリレーショナルデータベースエンジンを含むことを特徴とする請求項１５に記載のコンピュータシステム。
JP2005509111A 2003-08-21 2003-08-21 データの編成、検索、および共有のためのストレージプラットフォーム Expired - Fee Related JP4394644B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2003/027419 WO2005029314A1 (en) 2003-08-21 2003-08-21 Storage platform for organizing, searching, and sharing data

Publications (2)

Publication Number Publication Date
JP2007521537A JP2007521537A (ja) 2007-08-02
JP4394644B2 true JP4394644B2 (ja) 2010-01-06

Family

ID=34374773

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005509111A Expired - Fee Related JP4394644B2 (ja) 2003-08-21 2003-08-21 データの編成、検索、および共有のためのストレージプラットフォーム

Country Status (4)

Country Link
EP (1) EP1656610A4 (ja)
JP (1) JP4394644B2 (ja)
AU (1) AU2003270058A1 (ja)
WO (1) WO2005029314A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7702802B2 (en) 2004-12-03 2010-04-20 Microsoft Corporation Sharing framework for resource sharing
CN100445997C (zh) * 2005-12-30 2008-12-24 英业达股份有限公司 数据同步方法与系统
US9143563B2 (en) * 2011-11-11 2015-09-22 Rockwell Automation Technologies, Inc. Integrated and scalable architecture for accessing and delivering data
WO2020037608A1 (zh) * 2018-08-23 2020-02-27 西门子股份公司 人工智能计算设备、控制方法及装置、工程师站及工业自动化系统
US20210004743A1 (en) * 2019-07-03 2021-01-07 Gustavo Zarrate-Cardenas Methods and systems for facilitating exploration of data to evaluate activities and behavioral patterns for making decisions
CN111104456A (zh) * 2019-10-12 2020-05-05 深圳壹账通智能科技有限公司 数据持久化存储方法、装置、计算机设备及存储介质
US11940960B2 (en) 2022-04-21 2024-03-26 Folder Front, LLC Intelligent folder-based data organization system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136712A (en) * 1989-06-29 1992-08-04 Digital Equipment Corporation Temporary object handling system and method in an object based computer operating system
US6078925A (en) * 1995-05-01 2000-06-20 International Business Machines Corporation Computer program product for database relational extenders
US6519597B1 (en) * 1998-10-08 2003-02-11 International Business Machines Corporation Method and apparatus for indexing structured documents with rich data types
US6338056B1 (en) * 1998-12-14 2002-01-08 International Business Machines Corporation Relational database extender that supports user-defined index types and user-defined search
US6199195B1 (en) * 1999-07-08 2001-03-06 Science Application International Corporation Automatically generated objects within extensible object frameworks and links to enterprise resources
AU2001271802A1 (en) 2000-07-03 2002-01-14 Oculus Technologies Corporation Access control for a decentralized or emergent model on a computer network
US6999956B2 (en) * 2000-11-16 2006-02-14 Ward Mullins Dynamic object-driven database manipulation and mapping system
US6697818B2 (en) * 2001-06-14 2004-02-24 International Business Machines Corporation Methods and apparatus for constructing and implementing a universal extension module for processing objects in a database

Also Published As

Publication number Publication date
WO2005029314A1 (en) 2005-03-31
EP1656610A4 (en) 2008-06-11
JP2007521537A (ja) 2007-08-02
EP1656610A1 (en) 2006-05-17
AU2003270058A1 (en) 2005-04-11

Similar Documents

Publication Publication Date Title
JP4394643B2 (ja) アイテムベースのストレージプラットフォームにおけるデータモデリングのためのシステムおよび方法
US7555497B2 (en) Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization
US7428546B2 (en) Systems and methods for data modeling in an item-based storage platform
US7483915B2 (en) Systems and method for representing relationships between units of information manageable by a hardware/software interface system
US8131739B2 (en) Systems and methods for interfacing application programs with an item-based storage platform
US7739316B2 (en) Systems and methods for the implementation of base schema for organizing units of information manageable by a hardware/software interface system
US7349913B2 (en) Storage platform for organizing, searching, and sharing data
US7529811B2 (en) Systems and methods for the implementation of a core schema for providing a top-level structure for organizing units of information manageable by a hardware/software interface system
AU2003259961B2 (en) Systems and methods for interfacing application programs with an item-based storage platform
JP4583377B2 (ja) ハードウェア／ソフトウェアインターフェースシステムにより管理可能な情報のユニットに対する関係および階層の同期サービスを実現するシステムおよび方法
JP4583376B2 (ja) ハードウェア／ソフトウェアインタフェースシステムにより管理可能な情報のユニットに対する同期処理サービスを実現するシステムおよび方法
US20050055354A1 (en) Systems and methods for representing units of information manageable by a hardware/software interface system but independent of physical representation
JP4583375B2 (ja) 同期スキーマの実装のためのシステム
JP4580390B2 (ja) ハードウェア／ソフトウェアインターフェイスシステムによって管理可能な情報単位の拡張および継承のためのシステムおよび方法
JP4394644B2 (ja) データの編成、検索、および共有のためのストレージプラットフォーム
RU2371757C2 (ru) Системы и способы моделирования данных в основанной на предметах платформе хранения
RU2412461C2 (ru) Системы и способы сопряжения прикладных программ с платформой хранения на основе статей
ZA200600644B (en) Systems and methods for interfacing application programs with an item-based storage platform

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090522

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090824

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090915

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20091015

R150 Certificate of patent or registration of utility model

Ref document number: 4394644

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121023

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131023

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees