JPH1078881A

JPH1078881A - オブジェクト呼出の性能を改善するためのメソッドと装置

Info

Publication number: JPH1078881A
Application number: JP9170755A
Authority: JP
Inventors: Swee Boon Lim; ブーンリムスウィー; Peter B Kessler; ビー．ケスラーピーター; Sanjay R Radia; アール．ラディアサンジェイ; Graham Hamilton; ハミルトングラハム
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-06-26
Filing date: 1997-06-26
Publication date: 1998-03-24
Also published as: EP0817024A3; EP0817024A2; US6718550B1

Abstract

(57)【要約】【課題】分散クライアント／サーバー・ベースのコンピ
ューティングシステムにおいて同一プロセスおよび異な
るプロセス呼出用の異なる呼出経路を利用することによ
ってコンピューティングオーバーヘッドを削減するデー
タ構造、メソッド、および装置を開示する。【解決手段】発明の一側面では、リクエストするクライ
アントと同一プロセスを共有しないサーバントへのコー
ルはトランスポート層を介して伝送され、またリクエス
トするクライアントと同一プロセスを共有するサーバン
トへのコールは当該サーバントに直接にパスされること
によってトランスポート層をバイパスする。発明の別の
側面では、リクエストの知的な伝送を容易にするため
に、異なるリモートおよびローカルメソッドテーブルが
提供される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、概して、分散オブ
ジェクト指向コンピューティングシステムに関する。よ
り詳細には、分散オブジェクトシステムにおけるオブジ
ェクトの呼出の性能を改善するために構成されたメソッ
ド、データ構造および装置を開示する。

【０００２】

【従来の技術】ネットワークで連結された異なるコンピ
ュータ上にオブジェクトが配置されたコンピューティン
グ環境は、通常、クライアント−サーバーコンピューテ
ィング環境と呼ばれている。コンピュータの中には、他
のコンピュータに対するサービスや機能の提供者として
働くものがある。サービスや機能の提供者は「サーバ
ー」として知られ、サービスや機能の消費者は「クライ
アント」と呼ばれている。クライアント−サーバーモデ
ルは、同一コンピュータ上で動作する異なるプログラム
が、或る保護されたメカニズムを介して互いに通信して
おり、かつサービスや機能の提供者および消費者として
働いているケースに一般化することもできる。

【０００３】

【発明が解決しようとする課題】そのような分散システ
ムを提供する試みは、従来、クライアント−サーバーモ
デル（そこではサーバーオブジェクトが当該オブジェク
トにリクエストするクライアントオブジェクトにインタ
ーフェイスを提供する）に基づくオブジェクト指向メソ
ッド論を使って行なわれている。通常、そのような分散
システムでは、サーバーは、データと関連メソッドから
成るオブジェクトである。クライアントオブジェクト
は、サーバーオブジェクトをコール（当該分散システム
によって媒介される）することによって、そのサーバー
オブジェクトの機能に対するアクセスを獲得する。サー
バーオブジェクトがコールを受け取ると、それは適切な
メソッドを実行して、結果をクライアントオブジェクト
に送り返す。クライアントオブジェクトとサーバーオブ
ジェクトは、各種分散オブジェクトを配置すると共にオ
ブジェクト間の通信を確立するために使用されるオブジ
ェクトリクエストブローカー（ＯＲＢ）を介して通信す
る。分散オブジェクトは、ネットワーク内の任意の場
所、例えばクライアントのアドレス空間やクライアント
マシン上の多重アドレス空間やネットワーク全体の多重
マシンの中に存在することができる。

【０００４】ソフトウェア産業は、これまで、オブジェ
クト管理グループ（ＯＭＧ）を形成することによって分
散オブジェクトテクノロジーに対するニーズに対応して
きた。ＯＭＧの目標は、オブジェクト管理アーキテクチ
ャ（ＯＭＡ）を定義することで、それは４つの大きなコ
ンポーネント、すなわちオブジェクトリクエストブロー
カー（ＯＲＢ）、オブジェクトサービス、共通ファシリ
ティ、およびアプリケーションオブジェクトを持つ。オ
ブジェクトリクエストブローカーは、基本的なオブジェ
クト通信と管理サービスとを提供し、それによって分散
オブジェクトシステムの基礎を形成する。オブジェクト
リクエストブローカーの規格は共通オブジェクトリクエ
ストブローカーアーキテクチャ（ＣＯＲＢＡ）仕様の中
に含まれる。

【０００５】典型的なクライアント−サーバーシステ
ム、つまり分散オブジェクトシステムでは、そのアーキ
テクチャは、クライアントとサーバーの相対位置に関係
なく、所定の呼出経路を使用してクライアントからのリ
クエストをサーバーに伝達するように構成されている。
すなわち、リクエストは、クライアントとサーバーが同
一または異なるプロセスに存在するか否かにかかわら
ず、システムの実質的に同じ層を介して伝えられる。ロ
ーカルコール、すなわち同一プロセスに位置するサーバ
ーへのコールと、リモートコール、すなわち異なるプロ
セスに位置するサーバーへのコールの両者に対するこの
ような同一経路を使用することは、非効率的である。特
に、クライアントとサーバーが同一プロセスにあるとき
は、クライアントからサーバーへの転送のリクエストを
マーシャルした後、そのリクエストにアンマーシャルす
るトランスポートレベル関数は必要がなく、コンピュー
ティングオーバーヘッドの非効率な使用であることが分
かる。従って、クライアントとサーバーが同一プロセス
に位置するか異なるプロセスにあるかによって選ばれる
異なる呼出経路を利用することによってコンピューティ
ングオーバーヘッドを削減するメソッドが、オブジェク
ト呼出の総合的性能を改善するために望ましいであろ
う。

【０００６】

【課題を解決するための手段】前記およびその他の目的
を達成するために、また本発明の目的に従って、分散ク
ライアント／サーバー・ベースのコンピューティングシ
ステムにおいて異なる呼出経路を利用してコンピューテ
ィングオーバーヘッドを削減するためのメソッドと装置
が開示される。発明の一側面では、リクエストするクラ
イアントと同一プロセスを共有しないサーバントへのコ
ールはトランスポート層を介して伝えられ、リクエスト
するクライアントと同一プロセスを共有するサーバント
へのコールはサーバントに直接にパスされることによっ
てトランスポート層をバイパスする。

【０００７】発明の別の側面では、複数のクライアント
表示、リモートメソッドテーブル、およびローカルメソ
ッドテーブルを含む分散クライアント／サーバー・ベー
スのコンピューティングシステムは、独特なメソッドで
関連オブジェクトを識別するオブジェクトレファレンス
を利用するように構成される。各オブジェクトレファレ
ンスは関連クライアント表示を有する一方、選択された
クライアント表示は複数の異なるオブジェクトレファレ
ンスに関連することができる。リモートメソッドテーブ
ルは、第１セットのクライアント表示に関連するリモー
トディスパッチメソッドを識別するように構成される。
リモートディスパッチメソッドは、呼出リクエストがト
ランスポート層を介して伝えられるように構成される。
対照的に、ローカルメソッドテーブルは、第２セットの
クライアント表示に関連するローカルディスパッチメソ
ッドを識別するように構成される。

【０００８】本発明は、その更なる目的と利点と共に、
添付の図面に関する下記説明を参照することによって最
もよく理解されるであろう。

【０００９】

【発明の実施の形態】本発明は分散オブジェクトシステ
ムに関し、添付の図面に示すいくつかの好ましい実施例
について説明する。本発明は、ＣＯＲＢＡによって定義
されたもの、または他の任意の適切な仕様を含め、任意
の適切な分散オブジェクトシステムとの関連において実
行することができる。しかしながら、説明の目的のた
め、本発明は、主として、１９９５年７月付のＯＭＧか
らのＣＯＲＢＡ仕様、改訂版２．０、に基づいて実装さ
れたオブジェクトリクエストブローカー（ＯＲＢ）の関
連において記述される。図１は、本発明の実施に適した
代表的な分散オブジェクトシステムの全体的アーキテク
チャを概略説明する。図２は、或るクライアントからサ
ーバントオブジェクトへのリクエストが、３つのレベル
のディスパッチメカニズムを含むようなアーキテクチャ
内で取り得るいくつかの可能な流れ経路を概略説明す
る。図３は、サーバントオブジェクトを参照するために
クライアントが使用できるオブジェクトレファレンスデ
ータ構造の一つを示す。

【００１０】分散オブジェクトシステム１０は、図１に
象徴的に示すように、通常、オブジェクトリクエストブ
ローカー（ＯＲＢ）１１を含む。ＯＲＢ１１は、クライ
アントからのコールをサーバント（目標オブジェクト）
に伝達してそのクライアントに応答を返すのに必要な場
所と輸送メカニズムと設備のすべてを提供するが、これ
については図２に関して以下に説明する。クライアント
とサーバントは、同一プロセス内、同一マシン上の異な
るプロセス内、または全く異なるマシン上に配置でき
る。この検討の目的のためには、クライアント２０は、
分散オブジェクト上のオペレーションを呼び出す任意の
コードでよいので、分散オブジェクトやプロセスの形を
取っても、取らなくてもよい。正常なオブジェクトイン
プリメンテーション１４は、Ｃ＋＋等の従来のオブジェ
クトプログラミング言語で定義されるオブジェクトタイ
プの表示である。様々な表示が可能である。例として、
オブジェクトインプリメンテーション１４は、アプリケ
ーションディベロッパによって提供される単純なＣ＋＋
オブジェクトタイプでもよい。そのほか、オブジェクト
タイプのためのインプリメンテーションは、視覚アプリ
ケーションビルダー１５内で開発することもできる。こ
の視覚アプリケーションビルダーによって、開発者は既
存のオブジェクトタイプをカタログからビジュアルに選
択して、オブジェクトタイプ用の新しいインプリメンテ
ーションを作成するために、あるオブジェクトによって
提供されたサービスを別のオブジェクト（属性、引数
等）によって必要とされるサービスに図式的に接続する
ことが可能となる。

【００１１】オブジェクト開発ファシリティ１６は、分
散オブジェクトの作成とインストレーションを簡略化す
るために使用できる。それを使って、ディベロッパオブ
ジェクトを分散オブジェクトコードの中に「ラップ」す
るか、カプセル化する。このように、オブジェクト開発
ファシリティ１６は、ディベロッパオブジェクトをＯＲ
Ｂオブジェクトインプリメンテーション１４に変換する
ために使用できる。この例ではＯＲＢオブジェクトイン
プリメンテーション１４は、図中のその場所で示される
ように、サーバーとして提示される。ディベロッパはイ
ンタフェース定義言語を使ってＯＲＢオブジェクト用イ
ンタフェースを定義し、そのオブジェクトの挙動を実装
するオブジェクトインプリメンテーションをディベロッ
パに提供した後、そのオブジェクトの開発ファシリティ
を使ってＯＲＢオブジェクトインプリメンテーション１
４を作成する。動作時には、このＯＲＢオブジェクトイ
ンプリメンテーション１４を利用する、このＯＲＢオブ
ジェクト（サーバントオブジェクト）のインスタンスが
作成される。オブジェクト開発ファシリティも、或る時
点でクライアントの役割を担うオブジェクトの作成のた
めに使用できることを理解しなければならない。

【００１２】クライアント２０は、スタブ２１、メソッ
ドテーブルディスパッチ２４、サブコントラクト層３
６、可能性としてフィルタ４０、およびトランスポート
層３８を介してサーバントと通信する。スタブ２１はサ
ロゲート２２、メソッドテーブル２４、およおびスタブ
関数２５を含む。クライアント２０は、最初、クライア
ントにはサーバーオブジェクトに見えるサロゲート２２
と通信する。そのほかに、クライアント２０は、サロゲ
ート２２、メソッドテーブル２４、およびスタブ関数２
５の代わりに、動的呼出インタフェース（ＤＩＩ）を介
してサーバーオブジェクトと直接に通信してもよい。動
的呼出インタフェース２６を使用して、クライアント、
例えばクライアント２０は動的リクエストを構築でき
る。上記の層を利用してクライアントがサーバントにコ
ールする一つの手順を、図２に関して以下により詳しく
説明する。

【００１３】サブコントラクト層３６は、サブコントラ
クトを利用して特定のサブコントラクトによって指名(n
amed) された各種サービス（または特徴やオブジェクト
メカニズム）を実施するために、オブジェクトによって
要求された機能を提供するが、これについては上記の１
９９５年１１月７日申請の米国特許出願第０８／５５
４，７９４号に更に詳しく記載されている。サブコント
ラクトは、個々のオブジェクトによって利用される分散
オブジェクトシステムによって提供されるサービスの質
を識別する。例えば、サブコントラクトは、特定のオブ
ジェクトのために安全性の特徴が使用されることを識別
するだろう。フィルタ４０が使用される場合、それは圧
縮、暗号化、トレース、またはデバッグ等の、オブジェ
クトに出入りする通信に適用すべき様々なタスクを実行
するだろう。

【００１４】トランスポート層３８は、通常はクライア
ントと同一プロセスを共有しないサーバントに出入りす
る情報を、マーシャル、アンマーシャル、および物理的
に輸送するために動作する。

【００１５】標準インプリメンテーションスイート２８
（またはオブジェクトアダプタ）は、同一の方式でＯＲ
Ｂオブジェクト１４と相互作用する例えばオブジェクト
キーマネージメントとしてのサブコントラクトの集まり
を表す。当然のことながら、一つのサブコントラクトは
複数のインプリメンテーションスイートに属することが
できる。従って、他のインプリメンテーションスイート
が異なるサブコントラクトを利用することが可能であ
る。スケルトンは、静的スケルトン３２や動的スケルト
ン３０の形を取り得るが、これは、サーバントオブジェ
クト１４によってリクエストされるフォーマットにリク
エストを変換するために使用される。かくして、スケル
トン３２、３０は適切なサーバントオブジェクト１４を
コールする。静的スケルトン３２はインタフェース固有
のオブジェクトインプリメンテーション１４をコールす
るために使用され、動的スケルトン３０は、一般に、イ
ンタフェース固有のオブジェクトが利用できないときに
使用される。ＯＲＢインタフェース３４は、すべてのＯ
ＲＢに対して同一であってオブジェクトのインタフェー
スやオブジェクトアダプタに依存しない、直接にＯＲＢ
に頼るインタフェースである。ＯＲＢデーモン４６は、
オブジェクトサーバーがクライアントによって呼び出さ
れたときにアクティブである旨保証する責任がある。オ
ブジェクトサーバーを起動する技術は、米国特許出願第
０８／４０８，６４５号に開示されている。

【００１６】安全プロトコル４２は、インターネットイ
ンターＯＲＢプロトコルを保証して、トランスポート層
３８を介して安全なメソッドで情報を伝達するのに役立
つ安全インタオペラビリティプロトコルである。これは
一貫性保護、機密性等を意味するだろう。インターネッ
トインターＯＲＢプロトコルは、通常、異なるマシン上
のプロセス間で通信するプロトコルである。しかしなが
ら、場合によって、インターネットインターＯＲＢプロ
トコルは同一マシン上のプロセス間で通信することがで
きる。セキュリティサーバー５４は、異なるコンピュー
タ上のプロセス間で使用されるサービスを保証するセキ
ュリティアドミニストレーションサーバーである。

【００１７】タイプコード／Ａｎｙモジュール４４はタ
イプコードと「Ａｎｙ」オブジェクトを実装する。タイ
プコードはインタフェース定義言語（ＩＤＬ）データタ
イプを記述し、クライアントとサーバー間のタイプ記述
の伝達を可能にする。ＩＤＬデータタイプのインスタン
スを「Ａｎｙ」オブジェクトによってカプセル化するこ
とができる。Ａｎｙオブジェクトは、カプセル化された
データのタイプコードと、データの総称的コード化を参
照する。

【００１８】インプリメンテーションレポジトリ５０
は、オブジェクトサーバーに関する情報を格納するため
に使用される。具体的には、インプリメンテーションレ
ポジトリ５０は、サーバープロセスを開始するのに必要
な情報を格納する。例えば、インプリメンテーションレ
ポジトリ５０は、サーバープログラムの場所、プログラ
ムに対する任意の引数、およびプログラムに渡すべき任
意の環境変数等の情報を格納する。

【００１９】シンプルパーシステンス５６は、追加コー
ドの一部と共に、インタフェース定義言語（ＩＤＬ）定
義タイプと、ＩＤＬコンパイラを介してそのＩＤＬタイ
プを実行する出力形とを使用するので、ＩＤＬ定義タイ
プをディスクから読み取ったりディスクへ書き込むこと
ができる。ネームサーバー５２は、ＯＲＢオブジェクト
を名前付け(name)するために使用される。或るクライア
ント、例えばクライアント２０は、ネームサーバー５２
を使って希望のオブジェクトをネームで発見することが
できる。ネームサーバー５２はオブジェクトレファレン
スを返し、次にそのレファレンスを使ってそのオブジェ
クトにリクエストを送ることができる。インタフェース
レポジトリ４８（ＩＦＲ）は、分散オブジェクトシステ
ム内のすべてのオブジェクトに対するすべてのインタフ
ェースについて知識を持つ。

【００２０】メソッドテーブル（「ｍ−テーブル」）デ
ィスパッチを使って、クライアントによって行なわれた
リクエストは、図２に概略図示するように、途中、アー
キテクチャの前記の様々な層を通ってサーバントに至
る。リクエストはクライアントによって開始され、任意
の形を取ることができる。リクエストの形は、クライア
ントを作成するために使用されるプログラミング言語の
性質に大きく依存する。例として、クライアントがＣ＋
＋言語で書かれている場合、リクエストはＣ＋＋メソッ
ドコール６２の形を取ることができる。コールは、サロ
ゲートの形を取る指定のオブジェクトレファレンスに対
して行なわれる。サロゲートは、オブジェクトのインタ
フェースに適合するメソッドを含む。当業者にはよく理
解されるように、分散オブジェクトシステム内の異なる
ロケーションで使用されるオブジェクトレファレンスは
外観が大きく変わる場合がある。記載の実施例では、ク
ライアント側オブジェクトレファレンスはデュアルポイ
ンタである（本明細書では「ファットポインタ(fat poi
nter」と呼ぶ）。ファットポインタは性質の異なる２つ
のポインタを含む。第１のポインタ、つまり第１の場所
インジケータは、レファレンスドオブジェクトに関連す
るクライアント表示（「クライアントレプ」）を指示す
る。第２のポインタ、つまり第２の場所インジケータ
は、レファレンスドオブジェクトに関連するメソッドテ
ーブルディスパッチ２４のメソッドテーブルを指示す
る。ここで用いられる用語「ポインタ」はコンピュータ
ネットワーク内の場所を識別するために使用されるばか
りでなく、用語「ポインタ」は一般的な場所インジケー
タのことを指すためにも使用されることを理解しなけれ
ばならない。クライアント表示は、呼出、ならびにＣＯ
ＲＢＡで定義された「疑似」オブジェクトレファレンス
オペレーションを支援するメソッドを持つオブジェクト
である。これらのオペレーションは、これに限定される
ものではないが、デュプリケートメソッド、リリーズメ
ソッド、ナローメソッド、ハッシュメソッド、およびイ
ズ−イクイバレントメソッドを含む。

【００２１】クライアントがコールを開始した後、その
コールはメソッドテーブルディスパッチメカニズム２４
を使って処理される。かかる技術は米国特許出願第０８
／３０７，９２９号に開示されている。メソッドテーブ
ルディスパッチメカニズムは、スタブ関数２５に対する
ポインタ、つまり場所インジケータ、のリストを含むメ
ソッドテーブルを使用するが、そのポインタの一つは呼
び出すべきメソッドに関連している。スタブ関数２５は
クライアントプロセスの「ネイティブ」言語による関数
や手続きコールを受け取った後、サブコントラクト層３
６かネイティブコールのいずれかを使って、結局、対応
するサーバントオブジェクトをコールする。ネイティブ
言語は、任意の適切な言語、例えばＣ＋＋のような言語
でもよい。

【００２２】メソッドテーブルディスパッチ２４はその
メソッドコールを処理する適切なスタブ関数２５を決定
した後、メソッドコールをその適切なスタブ関数２５と
組合せる。メソッドコールを行なったクライアントがサ
ーバントオブジェクトと同一プロセスにある場合、ロー
カルスタブ関数がコールされる。ローカルスタブ関数
は、そのメソッドコールを直接にサーバントオブジェク
ト７８に送る。そのほかに、サーバントオブジェクトが
異なるプロセス、すなわちリモートプロセスにある場
合、リモートスタブ関数がコールされる。リモートスタ
ブ関数はクライアント表示を呼び出し、クライアント表
示がその呼出をサーバントオブジェクト７８に伝達す
る。

【００２３】サブコントラクト層３６によって実装され
たサブコントラクトは、分散オブジェクトシステムで重
要なオブジェクトの呼出と引数のパスの基本メカニズム
を制御する論理モジュールである。サブコントラクト層
３６によって実装されるサブコントラクトは、オブジェ
クトによって使用されるサービスの固有の質を決定す
る。サブコントラクトはサブコントラクト識別子によっ
て独特なメソッドで識別され、その識別子は、通常、オ
ブジェクトレファレンスに埋め込まれている。サービス
の質とはサービス特性の集まりである。選択可能なサー
ビス特性の中には、サーバーの作動、セキュリティ、ト
ランザクション、フィルタ性、およびクリーンシャット
ダウンに関係する質がある。サブコントラクトは、一定
の質のサービスが利用できるように構成されている。予
め定められたサービスの質によって、個々のサービス特
性の処理に伴うオーバーヘッドが削減される。実施に、
「妥当な」または一般的に使用されるサービス特性の組
合せがサブコントラクトによってサポートされる。しか
しながら、所定の分散オブジェクトシステムの固有の要
件を満たすためにサブコントラクトを作成してもよい。

【００２４】サブコントラクト層３６内の適切なサブコ
ントラクトの識別は、そのサブコントラクトに独特な望
ましい関数の識別と見做すことができる。例えば、マー
シャル関数やアンマーシャル関数は、各サブコントラク
ト毎に定義される。サブコントラクトマーシャル関数
は、別のアドレス空間や領域に伝送できるようにオブジ
ェクトレファレンスをマーシャルするためにスタブによ
って使用される。オブジェクトレファレンスは、通常、
トランスポート層３８内のトランスポートメカニズムに
よって処理される。

【００２５】Ｔ１、Ｔ２等のトランスポートメカニズム
は、トランスポート層３８の一部だが、サーバントオブ
ジェクトに出入りする情報をマーシャルして物理的に輸
送するために使用される。情報、すなわちオブジェクト
レファレンスやリクエストは、所定の領域に適したプロ
トコルに転換される。例として、プロトコルは、それに
限定されるわけではないが、イーサーネットプロトコル
とインターネットインタオペラブルプロトコル（ＩＩＯ
Ｐｓ）を含んでもよい。希なケースでは、プロトコル
は、サーバー上で実装されるべき命令を伝送するために
電子メールの使用を必要とすることもある。情報がマー
シャルされた後、そのトランスポートメカニズムはオペ
レーティングシステム、デバイスドライバ、またはネッ
トワーク（これらは、すべて、分散オブジェクトシステ
ムのクライアント側によって使用されるハードウェア７
０の一部）の任意の組合せを介して情報を輸送する。ト
ランスポートメカニズムでは、情報を所定領域に適した
プロトコルに転換する必要があるが、中には異なる領域
に対する情報のコード化を必要としないトランスポート
メカニズムもある。情報の発生場所以外の領域に適した
プロトコルへの情報の転換を必要としないトランスポー
トメカニズムは「ドア」と呼ばれる。ドアは、基本的
に、同一ホスト上の２つの異なるプロセス間のゲートウ
ェイである。ドアを使用することによって、トランスポ
ート層３８内の標準インプリメンテーションに情報を転
換するニーズが除去される。というのは、情報が同一ホ
ストに残っているので領域を変更する必要がないため
に、異なるマシンによって使用され得るプロトコルに情
報をコード化する必要がないからである。従って、情報
を単に「平坦化(flattened out) 」するか、あるいは異
なるマシンによる使用のためにコード化されないストリ
ームの中にマーシャルして、ホスト上の２つのプロセス
間でパスすることができる。

【００２６】一旦、情報が、クライアント側によって使
用されるハードウェア７０を介して輸送されると、その
情報は、次に、分散オブジェクトシステムのサーバー側
のハードウェア７０に輸送される。一旦、情報がハード
ウェア７０を通って流されると、分散オブジェクトシス
テムのサーバー側は、トランスポート層３８の一部であ
るエンドポイントで情報を受け取るために、Ｔ１、Ｔ２
等のトランスポートメカニズムを呼び出す。万一トラン
スポート層３８によってエンドポイントが作成されない
場合、トランスポート層３８は、そのエンドポイントが
サブコントラクト層３６によって作成されるのに必要な
機能を提供する。例として、ドアエンドポイントは、通
常サブコントラクト層３６によって作成され、一方、ネ
ットワークとＴＣＰ／ＩＰエンドポイントを含む他のエ
ンドポイントは、通常、トランスポート層３８によって
作成される。エンドポイントの作成がサブコントラクト
層３６によるかトランスポート層３８によるかにかかわ
らず、エンドポイントはトランスポート層３８の中に
「住む(live in) 」、つまりその一部である。エンドポ
イントは、基本的に異なる領域から情報を受け取るポー
トである。トランスポート層３８内のエンドポイント
が、異なる領域から輸送された情報を受け取った後、そ
のエンドポイントは、次に、その情報をトランスポート
層３８からサブコントラクト層３６にディスパッチす
る。サブコントラクト層３６、より具体的にはその情報
を受け取るサブコントラクト層３６内のサブコントラク
トが、次にその情報をスケルトンとサーバントにディス
パッチする。

【００２７】サブコントラクト層３６は、それが受け取
った情報の少なくとも一部をアンマーシャルするための
機能を提供する。すなわち、サブコントラクト層３６は
リクエストの少なくとも一部をアンマーシャルする。次
に、リクエストがスケルトン３１にディスパッチされ、
スケルトンがそのリクエストを、サーバントオブジェク
ト７８によって要求されるインプリメンテーションの固
有のフォーマットに変換する。スケルトンは、上記のよ
うに、静的スケルトンでも動的スケルトンでもよい。

【００２８】一般に、リモートリクエストのルートは、
上記のように、クライアント側とサーバー側を通らなけ
ればならない。メソッドコール６２が受け取られると、
メソッドテーブルディスパッチ層２４を使って、リクエ
ストをマーシャルしてそれを別の領域に輸送するために
準備するトランスポート層３８内のトランスポートメカ
ニズムを選択する前に、適切なサブコントラクトが識別
される。ハードウェア７０を介して、マーシャルされた
リクエストがサーバー側に輸送され、そこでそのリクエ
ストがトランスポート層３８の一部のエンドポイント上
で受け取られる。適切なエンドポイントがワイヤを伝っ
て輸送された情報を受け取ると共に、情報がトランスポ
ート層３８からサブコントラクト層３６にディスパッチ
されるので、サブコントラクト層はそれが受け取った情
報を少なくとも部分的にアンマーシャルする機能を提供
する。次に、サブコントラクトは、そのリクエストをス
ケルトン３１にディスパッチし、スケルトンはそのリク
エストを、サーバントオブジェクト７８によって要求さ
れる固有のフォーマットに変換する。この経路を矢印７
７で示すが、これはリモートリクエストとローカルリク
エストが共に取り得る経路である。

【００２９】しかしながら、クライアントとサーバーが
ローカルプロセスにある場合、すなわちクライアントと
サーバーが共に同一プロセスにある場合、上記の矢印７
７で示される経路の使用は必要以上に複雑である。クラ
イアントとサーバーが同一プロセスにあることが分かっ
ていれば、呼出し、つまりサービスのためのリクエスト
の流れ経路を短縮することができる。オブジェクトレフ
ァレンスを作成するときにローカルプロセスが識別され
た場合、クライアントであるものから同一ホスト上のサ
ーバーにリクエストを送るために、短縮された流れ経
路、つまり矢印７５、７６で示される経路を取ることが
できる。矢印７６で示される経路を取る可能性の方が大
きい。というのは、それが適切なサブコントラクトを識
別するためにサブコントラクト層３６を使用しているか
らである。しかしながら、適切なサブコントラクトをは
っきり識別する必要のない状況では矢印７５で示される
経路を取ることができる。

【００３０】ここで、図３を使って、オブジェクトレフ
ァレンスの一実施例を説明する。当業者にはよく知られ
ているように、オブジェクトレファレンスは、それらが
任意の時点で占めているプロセス内の場所によって様々
な形を取ることができる。しかしながら、背景として、
低いオーバーヘッドのオブジェクトアダプタを利用する
システムで使用するための代表的なオブジェクトレファ
レンスを図３に示す。ここで示されるインプリメンテー
ションでは、オブジェクトレファレンス１５０は、ホス
ト識別子１５２、ポート指定１５４、およびオブジェク
トキー１５６を含む。オブジェクトキー１５６は、サブ
コントラクト識別子１５８、サーバー識別子１６０、イ
ンプリメンテーション識別子１６２、およびユーザーキ
ー１６４を含む。ホスト識別子１５２は、ネットワーク
内の特定のコンピュータを指し、ポート指定１５４は、
通信用に使用すべき選ばれたコンピュータのポートを識
別する。オブジェクトキー１５６は、望ましいサーバン
トオブジェクトをホストマシン上に配置するために使用
される更なる識別用情報を提供する。

【００３１】サーバー識別子１６０は、サーバントオブ
ジェクトが常駐する特定のプロセスやプログラムを指示
し、一方、ユーザーキー１６４は、サーバー識別子１６
０によって指示されるプロセス内にサーバントを配置す
るために使用される唯一の数または文字列である。サブ
コントラクト識別子１５８は、特定サブコントラクトの
プロトコルと、サーバントに対するその関連サービスと
を生成するために使用され、インプリメンテーション識
別子１６２は、そのサーバントオブジェクトと共に使用
すべきインタフェースのインプリメンテーションを指示
する。

【００３２】次に図４を参照して、ｍテーブルディスパ
ッチメカニズムを更に詳しく説明する。上述のように、
記載の実施例では、呼び出すべきサーバントを識別する
ためにクライアントによって使用されるオブジェクトレ
ファレンスは「デュアル」ポインタまたは「ファットポ
インタ」９０と見做すことができる。すなわち、２つの
「正常な」ポインタを含むポインタ構造である。ファッ
トポインタ９０はＣＯＲＢＡオブジェクトレファレンス
と見做すこともできる。各ポインタのサイズはシステム
の要件によって支配される。ファットポインタ９０の第
１ポインタは、クライアント表示（「クライアントレ
プ」）９４を指示するクライアント表示ポインタ９０ａ
である。ファットポインタ９０の第２ポインタは、クラ
イアント表示９４に関連するｍテーブル２４を指示する
ｍテーブルポインタ９０ｂである。上記の説明のよう
に、クライアント表示９４は、オブジェクト呼出とＣＯ
ＲＢＡで定義された「疑似」オブジェクトレファレンス
オペレーション（デュプリケートおよびナローメソッド
を含む）とをサポートするメソッドを持つオブジェクト
である。クライアント表示９４はクライアント上のサー
バントオブジェクトの表示と見做される。かくして、ク
ライアント表示９４はサーバントと関連している。各オ
ブジェクトレファレンスは単一の関連クライアント表示
９４を持つが、各クライアント表示９４は一つ以上の異
なるオブジェクトレファレンスに関連することができ
る。クライアント表示９４のサブコントラクトは、クラ
イアント表示９４が一つ以上のオブジェクトレファレン
スと関連するか否かを決定する。

【００３３】各クライアント表示９４は、一般に、関連
するｍテーブルを持つ。関連ｍテーブルはローカルｍテ
ーブルでも、リモートｍテーブルでもよい。或る実施例
では、多重のローカルまたはリモートｍテーブルが利用
される。クライアント表示の中には一つ以上の関連ｍテ
ーブルを持つものがある。クライアント表示９４がロー
カルｍテーブルとリモートｍテーブルの両者を格納、維
持するか否かは、クライアント表示９４が関連するサブ
コントラクトのインプリメンテーションに依存する。一
般に、ｍテーブル２４は、ディスパッチの決定のために
使用されるメソッドへのポインタのアレイを含む。クラ
イアント表示９４はスタブ、つまりスタブ関数２５にパ
スされる引数であるから、ディスパッチはクライアント
表示９４から独立している。スタブ関数２５は、先に記
載したように、クライアントプロセスのネイティブ言語
による関数コールを受け取った後、サポートライブラリ
を使って、結局、対応するサーバントオブジェクトをコ
ールする。ディスパッチを決定するために使用されるｍ
テーブルは希望のオペレーション用のスタブ関数２５を
指示することができる。別法として、スタブ関数２５を
直接指示するのではなく、ｍテーブルは、ディスパッチ
を決定するために使用されるスタブ関数２５へのポイン
タのアレイを含む他のｍテーブルを指示してもよい。

【００３４】分散オブジェクトシステムの中の各インタ
フェースは少なくとも一つのｍテーブルに関連すること
ができる。しかしながら、インスタンスの中には関連す
るｍテーブルを持たないものもあることを理解しなけれ
ばならない。ｍテーブルは、通常、コンパイルされた、
つまり静的なスタブと共に使用される。従って、コンパ
イルされたスタブが存在しない実施例では、インタフェ
ースは関連ｍテーブルを持たないかもしれない。通常、
各インタフェースは単一のローカルｍテーブルと単一の
リモートｍテーブルに関連している。もっとも、或る場
合には、一つのインタフェースが一つ以上のローカルｍ
テーブルに関連することができる。

【００３５】一般に、ｍテーブルは多くの異なる表示を
持つことができる。例として、或る実施例では、ｍテー
ブルは「フラット」、つまりｍテーブルは直接にスタブ
関数を指示できる。他の実施例では、ｍテーブルはツリ
ー構造、すなわちｍテーブルは、直接にｍテーブルによ
って指示されないスタブ関数２５を指示し得るデータ構
造を指示するだろう。所定のインタフェースの各メソッ
ドに対するポインタは、そのインタフェースに関連する
ｍテーブルからアクセス可能であることを理解しなけれ
ばならない。従ってｍテーブルがツリー構造の場合、メ
ソッドに関連するポインタを発見するためにｍテーブル
のツリー構造をたどる必要があるかもしれない。

【００３６】下記に更に詳しく説明するように、提案の
アーキテクチャの一つの利点は、ローカルとリモートの
手続きの間の区別を可能にすることによって、クライア
ントによって受け取られるリクエストの最適な流れ経路
や呼出経路の決定が可能になることである。例として、
クライアントとサーバーが同一プロセスに存在しない場
合、受け取られたリクエストは少なくともクライアント
とサーバーの両者のトランスポート層を介して伝えら
れ、サーバープロセスが異なるホスト上にあるときは、
ハードウェア層も通ることになる。しかしながら、クラ
イアントとサーバーが互いにローカルにある場合、すな
わち、同一プロセスを共有するときは、受け取られたリ
クエストをトランスポート層とハードウェア層とを介し
て送る必要はない。クライアントとサーバーが同一プロ
セスにある場合は、修正された、より短い流れ経路を利
用できるので、受け取られたリクエストはクライアント
側のサブコントラクト層とｍテーブルディスパッチ層の
どちらからも適切なサーバントオブジェクトに伝達する
ことができる。不必要なときに、受け取ったリクエスト
をトランスポート層とハードウェア層とを介して送るこ
と（リクエストと回答のマーシャルとアンマーシャルが
必要）は、効率、従ってオブジェクトの呼出性能を損な
うことになる。サーバントがクライアントと同一プロセ
スにあるか否かを効率的に識別できるようにオブジェク
トレファレンスを構成することによって、クライアント
とサーバーが同一プロセスに存在する場合でも、短い流
れ経路の利用が可能となる。従って、オブジェクト呼出
の性能が改善される。

【００３７】次ぎに図５を参照して、ｍテーブルディス
パッチを使用したオブジェクトの呼出に関するステップ
を説明する。最初、ファットポインタを使ってコールが
行なわれる。記載の実施例では、Ｃ＋＋コールの形を取
る。もっとも、コールの性質は、勿論、通常はクライア
ントが書かれたプログラム言語の関数になる。ステップ
１００では、コールされたメソッドが、ファットポイン
タによって指示されたｍテーブルに配置される。コール
されたオブジェクトがローカルなメソッドの場合、ファ
ットポインタによって指示されるｍテーブルはローカル
ｍテーブルになる。同様に、コールされたオブジェクト
がリモートな場合、ファットポインタによって指示され
るｍテーブルはリモートｍテーブルになる。ステップ１
０５では、コールは、ステップ１００で指示されたスタ
ブ関数に対して行なわれる。記載の実施例ではＣ＋＋コ
ールであるコールは、ファットポインタによって識別さ
れたクライアント表示と、コールパラメータとしてパス
された他の引数とを使って行なわれる。或る実施例で
は、追加の引数がパスされる。指示されたスタブ関数が
コールされた後、プロセス制御は、指示されたスタブ関
数がローカルスタブ関数にあるかリモートスタブ関数に
あるかによって、異なる関数に分岐する。指示された関
数がローカルスタブ関数にある場合、プロセス制御はス
テップ１１０に進み、そこでローカルスタブ関数が実行
される。このローカル呼出は図４に関して以下により詳
しく検討する。ローカルスタブがステップ１１０で実行
された後、プロセスはステップ１２０の関数コールから
戻る。ファットポインタによって指示された関数がリモ
ートスタブ関数にある場合、プロセス制御は、ステップ
１０５からステップ１１５に進み、そこでリモートスタ
ブが実行される。リモートスタブがステップ１１５で実
行された後、プロセス制御はその関数コールからの戻り
であるステップ１２０に進む。

【００３８】次に図６を参照して、ローカルスタブを使
用して呼出を実施するための適切なメソッドを説明す
る。すなわち、図５のステップ１１０の一実施例を更に
詳しく説明する。図２に関して、ローカルスタブを「実
行」するプロセスは、経路７５または７６を介してサー
バントを呼び出すプロセスと理解されるだろう。或るオ
ペレーション、例えばオペレーションＸのためのローカ
ルスタブを実行するプロセスはステップ２００で開始さ
れ、ローカルスタブによってパスされたクライアント表
示のローカルフックがアクティブか否か決定される。フ
ックがアクティブか否かの任意の適切な表示が使用でき
る。例として、ローカルフックはその一部であるクライ
アント表示がアクティブか否かを識別する２値のフラグ
でもよい。ローカルフックは、追加コード（例えばオブ
ジェクトディベロッパによってカスタマイズされたコー
ド）がクライアント−サーバーシステム内で実行できる
メカニズムを提供する。すなわち、ローカルフックは、
クライアント−サーバーシステムが追加コードを実行し
なければならないか否かを示すようにセットできる。大
抵の実施例では、この決定は実行時と対立するコンパイ
ル時に行なわれるので、ローカルフックが使用されない
ときは、フック設備の設置による性能の低下はないだろ
う。

【００３９】ローカルフックがアクティブでないとき、
それはローカルスタブを実行するプロセス内に含むべき
追加コード、特にサブコントラクト固有のコードが存在
しないことを示し、プロセス制御はステップ２１６に進
み、そこで、インタフェース定義言語（ＩＤＬ）で規定
されたネームのエレメントを持つ新しいコンテクストオ
ブジェクトが、オリジナルコールとスタブ関数へのコー
ルからパスされたオリジナルコールリクエストから作成
される。ＩＤＬは、オブジェクトのインタフェースを定
義するために使われる言語である。コンテクストオブジ
ェクトは、結合のリスト、例えば「ＵＳＥＲＮＡＭＥ＝
ｆｏｏ」および「ＨＯＳＴＮＡＭＥ＝ｆｏｏ」の２つの
文字列を含むリストである。更に一般的にはコンテクス
トオブジェクトは、優先情報や分散オブジェクトシステ
ムの構成に関する情報を格納するために使用できる。コ
ンテクストオブジェクトがステップ２１６で作成された
後、プロセス制御はステップ２１８に進み、そこで、サ
ーバントがクライアント表示から直接に取得される。ロ
ーカルスタブは使用中なので、クライアントとサーバン
トが同一プロセスを共有することが分かる。従って、サ
ーバントは、当業者には理解されるように、標準技術を
使って容易に取得できる。記載のコンテクストオブジェ
クト作成ステップ２１６はオプションのステップで、希
望なら除去してもよい。通常、コンテクスト作成ステッ
プ２１６は、関連メソッドがＩＤＬによるコンテクスト
クローズで規定されないときは削除される。関連メソッ
ドがコンテクストクローズで規定されない場合、コンテ
クスト引数はオリジナルコールまたはスタブ関数へのコ
ールの一部としてパスされないだろう。コンテクストオ
ブジェクト作成ステップ２１６が省略された場合、プロ
セス制御はステップ２００（そこでクライアント表示の
ローカルフックがアクティブでない旨決定された）から
直接にステップ２１８に進み、そこで、サーバントがク
ライアント表示から直接取得される。

【００４０】サーバントがステップ２１８で取得された
後、ステップ２１８で識別されたサーバー用のオペレー
ションＸに対応するメソッドがステップ２２０でコール
される。ステップ２２０でのサーバーコールに対する引
数は、通常、クライアント表示を除いて、スタブ呼出ス
テップ１０５でローカルスタブにパスされるものと同一
引数である。新しいコンテクストがオプションのステッ
プ２１６で作成された場合、その新コンテクストもその
コールと共にオリジナルコンテクストの代わりにパスさ
れる。ステップ２２０が完了した後、結果が返される。
結果が返されたとき、新コンテクストは、それが作成さ
れた場合には、自動的に削除または破壊される。

【００４１】クライアント表示のローカルフックがアク
ティブである旨ステップ２００で決定された場合、それ
は追加コードを実行しなければならないことを示し、プ
ロセス制御はステップ２０２に移り、そこで、クライア
ント表示のプレローカルディスパッチメソッドに対する
コールが行なわれる。クライアント表示のローカルフッ
クがアクティブなときは、プレローカルディスパッチメ
ソッドが、ローカルディスパッチ、特にサーバントオブ
ジェクトへのポインタによって要求されるクライアント
表示に固有の情報を収集するために、ローカルディスパ
ッチが起こる前にコールされる。プレローカルディスパ
ッチは、サーバントポインタが確実に取得されることを
確認するために使用される。更に、プレローカルディス
パッチメソッドは、サーバントにコールを受け取るよう
に準備させたり（活性化）、コーラーがサーバントを呼
び出す許可を取るのを保証したり（セキュリティ）、ト
ランザクションを格納したり、ロックを獲得したりする
ために、追加のサブコントラクト処理を実行することが
できる。正確な処理はクライアント表示に関連するサブ
コントラクトに依存することを理解しなければならな
い。プレローカルディスパッチメソッドに対するコール
では、ジェネリックホルダーがパスされる。総称的ホル
ダーは、プレローカルディスパッチメソッドからポスト
ローカルディスパッチメソッドまでのローカルスタブの
実行に関係する希望の情報をパスするために使用でき
る。総称的ホルダーは、サブコントラクトに関係するプ
レ呼出状態を保つための全体的記憶やスレッド固有の記
憶の使用を避けるために用意される。総称的ホルダー
は、そのホルダーにバリューを割り当てるプレローカル
ディスパッチメソッドにパスされる。一般的に、割り当
てられる値はトランザクション識別子を含む構造へのポ
インタや、プレローカルディスパッチで割り当てられた
記憶へのポインタ（通常、次のサーバントコール用ポス
トローカルディスパッチで割当て解除される）でもよ
い。

【００４２】ステップ２０２におけるクライアント表示
のプレローカルディスパッチメソッドに対するコールか
ら、プロセス制御はステップ２０４に進み、そこで、プ
レローカルディスパッチコールが成功したか否か決定さ
れる。コールが不成功の場合、例外、つまりこの実施例
ではＣ＋＋例外が起こり、更なる処理は行なわれない。
コールが成功した場合、プロセス制御はステップ２０６
に進み、そこで、ＩＤＬで規定されたネームのエレメン
トを持つ新しいコンテクストオブジェクトが作成され
る。従って、プロセス制御はステップ２０８に進み、そ
こで、サーバントがクライアント表示から取得される。
サーバントが取得された後、オペレーションＸに対応す
るメソッドが、識別されたサーバントに対してステップ
２１０でコールされる。すなわち、ステップ２１０では
ローカルディスパッチが起こる。ステップ２０６〜２１
０は上述のステップ２１６〜２２０のミラーであること
を理解しなければならない。従って、コンテクストオブ
ジェクト作成ステップ２１６と同様に、コンテクスト作
成ステップ２０６はオプションのステップである。

【００４３】ローカルディスパッチがステップ２１０で
実行された後、プロセス制御はステップ２１２に進み、
そこで、ジェネリックホルダーがプレローカルディスパ
ッチメソッドからパスされた状態で、クライアント表示
のポストローカルディスパッチメソッドがコールされ
る。ポストローカルディスパッチメソッドはジェネリッ
クホルダーに割り当てられた値（通常、ローカルコール
に関連するデータを含む構造へのポインタを含む）を回
復する。ポストローカルディスパッチメソッドは、事実
上、プレローカルディスパッチ用のクロージャであり、
プレローカルディスパッチオペレーションに対応するハ
ウスキーピングオペレーションを実行させるためにコー
ルされる。例として、ポストローカルディスパッチメソ
ッドは、サーバントオブジェクトを非活性化したり、ト
ランザクションを行なったり、ロックを解除することが
できる。一般に、プレローカルディスパッチとポストロ
ーカルディスパッチは、サブコントラクトのローカル呼
出への参加や介入を可能にする。一旦、ローカルディス
パッチプロセスを終了するためにポストローカルディス
パッチメソッドがコールされると、ローカルスタブを実
行するプロセスが完了する。

【００４４】ローカルフックがコンパイル時に有効にさ
れると、ステップ２０２〜２１２、すなわちプレローカ
ルとポストローカルディスパッチメソッドを利用するメ
ソッドに対するコールが実行されることを理解しなけれ
ばならない。ローカルフックがコンパイル時に有効にさ
れないと、ステップ２１６〜２２０、すなわちプレロー
カルとポストローカルディスパッチメソッドを利用しな
いメソッドへのコールが実行される。換言すれば、ステ
ップ２００の分岐、すなわちローカルフックがアクティ
ブか否かの決定は、そのブランチがコンパイラによって
予め決定できるので、必要がないかもしれない。従っ
て、所定のブランチに関係するコードのみが生成され
る。

【００４５】上述のように、知的なメソッドでオブジェ
クトレファレンスを構築することによって、クライアン
トとサーバーが同一プロセスにある場合に、より短い流
れ経路を利用することが可能になる。知的なメソッドで
オブジェクトレファレンスを構築することは、関係する
オブジェクトレファレンス、すなわち新しいオブジェク
トレファレンスの作成元であるオブジェクトレファレン
スがサーバーに対してローカルであるか否かを決定する
ことを意味する。新オブジェクトレファレンスの作成元
であるオブジェクトレファレンスがサーバーに対してロ
ーカルである場合、ローカルｍテーブルを指示するｍテ
ーブルポインタを持つファットポインタ、すなわちＣＯ
ＲＢＡオブジェクトレファレンスが作成される。新オブ
ジェクトレファレンスの作成元であるオブジェクトレフ
ァレンスがサーバーに対してローカルでない場合、リモ
ートｍテーブルを指示するｍテーブルポインタを持つフ
ァットポインタが作成される。

【００４６】適切なｍテーブルを指示するかそれに添付
されたｍテーブルポインタを使ってファットポインタ、
つまりＣＯＲＢＡオブジェクトレファレンスを作成する
ために、ファットポインタの作成時に、適切なｍテーブ
ルはローカルテーブルかリモートテーブルかに関する決
定を行なわなければならない。オブジェクトレファレン
スの作成のために使用される標準ＣＯＲＢＡ関数は、ク
リエートメソッド、デュプリケートメソッド、ナローメ
ソッド、アンマーシャルメソッド、およびデストリンジ
ファイ(destringify) メソッドを含む。すなわち、デュ
プリケートメソッド、ナローメソッド、アンマーシャル
メソッド、およびデストリンジファイメソッドは、すべ
て、新オブジェクトレファレンスを構築するために使用
できる。従って、これらの各メソッド（および新オブジ
ェクトレファレンスを作成する他の任意のメソッド）に
おいて、サーバントが、作成されるオブジェクトレファ
レンスと同一プロセスにあるか否かに関する決定がなさ
れるなら、より短い流れ経路でローカルリクエストを処
理することが可能となるだろう。つまり、大抵の場合、
かなりの割合のオブジェクト呼出がローカルになるの
で、短い流れ経路の使用は、先に検討したように、オブ
ジェクト呼出の性能の改善に役立つ。

【００４７】次に図７を参照して、本発明の一実施例に
よる、サーバントがローカルかリモート火を決定するオ
ブジェクトレファレンスを複製するプロセスを説明す
る。記載の実施例では、プロセスはステップ２５０で開
始され、オブジェクトレファレンス、つまりオブジェク
ト「レフ」が関連するクライアント表示のデュプリケー
トメソッドに対するコールが行なわれる。複製されるオ
ブジェクトレファレンスのｍテーブルへのポインタは、
クライアント表示のデュプリケートメソッドに対するコ
ールの引数としてパスされる。すなわち、各クライアン
ト表示は、ｍテーブルを引数と見做すデュプリケートメ
ソッドを持つ。コールされるデュプリケートメソッド
は、通常、オブジェクトレファレンスのクライアント表
示によって識別される。デュプリケートメソッドがステ
ップ２５０でコールされた後、プロセス制御はクライア
ント表示のレファレンスカンウントが増分されるステッ
プ２５２か、クライアント表示のコピーが作成されるス
テップ２５６のいずれかに進むことができる。レファレ
ンスカウントがステップ２５２で増分されるか、クライ
アント表示のコピーがステップ２５６で作成されるか
は、クライアント表示のサブコントラクトが参照された
オブジェクトの可測性(accountability)をどのように管
理するかによって決まる。当業者にはよく理解されるよ
うに、様々なメカニズムを使用して特定のクライアント
表示のために存在する顕著なオブジェクトレファレンス
の数をカウントすることができる。例として、レファレ
ンスカウンタを使って同一クライアント表示に関係する
オブジェクトレファレンスの数が追跡される。すなわ
ち、レファレンスカウントは、複製されたオブジェクト
レファレンスがクライアント表示に関連するオブジェク
トレファレンスの数を追跡するためにクライアント表示
に対して作成される毎に増分される。別法として、オブ
ジェクトレファレンスが作成される毎にクライアント表
示の新しいコピーを作ることができる。オブジェクトレ
ファレンスが作成される毎にクライアント表示のコピー
を作成することによって、クライアント表示当たり一つ
しかオブジェクトレファレンスは存在しないので、オブ
ジェクトレファレンスの数を容易にカウントすることが
できる。

【００４８】デュプリケートメソッドのための可測性メ
カニズムがレファレンスカウントの増分化を含む場合、
プロセス制御はステップ２５０のデュプリケートメソッ
ドに対するコールからステップ２５２のレファレンスカ
ウントの増分化に移る。レファレンスカウントの増分化
によって、ＯＲＢは新、すなわち複製されたオブジェク
トレファレンスが作成されようといることを知らされ
る。ステップ２５４では、クライアント表示へのポイン
タと、デュプリケートメソッドへのコールに対する引数
として受け取られたｍテーブルポインタの両者を含む新
オブジェクトレファレンスが作成される。サブコントラ
クトは、レファレンスカウントがステップ２５２で増分
されたことによって新オブジェクトレファレンスが作成
されたことを知っている。複製用オブジェクトレファレ
ンスがステップ２５４で作成された後、プロセス制御は
進み、新しく作成されたオブジェクトレファレンスを返
す。レファレンスカウントを増分するステップと、オリ
ジナルのクライアント表示を含むオブジェクトレファレ
ンスを作成するステップとは、オブジェクトレファレン
スを複製するいくつかのメソッドに特有であることを理
解しなければならない。

【００４９】デュプリケートメソッドのための可測性メ
カニズムが、クライアント表示のコピーの作成を含む場
合、プロセス制御は、ステップ２５０のクライアント表
示のデュプリケートメソッドへのコールからステップ２
５６のクライアント表示のコピーの作成に移る。クライ
アント表示のコピーが作成された後、プロセス制御はス
テップ２５８に進み、そこで、クライアント表示のコピ
ーへのポインタと、デュプリケートメソッドへのコール
から受け取られたｍテーブルポインタとを含む新しいオ
ブジェクトレファレンスが作成される。新オブジェクト
レファレンスがステップ２５８で作成された後、プロセ
ス制御は前進して新しく作成されたオブジェクトレファ
レンスを返す。クライアント表示のコピーを作成するス
テップとクライアント表示のコピーへのポインタを含む
オブジェクトレファレンスを作成するステップとは、オ
ブジェクトレファレンスを複製する場合に使用されるい
くつかのメソッドに特有であることを理解しなければな
らない。

【００５０】各サブコントラクトは異なるデュプリケー
トメソッドをそのサブコントラクトに関連するクライア
ント表示に結びつけることを理解しなければならない。
例として、上述のように、レファレンスカウントを増分
させるステップと、オリジナルのクライアント表示を含
むオブジェクトレファレンスを作成するステップとは、
上記メソッドの一つの一部であり、クライアント表示の
コピーを作成するステップと、クライアント表示のコピ
ーを含むオブジェクトレファレンスを作成するステップ
とは、別の上記メソッドの一部である。これらのメソッ
ドは、新しいオブジェクトレファレンスが作成されたと
きは常に、サーバントオブジェクトに接触するサブコン
トラクトに関係する追加処理を含むことができる。

【００５１】デュプリケートメソッドは、通常、クライ
アント表示に関連する他のオペレーション、またはメソ
ッド、によってコールされる。例として、デュプリケー
トメソッドは、ナローメソッド、アンマーシャルメソッ
ド、およびデストリンジファイメソッド等（すべてクラ
イアント表示に属するメソッド）によってコールでき
る。先に検討したように、これらのメソッドがコールさ
れるときに、サーバントがクライアントに対してローカ
ルプロセスにあるか否かを決定することによって、作成
されたオブジェクトレファレンスをローカルまたはリモ
ートｍテーブルのいずれかと関連させることが可能にな
る。それによってローカルプロセスの識別、従ってリク
エストを処理するためのより短い流れ経路の利用が可能
になるので、オブジェクト呼出の性能が改善される。

【００５２】次に図８を参照して、本発明の一実施例に
よる、サーバントがローカルかリモートかを決定するオ
ブジェクトレファレンスをナロー化する(narrowing) メ
ソッドを説明する。オブジェクトレファレンスをナロー
化することは、基本的に、オブジェクトレファレンスを
一般タイプから特定、つまり目標タイプに変換すること
である。オブジェクトレファレンスをナロー化すること
は、オブジェクトレファレンスのコピー作成のために使
用される一メソッドである。異なるサブコントラクトは
異なるナローメソッドを持つ異なるクライアント表示を
持ち得ることを理解しなければならない。オブジェクト
レファレンスをナロー化するプロセスはステップ２８０
で開始され、そこで、クライアント表示のナローメソッ
ドが、関連ローカルまたはリモートｍテーブルを目標タ
イプの引数として使用してコールされる。ステップ２８
２で、ナロー化が達成されるか否かについて決定が行な
われる。ナロー化が達成できないと決定された場合、プ
ロセス制御はステップ２８３で失敗状態を返す。しか
し、ナロー化が達成できる旨ステップ２８２で決定され
た場合、プロセス制御はステップ２８６に進み、サーバ
ントがローカルプロセスにあるか否かの決定が行なわれ
る。サーバントがローカルプロセスにあるか否かの決定
は、サーバントがローカルプロセスにあるか否かを決定
する目的で特別に書かれた関数、例えば上記のＮＥＯ分
散オブジェクトシステムのクライアント表示のイズ＿ロ
ーカルメソッドをコールすることによって行なわれる。
クライアント表示のイズ＿ローカルメソッドは、各サブ
コントラクトとクライアント表示に特有である。ローカ
ルプロセスが単にローカルマシン上で実行されるプロセ
スを指すだけではないことを理解しなければならない。
そうではなく、サーバントがローカルプロセスにあるか
否かの決定は、サーバントが同一プロセスにあるか否か
の決定なのである。ステップ２８６の結果が肯定的な場
合、すなわちサーバントがローカルプロセスにある場
合、クライアント表示のデュプリケートメソッドが、ロ
ーカルｍテーブルを持つナロー化されたオブジェクトレ
ファレンスを作成するために、ローカルｍテーブルを引
数として使用してステップ２８８でコールされる。ナロ
ーメソッドにパスされたｍテーブルは目標インタフェー
ス、つまりナロー化オブジェクトレファレンスが適合す
べきインタフェースに関係するｍテーブルであることを
理解しなければならない。クライアント表示のデュプリ
ケートメソッドは、指定のｍテーブルポインタを含むオ
ブジェクトレファレンスを作成し、図７に関して先に記
載されたように、作成されたオブジェクトレファレンス
を返すだろう。次に、新オブジェクトレファレンスはナ
ローオペレーションの結果として返される。

【００５３】サーバントがローカルプロセスにないとの
決定がステップ２８６で行われた場合、プロセス制御は
ステップ２９０に進み、そこで、リモートｍテーブルを
引数として使用して、クライアント表示のデュプリケー
トメソッドに対するコールが行われる。これが、リモー
トｍテーブルポインタを持つナロー化されたオブジェク
トレファレンスを作成する。再度述べておくが、デュプ
リケートメソッドが、図５に関して先に説明したオブジ
ェクトレファレンスを作成するのである。新オブジェク
トレファレンスは、次に、ナローオペレーションの結果
として返される。

【００５４】クライアント表示が一つのリモートｍテー
ブルと多数のローカルｍテーブルに関連する場合、一
旦、サーバントがローカルプロセスにあるとステップ２
８６で決定されると、プロセス制御は、ローカルｍテー
ブルを持つナロー化されたオブジェクトレファレンスを
作成するステップのステップ２８８と同じ一般的な目的
に役立つステップ２８８ａに進む。しかしながら、ステ
ップ２８８ａは、クライアント表示が関連する一つ以上
のローカルｍテーブルが存在するときは、ナロー化され
たオブジェクトレファレンスの作成に使用すべき適切な
ローカルｍテーブルの識別を含む。全体ステップ２８８
ａはサーバントオブジェクトを実装するための適切なｍ
テーブルを識別するステップであるステップ２９２を含
む。適切なｍテーブルの識別は、サブコントラクト、す
なわちクライアント表示固有のステップである。例とし
て、サブコントラクトに関連するインプリメンテーショ
ンレポジトリを使用して、クライアント表示によって表
されたサーバントオブジェクトの実装に適したローカル
ｍテーブルを配置することができる。多数の関連ｍテー
ブルを持つクライアント表示の場合、ナローメソッドへ
の引数としてパスされるローカルｍテーブルは、そのロ
ーカルｍテーブルがサーバントオブジェクトの実装に適
したローカルｍテーブルであると判明しない限り、通常
使用されない。一旦、適切なローカルｍテーブルが識別
されると、クライアント表示のデュプリケートメソッド
が、ローカルｍテーブルポインタを持つナロー化オブジ
ェクトレファレンスを作成するために、ローカルｍテー
ブルを引数として使用してステップ２９２でコールされ
る。次に、ナロー化オブジェクトレファレンスがコーラ
ーに返される。

【００５５】代表的な分散オブジェクト指向システムで
オブジェクトレファレンスを作成する他のメカニズムも
存在する。そのようなメカニズムの一つは、リクエスト
または回答の中で引用されるオブジェクトレファレンス
のアンマーシャルである。当業者にはよく理解されるよ
うに、ネットワークの通信ラインまたはプロセス内通信
ポートを介して転送される情報は、通常、マーシャルバ
ッファで受け取られる。受信された情報は、選ばれたネ
ットワークまたはプロセス内通信プロトコルに関連する
フォーマットで着信する。アンマーシャルとは、マーシ
ャルバッファで受け取った情報を、非ネットワーク環境
で有意のフォーマットに変換するプロセスのことを指
す。

【００５６】分散オブジェクト指向環境では、クライア
ントとサーバー間の大部分の通信は、リクエストや回答
の目標であるオブジェクトの識別を意図するオブジェク
トレファレンスで開始される。リクエストや回答も、通
常、追加情報を含み、その情報は、目標オブジェクトへ
の伝達のためのインタフェースパラメータ、例外パラメ
ータ、データ等の形を取ることができる。時には、リク
エストや回答を伴うデータおよび／またはパラメータ
は、リクエストや回答を伝送するために使用されるのに
反して、目標オブジェクトに伝達されると予想される追
加のオブジェクトレファレンスを含むこともある。アン
マーシャル用のメカニズムは、少なくとも一部分、目標
オブジェクトレファレンスに基づいてリクエストを正し
く伝送するとともに、目標オブジェクトによって使用で
きる形に追加情報を（必要に応じて）変換するように、
構成しなければならない。かくして、オブジェクトレフ
ァレンスが目標オブジェクトに伝達すべきパラメータや
他のデータの一部であるときは、アンマーシャル関数
は、目標プロセスに有意なオブジェクトレファレンスを
効果的に作成しなければならない。これはオブジェクト
レファレンスを作成する別の潜在的メカニズムであるか
ら、「データ」オブジェクトレファレンスが、リクエス
トや回答を受け取っているプロセスに対する「ローカ
ル」オブジェクトを指すのか「リモート」オブジェクト
を指すかを決定することが大切である。

【００５７】次に図９を参照して、本発明の一実施例に
よる、リクエストと回答に記載されるデータオブジェク
トレファレンスをアンマーシャルするメソッドを説明す
る。データオブジェクトレファレンスのインタフェース
タイプが分かっている限り、適切なタイプのデータオブ
ジェクトレファレンス用のＯＲＢ提供のジェネリックア
ンマーシャル用ルーチンに対するコールがステップ３０
０で行なわれる。この例の目的では、データオブジェク
トレファレンスに関連するインタフェースを「インタフ
ェースＹ」と呼ぶ。アンマーシャルメソッドは、インタ
フェースＹ用マーシャルバッファと共に、インタフェー
スＹ用リモートｍテーブルへのポインタとインタフェー
スＹ用ローカルｍテーブルへのポインタの両者を持つＯ
ＲＢ提供のジェネリックアンマーシャル用ルーチンをコ
ールする。

【００５８】ＯＲＢによって提供されたジェネリックア
ンマーシャル用ルーチンがコールされた後、データオブ
ジェクトレファレンスに関連するサブコントラクト識別
子、すなわちサブコントラクトＩＤがステップ３０３で
取得される。オブジェクトレファレンス内のサブコント
ラクト識別子の場所が分かっているので、「ピーク」メ
ソッドを使用してデータオブジェクトレファレンス内か
らサブコントラクト識別子を取得できる。ピークメソッ
ドは、抽出はしないが、マーシャルバッファの既知の場
所からサブコントラクト識別子を読み取る。一旦、オブ
ジェクトレファレンス用のサブコントラクトＩＤが分か
ると、オブジェクトレファレンスに対応するアンマーシ
ャル関数が、サブコントラクトＩＤをキーとして使って
サブコントラクトレジストリで調査される。ステップ
３０６で求められたアンマーシャル関数は、インタフェ
ースＹに関連する引数、すなわちリモートとローカルの
ｍテーブル、ならびにマーシャルバッファを使って、ス
テップ３０９でコールされる。アンマーシャル関数への
コールの後、プロセス制御はステップ３１２に進み、そ
こで、マーシャルバッファ内の情報からクライアント表
示が作成される。次に、マーシャルバッファポインタが
マーシャルバッファ内の次のアイテムに「加え」れらる
か、移される。ステップ３１５では、作成されたクライ
アント表示のホスト識別子とサーバー識別子、すなわち
ホストＩＤとサーバーＩＤとが、現行プロセスのホスト
ＩＤおよびサーバーＩＤと同一か否か決定される。それ
に従って、クライアント表示のローカルフラグが、次
に、ステップ３１５でセットされる。すなわち、オブジ
ェクトレファレンスから抽出されたホストＩＤおよびサ
ーバーＩＤが現行プロセスのホストＩＤおよびサーバー
ＩＤとマッチした場合、ローカルフラグはローカルサー
バントを示す状態にセットされる。さもなければ、ロー
カルフラグはリモートサーバントを示す状態にセットさ
れる。ステップ３２０では、サーバントがローカルプロ
セスにあるか否か決定される。図８に関して先に説明し
たように、サーバントがローカルプロセスにあるか否か
の決定は、サーバントがローカルプロセスにあるか否か
を決定するために特別に書かれたクライアント表示固有
関数をコールすることによって行なわれる。この場合、
その関数がクライアント表示のローカルフラグをチェッ
クする。サーバントがローカルプロセスにある場合、プ
ロセス制御はステップ３２３に進み、クライアント表示
のデュプリケートメソッドへのコールが、ローカルｍテ
ーブルを持つアンマーシャルされたオブジェクトレファ
レンスを作成するために、ローカルｍテーブルを引数と
して使用して行なわれる。次に、新しく作成されたアン
マーシャルされたオブジェクトレファレンスが返され
る。

【００５９】クライアント表示が、一つのリモートｍテ
ーブルと多数のローカルｍテーブルに関連する場合、一
旦、サーバントがローカルプロセスにある旨ステップ３
２０で決定されると、プロセス制御はステップ３２３ａ
に進む。ステップ３２３ａは、ローカルｍテーブルを持
つアンマーシャルされたオブジェクトレファレンスを作
成するステップであるステップ３２３と同じ全体的な目
的に役立つ。しかしながら、ステップ３２３ａは、クラ
イアント表示が関連する一つ以上のローカルｍテーブル
が存在するときは、ナロー化されたオブジェクトレファ
レンスの作成に使用するための適切なローカルｍテーブ
ルの識別を含む。全体ステップ３２３ａは、サーバント
オブジェクトの実装用の適切なｍテーブルを識別するス
テップのステップ３２４を含む。適切なｍテーブルの識
別は、サブコントラクト、すなわちクライアント表示固
有ステップである。複数の関連ｍテーブルを持つクライ
アント表示のケースでは、アンマーシャルメソッドへの
引数としてパスされるローカルｍテーブルは、ローカル
ｍテーブルがサーバントオブジェクトの実装用の適切な
ローカルｍテーブルであると判明しない限り、通常、使
用されない。一旦、適切なローカルｍテーブルが識別さ
れると、クライアント表示のデュプリケートメソッド
が、ローカルｍテーブルポインタを持つアンマーシャル
されたオブジェクトレファレンスを作成するために、ロ
ーカルｍテーブルを引数として使用してステップ３２５
でコールされる。次の、そのアンマーシャルされたオブ
ジェクトレファレンスがコーラーに返される。

【００６０】サーバントがローカルプロセスにない旨ス
テップ３２０で決定された場合、プロセス制御はステッ
プ３２０からステップ３２６に進み、そこで、リモート
ｍテーブルを持つアンマーシャルされたオブジェクトレ
ファレンスを作成するために、クライアント表示のデュ
プリケートメソッドがリモートｍテーブルを引数として
使ってコールされる。ステップ３２６が完了すると、ア
ンマーシャルされたオブジェクトレファレンスが返され
る。クライアント表示のデュプリケートメソッドに対す
るコールは図５に関して上記で説明されている。

【００６１】次に図１０を参照して、マーシャルバッフ
ァの情報からクライアント表示を作成する別のメソッド
を、既知のタイプのインタフェース用のオブジェクトレ
ファレンスをアンマーシャルする関連において説明す
る。この実施例では、オブジェクトレファレンスをアン
マーシャルするプロセスは、クライアント表示を作成す
るステップまでは図９に記載のプロセスと同一である。
クライアント表示の作成はステップ３３０で開始され、
そこで、オブジェクトレファレンスに関係する情報がマ
ーシャルバッファから抽出される。ステップ３３０は枠
３２１ａの一部であり、適切なマーシャル関数を調べる
ステップの、図７のステップ３０６から直接に続く。オ
ブジェクトレファレンスに関係する情報がステップ３３
０でマーシャルバッファから抽出された後、ステップ３
３２で、参照されたサーバントオブジェクトレファレン
ス用のクライアント表示がすでの存在しているか否かの
決定が行なわれる。決定の結果が否定的な場合、プロセ
ス制御はステップ３３４に進み、そこで、クライアント
表示が、ステップ３３０で先に抽出されたオブジェクト
レファレンスに関係する情報を使って作成される。次
に、ステップ３１５ａで、新しく作成されたクライアン
ト表示の中のホストＩＤとサーバーＩＤとが現行プロセ
スのホストＩＤおよびサーバーＩＤと同一か否かについ
ての決定が行なわれる。一旦、決定が行なわれると、ク
ライアント表示のローカルフラグがそれに従ってセット
される。サーバントが同一プロセスにあるか否かを決定
するために使用されるメカニズムには、違いがあること
を理解しなければならない。例として、ホスト内コール
がサポートされない実施例では、ホストＩＤは使用され
ないだろう。一旦、ローカルフラグがセットされると、
次にプロセス制御はステップ３２０に進む。このステッ
プは、図９に関して上記に説明したように、適当なサー
バントがローカルプロセスにあるか否かを決定するステ
ップである。オブジェクトレファレンスのためのクライ
アント表示がすでに存在している旨ステップ３３２で決
定された場合、プロセス制御はステップ３３２から直接
にステップ３２０に進み、適切なサーバントがローカル
プロセスにあるか否かの決定が行なわれる。一旦、プロ
セス制御が、適切なサーバントはローカルプロセスにあ
るか否かを決定するステップ、すなわちステップ３２０
に到達すると、既知のタイプを持つインタフェース用の
オブジェクトレファレンスをアンマーシャルするステッ
プの残りは、図９に関して先に説明したものと同一ステ
ップである。

【００６２】図１１を参照して、本発明の一実施例によ
る、サーバントがローカルかリモートかを決定するオブ
ジェクトレファレンスをデストリンジファイ(destringi
fying)するメソッドを説明する。オブジェクトレファレ
ンスを「デストリンジファイ」するとは、ＡＳＣＩＩ文
字列を受取用プロセスによって理解可能なオブジェクト
レファレンスに変換することを意味する。すなわち、オ
ブジェクトレファレンスのデストリンジファイは、ＡＳ
ＣＩＩ文字列の「ディヘクシファイ(dehexifying) 」を
必要とする。デストリンジファイのプロセスは新オブジ
ェクトレファレンスの作成をもたらし、記載の実施例で
はステップ３５０で開始され、そこで、ストリンジファ
イされたオブジェクトレファレンスであるＡＳＣＩＩ文
字列が、マーシャルバッファによってデコードするのに
適した文字列に変換される。記載の実施例では、文字列
はマーシャルバッファによってデコードするのに適した
オクテットの二進ストリング、つまりストリームであ
る。ＡＳＣＩＩ文字列は、通常、文字列の初めにヘッダ
ーを含むことに注意しなければならない。ＡＳＣＩＩ文
字列がオクテットの二進ストリームに変換されると、ヘ
ッダーは無視、すなわち完全にマスクされる。オクテッ
トの二進ストリームが形成された後、プロセス制御はス
テップ３５２に進み、そこで、オクテットの二進ストリ
ームのためのマーシャルバッファが作成される。次にス
テップ３５４で、アンマーシャルメソッドのＣＯＲＢＡ
オブジェクト版がコールされる。すなわち、図７に関し
て上述したアンマーシャルメソッドが、インタフェース
Ｙ用のオブジェクトレファレンスをアンマーシャルする
ためにコールされる。この場合、既知のタイプのインタ
フェース、すなわちインタフェースＹは、ＣＯＲＢＡオ
ブジェクト、すなわちＹ＝ＣＯＲＢＡ：：Ｏｂｊｅｃｔ
である。アンマーシャルメソッドがコールされた後、デ
ストリンジファイされたオブジェクトレファレンスが返
される。

【００６３】上記に説明したメソッド、すなわちナロ
ー、アンマーシャル、およびデストリンジファイメソッ
ドも、オブジェクトレファレンスを作成するために使用
できる。これらのメソッドにはクライアント表示のデュ
プリケートメソッドをコールできるものもあれば、でき
ないものもある。一般に、ＯＲＢに固有のインプリメン
テーション定義、インタフェース定義、およびユーザー
によって提供されるレファレンスデータが分かっている
か与えられると、オブジェクトレファレンスをサーバン
トから作成することができる。インプリメンテーション
定義は現行プロセスのホストＩＤとサーバーＩＤとを含
む。インプリメンテーション定義、インタフェース定
義、およびレファレンスデータが分かっていれば、オブ
ジェクトレファレンスを作成するために明白なオブジェ
クトアダプタを必要としない。しかしながら、レファレ
ンスデータを明白に規定する必要がある場合は、オブジ
ェクトレファレンスを作成するためにオブジェクトアダ
プタが必要である。

【００６４】次に図１２を参照して、本発明の一実施例
による、サーバントがローカルかリモートかを決定する
オブジェクトレファレンスを作成するメソッドを、オブ
ジェクトアダプタ（ＯＡ）を使用してオブジェクトレフ
ァレンスの作成に関連して説明する。ＯＡは引数として
インプリメンテーション定義（例えばＮＥＯ分散オブジ
ェクトシステムにおけるＩＭＰＬ＿ＤＥＦ）、インタフ
ェース定義（例えばＩＮＴＦ＿ＤＥＦ）、およびレファ
レンスデータ（例えばＲＥＦ＿ＤＡＴＡ）を使用して、
ローカルプロセスのオブジェクトレファレンスインタフ
ェースを作成する。この実施例では、ＩＮＴＦ＿ＤＥＦ
の使用はオプションである。プロセスはステップ４０２
で開始され、そこで、引数ＩＭＰＬ＿ＤＥＦを使って、
作成すべきオブジェクトレファレンスに関連するサブコ
ントラクトが決定される。ＩＭＰＬ＿ＤＥＦは、どのサ
ブコントラクトが適切であるかを決定することによっ
て、使用すべきサブコントラクトを識別する。ステップ
４０４では、ＩＭＰＬ＿ＤＥＦによって識別されたサブ
コントラクトに適したクライアント表示が、「クリエー
ト」引数、すなわちクライアント表示の作成に必要な情
報を規定する引数で提供された情報を使って作成され
る。適切なクライアント表示が作成された後、プロセス
の流れはステップ４０６に進み、そこで、作成されたク
ライアント表示の中のホストＩＤとサーバーＩＤが、現
行プロセスのホストＩＤおよびサーバーＩＤと同一か否
かの決定が行なわれる。一旦、決定が行なわれると、そ
れに従ってクライアント表示のローカルフラグがセット
される。プロセス制御は、次に、ステップ４０８に進
み、作成されたクライアント表示が現行プロセスに対し
てローカルか否かを示すためにローカルフラグをセット
するか否かの決定が行なわれる。すなわち、ステップ４
０８では、ローカルフラグが正しくセットされているか
否かを決定する。決定が肯定的な場合、すなわち、ロー
カルフラグが正しくセットされている旨決定された場
合、ステップ４１０で、クライアント表示のデュプリケ
ートメソッドへのコールがＣＯＲＢＡオブジェクトロー
カルｍテーブルへのポインタを使って行なわれる。次い
で、結果が返される。

【００６５】クライアント表示が２つ以上の関連ローカ
ルｍテーブルを持つ場合、一旦、ローカルフラグが正し
くセットされると、プロセスの流れはステップ４１０ａ
に移る。ステップ４１０ａは、クライアント表示が関連
する２つ以上のローカルｍテーブルが存在するときは、
ナロー化オブジェクトレファレンスを作成する場合に使
用すべき適切なローカルｍテーブルの識別を含む。全体
ステップ４１０ａは、サーバントオブジェクトの実装の
ための適切なｍテーブルを識別するステップであるステ
ップ４１１を含む。適切なｍテーブルの識別は、サブコ
ントラクト、すなわちクライアント表示固有のステップ
である。多数の関連ｍテーブルを持つクライアント表示
の場合には、ローカルｍテーブルがサーバントオブジェ
クトの実装用の適切なローカルｍテーブルであると判明
しない限り、ナローメソッドに対する引数としてパスさ
れるローカルｍテーブルは、通常、使用されない。一
旦、適切なローカルｍテーブルが識別されると、識別さ
れたＣＯＲＢＡオブジェクトローカルｍテーブルへのポ
インタを使って、ステップ４１３で、クライアント表示
のデュプリケートメソッドに対するコールが行なわれ
る。デュプリケートメソッドへのコールの後、コールの
結果が返される。

【００６６】ローカルフラグがセットされていないか、
間違ってセットされている旨ステップ４０８で決定され
た場合、プロセス制御はステップ４１２に進み、そこ
で、クライアント表示デュプリケートメソッドに対する
コールが、ＣＯＲＢＡオブジェクトのリモートｍテーブ
ルへのポインタを使って行なわれる。ＣＯＲＢＡオブジ
ェクトリモートｍテーブルによるクライアント表示のデ
ュプリケートメソッドに対するコールが完了すると、コ
ールの結果が返される。

【００６７】先に記載したように、インプリメンテーシ
ョン定義、インタフェース定義、およびレファレンスデ
ータが提供されると、オブジェクトレファレンスのサー
バントベースの作成が、通常、可能である。レファレン
スデータが提供されず、それを規定しなければならない
場合、図１２に関して説明したように、オブジェクトレ
ファレンスを作成するためにオブジェクトアダプタが必
要である。しかしながら、レファレンスデータが提供さ
れた場合、オブジェクトレファレンスを作成するための
ナロー、アンマーシャル、またはデストリンジファイメ
ソッドの使用に代わるものとして、オブジェクトレファ
レンスを作成するためのサーバー表示の使用がある。サ
ーバー表示は、サーバントと同一のプロセスにあるが、
オブジェクトレファレンスを作成するために使用でき
る。サーバー表示がオブジェクトレファレンスを作成す
るので、作成されたオブジェクトレファレンスはサーバ
ントと同一プロセスにある。

【００６８】次に図１３を参照して、サーバー表示を使
ってオブジェクトレファレンスを作成するプロセスを説
明する。用語のサーバー表示、つまりサーバー「レプ」
と、サーバント表示、つまりサーバント「レプ」とは、
互換性をもって使用できることを理解しなければならな
い。リモートとローカルｍテーブルを引数として、サー
バントに付されたサーバー表示によってオブジェクトレ
ファレンスが作成される。ステップ４５０では、サーバ
ー表示に対応するクライアント表示が作成される。関連
するサブコントラクトに適したクライアント表示の作成
に必要な引数は、サーバー表示の中で発見することがで
きる。クライアント表示が作成された後、プロセス制御
はステップ４５２に進み、そこで、クライアント表示と
ローカルｍテーブルへのポインタとを含むオブジェク
ト、つまりオブジェクトレファレンスが作成される。次
に、ステップ４５４で、新たに作成されたオブジェクト
レファレンスが返される前にサーバーと同一プロセスの
クライアント表示が作成されたことを示すために、ロー
カルフラグを正しくセットすることができる。ローカル
フラグを正しくセットすることは、クライアント表示、
すなわちオブジェクトレファレンスが、サーバントと同
一プロセスにあることを示す。

【００６９】本発明は、上記のように、コンピュータシ
ステムに格納されるデータを伴う様々なプロセスステッ
プを使用する。これらのステップは物理量の物理的操作
を必要とするステップである。通常、必ずしもそうでは
ないが、これらの量は格納、転送、結合、比較、その他
の操作が可能な電気的または磁気的信号の形を取る。主
として一般的慣行の理由で、これらの信号をビット、バ
リュー、エレメント、変数、キャラクタ、データ構造等
と呼ぶと便利な場合がある。しかしながら、これらの用
語や類似の用語は、すべて、適切な物理量に関連される
べきであり、また、これらの量に付される単なる便利な
ラベルに過ぎないことを忘れてはならない。

【００７０】更に、実行される操作は識別、実行、また
は比較等の用語で呼ばれることが多い。本発明の一部を
形成する、本明細書に記載のオペレーションでは、これ
らのオペレーションはマシンオペレーションである。本
発明のオペレーションを実行するために便利なマシン
は、汎用ディジタルコンピュータやその他類似の装置を
含む。いずれにしても、コンピュータを操作する場合の
オペレーションのメソッドと、計算自体のメソッドとの
相違を忘れてはならない。本発明は、電気的またはその
他の物理的信号を処理して他の望ましい物理信号を発生
させる場合の、コンピュータを操作するためのメソッド
ステップに関する。

【００７１】本発明は、これらのオペレーションを実行
する装置にも関係する。この装置は、要求される目的の
ために特別に製造してもよいし、また、それはコンピュ
ータに格納されたコンピュータプログラムによって選択
的に作動されるか再構成される汎用コンピュータでもよ
い。本明細書で提示されるプロセスは、特定のコンピュ
ータやその他装置に固有の関係を持つものではない。特
に本明細書の教示に従って書かれたプログラムを使って
様々な汎用マシンを使用できるし、また、要求されるメ
ソッドステップを実行するためにより特殊化された装置
を製造する方が便利な場合もある。これらの様々なマシ
ンに必要な構造は上記の説明から明らかであろう。

【００７２】また、本発明は、更に、様々なコンピュー
タ実装オペレーションを実行するためのプログラム命令
を含むコンピュータ読取り可能メディアに関係する。メ
ディアとプログラム命令は、本発明の目的のために特別
に設計、製造されたものでよいし、また、コンピュータ
ソフトウェア技術の専門家に周知の利用可能な類のもの
でもよい。コンピュータ読取り可能メディアの例は、こ
れに限定されるわけではないが、ハードディスク、フロ
ッピーディスク、および磁気テープ等の磁気メディア；
ＣＤ−ＲＯＭディスク等の光学メディア；オプティカル
ディスク等の磁気光学的メディア；およびプログラム命
令を格納、実行するために特別に構成されたハードウェ
アディバイス、例えばリードオンリーメモリ（ＲＯＭ）
およびランダムアクセスメモリ（ＲＡＭ）を含む。プロ
グラム命令の例は、コンパイラによって製作されたマシ
ンコードと、インタプリタを使ってコンピュータによっ
て実行されるハイレベルのコードを含むファイルの両者
を含む。

【００７３】図１４は、本発明による典型的なコンピュ
ータシステムを示す。コンピュータシステム５００は、
主記憶装置５０４（通常、リードオンリーメモリ、また
はＲＯＭと呼ぶ）、および主記憶装置５０６（通常、ラ
ンダムアクセスメモリ、またはＲＡＭと呼ぶ）を含む記
憶装置に連結された任意の数のプロセッサ５０２（中央
処理装置、つまりＣＰＵとも呼ぶ）を含む。当業者には
周知のように、ＲＯＭ５０４は、データと命令をＣＰＵ
に一方向的に転送する働きがあり、ＲＡＭ５０６は、通
常、データと命令を双方向的に転送するために使用され
る。主記憶装置５０４、５０６は、共に、上記のように
任意の適切なコンピュータ読取り可能媒体を含むことが
できる。大容量記憶装置５０８もＣＰＵ５０２に双方向
的に連結されて、追加のデータ記憶容量を提供する。大
容量記憶装置５０８はプログラム、データ等を格納する
ために使用され、通常、主記憶装置５０４、５０６より
も遅いハードディスク等の二次記憶媒体である。大容量
記憶装置５０８は、磁気または紙テープリーダーやその
他の周知の装置の形を取ることができる。大容量記憶装
置５０８内に保持される情報は、適切な場合に、バーチ
ュアルメモリとして、ＲＡＭ５０６の一部として標準的
に組み込まれることはよく理解されるだろう。ＣＤ−Ｒ
ＯＭ５１４等の特定の大容量記憶装置もデータを一方向
的にＣＰＵに送る。

【００７４】ＣＰＵ５０２も、これに限定されるわけで
はないが、ビデオモニタ、トラックボール、マウス、キ
ーボード、マイクロホン、タッチセンシティブディスプ
レイ、トランスデューサカードリーダ、磁気または紙テ
ープレコーダ、タブレット、スタイラス、音声や手書き
の認識装置、その他の周知の入力装置、例えば、勿論、
他のコンピュータ等の、一つ以上の入出力装置５１０に
連結される。最後に、ＣＰＵ５０２は、オプションとし
て、５１２で概略的に示されるネットワーク接続を使用
してコンピュータや通信ネットワークに連結することが
できる。上記のネットワーク接続によって、ＣＰＵは、
上記のメソッドステップを実行する中でネットワークか
らの情報を受け取ったり、ネットワークに情報を出力す
るものと予想される。上記の装置と材料は、コンピュー
タハードウェアとソフトウェア技術の専門家には周知の
ものであろう。

【００７５】本発明の実施例を一つだけ説明したが、本
発明は、その精神と範囲から逸脱することなく、他の多
くの形式で具体化し得ることは言うまでもない。特に、
本発明に関して記載されたｍテーブルは多くの異なる形
を取ることができる。例として、これらの形は、これに
限定されるわけではないが、従来のＣ＋＋ｖテーブルに
似た構造を持つフラットｍテーブル、およびツリー構造
のｍテーブルを含む。従って、記載の実施例は説明のた
めであって、限定のためではないと見做すべきであり、
本発明は下記クレームならびにそれらに相当する仕様に
よって定義されるものとする。

【図面の簡単な説明】

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

【図２】クライアントによるリクエストが、分散オブジ
ェクトシステムのクライアント側とサーバー側のアーキ
テクチャ、および分散オブジェクトシステムのクライア
ント側とサーバー側の間のインターフェースを介してど
のように流れるかを示す概略説明図である。

【図３】オブジェクトレファレンスの概略表示図であ
る。

【図４】ファットポインタ、クライアント表示、および
分散オブジェクトレファレンスに関連するメソッドの間
のインタフェースの概略説明図である。

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

【図６】本発明の一実施例による、ローカルスタブの処
理に係わるステップを説明するプロセス流れ図である。

【図７】本発明の一実施例による、オブジェクトレファ
レンスを複製する(duplicating) 処理に係わるステップ
を説明するプロセス流れ図である。

【図８】本発明の一実施例による、オブジェクトレファ
レンスをナロー化する(narrowing) 処理に係わるステッ
プを説明するプロセス流れ図である。

【図９】本発明の一実施例による、オブジェクトレファ
レンスをアンマーシャル(unmarshaling)する処理に係わ
るステップを説明するプロセス流れ図である。

【図１０】本発明の一実施例による、図７に示すオブジ
ェクトレファレンスをアンマーシャルする処理において
マーシャルバッファの情報からクライアント表示を作成
するステップのための代替メソッドを説明するプロセス
流れ図である。

【図１１】本発明の一実施例による、オブジェクトレフ
ァレンスをデストリンジファイする(destringifying)処
理に係わるステップを説明するプロセス流れ図である。

【図１２】本発明の一実施例による、オブジェクトレフ
ァレンスを作成するためのオブジェクトアダプタの使用
に係わるステップを説明するプロセス流れ図である。

【図１３】本発明の一実施例による、オブジェクトレフ
ァレンスを作成するためのサーバー表示の使用に係わる
ステップを説明するプロセス流れ図である。

【図１４】本発明による代表的なコンピュータシステム
の説明図である。

フロントページの続き (72)発明者ピータービー．ケスラーアメリカ合衆国，カリフォルニア州，パロアルト，ヴァードサドライヴ 4121 (72)発明者サンジェイアール．ラディアアメリカ合衆国，カリフォルニア州，フリーモント，ボアーサークル 883 (72)発明者グラハムハミルトンアメリカ合衆国，カリフォルニア州，パロアルト，デイヴィッドコート 3143

Claims

【特許請求の範囲】

【請求項１】トランスポート層と、該トランスポート層
の上にあるクライアント側の、複数のローカルメソッド
テーブルと複数のリモートメソッドテーブルとを含むメ
ソッドテーブルディスパッチ層、とを含む、クライアン
トオブジェクトからサーバントオブジェクトへコールを
ディスパッチするためのディスパッチメカニズムを有す
る分散クライアント／サーバー・ベースのコンピューテ
ィングシステムにおいて、第１セットの選択されたクラ
イアント表示がローカルメソッドテーブルと関連すると
共に第２セットの選択されたクライアント表示がリモー
トメソッドテーブルと関連し、クライアントからサーバ
ントへコールを伝送するメソッドが、該クライアントとサーバントが同一プロセスを共有しな
いときは、リモートメソッドテーブルと該トランスポー
ト層を使って該コールを伝送するステップ、および
該クライアントとサーバントが同一プロセスを共有す
るときは、ローカルメソッドテーブルを使い、かつ該ト
ランスポート層をバイパスすることによって該コールを
伝送するステップ、を含むメソッド。
【請求項２】関連オブジェクトを独特なメソッドで識別
するオブジェクトレファレンスを利用するように構成さ
れた分散クライアント／サーバー・べースのコンピュー
ティングシステムにおいて、サービスのためのリクエストを示す複数のクライアント
表示であって、各オブジェクトレファレンスは関連する
クライアント表示を有し、選択されたクライアント表示
は複数の異なるオブジェクトレファレンスと関連し得る
ように成したクライアント表示、呼び出しリクエストがトランスポート層を介して伝送さ
れるように構成された、第１セットの該クライアント表
示に関連したリモートディスパッチメソッド、を識別す
るように構成されたリモートメソッドテーブル、および
呼び出しリクエストがトランスポート層を介して伝送さ
れることなくサーバントにパスするように構成された、
第２セットの該クライアント表示に関連したローカルデ
ィスパッチメソッド、を識別するように構成されたロー
カルメソッドテーブル、を含む構成。
【請求項３】該オブジェクトレファレンスがそれぞれ関
連クライアント表示を識別するように構成された第１ポ
インタと、該メソッドテーブルの中の関連する一つを識
別するように構成された第２ポインタとを含むように成
した、請求項２に記載の構成。
【請求項４】各メソッドテーブルは関連スタブを識別す
るように構成された複数のポインタを含み、かつ該メソ
ッドテーブルの中の選択された一つへのポインタを含む
各オブジェクトレファレンスが、該選択されたメソッド
テーブルによって指示された関連スタブを有するように
成した請求項２または３に記載の構成。
【請求項５】複数のリモートメソッドテーブルが、該第
１セットのクライアント表示に関連するリモートディス
パッチメソッドを識別するように構成されると共に、複
数のローカルメソッドテーブルが、該第２セットのクラ
イアント表示に関連するローカルディスパッチメソッド
を識別するように構成された請求項２、３または４に記
載の構成。
【請求項６】該複数のクライアントの少なくとも一部
が、関連リモートメソッドテーブルと関連ローカルメソ
ッドテーブルの両者を有するように成した請求項２〜５
のいずれかに記載の構成。
【請求項７】クライアント表示に関連するリモートメソ
ッドテーブルとローカルメソッドテーブルの少なくとも
一方を有する複数のクライアント表示を持つ分散クライ
アント／サーバー・ベースのコンピューティングシステ
ムにおいて、サーバントオブジェクトを識別するオブジェクトレファ
レンスをナロー化するための、クライアントプロセス内
で受け取られるリクエスト、を受け取るステップ、該リクエストによって識別される該サーバントオブジェ
クトが該クライアントプロセスにあるか否かを決定する
プロセス、および該リクエストによって識別された該サ
ーバントオブジェクトが該クライアントプロセスにある
時は、ローカルメソッドテーブルを識別するナロー化さ
れたオブジェクトレファレンスを作成するステップ、を
含む、オブジェクトレファレンスをナロー化するメソッ
ド。
【請求項８】該リクエストによって識別された該サーバ
ントオブジェクトが該クライアントプロセスにないと決
定されたときに、リモートメソッドテーブルを識別する
ナロー化されたオブジェクトレファレンスを作成するよ
うに成した請求項７に記載のメソッド。
【請求項９】クライアント表示に関連するローカルｍテ
ーブルとリモートｍテーブルの一方を有する複数のクラ
イアント表示を持つ分散クライアント／サーバー・ベー
スのコンピューティングシステムにおいて、サーバントオブジェクトを識別するオブジェクトレファ
レンスをアンマーシャルするための、クライアントプロ
セス内で受け取られるアンマーシャル用リクエストを受
け取るステップ、該リクエストによって識別された該サーバントオブジェ
クトが該クライアントプロセスにあるか否かを決定する
ステップ、該リクエストによって識別された該サーバントオブジェ
クトが該クライアントプロセスにあると決定されたとき
は、ローカルメソッドテーブルを識別するアンマーシャ
ルされたオブジェクトレファレンスを作成するステッ
プ、および該リクエストによって識別された該サーバン
トオブジェクトが該クライアントプロセスにないと決定
されたときは、リモートメソッドテーブルを識別するア
ンマーシャルされたオブジェクトレファレンスを作成す
るステップ、を含む、オブジェクトレファレンスをアン
マーシャルするメソッド。
【請求項１０】オブジェクトレファレンスをアンマーシ
ャルするための該リクエストが、クライアント表示に関
連する該ローカルメソッドテーブルと該リモートメソッ
ドテーブルの一方を使ってクライアント表示のアンマー
シャル関数をコールするステップを備えるように成した
請求項９に記載のメソッド。
【請求項１１】該クライアント表示がそれに関連する複
数の異なるローカルメソッドテーブルを有する、クレー
ム９または１０に記載のメソッドであって、更に、該ク
ライアント表示に関連するローカルメソッドテーブルの
中の特定の一つを選択するステップを含み、また該アン
マーシャル関数への該コールが該選択されたローカルメ
ソッドテーブルによって行なわれるように成した、メソ
ッド。
【請求項１２】クライアント表示に関連するローカルス
タブとリモートスタブの一方を有する複数のクライアン
ト表示を持つ分散クライアント／サーバー・ベースのコ
ンピューティングシステムにおいて、該ストリンジファイされた(stringified) オブジェクト
レファレンスを、マーシャルバッファによるデコードに
適した二進ストリングに変換するステップ、該二進ストリングをカプセル化するためにマーシャルバ
ッファを取得するステップ、および該マーシャルバッフ
ァの内容をアンマーシャルするメソッドを呼び出すステ
ップであって、該アンマーシャルは請求項９、１０また
は１１のいずれか一つのメソッドを利用することによっ
て達成されるように成した呼出ステップ、を含む、スト
リンジファイされたオブジェクトレファレンスをデスト
リンジファイするメソッド。
【請求項１３】該ストリンジファイされたオブジェクト
はＡＳＣＩＩストリンジファイドオブジェクトである請
求項１２に記載のメソッド。
【請求項１４】分散クライアント／サーバー・ベースの
コンピューティングシステムにおいて、その関数が該クライアント／サーバー・ベースのオブジ
ェクト指向オペレーティングシステムによって実行され
るべき追加コードを含むか否かを示すように構成された
ローカルフックを含む、該クライアントに関連するクラ
イアント表示、によって指示された関数をコールするス
テップ、該クライアント表示によって指示された該関数が、該ク
ライアントに対してローカルプロセスにあるスタブ関数
であるローカルスタブ関数か否かを決定するステップ、
および該クライアント表示によって指示された該関数が
該ローカルスタブ関数であると決定されたときは、該ロ
ーカルスタブ関数を実行するステップ、を含む、サーバ
ントをクライアントから呼び出すメソッド。
【請求項１５】該ローカルスタブ関数を実行するステッ
プは、更に、下記のステップを備えるように成した、請
求項１４に記載のメソッド：追加コードを実行すべきこ
とを該クライアント表示の該ローカルフックが示すか否
かを決定するステップ、該クライアント表示の該ローカルフックがアクティブで
あると決定されたときに、該クライアント表示に関する
情報を収集するように構成された、該クライアント表示
のプレローカルディスパッチメソッド、をコールするス
テップ、該クライアント表示から該サーバントを取得するステッ
プ、該サーバントにおいて識別された、ローカルディスパッ
チメソッドであるメソッド、をコールするステップ、お
よび該プレローカルディスパッチメソッドに関連した、
該クライアント表示のポストローカルディスパッチメソ
ッド、をコールするステップ。
【請求項１６】該プレローカルディスパッチメソッドと
該ポストローカルディスパッチメソッドの間で情報をパ
スするように構成された総称的ホルダーが該プレローカ
ルディスパッチメソッドの該コールにパスされるように
成した請求項１５に記載のメソッド。
【請求項１７】該プレローカルディスパッチメソッドが
該クライアントからコールを受け取るための該サーバン
トを準備するように成した請求項１５または１６に記載
のメソッド。
【請求項１８】該ポストローカルディスパッチメソッド
が該サーバントを非活性化するように成した請求項１
５、１６、または１７に記載のメソッド。
【請求項１９】分散オブジェクトコンピューティングシ
ステム内の分散サーバーオブジェクト上で定義されたオ
ブジェクトメソッドを呼び出すためにコンピュータ読取
り可能コードが具体化されているコンピュータ使用可能
媒体を備えたコンピュータプログラムプロダクトであっ
て、該分散オブジェクトコンピューティングシステムは
関連オブジェクトを独特のメソッドで識別するオブジェ
クトレファレンスを利用するように構成され、該コンピ
ュータプログラムプロダクトは、サービスのためのリクエストを示す複数のクライアント
表示であって、各オブジェクトレファレンスは関連する
クライアント表示を有し、選択されたクライアント表示
が複数の異なるオブジェクトレファレンスと関連し得る
ようなクライアント表示、第１セットの該クライアント表示に関連する、呼出リク
エストがトランスポート層を介して伝送されるように構
成されたリモートディスパッチメソッド、を識別するよ
うに構成されたリモートメソッドテーブル、および第２
セットの該クライアント表示に関連する、呼出リクエス
トがトランスポート層を介して伝送されることなくサー
バントにパスするように構成されたローカルディスパッ
チメソッド、を識別するように構成されたローカルメソ
ッドテーブル、を備えた、構成用のコンピュータ読取り
可能プログラムコードを備えたコンピュータプログラム
プロダクト。
【請求項２０】該オブジェクトレファレンスが、それぞ
れ、関連するクライアント表示を識別するように構成さ
れた第１ポインタと、該メソッドテーブルの中の関連す
る一つを識別するように構成された第２ポインタとを含
むように成した、請求項１９に記載の、構成用のコンピ
ュータ読取り可能プログラムコードを備えたコンピュー
タプログラムプロダクト。
【請求項２１】各メソッドテーブルが、関連スタブを識
別するように構成された複数のポインタを含み、該メソ
ッドテーブルの中の選択された一つへのポインタを含む
各オブジェクトレファレンスが、該選択されたメソッド
テーブルによって指示される関連スタブを有するように
成した請求項１９または２０に記載の、構成用のコンピ
ュータ読取り可能プログラムコードを備えたコンピュー
タプログラムプロダクト。
【請求項２２】該複数のクライアント表示の少なくとも
一部が、関連リモートメソッドテーブルと関連ローカル
メソッドテーブルの両者を有するように成した請求項１
９、２０、または２１のいずれかに記載の、構成用のコ
ンピュータ読取り可能プログラムコードを備えたコンピ
ュータプログラムプロダクト。
【請求項２３】分散オブジェクトコンピューティングシ
ステム内の分散サーバントオブジェクト上で定義された
オブジェクトメソッドを呼び出すためにコンピュータ読
取り可能コードが具体化されているコンピュータ使用可
能媒体を備えたコンピュータプログラムプロダクトであ
って、該分散オブジェクトコンピューティングシステム
は、クライアント表示に関連するリモートメソッドテー
ブルとローカルメソッドテーブルの少なくとも一方を有
する複数のクライアント表示を持ち、該コンピュータプ
ログラムプロダクトは該コンピュータシステム内に下記
ステップをもたらすためのコンピュータ読取り可能プロ
グラムコードを備えたプロダクト：該サーバントオブジ
ェクトを識別するオブジェクトレファレンスを処理する
ためのリクエストを受け取るステップであって、該ナロ
ー化リクエストはクライアントプロセス内で受け取ら
れ、処理用の該リクエストは、該オブジェクトレファレ
ンスをナロー化するためのリクエストと、該オブジェク
トレファレンスをアンマーシャルするためのリクエスト
の一方であるステップ、該リクエストによって識別された該サーバントオブジェ
クトがクライアントプロセスにあるか否かを決定するス
テップ、該リクエストによって識別された該サーバントオブジェ
クトが該クライアントプロセスにあると決定されたとき
は、ローカルメソッドテーブルを識別する処理されたオ
ブジェクトレファレンスを作成するステップ、および該
リクエストによって識別された該サーバントオブジェク
トが該クライアントプロセスにないと決定されたとき
は、リモートメソッドテーブルを識別する処理されたオ
ブジェクトレファレンスを作成するステップ。
【請求項２４】オブジェクトレファレンスをナロー化す
るための該リクエストが、それに関連する該ローカルメ
ソッドテーブルと該リモートメソッドテーブルの一方に
よってクライアント表示のナロー関数をコールするステ
ップを備えた、請求項２３に記載の、コンピュータ読取
り可能プログラムコードを備えたコンピュータプログラ
ムプロダクト。
【請求項２５】該クライアント表示が、それに関連する
複数の異なるローカルメソッドテーブルを有する、請求
項２３または２４に記載の、コンピュータ読取り可能プ
ログラムコードを備えたコンピュータプログラムプロダ
クトであって、該メソッドは、更に、該クライアント表
示に関連する該ローカルメソッドテーブルの中の特定の
一つを選択するステップを備え、かつ該デュプリケート
関数へのコールは、該選択されたローカルメソッドテー
ブルによって行なわれるように成した、コンピュータプ
ログラムプロダクト。
【請求項２６】オブジェクトレファレンスをアンマーシ
ャルするための該リクエストが、関連する該ローカルメ
ソッドテーブルと該リモートメソッドテーブルの一方に
よってクライアント表示のアンマーシャル関数をコール
するステップを備えた、請求項２３に記載の、コンピュ
ータ読取り可能プログラムコードを備えたコンピュータ
プログラムプロダクト。
【請求項２７】該クライアント表示がそれに関連する複
数の異なるローカルメソッドテーブルを有する、請求項
２３または２６に記載の、コンピュータ読取り可能プロ
グラムコードを備えたコンピュータプログラムプロダク
トであって、該メソッドは、更に、該クライアント表示
に関連する該ローカルメソッドテーブルの中の特定の一
つを選択するステップを備え、かつ該アンマーシャル関
数への該コールが該選択されたローカルメソッドテーブ
ルによって行なわれるように成した、コンピュータプロ
グラムプロダクト。
【請求項２８】分散オブジェクトコンピューティングシ
ステム内の分散サーバーオブジェクト上で定義されたオ
ブジェクトメソッドを呼び出すためにコンピュータ読取
り可能コードが具体化されているコンピュータ使用可能
媒体を備えたコンピュータプログラムプロダクトであっ
て、該コンピュータシステム内に下記のステップをもた
らすためのコンピュータ読取り可能プログラムコートを
備えたコンピュータプログラムプロダクト：その関数が
該クライアント／サーバー・ベースの分散オブジェクト
コンピューティングシステムによって実行されるべき追
加コードを含むか否かを示すように構成されたローカル
フックを含む、該クライアントに関連するクライアント
表示、によって指示された関数をコールするステップ、該クライアント表示によって指示された関数が、該クラ
イアントに対してローカルプロセスにあるスタブ関数で
あるローカルスタブ関数であるか否か、を決定するステ
ップ、および該クライアント表示によって指示された該
関数が該ローカルスタブ関数であると決定されたとき
に、該ローカルスタブ関数を実行するステップ。
【請求項２９】該ローカルスタブ関数を実行するステッ
プが、更に、下記のステップを備えるように成した、請
求項２８に記載の、コンピュータ読取り可能プログラム
コードを備えたコンピュータプログラムプロダクト：追
加コードを実行すべきことを該クライアント表示の該ロ
ーカルフックが示すか否か、を決定するステップ、該クライアント表示の該ローカルフックがアクティブで
あると決定されたときに、該クライアント表示に関係す
る情報を収集するように構成された、該クライアント表
示のプレローカルディスパッチメソッド、をコールする
ステップ、該クライアント表示から該サーバントを取得するステッ
プ、ローカルディスパッチメソッドである、該サーバントの
中で識別されたメソッド、をコールするステップ、およ
び該プレローカルディスパッチメソッドに関連する、該
クライアント表示のポストローカルディスパッチメソッ
ド、をコールするステップ。
【請求項３０】該プレローカルディスパッチメソッドと
該ポストローカルディスパッチメソッドの間で情報をパ
スするように構成された総称的ホルダーが、該プレロー
カルディスパッチメソッドにパスされるように成した、
請求項２９に記載の、コンピュータ読取り可能プログラ
ムコードを備えたコンピュータプログラムプロダクト。