(57)【特許請求の範囲】
【請求項１】
ネットワーク接続されたクライアントとサーバがＲＰＣ（リモートプロシジャコール）による通信を行うネットワークコンピュータシステムであって、
ＲＰＣにおける通信のインタフェースの定義情報から、当該定義情報のハッシュ値である前記インタフェースの識別情報を生成する第１の生成手段と、
前記定義情報に基づいて、ＲＰＣにより通信を実行する前記クライアント上のプログラムとなるクライアントスタブと、ＲＰＣにより通信を実行する前記サーバ上のプログラムとなるサーバスタブとを生成し、前記クライアントスタブと前記サーバスタブに前記識別情報をそれぞれ埋め込む第２の生成手段と、
前記定義情報に基づいたＲＰＣによる通信の伝送パケットの送信元となる、前記クライアントスタブをインストールされた前記クライアント又は前記サーバスタブをインストールされた前記サーバが、前記伝送パケットに前記識別情報を付加して送信する手段と、
前記定義情報に基づいたＲＰＣによる通信の前記伝送パケットの送信先となる、前記クライアントスタブをインストールされた前記クライアント又は前記サーバスタブをインストールされた前記サーバが、受信した前記伝送パケットから前記付加された識別情報を取り出し前記自己に埋め込まれた識別情報と比較することで、通信インタフェースの不一致を検出する手段とを備える
ことを特徴とするネットワークコンピュータシステム。
【請求項２】
ＲＰＣにより通信を実行するサーバ上のアプリケーションプログラムのソースコードであって、前記ＲＰＣにおける通信のインタフェースを定義する定義部分を備えるプログラムソースコードの前記定義部分から生成した前記定義部分のハッシュ値である前記インタフェースの識別情報を埋め込まれており、前記定義部分に基づいて前記ＲＰＣによる通信を行う際に、送信元は伝送パケットに前記識別情報を付加して送信し、送信先は受信した前記伝送パケットから前記付加された識別情報を取り出し前記自己に埋め込まれた識別情報と比較することで、通信インタフェースの不一致を検出する下位ＲＰＣ通信手段と、
前記ＲＰＣにおける通信のインタフェースの定義情報に基づいて前記ＲＰＣによる通信を行う上位ＲＰＣ通信手段とを備える
ことを特徴とするネットワークコンピュータシステム。
【請求項３】
ＲＰＣにより通信を実行するサーバ上のアプリケーションプログラムのソースコードであって、前記ＲＰＣにおける通信のインタフェースを定義する定義部分を備えるプログラムソースコードの前記定義部分のハッシュ値である前記インタフェースの識別情報を生成する第１の生成手段と、
前記定義部分に基づいて前記ＲＰＣによる通信を行う下位ＲＰＣ通信手段を生成し、前記下位ＲＰＣ通信手段に前記識別情報を埋め込む第２の生成手段と、
前記ＲＰＣにおける通信のインタフェースの定義情報に基づいて前記ＲＰＣによる通信を行う上位ＲＰＣ通信手段を生成する第３の生成手段とを備える
ことを特徴とするネットワークコンピュータシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークコンピュータシステムに関し、特に、プログラム間のインタフェースの信頼性を向上したリモートプロシジャコールを利用したネットワークコンピュータシステムに関する。
【０００２】
【従来の技術】
分散処理環境を構成するネットワークコンピュータシステムでは、サーバやクライアントの上で動作する複数のプログラムが処理を相互に分散するために、リモートプロシジャコール（ＲＰＣ）を採用する場合がある。ＲＰＣにおいては、例えば、サーバ上のあるアプリケーションプログラムが、そのプロシジャの一部をクライアント上の他のアプリケーションプログラムに実行させて、その結果を通常のプロシジャコールと同様に帰り値として受け取る。
【０００３】
ＲＰＣにおいては、開発時において、そのインタフェースをインタフェース定義スクリプト（ＩＤＬ）に記述しておく。そして、ＩＤＬに基づいて、アプリケーションプログラムがＲＰＣにより通信を実行する時にこれを支援する（代わりにＲＰＣにより通信を実行する）プログラム（スタブ（ＳＴＵＢ）プログラム）を、自動生成する。スタブプログラムは、コンパイルにより、サーバ及びクライアントの各々の上のアプリケーションプログラムに組み込まれる。運用時において、サーバ及びクライアント上のアプリケーションプログラムは、各々のスタブプログラムによりＲＰＣにより通信を実行する。
【０００４】
【発明が解決しようとする課題】
種々の理由により、ＲＰＣのインタフェースが変更され、これに伴って、ＩＤＬがバージョンアップ（改版）される場合がある。本来であれば、これは、サーバ及びクライアントの双方において、同様にインタフェースに反映されているはずである。
【０００５】
しかし、ＩＤＬがバージョンアップされた場合、運用時において、インタフェースの不一致による実行不可が出力されることがある。例えば、サーバ上のアプリケーションプログラムに組み込まれたスタブプログラムが、クライアントから受信した伝送パケットを分析しインタフェースが合致するか否かを検証した結果、インタフェースが不一致となり、実行不可が出力されることがある。このような事態は、多くの場合サーバ（の管理者）が新しいスタブプログラムをコンパイルしていないこと等により生じる。この場合、処理が途中で止まってしまうことになる。また、当該検証を終了するまでは、インタフェースの不一致を検出することができない。
【０００６】
また、ＩＤＬがバージョンアップされた場合、運用時において、本来ＩＤＬが不一致であるにもかかわらず、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラムを実行してしまうことがある。即ち、実際はＩＤＬが変更されているが、データパケットとして見た場合にはインタフェースが変更とならない場合がある。これは、例えば、バージョンアップが、送信パケットのフォーマット等に関するものではなく、些細なバグ（スペルミス等）の訂正等である場合である。この場合、例えばクライアントから受信した送信パケットのフォーマット等が一致してしまうと、サーバ上のスタブプログラムを介してこれを受け取ったアプリケーションプログラムが、帰り値をクライアント上の当該アプリケーションプログラムに返してしまう。しかし、この場合、本来バージョンが不一致であるので、サーバのアプリケーションプログラムは誤った処理を実行した可能性がある。従って、また、クライアントのアプリケーションプログラムも、誤った処理に基づく誤った帰り値を用いて誤った処理を実行する可能性がある。
【０００７】
なお、以上のような誤動作等を防止するためには、ＩＤＬのバージョン（版数）を管理することが望ましい。しかし、ＩＤＬの版数を管理しようとすると、開発者が当該バージョン情報をＩＤＬ内に記述する必要がある。これは開発者にとっては煩わしいので記述を省略する場合があり、また、人手により管理することになるので開発者が記述を忘れたり内容を誤ったりする場合がある。従って、管理されていない場合や、管理されてはいても適切でない場合がある。なお、ＩＤＬのバージョン管理は義務付けられてはいない。
【０００８】
本発明は、リモートプロシジャコールのインタフェースの信頼性を向上したネットワークコンピュータシステムを提供することを目的とする。
【０００９】
また、本発明は、リモートプロシジャコールのインタフェースの変更の管理を行うことなく、確実にインタフェースの不一致を検出するネットワークコンピュータシステムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明のネットワークコンピュータシステムは、ネットワーク接続されたクライアントとサーバがＲＰＣ（リモートプロシジャコール）による通信を行う場合において、ＲＰＣにおける通信のインタフェースの定義情報から生成されたインタフェースの識別情報を含み、識別情報を用いて定義情報に基づいてＲＰＣにおける通信を行うＲＰＣ通信手段を備える。具体的には、本発明のネットワークコンピュータシステムは、ＲＰＣにおける通信のインタフェースの定義情報から、当該定義情報のハッシュ値である前記インタフェースの識別情報を生成する第１の生成手段と、前記定義情報に基づいて、ＲＰＣにより通信を実行する前記クライアント上のプログラムとなるクライアントスタブと、ＲＰＣにより通信を実行する前記サーバ上のプログラムとなるサーバスタブとを生成し、前記クライアントスタブと前記サーバスタブに前記識別情報をそれぞれ埋め込む第２の生成手段と、前記定義情報に基づいたＲＰＣによる通信の伝送パケットの送信元となる、前記クライアントスタブをインストールされた前記クライアント又は前記サーバスタブをインストールされた前記サーバが、前記伝送パケットに前記識別情報を付加して送信する手段と、前記定義情報に基づいたＲＰＣによる通信の前記伝送パケットの送信先となる、前記クライアントスタブをインストールされた前記クライアント又は前記サーバスタブをインストールされた前記サーバが、受信した前記伝送パケットから前記付加された識別情報を取り出し前記自己に埋め込まれた識別情報と比較することで、通信インタフェースの不一致を検出する手段とを備える。
【００１２】
本発明のネットワークコンピュータシステムによれば、インタフェースの識別情報が当該ＲＰＣのインタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成される。従って、当該定義情報をＲＰＣのインタフェースについて一意に定めることができる。そして、識別情報を埋め込まれたクライアントスタブとサーバスタブをインストールされたクライアント又はサーバが、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。これにより、インタフェースが変更（ＩＤＬがバージョンアップ）された場合、運用時において、インタフェースの不一致を確実に検出することができる。特に、インタフェースが不一致であるにもかかわらず、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラムを実行してしまうことを防止することができる。また、インタフェースのバージョンの管理や記述等についての開発者の負担をなくすことができ、前記バージョンの管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【００１３】
また、本発明のネットワークコンピュータシステムは、ＲＰＣにより通信を実行するサーバ上のアプリケーションプログラムのソースコードであって、前記ＲＰＣにおける通信のインタフェースを定義する定義部分を備えるプログラムソースコードの前記定義部分から生成した前記定義部分のハッシュ値である前記インタフェースの識別情報を埋め込まれており、前記定義部分に基づいて前記ＲＰＣによる通信を行う際に、送信元は伝送パケットに前記識別情報を付加して送信し、送信先は受信した前記伝送パケットから前記付加された識別情報を取り出し前記自己に埋め込まれた識別情報と比較することで、通信インタフェースの不一致を検出する下位ＲＰＣ通信手段と、前記ＲＰＣにおける通信のインタフェースの定義情報に基づいて前記ＲＰＣによる通信を行う上位ＲＰＣ通信手段とを備える。
また、本発明のネットワークコンピュータシステムは、ＲＰＣにより通信を実行するサーバ上のアプリケーションプログラムのソースコードであって、前記ＲＰＣにおける通信のインタフェースを定義する定義部分を備えるプログラムソースコードの前記定義部分のハッシュ値である前記インタフェースの識別情報を生成する第１の生成手段と、前記定義部分に基づいて前記ＲＰＣによる通信を行う下位ＲＰＣ通信手段を生成し、前記下位ＲＰＣ通信手段に前記識別情報を埋め込む第２の生成手段と、前記ＲＰＣにおける通信のインタフェースの定義情報に基づいて前記ＲＰＣによる通信を行う上位ＲＰＣ通信手段を生成する第３の生成手段とを備える。
【００１４】
本発明のネットワークコンピュータシステムによれば、インタフェースの識別情報が当該ＲＰＣのインタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成され、これがリモートプロシジャコールにおける通信を行う下位ＲＰＣ通信手段に埋め込まれる。そして、下位ＲＰＣ通信手段が、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。従って、インタフェースのバージョンの管理や記述等についての開発者の負担なしで、事実上当該管理等を行うことができ、当該管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【００１５】
【発明の実施の形態】
図１は、ネットワークコンピュータシステム構成図であり、本発明のネットワークコンピュータシステムの構成を示す。
【００１６】
ネットワークコンピュータシステムは、複数のネットワークコンピュータ２０、３０とこれらの間を接続するネットワーク４０からなる。ネットワークコンピュータ２０、３０は、例えばサーバ２０及びクライアント３０からなり、リモートプロシジャコール（ＲＰＣ）によりコンピュータ間通信を行う。サーバ２０及びクライアント３０は各々複数であってもよい。ネットワークコンピュータシステムは、サーバ２０及びクライアント３０以外に、例えば開発用のホストコンピュータ１０を備える。
【００１７】
ホストコンピュータ１０は、サーバ２０及びクライアント３０の開発のために、スタブ（ＳＴＵＢ）ジェネレータ１２、コンパイラ及びリンカ１７を備える。スタブジェネレータ１２、コンパイラ及びリンカ１７は、ホストコンピュータ１０を構成する主メモリ（図示せず）上に存在しホストコンピュータ１０を構成するＣＰＵ（図示せず）上で実行される当該プログラムにより実現される。また、ホストコンピュータ１０は、インタフェース定義スクリプト（ＩＤＬ）１１、サーバ２０上で動作するアプリケーション（ソース又はオブジェクト）プログラム（サーバアプリ）１８、クライアント３０上で動作するアプリケーション（ソース又はオブジェクト）プログラム（クライアントアプリ）１９を、磁気ディスク装置等の補助記憶（図示せず）上に備える。
【００１８】
ホストコンピュータ１０は、図１に点線で示すように、ネットワーク４０を介して、サーバ２０等と接続してもよい。この場合、後述するスタブプログラム１５等は、ネットワーク４０を介して、サーバ２０等に配信される。また、スタブジェネレータ１２、コンパイラ及びリンカ１７は、バージョンアップされたＩＤＬ（修正ＩＤＬ）１１’に基づいてスタブプログラム１５（２２、２３）を生成する必要があるため、サーバ２０及びクライアント３０の各々にも設けられる（図示せず）。この場合、修正ＩＤＬ１１’は、フレキシブルディスク等により、サーバ２０及びクライアント３０に提供される。
【００１９】
スタブジェネレータ１２はスタブプログラム（又はスタブコード）１５を生成する。スタブプログラム１５は、アプリケーションプログラムがＲＰＣにより通信を実行する時に、これを支援する。即ち、アプリケーションプログラム（２１、３１）の代わりにＲＰＣにより通信を実行するＲＰＣ通信手段１５（２２、３２）である。この生成のために、スタブジェネレータ１２は第１の生成手段１３と第２の生成手段１４とを備える。第１の生成手段１３は、ＲＰＣにおける通信のインタフェースの定義情報（ＩＤＬ）１１からインタフェースの識別情報１６を生成する。第２の生成手段１４は、定義情報１１に基づいてＲＰＣにおける通信を行うＲＰＣ通信手段１５を生成し、ＲＰＣ通信手段１５に識別情報１６を付加する。
【００２０】
この例において、定義情報１１は、インタフェース定義スクリプト（ＩＤＬ）１１からなる。ＩＤＬ１１はＲＰＣにおける通信のインタフェースを定義する。また、識別情報１６は、定義情報１１から生成されたハッシュ値（ハッシュコード）１６からなる。従って、この例では、ＩＤＬ１１からハッシングにより識別情報１６としてのハッシュ値１６が生成され、ＩＤＬ１１に基づいてスタブプログラム１５が生成される。そして、ハッシュ値１６はスタブプログラム１５に付加される（埋め込まれる）。このために、スタブジェネレータ１２はハッシュ関数を備える。ハッシュ関数としては、例えば周知のＲＳＡ−ＭＤ５：ＲＦＣ１３２１を用い、例えば１６バイトのメッセージダイジェストとされる。スタブプログラム１５としては、クライアント３０上のスタブプログラム（クライアントスタブ）３２と（なるもの）、及び、サーバ２０上のスタブプログラム（サーバスタブ）２２と（なるもの）が生成される。
【００２１】
ここで、ＩＤＬ１１の一例を図２に示す。図２において、ＩＤＬ１１は、ＲＰＣのインタフェースの種々の情報を記述する。ＩＤＬ１１は、図２に示すようなテキストファイルである。図２のＩＤＬ１１の全体がハッシングに用いられる。ハッシングの結果生成されるハッシュ値１６は、図３に示すように、１６バイトの１６進数である。
【００２２】
サーバスタブ２２の一例を図３に示す。サーバスタブ２２は、実際には、２個のハッシュ値１６（１６１、１６２）を保持する。例えば、ハッシュ値１６１は、クライアント３０から受信した伝送パケット５０に埋め込まれたハッシュ値１６と比較するためのものである。サーバスタブ２２は、受信した識別情報１６を解析し、これが自己の持つ識別情報１６１と不一致である場合、受信した識別情報１６の送信元であるクライアント３０にエラー情報を返信する。ハッシュ値１６２は、当該サーバ２０がクライアント３０に対して伝送パケット５０を送信する際に、これに埋め込むためのものである。サーバスタブ２２は、２個のエラー値２２１及び２２２をも保持する。エラー値２２１及び２２２は、ハッシュ値１６１とクライアント３０から受信した伝送パケット５０に埋め込まれたハッシュ値１６との比較結果が不一致である場合に、クライアント３０に対して返信されるエラーメッセージである。エラー値２２１及び２２２は、エラーの種類に応じて、使い分けられる。なお、クライアントスタブ３２も同様の構成を有する。
【００２３】
コンパイラ及びリンカ１７は、クライアントアプリ（のソース）１９をコンパイルしたものにクライアントスタブ１５（３２）をリンクして、クライアントアプリの実行形式のロードモジュール（クライアントＲＭ）３３を得て、これをクライアント３０にインストールする。また、コンパイラ及びリンカ１７は、サーバアプリ（のソース）１８をコンパイルしたものにサーバスタブ１５（２２）をリンクしてサーバアプリの実行形式のロードモジュール（サーバＲＭ）２３を得て、これをサーバ２０にインストールする。なお、クライアントＲＭ３３もクライアントアプリといい、サーバＲＭ２３もサーバアプリということとする。
【００２４】
ネットワークコンピュータであるサーバ２０は、複数の（実行形式の）サーバアプリ２３を備える。複数のサーバアプリ２３の各々は、サーバ２０が提供するサービス（呼び出されるプロシジャ）の各々に応じて設けられる。複数のサーバアプリ２３の各々がスタブプログラム（サーバスタブ）２２を備える。ネットワークコンピュータであるクライアント２０は、複数の（実行形式の）クライアントアプリ３３を備える。複数のクライアントアプリ３３の各々は、クライアント３０が実行する処理（アプリケーション）の各々に応じて設けられる。複数のクライアントアプリ３３の各々がスタブプログラム（クライアントスタブ）３２を備える。
【００２５】
ネットワークコンピュータであるサーバ２０及びクライアント３０は、ロードモジュールの形で、各々、ＲＰＣ通信手段であるスタブプログラム２２及び３２（１５）を備える。スタブプログラム２２及び３２は、ＲＰＣにおける通信のインタフェースの定義情報１１から生成されたインタフェースの識別情報１６を含み、定義情報１１に基づいてＲＰＣにおける通信を行う。具体的には、クライアント３０では、ＲＰＣ通信手段３２が、少なくとも識別情報１６を送信する。サーバ２０では、ＲＰＣ通信手段２２が、少なくとも受信した識別情報１６を解析する。
【００２６】
サーバ２０及びクライアント３０は、ネットワーク４０を介して、ＲＰＣに従って、コンピュータ間通信を行う。この通信において、識別情報１６が当該伝送データの先頭に（又は先頭の伝送パケットに）付加される。従って、この例では、前述のように、定義情報１１であるＩＤＬ１１から生成された識別情報１６であるハッシュ値１６が、先頭の伝送パケットに格納される。
【００２７】
クライアントスタブ３２は、少なくとも識別情報１６としてのハッシュ値１６を送信する。従って、クライアントスタブ３２として生成されたスタブプログラム１５は、ハッシュ値１６を送信する機能を備える。サーバスタブ２２は、少なくとも受信した識別情報１６としてのハッシュ値１６を解析する。従って、サーバスタブ２２として生成されたスタブプログラム１５は、ハッシュ値１６を解析する機能を備える。なお、実際は、クライアントスタブ３２も受信した識別情報１６を解析し、サーバスタブ２２も識別情報１６を送信する場合があるので、両者は同一であってよい。
【００２８】
サーバ２０及びクライアント３０は、コンピュータ間通信を行うために、各々、伝送処理部２４及び３４を備える。また、クライアント３０は、クライアントアプリ３１における処理結果等を表示する表示装置３５、クライアントアプリ３１における処理のための指示入力等のための入力装置３６を備える。
【００２９】
図４は、スタブプログラム２２、３２の生成処理フローを示す。
【００３０】
開発者が、ＩＤＬ１１を作成し（ステップＳ１）、この後、スタブジェネレータ１２を起動する（ステップＳ２）。
【００３１】
スタブジェネレータ１２が、ＩＤＬ１１を読み込み（ステップＳ３）、ＩＤＬ１１をハッシングすることにより、これからハッシュ値１６を算出する（ステップＳ４）。この後、スタブジェネレータ１２が、クライアントスタブ３２を生成する（ステップＳ５）。このクライアントスタブ３２には、識別情報１６としてハッシュ値１６が埋め込まれる。また、スタブジェネレータ１２が、サーバスタブ２２を生成する（ステップＳ６）。このサーバスタブ２２にも、識別情報１６として同一のハッシュ値１６が埋め込まれる。
【００３２】
開発者が、クライアント３０に、クライアントアプリ（ＡＰＬとも記す、以下同じ）３３をビルド（内蔵）する（ステップＳ７）。即ち、コンパイラ及びリンカ１７により、クライアントアプリ１９をコンパイルしたもの（３１）にクライアントスタブ３２をリンクしてクライアントアプリ１９のロードモジュール（クライアントＲＭ）３３を得て、これをクライアント３０にインストールする。
【００３３】
また、開発者が、サーバ２０に、サーバアプリ２３をビルド（内蔵）する（ステップＳ８）。即ち、コンパイラ及びリンカ１７により、サーバアプリ１８をコンパイルしたもの（２１）にサーバスタブ２２をリンクしてサーバアプリ１８のロードモジュール（サーバＲＭ）２３を得て、これをサーバ２０にインストールする。
【００３４】
図５は、クライアント３０におけるＲＰＣによる通信処理フローを示す。
【００３５】
（クライアントＲＭ３３の）クライアントアプリ３１が、サーバ２０の呼び出しを（クライアントＲＭ３３の）クライアントスタブ３２に依頼する（ステップＳ１１）。
【００３６】
クライアントスタブ３２が、伝送データの作成処理を行う（ステップＳ１２）。この作成処理において、クライアントスタブ３２が、自己の保持するハッシュ値１６をデータの先頭に埋め込み（ステップＳ１３）、パラメータを組み立てることにより伝送パケット５０を生成し（ステップＳ１４）、この送信を伝送処理部３４に依頼する。
【００３７】
この依頼を受けたクライアント３０の伝送処理部３４が、通信処理を行う。即ち、伝送処理部３４がサーバ２０に伝送パケット５０を送信する（ステップＳ１５）。この送信処理は図６のステップＳ２１に対応する。伝送処理部３４は、サーバ２０からの応答があると、当該処理結果を受信する（ステップＳ１６）。この受信処理は図６のステップＳ２９に対応する。この後、クライアント３０における処理は、クライアントスタブ３２を介して、クライアントアプリ３１に復帰する（ステップＳ１７）。
【００３８】
図６は、サーバ２０におけるＲＰＣによる通信処理フローを示す。
【００３９】
サーバ２０の伝送処理部２４が、クライアント３０からの伝送パケット５０を受信し（ステップＳ２１）、起動対象のサーバスタブ２２を検索して選択し（ステップＳ２２）、当該サーバスタブ２２を起動する（ステップＳ２３）。ステップＳ２１は図５のステップＳ１５に対応する。
【００４０】
起動されたサーバスタブ２２は受信した伝送データを解析する。即ち、サーバスタブ２２が、受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しいか否かを調べる（ステップＳ２４）。
【００４１】
等しい場合、サーバスタブ２２は、伝送パケット５０の後続のパラメータを解析して（ステップＳ２５）、サーバアプリ２１を起動し（ステップＳ２６）、応答を待つ。起動されたサーバアプリ２１は、解析された後続のパラメータを用いて所定の処理を行い、その処理結果をサーバスタブ２２に返す（ステップＳ２７）。サーバスタブ２２は、サーバアプリ２１からの処理結果を帰り値（復帰値）として設定し（ステップＳ２８）、伝送処理部２４に返信を依頼する。
【００４２】
伝送処理部２４は、サーバスタブ２２からの依頼に従って、結果をクライアント３０に返信する（ステップＳ２９）。この処理は図５のステップＳ１６に対応する。
【００４３】
一方、ステップＳ２４において受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しくない場合、サーバスタブ２２は、エラー値を設定し（ステップＳ３０）、伝送処理部２４に返信を依頼する。この後、ステップＳ２９が実行される。
【００４４】
図７及び図８は、ハッシュ値１６を用いたインタフェースのバージョンの検出処理説明図である。
【００４５】
図７において、ＲＰＣを採用するアプリケーションプログラム２３、３３の開発時、開発者により、インタフェース定義スクリプト（ＩＤＬ）１１が用意される。ＩＤＬ１１はＲＰＣのインタフェースを記述する。
【００４６】
スタブジェネレータ１２が、ＩＤＬ１１に基づいて、スタブプログラム１５を生成する。また、スタブジェネレータ１２は、ＩＤＬ１１からハッシングにより識別情報（ハッシュ値）１６を生成する。スタブジェネレータ１２は、生成した識別情報１６をスタブプログラム１５（サーバスタブ２２及びクライアントスタブ３２）に付加する。
【００４７】
識別情報１６はＩＤＬ１１（のバージョン）を一意に特定できるものであればよい。従って、識別情報１６はＩＤＬ１１のバージョン情報である。例えば、識別情報１６はＩＤＬ１１から生成したハッシュ値１６（ハッシュ値）からなる。即ち、ＩＤＬ１１それ自体をハッシングすることにより、識別情報１６を生成する。ハッシュ値１６が相互に衝突することは、確率的に見て事実上あり得ない。従って、このハッシュ値１６はＩＤＬ１１（のバージョン）を一意に特定できる。ＩＤＬ１１のバージョン情報をＩＤＬ１１自体のハッシングにより生成しているので、開発者がＩＤＬ１１の版数をＩＤＬ１１に記述し管理する必要がなく、従って、ＩＤＬ１１のバージョン情報を人為的に誤ることもない。
【００４８】
スタブプログラム１５は、コンパイラ及びリンカ１７の実行するコンパイル及びリンクにより、アプリケーションプログラムに組み込まれる。即ち、サーバスタブ２２及びクライアントスタブ３２が、各々、コンパイルされたサーバアプリ２１及びクライアントアプリ３１にリンクされる。これにより、サーバアプリ２１のロードモジュール（サーバＲＭ）２３及びクライアントアプリ３１のロードモジュール（クライアントＲＭ）３３が得られる。
【００４９】
ＲＰＣを採用するアプリケーションプログラム２３、３３の運用時において、サーバ２０及びクライアント３０上のアプリケーションプログラム２３、３３は、各々のスタブプログラム２２、３２（１５）によりＲＰＣにより通信を実行する。例えば、クライアントスタブ３２は、送信する伝送パケット５０を生成して、その先頭に自己に付加された識別情報１６であるハッシュ値１６を付加する。これを受信したサーバスタブ２２は、当該伝送パケット５０からハッシュ値１６を取り出して、これと自己に付加されたハッシュ値１６とを比較する。両者が一致すれば、ＩＤＬ１１（のバージョン）が一致していることになる。従って、以後の通信が正しいことが保証される。
【００５０】
図８において、図７の開発の後、ＲＰＣのインタフェースの変更により、開発者により、バージョンアップ（改版）されたＩＤＬ（修正ＩＤＬ）１１’が作成される。そこで、前述と同様に、スタブジェネレータ１２が、修正ＩＤＬ１１’に基づいてスタブプログラム１５’を生成し、修正ＩＤＬ１１’から新たなハッシュ値（新ハッシュ値）１６’を生成する。ＩＤＬ１１のバージョンアップがあれば、それが送信パケットのフォーマットの変更ではなく単なるバグの修正であっても、当該修正が必ずハッシュ値１６に反映される。即ち、バージョンアップの前後において、ハッシュ値１６と１６’とは必ず異なるものとなる。従って、この点からも、ハッシュ値１６はＩＤＬ１１（のバージョン）を一意に特定できる。
【００５１】
通常は、スタブジェネレータ１２により、クライアント３０及びサーバ２０の双方において、新ハッシュ値１６’を埋め込んだクライアントスタブ３２’及びサーバスタブ２２’として再度生成される。なお、スタブジェネレータ１２は、新ハッシュ値１６’を生成した後、ハッシュ値１６と１６’とを比較し、両者に相違がない場合、インタフェースの変更がＲＰＣ通信にかかわりのないものであると判断して、新しいクライアントスタブ３２’及びサーバスタブ２２’の生成を行わない。これにより、不必要な更新は行われることがない。
【００５２】
しかし、修正ＩＤＬ１１’に基づくスタブプログラム１５’が作成されたにもかかわらず、サーバ２０が、これをコンパイル（及びリンク）しなかったとする。クライアント３０は、前述と同様に、コンパイル（及びリンク）したとする。この場合、運用時において、例えばクライアントスタブ３２’は、その先頭に新ハッシュ値１６を付加した伝送パケット５０をサーバスタブ２２へ送信する。これを受信したサーバスタブ２２が、当該伝送パケット５０から取り出した新ハッシュ値１６’と、これと自己に付加された（旧）ハッシュ値１６とを比較する。従って、両者は一致しないので、ＩＤＬ１１（のバージョン）が不一致であるとして、サーバスタブ２２からクライアントスタブ３２’にエラーが通知される。
【００５３】
従って、先頭の伝送パケット５０を解析した時点で、ＩＤＬ１１が不一致であることを検出することができる。これにより、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラム２３、３３を実行してしまうことを防止することができる。また、以後のパケットを解析する必要がないので、処理に無駄が生じることがない。なお、以上とは逆に、クライアント３０において新しいクライアントスタブ３２’のコンパイルが行われていない場合でも同様である。また、利用者が誤って、古いサーバスタブ２２又はクライアントスタブ３２を起動してしまった場合でも同様である。更に、例えば、サーバ２０において、サーバスタブ２２（従って、ＩＤＬ１１）を勝手に変更したような場合でも同様である。
【００５４】
図９及び図１０は、ネットワークコンピュータシステム構成図であり、図１のネットワークコンピュータシステム（ＲＰＣシステム）を利用した汎用的なＲＰＣシステムの構成を示す。
【００５５】
図１のＲＰＣシステムにおいては、サーバ２０におけるアプリケーションプログラム（サブルーチン）の各々に応じて、ＩＤＬ１１及びスタブジェネレータ１２を用意する必要がある。また、既存のＲＰＣシステムにハッシュ値１６によるインタフェースの検査を導入するためには、既存のプログラムを当該処理を行うように変更する必要がある。
【００５６】
そこで、図９に示すように、図１のＲＰＣシステムを基盤としてのＲＰＣシステムとして採用する。即ち、ＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００は、各々、図１のサーバ２０及びクライアント３０に相当する。図９のサーバ２０とクライアント３０との間の通信は、全て１個のＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００に依存する。基盤としてのＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００と実際のアプリケーションプログラム２１Ａ及び３１Ａとの間の通信（従って、アプリケーションプログラム間の通信）を、１個の汎用（ユニバーサル）インタフェース６０で、統一的に通信する。汎用インタフェース６０と実際のアプリケーションプログラム２１Ａ及び３１Ａとの間には、各々、マーシャリングプログラム（又はコード）２２Ａ及び３２Ａが存在する。マーシャリングプログラム２２Ａ及び３２Ａは、通常のＲＰＣシステムにおけるスタブプログラム（図１のスタブプログラム２２及び３２）が実行する種々の処理を行う。
【００５７】
即ち、図９から判るように、図９のサーバ２０とクライアント３０は階層的な通信手段を構成する。下位ＲＰＣ通信手段であるマーシャリングプログラム２２Ａ及び３２Ａは、インタフェースの識別情報１６を含む。識別情報１６は、ＲＰＣにより通信を実行するサーバ２０上のアプリケーションプログラム２１ＡにおけるＲＰＣにおける通信のインタフェースを定義する定義部分から生成される。マーシャリングプログラム２２Ａ及び３２Ａは、識別情報１６を用いて、定義部分に基づいて、ＲＰＣにおける通信を行う。上位ＲＰＣ通信手段であるＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００（サーバスタブ２２２及びクライアントスタブ３３２）は、ＲＰＣにおける通信のインタフェースの定義情報に基づいて、ＲＰＣにおける通信を行う。
【００５８】
インタフェースの識別情報１６は、第１の生成手段であるスタブジェネレータ１２Ａにより、アプリケーションプログラム２１Ａの前記定義部分から生成される。下位ＲＰＣ通信手段であるマーシャリングプログラム２２Ａ及び３２Ａは、第２の生成手段であるスタブジェネレータ１２Ａにより、前記定義部分に基づいて生成される。上位ＲＰＣ通信手段であるサーバスタブ２２２及びクライアントスタブ３３２は、ＲＰＣにおける通信のインタフェースの定義情報（ＩＤＬ）１１に基づいて、第３の生成手段であるスタブジェネレータ１２により、前記定義情報１１に基づいて生成される。
【００５９】
即ち、図１０に示すように、ＲＰＣサーバシステム２００におけるサーバスタブ２２２は、そのＩＤＬ１１に基づいて、スタブジェネレータ１２により生成される。この時、ＩＤＬ１１からのハッシュ値（１６）の生成は行われない。従って、この例におけるサーバスタブ２２２は、識別情報１６を持たない（この点で、図１の例とは異なる）。サーバスタブ２２２とサーバアプリ２２１とで、ＲＰＣサーバシステム２００（のロードモジュール２２３）を構成する。ＲＰＣクライアントシステム３００におけるクライアントスタブ３３２についても同様である。クライアントスタブ３３２とクライアントアプリ３３１とで、ＲＰＣクライアントシステム３００（のロードモジュール３３３）を構成する。なお、図１０において、コンパイラ及びリンカ（１７）、伝送処理部（２４、３４）は、図示を省略している。
【００６０】
一方、サーバ２０上のマーシャリングプログラム（サーバマーシャリング）２２Ａは、サーバアプリ２１Ａのソースコード２１Ａ’上のインタフェース定義部に基づいて、スタブジェネレータ１２Ａにより生成される。この時、インタフェース定義部からのハッシュ値１６が生成される。従って、サーバマーシャリング２２Ａは、ハッシュ値１６からなる識別情報１６を持つ。クライアント３０上のマーシャリングプログラム（クライアントマーシャリング）３２Ａも、同様に、サーバアプリ２１Ａのソースコード２１Ａ’上のインタフェース定義部に基づいてスタブジェネレータ１２Ａにより生成され、インタフェース定義部からのハッシュ値１６が埋め込まれる。従って、クライアントマーシャリング３２Ａも、ハッシュ値１６からなる識別情報１６を持つ。
【００６１】
図１１は、サーバアプリ２１Ａのソースコード２１Ａ’上のインタフェース定義部の一例を示す図である。ソースコード２１Ａ’上のインタフェース定義部は、図１１（Ａ）に示すパラメータ部と、図１１（Ｂ）に示すリンケージ部とからなる。これらが、サーバマーシャリング２２Ａとサーバアプリ２１Ａとの間の通信に関する定義情報である。
【００６２】
図１２は、マーシャリングプログラムの生成処理フローである。
【００６３】
開発者が、サーバアプリ２１Ａのソースコード２１Ａ’を作成し（ステップＳ３１）、この後、スタブジェネレータ１２Ａを起動する（ステップＳ３２）。なお、ＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００は、図１の例と類似の処理により、既に生成されているものとする。
【００６４】
スタブジェネレータ１２Ａが、サーバアプリ２１Ａのソースコード２１Ａ’を読み込み（ステップＳ３３）、ソースコード２１Ａ’上のインタフェース定義部からハッシュ値１６を算出する（ステップＳ３４）。
【００６５】
スタブジェネレータ１２が、クライアントマーシャリング３２Ａを生成する（ステップＳ３５）。このクライアントマーシャリング３２Ａには、識別情報１６としてハッシュ値１６が埋め込まれる。
【００６６】
スタブジェネレータ１２Ａが、サーバマーシャリング２２Ａを生成する（ステップＳ３６）。このサーバマーシャリング２２Ａにも、識別情報１６として同一のハッシュ値１６が埋め込まれる。
【００６７】
クライアント３０に、クライアントアプリ３３Ａをビルド（内蔵）する（ステップＳ３７）。即ち、コンパイラ及びリンカ（１７）により、クライアントアプリをコンパイルしたもの（３１Ａ）にクライアントマーシャリング３２Ａをリンクしてクライアントアプリのロードモジュール（クライアントＲＭ）３３Ａを得て、これをクライアント３０にインストールする。
【００６８】
サーバ２０に、サーバアプリ２３Ａをビルド（内蔵）する（ステップＳ３８）。即ち、コンパイラ及びリンカ（１７）により、サーバアプリ２１Ａ’をコンパイルしたもの２１Ａにサーバマーシャリング２２Ａをリンクしてサーバアプリ２１Ａ’のロードモジュール（サーバＲＭ）２３Ａを得て、これをサーバ２０にインストールする。
【００６９】
図１３は、クライアント３０におけるＲＰＣによる通信処理フローである。
【００７０】
（クライアントＲＭ３３Ａの）クライアントアプリ３１Ａが、サーバ２０の呼び出しを（クライアントＲＭ３３Ａの）クライアントマーシャリング３２Ａに依頼する（ステップＳ４１）。
【００７１】
クライアントマーシャリング３２Ａが、伝送データの作成処理を行う（ステップＳ４２）。この処理において、クライアントマーシャリング３２Ａが、起動パラメータ５１の先頭にハッシュ値１６を埋め込み（ステップＳ４３）、パラメータを組み立てることにより起動パラメータ５１を生成し（ステップＳ４４）、これを汎用インタフェース６０に送りサーバ２０の起動を依頼する（ステップＳ４５）。
【００７２】
依頼された汎用インタフェース６０は、ＲＰＣクライアントシステム３００及びＲＰＣサーバシステム２００を介して、サーバ２０（のサーバアプリ２１Ａ）を起動する。この処理は図１４のステップＳ５１に対応する。ＲＰＣクライアントシステム３００及びＲＰＣサーバシステム２００の間の処理は、図１の例に類似である。汎用インタフェース６０は、サーバ２０からの応答があると、当該処理結果を受信する（ステップＳ４６）。この受信処理は図１４のステップＳ５８に対応する。この後、クライアント３０における処理は、クライアントマーシャリング３２Ａを介して、クライアントアプリ３１Ａに復帰する（ステップＳ４７）。
【００７３】
図１４は、サーバ２０におけるＲＰＣによる通信処理フローである。
【００７４】
サーバ２０の汎用インタフェース６０は、ＲＰＣサーバシステム２００を介して、クライアント３０からの起動要求を受信する（ステップＳ５１）。この処理は、図１３のステップＳ４５に対応する。汎用インタフェース６０は、起動対象のサーバマーシャリング２２Ａを検索して選択し（ステップＳ５２）、当該サーバマーシャリング２２Ａを起動する（ステップＳ５３）。
【００７５】
起動されたサーバマーシャリング２２Ａは受信した起動パラメータ５１を解析する。即ち、サーバマーシャリング２２Ａが、受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しい否かを調べる（ステップＳ５４）。
【００７６】
等しい場合、サーバマーシャリング２２Ａは、当該起動パラメータ５１の後続のパラメータを解析して（ステップＳ５５）、サーバアプリ２１Ａを起動し（ステップＳ５６）、応答を待つ。起動されたサーバアプリ２１Ａは、解析された後続のパラメータを用いて所定の処理を行い、その処理結果をサーバマーシャリング２２Ａに返す。サーバマーシャリング２２Ａは、サーバアプリ２１Ａからの処理結果を帰り値（復帰値）として設定し（ステップＳ５７）、汎用インタフェース６０に返信を依頼する。
【００７７】
汎用インタフェース６０は、サーバマーシャリング２２Ａからの依頼に従って、ＲＰＣサーバシステム２００を介して、結果をクライアント３０に返信する（ステップＳ５８）。この処理は図１３のステップＳ４６に対応する。
【００７８】
一方、ステップＳ５４において受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しくない場合、サーバマーシャリング２２Ａは、エラー値を設定し（ステップＳ５９）、汎用インタフェース６０に返信を依頼する。この後、ステップＳ５８が実行される。
【００７９】
以上、本発明をその実施の態様に従って説明したが、本発明は、その主旨の範囲において、種々の変形が可能である。
【００８０】
例えば、以上の実施態様においては識別情報１６をＩＤＬ１１のハッシングにより生成したが、本発明は、ＪＡＶＡＲＭＩ（リモートメソッドインボケーション）のようにＩＤＬ１１を持たないプログラムにも適用できる。ＪＡＶＡＲＭＩにおいては、サーバ２０のアプリケーション（ソース又はオブジェクト）プログラム１８からインタフェース定義及びスタブプログラムが生成される。従って、ＩＤＬ１１を持たない。そこで、図１５に示すように、定義情報１１として、ＲＰＣにより通信を実行するサーバ２０上のアプリケーションプログラム１８が有するＲＰＣにおける通信のインタフェースを定義する定義部分１８１を用いる。ハッシュ値１６は定義部分１８１から生成される。スタブプログラム１５（２２、３２）は定義部分１８１に基づいて生成される。これは、前述の図１０の実施態様に類似である。
【００８１】
また、以上の実施態様は、（狭義の）ＲＰＣによりコンピュータ間通信を行う場合について説明したが、本発明は、ＲＰＣを発展させた技術であるオブジェクトリクエストブローカー（ＯＲＢ）にも適用可能である。この場合、ＩＤＬ１１に代えて、ＯＲＢにおける通信のインタフェースを定義するインタフェース定義スクリプトであるＯＤＬを定義情報１１として用いて、これをハッシングすることにより識別情報１６を生成すればよい。即ち、本発明は、ＲＰＣの変形技術の全般に広く適用することができる。従って、この明細書において、ＲＰＣとは、ＯＲＢのようなＲＰＣの応用又は利用技術（ＲＰＣを基礎とする技術）をも含むものである。
【００８２】
（付記１）  リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を備えることを特徴とするネットワークコンピュータシステム。（１）
【００８３】
（付記２）  前記識別情報が、前記定義情報から生成されたハッシュ値からなることを特徴とする付記１に記載のネットワークコンピュータシステム。
【００８４】
（付記３）  前記識別情報が、前記通信において当該データの先頭に付加されることを特徴とする付記１に記載のネットワークコンピュータシステム。
【００８５】
（付記４）  リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を備え、前記ＲＰＣ通信手段が、少なくとも前記識別情報を送信することを特徴とするクライアント。
【００８６】
（付記５）  前記定義情報が、リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムが有する前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分からなることを特徴とする付記４に記載のクライアント。
【００８７】
（付記６）  リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を備え、前記ＲＰＣ通信手段が、少なくとも受信した前記識別情報を解析することを特徴とするサーバ。（２）
【００８８】
（付記７）  前記受信した識別情報を解析し、これが自己の持つ識別情報と不一致である場合、前記受信した識別情報の送信元であるクライアントにエラー情報を返信することを特徴とする付記６に記載のサーバ。
【００８９】
（付記８）  ネットワークコンピュータシステムを実現するプログラムを格納するコンピュータ読取可能なプログラム記録媒体であって、リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記定義情報に基づいて前記リモートプロシジャコールにおける通信処理において、少なくとも前記識別情報を送信する処理を、前記ネットワークコンピュータシステムに実行させるプログラムを格納することを特徴とするプログラム記録媒体。
【００９０】
（付記９）  ネットワークコンピュータシステムを実現するプログラムを格納するコンピュータ読取可能なプログラム記録媒体であって、リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記定義情報に基づいて前記リモートプロシジャコールにおける通信処理において、少なくとも受信した前記識別情報を解析する処理を、前記ネットワークコンピュータシステムに実行させるプログラムを格納することを特徴とするプログラム記録媒体。
【００９１】
（付記１０）  リモートプロシジャコールにおける通信のインタフェースの定義情報から前記インタフェースの識別情報を生成する第１の生成手段と、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を生成し、前記ＲＰＣ通信手段に前記識別情報を付加する第２の生成手段とを備えることを特徴とするネットワークコンピュータシステム。（３）
【００９２】
（付記１１）  前記定義情報が、前記リモートプロシジャコールにおける通信のインタフェースを定義するインタフェース定義スクリプトからなることを特徴とする付記１０に記載のネットワークコンピュータシステム。
【００９３】
（付記１２）  前記定義情報が、リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムが有する前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分からなることを特徴とする付記１０に記載のネットワークコンピュータシステム。
【００９４】
（付記１３）  前記識別情報が、前記定義情報から生成されたハッシュ値からなることを特徴とする付記１０に記載のネットワークコンピュータシステム。
【００９５】
（付記１４）  ネットワークコンピュータシステムを実現するプログラムを格納するコンピュータ読取可能なプログラム記録媒体であって、リモートプロシジャコールにおける通信のインタフェースの定義情報から前記インタフェースの識別情報を生成する第１の生成処理と、前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を生成し、前記ＲＰＣ通信手段に前記識別情報を付加する第２の生成処理とを、前記ネットワークコンピュータシステムに実行させるプログラムを格納することを特徴とするプログラム記録媒体。
【００９６】
（付記１５）  リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムであって前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分を備えるプログラムの前記定義部分から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義部分に基づいて前記リモートプロシジャコールにおける通信を行う下位ＲＰＣ通信手段と、前記リモートプロシジャコールにおける通信のインタフェースの定義情報に基づいて前記リモートプロシジャコールにおける通信を行う上位ＲＰＣ通信手段とを備えることを特徴とするネットワークコンピュータシステム。（４）
【００９７】
（付記１６）  リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムであって前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分を備えるプログラムの前記定義部分から、前記インタフェースの識別情報を生成する第１の生成手段と、前記定義部分に基づいて前記リモートプロシジャコールにおける通信を行う下位ＲＰＣ通信手段を生成し、前記下位ＲＰＣ通信手段に前記識別情報を付加する第２の生成手段と、前記リモートプロシジャコールにおける通信のインタフェースの定義情報に基づいて前記リモートプロシジャコールにおける通信を行う上位ＲＰＣ通信手段を生成する第３の生成手段とを備えることを特徴とするネットワークコンピュータシステム。（５）
【００９８】
【発明の効果】
以上説明したように、本発明によれば、ネットワークコンピュータシステムにおいて、ＲＰＣのインタフェースの識別情報を当該インタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成することにより、定義情報を当該インタフェースについて一意に定めることができる。そして、識別情報を埋め込まれたスタブをインストールされたクライアント又はサーバが、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。これにより、インタフェースが変更された場合でも、インタフェースの不一致を確実に検出することができ、特に、インタフェースが不一致であるにもかかわらず、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラムを実行してしまうことを防止することができ、また、インタフェースのバージョンの管理や記述等についての開発者の負担をなくすことができ、バージョン管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【００９９】
また、本発明によれば、ネットワークコンピュータシステムにおいて、ＲＰＣのインタフェースの識別情報を当該インタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成してＲＰＣにおける通信を行う下位ＲＰＣ通信手段に埋め込む。そして、下位ＲＰＣ通信手段が、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。これにより、インタフェースのバージョンの管理や記述等についての開発者の負担なしで、事実上当該管理等を行うことができるので、当該管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【図面の簡単な説明】
【図１】ネットワークコンピュータシステム構成図である。
【図２】ＩＤＬの一例を示す図である。
【図３】サーバスタブの一例を示す図である。
【図４】スタブプログラムの生成処理フローである。
【図５】クライアントにおけるＲＰＣによる通信処理フローである。
【図６】サーバにおけるＲＰＣによる通信処理フローである。
【図７】インタフェースのバージョンの検出処理説明図である。
【図８】インタフェースのバージョンの検出処理説明図である。
【図９】ネットワークコンピュータシステム構成図である。
【図１０】ネットワークコンピュータシステム構成図である。
【図１１】インタフェース定義部の一例を示す図である。
【図１２】マーシャリングプログラムの生成処理フローである。
【図１３】クライアントにおけるＲＰＣによる通信処理フローである。
【図１４】サーバにおけるＲＰＣによる通信処理フローである。
【図１５】インタフェースのバージョンの検出処理説明図である。
【符号の説明】
１１    定義情報又はインタフェース定義スクリプト（ＩＤＬ）
１２    スタブジェネレータ
１５    スタブプログラム
１６    識別情報（ハッシュ値）
２０    サーバ
２１    サーバアプリ（アプリケーションプログラム）
２２    サーバスタブ（スタブプログラム）
３０    クライアント
３１    クライアントアプリ（アプリケーションプログラム）
３２    クライアントスタブ（スタブプログラム）
４０    ネットワーク
【図１】
0004184576.tif 000002
【図２】
0004184576.tif 000003
【図３】
0004184576.tif 000004
【図４】
0004184576.tif 000005
【図５】
0004184576.tif 000006
【図６】
0004184576.tif 000007
【図７】
0004184576.tif 000008
【図８】
0004184576.tif 000009
【図９】
0004184576.tif 000010
【図１０】
0004184576.tif 000011
【図１１】
0004184576.tif 000012
【図１２】
0004184576.tif 000013
【図１３】
0004184576.tif 000014
【図１４】
0004184576.tif 000015
【図１５】
0004184576.tif 000016