JP2000515278A

JP2000515278A - 非同期式にオブジェクトを呼出し、処理するための方法および装置

Info

Publication number: JP2000515278A
Application number: JP10506101A
Authority: JP
Inventors: スコフィールド，アンドリュー
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1996-07-11
Filing date: 1997-07-10
Publication date: 2000-11-14
Also published as: US6253252B1; EP0912937A1; WO1998002809A1

Abstract

(57)【要約】非同期式にオブジェクトを呼出し実行するための方法および装置が開示されている。オペレーションを実行するためのオブジェクト呼出しは、クラアントアプリケーションから適切なスタブ関数を呼出し、オブジェクト参照、入力パラメータおよび完了ルーチンを指示するポインタを取り込むことによって、非同期式に行われる。前記オブジェクト参照、入力パラメータおよび完了ルーチンアドレスは、クラアント側実行環境に与えられる。このクラアント側実行環境は、前記完了ルーチンアドレスを格納し、前記入力パラメータをサーバ側実行環境に送る。前記サーバ側実行環境は、リクエストされたオペレーションを実行するサーバアプリケーションにおけるメソッドを呼出す。前記サーバアプリケーションは、リクエストされたオペレーションを実行する。前記呼出しに応答がなされると、前記クラアント側実行環境は、前記完了ルーチンを呼出し、前記リクエストされたオペレーションに出力パラメータを送る。前記完了ルーチンが呼出される前において、前記クラアントアプリケーションは、他の非同期オペレーションを実行し続けることができる。呼出されたオブジェクトを非同期式に実行するために、非同期オペレーションを呼出す前記サーバアプリケーションにおける適切なメソッド関数が呼出される。前記非同期オペレーションが戻されると、このアプリケーションは前記クラアントアプリケーションに応答する。

Description

【発明の詳細な説明】非同期式にオブジェクトを呼出し、処理するための方法および装置発明の背景１．発明の分野この発明は、クライアントアプリケーションおよひサーバアプリケーションにおいて非同期的なオブジェクト呼出しおよび非同期的なオブジェクト実行を行うための方法および装置に関する。２．背景分散型オブジェクトコンピューティング方式は、分散型コンピューティングおよびオブジェクト指向型コンピューティングの概念を組合わせたものである。分散型コンピューティング方式は、相互に情報を共有する２つまたは３つ以上のソフトウエアで構成される。これら２つのソフトウエアは、同一のコンピュータ、または、共通のネットワークに接続された複数の異なるコンピュータ上で実行される。ほとんどの分散型コンピューティング方式は、クライアント／サーバモデルに基づいている。このようなクライアント／サーバモデルでは、大別して２種類のソフトウエア、すなわち、情報またはサービスを要求するクライアントソフトウエアと、情報またはサービスを提供または実行するサーバソフトウエアが使用される。前記オブジェクト指向型コンピューティングは、“オブジェクト”と呼ばれるコード（しばしば、現実世界における現実の対象から抽出される）がデータ（オブジェクト指向プログラミング言語では“属性”と呼ばれる）を含み、これらオブジェクトについて実行される行為（“オペレーション”とも呼ばれる）を含むことがあるオブジェクトモデルに基づくものである。各オブジェクトは、そのインターフェイス（または、Ｃ＋＋言語では“クラス”）によって定義される。前記インターフェイスは、該インターフェイスのオブジェクトについて実行されるオペレーション、および、該オペレーションのためのパラメータを含む、オブジェクトの特徴および作用を定義する。オブジェクトは、分散型オブジェクトシステムにおいて、オブジェクト参照と呼ばれるユニークな識別子によって識別される。分散型オブジェクトシステムにおいて、クライアントアプリケーションは、サーバアプリケーションに対してリクエスト（または“オブジェクトコール（呼出し）”）を送る。このリクエストは、特定のオブジェクトについて実行すべきオペレーション、このオペレーションのためのパラメータ、前記オブジェクトのオブジェクト参照、および、リクエストの成功または失敗についてのエラー情報（または“例外情報”）を戻すためのメカニズムを含んでいる。サーバアプリケーションは、前記リクエストを受け取り、サーバ“処理系”を介して前記リクエストを実行する。前記処理系は、特定のオブジェクトについてのオペレーションを要求するクライアントのリクエストに答える。前記処理系は、サーバアプリケーションにおいてその実行に関して要求された作業を実際に行うコード部分である１つまたは複数のメソッドを含む。前記処理系による実行が成功した場合、前記サーバアプリケーションは、必要に応じて、クライアントに対して応答を送る。前記サーバアプリケーションは、例外情報を戻すこともある。分散型オブジェクトシステムを標準化するために、コンピュータソフトウエア会社の協会であるオブジェクト管理グループ（“ＯＭＧ”：Object Management Group)は、“ＣＯＲＢＡ”（Common Object Request Broker Architecture）を提案した。ＣＯＲＢＡ基準の下では、オブジェクトリクエストブローカ（“ＯＲＢ”）は、そのシステムにおけるすべてのオブジェクトのために、サーバに対してリクエストを送り、クライアントに応答を送る通信ハブを提供する。市販のＯＲＢは従来より知られており、一般的なタイプとしては、ＩＢＭのSystem Objec t Model（“ＳＯＭ”）がある。クライアント側のＯＲＢは、メソッドの実行、ならびに、これに関連したサーバおよびメソッドの選択を要求するリクエストを取り扱う。クライアントアプリケーションが、前記ＯＲＢに対して、１つのオブジェクトについて実行すべきメソッドを要求するリクエストを送ると、前記ＯＲＢでは、該リクエストに含まれる引数をそのオブジェクトのインターフェイスに対して検査し、該リクエストをサーバに送り、必要な場合それを開始する。サーバ側のＯＲＢは、前記リクエスト中の情報を使用して、該リクエストを満足させる最良の処理系を決定する。前記リクエスト中の情報には、前記クライアントが要求しているオペレーション、該オペレーションがどのオブジェクトについて実行されるかについての情報、さらに、前記リクエストについて格納されている付加情報が含まれる。さらに、前記サーバ側のＯＲＢは、各リクエストおよびその引数を検査する。さらに、該ＯＲＢは、前記クライアントに応答を送る機能も果たす。クライアントアプリケーションおよびサーバアプリケーションは、共に、オブジェクトおよびこれらのオブジェクトについて実行可能なオペレーションを含む利用可能なインターフェイスについての情報を有する必要がある。インターフェイス定義の共用化を容易にするために、前記ＯＭＧは、インターフェイス定義言語（“ＩＤＬ”）を提案した。該ＩＤＬは、オブジェクトのインターフェイス、すなわち、該オブジェクトについて実行可能なオペレーションを含む該オブジェクトの特徴および作用を記述するために使用される定義言語である（プログラミング言語ではない）。ＩＤＬは、ＯＭＧのＣＯＲＢＡのRevision２．０仕様を実行する分散型オブジェクトシステムに使用されるよう設計されている。前記ＣＯＲＢＡ仕様を実行する典型的なシステムにおいて、インターフェイス定義は、ＩＤＬ定義ソースファイル（“翻訳単位”としても知られている）に書かれている。前記ソースファイルは、クライアントスタブファイル、サーバスタブファイルおよびヘッダファイルを含むプログラミング言語別ファイルを生成するＩＤＬコンパイラによってコンパイルされる。前記クライアントスタブファイルは、ある１つのオブジェクトタイプに関するＩＤＬオペレーション定義の手続きルーチンへの、各言語別の対応づけ（マッピング）であり、各オペレーション毎に１つ設けられる。ある言語に固有のコンパイラによってコンパイルされ、クライアントアプリケーションにリンクされる場合、スタブルーチンは、リクエストを記述するために、前記クライアントアプリケーションによって呼び出されることができる。同様に、前記サーバスタブファイルは、ある１つのオブジェクトタイプに関するＩＤＬオペレーション定義（インターフェイスによる定義）の手続きルーチンへの、各言語別の対応づけである。コンパイルされ、サーバアプリケーションにリンクされる場合、前記サーバアプリケーションは、対応するリクエストが到着した時にこれらのルーチンを呼び出すことができる。前記ヘッダファイルは、コンパイルされ、クライアントアプリケーションおよびサーバアプリケーションにリンクされ、共通のデータ型および構造体を定義するために使用される。一般的に、コンピュータシステムは、（１）一方向通信、（２）同期通信および（３）非同期通信、である３つの通信方式のうちのいずれか１つを使用する。分散型オブジェクトシステムにおけるクライアントアプリケーションが一方向通信リクエストを呼び出すと、前記アプリケーションは、このリクエストを送り、そして、該リクエストが完了したか否かをチェックすることなく他の作業を続行する。この場合、前記リクエストは、実際、一方向のみ送られる。すなわち、前記アプリケーションは前記リクエストをサーバに送るが、該サーバからは何の応答も戻されない。また、クライアントアプリケーションが同期通信リクエストを呼び出すと、前記アプリケーションは、制御をＯＲＢに移し、該リクエストが完了しまたは失敗するまで何も実行することができない。アプリケーションが一定の順序でリクエストを送ったり完了させたりする必要があり、オペレーションが短い時間のものである場合、同期通信は最も適切である。アプリケーションが非同期オブジェクトコールを呼び出した場合、前記アプリケーションは、該リクエストが完了するのを待たずに、他の作業を続行する。時間が重要要素である情況下においては、非同期通信はオブジェクトコールのための最も好ましい方式である。同様に、非同期通信が効率的にサポートされる場合、サーバアプリケーションにおけるオブジェクトの実行が有用である。しかし、残念ながら、従来の分散型オブジェクトシステムは、クライアントアプリケーションからのオブジェクトコールについて、真の非同期通信をサポートするものではない。例えば、前記ＣＯＲＢＡ仕様は“遅延型同期通信”を提供する。この遅延型同期通信において、リクエスト側アプリケーションは、CORBA_Re quest_get_responseオペレーションまたはCORBA_get_next_responseルーチンを使用して連続的にポーリングすることによって、リクエストが完了したか否かを定期的にチェックする。しかし、この処理は、時間がかかり、真の非同期通信の持つ利点を提供するものではない。さらに、従来の分散型オブジェクトシステムは、非同期のオペレーションを取り扱うための処理から分岐する実行ストリームである“スレッド（thread）”をサポートする。しかし、このスレデッド型の実行には、共通データに対するアクセスを同期させなければならないという不都合、全体的な動作効率ロスおよびプラットフォーム依存等の問題点がある。従って、分散型オブジェクトシステム内において真の非同期オブジェクト呼び出し（コール）を実行するための方法および装置が必要とされている。さらに、スレデッド型実行を使用することなく非同期オブジェクト処理を実行するための方法および装置が必要とされている。発明の要旨この発明は、非同期のオブジェクト呼出しを実行するための方法および装置を提供する。さらに、この発明は、スレッド化されていない非同期のオブジェクト実行をなす方法および装置に対する需要を満たすものである。好ましい実施の形態において、この発明に係る非同期のオブジェクト呼出しを実行する方法は、クラアントアプリケーションからスタブ関数を呼び出すことによって、オブジェクトについてのオペレーションを実行することを含む。前記クラアントアプリケーションは、前記スタブ関数に対して、前記オペレーションに対する入力パラメータおよび完了ルーチンを指示するポインタを与える。前記呼出しは、前記クラアントアプリケーションおよびサーバアプリケーションに共通の実行環境を使用して、サーバアプリケーションに送られる。前記サーバアプリケーションは、前記オブジェクトについてのオペレーションを実行し、前記実行環境に対して応答を送る。前記オペレーションが前記サーバアプリケーションによって実行されると、前記実行環境は、前記オペレーションの出力パラメータと共に、前記完了ルーチンを呼び出す。該完了ルーチンは、さらに、前記オブジェクト呼出しが成功したか否かを判定する。前記の実行は、非同期式に行うこともできる。非同期実行の間、クラアントアプリケーションは、オブジェクトについてオペレーションが実行されることをリクエストする（上述のように、このリクエストは同期式または非同期式になされてよい）。前記リクエストは、前記クラアントアプリケーションおよびサーバアプリケーションの両方によってアクセス可能な実行環境によって、前記サーバアプリケーションに送られる。前記リクエストが送られると、前記サーバアプリケーションは、前記呼出しを呼出し識別子に関連付ける。前記サーバアプリケーションから非同期メソッドが呼び出される場合、該サーバアプリケーションは、前記呼出し識別子および応答関数のアドレスを前記非同期メソッドに送る。コールバック関数（“完了ルーチン”および“応答関数”）を使用することにより、前記クラアントアプリケーションおよびサーバアプリケーションの両方は、特定の関数内で待機することなく、他の作業を行い続けることができる。さらに、クラアントおよびサーバの両方が非同期式に実行できるようにすることによって、異なる呼出し方式を用いて、特定のタスクに適応できる。例えば、オブジェクト呼出しを非同期式に行い、その実行を同期式に行ってよく、または、その逆であってもよい。このようにして、開発者に対してより高い自由度が提供される。非同期式に呼出しを実行するための方法および装置、ならびに、その利点および目的は、添付図面を参照して以下に述べるこの発明の詳細な説明によって、より完全に理解されるであろう。図面の簡単な説明図１は、この発明の方法を使用したクライアント／サーバシステムを示す図。図２Ａおよび図２Ｂは、共通実行環境（ＣＥＥ）カプセルの異なる構成を示す図。図３は、ＣＥＥカプセルおよびそのコア要素を示す図。図４は、ＩＤＬソースコードのコンパイルおよびクライアントアプリケーションおよびサーバアプリケーションへのリンクを説明する図。図５は、同期オブジェクト呼出しに係るステップを示すフローチャート。図６は、非同期オブジェクト呼出しに係るステップを示すフローチャート。図７は、非同期オブジェクト呼出しを実行するプログラミングコードの一部を示す図。図８は、オブジェクトの非同期実行に係るステップを示すフローチャート。図９は、非同期オブジェクト実行を行うプログラミングコードの一部を示す図。図１０は、この発明の方法の第２の実施の形態を示すフローチャート。図１１は、この発明の方法に係るステップを示すフローチャート。図１２は、この発明の方法の他の実施の形態に係るステップを示すフローチャート。図１３は、ＰＩＦデータ構造を示す図。図１４は、エントリデータ構造を示す図。図１５は、オペレーションデータ構造を示す図。図１６は、共用体データ構造を示す図。好適な実施の形態の詳細な説明以下、添付図面に示した例を参照して、この発明の好適な実施の形態を詳細に説明する。添付図面において、同一または類似した構成要素には同一の参照番号が付されている。Ｉ．システムの概要図１に示すように、この発明の方法は、分散型（クライアント／サーバ）コンピューティング環境１０に使用されるよう設計されている。該クライアント／サーバシステムは、インターネット接続部またはローカルエリアネットワーク接続部のようなネットワーク接続部１２によって接続されている。サーバコンピュータ１１は、バスまたはＩ／Ｏチャンネル２０を介して、ディスク記憶サブシステム１３と通信する。サーバシステム１１は、ＣＰＵ１５と、プログラムの実行についての現在の状態情報を格納するためのメモリ１７とを具備している。該メモリ１７の一部は、クライアントコンピュータ上で現在実行されているプログラムの各関数に関連した状態および変数を格納するために専用される。同様に、クライアントコンピュータ２１は、ＣＰＵ２７とこれに関連するメモリ２３と、キーボード２９またはマウス３１のような入力装置２９と、ビデオ表示端末（“ＶＤＴ”）のような表示装置３３とを具備している。該クライアントのＣＰＵは、バスまたはＩ／Ｏチャンネル４０を介してディスク記憶サブシステム３３と通信し、また、Ｉ／Ｏチャンネル４１を介してキーボード２９、ＶＤＴ３３およびマウス３１と通信する。好ましくは、前記クライアントメモリ２３は、クライアントスタブ７９に後述のようにリンクされるクライアントアプリケーション７７がロードされている。同様に、前記サーバメモリ１７には、サーバスタブ８９にリンクされるサーバアプリケーション８７を含む。さらに、前記クライアントメモリおよびサーバメモリは、共に、実行環境（“ＣＥＥ”）７５，８５を含んでいる（後述）。図１に示すクライアント／サーバモデルは、単に、典型的なクライアント／サーバシステムを例示するものである。この発明によると、前記クライアントは、あるオブジェクトについてオペレーションが実行されるべきことをリクエストするアプリケーションであり、前記サーバは、前記オブジェクトについて前記オペレーションを実行するアプリケーションである。実際上、前記クライアントアプリケーションおよびサーバアプリケーションは、後述のように、同一のコンピュータおよび共通のカプセル内に備えられていてよい。しかし、ほとんどの場合、前記クライアントアプリケーションおよびサーバアプリケーションは、異なるオペレーティングシステムを使用する異なるコンピュータに備えられることになる。以下、この発明の方法を、異なるマシーン上で動作する２つのカプセルについて説明する。 II．分散型コンピューティング環境この発明の方法および装置は、任意の分散型コンピューティング環境内で利用可能である。好ましい実施の形態において、Tandem Message Switching Facilit y（“ＭＳＦ”）Architectureの一要素である共通実行環境（“ＣＥＥ”）７５，８５が使用される。前記ＣＥＥは、オブジェクトを起動したり停止したりするものであり、ＣＥＥカプセルにロードされたクライアントアプリケーションとサーバアプリケーションとの間でメッセージのやり取りするために使用される。該ＣＥＥは、１つのマシーンのメモリに格納されてよい。しかし、該ＣＥＥ、クライアントアプリケーションおよびサーバアプリケーションは、図１に示すように、ネットワーク上の多数のマシーンにロードされてもよい。クライアント側のＣＥＥ７５は、クライアントメモリ２３に格納されている。また、サーバ側のＣＥＥ８５は、サーバメモリ１７に格納されている。前記共通実行環境（“ＣＥＥ”）は、“カプセル”下部構造を使用する。該カプセルは、メモリスペースおよび１つまたは複数の実行ストリームを封入するものである。カプセルは、異なるシステムでは、当該システムによって使用されるオペレーティングシステムに応じて、異なる態様で実現されてよい。例えば、あるシステムでは、前記カプセルはプロセスとして実現される。また、他のシステムでは、前記カプセルはスレッド（thread）として実現される。さらに、クライアントアプリケーションおよびサーバアプリケーションは、図１に示すように異なるマシーンに含まれる異なるカプセル内に構成されてもよい。代案として、異なるカプセルが図２のように構成されてもよい。図２Ａは１つのカプセル８１にロードされたクライアントアプリケーション７７を示し、この場合、サーバアプリケーション８７は別のカプセル８５にされてよい。しかし、これら２つのアプリケーションは、同一のマシーン２１に格納されている。また、図２Ｂに示すように、前記クライアントアプリケーションおよびサーバアプリケーションは、共に、同一のマシーン２１上の１つのカプセル８１内にロードされてもよい。上述のように、ここでは、多数のカプセル、多数のマシーンを使用する例についてこの発明の方法を説明する。従って、クライアントマシーン１２およびサーバマシーン１１は、それぞれのメモリにロードされたクライアント側ＣＥＥ７５およびサーバ側ＣＥＥ８５を備えている。図３は、例えば、クライアントコンピュータメモリ２７（ここでは図示せず）に格納されたＣＥＥカプセル７０を示すものであり、該ＣＥＥカプセル７０は、ＣＥＥ７５、ならびに、コアＣＥＥ要素および処理系ライブラリ７１内に含まれるオブジェクトの処理系のうちのいくつかを含むものである。前記処理系ライブラリ７１は、後述のように、オブジェクトインターフェイスのＩＤＬ仕様書から生成されたクライアントアプリケーション７９（サーバカプセルの場合、サーバアプリケーション）およびクライアントスタブ７７（またはサーバスタブ）を含んでいる。前記処理系ライブラリ７１およびＣＥＥ７５は、該ＣＥＥによって供給される動的アクセス可能なルーチンのダウンコーリングおよび前記処理系ライブラリに含まれるルーチンのアップコーリングによって、相互作用する。また、前記ＣＥＥ７５は、同じマシーン内の他のカプセルからのオブジェクトコール８２、および、他のＣＥＥからのリクエスト８４を受け取ることができる。前記クライアント側ＣＥＥ７５およびサーバ側ＣＥＥ８５は、任意の既知のネットワークプロトコルを使用して通信することができる。ＣＥＥカプセルで実現されるオブジェクトは、構成オブジェクトまたは動的オブジェクトであってよい。構成オブジェクトの処理系の詳細は、（MSF Warehous e85のような）格納部または初期化スクリプトに格納されている。特定のオブジェクト参照に対するリクエストがあった場合、前記クライアント側ＣＥＥ７５では、この構成データに基づいて適切なカプセルを始動する。前記カプセルは、この構成データを使用して、ロードすべき処理系ライブラリおよび呼び出すべきオブジェクト初期化ルーチンを決定する。そして、前記オブジェクト初期化ルーチンがそのオブジェクトを作成する。動的オブジェクトは、同一のカプセル内において、動的に作成され、破棄される。該動的オブジェクトには、格納部に格納されたまたはスクリプト化された構成情報が無い。以下のパラグラフでは、前記処理系ライブラリがどのようにＣＥＥ７５と相互作用するのかについてシステムレベルで概説する。前記ＣＥＥ７５は、カプセル内でオブジェクトを起動したり停止したりするためのリクエストを実行する。さらに、上述の如く、前記ＣＥＥは、カプセル間オブジェクトコール８２および他のＣＥＥ８４からのリクエストを容易にする。オブジェクト起動リクエストは、クライアントアプリケーションまたはサーバアプリケーションからのオブジェクトコールが満足させられなければならない場合に発生する。以下に示すように、オブジェクトを起動するためには、前記ＣＥＥ７５は、それが未だロードされていない場合、前記オブジェクトのメソッドを含む適切な処理系ライブラリをロードし、その後、前記処理系ライブラリに含まれる構成オブジェクト初期化ルーチンを呼び出す。該初期化ルーチンは、前記処理系ライブラリがサポートするインターフェイスを指定し、その後前記ＣＥＥによって呼出すべき前記オブジェクトのメソッドのエントリポイントを登録する。クライアントシステムおよびサーバシステムが始動すると、前記クライアント側ＣＥＥおよびサーバ側ＣＥＥは各々の初期化を実行する。この初期化は、前記クライアント側ＣＥＥおよびサーバ側ＣＥＥに対して、様々な前記処理系ライブラリの位置を指示する。前記ＣＥＥによる位置検出がなされると、前記ＣＥＥは、前記クライアントアプリケーションおよびサーバアプリケーションにおける初期化ルーチンを呼び出す。次に、前記クライアントアプリケーションおよびサーバアプリケーションに含まれる初期化ルーチンは、先ず、必要とされるアプリケーション別の初期化を実行しなければならない。次に、クライアント初期化ルーチンおよびサーバ初期化ルーチンが生成されたスタブ関数を呼出し、該スタブ関数は、前記オブジェクトのインターフェイスを指定するために、GEE_INTERFACE_ CREATEと称される（上述の如く動的ライブラリに含まれる）ＣＥＥ関数をダウンコールする。各オブジェクトごとにインターフェイスを指定してよい。後述のように、このインターフェイスの記述は、通常、該インターフェイスのＩＤＬ記述から生成される。GEE_INTERFACE_CREATEは、インターフェイスを作成し、この新たに作成されたインターフェイスに“インターフェイスハンドル”を戻す。前記ハンドルは、前記インターフェイスを指示するユニークな識別子である。そして、前記サーバアプリケーションの初期化ルーチンは、前記インターフェイスハンドルを使用して、GEE_IMPLEMENTATION_CREATEをダウンコールする。該GEE_IMPLE MENTATION_CREATEは、１つまたは複数のオブジェクトで使用可能な実行記述を作成する。該GEE_IMPLEMENTATION_CREATEは、前記インターフェイスにおいて各オペレーションごとの処理系を指示するユニークな識別子である“処理系ハンドル ”を戻す。最後に、前記サーバアプリケーションの初期化ルーチンは、前記処理系ハンドルを使用して、CEE_SET_METHODをダウンコールするスタブ関数を呼び出す。該CEE_SET_METHODは、前記サーバアプリケーションに含まれる前記処理系の特定のメソッドルーチンの実際のアドレスを指示する。こうして、前記ＣＥＥは、前記クライアントアプリケーションにおけるオブジェクト呼出しを、前記サーバアプリケーションにおける特定のメソッドに接続する。 III．ＩＤＬソースファイルのコンパイルおよびリンク図４は、ＩＤＬソースファイルが、コンパイルされ、この発明の方法および装置を使用するクライアントアプリケーションおよびサーバアプリケーションにリンクされる手順を示すものである。先ず、ＩＤＬインターフェイス定義を含むＩＤＬソースファイル１０１が作成される。ＩＤＬコンパイラ１０３は、前記ＩＤＬソースファイル１０１をコンパイルする。前記ＩＤＬコンパイラ１０３は、オリジナルソースファイルの格納するために、コード１０１を分析して中間的なPi ckled IDLファイル（“ＰＩＦ”）１０５を生成する。ＰＩＦファイルの生成は、下記のセクションVIIIにおいて説明されている。コードジェネレータ１１１はＰＩＦファイルを分析する。しかしながら、好ましくは、前記ソースファイルから直接にコードを生成するために、前記ＩＤＬコンパイラおよびコードジェネレータは組み合わされる。前記コードジェネレータ１１１は、前記クライアントアプリケーションおよびサーバアプリケーションの言語のファイルを生成する。前記クライアントアプリケーションとサーバアプリケーションとが異なる言語によるものである場合、異なるコードジェネレータ１１１が使用される。代案として、前記コードジェネレータ１１１およびＩＤＬコンパイラ１０３は、１つのアプリケーションにおいて、言語別コードを生成するために組み合わされてもよい。前記コードジェネレータ１１１は、クライアントスタブ関数を含むクライアントスタブファイル７７と、オブジェクト実行についての定義を含むサーバスタブファイル８７とを生成する。コンパイルされたクライアントスタブオブジェクトコードおよびコンパイルされたサーバスタブオブジェクトコードを生成するために、前記クライアントスタブファイル７７およびサーバスタブファイル８７は、プログラミング言語別のコンパイラ１２１，１２３によってコンパイルされる。同様に、コンパイルされたクライアントアプリケーションオブジェクトコードおよびコンパイルされたサーバアプリケーションオジェクトコードを生成するために、クライアントアプリケーション７９およびサーバアプリケーション８９は、プログラミング言語別のコンパイラによってコンパイルされる。前記クライアントアプリケーション７９およびサーバアプリケーション８９は、さらに、前記コードジェネレータ１１１によって生成されるヘッダファイル１１９を含む。該ヘッダファイル１１９は共通の定義および宣言を含む。最後に、コンパイラ１２１は、前記クライアントアプリケーションオブジェクトコードとクライアントスタブオブジェクトコードとをリンクすることにより、処理系ライブラリ７１を生成する。同様に、第２のコンパイラ１２３は、前記サーバアプリケーションオブジェクトコードとサーバスタブオブジェクトコードとをリンクすることにより、他の処理系ライブラリ８１を生成する。 IV．非同期クライアントスタブファイルおよびサーバスタブファイル前記コードジェネレータ１１１は、クライアントスタブ関数７７において、前記ＩＤＬソースファイル１０１に定義された各インターフェイスの各オペレーションごとに同期クライアントスタブ関数および非同期クライアントスタブ関数を生成する。各スタブ関数は、前記ＩＤＬソースファイル１０１に定義された１つの特定のオペレーションに対応する。前記クライアントアプリケーション７９は、これらのスタブ関数を呼出して、あるオブジェクトについてオペレーションが行われることをリクエストする。前記同期クライアントスタブ関数は、当該オペレーションの入力パラメータおよび前記オブジェクトに対する参照（プロキシ一つまり代理ハンドルの形態での参照）を受け取る。前記同期クライアントスタブ関数は、（以下に示すように）前記クライアント側ＣＥＥ全体に対するオブジェクト呼出しを行うために使用されるCEE_OBJECT_CALLへの呼出しを含む。また、前記非同期クライアントスタブ関数は、リクエストされたオペレーションのための入カパラメータ、プロキシーハンドルおよび完了ルーチンアドレスを示すポインタを受け取る。これらのパラメータは、同様に後で詳述するＣＥＥ関数CEE_OB JECT_CALL_POSTに送られる。同様に、前記コードジェネレータ１１１は、サーバスタブ関数８７において、同期サーバスタブ関数および非同期サーバスタブ関数を生成する。各スタブ関数は、前記ＩＤＬソースファイル１０１に定義された１つの特定のオペレーションに対応する。前記サーバアプリケーションは、これらのスタブ関数を呼出し、該スタブに対応するインターフェイスオペレーションを実行するためにアップコールすべきメソッドを前記ＣＥＥに通知する。各オペレーションの同期サーバスタブ関数は、（CEE_IMPLEMEMTATION_CREATEに対する呼出しから戻される）処理系ハンドル、および、前記サーバアプリケーションにおけるメソッドのアドレスを受け取る。前記サーバアプリケーションにおいて呼出されると、前記同期サーバスタブ関数は、CEE_SET_METHODを呼出し、前記サーバアプリケーションのメソッドを前記スタブによって指定されたオペレーションに接続する。特定のオペレーションに対するリクエストが前記サーバ側ＣＥＥに到達すると、該サーバ側ＣＥＥは、そのリクエストされたオペレーションについて設定されたアドレスに基づいて、前記サーバアプリケーションにおける適切なメソッドを呼び出す。前記サーバアプリケーションのメソッドが戻されると、前記サーバ側ＣＥＥはクライアントに対して応答を送る。前記コードジェネレータ１１１は、非同期オブジェクト実行を処理するためのスタブ関数を生成する。前記非同期サーバスタブ関数は、（前記サーバアプリケーションから）処理系ハンドルおよび前記サーバアプリケーションからアップコールすべきメソッドのアドレスを受け取る、という点で前記同期スタブ関数と同様である。前記非同期スタブ関数は、前記サーバアプリケーションのメソッドを前記スタブに対応したオペレーションに接続するCEE_SET_METHODを呼び出す。このCEE_SET_METHODに対する呼出しは、(CEE_SET_METHODのパラメータを介して）前記ＣＥＥに対して、前記メソッドが非同期式に実行されるべきことを通知する。アップコールされた前記サーバアプリケーションのメソッドは非同期的なものであるので、前記ＣＥＥは、同様に前記サーバスタブファイル８７に含まれる生成された応答スタブ関数を呼び出すと直ぐに、前記クライアントに対して応答する。前記生成された応答スタブ関数は、前記オペレーションの出力パラメータおよび呼出し識別子を受け取る。これらのパラメータは、前記クライアントアプリケーションに応答するＣＥＥ関数CEE_RESPOND（後述）に送られる。Ｖ．同期呼出しおよび実行ならびに非同期呼出しおよび実行Ａ．同期呼出し／同期実行次に図５〜図１０を参照して、この発明の方法を説明する。ここでは、呼出すべきサーバオブジェクトが前記サーバ側ＣＥＥによって予め起動されている、と仮定する。上述のように、オブジェクト呼出しは、生成された同期クライアントスタブおよび非同期クライアントスタブを介して同期式または非同期式に実行されてよい。同様に、前記サーバアプリケーションにおけるオブジェクト実行も、同期式または非同期式に実行されてよい。ここに説明する方法および装置は、異なるマシーンにロードされた異なるカプセルを使用する。先ず、同期オブジェクト実行と組み合わされる同期オブジェクト呼出しについて説明する。図５は、オブジェクトに対する同期呼出しに係るステップを説明するフローチャートである。最初のステップ５０１では、前記クライアントアプリケーションによって、所望のオブジェクトについてのオブジェクト参照が得られなければならない。該オブジェクト参照は、様々な方法で得ることができる。通常、クライアントアプリケーションは、これらがオブジェクト参照を有する他のオブジェクトについての構成（configuration）データ、ディレクトリまたは呼出しから前記オブジェクト参照を受け取る。オブジェクト参照は、後にアクセスされるファイルに格納可能な文字列名に変換可能である。前記オブジェクト呼出しは、ステップ５０３において、先ず前記ＣＥＥから該オブジェクト参照に対する“プロキシーハンドル”を得ることによって開始される。前記プロキシーハンドルは、その都度オブジェクトを呼び出す際に発生することになるオーバーヘッドを招くことなく、同一のオブジェクトに対する多くの呼出しを容易にするよう設計されている。複数のオブジェクト呼出しを実行可能なプロキシーハンドルを作成することによって、前記プロキシーハンドルを介して、プロキシーオブジェクトに対する多くの同時呼出しを可能にしながら、初期化ルーチンを一通り実行することができる。プロキシーハンドルは、前記クライアントアプリケーションからＣＥＥ関数CEE_PROXY_CREATEをダウンコールすることによって、ＣＥＥ７５において作成される。前記関数はＣプログラミング言語により次のように定義される。 CEE_PROXY_CREATE( const char ^*objref， const char ^*intf_handle， char ^*proxy_handle); 前記関数は、CEE_INTERFACE_CREATE（上述）によって戻されるオブジェクト参照 objrefおよびインターフェイスハンドルintf_handleを受け取り、新たに作成されたプロキシーオブジェクトを示すプロキシーハンドルを戻す。プロキシーの作成の詳細、および、CEE_PROXY_CREATEによって戻されるプロキシーハンドル構造の記述については、下記のセクションVIおよびVIIにおいて説明する。 CEE_PROXY_CREATEによって戻される前記プロキシーハンドルは、当該オブジェクトが同一のカプセル内にある場合は該オブジェクトを指示するポインタを含む構造体であり、当該オブジェクトが同一のカプセル内にない場合はクライアントポートを指示するポインタを含む構造体である。さらに、前記クライアント側ＣＥＥは、前記プロキシーを使用して、非同期オブジェクト呼出し（後述）に使用される完了ルーチンのアドレスを格納する。該完了ルーチンについては、前記クライアントアプリケーションからの非同期呼出しに関して詳述する。同期オブジェクト呼出しにおいては、完了ルーチンのアドレスは前記プロキシーハンドル構造に格納されない。ステップ５０５において、前記クライアントは前記オブジェクトを呼び出す。より詳しくは、前記クライアントアプリケーションは、適切に生成された同期スタブ関数を呼び出すことによって前記オブジェクトについてオブジェクトのインターフェイスのオペレーションが実行されることをリクエストする。前記同期スタブ関数はCEE_OBJECT_CALLに対するダウンコールを含むものであり、該CEE_OBJ ECT_CALLはCプログラミング言語により次のように定義される。 CEE_OBJECT_CALL( const char ^*proxy_handle， long ^*operation_idx， void ^*param_vector); 前記スタブ関数は、前記プロキシーハンドルおよび前記オペレーションのための入力パラメータを受け取る。前記スタブ関数は、３つのパラメータを有するCEE_ OBJECT_CALLを提供する。最初のパラメータはproxy_handleである。２番目のパラメータoperation_idxは、オブジェクトのどのメソッドを呼び出すべきかを指示する整数である。該識別子は、クライアントによって、特定のオペレーションを指示するために局所的に使用される。該識別子は、クライアント側においてオペレーション名について繰返し文字列比較を実行する面倒を省くものである。同様に、サーバ側でも、該サーバは、自己のオペレーション識別子を使用してオペレーションを指示する。param_vectorは、前記オブジェクト呼出しの入力パラメータ、出力パラメータおよび例外構造体のアドレスを含むアレイである。好ましくは、例外構造体のアドレスは、前記アレイにおける最初の構成要素である。前記オペレーションがvoid（空）タイプのものでない場合、前記アレイにおける次の構成要素は、前記オペレーションの結果を受け取るための変数のアドレスを含む。後の構成要素は、ＩＤＬにおいて定義された順序と同じ順序で、前記オペレーションの入力パラメータおよび出力パラメータのアドレスを含む。ステップ５０７では、入力パラメータ、オペレーション識別子および（プロキシーハンドルによって決定される）オブジェクト参照を含む、実行すべきオペレーションを要求するリクエストが、ＣＥＥインターフェイス８４を介して前記クライアント側ＣＥＥから前記サーバ側ＣＥＥに送られる。上述のように、前記ＣＥＥは、システムまたはネットワーク間で前記呼出しを伝送するための任意のデータ伝送方法を使用してよい。前記オブジェクトを非同期式に実行するために、前記サーバ側ＣＥＥ８５は、（CEE_SET_METHODを呼び出すサーバスタブ関数に対する初期化ルーチンの呼出しによって指示される）前記サーバアプリケーションにおける適切なメソッドを呼び出す。好ましくは、前記サーバ側ＣＥＥ８５は、前記サーバアプリケーションにおけるメソッドに対して３つのパラメータ、すなわち、（１）前記呼出しのためにメモリを割当てたり、割当てを解除したりするために前記サーバアプリケーションによって使用される任意の呼出し識別子、（２）コーラ（呼出し側）に戻され得るエラー情報を保持する例外識別子、および、（３）ＩＤＬで当初定義された順序で配列されたリクエストされたオペレーションのための入力パラメータ、を与える。前記メソッドは、ステップ５０９において、前記入力パラメータを使用し、前記メソッドを実行する。図１０に関して後述するように、前記呼出し識別子を使用することにより、前記サーバアプリケーションのメソッド内で自動的に前記メモリを割当てたり、割当てを解除したりする他のＣＥＥ関数を呼び出すことができる。前記クライアントによってリクエストされたオペレーションが出力パラメータを含むものである場合、前記サーバアプリケーションにおけるメソッドは、該メソッドの本体内で前記出力パラメータを初期化し、（必要ならば）これを修正する。前記メソッドが完了すると、ステップ５１１において、前記出力パラメータを前記サーバ側ＣＥＥに戻す。該サーバ側ＣＥＥは、ステップ５１３において、前記クライアントアプリケーションにおける呼出し側関数に応答する。この応答メッセージは、（もし存在する場合）前記オペレーションの成功または失敗に関する任意のサーバ側ＣＥＥで生成された例外情報と共に前記出力パラメータを含むものである。こうして、前記オブジェクト呼出しが完了する。Ｂ．非同期呼出し／同期実行図６は、前記クライアントアプリケーションからの非同期オブジェクト呼出しを、同期実行と組み合せて実行する。初めいくつかのステップは前記同期オブジェクト呼出しの場合のステップと同様である。ステップ６０１において、前記クライアントアプリケーションはオブジェクト参照を得る。ステップ６０３では、前記クライアントアプリケーションは、CEE_PROXY_CREATEを使用して、前記オブジェクト参照に関するプロキシーハンドルを作成する。次のステップ６０５では、生成された非同期クライアントスタブ関数を使用して、前記オブジェクトを呼び出す。この生成された非同期クライアントスタブ関数は、前記オブジェクトのプロキシーハンドル、オペレーションの入力パラメータ、呼出しタグ（後述）および前記クライアントアプリケーション内における“ 完了ルーチン”のアドレスを受け取る。前記オブジェクト呼出しに対する応答が戻された時、前記クライアント側ＣＥＥによって前記完了ルーチンが呼出されることになる。前記非同期クライアントスタブ関数は、前記オブジェクトを呼び出すクライアント側ＣＥＥ関数CEE_OBJECT_CALL_POSTをダウンコールする。該CEE_ OBJECT_CALL_POSTはCプログラミング言語により次のように定義される。 CEE_OBJECT_CALL_POST( const char ^*proxy_handle， long ^*operation_idx， const void ^*const^*param_vector， void ^*completion_routine， char ^*call_tag1)；前記スタブ関数は、リクエストされたオブジェクトのプロキシーハンドル、および、前記オブジェクトのどのオペレーションを実行すべきかを指示するオペレーションインデックスを供給する。ここで供給される前記param_vectorパラメータは、前記オブジェクト呼出しの入力パラメータのアドレスのみを含むアレイである。前記入力パラメータは、多数のプラットフォーム間におけるオブジェクト呼出しを可能にするよう、ＩＤＬで当初定義された順序のアレイで格納される。前記call_tag1は、前記オブジェクトに対する呼出しを識別するために使用される定数である。さらに、前記非同期クライアントスタブ関数およびCEE_OBJECT_CALL_POSTは、前記オブジェクトに対する応答が前記クライアントアプリケーションに戻され、または、エラー状態（あるいは他の例外）が前記クライアント側ＣＥＥに受け取られた時に前記クライアント側ＣＥＥ７５によって呼出される前記クライアントアプリケーションにおける“完了ルーチン”のアドレスを受け取る。ステップ６０７において、前記クライアント側ＣＥＥは、後における使用のために、前記プロキシーハンドルに前記完了ルーチンのアドレスを格納する。特定のプロキシーハンドルについての呼出しが戻されると、前記クライアント側ＣＥＥは、前記プロキシー構造体から前記完了ルーチンのアドレスを抽出し、該完了ルーチンを呼び出す。該完了ルーチンについては後述する。これと同じ完了ルーチンを必要とする多数の呼出しがなされる場合、前記完了ルーチン内の特定の呼出しを識別するために、前記call_tag1パラメータを使用してよい。該call_tag1パラメータも、ステップ６０７において、前記プロキシー構造体に格納される。ステップ６０９では、移送メカニズムを使用して、オブジェクトについて実行すべきオペレーションを要求するリクエストが前記クライアント側ＣＥＥから前記サーバ側ＣＥＥに送られる。前記オブジェクト呼出しがなされると、前記クライアントは他の関数の実行を続ける。前記同期呼出しのように応答を待つ必要がない。さらに、応答を得るためにサーバに対して連続的にポーリングするために、前記クライアントアプリケーションは必要とされない。サーバ側において、前記オブジェクトは上述のように同期式に実行される。前記サーバ側ＣＥＥでは、前記オペレーションを実行するために前記サーバアプリケーションにおける適切なメソッドを選択する。前記メソッドは、ステップ６１１において前記リクエストされたオブジェクトについてのオペレーションを実行し、ステップ６１３において前記クライアントアプリケーションに応答する。ステップ６１５において、前記サーバ側ＣＥＥは、前記クライアント側ＣＥＥに対して、出力パラメータと例外情報を含む応答を送る。前記クライアント側ＣＥＥは、前記送られた応答のプロキシーハンドル構造体を前記クライアントＣＥＥカプセルに格納する。そして、ステップ６１７において、前記クライアント側ＣＥＥは、前記プロキシーハンドル構造体から前記完了ルーチンのアドレスおよびcall_tag1を抽出する。ステップ６１９において、前記クライアント側ＣＥＥは、前記クライアントアプリケーションの完了ルーチンを呼び出す。前記クライアント側ＣＥＥは、前記完了ルーチンに対して、前記例外情報、前記オブジェクトのメソッドの出力パラメータ、および、（多数の呼出しが同一の完了ルーチンを使用している場合）どの非同期呼出しが完了したのかを指示する任意の識別子タグ(call_tag1)を与える。こうして、前記クライアントアプリケーションにおける完了ルーチンは、必要に応じてこれらのパラメータを使用することができる。図７は、この発明のメソッドを使用するクライアントアプリケーション７７におけるサンプルコードを示す。該クライアントアプリケーションは、Ｃプログラミング言語で書かれている。この例において、クライアントは、Timeインターフェイスのオブジェクト（“Timeオブジェクト”）から現在の時間を得る。該オブジェクトは、前記TimeオブジェクトについてTim_Nowオペレーションの実行をリクエストすることによって現在の時間を得る。前記Tim_Nowオペレーションは、入力パラメータとして定数（LOCALまたはGMT）をとり、ローカル時間またはグリニッチ標準時間（ＧＭＴ）を戻す。ライン７０１において、前記クライアントアプリケーションは、前記Timeインターフェイス定義を含むＩＤＬソースファイルから前記コードジェネレータによって生成されたヘッダファイル１１９を含む。該ヘッダファイル１１９は、前記 Timeインターフェイスにおける各オペレーションごとに、Tim_Nowスタブ関数を含む同期および非同期のクライアント（およびサーバ）スタブ関数を含む。ライン７０２において、前記クライアント側ＣＥＥ７５によって、クライアント初期化ルーチンがアップコールされる。ステップ７０３において、前記クライアントは、CEE_INTERFACE_CREATEを呼び出すインターフェイススタブ関数を呼び出すことによって、前記Timeインターフェイスを前記クライアント側ＣＥＥ７５に登録する。前記ＣＥＥは、インターフェイスハンドルintfをクライアントに戻す。（変数sts（ステータス）は、デバッグ時に関数戻し値の検査を可能にするダミー変数である。) ライン７０３において、前記クライアントは、前記ＣＥＥに前に登録された構成（コンフィギュレーション）ファイルからオブジェクト参照を得る。参照objr efは、Timeインターフェイスのオブジェクトを指示するものである。前記クライアントアプリケーションはTIM_Nowを２回同時に呼び出すつもりであるので、前記クライアントは、ライン７０５および７０６において、前記オブジェクト参照を使用して２つのプロキシーハンドルを作成する。前記クライアントは、proxy およびproxy1を戻すCEE_PROXY_CREATEを呼び出す。ライン７０７では、前記クライアントは、非同期スタブ関数TIM_Now_pstを使用して前記Timeオブジェクトを呼び出す。前記クライアントは、第１のプロキシーハンドル（proxy）、完了ルーチンタグ（LOCAL_TIME_TAG）および入力パラメータ（LOCAL）を供給する。ライン７０８では、前記クライアントは、異なるプロキシーハンドル（proxy）、完了ルーチンタグ（LOCAL_TIME_TAG）および入力パラメータ（LOCAL）を使用して同一のオブジェクトに他の呼出しを実行することによって、他の非同期の作業を行う。最初の呼出しが同期式に行われた場合、 Tim_Nowに対して２番目の呼出しを行う前に前記Tim_Nowに対する最初の呼出しが戻るまで、クライアントアプリケーションは待機しなければならない。両前記呼出しについて、前記クライアント側ＣＥＥは、前記プロキシー構造体に前記完了ルーチンのアドレスおよび完了ルーチンのタグを格納する。前記クライアント側ＣＥＥ７５は、両リクエストを前記サーバ側ＣＥＥ８５に送る。前記サーバアプリケーションは、前記Tim_Nowオペレーションのための処理系を含んでいる。この処理系（図示せず）は、ローカル時間またはグリニッチ標準時間（ＧＭＴ）を提供する。該時間は出力パラメータに挿入され、該出力パラメータおよび例外情報は前記クライアント側ＣＥＥ７５に送り返される。前記クライアント側ＣＥＥは、どの呼出しが戻されたのかを判定し、該戻された呼出しのための完了ルーチンを呼び出す。この例の完了ルーチンは、ライン７０９から示されている。ライン７１０のswitch文は、任意の完了ルーチンのタグパラメータを受け取る。前記タグの値がLOCALである場合、前記関数はライン７１１−７１２に示されているようなローカル時間を印刷する。前記タグの値がGM Tである場合、前記関数はライン７１３−７１４に示されているようなＧＭＴ時間を印刷する。完了ルーチンタグの他の例によると、前記ＣＥＥは、１つの呼出しに対して新たな関数呼出しを行うごとに、連続したタグ番号を割当てる。Ｂ．非同期実行次に、図８を参照して、前記サーバアプリケーションによるオブジェクトの非同期実行について説明する。この非同期実行は、前記サーバアプリケーションにおけるオリジナルのメソッドが第２のメソッドを呼び出すことを含む。前記オリジナルのメソッドは、前記クライアントによって同期式または非同期式に呼び出されてよい。ここで説明するメソッドにより、オブジェクトは２つ以上の同時のリクエストをサポートすることができる。最初のステップ８０１において、前記クライアントは、前記オブジェクトを呼び出し、該オブジェクトについてオペレーションが実行されることをリクエストする。上述の如く、前記オブジェクト呼出し自体は同期的または非同期的なものでよい。しかし、前記呼出しが同期的なものであって、前記オブジェクトの実行が非同期的なものである場合、前記クライアントおよびオブジェクトは、ＭＳＦシステムにおける異なるカプセル内で実行されなければならない。ここでは、前記クライアントアプリケーションおよびサーバアプリケーションは、異なるマシーン上の異なるカプセル内で実行されるものと仮定する。ステップ８０３では、前記呼出しは、任意の既知の移送メカニズムを使用するインターフェイス８４を介して、前記クライアント側ＣＥEからサーバ側ＣＥＥに送られる。前記サーバ側において、ステップ８０５において、前記ＣＥＥは、リクエストされたオペレーションのために適切なメソッドを呼び出す。このメソッド（以下、“オリジナルメソッド”と呼ぶ）は、上述のように、前記初期化ルーチンから非同期スタブ関数に対する呼出しによって、前記リクエストされたオペレーションのための適切なメソッドとして明示されたものである。前記ＣＥＥは、前記同期実行の場合と同様なパラメータ、すなわち、（１）call_idパラメータ、（２）前記オブジェクトを実行する際のエラーを検出するために使用される例外パラメータ、および、（３）前記オペレーションに対する入力パラメータ、を前記サーバアプリケーションにおけるオリジナルメソッドに与える。しかし、この非同期実行の場合、前記サーバアプリケーションメソッドに与えられる呼出し識別子は、前記サーバコンピュータメモリ１７におけるサーバ側ＣＥＥによって格納される。（前記オリジナルメソッドからのリターン時に自動的に行われるのではなく） CEE_RESPONDに対する呼出し時に前記サーバ側ＣＥＥが前記クライアント側ＣＥＥに応答することになるので、前記サーバ側ＣＥＥは異なる呼出し識別子によって各呼出しを追跡することになる。従って、前記オリジナルメソッド、該オリジナルメソッドから呼び出される非同期メソッド、および、応答関数（後述）は、前記呼出し識別子をも追跡しなければならない。ステップ８０７では、前記オリジナルメソッド内において、好ましくは、コンテキスト変数を使用して、前記オリジナルメソッドに送られた呼出し識別予を格納する。前記コンテキスト変数は、前記メソッドによって実行されるオペレーションの結果を含む出力パラメータを格納するためにも格納される。前記コンテキスト変数は、前記オリジナルメソッドから呼出された非同期メソッドに送られることになる。前記ＣＥＥが前記オリジナルメソッドをアップコールする毎に、新たなコンテキスト変数が作成される。ステップ８０９では、前記オリジナルメソッドは、非同期メソッドを呼出して他の関数を実行する。例えば、前記オリジナルメソッドは、ディスクファイルを開きまたは閉じることなどの非同期入力／出力を行う必要があるかもしれない。または、前記オリジナルメソッドは、ある関数を実行するために非同期オブジェクト呼出し自体を実行してよい。前記オリジナルメソッドが非同期メソッドを呼び出す場合、好ましくは、前記オリジナルメソッドは、該非同期メソッドに対して前記サーバアプリケーションにおける応答関数のアドレスを与える。さらに、前記非同期メソッドは、前記呼出し識別子を含むコンテキスト変数および前記オリジナルメソッドにおいて実行されたオペレーションの結果を受け取る。最終的に、前記コンテキスト変数は、前記応答を特定のオブジェクト呼出しに対応づけるために、前記応答関数によって使用されることになる。前記非同期メソッドは、指定された関数を実行する。完了すると、前記非同期メソッドはステップ８１１において応答関数を呼び出す。前記非同期メソッドは、前記呼出し識別子および出力パラメータ（ならびに有用と思われる他のコンテキスト）を含むコンテキストパラメータを、前記応答関数に与える。そして、該応答関数は、ステップ８１３において、前記サーバアプリケーションにおける非同期応答スタブ関数を呼び出す。上述のように、該非同期応答スタブ関数は、CEE_ RESPONDに対するダウンコールを含む。前記オリジナルメソッドが非同期メソッドを呼び出しておらないが、前記初期化ルーチンにおいて非同期メソッドとして指定されている場合、該オリジナルメソッドは、直接的に、前記非同期応答スタブ関数を呼び出すことができる。または、前記サーバアプリケーションにおける任意のメソッドがCEE_RESPONDを呼び出すことができる。該CEE_RESPONDはCプログラミング言語により次のように定義される。 CEE_RESPOND( const char ^*call_id， const void ^*const^*param_vector)；前記応答関数は、前記コンテキストから前記呼出し識別子を抽出することによって、該呼出し識別子を前記スタブ関数に送る。該スタブ関数は前記識別子をCEE_ RESPONDに送る。前記サーバ側ＣＥＥは、前記サーバコンピュータメモリにおける呼出し識別子を捜し出し、該呼出し識別子に基づいて適切な呼出しに応答する。この応答は、前記オブジェクト呼出しの出力パラメータおよび例外構造体を指示するポインタを含むアレイであるparam_vectorパラメータを含むものである。前記アレイの最初の構成要素は、前記例外構造体のアドレスである。前記オペレーションがvoid（空）タイプのものでない場合、次の構成要素は、前記オペレーションの結果を含む変数のアドレスを含む。その後の構成要素は、ＩＤＬにおいて定義された順序と同じ順序で、前記オペレーションの出力パラメータのアドレスを含む。ステップ８１５では、インターフェイス８４を介して前記クライアント側ＣＥＥに前記応答が送り返される。前記クライアント側ＣＥＥは、前記クライアントアプリケーションにおける適切なメソッドをアップコールし、前記呼出しからCE E_RESPONDに前記出力パラメータおよび例外構造体を与える。図９は、非同期式にオブジェクトを実行するＣ言語サーバアプリケーションにおけるサンプルコードを示すものである。この例は、前記TimインターフェイスのオブジェクトについてのTim_Nowオペレーションの非同期実行を含む。（データ型定義は省略されている）。前記処理系ライブラリがロードされた時、前記サーバ側ＣＥＥ８５が前記サーバアプリケーションの初期化ルーチンを呼び出す。ライン９０１から開始するルーチンは、ライン９０２においてサーバスタブ関数を呼び出すことによって、インターフェイスハンドルを得る。ライン９０３では、該インターフェイスハンドルを使用して実行ハンドルが作成され、該実行ハンドルは、前記サーバアプリケーションにおけるメソッドのためのアドレスを設定するためのサーバスタブに送られる。ライン９０４では、前記サーバメソッドのアドレスNowMethodは、前記T im_Nowオペレーションのために前記サーバ側ＣＥＥ８５によってアップコールされるべきメソッドとして指定される。さらに、前記アドレスを設定するためのサーバスタブを呼び出すことによって、サーバアプリケーションは、前記サーバＣＥＥに対して、（前記アップコールされたメソッドからの退出時に自動的に応答する代りに）前記クライアントに応答する前にCEE_RESPONDに対する呼出しが必要である旨通知する。さらに、前記サーバ側ＣＥＥ８５は、前記呼出しを識別する呼出し識別子を前記メソッドに送ることになる。 TIM_Nowの呼出しが前記サーバ側ＣＥＥに到達すると、前記ＣＥＥは前記サーバアプリケーションにおけるNowMethod（オリジナルメソッド）をアップコールする。ライン９０５では、NowMethodは、時間をリクエストされた時間帯に変換し、変数timeptrに格納する。ライン９０６−９０７では、前記メソッドは、その結果を予め定義されたコンテキスト構造体に格納する。ライン９０８では、このコンテキスト構造体を使用して、ライン９２０で前記メソッドに送られた前記呼出し識別子を格納する。ステップ９０９では、前記オリジナルメソッド（NowMethod）が非同期メソッドを呼び出す。この例において、前記非同期メソッドは、ＣＥＥタイマ関数に対する単純なダウンコールである。前記ＣＥＥタイマメソッドは、前記コンテキスト構造体、および、前記サーバアプリケーションにおける応答関数TimerExpired のアドレスを受け取る。１秒後に前記タイマが“ポップ”した時、該ＣＥＥは前記応答関数を呼び出すことになる。ライン９０９の呼出しの後、前記サーバ側の実行は、制御がCEE_TIMER_CREATEからリターンするのを待つことなく続けられる。前記タイマがポップすると、前記ＣＥＥは前記応答関数TimerExpiredを呼び出す。ライン９１０において、TimerExpiredは、サーバスタブ応答関数に対する１つの呼出しを含む。好ましくは、前記サーバスタブ応答関数はCEE_RESPONDを呼び出す。前記サーバスタブ応答関数に対する呼出しは、呼出し識別子および出力パラメータtimestrを抽出する。前記サーバ側ＣＥＥは、前記オリジナル呼出しが同期式または非同期式になされたのかに応じて、前記出力パラメータ（および、もし存在するならば、例外情報）を前記クラアント側ＣＥＥ７５に送り返す。Ｃ．メモリ割当てによる非同期実行前記サーバアプリケーションにおける同じメソッドに対して多数の呼出しが可能であるので、前記方法は、多数の呼出しのためのメモリを割り当てたり、割当てを解除したりするためのメソッドを有するのが好ましい。この発明の方法および装置の他の実施の形態において、オブジェクトの実行時におけるメモリの割当ておよび割当て解除（“不要部分の整理”）が提供される。図１０は、この発明のこのような他の実施の形態に係る方法を示すものである。ステップ１００１− １００５は図６のステップと同様なものである。すなわち、ステップ１００１において、前記オブジェクトは非同期式または同期式に呼び出される。次に、ステップ１００３において、前記クライアント側ＣＥＥからサーバ側ＣＥＥにリクエストが送られる。そして、ステップ１００５において、前記サーバ側ＣＥＥは、前記サーバアプリケーションにおける適切なメソッドをアップコールする。ステップ１００７において、前記サーバアプリケーションは前記呼出しのためのメモリを割り当てる。これは、ＣおよびＣ＋＋言語におけるMALLOCのような適切なメモリ割当て関数を呼び出すことによって実現される。前に割り当てられた資源の割当てを解除するためのメカニズムも提供されなければならない。好ましくは、メモリの割当ておよび割当て解除は、次のようにC言語で定義されたCEE_T MP_ALLOCATEをダウンコールすることによって実行される。 CEE_TMP_ALLOCATE( const char ^*call_id long len void ^**ptr 前記call_idパラメータは、前記ＣＥＥが前記呼出し時に前記メモリの割当てを自動的に解除できるよう、前記特定の呼出しを識別するものである。前記lenパラメータは、割り当てるバイト数を指示する。前記ＣＥＥは、前記ptrパラメータを使用して、割り当てられたメモリのアドレスを戻す。次に、ステップ１００９において、前記メソッドが実行され、その結果および call_idがコンテキスト変数に格納される。その後、前記メソッドは、ステップ１０１１において、非同期メソッドを呼出す（すなわちオブジェクト呼出し）。ステップ１０１３では、前記非同期オペレーションは、その関数を実行し、応答関数を呼び出す。こうして、ステップ１０１５において、前記応答関数がサーバスタブ応答関数を呼び出す。ステップ１０１７では、前記オブジェクト呼出しの成功または失敗を示す例外情報と共に、前記オペレーションの出力パラメータがコーラ(Caller)に送り返される。 VI．プロキシー作成および削除次に、図１１および図１２を参照して、この発明の方法を説明する。ここでは、この発明の方法を、クライアントコンピュータのカプセル内で実行されるクライアントアプリケーション、および、サーバコンピュータのカプセル内で実行されるサーバアプリケーションについて説明する。図１１は、オブジェクトを呼び出すためにプロキシーハンドルを利用するためのステップを示すフローチャートである。最初のステップ１１０１において、所望のオブジェクトのオブジェクト参照が得られ必要がある。該オブジェクト参照は、様々な方法で得られてよい。通常、クライアントアプリケーションは、これらがオブジェクト参照を有する他のオブジェクトについての構成データ、ディレクトリまたは呼出しから前記参照を受け取る。オブジェクト参照は、後にアクセスすべきファイルに格納可能な文字列名に変換されることができる。前記オブジェクト参照が得られと、オブジェクト呼出しを実行することができる。この発明の方法において、先ず前記オブジェクト参照に対する“プロキシーハンドル”を得ることによって前記オブジェクト呼出しが実行される。該プロキシーハンドルは、特定のオブジェクト参照のためのユニークな識別データ構造体（“プロキシーオブジェクト”）である。このプロキシー構造体は、オブジェクトについての情報および該オブジェクトに対する呼出しを含む。このプロキシーハンドルを使用して、指定されたオブジェクトに対する呼出しを行うことができる。前記プロキシーハンドルは、同じオブジェクトに対する多数の呼出しを容易にし、該同じオブジェクトに対する多数の呼出しにおいて発生するオーバヘッドを防止する。オブジェクトを実行可能にするプロキシーハンドルを作成することによって、該プロキシーハンドルを介して、代理されるオブジェクトに対する多数の呼出しを可能にしながら、初期化ルーチンを一通り実行することができる。さらに、前記プロキシーハンドルは、オブジェクトに対する非同期呼出しの使用を容易にする（後述）。好ましい実施の形態によると、ステップ１１０３において、前記クライアントアプリケーションにおいてクライアント側ＣＥＥ関数CEE_ PROXY_CREATEをダウンコールすることによってプロキシーハンドルが作成される。該関数はCプログラミング言語により次のように定義される。 CEE_PROXY_CREATE( const char ^*objref const char ^*intf_handle char ^*proxy_handle); 前記関数は、オブジェクト参照objrefおよびインターフェイスハンドルintf_han dleを受け取り、新たに作成されたプロキシーオブジェクトを指示するプロキシーハンドルを戻す。図３について上述したように、インターフェイスは各オブジェクトごとに作成されなければならない。インターフェイスは、類似したオブジェクトの集合に利用可能なオペレーションを定義するものである。前記インターフェイスは、ＩＤＬで定義され、コンパイルされ、クライアントアプリケーションにリンクされる。該クライアントアプリケーションは、その初期化ルーチンで CEE_INTERFACE_CREATEを呼び出し、前記インターフェイスを指定する。前記クライアント側ＣＥＥは、任意の数のオブジェクトまたはプロキシーを作成するために使用可能なインターフェイスハンドルを戻す。この発明の好ましい実施の形態において、前記プロキシーオブジェクトは次のようなフィールドを含む構造体によって表現される。 link; call_link; self; nor; state; call_active; destroy; lock_count; ^*intf; call_compl_rtn; call_compl_tag1; call_complt_tag2; call_compl_sts; operation_idx; ^*client_allocated_params; ^*senrver_allocated_params; ^*obj; operation_idx_table; max_response_size; ^*req_area; ^*rsp_area; ^*rsp_param_buf， ochan; 次に、前記プロキシーオブジェクトのデータ構造体における各構成要素について説明する。前記構成要素の各々のアドレスおよび値は、該プロキシー構造体によって示されるオブジェクトに対するする各呼出しごとに、前記クライアント側ＣＥＥによって修正される。該クライアント側ＣＥＥは、プロキシー構造体のリンクされたリストを維持する。各プロキシー構造体のリンクメンバは、このプロキシー構造体のリストにおける次のエントリを指示するポインタを含むものである。好ましい実施の形態において、オブジェクト呼出しは同期的なもの（クライアントアプリケーションが、オブジェクトについてのオペレーションが行われるようリクエストし、応答を待つもの）、あるいは、非同期的なもの（クライアントアプリケーションが、オブジェクトについてのオペレーションが行われるようリクエストし、他の作業を続けて行うもの）のいずれであってもよい。同一のカプセル内において非同期オブジェクト呼出しが送られると、各呼出しは、起動時に、各オブジェクトごとに存在するオブジェクト構造体に含まれるリンクリスト上に並べられる。前記call_linkパラメータは、前記呼出しリストへのリンクである。前記selfメンバは、この特定のプロキシー構造体のハンドルである。このハンドルは、CEE_PROXY_CREATEの間に前記クライアントに戻される。 CEE_PROXY_CREATEに送られたオブジェクト参照は、norメンバに格納される。前記stateパラメータは、前記プロキシー構造体が内部オブジェクト構造体、（クライアントポートを介した）外部オブジェクト、または存在しない（無効な）オブジェクト構造体を指示するポインタを含むか否かを示す。前記プロキシーが内部的なものである場合、前記オブジェクトのポインタは前記objパラメータに含まれる。前記オブジェクトが異なるカプセル内にある場合、前記ochanパラメータは、クライアントポートハンドルを指示するポインタ、または、前記オブジェクトと通信するために必要な他の情報を含む。前記call_activeメンバは真／偽の値を保持する。この特定のプロキシーハンドルについてのオブジェクト呼出しが未完了である場合、前記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_r tnは、前記完了ルーチンのアドレスを含むものである。同一のプロキシーオブジェクトに対して多数の呼出しが可能であるので、前記クライアントアプリケーションは、オブジェクト呼出し実行時に、前記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メンバは、前記リクエストのために使用されるエリア構造体を指示する。また、前記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パラメータが与えられる。前記メソッドが退出すると、ステップ１１１９において、前記コーラに応答がなされ、前記オブジェクト呼出しが完了する。最初の呼出しが完了すると、前記プロキシーハンドルを再使用して、同じオブジェクトに対して更なる呼出しを行うことができる。後の各呼出しは、前記オブジェクトを確認したり、他のスタートアップオペレーションを実行したりすることなく実行することができる。このようにして、前記プロキシー作成ステップは前記クライアントアプリケーションにおける時間が重要な要素でない部分に置くことができ、オブジェクト呼出しは前記アプリケーションにおける時間が重要な部分において行うことができる。指定されたプロキシーハンドルについての最終的なオブジェクト呼出しに続いて、ステップ１２１1では、前記プロキシーハンドルが破棄される。これは、クライアントアプリケーションにおいて次のようにＣ言語で定義されるCEE_PROXY_ DESTROYを呼び出すことによって実現される。 CEE_PROXY_DESTROY( const char ^*proxy_handle); 前記プロキシーハンドルは前記関数に送られる。前記クライアント側ＣＥＥでは、ステップ１１２８において、このプロキシーハンドルを破棄し、該プロキシーハンドルについて割当てられていたすべての資源を解放する。代案として、オブジェクト呼出しがキャンセルされ、該呼出しが未完了のまま該呼出しに関連するすべての資源の割当てが解除されてよい。 VII．プロキシー作成およびメモリ割当て図１２は、この発明に係るオブジェクト呼出しメソッドの他の実施の形態を示すものである。この実施の形態において、オブジェクトの呼出し中のみならずオブジェクトの実行中にメモリが割り当てられる。ステップ１２０１−１２１１は上記と同様である。従って、ステップ１２０１では、オブジェクト参照が得られる。次に、前記プロキシーハンドルを戻すCEE_ PROXY_CREATEをダウンコールすることによって、プロキシーハンドルが得られる。そして、ステップ１２１１において、参照されたオブジェクトのプロキシーハンドルが与えられたCEE_OBJECT_CALLを使用して、前記オブジェクト呼出しが行われる。ステップ１２１３において、前記サーバ側ＣＥＥは、前記サーバアプリケーションにおける適切なメソッドルーチンをアップコールする。ステップ１２１６では、前記メソッドルーチンは、その呼出し時に、サーバ側ＣＥＥ関数をダウンコールし、メモリを割当てる。その関数CEE_TMP_ALLOCATEは、次のようにC言語で定義される。 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パラメータが与えられる。前記ＣＥＥは、前記パラメータによって指示されたアドレスを解放する。 VIII．ピクルドＩＤＬフォーマットデータ構造体の作成ピクルド（pickled）ＩＤＬフォーマット（“ＰＩＦ”）データ構造体は、クライアントメモリ２３およびサーバメモリ１７にロードされたＩＤＬコンパイラおよびコードジェネレータと共に使用されるよう設計されている。該データ構造体は、メモリ２３またはメモリ１７に格納されたＩＤＬソースファイルに基づいている。該ソースファイルも、ディスクのようなコンピュータによって読取り可能な媒体に格納されることができる。このデータ構造体は、ＩＤＬソースファイルを示す解析ツリーを含んでいる。該データ構造体は、メモリ２３またはメモリ１７あるいはディスクのようなコンピュータによって読取り可能な媒体に格納可能である。前記ソースファイルを示す前記データ構造体は、ピクルドＩＤＬフォーマット（“ＰＩＦ”）と呼ばれている。該ＰＩＦファイルは、前記ソースファイルに定義されたインターフェイスを使用するクライアントおよびサーバにより実行時にアクセス可能である。該ＰＩＦファイルに含まれる解析ツリーは、ポインタの代りにアレイインデックスを使用するアレイである。このアレイインデックスの使用により、その結果としての解析ツリーは言語とは独立したものとすることができる。前記アレイの最初の構成要素は使用されない。前記アレイの２番目の構成要素（インデックス１）は、前記解析ツリーの残りの部分へのエントリポイントとして機能するルート部である。図１３にはデータ構造体tu１３０１が示されており、これは次のようにＩＤＬによって定義される。 strunct tu_def{ sequence<entry_def> entry; sequence<string> source; } 前記データ構造体１３０１は、その各々がentry_defタイプ（後で定義）である解析ツリーノード１３０５のシーケンス（可変サイズアレイ）およびソースファイルライン１３０７のシーケンスを含む。前記ソースファイルライン１３０７のシーケンスは、前記ＩＤＬソースファイルからの実際のソースコードラインを含む文字列シーケンスである。各解析ツリーノード（または“エントリ”）１３０５は、該ノードの名前およびその特性を含む固定部、ならびに、前記ノードのタイプによって決まる可変部で構成される。前記解析ツリーノードは図１４に示されており、これは次のようにＩＤＬによって定義される。 struct entry_def{ unsigned long entry_index; string name; string jile_name; unsigned long line_nr; boolean in_main_file; union u_tag switch(entry_type_def){ case entry_argument:argument_def argument_entry; case entry_array:array_def array_entry; case entry_attr:attr_def attr_entry; case entry_const:const_def const_entry; case entry_enum:enum_def enum_entry; case entry_enum val:enum_val_def enum_val_entry; case entry_except:except_def except_def_entry; case entry_field:field_defneld_def entry; case entry_interface:interface_def interface_entry; case entry_interface_fwd:interface_fwd_def interface _fwd_entry; case entry_module:module_def module_entry; case entry_op:op_def op_entry; case entry_pre_defined:pre_defined_def pre_defined_e ntry; case entry_sequencec:sequence_def sequence_entry; case entry_string:string_def string_entry; case entry_struct:struct_def struct_entry; case entry_typedef:typedef_def typedef_entry; case entry_union:union_def union_entry; case entry_union_branch:union_branch_def union_branc h_entry; }u; }; 前記解析ツリーノードの固定部はentry_index１４０５を含み、これは前記解析ツリーにおけるこの特定のエントリのインデックスである符号なしlongである。前記エントリの非修飾名は、nameフィールド１４０７に含まれる。オリジナルのＩＤＬソースファイルの名前は、file_nameフィールド１４１１に含まれる。l ine_nrフィールド１４１３は、この解析ツリーノードを作成させる前記ＩＤＬソースファイルにおけるライン番号を含む。ブールin_main_file１４１５は、コマンドライン上に指定されたＩＤＬソースファイルにおいてエントリがなされたか否か、または、前記エントリが“include”ファイルの一部か否かを示す。このファイルに続いて、前記解析ツリーは、可変部、すなわち、識別子entry_type_d efを有する共用体１４１７を含む。前記共用体識別子entry_type_defは、ノードのタイプおよびentry_def内のどの変数がアクティブなのかを指示する。entry_type_ defは次のように定義される列挙である。 enum entry_type_def{ entry_unused, entry_module, entry_interface, entry_interface_Fwd, entry_const, entry_except, entry_attr, entry_op, entry_argument, entry_union, entry_union_branch, entry_struct, entry_field, entry_enum, entry_enum_val, eniry_string, entry_array, entry_sequence, cntry_typedef, entry_pre_defined }; entry_type_defは、各種の解析ツリーエントリのリストを含む。各解析ツリーエントリは、entry_defに含まれるswitch文に使用される一定の定数を示す。各エントリごとに、共用体u_tagは異なるタイプの構造体を含むことになる。列挙された最初の値entry_unusedは、ゼロの値に対応し、前記共用体のタイプを決定するのに使用されない。前記解析ツリーエントリが（値entry_moduleによって指示された）モジュールである場合、前記解析ツリーの可変部は、モジュール定義シーケンスを含むデータ構造体である。各モジュール定義は、前記解析ツリーにおけるインデックスとして機能する符号なしlongである。前記解析ツリーエントリが値entry_inter faceによって指示されたインターフェイスである場合、前記解析ツリーの可変部は、ローカル定義シーケンス、および、このインターフェイスが継承する基本インターフェイスのシーケンスを含むデータ構造体である。前記解析ツリーエントリがインターフェイスの前向き宣言（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

【特許請求の範囲】１．クラアントアプリケーションからサーバアプリケーションにリクエストされるオブジェクトについてのオペレーションを非同期式に実行するための方法であって、前記クラアントアプリケーションにおいて前記オペレーションに対するオブジェクト参照を得るステップと、前記クラアントアプリケーションにおいて、前記オブジェクト参照、前記オペレーションの入力パラメータ、および、前記クラアントアプリケーションにおける完了ルーチンのクラアントコンピュータメモリアドレスが与えられたスタブ関数により前記オペレーションをリクエストするステップと、前記完了ルーチンのメモリアドレスを格納するステップと、前記クラアントアプリケーションおよびサーバアプリケーションによりアクセス可能な実行環境を介して、前記サーバアプリケーションにおけるメソッドに前記入力パラメータを送るステップと、前記サーバアプリケーションにおいて前記オブジェクトについてのオペレーションを実行するステップであって、その実行が前記クラアントアプリケーションに対する応答を含むものと、前記実行環境を介して前記クラアントアプリケーションに対する応答を送るステップと、前記クラアントアプリケーションにおける完了ルーチンを呼び出し、該完了ルーチンに前記応答を与えるステップとを具備する方法。２．前記オブジェクト参照が、前記クラアントアプリケーションによりアクセス可能な構成ファイルから得られる請求の範囲第１項に記載の方法。３．前記オブジェクト参照が、前記クラアントアプリケーションによりアクセス可能なディスクファイルから得られる請求の範囲第１項に記載の方法。４．前記オブジェクト参照が、前記クラアントアプリケーションによる前のオブジェクト呼出しから得られる請求の範囲第１項に記載の方法。５．前記オブジェクトについてのオペレーションを実行するステップが非同期式に行われる請求の範囲第１項に記載の方法。６．前記オブジェクトについてのオペレーションを非同期式に実行するステップが、前記サーバアプリケーションにおけるメソッド内から非同期関数を呼び出し、該非同期関数に、呼出し識別子およびサーバアプリケーションにおける応答関数を含むメモリアドレスを与えるステップと、前記非同期関数から前記応答関数を呼び出し、該応答関数に前記呼出し識別子を与えるステップと、前記識別子に基づいて前記オブジェクト呼出しに応答するステップとをさらに含む請求の範囲第５項に記載の方法。７．クラアントアプリケーションからサーバアプリケーションへのリクエストを介してオブジェクトについてのオペレーションを非同期式に実行するための方法であって、前記オブジェクトを示すオブジェクト参照を得るステップと、前記クラアントアプリケーションにおいてスタブ関数により前記オブジェクトを呼び出すステップであって、このスタブ関数は、前記オブジェクト参照、前記オペレーションの入力パラメータ、および、前記クラアントアプリケーションにおける完了ルーチンのクラアントコンピュータメモリアドレスが与えられることと、前記クラアントアプリケーションおよびサーバアプリケーションによりアクセス可能な実行環境を介して、前記サーバアプリケーションにおけるメソッドに前記入力パラメータおよびオブジェクト参照を送るステップと、前記サーバアプリケーションにおけるメソッド内から非同期関数を呼び出し、該非同期関数に対して、呼出し識別子およびサーバコンピュータの応答関数のメモリアドレスを与えるステップと、前記非同期関数から前記応答関数を呼び出し、該応答関数に前記呼出し識別子を与えるステップと、前記識別子に基づいて前記オブジェクト呼出しに応答するステップと前記実行環境を介して前記コーラに応答を送るステップと、前記完了ルーチンを呼び出し、該完了ルーチンに前記応答を与えるステップとを具備する方法。８．クラアントコンピュータアプリケーションからサーバコンピュータアプリケーションへのリクエストを介して、オブジェクトについてのオペレーションを非同期式に実行するための方法であって、前記オブジェクトを示すオブジェクト参照をステップと、前記オブジェクト参照を示すプロキシーハンドルを作成するステップと、前記クラアントアプリケーションにおいて、前記プロキシーハンドル、前記オペレーションの入力パラメータ、および、前記クラアントアプリケーションにおける完了ルーチンのクラアントコンピュータメモリアドレスが与えられたスタブ関数により前記オブジェクトを呼び出すステップと、前記プロキシーハンドルに基づき前記クラアントアプリケーションおよびサーバアプリケーションによりアクセス可能な実行環境を介して、前記サーバアプリケーションに前記入力パラメータを送るステップと、前記サーバアプリケーションにおいて前記オブジェクトについてのオペレーションを実行するステップであって、その実行が前記クラアントアプリケーションに対する応答を含むものと、前記実行環境を介して前記クライアントアプリケーションに前記応答を送るステップと、前記クラアントアプリケーションにおける完了ルーチンを呼び出し、該完了ルーチンに前記応答を与えるステップとを具備する方法。９．前記オブジェクト参照が、前記クラアントアプリケーションにおける初期化ルーチンから得られる請求の範囲第８項に記載の方法。１０．前記オブジェクト参照がディスクファイルから得られる請求の範囲第８項に記載の方法。１１．前記オブジェクト参照が前のオブジェクト呼出しから得られる請求の範囲第８項に記載の方法。１２．前記オブジェクトについてのオペレーションを実行するステップが非同期式に行われる請求の範囲第８項に記載の方法。１３．前記オブジェクトについてのオペレーションを非同期式に実行するステップが、前記メソッド内から非同期関数を呼び出し、該非同期関数に呼出し識別子および応答関数アドレスを与えるステップと、前記非同期関数から前記応答関数を呼び出し、該応答関数に前記呼出し識別子を与えるステップと、前記識別子に基づいて前記オブジェクト呼出しに応答するステップとをさらに含む請求の範囲第１２項に記載の方法。１４．オブジェクトについてのオペレーションを実行するための方法であって、前記オペレーションを実行するためのメソッド関数を呼び出し、前記関数に対して、呼び出される前記オブジェクトを識別するための識別子を与えるステップと、前記メソッド関数内から非同期関数を呼び出し、前記非同期関数に前記識別子を与えるステップと、前記識別子に基づいて前記オブジェクト呼出しに応答するステップとを具備する方法。１５．前記サーバコンピュータメモリの一部を前記オブジェクト呼出しに割り当てるステップと、前記オブジェクト呼出しに応答した後、前記サーバコンピュータメモリの一部の割当てを解除するステップとを具備した請求の範囲第１４項に記載の方法。１６．クラアントアプリケーションからサーバアプリケーションへのリクエストを介してオブジェクトについてのオペレーションを実行するためにコンピュータにより読み取り可能なコード手段を有するコンピュータで使用可能な媒体と、前記オブジェクトを示すオブジェクト参照を得るソフトウエア手段と、前記クラアントアプリケーションにおいて、前記オブジェクト参照、前記オペレーションの入力パラメータ、および、前記クラアントアプリケーションにおける完了ルーチンのクラアントコンピュータメモリアドレスが与えられたスタブ関数により前記オブジェクトを呼び出すソフトウエア手段と、前記クラアントアプリケーションおよびサーバアプリケーションによりアクセス可能な実行環境に、前記オブジェクト参照、入力パラメータおよび完了ルーチンのアドレスを送るソフトウエア手段と、前記オブジェクト参照に基づいて前記実行環境を介して、前記サーバアプリケーションにおけるメソッドに前記入力パラメータを送るソフトウエア手段と、前記サーバアプリケーションにおいて前記オブジェクトについてのオペレーションを実行するためのソフトウエア手段であって、その実行が前記クライアントアプリケーションに対する応答を含むものと、前記実行環境を介して前記クライアントアプリケーションに応答を送るソフトウエア手段と、前記クライアントアプリケーションにおける完了ルーチンを呼び出し、該完了ルーチンに前記応答を与えるソフトウエア手段とを具備するコンピュータプログラム製品。１７．前記第１のコンピュータおよび第２のコンピュータの一方に前記オブジェクトについてのオペレーションを実行させるソフトウエア手段が、前記サーバアプリケーションにおけるメソッド内から非同期関数を呼び出し、前記非同期関数に呼出し識別子および応答関数を与えるソフトウエア手段と、前記非同期関数から前記応答関数を呼び出し、前記応答関数に前記呼出し識別子を送るソフトウエア手段と、前記識別子に基づいて前記オブジェクト呼出しに応答するソフトウエア手段とを含む請求の範囲第１７項に記載のコンピュータプログラム製品。