JP2003084992A - クライアントサーバ間のｒｐｃ接続プログラム - Google Patents

Abstract

(57)【要約】 【課題】 従来、クライアントサーバ間のＲＰＣ接続に
おいては、ＲＰＣクライアント業務プログラム内からの
呼出しによってＲＰＣサーバ業務プログラムの用意され
たサービス関数が実行されるが、ＲＰＣサーバ業務プロ
グラムにおいて、呼出し元のクライアントを認識でき
ず、クライアントに応じた処理を行うサーバ業務サービ
ス関数を記述することができない、という課題があっ
た。 【解決手段】 呼出し元のクライアントを認識し、当該
クライアント識別子をＲＰＣサーバ業務プログラムが参
照可能な変数領域に格納する段階をコンピュータに実行
させるＲＰＣサーバ・スタブプログラムによって、ＲＰ
Ｃサーバ業務プログラム内に、クライアントに応じた処
理を行うサーバ業務関数を記述することが可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアントサー
バ間のリモートプロシージャ呼び出し（ＲＰＣ）技術に
係り、特に、クライアント属性によってサービス・ルー
チンの動作内容を変化させる必要のある場合に便利なプ
ロシージャ呼び出し方式に関する。

【０００２】

【従来の技術】複数計算機間をネットワークで接続する
分散コンピューティング環境（ＤＣＥ）技術の進歩によ
り、多くの企業業務システムがクライアントサーバ型の
システム構成をとっている。本明細書ではアプリケーシ
ョン業務システムを構成するクライアント上のアプリケ
ーション業務プログラムをクライアント業務プログラム
と呼び、アプリケーション業務システムを構成するサー
バ上のアプリケーション業務プログラムをサーバ業務プ
ログラムと呼ぶ。

【０００３】クライアントサーバ間の通信方法は、従
来、プロセスに対して仮想的な通信機構である「ソケッ
ト」 を与え、ソケット同士が通信を行うことでプロセス
間のデータの送受信を行なうソケット通信によるものが
主流であった。しかし、この方法ではクライアント、サ
ーバの双方において、各アプリケーションプロセスプロ
グラムで、相手アドレスやポート番号を指定して複雑な
コネクションの開設／開放を行う記述が必要であり、ク
ライアント業務プログラムやサーバ業務プログラムの作
成、保守に高度知識を必要とした。

【０００４】一方、近年、ＤＣＥ技術の一つとしてＲｅ
ｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ（リモートプ
ロシージャ呼び出し、以下ＲＰＣと記す）プロトコルが
開発された。これはローカルなルーチンと同等なインタ
フェースでリモートに存在するルーチンを実行させる通
信プロトコルである。すなわち、ＲＰＣではクライアン
トアプリケーションプログラムから、特定サーバを指定
することなく、サービス関数名を指定することによって
サーバ上のサービスを呼び出すことができるので、クラ
イアント業務プログラムの作成、保守効率が向上する。
最近のプログラミング環境であるＣＯＲＢＡ（Common O
bject Request Broker Architecture ：分散システム
で、オブジェクト同士がメッセージを交換するための標
準仕様) 、ＲＭＩ（Remote Method Invocation：分散ネ
ットワーク環境でのオブジェクトの遠隔呼び出し機
能）、ＤＣＯＭ（Distributed Component Object Mode
l：分散ネットワーク環境でＪａｖａアプレットやＡｃ
ｔｉｖｅＸコントロールなどのＣＯＭオブジェクトを利
用できるようにする機能）などもＲＰＣプロトコルをサ
ポートしている。

【０００５】本明細書ではＲＰＣ接続方法を用いたシス
テムのクライアントをＲＰＣクライアント、サーバをＲ
ＰＣサーバと呼ぶ。また、ＲＰＣ接続方法を用いたアプ
リケーション業務システムを構成するＲＰＣクライアン
ト上のアプリケーション業務プログラムをＲＰＣクライ
アント業務プログラムと呼び、アプリケーション業務シ
ステムを構成するＲＰＣサーバ上のアプリケーション業
務プログラムをＲＰＣサーバ業務プログラムと呼ぶ。

【０００６】クライアントサーバ間のＲＰＣ接続の一般
的形態例を図５により説明する。図に示す如く、業務サ
ービスを提供するＲＰＣサーバ業務プログラム５と、こ
れを利用するＲＰＣクライアント業務プログラム１と、
ＲＰＣクライアント業務プログラム１からＲＰＣサーバ
業務プログラム５を呼び出す処理を通信データに置き換
えるＲＰＣクライアント・スタブプログラム２と、通信
で送られたデータに応じてＲＰＣサーバ業務プログラム
５を呼び出すＲＰＣサーバ・スタブプログラム４' と、
通信データを送受信する通信制御部３とによってＲＰＣ
通信が行われる。このようなＲＰＣ実現のための二つの
スタブは、システム設計者がＲＰＣコンパイラにインタ
ーフェース仕様（ＩＤＬソース）を与えてコンパイルす
ることにより生成され、アプリケーションプログラムと
コンパイラ・リンカによってリンクされる。

【０００７】図５の構成において、ＲＰＣサーバ業務プ
ログラム５内には種々の業務サービスに対応するJ 個の
サービス関数FNj(),j=1,2,...,J が実装されている。Ｒ
ＰＣクライアント業務プログラム１はサービス要求記
述、call FNk(Ak)によってk 番目のサービス関数 FNk(a
rg) を引数Akを与えて呼び出している。このサービス要
求がＲＰＣサーバ業務プログラム５を実行させる過程を
図７で説明する。

【０００８】ステップＳ71でＲＰＣクライアント業務プ
ログラム１がcall FNk(Ak)記述でサービス要求を行う
と、ＲＰＣクライアント・スタブプログラム２のCLS 呼
出し共通部が擬似的にこの呼出しを受け、ステップＳ72
でサービス関数名FNk を調べ、これがローカルな関数か
リモート処理のものかを判定し、FN/CLSテーブル（関数
名変換）をサーチして対応するCLS 個別部k を呼び出
す。k 番目の個別部、CLS個別部k はステップＳ73で関
数 CLS-FNk(Ak)を実行し、呼び出す処理をあらかじめ決
められた機能番号に変換し、引数の型に基づいてあらか
じめ決められた変換処理を使って引数を一次元の通信デ
ータストリームに変換し、CLS 接続共通部に通信を依頼
する。CLS 接続共通部はステップＳ74でCLS-FN/SVS-FN
テーブルをサーチし、ＲＰＣサーバ・スタブプログラム
４' 内のSVS 個別部k を指定して、通信データストリー
ムを送信する。

【０００９】ＲＰＣサーバ・スタブプログラム４' のSV
S 呼出し共通部は、図示しないが初期立ち上げ時にSVS
接続共通部を介してＲＰＣクライアント・スタブプログ
ラム２からの要求待機体制を取っているものとする。こ
のもとで、SVS 接続共通部はステップＳ75でＲＰＣクラ
イアント・スタブプログラム２からの通信データストリ
ームを受信し、その宛て先であるSVS 個別部k を起動す
る。SVS 個別部k はステップＳ76で受信した通信データ
ストリームから機能番号を抽出し、機能番号に割り当て
られたルーチンの引数の型に基づいてあらかじめ決めら
れた変換処理を使って引数を復元し、元のサービス要求
call FNk(Ak)を復元して起動する。これによってＲＰＣ
サーバ業務プログラム５内のサービス関数 FNk(arg) が
呼び出され、ステップＳ77で実行される。以上のよう
に、CLS 個別部k およびSVS 個別部k はサービス関数FN
j() の機能番号及び引数の型に依存するために、ＲＰＣ
コンパイラによって個別に用意されている。

【００１０】このように、従来のＲＰＣ接続方法におい
てはＲＰＣクライアント業務プログラム１はサービス関
数FNj() がどのサーバ上に存在するかをまったく意識す
ることなく呼び出すことができ、また、同様に、ＲＰＣ
サーバ業務プログラム５のサービス関数FNk() 実行結果
はＲＰＣサーバ・スタブプログラム４' のSVS 個別部k
に戻り値として返され、ＲＰＣクライアント・スタブプ
ログラム２を経由してＲＰＣクライアント業務プログラ
ム１に戻されるので、ＲＰＣサーバ業務プログラム５は
いずれのＲＰＣクライアントにサービス応答を返したか
を意識することがない。

【００１１】図６は以上の動作をダイヤグラムで示した
ものである。図に示す如く、従来のクライアントサーバ
間のＲＰＣ接続動作においては、ＲＰＣクライアント業
務プログラム１からのサービス関数FNk(Ak) 要求により
ＲＰＣクライアント・スタブプログラム２が通信制御部
３を経てＲＰＣサーバ・スタブプログラム４' にconnec
t し、ＲＰＣサーバ・スタブプログラム４' によってＲ
ＰＣサーバ業務プログラム５内のサービス関数FNk(Ak)
がcallされ、その戻り値はＲＰＣサーバ・スタブプログ
ラム４' にresponseされ、通信制御部３を経てＲＰＣク
ライアント・スタブプログラム２に返されるとともにコ
ネクションの開放(release) が依頼され、最終的にＲＰ
Ｃクライアント業務プログラム１にサービス関数FNk(A
k) の応答が伝えられる。

【００１２】このようなＲＰＣ接続方法は業務アプリケ
ーションプログラム上で通信処理関係の面倒な記述が不
要であり、異なるOS間、言語間でも接続性があることか
ら、多くのクライアントサーバ型業務システム構築上有
利である。しかし、サーバ側で同一サービスであっても
クライアント毎にサービス内容を変化させたい場合には
問題が生ずる。すなわち、従来のＲＰＣ接続方法にあっ
ては、ＲＰＣサーバ業務プログラム５はＲＰＣサーバ・
スタブプログラム４' によって起動される時に元のクラ
イアントを識別する情報を取得することができないの
で、サーバ側でクライアント毎にサービスを制御した
り、サービスの履歴をクライアント毎に管理するＲＰＣ
サーバ業務プログラムを作成することができない、とい
う問題が発生する。

【００１３】このような問題は特に既開発のサービス関
数の呼出しインタフェースを変えないで業務システムを
従来のソケット通信型からＲＰＣ接続方法に移行する場
合に顕著である。図８のアプリケーション業務システム
の場合によってこれを説明する。図８は資産管理システ
ムの一部機能を示す。資産管理システムはインターネッ
ト環境における巨大企業業務システムの稼働管理、資産
管理を統合的に行うシステムで、図８に示すのはその資
産管理の一部である『資源の配布』業務システムであ
る。ここに『資源』とは当該企業業務システムで使用す
る業務プログラムやシステムプログラムおよび各種デー
タファイルなどを指す。

【００１４】資産管理システム中の資源の配布サーバは
これら資源を企業各事業所の必要なクライアントや中間
サーバに自動配布展開インストールするサービス実体で
ある。資産管理システム中の資源の配布クライアントは
資源の配布操作端末として、操作者が資源の配布業務の
ために操作する。資源の配布業務のサービス種類として
は例えば以下のようなものがある。 （１）配布先システム構成登録−−（システム構成構
築） （２）配布資源の格納登録−−−−（資源の登録） （３）配布スケジュール作成−−−（配布の計画） （４）資源の配布実行−−−−−−−（資源の配布） （５）配布状況表示−−−−−−−（状況表示） 上記括弧内に示した関数名で必要なサービスルーチンが
資産管理システム資源の配布サーバに備えられ、資産管
理システム資源の配布クライアントからのサービス要求
に応じて起動実行される仕組みである。

【００１５】現在この資産管理システム資源の配布シス
テムは、クライアントサーバ間の通信をソケット型通信
で行っているとする。上記サービスの円滑な運用と障害
時への対応のために、資産管理システム資源の配布サー
バではサービス要求の受付応答の履歴をクライアント毎
に区別して蓄積している。ところが、このようなシステ
ムを、より保守効率の高いＲＰＣ接続方法によって再構
築しようとすると、ＲＰＣクライアントは容易に移行で
きるが、ＲＰＣサーバの側のＲＰＣサーバ業務プログラ
ムでは、先に述べた如くクライアントを識別することが
できないため、クライアント毎の要求応答履歴をとるこ
とができない。また、資産管理システム中の資源の配布
クライアントは、運用管理者が専用で使用する運用管理
端末と、資源ソフト開発者が開発資源を登録する開発者
用端末とがあり、両者の種類に応じて処理優先度を変え
ている。このようなことも従来のＲＰＣ接続方法を採用
してシステム移行した場合には実現不可能となる。

【００１６】

【発明が解決しようとする課題】このように従来、クラ
イアントサーバ間を保守性の優れたＲＰＣプロトコルで
接続した場合には、ＲＰＣクライアント業務プログラム
内からの呼出しによってＲＰＣサーバ業務プログラムの
用意されたサービス関数を実行しつつ、ＲＰＣサーバ業
務プログラムにおいて、呼出し元のクライアントをアド
レスによって認識して、クライアントに応じた処理を行
うサーバ業務サービス関数を記述することができない、
という課題があった。

【００１７】

【課題を解決するための手段】上記課題は、図１に示す
如く、ＲＰＣクライアント業務プログラム１からのサー
ビス要求を受けて、当該ＲＰＣクライアントを識別する
アドレスpeer＿addrを取得し、これをＲＰＣサーバ業務
プログラム５に参照させる機能をコンピュータに実現さ
せるＲＰＣサーバ・スタブプログラム４を提供すること
により解決される。

【００１８】すなわち、図１のＲＰＣクライアント業務
プログラム１のサービス要求FNk(Ak) を受けたＲＰＣク
ライアント・スタブプログラム２は通信制御部３を経て
ＲＰＣサーバ・スタブプログラム４にconnect 依頼をす
る。ＲＰＣクライアント・スタブプログラム２からコネ
クションを受け、要求データストリームを受信したＲＰ
Ｃサーバ・スタブプログラム４は、ＲＰＣサーバ業務プ
ログラム５内のサービス関数FNk(Ak) を呼び出す他に、
図１にpeer＿addrと記した変数領域に当該要求元クライ
アントのIPアドレスなどを格納する。peer＿addrはＲＰ
Ｃサーバ業務プログラム５から参照可能な構造体であ
る。これによって、ＲＰＣサーバ業務プログラム５内に
記述する任意のサービス関数でpeer＿addrを参照するプ
ログラムを記述することができ、クライアントに応じた
処理を行うサーバ業務サービス関数の作成が可能とな
る。

【００１９】例えば、図１の実施例ではcall with peer
＿addrと示す如く、ＲＰＣサーバ・スタブプログラム４
はＲＰＣサーバ業務プログラム５内のサービス履歴収集
ルーチンをpeer＿addrを引数として呼び出す構造として
いる。これによって、ＲＰＣサーバ業務プログラム５内
のサービス履歴収集ルーチンはクライアントに応じた処
理を行うことが可能であり、クライアント毎のサービス
履歴収集が可能である。

【００２０】また、図１の実施例ではＲＰＣサーバ業務
プログラム５内のサービス関数 FNk(arg) はrequest w
ith peer＿addrと示す如く、ＲＰＣサーバ業務プログラ
ム５内の受付優先度処理ルーチンに対して、peer＿addr
を引数として処理要求の受付を報告し、その処理にはい
る許可を待つ。受付優先度処理ルーチンはpeer＿addrで
渡されるクライアントアドレスに応じた受付優先度処理
を行うことができる。サービス関数 FNk(arg) は受付優
先度処理ルーチンからの許可（OK応答）を得てサービス
処理を開始する。サービス終了時にはサービス履歴収集
ルーチンに返却時刻が通知され、ＲＰＣサーバ・スタブ
プログラム４にresponseされ、通信制御部３を経てＲＰ
Ｃクライアント・スタブプログラム２にコネクションの
開放(release) が依頼され、サービス関数FNk(Ak) 実行
結果の戻り値がある場合には最終的にＲＰＣクライアン
ト業務プログラム１にサービス関数FNk(Ak) の応答が伝
えられる。

【００２１】

【発明の実施の形態】本発明のクライアントサーバ間の
ＲＰＣ接続の実施例を図１〜図８により説明する。な
お、本発明におけるコンピュータ処理は、コンピュータ
プログラムにより当該コンピュータの主記憶装置上で実
行されるが、このコンピュータプログラムの提供形態
は、当該コンピュータに接続された補助記憶装置をはじ
め、フロッピー（登録商標）ディスクやＣＤ−ＲＯＭ等
の可搬型記憶装置やネットワーク接続された他のコンピ
ュータの主記憶装置及び補助記憶装置等の各記録媒体に
格納されて提供されるもので、このコンピュータプログ
ラムの実行に際しては、当該コンピュータの主記憶装置
上にローディングされ実行されるものである。

【００２２】図２は本発明のＲＰＣサービス要求伝播動
作フローの例を示すものである。ステップＳ21でＲＰＣ
クライアント業務プログラム１はcall FNk(Ak)記述でサ
ービス要求を行うと、ＲＰＣクライアント・スタブプロ
グラム２のCLS 呼出し共通部が擬似的にこの呼出しを受
け、ステップＳ22でサービス関数名FNk を調べ、これが
ローカルな関数かリモート処理のものかを判定し、FN/C
LSテーブル（関数名変換）をサーチして対応するCLS 個
別部k を呼び出す。k 番目の個別部、CLS 個別部k はス
テップＳ23で関数 CLS-FNk(Ak)を実行し、呼び出す処理
をあらかじめ決められた機能番号に変換し、引数の型に
基づいてあらかじめ決められた変換処理を使って引数を
一次元の通信データストリームに変換し、CLS 接続共通
部に通信を依頼する。CLS 接続共通部はステップＳ24で
CLS-FN/SVS-FN テーブルをサーチし、ＲＰＣサーバ・ス
タブプログラム４内のSVS 個別部k を指定して、通信デ
ータストリームを送信する。

【００２３】ＲＰＣサーバ・スタブプログラム４のSVS
呼出し共通部は、図示しないが初期立ち上げ時にSVS 接
続共通部を介してＲＰＣクライアント・スタブプログラ
ム２からの要求待機体制を取っているものとする。この
もとで、SVS 接続共通部はステップＳ25でＲＰＣクライ
アント・スタブプログラム２からの通信データストリー
ムを受信し、その宛て先であるSVS 個別部k を起動す
る。SVS 個別部k はステップＳ26で受信した通信データ
ストリームから機能番号を抽出し、機能番号に割り当て
られたルーチンの引数の型に基づいてあらかじめ決めら
れた変換処理を使って引数を復元し、元のサービス要求
call FNk(Ak)を復元して起動する。

【００２４】次にＲＰＣサーバ・スタブプログラム４の
SVS 個別部k はステップＳ27において改めてsocket()、
listen()を発行し、接続元ＩＰアドレスを含むソケット
情報を獲得し、これをＲＰＣサーバ業務プログラム５の
全体にpublic設定された変数領域である構造体peer＿ad
drに格納する。これによって、ＲＰＣサーバ業務プログ
ラム５は必要に応じて要求元クライアントのアドレスを
取得することができる。本実施例では、ステップＳ27で
これに続き、ＲＰＣサーバ業務プログラム５内のサービ
ス履歴収集ルーチンであるKlaaLog.output()関数を呼び
出す。このとき、引数の一つとしてpeer＿addrが渡され
る。

【００２５】先のステップＳ26のcall FNk(Ak)によりＲ
ＰＣサーバ業務プログラム５のサービス関数 FNk(arg)
がステップＳ28で起動され実行される。また、先のステ
ップＳ27のKlaaLog.output()関数呼出しにより、ＲＰＣ
サーバ業務プログラム５のサービス履歴収集ルーチンが
ステップＳ29で起動され実行される。図３はサービス履
歴収集ルーチンが蓄積する受付処理履歴レコードのデー
タ構造例を示す。本実施例ではレコードは 8つの項目か
らなる。項番１『インシデンス番号（年月日＋追番）』
はこの日のサービス履歴収集ルーチンが受け付けた全要
求に追番を発行するものである。項番２『受付時刻タイ
ムスタンプ』は図１に受付時刻と記したタイミングの時
刻を記入する。項番３『返却時刻タイムスタンプ』は図
１に返却時刻と記したタイミングの時刻を記入する。項
番４『要求クライアントＩＰアドレス』および項番５
『要求クライアントＭＡＣアドレス』はpeer＿addrによ
って取得したＩＰアドレスおよびＭＡＣアドレスを記入
する。項番６『呼出しスタブ名（サービス種類）』は図
２におけるＲＰＣサーバ・スタブプログラム４のSVS 個
別部k の関数名すなわち『SVS-FNk 』を記入する。これ
はＲＰＣサーバ業務プログラム５のサービス関数 FNk(a
rg) に対応するもので、サービス種類を示すものであ
る。項番７『要求識別子（スタブ名＋追番）』は項番１
『インシデンス番号（年月日＋追番）』とともに本レコ
ードを識別するもので、項番６『呼出しスタブ名（サー
ビス種類）』毎に追番を付して記入する。

【００２６】次に受付優先度処理ルーチンの動作例を図
１および図４によって説明する。図１の実施例ではＲＰ
Ｃサーバ業務プログラム５内の起動されたサービス関数
FNk(arg) は多重処理が可能なプロセスであり、処理実
行中に他のクライアントからの処理要求を受け付けるこ
とができるものとしている。よってサービス関数 FNk(a
rg) はＲＰＣサーバ・スタブプログラム４からの起動要
求毎に図１にrequestwith peer＿addrで示すように受付
優先度処理ルーチンに実行許可を求める。

【００２７】図４は受付優先度処理ルーチンが使用する
受付制御ブロックのデータ構造例を示すものである。受
付優先度処理ルーチンはrequest with peer＿addrを図
４(b) に示す受付制御ブロックにつなぐ。このブロック
は要求サービス種類毎に、かつ優先度毎に決められた受
付容量をもつ待ち行列ブロックである。図４(b) の例で
は優先度１の容量は１０、優先度k の容量は６と設定さ
れている。受付優先度処理ルーチンはrequest with pe
er＿addrの優先度を判定するために図４(a) に示すＲＰ
Ｃクライアントのグループ分けテーブルを参照する。Ｒ
ＰＣクライアントはその設置場所、割りあて使用者に応
じて運用管理者用、開発者用などとカストマイズされて
おり、それぞれの属性に応じて優先度を伴ったグループ
分けがなされている。本テーブルは各グループ毎に所属
するＲＰＣクライアントのＩＰアドレスが登録されたリ
ストである。

【００２８】受付優先度処理ルーチンはrequest with
peer＿addrからpeer＿addrを取り出し、図４(a) グルー
プ分けテーブルを参照して優先度を決定し、一方要求元
スタブ名SVS-FNk により図４(b) の対応するサービス名
を決定し、これらで決まる待ち行列にrequest with pe
er＿addrをスタックする。図４(b) の例では『資源の登
録』サービス要求において、優先度k の要求が1 、2 、
3 の順序でスタックされた後、優先度1 の要求が４番目
に到着したことを示している。この時点で『資源の登
録』サービス関数が 1番目の要求に対する処理を実行し
終えたとすると、サービス履歴収集ルーチンは返却時刻
を受け取り、受付優先度処理ルーチンに要求１の終了を
伝える。受付優先度処理ルーチンは、次に要求２より優
先度の高い要求４を指定して『資源の登録』サービス関
数に処理実行許可を与える。

【００２９】このようにしてＲＰＣサーバ業務プログラ
ム５は要求クライアントを識別することにより、クライ
アント属性やサービス種類に応じた処理を行うことがで
きる。なお、図２の実施例ではＲＰＣサーバ・スタブプ
ログラム４のSVS 個別部k 中で要求クライアントの識別
情報を取得する場合を示したが、SVS 呼出し共通部やSV
S 接続共通部においてこれを行う場合も考えられる。ま
た、図４の実施例では優先度がＲＰＣクライアントのＩ
Ｐアドレスによって一意に決定し、待ち行列容量が優先
度によって一意に決定する場合を示したが、サービス種
類によってこれらをさらに変化させることも可能なこと
はいうまでもない。

【００３０】（付記１） ＲＰＣクライアント業務プロ
グラムとＲＰＣクライアント・スタブプログラムとを備
えたＲＰＣクライアントと、ＲＰＣサーバ業務プログラ
ムとＲＰＣサーバ・スタブプログラムとを備えたＲＰＣ
サーバとをネットワークを介して接続し、ＲＰＣプロト
コルによって通信を行うクライアントサーバ間のＲＰＣ
接続機能を実現させるプログラムであって、ＲＰＣクラ
イアント業務プログラムからのサービス要求を受けたＲ
ＰＣサーバ業務プログラムが当該ＲＰＣクライアントを
識別するアドレスをＲＰＣサーバ・スタブプログラムを
通じて取得する段階をコンピュータに実行させるクライ
アントサーバ間のＲＰＣ接続プログラム。

【００３１】（付記２） さらに、ＲＰＣクライアント
からのサービス要求をＲＰＣサーバが受付処理をした履
歴をＲＰＣクライアント毎に区別して記録する段階をコ
ンピュータに実行させることを特徴とする付記１記載の
クライアントサーバ間のＲＰＣ接続プログラム。 （付記３） さらに、ＲＰＣクライアントからのサービ
ス要求をＲＰＣクライアント毎に事前設定された受付容
量に基づいて同時受付処理を行う段階をコンピュータに
実行させることを特徴とする付記１記載のクライアント
サーバ間のＲＰＣ接続プログラム。

【００３２】（付記４） さらに、ＲＰＣクライアント
からのサービス要求をＲＰＣクライアント毎に事前設定
された処理優先度に基づいて同時受付処理を行う段階を
コンピュータに実行させることを特徴とする付記１記載
のクライアントサーバ間のＲＰＣ接続プログラム。 （付記５） ＲＰＣクライアント業務プログラムからの
サービス要求を受けて、当該ＲＰＣクライアントを識別
するアドレスを取得し、これをＲＰＣサーバ業務プログ
ラムに参照させる機能をコンピュータに実現させるＲＰ
Ｃサーバ・スタブプログラム。

【００３３】（付記６） 付記５記載のプログラムを記
録したコンピュータ読み取り可能な記録媒体。 （付記７） ＲＰＣクライアント業務プログラムとＲＰ
Ｃクライアント・スタブプログラムとを備えたＲＰＣク
ライアントと、ＲＰＣサーバ業務プログラムとＲＰＣサ
ーバ・スタブプログラムとを備えたＲＰＣサーバとをネ
ットワークを介して接続し、ＲＰＣプロトコルによって
通信を行うクライアントサーバ間のＲＰＣ接続方法であ
って、ＲＰＣクライアント業務プログラムからのサービ
ス要求を受けたＲＰＣサーバ業務プログラムが当該ＲＰ
Ｃクライアントを識別するアドレスをＲＰＣサーバ・ス
タブプログラムを通じて取得する段階を有することを特
徴とするクライアントサーバ間のＲＰＣ接続方法。

【００３４】（付記８） 付記１記載のプログラムを記
録したコンピュータ読み取り可能な記録媒体。

【００３５】

【発明の効果】以上の説明から明らかなように、本発明
によれば、クライアントサーバ間を保守性の優れたＲＰ
Ｃプロトコルで接続し、ＲＰＣクライアント業務プログ
ラム内からの呼出しによってＲＰＣサーバ業務プログラ
ムの用意されたサービス関数を実行しつつ、ＲＰＣサー
バ業務プログラムにおいて、呼出し元のクライアントを
アドレスによって認識して、クライアントに応じた処理
を行うサーバ業務サービス関数をも記述することができ
る、という効果がある。

【図面の簡単な説明】

【図１】本発明のクライアントサーバ間のＲＰＣ接続動
作ダイヤグラム例

【図２】本発明のＲＰＣサービス要求伝播動作フロー例

【図３】受付処理履歴レコードのデータ構造例

【図４】受付制御ブロックのデータ構造例

【図５】クライアントサーバ間のＲＰＣ接続の一般的形
態例

【図６】従来のクライアントサーバ間のＲＰＣ接続動作
ダイヤグラム例

【図７】従来のＲＰＣサービス要求伝播動作フロー例

【図８】アプリケーション業務システムの構成例

【符号の説明】

１ ＲＰＣクライアント業務プログラム ２ ＲＰＣクライアント・スタブプログラム ３ 通信制御部 ４ 本発明のＲＰＣサーバ・スタブプログラム ４' 従来のＲＰＣサーバ・スタブプログラム ５ ＲＰＣサーバ業務プログラム

フロントページの続き Ｆターム(参考） 5B089 GA11 GA21 GB01 JA35 JB10 KA04 KB06 KB09 KB10 KC05 KC14 MC03 5B098 AA10 GA01 GC01 GC03

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ＲＰＣクライアント業務プログラムとＲ
   ＰＣクライアント・スタブプログラムとを備えたＲＰＣ
   クライアントと、ＲＰＣサーバ業務プログラムとＲＰＣ
   サーバ・スタブプログラムとを備えたＲＰＣサーバとを
   ネットワークを介して接続し、ＲＰＣプロトコルによっ
   て通信を行うクライアントサーバ間のＲＰＣ接続機能を
   実現させるプログラムであって、 ＲＰＣクライアント業務プログラムからのサービス要求
   を受けたＲＰＣサーバ業務プログラムが当該ＲＰＣクラ
   イアントを識別するアドレスをＲＰＣサーバ・スタブプ
   ログラムを通じて取得する段階をコンピュータに実行さ
   せるクライアントサーバ間のＲＰＣ接続プログラム。
2. 【請求項２】 さらに、ＲＰＣクライアントからのサー
   ビス要求をＲＰＣサーバが受付処理をした履歴をＲＰＣ
   クライアント毎に区別して記録する段階をコンピュータ
   に実行させることを特徴とする請求項１記載のクライア
   ントサーバ間のＲＰＣ接続プログラム。
3. 【請求項３】 さらに、ＲＰＣクライアントからのサー
   ビス要求をＲＰＣクライアント毎に事前設定された受付
   容量に基づいて同時受付処理を行う段階をコンピュータ
   に実行させることを特徴とする請求項１記載のクライア
   ントサーバ間のＲＰＣ接続プログラム。
4. 【請求項４】 さらに、ＲＰＣクライアントからのサー
   ビス要求をＲＰＣクライアント毎に事前設定された処理
   優先度に基づいて同時受付処理を行う段階をコンピュー
   タに実行させることを特徴とする請求項１記載のクライ
   アントサーバ間のＲＰＣ接続プログラム。
5. 【請求項５】 ＲＰＣクライアント業務プログラムから
   のサービス要求を受けて、当該ＲＰＣクライアントを識
   別するアドレスを取得し、これをＲＰＣサーバ業務プロ
   グラムに参照させる機能をコンピュータに実現させるＲ
   ＰＣサーバ・スタブプログラム。