JPH08504975A - 分散型コンピュータシステムにおける遠隔手続き呼出しを実行するための方法およびシステム - Google Patents

Abstract

(57)【要約】 分散型コンピュータシステムにおいて遠隔手続き呼出しを実行するためのシステムおよび方法は、すべての分散オブジェクトが派生可能な基礎オブジェクトクラス（図１（1）および図１（2））を提供する。前記基礎クラスから派生するすべてのクラスを抽出するプログラムは、ルートクラスから基礎クラスへのダウンキャストを可能にし、遠隔手続き呼出しの参加者の間において高レベル構造を伝送することを可能にするための継承の木（図３ａ）を提供する。UNIXスクリプトは、クライアント・サーバー型通信処理を実行するためのスタブルーチン（図７ａおよび図７ｂ）を提供する。

Description

【発明の詳細な説明】 分散型コンピュータシステムにおける 遠隔手続き呼出しを実行するための方法およびシステム 発明の背景 １．発明の分野 この発明は、分散型コンピュータシステムに関し、特に、分散型コンピュータ システムにおける遠隔手続き呼出しメカニズムの使用に関する。 ２．関連技術の説明 分散型コンピュータシステムにおいては、該システムにおける多数のコンピュ ータ間で資源（例えばファイルシステム）を共用することによって効率を高める ことが可能である。さらに、このようなシステムにおいては、多数のコンピュー タを、共通のタスクを実行するために相互に共働するよう使用可能である。これ らのコンピュータが共働する、または、資源を共用するようにするネットワーク を構成するための通信技術が多数開発されてきた。これらの通信技術の一例とし ては、“クライアント・サーバーモデル”がある。該クライアント・サーバーモ デルにおいて、１つまたは複数のコンピュータ（“サーバー”）は、該サーバー にメッセージを送ることによって、または、遠隔手続き呼出しを実行することに よって当該分散型コンピュータシステムの他のコンピュータ（“クライアント” ）が要求するサービスを提供するよう指令される。また、このクライアント・サ ーバーモデルにおいて、前記クライアントはサービス要求を出し、前記サーバー はこのサービス要求に応答する。 遠隔手続き呼出しは、１つのコンピュータの処理スペースで実行されるプログ ラムによって、他のコンピュータ（遠隔コンピュータ）の処理スペースで手続き が実行されるようにするためのメカニズムである。前記クライアント・サーバー 技術の１つの実施例においては、クライアント処理によって、サーバー処理で前 記要求されたサービスを始動させるための遠隔手続き呼出しを実行する。前記サ ーバー処理の便利な実施例は、デーモン（daemon）処理である。このデーモン処 理は、他の処理からメッセージを受け取り、一端スタートしたならば、“キル（ kill）”メッセージを他の処理から受け取り、タイマが休止するまで、または、 すべての予期されるメッセージを受け取るまで、該コンピュータに滞在するコン ピュータ処理である。このようなデーモン処理は、共用資源を管理するために使 用される。例えば、印刷待ち行列のためのデーモン処理は、前記印刷待ち行列に 係る１つまたは複数のプリンタの使用を必要とする処理からメッセージを受け取 る。印刷処理を実行する際、要求処理が前記デーモン処理に対して印刷要求を送 り、該デーモン処理は、前記印刷要求が適切である場合、該印刷要求を満たすた めに、必要な印刷処理の準備を行い、そのスケジュールを作成する。プリンタご との情報を必要とするタスクは前記デーモン処理に割り当てられ、前記要求処理 からアンロードされるので、前記デーモン処理は効率を高める。該デーモン処理 は、要求処理からのメッセージを待っている間“睡眠中（sleeping）”であると 言われ、割り当てられたタスクを実行している時には“目覚めている（awaken） ”と言われる。 現在のソフトウエアは、モジュール化およびデータ抽象化の利点を利用するよ う設計されている。モジュール化は、定義された機能上のインターフェースにお いて、複雑なシステムを相互に関連したサブシステムに区分する。このようにし て、各サブシステムの実行上の複雑さは、他のサブシステムから隠され（見えな いようにされ）、従って、他のサブシステムとは独立に、大いに開発、変更され ることができる。 また、データ抽象化は、そのデータが示すオブジェクトについての論理的また は概念的な表示である高レベルデータ構造を使用することによって、プログラミ ングタスクを簡略化する。こうして、データ抽象化によって、プログラマは、デ ータを原始的なデータ型の集まりとして処理する代りに、概念的なレベルで処理 することができる。 理想的には、適当なモジュール化によって、適用業務プログラマは、どのよう にサービスが提供されるのか、または、サービス提供者がどこに位置しているの かについての複雑な知識無しに、印刷ジョブのステータスを要求するなどの、オ ペレーティングシステムのサービスを実行することができる。さらに、応用プロ グラムの高レベルデータ構造をより低い原始データ構造に分解することなしに、 該応用プログラムが他のプログラムに干渉することができるようにするためには 、高レベルデータ構造サポート手段を設ける必要がある。 分散型コンピュータは広く使用されているが、データ抽象化およびモジュール 化の目的に反して、遠隔手続き呼出しは言語独立型のフレームワークで実施され る。その結果、比較的低レベルのデータ構造を、遠隔手続き呼出しに関与するコ ンピュータ処理の間で伝送することができ、これにより、適用業務プログラマが 、特別に、分散されたオブジェクトを処理することが必要になる。このような必 要性は、モジュール化を挫折させる。 さらに、高レベルデータ構造の通信を行うための適当なメカニズムが入手不能 であるので、マシーンの境界を越えてデータ通信を行うのに必要な低レベルデー タ構造を作成するために、応用プログラムのデータ構造は、しばしば、該応用プ ログラムにおいて明確に分解される。従って、このような応用プログラムの軽便 性および確実性に影響が出る。 以上のような理由により、応用プログラムを遠隔手続き呼出しのために準備す る必要性から絶縁するには、高いレベルの抽象化が望まれる。例えば、遠隔手続 き呼出しは、適用業務プログラマに見えないようにする必要がある。すなわち、 前記メカニズムは、応用プログラムの特定のデータ構造が遠隔のマシーンによっ て制御される資源に基づいて実施されまたは該資源に依存すべきという認識また は必要性無しに、前記応用プログラムが書込まれるのを可能にする。 発明の概要 この発明に従うと、高レベルデータ構造をサポートする遠隔手続き呼出し構造 および方法は、共通のデータ構造すなわちクラス（“基礎（base）”クラス）の 使用によって提供される。分散オブジェクトまたは共用オブジェクトを得るため に共用データ構造を使用することによって、遠隔手続き呼出しのためのクライア ントスタブルーチンおよびサーバースタブルーチンの両方を自動的に発生するた めプリプロセッサを構築することができる。サーバールーチンを呼出す応用プロ グラムは、同じデータ構造をローカルルーチンに送るのと同様に、サーバールー チンの高レベルデータに送られることができる。 この発明の一実施例において、前記サーバーは、システム初期化時にデーモン 処理として創造される。該サーバーは、１つまたは複数の遠隔手続き呼出しクラ イアントオブジェクト（“RpcClients”）を受入れ可能な遠隔手続き呼出しサー バーオブジェクト（“RpcServer”）を作り出す。前記クライアントにおいて作 り出されるRpcClientは、前記サーバー側のRpcServerと前記クライアントとの間 の通信チャンネルを提供する。さらに、RpcC1ientは、前記サーバー側と前記ク ライアントとの間の非同期通信を提供するために、前記サーバー側に作り出され る。 RpcClientオブジェクトが前記クライアントにおいて作り出されると、“マニ フェスト（伝送目録）”がRpcServerに送られ、該RpcServerは、前記RpcClient に対して自分自身のマニフェストを送ることによってこれに応答する。前記マニ フェストは、対応するサーバーまたはクライアント内の各クラスのクラスメタ情 報を含んでいる。このような各クラスごとのクラスメタ情報は、（i）そのクラ スを示す“型（type）コード”、（ii）そのクラスの名前、（iii）基礎クラス の数、および、（iv）もし存在すれば、そのクラスの派生源であるすべてのクラ スの名前を含むものである。さらに、前記マニフェストは、各共用オブジェクト ごとに、（i）前記共用オブジェクトの型コード、および、前記マニフェスト送 り側の環境における共用オブジェクトのリストへのインデックスを提供する。前 記リストは、各共用オブジェクトごとに、該共用オブジェクトへのポインタを提 供する。 分散オブジェクトまたは共用オブジェクトは、サーバーで実行されるマスター オブジェクト（“マスター”）と、クライアントで実行される１つまたは２つ以 上のスレイブオブジェクト（“スレイブ”）との組合わせによって実現される。 前記マスターとスレイブとは、同一の共通基礎クラスから派生する。前記マスタ ーと各スレイブとは異なるメモリスペースに存在するので、前記マスターと各ス レイブとの通信を維持するために、前記マスターには、遠隔手続き呼出しがスレ イブのメモリスペース内の前記スレイブへのポインタを得ることができるように するキーが与えられ、各スレイブには、マスターメモリスペース内の前記マスタ ーへのキーが与えられる。このようにして、遠隔手続き呼出しは、遠隔オブジェ クトが該遠隔オブジェクトへのキーだけを送った時に、動作可能になる。 この発明は、スレイブが前記遠隔手続き呼出しの返りに応答することを要求す ることによって、ローカル手続き呼出しの意味（semantics:セマンティクス）を 保存する。また、ローカル手続き呼出しの意味は、（i）例外（異常）を前記サ ーバーメモリスペースにトラップし、（ii）前記異常をクライアントに戻すエラ ー処理メカニズムによっても保存され、こうして、（iii）前記クライアントは 、前記異常をソフトウエアの適切なレベルに戻して処理する。前記応用プログラ ムにおいて、前記遠隔の異常は、ローカルに実行される手続きによって発生する 異常とは全く異ならないように見える。 １つの実施例において、RpcClientsは、サーバーがマスターオブジェクトのス レイブと通信できるよう、前記サーバーにおいても作り出される。該実施例にお いて、メッセージを前記スレイブに送るためのメッセージデーモンは、前記サー バーによって作り出される。各スレイブは、マスターに対して、前記サーバーの RpcClientsを介して前記クライアントに与えられ該スレイブへのポインタに翻訳 されるキーを提供する。前記スレイブへのポインタは、前記スレイブが前記メッ セージデーモンからのメッセージを受け取るためのメソッドを呼出すために使用 可能である。 さらに、この発明によると、自動プログラムは、分散オブジェクト内のメソッ ドを呼出すためにクライアントスタブルーチンおよびサーバースタブルーチンを 発生する。 この発明は、Ｃ＋＋クラスのような比較的高いレベルのデータ構造のコンテキ スト内の分散オブジェクトに対するサポートを提供し、ローカル呼出しの意味を 保存するので、分散オブジェクトは、適用業務プログラマに見えない方法で実行 可能であり、これにより、前記分散オブジェクトの頑強性および保存性を向上さ せる。また、この発明は、分散型コンピュータシステムを制御するために使用さ れる応用プログラムを簡略化する。 この発明は、下記の詳細な説明および添付図面を考察することによって、より 明確に理解されるであろう。 図面の簡単な説明 図１は、この発明の一実施例におけるクラスShareThang、ShareThangIdおよび RemoteIdの宣言を示す図。 図２は、この発明の一実施例におけるサーバー処理およびクライアント処理の 処理スペースを示すブロック図。 図３ａは、マクロ命令GIFTS_DECLARおよびプログラムGenTYPEを使用して継承 の木を作成するステップを示ブロック図。 図３ｂは、この発明に従って継承の木を提供するために使用されるプログラム GenTypeから＿magic＿を抽出するスクリプトファイルchomp.cppのリストを示す 図。 図４ａは、デーモン処理Sectdを実行するプログラムを示すブロック図。 図４ｂは、この実施例のサーバー処理Sectdにおいて実行されるプムグラムセ グメントSectd.Cのリストを示す図。 図４ｃは、Sectdの手続きを呼出すために遠隔手続き呼出しメカニズム（ＲＰ Ｃ）２０４によって呼出されるルーチンSectdProg_1のリストを示す図。 図５は、この実施例におけるSectd処理とそのクライアントとの間における通 信を行うために使用されるクラスRpcServerのオブジェクトの作成を示すブロッ ク図。 図６ａおよび図６ｂは、それぞれ、クラスSectC1ientControllerのオブジェク トを実行するプログラムコードのブロック図、および、前記プログラムコードの リストを示す図。 図７ａおよび図７ｂは、SectClientControllerおよびSectdにおいて分散オブ ジェクトSectControllerを実行するマスタオブジェクトおよびスレイブオブジェ クトのためのozスクリプトによって発生されるスタブルーチンSectController:: startTesterおよびrStartTesterのブロック図。 図８は、SectにおいてクラスSectControllerを実際に実行するためのファイル SectController.Cにおけるソースコードを示す図。 図９ａおよび図９ｂは、それぞれ、図７ａおよび図７ｂのブロック図に示すよ うに、クラスStartTesterに応じてozスクリプトによって発生されるスタブルー チンセグメントSectController::startTesterおよびrStartTesterを示す図。 図１０は、この発明に従って、クライアント処理およびサーバー処理用のスタ ブルーチンを発生するためのスクリプトファイルozを示すブロック図。 図１１は、図１０のozスクリプトに入力される仕様ファイルの一例を示す図。 付録Ｃは、プログラムGenTypeのリストを示す図。 付録Ｄは、スクリプトファイルozのリストを示す図である。 好ましい実施例の詳細な説明 本発明は任意のプログラム言語を使用する任意の分散型コンピュータシステム に使用可能であるが、この詳細な説明においては、“Ｃ＋＋”プログラム言語を 使用する実施例について説明する。Ｃ＋＋プログラム言語については、Addison and Welsley社によって１９９０年によって発行されたEllisおよびStroustrup著 、“An Annotated C++ Reference Manual”を参照されたし。また、この実施例 において、UNIXオペレーティングシステムで実行される周知のテキスト処理プロ グラムである“awk”を使用してプログラムセグメントを発生する。前記awkおよ びその他の同様なテキスト処理プログラムは、当業者によく知られている。前記 awkについての説明は、カルフォルニア州、Mountain Viewに在るSun Microsyste msから入手可能な、1990年発行の“SunOS Reference Manual Release 4.1”のSe ction１になされている。 以下の記載および添付した図面においては、多重定義された関数および演算子 の名前に関するＣ＋＋プログラム言語での名前は、これらに対応する、いわゆる “ネーム・マングリング・ルール”に従うＣプログラム言語の署名コード化ネー ム（“マングル化された（mangled）名前”）と相互交換可能に使用される。当 業者はマングル化された名前とマングル化されていない名前（unmangled name） との間の対応関係を理解すると思うので、ネーム・マングリングについての詳細 説明を省略する。前記ネーム・マングリング・ルールについての説明は、上記An Annotated C++ Reference Manualにも見られる。 この発明は、遠隔手続き呼出しをサポートするすべての分散型コンピュータシ ステムに適用可能である。このようなシステムの一例は、上記カルフォルニア州 、 Mountain ViewのSun Microsystemsから入手可能なNFS（ネットワーク・ファイル ・システム）におけるコンピュータネットワークである。この発明の１つの用途 は、カルフォルニア州、Cupertinoに在るTandem Computers Inc.のGiftsプロダ クトに見られる。このGiftsの下において、遠隔のマシーンのハードウエアコン ポーネントを制御し、診断し、構成するために、応用プログラムが使用される。 フォールトトレラント（耐故障性）環境において、この発明は、物理的なアクセ スおよびサービスの中断無しに、前記Giftsプロダクトがハードウエアを制御し 、ハードウエアコンポーネントの付加およびサービスからの除去、ならびに、ハ ードウエアの再構成を制御するのを可能にするものである。 以下の記載において、“オブジェクト”とは、典型的には、“属性”および“ メソッド”からなるデータ構造である。前記属性は、オブジェクトに関連するデ ータ構造と言える。このようなデータ構造の一例は、ある値（例えば、整数）の アレイ、または、オブジェクトのステート情報を表すのに有用なステート変数で ある。前記メソッドは、オブジェクトに関連する意味ある行為を実行するのに有 用な１つまたは複数の命令からなる。手続き型プログラミング言語で実行される 場合、前記メソッドは、典型的には、演算子または手続きによって表される。 さらに、各オブジェクトは、１つまたは複数のクラスに属する。１つのクラス 内のすべてのオブジェクトは、同一の属性およびメソッドの組を有するという点 で、互いに似たものである。オブジェクトの各クラスは、他のクラスのオブジェ クトを定義するために使用可能である。派生クラスは、“親”クラスから該親ク ラスの属性およびメソッドを継承したものであり、さらに、該派生クラスのため に定義された、または、親クラスのものを変更した属性およびメソッドを含む。 この階層において、１つまたは複数の他のクラスの派生源となるクラスを、“基 礎”クラスという。 この発明の一実施例は、すべての分散オブジェクトの派生源となる基礎クラス ShareThangを提供する。このShareThangのクラス定義およびその実行は、付録Ａ のファイルShareThang.CおよびShareThang.hに見られる。前記クラスShareThang は、（i）クラスShareThangIdのオブジェクトへのポインタである属性stid、お よび、（ii）クラスClassInfoのオブジェクトへのポインタである属性commonTyp eを有する。前記属性stidは、現在の処理スペースにおけるすべての共用オブジ ェクトのリスト（“shared object list”）にアクセスするオブジェクトShareT hangIdを示す。各共用オブジェクトに関し、該共用オブジェクトがマスタである 場合、そのShareThangIdは、前記共用オブジェクトのスレイブ（“slave”）の リストを維持する。一方、前記共用オブジェクトがスレイブである場合、ShareT hangIdは、前記共用オブジェクトのマスタ（“master”）のリストを維持する。 ClassInfoオブジェクトは、（i）そのクラス（“インスタンスクラス”（inst ance class））を特定する“型コード”であるtype、（ii）インスタンスクラス を特定する文字列であるname、（iii）もし存在する場合には、インスタンスク ラスの継承源である基礎クラスの数であるnbases、（iv）インスタンスクラスの 基礎クラスの１つに対応する、クラスClassInfoの１つのオブジェクトを示すポ インタのアレイであるbases、および、（v）クラスXdrBufferのデータバッファ によるコンピュータ間の送信に適した中立的なデータフォーマットに対して、イ ンスタンスクラスのオブジェクトをエンコードまたはデコードするために提供さ れるポインタであるxdr、からなる属性を有する。 さらに、クラスClassInfoは、（i）１つのオブジェクトのポインタを、同じル ートクラスに含まれる他のオブジェクトのポインタに交換するために使用可能な メソッドCastDown、（ii）１つのオブジェクトのクラスに対応するClassInfoを 返すメソッドtypeまたはget、（iii）そのオブジェクトのクラスの名前を戻すメ ソッドnameof、および、（iv）継承の木（下記を参照）におけるすべてのノード を訪問するメソッドtraverseを含む。ClassInfoのクラス定義およびその実行は 、付録Ｂに含まれるClassInfo.hおよびClassInfo.Cに見られる。この実施例にお いて、クラスClasslnfoのオブジェクトは、（i）各サポートされたデータ型（例 えば、整数、実数等）、（ii）各宣言されたクラス、および、（iii）各宣言さ れたクラスに関連するポインタタイプ、ごとに創造される。 ShareThangIdにおいて、slaveおよびmasterの各々は、クラスRemoteIdのオブ ジェクトによって表される。各RemoteIdは、遠隔環境における共用オブジェクト の対応物（つまり、“ツイン（twin）”）を特定する。例えば、サーバー（すな わち、マスタ）における共用オブジェクトのツインは、RemoteIdオブジェクトの リストslaveを有し、各RemoteIdオブジェクトはマスタのスレイブの１つに対応 する。逆に、クライアント（すなわち、スレイブ）における共用オブジェクトの ツインは、前記スレイブのマスタに対応するRemoteIdオブジェクトmasterを有す る。各RemoteIdオブジェクトは、クラスRpcClientのオブジェクトへのポインタ と、ShareThangIdの共用オブジェクトのリストへのポインタを有する。前記サー バーおよびクライアントのShareThangIdは異なる共用オブジェクトリストを有す るので、同一の共用オブジェクトは、前記サーバーおよびクライアントの共用オ ブジェクトリストにおいて異なるインデックスを有する。後で詳述するように、 RpcClientは、マスタとスレイブとの間の通信チャンネルを特定する。 図１は、クラスShareThang、 ShareThangIdおよびRemoteIdの宣言を示す。ク ラスShareThangは、（i）前記属性stidを返すメソッドid()、（ii）ShareThang のマスタのRemoteIdを返すメソッドmasterid()、（iii）ClassInfoのクラスのオ ブジェクトであるcommonTypeを返すgetCommonType()を提供する。また、クラスS hareThangIdは、スレイブに対応するRemoteIdをマスタのリストSlaveに付加する ため、および、マスタに対応するRemoteIdをスレイブに付加するための、メソッ ドaddClientおよびaddMasterを提供する。 この実施例において、遠隔手続き呼出しは、遠隔手続き呼出しメカニズムにメ ッセージおよび手続き番号を与える遠隔手続き呼出し関数executeを実行するこ とによって行われる。前記手続き番号は通信プログラム間の接続を特定し、前記 メッセージはクラスXdrBufferのバッファ（“message”）に含まれている。XdrB ufferの定義および実行は、付録ＢにリストされたファイルXdrBuffer.hおよびXd rBuffer.Cに含まれている。クラスThang（ShareThangの派生源）から派生したオ ブジェクトをメッセージにエンコードし、メッセージからデコードするために、 前記オブジェクトのクラスのClassInfoオブジェクトにおけるメソッドxdrが、ク ラスインプリメンタ（クラス作成者）によって提供される。 この実施例のメッセージにおいて、エンコードされたオブジェクトは、フィー ルドとして、（i）該エンコードされたオブジェクトのサイズをバイトで示すbyt e_countと、（ii）subrecordのリストを有する。また、各subrecordは、フィー ルドとして、（i）内句されたオブジェクトの型コードであるtype_tag、（ii）s ubrecordのサイズをバイトで示すbyte_count、（iii）原始データ構造のリスト であるprimitive、および、（iv）subrecordのリストを有する。 図２は、この発明の一実施例におけるサーバーマシーンおよびクライアントマ シーンの処理スペースを示す。サーバーマシーン２００において、遠隔手続き呼 出し（ＲＰＣ）メカニズム２０４は、他の応用プログラムのために、該サーバー マシーン２００のカーネル２５０における低レベル、マシーン内通信サービスに アクセスするための遠隔手続き呼出しインターフェイスを提供する通常の応用プ ログラムである。同様に、遠隔手続き呼出しメカニズム２０３は、他の応用プロ グラムがカーネル２５１のマシーン内通信サービスにアクセスするための通常の 応用プログラムである。典型的には、遠隔手続き呼出しメカニズム２０３、２０ ４などの遠隔手続き呼出しのヘッダファイルは、通常の応用プログラムインター フェイスを提供するための応用プログラムによってコンパイルされる。カーネル ２５０、２５１は、相互接続されたコンピュータ間の、ネットワークまたはバス プロトコルのような基礎的な物理的接続を制御する。この実施例において、相互 接続されたコンピュータは、極めて多様なアーキテクチャからなるものとするこ とができる。 この実施例において実行される各々の分散オブジェクトに関し、該分散オブジ ェクトの“マスタ”は、実際のローカル手続き呼出しを呼出すため、サーバー２ ０６で示すサーバー処理において作成される。マスタオブジェクトのメソッドに アクセスするためには、前記サーバー２０６の共用オブジェクトのリスト（すな わち、サーバー２０６のすべてのSharedThangのリスト）へのインデックスであ るキーを、サーバー２０６のメモリスペース内のマスタオブジェクトへのポイン タと交換することが必要である。共用オブジェクトのリスト内のポインタはマス タの内包オブジェクト（クラスSharedThang）へのポインタであるので、前記マ スタの他の内包オブジェクト（例えば、クラスSharedThangから発生するクラス ｆoo）のメンバ関数を実行することが必要である場合、前記共用オブジェクトの リストからのSharedThangへのポインタが、前記内包fooオブジェクトへのポイン タに交換されなければならない。“ダウンキャスティング（down casting）”と 呼ばれるこの処理は、クラスClassInfoのメンバ関数CastDownによって実行され る。 このCastDownを実行するには、すべての共用オブジェクトのクラスの派生経過を 有することが必要である。この実施例において、この派生経過は、（i）共用オ ブジェクトの各クラスの宣言を修正するためにマクロGIFTS_DECLAREを使用し、 （ii）プリプロセッサcppによって発生されたコードから、共用オブジェクトの クラスのリストを抽出し、（iii）このようなリストをスタンドアローンプログ ラムGenTypeに提供して、実行時継承の木を形成するためにコンパイル可能なＣ 言語でのコードを発生する、ことによって提供される。この処理は、図３ａのブ ロック図に示されている。 図３ａに示すように、マクロGIFTS_DECLAREは、ステップ３０１において提供 され、クラスThangから派生したすべてのクラス（“インスタントクラス”）の 宣言に、（i）メンバ関数＿typeof()、（ii）各々が、文字列“＿magic＿”の連 鎖およびインスタントクラスの派生源である基礎クラスの名前からなる多数の記 号、ならびに、（iii）インスタントクラスの名前が割り当てられた文字列＿nam eofの宣言を挿入する。前記マクロGIFTS_DECLAREの結果、これらの付加的な宣言 のコンパイルは、各クラスの記号テーブルに、接頭辞文字列“＿magic＿”が付 いた多数の記号を含むことになる。この発明において、これらの記号は、クラス Thangから派生した各クラスの派生可能性をエンコードするために使用される。 前記マクロGIFTS_DECLAREは、付録Ｂに含まれるmacros.hにリストされている。 ステップ３０２において、“スクリプト”ファイルchomp.cppは、テキスト処 理ユーティリティegrepを使用して、コンパイルされたオブジェクトファイルの 記号テーブルから、前記接頭辞文字列“＿magic＿”が付いた前記挿入された記 号を抽出する。そして、これらの記号は、コマンドラインインタプリタすなわち “shell”によりUNIXで実行されるスタンドアローンプログラムGenTypeに供給さ れる。これらの記号により、GenTypeが、Thangから派生したすべてのクラスのオ ブジェクトに関する継承の木を構築することが可能になる。chomp.cppは図３ｂ にリストされている。前記継承の木は、（i）すべてのクラス、これらクラスへ のポインタ、および、サポートされる原始データタイプに対応するClassInfo構 造を含む配列であるアレイリスト、および、（ii）共用オブジェクトの各クラス （“インスタントクラス”）ごとに、各々の配列要素が該インスタントクラスの 派生源である基礎クラスを示すものである、ClassInfoへのポインタのアレイか らなる。 GenTypeは、ステップ３０３において構築された継承の木をＣコードで出力す るものであり、前記サーバーアドレススペースおよびクライアントアドレススペ ースの各々における静的データ構造として前記継承の木を作成するためにコンパ イルされる。さらに、GenTypeは、各クラスごとの＿typeof()メンバ関数を実行 するためのコードを発生する。前記＿typeof()関数は、１つのオブジェクトの型 コードを読み出すためにリストデータ構造にアクセスする。GenTypeのためのソ ースコードは、付録ＣのGenType.Cとして提供される。 上述のように、より大きなオブジェクトに内包されるThangオブジェクトへの ポインタが与えられると、ClassInfoのメンバ関数CastDownの目的は、前記より 大きなオブジェクトのその他の内包オブジェクト、または、前記より大きなオブ ジェクト自体へのポインタを読み出すことである。ダウンキャスティングのため に意図されたクラスが、CastDownに提供される。より大きなオブジェクトへのポ インタを得るために、関数rootが呼出され、前記より大きなオブジェクトのポイ ンタ“root”を返す。前記ダウンキャスティングが前記より大きなオブジェクト に内包されたオブジェクトへのダウンキャスティングである場合、前記意図され たクラスに到達するために、CastDownが、ClassInfoのメンバ関数getから返され た“root”のClassInfoからの継承の木を探索する。前記意図されたクラスの名 前と一致するクラスに到達すると、CastDownは、その派生パスに介在する各クラ スのデストラクタ関数とthisポインタとの間のオフセットを使用して、前記より 大きなオブジェクトへのポインタを算出する。（Ｃ＋＋プログミング言語におい て、各オブジェクトには、該オブジェクト自体を示すポインタthisが与えられて いる）。このようにして算出された前記より大きなオブジェクトへのポインタが rootから返されたポインタと一致する場合、ダウンキャスティングは成功であり 、前記意図されたクラスに内包されたオブジェクトへのポインタが返される。一 致しない場合、前記意図されたクラスに到達する他の継承パスを求めて、前記継 承の木がさらに探索される。Ｃ＋＋プログミング言語は多数の継承パスを許容す るので、この手続きが必要になる。 サーバー２０６は、通常、デーモンとして実行される。図４ａは、デーモンSe ctd（system Exercise and Confidence Test Daemon）を実現するプログラムの ブロック図である。デーモンSectdは、マスターオブジェクトSectContro1lerを 収容している。SectdおよびSectControllerは、それぞれ、図４ｂおよび図８に リストされているプログラムセグメントSectd.CおよびSectController.Cによっ て実行される。図４ａに示すように、Sectdは、Giftsユーザインターフェイスを 用いて、応用プログラムとしてスタートされる（ステップ４０１）。そして、Se ctdは、“サーバー”側コンストラクタルーチンを呼出すことによって、分散オ ブジェクトSectControllerのマスタを作り出す（ステップ４０２）。図８のプロ グラムセグメントSectController.Cに示すように、メソッドStartTesterは、Sec tdにおいて実行されるクラスSectControllerの唯一のメソッドである。 SectControllerのためのコンストラクタルーチンは、作り出されたSectContro llerのためのポインタを返す（ステップ４０３）。そのクライアントと通信する ために、Sectdは、通信サーバーオブジェクトRpcServerを作り出す（ステップ４ ０４）。RpcServerは、遠隔手続き呼出しメカニズム２０４とSectdとの間の通信 をフィルタするために使用される。図５は、RpcServerの実行を示すブロック図 である。RpcServerは、付録Ａにリストされた２つのプログラムセグメントRpcSe rver.hおよびRpcServer.Cによって実行される。RpcServerを作り出した後、Sect dは、クライアントマシーン２５１のクライアント２０７のような、クライアン トオブジェクトからのサービスリクエストを待つスリープモードに進む。遠隔手 続き呼出しメカニズム２０４は、クライアントオブジェクトから受けたハンドル に従ってSectd内のルーチンを呼出すルーチンSectdProg_1（図４ｃにリストされ ている）を呼出す。 図５に示すように、Sectdは、ステップ５０１においてRpcServerのコンストラ クタルーチンを呼出すことによって、RpcServerを作り出す。このコンストラク タルーチンは、（i）システムルーチンsvc_registerを呼出すことによって、遠 隔手続き呼出しメカニズム２０４とSectdとの間の通信を行うための移送レベル サービスを作り出し（ステップ５０２）、（ii）前記RpcServerをネットワーク のレジスタサービスに登録する（ステップ５０３）。前記ネットワークのレジス タサービスは、プログラムを探し出すための該ネットワークの探索サービスを提 供する。前記ネットワークのレジスタは、ホストマシーンの名前、前記プログラ ムの名前およびバージョンを受け取り、リクエストされたプログラムへのハンド ルを返す。前記ネットワークのレジスタサービスへの登録により、遠隔プログラ ムは、遠隔手続き呼出しのプログラム番号を使用して、前記RpcServerにアクセ スすることができる。 分散オブジェクトの各メソッドごとに、Sectd、および、クライアント２０７ のようなその各クライアントにおいて、スタブルーチンが提供される。このよう にして、図２に示すように、SectControllerのメソッドStartTesterのための遠 隔手続き呼出しの準備を行うために、“スタブ”ルーチン２０２、２０１が提供 され、それぞれ、Sectd処理スペースおよびクライアント２０７の処理スペース で実行される。典型的には、前記スタブルーチン２０２、２０１は、“配列（ma rshalling）”および“解列（unmarshalling）”と呼ばれる処理を実行する。前 記配列（marshalling）は、１つのマシーンのメソッド呼出し（例えば、アレイ へのポインタ）の仮パラメータからのマシーン依存型のデータ構造を、他のマシ ーンの潜在的に異なる環境に送られることが可能な“中立”型データ構造にマッ プする。前記解列（unmarshalling）は、環境間で交換される中立フォーマット をマシーン依存型のデータ構造にマップする。例えば、応用プログラム２０５が マシーン依存型のデータ構造における引数リストを持つクライアントスタブルー チン２０１を呼出すと、前記クライアントスタブルーチン２０１は、前記配列（ marshalling）を実行し、遠隔手続き呼出しメカニズム２０３に対して、通常は インタープロセスメッセージからなる配列された引数を送る。遠隔手続き呼出し メカニズム２０３、および、これに対応する遠隔手続き呼出しメカニズム２０４ は、カーネル２５１に対して、マシーンの境界を超えて通信を行うためのシステ ムサービス（例えば、ポートおよびプロトコル）を要求する。遠隔手続き呼出し メカニズム２０３によって送られる前記配列された引数は、遠隔手続き呼出しメ カニズム２０４によって受け取られ、該呼出しメカニズム２０４は、前記配列さ れた引数をSectdに送る。デーモン処理であるSectdは、受け取った前記Sectdを 解列するためにスタブルーチン２０２を呼出す。そして、スタブルーチンは、メ ソッドStartTesterの実際にリクエストされたサービスを実行するローカル手続 き２０５（例えば、“startTester_14SectControllerFRUiRC5Twine”）^*1に対し て、前記解列された引数を送る。もし存在するならば、その結果は、ローカル手 続き２０５から、該結果をクライアント２０７に返すために整列させるスタブル ーチン２０２に返される。Sectdからクライアント２０７への結果の返却は、前 記整列された引数の送路を逆方向に辿るものである。スタブルーチン２０１は前 記結果を解列し、しかる後、該結果は応用プログラム２０８に返される。Sectd がサービスすることができるクライアント２０７のようなクライアントの数には 、制限がない。 図６ｂのSectClientController.cにリストされ、図６ａのブロック図に要約さ れたSectClientControllerのプログラムセグメントは、遠隔手続き呼出しを行う クライアント２０７のようなクライアント処理の一部分の一例である。 遠隔手続き呼出しを行う前に、SectClientControllerは、それ自身とSectdと の間に通信チャンネルを形成するするために、クラスRpcClientのオブジェクト を作り出す（ステップ６０１）。前記クラスRpcClientは、クラスSharedThangか らも派生する。前記RpcClientのオブジェクトおよび関連メソッドの実行は、マ イクロフィッシュ付録Ａに含まれるファイルであるRpcClient.h、RpcClient.c、 RpcUtil.h、RpcUtil.h、Wrapper.hおよびWrapper.cに見られる。 図６ａに示すように、SectClientControllerがRpcClientオブジェクトを作り 出すと、RpcClientコンストラクタルーチン（SectClientController側）は、シ ステムサービスに対して、移送レベルサービスを開始するためのバージョンナン バが与えられる一時プログラムナンバを要求するようリクエストする（ステップ ６０２）。この移送レベルサービスは、後述されるSectdのRpcClientオブジェク トからのメッセージを受け取る、SectClientControllerのサーバーとして使用さ れる。（SectdのRpcClientは、SectdにおけるマスターオブジェクトのSectdクラ イアントステート情報に通信するためのパスを提供する）。こうして、Sectdか ら受け取られたメッセージに関して、SectClientControllerはサーバーとして作 用する。この移送レベルサービスは、SectdからのメッセージがSectClientContr ollerに到達するのを可能にするネットワークレジスタサービスによって登録さ れる（ステップ６０３）。そして、RpcClientのコンストラクタルーチンは、Sec tdにおけるrct＿9RpcClientFPCcU1U1R8ManifestU1PC9RpcHandlePC7timeinterval （“rct”）遠隔ルーチンに対して、遠隔手続き呼出しを行う（図４ｃに示したS ectdProg_1）（ステップ６０４）。rctへの遠隔手続き呼出しは、Sectdに対して 、（i）前記移送レベルサービスの一時プログラムナンバおよびバージョンナン バ、（ii） SectClientControllerのホストマシーンの名前、（iii）（後述の） SectClientControllerの“マニフェスト”（下記参照）、および、（iv）SectCl ientControllerの共用オブジェクトリストにおけるRpcClientオブジェクトのイ ンデックスを送る。こうして、付録ＡのWrapper.Cのプログラムセグメントで実 行されるrctへの遠隔手続き呼出しは、ステップ６０５において、RpcClientが（ i）受け取ったマニフェストを翻訳し、ii）コールバック目的で、SectdのrpcCli entのマスタとして、オブジェクトSectdClientControllerのRpcC1ientのSectdリ ストにおけるインデックスを割り当てる、ようRcpClientのためのコンストラク タルーチン（サーバー側）に要求する。また、Sectdは、メッセージデーモンozm sgdを作り出す（ステップ６０６）。前記rctへの遠隔手続き呼出しは、Sectdで 実行されるすべてのクラスに対する情報を含むマニフェストを返す。前記メッセ ージデーモンozmsgdは、（i）マスターにおける非同期的なステート変化、また は、（ii）Sectdにおける新たな共用オブジェクトの作成、または、（iii）Sect dにおける新たな共用オブジェクトの破壊をスレイブに知らせるために、Sectdの マ スタのスレイブを“コールバック（call-back）”する機能として意図されてい る。 通常のサーバークライアントモデルにおいて、クライアントは、サーバーに対 してメッセージを送ることによって、サーバーにサービスを要求する。こうして 、前記サーバーは、前記要求されたサービスを実行した後、その結果を返す。こ の通常モデルにおいて、前記サーバーは、前記クライアントとの通信を開始しな い。しかし、この実施例において、分散オブジェクトのマスタは１つまたは２つ 以上のクライアントにサービスするので、前記分散オブジェクトのマスタがマス ターオブジェクトのステート変化を非同期的に伝えることが必要になることがあ る。この目的のために、上述のように、マスターオブジェクトのステート変化、 および、共用オブジェクトの作成または破壊を伝えるため、デーモンozmsgdであ るこの場合のクライアントとして機能することは、SectClientControllerおよび Sectdのすべての同様なクライアントを呼出す。 この実施例において、マニフェストは、各々の既知のクラスごとに、クラス“ メタ情報”を含む。スレイブオブジェクトとマスタオブジェクトとが適当に一致 するよう、前記マニフェストは、各クラスごとに、（i）該クラスを特定する型 コード、（ii）該クラスの名前、（iii）もし存在するならば、該クラスの派生 源である基礎クラスの数、および、（iv）前記基礎クラスの名前を含むものであ る。さらに、マニフェストは、該マニフェストを提供する処理における各共用オ ブジェクトごとに、型コードと、送り処理の共用オブジェクトへの共用オブジェ クトのインデックスを含む。前記マニフェストは、上述したGenTypeによって作 り出された継承の木の一部である構造リストから作られる。前記クラスマニフェ ストの定義および実行は、付録Ｂに含まれるファイルmanifest.cおよびmanifest .hにおいて与えられる。 この実施例において、システム設計者は、使用すべき応用プログラムのための すべてのシステムオブジェクトを提供する。これらのシステムオブジェクトはロ ーカルに分散されるが、その実行は前記応用プログラムから隠される。先ずSect ClientControllerクラスが例示されるとき、前記SectClientControllerのコンス トラクタルーチンは、前記SectClientControllerから受け取ったマニフェストか ら作り出されたマスタの共用オブジェクトリストから、マスタSectClientContro llerを捜し出す（ステップ６０７）。この例によって示されるように、マスタと スレイブとの間の接続は、前記マスタとスレイブオブジェクトとが同一クラスで あることを必要としない。この実施例において、SectClientControllerはSectCo ntrollerから派生したクラスであるので、互換性が実現される。こうして、Sect dにおける同一のSectControllerを使用して、前記SectControllerから派生した クラスに属する多数のデバイスを制御できる。前記接続を実現するために、Sect ClientControllerは、関数joinWithMasterに対する呼出しを行い、該joinWithMa sterに対して、（i）SectClientControllerへのポインタ、（ii）joinWithMaste rに対するルーチンjoinWithSlaveを呼出せよとの命令を示すハンドルJoin-With_ Slave_1、（iii）SectClientControllerのRpcC1ientへのポインタ、（iv）基礎 クラス“SectController”の名前、および、Sectdの共用オブジェクトリストへ のインデックスmaster（該masterはSectdにおけるSectControllerに対応する） を送ることによって、Sectdにおける前記マスタオブジェクトSectControllerと の“結合（join）”を要求する。joinWithMasterおよびjoinWithSlaveの両方は 、付録Ａに含まれるファイルRpcUtil.hおよびRpcUtil.Cのプログラムセグメント にリストされている。 joinWithMasterは、クラスSectControllerに対応するClassInfoオブジエクト を得る。前記ClassInfoオブジェクトは、名前“SectController”にTypeofメソ ッドを適用することによって返される。そして、前記インデックスmasterおよび RpcClientは、SharedThangIdのメンバ関数addMasterによって、SectClientContr ollerに関連付けられる。その後、ハンドルJoin_With_Slave_1を使用する遠隔手 続き呼出し（ステップ６０９）は、SectdProg_1を介して、Sectdにおける関数rj oinWithSlav＿FP11SharedThangP9RpcClientuUi (“rjoin”）を呼出し、Sectdに 対して、SectClientControllerの共用オブジェクトリストへのインデックスを提 供する。 rjoinへの遠隔手続き呼出しは、Sectdに対して、（i）SharedThangのSectdの リストにおけるSectControllerを特定するインデックスmaster、および、（ii） SectClientControllerの共用オブジェクトリストへのRpcClientおよびSectClien tControllerのインデックスを送る。Sectにおける対応するRpcClientと調和させ るため、RpcClientのインデックスは、クラスSharedThangの対応するRpcClient に組込まれたオブジェクトへのポインタと交換される。このSharedThangのポイ ンタは、上記Sectdによって作り出されたRpcClientオブジェクトへのポインタに ダウンキャストされる。そして、rjoinは、SectdのSectControllerを、（i）Sec tClientControllerの送られたインデックスおよび（ii）Sectdの対応するRpcCli entオブジェクトによって形成されたRemoteldと関連づけるために、ローカルル ーチンJoinWithSlaveを呼出す。このRemoteldオブジェクトは、SharedThangIdの addClientメンバ関数を使用して、前記SectControllerのslaveリストに挿入され る。 上記の実行が適用業務プログラマに見えないようにするために、この発明は、 遠隔手続き呼出しのために“ローカル手続き呼出しセマンティクス”を保存する メカニズムを提供する。このローカル手続き呼出しセマンティクスにより、前記 クライアントプロセスは、該クライアントプロセスのメモリスペースにおける手 続きと同様に、前記手続き呼出しがリターンするのを待つ。さらに、通常の遠隔 手続き呼出しにおいて言語独立エラー処理メカニズムを実現する困難のために、 遠隔環境において発生するエラーは、しばしば、ローカル環境にリターンされな い。その代りに、予期される結果が得られないとき、ある時間の後に、前記呼出 し手続きは、タイムアウトメッセージを返す。しかしながら、遠隔手続き呼出し のためのエラー処理メカニズムもが、ローカル手続き呼出しのためのエラー処理 メカニズムとは区別できないものとされたときにのみ、ローカル手続き呼出しセ マンティクスが保存可能になる。 遠隔手続き呼出しの従来型の実行においては、明確な“待機”命令が実行され るまで、クライアントはその処理スペースにおける順次の実行を続行するように なっている。そのような実行は、応用プログラムは遠隔実行および遠隔イベント との同期について知る必要があるので、望ましくない。 遠隔手続き呼出しは、図２に関して上述したように、スタブルーチン２０１の ようなスタブルーチンをSectClientControllerで呼出すことによって、実現可能 である。この実施例において、スタブルーチン２０１，２０２は、“スクリプト ” ファイル（“oz”スクリプト）によって実行されるスタブルーチンジェネレータ を使用することによって、同時に発生される。スクリプトファイルは、UNIXコマ ンドラインインタプリタ（UNIXの用語では“シェル（shell）”と呼ばれる）に よって実行可能なプログラムである。 図７ａおよび７ｂは、それぞれ、SectControllerおよびSectdにおいて分散ク ラスを実行するマスタオブジェクトおよびスレイブオブジェクトのための前記oz スクリプトによつて発生される、スタブルーチンSectController::startTester およびrstartTester＿14SectControllerFRUiRC5Twine（“rstartTester”）のブ ロック図である。図８は、コンストラクタおよびデストラクタ関数に加えて１つ の関数SectController::startTesterを有する、SectdにおけるクラスSectContro llerを実際に実行するためのファイルSectController.Cにおけるソースコードで ある。StartTesterはSectdに存在するので、StartTesterに対するSectClientCon trollerのアクセスは、前記ozスクリプトによって発生されるスタブルーチンに よって行われる。前記ozスクリプトは、svc_SectController.Cおよびclnt_SectC ontroller.CファイルにおけるSectControllerのための２つのスタブルーチンを 発生する。SectClientControllerをコンパイルする目的で、SectClientControll er.Cは、clnt_SectController.Cファイルを含む。また、サーバ−２０６をコン パイルする目的で、SectClientController.Cは、svc_SectController.Cを含む。 前記メンバ関数StartTesterはSectdにおいてのみ実際に実行されるので、メンバ 関数SectControlle::startTesterの本体は、前記Sectdでのコンパイルのためだ けに含まれる。Sectdにおいて前記ozスクリプトによって発生されるスタブルー チンは、実際のSectController::startTesterコードと区別できるよう、文字“ ｒ”によって示される。このため、図８に示すように、SectdのSectController. Cバージョン（すなわち、svc_SectController）への包含が所望の場合、別のコ ンパイル指令“♯if defined（server）”が使用され、SectClientControllerの SectController.C（すなわち、SectController::startTesterスタブ）への包含 が所望の場合、別のコンパイル指令“♯if defined（oz）”が使用される。コン パイルの結果、SectController.Cの各バージョンごとに、オブジェクトファイル SectController.oが得られ、対応するクライアントまたはサーバーと結び付け られる。クライアントのSectController.oバージョンと結び付けられる応用プロ グラムは、SectControllerが分散オブジェクトであることを知る必要がない。 図７ａに示すように、SectController::startTesterは、SectControllerのイ ンデックスmasterid（すなわち、Sectdの共用オブジェクトリスト）を得る（ス テップ７０１）。そして、前記メンバ関数の名前を前記ハンドルにマップするRp cClientのメンバ関数rwhichによって、呼出しのための前記メンバ関数をエンコ ードする符号無しの整数ハンドルが読み出される（ステップ７０２）。その後、 メンバ関数parm1およびparm2への引き数、前記マスタのアドレスmasterid、およ び、RpcClientオブジェクトrid.idが、前記遠隔手続き呼出し２０３，２０４に よってサポートされる前記クラスXdrBufferのバッファ構造において提供される （ステップ７０３）。前記遠隔関数のバッファおよびハンドルは、前記遠隔手続 き呼出しメカニズムによって、Sectdに送られる（ステップ７０４）。図９ａは 、SectClientControllerのための前記ozスクリプトによって発生される図７ａの スタブルーチンのソースコードである。 図７ｂは、前記クラスSectControllerの１つのオブジェクトのSectdのためのo zスクリプトによって発生されるスタブルーチンrStartTesterのブロック図であ る。図７ｂに示すように、Sectdの共用オブジェクトリストへの前記マスタのRpc Clientオブジェクトのインデックスは、SectClientControllerから受け取られる メッセージから抽出される（ステップ７５０）。そして、前記RpcClientオブジ ェクトのインデックスは、前記ShareThang::get（id）メンバ関数を使用して、S ectdのメモリスペースにおけるポインタを前記RpcClientのShareThang内包オブ ジェクトに取り込むために使用される（ステップ７５１）。こうして、前記ポイ ンタは、前記クラスRpcClientの１つのオブジェクトーのポインタとなるようダ ウンキャストされる（ステップ７５２）。その後、前記XdrBufferの残りのパラ メータは、Sectdの共用オブジェクトリストにおけるSectControllerのインデッ クスid、および、前記starTesterのパラメータparm1、parm2を得るために使用さ れる（ステップ７５３）。前記インデックスidは、SectControllerの包含ShareT hangオブジェクトに対応するポインタを読み出すために使用される。そして、こ のポインタは、前記クラスSectControllerの１つのオブジェクトへのポインタに ダ ウンキャストされる（ステップ７５４）。そして、rstarTesterは、前記クラスS ectControllerのメンバ関数として、実際のローカル手続きStartTesterを呼出す （ステップ７５５）。前記ローカル手続き呼出しにエラーが発生しなかった場合 、変数parm1の返却値およびエラーコードLPC_Successが返される（ステップ７５ ６）。そうでない場合、２つのcatchステートメントのうちの１つによって例外 が捕らえられ、前記エラーコードが返される。こうして、SectClientController におけるスタブルーチンに、例外が送り返される。このように、この発明は、遠 隔手続き呼出しにおいてローカル呼出しセマンティクスを保存する。図９ｂは、 前記Sectdのためのozスクリプトによって発生される図７ｂのスタブルーチンrSt artTesterのソースコードである。 図１０は、前記ozスクリプトの作用を示すブロック図である。様々な変更例を 使用して前記スタブルーチンを提供することができる、ということが当業者に理 解されるであろう。このような変更例は、シェル以外によって実行可能なプログ ラムの使用、または、awk以外のテキスト処理ユーティリティの使用を含んでよ いが、これらに限られるものではない。この実施例の前記ozスクリプトは、仕様 ファイルを入力し、任意のコマンドライン引き数を受入れる。これらのコマンド ライン引き数は、（i）前記仕様ファイルにおける名前を“マングル化されてい ない”必要があるか否か（-rawオプション）、（ii）クライアントスタブルーチ ンファイルを発生すべきか否か（-cオプション）、（iii）サーバースタブルー チンファイルを発生すべきか否か（-sオプション）、（iv）前記サーバースタブ ルーチンファイルまたはクライアントスタブルーチンファイルの選択的な包含の ためのコンパイラ指示を、分散オブジェクトを実施する前記.cファイルの本体に 付加すべきか否か（-mオプション）、および、（v）例えばrstartTesterのよう な遠隔関数へのハンドルを、前記サーバー側の遠隔手続き呼出しメカニズムによ って呼出される例えばSectProg_1のようなプログラムに包含させるために発生す べきか否か（-hオプション）、を明記する。 図１１は、図７ａおよび７ｂに示されたSectControllerのためのスタブルーチ ンを発生するために前記ozスクリプトによって使用される仕様ファイルである。 上記のスタブルーチンの発生を説明するためには、前記仕様ファイルの第１行だ けを考慮するだけで十分である。 図１０に示すように、ozスクリプトは、コマンドラインを分析し、該コマンド ラインから該ozスクリプトの内部ステートを設定するための引き数を抽出する（ ステップ１００１）。前記-rawオプションが設定されているか否かに応じて、前 記使用ファイルについてネームマングリング処理が実行される（ステップ１００ ２）。このマングリング処理は、Ｃ＋＋関数の名前を、その関数のパラメータリ ストのコード化を含む独特な名前に変換するものである。前記仕様ファイルをネ ームマングリング処理した結果は、新たなファイルinput（“input（入力）”フ ァイル）に記憶される。この実施例において、その他のシェルスクリプト“mang le”がネームマングリング処理を実行するために使用された。しかし、上記参考 文献に記載されたネームマングリング規則と略一致する他のシェルスクリプトも 、適用可能である。前記rawオプションが設定されていない場合、前記仕様ファ イルは、前記ネームマングリング処理を迂回して、前記入力ファイルに直接にコ ピーされる（ステップ１００３）。さらに、前記-mオプションが設定されていな い場合、前記分散クラスのソースコードに、他のコンパイル指令が付加される（ ステップ１００４）。そして、前記入力ファイルは、前記接続された名前から、 該入力ファイルで示された基礎クラスのリストを抽出するために分析される（ス テップ１００５）。例えば、図１１の仕様ファイルから得られた入力ファイルに おいては、２つの基礎クラス“SectTester”および“SectController”が前記入 力ファイルから引出される。前記引出された基礎クラスのリストは、“基礎リス ト”ファイルに格納される。 次のステップ１００６および１００７では、awkコマンドファイルsvc.awkおよ びclnt.awkが作成される。前記コマンドファイルsvc.awkは、（i）遠隔手続き呼 出しファシリティおよび例えばSharedThangIdのような他のデータ構造の宣言に 対して、必要なヘッダファイルを提供し、（ii）メンバ関数呼出しために入力一 時ファイルを調べ、（iii）前記分散の実際の実行に対して入力型パラメータを 送るため解列命令を提供し、且つ、（iv）他の入力／出力型のパラメータ値を返 すために配列命令を提供する。また、コマンドファイルsvc.awkは、ShareThang オブジェクトを前記入力一時ファイルに明記された基礎クラスにダウンキャスト するために、出力サーバーオブジェクトにおいて命令を提供する。 また、コマンドファイルclnt.awkは、遠隔手続き呼出し機能、および、データ 構造の宣言にインターフェイスを提供する。さらに、clnt.awkは、入力パラメー タを使用して遠隔手続き呼出しを形成するために、入力型パラメータを配列し、 その値が前記遠隔手続き呼出しから返される出力または二方向パラメータに関し て、解列命令を与える。 ステップ１００８では、前記基礎リストファイルを使用して、各基礎クラスご とに、出力一時ファイルに格納すべき前記入力ファイルからのメンバ関数呼出し を抽出いる。その後、この一時ファイルは、ステップ１００９において、出力ス タブルーチンファイルsvc_〈base〉.Cおよびclnt_〈base〉.Cを発生するために 、両前記コマンドファイルclnt.awkおよびsvc.awkによって使用される（ここで 、〈ba ステップ１０１０では、前記クラスSectControllerのメンバ関数が、フ ァイルSectdProg.cに包含されるハンドルにコード化される。該SectdProg.cは、 前記遠隔手続き呼出しメカニズムに提供されるハンドルに従って、スイッチステ ートメントを介して、Sectdの関数を呼出すSectd関数SectdProg_1を含む。 付録Ｄは、図１０においてブロックで示されたozスクリプトのソースリストを 提供する。 上記説明は、この発明の特定の実施例を説明したものであるが、この発明を前 記実施例に限定するものではない。この発明の範囲内において、様々な変更が可 能である。例えば、上記詳細な説明はＣ＋＋プログラミング言語での実施例を説 明したが、この発明は、その他のオブジェクト指向プログラミング言語にも適用 可能である。この発明の範囲は、次の特許請求の範囲に記載されている。

【手続補正書】特許法第１８４条の７第１項 【提出日】１９９４年２月３日 【補正内容】 （1994年2月3日付提出の請求の範囲の翻訳文） 請求の範囲 １．第１のコンピュータと第２のコンピュータとを具備する分散型コンピュータ システムの応用プログラムにおけるデータオブジェクトを共用するための構造で あって、 第１の遠隔手続き呼出しメカニズムに対するインターフェースであって、前記 第１のコンピュータに設けられた第１の応用レベルインターフェイスと、 第２の遠隔手続き呼出しメカニズムに対するインターフェースであって、前記 第２のコンピュータに設けられた第２の応用レベルインターフェイスと、 該第１のコンピュータと第２のコンピュータとの間におけるデータの伝送を行 うために、前記第１のコンピュータおよび第２のコンピュータに設けられていて 、前記第１の遠隔手続き呼出しメカニズムと第２の遠隔手続き呼出しメカニズム とを結合する手段と、 前記第１の応用レベルインターフェイスに結合されていて、共用可能なオブジ ェクトの基礎クラスを表現するデータ構造を提供するものであり、該各共用可能 なオブジェクトは前記第１のコンピュータおよび第２のコンピュータの処理によ ってアクセス可能である第１の手段と、 前記第２の応用レベルインターフェイスに結合されていて、前記共用可能なオ ブジェクトの前記基礎クラスを表現する前記データ構造を提供する第２の手段と 、 前記第１の応用レベルインターフェイスに結合されていて、クラスの階層に従 って前記基礎クラスから派生された共用可能オブジェクトの複数のクラスを夫々 表現するデータ構造を提供するものであり、該共用可能オブジェクトの複数のク ラスの各々における各共用可能オブジェクトは前記第１のコンピュータおよび第 ２のコンピュータの処理によってアクセス可能である第１の手段と、 前記第２の応用レベルインターフェイスに結合されていて、前記共用可能オブ ジェクトの前記複数のクラスを夫々表現する前記データ構造を提供する第２の手 段と、 前記第１のコンピュータに設けられていて、前記基礎クラスを表現するデータ 構造に根付いた継承の木を構築するものであり、該継承の木は前記クラスの階層 に従って前記共用可能オブジェクトの複数のクラスと前記基礎クラスとの間の関 係を表現するデータ構造を持っている第１の手段と、 前記第２のコンピュータに設けられていて、該第２のコンピュータにおいて前 記継承の木を構築する第２の手段と、 前記第１のコンピュータに設けられていて、該第１のコンピュータにおける或 る第１のオブジェクトと或る第２のオブジェクトとの間の関係を表現するデータ 構造を構築するために前記継承の木を探索するものであり、この第１のオブジェ クトは前記第１及び第２の遠隔手続き呼出しメカニズムを介して前記第２のコン ピュータにおける処理によってマシーン独立型フォーマットで特定されるもので ある第１の手段と、 前記第２のコンピュータに設けられていて、該第２のコンピュータにおける或 る第１のオブジェクトと或る第２のオブジェクトとの間の関係を表現するデータ 構造を構築するために前記継承の木を探索するものであり、この第１のオブジェ クトは前記第１及び第２の遠隔手続き呼出しメカニズムを介して前記第１のコン ピュータにおける処理によってマシーン独立型フォーマットで特定されるもので ある第２の手段と を具備した構造。 ２．第１のコンピュータと第２のコンピュータとを具備する分散型コンピュータ システムの応用プログラムにおけるデータオブジェクトを共用するための方法で あって、 前記第１のコンピュータにおいて、該第１のコンピュータの第１の遠隔手続き 呼出しメカニズムに対する第１の応用レベルインターフェイスを提供するステッ プと、 前記第２のコンピュータにおいて、該第２のコンピュータの第２の遠隔手続き 呼出しメカニズムに対する第２の応用レベルインターフェイスを提供するステッ プと、 前記第１のコンピュータと第２のコンピュータとの間におけるデータの伝送を 行うため、前記第１及び第２のコンピュータにおける前記第１の遠隔手続き呼出 しメカニズムと第２の遠隔手続き呼出しメカニズムとを結合するステップと、 前記第１及び第２のコンピュータの各々において、該第１及び第２のコンピュ ータにおける共用可能なオブジェクトの基礎クラスを表現するデータ構造を提供 し、かつ、前記第１及び第２のコンピュータの各々において、前記基礎クラスか ら派生された共用可能オブジェクトの複数のクラスを夫々表現するデータ構造を 提供するステップと、 前記第１及び第２のコンピュータの各々において、前記基礎クラスを表現する データ構造に根付いており、かつ、クラスの階層に従って前記共用可能オブジェ クトの複数のクラスと前記基礎クラスとを関係づけるデータ構造を持っている、 継承の木を提供するステップと、 或る第１のオブジェクトが前記第１及び第２のコンピュータの一方における処 理によって特定され、かつ該第１のオブジェクトが前記第１及び第２のコンピュ ータの前記遠隔手続き呼出しメカニズムを介して前記第１及び第２のコンピュー タの他方に供給される毎に、前記第１及び第２のコンピュータの各々において、 前記第１のオブジェクトと或る第２のオブジェクトとの間の関係を表現するデー タ構造を構築するために前記継承の木を探索するステップと を具備する方法。 ３．前記各共用可能オブジェクトが、前記第１のコンピュータおよび第２のコン ピュータのうちの選択された一方におけるサーバーオブジェクトと、前記第１の コンピュータおよび第２のコンピュータのうちの他方におけるクライアントオブ ジェクトとを具備し、前記サーバーオブジェクトとクライアントオブジェクトと が、前記第１の応用レベルインターフェイスおよび第２の応用レベルインターフ ェイスを介して通信する請求の範囲第１項に記載の構造。 ４．前記クライアントオブジェクトが、（ａ）共用可能オブジェクトのサーバー オブジェクトクラス、または、（ｂ）前記共用可能オブジェクトのサーバーオブ ジェクトクラスから派生された共用可能オブジェクトの或るクラスに属している 請求の範囲第３項に記載の構造。 ５．前記サーバーオブジェクトが、前記選択されたコンピュータにおいて実行さ れる複数のメソッドを有し、前記クライアントオブジェクトが、前記第１及び第 ２の応用レベルインターフェイスによる遠隔手続き呼出しを介して前記メソッド の各々にアクセスする請求の範囲第３項に記載の構造。 ６．前記継承の木に基づき、および、共用されるオブジェクトへのポインタを使 用して、（ａ）前記共用されるオブジェクトを含む親オブジェクト、または、（ ｂ）前記親オブジェクトの内包オブジェクトへのポインタを求める手段をさらに 具備した請求の範囲第５項に記載の構造。 ７．前記サーバーオブジェクトが共用可能オブジェクトのリストを維持し、前記 クライアントオブジェクトが、前記リストへのインデックスを使用して、前記リ スト内の１つの共用可能オブジェクトのメソッドを特定し、その後、前記サーバ ーオブジェクトが、前記インデックスを受け取って、前記ポインタを求める手段 を介して前記メソッドへのポインタを求める請求の範囲第６項に記載の構造。 ８．前記サーバーオブジェクトが、前記メソッドのいずかれを実行した結果を、 前記第１の応用レベルインターフェイスおよび第２の応用レベルインターフェイ スを介して前記クライアントオブジェクトに返すものであり、前記クライアント オブジェクトは、前記結果を受け取るまで、スリープモードで待機する請求の範 囲第５項に記載の構造。 ９．前記サーバーオブジェクトが、前記メソッドのいずかれを実行している間に 発生したエラーメッセージを、前記第１の応用レベルインターフェイスおよび第 ２の応用レベルインターフェイスを介して前記クライアントオブジェクトに返す ものである請求の範囲第５項に記載の構造。 １０．前記クライアントオブジェクトが、サーバー通信オブジェクトと、前記サ ーバーオブジェクトに対して該サーバー通信オブジェクトの作成を通知するメッ セージを作成するものであり、前記サーバーオブジェクトが、前記メッセージに 応答して、前記クライアントオブジェクトにメッセージを送るためのクライアン ト通信オブジェクトを作成する請求の範囲第３項に記載の構造。 １１．前記サーバーオブジェクトが、前記サーバーオブジェクトクラス、および 、該サーバーオブジェクトクラスの派生源であるクラスをリストしたサーバーマ ニフェストを前記クライアントオブジェクトに送り、前記クライアントオブジェ クトが、前記クライアントオブジェクトクラス、および、該クライアントオブジ ェクトクラスの派生源であるクラスをリストしたクライアントマニフェストを前 記サーバーオブジェクトに送る請求の範囲第４項に記載の構造。 １２．前記共用可能なオブジェクトの各々を、前記第１のコンピュータおよび第 ２のコンピュータのうちの選択された一方においてサーバーオブジェクトとして 実行し、前記第１のコンピュータおよび第２のコンピュータの他方においてクラ イアントオブジェクトとして実行するステップを更に具備し、前記サーバーオブ ジェクトとクライアントオブジェクトとが、前記第１の応用レベルインターフェ イスおよび第２の応用レベルインターフェイスを介して通信する請求の範囲第２ 項に記載の方法。 １３．前記クライアントオブジェクトに対して、（ａ）共用可能オブジェクトの 前記サーバーオブジェクトクラス、または、（ｂ）前記共用可能オブジェクトの サーバーオブジェクトクラスから派生する共用可能オブジェクトの１つのクラス で、前記クライアントオブジェクトを供給するステップを更に具備する請求の範 囲第１２項に記載の方法。 １４．前記サーバーオブジェクトに対して、前記選択されたコンピュータで実行 される複数のメソッドを供給するステップと、 前記第１の応用レベルインターフェイスおよび第２の応用レベルインターフェ イスによる遠隔手続き呼出しを介して、前記クライアントオブジェクトから各前 記メソッドをアクセスするステップと を更に具備する請求の範囲第１３項に記載の方法。 １５．前記第１のコンピュータおよび第２のコンピュータの各々において、前記 継承の木に基づき、および、共用されるオブジェクトへのポインタを使用して、 （ａ）前記共用されるオブジェクトを含む親オブジェクト、または、（ｂ）前記 親オブジェクトの内包オブジェクトへのポインタを求めるステップを更に具備す る請求の範囲第１４項に記載の方法。 １６．共用可能オブジェクトのリストを前記サーバーオブジェクト内に維持する ステップと、 前記リスト内の前記共用可能オブジェクトの１つのいずれかのメソッドにアク セスする際、前記リストへのインデックスを特定するステップと、 前記インデックスを受け取り、前記ポインタを求めるステップを使用して前記 メソッドへのポインタを求めるステップと を更に具備する請求の範囲第１５項に記載の方法。 １７．前記第１の応用レベルインターフェイスおよび第２の応用レベルインター フェイスを介して、前記サーバーオブジェクトから前記クライアントオブジェク トに、前記メソッドのいずかれを実行した結果を返すステップと、 前記結果を受け取るまで、前記クライアントオブジェクトがスリープモードで 待機するステップと を更に具備する請求の範囲第１４項に記載の方法。 １８．前記メソッドのいずれかを実行している間に発生したエラーメッセージを 、前記第１の応用レベルインターフェイスおよび第２の応用レベルインターフェ イスを介して前記クライアントオブジェクトに返す請求の範囲第１４項に記載の 方法。 １９．前記クライアントオブジェクトにおいて、サーバー通信オブジェクトと、 前記サーバーオブジェクトに対して該サーバー通信オブジェクトの作成を通知す るメッセージとを作成するステップと、 前記サーバーオブジェクトにおいて、前記メッセージに応答して、前記クライ アントオブジェクトにメッセージを送るためのクライアント通信オブジェクトを 作成するステップと を更に具備する請求の範囲第１２項に記載の方法。 ２０．前記サーバーオブジェクトクラス、および、該サーバーオブジェクトクラ スの派生源であるクラスをリストしたサーバーマニフェストを前記クライアント オブジェクトに送るステップと、 前記クライアントオブジェクトクラス、および、該クライアントオブジェクト クラスの派生源であるクラスをリストしたクライアントマニフェストを前記サー バーオブジェクトに送るステップと を更に具備する請求の範囲第１３項に記載の方法。

Claims (1)

1. 【特許請求の範囲】 １．分散型コンピュータシステムの応用プログラム用の高レベルデータ構造（“ オブジェクト”）サポートを提供するための構造であって、 第１の遠隔手続き呼出しメカニズムに対する第１の応用レベルインターフェイ スを提供する第１のコンピュータ、および、前記遠隔手続き呼出しメカニズムに 対する第２の応用レベルインターフェイスを提供する第２のコンピュータと、 前記第１のコンピュータと前記第２のコンピュータとの間でデータの伝送を行 うために、前記第１の遠隔手続き呼出しメカニズムと前記遠隔手続き呼出しメカ ニズムと接続する物理的接続部を含む手段と、 前記第１のコンピュータと前記第２のコンピュータとの間で共用可能なオブジ ェクトの基礎クラスを提供する手段と、 各々が前記基礎クラスから派生した共用可能なオブジェクトの複数のクラスを 提供する手段と、 前記複数のクラスの各々を、前記基礎クラス、および、これから派生した前記 複数のクラスの他のものに関連付ける、前記基礎クラスに根付いた継承の木を提 供する手段と、 前記第１の遠隔手続き呼出しメカニズムおよび第２の遠隔手続き呼出しメカニ ズムを介して提供されるクラスを構築するために前記継承の木を探索する手段と を具備した構造。 ２．分散型コンピュータシステムの応用プログラム用の高レベルデータ構造（“ オブジェクト”）サポートを提供する方法であって、 第１の遠隔手続き呼出しメカニズムに対する第１の応用レベルインターフェイ スを提供する第１のコンピュータ、および、前記遠隔手続き呼出しメカニズムに 対する第２の応用レベルインターフェイスを提供するステップと、 前記第１のコンピュータと前記第２のコンピュータとの間におけるデータの伝 送を行うために、前記第１の遠隔手続き呼出しメカニズムと前記遠隔手続き呼出 しメカニズムとを結合するステップであって、前記第１及び第２のコンピュータ を物理的に接続することを含むステップと、 前記第１のコンピュータと前記第２のコンピュータとの間で共用可能なオブジ ェクトの基礎クラスを提供するステップと、 各々が前記基礎クラスから派生した共用可能なオブジェクトの複数のクラスを 提供するステップと、 前記複数のクラスの各々を、前記基礎クラス、およびこれから派生した前記複 数のクラスの他のものに関連付ける、前記基礎クラスに根付いた継承の木を提供 するステップと、 前記第１の遠隔手続き呼出しメカニズムおよび第２の遠隔手続き呼出しメカニ ズムを介して提供されるクラスを構築するために前記継承の木を探索するステッ プとを備える方法。