(57)【特許請求の範囲】
【請求項１】
分散オブジェクトのオブジェクトリファレンスを管理する分散オブジェクトリファレンス管理方法において、
サーバアプリケーションを識別する為の情報であるアプリケーション識別情報を付加したオブジェクトリファレンス登録要求をネームサーバへ送信してオブジェクトリファレンスの登録要求を行うステップと、前記送信されたオブジェクトリファレンス登録要求に付加されているアプリケーション識別情報を登録要求の行われた名前及びオブジェクトリファレンスのペアを一つ以上関連付けてネームサーバに保持するステップと、
サーバアプリケーションに何らかの停止要因が発生した場合にそのアプリケーション識別情報を指定してオブジェクトリファレンスの削除要求を行うステップと、前記削除要求で指定されたアプリケーション識別情報に関連付けられた名前及びオブジェクトリファレンスのペアを全てネームサーバから削除するステップとを有することを特徴とする分散オブジェクトリファレンス管理方法。
【請求項２】
サーバアプリケーションを起動したプロセス制御部を識別する為のプロセス制御部識別子を前記アプリケーション識別情報としてネームサーバに保持し、プロセス制御部の停止の際に当該プロセス制御部のプロセス制御部識別子に対応付けられたオブジェクトリファレンスを削除することを特徴とする請求項１に記載された分散オブジェクトリファレンス管理方法。
【請求項３】
サーバアプリケーションを起動したプロセス制御部を識別する為のプロセス制御部識別子と当該サーバアプリケーション自身を識別する為のサーバアプリケーション識別子とを前記アプリケーション識別情報としてネームサーバに保持し、サーバアプリケーションの停止の際に当該プロセス制御部のプロセス制御部識別子及びサーバアプリケーション識別子に対応付けられたオブジェクトリファレンスを削除することを特徴とする請求項１または請求項２のいずれかに記載された分散オブジェクトリファレンス管理方法。
【請求項４】
分散オブジェクトのオブジェクトリファレンスを管理する分散オブジェクトシステムにおいて、
サーバアプリケーションを識別する為の情報であるアプリケーション識別情報を付加したオブジェクトリファレンス登録要求をネームサーバへ送信してオブジェクトリファレンスの登録要求を行う登録要求処理部と、前記送信されたオブジェクトリファレンス登録要求に付加されているアプリケーション識別情報を登録要求の行われた名前及びオブジェクトリファレンスのペアを一つ以上関連付けてネームサーバに保持する登録処理部と、
サーバアプリケーションに何らかの停止要因が発生した場合にそのアプリケーション識別情報を指定してオブジェクトリファレンスの削除要求を行う削除要求処理部と、前記削除要求で指定されたアプリケーション識別情報に関連付けられた名前及びオブジェクトリファレンスのペアを全てネームサーバから削除する削除処理部とを備えることを特徴とする分散オブジェクトシステム。
【請求項５】
分散オブジェクトのオブジェクトリファレンスを管理する分散オブジェクトシステムとしてコンピュータを機能させる為のプログラムにおいて、
サーバアプリケーションを識別する為の情報であるアプリケーション識別情報を付加したオブジェクトリファレンス登録要求をネームサーバへ送信してオブジェクトリファレンスの登録要求を行う登録要求処理部と、前記送信されたオブジェクトリファレンス登録要求に付加されているアプリケーション識別情報を登録要求の行われた名前及びオブジェクトリファレンスのペアを一つ以上関連付けてネームサーバに保持する登録処理部と、
サーバアプリケーションに何らかの停止要因が発生した場合にそのアプリケーション識別情報を指定してオブジェクトリファレンスの削除要求を行う削除要求処理部と、前記削除要求で指定されたアプリケーション識別情報に関連付けられた名前及びオブジェクトリファレンスのペアを全てネームサーバから削除する削除処理部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は分散オブジェクトのオブジェクトリファレンスを管理する分散オブジェクトシステムに関し、特にネームサーバに残留した無効オブジェクトリファレンスの削除を行う分散オブジェクトシステムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来の分散オブジェクトシステムにおける処理の流れでは、サーバアプリケーション内でオブジェクトの生成が行われ、オブジェクトリファレンスが生成されると、クライアントアプリケーション上でオブジェクトを利用することが出来る様にする為、サーバアプリケーションは、ネームサーバに対してオブジェクトリファレンスの登録要求を行う。この際、サーバアプリケーションは、オブジェクトリファレンスに一意な名前を付与し、この要求を受信したネームサーバは、オブジェクトリファレンスとその名前を関連付けて保持する。
【０００３】
オブジェクトを利用するクライアントアプリケーションは、名前を検索キーとしてネームサーバに対してオブジェクトリファレンスの取得要求を行い、ネームサーバは、検索キーの名前に対応したオブジェクトリファレンスをクライアントアプリケーションに返却する。クライアントアプリケーションは、受け取ったオブジェクトリファレンスを解析した後、目的となるオブジェクトを保持するサーバアプリケーションに対してメッセージを送信して、アプリケーション固有の処理を行う。
【０００４】
従来の分散オブジェクトシステムで用いられるインタフェース（アプリケーション間の通信プロトコルやネームサービスの仕様）として代表的なものにＣＯＲＢＡ(Common Object Request Broker Architecture)がある。
【０００５】
ＣＯＲＢＡインタフェースを適用した場合を例にとると、サーバアプリケーションとクライアントアプリケーションの間の通信、及びサーバアプリケーション、クライアントアプリケーションとネームサーバとの通信はＩＩＯＰ(Internet Inter-ORB Protocol)というプロトコルで仕様化されており、サーバアプリケーションの位置情報を示す名前とオブジェクトリファレンスのペアは、ＩＯＲ(Interoperable Object Reference)という名称で仕様化されている。ＩＩＯＰ、ＩＯＲは、ネットワーク通信プロトコルＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)の上に実装されたインタフェースであり、アプリケーションの位置を特定する手段として、ＩＰアドレス、及びＴＣＰ／ＩＰのポート番号が使用される。
【０００６】
次に従来の分散オブジェクトシステムにおいて、無効となったオブジェクトリファレンスをネームサーバから削除する処理について述べる。ネームサーバ上に保持されている名前とオブジェクトリファレンスのペアの削除は、一般的にはサーバアプリケーションの終了時、若しくは再起動時、つまり名前とオブジェクトリファレンスが無効となるタイミングで、サーバアプリケーションの要求によって行われる。
【０００７】
無効なオブジェクトリファレンスを消去する方法には２通りある。第１には名前をキーとしたオブジェクトリファレンスの削除要求を行う方法である。この場合、ネームサーバ上からは名前及びオブジェクトリファレンスのペアが完全に削除される為、サーバアプリケーションは、その後、改めてオブジェクトリファレンスの登録要求を行う必要がある。第２には、名前をキーとしてオブジェクトリファレンスの再登録要求を行う方法である。これは、既に重複する名前でオブジェクトリファレンスが登録されていた場合、オブジェクトリファレンス部分のみを新しいものに上書きする方法である。この場合、一度の要求で無効オブジェクトリファレンスの消去と、オブジェクトリファレンスの再登録を行うことが出来る。
【０００８】
なお、ネットワークを通じてネームサーバのネームデータベースに登録されているファクトリオブジェクトと被ファクトリオブジェクトの登録情報を削除する際、ネットワークトラフィックの削減ができるオブジェクト名前管理方式については特開２０００−２１５１７９号公報に記載されている。
【０００９】
その概要は、ファクトリオブジェクトと被ファクトリオブジェクトのそれぞれを識別するオブジェクトリファレンスをオブジェクトリファレンス生成装置で生成し、ファクトリオブジェクトの名前とこのファクトリオブジェクトの名前が連結された被ファクトリオブジェクトの名前を名前作成装置で作成し、これらのファクトリオブジェクトと被ファクトリオブジェクトのオブジェクトリファレンスと名前をネームデータベースに登録し、また、ネームデータベース管理装置はファクトリオブジェクトの名前に基づきファクトリオブジェクトの識別情報と名前を削除すると共に、ファクトリオブジェクトの名前が連結された被ファクトリオブジェクトの名前に基づき被ファクトリオブジェクトの識別情報と名前を削除するものである。
【００１０】
【発明が解決しようとする課題】
以上の様に、従来技術におけるネームサーバ上に存在するオブジェクトリファレンスの削除は、名前をキーとしてアプリケーションが逐一指示することによってなされるものであった。しかしこれには次の様な問題点が存在した。
【００１１】
サーバアプリケーションの不意な異常終了等により、ネームサーバ上に保持されている名前及びオブジェクトリファレンスの組が無効となった場合、再び同じ名前でオブジェクトリファレンスの削除要求、若しくは再登録要求が行われない限り、オブジェクトリファレンスが既に無効であるかどうか分からないという問題が存在した。また、ネームサーバ上に多量の無効オブジェクトリファレンスが残留した場合、サーバアプリケーションは多量の削除要求をネームサーバに対して送信しなければならず、ネットワークトラフィックの増大等システムに大きな負荷を与える要因となっていた。本問題の解決策としては、前記の特開２０００−２１５１７９号公報に記載の「オブジェクト名前管理方式」に示される様な方法が提示されているが、それでもファクトリオブジェクトの識別情報と名前を削除する際にその名前をキーとして逐一削除要求を送信する必要があった。
【００１２】
本発明の目的は上記問題を解決し、オブジェクトリファレンスの削除効率を向上させ、無効オブジェクトリファレンスの発生を防止することが可能な技術を提供することにある。
【００１３】
【課題を解決するための手段】
本発明は、分散オブジェクトのオブジェクトリファレンスを管理する分散オブジェクトシステムにおいて、サーバアプリケーションを識別する為のアプリケーション識別情報をオブジェクトリファレンスと関連付けて保持し、前記アプリケーション識別情報で指定されたオブジェクトリファレンスを削除するものである。
【００１４】
本発明の分散オブジェクトシステムでは、オブジェクトリファレンスの登録要求を行う際に、サーバアプリケーションを起動したプロセス制御部を識別する為のプロセス制御部識別子やそのサーバアプリケーション自身を識別する為のサーバアプリケーション識別子を、当該サーバアプリケーションを識別する為の情報であるアプリケーション識別情報としてオブジェクトリファレンス登録要求に付加した後、ネームサーバへ送信してオブジェクトリファレンスの登録要求を行う。ネームサーバでは、前記送信されたオブジェクトリファレンス登録要求に付加されているアプリケーション識別情報を、登録要求の行われたオブジェクトリファレンスと関連付けてネームサーバ内に保持する。
【００１５】
そして、サーバアプリケーションに何らかの停止要因が発生した場合には、そのアプリケーション識別情報のプロセス制御部識別子やサーバアプリケーション識別子を指定してオブジェクトリファレンスの削除要求を行い、前記削除要求で指定されたアプリケーション識別情報のプロセス制御部識別子やサーバアプリケーション識別子に関連付けられたオブジェクトリファレンスをネームサーバから削除する。
【００１６】
この様に、プロセス制御部識別子単位やサーバアプリケーション識別子単位、すなわちプロセス制御部単位またはサーバアプリケーション単位でオブジェクトリファレンスを削除することにより、オブジェクトリファレンスの削除を効率的に行うことが可能である。また、オブジェクトを保持するサーバアプリケーションの異常終了をプロセス制御部で検知して、プロセス制御部によりオブジェクトリファレンスの削除処理を行うことにより、無効オブジェクトリファレンスの発生を防止することができる。
【００１７】
以上の様に本発明の分散オブジェクトシステムによれば、サーバアプリケーションを識別する為のアプリケーション識別情報をオブジェクトリファレンスと関連付けて保持し、前記アプリケーション識別情報で指定されたオブジェクトリファレンスを削除するので、オブジェクトリファレンスの削除効率を向上させ、無効オブジェクトリファレンスの発生を防止することが可能である。
【００１８】
【発明の実施の形態】
以下に分散オブジェクトのオブジェクトリファレンスを管理する一実施形態の分散オブジェクトシステムについて説明する。
【００１９】
図１は本実施形態の分散オブジェクトシステムの概略構成を示す図である。図１に示す様に本実施形態のコンピュータ１１は、登録要求処理部１１１と、削除要求処理部１１２とを有している。
【００２０】
登録要求処理部１１１は、サーバアプリケーション１５を識別する為の情報であるアプリケーション識別情報２４を付加したオブジェクトリファレンス登録要求をネームサーバ１４へ送信してオブジェクトリファレンスの登録要求を行う処理部である。削除要求処理部１１２は、サーバアプリケーション１５に何らかの停止要因が発生した場合にそのアプリケーション識別情報２４を指定してオブジェクトリファレンスの削除要求を行う処理部である。
【００２１】
コンピュータ１１を登録要求処理部１１１及び削除要求処理部１１２として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２２】
コンピュータ１３は、登録処理部１３１と、削除処理部１３２とを有している。
【００２３】
登録処理部１３１は、前記送信されたオブジェクトリファレンス登録要求に付加されているアプリケーション識別情報２４を登録要求の行われたオブジェクトリファレンスと関連付けてネームサーバ１４に保持する処理部である。削除処理部１３２は、前記削除要求で指定されたアプリケーション識別情報２４に関連付けられたオブジェクトリファレンスをネームサーバ１４から削除する処理部である。
【００２４】
コンピュータ１３を登録処理部１３１及び削除処理部１３２として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２５】
図２は本実施形態のネームサーバ１４に登録されたオブジェクトリファレンスの例を示す図である。図２に示す様にネームサーバ１４には、登録要求の行われたオブジェクトリファレンスの名前とオブジェクトリファレンスのペア１９と、そのオブジェクトリファレンスに対応するアプリケーション識別情報２４が格納されており、アプリケーション識別情報２４中には、サーバアプリケーション１５自身を識別する為のサーバアプリケーション識別子であるプロセスＩＤと、サーバアプリケーション１５が起動された時刻を示す起動時刻と、サーバアプリケーション１５を起動したプロセス制御部１７を識別する為のプロセス制御部識別子とが格納されている。
【００２６】
図３は本実施形態のプロセス制御部１７のネームサーバ登録情報２１の例を示す図である。図３に示す様にプロセス制御部１７のプロセス監視情報２３には、プロセス制御部１７によって起動されたサーバアプリケーション１５の起動時刻とプロセスＩＤが格納され、ネームサーバ登録情報２１には、プロセス監視情報２３で識別されるサーバアプリケーション１５のオブジェクトリファレンスが登録されたネームサーバ１４の位置を示すＩＰアドレスとポート番号が格納されている。
【００２７】
図１の様に本実施形態の分散オブジェクトシステムは、コンピュータ１１上に存在するプロセス制御部１７と、プロセス制御部１７と同じコンピュータ１１に存在する、オブジェクト１８を保持しているサーバアプリケーション１５と、オブジェクト１８を利用するクライアントアプリケーション１６と、システムに１つ以上存在するネームサーバ１４によって構成される。
【００２８】
図１上のプロセス制御部１７は、サーバアプリケーション１５の起動、停止、及び異常停止の監視を行うサービスを提供する、１台のコンピュータにつき１つのみ存在するアプリケーションである。
【００２９】
プロセス制御部１７は、起動する前に予め次の２つの情報が与えられているものとする。１つ目は、プロセス制御部１７を一意に識別するプロセス制御部識別子２２である。プロセス制御部識別子２２とは、プロセス制御部１７を分散オブジェクトシステム上で一意に識別する為の文字列である。図１では、プロセス制御部は１つしか存在していないが、もし複数のコンピュータ上にそれぞれプロセス制御部が存在していた場合、各プロセス制御部の識別子はユニークとなる様に設定しなければならない。図１の場合、プロセス制御部１７のプロセス制御部識別子２２には‘ＳｙｓｔｅｍＩＤ１’が設定されている。
【００３０】
２つ目は、プロセス制御部１７が起動、停止、監視を行うサーバアプリケーション１５に対応する実行可能モジュール名称が格納されている、アプリケーション定義情報２０である。プロセス制御部１７は、アプリケーション定義情報２０に記述されている実行可能モジュールを使用し、サーバアプリケーション１５の起動を行う。図１では、サーバアプリケーション１５に対応する実行可能モジュール名称は、‘／ａｐｐ／ｂｉｎ／ＳｅｒｖｅｒＯｂｊｅｃｔ１’である。また、アプリケーション定義情報２０には複数の実行可能モジュール名称を記述することが可能であり、その場合、プロセス制御部１７は複数のサーバアプリケーションの起動、停止、監視を行うものとする。
【００３１】
プロセス制御部１７がサーバアプリケーションの起動、停止、及び監視を行う為の手段であるが、例えばＵＮＩＸシステムを例にあげると、アプリケーション起動にはｆｏｒｋ／ｅｘｅｃシステムコール、停止にはｋｉｌｌシステムコール、監視にはシグナルハンドラ等を使用して実現することが出来る。
【００３２】
プロセス制御部１７によって起動されたアプリケーションの生存期間についてであるが、プロセス制御部１７が稼動している間は、いつでもプロセス制御部１７からの指示で停止及び再起動を行うことが可能である。しかし、プロセス制御部１７自体が停止しようとした場合、プロセス制御部１７は自身が起動したサーバアプリケーション全てを終了させる。
【００３３】
次に、図１におけるプロセス制御部１７の処理について詳細に述べていく。オブジェクト１８を保持しているサーバアプリケーション１５がプロセス制御部１７によって起動されると、プロセス制御部１７は、サーバアプリケーション１５を一意に識別する為のプロセス監視情報２３を図３の様に保持する。
【００３４】
プロセス監視情報２３には、サーバアプリケーション１５を起動した時刻、及びコンピュータ１１内で一意にサーバアプリケーション１５を認識する為の情報が含まれている。オペレーティングシステムＵＮＩＸを例にあげると、サーバアプリケーション１５を一意に認識する為の情報として、プロセスＩＤを用いることができる。ＵＮＩＸオペレーティングシステムではプロセスＩＤを用いて、アプリケーションが存在しているか否かを判定する機構を持っており、プロセス制御部１７は、この機構を用いてサーバアプリケーション１５の認識、及び監視を行うことが可能である。逆にいえば、本システムはプロセス制御部１７がサーバアプリケーション１５を監視することが可能となる機能を持つオペレーティングシステム上で動作することが前提となる。図３の例では、プロセス制御部１７が起動したサーバアプリケーション１５の起動時刻は１３：００：００、プロセスＩＤは４３９６である。
【００３５】
次に、サーバアプリケーション１５が、プロセス制御部１７によって起動された際に行う処理について述べる。
【００３６】
図４は本実施形態のサーバアプリケーション１５の起動処理の処理手順を示すフローチャートである。サーバアプリケーション１５がプロセス制御部１７により起動されると、サーバアプリケーション１５は、まず自身がプロセス制御部１７から起動されたかどうかの判定を行う（ステップ３５）。
【００３７】
自身がプロセス制御部から起動されたかどうかを判断する方法であるが、例えばプロセス制御部１７が、特別なコマンドラインオプションを付与してサーバアプリケーション１５を起動し、サーバアプリケーション１５側でコマンドラインオプションが付与されているかどうか判定する手段等が考えられる。
【００３８】
ここで、サーバアプリケーション１５がプロセス制御部１７から起動されていると判断した場合、サーバアプリケーション１５は、プロセス制御部１７よりプロセス制御部識別子２２を入手する（ステップ３６）。
【００３９】
プロセス制御部識別子２２は、先にも述べた通りプロセス制御部１７に割り当てられた識別子であり、分散オブジェクトシステム上に複数存在しうる、各プロセス制御部毎にユニークに割り当てられた識別情報である。本情報の伝達手段には、例えばＵＮＩＸを使用する場合、共用メモリを使用したプロセス間通信や、ＵＮＩＸドメインソケットを用いたメッセージ送受信による方法が挙げられるが、特に方法は問わない。
【００４０】
次に、サーバアプリケーション１５がネームサーバ１４へオブジェクトリファレンスを登録する際の処理について述べる。図５は、この時の処理の流れを示している。なおサーバアプリケーション１５は、その処理内容に応じて複数のオブジェクトリファレンスの登録を行うものとする。
【００４１】
図５は本実施形態のオブジェクトリファレンスの登録要求処理の処理手順を示すフローチャートである。サーバアプリケーション１５は、オブジェクトリファレンス登録要求をネームサーバ１４へ送信する前に、自身がプロセス制御部１７のプロセス制御部識別子２２を入手しているかどうか（つまり、自身がプロセス制御部１７より起動されたのかどうか）を判定する（ステップ３７）。サーバアプリケーション１５がプロセス制御部識別子２２を入手していた場合、サーバアプリケーション１５は、登録要求処理部１１１により、アプリケーション識別情報２４をオブジェクトリファレンス登録要求の電文へ付加（ステップ３８）し、この情報と共にオブジェクトリファレンスの登録要求をネームサーバ１４へ送信する（ステップ３９）。
【００４２】
ここで登録要求処理部１１１が付加するアプリケーション識別情報２４とは、オブジェクトリファレンスの登録元であるサーバアプリケーション１５を、ネームサーバ１４側で特定する為の情報であり、サーバアプリケーション１５の起動時刻及びプロセスＩＤと、サーバアプリケーション１５が入手しているプロセス制御部識別子２２を示す情報である。
【００４３】
もし、サーバアプリケーション１５がプロセス制御部１７により起動されたものではなく、単独で起動していた場合、オブジェクトリファレンス登録要求へのアプリケーション識別情報２４の付加は行われない。
【００４４】
アプリケーション識別情報２４をオブジェクトリファレンス登録要求に付加する処理であるが、これはサーバアプリケーション１５からのオブジェクトリファレンス登録要求時に登録要求処理部１１１によって行われる処理である為、サーバアプリケーション１５のユーザが意図して行う必要は無い。
【００４５】
次に、サーバアプリケーション１５からオブジェクトリファレンス登録要求を受信した後のネームサーバ１４の処理について述べる。図６は、この時のネームサーバ１４の処理の流れを表している。
【００４６】
図６は本実施形態のネームサーバ１４のオブジェクトリファレンス登録処理の処理手順を示すフローチャートである。ステップ４０でネームサーバ１４の登録処理部１３１は、サーバアプリケーション１５からオブジェクトリファレンス登録要求を受け付けると、まず、オブジェクトリファレンス登録要求にアプリケーション識別情報２４が付加されているかどうかの判定を行う（ステップ４１）。
【００４７】
アプリケーション識別情報２４が付加されていた場合、ネームサーバ１４の登録処理部１３１は、オブジェクトリファレンス登録要求に付加されているアプリケーション識別情報２４を取り出し、名前とオブジェクトリファレンスのペア１９と、取り出したアプリケーション識別情報２４とを関連付けて保持する（ステップ４２）。
【００４８】
もし仮にサーバアプリケーション１５が登録要求処理部１１１へのインタフェースを備えていないか若しくはプロセス制御部１７より起動されたものではない等の要因で、ネームサーバ１４へ伝達される情報がアプリケーション識別情報２４が付与されていない従来の情報であった場合、ネームサーバ１４の登録処理部１３１は、名前とオブジェクトリファレンスのペア１９のみを管理する（ステップ４３）。つまりネームサーバ１４の登録処理部１３１は、従来のサーバアプリケーションから送信される、名前とオブジェクトリファレンスのペア１９のみで構成される登録要求も受け付けることが可能である。
【００４９】
図７は本実施形態のサーバアプリケーション１５のネームサーバ登録情報通知処理の処理手順を示すフローチャートである。ここで、再度サーバアプリケーション１５の起動処理に戻って説明する。図７は、この時のサーバアプリケーション１５の処理の流れを表している。
【００５０】
ネームサーバ１４へ名前とオブジェクトリファレンスのペア１９の登録要求を行った後、登録要求処理部１１１は、直前に行ったネームサーバ１４へのオブジェクトリファレンス登録要求が、サーバアプリケーション１５が起動されてから最初に行われた要求か否かの判定を行う（ステップ４４）。
【００５１】
ここで、最初のオブジェクトリファレンス登録要求であると判断した場合、登録要求処理部１１１は、サーバアプリケーション１５の識別情報とネームサーバ登録情報２１をプロセス制御部１７へ通知する（ステップ４５）。もしこの時点で、サーバアプリケーション１５がネームサーバ１４へのオブジェクトリファレンス登録要求を過去１度でも行っていた場合は、プロセス制御部１７へのネームサーバ登録情報２１の通知は行わない。
【００５２】
ネームサーバ登録情報２１には、オブジェクトリファレンス登録要求の行われたネームサーバ１４の位置を、ネットワーク上で特定する為の情報（例えば、ＴＣＰ／ＩＰプロトコルを使用している場合は、ＩＰアドレスとポート番号）が格納されている。ネームサーバ登録情報２１と共に通知されるサーバアプリケーション１５の識別情報は、具体的には前述のアプリケーション識別情報２４にも含まれているプロセスＩＤ及び起動時刻であり、この情報は、ネームサーバ登録情報２１を通知したサーバアプリケーション１５をプロセス制御部１７が識別する為に使用するものである。
【００５３】
プロセス制御部１７は、前記通知されたネームサーバ登録情報２１を受信すると、そのネームサーバ登録情報２１と共に通知したサーバアプリケーション１５の識別情報に一致するプロセス監視情報２３を検索し、検索されたプロセス監視情報２３と前記受信したネームサーバ登録情報２１を関連付けて保持する。
【００５４】
図３では、プロセス監視情報２３に関連付けられているネームサーバ登録情報２１内のＩＰアドレスは１７２．１６．２３．１５であり、受信ポートは１５０００である。これは、サーバアプリケーション１５が使用しているネームサーバの位置が、ＩＰアドレス：１７２．１６．２３．１５、受信ポート：１５０００であることを示している。
【００５５】
サーバアプリケーション１５は、以上の処理によりネームサーバ１４に対しオブジェクトリファレンスを登録する。
【００５６】
次に、サーバアプリケーション１５に何らかの停止要因が発生し、ネームサーバ１４上に登録されていたオブジェクトリファレンスや、異常終了により残存した無効オブジェクトリファレンスを削除するまでの流れについて述べる。
【００５７】
図８は本実施形態のオブジェクトリファレンス削除要求処理の処理手順を示すフローチャートである。図８では、サーバアプリケーション１５に停止要因発生が発生した後のプロセス制御部１７の処理の流れを示したものであるが、この処理は、次に述べる２つの条件の内、何れか１つを満たした場合に行われる。
【００５８】
１つ目は、プロセス制御部１７自体の停止に伴い、サーバアプリケーション１５に対して終了指示が行われた場合である。２つ目は、サーバアプリケーション１５が何らかの要因で自発的に停止（正常停止、異常停止含む）したことを、プロセス制御部１７が検知した場合である。
【００５９】
図８のフローに示す最初の処理でプロセス制御部１７は、削除要求処理部１１２により、前述の２条件のどちらに合致しているか（プロセス制御部１７自体が停止処理に入っているかどうか）を判定する処理を行う（ステップ４６）。
【００６０】
もし、サーバアプリケーション１５の停止要因が、プロセス制御部１７の停止によるものであった場合には、ネームサーバ１４へのオブジェクトリファレンス削除要求に付加する削除キーとしてプロセス制御部識別子２２のみを設定する（ステップ４７）。そうでない場合には、終了を検知したサーバアプリケーション１５のプロセス監視情報２３をプロセス制御部識別子２２に加えたものを削除キーに設定する（ステップ４８）。
【００６１】
削除要求処理部１１２は、この後、プロセス制御部１７の保持するプロセス監視情報２３に関連付けられた、ネームサーバ登録情報２１が存在するかどうかの検索を行う（ステップ４９）。
【００６２】
プロセス監視情報２３に対応付けされたネームサーバ登録情報２１が存在し、サーバアプリケーション１５のオブジェクトリファレンスが登録されているネームサーバ１４が特定出来たら、削除要求処理部１１２は、前記削除キーを設定したオブジェクトリファレンス削除要求を前記特定したネームサーバ１４に対して送信する（ステップ５０）。また、もしプロセス監視情報２３に対応付けされたネームサーバ登録情報２１が存在していない場合には、何のアクションも行わない。
【００６３】
次に、削除要求処理部１１２からオブジェクトリファレンス削除要求を受けた後の、ネームサーバ１４の処理の流れについて述べる。
【００６４】
図９は本実施形態の名前及びオブジェクトリファレンスの組の削除処理の処理手順を示すフローチャートである。ステップ５１でネームサーバ１４の削除処理部１３２は、削除要求処理部１１２からのオブジェクトリファレンス削除要求を受信するとステップ５２に進み、オブジェクトリファレンス削除要求に設定されている削除キーを、削除対象のオブジェクトリファレンスを検索する為の検索キーとして読み出して解析する。
【００６５】
検索キーのパターンには、前述した様に２パターン存在し、プロセス制御部識別子２２のみの情報である場合と、プロセス制御部識別子２２情報及びプロセス監視情報２３の２つを含む場合とがある。
【００６６】
検索キーがプロセス制御部識別子２２の情報のみの場合には、渡されたプロセス制御部識別子２２で識別されるプロセス制御部１７の配下で起動しているサーバアプリケーション１５が、全て停止しようとしていることを意味している。また、プロセス監視情報２３が更に検索キーに付加されている場合には、プロセス制御部１７で起動されている特定のサーバアプリケーション１５が停止したことを意味している。
【００６７】
ネームサーバ１４の削除処理部１３２は、検索キーにプロセス制御部識別子２２及びプロセス監視情報２３が含まれていると判断した場合、ネームサーバ１４内で保持しているアプリケーション識別情報２４内のプロセスＩＤに、プロセス監視情報２３に含まれるプロセスＩＤと合致するものが無いか検索し、合致するものがあった場合、アプリケーション識別情報２４に関連付けられている名前とオブジェクトリファレンスのペア１９を全て削除する（ステップ５４）。この際、プロセスＩＤ及び起動時刻の両方を用いて検索を行い、連続稼動により同じプロセスＩＤが用いられているプロセスを起動時刻の違いにより識別するものとしても良い。
【００６８】
図３の場合では、プロセス監視情報２３にはサーバアプリケーション１５のプロセスＩＤ４３９６が含まれている為、図２のアプリケーション識別情報２４の内、プロセスＩＤが４３９６のものに関連付けられている名前とオブジェクトリファレンスのペア１９が全て削除されることになる。
【００６９】
また、検索キーにプロセス制御部識別子２２の情報しか含まれていない場合は、ネームサーバ１４内で保持しているアプリケーション識別情報２４の内、検索キーで示されるプロセス制御部識別子２２が含まれている全てのアプリケーション識別情報２４に関連付けられている名前とオブジェクトリファレンスのペア１９を全て削除する（ステップ５３）。
【００７０】
図１の場合では、プロセス制御部識別子２２にはプロセス制御部１７の識別子（‘ＳｙｓｔｅｍＩＤ１’）が含まれている為、図２のアプリケーション識別情報２４の内、プロセス制御部識別子が‘ＳｙｓｔｅｍＩＤ１’のものに関連付けられている名前とオブジェクトリファレンスのペア１９が全て削除される。
【００７１】
以上の処理により、名前とオブジェクトリファレンスのペア１９に対する削除要求をサーバアプリケーション１５から逐一送信することなく、削除要求処理部１１２からの一度の削除要求で複数のオブジェクトリファレンスをネームサーバ１４上から削除することが出来る。従って、本実施形態により従来方式に比べオブジェクトリファレンス削除要求に伴うネットワークリソースの消費を削減することが可能となる。
【００７２】
以上説明した様に本実施形態の分散オブジェクトシステムによれば、サーバアプリケーションを識別する為のアプリケーション識別情報をオブジェクトリファレンスと関連付けて保持し、前記アプリケーション識別情報で指定されたオブジェクトリファレンスを削除するので、オブジェクトリファレンスの削除効率を向上させ、無効オブジェクトリファレンスの発生を防止することが可能である。
【００７３】
【発明の効果】
本発明によればサーバアプリケーションを識別する為のアプリケーション識別情報をオブジェクトリファレンスと関連付けて保持し、前記アプリケーション識別情報で指定されたオブジェクトリファレンスを削除するので、オブジェクトリファレンスの削除効率を向上させ、無効オブジェクトリファレンスの発生を防止することが可能である。
【図面の簡単な説明】
【図１】本実施形態の分散オブジェクトシステムの概略構成を示す図である。
【図２】本実施形態のネームサーバ１４に登録されたオブジェクトリファレンスの例を示す図である。
【図３】本実施形態のプロセス制御部１７のネームサーバ登録情報２１の例を示す図である。
【図４】本実施形態のサーバアプリケーション１５の起動処理の処理手順を示すフローチャートである。
【図５】本実施形態のオブジェクトリファレンスの登録要求処理の処理手順を示すフローチャートである。
【図６】本実施形態のネームサーバ１４のオブジェクトリファレンス登録処理の処理手順を示すフローチャートである。
【図７】本実施形態のサーバアプリケーション１５のネームサーバ登録情報通知処理の処理手順を示すフローチャートである。
【図８】本実施形態のオブジェクトリファレンス削除要求処理の処理手順を示すフローチャートである。
【図９】本実施形態の名前及びオブジェクトリファレンスの組の削除処理の処理手順を示すフローチャートである。
【符号の説明】
１１…コンピュータ、１２…コンピュータ、１３…コンピュータ、１４…ネームサーバ、１５…サーバアプリケーション、１６…クライアントアプリケーション、１７…プロセス制御部、１８…オブジェクト、１９…名前とオブジェクトリファレンスのペア、２０…アプリケーション定義情報、２１…ネームサーバ登録情報、２２…プロセス制御部識別子、２３…プロセス監視情報、２４…アプリケーション識別情報、１１１…登録要求処理部、１１２…削除要求処理部、１３１…登録処理部、１３２…削除処理部。
【図１】
0003689035.tif 000002
【図２】
0003689035.tif 000003
【図３】
0003689035.tif 000004
【図４】
0003689035.tif 000005
【図５】
0003689035.tif 000006
【図６】
0003689035.tif 000007
【図７】
0003689035.tif 000008
【図８】
0003689035.tif 000009
【図９】
0003689035.tif 000010