JPH10511202A - オブジェクト指向環境における回復可能プロキシ・オブジェクト - Google Patents

Abstract

(57)【要約】 サーバの誤動作後にプロキシ・オブジェクト（４４９）の無効な使用からサーバを保護し、クライアント−サーバ分散処理システムのクライアントにおいてプロキシ・オブジェクトを透過的に再作成する機構について記載する。サーバ内のターゲット・オブジェクトの名前（４５５）を示す追加の属性と、その名前が現在有効であるかどうかに関する標識（４５９）と、ターゲット・オブジェクトを指す代替ポインタ（４５７）とを有するプロキシ・クラスを使用する。クライアント内のプロキシ・レジスタ・オブジェクト（１５５）が、サーバ内のオブジェクトを指すすべてのプロキシ・オブジェクト（４４９）を指すポインタを維持する。サーバの誤動作が発生し、その結果としてプロキシ・オブジェクト（４４９）が無効になると、プロキシ・レジスタ・オブジェクト（１５５）はすべてのプロキシ・オブジェクト（４４９）をリフレッシュさせる。

Description

【発明の詳細な説明】 オブジェクト指向環境における回復可能プロキシ・オブジェクト発明の分野 本発明は、コンピュータ化オブジェクト指向技法に関し、具体的には、サーバ にあるターゲット・オブジェクトを表すプロキシ・オブジェクトがクライアント にあり、プロキシ・オブジェクトがサーバの障害後に回復可能な、前記技法で使 用するプロキシ・オブジェクトに係わる。発明の背景 オブジェクト指向プログラミングの概要 オブジェクト指向プログラミングが開発される以前に、構造化プログラミング と呼ばれるプログラミングの一形態が開発され、今でも広く使用されている。こ の技法では、まずさまざまな関数を定義し、次にプログラムがその定義された関 数を適切な時点で呼び出してアプリケーション・プログラムの全体的な目的を実 現することから成る。このような関数は、データを操作するために使用するメソ ッドを定義するが、データ自体は定義しない。構造化プログラミングはモジュー ル化手法の機会をもたらした。これは、メンテナンスやデバッグが難しい「スパ ゲッティ・コード」を克服する重要な改 良であった。それにもかかわらず、構造化プログラミングには、プログラムによ ってモデル化される世界における概念および実体と、プログラミング言語におけ る概念との間の「意味ギャップ」や、プログラム・コードのテキスト性、コード ・モジュールの再使用可能性の限界などいくつかの欠点も残されている。 その後、オブジェクト指向プログラミングと呼ばれる新しいプログラミング・ パラダイムが開発された。この技法では、関数を定義する代わりに、「クラス」 を定義する。クラス定義によって、そのクラスの任意のインスタンスが実行する ことができるメソッドと、そのクラスのインスタンスに含まれる属性（またはデ ータ）とを定義する。オブジェクトはクラスのメンバーであり、クラス定義で定 義されているメソッドを実際に実行することができる。オブジェクトは、クラス によって定義された各属性に付随する値を持つ。オブジェクトは、ゼロまたは１ 個以上の属性を持ち、そのオブジェクトに対して実行することができるゼロまた は１個以上のメソッドを持つ。 オブジェクトとのインタフェースは、メソッドを介して属性にアクセスするこ とができる方法である。そのクラスから導き出されるすべてのオブジェクトがそ のクラスのインタフェースを共有する。オブジェクトの実現部分はオブジェクト を呼び出すアプリケーションから隠蔽される。オブジェクトへのインタフェース が変わらない限り、アプリケーションに 影響を与えることなく実現部分を完全に変えることはできない。 オブジェクトが内部でどのように「見える」か、また内部で何を「行う」かを 記述する必要なしにオブジェクトの「外観」を記述するこの技法を単純化した例 として、また、そのようなオブジェクト指向プログラミングの重要な利点を例示 するための例として、オブジェクト指向手法によってモデル化することができる 普通の家庭用トースタを考えてみる。外部「インタフェース」は、トーストの所 望の焼き加減を調節するパラメータを本質的に表すつまみと、パンを入れるスロ ットと、トースタへの挿入とトースタの起動を行うレバーとから成る。重要な概 念は、この種の家電製品のエンドユーザはそれを使用するためにトースタの「内 部」を知る必要がないことである。たとえば、熱が電気によって供給されるのか 、化学薬品やその他の手段によって供給されるのかを知る必要はない。ユーザは 上記の外面部と正しくインタフェースするだけでよい。 プログラミングにおけるこの進化の利点は、上記の例を続けて用いると、トー スタをモデル化するプログラミング・コードのモジュールであるオブジェクトの 設計者が、ユーザにとって内部が見えないために、たとえばユーザがそのオブジ ェクトを使用する能力に影響を与えることなくトースタの内部要素を改良するこ とに焦点を絞ることができ、効率を向上させることができることである。したが って、より抽象的に 言うと、オブジェクト指向技法は本質的に、オブジェクトのインタフェースをオ ブジェクトの実現部分から分離する利点をもたらすものと見なすことができる。 ソフトウェア環境においては、それによって、外部の「つまみ」などやその予想 される動作が変わらない限り、アプリケーション・プログラム全体を書き直さな くてもオブジェクトの内部を書き直し、改良することができる。 本発明の理解を助けるオブジェクト技法に関するその他の一般的背景について は、デイビッドＡ．テイラー（Ｄａｖｉｄ Ａ．Ｔａｙｌｏｒ）による「Ｏｂｊ ｅｃｔ Ｏｒｉｅｎｔｅｄ Ｔｅｃｈｎｏｌｏｇｙ − Ａ Ｍａｎａｇｅｒ’ ｓ Ｇｕｉｄｅ」（ｃｏｐｙｒｉｇｈｔ １９９０，Ｓｅｒｖｉｏ Ｃｏｒｐｏ ｒａｔｉｏｎ）を参照されたい。 オブジェクト指向プログラミングの発展に伴い、様々な組織やソフトウェア会 社によっていくつかの「オブジェクト・モデル」がさらに改良され、開発された 。オブジェクトとその外部インタフェースを定義する方法が規定され、そのよう な様々なオブジェクト・モデルによって特にカプセル化と継承の特性が規定され た。ある程度の高レベルから見れば、これらの様々なオブジェクト・モデルはき わめて類似している。たとえば、システム・オブジェクト・モデル（ＳＯＭ）、 コモンＬｉｓｐオブジェクト・システム（ＣＬＯＳ）、Ｓｍａｌｌｔａｌｋ、お よびＣ＋＋などがある。本質的には、これらの様々なオブジェクト・モデルはオ ブジェクトが何であ るかという問いに答える規則の集まりに過ぎず、より低レベルで検討するとそれ ぞれわずかに異なった答えが出る。たとえば、言語構文とカプセル化および継承 の機能はオブジェクト・モデルによって異なる。 これらの相違の直接の結果として、異なるオブジェクト指向言語およびオブジ ェクト・モデルの使用可能性により生じる１つの問題は、そのような言語の混合 で書かれたオブジェクト・プログラム間のインターオペラビリティを実現するこ とができないことであった。この問題は、オブジェクト技法の重要な利点の１つ であるコードの再使用可能性に悪影響を与える。業界を悩ませるこの問題を解決 しようとして、委員会は共通オブジェクト要求ブローカ・アーキテクチャ（ＣＯ ＲＢＡ）に到達した。これには標準化インタフェース定義言語（ＩＤＬ）が含ま れていた。業界ではオブジェクトインタフェースをどのように規定するか、すな わち、オブジェクト・インタフェースを定義する標準に関して本質的に合意に達 し、その結果、１つのベンダーによって定義されたオブジェクトを他のベンダー が使用することが可能になった。「Ｔｈｅ Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅ ｑｕｅｓｔ Ｂｒｏｋｅｒ：Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｓｐｅｃｉｆ ｉｃａｔｉｏｎ」（ＯＭＧ Ｄｏｃｕｍｅｎｔ Ｎｕｍｂｅｒ ９１．１２．１ Ｒｅｖｉｓｉｏｎ１．１）を参照されたい。 オブジェクト要求ブローカ（ＯＲＢ） ＣＯＲＢＡアーキテクチャで記述されたオブジェクト要求ブローカ（ＯＲＢ） は、ＵＮＩＸオペレーティング・システム環境で作業をする人には周知のリモー ト・プロシージャ・コール（ＲＰＣ）に似ている（ＵＮＩＸはＸ／Ｏｐｅｎ Ｃ Ｏ．Ｌｔｄ．によって独占的にライセンス許諾される商標である）。 従来技術のシステムを第１図および第２図に示す。 第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブロ ーカを示すブロック図である。 第２図は、ＤＳＯＭと呼ばれる従来技術の環境を示すブロック図である。 第１図に、ＯＲＢを含むクライアント／サーバ環境を示す。このＯＲＢは２つ の部分に分かれており、そのうちの部分５０はＯＲＢを使用して各クライアント で実行され、部分５２はＯＲＢをサポートする各サーバで実行される。ＲＰＣと 同様に、ＯＲＢは１つのアドレス空間５３で稼働しているクライアント・アプリ ケーション４８が別のアドレス空間５４のオブジェクト５１と通信することがで きるようにする機構である。他方のアドレス空間５４、すなわちクライアント・ アプリケーション４８が実行されているアドレス空間と同じアドレス空間５３で はないアドレス空間にあるオブジェクト５１を「リモート」オブジェクトと呼ぶ 。クライアント・アプリケーション４８と同じアドレス空間５３にあるオブジェ クトを「ローカル」オブジェクトと呼ぶ。ＯＲＢ５０は１つのアドレス空間５３ 内のクライアント・アプリケーション４８からの呼出しを代行受信し、それをネ ットワーク・プロトコルにカプセル化し、別のアドレス空間５４内のターゲット ・オブジェクト５１に合わせて呼出しをデコードし、その結果を呼び出し側クラ イアント・アプリケーション４８に返す。これによって、一方のアドレス空間（ ローカル）で稼働しているクライアント・アプリケーション４８が他方のアドレ ス空間（リモート）内のオブジェクト５１と通信することができる。ＯＲＢは、 オブジェクト指向プログラミングによって得られる高度の柔軟性と能力を備える ように設計されている点で、ＲＰＣが改良されたものである。 「オブジェクト・モデル」は様々な組織やソフトウェア会社によって開発され ている。オブジェクト・モデルはオブジェクトとその外部インタフェースの定義 の仕方を規定する。このようなオブジェクト・モデルの１つは、IBM Corporatio nのシステム・オブジェクト・モデル（ＳＯＭ）である。ＳＯＭでは、オブジェ クトを使用するすべてのアプリケーションはそれらのオブジェクトが入っている １つのアドレス空間内で実行される。ＳＯＭ内で作成されるものは、分散システ ム・オブジェクト・モデル（ＤＳＯＭ）と呼ばれるオブジェクト・クラスのフレ ームワークである。ＤＳＯＭでは、１つのアドレス空間内の（クライアントで稼 働している）アプリケーションは別のアドレス空間（サーバに属するアドレス空 間 など）内のオブジェクトにアクセスすることができる。これらのアドレス空間は 同じシステムと異なるシステムのどちらにあってもよい。実際には、システムは 同じプラットフォームで稼働している必要はない。たとえば、ＯＳ／２システム 上のアドレス空間で稼働しているクライアント・アプリケーションがＡＩＸ／６ ０００システム上のアドレス空間にあるオブジェクトにアクセスすることができ 、その逆も可能である。ＳＯＭとＤＳＯＭの両方については、IBM Corporation が発行している「ＳＯＭｏｂｊｅｃｔ：Ａ Ｐｒａｃｔｉｃａｌ Ｉｎｔｒｏｄ ｕｃｔｉｏｎ ｔｏ ＳＯＭ ａｎｄ ＤＳＯＭ」（Ｃｏｐｙｒｉｇｈｔ １９ ９４，Ｏｒｄｅｒ ｎｏ．ＧＧ２４−４３５７−００）に記載されている。 上記のシステム・オブジェクト・モデル（ＳＯＭ）は、ＣＯＲＢＡとＩＤＬに 準拠した１つのオブジェクト・モデルである。準拠とは、ＳＯＭオブジェクトが ＣＯＲＢＡのセマンティクスに従っており、ＳＯＭオブジェクトがＩＤＬ構文で 定義されているという意味である。 ＤＳＯＭのフレームワークは、ターゲット・オブジェクトがインスタンス化さ れる場所やプラットフォームのタイプをクライアント・プログラマが知らなくて も済むようにするオブジェクト実現部を備える。このプロセス間通信に使用され る通信機構は、プログラマには見えないように完全に隠蔽される。 クライアント−サーバ・アーキテクチャ クライアント−サーバ・アーキテクチャでは、アプリケーション・プログラム は個別の構成要素として実行される個別のタスクに分けられる。各構成要素には クライアントまたはサーバの役割が割り当てられる。１つの構成要素は、ある目 的のためにはサーバの役割を果たし、他の目的のためにはクライアントの役割を 果たすことができる。各構成要素は独立して動作し、特定の責任を担う。クライ アントの役割が割り当てられた構成要素は、サーバ・プロセス内のオブジェクト に対するメソッド呼出しを行うことによって、サーバにサービスを要求する。サ ーバの役割が割り当てられた構成要素は、それらのメソッド呼出しを受け取り、 該当するオブジェクトに対してそれらのメソッド呼出しを行い、その結果をクラ イアントに返すことによってサービスを提供する。クライアントとサーバは事前 定義されたプロトコルを使用してメッセージを交換する。サーバは多くのクライ アントにサービスを提供することができ、クライアントは多くのサーバにサービ スを要求することができる。 プロキシ・オブジェクト プロキシ・オブジェクトとは、リモート・ターゲット・オブジェクトのローカ ル表現である。プロキシ・オブジェクトはターゲット・オブジェクトのインタフ ェースを継承し、その結果、同じメソッドに応答する。プロキシ・オブジェクト で呼び出されたメソッドはローカルでは実行されず、実ターゲット・オブジェク トに転送されて実行される。クライアントで稼働しているプログラムは常に、各 リモート・オブジェクトが稼働しているサーバ内の各リモート・オブジェクトの ローカル・プロキシ・オブジェクトをそのクライアント内に持っている。プロキ シ・オブジェクト内には、ターゲット・オブジェクトが入っているサーバ内の記 憶場所を指すポインタが含まれている。プロキシ・オブジェクトにはターゲット ・オブジェクトの名前は含まれない。プロキシ・オブジェクトは、リモート・サ ーバに対してリモート・オブジェクトに対するメソッド呼出しの要求が行われる と常に、ＤＳＯＭ実行時環境によって作成される。 ＤＳＯＭ環境 クライアント・プロセスはサーバ・プロセス内のオブジェクトについてメソッ ド呼び出しを行う。これらのメソッド呼び出しは、たとえば属性に付随する値の 入手（読取り）や属性に付随する値の設定（書込み）を行うことができる。サー バ・プロセスはこれらのメソッド呼び出しを受け取り、該当するオブジェクトに ついてそれらを呼び出し、クライアントに結果を返す。第２図にＤＳＯＭ環境の 構成要素の一部の超高水準図を示す。クライアント・アドレス空間５３はＤＳＯ Ｍオブジェクト・マネージャ３０３と呼ぶオブジェクトを含む。このオブジェク トは、サーバ・オブジェクト３１３の（ 後述する）プロキシ・オブジェクト３０５を指すポインタを返すことによって、 クライアント・アプリケーション（第１図の４８）がサーバ５４を見つけ出すの を支援する。クライアントは次に、そのサーバ５４上で事前定義されているクラ スのオブジェクト５１のインスタンスを作成したり、そのサーバ上にすでに存在 するオブジェクト５１へのアクセスを獲得したり、そのサーバ５４上のオブジェ クト５１が不要になった場合にそれを破棄したりするために、サーバ・オブジェ クト３１３に対するメソッドを（そのプロキシ・オブジェクト３０５を介して） 呼び出す。 クライアント・アプリケーション（第１図の４８）は、サーバ・プロキシ・オ ブジェクト３０５に対して呼出しを行い、メソッド呼出しを行いたいオブジェク ト５１のある場所を見つけ出す。サーバ・プロキシ・オブジェクト３０５は、サ ーバ・オブジェクト３１３を呼び出してサーバ内のターゲット・オブジェクト５ １の記憶場所を判断する。サーバ・オブジェクトは、この情報をネーム・サーバ ３１７から入手する。ネーム・サーバの機能はオブジェクト名が与えられた場合 に記憶場所を示すことである。その機能はＵＮＩＸオペレーティング・システム 環境の業者には周知である。サーバ・オブジェクト３１３は、サーバ・プロキシ ・オブジェクト３０５に対してターゲット・オブジェクト５１の記憶場所を示す 。次にクライアント・アドレス空間５３内にターゲット・オブジェクト５１のプ ロキシ・オブジェクト４９が作成される 。そうすると、ローカル・クライアント・アプリケーションは、ローカル・プロ キシ・オブジェクト４９に対して、リモート・ターゲット・オブジェクト５１で あるかのようにメソッド呼出しを行うことができる。ＤＳＯＭは、そのメソッド 呼出しをサーバ・アドレス空間５４に渡し、そこでターゲット・オブジェクト５ １に対してメソッド呼出しが行われ、その結果がローカル・クライアント・アプ リケーションに返される。 サーバまたはクライアントあるいはその両方の役割を果たすどのシステム上で も、「ｓｏｍｄｄ」と呼ばれる別個のデーモン・プロセス３４１がアクティブに なっていなければならない。このプロセスは、サーバ・プロセスの開始、常時使 用可能でなければならないサービスの提供、およびクライアント・プロセスとサ ーバ・プロセスとの間のバインディングの作成の際の手段となる。「デーモン・ プロセス」という用語とその機能は、ＵＮＩＸオペレーティング・システム環境 の業者には周知であろう。このデーモン・プロセスは本発明ではこれ以上の役割 を果たさない。 ＤＳＯＭ環境に必要な２つの追加の機能がある。それは、インタフェース・リ ポジトリ３２１とインプリメンテーション・リポジトリ３３１である。 インタフェース・リポジトリ３２１は、オブジェクト・インタフェース定義を 記憶するデータベースである。インタフェース・リポジトリにはクラス・インタ フェース定義（メソ ッドのパラメータと戻り値）が登録される。インタフェース・リポジトリは本発 明では役割を果たさない。インプリメンテーション・リポジトリには、サーバ・ インプリメンテーションとそれがサポートするクラスが登録される。すなわち、 サーバおよびクラスと、ＤＳＯＭがオブジェクト・サーバを見つけ出して起動す るのに必要な属性（サーバ・プログラム名、サーバがあるマシンのホスト名など ）がインプリメンテーション・リポジトリに登録される。 持続性 持続オブジェクトとは、そのオブジェクトに付随する属性が不揮発性記憶装置 に記憶され、それを作成したプロセスが終了した後でも使用可能なオブジェクト である。持続性でないオブジェクトは、そのオブジェクトの属性に付随する属性 が不揮発性記憶域に記憶されておらず、そのオブジェクトを作成したプロセスが 終了した後は使用することができない。サーバがクラッシュした場合、非持続性 オブジェクトは復元されないが、持続性オブジェクトはサーバが回復可能なサー バであれば復元され、したがって誤動作が起こった後でも再始動される。 サーバ誤動作 第２図を参照すると、サーバ５４が誤動作した場合、サーバ・アドレス空間５ ４にあるターゲット・オブジェクト５１ を指すクライアント・アドレス空間５３にあるプロキシ・オブジェクト４９内の 参照は無効になる。サーバ５４はクライアント・アプリケーション（第１図の４ ８）がオブジェクトを使用することができるようにオブジェクトをメモリに再ロ ードする。サーバ５４は、誤動作が起こる前にロードされていた場所とは異なる 場所にあるメモリにオブジェクト５１を再ロードすることができる。オブジェク ト５１が特にクライアント・アプリケーション（第１図の４８）の要求によって ロードされていた場合、すなわち持続オブジェクトでない場合、サーバ５４はオ ブジェクト５１をメモリに再ロードすることがまったくできない。このいずれの 状況でも、サーバ５４内のターゲット・オブジェクト５１を指すプロキシ・オブ ジェクト４９内に含まれる参照は無効になる。プロキシ・オブジェクト４９を使 用すると、参照されているオブジェクトが誤ったオブジェクトであることなどを 示すエラー条件になる。オブジェクト要求ブローカの実施態様によっては、これ によってサーバ内のメモリの破壊や、サーバをさらに再始動させる必要があるサ ーバの誤動作など、重大な影響が生じる可能性がある。 クライアント・アプリケーション４８は、そのプロキシ・オブジェクト４９の うちの１つまたは複数が無効になったことを示すエラー条件を受け取った場合、 以下のステップのいずれかを実行する必要がある。 Ａ．ターゲット・オブジェクト５１が持続オブジェクトでな かった場合、クライアント・アプリケーション４８はサーバ５４内に新しいター ゲット・オブジェクト５１を作成する必要がある。クライアント・アプリケーシ ョン４８はサーバ・プロキシ・オブジェクト３０５を呼び出し、作成するオブジ ェクトのクラスを指定して新しいターゲット・オブジェクト５１を作成するよう に要求する。サーバ・プロキシ・オブジェクト３０５はサーバ・オブジェクト３ １３を呼び出し、サーバ５４内のターゲット・オブジェクト５１の記憶場所を判 断する。サーバ・オブジェクト３１３はターゲット・オブジェクト５１の記憶場 所をサーバ・プロキシ・オブジェクト３０５に送る。次に、クライアント・アド レス空間５３内にターゲット・オブジェクト５１のプロキシ・オブジェクト４９ が作成される。プロキシ・オブジェクト４９には、ターゲット・オブジェクト５ １を見つけることできるサーバ５４のメモリ内の場所を指す参照が含まれる。 Ｂ．ターゲット・オブジェクトが持続性だった場合、クライアント・アプリケー ション４８はターゲット・オブジェクト５１が入っているサーバ５４のメモリ内 の場所を指す参照を含む新しいプロキシ・オブジェクト４９を作成する必要があ る。 サーバ５４が誤動作した場合、上記のステップを行うことによって、クライア ント・アドレス空間５３にあるプロキシ・オブジェクト４９からターゲット・サ ーバ５４にあるすべてのターゲット・オブジェクト５１を指すすべての参照をリ フレッシュしなければならない可能性が高い。これは、典型的なクライアント・ アプリケーション４８にとって重大な作業である。クライアント・アプリケーシ ョン４８は、アドレス空間全体の様々な場所にあるプロキシ・オブジェクト４９ を指すポインタを持っており、以下のタスクを行う必要がある。 １．サーバ５４の誤動作の前にはターゲット・オブジェクト５１を指す有効な参 照であったが今は無効になっているサーバ５４内の記憶場所を指す参照を含む古 いプロキシ・オブジェクト４９を破棄する必要がある。 ２．古い各プロキシ・オブジェクトに対応する新しいプロキシ・オブジェクト４ ９を作成する必要がある。これらの新しいプロキシ・オブジェクト４９は、それ に含まれている参照が、サーバ５４が誤動作後に再始動されたために得られたサ ーバ５４内のターゲット・オブジェクト５１を指す有効な参照である点を除けば 、古いプロキシ・オブジェクトに対応している。 ３．クライアント・アドレス空間５３にあるプロキシ・オブジェクト４９を指す クライアント・アプリケーション内のすべてのポインタは、ステップ１で破棄さ れており、ステップ２で作成されたそれに対応する新しいプロキシ・オブジェク ト４９を指すポインタに更新する必要がある。このステップでは、そのポインタ を更新する必要のあるアプリケーションに固有の知識が必要である。 サーバが誤動作した場合、サーバにあるターゲット・オブジェクトを指す、ク ライアントにあるプロキシ・オブジェクト内の参照は無効になる。リモート・サ ーバがもはや存在しないため、クライアントが無効な参照を使用しようとすると オブジェクト要求ブローカはタイムアウト・エラーを発生させる。 無効なプロキシ・オブジェクトの使用の防止 ＤＳＯＭフレームワークを使用して実施されたサーバはすべてサーバ・オブジ ェクトを持っており、着信メッセージはすべてそのサーバ・オブジェクトに対し て送られる。このオブジェクトはそのメッセージをその実際の宛先にディパッチ する。この実際の宛先は同じＤＳＯＭサーバ内の別のオブジェクトである。無効 なプロキシ・オブジェクトの使用を防止する方法は、ＤＳＯＭサーバがプロキシ ・オブジェクトに付随するタイムスタンプを調べてＤＳＯＭサーバ自体に付随す るタイムスタンプと突き合わせする何らかの基本検査を行い、ＤＳＯＭに付随す るタイムスタンプがプロキシ・オブジェクトに付随するタイムスタンプより遅い 場合はエラー条件を返すことである。同様の検査は、他のオブジェクト要求ブロ ーカを使用するシステムでも行うことができる。 これらの検査によって、エラーが発生したことと、プロキシ・オブジェクト内 に含まれる参照が無効であることは検出されるが、そのエラーを修正する方法に はならない。参照は 、クライアント・アプリケーションに入っているプロキシ・オブジェクト内の参 照を修正するアプリケーション固有の知識とコードを使用して修正することがで きる。 「Ｏｂｊｅｃｔ ｒｅｐｌａｃｅｍｅｎｔ ｕｓｉｎｇ ｄｙｎａｍｉｃ ｐ ｒｏｘｙ ｕｐｄａｔｅｓ」（Ｓ．Ｍｅｎｏｎ，Ｒ．Ｊ．ＬｅＢｌａｎｃ Ｊｒ 、Ｄｉｓｔ．Ｓｙｓｔ．Ｅｎｇｎｇ１（１９９４）ｐｐ．２７１−２７９）では 、ターゲット・オブジェクトを指すプロキシ・オブジェクト参照が無効であるこ とを示すエラーを受け取ると、プロキシ・オブジェクトがネーム・サーバに対し て更新された参照を要求するオブジェクト置換方式が開示されている。低水準事 象を使用してエラーを検出し、プロキシ・オブジェクトを更新する。このオブジ ェクト置換方式は特にＣｌｏｕｄｓ分散オペレーティング・システムと共に使用 するものである。記載されている方式はその他のオペレーティング・システムや オブジェクト要求ブローカ一般では機能しない。発明の開示 したがって本発明は、クライアント・アドレス空間にある回復可能プロキシ・ オブジェクトがサーバ・アドレス空間内のターゲット・オブジェクトを指すポイ ンタを有し、前記プロキシ・オブジェクトにターゲット・オブジェクトの名前と 、プロキシ・オブジェクトの妥当性に関する標識と、前記ターゲット・オブジェ クトの代替プロキシとを格納するステッ プと、前記プロキシ・オブジェクトがそれ自体を、前記プロキシ・オブジェクト を指す参照ポインタを維持するプロキシ・レジスタ・オブジェクトに登録するス テップと、前記ターゲット・オブジェクトの各呼出しの前に前記プロキシ・オブ ジェクトがプロキシ・オブジェクトの妥当性を検査するステップと、前記検査に 応答して、有効な場合はプロキシ・オブジェクトを使用し、無効な場合は代替プ ロキシを使用するステップと、前記サーバ・アドレス空間における誤動作に応答 して、前記プロキシ・レジスタ・オブジェクトが前記プロキシ・オブジェクトの それぞれに前記サーバ内のターゲット・オブジェクトの有効な代替プロキシを入 手させ、前記プロキシ・オブジェクトが無効であることを示させ、有効な代替プ ロキシを指すポインタを記憶させるステップとを特徴とする、分散オブジェクト 指向コンピューティングの方法を提供する。 第１の実施例では、サーバ・アドレス空間とクライアント・アドレス空間が双 方向通信リンクによってリンクされ、サーバ・オブジェクトがクライアント・ア プリケーションに対して、サーバ・アドレス空間内にあるターゲット・オブジェ クトの有効な代替プロキシを入手することによって各プロキシ・オブジェクトを リフレッシュするように要求する。 第２の実施例では、クライアント・アプリケーションは、サーバ・アドレス空 間にあるターゲット・オブジェクトにアクセスする際にエラー標識を受け取ると 、サーバ・アドレス 空間にあるターゲット・オブジェクトの有効代替プロキシを入手することによっ て各プロキシ・オブジェクトをリフレッシュする。 分散オブジェクト指向システムはＣＯＲＢＡ準拠システムであり、分散オブジ ェクト指向コンピュータ・システムはＤＳＯＭクラス・ライブラリを使用するこ とが好ましい。しかし、本発明はそのようなシステムでの応用やそのようなクラ ス・ライブラリの使用には限定されない。たとえば、分散オブジェクト指向シス テムはマイクロソフトのコンポーネント・オブジェクト・モデル（ＣＯＭ）に準 拠していてもよい。また、分散オブジェクト環境（ＤＯＥ）としてＳｕｎＳｏｆ ｔから、およびＯＲＢプラスとしてヒューレット・パッカードＣｏ．から入手可 能な、分散オブジェクト管理機能（ＤＯＭＦ）を使用することもできる。 本発明は、クライアント・アドレス空間内のプロキシ・オブジェクトがサーバ ・アドレス空間内のターゲット・オブジェクトを指す一次ポインタを有し、それ によってプロキシ・オブジェクトに対する呼出しの結果、対応するターゲット・ オブジェクトが呼び出される分散オブジェクト指向コンピューティングの方法で あって、サーバ・アドレス空間における誤動作に応答して、前記ターゲット・オ ブジェクトの再配置を引き起こすステップと、再配置されたターゲット・オブジ ェクトを指すように前記プロキシ・オブジェクトを回復するステップとを含み、 前記各プロキシ・オブジェクトに前記ア ドレス空間内のネーム・サーバから前記再配置されたターゲット・オブジェクト を指す有効な代替ポインタを入手させ、記憶させるステップと、前記一次ポイン タが無効であり、前記代替ポインタを使用すべきであることを示す妥当性フラグ を前記プロキシ・オブジェクト内に作成するステップとをさらに含み、それによ ってプロキシ・オブジェクトに対する呼出しの結果として該当するターゲット・ オブジェクトが呼び出されることを特徴とする方法も提供する。 分散オブジェクト指向コンピュータ・システムがＤＳＯＭクラス・ライブラリ を使用する好ましい実施例では、回復可能プロキシ・オブジェクトはＳＯＭＤＣ ｌｉｅｎｔｐｒｏｘｙのサブクラスであり、ＤＳＯＭは通信機構である。サブク ラス（または子クラス）はそのスーパークラス（または親クラス）からすべての 属性とメソッドを継承する。ＳＯＭＤＣｌｉｅｎｔＰｒｏｘｙはＤＳＯＭの一部 として事前定義されたオブジェクト・クラスである。さらに、プロキシ・レジス タ・オブジェクトはメタクラスＳＯＭＭＳｉｎｇｌｅＩｎｓｔａｎｃｅを持つＳ ＯＭオブジェクトであることが好ましい。これは、プロキシ・レジスタ・オブジ ェクトがクラスのメンバであり、そのクラス自体がメタクラスＳＯＭＭＳｉｎｇ ｌｅＩｎｓｔａｎｃｅから派生していることを意味する。このメタクラスによっ て、そのメタクラスから派生した各クラスの単一のインスタンスだけが作成され るように保証される。このようにして派生したクラスのインスタンスをさらに作 成する要求を行っても、すでに作成済みのインスタンスを指すポインタが返され るだけである。 本発明は、１つまたは複数のプロキシ・オブジェクトを有し、サーバ・アドレ ス空間とクライアント・アドレス空間を含む分散オブジェクト指向コンピュータ ・システムも提供する。サーバ・アドレス空間は、アドレス空間内にあり、クラ イアント・アプリケーションがそれに対して操作を行うことができるターゲット ・オブジェクトと、クライアント・アドレス空間内のクライアント・アプリケー ションとの通信を可能にするオブジェクト要求ブローカと、クライアント・アプ リケーションからの要求に応答するサーバ・オブジェクトとを有する。クライア ント・アドレス空間は、アドレス空間内にあり、クライアント・アドレス空間に ある１つまたは複数のオブジェクトに対して操作を行うクライアント・アプリケ ーションと、サーバ・アドレス空間内のオブジェクトとの通信を可能にするオブ ジェクト要求ブローカと、各プロキシ・オブジェクトがサーバ・アドレス空間内 のターゲット・オブジェクトの場所を指すポインタを含む１つまたは複数のプロ キシ・オブジェクトとを有する。 このシステムは、１つまたは複数のプロキシ・オブジェクトのそれぞれが、サ ーバ・アドレス空間にあるターゲット・オブジェクトの名前と、ターゲット・オ ブジェクトを指す代替ポインタと、ターゲット・オブジェクトを参照するために プロキシと代替ポインタのどちらを使用すべきかを示す妥当 性フラグとをさらに含むことを特徴とする。クライアント・アドレス空間は、ク ライアント・アドレス空間内にあるプロキシ・オブジェクトを指す参照ポインタ を維持するプロキシ・レジスタ・オブジェクトと、サーバ・アドレス空間におけ る誤動作の後に１つまたは複数のプロキシ・オブジェクトを更新する手段とをさ らに含む。図面の簡単な説明 以下に本発明の実施例について例として添付図面を参照しながら説明する。 第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブロ ーカを示すブロック図である。 第２図は、従来技術のＤＳＯＭ環境を示すブロック図である。 第３図は、本発明と共に使用するのに適した従来技術のコンピュータ・システ ムを示す図である。 第４図は、第１図のクライアント／サーバ環境にある、本発明によるプロキシ ・オブジェクトとプロキシ・レジスタ・オブジェクトを示す図である。 第５図は、第１図のクライアント／サーバ環境で使用される従来技術のプロキ シ・オブジェクトの構築を示す図である。 第６図は、第８図および第９図のクライアント／サーバ環境で使用する、本発 明によるプロキシ・オブジェクトの構築 を示す図である。 第７図は、第６図により構築されたプロキシ・オブジェクトを示す図である。 第８図は、クライアントとサーバの間に双方向リンクを有するシステムにおい て実施された、本発明による回復可能プロキシ・オブジェクトの第１の実施例を 含むクライアント／サーバ環境を示す図である。 第９図は、クライアントとサーバの間に双方向通信リンクを持たないシステム において実施された、本発明による回復可能プロキシ・オブジェクトの第２の実 施例を含むクライアント／サーバ環境を示す図である。発明の詳細な説明 本発明を実施することができる適合するハードウェア 本発明は、いくつかの異なるオペレーティング・システム下にある様々なコン ピュータまたはコンピュータの集合上で実行することができる。コンピュータは 、たとえばパーソナル・コンピュータ、ミニ・コンピュータ、メインフレーム・ コンピュータ、または他のコンピュータの分散ネットワーク内で稼働するコンピ ュータとすることができる。特定のコンピュータの選定はメモリおよびディスク の必要記憶容量によってのみ限定されるが、本発明ではＩＢＭ ＰＳ／２シリー ズのコンピュータを使用することができる（ＩＢＭはIBM Corporationの登録商 標であり、ＰＳ／２は商標である）。ＩＢ ＭのＰＳ／２シリーズ・コンピュータの詳細については、Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ Ｐｅｒｓｏｎａｌ Ｓｙｓｔｅｍ／２（Ｍ ｏｄｅｌ ８０）（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ Ｐａｒｔ Ｎｏ．６８Ｘ ２２５６ Ｏｒｄｅｒ Ｎｕｍｂｅｒ Ｓ６８Ｘ−２２５４）を参照されたい 。ＩＢＭ ＰＳ／２パーソナル・コンピュータで実行することができるオペレー ティング・システムはＩＢＭのＯＳ／２ ２．０であり、ＩＢＭ ＯＳ／２ ２ ．０オペレーティング・システムの詳細については、ＯＳ／２ ２．０ Ｔｅｃ ｈｎｉｃａｌ Ｌｉｂｒａｒｙ，Ｐｒｏｇｒａｍｍｉｎｇ Ｇｕｉｄｅ Ｖｏｌ ．１，２，３ Ｖｅｒｓｉｏｎ ２．００（Ｏｒｄｅｒ Ｎｏｓ．１０Ｇ６２６ １，１０Ｇ６４９５、１０Ｇ６４９４）を参照されたい（ＯＳ／２はIBM Corpor ationの商標である）。 代替実施例では、コンピュータ・システムはＡＩＸオペレーティング・システ ム上で稼働するＩＢＭ ＲＩＳＣ Ｓｙｓｔｅｍ／６０００ラインのコンピュー タとすることができる（ＲＩＳＣ Ｓｙｓｔｅｍ／６０００およびＡＩＸはIBM Corporationの商標である）。ＲＩＳＣ Ｓｙｓｔｅｍ／６０００の様々なモデ ルについては、たとえばＲＩＳＣ Ｓｙｓｔｅｍ／６０００，７０７３および７ ０１６ ＰＯＷＥＲｓｔａｔｉｏｎ ａｎｄ ＰＯＷＥＲｓｅｒｖｅｒ Ｈａｒ ｄｗａｒｅ Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃｅ（Ｏｒｄｅｒ Ｎｏ．Ｓ Ａ２３−２６４４−００）など、IBM Corp orationの多くの刊行物に記載されている（ＰＯＷＥＲｓｔａｔｉｏｎおよびＰ ＯＷＥＲｓｅｒｖｅｒはIBM Corporationの商標である）。ＡＩＸオペレーティ ング・システムについては、Ｇｅｎｅｒａｌ Ｃｏｎｃｅｐｔｓ ａｎｄ Ｐｒ ｏｃｅｄｕｒｅ−−ＡＩＸ Ｖｅｒｓｉｏｎ３ ｆｏｒ ＲＩＳＣ Ｓｙｓｔｅ ｍ／６０００（Ｏｒｄｅｒ Ｎｏ．ｓｃ２３−２２０２−００）およびIBM Corp orationのその他の刊行物に記載されている。 第３図には、システム・ユニット１１と、キーボード１２と、マウス１３と、 表示装置１４を含むコンピュータ１０のブロック図が図示されている。システム ・ユニット１１は、１本または複数のシステム・バス２１を含み、システム・バ スには様々な構成要素が接続され、それによって様々な構成要素間の通信を行う 。マイクロプロセッサ２２がシステム・バス２１に接続され、やはりシステム・ バス２１に接続された読取り専用メモリ（ＲＯＭ）２３とランダム・アクセス・ メモリ（ＲＡＭ）２４によってサポートされている。ＩＢＭ ＰＳ／２シリーズ のコンピュータのマイクロプロセッサは、３８６または４８６マイクロプロセッ サを含むインテル・ファミリのマイクロプロセッサのうちの１つである。しかし 、６８０００、６８０２０、または６８０３０マイクロプロセッサなどのモトロ ーラのマイクロプロセッサ・ファミリや、ＰｏｗｅｒＰＣチップなどのＩＢＭ製 の様々な縮小命令セット・コンピュータ（ＲＩＳＣ）マイクロプロセッサその他 のマイクロプロセッサ、またはヒューレット・パッカード、サン、モトローラお よびその他のマイクロプロセッサなど、他のマイクロプロセッサもこの特定のコ ンピュータで使用することができる。 ＲＯＭ２３は、基本的ハードウェア動作を制御する基本入出力システム（ＢＩ ＯＳ）も含む。ＲＡＭ２４は、オペレーティング・システムとアプリケーション ・プログラムがロードされるメイン・メモリである。メモリ管理チップ２５がシ ステム・バス２１に接続され、ＲＡＭ２４とハードウェア・ディスク・ドライブ ２６とフロッピィ・ディスク・ドライブ２７との間のデータの受渡しを含む直接 メモリ・アクセス操作を制御する。システム・バス２１にはＣＤ ＲＯＭ３２も 結合され、たとえばマルチメディア・プログラムやプレゼンテーションなど大量 のデータを記憶するために使用される。 このシステム・バス２１には、様々な入出力コントローラ、キーボード・コン トローラ２８、マウス・コントローラ２９、ビデオ・コントローラ３０、および オーディオ・コントローラ３１も接続される。当然ながら、キーボード・コント ローラ２８はキーボード１２のハードウェア・インタフェース、マウス・コント ローラ２９はマウス１３のハードウェア・インタフェース、ビデオ・コントロー ラ３０は表示装置１４のハードウェア・インタフェース、オーディオ・コントロ ーラ３１はスピーカ１５ａおよび１５ｂのハードウェア・インタフェース機能を 備える。トークン・リンク・アダプタな どの入出力コントローラ４０によって、他の同様に構成されたデータ処理システ ムとネットワーク４６を介して通信することができる。 本発明の好ましい実施例の１つは、大体上述のように構成された１つまたは複 数のコンピュータ・システムのランダム・アクセス・メモリ２４に入っている１ 組の命令４８〜５２としての実施態様である。この１組の命令は、コンピュータ ・システムが必要とするまで、たとえばハードウェア・ディスク・ドライブ２６ 、または最終的にＣＤ−ＲＯＭ３２で使用される光ディスクまたは最終的にフロ ッピィ・ディスク・ドライブ２７で使用されるフロッピィ・ディスクなどの取り 外し可能メモリなど、別のコンピュータ・メモリに記憶することができる。ＯＲ Ｂを使用して相互に結合されるメモリ・アドレス空間は、ネットワーク４６を介 して通信する別々のシステムに存在することもでき、第３図に示すように１つの コンピュータ・システムのメモリ内の２つ以上のアドレス空間５３、５４とする こともできる。 本発明の要素 本発明は、回復可能プロキシ・オブジェクトを設け、それによってクライアン トにある古いプロキシ・オブジェクトを指すクライアント・アプリケーション内 のすべてのポインタをクライアントにある新しいプロキシ・オブジェクトを指す 新しいポインタに置き換える代わりに、クライアント内の各 プロキシ・オブジェクトに対してそれ自体を妥当性検査し直すように求めること によって、前述の従来技術のクライアント／サーバ環境の問題点を克服する。こ のような再妥当性検査は、クライアント・アプリケーション固有の知識またはコ ードをまったく必要としない。回復可能プロキシ・オブジェクトは、クライアン トの所にあり、リモート・サーバ内にあるオブジェクトを指すすべてのプロキシ ・オブジェクトを指すポインタを維持する「プロキシ・レジスタ」オブジェクト にそれ自体を登録する。回復可能プロキシ・オブジェクトは、回復不能プロキシ ・オブジェクトには存在しない３つの属性を含む。この３つの属性とは、プロキ シ・オブジェクトが指すターゲット・オブジェクトの「名前」と、プロキシ・オ ブジェクトが有効なオブジェクトを指しているかどうかを示すフラグと、代替プ ロキシを指すポインタである。 以下に、本発明の一部として使用するプロキシ・レジスタ・オブジェクトにつ いて、第４図および例１を参照しながら説明する。次に、本発明の一部として使 用するプロキシ・オブジェクトについて第５図、第６図、および例２を参照しな がら説明する。その後で、そのようなプロキシ・オブジェクトの初期設定につい て第７図を参照しながら説明する。 非同期的に動作し、プロキシ・レジスタ・オブジェクトとプロキシ・オブジェ クトが組み込まれた本発明の第１の実施例について、第８図を参照しながら説明 する。次に、同期的に動作する第２の実施例について第９図を参照しながら説明 する。その後で、ＤＳＯＭプロキシ・オブジェクトによるリモート・サーバへの 従来技術のメソッド呼出しのディスパッチについて、例３を参照しながら説明す る。さらに、本発明による、ＤＳＯＭプロキシによるリモート・サーバへのメソ ッド呼出しのディスパッチについて例４を参照しながら説明する。 プロキシ・レジスタ・オブジェクト 第４図に、周知のクライアント・アプリケーション４８と周知のターゲット・ オブジェクト５１と周知のＯＲＢ５０、５２を有する、クライアント・アドレス 空間５３とサーバ・アドレス空間５４を示す。任意選択として、クライアント・ アドレス空間５３とサーバ・アドレス空間５４の間に双方向通信リンク４６０を 備えることができる。そのようなリンク４６０がない場合、サーバはクライアン ト・アプリケーション４８に要求を送ることができない。オブジェクト名を示す とメモリ・アドレスを出力する機能を持つネーム・サーバ３１７を備える。第４ 図には、本発明で使用するプロキシ・レジスタ・オブジェクト１５５も図示され ている。プロキシ・レジスタ・オブジェクト１５５は、回復可能プロキシ・オブ ジェクト４４９が作成されると、回復可能プロキシ・オブジェクト４４９からそ れ自体を登録する要求を受け取る。プロキシ・レジスタ・オブジェクト１５５は 、クライアント・アプリケーション４８がプロキシ・オブジェクト４４９をリフ レッシュしたい場合にも要求を受け取る（第８図の５２０）。どの１つのクライ アント・アドレス空間５３内にも１つのプロキシ・レジスタ・オブジェクト１５ ５しか入っていない。これは、ＳＯＭのＳＯＭＭＳｉｎｇｌｅＩｎｓｔａｎｃｅ メタクラスを使用することによって実現される。このメタクラスによって、メタ クラスから派生した各クラスの１つのインスタンスだけが作成されるように保証 される。このようにして派生したクラスのインスタンスをさらに作成する要求を 出しても、すでに作成されているインスタンスを指すポインタが返されるだけで ある。 プロキシ・レジスタ・オブジェクトに対して行うことができるメソッドは以下 の３つである。 １．所与のサーバ名のプロキシ・オブジェクトをすべてリフレッシュする。これ は、その所与のサーバが再始動され、そのサーバ内の場所を指すプロキシ・オブ ジェクト参照が無効になっている可能性があることをクライアントが認識すると 、クライアントによって使用される。 ２．プロキシ・レジスタ・オブジェクトによって維持されているリストにプロキ シ・オブジェクトを追加する。これは、プロキシ・オブジェクトが指すターゲッ ト・オブジェクトが入っているサーバが再始動された場合、プロキシ・オブジェ クトがそれ自体をリフレッシュするように求められるようにするために、プロキ シ・オブジェクトが作成された後でそのプロキシ・オブジェクトが使用する。 ３．プロキシ・レジスタ・オブジェクトによって維持されているリストからプロ キシ・オブジェクトを削除する。これは、プロキシ・オブジェクトが破棄され、 リフレッシュする必要がなくなった場合に使用される。 例１に、プロキシ・レジスタ・オブジェクトのサンプル宣言を示す。この宣言 は（ＣＯＲＢＡについて言及しながら前述した）ＩＤＬで書かれており、オブジ ェクトが示すインタフェースを定義する。ＩＤＬでは、「／／」はそれに続くテ キストが注釈であることを意味する。「ｖｏｉｄ」はＣ言語の場合と同じ意味を 持つ。すなわち値を返さないものを定義するものである。例１−プロキシ・レジスタ・オブジェクトのサンプル宣言 例１の終わり プロキシ・オブジェクト 第５図に、クラスＡｎｉｍａｌのための従来技術のプロキシ・クラスの構築を 示す。ＤＳＯＭ、具体的にはＳＯＭＤＯｂｊｅｃｔＭｇｒは、ＤＳＯＭ実行時モ ジュールと共に、Ａｎｉｍａｌ＿Ｐｒｏｘｙ７１０と呼ぶプロキシ・クラスを作 成する。プロキシ・クラスＡｎｉｍａｌ＿Ｐｒｏｘｙ７１０は、クラスＡｎｉｍ ａｌ７２０のインタフェースとＳＯＭＤＣｌｉｅｎｔＰｒｏｘｙ７３０の実現部 とを継承する。この実現部の属性には、リモート・オブジェクトの記憶場所であ るリモート・オブジェクト参照と、リモート・サーバ・バインディングが含まれ る。Ａｎｉｍａｌ＿ｐｒｏｘｙクラス７１０はクラスＡｎｉｍａｌ７２０のメソ ッドを保持し、ＤＳＯＭのデフォルトの方式でリモート・サーバにメソッド呼出 しのディスパッチを行う。詳細は、前掲の「ＳＯＭｏｂｊｅｃｔｓ：Ａ Ｐｒａ ｃｔｉｃａｌ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ ＳＯＭ ａｎｄ ＤＳＯＭ」 の７４〜７５ページに記載されている。ＤＳＯＭのデフォルトの方式でのディス パッチについては、例３を参照しながら後述する。 第６図に、クラスＡｎｉｍａｌ７２０の本発明によるプロキシ・クラスの構築 を示す。Ａｎｉｍａｌ＿Ｐｒｏｘｙオブジェクトがクラス・ライブラリ提供者、 すなわちサーバ・オ ブジェクトの作者によって与えられる。Ａｎｉｍａｌ＿Ｐｒｏｘｙ７１０のプロ キシ・クラスは、クラスＡｎｉｍａｌ＿７２０のインタフェースとＣｕｓｔｏｍ ＿Ｐｒｏｘｙ８４０の実現を継承する。さらにＣｕｓｔｏｍ＿Ｐｒｏｘｙ８４０ の実現はＳＯＭＤＣｌｉｅｎｔＰｒｏｘｙ７３０の実現を継承する。Ｃｕｓｔｏ ｍ＿Ｐｒｏｘｙ８４０実現の属性によって、ＳＯＭＣｌｉｅｎｔＳｅｒｖｅｒ７ ３０の属性にリモート・オブジェクト名４５５と、妥当性フラグ４５９と代替プ ロキシ４５７が加えられる。Ａｎｉｍａｌ＿Ｐｒｏｘｙクラス７１０によって、 Ａｎｉｍａｌ７２０のメソッドが上書きされ、リモート・サーバへのメソッド呼 出しのカスタム・ディスパッチが行われる。このカスタム方式のディスパッチに ついては、例４を参照しながら後述する。 本発明によるプロキシ・オブジェクトは、Ｃｕｓｔｏｍ＿Ｐｒｏｘｙの実現の 継承によって加えられる属性によって従来技術のプロキシ・オブジェクトとは区 別される。リモート・オブジェクト名４５５は、リモート・サーバ内のプロキシ ・オブジェクト４４９が指すオブジェクト（第４図の５１）の名前である。この プロキシが有効であるか、または代替プロキシ４５７を使用すべきかが、妥当性 フラグ４５９によって示される。代替プロキシ４５７には、妥当性フラグ４５９ によってプロキシ自体が無効であることが示された場合に使用する、再配置され たターゲット・オブジェクトを指すポインタが含まれる。 例２にＣｕｓｔｏｍ＿Ｐｒｏｘｙクラスのサンプル宣言を示す。本発明による プロキシ・オブジェクトはすべてこのクラスから導き出される。例２−カスタム・プロキシ・クラスのサンプル宣言 例２の終わり 第７図に、第６図に従って構築されたプロキシ・オブジェクトの初期設定を示 す。クライアント・アプリケーション４８、プロキシ・オブジェクト４４９、プ ロキシ・レジスタ・オブジェクト１５５、およびＯＲＢ５０については、第４図 のクライアント・アドレス空間５３を参照しながら前述している。サーバ３１３ 、ターゲット・オブジェクト５１、ネーム・サーバ３１７、およびＯＲＢ５２に ついても、第１図および第２図のサーバ・アドレス空間５４を参照しながら前述 している。 第７図を参照すると、ステップ９１０で、クライアント・ アプリケーション４８がサーバ３１３に対してオブジェクトを作成する要求を送 る。サーバ３１３はこの要求に応答して、ステップ９２０でオブジェクト５１を 作成する。サーバ３１３はステップ９３０でクライアントにプロキシ・オブジェ クト４４９を返す。ステップ９４０で、プロキシ・オブジェクト４４９はサーバ ・アドレス空間５４内のネーム・サーバ３１７に接触して、サーバ・アドレス空 間５４内に作成された新しいオブジェクト５１の名前（またはハンドル）を入手 する。ステップ９５０で、ネーム・サーバ３１７は名前を返し、プロキシ・オブ ジェクト４４９はその名前４５５を記憶し、妥当性フラグ４５９を真に設定して 代替プロキシ４５７ではなく実プロキシを使用すべきであることを示す。ステッ プ９６０で、プロキシ・オブジェクト４４９はそれ自体をプロキシ・レジスタ・ オブジェクト１５５に登録する。 第１の実施例 第８図に、サーバとそのクライアントとの間に双方向リンクがある本発明の第 １の実施例を示す。サーバは誤動作後に再始動すると、それに接続されていたす べてのクライアントに接触し、それらのクライアントのプロキシ・オブジェクト をリフレッシュするように指示する。クライアント・アプリケーション４８、プ ロキシ・オブジェクト４４９、プロキシ・レジスタ・オブジェクト１５５、およ びＯＲＢ５０については、第４図のクライアント・アドレス空間５３を参照しな がら前述している通りである。サーバ３１３、ターゲット・オブジェクト５１、 ネーム・サーバ３１７、およびＯＲＢ５２は、第２図のサーバ・アドレス空間５ ４を参照しながら前述した通りである。 第８図を参照すると、ステップ５１０で、サーバ３１３はそのクライアント・ アプリケーション４８のそれぞれに対して、誤動作後に再始動したことを通知す る。第８図および第９図には、図を簡単にするために１つのクライアント・アプ リケーション４８しか図示されていないが、実際にはクライアント・アプリケー ション４８は１つでも複数でもよい。ステップ５２０で、クライアント・アプリ ケーション４８がプロキシ・レジスタ・オブジェクト１５５に対して、リモート ・サーバ５４にあるターゲット・オブジェクト５１のプロキシ・オブジェクト４ ４９をすべてリフレッシュするように要求する。ステップ５３０で、プロキシ・ レジスタ・オブジェクト１５５はサーバ５４にあるターゲット・オブジェクト５ １のすべてのプロキシ・オブジェクト４４９に対してそのプロキシ・オブジェク ト４４９自体をリフレッシュするように要求する。ステップ５４０で、各プロキ シ・オブジェクト４４９はリモート・ネーム・サーバ３１７に接触し、パラメー タとしてリモート・オブジェクト名４５５を渡し、リモート・オブジェクト５１ の更新された記憶場所を問い合わせる。ステップ５５０で、オブジェクトが従属 オブジェクトである場合、ネーム・サーバ３１７は渡された名前を持つターゲッ ト・オブジェクト５１を探し出す。オブジェクトが持続オブジェクトでない場合 、ネーム・サーバ３１７はそのオブジェクトを作成する。ステップ５５５で、ネ ーム・サーバ３１７はクライアント・アドレス空間５３にあるプロキシ・オブジ ェクト４４９にリモート・オブジェクト５１の新しい記憶場所を返す。ステップ ５６０で、プロキシ・オブジェクト４４９は妥当性フラグ４５９を偽に設定し、 リモート・オブジェクト５１の新たに供給された記録場所を指すようにその代替 プロキシ・ポインタ４５７を更新する。 第２の実施例 第９図に、サーバとクライアントの間に双方向リンクがない本発明の第２の実 施例を示す。この実施例のクライアントは、「最初の障害時にすべてのプロキシ ・オブジェクトをリフレッシュする」というポリシーを実行しなければならない 。クライアント・アプリケーション４８、プロキシ・オブジェクト４４９、プロ キシ・レジスタ・オブジェクト１５５、およびＯＲＢ５０については、第４図の クライアント・アドレス空間５３を参照しながら前述した通りである。サーバ３ １３、ターゲット・オブジェクト５１、ネーム・サーバ３１７、およびＯＲＢ５ ２についても、第１図および第２図のサーバ・アドレス空間５４を参照しながら 前述した通りである。 第９図を参照すると、ステップ６１０で、プロキシ・オブ ジェクト４４９はデフォルトのディスパッチ方法（例３）を使用してメソッド呼 出しを無効なプロキシを使用しているサーバ３１３にディスパッチしようとする 。この結果、ステップ６２０でサーバ３１３は不正オブジェクト参照例外を返す 。この実施例では、クライアントは「最初の障害時にすべてのプロキシ・オブジ ェクトをリフレッシュする」ポリシーを実行するため、ステップ６３０でプロキ シ・オブジェクト４４９は、プロキシ・レジスタ・オブジェクト１５５に対して リモート・サーバ５４のすべてのプロキシ・オブジェクトをリフレッシュするよ うに要求する。ステップ６４０で、プロキシ・レジスタ・オブジェクト１５５は サーバ５４にあるターゲット・オブジェクト５１のすべてのプロキシ・オブジェ クト４４９にそのプロキシ・オブジェクト４４９自体をリフレッシュするように 指示する。ステップ６５０で、各プロキシ・オブジェクト４４９はリモート・ネ ーム・サーバ３１７に接触し、パラメータとしてその名前を渡し、ターゲット・ オブジェクト５１の更新された記憶場所を問い合わせる。ステップ６６０で、ネ ーム・サーバ３１７は与えられた名前を持つオブジェクト５１を探し出す（また は非持続性の場合には作成する）。ステップ６７０で、ネーム・サーバ３１７は クライアント・アドレス空間５３にあるプロキシ・オブジェクト４４９に新しい プロキシを返す。ステップ６８０で、プロキシはその妥当性フラグ４５９を偽に 設定し、その代替プロキシ・ポインタ４５７を新たに供給されたプロキシを指す ように更新する。ステップ６９０で、プロキシ・オブジェクト４４９はその代替 プロキシ４５７を使用して元の要求をカスタム方式（例４）で再ディスパッチす る。 以降のシステム誤動作 リモート・サーバの誤動作がもう一度発生し、その後で再始動した場合、クラ イアントは第３のプロキシを必要としない。クライアントは代替プロキシ・ポイ ンタによって指されているプロキシを削除し、そのプロキシを新しいプロキシに 置き換える。クライアント・アプリケーションはこれをまったく認識しない。し たがって、クライアントはアクセスする各リモート・オブジェクトについてプロ キシを２つ（１つは無効で１つは有効）持つことになる。クライアントはサーバ よりも存続期間が短い傾向があり、クライアントが再始動するときに無効なプロ キシは消滅しているため、追加の無効なプロキシによるオーバーヘッドは大きく ない。 ディスパッチ ディスパッチは、ＤＳＯＭプロキシ・オブジェクトがメソッド呼出しをリモー ト・サーバにディスパッチするに過ぎない。本発明は、通常のプロキシと代替プ ロキシのどちらを使用するかを判断するために、デフォルトのディスパッチ方法 の変形を必要とする。例３に、従来技術のＤＳＯＭプロキシ・オブジェクトで採 用されているＩＤＬ言語で書かれたデフ ォルトの従来技術のディスパッチ方法を示す。このディスパッチ方法は、ＤＳＯ Ｍフレームワークによって与えられ、プロキシ・オブジェクトの作成時にプロキ シ・オブジェクトによって継承される。例３−デフォルト・ディスパッチ関数の例： 例３の終わり 例４に、本発明により実施されるＤＳＯＭプロキシ・オブジェクトで使用する ディスパッチのカスタマイズされた方法をＩＤＬ言語で示す。本発明によるディ スパッチ方法では、妥当性標識（４５９）の検査による通常のポインタと代替プ ロキシ・ポインタ（４５７）のどちらを使用するかを判断する追加のステップが 含まれる。妥当性フラグ（４５９）を検査し、通常のプロキシ・ポインタが有効 であることを示している場合はそのポインタを使用し、次にメソッドが従来技術 で周知の方式と同じ方式でディスパッチされる。妥当性フラグ（４５９）が、通 常のプロキシ・ポインタが無効であることを示している場合、メソッドは従来技 術で周知の方式と同じ方式でディスパッチされるが、代替プロキシ・ポインタ（ ４５７）が使用される。 さらに、プロキシ・オブジェクトをすべて更新させることによって、不正オブ ジェクト参照のエラー処理を行う。ＤＳＯＭフレームワークが備えるディスパッ チ方法を修正することによってカスタマイズが行われ、プロキシ・オブジェクト の作成時にプロキシ・オブジェクトによって継承される。例４−カスタマイズされたディスパッチ関数の例： 例４の終わり

Claims (1)

1. 【特許請求の範囲】 １．クライアント・アドレス空間（５３）にある回復可能プロキシ・オブジェク ト（４４９）がサーバ・アドレス空間（５４）内のターゲット・オブジェクト（ ５１）を指すポインタを有する分散オブジェクト指向コンピューティングの方法 であって、 前記プロキシ・オブジェクト（４４９）にターゲット・オブジェクト（５１） の名前（４５５）と、前記プロキシ・オブジェクトの妥当性に関する標識（４５ ９）と、前記ターゲット・オブジェクト（５１）の代替プロキシ（４５７）とを 記憶するステップ（９５０）と、 前記プロキシ・オブジェクト（４４９）を指す参照ポインタを維持するプロキ シ・レジスタ・オブジェクト（１５５）に前記プロキシ・オブジェクト（４４９ ）がそれ自体を登録するステップ（９６０）と、 前記ターゲット・オブジェクト（５１）の各呼出しの前に、前記プロキシ・オ ブジェクト（４４９）が該プロキシ・オブジェクト（４４９）の妥当性を検査す るステップと、 前記検査に応答して、有効な場合は前記プロキシ・オブジェクト（４４９）を 使用し、無効な場合は前記代替プロキシ（４５７）を使用するステップと、 前記サーバ・アドレス空間における誤動作に応答して、前記プロキシ・レジス タ・オブジェクト（１５５）が各前記プ ロキシ・オブジェクト（４４９）に、前記サーバ内の前記ターゲット・オブジェ クト（５１）の有効な前記代替プロキシ（４５７）を入手させ（５４０、６５０ ）、前記プロキシ・オブジェクト（４４９）が無効であることを示させ（５６０ 、６８０）、有効な前記代替プロキシ（４５７）を指すポインタを記憶させる（ ５６０、６８０）ステップ（５３０、６４０）とを含む方法。 ２．前記サーバ・アドレス空間（５４）と前記クライアント・アドレス空間（５ ３）とが双方向通信リンク（４６０）によってリンクされ、 前記サーバ・オブジェクト（３１３）が前記クライアント・アプリケーション （４８）に要求（５１０）して前記サーバ・アドレス空間（５４）にある前記タ ーゲット・オブジェクト（５１）の有効な前記代替プロキシ（４５７）を入手す ることによって各前記プロキシ・オブジェクト（４４９）をリフレッシュさせる 、請求項１に記載の方法。 ３．前記クライアント・アプリケーション（４８）が、前記サーバ・アドレス空 間（５４）内にある前記ターゲット・オブジェクト（５１）にアクセスする際に エラー標識を受け取ると、前記サーバ・アドレス空間（５４）内にある前記ター ゲット・オブジェクト（５１）の有効な前記代替プロキシ（４５７）を入手する ことによって各前記プロキシ・オブジェクト（４４９）をリフレッシュさせる、 請求項１に記載の方法。 ４．前記プロキシ・オブジェクト（４４９）をリフレッシュする前記ステップが 、前記クライアント・アプリケーション（４８）に応答して、前記ターゲット・ オブジェクト（５１）が持続オブジェクトでなかった場合に前記サーバ・オブジ ェクト（３１３）を使用して前記ターゲット・オブジェクト（５１）を作成する ステップをさらに含む、請求項２または３に記載の方法。 ５．前記分散オブジェクト指向システムがＣＯＲＢＡ準拠システムである、請求 項１、２、または３のいずれか一項に記載の方法。 ６．前記分散オブジェクト指向コンピュータ・システムがＤＳＯＭクラス・ライ ブラリを使用する、請求項５に記載の方法。 ７．回復可能な前記プロキシ・オブジェクト（４４９）がＳＯＭＤＣｌｉｅｎｔ Ｐｒｏｘｙのサブクラスであり、ＤＳＯＭが通信機構である、請求項６に記載の 方法。 ８．前記プロキシ・レジスタ・オブジェクト（１５５）がメタクラスＳＯＭＭＳ ｉｎｇｌｅＩｎｓｔａｎｃｅを持つＳＯＭオブジェクトである、請求項６に記載 の方法。 ９．クライアント・アドレス空間（５３）内のプロキシ・オブジェクト（４９） がサーバ・アドレス空間（５４）内のターゲット・オブジェクト（５１）を指す 一次ポインタを有し、それによって前記プロキシ・オブジェクトに対する呼出し の結果として対応する前記ターゲット・オブジェクトが呼び 出される分散オブジェクト指向コンピューティングの方法であって、 前記サーバ・アドレス空間における誤動作に応答して、場合によって前記ター ゲット・オブジェクトの再配置を引き起こすステップと、 再配置された前記ターゲット・オブジェクトを指す前記プロキシ・オブジェク トを回復するステップとを含み、 各前記プロキシ・オブジェクトに前記アドレス空間内のネーム・サーバ（３１ ７）から有効な代替ポインタ（４５７）を入手させ、再配置された前記ターゲッ ト・オブジェクト（５１）に記憶させるステップと、 前記プロキシ・オブジェクト内に、前記一次ポインタが無効であって前記代替 ポインタ（４５７）を使用すべきであることを示す妥当性フラグ（４５９）を作 成し、それによって前記プロキシ・オブジェクトに対する呼出しの結果として該 当する前記ターゲット・オブジェクトが呼び出されるステップとをさらに含むこ とを特徴とする方法。 １０．１つまたは複数のプロキシ・オブジェクト（４４９）を有する分散オブジ ェクト指向コンピュータ・システムであって、 アドレス空間内にある、 クライアント・アプリケーション（４８）がそれに対して操作を実行すること ができるターゲット・オブジェクト（５１）と、 クライアント・アドレス空間（５３）内の前記クライアント・アプリケーショ ン（４８）との通信を可能にするオブジェクト要求ブローカ（５２）と、 前記クライアント・アプリケーション（４８）からの要求に応答するサーバ・ オブジェクト（３１３）とを有するサーバ・アドレス空間（５４）と、 アドレス空間内にある、 前記クライアント・アドレス空間（５３）内にある１つまたは複数のオブジェ クト（４４９）に対する操作を行う前記クライアント・アプリケーション（４８ ）と、 前記サーバ・アドレス空間（５４）内のオブジェクト（３１３、５１）との通 信を可能にするオブジェクト要求ブローカ（５０）と、 各前記プロキシ・オブジェクト（４４９）が前記サーバ・アドレス空間（５４ ）内の前記ターゲット・オブジェクト（５１）の場所を指すポインタを含む１つ または複数の前記プロキシ・オブジェクト（４４９）とを有する前記クライアン ト・アドレス空間（５３）とを含み、 前記１つまたは複数の前記プロキシ・オブジェクト（４４９）のそれぞれが、 前記サーバ・アドレス空間（５４）内にある前記ターゲット・オブジェクトの 名前（４５５）と、 前記ターゲット・オブジェクト（５１）を指す代替ポインタ（４５７）と、 前記ターゲット・オブジェクト（５１）を参照するためにプロキシ・オブジェ クト内のポインタと代替ポインタ（４５７）とのいずれを使用すべきかを示す妥 当性フラグ（４５９）とをさらに含むことを特徴とし、 前記クライアント・アドレス空間が、 該クライアント・アドレス空間（５３）内にある前記プロキシ・オブジェクト （４４９）を指す参照ポインタを維持するプロキシ・レジスタ・オブジェクト（ １５５）と、 前記サーバ・アドレス空間（５４）における誤動作後に１つまたは複数の前記 プロキシ・オブジェクト（４４９）を更新する手段をさらに含むシステム。 １１．前記サーバ・アドレス空間（５４）と前記クライアント・アドレス空間（ ５３）とが双方向通信リンク（４６０）によってリンクされ、前記サーバ・オブ ジェクト（３１３）が前記クライアント・アドレス空間に要求して前記サーバ・ アドレス空間（５４）内にある前記ターゲット・オブジェクト（５１）の有効な 代替プロキシ（４５７）を入手することによって各前記プロキシ・オブジェクト （４４９）をリフレッシュさせる、請求項９に記載のシステム。 １２．前記サーバ・アドレス空間（５４）内にある前記ターゲット・オブジェク ト（５１）にアクセスする際にエラー標識を受け取ると、前記クライアント・ア プリケーション（４８）が前記サーバ・アドレス空間（５４）内の前記ターゲッ ト・オブジェクト（５１）の前記有効代替プロキシ（４５７ ）を入手することによって各前記プロキシ・オブジェクト（４４９）をリフレッ シュさせる、請求項９に記載のシステム。 １３．前記システムがＣＯＲＢＡ準拠システムである、請求項９ないし１１のい ずれか一項に記載のシステム。