JP2000500255A - 多サイトに分散されたオブジェクト管理環境に対するシステム及び方法 - Google Patents

Abstract

(57)【要約】 分散されたオブジェクトメッセージシステム及び方法(１０)は、多くの物理的に離れたサイト(１２，１３)に分散された多数のノード(１５〜２１，２５〜３２)に対して提供される。各ノードには実行する多数のプロセスが存在する。プロセスは、各ノードにおける多数のオブジェクトを登録する。オブジェクトは、クライアントオブジェクト及びサーバーオブジェクトを含む。上記複数のサーバーオブジェクトは、ローカルノード、ローカルサイト、及び／又は、遠隔サイトにおけるクライアントオブジェクトに利用可能なサービスであるサイトグローバルサービスにおいて、クライアントオブジェクトに利用できるサービスであるグローバルサービスが登録できる。上記ノードに登録された各サーバーオブジェクト、及び、遠隔ノードに登録されているオブジェクトであって、グローバルサービス又はサイトグローバルサービス用に登録されたオブジェクトに関するサーバーオブジェクト記述を格納するためにサーバーオブジェクト・データベース(４６)が各ノードにおいて利用される。クライアントサーバー・インターフェース(５０)は、クライアントオブジェクトによりアクセス可能であり、それらからのサービスに関する要求を受け取る。クライアントサーバー・インターフェースは、クライアントオブジェクトの要求するサービスを実行可能な、少なくとも１つの行き先サーバーオブジェクトを探すために上記サーバーオブジェクトデータベース(４６)にアクセスし、ローカルサイト又は遠隔サイトにある行き先サーバーオブジェクトにサービス要求を送る。

Description

【発明の詳細な説明】 多サイトに分散されたオブジェクト管理環境に対するシステム及び方法 発明の技術分野 本発明は、複数の物理的位置において、信頼性のためのハードウェア及びソフ トウェアサービスのリダンダンシーを必要とする通信アプリケーションについて の分散コンピュータシステムの技術分野に広く関する。特に、本発明は、多サイ トに分散されたオブジェクト管理環境に関する。本発明は、特に、複数の物理的 位置において、信頼性のためのハードウェア及びソフトウェア・サービスのリダ ンダンシーを必要とする通信に利用できる。 発明の背景 クライアントとサーバーの間のインタフェースは、クライアントとサーバーが 同じプロセスに接続されている場合に、最も単純で最も共通するものとなる。こ の場合、クライアントはサブルーチンを呼び出してサーバーにアクセスできる。 呼び出し入力パラメータが共通のメモリ中でクライアントからサーバーへ渡され 、返送された出力パラメータがサーバーからクライアントへ共通のメモリを介し て渡されて、呼び出しを完了する。 分散コンピュータアーキテクチャの能力を利用するために、サーバーは、しば しばクライアントノードから離れたネットワークノード中にあることが必要であ る。複数のクライアントは同じサービスを複数のサーバーから同時に要求しても よい。さらに、通信アプリケーションにおいて、ハードウェア／ソフトウェアの 故障許容サービス環境を実現するために、ハードウェア及びソフトウェアのリダ ンダンシーが要求される。この環境は、グローバル通信ネットワークにおいて地 理的に遠隔位置にあるノードから構成される。システムは、ネットワークの任意 のポイントでのサーバーの停止に迅速に適応できなければならない。 発明の要約 したがって、多サイトにおいて、単純なクライアント／サーバー・サブルーチ ンを呼び出すかわりに、サーバーのグローバルネットワークに対してアクセスで きる環境が要求されている。 本発明によれば、多サイトに分散されたオブジェクトメッセージシステム及び 方法が提供され、それにより、従来のシステムに関連する問題点を消滅し、また は実質的に低減する。 本発明の１つの態様において、分散オブジェクトメッセージシステム及び方法 は複数の物理的に分離されたサイトに分散された複数のノードに対して提供され る。複数のプロセスは各ノードで実行する。複数のプロセスは各ノードにおいて 複数のオブジェクトを登録する。オブジェクトはクライアントオブジェクト及び サーバーオブジェクトを含む。サーバーオブジェクトは、ローカルノード、ロー カルサイトにおいてクライアントオブジェクトへのサービス利用可能性のための グローバルサービス、および／または、遠隔サイトにおいてクライアントオブジ ェクトの利用可能性のためのサイトグローバルサービスに対して登録できる。サ ーバーオブジェクト・データベースは各ノードにおいて利用され、ノードに登録 された各サーバーオブジェクトと、グローバルサービスまたはサイトグローバル サービスに対して登録された遠隔ノードに登録されたオブジェクトとに対するサ ーバーオブジェクト記述を格納する。クライアント・サーバーインタフェースは 、クライアントオブジェクトによってアクセスでき、それらからのサービスに対 する要求を受信する。クライアントサービスインタフェースは、少なくとも１つ の宛先サーバーオブジェクトがクライアントオブジェクトの要求されたサービス を実行できるようにするために、サーバーオブジェクト・データベースにアクセ スし、また、サービス要求をローカルサイトすなわち遠隔サイトにある宛先サー バーオブジェクトに転送する。 本発明のもう１つの態様において、ローカルキャッシュが各プロセスにおいて 確保され、過去のサービス要求及びサーバーオブジェクトの一致を記録する。ロ ーカルキャッシュは、サーバーオブジェクト・データベースが最後のデータベー スのアクセス以来変更されていない場合は、最初に、一致のためのサービス要求 を行うためにアクセスされる。 さらに、本発明の別の態様では、ノードの現在のサービスステータスは、サー バーオブジェクト・データベースのオブジェクトの１つが登録されたときはいつ でもサーバーオブジェクト・データベースに記録される。そのとき、サーバーオ ブジェクト・データベースの内容は、サービスステータスにおけるノードのアッ プグレードまたはダウングレードに応じて適合させることができる。 図面の簡単な説明 本発明をより理解するために、以下の添付の図面を参照できる。 図１は、それらの間に通信リンクを有する２つのサイトにあるノードのトップ レベルの図である。 図２は、複数のプロセスを有するノードの単純化された図である。 図３は、ＤＯＭＥ複数サイト初期化プロセスの１例のフローチャートである。 図４は、オブジェクト登録プロセスの１例のフローチャートである。 図５は、サーバーオブジェクト・データベースに格納される情報のタイプを示 したサーバーオブジェクト・データベースの１例である。 図６は、要求サービスプロセスの１例のフローチャートである。 図７は、サーバーオブジェクトプロセスの取得リストの１例のフローチャート である。 図８は、サーバーオブジェクトプロセスの要求リストの１例のフローチャート である。 図９は、サーバーオブジェクトプロセスの受信リストの１例のフローチャート である。 図１０は、内部ノード通信プロセスの図である。 図１１は、別の内部ノード通信プロセスの図である。 図１２は、ノードステータス設定プロセスの１例のフローチャートである。 図１３は、ノードサービス状態の１例の状態図である。 発明の詳細な説明 本発明の好ましい実施の形態が図１〜図１３に示される。同じ参照番号が、種 々の図面において同じまたは同様な部分を参照するために使用される。 図１を参照すると、参照番号１０により広く示される多サイト環境における分 散オブジェクト管理環境（ＤＯＭＥ）の単純化された図が示されている。ＤＯＭ Ｅ１０は、説明のために、参照番号１２と１３でそれぞれ示されるサイトＳ０と サイトＳ１の２つのサイトを含み、それらは、コンピュータネットワークやメデ ィアアクセス制御（ＭＡＣ）ブリッジ１４のようないくつかの通信回線を介して 接続されている。各サイト１２、１３は、ノード１５〜２１、２５〜３２のグル ープをそれぞれ含む。ＤＯＭＥシステムは、１つ、２つ、または複数のサイトを 含んでもよい。サイトは、お互いに物理的に遠隔した位置にあってもよい。例え ば、サイト１２が物理的にシカゴに位置し、ノード１３が物理的にニューヨーク に位置してもよい。 サイトはイーサネットのような１つ以上のコンピュータネットワークにより接 続されたノードのグループとして定義されてもよい。必要なことではないが、典 型的には、サイト中のノードは互いに近接して位置し、互いに協力して動作する 。ノードは１つ以上の中央演算処理装置を備えるワークステーションとして定義 されてもよい。中央演算処理装置はオペレーティングシステムのインスタンス及 びいくつかのアプリケーションソフトウェアまたはプロセスを実行する。各サイ ト１２、１３は、アクティブプラットフォームマネージャ（ＰＭ）ノード１５、 ２５を含んでもよい。それらはいくつかの特定の１次的な管理機能を実行する。 待機プラットフォームマネージャノード１６、２６は、アクティブプラットフォ ームマネージャが故障した場合にバックアップ支援を提供するインスタンスに含 まれてもよい。アプリケーションノード１７〜２１、２７〜３２はまた、「アク ティブ／待機」及び「負荷分散」として指示されてもよい。負荷分散の指示は、 機能すなわちプロセスを等しく割り当て、負荷分散ノードにより実行させる。図 １に示すように、各ノードは、同じサイトの１つのノードと通信するのと同様に 、他 のサイトの他のノードと直接通信してもよい。 図２を参照すると、ノードＡＰＯ１７が複数のプロセスＰ０〜Ｐ４（４０〜４ ４）を含むことが示されている。各プロセスは、クライアントプロセス、サーバ ープロセスであってもよく、すなわち、１つのプロセスに対するクライアント及 び他のプロセスに対するサーバーとして機能してもよい。さらに、各ノードはＤ ＯＭＥサーバープロセス４８を含む。ＤＯＭＥサーバープロセス４８は、クライ アントオブジェクトとサーバーオブジェクトとの間の登録インタフェースとして 機能する。クライアントオブジェクトとサーバーオブジェクトは、同じかまたは 異なるサイトにおいて、ノード内の異なるプロセス、またはシステムにおける異 なるノードにある。各プロセス４０〜４４は、ＤＯＭＥサーバープロセス４８に より１つ以上のオブジェクトのインスタンスを登録してもよい。ＤＯＭＥサーバ ープロセス４８は、サーバーオブジェクト・データベース４６に登録されたオブ ジェクトの情報を格納する。サーバーオブジェクト・データベース４６は、同一 または異なるサイトでのノード及び他のノードにおけるプロセス４０〜４４に対 してアクセスできる。サーバーオブジェクト・データベース４６はクライアント によりアクセスされて読み出される。ＤＯＭＥはサーバーオブジェクトからのク ライアント要求サービスをいつでもインタフェースする。全てのローカルサーバ ーオブジェクトは、ＤＯＭＥクライアントインタフェースにより、サービス要求 を直接サーバーオブジェクトメッセージキューに配置することにより、直接アク セスされる。サーバーオブジェクトは、メソッドを呼び出すことにより遠隔のク ライアントオブジェクトにアクセスが可能となる機能及びデータを内部に閉じ込 めたものとして定義される。 各プロセス４０〜４４には、クライアントとサービスオブジェクトとの間の、 内部プロセス、内部ノード及び内部サイト通信を与えるＤＯＭＥ５０のインスタ ンスもある。同一サイトまたは異なるサイトでのノード間の二地点間通信は、各 ノードにあるプロセスＭＨ（メッセージハンドラー）５２及びリンクＴＣＰ（Li nk Transmission Control Protocol）により形成されるＴＣＰ／ＩＰ（Transmis sion Control Protocol/Internet Protocol）経路上で可能である。ＤＯＭＥの 通信態様を以下に詳細に説明する。 また、図３を参照して、多サイトＤＯＭＥ初期化プロセス５０の実施の形態の 単純化したフローチャートが示されている。サイトでシステムが起動したとき、 ブロック５２に示すように、最初のステップの１つが、ＤＯＭＥサーバープロセ ス４８を呼び出し、そのオブジェクト及びサーバーメンバ機能を登録する。サー バーオブジェクトは１つ以上のサーバーメンバ機能を有する。サーバーメンバ機 能は、クライアントオブジェクトに対してコールパラメータの送受信を行う、ユ ーザにより定義された一意の（unique）インタフェースを有する。サーバーメン バ機能は、サーバーオブジェクト記述に記録された認識番号を用いてクライアン トにより参照される。各メンバ機能は、サーバーオブジェクトによって登録され た機能プロトタイプ定義を有する。サーバーメンバ機能記述データベース（図示 せず）は、各プロセスにおいて維持され、プロセスにおいて登録されたサーバー オブジェクトの登録されたサーバーメンバ機能記述を記録する。 オブジェクト登録後、ブロック５４に示すように、ＤＯＭＥサーバープロセス ４８はサーバーオブジェクト・データベース４６を初期化する。その後、ブロッ ク５６と５８において、ＤＯＭＥサーバープロセス４８は、全てのサイトでのノ ードの数に対するプラットフォームマネージャノードと、全てのノードに対する 詳細なノード記述とを要求する。ＤＯＭＥサーバープロセス４８は、ブロック６ ０に示すように、オブジェクトサーバー・データベースにノード記述を保管し、 返送されたノード記述の配列を検索し、それ自身のノードの配列インデックスと 、それが存在するサイトの名前とを決定する。ＤＯＭＥサーバープロセス４８は 、その後、ブロック６２に示すように、ＭＨ及びリンクＴＣＰプロセス５２、５ ４と通信することにより通信リンクを確立する。ブロック６４において、ＤＯＭ Ｅサーバープロセス４８は各遠隔ノードにそのオブジェクトサーバー・データベ ースの内容を送信するように要求する。これらの要求に対する応答により、ＤＯ ＭＥサーバープロセス４８は、オブジェクトサーバー・データベース４６を、他 のノードにおけるグローバルサービスまたはサイトグローバルサービスに対して 登録されたオブジェクトに関する情報により更新することができる。グローバル サ ーバーオブジェクトは、同じサイトにおいてクライアントオブジェクトを管理す ることができ、同様に、サイトグローバルサーバーオブジェクトは、他のサイト においてクライアントオブジェクトを管理することができる。 また、図５を参照すると、サーバーオブジェクト・データベース４６は、オブ ジェクト名、ノード名、サイト名及びインスタンス名のようなオブジェクト記述 を含む。オブジェクト名、ノード名、サイト名及びインスタンス名は、英数字ス トリングまたは所定の命名規則にしたがった数字であってもよい。また、ノード 名とサイト名の少なくとも１つは、サーバーオブジェクト・データベースにおい て保管されるリストのそれぞれに対するインデックスであってもよい。さらに、 名前は、所定の方法で連結されてもよい。もしノードの位置が異なれば、オブジ ェクトの複数のコピーをインスタンス名なしに登録することもできる。インスタ ンス名により、クライアントオブジェクトは、特定のノードにおいてオブジェク トの一意のインスタンスを選択することができる。もし、ノード名がクライアン トオブジェクトにより特定されなければ、ＤＯＭＥはオブジェクトを含む任意の ノードが適正なサーバーであると仮定する。 サーバーオブジェクト・データベース４６はさらに、オブジェクト登録時のノ ードオペレーティングステータスを含む。ノードオペレーティングステータスは 、サービス外、オペレーティングシステム・ミニマム（OS min）またはサービス 中を含む。また、オブジェクトの動作モードも含まれる。それには、アクティブ ／待機、負荷分散、ローカルサービス、グローバルサービス及びサイトグローバ ルサービスのモードを含んでもよい。負荷分散オブジェクトはアクティブのとき 、選択メソッドはこのモードで動作するオブジェクト間の負荷を等しく分散させ るために使用される。アクティブ／待機オブジェクトはまた次のアクセスモード を登録する。そのアクセスモードは、それらがアクティブステータスまたは待機 ステータスのいずれにおいて要求を受信すべきかを特定する。ローカルサービス モード、グローバルサービスモード及びサイトグローバルサービスモードは、オ ブジェクトが、クライアントオブジェクトが存在するノードもしくはサイトにあ るクライアントオブジェクトからの要求、または他のサイトからのクライアント オ ブジェクトからの要求のいずれをサービスできるのかを決定する。サーバーオブ ジェクト・データベース４６は、さらに通信オプションと、それに対するオブジ ュクトの特別な情報とを含む。例えば、ＴＣＰ／ＩＰまたはUser Datagram Prot ocol/Transport Layer Interface（ＵＤＰ／ＴＬＩ）ソケット接続のいずれが使 用されているかのような情報を含む。もし、ＴＣＰ／ＩＰが使用されていれば、 オブジェクトのよく知られたポートアドレスが含まれる。 ブロック６６において、ＤＯＭＥサーバープロセス４８は、任意のノードがそ の動作ステータスを変化したときはいつでも通知するように要求し、それにより 、そのサーバーオブジェクト・データベースはその変化を反映して更新されても よい。その後、ブロック６８に示すように、ＤＯＭＥサーバープロセス４８はサ ービス提供の準備状態になり、サービスに対する要求を待つ。 図４は、オブジェクト７０を登録するためのプロセスの１例の単純化されたフ ローチャートである。ブロック７２に示すように、ＤＯＭＥは最初、ＤＯＭＥＯ ＢＪ構造を構築し、オブジェクト記述についての一時記憶域を与える。次に、ブ ロック７４に示すように、オブジェクトが既に登録されているかが判断される。 もし、オブジェクトが既に登録されていれば、ブロック７６と７８に示すように 、そのメッセージキューは除去され、サーバーオブジェクト・データベース４６ においてその対応するエントリが削除される。実質的に、ブロック８０において 、オブジェクトインスタンスのオブジェクト記述はサーバーオブジェクト・デー タベース４６に追加される。 もし、ブロック８２において判断されるように、オブジェクトがグローバルサ ービスモードで登録されていれば、ブロック８４に示すように、オブジェクト記 述は、同一サイトにある全ての他のノードの全てのＤＯＭＥサーバープロセスに ブロードキャストされ、他のノードにおけるクライアントオブジェクトもまた管 理する登録されたオブジェクトインスタンスを新たに作成する。その後、プロセ スはブロック８６に進む。サイトグローバルサービスモードにおいて登録された オブジェクトは、登録時には遠隔サイトへはブロードキャストされない。サイト グローバルオブジェクトは、遠隔サイトノードがサーバーオブジェクト・データ ベースに対して要求したときに、他のサイトに対して明らかになる。それは、典 型的には、ノードステータスが変化したときに起こる。 図６に、クライアントのオブジェクト９０のためのサーバーオブジェクトから のサービスの要求の簡単化されたフローチャートが示される。クライアント・オ ブジェクトは、サービス要求をし、コール(calling)パラメータを与える。ブロ ック９２に示されるように、ＤＯＭＥは、サーバーメンバー機能のためのクライ アントのコールパラメータを、サービス要求メッセージにフォーマットする。次 に、ブロック９４に示されるように、ＤＯＭＥは、クライアントの全部または一 部のサーバーオブジェクト記述にマッチするサーバーオブジェクトのリストを要 求する。サーバーオブジェクト・データベース４６（図２）は、ＤＯＭＥプロセ スが、あるオブジェクトインスタンスにただちにアクセスできるか、または、部 分的記述にマッチする全オブジェクトをアクセスできるように、組織化される。 たとえば、ＤＯＭＥは、オブジェクトのあるバージョンのためのノードにおける 全オブジェクトをアクセスできる。または、ＤＯＭＥは、全バージョンのための 全ノードにおける全オブジェクトインスタンスをアクセスできる。１つのエント リーまたは１グループのエントリーへの速いアクセスを可能にするハッシュアル ゴリズムを用いて、データベースにおける各フィールドのためのデータエントリ ーは、アルファベットの順でリンクされる。さらに、オブジェクト名がノードエ ントリーのリストを指し、かつ、各ノードエントリーが名付けられたインスタン スのリストを指すように、データが組織化される。ブロック９５〜１００に示さ れるように、ＤＯＭＥは、リストからサーバーオブジェクトをサービス要求のた めの行き先として選択し、選択されたサーバーオブジェクトにサービスメッセー ジ要求を送り、フローから出る。 以下のルーティング規則は、要求サービスコールにおいて当てはまる。 １．もし一意のローカルまたは遠隔のノード名が行き先として指定されるなら 、サービス要求メッセージは、後で詳細に説明されるアクティブ／待機および負 荷分散のルーティング規則を用いずに、そのノードにルートされる。これは、同 じサイトでない遠隔ノードを含む。 ２．もしクライアントオブジェクトが行き先を指定しないならば、この要求は 、アクティブ／待機および負荷分散のルーティング規則を用いて、ローカルのサ イトの１つまたは複数のサーバーにルートされる。 ３．もしサイト名または遠隔サイト特定子（specifier）が行き先として用い られるなら、そのサイトにおいてグローバルとして登録されたサーバーオブジェ クトのサイトのみが行き先ターゲットとして考慮され、アクティブ／待機および 負荷分散のルーティング規則が当てはまる。 サーバーオブジェクトとノードは、アクティブ／待機モードまたはアクティブ （負荷分散）モードとして登録できる。アクティブなオブジェクトは、どのオブ ジェクトが今扱っているサービス要求を処理するべきかを決定するラウンドロビ ン選択アルゴリズムを用いて負荷が分散される。まず、クライアントのＤＯＭＥ は、どのノードが最高サービスステートにあるかを決定する。次に、ＤＯＭＥは 、最高サービスステートのオブジェクトインスタンスを選択する。プラットフォ ームマネージャおよび／またはアプリケーションソフトウエアのどれが実行中で あるかによって、ノードのサービスステートは、サービス外、ＯＳミニマムまた はサービス中である。サービスステートの詳細は、図１２と図１３と関連して後 で説明される。もし多ノードが同じサービスステートで動作中であるならば、サ ービス要求を等しく分散するために、上述のラウンドロビンアルゴリズムまたは 同様なアルゴリズムが使用できる。アクティブなオブジェクトは、アクティブ／ 待機モードとして登録されているノードに常駐することがある。 サービスのためにクライアントの要求を処理するためにＤＯＭＥが用いる８個 の異なるサーバーオブジェクト・ルーティング・アルゴリズムがある。もし特定 されたノード名の代わりにサイト名が行き先フィールドにおいて特定されるなら 、ノード名はヌル（null）であると考えられ、ノードの選択は、特定されたサイ トでのノードに限られる。もし行き先名がヌルのフィールドであるなら、ローカ ルのサイトが特定される。 ルーティング規則は次のとおりである。 行き先は、特定の名により、または、以下の５個の特定子のいずれかを用いて 、指定できる。 ＲＥＭＯＴＥ＿ＳＩＴＥ（"＆"）： 要求サービスコールのためのアクティ ブ／待機および負荷分散のルーティング規則を用いて、遠隔サイトにあるノード のみへルートする。 ＡＬＬ＿ＳＩＴＥＳ（"Ｓ"）： ブロードキャストコールにおいて用いられ るとき全サイトで全ノードにルートする。要求サービスコールのためアクティブ ／待機および負荷分散のルーティング規則を用いる。 ＮＯＴ＿ＬＯＣＡＬ＿ＳＩＴＥ（"＃"）： ブロードキャストコールと要求 サービスコールの両方のため常駐ノードの他のローカルサイトにおけるどのノー ドにもルートする。 ＬＯＣＡＬ＿ＳＩＴＥ（"？"）： ブロードキャストコールにおいてどのロ ーカルサイトのノードにもルートする。要求サービスコールのためアクティブ／ 待機および負荷分散のルーティング規則を用いる。 ＬＯＣＡＬ＿ＮＯＤＥ（"％"）： ブロードキャストコールまたは要求サー ビスコールのためローカルサイトへのみルートする。 引用符号で囲まれる特定子の文字は、行き先の種類を特定するために用いられ る。なお、上述の文字は例として挙げられたものであり、本発明はそれに限定さ れない。 クライアントがサービス要求をするとき、オブジェクト名がサービスオブジェ クトデータベースにおいて検索され、そのオブジェクトがアクティブ／待機型か 常にアクティブ型かを決定する。次に、ノード名がヌルのストリングまたは一意 のＡＳＣＩＩ名のいずれであるか調べられる。また、インスタンス名も、ヌルの ストリングまたは一意のＡＳＣＩＩ名のいずれであるか調べられる。これらの３ つの指定子は、ノード・ルーティングのメソッドとインスタンス選択のメソッド にアクセスするために用いられる。 ８個のサーバーオブジェクト・ルーティング・アルゴリズムの各々は、２つの 部分からなる。クライアントモードでは、ＤＯＭＥは要求にサービスするための 最良のサーバーノードを選択し、その要求をノードに送る。サービスルーティン グのこの部分は、サーバーノード選択メソッドである。上述の表は、オブジェク トの型、ノード名およびインスタンス名の組み合わせの各々についてのエントリ ーを含む。各エントリーは、後で詳細に説明するノード選択メソッドとインスタ ンス選択メソッドの数を特定する。 １． クライアントは、サービス要求を処理するべき一意のノード名を特定 する。第１に、サーバーオブジェクトが特定されたノード名の中にあるか否かを 決定するために、サーバーオブジェクト・データベースがアクセスされる。もし その特定されたノード名の中になければ、ＤＯＭＥはオブジェクトが発見されな かったというエラーを宣言する。もしサーバーインスタンス名が特定されるなら 、サーバーオブジェクト・データベースが検索され、名付けられたインスタンス が特定されたノード名の中にあることを確認する。もし正確なインスタンス名が そのノードに存在しないなら、インスタンスが見いだされないというエラーが戻 される。サービス要求メッセージはフォーマットされ、特定されたノードに送ら れる。 ２． クライアントは、アクティブ／待機型であるが特定のノードまたはイ ンスタンスを要求しないオブジェクト名を特定する。クライアントのＤＯＭＥは 、 要求されるオブジェクト名の全ノードにおける全インスタンスリストを作る。登 録されたサーバーオブジェクトの受信ステートはサーバーオブジェクト・データ ベースにおいて見いだされる。サーバーオブジェクトは、アクティブ、待機、ま たは、アクティブ／待機のステートにおいて受信するため、登録できる。インス タンスリストは、アクティブ、待機、またはいずれかである、要求された受信ス テートにあるノードにおいて存在するオブジェクトのインスタンスのためスキャ ンされる。サービス要求は、資格のある１以上のノードに送られる。もし資格の あるノードがなければ、エラーリターンがクライアントに対してなされる。 ３． クライアントは、オブジェクトを特定する。このオブジェクトは、ア クティブ／待機にあり、システムのいずれかのノードに存在し得る特定のインス タンス名にサービス要求を送ることを希望するものである。サーバーオブジェク ト・データベースは、どのノードにインスタンス名があるかを決定するために調 べられる。 ４． オブジェクトの型は、常にアクティブであり、クライアントは、特定 のノード名または特定のインスタンス名を特定しない。第１に、ＤＯＭＥは、オ ブジェクト名を含む全ノードのリストを作る。もしノードが見いださなければ、 エラーがクライアントに戻される。次に、ＤＯＭＥは、最高サービスステートに あるノードのためのリストを検索し、最高サービスステートを有しない見いださ れたどのノードもリストから除く。次に、ＤＯＭＥは、ラウンドロビン選択アル ゴリズムに基づいて残りのノードのリストからノードを選択する。リストにおけ る、前に選択されたインデックスは、このサービス要求において使用されるノー ドを選択するために、インクリメントされ、使用される。 ５． オブジェクトの型は常にアクティブであり、クライアントは、特定の インスタンス名を特定した。第１に、ＤＯＭＥは、オブジェクト名と特定のイン スタンス名を含む全ノードのリストを作る。もしノードが見いださなければ、エ ラーがクライアントに戻される。次に、ＤＯＭＥは、最高サービスステートにあ るノードのためのリストを検索し、最高サービスステートを有しない見いだされ たどのノードもリストから除く。最後に、ＤＯＭＥは、ラウンドロビン選択アル ゴリズムに基づいて残りのノードのリストからノードを選択する。リストにおけ る、前に選択されたインデックスは、このサービス要求において使用されるノー ドを選択するために、インクリメントされ、使用される。 別の手法では、クライアント・オブジェクトは、ローカルサーバーオブジェク ト・データベースにリストされていない他のノードにおいてサーバーに特殊化さ れた要求をすることができる。これらは、サイトグローバルサーバーオブジェク トとして登録されていなかったサーバーである。この特殊化された要求は、メッ セージハンドラープロセスに転送され、このプロセスは、要求されるオブジェク トのために行き先キューＩＤを探し、そのメッセージをオブジェクトのＤＯＭＥ サーバープロセスに転送する。次に、ＤＯＭＥサーバーインターフェイスは、サ ービス要求メッセージを受け取り、メッセージに含まれるパラメータを、サーバ ーオブジェクトにより予期される入力シーケンスにフォーマットする。次に、サ ーバーオブジェクトは、メッセージを受け取り、要求されるサービスを実行する 。 図７は、サーバーオブジェクトのリストを取得するためのプロセス１１０の追 加の詳細を示す。図２をも参照して、サーバーオブジェクト・データベース４６ は、変更カウンタ１１１を含み、このカウンタは、データベースの内容が変わる たびにインクリメントされる。ノードにおける各プロセス４０〜４４は、ローカ ルキャッシュ１１２を備え、その内容は、過去のサービス要求と、要求されたサ ービスを行う対応するマッチされたサーバーオブジェクトの履歴レコードである 。また、ローカルキャッシュ１１２は、最新のデータベースのアクセスのときに 変更カウンタがカウントしたもののレコードを保持する。ブロック１１４と１１ ６において、変更カウンタ１１１は、読み出され、そのカウントのローカルレコ ードと比較される。もし、数が一致（match）しないなら、サーバーオブジェク ト・データベース４６の内容が変えられ、ローカルキャッシュ１１２の内容はも はや正しくない。したがって、ブロック１１８〜１２２に示されるように、サー バーオブジェクト・データベース４６は、信号（semaphore）をロックして、デ ータベース４６における関連する１つまたは複数のエントリーを読みだし、信号 を解放することにより、アクセスされる。 他方、ブロック１２４に示されるように、もしカウントがローカルに保持され 、変更カウンタが同じであれば、オブジェクト記述のローカルキャッシュは一致 のために検索できる。また、もしサービス要求との一致がなければ、ブロック１ １８〜１２２に示されるのと同様に、サーバーオブジェクト・データベース４６ がアクセスされる。続いて、このプロセスはブロック１２６において終了する。 ノードがはじめに初期化されるとき、図３のブロック６４に示されるように、 そのノードを、サーバーオブジェクト・データベースに格納されるオブジェクト 記述とともに供給するために、同じサイトでの他のノードを要求する。サイトグ ローバルサーバーは、登録されるときに、遠隔サイトにブロードキャストされな い。サイトグローバルサーバーオブジェクトは、遠隔サイトのノードがサーバー オブジェクト・データベースを探すとき、遠隔サイトのクライアントに可視化さ れる。これは、典型的には、ノードステータスの変化のときに生じる。図９は、 サーバーオブジェクトプロセス１３０のリストの要求を示す。ブロック１３２に おいて、要求がローカルサイトまたは遠隔サイトのノードからであるかの決定が なされる。もし要求がローカルサイトからであれば、ブロック１３４に示される ように、グローバルサービスのため登録されるサーバーオブジェクトのオブジェ クト記述が得られる。そうでなければ、希望されるオブジェクト記述は、サイト グローバルサービスのために登録されるサーバーオブジェクト（ブロック１３６ で得られる）のものである。次に、ブロック１３８に示されるように、オブジェ クト記述は、要求するノードに通信される。このプロセスは、ブロック１４０で 終了する。 図９は、ローカルサイトまたは遠隔サイトからオブジェクト記述を受信するプ ロセスフロー１５０を示す。ブロック１５２に示されるように、オブジェクト記 述を受け取ると、サーバーオブジェクト・データベースの信号が得られて、他の プロセスを締め出す。ブロック１５４において、データベースが変更されたこと を反映するために、データベースのために保持される変更カウンタはインクリメ ントされる。次に、ブロック１５６と１５８に示されるように、今問題となって いるノードのためのサーバーオブジェクト記述が除かれ、更新された記述がサー バーオブジェクト・データベースに挿入される。次に、ブロック１６０において 、この信号が解放され、ブロック１６２において、このプロセスは終了する。 以上に説明したように、ノード間の通信は、メッセージハンドラープロセスと リンクＴＣＰプロセスとをとおしてなされる。図１０は、通信プロセスを表す。 図１０は、クライアントオブジェクト１７４とサーバーオブジェクト１７６を示 し、ここに、クライアントオブジェクトとサーバーオブジェクトは、別々のノー ドＸ１７０とノードＹ１７２にそれぞれ常駐する。サーバーオブジェクト１７２ がちがうノードにあるとき、ＤＯＭＥは、ノード間通信のための２つの特殊化プ ロセス、すなわち、メッセージ・ハンドラーとリンクＴＣＰにより提供されるネ ットワーク論理リンクインターフェイスを用いる。メッセージハンドラーとリン クＴＣＰは、ノード間通信のためのＴＣＰ／ＩＰを生成する。サービス要求を送 るために、ＤＯＭＥはクライアント要求を常駐のメッセージハンドラー１７８に 転送する。次に、メッセージハンドラーは、要求を行き先のノードのリンクＴＣ Ｐプロセス１８０に転送し、このプロセスは、サーバーオブジェクト１７６によ り受信されるサーバーオブジェクトＩＰＣシステムＶメッセージキューにサービ ス要求を置く。サーバーオブジェクトは、メッセージの到来を知らせるあらかじ め決められた信号によるサービス要求を知らされる。別の方法では、サーバーオ ブジェクトは、サービス要求の存在をポールするか、または、サービス要求が存 在するまで、一時停止する。各メッセージキュー１８２は、メッセージの数とバ イトの全体の数についてあらかじめ決められた最大容量限界を持つことができる 。 もしクライアントオブジェクト１７４に戻される結果または答えがあるなら、 まずノードＸ１７２にあるメッセージハンドラー１８４に送られる。次に、メッ セージハンドラー１８４は、リターンメッセージを、ノードＹ１７０にあるリン クＴＣＰプロセス１８６に通信する。次に、このメッセージは、クライアントオ ブジェクト１７４のメッセージキュー１８８に置かれる。各クライアント要求は 、サーバーの応答とともにクライアントに戻される一意のトランザクションＩＤ でマークされる。次に、クライアントオブジェクトは、サーバーオブジェクトか ら正しい応答が要求に対して戻されたことを保証される。なお、行き先のサーバ ー のオブジェクトがクライアントオブジェクトと同じノードにあるとき、サービス 要求メッセージは直接にクライアントオブジェクトからサーバーオブジェクトの メッセージキューに送られる。 図１１は、ノード間通信の他の方法を示す。ノードＸ１７０にあるクライアン トオブジェクト１７４は、ノードＹにあるサーバーオブジェクト１７６にＵＤＰ を介してサービス要求を送ることができる。実行されるサービスの結果は、もし あれば、同じように、クライアントオブジェクト１７４に送り返される。この方 法は、ＴＣＰ／ＩＰ送信法より少ないオーバーヘッドを含むが、メッセージの伝 達を保証しない。グローバルサーバーオブジェクトは、その周知のＵＤＰポート ＩＤを、それが登録されている他のノードにブロードキャストできる。サイトグ ローバルサーバーオブジェクトの周知のＵＤＰポートＩＤは、そのノードのサー バーオブジェクト・データベースが遠隔ノードにより要求されるとき、他のサイ トにおけるノードにも利用できる。 図１２を参照して、ノードステータスをセットするプロセス１９０は、ノード ステータス変化を反映するためにサーバーオブジェクトデータベースを自動的に 更新するために用いられる。遠隔ノードのステータスまたはサービスステートが 変更されるたびに、ノードのＤＯＭＥサイト４８（図２）のプロセスは、そのサ ーバーオブジェクト・データベースを更新する。ブロック１９２に示されるよう に、ノードはステータスの変化を経験した遠隔ノードの新しいステータスを受け 取り、古いステートを前のサービスステートに等しくセットする。ブロック１９ ４と１９６に示されるように、もし新しいステータスがサービス外であり、ノー ドがもはやアップでなく実行されていないなら、サーバーオブジェクト・データ ベースの内容は、ダウングレードされたノードの登録されたオブジェクトを除く ために、更新されねばならない。このため、まず、ブロック１９８と２００に示 されるように、サーバーオブジェクト・データベースの信号をロックし、変更カ ウンタをインクリメントする。次に、ブロック２０２に示されるように、ダウン グレードされるノードにある登録されたサーバーオブジェクトは、サーバーオブ ジェクト・データベースから除かれる。次に、ブロック２０４において、信号は 解放される。したがって、サーバーオブジェクト・データベースは、サービス外 のノードにあった全登録オブジェクトを取り除かれる。 ブロック１９４と２１０に示されるように、もし新しいステータスがＯＳミニ マムであるなら、または、ブロック２１６で決定されるように、もし新しいステ ータスがサービス中であるなら、ブロック２１８に示されるように、サーバーオ ブジェクト・データベースは、ノードステータスがグレードをアップするかダウ ンするかに依存して更新されねばならない。ステータスのアップグレードは、 サービス外 → ＯＳミニマム → サービス中 の方向での遷移に対応し、ブロック２１８における条件をつくる。他方、 サービス中 → ＯＳミニマム → サービス外 の方向における遷移は、ブロック２１９における条件を真とする。ブール変数Ｕ ＰＤＡＴＥは、もはやサービスのために利用できないサーバーオブジェクトをデ ータベースから除くことを積極的に要求するために使用できる。もしブロック２ １８における条件が偽であるなら、ブロック２２０に示されるように、遠隔ノー ドの全体のサーバーオブジェクト・データベースのコピーが要求され、ローカル のデータベースに追加される。サーバーオブジェクトの要求と受信のプロセスは 、上に説明した図８と図９に示される。 もしブロック２１８における条件が真であるなら、ローカルノードのサーバー オブジェクト・データベースの内容は、選択的に除かれねばならない。もしサー ビスステートのダウングレードがあるなら、現在の新しいステータスより高いサ ービスステートで登録されていたオブジェクトがもはや妥当でなく、それぞれの 記述はサーバーオブジェクト・データベースから除かれる。まずサーバーオブジ ェクト・データベースの信号が、ブロック１２２に示されるように、確保される 。次に、更新カウンタが、データベースの内容におけるこの最近の変化を反映す るためにインクリメントされる。続いてブロック２２６において、新しいステー タスより大きな登録時間でのステータスをもつ全オブジェクトが、もはや実行さ れていないので、データベースから除かれる。次に、ブロック２２８において、 信号が解放され、この手続きはブロック２３０において終了する。ノードのサー ビ スステートがサーバーオブジェクト・データベースにおいてわかるので、ノード のステータスがダウングレードされるときにもはや妥当でないオブジェクトを除 くために、データベースが自動的に更新できる。 図１３は、ノードにおけるサービスステートの遷移を示すステート図である。 サービス外ステート１９６とＯＳミニマムステート２１０との間の遷移は、プラ ットフォームマネージャ４０、４１（図２）がアップであるか実行中であるかに より起こされる。もしプラットフォームマネージャがダウンであるなら、ノード はサービス外ステート１９６にある。もしプラットフォームマネージャがアップ でありアプリケーションソフトウエアが実行中でないなら、ノードはＯＳミニマ ムステート２１０にある。他方、もしプラットフォームマネージャがアップであ りアプリケーションソフトウエアが実行中であるなら、ノードはサービス中ステ ート２１６にある。ステート図により、全プラットフォームマネージャオブジェ クトが登録時にサービス外ステートを持つことや、すべての他のプロセスオブジ ェクトが、登録時にＯＳミニマムステートを持つことがわかる。 好ましくは、すべてのＤＯＭＥインターフェイスは、ランタイム共用ライブラ リにあり、要求されたランタイムでユーザーコードとリンクされる。共用ライブ ラリが２以上のプロセスによりアクセスできるので、ユーザーは、ユーザー自身 のプロセス空間においてＤＯＭＥオブジェクトをインスタンス化できる。ＤＯＭ Ｅのメンバー機能が参照されるので、共用ライブラリから実行時間でリンクされ る。 本発明とその効果が詳細に説明されたが、理解されるように、特許を請求する 範囲において定義される本発明の精神と範囲の中からはずれることなく、種々の 変形、置換、代替をすることができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者 シャー，マヘシュ・ブイ アメリカ合衆国75025テキサス州プラノ、 ボウイ・ドライブ2608番 【要約の続き】 ントオブジェクトによりアクセス可能であり、それらか らのサービスに関する要求を受け取る。クライアントサ ーバー・インターフェースは、クライアントオブジェク トの要求するサービスを実行可能な、少なくとも１つの 行き先サーバーオブジェクトを探すために上記サーバー オブジェクトデータベース(４６)にアクセスし、ローカ ルサイト又は遠隔サイトにある行き先サーバーオブジェ クトにサービス要求を送る。

Claims (1)

1. 【特許請求の範囲】 １． 少なくとも一つの通信リンクを介して互いに接続された多サイトであって 各サイトが少なくとも一つのコンピュータネットワークによって接続された複数 のプロセッサノードを有している多サイトのための分散オブジェクトメッセージ 伝達システムにおいて、 各プロセッサノードにおいて実行する複数のプロセスを備え、 上記複数のプロセスは複数のオブジェクトを登録し、該オブジェクトはクライ アントオブジェクトおよびサーバーオブジェクトを含み、各オブジェクトは該オ ブジェクトのインスタンスを少なくとも一つ有し、 上記複数のサーバープロセスは、ローカルノード、ローカルサイトにおけるク ライアントオブジェクトに対するサービス利用可能性のためのグローバルサービ ス、および／または、遠隔サイトにおけるクライアントオブジェクトに対するサ ービス利用可能性のためのサイトグローバルサービスに対して登録がされ、 登録された各サーバーオブジェクトに対するサーバーオブジェクト記述を格納 する、各プロセッサノードに存在するサーバーオブジェクト・データベースを備 え、該サーバーオブジェクト記述は、オブジェクト名、ノード名、サイト名、お よび、オブジェクトの１より多いインスタンスが同一プロセッサノードに登録さ れている場合にはインスタンス名を含み、 上記クライアントオブジェクトによってアクセス可能で上記クライアントオブ ジェクトからサービス要求を受け取り、上記要求されたサービスを実行すること ができる少なくとも一つの行き先サーバーオブジェクトの上記サーバーオブジェ クト・データベースにアクセスし、上記サービス要求をメッセージへとフォーマ ットし、該メッセージをローカルサイトまたは遠隔サイトの上記行き先サーバー オブジェクトへと転送するクライアントサーバーインタフェースを備えるシステ ム。 ２． 請求項１に記載のシステムにおいて、上記複数のプロセスが、過去のサー バーオブジェクト・データベースアクセス要求および行き先サーバーオブジェク トのローカルキャッシュを更に備えているシステム。 ３． 請求項２に記載のシステムにおいて、上記サーバーオブジェクト・データ ベースは、上記サーバーオブジェクト・データベースに対し実行される変更のカ ウントを記録する変更カウンタを更に備え、上記クライアントサーバーインタフ ェースは、上記サーバーオブジェクト・データベースにおける上記変更カウンタ の上記カウントに等しいローカル変更カウントに応じてサーバーオブジェクトを 一致させるために上記ローカルキャッシュにアクセスし、上記サーバーオブジェ クト・データベースにおける上記変更カウンタの上記カウントに等しくない上記 ローカル変更カウントに応じて上記サーバーオブジェクト・データベースにアク セスするシステム。 ４． 請求項１に記載のシステムにおいて、 遠隔プロセッサノードに存在する行き先オブジェクトへメッセージを送るため の、各プロセッサノードに存在するメッセージ処理プロセスと、 遠隔プロセッサノードに存在するオブジェクトからメッセージを受信するため の、各プロセッサノードに存在するリンクＴＣＰプロセスと、 を更に備えるシステム。 ５． 請求項４に記載のシステムにおいて、前記メッセージ処理プロセスおよび リンクＴＣＰプロセスは、プロセッサノードの間に、上記メッセージの送信およ び受信のための二地点間ＴＣＰ／ＩＰ経路を生成するシステム。 ６． 請求項１に記載のシステムにおいて、上記サーバーオブジェクト・データ ベースに格納された上記サーバーオブジェクト記述は、オブジェクト登録時にお けるプロセッサノードのサービス状態を更に含んでいるシステム。 ７． 請求項６に記載のシステムにおいて、上記プロセッサノードのサービス状 態は、サービス外状態、最小サービス状態、およびサービス中状態を含むシステ ム。 ８． 請求項６に記載のシステムにおいて、上記サーバーオブジェクト・データ ベースから、上記登録オブジェクトの常駐ノードの現時点のサービス状態よりも 高いサービス状態を有する登録オブジェクトが、上記常駐ノードのサービス状態 の低下に応じて取り除かれるシステム。 ９． 請求項６に記載のシステムにおいて、上記サーバーオブジェクト・データ ベースは、遠隔ノードのサーバーオブジェクト・データベースの新しいコピーに より、該遠隔ノードのサービス状態の向上に応じて置き換えられるシステム。 １０． 請求項１に記載のシステムにおいて、上記サーバーオブジェクト・デー タベースに格納された上記サーバーオブジェクト記述は、アクティブ／待機モー ドと負荷分散モードを含む上記登録オブジェクトの動作モードを更に含むシステ ム。 １１． 請求項１に記載のシステムにおいて、上記サーバーオブジェクト・デー タベースに格納された上記サーバーオブジェクト記述は、各登録オブジェクトに 対するメッセージキューＩＤを更に含むシステム。 １２． 請求項１に記載のシステムにおいて、上記サーバーオブジェクト・デー タベースに格納された上記サーバーオブジェクト記述は、上記登録オブジェクト に対する既知のポートＩＤを更に含むシステム。 １３． 各サイトが複数の相互接続ノードを有し、各ノードが該ノードで実行す る複数のプロセスを有している多サイトに対する分散オブジェクトメッセージ伝 達のための方法であって、 各ノードにおける複数プロセスにより複数のサーバーオブジェクトの少なくと も一つのインスタンスを登録し、該サーバーオブジェクトがローカルサービス、 グローバルサービスおよび／またはサイトグローバルサービスに対して登録され るステップと、 サーバーオブジェクト・データベースにおける各登録オブジェクトのサーバー オブジェクト記述を格納するステップであって、該サーバーオブジェクト記述は 、オブジェクト名、ノード名、サイト名、および、オブジェクトの一つ以上のイ ンスタンスが同一ノードに登録されている場合にはインスタンス名を含んでいる ステップと、 ローカルサイトにおける遠隔ノードに対するグローバルサービスに対して登録 されたサーバーオブジェクトの上記サーバーオブジェクト記述をブロードキャス トするステップと、 遠隔サイトにおけるノードからのサイトグローバルサービスに対して登録され たサーバーオブジェクトのサーバーオブジェクト記述を要求するステップと、 遠隔ノードにおける登録サーバーオブジェクトの上記サーバーオブジェクト記 述を受信し、受信した該サーバーオブジェクト記述を上記サーバーオブジェクト ・データベースに格納するステップと、 クライアントオブジェクトからのサービス要求を受信し、上記サーバーオブジ ェクト・データベースを検索して上記サービス要求を実行できる行き先サーバー オブジェクトを探し、上記サービス要求をメッセージへとフォーマットし、該メ ッセージをローカルサイトまたは遠隔サイトにおける上記行き先サーバーオブジ ェクトへ転送するステップと、 を有する方法。 １４． 請求項１３に記載の方法において、 上記サーバーオブジェクト・データベースに対して行われる変更の数に応じて 上記サーバーオブジェクト・データベースに変更カウントを格納するステップと 、 過去のサービス要求と該サービス要求を実行できる行き先サーバーオブジェク トとのローカル履歴キャッシュを各プロセスに格納するステップと、 ローカル変更カウントを上記ローカル履歴キャッシュに格納するステップと、 サービス要求と上記サーバーオブジェクト・データベースにおける上記変更カ ウントに等しい上記ローカル変更カウントとに応じて、上記ローカル履歴キャッ シュにアクセスするステップと、 サービス要求と上記サーバーオブジェクト・データベースにおける上記変更カ ウントに等しくない上記ローカル変更カウントとに応じて、上記サーバーオブジ ェクト・データベースにアクセスするステップと、 を更に有する方法。 １５． 請求項１４に記載の方法において、サーバーオブジェクト記述を格納す る上記ステップが、各登録オブジェクトに対してオブジェクト登録時におけるノ ードサービス状態を記憶するステップを更に含む方法。 １６． 請求項１５に記載の方法において、ノードサービス状態を記憶する上記 ステップが、サービス外状態、ミニマムサービス状態またはサービス中状態を記 憶するステップを更に含む方法。 １７． 請求項１５に記載の方法において、 ノードを下位のサービス状態へとダウングレードするステップと、 ダウングレードされた上記ノードの上記下位のサービス状態よりも高いサービ ス状態を有する上記ダウングレードノードに存在する登録オブジェクトを上記サ ーバーオブジェクト・データベースから除くステップと、 を更に有する方法。 １８． 請求項１５に記載の方法において、 ノードをより高いサービス状態へとアップグレードするステップと、 他の全てのノードに上記アップグレードされたノードのより高いサービス状態 を通知するステップと、 上記アップグレードされたノードのサーバーオブジェクト・データベースの内 容のコピーを要求するステップと、 サーバーオブジェクト・データベースにおける上記コピーを他の全てのノード に格納するステップと、 を有する方法。 １９． 請求項１３に記載の方法において、サーバーオブジェクト記述を格納す る上記ステップが、上記登録オブジェクトの動作モードを記憶するステップを更 に含み、該動作モードがアクティブ／待機モードおよび負荷分散モードを有して いる方法。 ２０． 請求項１３に記載の方法において、サーバーオブジェクト記述を格納す る上記ステップが、各登録オブジェクトに対するメッセージキューＩＤを記憶す るステップを更に含む方法。 ２１． 請求項１３に記載の方法において、サーバーオブジェクト記述を格納す る上記ステップが、各登録オブジェクトに対する既知のポートＩＤを記憶するス テップを更に含む方法。 ２２． 請求項１３に記載の方法において、サーバーオブジェクト記述を格納す る上記ステップが、アクティブ／待機モードまたは負荷分散モードを指定する動 作モードを記憶するステップを更に含む方法。 ２３． 請求項２２に記載の方法において、上記サーバーオブジェクト・データ ベースを検索して行き先サーバーオブジェクトを探す上記ステップは、負荷分散 モードに対して登録されている上記サーバーオブジェクトに応じて、上記行き先 サーバーオブジェクトの間に実質的に均等にサービス要求を分配するステップを 含んでいる方法。 ２４． 請求項２２に記載の方法において、上記サーバーオブジェクト・データ ベースを検索して行き先サーバーオブジェクトを探す上記ステップは、負荷分散 モードに対して登録されている上記サーバーオブジェクトに応じて、ラウンドロ ビンアルゴリズムを用いて上記行き先サーバーオブジェクトの間に実質的に均等 にサービス要求を分配するステップを含んでいる方法。 ２５． 請求項１３に記載の方法において、上記メッセージを上記行き先サーバ ーオブジェクトに転送する上記ステップは、上記行き先サーバーオブジェクトが 存在する行き先ノードへの通信リンクを確立するステップを含んでいる方法。 ２６． 請求項１３に記載の方法において、上記メッセージを上記行き先サーバ ーオブジェクトに転送する上記ステップは、上記行き先サーバーオブジェクトが 存在する行き先ノードへのＴＣＰ／ＩＰ通信リンクを確立するステップを含んで いる方法。 ２７． 請求項１３に記載の方法において、上記メッセージを上記行き先サーバ ーオブジェクトに転送する上記ステップは、上記行き先サーバーオブジェクトが 存在する行き先ノードのＵＤＰ／ＴＬＩソケット接続によって上記メッセージを 転送するステップを含んでいる方法。 ２８． 請求項２５に記載の方法において、上記メッセージを上記行き先サーバ ーオブジェクトに転送する上記ステップは、 上記フォーマットされたメッセージをメッセージハンドラープロセスに転送し 、該メッセージハンドラープロセスが該メッセージを上記行き先ノードにおける リンクＴＣＰプロセスへ送信するステップと、 上記メッセージを上記行き先サーバーオブジェクトに転送するステップと、 を有している方法。 ２９． 請求項１３に記載の方法において、上記行き先サーバーオブジェクトか ら応答を受信するステップを更に有する方法。 ３０． 多くの物理的に離れたサイトにおいて実行する電話アプリケーションに おいて、多くのサイトの間での分散されたオブジェクトメッセージのための方法 であって、各サイトは相互接続された多数のノードを有し、各ノードは、その中 において実行する多数のプロセスを有しており、上記方法は、 各ノードにおける複数のプロセスにより複数のサーバーオブジェクトの内の少 なくとも１つのインスタンスを登録し、上記サーバーオブジェクトはローカルノ ードに対するサービス、ローカルサイトに対するグローバルサービス、及び／又 は、複数の遠隔サイトに対するサイトグローバルサービスのために登録されてお り、 サーバーオブジェクト・データベースに登録されている各オブジェクトのサー バーオブジェクト記述を格納し、上記サーバーオブジェクト記述はオブジェクト 名、ノード名、サイト名、及び、同じノードにオブジェクトのインスタンスが２ 以上登録されている場合にはインスタンス名を含むステップ、 ローカルサイトにおいて遠隔ノードへのグローバルサービスのために登録され たサーバーオブジェクトの上記サーバーオブジェクト記述をブロードキャストし 、ブロードキャストされた上記サーバーオブジェクト記述は、上記遠隔ノードで のサーバーオブジェクト・データベースに格納されているステップ、 遠隔サイトでの複数のノードからサイトグローバルサービスのために登録され たサーバーオブジェクトのサーバーオブジェクト記述を要求するステップ、 遠隔ノードにおいて登録されたサーバーオブジェクトの上記サーバーオブジェ クト記述を受け取り、受け取ったサーバーオブジェクト記述をサーバーオブジェ クト・データベースに格納するステップ、 クライアントオブジェクトからのサービス要求を受け取り、上記サービス要求 を実行できる行き先サーバーオブジェクトのため上記サーバーオブジェクト・デ ータベースを検索し、上記サービス要求をメッセージにフォーマットし、ローカ ルサイト又は遠隔サイトでの上記行き先サーバーオブジェクトに上記メッセージ を送るステップ からなる方法。 ３１． 請求項３０に記載の方法であって、さらに、 上記サーバーオブジェクト・データベースで形成される変更の数に応じて上記 サーバーオブジェクト・データベースにおける変更カウントを格納するステップ 、 過去のサービス要求のローカル履歴キャッシュ、及び、各プロセスにおいてサ ービス要求を実行可能な行き先サーバーオブジェクトを格納するステップ、 上記ローカル履歴キャッシュにおけるローカル変更カウントを格納するステッ プ、 サービス要求と、上記サーバーオブジェクト・データベースにおける上記変更 カウントと等しいローカル変更カウントに対応して上記ローカル履歴キャッシュ をアクセスするステップ、 サービス要求と、上記サーバーオブジェクト・データベースにおける上記変更 カウントとは等しくない上記ローカル変更カウントとに応じて上記サーバーオブ ジェクト・データベースをアクセスするステップ を備えることを特徴とする方法。 ３２． 請求項３１に記載の方法であって、 上記サーバーオブジェクト記述を格納するステップは、さらに、登録された各 オブジェクトに関し、オブジェクト登録時におけるノードサービスステートを格 納するステップを含むことを特徴とする方法。 ３３． 請求項３２に記載の方法において、 上記ノードサービスステートを格納するステップは、さらに、サービス外ステ ート、ミニマムサービスステート又はサービス中ステートを格納するステップを 含むことを特徴とする方法。 ３４． 請求項３２に記載の方法であって、さらに、 ノードをより低いサービスステートへダウングレードするステップ、および 上記ダウングレードされたノードの上記の低いサービスステートよりも高いサ ービスステートを有し、上記ダウングレードされたノードに常駐する登録された オブジェクトを、上記サーバーオブジェクト・データベースより除去するステッ プ を備えることを特徴とする方法。 ３５．請求項３２に記載の方法であって、さらに、 ノードをより高いサービスステートへアップグレードするステップ、 上記アップグレードされたノードのより高いサービスステートを他の全てのノ ードに通知するステップ、 上記アップグレードされたノードのサーバーオブジェクト・データベースの内 容のコピーを要求するステップ、 他の全てのノードにおけるサーバーオブジェクト・データベースに上記コピー を格納させるステップ を備えることを特徴とする方法。 ３６． 請求項３０に記載の方法であって、 サーバーオブジェクト記述を格納するステップは、さらに、上記登録されたオ ブジェクトの操作モードを格納するステップを備え、上記操作モードは、アクテ ィブ／待機モード及び負荷分散モードを備えることを特徴とする方法。 ３７． 請求項３０に記載の方法であって、サーバーオブジェクト記述を格納す るステップは、さらに、各々の登録されたオブジェクトに対するメッセージキュ ーＩＤを格納するステップを備えることを特徴とする方法。 ３８． 請求項３０に記載の方法であって、サーバーオブジェクト記述を格納す るステップは、さらに、各々の格納されたオブジェクトに対する周知のポートＩ Ｄを格納するステップを備えることを特徴とする方法。 ３９． 請求項３０に記載の方法であって、サーバーオブジェクト記述を格納す るステップは、さらに、アクティブ／待機モード又は負荷分散モードを指定する 操作を格納するステップを備えることを特徴とする方法。 ４０． 請求項３９に記載の方法は、行き先サーバーオブジェクトに関して上記 サーバーオブジェクト・データベースを検索するステップは、負荷分散操作モー ドのために登録されている上記サーバーオブジェクトに応じて上記行き先サーバ ーオブジェクト間でサービス要求を実質的に等しく分散するステップを備えるこ とを特徴とする方法。 ４１． 請求項３９に記載の方法であって、行き先サーバーオブジェクトに関し て上記サーバーオブジェクト・データベースを検索するステップは、負荷分散操 作モードのために登録されている上記サーバーオブジェクトに応じてラウンドロ ビン・アルゴリズムを利用する上記行き先サーバーオブジェクト間でサービス要 求を実質的に等しく分散するステップを備えることを特徴とする方法。 ４２． 請求項３０に記載の方法であって、上記行き先サーバーオブジェクトに 上記メッセージを送信するステップは、上記行き先サーバーオブジェクトが属す る行き先ノードに通信リンクを確立するステップを備えることを特徴とする方法 。 ４３． 請求項３０に記載の方法において、上記行き先サーバーオブジェクトに 上記メッセージを送信するステップは、上記行き先サーバーオブジェクトが属す る行き先ノードにＴＣＰ／ＩＰ通信リンクを確立するステップを備えることを特 徴とする方法。 ４４． 請求項３０に記載の方法において、上記行き先サーバーオブジェクトに 上記メッセージを送信するステップは、上記行き先サーバーオブジェクトが属す る行き先ノードのＵＤＰ／ＴＬＩソケット接続を介して上記メッセージを送信す るステップを備えることを特徴とする方法。 ４５． 請求項４２に記載の方法において、上記行き先サーバーオブジェクトに 上記メッセージを送信するステップは、 上記のフォーマットされたメッセージをメッセージハンドラーに送り、このメ ッセージハンドラーは上記行き先ノードにおけるリンクＴＣＰプロセスに上記メ ッセージを送るステップと、 上記のメッセージを上記行き先サーバーオブジェクトへ送るステップ を備えることを特徴とする方法。 ４６． 請求項３０に記載の方法において、さらに、上記行き先サーバーオブジ ェ クトから応答を受け取るステップを備えることを特徴とする方法。