(57)【特許請求の範囲】
【請求項１】
クライアント・アドレス空間（53）にある回復可能プロキシ・オブジェクト（449）がサーバ・アドレス空間（54）内のターゲット・オブジェクト（51）を指すポインタを有する分散オブジェクト指向コンピューティングの方法であって、
前記プロキシ・オブジェクト（449）にターゲット・オブジェクト（51）の名前（455）と、前記プロキシ・オブジェクトの妥当性に関する標識（459）と、前記ターゲット・オブジェクト（51）の代替プロキシ（457）とを記憶させるステップ（950）と、
前記プロキシ・オブジェクト（449）を指す参照ポインタを維持すると共に、各クライアント・アドレス空間にそれぞれ含まれるプロキシ・レジスタ・オブジェクト（155）に前記プロキシ・オブジェクト（449）を登録させるステップ（960）と、
前記ターゲット・オブジェクト（51）の各呼出しの前に、前記プロキシ・オブジェクト（449）が該プロキシ・オブジェクト（449）の妥当性に関する標識を検査するステップと、
前記検査に応答して、有効な場合は前記プロキシ・オブジェクト（449）を使用し、無効な場合は前記代替プロキシ（457）を使用するステップと、
前記サーバ・アドレス空間における誤動作に応答して、前記プロキシ・レジスタ・オブジェクト（155）が、前記プロキシ・オブジェクト（449）が無効であることを示す（560、680）と共に、各前記プロキシ・オブジェクト（449）に、前記サーバ内の前記ターゲット・オブジェクト（51）の有効な前記代替プロキシ（457）をネーム・サーバから取得させ、記憶された前記代替プロキシ（457）を指すポインタによりターゲット・オブジェクトを使用させる（540、650）ステップとを含む方法。
【請求項２】
前記サーバ・アドレス空間（54）と前記クライアント・アドレス空間（53）とが双方向通信リンク（460）によってリンクされ、
前記サーバ・オブジェクト（313）が前記クライアント・アプリケーション（48）に要求（510）して前記サーバ・アドレス空間（54）にある前記ターゲット・オブジェクト（51）の有効な前記代替プロキシ（457）を取得させることによって各前記プロキシ・オブジェクト（449）をリフレッシュさせる、請求項１に記載の方法。
【請求項３】
前記クライアント・アプリケーション（48）が、前記サーバ・アドレス空間（54）内にある前記ターゲット・オブジェクト（51）にアクセスする際にエラー標識を受け取ると、前記サーバ・アドレス空間（54）内にある前記ターゲット・オブジェクト（51）の有効な前記代替プロキシ（457）を取得させることによって各前記プロキシ・オブジェクト（449）をリフレッシュさせる、請求項１に記載の方法。
【請求項４】
前記プロキシ・オブジェクト（449）をリフレッシュする前記ステップが、前記クライアント・アプリケーション（48）に応答して、前記ターゲット・オブジェクト（51）が持続オブジェクトでなかった場合に前記サーバ・オブジェクト（313）を使用して前記ターゲット・オブジェクト（51）を作成するステップをさらに含む、請求項２または３に記載の方法。
【請求項５】
前記分散オブジェクト指向システムがCORBA準拠システムである、請求項１、２、または３のいずれか一項に記載の方法。
【請求項６】
前記分散オブジェクト指向コンピュータ・システムがDSOMクラス・ライブラリを使用する、請求項５に記載の方法。
【請求項７】
回復可能な前記プロキシ・オブジェクト（449）がSOMDClientProxyのサブクラスであり、DSOMが通信機構である、請求項６に記載の方法。
【請求項８】
前記プロキシ・レジスタ・オブジェクト（155）がメタクラスSOMMSingleInstanceを持つSOMオブジェクトである、請求項６に記載の方法。
【請求項９】
クライアント・アドレス空間（53）内のプロキシ・オブジェクト（49）がサーバ・アドレス空間（54）内のターゲット・オブジェクト（51）を指す一次ポインタを有し、前記一次ポインタによって前記プロキシ・オブジェクトに対する呼出しの結果、対応する前記ターゲット・オブジェクトの呼び出しが実行される分散オブジェクト指向コンピューティングの方法であって、
前記サーバ・アドレス空間における誤動作に応答して、場合によって前記ターゲット・オブジェクトの再配置を引き起こすステップと、再配置された前記ターゲット・オブジェクトを指す前記プロキシ・オブジェクトを、各クライアント・アドレス空間にそれぞれ含まれるプロキシ・レジスタ・オブジェクト（155）を介して回復するステップとを含み、
各前記プロキシ・オブジェクトに前記アドレス空間内のネーム・サーバ（317）により生成される有効な代替プロキシ（457）を取得させ、再配置された前記ターゲット・オブジェクト（51）を記憶させるステップと、
前記プロキシ・オブジェクト内に、前記一次ポインタが無効であって前記代替プロキシ（457）を使用すべきであることを示す妥当性フラグ（459）を作成し、前記妥当性フラグ（459）を判断し、前記プロキシ・オブジェクトに対する呼出しの結果として該当する前記ターゲット・オブジェクトを呼び出すステップとをさらに含むことを特徴とする方法。
【請求項１０】
１つまたは複数のプロキシ・オブジェクト（449）を有する分散オブジェクト指向コンピュータ・システムであって、
アドレス空間内にある、
クライアント・アプリケーション（48）がそれに対して操作を実行することができるターゲット・オブジェクト（51）と、
クライアント・アドレス空間（53）内の前記クライアント・アプリケーション（48）との通信を可能にするオブジェクト要求ブローカ（52）と、
前記クライアント・アプリケーション（48）からの要求に応答するサーバ・オブジェクト（313）とを有するサーバ・アドレス空間（54）と、
アドレス空間にある、前記クライアント・アドレス空間（53）内にある１つまたは複数のオブジェクト（449）に対する操作を行う前記クライアント・アプリケーション（48）と、
前記サーバ・アドレス空間（54）内のオブジェクト（313、51）との通信を可能にするオブジェクト要求ブローカ（50）と、
各前記プロキシ・オブジェクト（449）が前記サーバ・アドレス空間（54）内の前記ターゲット・オブジェクト（51）の場所を指すポインタを含む１つまたは複数の前記プロキシ・オブジェクト（449）とを有する前記クライアント・アドレス空間（53）とを含み、
前記１つまたは複数の前記プロキシ・オブジェクト（449）のそれぞれが、
前記サーバ・アドレス空間（54）内にある前記ターゲット・オブジェクトの名前（455）と、
前記ターゲット・オブジェクト（51）を指すポインタと、
前記ターゲット・オブジェクト（51）を参照するためにプロキシ・オブジェクト内の前記ポインタと代替プロキシ（457）を指すポインタとのいずれを使用すべきかを示す妥当性フラグ（459）とをさらに含むことを特徴とし、
前記クライアント・アドレス空間が、
該クライアント・アドレス空間（53）内にある前記プロキシ・オブジェクト（449）を指す参照ポインタを維持すると共に、各クライアント・アドレス空間にそれぞれ含まれるプロキシ・レジスタ・オブジェクト（155）と、
前記サーバ・アドレス空間（54）における誤動作後に１つまたは複数の前記プロキシ・オブジェクト（449）を更新する手段と、をさらに含むシステム。
【請求項１１】
前記サーバ・アドレス空間（54）と前記クライアント・アドレス空間（53）とが双方向通信リンク（460）によってリンクされ、前記サーバ・オブジェクト（313）が前記クライアント・アドレス空間に要求して前記サーバ・アドレス空間（54）内にある前記ターゲット・オブジェクト（51）の有効な代替プロキシ（457）を取得させることによって各前記プロキシ・オブジェクト（449）をリフレッシュさせる、請求項10に記載のシステム。
【請求項１２】
前記サーバ・アドレス空間（54）内にある前記ターゲット・オブジェクト（51）にアクセスする際にエラー標識を受け取ると、前記クライアント・アプリケーション（48）が前記サーバ・アドレス空間（54）内の前記ターゲット・オブジェクト（51）の前記有効代替プロキシ（457）を取得させることによって各前記プロキシ・オブジェクト（449）をリフレッシュする、請求項10に記載のシステム。
【請求項１３】
前記システムがCORBA準拠システムである、請求項10ないし11のいずれか一項に記載のシステム。
【請求項１４】
クライアント・アドレス空間（53）にある回復可能プロキシ・オブジェクト（449）がサーバ・アドレス空間（54）内のターゲット・オブジェクト（51）を指すポインタを有する分散オブジェクト指向コンピューティングの方法を実行するコンピュータ・プログラムを含むコンピュータ可読記録媒体であって、該コンピュータ・プログラムは、
前記プロキシ・オブジェクト（449）にターゲット・オブジェクト（51）の名前（455）と、前記プロキシ・オブジェクトの妥当性に関する標識（459）と、前記ターゲット・オブジェクト（51）の代替プロキシ（457）とを記憶するステップ（950）と、
前記プロキシ・オブジェクト（449）を指す参照ポインタを維持すると共に、各クライアント・アドレス空間にそれぞれ含まれるプロキシ・レジスタ・オブジェクト（155）に前記プロキシ・オブジェクト（449）がそれ自体を登録するステップ（960）と、
前記ターゲット・オブジェクト（51）の各呼出しの前に、前記プロキシ・オブジェクト（449）が該プロキシ・オブジェクト（449）の妥当性を検査するステップと、
前記検査に応答して、有効な場合は前記プロキシ・オブジェクト（449）を使用し、無効な場合は前記代替プロキシ（457）を使用するステップと、
前記サーバ・アドレス空間における誤動作に応答して、前記プロキシ・レジスタ・オブジェクト（155）が、前記プロキシ・オブジェクト（449）が無効であることを示す（560、680）と共に、各前記プロキシ・オブジェクト（449）に、前記サーバ内の前記ターゲット・オブジェクト（51）の有効な前記代替プロキシ（457）をネーム・サーバから取得させ、記憶された前記代替プロキシ（457）を指すポインタによりによりターゲット・オブジェクトを使用させる（540、650）ステップとをコンピュータに対して実行させる記録媒体。
【請求項１５】
クライアント・アドレス空間（53）内のプロキシ・オブジェクト（49）がサーバ・アドレス空間（54）内のターゲット・オブジェクト（51）を指す一次ポインタを有し、前記一次ポインタによって前記プロキシ・オブジェクトに対する呼出しの結果として対応する前記ターゲット・オブジェクトの呼び出しを実行する分散オブジェクト指向コンピューティングの方法を実行させるためのコンピュータ・プログラムを含むコンピュータ可読記録媒体であって、該コンピュータ・プログラムは、
前記サーバ・アドレス空間における誤動作に応答して、場合によって前記ターゲット・オブジェクトの再配置を引き起こすステップと、
再配置された前記ターゲット・オブジェクトを指す前記プロキシ・オブジェクトを、各クライアント・アドレス空間にそれぞれ含まれるプロキシ・レジスタ・オブジェクト（155）を介して回復するステップとを含み、
各前記プロキシ・オブジェクトに前記アドレス空間内のネーム・サーバ（317）により有効な代替プロキシ（457）を生成し、前記クライアント・アドレス空間に取得させ、再配置された前記ターゲット・オブジェクト（51）を記憶させるステップと、
前記プロキシ・オブジェクト内に、前記一次ポインタが無効であって前記代替プロキシ（457）を指すポインタを使用すべきであることを示す妥当性フラグ（459）を作成し、それによって前記プロキシ・オブジェクトに対する呼出しの結果として該当する前記ターゲット・オブジェクトが呼び出されるステップとをさらに含むことを特徴とする記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
発明の分野
本発明は、コンピュータ化オブジェクト指向技法に関し、具体的には、サーバにあるターゲット・オブジェクトを表すプロキシ・オブジェクトがクライアントにあり、プロキシ・オブジェクトがサーバの障害後に回復可能な、前記技法で使用するプロキシ・オブジェクトに係わる。
【０００２】
【従来の技術】
発明の背景
オブジェクト指向プログラミングの概要
オブジェクト指向プログラミングが開発される以前に、構造化プログラミングと呼ばれるプログラミングの一形態が開発され、今でも広く使用されている。この技法では、まずさまざまな関数を定義し、次にプログラムがその定義された関数を適切な時点で呼び出してアプリケーション・プログラムの全体的な目的を実現することから成る。このような関数は、データを操作するために使用するメソッドを定義するが、データ自体は定義しない。構造化プログラミングはモジュール化手法の機会をもたらした。これは、メンテナンスやデバッグが難しい「スパゲッティ・コード」を克服する重要な改良であった。それにもかかわらず、構造化プログラミングには、プログラムによってモデル化される世界における概念および実体と、プログラミング言語における概念との間の「意味ギャップ」や、プログラム・コードのテキスト性、コード・モジュールの再使用可能性の限界などいくつかの欠点も残されている。
【０００３】
その後、オブジェクト指向プログラミングと呼ばれる新しいプログラミング・パラダイムが開発された。この技法では、関数を定義する代わりに、「クラス」を定義する。クラス定義によって、そのクラスの任意のインスタンスが実行することができるメソッドと、そのクラスのインスタンスに含まれる属性（またはデータ）とを定義する。オブジェクトはクラスのメンバーであり、クラス定義で定義されているメソッドを実際に実行することができる。オブジェクトは、クラスによって定義された各属性に付随する値を持つ。オブジェクトは、ゼロまたは１個以上の属性を持ち、そのオブジェクトに対して実行するこができるゼロまたは１個以上のメソッドを持つ。
【０００４】
オブジェクトとのインタフェースは、メソッドを介して属性にアクセスすることができる方法である。そのクラスから導き出されるすべてのオブジェクトがそのクラスのインタフェースを共有する。オブジェクトの実現部分はオブジェクトを呼び出すアプリケーションから隠蔽される。オブジェクトへのインタフェースが変わらない限り、アプリケーションに影響を与えることなく実現部分を完全に変えることはできない。
【０００５】
オブジェクトが内部でどのように「見える」か、また内部で何を「行う」かを記述する必要なしにオブジェクトの「外観」を記述するこの技法を単純化した例として、また、そのようなオブジェクト指向プログラミングの重要な利点を例示するための例として、オブジェクト指向手法によってモデル化することができる普通の家庭用トースタを考えてみる。外部「インタフェース」は、トーストの所望の焼き加減を調節するパラメータを本質的に表すつまみと、パンを入れるスロットと、トースタへの挿入とトースタの起動を行うレバーとから成る。重要な概念は、この種の家電製品のエンドユーザはそれを使用するためにトースタの「内部」を知る必要がないことである。たとえば、熱が電気によって供給されるのか、化学薬品やその他の手段によって供給されるのかを知る必要はない。ユーザは上記の外面部と正しくインタフェースするだけでよい。
【０００６】
プログラミングにおけるこの進化の利点は、上記の例を続けて用いると、トースタをモデル化するプログラミング・コードのモジュールであるオブジェクトの設計者が、ユーザにとって内部が見えないために、たとえばユーザがそのオブジェクトを使用する能力に影響を与えることなくトースタの内部要素を改良することに焦点を絞ることができ、効率を向上させることができることである。したがって、より抽象的に言うと、オブジェクト指向技法は本質的に、オブジェクトのインタフェースをオブジェクトの実現部分から分離する利点をもたらすものと見なすことができる。ソフトウェア環境においては、それによって、外部の「つまみ」などやその予想される動作が変わらない限り、アプリケーション・プログラム全体を書き直さなくてもオブジェクトの内部を書き直し、改良することができる。
【０００７】
本発明の理解を助けるオブジェクト技法に関するその他の一般的背景については、デイビッドA.テイラー（David  A.Taylor）による「Object  Oriented  Technology−Ａ  Manager's  Guide」（copyright  1990,Servio  Corporation）を参照されたい。
【０００８】
オブジェクト指向プログラミングの発展に伴い、様々な組織やソフトウェア会社によっていくつかの「オブジェクト・モデル」がさらに改良され、開発された。オブジェクトとその外部インタフェースを定義する方法が規定され、そのような様々なオブジェクト・モデルによって特にカプセル化と継承の特性が規定された。ある程度の高レベルから見れば、これらの様々なオブジェクト・モデルはきわめて類似している。たとえば、システム・オブジェクト・モデル（SOM）、コモンLispオブジェクト・システム（CLOS）、Smalltalk、およびＣ＋＋などがある。本質的には、これらの様々なオブジェクト・モデルはオブジェクトが何かであるかという問いに答える規則の集まりに過ぎず、より低レベルで検討するとそれぞれわずかに異なった答えが出る。たとえば、言語構文とカプセル化および継承の機能はオブジェクト・モデルによって異なる。
【０００９】
これらの相違の直接の結果として、異なるオブジェクト指向言語およびオブジェクト・モデルの使用可能性により生じる１つの問題は、そのような言語の混合で書かれたオブジェクト・プログラム間のインターオペラビリティを実現することができないことであった。この問題は、オブジェクト技法の重要な利点の１つであるコードの再使用可能性に悪影響を与える。業界を悩ませるこの問題を解決しようとして、委員会は共通オブジェクト要求ブローカ・アーキテクチャ（CORBA）に到達した。これには標準化インタフェース定義言語（IDL）が含まれていた。業界ではオブジェクトインタフェースをどのように規定するか、すなわち、オブジェクト・インタフェースを定義する標準に関して本質的に合意に達し、その結果、１つのベンダーによって定義されたオブジェクトを他のベンダーが使用することが可能になった。「The  Common  Object  Request  Broker:Architecture  and  Specification」（OMG  Document  Number  91.12.1  Revision1.1）を参照されたい。
【００１０】
オブジェクト要求ブローカ（ORB）
CORBAアーキテクチャで記述されたオブジェクト要求ブローカ（ORB）は、UNIXオペレーティング・システム環境で作業をする人には周知のリモート・プロシージャ・コール（RPC）に似ている（UNIXはX/Open  CO.Ltd.によって独占的にライセンス許諾される商標である）。
【００１１】
従来技術のシステムを第１図および第２図に示す。
【００１２】
第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブローカを示すブロック図である。
【００１３】
第２図は、DSOMと呼ばれる従来技術の環境を示すブロック図である。
【００１４】
第１図は、ORBを含むクライアント／サーバ環境を示す。このORBは２つの部分に分かれており、そのうちの部分50はORBを使用して各クライアントで実行され、部分52はORBをサポートする各サーバで実行される。RPCと同様に、ORBは１つのアドレス空間53で稼働しているクライアント・アプリケーション48が別のアドレス空間54のオブジェクト51と通信することができるようにする機構である。他方のアドレス空間54、すなわちクライアント・アプリケーション48が実行されているアドレス空間と同じアドレス空間53ではないアドレス空間にあるオブジェクト51を「リモート」オブジェクトと呼ぶ。クライアント・アプリケーション48と同じアドレス空間53にあるオブジェクトを「ローカル」オブジェクトと呼ぶ。ORB50は１つのアドレス空間53内のクライアント・アプリケーション48からの呼出しを代行受信し、それをネットワーク・プロトコルにカプセル化し、別のアドレス空間54内のターゲット・オブジェクト51に合わせて呼出しをデコードし、その結果を呼び出し側クライアント・アプリケーション48に返す。これによって、一方のアドレス空間（ローカル）で稼働しているクライアント・アプリケーション48が他方のアドレス空間（リモート）内のオブジェクト51と通信することができる。ORBは、オブジェクト指向プログラミングによって得られる高度の柔軟性と能力を備えるように設計されている点で、RPCが改良されたものである。
【００１５】
「オブジェクト・モデル」は様々な組織やソフトウェア会社によって開発されている。オブジェクト・モデルはオブジェクトとその外部インタフェースの定義の仕方を規定する。このようなオブジェクト・モデルの１つは、IBM Corporationのシステム・オブジェクト・モデル（SOM）である。SOMでは、オブジェクトを使用するすべてのアプリケーションはそれらのオブジェクトが入っている１つのアドレス空間内で実行される。SOM内で作成されるものは、分散システム・オブジェクト・モデル（DSOM）と呼ばれるオブジェクト・クラスのフレームワークである。DSOMでは、１つのアドレス空間内の（クライアントで稼働している）アプリケーションは別のアドレス空間（サーバに属するアドレス空間など）内のオブジェクトにアクセスすることができる。これらのアドレス空間は同じシステムと異なるシステムのどちらにあってもよい。実際には、システムは同じプラットフォームで稼働している必要はない。たとえば、OS/2システム上のアドレス空間で稼働しているクライアント・アプリケーションがAIX/6000システム上のアドレス空間にあるオブジェクトにアクセスすることができ、その逆も可能である。SOMとDSOMの両方については、IBM Corporationが発行している「SOMobject:A  Practical  Introduction  to  SOM  and  DSOM」（Copyright  1994,Order  no.GG24−4357−00）に記載されている。
【００１６】
上記のシステム・オブジェクト・モデル（SOM）は、CORBAとIDLに準拠した１つのオブジェクト・モデルである。準拠とは、SOMオブジェクトがCORBAのセマンティクスに従っており、SOMオブジェクトがIDL構文で定義されているという意味である。
【００１７】
DSOMのフレームワークは、ターゲット・オブジェクトがインスタンス化される場所やプラットフォームのタイプをクライアント・プログラマが知らなくても済むようにするオブジェクト実現部を備える。このプロセス間通信に使用される通信機構は、プログラマには見えないように完全に隠蔽される。
【００１８】
クライアント−サーバ・アーキテクチャ
クライアント−サーバ・アーキテクチャでは、アプリケーション・プログラムは個別の構成要素として実行される個別のタスクに分けられる。各構成要素にはクライアントまたはサーバの役割が割り当てられる。１つの構成要素は、ある目的のためにはサーバの役割を果たし、他の目的のためにはクライアントの役割を果たすことができる。各構成要素は独立して動作し、特定の責任を担う。クライアントの役割が割り当てられた構成要素は、サーバ・プロセス内のオブジェクトに対するメソッド呼出しを行うことによって、サーバにサービスを要求する。サーバの役割が割り当てられた構成要素は、それらのメソッド呼出しを受け取り、該当するオブジェクトに対してそれらのメソッド呼出しを行い、その結果をクライアントに返すことによってサービスを提供する。クライアントとサーバは事前定義されたプロトコルを使用してメッセージを交換する。サーバは多くのクライアントにサービスを提供することができ、クライアントは多くのサーバにサービスを要求することができる。
【００１９】
プロキシ・オブジェクト
プロキシ・オブジェクトとは、リモート・ターゲット・オブジェクトのローカル表現である。プロキシ・オブジェクトはターゲット・オブジェクトのインタフェースを継承し、その結果、同じメソッドに応答する。プロキシ・オブジェクトで呼び出されたメソッドはローカルでは実行されず、実ターゲット・オブジェクトに転送されて実行される。クライアントで稼働しているプログラムは常に、各リモート・オブジェクトが稼働しているサーバ内の各リモート・オブジェクトのローカル・プロキシ・オブジェクトをそのクライアント内に持っている。プロキシ・オブジェクト内には、ターゲット・オブジェクトが入っているサーバ内の記憶場所を指すポインタが含まれている。プロキシ・オブジェクトにはターゲット・オブジェクトの名前は含まれない。プロキシ・オブジェクトは、リモート・サーバに対してリモート・オブジェクトに対するメソッド呼出しの要求が行われると常に、DSOM実行時環境によって作成される。
【００２０】
DSOM環境
クライアント・プロセスはサーバ・プロセス内のオブジェクトについてメソッド呼び出しを行う。これらのメソッド呼び出しは、たとえば属性に付随する値の入手（読取り）や属性に付随する値の設定（書込み）を行うことができる。サーバ・プロセスはこれらのメソッド呼び出しを受け取り、該当するオブジェクトについてそれらを呼び出し、クライアントに結果を返す。第２図にDSOM環境の構成要素の一部の超高水準図を示す。クライアント・アドレス空間53はDSOMオブジェクト・マネージャ303と呼ぶオブジェクトを含む。このオブジェクトは、サーバ・オブジェクト313の（後述する）プロキシ・オブジェクト305を指すポインタを返すことによって、クライアント・アプリケーション（第１図の48）がサーバ54を見つけ出すのを支援する。クライアントは次に、そのサーバ54上で事前定義されているクラスのオブジェクト51のインスタンスを作成したり、そのサーバ上にすでに存在するオブジェクト51へのアクセスを獲得したり、そのサーバ54上のオブジェクト51が不要になった場合にそれを破棄したりするために、サーバ・オブジェクト313に対するメソッドを（そのプロキシ・オブジェクト305を介して）呼び出す。
【００２１】
クライアント・アプリケーション（第１図の48）は、サーバ・プロキシ・オブジェクト305に対して呼出しを行い、メソッド呼出しを行いたいオブジェクト51のある場所を見つけ出す。サーバ・プロキシ・オブジェクト305は、サーバ・オブジェクト313を呼び出してサーバ内のターゲット・オブジェクト51の記憶場所を判断する。サーバ・オブジェクトは、この情報をネーム・サーバ317から入手する。ネーム・サーバの機能はオブジェクト名が与えられた場合に記憶場所を示すことである。その機能はUNIXオペレーティング・システム環境の業者には周知である。サーバ・オブジェクト313は、サーバ・プロキシ・オブジェクト305に対してターゲット・オブジェクト51の記憶場所を示す。次にクライアント・アドレス空間53内にターゲット・オブジェクト51のプロキシ・オブジェクト49が作成される。そうすると、ローカル・クライアント・アプリケーションは、ローカル・プロキシ・オブジェクト49に対して、リモート・ターゲット・オブジェクト51であるかのようにメソッド呼出しを行うことができる。DSOMは、そのメソッド呼出しをサーバ・アドレス空間54に渡し、そこでターゲット・オブジェクト51に対してメソッド呼出しが行われ、その結果がローカル・クライアント・アプリケーションに返される。
【００２２】
サーバまたはクライアントあるいはその両方の役割を果たすどのシステム上でも、「somdd」と呼ばれる別個のデーモン・プロセス341がアクティブになっていなければならない。このプロセスは、サーバ・プロセスの開始、常時使用可能でなければならないサービスの提供、およびクライアント・プロセスとサーバ・プロセスとの間のバインディングの作成の際の手段となる。「デーモン・プロセス」という用語とその機能は、UNIXオペレーティング・システム環境の業者には周知であろう。このデーモン・プロセスは本発明ではこれ以上の役割を果たさない。
【００２３】
DSOM環境に必要な２つの追加の機能がある。それは、インタフェース・リポジトリ321とインプリメンテーション・リポジトリ331である。
【００２４】
インタフェース・リポジトリ321は、オブジェクト・インタフェース定義を記憶するデータベースである。インタフェース・リポジトリにはクラス・インタフェース定義（メソッドのパラメータと戻り値）が登録される。インタフェース・リポジトリは本発明では役割を果たさない。インプリメンテーション・リポジトリには、サーバ・インプリメンテーションとそれがサポートするクラスが登録される。すなわち、サーバおよびクラスと、DSOMがオブジェクト・サーバを見つけ出して起動するのに必要な属性（サーバ・プログラム名、サーバがあるマシンのホスト名など）がインプリメンテーション・リポジトリに登録される。
【００２５】
持続性
持続オブジェクトとは、そのオブジェクトに付随する属性が不揮発性記憶装置に記憶され、それを作成したプロセスが終了した後でも使用可能なオブジェクトである。持続性でないオブジェクトは、そのオブジェクトの属性に付随する属性が不揮発性記憶域に記憶されておらず、そのオブジェクトを作成したプロセスが終了した後は使用することができない。サーバがクラッシュした場合、非持続性オブジェクトは復元されないが、持続性オブジェクトはサーバが回復可能なサーバであれば復元され、したがって誤動作が起こった後でも再始動される。
【００２６】
サーバ誤動作
第２図を参照すると、サーバ54が誤動作した場合、サーバ・アドレス空間54にあるターゲット・オブジェクト51を指すクライアント・アドレス空間53にあるプロキシ・オブジェクト49内の参照は無効になる。サーバ54はクライアント・アプリケーション（第１図の48）がオブジェクトを使用することができるようにオブジェクトをメモリに再ロードする。サーバ54は、誤動作が起こる前にロードされていた場所とは異なる場所にあるメモリにオブジェクト51を再ロードすることができる。オブジェクト51が特にクライアント・アプリケーション（第１図の48）の要求によってロードされていた場合、すなわち持続オブジェクトでない場合、サーバ54はオブジェクト51をメモリに再ロードすることがまったくできない。このいずれの状況でも、サーバ54内のターゲット・オブジェクト51を指すプロキシ・オブジェクト49内に含まれる参照は無効になる。プロキシ・オブジェクト49を使用すると、参照されているオブジェクトが誤ったオブジェクトであることなどを示すエラー条件になる。オブジェクト要求ブローカの実施態様によっては、これによってサーバ内のメモリの破壊や、サーバをさらに再始動させる必要があるサーバの誤動作など、重大な影響が生じる可能性がある。
【００２７】
クライアント・アプリケーション48は、そのプロキシ・オブジェクト49のうちの１つまたは複数が無効になったことを示すエラー条件を受け取った場合、以下のステップのいずれかを実行する必要がある。
A.ターゲット・オブジェクト51が持続オブジェクトでなかった場合、クライアント・アプリケーション48はサーバ54内に新しいターゲット・オブジェクト51を作成する必要がある。クライアント・アプリケーション48はサーバ・プロキシ・オブジェクト305を呼び出し、作成するオブジェクトのクラスを指定して新しいターゲット・オブジェクト51を作成するように要求する。サーバ・プロキシ・オブジェクト305はサーバ・オブジェクト313を呼び出し、サーバ54内のターゲット・オブジェクト51の記憶場所を判断する。サーバ・オブジェクト313はターゲット・オブジェクト51の記憶場所をサーバ・プロキシ・オブジェクト305に送る。次に、クライアント・アドレス空間53内にターゲット・オブジェクト51のプロキシ・オブジェクト49が作成される。プロキシ・オブジェクト49には、ターゲット・オブジェクト51を見つけることできるサーバ54のメモリ内の場所を指す参照が含まれる。
B.ターゲット・オブジェクトが持続性だった場合、クライアント・アプリケーション48はターゲット・オブジェクト51が入っているサーバ54のメモリ内の場所を指す参照を含む新しいプロキシ・オブジェクト49を作成する必要がある。
【００２８】
【発明が解決しようとする課題】
サーバ54が誤動作した場合、上記のステップを行うことによって、クライアント・アドレス空間53にあるプロキシ・オブジェクト49からターゲット・サーバ54にあるすべてのターゲット・オブジェクト51を指すすべての参照をリフレッシュしなければならない可能性が高い。これは、典型的なクライアント・アプリケーション48にとって重大な作業である。クライアント・アプリケーション48は、アドレス空間全体の様々な場所にあるプロキシ・オブジェクト49を指すポインタを持っており、以下のタスクを行う必要がある。
1.サーバ54の誤動作の前にはターゲット・オブジェクト51を指す有効な参照であったが今は無効になっているサーバ54内の記憶場所を指す参照を含む古いプロキシ・オブジェクト49を破棄する必要がある。
2.古い各プロキシ・オブジェクトに対応する新しいプロキシ・オブジェクト49を作成する必要がある。これらの新しいプロキシ・オブジェクト49は、それに含まれている参照が、サーバ54が誤動作後に再始動されたために得られたサーバ54内のターゲット・オブジェクト51を指す有効な参照である点を除けば、古いプロキシ・オブジェクトに対応している。
3.クライアント・アドレス空間53にあるプロキシ・オブジェクト49を指すクライアント・アプリケーション内のすべてのポインタは、ステップ１で破棄されており、ステップ２で作成されたそれに対応する新しいプロキシ・オブジェクト49を指すポインタに更新する必要がある。このステップでは、そのポインタを更新する必要のあるアプリケーションに固有の知識が必要である。
【００２９】
サーバが誤動作した場合、サーバにあるターゲット・オブジェクトを指す、クライアントにあるプロキシ・オブジェクト内の参照は無効になる。リモート・サーバがもはや存在しないため、クライアントが無効な参照を使用しようとするとオブジェクト要求ブローカはタイムアウト・エラーを発生させる。
【００３０】
無効なプロキシ・オブジェクトの使用の防止
DSOMフレームワークを使用して実施されたサーバはすべてサーバ・オブジェクトを持っており、着信メッセージはすべてそのサーバ・オブジェクトに対して送られる。このオブジェクトはそのメッセージをその実際の宛先にディパッチする。この実際の宛先は同じDSOMサーバ内の別のオブジェクトである。無効なプロキシ・オブジェクトの使用を防止する方法は、DSOMサーバがプロキシ・オブジェクトに付随するタイムスタンプを調べてDSOMサーバ自体に付随するタイムスタンプと突き合わせする何らかの基本検査を行い、DSOMに付随するタイムスタンプがプロキシ・オブジェクトに付随するタイムスタンプより遅い場合はエラー条件を返すことである。同様の検査は、他のオブジェクト要求ブローカを使用するシステムでも行うことができる。
【００３１】
これらの検査によって、エラーが発生したことと、プロキシ・オブジェクト内に含まれる参照が無効であることは検出されるが、そのエラーを修正する方法にはならない。参照は、クライアント・アプリケーションに入っているプロキシ・オブジェクト内の参照を修正するアプリケーション固有の知識とコードを使用して修正することができる。
【００３２】
「Object  replacement  using  dynamic  proxy  updates」（S.Menon,R.J.LeBlanc  Jr、Dist.Syst.Engng1（1994）pp.271−279）では、ターゲット・オブジェクトを指すプロキシ・オブジェクト参照が無効であることを示すエラーを受け取ると、プロキシ・オブジェクトがネーム・サーバに対して更新された参照を要求するオブジェクト置換方式が開示されている。低水準事象を使用してエラーを検出し、プロキシ・オブジェクトを更新する。このオブジェクト置換方式は特にClouds分散オペレーティング・システムと共に使用するものである。記載されている方式はその他のオペレーティング・システムやオブジェクト要求ブローカ一般では機能しない。
【００３３】
【課題を解決するための手段】
発明の開示
したがって本発明は、クライアント・アドレス空間にある回復可能プロキシ・オブジェクトがサーバ・アドレス空間内のターゲット・オブジェクトを指すポインタを有し、前記プロキシ・オブジェクトにターゲット・オブジェクトの名前と、プロキシ・オブジェクトの妥当性に関する標識と、前記ターゲット・オブジェクトの代替プロキシとを格納するステップと、前記プロキシ・オブジェクトがそれ自体を、前記プロキシ・オブジェクトを指す参照ポインタを維持するプロキシ・レジスタ・オブジェクトに登録するステップと、前記ターゲット・オブジェクトの各呼出しの前に前記プロキシ・オブジェクトがプロキシ・オブジェクトの妥当性を検査するステップと、前記検査に応答して、有効な場合はプロキシ・オブジェクトを使用し、無効な場合は代替プロキシを使用するステップと、前記サーバ・アドレス空間における誤動作に応答して、前記プロキシ・レジスタ・オブジェクトが前記プロキシ・オブジェクトのそれぞれに前記サーバ内のターゲット・オブジェクトの有効な代替プロキシを入手させ、前記プロキシ・オブジェクトが無効であることを示させ、有効な代替プロキシを指すポインタを記憶させるステップとを特徴とする、分散オブジェクト指向コンピューティングの方法を提供する。
【００３４】
第１の実施例では、サーバ・アドレス空間とクライアント・アドレス空間が双方向通信リンクによってリンクされ、サーバ・オブジェクトがクライアント・アプリケーションに対して、サーバ・アドレス空間内にあるターゲット・オブジェクトの有効な代替プロキシを入手することによって各プロキシ・オブジェクトをリフレッシュするように要求する。
【００３５】
第２の実施例では、クライアント・アプリケーションは、サーバ・アドレス空間にあるターゲット・オブジェクトにアクセスする際にエラー標識を受け取ると、サーバ・アドレス空間にあるターゲット・オブジェクトの有効代替プロキシを入手することによって各プロキシ・オブジェクトをリフレッシュする。
【００３６】
分散オブジェクト指向システムはCORBA準拠システムであり、分散オブジェクト指向コンピュータ・システムはDSOMクラス・ライブラリを使用することが好ましい。しかし、本発明はそのようなシステムでの応用やそのようなクラス・ライブラリの使用には限定されない。たとえば、分散オブジェクト指向システムはマイクロソフトのコンポーネント・オブジェクト・モデル（COM）に準拠していてもよい。また、分散オブジェクト環境（DOE）としてSunSoftから、およびORBプラスとしてヒューレット・パッカードCo.から入手可能な、分散オブジェクト管理機能（DOMF）を使用することもできる。
【００３７】
本発明は、クライアント・アドレス空間内のプロキシ・オブジェクトがサーバ・アドレス空間内のターゲット・オブジェクトを指す一次ポインタを有し、それによってプロキシ・オブジェクトに対する呼出しの結果、対応するターゲット・オブジェクトが呼び出される分散オブジェクト指向コンピューティングの方法であって、サーバ・アドレス空間における誤動作に応答して、前記ターゲット・オブジェクトの再配置を引き起こすステップと、再配置されたターゲット・オブジェクトを指すように前記プロキシ・オブジェクトを回復するステップとを含み、前記各プロキシ・オブジェクトに前記アドレス空間内のネーム・サーバから前記再配置されたターゲット・オブジェクトを指す有効な代替ポインタを入手させ、記憶させるステップと、前記一次ポインタが無効であり、前記代替ポインタを使用すべきであることを示す妥当性フラグを前記プロキシ・オブジェクト内に作成するステップとをさらに含み、それによってプロキシ・オブジェクトに対する呼出しの結果として該当するターゲット・オブジェクトが呼び出されることを特徴とする方法も提供する。
【００３８】
分散オブジェクト指向コンピュータ・システムがDSOMクラス・ライブラリを使用する好ましい実施例では、回復可能プロキシ・オブジェクトはSOMDClientproxyのサブクラスであり、DSOMは通信機構である。サブクラス（または子クラス）はそのスーパークラス（または親クラス）からすべての属性とメソッドを継承する。SOMDClientProxyはDSOMの一部として事前定義されたオブジェクト・クラスである。さらに、プロキシ・レジスタ・オブジェクトはメタクラスSOMMSingleInstanceを持つSOMオブジェクトであることが好ましい。これは、プロキシ・レジスタ・オブジェクトがクラスのメンバであり、そのクラス自体がメタクラスSOMMSingleInstanceから派生していることを意味する。このメタクラスによって、そのメタクラスから派生した各クラスの単一のインスタンスだけが作成されるように保証される。このようにして派生したクラスのインスタンスをさらに作成する要求を行っても、すでに作成済みのインスタンスを指すポインタが返されるだけである。
【００３９】
本発明は、１つまたは複数のプロキシ・オブジェクトを有し、サーバ・アドレス空間とクライアント・アドレス空間を含む分散オブジェクト指向コンピュータ・システムも提供する。サーバ・アドレス空間は、アドレス空間内にあり、クライアント・アプリケーションがそれに対して操作を行うことができるターゲット・オブジェクトと、クライアント・アドレス空間内のクライアント・アプリケーションとの通信を可能にするオブジェクト要求ブローカと、クライアント・アプリケーションからの要求に応答するサーバ・オブジェクトとを有する。クライアント・アドレス空間は、アドレス空間内にあり、クライアント・アドレス空間にある１つまたは複数のオブジェクトに対して操作を行うクライアント・アプリケーションと、サーバ・アドレス空間内のオブジェクトとの通信を可能にするオブジェクト要求ブローカと、各プロキシ・オブジェクトがサーバ・アドレス空間内のターゲット・オブジェクトの場所を指すポインタを含む１つまたは複数のプロキシ・オブジェクトとを有する。
【００４０】
このシステムは、１つまたは複数のプロキシ・オブジェクトのそれぞれが、サーバ・アドレス空間にあるターゲット・オブジェクトの名前と、ターゲット・オブジェクトを指す代替ポインタと、ターゲット・オブジェクトを参照するためにプロキシと代替ポインタのどちらを使用すべきかを示す妥当性フラグとをさらに含むことを特徴とする。クライアント・アドレス空間は、クライアント・アドレス空間内にあるプロキシ・オブジェクトを指す参照ポインタを維持するプロキシ・レジスタ・オブジェクトと、サーバ・アドレス空間における誤動作の後に１つまたは複数のプロキシ・オブジェクトを更新する手段とをさらに含む。
【発明の実施の形態】
発明の詳細な説明
以下に本発明の実施例について例として添付図面を参照しながら説明する。
本発明を実施することができる適合するハードウェア
本発明は、いくつかの異なるオペレーティング・システム下にある様々なコンピュータまたはコンピュータの集合上で実行することができる。コンピュータは、たとえばパーソナル・コンピュータ、ミニ・コンピュータ、メインフレーム・コンピュータ、または他のコンピュータの分散ネットワーク内で稼働するコンピュータとすることができる。特定のコンピュータの選定はメモリおよびディスクの必要記憶容量によってのみ限定されるが、本発明ではIBM  PS/2シリーズのコンピュータを使用することができる（IBMはIBM Corporationの登録商標であり、PS/2は商標である）。IBMのPS/2シリーズ・コンピュータの詳細については、Technical  Reference  Manual  Personal  System/2（Model  80）（IBM  Corporation  Part  No.68X  2256  Order  Number  S68X−2254）を参照されたい。IBM  PS/2パーソナル・コンピュータで実行することができるオペレーティング・システムはIBMのOS/2  2.0であり、IBM  OS/2  2.0オペレーティング・システムの詳細については、OS/2  2.0  Technical  Library,Programming  Guide  Vol.1,2,3  Version  2.00（Order  Nos.10G6261,10G6495、10G6494）を参照されたい（OS/2はIBM Corporationの商標である）。
【００４１】
代替実施例では、コンピュータ・システムはAIXオペレーティング・システム上で稼働するIBM  RISC  System/6000ラインのコンピュータとすることができる（RISC  System/6000およびAIXはIBM Corporationの商標である）。RISC  System/6000の様々なモデルについては、たとえばRISC  System/6000,7073および7016  POWERstation  and  POWERserver  Hardware  Technical  Reference（Order  No.SA23−2644−00）など、IBM Corporationの多くの刊行物に記載されている（POWERstationおよびPOWERserverはIBM Corporationの商標である）。AIXオペレーティング・システムについては、General  Concepts  and  Procedure−−AIX  Version3  for  RISC  System/6000（Order  No.sc23−2202−00）およびIBM Corporationのその他の刊行物に記載されている。
【００４２】
第３図には、システム・ユニット11と、キーボード12と、マウス13と、表示装置14を含むコンピュータ10のブロック図が図示されている。システム・ユニット11は、１本または複数のシステム・バス21を含み、システム・バスには様々な構成要素が接続され、それによって様々な構成要素間の通信を行う。マイクロプロセッサ22がシステム・バス21に接続され、やはりシステム・バス21に接続された読取り専用メモリ（ROM）23とランダム・アクセス・メモリ（RAM）24によってサポートされている。IBM  PS/2シリーズのコンピュータのマイクロプロセッサは、386または486マイクロプロセッサを含むインテル・ファミリのマイクロプロセッサのうちの１つである。しかし、68000、68020、または68030マイクロプロセッサなどのモトローラのマイクロプロセッサ・ファミリや、PowerPCチップなどのIBM製の様々な縮小命令セット・コンピュータ（RISC）マイクロプロセッサその他のマイクロプロセッサ、またはヒューレット・パッカード、サン、モトローラおよびその他のマイクロプロセッサなど、他のマイクロプロセッサもこの特定のコンピュータで使用することができる。
【００４３】
ROM23は、基本的ハードウェア動作を制御する基本入出力システム（BIOS）も含む。RAM24は、オペレーティング・システムとアプリケーション・プログラムがロードされるメイン・メモリである。メモリ管理チップ25がシステム・バス21に接続され、RAM24とハードウェア・ディスク・ドライブ26とフロッピィ・ディスク・ドライブ27との間のデータの受渡しを含む直接メモリ・アクセス操作を制御する。システム・バス21にはCD  ROM32も結合され、たとえばマルチメディア・プログラムやプレゼンテーションなど大量のデータを記憶するために使用される。
【００４４】
このシステム・バス21には、様々な入出力コントローラ、キーボード・コントローラ28、マウス・コントローラ29、ビデオ・コントローラ30、およびオーディオ・コントローラ31も接続される。当然ながら、キーボード・コントローラ28はキーボード12のハードウェア・インタフェース、マウス・コントローラ29はマウス13のハードウェア・インタフェース、ビデオ・コントローラ30は表示装置14のハードウェア・インタフェース、オーディオ・コントローラ31はスピーカ15aおよび15bのハードウェア・インタフェース機能を備える。トークン・リンク・アダプタなどの入出力コントローラ40によって、他の同様に構成されたデータ処理システムとネットワーク46を介して通信することができる。
【００４５】
本発明の好ましい実施例の１つは、大体上述のように構成された１つまたは複数のコンピュータ・システムのランダム・アクセス・メモリ24に入っている１組の命令48〜52としての実施態様である。この１組の命令は、コンピュータ・システムが必要とするまで、たとえばハードウェア・ディスク・ドライブ26、または最終的にCD−ROM32で使用される光ディスクまたは最終的にフロッピィ・ディスク・ドライブ27で使用されるフロッピィ・ディスクなどの取り外し可能メモリなど、別のコンピュータ・メモリに記憶することができる。ORBを使用して相互に結合されるメモリ・アドレス空間は、ネットワーク46を介して通信する別々のシステムに存在することもでき、第３図に示すように１つのコンピュータ・システムのメモリ内の２つ以上のアドレス空間53、54とすることもできる。
【００４６】
本発明の要素
本発明は、回復可能プロキシ・オブジェクトを設け、それによってクライアントにある古いプロキシ・オブジェクトを指すクライアント・アプリケーション内のすべてのポインタをクライアントにある新しいプロキシ・オブジェクトを指す新しいポインタに置き換える代わりに、クライアント内の各プロキシ・オブジェクトに対してそれ自体を妥当性検査し直すように求めることによって、前述の従来技術のクライアント／サーバ環境の問題点を克服する。このような再妥当性検査は、クライアント・アプリケーション固有の知識またはコードをまったく必要としない。回復可能プロキシ・オブジェクトは、クライアントの所にあり、リモート・サーバ内にあるオブジェクトを指すすべてのプロキシ・オブジェクトを指すポインタを維持する「プロキシ・レジスタ」オブジェクトにそれ自体を登録する。回復可能プロキシ・オブジェクトは、回復不能プロキシ・オブジェクトには存在しない３つの属性を含む。この３つの属性とは、プロキシ・オブジェクトが指すターゲット・オブジェクトの「名前」と、プロキシ・オブジェクトが有効なオブジェクトを指しているかどうかを示すフラグと、代替プロキシを指すポインタである。
【００４７】
以下に、本発明の一部として使用するプロキシ・レジスタ・オブジェクトについて、第４図および例１を参照しながら説明する。次に、本発明の一部として使用するプロキシ・オブジェクトについて第５図、第６図、および例２を参照しながら説明する。その後で、そのようなプロキシ・オブジェクトの初期設定について第７図を参照しながら説明する。
【００４８】
非同期的に動作し、プロキシ・レジスタ・オブジェクトとプロキシ・オブジェクトが組み込まれた本発明の第１の実施例について、第８図を参照しながら説明する。次に、同期的に動作する第２の実施例について第９図を参照しながら説明する。その後で、DSOMプロキシ・オブジェクトによるリモート・サーバへの従来技術のメソッド呼出しのディスパッチについて、例３を参照しながら説明する。さらに、本発明による、DSOMプロキシによるリモート・サーバへのメソッド呼出しのディスパッチについて例４を参照しながら説明する。
【００４９】
プロキシ・レジスタ・オブジェクト
第４図に、周知のクライアント・アプリケーション48と周知のターゲット・オブジェクト51と周知のORB50、52を有する、クライアント・アドレス空間53とサーバ・アドレス空間54を示す。任意選択として、クライアント・アドレス空間53とサーバ・アドレス空間54の間に双方向通信リンク460を備えることができる。そのようなリンク460がない場合、サーバはクライアント・アプリケーション48に要求を送ることができない。オブジェクト名を示すとメモリ・アドレスを出力する機能を持つネーム・サーバ317を備える。第４図には、本発明で使用するプロキシ・レジスタ・オブジェクト155も図示されている。プロキシ・レジスタ・オブジェクト155は、回復可能プロキシ・オブジェクト449が作成されると、回復可能プロキシ・オブジェクト449からそれ自体を登録する要求を受け取る。プロキシ・レジスタ・オブジェクト155は、クライアント・アプリケーション48がプロキシ・オブジェクト449をリフレッシュしたい場合にも要求を受け取る（第８図の520）。どの１つのクライアント・アドレス空間53内にも１つのプロキシ・レジスタ・オブジェクト155しか入っていない。これは、SOMのSOMMSingleInstanceメタクラスを使用することによって実現される。このメタクラスによって、メタクラスから派生した各クラスの１つのインスタンスだけが作成されるように保証される。このようにして派生したクラスのインスタンスをさらに作成する要求を出しても、すでに作成されているインスタンスを指すポインタが返されるだけである。
【００５０】
プロキシ・レジスタ・オブジェクトに対して行うことができるメソッドは以下の３つである。
1.所与のサーバ名のプロキシ・オブジェクトをすべてリフレッシュする。これは、その所与のサーバが再始動され、そのサーバ内の場所を指すプロキシ・オブジェクト参照が無効になっている可能性があることをクライアントが認識すると、クライアントによって使用される。
2.プロキシ・レジスタ・オブジェクトによって維持されているリストにプロキシ・オブジェクトを追加する。これは、プロキシ・オブジェクトが指すターゲット・オブジェクトが入っているサーバが再始動された場合、プロキシ・オブジェクトがそれ自体をリフレッシュするように求められるようにするために、プロキシ・オブジェクトが作成された後でそのプロキシ・オブジェクトが使用する。
3.プロキシ・レジスタ・オブジェクトによって維持されているリストからプロキシ・オブジェクトを削除する。これは、プロキシ・オブジェクトが破棄され、リフレッシュする必要がなくなった場合に使用される。
【００５１】
例１に、プロキシ・レジスタ・オブジェクトのサンプル宣言を示す。この宣言は（CORBAについて言及しながら前述した）IDLで書かれており、オブジェクトが示すインタフェースを定義する。IDLでは、「//」はそれに続くテキストが注釈であることを意味する。「void」はＣ言語の場合と同じ意味を持つ。すなわち値を返さないものを定義するものである。
例１−プロキシ・レジスタ・オブジェクトのサンプル宣言
0003595340.tif 000002
例１の終わり
【００５２】
プロキシ・オブジェクト
第５図に、クラスAnimalのための従来技術のプロキシ・クラスの構築を示す。DSOM、具体的にはSOMD_ObjectMgrは、DSOM実行時モジュールと共に、Animal_Proxy710と呼ぶプロキシ・クラスを作成する。プロキシ・クラスAnimal_Proxy710は、クラスAnimal720のインタフェースとSOMDClientProxy730の実現部とを継承する。この実現部の属性には、リモート・オブジェクトの記憶場所であるリモート・オブジェクト参照と、リモート・サーバ・バインディングが含まれる。Animal_proxyクラス710はクラスAnimal720のメソッドを保持し、DSOMのデフォルトの方式でリモート・サーバにメソッド呼出しのディスパッチを行う。詳細は、前掲の「SOMobjects:A  Practical  Introduction  to  SOM  and  DSOM」の74〜75ページに記載されている。DSOMのデフォルトの方式でのディスパッチについては、例３を参照しながら後述する。
【００５３】
第６図に、クラスAnimal720の本発明によるプロキシ・クラスの構築を示す。Animal_Proxyオブジェクトがクラス・ライブラリ提供者、すなわちサーバ・オブジェクトの作者によって与えられる。Animal_Proxy710のプロキシ・クラスは、クラスAnimal720のインタフェースとCustom_Proxy840の実現を継承する。さらにCustom_Proxy840の実現はSOMDClientProxy730の実現を継承する。Custom_Proxy840実現の属性によって、SOMClientServer730の属性にリモート・オブジェクト名455と、妥当性フラグ459と代替プロキシ457が加えられる。Animal_Proxyクラス710によって、Animal720のメソッドが上書きされ、リモート・サーバへのメソッド呼出しのカスタム・ディスパッチが行われる。このカスタム方式のディスパッチについては、例４を参照しながら後述する。
【００５４】
本発明によるプロキシ・オブジェクトは、Custom_Proxyの実現の継承によって加えられる属性によって従来技術のプロキシ・オブジェクトとは区別される。リモート・オブジェクト名455は、リモート・サーバ内のプロキシ・オブジェクト449が指すオブジェクト（第４図の51）の名前である。このプロキシが有効であるか、または代替プロキシ457を使用すべきかが、妥当性フラグ459によって示される。代替プロキシ457には、妥当性フラグ459によってプロキシ自体が無効であることが示された場合に使用する、再配置されたターゲット・オブジェクトを指すポインタが含まれる。
【００５５】
例２にCustom_Proxyクラスのサンプル宣言を示す。本発明によるプロキシ・オブジェクトはすべてこのクラスから導き出される。
例２−カスタム・プロキシ・クラスのサンプル宣言
0003595340.tif 000003
【００５６】
0003595340.tif 000004
例２の終わり
【００５７】
第７図に、第６図に従って構築されたプロキシ・オブジェクトの初期設定を示す。クライアント・アプリケーション48、プロキシ・オブジェクト449、プロキシ・レジスタ・オブジェクト155、およびORB50については、図４図のクライアント・アドレス空間53を参照しながら前述している。サーバ313、ターゲット・オブジェクト51、ネーム・サーバ317、およびORB52についても、第１図および第２図のサーバ・アドレス空間54を参照しながら前述している。
【００５８】
第７図を参照すると、ステップ910で、クライアント・アプリケーション48がサーバ313に対してオブジェクトを作成する要求を送る。サーバ313はこの要求に応答して、ステップ920でオブジェクト51を作成する。サーバ313はステップ930でクライアントにプロキシ・オブジェクト449を返す。ステップ940で、プロキシ・オブジェクト449はサーバ・アドレス空間54内のネーム・サーバ317に接触して、サーバ・アドレス空間54内に作成された新しいオブジェクト51の名前（またはハンドル）を入手する。ステップ950で、ネーム・サーバ317は名前を返し、プロキシ・オブジェクト449はその名前455を記憶し、妥当性フラグ459を真に設定して代替プロキシ457ではなく実プロキシを使用すべきであることを示す。ステップ960で、プロキシ・オブジェクト449はそれ自体をプロキシ・レジスタ・オブジェクト155に登録する。
【００５９】
第１の実施例
第８図に、サーバとそのクライアントとの間に双方向リンクがある本発明の第１の実施例を示す。サーバは誤動作後に再始動すると、それに接続されていたすべてのクライアントに接触し、それらのクライアントのプロキシ・オブジェクトをリフレッシュするように指示する。クライアント・アプリケーション48、プロキシ・オブジェクト449、プロキシ・レジスタ・オブジェクト155、およびORB50については、第４図のクライアント・アドレス空間53を参照しながら前述している通りである。サーバ313、ターゲット・オブジェクト51、ネーム・サーバ317、およびORB52は、第２図のサーバ・アドレス空間54を参照しながら前述した通りである。
【００６０】
第８図を参照すると、ステップ510で、サーバ313はそのクライアント・アプリケーション48のそれぞれに対して、誤動作後に再始動したことを通知する。第８図および第９図には、図を簡単にするために１つのクライアント・アプリケーション48しか図示されていないが、実際にはクライアント・アプリケーション48は１つでも複数でもよい。ステップ520で、クライアント・アプリケーション48がプロキシ・レジスタ・オブジェクト155に対して、リモート・サーバ54にあるターゲット・オブジェクト51のプロキシ・オブジェクト449をすべてリフレッシュするように要求する。ステップ530で、プロキシ・レジスタ・オブジェクト155はサーバ54にあるターゲット・オブジェクト51のすべてのプロキシ・オブジェクト449に対してそのプロキシ・オブジェクト449自体をリフレッシュするように要求する。ステップ540で、各プロキシ・オブジェクト449はリモート・ネーム・サーバ317に接触し、パラメータとしてリモート・オブジェクト名455を渡し、リモート・オブジェクト51の更新された記憶場所を問い合わせる。ステップ550で、オブジェクトが従属オブジェクトである場合、ネーム・サーバ317は渡された名前を持つターゲット・オブジェクト51を探し出す。オブジェクトが持続オブジェクトでない場合、ネーム・サーバ317はそのオブジェクトを作成する。ステップ555で、ネーム・サーバ317はクライアント・アドレス空間53にあるプロキシ・オブジェクト449にリモート・オブジェクト51の新しい記憶場所を返す。ステップ560で、プロキシ・オブジェクト449は妥当性フラグ459を偽に設定し、リモート・オブジェクト51の新たに供給された記録場所を指すようにその代替プロキシ・ポインタ457を更新する。
【００６１】
第２の実施例
第９図に、サーバとクライアントの間に双方向リンクがない本発明の第２の実施例を示す。この実施例のクライアントは、「最初の障害時にすべてのプロキシ・オブジェクトをリフレッシュする」というポリシーを実行しなければならない。クライアント・アプリケーション48、プロキシ・オブジェクト449、プロキシ・レジスタ・オブジェクト155、およびORB50については、第４図のクライアント・アドレス空間53を参照しながら前述した通りである。サーバ313、ターゲット・オブジェクト51、ネーム・サーバ317、およびORB52についても、第１図および第２図のサーバ・アドレス空間54を参照しながら前述した通りである。
【００６２】
第９図を参照すると、ステップ610で、プロキシ・オブジェクト449はデフォルトのディスパッチ方法（例３）を使用してメソッド呼出しを無効なプロキシを使用しているサーバ313にディスパッチしようとする。この結果、ステップ620でサーバ313は不正オブジェクト参照例外を返す。この実施例では、クライアントは「最初の障害時にすべてのプロキシ・オブジェクトをリフレッシュする」ポリシーを実行するため、ステップ630でプロキシ・オブジェクト449は、プロキシ・レジスタ・オブジェクト155に対してリモート・サーバ54のすべてのプロキシ・オブジェクトをリフレッシュするように要求する。ステップ640で、プロキシ・レジスタ・オブジェクト155はサーバ54にあるターゲット・オブジェクト51のすべてのプロキシ・オブジェクト449にそのプロキシ・オブジェクト449自体をリフレッシュするように指示する。ステップ650で、各プロキシ・オブジェクト449はリモート・ネーム・サーバ317に接触し、パラメータとしてその名前を渡し、ターゲット・オブジェクト51の更新された記憶場所を問い合わせる。ステップ660で、ネーム・サーバ317は与えられた名前を持つオブジェクト51を探し出す（または非持続性の場合には作成する）。ステップ670で、ネーム・サーバ317はクライアント・アドレス空間53にあるプロキシ・オブジェクト449に新しいプロキシを返す。ステップ680で、プロキシはその妥当性フラグ459を偽に設定し、その代替プロキシ・ポインタ457を新たに供給されたプロキシを指すように更新する。ステップ690で、プロキシ・オブジェクト449はその代替プロキシ457を使用して元の要求をカスタム方式（例４）で再ディスパッチする。
【００６３】
以降のシステム誤動作
リモート・サーバの誤動作がもう一度発生し、その後で再始動した場合、クライアントは第３のプロキシを必要としない。クライアントは代替プロキシ・ポインタによって指されているプロキシを削除し、そのプロキシを新しいプロキシに置き換える。クライアント・アプリケーションはこれをまったく認識しない。したがって、クライアントはアクセスする各リモート・オブジェクトについてプロキシを２つ（１つは無効で１つは有効）持つことになる。クライアントはサーバよりも存続期間が短い傾向があり、クライアントが再始動するときに無効なプロキシは消滅しているため、追加の無効なプロキシによるオーバーヘッドは大きくない。
【００６４】
ディスパッチ
ディスパッチは、DSOMプロキシ・オブジェクトがメソッド呼出しをリモート・サーバにディスパッチするに過ぎない。本発明は、通常のプロキシと代替プロキシのどちらを使用するかを判断するために、デフォルトのディスパッチ方法の変形を必要とする。例３に、従来技術のDSOMプロキシ・オブジェクトで採用されているIDL言語で書かれたデフォルトの従来技術のディスパッチ方法を示す。このディスパッチ方法は、DSOMフレームワークによって与えられ、プロキシ・オブジェクトの作成時にプロキシ・オブジェクトによって継承される。
【００６５】
例３−デフォルト・ディスパッチ関数の例：
0003595340.tif 000005
例３の終わり
【００６６】
例４に、本発明により実施されるDSOMプロキシ・オブジェクトで使用するディスパッチのカスタマイズされた方法をIDL言語で示す。本発明によるディスパッチ方法では、妥当性標識（459）の検査による通常のポインタと代替プロキシ・ポインタ（457）のどちらを使用するかを判断する追加のステップが含まれる。妥当性フラグ（459）を検査し、通常のプロキシ・ポインタが有効であることを示している場合はそのポインタを使用し、次にメソッドが従来技術で周知の方式と同じ方式でディスパッチされる。妥当性フラグ（459）が、通常のプロキシ・ポインタが無効であることを示している場合、メソッドは従来技術で周知の方式と同じ方式でディスパッチされるが、代替プロキシ・ポインタ（457）が使用される。
【００６７】
さらに、プロキシ・オブジェクトをすべて更新させることによって、不正オブジェクト参照のエラー処理を行う。DSOMフレームワークが備えるディスパッチ方法を修正することによってカスタマイズが行われ、プロキシ・オブジェクトの作成時にプロキシ・オブジェクトによって継承される。
【００６８】
例４−カスタマイズされたディスパッチ関数の例：
0003595340.tif 000006
0003595340.tif 000007
例４の終わり
【図面の簡単な説明】
【図１】第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブローカを示すブロック図である。
【図２】第２図は、従来技術のDSOM環境を示すブロック図である。
【図３】第３図は、本発明と共に使用するのに適した従来技術のコンピュータ・システムを示す図である。
【図４】第４図は、第１図のクライアント／サーバ環境にある、本発明によるプロキシ・オブジェクトとプロキシ・レジスタ・オブジェクトを示す図である。
【図５】第５図は、第１図のクライアント／サーバ環境で使用される従来技術のプロキシ・オブジェクトの構築を示す図である。
【図６】第６図は、第８図および第９図のクライアント／サーバ環境で使用する、本発明によるプロキシ・オブジェクトの構築を示す図である。
【図７】第７図は、第６図により構築されたプロキシ・オブジェクトを示す図である。
【図８】第８図は、クライアントとサーバの間に双方向リンクを有するシステムにおいて実施された、本発明による回復可能プロキシ・オブジェクトの第１の実施例を含むクライアント／サーバ環境を示す図である。
【図９】第９図は、クライアントとサーバの間に双方向通信リンクを持たないシステムにおいて実施された、本発明による回復可能プロキシ・オブジェクトの第２の実施例を含むクライアント／サーバ環境を示す図である。
【図１】
0003595340.tif 000008
【図４】
0003595340.tif 000009
【図２】
0003595340.tif 000010
【図３】
0003595340.tif 000011
【図５】
0003595340.tif 000012
【図６】
0003595340.tif 000013
【図７】
0003595340.tif 000014
【図８】
0003595340.tif 000015
【図９】
0003595340.tif 000016