(57)【要約】【課題】ネーミングサービスがオブジェクトの稼動状態を確認することにより、より適切なオブジェクトの検索結果をクライアントへ応答することができる分散オブジェクトの検索システムを提供する。【解決手段】ネットワーク１０７によって夫々サーバ１０８及びクライアント１１１に通信自在に接続される複数のネーミングサービス１０１が連携して相互に通信自在に接続される分散オブジェクトの検索システムであって、ネーミングサービス１０１は、クライアント１１１から、検索要求を受信すると、名前空間テーブル１０５に検索要求のオブジェクトの参照情報が存在するか照合する手段と、存在が確認されると、オブジェクトの参照情報の実態であるサーバ１０８へ存在確認要求を送信し稼動状態を確認する手段と、サーバ１０８が稼動している場合は、クライアント１１１へサーバ１０８のオブジェクトの参照情報を返信する手段等を備えている。【選択図】図１
2009271850.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークによって夫々サーバ及びクライアントに通信自在に接続される複数のネーミングサービスが連携して相互に通信自在に接続され、前記ネーミングサービスは、連携する他のネーミングサービスの情報を格納する連携ネーミングテーブルと、サーバの位置情報であるネームコンポーネント及びオブジェクトの参照情報を格納する名前空間テーブルとを夫々備えた分散オブジェクトの検索システムであって、
前記ネーミングサービスは、稼動監視を行うため、前記名前空間テーブルに登録されているサーバに対して、稼動状態監視間隔の時間が経過するごとに存在確認要求を送信する手段と、
存在確認要求に対するリプライを受信することができない場合は、前記名前空間テーブルから前記サーバのオブジェクトの参照情報のエントリを削除する手段と、
前記クライアントから、サーバのネームコンポーネントを指定した検索要求を受信すると、前記名前空間テーブルに検索要求のオブジェクトの参照情報が存在するか照合する手段と、
前記オブジェクトの参照情報の存在が確認されると、前記オブジェクトの参照情報の実態であるサーバへ存在確認要求を送信し稼動状態を確認する手段と、
前記サーバからリプライを受信できなかった場合は、前記名前空間テーブルから前記サーバのオブジェクトの参照情報のエントリを削除し、前記クライアントへ検索失敗を通知する手段と、
前記サーバが稼動している場合は、前記サーバからリプライとして存在通知を受信し、前記クライアントへ前記サーバのオブジェクトの参照情報を返信する手段とを備えたことを特徴とする分散オブジェクトの検索システム。
【請求項２】
前記ネーミングサービスは、前記クライアントからサーバのネームコンポーネントを指定した検索要求を受信した時、前記名前空間テーブルに前記検索要求のオブジェクトの参照情報の存在が確認されない場合、前記連携ネーミングテーブルから連携済みでないネーミングサービスを選択する手段と、
検索要求のサービスコンテキストに自らのオブジェクトＵＲＬを追加して、選択されたネーミングサービスに対し送信する手段と、
他の連携ネーミングサービスからオブジェクトの参照情報が設定されたリプライを受信すると、前記名前空間情報テーブルに前記オブジェクトの参照情報を登録する手段と、
前記オブジェクトの参照情報を前記クライアントへ返信する手段と、
他の連携ネーミングサービスから検索失敗のリプライを受信すると、
前記クライアントへ前記検索失敗を返信する手段とを備えたことを特徴とする請求項１記載の分散オブジェクトの検索システム。
【請求項３】
前記ネーミングサービスは、連携済みネーミングサービスからサーバのネームコンポーネントを指定した検索要求を受信した時、前記名前空間テーブルに検索要求のオブジェクトの参照情報が存在するか照合する手段と、
前記オブジェクトの参照情報の存在が確認されると、前記オブジェクトの参照情報の実態であるサーバへ存在確認要求を送信し稼動状態を確認する手段と、
前記サーバからリプライを受信できなかった場合は、リプライのサービスコンテキストへ自らのオブジェクトＵＲＬを追加し、前記連携済みネーミングサービスへ検索失敗を通知する手段と、
前記サーバが稼動している場合は、前記サーバからリプライとして存在通知を受信し、リプライとして前記サーバのオブジェクトの参照情報を設定し、サービスコンテキストに自らのオブジェクトＵＲＬを追加して前記連携済みネーミングサービスへ返信する手段と、
前記名前空間テーブルに検索要求のオブジェクトの参照情報の存在が確認されない場合、前記検索要求のサービスコンテキストに設定された連携済みネーミングサービスを取得し、前記連携ネーミングテーブルから連携済みでないネーミングサービスを選択する手段と、
選択されたネーミングサービスに対し、前記検索要求のサービスコンテキストに自らのオブジェクトＵＲＬを追加して送信する手段と、
前記連携ネーミングテーブルに連携済みでないネーミングサービスが存在しない場合、検索要求を受信した前記連携済みネーミングサービスへ、リプライのサービスコンテキストに自らのオブジェクトＵＲＬを追加して検索失敗を送信する手段と、
他の連携ネーミングサービスからオブジェクトの参照情報が設定されたリプライを受信すると、前記名前空間情報テーブルに前記オブジェクトの参照情報を登録する手段と、
検索要求を受信した前記連携済みネーミングサービスへ前記オブジェクトの参照情報を返信する手段と、
他の連携ネーミングサービスから検索失敗のリプライを受信すると、検索要求を受信した前記連携済みネーミングサービスへ前記リプライを返信する手段とを備えたことを特徴とする請求項１または２記載の分散オブジェクトの検索システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネーミングサービスに登録されたオブジェクトの稼動状態を監視するための分散オブジェクトの検索システムに関するものである。
【背景技術】
【０００２】
分散オブジェクトを使ったシステムにおいて、オブジェクトの呼び出しには、呼び出すオブジェクトの参照情報を知る必要がある。オブジェクトの参照情報を取得する方法の一つに、ＯＭＧ（Object Management Group）が提供している公式文書Common
Object Request Broker Architecture:Core Specificationに記載されているネーミングサービスを利用する方法がある。ネーミングサービスは階層的な名前空間でオブジェクトの参照情報を管理するものである。
なお、本発明に関連する公知技術文献としては下記の特許文献１がある。特許文献１は、オブジェクト連鎖情報記憶手段を設けたことにより、分散オブジェクトを呼び出す度にアドレスの問い合わせをしなくてもよく、アプリケーション全体におけるオーバヘッドが軽減され、アプリケーションの処理性能を向上させることができるものである。
【特許文献１】特開２００１−２５６２０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のネーミングサービスの構成では、クライアントから検索要求(resolveオペレーション等)を受け付けると、オブジェクトの稼動状態に関わらず、オブジェクトの参照情報をクライアントへ戻していた。即ち、従来のネーミングサービスは明示的に登録されたオブジェクトの参照情報しか管理しておらず、リアルタイムな状態を管理していないため、オブジェクトの稼動状態を確認することができなかった。
【０００４】
従って、ネーミングサービスから検索したオブジェクトの参照情報であっても、実際上は稼動していないオブジェクトが含まれる場合があるため、クライアントによる不要な接続処理が発生し、システム全体の性能を低下させる要因になっている。また、検索要求を送信したネーミングサービスに対象のオブジェクトの参照情報が存在しない場合でも、他方のネーミングサービスには登録されている可能性もあり、検索要求は単体のネーミングサービスに閉じた要件ではなく、システム全体でのリアルタイムの検索結果が反映されることが期待されるようになった。
【０００５】
以上の現状に鑑み、本発明は、ネーミングサービスがオブジェクトの稼動状態を確認すると共に、その他のネーミングサービスと連携することにより、より適切なオブジェクトの検索結果をクライアントへ応答することを可能とする分散オブジェクトの検索システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記の課題を解決すべく、本発明は以下の構成を提供する。
請求項１に係る発明は、ネットワークによって夫々サーバ及びクライアントに通信自在に接続される複数のネーミングサービスが連携して相互に通信自在に接続され、前記ネーミングサービスは、連携する他のネーミングサービスの情報を格納する連携ネーミングテーブルと、サーバの位置情報であるネームコンポーネント及びオブジェクトの参照情報を格納する名前空間テーブルとを夫々備えた分散オブジェクトの検索システムであって、
前記ネーミングサービスは、稼動監視を行うため、前記名前空間テーブルに登録されているサーバに対して、稼動状態監視間隔の時間が経過するごとに存在確認要求を送信する手段と、
存在確認要求に対するリプライを受信することができない場合は、前記名前空間テーブルから前記サーバのオブジェクトの参照情報のエントリを削除する手段と、
前記クライアントから、サーバのネームコンポーネントを指定した検索要求を受信すると、前記名前空間テーブルに検索要求のオブジェクトの参照情報が存在するか照合する手段と、
前記オブジェクトの参照情報の存在が確認されると、前記オブジェクトの参照情報の実態であるサーバへ存在確認要求を送信し稼動状態を確認する手段と、
前記サーバからリプライを受信できなかった場合は、前記名前空間テーブルから前記サーバのオブジェクトの参照情報のエントリを削除し、前記クライアントへ検索失敗を通知する手段と、
前記サーバが稼動している場合は、前記サーバからリプライとして存在通知を受信し、前記クライアントへ前記サーバのオブジェクトの参照情報を返信する手段とを備えたことを特徴とする分散オブジェクトの検索システムを提供するものである。
【０００７】
請求項２に係る発明は、前記ネーミングサービスは、前記クライアントからサーバのネームコンポーネントを指定した検索要求を受信した時、前記名前空間テーブルに前記検索要求のオブジェクトの参照情報の存在が確認されない場合、前記連携ネーミングテーブルから連携済みでないネーミングサービスを選択する手段と、
検索要求のサービスコンテキストに自らのオブジェクトＵＲＬを追加して、選択されたネーミングサービスに対し送信する手段と、
他の連携ネーミングサービスからオブジェクトの参照情報が設定されたリプライを受信すると、前記名前空間情報テーブルに前記オブジェクトの参照情報を登録する手段と、
前記オブジェクトの参照情報を前記クライアントへ返信する手段と、
他の連携ネーミングサービスから検索失敗のリプライを受信すると、
前記クライアントへ前記検索失敗を返信する手段とを備えたことを特徴とする請求項１記載の分散オブジェクトの検索システムを提供するものである。
【０００８】
請求項３に係る発明は、前記ネーミングサービスは、連携済みネーミングサービスからサーバのネームコンポーネントを指定した検索要求を受信した時、前記名前空間テーブルに検索要求のオブジェクトの参照情報が存在するか照合する手段と、
前記オブジェクトの参照情報の存在が確認されると、前記オブジェクトの参照情報の実態であるサーバへ存在確認要求を送信し稼動状態を確認する手段と、
前記サーバからリプライを受信できなかった場合は、リプライのサービスコンテキストへ自らのオブジェクトＵＲＬを追加し、前記連携済みネーミングサービスへ検索失敗を通知する手段と、
前記サーバが稼動している場合は、前記サーバからリプライとして存在通知を受信し、リプライとして前記サーバのオブジェクトの参照情報を設定し、サービスコンテキストに自らのオブジェクトＵＲＬを追加して前記連携済みネーミングサービスへ返信する手段と、
前記名前空間テーブルに検索要求のオブジェクトの参照情報の存在が確認されない場合、前記検索要求のサービスコンテキストに設定された連携済みネーミングサービスを取得し、前記連携ネーミングテーブルから連携済みでないネーミングサービスを選択する手段と、
選択されたネーミングサービスに対し、前記検索要求のサービスコンテキストに自らのオブジェクトＵＲＬを追加して送信する手段と、
前記連携ネーミングテーブルに連携済みでないネーミングサービスが存在しない場合、検索要求を受信した前記連携済みネーミングサービスへ、リプライのサービスコンテキストに自らのオブジェクトＵＲＬを追加して検索失敗を送信する手段と、
他の連携ネーミングサービスからオブジェクトの参照情報が設定されたリプライを受信すると、前記名前空間情報テーブルに前記オブジェクトの参照情報を登録する手段と、
検索要求を受信した前記連携済みネーミングサービスへ前記オブジェクトの参照情報を返信する手段と、
他の連携ネーミングサービスから検索失敗のリプライを受信すると、検索要求を受信した前記連携済みネーミングサービスへ前記リプライを返信する手段とを備えたことを特徴とする請求項１または２記載の分散オブジェクトの検索システムを提供するものである。
【発明の効果】
【０００９】
本発明によれば、クライアントからの検索要求に対し、稼動状態が確認されたもののオブジェクトの参照情報を検索要求のリプライに含めることとしたので、クライアントに対して実際に稼動しているオブジェクトにのみ接続させることが可能となり、検索結果にリアルタイムのオブジェクト稼動状態を反映させることができる。
また、稼動状態は起動時に設定された時間間隔で定期的に監視するようにしたため、既にシステムから消滅したオブジェクトへの不要な接続処理は行われなくなる。
更に、ネーミングサービス同士を連携する手段を備えたので、自らの名前空間テーブルで解決できない検索要求はその他のネーミングサービスと連携して解決することが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、実施例を示した図面を参照しつつ、本発明を適用した分散オブジェクトの検索システムの一実施の形態について説明する。
図１は、本発明の実施の形態の一例を示すブロック構成図である。
本分散オブジェクトの検索システムは、ネットワーク１０７で接続されたネーミングサービス１０１、サーバ１０８、クライアント１１１で実現されるシステムである。
ネーミングサービス１０１は、オブジェクトの稼動監視を行う稼動状態監視部１０２と任意のネームコンポーネントとオブジェクトの参照情報の検索要求を解決するネーミングサービス部１０４で構成される。
サーバ１０８はオペレーション実行部１１０を備え、ネットワーク１０７のどこからでも接続できるように自身のオブジェクトの参照情報をネーミングサービス１０１へ登録する。
クライアント１１１はオペレーション呼び出し部１１３を備え、ネーミングサービス１０１からサーバ１０８のオブジェクトの参照情報を検索し、分散オブジェクト基盤１０９を介してサーバ１０８のオペレーション実行部１１０を動作させることができる。
【００１１】
図２は、ネーミングサービス１０１で保持するテーブルの構成要素の一例を示す図である。
稼動状態監視部１０２は連携する他のネーミングサービスの情報を持つ連携ネーミングテーブル１０３を備えている。一つのエントリには他のネーミングサービスのオブジェクトＵＲＬとオブジェクトの参照情報を格納する。
ネーミングサービス部１０４はサーバの位置情報を持つ名前空間テーブル１０５を備えている。一つのエントリには任意のネームコンポーネントとサーバのオブジェクトの参照情報を格納する。
【００１２】
図３は、稼動状態監視部１０２における初期化処理の概要を示すフローチャートである。稼動状態監視部１０２はネーミングサービス１０１の起動時に初期化を行い、オブジェクトの稼動状態監視間隔を登録する（ステップ３０１、３０２、３０３）。次に、連携するネーミングサービスのオブジェクトＵＲＬからオブジェクトの参照情報を生成し、連携ネーミングテーブル１０３へ登録する（ステップ３０４、３０５、３０６）。稼動状態監視間隔および連携するネーミングサービスのオブジェクトＵＲＬはネーミングサービス１０１起動時にパラメータとして与えられるものとする。
【００１３】
図４は、ネーミングサービス１０１が登録されたオブジェクトを定期的に稼動監視する実施の形態の一例であり、図５は、ネーミングサービス１０１の定期的な稼動状態監視処理のフローチャートである。
ネーミングサービス１０１は稼動状態監視間隔の時間が経過するごとに、名前空間テーブル１０５に登録されているオブジェクトの稼動監視を行う（ステップ５０１、５０２）。
稼動状態の確認は、名前空間テーブル１０５に登録されているオブジェクトの参照情報の実態であるサーバＡ４０２、サーバＢ４０３、サーバＣ４０４に対して、存在確認要求（＿ｎｏｎ＿ｅｘｉｓｔｅｎｔオペレーション）を送信することにより行う。
【００１４】
図４では、サーバＡ４０２およびサーバＢ４０３は稼動しているため、存在確認要求に対するリプライとして存在通知を受信することができる。一方、サーバＣ４０４は稼動しておらず、ネーミングサービス１０１は存在確認要求に対するリプライを受信することができない。このような場合は、ネーミングサービス１０１が名前空間テーブル１０５からサーバＣ４０４のオブジェクトの参照情報のエントリであるＲｅｆｅｒｅｎｃｅＣ４０１を削除することにより、以降クライアントから検索要求があってもサーバＣ４０４のオブジェクトの参照情報を返信しないようにし、クライアントからの不要な接続処理を回避させる（ステップ５０３、５０４）。また、サーバＣ４０４は稼動しているが対象のオブジェクトだけが非活性化されている場合も考えられる。サービス閉塞などで一時的にオブジェクトが不活動状態になっているだけの可能性もあるため、この場合は名前空間テーブル１０５からは削除しない。
【００１５】
図６、図７はオブジェクトをリアルタイムに稼動監視を実施する形態の一例であり、図８、図９は他のネーミングサービスと連携する場合の実施の形態の一例である。図１０は、ネーミングサービス１０１がリアルタイムに稼動監視する処理と他のネーミングサービスと連携する処理の概要を示すフローチャートである。
【００１６】
図６に於いて、クライアントＡ６０１は、例えば、サーバＢ６０２のネームコンポーネントを指定しネーミングサービス１０１へ検索要求を送信する。一般的なネーミングサービスでは名前空間テーブル１０５に存在するＲｅｆｅｒｅｎｃｅＢ２０４をクライアントＡ６０１へ即座に返信する。この場合、クライアントＡ６０１は既にシステムとして稼動していないことが分かっているサーバＢ６０２に対して不要な接続処理を試みる。ＲｅｆｅｒｅｎｃｅＢ２０４を検索するクライアントが増えれば増えるほど、システム全体の不要な処理は増大していくことになる。
【００１７】
本発明によるネーミングサービスでは、名前空間テーブル１０５に存在するＲｅｆｅｒｅｎｃｅＢ２０４をクライアント６０１へ返信する前に、ＲｅｆｅｒｅｎｃｅＢ２０４の実態であるサーバＢ６０２へ存在確認要求を送信し稼動状態を確認する（ステップ１００１、１００２、１００３）。サーバＢ６０２からリプライを受信できなかった場合は、名前空間テーブル１０５からＲｅｆｅｒｅｎｃｅＢ２０４のエントリを削除し、クライアントＡ６０１へ検索失敗（ＮｏｔＦｏｕｎｄ例外）を通知する（ステップ１００５、１００６）。この場合、クライアントＡ６０１はサーバＢ６０２に対する不要な接続処理を行わず、必要であれば次の復旧手段の処理に移ることができる。
【００１８】
図７に於いて、サーバＢ７０２のように稼動している場合は、ネーミングサービス１０１はサーバＢ７０２からリプライとして存在通知を受信し、クライアントＡ７０１へＲｅｆｅｒｅｎｃｅＢ２０４を返信する（ステップ１００４）。
【００１９】
また、本発明によるネーミングサービス１０１ではクライアントから検索要求されたネームコンポーネントが名前空間テーブル１０５に存在しなかった場合は、図８に示すように他のネーミングサービスに同一のネームコンポーネントが存在しているかどうか確認することができる。ネーミングサービスＡ８０１、ネーミングサービスＢ８０６、ネーミングサービスＣ８１１は連携するネーミングサービスとして互いのオブジェクトＵＲＬを起動時に指定し、各々の連携ネーミングテーブル８０２、連携ネーミングテーブル８０７、連携ネーミングテーブル８１２へオブジェクトの参照情報と共に登録している。
ネーミングサービスＡ８０１はクライアントから／Ｂａｎｋ／ＳｅｒｖｅｒＤ８１６の検索要求があると、名前空間テーブル８０５に存在しないことを確認した後、連携ネーミングテーブル８０２からＮａｍｅＲｅｆｅｒｅｎｃｅＢ８０３を選択し、検索要求８１７のサービスコンテキストに自らのオブジェクトＵＲＬを追加してからネーミングサービスＢ８０６へ送信する（ステップ１００７、１００８、１００９、１０１０）。
サービスコンテキストとは、識別子となるｃｏｎｔｅｘｔ＿ｉｄと、その内容を表すｃｏｎｔｅｘｔ＿ｄａｔａからなるリクエストおよびリプライの付加情報であり、その仕様はＣＯＲＢＡで規定されている。ｃｏｎｔｅｘｔ＿ｉｄはＯＭＧからＣＯＲＢＡベンダでユニークな識別子を採番してもらうことができ、ベンダ独自の実装をすることが可能である。
【００２０】
本発明ではこのサービスコンテキストを連携済みネーミングサービスの情報を格納する領域として使用する。これにより、連携するネーミングサービス同士が互いを重複して検索することを防ぎ、効率の良い検索要求の伝達が可能となる。
ネーミングサービスＡ８０１から検索要求８１７を受信したネーミングサービスＢ８０６は、名前空間テーブル８１０に存在しないことを確認した後、検索要求８１７のサービスコンテキストから連携済みネーミングサービス情報としてネーミングサービスＡ８０１のオブジェクトＵＲＬを取得する（ステップ１００７）。連携ネーミングテーブル８０７からまだ連携済みでないＮａｍｅＲｅｆｅｒｅｎｃｅＣ８０９を選択し、検索要求８１７のサービスコンテキストに自らのオブジェクトＵＲＬを追加した検索要求８１８をネーミングサービスＣ８１１へ送信する（ステップ１００８、１００９、１０１０）。
【００２１】
ネーミングサービスＢ８０６から検索要求８１８を受信したネーミングサービスＣ８１１は、名前空間テーブル８１５から／Ｂａｎｋ／ＳｅｒｖｅｒＤ８１６に対応するＲｅｆｅｒｅｎｃｅＤ８２１を取得し、存在確認要求をサーバに送信する。サーバから存在通知を受信したネーミングサービスＣ８１１は、検索要求８１８のリプライとしてＲｅｆｅｒｅｎｃｅＤ８２１を設定し、サービスコンテキストに自らのオブジェクトＵＲＬを追加したリプライ８１９をネーミングサービスＢ８０６へ返信する（ステップ１０１０）。リプライ８１９を受信したネーミングサービスＢ８０６は、オブジェクトの参照情報が返信（ステップ１０１１）されたことを受けて名前空間情報テーブル８１０に／Ｂａｎｋ／ＳｅｒｖｅｒＤに対応するＲｅｆｅｒｅｎｃｅＤを登録し、ＲｅｆｅｒｅｎｃｅＤが設定されたリプライ８２０をネーミングサービスＡ８０１へ返信する（ステップ１０１２）。リプライ８２０を受信したネーミングサービスＡ８０１は、オブジェクトの参照情報が返信された（ステップ１０１１）ことを受けて名前空間情報テーブル８０５に／Ｂａｎｋ／ＳｅｒｖｅｒＤに対応するＲｅｆｅｒｅｎｃｅＤを登録し、ＲｅｆｅｒｅｎｃｅＤをクライアントへ返信する（ステップ１０１２）。クライアントはネーミングサービスＡ８０１だけでは解決できなかった稼動確認済みのＲｅｆｅｒｅｎｃｅＤへ接続を行う事ができる。
【００２２】
なお、図９に示すネーミングサービスＣ８１１で名前空間テーブル８１５からＲｅｆｅｒｅｎｃｅＤを解決できなかった場合は、連携ネーミングテーブル８１２による他のネーミングサービスとの連携を試みるが、検索要求８１８のサービスコンテキストに連携ネーミングテーブル８１２のオブジェクトＵＲＬが全て含まれているため、ネーミングサービスＣ８１１はこれ以上連携対象となるネーミングサービスはないものと判定する。この場合、ネーミングサービスＣ８１１はリプライ９０１のサービスコンテキストへ自らのオブジェクトＵＲＬを追加してから、ネーミングサービスＢ８０６へ検索失敗を返信する（ステップ１００６）。以降、ネーミングサービスＢ８０６およびネーミングサービスＡ８０１でも同様にこれ以上連携対象となるネーミングサービスはないものと判定し、クライアントへ検索失敗を返信する（ステップ１００６）。
【図面の簡単な説明】
【００２３】
【図１】本発明による分散オブジェクトの検索システムの実施の形態の一例を示すブロック構成図である。
【図２】本発明によるネーミングサービスで保持するテーブルの構成要素の一例を示す図である。
【図３】本発明による稼動状態監視部における初期化処理の概要を示すフローチャートである。
【図４】本発明によるネーミングサービスが、登録されたオブジェクトを定期的に稼動監視する実施の形態の一例を示す図である。
【図５】本発明によるネーミングサービスの定期的な稼動状態監視処理のフローチャートである。
【図６】本発明によるオブジェクトをリアルタイムに稼動監視する形態の異常ケースの一例を示す図である。
【図７】本発明によるオブジェクトをリアルタイムに稼動監視する形態の正常ケースの一例を示す図である。
【図８】本発明によるネーミングサービスと連携する場合の実施の形態の正常ケースの一例を示す図である。
【図９】本発明によるネーミングサービスと連携する場合の実施の形態の異常ケース一例を示す図である。
【図１０】本発明によるネーミングサービスがリアルタイムに稼動監視する処理と他のネーミングサービスと連携する処理の概要を示すフローチャートである。
【符号の説明】
【００２４】
１０１，８０１，８０６，８１１  ネーミングサービス
１０３，８０２，８０７，８１２  連携ネーミングテーブル
１０５，８０５，８１０，８１５  名前空間テーブル
１０７  ネットワーク
１０８，４０２，４０３，４０４，６０２，７０２  サーバ
１１１，６０１，７０１  クライアント
２０１，２０３  オブジェクトの参照情報
８１７，８１８  検索要求
８１９，８２０，９０１，９０２  リプライ
【図１】
2009271850.tif 000003
【図２】
2009271850.tif 000004
【図３】
2009271850.tif 000005
【図４】
2009271850.tif 000006
【図５】
2009271850.tif 000007
【図６】
2009271850.tif 000008
【図７】
2009271850.tif 000009
【図８】
2009271850.tif 000010
【図９】
2009271850.tif 000011
【図１０】
2009271850.tif 000012