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)【要約】
【目的】 リモ−トプロシジャコ−ルにおいて、プロシ
ジャ要求側とプロシジャ実行側との間に代行するシステ
ムを配置して、プロシジャ要求側の処理負担を軽減す
る。 【構成】 プロシジャ要求側とプロシジャ実行側との間
にRPC要求代行処理装置を配置し、その中にプロシジ
ャディレクトリとクライアント/サ−バディレクトリと
各プロシジャ毎の共用メモリとRPC処理装置とを設け
る。RPC要求代行処理装置は、プロシジャ要求側から
要求を受け取り、プロシジャディレクトリを参照してプ
ロシジャ実行側を決定し、実行を要求する。そして、実
行結果を受け取ると、クライアント/サ−バディレクト
リを用いてプロシジャ要求側の認証、およびデ−タ変換
処理を実行する。
ジャ要求側とプロシジャ実行側との間に代行するシステ
ムを配置して、プロシジャ要求側の処理負担を軽減す
る。 【構成】 プロシジャ要求側とプロシジャ実行側との間
にRPC要求代行処理装置を配置し、その中にプロシジ
ャディレクトリとクライアント/サ−バディレクトリと
各プロシジャ毎の共用メモリとRPC処理装置とを設け
る。RPC要求代行処理装置は、プロシジャ要求側から
要求を受け取り、プロシジャディレクトリを参照してプ
ロシジャ実行側を決定し、実行を要求する。そして、実
行結果を受け取ると、クライアント/サ−バディレクト
リを用いてプロシジャ要求側の認証、およびデ−タ変換
処理を実行する。
Description
【0001】
【産業上の利用分野】本発明は、情報の分散処理方法に
関し、特に分散したシステムが各種のサ−ビスをプロシ
ジャの形で提供している場合の処理方法および処理装置
に関する。
関し、特に分散したシステムが各種のサ−ビスをプロシ
ジャの形で提供している場合の処理方法および処理装置
に関する。
【0002】
【従来の技術】従来より、リモ−トプロシジャコ−ル
(以下、RPC)自体は既に知られた技術であって、R
PCを実装した製品も使用されている。これらのRPC
では、プロシジャの要求側は通常プロシジャの実行側に
直接、プロシジャの要求を行っていた。図2は、従来の
RPCの形態を示す図であり、また図5は、従来のRP
Cにおけるプロシジャ要求側の処理の例を示すフロ−チ
ャ−トである。図2に示すように、プロシジャ要求側1
0は、個々のプロシジャの実行側毎(11,12,1
3)に一連の処理をする必要があった。すなわち、プロ
シジャの要求側10はディレクトリ等を用いてプロシジ
ャ実行側11,12,13の位置を知り、そのサ−バと
の通信を行ってプロシジャの処理要求を行い、処理され
た結果を返送してもらう。また、プロシジャの要求側1
0は、プロシジャの実行側11,12,13に必要に応
じて認証を行う。プロシジャの要求側10とプロシジャ
の実行側11〜13でデ−タの表現が異なると、プロシ
ジャの要求側10またはプロシジャの実行側11〜13
またはその両方で、デ−タ変換を行っていた。従って、
複数のプロシジャ実行側11〜13にプロシジャを要求
する場合には、プロシジャの要求側10は上記デ−タ変
換処理を各プロシジャ実行側毎に行う必要があった。
(以下、RPC)自体は既に知られた技術であって、R
PCを実装した製品も使用されている。これらのRPC
では、プロシジャの要求側は通常プロシジャの実行側に
直接、プロシジャの要求を行っていた。図2は、従来の
RPCの形態を示す図であり、また図5は、従来のRP
Cにおけるプロシジャ要求側の処理の例を示すフロ−チ
ャ−トである。図2に示すように、プロシジャ要求側1
0は、個々のプロシジャの実行側毎(11,12,1
3)に一連の処理をする必要があった。すなわち、プロ
シジャの要求側10はディレクトリ等を用いてプロシジ
ャ実行側11,12,13の位置を知り、そのサ−バと
の通信を行ってプロシジャの処理要求を行い、処理され
た結果を返送してもらう。また、プロシジャの要求側1
0は、プロシジャの実行側11,12,13に必要に応
じて認証を行う。プロシジャの要求側10とプロシジャ
の実行側11〜13でデ−タの表現が異なると、プロシ
ジャの要求側10またはプロシジャの実行側11〜13
またはその両方で、デ−タ変換を行っていた。従って、
複数のプロシジャ実行側11〜13にプロシジャを要求
する場合には、プロシジャの要求側10は上記デ−タ変
換処理を各プロシジャ実行側毎に行う必要があった。
【0003】図2に示すように、プロシジャ要求側10
と複数のプロシジャ実行側11〜13が直接プロシジャ
の要求を行う場合の動作は、図5に示すようなフロ−で
示される。先ず、プロシジャ要求側では、アプリケ−シ
ョンプログラム等から自システムにないプロシジャコ−
ルの要求が発生する(ステップ501)。プロシジャ要
求側は、そのプロシジャをどのプロシジャ実行側に依頼
するか、ディレクトリ等を使用して調べる(ステップ5
02)。プロシジャ要求側は、依頼先のプロシジャ実行
側に対する認証する準備をする(ステップ503)。プ
ロシジャ要求側は、次にプロシジャに使用する引数を標
準のデ−タ形式に変換する(ステップ504)。プロシ
ジャ要求側は、プロシジャ実行側に対してプロシジャの
実行要求を送信する(ステップ505)。この後、プロ
シジャ要求側は、プロシジャの実行結果を受け取る(ス
テップ506)。プロシジャ要求側は、実行結果のデ−
タを自システムで処理できる形に変換し(ステップ50
7)、アプリケ−ションプログラムにその結果を返す
(ステップ508)。プロシジャ要求側は、オプション
としてプロシジャ実行側に対して課金処理を行う(ステ
ップ509)。そして、再びステップ501に戻る。こ
こまでの処理が、1つのプロシジャに対する処理であ
る。いま、図2に示すように、異なる3つのプロシジャ
実行側に対して、それぞれプロシジャの実行要求を行う
場合には、図5に示す処理を3回繰り返す必要がある。
すなわち、プロシジャの数が多くなると、プロシジャ要
求側の負担は大きくなる。
と複数のプロシジャ実行側11〜13が直接プロシジャ
の要求を行う場合の動作は、図5に示すようなフロ−で
示される。先ず、プロシジャ要求側では、アプリケ−シ
ョンプログラム等から自システムにないプロシジャコ−
ルの要求が発生する(ステップ501)。プロシジャ要
求側は、そのプロシジャをどのプロシジャ実行側に依頼
するか、ディレクトリ等を使用して調べる(ステップ5
02)。プロシジャ要求側は、依頼先のプロシジャ実行
側に対する認証する準備をする(ステップ503)。プ
ロシジャ要求側は、次にプロシジャに使用する引数を標
準のデ−タ形式に変換する(ステップ504)。プロシ
ジャ要求側は、プロシジャ実行側に対してプロシジャの
実行要求を送信する(ステップ505)。この後、プロ
シジャ要求側は、プロシジャの実行結果を受け取る(ス
テップ506)。プロシジャ要求側は、実行結果のデ−
タを自システムで処理できる形に変換し(ステップ50
7)、アプリケ−ションプログラムにその結果を返す
(ステップ508)。プロシジャ要求側は、オプション
としてプロシジャ実行側に対して課金処理を行う(ステ
ップ509)。そして、再びステップ501に戻る。こ
こまでの処理が、1つのプロシジャに対する処理であ
る。いま、図2に示すように、異なる3つのプロシジャ
実行側に対して、それぞれプロシジャの実行要求を行う
場合には、図5に示す処理を3回繰り返す必要がある。
すなわち、プロシジャの数が多くなると、プロシジャ要
求側の負担は大きくなる。
【0004】
【発明が解決しようとする課題】このように、従来のR
PCでは、プロシジャの要求側がプロシジャの実行側の
位置の調査を行った後、プロシジャ実行側に対してプロ
シジャ実行要求を行い、その実行結果を受信するととも
に、プロシジャの要求側の認証、デ−タ変換の作業を行
う必要があった。また、複数のプロシジャ実行側にプロ
シジャの実行を要求する場合には、プロシジャの実行側
毎にそれぞれ上述の各処理を行う必要があるため、プロ
シジャ要求側の負担は極めて大きかった。本発明の目的
は、このような従来の課題を解決し、プロシジャ要求側
の負担を軽減することができるリモ−トプロシジャコ−
ル要求代行処理方法および装置を提供することにある。
PCでは、プロシジャの要求側がプロシジャの実行側の
位置の調査を行った後、プロシジャ実行側に対してプロ
シジャ実行要求を行い、その実行結果を受信するととも
に、プロシジャの要求側の認証、デ−タ変換の作業を行
う必要があった。また、複数のプロシジャ実行側にプロ
シジャの実行を要求する場合には、プロシジャの実行側
毎にそれぞれ上述の各処理を行う必要があるため、プロ
シジャ要求側の負担は極めて大きかった。本発明の目的
は、このような従来の課題を解決し、プロシジャ要求側
の負担を軽減することができるリモ−トプロシジャコ−
ル要求代行処理方法および装置を提供することにある。
【0005】
【課題を解決するための手段】上記目的を達成するた
め、本発明によるリモ−トプロシジャコ−ル要求代行処
理方法は、(イ)アプリケ−ションプログラムからリモ
−トプロシジャコ−ルを受け付けると、プロシジャ要求
代行処理装置は、プロシジャに関する情報を基にプロシ
ジャを実行するシステムへのプロシジャ実行要求を代行
し、プロシジャ実行の結果をプロシジャ実行側から受け
取ると、実行結果を該プロシジャ要求側に返し、この期
間中、プロシジャの要求側と実行側の間の認証、および
デ−タ変換を行うことに特徴がある。また、(ロ)プロ
シジャ要求代行処理装置は、プロシジャ要求側からの要
求に対して、プロシジャ実行側への課金に責任を持ち、
プロシジャ要求側に全体でかかった費用を請求すること
にも特徴がある。さらに、(ハ)本発明のリモ−トプロ
シジャコ−ル要求代行処理装置は、プロシジャ要求側か
ら要求されたプロシジャをどのプロシジャ実行側に要求
するかを決定する際に参照されるプロシジャディレクト
リと、プロシジャ要求側およびプロシジャ実行側でのデ
−タ表現形式を登録しておくクライアント/サ−バディ
レクトリと、各プロシジャ実行側で共通に参照する共用
変数および定数を格納しておく共用メモリと、プロシジ
ャディレクトリ、クライアント/サ−バディレクトリ、
および共用メモリを使用してリモ−トプロシジャコ−ル
要求代行処理を実行するプロシジャ処理装置とを有する
ことに特徴がある。
め、本発明によるリモ−トプロシジャコ−ル要求代行処
理方法は、(イ)アプリケ−ションプログラムからリモ
−トプロシジャコ−ルを受け付けると、プロシジャ要求
代行処理装置は、プロシジャに関する情報を基にプロシ
ジャを実行するシステムへのプロシジャ実行要求を代行
し、プロシジャ実行の結果をプロシジャ実行側から受け
取ると、実行結果を該プロシジャ要求側に返し、この期
間中、プロシジャの要求側と実行側の間の認証、および
デ−タ変換を行うことに特徴がある。また、(ロ)プロ
シジャ要求代行処理装置は、プロシジャ要求側からの要
求に対して、プロシジャ実行側への課金に責任を持ち、
プロシジャ要求側に全体でかかった費用を請求すること
にも特徴がある。さらに、(ハ)本発明のリモ−トプロ
シジャコ−ル要求代行処理装置は、プロシジャ要求側か
ら要求されたプロシジャをどのプロシジャ実行側に要求
するかを決定する際に参照されるプロシジャディレクト
リと、プロシジャ要求側およびプロシジャ実行側でのデ
−タ表現形式を登録しておくクライアント/サ−バディ
レクトリと、各プロシジャ実行側で共通に参照する共用
変数および定数を格納しておく共用メモリと、プロシジ
ャディレクトリ、クライアント/サ−バディレクトリ、
および共用メモリを使用してリモ−トプロシジャコ−ル
要求代行処理を実行するプロシジャ処理装置とを有する
ことに特徴がある。
【0006】
【作用】本発明においては、プロシジャの要求側が直接
に複数のプロシジャ実行側にプロシジャを要求する代り
に、プロシジャ要求側の代行者であるRPC要求代行処
理装置を配置して、この装置がサ−バとのやり取りを代
行することにより実現される。このように、RPC要求
代行処理装置は、プロシジャ実行側にプロシジャ実行の
依頼に関して、プロシジャ要求側の代行を行う。それに
より、(イ)プロシジャ要求側は、RPC要求代行処理
装置のみにプロシジャ実行要求を送出すればよいので、
プロシジャ要求側の作業が大幅に軽減される。また、
(ロ)特定のプロシジャを供与するプロシジャ実行側の
位置は、プロシジャディレクトリを参照することによ
り、RPC要求代行処理装置が決定される。それによ
り、プロシジャ要求側はどのプロシジャがどのプロシジ
ャ実行側で供与されるかを意識せずに要求を行うことが
できるので、要求側の処理は減少される。また、(ハ)
プロシジャ要求側とプロシジャ実行側のデ−タ表現の変
換は、クライアント/サ−バディレクトリを用いて、R
PC要求代行処理装置が行う。それによって、プロシジ
ャ要求側はデ−タの変換を行う必要がなくなるので、そ
れによっても要求側の処理は軽減する。さらに、(ニ)
各プロシジャ実行側への認証は、RPC要求代行処理装
置が実行する。これによっても、プロシジャ要求側はR
PC要求代行処理装置に対してのみ認証を行うだけでよ
いので、処理は軽減する。さらに、(ホ)各プロシジャ
実行側への課金は、RPC要求代行処理装置が対応する
ので、プロシジャ要求側は、RPC要求代行処理装置に
対しての課金処理のみでよく、これによっても処理は軽
減される。
に複数のプロシジャ実行側にプロシジャを要求する代り
に、プロシジャ要求側の代行者であるRPC要求代行処
理装置を配置して、この装置がサ−バとのやり取りを代
行することにより実現される。このように、RPC要求
代行処理装置は、プロシジャ実行側にプロシジャ実行の
依頼に関して、プロシジャ要求側の代行を行う。それに
より、(イ)プロシジャ要求側は、RPC要求代行処理
装置のみにプロシジャ実行要求を送出すればよいので、
プロシジャ要求側の作業が大幅に軽減される。また、
(ロ)特定のプロシジャを供与するプロシジャ実行側の
位置は、プロシジャディレクトリを参照することによ
り、RPC要求代行処理装置が決定される。それによ
り、プロシジャ要求側はどのプロシジャがどのプロシジ
ャ実行側で供与されるかを意識せずに要求を行うことが
できるので、要求側の処理は減少される。また、(ハ)
プロシジャ要求側とプロシジャ実行側のデ−タ表現の変
換は、クライアント/サ−バディレクトリを用いて、R
PC要求代行処理装置が行う。それによって、プロシジ
ャ要求側はデ−タの変換を行う必要がなくなるので、そ
れによっても要求側の処理は軽減する。さらに、(ニ)
各プロシジャ実行側への認証は、RPC要求代行処理装
置が実行する。これによっても、プロシジャ要求側はR
PC要求代行処理装置に対してのみ認証を行うだけでよ
いので、処理は軽減する。さらに、(ホ)各プロシジャ
実行側への課金は、RPC要求代行処理装置が対応する
ので、プロシジャ要求側は、RPC要求代行処理装置に
対しての課金処理のみでよく、これによっても処理は軽
減される。
【0007】
【実施例】以下、本発明の実施例を、図面により詳細に
説明する。図1は、本発明の一実施例を示すRPC要求
代行処理装置とプロシジャ要求側および実行側との関係
を示す図である。図1に示すように、本実施例において
は、プロシジャ要求側6とプロシジャ実行側7〜9との
間に、RPC要求代行処理装置1を導入する。RPC要
求代行処理装置1は、RPCの処理を行うRPC処理装
置5と、プロシジャディレクトリ2と、クライアント/
サ−バディレクトリ3と、RPC処理装置5に接続され
た共用メモリ4とから構成される。RPC要求代行処理
装置1のうち、RPC処理装置5は、プロシジャディレ
クトリ2を用いてプロシジャ実行側の位置を決定し、ク
ライアント/サ−バディレクトリ3を用いて要求側と実
行側のデ−タ表現の変換を行う。また、プロシジャ要求
側から認証を受け取った後、これに基づいてプロシジャ
実行側の各々に対して認証を行う。さらに、プロシジャ
要求側から課金されることにより、それに基づいてプロ
シジャ実行側の各々に対して課金を行う。
説明する。図1は、本発明の一実施例を示すRPC要求
代行処理装置とプロシジャ要求側および実行側との関係
を示す図である。図1に示すように、本実施例において
は、プロシジャ要求側6とプロシジャ実行側7〜9との
間に、RPC要求代行処理装置1を導入する。RPC要
求代行処理装置1は、RPCの処理を行うRPC処理装
置5と、プロシジャディレクトリ2と、クライアント/
サ−バディレクトリ3と、RPC処理装置5に接続され
た共用メモリ4とから構成される。RPC要求代行処理
装置1のうち、RPC処理装置5は、プロシジャディレ
クトリ2を用いてプロシジャ実行側の位置を決定し、ク
ライアント/サ−バディレクトリ3を用いて要求側と実
行側のデ−タ表現の変換を行う。また、プロシジャ要求
側から認証を受け取った後、これに基づいてプロシジャ
実行側の各々に対して認証を行う。さらに、プロシジャ
要求側から課金されることにより、それに基づいてプロ
シジャ実行側の各々に対して課金を行う。
【0008】図1において、プロシジャ要求側6は、R
PC要求代行処理装置1に直接プロシジャの要求を依頼
する。RPC要求代行処理装置1は、個々のプロシジャ
がどこで実行可能であるかという情報を保持するプロシ
ジャディレクトリ2を備えている。なお、このプロシジ
ャディレクトリ2は、RPC要求代行処理装置1と同じ
システム内にあるとは限らない。すなわち、RPC要求
代行処理装置1は一般のディレクトリを利用することに
よっても、同じサ−ビスを提供することができる。RP
C要求代行処理装置1は、プロシジャディレクトリ2の
情報を使用して、プロシジャ要求側が要求したプロシジ
ャをどのプロシジャ実行側に要求するかを決定し、プロ
シジャの実行要求を送出する。プロシジャ実行側からプ
ロシジャの実行結果を受け取り、これをプロシジャの要
求側6に返送する。また、プロシジャ要求側とプロシジ
ャ実行側でデ−タ表現が異なる場合には、次の処理を行
う。すなわち、先ず、クライアント/サ−バディレクト
リ3で、プロシジャ要求側6とプロシジャ実行側7〜9
でのデ−タ表現形式を登録しておく。プロシジャ要求側
6がRPC要求代行処理装置1にプロシジャを要求する
と、RPC要求代行処理装置1はクライアント/サ−バ
ディレクトリ3の情報を参照し、プロシジャ要求側6の
デ−タ表現をプロシジャ実行側7〜9のデ−タ表現に変
換した後に、プロシジャ実行側7〜9にこれらの要求を
送出する。プロシジャ実行の結果の転送時には、上述の
逆の変換を行う。これにより、プロシジャの要求側6お
よび実行側7〜9でデ−タ表現の変換処理を行う必要が
なく、プロシジャの要求側6および実行側7〜9の処理
は軽減される。
PC要求代行処理装置1に直接プロシジャの要求を依頼
する。RPC要求代行処理装置1は、個々のプロシジャ
がどこで実行可能であるかという情報を保持するプロシ
ジャディレクトリ2を備えている。なお、このプロシジ
ャディレクトリ2は、RPC要求代行処理装置1と同じ
システム内にあるとは限らない。すなわち、RPC要求
代行処理装置1は一般のディレクトリを利用することに
よっても、同じサ−ビスを提供することができる。RP
C要求代行処理装置1は、プロシジャディレクトリ2の
情報を使用して、プロシジャ要求側が要求したプロシジ
ャをどのプロシジャ実行側に要求するかを決定し、プロ
シジャの実行要求を送出する。プロシジャ実行側からプ
ロシジャの実行結果を受け取り、これをプロシジャの要
求側6に返送する。また、プロシジャ要求側とプロシジ
ャ実行側でデ−タ表現が異なる場合には、次の処理を行
う。すなわち、先ず、クライアント/サ−バディレクト
リ3で、プロシジャ要求側6とプロシジャ実行側7〜9
でのデ−タ表現形式を登録しておく。プロシジャ要求側
6がRPC要求代行処理装置1にプロシジャを要求する
と、RPC要求代行処理装置1はクライアント/サ−バ
ディレクトリ3の情報を参照し、プロシジャ要求側6の
デ−タ表現をプロシジャ実行側7〜9のデ−タ表現に変
換した後に、プロシジャ実行側7〜9にこれらの要求を
送出する。プロシジャ実行の結果の転送時には、上述の
逆の変換を行う。これにより、プロシジャの要求側6お
よび実行側7〜9でデ−タ表現の変換処理を行う必要が
なく、プロシジャの要求側6および実行側7〜9の処理
は軽減される。
【0009】クライアント/サ−バディレクトリ3に登
録されていないプロシジャ要求側またはプロシジャ実行
側と、RPC要求代行処理装置1との通信では、標準の
デ−タ形式を使用する。RPC要求代行処理装置1内に
は共用メモリ4が配置される。これは、各プロシジャ実
行側7〜9で共通に参照する共用変数、定数を格納して
おくものである。これにより、異なるシステムに存在す
るプロシジャ実行側でのプロシジャ間の通信が、RPC
ライブラリの共用メモリ4を介して可能となる。また、
従来では、個々のプロシジャ要求側は、それぞれのプロ
シジャ実行側に対して認証(自分の身元確認)を行う必
要があった。しかしながら、本実施例では、プロシジャ
の要求側6はRPC要求代行処理装置1に対してのみ認
証を行う。また、RPC要求代行処理装置1は、信頼で
きるサ−バとしての機能を備えている。すなわち、RP
C要求代行処理装置1はプロシジャ要求側6を認証する
と、プロシジャ要求側6の身元をプロシジャ実行側7〜
9に保証して、プロシジャ実行側7〜9との間は、RP
C要求代行処理装置1自身の認証のみを行う。これによ
って、プロシジャ要求側6は、1回だけRPC要求代行
処理装置1に対して認証するだけですむので、負担が軽
減される。プロシジャ要求側6とプロシジャ実行側7〜
9での課金についても、従来では、プロシジャ要求側6
がそれぞれのプロシジャ実行側7〜9に課金していた
が、本実施例では、プロシジャ要求側6はRPC要求代
行処理装置1に対してのみ課金を行えばすむ。RPC要
求代行処理装置1は、プロシジャ実行側7〜9に対する
課金に責任を持ち、プロシジャ要求側6に全体でかかっ
た費用を請求する。これによって、プロシジャ要求側6
の課金処理は軽減され、単純化される。
録されていないプロシジャ要求側またはプロシジャ実行
側と、RPC要求代行処理装置1との通信では、標準の
デ−タ形式を使用する。RPC要求代行処理装置1内に
は共用メモリ4が配置される。これは、各プロシジャ実
行側7〜9で共通に参照する共用変数、定数を格納して
おくものである。これにより、異なるシステムに存在す
るプロシジャ実行側でのプロシジャ間の通信が、RPC
ライブラリの共用メモリ4を介して可能となる。また、
従来では、個々のプロシジャ要求側は、それぞれのプロ
シジャ実行側に対して認証(自分の身元確認)を行う必
要があった。しかしながら、本実施例では、プロシジャ
の要求側6はRPC要求代行処理装置1に対してのみ認
証を行う。また、RPC要求代行処理装置1は、信頼で
きるサ−バとしての機能を備えている。すなわち、RP
C要求代行処理装置1はプロシジャ要求側6を認証する
と、プロシジャ要求側6の身元をプロシジャ実行側7〜
9に保証して、プロシジャ実行側7〜9との間は、RP
C要求代行処理装置1自身の認証のみを行う。これによ
って、プロシジャ要求側6は、1回だけRPC要求代行
処理装置1に対して認証するだけですむので、負担が軽
減される。プロシジャ要求側6とプロシジャ実行側7〜
9での課金についても、従来では、プロシジャ要求側6
がそれぞれのプロシジャ実行側7〜9に課金していた
が、本実施例では、プロシジャ要求側6はRPC要求代
行処理装置1に対してのみ課金を行えばすむ。RPC要
求代行処理装置1は、プロシジャ実行側7〜9に対する
課金に責任を持ち、プロシジャ要求側6に全体でかかっ
た費用を請求する。これによって、プロシジャ要求側6
の課金処理は軽減され、単純化される。
【0010】図3は、図1におけるプロシジャディレク
トリの内容例を示す図である。プロシジャディレクトリ
2には、プロシジャ名またはプロシジャを一意に識別す
る識別子と、そのプロシジャを供与するプロシジャ実行
側の位置情報睡のプロシジャに関する情報が登録されて
いる。図4は、図1におけるクライアント/サ−バディ
レクトリの内容例を示す図である。クライアント/サ−
バディレクトリ3には、プロシジャ要求側6およびプロ
シジャ実行側7〜9に関するデ−タ表現等の情報が登録
されている。例えば、プロシジャ実行側のシステム1
は、IEEEの浮動小数点およびASCIIの文字コ−
ドを使用している。プロシジャ実行側のシステム2は、
IBM形式の浮動小数点とEBCDICの文字コ−ドを
使用している。このように、各システム毎のデ−タ表
現、認証、課金等の情報をクライアント/サ−バディレ
クトリ3に登録しておく。共用メモリ4は、各プロシジ
ャ間での連絡に使用される。あるアプリケ−ションプロ
グラムが複数のプロシジャを呼び出す場合、そのプロシ
ジャ間での連絡のためにこの共用メモリ4を使用する。
トリの内容例を示す図である。プロシジャディレクトリ
2には、プロシジャ名またはプロシジャを一意に識別す
る識別子と、そのプロシジャを供与するプロシジャ実行
側の位置情報睡のプロシジャに関する情報が登録されて
いる。図4は、図1におけるクライアント/サ−バディ
レクトリの内容例を示す図である。クライアント/サ−
バディレクトリ3には、プロシジャ要求側6およびプロ
シジャ実行側7〜9に関するデ−タ表現等の情報が登録
されている。例えば、プロシジャ実行側のシステム1
は、IEEEの浮動小数点およびASCIIの文字コ−
ドを使用している。プロシジャ実行側のシステム2は、
IBM形式の浮動小数点とEBCDICの文字コ−ドを
使用している。このように、各システム毎のデ−タ表
現、認証、課金等の情報をクライアント/サ−バディレ
クトリ3に登録しておく。共用メモリ4は、各プロシジ
ャ間での連絡に使用される。あるアプリケ−ションプロ
グラムが複数のプロシジャを呼び出す場合、そのプロシ
ジャ間での連絡のためにこの共用メモリ4を使用する。
【0011】図6は、本発明の一実施例を示すプロシジ
ャ要求側の処理フロ−チャ−トである。先ず、プロシジ
ャの要求側6は、RPC要求代行処理装置1に対して認
証を行う(ステップ601)。プロシジャ要求側6内で
アプリケ−ションプログラム等からプロシジャコ−ルが
発生すると(ステップ602)、プロシジャ要求側6は
RPC要求代行処理装置1に対してプロシジャの実行要
求を送る(ステップ603)。プロシジャ要求側6は、
RPC要求代行処理装置1からプロシジャの実行結果を
受け取る(ステップ604)。プロシジャの結果をアプ
リケ−ションプログラム等に返す(ステップ605)。
また、他のプロシジャコ−ルがあれば、ステップ602
に戻る。他にプロシジャコ−ルがなければ、今回使用し
たプロシジャに対する課金処理を行う(ステップ60
6)。このように、本実施例においては、従来の方法に
比べて、プロシジャ要求側の処理の負担が大幅に軽減さ
れている。
ャ要求側の処理フロ−チャ−トである。先ず、プロシジ
ャの要求側6は、RPC要求代行処理装置1に対して認
証を行う(ステップ601)。プロシジャ要求側6内で
アプリケ−ションプログラム等からプロシジャコ−ルが
発生すると(ステップ602)、プロシジャ要求側6は
RPC要求代行処理装置1に対してプロシジャの実行要
求を送る(ステップ603)。プロシジャ要求側6は、
RPC要求代行処理装置1からプロシジャの実行結果を
受け取る(ステップ604)。プロシジャの結果をアプ
リケ−ションプログラム等に返す(ステップ605)。
また、他のプロシジャコ−ルがあれば、ステップ602
に戻る。他にプロシジャコ−ルがなければ、今回使用し
たプロシジャに対する課金処理を行う(ステップ60
6)。このように、本実施例においては、従来の方法に
比べて、プロシジャ要求側の処理の負担が大幅に軽減さ
れている。
【0012】図7は、本発明の一実施例を示すRPC要
求代行処理装置の処理フロ−チャ−トである。先ず、R
PC要求代行処理装置1は、プロシジャ要求側6の認証
を行う(ステップ701)。プロシジャ要求側6からの
プロシジャ要求があれば(ステップ702)、これを受
け付け、プロシジャディレクトリ2を用いてプロシジャ
を供与しているプロシジャ実行側7〜9の位置を調べる
(ステップ703)。RPC要求代行処理装置1は、プ
ロシジャ実行側7〜9に対して認証の準備を行う(ステ
ップ704)。RPC要求代行処理装置1は、クライア
ント/サ−バディレクトリ3を用いて、プロシジャ要求
側6とプロシジャ実行側7〜9のデ−タ表現を調べる。
そして、プロシジャの引数をプロシジャ要求側6のデ−
タ表現からプロシジャ実行側7〜9のデ−タ表現に変換
する(ステップ705)。RPC要求代行処理装置1
は、この変換したデ−タを使用してプロシジャ実行側7
〜9にプロシジャの実行を依頼する(ステップ70
6)。RPC要求代行処理装置1は、プロシジャ実行側
6からプロシジャの結果を受け取る(ステップ70
7)。RPC要求代行処理装置1は、プロシジャ実行側
7〜9に対して、オプションとして課金処理を行う場合
もある(ステップ708)。RPC要求代行処理装置1
は、結果のパラメタをプロシジャ実行側7〜9のデ−タ
表現からプロシジャ要求側6のデ−タ表現に変換する
(ステップ709)。RPC要求代行処理装置1は、プ
ロシジャの結果をプロシジャ要求側6に送出する。も
し、プロシジャ要求側6から他のプロシジャ要求があれ
ば、ステップ702に戻る。もし、プロシジャ要求がな
ければ、オプションとして、プロシジャ要求側6に課金
処理を行う場合もある(ステップ710)。
求代行処理装置の処理フロ−チャ−トである。先ず、R
PC要求代行処理装置1は、プロシジャ要求側6の認証
を行う(ステップ701)。プロシジャ要求側6からの
プロシジャ要求があれば(ステップ702)、これを受
け付け、プロシジャディレクトリ2を用いてプロシジャ
を供与しているプロシジャ実行側7〜9の位置を調べる
(ステップ703)。RPC要求代行処理装置1は、プ
ロシジャ実行側7〜9に対して認証の準備を行う(ステ
ップ704)。RPC要求代行処理装置1は、クライア
ント/サ−バディレクトリ3を用いて、プロシジャ要求
側6とプロシジャ実行側7〜9のデ−タ表現を調べる。
そして、プロシジャの引数をプロシジャ要求側6のデ−
タ表現からプロシジャ実行側7〜9のデ−タ表現に変換
する(ステップ705)。RPC要求代行処理装置1
は、この変換したデ−タを使用してプロシジャ実行側7
〜9にプロシジャの実行を依頼する(ステップ70
6)。RPC要求代行処理装置1は、プロシジャ実行側
6からプロシジャの結果を受け取る(ステップ70
7)。RPC要求代行処理装置1は、プロシジャ実行側
7〜9に対して、オプションとして課金処理を行う場合
もある(ステップ708)。RPC要求代行処理装置1
は、結果のパラメタをプロシジャ実行側7〜9のデ−タ
表現からプロシジャ要求側6のデ−タ表現に変換する
(ステップ709)。RPC要求代行処理装置1は、プ
ロシジャの結果をプロシジャ要求側6に送出する。も
し、プロシジャ要求側6から他のプロシジャ要求があれ
ば、ステップ702に戻る。もし、プロシジャ要求がな
ければ、オプションとして、プロシジャ要求側6に課金
処理を行う場合もある(ステップ710)。
【0013】図8は、本発明の一実施例を示すプロシジ
ャ実行側の処理フロ−チャ−トである。プロシジャ実行
側7〜9は、RPC要求代行処理装置1の認証を確認す
る(ステップ801)。次にプロシジャ実行側7〜9
は、RPC要求代行処理装置1からプロシジャの実行の
要求を受け付ける(ステップ802)。プロシジャ実行
側7〜9は、要求されたプロシジャを実行する(ステッ
プ803)。そして、実行結果をRPC要求代行処理装
置1に返送する(ステップ804)。そして、他のプロ
シジャ要求がないか否かを調べ、あればステップ802
に戻って、受け付けを行う。もし、プロシジャ要求がな
ければ、オプションとして、RPC要求代行処理装置1
に対する課金処理を行う(ステップ805)。これによ
り、本実施例では、従来のプロシジャ実行側に比べてデ
−タ変換がない分だけ、処理が軽減される。なお、全体
として、課金処理はプロシジャの要求毎に行う場合と、
ある一定期間毎に行う場合とがある。
ャ実行側の処理フロ−チャ−トである。プロシジャ実行
側7〜9は、RPC要求代行処理装置1の認証を確認す
る(ステップ801)。次にプロシジャ実行側7〜9
は、RPC要求代行処理装置1からプロシジャの実行の
要求を受け付ける(ステップ802)。プロシジャ実行
側7〜9は、要求されたプロシジャを実行する(ステッ
プ803)。そして、実行結果をRPC要求代行処理装
置1に返送する(ステップ804)。そして、他のプロ
シジャ要求がないか否かを調べ、あればステップ802
に戻って、受け付けを行う。もし、プロシジャ要求がな
ければ、オプションとして、RPC要求代行処理装置1
に対する課金処理を行う(ステップ805)。これによ
り、本実施例では、従来のプロシジャ実行側に比べてデ
−タ変換がない分だけ、処理が軽減される。なお、全体
として、課金処理はプロシジャの要求毎に行う場合と、
ある一定期間毎に行う場合とがある。
【0014】
【発明の効果】以上説明したように、本発明によれば、
RPC要求代行処理装置を導入したことにより、プロシ
ジャ要求側の処理が大幅に軽減されるので、パ−ソナル
コンピュ−タ等の安価な小型機器でも、リモ−トプロシ
ジャコ−ルを実現することができる。また、本発明によ
れば、プロシジャ実行側でプロシジャの存在する場所を
意識する必要がない。
RPC要求代行処理装置を導入したことにより、プロシ
ジャ要求側の処理が大幅に軽減されるので、パ−ソナル
コンピュ−タ等の安価な小型機器でも、リモ−トプロシ
ジャコ−ルを実現することができる。また、本発明によ
れば、プロシジャ実行側でプロシジャの存在する場所を
意識する必要がない。
【0015】
【図1】本発明の一実施例を示すRPC要求代行処理装
置とプロシジャ要求側、実行側の接続関係図である。
置とプロシジャ要求側、実行側の接続関係図である。
【図2】従来のリモ−トプロシジャコ−ルの要求側と実
行側の接続関係図である。
行側の接続関係図である。
【図3】図1におけるプロシジャディレクトリの内容例
を示す図である。
を示す図である。
【図4】図1におけるクライアント/サ−バディレクト
リの内容例を示す図である。
リの内容例を示す図である。
【図5】従来のリモ−トプロシジャコ−ルのプロシジャ
要求側の処理フロ−チャ−トである。
要求側の処理フロ−チャ−トである。
【図6】本発明の一実施例を示すプロシジャ要求側の処
理フロ−チャ−トである。
理フロ−チャ−トである。
【図7】本発明の一実施例を示すRPC要求代行処理装
置の処理フロ−チャ−トである。
置の処理フロ−チャ−トである。
【図8】本発明の一実施例を示すプロシジャ実行側の処
理フロ−チャ−トである。
理フロ−チャ−トである。
1 RPC要求代行処理装置 2 プロシジャディレクトリ 3 クライアント/サ−バディレクトリ 4 共用メモリ 5 RPC処理装置 6 プロシジャ要求側 7〜9 プロシジャ実行側A,B,C 10 プロシジャ要求側 11〜13 プロシジャ実行側A,B,C
Claims (3)
- 【請求項1】 プロシジャ要求側のアプリケ−ションプ
ログラムからリモ−トプロシジャコ−ルを受け付ける
と、プロシジャ要求代行処理装置は、プロシジャに関す
る情報を基に該プロシジャを実行するシステムへのプロ
シジャ実行要求を代行し、プロシジャ実行の結果をプロ
シジャ実行側から受け取ると、実行結果を該プロシジャ
要求側に返し、この期間中、プロシジャの要求側と実行
側の間の認証、およびデ−タ変換を行うことを特徴とす
るリモ−トプロシジャコ−ル要求代行処理方法。 - 【請求項2】 請求項1に記載のリモ−トプロシジャコ
−ル要求代行処理方法において、上記プロシジャ要求代
行処理装置は、プロシジャ要求側からの要求に対して、
プロシジャ実行側への課金に責任を持ち、プロシジャ要
求側に全体でかかった費用を請求することを特徴とする
リモ−トプロシジャコ−ル要求代行処理方法。 - 【請求項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) | 宣言型パラダイムをサポートするステートレスなウェブ環境におけるトランザクションを実行するための方法および装置 | |
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 | |
CN113190360A (zh) | 基于云平台的物流数据共享方法、装置、设备及存储介质 | |
JPH08314863A (ja) | コンピュータネットワークにおけるセキュリティ方式 | |
JPH05113959A (ja) | リモ−トプロシジヤコ−ル要求代行処理方法および装置 | |
JP2002505491A (ja) | 分散形システムにおける動的情報証明のための装置及び方法 | |
EP1468544B1 (en) | Method and apparatus for controlling a multi-node process | |
CN114338130A (zh) | 信息的处理方法、装置、服务器及存储介质 | |
CN113987035A (zh) | 区块链的外部数据访问方法、装置、***、设备和介质 | |
US7603407B2 (en) | Method and system for registering binary data | |
US20080256608A1 (en) | Linking Between Internet Subscription Websites | |
CN113934383B (zh) | 将云打印机与业务绑定的方法、装置、服务器及存储介质 | |
JP2819858B2 (ja) | 情報処理ステーション | |
JP2757834B2 (ja) | サーバ・クライアントコンピュータシステムにおけるアプリケーションプログラムの実行方法および実行装置 | |
JP2002157232A (ja) | データ処理システム |