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

Description

【０００１】
【産業上の利用分野】
本発明は分散形計算システム、クライアントサーバ計算及びオブジェクト指向プログラミングの分野に関する。特定すれば、本発明は、クライアント側スタブにより要求されるメモリスペースを最小限に抑えるように設計され且つクライアント側スタブジェネレータ及びクライアント側スタブインタプリタと呼ばれる論理モジュールを具備する方法及び装置である。
【０００２】
【従来の技術】
オペレーティングシステムの開発と保守における重大な問題は、オペレーティングシステムにインプリメンテーションの詳細をロードダウンせずにクライアントやプログラマに最大限の融通性を与えるような方法で新たなインタフェースとインプリメンテーション技法の導入を可能にするということである。さらに、マイクロカーネルアーキテクチャを有するオブジェクト指向オペレーティングシステムを開発する場合には、この問題は一層深刻になる。マイクロカーネルは、典型的には、クライアントに、たとえば、ファイルシステムなどのクライアントレベルの複雑なサブシステムを実現させる。それにもかかわらず、クライアント間通信又はコンピュータ間通信などの基本システムプロセスは非常に複雑であるので、クライアントとオブジェクトインプリメンタはそれらのプロセスに関わるべきではない。すなわち、それらの本来は「システム」型であるプロセスは標準モジュールによってより効率良く実行されるのであるが、基本オペレーティングシステムがそれらのプロセスによって制約されることを要求しないような方法で処理されるべきである。
【０００３】
システムの異なるコンポーネントの間のインタフェースを定義するためにオブジェクトメタファを使用するシステムについてこの基本的な問題を解決する方法の一部として、スタブや、他の同様の種類の中間論理モジュールが使用されてきた。そのようなスタブは、呼出しのパラメータとして別のオブジェクトを送信していることもある遠隔コンピュータの間でのオブジェクト呼出しの通信を処理するための標準モジュールとして記述される。それらのスタブ及び他の類似するモジュールと、その相互関係については、以下に、スタブジェネレータとスタブインタプリタを含む本発明の詳細な説明の文脈の中でさらに詳細に説明する。
【０００４】
オブジェクト指向システムでは、オブジェクトは、データと、そのデータを操作するために呼出すことができる動作とから成るコンポーネントである。動作はオブジェクトにおいて、オブジェクトへ呼出しを送信することによって呼出される。各オブジェクトはオブジェクト型を有する。オブジェクト型はその型のオブジェクトで実行できる動作を定義する。オブジェクト動作はオブジェクト自体とは無関係に実現される。加えて、１つのオブジェクト型は他のオブジェクト型に関して定義され且つ実現されるオブジェクト動作を継承していることもある。オブジェクト指向デザインとプログラミング技法の詳細については、Ｂｅｒｔｒａｎｄ Ｍｅｙｅｒの「Ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ Ｃｏｎｓｔｒｕｃｔｉｏｎ」（Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ，１９８８年）を参照。
【０００５】
クライアント−サーバ計算においては、典型的には、コンピュータを接続するネットワークを介して互いに通信できる１組のコンピュータがある。それらのコンピュータの一部は、他のコンピュータにサービス又は機能性を提供する働きをする。そのようなサービス又は機能の提供者は「サーバ」として知られており、そのようなサービス又は機能性を消費する側を「クライアント」と呼ぶ。クライアント−サーバモデルは、同じコンピュータでランしている別個のプログラムが何らかの保護メカニズムを介して互いに通信しており且つ機能性の提供者並びに消費者として活動しているようなケースにも一般化される。
【０００６】
クライアント−サーバモデルに基づくオブジェクト指向分散形システムには、オブジェクト指向インタフェースをクライアントに提供するサーバが存在する。それらのサーバはデータと、関連ソフトウェアとから構成されるオブジェクトを支援する。クライアントはそれらのオブジェクトに対するアクセスを獲得し且つそれらのオブジェクトに対して呼出しを実行する。それらの呼出しはクライアントからサーバへ伝送される。サーバでは、それらの呼出しをオブジェクトと関連するソフトウェアを介して実行する。次に、それらの呼出しの結果をクライアントに伝送して戻す。
【０００７】
さらに最近のシステムにおいては、アプリケーションソフトウェアはネットワークと直接には通信しない。その代わりに、アプリケーションソフトウェアは「スタブ」（図１の１４）と通信する。スタブは、クライアントとサーバとの間にネットワークが存在しているか否かにかかわらず、一貫したインタフェースを形成する。システムにより支援される個別のインタフェースごとに、別々のスタブが存在する。スタブコードは、アプリケーションレベルソフトウェアが見る特定言語レベルインタフェースと、ネットワークソフトウェアが提供する標準低レベル通信インタフェースとの間で変換を実行する必要がある。たとえば、スタブは遠隔呼出しに対する引数を取上げ、それらの引数をネットワークソフトウェアがネットワークを介して伝送するのに適するメッセージに導入する必要がある。そのようなスタブの利用法は、Ｄｏｎａｌｄ Ｅ．Ｍｅｒｕｓｉの著書「Ｓｏｆｔｗａｒｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅ」の３４９〜３６８ページのＲｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌｓ（「ＲＰＣ」）についての章（Ｄｉｇｉｔａｌ Ｐｒｅｓｓ，１９９２年，ＩＳＢＮ１−５５５５８−０９０−４）の中に記載されている。
【０００８】
そのようなオブジェクト指向分散形システムで生成されるクライアント側スタブの数の関係上、それらの数多くのクライアント側スタブに関連するコードが占めるテキストメモリスペースを縮小するためのメカニズムが必要であることが明らかになっている。
【０００９】
【発明が解決しようとする課題】
従って、本発明は、分散形システムで最も重要であるオブジェクト呼出し及び引数渡しの基本メカニズムの制御を実行するためのスタブの設計を保持しつつ、クライアント側スタブが要求するメモリスペースを最小限に抑えるように設計されており且つアプリケーションプログラマに特定のオブジェクトのために使用されている特定スタブを知らせないようにしても差しつかえないようにする、クライアント側スタブジェネレータ、圧縮クライアント側スタブ実行コードのデータベース及びクライアント側スタブインタプリタと呼ばれる論理モジュールを具備する装置及び方法を提供することを課題内とする。
【００１０】
【課題を解決するための手段】
本発明は、クライアントアプリケーションによるオブジェクトの呼出しを実行し且つクライアントアプリケーションと、オブジェクトインプリメンテーションとの間で引数を渡すメカニズムを形成し、クライアントアプリケーション又はオペレーティングシステムはそれらのメカニズムがどのように動作するかの詳細を知ることなく、クライアント側スタブ用として要求されるメモリスペースを縮小するような手際よく、簡潔な方法を提供する。さらに、それらのメカニズムは、クライアントアプリケーションが１つのコンピュータノードにあり、オブジェクトインプリメンテーションは別のコンピュータノードにあるような分散形コンピュータ環境でも同様の容易さと効率をもって機能する。
【００１１】
コンピュータシステム中のクライアントにより呼出される特定のスタブ動作を、複数の異なるスタブ方法に共通するコードとして識別され、そのスタブ動作を実行するために要求されるコードの第１の部分をコンピュータメモリの第１の領域からアクセスし、且つ呼出される特定のスタブ動作について独自のものであるコードの第２の部分をコンピュータメモリの第２の部分からアクセスすることによって実行する方法及び装置を説明する。複数のスタブ方法に共通するコードは一度しか記憶されないので、これにより、要求されるコンピュータメモリを縮小できる。
【００１２】
さらに、スタブ動作を実行するために生成されるコードを複数のスタブ方法に共通するコードの第１の部分と、各スタブ動作について独自のものであるコードの第２の部分とに分割すると共に、様々な方法、テキスト及びパラメータのバイトコード表現を使用して、このコードの第２の部分を圧縮形式でコンピュータメモリに記憶するプロセスを提供する方法及び装置を示す。複数のスタブ方法に共通するコードの部分はスタブインタプリタと呼ばれるメカニズムの中に含まれており、このスタブインタプリタは、クライアントによりスタブ動作が呼出されるたびに、共通コードのこの部分を供給する。スタブインタプリタは、スタブ方法が呼出されるたびに、そのスタブ方法を完了するために要求されるスタブコードの独自の部分を獲得するために、メモリをアクセスする。
【００１３】
このメモリスペースを縮小するために使用されるメカニズムは、コンピュータメモリに記憶される圧縮クライアント側スタブ記述ファイルから成るデータベースを生成するスタブジェネレータ（「ＣＯＮＴＯＣＣ」と呼ばれる）と、それらのクライアント側スタブ記述ファイルをいかにして読取るべきかについての知識をもつスタブインタプリタとを具備する。ＣＯＮＴＯＣＣはインタフェース定義言語（「ＩＤＬ」）ファイルを読取り、対応するＣ＋＋ファイルを生成する。ＣＯＮＴＯＣＣはＩＤＬデータを読取り、圧縮解除Ｃ＋＋スタブファイルか、バイト符号化形態に含まれている特定のスタブ方法について独自のものであるデータのみを含む特殊圧縮クライアント側スタブインタプリタファイルのいずれかを生成する能力を有する。
【００１４】
スタブインタプリタ論理モジュールはターゲットオブジェクトと、呼出された特定のスタブ方法に関連する引数と、コンピュータメモリに記憶されている圧縮クライアント側スタブ記述ファイルのデータベースの中のスタブコードの圧縮バイトコード表現に対するポインタとを受信し、必要に応じてオブジェクト呼出し、戻りメッセージのマーシャル化又はアンマーシャル化を実行するように進行する。
本発明のシステムの目的、特徴及び利点は以下の説明から明白になるであろう。
【００１５】
〔表記法及び用語〕
以下の詳細な説明はコンピュータ又は複数のコンピュータから成るネットワークで実行されるプログラム手続きによって提示される。そのような手続きによる手続きや表現は、当業者がその作業の内容を他の当業者に最も有効に伝達するために使用する手段である。
【００１６】
ここでは、また、一般的にも、手続きはある所望の結果に至るステップの首尾一貫したシーケンスである。それらのステップは物理的量の物理的操作を要求するステップである。通常、それらの量は記憶、転送、組合せ、比較及びその他の操作が可能である電気信号又は磁気信号の形態をとる。時によっては、主として一般に使用されている用語であるという理由により、それらの信号をビット、値、要素、信号、文字、項、数などと呼ぶと好都合であることがわかる。しかしながら、それらの用語及びそれに類する用語は、全て、適切な物理的量と関連させるべきものであり、単にそれらの量に便宜上付されたラベルであるにすぎないということに注意すべきである。
【００１７】
さらに、実行される操作を、一般にはオペレータが実行する知的動作と関連する加算又は比較などの用語で呼ぶことが多い。ここで説明する、本発明の一部を成す動作のいずれをとっても、オペレータのそのような能力は不要であるか、又は多くの場合に望ましくない。動作は機械動作である。本発明の動作を実行するのに有用な機械には、汎用デジタルコンピュータ又はそれに類する装置がある。
【００１８】
本発明は、それらの動作を実行するための装置にも関する。この装置は要求される目的に合わせて特別に構成されても良く、あるいは、汎用コンピュータに記憶させたコンピュータプログラムによってコンピュータを選択的に起動又は再構成しても良い。ここで提示する手続きは、本来、特定のコンピュータ又は他の特定の装置に関連するものではない。様々な汎用機械をここで示す教示に従って書込んだプログラムと共に使用しても良く、あるいは、要求される方法ステップを実行するためには、より特殊化した装置を構成するほうが好都合であると判明するかもしれない。それらの様々な機械について要求される構造は以下の説明から明白になるであろう。
【００１９】
【実施例】
以下の開示は、オブジェクト指向、クライアントサーバ、分散形計算演算から成る計算環境におけるスタブ演算を実行するコンピュータコードが占める総メモリスペースを縮小する独特の革新的な方法及び装置を説明する。
【００２０】
そこで図２を参照すると、本発明が示されている。本発明は、入力としてインタフェース定義言語（「ＩＤＬ」）コード１５０を受信し、必要に応じてクライアント側スタブ用の圧縮コード及びテーブルから成るデータベース１５６を生成するか、又は必要に応じて正規のＣ＋＋スタブコード１５４を生成するクライアント側スタブジェネレータ（「ＣＯＮＴＯＣＣ」）１５２と、マーシャル化、アンマーシャル化及びオブジェクト呼出しといったクライアント側スタブ機能を実行できるランタイムクライアント側スタブインタプリタ１５８とを含む。呼出されつつある方法に対するターゲットオブジェクトと引数１６８を渡し且つコンピュータメモリ１７０に記憶されている正規スタブコードを介してその方法を実行する正規スタブ方法呼出し１６２が指示されている。また、スタブインタプリタ１５８と共に使用される型のスタブ方法呼出し１６４も示されており、これも呼出されつつある方法に対するターゲットオブジェクトと引数を渡すのであるが、それに加えて、コンピュータメモリ１７２の圧縮スタブコード１６６に対するポインタを渡し、それにより、スタブインタプリタ１５８はその方法呼出しを実行することができる。以下、本発明の好ましい実施例を実現する動作環境を簡単に説明した後に、本発明のそれらのコンポーネントについてさらに詳細に説明する。
【００２１】
以下の説明中、本発明を完全に理解させるために、説明の便宜上、特定のデータや構成を挙げる。ここで説明する好ましい実施例は、方法テーブルと、サブコントラクトメカニズムと、「サブコントラクトの」局所専用状態を表わすデータ構造とを含む「spring object」 と呼ばれる新しい型のオブジェクトを含む計算環境において実現され、ここに挙げたものは全てＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．（「Ｓｕｎ」）のＳＰＲＩＮＧ Ｏｂｊｅｃｔ Ｏｒｉｅｎｔｅｄ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（「ＳＰＲＩＮＧ」）の制御の下に動作している。クライアント側スタブインタプリタとその基礎を成すプロセスをここで説明する特定の詳細がなくとも実施しうると共に、様々なコンピュータシステムや、密結合プロセッサの様々な構成、形態又はモデル、あるいは、疎結合多重プロセッサシステムの様々な構成において実現しうることは当業者には認められるであろう。
【００２２】
ＳＰＲＩＮＧオブジェクトは、状態を含み、その状態を操作するための１組の方法を提供する抽象である。オブジェクトとその方法の記述は、インタフェース定義言語（「ＩＤＬ」）で指定されるインタフェースである。インタフェースはインプリメンタ（サーバ）と、オブジェクトのクライアントとの間の強く型付けされたコントラクトである。
【００２３】
ＳＰＲＩＮＧドメインは、スレッド群を伴なうアドレススペースである。１つのドメインが与えられたとき、そのドメインはいくつかのオブジェクトのサーバとして活動し、別のオブジェクトのクライアントとして活動することもある。インプリメンタとクライアントは同一のドメインにあっても良く、異なるドメインにあっても良い。
【００２４】
ＳＰＲＩＮＧはオブジェクト指向であるので、インタフェース継承の概念を支援する。ＳＰＲＩＮＧは単一インタフェース継承と、多重インタフェース継承双方の概念を支援する。「ｆｏｏ」型のオブジェクトを受入れるインタフェースは、［ｆｏｏ」のサブクラスの事例をも受入れる。たとえば、address＿spaceオブジェクトはmemory＿objectを取出し、それをアドレススペースにマッピングする方法を有する。同じ方法は、memory＿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＿preamble動作を呼出す（ステップ５６）。
３．ＳＡinvoke＿preambleコードは必要な初期設定と復帰を実行する（ステップ５８）。
【００４７】
４．次に、クライアント側スタブコードは、Ｘの marshal＿copy動作を呼出すことにより、引数オブジェクトＸをコピー引数としてマーシャル化しようとする。図６では、これは次のように進行してゆく。クライアント側スタブfredは、マーシャル化すべき引数が存在するか否かを知るために試験を実行する（ステップ６０）。その返答はイエスであるので、次に、スタブfredはいずれかがオブジェクトであるか否かを知るために引数を試験する（ステップ６２）。オブジェクトＸを発見し、ＸはサブコントラクトＳＸを有することがわかると、スタブfredはオブジェクトＸをマーシャル化するためにサブコントラクトＳＸを呼出す。
【００４８】
５．ＳＸmarshal＿copy コードは、引数バッファに導入すべきＸのコピーを記述する情報を配列し且つスタブfredに戻る（ステップ６４）。
６．ここで、クライアント側スタブコードは全ての引数をマーシャル化し終わっており、呼出しを実際に実行可能な状態になる。そこで、Ａのinvoke動作を呼出す（ステップ７０）。
【００４９】
７．ＳＡinvoke方法は、fred方法についての呼出しがオブジェクトＡに関するサーバ状態で起こるという要求をもって、引数バッファをターゲットサーバへ伝送するために必要な作業を実行し、次に、サーバから戻る結果バッファを待機する（ステップ７２）。
【００５０】
８．次に、図７を参照すると、ターゲットサーバにより呼出しを受信し、サーバ側サブコントラクトＳＳＡにデータを供給し、サブコントラクトＳＳＡはバッファをサーバ側スタブＳ２に供給する（ステップ７４，７６）。スタブＳ２はアンマーシャル化すべき引数が存在するか否かを知るために検査し（ステップ７８）、次に、引数のいずれかがオブジェクトであるか否かを知るために検査する（ステップ８０）。アンマーシャル化すべきオブジェクトＸが存在することが発見されると、サーバ側スタブＳ２はＳＳＡサブコントラクトのアンマーシャル化動作を呼出す（ステップ８２）。サブコントラクトＳＳＡはオブジェクトＸのサブコントラクトｉｄを検査して、それが関連するサブコントラクトＳＸを有することを発見する（ステップ８４）。次に、サブコントラクトＳＳＡはサブコントラクトＳＸの対してアンマーシャル化動作を呼出し（ステップ８４）、サブコントラクトＳＸはオブジェクトＸをアンマーシャル化して、それをサブコントラクトＳＳＡに戻し、そこで、サブコントラクトＳＳＡはそれをスタブＳ２に戻す（ステップ８６）。サーバ側スタブは受信した全ての引数のアンマーシャル化を完了しており、その呼出しと引数をターゲットオブジェクトインプリメンテーションに渡し（ステップ９２）、応答を待機する（ステップ９４）。オブジェクトインプリメンタは呼出しを処理し、サブコントラクトＳＦ及びサーバ側サブコントラクトＳＳＦをもつオブジェクトfruitbat−１を生成し、サブコントラクトＳＳＦにサブコントラクトＳＦに関わるサーバ側サブコントラクトとして活動するように命令する（ステップ９６）。サブコントラクトＳＳＦはＦ１を識別するために内部状態を生成し（ステップ９６）、この状態を指示するオブジェクトＦ１を戻す（ステップ９８）。次に、オブジェクトインプリメンタはクライアントに戻すためにオブジェクトＦ１をサーバ側スタブＳ２に戻す（ステップ１００）。そこで図８を参照すると、スタブＳ２はここでオブジェクトfruitbatをマーシャル化するために、引数マーシャル化ルーチンを再び経過しなければならない（ステップ１０４，１０６，１０８，１１０及び１１２）。そこで、サブコントラクトＳＳＦ（ステップ１１２）はマーシャル化引数をスタブＳ２に戻し、スタブＳ２はマーシャル化データをサーバ側サブコントラクトＳＳＡに供給して、クライアント側サブコントラクトＳＡへ伝送させる（ステップ１１６，１１４）。
【００５１】
９．この時点で、クライアント側スタブコードはＳＡinvoke方法から結果バッファを受信し（ステップ１３０）、その結果のアンマーシャル化を開始することを望む。この場合、結果はサブコントラクトＳＦを有するfruitbat型のオブジェクトにはわかっているので、クライアント側スタブfred（ＳＡ）はＳＦサブコントラクトのアンマーシャル化動作を呼出して、fruitbat型に関わる正規方法テーブルを渡す。呼出しステップはブロック１４２，１３４，１３６，１３８に示されており、先に引用した同時係属出願の中のコンパチブルオブジェクトの説明中にさらに詳細に記載されている。
【００５２】
１０．ＳＦサブコントラクトアンマーシャル化コードは、結果バッファからのオブジェクトをアンマーシャル化しようとする。コードは結果バッファからの情報を独自のサブコントラクト方法テーブル及び渡された正規方法テーブルと組合せて新たなＳＰＲＩＮＧオブジェクトＦ２を形成し、そのオブジェクトＦ２をクライアント側スタブに渡して戻す（ステップ１４０）。
【００５３】
１１．クライアント側スタブfredはそのタスクを完了し、結果オブジェクトをアプリケーションレベルに戻すことができる（ステップ１４８）。
【００５４】
このプロセスはＡのfred方法に関わるクライアント側スタブコードによって駆動されていたが、ターゲットオブジェクト、引数オブジェクト及び結果オブジェクトとに関わるサブコントラクトをも含んでいた。
【００５５】
クライアント側スタブジェネレータとスタブインタプリタ
スタブ及びサブコントラクトの利用法についてのこの例示説明の中で指示した通り、クライアント側スタブはクライアントに対する一次インタフェースである。オブジェクト指向、分散形システムで生成されるクライアントスタブの数の関係上、それらのクライアント側スタブのコードが占めるテキストメモリスペースを縮小する方法を考えることが適切になった。再び図２を参照すると、このメモリスペースを縮小するために使用されるメカニズムはスタブジェネレータ（「ＣＯＮＴＯＣＣ」と呼ばれる）１５２と、クライアント側スタブ記述ファイルのデータベース（圧縮スタブコード）１５６と、それらのクライアント側スタブ記述ファイルをいかにして読取るべきかに関する知識をもつスタブインタプリタ１５８とを含む。ＣＯＮＴＯＣＣ１５２はインタフェース定義言語（「ＩＤＬ」）ファイル１５０を読取り、対応するＣ＋＋ファイルを生成する。ＣＯＮＴＯＣＣ１５２はＩＤＬデータ１５０を読取り且つ正規のＣ＋＋スタブファイル又は以下にさらに詳細に説明する特殊クライアント側スタブインタプリタファイル１５８のいずれかを生成する能力を有する。
【００５６】
クライアント側スタブ
クライアント側スタブはＣＯＮＴＯＣＣにより生成されて、ＩＤＬオブジェクトについての動作の実行という結果をもたらすクライアントが呼出しできるＣ＋＋方法を提供する。スタブは多重継承を処理するメカニズムと、ＳＰＲＩＮＧオブジェクト呼出しを実行するメカニズムとから構成されている。
【００５７】
ＳＰＲＩＮＧオブジェクト呼出しは、呼出しに対する引数をトランスポートと呼ばれる線形データ構造へとマーシャル化し、呼出しに対する識別オブジェクトについての方法を呼出し、且つ呼出しの結果をアンマーシャル化する（例外が発生すれば、その例外を処理する）ことによって実行される。Ｓｐｒｉｎｇのサブコントラクトメカニズムであるため、クライアント側スタブはパラメータオブジェクトをマーシャル化又はアンマーシャル化することの詳細に対して管理する必要がなく、実際の呼出しについても管理する必要がない。クライアント側スタブは、引数と結果が適切な順序でマーシャル化、アンマーシャル化されるように保証すると共に、動作呼出しを実行するために識別オブジェクトのサブコントラクトを呼出す必要がある。
【００５８】

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

【００６０】
このコードに関して実現すべき重要な事項は、そのような全てのクライアント側スタブ方法においてコードの大半が同一であること、及び変更可能な部分を適切、簡潔に記述できることである。それらの観察によって、クライアント側スタブのインタプリタという概念が生まれた。
【００６１】
クライアント側スタブ方法の可変部分は先に肉太の字体で示されている。パラメータの型とモードはスタブ方法ごとに変化するが、識別オブジェクトは常に「any＿obj^* 」型であって、常に第１のパラメータである。異なるスタブ方法によって発生する例外は異なる場合もある。異なるパラメータは異なる方式でマーシャル化されなければならないが、ライブラリ型についてのマーシャル化方法は良く知られており、オブジェクトと構成型（array，struct など）のマーシャル化はその型についてのマーシャル化方法を呼出すことにより実行される。呼出しは、サブコントラクト方法を呼出すことによって実行される。この場合、スタブ方法間の唯一の変数は呼出し中の動作の識別である。アンマーシャル化はマーシャル化と全く同様に変化し、ライブラリ型についてはこれも同じように良く知られており、どのオブジェクト又は構成型もアンマーシャル化方法を呼出すことによりアンマーシャル化される。発生する必要のある例外はいずれもinvoke呼出しからの復帰コードとして符号化され、例外に対するパラメータのアンマーシャル化と例外の発生は１つの方法の中にカプセル化される。（しかしながら、例外に対するパラメータのアンマーシャル化と例外の発生は先にはインラインで生成されていたが、好ましい実施例ではそれを別個の方法にすることにより、Ｃ＋＋符号化スタブにあってもスペースを節約する可能性があることに注意する。）
【００６２】
クライアント側スタブのインタプリタ
Ｃ＋＋符号化スタブで観察された限定された可変性があれば、Ｃ＋＋符号化スタブの固定部分を本体とし且つ可変部分を記述するテーブルを参照し、その記述が与えられると、それに従って活動するインタプリタが設けられる。スペースの節約はテーブル駆動スタブインタプリタを使用することの第１の目的であったので、テーブルはできる限り実用的に形成されている。
【００６３】
スタブの記述は数種類の情報、すなわち、引数の型及びモードと、パラメータに関わるマーシャル方法及びアンマーシャル方法並びにそれらの方法を必要とする結果と、実行すべき動作の識別と、例外識別子から例外のパラメータをアンマーシャル化し且つその例外を発生させる方法へのマッピングとから構成されている。加えて、以下に詳細に説明するように、必要とされるデータは他にも様々ある。一連のスタブの記述はかなりの量の共通情報を含むので、１つのモジュール（動作の集合体である一連のインタフェース）に関わる記述は１つのテーブルにまとめられる。
【００６４】
好ましい実施例には、現時点で、スタブインタプリタが認識するcopy，share，consume，produce（「out」としても使用される），borrow，in，in＿out 及びreturnという９つのパラメータパスモードがある。スタブインタプリタが認識するパラメータ型はbool，octet，char，short，long，long long，unsigned short，unsigned long，unsigned long long，float，double，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 パラメータについて、スタブインタプリタはマーシャル化の後にパラメータをクリーンアップするための方法をも呼出さなければならない。そのパラメータに関わるデストロイヤのアドレスを記述中の、マーシャル方法の後に記憶する。struct，union又はbuiltinパラメータの記述における方法の実際の順序は、marshal＿consume，アンマーシャル化（おそらくはmarshal＿consume＋１でアクセスされる）、デストロイヤ（marshal＿consume＋２でアクセスされる）、イニシャライザ（un＿marshal ＋２でアクセスされる）となる。
【００６８】
好ましい実施例では、マーシャル化方法、アンマーシャル化方法、イニシャライザ方法又はデストロイヤ方法を呼出すためにスタブインタプリタが使用する方法アドレスについて検査を実行しない。スタブジェネレータは正しい方法を期待されたスロットに挿入し且つ正確に索引を充填しているものと仮定する。事実、スタブインタプリタは構成型のパラメータについてはmarshal＿consume方法と、marshal＿copy 方法とを区別しない。テーブル中の適切な方法の索引がスタブインタプリタに与えられると仮定する。
【００６９】
１つのモジュールによって発生する可能性のある全ての例外は、例外に対する引数をいずれもアンマーシャル化し且つその例外を発生させる方法のアドレスへの例外識別子から１つのマップに統合される。例外が発生したことをスタブインタプリタが検出すると、スタブインタプリタは例外識別子を求めてテーブルを探索し、例外を発生させるために対応する方法を呼出す。スタブインタプリタ自体から任意の例外を発生させるための方法は編成するのが困難であるので、スタブインタプリタ自体に例外を発生させる代わりに、方法呼出しを使用した。
【００７０】
再び図１１を参照すると、短縮をはかるため、モジュールを記述する様々なバイトとテーブルを連続して記憶してあるので、記述に対する１つの索引で、特定の動作呼出しについて必要とされる全ての情報を十分に発見できる。まず、テーブル中のエントリの数を接頭部として、アンマーシャル化などの方法２００のテーブルを記憶する。次に、同様にエントリの数を接頭部とする例外のテーブル２０２が続く。次に、実際の方法記述子自体２０４があり、各記述子は動作識別子である索引２０６から構成されており、これは動作記述から記述の前のテーブルに至るために使用される。その後に、動作のパラメータを記述するバイトと索引２０８が続く。それらのバイトはファンクションの復帰型の記述２１０を含む。必要に応じて、それらの記述子に４バイトの複数を充填させるために、各動作バイト群の後に空パディングが続く。各ファンクション記述は少なくともファンクションコード２０４と、（方法のテーブルをアクセスするために）記述の始めに戻るまでの距離２０６と、ファンクションの復帰型に関わる記述子２１０とを含む。未構成復帰値として３つまでの未構成引数をもつファンクションに対して、最小ファンクション記述子は１２バイトである。型がアンマーシャル化等の方法に対し索引を必要としないのであれば、索引を省略する。上記の例のＩＤＬインタフェースの記述は次の通りである：
【００７１】

【００７２】
好ましい実施例のインプリメンテーションの詳細
スタブインタプリタは主として簡明なＣ＋＋コードである。この章では、好ましい実施例で使用される詳細を説明する。
ＣＯＮＴＯＣＣがインタプリタを使用してクライアント側スタブを使用することを伝えられると、ＣＯＮＴＯＣＣは依然として呼出すべきクライアントに関わる方法を生成するが、その方法は単にスタブインタプリタを呼出すだけである。その方法の目的は、たとえば、クライアントに呼出しのための適正なＣ＋＋方法宣言を与えることにより、クライアントをインタプリタの存在から隔離することである。
【００７３】
多様復帰型
スタブインタプリタは、それが様々なＣ＋＋符号化スタブであるかのように、様々な型の結果を戻すことができなければならない。通常のＣ＋＋コードは戻すと宣言されている型しか戻せない。好ましい実施例では、本発明が一部を成しているＳＰＲＩＮＧオペレーティングシステムは、ＳＰＡＲＣ（登録商標）アーキテクチャベースシステムでランするように設計されている。ＳＰＡＲＣはＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌの登録商標であり、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が開発したＲＩＳＣコンピュータに基づく「Ｓｃａｌａｂｌｅ Ｐｅｒｆｏｒｍａｎｃｅ ＡＲＣｈｉｔｅｃｔｕｒｅ」の頭文字である。ＳＰＡＲＣアーキテクチャでは、様々な異なる型の結果を戻すための規約はそれらの結果を様々な異なる場所（たとえば、大半の結果に対するレジスタ、他の結果に対する事前割当てメモリなど）に導入することを要求する。（付録Ｄ「Ｓｏｆｔｗａｒｅ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」，Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ第８版，Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，１９９２年刊，ＩＳＢＮＯ−１３−８２５００１−４参照。）多様復帰を実行するために、スタブインタプリタは少数のアセンブラ方法に依存する。それらの方法は様々な種類の復帰結果をパラメータとして取上げ、それらを従来通りの復帰結果用の場所に導入する。それらの方法は実際にはインライン化されているが、レジスタウインドウ又はスタックフレームを割当てないので、インタプリタ自体のレジスタとスタックフレームをアクセスすることができる。
【００７４】
多様バリアディック，パラメータ型
スタブインタプリタはＣ＋＋符号化スタブに渡されるであろうパラメータと同じパラメータをアクセスしなければならない。インタプリタは、クライアント側スタブに渡されるパラメータの数又は型をあらかじめ知ることはできない。加えて、インタプリタは呼出し中の方法に関わる動作記述の中の適切なエントリに対するポインタを獲得しなければならない。好ましい実施例では、それらの問題は、共に、クライアントが呼出すＣ＋＋方法からスタブインタプリタへの１種のテール呼出しによって解決される。
【００７５】
上記の例のインタフェースのクライアントは、次のように定義される方法を呼出すであろう。

【００７６】
復帰ステートメントの目的は、できる限り少ないコードを生成しつつ、この方法に対するパラメータをコードの第１行を通して生き状態に保持することである。復帰ステートメントには決して到達しない。（すなわち、全てのことは計画に従って進行する。その行に達してしまうと、システムはパニックを起こす。）コードの第１行はスタブインタプリタ自体へ制御を移行し、呼出すべき動作に関わる記述のアドレスをそれに渡す。
【００７７】
スタブインタプリタに制御が移行されると、クライアント側スタブに対する引数（識別オブジェクトなどを含む）は、初めのいくつかのイン・レジスタ内又は通常のＳＰＡＲＣ呼出し規約における呼出し側のフレーム内にある（先に挙げたＳＰＡＲＣアーキテクチャマニュアルの付録Ｄを参照）。動作に関わる記述のアドレスは第１のアウト・レジスタにある。尚、この好ましい実施例においては、クライアント側スタブに対する引数の１つのレジスタウインドウから次のレジスタウインドウへのコピーを回避している。イン・レジスタから引数を失わないようにするために、スタブインタプリタは新たなレジスタ／メモリフレームを割当てない。その代わりに、インタプリタの局所変数に対する要求に応じてクライアント側スタブのメモリフレームを拡張する。（レジスタフレームを押さないメモリフレームの拡張は、Ｃ＋＋コンパイラにスタブインタプリタのアセンブラコードを生成させ且つインタプリタ方法に関わるセーブ命令を加算命令に変更することによって実行される。）アウト・レジスタから動作記述のアドレスを失わないようにするために、スタブインタプリタが実行する第１の事柄はそのアドレスを局所レジスタ変数にコピーすることである。このように、スタブインタプリタでは通常のレジスタの引数をもってランしており、１回の飛越し、１回の加算及び１回のレジスタコピーの中で動作記述のアドレスを渡している。スタブインタプリタはクライアント側スタブのレジスタフレームでランしているので、多様復帰値を戻す方法はスタブインタプリタから直接にクライアントコードに戻す（すなわち、クライアント側スタブでパニックを起こすことはない）。
【００７８】
好ましい実施例では、スタブインタプリタは、記述データベース中のバイトコードからどのような型であるかを見出すときに、クライアント側スタブに対する引数をアクセスしなければならない。クライアント側スタブに対する引数をもってインタプリタが実行する第１の事柄は、引数をイン・レジスタからクライアントの（呼出し側）のフレームで引数用として割当てれられているスペースにコピーすることであるので、引数をメモリで渡された引数と共に順次アドレス指定することができる。インタプリタは様々なＣ＋＋要素を渡すための標準規約（たとえば、structs は参照により渡されるなど）と、様々なＩＤＬパラメータパスモードに関わる規約（たとえば、borrowパラメータは参照により渡されるなど）とを処理するように設計されている。そのようにして、インタプリタは、バイトコード記述を処理するときに、クライアント側スタブに対する引数を適切にアクセスできるのである。
【００７９】
インタプリタ自体はバイトコード記述にわたる本質的には２つのループである。第１のループは、何らかの引数のマーシャル化を要求するか否かを知るために、各バイトコードを検査する。次に、識別オブジェクトについて指示された動作を呼出し、復帰コードを検査する。その動作が成功したならば、バイトコード記述にわたる第２のループは、いずれかの結果がアンマーシャル化を必要とするか否かを判定する。この第２のループが動作のreturn型を記述するバイトコードを検査するとき、インタプリタからクライアントに戻すために適切な多様復帰方法を呼出す。動作呼出しが失敗であった場合には、復帰コードを使用して、適切な例外に対するパラメータをアンマーシャル化し且つその例外を発生させる方法へマッピングする。
【００８０】
サーバ側スタブに関わるインタプリタの構成に伴なう概念上の問題はない。ところが、いくつかの理由によって、好ましい実施例ではこれを実行しなかった。
【００８１】
ドメインは多数のサービスの１クライアントであっても良いが、典型的にはごく少数のサービスに対するサーバである。そのため、ドメインはクライアント側スタブを数多く必要とするであろうが、サーバ側スタブについては若干のスタブを必要とするだけであろう。従って、クライアント側スタブが占めるスペースを縮小する場合と比べて、サーバ側スタブが占めるスペースの縮小のもたらす利点は相対的に少ないであろう。
【００８２】
ＳＰＡＲＣにおける通常の呼出し規約を越えるＣ＋＋コンパイラの規約の知識を余りに多くもつ必要なく、クライアント側スタブの呼出し環境を理解することは可能であった。これに対し、サーバ側スタブは、典型的にはＣ＋＋vtables を介して、サーバ方法のインプリメンテーションを呼出さなければならない。vtableディスパッチはＣ＋＋コンパイラのライターの思いつきの影響のみを受けるので、特定のＣ＋＋インプリメンテーションに結合することが望ましいとは思わなかった。
【図面の簡単な説明】
【図１】 従来の技術におけるクライアントアプリケーション及びサーバアプリケーションと、スタブ及びネットワークソフトウェアとの関係を示す図。
【図２】 スタブジェネレータ／インタプリタの主要なシステムコンポーネントを示す図。
【図３】 スタブオブジェクトと、サブコントラクトオブジェクトと、サーバアプリケーションオブジェクトとの関係を示す図。
【図４】 サブコントラクトを使用する遠隔オブジェクト呼出しを示す図。
【図５】 サブコントラクトを使用する単一の機械におけるオブジェクト呼出しを示す図。
【図６】 本発明によるサブコントラクトの方法の使用例を示すフローチャート。
【図７】 本発明によるサブコントラクトの方法の使用例を示すフローチャート。
【図８】 本発明によるサブコントラクトの方法の使用例を示すフローチャート。
【図９】 本発明によるサブコントラクトの方法の使用例を示すフローチャート。
【図１０】 ＳＰＲＩＮＧによるオブジェクトの見方と、従来の技術によるオブジェクトの見方とを対比して示す図。
【図１１】 クライアント側スタブ記述のレイアウト例を示す図。
【符号の説明】
１０…機械Ａ、１２…クライアントアプリケーション、１４…クライアント側スタブ、１６，２０…ネットワークソフトウェア、１８…機械Ｂ、２２…サーバ側スタブ、２４…サーバアプリケーション、３０…クライアント側サブコントラクト、３２…サーバ側サブコントラクト、３６…オペレーティングシステム、１５０…インタフェース定義言語、１５２…クライアント側スタブジェネレータ、１５４…Ｃ＋＋スタブコード、１５６…データベース、１５８…クライアント側スタブインタプリタ、１６６…限定スタブコード、１６８…引数、１７０、１７２…コンピュータメモリ。

Claims (8)

1. 共通部分と独自部分を含むコードによって定められたスタブ動作を複数有しており、前記共通部分は各スタブ動作を実行するために必要なコードを有し、前記独自部分は前記複数のスタブ動作のそれぞれの動作を定めるコードを有しており、前記共通部分を格納する第１領域と前記複数の独自部分を格納する第２領域とを有するメモリを備えたコンピュータシステムにおいて、複数のスタブ動作の内、クライアントにより呼出された特定のスタブ動作を実行する方法において、
   スタブ動作を実行するために生成されたコードを受けたスタブジェネレータが、前記独自コード部分を取り出して前記コンピュータメモリの第２の領域に格納する過程と、
   前記特定のスタブ動作を実行させるために、前記第２の領域に格納された前記独自コード部分を指すポインタを含む要求を前記クライアントがスタブインタプリタに発行する過程と、
   前記スタブインタプリタが、前記特定のスタブ動作を実行するために、前記第１の領域に格納されたスタブ動作に関する共通コード部分と、前記発行された要求のポインタに基づいて前記コンピュータメモリの第２の領域に格納された前記特定のスタブ動作に関する独自コード部分とを呼び出す過程と、
   から成り、
   それにより、クライアント側スタブに要求されるコンピュータメモリスペースの量を減少させる方法。
2. コンピュータシステム内でクライアントにより呼出された特定のスタブ動作を実行する方法において、
   スタブ動作を実行するために生成されたコードを受け取ったスタブジェネレータが、当該コードを、複数のスタブ動作に共通するコードであって各スタブ動作を実行するのに必要なコードの第１の部分と、前記複数のスタブ動作のそれぞれの動作内容を定めるコードであって各スタブ動作に独自のものであるコードの第２の部分とに分割し、且つ前記コードの第２の部分をコンピュータメモリに記憶する過程と、
   前記コードの第１の部分のコピーを包含するスタブインタプリタによって実行される過程であって、
   前記スタブインタプリタは、前記コンピュータメモリから呼び出すべきスタブ動作に関するポインタを含んだクライアントからのスタブ動作の呼び出しを受けるものであり、その呼び出しを受けるたびに、
   （１）前記コードの第１の部分を供給する過程と、
   （２）前記スタブ動作に関するポインタに基づいて、前記コードの第２の部分をアクセスして取得する過程と、
   （３）前記第１、第２の部分のコードを実行して、スタブ動作を実行するためのサブコントラクトを呼び出す過程と
   を実行する過程と
   から成る方法。
3. クライアント側スタブに要求される前記コンピュータメモリスペースをさらに縮小するために、前記スタブジェネレータが前記コードの第２の部分を圧縮する過程を含む請求項２記載の方法。
4. 各々がクライアント側スタブを呼出しうるクライアントアプリケーションを実行可能な複数のデータ処理システムで使用するために、クライアント側スタブに対するクライアント動作呼出しを実行する方法において、
   スタブジェネレータによって、スタブ動作を実行するために生成されたコードを、複数のスタブ動作に共通するコードであって各スタブ動作を実行するのに必要なコードの第１の部分と、特定のスタブ動作の動作内容を定めるコードであって当該特定のスタブ動作に独自のものであるコードの第２の部分とに分割し、かつ前記コードの第２の部分を圧縮して圧縮スタブコードを生成してメモリに記憶する過程と、
   前記コードの第１の部分のコピーを包含するスタブインタプリタによって実行される過程であって、
   前記スタブインタプリタは、前記メモリから呼び出すべきスタブ動作に関するポインタを含んだクライアントからのスタブ動作の呼び出しを受けるものであり、このクライアントからのスタブ動作の呼び出しを受けるたびに、
   （１）前記コードの第１の部分を供給する過程と、
   （２）前記コードの第２の部分を前記ポインタに基づきアクセスして取得し、前記供給された前記第１の部分のコードと当該第２の部分のコードとに基づき、前記呼び出すべきスタブ動作を実行する過程とから成り、
   それにより、クライアント側スタブの記憶装置に要求されるメモリスペースを縮小する方法。
5. クライアント側スタブ動作を実行するシステムにおいて、
   前記クライアント側スタブ動作を実行するために生成されたコードを複数のスタブ動作に共通するコードの第１の部分と、前記複数のスタブ動作の中の特定の１つのスタブ動作に独自のものであるコードの第２の部分とに分割する手段と、
   前記共通するコードの第１部分を保持するとともに、クライアントからのスタブ動作要求を受けるスタブインタプリタと、
   前記複数のクライアント側スタブ動作に独自のものであるコードの第２の部分を保持するよう構成された記憶手段と、
   を備え、
   前記スタブインタプリタは、前記記憶手段の前記コードの第２の部分を指すポインタを、前記クライアントからの特定のスタブ動作要求により受け取り、前記記憶手段から該ポインタに基づき当該特定スタブに関する独自のコードを取り出し前記コードの第１部分と合わせて実行させてスタブ動作を実行するためのサブコントラクトを呼び出し、
   それにより、クライアント側スタブ動作に関わるコードを記憶するために使用されるメモリスペースを縮小するシステム。
6. 前記分割する手段は、前記コードの第２の部分を圧縮して生成した圧縮スタブコードを前記記憶手段に送ることを特徴とする請求項５記載のシステム。
7. コンピュータでクライアントにより呼出される特定のスタブ動作を実行するシステムであって、各々が複数のスタブ動作に共通するコードの第１の部分と、前記特定のスタブ動作のそれぞれに独自のものであるコードの第２の部分とを含んでいるクライアント側スタブについて要求されるコンピュータメモリスペースを最小限に抑えるシステムにおいて、
   前記クライアント側スタブ動作を実行するために生成されたコードを複数のスタブ動作に共通するコードの第１の部分と、前記複数のスタブ動作の中の特定の１つのスタブ動作に独自のものであるコードの第２の部分とに分割し、該分割したコードの第２の部分をコンピュータメモリに記憶する手段と、
   前記特定のスタブ動作を実行させるために、当該特定のスタブ動作に関するコードの第２の部分を指すポインタをともなって当該特定のスタブ動作を呼び出す要求をスタブインタプリタに発行する、前記クライアントに設けられた手段と、
   を備え、
   前記スタブインタプリタは、前記コードの第１の部分のコピーを包含し、前記特定のスタブ動作を呼び出す要求を受け取るたびに、前記コードの第１の部分を供給するとともに、前記ポインタに基づき前記特定のスタブ動作に関する第２のコード部分を前記記憶する手段から呼び出して、さらに前記第１、第２のコード部分を実行してスタブ動作を実行するためのサブコントラクトを呼び出し、
   それにより、クライアント側スタブ用として要求される前記コンピュータメモリスペースを縮小するシステム。
8. 前記記憶する手段は、前記分割されたコードの第２の部分を圧縮した圧縮スタブコードを記憶する請求項７記載のシステム。

Images