JP2000515279A - プロキシーおよびメモリ割当てを使用して分散オブジェクト呼出しを実行するための方法および装置 - Google Patents

Abstract

(57)【要約】 分散オブジェクト呼出しを実行するための方法および装置は、プロキシー、ならびに、メモリ割当ておよび割当て解除を使用する。詳しくは、オブジェクトを示すオブジェクト参照が得られる。このオブジェクト参照は、前記オブジェクトを代理するプロキシーハンドルデータ構造体を作成するために使用される。前記プロキシーハンドルは、前記オブジェクトを呼び出すクライアントアプリケーションスタブ関数に与えられる。このスタブ関数には、さらに、例外情報と共に入力パラメータおよび出力パラメータが与えられる。オブジェクトリクエストブローカは、サーバアプリケーションにおける適切な処理系を見つける。前記サーバアプリケーションは、前記呼出しを実行するためのメモリを割り当てる。前記オブジェクトが実行され、そして、前記サーバアプリケーションによって割り当てられたメモリの割当てが解除される。前記サーバアプリケーションはクライアントアプリケーション応答し、これにより、クライアントは、同じプロキシーハンドルを使用して他のオブジェクト呼出しを行うか、または、前記プロキシーハンドルを破棄する。前記オブジェクト呼出しは特定のオブジェクトについて１回だけ初期化され得るので、多数回のオブジェクト呼出し初期化が回避される。さらに、オブジェクトの呼出しおよび実行時に発生するおそれのあるワイルドポインタおよびメモリリークの発生頻度を最少化することによって、資源が保護される。

Description

【発明の詳細な説明】 プロキシーおよびメモリ割当てを使用して分散オブジェクト呼出し を実行するための方法および装置 発明の背景 １．発明の分野 この発明は、クライアント側におけるプロキシーおよびサーバ側におけるメモ リ割当てを使用して分散オブジェクト呼出しを実行するための方法および装置に 関する。特に、この発明の方法は、特定のオブジェクトおよびそのオブジェクト 参照に関連づけるべきプロキシーハンドルデータ構造体の作成に関する。クライ アント側において、関連オブジェクトに対するオブジェクト呼出しはプロキシー ハンドルを使用して行われ、これにより、同一のオブジェクトに対する多数の呼 出しが可能になり、呼出し毎に初期化ルーチンを実行する必要がなくなる。サー バ側において、サーバは、プラットフォームとは独立した形態でメモリを割り当 てる。 ２．背景 分散型オブジェクトコンピューティング方式は、分散型コンピューティングお よびオブジェクト指向型コンピューティングの概念を組合わせたものである。分 散型コンピューティング方式は、相互に情報を共有する２つまたは３つ以上のソ フトウエアで構成される。これら２つのソフトウエアは、同一のコンピュータ、 または、共通のネットワークに接続された複数の異なるコンピュータ上で実行さ れる。ほとんどの分散型コンピューティング方式は、クライアント／サーバモデ ルに基づいている。このようなクライアント／サーバモデルでは、大別して２種 類のソフトウエア、すなわち、情報またはサービスを要求するクライアントソフ トウエアと、情報またはサービスを提供または実行するサーバソフトウエアが使 用される。 前記オブジェクト指向型コンピューティングは、“オブジェクト”と呼ばれる コード（しばしば、現実世界における現実の対象から抽出される）がデータ（オ ブジェクト指向プログラミング言語では“属性”と呼ばれる）を含み、これらオ ブジェクトについて実行される行為（“オペレーション”とも呼ばれる）を含む ことがあるオブジェクトモデルに基づくものである。各オブジェクトは、そのイ ンターフェイス（または、Ｃ＋＋言語では“クラス”）によって定義される。前 記インターフェイスは、該インターフェイスのオブジェクトについて実行される オペレーション、および、該オペレーションのためのパラメータを含む、オブジ ェクトの特徴および作用を定義する。オブジェクトは、分散型オブジェクトシス テムにおいて、オブジェクト参照と呼ばれるユニークな識別子によって識別され る。 分散型オブジェクトシステムにおいて、クライアントアプリケーションは、サ ーバアプリケーションに対してリクエスト（または“オブジェクトコール（呼出 し）”）を送る。このリクエストは、特定のオブジェクトについて実行すべきオ ペレーション、このオペレーションのためのパラメータ、前記オブジェクトのオ ブジェクト参照、および、リクエストの成功または失敗についてのエラー情報（ または“例外情報”）を戻すためのメカニズムを含んでいる。サーバアプリケー ションは、前記リクエストを受け取り、サーバ“処理系”を介して前記リクエス トを実行する。前記処理系は、特定のオブジェクトについてのオペレーションを 要求するクライアントのリクエストに答える。前記処理系は、サーバアプリケー ションにおいてその実行に関して要求された作業を実際に行うコード部分である １つまたは複数のメソッドを含む。前記処理系による実行が成功した場合、前記 サーバアプリケーションは、必要に応じて、クライアントに対して応答を送る。 前記サーバアプリケーションは、例外情報を戻すこともある。 分散型オブジェクトシステムを標準化するために、コンピュータソフトウエア 会社の協会であるオブジェクト管理グループ（“ＯＭＧ”：Object Management Group）は、“ＣＯＲＢＡ”（Common Object Request Broker Architecture）を 提案した。ＣＯＲＢＡ基準の下では、オブジェクトリクエストブローカ（“ＯＲ Ｂ”）は、そのシステムにおけるすべてのオブジェクトのために、サーバに対し てリクエストを送り、クライアントに応答を送る通信ハブを提供する。市販のＯ ＲＢは従来より知られており、一般的なタイプとしては、ＩＢＭのSystem Objec t Model（“ＳＯＭ”）がある。クライアント側のＯＲＢは、メソッドの呼出し 、ならびに、これに関連したサーバおよびメソッドの選択を要求するリクエスト を取り扱う。クライアントアプリケーションが、前記ＯＲＢに対して、１つのオ ブジェクトについて実行すべきメソッドを要求するリクエストを送ると、前記Ｏ ＲＢでは、該リクエストに含まれる引数をそのオブジェクトのインターフェイス に対して検査し、該リクエストをサーバに送り、必要な場合それを開始する。サ ーバ側のＯＲＢは、前記リクエスト中の情報を使用して、該リクエストを満足さ せる最良の処理系を決定する。前記リクエスト中の情報には、前記クライアント が要求しているオペレーション、該オペレーションがどのオブジェクトについて 実行されるかについての情報、さらに、前記リクエストについて格納されている 付加情報が含まれる。さらに、前記サーバ側のＯＲＢは、各リクエストおよびそ の引数を検査する。さらに、該ＯＲＢは、前記クライアントに応答を送る機能も 果たす。 クライアントアプリケーションおよびサーバアプリケーションは、共に、オブ ジェクトおよびこれらのオブジェクトについて実行可能なオペレーションを含む 利用可能なインターフェイスについての情報を有する必要がある。インターフェ イス定義の共用化を容易にするために、前記ＯＭＧは、インターフェイス定義言 語（“ＩＤＬ”）を提案した。該ＩＤＬは、オブジェクトのインターフェイス、 すなわち、該オブジェクトについて実行可能なオペレーションを含む該オブジェ クトの特徴および作用を記述するために使用される定義言語である（プログラミ ング言語ではない）。 ＩＤＬは、ＯＭＧのＣＯＲＢＡのRevision ２．０仕様を実行する分散型オブ ジェクトシステムに使用されるよう設計されている。前記ＣＯＲＢＡ仕様を実行 する典型的なシステムにおいて、インターフェイス定義は、ＩＤＬ定義ソースフ ァイル（“翻訳単位”としても知られている）に書かれている。前記ソースファ イルは、クライアントスタブファイル、サーバスタブファイルおよびヘッダファ イルを含むプログラミング言語別ファイルを生成するＩＤＬコンパイラによって コンパイルされる。前記クライアントスタブファイルは、ある１つのオブジェク トタイプに関するＩＤＬオペレーション定義の手続きルーチンへの、各言語別の 対 応づけ（マッピング）であり、各オペレーション毎に１つ設けられる。ある言語 に固有のコンパイラによってコンパイルされ、クライアントアプリケーションに リンクされる場合、スタブルーチンは、リクエストを実行するために、前記クラ イアントアプリケーションによって呼び出されることができる。同様に、前記サ ーバスタブファイルは、ある１つのオブジェクトタイプに関するＩＤＬオペレー ション定義（インターフェイスによる定義）の手続きルーチンへの、各言語別の 対応づけである。コンパイルされ、サーバアプリケーションにリンクされる場合 、前記サーバアプリケーションは、対応するリクエストが到着した時にこれらの ルーチンを呼び出すことができる。前記ヘッダファイルは、コンパイルされ、ク ライアントアプリケーションおよびサーバアプリケーションにリンクされ、共通 のデータ型および構造体を定義するために使用される。 前記ＣＯＲＢＡ仕様を実行するシステムにおいて、オブジェクト呼出しは、適 切なクライアントスタブ関数を呼び出すことによって行われる。これらのクライ アントスタブ関数に対するパラメータは、典型的には、リクエストされたオペレ ーションのための入力パラメータ、および、前記オブジェクトのオブジェクト参 照を含む。しかし、前記ＣＯＲＢＡ仕様には能力上の問題点がある。第１に、オ ブジェクトが呼び出されるごとに、ある構成設定作業がなされる必要がある。例 えば、オブジェクトは、その存在を保証するために検査されなければならない。 さらに、その呼出しのために、しはしば、メモリ（またはその他の資源）が割り 当てられる。また、インターフェイスが確認されなければならない。最後に、該 呼出しの移送準備がなされる（例えば、ファイルを開けたり、ソケットを準備し たり等々）。各オブジェクトの呼出しの前にこれらの作業の各々を行うのは、大 変時間がかかる。時間が重要な要素となるアプリケーションにおいて、各オブジ ェクト呼出しに伴うオーバーヘッドはその性能に大きく影響するおそれがある。 さらに、サーバ側において、不適当なメモリ割当てや割当て解除（ガーベジコ レクション：不要部分整理）によって性能が影響される。多くの分散型オブジェ クトシステムにおいて、オブジェクト呼出しの実行のためにメモリを割り当てる ことができる。しかしながら、呼出しが実行され、サーバがその呼出しに応答し た時に、メモリは自動的に解除されない。このようなメモリ割当て解除の不履行 は、資源の浪費、故に、処理速度の低下に至ることになる。さらに、ポインタま たはポインタによって指示されるアドレスの除去をしないことにより、システム エラーおよびアプリケーションの動作停止などのより大きな問題につながるおそ れがある。 あるシステムにおいては、オブジェクト呼出し実行の際に不要部分整理を使用 することを試みた。しかし、これらのシステムは、メモリの割当てを解除するた めにプラットフォームごとに固有の方式を使用している。このため、適当なメモ リ割当ておよび割当て解除を優先すると、しばしば、コード移植性が犠牲にされ ることになる。 従って、オブジェクトの呼出し毎にオブジェクト呼出しを構成設定する必要を 無くすることによって、オブジェクト呼出し性能を向上させる方法が望まれてい る。 さらに、オブジェクト実行中にメモリの割当ておよび割当て解除を行うことに よって、オブジェクト呼出し性能を向上させる、プラットフォームから独立した 方法が望まれている。 発明の要旨 この発明は、オブジェクトの呼出し毎にオブジェクト呼出しを構成設定する必 要を無くすることによって性能を向上させることのできる、オブジェクト呼出し を実行するための方法および装置を提供するものである。また、この発明は、オ ブジェクト実行中にメモリの割当ておよび割当て解除を行うことによって、オブ ジェクト呼出し性能を向上させるものである。 より詳しくは、この発明は、クラアントアプリケーション内で生成されたスタ ブ関数を介して、サーバアプリケーションにオブジェクトを呼び出すための方法 に係るものである。前記呼出しは、先ず前記オブジェクトを示すオブジェクト参 照を得ることによって実行される。次に、該オブジェクト参照を使用して、該オ ブジェクトに対する呼出しにおいて該オブジェクトを代理するプロキシーハンド ルを作成する。そして、前記スタブ関数を介して、前記オブジェクトが呼び出さ れる。該スタブ関数には、前記プロキシーハンドル、前記オブジェクトについて 実行すべきオペレーションの入力パラメータ、該オペレーションの出力パラメー タおよび例外情報が与えられる。その後、前記オブジェクトは、前記サーバアプ リケーションにおいてメソッド関数を介して実行される。前記サーバアプリケー ションは、前記コーラ（呼出し側）に応答し、前記呼出しを完了する。前記プロ キシーハンドルは、同一のオブジェクトに対する後の呼出しのために再び使用可 能である。最後のオブジェクト呼出しがなされると、前記プロキシーハンドルは 破棄される。 前記プロキシーハンドルの作成により、前記オブジェクト呼出しのための資源 が自動的に割り当てられる。前記プロキシーハンドルが破棄されると、これらの 資源は解放される。さらに、前記プロキシーハンドルは同一のオブジェクトに対 する多数の呼出しのために使用可能であるので、前記クラアントアプリケーショ ンは、前のオブジェクト呼出し時に実行されたであろう初期化を行うために必要 とされない。例えば、オブジェクト検査、ファイル開きおよびソケット準備は、 各オブジェクト呼出し中に一般的に実行されるイベントである。資源を節約する ために、これらの初期化イベントは、前記アプリケーションにおける時間が重要 な要素となる部分に入れられてよい。最後に、オブジェクトの特定の特徴を実行 する前にユーザを一定の要件に従わせるために、同一のオブジェクトについて多 数のプロキシーハンドルが使用されてよい。このようにして、ファイルおよび同 様なオブジェクトが、擬似的に暗号化されてよい。 他の実施の形態によると、オブジェクトの実際の実行中に、資源の割当て、割 当て解除がなされてよい。この実施の形態において、前記サーバアプリケーショ ンにおけるメソッド関数が、適切な資源を割り当てるための関数を呼び出す。該 関数は、前記サーバコンピュータにおけるヒープに割り当てられたメモリを指示 するポインタを戻す。前記メソッド関数が完了すると、前記メモリは自動的に割 当て解除される。メモリの自動的な割当て解除により、オブジェクトの実行時に しばしば発生しがちなランダムポインタおよびメモリのリークの可能性が減少す る。 この発明に係るオブジェクト呼出しを実行するための方法および装置、ならび に、その利点および目的は、添付図面を参照して以下に述べるこの発明の詳細な 説明によって、より完全に理解されるであろう。 図面の簡単な説明 図１は、この発明の方法を使用したクライアント／サーバシステムを示す図。 図２Ａおよび図２Ｂは、共通実行環境（ＣＥＥ）カプセルの異なる構成を示す 図。 図３は、ＣＥＥカプセルおよびそのコア要素を示す図。 図４は、ＩＤＬソースコードのコンパイルおよびクライアントアプリケーショ ンおよびサーバアプリケーションへのリンクを説明する図。 図５は、この発明の方法に係るステップを示すフローチャート。 図６は、この発明の他の実施の形態に係るステップを示すフローチャート。 図７は、ＰＩＦデータ構造体を示す図。 図８は、エントリデータ構造体を示す図。 図９は、オペレーションデータ構造体を示す図。 図１０は、共用体データ構造を示す図。 好適な実施の形態の詳細な説明 以下、添付図面に示した例を参照して、この発明の好適な実施の形態を詳細に 説明する。添付図面において、同一または類似した構成要素には同一の参照番号 が付されている。 Ｉ．システムの概要 図１に示すように、この発明の方法は、分散型（クライアント／サーバ）コン ピューティング環境１０に使用されるよう設計されている。該クライアント／サ ーバシステムは、インターネット接続部またはローカルエリアネットワーク接続 部のようなネットワーク接続部１２によって接続されている。サーバコンピュー タ１１は、バスまたはＩ／Ｏチャンネル２０を介して、ディスク記憶サブシステ ム１３と通信する。サーバシステム１１は、ＣＰＵ１５と、プログラムの実行に ついての現在の状態情報を格納するためのメモリ１７とを具備している。該メモ リ１７の一部は、クライアントコンピュータ上で現在実行されているプログラム の各関数に関連した状態および変数を格納するために専用される。同様に、クラ イアントコンピュータ２１は、ＣＰＵ２７とこれに関連するメモリ２３と、キー ボードまたはマウスのような入力装置２９と、ビデオ表示端末（“ＶＤＴ”）３ ３とを具備している。該クライアントのＣＰＵは、バスまたはＩ／Ｏチャンネル ４０を介してディスク記憶サブシステム３３と通信し、また、Ｉ／Ｏチャンネル ４１を介してキーボード２９、ＶＤＴ３３およびマウス３１と通信する。両前記 コンピュータは、フロッピーディスクおよびＣＤ−ＲＯＭを含む各種の媒体を読 取ることができる。 前記クライアントメモリ２７は、クライアントアプリケーション７７およびこ れにロードされたクライアントスタブ７９を含む。同様に、前記サーバメモリ１ ７には、サーバアプリケーション８７およびサーバスタブ８９を含む。さらに、 前記クライアントメモリおよびサーバメモリは、共に、実行環境７５，８５を含 んでいる（後述）。 図１に示すクライアント／サーバモデルは、単に、典型的なクライアント／サ ーバシステムを例示するものである。この発明によると、前記“クライアンド” は、あるオブジェクトについてオペレーションが実行されるべきことをリクエス トするアプリケーションであり、前記“サーバ”は、前記オブジェクトについて 前記オペレーションを実行するアプリケーションである。実際上、前記クライア ントアプリケーションおよびサーバアプリケーションは、後述のように、同一の コンピュータ上の共通のカプセル内に備えられていてよい。しかし、ほとんどの 場合、前記クライアントアプリケーションおよびサーバアプリケーションは、異 なるオペレーティングシステムを使用する異なるコンピュータに備えられること になる。以下、この発明の方法を、異なるマシーン上で動作する２つのカプセル について説明する。 この発明の方法および装置は、任意の分散型コンピューティング環境内で利用 可能である。好ましい実施の形態において、Tandem Message Switching facilit y（“ＭＳＦ”）Architectureの一要素である共通実行環境（“ＣＥＥ”）が使 用される。前記CＥＥは、オブジェクトを起動したり停止したりするものであり 、ＣＥＥカプセルにロードされたクライアントアプリケーションおよびサーバア プ リケーション間でメッセージのやり取りするために使用される。該ＣＥＥは、１ つのマシーンのメモリに格納されてよい。しかし、該ＣＥＥ、クライアントアプ リケーションおよびサーバアプリケーションは、図１に示すように、ネットワー ク上の多数のマシーンにロードされてもよい。クライアント側のＣＥＥ７５は、 クライアントメモリ２７に格納されている。また、サーバ側のＣＥＥ８５は、サ ーバメモリ１７に格納されている。 前記ＣＥＥは、“カプセル”下部構造を使用する。該カプセルは、メモリスペ ースおよび実行ストリームを封入するものである。カプセルは、異なるシステム では、当該システムによって使用されるオペレーティングシステムに応じて、異 なる態様で実現されてよい。例えば、あるシステムでは、前記カプセルはプロセ スとして実現される。また、他のシステムでは、前記カプセルはスレッド（thre ad）として実現される。さらに、クライアントアプリケーションおよびサーバア プリケーションは、図１に示すように異なるマシーンに含まれる異なるカプセル 内に構成されてもよい。代案として、異なるカプセルが図２のように構成されて もよい。図２Ａは１つのカプセル８１にロードされたクライアントアプリケーシ ョン７７を示し、この場合、サーバアプリケーション８７は別のカプセル８５に されてよい。しかし、これら２つのアプリケーションは、同一のマシーン２１に 格納されている。また、図２Ｂに示すように、前記クライアントアプリケーショ ンおよびサーバアプリケーションは、共に、同一のマシーン２１上の１つのカプ セル８１内にロードされてもよい。上述のように、ここでは、多数のカプセル、 多数のマシーンを使用する例についてこの発明の方法を説明する。従って、クラ イアントマシーン１２およびサーバマシーン１１は、それぞれのメモリにロード されたクライアント側CＥＥ７５およびサーバ側ＣＥＥ８５を備えている。 図３は、例えば、クライアントコンピュータメモリ２７（ここでは図示せず） に格納されたＣＥＥカプセル７０を示すものであり、該ＣＥＥカプセル７０は、 ＣＥＥ７５、ならびに、コアＣＥＥ要素および処理系ライブラリ７１内に含まれ るオブジェクトの処理系のうちのいくつかを含むものである。前記処理系ライブ ラリ７１は、後述のように、オブジェクトインターフェイスのＩＤＬ仕様書から 生成されたクライアントアプリケーション７９（サーバカプセルの場合、サーバ アプリケーション）およびクライアントスタブ７７を含んでいる。前記処理系ラ イブラリ７１およびCＥＥ７５は、該ＣＥＥによって供給される動的アクセス可 能なルーチンのダウンコーリングおよび前記処理系ライブラリに含まれるルーチ ンのアップコーリングによって、相互作用する。また、前記ＣＥＥ７５は、同じ マシーン内の他のカプセルからのオブジェクトコール８２、および、他のＣＥＥ からのリクエスト８４を受け取ることができる。前記クライアント側ＣＥＥ７５ およびサーバ側ＣＥＥ８５は、任意の既知のネットワークプロトコルを使用して 通信することができる。 ＣＥＥカプセルで実現されるオブジェクトは、構成設定オブジェクトまたは動 的オブジェクトであってよい。構成設定オブジェクトの処理系の詳細は、（MSF Warehouse85のような）格納部または初期化スクリプトに格納されている。特定 のオブジェクト参照に対するリクエストがあった場合、前記クライアント側ＣＥ Ｅ７５では、この構成設定データに基づいて適切なカプセルを始動する。前記カ プセルは、この構成設定データを使用して、ロードすべき処理系ライブラリおよ び呼び出すべきオブジェクト初期化ルーチンを決定する。そして、前記オブジェ クト初期化ルーチンがそのオブジェクトを作成する。動的オブジェクトは、同一 のカプセル内において、動的に作成され、破棄される。該動的オブジェクトには 、格納部に格納されたまたはスクリプト化された構成設定情報が無い。 以下のパラグラフでは、前記処理系ライブラリがどのようにＣＥＥ７５と相互 作用するのかについてシステムレベルで概説する。前記ＣＥＥ７５は、カプセル 内でオブジェクトを起動したり停止したりするためのリクエストを実行する。さ らに、上述の如く、前記ＣＥＥは、カプセル間オブジェクトコール８３および他 のＣＥＥ８７からのリクエストを容易にする。オブジェクト起動リクエストは、 クライアントアプリケーションまたはサーバアプリケーションからのオブジェク トコールが満足させられなければならない場合に発生する。オブジェクトを起動 するためには、前記ＣＥＥ７５は、それが未だロードされていない場合、前記オ ブジェクトのメソッドを含む適切な処理系ライブラリをロードし、その後、前記 処理系ライブラリに含まれる構成設定オブジェクト初期化ルーチンを呼び出す。 該初期化ルーチンは、前記処理系ライブラリがサポートするインターフェイスを 指定し、その後前記ＣＥＥによって呼出すべき前記オブジェクトのメソッドのエ ントリポイントを登録する。 クライアントシステムおよびサーバシステムが始動すると、前記クライアント 側ＣＥＥおよびサーバ側ＣＥＥは各々の初期化を実行する。この初期化は、前記 クライアント側ＣＥＥおよびサーバ側ＣＥＥに対して、様々な前記処理系ライブ ラリの位置を指示する。前記ＣＥＥによる位置検出がなされると、前記クライア ントアプリケーションおよびサーバアプリケーションにおける初期化ルーチンが 呼び出される。前記初期化ルーチンは、先ず、必要とされるアプリケーション別 の初期化を実行しなければならない。次に、クライアント初期化ルーチンおよび サーバ初期化ルーチンは、前記オブジェクトのインターフェイスを指定するため に、GEE_INTERFACE_CREATEと称される（上述の如く動的ライブラリに含まれる） ＣＥＥ関数をダウンコールする。後述のように、このインターフェイスの記述は 、通常、ＩＤＬソースファイルに含まれる該インターフェイスのＩＤＬ記述から 生成される。GEE_INTERFACE_CREATEは、インターフェイスを作成し、この新たに 作成されたインターフェイスに“インターフェイスハンドル”を戻す。前記ハン ドルは、前記インターフェイスを指示するユニークな識別子である。そして、前 記サーバアプリケーションの初期化ルーチンは、前記インターフェイスハンドル を使用して、GEE_IMPLEMENTATION_CREATEをダウンコールする。該GEE_IMPLEMENT ATION_CREATEは、１つまたは複数のオブジェクトで使用可能な実行記述を作成す る。該GEE_IMPLEMENTATION_CREATEは、前記インターフェイスにおいて各オペレ ーションごとの処理系を指示するユニークな識別子である“処理系ハンドル”を 戻す。最後に、前記サーバアプリケーションの初期化ルーチンは、前記処理系ハ ンドルを使用してCEE_SET_METHODを呼び出し、前記サーバアプリケーションに含 まれる前記処理系の特定のメソッドルーチンの実際のアドレスを指示する。こう して、前記ＣＥＥは、前記クライアントアプリケーションにおけるオブジェクト 呼出しを、前記サーバアプリケーションにおける特定のメソッドに接続するのに 十分な情報を有することになる。 図４は、ＩＤＬソースファイルが、コンパイルされ、この発明の方法および装 置を使用するクライアントアプリケーションおよびサーバアプリケーションにリ ンクされる手順を示すものである。先ず、ＩＤＬインターフェイス定義を含むＩ ＤＬソースファイル１０１が作成される。ＩＤＬコンパイラ１０３は、前記ＩＤ Ｌソースファイル１０１をコンパイルする。前記ＩＤＬコンパイラ１０３は、オ リジナルソースファイルの格納するために、コード１０１を分析してPickled ID Lファイル（“ＰＩＦ”）１０５を生成する。ＰＩＦファイルの生成は、下記の セクションIVにおいて説明されている。コードジェネレータ１１１はＰＩＦファ イルを分析する。前記コードジェネレータ１１１は、前記クライアントアプリケ ーションおよびサーバアプリケーションの言語のファイルを生成する。前記クラ イアントアプリケーションとサーバアプリケーションとが異なる言語によるもの である場合、異なるコードジェネレータが使用される。好ましくは、前記コード ジェネレータ１１１およびＩＤＬコンパイラ１０３は、１つのアプリケーション において、言語別コードを生成するために組み合わされる。前記コードジェネレ ータ１１１は、クライアントスタブ関数を含むクライアントスタブファイル１１ ５と、オブジェクト実行についての定義を含むサーバスタブファイル１１７とを 生成する。前記クライアントスタブ関数は、前記ＣＥＥに対する同期的および非 同期的な呼出しを含む。コンパイルされたクライアントスタブオブジェクトコー ドおよびコンパイルされたサーバスタブオブジェクトコードを生成するために、 前記クライアントスタブファイル１１５およびサーバスタブファイル１１７は、 プログラミング言語別のコンパイラ１２１，１２３によってコンパイルされる。 同様に、コンパイルされたクライアントアプリケーションオブジェクトコードお よびコンパイルされたサーバアプリケーションオジェクトコードを生成するため に、クライアントアプリケーション７９およびサーバアプリケーション８９は、 プログラミング言語別のコンパイラによってコンパイルされる。前記クライアン トアプリケーション１２１およびサーバアプリケーション１２３は、さらに、前 記コードジェネレータ１１１によって生成されるヘッダファイル１１９を含む。 該ヘッダファイル１１９は共通の定義および宣言を含む。最後に、前記コンパイ ラ１２１は、前記クライアントアプリケーションオブジェクトコードとクライア ントスタブオブジェクトコードとをリンクすることにより、処理系ライブラリ７ １を生成する。同様に、第２のコンパイラは、前記サーバアプリケーションオブ ジェ クトコードとサーバスタブオブジェクトコードとをリンクすることにより、他の 処理系ライブラリ８１を生成する。 II．プロキシー作成 次に、図５および図６を参照して、この発明の方法を説明する。ここでは、こ の発明の方法を、クライアントコンピュータのカプセル内で実行されるクライア ントアプリケーション、および、サーバコンピュータの別のカプセル内で実行さ れるサーバアプリケーションについて説明する。図５は、オブジェクトを呼び出 すためにプロキシーハンドルを利用するためのステップを示すフローチャートで ある。最初のステップ５０１において、所望のオブジェクトのオブジェクト参照 が得られ必要がある。該オブジェクト参照は、様々な方法で得られてよい。通常 、クライアントアプリケーションは、これらがオブジェクト参照を有する他のオ ブジェクトについての構成設定データ、ディレクトリまたは呼出しから前記参照 を受け取る。オブジェクト参照は、後にアクセスすべきファイルに格納可能な文 字列名に変換されることができる。 前記オブジェクト参照が得られと、オブジェクト呼出しを実行することができ る。この発明の方法において、先ず前記オブジェクト参照に対する“プロキシー ハンドル”を得ることによって前記オブジェクト呼出しが実行される。該プロキ シーハンドルは、特定のオブジェクト参照のためのユニークな識別データ構造体 （“プロキシーオブジェクド”）である。このプロキシー構造体は、前記オブジ ェクトについての情報および該オブジェクトに対する呼出しを含む。このプロキ シーハンドルを使用して、指定されたオブジェクトに対する呼出しを行うことが できる。前記プロキシーハンドルは、同じオブジェクトに対する多数の呼出しを 容易にし、該同じオブジェクトに対する多数の呼出しにおいて発生するオーバヘ ッドを防止する。オブジェクトを実行可能にするプロキシーハンドルを作成する ことによって、該プロキシーハンドルを介して、代理されるオブジェクトに対す る多数の呼出しを可能にしながら、初期化ルーチンを一通り実行することができ る。さらに、前記プロキシーハンドルは、オブジェクトに対する非同期呼出しの 使用を容易にする（後述）。好ましい実施の形態によると、ステップ５０３にお いて、前記クライアントアプリケーションにおけるクライアント側ＣＥＥ関数CE E_PROXY_CREATEをダウンコールすることによってプロキシーハンドルが作成され る。該関数はＣプログラミング言語により次のように定義される。 CEE_PROXY_CREATE( const char ^*objref const char ^*intf_handle char ^*proxy_handle); 前記関数は、オブジェクト参照objrefおよびインターフェイスハンドルintf_han dleを受け取り、新たに作成されたプロキシーオブジェクトを指示するプロキシ ーハンドルを戻す。図３について上述したように、インターフェイスは各オブジ ェクトごとに作成されなければならない。インターフェイスは、類似したオブジ ジェクトの集合について利用可能なオペレーションを定義するものである。前記 インターフェイスは、ＩＤＬで定義され、コンパイルされ、クライアントアプリ ケーションにリンクされる。該クライアントアプリケーションは、その初期化ル ーチンでCEE_INTERFACE_CREATEを呼び出し、前記インターフェイスを指定する。 前記クライアント側ＣＥＥは、任意の数のオブジェクトまたはプロキシーを作成 するために使用可能なインターフェイスハンドルを戻す。 この発明の好ましい実施の形態において、前記プロキシーオブジェクトは次の ようなフィールドを含む構造体によって表現される。 次に、前記プロキシーオブジェクトのデータ構造体における各構成要素につい て説明する。前記構成要素の各々のアドレスおよび値は、該プロキシー構造体に よって示されるオブジェクトに対する各呼出しごとに、前記クライアント側ＣＥ Ｅによって修正される。該クライアント側ＣＥＥは、プロキシー構造体のリンク されたリストを維持する。各プロキシー構造体のリンクメンバは、このプロキシ ー構造体のリストにおける次のエントリを指示するポインタを含むものである。 好ましい実施の形態において、オブジェクト呼出しは同期的なもの（クライア ントアプリケーションが、オブジェクトについてのオペレーションが行われるよ うリクエストし、応答を待つもの）、あるいは、非同期的なもの（クライアント アプリケーションが、オブジェクトについてのオペレーションが行われるようリ クエストし、他の作業を続けて行うもの）のいずれであってもよい。同一のカプ セル内において非同期オブジェクト呼出しが送られると、各呼出しは、その起動 時に、各オブジェクトごとに存在するオブジェクト構造体に含まれるリンクリス ト上に並べられる。前記call_linkパラメータは、前記呼出しリストへのリンク である。前記selfメンバは、この特定のプロキシー構造体のハンドルである。こ のハンドルは、CEE_PROXY_CREATEの間に前記クライアントに戻される。 CEE_PROXY_CREATEに与えられたオブジェクト参照は、norメンバに格納される 。 前記stateパラメータは、前記プロキシー構造体が内部オブジェクト構造体、（ クライアントポートを介した）外部オブジェクト、または存在しない（無効な） オブジェクト構造体を指示するポインタを含むか否かを示す。前記プロキシーが 内部的なものである場合、前記オブジェクトのポインタは前記objパラメータに 含まれる。前記オブジェクトが異なるカプセル内にある場合、前記ochanパラメ ータは、クライアントポートハンドルを指示するポインタ、または、前記オブジ ェクトと通信するために必要な他の情報を含む。 前記call_actlveメンバは真／偽の値を保持する。この特定のプロキシーハン ドルについてのオブジェクト呼出しが未処理である場合、前記call_activeメン バは真の値に設定される。１つの特定のプロキシーについて１つのオブジェクト 呼出しだけが未完了となり得る。前記プロキシー構造体が破棄されるのを防止す るために、前記lock_countメンバがインクリメントされる。前記構造体がもはや 必要でない時、前記lock_countメンバはデクリメントされる。前記destroyメン バは、前記lock_countメンバがゼロになった時このプロキシー構造体が破棄され るべき場合に真の値に設定される真／偽値である。前記intfメンバは前記インタ ーフェイスを記述するintf構造体のアドレスである（上述）。 次の４つの構造体メンバcall_compl_rtn，call_compl_tag1，call_compl_tag2 ，call_compl_stsは、非同期オブジェクト呼出しを実行するために使用される。 サーバアプリケーションにおけるオブジェクトに対する非同期呼出しは、呼出し 時に、完了ルーチンのアドレスをクライアントスタブ関数に送ることによって行 われる。こうして、前記クライアントスタブ関数は、前記クライアント側ＣＥＥ を呼び出し、前記完了関数アドレスを送る。前記クライアント側ＣＥＥは、前記 プロキシーハンドルが作成された時に、前記完了関数のアドレスを前記プロキシ ー構造体に格納する。前記オブジェクト呼出しが完了すると、前記クライアント 側ＣＥＥは、前記プロキシーハンドルにおいて指示される完了ルーチンを呼び出 す。前記ルーチンは、前記呼出しが完了したことを前記クライアントアプリケー ションに通知するために呼出される。前記オブジェクトの実行中において、前記 クライアントアプリケーションは他の関数の実行を続けることができる。前記メ ンバcall_compl_rtnは、前記完了ルーチンのアドレスを含むものである。同一の プロ キシーオブジェクトに対して多数の呼出しが可能であるので、前記クライアント アプリケーションは、オブジェクト呼出し実行時に、前記call_compl_tag1を使 用することによって、前記呼出しを確認することができる。該call_compl_tag1 は、前記クライアントスタブ関数に送られる。これらの識別子は、前記プロキシ ー構造体において前記メンバcall_compl_tag1およびcall_compl_tag2によって指 示される。前記call_compl_stsは、呼び出しできなかった非同期呼出しについて の完了ステータスを示す。 前記operation_idxメンバは、どのオブジェクトのオペレーションを呼び出す べきかを指示する。オペレーション識別子は、前記インターフェイスにおける各 オペレーションごとに、前記コードジェネレータによって生成される。前記allo cated_paramsメンバは、一時的に割り当てられた（制限の無いタイプなどに使用 される）親を指示するポインタである。このメンバの割当て解除は、このプロキ シー構造体によって参照されるオブジェクトに対する次の呼出しについて不要部 分整理を行う。前記operation_idx_tableパラメータは、前記オブジェクトが同 一のカプセル内に含まれる場合にのみ使用されるオペレーションインデックス翻 訳テーブルを指示するポインタである。 メモリ割当ては、max_response_size，req_area，rep_area，rsp_param_bufメ ンバを使用して実行される。前記rsp_param_bufメンバは、応答パラメータを含 むバッフアを指示する。次にこのプロキシーオブジェクトが使用されるとき、前 記バッファの割当てが解除される。前記max_response_sizeは、予期され得る最 大の応答サイズである。これは、前記rep_areaを割り当てるために使用される。 前記req_areaメンバは、前記オブジェクト呼出しに対する応答のために使用され るエリア（area）構造体を指示する。前記rep_areaは、前記オブジェクト呼出し に対する応答に使用されるエリア構造体である。該エリア構造体は、Ｃプログラ ミング言語により次のように定義される。 desc; ^*data; curlen; 前記エリア構造体は、オブジェクト呼出しエリア記述子、データポインタおよび 該データの長さを含む。 前記クライアントアプリケーションによるCEE_PROXY_CREATEの呼出しにより、 ステップ５０８において、前記クライアント側ＣＥＥは、自動的に、前記オブジ ェクトのためのメモリを割り当てる。前記クライアントコンピュータにおけるメ モリは、前記呼出しを行うために必要な付加的な資源と共に割り当てられる。前 記プロキシーハンドルが（後述のように、CEE_PROXY_DESTROYに対するダウンコ ールにより）破棄されると、前記メモリおよび割り当てられた資源が解放される 。オブジェクト呼出しから可変サイズの出力パラメータのために割り当てられた メモリは、同一のプロキシーハンドルを使用して次のオブジェクト呼出しがなさ れる時に、その割当てが解除される。 前記プロキシーハンドルは、前記プロキシーによって参照されるオブジェクト に対する後のすべての呼出しを行うために使用される。前記オブジェクト呼出し は、ステップ５１１において、前記クライアントアプリケーションにおける適切 なスタブ関数を呼び出し、例外情報と共に前記プロキシーハンドル、入力パラメ ータおよび出力パラメータを前記関数に与えることによって行われる。こうして 、前記スタブ関数は、次のようにＣ言語によって定義されるCEE_OBJECT_CALLを ダウンコールする。 CEE_OBJECT_CALL( const char ^*proxy_handle long operation_idx void ^**param_vector); 前記プロキシーハンドルは前記proxy_handleパラメータによって指示される。前 記パラメータOperation_idxは、どのオブジェクトのメソッドが呼び出されるべ きかを指示する。このパラメータは、前記インターフェイスが作成された時に供 給された前記インターフェイス記述における必要なメソッドに対するインデック スである。最後に、前記param_vectorは、前記オブジェクト呼出しの入カパラメ ータ、出力パラメータおよび例外構造体を指示するポインタのアレイである。前 記例外構造体のアドレスは、前記アレイにおける最初の構成要素である。前記オ ペレーションがvoid（空）タイプのものでない場合、前記アレイにおける次の構 成 要素は、前記オペレーションの結果を受け取るための変数のアドレスを含む。そ の後の構成要素は、ＩＤＬにおいて定義された順序と同じ順序で、前記オペレー ションの入力パラメータおよび出力パラメータのアドレスを含む。 そして、前記呼出しは、任意の移送メカニズムを使用して前記サーバに送られ る。ステップ５１５では、前記サーバアプリケーションが前記オブジェクトを実 行する。これは、適切なメソッドルーチンをアップコールする前記サーバ側ＣＥ Ｅによって実行される。前記メソッドルーチンには、前記入力パラメータおよび 出力パラメータのすべてのアドレスを含む前記param_vectorパラメータが与えら れる。前記メソッドが退出すると、ステップ５１９において、前記コーラに応答 がなされ、前記オブジェクト呼出しが完了する。 最初の呼出しが完了すると、前記プロキシーハンドルを再使用して、同じオブ ジェクトに対して更なる呼出しを行うことができる。前記オブジェクトに対する 後の各呼出しは、前記オブジェクトを確認したり、他のスタートアップオペレー ションを実行したりすることなく行うことができる。このようにして、前記プロ キシー作成ステップは、前記クライアントアプリケーションにおける時間が重要 な要素とはならない部分に置くことができ、オブジェクト呼出しは前記アプリケ ーションにおける時間が重要な要素となる部分において行うことができる。 指定されたプロキシーハンドルについての最終的なオブジェクト呼出しに続い て、ステップ５２１では、前記プロキシーハンドルが破棄される。これは、クラ イアントアプリケーションにおいて次のようにＣ言語で定義されるCEE_PROXY_DE STROYを呼び出すことによって実現される。 CEE_PROXY_DESTROY( const char ^*proxy_handle); 前記プロキシーハンドルは前記関数に与えられる。前記クライアント側ＣＥＥで は、ステップ５２８において、このプロキシーハンドルを破棄し、該プロキシー ハンドルについて割当てられていたすべての資源を解放する。代案として、オブ ジェクト呼出しがキャンセルされ、該呼出しが未完了の間に該呼出しに関連する すべての資源の割当てが解除されてよい。 III．プロキシー作成およびメモリ割当て 図６は、この発明に係るオブジェクト呼出しメソッドの他の実施の形態を示す ものである。この実施の形態において、オブジェクトの呼出し中のみならずオブ ジェクトの実行中にもメモリが割り当てられる。 ステップ６０１−６１１は上記のステップと同様である。従って、ステップ６ ０１では、オブジェクト参照が得られる。次に、前記プロキシーハンドルを戻す CEE_PROXY_CREATEをダウンコールすることによって、プロキシーハンドルが得ら れる。そして、ステップ６１１において、参照されたオブジェクトのプロキシー ハンドルが与えられたCEE_OBJECT_CALLを使用して、前記オブジェクト呼出しが 行われる。 ステップ６１３において、前記サーバ側ＣＥＥは、前記サーバアプリケーショ ンにおける適切なメソッドルーチンをアップコールする。ステップ６１６では、 前記メソッドルーチンは、その呼出し時に、サーバ側ＣＥＥ関数をダウンコール し、メモリを割当てる。その関数CEE_TMP_ALLOCATEは、次のようにＣ言語で定義 される。 CEE_TMP_ALLOCATE( const_char ^*call_id long len void ^**ptr); 前記関数は、前記call_idパラメータを使用して特定のオブジェクト呼出しを追 跡する。前記オブジェクトに対する各呼出しには、前記サーバアプリケーション によってユニークなcall_idが与えられる。こうして、前記呼出しが行われると 、前記サーバの処理系は、前記call_idパラメータにおける前記呼出しにｉｄを 与える。割り当てるべきバイト数は、前記lenパラメータにおいて指定される。 前記関数は、前記ptrパラメータを介して前記割り当てられたメモリのアドレス を戻す。 ステップ６１９において、前記オブジェクトのメソッドが前記サーバアプリケ ーションによって実行される。該サーバアプリケーションは、ステップ６１５に おいて、前記コーラに応答する。前記メソッド関数からの退出時に、ステップ６ ２０において、CEE_TMP_ALLOCATEに対するダウンコールに基づいて割り当てられ たメモリが解放される。その後、前記クライアントアプリケーションは、ステッ プ６１１において他のオブジェクト呼出しを行うか、または、ステップ６２５に おいて前記プロキシーハンドルを破棄する。前記プロキシーハンドルが破棄され ると、ステップ６０９で割り当てられたメモリが、ステップ６２８において、前 記クライアント側ＣＥＥによって自動的に割当て解除される。 メモリは、CEE_TMP_DEALLOCATEを使用して早めに割当て解除されることができ る。その関数は次のように定義される。 CEE_TMP_DEALLOCATE( In void ^*ptr); 前記関数には、CEE_TMP_ALLOCATEによって提供された前記ptrパラメータが与え られる。前記ＣＥＥは、前記パラメータによって指示されたアドレスを解放する 。 IV．ピクルドＩＤＬフォーマットデータ構造体の作成 ピクルド（pickled）ＩＤＬフォーマット（“ＰＩＦ”）データ構造体は、ク ライアントメモリ２３およびサーバメモリ１７にロードされたＩＤＬコンパイラ およびコードジェネレータと共に使用されるよう設計されている。該データ構造 体は、メモリ２３またはメモリ１７に格納されたＩＤＬソースファイルに基づい ている。該ソースファイルも、ディスクのようなコンピュータによって読取り可 能な媒体に格納されることができる。このデータ構造体は、ＩＤＬソースファイ ルを示す解析ツリーを含んでいる。該データ構造体は、メモリ２３またはメモリ １７あるいはディスクのようなコンピュータによって読取り可能な媒体に格納可 能である。前記ソースファイルを示す前記データ構造体は、ピクルドＩＤＬフォ ーマット（“ＰＩＦ”）と呼ばれている。該ＰＩＦファイルは、前記ソースファ イルに定義されたインターフェイスを使用するクライアントおよびサーバにより 実行時にアクセス可能である。該ＰＩＦファイルに含まれる解析ツリーは、ポイ ンタの代りにアレイインデックスを使用するアレイである。このアレイインデッ クスの使用により、その結果としての解析ツリーは言語とは独立したものとする ことができる。前記アレイの最初の構成要素は使用されない。前記アレイの２番 目の構成要素（インデックス１）は、前記解析ツリーの残りの部分へのエントリ ポイントとして機能するルート部である。 図７にはデータ構造体tu７０１が示されており、これは次のようにＩＤＬによ って定義される。 strunct tu_def｛ sequence<entry_def> entry; sequence<string> source; ｝ 前記データ構造体７０１は、その各々がentry_defタイプ（後で定義）である解 析ツリーノード７０５のシーケンス（可変サイズアレイ）およびソースファイル ライン７０７のシーケンスを含む。前記ソースファイルライン７０７のシーケン スは、前記ＩＤＬソースファイルからの実際のソースコードラインを含む文字列 シーケンスである。 各解析ツリーノード（または“エントリ”）７０５は、該ノードの名前および その特性を含む固定部、ならびに、前記ノードのタイプによって決まる可変部で 構成される。前記解析ツリーノードは図８に示されており、これは次のようにＩ ＤＬによって定義される。 前記解析ツリーノードの固定部はentry_index８０５を含み、これは前記解析 ツリーにおけるこの特定のエントリのインデックスである符号なしlongである。 前記エントリの非修飾名は、nameフィールド８０７に含まれる。オリジナルのＩ ＤＬソースファイルの名前は、file_nameフィールド８１１に含まれる。line_nr フィールド８１３は、この解析ツリーノードを作成させる前記ＩＤＬソースファ イルにおけるライン番号を含む。ブールin_main_file８１５は、コマンドライン 上に指定されたＩＤＬソースファイルにおいてエントリがなされたか否か、また は、前記エントリが“include”ファイルの一部か否かを示す。これらのファイ ルに続いて、前記解析ツリーは、可変部、すなわち、識別子entry_type_defを有 する共用体８１７を含む。前記共用体識別子entry_type_defは、ノードのタイプ およびentry_def内のどの変数がアクティブなのかを指示する。entry_type_def は次のように定義される列挙である。 entry_type_defは、各種の解析ツリーエントリのリストを含む。各解析ツリー エントリは、entry_defに含まれるswitch文に使用される一定の定数を示す。各 エントリごとに、共用体u_tagは異なるタイプの構造体を含むことになる。列挙 された最初の値entry_unusedは、ゼロの値に対応し、前記共用体のタイプを決定 するのに使用されない。 前記解析ツリーエントリが（値entry_moduleによって指示された）モジュール である場合、前記解析ツリーの可変部は、モジュール定義のシーケンスを含むデ ータ構造である。各モジュール定義は、前記解析ツリーアレイにおけるインデッ クスとして機能する符号なしlongである。 前記解析ツリーエントリが（値entry_interfaceによって指示された）インタ ーフェイスである場合、前記解析ツリーの可変部は、ローカル定義シーケンス、 および、このインターフェイスが継承する基本インターフェイスのシーケンスを 含むデータ構造体である。前記解析ツリーエントリがインターフェイスの前向き 宣言（entry_interface_fwd）である場合、前記共用体はフル定義のインデック スを含む符号なしのlongである。 定数（entry_const）は、解析ツリーノードにおいて該定数の値を含む構造体 として表現される。好ましくは、前記ソースファイルに含まれる各種の基本タイ プ定数（ブール定数、char定数、double定数等）を識別するために、共用体およ びswitch/case文が使用される。 例外（entry_except）は、解析ツリーノードにおいてフィールドのシーケンス を含む構造体として表現される。属性（entry_attr）は、該属性が読出し専用で あるか否かを示すブール値、および、そのデータ型を示す符号なしのlongを含む データ構造として表現される。 前記解析ツリーエントリがオペレーション（op_def）である場合、前記エント リデータ構造体９０５の可変部８１７は図９に示されるようなデータ構造体であ る。前記データ構造体８１７は、前記オペレーションが一方向属性を有するもの か否かを示すブール数９０５、戻りタイプを示す符号なしのlong９０７、前記オ ペレーションに対する引数９０９のシーケンス、前記オペレーションに対する例 外９１１のシーケンス、および、前記オペレーションに含まれるコンテキストを 指示する文字列１３１３のシーケンスを含む。前記解析ツリーエントリが特定の オペレーションに対する引数（entry_argument）である場合、該解析ツリーエン トリの可変部は、該引数の方向およびデータ型を示す符号なしのlongを含む。 前記解析ツリーエントリが共用体（entry_union）である場合、これは解析ツ リーエントリにおいて図１０に示すようなに表現される。前記データ構造体８１ ７は、識別子１００３を示す符号なしのlong、および、その型１００５を示す符 号なしのlongを含む。その型は、基本型の列挙リストを使用して指示されるのが 好ましい。該データ構造体８１７は、共用体フィールド１００７のシーケンスを さらに含む。前記解析ツリーエントリが共用体ブランチ（entry_branch）である 場合、前記解析ツリーエントリの可変部は、前記ブランチの基本型を示す符号な しのlong、前記ブランチがcaseラベルを含むか否かを示すブール数、および、識 別子の値を含む構造体である。前記値は特定のデータ型であるので、好ましくは 、各種基本型の列挙リストを使用して、該共用体ブランチを表現するために使用 される構造体内の値を示す。 データ構造体（entry_struct）の場合、前記解析ツリーエントリの可変部は、 指定された構造体フィールドのシーケンスを含む構造体を含む。列挙された値（ entry_enum）は、列挙された値のシーケンスを含む構造体によって表現される。 列挙されたタイプの列挙（entry_enum_val）は、前記解析ツリーエントリにおい て、列挙の数値を保持する符号なしのlongを含む構造体によって表現される。 前記解析ツリーエントリが文字列（entry_string）である場合、前記解析ツリ ーエントリの可変部は、該文字列の最大サイズを含む構造体である。最大サイズ がゼロである場合、これは制限なしの文字列を示す。アレイ（entry_array）は 、前記解析ツリーエントリにおいて、前記アレイの基本型を保持する符号なしの long、および、前記アレイのサイズを保持するlongのシーケンス含む構造体によ って表現される。シーケンス（entry_sequence）は、前記シーケンスの基本型お よび最大サイズを保持する符号なしのlongを含む構造体によって表現される。 タイプ定義（entry_typedef）の場合、前記解析ツリーエントリは、前記タイ プ定義の基本型を示す符号なしのlongの値を含む構造体によって表現される。予 め定義されたタイプ（entry_pre_defined）は、データ型を含む構造体によって 表現される。前記タイプを指示するために、前記各種基本型の列挙が使用される のが好ましい。 前記tuデータ構造体を使用して前記ＩＤＬソースが記述されると、前記データ 構造体は任意の既知の方法を使用してファイルまたはデータベースに移送される 。 以上のようにプロキシーおよびメモリ割当て／割当て解除を使用してオブジェ クト呼出しを実行するための方法の好ましい実施の形態について説明してきたが 、この発明の範囲および精神の範囲内で様々な変更が可能である。

───────────────────────────────────────────────────── 【要約の続き】 る。前記オブジェクト呼出しは特定のオブジェクトにつ いて１回だけ初期化され得るので、多数回のオブジェク ト呼出し初期化が回避される。さらに、オブジェクトの 呼出しおよび実行時に発生するおそれのあるワイルドポ インタおよびメモリリークの発生頻度を最少化すること によって、資源が保護される。

Claims (1)

1. 【特許請求の範囲】 １．コンピュータメモリに格納されたオブジェクトを呼び出す方法であって、 前記オブジェクトを示すオブジェクト参照をクライアントアプリケーションに よって得るステップと、 前記オブジェクトを示すプロキシーハンドルデータ構造体を作成するステップ であって、該プロキシーハンドルデータ構造体が、前記オブジェクト参照と、前 記オブジェクトが前記クライアントアプリケーションと同じプロセス内にある場 合には前記オブジェクトを指示するポインタ、また、前記オブジェクトが前記ク ライアントアプリケーションとは異なるプロセス内にある場合には前記オブジェ クトと通信するために必要な情報を指示するポインタとを含むことと、 前記クライアントアプリケーションにおけるスタブ関数を介して前記オブジェ クトについてのオペレーションが実行されるようリクエストするステップであっ て、前記スタブ関数が前記プロキシーハンドルおよび前記オペレーションの入力 パラメータが与えられるものであるステップと、 サーバアプリケーションにおいて前記オペレーションを実行するステップと、 前記クライアントアプリケーションに応答するステップと を具備した方法。 ２．前記呼出しが完了した後、前記プロキシーハンドルを破棄するステップをさ らに具備した請求の範囲第１項に記載の方法。 ３．前記呼出しが未完了の間に、前記プロキシーハンドルを破棄するステップを さらに具備した請求の範囲第１項に記載の方法。 ４．前記オブジェクトの呼出しが、前記クライアントアプリケーションによって アクセス可能な実行環境を使用して実行される請求の範囲第２項に記載の方法。 ５．前記プロキシーハンドルを作成するステップが、前記実行環境によって実行 される請求の範囲第５項に記載の方法。 ６．前記プロキシーハンドルを破棄するステップが、前記実行環境によって実行 される請求の範囲第６項に記載の方法。 ７．前記スタブ関数には、前記オブジェクトについて実行されるべきオペレーシ ョンの出力パラメータも与えられる請求の範囲第１項に記載の方法。 ８．前記スタブ関数には例外情報も与えられる請求の範囲第７項に記載の方法。 ９．前記オペレーションを実行するために、コンピュータメモリのブロックを割 当てるステップと、 前記オペレーションの実行後に、前記コンピュータメモリのブロックの割当て を解除するステップと をさらに具備した請求の範囲第１項に記載の方法。 １０．前記メモリのブロックが、前記サーバアプリケーションによってアクセス 可能な実行環境によって割り当てられる請求の範囲第９項に記載の方法。 １１．前記クライアントアプリケーションが前記コンピュータメモリに格納され る請求の範囲第１項に記載の方法。 １２．前記クライアントアプリケーションが第２のコンピュータメモリに格納さ れる請求の範囲第１項に記載の方法。 １３．コンピュータメモリに格納されたオブジェクトを呼び出す方法であって、 前記オブジェクトを示すオブジェクト参照をクライアントアプリケーションに よって得るステップと、 前記オブジェクトを示すプロキシーハンドルデータ構造体を作成するステップ であって、該プロキシーハンドルデータ構造体が、前記オブジェクト参照と、前 記オブジェクトが前記クライアントアプリケーションと同じプロセス内にある場 合には前記オブジェクトを指示するポインタ、また、前記オブジェクトが前記ク ライアントアプリケーションとは異なるプロセス内にある場合には前記オブジェ クトと通信するために必要な情報を指示するポインタとを含むことと、 前記クライアントアプリケーションにおけるスタブ関数を介して前記オブジェ クトについてのオペレーションが実行されるようリクエストするステップであっ て、前記スタブ関数が前記プロキシーハンドルおよび前記オペレーションの入力 パラメータが与えられるものであるステップと、 前記オブジェクトについてのオペレーションを実行するために、コンピュータ メモリのブロックを割当てるステップと、 サーバアプリケーションにおいて前記オペレーションを実行するステップと、 前記メモリのブロックの割当てを解除するステップと、 前記クライアントアプリケーションに応答するステップと、 前記プロキシーハンドルを破棄するステップと を具備した方法。 １４．前記プロキシーハンドルデータを作成するステップが、前記クライアント アプリケーションによってアクセス可能な実行環境によって実行される請求の範 囲第１３項に記載の方法。 １５．前記プロキシーハンドルを破棄するステップが、前記実行環境によって実 行される請求の範囲第１４項に記載の方法。 １６．前記スタブ関数には、前記オブジェクトについて実行されるべきオペレー ションの出力パラメータも与えられる請求の範囲第１３項に記載の方法。 １７．前記スタブ関数には例外情報も与えられる請求の範囲第１６項に記載の方 法。 １８．オブジェクト呼出しを実行するためのコンピュータによって読取り可能な コード手段を格納したコンピュータで使用可能な媒体を備えたコンピュータプロ グラム製品であって、 前記オブジェクトを示すオブジェクト参照をクライアントアプリケーションに よって得るソフトウエア手段と、 前記オブジェクトを示すプロキシーハンドルデータ構造体を作成するソフトウ エア手段であって、該プロキシーハンドルデータ構造体が、前記オブジェクト参 照と、前記オブジェクトが前記クライアントアプリケーションと同じプロセス内 にある場合には前記オブジェクトを指示するポインタ、また、前記オブジェクト が前記クライアントアプリケーションとは異なるプロセス内にある場合には前記 オブジェクトと通信するために必要な情報を指示するポインタとを含むものと、 前記クライアントアプリケーションにおけるスタブ関数を介して前記オブジェ クトについてのオペレーションが実行されるようリクエストするソフトウエア手 段であって、前記スタブ関数が前記プロキシーハンドルおよび前記オペレーショ ンの入力パラメータが与えられるものと、 サーバアプリケーションにおいて前記オペレーションを実行するソフトウエア 手段と、 前記クライアントアプリケーションに応答するソフトウエア手段と を具備したコンピュータプログラム製品。