(57)【特許請求の範囲】
【請求項１】
リモート・ノード上で実行されるアプリケーション・プログラムから、コンピュータ・ネットワーク内のサーバ・ノードにあるところの、複数のサービス・プロシージャの１つをコールするための方法であって、前記アプリケーション・プログラムは第１のスタブ・ファイルを利用して、前記サーバ・ノードにある第２のスタブ・ファイルをコールし、
該方法は、
前記アプリケーション・プログラムのリクエストに応じて、一つの汎用のクライアント・スタブ・ファイルを、一つの前記リモート・ノードによって呼び出すステップと、
前記呼び出された一つの汎用のクライアント・スタブ・ファイルに情報パラメータを、一つの前記リモート・ノード上によって渡すステップであって、前記情報パラメータは、リモート・プロシージャ・コールが有する数のパラメータを含む、前記渡すステップと、
前記第１のスタブ・ファイル・メッセージとして働くように、前記呼び出された一つの汎用のクライアント・スタブ・ファイルを前記渡された情報パラメータでもって、一つの前記リモート・ノードによってカストマイズするステップであって、前記情報パラメータは前記複数のサービス・プロシージャの１つに対応する、前記カストマイズするステップと、
前記一つの汎用のサーバ・スタブ・ファイルに前記コンピュータ・ネットワークを通して前記第１のスタブ・ファイル・メッセージを、一つの前記リモート・ノードによって送信するステップと、
第２のスタブ・ファイル・メッセージとして働くように、前記一つの汎用のサーバ・スタブ・ファイルを前記第１のスタブ・ファイル・メッセージ内の前記情報パラメータでもって、一つの前記サーバ・ノードによってカストマイズするステップと、
前記第２のスタブ・ファイル・メッセージを前記一つの第２のスタブ・ファイル・メッセージから前記サーバ・ノード内に、一つの前記サーバ・ノードによって転送して、前記複数のサービス・プロシージャの前記１つを検索するステップと、
前記アプリケーション・プログラムによって利用されるように前記検索された複数のサービス・プロシージャの１つを、一つの前記サーバ・ノードによって準備するステップと、
前記アプリケーション・プログラムに制御を、一つの前記サーバ・ノードによって戻すステップと
を含み、
それによって、前記複数のサービス・プロシージャの１つが前記アプリケーション・プログラムによって利用される、前記方法。
【請求項２】
リモート・ノード上で実行されるアプリケーション・プログラムから、コンピュータ・ネットワーク内のサーバ・ノードにあるところの、複数のサービス・プロシージャの１つをコールするためのシステムであって、前記アプリケーション・プログラムは第１のスタブ・ファイルを利用して、前記サーバ・ノードにある第２のスタブ・ファイルをコールし、
一つの前記リモート・ノードが、
前記アプリケーション・プログラムのリクエストに応じて、一つの汎用のクライアント・スタブ・ファイルを呼び出す手段と、
前記呼び出された一つの汎用のクライアント・スタブ・ファイルに情報パラメータを渡す手段であって、前記情報パラメータは、リモート・プロシージャ・コールが有する数のパラメータを含む、前記渡す手段と、
前記第１のスタブ・ファイル・メッセージとして働くように、前記呼び出された一つの汎用のクライアント・スタブ・ファイルを前記渡された情報パラメータでもってカストマイズする手段であって、前記情報パラメータは前記複数のサービス・プロシージャの１つに対応する、前記カストマイズする手段と、
一つの前記リモートが、前記一つの汎用のサーバ・スタブ・ファイルに前記コンピュータ・ネットワークを通して前記第１のスタブ・ファイル・メッセージを送信する手段と、
を含み、
１つの前記サーバ・ノードが、
第２のスタブ・ファイル・メッセージとして働くように、前記一つの汎用のサーバ・スタブ・ファイルを前記第１のスタブ・ファイル・メッセージ内の前記情報パラメータでもってカストマイズする手段と、
前記第２のスタブ・ファイル・メッセージを前記一つの第２のスタブ・ファイル・メッセージから前記サーバ・ノード内に転送して、前記複数のサービス・プロシージャの前記１つを検索する手段と、
前記アプリケーション・プログラムによって利用されるように前記検索された複数のサービス・プロシージャの１つを準備する手段と、
前記アプリケーション・プログラムに制御を戻す手段と、
を含み、
それによって前記複数のサービス・プロシージャの１つが前記アプリケーション・プログラムによって利用される、前記システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、概して云えば、ネットワークを介した通信に関するものであり、詳しく云えば、ネットワーク・システムを介してコール及びレスポンスを転送するためのプロシージャを標準化することに関するものである。更に詳しく云えば、本発明は、ネットワーク・システムを介してクライアントとサーバとの間でリモート・プロシージャ・コール及びレスポンスを転送し、従って、一般には各サーバ及びクライアントにとって必要な個々のプログラム・モジュールを排除するためのストリームライン化した方法に関するものである。
【０００２】
【従来の技術】
ネットワーク分散に対していくつもの標準がある。そのような標準の１つは、分散コンピューティング環境（ＤＣＥ）を開発した米国のオープン・ソフトウエア財団（ＯＳＦ）によって開発された。ＤＣＥは、クライアント／サーバ・ネットワークにおける通信を容易にするためにＤＣＥリモート・プロシージャ・コール（ＲＰＣ）を提供している。アプリケーションは、ＤＣＥを使用してネットワーク上に分散される。ディレクトリ、セキュリティ、及びタイム・サービスのような他のすべてのＤＣＥコンポーネントは、それ自身、ＤＣＥ  ＲＰＣを使用するＤＣＥアプリケーションである。
【０００３】
ＤＣＥクライアント・アプリケーションは１つ又は複数個のＲＰＣインターフェースをインポートする。クライアントは、ＲＰＣインターフェースにおいて定義されたオペレーションに関するＲＰＣをサーバによりエクスポートさせることによってサーバ・サービスをアクセスする。ＲＰＣコンパイラはクライアント・スタブ・ルーチン及びサーバ・スタブ・ルーチンを生成して、リモート・プロシージャ・コール・オペレーションのためのデータを処理する。スタブ・ルーチンは、クライアントとサーバとの間でリモート・プロシージャ・コール及びレスポンスを転送するプログラム・モジュールである。
【０００４】
通常、クライアント・スタブ及びサーバ・スタブは大きいので、それらはアプリケーションのコード・サイズを増加させる。インターフェースの複雑性が増す時、対応するＲＰＣスタブ・ルーチンは更に大きくなる。ＤＣＥシステムが成長する時、ＤＣＥアプリケーションが複雑になればなるほど、多くのＲＰＣスタブを導入することになる。
【０００５】
メモリ及び大容量記憶装置の必要条件は、限定された資源のための小型システムのユーザ及び多くの大きなアプリケーションを同時に実行し得る大型システムのユーザの関心事である。大きいＲＰＣスタブは、優れたシステム生産性のために利用可能なかなりのメモリと大容量記憶空間を占める。この問題に照らして、ＲＰＣスタブ・サイズを縮小させるために、２つの相補的な技法が開発されている。第１の技法はＩＢＭ社によって開発されたものであり、インターフェースのオペレーションに対する多数のスタブ・ルーチンを結合して単一のスタブ・ルーチンにするものである。この技法は、単一のスタブ初期設定及び終期設定コードが多数のスタブ・ルーチンによって共用されることを可能にする。スタブのオブジェクト・コード・サイズは３０％乃至５０％だけ縮小される。
【０００６】
第２の技法はＯＳＦ  ＤＣＥ１．０．３の下で得られるものであり、ＲＰＣコンパイラは、パラメータをマーシャル及びアンマーシャルするために実行時ライブラリにおいて使用するスタブを生成する。これはスタブ・ファイルのオブジェクト・コード・サイズを４０％乃至６０％縮小させる。それら２つの方法はスタブ・ファイルにおけるコードの相異なる領域を最適化するので、それらは相補的技法である。
【０００７】
残念なことに、クライアント側及びサーバ側の両方におけるＲＰＣスタブは、依然として、大量のメモリ空間及び大きな記憶空間を必要とする。従って、望ましいものは、システム・メモリ及び大容量の記憶装置におけるインパクトを大きく縮小させるように、ＲＰＣスタブ・ルーチンを更に最適化するための手段である。
【０００８】
【発明が解決しようとする課題】
従って、本発明の１つの目的は、ネットワークを介した通信を提供することにある。
【０００９】
本発明のもう１つの目的は、ネットワーク・システムを介してコール及びレスポンスを転送するためのプロシージャを標準化することにある。
【００１０】
本発明の更にもう１つの目的は、ネットワーク・システムを介してクライアント及びサーバの間でリモート・プロシージャ・コール及びレスポンスを転送し、従って、クライアント・スタブ及びサーバ・スタブと呼ばれ、一般に各サーバ及びクライアントにとって必要な個々のプログラム・モジュールを排除するストリームライン化された方法を提供することにある。
【００１１】
【課題を解決するための手段】
前記の目的は、後述のようにして達成される。本発明によれば、コンピュータ・ネットワークを介してリモート・プロシージャ・コール及びレスポンスを転送するための改良された方法及びシステムが開示される。その方法及びシステムは汎用のＲＰＣクライアント・スタブ及び汎用ＲＰＣサーバ・スタブを利用して、通常各クライアント及びサーバ・アプリケーションと関連したすべての専用のＲＰＣスタブを置換する。それら汎用のスタブは、呼出し時にカストマイズされ、あたかもそれらが正規のスタブであるかのようにネットワークを介して情報及びプログラムを伝送及び検索する。それら汎用のスタブは、利用可能な各プログラムと関連した正規の各スタブにとって必要なすべてのサブファイルと関連のメモリの量を減少させることができる。
【００１２】
【実施例】
図面、特に、図１を参照すると、本発明の方法及びシステムを実施するために利用可能な分散データ処理システム８の概略図が示される。明らかなように、分散データ処理システム８は、ローカル・エリア・ネットワーク（ＬＡＮ）１０及び３２のような複数個のネットワークを含み、それらの各々は複数個の個別のコンピュータ１２及び３０を含む。勿論、当業者には明らかなように、ホスト・プロセッサに接続された複数個のインテリジェント・ワーク・ステーション（ＩＷＳ）がそのような各ネットワークに対して利用可能である。
【００１３】
そのようなデータ処理システムには一般的であるように、各個別のコンピュータは記憶装置１４及びプリンタ／出力装置１６に接続可能である。１つ又は複数個のそのような記憶装置１４は、本発明の方法及びシステムに従って、分散データ処理システム８においてユーザによる周期的にアクセス及び処理可能な種々のデータ・オブジェクト又はドキュメントを記憶するように、本発明の方法に従って利用可能である。そのような各データ処理プロシージャ又はドキュメントは、その分野ではよく知られた方法で、関連の資源オブジェクトすべてを維持及び更新するように働く資源マネージャ又はライブラリ・サービスと関連した記憶装置１４内に記憶可能である。
【００１４】
更に図１を参照すると、分散データ処理システム８は、望ましくは通信リンク２２によってローカル・エリア・ネットワーク（ＬＡＮ）１０に接続されるメインフレーム・コンピュータ１８をも含み得ることは明らかである。メインフレーム・コンピュータ１８は、ローカル・エリア・ネットワーク（ＬＡＮ）１０に対するリモート記憶装置として働き得る記憶装置２０を含むことができる。第２のローカル・エリア・ネットワーク（ＬＡＮ）３２が、通信制御装置２６、通信リンク３４、及びゲートウエイ・サービス２８を介してローカル・エリア・ネットワーク１０に接続可能である。望ましくは、ゲートウエイ・サービス２８は、ローカル・エリア・ネットワーク（ＬＡＮ）３２をローカル・エリア・ネットワーク（ＬＡＮ）１０にリンクするように働く独立したコンピュータ又はインテリジェント・ワーク・ステーション（ＩＷＳ）である。
【００１５】
ローカル・エリア・ネットワーク（ＬＡＮ）３２及びローカル・エリア・ネットワーク（ＬＡＮ）１０に関連して説明したように、複数個のデータ処理プロシージャ或いはドキュメントが記憶装置２０に記憶可能であり、そのように記憶されたデータ処理プロシージャ及びドキュメントに対する資源マネージャ又はライブラリ・サービスとしてメインフレーム・コンピュータ１８によって制御可能である。
【００１６】
勿論、当業者には明らかなように、メインフレーム・コンピュータ１８は、ローカル・エリア・ネットワーク（ＬＡＮ）１０から大きな幾何学的距離で配置可能であり、同様に、ローカル・エリア・ネットワーク（ＬＡＮ）１０は、ローカル・エリア・ネットワーク（ＬＡＮ）３２から大きな距離で配置可能である。即ち、ローカル・エリア・ネットワーク（ＬＡＮ）３２をカリフォルニアに配置し、ローカル・エリア・ネットワーク（ＬＡＮ）１０をテキサスに配置し、そしてメインフレーム・コンピュータ１８をニューヨークに配置することが可能である。
【００１７】
前記説明から明らかなように、分散データ処理システム８の或る部分におけるユーザにとって、その分散データ処理システム８の他の部分に記憶されたデータ・オブジェクト或いはドキュメントをアクセスすることが望ましいことがよくある。分散データ処理システム８内に記憶されたドキュメントにおける外見上の順序を維持するために、アクセス制御プログラムを導入することが望ましいことがよくある。これは、一般的には、個々の各データ・オブジェクト又はドキュメントへのアクセスを認められたユーザを、各ユーザが資源マネージャ或いはライブラリ・サービスにおけるドキュメントに関して持ち得る権限のレベルと共にリストすることによって達成される。この場合、データ処理プロシージャ及びドキュメントは、分散データ処理システム８における登録されたユーザによってアクセス可能であり、他のユーザによるアクセスを防ぐように周期的にロック可能である。
【００１８】
一般には、ＯＳＦの分散コンピュータ環境（本発明を含むＤＣＥ）の下で動作するクライアント／サーバ・ネットワーク・システムでは、殆どのＤＣＥクライアントは、如何なるクライアント・スタブ・ルーチンも生成されることを必要としない。或る特別のクライアントは、各々が１つのプロシージャ・コール・ステートメントしか含まない一組の非常に小さい代用スタブしか必要としない。各ＤＣＥサーバは、サービス・プロシージャ・コール・ステートメントしか含まない非常に小さいスタブ・ルーチンを必要とする。従って、本発明は、クライアント側におけるＲＰＣスタブを排除し且つサーバ側におけるＲＰＣスタブを最小にする方法を紹介する。この新しい方法は、リモート・プロシージャ・コール（ＲＰＣ）スタブによるＤＣＥアプリケーションのメモリ及び大容量記憶装置の必要条件を最良の可能な範囲まで縮小させる。
【００１９】
次のような例を比較することによって、本発明の利点を説明することにする。例えば、図２に示されるように、システムが、１０個のオペレーションのインターフェースをインポートする１０個のＤＣＥクライアント・アプリケーションを有する場合、そのシステムは、各クライアントに対して１０個のクライアント・スタブを生成する。その結果、１０個のクライアント・アプリケーションに対して１００個のクライアント・スタブが生成される。ＤＣＥ１．０．３の下で初期のバージョンを使用する場合、ＲＰＣは、実行時インタプリタを使って図２の下部に示されたパラメータをマーシャル及びアンマーシャルする。この方法は、特殊化したマーシャリング及びアンマーシャリング・コードを組み込む必要をなくする。これは、ＤＣＥ１．０．３プロシージャ以前の方法に比べて約５０％のスタブ・サイズの縮小を可能にする。何れの場合も、それぞれ「Ｍ」個のオペレーションに接続された「Ｎ」個のクライアントをシステムが走らせる時、「Ｎ＊Ｍ」個のクライアント・スタブが生成される。スペースの複雑さは「Ｎ＊Ｍ」のオーダ、即ち、Ｏ（Ｎ＊Ｍ）である。
【００２０】
図３には、第２のスタブ・サイズ縮小技法が示される。この技法はＩＢＭ社によって最初に開発されたものであり、ＲＰＣにおけるオペレーションに対する多数のクライアント・スタブを結合して単一のクライアント・スタブにするものである。これは、本出願人による未決の米国特許出願番号第０７／９４９，２９４号の主題でもある。この技法が適用される時、各インターフェースに対して唯
一のクライアント・スタブが生成される。その結果、１０個のＤＣＥクライアントに対して１０個のクライアント・スタブが生成されるであろう。この技法は、スペースの複雑性を「Ｎ」のオーダまで縮小させる。これは、それぞれ「Ｎ」個のオペレーションに接続された「Ｎ」個のクライアントをシステムが走らせる時、「Ｎ」個のクライアント・スタブしか生成されない。
【００２１】
しかし、何れの場合も、システムは、多すぎる量のシステム資源メモリ及び大容量記憶装置の容量を占める多すぎる数のスタブを生成する。本発明は、殆どの場合にＲＰＣスタブを生成する必要をなくすることによって従来の方法の制限を克服している。特に、１つのシステムにおけるすべてのＤＣＥクライアントが、ＲＰＣに任意のオペレーションをさせる時同じ汎用のスタブを共用する。この汎用のＲＰＣスタブ法の結果の表示が図４に示される。この方法はＤＣＥ１．０．３の方法のベースに適用され、パラメータ・マーシャリング又はアンマーシャリング・インタプリタを使用する単一のＤＣＥ１．０．３クライアント・スタブのサイズのように小さい汎用のクライアント・スタブに通じる。その汎用のスタブ及びインタプリタの両方とも、アプリケーションにより共用される実行時ライブラリにおいて見られる。
【００２２】
汎用のスタブは多数のＲＰＣに対する多数のクライアントによって共用されるので、空間計算量は更に１のオーダ、即ちＯ（１）に縮小される。これは、スタブ・ルーチンの数が一定であり、アプリケーションの数及び複雑さに関係ないことを意味する。空間計算量をＯ（Ｎ＊Ｍ）からＯ（１）に縮小させる効果を説明すると、それぞれが１０個のリモート・オペレーションをアクセスする２０個のＤＣＥクライアントをシステムが有する場合、２０＊１０＝２００個のクライアント・スタブ・ルーチンが生成されるであろう。そのスタブ・ルーチンの平均的オブジェクト・コード・サイズが１０キロバイトである場合、スタブ・ルーチン・コードだけで２メガバイト・メモリが取られるであろう。本発明による方法を適用すると、実行時ライブラリに特別な１０キロバイトのスタブ・コードが加えられ、前の方法における２００個のスタブは必要ない。従って、約２００メガバイトが節約される。
【００２３】
更なるバックグランドのために、リモート・プロシージャ・コール（ＲＰＣ）５０２は、クライアント・プログラム５１４及びサーバ・プログラム５１６とそれぞれリンクされたＲＰＣクライアント・スタブ５１０及びＲＰＣサーバ・スタブ５１２を必要とする。これは図５に示される。クライアントは、正規のローカル・プロシージャ・コールと同じプロシージャ名及びパラメータを持ったコール・ステートメントを通して正規のプロシージャ・コールを行う。そのコールはＲＰＣインターフェース５０４を介してクライアント・スタブ５１０への制御転送を生じさせる。クライアント・スタブ５１０はパラメータをマーシャルし、実行時ルーチン５２２をコールする。そこから、サーバ・スタブ５１２はパラメータをアンマーシャルし、プロシージャ・コール５２６を行い、そしてそれらパラメータをサーバにおける実際のリモート・プロシージャに送る。そこで、それらの結果はそのプロシージャから戻され、しかる後、サーバ・スタブにおいてマーシャルされてクライアント・スタブに返送される。クライアント・スタブはそれら結果をアンマーシャルしてクライアント・プログラムに戻す。コール・ステートメントから、クライアント・プログラムは、ジョブがローカル的に行われるか或いはリモート的に行われるかを知ることはできない。
【００２４】
如何なるインターフェースの如何なるオペレーションにとっても特殊化されたスタブを必要としないように、すべてのインターフェースのすべてのオペレーションに対する汎用のスタブを生成するためには、次のような２つの要件がある。第１の要件は、ＲＰＣの機能性が変更されないよう汎用のスタブの機能性が正規のスタブに等しくなければならないことである。第２の要件は、パフォーマンス・インパクトが最小にされるか或いは最小でなければならないことである。従って、システムは、正規のＲＰＣスタブの生成又は汎用のスタブを利用するためのコードの作成を行うＲＰＣコンパイラ・オプションを含む。単一の汎用のクライアント・スタブ及び単一の汎用のサーバ・スタブは、すべてのＲＰＣインターフェースにおけるすべてのアプリケーションからのすべてのＲＰＣによって共用されるべきライブラリにある。
【００２５】
クライアント側では、汎用のクライアント・スタブは、特定のＲＰＣコールを特徴づけるエクストラ・パラメータによって実行時にカストマイズ可能なパラメータ化ルーチンである。暗示的に云えば、適当な特徴パラメータが汎用のスタブに送られる時、そのスタブは、前述の従来方法において使用されていたオリジナルＲＰＣクライアント・スタブと全く同じに動作するよう特殊化される。汎用のクライアント・スタブ・ルーチンを実施するためには、ネットワーク「インターフェース定義言語（ＩＤＬ）」コンパイラは、特徴付けパラメータを生成することはできるがＲＰＣクライアント及びサーバ・スタブを生成することができないように設計される。
【００２６】
サーバ側では、汎用のサーバ・スタブが、コールに対するメッセージを受け付けることができるように及びそれがコールされたプロシージャに対するオリジナルＲＰＣサーバ・スタブであるかの如く（図６参照）作用することができるように特殊化される。サーバ・スタブ特徴付けパラメータは、修正されたＩＤＬコンパイラによって生成される。
【００２７】
汎用のクライアント・スタブ・ルーチンが任意のリモート・オペレーションに対するコールによって呼び出されることを可能にするためには、ルーチン・シグナチャ（Ｃにおける機能プロトタイプ）が任意の可能なリモート・オペレーションのシグナチャによってコンパイル可能でなければならない。「汎用のシグナチャ」又は汎用の機能プロトタイプは、任意のデータ・タイプのパラメータとして定義された任意の数のパラメータを取ることができなければならない。汎用のタイプは、任意の可能な長さのパラメータ・リストに適応するように可変リストでもって定義される。汎用であるためには、各パラメータは、文字に対するポインタとして定義される。ＲＰＣのすべてのポインタ・アーギュメントはポインタ・文字タイプにされる。スカラ・アーギュメントに対しては、先ず、それらアーギュメントに対する参照が得られ、しかる後、ポインタ・ツー・文字にされる。汎用のスタブ・ルーチンでは、これら参照はその値を回復するために参照解除される。
【００２８】
正規のＲＰＣクライアント・スタブ・ルーチンはそのリモート・オペレーションの同じ名前を持っている。図６は本発明によるＲＰＣルーチンの処理を示す。クライアント・プログラム６１０はそのスタブ・ルーチンにリンクされ、或いはパラメータ化され、ＲＰＣ実行時ライブラリにおけるルーチンを呼び出す。そのスタブ・ルーチンが汎用のスタブ６１４によって置換される時、汎用のＲＰＣクライアント・スタブが正規のスタブの代りに呼び出される。実行時ルーチンはＲＰＣメッセージをサーバ実行時６１６へ搬送する。次に、サーバ実行時ルーチンは汎用のＲＰＣサーバ・スタブ６１８をコールし、そのスタブ６１８はサーバ・プログラム６２０におけるリモート・プロシージャを呼び出す。
【００２９】
アプリケーションの透明性を保持するためには、クライアント・アプリケーションにおけるＲＰＣステートメントは変更されてはならない。この問題は、リモート・オペレーションに対するマクロ定義を生成することによって解決される。それらマクロによって、言語プリプロセッサは、汎用のスタブに対するコール・ステートメントでもってすべてのＲＰＣステートメントを置換する。しかる後、適当なアーギュメントが汎用のスタブに送られる。下記のコードは、汎用のクライアント・スタブ・コールでもって正規のＲＰＣステートメントを代用するマクロ定義の一例である。正規のクライアント・スタブ・ルーチン及び汎用のクライアント・スタブ・ルーチンは、それぞれ、ＡＩとして表１及び表２に示され、及びＡＩＩとして表３及び表４に示される。
【００３０】
／＊”ａｒｒａｙ＿ｏｐ３”に対するマクロ定義＊／
＃ｄｅｆｉｎｅ  ａｒｒａｙ＿ｏｐ３（ｐ１，ｐ２）／
＊（ｉｄｌ＿ｌｏｎｇ＿ｉｎｔ＊）ｃｓｔｕｂ−ｃｏｍｍｏｎ（／
２，＼
０｜ｒｐｃ＿ｃ＿ｃａｌｌ＿ｉｄｅｍｐｏｔｅｎｔ，＼
１，＼
２６４，＼
１，＼
２８４，＼
２，＼
（ｃｈａｒ＊）＆ｐ１，＼
（ｃｈａｒ＊）ｐ２＼
）
【００３１】
或るケースでは、どの機能をコールすべきを動的に決定するために、特別のクライアント・プログラムが機能ポインタ変数を使用する。ＲＰＣステートメントをマクロによるコンパイル時に配線することはできないので、そのマクロ法は使用不可である。しかし、代わりに軽い代用スタブ・ルーチンを使用した動的な呼出しは処理可能である。その代用ルーチンは、リモート・オペレーションのそれと同じ名前及びシグナチャでもって生成される。このルーチンは、汎用のルーチンを呼び出すための唯一のコール・ステートメントを含む。下記のコードは汎用のクライアント・スタブ・コールを行う代用スタブの一例である。正規のクライアント・スタブ・ルーチン及び汎用のクライアント・スタブ・ルーチンの両方とも、それぞれ、表１、表２及び表３、表４においてリストされている。
【００３２】
ｖｏｉｄ  ａｒｒａｙ＿ｏｐ６（
ｈａｎｄｌｅ＿ｔ  ｈ，
ｍｙ＿ａｒｒａｙ  ａｒｒ，
ｉｄｌ＿ｌｏｎｇ＿ｉｎｔ  ＊ｌａｓｔ，
ｉｄｌ＿ｌｏｎｇ＿ｉｎｔ  ｍａｘ，
ｉｄｌ＿ｌｏｎｇ＿ｉｎｔ  ＊ｃｈｅｃｋｉｎ，
ｉｄｌ＿ｌｏｎｇ＿ｉｎｔ  ＊ｃｈｅｃｋｏｕｔ
）｛
ｃｓｔｕｂ＿ｃｏｍｍｏｎ（
５，／＊ｏｐ番号＊／
０｜ｒｐｃ＿ｃ＿ｃａｌｌ＿ｉｄｅｍｐｏｔｅｎｔ，／＊ｏｐタグ＊／
３，／＊パラメータ内の番号＊／
３６４，／＊イン・タイプ・インデックス＊／
４，／＊パラメータ外の番号＊／
４００，／＊アウト・タイプ・インデックス＊／
６，／＊番号パラメータ＊／
（ｃｈａｒ  ＊）＆ｈ，
（ｃｈａｒ  ＊）ａｒｒ，
（ｃｈａｒ  ＊）ｌａｓｔ，
（ｃｈａｒ  ＊）＆ｍａｘ，
（ｃｈａｒ  ＊）ｃｈｅｃｋｉｎ，
（ｃｈａｒ  ＊）ｃｈｅｃｋｏｕｔ）；
｝
【００３３】
使用されるパラメータがスカラである時、アーギュメントはスカラ値に価する表現にすることができる。この場合、その表現値に対して割当てられるプレースホルダはない。その結果、その「表現値」のアドレス又はその「表現値」への参照は得られない。問題は、汎用のルーチンがそのアドレスを送らなければならない場合に生じる。この問題に対する１つの解決法は、マクロの代わりに軽い代用スタブを用いることである。もう１つの解決法は、表現値に対するプレースホルダとして特別変数を割当てることである。
【００３４】
代用スタブの形式上のパラメータはその値に対するプレースホルダであるので、そのパラメータに対するアドレスを汎用のクライアント・スタブに送ることが可能である。残念なことに、この解決法は、ユーザに対して可視的な代用スタブの生成に関してプログラムの複雑性を増加させる。更に、この解決法は、代用スタブによるスペース利用及びパフォーマンスの両方に不利に影響する。従って、単純な代用スタブでさえ、できるだけ回避することが望ましい。
【００３５】
図７においてフローチャートにより示された第２の解決法は、スカラ・アーギュメント（可能性としては、表現）を押さえるために実行時ルーチン「ｓｓｒ＿ｅｘｔｒａ＿ｖａｒｉａｂｌｅＯ」（ステップ７１０）に対する特別のプロシージャ・コールを生成することによって実施される。ステップ７１２において、その実行時ルーチンはスカラ変数を割振り、しかる後、その値を変数に割当て（ステップ７１４）、そしてその変数に対する参照をパラメータとして汎用のクライアント・スタブに戻す（ステップ７１６）。
【００３６】
ｃｈａｒ  ＊  ＿ｓｓｒ＿ｅｔｒａ＿ｖａｒｉａｂｌｅ（ｃｈａｒ  ＊ｐ）
｛
ｄｏｕｂｌｅ  ＊ｎｅｗ＿ｐ；
ｎｅｗ＿ｐ  ＝  （ｄｏｕｂｌｅ  ＊）ｍａｌｌｏｃ（ｓｉｚｅｏｆ（ｄｏｕｂｌｅ））；
＊ｎｅｗ＿ｐ  ＝  ＊（ｄｏｕｂｌｅ  ＊）ｐ；
ｒｅｔｕｒｎ（ｎｅｗ＿ｐ）；
｝
【００３７】
それら動的に割振られた変数は、システムにおけるメモリ・リークを回避するためには、それらの使用後に再利用されなければならない。その割振りは汎用のスタブの終了時に行われる。実行時ルーチンは、動的に割振られたスカラ変数すべてを割振り解除するために呼出し可能である。このルーチンは、どのパラメータが動的に割振り可能な変数を有するか及びどれを割振り解除する必要があるかに関して、グローバル一定ベクトルを考慮するであろう。
【００３８】
パラメータ伝送規約として、アレーを「アレー名」又は「アレー名に対する参照」によって送ることが可能である。両方の方法において、同じ「アレーに対する参照」が送られる。例えば、下記のルーチンにおける２つのコールは共に正しいし、結果的に同じ出力を生じる。
【００３９】
ｍａｉｎ０
｛
ｉｎｔ  ａｒｙ［１０］；
ａｒｙ［０］＝１０００；
ｏｐ（ａｒｙ）；
ｏｐ（＆ａｒｙ）；
｝
ｏｐ（ｉｎｔ  ＊ｐ）
｛
ｐｒｉｎｔｆ（”％ｄ＼ｎ”，ｐ［０］；
｝
【００４０】
ＤＣＥ  ＲＰＣでは、アレーをクライアントに返送しようする時、アトリビュート［ｏｕｔ］が指定される。この場合、このアレー名に対する参照はマーシャリング及びアンマーシャリング・インタプリタによって使用される。しかし、「＆ａｒｙ」に対する参照は、単に「＆ａｒｙ」前にオペレータ「＆」をプレフィックスすることによって得ることはできない。この問題は、スカラ・パラメータ問題に対する場合と同様に、代用スタブ又はポインタ変数の動的割振りによって解決される。後者は両方の問題に共通の一様な解決法を得るために採用される。
【００４１】
ｃｈａｒ  ＊＿ｓｓｒ＿ｅｘｔｒａ＿ｐｏｉｎｔｅｒ（ｃｈａｒ  ＊ｐ）
｛
ｃｈａｒ  ＊＊ｎｅｗ＿ｐ；
ｎｅｗ＿ｐ  ＝  （ｃｈａｒ  ＊＊）ｍａｌｌｏｃ（ｓｉｚｅｏｆ（ｃｈａｒ  ＊））；
＊ｎｅｗ＿ｐ  ＝  （ｃｈａｒ  ＊）ｐ；
ｒｅｔｕｒｎ（ｎｅｗ＿ｐ）；
｝
【００４２】
パラメータ・マーシャリング又はアンマーシャリングのためのマーシャリング及びアンマーシャリング・インタプリタに対するコールは、インタプリタ「パラメータ数及びインデックス」を含む。これらの値は、そのインタプリタが遂行される（働かれる）オペレーションのシグナチャに依存する。スタブ・コードを汎用化するために、これらの値はパラメータ化される。これらの値は、先ず、汎用のスタブ・ルーチンにパラメータとして送られ、しかる後、その汎用のスタブの形式上のパラメータがインタプリタに送られる。
【００４３】
各クライアント・スタブには、エラー報告ルーチン「ｒｐｃ＿ｓｓ＿ｒｅｐｏｒｔ＿ｅｒｒ＿２Ｏ」に送られる２つの表現ルーチンがある。又、これらの表現は汎用のスタブ・レベルに上げられる。汎用のスタブ・ルーチンはこれら２つの表現をパラメータとして取り、それの形式上のパラメータをエラー報告ルーチンに伝送する。
【００４４】
汎用のスタブ・ルーチンの１つのパラメータは、ＲＰＣが有する数のパラメータである。このパラメータは、可変数のパラメータをバッファに割当てる汎用のマーシャリング及びアンマーシャリング・バッファ初期設定コードによって使用される。汎用の初期設定コードは一連の割当てを置換する。それはパラメータの数によって制御されるループを含む。
【００４５】
｛
ｖａ＿ｌｉｓｔ  ａｐ；
ｉｎｔ  ｜；
ｖａ＿ｓｔａｒｔ（ａｐ，＿ｓａｒ＿ｎｕｍ＿ｐａｒａｍｓ）（；
ｆｏｒ（ｉ＝１；ｉ＜＝＿ｓｓｒ＿ｎｕｍ＿ｐａｒａｍｓ；ｉ＋  ＋）
ＩＤＬ＿ｐａｒａｍ＿ｖｅｃ［ｉ］＝（ｒｐｃ＿ｖｏｉｄ＿ｐ＿ｔ）ｖａ＿ａｒｇ（ａｐ，ｃｈａｒ  ＊）；
ｖａ＿ｅｎｄ（ａｐ）；
｝
【００４６】
機能結果変数はオペレーションとは無関係に割振られなければならない。或るオペレーションの機能結果のタイプは他のオペレーションのそれとは異なることがあるので、その変数はローカル変数によって、静的ではなく動的に割振られる。機能結果変数に対して割振られるべきメモリのサイズは、そのインターフェースにおけるすべてのオペレーションに対して機能結果のタイプのサイズを定義するグローバル一定ベクトルによって指定される。汎用の機能結果はポインタ・ツー・文字でもある。機能結果変数に対する参照が得られ、しかる後、型キャストされ、しかる後、戻される。それは、必要に応じて望ましい機能結果値に型キャストされ、参照解除される。
【００４７】
その変数は、その後、割振り解除される。割振り解除コール・ステートメントはマクロ定義における汎用のスタブ・コール・ステートメントに後続し、機能結果変数を割振り解除する。
【００４８】
サーバ側はクライアント側に適用された方法と同じ方法を多く使用するけれども、サーバ側は次のような特定の点においてクライアント側とは異なっている。即ち、
（１）ＲＰＣルーチン・コールバック・ルーチンは、サーバ・スタブの代わりに汎用のサーバ・スタブ・ルーチンを呼び出すように修正される必要がある。
（２）サーバ・スタブにおいて割当てられたサービス・ルーチンに対する実際の機能コールのアーギュメントは汎用のサーバ・スタブにおいて割振られなければならない。
（３）サービス機能コール・ステートメントは種々の可能なパラメータ・タイプのために汎用にはされ得ない。
【００４９】
比較してみると、ＤＣＥ法では、すべてのＲＰＣの正規のサーバ・スタブは同じシグナチャを有する。ＲＰＣルーチンは、独特のサーバ・スタブ・プロシージャ名に基づいて特定のオペレーションに対するサーバ・スタブにコールバックする。同じ汎用のサーバ・スタブ・ルーチンがＲＰＣ実行時によってコールされ、異なるオペレーション・コールを処理する。コールバックが行われるオペレーションを区別するために、特別のパラメータが使用されてそのオペレーション番号を指定する。
【００５０】
本発明では、図８におけるフローチャートによって示されるように、ＲＰＣ実行時コールバック・ルーチンは、ステップ８１０において、サーバ・スタブが正規のものであるか或いは汎用のものであるか（ステップ８１２）が検出できるように修正され、従って、正規のスタブ・ルーチン（ステップ８１４）又は汎用のスタブ・ルーチン（ステップ８１６）を呼び出す。サーバ・スタブ・ルーチンに対する機能ポインタをコールバックのためのＲＰＣ実行時に送るために使用されるサーバ・スタブ・ファイルにおける「ＩＤＬ＿ｅｐｖａ」アレーは、その検出を行うためにそのルーチンに対して異なって生成される。
【００５１】
汎用のサーバ・スタブ・ルーチンが使用される時、これら機能ポインタはすべてヌル（ＮＵＬＬ）にセットされる。実行時コールバック・ルーチンがヌル機能ポインタを検出した時（ステップ８１２）、それはその実行時における汎用のサーバ・スタブ・ルーチンを呼出し、オペレーション番号を送る（ステップ８１６）。そのコールバック・ルーチンは、それらポインタが非ヌルである時、正常に遂行する。この方法は、正規のサーバ・スタブ・オペレーションとの互換性を保持している。
【００５２】
更に、正規のサーバ・スタブでは、ステップ８１８において、サーバ機能コールに対するアーギュメント変数が一連のローカル変数定義によって静的に割振られ、一連の割当てによって初期設定される。ステップ８２０では、静的メモリ割振りの代りに動的メモリ割振りを使用してコードが生成される。ステップ８２２では、パラメータの数によって制御される割当てループがある。ステップ８２４において、動的に割振られた変数は、パラメータがアンマーシャルされた後に割振り解除される。この方法は、汎用のクライアント・スタブ・ルーチンにおいてパラメータに対する動的割振り及び割振り解除のために使用された方法と同じである。
【００５３】
マーシャリング及びアンマーシャリング・インタプリタへのコール及びエラー報告ルーチンに対するハードコード値は、特殊化されたコードを排除するために、クライアント側における場合と同様に、ステップ８２６においてパラメータ化される。
【００５４】
正規のサーバ・スタブでは、ステップ８２８において、サービス機能は、その機能に対するアーギュメントが作成されてしまった後にコールされる。マネージャ機能コール・ステートメントは、それらがオペレーション毎に異なっているので、汎用にはされ得ない。これは汎用のサーバ・スタブ・ルーチン及びサービス機能を接続する、生成されなければならない唯一のサーバ・ルーチンとなる。このサーバ・ルーチンはすべてのサービス機能コール・ステートメントの条件付きブランチを含む。コール・ステートメントは汎用のサーバ・スタブ・ルーチンから送られる機能番号によって選択される。
【００５５】
本発明による方法の実施を説明するために、その流れを示すフローチャートが図９に示される。ステップ９１０において、クライアント・プログラムにおけるコール・ステートメントが機能名の代わりに機能ポインタを指定する場合、コンパイル時マクロ展開は不十分であり、従って、ステップ９１２において、汎用のクライアント・スタブに対する１つのプロシージャ・コール・ステートメント「ＲＰＣ＿ｓｓ＿ｃｓｔｕｂ（ｓ＿ｐｍｔｓ，ｏｐ＿ｐｍｔｓ”）」を含む小さいプロシージャがＩＤＬコンパイラによって作成されることになる。コールされるべきリモート・プロシージャは実行時に決定される（ステップ９１４）。ステップ９１６において、クライアント・プログラムはこの小さいプロシージャを呼出し、そして、ステップ９１８において、このプロシージャは汎用のスタブを呼出し、特徴付けパラメータ及びＲＰＣパラメータ（請求項に記載の「情報パラメータ」に相当する）をその汎用のスタブに渡す。
【００５６】
ステップ９１０においてシステムが機能名を指定する場合、ステップ９２０においてマクロ展開が生成される。そこで、ステップ９２２において、正規のプロシージャ・コール・ステートメント「ｍｇｒ＿ｆｌ（ｏｐ＿ｐｍｔｓ）」が、「ＲＰＣ＿ｓｓ＿ｃｓｔｕｂ（ｓ＿ｐｍｔｓ）」に対するマクロ展開によって、コール・ステートメントに対するクライアント・プログラムのコンパイル時に、汎用のクライアント・スタブの実行時ライブラリ・ルーチン「ＲＰＣ＿ｓｓ＿ｃｓｔｕｂ」に変換される。そのマクロは特別のＲＰＣ特徴付けパラメータ「ｓ＿ｐｍｔｓ」を含む、そのパラメータは呼出し時に汎用のスタブに渡され（ステップ９２４）そしてその汎用のスタブをカストマイズし（又は、特殊化し）、オリジナルＲＰＣスタブが遂行する機能を正確に遂行する（ステップ９２６）。「ｏｐ＿ｐｍｔｓ」はリモート・プロシージャ・コールに対するパラメータであることに注意して欲しい。
【００５７】
サーバ実行時がコール・メッセージを受ける時、ステップ９２８において、実行時は、スタブ排除法が使用されようとしているかどうかを検出する。それが否定される場合、ステップ９３０において、それはサーバ・プログラムにおけるリモート・プロシージャに対する正規の（オリジナル）サーバ・スタブにそのコールをディスパッチする。そうでない場合、ステップ９３２において、それは実行時共用ライブラリにおける汎用のサーバ・スタブを呼出し、ＲＰＣパラメータ（ステップ９３４）及びサーバ・スタブ特徴付けパラメータを含むコールを汎用のサーバ・スタブへ渡す。ステップ９３６において、汎用のサーバ・スタブは、オリジナルの対応したサーバ・スタブが遂行する特別機能を遂行する。
【００５８】
次に、ステップ９３８において、切替えルーチンが呼び出されて、サーバ・プロセスにおけるリモート・プロシージャ「ｍｇｒ＿ｆ１Ｏ｛｝」を呼び出す。ステップ９４０において、その切替えルーチンは、ＩＤＬコンパイラにより各ＲＰＣインターフェースに対して生成される。その切替えルーチンは、それがＲＰＣインターフェースにおけるオペレーションの数と同じ数のプロシージャ・コール・ステートメントしか含まないので小さい。
【００５９】
なお、参考のために、正規のクライアント・スタブ（Ｒｅｇｕｌａｒ  Ｃｌｉｅｎｔ  Ｓｔｕｂ）を表１及び表２に示し、汎用のクライアント・スタブ（Ｇｅｎｅｒｉｃ  Ｃｌｉｅｎｔ  Ｓｔｕｂ）を表３及び表４に示す。
【００６０】
【表１】
0003546394.tif 000002
【００６１】
【表２】
0003546394.tif 000003
【００６２】
【表３】
0003546394.tif 000004
【００６３】
【表４】
0003546394.tif 000005
【００６４】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００６５】
（１）  リモート・ノード上で実行されるアプリケーション・プログラムから、コンピュータ・ネットワーク内のサーバ・ノードにあるところの、複数のサービス・プロシージャの１つをコールするための方法であって、前記アプリケーション・プログラムは第１のスタブ・ファイルを利用して、前記サーバ・ノードにある第２のスタブ・ファイルをコールし、
該方法は、
前記アプリケーション・プログラムのリクエストに応じて、一つの汎用のクライアント・スタブ・ファイルを、一つの前記リモート・ノードによって呼び出すステップと、
前記呼び出された一つの汎用のクライアント・スタブ・ファイルに情報パラメータを、一つの前記リモート・ノード上によって渡すステップであって、前記情報パラメータは、リモート・プロシージャ・コールが有する数のパラメータを含む、前記渡すステップと、
前記第１のスタブ・ファイル・メッセージとして働くように、前記呼び出された一つの汎用のクライアント・スタブ・ファイルを前記渡された情報パラメータでもって、一つの前記リモート・ノードによってカストマイズするステップであって、前記情報パラメータは前記複数のサービス・プロシージャの１つに対応する、前記カストマイズするステップと、
前記一つの汎用のサーバ・スタブ・ファイルに前記コンピュータ・ネットワークを通して前記第１のスタブ・ファイル・メッセージを、一つの前記リモート・ノードによって送信するステップと、
第２のスタブ・ファイル・メッセージとして働くように、前記一つの汎用のサーバ・スタブ・ファイルを前記第１のスタブ・ファイル・メッセージ内の前記情報パラメータでもって、一つの前記サーバ・ノードによってカストマイズするステップと、
前記第２のスタブ・ファイル・メッセージを前記一つの第２のスタブ・ファイル・メッセージから前記サーバ・ノード内に、一つの前記サーバ・ノードによって転送して、前記複数のサービス・プロシージャの前記１つを検索するステップと、
前記アプリケーション・プログラムによって利用されるように前記検索された複数のサービス・プロシージャの１つを、一つの前記サーバ・ノードによって準備するステップと、
前記アプリケーション・プログラムに制御を、一つの前記サーバ・ノードによって戻すステップと
を含み、
それによって、前記複数のサービス・プロシージャの１つが前記アプリケーション・プログラムによって利用される、前記方法。
（２）  リモート・ノード上で実行されるアプリケーション・プログラムから、コンピュータ・ネットワーク内のサーバ・ノードにあるところの、複数のサービス・プロシージャの１つをコールするためのシステムであって、前記アプリケーション・プログラムは第１のスタブ・ファイルを利用して、前記サーバ・ノードにある第２のスタブ・ファイルをコールし、
一つの前記リモート・ノードが、
前記アプリケーション・プログラムのリクエストに応じて、一つの汎用のクライアント・スタブ・ファイルを呼び出す手段と、
前記呼び出された一つの汎用のクライアント・スタブ・ファイルに情報パラメータを渡す手段であって、前記情報パラメータは、リモート・プロシージャ・コールが有する数のパラメータを含む、前記渡す手段と、
前記第１のスタブ・ファイル・メッセージとして働くように、前記呼び出された一つの汎用のクライアント・スタブ・ファイルを前記渡された情報パラメータでもってカストマイズする手段であって、前記情報パラメータは前記複数のサービス・プロシージャの１つに対応する、前記カストマイズする手段と、
一つの前記リモートが、前記一つの汎用のサーバ・スタブ・ファイルに前記コンピュータ・ネットワークを通して前記第１のスタブ・ファイル・メッセージを送信する手段と、
を含み、
１つの前記サーバ・ノードが、
第２のスタブ・ファイル・メッセージとして働くように、前記一つの汎用のサーバ・スタブ・ファイルを前記第１のスタブ・ファイル・メッセージ内の前記情報パラメータでもってカストマイズする手段と、
前記第２のスタブ・ファイル・メッセージを前記一つの第２のスタブ・ファイル・メッセージから前記サーバ内に転送して、前記複数のサービス・プロシージャの前記１つを検索する手段と、
前記アプリケーション・プログラムによって利用されるように前記検索された複数のサービス・プロシージャの１つを準備する手段と、
前記アプリケーション・プログラムに制御を戻す手段と、
を含み、
それによって前記複数のサービス・プロシージャの１つが前記アプリケーション・プログラムによって利用される、前記システム。
【００６６】
【発明の効果】
本発明によれば、ネットワーク・システムを介してクライアントとサーバとの間でリモート・プロシージャ・コール及びレスポンスを転送することにより、各サーバ及びクライアントに対して必要であったサーバ・スタブ及びクライアント・スタブと呼ばれる個々のプログラム・モジュールを不要にする。
【図面の簡単な説明】
【図１】本発明が動作するクライアント・サーバ・ネットワーク・システムの概略表示である。
【図２】ＤＣＥ１．０．３インタプリタ使用した結果としてのＲＰＣスタブ・サイズ縮小の効果を示す図である。
【図３】前のＩＢＭスタブ・サイズ縮小技法を適用した結果としてのＲＰＣスタブ・サイズ縮小の効果を示す図である。
【図４】本発明で開示された技法によるＲＰＣスタブ・サイズ縮小の効果を示す図である。
【図５】ＲＰＣスタブによる一般的なＲＰＣに対する実行の流れを示す図である。
【図６】本発明において実施されたアプリケーションＲＰＣスタブなしによるＲＰＣに対する実行の流れを示す図である。
【図７】スカラ変数でもってＲＰＣスタブをカストマイズするためのフローチャートである。
【図８】汎用のサーバ・スタブを使用すべきか或いは正規のサーバ・スタブを使用すべきかを決定する本発明のフローチャートである。
【図９】本発明に従って汎用のスタブＲＰＣ又は正規のスタブＲＰＣを遂行するシステムのフローチャートである。
【符号の説明】
８  分散データ処理システム
１０  ローカル・エリア・ネットワーク
１２  コンピュータ
１４  記憶装置
１６  プリンタ
１８  メインフレーム・コンピュータ
２０  記憶装置
２６  通信制御装置
【図１】
0003546394.tif 000006
【図２】
0003546394.tif 000007
【図３】
0003546394.tif 000008
【図４】
0003546394.tif 000009
【図５】
0003546394.tif 000010
【図６】
0003546394.tif 000011
【図７】
0003546394.tif 000012
【図８】
0003546394.tif 000013
【図９】
0003546394.tif 000014