サーバ、クライアント及びクライアント・サーバ・システム

トップ :: G 物理学 :: G06 計算;計数

【発明の名称】	サーバ、クライアント及びクライアント・サーバ・システム
【発明者】	【氏名】山根慎治【氏名】佐川徹【氏名】板村典子【氏名】渡邊良子【氏名】甲田智宏
【要約】	【課題】異なるＣＯＲＢＡに準拠するサーバ（Ｓ）及びクライアント（Ｃ）の間においても、オブジェクト・リファレンス（ＯＲ）をＣに提供できるＳ、ＯＲをＳから受けられるＣ、及び、ＯＲを送受信できるＣＳシステムを提供する。【解決手段】当該Ｓが属するＣＯＲＢＡでネーミング・サービス部（ＮＳ部）が稼働している場合には、ＮＳ部からＯＲを収集し、収集した該ＯＲをインタオペラティブ・オブジェクト・リファレンス（ＩＯＲ）に変換し、変換した該ＩＯＲをＣにブロードキャスト通知し、当該Ｓが属するＣＯＲＢＡでネーミングが稼働していない場合には、アプリケーション部からＩＯＲを収集し、収集した該ＩＯＲをＣにブロードキャスト通知するゲートウェイＮＳ部を備えてサーバを構成する。

【特許請求の範囲】
【請求項１】当該サーバが属するコモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ（ＣＯＲＢＡ）でネーミング・サービス部が稼働している場合には、該ネーミング・サービス部からオブジェクト・リファレンスを収集し、収集した該オブジェクト・リファレンスをインタオペラティブ・オブジェクト・リファレンス（ＩＯＲ）に変換し、該ＩＯＲをクライアントにブロードキャスト通知し、当該サーバが属するＣＯＲＢＡでネーミングが稼働していない場合には、アプリケーション部のＩＯＲファイルからＩＯＲを収集し、収集した該ＩＯＲをクライアントにブロードキャスト通知するゲートウェイ・ネーミング・サービス部を備えることを特徴とするサーバ。
【請求項２】当該クライアントが属するＣＯＲＢＡでネーミング・サービス部が稼働している場合には、サーバから転送を受けたＩＯＲをオブジェクト・リファレンスに復元してネーミング・サービス部に登録し、当該クライアントが属するＣＯＲＢＡでネーミング・サービス部が稼働していない場合には、サーバから転送を受けたＩＯＲをリネームするゲートウェイ・ネーミング・サービス部を備えることを特徴とするクライアント。
【請求項３】請求項１記載のサーバと、請求項２記載のクライアントとを収容して構成することを特徴とするクライアント・サーバ・システム。

【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、コモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ（Common Object Request Bruker Architecture 。以降、「ＣＯＲＢＡ」と略記する。）に準拠するクライアント・サーバ・システムに係り、特に、異なるＣＯＲＢＡに準拠するサーバ及びクライアントの間においても、クライアントが、サーバに実行を要求するオブジェクトのオブジェクト名と該オブジェクトを保有している特定のサーバを結び付ける情報であるオブジェクト・リファレンスを得ることが可能なクライアント・サーバ・システムに関する。
【０００２】当初はスタンド・アロンの大型コンピュータだけで処理をするシステムが主流であったものが、パーソナル・コンピュータやワーク・ステーションの普及と高性能化に伴って、次第に大型コンピュータを核とするネットワーク化されたコンピュータ・システムが構築されるようになった。
【０００３】そして、１９９０年前後の所謂ダウン・サイジングの潮流にのって、従来の概念とは異なるコンピュータ・ネットワーク・システムが構築されるようになり、急速に普及してきた。これが、クライアント・サーバ・システムである。
【０００４】クライアント・サーバ・システムは、１つのネットワーク内に複数のサーバと呼ばれるコンピュータと多数のクライアントと呼ばれるインテリジェント・ターミナルとしてのコンピュータが共存し、クライアントの要求に従って、例えば、サーバが処理を実行したり、格納している情報を配信する。このような、処理や通信の対象をＣＯＲＢＡではオブジェクトと呼ぶ。
【０００５】上記のような通信環境下で効率がよい通信を行なうには、クライアントはどのようなオブジェクトをどのサーバが実行できるのか、どのような送受信能力をもっているのか、どのようなアドレス体系なのか等を予め知りうることが必要である。ネーミング・サービス部は、上記コンピュータ・ネットワーク内に存在して、上記目的のためにオブジェクトに関する情報即ちオブジェクト・リファレンス（以降、図においては「ＯＲ」と略記することがある。）を格納する一種のデータベースである。そして、該ネーミング・サービス部は、特定のサーバ内に存在してもよいし、独立に存在してもよい。
【０００６】図１３は、オブジェクト・リファレンスの登録と参照を示す図である。
【０００７】図１３において、１０１は、クライアント・サーバ・システム内のネットワーク、１０２は、第一のサーバ、１０３は、第二のサーバ、１０４はクライアントである。このうち、第一のサーバ１０２はオブジェクトを実行するアプリケーション部１０２－１及びオブジェクト・リファレンスを格納するネーミング・サービス部１０２－２を備えており、第二のサーバ１０３はアプリケーション部１０３－１を備えている。
【０００８】又、アプリケーション部１０２－１及びアプリケーション部１０３－１はそれぞれのオブジェクト・リファレンスを保有している。尚、それぞれのオブジェクト・リファレンスが保有するオブジェクト・リファレンスは１つには限らない。
【０００９】クライアント・サーバ・システムの立ち上げ時に、第一のサーバ１０２及び第二のサーバ１０３は、それぞれのオブジェクト・リファレンスをネーミング・サービス部に登録する。図１３の構成では、第一のサーバ１０２はサーハ内のバスを介してオブジェクト・リファレンスを登録し、第二のサーバ１０３はクライアント・サーバ・システムのネットワークを介してオブジェクト・リファレンスを登録すればよい。これによって、ネーミング・サービス部１０２－２には全てのサーバが保有する全てのオブジェクト・リファレンスが格納される。
【００１０】一方、クライアント１０４は、オブジェクトの実行に当たってネーミング・サービス部１０２－２にアクセスして、実行すべきオブジェクトのオブジェクト・リファレンスを検索する。例えば、第一のサーバ１０２のオブジェクトを実行する場合には、ネーミング・サービス部１０２－２から当該オブジェクトのオブジェクト・リファレンスを取得する。
【００１１】尚、登録と検索の矢印は論理的な経路を示すもので、実際にはバスやネットワークを介して行なわれる。このような表現をしているのは図面の輻輳を避けるためで、以降も同様な図面においては同じように表現する。
【００１２】必要なオブジェクトのオブジェクト・リファレンスを取得すると、クライアント１０４は取得したオブジェクト・リファレンスを参照して第一のサーバ１０２との間で通信して、当該オブジェクトの実行を依頼して結果を受け取る。
【００１３】しかし、サーバがネーミング・サービス部にオブジェクト・リファレンスを任意に登録したり、クライアントがネーミング・サービス部からオブジェクト・リファレンスを任意に検索することができるためには、サーバ及びクライアントが同一のＣＯＲＢＡに準拠している必要がある。これは、ＣＯＲＢＡが異なる場合にはオブジェクト・リファレンスのネーミング規則が異なるために、登録や検索ができないからである。
【００１４】図１４は、ＣＯＲＢＡの同一、異種による通信の可否を示す図である。
【００１５】図１４において、１０１は、クライアント・サーバ・システム内のネットワーク、１０５、はサーバ、１０６は、第一のクライアント、１０７は第二のクライアントである。そして、サーバ１０５にはアプリケーション部１０５－１とネーミング・サービス部１０５－２が備えられており、第一のクライアント１０６にはアプリケーション部１０６－１が備えられており、第二のクライアント１０７にはアプリケーション部１０７－１が備えられている。
【００１６】ここでは、ネーミング・サービス部１０５－２も含めてサーバ１０５と第一のクライアント１０６が同一のＣＯＲＢＡに準拠しており、クライアント１０７は異種のＣＯＲＢＡに準拠しているものとする。
【００１７】まず、第一のクライアント１０６が同一ＣＯＲＢＡ下のネーミング・サービス部１０５－２にアクセスする場合、ネーミング規則が同一であるのでオブジェクト・リファレンスを検索することができ、この場合、サーバ１０５のアプリケーション部が保有するオブジェクトのオブジェクト・リファレンスを検索することができる。従って、クライアント１０６は検索したオブジェクト・リファレンスを参照してサーバ１０５と通信することが可能で、オブジェクトの実行を依頼することができ、その結果を取得することができる。
【００１８】一方、第二のクライアント１０７が異なるＣＯＲＢＡ下のネーミング・サービス部１０５－２にアクセスしても、ネーミング規則が異なるためにネーミング・サービス部１０５－２にてオブジェクト・リファレンスを検索することが不可能である。従って、第二のクライアント１０７は実行したいオブジェクトをどのサーバが保有しているのかが判らず、図１４の構成の場合、サーバ１０５と通信が不可能なため、サーバ１０５が保有しているオブジェクトの実行を依頼することが不可能である。
【００１９】
【従来の技術】図１０は、異なるＣＯＲＢＡ下の装置間で通信を可能にする従来の構成である。
【００２０】図１０において、１は、クライアント・サーバ・システム内のネットワークである。
【００２１】２ｃは、サーバで、バス２１、バス２１に接続されているアプリケーション部２２と及びインタオペラブル・オブジェクト・リファレンス・ファイル２２－１（Interoperable Object Reference File 。以降、インタオペラブル・オブジェクト・リファレンスを「ＩＯＲ」と略記する。又、インタオペラブル・オブジェクト・リファレンス・ファイルを「ＩＯＲファイル」と略記する。但し、図においてはインタオペラブル・オブジェクト・リファレンス・ファイルを「ＩＯＲ－Ｆ」と略記する。）を備えている。
【００２２】ここで、ＩＯＲファイルとは、上記オブジェクト・リファレンスをテキスト形式で格納するファイル（記憶装置）である。
【００２３】３ｃは、クライアントで、バス３１、バス３１に接続されているアプリケーション部３２及びＩＯＲファイル３２－１を備えている。
【００２４】そして、サーバ２ｃとクライアント３ｃは異なるＣＯＲＢＡ下の装置であり、下記の手順によってネットワーク１を介する通信を可能にする。
【００２５】■ サーバ２ｃは、アプリケーション部２２のオブジェクト・リファレンスをテキスト形式のＩＯＲに変換してＩＯＲファイル２２－１に格納する。ここで、ＩＯＲファイル２２－１のファイル名は、サーバ名（ホスト名）とオブジェクト名及び識別子となり、オブジェクト・リファレンスとサーバ名及び当該オブジェクトにアクセスするためのポート番号が格納される。
【００２６】■ サーバ２ｃは、上記■のステップでＩＯＲファイル２２－１に格納した内容をファイル・トランスポート・ブロトコル（以降、「ＦＴＰ」と略記する。）によるファイル転送を使用してクライアント３ｃのＩＯＲファイル３２－１に転送する。ＦＴＰによるファイル転送には、サーバ名、クライアント名（ユーザ名）、パスワード、ディレクトリ名及びファイル名の情報が必要である。現状では、これらを指定してファイル転送する全自動化されたアプリケーションは存在しない。
【００２７】■ クライアント３ｃのアプリケーション部３２は、■のステップで取得したＩＯＲを、ファイル名をキーにオブジェクト名、サーバ名及びポート番号を獲得してオブジェクト・リファレンスに復元する。
【００２８】これにより、サーバ２ｃとクライアント３ｃは異なるＣＯＲＢＡしたの装置であるが、テキスト形式に変換したＩＯＲを介してオブジェクト・リファレンスを検索できるので、異なるＣＯＲＢＡ下の装置間でも通信が可能になる。
【００２９】
【発明が解決しようとする課題】しかし、上記従来の技術では、同一ＣＯＲＢＡ下の装置間でネーミング・サービス部を使用できる場合と、異種ＣＯＲＢＡ下の装置間でネーミング・サービス部を使用できない場合によって、サーバ及びクライアントのアプリケーション部の処理機能が異なるので、サーバ及びクライアントの処理機能を修正する必要が生じ、しかも、全てのアプリケーション部について処理機能を修正する必要がある。
【００３０】図１１は、図１０の構成におけるサーバ側の処理の変更を説明する図で、図１１（イ）は、同一ＣＯＲＢＡ下の装置であるためにネーミング・サービス部を使用できる場合の処理機能を示し、図１１（ロ）は異種ＣＯＲＢＡ下の装置であるためにネーミング・サービス部を使用できない場合の処理機能を示す。
【００３１】まず、ネーミング・サービス部を使用できる場合のサーバでの処理は、Ｓ１０１．通信オブジェクトを生成し、Ｓ１０２．オブジェクト名をキーに、オブジェクト・リファレンスをネーミング・サービス部に登録した後、スリープ状態に入り、クライアントからの起動を待つ。という処理手順である。
【００３２】これに対して、ネーミング・サービス部を使用できない場合のサーバ出の処理は、Ｓ１１１．通信オブジェクトを生成し、Ｓ１１２．オブジェクト・リファレンスをＩＯＲに変換してＩＯＲファイルに格納し、Ｓ１１３．全クライアントにＩＯＲファイルの転送処理をした後、スリープ状態に入り、クライアントからの起動を待つ。という処理手順である。
【００３３】即ち、サーバのアプリケーション部毎に、オブジェクト・リファレンスをＩＯＲに変換してＩＯＲファイルに格納する処理と、全クライアントにＩＯＲファイルの転送する処理を追加する必要がある。
【００３４】図１２は、図１０の構成におけるクライアント側の処理の変更を説明する図で、図１２（イ）は、同一ＣＯＲＢＡ下の装置であるためにネーミング・サービス部を使用できる場合の処理機能を示し、図１２（ロ）は異種ＣＯＲＢＡ下の装置であるためにネーミング・サービス部を使用できない場合の処理機能を示す。
【００３５】まず、ネーミング・サービス部を使用できる場合のクライアントでの処理は、Ｓ１２１．オブジェクト名をキーにオブジェクト・リファレンスをネーミング・サービス部から取得し、Ｓ１２２．取得したオブジェクト・リファレンスを参照して通信オブジェクトを生成し、Ｓ１２３．生成した通信オブジェクトを使用してサーバと通信してオブジェクトを実行する。という処理手順である。
【００３６】これに対して、ネーミング・サービス部を使用できない場合のクライアントでの処理は、Ｓ１３１．サーバからＩＯＲファイルの格納内容を収集し、Ｓ１３２．収集したＩＯＲファイルの格納内容をオブジェクト・リファレンスに逆変換するという形でオブジェクト・リファレンスを復元し、Ｓ１３３．復元したオブジェクト・リファレンスを参照して通信オブジェクトを生成し、Ｓ１３４．生成した通信オブジェクトを使用してサーバと通信してオブジェクトを実行する。という手順である。
【００３７】即ち、クライアントのアプリケーション部毎に、サーバからＩＯＲファイルの格納内容を収集する処理及び収集したＩＯＲファイルの格納内容からオブジェクト・リファレンスを復元する処理を追加する必要がある。
【００３８】但し、上記はサーバ側での処理追加とクライアント側での処理追加を独立に見た場合の説明であり、サーバ側の処理追加とクライアント側の処理追加を関連付けて見る場合には、一方で一部処理の追加を割愛することができる。即ち、サーバ側でＩＯＲファイルを転送する処理を追加した場合には、クライアント側ではサーバからＩＯＲファイルの格納内容を収集する処理を追加する必要はなく、クライアントにサーバからＩＯＲファイルの格納内容を収集する処理を追加した場合には、サーバ側にはクライアントに対してＩＯＲファイルを転送する処理を追加する必要はない。
【００３９】本発明は、かかる問題点に鑑み、異なるＣＯＲＢＡに準拠するサーバ及びクライアントの間においても、クライアントがオブジェクト・リファレンスを得ることが可能なクライアント・サーバ・システムを提供することを目的とする。
【００４０】
【課題を解決するための手段】第一の発明は、当該サーバが属するコモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ（ＣＯＲＢＡ）でネーミング・サービス部が稼働している場合には、該ネーミング・サービス部からオブジェクト・リファレンスを収集し、収集した該オブジェクト・リファレンスをインタオペラティブ・オブジェクト・リファレンス（ＩＯＲ）に変換し、該ＩＯＲをクライアントにブロードキャスト通知し、当該サーバが属するＣＯＲＢＡでネーミングが稼働していない場合には、アプリケーション部のＩＯＲファイルからＩＯＲを収集し、収集した該ＩＯＲをクライアントにブロードキャスト通知するゲートウェイ・ネーミング・サービス部を備えるサーバである。
【００４１】第一の発明によれば、サーバのゲートウェイ・ネーミング・サービス部が、当該サーバでネーミング・サービス部が稼働している場合にはネーミング・サービス部からオブジェクト・リファレンスを収集し、収集したオブジェクト・リファレンスをＩＯＲに変換し、変換したＩＯＲをクライアントにブロードキャスト通知し、当該サーバでネーミングが稼働していない場合にはアプリケーション部のＩＯＲファイルからＩＯＲを収集し、収集したＩＯＲをクライアントにブロードキャスト通知する。
【００４２】従って、サーバにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、サーバとクライアントの間ではテキスト形式のＩＯＲを転送すればよく、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもオブジェクト・リファレンスの転送が可能になる結果、サーバとクライアント間の間で実質的にオブジェクト・リファレンスの転送が可能になる。
【００４３】第二の発明は、当該クライアントが属するＣＯＲＢＡでネーミング・サービス部が稼働している場合には、サーバから転送を受けたＩＯＲをオブジェクト・リファレンスに復元してネーミング・サービス部に登録し、当該クライアントが属するＣＯＲＢＡでネーミング・サービス部が稼働していない場合には、サーバから転送を受けたＩＯＲをリネームするゲートウェイ・ネーミング・サービス部を備えるクライアントである。
【００４４】第二の発明によれば、クライアントのゲートウェイ・ネーミング・サービス部が、当該クライアントでネーミング・サービス部が稼働している場合にはサーバから転送を受けたＩＯＲをオブジェクト・リファレンスに復元してネーミング・サービス部に登録し、当該クライアントでネーミング・サービス部が稼働していない場合にはサーバから転送を受けたＩＯＲをリネームする。
【００４５】従って、クライアントにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、クライアントはＩＯＲの転送を受けて、該ＩＯＲからオブジェクト・リファレンスを復元するか、該ＩＯＲをリネームするかが可能になるので、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であっても実質的にオブジェクト・リファレンスの取得が可能になる。
【００４６】第三の発明は、第一の発明のサーバと、第二の発明のクライアントとを収容して構成するクライアント・サーバ・システムである。
【００４７】第三の発明によれば、サーバのゲートウェイ・ネーミング・サービス部は、当該サーバでネーミング・サービス部が稼働している場合にはネーミング・サービス部からオブジェクト・リファレンスを収集し、収集したオブジェクト・リファレンスをＩＯＲに変換し、変換したＩＯＲをクライアントにブロードキャスト通知し、当該サーバでネーミングが稼働していない場合にはアプリケーション部のＩＯＲファイルからＩＯＲを収集し、収集したＩＯＲをクライアントにブロードキャスト通知する。又、クライアントのゲートウェイ・ネーミング・サービス部は、当該クライアントでネーミング・サービス部が稼働している場合にはサーバから転送を受けたＩＯＲをオブジェクト・リファレンスに復元してネーミング・サービス部に登録し、当該クライアントでネーミング・サービス部が稼働していない場合にはサーバから転送を受けたＩＯＲをリネームする。
【００４８】従って、サーバにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、サーバとクライアントの間ではテキスト形式のＩＯＲを転送すればよく、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもオブジェクト・リファレンスの転送が可能になる結果、サーバとクライアント間の間で実質的にオブジェクト・リファレンスの転送が可能になり、クライアントにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、クライアントはＩＯＲの転送を受けて、該ＩＯＲからオブジェクト・リファレンスを復元するか、該ＩＯＲをリネームするので、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもクライアントは実質的にオブジェクト・リファレンスの取得が可能になる。この結果、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもサーバとクライアントの間で通信が可能になる。
【００４９】
【発明の実施の形態】図１は、本発明の第一の実施の形態で、サーバとクライアントの双方でネーミング・サービス部が稼働している場合の、サーバの構成とクライアントの構成及びクライアント・サーバ・システムの構成を示すものである。尚、図１では、サーバとクライアントは互いに異なるＣＯＲＢＡ下の装置であることを想定している。
【００５０】図１において、１はクライアント・サーバ・システム内のネットワークである。
【００５１】２は、第一のＣＯＲＢＡ下のサーバで、サーバ内のバス２１、オブジェクトを実行するアプリケーション部２２、ネーミング・サービス部２３、ゲートウェイ・ネーミング・サービス部２４、ローカル・ディレクトリのＩＯＲファイル２５（図では、「ローカルＩＯＲ－Ｆ」と略記している。以降も、図では同様に略記する。）及びリモート・ディレクトリのＩＯＲファイル２６（図では、「リモートＩＯＲ－Ｆ」と略記している。以降も、図では同様に略記する。）を備えている。尚、ゲートウェイ・ネーミング・サービス部２４のＩＯＲファイル２４－１は、変換が行なわれる度に生成される。
【００５２】図１の構成のサーバ２の動作概要は下記の通りである。
【００５３】即ち、アプリケーション部２２は、当該アプリケーション部が実行するオブジェクトに関する第一のＣＯＲＢＡ下で有効なオブジェクト・リファレンスを保有しており、該オブジェクト・リファレンスをネーミング・サービス部２３に登録している。
【００５４】ゲートウェイ・ネーミング・サービス部２４は、ネーミング・サービス部２３に登録されている該オブジェクト・リファレンスを収集してＩＯＲに変換し、一旦ＩＯＲファイル２４－１に格納し、ＩＯＲファイル２４－１の格納内容をネーミング規則に則ってリネームしてローカル・ディレクトリのＩＯＲファイルに格納し、クライアントに対してネットワーク１を介してブロードキャストする。
【００５５】ここで、図１には１つのクライアントしか示されていないのにブロードキャストするというのは一見適切ではないようであるが、これは、図の煩雑化を防ぐために１つのサーバと１つのクライアントによって構成されるクライアント・サーバ・システムを示しているだけであって、実際には複数のサーバと複数のクライアントによってクライアント・サーバ・システムが構成されている。従って、そういう実際のクライアント・サーバ・システムを考慮してブロードキャストすると記載したものである。このことは、以降に説明する全ての発明の実施の形態に共通することである。
【００５６】３は、第二のＣＯＲＢＡ下のクライアントで、クライアント内のバス３１、オブジェクトを実行するアプリケーション部３２、ネーミング・サービス部３３、ゲートウェイ・ネーミング・サービス部３４、ローカル・ディレクトリのＩＯＲファイル３５及びリモート・ディレクトリのＩＯＲファイル３６を備えている。尚、ゲートウェイ・ネーミング・サービス部３４にはＩＯＲファイル３４－１が備えられている。
【００５７】図１の構成のクライアントの動作概要は下記の通りである。
【００５８】ゲートウェイ・ネーミング・サービス部３４はサーバからＩＯＲのブロードキャストを受け、受けたＩＯＲをリモート・ディレクトリのＩＯＲファイルに格納し、該ＩＯＲからサーバ２のアプリケーション部２２のオブジェクト・リファレンスを復元し、ネーミング・サービス部３３に登録する。
【００５９】このようにして、第二のＣＯＲＢＡ下のクライアント３のネーミング・サービス部３３に、第一のＣＯＲＢＡ下のサーバ２のアプリケーション部２２のオブジェクト・リファレンスが登録されるので、第二のＣＯＲＢＡ下のクライアント３のアプリケーション部３２は、ネーミング・サービス部３３に登録された第一のＣＯＲＢＡ下のサーバ２のアプリケーション部２２のオブジェクト・リファレンスを取得することができる。
【００６０】従って、第二のＣＯＲＢＡ下のクライアント３のアプリケーション部３２は取得したオブジェクト・リファレンスを参照して第一のＣＯＲＢＡ下のサーバ２のアプリケーション部２２にアクセスすることが可能になるので、異なるＣＯＲＢＡ下の装置であるサーバ２とクライアント３の間で通信することによってオブジェクトの実行が可能になる。
【００６１】そして、サーバ２とクライアント３が同一ＣＯＲＢＡ下の装置である場合にも、サーバ２が変換して格納したＩＯＲをクライアント３に転送し、転送されたＩＯＲをクライアント３がリネームしてサーバ２のオブジェクト・リファレンスを復元するので、当然、クライアント３はサーバ２のオブジェクト・リファレンスを取得可能で、サーバ２とクライアント３の間で通信が可能である。
【００６２】尚、ローカル・ディレクトリのＩＯＲファイルとは、当該装置のオブジェクト・リファレンスを変換したＩＯＲを格納するファイルであることを意味し、リモート・ディレクトリのＩＯＲファイルとは、外部装置のオブジェクト・リファレンスを変換したＩＯＲを格納するファイルであることを意味する。
【００６３】又、上ではサーバ２のローカル・ディレクトリのＩＯＲファイル２５と、クライアント３のリモート・ディレクトリのＩＯＲファイル３６のみが使用されるように記載しているが、これは、一方の装置をサーバであると定義し、もう一方の装置をクライアントであると定義しているためである。
【００６４】即ち、クライアント・サーバ・システムでは各々の装置自体の構成は同じで、機能的にサーバとなったりクライアントになるということがある。従って、図１においてサーバとして定義した装置がクライアントになり、クライアントとして定義した装置がサーバになることがあることを考慮すると、サーバとして定義した装置にもリモート・ディレクトリのＩＯＲファイルを備え、クライアントとして定義した装置にもローカル・ディレクトリのＩＯＲファイルを備えておくことが好ましい。この意味で、図１においては、ローカル・ディレクトリとリモート・ディレクトリの双方のＩＯＲファイルを備えるサーバ２とクライアント３を示している。このことは、以降に説明する全ての実施の形態について共通である。
【００６５】更に、上記説明では、ネーミング・サービス部がサーバやクライアントの中に存在するように記載しているが、先にも説明した如く、ネーミング・サービス部はクライアント・サーバ・システムの中の任意の場所に存在することができるので、例えば、サーバ２の中にネーミング・サービス部２３が存在するということは、サーバ２と同一ＣＯＲＢＡ下の複数の装置で構成されるサブ・システムの中にネーミング・サービス部が存在するという意味である。
【００６６】従って、図１に示したクライアント・サーバ・システムは、異なるＣＯＲＢＡ下の複数の装置からなるサブ・システムの各々の中にネーミング・サービス部が存在するクライアント・サーバ・システムであり、上記は、異なるＣＯＲＢＡ下のサブ・システム間でＩＯＲを交換することができることを示している。
【００６７】図２は、本発明の第二の実施の形態で、サーバではネーミング・サービス部が稼働しておらずクライアントではネーミング・サービス部が稼働している場合の、サーバの構成とクライアントの構成及びクライアント・サーバ・システムの構成を示すものである。尚、図２では、一応サーバとクライアントが互いに異なるＣＯＲＢＡ下の装置であることを想定している。
【００６８】図２において、１はクライアント・サーバ・システム内のネットワークである。
【００６９】２ａは、第一のＣＯＲＢＡ下のサーバで、サーバ内のバス２１、オブジェクトを実行するアプリケーション部２２ａ、ゲートウェイ・ネーミング・サービス部２４、ローカル・ディレクトリのＩＯＲファイル２５及びリモート・ディレクトリのＩＯＲファイル２６を備えている。尚、アプリケーション部２２ａにはＩＯＲファイル２２－１が、ゲートウェイ・ネーミング・サービス部２４にはＩＯＲファイル２４－１が備えられている。
【００７０】図２の構成のサーバの動作概要は下記の通りである。
【００７１】即ち、アプリケーション部２２ａは、当該アプリケーション部が実行するオブジェクトに関するオブジェクト・リファレンスを保有しており、該オブジェクト・リファレンスをＩＯＲに変換し、ＩＯＲファイル２２－１に格納している。
【００７２】ゲートウェイ・ネーミング・サービス部２４は、アプリケーション部２２ａのＩＯＲファイルに格納されているＩＯＲを収集して一旦ＩＯＲファイル２４－１に格納し、ＩＯＲファイル２４－１の格納内容をネーミング規則に則ってリネームしてローカル・ディレクトリのＩＯＲファイルに格納して、クライアントに対してネットワーク１を介してブロードキャストする。
【００７３】３は、第二のＣＯＲＢＡ下のクライアントで、クライアント内のバス３１、オブジェクトを実行するアプリケーション部３２、ネーミング・サービス部３３、ゲートウェイ・ネーミング・サービス部３４、ローカル・ディレクトリのＩＯＲファイル３５及びリモート・ディレクトリのＩＯＲファイル３６を備えている。尚、ゲートウェイ・ネーミング・サービス部３４にはＩＯＲファイル３４－１が備えられている。
【００７４】図２の構成のクライアント３は図１の構成のクライアント３と同じ構成であるので、動作概要は図１の説明において記載したものと同じである。
【００７５】即ち、ゲートウェイ・ネーミング・サービス部３４はサーバからＩＯＲのブロードキャストを受け、受けたＩＯＲをリモート・ディレクトリのＩＯＲファイルに格納し、該ＩＯＲから第一のＣＯＲＢＡ下のサーバ２ａのアプリケーション部２２ａのオブジェクト・リファレンスを復元し、ネーミング・サービス部３３に登録する。
【００７６】このようにして、第二のＣＯＲＢＡ下のクライアント３のネーミング・サービス部に、第一のＣＯＲＢＡ下のサーバ２ａのアプリケーション部２２ａのオブジェクト・リファレンスが登録されるので、第二のＣＯＲＢＡ下のクライアント３のアプリケーション部３２はネーミング・サービス部３３に登録された、第一のＣＯＲＢＡ下のサーバ２ａのアプリケーション部２２ａのオブジェクト・リファレンスを取得することができる。
【００７７】従って、第二のＣＯＲＢＡ下のクライアント３のアプリケーション部３２は取得したオブジェクト・リファレンスを参照して第一のＣＯＲＢＡ下のサーバ２ａのアプリケーション部２２ａにアクセスすることが可能になるので、異なるＣＯＲＢＡ下の装置であるサーバ２ａとクライアント３の間で通信することによってオブジェクトの実行が可能になる。
【００７８】そして、サーバ２ａとクライアント３が同一ＣＯＲＢＡ下の装置である場合にも、サーバ２ａが変換して格納したＩＯＲをクライアント３に転送し、転送されたＩＯＲをクライアント３がリネームしてサーバ２ａのオブジェクト・リファレンスを復元するので、当然、クライアント３はサーバ２ａのオブジェクト・リファレンスを取得可能で、サーバ２ａとクライアント３の間で通信が可能である。
【００７９】更に、上記説明では、第一のＣＯＲＢＡ下のサーバ２ａ内にネーミング・サービス部が存在せず、第二のＣＯＲＢＡ下のクライアント３の中にネーミング・サービス部が存在するように記載しているが、これの真の意味は、第一のＣＯＲＢＡ下のサブ・システム中にはネーミング・サービス部が存在せず、第二のＣＯＲＢＡ下のサブ・システム中にはネーミング・サービス部２３が存在するということである。
【００８０】従って、上記は、異なるＣＯＲＢＡ下の複数の装置からなるサブ・システムの中にネーミング・サービス部が存在するサブ・システムとネーミング・サービス部が存在しないサブ・システムが混在するクライアント・サーバ・システムであり、このような場合にも異なるＣＯＲＢＡ下のサブ・システム間でＩＯＲを交換することができることを示している。
【００８１】図３は、本発明の第三の実施の形態で、サーバではネーミング・サービス部が稼働しており、クライアントではネーミング・サービス部が稼働していない場合の、サーバの構成とクライアントの構成及びクライアント・サーバ・システムの構成を示すものである。尚、図３では、一応サーバとクライアントが異なるＣＯＲＢＡしたの装置であることを想定している。
【００８２】図３において、１はクライアント・サーバ・システム内のネットワークである。
【００８３】２は、第一のＣＯＲＢＡ下の装置であるサーバで、サーバ内のバス２１、オブジェクトを実行するアプリケーション部２２、ネーミング・サービス部２３、ゲートウェイ・ネーミング・サービス部２４、ローカル・ディレクトリのＩＯＲファイル２５及びリモート・ディレクトリのＩＯＲファイル２６を備えている。尚、ゲートウェイ・ネーミング・サービス部２４にはＩＯＲファイル２４－１が備えられている。
【００８４】図３の構成のサーバ２の動作概要は図１の構成のサーバ２の動作概要と同じである。
【００８５】即ち、アプリケーション部２２は、当該アプリケーション部が実行するオブジェクトに関する第一のＣＯＲＢＡ下で有効なオブジェクト・リファレンスを保有しており、該オブジェクト・リファレンスをネーミング・サービス部２３に登録している。
【００８６】ゲートウェイ・ネーミング・サービス部２４は、ネーミング・サービス部２３に登録されているオブジェクト・リファレンスを収集してＩＯＲに変換し、一旦ＩＯＲファイル２４－１に格納し、ＩＯＲファイル２４－１の格納内容をネーミング規則に則ってリネームしてローカル・ディレクトリのＩＯＲファイルに格納して、クライアントに対してネットワーク一を介してブロードキャストする。
【００８７】３ａは、第二のＣＯＲＢＡ下の装置であるクライアントで、クライアント内のバス３１、オブジェクトを実行するアプリケーション部３２、ゲートウェイ・ネーミング・サービス部３４ａ、ローカル・ディレクトリのＩＯＲファイル３５及びリモート・ディレクトリのＩＯＲファイル３６を備えている。尚、ゲートウェイ・ネーミング・サービス部３４ａにはＩＯＲファイル３４－１及びＩＯＲファイル３４－２が備えられている。
【００８８】図３の構成のクライアントの動作概要は下記の通りである。
【００８９】即ち、ゲートウェイ・ネーミング・サービス部３４ａはサーバ２からＩＯＲのブロードキャストを受け、受けたＩＯＲをリモート・ディレクトリのＩＯＲファイル３６に格納し、ＩＯＲファイル３６に格納したＩＯＲをネーミング規則に則ってリネームしてＩＯＲファイル３４－２に格納する。
【００９０】クライアント３ａのアプリケーション部３２は、ゲートウェイ・ネーミング・サービス部３４ａのＩＯＲファイル３４－２に格納されているＩＯＲから第一のＣＯＲＢＡ下のサーバ２のアプリケーション部２２のオブジェクト・リファレンスを復元する。
【００９１】このようにして、第二のＣＯＲＢＡ下のクライアント３ａのアプリケーション部３２は、第一のＣＯＲＢＡ下のサーバ２のアプリケーション部２２のオブジェクト・リファレンスを取得することができる。
【００９２】従って、クライアント３ａのアプリケーション部３２は取得したオブジェクト・リファレンスを参照してサーバ２のアプリケーション部２２にアクセスすることが可能になるので、異なるＣＯＲＢＡ下のサーバ２とクライアント３ａの間で通信することによってオブジェクトの実行が可能になる。
【００９３】そして、サーバ２とクライアント３ａが同一ＣＯＲＢＡ下の装置である場合にも、サーバ２が変換して格納したＩＯＲをクライアント３ａに転送し、転送されたＩＯＲをクライアント３ａがリネームしてサーバ２のオブジェクト・リファレンスを復元するので、当然、クライアント３ａはサーバ２のオブジェクト・リファレンスを取得可能で、サーバ２とクライアント３ａの間で通信が可能である。
【００９４】更に、上記説明では、第一のＣＯＲＢＡ下のサーバ２内にネーミング・サービス部が存在し、第二のＣＯＲＢＡ下のクライアント３ａの中にネーミング・サービス部が存在しないように記載しているが、これの真の意味は、第一のＣＯＲＢＡ下のサブ・システム中にはネーミング・サービス部が存在し、第二のＣＯＲＢＡ下のサブ・システム中にはネーミング・サービス部２３が存在しないということである。
【００９５】従って、上記は、異なるＣＯＲＢＡ下の複数の装置からなるサブ・システムの中にネーミング・サービス部が存在するサブ・システムとネーミング・サービス部が存在しないサブ・システムが混在するクライアント・サーバ・システムであり、このような場合にも異なるＣＯＲＢＡ下のサブ・システム間でＩＯＲを交換することができることを示している。
【００９６】図４は、本発明の第四の実施の形態で、サーバ及びクライアント共ネーミング・サービス部が稼働していない場合の、サーバの構成、クライアントの構成及びクライアント・サーバ・システムの構成を示すものである。尚、図４では一応サーバとクライアントが異なるＣＯＲＢＡ下の装置であることを想定している。
【００９７】図４において、１はクライアント・サーバ・システム内のネットワークである。
【００９８】２ａは、第一のＣＯＲＢＡ下のサーバで、サーバ内のバス２１、オブジェクトを実行するアプリケーション部２２ａ、ゲートウェイ・ネーミング・サービス部２４、ローカル・ディレクトリのＩＯＲファイル２５及びリモート・ディレクトリのＩＯＲファイル２６を備えている。尚、アプリケーション部２２ａにはＩＯＲファイル２２－１が、ゲートウェイ・ネーミング・サービス部２４にはＩＯＲファイル２４－１が備えられている。
【００９９】図４の構成のサーバ２ａの動作概要は図２の構成のサーバ２ａの動作概要と同じである。
【０１００】即ち、アプリケーション部２２ａは、当該アプリケーション部が実行するオブジェクトに関する第一のＣＯＲＢＡ下で有効なオブジェクト・リファレンスを保有しており、該オブジェクト・リファレンスをＩＯＲに変換し、ＩＯＲファイル２２－１に格納している。
【０１０１】ゲートウェイ・ネーミング・サービス部２４は、アプリケーション部２２ａのＩＯＲファイルに格納されているＩＯＲを収集して一旦ＩＯＲファイル２４－１に格納し、ＩＯＲファイル２４－１の格納内容をネーミング規則に則ってリネームしてローカル・ディレクトリのＩＯＲファイルに格納して、クライアントに対してネットワーク１を介してブロードキャストする。
【０１０２】３ａは、第二のＣＯＲＢＡ下の装置であるクライアントで、クライアント内のバス３１、オブジェクトを実行するアプリケーション部３２、ゲートウェイ・ネーミング・サービス部３４ａ、ローカル・ディレクトリのＩＯＲファイル３５及びリモート・ディレクトリのＩＯＲファイル３６を備えている。尚、ゲートウェイ・ネーミング・サービス部３４ａにはＩＯＲファイル３４－１及びＩＯＲファイル３４－２が備えられている。
【０１０３】図４の構成のクライアント３ａの動作概要は図３の構成のクライアント３ａの動作概要と同じである。
【０１０４】即ち、ゲートウェイ・ネーミング・サービス部３４ａはサーバ２ａからＩＯＲのブロードキャストを受け、受けたＩＯＲをリモート・ディレクトリのＩＯＲファイル３６に格納し、ＩＯＲファイル３６に格納したＩＯＲをネーミング規則に則ってリネームしてＩＯＲファイル３４－２に格納する。
【０１０５】クライアント３ａのアプリケーション部３２は、ゲートウェイ・ネーミング・サービス部３４ａのＩＯＲファイル３４－２に格納されているＩＯＲから第一のＣＯＲＢＡ下のサーバ２ａのオブジェクト・リファレンスを復元する。
【０１０６】このようにして、第二のＣＯＲＢＡ下のクライアント３ａのアプリケーション部３２は、第一のＣＯＲＢＡ下のサーバ２ａのアプリケーション部２２ａのオブジェクト・リファレンスを取得することができる。
【０１０７】従って、クライアント３ａのアプリケーション部３２は取得したオブジェクト・リファレンスを参照してサーバ２ａのアプリケーション部２２ａにアクセスすることが可能になるので、異なるＣＯＲＢＡ下の装置であるサーバ２ａとクライアント３ａの間で通信することによってオブジェクトの実行が可能になる。
【０１０８】そして、サーバ２ａとクライアント３ａが同一ＣＯＲＢＡ下の装置である場合にも、サーバ２ａが変換して格納したＩＯＲをクライアント３ａに転送し、転送されたＩＯＲをクライアント３ａがリネームしてサーバ２ａのオブジェクト・リファレンスを復元するので、当然、クライアント３ａはサーバ２のオブジェクト・リファレンスを取得可能で、サーバ２ａとクライアント３ａの間で通信が可能である。
【０１０９】更に、上記説明では、第一のＣＯＲＢＡ下のサーバ２ａと第二のＣＯＲＢＡ下のクライアント３ａの中にネーミング・サービス部が存在しないように記載しているが、これの真の意味は、第一のＣＯＲＢＡ下のサブ・システム中と第二のＣＯＲＢＡ下のサブ・システム中にネーミング・サービス部が存在しないということである。
【０１１０】従って、上記は、異なるＣＯＲＢＡ下の複数の装置からなるサブ・システムの中にネーミング・サービス部が存在しないクライアント・サーバ・システムであり、このような場合にも異なるＣＯＲＢＡ下のサブ・システム間でＩＯＲを交換することができることを示している。
【０１１１】以上で、本発明の４つの実施の形態について、サーバの構成、クライアントの構成及びクライアント・サーバ・システムの構成と機能について説明した。各々の説明を総合的に解釈すると、サーバに備えられるゲートウェイ・ネーミング・サービス部の動作とクライアントに備えられるゲートウェイ・ネーミング・サービス部の動作も、ネーミング・サービス部が備えられているか否かで異なるだけであるから、サーバに備えられるゲートウェイ・ネーミング・サービス部の動作は１つのフローチャートに統合でき、クライアントに備えられるゲートウェイ・ネーミング・サービス部の動作も１つのフローチャートに統合できる。以降、統合されたフローチャートによってサーバに備えられるゲートウェイ・ネーミング・サービス部の動作とクライアントに備えられるゲートウェイ・ネーミング・サービス部の動作を説明する。
【０１１２】図６は、サーバ側ゲートウェイ・ネーミング・サービス部の動作である。以降、図６の符号にそって説明する。
【０１１３】Ｓ１．当該サーバ内でネーミング・サービス部が稼働しているか否かを判定する。
【０１１４】ここで、「当該サーバ内でネーミング・サービス部が稼働しているか否か」は若干正確さを欠く表現で、「当該サーバが属するＣＯＲＢＡしたでネーミング・サービス部が稼働しているか否か」とする方が正確であるが、図１乃至図５の表現に合わせているために、「当該サーバ内でネーミング・サービス部が稼働しているか否か」と記載している。以降も、同様な表現を繰り返し使用するが、上記意味を汲み取って戴きたい。
【０１１５】Ｓ２．ステップＳ１で、ネーミング・サービス部が稼働していると判定した場合（Ｙｅｓ）には、ネーミング・サービス部に登録されているオブジェクト・リファレンスを収集する。
【０１１６】Ｓ３．収集したオブジェクト・リファレンスをＩＯＲに変換して、ゲートウェイ・ネーミング・サービス部内のＩＯＲファイルに格納する。
【０１１７】Ｓ４．ステップＳ３で格納したＩＯＲを、リネームしてサーバのローカル・ディレクトリのＩＯＲファイルに格納する。
【０１１８】尚、図５の構成の場合には、上記「サーバの」を「サーバと同じＣＯＲＢＡ下の」と読み替えれば正確になる。以降も、同様な表現をするが、上記意味を汲み取って戴きたい。
【０１１９】Ｓ５．ステップＳ１で、当該サーバ内でネーミング・サービス部が稼働していないと判定した場合（Ｎｏ）には、当該サーバ内のアプリケーション部のＩＯＲファイルからＩＯＲを収集する。
【０１２０】Ｓ６．収集したＩＯＲをリネームしてサーバのローカル・ディレクトリのＩＯＲファイルに格納する。
【０１２１】Ｓ７．ステップＳ４又はステップＳ６の処理を終了した後、クライアントに対してＩＯＲをブロードキャストする。
【０１２２】以上が、サーバの立ち上げ時のゲートウェイ・ネーミング・サービス部の処理である。
【０１２３】Ｓ８．所定時間のスリープ状態を経過した後、当該サーバ内でネーミング・サービス部が稼働しているか否かを判定する。
【０１２４】Ｓ９．ステップＳ８で、当該サーバ内でネーミング・サービス部が稼働していると判定した場合（Ｙｅｓ）には、当該サーバのネーミング・サービス部のオブジェクト・リファレンスを収集する。
【０１２５】Ｓ１０．収集したオブジェクト・リファレンスをＩＯＲに変換して、ゲートウェイ・ネーミング・サービス部内のＩＯＲファイルに格納する。
【０１２６】Ｓ１１．ゲートウェイ・ネーミング・サービス部内のＩＯＲファイルの格納内容と、サーバのローカル・ディレクトリのＩＯＲファイルの格納内容を比較する。
【０１２７】これは、オブジェクト自体を保有するサーバが絶対不変ではなく、何らかの理由で当初とは異なるサーバに移管されることがありうるため、オブジェクト・リファレンスが変化する可能性を考慮して、ローカル・ディレクトリのＩＯＲファイルに先に格納されたＩＯＲと現在のオブジェクト・リファレンスから変換したＩＯＲを比較するものである。
【０１２８】Ｓ１２．ステップＳ１１での比較の結果、ＩＯＲが変わったか否か判定する。
【０１２９】ＩＯＲが変わらなかったと判定した場合（Ｙｅｓ）には、スリープ状態に移行する。
【０１３０】Ｓ１３．ステップＳ１２で、ＩＯＲが変わったと判定した場合（Ｙｅｓ）には、ゲートウェイ・ネーミング・サービス部内のＩＯＲファイルの格納内容をサーバのローカル・ディレクトリのＩＯＲファイルに上書きする。
【０１３１】Ｓ１４．ステップＳ８で、当該サーバでネーミング・サービス部が稼働していないと判定した場合（Ｎｏ）には、アプリケーション部のＩＯＲファイルに格納されているＩＯＲを収集してゲートウェイ・ネーミング・サービス部内のＩＯＲファイルに格納する。
【０１３２】Ｓ１５．ゲートウェイ・ネーミング・サービス部内のＩＯＲファイルの格納内容と、サーバのローカル・ディレクトリのＩＯＲファイルの格納内容を比較する。
【０１３３】比較を行なう理由は、既に説明した通りである。
【０１３４】Ｓ１６．ステップＳ１５での比較の結果、ＩＯＲが変わったか否か判定する。
【０１３５】Ｓ１７．ステップＳ１６で、ＩＯＲに変化があったと判定した場合（Ｔｅｓ）には、ゲートウェイ・ネーミング・サービス部内のＩＯＲファイルの格納内容をサーバのローカル・ディレクトリのＩＯＲファイルに上書きする。
【０１３６】Ｓ１８．ステップＳ１３又はステップＳ１７で上書きした後、クライアントに対してブロードキャストを行なう。
【０１３７】その後は、再びスリープ状態に入り、以降は、ステップＳ８乃至ステップＳ１８の処理を繰り返し行なう。即ち、ステップＳ８以降ステップＳ１８の処理はサーバ側のゲートウェイ・ネーミング・サービス部の定周期の動作で、これによって、クライアント側は常に新しいオブジェクト・リファレンスの情報を得ることができる。
【０１３８】図７は、クライアント側ゲートウェイ・ネーミング・サービス部の動作である。以降、図７の符号に沿って説明する。
【０１３９】Ｓ３１．動作開始時にタイマーを起動する。
【０１４０】そして、サーバからのブロードキャスト又はタイマーがタイムアウトとなるのを待つ。
【０１４１】Ｓ３２．サーバからブロードキャストがあったか否かを判定する。上記の如く、ブロードキャスト又はタイムアウトを待っているので、割込みがあって且つブロードキャストによる割込みではない場合にはタイムアウトによる割込みがあったことになる。
【０１４２】Ｓ３３．ステップＳ３２で、ブロードキャストがあったと判定した場合（Ｙｅｓ）には、当該クライアントでネーミング・サービス部が稼働しているか否かを判定する。
【０１４３】Ｓ３４．ステップＳ３３で、ネーミング・サービス部が稼働していると判定した場合（Ｙｅｓ）には、ブロードキャスト通知してきた装置のローカル・ディレクトリのＩＯＲファイルに格納されているＩＯＲをＦＴＰにて取得する。
【０１４４】Ｓ３５．獲得したＩＯＲをリネームしてクライアントのリモート・ディレクトリのＩＯＲファイルに格納する。
【０１４５】Ｓ３６．獲得したＩＯＲをオブジェクト・リファレンスに変換する。
【０１４６】Ｓ３７．変換したオブジェクト・リファレンスをクライアント側のネーミング・サービス部に登録して、ブロードキャスト待ち又はタイムアウト待ちの状態に移行する。
【０１４７】Ｓ３８．ステップＳ３３で、ネーミング・サービス部が稼働していないと判定した場合（Ｎｏ）には、通知してきた装置のローカル・ディレクトリのＩＯＲファイルに格納されているＩＯＲをＦＴＰにて取得する。
【０１４８】Ｓ３９．取得したＩＯＲをリネームして格納する。
【０１４９】Ｓ４０．ステップＳ３９でリネームしたＩＯＲをクライアント側のリモート・ディレクトリのＩＯＲファイルに格納して、ブロードキャスト待ち又はタイムアウト待ちの状態に移行する。
【０１５０】上記ステップＳ３３乃至Ｓ４０がクライアントの定周期動作である。
【０１５１】Ｓ４１．一方、ステップＳ３２で、ブロードキャスト通知でなく、タイムアウトであると判定した場合（Ｎｏ）には、当該クライアントでネーミング・サービス部が稼働しているか否かを判定する。
【０１５２】Ｓ４２．ステップＳ４１で、ネーミング・サービス部が稼働していると判定した場合（Ｙｅｓ）には、クライアント側のリモート・ディレクトリのＩＯＲファイルに格納されているＩＯＲからオブジェクト・リファレンスを復元する。
【０１５３】Ｓ４３．復元したオブジェクト・リファレンスをネーミング・サービス部に登録する。
【０１５４】Ｓ４４．ステップＳ４１で、ネーミング・サービス部が稼働していないと判定した場合（Ｎｏ）には、クライアントのリモート・ディレクトリのＩＯＲファイルに格納されているＩＯＲをリネームする。
【０１５５】そして．ステップＳ４３又はステップＳ４４を終了した後、ステップＳ３１に戻る。
【０１５６】上記ステップＳ４１乃至ステップＳ４４の処理がタイムアウト後の処理である。
【０１５７】図５は、本発明の第五の実施の形態で、サーバとクライアントの双方でネーミング・サービス部が稼働している場合で、サーバ及びクライアントと独立にゲートウェイ・ネーミング・サービス機能が存在する場合の、サーバの構成とクライアントの構成、ゲートウェイ・ネーミング・サービス装置の構成及びクライアント・サーバ・システムの構成を示すものである。尚、図１では、サーバとクライアントは互いに異なるＣＯＲＢＡ下の装置であることを想定している。
【０１５８】図５において、１はクライアント・サーバ・システム内のネットワークである。
【０１５９】２ｂは、第一のＣＯＲＢＡ下のサーバで、サーバ２ｂ内のバス２１、オブジェクトを実行するアプリケーション部２２及びネーミング・サービス部２３を備えている。
【０１６０】３ｂは、第二のＣＯＲＢＡ下のクライアントで、クライアント３ｂ内のバス３１、オブジェクトを実行するアプリケーション部３２及びネーミング・サービス部３３を備えている。
【０１６１】４は、ゲートウェイ・ネーミング・サービス装置で、ゲートウェイ・ネーミング・サービス装置内のバス４１、第一のＣＯＲＢＡに対応するゲートウェイ・ネーミング・サービス部４２、ローカル・ディレクトリのＩＯＲファイル４３、リモート・ディレクトリのＩＯＲファイル４４、第二のＣＯＲＢＡに対応するゲートウェイ・ネーミング・サービス部４２ａ、ローカル・ディレクトリのＩＯＲファイル４３ａ及びリモート・ディレクトリのＩＯＲファイル４４ａを備えている。
【０１６２】尚、ゲートウェイ・ネーミング・サービス部４２はＩＯＲファイル４２－１を備え、ゲートウェイ・ネーミング・サービス部４２ａはＩＯＲファイル４２－１ａを備えている。
【０１６３】図５の構成の動作概要は下記の通りである。
【０１６４】第一のＣＯＲＢＡ下のサーバ２ｂにおいて、アプリケーション部２２はオブジェクト・リファレンスをネーミング・サービス部２３に登録している。
【０１６５】ゲートウェイ・ネーミング・サービス装置４において、ゲートウェイ・ネーミング・サービス部４２は、サーバ２ｂのネーミング・サービス部２３に登録されている第一のＣＯＲＢＡで有効なオブジェクト・リファレンスを収集し、ＩＯＲに変換し、リネームしてＩＯＲファイル４２－１に一旦格納、ＩＯＲファイル４２－１に格納しているＩＯＲをリネームしてローカル・ディレクトリのＩＯＲファイル４３に格納し、ゲートウェイ・ネーミング・サービス装置４内のバスを介してブロードキャストにてリモート・ディレクトリのＩＯＲファイル４４ａに転送する。
【０１６６】ゲートウェイ・ネーミング・サービス部４２ａは、リモート・ディレクトリのＩＯＲファイル４４ａに格納されたＩＯＲをオブジェクト・リファレンスに変換し、変換したオブジェクト・リファレンスを第二のＣＯＲＢＡ下のクライアントのネーミング・サービス部３３に登録する。
【０１６７】第二のＣＯＲＢＡ下のクライアント３ｂにおいて、アプリケーション部３２は、ネーミング・サービス部３３に登録されたオブジェクト・リファレンスを取得し、取得したオブジェクト・リファレンスを参照して第一のＣＯＲＢＡ下のサーバ２ｂのアプリケーション部２２にアクセスすることが可能になるので、異なるＣＯＲＢＡ下の装置であるサーバ２ｂとクライアント３ｂの間で通信することによってオブジェクトの実行が可能になる。
【０１６８】そして、サーバ２ｂとクライアント３ｂが同一ＣＯＲＢＡ下の装置である場合にも、サーバ２ｂが変換して格納したＩＯＲを第二のＣＯＲＢＡ側に転送し、転送されたＩＯＲをゲートウェイ・ネーミング・サービス部４２ａがサーバ２ｂのオブジェクト・リファレンスに復元するので、当然、クライアント３ｂはサーバ２ｂのオブジェクト・リファレンスを取得可能で、サーバ２ｂとクライアント３ｂの間で通信が可能である。
【０１６９】上記では、リモート・ディレクトリのＩＯＲファイル４４とローカル・ディレクトリのＩＯＲファイル４３ａが使用されないかのようであるが、これらは、上記でクライアントであると定義した装置がサーバとなり、上記でサーバであると定義した装置がクライアントになる場合に使用される。そして、サーバであると定義された装置の動作は上記と同じであり、クライアントであると定義された装置の動作も上記と同じである。
【０１７０】上記の如く、ゲートウェイ・ネーミング・サービス部を独立な装置に集約する場合でも、ゲートウェイ・ネーミング・サービス部としての動作は本質的には変わりがないが、若干の違いもあるので、以降、ゲートウェイ・ネーミング・サービス部が独立装置として存在する場合の、サーバ側のゲートウェイ・ネーミング・サービス部とクライアント側のゲートウェイ・ネーミング・サービス部の動作をフローチャートによって説明する。ただ、既に行なった説明との重複になる部分が多いので、説明は簡単にしたい。
【０１７１】図８は、ゲートウェイ・ネーミング・サービス装置のサーバ側ゲートウェイ・ネーミング・サービス部の動作（その２）である。
【０１７２】Ｓ５１．サーバからＩＰアドレス、ホスト名の通知を受ける。
【０１７３】Ｓ５２．ネーミング・サービス部よりオブジェクト・リファレンスを獲得する。
【０１７４】Ｓ５３．獲得したオブジェクト・リファレンスをＩＯＲに変換する。
【０１７５】Ｓ５４．ＩＯＲをサーバ側のローカル・ディレクトリのＩＯＲファイルに格納する。
【０１７６】Ｓ５５．ＩＯＲをクライアント側のリモート・ディレクトリのＩＯＲファイルに格納する。
【０１７７】以上ステップＳ５２乃至ステップＳ５５が、サーバ立ち上げ時のネーミング・サービス装置のサーバ側のゲートウェイ・ネーミング・サービス部の処理である。
【０１７８】そして、一旦スリープ状態に入る。
【０１７９】Ｓ５６．ネーミング・サービス部よりオブジェクト・リファレンスを獲得する。
【０１８０】Ｓ５７．獲得したオブジェクト・リファレンスをＩＯＲに変換する。
【０１８１】Ｓ５８．ＩＯＲが変わっているか否かを判断する。
【０１８２】変わっていない場合（Ｎｏ）には、スリープ状態に戻る。
【０１８３】Ｓ５９．ステップＳ５８で、ＩＯＲが変わっていると判断された場合（Ｙｅｓ）には、ステップＳ５７で新たに変換したＩＯＲをサーバ側のローカル・ディレクトリのＩＯＲファイルに格納する。
【０１８４】Ｓ６０．ＩＯＲをクライアント側のリモート・ディレクトリのＩＯＲファイルに格納する。
【０１８５】以上ステップＳ５５乃至ステップＳ６０が、ゲートウェイ・ネーミング・サービス装置のサーバ側ゲートヲェイ・ネーミング・サービス部の定周期での処理である。
【０１８６】そして、再びスリープ状態に入る。
【０１８７】図９は、ゲートウェイ・ネーミング・サービス装置のクライアント側ゲートウェイ・ネーミング・サービス部の動作（その２）である。
【０１８８】当初は待ち状態にある。
【０１８９】Ｓ７１．クライアント側のリモート・ディレクトリのＩＯＲファイルに格納されているＩＯＲをオブジェクト・リファレンスに変換する。
【０１９０】Ｓ７２．変換されたオブジェクト・リファレンスをクライアントのネーミング・サービス部に登録する。
【０１９１】そして、再び待ち状態に入る。
【０１９２】以上が、ゲートウェイ・ネーミング・サービス装置のクライアント側ゲートヲェイ・ネーミング・サービス部の登録動作である。
【０１９３】
【発明の効果】以上詳述した如く、本発明により、異なるＣＯＲＢＡに準拠するサーバ及びクライアントの間においても、オブジェクト・リファレンスをクライアントに提供できるサーバ、オブジェクト・リファレンスをサーバから受けることができるクライアント、及び、オブジェクト・リファレンスを送受信できるクライアント・サーバ・システムを実現することができる。
【０１９４】即ち、第一の発明によれば、サーバのゲートウェイ・ネーミング・サービス部が、当該サーバでネーミング・サービス部が稼働している場合にはネーミング・サービス部からオブジェクト・リファレンスを収集し、収集したオブジェクト・リファレンスをＩＯＲに変換し、変換したＩＯＲをクライアントにブロードキャスト通知し、当該サーバでネーミングが稼働していない場合にはアプリケーション部のＩＯＲファイルからＩＯＲを収集し、収集したＩＯＲをクライアントにブロードキャスト通知する。
【０１９５】従って、サーバにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、サーバとクライアントの間ではテキスト形式のＩＯＲを転送すればよく、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもオブジェクト・リファレンスの転送が可能になる結果、サーバとクライアント間の間で実質的にオブジェクト・リファレンスの転送が可能になる。
【０１９６】又、第二の発明によれば、クライアントのゲートウェイ・ネーミング・サービス部が、当該クライアントでネーミング・サービス部が稼働している場合にはサーバから転送を受けたＩＯＲをオブジェクト・リファレンスに復元してネーミング・サービス部に登録し、当該クライアントでネーミング・サービス部が稼働していない場合にはサーバから転送を受けたＩＯＲをリネームする。
【０１９７】従って、クライアントにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、クライアントはＩＯＲの転送を受けて、該ＩＯＲからオブジェクト・リファレンスを復元するか、該ＩＯＲをリネームするかが可能になるので、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であっても実質的にオブジェクト・リファレンスの取得が可能になる。
【０１９８】更に、第三の発明によれば、サーバのゲートウェイ・ネーミング・サービス部は、当該サーバでネーミング・サービス部が稼働している場合にはネーミング・サービス部からオブジェクト・リファレンスを収集し、収集したオブジェクト・リファレンスをＩＯＲに変換し、変換したＩＯＲをクライアントにブロードキャスト通知し、当該サーバでネーミングが稼働していない場合にはアプリケーション部のＩＯＲファイルからＩＯＲを収集し、収集したＩＯＲをクライアントにブロードキャスト通知する。又、クライアントのゲートウェイ・ネーミング・サービス部は、当該クライアントでネーミング・サービス部が稼働している場合にはサーバから転送を受けたＩＯＲをオブジェクト・リファレンスに復元してネーミング・サービス部に登録し、当該クライアントでネーミング・サービス部が稼働していない場合にはサーバから転送を受けたＩＯＲをリネームする。
【０１９９】従って、サーバにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、サーバとクライアントの間ではテキスト形式のＩＯＲを転送すればよく、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもオブジェクト・リファレンスの転送が可能になる結果、サーバとクライアント間の間で実質的にオブジェクト・リファレンスの転送が可能になり、クライアントにおけるネーミング・サービス部の稼働、非稼働の如何を問わず、クライアントはＩＯＲの転送を受けて、該ＩＯＲからオブジェクト・リファレンスを復元するか、該ＩＯＲをリネームするので、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもクライアントは実質的にオブジェクト・リファレンスの取得が可能になる。この結果、サーバとクライアントが如何なるＣＯＲＢＡ下の装置であってもサーバとクライアントの間で通信が可能になる。

【出願人】	【識別番号】０００００５２２３【氏名又は名称】富士通株式会社
【出願日】	平成１２年１０月２４日（２０００．１０．２４）
【代理人】	【識別番号】１００１０８２０２【弁理士】【氏名又は名称】野澤裕
【公開番号】	特開２００２－１３２７４０（Ｐ２００２－１３２７４０Ａ）
【公開日】	平成１４年５月１０日（２００２．５．１０）
【出願番号】	特願２０００－３２４０９０（Ｐ２０００－３２４０９０）