JPH08115223A - コンピュータで実施する方法及びデータ処理システム - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、クライアント・アプリケーション
によってオブジェクトを呼び出す機構と、クライアント
・アプリケーションとその他の処理系の間で引数を渡す
ための機構を、クライアント・アプリケーションにも、
オペレーティング・システムにも、これらの機構がどの
ように動作するかの詳細が分からないように提供する優
れた簡単な方法を提供することである。 【解決手段】 クライアントとサーバが、カーネルの介
入も、交換される引数のタイプまたは複雑さに関する制
限もなしに、ある種の環境で引数および結果を渡すため
にメモリ領域を共用できるようにする共用メモリ・サブ
コントラクトに関する。

Description

【発明の詳細な説明】

【０００１】関連出願 本出願は、本出願の１人の発明者によって１９９２年１
２月２１日に出願され、米国特許出願番号第０７／９９
５８６３号を有する、「Ａ ＭＥＴＨＯＤ ＡＮＤ Ａ
ＰＰＡＲＡＴＵＳ ＦＯＲ ＳＵＢＣＯＮＴＲＡＣＴＳ
ＩＮ ＤＩＳＴＲＩＢＵＴＥＤ ＰＲＯＣＥＳＳＩＮ
Ｇ ＳＹＳＴＥＭＳ」と題する関連米国特許出願の一部
継続である。

【０００２】

【発明の属する技術分野】本発明は、分散計算システ
ム、クライアント・サーバ計算、およびオブジェクト指
向プログラミングの分野に関する。詳細には、本発明
は、オブジェクトを使用するクライアント間通信を処理
するために、オペレーティング・システム・カーネルと
は独立のプログラム機構を提供する方法および装置であ
る。この一部継続出願は具体的には、共用メモリを効率
的にかつ安全に使用できるよう共用メモリ領域を使用す
ることによって定義域間で引数を渡す特定のタイプの機
構に関する。

【０００３】

【従来の技術】オペレーティング・システムの開発およ
び保守の主要な問題は、オペレーティング・システムを
処理系の詳細にダウンロードせずにクライアントおよび
プログラマに最大の柔軟性を与えられるように新しいイ
ンタフェースおよび処理系技法を導入できるようにする
ことである。さらに、この問題は、マイクロ・カーネル
・アーキテクチャを有するオブジェクト指向オペレーテ
ィング・システムを開発する際にさらに著しくなる。マ
イクロ・カーネルによって、クライアントは通常、たと
えばファイル・システムなど複雑なサブシステムをクラ
イアント・レベルで実施することができる。それにもか
かわらず、クライアント間通信およびコンピュータ間通
信など基本的なシステム・プロセスは非常に複雑なの
で、クライアントおよびオブジェクト・インプリメンタ
はこのようなプロセスに関与すべきではない。すなわ
ち、このような基本的に「システム」タイプのプロセス
は、標準モジュールによってより効率的に実行される
が、基本オペレーティング・システムがこのようなプロ
セスによって制限されることを必要としないように処理
すべきである。

【０００４】本開示は、オブジェクト・メタファを使用
してシステムの異なる構成要素間のインタフェースを定
義するシステムに関するこの基本的な問題の解決策につ
いて説明するものである。呼出しのパラメータとして他
のオブジェクトを送信するリモート・コンピュータ間の
オブジェクト呼出しの通信を処理できるようにする優れ
た解決策について説明する。

【０００５】オブジェクト指向システムで、オブジェク
トとは、データと、データを処理するために呼び出すこ
とができる動作とを備える構成要素である。動作は、オ
ブジェクトに呼出しを送信することによってオブジェク
ト上で呼び出される。各オブジェクトはオブジェクト・
タイプを有する。オブジェクト・タイプは、そのタイプ
のオブジェクトに対して実行できる動作を定義する。オ
ブジェクト動作は、オブジェクト自体とは独立に実施さ
れる。また、１つのオブジェクト・タイプは、他のオブ
ジェクト・タイプに関して定義され実施されるオブジェ
クト動作を継承することができる。オブジェクト指向デ
ザイン・プログラミング技法の詳細に関しては、Ｂｅｒ
ｔｒａｎｄ Ｍｅｙｅｒ著「Ｏｂｊｅｃｔ−ｏｒｉｅｎ
ｔｅｄＳｏｆｔｗａｒｅ Ｃｏｎｓｔｒｕｃｔｉｏｎ」
（Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、１９８８年）を参照さ
れたい。

【０００６】クライアント・サーバ計算では、通常、コ
ンピュータ自体を接続するネットワークを介して相互に
通信できる１組のコンピュータがある。これらのコンピ
ュータのうちのいくつかは、他のコンピュータへのサー
ビスまたは機能の提供者として働く。そのようなサービ
スまたは機能の提供者を「サーバ」と呼び、そのような
サービスまたは機能の消費者を「クライアント」と呼
ぶ。クライアント・サーバ・モデルは、同じコンピュー
タ上で動作する異なるプログラムが、何らかの保護機構
を介して相互に通信し、機能の提供者および消費者とし
て働くケースとしても一般化されている。

【０００７】クライアント・サーバ・モデルに基づくオ
ブジェクト指向分散システムでは、オブジェクト指向イ
ンタフェースをクライアントに提供するサーバが存在す
る。このようなサーバは、データから成るオブジェクト
と、関連するソフトウェアをサポートする。クライアン
トは、このようなオブジェクトにアクセスしてその呼出
しを実行することができる。この呼出しは、クライアン
トからサーバへ送信される。サーバでは、この呼出し
が、オブジェクトに関連するソフトウェアを介して実行
される。次いで、この呼出しの結果がクライアントに送
り返される。

【０００８】オブジェクト・メタファは、オブジェクト
のインタフェースとその処理系を分離し、分散システム
では異なる計算機上に存在することができる単一のイン
タフェースの複数の処理系を可能にするので、有用な技
法である。しかし、既存のオブジェクト指向システムで
は、基本システムは、オブジェクト「呼出し」が何を意
味するか、「オブジェクトを引数として渡す」ことが何
を意味するかなど、基本的なオブジェクト特性を定義す
る。

【０００９】残念なことに、基本特性が何であるかを基
本システムに定義させることによって、基本システム
が、ユーザがオブジェクトに有させたいすべての基本特
性をサポートすることが必要になる。たとえば、信頼性
を増大させるためにオブジェクトの複製をサポートした
いと仮定する。複製されたオブジェクトと対話するため
の余分の作業をクライアント・アプリケーション・コー
ドに実行させるのは望ましくない。したがって、システ
ムによって複製をサポートすることが好ましい。しか
し、複製を実施するには多数の方法がある。問題は、こ
れらの方法のうちのいくつかを基本システムに組み込
み、他の方法を拒否することである。アプリケーション
開発者が、複製したオブジェクトを自分のアプリケーシ
ョン内で管理するより効率的な方法を発見した場合、ア
プリケーション開発者が複製したオブジェクトを基本機
構を変更する必要なく管理できることが望ましい。さら
に、基本システムを使用して、複製、パシスタンス（pe
rsistence)、クラッシュ回復、キャッシングなど特定の
特性用の何らかの標準基本機構をサポートすることがで
きるが、このことには２つの問題があるように思われ
る。第１に、高価な特性を必要としないオブジェクトの
場合でも、簡単なオブジェクト呼出しが高価なものにな
る。第２に、第三者が、その特定のニーズに特有の新し
い特性を追加することが難しくなる。

【００１０】したがって、オブジェクト・インタフェー
スおよびオブジェクト処理系から分離された何らかの方
式で実施される、分散システムで最も重要なオブジェク
ト呼出しおよび引数引渡しの基本機構を制御する方法が
必要である。

【００１１】リモート動作用の言語レベル・ベニヤ（ve
neer）を与える技法（たとえば、「リモート・プロシー
ジャ・コール」）が何年も前から使用されている。通
常、このような技法は、リモート・インタフェースがあ
る種の言語で定義された形をとる。その場合、このイン
タフェースから一対のスタブが生成される。クライアン
ト・スタブは、ある計算機で動作し、リモート・インタ
フェースから導かれる言語レベル・インタフェースを提
供する。サーバ・スタブは、他の何らかの計算機で動作
し、リモート・インタフェースから導かれる言語レベル
・インタフェースを呼び出す。次に、図１を参照する。
ある計算機１０上のクライアント・アプリケーション１
２は、リモート動作を実行するために、クライアント・
スタブ１４を呼び出す。クライアント・スタブ１４は、
呼出しに関連する引数を、ネットワーク・バッファにマ
ーシャルして、リモート・計算機１８上のサーバ・スタ
ブ２２に送信する。サーバ・スタブは、ネットワーク・
バッファから引数をマーシャル解除して、サーバ・アプ
リケーション２４を呼び出す。同様に、サーバ・アプリ
ケーション２４が応答を返すときは、結果がサーバ・ス
タブ２２によってマーシャルされ、クライアント・スタ
ブ１４に返される。クライアント・スタブ１４は、結果
をマーシャル解除してクライアント・アプリケーション
１２に返す。引数および結果の送信とリモート・オブジ
ェクト呼出しの機構全体がスタブで実行される。クライ
アント・アプリケーションとサーバ・アプリケーション
は共に、従来型の言語レベル・インタフェースを使用す
るに過ぎない。

【００１２】引数または結果が整数や文字列など簡単な
値であるとき、マーシャルおよびマーシャル解除の作業
はかなり簡単である。スタブは通常、引数のリテラル値
をネットワーク・バッファに入れるに過ぎない。しか
し、抽象データ・タイプまたは抽象オブジェクトをサポ
ートする言語では、マーシャルははるかに複雑なものと
なる。１つの解決策は、スタブがオブジェクトの内部デ
ータ構造をマーシャルし、次いでこのデータを新しいオ
ブジェクトとしてマーシャル解除することである。この
ことには、いくつかの重大な欠点がある。第１に、これ
はオブジェクト指向プログラミングの「抽象化」原則の
違反である。というのは、スタブはオブジェクトの内部
構造に関して知ることができないからである。第２に、
オブジェクトのサーバ処理系とクライアント処理系はそ
のデータ構造用に同じ内部レイアウトを使用する必要が
ある。第３に、実際にはオブジェクトのすべての内部状
態を他の計算機へ送信する必要があるわけではないの
で、大量の不要なデータをマーシャルすることが必要に
なることがある。代替解決策は、オブジェクトをマーシ
ャルするときに、オブジェクトの内部状態を送信しない
ことである。その代わりに、オブジェクト用の識別トー
クンを生成し、このトークンを送信する。たとえば、Ｅ
ｄｅｎシステムでは、オブジェクトに名前が割り当てら
れ、オブジェクトがマーシャルされるとき、その実際の
表現ではなくその名前がマーシャルされる。その後、リ
モート計算機は、このオブジェクト上で動作したいと
き、名前を使用して、オブジェクトの最初の位置を見つ
けて呼出しをその位置へ送信しなければならない。この
機構は、ファイルやデータベースなど複雑なオブジェク
トに適しているが、デカルト座標対を表すオブジェクト
など簡単な抽象化には不適当であることが多い。後者の
場合、オブジェクトの実際の状態をマーシャルした方が
よい。最後に、ある種のオブジェクト指向プログラミン
グ・システムは、オブジェクト処理系が、その引数をど
のようにマーシャルしマーシャル解除するかを制御でき
るようにする手段を提供する。たとえば、Ａｒｇｕｓシ
ステムでは、オブジェクト処理系はその内部表現と特定
の具体的な外部表現のマップを行う機能を提供すること
ができる。Ａｒｇｕｓスタブは、特定の内部表現ではな
く外部表現が送信されるように、オブジェクトをマーシ
ャルしマーシャル解除する際に適当なマッピング関数を
呼び出す。これらの異なる解決策はすべて、すべてのオ
ブジェクト用の単一の標準マーシャル方式を課し、ある
いは個別のオブジェクト・インプリメンタがマーシャル
の詳細に責任を負うことを必要とするものである。

【００１３】オブジェクト指向言語内では、反射技法に
よって、オブジェクト・インプリメンタは、いくつかの
基本オブジェクト機構を制御することができる。［「Ｒ
ｅｆｌｅｃｔｉｖｅ Ｆａｃｉｌｉｔｉｅｓ ｉｎ Ｓ
ｍａｌｌｔａｌｋ−８０」（Ｂｒｉａｎ Ｆｏｏｔｅ
＆ Ｒａｌｐｈ Ｅ．Ｊｏｈｎｓｏｎ １９８９、ＯＯ
ＰＳＬＡ ’８９ Ｐｒｏｃｅｅｄｉｎｇｓ、３２７な
いし３３５ページ）を参照されたい］。極めて簡単に言
うと、反射システムとは、それ自体の態様を表す構造を
組み込んだシステムであり、反射計算とは、システム自
体に関するシステムの計算である。

【００１４】たとえば、３−ＫＲＳ言語では、オブジェ
クトはそれ自体に関連するメタ・オブジェクトを有する
ことができる。メタ・オブジェクトは、オブジェクトが
どのように情報を継承するか、オブジェクトをどのよう
にプリントするか、メッセージの引渡し（すなわちオブ
ジェクト呼出し）をどのように実施するかなどを指定す
る方法を提供する。しかし、３−ＫＲＳは引数引渡しに
対する制御は提供しない。

【００１５】Ｓｍａｌｌｔａｌｋ８０で反射オブジェク
ト呼出しを行うことによって、呼出し時に自動的にロッ
クされるオブジェクトと、最初に読み取られたときしか
値の計算を行わないオブジェクトを実施することが可能
になった。

【００１６】しかし、反射は単一のアドレス空間内で使
用されたが、具体的に分散計算の問題にそれを適用しよ
うとする試みはなされなかった。

【００１７】

【発明が解決しようとする課題】したがって、本発明
は、サブコントラクトと呼ばれる論理モジュールを備
え、オブジェクト・インプリメンタが容易に、既存のサ
ブコントラクトを選択して使用できるようになり、アプ
リケーション・プログラマが、特定のオブジェクトに使
用されている特定のサブコントラクトに気付かないよう
に、分散システムで最も重要なオブジェクト呼出しおよ
び引数引渡しの基本機構を制御するように設計された装
置および方法を提供するものである。

【００１８】具体的には、本出願は、共用メモリ領域に
よって安全にかつ効率的に引数を渡す共用メモリ・サブ
コントラクト機構を提供するものである。この共用メモ
リ・サブコントラクト機構は、クライアントとサーバが
同じ計算機上、または同じマルチプロセッサ装置上、あ
るいは場合によってはいくつかのローカル・エリア・ネ
ットワーク（ＬＡＮ）中にある場合など、クライアント
およびサーバが動作している特定のハードウェア構成で
許容されるときに特に適切である、共用メモリ領域によ
って安全にかつ効率的に引数を渡す共用メモリ・サブコ
ントラクト機構を提供するものである。従来技術は、Ｄ
ｉｇｉｔａｌ Ｅｑｕｉｐｍｅｎｔ Ｃｏｒｐｏｒａｔ
ｉｏｎ ＳＲＣ Ｆｉｒｅｆｌｙマルチプロセッサ・ワ
ークステーションのＴＡＯＳオペレーティング・システ
ムに一体化された「ライトウェイト・リモート・プロシ
ージャ・コール（「ＬＲＰＣ」）通信機構について説明
している「Ｌｉｇｈｔｗｅｉｇｈｔ Ｒｅｍｏｔｅ Ｐ
ｒｏｃｅｄｕｒｅ Ｃａｌｌ」（Ｂｒｉａｎ Ｎ．Ｂｅ
ｒｓｈａｄ、Ｔｈｏｍａｓ Ｅ．Ａｎｄｅｒｓｏｎ、Ｅ
ｄｗａｒｄ Ｄ．Ｌａｚｏｗｓｋａ、およびＨｅｎｒｙ
Ｍ．Ｌｅｖｙ著、Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏ
ｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ，Ｕｎｉｖｅｒｓｉｔｙ
ｏｆ Ｗａｓｈｉｎｇｔｏｎ、ワシントン州シアト
ル、Ａｓｓｏｃｉａｔｉｏｎ ｆｏｒ Ｃｏｍｐｕｔｉ
ｎｇ Ｍａｃｈｉｎｅｒｙ発行、１９８９年（文書＃Ａ
ＣＭ０８９７９１−３３８−３／８９／００１２／０１
０２ １０２ないし１１３ページ）と題する論文を参照
されたい）。しかし、このＬＲＰＣ機構は、特にカーネ
ル制御機構に関するものであり、小さく簡単な引数しか
渡さず、カーネルがクライアントとサーバを結合させ、
その後カーネルを使用して、共用メモリ領域（Ａ−スタ
ックと呼ばれる）を割り振り、オブジェクト呼出し時に
Ａ−スタックの有効性を検査する必要がある、同一計算
機通信のケースに対処するものであった。本発明は、共
用メモリ・プロセスでカーネルを使用せず、カーネル・
メモリを必要とせず、少数のドア識別子およびチャネル
識別子しか必要としない。渡される引数は、「小さく簡
単な引数だけ」に制限されず、共用メモリ・プロセスを
変更または修正する場合も、あるいは異なる共用メモリ
・プロセスを追加する場合も、カーネルを修正する必要
はない。

【００１９】

【課題を解決するための手段】本発明は、クライアント
・アプリケーションによってオブジェクトを呼び出すた
めの機構と、クライアント・アプリケーションとオブジ
ェクト処理系の間で引数を渡すための機構を、クライア
ント・アプリケーションにも、オペレーティング・シス
テムにも、これらの機構がどのように動作するかの詳細
が分からないように提供する優れた簡単な方法を提供す
るものである。さらに、これらの機構は、クライアント
・アプリケーションがあるコンピュータ上にあり、オブ
ジェクト処理系が別のコンピュータ上にある分散コンピ
ュータ環境で同様に容易にかつ効率的に機能する。

【００２０】本発明は、メソッド・テーブルと、サブコ
ントラクト機構と、サブコントラクトのローカル・プラ
イベート状態を表すデータ構造とを含む「スプリング・
オブジェクト」と呼ばれる新しいタイプのオブジェクト
を含む。

【００２１】サブコントラクト機構は、本発明の中心で
あり、各サブコントラクトは、クライアント側部分と関
連するサーバ側部分とを含む。各オブジェクト・タイプ
は、関連するサブコントラクトを有する。サブコントラ
クトのクライアント側部分は、新しいスプリング・オブ
ジェクトを生成し、スプリング・オブジェクトを削除
し、クライアントに関連するオブジェクトに関する情報
を通信バッファにマーシャルし、クライアントに関連す
るオブジェクトを表す通信バッファ中のデータをマーシ
ャル解除し、クライアントに関連するサーバ側サブコン
トラクトへ通信バッファを送信する能力を有する。通信
バッファの送信には、ある位置から他の位置へのオブジ
ェクトの送信、またはある位置から他の位置へのオブジ
ェクトのコピーの送信が含まれる。サブコントラクト機
構のサーバ側部分は、スプリング・オブジェクトを作成
し、着呼および関連する通信バッファを処理するための
サポートを提供し、オブジェクトを取り消すためのサポ
ートを提供する能力を含む。

【００２２】本発明は、クライアント・アプリケーショ
ンがオブジェクト処理系とは異なるコンピュータ上にあ
る分散計算システムで、サブコントラクトを使用して、
引数自体がオブジェクトでもよい引数の引渡しを含めオ
ブジェクト呼出しを処理する方法を含む。

【００２３】提供される１つのサブコントラクト機構
は、本明細書で定義したすべてのサブコントラクトの場
合と同様に、オペレーティング・システム・カーネルの
外側で実行され、クライアントとサーバの間で共用すべ
きメモリ空間を見つけるための複数のデータ構造を有
し、アドレスされた共用メモリが呼び出し中のサーバに
よって許可されていることを確実に識別するインデック
スをこれらのデータ構造のうちの１つに有する共用メモ
リ・サブコントラクトである。

【００２４】本出願では、サーバが最初、共用メモリ領
域をセットアップし、その後、共用メモリ領域を使用し
たいクライアントを認めるかどうかと、ユーザ定義域で
実行され、オペレーティング・システム・カーネルでは
実行されないのはどのメソッドかを試験して判定するこ
とができるように、非カーネル・プロセスによってクラ
イアントとサーバの間の共用メモリ領域を使用する方法
も請求する。共用メモリ領域を以前には存在しなかった
場所でセットアップするプロセスも請求する。

【００２５】以下の詳細な説明は、コンピュータまたは
コンピュータ・ネットワーク上で実行されるプログラム
・プロシージャで表して提示することができる。このよ
うなプロシージャによる記述および表現は、当業者が自
分の研究の内容を他の当業者に最も効率的に伝えるため
に使用する手段である。

【００２６】プロシージャとは、本明細書では、および
一般に、所望の結果に至るステップの首尾一貫したシー
ケンスである。このようなステップは、物理量の物理的
操作を必要とするものである。必ずしもそうであるとは
言えないが、この量は通常、記憶し、転送し、組み合わ
せ、その他の方法で操作することができる電気信号また
は磁気信号の形をとる。主として、一般的に使用される
ために、これらの信号をビット、値、要素、記号、文
字、項、数などと呼んだ方が好都合なことがある。しか
し、これらのおよび類似の語がすべて、適当な物理量に
関連付けるべきものであり、かつこのような量に適用さ
れる好都合なラベルに過ぎないことに留意されたい。

【００２７】さらに、実行される操作は、加算や比較な
ど、人間のオペレータによって実行される知的動作に一
般に関連する語で呼ばれることが多い。本発明の一部を
形成する、本明細書で説明する動作では、人間のオペレ
ータのそのような機能は、必要ではなく、あるいは大部
分のケースでは望ましくもない。すなわち、本明細書で
説明する動作は計算機動作である。本発明の動作を実行
するのに有用な計算機には、汎用ディジタル・コンピュ
ータまたは類似の装置が含まれる。

【００２８】本発明は、このような動作を実行する装置
にも関する。この装置は、必要な目的のために特定的に
構成することも、あるいはコンピュータに記憶されたコ
ンピュータ・プログラムによって選択的に活動化され、
あるいは再構成される汎用コンピュータを備えることも
できる。本明細書で提示するプロシージャは、基本的
に、特定のコンピュータまたはその他の装置に関係する
ものではない。本明細書中の教示に従って作成されたプ
ログラムと共に様々な汎用計算機を使用することがで
き、あるいは必要なメソッド・ステップを実行するため
により専門的な装置を構成した方が好都合であることも
ある。このような様々な計算機に必要な構造は、与えら
れた説明から明らかになろう。

【００２９】

【発明の実施の形態】以下の開示は、オブジェクト指向
システムの設計者が、後で変更するのが困難なメソッド
にオブジェクト指向システムをロックしないように、引
数がオブジェクトでよい分散システムでオブジェクト呼
出し方式および引数引渡し方式を実施しようとする際に
出会う問題の解決策について説明するものである。本発
明は、メソッド・テーブルと、サブコントラクト機構
と、サブコントラクトのローカル・プライベート状態を
表すデータ構造とを含む「スプリング・オブジェクト」
と呼ばれる新しいタイプのオブジェクトを含む。各オブ
ジェクトに関連するサブコントラクトに関する方法およ
び装置を開示する。各サブコントラクトは、クライアン
ト側部分と関連するサーバ側部分とを含む。各オブジェ
クト・タイプは、関連するサブコントラクトを有する。
サブコントラクトのクライアント側部分は、新しいスプ
リング・オブジェクトを生成し、スプリング・オブジェ
クトを削除し、クライアントに関連するオブジェクトに
関する情報を通信バッファにマーシャルし、クライアン
トに関連するオブジェクトを表す通信バッファ中のデー
タをマーシャル解除し、クライアントに関連するサーバ
側サブコントラクトへ通信バッファを送信する能力を有
する。通信バッファの送信には、ある位置から他の位置
へのオブジェクトの送信、またはある位置から他の位置
へのオブジェクトのコピーの送信が含まれる。サブコン
トラクト機構のサーバ側部分は、スプリング・オブジェ
クトを作成し、着呼および関連する通信バッファを処理
するためのサポートを提供し、オブジェクトを取り消す
ためのサポートを提供する能力を含む。

【００３０】以下の説明では、説明の都合上、本発明を
完全に理解してもらうために特定のデータおよび関係に
ついて述べる。本明細書で説明する好ましい実施の態様
は、サン・マイクロシステムズ社（Ｓｕｎ Ｍｉｃｒｏ
ｓｙｓｔｅｍｓ，Ｉｎｃ．、Ｓｕｎ Ｍｉｃｒｏｓｙｓ
ｔｅｍｓはサン・マイクロシステムズ社の登録商標であ
る）のＳＰＲＩＮＧオブジェクト指向オペレーティング
・システム（ＳＰＲＩＮＧ Ｏｂｊｅｃｔ−Ｏｒｉｅｎ
ｔｅｄ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の一部と
して実施される。しかし、当業者には、本発明が、特定
の詳細なしで実施でき、様々なコンピュータ・システム
や、様々な構成またはモデルの密結合プロセッサあるい
は様々な構成の粗結合マルチプロセッサ・システムで実
施できることが明らかであろう。

【００３１】ＳＰＲＩＮＧオブジェクトとは、状態を含
む抽象化であり、その状態を操作する１組のメソッドを
与える。オブジェクトおよびそのメソッドの記述は、イ
ンタフェース定義言語で指定されたインタフェースであ
る。インタフェースは、オブジェクトのインプリメンタ
（サーバ）とクライアントの間の強力なタイプのコント
ラクトである。

【００３２】ＳＰＲＩＮＧ定義域とは、スレッドの集合
を有するアドレス空間である。所与の定義域は、ある種
のオブジェクトのサーバおよび他のオブジェクトのクラ
イアントとして働くことができる。インプリメンタとク
ライアントは、同じ定義域に存在することも、あるいは
異なる定義域に存在することもできる。

【００３３】ＳＰＲＩＮＧは、オブジェクト指向のもの
なので、インタフェース継承の概念をサポートする。ス
プリングは、単一インタフェース継承の概念と複数イン
タフェース継承の概念を共にサポートする。タイプ「ｆ
ｏｏ」のオブジェクトを受け入れるインタフェースは、
「ｆｏｏ」のサブクラスのインスタンスも受け入れる。
たとえば、ａｄｄｒｅｓｓ＿ｓｐａｃｅオブジェクト
は、ｍｅｍｏｒｙ＿ｏｂｊｅｃｔを取り出してアドレス
空間にマップするメソッドを有する。同じメソッドは、
ｆｉｌｅオブジェクトおよびｆｒａｍｅ＿ｂｕｆｆｅｒ
オブジェクトがｍｅｍｏｒｙ＿ｏｂｊｅｃｔインタフェ
ースから継承する限りそれらのオブジェクトも受け入れ
る。

【００３４】ＳＰＲＩＮＧカーネルは、基本定義域間呼
出しおよびスレッドと、低レベル計算機依存処理をサポ
ートすると共に、メモリ・マッピングおよび物理メモリ
管理のための基本仮想メモリ・サポートを提供する。Ｓ
ＰＲＩＮＧカーネルは、他のＳＰＲＩＮＧカーネルのこ
とは知らず、すべてのリモート呼出しはネットワーク・
プロキシ・サーバによって処理される。仮想メモリ・シ
ステムは、記憶およびネットワーク・コヒーレンシを処
理するために外部ページャにも依存する。

【００３５】図２を参照すると、典型的なＳＰＲＩＮＧ
ノードは、カーネル５０だけでなくいくつかのサーバも
実行する。このようなサーバには、定義域マネージャ５
２、仮想メモリ・マネージャ（「ＶＭＭ」）５４、名前
サーバ５６、ＣＦＳファイル・サーバ５８、ローカル・
ファイル・サーバ６０、動的にリンクされたライブラリ
を管理しキャッシュする責任を負うリンカ定義域６２、
リモート呼出しを処理するネットワーク・プロキシ６
４、基本端末処理を行い、フレーム・バッファおよびマ
ウス・サポートを提供するｔｔｙサーバ６６が含まれ
る。存在してよい他の主要なＳＰＲＩＮＧシステム構成
要素は、ＵＮＩＸプロセス・サーバ６８、サブコントラ
クト・レジストリ６９、任意の数のＳＰＲＩＮＧアプリ
ケーション７０である。

【００３６】ＳＰＲＩＮＧとは、実験的分散環境であ
る。ＳＰＲＩＮＧは現在、分散オペレーティング・シス
テムと、分散アプリケーション用のサポート・フレーム
ワークとを含む。ＳＰＲＩＮＧは、既存のオペレーティ
ング・システムのいくつかの問題、具体的には時間の経
過と共にシステムを進化させ拡張する問題の解決策を開
発するものである。

【００３７】ＳＰＲＩＮＧは、単に処理系を提供するの
でなくインタフェースを提供することに焦点を当ててい
る。ＳＰＲＩＮＧでは、所与のインタフェースの著しく
異なる処理系を単一のシステム内に共存させることがで
きる。オブジェクト・メタファを使用して、インタフェ
ースと処理系のこの分離を表すと好都合であることが分
かっている。

【００３８】ＳＰＲＩＮＧは、アプリケーション作成者
が基本機構を変更せずに新しい基本的な特性をシステム
に追加することを容易にすることを目的としている。た
とえば、現行のシステムは、アトミック・トランザクシ
ョンをサポートしていない。このような新しい特性をシ
ステムに徐々に追加することは可能なはずである。

【００３９】インタフェース定義言語 ＳＰＲＩＮＧの基本原則は、すべての主要なインタフェ
ースが標準インタフェース定義言語で定義されることで
ある。この言語は、オブジェクト指向であり、複数継承
のサポートを含む。この言語は、インタフェースの特性
のみに関与し、処理系の情報は提供しない。

【００４０】インタフェース定義言語から言語固有スタ
ブを生成することが可能である。このスタブは、ＳＰＲ
ＩＮＧインタフェースとの言語固有マッピングを行う。
たとえば、主要な処理系言語のＣ＋＋では、スプリング
・オブジェクトはＣ＋＋オブジェクトによって表され
る。スタブ・オブジェクト上のメソッドは、呼び出され
ると、現アドレス空間内でローカル呼出しを実行し、あ
るいは異なる計算機上にある他のアドレス空間へ呼出し
を転送する。

【００４１】ＳＰＲＩＮＧは、インタフェースの処理系
からの分離を極めて重視する。クライアントは、それが
ローカル・オブジェクトとして認識するものを処理する
ことに制限され、システムは、このうようなオブジェク
トがどのように実施されるかに関して制限を課さない。
たとえば、オブジェクトの基本状態は、クライアントと
同じアドレス空間にあることも、他のアドレス空間にあ
ることも、クライアントとサーバの間で共用されるメモ
リにあることも、これらの状態のうちのいくつかの状態
の間で動的に移行することもある。

【００４２】スプリング・オブジェクト・モデル ＳＰＲＩＮＧは、他の分散オブジェクト指向システムと
はわずかに異なる方法でオブジェクトを見る。サブコン
トラクトの詳細を論じる前にこのことを明確にしておく
必要がある。

【００４３】大部分の分散システムは、オブジェクトが
サーバ計算機に存在し、クライアント計算機が、サーバ
にあるオブジェクトを指すオブジェクト・ハンドルを有
する、モデルを提供する（図１０ａ参照）。したがっ
て、クライアントは、オブジェクトではなくオブジェク
ト・ハンドルを渡す。

【００４４】ＳＰＲＩＮＧは、クライアントがオブジェ
クト・ハンドルではなく直接オブジェクトを処理するモ
デルを提供する（図１０ｂ参照）。このようなオブジェ
クトのうちのいくつかは、それらに関連するすべての状
態をあるリモート位置に維持し、そのため、それらのロ
ーカル状態はこのリモート位置へのハンドルから成るに
過ぎない。オブジェクトは一度に１つの場所にしか存在
できず、したがって、オブジェクトを誰かに送信する場
合は、オブジェクト自体を有することを終了する。しか
し、オブジェクトは送信する前にコピーすることがで
き、これは、２つの異なるオブジェクトが同じリモート
状態を指すように実施することができる。

【００４５】したがって、Ｅｄｅｎなどのシステムで
は、いくつかのクライアントが、あるリモート・オブジ
ェクトを参照するオブジェクト・ハンドルを有するが、
ＳＰＲＩＮＧでは、いくつかのクライアントが、同じリ
モート状態を参照するオブジェクトを有する。

【００４６】大部分のサーバ・ベースのオブジェクトで
は、この違いは主として１つの用語である。しかし、Ｓ
ＰＲＩＮＧは、サーバ・ベースではなく、あるいはオブ
ジェクトの状態がクライアントとサーバの間で分割され
るオブジェクトもサポートする。このような場合、クラ
イアントを、単にポインタを処理するものではなく、真
のオブジェクトを処理するものとみなした方がずっと好
都合である。

【００４７】現在の所、ＳＰＲＩＮＧオペレーティング
・システムは、基本オブジェクト指向プロセス間通信お
よびメモリ管理を行う最小カーネルに基づくものであ
る。名前付け、ページング、ファイル・システムなどの
機能はすべて、基本カーネル上のユーザ・モード・サー
ビスとして提供される。システムは基本的に分散型であ
り、主要な機能のネットワーク性能を高めるためにいく
つかのキャッシング技法が使用される。システムは、ｍ
ａｋｅ、ｖｉ、ｃｓｈ、Ｘウィンドウ・システムなど標
準ユーティリティをサポートするのに十分なＵＮＩＸエ
ミュレーションもサポートする。

【００４８】ＳＰＲＩＮＧの目標は、高度の多様性をサ
ポートすることである。個別のサブシステムが、一般規
則および規定を無視できるサブシステム自体の作業実施
方法を開発できることが重要であると考えられる。

【００４９】サブコントラクト機構 より近代的なシステムでは、アプリケーション・ソフト
ウェアが直接ネットワーク・ソフトウェアと対話するこ
とはない。その代わり、アプリケーション・ソフトウェ
アは、「スタブ」（図１中の１４）と対話する。ネット
ワークを介してサポートされる異なる各インタフェース
ごとに異なるスタブがある。スタブ・コードは、アプリ
ケーション・レベル・ソフトウェアから見える特定言語
レベル・インタフェースと、ネットワーク・ソフトウェ
アによって提供される低レベル通信インタフェースとの
間の変換を行う責任を負う。たとえば、スタブは、リモ
ート呼出しの引数を取り出し、ネットワーク・ソフトウ
ェアがネットワークを介して送信するのに適したメッセ
ージに入れることに責任を負う。

【００５０】次に図４を参照すると、本発明の環境で
は、計算機１０上のクライアント・アプリケーション１
２が適当なクライアント側スタブ１４へ呼出しを発行
し、スタブ１４が「サブコントラクト」３０のクライア
ント側部分を呼び出す。サブコントラクトは、ネットワ
ーク・ソフトウェア１６と対話し、ネットワーク・ソフ
トウェア１６は、一般に他の計算機１８にある、ソフト
ウェア１６と対のネットワーク・ソフトウェア２０と通
信する。このサーバ側ネットワーク・ソフトウェア２０
は、サブコントラクト３２のサーバ側部分へ着信メッセ
ージを転送し、サブコントラクト３２はサーバ・アプリ
ケーション２４へそのデータを転送する。図のように、
サブコントラクトは、スタブとネットワーク・ソフトウ
ェアの間に位置する。スタブは、サブコントラクトを使
用して、リモート呼出しを実行し、次いで同様に、ネッ
トワーク・ソフトウェアを使用して、実際の呼出しを実
行する。異なるサブコントラクトは、標準通信ソフトウ
ェア上で異なる種類のリモート通信プロトコル（複製
用、キャッシング用など）を実施する。

【００５１】単一のコンピュータ内で、異なるアプリケ
ーションがサブコントラクトを使用して通信することも
できる。次に図５を参照すると、クライアント・アプリ
ケーション１２は、アプリケーション空間３８にあり、
適当なクライアント側スタブ１４上で呼出しを発行す
る。クライアント側スタブ１４は適当なサブコントラク
ト３０を呼び出す。サブコントラクト３０は、その通信
をオペレーティング・システム３６へ転送し、オペレー
ティング・システム３６はサーバ側サブコントラクト３
２へ通信を中継する。サーバ側サブコントラクト３２は
そのサーバ側スタブ２２にデータを与え、サーバ側スタ
ブ２２はサーバ・アプリケーション２４にデータを渡
す。この場合、オペレーティング・システム３６によっ
て提供されるプロセス間通信プリミティブが、ネットワ
ーキング・ソフトウェアによって提供される計算機間通
信機構（図４中の１６および２０）に取って代わってい
る。

【００５２】単一のアドレス空間で動作する単一のアプ
リケーション内でも、アプリケーションの異なる構成要
素間でサブコントラクトを使用して通信することができ
る。

【００５３】次に図３を参照し、オブジェクト指向の観
点から検討すると、クライアント・アプリケーション１
は「スタブ・オブジェクト」２を介して動作する。この
ようなスタブ・オブジェクト２はそれぞれ、サブコント
ラクト・オブジェクト３を含む。サブコントラクト・オ
ブジェクト３の内部状態４（サブコントラクト・オブジ
ェクトの「表現」と呼ばれる）は、同じアドレス空間に
存在することも、同じ計算機上の他のアドレス空間に存
在することも、あるいは全体的に他の計算機上に存在す
ることもできる実際の基本状態５を指す何らかの形のポ
インタ６を含む。基本状態は通常、サーバ・アプリケー
ションのアドレス空間中のオブジェクト５として表され
る。

【００５４】サブコントラクトの適用 スプリング・オブジェクトは、オブジェクトのタイプ定
義によって暗黙指定される各動作ごとの項目を含むメソ
ッド・テーブルと、次節で説明する基本サブコントラク
ト動作を指定するサブコントラクト記述と、オブジェク
トの表現と呼ばれるあるローカル・プライベート状態の
３つから成るものとしてクライアントによって認識され
る。

【００５５】クライアントは、Ｃ＋＋オブジェクト上で
メソッドを呼び出すことによってオブジェクトと相互作
用する。このオブジェクト用のコードは実際は自動的に
生成されており、そのコードは、オブジェクトの正規メ
ソッド・テーブルまたはオブジェクトのサブコントラク
ト動作ベクトル上での呼出しへメソッド呼出しを変換す
る。このようなメソッドがどのようにその効果を達成す
るかは、クライアントからは見えない。

【００５６】オブジェクトがリモート・サーバによって
実施される場合、典型的な構成は、サブコントラクト
が、リモート・サーバと通信する機構を実施するもので
あり、メソッド・テーブルは、バッファに引数をマーシ
ャルし、リモート呼出しを実行するサブコントラクトを
呼出し、次いで応答バッファから結果をマーシャル解除
することのみを実行するスタブ・メソッドを指すポイン
タから成る。ＳＰＲＩＮＧは、インタフェース定義言語
から適当なスタブを生成する自動スタブ・ジェネレータ
を提供する。

【００５７】リモート・サーバには通常、着呼に関連す
るサブコントラクト作業を実行する何らかのサブコント
ラクト・コードと、各動作ごとの引数をマーシャル解除
しサーバ・アプリケーションを呼び出す何らかのサーバ
側スタブ・コードがある（このサーバ・スタブ・コード
も自動的に生成される）。

【００５８】オブジェクトが全体的にローカルに実施さ
れる場合、スタブ・メソッドを不要にして、メソッド・
テーブルに直接入れることができる処理系メソッドを提
供することができる。ＳＰＲＩＮＧは、この場合にメソ
ッド・テーブルを生成するためのサポートを提供する。

【００５９】基本サブコントラクト機構 クライアント側サブコントラクト動作は以下のとおりで
ある。 ・ｃｏｐｙ ・ｃｏｎｓｕｍｅ ・ｕｎｍａｒｓｈａｌ ・ｍａｒｓｈａｌ ・ｍａｒｓｈａｌ＿ｃｏｐｙ ・ｉｎｖｏｋｅ ・ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ ・ｎａｒｒｏｗ ・ｏｂｊｅｃｔ＿ｔｙｐｅ＿ｉｄ ・ｏｂｊｅｃｔ＿ｍａｎａｇｅｒ＿ｉｄ ・ｉｓ＿ｎｕｌｌ

【００６０】サブコントラクト動作を例示するために、
ｓｉｎｇｌｅｔｏｎと呼ばれるサブコントラクトを一例
として使用するものとする。このサブコントラクトは、
ドアと呼ばれるＳＰＲＩＮＧカーネル通信機構上に構成
される。ドアは、通信エンドポイントであり、スレッド
は、通信エンドポイントに対してアドレス空間間呼出し
を実行することができる。ドアを作成する定義域は、ド
ア識別子を受信する。定義域はドア識別子を他の定義域
に渡すことができ、したがって、他の定義域は、関連す
るドアに呼出しを発行することができる。カーネルは、
ドアおよびドア識別子の構成、破壊、コピー、送信を含
め、ドアおよびドア識別子に対するすべての動作を管理
する。

【００６１】ｓｉｎｇｌｅｔｏｎでは、サーバ定義域
は、オブジェクトに関連する基本状態を維持し、着呼を
受け入れるドアを作成する。クライアント定義域は、サ
ーバ定義域を呼び出すために使用するドア識別子を所有
するに過ぎない。

【００６２】したがって、ｓｉｎｇｌｅｔｏｎサブコン
トラクト上に構成されるＳＰＲＩＮＧオブジェクトは、
全体的にスタブ・メソッドから成るメソッド・テーブル
と、ｓｉｎｇｌｅｔｏｎサブコントラクト記述子と、カ
ーネルドア識別子から成る表現とから成る。

【００６３】Ｃｏｐｙサブコントラクトｃｏｐｙ動作
は、既存のスプリング・オブジェクトに密接に関係する
新しいスプリング・オブジェクトを生成するために使用
される。コピーとオリジナルの正確な関係は、完全にサ
ブコントラクトの動作に依存する。サブコントラクト・
コードがそれ自体のコピーを実行するもできるが、オブ
ジェクトの処理系コードを含めることを選択することも
できる。

【００６４】ｓｉｎｇｌｅｔｏｎは、現ドア識別子のコ
ピーを作成するようカーネルに要求し、次いで、表現が
この新しいドア識別子であり、かつ現オブジェクトと同
じサブコントラクトおよびメソッド・テーブルを参照す
る、新しいオブジェクトを作成することによって、コピ
ーを実施する。したがって、コピー後、それぞれ、同じ
基本サーバ状態を参照する２つの異なるスプリング・オ
ブジェクトがある（この場合、コピーの意味は、ポイン
タをコピーするという意味である）。

【００６５】サーバレス・オブジェクトでは、コピーを
実施する際、オブジェクトの状態全体をコピーする必要
があり、そのため、新しいオブジェクトは、最初のオブ
ジェクトとはまったく異なるものとなる。

【００６６】Ｃｏｎｓｕｍｅ サブコントラクトｃｏｎｓｕｍｅ動作は、スプリング・
オブジェクトを削除するために使用される。

【００６７】ｓｉｎｇｌｅｔｏｎは、現オブジェクトに
関連するドア識別子を削除することによってｃｏｎｓｕ
ｍｅを実施する。これによってオブジェクトのサーバ状
態が直接影響を受けることはなく、同じサーバ状態を参
照する他のスプリング状態がある場合、その状態がこの
動作の影響を受けることはない。

【００６８】実際は、ドアを参照するすべてのドア識別
子が削除されているとき、サーバがそのサーバ状態を解
除できるようにカーネルが任意選択でサーバに通知する
ことに留意されたい。

【００６９】Ｍａｒｓｈａｌ サブコントラクトｍａｒｓｈａｌ動作は、オブジェクト
を他の計算機へ送信するときに使用される。

【００７０】この動作は、現オブジェクトを取り出し、
通信バッファに十分な情報を置き、それによって、この
バッファの他の定義域からほぼ同じオブジェクトをマー
シャル解除できるようにする。

【００７１】所望の意味がオブジェクトを送信すること
なので、オブジェクトを送信した後に、もはやそのオブ
ジェクトをアドレス空間に有すべきでないことは明らか
である。したがって、マーシャルの暗黙的な副作用は、
オブジェクトに関連するすべてのローカル状態を削除す
ることである。

【００７２】ｓｉｎｇｌｅｔｏｎは、そのドア識別子を
マーシャル・バッファ中に置くことによってマーシャル
を実施する。カーネルの定義域間呼出し機構は、通信バ
ッファを他の定義域へ送信する際にドア識別子をその定
義域から暗黙的に削除する。

【００７３】Ｍａｒｓｈａｌ ｃｏｐｙ インタフェース定義言語は、パラメータ引渡しモードｃ
ｏｐｙをサポートする。このモードは、引数オブジェク
トのコピーが送信されるが、現定義域が最初のオブジェ
クトを保持することを暗黙指定する。

【００７４】このモードは最初、まずサブコントラクト
・コピー動作を呼び出し、次いでサブコントラクト・マ
ーシャル動作を呼び出すことによって実施された。しか
し、この場合、ただちに削除されるスプリング・オブジ
ェクトを作成する冗長な作業が行われることが多かっ
た。この作業は、大量の状態を有するサーバレス・オブ
ジェクトでは特に費用がかかった。

【００７５】したがって、ｍａｒｓｈａｌ＿ｃｏｐｙ動
作が導入された。この動作は、コピーとその後に続くマ
ーシャルの効果をもたらすことと定義されているが、い
くつかの中間ステップを省略して最適化することが可能
である。

【００７６】ｓｉｎｇｌｅｔｏｎの場合、現ドア識別子
をコピーし、新しいドア識別子を通信バッファに入れる
だけである。

【００７７】サーバレス・オブジェクトの場合、ｍａｒ
ｓｈａｌ＿ｃｏｐｙでは、オブジェクトのデータ構造を
マーシャル・バッファにコピーすることが必要になるこ
とがある。

【００７８】Ｕｎｍａｒｓｈａｌ ｕｎｍａｒｓｈａｌ（マーシャル解除）動作は、他の定
義域からオブジェクトを受信するときに使用される。こ
の動作のジョブは、メソッド・テーブルとサブコントラ
クト・ベクトルと表現とから成る完全なスプリング・オ
ブジェクトを作成することである。

【００７９】あるソフトウェア（通常スタブ・メソッ
ド）が通信バッファからオブジェクトを読み取ることを
決定したとき、そのソフトウェアは、予想されるオブジ
ェクト・タイプに基づいて最初のサブコントラクトと最
初のメソッド・テーブルを共に選択しなければならな
い。ソフトウェアは次いで、最初のサブコントラクトを
呼び出し、そのサブコントラクトに最初のメソッド・テ
ーブルを渡す。

【００８０】サブコントラクトは次いで、通信バッファ
中の情報に基づいてオブジェクトの作成を試みなければ
ならない。この場合、通常、表現を作成できるように通
信バッファから十分な情報を読み取る必要がある。

【００８１】ｓｉｎｇｌｅｔｏｎの場合、この動作では
通常、ドア識別子をバッファから読み取り、このドア識
別子を保持する表現を作成する必要がある。

【００８２】最後に、マーシャル解除は、サブコントラ
クト・ポインタとメソッド・テーブル・ポインタと表現
を組み合わせて、新しいスプリング・オブジェクトを作
成する。

【００８３】Ｉｎｖｏｋｅ ｉｎｖｏｋｅ動作は、引数バッファを宛先へ送信して結
果バッファを受信するために使用される。

【００８４】ｓｉｎｇｌｅｔｏｎの場合、この動作で
は、ターゲットドア識別子への定義域間呼出しを実行す
るうえでカーネルへのトラップしか使用しない。

【００８５】複製をサポートするサブコントラクトの場
合、この動作では、１組の可能なサーバのうちの１つ
（または複数）へ引数バッファを送信することが必要に
なることがある。

【００８６】Ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ サブコントラクト呼出し動作が呼び出されるのは、すべ
ての引数マーシャルが実行された後だけである。実際に
は、オブジェクトのサブコントラクトが、何らかのプリ
アンブル情報を通信バッファに書き込み、あるいは将来
のマーシャルに影響を及ぼすようにフラグをセットする
ことができるように、前記サブコントラクトをプロセス
の初期に使用したいケースがあることが分かった。

【００８７】サブコントラクトが必要な状態をセットア
ップできるように、ＳＰＲＩＮＧは新しいサブコントラ
クト動作ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅを有する。こ
のサブコントラクト動作は、引数マーシャルが行われる
前に呼び出される。

【００８８】たとえば、ある種の状況では、サブコント
ラクトは共用メモリ領域を使用してサーバと通信するこ
とができる。この場合、ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌ
ｅを呼び出すと、サブコントラクトは、すべてのマーシ
ャルが完了した後に引数が共用メモリ領域にコピーされ
るのでなく、その領域に直接引数がマーシャルされるよ
うに共用メモリ領域内を指すように通信バッファを調整
することができる。

【００８９】Ｏｂｊｅｃｔ＿ｔｙｐｅ＿ｉｄ スプリングは、限られた量の実行時入力をサポートす
る。これは、オブジェクト・ブラウジングなどの動作
時、あるいは静的タイプ検査に依存できないある種の動
作のタイプ・セーフティ（すなわちネーミング）を検証
するために使用される。

【００９０】ｏｂｊｅｃｔ＿ｔｙｐｅ＿ｉｄ動作は、現
オブジェクトに関する真のｔｙｐｅ＿ｉｄを返す。

【００９１】ある種のサブコントラクトは、サーバを呼
び出してｔｙｐｅ＿ｉｄを得ることによってこの動作を
実施する。他のサブコントラクトは、オブジェクトのｔ
ｙｐｅ＿ｉｄをその表現の一部として維持することによ
ってこの動作を実施する。この場合、ｔｙｐｅ＿ｉｄ
は、オブジェクトのマーシャルされた形の一部として送
信される必要がある。

【００９２】Ｎａｒｒｏｗ サブコントラクトｎａｒｒｏｗ動作は、基本タイプから
派生タイプへのオブジェクトに対するタイプ検査による
タイプｎａｒｒｏｗｉｎｇをサポートするために使用さ
れる。この動作は、オブジェクトのｔｙｐｅ＿ｉｄを使
用して、ｎａｒｒｏｗが有効であることを検証し、そう
でない場合は例外を発生させる。

【００９３】Ｏｂｊｅｃｔ＿ｍａｎａｇｅｒ＿ｉｄ このサブコントラクト動作は、スプリング・ネーミング
・アーキテクチャをサポートする。この動作は、オブジ
ェクトの基本サーバの名前を得る信頼できる方法を提供
する。この動作は通常、基本サーバを呼び出して名前を
得ることによって実施される。

【００９４】Ｉｓ＿ｎｕｌｌ スプリングは、ヌル・オブジェクトの概念をサポートす
る。このオブジェクトは、プログラムおよびデータ構造
の初期設定時に使用できるプレースホルダ・オブジェク
トを提供する。規則上、ヌル・オブジェクトはすべての
メソッドおよび大部分のサブコントラクト動作上で例外
を発生させる。

【００９５】ＳＰＲＩＮＧは、特殊なヌル・サブコント
ラクトをヌル・オブジェクトに提供することによってこ
のオブジェクトをサポートする。ヌル・サブコントラク
トのｉｓ＿ｎｕｌｌ動作は真を返し、通常のサブコント
ラクトは偽を返す。

【００９６】ヌル・サブコントラクトでは通常、ヌル・
サブコントラクトのオブジェクトをマーシャルすること
ができるが、他の大部分のサブコントラクト動作に対し
て例外を発生させる。

【００９７】サブコントラクト使用法の一例 リモート・オブジェクトを呼び出すときに実行されるサ
ブコントラクト動作のシーケンスを検討すると有用であ
る。これが一例に過ぎず、当業者には、本発明で定義し
たサブコントラクトが、本明細書に記載したこととはか
なり異なることを実行するように構成できることが認識
されよう。以下の議論では図６ないし図９を参照された
い。

【００９８】メソッドＦｒｅｄをサポートし、サブコン
トラクトＳＡを使用する、オブジェクトＡを有すると仮
定する。 fred: proc(copy x: wombat)returns fruitbat

【００９９】リターン・タイプｆｒｕｉｔｂａｔは、あ
る種のサブコントラクトＳＦを使用することが分かって
いる。

【０１００】たとえば、サブコントラクトＳＸを使用す
るタイプｗｏｍｂａｔのオブジェクトＸを有しており、
Ａのｆｒｅｄメソッドを呼び出し、Ｘを引数として渡す
（５０）。

【０１０１】１．まず、「ｆｒｅｄ」のスタブ・メソッ
ドに入る（５２、５４）。

【０１０２】２．スタブ・コードが、Ａのｉｎｖｏｋｅ
＿ｐｒｅａｍｂｌｅ動作を呼び出す（５６）。

【０１０３】３．ＳＡ ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌ
ｅコードが必要な初期設定を実行してリターンする（５
８）。

【０１０４】４．スタブ・コードは次いで、Ｘのｍａｒ
ｓｈａｌ＿ｃｏｐｙ動作を呼び出すことによって、引数
オブジェクトＸをコピー引数としてマーシャルしようと
する。図６で、これは以下のように進行する。スタブｆ
ｒｅｄが、マーシャルすべき引数があるかどうかを調べ
る試験を行う（６０）。答えがｙｅｓなので、スタブｆ
ｒｅｄは、引数を試験して引数のうちにオブジェクトが
あるかどうかを調べる（６２）。スタブｆｒｅｄは、オ
ブジェクトＸを見つけて、ＸがサブコントラクトＳＸを
有することを知り、サブコントラクトＳＸを呼び出して
オブジェクトＸをマーシャルする（６４）。

【０１０５】５．ＳＸ ｍａｒｓｈａｌ＿ｃｏｐｙコー
ドは、Ｘのコピーを表す情報が引数バッファ中に置かれ
るようにして、スタブｆｒｅｄにリターンする（６
４）。

【０１０６】６．この場合、スタブ・コードはすべての
引数をマーシャルしており、実際に呼出しを実行する準
備ができている。したがって、スタブ・コードはＡの呼
出し動作を呼び出す（７０）。

【０１０７】７．ＳＡ呼出しメソッドは、Ｆｒｅｄメソ
ッドに対する呼出しをオブジェクトＡのサーバ状態上で
行うことを求める要求によって、引数バッファをターゲ
ット・サーバへ送信するのに必要な作業を実行し、次い
で結果バッファがサーバから戻るのを待つ（７２）。

【０１０８】８．次に図７を参照すると、呼出しがター
ゲット・サーバによって受信され、データがサーバ側サ
ブコントラクトＳＳＡに転送され、サーバ側サブコント
ラクトＳＳＡはサーバ側スタブＳ２へバッファを転送す
る（７４、７６）。スタブＳ２は、マーシャル解除すべ
き引数があるかどうかを調べる検査を行い（７８）、次
いでどの引数がオブジェクトであるかを調べる検査を行
う（８０）。スタブＳ２は、マーシャル解除すべきオブ
ジェクトＸがあることを知ると、ＳＳＡサブコントラク
トのマーシャル解除動作を呼び出す（８２）。サブコン
トラクトＳＳＡは、オブジェクトＸのサブコントラクト
ｉｄを検査して、オブジェクトＸにサブコントラクトＳ
Ｘが関連付けられていることを知る（８４）。サブコン
トラクトＳＳＡは次いで、サブコントラクトＳＸ上でマ
ーシャル解除動作を呼び出す（８４）。サブコントラク
トＳＸは、オブジェクトＸをマーシャル解除してサブコ
ントラクトＳＳＡに返し、サブコントラクトＳＳＡはオ
ブジェクトＸをスタブＳ２に返す（８６）。スタブＳ２
は、受信したすべての引数のマーシャル解除を完了し
て、ターゲット・オブジェクト処理系に呼出しおよび引
数を渡し（９２）、応答を待つ（９４）。オブジェクト
・インプリメンタは、呼出しを処理して、サブコントラ
クトＳＦとサーバ側サブコントラクトＳＳＦとを有する
オブジェクトｆｒｕｉｔｂａｔ−１を作成し、サブコン
トラクトＳＦ用のサーバ側サブコントラクトとして働く
ようサブコントラクトＳＳＦに命令する（９６）。サブ
コントラクトＳＳＦは、ｆｒｕｉｔｂａｔ−１を識別す
る内部状態を作成し、この状態を指すオブジェクトｆｒ
ｕｉｔｂａｔを返す（９８）。オブジェクト・インプリ
メンタは次に、オブジェクトｆｒｕｉｔｂａｔを、クラ
イアントに返すためにサーバ側スタブＳ２に返す（１０
０）。次に図８を参照すると、スタブＳ２は次に、引数
マーシャル・ルーチンを再び実行してオブジェクトｆｒ
ｕｉｔｂａｔをマーシャルし（１０４、１０６、１０
８、１１０、１１２）、マーシャル済み引数をスタブＳ
２に返さなければならない。スタブＳ２は、マーシャル
済みデータを、クライアント側サブコントラクトＳＡへ
再送信する（１１６）ためにサーバ側サブコントラクト
ＳＳＡへ転送する（１１４）。

【０１０９】９．スタブ・コードは次に、ＳＡ呼出しメ
ソッドから結果バッファを受信し（１３０）、結果のマ
ーシャル解除を開始する。この場合、結果は、サブコン
トラクトＳＦを有するタイプｆｒｕｉｔｂａｔのオブジ
ェクトであることが分かり、したがってスタブｆｒｅｄ
（ＳＡ）は、ＳＦサブコントラクトのマーシャル解除動
作を呼び出し、タイプｆｒｕｉｔｂａｔ用の正規メソッ
ド・テーブルを渡す。呼出しステップ全体を、論理ブロ
ック１４２、１３４、１３６、１３８に示し、互換性の
あるオブジェクトに関する以下の議論でさらに詳しく説
明する。

【０１１０】１０．ＳＦマーシャル解除コードは次に、
結果バッファからオブジェクトをマーシャル解除しよう
とする。ＳＦマーシャル解除コードは、それ自体のサブ
コントラクト・メソッド・テーブル、および渡された正
規メソッド・テーブルと、結果バッファから得た情報を
組み合わせて、新しいスプリング・オブジェクトを形成
する。ＳＦマーシャル解除コードは、新しいスプリング
・オブジェクトを再びスタブに渡す（１４０）。

【０１１１】１１．ｆｒｅｄスタブはそのタスクを完了
しており、結果オブジェクトをアプリケーション・レベ
ルに返すことができる（１４８）。

【０１１２】プロセスは、Ａのｆｒｅｄメソッド用のス
タブ・コードによって駆動されたが、ターゲット・オブ
ジェクト、引数オブジェクト、および結果オブジェクト
用のサブコントラクトも使用した。

【０１１３】互換性のあるサブコントラクト 異なるオブジェクトが異なるサブコントラクトを有する
ことが望ましいことは明らかである。具体的には、同じ
タイプを有するものとしてクライアント・アプリケーシ
ョンによって認識される２つのオブジェクトは、実際に
は異なるサブコントラクトを有することができる。たと
えば、「ファイル」タイプのあるインスタンスは標準
「ｓｉｎｇｌｅｔｏｎ」サブコントラクトを使用するこ
とができ、「ファイル」の他のインスタンスは、これよ
りも興味深い「キャッシュ可能な」サブコントラクトを
使用することができる。

【０１１４】各タイプごとに、標準サブコントラクト
を、そのタイプと対話するときに使用できるように指定
することができる。異なるサブコントラクトが実際に必
要なとき、ＳＰＲＩＮＧがどのように動作するかについ
て説明する。

【０１１５】たとえば、標準タイプｆｉｌｅは、ｓｉｎ
ｇｌｅｔｏｎと呼ばれる簡単なサブコントラクトを使用
するように指定される。タイプｃａｃｈａｂｌｅ＿ｆｉ
ｌｅはｆｉｌｅのサブタイプであるが、その代わり、ｃ
ａｃｈｉｎｇサブコントラクトを使用する。タイプｃａ
ｃｈａｂｌｅ＿ｆｉｌｅのオブジェクトが、タイプｆｉ
ｌｅのオブジェクトが存在することが予想される位置に
送信されたときどうなるかを考える。受信側が、キャッ
ング・オブジェクトをｓｉｎｇｌｅｔｏｎの場合と同様
にマーシャル解除しようとした場合、失敗することは明
らかである。

【０１１６】この問題は、互換性のあるサブコントラク
トの概念を導入することによって解決される。サブコン
トラクトＡは、サブコントラクトＢに関するマーシャル
解除コードが、サブコントラクトＡのオブジェクトの受
信を正しく処理できる場合、サブコントラクトＢと互換
性があると言われる。

【０１１７】互換性のあるサブコントラクトを実施する
ために使用される通常の機構は、ある形のサブコントラ
クト識別子を各オブジェクトのマーシャルされた形の一
部として含めることである。

【０１１８】したがって、典型的なサブコントラクト・
マーシャル解除動作は、通信バッファ中の予想されるサ
ブコントラクト識別子を見ることによって開始する。現
サブコントラクトの予想される識別子が通信バッファに
含まれている場合、サブコントラクトは、正規マーシャ
ル解除を実行する。しかし、他の何らかの値を見つけた
場合、レジストリを呼び出してそのサブコントラクト用
の正しいコードを見つけ、次いでそのサブコントラクト
を呼び出してマーシャル解除を実行する。

【０１１９】現在、すべてのサブコントラクトは相互に
互換性を有し、単一の方式を使用してサブコントラクト
自体を識別している。しかし、相互識別のために異なる
方式を使用し、かつ標準セットと互換性のない、他の数
組のサブコントラクトを追加することが可能である。

【０１２０】新しいサブコントラクトの発見 プログラムは通常、１組の標準サブコントラクトを提供
する１組のライブラリにリンクされる。しかし、プログ
ラムは実行時に、その標準ライブラリにないサブコント
ラクトを使用するオブジェクトに出会うことがある。

【０１２１】サブコントラクト識別子からライブラリ名
へのマップを行う機構が提供され、新しいサブコントラ
クトを得るためのライブラリの動的リンクがサポートさ
れる。

【０１２２】たとえば、定義域は、ｓｉｎｇｌｅｔｏｎ
サブコントラクトを使用してタイプｆｉｌｅのオブジェ
クトを受信することを予想しているが、ここでは、その
代わりにｒｅｐｌｉｃｏｎサブコントラクトを使用して
タイプｒｅｐｌｉｃａｔｅｄ＿ｆｉｌｅのオブジェクト
を定義域へ送信する。ｓｉｎｇｌｅｔｏｎマーシャル解
除動作は、異なるサブコントラクトが使用されているこ
とを発見し、定義域のサブコントラクト・レジストリを
呼び出して正しいサブコントラクト・コードを見つけ
る。レジストリは、現在適切なサブコントラクトがロー
ドされていないことを発見するが、次いでネットワーク
・サービスを使用してサブコントラクト識別子をライブ
ラリ名としてマップし（たとえば、ｒｅｐｌｉｃｏｎ．
ｓｏ）、次いでそのライブラリに動的にリンクしてサブ
コントラクトを得ようとする。

【０１２３】したがって、プログラムが、複製オブジェ
クトの概念を有さず、最初に、複製オブジェクトを理解
するライブラリにリンクされなかった場合でも、複製フ
ァイル・オブジェクトと対話する妥当なコードを動的に
得ることができた。

【０１２４】この機構は、実行時に、古いプログラムが
適当なサブコントラクト・ライブラリを利用できるよう
にしさえすれば、新しいサブコントラクトを追加し、そ
れを使用して、古いアプリケーションも標準ライブラリ
も変更せずに古いアプリケーションと対話することが可
能であることを意味する。この動的リンク方式は、欠点
が多い。

【０１２５】多くの定義域、具体的にはシステム・サー
バは、場合によっては悪意のあるクライアントによって
指定された何らかのランダム動的ライブラリ・コードを
単純に実行することを好まない。したがって、機密保護
のために、動的リンカは、指定されたディレクトリ探索
経路上にあるライブラリしかロードしない。したがっ
て、通常、システム管理者が介入して、大部分の定義域
の探索経路上にある新しいサブコントラクト・ライブラ
リを標準ディレクトリにインストールする必要がある。

【０１２６】サーバ側 多くのサブコントラクトは、クライアント・サーバ計算
をサポートする。サブコントラクトのクライアント側の
ビューについて説明したが、サーバ・ベースのオブジェ
クトでは、サーバ側にもある量の機構がある。

【０１２７】クライアント側では、アプリケーション・
プログラマがサブコントラクト処理系を利用することは
できない。しかし、サーバ側では、サーバ処理系を特定
のサブコントラクトにより密に結合することができる。
たとえば、複製サブコントラクトでは、複製をサポート
するためにサーバ・アプリケーションとの特殊なインタ
フェースが必要になることがある。

【０１２８】したがって、サーバ側インタフェースは、
サブコントラクト間でかなり異なるものになることがあ
る。しかし、言語レベル・オブジェクトからスプリング
・オブジェクトを作成することのサポートと、着呼を処
理することのサポートと、オブジェクトを拒否すること
のサポートの３つの要素が、通常存在する。「言語レベ
ル」オブジェクトとは、状態と１組のメソッドしか含ま
ないオブジェクトである。

【０１２９】スプリング・オブジェクトの作成 サブコントラクトは、言語レベル・オブジェクトからス
プリング・オブジェクトを作成する方法を提供しなけれ
ばならない。これは２つの形をとることができる。

【０１３０】最も簡単な形は、サブコントラクトが通常
のクライアント側スプリング・オブジェクトを作成する
ことである。これは、サブコントラクトがある種の通信
エンドポイント（たとえばｎｕｃｌｅｕｓドア）を作成
し、かつそのエンドポイントが表現によって使用される
クライアント側スプリング・オブジェクトを作成しなけ
ればならないことを意味する。

【０１３１】しかし、ある種のサブコントラクトは、そ
のサーバと同じアドレス空間に存在するスプリング・オ
ブジェクトのための特殊なサポートを提供する。たとえ
ば、ｓｉｎｇｌｅｔｏｎサブコントラクトは、単一のア
ドレス空間内で使用できる最適化された呼出し機構を提
供する。そのようなサブコントラクトを使用してスプリ
ング・オブジェクトが作成されると、そのスプリング・
オブジェクトは通常、特殊なサーバ側動作ベクトルを使
用してオブジェクトを作成し、定義域間通信に必要な資
源を作成する経費を支払うことを不要にする。オブジェ
クトが実際に、他の定義域への送信のためにマーシャル
されるとき、サブコントラクトは最終的に、このような
資源を作成する。

【０１３２】したがって、ｓｉｎｇｌｅｔｏｎサブコン
トラクトは最初、サーバ状態を指すローカルＣ＋＋ポイ
ンタのみを使用してスプリング・オブジェクトを作成す
る。ｓｉｎｇｌｅｔｏｎが、ｎｕｃｌｅｕｓドアを作成
して対応するドアｉｄをマーシャルする経費を支払うの
は、このオブジェクトが外部送信のためにマーシャルさ
れたときだけである。

【０１３３】着呼の処理 サブコントラクトは、直接サーバ側スタブへ着呼を転送
する通信エンドポイントを作成することがある。しか
し、より一般的には、サブコントラクトは、着呼が、ま
ずサブコントラクトに到着し、次いでサブコントラクト
自体が呼出しをスタブ・レベルへ転送するようにする。

【０１３４】このため、サーバ側サブコントラクトは、
呼出しおよび応答に関する情報をピギーバックすること
によって、対応するクライアント側コードとの対話を維
持することができる。たとえば、複製をサポートするサ
ブコントラクトは、応答に関する情報をピギーバックし
て、１組の複製サーバの変更、またはクライアントにど
のサーバを使用してほしいかをクライアントに通知する
ことができる。

【０１３５】オブジェクトの取消し 現在、ある状態を指すオブジェクトを有するクライアン
トが存在する場合でも、サーバがその状態の一部を破棄
することを決定することがある。このことは、すべての
クライアントが同意するのを待たずに資源を再利用する
オペレーティング・システム・サービスでは特に重要で
ある。

【０１３６】したがって、典型的なサーバ側サブコント
ラクトは、サーバ・アプリケーションが未処理のオブジ
ェクトを取り消す方法を提供する。たとえば、ｓｉｎｇ
ｌｅｔｏｎの場合、これは、基本ｎｕｃｌｅｕｓドアを
取り消し、それによって実際上、次の着信カーネル呼出
しを妨げることによって実施される。

【０１３７】共用メモリ・サブコントラクト 共用メモリ領域によって引数を安全にかつ効率的に渡す
特殊な種類のサブコントラクトを利用することができ
る。このサブコントラクトは、クライアントとサーバが
同じ計算機上、または同じマイクロプロセッサ装置上、
または場合によってはある種のローカル・エリア・ネッ
トワーク（ＬＡＮ）中にある場合など、クライアントと
サーバが動作する特定のハードウェア構成で許容される
ときに特に適切である。このような状況では、通信バッ
ファの通常のマーシャルおよび送信のある程度のオーバ
ヘッドが、不要になり、したがって引数引渡しに共用メ
モリを使用することによって防止される。共用メモリ・
プロセスでの機密保護の維持に関係する追加オーバヘッ
ドが必要になるが、この状況では最小限のものとみなさ
れる。共用メモリ・サブコントラクトは、ｃｏｐｙ、ｃ
ｏｎｓｕｍｅ、ｎａｒｒｏｗ、ｏｂｊｅｃｔ＿ｔｙｐｅ
＿ｉｄ、ｏｂｊｅｃｔ＿ｍａｎａｇｅｒ＿ｉｄ、ｉｓ＿
ｎｕｌｌ、およびｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅの通
常のサブコントラクト・メソッドを上述の一般的な方法
で処理する。ｍａｒｓｈａｌメソッドおよびｕｎｍａｒ
ｓｈａｌメソッドは、ランダム・スタブによって呼び出
されると、上述のように動作する。ｉｎｖｏｋｅメソッ
ドは、実際には、以下でさらに詳しく説明するように、
ｃｈａｎｎｅｌオブジェクト上で必要なメソッドを呼び
出してインデックスを渡すという点で異なる。共用メモ
リ・サブコントラクトは、ｃｒｅａｔｅ＿ｃｈａｎｎｅ
ｌメソッドおよびｇｅｔ＿ｉｎｄｅｘメソッドの２つの
追加メソッドも含む。これらのメソッドについては、共
に、以下でさらに詳しく説明する。

【０１３８】次に図１１を参照すると、共用メモリ・サ
ブコントラクト２００のクライアント側に含まれるデー
タ構造の例が示されている。このデータ構造でのデータ
の使用法について、以下でさらに詳しく説明する。第１
のデータ構造２０２は、フィールド１ ２０６、フィー
ルド２ ２０８、及びフィールド３ ２１０の３つのフ
ィールドを備えている。フィールド１は、クライアント
によって呼び出される最初のオブジェクトにその最初の
オブジェクトが共用メモリ・サブコントラクトを使用す
るハンドル（ポインタ）を含めるために使用される。フ
ィールド２はフィールド１が指すオブジェクトに関係す
るインデックスを含めるために使用される。フィールド
３は第２のデータ構造２０４を指すポインタを含めるた
めに使用される。第２のデータ構造は２０４は、クライ
アントとサーバ上の１つまたは複数のオブジェクト処理
系との間の通信に使用されるサーバ上のチャネル・オブ
ジェクトを指すハンドルを含むフィールドａ ２１２と
呼ばれるフィールドを含む（図１７および以下の説明を
参照されたい）。第２のデータ構造２０４は、（クライ
アント・アドレス空間にもサーバ・アドレス空間にもマ
ップされた）メモリ・オブジェクトを指すハンドルと、
マップ済み領域のサイズと、マップ済み領域のメモリの
サブブロックを割り振り、割り振り解除するために使用
される割振りマップとを含むフィールドｂ ２１４と呼
ばれるフィールドも含む。データをマーシャルする際、
割振りマップが参照されてマーシャル・バッファが割り
振られ、データをマーシャル解除した後、マーシャル・
バッファを割り振り解除するように割振りマップが更新
される。当業者には、これらのフィールドを任意の方法
で使用してこのようなデータを含めることができ、割振
りマップが、ビット・マップ、ファースト・フィット方
式、バディ・システム、類似のマッピング方法など、メ
モリ・マップの合理的な実施態様でよいことが認識され
よう。第２のデータ構造２０４のフィールドｃ２１６
は、サーバ定義域ｉｄを含む。

【０１３９】次に図１２ないし図１６を参照して、共用
メモリ・サブコントラクトの動作について説明する。図
１２で、クライアントは、共用メモリ・サブコントラク
トを有する最初のオブジェクトＪ上でメソッドＡを呼び
出す（２５２）。クライアント呼出しは、クライアント
・スタブ２５４に渡され（２５４）、クライアント・ス
タブは共用メモリ・サブコントラクトを呼び出す。共用
メモリ・サブコントラクトは、その第１のデータ構造
（図１１中の２０２）中のフィールド２および３（図１
１中の２０８および２１０）を検査して、それらのフィ
ールドが空であるかどうかを調べる（２５６）。これら
のフィールドが空である場合（２６０）、これがこの最
初のオブジェクトに対する最初の呼出しであり、共用メ
モリ空間を確立しなければならないことが分かる。この
場合、制御は、以下で説明する図１５ないし図１６に示
す「初期設定」プロセスにシフトする。第１のデータ構
造（図１１中の２０２）中のフィールド２および３（図
１１中の２０８および２１０）が空でない場合（２５
８）、このオブジェクトが以前に呼び出されたことがあ
り、共用メモリがすでにセットアップされており、（図
１３ないし図１４に示すように）通常のマーシャルを実
行できることが分かる。

【０１４０】第１のデータ構造（図１１中の２０２）中
のフィールド２および３（図１１中の２０８および２１
０）が空であることが分かると、制御は、図１５に示し
た「初期設定」開始プロセスにシフトする（２６４）。
共用メモリ・サブコントラクトは、最初に呼び出された
オブジェクトＪのサーバ定義域ｉｄをｎｕｃｌｅｕｓか
ら取り出す（３１２）。共用メモリ・サブコントラクト
は次いで、それが有することができる１つまたは複数の
第２のデータ構造（図１１中の２０４）のフィールド３
（図１１中の２１６）中のサーバ定義域ｉｄを検査する
ことによって、識別されたサーバ定義域へのチャネルが
存在するかどうかを判定する（３１４）。チャネルが存
在しない場合（３１８）、チャネルを確立しなければな
らない。そうするために、共用メモリサブコントラクト
は、仮想メモリ・システムから新しいメモリ・オブジェ
クトを得て、クライアント・アドレス空間にマップする
（３２０）。共用メモリ・サブコントラクトは次いで、
最初のオブジェクトＪ上でｃｒｅａｔｅ＿ｃｈａｎｎｅ
ｌメソッドを呼び出す。サブコントラクトの第１のデー
タ構造のフィールド１（図１１中のフィールド２０６）
にあるオブジェクトＪのハンドルが使用され、メモリ・
オブジェクトが、最初のオブジェクトＪの処理系を含む
引数としてサーバに渡される。共用メモリ・サブコント
ラクトのサーバ側は、サーバのアドレス空間にメモリ・
オブジェクトをマップし、新しいチャネル・オブジェク
トを作成し、このチャネル・オブジェクトを呼出し側へ
返す（３２２）。この場合の呼出し側は、共用メモリ・
サブコントラクトのクライアント側であった。サブコン
トラクトのサーバ側からのこのリターンが受信される
と、コントラクトのクライアント側は、チャネル・オブ
ジェクトのハンドルをフィールドａ ２１２に入れ、メ
モリ・オブジェクトを指すハンドル（現在、クライアン
ト・アドレス空間にもサーバ・アドレス空間にもマップ
されている）、マップ済み領域のサイズ、および割振り
マップをフィールドｂ ２１４に置き、サーバ定義域の
定義域ｉｄをフィールドｃ ２１６に置いて、第２のタ
イプのデータ構造（図１１中の２０４）を作成する。サ
ブコントラクトのクライアント側は次いで、サブコント
ラクトの第１のタイプのデータ構造２０２のフィールド
３ ２１０にこの第２のタイプのデータ構造を指すポイ
ンタを入れる（図１５中のステップ３２６）。共用メモ
リ・サブコントラクトのクライアント側は次いで、チャ
ネル・オブジェクト上でｇｅｔ＿ｉｎｄｅｘメソッドを
呼び出し、第１のデータ構造２０２のフィールド１ ２
０６の最初のオブジェクトＪのハンドルを引数として渡
す（図１５のステップ３２８）。共用メモリ・サブコン
トラクトのサーバ側は、最初のオブジェクトＪ（引数と
して渡されたオブジェクト）の状態をインデックスに関
連付け、このインデックスを返す（３３０）。サブコン
トラクトのクライアント側は、サブコントラクトの第１
のデータ構造２０２のフィールド２２０８にこのインデ
ックスを入れる（図１６中のステップ３３４）。このイ
ンデックスを使用してチャネル・オブジェクトに対して
行われた呼出しは、サーバによって最初のオブジェクト
Ｊの適当な状態に方向付けられる。インデックスについ
ては、図１７に関して以下でさらに詳しく説明する。

【０１４１】図１５ないし図１６に示したこの初期設定
プロセス３１０では、サーバ定義域（３１６）へのチャ
ネルがすでに存在していることがステップ３１４で判定
された場合、ステップ３２０ないし３２４がスキップさ
れ、既存のチャネルを指すポインタが、呼出し側オブジ
ェクトの共用メモリサブコントラクトの第１のデータ構
造（図１１中の２０２）のフィールド３ ２１０に入れ
られる。その後、上述のように、図１５中のステップ３
２８で初期設定プロセスが継続する。

【０１４２】最初の呼出しを実行するプロセス（オブジ
ェクトＪ上のメソッドＡ）（図１２中の２５２）におい
て、「初期設定」プロセスについては前述のとおりであ
り、次に、最初の呼出しの処理が、図１３ないし図１４
に示したように継続する。共用メモリ・サブコントラク
トは、第２のデータ構造（図１１中の２０４）中の情報
を使用して、確立された共用メモリ領域の内部にメソッ
ドＡ用の呼出し引数をマーシャルし（２７４）、共用メ
モリ領域中のどこから引数バッファが開始するかを示す
オフセット値を記録する。共用メモリ・サブコントラク
トは、（図１１に示した第２のデータ構造２０４のフィ
ールドａ ２１２から得た）チャネル・オブジェクト上
で、呼び出すべきメソッドＡ ２７６を呼び出し、（第
１のデータ構造２０２のフィールド２ ２０８から得
た）インデックスおよびオフセット値を引数として渡
す。共用メモリ・サブコントラクト２７８のサーバ側
で、サーバは、受信されたインデックスおよびオフセッ
トが有効であるかどうかを判定する。有効でない場合
（２８０）、サーバは、図１４中の２９２でエラー・コ
ードを返し、サブコントラクトのクライアント側は、呼
出しが失敗したと判定し（２９６）、バッファを解放し
て例外を発生させ（３００）、クライアントにリターン
する（３０２）。

【０１４３】図１３中のステップ２７８で、インデック
スおよびオフセットが有効である（２８４）とサーバが
判定した場合、サーバは２８６で、インデックスを使用
して最初のオブジェクトＪの処理系および共用メモリ領
域を見つけ、オフセットを使用して共用メモリ領域中の
マーシャルされたバッファを見つける。サーバは次い
で、最初のオブジェクトＪ２８８上でメソッドＡを呼び
出し、オブジェクト処理系の結果を共用メモリ領域２８
８の同じバッファにマーシャルし、クライアント側サブ
コントラクト２９０にリターンする。呼出しが成功した
場合（２９８）、サブコントラクトのクライアント側
は、結果をマーシャル解除し、呼出し側クライアントへ
リターンできるようにクライアント・スタブに結果を渡
し、次の呼出しで再使用すべきバッファを開放する（３
０２）。制御はクライアントに返される（３０４）。

【０１４４】チャネル・オブジェクトと最初のオブジェ
クトの関係のサーバ側処理系３５０をさらに示すため
に、次に図１７を参照する。チャネル・オブジェクト処
理系状態３５２は、それぞれ、関係する最初のオブジェ
クトｉ３６０の処理系を指すインデックスｉ３５８およ
びポインタを含む、１つまたは複数の最初のオブジェク
ト・レコード３５６、３６４、３７２に連係リスト３５
４によって接続される。たとえば、レコード３５６は、
関係する最初のオブジェクトｉ３６０の処理系を指すイ
ンデックスｉ３５８およびポインタを含む。当業者に
は、たとえばハッシュ・テーブルを使用することなど、
連係リスト以外のレコードのデータ構造の実施態様とし
て様々なデータ構造が可能であることが認識されよう。

【０１４５】インデックス自体について、さらに説明す
る。好ましい実施の態様では、インデックスおよびチャ
ネル・オブジェクトが与えられた場合、クライアントか
ら呼出しを行った最初のオブジェクトのハンドルを算出
できるように、インデックスは、クライアントから呼出
しを行った最初のオブジェクトのハンドルおよびチャネ
ル・オブジェクトの関数として共用メモリ・サブコント
ラクトのサーバ側によって作成される。サーバは最初、
安全なチャネル・オブジェクトからこのインデックスを
算出する。したがって、インデックスは固有にかつ安全
に、特定の最初のオブジェクトを識別する。したがっ
て、共用メモリ・サブコントラクトのサーバ側が、イン
デックスおよびチャネル・オブジェクトを引数として含
む呼出しを受信したとき、このサーバは、クライアント
の呼出しを行った最初のオブジェクトのハンドルを逆算
し、このインデックスが、サーバが最初に導いたインデ
ックスであることを検証する。したがって、未知のオブ
ジェクトまたはクライアント側サブコントラクトが、他
の何らかの定義域から得たインデックスまたはチャネル
・オブジェクトでメソッドを呼び出そうとした場合、サ
ーバは、最初のオブジェクトの正しいハンドルを導くこ
とができず、エラー・インディケータを返す。

【０１４６】好ましい実施の態様では、「組合せ」サブ
コントラクトによって、共用メモリ・サブコントラクト
の属性とＳｉｎｇｌｅｔｏｎサブコントラクトの属性を
組み合わせて、所与の最初のオブジェクトからの最初の
呼出し時に、組合せサブコントラクトが、サブコントラ
クトのサーバ側が分散システムまたはネットワーク・シ
ステム中のリモート・サーバ上にあるかどうかを判定
し、そうである場合、Ｓｉｎｇｌｅｔｏｎサブコントラ
クト・メソッドを使用し、サーバ側が同じ計算機上また
は適当に隣接するプロセッサ上にある場合は、共用メモ
リ・サブコントラクト・メソッドを使用することを提案
する。当業者には、これらのサブコントラクト機構の他
の様々な組合せが可能であることが認識されよう。

【０１４７】サブコントラクトの例 以下に、いくつかの例示的なサブコントラクトの概要を
示す。当業者には、本発明を実施するうえでこれらのタ
イプのうちの特定の１つのタイプが必要とされるわけで
はなく、他の多数のタイプのサブコントラクトが構想で
きることを理解されたい。要するに、これらのサブコン
トラクトの主要な特徴の簡単な概要を提示し、エラー条
件および特殊ケースの説明を省略する。

【０１４８】すべての場合に、クライアント・アプリケ
ーション・コードが、オブジェクトを引数として渡す簡
単なスプリング・オブジェクト呼出ししか実行しないこ
とに留意されたい。サブコントラクトでは、説明したす
べての機構が隠される。

【０１４９】クラスタ・サブコントラクト ｓｉｎｇｌｅｔｏｎサブコントラクトは、個別のスプリ
ング・オブジェクトとしてさらすことができるサーバ状
態の各部分ごとに異なるカーネル・ドアを使用する。カ
ーネルがドア識別子に対してｃａｐａｂｉｌｉｔｙ ｌ
ｉｋｅ気密保護モデルを課すので、これは、異なる方法
で保護されるシステム資源へのアクセスを与えるために
使用されるオブジェクトに対して適切な処理系である。

【０１５０】しかし、いくつかのサーバは、多数のオブ
ジェクトをエクスポートし、クライアントは、あるオブ
ジェクトへのアクセスを与えられた場合、すべてのオブ
ジェクトへのアクセスも得ることができる。この場合、
クライアントは、単一のドアを介して１組のオブジェク
トにアクセスできるようにシステム・オーバヘッドを低
減させることができる。

【０１５１】クラスタ・サブコントラクトは、この概念
をサポートする。各クラスタ・オブジェクトは、ドア・
オブジェクトと整数タグの組合せによって表される。ク
ラスタｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ動作とクラスタ
呼出し動作は協働して、ドア上で定義域間呼出しを実行
する際にサーバにタグを渡す。同様に、マーシャル・メ
ソッドおよびマーシャル解除メソッドは、ドア識別子と
整数タグを共に送受信する。

【０１５２】キャッシング・サブコントラクト サーバがそのクライアントとは異なる計算機上にあると
き、クライアント計算機上でキャッシングを実行すると
有用であることが多い。したがって、キャッシュ可能な
オブジェクトを計算機間で送信するとき、受信側マシン
が、受信したオブジェクトをローカル・キャッシュ・マ
ネージャに登録し、そのキャッシュを介してオブジェク
トにアクセスすることが望ましい。

【０１５３】キャッシング・サブコントラクトは、この
機能を提供する。キャッシング・オブジェクトの表現
は、サーバを指すドア識別子ＤＩ１と、ローカル・キャ
ッシュを指すドア識別子ＤＩ２とを含む。

【０１５４】キャッシング・オブジェクトを計算機間で
送信するとき、ＤＩ１ドア識別子のみを送信する。キャ
ッシング・マーシャル解除コードは、ローカル・キャッ
シュ・マネージャにＤＩ１ドア識別子を提供し、新しい
ＤＩ２を受信する。このサブコントラクトは、呼出し動
作を実行するときは常に、ＤＩ２ドア識別子を使用す
る。したがって、キャッシュ可能なオブジェクトに対す
るすべての呼出しは、ローカル計算機上のキャッシュ・
マネージャに方向付けられる。この種のコントラクトの
使用法は、本出願と同じ日に出願され、引用によって本
明細書に合体された、関連出願第 号「Ａ Ｍｅｔｈ
ｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ ａ Ｃａ
ｃｈｉｎｇ Ｆｉｌｅ Ｓｅｒｖｅｒ」に詳しく記載さ
れている。

【０１５５】回復可能なサブコントラクト ある種のサーバは、安定な記憶域にサーバ自体の状態を
維持する。クライアントは、そのようなサーバに状態が
維持されたオブジェクトを有する場合、オブジェクトが
サーバ・クラッシュから自動的に回復できるようにする
ことを望む。サーバがクラッシュすると通常のスプリン
グドア識別子は無効になり、したがってクライアントが
サーバに再接続できるようにする何らかの新しい機構を
追加する必要がある。通常のドア識別子はｃａｐａｂｉ
ｌｉｔｙ ｌｉｋｅ特性を有するので、サーバ状態の所
与の部分を使用する資格があることをサーバに通知する
何らかの方法を有することも望ましい。

【０１５６】回復可能なサブコントラクトは、通常のド
ア識別子と、回復マネージャの名前と、暗号で署名され
た証明書とから成る表現を使用する。サーバは、回復可
能なオブジェクトを渡すとき、このオブジェクトが資格
を有するアクセスを記述する証明書を作成し、従来型の
暗号署名を使用してこの証明書に署名する。

【０１５７】通常、回復可能な呼出しコードは、簡単な
ドア呼出しをドア識別子上で実行するに過ぎない。しか
し、これが失敗した場合、このサブコントラクトはその
代わりに、回復マネージャを呼び出し、サブコントラク
ト自体の証明書を提示して、サーバが回復したときに通
知することを要求する。サーバは、リブートすると、回
復マネージャと連絡を取り、証明書を使用してアクセス
を有効化し、クライアントが動作を再開できるように新
しいドア識別子をクライアントに与える。

【０１５８】ｒｅｐｌｉｃｏｎサブコントラクト ｒｅｐｌｉｃｏｎサブコントラクトは、複製されたサー
ビスを扱う極めて簡単なサブコントラクトである。

【０１５９】ｒｅｐｌｉｃｏｎオブジェクトの状態は、
ドア識別子のベクトルから成る。ｒｅｐｌｉｃｏｎオブ
ジェクトは、呼出しを実行する際、１つの呼出しが成功
するまで、各ドア識別子上で順に定義域呼出しを発行し
ようとする。

【０１６０】ｒｅｐｌｉｃｏｎサブコントラクトに容易
に追加できる多数の追加機能がある。たとえば、ドア識
別子のベクトルだけでなく、現サーバ構成の構成タグを
追跡することもできる。サーバ呼出しが実行されるとき
はいつでも、この構成タグを送信することができる。サ
ーバは、（サーバがリブートしたため、あるいはロード
の平衡のために）構成を変更したい場合、ドア識別子の
新しいベクトルおよび構成ｉｄを結果バッファ上にピギ
ーバックすることができる。

【０１６１】サブコントラクトの反射 サブコントラクトが有効である１つの理由は、サブコン
トラクトでは、オブジェクトを実施する動作がオブジェ
クト機構を実施する動作から分離されることである。サ
ブコントラクト・インプリメンタは、あらゆるオブジェ
クト・インプリメンタがオブジェクト処理系機構の詳細
を知ることを必要とせずに一連の異なるオブジェクト方
式のうちの１つを選択できるようにする１組の有用なサ
ブコントラクトを提供する。

【０１６２】サブコントラクトが提供する１組の動作
は、分散環境内の制御を得るための適切なキーのような
ものである。設計上、リモート・オブジェクトに対して
とられるすべてのキー処置は、オブジェクトのサブコン
トラクトを何らかの方法で使用する。

【０１６３】実際、サブコントラクトは、基本システム
によって提供しなければならない機能を低減させること
に成功した。基本システム中の新しい機構の必要なし
で、いくつかの新しく興味深いサブコントラクトを実施
した。

【０１６４】互換性のあるサブコントラクト機構とサブ
コントラクトの動的リンクとは、既存のオペレーティン
グ・システムを変更せずに、新しいサブコントラクトを
導入して古いＳＰＲＩＮＧシステム上で利用できること
を意味する。

【０１６５】

【実施例】好ましい実施例では、当業者は、以下のイン
タフェース定義コード・リストを参照することによっ
て、本明細書で説明したサブコントラクト機構をよりよ
く理解することができる。 ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／説明を明確にするために、以下のコード化例では、エラー処理コードを省略 してある。実際は、説明した多数のメソッドは、エラー条件があるかどうかを検 査する追加コードを有し、エラーに出会った場合は適当な例外を発生させる。 ｔｙｐｅｄｅｆ ｉｎｔ ｂｏｏｌ； ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔクラスは、リモート計算機 との間でメッセージを送受信するために使用できる通信エンドポイントを記述す る。ここでは、以下の例を示すために部分的な記述のみを提示する。 ｃｌａｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ｛ ／／様々なプライベート・データ・フィールド ｐｕｂｌｉｃ： ／／既存の通信エンドポイントをコピーするコンストラクタ ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ（ｃｏｍｍｕｎｉｃａｔｉｏ ｎ＿ｅｎｄｐｏｉｎｔ＊ｏｌｄ＿ｅｎｄｐｏｉｎｔ）； ／／メッセージをターゲットへ送信して応答メッセージを得るメソッド ｃｌａｓｓ ｍｅｓｓａｇｅ＊ｓｅｎｄ＿ｍｅｓｓａｇｅ＿ａｎｄ＿ｇｅｔ＿ ｒｅｐｌｙ（ｍｅｓｓａｇｅ＊ｍ）； ／／他の様々なメソッド ｝： ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／「メッセージ」クラスは、メッセージ・バッファを記述し、メッセージ・バ ッファとの間でメッセージの読取りおよび書込みを行うメソッドを提供する。こ こでは、以下のサブコントラクト例を示すのに十分な部分的な記述のみを提示す る。 ｃｌａｓｓ ｍｅｓｓａｇｅ｛ ／／様々なプライベート・データ・フィールド ｐｕｂｌｉｃ： ｉｎｔ ｇｅｔ＿ｉｎｔ（）； ／／整数を読み取る。 ｖｏｉｄ ｐｕｔ＿ｉｎｔ（ｉｎｔ ｘ）；／／整数を書き込む。 ｉｎｔ ｐｅｅｋ＿ｉｎｔ（）；／／次の整数を見る。 ／／ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔをメッセージから読み取 る。 ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ＊ｇｅｔ＿ｃｏｍｍｕｎｉｃ ａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ（）； ／／ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔをメッセージに書き込む 。 ｖｏｉｄ ｐｕｔ＿ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ（ｃｏｍ ｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ＊ｘ）； ／／他の様々なメソッド ｝： ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／クラス「サブコントラクト」は、各サブコントラクトがサポートしなければ ならないメソッドを定義するＣ＋＋仮想基本クラスである。 ｃｌａｓｓ ｓｕｂｃｏｎｔｒａｃｔ｛ ｐｕｂｌｉｃ： ｖｉｒｔｕａｌ ｖｏｉｄ ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ（ｍｅｓｓａｇ ｅ＊ｍ，ｉｎｔ ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ）＝０； ｖｉｒｔｕａｌ ｍｅｓｓａｇｅ＊ｉｎｖｏｋｅ（ｍｅｓｓａｇｅ＊ｍ， ｉ ｎｔ ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ）＝０； ｖｉｒｔｕａｌ ｖｏｉｄ ｃｏｎｓｕｍｅ（）＝０； ｖｉｒｔｕａｌ ｓｕｂｃｏｎｔｒａｃｔ＊ｃｏｐｙ（）＝０； ｖｉｒｔｕａｌ ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ｍｅｓｓａｇ ｅ＊ｍ）＝０； ｖｉｒｔｕａｌ ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍｅｓｓａｇｅ＊ｍ ）＝０； ｝： ／／このｔｙｐｅｄｅｆは、標準マーシャル解除静的メソッドのタイプを記述す るものである。 ｔｙｐｅｄｅｆ ｓｕｂｃｏｎｔｒａｃｔ＊（＊ｓｕｂｃｏｎｔｒａｃｔ＿ｕｎ ｍａｒｓｈａｌ＿ｍｅｔｈｏｄ）（ｍｅｓｓａｇｅ＊）； ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙは、現プログラムに知られてい るすべてのサブコントラクトを追跡する。 ／／「ｒｅｇｉｓｔｅｒ＿ｓｕｂｃｏｎｔｒａｃｔ」メソッドは、新しいサブコ ントラクトをレジストリに追加するために使用することができる。 ／／「マーシャル解除」メソッドは、誰かが未知のサブコントラクトをメッセー ジからマーシャル解除したいときに使用することができる。 ｃｌａｓｓ ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙ｛ ｐｕｂｌｉｃ： ｓｔａｔｉｃ ｖｏｉｄ ｒｅｇｉｓｔｅｒ＿ｓｕｂｃｏｎｔｒａｃｔ（ｉｎ ｔｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ，ｓｕｂｃｏｎｔｒａｃｔ＿ｕｎ ｍａｒｓｈａｌ＿ｍｅｔｈｏｄ ｍ）； ｓｔａｔｉｃ ｓｕｂｃｏｎｔｒａｃｔ＊ｕｎｍａｒｓｈａｌ（ｍｅｓｓａｇ ｅ＊ｍ）； ｝； ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／クラスｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔは、簡単なサブコントラクト 例である。ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔは、「サブコントラクト」ク ラスによって定義されたインタフェースから継承し、「サブコントラクト」に指 定された様々な仮想メソッド定義を満たすメソッド定義を提供する。ｓｉｍｐｌ ｅ＿ｓｕｂｃｏｎｔｒａｃｔは、サブコントラクト・オブジェクトをメッセージ から読み取るために使用できる「マーシャル解除」メソッドも提供する。 ｃｌａｓｓ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：ｐｕｂｌｉｃ ｓｕｂｃ ｏｎｔｒａｃｔ｛ ／／Ｃ＋＋プライベート・データは、リモート・オブジェクトの「表現」と呼 ばれるものを構成する。 ／／このサブコントラクトは、単一のｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐ ｏｉｎｔしか使用しない。 ／／他のサブコントラクトは複数のエンドポイントを使用することができる。 ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ＊ｐｏｒｔ； ｐｕｂｌｉｃ： ｃｏｎｓｔ ｉｎｔ ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ＝ ０ｘ５５５５０００４； ｖｏｉｄ ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ（ｍｅｓｓａｇｅ＊ｍ， ｉｎｔ ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ）； ｍｅｓｓａｇｅ＊ｉｎｖｏｋｅ（ｍｅｓｓａｇｅ＊ｍ，ｉｎｔ ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ）； ｖｏｉｄ ｃｏｎｓｕｍｅ（）； ｓｕｂｃｏｎｔｒａｃｔ＊ｃｏｐｙ（）； ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ｍｅｓｓａｇｅ＊ｍ）； ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍｅｓｓａｇｅ＊ｍ）； ｓｔａｔｉｃ ｓｕｂｃｏｎｔｒａｃｔ＊ｕｎｍａｒｓｈａｌ（ｍｅｓｓａｇ ｅ＊ｍ）； ｝； ／／プログラム始動の一部として、ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔをｓ ｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙに登録するグローバル・イニシャライ ザを定義する。 ｓｔａｔｉｃ ｉｎｔ ｒｅｇｉｓｔｅｒ＿ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ（） ｛ ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙ：：ｒｅｇｉｓｔｅｒ＿ｓｕｂｃ ｏｎｔｒａｃｔ（ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｓｕｂｃｏｎｔｒａｃｔ＿ ｉｄ， ＆ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｕｎｍａｒｓｈａｌ）； ｒｅｔｕｒｎ（１）； ｝ ｉｎｔ ｆｏｒｃｅ＿ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒ ａｔｉｏｎ＝ｒｅｇｉｓｔｅｒ＿ｓｉｍｐｌｅ＿ｓｕｂｃｏ ｎｔｒａｃｔ（）； ／／ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔによるｉｎｖｏｋｅ＿ｐｒｅａｍｂ ｌｅメソッドの使用は非常に限られたものであり、このメソッドではメソッド番 号がメッセージ中に置かれるに過ぎない。 ｖｏｉｄ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ（ ｍｅｓｓａｇｅ＊ｍ，ｉｎｔ ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ） ｛ ｍ−＞ｐｕｔ＿ｉｎｔ（ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ）； ｝ ／／ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔは、低レベル・コードを呼び出し、 実際にメッセージを送信して応答を得ることによって、呼出しを実施する。 ｍｅｓｓａｇｅ＊ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｉｎｖｏｋｅ（ｍｅｓｓａｇｅ＊ ｍ，ｉｎｔ ｍｅｔｈｏｄ＿ｎｕｍｂｅｒ） ｛ ／／これは、最も簡単な種類の呼出しである。他の種類のサブコントラクトは 、複数の通信エンドポイントなどを呼び出す必要があることがある。 ｍｅｓｓａｇｅ＊ｒｅｐｌｙ； ｒｅｐｌｙ＝ｐｏｒｔ−＞ｓｅｎｄ＿ｍｅｓｓａｇｅ＿ａｎｄ＿ｇｅｔ＿ｒｅ ｐｌｙ（ｍ）； ｒｅｔｕｒｎ（ｒｅｐｌｙ）； ｝ ／／ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ ｃｏｎｓｕｍｅメソッドは、現サ ブコントラクトに関連するすべての状態を検出する。 ｖｏｉｄ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｃｏｎｓｕｍｅ（） ｛ ｄｅｌｅｔｅ ｐｏｒｔ； ｄｅｌｅｔｅ ｔｈｉｓ； ｝ ／／ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ ｃｏｐｙメソッドは、現サブコン トラクト・オブジェクトのコピーである新しいサブコントラクト・オブジェクト を作成する。 ｓｕｂｃｏｎｔｒａｃｔ＊ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｃｏｐｙ（） ｛ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ＊ｒｅｓｕｌｔ＝ｎｅｗ ｓｉｍｐｌ ｅ＿ｓｕｂｃｏｎｔｒａｃｔ（）； ／／通信エンドポイントのコピーを作成する。 ｒｅｓｕｌｔ−＞ｐｏｒｔ＝ｎｅｗ ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐ ｏｉｎｔ（ｐｏｒｔ）； ｒｅｔｕｒｎ（ｒｅｓｕｌｔ）； ｝ ／／ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ メソッドは、サブコントラクト・オブジェクトをマーシャルし、次いで削除する 。 ｖｏｉｄ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ ｍｅｓｓａｇｅ＊ｍ） ｛ ／／まずサブコントラクト識別子をマーシャルする。 ｍ−＞ｐｕｔ＿ｉｎｔ（ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ）； ／／次に自分のｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔをマーシャル する。 ｍ−＞ｐｕｔ＿ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ（ｐｏｒｔ） ； ／／次に自分自身を削除する。 ｃｏｎｓｕｍｅ（）； ｝ ／／ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ ｍａｒｓｈａｌ＿ｃｏｐｙメソッ ドは、「ｃｏｐｙ」の効果と「ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ」の効果を組み 合わせる。これは容易である。「ｃｏｐｙ」オブジェクトを作成して削除するこ とを不要にすることができ、その代わりに単に現オブジェクトの状態をマーシャ ルすることができる。 ｖｏｉｄ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍｅｓ ｓａｇｅ＊ｍ） ｛ ／／まず自分のサブコントラクト識別子をマーシャルする。 ｍ−＞ｐｕｔ＿ｉｎｔ（ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ） ／／次に自分のｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔをマーシャル する。 ｍ−＞ｐｕｔ＿ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ｅｎｄｐｏｉｎｔ（ｐｏｒｔ） ； ｝ ／／「ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｕｎｍａｒｓｈａｌ」静的メ ソッドは、メッセージ中の次のものが実際に、「ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔ ｒａｃｔ」を使用するオブジェクトであるかどうかを調べる検査を行う。 ／／そうである場合、このメソッドは新しいｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａ ｃｔを作成し、必要な情報をメッセージから読みとってｓｉｍｐｌｅ＿ｓｕｂｃ ｏｎｔｒａｃｔを初期設定する。 ／／メッセージ中の次のものがｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔオブジェ クトでない場合、ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙを呼び出し、それ が実際にはどのサブコントラクトであるかを調べてマーシャル解除を完了する。 ｓｕｂｃｏｎｔｒａｃｔ＊ ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｕｎｍａｒｓｈａｌ（ｍｅｓｓａｇ ｅ＊ｍ） ｛ ／／メッセージ中の次の値を見る。 ｉｎｔ ｎｅｘｔ＿ｖａｌｕｅ＝ｍ−＞ｐｅｅｋ＿ｉｎｔ（）； ｉｆ（ｎｅｘｔ＿ｖａｌｕｅ＝＝ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ）｛ ／／このメッセージは、ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔオブジェク トを含んでおり、したがってそれを読み取る。 ｉｎｔ ｄｉｓｃａｒｄ＿ｖａｌｕｅ＝ｍ−＞ｇｅｔ＿ｉｎｔ（）； ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ＊ｒｅｓｕｌｔ＝ｎｅｗ ｓｉｍｐ ｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ（）； ｒｅｓｕｌｔ−＞ｐｏｒｔ＝ｍ−＞ｇｅｔ＿ｃｏｍｍｕｎｉｃａｔｉｏｎ＿ ｅｎｄｐｏｉｎｔ（）； ｒｅｔｕｒｎ（ｒｅｓｕｌｔ）； ｝ｅｌｓｅ｛ ｒｅｔｕｒｎ（ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙ：：ｕｎｍａｒ ｓｈａｌ（ｍ））； ｝ ｝ ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ｖｏｉｄ ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙ：：ｒｅｇｉｓｔｅｒ＿ｓｕｂｃｏ ｎｔｒａｃｔ（ｉｎｔ ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ， ｓｕｂｃｏｎｔｒａｃｔ＿ｕｎｍａｒｓｈａｌ＿ｍｅｔｈｏ ｄ ｍ） ｛ ／／このコードは、所与のサブコントラクトｉｄおよびマーシャル解除メソッ ドを、知られているサブコントラクトのテーブルに追加する。 ／／．．． ｝ ｓｕｂｃｏｎｔｒａｃｔ＊ ｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙ：：ｕｎｍａｒｓｈａｌ（ｍｅｓｓ ａｇｅ＊ｍ） ｛ ｉｎｔ ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ＝ｍ−＞ｐｅｅｋ＿ｉｎｔ（）； ／／このコードは、サブコントラクトのテーブルで新しいｓｕｂｃｏｎｔｒａｃ ｔ＿ｉｄを探そうとする。 ｓｕｂｃｏｎｔｒａｃｔ＿ｕｎｍａｒｓｈａｌ＿ｍｅｔｈｏｄ＊ｓｕｍ＝ｔａｂ ｌｅ＿ｌｏｏｋｕｐ（ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ）； ｉｆ（ｓｕｍ＝＝０）｛ ／／所与のｓｕｂｃｏｎｔｒａｃｔ＿ｉｄが分からない。 ／／適当な動的ライブラリを見つけてそれをアドレス空間に追加してみる。一 例として、サブコントラクトＩＤからサブコントラクト・ライブラリへの非常 に簡単なマッピングを使用する。 ｃｈａｒ ｌｉｂｒａｒｙ＿ｎａｍｅ［１００］； ｓｐｒｉｎｔｆ（ｌｉｂｒａｒｙ＿ｎａｍｅ，”／ｕｓｒ／ｌｉｂ／ｓｕｂｃ ｏｎｔｒａｃｔ／％ｄ．ｓｏ”，ｓｕｂｃｏｎｔｒａｃｔ ＿ｉｄ）； ｌｏａｄ＿ｄｙｎａｍｉｃ＿ｌｉｂｒａｒｙ（ｌｉｂｒａｒｙ＿ｎａｍｅ）； ／／動的ライブラリをロードする動作によって、ライブラリの初期設定関数が 呼び出され、それによって初期設定関数は、それがサポートするサブコントラ クト上でｓｕｂｃｏｎｔｒａｃｔ＿ｒｅｇｉｓｔｒｙ：：ｒｅｇｉｓｔｅｒ＿ ｓｕｂｃｏｎｔｒａｃｔを呼び出す。 ／／したがって、サブコントラクトｉｄが分かったかどうかをもう一度調べる 。 ｓｕｍ＝ｔａｂｌｅ＿ｌｏｏｋｕｐ（ｓｕｂｃｏｎｔｒａｃｔ＿ｉｄ）； ｉｆ（ｓｕｍ＝＝０）｛ ／／失敗した。 ／／ここで例外を発生させるべきである。 ｝ｅｌｓｅ｛ ／／次に、サブコントラクトｉｄが分かり、次いで、マーシャル解除を行う ことができる。 ｝ ｝ ／／所与のサブコントラクト・メソッドを使用してオブジェクトをマーシャル 解除する。このメソッドはたとえば、ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ ：：ｕｎｍａｒｓｈａｌメソッドでよい。あるいは、他のサブコントラクト用 の類似のマーシャル解除メソッドでもよい。 ｓｕｂｃｏｎｔｒａｃｔ＊ｒｅｓｕｌｔ＝（＊ｓｕｍ）（ｍ）； ｒｅｔｕｒｎ（ｒｅｓｕｌｔ）； ｝ ／／−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ／／次に、ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔを使用するオブジェクトの簡 単な例を与える。 ／／クラス「ｗｏｍｂａｔ」は、インタフェース定義言語では、「ｇｉｖｅ＿ｂ ｉｒｔｈ」と「ｍｅｅｔ」の２つのメソッドを有するものとして定義されている 。「ｇｉｖｅ＿ｂｉｒｔｈ」は新しいｗｏｍｂａｔを作成する。「ｍｅｅｔ」は 他のｗｏｍｂａｔを引数として取り出す。 ／／ ／／ ｉｎｔｅｒｆａｃｅ ｗｏｍｂａｔ｛ ／／ ｗｏｍｂａｔ ｇｉｖｅ＿ｂｉｒｔｈ（）； ／／ ｖｏｉｄ ｍｅｅｔ（ｃｏｐｙ ｗｏｍｂａｔ ｗ，ｃｏｐｙ ｉｎｔ ａｇｅ）； ／／ ｝； ／／ ／／また、ｗｏｍｂａｔの省略時サブコントラクトがｓｉｍｐｌｅ＿ｓｕｂｃｏ ｎｔｒａｃｔであることをスタブ・ジェネレータに指定する。 ／／ ／／このインタフェース定義は、以下のクラス「ｗｏｍｂａｔ」および「ｒｅｍ ｏｔｅ＿ｗｏｍｂａｔ」用のＣ＋＋クライアント・スタブに変換される。 ｃｌａｓｓ ｗｏｍｂａｔ｛ ／／これは、「ｗｏｍｂａｔ」インタフェース用の仮想基本クラスである。ｗ ｏｍｂａｔのリモート処理系にもｗｏｍｂａｔのローカル処理系にも適した様 々な種類の具体的なｗｏｍｂａｔクラスをこのインタフェースから導くことが できる。現議論では、以下の「ｒｅｍｏｔｅ＿ｗｏｍｂａｔ」のみについて考 える。 ｐｕｂｌｉｃ： ｖｉｒｔｕａｌｗｏｍｂａｔ＊ｇｉｖｅ＿ｂｉｒｔｈ（）＝０； ｖｉｒｔｕａｌ ｖｏｉｄ ｍｅｅｔ（ｗｏｍｂａｔ＊ｗ，ｉｎｔ ａｇｅ） ＝０； ／／ｗｏｍｂａｔｓのマーシャルおよびマーシャル解除のサポート ｖｉｒｔｕａｌ ｖｏｉｄ ｃｏｎｓｕｍｅ（）＝０； ｖｉｒｔｕａｌ ｗｏｍｂａｔ＊ｃｏｐｙ（）＝０； ｖｉｒｔｕａｌ ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ｍｅｓｓａｇ ｅ＊ｍ）＝０； ｖｉｒｔｕａｌ ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍｅｓｓａｇｅ＊ｍ ）＝０； ｝； ｃｌａｓｓ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：ｐｕｂｌｉｃ ｗｏｍｂａｔ｛ ／／ｒｅｍｏｔｅ＿ｗｏｍｂａｔクラスはサブコントラクトに基づくものであ る。 ／／クラス・メソッドのすべての作業は、サブコントラクトｓｃによって提供 されるサポート上に作成される。 ｐｒｉｖａｔｅ： ｓｕｂｃｏｎｔｒａｃｔ＊ｓｃ； ｒｅｍｏｔｅ＿ｗｏｍｂａｔ（ｓｕｂｃｏｎｔｒａｃｔ＊ｓｃｌ）； ｐｕｂｌｉｃ： ｗｏｍｂａｔ＊ｇｉｖｅ＿ｂｉｒｔｈ（）； ｖｏｉｄ ｍｅｅｔ（ｗｏｍｂａｔ＊ｗ，ｉｎｔ ａｇｅ）； ／／ｗｏｍｂａｔｓのマーシャルおよびマーシャル解除のサポート ｓｔａｔｉｃ ｗｏｍｂａｔ＊ｕｎｍａｒｓｈａｌ（ｍｅｓｓａｇｅ＊ｍ）； ｖｏｉｄ ｃｏｎｓｕｍｅ（）； ｗｏｍｂａｔ＊ｃｏｐｙ（）； ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ｍｅｓｓａｇｅ＊ｍ）； ｖｏｉｄ ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍｅｓｓａｇｅ＊ｍ）； ｝； ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｒｅｍｏｔｅ＿ｗｏｍｂａｔ（ｓｕｂｃｏｎｔ ｒａｃｔ＊ｓｃｌ） ｛ ｓｃ＝ｓｃｌ； ｝ ｗｏｍｂａｔ＊ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｕｎｍａｒｓｈａｌ（ｍｅｓｓａｇｅ＊ｍ） ｛ ／／省略時サブコントラクトはｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔである が、ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：：ｕｎｍａｒｓｈａｌ動作は、 他の種類のサブコントラクト・オブジェクトを返すことを選択することができ る。 ｓｕｂｃｏｎｔｒａｃｔ＊ｓｃ＝ｓｉｍｐｌｅ＿ｓｕｂｃｏｎｔｒａｃｔ：： ｕｎｍａｒｓｈａｌ（ｍ）； ｒｅｔｕｒｎ（ｎｅｗ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ（ｓｃ））； ｝ ｖｏｉｄ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｃｏｎｓｕｍｅ（） ｛ ｓｃ−＞ｃｏｎｓｕｍｅ（）； ｝ ｗｏｍｂａｔ＊ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｃｏｐｙ（） ｛ ｓｕｂｃｏｎｔｒａｃｔ＊ｓｃ２＝ｓｃ−．ｃｏｐｙ（）； ｒｅｔｕｒｎ（ｎｅｗ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ（ｓｃ２））； ｝ ｖｏｉｄ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ｍｅｓｓａ ｇｅ＊ｍ） ｛ ｓｃ−＞ｍａｒｓｈａｌ＿ｃｏｎｓｕｍｅ（ｍ）； ｝ ｖｏｉｄ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍｅｓｓａｇｅ＊ ｍ） ｛ ｓｃ−＞ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍ）； ｝ ｗｏｍｂａｔ＊ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｇｉｖｅ＿ｂｉｒｔｈ（） ｛ ／／実際の「ｒｅｍｏｔｅ＿ｗｏｍｂａｔ」サーバを呼び出して新しいｒｅｍ ｏｔｅ＿ｗｏｍｂａｔを作成する。「ｇｉｖｅ＿ｂｉｒｔｈ」メソッド用のメ ソッド識別子として「７」を割り振った。 ／／発呼用のメッセージを作成する。 ｍｅｓｓａｇｅ＊ｍ＝ｎｅｗ ｍｅｓｓａｇｅ（）； ／／サブコントラクトにプリアンブルをセットアップさせる。 ｓｃ−＞ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ（ｍ，７）； ／／マーシャルすべき引数はない。 ／／リモート・サーバを呼び出すようサブコントラクトに命令する。 ／／応答データを含む新しいメッセージが返される。 ｍ＝ｓｃ−＞ｉｎｖｏｋｅ（ｍ，７）； ／／結果をマーシャル解除する。これはリモート呼出しであり、したがってｒ ｅｍｏｔｅ＿ｗｏｍｂａｔ ｕｎｍａｒｓｈａｌメソッドを使用する。 ｗｏｍｂａｔ＊ｒｅｓｕｌｔ＝ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｕｎｍａｒｓ ｈａｌ（ｍ）； ／／終了である。応答メッセージを削除してリターンする。 ｄｅｌｅｔｅ ｍ； ｒｅｔｕｒｎ（ｒｅｓｕｌｔ）； ｝ ｖｏｉｄ ｒｅｍｏｔｅ＿ｗｏｍｂａｔ：：ｍｅｅｔ（ｗｏｍｂａｔ＊ｗ，ｉｎｔ ａｇｅ ） ｛ ／／実際の「ｒｅｍｏｔｅ＿ｗｏｍｂａｔ」サーバを呼び出して「ｍｅｅｔ」 メソッドを実施する。「ｍｅｅｔ」メソッド用のメソッド識別子として「８」 を割り振った。 ／／発呼用のメッセージを作成する。 ｍｅｓｓａｇｅ＊ｍ＝ｎｅｗ ｍｅｓｓａｇｅ（）； ／／サブコントラクトにプリアンブルをセットアップさせる。 ｓｃ−ｉｎｖｏｋｅ＿ｐｒｅａｍｂｌｅ（ｍ，８）； ／／引数ｗｏｍｂａｔ”ｗ”のコピーをマーシャルする。 ｗ−＞ｍａｒｓｈａｌ＿ｃｏｐｙ（ｍ）； ／／ａｇｅ引数をマーシャルする。 ｍ−＞ｐｕｔ＿ｉｎｔ（ａｇｅ）； ／／リモート・サーバを呼び出すようサブコントラクトに命令する。 ／／応答データを含む新しいメッセージが返される。 ｍ＝ｓｃ−＞ｉｎｖｏｋｅ（ｍ，８）； ／／結果はない。 ／／終了である。応答メッセージを削除してリターンする。 ｄｅｌｅｔｅ ｍ； ｝ ／／したがって、Ｃ＋＋ｗｏｍｂａｔオブジェクトを得たクライアントはオブジ ェクトに対する動作を実行することができ、サブコントラクトがｗｏｍｂａｔご とに異なるものであっても、正しいスタブおよびサブコントラクトが呼び出され る。 ｍａｉｎ（） ｛ ／／プログラムは次に、名前サーバなどあるソースから最初のｗｏｍｂａｔを 得る。 ｗｏｍｂａｔ＊ｍｏｔｈｅｒ＝ｎａｍｅ＿ｓｅｒｖｉｃｅ＿ｌｏｏｋｕｐ＜ｗ ｏｍｂａｔ＞（”ｓｕｓｉｅ”）； ／／次にｗｏｍｂａｔ動作を実行することができる。 ｗｏｍｂａｔ＊ｃｈｉｌｄ＝ｍｏｔｈｅｒ−＞ｇｉｖｅ＿ｂｉｒｔｈ（）； ｍｏｔｈｅｒ−＞ｍｅｅｔ（ｃｈｉｌｄ，０）； ｝ 特定のオペレーティング・システム環境での好ましい実
施例に関して本発明を説明したが、当業者には、添付の
特許請求の範囲の趣旨および範囲内で、他の異なるオペ
レーティング・システムで、修正を加えたうえで本発明
を実施できることが認識されよう。

【図面の簡単な説明】

【図１】 従来技術でのクライアント・アプリケーショ
ンおよびサーバ・アプリケーションのスタブおよびネッ
トワーク・ソフトウェアとの関係を示す図である。

【図２】 ＳＰＲＩＮＧオペレーティング・システムの
主要なシステム構成要素を示す図である。

【図３】 スタブ・オブジェクトとサブコントラクト・
オブジェクトとサーバ・アプリケーション・オブジェク
トの関係を示す図である。

【図４】 サブコントラクトを使用するリモート・オブ
ジェクト呼出しを示す図である。

【図５】 サブコントラクトを使用する単一の計算機上
でのオブジェクト呼出しを示す図である。

【図６】 本発明のサブコントラクト方法の典型的な使
用法のフロー・チャートを示す図である。

【図７】 本発明のサブコントラクト方法の典型的な使
用法のフロー・チャートを示す図である。

【図８】 本発明のサブコントラクト方法の典型的な使
用法のフロー・チャートを示す図である。

【図９】 本発明のサブコントラクト方法の典型的な使
用法のフロー・チャートを示す図である。

【図１０】 ＳＰＲＩＮＧのオブジェクトのビューと従
来技術のオブジェクトのビューである。

【図１１】 共用メモリ・サブコントラクト中の典型的
なデータ構造を示す図である。

【図１２】 共用メモリ・サブコントラクト上での呼出
しを処理する典型的な方法のフロー・チャートを示す図
である。

【図１３】 共用メモリ・サブコントラクト上での呼出
しを処理する典型的な方法のフロー・チャートを示す図
である。

【図１４】 共用メモリ・サブコントラクト上での呼出
しを処理する典型的な方法のフロー・チャートを示す図
である。

【図１５】 共用メモリ・サブコントラクト上での呼出
しを処理する典型的な方法のフロー・チャートを示す図
である。

【図１６】 共用メモリ・サブコントラクト上での呼出
しを処理する典型的な方法のフロー・チャートを示す図
である。

【図１７】 チャネル・オブジェクトが、それを使用す
る異なるオブジェクト用の複数のデータ構造に関係す
る、共用メモリ・サブコントラクトのサーバ側の典型的
なデータ構造を示す図である。

【符号の説明】

５０ スプリング・カーネル ５２ 定義域マネージャ ５４ 仮想メモリ・マネージャ ５６ 名前サーバ ５８ キャッシング・ファイル・サーバ ６０ ローカル・ファイル・サーバ ６２ リンカ ６４ ネットワーク・プロキシ ６６ ｔｔｙサーバ ６８ ＵＮＩＸプロセス・サーバ ６９ サブコントラクト・レジストリ ７０ スプリング・アプリケーション

───────────────────────────────────────────────────── フロントページの続き (72)発明者 グラハム・ハミルトン アメリカ合衆国 94303 カリフォルニア 州・パロ アルト・デビッド コート・ 3143 (72)発明者 パナギオティス・エス・クーギオリス アメリカ合衆国 94040 カリフォルニア 州・マウンテンビュー・デイル アヴェニ ュ・ナンバー132・1200

Claims (9)

【特許請求の範囲】
1. 【請求項１】 共用メモリ空間を使用する、コンピュー
   タによって実施される方法において、 クライアント・アプリケーションによって行われ、かつ
   他のオブジェクトなど複雑な引数である引数を要求する
   動作呼出しを、共用メモリ・サブコントラクトを有する
   最初のオブジェクト上で実行するステップと、 前記共用メモリ・サブコントラクトのクライアント側部
   分によって前記動作呼出しを認識するステップと、 前記最初のオブジェクトを実行する前記共用メモリ・サ
   ブコントラクトの前記クライアント側部分が使用できる
   共用メモリ領域が存在しているかどうかを、非カーネル
   ・ルーチンによって判定するステップと、 前記共用メモリ領域が存在する場合、前記共用メモリ・
   サブコントラクトの前記クライアント側部分によって、
   前記確立された共用メモリ領域の内側に前記動作呼出し
   の引数をマーシャルするステップと、 前記共用メモリ・サブコントラクトの前記クライアント
   側部分によって既存のチャネル・オブジェクト上で前記
   動作呼出しを呼び出すステップと、 前記最初のオブジェクトの前記処理系を含む前記サーバ
   によって、前記呼び出された動作呼出しを受信するステ
   ップとを含むことを特徴とする方法。
2. 【請求項２】 前記最初のオブジェクトの前記処理系を
   含む前記サーバ上に位置する前記共用メモリ・サブコン
   トラクトのサーバ側部分によって、前記呼び出された動
   作呼出しを受信するステップと、 前記共用メモリ・サブコントラクトの前記サーバ側部分
   が、非カーネル・プロセスを使用して、前記最初のオブ
   ジェクトの前記処理系を見つけ、前記共用メモリ領域中
   の前記呼び出された動作呼出しの前記引数を含むバッフ
   ァを見つけるステップと、 前記バッファから前記引数をマーシャル解除するステッ
   プと、 前記呼び出された動作呼出しおよび前記マーシャル解除
   された引数を前記最初のオブジェクトの前記処理系に渡
   すステップの追加ステップとを含むことを特徴とする請
   求項１に記載のコンピュータによって実施される方法。
3. 【請求項３】 前記共用メモリ・サブコントラクトの前
   記サーバ側部分によって、前記最初のオブジェクトの前
   記処理系から前記呼び出された動作呼出しの結果を受信
   するステップと、 最初に、前記呼び出された動作呼出しの引数を含んでい
   た、前記共用メモリ領域中の前記バッファに前記結果を
   マーシャルするステップと、 前記共用メモリ・サブコントラクトの前記サーバ側部分
   が、前記共用メモリ・サブコントラクトの前記クライア
   ント側部分へリターン・メッセージを送信するステップ
   の追加ステップを含むことを特徴とする請求項２に記載
   のコンピュータによって実施される方法。
4. 【請求項４】 前記共用メモリ・サブコントラクトの前
   記クライアント側部分によって前記リターン・メッセー
   ジを受信するステップと、 前記共用メモリ領域中の前記バッファから前記結果をマ
   ーシャル解除するステップと、 前記動作呼出しを行った前記クライアント・アプリケー
   ションに前記結果を渡し、それによって、前記共用メモ
   リ・サブコントラクトの前記クライアント側部分と前記
   サーバ側部分が共用するメモリ領域を使用して、前記最
   初のオブジェクト上の前記クライアント・アプリケーシ
   ョンの動作呼出しが実行されるステップの追加ステップ
   を含むことを特徴とする請求項３に記載のコンピュータ
   によって実施される方法。
5. 【請求項５】 前記共用メモリ領域が存在しない場合に
   共用メモリ領域を確立する追加ステップを含むことを特
   徴とする請求項１に記載のコンピュータによって実施さ
   れる方法。
6. 【請求項６】 共用メモリ空間を使用する、コンピュー
   タによって実施される方法において、 他のオブジェクトなど複雑な引数である引数を要求する
   動作呼出しを最初のオブジェクト上で実行するステップ
   と、 前記共用メモリ・サブコントラクトのクライアント側部
   分によって前記動作呼出しを認識するステップと、 前記最初のオブジェクトを実行する前記共用メモリ・サ
   ブコントラクトの前記クライアント側部分が使用できる
   共用メモリ領域が存在しているかどうかを、非カーネル
   ・ルーチンによって判定するステップと、 前記共用メモリ領域が存在する場合、前記共用メモリ・
   サブコントラクトの前記クライアント側部分によって、
   前記確立された共用メモリ領域の内側に前記動作呼出し
   の引数をマーシャルするステップと、 前記最初のオブジェクトの処理系を含むサーバへ前記動
   作呼出しを送信するステップと、 前記共用メモリ・サブコントラクトのサーバ側部分によ
   って、非カーネル・プロセスを使用して前記動作呼出し
   の前記引数を前記共用メモリ領域からマーシャル解除す
   るステップと、 前記動作呼出しおよび前記マーシャル解除された引数を
   前記最初のオブジェクトの前記処理系に渡すステップ
   と、 最初に、前記動作呼出しの前記引数を含んでいた、前記
   共用メモリ領域中の前記バッファに、前記最初のオブジ
   ェクトの前記処理系から得た前記動作呼出しの結果をマ
   ーシャルするステップと、 前記メモリ・サブコントラクトの前記サーバ側部分が、
   前記マーシャルされた結果を含むリターン・メッセージ
   を、前記動作呼出しを発行した前記クライアントへ送信
   するステップと、 前記共用メモリ領域中の前記バッファから前記結果をマ
   ーシャル解除するステップと、 前記動作呼出しを行った前記クライアント・アプリケー
   ションに前記結果を渡すステップとを含み、それによっ
   て、前記クライアントと前記サーバが共用するメモリ領
   域を使用し、かつ非カーネル・プロセスを使用して、前
   記最初のオブジェクト上の前記クライアント・アプリケ
   ーションの動作呼出しが実行されることを特徴とする方
   法。
7. 【請求項７】 共用メモリ空間を使用する、コンピュー
   タによって実施される方法において、 データ構造を備える他のオブジェクトなど複雑な引数で
   ある引数を要求する、クライアント・アプリケーション
   による動作呼出しを最初のオブジェクト上で実行するス
   テップと、 前記動作呼出しの引数をマーシャルするために使用でき
   る共用メモリ領域が存在しているかどうかを非カーネル
   ・ルーチンによって判定するステップと、 前記共用メモリ領域が存在する場合、前記既存の共用メ
   モリ領域の内側に前記動作呼出しの前記引数をマーシャ
   ルするステップと、 前記最初のオブジェクトの処理系を含むサーバへ前記動
   作呼出しを送信するステップと、 前記サーバが、非カーネル・プロセスを使用して前記動
   作呼出しの前記引数を前記共用メモリ領域からマーシャ
   ル解除するステップと、 前記動作呼出しおよび前記マーシャル解除された引数を
   前記最初のオブジェクトの前記処理系に渡すステップ
   と、 最初に、前記動作呼出しの前記引数を含んでいた前記共
   用メモリ領域に、前記最初のオブジェクトの前記処理系
   から得た前記動作呼出しの結果をマーシャルするステッ
   プと、 前記サーバが、前記マーシャルされた結果を含むリター
   ン・メッセージを、前記動作呼出しを発行した前記クラ
   イアントへ送信するステップと、 前記共用メモリ領域から前記結果をマーシャル解除する
   ステップと、 前記動作呼出しを行った前記クライアント・アプリケー
   ションに前記結果を渡すステップとを含み、それによっ
   て、前記クライアントと前記サーバが共用するメモリ領
   域を使用し、かつ非カーネル・プロセスを使用して、前
   記最初のオブジェクト上の前記クライアント・アプリケ
   ーションの動作呼出しが実行されることを特徴とする方
   法。
8. 【請求項８】 共用メモリ空間を使用する、コンピュー
   タによって実施される方法において、 データ構造を備える他のオブジェクトなど複雑な引数で
   ある引数を要求する、クライアント・アプリケーション
   による動作呼出しをデータ構造を備えるターゲット・オ
   ブジェクト上で実行するステップと、 前記動作呼出しの前記引数を共用メモリ領域にマーシャ
   ルするステップと、 前記最初のオブジェクトの処理系を含むサーバへ前記動
   作呼出しを送信するステップと、 前記サーバが、非カーネル・プロセスを使用して前記動
   作呼出しの前記引数を前記共用メモリ領域からマーシャ
   ル解除し、前記動作呼出しおよび前記マーシャル解除さ
   れた引数を前記ターゲット・オブジェクトの前記処理系
   に渡すステップと、 前記サーバが、前記ターゲット・オブジェクトの前記処
   理系から得た前記動作呼出しの結果を前記共用メモリ領
   域にマーシャルし、前記マーシャルされた結果を含むリ
   ターン・メッセージを、前記動作呼出しを発行した前記
   クライアントへ送信するステップと、 前記クライアントが、前記共用メモリ領域から前記結果
   をマーシャル解除するステップと、 前記動作呼出しを行った前記クライアント・アプリケー
   ションに前記結果を渡すステップとを含み、それによっ
   て、前記クライアントと前記サーバが共用するメモリ領
   域を使用し、かつ非カーネル・プロセスを使用して、前
   記最初のオブジェクト上の前記クライアント・アプリケ
   ーションの動作呼出しが実行されることを特徴とする方
   法。
9. 【請求項９】 データ処理システムにおいて、 相互接続された１つまたは複数の中央演算処理装置（Ｃ
   ＰＵ）と、 相互接続された１つまたは複数の中央演算処理装置上で
   動作するオペレーティング・システム・カーネルと、 データ構造を備える他のオブジェクトなど複雑な引数で
   ある引数を要求する動作呼出しを、データ構造を備える
   ターゲット・オブジェクト上で実行することができる、
   前記オペレーティング・システム・カーネルの下で動作
   するクライアント・アプリケーションと、 前記動作呼出しの前記引数を共用メモリ領域にマーシャ
   ルすることによって前記ターゲット・オブジェクト上で
   前記動作呼出しを実行することができ、前記ターゲット
   ・オブジェクトの処理系を含む非カーネル・サーバへ前
   記動作呼出しを送信することができ、サーバが前記動作
   呼出しの前記引数を前記共用メモリ領域からマーシャル
   解除し、前記動作呼出しおよび前記マーシャル解除され
   た引数を前記ターゲット・オブジェクトの処理系に渡す
   ことができ、さらに、前記サーバが、前記ターゲット・
   オブジェクトの前記処理系から受信された前記動作呼出
   しの結果を前記共用メモリ領域にマーシャルし、前記マ
   ーシャルされた結果を含むリターン・メッセージを、前
   記動作呼出しを発行した前記クライアントへ送信するよ
   うに動作する、非カーネル・クライアント側サブシステ
   ムとを備え、 それによって、前記クライアント側サブシステムと前記
   サーバが共用するメモリ領域を使用し、かつ非カーネル
   ・プロセスを使用して、前記最初のオブジェクト上の前
   記クライアント・アプリケーションの動作呼出しを、デ
   ータ処理システムによって実行することができることを
   特徴とするデータ処理システム。