(57)【要約】【課題】分散オブジェクトを用いたクライアント・サーバ型システムにおいて、一部のハードウェアが停止しても、実行中のソフトウェアを継続実行させ得る方式を提供する。【解決手段】サーバをＯＲＢに登録すると同時に、サーバのミラーを作成するマシン情報をＯＲＢに通知し、ＯＲＢが、指定されたマシン上にサーバのミラーを複数作成すること、およびサーバが何らかの理由で実行を完了できないときに、ＯＲＢが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とし、ＯＲＢが、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返し、クライアントがその実行結果を受け取り、スタブをサーバと思ってアクセスするので、サーバが停止してもクライアントが実行を継続し、分散オブジェクト技術として高信頼化が図れる。【選択図】図４
2007334717.tif 000002
【特許請求の範囲】
【請求項１】
分散オブジェクトを用いたクライアント・サーバ型システムにおいて、一部のハードウェアが何らかの理由により停止した場合であっても、実行中のソフトウェアを継続実行させ得る方式であって、
サーバをＯＲＢに登録すると同時に、該サーバのミラーを作成するマシン情報をＯＲＢに通知するステップ、
前記ＯＲＢが、指定された一または複数のマシン上に前記サーバのミラーを複数作成するステップ、
クライアントが前記サーバを前記ＯＲＢで検索するステップ、
前記ＯＲＢが、前記サーバの、特定のミラーにはよらないスタブを作成するステップ、
前記ＯＲＢが前記スタブヘの参照を前記クライアントヘ返すステップ、
前記クライアントが前記サーバに代えて前記スタブをアクセスするステップ、
前記スタブが、前記クライアントからの前記サーバヘのアクセス要求を前記ＯＲＢへ渡すステップ、
前記ＯＲＢが、前記クライアントからの要求を前記サーバとその全ての前記ミラーに渡すステップ、
前記サーバおよびその前記ミラーが要求を実行するステップ
前記サーバが何らかの理由で実行を完了できないときに、実行を完了できた前記ミラーの少なくとも一が該実行結果を前記ＯＲＢへ返すステップ、
前記ＯＲＢが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものを前記スタブヘ返すステップ、
前記ＯＲＢが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すステップ、
前記クライアントが前記スタブから実行結果を受け取るステップ、
前記クライアントが前記スタブをサーバと思ってアクセスするステップ、
前記スタブが前記クライアントからの前記サーバヘのアクセス要求を前記ＯＲＢへ渡すステップ、
前記ＯＲＢが、前記クライアントからの要求を生きているミラーに渡すステップ、
前記生きているミラーが要求を実行するステップ、
実行を完了できた前記ミラーが実行結果を前記ＯＲＢへ返すステップ、そして
前記ＯＲＢが、前記ミラーからの実行結果を受け取り、正しいものを前記スタブヘ返し、前記クライアントが、前記スタブから実行結果を受け取ることができ、前記サーバが停止しても前記クライアントが実行を継続するステップ
からなることを特徴とする分散オブジェクトの高信頼化方式。
【請求項２】
分散オブジェクトを用いたクライアント・サーバ型システムにおいて、一部のハードウェアが何らかの理由により停止した場合であっても、実行中のソフトウェアを継続実行させ得る方式であって、
サーバをＯＲＢに登録すると同時に該サーバのミラーを作成するマシン情報をＯＲＢに通知するステップであって、
・前記サーバを新ＯＲＢに登録すると同時に該サーバのミラーを作成するマシン情報を新ＯＲＢに通知し、
・前記新ＯＲＢは前記サーバを旧ＯＲＢに登録し、
前記ＯＲＢが、指定された一または複数のマシン上に前記サーバのミラーを複数作成するステップであって、
・前記新ＯＲＢは指定されたマシン上にサーバのミラーを作成し、
・前記新ＯＲＢは作成したミラーを前記旧ＯＲＢに登録し、
クライアントが前記サーバをＯＲＢで検索するステップであって、
・前記クライアントが前記サーバを前記新ＯＲＢで検索し、
・前記新ＯＲＢが前記サーバおよびそのミラーを前記旧ＯＲＢで検索し、
前記ＯＲＢが、前記サーバの、特定のミラーにはよらないスタブを作成するステップであって、
・前記旧ＯＲＢは前記サーバおよび複数の前記ミラーの個別の旧スタブを作成し、
・前記旧ＯＲＢは前記旧スタブの参照を前記新ＯＲＢへ通知し、
・前記新ＯＲＢは特定のミラーにはよらないサーバのスタブを作成し、
前記新ＯＲＢが前記スタブヘの参照を前記クライアントヘ返すステップであって、
・前記新ＯＲＢは前記新スタブヘの参照を前記クライアントヘ返すステップ、
前記クライアントは前記新スタブをサーバと思ってアクセスし、前記新スタブは前記クライアントからのサーバヘのアクセス要求を前記新ＯＲＢへ渡すステップ、
前記新ＯＲＢは、前記クライアントからの要求を、前記旧スタブと前記旧ＯＲＢを介してサーバとその全てのミラーに渡すステップであって、
・前記新ＯＲＢは前記クライアントからの要求を前記旧スタブヘ渡し、
・前記旧スタブは前記クライアントからの要求を前記旧ＯＲＢへ渡し、
・前記旧ＯＲＢは、クライアントからの要求を前記サーバや前記ミラーに渡し、
前記サーバおよびそのミラーが要求を実行するステップ、
前記サーバが何らかの理由で実行を完了できないときには、実行を完了できたミラーが実行結果を前記旧ＯＲＢへ返すステップ、
前記旧ＯＲＢが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返すステップであって、
・前記旧ＯＲＢは実行結果を旧スタブヘ返し、
・前記旧スタブはそれぞれの実行結果を前記新ＯＲＢへ返し、
・前記新ＯＲＢは前記各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を前記新スタブヘ返し、
前記新ＯＲＢが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すステップ、そして
前記クライアントが新スタブから実行結果を受け取るステップ
からなることを特徴とする分散オブジェクトの高信頼化方式。
【請求項３】
分散オブジェクトを用いたクライアント・サーバ型システムにおいて、
サーバをＯＲＢに登録すると同時に、該サーバのミラーを作成するマシン情報をＯＲＢに通知し、該ＯＲＢが、指定されたマシン上に前記サーバのミラーを作成し、クライアントが前記サーバを前記ＯＲＢで検索し、
前記ＯＲＢが、前記サーバの、特定のミラーにはよらないスタブを作成し、前記ＯＲＢが前記スタブヘの参照を前記クライアントヘ返し、該クライアントが前記サーバに代えて前記スタブをアクセスし、
前記スタブが、前記クライアントからの前記サーバヘのアクセス要求を前記ＯＲＢへ渡し、該ＯＲＢが、前記クライアントからの要求を前記サーバとその全ての前記ミラーに渡し、前記サーバおよびその前記ミラーが要求を実行し、
前記サーバが何らかの理由で実行を完了できないときに、実行を完了できた前記ミラーの少なくとも一が該実行結果を前記ＯＲＢへ返し、該ＯＲＢが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものを前記スタブヘ返し、
前記クライアントが前記スタブから実行結果を受け取り、前記クライアントが前記スタブをサーバと思ってアクセスし、前記スタブが前記クライアントからの前記サーバヘのアクセス要求を前記ＯＲＢへ渡し、該ＯＲＢが、前記クライアントからの要求を生きているミラーに渡し、該生きているミラーが要求を実行し、
実行を完了できた前記ミラーが実行結果を前記ＯＲＢへ返し、該ＯＲＢが、前記ミラーからの実行結果を受け取り、正しいものを前記スタブヘ返し、前記クライアントが、前記スタブから実行結果を受け取ることができ、前記サーバが停止しても前記クライアントが実行を継続する分散オブジェクトの高信頼化方式において、
前記ＯＲＢが、指定された一または複数のマシン上に前記サーバのミラーを複数作成し、
また前記サーバが何らかの理由で実行を完了できないときに、前記ＯＲＢが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とする分散オブジェクトの高信頼化方式。
【請求項４】
分散オブジェクトを用いたクライアント・サーバ型システムにおいて、
サーバをＯＲＢに登録すると同時に該サーバのミラーを作成するマシン情報をＯＲＢに通知するに際し、前記サーバを新ＯＲＢに登録すると同時に該サーバのミラーを作成するマシン情報を新ＯＲＢに通知し、前記新ＯＲＢは前記サーバを旧ＯＲＢに登録し、
前記新ＯＲＢは指定されたマシン上にサーバのミラーを作成し、前記新ＯＲＢは作成したミラーを前記旧ＯＲＢに登録し、クライアントが前記サーバをＯＲＢで検索するに際し、前記クライアントが前記サーバを前記新ＯＲＢで検索し、前記新ＯＲＢが前記サーバおよびそのミラーを前記旧ＯＲＢで検索し、
前記ＯＲＢが、前記サーバの、特定のミラーにはよらないスタブを作成し、前記旧ＯＲＢは前記サーバおよび複数の前記ミラーの個別の旧スタブを作成し、前記旧ＯＲＢは前記旧スタブの参照を前記新ＯＲＢへ通知し、前記新ＯＲＢは特定のミラーにはよらないサーバのスタブを作成し、前記新ＯＲＢが前記スタブヘの参照を前記クライアントヘ返すに際し、前記新ＯＲＢは前記新スタブヘの参照を前記クライアントヘ返し、前記クライアントは前記新スタブをサーバと思ってアクセスし、前記新スタブは前記クライアントからのサーバヘのアクセス要求を前記新ＯＲＢへ渡し、
前記新ＯＲＢは、前記クライアントからの要求を、前記旧スタブと前記旧ＯＲＢを介してサーバとその全てのミラーに渡すに際し、前記新ＯＲＢは前記クライアントからの要求を前記旧スタブヘ渡し、前記旧スタブは前記クライアントからの要求を前記旧ＯＲＢへ渡し、前記旧ＯＲＢは、クライアントからの要求を前記サーバや前記ミラーに渡し、前記サーバおよびそのミラーが要求を実行し、前記サーバが何らかの理由で実行を完了できないときには、実行を完了できたミラーが実行結果を前記旧ＯＲＢへ返し、前記旧ＯＲＢが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返すに際し、前記旧ＯＲＢは実行結果を旧スタブヘ返し、前記旧スタブはそれぞれの実行結果を前記新ＯＲＢへ返し、前記新ＯＲＢは前記各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を前記新スタブヘ返し、
前記クライアントが新スタブから実行結果を受け取る分散オブジェクトの高信頼化方式において、
前記ＯＲＢが、指定された一または複数のマシン上に前記サーバのミラーを複数作成し、
前記新ＯＲＢが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とする分散オブジェクトの高信頼化方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散オブジェクトを用いたクライアント・サーバ型システムにおいて、サーバの可用性を向上させる方式に関し、詳細には、何らかの理由で一部のハードウェアが停止した場合でも、実行中のソフトウェアを継続実行させ得る方式に関する。
【背景技術】
【０００２】
クライアント・サーバ型ソフトウェアは、例えば銀行のオンラインシステムや、Ｗｅｂにおけるオンライン取引を行うシステムの実現のために数多く用いられている。大規模オンラインシステムや、サーバシステムなどの情報システムは、その一時的な停止でさえも人間生活に大きな影響を与えるようになってきている。そのため、それらのシステムの信頼性を向上させることは大変に重要である。現在でも、いくつかの方法で信頼性を向上させる努力がなされている。
【０００３】
銀行のオンラインシステム等のような情報システムは、ソフトウェアとそれを実行するための計算機のハードウェアから構成されるが、計算機のハードウェアは、その安定性を向上させるために、これまで様々な努力がなされてきた。ハードウェアモジュールの２重化や、システムを稼働させたままでモジュールを入れ替えるホツトスワツプ機能などが、その例である。
【０００４】
しかしながら、いくら安定したハードウェアシステムであれ、１００％停止させないで実行を継続させることは不可能である。例えば、システムの保守のための停止は必要不可欠であり、また、停電や地震などの外部要因によるハードウェアの停止は、単一のハードウェア白身の信頼性の向上のみでは防ぐことのできない問題である。
【０００５】
このような停止の際に問題となるのは、ハードウェアが停止した際には、そこで実行されているソフトウェアも停止しまうことである。組み込み型のソフトウェアを別にして、ソフトウェアとハードウェアはもともと独立して存在しているものであるから、例えば、実行中のソフトウェアを他の計算機に移動させることができれば、実行を継続できるはずでる。
【０００６】
そこで、何らかの理由でハードウェアが停止した場合でも、実行中のソフトウェアを継続実行させる方式が必要となるが、そのために現在用いられている代表的な方式が、ハードディスクのミラーリング、フォールト・トーレラント・コンピュータ（ＦＴＣ）、およびサーバのクラスタリングである。
【０００７】
ハードディスクのミラーリングは、データを書き込む際に、同一のデータを複数のハードディスクに同時に書き込むことにより信頼性を向上させる方式である。このため、一つのハードディスクに障害が起きた場合でも複数のディスクが全部故障しない限り、データが保障される。
【０００８】
またＦＴＣでは、対故障性を高めるために、コンピュータを構成する各モジュールを冗長化（多重化）構成にしている。これにより、ひとつのモジュールが故障しても冗長化したモジュールで実行を継続することができる。
【０００９】
サーバのクラスタリング方式は、複数のサーバとなるコンピュータを相互接続することでクラスタを構成し、一つのコンピュータのように振舞わせる。現在、実用レベルに達しているものに、汎用的なクラスタリングシステムやＷｅｂアプリケーション専用のクラスタリングシステムなどがある。サーバのクラスタリングの実装方式はいくつかあるが、標準的な方式では、クラスタ内のサーバの中で、主系となるものが通常時はアプリケーションを実行し、他のサーバは待機系として主系のサーバを監視しており、主系に障害が起こったと判断した時は、待機系が主系となってアプリケーションを実行する。
【００１０】
しかしながら、ハードディスクのミラーリングでは、何か障害が発生した場合、データに関する信頼性は向上するが、処理の継続性が保証されないという問題がある。従って、ミラーリングだけでは、システムの信頼性を向上させるためには不十分で、他の方式と共に用いられることが多い。
【００１１】
ＦＴＣでは、各々のコンピュータの対故障性は向上させることができるものの、高価な専用ハードウェアが必要になる。また、最近は負荷分散のために分散システムを用いることも多く、分散システム全体の可用性の向上にはコストが掛かり過ぎて向いていない。また停電やサーバの定期保守などの際には、１台しかないサーバの停止に伴い、システム全体が停止してしまうという問題もある。
【００１２】
一方、サーバのクラスタリングでは、ＦＴＣとは異なり、停電や定期保守の際にも別の場所の別のサーバを使用してシステムの実行を継続できるという利点があるが、サーバに不具合が発生した場合、ロールバック、即ち停止した処理の再実行が発生してしまうという問題がある。サーバのクラスタリングでは、サーバアブリケーションを実行するサーバマシンごとに複製を作成することになる。言わば、アプリケーションレベルのクラスタリングである。従って、あるサーバマシン上で問題が発生すると、別のサーバマシンにアプリケーションごと切り替わるため、問題が発生したサーバマシン上で実行途中であった処理は失われてしまい、切り替わったサーバマシン上で再実行が必要となってしまう。しかも、そのロールバックは、アプリケーション単位で行われるため、再実行が必要となる処理が大きくなってしまうという問題がある。
【特許文献１】特開２００６−１４６５８０号
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、上述した従来の問題点に鑑みてなしたもので、既存のアプリケーションレベルでのクラスタリングと異なり、オブシェクトレベルでのミラーリングを提案するものである。オブジェクトのミラーリングには、以下の３つの目的がある。
【００１４】
すなわち、これまでの方式では、ＲＡＩＤシステムやＦＴＣなどの特定のハードウェアを必要とする場合が多いが、オブジェクトのミラーリングでは、特定のハードウェアに依存しない高可用性システムを構築することを第１の目的とする。
【００１５】
また、アプリケーションのクラスタリングでは、サーバの切り替えの際に、ロールバックが発生することが問題であることは上述の通りであるが、オブジェクトのミラーリングでは、アプリケーションレベルではなく、より細粒度のオブジェクトレベルで多重化を図るだけでなく、ＦＴＣのようにオブジェクトを冗長構成として並列実行することにより、ロールバック作業ならびに切り替え作業を不要にすることを第２の目的とする。
【００１６】
さらに、アブリケーションレベルの粒度の大きなクラスタリングでは、クラスタリングするアプリケーションには手を加えないでそのまま多重化できるという利点があり、その一方ではオブジェクトレベルで細粒度の多重化を行う場合には、オブジェクト自身やそれを使用するアプリケーションに何らかの変更を加える必要が発生してしまう可能性がある。そこで、アプリケーションのクラスタリングと同様に、多重化されるオブジェクトや、それを使用するシステムに対しては、多重化のための変更を特に行う必要がないようにすることを第３の目的とする。
【課題を解決するための手段】
【００１７】
本発明は、既存のアプリケーションレベルでのクラスタリングと異なり、オブシェクトレベルでのミラーリングを提案するものである。
【００１８】
以下、分散オブジェクト技術の概要と、分散オブジェクトのミラーリングの概要について述べるが、次のような用語の使い分けを行う。或るオブジェクトが他のオブジェクトのメソッドを呼び出している場合、呼び出す側のオブジェクトをクライアント、呼び出される側のオブジェクトをサーバという。オブジェクトのサーバと計算機のサーバを区別するため、計算機のサーバに言及する必要がある場合は、サーバマシンという。また、あるオブジェクトのメソッドをネットワーク越しに他のホスト上のオブジェクトから呼び出すことができる時、そのメソッドをリモートメソッドという。リモートメソッドを含むオブジェクトをリモートオブジェクトあるいはリモートサーバという。
【００１９】
分散オブジェクト技術の概要について説明する。近年、クライアント・サーバ型システムは、ＲＭＩやＣＯＲＢＡ等の分散オブジェクト技術を用いて実装することが多くなった。これは、クライアントとサーバ間での通信処理をＴＣＰ／ＩＰ等を用いて直接実装するよりも、ＲＭＩやＣＯＲＢＡを用いて実装することにより、開発効率が向上するだけでなく、汎用性の高い方式で実装できるからである。
【００２０】
これらの分散オブジェクト技術を利用してクライアント・サーバ型のシステムを開発する際には、Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ（ＯＲＢ）と呼ばれるミドルウエアを使用することが一般的である。ＯＲＢには大分して２つの役割がある。まず、クライアントが自分とは離れたホスト上に存在するリモートサーバを検索する時に使用される。また。見つかったリモートサーバに対するメソッドの呼び出しや、その結果の受け取りもＯＲＢを経由して行われる。
【００２１】
現在では、数種類の分散オブジェクト技術が存在するが、それらは異なるＯＲＢを提供している。ＲＭＩやＣＯＲＢＡなどの分散オブジェクト技術でも、独自のＯＲＢを使用している。最近では、異なるＯＲＢ間の通信プロトコルを定めたＩＩＯＰも開発されているので、異なるＯＲＢ間での互換性も少しずつではあるが、実現されつつある。ＲＭＩやＣＯＲＢＡ、ＲＭＩ−ＩＩＯＰといった標準的なＯＲＢの他にも、ＨＯＲＢ、Ｖｏｙａｇｅｒなどの数多くのＯＲＢが開発され、提供されている。
【００２２】
これらの分散オブジェクト技術に共通する点は、図１に示す標準的分散オブジェクトモデルの通り、サーバ側とクライアント側にそれぞれ独自の代理オブジェクトを用いることである。これをＪａｖａ（登録商標）言語での実装を例にとって説明する。
【００２３】
Ｊａｖａ（登録商標）においては、ＲＭＩを代表とし、ＣＯＲＢＡのＪａｖａ（登録商標）での実装であるＪａｖａ（登録商標）ｌＤＬや、ＲＭＩ−ＩＩＯＰ、ＨＯＲＢなどが全てこの形式をとっている。代理オブジェクトの名称は、それぞれの方式において異なってはいるが、多くの場合、クライアント側の代理オブジェクトをスタブ、サーバ側の代理オブジェクトをスケルトンと呼ぶ。通常、スタブやスケルトンはＯＲＢ側が提供するツールによってクライアントやサーバのコードから自動生成されるため、クライアントやサーバの開発者が自分で記述する必要はない。そのため、スタブやスケルトンはＯＲＢの一部としての機能も持つことが多い。
【００２４】
クライアント側とサーバ側にそれぞれ代理オブジェクトを置くモデルでは、クライアントとサーバ自身は、自分が分散環境にいることをそれほど意識しなくて済む。それは、代理オブジェクトが、クライアントやサーバに代わってネットワーク処理を行うからである。
【００２５】
すなわち、クライアント側では、スタブはサーバの参照としての役割を果たす。またクライアント側では、スタブをサーバだと思ってアクセスする。すると、スタブが、クライアントに代って０ＲＢを介してサーバをアクセスすることになる。サーバとなるオブジェクトは、ネットワークを介したＪａｖａ（登録商標）仮想マシン（ＪＶＭ）上に存在するのであるが、クライアントは、自分と同じＪＶＭにあるスタブをアクセスするため、ネットワークの存在を意識する必要は軽減される。ただし、多くの分散オブジェクト技術において、全く意識しなくて済むわけではない。クライアントは、スタブをＯＲＢから取得する作業と、スタブをアクセスする際でも、ネットワークに起因する例外の処理などを行う必要はある。なお、代理オブジェクト自身の存在をクライアントやサーバから透過的にするシステムにはＴＲＭＩがある。
【００２６】
一方、サーバ側でも、スタブからのアクセスをＯＲＢを経由して直接受け付けるのは、サーバ側の代理オブジェクトであるスケルトンとなる。スケルトンが、ネットワーク越しにアクセスを受け付け、それを同一ＪＶＭ上のサーバに渡す。サーバは、受け取ったアクセスがクライアントからのものであるかのように処理を行うことができる。処理の結果は再びスケルトンとスタブを経由してクライアントに返ざれる。
【００２７】
図２は基本的な分散オブジェクト技術における処理の流れを示す図であり、サーバが何らかの理由で停止する例である。下記説明における（１）等は、図に示した処理の番号に対応している。
（１）サーバをＯＲＢに登録する。
（２）クライアントがサーバをＯＲＢで検索する。
（３）サーバが見つかった場合は、ＯＲＢはサーバのスタブを生成する。
（４）ＯＲＢはスタブの参照をクライアントヘ返す。
（５）クライアントはスタブをサーバと思ってアクセスする。
（６）スタブはクライアントからのサーバヘのアクセス要求をＯＲＢへ渡す。
（７）ＯＲＢはクライアントからの要求を指定されたサーバヘ渡す。
（８）サーバが要求を実行する。
（９）サーバが実行結果をＯＲＢに返す。
（１０）スタブはＯＲＢから実行結果を受け取る。
（１１）クライアントがスタブから実行結果を受け取る。
（１２）サーバが何らかの理由で停止する。
（１３）クライアントはスタブをサーバと思ってアクセスする。
（１４）スタブはクライアントからのサーバヘのアクセス要求をＯＲＢへ渡す。
（１５）ＯＲＢはクライアントからの要求を指定されたサーバヘ渡そうとするがサーバが停止しているので渡せない。
（１６）クライアントは待ち状態となり、実行を継続できなくなってしまう。
もちろん（１２）においてサーバが停止しなければ、（１）から（１１）の処理が所要の処理が済むまで繰り返される。
【００２８】
次に、分散オブジェクト技術を利用してクライアント・サーバ型のシステムにおいて分散オブジェクトのミラーリングを行うモデル、すなわち０ＲＢに対してミラーリングの機能を追加する方式ＭＭＩ（Ｍｉｒｒｏｒｅｄ  Ｍｅｔｈｏｄ  Ｉｎｖｏｃａｔｉｏｎ）における新規な処理の流れを説明する。
【００２９】
ＭＭＩでは、前述の分散オブジェクトのモデルを拡張し、分散オブジェクトの高信頼化を図っている。ＭＭＩは、サーバの複製をいくつかのホスト上に生成し、それを同時にアクセスしてそれらの複製の状態を常に同じに保っておくことにより、いくつかの複製が使用不能になっても、残りの複製でシステムの運用に支障がないようにする方式である。しかも、クライアントやサーバの開発者にとっては、通常の分散オブジェクトを開発しているという認識のみで、高信頼化が達成できる。即ち、クライアントやサーバの開発者は、サーバの複製を自分で生成する必要が無いだけではなく、複製が作られていることさえも認識しなくてよい。
【００３０】
図３は、ＭＭＩの分散オブジェクトモデルである。ＭＭＩでは、サーバ側で分散オブジェクトを生成してＯＲＢに登録すると、その複製となるオブジェクトが複数個、異なるマシン上に自動的に生成される。このオブジェクトの複製をミラーと言う。そして、クライアントが分散オブジエクトをＯＲＢに対して要求すると、０ＲＢは特定のミラーに依存しない参照であるスタブをクライアントに返す。クライアント側では、通常のＪａｖａ（登録商標）の分散オブジェクトモデルと同様、クライアントがスタブをサーバだと思ってアクセスを行う。そのスタブを用いて、クライアントがサーバのメソッドを呼び出すと、すべてのミラーの同じメソッドが同時に実行される。
【００３１】
クラスタリングでは、一時に動作しているアブリケーションは一つのみであり、待機しているアプリケーションが複数存在していたが、ミラーリングでは、クラスタリングと異なり、複数のミラーが同時に動作していることに特徴がある。またサーバ側で実行が終了すると、その結果はスケルトンとスタブを経由してクライアントヘ返される。しかし、複数のミラーの実行結果を別々に返すことはできない。そこで、複数のミラーの実行結果は、０ＲＢによって取りまとめられて、ひとつのサーバの実行結果であるかのようにクライアントヘ返される。従って、クライアントはサーバが一台だけ存在しているという認識で、複数のミラーを同時にアクセスすることができる。
【００３２】
ＭＭＩのＯＲＢは、サーバのどのミラーが正常であるかを常に監視しており、正常なミラーのみを用いてクライアントからの要求に笞える。また、ＯＲＢは、異常を検知したミラーを切り離す機能を持つ。異常なミラーとは、他のミラーと異なる実行結果を返したミラーや、一定時間経過しても結果を返さないミラーなどである。従って、常に動作しているミラーのみで実行を継続するため、ＭＭＩにおいてはミラーの切り替え作業やロールバックはあたかも発生していないかのように、クライアントからは認識される。
【００３３】
さらに、ＯＲＢは異常の発生したミラーを、可能な場合に限り自動的に復元する機能を持つ。それは、他の正常なミラーの複製を生成することにより行う。もちろん、ミラーホスト自身が停止しているような場合は、ミラーホスト自身が人手あるいはその他の方法で修復された後に、ミラーの復元が行われる。この作業が、ロールバックであるが、クライアントからは透過的に行われる。
【００３４】
このように、クライアントはサーバ側のオブジェクトがどのような状態でミラーリングされているか意識する必要はない。このため、クライアントは通常の分散型のアプリケーションを実行している感覚で。障害の発生を意識せずに安定して動作することが可能となる。
【００３５】
なお、ＭＭＩでは、０ＲＢ自身をクライアントやサーバから隠すことを目的としているわけではない。ＭＭＩでは、クライアントやサーバは、ＯＲＢが提供するＡＰＩを経由して、通常通りメソッド呼び出しなどの処理を行う。従って、クライアントはＯＲＢの存在を通常通り意識する必要がある。ただし、サーバはクライアントからは透過的に多重化されていることに特徴がある。
【００３６】
図４は、ＭＭＩ方式における処理の流れを示す図であり、図２の例と同様に、サーバが何らかの理由で停止する例である。下記説明における（１）等は、図に示した処理の番号に対応している。
（１）サーバをＯＲＢに登録すると同時にサーバのミラーを作成するマシン情報をＯＲＢに通知する。
（２）ＯＲＢは指定された指定された一または複数のマシン上にサーバのミラー（複製）を複数作成する。この例では、ミラーは２つ作成する。もちろん、ミラーの個数は２つに限定されるものではない。
（３）クライアントがサーバをＯＲＢで検索する。
（４）ＯＲＢはサーバのスタブを作成する。スタブは特定のミラーにはよらない。
（５）ＯＲＢはスタブヘの参照をクライアントヘ返す。
（６）クライアントはスタブをサーバと思ってアクセスする。
（７）スタブはクライアントからのサーバヘのアクセス要求をＯＲＢへ渡す。
（８）ＯＲＢは、クライアントからの要求をサーバとその全てのミラーに渡す。
（９）サーバおよびそのミラーが要求を実行する。
（１０）サーバが何らかの理由で実行を完了できない。
（１１）実行を完了できたミラーが実行結果をＯＲＢへ返す。
（１２）ＯＲＢは、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
（１３）ＯＲＢは正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離す。
（１４）クライアントがスタブから実行結果を受け取る。
（１５）クライアントはスタブをサーバと思ってアクセスする。
（１６）スタブはクライアントからのサーバヘのアクセス要求をＯＲＢへ渡す。
（１７）ＯＲＢは、クライアントからの要求を生きているミラーに渡す。
（１８）ミラーが要求を実行する。
（１９）実行を完了できたミラーが実行結果をＯＲＢへ返す。
（２０）ＯＲＢは、ミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
（２１）クライアントがスタブから実行結果を受け取ることができ、サーバが停止してもクライアントは実行を継続できる。
【００３７】
すなわち、オブジェクトのミラーリングでは、特定のハードウェアに依存しない高可用性システムを構築でき、アプリケーションレベルではなく、より細粒度のオブジェクトレベルで多重化を図れ、ロールバック作業ならびに切り替え作業を不要とし、多重化されるオブジェクトや、それを使用するシステムに対しては、多重化のための変更を特に行う必要がないようにしている。
【発明を実施するための最良の形態】
【００３８】
以下本発明を実施するための最良の形態を、図に示す実施例を参照して説明する。
【実施例１】
【００３９】
この図５に示す実施例は、本発明の方式を、旧方式を用いて実装することが可能であることを示すものである。以下に、その場合の処理の流れを示す。
（１）サーバを新ＯＲＢに登録すると同時にサーバのミラーを作成するマシン情報を新ＯＲＢに通知する。
Ａ：サーバを新ＯＲＢに登録すると同時にサーバのミラーを作成するマシン情報を新ＯＲＢに通知する。
Ｂ：新ＯＲＢはサーバを旧ＯＲＢに登録する。
（２）新ＯＲＢは指定されたマシン上にサーバのミラーを作成する。この例では、ミラーはやはり２つ作成するものとする。もちろん、ミラーの個数は２つに限定されない。
Ａ：新ＯＲＢは指定されたマシン上にサーバのミラーを作成する。
Ｂ：新ＯＲＢは作成したミラーを旧ＯＲＢに登録する。
（３）クライアントがサーバを新ＯＲＢで検索する。
Ａ：クライアントがサーバを新ＯＲＢで検索する。
Ｂ：新ＯＲＢがサーバおよびそのミラーを旧ＯＲＢで検索する。
（４）新ＯＲＢはサーバのスタブを作成する。スタブは特定のミラーにはよらないものである。
Ａ：旧ＯＲＢはサーバおよび２つのミラーの個別の旧スタブを作成する。
Ｂ：旧ＯＲＢは旧スタブの参照を新ＯＲＢへ通知する。
Ｃ：新ＯＲＢは特定のミラーにはよらないサーバのスタブを作成する（旧ＯＲＢの上位で新ＯＲＢが統轄することになる）。
（５）新ＯＲＢはスタブヘの参照をクライアントヘ返す。
Ａ：新ＯＲＢは新スタブヘの参照をクライアントヘ返す。
（６）クライアントは新スタブをサーバと思ってアクセスする。
（７）新スタブはクライアントからのサーバヘのアクセス要求を新ＯＲＢへ渡す。
（８）新ＯＲＢは、クライアントからの要求を、旧スタブと旧ＯＲＢを介してサーバとその全てのミラーに渡す。
Ａ：新ＯＲＢはクライアントからの要求を旧スタブヘ渡す。
Ｂ：旧スタブはクライアントからの要求を旧ＯＲＢへ渡す。
Ｃ：旧ＯＲＢは、クライアントからの要求をサーバやミラーに渡す。
（９）サーバおよびそのミラーが要求を実行する。
（１０）サーバが何らかの理由で実行を完了できない。
（１１）実行を完了できたミラーが実行結果を旧ＯＲＢへ返す。
（１２）新ＯＲＢは、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
Ａ：旧ＯＲＢは実行結果を旧スタブヘ返す。
Ｂ：旧スタブはそれぞれの実行結果を新ＯＲＢへ返す。
Ｃ：新ＯＲＢは各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を新スタブヘ返す。
（１３）新ＯＲＢは正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離す。
（１４）クライアントが新スタブから実行結果を受け取る。
【００４０】
すなわちこの実施例においても、オブジェクトのミラーリングでは、特定のハードウェアに依存しない高可用性システムを構築できる。またアプリケーションレベルではなく、より細粒度のオブジェクトレベルで多重化を図れ、ロールバック作業及び切り替え作業を不要とする。したがって、多重化されるオブジェクトや、それを使用するシステムに対しては、多重化のための変更を特に行う必要がない。
【図面の簡単な説明】
【００４１】
【図１】標準的分散オブジェクトモデルを示す図
【図２】図１に示した基本的な分散オブジェクト技術における処理の流れを示す図
【図３】ＭＭＩの分散オブジェクトモデルを示す図
【図４】ＭＭＩ方式における処理の流れを示す図５に示す
【図５】本発明の方式を、旧方式を用いて実装することが可能であることを示した例であって、その場合の処理の流れを示す図
【図１】
2007334717.tif 000003
【図２】
2007334717.tif 000004
【図３】
2007334717.tif 000005
【図４】
2007334717.tif 000006
【図５】
2007334717.tif 000007