JP4184576B2

JP4184576B2 - Network computer system

Info

Publication number: JP4184576B2
Application number: JP2000198680A
Authority: JP
Inventors: 景介森永
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-06-30
Filing date: 2000-06-30
Publication date: 2008-11-19
Anticipated expiration: 2020-06-30
Also published as: JP2002014832A

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークコンピュータシステムに関し、特に、プログラム間のインタフェースの信頼性を向上したリモートプロシジャコールを利用したネットワークコンピュータシステムに関する。
【０００２】
【従来の技術】
分散処理環境を構成するネットワークコンピュータシステムでは、サーバやクライアントの上で動作する複数のプログラムが処理を相互に分散するために、リモートプロシジャコール（ＲＰＣ）を採用する場合がある。ＲＰＣにおいては、例えば、サーバ上のあるアプリケーションプログラムが、そのプロシジャの一部をクライアント上の他のアプリケーションプログラムに実行させて、その結果を通常のプロシジャコールと同様に帰り値として受け取る。
【０００３】
ＲＰＣにおいては、開発時において、そのインタフェースをインタフェース定義スクリプト（ＩＤＬ）に記述しておく。そして、ＩＤＬに基づいて、アプリケーションプログラムがＲＰＣにより通信を実行する時にこれを支援する（代わりにＲＰＣにより通信を実行する）プログラム（スタブ（ＳＴＵＢ）プログラム）を、自動生成する。スタブプログラムは、コンパイルにより、サーバ及びクライアントの各々の上のアプリケーションプログラムに組み込まれる。運用時において、サーバ及びクライアント上のアプリケーションプログラムは、各々のスタブプログラムによりＲＰＣにより通信を実行する。
【０００４】
【発明が解決しようとする課題】
種々の理由により、ＲＰＣのインタフェースが変更され、これに伴って、ＩＤＬがバージョンアップ（改版）される場合がある。本来であれば、これは、サーバ及びクライアントの双方において、同様にインタフェースに反映されているはずである。
【０００５】
しかし、ＩＤＬがバージョンアップされた場合、運用時において、インタフェースの不一致による実行不可が出力されることがある。例えば、サーバ上のアプリケーションプログラムに組み込まれたスタブプログラムが、クライアントから受信した伝送パケットを分析しインタフェースが合致するか否かを検証した結果、インタフェースが不一致となり、実行不可が出力されることがある。このような事態は、多くの場合サーバ（の管理者）が新しいスタブプログラムをコンパイルしていないこと等により生じる。この場合、処理が途中で止まってしまうことになる。また、当該検証を終了するまでは、インタフェースの不一致を検出することができない。
【０００６】
また、ＩＤＬがバージョンアップされた場合、運用時において、本来ＩＤＬが不一致であるにもかかわらず、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラムを実行してしまうことがある。即ち、実際はＩＤＬが変更されているが、データパケットとして見た場合にはインタフェースが変更とならない場合がある。これは、例えば、バージョンアップが、送信パケットのフォーマット等に関するものではなく、些細なバグ（スペルミス等）の訂正等である場合である。この場合、例えばクライアントから受信した送信パケットのフォーマット等が一致してしまうと、サーバ上のスタブプログラムを介してこれを受け取ったアプリケーションプログラムが、帰り値をクライアント上の当該アプリケーションプログラムに返してしまう。しかし、この場合、本来バージョンが不一致であるので、サーバのアプリケーションプログラムは誤った処理を実行した可能性がある。従って、また、クライアントのアプリケーションプログラムも、誤った処理に基づく誤った帰り値を用いて誤った処理を実行する可能性がある。
【０００７】
なお、以上のような誤動作等を防止するためには、ＩＤＬのバージョン（版数）を管理することが望ましい。しかし、ＩＤＬの版数を管理しようとすると、開発者が当該バージョン情報をＩＤＬ内に記述する必要がある。これは開発者にとっては煩わしいので記述を省略する場合があり、また、人手により管理することになるので開発者が記述を忘れたり内容を誤ったりする場合がある。従って、管理されていない場合や、管理されてはいても適切でない場合がある。なお、ＩＤＬのバージョン管理は義務付けられてはいない。
【０００８】
本発明は、リモートプロシジャコールのインタフェースの信頼性を向上したネットワークコンピュータシステムを提供することを目的とする。
【０００９】
また、本発明は、リモートプロシジャコールのインタフェースの変更の管理を行うことなく、確実にインタフェースの不一致を検出するネットワークコンピュータシステムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明のネットワークコンピュータシステムは、ネットワーク接続されたクライアントとサーバがＲＰＣ（リモートプロシジャコール）による通信を行う場合において、ＲＰＣにおける通信のインタフェースの定義情報から生成されたインタフェースの識別情報を含み、識別情報を用いて定義情報に基づいてＲＰＣにおける通信を行うＲＰＣ通信手段を備える。具体的には、本発明のネットワークコンピュータシステムは、ＲＰＣにおける通信のインタフェースの定義情報から、当該定義情報のハッシュ値である前記インタフェースの識別情報を生成する第１の生成手段と、前記定義情報に基づいて、ＲＰＣにより通信を実行する前記クライアント上のプログラムとなるクライアントスタブと、ＲＰＣにより通信を実行する前記サーバ上のプログラムとなるサーバスタブとを生成し、前記クライアントスタブと前記サーバスタブに前記識別情報をそれぞれ埋め込む第２の生成手段と、前記定義情報に基づいたＲＰＣによる通信の伝送パケットの送信元となる、前記クライアントスタブをインストールされた前記クライアント又は前記サーバスタブをインストールされた前記サーバが、前記伝送パケットに前記識別情報を付加して送信する手段と、前記定義情報に基づいたＲＰＣによる通信の前記伝送パケットの送信先となる、前記クライアントスタブをインストールされた前記クライアント又は前記サーバスタブをインストールされた前記サーバが、受信した前記伝送パケットから前記付加された識別情報を取り出し前記自己に埋め込まれた識別情報と比較することで、通信インタフェースの不一致を検出する手段とを備える。
【００１２】
本発明のネットワークコンピュータシステムによれば、インタフェースの識別情報が当該ＲＰＣのインタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成される。従って、当該定義情報をＲＰＣのインタフェースについて一意に定めることができる。そして、識別情報を埋め込まれたクライアントスタブとサーバスタブをインストールされたクライアント又はサーバが、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。これにより、インタフェースが変更（ＩＤＬがバージョンアップ）された場合、運用時において、インタフェースの不一致を確実に検出することができる。特に、インタフェースが不一致であるにもかかわらず、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラムを実行してしまうことを防止することができる。また、インタフェースのバージョンの管理や記述等についての開発者の負担をなくすことができ、前記バージョンの管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【００１３】
また、本発明のネットワークコンピュータシステムは、ＲＰＣにより通信を実行するサーバ上のアプリケーションプログラムのソースコードであって、前記ＲＰＣにおける通信のインタフェースを定義する定義部分を備えるプログラムソースコードの前記定義部分から生成した前記定義部分のハッシュ値である前記インタフェースの識別情報を埋め込まれており、前記定義部分に基づいて前記ＲＰＣによる通信を行う際に、送信元は伝送パケットに前記識別情報を付加して送信し、送信先は受信した前記伝送パケットから前記付加された識別情報を取り出し前記自己に埋め込まれた識別情報と比較することで、通信インタフェースの不一致を検出する下位ＲＰＣ通信手段と、前記ＲＰＣにおける通信のインタフェースの定義情報に基づいて前記ＲＰＣによる通信を行う上位ＲＰＣ通信手段とを備える。
また、本発明のネットワークコンピュータシステムは、ＲＰＣにより通信を実行するサーバ上のアプリケーションプログラムのソースコードであって、前記ＲＰＣにおける通信のインタフェースを定義する定義部分を備えるプログラムソースコードの前記定義部分のハッシュ値である前記インタフェースの識別情報を生成する第１の生成手段と、前記定義部分に基づいて前記ＲＰＣによる通信を行う下位ＲＰＣ通信手段を生成し、前記下位ＲＰＣ通信手段に前記識別情報を埋め込む第２の生成手段と、前記ＲＰＣにおける通信のインタフェースの定義情報に基づいて前記ＲＰＣによる通信を行う上位ＲＰＣ通信手段を生成する第３の生成手段とを備える。
【００１４】
本発明のネットワークコンピュータシステムによれば、インタフェースの識別情報が当該ＲＰＣのインタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成され、これがリモートプロシジャコールにおける通信を行う下位ＲＰＣ通信手段に埋め込まれる。そして、下位ＲＰＣ通信手段が、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。従って、インタフェースのバージョンの管理や記述等についての開発者の負担なしで、事実上当該管理等を行うことができ、当該管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【００１５】
【発明の実施の形態】
図１は、ネットワークコンピュータシステム構成図であり、本発明のネットワークコンピュータシステムの構成を示す。
【００１６】
ネットワークコンピュータシステムは、複数のネットワークコンピュータ２０、３０とこれらの間を接続するネットワーク４０からなる。ネットワークコンピュータ２０、３０は、例えばサーバ２０及びクライアント３０からなり、リモートプロシジャコール（ＲＰＣ）によりコンピュータ間通信を行う。サーバ２０及びクライアント３０は各々複数であってもよい。ネットワークコンピュータシステムは、サーバ２０及びクライアント３０以外に、例えば開発用のホストコンピュータ１０を備える。
【００１７】
ホストコンピュータ１０は、サーバ２０及びクライアント３０の開発のために、スタブ（ＳＴＵＢ）ジェネレータ１２、コンパイラ及びリンカ１７を備える。スタブジェネレータ１２、コンパイラ及びリンカ１７は、ホストコンピュータ１０を構成する主メモリ（図示せず）上に存在しホストコンピュータ１０を構成するＣＰＵ（図示せず）上で実行される当該プログラムにより実現される。また、ホストコンピュータ１０は、インタフェース定義スクリプト（ＩＤＬ）１１、サーバ２０上で動作するアプリケーション（ソース又はオブジェクト）プログラム（サーバアプリ）１８、クライアント３０上で動作するアプリケーション（ソース又はオブジェクト）プログラム（クライアントアプリ）１９を、磁気ディスク装置等の補助記憶（図示せず）上に備える。
【００１８】
ホストコンピュータ１０は、図１に点線で示すように、ネットワーク４０を介して、サーバ２０等と接続してもよい。この場合、後述するスタブプログラム１５等は、ネットワーク４０を介して、サーバ２０等に配信される。また、スタブジェネレータ１２、コンパイラ及びリンカ１７は、バージョンアップされたＩＤＬ（修正ＩＤＬ）１１’に基づいてスタブプログラム１５（２２、２３）を生成する必要があるため、サーバ２０及びクライアント３０の各々にも設けられる（図示せず）。この場合、修正ＩＤＬ１１’は、フレキシブルディスク等により、サーバ２０及びクライアント３０に提供される。
【００１９】
スタブジェネレータ１２はスタブプログラム（又はスタブコード）１５を生成する。スタブプログラム１５は、アプリケーションプログラムがＲＰＣにより通信を実行する時に、これを支援する。即ち、アプリケーションプログラム（２１、３１）の代わりにＲＰＣにより通信を実行するＲＰＣ通信手段１５（２２、３２）である。この生成のために、スタブジェネレータ１２は第１の生成手段１３と第２の生成手段１４とを備える。第１の生成手段１３は、ＲＰＣにおける通信のインタフェースの定義情報（ＩＤＬ）１１からインタフェースの識別情報１６を生成する。第２の生成手段１４は、定義情報１１に基づいてＲＰＣにおける通信を行うＲＰＣ通信手段１５を生成し、ＲＰＣ通信手段１５に識別情報１６を付加する。
【００２０】
この例において、定義情報１１は、インタフェース定義スクリプト（ＩＤＬ）１１からなる。ＩＤＬ１１はＲＰＣにおける通信のインタフェースを定義する。また、識別情報１６は、定義情報１１から生成されたハッシュ値（ハッシュコード）１６からなる。従って、この例では、ＩＤＬ１１からハッシングにより識別情報１６としてのハッシュ値１６が生成され、ＩＤＬ１１に基づいてスタブプログラム１５が生成される。そして、ハッシュ値１６はスタブプログラム１５に付加される（埋め込まれる）。このために、スタブジェネレータ１２はハッシュ関数を備える。ハッシュ関数としては、例えば周知のＲＳＡ−ＭＤ５：ＲＦＣ１３２１を用い、例えば１６バイトのメッセージダイジェストとされる。スタブプログラム１５としては、クライアント３０上のスタブプログラム（クライアントスタブ）３２と（なるもの）、及び、サーバ２０上のスタブプログラム（サーバスタブ）２２と（なるもの）が生成される。
【００２１】
ここで、ＩＤＬ１１の一例を図２に示す。図２において、ＩＤＬ１１は、ＲＰＣのインタフェースの種々の情報を記述する。ＩＤＬ１１は、図２に示すようなテキストファイルである。図２のＩＤＬ１１の全体がハッシングに用いられる。ハッシングの結果生成されるハッシュ値１６は、図３に示すように、１６バイトの１６進数である。
【００２２】
サーバスタブ２２の一例を図３に示す。サーバスタブ２２は、実際には、２個のハッシュ値１６（１６１、１６２）を保持する。例えば、ハッシュ値１６１は、クライアント３０から受信した伝送パケット５０に埋め込まれたハッシュ値１６と比較するためのものである。サーバスタブ２２は、受信した識別情報１６を解析し、これが自己の持つ識別情報１６１と不一致である場合、受信した識別情報１６の送信元であるクライアント３０にエラー情報を返信する。ハッシュ値１６２は、当該サーバ２０がクライアント３０に対して伝送パケット５０を送信する際に、これに埋め込むためのものである。サーバスタブ２２は、２個のエラー値２２１及び２２２をも保持する。エラー値２２１及び２２２は、ハッシュ値１６１とクライアント３０から受信した伝送パケット５０に埋め込まれたハッシュ値１６との比較結果が不一致である場合に、クライアント３０に対して返信されるエラーメッセージである。エラー値２２１及び２２２は、エラーの種類に応じて、使い分けられる。なお、クライアントスタブ３２も同様の構成を有する。
【００２３】
コンパイラ及びリンカ１７は、クライアントアプリ（のソース）１９をコンパイルしたものにクライアントスタブ１５（３２）をリンクして、クライアントアプリの実行形式のロードモジュール（クライアントＲＭ）３３を得て、これをクライアント３０にインストールする。また、コンパイラ及びリンカ１７は、サーバアプリ（のソース）１８をコンパイルしたものにサーバスタブ１５（２２）をリンクしてサーバアプリの実行形式のロードモジュール（サーバＲＭ）２３を得て、これをサーバ２０にインストールする。なお、クライアントＲＭ３３もクライアントアプリといい、サーバＲＭ２３もサーバアプリということとする。
【００２４】
ネットワークコンピュータであるサーバ２０は、複数の（実行形式の）サーバアプリ２３を備える。複数のサーバアプリ２３の各々は、サーバ２０が提供するサービス（呼び出されるプロシジャ）の各々に応じて設けられる。複数のサーバアプリ２３の各々がスタブプログラム（サーバスタブ）２２を備える。ネットワークコンピュータであるクライアント２０は、複数の（実行形式の）クライアントアプリ３３を備える。複数のクライアントアプリ３３の各々は、クライアント３０が実行する処理（アプリケーション）の各々に応じて設けられる。複数のクライアントアプリ３３の各々がスタブプログラム（クライアントスタブ）３２を備える。
【００２５】
ネットワークコンピュータであるサーバ２０及びクライアント３０は、ロードモジュールの形で、各々、ＲＰＣ通信手段であるスタブプログラム２２及び３２（１５）を備える。スタブプログラム２２及び３２は、ＲＰＣにおける通信のインタフェースの定義情報１１から生成されたインタフェースの識別情報１６を含み、定義情報１１に基づいてＲＰＣにおける通信を行う。具体的には、クライアント３０では、ＲＰＣ通信手段３２が、少なくとも識別情報１６を送信する。サーバ２０では、ＲＰＣ通信手段２２が、少なくとも受信した識別情報１６を解析する。
【００２６】
サーバ２０及びクライアント３０は、ネットワーク４０を介して、ＲＰＣに従って、コンピュータ間通信を行う。この通信において、識別情報１６が当該伝送データの先頭に（又は先頭の伝送パケットに）付加される。従って、この例では、前述のように、定義情報１１であるＩＤＬ１１から生成された識別情報１６であるハッシュ値１６が、先頭の伝送パケットに格納される。
【００２７】
クライアントスタブ３２は、少なくとも識別情報１６としてのハッシュ値１６を送信する。従って、クライアントスタブ３２として生成されたスタブプログラム１５は、ハッシュ値１６を送信する機能を備える。サーバスタブ２２は、少なくとも受信した識別情報１６としてのハッシュ値１６を解析する。従って、サーバスタブ２２として生成されたスタブプログラム１５は、ハッシュ値１６を解析する機能を備える。なお、実際は、クライアントスタブ３２も受信した識別情報１６を解析し、サーバスタブ２２も識別情報１６を送信する場合があるので、両者は同一であってよい。
【００２８】
サーバ２０及びクライアント３０は、コンピュータ間通信を行うために、各々、伝送処理部２４及び３４を備える。また、クライアント３０は、クライアントアプリ３１における処理結果等を表示する表示装置３５、クライアントアプリ３１における処理のための指示入力等のための入力装置３６を備える。
【００２９】
図４は、スタブプログラム２２、３２の生成処理フローを示す。
【００３０】
開発者が、ＩＤＬ１１を作成し（ステップＳ１）、この後、スタブジェネレータ１２を起動する（ステップＳ２）。
【００３１】
スタブジェネレータ１２が、ＩＤＬ１１を読み込み（ステップＳ３）、ＩＤＬ１１をハッシングすることにより、これからハッシュ値１６を算出する（ステップＳ４）。この後、スタブジェネレータ１２が、クライアントスタブ３２を生成する（ステップＳ５）。このクライアントスタブ３２には、識別情報１６としてハッシュ値１６が埋め込まれる。また、スタブジェネレータ１２が、サーバスタブ２２を生成する（ステップＳ６）。このサーバスタブ２２にも、識別情報１６として同一のハッシュ値１６が埋め込まれる。
【００３２】
開発者が、クライアント３０に、クライアントアプリ（ＡＰＬとも記す、以下同じ）３３をビルド（内蔵）する（ステップＳ７）。即ち、コンパイラ及びリンカ１７により、クライアントアプリ１９をコンパイルしたもの（３１）にクライアントスタブ３２をリンクしてクライアントアプリ１９のロードモジュール（クライアントＲＭ）３３を得て、これをクライアント３０にインストールする。
【００３３】
また、開発者が、サーバ２０に、サーバアプリ２３をビルド（内蔵）する（ステップＳ８）。即ち、コンパイラ及びリンカ１７により、サーバアプリ１８をコンパイルしたもの（２１）にサーバスタブ２２をリンクしてサーバアプリ１８のロードモジュール（サーバＲＭ）２３を得て、これをサーバ２０にインストールする。
【００３４】
図５は、クライアント３０におけるＲＰＣによる通信処理フローを示す。
【００３５】
（クライアントＲＭ３３の）クライアントアプリ３１が、サーバ２０の呼び出しを（クライアントＲＭ３３の）クライアントスタブ３２に依頼する（ステップＳ１１）。
【００３６】
クライアントスタブ３２が、伝送データの作成処理を行う（ステップＳ１２）。この作成処理において、クライアントスタブ３２が、自己の保持するハッシュ値１６をデータの先頭に埋め込み（ステップＳ１３）、パラメータを組み立てることにより伝送パケット５０を生成し（ステップＳ１４）、この送信を伝送処理部３４に依頼する。
【００３７】
この依頼を受けたクライアント３０の伝送処理部３４が、通信処理を行う。即ち、伝送処理部３４がサーバ２０に伝送パケット５０を送信する（ステップＳ１５）。この送信処理は図６のステップＳ２１に対応する。伝送処理部３４は、サーバ２０からの応答があると、当該処理結果を受信する（ステップＳ１６）。この受信処理は図６のステップＳ２９に対応する。この後、クライアント３０における処理は、クライアントスタブ３２を介して、クライアントアプリ３１に復帰する（ステップＳ１７）。
【００３８】
図６は、サーバ２０におけるＲＰＣによる通信処理フローを示す。
【００３９】
サーバ２０の伝送処理部２４が、クライアント３０からの伝送パケット５０を受信し（ステップＳ２１）、起動対象のサーバスタブ２２を検索して選択し（ステップＳ２２）、当該サーバスタブ２２を起動する（ステップＳ２３）。ステップＳ２１は図５のステップＳ１５に対応する。
【００４０】
起動されたサーバスタブ２２は受信した伝送データを解析する。即ち、サーバスタブ２２が、受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しいか否かを調べる（ステップＳ２４）。
【００４１】
等しい場合、サーバスタブ２２は、伝送パケット５０の後続のパラメータを解析して（ステップＳ２５）、サーバアプリ２１を起動し（ステップＳ２６）、応答を待つ。起動されたサーバアプリ２１は、解析された後続のパラメータを用いて所定の処理を行い、その処理結果をサーバスタブ２２に返す（ステップＳ２７）。サーバスタブ２２は、サーバアプリ２１からの処理結果を帰り値（復帰値）として設定し（ステップＳ２８）、伝送処理部２４に返信を依頼する。
【００４２】
伝送処理部２４は、サーバスタブ２２からの依頼に従って、結果をクライアント３０に返信する（ステップＳ２９）。この処理は図５のステップＳ１６に対応する。
【００４３】
一方、ステップＳ２４において受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しくない場合、サーバスタブ２２は、エラー値を設定し（ステップＳ３０）、伝送処理部２４に返信を依頼する。この後、ステップＳ２９が実行される。
【００４４】
図７及び図８は、ハッシュ値１６を用いたインタフェースのバージョンの検出処理説明図である。
【００４５】
図７において、ＲＰＣを採用するアプリケーションプログラム２３、３３の開発時、開発者により、インタフェース定義スクリプト（ＩＤＬ）１１が用意される。ＩＤＬ１１はＲＰＣのインタフェースを記述する。
【００４６】
スタブジェネレータ１２が、ＩＤＬ１１に基づいて、スタブプログラム１５を生成する。また、スタブジェネレータ１２は、ＩＤＬ１１からハッシングにより識別情報（ハッシュ値）１６を生成する。スタブジェネレータ１２は、生成した識別情報１６をスタブプログラム１５（サーバスタブ２２及びクライアントスタブ３２）に付加する。
【００４７】
識別情報１６はＩＤＬ１１（のバージョン）を一意に特定できるものであればよい。従って、識別情報１６はＩＤＬ１１のバージョン情報である。例えば、識別情報１６はＩＤＬ１１から生成したハッシュ値１６（ハッシュ値）からなる。即ち、ＩＤＬ１１それ自体をハッシングすることにより、識別情報１６を生成する。ハッシュ値１６が相互に衝突することは、確率的に見て事実上あり得ない。従って、このハッシュ値１６はＩＤＬ１１（のバージョン）を一意に特定できる。ＩＤＬ１１のバージョン情報をＩＤＬ１１自体のハッシングにより生成しているので、開発者がＩＤＬ１１の版数をＩＤＬ１１に記述し管理する必要がなく、従って、ＩＤＬ１１のバージョン情報を人為的に誤ることもない。
【００４８】
スタブプログラム１５は、コンパイラ及びリンカ１７の実行するコンパイル及びリンクにより、アプリケーションプログラムに組み込まれる。即ち、サーバスタブ２２及びクライアントスタブ３２が、各々、コンパイルされたサーバアプリ２１及びクライアントアプリ３１にリンクされる。これにより、サーバアプリ２１のロードモジュール（サーバＲＭ）２３及びクライアントアプリ３１のロードモジュール（クライアントＲＭ）３３が得られる。
【００４９】
ＲＰＣを採用するアプリケーションプログラム２３、３３の運用時において、サーバ２０及びクライアント３０上のアプリケーションプログラム２３、３３は、各々のスタブプログラム２２、３２（１５）によりＲＰＣにより通信を実行する。例えば、クライアントスタブ３２は、送信する伝送パケット５０を生成して、その先頭に自己に付加された識別情報１６であるハッシュ値１６を付加する。これを受信したサーバスタブ２２は、当該伝送パケット５０からハッシュ値１６を取り出して、これと自己に付加されたハッシュ値１６とを比較する。両者が一致すれば、ＩＤＬ１１（のバージョン）が一致していることになる。従って、以後の通信が正しいことが保証される。
【００５０】
図８において、図７の開発の後、ＲＰＣのインタフェースの変更により、開発者により、バージョンアップ（改版）されたＩＤＬ（修正ＩＤＬ）１１’が作成される。そこで、前述と同様に、スタブジェネレータ１２が、修正ＩＤＬ１１’に基づいてスタブプログラム１５’を生成し、修正ＩＤＬ１１’から新たなハッシュ値（新ハッシュ値）１６’を生成する。ＩＤＬ１１のバージョンアップがあれば、それが送信パケットのフォーマットの変更ではなく単なるバグの修正であっても、当該修正が必ずハッシュ値１６に反映される。即ち、バージョンアップの前後において、ハッシュ値１６と１６’とは必ず異なるものとなる。従って、この点からも、ハッシュ値１６はＩＤＬ１１（のバージョン）を一意に特定できる。
【００５１】
通常は、スタブジェネレータ１２により、クライアント３０及びサーバ２０の双方において、新ハッシュ値１６’を埋め込んだクライアントスタブ３２’及びサーバスタブ２２’として再度生成される。なお、スタブジェネレータ１２は、新ハッシュ値１６’を生成した後、ハッシュ値１６と１６’とを比較し、両者に相違がない場合、インタフェースの変更がＲＰＣ通信にかかわりのないものであると判断して、新しいクライアントスタブ３２’及びサーバスタブ２２’の生成を行わない。これにより、不必要な更新は行われることがない。
【００５２】
しかし、修正ＩＤＬ１１’に基づくスタブプログラム１５’が作成されたにもかかわらず、サーバ２０が、これをコンパイル（及びリンク）しなかったとする。クライアント３０は、前述と同様に、コンパイル（及びリンク）したとする。この場合、運用時において、例えばクライアントスタブ３２’は、その先頭に新ハッシュ値１６を付加した伝送パケット５０をサーバスタブ２２へ送信する。これを受信したサーバスタブ２２が、当該伝送パケット５０から取り出した新ハッシュ値１６’と、これと自己に付加された（旧）ハッシュ値１６とを比較する。従って、両者は一致しないので、ＩＤＬ１１（のバージョン）が不一致であるとして、サーバスタブ２２からクライアントスタブ３２’にエラーが通知される。
【００５３】
従って、先頭の伝送パケット５０を解析した時点で、ＩＤＬ１１が不一致であることを検出することができる。これにより、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラム２３、３３を実行してしまうことを防止することができる。また、以後のパケットを解析する必要がないので、処理に無駄が生じることがない。なお、以上とは逆に、クライアント３０において新しいクライアントスタブ３２’のコンパイルが行われていない場合でも同様である。また、利用者が誤って、古いサーバスタブ２２又はクライアントスタブ３２を起動してしまった場合でも同様である。更に、例えば、サーバ２０において、サーバスタブ２２（従って、ＩＤＬ１１）を勝手に変更したような場合でも同様である。
【００５４】
図９及び図１０は、ネットワークコンピュータシステム構成図であり、図１のネットワークコンピュータシステム（ＲＰＣシステム）を利用した汎用的なＲＰＣシステムの構成を示す。
【００５５】
図１のＲＰＣシステムにおいては、サーバ２０におけるアプリケーションプログラム（サブルーチン）の各々に応じて、ＩＤＬ１１及びスタブジェネレータ１２を用意する必要がある。また、既存のＲＰＣシステムにハッシュ値１６によるインタフェースの検査を導入するためには、既存のプログラムを当該処理を行うように変更する必要がある。
【００５６】
そこで、図９に示すように、図１のＲＰＣシステムを基盤としてのＲＰＣシステムとして採用する。即ち、ＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００は、各々、図１のサーバ２０及びクライアント３０に相当する。図９のサーバ２０とクライアント３０との間の通信は、全て１個のＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００に依存する。基盤としてのＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００と実際のアプリケーションプログラム２１Ａ及び３１Ａとの間の通信（従って、アプリケーションプログラム間の通信）を、１個の汎用（ユニバーサル）インタフェース６０で、統一的に通信する。汎用インタフェース６０と実際のアプリケーションプログラム２１Ａ及び３１Ａとの間には、各々、マーシャリングプログラム（又はコード）２２Ａ及び３２Ａが存在する。マーシャリングプログラム２２Ａ及び３２Ａは、通常のＲＰＣシステムにおけるスタブプログラム（図１のスタブプログラム２２及び３２）が実行する種々の処理を行う。
【００５７】
即ち、図９から判るように、図９のサーバ２０とクライアント３０は階層的な通信手段を構成する。下位ＲＰＣ通信手段であるマーシャリングプログラム２２Ａ及び３２Ａは、インタフェースの識別情報１６を含む。識別情報１６は、ＲＰＣにより通信を実行するサーバ２０上のアプリケーションプログラム２１ＡにおけるＲＰＣにおける通信のインタフェースを定義する定義部分から生成される。マーシャリングプログラム２２Ａ及び３２Ａは、識別情報１６を用いて、定義部分に基づいて、ＲＰＣにおける通信を行う。上位ＲＰＣ通信手段であるＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００（サーバスタブ２２２及びクライアントスタブ３３２）は、ＲＰＣにおける通信のインタフェースの定義情報に基づいて、ＲＰＣにおける通信を行う。
【００５８】
インタフェースの識別情報１６は、第１の生成手段であるスタブジェネレータ１２Ａにより、アプリケーションプログラム２１Ａの前記定義部分から生成される。下位ＲＰＣ通信手段であるマーシャリングプログラム２２Ａ及び３２Ａは、第２の生成手段であるスタブジェネレータ１２Ａにより、前記定義部分に基づいて生成される。上位ＲＰＣ通信手段であるサーバスタブ２２２及びクライアントスタブ３３２は、ＲＰＣにおける通信のインタフェースの定義情報（ＩＤＬ）１１に基づいて、第３の生成手段であるスタブジェネレータ１２により、前記定義情報１１に基づいて生成される。
【００５９】
即ち、図１０に示すように、ＲＰＣサーバシステム２００におけるサーバスタブ２２２は、そのＩＤＬ１１に基づいて、スタブジェネレータ１２により生成される。この時、ＩＤＬ１１からのハッシュ値（１６）の生成は行われない。従って、この例におけるサーバスタブ２２２は、識別情報１６を持たない（この点で、図１の例とは異なる）。サーバスタブ２２２とサーバアプリ２２１とで、ＲＰＣサーバシステム２００（のロードモジュール２２３）を構成する。ＲＰＣクライアントシステム３００におけるクライアントスタブ３３２についても同様である。クライアントスタブ３３２とクライアントアプリ３３１とで、ＲＰＣクライアントシステム３００（のロードモジュール３３３）を構成する。なお、図１０において、コンパイラ及びリンカ（１７）、伝送処理部（２４、３４）は、図示を省略している。
【００６０】
一方、サーバ２０上のマーシャリングプログラム（サーバマーシャリング）２２Ａは、サーバアプリ２１Ａのソースコード２１Ａ’上のインタフェース定義部に基づいて、スタブジェネレータ１２Ａにより生成される。この時、インタフェース定義部からのハッシュ値１６が生成される。従って、サーバマーシャリング２２Ａは、ハッシュ値１６からなる識別情報１６を持つ。クライアント３０上のマーシャリングプログラム（クライアントマーシャリング）３２Ａも、同様に、サーバアプリ２１Ａのソースコード２１Ａ’上のインタフェース定義部に基づいてスタブジェネレータ１２Ａにより生成され、インタフェース定義部からのハッシュ値１６が埋め込まれる。従って、クライアントマーシャリング３２Ａも、ハッシュ値１６からなる識別情報１６を持つ。
【００６１】
図１１は、サーバアプリ２１Ａのソースコード２１Ａ’上のインタフェース定義部の一例を示す図である。ソースコード２１Ａ’上のインタフェース定義部は、図１１（Ａ）に示すパラメータ部と、図１１（Ｂ）に示すリンケージ部とからなる。これらが、サーバマーシャリング２２Ａとサーバアプリ２１Ａとの間の通信に関する定義情報である。
【００６２】
図１２は、マーシャリングプログラムの生成処理フローである。
【００６３】
開発者が、サーバアプリ２１Ａのソースコード２１Ａ’を作成し（ステップＳ３１）、この後、スタブジェネレータ１２Ａを起動する（ステップＳ３２）。なお、ＲＰＣサーバシステム２００及びＲＰＣクライアントシステム３００は、図１の例と類似の処理により、既に生成されているものとする。
【００６４】
スタブジェネレータ１２Ａが、サーバアプリ２１Ａのソースコード２１Ａ’を読み込み（ステップＳ３３）、ソースコード２１Ａ’上のインタフェース定義部からハッシュ値１６を算出する（ステップＳ３４）。
【００６５】
スタブジェネレータ１２が、クライアントマーシャリング３２Ａを生成する（ステップＳ３５）。このクライアントマーシャリング３２Ａには、識別情報１６としてハッシュ値１６が埋め込まれる。
【００６６】
スタブジェネレータ１２Ａが、サーバマーシャリング２２Ａを生成する（ステップＳ３６）。このサーバマーシャリング２２Ａにも、識別情報１６として同一のハッシュ値１６が埋め込まれる。
【００６７】
クライアント３０に、クライアントアプリ３３Ａをビルド（内蔵）する（ステップＳ３７）。即ち、コンパイラ及びリンカ（１７）により、クライアントアプリをコンパイルしたもの（３１Ａ）にクライアントマーシャリング３２Ａをリンクしてクライアントアプリのロードモジュール（クライアントＲＭ）３３Ａを得て、これをクライアント３０にインストールする。
【００６８】
サーバ２０に、サーバアプリ２３Ａをビルド（内蔵）する（ステップＳ３８）。即ち、コンパイラ及びリンカ（１７）により、サーバアプリ２１Ａ’をコンパイルしたもの２１Ａにサーバマーシャリング２２Ａをリンクしてサーバアプリ２１Ａ’のロードモジュール（サーバＲＭ）２３Ａを得て、これをサーバ２０にインストールする。
【００６９】
図１３は、クライアント３０におけるＲＰＣによる通信処理フローである。
【００７０】
（クライアントＲＭ３３Ａの）クライアントアプリ３１Ａが、サーバ２０の呼び出しを（クライアントＲＭ３３Ａの）クライアントマーシャリング３２Ａに依頼する（ステップＳ４１）。
【００７１】
クライアントマーシャリング３２Ａが、伝送データの作成処理を行う（ステップＳ４２）。この処理において、クライアントマーシャリング３２Ａが、起動パラメータ５１の先頭にハッシュ値１６を埋め込み（ステップＳ４３）、パラメータを組み立てることにより起動パラメータ５１を生成し（ステップＳ４４）、これを汎用インタフェース６０に送りサーバ２０の起動を依頼する（ステップＳ４５）。
【００７２】
依頼された汎用インタフェース６０は、ＲＰＣクライアントシステム３００及びＲＰＣサーバシステム２００を介して、サーバ２０（のサーバアプリ２１Ａ）を起動する。この処理は図１４のステップＳ５１に対応する。ＲＰＣクライアントシステム３００及びＲＰＣサーバシステム２００の間の処理は、図１の例に類似である。汎用インタフェース６０は、サーバ２０からの応答があると、当該処理結果を受信する（ステップＳ４６）。この受信処理は図１４のステップＳ５８に対応する。この後、クライアント３０における処理は、クライアントマーシャリング３２Ａを介して、クライアントアプリ３１Ａに復帰する（ステップＳ４７）。
【００７３】
図１４は、サーバ２０におけるＲＰＣによる通信処理フローである。
【００７４】
サーバ２０の汎用インタフェース６０は、ＲＰＣサーバシステム２００を介して、クライアント３０からの起動要求を受信する（ステップＳ５１）。この処理は、図１３のステップＳ４５に対応する。汎用インタフェース６０は、起動対象のサーバマーシャリング２２Ａを検索して選択し（ステップＳ５２）、当該サーバマーシャリング２２Ａを起動する（ステップＳ５３）。
【００７５】
起動されたサーバマーシャリング２２Ａは受信した起動パラメータ５１を解析する。即ち、サーバマーシャリング２２Ａが、受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しい否かを調べる（ステップＳ５４）。
【００７６】
等しい場合、サーバマーシャリング２２Ａは、当該起動パラメータ５１の後続のパラメータを解析して（ステップＳ５５）、サーバアプリ２１Ａを起動し（ステップＳ５６）、応答を待つ。起動されたサーバアプリ２１Ａは、解析された後続のパラメータを用いて所定の処理を行い、その処理結果をサーバマーシャリング２２Ａに返す。サーバマーシャリング２２Ａは、サーバアプリ２１Ａからの処理結果を帰り値（復帰値）として設定し（ステップＳ５７）、汎用インタフェース６０に返信を依頼する。
【００７７】
汎用インタフェース６０は、サーバマーシャリング２２Ａからの依頼に従って、ＲＰＣサーバシステム２００を介して、結果をクライアント３０に返信する（ステップＳ５８）。この処理は図１３のステップＳ４６に対応する。
【００７８】
一方、ステップＳ５４において受信したハッシュ値１６と自己に埋め込まれているハッシュ値１６とが等しくない場合、サーバマーシャリング２２Ａは、エラー値を設定し（ステップＳ５９）、汎用インタフェース６０に返信を依頼する。この後、ステップＳ５８が実行される。
【００７９】
以上、本発明をその実施の態様に従って説明したが、本発明は、その主旨の範囲において、種々の変形が可能である。
【００８０】
例えば、以上の実施態様においては識別情報１６をＩＤＬ１１のハッシングにより生成したが、本発明は、ＪＡＶＡＲＭＩ（リモートメソッドインボケーション）のようにＩＤＬ１１を持たないプログラムにも適用できる。ＪＡＶＡＲＭＩにおいては、サーバ２０のアプリケーション（ソース又はオブジェクト）プログラム１８からインタフェース定義及びスタブプログラムが生成される。従って、ＩＤＬ１１を持たない。そこで、図１５に示すように、定義情報１１として、ＲＰＣにより通信を実行するサーバ２０上のアプリケーションプログラム１８が有するＲＰＣにおける通信のインタフェースを定義する定義部分１８１を用いる。ハッシュ値１６は定義部分１８１から生成される。スタブプログラム１５（２２、３２）は定義部分１８１に基づいて生成される。これは、前述の図１０の実施態様に類似である。
【００８１】
また、以上の実施態様は、（狭義の）ＲＰＣによりコンピュータ間通信を行う場合について説明したが、本発明は、ＲＰＣを発展させた技術であるオブジェクトリクエストブローカー（ＯＲＢ）にも適用可能である。この場合、ＩＤＬ１１に代えて、ＯＲＢにおける通信のインタフェースを定義するインタフェース定義スクリプトであるＯＤＬを定義情報１１として用いて、これをハッシングすることにより識別情報１６を生成すればよい。即ち、本発明は、ＲＰＣの変形技術の全般に広く適用することができる。従って、この明細書において、ＲＰＣとは、ＯＲＢのようなＲＰＣの応用又は利用技術（ＲＰＣを基礎とする技術）をも含むものである。
【００８２】
（付記１）リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を備えることを特徴とするネットワークコンピュータシステム。（１）
【００８３】
（付記２）前記識別情報が、前記定義情報から生成されたハッシュ値からなることを特徴とする付記１に記載のネットワークコンピュータシステム。
【００８４】
（付記３）前記識別情報が、前記通信において当該データの先頭に付加されることを特徴とする付記１に記載のネットワークコンピュータシステム。
【００８５】
（付記４）リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を備え、前記ＲＰＣ通信手段が、少なくとも前記識別情報を送信することを特徴とするクライアント。
【００８６】
（付記５）前記定義情報が、リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムが有する前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分からなることを特徴とする付記４に記載のクライアント。
【００８７】
（付記６）リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を備え、前記ＲＰＣ通信手段が、少なくとも受信した前記識別情報を解析することを特徴とするサーバ。（２）
【００８８】
（付記７）前記受信した識別情報を解析し、これが自己の持つ識別情報と不一致である場合、前記受信した識別情報の送信元であるクライアントにエラー情報を返信することを特徴とする付記６に記載のサーバ。
【００８９】
（付記８）ネットワークコンピュータシステムを実現するプログラムを格納するコンピュータ読取可能なプログラム記録媒体であって、リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記定義情報に基づいて前記リモートプロシジャコールにおける通信処理において、少なくとも前記識別情報を送信する処理を、前記ネットワークコンピュータシステムに実行させるプログラムを格納することを特徴とするプログラム記録媒体。
【００９０】
（付記９）ネットワークコンピュータシステムを実現するプログラムを格納するコンピュータ読取可能なプログラム記録媒体であって、リモートプロシジャコールにおける通信のインタフェースの定義情報から生成された前記インタフェースの識別情報を含み、前記定義情報に基づいて前記リモートプロシジャコールにおける通信処理において、少なくとも受信した前記識別情報を解析する処理を、前記ネットワークコンピュータシステムに実行させるプログラムを格納することを特徴とするプログラム記録媒体。
【００９１】
（付記１０）リモートプロシジャコールにおける通信のインタフェースの定義情報から前記インタフェースの識別情報を生成する第１の生成手段と、前記識別情報を用いて前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を生成し、前記ＲＰＣ通信手段に前記識別情報を付加する第２の生成手段とを備えることを特徴とするネットワークコンピュータシステム。（３）
【００９２】
（付記１１）前記定義情報が、前記リモートプロシジャコールにおける通信のインタフェースを定義するインタフェース定義スクリプトからなることを特徴とする付記１０に記載のネットワークコンピュータシステム。
【００９３】
（付記１２）前記定義情報が、リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムが有する前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分からなることを特徴とする付記１０に記載のネットワークコンピュータシステム。
【００９４】
（付記１３）前記識別情報が、前記定義情報から生成されたハッシュ値からなることを特徴とする付記１０に記載のネットワークコンピュータシステム。
【００９５】
（付記１４）ネットワークコンピュータシステムを実現するプログラムを格納するコンピュータ読取可能なプログラム記録媒体であって、リモートプロシジャコールにおける通信のインタフェースの定義情報から前記インタフェースの識別情報を生成する第１の生成処理と、前記定義情報に基づいて前記リモートプロシジャコールにおける通信を行うＲＰＣ通信手段を生成し、前記ＲＰＣ通信手段に前記識別情報を付加する第２の生成処理とを、前記ネットワークコンピュータシステムに実行させるプログラムを格納することを特徴とするプログラム記録媒体。
【００９６】
（付記１５）リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムであって前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分を備えるプログラムの前記定義部分から生成された前記インタフェースの識別情報を含み、前記識別情報を用いて前記定義部分に基づいて前記リモートプロシジャコールにおける通信を行う下位ＲＰＣ通信手段と、前記リモートプロシジャコールにおける通信のインタフェースの定義情報に基づいて前記リモートプロシジャコールにおける通信を行う上位ＲＰＣ通信手段とを備えることを特徴とするネットワークコンピュータシステム。（４）
【００９７】
（付記１６）リモートプロシジャコールにより通信を実行するサーバ上のアプリケーションプログラムであって前記リモートプロシジャコールにおける通信のインタフェースを定義する定義部分を備えるプログラムの前記定義部分から、前記インタフェースの識別情報を生成する第１の生成手段と、前記定義部分に基づいて前記リモートプロシジャコールにおける通信を行う下位ＲＰＣ通信手段を生成し、前記下位ＲＰＣ通信手段に前記識別情報を付加する第２の生成手段と、前記リモートプロシジャコールにおける通信のインタフェースの定義情報に基づいて前記リモートプロシジャコールにおける通信を行う上位ＲＰＣ通信手段を生成する第３の生成手段とを備えることを特徴とするネットワークコンピュータシステム。（５）
【００９８】
【発明の効果】
以上説明したように、本発明によれば、ネットワークコンピュータシステムにおいて、ＲＰＣのインタフェースの識別情報を当該インタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成することにより、定義情報を当該インタフェースについて一意に定めることができる。そして、識別情報を埋め込まれたスタブをインストールされたクライアント又はサーバが、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。これにより、インタフェースが変更された場合でも、インタフェースの不一致を確実に検出することができ、特に、インタフェースが不一致であるにもかかわらず、ＲＰＣの不適切な帰り値を用いてアプリケーションプログラムを実行してしまうことを防止することができ、また、インタフェースのバージョンの管理や記述等についての開発者の負担をなくすことができ、バージョン管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【００９９】
また、本発明によれば、ネットワークコンピュータシステムにおいて、ＲＰＣのインタフェースの識別情報を当該インタフェースの定義情報それ自体からそのハッシュ値を求めることにより生成してＲＰＣにおける通信を行う下位ＲＰＣ通信手段に埋め込む。そして、下位ＲＰＣ通信手段が、受信した伝送パケットから取り出した識別情報と埋め込まれた識別情報とを比較する。これにより、インタフェースのバージョンの管理や記述等についての開発者の負担なしで、事実上当該管理等を行うことができるので、当該管理等についての人為的な誤り等によるインタフェースの不一致等の発生を防止することができる。
【図面の簡単な説明】
【図１】ネットワークコンピュータシステム構成図である。
【図２】ＩＤＬの一例を示す図である。
【図３】サーバスタブの一例を示す図である。
【図４】スタブプログラムの生成処理フローである。
【図５】クライアントにおけるＲＰＣによる通信処理フローである。
【図６】サーバにおけるＲＰＣによる通信処理フローである。
【図７】インタフェースのバージョンの検出処理説明図である。
【図８】インタフェースのバージョンの検出処理説明図である。
【図９】ネットワークコンピュータシステム構成図である。
【図１０】ネットワークコンピュータシステム構成図である。
【図１１】インタフェース定義部の一例を示す図である。
【図１２】マーシャリングプログラムの生成処理フローである。
【図１３】クライアントにおけるＲＰＣによる通信処理フローである。
【図１４】サーバにおけるＲＰＣによる通信処理フローである。
【図１５】インタフェースのバージョンの検出処理説明図である。
【符号の説明】
１１定義情報又はインタフェース定義スクリプト（ＩＤＬ）
１２スタブジェネレータ
１５スタブプログラム
１６識別情報（ハッシュ値）
２０サーバ
２１サーバアプリ（アプリケーションプログラム）
２２サーバスタブ（スタブプログラム）
３０クライアント
３１クライアントアプリ（アプリケーションプログラム）
３２クライアントスタブ（スタブプログラム）
４０ネットワーク[0001]
BACKGROUND OF THE INVENTION
  The present invention relates to a network computer system.ToIn particular, a network computer system using a remote procedure call that improves the reliability of the interface between programs.ToRelated.
[0002]
[Prior art]
In a network computer system constituting a distributed processing environment, a remote procedure call (RPC) may be employed in order for a plurality of programs operating on a server or client to distribute processing to each other. In RPC, for example, an application program on the server causes a part of the procedure to be executed by another application program on the client, and the result is received as a return value in the same manner as a normal procedure call.
[0003]
In RPC, the interface is described in an interface definition script (IDL) at the time of development. Based on the IDL, a program (stub (STUB) program) that supports this when the application program executes communication by RPC (instead of executing communication by RPC) (STUB program) is automatically generated. The stub program is incorporated into an application program on each of the server and the client by compiling. During operation, the application program on the server and client executes communication by RPC using each stub program.
[0004]
[Problems to be solved by the invention]
For various reasons, the RPC interface is changed, and IDL may be upgraded (revised) accordingly. Originally, this should be reflected in the interface as well on both the server and client.
[0005]
However, when the IDL is upgraded, it may be output that execution is not possible due to an interface mismatch during operation. For example, a stub program embedded in an application program on a server analyzes a transmission packet received from a client and verifies whether or not the interface matches. As a result, the interface does not match and an execution impossible message may be output. . Such a situation often occurs because the server (administrator) has not compiled a new stub program. In this case, the process stops midway. Further, the interface mismatch cannot be detected until the verification is completed.
[0006]
In addition, when the IDL is upgraded, the application program may be executed using an inappropriate return value of the RPC even when the IDL originally does not match during operation. That is, the IDL is actually changed, but the interface may not be changed when viewed as a data packet. This is the case, for example, when the version upgrade is not related to the format or the like of the transmission packet but is a correction of a minor bug (such as a spelling error). In this case, for example, if the format of the transmission packet received from the client matches, the application program that has received this via the stub program on the server returns a return value to the application program on the client. However, in this case, since the versions originally do not match, the server application program may have executed an incorrect process. Therefore, the client application program may also execute an erroneous process using an incorrect return value based on the incorrect process.
[0007]
In order to prevent such malfunctions as described above, it is desirable to manage the IDL version (version number). However, in order to manage the IDL version number, the developer needs to describe the version information in the IDL. Since this is troublesome for the developer, the description may be omitted, and since it is managed manually, the developer may forget the description or mistake the content. Therefore, there is a case where it is not managed or a case where it is managed but not appropriate. Note that IDL version management is not obligatory.
[0008]
An object of the present invention is to provide a network computer system in which the reliability of a remote procedure call interface is improved.
[0009]
It is another object of the present invention to provide a network computer system that reliably detects an interface mismatch without managing the change of the interface of a remote procedure call.
[0011]
[Means for Solving the Problems]
  The network computer system of the present invention comprises:When a network-connected client and server communicate by RPC (Remote Procedure Call), RPCAnd RPC communication means for performing communication in RPC based on the definition information using the identification information.Specifically, the network computer system of the present invention includes, from the definition information of the communication interface in RPC, a first generation unit that generates identification information of the interface that is a hash value of the definition information, and the definition information And generating a client stub that is a program on the client that performs communication by RPC and a server stub that is a program on the server that performs communication by RPC, and identifying the client stub and the server stub with the identification A second generation means for embedding information, and a client installed with the client stub or the server installed with the server stub, which is a transmission source of a transmission packet of communication by RPC based on the definition information, The transmission packet Means for adding and transmitting the identification information; and the client installed with the client stub or the server installed with the server stub, which is the transmission destination of the transmission packet for communication by RPC based on the definition information Comprises means for detecting a mismatch of communication interfaces by taking out the added identification information from the received transmission packet and comparing it with the identification information embedded in the transmission packet.
[0012]
  According to the network computer system of the present invention, the interface identification information is obtained from the RPC interface definition information itself.By finding its hash valueGenerated. Therefore, the definition information can be uniquely determined for the RPC interface.Then, the client stub embedded with the identification information and the client or server installed with the server stub compare the identification information extracted from the received transmission packet with the embedded identification information.As a result, when the interface is changed (IDL is upgraded), it is possible to reliably detect an interface mismatch during operation. In particular, it is possible to prevent the application program from being executed using an inappropriate return value of the RPC even though the interfaces do not match. Further, it is possible to eliminate the burden of the developer on the management and description of the interface version, and it is possible to prevent the occurrence of an interface mismatch due to an artificial error in the management of the version.
[0013]
  Further, the network computer system of the present invention is generated from the definition part of the program source code including the definition part defining the communication interface in the RPC, which is the source code of the application program on the server that performs communication by RPC. The identification information of the interface that is the hash value of the definition part is embedded, and when performing communication by the RPC based on the definition part, the transmission source adds the identification information to the transmission packet and transmits it. The transmission destination extracts the added identification information from the received transmission packet and compares it with the identification information embedded in itself, thereby detecting a lower-order RPC communication means for detecting a communication interface mismatch, and communication in the RPC. Based on interface definition information And a upper RPC communication means for performing communication by RPC.
  The network computer system of the present invention isA source code of an application program on a server that performs communication by RPC, the RPCCommunication interfaceThe hash value of the definition part of the program source code comprising the definition part for definingFirst generating means for generating interface identification information;According to the RPC based on the definition partCommunicateSubordinateGenerate RPC communication means,SaidSubordinateRPC communication meansAboveIdentification informationEmbedSecond generation means;, Third generation means for generating upper RPC communication means for performing communication by the RPC based on definition information of the communication interface in the RPCWith.
[0014]
  According to the network computer system of the present invention, the interface identification information is obtained from the RPC interface definition information itself.By finding its hash valueGenerated and this communicates in remote procedure callsSubordinateRPC communication meansEmbedded. Then, the lower RPC communication means compares the identification information extracted from the received transmission packet with the embedded identification information.Therefore, the management of the interface version, description, etc. can be performed without any burden on the developer, and it is possible to prevent the occurrence of interface mismatch due to human error in the management, etc. be able to.
[0015]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a network computer system configuration diagram showing the configuration of the network computer system of the present invention.
[0016]
The network computer system includes a plurality of network computers 20 and 30 and a network 40 connecting them. The network computers 20 and 30 include, for example, a server 20 and a client 30 and perform communication between computers by remote procedure call (RPC). There may be a plurality of servers 20 and clients 30 each. In addition to the server 20 and the client 30, the network computer system includes, for example, a development host computer 10.
[0017]
The host computer 10 includes a stub (STUB) generator 12, a compiler and a linker 17 for developing the server 20 and the client 30. The stub generator 12, the compiler and the linker 17 are realized by a program that exists on a main memory (not shown) constituting the host computer 10 and is executed on a CPU (not shown) constituting the host computer 10. . The host computer 10 includes an interface definition script (IDL) 11, an application (source or object) program (server application) 18 that operates on the server 20, and an application (source or object) program (client application) that operates on the client 30. ) 19 is provided on an auxiliary storage (not shown) such as a magnetic disk device.
[0018]
The host computer 10 may be connected to the server 20 or the like via the network 40 as indicated by a dotted line in FIG. In this case, a stub program 15 and the like, which will be described later, are distributed to the server 20 and the like via the network 40. Further, since the stub generator 12, the compiler and the linker 17 need to generate the stub program 15 (22, 23) based on the upgraded IDL (modified IDL) 11 ′, each of the server 20 and the client 30 is provided. Is also provided (not shown). In this case, the correction IDL 11 ′ is provided to the server 20 and the client 30 by a flexible disk or the like.
[0019]
The stub generator 12 generates a stub program (or stub code) 15. The stub program 15 supports this when the application program executes communication by RPC. That is, the RPC communication means 15 (22, 32) executes communication by RPC instead of the application program (21, 31). For this generation, the stub generator 12 includes first generation means 13 and second generation means 14. The first generation unit 13 generates interface identification information 16 from the interface definition information (IDL) 11 for communication in RPC. The second generation unit 14 generates an RPC communication unit 15 that performs RPC communication based on the definition information 11, and adds identification information 16 to the RPC communication unit 15.
[0020]
In this example, the definition information 11 includes an interface definition script (IDL) 11. IDL11 defines an interface for communication in RPC. The identification information 16 includes a hash value (hash code) 16 generated from the definition information 11. Therefore, in this example, hash value 16 as identification information 16 is generated from IDL 11 by hashing, and stub program 15 is generated based on IDL 11. The hash value 16 is added (embedded) to the stub program 15. For this purpose, the stub generator 12 has a hash function. As the hash function, for example, the well-known RSA-MD5: RFC1321 is used, and for example, a 16-byte message digest is used. As the stub program 15, a stub program (client stub) 32 on the client 30 and a stub program (server stub) 22 on the server 20 and a stub program (server stub) 22 are formed.
[0021]
Here, an example of the IDL 11 is shown in FIG. In FIG. 2, IDL 11 describes various information of the interface of RPC. The IDL 11 is a text file as shown in FIG. The entire IDL 11 in FIG. 2 is used for hashing. As shown in FIG. 3, the hash value 16 generated as a result of hashing is a 16-byte hexadecimal number.
[0022]
An example of the server stub 22 is shown in FIG. The server stub 22 actually holds two hash values 16 (161, 162). For example, the hash value 161 is for comparison with the hash value 16 embedded in the transmission packet 50 received from the client 30. The server stub 22 analyzes the received identification information 16 and returns error information to the client 30 that is the transmission source of the received identification information 16 if it does not match the identification information 161 that the server stub 22 has. The hash value 162 is for embedding the hash value 162 when the server 20 transmits the transmission packet 50 to the client 30. The server stub 22 also holds two error values 221 and 222. The error values 221 and 222 are error messages returned to the client 30 when the comparison result between the hash value 161 and the hash value 16 embedded in the transmission packet 50 received from the client 30 does not match. The error values 221 and 222 are selectively used according to the type of error. The client stub 32 has a similar configuration.
[0023]
The compiler and linker 17 links the client stub 15 (32) to the compiled version of the client application (source) 19 to obtain a load module (client RM) 33 of the client application execution format. To install. Further, the compiler and linker 17 obtains a server application executable load module (server RM) 23 by linking a server stub 15 (22) to a compiled version of the server application (source) 18. 20 to install. The client RM 33 is also referred to as a client application, and the server RM 23 is also referred to as a server application.
[0024]
The server 20, which is a network computer, includes a plurality of (execution format) server applications 23. Each of the plurality of server applications 23 is provided according to each of the services (procedures to be called) provided by the server 20. Each of the plurality of server applications 23 includes a stub program (server stub) 22. The client 20, which is a network computer, includes a plurality of (execution format) client applications 33. Each of the plurality of client applications 33 is provided according to each process (application) executed by the client 30. Each of the plurality of client applications 33 includes a stub program (client stub) 32.
[0025]
The server 20 and the client 30 that are network computers include stub programs 22 and 32 (15) that are RPC communication means in the form of load modules, respectively. The stub programs 22 and 32 include interface identification information 16 generated from the RPC communication interface definition information 11, and perform RPC communication based on the definition information 11. Specifically, in the client 30, the RPC communication unit 32 transmits at least the identification information 16. In the server 20, the RPC communication means 22 analyzes at least the received identification information 16.
[0026]
The server 20 and the client 30 perform inter-computer communication via the network 40 according to RPC. In this communication, the identification information 16 is added to the head of the transmission data (or to the head transmission packet). Therefore, in this example, as described above, the hash value 16 that is the identification information 16 generated from the IDL 11 that is the definition information 11 is stored in the leading transmission packet.
[0027]
The client stub 32 transmits at least the hash value 16 as the identification information 16. Therefore, the stub program 15 generated as the client stub 32 has a function of transmitting the hash value 16. The server stub 22 analyzes at least the hash value 16 as the received identification information 16. Therefore, the stub program 15 generated as the server stub 22 has a function of analyzing the hash value 16. In practice, the client stub 32 may also analyze the received identification information 16 and the server stub 22 may transmit the identification information 16, so both may be the same.
[0028]
The server 20 and the client 30 include transmission processing units 24 and 34, respectively, for performing communication between computers. In addition, the client 30 includes a display device 35 that displays a processing result in the client application 31 and an input device 36 for inputting an instruction for processing in the client application 31.
[0029]
FIG. 4 shows a generation processing flow of the stub programs 22 and 32.
[0030]
The developer creates IDL 11 (step S1), and then activates the stub generator 12 (step S2).
[0031]
The stub generator 12 reads the IDL 11 (step S3), and hashes the IDL 11 to calculate the hash value 16 therefrom (step S4). Thereafter, the stub generator 12 generates a client stub 32 (step S5). A hash value 16 is embedded in the client stub 32 as the identification information 16. Further, the stub generator 12 generates a server stub 22 (step S6). The same hash value 16 is embedded in the server stub 22 as the identification information 16.
[0032]
The developer builds (embeds) a client application (also referred to as APL, hereinafter the same) 33 in the client 30 (step S7). In other words, the client stub 32 is linked to the compiled client application 19 (31) by the compiler and linker 17 to obtain the load module (client RM) 33 of the client application 19, and this is installed in the client 30.
[0033]
Further, the developer builds (built in) the server application 23 in the server 20 (step S8). That is, the server stub 22 is linked to the compiled server application 18 (21) by the compiler and linker 17 to obtain the load module (server RM) 23 of the server application 18, and this is installed in the server 20.
[0034]
FIG. 5 shows a communication processing flow by RPC in the client 30.
[0035]
The client application 31 (of the client RM 33) requests the client stub 32 (of the client RM 33) to call the server 20 (step S11).
[0036]
The client stub 32 performs transmission data creation processing (step S12). In this creation process, the client stub 32 embeds the hash value 16 held by the client stub 32 at the beginning of the data (step S13), generates a transmission packet 50 by assembling parameters (step S14), and transmits this transmission to the transmission processing unit. Ask 34.
[0037]
Upon receiving this request, the transmission processing unit 34 of the client 30 performs communication processing. That is, the transmission processing unit 34 transmits the transmission packet 50 to the server 20 (step S15). This transmission process corresponds to step S21 in FIG. When there is a response from the server 20, the transmission processing unit 34 receives the processing result (step S16). This reception process corresponds to step S29 in FIG. Thereafter, the processing in the client 30 returns to the client application 31 via the client stub 32 (step S17).
[0038]
FIG. 6 shows a communication processing flow by RPC in the server 20.
[0039]
The transmission processing unit 24 of the server 20 receives the transmission packet 50 from the client 30 (step S21), searches for and selects the server stub 22 to be activated (step S22), and activates the server stub 22 (step S21). S23). Step S21 corresponds to step S15 in FIG.
[0040]
The activated server stub 22 analyzes the received transmission data. That is, the server stub 22 checks whether or not the received hash value 16 is equal to the hash value 16 embedded in itself (step S24).
[0041]
If equal, the server stub 22 analyzes the subsequent parameters of the transmission packet 50 (step S25), starts the server application 21 (step S26), and waits for a response. The activated server application 21 performs a predetermined process using the analyzed subsequent parameter, and returns the processing result to the server stub 22 (step S27). The server stub 22 sets the processing result from the server application 21 as a return value (return value) (step S28), and requests the transmission processing unit 24 for a reply.
[0042]
The transmission processing unit 24 returns the result to the client 30 according to the request from the server stub 22 (step S29). This process corresponds to step S16 in FIG.
[0043]
On the other hand, if the hash value 16 received in step S24 is not equal to the hash value 16 embedded in itself, the server stub 22 sets an error value (step S30) and requests the transmission processing unit 24 to send a reply. . Thereafter, step S29 is executed.
[0044]
7 and 8 are explanatory diagrams of interface version detection processing using the hash value 16.
[0045]
In FIG. 7, an interface definition script (IDL) 11 is prepared by a developer when developing application programs 23 and 33 that employ RPC. IDL11 describes the interface of RPC.
[0046]
The stub generator 12 generates a stub program 15 based on the IDL 11. The stub generator 12 generates identification information (hash value) 16 from the IDL 11 by hashing. The stub generator 12 adds the generated identification information 16 to the stub program 15 (server stub 22 and client stub 32).
[0047]
The identification information 16 only needs to be able to uniquely identify the IDL 11 (version). Accordingly, the identification information 16 is IDL 11 version information. For example, the identification information 16 includes a hash value 16 (hash value) generated from the IDL 11. That is, the identification information 16 is generated by hashing the IDL 11 itself. It is virtually impossible for the hash values 16 to collide with each other. Therefore, the hash value 16 can uniquely identify the IDL 11 (version). Since the IDL11 version information is generated by hashing the IDL11 itself, the developer does not need to describe and manage the IDL11 version number in the IDL11. Therefore, the IDL11 version information is not artificially mistaken.
[0048]
The stub program 15 is incorporated into the application program by compiling and linking executed by the compiler and linker 17. That is, the server stub 22 and the client stub 32 are linked to the compiled server application 21 and client application 31, respectively. Thereby, the load module (server RM) 23 of the server application 21 and the load module (client RM) 33 of the client application 31 are obtained.
[0049]
When the application programs 23 and 33 adopting RPC are operated, the application programs 23 and 33 on the server 20 and the client 30 perform communication by RPC by the stub programs 22 and 32 (15). For example, the client stub 32 generates a transmission packet 50 to be transmitted, and adds a hash value 16 that is identification information 16 added to the client stub 32 to the head thereof. The server stub 22 that has received this takes out the hash value 16 from the transmission packet 50 and compares it with the hash value 16 added to itself. If they match, IDL11 (version) is matched. Therefore, it is guaranteed that the subsequent communication is correct.
[0050]
In FIG. 8, after the development of FIG. 7, IDL (modified IDL) 11 ′ that has been upgraded (revised) by the developer is created by changing the RPC interface. Therefore, as described above, the stub generator 12 generates a stub program 15 'based on the modified IDL 11', and generates a new hash value (new hash value) 16 'from the modified IDL 11'. If there is a version upgrade of IDL11, even if it is not a change in the format of the transmission packet but a simple bug correction, the correction is always reflected in the hash value 16. That is, the hash values 16 and 16 'are always different before and after the version upgrade. Therefore, also from this point, the hash value 16 can uniquely identify the IDL 11 (version).
[0051]
Normally, the stub generator 12 generates again the client stub 32 ′ and the server stub 22 ′ in which the new hash value 16 ′ is embedded in both the client 30 and the server 20. The stub generator 12 compares the hash values 16 and 16 ′ after generating the new hash value 16 ′, and if there is no difference between the two, it is determined that the interface change is not related to the RPC communication. Thus, the new client stub 32 ′ and the server stub 22 ′ are not generated. As a result, unnecessary updates are not performed.
[0052]
However, even though the stub program 15 ′ based on the modified IDL 11 ′ is created, the server 20 does not compile (and link) it. Assume that the client 30 is compiled (and linked) as described above. In this case, at the time of operation, for example, the client stub 32 ′ transmits the transmission packet 50 with the new hash value 16 added to the head to the server stub 22. The server stub 22 that has received this compares the new hash value 16 ′ extracted from the transmission packet 50 with the (old) hash value 16 added to itself. Accordingly, since the two do not match, the server stub 22 notifies the client stub 32 'of an error that the IDL 11 (version) does not match.
[0053]
Therefore, when the leading transmission packet 50 is analyzed, it can be detected that the IDLs 11 do not match. Thus, it is possible to prevent the application programs 23 and 33 from being executed using an inappropriate return value of RPC. Further, since there is no need to analyze subsequent packets, processing is not wasted. In contrast, the same applies to the case where the client 30 does not compile a new client stub 32 '. The same applies when the user accidentally activates the old server stub 22 or the client stub 32. Further, for example, the same applies to the case where the server 20 changes the server stub 22 (accordingly, the IDL 11).
[0054]
9 and 10 are configuration diagrams of a network computer system, showing a configuration of a general-purpose RPC system using the network computer system (RPC system) of FIG.
[0055]
In the RPC system of FIG. 1, it is necessary to prepare an IDL 11 and a stub generator 12 according to each application program (subroutine) in the server 20. In addition, in order to introduce the inspection of the interface with the hash value 16 into the existing RPC system, it is necessary to change the existing program so as to perform the processing.
[0056]
Therefore, as shown in FIG. 9, the RPC system shown in FIG. 1 is adopted as an RPC system. That is, the RPC server system 200 and the RPC client system 300 correspond to the server 20 and the client 30 in FIG. 1, respectively. All communication between the server 20 and the client 30 in FIG. 9 depends on one RPC server system 200 and RPC client system 300. Communication between the RPC server system 200 and the RPC client system 300 as the base and the actual application programs 21A and 31A (accordingly, communication between the application programs) is unified by a single universal interface 60. connect. Between the general-purpose interface 60 and the actual application programs 21A and 31A, marshalling programs (or codes) 22A and 32A exist, respectively. The marshalling programs 22A and 32A perform various processes executed by the stub program in the normal RPC system (stub programs 22 and 32 in FIG. 1).
[0057]
That is, as can be seen from FIG. 9, the server 20 and the client 30 in FIG. 9 constitute a hierarchical communication means. The marshalling programs 22 </ b> A and 32 </ b> A, which are lower RPC communication means, include interface identification information 16. The identification information 16 is generated from a definition part that defines an RPC communication interface in the application program 21A on the server 20 that performs communication by RPC. The marshalling programs 22A and 32A use the identification information 16 to perform communication in RPC based on the definition part. The RPC server system 200 and the RPC client system 300 (server stub 222 and client stub 332), which are upper RPC communication means, perform RPC communication based on the definition information of the RPC communication interface.
[0058]
The interface identification information 16 is generated from the definition part of the application program 21A by the stub generator 12A as the first generation means. The marshalling programs 22A and 32A as the lower RPC communication means are generated based on the definition part by the stub generator 12A as the second generation means. Based on the definition information 11, the server stub 222 and the client stub 332, which are the upper RPC communication means, are based on the definition information (IDL) 11 of the communication interface in RPC by the stub generator 12 that is the third generation means. Generated.
[0059]
That is, as shown in FIG. 10, the server stub 222 in the RPC server system 200 is generated by the stub generator 12 based on the IDL 11. At this time, the generation of the hash value (16) from the IDL 11 is not performed. Therefore, the server stub 222 in this example does not have the identification information 16 (this is different from the example of FIG. 1). The server stub 222 and the server application 221 constitute an RPC server system 200 (the load module 223). The same applies to the client stub 332 in the RPC client system 300. The client stub 332 and the client application 331 constitute an RPC client system 300 (load module 333 thereof). In FIG. 10, the compiler, linker (17), and transmission processing units (24, 34) are not shown.
[0060]
On the other hand, the marshalling program (server marshalling) 22A on the server 20 is generated by the stub generator 12A based on the interface definition part on the source code 21A 'of the server application 21A. At this time, the hash value 16 from the interface definition unit is generated. Accordingly, the server marshalling 22A has the identification information 16 including the hash value 16. Similarly, the marshalling program (client marshalling) 32A on the client 30 is generated by the stub generator 12A based on the interface definition part on the source code 21A ′ of the server application 21A, and the hash value 16 from the interface definition part is embedded. . Accordingly, the client marshalling 32A also has the identification information 16 consisting of the hash value 16.
[0061]
FIG. 11 is a diagram illustrating an example of an interface definition unit on the source code 21A ′ of the server application 21A. The interface definition section on the source code 21A 'includes a parameter section shown in FIG. 11A and a linkage section shown in FIG. These are definition information regarding communication between the server marshalling 22A and the server application 21A.
[0062]
FIG. 12 is a process flow of generating a marshalling program.
[0063]
The developer creates the source code 21A 'of the server application 21A (step S31), and then activates the stub generator 12A (step S32). It is assumed that the RPC server system 200 and the RPC client system 300 have already been generated by processing similar to the example of FIG.
[0064]
The stub generator 12A reads the source code 21A 'of the server application 21A (step S33), and calculates the hash value 16 from the interface definition section on the source code 21A' (step S34).
[0065]
The stub generator 12 generates client marshalling 32A (step S35). A hash value 16 is embedded as identification information 16 in the client marshalling 32A.
[0066]
The stub generator 12A generates server marshalling 22A (step S36). Also in this server marshalling 22A, the same hash value 16 is embedded as the identification information 16.
[0067]
The client application 33A is built (built in) in the client 30 (step S37). That is, the client marshalling 32A is linked to the compiled client application (31A) by the compiler and linker (17) to obtain the client application load module (client RM) 33A, which is installed in the client 30.
[0068]
The server application 23A is built (built in) in the server 20 (step S38). That is, the server marshalling 22A is linked to the server application 21A ′ compiled by the compiler and linker (17) 21A to obtain the load module (server RM) 23A of the server application 21A ′, which is installed in the server 20. .
[0069]
FIG. 13 is a communication processing flow by RPC in the client 30.
[0070]
The client application 31A (of the client RM 33A) requests the client marshalling 32A (of the client RM 33A) to call the server 20 (step S41).
[0071]
The client marshalling 32A performs transmission data creation processing (step S42). In this process, the client marshalling 32A embeds the hash value 16 at the head of the activation parameter 51 (step S43), generates the activation parameter 51 by assembling the parameter (step S44), sends this to the general-purpose interface 60, and sends it to the server 20 Is requested (step S45).
[0072]
The requested general-purpose interface 60 activates the server 20 (the server application 21A) via the RPC client system 300 and the RPC server system 200. This process corresponds to step S51 in FIG. The processing between the RPC client system 300 and the RPC server system 200 is similar to the example of FIG. If there is a response from the server 20, the general-purpose interface 60 receives the processing result (step S46). This reception process corresponds to step S58 in FIG. Thereafter, the processing in the client 30 returns to the client application 31A via the client marshalling 32A (step S47).
[0073]
FIG. 14 is a communication processing flow by RPC in the server 20.
[0074]
The general-purpose interface 60 of the server 20 receives an activation request from the client 30 via the RPC server system 200 (step S51). This process corresponds to step S45 in FIG. The general-purpose interface 60 searches and selects the server marshalling 22A to be activated (step S52), and activates the server marshalling 22A (step S53).
[0075]
The activated server marshalling 22A analyzes the received activation parameter 51. That is, the server marshalling 22A checks whether or not the received hash value 16 is equal to the hash value 16 embedded in itself (step S54).
[0076]
If equal, the server marshalling 22A analyzes the subsequent parameter of the activation parameter 51 (step S55), activates the server application 21A (step S56), and waits for a response. The activated server application 21A performs a predetermined process using the analyzed subsequent parameter, and returns the processing result to the server marshalling 22A. The server marshalling 22A sets the processing result from the server application 21A as a return value (return value) (step S57), and requests a return from the general-purpose interface 60.
[0077]
The general-purpose interface 60 returns the result to the client 30 via the RPC server system 200 according to the request from the server marshalling 22A (step S58). This process corresponds to step S46 in FIG.
[0078]
On the other hand, if the hash value 16 received in step S54 is not equal to the hash value 16 embedded in itself, the server marshalling 22A sets an error value (step S59) and requests the general-purpose interface 60 to send a reply. Thereafter, step S58 is executed.
[0079]
As mentioned above, although this invention was demonstrated according to the embodiment, this invention can be variously deformed in the range of the main point.
[0080]
For example, although the identification information 16 is generated by hashing the IDL 11 in the above embodiment, the present invention can also be applied to a program that does not have the IDL 11 such as JAVAMI (Remote Method Invocation). In JAVAMI, an interface definition and a stub program are generated from an application (source or object) program 18 of the server 20. Therefore, it does not have IDL11. Therefore, as shown in FIG. 15, as the definition information 11, a definition portion 181 that defines an RPC communication interface included in the application program 18 on the server 20 that performs communication by RPC is used. The hash value 16 is generated from the definition part 181. The stub program 15 (22, 32) is generated based on the definition part 181. This is similar to the embodiment of FIG. 10 described above.
[0081]
Moreover, although the above embodiment demonstrated the case where communication between computers was performed by RPC (in a narrow sense), this invention is applicable also to the object request broker (ORB) which is the technique which developed RPC. In this case, instead of the IDL 11, the identification information 16 may be generated by hashing the ODL, which is an interface definition script that defines the communication interface in the ORB, as the definition information 11. That is, the present invention can be widely applied to all RPC deformation techniques. Therefore, in this specification, RPC includes RPC application or utilization technology (technology based on RPC) such as ORB.
[0082]
(Supplementary note 1) RPC communication means including communication interface definition information generated from communication interface definition information in a remote procedure call, and performing communication in the remote procedure call based on the definition information using the identification information A network computer system comprising: (1)
[0083]
(Supplementary note 2) The network computer system according to supplementary note 1, wherein the identification information includes a hash value generated from the definition information.
[0084]
(Supplementary note 3) The network computer system according to supplementary note 1, wherein the identification information is added to a head of the data in the communication.
[0085]
(Supplementary Note 4) RPC communication means including communication interface definition information generated from communication interface definition information in a remote procedure call and performing communication in the remote procedure call based on the definition information using the identification information And the RPC communication means transmits at least the identification information.
[0086]
(Supplementary Note 5) The client according to Supplementary Note 4, wherein the definition information includes a definition part that defines a communication interface in the remote procedure call included in an application program on a server that performs communication by remote procedure call. .
[0087]
(Supplementary note 6) RPC communication means including identification information of the interface generated from communication interface definition information in a remote procedure call and performing communication in the remote procedure call based on the definition information using the identification information And the RPC communication means analyzes at least the received identification information. (2)
[0088]
(Supplementary note 7) The supplementary note 6 is characterized in that the received identification information is analyzed, and if it does not match the identification information held by itself, error information is returned to the client that is the transmission source of the received identification information. The listed server.
[0089]
(Supplementary Note 8) A computer-readable program recording medium for storing a program for realizing a network computer system, including identification information of the interface generated from communication interface definition information in a remote procedure call, the definition information A program recording medium for storing a program for causing the network computer system to execute at least the process of transmitting the identification information in the communication process in the remote procedure call based on the program.
[0090]
(Supplementary Note 9) A computer-readable program recording medium for storing a program for realizing a network computer system, including identification information of the interface generated from communication interface definition information in a remote procedure call, the definition information A program recording medium storing a program for causing the network computer system to execute at least a process of analyzing the received identification information in a communication process in the remote procedure call based on the program.
[0091]
(Additional remark 10) The 1st production | generation means which produces | generates the identification information of the said interface from the definition information of the interface of communication in a remote procedure call, and communicates in the said remote procedure call based on the said definition information using the said identification information A network computer system comprising: RPC communication means; and second generation means for adding the identification information to the RPC communication means. (3)
[0092]
(Supplementary note 11) The network computer system according to supplementary note 10, wherein the definition information includes an interface definition script that defines a communication interface in the remote procedure call.
[0093]
(Supplementary note 12) The network according to supplementary note 10, wherein the definition information includes a definition part that defines an interface of communication in the remote procedure call included in an application program on a server that performs communication by remote procedure call. Computer system.
[0094]
(Supplementary note 13) The network computer system according to supplementary note 10, wherein the identification information includes a hash value generated from the definition information.
[0095]
(Supplementary Note 14) A computer-readable program recording medium for storing a program for realizing a network computer system, the first generation processing for generating identification information of the interface from communication interface definition information in a remote procedure call A program for generating RPC communication means for performing communication in the remote procedure call based on the definition information and causing the network computer system to execute a second generation process for adding the identification information to the RPC communication means. A program recording medium for storing the program.
[0096]
(Supplementary Note 15) Identification information of the interface generated from the definition part of an application program on a server that executes communication by a remote procedure call, the definition part defining a communication interface in the remote procedure call And lower RPC communication means for performing communication in the remote procedure call based on the definition part using the identification information, and performing communication in the remote procedure call based on definition information of a communication interface in the remote procedure call A network computer system comprising higher-order RPC communication means. (4)
[0097]
(Supplementary Note 16) The interface identification information is generated from the definition part of the application program on the server that executes communication by remote procedure call, the definition part defining a communication interface in the remote procedure call. A first generation means, a lower generation RPC communication means for performing communication in the remote procedure call based on the definition part, a second generation means for adding the identification information to the lower RPC communication means, the remote A network computer system comprising: third generation means for generating higher-order RPC communication means for performing communication in the remote procedure call based on definition information of a communication interface in the procedure call. (5)
[0098]
【The invention's effect】
  As described above, according to the present invention, in the network computer system, RPC interface identification information is obtained from the interface definition information itself.By finding its hash valueBy generating, definition information can be uniquely determined for the interface.. Then, the client or server installed with the stub in which the identification information is embedded compares the identification information extracted from the received transmission packet with the embedded identification information. ThisEven when the interface is changed, it is possible to reliably detect the interface mismatch, and in particular, the application program is executed using an inappropriate return value of the RPC even though the interface is mismatched. In addition, it is possible to eliminate the burden of the developer on interface version management and description, etc., and to prevent the occurrence of interface mismatches due to human error in version management etc. Can do.
[0099]
  Further, according to the present invention, in the network computer system, the RPC interface identification information is obtained from the interface definition information itself.By finding its hash valueGenerate and communicate in RPCSubordinateRPC communication meansEmbed. Then, the lower RPC communication means compares the identification information extracted from the received transmission packet with the embedded identification information. thisThis makes it possible to effectively manage the interface version without any burden on the developer, such as management and description of the interface, thus preventing the occurrence of interface mismatches due to human error in the management. can do.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a network computer system.
FIG. 2 is a diagram illustrating an example of IDL.
FIG. 3 is a diagram illustrating an example of a server stub.
FIG. 4 is a process flow of generating a stub program.
FIG. 5 is a communication processing flow by RPC in a client.
FIG. 6 is a communication processing flow by RPC in a server.
FIG. 7 is an explanatory diagram of interface version detection processing;
FIG. 8 is an explanatory diagram of interface version detection processing;
FIG. 9 is a configuration diagram of a network computer system.
FIG. 10 is a configuration diagram of a network computer system.
FIG. 11 is a diagram illustrating an example of an interface definition unit.
FIG. 12 is a generation process flow of a marshalling program.
FIG. 13 is a communication processing flow by RPC in a client.
FIG. 14 is a communication processing flow by RPC in a server.
FIG. 15 is an explanatory diagram of interface version detection processing;
[Explanation of symbols]
11 Definition information or interface definition script (IDL)
12 Stub generator
15 Stub program
16 Identification information (hash value)
20 servers
21 Server application (application program)
22 Server bathtub (stub program)
30 clients
31 Client application (application program)
32 Client stub (stub program)
40 network

Claims

A network computer system in which a client and a server connected to a network perform communication by RPC ( Remote Procedure Call ),
First generation means for generating identification information of the interface, which is a hash value of the definition information, from the definition information of the communication interface in the RPC ;
On the basis of the definition information, and generates the client stubs that the program on the client to perform communication by RPC, and said server stub as a program on the server that executes communication by RPC, the said client stub server Second generation means for embedding the identification information in each stub;
The client installed with the client stub or the server installed with the server stub, which is the transmission packet transmission source of communication by RPC based on the definition information, adds the identification information to the transmission packet. Means for transmitting;
The client in which the client stub is installed or the server in which the server stub is installed, which is the transmission destination of the transmission packet for communication by RPC based on the definition information, is added from the received transmission packet. A network computer system comprising: means for detecting a mismatch of communication interfaces by taking out identification information and comparing it with identification information embedded in the self .

A source code of an application program on the server that executes communication by RPC, a hash value of said defined portion generated from the definition part of the program source code including a definition part for defining a communication interface in the RPC said Interface identification information is embedded, and when performing communication by the RPC based on the definition part , the transmission source adds the identification information to the transmission packet and transmits the transmission packet, and the transmission destination is from the received transmission packet. Subordinate RPC communication means for detecting a mismatch of communication interfaces by taking out the added identification information and comparing it with identification information embedded in the self ;
Network computer system, characterized in that it comprises an upper RPC communication means for communicating with said RPC based on the definition information of the communication interface in the RPC.

A source code of an application program on the server that executes communication by RPC, generates identification information of said interface is a hash value of said defined portion of the program source code including a definition part for defining a communication interface in the RPC First generating means to:
A second generation unit that generates a lower RPC communication unit that performs communication by the RPC based on the definition part, and embeds the identification information in the lower RPC communication unit;
Network computer system, characterized in that it comprises a third generation means for generating a higher RPC communication means for communicating with said RPC based on the definition information of the communication interface in the RPC.