JPH05113959A - リモ−トプロシジヤコ−ル要求代行処理方法および装置 - Google Patents
リモ−トプロシジヤコ−ル要求代行処理方法および装置Info
- Publication number
- JPH05113959A JPH05113959A JP3274420A JP27442091A JPH05113959A JP H05113959 A JPH05113959 A JP H05113959A JP 3274420 A JP3274420 A JP 3274420A JP 27442091 A JP27442091 A JP 27442091A JP H05113959 A JPH05113959 A JP H05113959A
- Authority
- JP
- Japan
- Prior art keywords
- procedure
- request
- execution
- processing device
- executing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02E—REDUCTION OF GREENHOUSE GAS [GHG] EMISSIONS, RELATED TO ENERGY GENERATION, TRANSMISSION OR DISTRIBUTION
- Y02E60/00—Enabling technologies; Technologies with a potential or indirect contribution to GHG emissions mitigation
- Y02E60/10—Energy storage using batteries
Abstract
(57)【要約】
【目的】 リモ−トプロシジャコ−ルにおいて、プロシ
ジャ要求側とプロシジャ実行側との間に代行するシステ
ムを配置して、プロシジャ要求側の処理負担を軽減す
る。 【構成】 プロシジャ要求側とプロシジャ実行側との間
にＲＰＣ要求代行処理装置を配置し、その中にプロシジ
ャディレクトリとクライアント／サ−バディレクトリと
各プロシジャ毎の共用メモリとＲＰＣ処理装置とを設け
る。ＲＰＣ要求代行処理装置は、プロシジャ要求側から
要求を受け取り、プロシジャディレクトリを参照してプ
ロシジャ実行側を決定し、実行を要求する。そして、実
行結果を受け取ると、クライアント／サ−バディレクト
リを用いてプロシジャ要求側の認証、およびデ−タ変換
処理を実行する。
ジャ要求側とプロシジャ実行側との間に代行するシステ
ムを配置して、プロシジャ要求側の処理負担を軽減す
る。 【構成】 プロシジャ要求側とプロシジャ実行側との間
にＲＰＣ要求代行処理装置を配置し、その中にプロシジ
ャディレクトリとクライアント／サ−バディレクトリと
各プロシジャ毎の共用メモリとＲＰＣ処理装置とを設け
る。ＲＰＣ要求代行処理装置は、プロシジャ要求側から
要求を受け取り、プロシジャディレクトリを参照してプ
ロシジャ実行側を決定し、実行を要求する。そして、実
行結果を受け取ると、クライアント／サ−バディレクト
リを用いてプロシジャ要求側の認証、およびデ−タ変換
処理を実行する。
Description
【０００１】
【産業上の利用分野】本発明は、情報の分散処理方法に
関し、特に分散したシステムが各種のサ−ビスをプロシ
ジャの形で提供している場合の処理方法および処理装置
に関する。
関し、特に分散したシステムが各種のサ−ビスをプロシ
ジャの形で提供している場合の処理方法および処理装置
に関する。
【０００２】
【従来の技術】従来より、リモ−トプロシジャコ−ル
（以下、ＲＰＣ）自体は既に知られた技術であって、Ｒ
ＰＣを実装した製品も使用されている。これらのＲＰＣ
では、プロシジャの要求側は通常プロシジャの実行側に
直接、プロシジャの要求を行っていた。図２は、従来の
ＲＰＣの形態を示す図であり、また図５は、従来のＲＰ
Ｃにおけるプロシジャ要求側の処理の例を示すフロ−チ
ャ−トである。図２に示すように、プロシジャ要求側１
０は、個々のプロシジャの実行側毎（１１，１２，１
３）に一連の処理をする必要があった。すなわち、プロ
シジャの要求側１０はディレクトリ等を用いてプロシジ
ャ実行側１１，１２，１３の位置を知り、そのサ−バと
の通信を行ってプロシジャの処理要求を行い、処理され
た結果を返送してもらう。また、プロシジャの要求側１
０は、プロシジャの実行側１１，１２，１３に必要に応
じて認証を行う。プロシジャの要求側１０とプロシジャ
の実行側１１〜１３でデ−タの表現が異なると、プロシ
ジャの要求側１０またはプロシジャの実行側１１〜１３
またはその両方で、デ−タ変換を行っていた。従って、
複数のプロシジャ実行側１１〜１３にプロシジャを要求
する場合には、プロシジャの要求側１０は上記デ−タ変
換処理を各プロシジャ実行側毎に行う必要があった。
（以下、ＲＰＣ）自体は既に知られた技術であって、Ｒ
ＰＣを実装した製品も使用されている。これらのＲＰＣ
では、プロシジャの要求側は通常プロシジャの実行側に
直接、プロシジャの要求を行っていた。図２は、従来の
ＲＰＣの形態を示す図であり、また図５は、従来のＲＰ
Ｃにおけるプロシジャ要求側の処理の例を示すフロ−チ
ャ−トである。図２に示すように、プロシジャ要求側１
０は、個々のプロシジャの実行側毎（１１，１２，１
３）に一連の処理をする必要があった。すなわち、プロ
シジャの要求側１０はディレクトリ等を用いてプロシジ
ャ実行側１１，１２，１３の位置を知り、そのサ−バと
の通信を行ってプロシジャの処理要求を行い、処理され
た結果を返送してもらう。また、プロシジャの要求側１
０は、プロシジャの実行側１１，１２，１３に必要に応
じて認証を行う。プロシジャの要求側１０とプロシジャ
の実行側１１〜１３でデ−タの表現が異なると、プロシ
ジャの要求側１０またはプロシジャの実行側１１〜１３
またはその両方で、デ−タ変換を行っていた。従って、
複数のプロシジャ実行側１１〜１３にプロシジャを要求
する場合には、プロシジャの要求側１０は上記デ−タ変
換処理を各プロシジャ実行側毎に行う必要があった。
【０００３】図２に示すように、プロシジャ要求側１０
と複数のプロシジャ実行側１１〜１３が直接プロシジャ
の要求を行う場合の動作は、図５に示すようなフロ−で
示される。先ず、プロシジャ要求側では、アプリケ−シ
ョンプログラム等から自システムにないプロシジャコ−
ルの要求が発生する（ステップ５０１）。プロシジャ要
求側は、そのプロシジャをどのプロシジャ実行側に依頼
するか、ディレクトリ等を使用して調べる（ステップ５
０２）。プロシジャ要求側は、依頼先のプロシジャ実行
側に対する認証する準備をする（ステップ５０３）。プ
ロシジャ要求側は、次にプロシジャに使用する引数を標
準のデ−タ形式に変換する（ステップ５０４）。プロシ
ジャ要求側は、プロシジャ実行側に対してプロシジャの
実行要求を送信する（ステップ５０５）。この後、プロ
シジャ要求側は、プロシジャの実行結果を受け取る（ス
テップ５０６）。プロシジャ要求側は、実行結果のデ−
タを自システムで処理できる形に変換し（ステップ５０
７）、アプリケ−ションプログラムにその結果を返す
（ステップ５０８）。プロシジャ要求側は、オプション
としてプロシジャ実行側に対して課金処理を行う（ステ
ップ５０９）。そして、再びステップ５０１に戻る。こ
こまでの処理が、１つのプロシジャに対する処理であ
る。いま、図２に示すように、異なる３つのプロシジャ
実行側に対して、それぞれプロシジャの実行要求を行う
場合には、図５に示す処理を３回繰り返す必要がある。
すなわち、プロシジャの数が多くなると、プロシジャ要
求側の負担は大きくなる。
と複数のプロシジャ実行側１１〜１３が直接プロシジャ
の要求を行う場合の動作は、図５に示すようなフロ−で
示される。先ず、プロシジャ要求側では、アプリケ−シ
ョンプログラム等から自システムにないプロシジャコ−
ルの要求が発生する（ステップ５０１）。プロシジャ要
求側は、そのプロシジャをどのプロシジャ実行側に依頼
するか、ディレクトリ等を使用して調べる（ステップ５
０２）。プロシジャ要求側は、依頼先のプロシジャ実行
側に対する認証する準備をする（ステップ５０３）。プ
ロシジャ要求側は、次にプロシジャに使用する引数を標
準のデ−タ形式に変換する（ステップ５０４）。プロシ
ジャ要求側は、プロシジャ実行側に対してプロシジャの
実行要求を送信する（ステップ５０５）。この後、プロ
シジャ要求側は、プロシジャの実行結果を受け取る（ス
テップ５０６）。プロシジャ要求側は、実行結果のデ−
タを自システムで処理できる形に変換し（ステップ５０
７）、アプリケ−ションプログラムにその結果を返す
（ステップ５０８）。プロシジャ要求側は、オプション
としてプロシジャ実行側に対して課金処理を行う（ステ
ップ５０９）。そして、再びステップ５０１に戻る。こ
こまでの処理が、１つのプロシジャに対する処理であ
る。いま、図２に示すように、異なる３つのプロシジャ
実行側に対して、それぞれプロシジャの実行要求を行う
場合には、図５に示す処理を３回繰り返す必要がある。
すなわち、プロシジャの数が多くなると、プロシジャ要
求側の負担は大きくなる。
【０００４】
【発明が解決しようとする課題】このように、従来のＲ
ＰＣでは、プロシジャの要求側がプロシジャの実行側の
位置の調査を行った後、プロシジャ実行側に対してプロ
シジャ実行要求を行い、その実行結果を受信するととも
に、プロシジャの要求側の認証、デ−タ変換の作業を行
う必要があった。また、複数のプロシジャ実行側にプロ
シジャの実行を要求する場合には、プロシジャの実行側
毎にそれぞれ上述の各処理を行う必要があるため、プロ
シジャ要求側の負担は極めて大きかった。本発明の目的
は、このような従来の課題を解決し、プロシジャ要求側
の負担を軽減することができるリモ−トプロシジャコ−
ル要求代行処理方法および装置を提供することにある。
ＰＣでは、プロシジャの要求側がプロシジャの実行側の
位置の調査を行った後、プロシジャ実行側に対してプロ
シジャ実行要求を行い、その実行結果を受信するととも
に、プロシジャの要求側の認証、デ−タ変換の作業を行
う必要があった。また、複数のプロシジャ実行側にプロ
シジャの実行を要求する場合には、プロシジャの実行側
毎にそれぞれ上述の各処理を行う必要があるため、プロ
シジャ要求側の負担は極めて大きかった。本発明の目的
は、このような従来の課題を解決し、プロシジャ要求側
の負担を軽減することができるリモ−トプロシジャコ−
ル要求代行処理方法および装置を提供することにある。
【０００５】
【課題を解決するための手段】上記目的を達成するた
め、本発明によるリモ−トプロシジャコ−ル要求代行処
理方法は、（イ）アプリケ−ションプログラムからリモ
−トプロシジャコ−ルを受け付けると、プロシジャ要求
代行処理装置は、プロシジャに関する情報を基にプロシ
ジャを実行するシステムへのプロシジャ実行要求を代行
し、プロシジャ実行の結果をプロシジャ実行側から受け
取ると、実行結果を該プロシジャ要求側に返し、この期
間中、プロシジャの要求側と実行側の間の認証、および
デ−タ変換を行うことに特徴がある。また、（ロ）プロ
シジャ要求代行処理装置は、プロシジャ要求側からの要
求に対して、プロシジャ実行側への課金に責任を持ち、
プロシジャ要求側に全体でかかった費用を請求すること
にも特徴がある。さらに、（ハ）本発明のリモ−トプロ
シジャコ−ル要求代行処理装置は、プロシジャ要求側か
ら要求されたプロシジャをどのプロシジャ実行側に要求
するかを決定する際に参照されるプロシジャディレクト
リと、プロシジャ要求側およびプロシジャ実行側でのデ
−タ表現形式を登録しておくクライアント／サ−バディ
レクトリと、各プロシジャ実行側で共通に参照する共用
変数および定数を格納しておく共用メモリと、プロシジ
ャディレクトリ、クライアント／サ−バディレクトリ、
および共用メモリを使用してリモ−トプロシジャコ−ル
要求代行処理を実行するプロシジャ処理装置とを有する
ことに特徴がある。
め、本発明によるリモ−トプロシジャコ−ル要求代行処
理方法は、（イ）アプリケ−ションプログラムからリモ
−トプロシジャコ−ルを受け付けると、プロシジャ要求
代行処理装置は、プロシジャに関する情報を基にプロシ
ジャを実行するシステムへのプロシジャ実行要求を代行
し、プロシジャ実行の結果をプロシジャ実行側から受け
取ると、実行結果を該プロシジャ要求側に返し、この期
間中、プロシジャの要求側と実行側の間の認証、および
デ−タ変換を行うことに特徴がある。また、（ロ）プロ
シジャ要求代行処理装置は、プロシジャ要求側からの要
求に対して、プロシジャ実行側への課金に責任を持ち、
プロシジャ要求側に全体でかかった費用を請求すること
にも特徴がある。さらに、（ハ）本発明のリモ−トプロ
シジャコ−ル要求代行処理装置は、プロシジャ要求側か
ら要求されたプロシジャをどのプロシジャ実行側に要求
するかを決定する際に参照されるプロシジャディレクト
リと、プロシジャ要求側およびプロシジャ実行側でのデ
−タ表現形式を登録しておくクライアント／サ−バディ
レクトリと、各プロシジャ実行側で共通に参照する共用
変数および定数を格納しておく共用メモリと、プロシジ
ャディレクトリ、クライアント／サ−バディレクトリ、
および共用メモリを使用してリモ−トプロシジャコ−ル
要求代行処理を実行するプロシジャ処理装置とを有する
ことに特徴がある。
【０００６】
【作用】本発明においては、プロシジャの要求側が直接
に複数のプロシジャ実行側にプロシジャを要求する代り
に、プロシジャ要求側の代行者であるＲＰＣ要求代行処
理装置を配置して、この装置がサ−バとのやり取りを代
行することにより実現される。このように、ＲＰＣ要求
代行処理装置は、プロシジャ実行側にプロシジャ実行の
依頼に関して、プロシジャ要求側の代行を行う。それに
より、（イ）プロシジャ要求側は、ＲＰＣ要求代行処理
装置のみにプロシジャ実行要求を送出すればよいので、
プロシジャ要求側の作業が大幅に軽減される。また、
（ロ）特定のプロシジャを供与するプロシジャ実行側の
位置は、プロシジャディレクトリを参照することによ
り、ＲＰＣ要求代行処理装置が決定される。それによ
り、プロシジャ要求側はどのプロシジャがどのプロシジ
ャ実行側で供与されるかを意識せずに要求を行うことが
できるので、要求側の処理は減少される。また、（ハ）
プロシジャ要求側とプロシジャ実行側のデ−タ表現の変
換は、クライアント／サ−バディレクトリを用いて、Ｒ
ＰＣ要求代行処理装置が行う。それによって、プロシジ
ャ要求側はデ−タの変換を行う必要がなくなるので、そ
れによっても要求側の処理は軽減する。さらに、（ニ）
各プロシジャ実行側への認証は、ＲＰＣ要求代行処理装
置が実行する。これによっても、プロシジャ要求側はＲ
ＰＣ要求代行処理装置に対してのみ認証を行うだけでよ
いので、処理は軽減する。さらに、（ホ）各プロシジャ
実行側への課金は、ＲＰＣ要求代行処理装置が対応する
ので、プロシジャ要求側は、ＲＰＣ要求代行処理装置に
対しての課金処理のみでよく、これによっても処理は軽
減される。
に複数のプロシジャ実行側にプロシジャを要求する代り
に、プロシジャ要求側の代行者であるＲＰＣ要求代行処
理装置を配置して、この装置がサ−バとのやり取りを代
行することにより実現される。このように、ＲＰＣ要求
代行処理装置は、プロシジャ実行側にプロシジャ実行の
依頼に関して、プロシジャ要求側の代行を行う。それに
より、（イ）プロシジャ要求側は、ＲＰＣ要求代行処理
装置のみにプロシジャ実行要求を送出すればよいので、
プロシジャ要求側の作業が大幅に軽減される。また、
（ロ）特定のプロシジャを供与するプロシジャ実行側の
位置は、プロシジャディレクトリを参照することによ
り、ＲＰＣ要求代行処理装置が決定される。それによ
り、プロシジャ要求側はどのプロシジャがどのプロシジ
ャ実行側で供与されるかを意識せずに要求を行うことが
できるので、要求側の処理は減少される。また、（ハ）
プロシジャ要求側とプロシジャ実行側のデ−タ表現の変
換は、クライアント／サ−バディレクトリを用いて、Ｒ
ＰＣ要求代行処理装置が行う。それによって、プロシジ
ャ要求側はデ−タの変換を行う必要がなくなるので、そ
れによっても要求側の処理は軽減する。さらに、（ニ）
各プロシジャ実行側への認証は、ＲＰＣ要求代行処理装
置が実行する。これによっても、プロシジャ要求側はＲ
ＰＣ要求代行処理装置に対してのみ認証を行うだけでよ
いので、処理は軽減する。さらに、（ホ）各プロシジャ
実行側への課金は、ＲＰＣ要求代行処理装置が対応する
ので、プロシジャ要求側は、ＲＰＣ要求代行処理装置に
対しての課金処理のみでよく、これによっても処理は軽
減される。
【０００７】
【実施例】以下、本発明の実施例を、図面により詳細に
説明する。図１は、本発明の一実施例を示すＲＰＣ要求
代行処理装置とプロシジャ要求側および実行側との関係
を示す図である。図１に示すように、本実施例において
は、プロシジャ要求側６とプロシジャ実行側７〜９との
間に、ＲＰＣ要求代行処理装置１を導入する。ＲＰＣ要
求代行処理装置１は、ＲＰＣの処理を行うＲＰＣ処理装
置５と、プロシジャディレクトリ２と、クライアント／
サ−バディレクトリ３と、ＲＰＣ処理装置５に接続され
た共用メモリ４とから構成される。ＲＰＣ要求代行処理
装置１のうち、ＲＰＣ処理装置５は、プロシジャディレ
クトリ２を用いてプロシジャ実行側の位置を決定し、ク
ライアント／サ−バディレクトリ３を用いて要求側と実
行側のデ−タ表現の変換を行う。また、プロシジャ要求
側から認証を受け取った後、これに基づいてプロシジャ
実行側の各々に対して認証を行う。さらに、プロシジャ
要求側から課金されることにより、それに基づいてプロ
シジャ実行側の各々に対して課金を行う。
説明する。図１は、本発明の一実施例を示すＲＰＣ要求
代行処理装置とプロシジャ要求側および実行側との関係
を示す図である。図１に示すように、本実施例において
は、プロシジャ要求側６とプロシジャ実行側７〜９との
間に、ＲＰＣ要求代行処理装置１を導入する。ＲＰＣ要
求代行処理装置１は、ＲＰＣの処理を行うＲＰＣ処理装
置５と、プロシジャディレクトリ２と、クライアント／
サ−バディレクトリ３と、ＲＰＣ処理装置５に接続され
た共用メモリ４とから構成される。ＲＰＣ要求代行処理
装置１のうち、ＲＰＣ処理装置５は、プロシジャディレ
クトリ２を用いてプロシジャ実行側の位置を決定し、ク
ライアント／サ−バディレクトリ３を用いて要求側と実
行側のデ−タ表現の変換を行う。また、プロシジャ要求
側から認証を受け取った後、これに基づいてプロシジャ
実行側の各々に対して認証を行う。さらに、プロシジャ
要求側から課金されることにより、それに基づいてプロ
シジャ実行側の各々に対して課金を行う。
【０００８】図１において、プロシジャ要求側６は、Ｒ
ＰＣ要求代行処理装置１に直接プロシジャの要求を依頼
する。ＲＰＣ要求代行処理装置１は、個々のプロシジャ
がどこで実行可能であるかという情報を保持するプロシ
ジャディレクトリ２を備えている。なお、このプロシジ
ャディレクトリ２は、ＲＰＣ要求代行処理装置１と同じ
システム内にあるとは限らない。すなわち、ＲＰＣ要求
代行処理装置１は一般のディレクトリを利用することに
よっても、同じサ−ビスを提供することができる。ＲＰ
Ｃ要求代行処理装置１は、プロシジャディレクトリ２の
情報を使用して、プロシジャ要求側が要求したプロシジ
ャをどのプロシジャ実行側に要求するかを決定し、プロ
シジャの実行要求を送出する。プロシジャ実行側からプ
ロシジャの実行結果を受け取り、これをプロシジャの要
求側６に返送する。また、プロシジャ要求側とプロシジ
ャ実行側でデ−タ表現が異なる場合には、次の処理を行
う。すなわち、先ず、クライアント／サ−バディレクト
リ３で、プロシジャ要求側６とプロシジャ実行側７〜９
でのデ−タ表現形式を登録しておく。プロシジャ要求側
６がＲＰＣ要求代行処理装置１にプロシジャを要求する
と、ＲＰＣ要求代行処理装置１はクライアント／サ−バ
ディレクトリ３の情報を参照し、プロシジャ要求側６の
デ−タ表現をプロシジャ実行側７〜９のデ−タ表現に変
換した後に、プロシジャ実行側７〜９にこれらの要求を
送出する。プロシジャ実行の結果の転送時には、上述の
逆の変換を行う。これにより、プロシジャの要求側６お
よび実行側７〜９でデ−タ表現の変換処理を行う必要が
なく、プロシジャの要求側６および実行側７〜９の処理
は軽減される。
ＰＣ要求代行処理装置１に直接プロシジャの要求を依頼
する。ＲＰＣ要求代行処理装置１は、個々のプロシジャ
がどこで実行可能であるかという情報を保持するプロシ
ジャディレクトリ２を備えている。なお、このプロシジ
ャディレクトリ２は、ＲＰＣ要求代行処理装置１と同じ
システム内にあるとは限らない。すなわち、ＲＰＣ要求
代行処理装置１は一般のディレクトリを利用することに
よっても、同じサ−ビスを提供することができる。ＲＰ
Ｃ要求代行処理装置１は、プロシジャディレクトリ２の
情報を使用して、プロシジャ要求側が要求したプロシジ
ャをどのプロシジャ実行側に要求するかを決定し、プロ
シジャの実行要求を送出する。プロシジャ実行側からプ
ロシジャの実行結果を受け取り、これをプロシジャの要
求側６に返送する。また、プロシジャ要求側とプロシジ
ャ実行側でデ−タ表現が異なる場合には、次の処理を行
う。すなわち、先ず、クライアント／サ−バディレクト
リ３で、プロシジャ要求側６とプロシジャ実行側７〜９
でのデ−タ表現形式を登録しておく。プロシジャ要求側
６がＲＰＣ要求代行処理装置１にプロシジャを要求する
と、ＲＰＣ要求代行処理装置１はクライアント／サ−バ
ディレクトリ３の情報を参照し、プロシジャ要求側６の
デ−タ表現をプロシジャ実行側７〜９のデ−タ表現に変
換した後に、プロシジャ実行側７〜９にこれらの要求を
送出する。プロシジャ実行の結果の転送時には、上述の
逆の変換を行う。これにより、プロシジャの要求側６お
よび実行側７〜９でデ−タ表現の変換処理を行う必要が
なく、プロシジャの要求側６および実行側７〜９の処理
は軽減される。
【０００９】クライアント／サ−バディレクトリ３に登
録されていないプロシジャ要求側またはプロシジャ実行
側と、ＲＰＣ要求代行処理装置１との通信では、標準の
デ−タ形式を使用する。ＲＰＣ要求代行処理装置１内に
は共用メモリ４が配置される。これは、各プロシジャ実
行側７〜９で共通に参照する共用変数、定数を格納して
おくものである。これにより、異なるシステムに存在す
るプロシジャ実行側でのプロシジャ間の通信が、ＲＰＣ
ライブラリの共用メモリ４を介して可能となる。また、
従来では、個々のプロシジャ要求側は、それぞれのプロ
シジャ実行側に対して認証（自分の身元確認）を行う必
要があった。しかしながら、本実施例では、プロシジャ
の要求側６はＲＰＣ要求代行処理装置１に対してのみ認
証を行う。また、ＲＰＣ要求代行処理装置１は、信頼で
きるサ−バとしての機能を備えている。すなわち、ＲＰ
Ｃ要求代行処理装置１はプロシジャ要求側６を認証する
と、プロシジャ要求側６の身元をプロシジャ実行側７〜
９に保証して、プロシジャ実行側７〜９との間は、ＲＰ
Ｃ要求代行処理装置１自身の認証のみを行う。これによ
って、プロシジャ要求側６は、１回だけＲＰＣ要求代行
処理装置１に対して認証するだけですむので、負担が軽
減される。プロシジャ要求側６とプロシジャ実行側７〜
９での課金についても、従来では、プロシジャ要求側６
がそれぞれのプロシジャ実行側７〜９に課金していた
が、本実施例では、プロシジャ要求側６はＲＰＣ要求代
行処理装置１に対してのみ課金を行えばすむ。ＲＰＣ要
求代行処理装置１は、プロシジャ実行側７〜９に対する
課金に責任を持ち、プロシジャ要求側６に全体でかかっ
た費用を請求する。これによって、プロシジャ要求側６
の課金処理は軽減され、単純化される。
録されていないプロシジャ要求側またはプロシジャ実行
側と、ＲＰＣ要求代行処理装置１との通信では、標準の
デ−タ形式を使用する。ＲＰＣ要求代行処理装置１内に
は共用メモリ４が配置される。これは、各プロシジャ実
行側７〜９で共通に参照する共用変数、定数を格納して
おくものである。これにより、異なるシステムに存在す
るプロシジャ実行側でのプロシジャ間の通信が、ＲＰＣ
ライブラリの共用メモリ４を介して可能となる。また、
従来では、個々のプロシジャ要求側は、それぞれのプロ
シジャ実行側に対して認証（自分の身元確認）を行う必
要があった。しかしながら、本実施例では、プロシジャ
の要求側６はＲＰＣ要求代行処理装置１に対してのみ認
証を行う。また、ＲＰＣ要求代行処理装置１は、信頼で
きるサ−バとしての機能を備えている。すなわち、ＲＰ
Ｃ要求代行処理装置１はプロシジャ要求側６を認証する
と、プロシジャ要求側６の身元をプロシジャ実行側７〜
９に保証して、プロシジャ実行側７〜９との間は、ＲＰ
Ｃ要求代行処理装置１自身の認証のみを行う。これによ
って、プロシジャ要求側６は、１回だけＲＰＣ要求代行
処理装置１に対して認証するだけですむので、負担が軽
減される。プロシジャ要求側６とプロシジャ実行側７〜
９での課金についても、従来では、プロシジャ要求側６
がそれぞれのプロシジャ実行側７〜９に課金していた
が、本実施例では、プロシジャ要求側６はＲＰＣ要求代
行処理装置１に対してのみ課金を行えばすむ。ＲＰＣ要
求代行処理装置１は、プロシジャ実行側７〜９に対する
課金に責任を持ち、プロシジャ要求側６に全体でかかっ
た費用を請求する。これによって、プロシジャ要求側６
の課金処理は軽減され、単純化される。
【００１０】図３は、図１におけるプロシジャディレク
トリの内容例を示す図である。プロシジャディレクトリ
２には、プロシジャ名またはプロシジャを一意に識別す
る識別子と、そのプロシジャを供与するプロシジャ実行
側の位置情報睡のプロシジャに関する情報が登録されて
いる。図４は、図１におけるクライアント／サ−バディ
レクトリの内容例を示す図である。クライアント／サ−
バディレクトリ３には、プロシジャ要求側６およびプロ
シジャ実行側７〜９に関するデ−タ表現等の情報が登録
されている。例えば、プロシジャ実行側のシステム１
は、ＩＥＥＥの浮動小数点およびＡＳＣＩＩの文字コ−
ドを使用している。プロシジャ実行側のシステム２は、
ＩＢＭ形式の浮動小数点とＥＢＣＤＩＣの文字コ−ドを
使用している。このように、各システム毎のデ−タ表
現、認証、課金等の情報をクライアント／サ−バディレ
クトリ３に登録しておく。共用メモリ４は、各プロシジ
ャ間での連絡に使用される。あるアプリケ−ションプロ
グラムが複数のプロシジャを呼び出す場合、そのプロシ
ジャ間での連絡のためにこの共用メモリ４を使用する。
トリの内容例を示す図である。プロシジャディレクトリ
２には、プロシジャ名またはプロシジャを一意に識別す
る識別子と、そのプロシジャを供与するプロシジャ実行
側の位置情報睡のプロシジャに関する情報が登録されて
いる。図４は、図１におけるクライアント／サ−バディ
レクトリの内容例を示す図である。クライアント／サ−
バディレクトリ３には、プロシジャ要求側６およびプロ
シジャ実行側７〜９に関するデ−タ表現等の情報が登録
されている。例えば、プロシジャ実行側のシステム１
は、ＩＥＥＥの浮動小数点およびＡＳＣＩＩの文字コ−
ドを使用している。プロシジャ実行側のシステム２は、
ＩＢＭ形式の浮動小数点とＥＢＣＤＩＣの文字コ−ドを
使用している。このように、各システム毎のデ−タ表
現、認証、課金等の情報をクライアント／サ−バディレ
クトリ３に登録しておく。共用メモリ４は、各プロシジ
ャ間での連絡に使用される。あるアプリケ−ションプロ
グラムが複数のプロシジャを呼び出す場合、そのプロシ
ジャ間での連絡のためにこの共用メモリ４を使用する。
【００１１】図６は、本発明の一実施例を示すプロシジ
ャ要求側の処理フロ−チャ−トである。先ず、プロシジ
ャの要求側６は、ＲＰＣ要求代行処理装置１に対して認
証を行う（ステップ６０１）。プロシジャ要求側６内で
アプリケ−ションプログラム等からプロシジャコ−ルが
発生すると（ステップ６０２）、プロシジャ要求側６は
ＲＰＣ要求代行処理装置１に対してプロシジャの実行要
求を送る（ステップ６０３）。プロシジャ要求側６は、
ＲＰＣ要求代行処理装置１からプロシジャの実行結果を
受け取る（ステップ６０４）。プロシジャの結果をアプ
リケ−ションプログラム等に返す（ステップ６０５）。
また、他のプロシジャコ−ルがあれば、ステップ６０２
に戻る。他にプロシジャコ−ルがなければ、今回使用し
たプロシジャに対する課金処理を行う（ステップ６０
６）。このように、本実施例においては、従来の方法に
比べて、プロシジャ要求側の処理の負担が大幅に軽減さ
れている。
ャ要求側の処理フロ−チャ−トである。先ず、プロシジ
ャの要求側６は、ＲＰＣ要求代行処理装置１に対して認
証を行う（ステップ６０１）。プロシジャ要求側６内で
アプリケ−ションプログラム等からプロシジャコ−ルが
発生すると（ステップ６０２）、プロシジャ要求側６は
ＲＰＣ要求代行処理装置１に対してプロシジャの実行要
求を送る（ステップ６０３）。プロシジャ要求側６は、
ＲＰＣ要求代行処理装置１からプロシジャの実行結果を
受け取る（ステップ６０４）。プロシジャの結果をアプ
リケ−ションプログラム等に返す（ステップ６０５）。
また、他のプロシジャコ−ルがあれば、ステップ６０２
に戻る。他にプロシジャコ−ルがなければ、今回使用し
たプロシジャに対する課金処理を行う（ステップ６０
６）。このように、本実施例においては、従来の方法に
比べて、プロシジャ要求側の処理の負担が大幅に軽減さ
れている。
【００１２】図７は、本発明の一実施例を示すＲＰＣ要
求代行処理装置の処理フロ−チャ−トである。先ず、Ｒ
ＰＣ要求代行処理装置１は、プロシジャ要求側６の認証
を行う（ステップ７０１）。プロシジャ要求側６からの
プロシジャ要求があれば（ステップ７０２）、これを受
け付け、プロシジャディレクトリ２を用いてプロシジャ
を供与しているプロシジャ実行側７〜９の位置を調べる
（ステップ７０３）。ＲＰＣ要求代行処理装置１は、プ
ロシジャ実行側７〜９に対して認証の準備を行う（ステ
ップ７０４）。ＲＰＣ要求代行処理装置１は、クライア
ント／サ−バディレクトリ３を用いて、プロシジャ要求
側６とプロシジャ実行側７〜９のデ−タ表現を調べる。
そして、プロシジャの引数をプロシジャ要求側６のデ−
タ表現からプロシジャ実行側７〜９のデ−タ表現に変換
する（ステップ７０５）。ＲＰＣ要求代行処理装置１
は、この変換したデ−タを使用してプロシジャ実行側７
〜９にプロシジャの実行を依頼する（ステップ７０
６）。ＲＰＣ要求代行処理装置１は、プロシジャ実行側
６からプロシジャの結果を受け取る（ステップ７０
７）。ＲＰＣ要求代行処理装置１は、プロシジャ実行側
７〜９に対して、オプションとして課金処理を行う場合
もある（ステップ７０８）。ＲＰＣ要求代行処理装置１
は、結果のパラメタをプロシジャ実行側７〜９のデ−タ
表現からプロシジャ要求側６のデ−タ表現に変換する
（ステップ７０９）。ＲＰＣ要求代行処理装置１は、プ
ロシジャの結果をプロシジャ要求側６に送出する。も
し、プロシジャ要求側６から他のプロシジャ要求があれ
ば、ステップ７０２に戻る。もし、プロシジャ要求がな
ければ、オプションとして、プロシジャ要求側６に課金
処理を行う場合もある（ステップ７１０）。
求代行処理装置の処理フロ−チャ−トである。先ず、Ｒ
ＰＣ要求代行処理装置１は、プロシジャ要求側６の認証
を行う（ステップ７０１）。プロシジャ要求側６からの
プロシジャ要求があれば（ステップ７０２）、これを受
け付け、プロシジャディレクトリ２を用いてプロシジャ
を供与しているプロシジャ実行側７〜９の位置を調べる
（ステップ７０３）。ＲＰＣ要求代行処理装置１は、プ
ロシジャ実行側７〜９に対して認証の準備を行う（ステ
ップ７０４）。ＲＰＣ要求代行処理装置１は、クライア
ント／サ−バディレクトリ３を用いて、プロシジャ要求
側６とプロシジャ実行側７〜９のデ−タ表現を調べる。
そして、プロシジャの引数をプロシジャ要求側６のデ−
タ表現からプロシジャ実行側７〜９のデ−タ表現に変換
する（ステップ７０５）。ＲＰＣ要求代行処理装置１
は、この変換したデ−タを使用してプロシジャ実行側７
〜９にプロシジャの実行を依頼する（ステップ７０
６）。ＲＰＣ要求代行処理装置１は、プロシジャ実行側
６からプロシジャの結果を受け取る（ステップ７０
７）。ＲＰＣ要求代行処理装置１は、プロシジャ実行側
７〜９に対して、オプションとして課金処理を行う場合
もある（ステップ７０８）。ＲＰＣ要求代行処理装置１
は、結果のパラメタをプロシジャ実行側７〜９のデ−タ
表現からプロシジャ要求側６のデ−タ表現に変換する
（ステップ７０９）。ＲＰＣ要求代行処理装置１は、プ
ロシジャの結果をプロシジャ要求側６に送出する。も
し、プロシジャ要求側６から他のプロシジャ要求があれ
ば、ステップ７０２に戻る。もし、プロシジャ要求がな
ければ、オプションとして、プロシジャ要求側６に課金
処理を行う場合もある（ステップ７１０）。
【００１３】図８は、本発明の一実施例を示すプロシジ
ャ実行側の処理フロ−チャ−トである。プロシジャ実行
側７〜９は、ＲＰＣ要求代行処理装置１の認証を確認す
る（ステップ８０１）。次にプロシジャ実行側７〜９
は、ＲＰＣ要求代行処理装置１からプロシジャの実行の
要求を受け付ける（ステップ８０２）。プロシジャ実行
側７〜９は、要求されたプロシジャを実行する（ステッ
プ８０３）。そして、実行結果をＲＰＣ要求代行処理装
置１に返送する（ステップ８０４）。そして、他のプロ
シジャ要求がないか否かを調べ、あればステップ８０２
に戻って、受け付けを行う。もし、プロシジャ要求がな
ければ、オプションとして、ＲＰＣ要求代行処理装置１
に対する課金処理を行う（ステップ８０５）。これによ
り、本実施例では、従来のプロシジャ実行側に比べてデ
−タ変換がない分だけ、処理が軽減される。なお、全体
として、課金処理はプロシジャの要求毎に行う場合と、
ある一定期間毎に行う場合とがある。
ャ実行側の処理フロ−チャ−トである。プロシジャ実行
側７〜９は、ＲＰＣ要求代行処理装置１の認証を確認す
る（ステップ８０１）。次にプロシジャ実行側７〜９
は、ＲＰＣ要求代行処理装置１からプロシジャの実行の
要求を受け付ける（ステップ８０２）。プロシジャ実行
側７〜９は、要求されたプロシジャを実行する（ステッ
プ８０３）。そして、実行結果をＲＰＣ要求代行処理装
置１に返送する（ステップ８０４）。そして、他のプロ
シジャ要求がないか否かを調べ、あればステップ８０２
に戻って、受け付けを行う。もし、プロシジャ要求がな
ければ、オプションとして、ＲＰＣ要求代行処理装置１
に対する課金処理を行う（ステップ８０５）。これによ
り、本実施例では、従来のプロシジャ実行側に比べてデ
−タ変換がない分だけ、処理が軽減される。なお、全体
として、課金処理はプロシジャの要求毎に行う場合と、
ある一定期間毎に行う場合とがある。
【００１４】
【発明の効果】以上説明したように、本発明によれば、
ＲＰＣ要求代行処理装置を導入したことにより、プロシ
ジャ要求側の処理が大幅に軽減されるので、パ−ソナル
コンピュ−タ等の安価な小型機器でも、リモ−トプロシ
ジャコ−ルを実現することができる。また、本発明によ
れば、プロシジャ実行側でプロシジャの存在する場所を
意識する必要がない。
ＲＰＣ要求代行処理装置を導入したことにより、プロシ
ジャ要求側の処理が大幅に軽減されるので、パ−ソナル
コンピュ−タ等の安価な小型機器でも、リモ−トプロシ
ジャコ−ルを実現することができる。また、本発明によ
れば、プロシジャ実行側でプロシジャの存在する場所を
意識する必要がない。
【００１５】
【図１】本発明の一実施例を示すＲＰＣ要求代行処理装
置とプロシジャ要求側、実行側の接続関係図である。
置とプロシジャ要求側、実行側の接続関係図である。
【図２】従来のリモ−トプロシジャコ−ルの要求側と実
行側の接続関係図である。
行側の接続関係図である。
【図３】図１におけるプロシジャディレクトリの内容例
を示す図である。
を示す図である。
【図４】図１におけるクライアント／サ−バディレクト
リの内容例を示す図である。
リの内容例を示す図である。
【図５】従来のリモ−トプロシジャコ−ルのプロシジャ
要求側の処理フロ−チャ−トである。
要求側の処理フロ−チャ−トである。
【図６】本発明の一実施例を示すプロシジャ要求側の処
理フロ−チャ−トである。
理フロ−チャ−トである。
【図７】本発明の一実施例を示すＲＰＣ要求代行処理装
置の処理フロ−チャ−トである。
置の処理フロ−チャ−トである。
【図８】本発明の一実施例を示すプロシジャ実行側の処
理フロ−チャ−トである。
理フロ−チャ−トである。
１ ＲＰＣ要求代行処理装置 ２ プロシジャディレクトリ ３ クライアント／サ−バディレクトリ ４ 共用メモリ ５ ＲＰＣ処理装置 ６ プロシジャ要求側 ７〜９ プロシジャ実行側Ａ，Ｂ，Ｃ １０ プロシジャ要求側 １１〜１３ プロシジャ実行側Ａ，Ｂ，Ｃ
Claims (3)
- 【請求項１】 プロシジャ要求側のアプリケ−ションプ
ログラムからリモ−トプロシジャコ−ルを受け付ける
と、プロシジャ要求代行処理装置は、プロシジャに関す
る情報を基に該プロシジャを実行するシステムへのプロ
シジャ実行要求を代行し、プロシジャ実行の結果をプロ
シジャ実行側から受け取ると、実行結果を該プロシジャ
要求側に返し、この期間中、プロシジャの要求側と実行
側の間の認証、およびデ−タ変換を行うことを特徴とす
るリモ−トプロシジャコ−ル要求代行処理方法。 - 【請求項２】 請求項１に記載のリモ−トプロシジャコ
−ル要求代行処理方法において、上記プロシジャ要求代
行処理装置は、プロシジャ要求側からの要求に対して、
プロシジャ実行側への課金に責任を持ち、プロシジャ要
求側に全体でかかった費用を請求することを特徴とする
リモ−トプロシジャコ−ル要求代行処理方法。 - 【請求項３】 プロシジャ要求側から要求されたプロシ
ジャをどのプロシジャ実行側に要求するかを決定する際
に参照されるプロシジャディレクトリと、プロシジャ要
求側およびプロシジャ実行側でのデ−タ表現形式を登録
しておくクライアント／サ−バディレクトリと、各プロ
シジャ実行側で共通に参照する共用変数および定数を格
納しておく共用メモリと、上記プロシジャディレクト
リ、クライアント／サ−バディレクトリ、および共用メ
モリを使用してリモ−トプロシジャコ−ル要求代行処理
を実行するプロシジャ処理装置とを有することを特徴と
するリモ−トプロシジャコ−ル要求代行処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP3274420A JPH05113959A (ja) | 1991-10-23 | 1991-10-23 | リモ−トプロシジヤコ−ル要求代行処理方法および装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP3274420A JPH05113959A (ja) | 1991-10-23 | 1991-10-23 | リモ−トプロシジヤコ−ル要求代行処理方法および装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH05113959A true JPH05113959A (ja) | 1993-05-07 |
Family
ID=17541426
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP3274420A Pending JPH05113959A (ja) | 1991-10-23 | 1991-10-23 | リモ−トプロシジヤコ−ル要求代行処理方法および装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH05113959A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06348511A (ja) * | 1993-05-21 | 1994-12-22 | American Teleph & Telegr Co <Att> | プログラム実行分割装置およびクライアント・サーバシステム |
| JPH1049539A (ja) * | 1996-07-31 | 1998-02-20 | Matsushita Electric Ind Co Ltd | データベース管理システム |
| JPH10511794A (ja) * | 1995-09-15 | 1998-11-10 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | クライアント−サーバ環境用ブリッジ |
| JP2002215503A (ja) * | 2001-01-17 | 2002-08-02 | Sony Corp | 変換装置及び方法、課金方法、並びにスクリプト変換システム及び方法 |
| JP2004533046A (ja) * | 2001-03-21 | 2004-10-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プラグ対応認可システムに対するサーバサポート方法およびシステム |
-
1991
- 1991-10-23 JP JP3274420A patent/JPH05113959A/ja active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06348511A (ja) * | 1993-05-21 | 1994-12-22 | American Teleph & Telegr Co <Att> | プログラム実行分割装置およびクライアント・サーバシステム |
| JPH10511794A (ja) * | 1995-09-15 | 1998-11-10 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | クライアント−サーバ環境用ブリッジ |
| JPH1049539A (ja) * | 1996-07-31 | 1998-02-20 | Matsushita Electric Ind Co Ltd | データベース管理システム |
| JP2002215503A (ja) * | 2001-01-17 | 2002-08-02 | Sony Corp | 変換装置及び方法、課金方法、並びにスクリプト変換システム及び方法 |
| JP4644940B2 (ja) * | 2001-01-17 | 2011-03-09 | ソニー株式会社 | 課金方法、並びにスクリプト変換システム及び方法 |
| JP2004533046A (ja) * | 2001-03-21 | 2004-10-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プラグ対応認可システムに対するサーバサポート方法およびシステム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2308772C (en) | Method and system for facilitating distributed software development in a distribution unaware manner | |
| JP3866768B2 (ja) | ハイパーメディアインタラクティブを形成する方法及び装置 | |
| US5864669A (en) | Method and system for accessing a particular instantiation of a server process | |
| EP1061432B1 (en) | Distributed authentication mechanisms for handling diverse authentication systems in an enterprise computer system | |
| EP1027796B1 (en) | Distributed web application server | |
| JP4729172B2 (ja) | 宣言型パラダイムをサポートするステートレスなウェブ環境におけるトランザクションを実行するための方法および装置 | |
| US5566326A (en) | Copy file mechanism for transferring files between a host system and an emulated file system | |
| US20020144009A1 (en) | System and method for common information model object manager proxy interface and management | |
| US7610388B2 (en) | System, method and program for coordinating timeouts for distributed servers | |
| TWI762293B (zh) | 安全的服務請求處理方法及裝置 | |
| CN110650216B (zh) | 云服务请求方法和装置 | |
| CN102497453A (zh) | 远端程序的调用装置和调用方法 | |
| US7970814B2 (en) | Method and apparatus for providing a synchronous interface for an asynchronous service | |
| JPH08314863A (ja) | コンピュータネットワークにおけるセキュリティ方式 | |
| US5913027A (en) | Data processing method for a computer system including computers connected via a communication path to each other and computer-readable recording media for use with the computers | |
| JPH05113959A (ja) | リモ−トプロシジヤコ−ル要求代行処理方法および装置 | |
| JP2002505491A (ja) | 分散形システムにおける動的情報証明のための装置及び方法 | |
| EP1468544B1 (en) | Method and apparatus for controlling a multi-node process | |
| CN114338130A (zh) | 信息的处理方法、装置、服务器及存储介质 | |
| CN113987035A (zh) | 区块链的外部数据访问方法、装置、系统、设备和介质 | |
| US20080256608A1 (en) | Linking Between Internet Subscription Websites | |
| CN113934383B (zh) | 将云打印机与业务绑定的方法、装置、服务器及存储介质 | |
| JP2819858B2 (ja) | 情報処理ステーション | |
| JP2757834B2 (ja) | サーバ・クライアントコンピュータシステムにおけるアプリケーションプログラムの実行方法および実行装置 | |
| CN113760401A (zh) | 目标数据发送方法、装置、电子设备和计算机可读介质 |