(57)【特許請求の範囲】
【請求項１】
分散データ処理システム内のオブジェクト指向永続性記憶機構内の永続オブジェクトをアクセスするための、コンピュータ・システムで実施される方法であって、前記永続オブジェクトが、各クラスが独自の永続性機構を有する複数の異なるオブジェクト・クラスを継承し、
前記永続性機構を突き止めるためのキーを有する永続オブジェクト・リファレンスを前記分散データ処理システム内で提供するステップと、
前記永続オブジェクトの複数の異なる永続性機構のメタ状態データに前記キーを関連付け、前記分散データ処理システムに前記キー及び前記メタ状態データを格納するステップと
を含む方法。
【請求項２】
前記関連付けるステップが、さらに、前記分散データ処理システム内のサーバによって前記永続オブジェクトのタプルを作成するステップを含み、前記タプルが、前記キーと、前記永続オブジェクトの位置を指すポインタとを含むことを特徴とする、請求項１の方法。
【請求項３】
前記提供するステップが、さらに、
複数のサーバ・プロセスのうちの１つに永続オブジェクトとして前記オブジェクトを登録するステップと、
前記サーバ・プロセスのうちの１つによって、前記永続オブジェクトのオブジェクト・リファレンス用の前記キーを作成するステップと
を含むことを特徴とする、請求項１の方法。
【請求項４】
前記データ処理システム内で前記永続オブジェクトを突き止める要求に応答して、前記キーだけが伝送されることを特徴とする、請求項１の方法。
【請求項５】
前記データ処理システム内で前記永続オブジェクトを突き止めるため、前記キーだけが単一のサーバに伝送されることを特徴とする、請求項１の方法。
【請求項６】
前記キーが、固定されたサイズであり、オブジェクト・クラスのそれぞれが独自の永続機構を有する複数の異なるオブジェクト・クラスを前記永続オブジェクトが継承する時に、前記キーが変化しないことを特徴とする、請求項１の方法。
【請求項７】
前記永続オブジェクトを登録するステップが、さらに、
前記永続オブジェクトのメモリ内オブジェクトを作成するステップと、
前記永続オブジェクトの前記キーを作成し、前記サーバ・プロセスのうちの前記１つのリファレンス・データ・テーブル内の新規項目として前記キーを格納するステップと
を含むことを特徴とする、請求項３の方法。
【請求項８】
分散データ処理システム内のオブジェクト指向永続性記憶機構内で永続オブジェクトをアクセスするための装置であって、前記永続オブジェクトが、各クラスが独自の永続性機構を有する複数の異なるオブジェクト・クラスを継承し、
前記永続オブジェクトを突き止めるためのキーを有する永続オブジェクト・リファレンスを前記分散データ処理システム内で提供する手段と、
前記永続オブジェクトの複数の異なる永続性機構のメタ状態データと前記キーを関連付け、前記分散データ処理システム内で前記キーと前記メタ状態データとを格納する手段と
を含む装置。
【請求項９】
前記関連付ける手段が、さらに、前記分散データ処理システム内でサーバによって前記永続オブジェクトのタプルを作成する手段を含み、前記タプルが、前記キーと、前記永続オブジェクトの位置を指すポインタとを含むことを特徴とする、請求項８の装置。
【請求項１０】
提供する手段がさらに、
複数のサーバ・プロセスのうちの１つに永続オブジェクトとして前記オブジェクトを登録する手段と、
前記サーバ・プロセスのうちの１つによって前記永続オブジェクトのオブジェクト・リファレンスの前記キーを作成する手段と
を含むことを特徴とする、請求項８の装置。
【請求項１１】
前記データ処理システム内で前記永続オブジェクトを突き止める要求に応答して、前記キーだけが伝送されることを特徴とする、請求項８の装置。
【請求項１２】
前記キーが、固定されたサイズであり、オブジェクト・クラスのそれぞれが独自の永続機構を有する複数の異なるオブジェクト・クラスを前記永続オブジェクトが継承する時に、前記キーが変化しないことを特徴とする、請求項８の装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ処理システムに関し、具体的には、永続オブジェクトの復元に必要なメタ状態またはクリティカル・データを制限のない個数だけ指定するのにオブジェクト・リファレンスを使用できるようにするための分散オブジェクト指向システムに関する。
【０００２】
本特許出願は、参照によって本明細書に組み込まれる、ＩＢＭドケット番号ＡＴ９−９６−０１３、米国特許出願通し番号第０８／６１９０４９号、表題「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｅｎａｂｌｉｎｇ  Ａ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｔｔｒｉｂｕｔｅｓ  ｉｎ  ａｎ  Ｏｂｊｅｃｔ  Ｏｒｉｅｎｔｅｄ  Ｅｎｖｉｒｏｎｍｅｎｔ」の関連特許である。
【０００３】
【従来の技術】
オブジェクト指向プログラミングは、特定の言語、ツール、オペレーティング・システム、アドレス空間、ネットワーク、コンパイラまたはアプリケーションという束縛からプログラマを解放するための解決策として、永年にわたって進歩してきた。選択された分散オブジェクトからなるコンポーネントが、どのネットワーク上にも存在でき、デスクトップ間であれ全企業にまたがるものであれ、他のコンポーネントと通信できるようにする、オブジェクト指向プログラミング言語におけるコンポーネント基盤を作成するために、コンポーネント標準規格が発展しつつある。主要な標準規格の１つが、ＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）である。ＯＭＧ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ）のＣＯＲＢＡ仕様では、クライアントに、あるオブジェクトへのオブジェクト・リファレンスを介してオブジェクトをアクセスする能力が与えられる。オブジェクト・リファレンスとは、オブジェクト・リクエスト・ブローカ（ＯＲＢ、Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ）に対してオブジェクトを指定するのに必要な情報である。オブジェクト・リファレンスを用いると、クライアントからＯＲＢへの要求でオブジェクトを識別できるだけではなく、永続オブジェクトのメタ状態を伝えることもできる。永続オブジェクトのメタ状態とは、永続オブジェクトがＯＲＢのプロセスのメモリに存在しない時に永続オブジェクトを復元するのに必要なクリティカル・データである。
【０００４】
オブジェクトは、複数の異なるインターフェースの実装（インターフェースの実装を、一般にクラスと称する）を多重継承することによって構成できる。これらのクラスのそれぞれを、異なる形態の永続性を使用して実装できる。クラスの中には、その実装にＣＯＲＢＡサービス永続オブジェクト・サービス（ＣＯＲＢＡｓｅｒｖｉｃｅｓ  Ｐｅｒｓｉｓｔｅｎｔ  Ｏｂｊｅｃｔ  Ｓｅｒｖｉｃｅ）インターフェースを使用するものもあれば、それ自体の独自の形態の永続性を使用するものもあり、実際には非オブジェクト指向レガシー・データ（以前に関係データベースに格納されたデータなど）のラッパー（ｗｒａｐｐｅｒ）として実装されるものもある。永続性へのこれらのアプローチのそれぞれが、永続オブジェクトを復元するために異なるタイプのメタ状態を維持するための実装を必要とする。単一のオブジェクトが、複数のこれらのクラスを継承する時には、１つのオブジェクト・リファレンスだけで、継承されたクラスのそれぞれをサポートするためのこれらのさまざまな形態のメタ状態を伝える必要がある。
【０００５】
あるオブジェクトが複数のクラス（これらがネーミング（Ｎａｍｉｎｇ）、イベント（Ｅｖｅｎｔｓ）、セキュリティ（Ｓｅｃｕｒｉｔｙ）、永続（Ｐｅｒｓｉｓｔｅｎｃｅ）、エクスターナリゼーション（Ｅｘｔｅｒｎａｌｉｚａｔｉｏｎ）、トランザクション（Ｔｒａｎｓａｃｔｉｏｎｓ）及びコンカレンシー（Ｃｏｎｃｕｒｒｅｎｃｙ）などのＣＯＲＢＡサービスの実装であれ、アプリケーション・インターフェース実装であれ）を継承する時には、複数のメタ状態の維持が問題になる可能性がある。ＣＯＲＢＡ仕様では、オブジェクト・リファレンスで伝えられるリファレンス・データが、１０２４個のオクテット・シーケンス（ここにメタ状態を格納しなければならない）を越えないことが要求されている。複数の異なるメタ状態を伝える時には、この制限を簡単に越えてしまう可能性がある。
【０００６】
オブジェクト・リファレンスに複数のメタ状態を格納する問題のほかに、オブジェクトを復元する時にオブジェクトの継承したクラスのそれぞれのメタ状態をどのように復元し、したがって、継承されたクラスのそれぞれが永続オブジェクトのその部分をどのように復元できるようにするかという問題がある。
【０００７】
【発明が解決しようとする課題】
したがって、オブジェクト・リファレンスのサイズを増やすことなく、オブジェクト・リファレンスがメタ状態データを永続的に維持できるようにし、永続オブジェクトがメモリから除去され、復元される時に、永続オブジェクトの継承したクラスのそれぞれのメタ状態を検索し、復元するための方法及び装置を有することが望ましい。
【０００８】
【課題を解決するための手段】
本発明は、オブジェクト・リファレンスのサイズを増やすことなく、永続オブジェクトの複数のメタ状態の維持を可能にするための方法及び装置に関する。オブジェクトのＵＵＩＤ（ｕｎｉｖｅｒｓａｌ  ｕｎｉｑｕｅ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）及びオブジェクトの他の包括的な一般情報を含むキーを伝えるために、オブジェクト・リファレンス・データ構造を提供する。サーバ・プロセスによってメモリ内及び永続性記憶装置内で維持されるリファレンス・データ・テーブルには、永続オブジェクトのキーとメタ状態を有するタプル（ｔｕｐｌｅ）が含まれる。永続オブジェクトとしてサーバにオブジェクトを登録するための手順を提供する。サーバ・プロセスへの登録時に、オブジェクトのキーが作成され、メモリ内リファレンス・データ・テーブル内及び永続性リファレンス・データ・テーブル内に項目が作られる。さらに、オブジェクトによって継承されるクラスから永続オブジェクトのメタ状態を格納し、検索するための用意をする。最後に、本発明は、永続オブジェクトがメモリ内に存在しない時（永続オブジェクトは、サーバがダウンする時にメモリから除去される可能性があり、サーバのキャッシュ・メモリ不足が原因でメモリからフラッシュされる）に、そのオブジェクトを復元するための技法を提供する。サーバと永続オブジェクトの間の協力は、サーバ・クラス及び永続オブジェクト基本クラスの導入を介して達成される。
【０００９】
【発明の実施の形態】
本発明は、分散オブジェクト環境でオブジェクト・リファレンスに関連付けられた永続性メタ状態を使用可能にすることを介して、複数の形態の永続性をオブジェクトによって使用可能にするための方法及び装置を提供する。オブジェクトのメタ状態は、オブジェクト・リファレンスのサイズを増やすことなく永続的に維持される。本発明の目的に関して、オブジェクトのメタ状態とは、永続オブジェクトがメモリ内に存在しない時にそのオブジェクトを復元するのに必要なクリティカル・データを指す。本発明を実施できる代表的なハードウェア環境を、図１に示す。図１には、分散データ処理システム８の絵図が示されている。図からわかるように、分散データ処理システム８には、ローカル・エリア・ネットワーク（ＬＡＮ）１０及び３２を含む複数のネットワークが含まれ、ＬＡＮ１０及び３２のそれぞれには、複数の個々のコンピュータ１２及び３０が含まれることが好ましい。当業者であれば、ホスト・プロセッサに結合された複数のワークステーションを、このようなネットワークのそれぞれに利用できることを諒解するであろう。このようなデータ処理システムで一般的であるように、各コンピュータ１２及び３０は、記憶装置１４及びプリンタ１６に結合することができる。
【００１０】
分散データ処理システム８には、さらに、メインフレーム・コンピュータ１８などの１つまたは複数のメインフレーム・コンピュータが含まれ、これらのメインフレーム・コンピュータは、通信リンク２２によってＬＡＮ１０に結合されることが好ましい。メインフレーム・コンピュータ１８は、ＬＡＮ１０の遠隔記憶装置として働く記憶装置２０に結合されることが好ましい。ＬＡＮ１０は、通信リンク２４を経由し、通信コントローラ２６及び通信リンク３４を介してゲートウェイ・サーバ２８にも結合される。ゲートウェイ・サーバ２８は、通信リンク３５を介してＬＡＮ３２をＬＡＮ１０にリンクするように働くワークステーションであることが好ましい。当業者に理解されるとおり、分散データ処理システム８には、分散データ処理システム８の諸セグメントを相互接続するのに使用される、図示されていないゲートウェイ、ルータ、ブリッジ及びさまざまな他のネットワーク・ハードウェアが追加的に含まれる。
【００１１】
図２を参照すると、通常のマイクロプロセッサなどの中央処理装置４０と、システム・バス４２を介して相互接続された複数の他のユニットとを有するワークステーションを表す絵図が示されている。図２に示されたワークステーションには、ランダム・アクセス・メモリ（ＲＡＭ）４４と、読取専用メモリ（ＲＯＭ）４６と、ディスク装置５０などの周辺機器をバスに接続するための入出力アダプタ４８と、キーボード５４、マウス５６、スピーカ５８、マイクロホン６０またはタッチ・スクリーン装置（図示せず）などの他のユーザ・インターフェース装置をバスに接続するためのユーザ・インターフェース・アダプタ５２と、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ６２と、バスを表示装置６６に接続するための表示アダプタ６４とが含まれる。好ましい実施例のワークステーションには、ＯＳ／２オペレーティング・システムと、ツールキットとして含まれる、本発明を構成するコンピュータ・ソフトウェアとが常駐している。当業者であれば、本発明の手順を、ワークステーション上のディスク装置５０、フロッピー・ディスケット６８または主記憶であるＲＡＭ４４に一時的または永久的にロードすることのできるコンピュータ可読媒体上のコンピュータ・プログラム製品の形にすることができることを諒解するであろう。
【００１２】
図３に移ると、単一の永続機構のためにオブジェクト永続性を使用可能にするための従来技術が示されている。図示のサーバ７０は、使用される永続機構を理解し、当技術分野で周知の形で永続オブジェクトのコンテキストで永続オブジェクトと相互作用する方法を理解する。サーバ７０は、メモリ７２のオブジェクトと相互作用し、このオブジェクトには、永続オブジェクトのためのメタ状態７１とオブジェクト状態７３が含まれる。永続オブジェクト用のオブジェクト状態７３は、何らかのタイプの永続性記憶装置７４（たとえばハード・ディスク、ファイル、テープなど）に永久的に格納される。サーバ７０は、永続オブジェクト用のオブジェクト・リファレンス７６を作成し、オブジェクト・リファレンス７６を解釈して、メモリ７２内の永続オブジェクトにアクセスし、これを復元する。当業者であれば、オブジェクト・リファレンス７６に、オブジェクト状態７３をメモリ７２に復元するのに必要なメタ状態７１が含まれることを諒解するであろう。
【００１３】
図４に移ると、従来技術の技法を使用した永続オブジェクトのファイルへの格納の例が示されている。サーバ７０は、メモリ７２内のオブジェクトと相互作用し、このオブジェクトは、この例ではファイルである永続性記憶装置７４に、永続機構を使用してオブジェクト状態７３を格納する。必要なメタ状態は、メタ状態ファイル名７１’であり、これは、永続性記憶装置７４にオブジェクト状態７３を永久的に格納するのに使用される。
【００１４】
図５に移ると、従来技術の永続機構の第２の例が示されている。図５からわかるように、サーバ７０は、特定の関係データベース・テーブルに関連する。サーバ７０に関連する各オブジェクトは、そのオブジェクト状態７３をテーブルの１行として格納されている。永続性記憶装置７４上の永続オブジェクトをアクセスまたは復元するのに必要なメタ状態は、その状態を含む行のメタ状態レコード・キー７１’’であるｒｅｃｏｒｄ＿ｋｅｙである。
【００１５】
ここで２つのクラスを定義することができる。一方のクラスは、図４に示されたメタ状態「ファイル名」を利用する永続機構を使用し、もう一方のクラスは、図５に示されたメタ状態「ｒｅｃｏｒｄ＿ｋｅｙ」を使用する。ここで定義された２つのクラスを多重継承する第３のクラスを作成する場合、第３のクラスのオブジェクト・リファレンスでは、両方のクラスのメタ状態を指定することが必要となる。
【００１６】
図６に移ると、従来技術の異なる形態の永続性を有する複数のクラスを継承する永続オブジェクトの処理の例が示されている。オブジェクト・リファレンス７６では、両方の永続機構のメタ状態を指定することが必要となる。メモリ７２内のオブジェクトには、第１の継承されたクラスからのメタ状態「ファイル名」７１’及びこれに関連するオブジェクト状態７３’と、第２の継承されたクラスからのメタ状態「レコード・キー」７１’’及びこれに関連するオブジェクト状態７３’’とが含まれる。当業者であれば、異なる形態の永続性の組合せのそれぞれが、独自のサーバ７０の実装を必要とし、永続性の形態のそれぞれが、オブジェクト・リファレンス７６へのメタ状態データの追加を必要とすることを諒解するであろう。
【００１７】
図７に移ると、複数の形態の永続性について永続性メタ状態を使用可能にするための本発明が示されている。本発明は、単一サーバ実施態様と、永続性の新しい形態ごとにサイズが増加しないオブジェクト・リファレンスを提供する。単一サーバ実施態様は、再利用という利益をもたらし、新しいオブジェクト・リファレンスは、ＣＯＲＢＡによって定義された固定サイズのオブジェクト・リファレンスによって引き起こされる問題を除去する。ＣＯＲＢＡでオブジェクト・リファレンスのサイズが固定されていなかったとしても、オブジェクト・リファレンスは、通常は何回も複製され、ネットワークを介して頻繁に受け渡しされるので、やはりオブジェクト・リファレンスをできる限り小さくすることが望ましい。性能は、大きいオブジェクト・リファレンスを送信する必要に起因して影響を受ける。図７を参照すると、オブジェクトのメタ状態データ（たとえば、「ファイル名」や「レコード・キー」）を指定するのではなく、サーバ７０によって生成されたキー７８を指定する、オブジェクト・リファレンス７６が示されている。サーバ７０は、オブジェクトごとにキー７８と、メモリ７２内の永続オブジェクトの記憶位置を指すポインタ７７と、メタ状態「ファイル名」７１’とメタ状態「レコード・キー」７１’’とを含む、それ自体のメタ状態データをメモリ８０内で維持する。さらに、サーバ７０は、メタ状態データを永続的に保存するために、永続性記憶装置８２へのアクセスを有する。永続性記憶装置８２には、オブジェクトごとに、キー７８ならびに、メタ状態データであるメタ状態「ファイル名」７１’及びメタ状態「レコード・キー」７１’’が格納される。サーバ７０は、メモリ８０及び永続性記憶装置８２に含まれるメタ状態データを、オブジェクト・リファレンス７６からのキー７８を使用してアクセスする。当業者であれば、メモリ７２とその永続機構７４’及び７４’’（たとえばファイル、データベースの行）の永続オブジェクトが、前に従来技術で説明したものと同一であることを諒解するであろう。
【００１８】
図８に移ると、オブジェクト・リファレンスのサイズを増やすことなく、第３の永続機構が追加されている本発明の例が示されている。永続機構は、索引付きファイルであり、メモリ７２内のオブジェクトには、ファイル名７１’’’及び関連する状態７３’’’を有するメタ状態が含まれる。このメタ状態によって、ファイル名と、オブジェクトの状態が永続性記憶装置７４’’’に格納されるファイル位置への指標とが識別される。当業者には明白なとおり、オブジェクト・リファレンス７６のサイズを増やすことなく、メモリ７２内、サーバのメモリ８０内及びサーバの永続データベースである永続性記憶装置８２内の永続オブジェクトのメタ状態が追加されている。
【００１９】
図９に移ると、オブジェクト・リファレンスのサイズを増やすことなくメタ状態データを永続的に維持するための構造の好ましい実施例が示されている。サーバ・プロセスが、メモリ内リファレンス・データ・テーブル９０と、ファイルや関係データベースなど、永続性記憶装置内リファレンス・データ・テーブル９２とを維持する。メモリ内リファレンス・データ・テーブル９０には、そのサーバによって管理される永続オブジェクトごとに、各永続オブジェトのキー７８と、オブジェクトを含むメモリ７２の位置を指すポインタ７７と、メタ状態７１が含まれる。永続性記憶装置内リファレンス・データ・テーブル９２には、各永続オブジェクトのキー７８とメタ状態７１が含まれる。メモリ７２内の各永続オブジェクトには、そのオブジェクトに適当とみなされる機構を使用してオブジェクトの状態を永続的に保管し復元するのに必要なメタ状態７１が含まれる。オブジェクト・リファレンス７６には、キー７８が含まれ、このキー７８は、サーバ・プロセスによって、オブジェクト・リファレンスと永続性記憶装置内リファレンス・データ・テーブル９２内の行及びオブジェクト・リファレンスとメモリ内リファレンス・データ・テーブル９０の行を関連付けるのに使用される。オブジェクト・リファレンス７６をメモリ７２内のオブジェクトと関連付けるためにサーバが呼び出された時には、サーバーは、キー７８を使って、メモリ内リファレンス・データ・テーブル９０内のそのオブジェクトの行を見つける。メモリ内オブジェクトを指すポインタ７７がＮＵＬＬの場合には、オブジェクトを復元する。復元は、メモリ７２で新規オブジェクトを作成すること、そのオブジェクトにそのメタ状態７１を与えること、及び、そのオブジェクトにその永続状態に基づいてオブジェクト自体を初期設定させることからなる。
【００２０】
オブジェクトの識別に使用されるキー７８は、特定のオブジェクトを永続性にすることを要求された時にサーバによって生成される。表１に、キー構造体の好ましい実施例を示す。この例では、キーに含まれるものに関して大きな柔軟性を可能にする構造体が、擬似コードの形で与えられる。当業者であれば、サーバによってキーが生成される場合に、キーに関連するオブジェクトを一意に識別するためにサーバがキーを使用できるのであれば、どのようなキー構造体でも使用できることを諒解するであろう。
【表１】
0003594210.tif 000002
0003594210.tif 000003
【００２１】
前に述べたように、本発明は、オブジェクト・リファレンスのサイズを増やすことなく、サーバが永続オブジェクトの複数のメタ状態を維持できるようにする。さらに、永続オブジェクトをサポートするサーバは、永続オブジェクトとしてオブジェクトを登録する機構、永続オブジェクトの正しいオブジェクト・リファレンスを作成する機構、及び、永続オブジェクトを管理する機構を提供しなければならない。永続オブジェクトを管理するためには、サーバ・オブジェクトと永続オブジェクトが協力しなければならない。この協力は、サーバ・オブジェクトと永続オブジェクトの標準インターフェースを提供することによって達成される。
【００２２】
表２に、サーバ・オブジェクトと永続オブジェクトの間の基本的な協力を達成するメソッドを含むサーバ・クラスの例を示す。このメソッドは、以下の３つの範疇に分類できる。
（１）オブジェクトを永続オブジェクトとして登録し、オブジェクトの永続的態様を削除し、オブジェクトが永続オブジェクトであるかどうかを問い合わせるためのメソッドｍａｋｅ＿ｐｅｒｓｉｓｔｅｎｔ（）、ｄｅｌｅｔｅ＿ｐｅｒｓｉｓｔｅｎｃｅ（）及びｉｓ＿ｐｅｒｓｉｓｔｅｎｔ（）。
（２）永続オブジェクトのメタ状態を格納し、復元するための、ｓｔｏｒｅ＿ｉｎｄｉｖｉｄｕａｌ＿ｍｅｔａｓｔａｔｅ（）、ｓｔｏｒｅ＿ｅｎｔｉｒｅ＿ｍｅｔａｓｔａｔｅ（）、ｒｅｓｔｏｒｅ＿ｍｅｔａｓｔａｔｅ（）などのメソッド。
（３）オブジェクトの永続性を失うことなくメモリ内オブジェクトを除去するための、ｐａｓｓｉｖａｔｅ＿ｏｂｊｅｃｔ（）、ｐａｓｓｉｖａｔｅ＿ａｌｌ＿ｏｂｊｅｃｔｓ（）などのメソッド。
【００２３】
本発明で定義されるサーバの例のインターフェース定義言語（ＩＤＬ）を、表２に示す。
【表２】
0003594210.tif 000004
0003594210.tif 000005
0003594210.tif 000006
【００２４】
表２からわかるように、Ｓｅｒｖｅｒは、ＢａｓｅＳｅｒｖｅｒインターフェースを継承する。ＢａｓｅＳｅｒｖｅｒインターフェースでは、とりわけオブジェクト・リファレンスのインポートとエクスポートのためのメソッドが定義されるが、これらのメソッドは、永続オブジェクトの正しいオブジェクト参照を構築するためにＳｅｒｖｅｒインターフェースでオーバーライドされなければならない。ＢａｓｅＳｅｒｖｅｒの例は、サーバとして実装されるものであれば、ＣＯＲＢＡ仕様の基本オブジェクト・アダプタ（Ｂａｓｉｃ  Ｏｂｊｅｃｔ  Ａｄａｐｔｅｒ）にある。
【００２５】
図１０に移ると、サーバ・オブジェクトにオブジェクトを登録するためのｍａｋｅ＿ｐｅｒｓｉｓｔｅｎｔ＿ｒｅｆ（）メソッドの流れ図が示されている。オブジェクトが永続オブジェクトになるためには、サーバに登録されなければならない。サーバにオブジェクトを登録する前には、そのオブジェクトは、単に過渡的なオブジェクトであり、サーバ・プロセスの正常終了や異常終了など、特定の動作が発生した場合には永久に失われる。図１０に戻って、この手順は、メモリ内オブジェクトを入力としてブロック１００から始まり、即座にブロック１０２に進んで、オブジェクトが永続オブジェクトであるかどうかを判定する。サーバのリファレンス・データ・テーブルにそのオブジェクトの項目が存在するならば、そのオブジェクトは永続オブジェクトである。ブロック１０２で、そうである場合には、この手順は即座に終了する。ブロック１０２で、そうでない場合には、ブロック１０４でキーを作り、ブロック１０６で、キーを使用したリファレンス・データ・テーブル内の新しい項目を作成するのにキーを利用する。ブロック１０８で、メモリ内オブジェクトを指すポインタを、リファレンス・データ・テーブルの過渡部分に置く。その後、ブロック１１０で、永続性リファレンス用の永続性記憶装置内に項目を作成し、ブロック１１２でこの手順が終了する。当業者であれば、オブジェクトを格納またはメモリから除去する時だけデータが取得されるので、登録処理中にはメタ状態データが実際にオブジェクトから取得されないことを諒解するであろう。
【００２６】
図１１に移ると、永続オブジェクトの永続性態様を除去する、Ｓｅｒｖｅｒのｄｅｌｅｔｅ＿ｐｅｒｓｉｓｔｅｎｃｅ（）メソッドの手順が示されている。この手順は、入力としてオブジェクトを指すポインタを使用して、ブロック１２０から始まる。ブロック１２２で、このポインタを使用して、リファレンス・データ・テーブル内のこのオブジェクトの項目を見つける。ブロック１２４で、検査を行って、項目が見つかったかどうかを判定する。見つからなかった場合、この手順はブロック１２９で終了する。見つかった場合、ブロック１２６で、ブロック１２２で見つかったリファレンス・データ・テーブル内の項目から、入力オブジェクトのキーを得る。ブロック１２８で、このキーを使用して永続性記憶装置からオブジェクトのメタ状態を除去し、ブロック１２９で終了する。
【００２７】
図１２に移ると、入力オブジェクトが永続オブジェクトであるかどうかを判定するための、Ｓｅｒｖｅｒのｉｓ＿ｐｅｒｓｉｓｔｅｎｔ（）メソッドが示されている。この手順は、オブジェクトを指すポインタを入力として、ブロック１３０から始まる。ブロック１３２で、このポインタを使用して、リファレンス・データ・テーブル内でオブジェクトの項目を探索する。ブロック１３４で検査を行って、項目が見つかったかどうかを判定する。見つからない場合、ブロック１４４でこの手順はＦＡＬＳＥ（偽）を返す。見つかった場合、ブロック１３６で、リファレンス・データ・テーブルの項目からオブジェクトのキーを抽出する。ブロック１３８で、キーを使って永続性記憶装置内で項目を探索する。ブロック１４０で検査を実行して、項目が見つかったかどうかを判定する。見つかった場合、ブロック１４２でＴＲＵＥ（真）を返す。そうでない場合、ブロック１４４でＦＡＬＳＥを返す。
【００２８】
上で述べたように、ＢａｓｅＳｅｒｖｅｒインターフェースでは、永続オブジェクトの正しいオブジェクト・リファレンスを構築するためにＳｅｒｖｅｒでオーバーライドしなければならない、オブジェクト・リファレンスのインポートとエクスポートのためのメソッドが定義される。オブジェクトは、そのオブジェクトがサーバ・プロセスの外部で処理される時に、サーバ・プロセスによってエクスポートされる。たとえば、サーバ内で新規オブジェクトを作成し、メソッド呼出しの戻り値としてまたはメソッドのｏｕｔ引数としてクライアントに返す時には、そのオブジェクト・リファレンスを作成する必要がある。
【００２９】
図１３に移ると、本発明を使用する、オブジェクトをエクスポートするための手順が示されている。この手順は、リモート・オブジェクト上のメソッドの呼出しに対する引数として、または、サーバ・プロセス内のオブジェクトに対するメソッド呼出しの戻り値もしくはｏｕｔパラメータとして、オブジェクトがサーバ・プロセスの外部に渡される時に呼び出される。この手順は、オブジェクトを指すポインタを入力としてブロック１５０から始まり、即座にブロック１５２に進んで、ポインタがリファレンス・データ・テーブルに存在するかどうかを判定する。存在する場合、ブロック１５４で、サーバがキーを表引きし、ブロック１５６で、キーを含むオブジェクト・リファレンスを作成する。存在しない場合、ブロック１５３で、親クラスＢａｓｅＳｅｒｖｅｒのメソッドを使用してリファレンスを生成する。ブロック１５８で、サーバがオブジェクト・リファレンスを返し、この手順は、ブロック１５９で終了する。
【００３０】
図１４に移ると、オブジェクトをサーバにインポートするための手順が示されている。この手順は、リモート・オブジェクトからのメソッド要求に対する「ｉｎ」引数または「ｉｎｏｕｔ」引数として受け取ったオブジェクトに関して呼び出される。この手順はブロック１６０で始まり、即座にブロック１６２に進んで、オブジェクト・リファレンスに、それが有効なオブジェクト・リファレンスであることを示す有効なキーが含まれるかどうかを判定する。含まれない場合、ブロック１６４でエラー・フラグを立てる。含まれる場合、ブロック１６６で、キーの構造体を調べることによって、オブジェクト・リファレンスが、永続オブジェクトのリファレンスであるかどうかを判定する。そうでない場合、ブロック１７０で、親クラスＢａｓｅＳｅｒｖｅｒで定義された、オブジェクトをインポートするメソッドを呼び出す。オブジェクト・リファレンスが永続オブジェクトのリファレンスである場合、ブロック１６８で、オブジェクト・リファレンスからキー部分を抽出する。ブロック１７２で、キーがリファレンス・データ・テーブルに存在するかどうかを判定する。存在しない場合、ブロック１７３でエラー・フラグを立てる。ブロック１７２でキーが存在する場合、ブロック１７４で、リファレンス・データ・テーブル内でキーに関連するポインタがＮＵＬＬでない場合には、ブロック１７５でポインタを返す。ブロック１７４でポインタがＮＵＬＬの場合には、ブロック１７６に進み、キーを使って永続性記憶装置内でオブジェクトのメタ状態を格納したレコードを探索する。ブロック１７８で検査を行って、メタ状態が見つかったかどうかを判定する。見つからない場合、ブロック１８０で、エラー表示を生成する。そうでない場合には、ブロック１８２で、初期設定されないオブジェクトを作成する。ブロック１８４で、新たに作成されたオブジェクトに対して「ｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｒｅａｃｔｉｖａｔｉｏｎ」を呼び出す。ブロック１８６で、オブジェクトに対して「ｒｅｉｎｉｔ」を呼び出し、メタ状態を渡す。ブロック１８８で、オブジェクト・ポインタをリファレンス・データ・テーブルに追加し、ブロック１９０でこの手順は終了する。
【００３１】
オブジェクトの永続性の作成、削除及び問合せに関するメソッドをサポートするほかに、サーバは、メタ状態を格納し復元する機構をサポートする必要がある。本発明のメタ状態のアーキテクチャを用いると、どの親クラスでもそれ自体のメタ状態を作成でき、それをオブジェクトの全メタ状態に追加でき、そのクラスに属するメタ状態を探せるようになる。メタ状態構造体に対する協力処理を可能にするために、このアーキテクチャでは、親クラスのそれぞれがそれ自体の状態を識別でき、その状態を、あるオブジェクトの他の親クラスに属する状態に影響せずに操作することができる。このような協力は、たとえば、サーバがメタ状態全体を受け渡しする場合に達成される。サーバは、必要に応じてメタ状態を永続性記憶装置に書き込み、メモリに読み取る以外は、メタ状態自体を操作しない。メタ状態に関して、多数のアーキテクチャが可能である。メタ状態は、一連の構造体または構造体のリストとして表現できる。メタ状態を構造体のリストとして定義することによって、または、特殊な登録インターフェースを提供することによって、メタ状態を動的に構成できるようになる。これによって、永続オブジェクトの親クラスの先見的知識に基づいて構成される必要のないサーバを設計することが可能になる。表３に、親の個数の上限が小さく、先験的に知られている時の、一連の構造体としてのメタ状態の表現の例を示す。ここでは、永続オブジェクトの親クラスと子クラスが、そのクラスに既知の固定された個数を有すると仮定する。
【表３】
0003594210.tif 000007
【００３２】
本発明で定義されるこの例のＳｅｒｖｅｒクラスは、それとメタ状態を交換するための下記の３つのメソッドを提供する。
（１）個々の親クラスがそのメタ状態を格納できるようにするｓｔｏｒｅ＿ｉｎｄｉｖｉｄｕａｌ＿ｍｅｔａｓｔａｔｅ（）
（２）あるオブジェクトのすべての親クラスのメタ状態を格納するｓｔｏｒｅ＿ｅｎｔｉｒｅ＿ｍｅｔａｓｔａｔｅ（）
（３）永続性記憶装置に前に格納されたメタ状態に基づいてオブジェクトを再初期設定するｒｅｓｔｏｒｅ＿ｍｅｔａｓｔａｔｅ（）
【００３３】
図１５に移ると、本発明を使用して個々のメタ状態を格納する手順が示されている。この手順は、クラスＩＤ、個々のメタ状態及びオブジェクトを指すポインタを入力としてブロック２００から始まる。ブロック２０２で、ポインタを使用して、リファレンス・データ・テーブル内でオブジェクトの項目を探索する。ブロック２０４で検査を実行して、項目が見つかったかどうかを判定する。見つからない場合、ブロック２１６で、エラー表示を生成する。見つかった場合、ブロック２０６に進んで、リファレンス・データ・テーブルからオブジェクトのキーを得る。ブロック２０８で、キーを使用して永続性記憶装置からメタ状態を検索し、ブロック２１０で、入力の個々のメタ状態を使用してメタ状態を修正する。ブロック２１２で、メタ状態を永続性記憶装置に格納し、ブロック２１４で手順を終了する。
【００３４】
図１６に移ると、オブジェクトの全メタ状態を格納する手順が示されている。この手順は、オブジェクトを指すポインタを入力としてブロック２２０から始まる。ブロック２２２で、リファレンス・データ・テーブル内でオブジェクトのキーを探索する。ブロック２２４で検査を行って、キーが見つかったかどうかを判定する。見つからない場合、ブロック２２３でエラー表示を生成する。見つかった場合、ブロック２２６で、オブジェクトに対してｃａｐｔｕｒｅ（）を呼び出すことによって、オブジェクトの全メタ状態を得る。ブロック２２８で、メタ状態を格納し、ブロック２２９で手順を終了する。下で説明するように、ｃａｐｔｕｒｅ（）メソッドは、オブジェクトの全メタ状態を得るために、すべての永続オブジェクトに対して使用可能である。
【００３５】
図１７に移ると、オブジェクトのメタ状態を復元する手順が示されている。この手順は、入力としてオブジェクトを指すポインタを使用して、ブロック２３０から始まる。ブロック２３２で探索を実行して、ポインタを使用してリファレンス・データ・テーブル内でオブジェクトのキーを探す。ブロック２３４で検査を行って、キーが見つかったかどうかを判定する。見つからない場合、ブロック２３３で、エラー表示を生成する。見つかった場合、ブロック２３６で、キーを使用して永続性記憶装置からメタ状態を見つける。ブロック２３８で、オブジェクトに対してｒｅｉｎｉｔ（）を呼び出し、メタ状態を渡し、ブロック２３９で終了する。下で説明するように、ｒｅｉｎｉｔ（）メソッドは、メタ状態を使用してオブジェクトを再初期設定するために、すべての永続オブジェクトに対して使用可能である。
【００３６】
例のＳｅｒｖｅｒクラスのメソッドの最後の範疇は、メモリ内オブジェクトと永続性記憶装置内の項目が、永続オブジェクトと関連するという事実に関する。たとえばリファレンス・データ・テーブルが大きくなりすぎた時やサーバが一時的に遮断される時など、状況によっては、メモリ内オブジェクトを除去する必要が生じる。２つのメソッドｐａｓｓｉｖａｔｅ＿ｏｂｊｅｃｔ（）及びｐａｓｓｉｖａｔｅ＿ａｌｌ＿ｏｂｊｅｃｔｓ（）が、サーバによってサポートされる。
【００３７】
図１８に移ると、オブジェクトをパシベート（ｐａｓｓｉｖａｔｅ）するための手順が示されている。この手順は、オブジェクトを指すポインタを入力として使用して、ブロック２４０から始まる。ブロック２４１で、ポインタを使用してリファレンス・データ・テーブル内でオブジェクトのキーを探索する。ブロック２４２で検査を行って、キーが見つかったかどうかを判定する。見つからない場合、ブロック２４３でエラー表示を生成する。見つかった場合、ブロック２４４で、オブジェクトに対して「ｃａｐｔｕｒｅ（）」メソッドを呼び出して、そのメタ状態を得る。ブロック２４６で、永続性記憶装置にメタ状態を格納し、ブロック２４８で、オブジェクトに対して「ｕｎｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｐａｓｓｉｖａｔｉｏｎ（）」を呼び出すことによって、適当な初期設定解除（ｕｎ−ｉｎｉｔｉａｌｉｚａｔｉｏｎ）を実行する機会をオブジェクトに与える。ブロック２４９で、メモリ内オブジェクトを破棄（ｄｅｓｔｒｏｙ）する。「ｐａｓｓｉｖａｔｅ＿ｏｂｊｅｃｔ（）」メソッドは、メモリ内オブジェクトだけを破棄することに留意されたい。このオブジェクトは、永続性記憶装置に格納されたメタ状態に基づいて、将来に再活性化することができる。「ｐａｓｓｉｖａｔｅ＿ａｌｌ＿ｏｂｊｅｃｔｓ（）」は、サーバに登録されたすべてのオブジェクトをループして、オブジェクトのそれぞれをパシベートする。
【００３８】
次に、永続オブジェクトがサーバ・オブジェクトと協力できるようにするための、永続オブジェクトの義務を論ずる。本発明は、すべての永続オブジェクトに、ＳｅｒｖｉｃｅＢａｓｅと称する新しい基本クラスを提供する。ＳｅｒｖｉｃｅＢａｓｅクラスには、永続オブジェクトとのメタ状態の交換を容易にするメソッド群と、オブジェクトのライフサイクル中に初期設定と初期設定解除を正しく行うメソッド群という２つの範疇のメソッドが含まれる。本発明で定義される例のＳｅｒｖｉｃｅＢａｓｅインターフェースのインターフェース定義言語（ＩＤＬ）を、表４に示す。
【表４】
0003594210.tif 000008
0003594210.tif 000009
【００３９】
永続オブジェクトに必要な協力の形態の１つが、サーバが永続オブジェクトからメタ状態を取得できなければならず、再初期設定のために永続オブジェクトにメタ状態を供給できなければならないことである。これを達成する方法の１つが、「ｒｅｉｎｉｔ（）」メソッドと「ｃａｐｔｕｒｅ（）」メソッドを有する基本クラスを定義することである。永続オブジェクトの親クラスは、この基本クラスを継承しなければならず、引数として渡されるメタ状態を使用してそのクラス専用の再初期設定を実行するために「ｒｅｉｎｉｔ（）」をオーバーライドしなければならない。同様に、永続オブジェクトの親クラスは、「ｃａｐｔｕｒｅ（）」メソッドのｉｎｏｕｔ引数としてメタ状態を供給しなければならない。サーバは、オブジェクト・リファレンスをインポートする時に「ｒｅｉｎｉｔ（）」を呼び出すことができ、オブジェクトをパシベートする時に「ｃａｐｔｕｒｅ（）」を呼び出すことができることを想起されたい。これらのメソッドの両方で、サーバが引数として全メタ状態を渡すことが好ましい。しかし、他の方式も考えられる。たとえば、サーバ・オブジェクトは、メタ状態の取得と供給のために、個々のクラスごとに独自のメソッドを利用することができる。これには、サーバ・オブジェクトがオブジェクトの型を調べ、その型から、使用するメソッドを演繹することが必要である。
【００４０】
永続オブジェクトに必要な協力のもう１つの形態が、オブジェクトのライフサイクル中に異なる形でオブジェクトの初期設定と初期設定解除を行うことが可能でなければならないことである。第１レベルがＲＡＭ（図２の記憶装置１４）であり、第２レベルが永続性記憶装置（図２の記憶装置２０）である少なくとも２レベルの記憶システム上に永続性の状態を有するオブジェクトは、２つの別個のライフサイクルすなわち、オブジェクトの永続性の状態のライフサイクルと、それを介してオブジェクトの状態を操作できるメモリ内オブジェクトのライフサイクルを有する。
【００４１】
オブジェクトは、オブジェクトが作成または破棄される際の条件に依存して、異なるタイプの初期設定及び初期設定解除をこうむる。当業者であれば、オブジェクトが始めて作成される時、そのオブジェクトが、静的に宣言するには複雑過ぎるインスタンス変数を格納するためにそれ自体でメモリを割り振らなければならないことを諒解するであろう。呼び出されるサーバ・プロセスにオブジェクトを登録することを含めて、オブジェクトが従属するさまざまなフレームワークにオブジェクトを登録することが必要になる場合がある。フレームワークまたはアプリケーションとの統合を、「機能的初期設定（ｆｕｎｃｔｉｏｎａｌ  ｉｎｉｔｉａｌｉｚａｔｉｏｎ）」と称する。この種の初期設定は、ＳｅｒｖｉｃｅＢａｓｅクラスの「ｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｃｒｅａｔｉｏｎ（）」メソッドで行われる。
【００４２】
その一方で、適当なフレームワークにすでに登録されているオブジェクトは、動作的初期設定（たとえば、状態などを格納するために必要なメモリの割振り）を実行すれば十分である。この種の初期設定は、ＳｅｒｖｉｃｅＢａｓｅクラスの「ｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｒｅａｃｔｉｖａｔｉｏｎ（）」メソッドで行われる。サーバは、オブジェクトを再活性化する時には必ず、オブジェクト状態の初期設定を全く含まない、包括的なクラス初期設定を呼び出す。その後、サーバ・プロセスは、「ｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｒｅａｃｔｉｖａｔｉｏｎ」を呼び出して、必要なメモリを割り振る機会をオブジェクトに与える。サーバ・プロセスは、オブジェクトのメタ状態を復元するために、オブジェクトに対して「ｒｅｉｎｉｔ」を呼び出す。
【００４３】
同様に、オブジェクト破棄中の初期設定解除に関して類似の結論を行うことができる。メモリ内オブジェクトだけが破棄され、その結果、オブジェクトを新しい位置に移動できる場合があり、単にメモリ内オブジェクトをパシベートするためにメモリ内オブジェクトが破棄される（たとえば、そのオブジェクトの永続性状態は有効なままになる）場合もある。最後に、オブジェクトがもはやシステムに属さなくなるので完全にオブジェクトが破棄される場合がある。サーバがオブジェクトをパシベートする時には必ず、サーバが、まず「ｃａｐｔｕｒｅ」を呼び出して、オブジェクトのメタ状態を得る。サーバは、その後、「ｕｎｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｐａｓｓｉｖａｔｉｏｎ」を呼び出し、その後、包括的なオブジェクト破棄メソッドを呼び出す。クライアントがオブジェクトを完全に破棄することを望む時には、クライアントは、まず「ｕｎｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｄｅｓｔｒｕｃｔｉｏｎ」を呼び出した後に包括的なオブジェクト破棄メソッドを呼び出す。
【００４４】
そのインスタンスが永続オブジェクトであるクラスのそれぞれは、メタ状態を導入する混入（ｍｉｘ−ｉｎ）として提供するクラスまたはメタ状態を導入するフレームワークのためのＳｅｒｖｉｃｅＢａｓｅのそれ自体の特化を提供する。このような特化は、それ自体の目的を交換するために「ｒｅｉｎｉｔ」及び「ｃａｐｔｕｒｅ」をオーバーライドしなければならない。ＳｅｒｖｉｃｅＢａｓｅクラスの各メソッドは、一般に「イニシャライザ」・メソッドまたは「デストラクタ」・メソッドとして既知のメソッドであることに留意されたい。これは、オブジェクトが複数のクラスから多重継承する時に、あるクラスでのこれらのメソッドの実装が、それ自体のレベルで必要なハウスキーピングを実行し、また、その親クラスのそれぞれの対応するメソッドの呼出しを行うことを意味する。当業者であれば、クラスは、それ自体の初期設定を行う前にその親のイニシャライザを呼び出さなければならず、それ自体の初期設定解除を行った後にその親の初期設定解除メソッド（デストラクタ）を呼び出さなければならないことを諒解するであろう。
【００４５】
次に、さまざまな初期設定メソッド及び初期設定解除メソッドの使い方を示す２つのシナリオを説明する。第１のシナリオの図１９に移ると、オブジェクト作成の流れ図が示されている。当業者であれば、オブジェクト作成が、局所または遠隔のオブジェクト・ファクトリによって正常に実行されることを諒解するであろう。局所オブジェクト・ファクトリは、図１９の手順を使用して新規オブジェクトを作成する。この手順は、ブロック２５０で始まり、即座にブロック２５２に移って、新規オブジェクトを作成する必要があるかどうかを判定する。そうである場合には、ブロック２５４で、局所オブジェクト・ファクトリが、オブジェクトのクラスを突き止め、ブロック２５６で、クラスに対する包括的なイニシャライザを呼び出す。そうでない場合には、この手順はブロック２５９で終了する。ブロック２５８で、特定のイニシャライザ、すなわち「ｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｃｒｅａｔｉｏｎ」を呼び出す。一般に、永続オブジェクトを導入する初期オブジェクト作成に使用されるイニシャライザは、サーバに対して「ｍａｋｅ＿ｐｅｒｓｉｓｔｅｎｔ＿ｒｅｆ」を呼び出して、永続性リファレンスを用いてオブジェクトを登録しなければならない。
【００４６】
第２のシナリオの図２０に移ると、オブジェクト活性化の流れ図が示されている。サーバは、永続性リファレンスを有するオブジェクトを自動的に再活性化する。別のプロセスからメソッドが呼び出される場合には、オブジェクト・アダプタが、オブジェクト・リファレンスを局所オブジェクト・ポインタに解決するようサーバに要求する。図２０を特に参照すると、この手順はブロック２６０から始まり、即座にブロック２６２に進んで、サーバがオブジェクト・リファレンスを識別し、ブロック２６４で、オブジェクトがメモリ内に存在するかどうかを判定する。オブジェクトがメモリ内にない場合、ブロック２６６で、サーバは、参照されたオブジェクトのクラス・オブジェクトを突き止める。オブジェクトがメモリ内にある場合、この手順はブロック２６１で停止する。ブロック２６８で、サーバは、クラスに対する包括的なクラス・イニシャライザを呼び出して、新規のメモリ内インスタンスを作成する。その後、ブロック２７０で、サーバは、オブジェクトに対して「ｉｎｉｔ＿ｆｏｒ＿ｏｂｊｅｃｔ＿ｒｅａｃｔｉｖａｔｉｏｎ」を呼び出して、オブジェクト初期設定を可能にする。ブロック２７２で、サーバは、新規作成されたオブジェクトに対して「ｒｅｉｎｉｔ」を呼び出して、そのオブジェクトのメタ状態をロードする。当業者であれば、オブジェクト永続性を管理するＳｅｒｖｉｃｅＢａｓｅのサブクラスが、「ｒｅｉｎｉｔ」をオーバーライドして、この時にオブジェクトの永続性状態も復元することができることを諒解するであろう。
【００４７】
好ましい実施例に関して本発明を説明してきたが、当業者であれば、本発明の趣旨、範囲及び教示から逸脱することなく、詳細におけるさまざまな変更を行えることを諒解するであろう。したがって、本明細書に開示された発明は、請求の範囲での指定によってのみ制限される。
【００４８】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００４９】
（１）分散データ処理システム内のオブジェクト指向永続性記憶機構内の永続オブジェクトをアクセスするための、コンピュータ・システムで実施される方法であって、前記永続オブジェクトが、各クラスが独自の永続性機構を有する複数の異なるオブジェクト・クラスを継承し、
前記永続性機構を突き止めるためのキーを有する永続オブジェクト・リファレンスを前記分散データ処理システム内で提供するステップと、
前記永続オブジェクトの複数の異なる永続性機構のメタ状態データに前記キーを関連付け、前記分散データ処理システムに前記キー及び前記メタ状態データを格納するステップと
を含む方法。
（２）前記関連付けるステップが、さらに、前記分散データ処理システム内のサーバによって前記永続オブジェクトのタプルを作成するステップを含み、前記タプルが、前記キーと、前記永続オブジェクトの位置を指すポインタとを含むことを特徴とする、上記（１）の方法。
（３）前記提供するステップが、さらに、
複数のサーバ・プロセスのうちの１つに永続オブジェクトとして前記オブジェクトを登録するステップと、
前記サーバ・プロセスのうちの１つによって、前記永続オブジェクトのオブジェクト・リファレンス用の前記キーを作成するステップと
を含むことを特徴とする、上記（１）の方法。
（４）前記データ処理システム内で前記永続オブジェクトを突き止める要求に応答して、前記キーだけが伝送されることを特徴とする、上記（１）の方法。
（５）前記データ処理システム内で前記永続オブジェクトを突き止めるため、前記キーだけが単一のサーバに伝送されることを特徴とする、上記（１）の方法。
（６）前記キーが、固定されたサイズであり、オブジェクト・クラスのそれぞれが独自の永続機構を有する複数の異なるオブジェクト・クラスを前記永続オブジェクトが継承する時に、前記キーが変化しないことを特徴とする、上記（１）の方法。
（７）前記永続オブジェクトを登録するステップが、さらに、
前記永続オブジェクトのメモリ内オブジェクトを作成するステップと、
前記永続オブジェクトの前記キーを作成し、前記サーバ・プロセスのうちの前記１つのリファレンス・データ・テーブル内の新規項目として前記キーを格納するステップと
を含むことを特徴とする、上記（３）の方法。
（８）分散データ処理システムでメタ状態データを交換するための、コンピュータ内で実施される方法であって、
前記メタ状態データを交換するための複数のメソッドを有する、複数の永続オブジェクトのための基本クラスを提供するステップと、
前記永続オブジェクトと前記メタ状態データを交換し、前記永続オブジェクトのうちの選択された１つのオブジェクト・リファレンスを作るためのサーバ・クラスを、前記分散データ処理システム内で提供するステップと
を含む方法。
（９）前記オブジェクト・リファレンスが、前記メタ状態データに関連するキーを含むことを特徴とする、上記（８）の方法。
（１０）分散データ処理システム内のオブジェクト指向永続性記憶機構内で永続オブジェクトをアクセスするための装置であって、前記永続オブジェクトが、各クラスが独自の永続性機構を有する複数の異なるオブジェクト・クラスを継承し、
前記永続オブジェクトを突き止めるためのキーを有する永続オブジェクト・リファレンスを前記分散データ処理システム内で提供する手段と、
前記永続オブジェクトの複数の異なる永続性機構のメタ状態データと前記キーを関連付け、前記分散データ処理システム内で前記キーと前記メタ状態データとを格納する手段と
を含む装置。
（１１）前記関連付ける手段が、さらに、前記分散データ処理システム内でサーバによって前記永続オブジェクトのタプルを作成する手段を含み、前記タプルが、前記キーと、前記永続オブジェクトの位置を指すポインタとを含むことを特徴とする、上記（１０）の装置。
（１２）提供する手段がさらに、
複数のサーバ・プロセスのうちの１つに永続オブジェクトとして前記オブジェクトを登録する手段と、
前記サーバ・プロセスのうちの１つによって前記永続オブジェクトのオブジェクト・リファレンスの前記キーを作成する手段と
を含むことを特徴とする、上記（１０）の装置。
（１３）前記データ処理システム内で前記永続オブジェクトを突き止める要求に応答して、前記キーだけが伝送されることを特徴とする、上記（１０）の装置。
（１４）前記キーが、固定されたサイズであり、オブジェクト・クラスのそれぞれが独自の永続機構を有する複数の異なるオブジェクト・クラスを前記永続オブジェクトが継承する時に、前記キーが変化しないことを特徴とする、上記（１０）の装置。
（１５）分散データ処理システム内のオブジェクト指向永続性記憶機構内の永続オブジェクトをアクセスするためのコンピュータ・プログラム論理を記録されたコンピュータ可読媒体を有するコンピュータ・プログラム製品であって、前記永続オブジェクトが、各クラスが独自の永続機構を有する複数の異なるオブジェクト・クラスを継承し、
前記永続オブジェクトを突き止めるためのキーを有する永続オブジェクト・リファレンスを前記分散データ処理システム内で提供するためのコンピュータ可読手段と、
前記永続オブジェクトの複数の異なる永続機構のメタ状態データに前記キーを関連付け、前記分散データ処理システム内で前記キーと前記メタ状態データとを格納するためのコンピュータ可読手段と
を有するコンピュータ・プログラム製品。
（１６）前記分散データ処理システム内のサーバによって前記永続オブジェクトのタプルを作成するためのコンピュータ可読手段を含み、前記タプルが、前記キーと、前記永続オブジェクトの位置を指すポインタとを含むことを特徴とする、上記（１５）のコンピュータ・プログラム製品。
（１７）複数のサーバ・プロセスのうちの１つに永続オブジェクトとして前記オブジェクトを登録するためのコンピュータ可読手段と、
前記サーバ・プロセスのうちの１つによって、前記永続オブジェクトのオブジェクト・リファレンス用の前記キーを作成するためのコンピュータ可読手段と
を含むことを特徴とする、上記（１５）のコンピュータ・プログラム製品。
（１８）前記データ処理システム内で前記永続オブジェクトを突き止める要求に応答して、前記キーだけが伝送されることを特徴とする、上記（１５）のコンピュータ・プログラム製品。
【図面の簡単な説明】
【図１】本発明を実施できる、分散オブジェクト指向データ処理システムを表すブロック図である。
【図２】本発明を実施できるコンピュータまたはワークステーションを表すブロック図である。
【図３】永続性記憶装置に永久的に永続オブジェクトを格納するためのメタ状態データの従来技術の使用を示すブロック図である。
【図４】ファイルに永続オブジェクトを格納するためのメタ状態データの従来技術の使用を示すブロック図である。
【図５】関係データベースの１行に永続オブジェクトを格納するための従来技術の技法を示すブロック図である。
【図６】異なる永続性記憶機構から多重継承する永続オブジェクトを格納するための従来技術の手順を示すブロック図である。
【図７】本発明で使用されるオブジェクト・リファレンス内のキーの使用を示すブロック図である。
【図８】本発明で使用されるオブジェクト・リファレンス内のキーの使用を示すブロック図である。
【図９】本発明を実施するためのメモリ構造を示すブロック図である。
【図１０】本発明を使用するオブジェクト登録を示す流れ図である。
【図１１】本発明を使用するオブジェクトの永続性態様の削除を示す流れ図である。
【図１２】本発明を使用する、オブジェクトが永続性であるかどうかの検査を示す流れ図である。
【図１３】本発明を使用するオブジェクトのエクスポートを示す流れ図である。
【図１４】本発明を使用するオブジェクトのインポートを示す流れ図である。
【図１５】本発明を使用する、個々のメタ状態の格納を示す流れ図である。
【図１６】本発明を使用する、永続オブジェクトの全メタ状態の格納を示す流れ図である。
【図１７】本発明を使用する、永続オブジェクトのメタ状態の復元を示す流れ図である。
【図１８】本発明を使用する、オブジェクトのパシベーションを示す流れ図である。
【図１９】本発明を使用する、永続オブジェクトの作成を示す流れ図である。
【図２０】本発明を使用する、オブジェクトの活性化を示す流れ図である。
【符号の説明】
７０  サーバ
７１  メタ状態
７１’  メタ状態ファイル名
７１’’  メタ状態レコード・キー
７１’’’  ファイル名
７２  メモリ
７３  オブジェクト状態
７３’  オブジェクト状態
７３’’  オブジェクト状態
７３’’’  状態
７４  永続性記憶装置
７４’  永続機構
７４’’  永続機構
７４’’’  永続性記憶装置
７６  オブジェクト・リファレンス
７７  ポインタ
７８  キー
８０  メモリ
８２  永続性記憶装置
９０  メモリ内リファレンス・データ・テーブル
９２  永続性記憶装置内リファレンス・データ・テーブル
【図１】
0003594210.tif 000010
【図２】
0003594210.tif 000011
【図３】
0003594210.tif 000012
【図４】
0003594210.tif 000013
【図５】
0003594210.tif 000014
【図６】
0003594210.tif 000015
【図７】
0003594210.tif 000016
【図８】
0003594210.tif 000017
【図９】
0003594210.tif 000018
【図１０】
0003594210.tif 000019
【図１１】
0003594210.tif 000020
【図１２】
0003594210.tif 000021
【図１３】
0003594210.tif 000022
【図１４】
0003594210.tif 000023
【図１５】
0003594210.tif 000024
【図１６】
0003594210.tif 000025
【図１７】
0003594210.tif 000026
【図１８】
0003594210.tif 000027
【図１９】
0003594210.tif 000028
【図２０】
0003594210.tif 000029