JPH0793264A - クライアント側スタブインタプリタ - Google Patents

Abstract

(57)【要約】 【目的】 分散型システムでクライアント側スタブが要
求するメモリスペースを最小にする。 【構成】 本発明は、クライアントアプリケーションに
よるオブジェクトの呼出しを実行し且つクライアントア
プリケーションと、オブジェクトインプリメンテーショ
ンとの間で引数を渡すメカニズムを形成し、クライアン
トアプリケーション又はオペレーティングシステムはそ
れらのメカニズムがどのように動作するかの詳細を知る
ことなく、クライアント側スタブ用として要求されるメ
モリスペースを縮小するような手際よく、簡潔な方法を
提供する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は分散形計算システム、ク
ライアントサーバ計算及びオブジェクト指向プログラミ
ングの分野に関する。特定すれば、本発明は、クライア
ント側スタブにより要求されるメモリスペースを最小限
に抑えるように設計され且つクライアント側スタブジェ
ネレータ及びクライアント側スタブインタプリタと呼ば
れる論理モジュールを具備する方法及び装置である。

【０００２】

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

【０００３】システムの異なるコンポーネントの間のイ
ンタフェースを定義するためにオブジェクトメタファを
使用するシステムについてこの基本的な問題を解決する
方法の一部として、スタブや、他の同様の種類の中間論
理モジュールが使用されてきた。そのようなスタブは、
呼出しのパラメータとして別のオブジェクトを送信して
いることもある遠隔コンピュータの間でのオブジェクト
呼出しの通信を処理するための標準モジュールとして記
述される。それらのスタブ及び他の類似するモジュール
と、その相互関係については、以下に、スタブジェネレ
ータとスタブインタプリタを含む本発明の詳細な説明の
文脈の中でさらに詳細に説明する。

【０００４】オブジェクト指向システムでは、オブジェ
クトは、データと、そのデータを操作するために呼出す
ことができる動作とから成るコンポーネントである。動
作はオブジェクトにおいて、オブジェクトへ呼出しを送
信することによって呼出される。各オブジェクトはオブ
ジェクト型を有する。オブジェクト型はその型のオブジ
ェクトで実行できる動作を定義する。オブジェクト動作
はオブジェクト自体とは無関係に実現される。加えて、
１つのオブジェクト型は他のオブジェクト型に関して定
義され且つ実現されるオブジェクト動作を継承している
こともある。オブジェクト指向デザインとプログラミン
グ技法の詳細については、Ｂｅｒｔｒａｎｄ Ｍｅｙｅ
ｒの「Ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａ
ｒｅ Ｃｏｎｓｔｒｕｃｔｉｏｎ」（Ｐｒｅｎｔｉｃｅ
−Ｈａｌｌ，１９８８年）を参照。

【０００５】クライアント−サーバ計算においては、典
型的には、コンピュータを接続するネットワークを介し
て互いに通信できる１組のコンピュータがある。それら
のコンピュータの一部は、他のコンピュータにサービス
又は機能性を提供する働きをする。そのようなサービス
又は機能の提供者は「サーバ」として知られており、そ
のようなサービス又は機能性を消費する側を「クライア
ント」と呼ぶ。クライアント−サーバモデルは、同じコ
ンピュータでランしている別個のプログラムが何らかの
保護メカニズムを介して互いに通信しており且つ機能性
の提供者並びに消費者として活動しているようなケース
にも一般化される。

【０００６】クライアント−サーバモデルに基づくオブ
ジェクト指向分散形システムには、オブジェクト指向イ
ンタフェースをクライアントに提供するサーバが存在す
る。それらのサーバはデータと、関連ソフトウェアとか
ら構成されるオブジェクトを支援する。クライアントは
それらのオブジェクトに対するアクセスを獲得し且つそ
れらのオブジェクトに対して呼出しを実行する。それら
の呼出しはクライアントからサーバへ伝送される。サー
バでは、それらの呼出しをオブジェクトと関連するソフ
トウェアを介して実行する。次に、それらの呼出しの結
果をクライアントに伝送して戻す。

【０００７】さらに最近のシステムにおいては、アプリ
ケーションソフトウェアはネットワークと直接には通信
しない。その代わりに、アプリケーションソフトウェア
は「スタブ」（図１の１４）と通信する。スタブは、ク
ライアントとサーバとの間にネットワークが存在してい
るか否かにかかわらず、一貫したインタフェースを形成
する。システムにより支援される個別のインタフェース
ごとに、別々のスタブが存在する。スタブコードは、ア
プリケーションレベルソフトウェアが見る特定言語レベ
ルインタフェースと、ネットワークソフトウェアが提供
する標準低レベル通信インタフェースとの間で変換を実
行する必要がある。たとえば、スタブは遠隔呼出しに対
する引数を取上げ、それらの引数をネットワークソフト
ウェアがネットワークを介して伝送するのに適するメッ
セージに導入する必要がある。そのようなスタブの利用
法は、Ｄｏｎａｌｄ Ｅ．Ｍｅｒｕｓｉの著書「Ｓｏｆ
ｔｗａｒｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ Ｔｅｃｈ
ｎｉｑｕｅ」の３４９〜３６８ページのＲｅｍｏｔｅ
Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌｓ（「ＲＰＣ」）につい
ての章（Ｄｉｇｉｔａｌ Ｐｒｅｓｓ，１９９２年，Ｉ
ＳＢＮ１−５５５５８−０９０−４）の中に記載されて
いる。

【０００８】そのようなオブジェクト指向分散形システ
ムで生成されるクライアント側スタブの数の関係上、そ
れらの数多くのクライアント側スタブに関連するコード
が占めるテキストメモリスペースを縮小するためのメカ
ニズムが必要であることが明らかになっている。

【０００９】

【発明が解決しようとする課題】従って、本発明は、分
散形システムで最も重要であるオブジェクト呼出し及び
引数渡しの基本メカニズムの制御を実行するためのスタ
ブの設計を保持しつつ、クライアント側スタブが要求す
るメモリスペースを最小限に抑えるように設計されてお
り且つアプリケーションプログラマに特定のオブジェク
トのために使用されている特定スタブを知らせないよう
にしても差しつかえないようにする、クライアント側ス
タブジェネレータ、圧縮クライアント側スタブ実行コー
ドのデータベース及びクライアント側スタブインタプリ
タと呼ばれる論理モジュールを具備する装置及び方法を
提供することを課題内とする。

【００１０】

【課題を解決するための手段】本発明は、クライアント
アプリケーションによるオブジェクトの呼出しを実行し
且つクライアントアプリケーションと、オブジェクトイ
ンプリメンテーションとの間で引数を渡すメカニズムを
形成し、クライアントアプリケーション又はオペレーテ
ィングシステムはそれらのメカニズムがどのように動作
するかの詳細を知ることなく、クライアント側スタブ用
として要求されるメモリスペースを縮小するような手際
よく、簡潔な方法を提供する。さらに、それらのメカニ
ズムは、クライアントアプリケーションが１つのコンピ
ュータノードにあり、オブジェクトインプリメンテーシ
ョンは別のコンピュータノードにあるような分散形コン
ピュータ環境でも同様の容易さと効率をもって機能す
る。

【００１１】コンピュータシステム中のクライアントに
より呼出される特定のスタブ動作を、複数の異なるスタ
ブ方法に共通するコードとして識別され、そのスタブ動
作を実行するために要求されるコードの第１の部分をコ
ンピュータメモリの第１の領域からアクセスし、且つ呼
出される特定のスタブ動作について独自のものであるコ
ードの第２の部分をコンピュータメモリの第２の部分か
らアクセスすることによって実行する方法及び装置を説
明する。複数のスタブ方法に共通するコードは一度しか
記憶されないので、これにより、要求されるコンピュー
タメモリを縮小できる。

【００１２】さらに、スタブ動作を実行するために生成
されるコードを複数のスタブ方法に共通するコードの第
１の部分と、各スタブ動作について独自のものであるコ
ードの第２の部分とに分割すると共に、様々な方法、テ
キスト及びパラメータのバイトコード表現を使用して、
このコードの第２の部分を圧縮形式でコンピュータメモ
リに記憶するプロセスを提供する方法及び装置を示す。
複数のスタブ方法に共通するコードの部分はスタブイン
タプリタと呼ばれるメカニズムの中に含まれており、こ
のスタブインタプリタは、クライアントによりスタブ動
作が呼出されるたびに、共通コードのこの部分を供給す
る。スタブインタプリタは、スタブ方法が呼出されるた
びに、そのスタブ方法を完了するために要求されるスタ
ブコードの独自の部分を獲得するために、メモリをアク
セスする。

【００１３】このメモリスペースを縮小するために使用
されるメカニズムは、コンピュータメモリに記憶される
圧縮クライアント側スタブ記述ファイルから成るデータ
ベースを生成するスタブジェネレータ（「ＣＯＮＴＯＣ
Ｃ」と呼ばれる）と、それらのクライアント側スタブ記
述ファイルをいかにして読取るべきかについての知識を
もつスタブインタプリタとを具備する。ＣＯＮＴＯＣＣ
はインタフェース定義言語（「ＩＤＬ」）ファイルを読
取り、対応するＣ＋＋ファイルを生成する。ＣＯＮＴＯ
ＣＣはＩＤＬデータを読取り、圧縮解除Ｃ＋＋スタブフ
ァイルか、バイト符号化形態に含まれている特定のスタ
ブ方法について独自のものであるデータのみを含む特殊
圧縮クライアント側スタブインタプリタファイルのいず
れかを生成する能力を有する。

【００１４】スタブインタプリタ論理モジュールはター
ゲットオブジェクトと、呼出された特定のスタブ方法に
関連する引数と、コンピュータメモリに記憶されている
圧縮クライアント側スタブ記述ファイルのデータベース
の中のスタブコードの圧縮バイトコード表現に対するポ
インタとを受信し、必要に応じてオブジェクト呼出し、
戻りメッセージのマーシャル化又はアンマーシャル化を
実行するように進行する。本発明のシステムの目的、特
徴及び利点は以下の説明から明白になるであろう。

【００１５】〔表記法及び用語〕以下の詳細な説明はコ
ンピュータ又は複数のコンピュータから成るネットワー
クで実行されるプログラム手続きによって提示される。
そのような手続きによる手続きや表現は、当業者がその
作業の内容を他の当業者に最も有効に伝達するために使
用する手段である。

【００１６】ここでは、また、一般的にも、手続きはあ
る所望の結果に至るステップの首尾一貫したシーケンス
である。それらのステップは物理的量の物理的操作を要
求するステップである。通常、それらの量は記憶、転
送、組合せ、比較及びその他の操作が可能である電気信
号又は磁気信号の形態をとる。時によっては、主として
一般に使用されている用語であるという理由により、そ
れらの信号をビット、値、要素、信号、文字、項、数な
どと呼ぶと好都合であることがわかる。しかしながら、
それらの用語及びそれに類する用語は、全て、適切な物
理的量と関連させるべきものであり、単にそれらの量に
便宜上付されたラベルであるにすぎないということに注
意すべきである。

【００１７】さらに、実行される操作を、一般にはオペ
レータが実行する知的動作と関連する加算又は比較など
の用語で呼ぶことが多い。ここで説明する、本発明の一
部を成す動作のいずれをとっても、オペレータのそのよ
うな能力は不要であるか、又は多くの場合に望ましくな
い。動作は機械動作である。本発明の動作を実行するの
に有用な機械には、汎用デジタルコンピュータ又はそれ
に類する装置がある。

【００１８】本発明は、それらの動作を実行するための
装置にも関する。この装置は要求される目的に合わせて
特別に構成されても良く、あるいは、汎用コンピュータ
に記憶させたコンピュータプログラムによってコンピュ
ータを選択的に起動又は再構成しても良い。ここで提示
する手続きは、本来、特定のコンピュータ又は他の特定
の装置に関連するものではない。様々な汎用機械をここ
で示す教示に従って書込んだプログラムと共に使用して
も良く、あるいは、要求される方法ステップを実行する
ためには、より特殊化した装置を構成するほうが好都合
であると判明するかもしれない。それらの様々な機械に
ついて要求される構造は以下の説明から明白になるであ
ろう。

【００１９】

【実施例】以下の開示は、オブジェクト指向、クライア
ントサーバ、分散形計算演算から成る計算環境における
スタブ演算を実行するコンピュータコードが占める総メ
モリスペースを縮小する独特の革新的な方法及び装置を
説明する。

【００２０】そこで図２を参照すると、本発明が示され
ている。本発明は、入力としてインタフェース定義言語
（「ＩＤＬ」）コード１５０を受信し、必要に応じてク
ライアント側スタブ用の圧縮コード及びテーブルから成
るデータベース１５６を生成するか、又は必要に応じて
正規のＣ＋＋スタブコード１５４を生成するクライアン
ト側スタブジェネレータ（「ＣＯＮＴＯＣＣ」）１５２
と、マーシャル化、アンマーシャル化及びオブジェクト
呼出しといったクライアント側スタブ機能を実行できる
ランタイムクライアント側スタブインタプリタ１５８と
を含む。呼出されつつある方法に対するターゲットオブ
ジェクトと引数１６８を渡し且つコンピュータメモリ１
７０に記憶されている正規スタブコードを介してその方
法を実行する正規スタブ方法呼出し１６２が指示されて
いる。また、スタブインタプリタ１５８と共に使用され
る型のスタブ方法呼出し１６４も示されており、これも
呼出されつつある方法に対するターゲットオブジェクト
と引数を渡すのであるが、それに加えて、コンピュータ
メモリ１７２の圧縮スタブコード１６６に対するポイン
タを渡し、それにより、スタブインタプリタ１５８はそ
の方法呼出しを実行することができる。以下、本発明の
好ましい実施例を実現する動作環境を簡単に説明した後
に、本発明のそれらのコンポーネントについてさらに詳
細に説明する。

【００２１】以下の説明中、本発明を完全に理解させる
ために、説明の便宜上、特定のデータや構成を挙げる。
ここで説明する好ましい実施例は、方法テーブルと、サ
ブコントラクトメカニズムと、「サブコントラクトの」
局所専用状態を表わすデータ構造とを含む「spring obj
ect」 と呼ばれる新しい型のオブジェクトを含む計算環
境において実現され、ここに挙げたものは全てＳｕｎ
Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．（「Ｓｕｎ」）の
ＳＰＲＩＮＧ Ｏｂｊｅｃｔ Ｏｒｉｅｎｔｅｄ Ｏｐ
ｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（「ＳＰＲＩＮＧ」）の
制御の下に動作している。クライアント側スタブインタ
プリタとその基礎を成すプロセスをここで説明する特定
の詳細がなくとも実施しうると共に、様々なコンピュー
タシステムや、密結合プロセッサの様々な構成、形態又
はモデル、あるいは、疎結合多重プロセッサシステムの
様々な構成において実現しうることは当業者には認めら
れるであろう。

【００２２】ＳＰＲＩＮＧオブジェクトは、状態を含
み、その状態を操作するための１組の方法を提供する抽
象である。オブジェクトとその方法の記述は、インタフ
ェース定義言語（「ＩＤＬ」）で指定されるインタフェ
ースである。インタフェースはインプリメンタ（サー
バ）と、オブジェクトのクライアントとの間の強く型付
けされたコントラクトである。

【００２３】ＳＰＲＩＮＧドメインは、スレッド群を伴
なうアドレススペースである。１つのドメインが与えら
れたとき、そのドメインはいくつかのオブジェクトのサ
ーバとして活動し、別のオブジェクトのクライアントと
して活動することもある。インプリメンタとクライアン
トは同一のドメインにあっても良く、異なるドメインに
あっても良い。

【００２４】ＳＰＲＩＮＧはオブジェクト指向であるの
で、インタフェース継承の概念を支援する。ＳＰＲＩＮ
Ｇは単一インタフェース継承と、多重インタフェース継
承双方の概念を支援する。「ｆｏｏ」型のオブジェクト
を受入れるインタフェースは、［ｆｏｏ」のサブクラス
の事例をも受入れる。たとえば、address＿spaceオブジ
ェクトはmemory＿objectを取出し、それをアドレススペ
ースにマッピングする方法を有する。同じ方法は、memo
ry＿objectインタフェースから継承するオブジェクトで
ある限り、fileオブジェクトや frame＿bufferオブジェ
クトをも受入れる。

【００２５】ＳＰＲＩＮＧカーネルは基本クロスドメイ
ン呼出し及びスレッド、低レベル機械依存処理、並びに
メモリマッピング及び物理メモリ管理のための基本仮想
メモリ支援を支援する。ＳＰＲＩＮＧカーネルは他のＳ
ＰＲＩＮＧカーネルに関する知識をもたず、遠隔呼出し
は全てネットワークプロクシサーバによって処理され
る。加えて、仮想メモリシステムは外部ページャに依存
して、記憶とネットワークのコヒーレンシーを処理す
る。

【００２６】各々のオブジェクトと関連してサブコント
ラクトメカニズムがある。各サブコントラクトはクライ
アント側部分と、関連するサーバ側部分とを有する。各
オブジェクト型は関連するサブコントラクトを有する。
サブコントラクトのクライアント側部分は新たなspring
オブジェクトを生成し、springオブジェクトを削除し、
関連オブジェクトに関する情報を通信バッファにマーシ
ャル化し、関連オブジェクトを表わす通信バッファ中の
データをアンマーシャル化し、オブジェクトを１つの記
憶場所から別の記憶場所へ伝送すること又はオブジェク
トのコピーを１つの記憶場所から別の記憶場所に伝送す
ることを含めて、通信バッファを関連するサーバ側サブ
コントラクトへ伝送する能力を有する。サブコントラク
トメカニズムのサーバ側部分はspringオブジェクトを生
成し、入力呼出し及び関連通信バッファを処理するため
の支援を実行し、オブジェクトを無効にするための支援
を実行する能力を有する。

【００２７】springオブジェクトモデル ＳＰＲＩＮＧは他の分散形オブジェクト指向システムと
はわずかに異なる方式でオブジェクトを見ているので、
スタブインタプリタ、スタブ及びサブコントラクトの詳
細を論ずるのに先立って、このことを明確にしておく必
要がある。

【００２８】大半の分散形システムは、オブジェクトが
サーバ機械に常駐し、クライアント機械はサーバにある
オブジェクトを指示する「オブジェクトハンドル」を所
有するようなモデルを提示する（図１０ａを参照）。そ
のため、クライアントはオブジェクトではなく、オブジ
ェクトハンドルを渡してゆく。

【００２９】ＳＰＲＩＮＧは、オブジェクトハンドルで
はなく、オブジェクトに対して直接にクライアントが動
作しているようなモデルを提供する（図１０ｂを参
照）。それらのオブジェクトのいくつかはいずれかの遠
隔場所でその関心状態を全て保持することもあるので、
それらのオブジェクトの局所状態は単にこの遠隔状態に
対するハンドルから構成されるのみである。１つのオブ
ジェクトは一度に１つの場所で存在することしかできな
いので、オブジェクトを誰か別の人へ伝送する場合に
は、伝送者自身はそのオブジェクトに関わるのを止め
る。ところが、伝送する前にオブジェクトをコピーする
ことも可能であり、これは同一の遠隔場所を指示する２
つの別個のオブジェクトが存在するように実現されるで
あろう。

【００３０】このように、多くのシステムでは、何らか
の遠隔オブジェクトを参照するオブジェクトハンドルを
有するいくつかのクライアントについて述べることにな
るであろうが、ＳＰＲＩＮＧにおいては、いくつかのク
ライアントが同じ遠隔場所を参照するオブジェクトを有
するということになるであろう。

【００３１】多くのサーバ利用オブジェクトに対して、
この相違は主に用語の違いである。しかしながら、ＳＰ
ＲＩＮＧはサーバをベースとしないオブジェクト、すな
わち、オブジェクトの状態がクライアントとサーバとの
間で分割されているような状況をも支援する。このよう
な場合、クライアントを単にポインタを所有するのでは
なく、真のオブジェクトを所有するものとみなすことが
はるかに好都合である。

【００３２】インタフェース定義言語 ＳＰＲＩＮＧの単一化原理は、重要な全てのインタフェ
ースが標準インタフェース定義言語で定義されるという
ことである。この言語はオブジェクト指向であり、多重
継承の支援を含む。これは真にインタフェースの特性に
関するものであって、インプリメンテーション情報を提
供しない。インタフェース定義言語から、特定言語向け
スタブを生成することが可能である。それらのスタブ
は、ＳＰＲＩＮＧインタフェースに対する特定言語向け
マッピングを実行する。たとえば、主なインプリメンテ
ーション言語であるＣ＋＋では、Ｃ＋＋オブジェクトに
よってspringオブジェクトを表現する。スタブオブジェ
クトについての方法を呼出すと、現在アドレススペース
の中で局所呼出しを実行するか、又はその呼出しを異な
る機械にあっても良い別のアドレススペースへ送り出
す。

【００３３】スタブ及びサブコントラクトメカニズム 次に図４を参照して説明すると、本発明の環境において
は、機械１０のクライアントアプリケーション１２は適
切なクライアント側スタブ１４に対して呼出しを発行
し、そのクライアント側スタブは「サブコントラクト」
３０のクライアント側部分を呼出し、そのサブコントラ
クトは、一般には別の機械１８にある相手方のネットワ
ークソフトウェア２０と通信するネットワークソフトウ
ェア１６に作用する。サーバ側ネットワークソフトウェ
ア２０は入力メッセージをサブコントラクトのサーバ側
部分へ転送し、そこで、サブコントラクトはそのデータ
をサーバ側スタブ２２に供給し、サーバ側スタブは典型
的にはオブジェクトインプリメンテーションであるサー
バアプリケーション２４にデータを渡す。指示した通
り、サブコントラクトはスタブとネットワークソフトウ
ェアとの間にはめ込まれている。スタブはサブコントラ
クトを使用して遠隔呼出しを実行し、次に、同様にして
サブコントラクトはネットワークソフトウェアを使用し
て、実際の呼出しを実行する。異なるサブコントラクト
は標準通信ソフトウェアの上に異なる種類の遠隔通信プ
ロトコル（複製用、キャッシング用など）を実現する。

【００３４】単一のコンピュータの中で、異なるアプリ
ケーションがサブコントラクトを使用して通信すること
もある。そこで図５を参照すると、クライアントアプリ
ケーション１２はアプリケーションスペース３８の中に
あり、適切なクライアント側スタブ１４に対して呼出し
を発行し、そこで、スタブは適切なサブコントラクト３
０を呼出す。サブコントラクト３０はその通信をオペレ
ーティングシステム３６へ転送し、オペレーティングシ
ステムはその通信をサーバ側サブコントラクト３２へ中
継し、そこで、サーバ側サブコントラクトはデータをサ
ーバ側スタブ２２に与え、スタブはデータをサーバアプ
リケーション２４に渡す。この場合、オペレーティング
システム３６が提供するプロセス間通信プリミティブは
ネットワーキングソフトウェアが提供する機械間通信メ
カニズムと置換えられる（図４の１６及び２０）。

【００３５】単一のアドレススペースでランする単一の
アプリケーションの中であっても、クライアント側とサ
ーバ側のスタブとサブコントラクトがアプリケーション
の異なるコンポーネントの間で通信するために使用され
ることもある。

【００３６】次に、図３を参照して、オブジェクト指向
という面から物を見てみると、クライアントアプリケー
ション１は「スタブオブジェクト」２によって動作す
る。それらのスタブオブジェクト２は、各々、１つのサ
ブコントラクトオブジェクト３を含み、このサブコント
ラクトオブジェクトの内部状態４（その「表現」として
知られている）は基礎にある実状態５に対する何らかの
形態のポイント６を含んでいても良い。実状態５は同じ
アドレススペースにあっても良く、同じ機械の別のアド
レススペース又は全く別の機械にあっても良い。典型的
には、基礎状態自体がサーバアプリケーションのアドレ
ススペースではオブジェクト５として表現される。

【００３７】クライアントはspringオブジェクトを３つ
のものから構成されるものと理解する。その３つとはオ
ブジェクトの型定義により示唆される動作ごとに１つの
エントリを含む方法テーブルと、次の章で説明する基本
サブコントラクト動作を指定するサブコントラクト記述
と、オブジェクトの表現と呼ばれる何らかの局所専用状
態である。

【００３８】クライアントは、Ｃ＋＋オブジェクトと見
えるものについて方法を呼出すことによってオブジェク
トと対話する。このオブジェクトに関わるコードは実際
には自動的に生成されており、方法呼出しをオブジェク
トの正規の方法テーブル又はそのサブコントラクト動作
ベクトルに対する呼出しに変換する。それらの方法がい
かにして効果をあげるかはクライアントにはわからない
が、適切なスタブ方法に対する呼出しを含む。その動作
については以下に説明する。

【００３９】オブジェクトが遠隔サーバにより実現され
る場合、サブコントラクトはその遠隔サーバと通信する
機械を実現し、一方、方法テーブルは、引数をバッファ
へマーシャル化し、遠隔呼出しを実行するためにサブコ
ントラクトを呼出し、次に応答バッファからの何らかの
結果をアンマーシャル化することを唯一必要とするスタ
ブ方法に対するポインタから構成されるというのが典型
的な構成である。ＳＰＲＩＮＧはインタフェース定義言
語から適切なスタブを生成するめに自動スタブジェネレ
ータ（「ＣＯＮＴＯＣＣ」）を構成する。本発明の開示
の対称となるのはこの自動スタブジェネレータと、クラ
イアント側スタブインタプリタプロセスである。本発明
の役割を適正に説明するためには、クライアント側スタ
ブとサーバ側スタブがシステムによりどのように使用さ
れるかをさらに説明することが必要である。

【００４０】遠隔サーバにおいては、通常、入力呼出し
と関連するサブコントラクト作業を実行するための何ら
かのサブコントラクトコードと、動作ごとの引数と、サ
ーバアプリケーションへの呼出しとをアンマーシャル化
する何らかのサーバ側スタブコードとが存在する。この
サーバ側スタブコードＣＯＮＴＯＣＣによって自動的に
生成される。しかしながら、後述するように、好ましい
実施例のスタブインタプリタはクライアント側スタブの
みを目指しているのであるが、同じ原理をサーバ側スタ
ブと共に使用できることは当業者には認められるであろ
う。

【００４１】オブジェクトが完全に局所的に実現される
場合には、スタブ方法の使用を回避し、方法テーブル中
に直接に導入できるインプリメンテーション方法を提供
することが可能である。ＳＰＲＩＮＧは、この場合、方
法テーブルを生成するための支援を実行する。

【００４２】基本サブコントラクトメカニズム クライアント側サブコントラクト動作は次の通りであ
る。 ・ copy ・ consume ・ unmarshal ・ marshal ・ marshal＿copy ・ invoke ・ invoke＿preamble ・ narrow ・ object＿type＿id ・ object＿manager＿id ・ is＿null

【００４３】これらのサブコントラクト動作とその詳細
な説明は、本明細書にも参考として取入れてあるＧｒａ
ｈａｍ Ｈａｍｉｌｔｏｎ，Ｍｉｃｈａｅｌ Ｌ．Ｐｏ
ｗｅｌｌ，Ｊａｍｅｓ Ｇ．Ｍｉｔｃｈｅｌｌ及びＪｏ
ｎａｔｈａｎ Ｊ．Ｇｉｂｂｓｏｎｓ出願による名称
「Ａ Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆ
ｏｒ Ｓｕｂｃｏｎｔｒａｃｔｓ ｉｎ Ｄｉｓｔｒｉ
ｂｕｔｅｄ Ｐｒｏｃｅｓｓｉｎｇ Ｓｙｓｔｅｍｓ」
の同時係属出願第０７／９９５，８６３号の中に記載さ
れている。サブコントラクトの使用例と、クライアント
側スタブ及びサーバ側スタブとサブコントラクトメカニ
ズムとの対話について、ここで簡単に説明する。

【００４４】スタブ及びサブコントラクト利用の例 本発明を詳細に説明する前に、遠隔オブジェクトを呼出
すときに実行されるスタブとサブコントラクトの動作の
シーケンスを考えることが有用である。尚、これは単な
る１例であり、ここで定義され且つ先に指示した同時係
属引例の中に定義されているようなサブコントラクトを
ここで説明するよりはるかに新奇な動作を実行するよう
に構成できることは当業者には認められるであろう。図
６から図９についての以下の説明を参照のこと。

【００４５】方法Fredを支援し且つサブコントラクトＳ
Ａを使用するオブジェクトＡがあると仮定する。 復帰型fruitbatは何らかのサブコントラクトＳＦを使用
することがわかっている。

【００４６】たとえば、サブコントラクトＳＸを使用す
るwombat型のオブジェクトＸがあり、Ｘを引数として渡
しつつＡのfred方法を呼出すものとする（ステップ５
０）： １．まず、「fred」に関わるクライアント側スタブ方法
を入力する（ステップ５２，５４）。 ２．クライアント側スタブコードはＡのinvoke＿preamb
le動作を呼出す（ステップ５６）。 ３．ＳＡinvoke＿preambleコードは必要な初期設定と復
帰を実行する（ステップ５８）。

【００４７】４．次に、クライアント側スタブコード
は、Ｘの marshal＿copy動作を呼出すことにより、引数
オブジェクトＸをコピー引数としてマーシャル化しよう
とする。図６では、これは次のように進行してゆく。ク
ライアント側スタブfredは、マーシャル化すべき引数が
存在するか否かを知るために試験を実行する（ステップ
６０）。その返答はイエスであるので、次に、スタブfr
edはいずれかがオブジェクトであるか否かを知るために
引数を試験する（ステップ６２）。オブジェクトＸを発
見し、ＸはサブコントラクトＳＸを有することがわかる
と、スタブfredはオブジェクトＸをマーシャル化するた
めにサブコントラクトＳＸを呼出す。

【００４８】５．ＳＸmarshal＿copy コードは、引数バ
ッファに導入すべきＸのコピーを記述する情報を配列し
且つスタブfredに戻る（ステップ６４）。 ６．ここで、クライアント側スタブコードは全ての引数
をマーシャル化し終わっており、呼出しを実際に実行可
能な状態になる。そこで、Ａのinvoke動作を呼出す（ス
テップ７０）。

【００４９】７．ＳＡinvoke方法は、fred方法について
の呼出しがオブジェクトＡに関するサーバ状態で起こる
という要求をもって、引数バッファをターゲットサーバ
へ伝送するために必要な作業を実行し、次に、サーバか
ら戻る結果バッファを待機する（ステップ７２）。

【００５０】８．次に、図７を参照すると、ターゲット
サーバにより呼出しを受信し、サーバ側サブコントラク
トＳＳＡにデータを供給し、サブコントラクトＳＳＡは
バッファをサーバ側スタブＳ２に供給する（ステップ７
４，７６）。スタブＳ２はアンマーシャル化すべき引数
が存在するか否かを知るために検査し（ステップ７
８）、次に、引数のいずれかがオブジェクトであるか否
かを知るために検査する（ステップ８０）。アンマーシ
ャル化すべきオブジェクトＸが存在することが発見され
ると、サーバ側スタブＳ２はＳＳＡサブコントラクトの
アンマーシャル化動作を呼出す（ステップ８２）。サブ
コントラクトＳＳＡはオブジェクトＸのサブコントラク
トｉｄを検査して、それが関連するサブコントラクトＳ
Ｘを有することを発見する（ステップ８４）。次に、サ
ブコントラクトＳＳＡはサブコントラクトＳＸの対して
アンマーシャル化動作を呼出し（ステップ８４）、サブ
コントラクトＳＸはオブジェクトＸをアンマーシャル化
して、それをサブコントラクトＳＳＡに戻し、そこで、
サブコントラクトＳＳＡはそれをスタブＳ２に戻す（ス
テップ８６）。サーバ側スタブは受信した全ての引数の
アンマーシャル化を完了しており、その呼出しと引数を
ターゲットオブジェクトインプリメンテーションに渡し
（ステップ９２）、応答を待機する（ステップ９４）。
オブジェクトインプリメンタは呼出しを処理し、サブコ
ントラクトＳＦ及びサーバ側サブコントラクトＳＳＦを
もつオブジェクトfruitbat−１を生成し、サブコントラ
クトＳＳＦにサブコントラクトＳＦに関わるサーバ側サ
ブコントラクトとして活動するように命令する（ステッ
プ９６）。サブコントラクトＳＳＦはＦ１を識別するた
めに内部状態を生成し（ステップ９６）、この状態を指
示するオブジェクトＦ１を戻す（ステップ９８）。次
に、オブジェクトインプリメンタはクライアントに戻す
ためにオブジェクトＦ１をサーバ側スタブＳ２に戻す
（ステップ１００）。そこで図８を参照すると、スタブ
Ｓ２はここでオブジェクトfruitbatをマーシャル化する
ために、引数マーシャル化ルーチンを再び経過しなけれ
ばならない（ステップ１０４，１０６，１０８，１１０
及び１１２）。そこで、サブコントラクトＳＳＦ（ステ
ップ１１２）はマーシャル化引数をスタブＳ２に戻し、
スタブＳ２はマーシャル化データをサーバ側サブコント
ラクトＳＳＡに供給して、クライアント側サブコントラ
クトＳＡへ伝送させる（ステップ１１６，１１４）。

【００５１】９．この時点で、クライアント側スタブコ
ードはＳＡinvoke方法から結果バッファを受信し（ステ
ップ１３０）、その結果のアンマーシャル化を開始する
ことを望む。この場合、結果はサブコントラクトＳＦを
有するfruitbat型のオブジェクトにはわかっているの
で、クライアント側スタブfred（ＳＡ）はＳＦサブコン
トラクトのアンマーシャル化動作を呼出して、fruitbat
型に関わる正規方法テーブルを渡す。呼出しステップは
ブロック１４２，１３４，１３６，１３８に示されてお
り、先に引用した同時係属出願の中のコンパチブルオブ
ジェクトの説明中にさらに詳細に記載されている。

【００５２】１０．ＳＦサブコントラクトアンマーシャ
ル化コードは、結果バッファからのオブジェクトをアン
マーシャル化しようとする。コードは結果バッファから
の情報を独自のサブコントラクト方法テーブル及び渡さ
れた正規方法テーブルと組合せて新たなＳＰＲＩＮＧオ
ブジェクトＦ２を形成し、そのオブジェクトＦ２をクラ
イアント側スタブに渡して戻す（ステップ１４０）。

【００５３】１１．クライアント側スタブfredはそのタ
スクを完了し、結果オブジェクトをアプリケーションレ
ベルに戻すことができる（ステップ１４８）。

【００５４】このプロセスはＡのfred方法に関わるクラ
イアント側スタブコードによって駆動されていたが、タ
ーゲットオブジェクト、引数オブジェクト及び結果オブ
ジェクトとに関わるサブコントラクトをも含んでいた。

【００５５】クライアント側スタブジェネレータとスタ
ブインタプリタ スタブ及びサブコントラクトの利用法についてのこの例
示説明の中で指示した通り、クライアント側スタブはク
ライアントに対する一次インタフェースである。オブジ
ェクト指向、分散形システムで生成されるクライアント
スタブの数の関係上、それらのクライアント側スタブの
コードが占めるテキストメモリスペースを縮小する方法
を考えることが適切になった。再び図２を参照すると、
このメモリスペースを縮小するために使用されるメカニ
ズムはスタブジェネレータ（「ＣＯＮＴＯＣＣ」と呼ば
れる）１５２と、クライアント側スタブ記述ファイルの
データベース（圧縮スタブコード）１５６と、それらの
クライアント側スタブ記述ファイルをいかにして読取る
べきかに関する知識をもつスタブインタプリタ１５８と
を含む。ＣＯＮＴＯＣＣ１５２はインタフェース定義言
語（「ＩＤＬ」）ファイル１５０を読取り、対応するＣ
＋＋ファイルを生成する。ＣＯＮＴＯＣＣ１５２はＩＤ
Ｌデータ１５０を読取り且つ正規のＣ＋＋スタブファイ
ル又は以下にさらに詳細に説明する特殊クライアント側
スタブインタプリタファイル１５８のいずれかを生成す
る能力を有する。

【００５６】クライアント側スタブ クライアント側スタブはＣＯＮＴＯＣＣにより生成され
て、ＩＤＬオブジェクトについての動作の実行という結
果をもたらすクライアントが呼出しできるＣ＋＋方法を
提供する。スタブは多重継承を処理するメカニズムと、
ＳＰＲＩＮＧオブジェクト呼出しを実行するメカニズム
とから構成されている。

【００５７】ＳＰＲＩＮＧオブジェクト呼出しは、呼出
しに対する引数をトランスポートと呼ばれる線形データ
構造へとマーシャル化し、呼出しに対する識別オブジェ
クトについての方法を呼出し、且つ呼出しの結果をアン
マーシャル化する（例外が発生すれば、その例外を処理
する）ことによって実行される。Ｓｐｒｉｎｇのサブコ
ントラクトメカニズムであるため、クライアント側スタ
ブはパラメータオブジェクトをマーシャル化又はアンマ
ーシャル化することの詳細に対して管理する必要がな
く、実際の呼出しについても管理する必要がない。クラ
イアント側スタブは、引数と結果が適切な順序でマーシ
ャル化、アンマーシャル化されるように保証すると共
に、動作呼出しを実行するために識別オブジェクトのサ
ブコントラクトを呼出す必要がある。

【００５８】 たとえば、ＩＤＬインタフェース： interface param｛｝； interface res｛｝； exception that｛long reason；｝； interface face｛ res thod（copy param arg,copy long input,produce long output ） raises（that）； ｝； は、param 型の１つの引数（arg）と、long型の１つの
引数（input）を取出し、１つのlong引数（output）を
発生し、例外（that）を生じない限り、res 型の結果
（unnamed）を戻す１つの方法（thod）を有する。尚、
例外（that） の場合には、例外の１パラメータとしてl
ong（reason）を渡す。上記のインタフェースについて
クライアント側スタブの一部として下記のコードを（常
に、さらには、オプションとして）発生するために使用
されるＣＯＮＴＯＣＣトランスレータは：

【００５９】

【数１】

【００６０】このコードに関して実現すべき重要な事項
は、そのような全てのクライアント側スタブ方法におい
てコードの大半が同一であること、及び変更可能な部分
を適切、簡潔に記述できることである。それらの観察に
よって、クライアント側スタブのインタプリタという概
念が生まれた。

【００６１】クライアント側スタブ方法の可変部分は先
に肉太の字体で示されている。パラメータの型とモード
はスタブ方法ごとに変化するが、識別オブジェクトは常
に「any＿obj^* 」型であって、常に第１のパラメータで
ある。異なるスタブ方法によって発生する例外は異なる
場合もある。異なるパラメータは異なる方式でマーシャ
ル化されなければならないが、ライブラリ型についての
マーシャル化方法は良く知られており、オブジェクトと
構成型（array，struct など）のマーシャル化はその型
についてのマーシャル化方法を呼出すことにより実行さ
れる。呼出しは、サブコントラクト方法を呼出すことに
よって実行される。この場合、スタブ方法間の唯一の変
数は呼出し中の動作の識別である。アンマーシャル化は
マーシャル化と全く同様に変化し、ライブラリ型につい
てはこれも同じように良く知られており、どのオブジェ
クト又は構成型もアンマーシャル化方法を呼出すことに
よりアンマーシャル化される。発生する必要のある例外
はいずれもinvoke呼出しからの復帰コードとして符号化
され、例外に対するパラメータのアンマーシャル化と例
外の発生は１つの方法の中にカプセル化される。（しか
しながら、例外に対するパラメータのアンマーシャル化
と例外の発生は先にはインラインで生成されていたが、
好ましい実施例ではそれを別個の方法にすることによ
り、Ｃ＋＋符号化スタブにあってもスペースを節約する
可能性があることに注意する。）

【００６２】クライアント側スタブのインタプリタ Ｃ＋＋符号化スタブで観察された限定された可変性があ
れば、Ｃ＋＋符号化スタブの固定部分を本体とし且つ可
変部分を記述するテーブルを参照し、その記述が与えら
れると、それに従って活動するインタプリタが設けられ
る。スペースの節約はテーブル駆動スタブインタプリタ
を使用することの第１の目的であったので、テーブルは
できる限り実用的に形成されている。

【００６３】スタブの記述は数種類の情報、すなわち、
引数の型及びモードと、パラメータに関わるマーシャル
方法及びアンマーシャル方法並びにそれらの方法を必要
とする結果と、実行すべき動作の識別と、例外識別子か
ら例外のパラメータをアンマーシャル化し且つその例外
を発生させる方法へのマッピングとから構成されてい
る。加えて、以下に詳細に説明するように、必要とされ
るデータは他にも様々ある。一連のスタブの記述はかな
りの量の共通情報を含むので、１つのモジュール（動作
の集合体である一連のインタフェース）に関わる記述は
１つのテーブルにまとめられる。

【００６４】好ましい実施例には、現時点で、スタブイ
ンタプリタが認識するcopy，share，consume，produce
（「out」としても使用される），borrow，in，in＿out
及びreturnという９つのパラメータパスモードがあ
る。スタブインタプリタが認識するパラメータ型はboo
l，octet，char，short，long，long long，unsigned s
hort，unsigned long，unsigned long long，float，do
uble，string，struct（unions 及びbuiltins にも使用
される），array，object及びvoid（void returnsにの
み使用される）の１６種類である。モードと型はそれぞ
れ４ビットに符号化でき、その組合せは都合良く１つの
バイトにはめ込まれる。方法に対する各パラメータ（及
びreturn型）は少なくとも１つのバイトとして符号化さ
れる。１つの動作の全てのパラメータに関わるパラメー
タ記述子は次々に記憶される。動作ごとのパラメータ記
述子は0x00を含む１つのバイトによって終了し、（必要
に応じて）アドレス指定を容易にするために、次の４バ
イト境界に至る0xffを含むバイトを埋込まれている。
（現時点で好ましい実施例は方法のパラメータ記述を終
了させるためにこの空バイトを使用するが、このバイト
と、３バイトまでの埋込みとを節約できるような別の実
施例も可能である。このテーブルにおける方法のデータ
の終わりを識別するこの代替方法は、スタブインタプリ
タがモード「return」をもつバイトを見出すのは記述の
終わりであるという知識をもっているために可能なので
ある。）最後に、動作識別子は、動作のパラメータを記
述するバイトの前に、４バイト符号なし整数として記憶
される。クライアント側スタブ記述のレイアウトの１例
を図１１に示す。

【００６５】ライブラリ型はスタブインタプリタで適切
な時点で周知のコードによりマーシャル化、アンマーシ
ャル化される。オブジェクトパラメータは、適切なサブ
コントラクトマーシャル化方法（記述子中のモードに応
じてmarshal＿copy 又はmarshal＿consume）を呼出すこ
とによりマーシャル化される。オブジェクトをアンマー
シャル化する必要がある場合、そのアンマーシャル化方
法のアドレスを記述の中のいずれかの箇所に記憶させ、
そのアドレスの索引を（mode，type）対の後に記憶させ
る。構成型のパラメータに関わるマーシャル化方法及び
アンマーシャル化方法を見出すときにも同じ方法を採用
する。パラメータについてマーシャル化とアンマーシャ
ル化の双方の方法が必要とされる（たとえば、borrowパ
ラメータである）場合、マーシャル化方法を所定の索引
に記憶させ、アンマーシャル化方法はそれに続き、所定
の索引＋１でアクセスされることになる。

【００６６】それらの索引（及び記述子中の他の何らか
の索引）は（記述子が通常は小さいために）通常は小さ
いので、それらの索引について次のような符号化を使用
する。すなわち、索引は７ビットにはめ込まれるのであ
れば、最上位ビットをクリアして、索引を１つのバイト
の中に記憶する。また、索引が７ビットにはめ込まれな
いのであれば、最上位ビットをセットして、索引の上位
の７ビットを第１のバイトに記憶し、それに続く索引の
７ビットチャンクを連続するバイトに記憶する。その場
合、各バイトの最上位ビットは、数を完了するために下
位の７ビットチャンクが必要とされることを指示してい
る。

【００６７】struct，union又はbuiltinのパラメータが
呼出しによって発生されるか又は戻される場合には、ス
タブインタプリタは、アンマーシャル化方法を呼出す前
に、その型に関わるイニシャライザを呼出す必要があ
る。その場合、イニシャライザ方法のアドレスを記述中
の、アンマーシャル化方法の後に記憶する。consume を
渡されるstruct，union 及びbuiltin パラメータについ
て、スタブインタプリタはマーシャル化の後にパラメー
タをクリーンアップするための方法をも呼出さなければ
ならない。そのパラメータに関わるデストロイヤのアド
レスを記述中の、マーシャル方法の後に記憶する。stru
ct，union又はbuiltinパラメータの記述における方法の
実際の順序は、marshal＿consume，アンマーシャル化
（おそらくはmarshal＿consume＋１でアクセスされ
る）、デストロイヤ（marshal＿consume＋２でアクセス
される）、イニシャライザ（un＿marshal ＋２でアクセ
スされる）となる。

【００６８】好ましい実施例では、マーシャル化方法、
アンマーシャル化方法、イニシャライザ方法又はデスト
ロイヤ方法を呼出すためにスタブインタプリタが使用す
る方法アドレスについて検査を実行しない。スタブジェ
ネレータは正しい方法を期待されたスロットに挿入し且
つ正確に索引を充填しているものと仮定する。事実、ス
タブインタプリタは構成型のパラメータについてはmars
hal＿consume方法と、marshal＿copy 方法とを区別しな
い。テーブル中の適切な方法の索引がスタブインタプリ
タに与えられると仮定する。

【００６９】１つのモジュールによって発生する可能性
のある全ての例外は、例外に対する引数をいずれもアン
マーシャル化し且つその例外を発生させる方法のアドレ
スへの例外識別子から１つのマップに統合される。例外
が発生したことをスタブインタプリタが検出すると、ス
タブインタプリタは例外識別子を求めてテーブルを探索
し、例外を発生させるために対応する方法を呼出す。ス
タブインタプリタ自体から任意の例外を発生させるため
の方法は編成するのが困難であるので、スタブインタプ
リタ自体に例外を発生させる代わりに、方法呼出しを使
用した。

【００７０】再び図１１を参照すると、短縮をはかるた
め、モジュールを記述する様々なバイトとテーブルを連
続して記憶してあるので、記述に対する１つの索引で、
特定の動作呼出しについて必要とされる全ての情報を十
分に発見できる。まず、テーブル中のエントリの数を接
頭部として、アンマーシャル化などの方法２００のテー
ブルを記憶する。次に、同様にエントリの数を接頭部と
する例外のテーブル２０２が続く。次に、実際の方法記
述子自体２０４があり、各記述子は動作識別子である索
引２０６から構成されており、これは動作記述から記述
の前のテーブルに至るために使用される。その後に、動
作のパラメータを記述するバイトと索引２０８が続く。
それらのバイトはファンクションの復帰型の記述２１０
を含む。必要に応じて、それらの記述子に４バイトの複
数を充填させるために、各動作バイト群の後に空パディ
ングが続く。各ファンクション記述は少なくともファン
クションコード２０４と、（方法のテーブルをアクセス
するために）記述の始めに戻るまでの距離２０６と、フ
ァンクションの復帰型に関わる記述子２１０とを含む。
未構成復帰値として３つまでの未構成引数をもつファン
クションに対して、最小ファンクション記述子は１２バ
イトである。型がアンマーシャル化等の方法に対し索引
を必要としないのであれば、索引を省略する。上記の例
のＩＤＬインタフェースの記述は次の通りである：

【００７１】 static int example＿stub＿descriptors［］＝ ｛ 1， （int）res::＿unmarshal， 1， face＿codes::e＿that， （int）unmarshal＿and＿raise＿that， face＿codes::f＿thod， 6， STUB＿BYTES（STUB＿ARG（m＿copy，t＿object）， STUB＿ARG（m＿copy，t＿int32）， STUB＿ARG（m＿returns，t＿object）． 0） ｝；

【００７２】好ましい実施例のインプリメンテーションの詳細 スタブインタプリタは主として簡明なＣ＋＋コードであ
る。この章では、好ましい実施例で使用される詳細を説
明する。ＣＯＮＴＯＣＣがインタプリタを使用してクラ
イアント側スタブを使用することを伝えられると、ＣＯ
ＮＴＯＣＣは依然として呼出すべきクライアントに関わ
る方法を生成するが、その方法は単にスタブインタプリ
タを呼出すだけである。その方法の目的は、たとえば、
クライアントに呼出しのための適正なＣ＋＋方法宣言を
与えることにより、クライアントをインタプリタの存在
から隔離することである。

【００７３】多様復帰型 スタブインタプリタは、それが様々なＣ＋＋符号化スタ
ブであるかのように、様々な型の結果を戻すことができ
なければならない。通常のＣ＋＋コードは戻すと宣言さ
れている型しか戻せない。好ましい実施例では、本発明
が一部を成しているＳＰＲＩＮＧオペレーティングシス
テムは、ＳＰＡＲＣ（登録商標）アーキテクチャベース
システムでランするように設計されている。ＳＰＡＲＣ
はＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌの登録商標
であり、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．
が開発したＲＩＳＣコンピュータに基づく「Ｓｃａｌａ
ｂｌｅ Ｐｅｒｆｏｒｍａｎｃｅ ＡＲＣｈｉｔｅｃｔ
ｕｒｅ」の頭文字である。ＳＰＡＲＣアーキテクチャで
は、様々な異なる型の結果を戻すための規約はそれらの
結果を様々な異なる場所（たとえば、大半の結果に対す
るレジスタ、他の結果に対する事前割当てメモリなど）
に導入することを要求する。（付録Ｄ「Ｓｏｆｔｗａｒ
ｅ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」，Ｔｈｅ ＳＰＡ
ＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ第８
版，Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，１９９２年刊，ＩＳ
ＢＮＯ−１３−８２５００１−４参照。）多様復帰を実
行するために、スタブインタプリタは少数のアセンブラ
方法に依存する。それらの方法は様々な種類の復帰結果
をパラメータとして取上げ、それらを従来通りの復帰結
果用の場所に導入する。それらの方法は実際にはインラ
イン化されているが、レジスタウインドウ又はスタック
フレームを割当てないので、インタプリタ自体のレジス
タとスタックフレームをアクセスすることができる。

【００７４】多様バリアディック，パラメータ型 スタブインタプリタはＣ＋＋符号化スタブに渡されるで
あろうパラメータと同じパラメータをアクセスしなけれ
ばならない。インタプリタは、クライアント側スタブに
渡されるパラメータの数又は型をあらかじめ知ることは
できない。加えて、インタプリタは呼出し中の方法に関
わる動作記述の中の適切なエントリに対するポインタを
獲得しなければならない。好ましい実施例では、それら
の問題は、共に、クライアントが呼出すＣ＋＋方法から
スタブインタプリタへの１種のテール呼出しによって解
決される。

【００７５】上記の例のインタフェースのクライアント
は、次のように定義される方法を呼出すであろう。 res＿fp face＿methods::thod（any＿obj^*obj，param＿fp arg＿arg，int arg＿input ） raises that，contract＿fault ｛ stub＿code::processor（&example＿stub＿descriptors［5］）； return ^*（res＿fp^*）stub＿code::panic（obj，&arg＿arg，&arg＿input）; ｝

【００７６】復帰ステートメントの目的は、できる限り
少ないコードを生成しつつ、この方法に対するパラメー
タをコードの第１行を通して生き状態に保持することで
ある。復帰ステートメントには決して到達しない。（す
なわち、全てのことは計画に従って進行する。その行に
達してしまうと、システムはパニックを起こす。）コー
ドの第１行はスタブインタプリタ自体へ制御を移行し、
呼出すべき動作に関わる記述のアドレスをそれに渡す。

【００７７】スタブインタプリタに制御が移行される
と、クライアント側スタブに対する引数（識別オブジェ
クトなどを含む）は、初めのいくつかのイン・レジスタ
内又は通常のＳＰＡＲＣ呼出し規約における呼出し側の
フレーム内にある（先に挙げたＳＰＡＲＣアーキテクチ
ャマニュアルの付録Ｄを参照）。動作に関わる記述のア
ドレスは第１のアウト・レジスタにある。尚、この好ま
しい実施例においては、クライアント側スタブに対する
引数の１つのレジスタウインドウから次のレジスタウイ
ンドウへのコピーを回避している。イン・レジスタから
引数を失わないようにするために、スタブインタプリタ
は新たなレジスタ／メモリフレームを割当てない。その
代わりに、インタプリタの局所変数に対する要求に応じ
てクライアント側スタブのメモリフレームを拡張する。
（レジスタフレームを押さないメモリフレームの拡張
は、Ｃ＋＋コンパイラにスタブインタプリタのアセンブ
ラコードを生成させ且つインタプリタ方法に関わるセー
ブ命令を加算命令に変更することによって実行され
る。）アウト・レジスタから動作記述のアドレスを失わ
ないようにするために、スタブインタプリタが実行する
第１の事柄はそのアドレスを局所レジスタ変数にコピー
することである。このように、スタブインタプリタでは
通常のレジスタの引数をもってランしており、１回の飛
越し、１回の加算及び１回のレジスタコピーの中で動作
記述のアドレスを渡している。スタブインタプリタはク
ライアント側スタブのレジスタフレームでランしている
ので、多様復帰値を戻す方法はスタブインタプリタから
直接にクライアントコードに戻す（すなわち、クライア
ント側スタブでパニックを起こすことはない）。

【００７８】好ましい実施例では、スタブインタプリタ
は、記述データベース中のバイトコードからどのような
型であるかを見出すときに、クライアント側スタブに対
する引数をアクセスしなければならない。クライアント
側スタブに対する引数をもってインタプリタが実行する
第１の事柄は、引数をイン・レジスタからクライアント
の（呼出し側）のフレームで引数用として割当てれられ
ているスペースにコピーすることであるので、引数をメ
モリで渡された引数と共に順次アドレス指定することが
できる。インタプリタは様々なＣ＋＋要素を渡すための
標準規約（たとえば、structs は参照により渡されるな
ど）と、様々なＩＤＬパラメータパスモードに関わる規
約（たとえば、borrowパラメータは参照により渡される
など）とを処理するように設計されている。そのように
して、インタプリタは、バイトコード記述を処理すると
きに、クライアント側スタブに対する引数を適切にアク
セスできるのである。

【００７９】インタプリタ自体はバイトコード記述にわ
たる本質的には２つのループである。第１のループは、
何らかの引数のマーシャル化を要求するか否かを知るた
めに、各バイトコードを検査する。次に、識別オブジェ
クトについて指示された動作を呼出し、復帰コードを検
査する。その動作が成功したならば、バイトコード記述
にわたる第２のループは、いずれかの結果がアンマーシ
ャル化を必要とするか否かを判定する。この第２のルー
プが動作のreturn型を記述するバイトコードを検査する
とき、インタプリタからクライアントに戻すために適切
な多様復帰方法を呼出す。動作呼出しが失敗であった場
合には、復帰コードを使用して、適切な例外に対するパ
ラメータをアンマーシャル化し且つその例外を発生させ
る方法へマッピングする。

【００８０】サーバ側スタブに関わるインタプリタの構
成に伴なう概念上の問題はない。ところが、いくつかの
理由によって、好ましい実施例ではこれを実行しなかっ
た。

【００８１】ドメインは多数のサービスの１クライアン
トであっても良いが、典型的にはごく少数のサービスに
対するサーバである。そのため、ドメインはクライアン
ト側スタブを数多く必要とするであろうが、サーバ側ス
タブについては若干のスタブを必要とするだけであろ
う。従って、クライアント側スタブが占めるスペースを
縮小する場合と比べて、サーバ側スタブが占めるスペー
スの縮小のもたらす利点は相対的に少ないであろう。

【００８２】ＳＰＡＲＣにおける通常の呼出し規約を越
えるＣ＋＋コンパイラの規約の知識を余りに多くもつ必
要なく、クライアント側スタブの呼出し環境を理解する
ことは可能であった。これに対し、サーバ側スタブは、
典型的にはＣ＋＋vtables を介して、サーバ方法のイン
プリメンテーションを呼出さなければならない。vtable
ディスパッチはＣ＋＋コンパイラのライターの思いつき
の影響のみを受けるので、特定のＣ＋＋インプリメンテ
ーションに結合することが望ましいとは思わなかった。

【図面の簡単な説明】

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

【図２】 スタブジェネレータ／インタプリタの主要な
システムコンポーネントを示す図。

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

【図４】 サブコントラクトを使用する遠隔オブジェク
ト呼出しを示す図。

【図５】 サブコントラクトを使用する単一の機械にお
けるオブジェクト呼出しを示す図。

【図６】 本発明によるサブコントラクトの方法の使用
例を示すフローチャート。

【図７】 本発明によるサブコントラクトの方法の使用
例を示すフローチャート。

【図８】 本発明によるサブコントラクトの方法の使用
例を示すフローチャート。

【図９】 本発明によるサブコントラクトの方法の使用
例を示すフローチャート。

【図１０】 ＳＰＲＩＮＧによるオブジェクトの見方
と、従来の技術によるオブジェクトの見方とを対比して
示す図。

【図１１】 クライアント側スタブ記述のレイアウト例
を示す図。

【符号の説明】

１０…機械Ａ、１２…クライアントアプリケーション、
１４…クライアント側スタブ、１６，２０…ネットワー
クソフトウェア、１８…機械Ｂ、２２…サーバ側スタ
ブ、２４…サーバアプリケーション、３０…クライアン
ト側サブコントラクト、３２…サーバ側サブコントラク
ト、３６…オペレーティングシステム、１５０…インタ
フェース定義言語、１５２…クライアント側スタブジェ
ネレータ、１５４…Ｃ＋＋スタブコード、１５６…デー
タベース、１５８…クライアント側スタブインタプリ
タ、１６６…限定スタブコード、１６８…引数、１７
０、１７２…コンピュータメモリ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 グラハム・ハミルトン アメリカ合衆国 94303 カリフォルニア 州・パロ アルト・デビッド コート・ 3143 (72)発明者 ジョナサン・ジェイ・ギボンズ アメリカ合衆国 94043 カリフォルニア 州・マウンテンビュー・ラッセン アヴェ ニュ・269

Claims (10)

【特許請求の範囲】
1. 【請求項１】 コンピュータシステム内でクライアント
   により呼出された特定のスタブ動作を実行する方法にお
   いて，コンピュータメモリの第１の領域から、前記スタ
   ブ動作を実行するために要求されるコード中で複数のス
   タブ動作に共通するものとして識別される第１の部分を
   アクセスする過程と，コンピュータメモリの第２の領域
   から、前記スタブ動作を実行するために要求されるコー
   ド中で前記特定のスタブ動作に独自のものとして識別さ
   れる第２の部分をアクセスする過程とから成り，それに
   より、クライアント側スタブに要求されるコンピュータ
   メモリスペースの量を減少させる方法。
2. 【請求項２】 コンピュータシステム内でクライアント
   により呼出された特定のスタブ動作を実行する方法にお
   いて，スタブ動作を実行するために生成されるコードを
   複数のスタブ動作に共通するコードの第１の部分と、前
   記スタブ動作の中の特定の１つの動作に独自のものであ
   るコードの第２の部分とに分割し、且つ前記コードの第
   ２の部分をコンピュータメモリに記憶する過程と，スタ
   ブインタプリタを使用して前記コードの第１の部分のコ
   ピーを包含し、前記スタブインタプリタは、クライアン
   トによりスタブ動作が呼出されるたびに前記コードの第
   １の部分を供給する過程と，クライアントにより特定の
   スタブ動作が呼出されるたびに、要求に応じて前記スタ
   ブインタプリタにより前記コードの第２の部分をアクセ
   スする過程とから成る方法。
3. 【請求項３】 クライアント側スタブに要求される前記
   コンピュータメモリスペースをさらに縮小するために、
   前記スタブ動作の前記コードの可変部分の符号化表現を
   生成することにより前記コードの第２の部分を圧縮する
   追加の過程を含む請求項２記載の方法。
4. 【請求項４】 各々がクライアント側スタブを呼出しう
   るクライアントアプリケーションを実行できるような複
   数の会話形ワークステーションを有するデータ処理シス
   テムで使用するために、クライアント側スタブに対する
   クライアント動作呼出しを実行する方法において，スタ
   ブ動作を実行するために生成されるコードを複数のスタ
   ブ動作に共通するコードの第１の部分と、特定のスタブ
   動作に独自のものであるコードの第２の部分とに分割す
   る過程と，スタブインタプリタを使用して前記コードの
   第１の部分のコピーを包含し、前記スタブインタプリタ
   は、クライアントによりスタブ動作が呼出されるたびに
   前記コードの第１の部分を供給する過程と，クライアン
   ト側スタブに要求される前記コンピュータメモリスペー
   スをさらに縮小するために、前記コードの第２の部分の
   符号化表現を生成することにより前記コードの第２の部
   分を圧縮する過程と，クライアントによりスタブ動作が
   呼出されるたびに、要求に応じて前記スタブインタプリ
   タにより前記コードの第２の部分をアクセスする過程と
   から成り，それにより、クライアント側スタブの記憶装
   置に要求されるメモリスペースを縮小する方法。
5. 【請求項５】 特定のクライアント側スタブ動作を呼出
   すことによりクライアント動作を実行する追加の過程
   と，前記符号化表現を使用することにより前記クライア
   ント動作を実行するために前記スタブインタプリタを呼
   出す追加の過程とを含む請求項４記載の方法。
6. 【請求項６】 クライアント側スタブ動作を実行するシ
   ステムにおいて，特定のクライアント側スタブ動作に独
   自のものであるデータの第２の部分を包含するように生
   成されるクライアント側スタブ動作のデータベースと，
   前記クライアント側スタブ動作のデータベースを受信し
   且つ記憶するコンピュータと，前記コンピュータの中に
   あり、前記クライアント側スタブ動作のデータベース
   と、複数のスタブ動作に共通するデータの第１の部分を
   包含しているスタブインタプリタとによってクライアン
   ト側スタブ動作に対するクライアント呼出しを実行する
   プロセッサとを具備し，それにより、クライアント側ス
   タブ動作に関わるデータを記憶するために使用されるコ
   ンピュータメモリスペースを縮小するシステム。
7. 【請求項７】 前記コンピュータに結合し、前記データ
   の第２の部分を前記データの符号化表現に変換して、ク
   ライアント側スタブ動作に関わるデータを記憶するため
   に使用される前記コンピュータメモリスペースをさらに
   縮小するスタブジェネレータをさらに具備する請求項６
   記載のシステム。
8. 【請求項８】 コンピュータでクライアントにより呼出
   される特定のスタブ動作を実行するシステムであって、
   各々が複数のスタブ動作に共通するコードの第１の部分
   と、前記特定のスタブ動作のそれぞれに独自のものであ
   るコードの第２の部分とを含んでいるクライアント側ス
   タブについて要求されるコンピュータメモリスペースを
   最小限に抑えるシステムにおいて，前記コードの第１の
   部分のコピーを包含し、前記特定のスタブ動作がクライ
   アントにより呼出されるたびに、前記コードの第１の部
   分を供給するスタブインタプリタと；前記特定のスタブ
   動作がクライアントにより呼出されるたびに必要に応じ
   て前記スタブインタプリタによってアクセスされる前記
   コードの第２の部分をコンピュータメモリに記憶するコ
   ンピュータとを具備し，それにより、クライアント側ス
   タブ用として要求される前記コンピュータメモリスペー
   スを縮小するシステム。
9. 【請求項９】 前記コンピュータに結合し、前記コード
   の第２の部分の符号化表現を生成することにより前記コ
   ードの第２の部分を圧縮して、クライアント側スタブ用
   として要求される前記コンピュータメモリスペースをさ
   らに縮小するスタブジェネレータをさらに具備する請求
   項８記載のシステム。
10. 【請求項１０】 クライアントアプリケーションと、オ
    ブジェクトと、オブジェクト型定義と、オブジェクトイ
    ンプリメンテーションと、サーバとが存在するオブジェ
    クト指向システムで、クライアント動作によりオブジェ
    クトに対して呼出される特定の動作を処理するために使
    用するためのコンピュータプログラムが記録されている
    コンピュータ読取り可能媒体を有するコンピュータプロ
    グラム製品において，オブジェクトに対して呼出される
    前記特定の動作を実行するために要求され、符号化され
    てコンピュータメモリに記憶された前記特定の動作に関
    連する特定のクライアント側スタブ方法に対し独自のも
    のとして識別されるコードの第２の部分を表わす符号化
    データのデータベースと；前記スタブ方法を実行するた
    めに要求され、複数の異なるクライアント側スタブ方法
    に共通するものとして識別されるコードの第１の部分を
    アクセスすると共に、前記クライアント動作によって呼
    出される特定のスタブ方法を実行するためにコンピュー
    タメモリから前記コードの第２の部分をアクセスし、前
    記特定のクライアント動作要求によって呼出されるクラ
    イアント側スタブ方法を実行するプログラムコードとを
    具備し，それにより、クライアント側スタブ動作を記憶
    するために要求されるコンピュータメモリを最小限に抑
    えるコンピュータプログラム製品。