JP5571544B2 - データ記憶リソース上のクライアント・データを管理するストレージ・マネージャにおけるデータ・フィルタリング方法およびコンピュータ・プログラム - Google Patents

Description

本発明は、ソフトウェア・アプリケーションにデータ記憶サービスを提供するストレージ・マネージャに関する。詳細には、本発明は、ストレージ・マネージャ操作の一部として、暗号化、圧縮、その他のデータ変換などのフィルタリング機能を提供することに関する。

背景として説明すると、ストレージ・マネージャは、ソフトウェア・アプリケーション（バックアップ／リストア・プログラムまたはＷｅｂサーバなど）とデータ記憶リソース（磁気テープ・ドライブ、ディスク・ドライブ、記憶サブシステムなど）との間の仲介として動作するシステムである。ストレージ・マネージャは、アプリケーション・プログラムと統合するかまたはそれとは別に実現することができ、記憶のためのオブジェクトを受け入れ、その後、要求に応じてそのオブジェクトを取り出すインターフェースを提供する。ストレージ・マネージャが使用されたアプリケーションは、データベース・インストール、エンタープライズ・アプリケーション・データ、個別ワークステーション、Ｗｅｂコンテンツなどのバックアップ・イメージの管理を含む。

多くの場合、ストレージ・マネージャは、物理記憶装置に書き込み中またはそこから読み取り中のデータを圧縮または暗号化することにより、そのデータをフィルタリングする必要がある。圧縮または暗号化あるいはその両方のサポートを行う既存のストレージ・マネージャは、２通りの方法の１つでそれを実行する。最も一般的なものとしては、このようなフィルタリングは、ストレージ・マネージャ・プロダクト（product）自体に埋め込まれたアルゴリズムによって提供される。あまり一般的ではないものとしては、このようなフィルタリングは、それ自体のアルゴリズム（複数も可）を作成するオプションをストレージ・マネージャ・ユーザに与えるプログラミング・フック（programming hook）を提供することによってサポートされる。このオプションにより、ユーザは、それ自体でストレージ・マネージャの機能の多くを再実現することも必要になる。

第１の手法の欠点としては以下のものを含む。
●ユーザは、ストレージ・マネージャ・プロダクト内に構築される圧縮アルゴリズムまたは暗号化アルゴリズムあるいはその両方に限定される。
●一部のプロダクトは、暗号化をサポートするが、圧縮をサポートしないか、またはその逆である。
●一部のプロダクトは、弱い暗号化または不十分な圧縮のみをサポートする。
●ストレージ・マネージャ・ベンダは、組み込まれる圧縮アルゴリズムまたは暗号化アルゴリズムあるいはその両方を使用可能にするために顧客に余分に課金する場合がある。
●組み込みアルゴリズムにセキュリティ欠陥または有害なバグがあると判明した場合、顧客は、リスクに曝されることを回避するために直ちに異なる既製のアルゴリズムにスワップインすることができない。
●最新技術がすでに既製のスタンドアロン・プログラム内に存在している可能性がある場合でも、ストレージ・マネージャの顧客は、より良いアルゴリズムが発明されたときにベンダがその最新技術で埋め込みアルゴリズムを更新するのを待たなければならない。
●ベンダは、顧客が要望する特定の圧縮アルゴリズムまたは暗号化アルゴリズムを実現できない場合がある。

第２の手法の欠点としては以下のものを含む。
●ストレージ・マネージャ・プログラミング・フックは、ストレージ・マネージャが本来提供する機能の多くを再実現するために、顧客に対し負担を掛ける。ユーザは、典型的に、記憶のためのオブジェクトを受け入れ、これらのオブジェクトの位置を追跡し、それを物理記憶装置に書き込むかまたはそこから読み取るかあるいはその両方を行い、ストレージ・マネージャがどのような照会プロトコルを必要とする場合でも、その照会プロトコルに基づく要求に応じてそのオブジェクトを取り出すことができるプログラムを作成するとともに、所望の圧縮アルゴリズムまたは暗号化アルゴリズムあるいはその両方を作成しなければならない。この解決策では、ストレージ・マネージャは、本質的に、すべての作業をユーザに委任し、それ自体の機能はまったく提供しない。ストレージ・マネージャは、たいていは、処理のためにすべての記憶および取り出し要求をユーザ作成外部プログラムに転送する中空シェル（hollow shell）または「スタブ（stub）」として動作する。ストレージ・マネージャ自体は単に、それとそれを呼び出すアプリケーションとの間で渡される情報のバッファをアセンブルし、それを逆アセンブルするだけであり、インターフェースＡＰＩ（アプリケーション・プログラミング・インターフェース）用のスタブを提供するが、作業のほとんどをユーザのプログラムに委任する。
●この手法は、圧縮および暗号化をほとんどサポートしない。プログラミング・フックは存在するが、顧客はそれ自身に対し多大な追加の費用および努力を払って必要なサポートを作成する必要がある。
●プログラミング・フックを使用するが、自分の外部プログラムを十分にテストおよびデバッグしない顧客は、自分のデータが自分自身のカスタム・プログラムによって破損されていることまたはダウン・システムを復元するためにそれを必要とする場合などの臨界時にプログラム内のバグが記憶オブジェクトの取り出しを妨げることに気付く可能性がある。
●前の段落に記載したイベントが発生した場合、ストレージ・マネージャ・ベンダは、顧客自身のプログラミング・ミスに関する責任に曝されていることに気付く可能性がある。

したがって、上記の不利点を克服するストレージ・マネージャ・フィルタリング技法が必要である。必要とされているのは、ストレージ・マネージャを再設計したり、その機能をカスタム・プログラムに複写する必要なしに、ストレージ・マネージャ・フィルタを容易に実現することができる解決策である。新しく異なるフィルタを実現する機能を提供することは、さらに望ましいであろう。現在、ストレージ・マネージャ・フィルタリングについて最も一般的な要求は圧縮と暗号化である。しかし、可能性はより広範囲であることが提起され、状況によっては、英国単位とメートル単位との変換あるいはＡＳＣＩＩ（情報交換用米国標準コード）、ＥＢＣＤＩＣ（拡張２進化１０進コード）、およびユニコードのような異なるコード・ページ間または文字セット間の変換など、他のデータ変換を提供することが有利である可能性もある。例として説明すると、この機能は、バックアップ・データが第１の文字フォーマットの第１のシステム（たとえば、ＥＢＣＤＩＣ文字を使用するメインフレーム・コンピュータ）によって生成され、そのデータが第２の文字フォーマットを使用する第２のシステム（たとえば、ＡＳＣＩＩ文字符号化を使用するワークステーション）に復元する必要がある場合に有用になるであるだろう。ストレージ・マネージャ・フィルタリングを使用できるもう１つの分野は監査証跡の生成である。このようなフィルタは、保管中または取り出し中のデータを点検し、管理のために監査情報を生成するために使用できるであろう。

データ記憶リソース上のクライアント・データを管理するストレージ・マネージャが、ストレージ・マネージャに組み込まれておらず、カスタム・プログラミング努力も必要としない多種多様なタイプのデータ・ストリーム・フィルタを利用する能力を有するという方法、システム、およびコンピュータ・プログラム（computer program product）により、上記の問題が解決され、当技術分野の進歩が得られる。ストレージ・マネージャ・ユーザは、ユーザのデータをフィルタリングするためにストレージ・マネージャに使用して欲しいデータ・ストリーム・フィルタを単に識別することにより、容易にフィルタリングを実現することができる。このフィルタは、ストレージ・マネージャの一部ではなく、クライアント・アプリケーションまたはストレージ・マネージャ・ドメイン知識（たとえば、クライアント・アプリケーションまたはストレージ・マネージャによって使用されるプロトコルまたはデータ・タイプの知識）を必要としない既製のプログラムにすることができる。ストレージ・マネージャは、要求されたデータ・ストリーム操作の一部として識別されたフィルタを呼び出し、データ・ストリーム・ソースからデータ・ストリームを受信する。データ・ストリームはフィルタに提供され、そのフィルタがデータ・ストリームをフィルタリングする。フィルタリング後、ストレージ・マネージャは、フィルタからデータ・ストリームを受信し、それをデータ・ストリーム宛先に送信する。

本明細書に開示された模範的な諸実施形態により、ストレージ・マネージャ・トランザクション要求、記憶リソース、アプリケーション、ホスト、ユーザ、記憶オブジェクト・カテゴリなどの属性の１つとして、フィルタ識別コードを受信することができる。フィルタリングの結果、データ・ストリームの変換が行われる場合もあれば、行われない場合もある。フィルタがデータ・ストリームを変換する場合、データ・ストリームに対して変換を実行する書き込みフィルタと、その変換を逆にする場合もあれば、逆にしない場合もある読み取りフィルタとを含むフィルタ対の一部としてフィルタを実現することができる。このような変換は、圧縮／圧縮解除フィルタリング、暗号化／暗号化解除フィルタリング、文字セット変換フィルタリングなどを含むことができる。フィルタがデータ・ストリームを変換しない場合、その代わりに、監査証跡など、データ・ストリームに関する情報を生成するように設計することができる。

フィルタはそれ自体の実行コンテキストで呼び出すことができ、データ・ストリームはプロセス間通信メカニズムを介してフィルタと交換することができる。このメカニズムは第１のパイプと第２のパイプを含むことができ、一方はデータ・ストリームをフィルタに提供するためのものであり、もう一方はフィルタリングされたデータ・ストリームをフィルタから受信するためのものである。フィルタは、そのフィルタが引数を処理するように適合されている場合に渡され、そうではない場合に抑制されるフィルタ引数によって呼び出すことができる。例として説明すると、フィルタは暗号化フィルタまたは暗号化解除フィルタにすることができ、フィルタ引数は暗号鍵の識別に関係する可能性がある。

他の一態様では、ストレージ・マネージャは、リモート・クライアントに代わる１つのサービスとしてデータ・ストリーム・フィルタリングによりデータ記憶リソース上のクライアント・データを管理するように適合される。フィルタリングを実現するために、ストレージ・マネージャは、リモート・クライアントまたは信頼された権限などのリモート・クライアントによって指定された位置から、クライアント選択フィルタのコピーまたはこのようなフィルタの識別コードを受信する。

さらに他の一態様では、ストレージ・マネージャは、必ずしもデータ・ストリーム・フィルタではないプラグインを利用するように適合される。このようなプラグインは、それが真のデータ・ストリーム・フィルタにならないように、クライアント・アプリケーション・データ・フォーマットまたはストレージ・マネージャのドメイン知識を有するカスタム・プログラムにすることができる。

本発明の上記その他の特徴および利点は、添付図面に例示される本発明の模範的な諸実施形態について以下に示すより詳細な説明から明らかになるであろう。

模範的なストレージ・マネージャ、クライアント・アプリケーション、およびデータ記憶リソースを示す機能ブロック図である。 図１に示されているコンポーネントについて可能な１つの実現例を示す機能ブロック図である。 図１のストレージ・マネージャの模範的な詳細を示す機能ブロック図である。 図３のストレージ・マネージャとフィルタとの間のプロセス間通信のための模範的なメカニズムを示す機能ブロック図である。 データ・ストリーム・フィルタリングを実行するために図１のストレージ・マネージャによって実現可能な模範的な諸ステップを示す流れ図である。 読み取りフィルタと書き込みフィルタの対と組み合わせて、図１のストレージ・マネージャを示す機能ブロック図である。 フィルタを呼び出すためにストレージ・マネージャ親プロセスによって実現可能な模範的な諸ステップを示す流れ図である。 ストレージ・マネージャ親プロセスによって作成されたフィルタ・クライアント・プロセスによって実現可能な模範的な諸ステップを示す流れ図である。 リモート・ストレージ・マネージャ・サービス環境における図１のストレージ・マネージャの模範的な実現例を示す機能ブロック図である。 図１のストレージ・マネージャのソフトウェア・バージョンを実現するためのシステムを提供するために使用可能な模範的なデータ処理ハードウェアを示す機能ブロック図である。 図１のストレージ・マネージャのコンピュータ・プログラム実現例で使用可能な模範的な記憶媒体の図表現である。

次に図面を参照すると、同様の参照番号は複数の図面のすべてにおいて同様の要素を示し、図１は、クライアント・アプリケーション４によって生成されたデータを保管し取り出すストレージ・マネージャ２を例示している。データ記憶モードでは、ストレージ・マネージャ２は、アプリケーション４からデータ・オブジェクトのストリーム（データ・ストリーム）を受信し、典型的には（必ずではないが）アーカイブ目的で、そのオブジェクトをデータ記憶リソース６に保管する。データ取り出しモードでは、ストレージ・マネージャ２は、前に保管したオブジェクトをデータ記憶リソース６から取り出し、それをアプリケーション４に返す。ストレージ・マネージャ・ロジックは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせで実現することができる。アプリケーション４は、そのデータがデータ記憶リソース６に置かれることを希望する任意のソフトウェア・アプリケーションを表すことができる。データ記憶リソース６は、１つまたは複数の磁気テープ・ドライブ、ディスク・ドライブ、記憶サブシステムなどを含む、任意の物理記憶装置またはシステムとして実現することができる。

次に図２を参照すると、本発明の範囲を制限せずに、データベース・システム８は、図１のコンポーネントを使用のために適合可能な１つの可能な環境を表している。システム８では、ストレージ・マネージャ２は磁気テープおよびディスク・ストレージ・マネージャ１０によって例示され、アプリケーション４はデータベース・バックアップ／リストア・システム１２によって例示され、データ記憶リソース６は磁気テープ・ドライブ・システム（図示せず）で動作可能な１組の磁気テープ記憶ボリューム１４と、ディスク記憶ボリューム１５によって例示される。バックアップ／リストア・システム１２は、その記憶空間および論理ログ１８を定期的にバックアップしリストアする必要があるデータベース・サーバ１６に代わってデータ・バックアップおよびリストア・サービスを提供する。例としてのみ説明すると、バックアップ／リストア・システム１２は、ＩＢＭ（Ｒ）Ｉｎｆｏｒｍｉｘ（Ｒ）ＯＮバー・バックアップおよびリストア・システムなどのプロダクト（product）を使用して、図２の環境で実現できるであろう。このプロダクトは、データベース・サーバ１６を実現するために使用可能なＩＢＭ（Ｒ）Ｉｎｆｏｒｍｉｘ（Ｒ）ダイナミック・サーバ（ＩＤＳ）などのデータベース・サーバに磁気テープおよびディスク・バックアップおよびリストア・サービスを提供する。データベース・サーバ１６は、Ｉｎｆｏｒｍｉｘ（Ｒ）プロダクトの一部であるアーカイブＡＰＩ（アプリケーション・プログラミング・インターフェース）を介してバックアップおよびリストア要求をバックアップ／リストア・システム１２に伝達することができる。これらの要求に応答して、バックアップ／リストア・システム１２は、ＸＢＳＡ（Ｘ／オープン・バックアップ・サービスＡＰＩ）などのプロトコルを介して記憶および取り出し操作を実現するためにストレージ・マネージャ１０を呼び出すであろう。ストレージ・マネージャ１０は、ＩＢＭ（Ｒ）Ｉｎｆｏｒｍｉｘ（Ｒ）ストレージ・マネージャ（ＩＳＭ）などのプロダクトを使用して（本明細書に記載したフィルタリングをサポートするための適切な変更とともに）実現することができる。ストレージ・マネージャ１０は、磁気テープ記憶ボリューム１４およびディスク記憶ボリューム１５を管理する。また、ストレージ・マネージャ１０は、保管されたデータ・オブジェクトと、対応する磁気テープ記憶ボリューム１４およびディスク記憶ボリューム１５を相関させるバックアップおよびリストア操作のカタログ２０をディスク記憶ボリューム１５内に維持する。ストレージ・マネージャ１０の諸機能としては、実際の磁気テープおよびディスク上のデータの書き込みおよび読み取り、どのデータがどの磁気テープまたはディスク上にあるかの追跡、カテゴリへのデータの割り当てがある。

データ・バックアップ操作は、データベース・サーバ１６の管理者がバックアップ／リストア・システム１２にバックアップ要求を発行することによって開始することができる。バックアップ／リストア・システム１２は、どのデータをバックアップする必要があるかを判断し、ストレージ・マネージャ１０に接続する。次にバックアップ／リストア・システム１２は、記憶空間および論理ログ１８から適切なデータを取り出し、バックアップ・オブジェクトのリストを構築し、それをストレージ・マネージャ１０に渡す。ストレージ・マネージャ１０は、データ・オブジェクト・リストから保存セットを作成し、その保存セット（１つまたは複数のデータ・オブジェクトを含む）を適切な磁気テープ記憶ボリューム１４またはディスク記憶ボリューム１５あるいはその両方に書き込む。次にストレージ・マネージャ１０は、保存セットおよび記憶ボリュームのレコードをカタログ２０に入力する。ストレージ・マネージャ１０は、カタログ２０を使用して、保存セットと、それらがバックアップされるボリュームを追跡する。

データ・リストア操作は、データベース・サーバ１６の管理者がバックアップ／リストア・システム１２にリストア要求を発行することによって開始することができる。バックアップ／リストア・システム１２は、どのデータをリストアする必要があるかを判断し、ストレージ・マネージャ１０に接続する。ストレージ・マネージャ１０は、バックアップ／リストア・システム１２によって要求された特定のリストア・オブジェクトを求めてカタログ２０をサーチし、保存セット内のそのオフセットにそれぞれのリストア・オブジェクトをマッピングする。次にバックアップ／リストア・システム１２は、ストレージ・マネージャからそのデータを取り出し、それをオブジェクトごとにデータベース・サーバ１６に渡す。データベース・サーバ１６は、そのデータを記憶空間および論理ログ１８内の適切な位置（複数も可）に書き込む。

背景として上述したように、データ記憶リソースに保管中またはそこから取り出し中のデータをストレージ・マネージャがフィルタリングすることが望ましい場合がある。従来のストレージ・マネージャは、圧縮／圧縮解除および暗号化／暗号化解除など、限られたフィルタリング・オプションを提供する。同じく前述したように、このようなフィルタはストレージ・マネージャ・ロジックに埋め込まれていて変更または更新が難しいか、あるいはプログラミング・フックを使用してこのようなフィルタを作成し実現するには複雑なプログラミング努力が必要である。ストレージ・マネージャ２は、データ記憶リソース６に書き込み中またはそこから読み取り中のデータに適用可能な既製の圧縮、暗号化、またはその他のデータ変換プログラムを、ユーザが容易にかつ率直にプラグインできるメカニズムを提供することにより、この状況に改良を加えるものである。

図３は、この機能を実現するために使用可能なストレージ・マネージャ２の模範的な実現例を例示している。図示の通り、ストレージ・マネージャ２は、フィルタ３２₁、３２₂、・・・３２_nのグループから指定可能なフィルタ３２を呼び出す役割を担うフィルタ呼び出しサブシステム３０を実現する。これらのフィルタはストレージ・マネージャ２の一部ではない。その代わりに、これらのフィルタは、典型的に（個別の実行コンテキスト内にもかかわらず）ストレージ・マネージャも実現することになる、データ処理システムに常駐するスタンドアロン・プログラム（またはライブラリ）である。代わって、ストレージ・マネージャ２およびフィルタ３２は、別々のシステム上で実行することができる。フィルタ識別インターフェース３４は、要求されたデータ・ストリーム操作の一部として使用すべきフィルタ３２をユーザが指定できるようにするものである。インターフェース３４は、ストレージ・マネージャのユーザまたは管理者によって操作されるコマンド行またはグラフィカル・ユーザ・インターフェースなどを介して、ストレージ・マネージャ２へのローカルまたはリモート・アクセスをサポートするように実現することができる。記憶ファイル、メモリなどのフィルタ識別ストア３６は、ストレージ・マネージャ２にフィルタ識別コードを保持するために使用することができる。以下に詳述するように、これは、記憶リソース６（図１を参照）、アプリケーション、ホスト、ユーザ、またはデータ・オブジェクト・カテゴリの属性などのオブジェクト属性としてフィルタ３２を識別する能力をサポートする。このようなオブジェクトに関するその他の属性はストレージ・マネージャ２によって従来通り維持されるので（たとえば、データ・リソース属性）、フィルタ属性の追加は容易に実現することができる。このようにして、異なるフィルタ３２を異なる記憶リソース６（図１を参照）、アプリケーション、ホスト、ユーザ、または記憶オブジェクト・カテゴリに関連付けることができる。この機能がない場合、ユーザまたはアプリケーションは、各データ・ストリーム・コマンドのパラメータとしてフィルタを識別しなければならないであろう。

データ・ストレージ・マネージャ２は、データ・ストリーム・レシーバ３８とデータ・ストリーム・センダ４０、ならびにフィルタ・ライタ４２とフィルタ・リーダ４４をさらに含む。第１の従来の通信インターフェース４６はアプリケーション４（図１を参照）と通信する（たとえば、ＸＢＳＡプロトコルを実現する）ために提供され、第２の従来の通信インターフェース４８はデータ記憶リソース６（図１を参照）と通信する（たとえば、記憶装置固有プロトコルを実現する）ために提供される。

データ・ストリーム・レシーバ３８、データ・ストリーム・センダ４０、フィルタ・ライタ４２、およびフィルタ・リーダ４４の配置は、フィルタ３２に対するデータ・ストリーム・ライタとデータ・ストリーム・リーダとの関係のように、図４に示されている。次に、上記のコンポーネントのアクションを含む、ストレージ・マネージャ２の動作について、図５の流れ図にさらに関連して説明する。図５のステップ５０に示されているように、フィルタ３２を利用するストレージ・マネージャ２の能力は、ユーザがフィルタ識別インターフェース３４を介してストレージ・マネージャに対してフィルタを識別することから始まる。図５のステップ５２では、ストレージ・マネージャ２はフィルタ識別コードをフィルタ識別ストア３６に保管する。フィルタ識別の後またはフィルタ識別と同時に、ストレージ・マネージャ２は、バックアップまたはリストアなどのデータ・ストリーム操作を実行するよう要求されることになる。図５のステップ５４では、フィルタ呼び出しサブシステム３０はフィルタ識別ストア３６を調べ、そこに識別されているフィルタ３２を呼び出す。図５のステップ５６では、データ・ストリーム・レシーバ３８はデータ・ストリーム・ソースからデータ・ストリームを受信する。一部の操作（たとえば、データ・バックアップ）の場合、データ・ストリーム・ソースはアプリケーション４（図１を参照）になる。他の操作（たとえば、データ・リストア）の場合、データ・ストリーム・ソースはデータ記憶リソース６（図１を参照）になる。図５のステップ５８では、データ・ストリーム・レシーバ３８は着信データ・ストリームをフィルタ・ライタ４２に渡す。フィルタ・ライタ４２の機能は、フィルタリングのために識別されたフィルタ３２にデータ・ストリームを提供することである。フィルタ３２は個別の実行コンテキストで（または個別システム上で）実行されるので、フィルタ・ライタ４２は、フィルタと通信するために、パイプＰ１およびＰ２の対（図４を参照）などの適切なプロセス間通信（ＩＰＣ）メカニズムを使用することになる。ソケット（たとえば、フィルタ３２が個別のデータ処理システム上で実行される場合）などの他のＩＰＣメカニズムも使用できるであろう。図５のステップ６０では、フィルタ・リーダ４４は、フィルタリングを実行したフィルタ３２からフィルタリングされたデータ・ストリームを受信する。フィルタ・リーダ４４は、図５のステップ６２でフィルタリングされたデータ・ストリームをデータ・ストリーム・センダ４０に渡し、データ・ストリーム・センダ４０はデータ・ストリームをデータ・ストリーム宛先に送信する。一部の操作（たとえば、データ・バックアップ）の場合、データ・ストリーム宛先はデータ記憶リソース６（図１を参照）になる。他の操作（たとえば、データ・リストア）の場合、データ・ストリーム宛先はアプリケーション４（図１を参照）になる。

多くの場合、フィルタ３２を含むフィルタ・プログラムは、ストレージ・マネージャ２またはアプリケーション４によって使用されるプロトコルまたはデータ・タイプに対する意識（以下「ドメイン知識」という）を必要としないが、ｓｔｄｉｎ（標準入力）からの読み取りおよびｓｔｄｏｕｔ（標準出力）への書き込みのみを必要とする。このようなプログラムは、ＵＮＩＸオペレーティング・システムの出現以来周知のものになっている「フィルタ」の標準定義により生のデータ・ストリームを処理できる、真の「フィルタ」である。ＵＮＩＸの「ｃｏｍｐｒｅｓｓ」および「ｕｎｃｏｍｐｒｅｓｓ」プログラムは、このタイプの操作をサポートする既製のプログラムの多くの例のうちの２つに過ぎない。ユーザは、暗号化および暗号化解除、異なる文字セットまたはコード・ページ間の変換、英国単位とメートル単位との変換など、他の所望のデータ変換を実現するフィルタ３２を指定することもできる。監査などのタスクを実行するフィルタ３２など、非データ変換フィルタ３２も指定できるであろう。たとえば、このようなフィルタは、ユーザおよびユーザがアクセスしたデータを後で識別できるようにする個別ログに、ユーザのデータの一部および現行ユーザ名をコピーすることができるであろう。代わって、このようなフィルタは、ストレージ・マネージャ２によって処理中のデータ・ストリームを点検し、トランザクションに関するログ情報を作成できるであろう。多くのフィルタ・プログラムは既製のソフトウェアになるが、カスタム・フィルタ・プログラムを作成することもできる。このようなフィルタ・プログラムはＵＮＩＸの意味で真のデータ・ストリーム・フィルタになる可能性があるか、ストレージ・マネージャのプロトコルあるいはアプリケーションのデータ・タイプまたはフォーマットのドメイン知識を必要とするプラグインの性質の点ではそれ以上のものになる可能性があり、単なる入力ストリーム以外の引数を受け入れるかまたは必要とする場合もある。たとえば、一部のフィルタ・プログラムは引数によって呼び出すことができる。このような引数の１つは、保管中または取り出し中のオブジェクトの固有のＩＤ（オブジェクトＩＤ）になるであろう。フィルタ・プログラムは、この引数を無視することを選択する可能性もあれば、適合すると見なした引数を使用する可能性もある。顧客は、複数の鍵でデータを暗号化することを要求するポリシーを持っている可能性があるので、この機能は暗号化フィルタには有用なものになるであろう。このような場合、オブジェクトＩＤを使用して、問題のオブジェクトを暗号化（書き込みフィルタ）または暗号化解除（読み取りフィルタ）するための鍵を選択することができる。たとえば、モジュロｎの演算を使用して、ｎ通りの鍵から選択することができるであろう（key_id = object_id MOD n）。すべての暗号化フィルタ・プログラムが鍵選択のために必ずしもこのような引数を必要とするわけではないことに留意されたい。たとえば、暗号化フィルタは、それが必ず使用する単一鍵をハードコード化する可能性がある（しかし、これにより、そのフィルタ自体の保護が一般的な暗号鍵の保護と同じ程度に重要なものになる）。

データ変換に使用可能な２つのタイプのフィルタ・プログラムは、書き込みフィルタと読み取りフィルタである。書き込みフィルタは、ストレージ・マネージャ２がデータ記憶リソース６に書き込むデータに適用される。ユーザが書き込みを要求したデータは入力として書き込みフィルタに渡され、その後、書き込みフィルタの出力は物理記憶域に書き込まれる。読み取りフィルタは、ストレージ・マネージャ２がデータ記憶リソース６から読み取るデータに適用される。データは物理記憶域から読み取られ、入力として読み取りフィルタに渡され、その後、読み取りフィルタの出力はこのデータの取り出しを要求したユーザに返される。

望ましい場合、ある方向にデータを変換する書き込みフィルタ（たとえば、ＵＮＩＸの「ｃｏｍｐｒｅｓｓ」）と、元の変換を逆にする読み取りフィルタ（たとえば、ＵＮＩＸの「ｕｎｃｏｍｐｒｅｓｓ」）という２つのフィルタ３２を対として定義することができる。このようなフィルタ対の一例は図６に示されているが、同図は読み取りフィルタ３２_Rと対になっている書き込みフィルタ３２_Wを例示している。変更せずにデータを通過させるだけのフィルタ３２も定義できることに留意されたい。したがって、ＥＢＣＤＩＣデータをＡＳＣＩＩに変換する書き込みフィルタと、変換をまったく行わない読み取りフィルタとを対にすることも可能であるだろう。この結果、ＥＢＣＤＩＣのソース・データがＡＳＣＩＩで保管され、その後、変換でＥＢＣＤＩＣに戻されるのではなく、ＡＳＣＩＩで取り出されることになるであろう。

上述の通り、ストレージ・マネージャ２の一実現例では、（たとえば、データ記憶リソース６の一部を表す）物理記憶装置の属性としてフィルタ３２を定義することもできる。多くのストレージ・マネージャでは、データを保管し取り出すために使用する前に物理記憶装置の属性を記述しなければならないので、これは都合の良いものである。このような属性としては、（１）装置へのパス、（２）それがディスク装置であるか磁気テープ装置であるか、（３）装置内に保管する最大バイト数を含むことができる。ストレージ・マネージャ２は、２通りの新しい装置属性、すなわち、読み取りフィルタと書き込みフィルタを実現することができる。これらの属性は、以下のように、装置定義コマンド上のフラグとして指定することができる。

このステートメントは、ストレージ・マネージャ１０に対して物理記憶装置を定義するために使用することができ、装置およびその様々な属性を識別し、この装置に使用するための読み取りフィルタ・プログラムへのパスが続く−Ｆｒフラグと、書き込みフィルタ・プログラムへのパスが続く−Ｆｗフラグとを含む。このステートメントは、ストレージ・マネージャを意味するための識別子「ｓｍ」から始まる。「ｐ」フラグは記憶装置パス指定を意味する。「/disk1/ids/logbu」フィールドは記憶装置への実際のパスを識別する。「-tDISK」属性は、装置タイプがディスクであることを意味する。「-s 1000M」属性は装置のサイズを識別する。例としてのみ説明すると、−Ｆｒフラグによって識別された読み取りフィルタ・プログラムはＵＮＩＸの「ｕｎｃｏｍｐｒｅｓｓ」プログラムであると示されており、−Ｆｗフラグによって識別された書き込みフィルタ・プログラムはＵＮＩＸの「ｃｏｍｐｒｅｓｓ」プログラムであると示されている。どちらのプログラムも通常は、ＵＮＩＸファイル・システムの/usr/binディレクトリ内に位置する。ストレージ・マネージャ２は、上記のコマンドを受信すると、その装置属性を装置属性ファイルまたはメモリあるいはその両方に保管することができる。このファイルまたはメモリのうち、読み取りおよび書き込みフィルタ属性を保持する部分は、図３のフィルタ識別ストア３６を表すことができる。したがって、ストレージ・マネージャ操作中にフィルタ呼び出しサブシステム３０がフィルタ識別ストア３６を調べ、データ記憶リソース６の特定の物理装置に書き込み中またはそこから読み取り中のデータにどのフィルタ（複数も可）が適用されるかを判断することができる。

上述の通り、フィルタ指定は物理装置レベルに限定されない。また、仮想デバイス・レベル、アプリケーション・レベル、ホスト・レベルなど、種々の細分性で指定することもできるであろう。フィルタ３２は、ログ・ファイル、データ・ファイルなど、種々のカテゴリの記憶オブジェクトについて指定することもできる。同様に、フィルタ３２は、種々のユーザまたはグループについて、あるいは任意の他のカテゴリ化方式に応じて、指定することができる。代わって、望ましい場合、フィルタ３２は、ストレージ・マネージャ２がアプリケーション４によって呼び出されるたびに、データ保管または取り出しコマンドのパラメータとして指定できるであろう。

ストレージ・マネージャ２が、暗号化／暗号化回路フィルタに対し、暗号鍵を決定するための「-id <object_id>」引数などのフィルタ引数を渡すように設計される場合、この機能をサポートするフィルタ３２を処理するための技法が必要になる可能性がある。理想的には、フィルタ３２は、この引数を使用するかまたは無視することができるであろう。しかし、多くの既製のフィルタは、ｓｔｄｉｎから読み取り、ｓｔｄｏｕｔに書き込むことが必要であり、その引数を認識しないという苦情を示す可能性がある。この問題を解決するための方法の１つは、この引数を処理するために既製のフィルタ・コンポーネントの周りに非常に小さいラッパ・スクリプトを作成することである。たとえば、データ・オブジェクトＩＤに基づく鍵選択を実現するために、暗号化フィルタについてこれを実行できるであろう。ＵＮＩＸの「ｃｏｍｐｒｅｓｓ」および「ｕｎｃｏｍｐｒｅｓｓ」プログラムなどの他の既製のフィルタ・プログラムの場合、引数を無視し、単にデータをプログラムに渡すだけのラッパを作成することができる。このようなラッパ・スクリプトは、ストレージ・マネージャに対し、対応する既製のフィルタ・プログラムを直接定義するのではなく、ストレージ・マネージャ２に対しフィルタ３２として定義され、実行可能なものになるであろう。

以下の例では、ｍｙＣｏｍｐｒｅｓｓ（ＵＮＩＸのｃｏｍｐｒｅｓｓをラップする）とｍｙＵｎｃｏｍｐｒｅｓｓ（ＵＮＩＸのｕｎｃｏｍｐｒｅｓｓをラップする）という１対の２行ラッパ・スクリプトにより、ストレージ・マネージャ２が渡すことができる引数を認識しない場合でも、ＵＮＩＸコマンドをフィルタ３２として使用することができる。これらのラッパは、引数を渡さずにＵＮＩＸフィルタ・プログラムを呼び出すだけである。

上記のラッパは、以下のように記憶装置フィルタ構成で使用できるであろう（ｍｙＣｏｍｐｒｅｓｓとｍｙＵｎｃｏｍｐｒｅｓｓが/usr/local/binにインストールされていると想定する）。

フィルタ引数を処理しないフィルタ・プログラムを処理するためのもう１つの手法は、フィルタ呼び出しサブシステム３０に対し、任意の引数をフィルタに渡すべきかどうかを示すフィルタを定義することになるであろう。所与のフィルタ定義について使用不可である場合、フィルタ呼び出しサブシステム３０は、どの引数もフィルタ３２に渡さず、それにより、いずれのラッパ・スクリプトもなしに使用すべき余分な引数（ｃｏｍｐｒｅｓｓ−ｕｎｃｏｍｐｒｅｓｓの対など）を認識しないかまたは必要としない純粋な既製のフィルタを使用可能にするであろう。一例を以下に示す。

この場合、-Fr_noargフラグは、これがどの引数も渡されない読み取りフィルタであることを示し、-Fw_noargフラグは、これがどの引数も渡されない書き込みフィルタであることを示す。次に、いかなるラッパも必要とせずに、既製のＵＮＩＸ「ｃｏｍｐｒｅｓｓ」および「ｕｎｃｏｍｐｒｅｓｓ」コマンドが指定される。引数をフィルタに渡すべきかどうかを示すために、依然として上述の元の-Frおよび-Fwフラグをサポートできることに留意されたい。

もう１つの手法は任意の引数列を各フィルタ３２に渡すことをサポートする。一例を以下に示す。

この場合、-Fr フラグは読み取りフィルタを示し、-Fr_argフラグは、それが呼び出された場合に読み取りフィルタに渡すべき引数列を提供する。-Fwフラグは書き込みフィルタを示し、-Fw_argフラグは、それが呼び出された場合に書き込みフィルタに渡すべき引数列を提供する。

外部フィルタを呼び出すためにフィルタ呼び出しサブシステム３０が使用可能な実現メカニズムとしては様々なものがある。次に、子プロセスを作成し、その入力ストリームおよび出力ストリームをリダイレクトするためにＵＮＩＸオペレーティング・システム機能を利用する一例について説明する。この例は本発明の範囲（または特許請求の範囲）を任意の特定の実現例に限定するためのものではなく、単にストレージ・マネージャ２を設計できる方法の１つを例示するためのものであることを理解されたい。また、この例は、本発明の範囲（または特許請求の範囲）をＵＮＩＸオペレーティング・システムに限定するためのものでもない。他のオペレーティング・システムは、子プロセスまたはスレッドを作成し、その入力ストリームおよび出力ストリームをリダイレクトするための同様の機能を有する。たとえば、Ｌｉｎｕｘは、以下に示す模範的な実現例も使用できるＵＮＩＸのフレーバ（flavor）である。移植（porting）すれば、同じ手法をＷｉｎｄｏｗｓオペレーティング・システム環境などで使用できるであろう。

模範的な実現例により、物理記憶域に書き込むためのデータを有するストレージ・マネージャ２のＵＮＩＸバージョン内のプロセスは、以下のように、まずそれを書き込みフィルタを通過させることができる。
●ｉｎ＿ｐｉｐｅおよびｏｕｔ＿ｐｉｐｅ（たとえば、図４のパイプＰ１およびＰ２）という２つのパイプを作成する。
●子フィルタを実行するために子プロセスをフォークする。
●アプリケーション４からデータを受信する。
●ｉｎ＿ｐｉｐｅ（Ｐ１）の入力端にデータを書き込む。
●ｏｕｔ＿ｐｉｐｅ（Ｐ２）の出力端からフィルタリング結果を読み取る。
●データ記憶リソース６にフィルタリング結果を書き込む。

子プロセスは、以下のように、フィルタならびにサービスｉｎ＿ｐｉｐｅおよびｏｕｔ＿ｐｉｐｅを実行する。
●ｓｔｄｉｎを閉じ、それをｉｎ＿ｐｉｐｅ（Ｐ１）の出力端で置き換える。
●ｓｔｄｏｕｔを閉じ、それをｏｕｔ＿ｐｉｐｅ（Ｐ２）の入力端で置き換える。
●（ＵＮＩＸでは、ｅｘｅｃｖｐ（）などを使用して）フィルタ・コマンドを実行する。
●ファイルの終わりに達したときに終了する（入力ストリームの終わり）。

上記の実現例では、親ストレージ・マネージャ・プロセスがｉｎ＿ｐｉｐｅ（Ｐ１）の入力端に未処理データを書き込み、これを子フィルタ・プロセスはｉｎ＿ｐｉｐｅの出力端から読み取る（フィルタは必ずｓｔｄｉｎから読み取るからであり、子はｉｎ＿ｐｉｐｅの出力端になるようにこれをリダイレクトしている）。子フィルタ・プロセスはｏｕｔ＿ｐｉｐｅ（Ｐ２）の入力端に処理結果を書き込む（フィルタは必ずｓｔｄｏｕｔに書き込むからであり、子はｏｕｔ＿ｐｉｐｅの入力端になるようにこれをリダイレクトしている）。最後に、親ストレージ・マネージャ・プロセスは、ｏｕｔ＿ｐｉｐｅの出力端から処理済みデータを取り出し、それを物理記憶域に書き込む。

読み取り処理は、逆のやり方で実行することができる。したがって、物理記憶域からデータを読み取らなければならないストレージ・マネージャ２のＵＮＩＸバージョン内のプロセスは、以下のように、まずそれを読み取りフィルタを通過させることができる。
●ｉｎ＿ｐｉｐｅおよびｏｕｔ＿ｐｉｐｅ（たとえば、図４のパイプＰ１およびＰ２）という２つのパイプを作成する。
●子フィルタを実行するために子プロセスをフォークする。
●データ記憶リソース６からデータを読み取る。
●ｉｎ＿ｐｉｐｅ（Ｐ１）の入力端にデータを書き込む。
●ｏｕｔ＿ｐｉｐｅ（Ｐ２）の出力端からフィルタリング結果を読み取る。
●アプリケーション４にフィルタリングされたデータを渡す。

子プロセスは、以下のように、フィルタならびにサービスｉｎ＿ｐｉｐｅおよびｏｕｔ＿ｐｉｐｅを実行する。
●ｓｔｄｉｎを閉じ、それをｉｎ＿ｐｉｐｅ（Ｐ１）の出力端で置き換える。
●ｓｔｄｏｕｔを閉じ、それをｏｕｔ＿ｐｉｐｅ（Ｐ２）の入力端で置き換える。
●（ＵＮＩＸでは、ｅｘｅｃｖｐ（）などを使用して）フィルタ・コマンドを実行する。
●ファイルの終わりに達したときに終了する（入力ストリームの終わり）。

上記の実現例では、親ストレージ・マネージャ・プロセスが物理記憶域から未処理データを読み取り、それをｉｎ＿ｐｉｐｅ（Ｐ１）の入力端に書き込み、これを子フィルタ・プロセスはｉｎ＿ｐｉｐｅの出力端から読み取る（フィルタは必ずｓｔｄｉｎから読み取るからであり、子はｉｎ＿ｐｉｐｅの出力端になるようにこれをリダイレクトしている）。子フィルタ・プロセスはｏｕｔ＿ｐｉｐｅ（Ｐ２）の入力端に処理結果を書き込む（フィルタは必ずｓｔｄｏｕｔに書き込むからであり、子はｏｕｔ＿ｐｉｐｅの入力端になるようにこれをリダイレクトしている）。最後に、親ストレージ・マネージャ・プロセスは、ｏｕｔ＿ｐｉｐｅの出力端から処理済みデータを取り出す。

図７および図８は、上記のアクションが実行されるときのストレージ・マネージャ親プロセスおよび子フィルタ・プロセスの動作をそれぞれ表す流れ図である。図７のステップ７０は、親プロセスがｉｎ＿ｐｉｐｅ（Ｐ１）およびｏｕｔ＿ｐｉｐｅ（Ｐ２）を作成することを表している。図７のステップ７２は、親プロセスが子フィルタを実行するために子プロセスをフォークすることを表している。図７のステップ７４は、親プロセスがｉｎ＿ｐｉｐｅの入力端にデータを書き込むことを表している。図７のステップ７６は、親プロセスがｏｕｔ＿ｐｉｐｅの出力端からデータを読み取ることを表している。図８のステップ７８は、子プロセスがｓｔｄｉｎを閉じ、それをｉｎ＿ｐｉｐｅ（Ｐ１）の出力端で置き換えることを表している。図８のステップ８０は、子プロセスがｓｔｄｏｕｔを閉じ、それをｏｕｔ＿ｐｉｐｅ（Ｐ２）の入力端で置き換えることを表している。図８のステップ８２は、子プロセスがフィルタ・コマンドを実行することを表している。図８のステップ８４は、入力ストリームの終わりに達したときに子プロセスが終了することを表している。

次に図９を参照すると、ネットワーク９４を介してリモート・クライアント９２に代わってストレージ・マネージャ・サービスを提供するためにストレージ・マネージャがサーバ・サイト９０で動作する、ストレージ・マネージャ２の他の模範的な実現例が示されている。アプリケーション４およびデータ記憶リソース６は、サーバ・サイト９０に位置することもできる。代わって、これらのコンポーネントは、他の場所の構外に位置することもできるであろう。クライアント９２は、（たとえば、フィルタ受信インターフェース９７を介して）クライアントのデータをフィルタリングする際に使用するためにそれがストレージ・マネージャ２に提供するフィルタ９６を維持できるであろう。したがって、ストレージ・マネージャ２は、サーバ・サイト９０でローカルにフィルタ９６のコピーを実現することになるであろう。代わって、望ましい場合、クライアント９２は、フィルタ９６の唯一のコピーを維持し、（たとえば、フィルタ識別インターフェース３４を介して）それをストレージ・マネージャ２に対して識別するだけであろう。その場合、ストレージ・マネージャ２は、リモート・プロシージャ・コールを使用してフィルタ９６を呼び出し、好ましくはセキュア接続（たとえば、ＳＳＬ（セキュア・ソケット・レイヤ））を使用して、ネットワーク９４を越えてフィルタにデータを渡すことができるであろう。信頼できないサード・パーティ・フィルタの使用を禁止するポリシーをサーバ・サイト９０が持っている場合、クライアント９２は、信頼できるフィルタ権限によって維持されたリポジトリ９８に常駐するフィルタを（ストレージ・マネージャ２に対して）指定できるであろう。

したがって、ストレージ・マネージャにより、データ・ストリームを処理するためのフィルタを実現できる技法が開示されている。開示された技法は、以下のものを含み、従来のストレージ・マネージャでは見られないいくつかの利点を提供することが認識されるであろう。
●ユーザは、ストレージ・マネージャ・ベンダによって提供される圧縮、暗号化、またはその他のフィルタに限定されない。
●ユーザは、組み込まれた圧縮アルゴリズムまたは暗号化アルゴリズムあるいはその両方を使用可能にするために余分な料金をストレージ・マネージャ・ベンダに支払う必要がない。
●ユーザは、ストレージ・マネージャ・ベンダがパッチ・リリースを発行するのを待つ必要なしに、セキュリティ欠陥または有害なバグがあると判明したフィルタから迅速にスワップアウトし、同様の機能を提供する他の既製のコンポーネントにスワップインすることができる。
●ユーザは、ストレージ・マネージャ・ベンダからの次のリリースを待たずに、最新のフィルタリング技術にアップグレードすることができる。
●ユーザは、自分自身の長いプログラムを作成したり、フィルタを使用していない場合にストレージ・マネージャが提供する機能を再実現する必要がない。
●この手法は、顧客にとって、プログラミング・フックよりかなり安全である。というのは、顧客は自分自身で大きい記憶管理ソフトウェアを作成する必要がないからであり、これは、生産に展開される前にソフトウェアが適切にテストされデバッグされることを保証するために所定の位置にプロセスを備えていない可能性がある。
●プログラミング・フック手法を実現するストレージ・マネージャ・ベンダの潜在的な責任を回避することができる。
●顧客は、フィルタが総称的にプラグ可能であるために、より創造的になることができ、これにより監査証跡生成など、単なる圧縮または暗号化あるいはその両方以上に多くの問題を解決できることに気付く可能性がある。

上記の概念は、必要な機能を実行するようデータ処理システムを制御する際に使用するために１つまたは複数の機械使用可能媒体によってプログラミング・ロジックが提供される、データ処理システム、機械で実現される方法、コンピュータ・プログラムのいずれかで様々に実施可能であることが認識されるであろう。データ処理システムおよび機械で実現される方法に関して説明すると、図１０は、ストレージ・マネージャ２がソフトウェアとして実現された場合に使用可能な模範的なハードウェア環境１００を例示している。ハードウェア環境１００は、データ処理コアを提供するＣＰＵまたはその他のデータ処理リソース１０２およびメイン・メモリ１０４と、表示モニタ１０７に視覚出力情報を生成するためのグラフィックス・カード１０６と、周辺記憶装置１０８と、その他の周辺装置１１０と、上記の諸要素を相互接続するバス・インフラストラクチャ１１２とを含む。ストレージ・マネージャ２は、メイン・メモリ１０４にロードすることができる。アプリケーション４（図１を参照）も、同じハードウェア・プラットフォーム上で実行される場合、メモリ１０４にロードすることができるであろう。記憶装置１０８は、フィルタ識別ストア３６用の持続記憶域として使用することができる。フィルタ情報のコピーもメモリ１０４に維持できるであろう。その他のデータ・ソースは、周辺装置１１０によって提供されるＩ／Ｏ（入出力）リソースを介してアクセスすることができ、その周辺装置は、ＵＳＢバス・コントローラ、ＳＣＳＩディスク・コントローラ、ネットワーク・インターフェース・カードを含むことができる。モニタ１０７は、管理情報を提示するために使用することができる。

機械可読媒体およびプログラミング・ロジックを有するコンピュータ・プログラムに関して説明すると、プログラミング・ロジックを保管するための模範的なデータ記憶媒体は図１１の参照番号２００によって示されている。媒体２００は、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）ディスク、書き換え可能コンパクト・ディスク（ＣＤ−Ｒ／Ｗ）ディスク、およびデジタル多用途ディスク（ＤＶＤ）など、従来通り商用ソフトウェア販売に使用されるタイプのポータブル光学記憶ディスクとして示されている。このような媒体は、単独で、または必要な機能を取り入れた他のソフトウェア・プログラムとともに、本発明のプログラミング・ロジックを保管することができる。プログラミング・ロジックは、ポータブル磁気媒体（フレキシブル・ディスク、フラッシュ・メモリ・スティックなど）、あるいはドライブ・システムと結合された磁気媒体（たとえば、ディスク・ドライブ）、あるいはランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、またはその他の半導体もしくはソリッド・ステート・メモリなど、データ処理プラットフォームに取り入れられた媒体によって提供することもできるであろう。より大まかにいえば、この媒体は、任意の電子、磁気、光学、電磁、赤外線、半導体のシステムまたは装置またはデバイス、伝送または伝搬媒体（ネットワークなど）または信号、あるいはデータ処理システム、コンピュータ、またはその他の命令実行システム、装置、もしくはデバイスによって使用するためにあるいはそれらに関連して使用するためにプログラミング・ロジックを収容、保管、伝達、伝搬、または伝送することができるその他のエンティティを含むことができるであろう。

本発明の様々な実施形態について説明してきたが、本発明により多くの変形および代替実施形態を実現できることは明らかになるはずである。したがって、本発明は、特許請求の範囲の精神によるものおよびそれと同等のものを除き、けっして限定されないことは言うまでもない。

Claims (6)

1. データ記憶リソース上のクライアント・データを管理するように適合されたストレージ・マネージャにおけるデータ・フィルタリング方法であって、
   データ・ストリーム・フィルタの識別コードを受信するステップであって、前記フィルタが前記ストレージ・マネージャの一部ではない、スタンドアロン・プログラムまたはライブラリであるステップと、
   記憶リソース、アプリケーション、ホスト、またはデータ・オブジェクト・カテゴリのうちの１つまたは複数のオブジェクト属性として前記フィルタの識別コードを保管するステップと、
   前記フィルタの識別コードと関連付けられた前記オブジェクト属性である前記記憶リソース、前記アプリケーション、前記ホスト、または前記データ・オブジェクト・カテゴリのうちの１つまたは複数を指定することにより、要求されたデータ・ストリーム操作の一部として、当該指定された前記オブジェクト属性に関連付けられた前記フィルタを呼び出すステップと、
   データ・ストリーム・ソースからデータ・ストリームを受信するステップと、
   呼び出された前記フィルタに受信された前記データ・ストリームを提供するステップと、
   データ・ストリーム宛先に前記フィルタによってフィルタリングされた前記データ・ストリームを送信するステップと、を含み、
   前記フィルタリングの結果、前記データ・ストリームの変換が行われ、前記フィルタが、前記データ・ストリームに対して変換を実行する書き込みフィルタと、前記変換を逆にする場合もあれば、逆にしない場合もある読み取りフィルタとを含むフィルタ対からなる、データ・フィルタリング方法。
2. 前記フィルタがそれ自体の実行コンテキストで呼び出され、前記データ・ストリームがプロセス間通信メカニズムを介して前記フィルタに提供され、そこから受信され、
   前記プロセス間通信メカニズムが、前記データ・ストリームを前記フィルタに提供するための第１のパイプと、前記データ・ストリームを前記フィルタから受信するための第２のパイプとを含む、請求項１記載の方法。
3. 前記フィルタがフィルタ引数を処理するように適合されている場合に前記フィルタに渡され、前記フィルタが前記フィルタ引数を処理するように適合されていない場合に抑制され、前記フィルタ引数によって前記フィルタが呼び出され、
   前記フィルタが暗号化フィルタまたは暗号化解除フィルタのうちの１つであり、前記フィルタ引数が暗号鍵の識別に関係する、請求項１記載の方法。
4. 前記フィルタリングの結果、前記データ・ストリームを変換せずに、前記データ・ストリームに関する情報が生成され、前記フィルタリングが監査証跡の生成を含む、請求項１記載の方法。
5. 請求項１ないし４のいずれかに記載の方法のすべてのステップを実行するために適合された手段を含むシステム。
6. コンピュータ・システムに、請求項１ないし４のいずれかに記載の方法のすべてのステップを実行させるコンピュータ・プログラム。

Images