JPH1069395A - 分散オブジェクトシステムにおけるリクエスト発送メカニズム - Google Patents

Abstract

(57)【要約】 【課題】分散クライアント／サーバーに基づくコンピュ
ーティングシステムにおいて、分散オブジェクト呼出し
に関連するコンピューティングオーバーヘッドを低減す
るためおよび発送フレームワークの柔軟性を改善するた
めのデータ構造、メソッドおよび装置を開示する。 【解決手段】本発明の一局面において、トランスポート
レヤー内のエンドポイントにおいて受信されたリクエス
トは、トランスポートレヤーからサブコントラクトレヤ
ー内のサブコントラクトへ発送され、そこで部分的にア
ンマーシャルされ、サブコントラクトからスケルトンレ
ヤー内のスケルトン機能へ発送され、そこでサーバント
が呼び出される。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

【０００３】

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

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

【０００５】代表的なクライアント・サーバー・システ
ムにおいては、性能オーバーヘッドが高価になる可能性
がある。すなわち、システム内のプロセスのスピードと
品質が、プロセスからの情報収集とプロセス内の情報回
送とに係わるアプリケーション・コードとメソッドの非
効率的使用によって、妥協させられる可能性がある。例
えば、あるシステムのサーバー側におけるリクエストの
発送に係わる性能オーバーヘッドは、高めであることが
多い。更に、あるクライアント・サーバー・システム内
における内部発送フレームワークを変更すると、普通、
アプリケーション・コードをかなり変更する必要があ
る。すなわち、例えば、あるトランスポートとあるスケ
ルトンとの間の関係を変えようとすると、多くの場合、
かなりの量の内部発送フレームワーク、すなわちアプリ
ケーション・コードを変更する必要がある。更に、クラ
イアント・サーバー・システムは普通、デベロッパーが
供給するアプリケーションコードを効率的に含みかつ実
行することはしない。換言すれば、内部発送フレームワ
ークをカスタマイズ（customize:特殊仕様化）すること
は非効率的であることが多い。その結果、普通の内部発
送フレームワークのフレキシビリティ（柔軟性）の大き
さが限られる。従って、システムのサーバー側における
リクエストの発送に係わる性能オーバーヘッドを低減
し、内部発送フレームワークのフレキシビリティを改善
するメソッドと装置の提供が望まれる。

【０００６】

【課題を解決するための手段】前記事項を達成するた
め、および本発明の目的に従って、分散クライアント／
サーバーに基づくオブジェクト指向オペレーティング・
システムの分散オブジェクト呼出しの発送に係わるコン
ピューティング・オーバーヘッドの低減と発送フレーム
ワークの柔軟性の改善のためのデータ構造、メソッドお
よび装置を開示する。本発明の一局面において、あるト
ランスポートレヤー内のエンドポイント上で受信された
リクエストは、このトランスポートレヤーからサブコン
トラクトレヤー内のサブコントラクトへ発送され、そこ
で部分的にアンマーシャルされる。この部分的にアンマ
ーシャルされたリクエストは次にサブコントラクトから
スケルトンレヤー内のスケルトン機能へ発送され、そこ
でサーバントが関連する。

【０００７】本発明のもう一つの局面において、サブコ
ントラクトが受信したリクエストの少なくとも一部をサ
ブコントラクトがアンマーシャルした後、受信したリク
エストを適当なスケルトンへ発送するようになされたス
ケルトン発送機能を含むサブコントラクトを初期化する
メソッドを開示する。このサブコントラクトの初期化
は、当該サブコントラクトに係わるサブコントラクト・
メタ・オブジェクトの作成ステップと、サブコントラク
ト・メタ・オブジェクトのサブコントラクト・レジスト
リへの保存ステップを含む。いくつかの実施例におい
て、サブコントラクトに係わる専用のエンドポイントが
初期化される。その他の実施例においては、サブコント
ラクトは、少なくとも一つのクラスター・エンドポイン
ト・レジストリとそのクラスター・エンドポイント・レ
ジストリに係わるユニークエンドポイントに登録され
る。

【０００８】本発明の更に一つの局面において、エンド
ポイント・発送レジストリ・データ構造は、関連するサ
ブコントラクトを識別するようになされたサブコントラ
クト識別子と、サブコントラクトに関連する発送機能を
識別するようになされたクロージャとを含む。いくつか
の実施例において、発送機能へのポインターと、発送機
能が用いる情報を含むデータ要素へのポインターとを含
む。

【０００９】

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

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

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

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

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

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

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

【００１６】標準実行スイート２８（またはオブジェク
トアダプター）は、同一のやり方で、例えばオブジェク
ト・キー・マネージメントのように、ＯＲＢオブジェク
ト１４と対話するサブコントラクトの一セットを表す。
サブコントラクトは複数実行スイート(multiple implem
entation suites)に属することに当然注目すべきであ
る。従って、異なるサブコントラクトを用いる他の実行
スイートも可能である。スタティックスケルトン３２ま
たはダイナミックスケルトン３０のいずれかの形をとる
ことのできる一つのスケルトンを用いて、サーバントオ
ブジェクト１４が要求するフォーマットにリクエストを
変換(transform)することができる。このように、スケ
ルトン３０と３２は適当なサーバントオブジェクト１４
をコールする。スタティックスケルトン３２は、特定の
インターフェイスに関するオブジェクト実行１４のコー
ルに用いられ、一方ダイナミックスケルトン３０は特定
のインターフェイスに関するオブジェクトが利用できな
いとき一般的に用いられる。ＯＲＢインターフェイス３
４は、すべてのＯＲＢに関して同じでありかつオブジェ
クトのインターフェイスにもオブジェクトアダプターに
も依存しないＯＲＢへ直接行くインターフェイスであ
る。ＯＲＢデーモン４６は、オブジェクトサーバーがク
ライアントによって呼び出されたとき確実にアクティブ
になるようにする役割をする。オブジェクトサーバーを
スタートさせる技法は、米国特許出願番号08/408,645
に開示されている。

【００１７】セキュア・プロトコル(Secure Protocol)
４２は、インターネット・インターＯＲＢプロトコルを
確保し、情報をトランスポートレヤー３８を介して安全
なメソッドで転送する助けをするセキュア・インターオ
ペラビリティ・プロトコルである。これは、完全性保護
(integrity protection)、機密性(confidentiality)、
等を意味する。インターネット・インターＯＲＢプロト
コルは、普通、別々のマシーン上のプロセス間で通信を
行うプロトコルである。しかし、インターネット・イン
ターＯＲＢプロトコルが同一マシーン上のプロセス間で
通信を行う場合もある。セキュリティ・サーバー５４
は、別々のコンピュータ上のプロセス間で用いられるサ
ービスを確保するセキュリティ管理サーバーである。

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

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

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

【００２１】図２にダイアグラム的に示すように、クラ
イアントがメソッドテーブル（ｍテーブル）ディスパッ
チを用いて行うリクエストは、サーバントに至るまでに
前記アーキテクチャの様々なレヤーを通過する。リクエ
ストはクライアントによって開始され、任意の形をとる
ことができる。リクエストの形は、クライアントの作成
に用いるプログラミング言語の性質に大きく依存する。
例えば、クライアントがＣ＋＋言語で書かれた場合、リ
クエストはＣ＋＋メソッドコール６２の形をとることが
できる。このコールは、サロゲートの形をとる指定オブ
ジェクトレファレンスとされる。サロゲートは、オブジ
ェクトのインターフェイスに適合するメソッドを含む。
当業者には理解できるように、一つの分散オブジェクト
システム内の別々の場所で用いられるオブジェクトレフ
ァレンスは、外観が著しく変化していることがある。上
記実施例においては、クライアント側のオブジェクトレ
ファレンスは二重ポインターである（本明細書では「フ
ァット・ポインター」と呼ぶ）。ファットポインターは
二つの別々の(distinct)ポインター、すなわちロケーシ
ョン・インジケータを含む。第１のポインターは、参照
されるオブジェクトに関するクライアント・レプレゼン
テーション（「クライアント・レプ」）を指す。第２の
ポインターは、参照されるオブジェクトに関するメソッ
ドテーブルディスパッチ２４のメソッドテーブルを指
す。「ポインター」という用語は、本明細書において用
いる場合、コンピュータまたはネットワーク・メモリー
内の場所のみならず広くロケーション・インジケータを
識別するのに用いられることを理解すべきである。クラ
イアント・レプレゼンテーションは、呼び出し(invocat
ion)と、ＣＯＲＢＡによって定義される「疑似」オブジ
ェクトレファレンスオペレーションをサポートするメソ
ッドを持つオブジェクトである。これらのオペレーショ
ンには、「複写(duplicate)」メソッド、「リリース」
メソッド、「狭い」メソッド、「ハッシュ（細断）」メ
ソッド、および「同等である」メソッドを含むが、これ
らに限らない。

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

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

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

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

【００２６】トランスポートレヤー３８の一部分である
Ｔ１，Ｔ２などのトランスポートメカニズムは、サーバ
ントオブジェクトとの間で情報をマーシャルしてやり取
りするのに用いられる。情報すなわちオブジェクトレフ
ァレンスまたはリクエストは、ある与えられたドメイン
に適したプロトコルへ変換される。例えば、プロトコル
はイーサーネットプロトコルとインターネット・インタ
ーオペラブル・プロトコル（ＩＩＯＰｓ）を含むが、こ
れらに限らない。いくつかのまれな場合において、プロ
トコルはサーバー上で実行されるべき命令を伝達するた
め電子メールの使用さえ必要とするかも知れない。情報
のマーシャル後、トランスポートメカニズムは次に、す
べて分散オブジェクトシステムのクライアント側が用い
るハードウェア７０の一部であるオペレーティングシス
テム、デバイスドライバー、またはネットワークの任意
の組合せを介して、情報を送る。トランスポートメカニ
ズムは、ある与えられたドメインに適したプロトコルへ
の情報の変換を必要とするが、いくつかのトランスポー
トメカニズムは、別々のドメインに関する情報のエンコ
ーディングを必要としない。情報源以外のドメインに適
したプロトコルへの情報変換を必要としないトランスポ
ートメカニズムを「ドア」（ｄｏｏｒ）と称する。ドア
は基本的には、同一ホスト上の二つの異なるプロセス間
のゲートウェイ（出入り口）である。ドアを用いると、
トランスポートレヤー３８において情報を規範的実行(c
anonical implementation)へ変換する必要がなくなる。
その理由は、情報を一つの異なるマシンが用いるプロト
コルへエンコードする必要がないからであり、これは、
情報が同一ホスト上に残っており、従ってドメインの変
更を必要としないという事実に基づく。従って、情報は
簡単に「平らに延ばされ」、すなわち一つの流れへとマ
ーシャルされ、これは一つの異なるマシンによって用い
られるようにエンコードされず、ホスト上の二つのプロ
セス間でやり取りされる。

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

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

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

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

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

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

【００３３】内部発送メカニズム・フレームワークは、
それが用いられるとき一般にかなりの量のオーバーヘッ
ドを必要とする。その理由は、特定のリクエストの回送
に用いる適当な発送メカニズムを決定するため、サーバ
ー内において普通、内部サーチを行わねばならないから
である。特定のリクエストの回送に用いる発送メカニズ
ムは普通、１）リクエストの発生元、２）サーバー側の
場合、リクエストを受信するエンドポイント、および
３）リクエストされたサーバーメソッドを呼び出すため
に用いられるスケルトン、を含む多様な要因に依存す
る。また、内部発送メカニズム・フレームワークの任意
の部分に何らかの変更が加えられると、普通、コードの
かなりの部分の変更を要する。更に、内部発送メカニズ
ム・フレームワークは普通、デベロッパーによって供給
される外部アプリケーション・コードを効率的に実行し
ない。従って、内部発送メカニズム・フレームワークは
一般的に、当該フレームワークへの変更が既存のコード
への変更であるか、あるいは当該フレームワークへの変
更が、アプリケーション・デベロッパーによって与えら
れる外部コードの追加に係わるかに関係なく、当該フレ
ームワークへの変更を速やかに行うという点においてフ
レキシブルでない。

【００３４】上記の欠点を克服するため、本発明は、ト
ランスポートレヤーとスケルトンレヤーとの間に存在す
るサブコントラクトレヤーの概念を利用する、多層発送
メカニズムフレームワークを利用する。そのような３層
発送メカニズムを関連データ構造とともに用いると、発
送リクエストに係わるオーバーヘッドを低減するととも
に、フレームワークのフレキシビリティを増大させるこ
とができる。発送層（ディスパッチ・レヤー）は、そこ
を介してリクエストが発送されるレベルと見なすことが
できる。ここに説明する実施例においては、トランスポ
ートレヤーは、入ってくるリクエストを受信し、そのリ
クエストをアンマーシャルせずに（サブコントラクト・
レヤー内の複数のサブコントラクトのうち）適当なサブ
コントラクトへ発送する。別の実施例においては、トラ
ンスポートレヤーはリクエストに対して最小量のアンマ
ーシャルを行うことがある。選ばれたサブコントラクト
は、リクエストの少なくとも一部をアンマーシャルし、
適当なスケルトンを識別し、適当なスケルトンへリクエ
ストを発送し、スケルトンは次にサーバーを呼び出す。
この多層アプローチがフレームワークの変更において大
きなフレキシビリティをもたらすことを理解すべきであ
る。具体的には、一つの新しいサブコントラクトまたは
一連のサブコントラクトを書いて実行するだけで全く新
しい発想メカニズムが作成できる。新しいサブコントラ
クト（単数または複数）を実行する場合、トランスポー
トレヤーもスケルトンレヤーも変更する必要がない。当
業者には理解できるように、このことは分散オブジェク
トシステムにおいて新しい特徴および／または機能性を
実行する場合、著しい利点をもたらす。

【００３５】サーバー側におけるリクエストの発送に係
わる性能オーバーヘッドは、データ構造の実行によって
更に低減することができる。例えば、ある与えられたエ
ンドポイントに係わる各（かつ唯一の）発送メカニズム
を識別するエンドポイント発送レジストリを提供するこ
とができる。これによれば、あるエンドポイントに用い
る適当な発送メカニズムは、当該エンドポイントに係わ
る発送メカニズムを含むデータ構造のサーチに絞られ
る。従って、発送メカニズムのサーチに係わる性能オー
バーヘッドを低減することができる。エンドポイント発
送レジストリ・データ構造の一例を図８を参照して説明
する。

【００３６】ここに説明する実施例においてクライアン
ト・サーバー・システムのサーバー側におけるリクエス
トの発送に係わる性能オーバーヘッドを低減するため用
いられる他のデータ構造は、サブコントラクト・レジス
トリ・データ構造と実行レジストリ・データ構造を含
む。サブコントラクト・レジストリ・データ構造と実行
レジストリ・データ構造はそれぞれ、サブコントラクト
と実行定義をリストで示し、これによって、サブコント
ラクトと実行定義のサーチをそれぞれのレジストリ・デ
ータ構造に集中することができる。従って、サブコント
ラクトと実行定義のサーチに用いる資源の数を減らすこ
とができ、その結果システム効率が向上する。適当なサ
ブコントラクト・レジストリ・データ構造と実行レジス
トリ・データ構造をそれぞれ図４と図５に示す。

【００３７】次に図４を参照して本発明の一実施例によ
るサブコントラクト・レジストリ・データ構造２００を
説明する。サブコントラクト・レジストリ・データ構造
２００、あるいは簡単にサブコントラクト・レジストリ
２００は、特定のサービス品質を、ユニークサブコント
ラクト識別子と、およびサブコントラクトクライアント
表現作成機能と、関連づける情報を保存する。サブコン
トラクト・レジストリ２００は、サブコントラクトに付
属する情報をチューブ状に登録し、システム内のサブコ
ントラクトをサーチ用に利用できるようにする。チュー
ブ状の利点は、任意数の実行を一つの特定のサブコント
ラクトに関連づけることを可能にすることである。一つ
のシステム内において所定数の特徴の順列が可能である
が、サブコントラクト・レジストリ２００は、分散オブ
ジェクトシステム内において既に実行されたこれら可能
なサブコントラクトの一つのサブセットのみの識別が可
能であることを理解すべきである。サブコントラクト・
レジストリ２００は、ハッシュテーブル、リンクされた
リスト、またはその他適当なデータ構造として実行する
ことができる。

【００３８】ここに示す実施例においては、サブコント
ラクト・レジストリ２００は、サブコントラクト識別子
（ＳＣＩＤ）コラム２０２、関連サービス品質リストコ
ラム２０４、サブコントラクト・クライアント表現作成
機能コラム２０６、および他の機能へのポインター２０
８を含む。サブコントラクト・レジストリ２００の各列
２００は、サブコントラクト・メタ・オブジェクトと称
し、例えばＣ＋＋オブジェクトとして実行することがで
きる。ここに示す実施例においては、サブコントラクト
・レジストリ２００内に複数のサブコントラクト・メタ
・オブジェクト２１２、２１４および２１６が与えられ
ている。第１サブコントラクト・メタ・オブジェクト２
１２は「１」というサブコントラクト識別子を持ってい
るので、サブコントラクト１として識別される。サブコ
ントラクト１はそのサービス品質に関して下記の特徴を
リストで示す：すなわち、クリーンシャットダウン、安
全性、持続性およびサーバーアクティベーションであ
る。サービス品質リスト中の名称と値のペアは、クリー
ンシャットダウンは実行されないこと、安全性のため認
証プロトコルにはＭＤ５を用いること、および持続性は
ターンオンされることを示す。他の機能コラム２０８内
の各サブコントラクト・メタ・オブジェクトに係わる種
々の他の機能への複数のポインター、すなわちロケーシ
ョン・インジケータは、アンマーシャル機能、デストリ
ンギファイ(destringify)機能、およびバッド・サーバ
ー識別子ハンドラーへのポインターを含む。

【００３９】二番目に図示したサブコントラクト・メタ
・オブジェクト２１４は、サブコントラクト２として識
別されたサブコントラクトに関連するサブコントラクト
・メタ・オブジェクトである。このサブコントラクトに
関するサービス品質リストは、サーバーアクティベーシ
ョンが存在することを示す。第３のサブコントラクト・
メタ・オブジェクト２１６は、サブコントラクト３とし
て識別されたサブコントラクトが処理、クリーンシャッ
トダウン、およびサーバーアクティベーションを可能に
することを示す。

【００４０】サブコントラクトレジストリ２００は普
通、登録をオーガナイズしアクセスするのに用いる関連
諸機能の一グループを持つ。関連諸機能には例えば、追
加機能(Add function)、発見機能(Find function)、ゲ
ット・ファースト機能、およびゲット・ネクスト機能が
含まれる。追加機能は、サービスの新しい品質をテーブ
ルに追加するのに用いることができる。ここで説明する
実施例においては、追加機能は引数としてサブコントラ
クト識別子とサブコントラクト・メタ・オブジェクトを
取る。発見機能は引数としてサブコントラクト識別子を
取り、その識別子に関連するサブコントラクト・メタ・
オブジェクトを返す。ゲット・ファースト機能およびゲ
ット・ネクスト機能は、例えばサブコントラクト・レジ
ストリ２００のような、サブコントラクト・レジストリ
を繰り返すのに用いられ、このようにしてそれを完全に
サーチし、適当なメタ・オブジェクトを返す。クライア
ントが一つのオブジェクト・レファレンス（Ｃ＋＋言語
のファット・ポインターでもよい）を得ようとする場
合、サブコントラクトレジストリ２００を用いて当該サ
ーバーオブジェクトに関連するサブコントラクト識別子
をルックアップ（検索）する。適当なサブコントラクト
識別子が見つかれば、適当な特徴を用いて特定のサーバ
ーオブジェクトに適したクライアント表現を作成するた
め、適当なサブコントラクトクライアント表現機能をコ
ールする。Ｃ＋＋実施例においては、ファット・ポイン
ターはこのクライアント表現を参照する。

【００４１】図５を参照して、本発明の一実施例による
実行レジストリ・データ構造２５０を説明する。クライ
アント・サーバー・システム内の各オブジェクトは普
通、一つの実行定義に関連づけられている。一つのオブ
ジェクトに関する各実行定義は、実行名、オブジェクト
作成に用いるサブコントラクト、当該オブジェクトに関
するインターフェイス識別子、当該オブジェクトに関す
る一セットのコールバック機能、およびスケルトンに関
連する情報などの情報を含む。コールバック機能は一つ
のオブジェクト内に保存することができる。実行レジス
トリ２５０は様々な実行定義に対応するエントリーを持
っている。実行レジストリ２５０を用いて、インプレメ
ンター（実行者）は、同じオブジェクトサーバー内の単
一ＯＲＢオブジェクトタイプの多重の別々の実行を提供
することができる。すなわち、一つのオブジェクトタイ
プが、別々の実行識別子によって識別される様々な実行
を持つことができる。各実行は、すべてのオペレーショ
ンに関する挙動と、それがサポートするインターフェイ
スの属性を定義する。すなわち、各インターフェイスが
多くの実行を持つことができる。従って、各実行識別子
は、特定のサブコントラクトを用いる一つのオブジェク
トに関して一つの明確な実行を表す。更に、各実行は、
一つのサブコントラクト・ポインターを介して一つの異
なるサブコントラクトを用いることができる。このよう
にして、実行レジストリ２５０は、呼び出し機能が特定
の実行を選ぶことを可能にし、この実行が次にサブコン
トラクトレジストリの必要なサブコントラクトを用いる
ことができるので、クライアント・サーバー・システム
の全体効率改善に寄与する。

【００４２】各実行定義は、保存されているデータへの
ポインターを含む実行レジストリ２５０内の一つのエン
トリーを表す。実行レジストリ２５０は、実行を指名す
る実行識別子コラム２５２、サブコントラクト・メタ・
オブジェクト・コラム２５４、インターフェイス識別子
コラム２５６、レディ・フラッグ(Ready Flag)コラム２
５７、コールバック機能コラム２５８、およびスケルト
ン情報コラム２５９を含む。実行識別子コラム２５２内
の実行識別子は、実行定義が作成されるときデベロッパ
ーによって供給される実行に関する名称である。サブコ
ントラクト・メタ・オブジェクト・ポインターは、図４
を参照して上に説明したように、特定の実行定義からサ
ブコントラクトレジストリに含まれるサブコントラクト
・メタ・オブジェクトへのポインターである。インター
フェイス識別子は、特定のインターフェイスの固定され
た包括的に(globally)ユニークなタイプ名である。いく
つかの実施例において、レディ・フラッグは、特定の実
行定義に係わる実行の使用準備が完了していることを示
すように設定することのできるブール・フラッグ(boole
an flag)である。スケルトン情報は、特定の実行にかか
わるスケルトンが用いる機能を含む。コールバック機能
は、各実行にかかわる複数の機能の複数セットである。
一つの特定の実行には広く多様なコールバック機能が係
わることができる。コールバック機能は例えば、ルック
アップ機能、不活性化機能およびシャットダウン機能を
含むが、これらに限らない。

【００４３】実行定義エントリー２６２は、実行レジス
トリ２５０内で見いだされる実行定義の例である。実行
定義エントリー２６２は、PRINTER INTERFACE というイ
ンターフェイスの PRINTER 実行用であって、例えば図
４のサブコントラクト・レジストリ２００のサブコント
ラクト１のようなサブコントラクト・レジストリ内のサ
ブコントラクト１へのポインターを持っている。サブコ
ントラクト・レジストリ内のサブコントラクトへのポイ
ンターは、ある与えられた実行に関する適当なサブコン
トラクトを識別するサブコントラクト・メタ・オブジェ
クト・ポインターである。実行定義２６２はまたユニー
クコールバック機能と、それが関連する１個のユニーク
・スケルトン発送機能も持っている。

【００４４】この実行レジストリ２５０には、レジスト
リの組織的形成と、レジストリへのアクセスを容易にす
ることを意図する種々の関連機能を持っている。例え
ば、特定の実行識別子を持った実行定義を実行レジスト
リ２５０へ追加するため、追加(Add)という機能を用い
ることができる。同様に、ファインド(Find)機能へのコ
ールは引数として実行識別子を取ることができ、実行識
別子によって識別された実行定義を返すため、実行レジ
ストリ２５０全体をサーチすることができる。実行定義
を実行レジストリ２５０にリストとして示すことによ
り、実行定義のサーチに係わる性能オーバーヘッドを減
らすことができる。実行レジストリ２５０は、ハッシュ
テーブル、リンクされたリスト、または任意の他の適当
なデータ構造として実行することができることを理解す
べきである。

【００４５】複数の発送層(dispatch layers)すなわち
レベルを利用する内部発送メカニズムのフレキシビリテ
ィは、リクエストを一つのレベルから次のレベルへ回送
するのに用いる発送メカニズムに対する変更が、後続の
レベルとの間の発送メカニズムに影響を及ぼさずにで
き、改善される。すなわち、フレームワークの二つのレ
ベル間で用いられる発送メソッドへの変更が、必ずしも
フレームワークの他の後続の複数レベル間の発送メソッ
ドへの変更を必要とせず、フレキシビリティが高められ
る。

【００４６】図２を参照して上に説明した分散オブジェ
クトシステムのサーバー側の内部発送メカニズムは３レ
ベル発送メカニズムと呼ぶことができる。この発送メカ
ニズムの３層は、トランスポートレヤーである第１レベ
ル、サブコントラクトレヤーである第２レベル、および
スケルトンレヤーとサーバントオブジェクトレヤーを含
む第３レベルである。トランスポートレヤーは、トラン
スポートレヤー内のエンドポイント上で受信したリクエ
ストを、エンドポイントに係わるサブコントラクトレヤ
ー内の適当なサブコントラクトへ発送する。サブコント
ラクトとトランスポート・エンドポイントとの間の関連
は、１：１、１：多数、多数：１、または多数：多数の
いずれかのマッピングであることを理解すべきである。
サブコントラクトレヤー内のサブコントラクトがリクエ
ストを受信した後、リクエストはスケルトンレヤー内の
適当なスケルトンへ発送される。

【００４７】トランスポートレヤーからサブコントラク
トレヤーへのリクエストの発送に用いることのできる一
つのメカニズムは、クロージャ(closure)、更に具体的
にはサブコントラクト発送クロージャである。クロージ
ャは、発送機能へのポインターと、データ要素へのポイ
ンターとを含み、これは「クッキー」と呼ばれることが
ある。クッキーは、クロージャが作成されるとき、サブ
コントラクトレヤーによって与えられる。クッキーは、
着信リクエストを処理するため特定のサブコントラクト
が要求するデータを参照する。従って、データ要素は各
サブコントラクトの要求によって異なる。更に、データ
要素は、同じサブコントラクトについても、コールが異
なるサーバントオブジェクトへ発送されると、異なる可
能性がある。

【００４８】トランスポートレヤー内のエンドポイント
上のもう一つのドメインからリクエストを受信すると、
リクエストはサブコントラクトレヤー内のサブコントラ
クトへ発送される。実行されるべき実際のサブコントラ
クト・コンピューテーションは、サブコントラクトに係
わるクロージャによって識別される。サブコントラクト
が初期化されると、サブコントラクトはサブコントラク
トへリクエストを発送することのできるエンドポイント
に「縛られる」、すなわち関連づけられる。

【００４９】次に図６を参照し、本発明の一実施例によ
るサブコントラクトの初期化のメソッドを説明する。ス
テップ４０３において、サブコントラクトに関連する任
意の「専用」エンドポイントを初期化する。専用エンド
ポイントを全く持たないサブコントラクトと、複数の専
用エンドポイントを持つサブコントラクトがあることを
理解すべきである。サブコントラクトの初期化の後、サ
ブコントラクトは更に必要に応じて追加の専用エンドポ
イントを作成または初期化することができる。図２につ
いて上に説明したように、専用エンドポイントは唯一の
サブコントラクトに関連づけられたエンドポイントであ
る。専用エンドポイントの一例は同一ホスト上の複数の
プロセス間のゲートウェイであるドアである。ドアは、
情報を別のドメインで使用するためエンコードせずに、
二つのプロセス間で送ることを可能にする。専用エンド
ポイントの初期化のプロセスを、図７を参照して以下更
に詳しく説明する。専用エンドポイントの初期化後、プ
ロセスコントロールはステップ４０５に移行し、そこで
サブコントラクトは関連する「クラスター」エンドポイ
ントに登録される。図２について上に述べたように、ク
ラスター・エンドポイントは複数のサブコントラクトに
関連づけることのできるエンドポイントである。代表的
なエンドポイント発送レジストリを以下に図８を参照し
て説明する。サブコントラクトの実際の登録は、サブコ
ントラクト識別子とサブコントラクト発送クロージャを
引数として、クラスター・エンドポイントの登録機能を
コールして行うことができる。

【００５０】関連するクラスター・エンドポイントにサ
ブコントラクトが登録された後、ステップ４０７におい
てサブコントラクト・メタ・オブジェクトが作成され
る。換言すれば、ステップ４０７は、図２に関連して上
記のように、サブコントラクトをサブコントラクト・レ
ジストリに登録するステップである。サブコントラクト
・メタ・オブジェクトは、特定のサブコントラクトを関
連するオブジェクトへ「接続する」サブコントラクト・
レジストリ内のデータ構造である。すなわち、サブコン
トラクト・メタ・オブジェクトは、サブコントラクト識
別子を用いてサブコントラクトをオブジェクトに関連づ
ける情報のコレクションである。サブコントラクト・メ
タ・オブジェクトは、サービス品質リスト、サブコント
ラクト・クライアント・表現作成機能、および、例えば
アンマーシャル機能のような、ある与えられたサブコン
トラクトに関連づけられた他の機能を含むが、これらに
限らない。サブコントラクト・メタ・オブジェクトが作
成された後、プロセスコントロールはステップ４０７へ
移行し、そこでサブコントラクト・メタ・オブジェクト
はサブコントラクト・レジストリに保存される。サブコ
ントラクト・メタ・オブジェクトがサブコントラクト・
レジストリに保存されて、サブコントラクトの初期化プ
ロセスが完了する。

【００５１】次に図７を参照し、本発明の一実施例によ
る専用エンドポイントの初期化のメソッドを説明する。
すなわち、図６のステップ４０３の実行、サブコントラ
クトに関する専用エンドポイントの初期化のステップを
説明する。専用エンドポイントの初期化のステップはス
テップ４２１から始まり、ここでサブコントラクト発送
クロージャを引数として「専用エンドポイント作成」機
能へコールを行う。専用エンドポイント作成用機能は、
エンドポイントが係わるトランスポートに依存する。ス
テップ４２３において専用エンドポイントが作成され
る。専用エンドポイントが作成された後、ステップ４２
５において新しく作成された専用エンドポイントに、サ
ブコントラクト発送クロージャが結びつけられる。作成
されたエンドポイントにサブコントラクト発送クロージ
ャが結びつけられて、専用エンドポイントの初期化のス
テップは完了する。

【００５２】図８は、本発明の一実施例によるエンドポ
イント・レジストリ・データ構造４５０を示す。複数の
サブコントラクトをサポートする各エンドポイントは、
関連するエンドポイント・レジストリ、すなわちエンド
ポイント発送レジストリを持つことができる。従って、
図６を参照すると、クラスター・エンドポイントに関連
する任意のサブコントラクトは普通、当該クラスター・
エンドポイントに関するエンドポイント・レジストリに
追加される。エンドポイント・レジストリ４５０は、複
数のキー４５２のリストと、キー４５２に関連するクロ
ージャ４５４とからなる。キー４５２は普通、サブコン
トラクト識別子（ＳＣＩＤ）である。ここに説明する実
施例においては、サブコントラクト識別子は、図１ｃに
ついて上に説明したように、オブジェクトレファレンス
の一部であるオブジェクトキーの最初の４バイトとして
エンコードされる。しかし、代替の実施例においては、
サブコントラクト識別子の形、サイズ、場所、および内
容は広く多様である。いずれにしても、複数のサブコン
トラクトをサポートするクラスター・エンドポイントを
実行するトランスポートメカニズムは、呼び出し中のタ
ーゲットオブジェクトのサブコントラクト識別子を得る
のに適したロジックを含む。通常、エンドポイントはト
ランスポートによって実行され、トランスポートは、リ
クエストメッセージ内のターゲット・オブジェクト・レ
ファレンスのエンコーディングを決定するトランスポー
ト・プロトコルによって決定される。

【００５３】一般的にクロージャは、ある状態を保持す
る「メッセージ」をその上に持ったクロージャである。
例えばクロージャ４５４のようなクロージャは、発送４
５６、すなわち発送機能へのポインターと、メモリーの
一小片内のデータ要素へのポインターを含む。具体的に
は、データ要素へのポインターは、関連する発送機能４
５６にとって重要であるデータを不透明にする(opaque)
ポインターである。ここに説明する実施例においては、
データ要素へのポインターはクッキー４５８として知ら
れている。エンドポイントは、関連するクロージャ４５
４とともに特定のサブコントラクトへマップすることが
でき、これはエンドポイント・レジストリ４５８を用い
て見いだされた発送機能４５６とクッキー４５８へのポ
インターを保持する。すなわち、キー４５２としてサブ
コントラクト識別子が与えられると、クロージャ４５４
の場所を見いだすことができる。見いだされたクロージ
ャ４５４を用いて、次に、キー４５２によって識別され
るサブコントラクトによって与えられる発送機能４５６
を正しくコールし、コールを処理する。クッキー４５８
は、コールを処理するためサブコントラクトによって維
持され要求されるデータを指示し、引数として発送機能
４５６へ送られる。

【００５４】ここに説明する実施例において、エンドポ
イントレジストリは、クラスター・エンドポイント（す
なわち２個以上のサブコントラクトと関連づけられるエ
ンドポイント）とのみ関連づけられる。適当な発送メソ
ッドを決定するため、サブコントラクト識別子をエンド
ポイント・レジストリ内のキーとして用いることは、サ
ブコントラクトのための適当な発送メソッドのための効
率的なメカニズムである。

【００５５】先に述べたように、サーバー上の受信リク
エストをトランスポートレヤーからサブコントラクトレ
ヤーへ、次にサブコントラクトレヤーからスケルトンレ
ヤーとサーバントオブジェクトへ発送するのに、３レベ
ル発送メカニズムを用いることができる。サブコントラ
クトとサブコントラクトレヤーとを用いることは、特
に、スケルトンレヤーをトランスポートレヤーからデカ
ップリングする(dcoupling:切り離す)目的を達成する。
このようにスケルトンレヤーとトランスポートレヤーを
サブコントラクトレヤーから切り離すことは、モジュー
ル状のフレームワークをもたらし、発送フレームワーク
全体への変更を容易にする。すなわち、サブコントラク
トレヤーがインターフェイスレヤーの役割を果たし、発
送フレームワークへの変更を直ちに行うことができる。
図８について上記に説明したように、エンドポイント・
レジストリを用いて、適当なクロージャを、従って発送
メソッドを見いだすことができ、トランスポートレヤー
内のエンドポイント上の受信リクエストをサブコントラ
クトレヤー内の適当なサブコントラクトへ送ることがで
きる。リクエストを適当なサブコントラクトへ送るのに
用いる発送メソッドを、ここではサブコントラクト宛ト
ランスポート発送メソッド(trnasport to subcontract
dispatch method)と呼ぶこととする。

【００５６】リクエストをサブコントラクトレヤーから
スケルトンレヤーとサーバントオブジェクトへ発送する
のに用いる特定のメソッドは、サブコントラクトを用い
る実行スイートに依存する。すなわち、リクエストをス
ケルトンレヤーへ発送するのに用いるメソッド（スケル
トン発送メソッドとしても知られている）は、システム
上で発送が実行される特定のクライアント・サーバー・
システムと呼び出される特定のオブジェクトの両方に依
存する。例えば、持続性オブジェクト(persistent obje
ct)を呼び出す場合に用いる実行スイートは、例えばロ
ーオーバーヘッドオブジェクトアダプター（ＬＯＡ:Low
-overhead Object Adaptor）である。持続性オブジェク
トの呼出しに適したサブコントラクトからスケルトンレ
ヤーへの発送メカニズムを以下、図９、１０、１１を参
照して説明する。

【００５７】サブコントラクトからスケルトンレヤーへ
の発送メカニズムは、発送メカニズムが関連するシステ
ムとサーバー上において呼出され中のオブジェクトに依
存して大幅に変わることを理解すべきである。例えば、
トランジエント（一時的）オブジェクトの呼出しに用い
る発送メカニズムは、持続性オブジェクトの呼出しに用
いる発送メカニズムとは異なる可能性がある。一時的オ
ブジェクトの発送に係わるオーバーヘッドは、持続性オ
ブジェクトのそれより通常は少ないので、一時的オブジ
ェクトの発送に別の発送メカニズムを用いると、一時的
オブジェクトの呼出しの全プロセス効率を改善すること
ができる。一時的オブジェクトの呼出し用に適したサブ
コントラクトからスケルトンレヤーへの発送メカニズム
の一例を図１２、１３、１４を参照して以下に説明す
る。

【００５８】次に図９を参照して、本発明の一実施例に
従って持続性オブジェクトを発送するのに適したスケル
トン発送機能をコールするメソッドを説明する。このプ
ロセスは、トランスポートレヤーがサブコントラクト識
別子（ＳＣＩＤ）を用いて特定のサブコントラクトに関
する発送機能をコールした後、開始される。いくつかの
実施例においては、例えばドア・エンドポイントのよう
なエンドポイントは、唯一の関連サブコントラクトを、
従って唯一の発送機能を持つことがある。その他の実施
例においては、図８について上記に説明したように、エ
ンドポイントは、サブコントラクト識別子によって識別
される適当なサブコントラクトへのリクエストの発送に
用いる適当な発送機能の決定に用いることのできるエン
ドポイント発送レジストリを持つことができる。図３に
示すように、サブコントラクト識別子はオブジェクトレ
ファレンス内に含まれている。従ってトランスポートレ
ヤーは、適当なサブコントラクトにアクセスするのに、
どの発送機能をコールすべきか決定するため、このサブ
コントラクト識別子において「のぞき見る」ことができ
る。いくつかの実施例において、このサブコントラクト
識別子においてのぞき見るため、ＰＥＥＫ ＳＣＩＤメ
ソッドを用いることができる。

【００５９】適当なサブコントラクトへのアクセスが行
われた後、ステップ７０２においてマーシャルバッファ
ー内のオブジェクトレファレンスからサブコントラクト
識別子が抽出される。抽出のプロセスは、マーシャルバ
ッファーから取出された当該情報は、もはやマーシャル
バッファーにおいて利用不可能であることを意味する。
次にステップ７０４において、この抽出されたサブコン
トラクト識別子を、現在使用中のサブコントラクトと比
較して、適切なサブコントラクトが使用中であるか、確
認する。前記のように、アプリケーションの開発者は、
オブジェクト開発中、サブコントラクト識別子を用い
て、特定のサブコントラクトを一つのオブジェクトに関
連づける。

【００６０】ステップ７０６において、マーシャルバッ
ファー内のオブジェクトレファレンスからサーバー識別
子（ＩＤ）が抽出される。この呼出しの主題であるサー
バーオブジェクトは、ホストコンピュータ上の特定のサ
ーバープロセス内に存在するので、このサーバー識別子
が現行のサーバーの識別子にマッチすることを確認する
ことが重要である。ステップ７０８において、この抽出
されたサーバー識別子を現行のサーバーの識別子と比較
してオブジェクトレファレンスが適切なサーバープロセ
スを参照しているか否か、判定する。ステップ７１０
は、抽出されたサーバー識別子が有効であるか、また現
行のサーバーに実際にマッチするか否か、判定する。こ
の現行のサーバーがマッチしないということは、当該サ
ーバー識別子が無効であり、適当な処置を取るべきこと
を示している。この処置は、バッドサーバー識別子ハン
ドラー機能を用いて取ることができる。ステップ７１２
は、適当なバッドサーバー識別子ハンドラーが、現行の
サブコントラクトに係わるサブコントラクト・メタ・オ
ブジェクトに登録されているか否かの判定である。サブ
コントラクト識別子が既にオブジェクトレファレンスか
ら抽出されているので、このステップは図４のサブコン
トラクトレジストリを用いて行われる。サブコントラク
ト識別子は、現行のサブコントラクトに係わるバッドサ
ーバー識別子ハンドラーが存在するか否か判定するため
「他の機能」のコラムをサーチできるようにする、サブ
コントラクトレジストリの特定の列へのキーとして作用
する。このハンドラーが存在しない場合、ステップ７１
６においてシステムはこの状況に関する例外を設け、発
送機能は終了する。しかしもしハンドラーがサブコント
ラクト・メタ・オブジェクトに登録されていれば、登録
されているバッドサーバー識別子ハンドラーは、サブコ
ントラクト識別子とマーシャルバッファーとを引数とし
てステップ７１４においてコールされる。

【００６１】ここで、抽出されたサーバー識別子が有効
であるか否かの判定であるステップ７１０に戻り、抽出
されたサーバー識別子が実際に現行のサーバーにマッチ
する場合、プロセスコントロールはステップ７１８に移
行し、そこでマーシャルバッファー内のオブジェクトレ
ファレンスから実行識別子が抽出される。この抽出され
た実行識別子を、ステップ７２０において図５の実行レ
ジストリへのキーとして用いて、実行識別子に対応する
実行定義を見いだす。実行レジストリの使用は、図５を
参照して上記に説明した。適当な実行レジストリを見い
だすステップは、ステップ７１８において抽出された実
行識別子がレジストリ内に存在するか否か判定するた
め、実行レジストリの可能な実行識別子のコラム全体を
サーチすることによって概念的に行うことができる。

【００６２】次に図１０を参照して、図９を参照して説
明したように、本発明の一実施例による持続性オブジェ
クトの発送に適したスケルトン発送機能における残りの
ステップを説明する。ステップ７２２において、適当な
実行定義が実行レジストリ内において見いだされたか否
か判定する。ステップ７２２において適当な実行定義が
見いだされない場合、ステップ７２４においてこの状態
に関する例外が設けられ、発送機能は終了する。しか
し、適当な実行定義が見いだされた場合、プロセスの流
れはこの定義を用いて進行するかもしれない。

【００６３】しかし、実行定義が見いだされても、それ
が必ずしも直ちに使用可能であるとは限らない。実行定
義を準備するステップが行われた場合、実行定義が準備
完了となる、すなわち準備された状態となる。実行定義
を準備するステップが行われると、特定の実行定義に対
応する「準備完了フラッグ」が設定されて、実行定義が
使用準備完了であることが示される。図９のステップ７
２０において見いだされた実行定義に対応する準備完了
フラッグが設定されたか否かの判定は、ステップ７２６
において行われる。準備完了フラッグがまだ設定されて
いないと判定されると、発送機能は待機状態になり、ス
テップ７２７において実行定義が準備完了になるのを待
つ。すなわち、発送機能は、実行定義が使用準備完了で
あることを示す状態に、関連する準備完了フラッグが設
定されるのを待つ。実行定義が準備完了になると、コン
トロールはステップ７２６における適当な準備完了フラ
ッグが設定されたか否かの判定からステップ７２８へ移
行し、実行定義からルックアップ機能が抽出される。こ
のルックアップ機能は、図５に示した実行レジストリ内
にある複数のコールバック機能の一つであって、コール
されたサーバントへの局地化された(localized)ポイン
ターの作成に用いられる。ステップ７３０において、ス
テップ７３０において、マーシャルバッファー内のオブ
ジェクトレファレンスからユーザーキーが抽出される。
次にステップ７３２において、ユーザーキーを引数とし
てルックアップ機能がコールされる。ルックアップ機能
は、実行されるとサーバントへのポインターを返す。サ
ーバントへのポインターはサーバーのローカル言語で実
行することができる。例えば、このポインターはサーバ
ントＣ＋＋オブジェクトを参照するＣ＋＋オブジェクト
ポインターであればよい。

【００６４】コールされたサーバントオブジェクトを指
示するローカルポインターが得られると、発送機能は、
クライアントが当初リクエストしたサーバントオブジェ
クト上において適当なメソッドを実行する準備完了とな
る。ステップ７３３において、マーシャルバッファーか
らメソッドデスクリプタ（記述子）が抽出される。メソ
ッドデスクリプタは、クライアントが呼び出そうとする
サーバント上において定義されるクライアントによって
理解されるようなメソッド名を保持するデータ構造であ
る。ステップ７３４において、スケルトン発送機能が実
行定義から抽出される。このスケルトン発送機能は図５
のスケルトン情報を保持するコラム内の実行レジストリ
内において見いだすことができる。図１１を参照して、
スケルトン発送機能を以下に説明する。スケルトン発送
機能は、クライアントが当初リクエストしたサーバント
上においてメソッドを実行する結果を達成する。オペレ
ーション、すなわちリクエストされたメソッドが実行さ
れると、クライアントによるサーバントオブジェクトの
呼出しが完了する。しかし、いくつかの実施例において
は、追加の機能が実行されることがある。ポスト呼出し
機能は、デベロッパーが求める機能性を達成する各実行
に関する、デベロッパーによって定義される機能であ
る。ステップ７３８において、ポスト呼出し機能が実行
定義から抽出される。次にステップ７４０においてユー
ザーキーを引数としてポスト呼出し機能がコールされ
る。デベロッパーは、オブジェクトの呼び出し後、特定
のアクションを実行するため、ポスト呼出し機能を用い
ることができる。

【００６５】次に図１１を参照して、本発明の一実施例
による、スケルトン発送機能の実行メソッド、すなわち
図１０のステップ７３６を説明する。スケルトン発送機
能へのコールはステップ７４２から始まり、ここで、ス
ケルトン発送機能へのコールを行うのに用いるメソッド
デスクリプタに対応するアンマーシャリング・メカニズ
ムが選ばれる。いくつかの実施例において、アンマーシ
ャリング・メカニズムは、スイッチ・ステートメントに
よって選ばれるコードのシーケンスである。他の情報が
先にマーシャルバッファーから抽出されているので、こ
の時点でマーシャルバッファー内に残っている情報は、
呼び出されるべきメソッドによって用いられる引数のみ
である。ステップ７４４において、選ばれたアンマーシ
ャリング・メカニズムを用いて、残りのマーシャルバッ
ファーを呼出し引数へアンマーシャルする。呼出し引数
が得られた後、ステップ７４６において、呼出し引数を
用いてサーバント上に定義されたメソッドを、メソッド
デスクリプタを用いて呼び出す。呼出し引数を用いてメ
ソッドを呼び出すことは、、当初クライアントがリクエ
ストしたメソッドを実行するという効果を有する。呼び
出されたメソッドが何の値も返さず、その代わり、他の
機能を実行したり、あるいはこのメソッドがクライアン
トへ値を返したりすることがあり得る。サーバント内の
メソッドが呼び出された後、ステップ７４８において、
呼び出されたメソッドが回答を出すか否か、判定され
る。回答が出されない場合、スケルトン発送機能が行わ
れる。回答が出されれば、コントロールはステップ７５
０へ移行し、そこでメソッドデスクリプタに対応する適
当なマーシャリング・メカニズムが選ばれる。マーシャ
リング・メカニズムが選ばれた後、選ばれたマーシャリ
ング・メカニズムを用いてステップ７５２において回答
をマーシャルバッファーへとマーシャルする。マーシャ
リング・メカニズムは普通、回答引数をマーシャルする
前に、回答ヘッダーをマーシャルする。回答に含まれる
バイト数が、オブジェクトレファレンスを含むマーシャ
ルバッファーがカプセル化できる数より多い場合、回答
をカプセル化するため新しいマーシャルバッファーを作
成することができる。そうでない場合、回答はリクエス
トを含んでいたマーシャルバッファーへとマーシャルさ
れる。回答がマーシャルバッファーへとマーシャルされ
た後、回答はトランスポートレヤーを介してクライアン
トへ返される準備完了状態となる。

【００６６】図９、１０および１１を参照して一つの発
送メカニズムを説明したが、本発明のマルチレベル発送
メカニズムに従って他の多様なメカニズムを提供できる
ことを理解すべきである。例えば上記に説明した発送メ
カニズムよりも容易にカスタマイズ（特別仕様化）でき
る発送メカニズムを実行することができる。３レベル発
送メカニズムにおける差異の主な理由は、図７ａ、７
ｂ、および７ｃを参照して上記に説明した実行はカスタ
ム・オブジェクトの組み込みを直ちにサポートしないこ
とである。例えば、図９、１０、および１１を参照して
上記に説明したように、発送プロセスには普通、適当な
実行の識別が係わるが、カスタムオブジェクトをサポー
トする呼出しに用いるプロセスには、適当な実行の識別
は係わらない。その理由は、普通唯一の実行が係わり、
更に唯一のサーバントオブジェクトが係わるからであ
る。

【００６７】次に図１２を参照して、本発明の第２実施
例による、持続性オブジェクトの発送に適したスケルト
ン発送機能のコールメソッドを説明する。このプロセス
は、トランスポートレヤーがサブコントラクト識別子
（ＳＣＩＤ）を用いて特定のサブコントラクトに関する
発送機能を呼び出してから開始する。いくつかの実施例
において、トランスポートレヤー内の、例えばドアエン
ドポイントのような、エンドポイントは関連サブコント
ラクトを一つしか、従って発送機能を一つしか持たない
ことがある。そのような実施例においては、エンドポイ
ントはリクエスト受信後、直接関連サブコントラクトへ
発送する。図８について上記に説明した他の実施例にお
いて、エンドポイントは、サブコントラクト識別子によ
って識別されるサブコントラクトへリクエストを送るの
に用いる適当な発送機能を判定するのに用いることので
きるエンドポイント発送レジストリを持つことができ
る。サブコントラクト識別子は、図３に示すようにオブ
ジェクトレファレンス内に含まれている。従って、その
ような実施例においては、トランスポートレヤーは、適
当なサブコントラクトにアクセスするためにはどの発送
機能をコールすべきかを判定するため、このサブコント
ラクト識別子においてのぞき見することができる。いく
つかの実施例において、サブコントラクト識別子におい
てのぞき見するために、ＰＥＥＫ ＳＣＩＤメソッドを
用いることができる。

【００６８】適当なサブコントラクトにアクセスした
後、すなわちリクエストが適当なサブコントラクトへ発
送された後、ステップ８０２においてサブコントラクト
識別子がマーシャルバッファー内のオブジェクトレファ
レンスから抽出される。この抽出プロセスは、マーシャ
ルバッファーから取出された情報はもはやマーシャルバ
ッファー内には存在しないことを意味する。次にステッ
プ８０４において、この抽出されたサブコントラクト識
別子を、現在使用中のサブコントラクトと比較して、適
切なサブコントラクトが使用中であるか、確認する。前
記のように、アプリケーションの開発者は、オブジェク
ト開発中、サブコントラクト識別子を用いて、特定のサ
ブコントラクトを一つのオブジェクトに関連づける。

【００６９】ステップ８０６において、マーシャルバッ
ファー内のオブジェクトレファレンスからサーバー識別
子（ＩＤ）が抽出される。この呼出しの主題であるサー
バーオブジェクトは、ホストコンピュータ上の特定のサ
ーバープロセス内に存在するので、このサーバー識別子
が現行のサーバーの識別子にマッチすることを確認する
ことが重要である。ステップ８０８において、この抽出
されたサーバー識別子を現行のサーバーの識別子と比較
してオブジェクトレファレンスが適切なサーバープロセ
スを参照しているか否か、判定する。ステップ８１０
は、抽出されたサーバー識別子が有効であるか、また現
行のサーバーに実際にマッチするか否か、判定する。こ
の現行のサーバーがマッチしないということは、当該サ
ーーバー識別子が無効であり、適当な処置を取るべきこ
とを示している。この処置は、バッドサーバー識別子ハ
ンドラー機能を用いて取ることができる。ステップ８１
２は、適当なバッドサーバー識別子ハンドラーが、現行
のサブコントラクトに係わるサブコントラクト・メタ・
オブジェクトに登録されているか否かの判定である。サ
ブコントラクト識別子が既にオブジェクトレファレンス
から抽出されているので、このステップは図４のサブコ
ントラクトレジストリを用いて行われる。サブコントラ
クト識別子は、現行のサブコントラクトに係わるバッド
サーバー識別子ハンドラーが存在するか否か判定するた
め「他の機能」のコラムをサーチできるようにする、サ
ブコントラクトレジストリの特定の列へのキーとして作
用する。このハンドラーが存在しない場合、ステップ８
１６においてシステムはこの状況に関する例外を設け、
発送機能は終了する。しかしもしハンドラーがサブコン
トラクト・メタ・オブジェクトに登録されていれば、登
録されているバッドサーバー識別子ハンドラーは、サブ
コントラクト識別子とマーシャルバッファーとを引数と
してステップ８１４においてコールされる。バッドサー
バー識別子ハンドラーがコールされた後、発送機能は終
了する。

【００７０】ここで、抽出されたサーバー識別子が有効
であるか否かの判定であるステップ８１０に戻り、抽出
されたサーバー識別子が実際に現行のサーバーにマッチ
する場合、プロセスコントロールは図１３のステップ８
３０へ移行し、そこでマーシャルバッファー内にカプセ
ル化されているオブジェクトレファレンスからユーザー
キーを抽出する。

【００７１】次に図１３を参照して、図１２を参照して
説明したように、本発明の台２実施例による持続性オブ
ジェクトの発送に適したスケルトン発送機能をコールす
るメソッドにおけるにおける残りのステップを説明す
る。ステップ８３０において、メソッドデスクリプタが
マーシャルバッファー内のオブジェクトレファレンスか
ら抽出される。次にステップ８３３において、マーシャ
ルバッファーからメソッドデスクリプタが抽出される。
上記のように、メソッドデスクリプタは、クライアント
が呼び出そうとするサーバー上において定義される、ク
ライアントによって理解されるような、メソッド名を保
持するデータ構造である。ステップ８３４において、ス
ケルトン発送機能は、ステップ８３０において抽出した
ユーザーキーを用いるマーシャルバッファー内にある。
抽出されたスケルトン発送機能は、ステップ８３６にお
いて、ユーザーキー、マーシャルバッファー、およびメ
ソッドデスクリプタを含む引数を用いてコールされる。
図１４を参照してスケルトン発送機能を以下に説明す
る。スケルトン発送機能は、クライアントが当初リクエ
ストしたサーバント上においてメソッドを実行する結果
を達成する。オペレーション、すなわちリクエストされ
たメソッドが実行されると、クライアントによるサーバ
ントオブジェクトの呼出しが完了する。

【００７２】次に図１４を参照して、本発明の第２実施
例によるスケルトン発送機能の実行メソッド、すなわち
図１３のステップ８３６を説明する。図１４を参照して
説明するスケルトン発送機能の実行メソッドは、図１１
を参照して説明したスケルトン発送機能の実行メソッド
とは異なることを理解すべきである。すなわち、図１４
を参照して説明するメソッドは、外部から供給されるコ
ードのモジュールを実行することができる。

【００７３】スケルトン発送機能へのコールはステップ
８４０から始まり、ここでカスタムオブジェクトが作成
される。換言すれば、任意のカスタムオブジェクト、す
なわちデベロッパーによって与えられるアプリケーショ
ンコードのモジュールが作成される。カスタムオブジェ
クトが存在しなければカスタムオブジェクトは」作成さ
れないことを理解すべきである。ステップ８４１におい
て、カスタム・プレ発送（ＣＵＳＴＯＭ．ＰＲＥ ＤＩ
ＳＰＡＴＣＨ）メソッドがコールされる。カスタム・プ
レ発送メソッドは、アプリケーション・デベロッパーに
よって与えられるメソッドであって、普通はユーザーキ
ーを用い、ユーザーキーは、コールの際、メソッドデス
クリプタにおいて識別されるメソッドを呼び出すのに適
したサーバントを判定するため、引数としてスケルトン
発送機能へ送られる。カスタム・プレ発送メソッドを含
めることは、「カスタム・フック」を用いることにより
可能になる。カスタムフックにより、外部コードをスケ
ルトン呼出しメソッドへのコールの一部として挿入し、
実行することができる。カスタムフックを用いない場
合、すなわち外部コードがない場合、プロセスの流れは
カスタム・プレ発送メソッドを実行しない。カスタムフ
ックを用いる場合、アプリケーション・デベロッパーに
よって与えられるカスタム・プレ発送メソッドを実行す
る。このカスタムフックは、他のものと同様に、外部コ
ードがスケルトン発送メソッドへのコールの一部として
効率的に実行できるように与えられることを理解すべき
である。

【００７４】カスタム・プレ発送メソッドへのコールの
後、プロセスの流れはステップ８４２へ移行し、そこで
スケルトン発送機能へのコールを構成するメソッドデス
クリプタに対応するアンマーシャリングカニズムが選ば
れる。いくつかの実施例において、アンマーシャリング
カニズムはスイッチステートメントによって選ばれる一
連のコードである。他の情報が既にマーシャルバッファ
ーから抽出されているので、この時点でマーシャルバッ
ファー内に残っている情報は、呼び出されるべきメソッ
ドによって用いられる引数のみである。

【００７５】ステップ８４４において、選ばれたアンマ
ーシャリング・メカニズムを用いて、残りのマーシャル
バッファーを呼出し引数へアンマーシャルする。呼出し
引数が得られた後、ステップ８４５において、カスタム
・プレオペレーション（ＣＵＳＴＯＭ．ＰＲＥ ≪ＯＰ
ＥＲＡＴＩＯＮ≫）メソッドへのコールがおこなわれ
る。「オペレーション」の名称は、コールされるＩＤＬ
の名称に依存する。いくつかの実施例において、このオ
ペレーションは読み出しロック(read lock)または書き
込みロック(write lock)の獲得である。読み出しロック
は任意の時点において全体変数(global variable)にお
ける書き込みオペレーションを防ぎ、書き込みロックは
任意の時点において全体変数上における読み出しオペレ
ーションと２回以上の書き込みオペレーションを防止す
るのに用いられる。カスタム・プレオペレーションへの
コールは、カスタムフックに関連づけられる。すなわ
ち、ユーザーが外部カスタム・プレオペレーション・コ
ードを与えると、カスタムフックはアクティブと見なさ
れ、外部カスタム・プレオペレーション・コードが実行
される。外部コードが与えられない場合、不活性カスタ
ムフックの存在は、スケルトン発送メソッドへのコール
の効率を全く損なわない。

【００７６】カスタム・プレオペレーションメソッドへ
のコールの後、ステップ８４６において、メソッドデス
クリプタを用いて呼び出し引数を用いてサーバント上に
定義されたメソッドを呼び出す。呼び出し引数を用いて
サーバント内にメソッドを呼び出すことは、クライアン
トが当初リクエストしたメソッドを実行するという効果
を持つ。呼び出されたメソッドが何の値も返さず、その
代わり、他の機能を実行したり、あるいはこのメソッド
がクライアントへ値を返したりすることがあり得る。い
くつかの実施例において、カスタム・プレオペレーショ
ンメソッドが用いられると、メソッドの呼出しがカスタ
ム・プレオペレーションメソッドの一部であるので、呼
び出されたメソッドが何の機能も実行しないことがあ
る。サーバント内のメソッドが呼び出された後、ステッ
プ８４７においてカスタム・ポストオペレーション（Ｃ
ＵＳＴＯＭ．ＰＯＳＴ ≪ＯＰＥＲＡＴＩＯＮ≫）メソ
ッドへのコールが行われる。「オペレーション」の名称
は、コールされるＩＤＬの名称に依存する。カスタム・
ポストオペレーションメソッドはカスタム・プレオペレ
ーションメソッドとペアにされる。換言すれば、もしカ
スタム・プレオペレーションメソッドが存在すれば、普
通、カスタム・ポストオペレーションメソッドも存在す
るはずである。カスタム・プレオペレーションメソッド
が読み出しロックまたは書き込みロックの獲得である実
施例においては、対応するカスタム・ポストオペレーシ
ョンメソッドは普通、それぞれ読み出しロックまたは書
き込みロックの解除である。カスタム・プレオペレーシ
ョンメソッドの場合もそうであったように、カスタム・
ポストオペレーションメソッドを含めることはカスタム
フックの使用によって可能になる。カスタム・ポストオ
ペレーションメソッドがコールされた後、ステップ８４
８４において、呼び出されたメソッドが回答を出すか否
か、判定が行なわれる。回答が出されない場合、プロセ
スコントロールはステップ８５３へ進み、そこでカスタ
ム・ポスト発送（ＣＵＳＴＯＭ．ＰＯＳＴ ＤＩＳＰＡＴ
ＣＨ）メソッドへのコールが行われる。回答が出される
と、コントロールはステップ８５０へ移行し、そこでメ
ソッドデスクリプタに対応する適当なマーシャリングメ
カニズムが選ばれる。

【００７７】マーシャリング・メカニズムが選ばれた
後、選ばれたマーシャリング・メカニズムを用いてステ
ップ８５２において回答をマーシャルバッファーへとマ
ーシャルする。回答に含まれるバイト数が、オブジェク
トレファレンスを含むマーシャルバッファーがカプセル
化できる数より多い場合、回答をカプセル化するため新
しいマーシャルバッファーを作成することができる。そ
うでない場合、回答はリクエストを含んでいたマーシャ
ルバッファーへとマーシャルされる。回答がマーシャル
バッファーへとマーシャルされた後、ステップ８５３に
おいてカスタム・ポスト発送（ＣＵＳＴＯＭ．ＰＯＳＴ
ＤＩＳＰＡＴＣＨ）メソッドへのコールが行われる。
カスタム・ポスト発送メソッドはカスタム・プレ発送メ
ソッドとペアにされて、普通、レファレンスの回数計測
に用いられる。すなわち、カスタム・プレ発送メソッド
を用いて、メソッドの実行に用いられるスレッドを追跡
し、カスタム・ポスト発送メソッドがコールされた時点
において実行中のスレッドの数を数える。ここでも、カ
スタム・ポストオペレーションメソッドに属するアプリ
ケーションコードを含めることは、カスタムフックの使
用によって可能になる。カスタム・ポストオペレーショ
ンメソッドがコールされた後、回答はトランスポートレ
ヤーを介してクライアントへ返送準備完了となる。

【００７８】サブコントラクト発送メソッドは、モジュ
ール性(modularity)を改善するため更に複数のサブレヤ
ーに分割できることを理解すべきである。例えば、低位
サブレヤー(lower sub-layer)と高位サブレヤー(higher
sub-layer)の二つのサブレヤーを用いることができ
る。このサブコントラクト発送メソッドの分割は、通
常、一つのサブコントラクトが、複数のトランスポート
をサポートし、それ故サブコントラクトによって用いら
れる多数のトランスポートによって与えられる種々のタ
イプのエンドポイントに登録される場合に発生する。こ
のサブコントラクトは、ターゲットオブジェクトレファ
レンスすなわちメソッド識別子を含み、リクエストヘッ
ダーをアンマーシャルするメソッドが、トランスポート
次第で異なり、従ってリクエストメッセージを出すのに
用いるメソッドが、トランスポート次第で異なるので、
各エンドポイント毎に異なる発想クロージャを登録する
ことができる。換言すれば、リクエストのアンマーシャ
ルに用いられる低サブレヤー内のメソッドは、サブコン
トラクトによって要求される、トランスポートに特有の
リクエストヘッダー情報をデコードするのに用いられる
「ロジックグルー」(logic glue)を提供する。トランス
ポートからサブコントラクトへの発送クロージャによっ
て参照される 発送機能は、このロジックグルーを実行
することができる。このロジックグルーは最終的に、ト
ランスポートに独立でサブコントラクトに依存する高位
サブレヤー内の機能をコールする。このプロセスは、サ
ーバントオブジェクト実行定義のルックアップ、トラン
ザクション処理、セキュリティチェック、スケルトン発
送機能のコール、等を含む、トランスポートに依存し、
トランスポートに独立な処理を提供する、サブコントラ
クト発送メソッドのサブレヤーへの細分は、サブコント
ラクトレヤーの展開に追加の柔軟性（フレキシビリテ
ィ）をもたらす。例えば一つのトランスポートをサポー
トする一つのサブコントラクトを、システム全体への変
更を極力少なくしつつ、他のトランスポートをサポート
するため、より強力なサブコントラクトへ組み入れるこ
とができる。

【００７９】次に図１５を参照して、本発明の第３実施
例による、サブレヤーへ分割されたサブコントラクト発
送メカニズムを説明する。図１５は、分散オブジェクト
システム上のトランスポートレヤー３８、サブコントラ
クトレヤー３６、およびスケルトンレヤー３１のダイヤ
グラム図である。トランスポートレヤー３８は、「トラ
ンスポート１」９０２、「トランスポート２」９０４、
「トランスポート３」９０６の３個のトランスポートメ
カニズムを持っている。「トランスポート１」９０２は
エンドポイント「エンドポイント１」９０８と、それに
係わるクロージャ「クロージャ１」９１０を持ってい
る。図示のように、「エンドポイント１」９０８は専用
エンドポイントである。「クロージャ１」９１０は、情
報をトランスポートレヤー３８からサブコントラクトレ
ヤー３６へ発送するのに用いることができる。「トラン
スポート２」９０４は、関連するエンドポイント発送レ
ジストリ９１２と、関連するクロージャ、例えば「クロ
ージャ２Ａ」９１４と「クロージャ２Ｂ」９１６を持っ
ている。エンドポイント発送レジストリ９１２は、「ト
ランスポート２」９０４に関連するエンドポイントがク
ラスターエンドポイントであるので用いられる。「トラ
ンスポート３」９０６は、「クロージャ３」９２０に関
連する専用エンドポイント「エンドポイント３」９１８
を持っている。

【００８０】先に述べたように、サブコントラクト発送
メソッドは、モジュール性を改善するため複数のサブレ
ヤーに分割することができる。「サブコントラクト１」
９２２と「サブコントラクト３」９２４はそれぞれ低位
サブレヤー９２２ａ、９２４ａと高位サブレヤー９２２
ｂ、９２４ｂに分割される。サブコントラクト発送メソ
ッドの分割は通常、例えば「サブコントラクト１」９２
２のようなサブコントラクトが複数のトランスポートを
サポートする場合に発生する。例えば低位サブレヤー９
２２ａ内のメソッドは、「トランスポート１」９０２に
関連するトランスポートに特有の、すなわちトランスポ
ートに依存する処理メソッド９２６と、「トランスポー
ト２」９０４に関連するトランスポートに特有の処理メ
ソッド９２８である。メソッド９２６、９２８は、「サ
ブコントラクト１」９２２が要求するトランスポートに
特有のリクエストヘッダー情報をデコードするのに用い
られ、最終的に、トランスポートに依存しサブコントラ
クトに独立の処理を実行する上位サブレヤー９２２ｂ内
のトランスポートに独立のサブコントラクト処理機能９
３０のコールに用いられる。この処理は、スケルトンレ
ヤー３１内のスケルトン発送機能９３４にアクセスする
のに用いる、実行レポジトリ９３２内のサーバントオブ
ジェクト実行定義のルックアップを含む。

【００８１】サブコントラクト発送メソッドのサブレヤ
ーへの細分は、サブコントラクトレヤー３６の展開にお
いて更に追加の柔軟性をもたらす。先に述べたように、
一つのトランスポートをサポートする一つのサブコント
ラクトを、システム全体への変更を極力少なくしつつ、
他のトランスポートをサポートするため、より強力なサ
ブコントラクトへ組み入れることができる。「サブコン
トラクト１」９２２は、「サブコントラクト３」９２４
が「トランスポート３」９０６をサポートする故「サブ
コントラクト１」９２２より「強力な」「サブコントラ
クト３」９２４の一部として組込むことができる。換言
すれば、「サブコントラクト１」９２２は、「サブコン
トラクト３」９２４の一部として組込まれ、それによっ
て「サブコントラクト３」９２４は「トランスポート
１」９０２、「トランスポート２」９０４、「トランス
ポート３」９０６をサポートすることができる。この組
込みは、「サブコントラクト１」９２２に関連する、ト
ランスポートに独立のサブコントラクト処理メソッド９
３０を利用する「サブコントラクト３」９２４の低位サ
ブレヤー９２４ａ内のトランスポートに特有の処理に関
連する。サブコントラクト発送メソッド内のサブレヤー
の使用、従って二つ以上のサブコントラクトに関する同
じトランスポートに独立のサブコントラクト処理メソッ
ドの使用は、サブコントラクトレヤー３６への変更を極
力少なくしつつサブコントラクトを他のサブコントラク
トのコンポーネントとして組込むことができるので、サ
ブコントラクトレヤー３６の柔軟性を改善する。

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

【００８３】上記本発明はコンピュータシステムに保存
されたデータを用いて様々なプロセスステップを行う。
これらステップには物理量の物理的処理が必要である。
常にという訳ではないが、通常、これらの量は保存、転
送、結合、比較、その他の処理が可能な電気信号または
磁気信号の形をとる。これらの信号は、ビット、バリュ
ー（値）、要素、変数、文字、データ構造、その他とし
て扱うのが、主として共通使用という理由で便利な場合
がある。しかし、これら類似の用語はすべて適当な物理
量に関連づけられるはずのものであり、これらの量に貼
り付けられた便利なラベルに過ぎない。

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

【００８５】更に本発明は、コンピュータによって実行
される様々なオペレーションの実行のためのプログラム
命令を包含した、コンピュータによる読み出し可能な媒
体にも関する。媒体命令およびプログラム命令は、本発
明の目的のために特別に設計され構成されたものでも、
あるいはコンピュータのソフトウェア技術の当業者に周
知かつ利用可能なものであってもよい。コンピュータに
よる読み出し可能な媒体の例としては、限定はしない
が、ハードディスク、フロッピーディスク、磁気テー
プ；ＣＤ−ＲＯＭディスク等の光媒体；オプティカルデ
ィスクなどの磁気光ディスク；リードオンリーディスク
（ＲＯＭ）装置やランダムアクセスメモリー（ＲＡＭ）
など、特にプログラム命令の記憶と実行のために構成さ
れたハードウェア装置がある。プログラム命令の例とし
ては、コンパイラによって作成されるマシンコードと、
インタープリター(interpreter)を用いてコンピュータ
によって実行される高レベルコードを含むファイルとが
ある。

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

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

【００８８】本発明の数実施例のみを説明したが、本発
明はその精神と範囲からかけ離れることなく他の多くの
形態において実施することができる。上記実施例におい
ては、スケルトンレヤー発送機能に対するただ二つのサ
ブコントラクトレヤーのみを、すなわちスケルトン発送
機能のみを説明したが、３レベル発送メカニズムの一部
として用いられるスケルトン発送機能は、発送メカニズ
ムが実行される特定のシステムに依存するので、スケル
トン発送機能は、本発明の範囲内において大幅に変更可
能であることを理解すべきである。例えばロー・オーバ
ーヘッド・オブジェクト・アダプター以外のオブジェク
ト・アダプターを利用することができる。

【００８９】更に、上記実施例においては、トランスポ
ートレヤーからサブコントラクトレヤーへの発送メカニ
ズムはクロージャである。トランスポートレヤーからサ
ブコントラクトレヤーへ発送メカニズムへのトランスポ
ートも、３レベル発送メカニズムが実行される特定のシ
ステムに依存して大幅に変化し得る。例えば、エンドポ
イント対サブコントラクトのマッピングは、エンドポイ
ントが存在するトランスポートレヤーの構造とサブコン
トラクトレヤーの構造によって変化する。

【００９０】更に、上記実施例においては、具体的なエ
ンドポイント、サブコントラクト、および実行レジスト
リを説明した。これらレジストリは、本発明の範囲内に
おいて大幅に変更可能であることを理解すべきである。
更に、発送メソッドの呼出しに係わるステップ、例えば
スケルトン発送機能は、順序を変えることができる。各
ステップはまた、本発明の精神または範囲からかけ離れ
ることなく削除または追加が可能である。従って、ここ
に説明した実施例は説明のためであって制限のためでは
ないと解釈すべきであって、本発明は以下の請求項とそ
の範囲によって定義されるべきである。

【図面の簡単な説明】

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

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

【図３】本発明の一実施例によるネットワーク上の使用
に適したオブジェクト・レファレンスのダイヤグラム図
である。

【図４】本発明の一実施例によるサブコントラクト・レ
ジストリ・データ構造のダイヤグラム図である。

【図５】本発明の一実施例による実行レジストリ・デー
タ構造のダイヤグラム図である。

【図６】本発明の一実施例によるサブコントラクトの初
期化メソッドを示すプロセス流れ図である。

【図７】本発明の一実施例による専用エンドポイントの
初期化メソッドを示すプロセス流れ図である。

【図８】本発明の一実施例によるエンドポイント・レジ
ストリ・データ構造のダイヤグラム図である。

【図９】本発明の一実施例によるパーシステント(persi
stent:永続性)オブジェクトに適したスケルトン発送機
能をコールするメソッドを示すプロセス流れ図である。

【図１０】本発明の一実施例によるパーシステント(per
sistent:永続性)オブジェクトに適したスケルトン発送
機能をコールするメソッドを示すプロセス流れ図であ
る。

【図１１】本発明の一実施例によるスケルトン発送機能
の実行メソッド、すなわち図１０のステップ７３６を示
すプロセス流れ図である。

【図１２】本発明の第２の実施例によるパーシステント
(persistent:永続性)オブジェクトに適したスケルトン
発送機能をコールするメソッドを示すプロセス流れ図で
ある。

【図１３】本発明の第２の実施例によるパーシステント
(persistent:永続性)オブジェクトに適したスケルトン
発送機能をコールするメソッドを示すプロセス流れ図で
ある。

【図１４】本発明の第２の実施例によるスケルトン発送
機能の実行メソッド、すなわち図１３のステップ８３６
を示すプロセス流れ図である。

【図１５】本発明の第３の実施例によって複数のサブレ
ヤーに分割されたサブコントラクト発送メカニズムのダ
イヤグラム図である。

【図１６】本発明の分散オブジェクトシステムの実行に
適した代表的なコンピュータのダイヤグラム図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 サンジェイ アール． ラディア アメリカ合衆国， カリフォルニア州， フリーモント， ボアー サークル 883 (72)発明者 ケン エム． カヴァナフ サード アメリカ合衆国， カリフォルニア州， モンタラ， フィフス ストリート 357 (72)発明者 クリスチャン ジェイ． コールセン アメリカ合衆国， カリフォルニア州， メンロ パーク， コールマン アヴェニ ュー 744， アパートメント エヌ.

Claims (28)

【特許請求の範囲】
1. 【請求項１】トランスポートレヤーの一部であるトラン
   スポートエンドポイント上においてリクエストを受信す
   るステップと、 前記リクエストを前記トランスポートレヤーからサブコ
   ントラクトレヤーの一部であり前記リクエストの少なく
   とも一部をアンマーシャルするように配設されたサブコ
   ントラクトへ発送するステップと、 部分的にアンマーシャルされたリクエストを前記サブコ
   ントラクトからスケルトンレヤーの一部であるスケルト
   ン機能へ発送するステップと、 前記スケルトン機能からサーバントを呼び出すステップ
   を含む分散オブジェクト呼出しを発送するためのメソッ
   ド。
2. 【請求項２】前記リクエストを前記サブコントラクトへ
   発送するステップは、受信したリクエストを保持してい
   るマーシャルバッファーを有するクロージャの呼出しに
   よって行われる請求項１に記載のメソッド。
3. 【請求項３】前記クロージャは、前記サブコントラクト
   の少なくとも一部を形成する発送機能へのポインター
   と、前記サブコントラクトが提供するクッキーへのポイ
   ンターとを含む請求項２に記載のメソッド。
4. 【請求項４】前記スケルトン機能は、前記リクエストの
   更に一部をアンマーシャルするように配設されている請
   求項１〜３のいずれかに記載のメソッド。
5. 【請求項５】前記サブコントラクトは、前記サーバント
   の言語マッピングから独立している請求項１〜４のいず
   れかに記載のメソッド。
6. 【請求項６】マルチレヤー発送メカニズムを利用する、
   分散クライアント／サーバーに基づくコンピューティン
   グシステムにおいて、サブコントラクトレヤーの一部で
   あるサブコントラクトを初期化するメソッドであって、 前記サブコントラクトが、前記サブコントラクトが前記
   受信したリクエストの少なくとも一部をアンマーシャル
   した後、受信したリクエストを適当なスケルトンへ発送
   するように配設されたスケルトン発送機能を含み、 それぞれ一つのユニークエンドポイントに関連する、少
   なくとも一つのクラスターエンドポイントレジストリに
   前記サブコントラクトを登録するステップと、 前記サブコントラクトに関連するサブコントラクトメタ
   オブジェクトを作成するステップと、 前記サブコントラクトメタオブジェクトをサブコントラ
   クトレジストリ内に保存するステップを含むメソッド。
7. 【請求項７】前記サブコントラクトに関連する専用エン
   ドポイントを初期化するステップを更に含む請求項６に
   記載のメソッド。
8. 【請求項８】前記ユニークエンドポイントは、トランス
   ポートレヤー内に作成されたクラスターエンドポイント
   である請求項６または７に記載のメソッド。
9. 【請求項９】前記クラスターエンドポイントは、ターゲ
   ットオブジェクトに関するサブコントラクト識別子を得
   るために用いることのできるロジックを含む請求項８に
   記載のメソッド。
10. 【請求項１０】マルチレヤー発送メカニズムを利用す
    る、分散クライアント／サーバーに基づくコンピューテ
    ィングシステムにおいて、リクエストをトランスポート
    レヤー内のエンドポイントからサブコントラクトレヤー
    へ発送する、複数のサブレヤーに分割されているサブコ
    ントラクト発送メソッドであって、 前記エンドポイントに発送クロージャを登録するステッ
    プと、 前記リクエストを前記トランスポートレヤーから、前記
    リクエストを部分的にデコードするように配設された、
    サブコントラクト発送メソッドの第１サブレヤーへ発送
    するステップと、 前記部分的にデコードされたリクエストを前記サブコン
    トラクト発送メソッドの前記第１サブレヤーから、トラ
    ンスポートから独立しサブコントラクトに従属する処理
    を実行するように配設されている、第２サブレヤーへ発
    送するステップを含むメソッド。
11. 【請求項１１】前記第１レヤーはトランスポートに特有
    の処理を行うように配設されている請求項１０に記載の
    メソッド。
12. 【請求項１２】前記サブコントラクトレヤー内の第１サ
    ブコントラクトは前記サブコントラクトレヤー内の第２
    サブコントラクトの一部である請求項１０または１１に
    記載のメソッド。
13. 【請求項１３】マルチレヤー発送メカニズムを利用す
    る、分散クライアント／サーバーに基づくコンピューテ
    ィングシステムにおいて、サブコントラクトレヤーの一
    部であるサブコントラクトを初期化するメソッドであっ
    て、 前記サブコントラクトは、前記サブコントラクトが前記
    受信したリクエストの少なくとも一部をアンマーシャル
    した後、受信したリクエストを適当なスケルトンへ発送
    するように配設されたスケルトン発送機能を含み、 前記サブコントラクト専用エンドポイントを初期化する
    ステップと、 前記サブコントラクトに関連するサブコントラクトメタ
    オブジェクトを作成するステップと、 前記サブコントラクトメタオブジェクトをサブコントラ
    クトレジストリ内に保存するステップを含むメソッド。
14. 【請求項１４】前記サブコントラクトに関連する専用エ
    ンドポイントを初期化するステップを更に含み、前記サ
    ブコントラクトに関連する専用エンドポイントを初期化
    するステップが、 コールへの引数としてサブコントラクト発送クロージャ
    を提供する専用エンドポイント作成機能を呼び出すステ
    ップと、 前記サブコントラクト発送クロージャを、作成された専
    用エンドポイントに結びつけるステップを含む請求項１
    ３に記載のメソッド。
15. 【請求項１５】専用エンドポイントを作成する機能性は
    前記サブコントラクトレヤー内に与えられているが、専
    用エンドポイントはトランスポートレヤー内に常駐す
    る、請求項１４に記載のメソッド。
16. 【請求項１６】分散クライアント／サーバーに基づくコ
    ンピューティングシステムのサーバー上のスケルトンレ
    ヤー内のスケルトンへサブコントラクトレヤー内のサブ
    コントラクトからリクエストを発送するメソッドであっ
    て、 前記リクエストがコールされたメソッドを識別するメソ
    ッドデスクリプタに関連し、 前記メソッドデスクリプタが同じく前記リクエストをカ
    プセル化するマーシャルバッファーから抽出され、該メ
    ソッドが、 分散クライアント／サーバーに基づくコンピューティン
    グシステム内へ挿入されたアプリケーションコードのモ
    ジュールである、前記リクエストに関連するカスタムオ
    ブジェクトを構成するステップと、 前記カスタムオブジェクトに対応し、前記メソッドデス
    クリプタ内に指定されたコールされたメソッドを呼び出
    すのに用いる適当なサーバントを判定するのに用いる、
    前記カスタムオブジェクトに対応する、カスタム・プレ
    発送メソッドをコールするステップと、 前記メソッドデスクリプタに対応するアンマーシャリン
    グメカニズムを選ぶステップと、 前記選ばれたアンマーシャリングメカニズムを用いて前
    記アンマーシャルバッファーの少なくとも一部をアンマ
    ーシャルして呼出し引数にするステップと、 前記呼出し引数を用いて前記メソッドデスクリプタに対
    応するサーバント内においてコールされたメソッドを呼
    び出すステップと、 前記カスタムオブジェクトに対応するカスタム・ポスト
    発送メソッドをコールし、前記カスタム・ポスト発送メ
    ソッドを用いて、コールされたメソッドの呼出しに用い
    られる資源の追跡に用いられるプロセスである参照の回
    数を計測するステップを含む前記メソッド。
17. 【請求項１７】コールされたメソッドからの回答が要求
    されているか否か判定するステップと、 コールされたメソッドからの回答が要求されていると判
    定された場合、前記メソッドデスクリプタに対応するマ
    ーシャリングメカニズムを選ぶステップと、 前記選ばれたマーシャリングメカニズムを用いて前記回
    答をマーシャルしてマーシャルバッファーにするステッ
    プを更に含む請求項１６に記載のメソッド。
18. 【請求項１８】前記コールされたメソッドを呼び出す前
    に前記カスタムオブジェクトに対応する第１カスタムメ
    ソッドをコールするステップと、 前記サーバント内において前記コールされたメソッドを
    呼び出した後、前記カスタムオブジェクトと前記コール
    されたメソッドに対応する第２カスタムメソッドをコー
    ルするステップを更に含む請求項１６または１７に記載
    のメソッド。
19. 【請求項１９】分散クライアント／サーバントに基づく
    コンピューティングシステム内における分散オブジェク
    ト呼出しのため媒体上にコンピュータによる読み出し可
    能なコードを実現して有する、コンピュータによる使用
    が可能な前記媒体を含むコンピュータ・プログラム・プ
    ロダクトであって、前記コンピューティングシステム内
    において、 トランスポートレヤーの一部であるトランスポートエン
    ドポイントにおいてリクエストを受信するステップと、 前記リクエストを、トランスポートレヤーから、サブコ
    ントラクトレヤーの一部であるとともに前記リクエスト
    の少なくとも一部をアンマーシャルするように配設され
    たサブコントラクトへ、発送するステップと、 前記部分的にアンマーシャルされたリクエストを前記サ
    ブコントラクトからスケルトンレヤーの一部であるスケ
    ルトン機能へ発送するステップと、を実行するためのコ
    ンピュータによる読み取り可能なプログラムコードを含
    む、コンピュータ・プログラム・プロダクト。
20. 【請求項２０】前記受信したリクエストを保持している
    マーシャルバッファーにおいてクロージャを呼び出すこ
    とによって前記リクエストを前記サブコントラクトへ発
    送するステップが行われる、コンピュータによる読み取
    り可能なプログラムコードを含む、請求項１９に記載の
    前記コンピュータ・プログラム・プロダクト。
21. 【請求項２１】分散クライアント／サーバントに基づく
    コンピューティングシステム内において定義されるサブ
    コントラクトレヤーの一部であるサブコントラクトを初
    期化するため媒体上にコンピュータによる読み取り可能
    なコードを実現して有する、コンピュータによる使用が
    可能な前記媒体を備えたコンピュータ・プログラム・プ
    ロダクトであって、 前記サブコントラクトは、受信したリクエストを、前記
    サブコントラクトが前記受信したリクエストの少なくと
    も一部をアンマーシャルした後、適当なスケルトンへ発
    送するように配設されたスケルトン発送機能を含み、前
    記コンピューティングシステム内において、 それぞれ一つのユニークエンドポイントに関連する、少
    なくとも一つのクラスターエンドポイントレジストリに
    前記サブコントラクトを登録するステップと、 前記サブコントラクトに関連するサブコントラクトメタ
    オブジェクトを作成するステップと、 前記サブコントラクトメタオブジェクトをサブコントラ
    クトレジストリ内に保存するステップと、を実行するた
    めのコンピュータによる読み取り可能なプログラムコー
    ドを含む、コンピュータ・プログラム・プロダクト。
22. 【請求項２２】前記ユニークエンドポイントが、マルチ
    プル・サブコントラクトをサポートするとともにトラン
    スポートレヤー内に作成されたクラスター・エンドポイ
    ントである、コンピュータによる読み取り可能なプログ
    ラムコードを有する、請求項２１に記載の前記コンピュ
    ータ・プログラム・プロダクト。
23. 【請求項２３】リクエストをトランスポートレヤー内の
    エンドポイントから分散クライアント／サーバントに基
    づくコンピューティングシステム内において定義される
    サブコントラクトレヤーへ発送するため媒体上にコンピ
    ュータによる読み取り可能なコードを実現して有する、
    コンピュータによる使用が可能な前記媒体を含むコンピ
    ュータ・プログラム・プロダクトであって、前記コンピ
    ューティングシステム内において、 前記エンドポイントに発送クロージャを登録するステッ
    プと、 前記リクエストを前記トランスポートレヤーから、サブ
    コントラクト発送メソッドの、前記リクエストを部分的
    にデコードするように配設された、第１サブレヤーへ発
    送するステップと、 前記部分的にデコードされたリクエストを、前記第１サ
    ブレヤーから、前記サブコントラクト発送メソッドの、
    トランスポートから独立するとともにサブコントラクト
    に依存するように配設された第２サブレヤーへ発送する
    ステップと、を実行するためのコンピュータによる読み
    取り可能なプログラムコードを含む、コンピュータ・プ
    ログラム・プロダクト。
24. 【請求項２４】コンピュータによる読み出し可能なプロ
    グラムコードを含み、前記第１サブレヤーはトランスポ
    ートに特有な処理を行うように配設されている請求項２
    ３に記載のコンピュータ・プログラム・プロダクト。
25. 【請求項２５】前記サブコントラクトレヤー内の第１サ
    ブコントラクトが前記サブコントラクトレヤー内の第２
    サブコントラクトの一部である請求項２３または２４に
    記載のコンピュータ・プログラム・プロダクト。
26. 【請求項２６】別々のオブジェクト間の通信を容易にす
    るためオブジェクトブローカーを利用する、分散クライ
    アント／サーバーに基づくコンピューティングシステム
    において用いるためのエンドポイント発送レジストリデ
    ータ構造であって、 関連するサブコントラクトを識別するように配設された
    サブコントラクトと、 前記サブコントラクトに関連する発送機能を識別するよ
    うに配設されたクロージャを含むエンドポイント発送レ
    ジストリデータ構造。
27. 【請求項２７】前記クロージャは前記発送機能へのポイ
    ンターと、前記発送機能が用いるデータ要素へのポイン
    ターとを含む請求項２６に記載のエンドポイント発送レ
    ジストリデータ構造。
28. 【請求項２８】分散クライアント／サーバーに基づくコ
    ンピューティングシステムにおいてサーバーオブジェク
    トの実行を呼び出すために用いるためのコンピュータ装
    置であって、 中央処理装置と、 前記中央処理装置に結合された入出力装置と、 請求項２６または２７に記載したデータ構造を含み、前
    記中央処理装置と通信を行うランダムアクセスメモリー
    と、 前記中央処理装置と通信を行う大容量記憶装置とを含
    む、コンピュータ装置。