JPH11249919A

JPH11249919A - 手続き呼出しの処理方法およびスタブ生成方法

Info

Publication number: JPH11249919A
Application number: JP10053643A
Authority: JP
Inventors: Haruyuki Otani; 治之大谷
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1998-03-05
Filing date: 1998-03-05
Publication date: 1999-09-17

Abstract

(57)【要約】【課題】本発明は、マルチスレッド等による並列処理
が可能なクライアントとサーバ間で実行される遠隔手続
き呼出しを効率的に処理できるようにすることを目的と
する。【解決手段】現在処理中の手続きの他に新たな手続き
がクライアントからサーバに対して呼出されたとき、現
在処理中の手続きの処理時間に関する情報に基づいて、
新たな手続きの呼出しに用いられる仮想通信回線が獲得
される。この結果、現在処理中の手続きの処理時間に応
じて適切な仮想通信回線を獲得することができる。ま
た、サーバに対して今回実行要求のあった手続きを実行
するスレッドが、今回実行要求のあった手続きの処理時
間の情報に基づいて獲得される。この結果、実行要求の
あった手続きの処理時間特性に適したスレッドを獲得す
ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチスレッド等
による並列処理が可能なクライアントサーバシステムで
用いられる手続き呼出し方法、並びに、該手続き呼出し
を可能にするクライアントスタブおよびサーバスタブを
生成するスタブ生成方法に関する。本発明において「手
続き呼出し」は、いわゆる「遠隔手続き呼出し」を意味
するもである。

【０００２】

【従来の技術】一般的に、遠隔手続き呼出しは、ＲＰＣ
（ＲｅｍｏｔｅＰｒｏｃｅｄｕｒｅＣａｌｌ）とも呼
ばれており、呼出す手続きと呼出される手続きとがそれ
ぞれ別個のプロセスで処理されることを意味するもので
ある。より具体的には、この遠隔手続き呼出しによっ
て、例えば二つのコンピュータのうちの一方が他方に対
してコンピュータ処理を依頼し、依頼された他方のコン
ピュータがその処理を実行して、実行結果を一方の依頼
元のコンピュータに返すことが可能になる。

【０００３】このような従来のＲＰＣに関する技術は、
例えばＯＳＦ（ＯｐｅｎＳｏｆｔｗａｒｅＦｏｕｎ
ｄａｔｉｏｎ）により頒布された「ＤＣＥＩｎｔｅｒ
ｎａｌｓＣｏｕｒｓｅＳｔｕｄｅｎｔＧｕｉｄｅ
Ｖｏｌｕｍｅ１」，ＤＣＥＲｅｌｅａｓｅ１．
０ｃｏｕｒｓｅ，ＶｅｒｓｉｏｎｏｆＪｕｎｅ１
３，１９９２の３−８０から３―１３１までの頁および
同じＯＳＦにより頒布された「ＯＳＦＤＣＥＡｐｐｌ
ｉｃａｔｉｏｎＤｅｖｅｌｏｐｍｅｎｔＧｕｉｄｅ−
ＣｏｒｅＣｏｍｐｏｎｅｎｔｓ」の１−３、１４−
４、１４−５の頁に開示されており、これら文献に開示
された技術内容を図１１および図１２を使って下記に説
明する。なお、ＤＣＥは、ＯＳＦにより開発された分散
コンピューティング環境（ＤｉｓｔｒｉｂｕｔｅｄＣ
ｏｍｐｕｔｉｎｇＥｎｖｉｒｏｍｅｎｔ）を指す。

【０００４】図１１は、ＲＰＣを実施する際に必要な各
機能要素間の関係を示すブロック図である。同図におい
て、１１０１は、インタフェース定義言語（Ｉｎｔｅｒ
ｆａｃｅＤｅｆｉｎｉｔｉｏｎＬａｎｇｕａｇｅ）
で記述されたインタフェース定義言語仕様ファイルであ
る。以下の説明において、インタフェース定義言語をＩ
ＤＬ、インタフェース定義言語仕様ファイルをＩＤＬ仕
様ファイルとも呼ぶ。

【０００５】このＩＤＬ仕様ファイル１１０１によっ
て、クライアントマルチスレッドアプリケーション１１
０３とサーバマルチスレッドアプリケーション１１０４
とをネットワーク１２０１を介して異なるコンピュータ
上で動作させることが可能になる。本従来例では、倍長
型（long型）の成分からなる２つのベクトルを、クライ
アントマルチスレッドアプリケーション１１０３がサー
バマルチスレッドアプリケーション１１０４に対して送
ると、サーバマルチスレッドアプリケーション１１０４
がその２つのベクトルの和を計算し、クライアントマル
チスレッドアプリケーション１１０３に対して計算結果
を返すといった比較的簡単な処理が実行される。

【０００６】クライアントマルチスレッドアプリケーシ
ョン１１０３が動作するクライアント側のコンピュータ
上にはオペレーティングシステムによってＴＣＰ／ＩＰ
通信処理装置１１０５、サーバマルチスレッドアプリケ
ーション１１０４が動作するサーバ側のコンピュータ上
にはＴＣＰ／ＩＰ通信処理装置１１０６がそれぞれが提
供されている。クライアントマルチスレッドアプリケー
ション１１０３とサーバマルチスレッドアプリケーショ
ン１１０４はこれら通信処理装置１１０５、１１０６を
それぞれ使ってデータを送受信する。

【０００７】図１１に示すアプリケーションを開発する
場合、ＯＳＦのＤＣＥにおけるＲＰＣでは、まずアプ
リケーション開発者は、ＲＰＣのインタフェースをＩＤ
Ｌで記述したＩＤＬ仕様ファイル１１０１を作成する必
要がある。ＩＤＬ仕様ファイル１１０１はＩＤＬコンパ
イラ１１０２に入力されコンパイル（翻訳）され、この
結果、クライアントスタブ１１０７とサーバスタブ１１
０８が生成される。

【０００８】ＤＣＥにおけるＲＰＣでは、クライアント
スタブ１１０７とサーバスタブ１１０８はＣ言語のコー
ドとして生成される。したがって、クライアントマルチ
スレッドアプリケーション１１０３とクライアントスタ
ブ１１０７とをコンパイルし、クライアント側のランタ
イムライブラリ１１０９とリンケージすることによっ
て、クライアントマルチスレッドアプリケーション１１
０３は、はじめて実行可能なモジュールとなる。サーバ
マルチスレッドアプリケーション１１０４も同様に、サ
ーバスタブ１１０８とともにコンパイルしてサーバ側の
ランタイムライブラリ１１１０とリンケージさせること
により、はじめて実行可能なモジュールとなる。

【０００９】上述のようなコンパイルとリンケージによ
り、クライアント側には、メッセージ作成装置１１１
１、コール管理装置１１１３およびアソシエーショング
ループ管理装置１１１５が提供される。一方、サーバ側
には、メッセージ作成装置１１１２、コール管理装置１
１１４、アソシエーショングループ管理装置１１１６お
よびスレッドプール管理装置１１１７が提供される。ク
ライアント側のメッセージ作成装置１１１１とコール管
理装置１１１３はクライアントスタブ１１０７とランタ
イムライブラリ１１０９にまたがるように設けられてい
る。また、サーバ側のメッセージ作成装置１１１２とコ
ール管理装置１１１４もサーバスタブ１１０８とランタ
イムライブラリ１１１０にまたがるように設けられてい
る。

【００１０】クライアント側のメッセージ作成装置１１
１１は、クライアントマルチスレッドアプリケーション
１１０３のスレッドから受け取ったデータをネットワー
ク１２０１を介した通信に適切な形式であるメッセージ
に変換し、また、その逆にネットワーク１２０１を介し
て受け取ったメッセージをクライアントマルチスレッド
アプリケーション１１０３のスレッドに対する適切なデ
ータに変換するものである。

【００１１】同様に、サーバ側のメッセージ作成装置１
１１２は、サーバマルチスレッドアプリケーション１１
０４のスレッドから受け取ったデータをネットワーク１
２０１を介した通信に適切な形式であるメッセージに変
換し、また、その逆にネットワーク１２０１を介して受
け取ったメッセージをサーバマルチスレッドアプリケー
ション１１０４のスレッドに対する適切なデータに変換
するものである。

【００１２】クライアント側のコール管理装置１１１３
は、アソシエーショングループ管理装置１１１５が提供
するＴＣＰ／ＩＰコネクションを獲得して、該ＴＣＰ／
ＩＰコネクション上でサーバ側へＲＰＣの要求を送り、
ＲＰＣの結果を受け取る。サーバ側のコール管理装置１
１１４も同様に、ＴＣＰ／ＩＰコネクションからＲＰＣ
の要求を受け取り、ＴＣＰ／ＩＰコネクション上にＲＰ
Ｃの結果を送出する。

【００１３】クライアントおよびサーバ側のそれぞれに
設けられたアソシエーショングループ管理装置１１１５
および１１１６は、クライアントとサーバ間で確立され
る複数のＴＣＰ／ＩＰコネクションを管理する。

【００１４】スレッドプール管理装置１１１７は、サー
バ側のランタイムライブラリ１１１０内だけに設けられ
ており、サーバマルチスレッドアプリケーション１１０
４の起動時に、ランタイムライブラリ１１１０内に予め
作成された複数のスレッドを管理している。これら複数
のスレッドによりスレッドプール１１１８が構成されて
おり、各スレッドは図１１におけるスレッドプール１１
１８内の矢印で表わされている。クライアントからサー
バにＲＰＣ要求が到着すると空いているスレッドがその
処理を担当する。スレッドは仮想的な処理プロセッサ
（ＣＰＵ）の実行体であり、アプリケーションはこの実
行体により動作する。

【００１５】次に、図１１を各装置間の関係をより詳細
に示した図１２を使って、従来のＲＰＣの動作を具体的
に説明する。クライアントマルチスレッドアプリケーシ
ョン１１０３は、現在２つのスレッドＴＨ５１とＴＨ５
２によって実行されている。この例では、スレッドＴＨ
５１もスレッドＴＨ５２も同じ引数値によって、サーバ
マルチスレッドアプリケーション１１０４で実行される
「sum array」手続きを呼出すものであるが、まず、ス
レッドＴＨ５１のみがこの「sum array」手続きを呼出
す場合について説明する。次に２つのスレッドＴＨ５
１、ＴＨ５２が同時に手続きを呼出した場合について説
明する。

【００１６】スレッド１３０１が「sum array」手続き
を呼出したときに与えられた引数ａ、ｂのベクトルデー
タ（配列データ）の値はクライアントスタブ１１０７に
渡される。クライアントスタブ１１０７は、メッセージ
作成装置１１１１によりこれら引数値等を適切な形式に
変換し配列して、ＲＰＣの要求メッセージを作成する。

【００１７】次に、コール管理装置１１１３は、作成さ
れた要求メッセージを獲得して、アソシエーショングル
ープ管理装置１１１５により提供されるＴＣＰ／ＩＰコ
ネクションを使用して要求メッセージをサーバ側に送信
する。図１２は、クライアント側のアソシエーショング
ループ管理装置１１１５とサーバ側のアソシエーション
管理装置１１１６が既にＴＣＰ／ＩＰコネクション１２
０１ａを確立している状態を示しており、このＴＣＰ／
ＩＰコネクション１２０１ａがアソシエーションとして
用いられる。

【００１８】サーバ側ではコール管理装置１１１４が、
アソシエーショングループ管理装置１１１６により提供
されるアソシエーションから要求メッセージを受信す
る。また、スレッドプール管理装置１１１７によりスレ
ッドプール１１１８から使用中でない空きスレッドを獲
得し、要求メッセージの処理スレッドＴＨ５３として割
り当てる。処理スレッドＴＨ５３はメッセージ作成装置
１１１２を利用して引数ａ、ｂに与えられたデータ値を
受信要求メッセージから取り出し、サーバマルチスレッ
ドアプリケーション１１０４の「sum array」手続きを
実行する。最後に、「sum array」手続きは処理結果を
表す引数cにベクトル値の和を代入する。

【００１９】ここまでが、クライアントマルチスレッド
アプリケーション１１０３の要求がサーバマルチスレッ
ドアプリケーション１１０４に送られ、その要求が実行
されるまでの過程である。手続きの実行結果をクライア
ントマルチスレッドアプリケーション１１０３に返す過
程はこの逆の過程を辿るので、ここでは説明を省略す
る。

【００２０】次にクライアントマルチスレッドアプリケ
ーション１１０３内のスレッドＴＨ５１とスレッドＴＨ
５２が同時に動作した場合について説明する。上述した
スレッドＴＨ５１のみが動作した場合との違いは、コー
ル管理装置１１１３がスレッドＴＨ５１によって作成さ
れた要求メッセージとスレッドＴＨ５２によって作られ
た要求メッセージの両方を送信する必要がある点であ
る。これらの要求メッセージは、ＴＣＰ／ＩＰコネクシ
ョンを使用中の手続きの処理が完了し、応答メッセージ
を受け取ってから、同一のＴＣＰ／ＩＰコネクションが
獲得されてこのコネクション上に時間をずらして送信さ
れる。あるいは、これらの要求メッセージをスレッドと
同数のＴＣＰ／ＩＰコネクションを用いて送信する。い
ずれの場合であっても、これらの送信のスケジューリン
グはアプリケーションの内容とは無関係に行われる。

【００２１】また、サーバ側に要求メッセージが届いた
とき、すべての要求メッセージに対して処理内容とは無
関係にスレッドプール管理装置１１１７が管理するスレ
ッドプール１１１８内の空きスレッドが処理スレッドと
して割り当てられる。図１２においてもスレッドＴＨ５
３やスレッドＴＨ５４はスレッドプール１１１８内の空
きスレッドから割り当てられたものである。

【００２２】

【発明が解決しようとする課題】従来のＲＰＣの処理方
法にあっては、クライアントが複数の手続きを同時に処
理する場合に、確立されている１つのTCP／ＩＰコネク
ションを複数の手続き処理で使用することはできるが、
動作中の手続きの処理が完了してＴＣＰ／ＩＰコネクシ
ョンの利用が終了するまで、同じＴＣＰ／ＩＰコネクシ
ョン上での他の手続きの処理は待ち状態に保たれるよう
になっていた。また、別の従来のＲＰＣの処理方法で
は、クライアントが複数の手続きを同時に処理する場
合、これらの手続きと同数のＴＣＰ／ＩＰコネクション
をそれぞれ利用しなければならなかった。すなわち、あ
る手続きがＴＣＰ／ＩＰコネクションを使用中の場合、
別の手続きの処理のために新たなＴＣＰ／ＩＰコネクシ
ョンを確立していた。

【００２３】これらのいずれかまたは両方の方法が、処
理するプロシジャの特性に無関係に採用されていた。こ
のため次のような問題が生じていた。マルチスレッドに
よって動作するクライアントでは、同時に多数の手続き
呼出し要求が生じる場合がある。前者の方法を用いた場
合、もし、多数の手続きのそれぞれの処理時間が長い場
合、すべての手続き処理を完了するまでの時間が著しく
長くなるという問題点があった。

【００２４】また、後者の方法を用いた場合、ＴＣＰ／
ＩＰコネクションの数が同時に実行する手続きの数とな
るので、同時に確立して使用するＴＣＰ／ＩＰコネクシ
ョンの数が多くなり、それに伴うネットワークトラフィ
ックやＴＣＰ／ＩＰコネクションを管理するためにＴＣ
Ｐ／ＩＰ通信処理装置内部に必要とされる資源が増大す
るという問題点があった。

【００２５】また、サーバ側にあっては、従来のサーバ
スタブ内でのマルチスレッド処理では、実行する手続き
の特性とは無関係に、クライアントからの手続き要求ご
とに新規にスレッドを作成するか、あるいは、クライア
ントからの手続き要求を全てスレッドプール内のスレッ
ドを使用して処理するかの何れかの方法のみが用いられ
てた。このため、前者の処理方法にあっては、全ての手
続きに対してスレッド作成のオーバヘッドを強いること
になるという問題点があった。後者の処理方法にあって
は、処理時間の長い手続きが呼出された場合には、スレ
ッドプール内の空きスレッドの枯渇が起きるという問題
点があった。

【００２６】また、従来のスタブ生成方法に注目した場
合でも、手続きの特性に応じて生成するスタブの形式を
変更することはできなかった。すなわち、どのようなス
タブを生成するかについては、呼出される手続きの特性
とは無関係にある決まった方法が提供されているだけで
あり、アプリケーション開発者が選択することはできな
かった。また、もしスタブ形式を変更しようとした場合
には、多くの変更点を必要とするだけでなく、その変更
がすべてのアプリケーションに影響を及ぼすという問題
点があった。

【００２７】本発明は、上記のような問題点を解決する
ためになされたもので、手続きの処理時間特性を考慮し
た仮想通信回線の獲得およびスレッドの獲得を可能にす
ることにより、仮想通信回線の有効利用と効率的なスレ
ッド管理を実現する遠隔手続き呼出しの処理方法を提供
することを目的とする。

【００２８】また、本発明は、手続きの処理時間特性を
考慮してスタブの形式を選択可能にすることにより、各
手続きに適したスタブを生成することができるようにし
たスタブ生成方法を提供することを目的とする。

【００２９】

【課題を解決するための手段】本発明は、上記課題を解
決するため、並列処理が行われるクライアントとサーバ
との間で仮想通信回線を介して複数の手続きを呼出して
実行する手続き呼出しの処理方法において、現在処理中
の手続きの他に新たな手続きが前記クライアントからサ
ーバに対して呼出されたとき、各手続きの処理時間に関
する情報を対応する手続きに関連付けて記憶したテーブ
ルから、現在処理中の手続きの処理時間に関する情報を
検索する時間情報検索工程と、該時間情報検索工程で検
索された現在処理中の手続きの処理時間に関する情報に
基づいて、前記新たな手続きの呼出しに用いられる仮想
通信回線を獲得する回線獲得工程と、を含むことを特徴
とするものである。

【００３０】また本発明は、前記各手続きの処理時間に
関する情報をインタフェース定義言語の拡張属性として
含むインタフェース定義言語仕様ファイルを、翻訳する
ことによりクライアントスタブを生成するスタブ生成工
程を含み、前記テーブルが前記クライアントスタブに含
まれるようにしてもよい。

【００３１】さらに本発明は、前記クライアントにより
呼出される手続きの処理時間が、所定の基準に対して長
時間であると判断される長時間グループと短時間である
と判断される短時間グループの何れかに分類されて前記
インタフェース定義言語の拡張属性として前記インタフ
ェース定義言語仕様ファイルに記述され、前記インタフ
ェース定義言語仕様ファイルにより定義された各手続き
の処理時間が前記長時間グループと前記短時間グループ
のどちらのグループに分類されたかを表す情報が前記テ
ーブルに記憶され、前記回線獲得工程が、前記テーブル
に記憶されている現在処理中の手続きの中に、長時間グ
ループに分類されている処理時間の手続きがあるとき、
長時間グループに分類された処理時間の手続きによって
現在使用されている仮想通信回線を、前記新たな手続き
の処理用に獲得して共用する回線共用工程を含むように
してもよい。

【００３２】さらに本発明は、前記クライアントにより
呼出される手続きの処理時間が、所定の基準に対して長
時間であると判断される長時間グループと短時間である
と判断される短時間グループの何れかに分類されて前記
インタフェース定義言語の拡張属性としてインタフェー
ス定義言語仕様ファイルに記述され、前記インタフェー
ス定義言語仕様ファイルにより定義された各手続きの処
理時間が前記長時間グループと前記短時間グループのど
ちらのグループに分類されたかを表す情報が前記テーブ
ルに記憶され、前記回線獲得工程が、前記テーブルに記
憶されている現在処理中の手続きの中に、長時間グルー
プに分類されている処理時間の手続きがあるか否かを判
別する第１の工程と、該第１の工程で長時間グループの
処理時間の手続きがあると判別されたとき、長時間グル
ープの処理時間の手続き用に獲得されている仮想通信回
線が信号伝送中の状態か空き状態かを判別する第２の工
程と、該第２の工程で仮想通信回線が空き状態であると
判別されたとき、長時間グループの処理時間の手続き用
に現在使用されている前記仮想通信回線を、前記新たな
手続き用に獲得して共用する第３の工程と、を含むよう
にしてもよい。

【００３３】また本発明は、マルチスレッドにより動作
するクライアントとサーバとの間で仮想通信回線を介し
て複数の手続きを呼出して実行する手続き呼出しの処理
方法において、前記サーバに対して前記クライアントか
ら手続きの実行が要求されたとき、前記複数の手続きの
それぞれの処理時間に関する情報を対応する各手続きに
関連付けて記憶したテーブルから、今回実行要求のあっ
た手続きの処理時間に関する情報を検索する時間情報検
索工程と、今回実行要求のあった手続きを前記サーバで
実行するためのスレッドを、前記テーブルに記憶された
今回実行要求のあった手続きの処理時間の情報に基づい
て獲得するスレッド獲得工程と、を含むことを特徴とす
るものである。

【００３４】さらに本発明は、前記各手続きの処理時間
に関する情報をインタフェース定義言語の拡張属性とし
て含むインタフェース定義言語仕様ファイルを、翻訳す
ることによりサーバスタブを生成する工程を含み、前記
テーブルが前記サーバスタブに含まれるようにしてもよ
い。

【００３５】また本発明は、前記サーバにより実行され
る手続きの処理時間が、所定の基準に対して相対的に長
時間であると判断される長時間グループと相対的に短時
間であると判断される短時間グループの何れかに分類さ
れて前記インタフェース定義言語の拡張属性として記述
され、前記インタフェース定義言語仕様ファイルにより
定義された各手続きの処理時間が前記長時間グループと
前記短時間グループのどちらのグループに分類されたか
を表す情報が前記テーブルに記憶され、前記スレッド獲
得工程が、前記サーバに対して手続きの実行が要求され
たとき、前記テーブルに記憶された情報から、今回実行
要求のあった手続きの処理時間が長時間グループと短時
間グループの何れに分類されているかを判別する第１の
工程と、該第１の工程で処理時間が短時間グループに分
類されていると判別されたとき、前記サーバ用に予め作
成されたスレッドを、今回要求のあった手続きを実行す
るためのスレッドとして獲得する第２の工程と、前記第
１の工程で処理時間が長時間グループに分類されている
と判別されたとき、新規にスレッドを作成し、該新規ス
レッドを、今回要求のあった手続きを実行するためのス
レッドとして獲得する第３の工程と、を含むようにして
もよい。

【００３６】さらに本発明は、前記サーバがメモリバス
と入出力バスを備えたコンピュータからなり、前記所定
の基準が、各手続きの前記入出力バスと前記メモリバス
の利用形態に基づくものであり、前記サーバに対して前
記入出力バスの利用を必要とする手続きの処理時間が長
時間グループに分類され、前記サーバに対して前記メモ
リバスの利用のみを必要とする手続きの処理時間が短時
間グループに分類されるようにしてもよい。

【００３７】また本発明は、クライアントとサーバとの
間で手続き呼出しを可能にするインタフェース定義言語
仕様ファイルを翻訳することによって、クライアントス
タブを生成するスタブ生成方法において、前記インタフ
ェース定義言語仕様ファイルが、前記クライアントによ
り呼出される手続きの処理時間に関する情報をインタフ
ェース定義言語の拡張属性として含むファイルからな
り、前記スタブ生成方法が、前記インタフェース定義言
語仕様ファイルから、該インタフェース定義言語仕様フ
ァイルで定義されている手続きの処理時間を認識する処
理時間認識工程と、予め準備された互いに異なる少なく
とも二つのスタブ生成プロセスの中から、前記処理時間
認識工程で認識された処理時間に基づいて、一つのスタ
ブ生成プロセスを選択するプロセス選択工程と、を含
み、前記クライアントスタブが、前記プロセス選択工程
で選択されたスタブ生成プロセスに従って生成されるこ
とを特徴とするものである。

【００３８】さらに本発明は、前記クライアントにより
呼出される手続きの処理時間が、所定の基準に対して長
時間であると判断される長時間グループと短時間である
と判断される短時間グループの何れかに分類されて前記
インタフェース定義言語の拡張属性として前記インタフ
ェース定義言語仕様ファイルに記述され、前記処理時間
認識工程が、インターフェース定義言語仕様ファイルに
定義されている手続きの中に、長時間グループに分類さ
れた処理時間の手続きがあるか否かを判別する時間グル
ープ判別工程を含み、前記スタブ生成方法が、前記時間
グループ判別工程で長時間グループの処理時間の手続き
があると判別されたとき、前記インタフェース定義言語
仕様ファイルにより定義された各手続きの処理時間が前
記長時間グループと前記短時間グループのどちらのグル
ープに分類されたかを表す情報を記憶したテーブルを、
クライアントスタブに作成するテーブル作成工程を含む
ようにしてもよい。

【００３９】また本発明は、クライアントとサーバとの
間で遠隔手続き呼出しを可能にするインタフェース定義
言語仕様ファイルを翻訳することによって、サーバスタ
ブを生成するスタブ生成方法において、前記インタフェ
ース定義言語仕様ファイルが、前記サーバにより実行さ
れる手続きの処理時間に関する情報をインタフェース定
義言語の拡張属性として含むファイルからなり、前記ス
タブ生成方法が、前記インタフェース定義言語仕様ファ
イルから、該インタフェース定義言語仕様ファイルで定
義されている手続きの処理時間を認識する処理時間認識
工程と、予め準備された互いに異なる少なくとも二つの
スタブ生成プロセスの中から、前記処理時間認識工程で
認識された処理時間に基づいて、一つのスタブ生成プロ
セスを選択するプロセス選択工程と、を含み、前記サー
バスタブが、前記プロセス選択工程で選択されたスタブ
生成プロセスに従って生成されることを特徴とするもの
である。

【００４０】さらに本発明は、前記サーバにより実行さ
れる手続きの処理時間が、所定の基準に対して長時間で
あると判断される長時間グループと短時間であると判断
される短時間グループの何れかに分類されて前記インタ
フェース定義言語の拡張属性として前記インタフェース
定義言語仕様ファイルに記述され、前記処理時間認識工
程が、インターフェース定義言語仕様ファイルに定義さ
れている手続きの中に、長時間グループに分類された処
理時間の手続きがあるか否かを判別する時間グループ判
別工程を含み、前記スタブ生成方法が、前記時間グルー
プ判別工程で長時間グループの処理時間の手続きがある
と判別されたとき、前記インタフェース定義言語仕様フ
ァイルにより定義された各手続きの処理時間が前記長時
間グループと前記短時間グループのどちらのグループに
分類されたかを表す情報を記憶したテーブルを、サーバ
スタブに作成するテーブル作成工程を含むようにしても
よい。

【００４１】

【発明の実施の形態】実施形態１．図１は、本発明に係
る遠隔手続き呼出しの処理方法を実行するクライアント
サーバシステムを示すブロック図である。まず、この図
１を参照して上記クライアントサーバシステムの概略構
成を説明する。

【００４２】図１において、１０３および１０４はそれ
ぞれ通信ノードであり、これら通信ノード１０３、１０
４はネットワーク１２０に接続されたコンピュータを表
している。本実施形態では、通信ノード１０３がクライ
アント、通信ノード１０４がサーバとなる。通信ノード
１０３、１０４はそれぞれ下位コネクション指向通信処
理装置１３１、１３２を有している。

【００４３】下位コネクション指向通信処理装置１３
１、１３２は各通信ノード上で実装されている下位レベ
ルの通信処理装置である。下位コネクション指向通信処
理装置１３１、１３２は、例えばＴＣＰ／ＩＰ（Ｔｒａ
ｎｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ
／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）に従って通信
を行う通信処理装置を表す。ＴＣＰ／ＩＰなどを採用す
る下位コネクション指向通信処理装置１３１、１３２
は、コネクションと呼ばれる仮想通信回線を通信ノード
間に確立して通信を処理する装置である。この他の下位
コネクション指向通信処理装置の例としては、ＩＰＸ／
ＳＰＸ（ＩｎｔｅｒｎｅｔＰａｃｋｅｔＥｘｃｈａｎ
ｇｅ／ＳｅｑｕｅｎｔｉａｌＰａｃｋｅｔＰｒｏｔ
ｏｃｏｌ）を採用する通信処理装置などがある。なお、
仮想通信回線は、論理的な架空通信回線を意味している
ので、論理通信回線と呼ぶこともできる。

【００４４】１０５はクライアントマルチスレッドアプ
リケーション、１０６はサーバマルチスレッドアプリケ
ーションであり、これらのアプリケーション１０５、１
０６はマルチスレッドによって動作するとともに本発明
に係る遠隔手続き呼出しの処理方法を利用するアプリケ
ーションである。マルチスレッドによって動作するアプ
リケーションは、スレッドと呼ばれる仮想的な処理プロ
セッサとしての一つまたは複数の実行体を有し、アプリ
ケーションはこの実行体により動作する。スレッドは例
えば通信ノード上のオペレーティングシステムなどによ
って提供される機能である。スレッドを提供しているオ
ペレーティングシステムの例として、マイクロソフト社
のＷｉｎｄｏｗｓＮＴやサンマイクロ社のＳｏｌａｒ
ｉｓなどがある。

【００４５】１０１は拡張属性を記述可能なＩＤＬによ
り記述されたＩＤＬ仕様ファイルであり、ＩＤＬ仕様フ
ァイル１０１はアプリケーションの開発者によって記述
されるファイルである。ＩＤＬ仕様ファイル１０１は、
クライアントマルチスレッドアプリケーション１０５と
サーバマルチスレッドアプリケーション１０６との呼出
しインタフェースを定義するものである。

【００４６】ＩＤＬ仕様ファイル１０１はＩＤＬコンパ
イラ１０２により翻訳（コンパイル）され、クライアン
トスタブ１０７とサーバスタブ１０８が生成される。よ
り具体的には、アプリケーション開発者が通信ノード１
０３、１０４上でＩＤＬコンパイラ１０２を実行してＩ
ＤＬ仕様ファイルからそれぞれクライアントスタブ１０
７およびサーバスタブ１０８を生成する。また、ＩＤＬ
コンパイラ１０２は従来のIDLコンパイラに対し受理可
能な文法の拡張を行なっており、構文解析処理において
拡張属性の認識が可能である。

【００４７】クライアントスタブ１０７は、メッセージ
作成装置１０９、メッセージ送受信装置１１０、コネク
ション管理装置１１１、オペレーション管理テーブル１
１２および回線管理テーブル１１３を備えている。

【００４８】メッセージ作成装置１０９は、クライアン
トマルチスレッドアプリケーション１０５のスレッドか
ら受け取ったデータを、ネットワーク１２０を介した通
信に適切な形式に変換してメッセージを作成する。また
メッセージ作成装置１０９は、逆にネットワーク１２０
から受け取ったメッセージをクライアントマルチスレッ
ドアプリケーション１０５のスレッドに対して適切なデ
ータ形式に変換してクライアントマルチスレッドアプリ
ケーション１０５に渡す。

【００４９】メッセージ送受信装置１１０は、後述のコ
ネクション管理装置１１１からの情報を基づいて、メッ
セージ作成装置１０９から受け取ったメッセージを下位
コネクション指向通信処理装置１３１により提供されて
いる仮想通信回線に対して送信する。またメッセージ送
受信装置１１０は、逆に仮想通信回線から受け取った複
数のメッセージを適切なクライアントマルチスレッドア
プリケーション１０５のスレッドに振り分ける。

【００５０】コネクション管理装置１１１は、後述する
オペレーション管理テーブル１１２および回線管理テー
ブル１１３を参照して、下位コネクション指向通信処理
装置１３１により提供されている仮想通信回線の確立と
破棄を行うものである。このコネクション管理装置１１
１によって、クライアントマルチスレッドアプリケーシ
ョン１０５とサーバマルチスレッドアプリケーション１
０６との間で同時に複数の仮想通信回線の使用が可能に
なる。

【００５１】一方、サーバスタブ１０８は、メッセージ
作成装置１１４、スレッド管理装置１１５、メッセージ
送受信装置１１６およびスレッドプール１１７を備えて
いる。メッセージ作成装置１１４は、ネットワーク１２
０から受け取ったメッセージをサーバマルチスレッドア
プリケーション１０６に対して適切なデータ形式に変換
する。またメッセージ作成装置１１４は、逆にサーバマ
ルチスレッドアプリケーション１０６のスレッドから受
け取ったデータを、ネットワーク１２０を介した通信に
適切な形式に変換してメッセージを作成する。

【００５２】スレッド管理装置１１５は、スレッドプー
ル１１７を管理するものであり、スレッドを生成し、ま
た消滅させる機能を有している。スレッドプール１１７
は、サーバマルチスレッドアプリケーション１０６を起
動する際に、あらかじめ複数個のスレッドを作成し備蓄
しておき、クライアントマルチスレッドアプリケーショ
ン１０６からの処理要求が来た際には、この備蓄された
スレッドがスレッド管理装置１１５を介して取り出さ
れ、その処理を担当するようになっている。

【００５３】メッセージ送受信装置１１６は、後述のコ
ネクション管理装置１１１からの情報を基づいて、メッ
セージ作成装置１０９から受け取ったメッセージを下位
コネクション指向通信処理装置１３２により提供されて
いる仮想通信回線に対して送信する。また、逆に仮想通
信回線から受け取った複数のメッセージを適切なクライ
アントマルチスレッドアプリケーション１０５のスレッ
ドに振り分ける装置である。

【００５４】次に、クライアント側の通信ノード１０３
内を詳細に示した図２および通信ノード１０３内で実行
される工程を示した図３を参照しながら、クライアント
の動作について説明する。図２において、クライアント
マルチスレッドアプリケーション１０５はサーバマルチ
スレッドアプリケーション１０６にある３つのオペレー
ションを起動するアプリケーションとして示されてい
る。ここに、オペレーションは「手続き」あるいは「プ
ロシジャ」と同義であり、ここでは上記３つのオペレー
ションを「operation1」、「operation2」、「operatio
n3」とそれぞれ記述する。

【００５５】このようなアプリケーションを開発する場
合、まず、アプリケーションの開発者はＩＤＬによって
図２に示すようなIDL仕様ファイル１０１を作成する。
本実施形態におけるＩＤＬを利用すると、従来のＩＤＬ
と同様に、インタフェース名、オペレーション名、オペ
レーションの返り値の型、オペレーションの引数の型と
名前およびオペレーションの引数の属性である方向をＩ
ＤＬ仕様ファイルに記述できる。例えば、図２に示され
たＩＤＬ仕様ファイル１０１では、インタフェース名A
において３つのオペレーションが定義されている。

【００５６】オペレーション名はサーバマルチスレッド
アプリケーションで起動されるオペレーションの名前で
あり、本実施形態では「operation1」、「operation
2」、「operation3」がオペレーション名である。図２
に示されたＩＤＬ仕様ファイルに示されるように、「op
eration1」は「double」型の返り値と２つの引数を持
つ。最初の引数は「short」型であり、引数名はsであ
る。次の引数は「long」型であり、引数名はtである。

【００５７】[in]、[inout]、[out]は引数に与えられた
データが送られる方向を表す属性である。[in]属性を持
つ引数は、クライアントマルチスレッドアプリケーショ
ン１０５からサーバマルチスレッドアプリケーション１
０６へと引数として与えられたデータが送られることを
表わす。

【００５８】[inout]属性を持つ引数は、クライアント
マルチスレッドアプリケーション１０５からサーバマル
チスレッドアプリケーション１０６に、引数として与え
られたデータが送られ、サーバ側の実際に実行されるオ
ペレーションでデータに対して何らかの処理を行った
後、再びサーバマルチスレッドアプリケーション１０６
からクライアントマルチスレッドアプリケーション１０
５にデータが送られることを表わす。

【００５９】[out]属性を持つ引数はサーバマルチスレ
ッドアプリケーションからクライアントマルチスレッド
アプリケーション２０３に、引数として与えれたデータ
が送られることを意味する。

【００６０】図２の「operation1」ではクライアントマ
ルチスレッドアプリケーション１０５から「short」型
と「long」型のデータがサーバマルチスレッドアプリケ
ーション１０６に対して送られ、このデータをもとにサ
ーバ側の「operation1」で開発者が記述した処理を実行
する。そして、処理後の「long」型のデータとオペレー
ションの返り値である「double」型のデータが、サーバ
マルチスレッドアプリケーション１０６からクライアン
トマルチスレッドアプリケーション１０５に送られる。

【００６１】本実施形態１のＩＤＬは、上述の従来の記
述に加えて、新たにオペレーションの属性として[long]
の指定が可能である。本実施形態では、図２に示される
ように「operation1」と「operation3」に対して[long]
属性が指定されている。[long]属性を持つオペレーショ
ンは、サーバ側で実際に処理される可能性のあるオペレ
ーション群をその処理時間が相対的に長時間である長時
間グループと短時間グループの２つのグループに分類し
たときに、長時間グループに属する処理時間のオペレー
ションを指す。逆にこの[long]属性の記述がないオペレ
ーションは、その処理時間が相対的に短時間である短時
間グループに属する処理時間のオペレーションであるこ
とを意味する。

【００６２】各オペレーションの処理時間の長短の基準
は、アプリケーション開発者の経験的な主観に基づくも
のである。あるいは、次のような基準で処理時間の長短
を判断してもよい。一般的に、サーバの機能を有するコ
ンピュータすなわち通信ノード１０４に対して入出力バ
スの利用を要求、例えばハードディスクに対するアクセ
スやネットワーク上の資源に対するアクセス等を要求す
るオペレーションの処理時間は、コンピュータに対して
メモリバスの利用のみを要求する手続きの処理時間に対
してオーダが一桁以上相違して長くなる。したがって、
サーバ側のコンピュータに対して入出力バスの利用を要
求するオペレーションの処理時間を長時間グループ、メ
モリバスの利用のみを要求するオペレーションの処理時
間を短時間グループに分類して、処理時間の長短を判断
するようにしてもよい。さらに、もしアプリケーション
開発者が各オペレーションの処理時間の値を予め知って
いる場合には、所定のしきい値に対する大小関係に基づ
いて処理時間の長短を決定するようにしてもよい。

【００６３】図２は、クライアントマルチスレッドアプ
リケーション１０５がスレッドＴＨ２に続いてスレッド
ＴＨ１が実行された状態を表している。詳しくは、スレ
ッドＴＨ２が既に「operation3」を実行しており、下位
コネクション指向通信処理装置１３１により提供される
2つ仮想通信回線１２１、１２２のうちの仮想通信回線
１２１が「operation3」のために使用されており、ここ
でクライアントマルチスレッドアプリケーション１０５
内の別のスレッドＴＨ１が「operation1」を２つの引数
データをともなって起動した状態を、図２は示してい
る。

【００６４】上述のように構成された通信ノード１０３
は、図３に示されるフローチャートに従って動作する。
まずステップＳ１で、クライアントマルチスレッドアプ
リケーション１０５が、「operation1」を引数５と３で
呼出す要求をクライアントスタブ１０７に送る。ステッ
プＳ２では、クライアントスタブ１０７内のメッセージ
作成装置１０９が、サーバ側でオペレーションを識別す
るためのオペレーションID（オペレーションを表す番号
またはオペレーション名そのものでも良い）と引数のデ
ータをクライアントマルチスレッドアプリケーション１
０５から受け取る。

【００６５】ステップＳ３で、メッセージ作成装置１０
９は、必要であれば与えられた引数をネットワーク１２
０上を送信可能な形式に変換するとともに、オペレーシ
ョンIDと複数の引数を予め決められたメッセージフォー
マットに従って整列させ、図２に示すようなメッセージ
１０９ａを作成する。このメッセージ１０９ａがサーバ
マルチスレッドアプリケーション１０６に向けて送信さ
れることになる。ステップＳ４では、メッセージ送受信
装置１１０がメッセージ作成装置２０７からメッセージ
１０９ａを受け取り、適切な仮想通信回線をコネクショ
ン管理装置１１１に対して要求する。

【００６６】ステップＳ６で、コネクション管理装置１
１１は、図２に示されるオペレーション管理テーブル１
１２から[long]属性を持つオペレーションによって現在
使用中の仮想通信回線を検索する。検索した結果、ステ
ップＳ７で、該当する仮想通信回線があればステップＳ
８に進み、なければステップＳ１０に進む。図２に示さ
れた動作状態では、[long]属性を持つ「operation3」が
仮想通信回線１２１を使用中であるので、仮想通信回線
１２１が検索されることになり、ステップＳ８に進むこ
とになる。

【００６７】このステップＳ８では、メッセージ送受信
装置１１０がコネクション管理装置１１１から該当する
仮想通信回線を獲得し、その仮想通信回線上にメッセー
ジ１０９ａを送信する。[long]属性を持つオペレーショ
ンは、通常、サーバ側での処理時間が長いため、使用し
ている仮想通信回線は実際には空き状態であることが多
い。メッセージ送受信装置１１０はこの空き時間を利用
して後発のオペレーションのメッセージを送信する。

【００６８】図４は、図３のステップＳ８から直接ステ
ップＳ８に進んだ場合の仮想通信回線１２１の各メッセ
ージの利用状態例を示している。スレッドＴＨ２が「op
eration3」の処理のために、仮想通信回線１２１を使用
し始めるのが時刻Ｔ１であり、サーバからの「short」
型の返り値を含む応答メッセージを受け取り、利用し終
わるのが時刻Ｔ６である。スレッドＴＨ１が「operatio
n1」を実行するために、仮想通信回線１２１を利用し始
めるのが時刻Ｔ３である。この時点で、スレッドＴＨ２
が「operation3」の処理のためにすでに仮想通信回線２
１０を使用中であるが、メッセージの送信自体はすでに
時刻Ｔ２の時点で終了している。

【００６９】したがって、スレッドＴＨ１は「operatio
n1」を実行するために、仮想通信回線１２１を利用して
メッセージを送信することが可能である。もしも、仮想
通信回線が先のオペレーションのために信号伝送中であ
る場合には、その信号伝送が終了して空き状態になるま
で待って、後発のオペレーションのメッセージが送信さ
れる。

【００７０】ステップＳ７からステップＳ１０に進んだ
場合、ステップＳ１０では、コネクション管理装置１１
１が回線管理テーブル１１３から未使用の仮想通信回線
を検索する。検索の結果、ステップＳ１１で該当する仮
想通信回線が検索された場合、ステップＳ８に進み、該
当する仮想通信回線がない場合には、ステップＳ１２に
進む。

【００７１】図２に示された回線管理テーブル１１３の
場合には、未使用の仮想通信回線１２２があるので、ス
テップＳ８に進んでこの仮想通信回線１２２をメッセー
ジ送受信装置１１０が獲得する。

【００７２】また、もし全ての仮想通信回線が使用中で
ある場合には、ステップＳ１２で下位コネクション指向
通信処理装置１３１に新しい仮想通信回線を確立させ
て、回線管理テーブル１１３に登録するとともに、「op
eration1」の使用中の回線としてコネクション管理装置
１１１に登録する。次いで、ステップＳ１２からステッ
プＳ８に進み、メッセージ送受信装置１１０は新規に登
録された仮想通信回線を獲得して、この仮想通信回線上
に「operation1」のメッセージを送信する。

【００７３】一方、図２に示した通信ノード１０４のメ
ッセージ送受信装置１１６は、各仮想通信回線から受信
した要求メッセージに対して、スレッド管理装置１１５
を介してスレッドプール１１７からスレッドを獲得し、
その要求メッセージのオペレーションの実行用に割り当
てる。また、メッセージ送受信装置１１６は、一つの仮
想通信回線が複数のオペレーションの要求メッセージに
より共用されていても、各要求メッセージに対して誤り
なく各スレッドを割り当て、さらに各スレッドの実行結
果を表す各回答メッセージを、対応する要求メッセージ
が送信されてきた仮想通信回線上に送り返す。

【００７４】上述のように本実施形態１によれば、ＩＤ
Ｌ仕様ファイルに記述された各オペレーションの拡張属
性から各オペレーションの処理時間に関する情報を認識
してオペレーション管理テーブル１１２に記憶してお
き、新たなオペレーションが呼出されるときには、この
オペレーション管理テーブル１１２に記憶された各オペ
レーションの処理時間情報に基づいて、仮想通信回線を
獲得している。したがって、処理中の各オペレーション
の処理時間に応じて変化する使用中の仮想通信回線の空
き時間を利用することが可能になり、既に使用中の仮想
通信回線の有効利用を図ることができる。

【００７５】また、各オペレーションの処理時間を[lon
g]指定有りの長時間グループと、[long]指定無しの短時
間グループとに分類して、現在処理中の長時間処理のオ
ペレーションにより使用されている仮想通信回線を、後
発のオペレーションのために共用している。この結果、
使用中の仮想通信回線の空き時間を有効利用することが
できるので、先のオペレーションによる仮想通信回線の
使用が全て終了するのを待って同じ仮想通信回線を使用
する従来の方法に比較して、全てのオペレーションの呼
出し処理を完了するまでの時間を大幅に短縮することが
できる。さらに、各オペレーションの呼出しごとに別の
仮想通信回線を確立して割り当てる従来の方法に比較す
ると、同時に確立され使用される仮想通信回線の数を減
少させることができ、結果的にネットワークトラフィッ
クを軽減するとともに、ＴＣＰ／ＩＰコネクションを管
理するためにＴＣＰ／ＩＰ通信処理装置内部に必要とさ
れる資源を減少させることができる。

【００７６】さらにまた、短時間処理のオペレーション
により使用中の仮想通信回線を後発のオペレーションが
共用しないので、短時間処理のオペレーション同士が仮
想通信回線を共有することによるオーバヘッドを軽減す
ることができる。

【００７７】またさらに、共用する仮想通信回線がない
場合には、まず、既に確立されている未使用の仮想通信
回線をまず検索して、このような仮想通信回線があれ
ば、これを後発のオペレーションが使用し、ない場合に
だけ新たに仮想通信回線を確立している。したがって、
オペレーションごとに仮想通信回線を確立するオーバヘ
ッドを軽減することができる。

【００７８】実施形態２．上述の実施形態１では、処理
時間の長いオペレーションが使用する仮想通信回線に着
目し、その仮想通信回線の再利用と有効利用を行なうよ
うにしたものであるが、本実施形態２では、更に、その
仮想通信回線上で現在メッセージの送受信を実際に行な
っているかどうかを示すフラグをオペレーション管理テ
ーブルに設け、そのフラグの状態もさらに考慮して仮想
通信回線の共用をするか否かを決定するようにしてい
る。

【００７９】図５において、ＩＤＬコンパイラ２０２
は、ＩＤＬ仕様ファイル１０１を翻訳して、クライアン
トスタブ２０７を生成する。図５に示されたクライアン
トスタブ２０７と、図２に示されたクラインとスタブ１
０７とは、コネクション管理装置とオペレーション管理
テーブルが相違する。図５に示されたオペレーション管
理テーブル２１２には、図２に示されたオペレーション
管理テーブル１１２の各項目に加え、使用中の仮想通信
回線が、現在、信号を伝送中か否かを表わす送受信中フ
ラグの項目が設けられている。

【００８０】図５に示されたコネクション管理装置２１
１は、図２に示されたコネクション管理装置１１１の機
能に加え、オペレーション管理テーブル２１２の送受信
中フラグをも管理するものである。詳しくは、コネクシ
ョン管理装置２１１は、送受信中フラグがオンのとき、
すなわち仮想通信回線が現在、信号伝送中であるとき、
その仮想通信回線がたとえ[long]属性を持つオペレーシ
ョンが使用している仮想通信回線であっても、メッセー
ジ送受信装置１１０に対してこの仮想通信回線を利用可
能な回線として渡さない。

【００８１】一方、送受信フラグがオフのとき、コネク
ション管理装置２１１は、[long]属性を持つオペレーシ
ョンが使用している仮想通信回線を、メッセージ送受信
装置１１０に対して共用すべき回線として渡す。

【００８２】図６は、図５に示された通信ノード内で実
行される工程を示すフローチャートであり、図３に示さ
れたフローチャートのステップＳ７とステップＳ８の間
にステップＳ７ａが挿入されている以外は図３のものと
同じである。このため、図３との相違個所を中心に説明
する。

【００８３】図６において、ステップＳ１〜Ｓ５の後、
ステップＳ６で、コネクション管理装置２１１は、図５
に示されるオペレーション管理テーブル２１２から[lon
g]属性を持つオペレーションが使用している仮想通信回
線を検索する。検索した結果、ステップＳ７で、該当す
る仮想通信回線があればステップＳ８に進み、なければ
ステップＳ１０に進む。図５に示された動作状態では、
[long]属性を持つ「operation3」が仮想通信回線１２１
を使用中であるので、仮想通信回線１２１が検索される
ことになり、ステップＳ７ａに進むことになる。このス
テップＳ７ａでは、仮想通信回線１２１が現在、信号を
伝送中か否かが判別され、信号伝送中であればステップ
Ｓ１０に進み、信号伝送中でなければステップＳ８に進
む。

【００８４】図５に示されたオペレーション管理テーブ
ル２１２の状態では、[long]属性を持つ「operation3」
用に使用されている仮想通信回線の送受信中フラグがオ
ン状態であるので、この場合にはステップＳ７ａはステ
ップＳ１０に進む。一方、もしステップＳ８に進んだ場
合には、[long]属性を持つオペレーション用に使用され
ている仮想通信回線が、「operation1」の処理に使用さ
れる仮想通信回線として獲得され共用されることにな
る。

【００８５】以上のように、処理時間の長いオペレーシ
ョンに着目し、それが使用している仮想通信回線を他の
オペレーションの実行に共有する際、仮想通信回線上で
現在、メッセージの伝送中かどうかまで判別することに
よって、同じ仮想通信回線を共有するオペレーションが
増えた場合でも、オペレーションの実行が過度に遅延す
るのを防止することができる。

【００８６】図７を用いて、本実施形態２の効果をより
具体的に説明する。図８は、ある仮想通信回線がすでに
５つのスレッドＴＨ２１〜ＴＨ２５による５つのオペレ
ーションの実行によって、共有されている様子を示した
ものである。時刻Ｔ１から始まり、時刻Ｔ６までは、こ
の仮想通信回線上に何らかのメッセージが送信中であ
る。例えば、時刻Ｔ１から時刻Ｔ２までは、スレッドＴ
Ｈ２２が実行したオペレーションのメッセージが送信中
であり、時刻Ｔ２から時刻Ｔ３まではスレッドＴＨ２１
が実行したオペレーションのメッセージがこの仮想通信
回線上に実際に送信中である。以下、時刻Ｔ４、Ｔ５，
Ｔ６と同様である。

【００８７】今、時刻Ｔ２と時刻Ｔ３の間の時刻Ｔに、
スレッドＴＨ２６があるオペレーションを実行し、これ
によるメッセージを送信しようとした場合、もし、図７
に示す仮想通信回線を使用した場合、この送信は時刻Ｔ
６以降まで遅延される。

【００８８】本実施形態２ではこのような場合を考慮
し、上述したように仮想通信回線を使用する前に、その
仮想通信回線上で現在メッセージ送信または受信、すな
わち信号伝送が行われているかをチェックする。もし、
メッセージの送信または受信が行われている場合は、そ
の仮想通信回線を利用せず、新たに仮想通信回線の確立
を行なう。これによって、同じ仮想通信回線を共有する
オペレーションが増えた場合でも、オペレーションの実
行が過度に遅延することなく共有が可能になる。

【００８９】実施形態３．上記実施形態１、２では、主
にクライアント側の仮想通信回線の有効利用に関するも
のであったが、本実施形態３は、処理時間の長いオペレ
ーションに着目してサーバ側の効率的なマルチスレッド
処理を可能にする方法に関するものである。

【００９０】図８は、ＩＤＬコンパイラ３０２とともに
サーバ側の通信ノードの内部を詳細に示したブロック図
である。なお、クライアント側の通信ノードは、例えば
図１および図２に示した通信ノード１０３ものと同じ構
成であるものとし、また、図１に示した通信ノード１０
４内の構成要素と同じものには同じ符号を付してそれら
の説明は省略する。

【００９１】ＩＤＬコンパイラ３０２は、ＩＤＬ仕様フ
ァイル１０１を翻訳することにより、サーバスタブ３０
４を生成する。サーバスタブ３０４は、図１に示したメ
ッセージ作成装置１１４、スレッド管理装置１１５およ
びスレッドプール１１７と同じ構成要素の他に、メッセ
ージ送受信装置３１６およびオペレーション管理テーブ
ル３１２を備えている。

【００９２】オペレーション管理テーブル３１２は、図
２に示したオペレーション管理テーブル１１２と同様に
構成されるものであり、このオペレーション管理テーブ
ル３１２には、オペレーションID、オペレーションの拡
張属性、使用中の仮想通信回線が登録されている。

【００９３】メッセージ送受信装置３１６は、下位コネ
クション指向通信処理装置１３２により提供される仮想
通信回線よりクライアントが作成したメッセージを受信
する。また、メッセージ送受信装置３１６は、受け取っ
たメッセージのオペレーションＩＤを読み取り、そのオ
ペレーションの拡張属性をオペレーション管理テーブル
３１２より検索する。例えば、オペレーションIDが２の
場合、このオペレーションはoperation2であり、属性は
[long]指定は無しである。オペレーションIDが１の場
合、このオペレーションは「operation1」であり、属性
は[long]指定である。

【００９４】図８に示した例では、オペレーションとし
て、「operation1」と「operation2」が動作している。
「operation1」はＩＤＬ仕様ファイルにおいて[long]属
性を指定されたオペレーションであり、下位コネクショ
ン指向通信処理装置１３２により提供される仮想通信回
線３２１を現在使用している。一方、「operatipon2」
は[long]属性を指定されていないオペレーションであ
り、下位コネクション指向通信処理装置１３２により提
供された仮想通信回線３２２を現在使用している。

【００９５】図９に示すフローチャートを参照して、図
８に示したサーバ側の通信ノードの動作をより具体的に
説明する。まずステップＳ３１で、メッセージ送受信装
置３１６は仮想通信回線を通してクライアントからのメ
ッセージを受け取る。次いでステップＳ３２で、メッセ
ージ送受信装置３１６は、受け取ったメッセージ中のオ
ペレーションＩＤをキーに、オペレーション管理テーブ
ル３１２を検索して、該当するオペレーションの拡張属
性を取得する。ステップＳ３３で取得したオペレーショ
ンの拡張属性に[long]の指定がある場合、ステップＳ３
４に進み、[long]の指定がない場合、ステップＳ３６に
進む。

【００９６】ステップＳ３４で、メッセージ送受信装置
は３１６は、新規に作成するように、スレッド管理装置
１１５に依頼する。ステップＳ３５で、新規スレッドを
今回受信したメッセージを処理するためのスレッドとし
て獲得する。ステップＳ３６で、獲得スレッドによっ
て、今回クライアントから送られてきたメッセージが処
理される。スレッドはメッセージ作成装置１１４を利用
して、メッセージ１１４ａ内の引数を取り出し、実際に
指定されたオペレーションを実行する。図８に示した例
では、オペレーション管理テーブル３１に示されるよう
に「operation1」に対しては[long]属性が指定されてい
る。「operation1」の処理はスレッド管理装置１１５に
よって新たに作成されたスレッドによって処理される。

【００９７】図８においてサーバマルチスレッドアプリ
ケーション３０６内のスレッドＴＨ３１はスレッドプー
ル１１７内のスレッドではなく、スレッド管理装置１１
５が作成した新規スレッドである。このスレッドはオペ
レーション実行後に消滅する。

【００９８】一方、ステップＳ３３からステップＳ３７
に進んだ場合、メッセージ送受信装置３１６は、未使用
中のスレッドをスレッドプール１１７から取り出して、
このスレッドに今回受信したメッセージを処理させるよ
うにスレッド管理装置１１５に依頼する。スレッド管理
装置１１５によってスレッドプール１１７から取り出さ
れたスレッドは、メッセージ作成装置１１４を利用して
メッセージの中身を分解し、指定されたオペレーション
を実行する。

【００９９】例えば、「operation2」には[long]属性が
ない。この場合、メッセージ送受信装置１１４ａは、ス
レッド管理装置１１５に対し、空いているスレッドを求
めてスレッドプール１１７を探索する。ステップＳ３８
で、空きスレッドがあれば、ステップＳ３５に進み、空
きスレッドがなければ、空きスレッドができるまでステ
ップＳ３８を繰り返す。

【０１００】ステップＳ３５では、空きスレッドを、今
回受信したメッセージのオペレーションを実行するため
のスレッドとして獲得する。図８に示した例では、サー
バマルチスレッドアプリケーション３０６内で「operat
ion2」を実行しているスレッドＴＨ３２はスレッドプー
ル１１７内にプールされていたスレッドである。

【０１０１】上述のように本実施形態３によれば、各オ
ペレーションの処理時間に関する情報を認識してオペレ
ーション管理テーブル３１２に記憶しておき、クライア
ント側からオペレーションの呼出し要求があったときに
は、そのオペレーション管理テーブル３１２を参照し
て、今回呼出し要求のあったオペレーションの処理時間
に基づいて、スレッドを獲得している。したがって、そ
のオペレーションの処理時間特性に適したスレッドを獲
得することができる。

【０１０２】また、今回の呼出し要求のオペレーション
が[long]属性である場合だけ、スレッドプールに備蓄さ
れたスレッドではなく、新規なスレッドを作成し、この
新規スレッドを今回呼出し要求のあったオペレーション
の実行に用いている。このため、実行するオペレーショ
ンの特性に関係なくクライアントからの要求メッセージ
ごとに新規にスレッドを作成していた従来の方法に比較
して、短時間処理のオペレーション用には新規スレッド
を作成しないので、スレッド処理作成によるオーバヘッ
ドを軽減することができる。長時間処理のオペレーショ
ンの実行に対して新規スレッドの作成によるオーバヘッ
ドは小さいので、問題にはならない。

【０１０３】さらに、新規スレッドを作成せずに、クラ
イアントからの要求メッセージをすべてスレッドプール
内のスレッドを割り当てていた従来の他の方法に比較し
て、本実施形態３では、呼出し要求のオペレーションの
特性に応じて新規スレッドを適宜作成するよぅにしてい
るので、スレッドプール内の空きスレッドが枯渇する可
能性が低くなり、新たにサーバに到着したメッセージが
待ち状態になる頻度を小さくすることができる。

【０１０４】実施形態４．本実施形態４は、ＩＤＬ仕様
ファイルに、長時間処理のオペレーションを含むもの
と、長時間処理のオペレーションを全く含まないものと
が混在した場合に、個々のＩＤＬ仕様ファイルの特性に
応じてより適切な処理を可能にしたものである。また、
本実施形態４はＩＤＬコンパイラによるスタブ生成過程
に特徴があるので、以下はＩＤＬコンパイラの処理フロ
ーを中心に説明する。

【０１０５】図１０は、本実施形態４におけるＩＤＬコ
ンパイラの処理過程を示すフローチャートである。ま
ず、ＩＤＬコンパイラの処理に入る前に、アプリケーシ
ョン開発者等によって作成された例えば図１に示すよう
なＩＤＬ仕様ファイルが準備される。ステップＳ４１
で、このＩＤＬ仕様ファイルがＩＤＬコンパイラに入力
されると、ステップ４２で、ＩＤＬ仕様ファイルに対し
て字句解析処理が実行される。この字句解析処理によ
り、ＩＤＬ仕様ファイルに記述された文字列がプログラ
ムを表現する意味のある最小単位である字句の列に変換
される。

【０１０６】次いでステップＳ４３で、ＩＤＬ仕様ファ
イルに定義されている各オペレーションの拡張属性が認
識される。ステップＳ４４で、ＩＤＬ仕様ファイルに含
まれたオペレーションの中に[long]属性の指定のものが
あるか否かが判別される。ＩＤＬ仕様ファイルに[long]
属性を持つオペレーションが１つでもある場合には、ス
テップＳ４４からステップＳ４５に進み、全くない場合
には、ステップＳ４６に進む。

【０１０７】ステップＳ４５では、オペレーションの処
理時間を考慮したコンパイル形式を選択して、該コンパ
イル形式に従ってクライアントスタブまたはサーバスタ
ブを生成する。このようなクライアントスタブは、実施
形態１および２で説明したクライアントスタブであり、
サーバスタブは、実施形態３で説明したサーバスタブで
ある。

【０１０８】一方、ステップＳ４６では、オペレーショ
ンの処理時間を考慮しないクライアントスタブまたはサ
ーバスタブを生成する。このようなクライアントスタブ
やサーバスタブは、例えば図１１および図１２に示した
従来技術により生成されるクライアントスタブやサーバ
スタブであればよい。

【０１０９】すなわち、クライアント側にあっては、ク
ライアントの複数のスレッドが同時にオペレーションを
呼出した場合、予め確立されている仮想通信回線の中か
ら各オペレーションに対しそれぞれ別個の仮想通信回線
を割り当てる。もし仮想通信回線の数が不足する場合
は、必要な分だけ新しい仮想通信回線の確立して不足分
を補う。また、クライアントとサーバ間で確立する仮想
通信回線の数に上限がある場合は、先に処理されている
手続きによる仮想通信回線の使用が全て終了するのを待
って、該仮想通信回線を使用する。サーバ側にあって
は、要求のあった各オペレーションに対しては、スレッ
ドプールから空きスレッドを順次割り当て、スレッドプ
ールが枯渇した場合には、空きスレッドが発生するまで
処理を待つか、あるいは新規スレッドを作成してこれを
割り当てるようにする。

【０１１０】上述の本実施形態４によれば、アプリケー
ション開発者が、ＩＤＬの拡張属性にオペレーションの
処理時間情報を記述するだけで、ＩＤＬ仕様ファイルで
定義されたオペレーションの処理時間特性に適したクラ
イアントスタブあるいはサーバスタブを生成することが
できる。

【０１１１】また、従来のＩＤＬ文法との互換性を維持
することが可能であり、クライアントマルチスレッドア
プリケーションまたはサーバマルチスレッドアプリケー
ションの処理を変更することなく、スタブ形式の変更が
可能である。しかも、この変更は、他のアプリケーショ
ンには影響を及ぼさない。

【０１１２】なお、上述の実施形態１、２および４にお
いて、本発明はマルチスレッドによる並列処理が可能な
サーバクライアントシステムに適用されたが、他の形式
の並列処理が可能なサーバクライアントシステムに適用
してもよい。また、本発明は、上記実施形態１〜４と同
様に全てオブジェクト指向型の遠隔手続き呼出しの処理
にも適用可能である。例えばオブジェクト指向技術の標
準化団体として、ＯＭＧ（ＯｂｊｅｃｔＭａｎａｇｅ
ｍｅｎｔＧｒｏｕｐ）が知られており、オブジェクト
指向版の遠隔手続き呼出しの共通仕様として、ＣＯＲＢ
Ａ（ＣｏｍｍｏｎＯｂｊｅｃｔＲｅｑｕｅｓｔＢ
ｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅ）が知られてい
る。このＯＭＧでは、前述のサーバスタブはスケルトン
と呼ばれている。

【０１１３】

【発明の効果】本発明によれば、現在処理中の手続きの
他に新たな手続きが前記クライアントからサーバに対し
て呼出されたとき、現在処理中の手続きの処理時間に関
する情報に基づいて、新たな手続きの呼出しに用いられ
る仮想通信回線が獲得されるので、現在処理中の手続き
の処理時間に応じて、適切な仮想通信回線を獲得するこ
とができる。

【０１１４】また本発明によれば、前記各手続きの処理
時間に関する情報を含むインタフェース定義言語仕様フ
ァイルを翻訳してクライアントスタブを生成することに
よって、各手続きの処理時間情報を含むテーブルを作成
しているので、ＩＤＬの文法を変更することなく、スタ
ブ内に上記テーブルを容易に作成することができ、結果
的にアプリケーション開発者に対する負荷を軽減するこ
とができる。

【０１１５】さらに本発明によれば、前記テーブルに記
憶されている現在処理中の手続きの中に、長時間グルー
プに分類されている処理時間の手続きがあるとき、長時
間グループに分類された処理時間の手続きによって現在
使用されている仮想通信回線が、前記新たな手続きの処
理用に獲得して共用されるので、この結果、新規に仮想
通信回線を確立できない場合でも、新たな手続きの呼出
しが待ち状態になる頻度を小さくすることができる。ま
た同時に仕様する仮想通信回線の数を減少させることが
でき、ネットワークトラフィックや仮想通信回線の管理
作業を軽減することができる。

【０１１６】また本発明によれば、前記テーブルに記憶
されている現在処理中の手続きの中に長時間グループに
分類されている処理時間の手続きがあり、かつ長時間グ
ループに分類されている処理時間の手続き用に獲得され
ている仮想通信回線が信号伝送中の状態か空き状態であ
るとき、長時間グループに分類されている処理時間の手
続き用に現在使用されている前記仮想通信回線を、前記
新たな手続き用に獲得して共用しているので、同じ仮想
通信回線を共有するオペレーションが増えた場合でも、
オペレーションの実行が過度に遅延するのを防止するこ
とができる。

【０１１７】さらに本発明によれば、サーバに対して今
回実行要求のあった手続きを実行するスレッドを、今回
実行要求のあった手続きの処理時間の情報に基づいて獲
得しているので、その実行要求のあった手続きの処理時
間特性に適したスレッドを獲得することができる。

【０１１８】また本発明によれば、前記各手続きの処理
時間に関する情報を含むインタフェース定義言語仕様フ
ァイルを翻訳してサーバスタブを生成することによっ
て、各手続きの処理時間情報を含むテーブルを作成して
いるので、ＩＤＬの文法を変更することなく、スタブ内
に上記テーブルを容易に作成することができ、結果的に
アプリケーション開発者に対する負荷を軽減することが
できる。

【０１１９】さらに本発明によれば、長時間グループの
処理時間の手続きの実行用のスレッドとしては、新規に
作成されたスレッドを獲得し、短時間グループの処理時
間の手続きの実行用のスレッドとしては、予め作成され
たスレッドを獲得しているので、スレッド作成のオーバ
ヘッドを小さくすることができる。

【０１２０】また本発明によれば、サーバに対して入出
力バスの利用を要求する手続きの処理時間が長時間グル
ープに分類され、前記サーバに対してメモリバスの利用
のみを要求する手続きの処理時間が短時間グループに分
類されるので、簡単な基準により長時間と短時間を確実
かつ容易に分類することができる。

【０１２１】さらに本発明によれば、予め準備された少
なくとも二種類のスタブ生成プロセスの中から、手続き
の処理時間に基づいて、一つのスタブ生成プロセスが選
択され、このスタブ生成プロセスに従ってクライアント
スタブが生成されるので、手続きの処理時間に適したク
ライアントスタブを生成することができる。

【０１２２】また本発明によれば、インタフェース定義
言語仕様ファイルで定義された手続きの中に長時間グル
ープの処理時間の手続きがあると判別されたとき、イン
タフェース定義言語仕様ファイルにより定義された各手
続きの処理時間が長時間グループと短時間グループのど
ちらのグループに分類されたかを表す情報を記憶したテ
ーブルが、クライアントスタブに作成されるので、クラ
イアントによる手続き呼出し時に上記テーブルを参照す
ることにより、例えば適切な仮想回線する獲得すること
が可能になる。

【０１２３】さらに本発明によれば、予め準備された少
なくとも二種類のスタブ生成プロセスの中から、手続き
の処理時間に基づいて、一つのスタブ生成プロセスが選
択され、このスタブ生成プロセスに従ってサーバスタブ
が生成されるので、手続きの処理時間に適したサーバス
タブを生成することができる。

【０１２４】また本発明によれば、インタフェース定義
言語仕様ファイルで定義された手続きの中に長時間グル
ープの処理時間の手続きがあると判別されたとき、イン
タフェース定義言語仕様ファイルにより定義された各手
続きの処理時間が長時間グループと短時間グループのど
ちらのグループに分類されたかを表す情報を記憶したテ
ーブルが、サーバスタブに作成されるので、上記テーブ
ルを参照することにより、例えばクライアントから呼出
された手続きを実行するスレッドとして適切なスレッド
を獲得することが可能になる。

【図面の簡単な説明】

【図１】本発明の実施形態１を示すブロック図である。

【図２】実施形態１の詳細構成を示すブロック図であ
る。

【図３】実施形態１の処理過程を示すフローチャートで
ある。

【図４】実施形態１における仮想通信回線の共用状態を
示す図である。

【図５】本発明の実施形態２を示すブロック図である。

【図６】実施形態２の処理過程を示すフローチャートで
ある。

【図７】実施形態２における仮想通信回線の共用状態を
示す図である。

【図８】本発明の実施形態３を示すブロック図である。

【図９】実施形態３の処理過程を示すブロック図であ
る。

【図１０】本発明の実施形態４の処理過程を示すフロー
チャートである。

【図１１】従来例の概略構成を示すブロック図である。

【図１２】従来例の詳細構成を示すブロック図である。

【符号の説明】

１０１ＩＤＬ仕様ファイル１０２、２０２、３０２ＩＤＬコンパイラ１０３通信ノード（クライアント側）１０４通信ノード（サーバ側）１０５クライアントマルチスレッドアプリケーショ
ン１０６、３０６サーバマルチスレッドアプリケーシ
ョン１０７、２０７クライアントスタブ１０８、３０４サーバスタブ１０９、１１４メッセージ作成装置１０９ａ、１１４ａメッセージ１１０、１１６、３１６メッセージ送受信装置１１１、２１１コネクション管理装置１１２、２１２、３１２オペレーション管理テーブ
ル１１３回線管理テーブル１１５スレッド管理装置１１７スレッドプール１２０ネットワーク

Claims

【特許請求の範囲】

【請求項１】並列処理が行われるクライアントとサー
バとの間で仮想通信回線を介して複数の手続きを呼出し
て実行する手続き呼出しの処理方法において、現在処理中の手続きの他に新たな手続きが前記クライア
ントからサーバに対して呼出されたとき、各手続きの処
理時間に関する情報を対応する手続きに関連付けて記憶
したテーブルから、現在処理中の手続きの処理時間に関
する情報を検索する時間情報検索工程と、該時間情報検索工程で検索された現在処理中の手続きの
処理時間に関する情報に基づいて、前記新たな手続きの
呼出しに用いられる仮想通信回線を獲得する回線獲得工
程と、を含むことを特徴とする手続き呼出しの処理方
法。
【請求項２】前記各手続きの処理時間に関する情報を
インタフェース定義言語の拡張属性として含むインタフ
ェース定義言語仕様ファイルを、翻訳することによりク
ライアントスタブを生成するスタブ生成工程を含み、前記テーブルが前記クライアントスタブに含まれたこと
を特徴とする請求項１記載の手続き呼出しの処理方法。
【請求項３】前記クライアントにより呼出される手続
きの処理時間が、所定の基準に対して長時間であると判
断される長時間グループと短時間であると判断される短
時間グループの何れかに分類されて前記インタフェース
定義言語の拡張属性として前記インタフェース定義言語
仕様ファイルに記述され、前記インタフェース定義言語仕様ファイルにより定義さ
れた各手続きの処理時間が前記長時間グループと前記短
時間グループのどちらのグループに分類されたかを表す
情報が前記テーブルに記憶され、前記回線獲得工程が、前記テーブルに記憶されている現
在処理中の手続きの中に、長時間グループに分類されて
いる処理時間の手続きがあるとき、長時間グループに分
類された処理時間の手続きによって現在使用されている
仮想通信回線を、前記新たな手続きの処理用に獲得して
共用する回線共用工程を含むことを特徴とする請求項１
または２記載の手続き呼出しの処理方法。
【請求項４】前記クライアントにより呼出される手続
きの処理時間が、所定の基準に対して長時間であると判
断される長時間グループと短時間であると判断される短
時間グループの何れかに分類されて前記インタフェース
定義言語の拡張属性としてインタフェース定義言語仕様
ファイルに記述され、前記インタフェース定義言語仕様ファイルにより定義さ
れた各手続きの処理時間が前記長時間グループと前記短
時間グループのどちらのグループに分類されたかを表す
情報が前記テーブルに記憶され、前記回線獲得工程が、前記テーブルに記憶されている現在処理中の手続きの中
に、長時間グループに分類されている処理時間の手続き
があるか否かを判別する第１の工程と、該第１の工程で長時間グループの処理時間の手続きがあ
ると判別されたとき、長時間グループの処理時間の手続
き用に獲得されている仮想通信回線が信号伝送中の状態
か空き状態かを判別する第２の工程と、該第２の工程で仮想通信回線が空き状態であると判別さ
れたとき、長時間グループの処理時間の手続き用に現在
使用されている前記仮想通信回線を、前記新たな手続き
用に獲得して共用する第３の工程と、を含むことを特徴
とする請求項１または２記載の手続き呼出しの処理方
法。
【請求項５】マルチスレッドにより動作するクライア
ントとサーバとの間で仮想通信回線を介して複数の手続
きを呼出して実行する手続き呼出しの処理方法におい
て、前記サーバに対して前記クライアントから手続きの実行
が要求されたとき、前記複数の手続きのそれぞれの処理
時間に関する情報を対応する各手続きに関連付けて記憶
したテーブルから、今回実行要求のあった手続きの処理
時間に関する情報を検索する時間情報検索工程と、今回実行要求のあった手続きを前記サーバで実行するた
めのスレッドを、前記テーブルに記憶された今回実行要
求のあった手続きの処理時間の情報に基づいて獲得する
スレッド獲得工程と、を含むことを特徴とする手続き呼
出しの処理方法。
【請求項６】前記各手続きの処理時間に関する情報を
インタフェース定義言語の拡張属性として含むインタフ
ェース定義言語仕様ファイルを、翻訳することによりサ
ーバスタブを生成する工程を含み、前記テーブルが前記サーバスタブに含まれたことを特徴
とする請求項５記載の手続き呼出しの処理方法。
【請求項７】前記サーバにより実行される手続きの処理
時間が、所定の基準に対して相対的に長時間であると判
断される長時間グループと相対的に短時間であると判断
される短時間グループの何れかに分類されて前記インタ
フェース定義言語の拡張属性として記述され、前記インタフェース定義言語仕様ファイルにより定義さ
れた各手続きの処理時間が前記長時間グループと前記短
時間グループのどちらのグループに分類されたかを表す
情報が前記テーブルに記憶され、前記スレッド獲得工程が、前記サーバに対して手続きの実行が要求されたとき、前
記テーブルに記憶された情報から、今回実行要求のあっ
た手続きの処理時間が長時間グループと短時間グループ
の何れに分類されているかを判別する第１の工程と、該第１の工程で処理時間が短時間グループに分類されて
いると判別されたとき、前記サーバ用に予め作成された
スレッドを、今回要求のあった手続きを実行するための
スレッドとして獲得する第２の工程と、前記第１の工程で処理時間が長時間グループに分類され
ていると判別されたとき、新規にスレッドを作成し、該
新規スレッドを、今回要求のあった手続きを実行するた
めのスレッドとして獲得する第３の工程と、を含むこと
を特徴とする請求項５または６記載の手続き呼出しの処
理方法。
【請求項８】前記サーバがメモリバスと入出力バスを
備えたコンピュータからなり、前記所定の基準が、各手
続きの前記入出力バスと前記メモリバスの利用形態に基
づくものであり、前記サーバに対して前記入出力バスの
利用を必要とする手続きの処理時間が長時間グループに
分類され、前記サーバに対して前記メモリバスの利用の
みを必要とする手続きの処理時間が短時間グループに分
類されることを特徴とする請求項３、４および７の何れ
か一つに記載の手続き呼出しの処理方法。
【請求項９】クライアントとサーバとの間で手続き呼
出しを可能にするインタフェース定義言語仕様ファイル
を翻訳することによって、クライアントスタブを生成す
るスタブ生成方法において、前記インタフェース定義言語仕様ファイルが、前記クラ
イアントにより呼出される手続きの処理時間に関する情
報をインタフェース定義言語の拡張属性として含むファ
イルからなり、前記スタブ生成方法が、前記インタフェース定義言語仕様ファイルから、該イン
タフェース定義言語仕様ファイルで定義されている手続
きの処理時間を認識する処理時間認識工程と、予め準備された互いに異なる少なくとも二つのスタブ生
成プロセスの中から、前記処理時間認識工程で認識され
た処理時間に基づいて、一つのスタブ生成プロセスを選
択するプロセス選択工程と、を含み、前記クライアントスタブが、前記プロセス選択工程で選
択されたスタブ生成プロセスに従って生成されることを
特徴とするスタブ生成方法。
【請求項１０】前記クライアントにより呼出される手
続きの処理時間が、所定の基準に対して長時間であると
判断される長時間グループと短時間であると判断される
短時間グループの何れかに分類されて前記インタフェー
ス定義言語の拡張属性として前記インタフェース定義言
語仕様ファイルに記述され、前記処理時間認識工程が、インターフェース定義言語仕
様ファイルに定義されている手続きの中に、長時間グル
ープに分類された処理時間の手続きがあるか否かを判別
する時間グループ判別工程を含み、前記スタブ生成方法が、前記時間グループ判別工程で長
時間グループの処理時間の手続きがあると判別されたと
き、前記インタフェース定義言語仕様ファイルにより定
義された各手続きの処理時間が前記長時間グループと前
記短時間グループのどちらのグループに分類されたかを
表す情報を記憶したテーブルをクライアントスタブに作
成するテーブル作成工程を含むことを特徴とする請求項
９記載のスタブ生成方法。
【請求項１１】クライアントとサーバとの間で遠隔手
続き呼出しを可能にするインタフェース定義言語仕様フ
ァイルを翻訳することによって、サーバスタブを生成す
るスタブ生成方法において、前記インタフェース定義言語仕様ファイルが、前記サー
バにより実行される手続きの処理時間に関する情報をイ
ンタフェース定義言語の拡張属性として含むファイルか
らなり、前記スタブ生成方法が、前記インタフェース定義言語仕様ファイルから、該イン
タフェース定義言語仕様ファイルで定義されている手続
きの処理時間を認識する処理時間認識工程と、予め準備された互いに異なる少なくとも二つのスタブ生
成プロセスの中から、前記処理時間認識工程で認識され
た処理時間に基づいて、一つのスタブ生成プロセスを選
択するプロセス選択工程と、を含み、前記サーバスタブが、前記プロセス選択工程で選択され
たスタブ生成プロセスに従って生成されることを特徴と
するスタブ生成方法。
【請求項１２】前記サーバにより実行される手続きの
処理時間が、所定の基準に対して長時間であると判断さ
れる長時間グループと短時間であると判断される短時間
グループの何れかに分類されて前記インタフェース定義
言語の拡張属性として前記インタフェース定義言語仕様
ファイルに記述され、前記処理時間認識工程が、インターフェース定義言語仕
様ファイルに定義されている手続きの中に、長時間グル
ープに分類された処理時間の手続きがあるか否かを判別
する時間グループ判別工程を含み、前記スタブ生成方法が、前記時間グループ判別工程で長
時間グループの処理時間の手続きがあると判別されたと
き、前記インタフェース定義言語仕様ファイルにより定
義された各手続きの処理時間が前記長時間グループと前
記短時間グループのどちらのグループに分類されたかを
表す情報を記憶したテーブルをサーバスタブに作成する
テーブル作成工程を含むことを特徴とする請求項１１記
載のスタブ生成方法。