JP4578480B2 - オブジェクトシステム間のファイルプロパティ管理を容易にするためのプロモーションおよびデモーション技術 - Google Patents

Description

本出願は、参照によりその全体が本明細書に組み込まれている、２００３年１０月２３日に出願した、「PROMOTION AND DEMOTION TECHNIQUES TO FACILITATE FILE PROPERTY MANAGEMENT BETWEEN OBJECT SYSTEMS」という名称の米国特許出願第１０／６９３，０９０号の優先権を主張するものである。

本発明は、一般に、コンピュータシステムに関し、より詳細には、ファイルプロパティのプロモーションおよびデモーションによって、バイトストリーム中の非構造化ファイルプロパティの記憶とそのファイルの構造化オブジェクト表現の間の互換性を容易にするためのファイルプロパティハンドラを使用したシステムおよび方法に関する。本明細書で使用しているアイテムという用語は、一般に、構造化オブジェクトストアに記憶された構造化図式オブジェクトを指す。ファイルバックドアイテム（ｆｉｌｅ−ｂａｃｋｅｄ ｉｔｅｍ）とは、オブジェクトストア中のファイルの構造化オブジェクト表現を指す。ファイルという用語は、所与のファイルバックドアイテムに対応する非構造化バイトストリームを表すのに使うことができる。

従来、コンピュータファイルシステムにおいては、ファイルがデータ記憶の基本的な単位である。一般的に、ファイルシステムにおけるファイルは、次の特徴を持っている。バイトの単一シーケンスである。固定長を持ち、一般的に不揮発性記憶媒体に記憶される。ディレクトリ内に作成され、ファイル操作においてそのファイルを呼ぶのに使用できる名前を持ち、可能にはそのパスと組み合わせて使用できる。さらに、ファイルシステムは、パーミッションビットやその他のファイル属性、ファイル作成、最終改定、最終アクセスなどについてのタイムスタンプなど、その他の情報をファイルに関連付けることができる。特定のアプリケーションはまた、ファイルのバイトストリーム中に領域特有のプロパティを記憶することができる。例えば、ワードプロセッシングアプリケーションによって使用されるファイル、つまり「文書」とみなされるファイルは、その文書のタイトルや作成者のようなプロパティを記憶することができる。これらのプロパティは、そのファイルを作成しているアプリケーションに特有のフォーマットで、そのファイルのバイトストリーム内に記憶される。これらのプロパティは、オブジェクトとして構造化されているわけではなく、また、標準化された名前を持っているわけでもない。バイトストリームは、構造化されていない値である。別の例として、ミュージッククリップを記憶するファイルが、バイトストリームに記憶されている、ジャンル、作者、録音日、アーティストなどのいくつかの興味あるプロパティを有することが挙げられる。このメタデータに加えて、何らかの広く認められているフォーマットでその音楽自体を表現するバイトストリームがある。これらのプロパティを扱う場合のプログラミングモデルは、バイトストリーム全体を操作するように適合させる。このプログラミングモデルは、結果として、バインドされたインスタンス（ＣｒｅａｔｅＦｉｌｅ／ＯｐｅｎＦｉｌｅ呼び出しの結果）のハンドルが作成される、バインド参照モデルである。その後のその値の操作は、バイトストリームの該当部分の検索および更新を行うＲｅａｄＦｉｌｅ／ＷｒｉｔｅＦｉｌｅによってなされる。

本発明の目的は、異種のデータシステムの間の相互作用性および互換性を容易にするためのシステムおよび方法を提供することにある。

本発明のいくつかの態様を基本的に理解できるように、以下に本発明の簡略な要約を提供する。この要約は、本発明の広範囲にわたる概略を示したものではない。本発明の重要な要素を識別することを意図したものでもなく、また、本発明の範囲を描写することを意図したものでもない。その唯一の目的は、後述するより詳細な説明の前置きとして、簡略化した形で本発明のいくつかの概念を提示することである。

本発明は、バイトストリーム中のプロパティの記憶と、ファイルの構造化オブジェクト表現のプロパティを、それらが単独に更新された場合に同期させることを可能にすることによって、構造化オブジェクトとして、またファイルバイトストリームとしてのファイル操作を容易にする、システムおよび方法に関する。オブジェクトストア内のファイルバックドアイテムを操作するための、また、非構造化バイトストリームとしてファイルを操作するための適切なアプリケーションプログラミングインターフェースがあるとする。プロモーションおよびデモーションと呼ばれるシステムの相互作用、方法、および手順によって、ファイル中の非構造化プロパティが、そのファイルのファイルバックドアイテム表現に適切にマップされ、またそのファイルバックドアイテム表現と一致し続けることを可能にするためのファイルプロパティハンドラが提供される。プロモーションは、アプリケーションが、ファイルに対応するバイトストリームを直接、操作することによって、そのファイルの修正または操作を行おうとする場合に呼び出される。したがって、プロモーションは、アプリケーションが２つの環境を一致させるためにバイトストリーム中の非構造化ファイルプロパティを更新した場合に、ファイルプロパティハンドラがオブジェクトストア中の構造化ファイルプロパティを更新するプロセスである。非構造化ファイルプロパティを構造化オブジェクトストア内のオブジェクトにプロモートすることは、様々な目的の達成を容易にする。例えば、以下はその例である。
ａ）構造化オブジェクトストアは、ファイルの問合せを、ファイルのプロパティに基づいて効率的に行うことができるようにする。これは、一般に、非構造化バイトストリーム中に記憶されているプロパティではできない。
ｂ）非構造化プロパティは、標準化されたオブジェクト表現を順守した、十分に構造化されたオブジェクトとして表現される。したがって、アプリケーションは、バイトストリームを操作するモデルではなく、オブジェクト指向のプログラミングモデルを使って、これらのオブジェクトと容易に動作することができる。

オブジェクトストア中のプロモート済みファイルバックドアイテムが操作され、更新された場合、ファイルプロパティハンドラは、デモーションプロセスを容易にする。デモーションプロセスでは、構造化オブジェクト中の変更に対応する非構造化ファイル中のプロパティを更新するために、逆変換が実行される。このように、プロモーションおよびデモーションは、ファイルプロパティが、手元の対象システムに適したプロパティに従って自動的に更新され、維持される（例えば、プロモーションによって非構造化プロパティを構造化プロパティに更新する、またはデモーションによってその反対を行う）ことを可能にする。

本発明の一態様では、アプリケーションがプロパティを操作して非構造化ファイルに保存すると、ブリッジコンポーネント（例えば、ファイルプロパティマネージャ）がファイルプロパティハンドラと通信して、ファイルバイトストリーム中の非構造化プロパティの構造化オブジェクトへの変換を行わせる。ファイルプロパティマネージャは、非構造化ファイルストアによってエクスポーズされるメカニズムを利用して、オブジェクトストアにおいて更新されるべき、修正された非構造化ファイルを追跡する。

前記および関連する目的を達成するために、本明細書では、本発明の特定の例示的態様を、以下の説明および添付の図面に関連させて説明する。これらの態様は、本発明を実施できる様々な方法を表すものであり、そのすべてが、本発明に包含されるよう意図されている。本発明のその他の利点および新奇な特徴は、図面と関連させながら以下の本発明の詳細な説明を読むことにより明らかになるであろう。

本発明は、ファイルを非構造化バイトストリームおよび構造化オブジェクトとして操作することを、特定のアプリケーションプログラミングインターフェースを介して一方がもう一方と無関係に更新された場合にもそれらを一致させることを可能にすることによって、容易にするシステムおよび方法に関する。

ファイルプロパティハンドラは、ファイル内の非構造化プロパティを、対応するファイルバックドアイテムに関連付けられた１つまたは複数の構造化オブジェクトプロパティに従って操作する。非構造化ファイルストリームが直接、更新された場合にはいつでも、プロモーションオペレーションが実行されて、構造化プロパティを有するファイルバックドアイテムが更新される。同様に、構造化オブジェクト環境で使用されているアプリケーションプログラミングインターフェースを用いてファイルバックドアイテムが操作され、更新された場合には、デモーションオペレーションまたは逆変換が実行されて、ファイルの非構造化表現中のプロパティが更新される。

この適用で使用されているように、「コンポーネント」、「ハンドラ」、「マネージャ」などの用語は、コンピュータ関連のエンティティ、すなわち、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図している。例えば、コンポーネントは、プロセッサ上で実行しているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピュータの場合があるが、それらであることに限定されるわけではない。例として、サーバ上で実行しているアプリケーションとそのサーバがともに１つのコンポーネントということがあり得る。１つまたは複数のコンポーネントがプロセスおよび／または実行のスレッド内に常駐することができる。また、コンポーネントを１台のコンピュータ上に集中させることができ、かつ／または２台以上のコンピュータに分散させることができる。

まず図１を見ると、本発明の一態様によるファイル変換システム１００を図示してある。ファイル変換システム１００は、一般的に１つまたは複数の非構造化ファイル１２０と関連付けられている、システムまたはアプリケーション１１０を含み、アプリケーション１１０およびファイルは、一般に、非構造化環境に関連付けられている。一般に構造化オブジェクトストア環境に関連付けられている構造化オブジェクトシステムまたはアプリケーション１５０との通信および互換性を容易にするために、ブリッジモジュール１３０およびファイルプロパティハンドラ１４０が設けられている。一例では、構造化システムアプリケーションを、一般的に例えばＸＭＬなどのコードに関連付けられている、１つまたは複数の図式オブジェクト１６０に関連付けることができる。

あるファイルが非構造化ファイルとして修正、保存、および／または操作された場合、ブリッジモジュールまたはファイルプロパティマネージャ１３０が、非構造化ファイルから構造化オブジェクトへの変換を指示する役割を果たす。この変換は、ブリッジモジュールがファイルプロパティハンドラ１４０を呼び出すことによって実行される。ファイルプロパティハンドラ１４０は、プロモーションオペレーションを実行して、管理されていないファイルの非構造化プロパティを、構造化ストア１６０に対して動作するアプリケーションに関連付けられた構造化プロパティに変換する。プロモートされたオブジェクトが構造化ストアアプリケーションプロパティから操作された場合には、ファイルプロパティハンドラ１４０はデモーションオペレーションを実行する。デモーションオペレーションは、プロパティを、その後に非構造化ファイル中で更新されるプロパティに逆変換する。

一態様では、ファイルベースのアプリケーション１１０が、ファイルバックドアイテムとしても知られる構造化オブジェクトに対応するファイルストリームを更新することによってプロパティの修正を継続する場合に、プロモーションが動作する。したがって、構造化オブジェクトシステム１６０内のアイテム中のプロパティのコピーを、ファイルの更新によって生じた変更をそのアイテムが反映するように更新するプロセスとして、プロモーションをモデル化することができる。一方、デモーションは、構造化ストアに対して動作する新しいアプリケーションが、例えば構造化オブジェクトのアプリケーションプログラミングインターフェース（ＡＰＩ）を使って、アイテムの問合せおよびアイテムの修正を行う場合に、そのアイテムがファイルバックドアイテムであるかどうかにかかわらず動作する。ファイルバックドアイテムの場合には、これらのプロパティのうちあるもの（前にそのファイルからプロモートされたもの）は、その後、ファイルに書き戻される。このプロセスはデモーションと呼ばれ、本質的にはプロモーションの逆変換である。

ファイルプロパティハンドラ１４０に関しては、所与のファイルからプロパティをどのようにプロモートし、かつ／または所与のファイルにプロパティをどのようにデモートするかを決定する、ファイルプロパティハンドラ（ＦＰＨ）と呼ばれるコードモジュールを呼び出すことによって、プロモーションおよびデモーションが行われる。ＦＰＨ１４０は、一般的に、１つまたは複数の選択されたファイル拡張子を処理するために登録される。場合によっては、ＦＰＨ１４０がプロモート機能またはデモート機能のみを実行することを決定できることに注意されたい。本明細書に記載してあるように、「プロモータ」という用語が使用されている場合、それは、プロモーションという状況で説明してるＦＰＨを指し、「デモータ」は、デモーションという状況で説明しているＦＰＨを指す。

ブリッジコンポーネント１３０（ファイルプロパティマネージャともいう）は、ＦＰＨ１４０と相互作用して、プロモーションおよびデモーションを容易にする。したがって、ブリッジコンポーネント１３０は、プロモーション変更待ち行列（以下に記載）からエントリを受け取ると、ファイルのプロモートすべきストリームへのポインタを有する、ファイルの適切なＦＰＨ１４０を呼び出す。次いで、ＦＰＨ１４０は、ファイル中の非構造化プロパティの抽出および構造化オブジェクトストア１６０に記憶されている、管理アイテムの構造化プロパティへの変換（以下に記載）を実行する。デモーションに関しては、構造化オブジェクトストア１６０中でアイテムが更新されると、構造化オブジェクトＡＰＩがデモータを呼び出す。デモータは、逆変換および抽出コードを利用して、更新されたプロパティをファイルに書き戻す。ＦＰＨ１４０の抽出部分は、そのファイルフォーマットに特有のＡＰＩを使って、プロパティを抽出する。一般に、１つの所与のファイルについて、１つの登録ＦＰＨ１４０が呼び出されることに注意されたい。

次に図２を見ると、本発明の一態様に従って、より詳細な変換システム２００を図示してある。システム２００は、プロモーションおよび／またはデモーションの論理モデルを表す。この態様では、１つまたは複数のＦＰＨ２１０（ファイルプロパティハンドラ）が管理コード中に常駐している。ＦＰＭ２２０（ファイルプロパティマネージャ）は、管理ＦＰＨ２１０に対する相互作用性またはブリッジコンポーネントとしての役割を果たす。ＦＰＭ２２０は、一般に、実際のオブジェクトストア２３０を維持するプロセスとはまったく異なる、別個のプロセスとして実行する。上述のように、プロモーションおよびデモーションのためのメソッドを定義する抽象ＢａｓｅＦｉｌｅＰｒｏｐｅｒｔｙＨａｎｄｌｅｒクラスを提供することができる。したがって、ファイルプロパティハンドラ２１０は、プロモーションおよび／またはデモーションにおいて呼び出されるメソッドを実行する、抽象ＢａｓｅＦｉｌｅＰｒｏｐｅｒｔｙＨａｎｄｌｅｒから導出される、具体的な管理クラスとしてモデル化される。例えば、ＦＰＭ２２０は、特定のファイル拡張子を有するファイルのためのプロモーションを呼び出すためにそのクラスのインスタンスを生成することができる。以下のコードの抜粋は、クラス指定の例を表す。

プロモーションは、ファイルと動作するアプリケーションが、ファイルＡＰＩを使ってファイルバックドアイテムのファイルストリームを修正する場合に呼び出される。したがって、プロモーションは、このようなアプリケーションを使って構造化ストアの名前空間中のファイルを修正する場合に呼び出されるべきものである。一般に、構造化ストアの名前空間に移行されず、また、非構造化ファイル環境中に存在し続けるファイルについては、どのようなプロモーションも行われるはずはない。構造化ストアの名前空間中のファイルがファイルＡＰＩを使用するアプリケーションによって修正されると、ファイルプロモーションマネージャ２２０またはサービスは、このファイル上に非同期的にＦＰＨ２１０を呼び出して、そのファイルに対応するアイテムを更新する。一般的に、ファイル拡張子ごとに１つのＦＰＨ２１０が登録される。ファイルバックドアイテム上に保留状態のプロモーションがあると、そのアイテム上の「ｐｒｏｍｏｔｉｏｎＳｔａｌｅ」フラグが１に設定される。

図２に示すように、非構造化ファイルと動作しているアプリケーションが、２３０の構造化ストアの名前空間中のファイル２４０を修正した場合、ＦＰＨ２１０は、２３０で保存すべきプロモート済みアイテムを返す前に、２５０で非構造化プロパティの抽出および変換を行う。これに対し、デモーションは、一般に、構造化ストアＡＰＩ２００によってファイルバックドアイテムが更新された場合に呼び出される。構造化ストアＡＰＩ２００は、アプリケーションが、１つまたは複数のファイルバックドアイテムまたはそのようなアイテムの一部を修正することを可能にする。これを行った後、アプリケーションが構造化ストアＡＰＩを使って変更済みアイテム（場合により複数）を保存しようとすると、保存を行うために呼び出された構造化ストアＡＰＩ中のメソッドは、以下を行う。アイテムを保存する機能を実行する構造化ストアＡＰＩ中のメソッドを、ここでは、概念上、「保存」メソッドと呼ぶ。ただし、正確なメソッド名は実装に依存する。

ファイルバックドアイテムまたはその一部が構造化ストアＡＰＩによって修正された場合、構造化ストアＡＰＩの保存メソッドは、そのファイルバックドアイテムに対応するデモータをルックアップし（ファイル拡張子に基づいて）、それを呼び出す。デモータは、読取／書込用のアイテム（またはその一部）および書込用のファイルストリームを取り込み、そのアイテムの変更に基づいてファイルの内容を更新する。デモーションは、アイテムを構造化ストアに保存しようとするオペレーションの間に呼び出されるため、一般に、同期的オペレーションである。上記の保存メソッドは、デモータを呼び出すことによってファイル２４０を更新するとともに、適切なプロパティを構造化データストア中のアイテムに書き込む。

図３〜６は、本発明の一態様による、ファイルプロパティハンドラおよびファイルプロパティマネージャのための自動化されたプロモーションおよびデモーションのプロセスを説明している。説明をわかりやすくするために、方法を一連の動作として示し、説明しているが、本発明はその動作順に限定されるわけでなく、本発明によれば、動作によっては、本明細書に示し、説明している順番とは異なる順序で、および／または他の動作と同時に行われる場合がある。例えば、当業者は、方法を、その代わりに、状態図におけるような一続きの相互関連する状態またはイベントとして表せることを理解されるであろう。さらに、本発明による方法を実施するために、図示の動作すべてが必要ではない場合もある。

図３および４を同時に説明する。図３は、プロモーション中のファイルプログラムマネージャ（ＦＰＭ）のプロセスを表し、図４は、プロモーション中のファイルプロパティハンドラ（ＦＰＨ）のプロセスを表す。一般に、ファイルは、プロモーションのために変更待ち行列と呼ばれる待ち行列に入れられる。以下は、ファイルプログラムマネージャが変更待ち行列からファイルバックドアイテムを受け取った後のプロモーションに関与する動作である。３１０で、ＦＰＭは、ファイルが存在する構造化ストアからＦＰＨ登録情報をルックアップすることによって、そのファイルのＦＰＨをルックアップする。３２０で、ＦＰＭは、対応するＦＰＨをロードする。例えば、これは、個々のマシンのグローバルアセンブリキャッシュからＦＰＨアセンブリをロードし、ＦＰＨクラスのインスタンスを検索することによって行うことができる。３３０で、ＦＰＭは、トランザクションを開始し、アイテムを変更待ち行列から取り出す。３４０で、ＦＰＭは、変更されたファイルに対応する構造化ストアアイテム（Ｉ１）を検索する。３５０で、ＦＰＭは、該当するメソッド（場合により複数）をＦＰＨ上に呼び出すことによって、プロモーションを実行する。

３５０の後、プロセスは、ＦＰＨ処理に関連する図４の４１０に進む。この時点で、ＦＰＨは、まず、アイテムの構造を変更することができる。４２０で、ＦＰＨは、プロパティを抽出し、そのプロパティに基づいてアイテムを更新する。４３０で、ＦＰＨは、アイテムの修正された部分を、プロモート済みとしてマークする。４３０の後、プロセスは、さらにＦＰＭ処理を行うために図３の３６０に戻る。３６０で、ＦＰＭは、そのアイテムを、ｐｒｏｍｏｔｉｏｎＳｔａｌｅではないとしてマークする。３７０で、ＦＰＭは、構造化オブジェクトストアにその変更を適用する。３８０で、ＦＰＭは、コミット／ロールバックトランザクションを実行し、ファイルハンドルを閉じる。

図５および６を同時に説明する。図５は、デモーション中の構造化ストア保存機能（前に定義済み）のプロセスを表し、図６は、デモーション中のファイルプロパティハンドラ（ＦＰＨ）のプロセスを表す。図５に進むと、修正されたアイテムについて以下の動作が実行される。５１０で、ファイルバックドアイテムかどうかを更新機能がチェックする。ファイルバックドアイテムでない場合には、デモーションコードがバイパスされ、通常の非ファイルバックドアイテムの処理が開始される。ファイルバックドアイテムの場合には、そのアイテムについて、アイテムのファイルバックされた一部のみに更新がなされたかどうかを判断する。これは、構造化オブジェクトストア中の、そのアイテムに関連付けられたｉｓＦｉｌｅＢａｃｋｅｄビットをルックバックすることによってなされる。

５２０で、保存機能は、ファイルバックドアイテムが常駐しているストア（これは、リモートファイルの場合には別のマシン上にある場合がある）に問い合わせて、このファイル拡張子について登録されているＦＰＨをチェックする。これによって、そのファイルをプロモートしたＦＰＨについての詳細（例えば、アセンブリ名およびバージョンナンバー）が返される。５３０で、更新機能は、前記の情報に基づいて該当するＦＰＨ（これは、例えば、個々のマシンのグローバルアセンブリキャッシュ中に登録しておくことができる）をロードする。５４０で、保存機能は、デモーションを実行するために、ＦＰＨ上にメソッド（場合により複数）を呼び出す。変更されたアイテムはまた、そのアイテムになされた変更の記録も含む。これらの変更は、構造化ストアＡＰＩによって追跡される。

５４０の後、プロセスは、さらにＦＰＨ処理を行うために図６の６１０に進む。６１０で、ＦＰＨは、追跡されたアイテム中の変更を見て、どのフィールドをデモートする必要があるかを識別する。６２０で、ＦＰＨは、アイテムから変更を読み取り、非構造化ファイルのプロパティに書き込む。これには、構造化ストアＡＰＩを呼び出して、そのストアから他の情報を読み取ることが含まれる場合もある。６３０で、ＦＰＨは、アイテム、またはアイテムのデモートされた部分に「プロモート済み」フラグを１に設定する。プロセスは、次いで、さらに保存機能の処理を行うために図５の５５０に戻る。５５０で、保存機能は、アイテムに施された変更をストアに適用する。５６０で、保存機能はストリームを閉じ、ファイルのトランザクションをコミットする。

前に述べたように、「第１のプロモーション」に関して処理が異なる場合がある。一般に、第１のプロモーションの動作は、その他のプロモーションとは区別される。これは、第１のプロモーションが、アイテムとファイルを互いに一致させる必要がある場合があるためである。

図７は、本発明の一態様によるファイルバックドアイテムの状態図７００を示す。上記の説明を考慮に入れて、ファイルバックドアイテムの状態を図７００において説明する。構造化ストアＡＰＩは、ｐｒｏｍｏｔｉｏｎＳｔａｌｅ＝１でファイルバックドアイテムを更新することはできない。あるアイテムがファイルバックドアイテムであって、７１０で、そのアイテム中に保留状態のプロモーションがある場合、そのアイテム上の「ｐｒｏｍｏｔｉｏｎＳｔａｌｅ」ビットは真である。構造化ストアＡＰＩを使ってファイルバックドアイテムを更新し、それによってデモーションを呼び出すことを望むアプリケーションは、以下のように動作することができる。
１）アイテムをフェッチする。
２）アイテムが「ｐｒｏｍｏｔｉｏｎＳｔａｌｅ」かどうかを問い合わせる。
３）アイテムがｓｔａｌｅの場合には、
− ＡＰＩ中の「ＳｙｎｃｈｒｏｎｏｕｓＰｒｏｍｏｔｅ」メソッドを呼び出して、アイテムを最新にする。
注意：２および３は任意選択である。
４）フェッチしたアイテムを更新する。
５）構造化ストアＡＰＩの保存メソッドを呼び出して、そのアイテムの保存を試みる。
６）保存がデモーションに成功した場合には、終了する。
７）そうでなければ、
８）返されたエラーコードが「Ｉｔｅｍ Ｉｓ ＰｒｏｍｏｔｉｏｎＳｔａｌｅ」の場合には（アプリケーションが上記の２および３を実行しなかった場合に生じる）、
− ＡＰＩ中の「ＳｙｎｃｈｒｏｎｏｕｓＰｒｏｍｏｔｅ」メソッドを呼び出して、アイテムを最新にする。ｕｐｄａｔｅｄＩｔｅｍを返す。
− 上記の４に行き、ｕｐｄａｔｅｄＩｔｅｍに変更を適用する。
９）返されたエラーコードが「Ｉｔｅｍ Ｈａｓ ｂｅｅｎ Ｕｐｄａｔｅｄ」の場合には、
− 上記の４に行く。

一般に、ファイルタイプごとに１つのＦＰＨが登録される。しかし、ファイルフォーマットが拡張可能な場合は、ファイル中の非構造化プロパティに新しいプロパティが追加される場合があり、それが作成されたときにＦＰＨがそのことを知らなかったということがある。所与のファイルタイプのＦＰＨを、そのＦＰＨの作成者およびエンドユーザ以外のソフトウェアベンダ／ソリューションプロバイダによって追加された新規またはカスタムのプロパティをプロモート／デモートするように拡張することを可能にする、本システムによってサポートされる様々な拡張スキームがある。これによって、その新たに追加された非構造化ファイルプロパティも、アイテム上の新しい構造化プロパティに変換することが可能になる。拡張スキームの例は以下の通りである。
１．単純非構造化プロパティをファイルに追加し、それらをアイテム上の単純構造化プロパティに変換したいと思うソフトウェアベンダ／ソリューションプロバイダは、以下を行うことができる。
ａ）対応する新しい単純構造化プロパティをそのアイテムに追加し、
ｂ）新たに追加された非構造化プロパティを、どのように新たに追加された構造化アイテムプロパティに変換すべきかを、ＸＭＬスキームを使って宣言部分で指定する。
ファイルタイプについて登録されている主要ＦＰＨがこれらの変換を実行する（プロモーションおよびデモーション両方の間に）ので、ファイルを拡張するベンダが新たなコードを書く必要がない。
２．ファイルに非構造化プロモーションを追加して、それらをアイテム上のより複雑な構造化プロパティに変換したいと思う、またはアイテム間の関係を確立したいと思うソフトウェアベンダ／ソリューションプロバイダは、以下を行うことができる。
ａ）対応する複雑構造化プロパティをアイテムに追加し、
ｂ）非構造化プロパティを新たに追加された構造化アイテムプロパティに変換する構造化ストアＡＰＩを使ったコード、またはまたはアイテム間の関係を確立するコードを書く。このコードは、ファイルタイプの主要ＦＰＨの実装に類似している。
３．エンドユーザは、新たなプロパティをファイルに追加することができる。これらは、ファイルの構造化アイテム表現上のデフォルトプロパティセットにプロモートまたはデモートされる。

図８を見ると、本発明の様々な態様を実施するための例示的環境８１０は、コンピュータ８１２を含む。コンピュータ８１２は、処理装置８１４、システムメモリ８１６、およびシステムバス８１８を含む。システムバス８１８は、システムコンポーネントを処理装置８１４に結合する。システムコンポーネントにはシステムメモリ８１６が含まれるが、それだけに限定されるものではない。処理装置８１４は、様々な利用可能なプロセッサのうちのいずれかであってよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、処理装置８１４として使用することができる。

システムバス８１８は、様々な利用可能なバスアーキテクチャのいずれかを使用した、メモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってよい。アーキテクチャには、１６ビットバス、業界標準アーキテクチャ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＣＡ）、拡張ＩＳＡ（ＥＩＳＡ）、インテリジェントドライブエレクトロニクス（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、周辺コンポーネント相互接続（ＰＣＴ）、ユニバーサルシリアルバス（ＵＳＢ）、アドバンストグラフィックスポート（ＡＧＰ）、パーソナルコンピュータメモリカード国際協会バス（ＰＣＭＣＩＡ）、および小型コンピュータシステムインターフェース（ＳＣＳＩ）が含まれるが、それらに限定されるわけではない。

システムメモリ８１６は、揮発性メモリ８２０および不揮発性メモリ８２２を含む。起動中などにコンピュータ８１２内の構成要素間で情報を転送するための基本ルーチンを含む、基本入出力システム（ＢＩＯＳ）は、不揮発性メモリ８２２に記憶されている。限定ではなく例として、不揮発性メモリ８２２は、読取り専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含む。揮発性メモリ８２０は、外部キャッシュメモリとしての役目を果たす、ランダムアクセスメモリ（ＲＡＭ）を含む。限定ではなく例として、ＲＡＭは、同期ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）などの多くの形態で利用可能である。

コンピュータ８１２はまた、取外し可能／取外し不可能な揮発性／不揮発性コンピュータ記憶媒体も含む。図８は、例えばディスクストレージ８２４を示す。ディスクストレージ８２４は、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックなどのデバイスを含むが、それらに限定されるわけではない。さらに、ディスクストレージ８２４は、その他の記憶媒体とは別個の、またはその他の記憶媒体と組み合わせた記憶媒体を含み、これには、コンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）などの光ディスクドライブ、ＣＤ記録可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ書換え可能ドライブ（ＣＤ−ＲＷドライブ）またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）が含まれるが、それらに限定されるわけではない。ディスクストレージデバイス８２４のシステムバス８１８への接続を容易にするために、一般的に、インターフェース８２６などの取外し可能または取外し不可能インターフェースが使用される。

図８が、適切な動作環境８１０において説明した、ユーザと基本的なコンピュータリソースの間を仲介する役目を果たすソフトウェアを説明する図であることに注意されたい。このようなソフトウェアにはオペレーティングシステム８２８が含まれる。オペレーティングシステム８２８は、ディスクストレージ８２４上に記憶することができ、コンピュータシステム８１２のリソースの制御および割当を行う役目を果たす。システムアプリケーション８３０は、システムメモリ８１６中またはディスクストレージ８２４上に記憶されているプログラムモジュール８３２およびプログラムデータ８３４を介して、オペレーティングシステム８２８によるリソースの管理を利用する。本発明を様々なオペレーティングシステムまたはオペレーティングシステムの組合せで実施装できることを理解されたい。

ユーザは、入力デバイス（場合により複数）８３６を介して、コンピュータ８１２にコマンドまたは情報を入力する。入力デバイス８３６は、マウス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどのポインティングデバイスを含むが、それらに限定されるわけではない。これらおよびその他の入力デバイスは、インターフェースポート（場合により複数）８３８を介し、システムバス８１８を通して、処理装置８１４に接続する。インターフェースポート（場合により複数）８３８は、例えば、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）を含む。出力デバイス（場合により複数）８４０は、入力デバイス（場合により複数）８３６と同じタイプのポートのいくつかを使用する。したがって、例えば、ＵＳＢポートを使って、コンピュータ８１２に入力を供給することができ、また、コンピュータ８１２からの情報を出力デバイス８４０に出力することができる。その他の出力デバイス８４０の中には、モニタ、スピーカ、およびプリンタのような、特殊なアダプタを必要とするいくつかの出力デバイス８４０があることを説明するために、出力アダプタ８４２を設けてある。出力アダプタ８４２は、限定ではなく例として、出力デバイス８４０とシステムバス８１８の間の接続手段を提供する、ビデオおよびサウンドカードを含む。リモートコンピュータ（場合により複数）８４４など、その他のデバイスおよび／またはデバイスのシステムが、入力と出力の両機能を提供することに注意されたい。

コンピュータ８１２は、リモートコンピュータ（場合により複数）８４４などの１つまたは複数のリモートコンピュータへの論理接続を使って、ネットワーク化された環境で動作することができる。リモートコンピュータ（場合により複数）８４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの器具、ピアデバイス、またはその他の一般的なネットワークノードなどであってよく、また、一般的に、コンピュータ８１２に関して説明した構成要素の多くまたはすべてを含む。簡単にするために、メモリ記憶デバイス８４６をリモートコンピュータ（場合により複数）８４４とともに示してある。リモートコンピュータ（場合により複数）８４４は、ネットワークインターフェース８４８を介してコンピュータ８１２に論理的に接続され、次いで、通信接続８５０を介して物理的に接続される。ネットワークインターフェース８４８は、ローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）などの通信ネットワークを包含する。ＬＡＮ技術には、ファイバー分布データインターフェース（ＦＤＤＩ）、銅線配線データインターフェース（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ１１０２．３、トークンリング／ＩＥＥＥ１１０２．５などが含まれる。ＷＡＮ技術には、ポイントツーポイントリンク、統合サービスデジタルネットワーク（ＩＳＤＮ）およびその変型のような回路交換ネットワーク、パケット交換ネットワーク、デジタル加入者回線（ＤＳＬ）などが含まれるが、それらに限定されるわけではない。

通信接続（場合により複数）８５０は、ネットワークインターフェース８４８をバス８１８に接続するために使用されるハードウェア／ソフトウェアを表す。説明をわかりやすくするために、通信接続８５０をコンピュータ８１２の内部に示してあるが、通信接続８５０はコンピュータ８１２の外部であってもよい。例にすぎないが、ネットワークインターフェース８４８への接続のために必要なハードウェア／ソフトウェアは、通常の電話グレードのモデム、ケーブルモデム、ＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、およびイーサネット（登録商標）カードなどの、内部および外部技術を含む。

図９は、本発明が相互作用できるサンプルコンピューティング環境９００のの概略構成図である。システム９００は、１つまたは複数のクライアント９１０を含む。クライアント（場合により複数）９１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であり得る。システム９００はまた、１つまたは複数のサーバ９３０を含む。サーバ（場合により複数）９３０も、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であり得る。サーバ９３０は、例えば、本発明を使用することによって、変換を実行するためのスレッドを収容することができる。クライアント９１０とサーバ９３０の間の可能な通信形態の１つとして、２つ以上のコンピュータプロセス間で伝送されるようになされたデータパケットという形態がある。システム９００は、クライアント（場合により複数）９１０とサーバ（場合により複数）９３０の間の通信を容易にするために使用できる、通信フレームワーク９５０を含む。クライアント（場合により複数）９１０は、クライアント（場合により複数）９１０にのみ利用可能な情報を記憶するために使用できる、１つまたは複数のクライアントデータストア９６０に動作可能に接続される。同様に、サーバ（場合により複数）９３０は、サーバ９３０にのみ利用可能な情報を記憶するために使用できる１つまたは複数のサーバデータストア（場合により複数）９４０に動作可能に接続される。

上記の説明には本発明の例が含まれている。本発明を説明する目的で、コンポーネントまたは方法の考えられるすべての組合せを記載することはもちろん不可能である。しかし、当業者は、本発明のさらなる組合せおよび並べ替えが可能であることを理解できるであろう。したがって、本発明は、添付の特許請求の範囲の趣旨および範囲に含まれる、すべてのこのような変更、修正、および変型を包含するよう意図されている。さらに、詳細な説明または特許請求の範囲のいずれかにおいて「含む（ｉｎｃｌｕｄｅｓ）」という用語が使われている場合、このような用語は、請求項において移行語として使用されている場合の「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語と同様に、包括的であるとして意図されたものである。

本発明の一態様によるファイル変換システムの概略構成図である。 本発明の一態様によるより詳細なファイル変換システムの概略構成図である。 本発明の一実施形態による、ファイルプロパティハンドラおよびファイルプロパティマネージャの自動化されたプロモーションおよびデモーションのプロセスを説明する流れ図である。 本発明の一実施形態による、ファイルプロパティハンドラおよびファイルプロパティマネージャの自動化されたプロモーションおよびデモーションのプロセスを説明する流れ図である。 本発明の一実施形態による、ファイルプロパティハンドラおよびファイルプロパティマネージャの自動化されたプロモーションおよびデモーションのプロセスを説明する流れ図である。 本発明の一実施形態による、ファイルプロパティハンドラおよびファイルプロパティマネージャの自動化されたプロモーションおよびデモーションのプロセスを説明する流れ図である。 本発明の一態様によるアイテムの状態図である。 本発明の一態様による適切な動作環境を説明する概略構成図である。 本発明が相互作用できるサンプルコンピューティング環境の概略構成図である。

Claims (26)

1. プロセッサを含むコンピュータ実装ファイル変換システムであって、
   オブジェクトとして構造化されていない１つまたは複数の非構造化プロパティを有するファイルと、
   オブジェクトとして構造化されている１つまたは複数の構造化プロパティを有するアイテムであって、前記ファイルの構造化オブジェクト表現であり、構造化オブジェクトストア中のファイルバックドアイテムであるアイテムと、
   非構造化バイトストリームと動作しているアプリケーションと、前記ファイルの構造化オブジェクト表現と動作しているアプリケーションとの間の通信を容易にするファイルプロパティマネージャであって、前記ファイルの前記非構造化バイトストリーム表現が修正されたという通知を受け取り、前記ファイルのバイトストリームへのポインタを有するファイルプロパティハンドラを呼び出すファイルプロパティマネージャと、
   前記構造化プロパティに対する変更に基づいて前記１つまたは複数の非構造化プロパティを更新する、デモートするための変換、および前記非構造化プロパティに対する変更に基づいて前記構造化プロパティを更新する、プロモートするための変換の少なくとも一方を実行するファイルプロパティハンドラと
   を備えることを特徴とするシステム。
2. 前記ファイルプロパティハンドラは、前記非構造化プロパティを前記構造化プロパティにプロモートするために、抽出と変換の少なくとも一方を実行することを特徴とする請求項１に記載のシステム。
3. 前記ファイルプロパティハンドラは、前記構造化プロパティを前記非構造化プロパティにデモートするために、抽出と変換の少なくとも一方を実行することを特徴とする請求項１に記載のシステム。
4. 前記ファイルプロパティハンドラは、アプリケーションが、前記ファイルバックドアイテムを操作する構造化ストアアプリケーションプログラミングインターフェース（ＡＰＩ）を使用してアイテムの問合せおよび修正を行う場合に、デモーションオペレーションを容易にすることを特徴とする請求項１に記載のシステム。
5. 前記ファイルプロパティハンドラは、１つまたは複数の選択されたファイル拡張子を処理するために登録されることを特徴とする請求項１に記載のシステム。
6. 前記ファイルプロパティハンドラは、プロモーションおよびデモーションのためのメソッドを定義する抽象クラスに関連付けられていることを特徴とする請求項１に記載のシステム。
7. 前記抽象クラスは、ＢａｓｅＦｉｌｅＰｒｏｐｅｒｔｙＨａｎｄｌｅｒ、プロモートメソッド、デモートメソッド、第１のプロモートメソッド、直列化アイテムストアメソッド、および直列化アイテム検索メソッドのうち少なくとも１つを含むことを特徴とする請求項６に記載のシステム。
8. アプリケーションがファイルバックドアイテムを修正できるようにするアプリケーションプログラミングインターフェース（ＡＰＩ）をさらに含むことを特徴とする請求項１に記載のシステム。
9. コンピュータを、請求項１記載のファイルプロパティハンドラとして機能させるためのプログラムを記録したことを特徴とするコンピュータ可読媒体。
10. プロセッサを含み、データ変換を容易にするためのコンピュータ実装システムであって、
    非構造化バイトストリームであるファイルの、オブジェクトとして構造化されていない非構造化ファイルプロパティを構造化ストアアプリケーションがアクセスできるようにする、エクスポーズするための手段と、
    前記非構造化ファイルプロパティと動作しているアプリケーションと、前記ファイルの構造化オブジェクト表現と動作しているアプリケーションとの間の通信を容易にするための手段と、
    前記ファイルの前記非構造化バイトストリーム表現が修正されたという通知を受け取るための手段と、
    前記ファイルの非構造化バイトストリームへのポインタを有する、前記ファイルのファイルプロパティハンドラを呼び出すための手段と、
    前記非構造化ファイルプロパティを、前記構造化ストアアプリケーションに関連付けられたアイテムであって、前記ファイルの構造化オブジェクト表現であり、構造化オブジェクトストア中のファイルドバックアイテムであるアイテムの構造化アイテムプロパティに変換するための手段と、
    ファイルアプリケーションプログラミングインターフェース（ＡＰＩ）ベースのアプリケーションが、ファイルバックドアイテムである構造化オブジェクトストアアイテムに対応する前記非構造化バイトストリームを更新することによって前記非構造化プロパティを修正する際に前記非構造化プロパティの修正に基づいて前記構造化アイテムプロパティを更新するプロモーション動作を容易にするための手段と、
    前記構造化ストアアプリケーションにおいて前記構造化アイテムプロパティを更新するための手段と、
    前記更新された構造化アイテムプロパティを記憶するための手段と
    を備えることを特徴とするシステム。
11. 前記構造化アイテムプロパティを非構造化ファイルプロパティに変換するための手段をさらに含むことを特徴とする請求項１０に記載のシステム。
12. データアイテム変換を容易にするコンピュータに実装される方法であって、
    オブジェクトとして構造化されていない非構造化プロパティを有するファイルのストリームと動作しているアプリケーションと、ファイルの構造化オブジェクト表現と動作しているアプリケーションとの間の通信を実行するステップと、
    ファイルアプリケーションプログラミングインターフェース（ＡＰＩ）ベースのアプリケーションを利用することを介して、構造化ストアの名前空間にある、１つまたは複数の非構造化プロパティに関連付けられた前記ファイルを修正するステップと、
    前記ファイルの非構造化プロパティを有するファイルのストリームの修正に関連する通知を受け取るステップと、
    前記修正された非構造化プロパティを有するファイルのストリームに対応するポインタを有する、前記ファイルのファイルプロパティハンドラを呼び出すステップと、
    ファイルアプリケーションプログラミングインターフェース（ＡＰＩ）ベースのアプリケーションが、前記ファイルの構造化オブジェクト表現であり、構造化オブジェクトストア中のファイルバックドアイテムである構造化オブジェクトストアアイテムに対応する前記ファイルのストリームを更新することによって前記非構造化プロパティを修正する際に、前記ファイルに関連付けられた１つまたは複数の非構造化プロパティの修正に基づいて、ファイルバックドアイテムに関連付けられた構造化プロパティを更新する、プロモートするステップと、
    前記更新された構造化プロパティを記憶するステップと
    を有することを特徴とする方法。
13. 前記アイテムに関連付けられた１つまたは複数の構造化プロパティの修正に基づいて、前記ファイルＡＰＩベースのアプリケーションに従うように前記ファイルの非構造化プロパティを更新する、デモートするステップをさらに含むことを特徴とする請求項１２に記載の方法。
14. 前記アイテムについて、その一部の更新を判断するステップをさらに含むことを特徴とする請求項１３に記載の方法。
15. ファイルプロパティハンドラの登録についてアイテムストアに問い合わせるステップをさらに含むことを特徴とする請求項１３に記載の方法。
16. 前記ファイルプロパティハンドラをキャッシュにロードするステップをさらに含むことを特徴とする請求項１５に記載の方法。
17. 更新すべきフィールドを自動的に識別するステップをさらに含むことを特徴とする請求項１３に記載の方法。
18. アイテムから変更を読み取り、非構造化ファイルプロパティを更新するステップをさらに含むことを特徴とする請求項１３に記載の方法。
19. 前記アイテムの前記ストアへの変更を送信するステップとストリームを閉じるステップの少なくとも一方をさらに含むことを特徴とする請求項１８に記載の方法。
20. 前記１つまたは複数の非構造化プロパティのプロモーションまたは前記１つまたは複数の構造化プロパティのデモーションを容易にするためにファイルプロパティハンドラを登録するステップをさらに含むことを特徴とする請求項１２に記載の方法。
21. 変更アイテムを待ち行列から取り出すステップをさらに含むことを特徴とする請求項１２に記載の方法。
22. 選択されたアイテムパスの構造化アイテムを検索するステップをさらに含むことを特徴とする請求項１２に記載の方法。
23. アイテムの構造のモーフィングを行い、またはアイテムの構造を変更するステップをさらに含むことを特徴とする請求項１２に記載の方法。
24. 自動的に１つまたは複数の非構造化プロパティを抽出し、アイテムを更新するステップをさらに含むことを特徴とする請求項１２に記載の方法。
25. アイテムの修正された部分を、プロモート済みとしてマークするステップをさらに含むことを特徴とする請求項１２に記載の方法。
26. 前記アイテムへの変更を、前記構造化オブジェクトストアに適用するステップをさらに含むことを特徴とする請求項１２に記載の方法。

Images