JPH04107741A - Ｒｐｃにおけるサービスプロシージャの外出し方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 この発明は、ＲＰ　Ｃ（Ｒｅｍｏｔｅ　Ｐｒｏｃｅｄｕ
ｒｅ　Ｃａ１ｌ）機能を持つコンピュータにおいて、Ｒ
ＰＣを使用したプログラム作成、及びその後のプログラ
ム改良に関するものである。

〔従来の技術〕

ＲＰＣプログラムは、大きく分けてクライアント、サー
バの両プログラムから構成される。

前記サーバ側の工つのプログラムは、自分自身のプログ
ラム番号をポート・マツプ（ｐｏｒｔ　ｍａｐ）という
ＲＰＣサーバプログラムに関する情報を持つプログラム
に登録し、１つのプログラム番号に対し、複数のプロシ
ージャ番号（サービスプロシージャ）を持つ。

一方、クライアント側のプログラムは、サービスを受け
たいサーへのプログラム番号を指定して、該プログラム
番号を上記ポート・マツプに問い合わせ、指定のプログ
ラムが存在すると判明したならば、更に、そのプログラ
ム番号に対するプロシージャを指定し、サービス要求を
出力する。

サーバ側の各サービスプロシージャは、タライアンド側
プログラムからのサービス要求を受けて実際のサービス
を実行するための処理を記述している必要がある。

現在のＲＰＣでは、ＲＰＣを使用した新しいサービスを
追加するためには、サーバ側で１つ新しいプログラムを
作成する必要がある。これは、各サービスプロシージャ
はサーバ側プログラム作成時にプログラム中に既に組み
込まれている必要があるためである。

また、サーバ側で新しいプログラムを作成し、それをポ
ート・マツプに登録するためには、そのプログラムは常
に動作中である必要がある。

〔発明が解決しようとする課題〕

従来のＲＰＣの機構では、上述のようにサービスプロシ
ージャの追加は常に新しいサーバ側プログラムの作成を
意味し、また、ポート・マツプに対する登録はサーバ側
プログラムを動作中にする必要があるので、より多くの
メモリを占有し、ホストコンピュータの処理能力を低下
させる恐れがある。

この発明は、上記の問題点を解決するためになされたも
ので、既存のＲＰＣサー八側へのサービスプロシージャ
の追加をモジュールを再作成（リコンパイル）すること
なく実行することを目的とする。

即ち、ワークステーションを中心に既に標準機能になっ
ているＲＰＣにおいて、各プログラムが独自に持つサー
ビスプロシージャを、現在のロードモジュール内部に持
つ方法以外に、後からのサービスプロシージャの追加を
可能にするものである。

〔課題を解決するための手段〕

この発明に係るＲＰＣにおけるサービスプロシージャの
外出し方式は、現在の標準ＲＰＣ機能に加え、ＲＰＣサ
ーバ側プログラムにおいて、プログラム組み込みのサー
ビス要求に対する新たなルーチン、そのために必要なプ
ログラム番号、プロシージャ番号等の対応を示すデータ
ベース及び実際のサービスを実行する別プログラムを利
用することにより、追加のサービスプロシージャの参照
を可能とするものである。

〔作　用〕

この発明におけるＲＰＣにおけるサービスプロシージャ
の外出し方式は、ＲＰＣサー八側へログラムにおけるサ
ービスプロシージャの外出しを実行することによりＲＰ
Ｃサーバ側のモジュール性（ｍｏｄｕｌａｒｉｔｙ）を
高める。

〔実施例〕

以下、この発明の一実施例を図について説明する。

第１図において、１０１はＲＰＣサーバ側プログラムの
うち、各サービスプロシージャに対する処理を実行する
部分の抜粋、１０２は各ＲＰＣプログラムに対し、外出
し可能となったＲＰＣサービスプロシージャの定義ファ
イル、１０３はＲＰＣの実際のサービス要求を実行する
部分である。

ここで、現在のＲＰＣサーバ側のプログラムに関して考
えると、第１図の１−０１において、“ｄｅｆａｕｌｔ
：”の際の処理結果は常に図に示した“ｅｌｓｅ”“の
場合しか存在しなかった。

二の場合において、図でいう各“ｃａｓｅ”文に相当し
ないサービスプロシージャの場合には、必ス”ｎｏ　５
ｕｃｈ　ｐｒｏｃｅｄｕｒｅ’となる。

そこで、第１図に示す１０４　（ＲＰＣサーバプログラ
ムの追加プログラム）の処理をＲＰＣサーバ側プログラ
ムに追加し、任意のＲＰＣサービスプロシージャの追加
を可能にする機構を従供する。

第１図における１０４に必要な処理を第２図のフローチ
ャートに示す。

ここの処理が実行されるのは、ＲＰＣサーバ側プログラ
ム内に要求されたサービスプロシージャが存在しないと
きである。

第１に、サービスプロシージャ定義ファイルを参照する
（関数ｇｅｔｒｐｃｐｒｏｃｅｎｔ（））。換言すると
、定義ファイル中に要求したプログラムプロシージャー
の対応が存在するか否か判断しくステップ５２０１）、
定義ファイルがない、或いは定義ファイル中に要求され
たプログラムプロシージャの対応が存在しなかった場合
には、　　ｎｏ　５ｕｃｈｐｒｏｃｅｄｕｒｅ”の結果
を繰り返し、指定のプロシージャに対するサービスを実
行しない（ステ、プ５２０２）。反対に、定義ファイル
がある、或いは定義ファイル中乙こ要求されたプログラ
ムプロシージャの対応が存在する場合うこは、定義ファ
イル中のｅｘｅｃｐａｔｈで指定されたプログラムが、
実際のサービスプロシージャに対する処理を実行する。

その際、ＲＰＣサーバ側プログラムは、その処理を子プ
ロセスに任せ、自分自身は子プロセスにより得られる結
果を受は取るまで待機状態となる（ステップ３２０３〜
ステツプ５２０６）。

結果として受は取るデータの型は、各サービスにより異
なるが、定義ファイルにその型を記述しておくことによ
り、データ型が保証される。

子プロセスの結果を受は取ったＲＰＣサーバ側プログラ
ムは、この状態で、サービスプロシージャに対する処理
を終了したことを確認できたので、第１図における他の
“ｃａｓｅ”文と同等の機能を果たしたことになる。

一方、ＲＰＣサーバ側プログラムにより起動され、実際
のサービスプロシージャに対する処理を実行するプログ
ラムのフローチャートを第３図に示す。

ここでは、定義ファイルより得られる引数のタイプ（第
１図“ａｒｇｕｔｙｐｅ”　）を基に引数を解釈しくス
テップＳ　３０１　）　、３解釈された引数を使用して
要求されたサービスプロシージャに対する処理の実行（
ステップ５３０２）Ｌ、定義ファイルより得られる結果
のタイプ（第１図のｒｅｓｕｌｔｔｙｐｅ”　）に合わ
せたＲＰＣサーバ側プログラムに返却すべき結果データ
を作成しくステップ５３０３）、該結果データをプロセ
ス間通信機能を使用してＲＰＣサーバ側プログラムに転
送する処理を実行する（ステップ５３０４）。

なお、上記実施例では、従来のＲＰＣサーバ側プログラ
ムと同様、その処理がＲＰＣサーバマシン内にのみ閉じ
たものと考えて説明したが、サービスプロシージャ定義
ファイルの書式にホスト名を加える、及び、プロセス間
通信の手段としてネットワーク・アクセス可能な手段を
使用することにより、ネットワーク透過な機能としても
使用できる。

〔発明の効果］ 以上のように、この発明によれば１、つのＲＰＣサーバ
側プログラムに任意のサービスプロシージャの追加を可
能としているので、サービスプロシージャの追加が容易
にでき、また、ソフトウェアの開発、保守の便宜が図れ
る効果がある。

【図面の簡単な説明】

第１図はこの発明の一実施例によるＲＰＣサーバ側で必
要なプログラム及びファイルの構成を示す説明図、第２
図は第１図中で本発明に必要な処理動作を示すフローチ
ャート、第３図は各ＲＰＣサービスに対する追加可能な
サービスプロシージャに必要な処理動作を示すフローチ
ャートである。 図において、 １０１−ＲＰ　Ｃサーバ側プログラム １０：ｌ”−−サービスプロシージャ定義ファイル１０
３−サービス実行 １０４−ＲＰ　Ｃサーバ側プログラムの追加プログラム である。 なお、各図中、同一符号は同一、又は相当部分を示す。

Claims (1)

1. 【特許請求の範囲】 クライアントプログラムとサーバプログラムから成るＲ
   ＰＣ（ＲｅｍｏｔｅＰｒｏｃｅｄｕｒｅＣａｌｌ）プロ
   グラムにおいて、 前記サーバプログラムにおけるプログラム組み込みのサ
   ービス要求に対するルーチンと、 前記ルーチンを実行するための必要なプログラム番号、
   プロシージャ番号等の対応を示すデータベースと、 実際のサービスを実行する別プログラムとを利用するこ
   とにより追加のサービスプロシージャの参照を可能にし
   たことを特徴とするＲＰＣにおけるサービスプロシージ
   ャの外出し方式。