JPH11259301A - Ｃ＋＋における例外の遅延投入のための方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 例外のスローを遅延するための方法及び装置
を提供する。 【解決手段】 本発明の１つの見地において、例外は、
オブジェクトベースのシステム内で第１オブジェクトの
起動中に発生する。例外は、例外をキャッチし、その例
外の第１コピーを作成することによって処理される。第
１コピーの作成には、動的メモリ内での例外の第１コピ
ーの記憶が含まれる。例外の第１コピーは、例外ヒープ
上に記憶される例外の実行時コピーを作成することによ
って処理されるであろう。例外の実行時コピーがキャッ
チされ、例外の第１コピーは動的メモリから削除され、
例外のキャッチされた実行時コピーが再処理される。一
実施形態において、例外の第１コピーの処理には、例外
の第１コピーをシステム例外としてスローすることが含
まれ、例外の第１コピーをシステム例外としてのスロー
することによって、例外の実行時コピーが作成される。

Description

【発明の詳細な説明】

【０００１】

【発明の背景】１．発明の分野 本発明は、一般的にオブジェクトベースのシステムに関
する。更に詳細には、本発明は、オブジェクトベースシ
ステムにおいて例外のスロー（投入:throwing）を延期
するための方法及び装置に関する。 ２．関連技術の説明 分散オブジェクトシステムにおいては、クライアントオ
ブジェクトがサーバオブジェクトを起動することがあ
る。クライアントは、通常、動作がオブジェクト、例え
ばサーバオブジェクト又はサーバで実行されることを要
求するエンティティである。リクエストは、大部分の場
合、オブジェクトリクエストブローカ（ＯＲＢ）インプ
リメンテーションを介してクライアントからサーバント
に渡され、それは共通オブジェクトリクエストブローカ
アーキテクチャ(Common Object Request Broker Archit
ecture）（ＣＯＲＢＡ）のもとで定められている。

【０００２】ＣＯＲＢＡ仕様内では、オブジェクトモデ
ル、即ちＣＯＲＢＡオブジェクトモデルが、オブジェク
ト、即ちサーバによって実現されるサーバントがクライ
アントにエクスポートされる可能性のあるリファレンス
を有するプログラミング言語上で定義されてい。オブジ
ェクトモデルが定義されるプログラミング言語は、Ｃ＋
＋やＪａｖａ（商標）等のプログラミング言語を含む可
能性はあるが、それらであることに制限されない。当業
者により理解されるように、ある特定のプログラムは、
クライアントとサーバの両方として役立つことがある。

【０００３】ＣＯＲＢＡオブジェクトモデルは、インタ
フェースをサーバントに対応するオブジェクトリファレ
ンスのために定義できるようにするインタフェース定義
言語（ＩＤＬ）を定義する。適切なインタフェースがオ
ブジェクトリファレンスに定義されると、通常、ＩＤＬ
コンパイラが使用されて、インタフェースのＩＤＬ定義
がプログラミング言語定義に変換される。一例として、
Ｃ＋＋プログラミング言語では、プログラミング言語定
義はＣ＋＋クラスとなることがある。代わりに、Ｊａｖ
ａ（商標）環境では、プログラミング言語定義はＪａｖ
ａ（商標）インタフェースである場合がある。

【０００４】プログラミング言語定義がＩＤＬコンパイ
ラによって作成された後は、プログラミング言語定義
は、そのプログラミング言語定義に対応するサーバント
を実現するために使用することができる。また、プログ
ラミング言語定義は、当業者によって理解されるよう
に、適切なオブジェクトリクエストブローカ（ＯＲＢ）
インプリメンテーションとサーバントを接続するために
使用されることもある。

【０００５】ＣＯＲＢＡオブジェクトモデルは、通常、
サーバント上での非局所的な起動をサポートする。サー
バプロセス内にある、サーバントとは異なるプロセスか
らのクライアントは、サーバントに対応するオブジェク
トリファレンスを起動することがある。クライアントＯ
ＲＢインプリメンテーションは、通常、起動リクエスト
をマーシャル（marshals）させ、例えば「パック（pack
s)」し、その起動リクエストをサーバントプロセスにデ
ィスパッチするか、ディスパッチしない場合には転送す
る。一般的には、クライアントとサーバによって定義さ
れるプロトコルを使ってコンパイルするプロセス間通信
プリミティブが使用され、クライアントとサーバ間で起
動リクエストが転送される。

【０００６】サーバプロセスがクライアントプロセスか
ら起動リクエストを受け取ると、サーバプロセスはその
起動リクエストをアンマーシャル（unmarshals）（例え
ば「アンパック（unpacks)」し）その起動リクエストに
サービスを提供するために適切なサーバプロセス内のサ
ーバントが特定される。適切なサーバントの位置が見つ
け出されると、起動はクライアントプロセスからそのサ
ーバントに転送される。当業者によって理解されるよう
に、起動リクエストは、通常、クライアントによって指
定されるパラメータとともに転送される。

【０００７】起動は、クライアントからの起動リクエス
トに応答してサーバントで実行される。サーバントでの
起動が完了した後、サーバＯＲＢインプリメンテーショ
ンは、通常、起動によって作成された出力値等のあらゆ
る結果を蓄積して、結果をクライアントに転送して返
す。サーバプロセスは、クライアントへのトランスポー
トのために結果をマーシャルし、クライアントは結果が
受け取られたときに結果をアンマーシャルする。

【０００８】分散オブジェクトシステム等のオブジェク
トベースのシステムでは、オブジェクト起動時に例外が
発生することがある。例外は、通常、多様な異なる理由
から生じる。一例に、例外は、大部分の場合、例外状
態、即ちエラーが発生したことを示す。例外は、通常、
「サービスを提供している」又はそれ以外の場合、クラ
イアントのリクエストを履行しているサーバント、又は
ＯＲＢインプリメンテーションのどちらかによって発生
する。例外が発生すると、例外はクライアントに戻され
る。一般的には、例外をクライアントに渡すこと、即ち
スローすることは、例外状態即ちエラーが発生したこと
をクライアントに知らせる目的を果たす。

【０００９】Ｃ＋＋環境等の環境においては、例外は、
通常、例外を保持するための呼出しスタック上に常駐す
る例外オブジェクトである。このような例外の寿命は、
一般的には、当業者により理解されるように、対応した
タイプの構造内での例外手渡し(handing)節のプログラ
ミング言語有効範囲規則によって制限される。ＩＤＬコ
ンパイラによって作成されたスケルトンは、ＯＲＢイン
プリメンテーションと、起動や、更に具体的には非局所
的な起動を実行するサーバの間のリンクとして役立つ。
スケルトンは、一般的には、多様な異なるタスクを実行
することがあるが、スケルトンは、大部分の場合、起動
に関連するパラメータについてＯＲＢに知らせ、オブジ
ェクトリファレンスに対するサーバントを起動する責任
を負う。

【００１０】Ｃ＋＋環境内では、例外オブジェクトは、
大部分の場合、例外処理オブジェクトの範囲を超えて存
在しなければならない。多くの例外は一時的に記憶され
て、後で適切なときにスローされる。例外は、大部分の
場合、それが生じた直後にはスローされない。むしろ、
サーバントによって発生した例外は、例えば、記憶さ
れ、後に、例えば「強制」コードの実行後にクライアン
トにスローされる。一般的には、例外のスローを遅延す
るために、例外のコピーが作成される。Ｃ＋＋実行時環
境は、記憶されて、最終的に適切なときにスローされる
例外のコピー、例えば動的コピーが割り当てられる。例
外をスローするためには、スローされている例外のタイ
プが、一般的に知られていなければならない。

【００１１】例外のコピーを作成すること、例外がどの
ような種類のなのかという点で例外をつねに把握してい
ること、及びコピーされた例外をスローできるようにす
ることに関連するコードは、大部分の場合、重要であ
る。一例として、このようなコードは、大部分の場合、
本質的に他のセクションからの複製であるセクションを
含む。従って、例外をスローするという総合的なプロセ
スは、大部分の場合複製コードが処理されなければなら
ず、例外の種類が大部分の場合追跡調査されなければな
らないため、非効率的である。一例として、複製コード
を組み入れる(inlining)ことは、過剰なコード膨張(bloa
t)につながる可能性がある。

【００１２】更に、例外のコピーが作成されるときに、
コピーがリリースされないと、コピーによるメモリ漏れ
が引き起こされる可能性がある。当業者により理解され
るように、一般的には、メモリ漏れは、メモリが動的に
割り当てられるが、解放されていないときに発生する。
メモリ漏れを防止するためには、メモリは定期的にリリ
ースされなければならない。しかし、メモリが定期的に
リリースされるとき、例外のコピーは、それが使用（即
ちスローされる）される前にリリースされてしまう可能
性がある。従って、オブジェクトベースシステム内で例
外をスローするための効率的な方法及び装置が望まし
い。

【００１３】

【発明の概要】前記及び他の目的を達成するため及び本
発明の目的に従って、例外のスローを延期、即ち遅延さ
せるための方法及び装置を開示する。本発明の１つの見
地において、例外は、オブジェクトベースシステム内で
第１オブジェクトの起動中に発生する。例外は、例外を
キャッチして、その例外の第１コピーを作成することに
よって処理されるであろう。例外の第１コピーを作成す
ることは、動的メモリ内に例外の第１コピーを記憶する
ことを含む。それから、例外の第１コピーは、例外ヒー
プに記憶された例外の実行時コピーを作成することによ
って処理されるであろう。例外の実行時コピーが次にキ
ャッチされる。例外の第１コピーは動的メモリから削除
されて、例外のキャッチされた実行時コピーが再処理さ
れる。

【００１４】一実施形態において、例外の第１コピーを
処理することは、例外の第１コピーをシステム例外とし
てスローすることを含む。このような実施形態において
は、例外の第１コピーをシステム例外としてスローする
と、例外の実行時コピーが作成される。別の実施形態に
おいては、例外の第１コピーを処理することは、例外の
第１コピーを利用者定義例外（user-defined exceptio
n）としてスローすることを含む。このような実施形態
においては、例外の第１コピーを利用者定義例外として
スローすると、例外の実行時コピーが作成される。

【００１５】

【実施形態の詳細な説明】本発明は分散オブジェクトシ
ステムに向けられたものであり、添付図面に示したよう
ないくつかの好ましい実施形態に関して説明する。本発
明は、ＣＯＲＢＡ又はそれ以外の任意の適切な仕様のも
とで定義されるものを含む任意の適切な分散オブジェク
トシステムのコンテキスト内で実施されるであろう。し
かしながら、説明の目的のため、本発明は、おもにＣＯ
ＲＢＡのもとで実現されるオブジェクトリクエストブロ
ーカ（ＯＲＢ）のコンテキストで説明する。図１に、本
発明を実現するための適切且つ代表的な分散オブジェク
トシステムの総合的なアーキテクチャを示す。図２に、
３レベルディスパッチ機構を含むこのようなアーキテク
チャ内でクライアントからサーバントオブジェクトまで
のリクエストがたどる可能性がある、考えられるいくつ
かのフロー経路を示す。図３に、サーバントオブジェク
トを参照するためにクライアントによって使用されるこ
とがある１つのオブジェクトリファレンスデータ構造を
示す。

【００１６】分散オブジェクトシステム１０は、通常、
図１に記号で示すような、オブジェクトリクエストブロ
ーカ（ＯＲＢ）１１を含む。ＯＲＢ１２は、図２に関し
て後述するように、ロケーションと、クライアントから
サーバント（ターゲットオブジェクト）に呼出しを送達
し、クライアントに応答を戻すために必要なトランスポ
ート機構と機能のすべてを提供する。クライアントとサ
ーバントは、同じプロセス内に位置することもあれば、
同じ機械の別のプロセス内に位置することもあれば、ま
ったく別の機械に位置することもある。この説明の目的
のため、クライアント２０は分散オブジェクト上で動作
を起動する任意のコードである場合があり、従って分散
オブジェクト又はプロセスの形を取ることもあれば、取
らないこともある。正常なオブジェクトインプリメンテ
ーション１４は、Ｃ＋＋等の従来のオブジェクトプログ
ラミング言語内で定義されるオブジェクトタイプの表現
である。多岐に渡る表現が考えられる。一例として、オ
ブジェクトインプリメンテーション１４が、アプリケー
ションの開発者によって提供された簡略なＣ＋＋オブジ
ェクトタイプである可能性がある。代わりに、オブジェ
クトタイプのインプリメンテーションが、ビジュアルア
プリケーションビルダ(builder)１５内で開発されるこ
ともある。このビジュアルアプリケーションビルダによ
って、開発者は、オブジェクトタイプの新しいインプリ
メンテーションを作成するために、カタログから既存の
オブジェクトタイプを視覚的に選択し、あるオブジェク
トによって提供されるサービスを別のオブジェクト（属
性、引き数など）によって必要とされるサービスにグラ
フィックに接続できるようになる。

【００１７】オブジェクト開発機能１６は、分散オブジ
ェクトの作成とインストールを簡略化するために使用さ
れることがある。それは、分散オブジェクトコードで開
発者オブジェクトを「ラップ」する、即ちカプセル化す
るために使用される。そのようなものとして、オブジェ
クト開発機能１６は、開発者オブジェクトをＯＲＢオブ
ジェクトインプリメンテーション１４に変換するために
使用されることがある。この例では、ＯＲＢオブジェク
トインプリメンテーション１４は、図中のそのロケーシ
ョンによって示されるように、サーバとして提示され
る。開発者は、ＯＲＢオブジェクトのインタフェースを
定義するためにインタフェース定義言語を使用し、オブ
ジェクトの動作を実現する開発者オブジェクトインプリ
メンテーションを提供してから、ＯＲＢオブジェクトイ
ンプリメンテーション１４を作成するために、オブジェ
クト開発機能を使用する。実行時に、このＯＲＢオブジ
ェクトのインスタンス、例えばこのＯＲＢオブジェクト
インプリメンテーション１４を活用するサーバントオブ
ジェクトが作成される。オブジェクト開発機能は、任意
のポイントでクライアントの役割を果たすオブジェクト
を作成するために使用してもよいことが理解されなけれ
ばならない。

【００１８】クライアント２０は、スタブ２１、方法テ
ーブルディスパッチ２４、サブコントラクト(subcontra
ct)層３６、あるいはフィルタ４０、及びトランスポー
ト層３８を経由してサーバントと通信する。スタブ２１
は、代用物(surrogate)２２、方法テーブル２４、及び
スタブ関数２５を含む。クライアント２０は、当初、ク
ライアントにとってサーバオブジェクトのように見える
代用物２２と通信する。代わりに、クライアント２０
は、代用物２２、方法テーブル２４、及びスタブ関数２
５を通す代わりに、動的起動インタフェース（ＤＩＩ）
２６を通して直接的にサーバオブジェクトと通信するこ
とがある。動的起動インタフェース２６は、クライアン
トが、例えばクライアント２０として、動的リクエスト
を構築できるようにするために使用される。クライアン
トが前記層を活用してサーバントに呼出しを行う１つの
手順を、図２に関して更に詳細に後述する。

【００１９】サブコントラクト層３６はサブコントラク
トを活用し、ある特定のサブコントラクトによって指定
される多様なサービス（又は特徴やオブジェクト機構）
を実現するために、オブジェクトによって必要とされる
機能性を提供する。サブコントラクトは、個別オブジェ
クトによって活用されることがある分散オブジェクトシ
ステムによって提供されるサービスの質を特定する。例
えば、サブコントラクトは、セキュリティの特徴がある
特定のオブジェクトに対し使用されなければならないこ
とを特定することがある。フィルタ４０は、使用される
場合、オブジェクトに対する通信とオブジェクトからの
通信に適用されなければならない、圧縮、暗号化、追
跡、又はデバッグなどの多様なタスクを実行することが
ある。

【００２０】トランスポート層３８は、情報を、マーシ
ャルし、アンマーシャルし、通常はクライアントと同じ
プロセスを共用しないサーバに対し、及びサーバから情
報を物理的にトランスポートするために動作する。標準
的なインプリメンテーションスーツ(suite)２８（即ち
オブジェクトアダプタ）は、例えば、オブジェクトキー
管理と同一の方法でＯＲＢオブジェクトインプリメンテ
ーション１４と対話する一組のサブコントラクトを表
す。サブコントラクトが複数のインプリメンテーション
セットに属することがあることに適切に注意する必要が
ある。従って、異なるサブコントラクトを活用する他の
インプリメンテーションスーツも考えられる。静的なス
ケルトン３２又は動的なスケルトン３０の形を取ること
があるスケルトンは、リクエストを、ＯＲＢオブジェク
トインプリメンテーション１４、例えばサーバントオブ
ジェクトによって要求されるフォーマットに変換するた
めに使用される。このようにして、スケルトン３２、３
０は、適切なＯＲＢオブジェクトインプリメンテーショ
ン１４を呼び出す。静的なスケルトン３２は、インタフ
ェースに特殊なオブジェクトインプリメンテーション１
４を呼び出すために使用されるが、動的なスケルトン３
０は、一般的には、インタフェースに特殊なオブジェク
トが使用できないときに使用される。ＯＲＢインタフェ
ース３４は、すべてのＯＲＢにとって同じであるＯＲＢ
に直接移動し、オブジェクトのインタフェース又はオブ
ジェクトアダプタに依存しないインタフェースである。
ＯＲＢデーモン４６は、クライアントによって起動され
たときにオブジェクトサーバがアクティブであることを
確実にすることに責任を負う。

【００２１】セキュア(secure)プロトコル４２は、イン
ターネットＯＲＢ間プロトコルをセキュアし、安全にト
ランスポート層３８を通して情報を伝達するのに役立つ
セキュアインタオペラビリティプロトコルである。これ
は、統合性の保護、機密性などを意味する場合がある。
インターネットＯＲＢ間プロトコルとは、通常、異なっ
た機械のプロセス間で通信するプロトコルのことであ
る。ただし、インターネットＯＲＢ間プロトコルが、同
じ機械のプロセス間で通信する場合もある。セキュリテ
ィサーバ５４は、異なるコンピュータ上のプロセス間で
使用されるサービスをセキュアするセキュリティ管理サ
ーバである。

【００２２】タイプコード(typecode)／任意（any）モ
ジュール４４は、タイプコードと「任意」オブジェクト
を実現する。タイプコードは、インタフェース定義言語
（ＩＤＬ）データタイプを記述し、タイプ記述をクライ
アントとサーバの間で伝送できるようにする。ＩＤＬデ
ータタイプのインスタンスは、「任意」オブジェクトによ
りカプセル化されることがある。任意オブジェクトは、
カプセル化されたデータのタイプコードと、データの総
合的な符号化を指す。

【００２３】インプリメンテーションリポジトリ５０
は、オブジェクトサーバに関する情報を記憶するために
使用される。具体的には、インプリメンテーションリポ
ジトリ５０は、サーバプロセスを開始するために必要と
される情報を記憶する。例えば、インプリメンテーショ
ンリポジトリ５０は、サーバプログラムのロケーショ
ン、プログラムに対するあらゆる引き数、及びプログラ
ムに渡すあらゆる環境変数などのような情報を記憶す
る。

【００２４】単純永続性５６は、ＩＤＬによって定義さ
れたタイプをディスクから読み出し、ディスクに書き込
むことができるように、インタフェース定義言語（ＩＤ
Ｌ）によって定義されるタイプとＩＤＬコンパイラを通
してそのＩＤＬタイプを実行することによる出力を、追
加コードの一部とともに使用する。ネームサーバ５２
が、ＯＲＢオブジェクトにネームを指定するために使用
される。クライアントは、例えばクライアント２０とし
てネームサーバ５２を使用し、希望するオブジェクトを
ネームで検索することがある。ネームサーバ５２は、同
様にリクエストをそのオブジェクトに送るために使用す
る可能性があるオブジェクトリファレンスを返す。イン
タフェースリポジトリ４８（ＩＦＲ）は、分散オブジェ
クトシステム内のすべてのオブジェクトに対するすべて
のインタフェースについて承知している。

【００２５】方法テーブル（「ｍ−テーブル」）ディス
パッチを使用してクライアントによって作成されるリク
エストは、図２に示すようにサーバントへ行くときにア
ーキテクチャの多様な前記層を通過するだろう。リクエ
ストは、クライアントによって起動され、任意の適切な
形を取りうる。リクエストの形は、クライアントを作成
するために使用されるプログラミング言語の性質にかな
り依存する。一例として、クライアントがＣ＋＋言語で
作成された場合、要求はＣ＋＋法呼出し６２の形を取る
ことがある。この呼出しは、代用物の形を取る指定され
たオブジェクトリファレンスに対して行われる。代用物
は、オブジェクトのインタフェースに適合する方法を含
む。当業者によって理解されるように、分散オブジェク
トシステム内のさまざまなロケーションで使用されるオ
ブジェクトリファレンスは、外観で大きく変わることが
ある。説明する実施形態においては、クライアント側オ
ブジェクトリファレンスは、二重ポインタ（本文では
「ファット（ｆａｔ）ポインタ」と呼ぶ）である。ファ
ットポインタは、２つの別個のポインタ、即ちロケーシ
ョンインジケータを含む。第１ポインタは、参照された
オブジェクトに対応するクライアント表記（「クライア
ント表記（ｒｅｐ）」）を指す。第２ポインタは、参照
されたオブジェクトに対応する方法テーブルディスパッ
チ２４の方法テーブルを指す。本文で使用されるよう
に、「ポインタ」という用語は、コンピュータ又はネッ
トワークメモリ内のロケーションを特定するだけではな
く、一般的にロケーションインジケータを指すために使
用されることを理解する必要がある。クライアント表記
は、ＣＯＲＢＡによって定義される「擬似」オブジェク
トリファレンス動作だけではなく、起動もサポートする
方法を有するオブジェクトのことである。これらの動作
は、複製法、リリース法、ナロー(narrow)法、ハッシュ
法、及びイズ##イクイバレント(is#equivalent)法を含む
が、それらに限られない。

【００２６】クライアントが呼出しを開始した後、呼出
しは方法テーブルディスパッチ機構２４を使用して処理
される。方法テーブルディスパッチ機構は、１つが起動
される方法に対応するスタブ関数２５に対するポインタ
のリストを含む方法テーブルを使用する。スタブ関数２
５は、クライアントプロセスの「自然」言語で、関数又
は手順呼出しを受け取ってから、サブコントラクト層３
６又は固有呼出しのどちらかを使用し、最終的に対応す
るサーバントオブジェクトを呼び出す。自然言語は、Ｃ
＋＋などの言語等の任意の適切な言語であってよい。

【００２７】方法テーブルディスパッチ２４は、方法呼
出しを処理するために適切なスタブ関数２５を決定して
から、方法呼出しを適切なスタブ関数と一対にする。方
法呼出しを行うクライアントが、サーバントオブジェク
トと同じプロセス内にある場合、ローカルスタブ関数が
呼び出される。ローカルスタブ関数は、方法呼出しを直
接的にサーバントオブジェクト７８に送る。代わりに、
サーバントオブジェクトが別のプロセス、即ちリモート
プロセス内にある場合は、リモートスタブ関数が呼び出
される。リモートスタブ関数はクライアント表記を起動
して、起動をサーバントオブジェクト７８に送達する。

【００２８】サブコントラクト層３６により実現される
サブコントラクトは、分散オブジェクトシステム内で重
要である、オブジェクト起動と引き数渡しの基本的な機
構の制御を提供する論理モジュールである。サブコント
ラクト層３６により実現されたサブコントラクトは、オ
ブジェクトによって使用されるためのサービスの特殊な
質を決定する。サブコントラクトは、通常、オブジェク
トリファレンス内に組み込まれたサブコントラクト識別
子によって一意に識別される。サービスの質とは、サー
ビス特性の集合である。選択することができると考えら
れるサービス特性の中には、サーバ起動、セキュリテ
ィ、トランザクション、濾過性、及びクリーン停止に関
する質がある。サブコントラクトは、一定のサービスの
質が使用できるように構成されている。所定のサービス
の質を使用すると、個々のサービス特性の処理に関連す
るオーバヘッドが削減される。現実的には、「妥当な」
即ち一般的に使用されるサービス特性の組み合わせだけ
がサブコントラクトでサポートされる。しかし、サブコ
ントラクトは、指定された分散オブジェクトシステムの
特殊用件を満たすために作成され得る。

【００２９】サブコントラクト層３６内の適切なサブコ
ントラクトの識別は、そのサブコントラクトに一意であ
る希望される機能の識別と考えてよい。例えば、マーシ
ャル関数又はアンマーシャル関数が、サブコントラクト
ごとに定義される。サブコントラクトマーシャル関数
は、それが別のアドレススペース、即ちドメインに伝送
されるように、オブジェクトリファレンスをマーシャル
するためにスタブによって使用される。オブジェクトリ
ファレンスは、通常、トランスポート層３８内のトラン
スポート機構によって処理される。

【００３０】トランスポート層３８の一部であるＴ１、
Ｔ２などのトランスポート機構は、情報をマーシャル
し、サーバントオブジェクトに対し、及びサーバントオ
ブジェクトから情報を物理的にトランスポートするため
に使用される。情報、即ちオブジェクトリファレンス又
はリクエストは、指定されたドメインに適切なプロトコ
ルに変換される。一例として、プロトコルは、イーサネ
ットプロトコルとインターネット相互運用プロトコル
（ＩＩＯＰ）を含むことがあるが、それらに限定されな
い。いくつかの珍しいケースでは、プロトコルは、サー
バ上で実現される命令を伝送するために、電子メールの
使用を伴うこともある。情報がマーシャルされてから、
トランスポート機構は、分散オブジェクトシステムのク
ライアント側によって使用されるハードウェア７０のす
べての部分である、オペレーティングシステム、デバイ
スドライバ、又はネットワークの任意の組み合わせを通
して情報をトランスポートする。トランスポート機構は
指定されたドメインに適切なプロトコルへの情報の変換
を必要とするが、いくつかのトランスポート機構は、異
なったドメインに対する情報の符号化は必要としない。
その上で情報が発生するドメイン以外のドメインに適切
なプロトコルへの情報の変換を必要としない１つのトラ
ンスポート機構が、「ドア」と呼ばれる。ドアは、本質
的には、同じホスト上での２つの異なったプロセスの間
のゲートウェイである。ドアを使用すると、情報が同じ
ホスト上に残っているため、ドメインの変更を必要とし
ないという事実のおかげで、別の機械によって使用され
る可能性のあるプロトコルに情報を符号化する必要性は
ないので、トランスポート層３８内での正規インプリメ
ンテーションへの情報の変換に対する必要性は排除され
る。従って、情報は、単に「単調化(flatten out)」さ
れる、即ち、別の機械によって使用されるために符号化
されないストリームにマーシャルされ、ホスト上の２つ
のプロセス間で渡される。

【００３１】情報がクライアント側によって使用される
ハードウェア７０を通してトランスポートされると、情
報は分散オブジェクトシステムのサーバ側でハードウェ
ア７０にトランスポートされる。情報がハードウェア７
０を通して送られると、分散オブジェクトシステムのサ
ーバ側が、Ｔ１、Ｔ２などのトランスポート機構を起動
し、トランスポート層３８の一部である端点で情報を受
け取る。端点がトランスポート層３８によって作成され
ない場合、トランスポート層３８は、サブコントラクト
層３６によって作成される端点に必要とされる機能性を
提供する。一例として、ドア端点は、通常、サブコント
ラクト層３６によって作成されるが、ネットワークとＴ
ＣＰ／ＩＰの端点を含むそれ以外の端点は、通常、トラ
ンスポート層３８によって作成される。端点がサブコン
トラクト層３６によって作成されるのか、トランスポー
ト層３８によって作成されるのかに関係なく、端点はト
ランスポート層３８「内部に存在する」、即ちその一部
である。端点は、本質的には、別のドメインから情報を
受け取るポートである。トランスポート層３８内の端点
が別のドメインからトランスポートされる情報を受け取
ってから、端点はその情報をトランスポート層３８から
サブコントラクト層３６にディスパッチする。サブコン
トラクト層３６、又は更に詳細には情報を受け取るサブ
コントラクト層３６内のサブコントラクトは、その後そ
の情報をスケルトンとサーバントにディスパッチする。

【００３２】サブコントラクト層３６は、それが受け取
った情報の少なくとも一部をアンマーシャルする機能を
提供する。即ち、サブコントラクト層３６は、リクエス
トの少なくとも一部をアンマーシャルする。それから、
リクエストは、そのリクエストをサーバントオブジェク
ト７８によって要求されるインプリメンテーションに特
殊なフォーマットに変換するスケルトン３１にディスパ
ッチされる。スケルトンは、前述されるように、静的ス
ケルトン又は動的スケルトンのどちらでもよい。

【００３３】一般的には、リモートリクエストは、前述
されるようにクライアント側とサーバ側を通して送られ
なければならない。方法呼出し６２が受け取られ、方法
テーブルディスパッチ層２４が、リクエストをマーシャ
ルし、それを別のドメインへのトランスポートのために
準備するトランスポート層内のトランスポート機構を選
択する前に適切なサブコントラクトを特定するために使
用される。ハードウェア７０を通して、マーシャルされ
たリクエストは、それがトランスポート層３８の一部で
ある端点で受け取られるサーバ側にトランスポートされ
る。適切な端点は有線で(across a wire)トランスポー
トされる情報を受け取り、情報は、トランスポート層３
８から、それが受け取った情報を少なくとも部分的にア
ンマーシャルする機能性を提供するサブコントラクト層
３６にディスパッチされる。それから、サブコントラク
トは、サーバントオブジェクト７８によって必要とされ
る特殊なフォーマットにリクエストを変換するスケルト
ン３１に、リクエストをディスパッチする。この経路を
矢印７７によって示す。これはリモートリクエストとロ
ーカルリクエストの両方によって取られる可能性のある
経路である。

【００３４】しかし、クライアントとサーバがローカル
プロセス内にある場合、即ちクライアントとサーバの両
方が同じプロセス内にある場合、前述されるように矢印
７７により示される経路を使用することは不必要に複雑
である。クライアントとサーバが同じプロセス内にある
ことが既知である場合には、起動、即ちフロー、サービ
スに対するリクエストの経路を短縮することができる。
オブジェクトリファレンスが作成されるときにローカル
プロセスが特定される場合、短縮されたフロー経路、即
ち矢印７５と７６によって表される経路が、同じプロセ
ス上にあるクライアントからサーバへであることからリ
クエストを送るために取られることがある。矢印７６に
よって表される経路は、それが適切なサブコントラクト
を特定するためにサブコントラクト層３６を使用するの
で取られやすい。ただし、適切なサブコントラクトが明
示的に特定される必要がない状況では、矢印７５によっ
て表される経路が取られる可能性がある。

【００３５】オブジェクトリファレンスの実施形態を説
明するために図３を用いて説明する。当業者によく知ら
れるように、オブジェクトリファレンスは、任意の指定
された時点で保持されているプロセス内でのロケーショ
ンに応じて多様な形を取ることがある。しかし、背景と
して、図１に関して前述したように、システム内で使用
するための代表的なオブジェクトリファレンスを図３に
示す。そこに図示されるインプリメンテーションにおい
ては、オブジェクトリファレンス１５０は、ホスト識別
子１５２、ポート指定(designation)１５４、及びオブ
ジェクトキー１５６を含む。オブジェクトキー１５６
は、サブコントラクト識別子１５８、サーバ識別子１６
０、インプリメンテーション識別子１６２、及びユーザ
キー１６４を含む。ホスト識別子１５２はネットワーク
内のある特定のコンピュータを示すが、ポート指定１５
４は通信用に使用されなければならない選択されたコン
ピュータのポートを特定する。オブジェクトキー１５６
は、そのホスト機械上で希望されるサーバントオブジェ
クトの位置を見つけ出すために使用される更なる識別情
報を提供する。

【００３６】サーバ識別子１６０は、その中にサーバン
トオブジェクトが常駐するある特定のプロセス又はプロ
グラムを指定するが、ユーザキー１６４はサーバ識別子
１６０によって指定されるプロセス内でサーバントの位
置を見つけ出すために使用される一意の数、即ち文字列
である。サブコントラクト識別子１５８は、ある特定の
サブコントラクトのプロトコルとその対応するサービス
をサーバントに結び付けるために使用され、インプリメ
ンテーション識別子１６２はそのサーバントオブジェク
トとともに使用されなければならないインタフェースの
インプリメンテーションを指定する。

【００３７】一般的には、１つのプロセス内のクライア
ントは、例えばサーバプロセスなどの別のプロセスに対
応するオブジェクトリファレンス上で起動する場合があ
る。即ち、非局所的な起動は、前述された、図１の分散
オブジェクトシステム１０によってサポートされる。サ
ーバプロセスがクライアントプロセスから起動を受け取
ると、サーバプロセスは起動をアンパックし、適切なサ
ーバントの位置を見つけ出し、起動をサーバントに転送
する。起動は、通常、クライアントによって指定された
パラメータとともにサーバントに転送される。サーバン
ト上での起動が完了すると、ＯＲＢオブジェクトインプ
リメンテーションが、起動によって作成された実質的に
はあらゆる出力値を収集し、出力をクライアントに転送
する。

【００３８】図１の静的なスケルトン３２等のスケルト
ンは、本来、非局所的な起動を実行するための、ＯＲＢ
オブジェクトインプリメンテーションとサーバントの間
のリンクとして役立つ。スケルトンは、通常、サーバン
トによってサポートされなければならないインタフェー
スに関する知識をもってＩＤＬコンパイラによって作成
される。スケルトンに対応するタスクは幅広く変わるこ
とがあるが、スケルトンに対応するタスクは、一般的に
は、起動用のパラメータについてＯＲＢに知らせるこ
と、パラメータを使ってサーバントを起動すること、及
び起動中に発生するあらゆる例外を記憶することだけで
はなくキャッチすることを含む。

【００３９】起動中、エラー条件即ち例外条件が発生す
ると、例外が発生する可能性がある。例外は、通常、サ
ーバントによって、又は起動に対応するＯＲＢインプリ
メンテーションによって生じる。一般的には、例外は、
固定フォーマットであるシステム例外又は固定フォーマ
ットではないユーザ例外のどちらでもよい。システム例
外はＣＯＲＢＡ内で定義される標準的な例外を含むが、
ユーザ例外、即ち利用者定義例外は、ユーザによって指
定されるＩＤＬによって作成される例外である。記載し
た実施形態では、「ＣＯＲＢＡ例外」はシステム例外と
ユーザ例外の両方を含む。

【００４０】図１に関して前述したアーキテクチャ内で
は、スケルトンは、前述されるように、非局所的な起動
を実行するためのＯＲＢインプリメンテーションとサー
バの間のリンクとして使用される。非局所的な起動用
の、ＩＤＬコンパイラによって作成されるスケルトンコ
ードは、図７と図８に関して後述するように、一般的に
は、カスタマイズポイントを提供することによって起動
に備えることを含むが、それに限られない多様な異なる
タスクを実行するために配列される可能性がある。ま
た、説明した実施形態においては、スケルトンコード
は、発生した例外をキャッチし、記憶し、起動後カスタ
マイズポイントを呼び出し、ＯＲＢがクライアントへの
トランスポートのために例外をパックするように、例外
を発生させるように配列される。当業者によって理解さ
れるように、パックされる例外は、クライアントがサー
バントを起動すると、例外の発生となるクライアントに
トランスポートされる。

【００４１】ある実施形態においては、起動後カスタマ
イズポイントは、例外が発生したかどうかに関係なくつ
ねに呼び出される。そのようなものとして、一般的に発
生する例外は、起動後カスタマイズポイントが呼び出さ
れてしまうまで一時的に記憶される。起動後カスタマイ
ズポイントは、例外が発生したかどうかに関係なく、起
動後カスタマイズポイントが呼び出されるように、スケ
ルトンコード内で複数回挿入されることがある。しか
し、コードが最適化されるときに起動後フックがコード
の中に組み込まれるので、複数の起動後カスタマイズポ
イントはコードの膨張につながる可能性がある。複数の
ロケーションに起動後カスタマイズポイントを挿入する
ことによって、スケルトンコードが実行する速度は加速
されるが、速度の上昇は、大部分の場合潜在的なコード
膨張を補償しない。図４に関して、クライアントからの
起動リクエスト等のリクエストを処理することに関連す
るステップが説明される。プロセスは、スケルトンがト
ランスポートからメッセージを受け取るステップ２０２
で開始する。一度メッセージがスケルトンによって受け
取られると、メッセージ中の入力パラメータが、ステッ
プ２０４で受け取られたメッセージからアンマーシャル
される。受け取られたメッセージからアンマーシャルさ
れた入力パラメータを使用すると、リクエストは、ステ
ップ２０６でサーバント、即ちターゲットオブジェクト
にディスパッチされる。当業者によって理解されるよう
に、リクエストはスケルトンによってサーバントにディ
スパッチされる。

【００４２】メッセージがサーバントにディスパッチさ
れてから、ステップ２０８で、リクエストが「例外」を
発生される、即ち「含む」かどうかに関する決定が下さ
れる。具体的には、サーバントへリクエストをディスパ
ッチした結果、例外が生じるかどうかに関する決定が下
される。リクエストが例外を含まないと決定される場合
には、プロセスフローは、ステップ２０８から、リクエ
ストからの出力パラメータがメッセージ中にマーシャル
されるステップ２１４に移動する。出力パラメータがメ
ッセージの中にマーシャルされると、メッセージはステ
ップ２１６内のクライアントに送られ、クライアントか
らのリクエストの処理が完了する。

【００４３】代わりに、ステップ２０８内で、リクエス
トが実際に例外を発生させたと決定される場合には、ス
テップ２１０では、例外はメッセージの中にマーシャル
される。それから、メッセージはステップ２１２でクラ
イアントに送られ、クライアントからのリクエストのス
テップ処理が完了する。

【００４４】例外が、起動中に、又は実質的には任意の
他のときに生じると、例外が、スケルトン中の例外処理
節の外側で使用できるようになることが望ましい。例え
ばＣ＋＋環境等のいくつかのプログラミング言語環境
は、例外オブジェクトの実行時コピーを作成するために
配列される。しかし、例外オブジェクトの実行時コピー
を例外スタック、即ちヒープ内で作成し、記憶すること
は、大部分の場合非効率的であり、例外が、使用が遅延
される場合に使用可能のままでなければならない場合に
は、メモリ漏れが生じる可能性がある。

【００４５】例外オブジェクトのコピーは、例外オブジ
ェクトが、後で使用するためにアクセスできるように、
例外ヒープから離れて作成され、記憶してよい。例外が
再スロー(rethrown)されなければならない場合、例外オ
ブジェクトのコピーは、メモリ漏れを回避するために削
除されることがある。図５に関して、ＣＯＲＢＡで指定
される方法を使用して例外オブジェクトのコピーを作成
するプロセスが、本発明の実施形態に従って説明され
る。Ｃ＋＋環境で定義されるｔｒｙ＿ｃａｔｃｈフレー
ズ２５０は、トライブロック２５２とキャッチブロック
２５６とを含む。トライブロック２５２は、通常、例外
を生じさせる動作を実行するコードを含む。ｃａｔｃｈ
ｓｔａｔｅｍｅｎｔ２５４は、ｔｒｙ＿ｃａｔｃｈフ
レーズ２５０に対応する例外をキャッチするために配列
される。キャッチブロック２５６内では、コピーステー
トメント２５８が、ｃａｔｃｈ ｓｔａｔｅｍｅｎｔ２
５４によってキャッチされた例外をコピーするために配
列される。

【００４６】例外のコピーがコピーステートメント２５
８を使用して作成されてから、例外は、通常、キャッチ
ブロック２５６内で処理される。例えば、一定の例外は
「許容できる」と見なされ、考えられるところでは無視
されるだろうが、他の例外はデバッグの目的のために統
計の訂正で使用されることがある。コピーステートメン
ト２５８を使用して作成される例外のコピーは、キャッ
チブロック２５６の外に存在する。言い替えると、例外
のコピーは、ｔｒｙ＿ｃａｔｃｈフレーズ２５０の範囲
の外に存在する。キャッチブロック２５６の実行が完了
すると、図６に関して以下に更に詳細に説明されるよう
に、ｔｈｒｏｗ＿ａｎｄ＿ｄｅｌｅｔｅルーチン２６０
がコピーされた例外をスローし、コピーされた例外を削
除するために実行される。

【００４７】ｔｈｒｏｗ＿ａｎｄ＿ｄｅｌｅｔｅルーチ
ン２６０は、一般的には、コピーステートメント２５８
を使用して作成されるコピーされた例外を発生させ、Ｃ
＋＋実行時環境によって作成される例外のコピーをキャ
ッチし、コピーステートメント２５８を使用して作成さ
れるコピーされた例外を削除し、Ｃ＋＋実行時環境によ
って作成される例外のコピーを再スローする、例外処理
サブルーチンである。図６は、本発明の実施形態に従っ
た図５の例外処理サブルーチンの概略図である。ｔｈｒ
ｏｗ＿ａｎｄ＿ｄｅｌｅｔｅサブルーチン２８０は、あ
る実施形態では図５のコピーステートメントを使用して
コピーされた例外である可能性がある、ＣＯＲＢＡ＿ｅ
ｘｃｅｐｔｉｏｎ“ｅｘｃ”２８２を引き数として解釈
する。

【００４８】ｔｈｒｏｗ＿ａｎｄ＿ｄｅｌｅｔｅサブル
ーチン２８０は、ｔｒｙ＿ｃａｔｃｈフレーズ２８４を
含む。ｔｒｙ＿ｃａｔｃｈフレーズ２８４のトライブロ
ック２８６内では、コピーされた例外ｅｘｃ２８２が適
宜にスローされ、例外の実行時コピーが作成される。具
体的には、コピーされた例外ｅｘｃ２８２が、一般的に
は固定長であるシステム例外である場合には、コピーさ
れた例外２８２は、スローコマンドを使用してシステム
例外としてスローされる。スローコマンドは、オブジェ
クト、即ち例外オブジェクトをスローし、本質的には、
オブジェクトを例外ヒープにコピーする。代わりに、コ
ピーされる例外ｅｘｃ２８２が、一般的には固定長では
ない利用者定義例外である場合には、コピーされた例外
ｅｘｃ２８２は利用者定義例外として発生する。ＩＤＬ
コンパイラによって生成される発生サブルーチンは、本
来、利用者定義例外をスローするために使用されること
がある。記載した実施形態においては、利用者定義例外
は、通常、システム例外をスローするため、又は発生さ
せるために使用される同じコマンドを使用してスローさ
れたり、発生したりしない。利用者定義例外が、システ
ム例外をスローするために使用される同じスローコマン
ドを使用してスローされると、例えば、利用者定義例外
は、スローコマンドへの呼出し中に「スライス」される
可能性がある。言い替えると、利用者定義例外のすべて
が呼出しに渡されるわけではなく、即ちその例外を最終
的に受け取らなければならないクライアント向けの情報
が失われる可能性があるということである。

【００４９】ｃａｔｃｈ ｓｔａｔｅｍｅｎｔ２９０
は、実質的には任意の例外をキャッチするために配列さ
れる。ｔｒｙ＿ｃａｔｃｈフレーズ２８４内では、ｃａ
ｔｃｈｓｔａｔｅｍｅｎｔ２９０が、トライブロック２
８６でスローされた例外をキャッチするために配列され
る。キャッチブロック２８８内では、コピーされた例外
ｅｘｃ２８２が削除され、ｃａｔｃｈ ｓｔａｔｅｍｅ
ｎｔ２９０によってキャッチされる例外がスローされ
る。ある実施形態では引き数なしで呼び出されるスロー
コマンドは、ｃａｔｃｈ ｓｔａｔｅｍｅｎｔ２９０に
よってキャッチされる例外をスローするために配列さ
れ、例外のコピーを作成することを必要としない。その
ようなものとして、コピーされた例外ｅｘｃ２８２が削
除され、ｃａｔｃｈ ｓｔａｔｅｍｅｎｔ２９０によっ
てキャッチされる例外がスローされると、コピーされた
例外に対応する記憶域が効果的に再生利用される。

【００５０】具体的には、ｔｈｒｏｗ＿ａｎｄ＿ｄｅｌ
ｅｔｅサブルーチン２８０の実行中、ある特定の例外が
２回スローされる。即ち、ｔｈｒｏｗ＿ａｎｄ＿ｄｅｌ
ｅｔｅサブルーチン２８０の中に渡される例外のコピー
はスローされ、ｃａｔｃｈｓｔａｔｅｍｅｎｔ２９０に
よってキャッチされる例外の「コピー」もスローされ
る。例外を処理するためのｔｈｒｏｗ＿ａｎｄ＿ｓｕｂ
ｒｏｕｔｉｎｅ２８０に対応するステップを、図９に関
して以下に更に詳細に説明する。

【００５１】図７と図８は、本発明の実施形態に従った
スケルトンディスパッチの実行に関連するステップを説
明するプロセスフロー図を表す。記載した実施形態で
は、スケルトンディスパッチ関数を実行することによっ
て、コードの外部に提供されるモジュールがスケルトン
ディスパッチ関数のコンテキストで実行できるようにな
る。スケルトンディスパッチ関数の起動は、カスタムオ
ブジェクトが構築されるステップ３０２で開始する。言
い替えると、あらゆるカスタムオブジェクト、即ち開発
者によって提供されるアプリケーションコードのモジュ
ールが構築される。カスタムオブジェクトが存在しない
場合には、カスタムオブジェクトが構築されないことが
理解される必要がある。ステップ３０４では、カスタム
プレディスパッチ（ＣＵＳＴＯＭ．ＰＲＥ＿ＤＩＳＰＡ
ＴＣＨ）法への呼出しが行われる。カスタムプレディス
パッチ法は、一般的には、アプリケーション開発者によ
って提供される方法であり、通常は、スケルトンディス
パッチ関数に対する呼出しの中で引き数として渡される
ユーザキーを使用し、ある特定の方法を起動するために
使用するための適切なサーバントを決定する。ユーザキ
ーは、図３に関して前述したように、通常、オブジェク
トリファレンスに含まれる。ある実施形態においては、
起動される特定の方法は、一般的には、方法記述子内で
識別される。マーシャルバッファから抽出されることが
ある方法記述子は、クライアントが起動を望むサーバン
ト上で定義される、クライアントによって理解されるよ
うな方法名を保持するデータ構造である。

【００５２】カスタムプレディスパッチ法を含めること
を可能にするための準備は、「カスタムフック」即ちカ
スタマイズポイントを使用することにより可能である。
カスタムフックによって、外部コードはスケルトン起動
方法に対する呼出しの一部に挿入され、呼出しの一部と
して実行できるようになる。このカスタムフックは、他
のものと同様に、スケルトンディスパッチ法に対する呼
出しの一部として外部コードを効率的に実行できるよう
にするために提供されることが理解されなければならな
い。

【００５３】カスタムプレディスパッチ法への呼出し
後、プロセスフローは、ステップ３０４から、スケルト
ンディスパッチ関数への呼出しがそれを使って行われる
方法記述子に一致することがあるアンマーシャル機構が
選択されるステップ３０６に移動する。いくつかの実施
形態においては、アンマーシャル機構は、交換ステート
メントによって選択されるコードのシーケンスである。
スケルトンディスパッチ関数が呼び出されるときまで
に、マーシャルバッファ内に記憶された実質的にはすべ
てのそれ以外の情報が、過去にマーシャルバッファから
抽出されたことがある。従って、この時点でマーシャル
バッファ内に残っている情報だけが、呼び出される方法
によって使用される引き数である。

【００５４】ステップ３０８では、選択されたアンマー
シャル機構が、マーシャルバッファの残りを起動引き数
にアンマーシャルするために使用される。起動引き数が
得られてから、ステップ３１０で、カスタムプレ動作
（ＣＵＳＴＯＭ．ＰＲＥ＿＜＜ＯＰＥＲＡＴＩＯＮ＞
＞）法への呼出しが行われる。「動作」のネームは、呼
び出されるＩＤＬ法のネームに依存する。動作が読取り
ロック又は書込みロックのどちらかの取得である実施形
態もある。読取りロックは、書込み動作が任意の指定さ
れたときにグローバル変数上で発生しないようにするた
めに使用されることがあり、一方書込みロックは、あら
ゆる読取り動作と複数の書込み動作が任意の指定された
ときにグローバル変数上で発生しないようにするために
使用されることがある。カスタムプレ動作法に対する呼
出しは、カスタムフックに対応する。即ち、外部カスタ
ムプレ動作コードがユーザによって提供される場合、カ
スタムフックはアクティブであると見なされ、外部カス
タムプレ動作コードが実行される。

【００５５】カスタムプレ動作法への呼出し後、ステッ
プ３１２では、方法記述子が、起動引き数を使用してサ
ーバント上で定義される方法を起動するために使用され
る。起動引き数を使用してサーバント内で方法を起動す
ると、通常、クライアントによって最初に要求された方
法を実行するという効果がもたらされる。起動された方
法が値を返さず、代わりに他の関数を実行することが考
えられるか、あるいは方法がクライアントに値を返すこ
とがある。実施形態によっては、カスタムプレ動作法が
使用されるときに、起動された方法が、方法の起動がカ
スタムプレ動作法の一部であるため、あらゆる関数を実
行しないことがある。

【００５６】サーバント内の方法が起動された後、プロ
セスフローは、ステップ３１４に移動し、例外がサーバ
ント内での方法の起動中に発生したかどうかに関する決
定が下される。例外が発生したと決定される場合には、
ステップ３２０で、カスタムセット例外（ＣＵＳＴＯ
Ｍ．ＳＥＴ＜＜ＥＸＣＥＰＴＩＯＮ＞＞）法に対する呼
出しが行われる。当業者によって理解されるように、
「例外」のネームは発生した例外の特定のタイプに依存
している。記載した実施形態においては、カスタムセッ
ト例外法は、発生した例外のコピーを作成するために使
用される。

【００５７】例外フラグは、発生した例外のコピーが作
成された後に、ステップ３２２で例外が発生したことを
示すためにセットされる。言い替えると、通常、カスタ
ムオブジェクトの構築中に「偽」に初期化される例外フ
ラグは、「真」にセットされる。例外フラグが「真」に
セットされると、ステップ３２４では、カスタムポスト
動作（ＣＵＳＴＯＭ．ＰＯＳＴ＿＜＜ＯＰＥＲＡＴＩＯ
Ｎ＞＞）法に対する呼出しが行われる。「動作」のネー
ムは、呼び出されたＩＤＬ法のネームに依存する。カス
タムポスト動作法は、カスタムプレ動作法と一対にされ
る。言い替えると、カスタムプレ動作法が存在する場
合、通常、カスタムポスト動作法も存在しなければなら
ない。また、カスタムプレ動作法の場合でのように、カ
スタムポスト動作法を含むことは、カスタムフックの使
用によって可能にされる。カスタムプレ動作法が、読出
しロック又は書込みロックのどちらかの取得を必要とす
る実施形態においては、対応するカスタムポスト動作法
は、通常、それぞれ読取りロック又は書込みロックのリ
リースを必要とする。

【００５８】カスタムポスト動作法がステップ３２４で
呼び出された後に、起動された方法が返信を作成するか
どうかに関しての決定がステップ３２６で下される。返
信が作成される場合、制御は、方法記述子に一致する適
切なマーシャル機構が選択されるステップ３２８に移
る。マーシャル機構が選択されると、選択されたマーシ
ャル機構は、ステップ３３０で返信をマーシャルバッフ
ァの中にマーシャルするために使用される。返信が、オ
ブジェクトリファレンスを記憶していたマーシャルバッ
ファより多くのバイトを含んでいる場合には、新しいマ
ーシャルバッファが作成され、返信がカプセル化され
る。それ以外の場合、返信は、通常、リクエストを記憶
していたマーシャルバッファの中にマーシャルされる。

【００５９】返信がマーシャルバッファの中にマーシャ
ルされた後で、ステップ３３１でカスタムポストディス
パッチ（ＣＵＳＴＯＭ．ＰＯＳＴ＿ＤＩＳＰＡＴＣＨ）
法に対する呼出しが行われる。カスタムプレディスパッ
チ法と一対にされるカスタムポストディスパッチ法は、
リファレンスカウントを含むが、それに限られない目的
のために使用されることがある。即ち、カスタムポスト
ディスパッチ法は、通常、カスタムポストディスパッチ
法が呼び出される時点で方法を実行しているスレッドの
数を数えるという意味で、方法を実行するために使用さ
れるスレッドを把握するために使用される。記載した実
施形態においては、カスタムポストディスパッチ法は、
例外を処理することを含む。例外を処理するための１つ
の適切な方法は、図９に関して以下に説明される。再
び、カスタムフックが、カスタムポストディスパッチ法
に関するアプリケーションコードを含むことを可能にす
るために使用される。カスタムポストディスパッチ法に
対する呼出しが行われると、トランスポート層からクラ
イアントへ返信が返される準備ができる。

【００６０】ステップ３３１でのカスタムポストディス
パッチ法への呼出しは、記載した実施形態においてはサ
ブステップ３３２と３３４を含む。ステップ３３２は、
例外フラグが偽にセットされるかどうかに関する決定で
ある。前述されたように例外フラグは、サーバント内の
方法の起動中に例外が発生したかどうかを示すためにセ
ットされる。例外フラグが偽であると決定される場合に
は、例外は発生しなかったと表示される。従って、例外
は処理されず、スケルトンディスパッチ関数の実行に関
連するステップが完了する。

【００６１】代わりに、ステップ３３２で、例外フラグ
が真にセットされると決定されると、例外が発生したと
表示される。従って、プロセスフローは、ステップ３３
２から、例外を処理するために準備が行われるステップ
３３４に移動する。例外を処理することに関連するステ
ップを、図９に関連して以下に説明する。例外が処理さ
れた後、スケルトンディスパッチ関数の実行は、実際上
完了する。

【００６２】ステップ３２６に戻ると、返信が方法から
作成されないと決定される場合には、プロセス制御は、
カスタムポストディスパッチ法に対する呼出しが行われ
るステップ３３１に進む。カスタムポストディスパッチ
法への呼出し後、スケルトンディスパッチに関連するス
テップは完了し、返信は、本質的には、トランスポート
層を介して要求側クライアントに返される準備が完了し
ている。

【００６３】次に図９を参照して、例外を処理すること
に関連するステップ、即ち図８のステップ３３４を、本
発明の実施形態に従って説明する。プロセスは、例外を
キャッチするために準備がなされるステップ４０２で開
始する。記載した実施形態においては、例外をキャッチ
するために準備することは、ｔｒｙ＿ｃａｔｃｈブロッ
クを開始することを含む。ｔｒｙ＿ｃａｔｃｈブロック
の例は、図６のｔｈｒｏｗ＿ａｎｄ＿ｄｅｌｅｔｅサブ
ルーチンに関して前述された。例外をキャッチするため
に準備がなされた後、システム例外がｔｒｙ＿ｃａｔｃ
ｈブロックに渡されたかどうかに関する決定が、ステッ
プ４０４で下される。

【００６４】システム例外が渡されたと決定される場合
には、プロセスフローは、例外がシステム例外としてス
ローされるステップ４０６に移動する。当業者によって
理解されるように、Ｃ＋＋環境においては、例外のコピ
ーは実行時に作成される。例外がシステム例外としてス
ローされると、例外のコピーはステップ４０８で「キャ
ッチされる」。記載した実施形態においては、例外のコ
ピーはｔｒｙ＿ｃａｔｃｈブロックの「キャッチ」部分
でキャッチされる。例外のコピーがキャッチされた後、
最初に渡された例外が、最初に渡された例外によって占
有されていたメモリを再生利用するためにステップ４１
０で削除される。それから、ステップ４１２では、コピ
ーされた例外がスローされる。即ち、ｔｒｙ＿ｃａｔｃ
ｈブロックのキャッチ部分でキャッチされた例外がスロ
ーされ、カスタムポストディスパッチ法を呼び出すプロ
セスが完了する。

【００６５】ステップ４０４に戻ると、システム例外が
渡されなかったと決定される場合には、記載した実施形
態では、ユーザ例外が渡されたと暗示される。ユーザ例
外は、ユーザによって定義される例外であり、システム
例外とは異なり、任意の長さでよい。従って、ユーザ例
外をスローするために使用される例外スロー機構は、一
般的には、システム例外をスローするために使用される
機構とは異なる。ユーザ例外が渡されたと決定される
と、プロセスフローが、ステップ４０４から、例外がユ
ーザ例外としてスローされるステップ４１４に移動す
る。システム例外の場合でのように、例外、即ちユーザ
例外のコピーが実行時に作成される。例外がユーザ例外
としてスローされた後、プロセスフローは、例外の実行
時コピーがキャッチされるステップ４０８に進む。

【００６６】本発明は、一般的には、任意の適切なコン
ピュータシステム上で実現されるであろう。図１０に、
本発明を実現するために適切な典型的な汎用コンピュー
タシステムを示す。コンピュータシステム５３０は、一
次記憶装置５３６（通常は読取り専用メモリ、即ちＲＯ
Ｍ）と、一次記憶装置５３４（通常はランダムアクセス
メモリ、即ちＲＡＭ）を含むメモリ素子にバインドされ
るプロセッサ５３２（中央演算処理装置、即ちＣＰＵと
も呼ばれる）を含む。

【００６７】当該技術分野でよく知られているように、
ＲＯＭはデータと命令を単一方向でＣＰＵ５３２に転送
するために動作するが、ＲＡＭは、通常、データと命令
を双方向で転送するために使用される。記憶装置５３４
と５３６の両方とも任意の適切なコンピュータ読取り可
能媒体を含むことがある。通常は大容量メモリ素子であ
る二次記憶装置媒体５３８も双方向でＣＰＵ５３２にバ
インドされ、補助的なデータ記憶容量を提供する。大容
量メモリ素子５３８は、コンピュータコード、データ、
及び類似物を含むプログラムを記憶するために使用され
るコンピュータ読取り可能媒体である。通常、大容量メ
モリ素子５３８は、ハードディスク、又は一般的には一
次記憶装置５３４，５３６より低速であるテープ等の記
憶装置媒体である。大容量記憶装置５３８は、磁気テー
プ読取り装置又は用紙読取り装置、あるいは他の周知デ
バイスの形を取ることがある。大容量メモリ素子５３８
内に保持される情報が、適切な場合には、仮想メモリと
してＲＡＭ５３６の一部として標準様式で実装されるこ
とがあることが理解されるだろう。ＣＤ−ＲＯＭ等の特
殊な一次記憶装置５３４も、データを単一方向でＣＰＵ
５３２に渡すことができる。

【００６８】ＣＰＵ５３２は、１以上の入力／出力装置
５４０にも接続され、当該入力／出力装置５４０は、ビ
デオモニタ、トラックボール、マウス、キーボード、マ
イクロフォン、接触式ディスプレイ、変換器カード読取
り装置、磁気テープ読取装置又は用紙読取装置、タブレ
ット、スタイラス、音声又は筆跡認識装置等のデバイ
ス、あるいは言うまでもなく他のコンピュータ等のそれ
以外の周知の入力装置を含むがそれらに限られない。最
終的に、ＣＰＵ５３２は、オプションで、コンピュータ
や、一般的には５１２で図示されるようなネットワーク
コネクションを使用して、インターネットネットワーク
又はイントラネットネットワーク等の電気通信網に接続
されることがある。このようなネットワークコネクショ
ンを使用する場合、ＣＰＵ５３２が、ネットワークから
情報を受け取るか、あるいは前述された方法ステップを
実行する過程で、ネットワークに情報を出力することが
あることが企図される。大部分の場合、ＣＰＵ５３２を
使用して実行される命令のシーケンスとして表されるこ
のような情報は、例えば、搬送波で実現されるコンピュ
ータデータ信号という形でネットワークから受け取ら
れ、ネットワークに出力されるであろう。前述されたデ
バイス及び材料は、コンピュータハードウェアとソフト
ウェアの技術の当業者にはよく知られているだろう。

【００６９】ある実施形態においては、命令のシーケン
スは、ＣＰＵ５３２と、例えばネットワークコネクショ
ン５１２全体でＣＰＵ５３２と通信しているＣＰＵ等の
他のＣＰＵ上で、実質的に同時に実行されることがあ
る。具体的には、前述された方法ステップは、コンピュ
ータネットワーク全体で実行されるであろう。

【００７０】本発明の数個の実施形態だけが説明した
が、本発明が、本発明の精神又は範囲を逸脱することな
く、それ以外の多くの特殊な形で実現されることがある
ことが理解されなければならない。一例として、本発明
に従ってスケルトンディスパッチ関数を実行することに
関連するステップは、並べ替えられることができる。ス
テップは、一般的には、本発明の精神又は範囲を逸脱す
ることなく、改変、追加、及び削除されることができ
る。例えば、例外フラグが偽にセットされているかどう
かを決定するチェックは、例外を処理することに関連す
るコードが複製される場合は、排除されることも可能で
ある。しかし、例外フラグをチェックするステップを排
除することは、コードの複製は、いくつかの実施形態に
おいては、重大なコード膨張を引き起こすことがあるた
め、必ずしも、スケルトンディスパッチ関数を実行する
総体的な効率を改善しない可能性がある。

【００７１】本発明の方法は、Ｃ＋＋環境における例外
のスローを延期するという点から説明されてきたが、方
法が、一般的には任意の適切な環境に適用可能であるこ
とが理解されなければならない。例えば、本発明は、例
外のスローが遅延されるように、例外が一時的に記憶さ
れなければならない環境において実現されることがあ
る。従って、記載した実施形態は制限的ではなく例示的
として解釈されなければならず、本発明は、請求項及び
同等のその完全な範囲によって定められなければならな
い。

【図面の簡単な説明】

本発明及び更なる利点は、以下の添付図面とともに上記
説明を参照することにより最良に理解されるであろう。

【図１】 分散オブジェクトシステムを記号化した概略
図である。

【図２】クライアントによるリクエストが、分散オブジ
ェクトシステムのクライアント側とサーバ側のアーキテ
クチャ、及び分散オブジェクトシステムのクライアント
側とサーバ側の間のインタフェースを通してどのように
送られるのかを表した図である。

【図３】オブジェクトリファレンスの概略図である。

【図４】クライアントからのリクエストを処理すること
に関連するステップを示す、プロセスフロー図である。

【図５】本発明の実施形態に従って例外処理サブルーチ
ンを呼び出すコードセグメントの概略図である。

【図６】本発明の実施形態に従った、図３の例外処理サ
ブルーチンの概略図である。

【図７】本発明の実施形態に従ったスケルトンディスパ
ッチの実行に関連するステップを示す、プロセスフロー
図である。

【図８】本発明の実施形態に従ったスケルトンディスパ
ッチの実行に関連するステップを示す、プロセスフロー
図である。

【図９】例外、即ち本発明の実施形態に従った図８のス
テップ３３４を処理することに関連するステップを示す
プロセスフロー図である。

【図１０】本発明を実現するために適切なコンピュータ
システムの概略図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ケン ジー．カヴァナフ アメリカ合衆国， カリフォルニア州， モンタラ， ピー．オー．ボックス 371480

Claims (15)

【特許請求の範囲】
1. 【請求項１】 オブジェクトベースシステム内での第１
   オブジェクトの起動中に発生する例外を、前記オブジェ
   クトベースシステムで処理するための方法であって、 前記例外をキャッチすることと、 メモリ内に前記例外の第１コピーを記憶することを含ん
   だ、前記例外の前記第１コピーを作成することと、 前記例外の実行時コピーを作成して、前記例外の前記実
   行時コピーを実行ヒープに記憶することによって、前記
   例外の前記第１コピーを処理することと、 前記例外の前記実行時コピーをキャッチすることと、 前記例外の前記第１コピーを前記メモリから削除するこ
   とと、 前記例外のキャッチされた前記実行時コピーを再処理す
   ることと、を含む方法。
2. 【請求項２】 前記例外の前記第１コピーを処理するこ
   とが、前記例外の前記第１コピーをシステム例外として
   スローし、もって前記例外の前記実行時コピーを作成す
   ることと、前記例外の前記第１コピーを利用者定義例外
   としてスローし、もって前記例外の前記実行時コピーを
   作成することの内の何れか１つを含む、請求項１に記載
   の方法。
3. 【請求項３】 前記例外の前記キャッチされた実行時コ
   ピーを再処理することが、 前記例外の前記キャッチされた実行時コピーを再スロー
   すること、を含む、請求項１又は２の何れか１項に記載
   の方法。
4. 【請求項４】 前記例外の前記実行時コピーが、前記例
   外のＣ＋＋実行時コピーである、請求項１〜３の何れか
   １項に記載の方法。
5. 【請求項５】 分散クライアント／サーバベースコンピ
   ューティングシステムのサーバ上にあるスケルトン層内
   のスケルトンにディスパッチされるリクエストを処理す
   るための方法であって、 分散クライアント／サーバベースコンピューティングシ
   ステムに挿入されるアプリケーションコードのモジュー
   ルである、前記リクエストに関したカスタムオブジェク
   トを構築することと、 前記リクエストで指定された呼び出された方法を起動す
   るために使用するための適切なサーバントを決定するた
   めに使用される、前記カスタムオブジェクトに対応した
   カスタムプレディスパッチ法を呼び出すことと、 マーシャルバッファ内の起動引き数を使用して、前記リ
   クエストに対応した前記サーバント内で呼び出された前
   記方法を起動することと、 前記例外が呼び出された前記方法の起動中に発生すると
   きに前記例外を処理するために使用される、前記カスタ
   ムオブジェクトに対応した前記カスタムポストディスパ
   ッチ法を呼び出すことと、を含む方法。
6. 【請求項６】 前記呼び出された方法の起動中に例外が
   発生する場合に、例外の第１コピーを作成することを更
   に含む、請求項５に記載の方法。
7. 【請求項７】 前記カスタムポストディスパッチ法を呼
   び出すことが、 前記例外の実行時コピーを作成することによって前記例
   外の前記第１コピーをスローすることを含み、前記例外
   の前記実行時コピーが実行ヒープ上に記憶され、 前記呼び出すことが、 前記例外の前記実行時コピーをキャッチすることと、 前記例外の前記第１コピーを削除することと、 前記例外の前記キャッチされた実行時コピーを再スロー
   することと、を更に含む、請求項６に記載の方法。
8. 【請求項８】 前記例外の前記第１コピーをキャッチす
   るために配列されるｔｒｙ＿ｃａｔｃｈブロックを開始
   することと、 前記例外がシステム例外であるかどうかを決定すること
   と、を更に含む、請求項７に記載の方法。
9. 【請求項９】 前記例外の前記第１コピーをスローする
   ことが、 前記例外がシステム例外であるときに、前記例外の前記
   第１コピーをシステム例外としてスローすることと、 前記例外がシステム例外ではないと決定されるときに、
   前記例外の前記第１コピーをユーザ例外としてスローす
   ることと、を含む、請求項７又は請求項８の何れか１項
   に記載の方法。
10. 【請求項１０】 コンピューティングシステムのサーバ
    上のスケルトン層内にあるスケルトンにディスパッチさ
    れるリクエストを処理するために配置された分散オブジ
    ェクトベースコンピューティングシステムであって、 プロセッサと、 前記コンピューティングシステムの中に挿入されたアプ
    リケーションコードのモジュールである、前記リクエス
    トに関するカスタムオブジェクトと、 前記リクエスト内で指定された呼び出された方法を起動
    するために使用する適切なサーバントを決定するために
    使用される、カスタムオブジェクトに対応したカスタム
    プレディスパッチ法を呼び出すための機構と、 前記アンマーシャル機構が、マーシャルバッファの少な
    くとも一部を起動引き数の中にアンマーシャルするため
    に配置される、前記リクエストに対応したアンマーシャ
    ル機構を選択するためのセレクタと、 前記起動引き数を使用して前記リクエストに対応する前
    記サーバント内の前記呼び出された前記方法を起動する
    ための方法起動側と、 前記呼び出された方法の起動中、いつ例外が発生するか
    を決定するための機構と、 前記カスタムポストディスパッチ法が、前記例外が前記
    呼び出された方法の起動中に発生したと決定するときに
    前記例外を処理するために配置された、前記カスタムオ
    ブジェクトに対応したカスタムポストディスパッチ法を
    呼び出すための呼出し側と、を含む、コンピューティン
    グシステム。
11. 【請求項１１】 前記例外が前記呼び出された方法の起
    動中に発生した決定された場合に、前記例外の第１コピ
    ーを作成するためのコピー機構を更に含む、請求項１０
    に記載のコンピューティングシステム。
12. 【請求項１２】 前記例外の第１コピーをスローするた
    めに配置された第１スロー機構であって、更に前記例外
    の実行時コピーを作成するために配置されている第１ス
    ロー機構と、 前記例外の実行時コピーを記憶するために配置された実
    行ヒープと、を更に含む、請求項１１に記載のコンピュ
    ーティングシステム。
13. 【請求項１３】 前記例外の前記実行時コピーをキャッ
    チするために配置されたキャッチ機構と、 前記例外の前記第１コピーを削除するために配置された
    削除機構と、 前記例外の前記キャッチされた実行時コピーをスローす
    るために配置された第２スロー機構と、を更に含む、請
    求項１２に記載のコンピューティングシステム。
14. 【請求項１４】 カスタムオブジェクトが前記分散クラ
    イアント／サーバベースコンピューティングシステムに
    挿入された、リクエストに関するカスタムオブジェクト
    を構築するコンピュータコードと、 前記リクエスト内で指定された呼び出された方法を起動
    するために用いる適切なサーバントを決定するために使
    用される、前記カスタムオブジェクトに対応したカスタ
    ムプレディスパッチ法を呼び出すコンピュータコード
    と、 前記リクエストに対応したアンマーシャル機構を選択す
    るコンピュータコードと、 前記選択されたアンマーシャル機構を使用して、起動引
    き数内にマーシャルバッファの少なくとも一部をアンマ
    ーシャルするコンピュータコードと、 前記起動引き数を使用して前記リクエストに対応したサ
    ーバント内で呼び出された方法を起動するコンピュータ
    コードと、 前記呼び出された方法の起動中にいつ例外が発生するの
    かを決定するコンピュータコードと、 前記呼び出された方法の起動中に前記例外が発生したと
    決定したときに、前記例外を処理するために使用され
    る、前記カスタムオブジェクトに対応したカスタムポス
    トディスパッチ法を呼び出すコンピュータコードと、 前記コンピュータコードを記憶するコンピュータ読取り
    可能媒体と、を備えた、分散クライアント／サーバベー
    スコンピューティングシステムのサーバ上のスケルトン
    層内にあるスケルトンにディスパッチされるリクエスト
    を処理するためのコンピュータプログラム製品。
15. 【請求項１５】 前記コンピュータ読取り可能媒体が、
    搬送波に組み込まれたデータ信号である、請求項１４に
    記載のコンピュータプログラム製品。