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