(57)【要約】【課題】ファイルシステムアイテムおよび関連エンティティのシリアライゼーション・デシリアライゼーションのためのシステムおよび方法を提供する。【解決手段】ファイルシステム「アイテム」はコアクラスを含み、コアクラスはプロパティを含み得る。アイテムは、単純アイテムでも複合アイテム（例えばその中に埋め込まれた他のアイテムを含む）でもよい。アイテムには、フラグメント、他のアイテムへのリンク、エクステンション等のエンティティが関連づけられる。シリアライゼーションシステムは、アイテムに関連するエンティティを識別する識別コンポーネントと、アイテムおよび関連エンティティをシリアライズするシリアライゼーションコンポーネントとを含む。シリアライゼーションコンポーネントは、アイテムおよび関連エンティティに関連する情報を含むヘッダをシリアライズすることもできる。【選択図】図１
2006236328.tif 000002
【特許請求の範囲】
【請求項１】
シリアライゼーションシステムにおいて、
アイテムに関連するエンティティを識別する識別コンポーネントと、
前記アイテムと、前記関連エンティティと、前記アイテムおよび関連エンティティに関連する情報を提供するヘッダとをシリアライズするシリアライゼーションコンポーネントと
を備えたことを特徴とするシリアライゼーションシステム。
【請求項２】
前記関連エンティティが、出リンク、入リンク、埋込みアイテム、エクステンション、アイテムフラグメントおよびバッキングファイルの少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記アイテムおよび関連エンティティのシリアライゼーションの開始が要求に基づくことを特徴とする請求項１に記載のシステム。
【請求項４】
前記関連エンティティの識別が、前記要求に関連するコンテクストに関連するセキュリティ情報に少なくとも部分的に基づくことを特徴とする請求項３に記載のシステム。
【請求項５】
前記関連エンティティの識別が、前記関連エンティティに関連するアクセス制御リストにさらに基づくことを特徴とする請求項４に記載のシステム。
【請求項６】
前記ヘッダが、前記アイテムおよび前記関連エンティティへのランダムアクセスを容易にすることを特徴とする請求項１に記載のシステム。
【請求項７】
前記システムと、前記アイテムのシリアライゼーションに関連するアプリケーションとの間の通信を容易にするアプリケーションプログラムインタフェースをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項８】
前記アプリケーションプログラムインタフェースが、前記アイテムおよび前記関連エンティティのエクスポート、バックアップ、リストアおよびコピーの少なくとも１つを容易にすることを特徴とする請求項７に記載のシステム。
【請求項９】
前記アプリケーションプログラムインタフェースがシリアライゼーションオプションに関連する情報を受け取り、該シリアライゼーションオプションは、複数の関連エンティティのうちのいずれを前記アイテムとともにシリアライズすべきかを選択するために使用されることを特徴とする請求項７に記載のシステム。
【請求項１０】
前記アプリケーションプログラムインタフェースがファイルシステムレベルで公開されることを特徴とする請求項７に記載のシステム。
【請求項１１】
前記アプリケーションプログラムインタフェースがストアドプロシジャレベルで公開されることを特徴とする請求項７に記載のシステム。
【請求項１２】
前記アプリケーションプログラムインタフェースが前記シリアライゼーションをバイト配列として返すことを特徴とする請求項７に記載のシステム。
【請求項１３】
前記アプリケーションプログラムインタフェースが前記シリアライゼーションに関連するポインタまたはファイル名を返すことを特徴とする請求項７に記載のシステム。
【請求項１４】
前記関連エンティティが埋込みアイテムを含み、前記システムがさらに、該埋込みアイテムを再帰的にシリアライズすることを特徴とする請求項１に記載のシステム。
【請求項１５】
請求項１に記載のシステムによって生成された前記シリアライゼーションを受け取ることを特徴とするデシリアライゼーションシステム。
【請求項１６】
アイテムのシリアライゼーションを容易にする方法において、
前記アイテムをシリアライズし、
前記アイテムに関連する少なくとも１つのエンティティを識別し、
前記関連エンティティをシリアライズする
ことを特徴とする、アイテムのシリアライゼーションを容易にする方法。
【請求項１７】
前記アイテムをシリアライズすることを求める要求を受け取ること、
前記アイテムおよび関連エンティティに関連する情報を含むヘッダをシリアライズすること、
シリアライゼーション長およびヘッダオフセットをシリアライズすること
の少なくとも１つをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記関連エンティティが、出リンク、入リンク、埋込みアイテム、エクステンション、アイテムフラグメント、セキュリティ情報およびバッキングファイルの少なくとも１つを含むことを特徴とする請求項１６に記載の方法。
【請求項１９】
請求項１６に記載の方法を実行するためのコンピュータ実行可能命令を格納したことを特徴とするコンピュータ可読媒体。
【請求項２０】
２つ以上のコンピュータコンポーネント間で伝送される、アイテムのシリアライズされた転送を容易にするデータパケットにおいて、
シリアライゼーション長フィールドと、
ヘッダオフセットフィールドと、
コアアイテムフィールドと、
少なくとも１つの関連エンティティを含むフィールドと、
前記アイテムおよび関連エンティティに関連する情報を提供するヘッダフィールドと
を備えたことを特徴とするデータパケット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にオブジェクトストレージシステムに関し、より詳細には、ファイルシステムアイテムおよび関連エンティティのシリアライゼーションおよび／またはデシリアライゼーションに関する。
【背景技術】
【０００２】
従来、コンピュータファイルシステムにおいて、ファイルはデータストレージ（データ記憶）の基本単位である。一般に、ファイルシステムにおけるファイルは以下の特性を有する。ファイルは単一のバイト列である。ファイルの長さは有限であり、通常、不揮発性記憶媒体に保存される。ファイルはディレクトリ内に作成され、ファイル操作において参照可能な名前を有し、場合によってはそのファイルのパスとともに用いられる。また、ファイルシステムが、パーミションビット等のファイル属性や、ファイルの作成、最終更新、および最終アクセス等のタイムスタンプのような他の情報をファイルに関連づけることもある。また、特定のアプリケーションが、ファイルのバイトストリーム内に領域固有のプロパティを保存することもできる。例えば、ワードプロセッサアプリケーションによって使用され、したがって「文書」とみなされるファイルは、その文書のタイトルや作成者のようなプロパティを記録しておくことが可能だ。これらのプロパティは、そのファイルを作成するアプリケーション固有のフォーマットでファイルのバイトストリーム内に保存される。それらのプロパティは、オブジェクトとして体系化されておらず、標準化された名前も有していない。バイトストリームは、体系化されていない値である。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
また、従来のコンピュータファイルシステムが提供しているファイル編成技法は、ユーザにとっての利用可能性が限られている。例えば、既存のアプリケーションは、ファイルの種々のタイプを編成し表示するために、ツリー構造のフォルダフォーマットを広く採用している。フォルダ、サブフォルダ、およびファイルの間の関係の一部を見ることはできるが、このような関係は適用範囲が限られ、主として、明示的なユーザ入力に依存する。例えば、ファイルは、ユーザによって示された共通のフォルダまたはサブフォルダに従って関係づけることができる。
【課題を解決するための手段】
【０００４】
以下に、本発明の諸態様の基本的理解を可能にするために、本発明の簡単な概要を提示する。この概要は、本発明の広範な概観ではない。この概要は、本発明の主要な要素を特定することや、本発明の範囲を画定することを意図していない。その唯一の目的は、後述するさらに詳細な説明への前触として、簡単な形で本発明のいくつかの概念を提示することである。
【０００５】
本発明は、ファイルシステムアイテムおよび関連エンティティのシリアライゼーションおよび／またはデシリアライゼーションを提供する。ファイルシステム「アイテム」はコアクラス（例えば連絡先）を含み、コアクラスはプロパティを含み得る。アイテムは、単純アイテムでも複合アイテム（例えばその中に埋め込まれた他のアイテムを含む）でもよい。アイテムには、フラグメント、他のアイテムへのリンクおよび／またはエクステンションのようなエンティティを関連づけることができる。シリアライゼーションにより、アイテムおよび関連エンティティ（もしあれば）の整合性のあるコピーを取得する（例えば、アイテムをトランスポートし、宛先システム上でそのアイテムを再構成するために）ことができる。
【０００６】
本発明の一態様によれば、シリアライゼーションシステムが提供される。シリアライゼーションシステムは、アイテムに関連するエンティティを識別する識別コンポーネントと、アイテムおよび関連エンティティをシリアライズするシリアライゼーションコンポーネントとを含む。シリアライゼーションコンポーネントはさらに、アイテムおよび関連エンティティに関連する情報を含むヘッダをシリアライズすることもできる。ヘッダは、アイテムおよび関連エンティティへのランダムアクセスを容易にする（例えば、読み手が関心のある部分のみを解釈／解析することを可能にする）。任意選択で、シリアライゼーションシステムは、アイテムおよびその関連エンティティをある場所から別の場所（例えば異なるコンピュータシステムおよび／またはリムーバブル媒体）へコピー、移動および／または転送することを容易にするアプリケーションプログラムインタフェース（ＡＰＩ）を公開することができる。
【０００７】
本発明のもう１つの態様は、アイテムおよびその関連エンティティをデシリアライズするために使用可能なアイテムデシリアライゼーションシステムを提供する。デシリアライゼーションシステムは、ヘッダを用いることにより、アイテムおよび関連エンティティにランダムアクセスすることができる（例えば、関心のある部分のみを解釈／解析できる）。デシリアライゼーションシステムは、ファイルシステムストアにアイテムストラクチャー（アイテム構造）を再作成することができる。
【０００８】
上記の目的および関連する目的を達成するため、本明細書において、以下の説明および添付図面を用いて本発明のいくつかの例示的態様を説明する。しかし、これらの態様は、本発明の原理を用いることができる種々の方法のほんの一部を示すに過ぎず、本発明は、すべてのこのような態様およびその均等物を含むことを意図している。本発明のその他の利点および新規な特徴は、以下の本発明の詳細な説明を図面とともに考慮することで明らかとなるであろう。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照して本発明について説明する。図中、同一参照番号は一貫して同一要素を指すために使用される。以下の説明では、説明の目的上、本発明の十分な理解を可能にするために数多くの具体的詳細が記載される。しかし、これらの具体的詳細なしで本発明を実施し得ることは明らかであろう。他の場合には、本発明の説明を容易にするために、周知の構造および装置（デバイス）はブロック図形式で示される。
【００１０】
本明細書で使用される場合、「コンポーネント」、「ハンドラ」、「モデル」、「システム」等の用語はコンピュータ関連のエンティティ（実体）を指すことを意図しており、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、あるいは実行中のソフトウェアのいずれかを問わない。例えば、コンポーネントは、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであり得るが、これらに限定されない。実例として、サーバ上で動作するアプリケーションおよびそのサーバの両方がコンポーネントであり得る。１つまたは複数のコンポーネントがプロセスおよび／または実行スレッド内に存在してもよいし、コンポーネントが１つのコンピュータに局在すること、および／または２つ以上のコンピュータに分散されることが可能である。また、これらのコンポーネントは、種々のデータストラクチャー（データ構造）が保存された種々のコンピュータ可読媒体から実行され得る。コンポーネントは、１つまたは複数のデータパケットを有する信号による等、ローカルおよび／またはリモートのプロセスを通じて通信され得る（例えば、あるコンポーネントが、ローカルシステム、分散システム内の別のコンポーネントと、および／またはインターネット等のネットワーク越しに他のシステムと、信号によりデータをやりとりする）。コンピュータコンポーネントは、例えばコンピュータ可読媒体上に保存できる。コンピュータ可読媒体としては、以下のものに限定されないが、本発明によれば、ＡＳＩＣ（特定用途向け集積回路）、ＣＤ（コンパクトディスク）、ＤＶＤ（ディジタルビデオディスク）、ＲＯＭ（読み出し専用メモリ）、フロッピー（登録商標）ディスク、ハードディスク、ＥＥＰＲＯＭ（電気的消去可能プログラム可能読み出し専用メモリ）およびメモリスティックがある。
【００１１】
本発明は、ファイルシステムアイテムおよび関連エンティティのシリアライゼーションおよび／またはデシリアライゼーションを提供する。本明細書で使用される場合、ファイルシステム「アイテム」はコアクラス（例えば連絡先）を含み、コアクラスはプロパティ（例えば名前、住所、電話番号）を含み得る。アイテム（項目）は、単純アイテムでも複合アイテム（例えばその中に埋め込まれた他のアイテムを含む）でもよい。アイテムには、フラグメント、他のアイテムへのリンク（例えばリレーションシップ）および／またはエクステンション（例えば追加プロパティ）のようなエンティティを関連づけることができる。
【００１２】
図１に、本発明の一態様によるシリアライゼーションシステム１００を例示する。システム１００は、アイテム（例えばコアアイテム）およびそのアイテムに関連するエンティティをシリアライズするために使用可能である。また、システム１００は、アイテムおよび関連エンティティに関連する情報を含むヘッダを生成しシリアライズすることもできる。
【００１３】
シリアライゼーションシステム１００は、アイテムに関連するエンティティを識別する識別コンポーネント１１０を含む。識別コンポーネント１１０は、ファイルシステムストア１２０からアイテムに関する情報を取得できる。後述するように、その情報としては、例えば、アイテムフラグメント、エクステンション、出リンク、入リンクおよび／または埋込みアイテムが挙げられる。
【００１４】
また、シリアライゼーションシステム１００は、アイテムおよび関連エンティティをシリアライズするシリアライゼーションコンポーネント１３０も含む。シリアライゼーションコンポーネント１３０は、さらに、アイテムおよび関連エンティティに関連する情報を含むヘッダを生成しシリアライズすることもできる。ヘッダは、アイテムおよび関連エンティティへのランダムアクセスを容易にする（例えば、読み手が関心のある部分のみを解釈／解析することを可能にする）。
【００１５】
簡単に図２を参照する。図２は、本発明の一態様による例示的なアイテムストラクチャーダイヤグラム２００を示している。本具体例では、コアアイテム２１０はプロパティを含み得る。例えば、コアアイテム２１０は、「名前」および「自宅電話番号」のプロパティを有する「連絡先」とすることができる。
【００１６】
コアアイテム２１０は、追加プロパティでコアアイテム２１０を拡張するために、特定のアプリケーションによって追加されるエクステンションを有し得る。「連絡先」コアアイテム２１０の例を続けると、電子メールアプリケーションが、エクステンションプロパティとして「電子メールアドレス」および「勤務先電話番号」を追加することによって、コアアイテム２１０のプロパティを拡張することができる。
【００１７】
次に、コアアイテム２１０は、０個、１個またはそれ以上の他のアイテム２３０にリンクされ得る。リンクは、出リンク２４０および／または入リンク２５０のいずれでもよい。出リンク２４０とは、コアアイテム２１０をソースとするコアアイテム２１０と他のアイテム２３０との間の結合を意味する。入リンク２５０とは、他のアイテム２３０をソースとするコアアイテム２１０とアイテム２３０との間の結合を意味する。出リンク２４０および／または入リンク２５０は型付けされていてもよい。したがって、リンク２４０、２５０は、アイテムの結合に対する関係機能（relational power）を提供する。例えば、リンク２４０、２５０は、「フレンド関係の日付（date of friendship）」および「格付け(rating)」という関連プロパティを有する「フレンド」型のものでもよい。さらに、リンク２４０、２５０は、アイテム間の結合を一意的に識別することが（例えばグローバル一意識別子を用いて）できる。
【００１８】
また、コアアイテム２１０は、埋込みアイテム２６０も含み得る。埋込みアイテム２６０は、本明細書ではまとめて複合アイテム(compound item)とも称する。例えば、「連絡先(contact)」型のコアアイテム２１０は、画像（例えば写真）からなる埋込みアイテム２６０を含み得る。本発明の一態様によれば、複合アイテムは、アイテムレベルの操作（例えばバックアップ、リストア、コピーおよび／またはエクスポート）による整合性のひとまとまりの単位とみなし得る。
【００１９】
コアアイテム２１０はフラグメント２７０を有し得る。フラグメント２７０は、アイテム型およびアイテムエクステンションに関して大きなコレクションの宣言を可能にするエンティティ型である。コレクションの要素は、キーを有するエンティティである。これは、アプリケーションが、所有側アイテムとは独立にコレクション内の要素にアクセスしそれを変更することを可能にする。コレクションを変更するために、所有側アイテム(owning item)を取得する必要はない。さらに、システムは、ネスト(入れ子)化された範囲の各要素の変更を追跡することができる。
【００２０】
コアアイテム２１０は、ファイルによってバックアップされることができ、あるいはＦｉｌｅＳｔｒｅａｍプロパティを有し得る。ファイルバックト（file backed）アイテムは、アイテムの一部がバッキングファイル２８０から昇格したアイテムである。
【００２１】
エクステンション２２０、出リンク２４０、入リンク２５０に関連する情報（例えばリンク識別子）、埋込みアイテム２６０、フラグメント２７０および／またはバッキングファイル２８０はまとめて、コアアイテム２１０の「関連エンティティ」と呼ぶことができる。コアアイテム２１０をシリアライズすることを求める要求が受け取られると、コアアイテム２１０および関連エンティティ（もしあれば）は、コアアイテム２１０の構造的完全性を保持するためにコピーされる。関連エンティティを含めることにより、シリアライゼーションストリームを受け取ったシステム（図示せず）は、コアアイテム２１０および関連エンティティをそれらの適切なコンテキストにおいて再構成することができる。
【００２２】
ダイヤグラム２００は、シリアライゼーションシステム１００で使用可能な例示的アイテムストラクチャーの要素を示している。当業者には認識されるように、本発明は、図２に示すアイテムストラクチャーに限定されない。本発明を実施するための任意の好適なアイテムストラクチャーが使用可能であり、すべてのそのようなアイテムストラクチャーは、添付の特許請求の範囲の記載の技術的範囲内に入るものとする。
【００２３】
図１および図２を参照すると、システム１００は、（例えば別のコンピュータシステムへトランスポートするために）コアアイテム２１０と、コアアイテム２１０の関連エンティティ（例えばエクステンション２２０、出リンク２４０、入リンク２５０に関連する情報（例えばリンク識別子）、埋込みアイテム２６０および／またはフラグメント２７０）をシリアライズするために使用可能である。識別コンポーネント１１０は、ファイルシステムストア１２０内のコアアイテム２１０を識別し、識別情報をシリアライゼーションコンポーネント１３０に提供する。また、識別コンポーネント１１０は、コアアイテム２１０に関連するエンティティを識別し、関連エンティティに関係する識別情報をシリアライゼーションコンポーネント１３０に提供する。
【００２４】
シリアライゼーションコンポーネント１３０は、シリアライゼーション中に埋められるヘッダのための空間を（例えば一時的に）割り当てることができる。本具体例では、シリアライゼーションコンポーネント１３０は以下を実行する：
１．ヘッダのための空間を割り当てる。
２．コアアイテム２１０をシリアライズする。
３．アイテムフラグメント２７０があれば、それをシリアライズする。
４．出リンク２４０があれば、それをシリアライズする。
５．入リンク識別子があれば、それをヘッダに入れる。
６．エクステンション２２０があれば、それをシリアライズする。
７．各埋込みアイテム２６０について、個々の埋込みアイテムをコアアイテム２１０として、アクト１〜８を再帰的に繰り返す。
８．バッキングファイルがあれば、それをシリアライズする。
９．シリアライゼーション長、ヘッダオフセットおよびヘッダ自体。
【００２５】
次に、図３に、本発明の一態様による例示的シリアライゼーションストラクチャー３００を示す。ストラクチャー（構造）３００は、例えばシリアライゼーションコンポーネント１３０によって、例えば次のように生成できる：
【００２６】
［テーブル１］
public class UdtSerialization
{
BinaryUdtSerialization bin;
}
【００２７】
ストラクチャー３００は、例えば次のように、シリアライゼーション長３２０およびヘッダオフセット３３０を含む。
【００２８】
［テーブル２］
public class BinaryUdtSerialization
{
// ストリーム内のシリアライゼーションのオフセット
long serializationOffset;
// シリアライゼーションの長さ
long serializationLength;
}
【００２９】
テーブル２に示したクラスは、ユーザ定義型（ＵＤＴ）のバイナリシリアライゼーションを解釈するために使用されるメタデータをサポートするために用いられる。
【００３０】
次に、ストラクチャー３００はコアアイテムセクション３４０を含む：
【００３１】
［テーブル３］
public class CoreItem : UdtSerialization
{ 
// ルートアイテムのアイテムＩＤ
SqlGuid itemId;
// コンテナのアイテムＩＤ
SqlGuid containerId;
// アイテムの名前空間名
SqlString naraespaceName;
// これはファイルバックトアイテムか？
bool isFileBacked;
// バッキングファイルがインライン化されている場合、そのバッキングファイルのオフセット
long backingFileOffset;
// バッキングファイルの長さ
long backingFileLength;
// ファイルバックトアイテムの属性を保存する
System.IO.FileAttributes fatFileAttributes;
// バッキングファイルの作成時
DateTime fileCreationTime;
// バッキングファイルの最終書き込み時
DateTime fileLastWriteTime;
// バッキングファイルの最終アクセス時
DateTime fileLastAccessTime;
// シリアライゼーション内のセキュリティディスクリプタのオフセット
long sdOffset;
// シリアライゼーション内のセキュリティディスクリプタの長さ
long sdLength;
// アイテムフラグメントのシリアライゼーションの先頭のオフセット
long itemFragmentOffset;
// シリアライゼーションに含まれるアイテムフラグメントの個数
long itemFragmentCount;
}
【００３２】
また、ストラクチャー３００は、例えば次のように、アイテムフラグメントセクション３５０を含む：
【００３３】
［テーブル４］
public class ItemFragmentHeader : UdtSerialization
{
// アイテムフラグメントのフラグメントＩＤ
private SqlGuid fragId;
// フラグメントのセットＩＤ
private SqlGuid setId;
}
【００３４】
次に、ストラクチャー３００は、例えば次のように、出リンクセクション３６０を含み得る：
【００３５】
［テーブル５］
public class LinkHeader : UdtSerialization
{
SqlGuid sourceItemId;
SqlGuid targetItemId;
SqlGuid linkId;
private bool excludesSchemaMetadata;
}
【００３６】
リンクオブジェクトは一般にソースアイテム識別子およびターゲットアイテム識別子のような情報を有するが、その情報は、ターゲットにおいてリンク型のスキーマがなくリンクをデシリアライズできない場合に備えて、LinkHeader内に複製される。
【００３７】
また、ストラクチャー３００は、アイテムエクステンションセクション３７０を含み得る：
【００３８】
［テーブル６］
public class ItemExtensionHeader : UdtSerialization
{
}
【００３９】
ストラクチャー３００は、埋込みアイテムセクション３８０を含み得る：
【００４０】
［テーブル７］
public class EmbeddedItem
{
// 埋込みアイテムのヘッダ
ItemHeader itemHeader;
}
【００４１】
ここで、
【００４２】
［テーブル８］
public class ItemHeader
{
// コアアイテムヘッダ
CoreItem coreItem;
// このアイテムに対するすべての出リンクを含むリンクヘッダのリスト
ArrayList outLinks;
// このアイテムのエクステンションに対するエクステンションヘッダのリスト
ArrayList extensions;
// 埋込みアイテムヘッダのリスト
ArrayList embeddedItems;
// このアイテムの入リンクのＩＤのリスト
ArrayList inLinkIds;
// バッキングファイルに関する情報
private BackingFileHeader backingFileHeader;
// シリアライゼーションがスキーマメタデータを除外するか否か
bool excludesSchemaMetadata;
// シリアライゼーション内のセキュリティディスクリプタのオフセット
long sdOffset;
// シリアライゼーション内のセキュリティディスクリプタの長さ
long sdLength;
}
【００４３】
次に、ストラクチャー３００は、バッキングファイルセクション３９０を含み得る：
【００４４】
［テーブル９］
public class BackingFileHeader
{
// バッキングファイルがインライン化されている場合、そのバッキングファイルのオフセット
private long backingFileOffset;
// バッキングファイルの長さ
private long backingFileLength;
// ファイルバックトアイテムの属性を保存する
private System.IO.FileAttributes fatFileAttributes;
// バッキングファイルの作成時
private DateTime fileCreationTime;
// バッキングファイルの最終書き込み時
private DateTime fileLastWriteTime;
// バッキングファイルの最終アクセス時
private DateTime fileLastAccessTime;
}
【００４５】
最後に、ストラクチャー３００はヘッダセクション３９４を含み得る。ヘッダセクション３９４は、コアアイテムおよび関連エンティティに関連する情報を含み得る。ヘッダセクション３９４は、コアアイテムおよび関連エンティティへのランダムアクセスを容易にする（例えば、読み手が関心のある部分のみを解釈／解析することを可能にする）。
【００４６】
次に、図４に、本発明の一態様によるシリアライゼーションシステム４００を例示する。シリアライゼーションシステム４００は、上記の通り、識別コンポーネント１１０およびシリアライゼーションコンポーネント１３０を含む。また、システム４００は、アプリケーションプログラムインタフェース（ＡＰＩ）４１０も含む。ＡＰＩ４１０は、システム４００とアプリケーション４２０の間の通信を容易にする。例えば、ＡＰＩ４１０は、アイテムおよびその関連エンティティをある場所から別の場所（例えば異なるコンピュータシステムおよび／またはリムーバブル媒体）へコピー、移動および／または転送することを容易にする。したがって、ＡＰＩ４１０は、エクスポート、バックアップ、リストア、コピー等のアイテムレベルの操作に使用可能である。一具体例として、アプリケーション４２０は、ＡＰＩ４１０にシリアライゼーション情報（例えばフラグ）を提供することによって、アイテムの全部または一部を選択的に含むことができる。ＡＰＩ４１０は、ファイルシステムレベルで、および／またはストアドプロシジャレベルで公開できる。例示的なＡＰＩ４１０について以下で説明する。
【００４７】
シリアライズアイテムＡＰＩ
シリアライズアイテム（serialize item）ＡＰＩは、以下のコンポーネントが存在する場合に、それを含むアイテムシリアライゼーションを生成する：
・コアアイテム
・出リンク（シリアライズされるアイテムがソースアイテムであるリンク）、および入リンク（シリアライズされるアイテムがターゲットアイテムであるリンク）のリンク識別子
・複合アイテム内のアイテム
・エクステンション
・アイテムフラグメント
・エンティティに対するローカル作成時および変更時
【００４８】
例えば、シリアライズアイテムＡＰＩへのコールは次の形式とすることができる：
[System.Storage.Serialization].SerializeItem (
@itemid uniqueidentifier,
@dataoptions int)
returns varbinary (max)
ここで、itemidは、シリアライズされるべきアイテムの識別子であり、dataoptionsは、シリアライゼーションの内容をカスタマイズするために用いられるSerialize Data Optionsオプション（後述）を指し、ＡＰＩはアイテムのシリアライゼーションをバイト配列として返す。
【００４９】
アイテムをファイルにシリアライズする（Serialize Item To File）
アイテムが非常に大きい場合、アイテムをメモリ内でシリアライズしてシリアライゼーションをクライアントアプリケーションに返すと非効率なことがある。このような場合、アプリケーションによって指定されたファイルに直接シリアライゼーションを書き込むＳｅｒｉａｌｉｚｅＩｔｅｍＴｏＦｉｌｅ  ＡＰＩを用いることができる。これにより、クライアントアプリケーションおよびサーバ側の両方で、シリアライゼーションによって消費されるメモリを限定できる。また、このＡＰＩによれば、サーバからクライアントアプリケーションへ送ることが必要なバイト数がはるかに少なくなるので、パフォーマンスを向上させることができる。例えば、ＳｅｒｉａｌｉｚｅＩｔｅｍＴｏＦｉｌｅへのコールは次の形式とすることができる：
[System.Storage.Serialization].SerializeItemToFile (
@itemid uniqueidentifier,
@dataoptions int,
@filename nvarchar (1024)
)
returns bigint
ここで、itemidは、シリアライズされるべきアイテムの識別子であり、dataoptionsは、シリアライゼーションの内容をカスタマイズするために用いられるSerialize Data Optionsオプション（後述）を指し、filenameはオブジェクトをシリアライズする先のファイルの名前であり、ＡＰＩはファイルに書き込むバイト数を返す。
【００５０】
シリアライゼーションデータオプション（Serialization Data Options）
オプションの値は、シリアライズ機能がさまざまな場合のカスタマの要求を満たすことを可能にする。これらのオプションは、アイテムに関係する、シリアライゼーションの一部として含まれるべきデータ／メタデータ要素を選択するために使用可能である。これらのオプションはシリアライゼーションの内容に影響し得る。
【００５１】
本具体例では、ｏｐｔｉｏｎｓ(オプション)の値は、次のもののＯＲ結合として指定できる：
・０個または１個の共通使用例
・個別オプションからの０個、１個またはそれ以上のオプション
【００５２】
個別オプション
以下のオプションは、個別の場合に対するアイテム境界を定義する。例：
・INCLUDE_EXTENSIONS  ０ｘ２
エクステンションをこのシリアライゼーションに含めるべきかどうかを指定する。
・INCLUDE_OUTGOING_LINKS  ０ｘ４
出リンクをこのシリアライゼーションに含めるべきかどうかを指定する。
・INCLUDE_EMBEDDED  ０ｘ８
複合アイテム内のすべてのアイテムをこのシリアライゼーションに含めるべきかどうかを指定する。
・INCLUDE_SECURITY_DESCRIPTOR  ０ｘ１０
アイテムに対する明示的なアクセス制御リスト（ＡＣＬ）を含めるべきかどうかを指定する。
・INCLUDE_SYNC_METADATA  ０ｘ８０
無権限リストアに必要な同期メタデータを含める。
・INCLUDE_SCHEMA_METADATA  ０ｘ１００
このアイテムをデシリアライズするために必要なスキーマメタデータをこのシリアライゼーションに含めるべきかどうかを指定する。多数のアイテムをシリアライズする場合、アプリケーションは、個別のアイテムシリアライゼーションとは別個にそれをバックアップすることを選択できる。
・INLINE_BACKING_FILE  ０ｘ２００
バッキングファイルをシリアライゼーション内にインライン化するか、それともファイルのＵＮＣパスのみをシリアライゼーションの一部とするかを指定する。これは、バッキングファイルの属性（不可視、読み取り専用等）およびタイムスタンプも含む。
【００５３】
これらの例示的なオプションを用いた有効（妥当）なシリアライズデータオプションの例を以下に挙げる：
SERIALIZE_FOR_COPY | INCLUDE_IDs
このオプションは、コピー用にカスタマイズされるとともに、ＩＤも含む、アイテムのシリアライゼーションを生成する。
SERIALIZE_FOR_BACKUP | INCLUDE_IDs
これは有効なオプションであるが、SERIALIZE_FOR_BACKUP.INCLUDE_IDsというオプションを指定することにより自動的にオンになるので、別個にそれを指定するのは冗長である。
INCLUDE_IDs | INCLUDE_OUTGOING_LINKS
これは、シリアライゼーション内にコアアイテムとそのアイテムを保持するエクステンションとのシリアライゼーションを生成する。本具体例では、共通使用例を指定しなくても有効である。
【００５４】
これらの例示的なオプションを用いた無効なシリアライズデータオプションの例を以下に挙げる：
SERIALIZE_FOR_COPY | SERIALIZE_FOR_BACKUP
本具体例において、複数のデフォルトを指定すると無効である。
SERIALIZE_FOR_COPY & !INCLUDE_EXTENSIONS
【００５５】
本具体例において、「ＡＮＤ」結合は許されない。上記を実現するためには、オプションは、次のように、明示または個別オプションの組合せを用いて指定しなければならない：
INCLUDE_OUTGOING_LINKS | INCLUDE_EMBEDDED |
INLINE_FILESTREAM_ATTRIBUTES |
INCLUDE_SCHEMA_METADATA
【００５６】
共通使用例
以下のオプションは、共通使用例の場合のアイテム境界を定義する。例：
・SERIALIZE_FOR_COPY  ０ｘ１０００００００
このオプションを選択すると以下のオプションがオンになる。
○  INCLUDE_EXTENSIONS
○  INCLUDE_OUTGOING_LINKS
○  INCLUDE_EMBEDDED
○  INCLUDE_SECURITY_DESCRIPTOR
○  INLINE_FILESTREAM_ATTRIBUTES
○  INCLUDE_SCHEMA_METADATA
・SERIALIZE_FOR_BACKUP  ０ｘ２０００００００
このオプションを選択すると以下のオプションがオンになる。
○  INCLUDE_EXTENSIONS
○  INCLUDE_OUTGOING_LINKS
○  INCLUDE_EMBEDDED
○  INLINE_FILESTREAM_ATTRIBUTES
○  INCLUDE_SECURITY_DESCRIPTOR
○  INCLUDE_SCHEMA_METADATA
○  INCLUDE_IDs
○  INCLUDE_SYNC_METADATA
【００５７】
次に、図５に、本発明の一態様によるシリアライゼーション環境５００を例示する。アプリケーション４２０が、シリアライズすべきアイテムに関連する情報、例えばアイテムＩＤを、シリアライゼーションシステム４００に提供する。その後、シリアライゼーションシステム４００は、ファイル記憶システムメタデータ５１０から、アイテムＩＤに関する型情報を取得する。シリアライゼーションコンポーネント４００は、アイテムＩＤおよび型情報を用いて、前述のように、シリアライズすべきアイテム（例えばアイテムおよび関連エンティティ）に関連する情報を、ファイルシステムビュー５３０に対して（例えば再帰的に）問い合わせる。
【００５８】
一具体例では、シリアライゼーションコンポーネント１３０は、アイテムフラグメントに対するランダムアクセスをサポートしない。この具体例では、アイテムフラグメントは、ヘッダからの開始オフセットおよび各フラグメントに先行する長さフィールドを用いてシーケンシャルに（例えば連結リストのように）アクセスすることができる。
【００５９】
複合アイテム内のアイテム
INCLUDE_EMBEDDEDオプションが選択されると、システム４００は、複合アイテム内のアイテムを再帰的にたどってそれらをシリアライズする。例えば、システム４００は、再帰的ストラクチャーをたどって複数の問合せを実行し、各アイテムをシリアライズすることができる。結果として得られるシリアライゼーションは、埋込みアイテムシリアライゼーションがそれらの親のシリアライゼーションに含まれるような再帰的構造を有する。
【００６０】
一具体例として、複合アイテム内の各アイテムが相異なるセキュリティディスクリプタを有し得る。このため、シリアライズＡＰＩの呼出側は、複合アイテム内のすべてのアイテムにアクセスできない可能性がある。この具体例では、ユーザがすべてのアイテムにアクセスできない場合、呼出側がアクセスできないアイテムはシリアライズされない。
【００６１】
バッキングファイル
本具体例において、バッキングファイルは、シリアライゼーション内にインライン化されても、呼出側によって（例えばシリアライズオプションに基づいて）別個にコピーされても、いずれでもよい。
【００６２】
インラインのバッキングファイル
アプリケーションが、ファイルバックアイテムをシリアライゼーション内に含めるよう要求した場合、バッキングファイルは、ファイル記憶システム１２０から読み出されることができる。ファイルに加えて、属性や、作成、最終アクセスおよび／または変更時刻もシリアライゼーションヘッダに含めることができる。例えば、この情報は、アイテムがバックアップのためにシリアライズされている場合に使用可能である（例えば、デシリアライゼーション後にタイムスタンプを元の値に戻すために必要とされる場合）。
【００６３】
インラインでないバッキングファイル
この場合、アプリケーションは、例えばシリアライズＡＰＩをコールする際にINLINE_BACKING_FILEオプションをセットしないことによって、ファイルバックアイテムをシリアライゼーション内に含めないよう要求している。本具体例では、シリアライズＡＰＩは、シリアライゼーション内にファイルの内容を含める代わりに、ヘッダにファイル名を埋め込むことができる。それに応じて、アプリケーションは、このファイル名を読み出し、ファイル記憶システムＡＰＩを直接使用してバッキングファイルの内容を処理できる。しかし、この場合でも、ファイル属性や作成、最終アクセスおよび変更のタイムスタンプをシリアライゼーションヘッダに取り込める。例えば、この情報は、アイテムがバックアップのためにシリアライズされている場合に使用可能である（例えば、デシリアライゼーション後にタイムスタンプを元の値に戻すために必要とされる場合）。
【００６４】
スキーマメタデータ
本具体例では、スキーマメタデータは、ファイルシステムストア１２０に固有であり得るタイプＩＤを含むので、各エンティティのシリアライゼーションとともに取り込まれる。タイプＩＤからアセンブリ名およびバージョンへのマッピングは、ユーザ定義型シリアライゼーションをデシリアライズするために必要なスキーマメタデータである。例えば、各エンティティ（例えばアイテム、リンク、エクステンションおよび／またはフラグメント）に関連するスキーマメタデータがあり得る。これは、それぞれのエンティティシリアライゼーションとともに含められることが可能である。
【００６５】
この情報を取得するため、シリアライゼーションシステム４００は、システムメタデータ５２０に問合せをすることにより完全限定型名を取得できる。例えば、ＧｅｔＮａｍｅＦｒｏｍＴｙｐｅＩｄは、与えられたＴｙｐｅＩｄ（タイプＩＤ）に対して、ＳｃｈｅｍａＮａｍｅおよびＴｙｐｅＮａｍｅをそれぞれ含む２列からなるちょうど１行のテーブルとして、完全限定型名を返す。ファイルシステムストア１２０のそれぞれのアイテム／リンク／エクステンション／フラグメントのテーブルからのＴｙｐｅＩｄを関数への入力として用いることにより、スキーマ名および型名を取得できる。さらに、これをｓｙｓ．ａｓｓｅｍｂｌｉｅｓテーブルと結合（join）することで完全限定型名が得られる。一般に、ＴｙｐｅＩｄはファイルシステムストア１２０（例えばデータベース）全体で一意ではないが、完全限定型名は一意である。ストア内コピー（例えば、タイプＩＤがソースとターゲットで同じである場合）、スキーマメタデータを除くことができる。
【００６６】
セキュリティ
前述のように、各アイテムには、そのアイテムにアクセスできるユーザおよび／またはそれにアクセスできないユーザを識別するセキュリティディスクリプタ（セキュリティー記述子）を関連づけることができる。図５に関して説明した例を続けると、例示的な信頼境界５４０が識別される。本具体例では、環境５００は、ファイルシステムの権限付与に基づいて、ユーザがファイルシステムストア１２０に接続するパーミッション（同意）を有するようにすることができる。特定のシリアライズＡＰＩまたはデシリアライズＡＰＩの呼出側は一般に、そのＡＰＩをコールする前にファイルシステムストア１２０との接続を確立している。
【００６７】
次に、図６に、本発明の一態様によるデシリアライゼーションシステム６００を例示する。システム６００は、例えばシステム１００および／またはシステム４００によって生成された、アイテムおよびその関連エンティティをデシリアライズするために使用可能である。システム６００は、ヘッダを用いることにより、アイテムおよび関連エンティティにランダムアクセスすることができる（例えば、関心のある部分のみを解釈／解析できる）。
【００６８】
システム６００は、アイテムおよびその関連エンティティのデシリアライゼーションを容易にするアプリケーションプログラムインタフェース（ＡＰＩ）６１０を公開することができる。ＡＰＩ６１０は、例えばアプリケーション６３０から受け取った、シリアライズされたアイテムを、デシリアライゼーションコンポーネント６２０に提供できる。デシリアライゼーションコンポーネント６２０は、アイテムストラクチャーを再作成し、それをファイルシステムストア６４０に保存することができる。
【００６９】
アプリケーション６３０からアイテムをデシリアライズすることを求める要求を受け取った後、ＡＰＩ６１０は、シリアライズされたアイテムをデシリアライゼーションコンポーネント６２０に提供し、デシリアライゼーションコンポーネント６２０は上記のようなヘッダオフセットを用いてヘッダを（例えばメモリ内に）読み出し、デシリアライズプロセスを通じてそのヘッダを使用することができる。その場合、一具体例として、デシリアライゼーションコンポーネント６２０は以下のことを実行できる：
１．コアアイテムをデシリアライズする。
２．アイテムフラグメントをデシリアライズする。
３．出リンクをデシリアライズする。
４．エクステンションをデシリアライズする。
５．例えば再帰的にツリーをトップダウンでたどることにより、複合アイテムコンテナに埋め込まれたアイテムをデシリアライズする。
６．バッキングファイルをデシリアライズする。
【００７０】
デシリアライズされたアイテムおよび関連エンティティはファイルシステムストア６４０に保存される。
【００７１】
リンク修復
一具体例において、デシリアライゼーション中に、システム６００は、シリアライゼーション内に存在したアイテムのすべてのリレーションシップ（関係）が、アイテムがデシリアライズされた後も存続するようにする。さらに、入リンク情報がシリアライズされているので、シリアライゼーションは、デシリアライズされたアイテムへの入リンクの修復も行う。これは、シリアライズされたものが、デシリアライズされた後に、（例えば厳密に）同一であることを保証するためである。
【００７２】
例えば、修復作業の適用範囲（スコープ）は、与えられたコピー操作におけるすべてのアイテムであってもよい。後述するように、シリアライゼーションＡＰＩのユーザは、BeginDeserializationBatchおよびEndDeserializationBatchという２つのヘルパーＡＰＩを呼び出すことによって、バッチスコープを作成できる。このスコープ内でデシリアライズされるいずれのアイテムも、このスコープ内の他のアイテムへのリンクが修復されることになる。例えば、一時テーブルを用いることにより、デシリアライズされるアイテムのリレーションシップについてＩＤを追跡することができる。その場合、この一時テーブルが旧ＩＤを新ＩＤにマッピングして、シリアライゼーションがリンクのターゲットＩＤとソースＩＤを修復する。本具体例では、（バッチ内の）リンクおよび包含リレーションシップを修復することができる。
【００７３】
これは、例えば、ＤｅｓｅｒｉａｌｉｚｅＩｔｅｍに対する追加フラグとして実装できる。ただし、一具体例では、シリアライゼーションＡＰＩのコンシューマは、バッチの開始および終了を明示的に記述する必要がある。
【００７４】
ＡＰＩ
ＡＰＩ６１０は、システム６００とアプリケーション６３０の間の通信を容易にする。例えば、ＡＰＩ６１０は、シリアライズされたアイテムのデシリアライゼーションを容易にする。ＡＰＩ６１０は、ファイルシステムレベルで、および／またはストアドプロシジャレベルで公開できる。例示的なＡＰＩ６１０について以下で説明する。
【００７５】
デシリアライズアイテムＡＰＩ
デシリアライズアイテム（ＤｅｓｅｒｉａｌｉｚｅＩｔｅｍ）ＡＰＩは、アイテムをデシリアライズし、それを、コンテナＩＤとして指定されるＩＤを有するコンテナに入れる。名前空間名およびコンテナＩＤが両方ともヌルとして渡される場合、それらの値はシリアライゼーションから取られる。ストアドプロシジャは、アイテムがシリアライズされた時に入っていたのと同じコンテナ内のアイテムをデシリアライズする。例えば、これは、アイテムＩＤを保持したままソースから宛先へのツリー全体（例えばフォルダおよびサブフォルダ）をコピーするような場合に必要となり得る。本具体例では、シリアライゼーションがアイテムＩＤを含まない（含むとエラーになる）場合には、コンテナＩＤをヌルとして渡すことはできない。例：
[System.Storage.Serialization].DeserializeItem (
@serialization varbinary (max),
@containerId uniqueidentifier,
@namespacename nvarchar(255),
@options int,
@itemid uniqueidentifier output)
@fileinfolist FileInfoList output
ここで、serializationは、（例えば以前のシリアライゼーションの結果として生成された）シリアライズされたアイテムを指し、containerIdは、新規アイテムを含むことになるコンテナのアイテムＩＤを指し、namespacenameは、デシリアライズされるアイテムの名前空間名を指し、optionsは、デシリアライズプロセスの挙動を支配するオプション（後述）を指し、itemidは、新規アイテムのアイテムＩＤを指し、fileinfolistは、このアイテムに含まれるファイルのファイル名、アイテムＩＤおよびサイズのリストである。例：
Class FilelnfoList: ArrayList;
// これは次のインスタンスを含む：
Class FileInfo {
SqlGuid itemId;
SqlString relativePath;
SqlBigint size;
}
【００７６】
既存アイテムを上書きしてデシリアライズする
このＡＰＩ６１０は、与えられたシリアライゼーションの内容を用いてデシリアライズを行い、ストア内の既存アイテムを上書きする。本具体例では、ファイルバックトアイテムを上書きする時、バッキングファイルは切り捨てられる。シリアライゼーションがファイルをインラインで有していない場合、この操作により、長さゼロのバッキングファイルが生じる。
【００７７】
さらに、本具体例において、このＡＰＩ６１０は、同一アイテムを過去のある状態にリストアする際にのみ使用可能である。例：
[System.Storage.Serialization].DeserializeItemReplace (
@serialization varbinary (max),
@targetitemid uniqueidentifier,
@options int)
ここで、serializationは、（例えば以前のシリアライゼーションの結果として生成された）シリアライズされたアイテムを指し、targetitemidは、置換されるアイテムのアイテムＩＤを指し、optionsは、デシリアライズプロセスの挙動を支配するオプション（後述）を指す。
【００７８】
アイテムをファイルからデシリアライズする（De-serialize Item From File）
このＡＰＩ６１０は、大きいアイテムを（例えばシステム１００および／またはシステム４００によって生成された）ファイルからデシリアライズすることができるように提供される。例えば、ファイルは、上記のＳｅｒｉａｌｉｚｅＩｔｅｍＴｏＦｉｌｅ  ＡＰＩによって生成されたものでも、上記のＳｅｒｉａｌｉｚｅＩｔｅｍ  ＡＰＩを呼び出してからアイテムシリアライゼーションをファイルに書き込むことによって生成されたものでもよい。本具体例では、名前空間名およびコンテナＩＤが両方ともヌルとして渡される場合、それらの値はシリアライゼーションから取られる。例：
[System.Storage.Serialization].DeserializeItemFromFile (
@filename nvarchar (1024),
@containerId uniqueidentifier,
@namespacename nvarchar(255),
@options int,
@itemid uniqueidentifier output,
@fileinfolist FileInfoList output
ここで、filenameは、デシリアライズすべきアイテムのシリアライゼーションを有するファイルの名前を指し、containerIdは、新規アイテムを含むことになるコンテナのアイテムＩＤを指し、namespacenameは、デシリアライズされるアイテムの名前空間名を指し、optionsは、デシリアライズプロセスの挙動を支配するオプション（後述）を指し、itemidは、新規アイテムのアイテムＩＤを指し、fileinfolistは、このアイテムに含まれるファイルのファイル名、アイテムＩＤおよびサイズのリストである。例：
Class FilelnfoList: ArrayList;
// これは次のインスタンスを含む：
Class Filelnfo {
SqlGuid itemid;
SqlString relativePath;
SqlBigint size;
}
【００７９】
既存アイテムを上書きしてファイルからデシリアライズする
「既存アイテムを上書きしてファイルからデシリアライズする」ＡＰＩ６１０は、指定されたファイル（例えば、上記のＳｅｒｉａｌｉｚｅＩｔｅｍＴｏＦｉｌｅ  ＡＰＩによって作成されたファイル、および／またはＳｅｒｉａｌｉｚｅＩｔｅｍ  ＡＰＩを呼び出してからアイテムシリアライゼーションをファイルに書き込んで作成されたファイル）に含まれる与えられたアイテムシリアライゼーションの内容を用いて、ファイルシステムストア６４０内の既存アイテムを上書きする。本具体例では、ファイルバックトアイテムを上書きする時、バッキングファイルは切り捨てられる。シリアライゼーションがファイルをインラインで有していない場合、この操作により、長さゼロのバッキングファイルが生じる。
【００８０】
本具体例において、ＤｅｓｅｒｉａｌｉｚｅＩｔｅｍＲｅｐｌａｃｅＦｒｏｍＦｉｌｅは、同一アイテムを過去のある状態にリストアする際にのみ使用可能である。例：
[System.Storage.Serialization].DeserializeItemReplaceFromFile (
@filename nvarchar (1024),
@fileoffset bigint,
@targetitemid uniqueidentifier,
@options int,
@bytesread bigint output
ここで、filenameは、デシリアライズすべきアイテムのシリアライゼーションを有するファイルの名前であり、targetitemidは、置換されるアイテムのアイテムＩＤであり、optionsは、デシリアライズプロセスの挙動を支配するオプション（後述）を指し、bytesreadは、（例えば次のオフセットへのジャンプを容易にするため）読み出されたバイト数を返す。
【００８１】
BeginDeserializationBatchおよびEndDeserializationBatch
これらのヘルパー関数（helper functions）は、互いに一緒に、そしてＬｉｎｋ＿Ｆｉｘ＿Ｕｐ（リンク修復）デシリアライゼーションオプション（後述）とともに、使用可能である。BeginDeserializationBatchをコールすることで、デシリアライゼーションバッチスコープが開始される。本具体例では、このスコープ内でシリアライズされるすべてのアイテムが機能し続けるように、すべてのリンクが補正される。すべてのアイテムがデシリアライズされた後、EndDeserializationBatchをコールすることにより、スコープを終了し、この操作によって使用された一時テーブルをクリーンアップする。
【００８２】
例えば、ＩｔｅｍＡがＩｔｅｍＢにリンクされ、ＩｔｅｍＢがＩｔｅｍＣにリンクされているとする。さらに、これらのアイテムが新規ストアにデシリアライズされているとする。本具体例において、クライアントアプリケーションは以下のコールを行う：
BeginDeserializationBatch() （すべてのリンクを追跡するための一時テーブルを作成）
リンク修復フラグを指定してすべてのアイテムをデシリアライズする
EndDeserializationBatch()
【００８３】
アイテムは、この新規ストアに再作成され新規のアイテムＩＤを有しているとしても、修復フラグのため、互いに正しくリンクされることが可能である。
【００８４】
デシリアライズオプション
デシリアライゼーションオプションの例を以下に挙げる：
・RETAIN_ITEM_ID  ０ｘ１
シリアライズされるアイテムと同じアイテムＩＤを保持する。これは、アイテムＩＤがヌルにされない場合にのみ適用可能である。
・RESTORE_SECURITY_DESCRIPTOR  ０ｘ２
シリアライズされるアイテムと同じ明示的アクセス制御リスト（ＡＣＬ）を保持する。
・RESTORE_TIME_STAMP  ０ｘ４
ローカル作成時刻および変更時刻をリストアする（例えばコピーおよび／またはリストアに適用可能）。
・RESTORE_SYNC_METADATA  ０ｘ８
アイテムに対する＿ＣｈａｎｇｅＩｎｆｏｒｍａｔｉｏｎ、ＳｙｎｃＭｅｔａｄａｔａをリストアする。Ｒｅｐｌｉｃａ／Ｍａｐｐｉｎｇ／Ｃｏｎｆｌｉｃｔアイテムの場合には、このオプションが指定されている場合に限りリストアされる。
・LINK_FIX_UP  ０ｘ１０
Ｌｉｎｋ＿Ｆｉｘ＿Ｕｐオプションは、BeginSerializationBatchおよびEndSerializationBatchという２つのヘルパーＡＰＩとともに使用すれば、すべてのアイテムリンクが保持されるようにすることができる。一具体例として、Ｌｉｎｋ＿Ｆｉｘ＿Ｕｐがバッチスコープの外側で用いられる場合、そのコールは失敗する。
【００８５】
デシリアライゼーションにおけるユーザ定義型の使用
デシリアライゼーションコンポーネント６２０によるユーザ定義型（ＵＤＴ）の再構成により、以下のことが実行できる：（１）シリアライゼーションが有効（妥当）なシリアライゼーションであるかどうかを確認すること、および、（２）アイテムをデシリアライズするために必要な型がシステムに存在するかどうかを確認すること、および／または、（３）妥当性制約をトリガすること。本具体例において、シリアライゼーションからＵＤＴを再構成することは、コアアイテムのデシリアライゼーションの前に実行される。
【００８６】
次に、図７に、本発明の一態様によるデシリアライゼーション環境７００を例示する。環境７００は、基本更新ＡＰＩ７２０を通じてファイルシステムストア６４０とやりとりするデシリアライゼーションシステム６００を含む。また、例示的な信頼境界７３０が識別される。前述のように、特定のデシリアライズＡＰＩの呼出側は一般に、そのＡＰＩをコールする前にファイルシステムストア６４０との接続を確立している。
【００８７】
例えば、アプリケーション６３０は、デシリアライゼーションシステム６００にアイテムシリアライゼーションを提供できる。デシリアライゼーションシステム６００は、前述のように、システムメタデータ７１０からユーザ定義型に関する情報を取得できる。デシリアライゼーションシステム６００は、基本更新ＡＰＩ７２０を通じて、デシリアライズされたコアアイテムおよび関連エンティティを保存しようと試みることができる。基本更新ＡＰＩ７２０として、例えば以下のものが挙げられる：
【００８８】
ＣｒｅａｔｅＩｔｅｍ
デシリアライゼーションシステム６００は、この基本更新ＡＰＩ７２０を用いることにより、デシリアライズされたアイテムをファイルシステムストア６４０内に作成できる。例えば、この基本更新ＡＰＩ７２０は、上書きせずにアイテムを作成する際に使用可能である。
【００８９】
ＳｅｔＩｔｅｍＳｅｃｕｒｉｔｙ
この基本更新ＡＰＩ７２０を使用すると、デシリアライズされたアイテムのセキュリティディスクリプタを設定できる。例えば、セキュリティディスクリプタを設定する際に、以下のポリシが使用可能である：
・デシリアライゼーションシステム６００がリストアセマンティクスを指定しない場合、ＳｅｔＩｔｅｍＳｅｃｕｒｉｔｙを用いてアクセス制御リストのみを設定する。
・リストアセマンティクスが指定されている場合、ＳｅｔＩｔｅｍＳｅｃｕｒｉｔｙを用いてアクセス制御リストとグループおよびオーナとを両方とも設定できる。
【００９０】
ＲｅｐｌａｃｅＩｔｅｍ
デシリアライゼーションシステム６００は、この基本更新ＡＰＩ７２０をコールすることにより、ファイルシステムストア６４０内で既存アイテムをデシリアライズされたアイテムで上書きできる。例えば、この基本更新ＡＰＩ７２０は、上書きでアイテムを作成する際に使用可能である。
【００９１】
ＭｏｖｅＩｔｅｍ
この基本更新ＡＰＩ７２０を用いると、アイテムがシリアライズされた時と同じコンテナおよび同じ名前空間名を有するように、置換すべきアイテムを移動することができる。
【００９２】
ＣｒｅａｔｅＬｉｎｋ
デシリアライゼーションシステム６００は、この基本更新ＡＰＩ７２０を用いることにより、ファイルシステムストア６４０内のアイテムの出リンクをデシリアライズできる。
【００９３】
ＣｒｅａｔｅＥｘｔｅｎｓｉｏｎ
この基本更新ＡＰＩ７２０を用いると、ファイルシステムストア６４０内のアイテムのエクステンションをデシリアライズできる。
【００９４】
ＣｒｅａｔｅＩｔｅｍＦｒａｇｍｅｎｔ
デシリアライゼーションシステム６００は、この基本更新ＡＰＩ７２０を用いることにより、ファイルシステムストア６４０内のアイテムのフラグメントをデシリアライズできる。
【００９５】
ＵｐｄａｔｅＬｉｎｋ
この基本更新ＡＰＩ７２０は、デシリアライゼーションシステム６００によって使用されることにより、後述するように、作成されたアイテムに対する入リンクであるリンクのターゲットアイテムＩＤを更新できる。
【００９６】
移動したアイテムの置換
デシリアライズ中にアイテムをその過去のコピーで置換することが、リストア中によく起こり得る。重要なことであるが、リストアされたアイテムは、シリアライズ（例えばバックアップ）された時とデシリアライズ（例えばリストア）された時との間で移動している可能性がある。移動は、次のいずれかを意味する一般的操作である：
ａ）親コンテナを変更する、
ｂ）名前空間名を変更する、および／または
ｃ）名前空間名および親コンテナの両方を変更する。
【００９７】
本具体例において、アイテムがリストアされる時、置換操作は名前空間名あるいはコンテナＩＤを変更できない。したがって、アイテムをその元の位置にリストアするためには、ＭｏｖｅＩｔｅｍを用いて、同じコンテナおよび同じ名前空間名（もしそれらのいずれかが変更されていれば）にしてから置換を実行する。
【００９８】
複合アイテムの置換
本具体例において、ＤｅｓｅｒｉａｌｉｚｅＩｔｅｍＲｅｐｌａｃｅが複合アイテムに対してコールされる（例えば、複合アイテムをその過去のコピーで置換する）と、以下のことが起こる：
１）ルートアイテムが元の位置に移動され、その名前空間名が元の値にリストアされ、シリアライゼーション内のアイテムで置換される。
２）シリアライズ（例えばバックアップ）された後に複合アイテムツリーに追加されたアイテムが削除される。
３）シリアライズされた後に複合アイテムから削除されたアイテムが、ＣｒｅａｔｅＩｔｅｍを用いてデシリアライズプロセスの一部として作成される。
４）最後のシリアライズ以降に削除されなかったアイテムが、ＲｅｐｌａｃｅＩｔｅｍを用いて置換される。
【００９９】
デシリアライズされているアイテムに対する入リンクの処理
一具体例において、リストア操作中に（例えば、アイテムＩＤが環境７００に保持されている時）、以下を使用することにより、アイテムへの入リンクに対するターゲットアイテムＩＤを修復できる。
各入リンクＩＤについて：
ａ．そのリンクＩＤを有するリンクがストア内に存在するかどうかをチェックする。存在する場合は次のステップに進み、存在しない場合は次のステップをスキップする。
ｂ．ＵｐｄａｔｅＬｉｎｋ  ＡＰＩ７２０を用いることにより、それらのリンクのターゲットアイテムＩＤを、デシリアライズされたアイテムのＩＤに更新する。
ｃ．すべての入リンクＩＤについて上記２つのステップを繰り返す。
【０１００】
ファイルバックトアイテムのデシリアライズ
シリアライゼーション内にインライン化されたファイル
ファイルがシリアライゼーション内にインライン化されている場合、一具体例では、ヘッダが次の情報を伝えることができる：ファイルバックトアイテムのアイテムＩＤ（これから、ファイルの書き込み先のパスを導き出すことができる）およびバッキングファイルを含むシリアライゼーションの部分。これを用いることにより、基本更新ＡＰＩ７２０を用いて指定位置にファイル（複数可）を書き込むことができる。
【０１０１】
シリアライゼーション内にインライン化されていないファイル
本具体例では、ファイルがシリアライゼーション内にインライン化されていない場合、基本更新ＡＰＩ７２０を用いてバッキングファイルをターゲット位置にコピーするのは呼出側の責任である。
【０１０２】
認識されるように、システム１００、ファイルシステムストア１２０、システム４００、ＡＰＩ４１０、アプリケーション４２０、システム５００、ファイル記憶システムメタデータ５１０、システムメタデータ５２０、ファイルシステムビュー５３０、環境６００、ＡＰＩ６１０、デシリアライゼーションコンポーネント６２０、アプリケーション６３０、ファイルシステムストア６４０、環境７００、システムメタデータ７１０および／または基本更新ＡＰＩ７２０は、当該用語が本明細書で定義されているようなコンピュータコンポーネントとすることができる。
【０１０３】
簡単に図８〜図１１を参照する。図８〜図１１は、本発明により実施可能な方法を例示している。説明を簡単にする目的上、本方法は一連のブロックとして図示され説明されるが、理解され認識されるように、本発明はそれらのブロックの順序に限定されない。本発明によれば、一部のブロックは、図示され本明細書に記載されるものとは異なる順序で、および／または他のブロックと並行して生起し得る。さらに、本発明による方法を実施するために、例示されたすべてのブロックが必須とは限らない。
【０１０４】
本発明は、１つまたは複数のコンポーネントによって実行されるプログラムモジュール等のコンピュータ実行可能命令との一般的関連で説明できる。一般的に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、データストラクチャー等を含む。一般に、プログラムモジュールの機能は、種々の実施形態において必要に応じて組み合わされ、あるいは分散され得る。
【０１０５】
図８および図９に、本発明の一態様によるアイテムのシリアライゼーションを容易にする方法８００を例示する。８０４で、アイテムをシリアライズすることを求める要求を（例えばアプリケーションから）受け取る。８０８で、ヘッダのためにメモリを割り当てる。８１２で、コアアイテムをシリアライズする。
【０１０６】
８１６で、アイテムフラグメントがあれば、それをシリアライズする。次に、８２０で、出リンクがあれば、それをシリアライズする。８２４で、入リンク識別子があれば、それをヘッダに入れる。８２８で、エクステンションがあれば、それをシリアライズする。８３２で、埋込みアイテムがあれば、それをシリアライズする。８３６で、バッキングファイルがあれば、それをシリアライズする。８４０で、シリアライゼーション長、ヘッダオフセットおよびヘッダをシリアライゼーションに書き込む。８４４で、シリアライゼーションに関する情報を要求側（例えば要求側アプリケーション）に提供する。例えば、シリアライゼーション自体を要求側アプリケーションに提供できる。別法として、シリアライゼーションへのポインタおよび／またはシリアライゼーションのファイル名を要求側アプリケーションに提供できる。
【０１０７】
次に、図１０および図１１に、本発明の一態様によるアイテムのデシリアライゼーションを容易にする方法１０００を例示する。１００４で、アイテムをデシリアライズすることを求める要求を受け取る。１００８で、ヘッダオフセットを用いてヘッダをメモリに読み込む。１０１２で、コアアイテムをデシリアライズする。１０１６で、アイテムフラグメントがあれば、それをデシリアライズする。１０２０で、出リンクがあれば、それをデシリアライズする。
【０１０８】
１０２４で、エクステンションがあれば、それをデシリアライズする。１０３２で、埋込みアイテムがあれば、それをデシリアライズする。１０３６で、バッキングファイルがあれば、それをデシリアライズする。デシリアライズされたアイテムおよび関連エンティティはファイル記憶システムに保存することができる。
【０１０９】
本発明の諸態様についてさらに前後関係を説明するため、図１２および以下の説明は、本発明の諸態様が実施され得る好適なオペレーティング環境１２１０の簡単な概説を行うことを意図している。本発明は、１つまたは複数のコンピュータまたはその他の装置によって実行されるプログラムモジュール等のコンピュータ実行可能命令との一般的関連で説明されるが、当業者には認識されるように、本発明は、他のプログラムモジュールと組み合わせて、および／またはハードウェアとソフトウェアの組合せとしても実施可能である。ただし、一般的に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データストラクチャー等を含む。オペレーティング環境１２１０は好適なオペレーティング環境の単なる一例であり、本発明の用途および機能の範囲に関するいかなる限定を示唆することも意図していない。本発明とともに使用するのに好適となり得る他の周知のコンピュータシステム、環境、および／または構成としては、以下のものに限定されないが、パーソナルコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサ方式のシステム、プログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置を含む分散コンピューティング環境等がある。
【０１１０】
図１２を参照すると、本発明の諸態様を実施する例示的環境１２１０はコンピュータ１２１２を含む。コンピュータ１２１２は、処理ユニット１２１４、システムメモリ１２１６、およびシステムバス１２１８を含む。システムバス１２１８は、システムメモリ１２１６を含む（ただしこれに限定されない）システムコンポーネントを処理ユニット１２１４に結合する。処理ユニット１２１４は種々の入手可能なプロセッサのいずれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャもまた、処理ユニット１２１４として使用可能である。
【０１１１】
システムバス１２１８は、メモリバスまたはメモリコントローラ、ペリフェラルバスまたは外部バス、および／または利用可能なさまざまなバスアーキテクチャのいずれかを用いたローカルバス等の数種のバス構成のいずれでもよい。そのようなバスアーキテクチャとしては、以下のものに限定されないが、８ビットバス、Industry Standard Architecture（ＩＳＡ）、Micro-Channel Architecture（ＭＣＡ）、Enhanced ISA（ＥＩＳＡ）、Intelligent Drive Electronics（ＩＤＥ）、VESA Local Bus（ＶＬＢ）、Peripheral Component Interconnect（ＰＣＩ）、Universal Serial Bus（ＵＳＢ）、Advanced Graphics Port（ＡＧＰ）、Personal Computer Memory Card International Associationバス（ＰＣＭＣＩＡ）、およびSmall Computer Systems Interface（ＳＣＳＩ）がある。
【０１１２】
システムメモリ１２１６は、揮発性メモリ１２２０および不揮発性メモリ１２２２を含む。起動中等にコンピュータ１２１２内の要素間で情報を転送するための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）が不揮発性メモリ１２２２に格納される。実例として、限定ではないが、不揮発性メモリ１２２２としては、読み出し専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、あるいはフラッシュメモリが挙げられる。揮発性メモリ１２２０としては、ランダムアクセスメモリ（ＲＡＭ）があり、これは外部キャッシュメモリとして作用する。実例として、限定ではないが、ＲＡＭは、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、Ｓｙｎｃｈｌｉｎｋ  ＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクトＲａｍｂｕｓ  ＲＡＭ（ＤＲＲＡＭ）のような多くの形態で入手可能である。
【０１１３】
また、コンピュータ１２１２はリムーバブル（取り外し可能）／非リムーバブル（取り外し不能）、揮発性／不揮発性のコンピュータ記憶媒体も含む。図１２は、例としてディスクストレージ１２２４を示している。ディスクストレージ１２２４としては、以下のものに限定されないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、あるいはメモリスティックのようなデバイスがある。さらに、ディスクストレージ１２２４は、以下のものに限定されないが、コンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤレコーダブルドライブ（ＣＤ−Ｒドライブ）、ＣＤリライタブルドライブ（ＣＤ−ＲＷドライブ）あるいはディジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）のような光ディスクドライブを含む記憶媒体を、単独で、または他の記憶媒体と組み合わせて含んでもよい。ディスクストレージデバイス１２２４をシステムバス１２１８に接続することを容易にするため、通常、インタフェース１２２６のような、リムーバブルまたは非リムーバブルインタフェースが用いられる。
【０１１４】
認識されるように、図１２は、ユーザと、好適なオペレーティング環境１２１０に記載された基本的なコンピュータリソースとの間の媒介手段として作用するソフトウェアを示している。このようなソフトウェアとしてオペレーティングシステム１２２８がある。オペレーティングシステム１２２８は、ディスクストレージ１２２４に格納されることが可能であり、コンピュータシステム１２１２のリソースを制御し割り当てるように作用する。システムアプリケーション１２３０は、システムメモリ１２１６またはディスクストレージ１２２４のいずれかに格納されたプログラムモジュール１２３２およびプログラムデータ１２３４を通じて、オペレーティングシステム１２２８によるリソースの管理を利用する。認識されるように、本発明は、種々のオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実施可能である。
【０１１５】
ユーザは、入力デバイス１２３６を通じてコンピュータ１２１２にコマンドまたは情報を入力する。入力デバイス１２３６としては、以下のものに限定されないが、ポインティングデバイス、例えばマウス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、ディジタルカメラ、ディジタルビデオカメラ、ウェブカメラ等がある。これらおよびその他の入力デバイスは、インタフェースポート１２３８経由でシステムバス１２１８を通じて処理ユニット１２１４に接続される。インタフェースポート１２３８としては、例えば、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）がある。出力デバイス１２４０は、入力デバイス１２３６と同種のポートの一部を使用する。したがって、例えば、ＵＳＢポートは、コンピュータ１２１２に入力を提供するとともに、コンピュータ１２１２から出力デバイス１２４０に情報を出力するために使用可能である。出力デバイス１２４０のうちにはとりわけ、特殊なアダプタを必要とするモニタ、スピーカ、およびプリンタのようないくつかの出力デバイス１２４０があることを例示するために、出力アダプタ１２４２が設けられている。出力アダプタ１２４２としては、例示であり限定ではないが、出力デバイス１２４０とシステムバス１２１８の間の接続手段を提供するビデオカードおよびサウンドカードがある。なお、リモートコンピュータ１２４４のように、他のデバイスおよび／またはデバイスのシステムでは、入出力両機能を提供することもある。
【０１１６】
コンピュータ１２１２は、リモートコンピュータ１２４４のような１つまたは複数のリモートコンピュータへの論理コネクションを用いたネットワーク環境で動作し得る。リモートコンピュータ１２４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサ方式の電子機器、ピアデバイスあるいはその他の一般的なネットワークノード等であってよく、一般に、コンピュータ１２１２に関連して説明した要素の多くまたはすべてを含む。簡単のため、メモリ記憶装置１２４６のみをリモートコンピュータ１２４４とともに示してある。リモートコンピュータ１２４４は、ネットワークインタフェース１２４８を通じてコンピュータ１２１２に論理的に接続され、通信コネクション１２５０を通じて物理的に接続される。ネットワークインタフェース１２４８は、ローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）のような通信ネットワークを包含する。ＬＡＮ技術としては、Fiber Distributed Data Interface（ＦＤＤＩ）、Copper Distributed Data Interface（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５等がある。ＷＡＮ技術としては、以下のものに限定されないが、ポイントツーポイントリンク、サービス総合ディジタル網（ＩＳＤＮ）およびその変種のような回線交換ネットワーク、パケット交換ネットワーク、およびディジタル加入者回線（ＤＳＬ）がある。
【０１１７】
通信コネクション１２５０とは、ネットワークインタフェース１２４８をバス１２１８に接続するために用いられるハードウェア／ソフトウェアを意味する。通信コネクション１２５０は説明を明確にするためにコンピュータ１２１２の内部に示されているが、コンピュータ１２１２の外部にあってもよい。ネットワークインタフェース１２４８への接続に必要なハードウェア／ソフトウェアとしては、単なる例示であるが、通常の電話級モデム、ケーブルモデムおよびＤＳＬモデム等のモデム、ＩＳＤＮアダプタ、およびイーサネット（登録商標）カードのような内蔵および外付けの技術がある。
【０１１８】
以上、本発明の実施例について説明した。もちろん、本発明を説明する目的で、コンポーネントまたは方法の想定し得るあらゆる組合せを記載することはできないが、当業者には認識されるように、本発明のさらに多くの組合せおよび置換が可能である。したがって、本発明は、添付の特許請求項の精神および範囲内に入るすべてのそのような変更、修正および変形を包含することを意図している。さらに、「includes」（含む）という用語が詳細な説明または特許請求の範囲で用いられる限り、この用語は、「comprising」（「包含する」、「より成る」あるいは「備えた」）という用語が請求項における移行語として用いられる場合に解釈されるのと同様に、包括的であることを意図している。
【図面の簡単な説明】
【０１１９】
【図１】本発明の一態様によるシリアライゼーションシステムのブロック図である。
【図２】本発明の一態様による例示的アイテムストラクチャーの図である。
【図３】本発明の一態様による例示的シリアライゼーションストラクチャーの図である。
【図４】本発明の一態様によるシリアライゼーションシステムのブロック図である。
【図５】本発明の一態様によるシリアライゼーション環境のブロック図である。
【図６】本発明の一態様によるデシリアライゼーションシステムのブロック図である。
【図７】本発明の一態様によるデシリアライゼーション環境のブロック図である。
【図８】本発明の一態様によるアイテムのシリアライゼーションを容易にする方法のフローチャートである。
【図９】図８の方法をさらに示すフローチャートである。
【図１０】本発明の一態様によるアイテムのデシリアライゼーションを容易にする方法のフローチャートである。
【図１１】図１０の方法をさらに示すフローチャートである。
【図１２】本発明が機能し得る例示的オペレーティング環境を示す。
【符号の説明】
【０１２０】
１００  シリアライゼーションシステム
１１０  識別コンポーネント
１２０  ファイルシステムストア
１３０  シリアライゼーションコンポーネント
２００  アイテムストラクチャー
２１０  コアアイテム
２２０  エクステンション（拡張部）
２３０  アイテム
２４０  出リンク
２５０  入リンク
２６０  埋込みアイテム
２７０  フラグメント
２８０  バッキングファイル
３００  シリアライゼーションストラクチャー
３２０  シリアライゼーション長
３３０  ヘッダオフセット
３４０  コアアイテム
３５０  アイテムフラグメント
３６０  出リンク
３７０  アイテムエクステンション
３８０  埋込みアイテム
３９０  バッキングファイル
３９４  ヘッダ
４００  シリアライゼーションシステム
４１０  アプリケーションプログラムインタフェース
４２０  アプリケーション
５００  シリアライゼーション環境
５１０  ファイル記憶システムメタデータ
５２０  システムメタデータ
５３０  ファイルシステムビュー
６００  デシリアライゼーションシステム
６１０  アプリケーションプログラムインタフェース
６２０  デシリアライゼーションコンポーネント
６３０  アプリケーション
６４０  ファイルシステムストア
７００  デシリアライゼーション環境
７１０  システムメタデータ
７２０  基本更新ＡＰＩ
１２１０  オペレーティング環境
１２１４  処理ユニット
１２１６  システムメモリ
１２１８  バス
１２２０  揮発性
１２２２  不揮発性
１２２４  ディスクストレージ
１２２６  インタフェース
１２２８  オペレーティングシステム
１２３０  アプリケーション
１２３２  モジュール
１２３４  データ
１２３６  入力デバイス
１２３８  インタフェースポート
１２４０  出力デバイス
１２４２  出力アダプタ
１２４４  リモートコンピュータ
１２４６  メモリストレージ
１２４８  ネットワークインタフェース
１２５０  通信コネクション
【図１】
2006236328.tif 000003
【図２】
2006236328.tif 000004
【図３】
2006236328.tif 000005
【図４】
2006236328.tif 000006
【図５】
2006236328.tif 000007
【図６】
2006236328.tif 000008
【図７】
2006236328.tif 000009
【図８】
2006236328.tif 000010
【図９】
2006236328.tif 000011
【図１０】
2006236328.tif 000012
【図１１】
2006236328.tif 000013
【図１２】
2006236328.tif 000014