JPH1063506A - タイプコードで解釈されコンパイル（編集）されたマーシャリングを可能にするトランスポートから独立した呼出しとサーバントインターフェイス - Google Patents

Abstract

(57)【要約】 【課題】分散クライアント・サーバーに基づくオブジェ
クト指向オペレーティングシステム内でサーバント呼び
出しを促進するため、データ構造メソッド、および装置
を開示する。 【解決手段】開発の一局面において、タイプコードイン
ジケータと、マーシャリング機能識別子と、アンマーシ
ャリング機能識別子とを含むデスクリプタデータ構造を
用いて、異なるオブジェクト間で、アプリケーションコ
ードが共有できるようになっていて、よって、オペレー
ティングシステム内の共通化されたコードの量を増やす
ことにより、サーバント呼び出しが促進される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は分散コンピューティ
ング・システム分野、クライアント・サーバー・コンピ
ューティング分野、およびオブジェクト指向プログラミ
ング分野に関する。更に具体的には本発明はサーバント
呼出しを容易にするデータ構造、メソッド、および装置
に関する。

【０００２】

【従来の技術】別々のコンピュータ上にあるオブジェク
トがネットワークによって接続されているコンピューテ
ィング環境は普通、クライアント・サーバー・コンピュ
ーティング環境と称する。いくつかのコンピュータは他
のコンピュータに対するサービスまたは機能性のプロバ
イダー（提供者）として作用する。その他のコンピュー
タはサービスまたは機能性のコンシューマー（消費者）
として作用する。サービスまたは機能性のプロバイダー
は「サーバー」として知られ、また、サービスまたは機
能性のコンシューマーは「クライアント」と呼ばれてい
る。このクライアント・サーバー・モデルはまた、同一
コンピュータ上で走っている別々のプログラムが何らか
の保護されたメカニズムを介して相互に通信を行い、両
者がそれぞれサービスまたは機能性のプロバイダーとコ
ンシューマーとして作用する場合として一般化すること
ができる。

【０００３】

【発明が解決しようとする課題】そのような分散システ
ムを提供するための試みが、サーバーオブジェクトのリ
クエストを行うクライアント・オブジェクトへのインタ
ーフェイスをサーバー・オブジェクトが提供する、クラ
イアント・サーバー・モデルに基づくオブジェクト指向
メソッド論を用いてなされてきた。そのような分散シス
テムにおいては普通、サーバーはデータおよび関連する
メソッドからなるオブジェクトである。クライアントオ
ブジェクトはサーバーオブジェクトへのコールを行って
サーバントオブジェクトの機能性へのアクセスを行う
が、このコールは、分散システムによって仲介される。
サーバーオブジェクトは、一つのコールを受け取ると適
当なメソッドを実行し、結果をクライアントオブジェク
トへ送り返す。クライアントオブジェクトとサーバーオ
ブジェクトは、オブジェクト・リクエスト・ブローカー
（ＯＲＢ）を介して通信を行うが、このＯＲＢは種々の
分散オブジェクトを探し当て、オブジェクト相互間の通
話を行うのに用いられる。分散オブジェクトはネットワ
ーク内の任意の場所に、例えばクライアントのアドレス
・スペース内、クライアントマシーン上の複数のアドレ
ス・スペース内、およびネットワーク全体の複数のマシ
ーン内に、存在することができる。

【０００４】ソフトウェア業界は、分散オブジェクト技
術の必要性に応じてオブジェクト・マネージメント・グ
ループ（ＯＭＧ）を作成した。ＯＭＧの目標は、オブジ
ェクト・リクエスト・ブローカー（ＯＲＢ）、オブジェ
クト・サービス、コモン・ファシリティ、およびアプリ
ケーション・オブジェクトの四つの主要コンポーネント
を持つオブジェクト・マネージメント・アーキテクチャ
（ＯＭＡ）を定義することである。オブジェクト・リク
エスト・ブローカーは、基本的なオブジェクト・コミュ
ニケーションとマネージメント・サービスを提供するこ
とによって分散オブジェクトシステムの基盤を形成す
る。オブジェクト・リクエスト・ブローカーの標準は、
ＯＭＧ、改訂２．０、１９９５年７月付け、コモン・オ
ブジェクト・リクエスト・ブローカー・アーキテクチャ
（ＣＯＲＢＡ）仕様に含まれている。

【０００５】代表的なクライアント・サーバー・システ
ムにおいては、性能オーバーヘッドが高価になる可能性
がある。すなわち、システム内のプロセスのスピードと
品質が、分散オブジェクト間の情報伝達に係わるアプリ
ケーション・コードとメソッドの非効率的使用によっ
て、妥協させられる可能性がある。例えば、クライアン
ト・サーバー・システムが情報を要求するたびにバッフ
ァーまたはコードの部分から情報を繰り返し抽出するこ
とに係わる性能オーバーヘッドは、高い。更に、当業者
には理解できるように、クライアント・サーバー・シス
テムは普通、編集された呼出し(compiled invocation)
と編集されない呼出し(non-compiled invocation)に関
して別々のインターフェイスを用いる。別々のインター
フェイスを用いることは非効率的である。従って、分散
オブジェクト間の情報交換に係わる性能オーバーヘッド
を低減するメソッド、データ構造、および／または装置
の提供が望まれる。更に、編集された呼出しと編集され
ない呼出しの間での共通ベースコードの共有を可能にす
るメカニズムを提供すれば、クライアント・サーバー・
システムの性能が改善されるであろう。

【０００６】

【課題を解決するための手段】前記目的およびその他の
目的を達成するため、および本発明の目的に従って、分
散クライアント・サーバーに基づくオブジェクト指向オ
ペレーティング・システムにおけるサーバント呼出しを
容易にするためのデータ構造、メソッドおよび装置を開
示する。本発明の一局面において、タイプコードインジ
ケータ、マーシャル機能識別子、およびアンマーシャル
機能識別子を含むデスクリプタ・データ構造を用いて、
アプリケーションコードのモジュールを別々のオブジェ
クト間で共有できるようにし、それによってオペレーシ
ティングシステム内における共通化されたコードの量を
増やし、サーバント呼出しを容易にする。

【０００７】本発明の種々の実施例において、デスクリ
プタ・データ構造は、下記フィールドの一つまたはそれ
以上を追加的に含むパラメータ・デスクリプタ・データ
構造である：デスクリプタ・データ構造に関連するエン
ティティの処理方向を識別する方向インジケータ：当該
デスクリプタ・データ構造に関連する当該エンティティ
の名称を与えるための名称インジケータ；当該デスクリ
プタ・データ構造に関連する当該エンティティを受け入
れるプロセスによって割当てられねばならないメモリー
の量を示すサイズインジケータ。本発明の他の実施例に
おいて、デスクリプタ・データ構造は、例外を記述する
例外デスクリプタ・データ構造という形をとる。

【０００８】本発明のもう一つ局面において、例外デス
クリプタ・データ構造は、タイプコード・インジケータ
と、投入(throw)機能がコールされた場合、例外の性質
を指定するように編成された投入機能を識別するように
編成された投入機能インジケータとを含む。実施例の中
には、例外デスクリプタ・データ構造内に、例外デスク
リプタ・データ構造に関連する例外を、一義的に識別す
るよう編成されたレポジトリ・デスクリプタも含む。

【０００９】本発明およびその利点は、添付図面に関連
した説明によって更によく理解できる。

【００１０】

【発明の実施の形態】本発明は分散オブジェクトシステ
ムを対象とし、添付の図面に示したいくつかの好ましい
実施例を参照して説明する。本発明は、ＣＯＲＢＡによ
る、或いは他の任意の適当な仕様による適当な分散オブ
ジェクトシステムを含む任意の分散オブジェクトシステ
ムに関連して実施することができる。しかし説明の便宜
上、本発明の実施例は、引用によって本出願に組み入れ
る１９９５年７月付け改訂２．０、オブジェクト・マネ
ージメント・グループ（ＯＲＧ）からのＣＯＲＢＡ仕様
のもとで実行されるオブジェクト・リクエスト・ブロー
カー（ＯＲＢ）に主として関連して説明する。図１は、
本発明の一実施例の実行に適した代表的な分散オブジェ
クトシステムの全体的構造(アーキテクチャ:architectu
re)をダイヤグラム的に示す。図２は、３レベル発送メ
カニズムを含むようなアーキテクチャ内においてクライ
アントからサーバントオブジェクトへのリクエストが追
従するいくつかの可能なフローパスをダイヤグラム的に
示す。図３は、クライアントがサーバントオブジェクト
を参照するために用いるオブジェクト・レファレンス・
データ構造を示す。

【００１１】分散オブジェクトシステム１０は普通、図
１に記号的に示したように、オブジェクトリクエストブ
ローカー（ＯＲＢ）１１を含む。ＯＲＢ（１１）は図２
を参照して以下に説明するように、クライアントからサ
ーバント（ターゲットオブジェクト）へコールを発送
し、クライアントへ応答（レスポンス）を返すのに必要
なすべてのロケーション・メカニズムとトランスポート
・メカニズムと設備を提供する。クライアントとサーバ
ントは、同一プロセス内、同一マシーン内の別々のプロ
セス内、あるいは全く別々のマシーン上に存在すること
ができる。ここでの検討に関しては、クライアント２０
は、分散オブジェクト上において一つのオペレーション
を呼び出す任意のコードであればよく、従って、分散オ
ブジェクトまたは一つのプロセスの形を取っても取らな
くてもよい。分散オブジェクトは様々な表現(represent
ation)を持ち得る。例えば、一つのオブジェクト１４
は、アプリケーション開発者によって提供されるＣ＋＋
オブジェクトでもよい。あるいは、一つのオブジェクト
に関する実行は、視覚的アプリケーションビルダー１５
内で作成してもよい。この視覚的アプリケーションビル
ダーは、開発者（作成者）があるオブジェクトに関して
新しい実行を作成するために、一つのカタログから既存
のオブジェクトタイプを視覚的に選んで、一つのオブジ
ェクトが提供するサービスをもう一つのオブジェクトが
必要とするサービス（属性(attributes)、引数、結果、
等）へグラフィック的に接続することを可能にする。

【００１２】オブジェクト開発設備１６は、分散オブジ
ェクトの作成とインストール（配置）を簡単にする。こ
れは、デベロッパーオブジェクトを「ラップする(包む:
rap)」すなわち分散オブジェクトコード内においてカプ
セル化する。従って、オブジェクト開発設備１６は、開
発オブジェクトをＯＲＢオブジェクト実行１４へ変換す
るのに用いることができる。この例においては、ＯＲＢ
オブジェクト実行１４は図のその位置に示したように、
サーバーとして表されている。デベロッパー（開発者、
作成者）は、一つのインターフェイス定義言語を用い
て、一つのＯＲＢオブジェクトに関する一つのインター
フェイスを定義し、オブジェクトの挙動を実行するデベ
ロッパー・オブジェクト実行を提供し、次にオブジェク
ト開発設備１６を用いてＯＲＢオブジェクト実行１４を
作成する。ランタイム(run time)においては、このＯＲ
Ｂオブジェクト実行１４を利用するＯＲＢオブジェクト
の事例（サーバントオブジェクト）を作成する。オブジ
ェクト開発設備は、ある時点においてクライアントの役
割をするオブジェクトの作成にも用いられることを理解
すべきである。

【００１３】クライアント２０は、スタブ２１、サブコ
ントラクト・レヤー３６、場合によってはフィルター４
０、およびトランスポート・レヤー３８を介して通信を
行う。スタブ２１は、サロゲート２２、メソッドテーブ
ル２４およびスタブ機能２５を含む。クライアント２０
は当初、クライアントにサーバントオブジェクトと見な
されるサロゲート２２と通信を行う。あるいは、クライ
アント２０は、サロゲート２２、メソッドテーブル２４
およびスタブ機能２５を介してでなく、ダイナミック呼
び出しインターフェイス（ＤＩＩ）２６を介して直接サ
ーバントオブジェクトと通信することもできる。クライ
アントがダイナミックリクエストを作成できるようにす
るため、ダイナミック呼び出しインターフェイス２６が
用いられる。クライアントが上記レヤーを用いてコール
を行うことができる一つの手順を、図２を参照して以下
に更に詳しく説明する。

【００１４】サブコントラクトレヤー３６は、上記に引
用した１９９５年１１月０７日出願の米国特許出願番号
08/554,794 に詳細に説明されているような特定のサブ
コントラクトによって指名される種々のサービス（また
は特徴またはオブジェクトメカニズム）を実行するため
にサブコントラクトを用いるため、一つのオブジェクト
が必要とする機能性を提供する。サブコントラクトは、
個々のオブジェクトが利用することができる分散オブジ
ェクトシステムが提供するサービスの品質を識別する。
例えば、サブコントラクトは、特定のオブジェクトのた
めに用いられるべき保安(security)の特徴を識別する。
フィルター４０は、もし使用中であれば、圧縮(compres
sion)、解読(encryption)、追跡(tracing)、またはデバ
ッギング(debuging)など、オブジェクトとの通信のやり
とりに適用すべき様々なタスクを実行することができ
る。

【００１５】トランスポートレヤー３８は、情報をマー
シャルし、アンマーシャルし、および普通はクライアン
トと同じプロセスを共有しないサーバントとの間で情報
を物理的にやりとりするように作用する。

【００１６】標準実行スイート２８（またはオブジェク
トアダプター）は、同一のやり方で、例えばオブジェク
ト・キー・マネージメントのように、ＯＲＢオブジェク
ト１４と対話するサブコントラクトの一セットを表す。
サブコントラクトは複数実行スイート(multiple implem
entation suites)に属することに注目すべきである。ま
た、実行スイートは種々のサブコントラクトを利用する
ことができる。スタティックスケルトン３２またはダイ
ナミックスケルトン３０のいずれかの形をとることので
きる一つのスケルトンを用いて、（図１ｂを参照して以
下更に詳しく説明するように）リクエストをサーバント
オブジェクト７８が要求するフォーマットに変換(trans
form)することができる。このように、スケルトン３０
と３２は適当なサーバントオブジェクト７８をコールす
る。スタティックスケルトン３２は、特定のインターフ
ェイスに関するオブジェクト実行１４のコールに用いら
れ、一方ダイナミックスケルトン３０は特定のインター
フェイスに関するオブジェクトが利用できないとき一般
的に用いられる。

【００１７】ＯＲＢデーモン４６は、オブジェクトサー
バーがクライアントによって呼び出されたとき確実にア
クティブになるようにする役割をする。オブジェクトサ
ーバーをスタートさせる技法は、米国特許出願番号 08/
408,645 に開示されている。セキュア・プロトコル(Sec
ure Protocol)４２は、インターネット・インターＯＲ
Ｂプロトコルを確保し、情報をトランスポートレヤー３
８を介して安全なメソッドで転送する助けをするセキュ
ア・インターオペラビリティ・プロトコルである。これ
は、完全性保護(integrity protection)、機密性(confi
dentiality)、等を意味する。インターネット・インタ
ーＯＲＢプロトコルは、普通、別々のマシーン上のプロ
セス間で通信を行うプロトコルである。しかし、インタ
ーネット・インターＯＲＢプロトコルが同一マシーン上
のプロセス間で通信を行う場合もある。セキュリティ・
サーバー５４は、別々のコンピュータ上のプロセス間で
用いられるサービスを確保するセキュリティ管理サーバ
ーである。

【００１８】タイプコード／エニー・モジュール４４
は、「タイプコード」オブジェクトと「エニー」オブジ
ェクトを実行する。タイプコードはインターフェイス定
義言語（ＩＤＬ:Interface Definition Language）デー
タタイプを記述し、クライアントとサーバーの間のタイ
プ記述の転送を可能にする。ＩＤＬデータタイプの一事
例は、一つの「エニー」オブジェクトによってカプセル
化することができる。一つのエニーオブジェクトはカプ
セル化したデータのタイプコードを参照し、データの一
般的エンコーディング（解読）である。

【００１９】実行レポジトリ５０は、オブジェクトサー
バーに関する情報を保存する。具体的に、実行レポジト
リ５０はサーバープロセスのスタート（始動）に必要な
情報を保存する。例えば、実行レポジトリ５０はサーバ
ープログラムの場所、プログラムへの任意の引数、およ
びプログラムへ引き渡すべき任意の環境変数等のような
情報を保存する。

【００２０】単純持続(simple persistence)は、インタ
ーフェイス定義言語（ＩＤＬ:Interface Definition La
nguage）によって定義されるタイプと、ＩＤＬコンパイ
ラ経由でそのＩＤＬタイプを実行した出力を、追加コー
ドの一部とともに用いて、ＩＤＬによって定義されたタ
イプをディスクに対して読み書きできるようにする。ネ
ーミングサービス５２は、ＯＲＢオブジェクトの指名に
用いられる。クライアントは、名前によって必要なオブ
ジェクトを見いだすためネーミングサービスネームサー
バー５２を用いることができる。ネームサーバー５２は
オブジェクトレファレンスを返し、次にこれを用いてそ
のオブジェクトへリクエストを送ることができる。イン
ターフェイスレポジトリ４８（ＩＦＲ）は、分散オブジ
ェクトシステム内のすべてのオブジェクトに関するすべ
てのインターフェイスについて知っている。

【００２１】図２にダイアグラム的に示すように、クラ
イアントがメソッドテーブル（ｍテーブル）ディスパッ
チを用いて行うリクエストは、サーバントに至るまでに
前記アーキテクチャの様々なレヤーを通過する。リクエ
ストはクライアントによって開始され、任意の形をとる
ことができる。リクエストの形は、クライアントの作成
に用いるプログラミング言語の性質に大きく依存する。
例えば、クライアントがＣ＋＋言語で書かれた場合、リ
クエストはＣ＋＋メソッドコール６２の形をとることが
できる。このコールは、サロゲートの形をとる指定オブ
ジェクトレファレンスとされる。サロゲートは、オブジ
ェクトのインターフェイスに適合するメソッドを含む。

【００２２】当業者には理解できるように、一つの分散
オブジェクトシステム内の別々の場所で用いられるオブ
ジェクトレファレンスは、外観が著しく変化しているこ
とがある。上記実施例においては、クライアント側のオ
ブジェクトレファレンスは二重ポインターである（本明
細書では「ファット(太った)・ポインター」と呼ぶ）。
ファットポインターは二つの別々の(distinct)ポインタ
ーを含む。第１のポインター、すなわちロケーション・
インジケータは、参照されるオブジェクトに関するクラ
イアント・レプレゼンテーション（「クライアント・レ
プ」）を指し示す。第２のポインター、すなわちロケー
ション・インジケータは、参照されるオブジェクトに関
するメソッドテーブルディスパッチ２４のメソッドテー
ブルを指し示す。「ポインター」という用語は、本明細
書において用いる場合、コンピュータまたはネットワー
ク・メモリー内の場所のみならず広くロケーション・イ
ンジケータを識別するのに用いられることを理解すべき
である。クライアント・レプレゼンテーションは、呼び
出し(invocation)と、ＣＯＲＢＡによって定義される
「疑似」オブジェクトレファレンスオペレーションをサ
ポートするメソッドを持つオブジェクトである。これら
のオペレーションには、「複写(duplicate)」メソッ
ド、「リリース」メソッド、「狭い」メソッド、「ハッ
シュ（細断）」メソッド、および「同等である」メソッ
ドを含むが、これらに限らない。

【００２３】クライアントがコールを開始すると、コー
ルはメソッドテーブルディスパッチメカニズム２４を用
いて処理される。そのような技法は米国特許出願番号 0
8/307,929 に開示されている。メソッドテーブル・ディ
スパッチ・メカニズムは、スタブ機能２５へのロケーシ
ョンインジケータのリストを含むメソッドテーブルを用
い、その内の一つは呼び出されるべきメソッドに関連す
る。スタブ機能２５は一つの機能または手順コールをク
ライアント手順の「ネイティブ」言語によって受け、次
にサブコントラクトレヤー３６またはネイティブコール
を用いて対応するサーバントオブジェクトを最終的にコ
ールする。ネイティブ言語は、例えばＣ＋＋のような任
意の適当な言語でよい。

【００２４】メソッドコールディスパッチ２４は、メソ
ッドコールを処理するため適当な一つのスタブ機能２５
を決定し、次にメソッドコールと適当なスタブ機能２５
のペアを作る。メソッドコールを行っているクライアン
トがサーバントオブジェクトと同じプロセス内にある場
合、ローカルスタブ機能がコールされる。ローカルスタ
ブ機能はメソッドコールを直接サーバントオブジェクト
７８へ送る。あるいは、サーバントオブジェクトが別の
プロセス内に、すなわちリモートプロセス内にある場
合、リモートスタブ機能がコールされる。リモートスタ
ブ機能はクライアントレプレゼンテーションを呼び出
し、この呼び出しがサーバントオブジェクト７８へ送ら
れる。

【００２５】サブコントラクトレヤー３６によって実行
されるサブコントラクト（複数）は、分散オブジェクト
システムにおいて重要な、オブジェクト呼び出しと引数
パッシングの基本的メカニズムのコントロールを提供す
るロジックモジュールである。サブコントラクトレヤー
３６によって実行される一つのサブコントラクトは、一
つのオブジェクトが用いるべきサービスの品質を決定す
る。一つのサブコントラクトは、普通はオブジェクトレ
ファレンスに埋め込まれている、サブコントラクト識別
子によって一義的に(uniquely)識別される。一つのサー
ビス品質は複数のサービス特性の一セットである。選択
可能な複数のサービス特性の中には、サービスアクティ
ベーション、保安(security)、取扱い(transactions)、
フィルター可能性(filterability)、およびクリーン・
シャットダウンに関する品質がある。サブコントラクト
は、特定のサービス品質が利用できるように構成され
る。予め定められたサービス品質によれば、個々のサー
ビス特性の処理に関わるオーバーヘッドが低減される。
現実的には、「合理的な」すなわち普通に用いられるサ
ービス特性の組合せのみがサポートされる。しかし、あ
る与えられた分散オブジェクトシステムの特定の要件を
充たすためにサブコントラクトを作成してもよい。

【００２６】サブコントラクトレヤー３６における適当
なサブコントラクトの識別は、当該サブコントラクトに
特有の必要機能の識別と見なされる。例えば、各サブコ
ントラクトに関してマーシャル機能またはアンマーシャ
ル機能が定義される。サブコントラクトマーシャル機能
は、それが別のアドレススペースまたはドメインへ伝達
され得るように、オブジェクトレファレンスをマーシャ
ルするため、スタブによって用いられる。オブジェクト
レファレンスは普通、トランスポートレヤー３８におい
て、トランスポートメカニズムによって処理される。

【００２７】トランスポートレヤー３８の一部分である
Ｔ１，Ｔ２などのトランスポートメカニズムは、サーバ
ントオブジェクトとの間で情報をマーシャルして物理的
にするのに用いられる。情報すなわちオブジェクトレフ
ァレンスまたはリクエストは、ある与えられたドメイン
に適したプロトコルへ変換される。例えば、プロトコル
はイーサーネットプロトコルとジェネラル・インターＯ
ＲＢ・プロトコル（ＧＩＯＰ）を含むが、これらに限ら
ない。いくつかのまれな場合において、プロトコルはサ
ーバー上で実行されるべき命令を伝達するため電子メー
ルの使用さえ必要とするかも知れない。情報のマーシャ
ル後、トランスポートメカニズムは次に、すべて分散オ
ブジェクトシステムのクライアント側が用いるハードウ
ェア７０の一部であるオペレーティングシステム、デバ
イスドライバーの任意の組合せ、すなわちネットワーク
を介して、情報を送る。

【００２８】トランスポートメカニズムは、ある与えら
れたドメインに適したプロトコルへの情報の変換を必要
とするが、いくつかのトランスポートメカニズムは、別
々のドメインに関する情報のエンコーディングを必要と
しない。情報源以外のドメインに適したプロトコルへの
情報変換を必要としないトランスポートメカニズムを
「ドア」(door)と称する。ドアは基本的には、同一ホス
ト上の二つの異なるプロセス間のゲートウェイ（出入り
口）である。ドアを用いると、トランスポートレヤー３
８において情報を規範的実行(canonical implementatio
n)へ変換する必要がなくなる。その理由は、情報を一つ
の異なるマシンが用いるプロトコルへエンコードする必
要がないからであり、これは、情報が同一ホスト上に残
っており、従ってドメインの変更を必要としないという
事実に基づく。従って、情報は簡単に「平らに延ばさ
れ」、すなわち一つの流れへとマーシャルされ、これは
一つの異なるマシンによって用いられるようにエンコー
ドされず、ホスト上の二つのプロセス間でやり取りされ
る。

【００２９】情報がいったんクライアント側で用いられ
るハードウェア７０を介して転送（トランスポート）さ
れると、次に情報は分散オブジェクトシステムのサーバ
ー側のハードウェア７０へ転送される。情報がいったん
ハードウェア７０を介して回送されると、分散オブジェ
クトシステムのサーバー側は、トランスポートレヤー３
８の一部分であるエンドポイント上で情報を受け取るた
め、Ｔ１、Ｔ２のようなトランスポートメカニズムを呼
び出す。トランスポートレヤー３８によってエンドポイ
ントが作られていない場合、トランスポートレヤー３８
は、サブコントラクトレヤー３６がエンドポイントを作
るのに必要な機能性を提供する。例えば、専用エンドポ
イントは普通、サブコントラクトレヤー３６によって作
成される一方、ネットワーク・エンドポイントおよびＴ
ＣＰ／ＩＰエンドポイントを含むのが普通であるクラス
ター・エンドポイントは、普通、トランスポートレヤー
３８によって作成される。エンドポイントがサブコント
ラクトレヤー３６、あるいはトランスポートレヤー３８
のいずれによって作成されるかにかかわらず、エンドポ
イントは「リブ・イン(live in)」、すなわちトランス
ポートレヤー３８の一部分である。エンドポイントは本
質的に別のドメインから情報を受けるポート（出入り
口）である。トランスポートレヤー３８内のエンドポイ
ントは、別のドメインから送られてきた情報を受け取る
と、その情報をトランスポートレヤー３８からサブコン
トラクトレヤー３６へ発送する。次にサブコントラクト
レヤー３６、あるいは更に具体的には情報を受信するサ
ブコントラクトレヤー３６内のサブコントラクトは、そ
の情報をスケルトンとサーバントへ発送する。

【００３０】サブコントラクトレヤー３６は、それが受
け取った情報の少なくとも一部分をアンマーシャルする
ための機能性を提供する。すなわち、サブコントラクト
レヤー３６は、リクエストの少なくとも一部分をアンマ
ーシャルする。次に、リクエストはスケルトン３１へ発
送され、スケルトン３１はこのリクエストをサーバント
オブジェクト７８が必要とする、実行に特有のフォーマ
ットに変換する。このスケルトンは、前記スタティック
スケルトンまたはダイナミックスケルトンのいずれでも
よい。

【００３１】一般的に、リモートリクエストはクライア
ント側とサーバー側を介して上記のように回送される。
メソッドコール６２が受信されると、メソッドテーブル
２４を用いて適当なサブコントラクトを識別し、引き続
きトランスポートレヤー３８においてトランスポートメ
カニズムを選択し、これによってリクエストをマーシャ
ルし、それをもう一つのドメインへ送る準備をする。マ
ーシャルされたリクエストはハードウェア７０を介して
サーバー側へ送られ、トランスポートレヤー３８の一部
分であるエンドポイントがそれを受け取る。適当なエン
ドポイントがワイヤーを介して情報を受け取り、情報は
トランスポートレヤー３８からサブコントラクトレヤー
３６へ送られ、サブコントラクトレヤー３６はそれが受
け取った情報を少なくとも部分的にアンマーシャルす
る。サブコントラクトレヤーは次にリクエストをスケル
トン３１へ発送し、スケルトン３１はこのリクエスト
を、サーバントオブジェクト７８が必要とする特定のフ
ォーマットに変換する。このパス(path:経路)を矢印７
７で示す。このパスは、リモートリクエスト、ローカル
リクエストのいずれもが取ることができる。

【００３２】しかし、もしクライアントとサーバーが一
つのローカルプロセスにあれば、すなわちクライアント
とサーバーの両方が同一プロセス内にあれば、上記のよ
うに矢印７７で示したパスの使用は不必要に複雑にな
る。もしクライアントとサーバーが同一プロセス内にあ
ることが分かっていれば、サービスのためのリクエスト
の呼び出しパスすなわちフローパスを短かくすることが
できる。オブジェクトレファレンスが作成されたとき、
もしローカルプロセスが識別できれば、短縮フローパ
ス、すなわち矢印７５、７６で表したパスを選んで、同
一ホスト上のクライアントからサーバーへリクエストを
送ることができる。矢印７６で表したパスは、適当なサ
ブコントラクトを識別するのにサブコントラクトレヤー
３６を用いるので、このパスを取る可能性が大きい。し
かし、適当なサブコントラクトを明確に識別する必要が
ない場合、矢印７５で表したパスを取ることができる。

【００３３】ここで図３を用いて一つのオブジェクトレ
ファレンスの一実施例を説明する。当業者にはなじみな
ように、オブジェクトレファレンスは、ある与えられた
時刻にそれらが保持されているプロセス内の場所次第で
様々な形を取ることができる。しかし、背景として、ロ
ーオーバーヘッド実行スイートを利用するシステム内で
用いるための代表的オブジェクトレファレンスを図３に
示す。同図に示した実行においては、オブジェクトレフ
ァレンス１５０は、ホスト識別子１５２、ポート指定１
５４、およびオブジェクトキー１５６を含む。オブジェ
クトキー１５６は、サブコントラクト識別子１５８、サ
ーバー識別子１６０、実行識別子１６２、およびユーザ
ーキー１６４を含む。ホスト識別子１５２は一つのネッ
トワーク内の特定のコンピュータを示す一方、ポート指
定１５４は通信のために用いるべき選ばれるコンピュー
タのポートを識別する。オブジェクトキー１５６は、そ
のホストマシン上で所望のサーバントオブジェクトの場
所を見いだすのに用いる追加の識別情報を提供する。

【００３４】サーバー識別子１６０は、中にサーバント
オブジェクトが常駐する特定のプロセスまたはプログラ
ムを指名する。一方、ユーザーキー１６４は、サーバー
識別子１６０によって指名されたプログラム内における
サーバントを見いだすのに用いられる特定の番号または
ストリングである。サブコントラクト識別子１５８は、
特定のサブコントラクトのプロトコルとその関連サービ
スにサーバントを添付するのに用いられ、実行識別子１
６２は当該サーバントオブジェクトとともに用いられる
べきインターフェイスの実行を指名する。

【００３５】分散オブジェクト指向システム、すなわち
分散動作環境によって用いられるアプリケーションコー
ドの量を、システムの性能面で妥協せずに減らすこと
は、当該システムの全体的効率を向上させる。分散オブ
ジェクト指向システムにおいて用いられるアプリケーシ
ョンコードの量を減らすメソッドの一つは、可能な限り
妥協することである。換言すれば、可能な場合は常に、
同じコードを用いて種々のタスクを実行すれば、システ
ムの全体的効率を向上させつつアプリケーションコード
の総量を低減させることができるであろう。更に、コー
ドパス(code paths)の数が少ないということは、コード
のテストが容易であることと、あまり普通でない特徴の
中にバグが潜んでいる可能性が少ないことを意味する。
例えば、ダイナミック呼出しのような、あまり普通でな
い特徴は、より普通であるスタティック呼出しのときテ
ストされる。一つまたはそれ以上のマイナールーチンを
含むかも知れないダイナミック呼出し特徴の残りは、独
立的にテストされる。

【００３６】共通化コードを実行することのできる一つ
の分野はメソッドの呼出し分野である。クライアント・
サーバー・システムにおけるメソッドへのコールは普
通、メソッドの指定と、そのメソッドを呼び出すのに必
要な、そのメソッドが用いる種々のインターフェイスパ
ラメータとそのメソッドが設ける例外を含む情報を必要
とする。普通、各パラメータに関連して作成されるコー
ドは、パラメータを用いる各メソッドへ直接仕向けられ
る。複数のメソッドが同じパラメータ（複数）を用いる
ことができるので、あるパラメータに関連するコードが
「モジュール」すなわちデータ構造内に包含されていれ
ば、システムの効率は改善される。次にこのモジュール
のコードに、二つ以上のメソッドがアクセスすることが
でき、それによって、一つのシステム内のコードの量が
低減される。

【００３７】共通化コードを実行することのできるもう
一つの分野は、マーシャリングおよびアンマーシャリン
グ分野である。情報のパケットをマーシャルするには、
情報を「ワイヤー」すなわちネットワーク通信ラインを
介して転送するために準備する必要がある。情報のパケ
ットをアンマーシャルすることは、本質的にマーシャル
手順の逆であって、それによって非ネットワーク環境に
おいて意味をもつ情報のパケットを作り出すことであ
る。マーシャリングとアンマーシャリングにはそれぞれ
二つの一般的タイプがある。すなわち、編集されたマー
シャリングまたはアンマーシャリングと、編集されな
い、すなわちタイプコードによって解釈されるマーシャ
リングおよびアンマーシャリングである。編集された、
すなわちインターフェイス定義言語（ＩＤＬ）によって
作成され、かつ非編集のマーシャリングルーチンとアン
マーシャリングルーチンの間の相違を分離すると、ルー
チンの相違しない部分とともに用いるための共通コード
の作成が可能になる。すなわち、汎用(genric)マーシャ
ルルーチンと汎用アンマーシャルルーチンを作成するこ
とができる。汎用ルーチンを用いると、コードのテスト
が容易になり、それによって、あまり普通でない特徴の
中にバグが潜んでいる可能性が少なくなる。

【００３８】一般的に、上記のように、一つのオブジェ
クトを呼び出すためのコールには、呼び出すべきメソッ
ドの指定、呼び出すべきメソッドに係わるパラメータの
指定、および呼び出すべきメソッドに係わる例外の指定
が係わる。データ構造を用いてコードを共通化すること
ができる。更にデータ構造を用いて、例えばパラメータ
に関連する変更を、変更対象のパラメータを用いるメソ
ッドの呼出し全体に影響を及ぼすことなく、行うことが
できる。言い換えれば、データ構造を用いることによっ
て、あるオブジェクトを呼び出すためのコールに関連す
る一つの要素への変更を、例えばアプリケーションソフ
トウェアを大幅に変更せずに、行うことができる。オブ
ジェクトの呼出しに用いることのできるデータ構造に
は、メソッドデスクリプタデータ構造、呼出し記述デー
タ構造、パラメータデータ構造、および例外データ構造
があるが、これらに限らない。

【００３９】次に図４は、本発明に関して用いるのに適
したメソッドデスクリプタ７９のダイヤグラム図であ
る。メソッドデスクリプタ７９は、多くのデスクリプタ
・データ構造の一つであって、コールされるべき、すな
わちインボーク（呼出）されるべき特定のメソッドを記
述するのに用いられる。普通、メソッドデスクリプタ７
９はリモート（遠隔の）手順メソッドを記述する。分散
オブジェクト指向システムのクライアントクライアント
側とサーバー側の両方がメソッドデスクリプタデータ構
造７９を用いる。図示した実施例において、メソッドデ
スクリプタデータ構造７９は、キー８０、呼び出される
べきメソッドのローカルネーム８１、呼び出されるべき
メソッドの論理識別子（ＩＤ）８２を含む。キー８０は
任意の適当な形をとることができ、例えば、一つの文字
列(a string of characters)であるローカルネームのハ
ッシュ値(hash value)、すなわち数値の形をとることが
できる。ローカルネーム８１のハッシュ値は、メソッド
番号の作成に用いることができ、これは一義的（ユニー
ク）ではないが、関連するメソッドの識別に用いること
ができる。呼び出されるべきメソッドのローカルネーム
８１は、ノン・スコープト・ネーム(non-scoped name)
であり、メソッドデスクリプタが関連づけられるべきク
ライアントを識別する作用をする。論理ＩＤ（８２）
は、関連するメソッドのユニークネームである。すなわ
ち、論理ＩＤ（８２）はメソッドのグローバル（全体
的）識別子として作用する。

【００４０】メソッドのローカルネーム８１とメソッド
デスクリプタ内の論理ＩＤ（８２）に加えてキー８０を
設けることの利点は、メソッドのローカルネーム８１と
論理ＩＤ（８２）は普通は文字列であるのに対して、キ
ー８０は数値を持っているという事実に基づいている。
数値は、文字列(strings of characters)であるバリュ
ー（値）よりもはるかに速やかに比較、デコード、およ
び発送が可能である。メソッドデスクリプタ７９はメソ
ッドに関する情報を含んでいるが、メソッドの実際の呼
出しを記述する情報は含まない。従って、メソッドの実
際の呼出しを記述するための呼出しデスクリプタを設け
る。呼出しデスクリプタは、メソッドの呼出しに属する
情報を提供するデータ構造である。すなわち、呼出しデ
スクリプタは、メソッドデスクリプタによって記述され
る特定のリモート手順メソッドに関するすべての情報の
コレクション（集合）である。

【００４１】図５は、本発明の一実施例による呼出しデ
スクリプタ８４のダイヤグラム図である。呼出しデスク
リプタ８４はブール値(boolean values)、整数値、コン
テクスト、他のデータ構造へのポインター、および機能
へのポインターの組合せを含むことができる。ポインタ
ーは、汎用識別子(generic identifiers)すなわち適当
なデータ構造または機能を識別する任意の手段で置き換
えることができるものと理解すべきである。本明細書に
おいては、ポインターおよび識別子という用語は互換性
をもって用いることとする。ブール値または論理フラッ
グは、「編集された（コンパイルド）」(compiled)フラ
ッグ８４と「ワンウェイ」フラッグ８５を含む。コンパ
イルド・フラッグ８４は、呼出しパスがスタティックで
あるか、すなわち編集されているか、あるいはダイナミ
ックであるか、すなわちタイプコードによって解釈され
ているか、判定する。ダイナミック呼出しパスは、非編
集(non-compiled)呼出しパスとしても知られている。ワ
ンウェイフラッグ８５は、回答がリクエストに応答する
ものであるか識別する。整数値は、「イン」デスクリプ
タ・カウンター８６（ＩＮ ＤＥＳＣ ＣＯＵＮＴ）と
「アウト」デスクリプタ・カウンター（ＯＵＴ ＤＥＳ
Ｃ ＣＯＵＮＴ）８７を含む。両カウンターは、特定の
呼出しに関連する「イン」パラメータの数と「アウト」
パラメータの数をそれぞれ表す値を保持している。

【００４２】図５に示した呼出しデスクリプタ８３は、
他のデータ構造へのポインター、すなわち「イン」デス
クリプタ８８へのポインター（ＩＮ ＤＥＳＣ）、「ア
ウト」デスクリプタ８９へのポインター（ＯＵＴ ＤＥ
ＳＣ）、および例外デスクリプタへのポインター９０
（ＥＸＣＥＰＴＩＯＮ ＤＥＳＣ）を含む。ＩＮ ＤＥ
ＳＣ（８８）とＯＵＴ ＤＥＳＣ（８９）は、図６につ
いて以下に詳しく説明するパラメータデスクリプタへの
ポインターである。ＩＮ ＤＥＳＣ（８８）とＯＵＴ
ＤＥＳＣ（８９）は、それぞれパラメータデスクリプタ
の任意のアレイへのポインターとなることができる。Ｅ
ＸＣＥＰＴＩＯＮ ＤＥＳＣ（９０）は、例外デスクリ
プタへのポインターのアレイへのポインターであって、
図６について以下に説明する。ＩＮ ＤＥＳＣ ＣＯＵ
ＮＴ ８６（ＯＵＴ ＤＥＳＣ ＣＯＵＮＴ ８７）とＩ
Ｎ ＤＥＳＣ ８８（ＯＵＴ ＤＥＳＣ ８９）は、パラ
メータデスクリプタのオーダーされ、カウントされた集
合を実行するが、他の適当なデータ構造を用いて実行す
ることができる。

【００４３】図５に示した呼出しデスクリプタは、コン
テクスト９１も含む。例えばコンテクスト９１のような
コンテクストは、一般的に、呼出されるべきメソッドに
関連する情報を含む関連ストリングのアレイであること
ができる。コンテクストに含まれる情報は、呼出される
べきメソッドの実行に有用な情報であるかも知れない。
コンテクストは、概念的には関連性の表である。各関連
性は普通、ストリングであるキーと、当該キーに関連し
同じくストリングであるバリューを含む。

【００４４】再初期化機能９２へのポインター（ＲＥＩ
ＮＩＴ）は、図５に示した呼出しデスクリプタ８３の一
部として含まれている。再初期化機能は、バッファー内
のデータが処理され終わると、保存されているすべての
ポインターを開放し、関連するバッファーをクリアす
る。例えば、呼出されるべきメソッドが、情報をネット
ワーク通信ラインを介して転送するための準備メソッド
であるマーシャルメソッドである場合、再初期化機能
は、パラメータ内の情報がマーシャルされた後のある時
点において、関連するパラメータをクリアする。

【００４５】次に図６は、本発明の一実施例によるパラ
メータデスクリプタ９３のダイヤグラム図である。パラ
メータデスクリプタ９３は、特定のパラメータに関連す
る特性を記述するように配設されたデータ構造であっ
て、それ自体はイン・デスクリプタ（ＩＮ ＤＥＳＣ）
およびアウト・デスクリプタ（ＯＵＴ ＤＥＳＣ）を介
して呼び出しデスクリプタに関連をもっている。パラメ
ータデスクリプタ９３は、方向(direction 指示、方向)
９４とタイプコード９５を含むことができ、更にサイズ
コード９６、名称９７、関連するマーシャル機能へのポ
インター９８、および関連するアンマーシャル機能への
ポインター９９の任意の組合せを含むことができる。方
向９４は、与えられたパラメータの処理方向を識別する
インジケータである。方向９４は、モードとも称する。
処理方向は、クライアントのレファレンスのフレームか
ら、「イン」方向、「アウト」方向、「インアウト」方
向、および「リターン」方向である。イン方向は、与え
られたパラメータはクライアントからサーバーへ与えら
れた引数であることを示し、アウト方向は、与えられた
パラメータはサーバーからクライアントへ与えられた引
数であることを示す。従ってインアウト方向は、与えら
れたパラメータはイン方向とアウト方向の両方向に伝達
される引数であることになる。リターン方向は、与えら
れたパラメータはコールからの帰りの引数であることを
示す。

【００４６】上記のように、例えばパラメータデスクリ
プタ９３のようなパラメータデスクリプタは呼出しデス
クリプタに関連づけられている。具体的に、パラメータ
デスクリプタは、図４について上に説明したように、呼
出しデスクリプタに含まれるＩＮ ＤＥＳＣポインター
とＯＵＴ ＤＥＳＣポインターによって間接的に指示(p
oint)される。ＩＮ ＤＥＳＣは一般的に、処理方向が
イン方向またはインアウト方向であるパラメータのアレ
イへのポインターであり、ＯＵＴ ＤＥＳＣは一般的
に、処理方向がアウト方向またはリターン方向であるパ
ラメータのアレイへのポインターである。

【００４７】タイプコード９５は、パラメータの処理方
向に関する情報は含んでいないが、特定のデータタイ
プ、この場合パラメータのデータタイプを記述する仕様
を含んでいる。タイプコード９５は、マーシャルおよび
アンマーシャルの機能またはメソッドへのポインターを
含む。マーシャル機能については、図５について先に説
明した。アンマーシャル機能は、マーシャリング手順を
逆にして、データタイプが用いられるドメインにおいて
意味をもつデータタイプの事例を作成する機能である。
タイプコード９５はまた、データタイプのサイズに関す
る、換言すれば、データタイプの各事例が必要とするメ
モリーの量に関する、情報を含む。タイプコード９５の
主な目的はデータタイプ、更に具体的にはデータタイプ
の構造または構成要素を記述することであると、理解す
べきである。

【００４８】タイプコード９５は、マーシャル機能、ア
ンマーシャル機能、データタイプの名称と構成要素に関
する情報、データタイプの事例に必要なメモリーのサイ
ズまたは量へのポインターを含んでいるので、パラメー
タデスクリプタの一部としてマーシャル機能、アンマー
シャル機能、およびデータタイプのサイズに関する値
（バリュー）を特に含む必要はない。しかし、パラメー
タデスクリプタ内のタイプコード９５から抽出すること
のできる情報を明示的に提供することは、情報を必要の
都度抽出することに係わる性能損失を除去できるので、
有利である。例えば、タイプコード９５を介してデータ
タイプのサイズを計算することは、構成要素タイプのサ
イズの繰り返し計算と結果の集計を伴い、経費がかか
る。従って、先に述べたように、パラメータデスクリプ
タ９３は、方向９４とパラメータのタイプコード９５に
加えて、マーシャル機能とアンマーシャル機能それぞれ
へのポインター９８および９９のみならず、関連するパ
ラメータのサイズ９６とパラメータの名称に関する情報
を明示的に含むことができる。

【００４９】次に図７は、本発明の一実施例による例外
デスクリプタ１０２のダイヤグラム図である。例外デス
クリプタ１０２は、関連する例外の特性を記述するよう
に配設されたデータ構造である。上記のパラメータデス
クリプタのように、例外デスクリプタ１０２は呼出しデ
スクリプタに関連し、図５について上に述べたＥＸＣＥ
ＰＴＩＯＮ ＤＥＳＣによって間接的に指し示される。
例外デスクリプタ１０２は、タイプコード１０３を含む
ことができ、更にサイズ１０４、キー１０７、レポジト
リ識別子１０８、関連するマーシャル機能１１１へのポ
インター、関連するアンマーシャル機能１１２へのポイ
ンター、および投入機能１１３へのポインターを含むこ
とができる。上記のパラメータデスクリプタは方向を含
んでいるが、例外デスクリプタ１０２は、処理方向が常
にサーバーからクライアントであるので、含まない。換
言すれば、例外は常にサーバーからクライアントへ伝達
される。

【００５０】図６について上に述べたように、タイプコ
ード１０３は、データタイプに関連するマーシャル機能
とアンマーシャル機能を含む特定のデータタイプを記述
する仕様を含む。図７に戻ると、この場合のエンティテ
ィは例外である。例外に関連するマーシャル機能とアン
マーシャル機能へのポインターを含むことに加えて、タ
イプコード１０３は、例外のサイズ、すなわち例外を受
信しているプロセスによって割当てられねばならないメ
モリーの量に関する情報を含む。タイプコード１０３は
更に、レポジトリ識別子（ＲＥＰＯＳＩＴＯＲＹ Ｉ
Ｄ）を含む。レポジトリ識別子は更に例外を一義的（ユ
ニーク）に識別する。レポジトリ識別子は、図４につい
て上に説明したメソッドデスクリプタの論理識別子ＬＯ
ＧＩＣＡＬ ＩＤに多少類似していて、例外レポジトリ、
あるいはすべての例外の「リスト」内の一つの例外を一
義的に識別するのに用いることができる。最後に、タイ
プコード１０３は、例外の性質を指定する投入機能（Ｔ
ＨＲＯＷ ＦＵＮＣ）へのポインターを含み、例外の場
合、リクエストの再回送に用いられる。特に例外デスク
リプタに関連するタイプコード１０３内の情報のみを説
明したが、タイプコード１０３は説明したよりも更に大
量の情報を一般的に含むことができるものと認識すべき
である。

【００５１】図６について上に述べたパラメータデスク
リプタの場合もそうであったが、図７について上に述べ
た例外デスクリプタ１０２はタイプコード１０３から抽
出することのできる情報を明示的に含んでいる。この場
合にも、この情報、すなわち、例外のサイズ１０４、キ
ー１０７、レポジトリ識別子１０８、関連するマーシャ
ル機能へのポインター１１１、および関連するアンマー
シャル機能へのポインター１１２、の任意の組合せを明
示的に例外レポジトリ１０２に含めて、情報をタイプコ
ード１０３からその都度抽出することに係わる性能損失
を避けることができる。

【００５２】図４から図７までについて説明した４つの
デスクリプタデータ構造は相互に関連づけられる。パラ
メータデスクリプタデータ構造と例外デスクリプタデー
タ構造は、分散オブジェクト指向システムの立上げ時、
コンパイラールーチンによって作成される。すなわち、
パラメータデスクリプタデータ構造と例外デスクリプタ
データ構造は、コンパイル時に自動的にファイルされ
る。他方、メソッドデスクリプタデータ構造と呼出しデ
スクリプタデータ構造は、立上げ時に作成されてコンパ
イル時に自動的にファイルされてもよいし、あるいは、
それらは実行時(run-time)に作成されてもよい。呼出し
デスクリプタは、パラメータデスクリプタのアレイへの
ポインターと例外デスクリプタへのポインターのアレイ
を含む。メソッドデスクリプタと残りの３つのデータ構
造の間の関係は、本発明の一実施例による分散オブジェ
クトのクライアント側における呼出しメソッドへのコー
ルの表現である図８を参照すると最もよく理解できる。
呼出しメソッドへのコールは、メソッドデスクリプタへ
のポインター、関連する呼出しデスクリプタへのポイン
ター、パラメータ・アドレスのアレイまたは保存場所へ
のポインター、ＣＯＲＢＡコンテクスト、およびＣＯＲ
ＢＡ例外を、引数として含めることに係わる。メソッド
デスクリプタと呼出しデスクリプタは、ともに呼出しメ
ソッドへのコールの一部であるので、相互に関連してい
る。メソッドデスクリプタと呼出しデスクリプタは、一
つのデスクリプタデータ構造にまとめることもできる
が、別々のままにしてある。その理由は、分散オブジェ
クトシステムのクライアント側とサーバー側はともにメ
ソッドデスクリプタを用いるが、サーバー側において、
メソッドデスクリプタ内の情報と呼出しデスクリプタ内
の情報はシステム全体の別々の場所から来るという事実
である。パラメータアドレスのリストは、呼出しメソッ
ドへのコール毎に変化し、そこから「イン」引数を取出
し、そこへ「アウト」引数を保存するメモリー場所を提
供する作用をする。パラメータ保存場所アレイは、図２
について上に述べたスタブとスケルトンによって step
up される。ＣＯＲＢＡ例外保存例外デスクリプタは、
例外リターンポインターへのポインターを提供する。こ
の例外リターンポインターへのポインターは、例外への
ポインターをどこに保存するかを示す。例外リターンポ
インターへのポインターが無しの場合、例外リターンが
投入される。

【００５３】次に図９について、本発明の一実施例によ
るオブジェクト呼出しメソッドを説明する。すなわち、
メソッドを呼び出すためにコールが行われると発生する
ステップをダイヤグラムに示す。まず、ファットポイン
トを用いるコールまたはリクエストをクライアントが受
取る。このコールは任意の適当なコンピュータ言語であ
ればよいが、図示の実施例においてはＣ＋＋コールであ
る。ファットポインターはまた、「大きな」ポインタ
ー、すなわち少なくとも２個の「通常」ポインターを含
むポインター構造であると見なすことができる。ファッ
トポインターはまた、ＣＯＲＢＡオブジェクトレファレ
ンスであると見なすこともできる。ファットポインター
が２個の「通常」ポインターを持つ場合、ファットポイ
ンターは普通、８バイトを含み、通常ポインターは普通
それぞれ４バイトを持つ。ファットポインターは、代表
ポインター「レップ」とメソッドテーブル（またはｍテ
ーブル）ポインターからなり、両者はそれぞれ通常ポイ
ンターであり、クライアント上において分散オブジェク
トを代表（表現）するサブコントラクト・エンティティ
である。

【００５４】ステップ１００において、コールされたメ
ソッドはファットポインターによって指示されるｍテー
ブル内にある。コールされたメソッドがローカルメソッ
ドであれば、ファットポインターによって指示されるｍ
テーブルはローカルｍテーブルである。同様に、コール
されたメソッドがリモートメソッドであれば、ファット
ポインターによって指示されるｍテーブルはリモートｍ
テーブルである。ステップ１０５において、ファットポ
インターとＣ＋＋コールへの引数によって識別されたク
ライアント表現をもって指示された機能へのコールが行
われる。この機能がコールされた後、プロセスコントロ
ールは、指示された機能がローカルプロセスであるかリ
モートプロセスであるかによって、異なる機能へ分岐す
る。指示された機能がローカルプロセスである場合、プ
ロセスコントロールはステップ１１０へ進み、ローカル
スタブが実行される。ステップ１１０においてローカル
スタブが実行された後、プロセスはステップ１２０にお
いて機能コールから戻る。ファットポインターによって
指示される機能がリモートプロセス内にあって、ローカ
ルプロセス内にない場合、プロセスコントロールはステ
ップ１０５において機能がコールされた後、ステップ１
１５へ進む。ステップ１１５において、リモートスタブ
が実行される。リモートスタブを実行するプロセスを以
下に詳しく説明する。ステップ１１５において、リモー
トスタブが実行された後、プロセスコントロールはステ
ップ１２０へ進み、これは次に機能コールから戻る。

【００５５】次に図１０を参照して、本発明の一実施例
によるリモートスタブの実行メソッドを説明する。すな
わち、図９を参照してリモートスタブの実行ステップ１
１５を説明する。複数の引数のリストまたはコンテクス
トを用いる場は、一つのコンテクストを用いるリモート
スタブからの呼出しのスタートは、ステップ１９０にお
いて始まり、リターンパラメータおよびアウトパラメー
タ、すなわちリターン処理方向を持ったパラメータおよ
びアウト処理方向を持ったパラメータのためのストーレ
ッジ、すなわちメモリーの割当てが行われる。本明細書
においては、「イン・パラメータ」および「アウト・パ
ラメータ」という用語はそれぞれ、「イン処理方向を持
ったパラメータ」および「アウト処理方向を持ったパラ
メータ」という語句と互換性をもって用いることとす
る。同様に、「リターン・パラメータ」および「インア
ウト・パラメータ」という用語はそれぞれ、「リターン
処理方向を持ったパラメータ」および「インアウト処理
方向を持ったパラメータ」という語句と互換性をもって
用いることとする。インアウト処理方向を持ったパラメ
ータ用のメモリーは予め割当てられているので、メモリ
ー割当てステップ１９０においては、インアウト・パラ
メータ用のメモリーは割当てられない。プロセスコント
ロールはメモリー割当てステップ１９０からステップ１
９２へ進み、そこでインパラメータが設定される。呼出
しメソッドがコールされる毎に、リモートスタブからの
呼出しに用いられた引数に関連するイン・パラメータを
設定しなければならない。イン・パラメータを設定は、
図８の呼出しメソッドへＩＮ ＰＡＲＡＭとして送るべ
きイン・パラメータを保持するメモリー場所へのポイン
ターのアレイの設定を必要とする。イン・パラメータの
設定から、プロセスコントロールはステップ１９４へ進
み、そこでアウトパラメータとインパラメータが設定さ
れる。すなわち、図８の呼出しメソッドへＯＵＴ ＰＡ
ＲＡＭとして送られるべきアウトパラメータを受信する
メモリー場所へのポインターのアレイが作成される。

【００５６】アウトパラメータ設定のステップ１９４か
ら、プロセスコントロールはステップ１９６へ移行し、
そこでクライアント表現(client representation)に関
する呼出しメソッドへのコールが行われる。「シグネチ
ャー」(signature)または基本的要素または呼出しメソ
ッドは、図８について先にのべたものと解釈されるべき
である。各クライアント表現は関連する呼出しメソッド
を持っている。クライアント表現に関する呼出しメソッ
ドのコールに係わるステップを、図１１を参照して以下
に説明する。ステップ１９７において、ステップ１９６
における呼出しメソッドへのコールの結果が例外になる
か否か判定される。例外があったと判定されると、プロ
セスコントロールはステップ１９８へ進み、ステップ１
９０においてリターンパラメータとアウトパラメータの
保存に割当てられたメモリーが割当て解除される。次に
プロセスコントロールはコールの結果を呼出しメソッド
へ返す。ステップ１９７において、例外がなかったと判
定されると、プロセスコントロールは単にコールの結果
を呼出しメソッドへ返すのみである。

【００５７】次に図１１を参照して、本発明の一実施例
によるクライアント表現の呼出しメソッドを説明する。
すなわち、図１０を参照して、クライアント表現の呼出
しメソッドをコールするステップ１９６を説明する。こ
のステップはステップ２０１において始まり、ここでは
リモートスタブが、引数として複数のデスクリプタ、す
なわちメソッドデスクリプタ、呼出しデスクリプタ、パ
ラメータ保存場所デスクリプタおよび例外保存場所デス
クリプタを用いて、クライアント表現の呼出しメソッド
をコールする。換言すれば、リモートスタブは複数のデ
スクリプタを引数として用いて適当なサブコントラクト
を呼出す。ステップ２０２において、トランスポートが
選ばれる。一つのサブコントラクトのみが一つのトラン
スポートをサポートするならば、そのトランスポートが
選ばれる。サブコントラクトが複数のトランスポートを
持っていれば、選ばれるべき最適のトランスポートを指
定する情報を、トランスポートに関連するメトリックス
(metrics)が提供する。トランスポートが選ばれると、
プロセスコントロールはステップ２０４へ進み、ターゲ
ットオブジェクトレファレンスに基づいてエンドポイン
トが識別される。エンドポイントは、呼出しを受信する
こと、およびメッセージを送ることに用いられる「ポー
トホール」(porthole 出入り口)、すなわち接続点であ
る。ＣＯＲＢＡオブジェクトレファレンスは他のオブジ
ェクトへのポインターを含むことができ、これについて
は図２を参照して先に説明した。オブジェクトレファレ
ンス内のオブジェクトキーは、図２を参照して先に説明
したように、ターゲットオブジェクト、すなわちリクエ
ストのターゲットであるオブジェクトを識別する。エン
ドポイントの識別は、クライアントのトランスポートレ
ヤーあるいはクライアントのサブコントラクトレヤーの
いずれにおいて行ってもよい。エンドポイントが識別さ
れた後、プロセスコントロールはステップ２０６へ進
み、そこでステップ２０２において選ばれた最適のマー
シャルバッファーが作成される。これはクライアント側
のトランスポートレヤーにおいて行われる。マーシャル
バッファーは本質的にはトランスポート（転送）される
べき情報をカプセル化するネットワークバッファーであ
って、トランスポートに適したアトミックデータをエン
コードする能力を持っている。マーシャルバッファー
は、マーシャルバッファーからマーシャルまたはアンマ
ーシャルされるべき情報のエンコーディング・フォーマ
ットを指定する識別子またはタグを持っている。サブコ
ントラクトは、識別子があるので、選ばれたトランスポ
ートに適したマーシャルバッファーを識別することがで
きる。

【００５８】選ばれたトランスポートに適したマーシャ
ルバッファーが作成された後、ステップ２０８におい
て、ターゲットオブジェクトレファレンスおよびオペレ
ーション、またはメソッドデスクリプションが、マーシ
ャルされる。このステップにおいては、別途分割できな
いオブジェクトレファレンス部分のみがマーシャルされ
る。ステップ２０９において、コンテクストが用いられ
る場合、コンテクストがマーシャルされる。コンテクス
ト内において呼出しメソッドに関連(interest)のある情
報のみがピックアウト（選出）される。コンテクストの
マーシャリングのステップから、プロセスコントロール
はステップ２１０へ進み、そこでデスクリプタを用いて
引数がマーシャルされる。オブジェクトレファレンスが
引数の一つとしておくられた場合、それは引数オブジェ
クトレファレンスによって供給される情報を用いてマー
シャルされる。デスクリプタを用いて引数をマーシャル
するプロセスは、図１２について以下に説明する。コン
テクストをマーシャルするステップ２０９は、デスクリ
プタを用いて引数をマーシャルする（図示の）ステップ
２１０の前、または後のいずれで行われてもよい。コン
テクストを用いない場合、ステップ２０９を行う必要は
全くない。

【００５９】コンテクスト（用いられる場合）と引数が
マーシャルされた後、プロセスコントロールはステップ
２１２へ進み、そこで、マーシャルバッファーの内容
が、選ばれたトランスポートを介して、識別されたエン
ドポイントへ伝達される。選ばれたトランスポートのほ
とんどすべてに関して、このステップは、マーシャルバ
ッファーの内容をワイヤーを介して送ることを必要とす
る。伝達ステップ２１２は、クライアントからサーバー
への通信と見なすことができる。伝達ステップ２１２か
ら、プロセスコントロールはステップ２１４へ進み、そ
こでクライアントはサーバーからの回答を待つ。ステッ
プ２１６において、クライアントはサーバーからの回答
を受取る。クライアントがサーバーからの回答を受取っ
た後、プロセスコントロールはステップ２１８へ進み、
そこでサーバーから受取った回答はマーシャルバッファ
ー内にカプセル化される。回答がリクエストより大きい
場合、回答をカプセル化するため新しいマーシャルバッ
ファーを作成することができる。しかし、回答がリクエ
ストより大きくないい場合、ステップ２０６において作
成されたマーシャルバッファーを用いて、ステップ２１
８において回答がカプセル化される。回答をカプセル化
するステップはトランスポートレヤーにおいて行われる
ものと理解すべきである。

【００６０】回答がマーシャルバッファー内においてカ
プセル化されると、プロセスコントロールはステップ２
２０へ進み、そこでトランスポートに特有のヘッダー
が、マーシャルバッファー内にカプセル化されている回
答からアンマーシャルされる。トランスポートに特有の
ヘッダーは、ステップ２０２において選ばれたトランス
ポートに属す情報を含んでいる。その他のヘッダーとし
ては、引数を識別するヘッダーとリクエスト識別子を指
定するヘッダーがある。マーシャルバッファーに関連す
るポインターを用いてヘッダーの始めと終わりを判定す
ることができる。このポインターはマーシャルバッファ
ー内においてバイトからバイトへ移動する。トランスポ
ートに特有のヘッダーが回答からアンマーシャルされた
後、プロセスコントロールはステップ２２２へ進み、そ
こでオリジナルコールからのデスクリプタを用いて引数
がアンマーシャルされる。ステップ２２２を、図１３に
ついて、以下に説明する。ステップ２２２を、図１３に
ついて、以下に説明する。デスクリプタを用いて引数が
アンマーシャルされた後、プロセスはリモートスタブへ
戻る。

【００６１】次に図１２を参照して、デスクリプタを用
いた引数のマーシャリングメソッド、すなわち図１０の
ステップ２１０を本発明の一実施例に従って説明する。
引数をマーシャルする図１０のステップは、このプロセ
スの作用は呼出しパスがスタティックであるか、すなわ
ち編集されているか、あるいはダイナミックであるかに
基づいて適当なマーシャリング・ルーチンを呼出すこと
であるので、デスクリプタを用いて引数を包括的にマー
シャルするプロセスと見なすことができる。図１２に戻
ると、デスクリプタを用いて引数を包括的にマーシャル
する第１のステップはステップ１１００であり、ここで
は呼出しパスがスタティックであるかダイナミックであ
るか、判定される。具体的に、本実施例のステップ１１
００において、呼出しデスクリプタのコンパイルフラッ
グが真(true)に設定されているか、判定される。コンパ
イルフラッグが真(true)に設定されていると判定された
場合、これは呼出しパスがスタティックであることを示
し、プロセスコントロールはステップ１１０２へ進み、
そこでカウンターｉはまずゼロに設定され、カウンター
の値ｉが引数カウント以上であるか否か判定される。引
数カウントは引数として送られる。これは普通、図５に
ついて先に説明したＩＮ ＤＥＳＣ ＣＯＵＮＴまたは
ＯＵＴ ＤＥＳＣ ＣＯＵＮＴである。引数カウント
は、引数として送り込まれたパラメータデスクリプタに
よって指示されたパラメータの合計数を表す。各パラメ
ータｉについて、パラメータ保存場所デスクリプタによ
って与えられる、関連するマーシャルバッファーとパラ
メータｉに関するアドレスを含む引数を送って、パラメ
ータｉに適したマーシャルメソッドが呼出されるステッ
プ１１０４が、繰り返される。パラメータｉに関するア
ドレスは、図７について上に述べたように、メソッドを
呼出すコールの一部であるパラメータアドレスリストへ
のポインターによって識別される。イン・パラメータに
関して一つのパラメータアドレスリストと、アウト・パ
ラメータに関して一つのパラメータアドレスリストがあ
るので、このメソッドへ送られるリストは、クライアン
ト側において「イン」引数がマーシャルされているか、
「アウト」引数がサーバー側においてマーシャルされて
いるかに依存する。プロセスコントロールは、すべての
パラメータが処理されてしまうまで、すべてのパラメー
タが処理されてしまったか否か判定するステップ１１０
２と、パラメータｉに適したマーシャルメソッドを呼出
すステップ１１０４の間においてループを描く（循環す
る）。すべてのパラメータが処理されてしまうと、すな
わちカウンターｉが引数・カウントに等しくなると、プ
ロセスコントロールはステップ１１１０へ進み、そこ
で、マーシャルメソッドを呼出すコールのいずれかによ
って例外が投入されたか否か判定される。

【００６２】ステップ１１１０において編集フラッグが
真に設定されていないと判定された場合、これは呼出し
パスがダイナミックであることを示す。呼出しパスがダ
イナミックであるとの判定の後、プロセスコントロール
はステップ１１０６へ進み、そこでカウンターｉはまず
ゼロに設定され、カウンターｉが引数カウント以上であ
るか否か判定される。引数カウントは通常、呼出しデス
クリプタのＩＮ ＤＥＳＣ ＣＯＵＮＴまたはＯＵＴ
ＤＥＳＣ ＣＯＵＮＴである。パラメータｉに関連する
タイプコード、関連するマーシャルバッファー、および
パラメータｉのアドレスを含む複数の引数を送ってタイ
プコード・マーシャリング・ルーチンが呼出されるステ
ップ１１０８が、各パラメータｉについて繰り返され
る。一般的に、タイプコード・マーシャリング・ルーチ
ンはタイプコード・インタープリタによって実行され
る。タイプコードはパラメータデスクリプタ内と例外デ
スクリプタ内の両方に見いだされるのに対して、パラメ
ータｉのアドレスは、図８について上に述べたように、
メソッドを呼出すコードの一部であるパラメータ・アド
レス・リストへのポインターによって識別される。イン
・パラメータに関して一つのパラメータアドレスリスト
と、アウト・パラメータに関して一つのパラメータアド
レスリストがあるので、このメソッドへ送られるリスト
は、クライアント側において「イン」引数がマーシャル
されているか、「アウト」引数がサーバー側においてマ
ーシャルされているかに依存する。プロセスコントロー
ルは、カウンターｉが引数カウントを超えるまで、すべ
てのパラメータが処理されてしまったか否か判定するス
テップ１１０６と、タイプコード・マーシャリング・ル
ーチンを呼出すステップ１１０８の間においてループを
描く（循環する）。すべてのパラメータが処理されたと
判定されると、プロセスコントロールはステップ１１１
０へ進み、そこで、マーシャルメソッドを呼出すコール
のいずれかによって例外が投入されたか否か判定され
る。

【００６３】マーシャルメソッドを呼出すコールのいず
れかによって例外が投入されたか否か判定するステップ
１１１０において、例外が投入されなかったと判定され
た場合、デスクリプタを用いて引数をマーシャルするス
テップ、すなわち図１０のステップ２１０は完了する。
例外が投入されたと判定された場合、プロセスコントロ
ールはステップ１１１２へ移行し、そこで例外リターン
・ポインターが無(null)であるか否か判定される。すな
わち、ステップ１１１２は、例外の投入が適切であるか
否かの判定である。呼出しメソッドへのコールの考察に
おいて先に述べた例外リターン・ポインターが無である
場合、これは特定のマーシャリングの例外がコーラーへ
投入されたことを示す。もしそうであるならば、プロセ
スコントロールは、例外ポインターが無であるか否かの
判定ステップ１１１２から、特定のマーシャリングの例
外を投入するステップ１１１４へ移行する。例外ポイン
ターが無でない場合、プロセスコントロールはステップ
１１１６へ移行し、そこでマーシャリングの例外のため
のメモリーが割当てられ、例外が初期化される。次にス
テップ１１１８において、ステップ１１１６において割
当てられたストーレッジのアドレス、すなわちメモリー
のアドレスが、例外リターン・ポインターによって指示
されたポインターへ割当てられる。ステップ１１１８の
完了後、デスクリプタを用いて引数をマーシャルするプ
ロセスは完了する。

【００６４】包括的なマーシャリング・ルーチンは、分
散オブジェクトシステムのクライアント側とサーバー側
によって共用されるものと理解すべきである。クライア
ント側からコールされた場合、引数としてＩＮ ＰＡＲ
ＡＭ、ＩＮ ＤＥＳＣ、およびＩＮ ＤＥＳＣ ＣＯＵ
ＮＴが送られる。同様に、サーバー側からコールされた
場合、引数としてＯＵＴ ＰＡＲＡＭ、ＯＵＴ ＤＥＳ
Ｃ、およびＯＵＴ ＤＥＳＣ ＣＯＵＮＴが送られる。
更に、多くの包括的マーシャリング・ルーチンがあり得
るものと理解すべきである。例えば、逆の順序で引数を
マーシャルする包括的マーシャリング・ルーチンがあり
得るものと理解すべきである。しかし、編集マーシャリ
ングとタイプコード解釈マーシャリングとの相違は、包
括的マーシャリング・ルーチン内においてのみ知り得
る。

【００６５】次に図１３を参照して、デスクリプタを用
いて引数をアンマーシャルするメソッドを、本発明の一
実施例に従って説明する。すなわち、図１１のステップ
２２２を検討する。デスクリプタを用いて引数をアンマ
ーシャルするプロセスはステップ１２０１において始ま
り、そこでサーバーが例外を提起したか(raised)否か判
定される。サーバーが例外を提起しなかった場合、プロ
セスコントロールはステップ１２０２へ進み、そこで、
先に用いたメモリーをリフレッシュするため再初期化機
能がコールされる。再初期化機能がコールされた後、プ
ロセスコントロールはステップ１２０３へ進み、そこ
で、包括的アンマーシャリング・ルーチンへのコールが
行われる。包括的なアンマーシャリング・ルーチンは、
分散オブジェクトシステムのクライアント側とサーバー
側両方によって用いられるものと理解すべきである。包
括的なアンマーシャリング・ルーチンの実行プロセスを
図１４を参照して以下に考察する。

【００６６】ステップ１２０１においてサーバーが例外
を提起したと判定された場合、ステップ１２０４におい
てマーシャルバッファー内の情報から例外のタイプ、識
別子（ＩＤ）、およびキーが決定される。例外のタイ
プ、識別子（ＩＤ）、およびキーは、任意の数のメソッ
ドによって決定することができる。例えば、当業者には
理解できるように、マーシャルバッファー上において
「ピーク」メソッドを用いることができる。例外のタイ
プ、識別子（ＩＤ）、およびキーが決定された後、ステ
ップ１２０６において、サーバーが提起した例外が、予
め定義されたシステム例外であるか、あるいはユーザー
によって定義された例外であるかが判定される。例外が
ユーザーによって定義された例外である場合、ステップ
１２６０において、ユーザー例外ルーチンをコールす
る。ユーザーによって定義された例外ルーチンの実行に
係わるステップを、図１５を参照して以下に説明する。

【００６７】ステップ１２０６において、例外が予め定
義されたシステム例外であると判定された場合、プロセ
スコントロールはステップ１２０８へ移行し、例外リタ
ーンポインターが無であるか否か判定される。例外リタ
ーンポインターが無であるか否かの判定は、アンマーシ
ャルされるべき例外のためのメモリーを割当てることが
最終的に必要であるか否かの判定と見なすことができ
る。例外リターンポインターが無である場合、プロセス
コントロールはステップ１２１０へ移行し、そこですべ
てのシステム例外のリストを含むシステム例外デスクリ
プタレポジトリ内のマッチするキーを探す。システムデ
スクリプタレポジトリは、システム全体のＥＸＣＥＰＴ
ＩＯＮ ＤＥＳＣ、すなわち、各システム例外を記述す
る例外デスクリプタへのポインターのリストである。マ
ッチするキーをサーチした後、ステップ１２１２におい
て、マーシャルバッファー内の情報から決定されたキー
に関するキー・マッチが見いだされたか、判定が行われ
る。キー・マッチが見いだされなかった場合、例外が投
入され、システム例外が見いだされなかったことを示
し、デスクリプタを用いて引数をアンマーシャルするプ
ロセスは完了したと見なされる。マーシャルバッファー
内の情報から決定されたキーに関するキー・マッチが見
いだされたと判定された場合、例外識別子（ＩＤ）を、
ステップ１２１４においてマッチしたキーに関する識別
子（ＩＤ）と比較する。換言すれば、システム例外デス
クリプタレポジトリ内で見いだされたキーに対応するＩ
Ｄと、ステップ１２０４においてマーシャルバッファー
内の情報から決定された例外ＩＤとの間で比較が行われ
る。

【００６８】例外ＩＤを、マッチしたキーに関連するＩ
Ｄと比較した後、プロセスコントロールはステップ１２
１６へ移行し、そこで例外ＩＤの、マッチしたキーに関
連するＩＤとの比較が有利であるか判定される。すなわ
ち、例外ＩＤと、マッチしたキーに関連するＩＤとが相
互に矛盾がないか判定される。例外ＩＤが、マッチした
キーに関連するＩＤに本当にマッチする場合、ステップ
１２２２においてマーシャルバッファーへのポインター
を送って、マッチしたキーに関連する投入機能がコール
される。Ｃ＋＋実施例においては、投入機能は例外に関
連するデータをアンマーシャルして例外を投入する。投
入機能は、図６を参照して上に説明した。マッチしたキ
ーに関連する投入機能がコールされると、デスクリプタ
を用いて引数をアンマーシャルするプロセスは完了す
る。ステップ１２１６において、例外ＩＤと、マッチし
たキーに関連するＩＤとがマッチしないと判定された場
合、ステップ１２１８において、システム例外デスクリ
プタレポジトリをサーチして、もう一つのキーマッチを
探す。次にプロセスコントロールはステップ１２１２へ
戻り、キーマッチが見いだされたか否か、判定される。

【００６９】先のステップ１２０８において例外リター
ンポインターが無でないと判定された場合、システム例
外デスクリプタレポジトリ内においてマッチするキーを
求めるサーチが行われる。次にステップ１２４２におい
て、キーマッチが見いだされたか、判定される。キーマ
ッチが見いだされなかった場合、ステップ１２５０にお
いて、システム例外が見いだされなかったことを示すた
めメモリーが割当てられる。従って、割り当てられた例
外が作成される。割り当てられた例外は次にステップ１
２５２において例外リターンポインターを介して戻され
る。すなわち、例外に割当てられたメモリーのアドレス
が戻され、デスクリプタを用いて引数をアンマーシャル
するプロセスは完了する。

【００７０】ステップ１２４２においてキーマッチが見
いだされた場合、プロセスコントロールはステップ１２
４４へ移行し、そこで例外識別子（ＩＤ）を、マッチし
たキーに関する識別子（ＩＤ）と比較する。ステップ１
２４４からプロセスコントロールはステップ１２４６へ
移行し、例外識別子（ＩＤ）と、マッチしたキーに関す
る識別子（ＩＤ）との比較の結果がマッチであるか、判
定される。ステップ１２４８において、システム例外デ
スクリプタレポジトリをサーチして、もう一つのキーマ
ッチを探す。システム例外デスクリプタレポジトリをサ
ーチして、もう一つのキーマッチを探した後、プロセス
コントロールはステップ１２４２へ戻り、もう一つのキ
ーマッチが見いだされたか否か、判定される。例外ＩＤ
と、マッチしたキーに関するＩＤが本当にマッチしてい
る場合、例外をアンマーシャルするためのメモリーがス
テップ１２５４において割当てられる。つぎにステップ
１２５５において、見いだされた例外デスクリプタに関
するアンマーシャル機能へのポインターが無であるか、
判定される。ポインターが無である場合、これは、コー
ルされるべきアンマーシャル機能がダイナミックであ
る、すなわちタイプコードに基づいていることを示す。
タイプコードに基づくアンマーシャルルーチンは、ステ
ップ１２５８において、関連する例外タイプコード、関
連するマーシャルバッファー、および割当てられたメモ
リーのアドレスを送ってコールされる。関連する例外タ
イプコードは例外デスクリプタレポジトリから見いだす
ことができるものと解釈すべきである。アンマーシャル
ルーチンがステップ１２５８においてコールされた後、
プロセスコントロールはステップ１２５２へ進み、そこ
で割当てられた例外が例外リターンポインターを介して
戻され、デスクリプタを用いて引数をアンマーシャルす
るプロセスは完了する。アンマーシャルされるべき機能
が無でない場合、コールされるべきアンマーシャル機能
がスタティック、すなわち編集されたものである。ステ
ップ１２５６において、マッチしたキーに関連するアン
マーシャル機能へのコールが行われ、関連するマーシャ
ルバッファーへのポインターが引数として送られる。ア
ンマーシャル機能へのコールの後、プロセスコントロー
ルはステップ１２５２へ進み、そこで割当てられた例外
が例外リターンポインターを介して戻される。

【００７１】次に図１４を参照して、デスクリプタを用
いて引数を包括的にアンマーシャルするメソッドを本発
明の一実施例に従って説明する。デスクリプタを用いて
引数を包括的にアンマーシャルするメソッドは、図２０
のステップ１５１０にも関係があり、これを以下に説明
する。デスクリプタを用いて引数を包括的にアンマーシ
ャルするメソッドの第１ステップはステップ１１３０で
あって、ここでは呼出しデスクリプタのコンパイル・フ
ラッグが真(true)に設定されているか、判定される。コ
ンパイル・フラッグが真(true)に設定されていると判定
された場合、これは呼出しパスがスタティックであるこ
とを示し、プロセスコントロールはステップ１１３２へ
進み、そこでカウンターｉがまず１に設定され、そこで
カウンターｉの値が引数のカウント（計数値）以上であ
るか、判定される。引数のカウント（計数値）は、アン
マーシャルされるべき引数またはパラメータの数を示
す。各パラメータｉについて、関連するマーシャルバッ
ファーとパラメータｉに関するアドレスを含む引数を送
って、パラメータｉに適した、送り込まれたパラメータ
デスクリプタによって識別されたアンマーシャルメソッ
ドが呼出される、ステップ１１３４が繰り返される。パ
ラメータｉに関するアドレスは、図８について上に説明
したように、メソッドを呼出すためのコールの一部であ
るパラメータアドレスリストへのポインターによって識
別される。「パラメータ保存場所」と「パラメータアド
レスリスト」という用語は互換的に用いられるものと解
釈すべきである。プロセスコントロールは、カウンター
ｉを増加させてカウンターｉが引数カウント以上である
か判定するステップ１１３２と、パラメータｉに関する
アンマーシャルメソッドを呼出すステップ１１３４の間
で、すべてのパラメータが処理されてしまうまで循環す
る。すべてのパラメータが処理されてしまうと、プロセ
スコントロールは１１４０へ進み、そこで、アンマーシ
ャルメソッドを呼出すコールのいずれかによって例外が
投入されたか否か判定される。

【００７２】ステップ１１３０においてコンパイルフラ
ッグが真に設定されていないと判定された場合、これは
呼出しパスがダイナミックである、すなわちタイプコー
ドによって解釈されることを示す。コンパイルフラッグ
が真に設定されていない場合、プロセスコントロールは
ステップ１１３６へ進み、そこでカウンターｉに増分が
加えられ、カウンターｉが引数カウント以上であるか否
か判定される。換言すれば、ステップ１１３６はカウン
ターｉに増分を加え、未処理のパラメータの有無を判定
する。各パラメータｉについて、パラメータｉに関連す
るタイプコード、関連するマーシャルバッファー、およ
びパラメータｉに関するアドレスを送ってタイプコード
・アンマーシャリング・ルーチンを呼出すステップ１１
３８が、未処理パラメータがなくなるまで繰り返され
る。タイプコードはパラメータデスクリプタと例外デス
クリプタの両方において見いだすことができるが、送り
込まれるパラメータｉに関するアドレスは、先に述べた
ように、パラメータ・アドレス・リストへのポインター
を用いて識別される。すべてのパラメータが処理された
と判定されると、プロセスコントロールはステップ１１
４０へ進み、そこで例外が投入されたか否か判定され
る。

【００７３】ステップ１１４０において、アンマーシャ
ルメソッドを呼出すコールのいずれかによって例外が投
入されたか否か判定される。例外が投入されなかった場
合、デスクリプタを用いて引数をアンマーシャルするプ
ロセスは完了する。例外が投入されたと判定された場
合、プロセスコントロールはステップ１１４２へ移行
し、そこで、例外リターンポインターが無であるか否か
判定される。例外リターンポインターが無である場合、
これは、特定のアンマーシャル例外が投入され得ること
を示す。もしそうであれば、ステップ１１４４において
特定のアンマーシャル例外が投入される。ステップ１１
４２において、例外リターンポインターが無でないと判
定された場合、プロセスコントロールはステップ１１４
６へ進み、そこで、例外をアンマーシャルするためのメ
モリーが割当てられる。次に、ステップ１１４８におい
て、ステップ１１４６において割当てられたストーレッ
ジ、すなわちメモリーのアドレスが、例外リターンポイ
ンターによって指し示されたポインターへ指定される。
ステップ１１４８の後、デスクリプタを用いて引数をア
ンマーシャルするプロセスは完了する。

【００７４】次に図１６を参照して、ユーザー例外ルー
チンのプロセス、すなわち図１４のステップ１２６０
を、本発明の一実施例に従って説明する。このプロセス
は、例外リターンポインターが無であるか否か判定する
ステップ１２６８において始まる。例外リターンポイン
ターが無である場合、プロセスコントロールは、マッチ
するキーを求めるべくユーザー例外デスクリプタレポジ
トリをサーチするステップ１２７０へ進む。ユーザー例
外デスクリプタレポジトリは、メソッドに関連するユー
ザー例外を記述する例外デスクリプタへのポインターの
リストであって、関連する呼出しデスクリプタから得ら
れる。ステップ１２７２において、ユーザー例外レポジ
トリのサーチの結果、キーマッチが見いだされたか否か
判定される。キーマッチが見いだされなかった場合、例
外が投入され、これは、ユーザー例外レポジトリ内にユ
ーザー例外が見いだされなかったことを示し、デスクリ
プタを用いて引数をアンマーシャルするプロセスは完了
する。キーマッチが見いだされた場合、ステップ１２７
４において、例外識別子（ＩＤ）を、マッチしたキーに
関連する識別子（ＩＤ）と比較する。例外ＩＤを、マッ
チしたキーに関連するＩＤと比較した後、プロセスコン
トロールはステップ１２７６へ進み、例外ＩＤとマッチ
したキーに関連するＩＤとの比較の結果がマッチになる
か否か判定される。例外ＩＤと、マッチしたキーに関連
するＩＤとの比較の結果がマッチになった場合、ステッ
プ１２８２において送られたマーシャルバッファーへの
ポインターによって、マッチしたキーに関連する投入機
能がコールされる。投入機能は図８について既に説明し
た。機能がコールされると、ステップデスクリプタを用
いて引数をアンマーシャルするプロセスは完了する。ス
テップ１２７６において、例外ＩＤと、マッチしたキー
に関連するＩＤとがマッチしなかった場合、ステップ１
２７８において、もう一つのキーマッチを求めるべくユ
ーザー例外デスクリプタレポジトリをサーチする。次に
プロセスコントロールはステップ１２７２へループバッ
クし、そこでキーマッチが見いだされたか判定される。

【００７５】例外リターンポインターが無であるか否か
判定するステップ１２６８を参照し、例外リターンポイ
ンターが無でないと判定された場合、ステップ１２８４
において、ユーザー例外デスクリプタレポジトリ内にお
いてマッチするキーをサーチする。次にステップ１２８
６において、キーマッチが見いだされたか否か判定され
る。キーマッチが見いだされなかった場合、ステップ１
２９３においてメモリーが割当てられて初期化され、ユ
ーザー例外が見いだされなかったことが示され、例外を
マーシャルするためのメモリーが割当てられる。ステッ
プ１２９１において、割当てられた例外が例外リターン
ポインターを介して返され、デスクリプタを用いて引数
をアンマーシャルするプロセスは完了する。

【００７６】ステップ１２８６においてキーマッチが見
いだされた場合、プロセスコントロールはステップ１２
８８へ移行し、そこで、例外ＩＤを、マッチしたキーに
関連するＩＤと比較する。比較ステップ１２８８から、
プロセスコントロールはステップ１２９０へ移行し、そ
こで、例外ＩＤとマッチしたキーに関連するＩＤとの比
較の結果がマッチになるか否か判定される。もう一つの
キーマッチを求めるべくユーザー例外デスクリプタレポ
ジトリをサーチする。もう一つのキーマッチをサーチし
た後、プロセスコントロールはステップ１２８６へ戻
り、そこで、キーマッチが見いだされたか否か判定され
る。ステップ１２９０において、例外ＩＤと、マッチし
たキーに関連するＩＤが間違いなくマッチする場合、ス
テップ１２９４において、例外をアンマーシャルするた
めのメモリーが割当てられる。次にステップ１２９５に
おいて、見いだされた例外デスクリプタに関するアンマ
ーシャル機能へのポインターが無であるか否か判定され
る。ポインターが無である場合、ステップ１２９８にお
いて、関連する例外タイプコード、関連するマーシャル
バッファー、および割当てられたメモリーのアドレスを
送って、タイプコードに基づくアンマーシャル・ルーチ
ンがコールされる。タイプコードに基づくアンマーシャ
ル・ルーチンがコールされた後、プロセスコントロール
はステップ１２９１へ進み、割当てられた例外が例外リ
ターンポインターを介して返され、デスクリプタを用い
て引数をアンマーシャルするプロセスは完了する。ステ
ップ１２９５において、アンマーシャル機能へのポイン
ターが無でないと判定された場合、プロセスコントロー
ルはステップ１２９６へ進み、そこで、マッチしたキー
に関連するアンマーシャル機能へのコールが行われ、関
連するマーシャルバッファーが引数として送られる。ア
ンマーシャル機能へのコールが行われた後、プロセスコ
ントロールは、割当てられた例外をステップ１２９１に
おいて例外リターンポインターを介して返し、デスクリ
プタを用いて引数をアンマーシャルするプロセスは完了
する。

【００７７】様々なマーシャルルーチンとアンマーシャ
ルルーチンがあるものと解釈すべきである。ルーチンの
数は、用いられるトランスポートまたはプロトコルに依
存する。通常、マーシャルルーチンとアンマーシャルル
ーチンの数はトランスポートの数より少ない。上記の包
括的なマーシャルとアンマーシャルの各ルーチンは、引
数が左から右へ、および各引数内において深度優先順に
マーシャルされる、ほとんどの標準プロトコルに適して
いる。その他の包括的なマーシャルとアンマーシャルの
各ルーチンは、引数を右から左へ、および各引数内にお
いて幅優先順にマーシャルすることができる。コンパイ
ル（編集）されたマーシャリングとアンマーシャリング
の各ルーチンは普通、深度優先順を、タイプコードで解
釈されるマーシャリングとアンマーシャリングの各ルー
チンは普通、幅優先順をとる。多くの場合、コンパイル
されたマーシャルおよびアンマーシャル・ルーチンとタ
イプコード解釈されるマーシャルおよびアンマーシャル
・ルーチンの相違は、包括的ルーチン内に隠れていて、
そのため、コンパイルされたマーシャルおよびアンマー
シャルとタイプコード解釈されるマーシャルおよびアン
マーシャルのいずれが用いられるかにかかわらず、トラ
ンスポート・パスとサブコントラクト・コード・パスが
同じままであることができる。従って、多くの場合、呼
出しはトランスポートに依存すると見なすことができ
る。

【００７８】いくつかの場合に、トランスポートは、引
数間と各データタイプ内において別々のマーシャル順序
とアンマーシャル順序を必要とするプロトコルを持つこ
とができる。従って、トランスポートは、図６を参照し
て上に説明した、当該メソッドに関連する呼出しデスク
リプタ内において特定のメソッドに関する情報が利用可
能であるので、各プロトコルに適した特定のマーシャル
・ルーチンおよびアンマーシャル・ルーチンを利用する
ことができる。例えば、右から左へのマーシャル順序
は、図１３を参照して説明したような左から右へのマー
シャル順序に関して用いられるインデックス増分ループ
と逆に、インデックス減分ループによって行うことがで
きる。標準の、コンパイルされた、深度優先の、引数の
マーシャル順序およびアンマーシャル順序が、与えられ
たトランスポートまたはプロトコルに適さない場合、他
のマーシャル順序およびアンマーシャル順序、例えば、
幅優先順序を、タイプコードをもつタイプコード・イン
タープリターを用いて行うことができる。その理由は、
タイプコードがデータタイプの完全な記述、すなわち構
造を含むからである。換言すれば、この場合、異なるタ
イプコード・マーシャル・インタープリターとタイプコ
ード・アンマーシャル・インタープリターが用いられる
ので、コンパイルされたマーシャル・ルーチンとアンマ
ーシャル・ルーチンは用いられない。従って、包括的マ
ーシャル・ルーチンとアンマーシャル・ルーチンが、与
えられたトランスポートに適さない場合、マーシャル・
コンベンションまたはアンマーシャル・コンベンション
が実行できるように、十分な情報がデスクリプタ内にお
いて利用可能であり、呼出しプロセス全体はトランスポ
ートから独立していると見なすことができる。

【００７９】ダイナミック呼出しの場合、スタティック
呼出しの場合にコールされると思われるものと同じクラ
イアント表現(representation)呼出しメソッドがコール
される。ただし、ダイナミック呼出しシステムは普通、
メソッドデスクリプタ、呼出しデスクリプタ、および他
の関連するデスクリプタを、利用可能なインターフェイ
ス・レポジトリのユーザーによって与えられる情報から
構成する。ダイナミック呼出しに関しては、関連する例
外デスクリプタとパラメータデスクリプタ内にマンダト
リー・フィールドのみが与えられる。

【００８０】分散オブジェクトシステムのサーバー側
は、受信エンドポイントにおいて受信したリクエストに
応答する。サーバー側は受信エンドポイントを絶えずモ
ニターしてリクエストの受信時を判定する。サーバー呼
出しに係わるメソッドとしては、サーバー呼出しオブジ
ェクトの初期化と破棄に用いられる従来技術の構築メソ
ッドと従来技術の破棄メソッドがある。図１９を参照し
て、サーバー呼出しオブジェクトを説明する。サーバー
側に関連するその他のメソッドとしては、アンマーシャ
ルメソッド、マーシャルメソッド、およびマーシャル例
外メソッドがある。各メソッドに、関連する呼出しデス
クリプタがある。マーシャルメソッドは、図１３につい
て上に述べたように包括的マーシャルメソッドをコール
する。同様に、アンマーシャルメソッドは、図１４につ
いて上に述べたように包括的アンマーシャルメソッドを
コールする。

【００８１】次に図１７を参照して、分散オブジェクト
指向システムのサーバー側において特定の受信エンドポ
イントがリクエストを受信したとき発生するステップ
を、本発明の一実施例に従って説明する。このプロセス
はステップ２５０において始まり、ここで、リクエスト
に特有のマーシャルバッファーを作成し、受信したリク
エストをカプセル化する。作成されるマーシャルバッフ
ァーのタイプは、図２について上に説明したように、専
用エンドポイントまたはクラスター・エンドポイントで
ある。ステップ２５２において、エンドポイントのタイ
プとターゲット・オブジェクト・レファレンスに基づい
て発送ルーチンが選ばれる。関連するサブコントラクト
とトランスポートは通常、発送ルーチンの選択における
要因である。発送ルーチンを選んだ後、プロセスコント
ロールはステップ２５４へ移行し、そこで、選ばれた発
送ルーチンがコールされる。ステップ２５０において作
成されたマーシャルバッファーは、「クッキー」ととも
に適当な発送ルーチンへのコールへ送られる。クッキー
はデータ要素へのポインターである。発送ルーチンがコ
ールされる場合、そこには普通、コールの一部として送
り込まれるクロージャがある。クロージャは、クッキー
と発送ルーチンへのポインターを含む。代表的な発送ル
ーチンをコールまたは実行するプロセスを、図１８を参
照して以下に詳しく説明する。発送ルーチンへのコール
の結果、回答がマーシャルバッファ内にカプセル化され
る。最後にステップ２５６において、回答が受信エンド
ポイント上に伝達される。

【００８２】次に図１７を参照して、代表的な発送ルー
チンの実行メソッドを、本発明の一実施例に従って説明
する。ステップ１３００において、ヘッダー情報が存在
すれば、マーシャルバッファーからヘッダー情報をアン
マーシャルする。クライアントからサーバーへリクエス
トを回送するために用いられる、選ばれたトランスポー
トが、時々マーシャルバッファーからヘッダーを除去す
る。ステップ１３０２において、ターゲット・オブジェ
クト・レファレンス・データがアンマーシャルされる。
すなわち、呼出されるべきオブジェクトを識別する任意
の項目にアクセスする。次にステップ１３０４におい
て、呼出し、すなわちコールされるべきオペレーション
名がアンマーシャルされる。プロセスコントロールはス
テップ１３０４からステップ１３０６へ進み、そこで、
マーシャルバッファーからオペレーション・キーが獲得
すなわちアンマーシャルされ、適当なメソッドデスクリ
プタが作成される。ターゲット・オブジェクト・レファ
レンス・データ、オペレーション名、およびオペレーシ
ョン・キーがアンマーシャルされる順序は、ステップの
順序が、用いられる特定のプロトコルに依存するので、
重要ではないと理解すべきである。

【００８３】ステップ１３０８において、発送ルーチン
に関連するトランスポートとサブコントラクトに適した
サーバー呼出しオブジェクトが作成される。サーバー呼
出しオブジェクトの作成に必要な情報は、ターゲット・
オブジェクト・レファレンス・データ、オペレーション
名、およびオペレーションキーをアンマーシャルするス
テップにおいて集められる情報である。サブコントラク
トは、作成されるべきサーバー呼出しオブジェクトの適
当な種類を黙示的に(implicitly)決定する。すなわち、
与えられたサブコントラクトは、同じトランスポートエ
ンドポイント、またはオブジェクトに関して作成される
サーバー呼出しオブジェクトの種類の選択に常に首尾一
貫している(consistent)。サーバー呼出しオブジェクト
の構造を、図１８について以下に説明し、サーバー呼出
しオブジェクトの作成に関するステップを図１９につい
て以下に説明する。

【００８４】ステップ１３０８においてサーバー呼出し
オブジェクトを作成した後、プロセスコントロールはス
テップ１３１０へ移行し、そこで、アンマーシャルされ
たターゲット・オブジェクト・レファレンス・データに
基づいて発送クロージャが識別される。発送クロージャ
の識別用には、ハッシュテーブルまたはユーザーによっ
て与えられるルーチンへのコールの使用を含む多くのメ
ソッドがある。発送クロージャは、ターゲット・オブジ
ェクト・レファレンスのオブジェクトキーをキーとして
用いて「ルックアップ」、すなわち識別することができ
る。関連するサブコントラクトとトランスポートは通
常、発送ルーチンの選択における要因であると理解すべ
きである。識別された発送クロージャ、または発送ルー
チンは、スケルトン発送機能へのポインターと、この場
合はサーバントへのポインターであるクッキーを持つ。

【００８５】ステップ１３１２において、識別されたク
ロージャー、および従って、識別されたスケルトンは、
ステップ１３１０において作成されたサーバー呼出しオ
ブジェクトへのポインターとクッキーを用いて呼出され
る。ステップ１３１４において、識別された発送クロー
ジャが呼出されたとき例外が投入されたか否か判定され
る。例外が投入されたと判定された場合、プロセスコン
トロールはステップ１３１６へ進み、そこで、投入され
たまたは返された例外を、引数として送り込んで、サー
バー呼出しオブジェクトのマーシャル例外メソッドが呼
出される。次にステップ１３１８において、サーバー呼
出しオブジェクトが破壊され、代表的な発送ルーチンを
実行するプロセスは完了する。サーバー呼出しオブジェ
クトを破壊するステップには、汎用コールバック・クロ
ージャへのコールが係わる。このクロージャは、マーシ
ャリング後、割当てられたメモリーをダイナミックスケ
ルトンが開放することを可能にする。ステップ１３１４
において例外が投入されなかったと判定された場合、プ
ロセスコントロールは直接ステップ１３１８へ進み、そ
こで、サーバー呼出しオブジェクトが破壊される。サー
バー呼出しオブジェクトが破壊された後、代表的な発送
ルーチンを実行するプロセスは完了する。発送クロージ
ャの呼出し、すなわちスケルトンの呼出しに係わるステ
ップを、図２０と図２１を参照して、以下に説明する。

【００８６】次に図１８を参照し、代表的なサーバー呼
出しオブジェクトの構造を、本発明の一実施例に従って
説明する。サーバー呼出しオブジェクト１４０８は、マ
ーシャルバッファー１４１０へのポインター、メソッド
デスクリプタ１４１２へのポインター、および呼出しデ
スクリプタへのポインター１４１４を含むデータ構造で
ある。サーバー呼出しオブジェクト１４０８は、分散オ
ブジェクトシステムのサーバー側においてメソッドの呼
出しに用いられる。具体的に、サーバー呼出しオブジェ
クト１４０８は、メソッドコールを実行するため、サー
バーが用いる機能性を含む。サーバー呼出しオブジェク
ト１４０８に係わるメソッドは他のメソッドによって上
書き(overwritten)できるものと解釈すべきである。こ
こに説明した実施例においては、サーバー呼出しオブジ
ェクトは、マーシャルメソッド、アンマーシャルメソッ
ド、およびマーシャル例外メソッドを持つＣ＋＋オブジ
ェクト、すなわちデータ構造である。

【００８７】サーバー呼出しオブジェクト１４０８はオ
プションとして、マーシャルバッファー１４１０へのポ
インター、メソッドデスクリプタ１４１２へのポインタ
ー、および呼出しデスクリプタへのポインター１４１４
以外の要素を含むことができる。例えば、サーバー呼出
しオブジェクト１４０８は、コンテクストが存在すれ
ば、コンテクスト１４１６へのポインター、および、コ
ールバック機能へのポインターとデータ要素、すなわち
クッキーへのポインターを含むコールバッククロージャ
をも含むことができる。ダイナミック・スケルトンイン
・ターフェイス（ＤＳＩ）は、ダイナミック・スケルト
ン呼出し中に割当てられ、割当てられたメモリーが、マ
ーシャルされねばならないかまたはマーシャリングの結
果のために必要である結果またはデスクリプタを含むの
で破壊または返却され得なかったメモリーを破壊および
再割り当てするプロセスを助けるために、コールバック
クロージャ１４１８を用いることができる。サーバー呼
出しオブジェクト１４０８は、システムの要件次第で追
加のポインターと機能を含むことができるものと解釈す
べきである。

【００８８】次に図１９を参照して、サーバー呼出しオ
ブジェクトの作成メソッドを、本発明の一実施例に従っ
て説明する。すなわち、図１９は図１７のステップ１３
０８の全体図である。ステップ１４０２において、サー
バー呼出しオブジェクトは、サーバー呼出しオブジェク
トのコンストラクターメソッドをコールすることによっ
て初期化される。コンストラクターメソッドはデータ構
造の初期化に広く用いられており、当業者には周知であ
る。サブコントラクトはコンストラクターメソッドを用
いてサーバー呼出しオブジェクトを作成する。サブコン
トラクトは、作成されるべきサーバー呼出しオブジェク
トのタイプを判定する。具体的に、サブコントラクトは
任意のオプショナル要素、例えば図１８について説明し
たような、サーバー呼出しオブジェクトの一部として含
めることのできる、コンテクストへのオプショナル・ポ
インターを判定する。しかし、この判定はサブコントラ
クト内において黙示的である。すなわち、与えられたサ
ブコントラクトは、同じトランスポート・エンドポイン
ト、すなわちオブジェクトに関して常に同種のサーバー
呼出しオブジェクトを作成する。 サーバー呼出しオブ
ジェクトが初期化された後、ステップ１４０４におい
て、適当なマーシャルバッファー、すなわちサーバー呼
出しオブジェクトに関連するマーシャルバッファーへの
ポインターがフィルイン（記入）される(filled in)。
次にステップ１４０６において、サーバー呼出しオブジ
ェクトに関連するメソッドデスクリプタへのポインター
がフィルインされる。いくつかの実施例において、メソ
ッドデスクリプタへのポインターは、マーシャルバッフ
ァーへのポインターがフィルインされる前にフィルイン
されてもよいと解釈すべきである。サーバー呼出しオブ
ジェクトは呼出しデスクリプタへのポインターを含む
が、このポインターは、サーバー呼出しオブジェクトが
作成された後、スケルトンによってフィルインされる。
メソッドデスクリプタへのポインターがフィルインされ
た後、サーバー呼出しオブジェクトを作成するステップ
は完了する。

【００８９】次に図２０を参照して、発送クロージャ、
またはスケルトンを呼出すステップ、すなわちスタティ
ックスケルトンである図１７のステップ１３１２を、本
発明の一実施例に従って説明する。サーバー呼出しオブ
ジェクトへのポインターとサーバントへのポインターが
スケルトンを呼出すためのコールへ送り込まれると、ス
テップ１５０２において、ほとんどのプログラミング言
語において標準的なオペレーションであるコントロール
の切替えが発生する。サーバー呼出しオブジェクトに関
連するメソッドデスクリプタを用いて呼出しデスクリプ
タが識別された後、プロセスコントロールはステップ１
５０４へ進み、そこで呼出しデスクリプタへのポインタ
ーがフィルインされる。呼出しデスクリプタへのポイン
ターは上記のようにサーバー呼出しオブジェクトの一部
である。呼出しデスクリプタへのポインターがフィルイ
ンされた後、ステップ１５０６においてメモリーが割当
てられる。スケルトンは、割当てるべきメモリーの量を
決定する能力を持つ。イン・パラメータ・アドレス・リ
スト、すなわちメモリー場所リストが次にステップ１５
０８において設定される。イン・パラメータ・リスト
は、イン・引数がマーシャルされるべき場所へのポイン
ターのリストからなる。

【００９０】イン・パラメータ・リストが設定された
後、プロセスの流れはステップ１５１０へ移行し、そこ
で、サーバー呼出しオブジェクトに関連するアンマーシ
ャルメソッドがイン・パラメータ・リストとともにコー
ルされる。コールされたアンマーシャルメソッドは特定
のサーバー呼出しオブジェクトに特有であって、ＩＮ Ｄ
ＥＳＣ、ＩＮ ＤＥＳＣ ＣＯＵＮＴ、およびイン・パ
ラメータリストを送って、最終的に図１４について上に
説明した一般的なアンマーシャリング・ルーチン、また
は同等のルーチンをコールする。ステップ１５１２にお
いて、メソッドデスクリプタによって識別されたサーバ
ントメソッドがコールされる。サーバントメソッドへの
コールによって例外が投入された場合、プロセスの流れ
は、図２２のサーバー呼出しオブジェクトのマーシャル
例外メソッドの呼出しステップ１３１６へ進む。例外が
投入されなかった場合、サーバントメソッドへのコール
の後、ステップ１５１４においてサーバントメソッドか
ら返信(return)を受取る。サーバントメソッドはまた
「コールされた」メソッドとしても知られているかも知
れない。ステップ１５１６において、アウト・パラメー
タのリストが設定される。アウト・パラメータのリスト
は、アウト・引数を保持している場所へのポインターの
リストからなる。アウト・パラメータのリストが設定さ
れた後、ステップ１５１８においてアウト・パラメータ
のリストとともにサーバー呼出しオブジェクトのマーシ
ャルメソッドへコールが行われる。マーシャルメソッド
はＯＵＴ ＤＥＳＣ、ＯＵＴ ＤＥＳＣ ＣＯＵＮＴ、お
よびアウト・パラメータリストを送って、最終的に図１
２について上に説明した一般的なマーシャルメソッド、
または同等のメソッドをコールする。マーシャルメソッ
ドへのコールが行われた後、スケルトンを呼出すプロセ
スは完了する。

【００９１】次に図２１を参照して、発送クロージャま
たはスケルトンの呼出しメソッド、すなわちダイナミッ
ク・スケルトン・インターフェイス（ＤＳＩ）における
図１７のステップ１３１２を、本発明の一実施例に従っ
て説明する。まず、サーバー呼出しオブジェクトへのポ
インターとサーバントアドレスへのポインターをコール
へ送ってＤＳＩスケルトンを呼出す。次にステップ１６
０２において、サーバー呼出しオブジェクトによって指
示されたメソッドデスクリプタによって識別されたメソ
ッドに関する呼出しデスクリプタを作成または獲得す
る。デスクリプタの作成に必要な情報は、デスクリプタ
・データ構造としても知られ、インターフェイス・レポ
ジトリ内に含まれている。インターフェイスに関連する
情報を保存しているインターフェイス・レポジトリは、
呼出しデスクリプタをはじめ、必要なすべてのデスクリ
プタを作成するのに十分な情報を集めるため、精査され
る(traversed)。この情報は次にデスクリプタを作成す
るためＤＳＩサブシステムによって用いられる。デスク
リプタは、必要になったとき、すなわち、インターフェ
イスレポジトリ内の情報を用いてメソッドが呼出された
とき作成されるものと理解すべきである。ダイナミック
の、またはタイプコードにより解釈される、マーシャリ
ングとアンマーシャリングは普通、予めコンパイルされ
たメソッドと呼出しデスクリプタを用いない。

【００９２】呼出しデスクリプタが作成または獲得され
た後、プロセスの流れはステップ１６０４へ移行し、そ
こで、サーバー呼出しオブジェクト内に含まれている呼
出しデスクリプタがフィルイン(filled in 記入)され
る。次にステップ１６０６において、呼出しデスクリプ
タによって指示されたパラメータ・デスクリプタによっ
て与えられたタイプコードを用いて、引数用のメモリー
が割当てられる。受信プロセスによって割当てられねば
ならないメモリーの量に関する情報はタイプコードから
計算することができるので、パラメータ・デスクリプタ
内のサイズコードを明示的に(explicitly)与える必要は
ない。

【００９３】メモリーが割当てられた後、ステップ１６
０８においてイン・パラメータ・リストが設定される。
すなわち、イン・引数がアンマーシャルされるべきポイ
ンターのリストが作成される。つぎに、ステップ１６１
０において、サーバー呼出しオブジェクトに関するアン
マーシャルメソッドへのコールが、引数とイン・パラメ
ータ・リストを用いて行われる。ステップ１６１２にお
いてイン・パラメータ・リストを用いてアンマーシャル
メソッドがコールされると、ＤＳＩサーバントの発送メ
ソッドへのコールが行われる。次にプロセスコントロー
ルはステップ１６１４へ進み、そこで、サーバントメソ
ッドからのリターン（回答）が受信される。サーバント
メソッドからのリターン（回答）の受信後、ステップ１
６１５において、例外が返されたか否か、判定される。
例外が返されたと判定された場合、ステップ１６２０に
おいてサーバー呼出しオブジェクトのマーシャル例外メ
ソッドが、例外において返された引数を用いて、コール
される。マーシャル例外メソッドへのコールが行われる
と、ＤＳＩスケルトンを呼出すプロセスは完了する。ス
テップ１６１５において、例外が返されなかったと判定
された場合、プロセスの流れはステップ１６１６へ進
み、そこで、アウト・パラメータ・リスト、すなわち、
アウト・引数がアンマーシャルされるべき場所へのポイ
ンターのリストが設定される。アウト・パラメータ・リ
ストが設定された後、ステップ１６１８において、アウ
ト・パラメータ・リストを引数として用いて、サーバー
呼出しオブジェクトのマーシャルメソッドが呼出され
る。マーシャルメソッドの呼出し後、ＤＳＩスケルトン
を呼出すプロセスは完了する。

【００９４】サブコントラクトとトランスポートに係わ
るコードは、コンパイルされたマーシャリングおよびア
ンマーシャリングと、解釈されたマーシャリングおよび
アンマーシャリングの間の相違を意識しないものと理解
すべきである。更に、ダイナミックスケルトンとスタテ
ィックスケルトンは、当初サーバー呼出しオブジェクト
によって定義された同じインターフェイスを利用する。
サーバー呼出しオブジェクトに関連するマーシャルメソ
ッドは、最終的に包括的なマーシャルメソッドまたは同
等のメソッドをコールする。同様に、アンマーシャルメ
ソッドは、最終的に包括的なアンマーシャルメソッドま
たは同等のメソッドをコールする。引数のマーシャルと
アンマーシャルに関する詳細は、包括的なマーシャルメ
ソッドとアンマーシャルメソッドまたは同等のメソッド
内に埋め込まれて、すなわち隠されている。しかし、し
かしサーバー呼出しオブジェクトのマーシャルメソッド
とアンマーシャルメソッドには、多くの種類があり、そ
の数は、用いられる特定のサブコントラクトとトランス
ポートに依存する。

【００９５】上記本発明は、コンピュータシステムに保
存されているデータに係わる様々なプロセスステップを
用いる。これらのステップは、物理量の物理的操作を必
要とするステップである。通常、必ずしも常にではない
が、これらの量は、保存、転送、結合、比較、その他の
操作を受けることのできる電気信号または磁気信号の形
をとる。それは時として、主に、これらの信号にビット
(bits)、値(values)、要素(elements)、変数(bariabe
s)、文字(characters)、データ構造(data structures)
などとして広く用いられるという理由で便利である。し
かし、これら用語や類似の用語は、適当な物理量に関連
づけられて、これらの量に貼り付けられる便利なラベル
に過ぎないことを忘れてはならない。

【００９６】更に、実行される操作はしばしば、識別(i
dentifying)、実行(running)、または比較(comparing)
と称される。本発明の一部をなし、ここに述べられる任
意のオペレーションにおいて、これらのオペレーション
はマシーンオペレーションである。本発明のオペレーシ
ョンの実行に有用なマシーンには、汎用ディジタルコン
ピュータまたはその他類似の装置がある。あらゆる場合
に忘れてならないのは、コンピュータ操作における操作
メソッドとコンピューテーション自体のメソッドとの区
別である。本発明は、電気信号またはその他の物理信号
を処理して他の必要な物理信号を発生させるため、コン
ピュータを操作するためのメソッドステップに関する。

【００９７】本発明はまた、これらのオペレーションを
実行するための装置にも関する。この装置は、必要な目
的のための特製品であっても、あるいはコンピュータ内
に保存されているコンピュータプログラムによって選択
的に起動される、あるいは再構成される(reconfigured)
汎用コンピュータであってもよい。本明細書に提示した
プロセスは、本質的に特定のコンピュータやその他の特
定の装置に関連するものではない。特に、本明細書の教
示に従って書かれるプログラムとともに様々な汎用マシ
ーンを使うことができ、あるいは、必要なメソッドステ
ップの実行するため更に専用化した装置を作れば更に便
利である。これら様々なマシーンの必要構造は上記説明
から明らかであろう。

【００９８】本発明は更に、コンピュータによって実行
される様々なオペレーションのためのプログラムインス
トラクションを含む、コンピュータによって読むことの
できる媒体にも関する。この媒体とプログラムインスト
ラクションは、本発明の目的のために特別に設計製作さ
れたものでも、あるいはコンピュータソフトウェアの当
業者に周知かつ利用可能な種類のものであってもよい。
コンピュータによって読むことのできる媒体には、ハー
ドディスク、フロッピーディスク、および磁気テープな
どの磁気媒体；フロプティカルディスクのような磁気光
媒体；および、リードオンリーメモリー装置（ＲＯＭ）
およびランダムアクセスメモリー（ＲＡＭ）のような、
プログラムインストラクションの保存と実行のために特
別構成されたハードウェア装置がある。プログラムイン
ストラクションの例としては、コンパイラーによって作
られるようなマシーンコード、およびインタープリタ(i
nterpreter)を用いるコンピュータによって実行される
ハイレベルコードを含むファイルなど、両方がある。

【００９９】図２２は、本発明の一実施例による代表的
なコンピュータシステムを示す。コンピュータシステム
５００は、主記憶装置(primary storage)５０４（普通
はリードオンリーメモリーすなわちＲＯＭ）、および主
記憶装置(primary storage)５０６（普通はランダムア
クセスメモリー、すなわちＲＡＭ）を含む記憶装置(sto
rage devices)に接続された適当数のプロセッサー（中
央処理装置、すなわちＣＰＵ）を含む。この技術分野で
は周知のように、ＲＯＭ ５０４は、データとインスト
ラクションを一方向にＣＰＵに送るように作用し、ＲＡ
Ｍ ５０６は普通、データとインストラクションを双方
向に送るのに用いられる。これら両主記憶装置は、上記
の任意の適当なコンピュータ読取り可能な媒体を含むこ
とができる。大容量記憶装置(mass storage device)５
０８もＣＰＵ ５０２に双方向的に接続して、追加の記
憶容量を提供し、上記の任意の適当なコンピュータ読取
り可能な媒体を含むことができる。大容量記憶装置５０
８は、プログラム、データ等を記憶するために用いるこ
とができ、普通は主記憶装置５０４、５０６より遅いハ
ードディスクのような二次記憶媒体(secondary storage
medium)である。大容量記憶装置５０８は、磁気または
紙テープリーダーまたはその他周知の装置であればよ
い。大容量記憶装置５０８に保持された情報は、バーチ
ュアルメモリー(virtual memory)としてのＲＡＭ ５０
６の一部として標準的なメソッドで適宜組み入れること
ができることが理解できる。ＣＤ−ＲＯＭ ５１４のよ
うな特定の大容量記憶装置もデータを一方向にＣＰＵへ
送ることができる。

【０１００】ＣＰＵ ５０２はまた、一つ以上の入出力
装置を備えたインターフェイス５１０に接続することが
でき、入手力装置としては、限定はしないが、ビデオモ
ニター、トラックボール、マウス、キーボード、マイク
ロホン、タッチ感知ディスプレイ、トランスデューサー
カードリーダー、磁気または紙テープリーダー、タブレ
ット、スタイラス、音声または手書き認識装置、または
もちろんコンピュータのような他の周知の入力装置があ
る。最後に、ＣＰＵ ５０２ は、コンピュータまたは一
般的に５１２で示したネットワーク接続を用いた遠隔通
信ネットワークにオプション的に接続することができ
る。そのようなネットワーク接続を用いると、上記メソ
ッドステップの実行中に、ＣＰＵがネットワークから情
報を受け取ったり、あるいは情報をネットワークへ出力
したりすることが考えられる。上記装置や材料はコンピ
ュータのハードウェアやソフトウェアの技術の当業者に
はなじみである。

【０１０１】本発明の好ましい実施例を一例のみ説明し
たが、本発明はその精神または範囲からかけ離れること
なく、他の多くの具体的形態において実施することがで
きるものと理解すべきである。上記実施例においては、
メソッドデスクリプタ、呼出しデスクリプタ、パラメー
タ・デスクリプタ、および例外デスクリプタに関する具
体的なデータ構造を説明した。これらのデータ構造を本
発明の範囲内において大幅に変更し得ることは明らかで
ある。同様に、引数をマーシャルおよびアンマーシャル
するメソッドも、本発明の範囲内において大幅に変更し
得ることは明らかである。例えば、引数をマーシャルお
よびアンマーシャルするメソッドの順序を入れ替えるこ
とができる。各ステップも、本発明の精神または範囲か
らかけ離れることなく、削除または追加が可能である。

【０１０２】更に、いくつかの状況において、共通のオ
ブジェクト、例えばパラメータに関連するマーシャルメ
ソッドおよびアンマーシャルメソッドを一つのメソッド
に結びつけることができる。マーシャルメソッドとアン
マーシャルメソッドが同一である場合、機能コールにお
ける引数の追加を用いて、マーシャリングまたはアンマ
ーシャリングの要否を指定することができる。マーシャ
ルメソッドとアンマーシャルメソッドが個別である場
合、新しい機能を作成して両方のメソッドを実行するこ
とができる。この新機能は、求められたメソッドがマー
シャルであるかアンマーシャルであるかを指定する機能
コールへの引数を含むことができる。単一の機能がマー
シャルとアンマーシャルの両方を表わしている場合、マ
ーシャルメソッドとアンマーシャルメソッドへのポイン
ターを持つタイプコードおよびデスクリプタのデータ構
造においては、一つのポインターを用いて単一の機能を
指示することができる。ブール値またはフラッグを、デ
スクリプタ・データ構造がマーシャリングまたはアンマ
ーシャリングを必要としているか否か示すデスクリプタ
・データ構造の中へ、実行することができる。従って、
上記実施例は説明的であって限定的ではないと解釈すべ
きであり、本発明は下記特許請求の範囲とその同等の全
範囲によって定義される。

【図面の簡単な説明】

【図１】分散オブジェクトシステムの象徴的概観図であ
る。

【図２】クライアントからのリクエストが、分散オブジ
ェクト指向システムのクライアント側およびサーバー側
の構造と、分散オブジェクト指向システムのクライアン
ト側およびサーバー側との間のインターフェイスを介し
て回送される様子を表すダイヤグラム図である。

【図３】オブジェクトレファレンスのダイヤグラム図で
ある。

【図４】本発明の一実施例によるメソッドデスクリプタ
のダイヤグラム図である。

【図５】本発明の一実施例による呼出しデスクリプタの
ダイヤグラム図である。

【図６】本発明の一実施例によるパラメータデスクリプ
タのダイヤグラム図である。

【図７】本発明の一実施例による例外デスクリプタのダ
イヤグラム図である。

【図８】本発明の一実施例による分散オブジェクト指向
システムのクライアント側における呼出しメソッドへの
コールの説明図である。

【図９】本発明の一実施例による、オブジェクトの呼び
出しに係れるステップを示すプロセス流れ図である。

【図１０】本発明の一実施例によるリモートスタブの実
行に係わるステップを示すプロセス流れ図である。

【図１１】本発明の一実施例によるクライアント表現の
呼出しメソッドをコールするリモートスタブに係わるス
テップを示すプロセス流れ図である。

【図１２】本発明の第一実施例によるデスクリプタを用
いる引数のマーシャリングに係わるステップを示プロセ
ス流れ図である。

【図１３】本発明の一実施例によるデスクリプタを用い
る引数のアンマーシャリングに係わるステップを示プロ
セス流れ図である。

【図１４】本発明の一実施例によるデスクリプタを用い
る引数の包括的なアンマーシャルに係わるステップを示
プロセス流れ図である。

【図１５】本発明の一実施例によるユーザー例外ルーチ
ンのコールに係わるステップを示プロセス流れ図であ
る。

【図１６】本発明の一実施例による、特定の受信エンド
ポイントにリクエストが受信されたとき分散オブジェク
ト指向システムのサーバー側に発生するステップを示プ
ロセス流れ図である。

【図１７】本発明の一実施例による代表的な発送ルーチ
ンの実行に係わるステップを示プロセス流れ図である。

【図１８】本発明の一実施例によるサーバー呼出しオブ
ジェクトのダイヤグラム図である。

【図１９】本発明の一実施例によるサーバー呼出しオブ
ジェクトの作成に係わるステップを示プロセス流れ図で
ある。

【図２０】本発明の一実施例によるスタティックである
スケルトンの呼出しに係わるステップを示プロセス流れ
図である。

【図２１】本発明の一実施例によるダイナミック・スケ
ルトン・インターフェイスにおけるスケルトンの呼出し
に係わるステップを示プロセス流れ図である。

【図２２】本発明による代表的なコンピュータシステム
を示す図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ピーター ビー． ケスラー アメリカ合衆国， カリフォルニア州， パロ アルト， ヴァードサ ドライヴ 4121 (72)発明者 デイヴィッド エム． ブローネル アメリカ合衆国， カリフォルニア州， パロ アルト， パーク ブルヴァード 2569， ナンバーティー−201

Claims (35)

【特許請求の範囲】
1. 【請求項１】異なるオブジェクト間の通信を容易にする
   ためのオブジェクトリクエストブローカーを利用する分
   散オペレーティング環境で使用されるデスクリプタ・デ
   ータ構造であって、 該デスクリプタ・データ構造に関連するエンティティを
   記述するように構成されタイプコードインジケータ、 該エンティティをマーシャルするのに適したマーシャル
   機能を識別するように構成されたマーシャル機能識別
   子、および該エンティティをアンマーシャルするのに適
   したアンマーシャル機能を識別するように構成されたア
   ンマーシャル機能識別子、を含むデスクリプタ・データ
   構造。
2. 【請求項２】該エンティティの期待される使用の性質を
   示す処理方向を識別するように構成された方向インジケ
   ータを含み、該方向インジケータの潜在的状態は、該エ
   ンティティがクライアントからサーバーへの引数であり
   得ることを示すイン方向状態と、該エンティティが該サ
   ーバーから該クライアントへの引数であり得ることを示
   すアウト方向状態と、該エンティティが該クライアント
   から該サーバーへと該クライアントから該サーバーへの
   両方の引数であり得ることを示すイン／アウト方向状態
   と、該エンティティがコールリターン状態アウト方向状
   態を更に含む請求項１に記載のデスクリプタ・データ構
   造。
3. 【請求項３】該エンティティ用の名前を提供する少なく
   とも一つのネームインジケータ、該エンティティを受け
   取るために受取プロセスによって割り当てられるべきメ
   モリの量を示すサイズインジケータ、該エンティティ用
   のローカルネームを提供するように構成されたキー、該
   エンティティを一義的に識別するように構成されたレポ
   ジトリ識別子、および投入機能(throw function)がコー
   ルされたときに該エンティティの性質を規定するように
   構成された投入機能を識別するように構成された投入機
   能識別子、を更に含む請求項１または２に記載のデスク
   リプタ・データ構造。
4. 【請求項４】該デスクリプタ・データ構造がパラメータ
   デスクリプタである請求項１〜３のいずれかに記載のデ
   スクリプタ・データ構造。
5. 【請求項５】該デスクリプタ・データ構造が例外デスク
   リプタである請求項１〜３のいずれかに記載のデスクリ
   プタ・データ構造。
6. 【請求項６】異なるオブジェクト間の通信を容易にする
   ためのオブジェクトリクエストブローカーを利用する分
   散オペレーティング環境で使用される例外デスクリプタ
   データ構造であって、該例外デスクリプタデータ構造
   が、 関連例外を記述するように構成されたタイプコードイン
   ジケータ、および投入機能がコールされたときに該例外
   の性質を規定するように構成された投入機能を識別する
   ように構成された投入機能インジケータ、を含む例外デ
   スクリプタ・データ構造。
7. 【請求項７】該パラメータをマーシャルするのに適した
   マーシャル機能を識別するように構成されたマーシャル
   機能識別子、および該パラメータをアンマーシャルする
   のに適したアンマーシャル機能を識別するように構成さ
   れたアンマーシャル機能識別子を更に含む請求項６に記
   載の例外デスクリプタ・データ構造。
8. 【請求項８】該例外用のローカルネームを提供するよう
   に構成されたキーを備えた請求項７に記載の例外デスク
   リプタ・データ構造。
9. 【請求項９】該例外を一義的に識別するように構成され
   たレポジトリ識別子を更に含む請求項６、７または８に
   記載の例外デスクリプタ・データ構造。
10. 【請求項１０】異なるオブジェクト間の通信を容易にす
    るためのオブジェクトリクエストブローカーを利用する
    分散オペレーティング環境で使用される呼出デスクリプ
    タデータ構造であって、該呼出デスクリプタデータ構造
    が、 呼出経路タイプを識別するように構成されたコンパイル
    フラグを更に含み、 該コンパイルされたフラグの第１状態は、該呼出経路タ
    イプが、該呼出の促進のために必要なマーシャルおよび
    アンマーシャル機能をプレコンパイル(precompiled) し
    たスタティックな、コンパイルされた呼出(compiled in
    vocation) であることを示すと共に、該コンパイルされ
    たフラグの第２状態は、該呼出経路タイプが、該呼出の
    促進のために必要なマーシャルおよびアンマーシャル機
    能をプレコンパイルしないダイナミックな、タイプコー
    ドで解釈された呼出(typecode interpreted invocatio
    n) であることを示す、呼出デスクリプタ・データ構
    造。
11. 【請求項１１】該呼出デスクリプタ・データ構造に関連
    するパラメータの特性を記述するパラメータデスクリプ
    タ・データ構造のアレイへのポインタ、および該呼出デ
    スクリプタ・データ構造に関連する例外の特性を記述す
    る例外デスクリプタ・データ構造へのポインタ（複数）
    のアレイへのポインタ（単数）を更に含む請求項１０に
    記載の呼出デスクリプタ・データ構造。
12. 【請求項１２】該呼出デスクリプタ・データ構造に関連
    するパラメータの数を示すデスクリプタカウンタを更に
    含む請求項１０または１１に記載の呼出デスクリプタ・
    データ構造。
13. 【請求項１３】該呼出デスクリプタ・データ構造に関連
    するバッファをクリアーするのに役立つ再初期化機能へ
    のポインタ、および該呼出デスクリプタ・データ構造に
    関連するメソッドに関係する情報を含むコンテクストデ
    スクリプタを更に含む請求項１０〜１２のいずれかに記
    載の呼出デスクリプタ・データ構造。
14. 【請求項１４】分散クライアント／サーバー・ベースの
    コンピューティングシステムにおいて、遠隔的に配置さ
    れたオブジェクトをコールするメソッドであって、 クライアントプロセス内でリクエストを受け取るステッ
    プ、 該リクエストをマーシャルするために用いられる、該リ
    クエストに適したトランスポート、を選択するステッ
    プ、 該リクエストをカプセル化するために用いられる、該選
    択されたトランスポートに適したマーシャルバッファ、
    を作成するステップ、 該マーシャルメソッドがタイプコードで解釈されたかコ
    ンパイルされたかを示すために用いられるコンパイルさ
    れたフラグを含む、マーシャルメソッドを利用したデス
    クリプタ・データ構造、を用いて引数をマーシャルする
    ステップ、および該コンパイルされたフラグがセットさ
    れるか否かを決定するステップであって、該コンパイル
    されたフラグがセットされると決定されたときは、該引
    数マーシャリングステップは、該リクエストに関連する
    該引数に関連するマーシャルメソッドを呼び出すことに
    よって達成されると共に、該コンパイルされたフラグが
    セットされないと決定されたときは、該引数マーシャリ
    ングステップは、該引数をタイプコードマーシャリング
    ルーチンにパスしてタイプコードマーシャリングルーチ
    ンを呼び出すことによって達成されるように成したステ
    ップ、を含むメソッド。
15. 【請求項１５】分散クライアント／サーバー・ベースの
    コンピューティングシステムにおいて、遠隔的に配置さ
    れたオブジェクトをコールするメソッドであって、 クライアントプロセス内で、アドレス内の場所に格納さ
    れた少なくとも一つの引数を含むリクエストを受け取る
    ステップ、 該リクエストに適したトランスポートを選択するステッ
    プ、 該リクエストをカプセル化するために用いられる、該選
    択されたトランスポートに適したマーシャルバッファ、
    を作成するステップ、 該リクエストがタイプコードで解釈されたかコンパイル
    されたかを示すために用いられるコンパイルされたフラ
    グを含む呼出デスクリプタ・データ構造と複数のパラメ
    ータデスクリプタとを含むデスクリプタ・データ構造を
    使って、該リクエストの中の該引数をマーシャルするの
    に適したマーシャル機能を選択するステップ、 該コンパイルされたフラグがセットされるか否かを決定
    するステップ、および該引数をマーシャルするステップ
    であって、該コンパイルされたフラグがセットされると
    決定されたときは、該引数マーシャリングステップは、
    該引数に関連するパラメータデスクリプタによって識別
    されたマーシャルメソッドを呼び出すことによって達成
    されると共に、該コンパイルされたフラグがセットされ
    ないと決定されたときは、該引数マーシャリングステッ
    プは、タイプコード解釈を使用して識別されたマーシャ
    リングメソッドを呼び出すことによって達成されるよう
    に成したステップ、を含むメソッド。
16. 【請求項１６】該デスクリプタ・データ構造を使って該
    リクエストの中の該引数をアンマーシャルするのに適し
    たアンマーシャル機能を選択するステップ、および該コ
    ンパイルされたフラグがセットされるか否かを決定する
    ステップであって、該コンパイルされたフラグがセット
    されると決定されたときは、該引数アンマーシャリング
    ステップは、該引数に関連するパラメータデスクリプタ
    によって識別されたアンマーシャルメソッドを呼び出す
    ことによって達成されると共に、該コンパイルされたフ
    ラグがセットされないと決定されたときは、該引数アン
    マーシャリングステップは、タイプコード解釈を使用し
    て識別されたアンマーシャルメソッドを呼び出すことに
    よって達成されるように成したステップを更に含む請求
    項１５に記載のメソッド。
17. 【請求項１７】該パラメータデスクリプタによって識別
    された該マーシャルメソッドが該引数をパスされると共
    に、タイプコードの解釈を使って識別された該マーシャ
    ルメソッドが該引数と関連タイプコードとをパスされる
    請求項１５または１６に記載のメソッド。
18. 【請求項１８】該マーシャルメソッドの一つにパスされ
    た各引数が、該引数を格納するメモリ場所を定めるアド
    レスの形をとる請求項１７に記載のメソッド。
19. 【請求項１９】該パラメータデスクリプタによって識別
    された該アンマーシャルメソッドが該引数をパスされる
    と共に、タイプコードの解釈を使って識別された該アン
    マーシャルメソッドが該引数と関連タイプコードとをパ
    スされる請求項１５〜１８のいずれかに記載のメソッ
    ド。
20. 【請求項２０】該アンマーシャルメソッドの一つにパス
    された各引数が、該引数を格納するメモリ場所を定める
    アドレスの形をとる請求項１９に記載のメソッド。
21. 【請求項２１】該リクエストがそれに関連する一つ以上
    の引数を有するときに、該コンパイルされたフラグがセ
    ットされると決定されたときは、該引数マーシャリング
    ステップは、該引数の各々に関連するマーシャルメソッ
    ドを逐次呼び出すことによって達成されると共に、該コ
    ンパイルされたフラグがセットされないと決定されたと
    きは、該引数マーシャリングステップは、該引数をそれ
    らの関連タイプコードマーシャリングルーチンにパスし
    て該引数の各々に関連するタイプコードマーシャリング
    ルーチンを逐次呼び出すことによって達成される請求項
    １５〜２０のいずれかに記載のメソッド。
22. 【請求項２２】該リクエストを該選択されたトランスポ
    ートを介して、サーバープロセスに関連する識別された
    エンドポイントまで伝送するステップ、および回答を該
    サーバープロセスから受け取るステップを更に含む請求
    項１５〜２１のいずれかに記載のメソッド。
23. 【請求項２３】異なるオブジェクト間の通信を容易にす
    るためのオブジェクトリクエストブローカーを利用する
    分散オペレーティング環境でメソッドコールを実行する
    場所に使用されるサーバー呼出オブジェクトであって、 該サーバー呼出オブジェクト用の関連マーシャルバッフ
    ァを識別するように構成された第１ポインタ、 サーバー呼出オブジェクト用の関連メソッドデスクリプ
    タを識別するように構成された第２ポインタ、および引
    数を含む、該サーバー呼出オブジェクト用の関連呼出デ
    スクリプタ、を識別するように構成された第３ポイン
    タ、を含むサーバー呼出オブジェクト。
24. 【請求項２４】該サーバー呼出オブジェクト用の関連コ
    ンテクストを識別するように構成された第４ポインタを
    更に含む請求項２３に記載のサーバー呼出オブジェク
    ト。
25. 【請求項２５】コールバック機能を識別するように構成
    された第５ポインタと、該サーバー呼出オブジェクト用
    のデータエレメントを識別するように構成された追加ポ
    インタとを含むように構成されたコールバッククロージ
    ャを更に含む請求項２３または２４に記載のサーバー呼
    出オブジェクト。
26. 【請求項２６】該関連呼出デスクリプタが少なくとも一
    つの関連パラメータデスクリプタを識別する請求項２３
    〜２５のいずれかに記載のサーバー呼出オブジェクト。
27. 【請求項２７】該関連パラメータデスクリプタが、該呼
    出デスクリプタ内の該引数をマーシャルおよびアンマー
    シャルするために汎用マーシャルおよびアンマーシャル
    メソッドをコールするように構成されたマーシャルおよ
    びアンマーシャルメソッドを識別する請求項２６に記載
    のサーバー呼出オブジェクト。
28. 【請求項２８】分散オブジェクトコンピューティングシ
    ステム内の分散サーバーオブジェクト上で定義されたオ
    ブジェクトメソッドを呼び出すためにコンピュータ読取
    り可能コードが具体化されたコンピュータ使用可能媒体
    を含むコンピュータプログラムプロダクトであって、該
    コンピュータプログラムプロダクトが該コンピュータシ
    ステム内で、 クライアントプロセス内でリクエストを受け取るステッ
    プ、 該リクエストをマーシャルするために用いられる、該リ
    クエストに適したトランスポート、を選択するステッ
    プ、 該リクエストをカプセル化するために用いられる、該選
    択されたトランスポートに適したマーシャルバッファ、
    を作成するステップ、 該マーシャルメソッドがタイプコードで解釈されたかコ
    ンパイルされたかを示すために用いられるコンパイルさ
    れたフラグを含む、マーシャルメソッドを利用したデス
    クリプタ・データ構造、を用いて引数をマーシャルする
    ステップ、および該コンパイルされたフラグがセットさ
    れるか否かを決定するステップであって、該コンパイル
    されたフラグがセットされると決定されたときは、該引
    数マーシャリングステップは、該リクエストに関連する
    該引数に関連するマーシャルメソッドを呼び出すことに
    よって達成されると共に、該コンパイルされたフラグが
    セットされないと決定されたときは、該引数マーシャリ
    ングステップは、該引数をタイプコードマーシャリング
    ルーチンにパスしてタイプコードマーシャリングルーチ
    ンを呼び出すことによって達成されるように成したステ
    ップをもたらすためのコンピュータ読取り可能プログラ
    ムコードを備えたコンピュータプログラムプロダクト。
29. 【請求項２９】分散オブジェクトコンピューティングシ
    ステム内の分散サーバーオブジェクト上で定義されたオ
    ブジェクトメソッドを呼び出すためにコンピュータ読取
    り可能コードが具体化されたコンピュータ使用可能媒体
    を含むコンピュータプログラムプロダクトであって、該
    コンピュータプログラムプロダクトが該コンピュータシ
    ステム内で、 クライアントプロセス内で、アドレス内の場所に格納さ
    れた少なくとも一つの引数を含むリクエストを受け取る
    ステップ、 該リクエストに適したトランスポートを選択するステッ
    プ、 該リクエストをカプセル化するために用いられる、該選
    択されたトランスポートに適したマーシャルバッファ、
    を作成するステップ、 該リクエストがタイプコードで解釈されたかコンパイル
    されたかを示すために用いられるコンパイルされたフラ
    グを含む呼出デスクリプタ・データ構造と、複数のパラ
    メータデスクリプタとを含むデスクリプタ・データ構造
    を使って、該リクエストの中の該引数をマーシャルする
    のに適したマーシャル機能を選択するステップ、 該コンパイルされたフラグがセットされるか否かを決定
    するステップ、および該引数をマーシャルするステップ
    であって、該コンパイルされたフラグがセットされると
    決定されたときは、該引数マーシャリングステップは、
    該引数に関連するパラメータデスクリプタによって識別
    されるマーシャルメソッドを呼び出すことによって達成
    されると共に、該コンパイルされたフラグがセットされ
    ないと決定されたときは、該引数マーシャリングステッ
    プは、タイプコード解釈を使用して識別されたマーシャ
    リングメソッドを呼び出すことによって達成されるよう
    に成したステップをもたらすためのコンピュータ読取り
    可能プログラムコードを備えたコンピュータプログラム
    プロダクト。
30. 【請求項３０】３０．該パラメータデスクリプタによっ
    て識別された該マーシャルメソッドが該引数をパスさせ
    ると共に、タイプコードの解釈を使って識別された該マ
    ーシャルメソッドが該引数と関連タイプコードとをパス
    される請求項２９に記載のコンピュータ読取り可能プロ
    グラムコードを備えたコンピュータプログラムプロダク
    ト。
31. 【請求項３１】該マーシャルメソッドの一つにパスされ
    た各引数が、該引数を格納するメモリ場所を定めるアド
    レスの形をとる請求項３０に記載のコンピュータ読取り
    可能プログラムコードを備えたコンピュータプログラム
    プロダクト。
32. 【請求項３２】該リクエストを該選択されたトランスポ
    ートを介して、サーバープロセスに関連する識別された
    エンドポイントまで伝送するステップ、および回答を該
    サーバープロセスから受け取るステップを更に含む請求
    項２９〜３１のいずれかに記載のコンピュータ読取り可
    能プログラムコードを備えたコンピュータプログラムプ
    ロダクト。
33. 【請求項３３】該サーバープロセスから回答を受け取る
    ステップが、更に、該パラメータデスクリプタによって
    識別されたマーシャル機能を使って該マーシャルバッフ
    ァ内で該回答をカプセル化するステップを含む請求項３
    ２に記載のコンピュータ読取り可能プログラムコードを
    含むコンピュータプログラムプロダクト。
34. 【請求項３４】回答の一部として受け取られた例外を扱
    うためにコンピュータ読取り可能コードが具体化された
    コンピュータ使用可能媒体を含むコンピュータプログラ
    ムプロダクトであって、該回答が分散オブジェクトコン
    ピュータシステム内でクライアントによってサーバーに
    対して行なわれるリクエストに応じて該サーバーから該
    クライアントによって受け取られ、該コンピュータプロ
    グラムプロダクトが該コンピュータシステム内に、 該クライアントに関連するホストマシン上のマーシャル
    バッファ内で回答を受け取るステップ、 該回答の中の引数が、所定の例外リターンポインタの形
    で該サーバーによって提起された(raised)システム例外
    であるか否かを決定するステップ、 システム例外が例外リターンポインタの形でサーバーに
    よって提起されたときに、該例外リターンポインタの中
    に示された値に一致するキー用の例外デスクリプタ・レ
    ポジトリを探索するステップ、および一致するキーが発
    見されたとき、投入機能コールと共に該マーシャルバッ
    ファにポインタをパスして、該一致したキーに関連する
    投入機能をコールするステップをもたらすためのコンピ
    ュータ読取り可能プログラムコードを含む該コンピュー
    タプログラムプロダクト。
35. 【請求項３５】分散クライアント／サーバー・ベースの
    コンピューティングシステム内でサーバーオブジェクト
    の実行を呼び出す場合に使用されるコンピュータ装置で
    あって、 中央処理ユニット、 該中央処理ユニットに連結された入／出力装置、 請求項１〜５のいずれかに記載のデータ構造を含む、該
    中央処理ユニットと通信するランダムアクセスメモリ、
    および該中央処理ユニットと通信する大量記憶装置、を
    含むコンピュータ装置。