JPH0926924A - 分散オブジェクトシステムにおける例外を解釈する方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 分散クライアント／サーバコンピューティン
グ環境において、ホストコンピューティングシステムが
遠隔装置から受信した例外識別子を、より読み取りやす
いメッセージストリングに変換するコンピュータシステ
ムおよびコンピュータに実装される方法を提供する。 【解決手段】 例外識別子は、例外を独自に識別するよ
うに配列されており、まず、例外識別子は、ドメイン名
と、メッセージ識別子とを含む例外タグの識別を助ける
ために使用される。次に、少なくとも一部でドメイン名
およびメッセージ識別子に基づいて、例外識別子に対応
するメッセージストリングを発見する。更に詳細に言え
ば、ドメイン名は、遠隔の場所にある装置に対応メッセ
ージファイルを識別するために使用される。次に、メッ
セージ識別子を使用して、例外識別子により指示される
例外に対応するメッセージストリングを例外メッセージ
ファイルの中で位置づける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的に、分散コ
ンピューティングシステム、クライアント−サーバコン
ピューティングおよびオブジェクト指向プログラミング
の分野に関する。更に特定すれば、本発明は、分散オブ
ジェクトシステムにおける例外を解釈する方法および装
置に関する。

【０００２】

【従来の技術および発明が解決しようとする課題】ここ
数年来、従来のプログラミング手法で開発されたソフト
ウェアの納期遅れと予算超過の傾向が強まるにつれて、
オブジェクト指向プログラミング手法への関心が高まっ
ている。これは、手順モデルと「線形」コードに重点を
置く従来のプログラミング技法においては、多くの課題
に関して、設計および保守が困難になりがちであるとい
う事実に起因している。一般的に、従来の方法を使用し
て作成された大きなプログラムは「脆い（brittle
）」。すなわち、わずかな変更でさえも、プログラミ
ングコードの全要素が影響を受ける。従って、ユーザの
要望に応じたソフトウェアの小規模な変更でも、全プロ
グラムの大幅な再設計と書き換えとが必要になることが
ある。また、情報量は処理能力を超えるほどの速度で増
え続けているため、データを処理する能力は低下しつつ
ある。この十年間に、コンピュータハドウェアの性能は
著しく向上したが、ソフトウェアの性能はそれに及ばな
い。ソフトウェアによって情報処理システムを設計、開
発、保守しようとする従来の試みは、能力をデータ管理
にのみ限定し続けるものであった。

【０００３】オブジェクトシコウプログラミング戦略
は、これらの問題を回避するのに向いている。その理由
は、オブジェクト手法が手順より、むしろデータの取り
扱いに重点を置くために、プログラマに現実世界の問題
をモデル化するに当たって、より直感的なアプローチを
提供するからである。更に、オブジェクトは関連データ
と手順とをカプセル化しており、オブジェクトのインタ
ーフェイスを介してのみデータおよび手順へのアクセス
を可能にすることによって、その情報がプログラムの他
の部分から隠されるようにしている。従って、オブジェ
クトのデータおよび／または手順への変更は、プログラ
ムの他の部分から比較的隠された状態にある。これによ
り、オブジェクトのコードを変更しても、その他のオブ
ジェクトのコードに影響を及ぼすことがなくなるので、
従来の方法を使用して書き込まれるコードと比べて、保
守が容易なコードが得られる。更に、オブジェクトは、
本来、モジュール的な性質を持つため、個々のオブジェ
クトを種々のプログラムで再使用できる。そこで、プロ
グラマは「試行正（tried and true）」オブジェクトの
ライブラリを開発し、様々に異なるアプリケーションで
オブジェクトを反復して使用することができる。このモ
ジュール性はソフトウェアの信頼性を向上させる一方
で、プログラミングコードの反復使用を可能にするの
で、開発時間の短縮につながる。オブジェクト指向設計
およびプログラミングの技法の詳細については、David
A.Taylorの「Object-Oriented Technology」（Addison-
Wesley, １９９０年刊）、General Electric Research
and Development Center刊行の「Object-Oriented Mode
ling and Design 」（Prentice-Hall,１９９１年刊）お
よびBertrand Meyerの「Object-oriented Software Con
struction 」（Prentice-Hall,１９８８年刊）を参照。
これら３冊の本の内容は、参考として本明細書にも取り
入れられている。

【０００４】しかし、オブジェクト指向方法論の利点を
十全に活用すること、特に、モジュール性によってもた
らされる利点の達成は今後の課題である。特に、異なる
プログラム言語によって作成されたオブジェクトや、相
互にネットワーク化された多数の計算プラットフォーム
上にあるオブジェクトに対して、プログラマや他のユー
ザのプログラミングコードを大幅に変更することなく、
透明性の良い手法でアクセスできるようにすることが大
いに望ましいであろう。

【０００５】クライアント−サーバコンピューティング
の場合、通常、複数のコンピュータがあり、それらのコ
ンピュータは互いにコンピュータ接続ネットワークを介
して通信するように配置されている。それらのコンピュ
ータの一部は、他のコンピュータに対し、サービスまた
は機能性の提供者として動作する。そのようなサービス
または機能性の提供者は、「サーバ」として知られてお
り、サービスまたは機能性を消費する側は、「クライア
ント」と呼ばれる。クライアント−サーバモデルも、同
じコンピュータで動作中の異なるプログラムが何らかの
保護機構を介して互いに通信しており、機能性の提供者
と消費者として動作しているようなケースに一般化され
ている。

【０００６】このような分散システムを提供しようとい
う試みは、クライアント−サーバモデルに基づくオブジ
ェクト指向手法を使用してなされてきた。この場合、サ
ーバオブジェクトは、そのサーバオブジェクトのリクエ
ストを発するクライアントオブジェクトに対してインタ
ーフェイスを構成する。こうした分散システムにおいて
は、それらのサーバは、データおよび関連方法から構成
されるオブジェクトである。クライアントオブジェクト
は、サーバオブジェクトへのコールを実行することによ
り、サーバオブジェクトの機能性に対するアクセスを獲
得する。それらのコールは分散システムによって仲介さ
れる。コールを受信すると、サーバオブジェクトは適切
な方法を実行し、その結果をクライアントオブジェクト
に送り返す。クライアントとサーバが通信する方法の一
つは、様々な分散オブジェクトの存在場所を突き止め且
つオブジェクト間に通信を成立させるために使用される
オブジェクトリクエストブローカ（Object Request Bro
ker ；ＯＲＢ）を介する方法である。

【０００７】分散システムにおけるオブジェクトメタフ
ァ（object metaphor ）は、オブジェクトのインターフ
ェイスをその実装（implementation）から分離し、それ
により、ソフトウェア設計者がオブジェクトの実装の詳
細に煩わされる必要なく、利用可能な種々のオブジェク
トの機能性を利用できるようにするため、有用な技法で
ある。プログラマはオブジェクトのインターフェイスの
みを認識していれば良い。更に、オブジェクト指向分散
システムにおいては、１つのインターフェイスの多重実
装（multiple implementation）が可能であり、そのイ
ンターフェイスはネットワークを介して接続されている
複数の計算プラットフォームに存在することになるであ
ろう。従って、ネットワークの一台のマシンで作業して
いるプログラマは、遠隔オブジェクトがコールされ、方
法が実行され、出力が適正に戻されるか、またはエラー
の場合には例外が発生するという確信を持って、詳細な
知識を持たないオブジェクトに対してコールを行うこと
ができるのである。そのようなシステムは、オブジェク
ト指向方法論のモジュール性およびカプセル化という利
点を十分に活用することにより、それ本来の利点を最大
限に引き出す。

【０００８】分散オブジェクトシステムのもう１つの利
点は、分散オブジェクトが場所独立性を持つことであ
る。すなわち、分散オブジェクトは、クライアントのア
ドレススペース、クライアントのマシンの複数のアドレ
ススペースおよびネットワークにまたがる複数のマシン
などの、ネットワーク内のどの場所にあっても良い。全
てのオブジェクトは、その存在場所に関わらず、クライ
アントによって一様に扱われる。更に、アプリケーショ
ンデベロッパが基準レベルの機能性を提供するために、
既存のインベントリ（inventory）に依存できるという
理由により、分散オブジェクトシステムは従来のシステ
ムより大きい機能性を与える。また、アプリケーション
がユーザ定義プラットフォーム独立インターフェイスを
介して協働できるので、分散オブジェクトシステムのポ
ータビリティは向上し、また、開発コストの低減も容易
に可能である。分散オブジェクトシステムによって、他
にも数多くの利点を実現できる。

【０００９】ソフトウェア業界は、分散オブジェクト技
法を求めるこのような声に、オブジェクト管理グループ
（Object Management Group ；ＯＭＧ）を形成すること
によって応えた。ＯＭＧの目的は、オブジェクトリクエ
ストブローカ（ＯＲＢ）、オブジェクトサービス、共通
ファシリティおよびアプリケーションオブジェクトとい
う４つの主要コンポーネントを有するオブジェクト管理
アーキテクチャ（Object Management Architecture；Ｏ
ＭＡ）の定義である。オブジェクトリクエストブローカ
は、基本的な場所トランスペアレントオブジェクト通信
および管理サービスを提供して、分散オブジェクトシス
テムの基礎を形成する。オブジェクトリクエストブロー
カに関する規格は、共通オブジェクトリクエストブロー
カアーキテクチャ（Common Object Request Broker Arc
hitecture;ＣＯＲＢＡ）仕様に含まれている。

【００１０】このような分散オブジェクトシステムを開
発する中で、オブジェクトのサービスを求めるリクエス
トに応答して例外が発生したときに、起こったエラーを
記述する英語または別の言語のテキストストリングをク
ライアントプロセスに提供しようという挑戦がなされ
た。例外には、システム例外とユーザ例外という２つの
基本的種類がある。システム例外は、オブジェクト管理
ファシリティのインフラストラクチャで、クライアント
のリクエストとは直接に関連しないエラーが検出された
ときに起こる。例えば、そのような例外は、メモリがク
ライアントのリクエストをサービスするには不十分であ
ること、ネットワークに通信障害があること、またはオ
ブジェクトの実装を含むサーバプロセスを利用できない
ことを指示すると思われる。

【００１１】ユーザ例外はオブジェクトに対するインタ
ーフェイスの一部として定義され、そのオブジェクトへ
の特定のリクエストをサービスしている間に起こると予
期し得るエラーを報告するために使用される。このよう
な例外は、サーバプロセスに無効パラメータが渡された
こと、または要求された資源を利用できないことを指示
すると思われる。例えば、クライアントプロセスが「Co
nnect to Modem」というオブジェクトのリクエストを発
した場合、クライアントプロセスは、モデムが存在する
と仮定し、接続が実行され且つ肯定応答が戻されると期
待している。ところが、何らかの理由によりサーバがモ
デムを利用できない場合には、エラーが起こっている。
そこで、サーバプロセスは例外を発生させ、独自の例外
識別子をクライアントプロセスへ送り返す。例外識別子
は、システムにより生成され、例外の原因を識別するた
めに使用することができる独自の「タグ」でなければな
らない。この例外識別子は、クライアントに対し例外の
原因を独自に識別することができるストリング、数、コ
ードまたは他の何らかの記号情報であれば良い。オブジ
ェクトインプリメンタ（object implementer）は、「Co
nnectionto Modem Railed -- No Modem Found On Syste
m 」のような、例外識別子を記述する英語ストリングを
指定していても良いが、このストリングは独自であると
保証されていないか、あるいはクライアントにとって不
適当な言語であるかもしれず、従って、クライアントプ
ロセスには送り返されない。

【００１２】すなわち、このような分散オブジェクトシ
ステムにおいては、独自の例外識別子のみがネットワー
クを介してクライアントプロセスへ送り返される。した
がって、クライアントプロセスは、例外を説明する英語
ストリングを受信しない。これは、リクエストが失敗し
た理由をクライアントプロセスがログすること、または
ユーザに表示することが不可能であるという点で、不利
益となる。分散システムが複数の異なる国にまたがって
いると、システムのユーザが多種多様な外国語を話し、
その母国語の説明を受信できないために、問題は一層複
雑になる。

【００１３】非分散（すなわち、局所）システムにおい
ては、あらゆるユーザが同じ言葉を話すと仮定でき、例
外識別子はその局所システムに対してのみ独自であれば
良く、クライアントプロセスは局所オブジェクトサーバ
プロセスと共用される単純なテキストファイルを介し
て、例外識別子を拡張することができる。このアプロー
チの一例は、数多くのUnixシステムによって支援されて
いる「perror」システムルーチンである。

【００１４】クライアントとサーバが分散している場
合、サーバは、存在し得るどのようなユーザに対して
も、そのユーザが話すあらゆる言語について例外テキス
トを提供しようと試みることができるであろう。ところ
が、サーバはアクセスしているクライアントの存在場所
および数とは無関係であるので、これは実際には不可能
であることがわかった。したがって、クライアントの言
語の実際の例外テキストがクライアントマシンになけれ
ばならない。このため、サーバは、オブジェクトリクエ
ストブローカによって支援されるあらゆるノードで実行
されている可能な全てのアプリケーションに対して独自
である独自の例外識別子を送信しなければならない。そ
のような識別子は、単に、同意された言語（例えば、英
語）のテキストストリングであってはならない。それ
は、クライアントが種々の、互いに無関係に開発された
オブジェクトサーバから例外を受信し得るという事実を
考えたとき、そのストリングが独自であり続けるという
保証が全くないからである。ここで説明する発明は、そ
れらの問題を、クライアントノードでニ重レベルマッピ
ング方式を実現することにより解決する。第１のレベル
では、独自の例外識別子をホスト言語（例えば、英語）
のテキスト説明に翻訳する。第２のレベルでは、ホスト
言語の説明をホスト言語からエンドユーザ指定言語に翻
訳する。

【００１５】

【課題を解決するための手段】以上のことを達成するた
めに、遠隔装置からホストコンピューティングシステム
により受信された例外識別子を、その例外識別子に対応
し、より読み取りやすいメッセージストリングに変換す
るために、分散クライアント／サーバ環境において使用
できるコンピュータシステムおよびコンピュータに実装
される方法を説明する。例外識別子は、例外を独自に識
別するように配列される。まず、ドメイン名と、メッセ
ージ識別子とを含む例外タグを識別するのを助けるため
に例外識別子を使用する。次に、少なくとも一部でドメ
イン名およびメッセージ識別子に基づいて、例外識別子
に対応するメッセージストリングを発見する。更に特定
していえば、ドメイン名は、遠隔場所に位置する装置に
対応する例外メッセージファイルを識別するために使用
される。その後、メッセージ識別子を使用して、例外識
別子により指示される例外に対応する、例外メッセージ
ファイル内のメッセージストリングを位置づける。メッ
セージストリングは、通常、基本言語で書かれた例外の
テキスト説明を提供する。

【００１６】説明する方法は、サーバ（ユーザ）生成例
外とシステム生成例外の双方を処理するために使用され
ても良い。一実施例においては、例外識別子がユーザ例
外を表わす場合、例外タグの第１の部分を得るために、
例外識別子を使用してインターフェイスレポジトリ機構
をアクセスし、例外タグの全ての部分が確定されるま
で、例外タグの残る部分を得るために、インターフェイ
スレポジトリ機構に対し、繰り返しコールを発する。

【００１７】別の実施例では、基本言語以外の言語でテ
キスト説明を提供することが望ましい場合に、メッセー
ジストリングのメッセージを第２の言語で提供する翻訳
ストリングをルックアップし且つ戻す国際サービス機能
をアクセスしても良い。翻訳ストリングは、例外メッセ
ージファイルに対応する例外翻訳ファイルに存在してい
ても良い。

【００１８】

【発明の実施の形態】以下の説明中、本発明を完全に理
解させるために、説明の便宜上、特定のデータや構成を
明示する。ここで説明する好ましい実施例は、サンマイ
クロシステムズ（Sun Microsystems, Inc.）のビジネス
部門であるサンソフト（SunSoft ）が製造している分散
オブジェクト環境（Distributed Objects Environment
；ＤＯＥ）の一部として実現される。しかしながら、
それらの特定の詳細を伴わずとも本発明を実施すること
は可能であり、本発明を様々な分散オブジェクトシステ
ムにおいて実現し得ることは、当業者には明白であろ
う。

【００１９】Ｉ．用語の定義 分散オブジェクトシステム（distributed object syste
m ）は、一般的には、分散オブジェクト技法を実現した
ものであり、オブジェクトリクエストブローカ（Object
Request Broker ；ＯＲＢ）を介して通信する複数の分
散オブジェクトを有するコンピュータシステムを指す。

【００２０】オブジェクトリクエストブローカ（ＯＲ
Ｂ）は、基本的なオブジェクト通信およびマネージメン
トサービスを実行することによって、分散オブジェクト
システムの基礎を形成する。

【００２１】クライアントプロセス（client process）
は、１つまたは複数のサーバプロセス（server proces
s）に向けてサービスを求めるリクエストを発行するソ
フトウェアプロセスである。クライアントプロセスとサ
ーバプロセスは同じマシンに存在していても良く、場合
によっては、同じプロセスであっても良いが、何れに対
しても強要される制限はないと考えられる。

【００２２】インターフェイス定義言語（interface de
finition language ；ＩＤＬ）は、オブジェクトのイン
ターフェイスを定義するために使用される言語である。
サーバはそれらのインターフェイスを実現し、クライア
ントは、それらの実装（implementations ）をそのイン
ターフェイスを介してアクセスする。

【００２３】オブジェクトまたは分散オブジェクトとい
う用語は、そのオブジェクトのインターフェイスを介す
る動作により操作できるコードとデータのカプセル化パ
ッケージを表わす。従って、分散オブジェクトは、従来
通りのプログラミングオブジェクトを定義する基本的特
性を含むことが当業者にはわかるであろう。しかし、分
散オブジェクトは、２つの重要な特徴を含むことによっ
て、従来のプログラミングオブジェクトとは異なる。第
１に、分散オブジェクトは言語独立性を持つ。分散オブ
ジェクトのインターフェイスは、多様な異なるプログラ
ミング言語にマップ（map ）できるインターフェイス定
義言語を使用して定義される。そのようなインターフェ
イス定義言語の１つがＩＤＬである。第２に、分散オブ
ジェクトは場所独立性を持つ。すなわち、分散オブジェ
クトはネットワーク中のどの場所にも配置可能である。
これは、通常は単一のアドレス空間、すなわち、クライ
アントプロセスのアドレス空間に存在している従来のプ
ログラミングオブジェクトとは著しく対照的である。分
散オブジェクトは、それらが他のオブジェクトにリクエ
ストを送信しているか、または他のオブジェクトからの
リクエストに応答しているかによって、クライアントオ
ブジェクトにも、サーバオブジェクトにもなり得る。分
散オブジェクトシステムにおけるクライアントオブジェ
クトとサーバオブジェクトは、インターフェイス定義言
語で定義されたインターフェイスによって通信する。リ
クエストと応答は、オブジェクトの場所と状態を認識し
ているオブジェクトリクエストブローカ（ＯＲＢ）を介
して出される。クライアントオブジェクトとサーバオブ
ジェクトは、同一のプロセスの中に存在することも可能
であり、同じホストコンピュータの異なるプロセスにあ
っても良く、あるいは、２つの異なるホストコンピュー
タに常駐するプロセスに存在していても良い。

【００２４】オブジェクト開発フレームワーク（Object
Development Framework）は、ＣＯＲＢＡコンプライア
ント分散オブジェクトをＣ＋＋で開発するためのプログ
ラミングモデルである。ＯＤＦは、デベロッパ（develo
per ）がオブジェクトをいかにして作成すべきか、その
オブジェクトをどの場所にインストール（install ）す
べきか、およびその活性化パラメータと非活性化パラメ
ータをいかにしてカスタマイズ（customize ）すべきか
を指定できるようにする単純な機構を構成する。また、
ＯＤＦは、マルチスレッド（multi-thread）化オブジェ
クトを実現し且つオブジェクト不変（persistent）デー
タを管理するための機能性を提供する。

【００２５】オブジェクトレファレンス（object refer
ence）は、クライアントにより遠隔オブジェクトをアク
セスするために使用される。一般に、オブジェクトレフ
ァレンスはクライアントプロセスの中にのみ存在する。
オブジェクトレファレンスを１つのストリングとして、
インポート、エクスポートすることができる。各オブジ
ェクトレファレンスは唯一のオブジェクトを指すことも
可能であるが、同じオブジェクトをいくつかのオブジェ
クトレファレンスが指していても良い。

【００２６】オブジェクトインターフェイス（object i
nterface）は、オブジェクトが提供する作動、属性およ
び例外の仕様である。一実施例においては、分散オブジ
ェクトのオブジェクトインターフェイスは、ＯＭＧイン
ターフェイス定義言語（ＩＤＬ）を使用して書き込まれ
ても良い。前述のように、オブジェクトはそのインター
フェイスを介してクライアントのリクエストにサービス
する。従って、インターフェイスを使用すると、オブジ
ェクトは、その方法およびデータをクライアント中のオ
ブジェクトレファレンスを介してアクセスするために使
用される他のプログラミング言語を知らなければならな
いという必要から解放されるのである。インターフェイ
スレポジトリ（interface repository；ＩＦＲ）は、シ
ステムの中で使用される全てのインターフェイスを追跡
し続ける。ＩＦＲは、本明細書中にも参考として取り入
れられているＣＯＲＢＡ仕様「The Common Object Requ
est Broker: Architecture and Specification」（改定
１．２版、ドラフト２９１９９３年１２月刊行）のInte
rface Repository Chapterの部分で説明されている。

【００２７】ＩＩ．特定の実施例 ここで説明する発明は、分散クライアント／サーバコン
ピューティングシステムにおいて発生する例外を解釈す
る機構を提供する。説明する実施例はＯＭＧのＣＯＲＢ
Ａ仕様に準拠して動作するように開発され、ＣＯＲＢＡ
仕様により指定されている、インターフェイスレポジト
リなどのいくつかのコンポーネントを利用すべく最適化
された。しかしながら、本発明を他の分散コンピューテ
ィングシステムでの仕様にも同様に容易に適合させ得る
ということを理解すべきである。

【００２８】先に指摘した通り、分散オブジェクトシス
テムの開発に際しては、遠隔サーバオブジェクトからの
サービスを求めるリクエストに応答して遠隔サーバオブ
ジェクトから発生した例外をクライアントへいかにして
報告すべきかを確定することに関して、挑戦がなされて
きた。ＣＯＲＢＡシステムにおいては、テキストストリ
ングの説明の拡張を許さず且つクライアントまたはサー
バの何れかで母国語とは無関係である標準化例外フォー
マットが要求される。したがって、デベロッパが顧客に
意味のわかる説明をするために、本発明では、実際の例
外テキストを、クライアントの言語で、クライアントの
マシンに格納することを考える。このためには、サーバ
は独自の例外識別子（オブジェクトリクエストブローカ
によって支援されるあらゆるノードで実行され得る全て
のアプリケーションに対して独自である）を送信するこ
とを求められる。サーバが例外識別子を戻すと、クライ
アントは、まず、その例外識別子を使用して例外タグを
導出する。そこで、例外タグを使用して、基本言語（例
えば、英語）の説明を提供するホスト例外ファイルをク
ライアントコンピュータに位置づけることができる。必
要に応じて、基本言語説明の外国語への翻訳を生成する
ために、基本言語説明を使用して、外国語ファイルを位
置づけることができる。次に、適切な説明をユーザに対
して表示するか、または後に解析するためにロギング
（logging ）することができる。

【００２９】この種のシステムを支援するために、サー
バのデベロッパはオブジェクトのインターフェイスの中
で例外を識別し、定義する。このインターフェイスをメ
ッセージファイルにコンパイルし、何らかの適切な言語
であれば良い基本言語テキスト説明を追加するために、
そのメッセージファイルを編集する。ここで説明する例
においては、基本テキスト説明は英語であるが、適切な
言語であれば、どのような言語を使用しても良いことを
理解すべきである。次に、メッセージファイルを使用し
て、ホスト（基本）例外メッセージファイルと、外国語
例外メッセージファイルとを生成する。ホストファイル
は基本言語（英語）の説明と、他の言語による説明を含
む外国語ファイルとを包含している。サーバを利用する
「クライアント」オブジェクトを新たなマシンにインス
トールする場合には、「クライアント」オブジェクトと
共にホストファイルを新たなマシンにインストールす
る。

【００３０】まず、図１を参照すると、分散オブジェク
トシステム２０におけるクライアントとサーバの関係の
一例が象徴的に示されている。分散オブジェクトシステ
ムはクライアントコンピュータ２２と、サーバコンピュ
ータ２４と、各コンピュータに存在し且つ分散オブジェ
クトシステム２０全体に及んでいるオブジェクトリクエ
ストブローカ（ＯＲＢ）２６とを含む。また、クライア
ントオブジェクト２９およびインターフェイスレポジト
リ（ＩＦＲ）３２を含むクライアントプロセス２８も示
されている。サーバプロセス３８は、オブジェクト４０
および４１を含む。ネットワーク通信装置４６はクライ
アントコンピュータ２２と、サーバコンピュータ２４と
の間で通信を実行する。インターフェイスレポジトリ
（ＩＦＲ）３２は、分散オブジェクトシステム内部の各
ノードに存在していても良い。すなわち、ＩＦＲはシス
テムのそれぞれのコンピュータのメモリに存在していて
もよい。別の実施例においては、ＩＦＲをネットワーク
の１つの場所に集中できる。説明を明確にするため、こ
こではＩＦＲの構造についての説明を省く。ただし、当
業者には理解されるであろうが、ＩＦＲの構造はＣＯＲ
ＢＡ仕様の中で説明されている。

【００３１】分散オブジェクトシステム２０は、クライ
アントプロセス２８を伴う唯１台のクライアントコンピ
ュータ２２と、サーバプロセス３８を伴う唯１台のサー
バコンピュータ２４とを示す。しかしながら、分散オブ
ジェクトシステムにおけるコンピュータとプロセスの数
は決まっておらず、所定の１台のコンピュータに多数の
プロセスが存在しても良いことを理解すべきである。ま
た、所定の１つのプロセスがオブジェクトからのリクエ
ストを発しているのか、またはそのようなリクエストを
受信しているのかに応じて、そのプロセスをクライアン
トとサーバの両方と考えることも可能であろう。プロセ
スがターゲットオブジェクトに関するリクエストを発し
ている場合、それをクライアントプロセスと呼び、プロ
セスがターゲットオブジェクトを実現する場合は、それ
をサーバプロセスと呼ぶ。更に、クライアントプロセス
２８およびサーバプロセス３８が共に同じホストコンピ
ュータで実行されていることも可能であろうと考えられ
る。ここで説明する方法は、同じホスト問い合わせを処
理するために使用できるが、多くの場合、同じホスト問
い合わせを処理するときには、より効率の良い手順が使
用されるであろう。クライアントコンピュータ２２とサ
ーバコンピュータ２４は、スーパーコンピュータ、ミニ
コンピュータ、ワークステーション、パーソナルコンピ
ュータ、パーソナルデジタルアシスタントおよびその他
の電子計算装置を含めて、オブジェクトを支援すること
が可能であるどのような種類の計算装置であっても良
い。一般的には、クライアントプロセス２８とサーバプ
ロセス３８は、定義済メモリ空間においてコンピュータ
で実行されるソフトウェアプロセスである。それらのプ
ロセスは、異なるプログラミング言語で書き込まれてい
ても良い。プロセスはアプリケーションプログラム、デ
ータベース、ネットワーク通信ソフトウェアまたは多様
な他のソフトウェア利用プログラムのうちの何れかであ
れば良いであろう。

【００３２】クライアントは、分散オブジェクトにある
方法を発動するプロセスである。クライアントそれ自体
が分散オブジェクトであっても良く、あるいは、非オブ
ジェクト指向プログラム（またはプロセス）であっても
良いであろうが、分散オブジェクトにある方法を呼び出
している間は、そのプロセスがクライアントとして活動
していると言う。また、システムソフトウェア自体がク
ライアントとして活動しても良い。

【００３３】図１に示す通り、ＯＲＢ２６は各計算装置
（この場合には、クライアントコンピュータ２２とサー
バコンピュータ２４）に存在していると共に、ネットワ
ーク４６全体にまたがっている。ＯＲＢは基本的なオブ
ジェクト通信およびマネージメントサービスを実行す
る。この分散オブジェクトシステム２０の中では、クラ
イアントはサーバのリクエストを発しても良い。サーバ
で例外が発生し、例外識別子をクライアントに戻す場
合、クライアントは説明テキストストリングをアクセス
できることが望ましいであろう。この説明テキストスト
リングは例外を説明し、ユーザに対してそれを表示する
か、またはそれをロギングすることができるであろう。
この必要性に対処した本発明の一実施例を以下に説明す
る。

【００３４】先に論じた通り、説明する実施例は２つの
段階を含む。第１の段階では、特定の例外を記述する説
明メッセージストリングをファイルに、そのファイルの
中では独自である対応するメッセージ識別子と共に追加
する。また、オプションとして、それらの説明メッセー
ジストリングの外国語への翻訳を作成し、ファイルに追
加しても良い。次に、それらのファイルをコンパイル
し、後続するクライアントアクセスに備えて、クライア
ントマシンへ転送する。本発明の第２の段階において
は、クライアントがサーバプロセスのリクエストを発
し、例外識別子を受信したとき、クライアントは、先に
クライアントマシンにインストールされていた、それら
の独自の名前を付されたファイルをアクセスすることに
よって、この例外識別子を説明メッセージストリングに
変換することができる。次に、図２のフローチャートを
参照して、本発明の第１の段階を説明する。

【００３５】まず、ステップ１０２では、サーバプロセ
スのデベロッパおよび／またはそのサーバの中のオブジ
ェクトのデベロッパは、どの例外を適用可能であるかを
識別する。そこで、例外をオブジェクトのインターフェ
イスで定義する。それらのインターフェイスと例外は、
インターフェイス定義言語（ＩＤＬ）を使用して定義さ
れる。言い換えれば、ＩＤＬは、オブジェクトがどの例
外を発することができるかを定義する。それらの例外を
「ユーザ例外」という。例えば、デベロッパがオブジェ
クト「Modem 」に対するインターフェイスを定義してお
り、クライアントがモデムをアクセスしようとしている
が、サーバが利用できるモデムが存在しないという状況
に関して例外を提供することを望む場合には、デベロッ
パはＩＤＬを使用して、サーバに例外「no modem」を戻
させる次のようなインターフェイスを定義すれば良い。

【００３６】 以下の例の中では、２つの例外、「underflow 」および
「overflow］を宣言するインターフェイス「Stack 」を
定義する。

【００３７】 例外をＩＤＬで定義したならば、ステップ１０４に示す
ように、ＩＤＬファイルをコンパイルする。一例とし
て、ＩＤＬファイルをＣコードまたはＣ＋＋コードでコ
ンパイルしても良い。ＩＤＬコンパイラは、また、局所
インターフェイスレポジトリをオブジェクトおよびその
インターフェイスに関する情報でポピュレート（popula
te）する。更に、コンパイラは、ステップ１０６に示す
ように、例外メッセージテキストファイルを生成する。
このファイルは、複数対のメッセージ識別子−メッセー
ジストリングを含むテンプレートである。メッセージ識
別子は、例外の名前を識別し、メッセージストリング
は、後にデベロッパが説明で充填するためにブランクの
まま残される。例えば、上記のモデムの例で言うと、コ
ンパイラは次のようにして現われる例外メッセージファ
イルの一部を生成することになるであろう。

【００３８】 # msgid "Modem no modem" msgstr " " # この例においては、「misgid」はメッセージ識別子を表
わし、インターフェイス名と、例外の名前とを連結した
ものであることに注意する。メッセージ識別子の別の変
形も可能である。例えば、メッセージ識別子は例外の名
前だけであっても良い。重要な点は、名前とメッセージ
ＩＤの組み合わせがＯＲＢの何れかの場所で可能である
全てのインターフェイスについて起こり得る全ての例外
に対して独自であるということである。この場合、「ms
gstr」はメッセージストリングであり、ブランクのまま
残されている。デベロッパがＩＤＬで更に多くの例外を
定義したならば、メッセージ識別子−メッセージストリ
ングの対の数は増えるであろう。ＩＤＬで定義される例
外ごとに、例外メッセージファイルの中にそれらの対の
うち一つが入る。

【００３９】ステップ１０８では、デベロッパは、例外
を説明する英語のストリングを挿入するために、例外メ
ッセージファイルを編集する。言い換えれば、メッセー
ジストリングは、メッセージ識別子として名前付けされ
た例外を説明するのである。例えば、デベロッパが上記
の例を編集した後、例外メッセージファイルは次のよう
に見えるであろう。

【００４０】 # msgid "Modem no modem" msgstr "Connection to Modem Failed--No Modem Found On System" # 上記のようなメッセージストリングとすることは、単に
例外の名前だけの場合と比べて、フルテキストの説明が
ユーザにとってはるかに有用であることがわかるので、
有利である。メッセージストリングをテキストストリン
グに限定する必要のないことを理解すべきである。メッ
セージストリングは、エンドユーザに有用なものである
ならば、数、記号または他の文字のストリングであって
も良い。

【００４１】また、例外がシステムインフラストラクチ
ャにおける障害の結果として起こること、あるいはその
障害を引き起こした方法とほとんど関係のない状況で起
こることも可能である。それらの例外を「システム例
外」と呼ぶ。システム例外は、サーバが故障した場合、
または通信障害があった場合、またはサーバがメモリを
使い果たした場合に起こり得るであろう。システム例外
は、システムデベロッパによりシステムソースコードで
定義される。ユーザ（あるいはサーバまたはオブジェク
トのデベロッパ）は、システム例外を定義できない。以
下に説明するように、システム例外はユーザ例外とはわ
ずかに異なるフォーマットを有する。

【００４２】システム例外の場合、ステップ１０８はシ
ステムデベロッパにより実行され、システムデベロッパ
はこの例外メッセージを直接作成するであろう。例え
ば、システムデベロッパが例外「NO MEMORY 」を定義し
た場合、デベロッパは、次のような形態を持つであろう
例外メッセージの中で等価の「msgstr」を指定しても良
い。

【００４３】 # msgid NO MEMORY/ANY/1 Bad Any msgstr "dynamic memory allocation failure" # この例において、「NO MEMORY 」は、ＣＯＲＢＡシステ
ム例外クラスの名前である。「Any 」は内部サブシステ
ム名、「１」はこの例外に関わるマイナコードである。
「Bad any 」は、ソースコードにおける内部識別子であ
る。説明する実施例においては、全てのシステム例外が
マイナコードを有する。マイナコードはデベロッパに起
こり得る例外をより精密な精度（granularity ）をもっ
て定義させることを可能にする数である。システム例外
の場合、例外メッセージファイルの説明メッセージスト
リングは、システム例外と、マイナコードを説明する。
したがって、例外メッセージファイルはサーバデベロッ
パによって充填されても良く、あるいはシステムデベロ
ッパによって充填されても良い。このファイルを他の個
人が作成すること、またはソフトウェアプログラムによ
り自動的に作成することさえ可能であるとも考えられ
る。

【００４４】本発明の別の実施例においては、メッセー
ジストリングを別個のメッセージテキストファイルに置
くのではなく、インターフェイスのＩＤＬ定義の中に直
接に配置する。すなわち、サーバデベロッパまたはシス
テムデベロッパがＩＤＬで例外を定義しているとき、対
応する説明メッセージもそのインターフェイス定義の中
に直接導入されることになるであろう。このステップ
は、別個に例外メッセージファイルを設ける必要をなく
すと考えられる。更に、例外発生したときには、メッセ
ージストリングを例外識別子と共にクライアントへ直接
に戻すことができるであろう。

【００４５】ステップ１０８でメッセージストリングを
例外メッセージファイルに追加した後、ステップ１１０
では、ホスト例外メッセージファイルと例外翻訳ファイ
ルを例外メッセージファイルから作成する。ホスト例外
ファイルはホスト言語（例えば、英語）説明ストリング
を生成するために使用され、翻訳ファイルは、この英語
ストリングの外国語への翻訳を保持するために使用され
る。例外メッセージファイルごとに１つのホスト例外メ
ッセージファイルがあるが、翻訳を希望する外国語の数
に応じて、例外メッセージファイルごとに多数の例外翻
訳ファイルが存在する可能性もあるだろう。それらのフ
ァイルは、人が読み取ることのできるファイルである。
一例として、ホスト例外メッセージファイルと、例外翻
訳ファイルとを異なる拡張子を利用して区別してもよ
い。例えば、ホスト例外メッセージファイルは拡張
子「.pox」を使用しても良く、また、外国語例外メッセ
ージファイルは拡張子「.po 」を使用する。これらのフ
ァイルは、「メイクファイルスクリプト（makefile scr
ipt ）」を使用することにより作成できるであろうが、
その他の方法も同様に使用できると考えられる。望まし
い実施例において使用される特定のソフトウェアユーテ
ィリティを「awk 」および「nawk」と呼ぶが、ファイル
をスキャンし、パターンを認識し、新たなファイルを生
成することができるどのようなユーティリティを使用し
てもよい。ユーティリティの使用は、当業者には周知で
あろう。ユーザ例外の場合、ホスト例外メッセージファ
イルは、例外メッセージファイルと同じメッセージ識別
子−メッセージストリング対を有する。システム例外の
場合には、ホスト例外メッセージファイルは、内部シス
テム名がオフのままであるという点で例外メッセージフ
ァイルとはわずかに異なっている。いずれの場合にも、
ファイル名とメッセージＩＤとの組み合わせは、ＯＲＢ
の何れかの場所において可能である全てのインターフェ
イスについて起こり得る全ての例外に対して独自であ
る。上記のシステム例外の例を使用すると、ホスト例外
メッセージファイルの一部は次のように現われるであろ
う。

【００４６】 # msgid NO MEMORY/ANY/1 msgstr "dynamic memory allocation failure" # 外国語例外メッセージファイルは、ユーザ例外とシステ
ム例外の双方について同じ形で現われる。このファイル
は、メッセージ識別子とメッセージストリングの双方に
ついて、例外メッセージファイルのメッセージストリン
グを含む。例えば、上記のモデムの例に関わる例外メッ
セージファイルを使用すると、外国語例外メッセージフ
ァイルは次のようになるであろう。

【００４７】 # msgid "Connection to Modem Failed--No Nodem Found On System" msgstr "Connection to Modem Failed--No Modem Found On System" # 次のステップ１１２では、メッセージストリングの外国
語への翻訳を挿入するために、外国語例外メッセージフ
ァイルを編集する。この外国語ストリングは、外国の場
所にいて、英語以外の言語の説明を必要としているクラ
イアントによってアクセスされる。メッセージ識別子フ
ィールドはそのままであるが、メッセージストリングフ
ィールドは外国語への翻訳と置き換えられる。例えば、
上記の外国語例外メッセージファイルをスペイン語圏に
あるクライアントマシンで使用すべき場合には、そのフ
ァイルはスペイン語の翻訳が得られるように編集され、
ファイルの一部は次のように現われるであろう。

【００４８】 # msgid "Connection to Modem Failed--No Modem Found On System" msgstr "Comunicacion con Modem no Sirvio. No se encuentra Modem en la sistema" # この編集は各人により実行されるのが好ましいが、ホス
ト言語（例えば、英語）のメッセージストリングを、コ
ンピュータソフトウェアの使用により自動的に外国語に
翻訳することも可能であろうと考えられる。また、先に
述べた通り、多数の外国語例外メッセージファイルを作
成しても良く、その場合、各ファイルは特定の言語に専
用となる。特定の場所に対して、システムのユーザは、
環境変数を設定することにより、どの外国語が好ましい
かを指示できる。更に、各ファイルは、各対が１つの例
外を表わす多数のメッセージ識別子−メッセージストリ
ング対を含んでいても良いことを理解すべきである。ク
ライアントマシンとクライアントが分散オブジェクトシ
ステムの数多くの異なる場所に存在していることもあり
得るので、複数の異なる言語への翻訳を実行する能力を
有していると有利である。

【００４９】ステップ１１４では、ホスト例外メッセー
ジファイルと、任意の数の外国語例外メッセージファイ
ルとを２進、コンピュータ読み取り可能形態にコンパイ
ルする。コンパイラは、それらのファイルを２進ツリー
英字ルックアップとして実現されたルックアップテーブ
ルとして表現する。２進ツリールックアップは当業者に
は周知である。コンパイルされるホストファイルと、外
国語ファイルの各々に対して、異なる２進ファイルがあ
る。

【００５０】ステップ１１６では、ホスト例外メッセー
ジファイルと、任意の数の外国語例外メッセージファイ
ルとを表わすそれらのコンパイル済２進ファイルをクラ
イアントマシンへ転送し、クライアントマシンのディレ
クトリにインストールする。それらのファイルは任意に
名前付けされておらず、ランタイム中のメッセージスト
リングの検索を容易にするために、標準名前付け規約を
使用する。例えば、一実施例においては、２進ホスト例
外メッセージファイルの名前は、ドメイン名に拡張
子「.mox」を加えたものであり、外国語例外メッセージ
ファイルの名前はドメイン名に拡張子「.mo 」を加えた
ものである。ドメイン名の意味と構造を図３を参照して
以下に説明する。ここでは、ランタイム時に、例えば、
ＵＮＩＸ「mmap」ファシリティを使用して即時アクセス
を行うために、例外処理ルーチンによりそれらの２進フ
ァイルをメモリにマップすることができる。このように
して、サーバプロセスまたはシステムソフトウェアから
例外が受信されたときに、説明メッセージストリングを
アクセスするためにクライアントプロセスをセットアッ
プする。クライアントは英語ストリング、または外国語
ストリングをアクセスすることができる。クライアント
プロセスがこのストリングをどのようにしてアクセスで
きるかについては、本発明の第二段階として後に説明す
る。

【００５１】２進ファイルを生成したならば、それら
を、関連サーバをコールする理由を持つオブジェクトと
共にパッケージングする。そのようなパッケージング
は、米国特許出願「弁理士書類番号：ＳＵＮ１Ｐ０２
２」の中で説明されている分散オブジェクト開発機能の
一部として実行可能である。すなわち、２進ファイルは
潜在クライアントオブジェクトと共にパッケージングさ
れるのである。次に図５を参照して、オブジェクトをホ
ストコンピュータシステムにインストールする方法の関
連ステップを説明する。まず、ステップ３０１では、ク
ライアントオブジェクトと関連するコードおよび／また
は何らかの不変データをホストコンピュータシステムに
インストールする。次に、ステップ３０３では、オブジ
ェクトにより支援される全てのインターフェイスをホス
トマシンのインターフェイスレポジトリ３２にインスト
ールする。その後、ステップ３０５においては、インス
トールされたインターフェイスと関連する例外メッセー
ジテキストファイルをホストマシンにインストールす
る。ホストマシンのユーザの母国語が例外ファイルの基
本言語ではない場合、ステップ３０７で、インストール
動作により、任意に適切な例外翻訳ファイルをインスト
ールしても良い。言うまでもなく、分散コンピューティ
ングシステムにおいては、インストール動作は、通常、
オブジェクトをオブジェクトリクエストブローカ（ＯＲ
Ｂ）とレジスタするステップなどのいくつかの他のステ
ップを有することを理解すべきであるが、それらのステ
ップは本発明とは特に関連していないので、ここではそ
の説明を省く。更に、インストール動作を特定の順序で
説明したが、様々なファイルをインストールする順序を
適切に変更しても良いことを理解すべきである。

【００５２】次に、図３を参照して、クライアントがサ
ーバプロセスから例外を受信したときに説明メッセージ
ストリングをアクセスする方法を説明する。このプロセ
スを説明するに当たり、例外、例外名、例外タグおよび
例外識別子を定義しておくと有益であろう。一般的に、
例外は、サーバプロセスまたはシステムソフトウェアで
エラーが起こった場合に発生する。そこで、この意味で
の「例外」の使用は、このような状況を指すことにな
る。例外の名前、すなわち、「例外名」は、図２のステ
ップ１０２におけるように、例外がＩＤＬで定義される
ときにサーバデベロッパまたはシステムデベロッパによ
り例外に与えられる名前である。モデムの例で言えば、
例外名は「no modem」である。

【００５３】フルスコープ例外名は、分散オブジェクト
システム全体を通じて例外に対し独自の識別子である。
フルスコープ例外名は、例外名を独自に修飾し、１つの
名前が２つ以上の例外を指すのを防止する。例外名の構
造は広範囲で変更自在であり、特定の１つのインターフ
ェイスを定義するエンティティは、その識別子の構造を
定義するに際して、広いラチチュード（latitude）を有
することを理解すべきである。ところが、単に例示を目
的として、代表的な例外ＩＤ構造を図６に示す。フルス
コープ例外名は、次に挙げるものを含めて、様々なコン
ポーネントを含む。第１のコンポーネントは、オブジェ
クトインターフェイスを定義していたエンティティを識
別するサイトプレフィクス（site prefix ）３２１であ
ろう。一例を挙げると、サイトプレフィクスは、１つの
エンティティに関するドメインネームサービス（Domain
Name Service ；ＤＮＳ）であっても良い。例えば、サ
ンマイクロシステムズのインターフェイスの場合、サイ
トプレフィックス（ドメイン名）は「eng.sun.com 」で
あろう。第２のコンポーネントは、モジュール名３２３
であろう。モジュールはインターフェイスおよび／また
はモジュール、例外などから成る１つのグループであ
る。モデムの例で言えば、モジュール名は「Peripheral
s 」になるであろう。モジュール名は入れ子構造になっ
ていても良いことを理解すべきである。すなわち、２つ
以上のレベルのモジュール名を使用しても良い。例え
ば、モデムの例においては、第１のモジュールの名前が
「Peripherals 」、第２のレベルのモジュール名が「Co
mmunications」であっても良い。第３のコンポーネント
は、インターフェイスの名前であろう。モデムの例で言
えば、インターフェイス名は「modem 」になるであろ
う。第４のコンポーネントは例外名自体であろう。モデ
ムの例で言えば、名前は「no modem」になるであろう。
別の層の名前付けコンポーネントも、当然、同じように
使用できるであろう。ＯＭＧ ＣＯＲＢＡ仕様は、フル
スコープ例外名に関する規格を定義している。すなわ
ち、フルスコープ例外名は次のようなコンポーネントを
含むことができるであろう。

【００５４】 site prefix, module(s),interface,exception name 分散オブジェクトシステムの所定の実現形態に対して、
フルスコープ例外名は可能なコンポーネントのサブセッ
トであり、上記の例は現われると思われる一部のコンポ
ーネントであることを理解すべきである。例外タグは、
変形した形のフルスコープ例外名のコンポーネントを含
む。一例を挙げると、例外タグは、フルスコープ例外名
のコンポーネント間にダブルコロンを挿入した形態であ
っても良い。コンポーネントを他の記号で分離すること
も可能である。ユーザ例外の場合は、フルスコープ例外
名と例外は同じコンポーネントを有する。システム例外
の場合には、例外タグはマイナコードとその他の情報と
を含むであろう。例えば、ユーザ例外の場合、例外タグ
は次のようなフォーマットを有することができるであろ
う。

【００５５】 site prefix::module::interface::exception name 分散オブジェクトシステムを実現するとき、デベロッパ
は、フルスコープ例外名に関わる特定の指定フォーマッ
トを使用するように促されるであろう。指定フォーマッ
トは可能なあらゆるコンポーネントを含んでいても良
く、あるいは、コンポーネントの部分集合を含んでいて
も良い。例えば、一実施例においては、フルスコープ例
外名は４つの指定フォーマットの中の何れか１つを使用
すれば良い。一例として例外タグを挙げると、それら４
つのフォーマットは次のようになると考えられる。

【００５６】 site prefix::exception name site prefix::module::exception name site prefix::module::interface::exception name site prefix::interface::exception name 言うまでもなく、指定フォーマットとして別の配列を規
定しても良い。下記の例は、モデムを例にとって、それ
ら４つのフォーマットの中で例外タグがどのように見え
るであろうかということを示している。

【００５７】 sun.eng.com::no modem sun.eng.com::Peripherals::no modem sun.eng.com::Peripherals::modem::no modem sun.eng.com::modem::no modem フルスコープ例外名（したがって、例外タグ）は、例外
をＩＤＬファイルで定義するに際してデベロッパがどれ
ほどグローバルに選択を行うかによって、指定フォーマ
ットの何れか１つの形態をとれば良いということを理解
すべきである。実現された実施例においては、上記の第
２および第３の指定フォーマットが好ましい。

【００５８】そこで、図３を参照して、例外識別子をメ
ッセージストリングに変換するプロセスを説明する。ま
ず、ステップ２０２では、クライアントはサーバプロセ
スのリクエストを発する。先に説明したように、クライ
アントはオブジェクト、プログラムのどちらであっても
良いであろう。クライアントはサーバの情報を要求して
いるか、もしくはアクションまたは他のアクティビティ
を求めていると思われる。ステップ２０４は、クライア
ントのリクエストに応答して例外が発生した状況を示
す。このとき、サーバはユーザ例外識別子をクライアン
トに戻す。前述のように、例外識別子は、分散オブジェ
クトシステムで起こった例外を独自に識別するストリン
グでなければならない。例外識別子は例外を識別する
が、クライアントが対応する説明メッセージストリング
をアクセスできるようになる前に、更に多くの処理が要
求される。

【００５９】例外を受信すると、ステップ２０７で、ク
ライアントは例外の型を確定する。例外は、システム例
外またはユーザ例外の何れかである。説明する実施例に
おいては、それぞれの例外は、Ｃ＋＋オブジェクトおよ
び例外クラス階層の一部である。したがって、例外がユ
ーザ例外であるか、またはシステム例外であるかを容易
に判定することができる。例外型を確定した後に、論理
はステップ２０８へ流れ、そこで、例外タグと、メッセ
ージ識別子とを生成するために、例外識別子を処理す
る。例外がシステム例外であれば、図４（ａ）を参照し
て以下に更に詳細に説明するように、例外をシステム例
外として処理する。これに対し、例外がユーザ例外であ
る場合には、例外は図４（ｂ）を参照して以下に更に詳
細に説明するように適切に処理される。

【００６０】例外タグとメッセージ識別子を生成した
後、論理はステップ２１０へ進み、ドメイン名を使用す
ることにより、２進ホスト例外メッセージファイルをク
ライアントコンピュータに位置づける。クライアントコ
ンピュータにある２進ホスト例外メッセージファイル
は、既に、（例えば）プレフィクスとしてドメイン名を
使用し且つ接尾部として「.mox」を使用して名前を付け
られているので、周知の技法を使用して、そのドメイン
名と接尾部によって、有効なファイル名識別子を生成す
ることが可能である。一例を挙げると、ドメイン名が
「eng.sun.com::modem」であり、接尾部が「.mox」であ
る場合、有効ファイル名識別子「eng sun modem.mox 」
を導出することができる。

【００６１】ステップ２１２では、説明メッセージスト
リングを検索するために、メッセージ識別子を２進ホス
ト例外メッセージファイルに渡す。特定の例外に対応す
るメッセージ識別子とメッセージストリングは先に１つ
の対としてホスト例外メッセージファイルの中に格納さ
れているので、メッセージ識別子に対応するメッセージ
ストリングを発見するために、このファイルの２進表現
を探索する従来通りの技法を使用することができる。次
に、基本言語説明メッセージストリング（すなわち、フ
ローチャートのボックス２１２の「英語メッセージスト
リング」）をクライアントに戻す。基本言語説明メッセ
ージストリングを戻した後、ステップ２１３では、その
基本言語がクライアントにとって好ましい言語であるか
否かに関して決定を行う。好ましい言語であれば、論理
はステップ２１８へ進み、表示またはロギングのため
に、例外メッセージストリングを出力する。

【００６２】ステップ２１３において、好ましい言語が
基本言語ではないと判定された場合には、論理はステッ
プ２１４へ進み、メッセージストリングを国際サービス
機能に渡す。国際サービス機能は、外国語の例外メッセ
ージファイルを探索するために、同じような２進ツリー
探索技法を使用する。当業者には理解されるであろう
が、そのような言語翻訳マッピングソフトウェアは市販
されている。サンマイクロシステムズのSolaris オペレ
ーティングシステムで利用できるそのようなソフトウェ
アの一つは、gettext( )と呼ばれるライブラリ機能であ
る。ホスト例外メッセージファイルを発見するために、
外国語例外メッセージファイルをステップ２１０で採用
されていた方式に類似する方式で位置づける。一実施例
においては、外国語例外メッセージファイルは接尾語と
してドメイン名を使用し、プレフィクスとして「.mo 」
を使用する。外国語例外メッセージファイルのメッセー
ジ識別子−メッセージストリングの対が共に説明テキス
トストリングであっても良いことに注意すべきである。
すなわち、外国語例外メッセージファイルにおいては、
メッセージ識別子はホスト例外メッセージファイルのメ
ッセージストリングと同じであり、外国語例外メッセー
ジファイルのメッセージストリングは外国語への翻訳で
ある。したがって、ホスト例外メッセージファイルのメ
ッセージストリングを使用することにより、国際サービ
ス機能は、等価のメッセージ識別子を発見するまで、外
国語例外メッセージファイル全体にわたって探索し、そ
の後、外国語への翻訳になる、対応するメッセージスト
リングを戻すことができる。

【００６３】ステップ２１６では、翻訳の済んだメッセ
ージストリングまたは例外タグ、あるいはその両方をク
ライアントに戻す。翻訳済メッセージストリングを受信
した後、論理はステップ２１８へ進み、クライアント
は、表示、ロギングなどのために、戻されてきた翻訳済
メッセージストリングを出力する。すなわち、ユーザが
ストリングを見られるように、ストリングを表示装置へ
送信しても良く、後の解析に備えてセーブしておくため
に、ストリングをログファイルへ送信しても良く且つ／
または他の何らかの方法でストリングを処理しても良
い。

【００６４】先に簡単に説明した本発明の別の実施例に
おいては、メッセージストリングをＩＤＬコードのイン
ターフェイス定義の中に直接配置する。この実施例の場
合、メッセージストリングがＩＤＬコンパイラにわかっ
ているので、ステップ２０４は例外識別子をクライアン
トに戻すばかりでなく、メッセージストリングをも戻
す。ＩＤＬコンパイラは、例外が発生したときに、サー
バが例外識別子およびメッセージストリングを戻すよう
に、例外をメッセージストリングと関連付ける。この代
替実施例では、クライアントはメッセージストリングを
直接にアクセスし、ステップ２０６から２１２は不要に
なるであろう。

【００６５】次に、図４（ｂ）を参照して、ユーザ例外
を受信した場合に例外タグおよびメッセージ識別子を獲
得するのに適するプロセス２０８ｂ（すなわち、図３の
ステップ２０８）を詳細に説明する。まず、ステップ２
６２では、インターフェイスレポジトリ（ＩＦＲ）を位
置づける。ＩＦＲを位置づけるこのステップは、当業者
には理解されるような多様な異なる方式により実行可能
である。ＩＲＡを位置づけたならば、ステップ２６４に
示すように、フルスコープ例外名を構成するために、Ｉ
ＦＲに対する反復コールを実行する。ＩＦＲは、システ
ムのあらゆるインターフェイスに関する知識を持つこと
を理解すべきである。したがって、ＩＦＲは、例外の発
生源を識別するために使用できる情報を提供することが
できる。そのような情報を得るために、ＣＯＲＢＡ規格
の「within」コールを使用しても良い。先に説明した、
例外タグが「site prefix module、 interface、 excepti
onname」という構造を持つ例においては、ＩＦＲに対す
る１回目のコール「lookup exception ID」は、例外名
である名前を持つコンテナを戻すであろう。１回目のコ
ールによって戻されたＩＦＲコンテナに対する２回目の
withinコールは、例外を包含しているインターフェイス
を戻すであろう。ＩＦＲへの３回目のコールはインター
フェイスに入り、そのインターフェイスを含むモジュー
ルを受信する。ＩＦＲへの４回目のコールはモジュール
に入り、ＩＦＲはサイトプレフィクスを戻す。ＩＦＲへ
の５回目のコールはサイトプレフィクスに入り、そこ
で、ＩＦＲは、プロセスが完了したことを指示する「イ
ンターフェイスレポジトリ」を戻す。このように、例外
識別子で始まり、ＩＦＲに対し反復コールを実行するこ
とによって、例外名、インターフェイス、モジュール、
サイトプレフィクスといったコンポーネントが順序で戻
されてくる。言うまでもなく、ＩＦＲにより戻される名
前の順序と性格は、例外タグの指定構造によって変わ
る。してがって、例外識別子によって、ＩＦＲは分散オ
ブジェクトシステムにおける例外を独自に識別できるの
である。

【００６６】ステップ２６６では、周知のプログラミン
グ技法を使用して、以下に示すように現れると考えられ
る例外タグを生成するために、ＩＦＲから戻されたコン
ポーネントを反転させ、ダブルコロンと連結することが
できる。

【００６７】 site prefix::module::interface::exception name 例外タグを識別したならば、論理はステップ２６８へ進
み、例外タグに基づいてドメイン名と、メッセージ識別
子とを確定する。ドメイン名と呼ばれる例外タグの実際
の部分は、特定のシステムの性質にしたがって大きく変
わる。説明する実施例においては、例外タグの初めの２
つのコンポーネント（すなわち、サイトプレフィクスと
モジュール）をドメイン名と考え、例外タグの残る部分
（すなわち，インターフェイスおよび例外名）がメッセ
ージを構成する。メッセージ識別子の中には、少なくと
も１つのコンポーネントがなければならない。例えば、
例外タグが「sun.con::peripherals::modem::no_mode
m」である場合、ドメイン名は「sun.com::peripheral
s」となり、メッセージ識別子は「modem::no_modem」と
なるであろう。ドメイン名およびメッセージ識別子につ
いては、他のフォーマットを使用しても良く、コンポー
ネントが異なる配列であったり、またはダブルコロ
ン「::」以外の文字によって分離されるか、あるいは全
く文字によって分離されなかったりしても差し支えない
ことを理解すべきである。例外タグ、ドメイン名及びメ
ッセージ識別子をプロセス２０８ｂにより確定したなら
ば、制御は前述のように図３のステップ２１０に戻る。

【００６８】次に、図４（ａ）を参照して、システム例
外を受信した場合に例外タグおよびメッセージ識別子を
獲得するのに適する方法２０８ａ（すなわち、図３のス
テップ２０８）を説明する。まず、ステップ２４２で
は、例外タグを生成するために、例外識別子を分析(par
sing）する。説明する実施例においては、システム例外
は、スコープ、例外タイトル、サブシステム名およびマ
イナコードを有すると思われる。スコープは、例外に関
わるモチベーション(motivation）を指示する。サブシ
ステム名は、その例外を生成したサブシステムを識別
し、マイナコードは例外メッセージファイルにおける適
切なメッセージストリングを直接に識別するキーとして
作用する。一例として、考え得る例外タグはＣＯＲＢ
Ａ::bad_memory::ORB::6502である。スコープは例外に
関わるモチベーションを指示する。この場合、スコープ
は、これがＣＯＲＢＡ指定エラーメッセージであること
を指示する。この場合、例外タイトルはメモリ割当ての
問題を指示する。サブシステム名は、エラーがＯＲＢに
よって生成されたことを指示し、マイナコードはメッセ
ージファイルにおける適切なメッセージストリングを識
別するためのキーとして使用できるレファレンスを提供
する。システムエラーを定義する債務を負うのは、通
常、唯一のエンティティ、すなわち、システムデベロッ
パのみであり、したがって、システムエラーメッセージ
の全てをシステムデベロッパが定義したシステムエラー
メッセージファイルで記述できるので、システム例外を
処理するために、サイトプレフィクスなどは不要である
ことを理解すべきである。

【００６９】システム例外を現す独自の例外識別子を受
信すると、例外識別子を既知のメッセージストリングと
の比較により分析して、例外タグを生成することができ
る。例外タグは、インターフェイスで定義されたときに
例外に与えられた名前である。例外タグを識別した後、
論理はステップ２４４へ進み、例外タグに基づいて、先
に図４（ｂ）のステップ２６８に関連して説明したのと
同様の方式で、ドメイン名とメッセージ識別子を生成す
る。プロセス２０８ｂにより例外タグ、ドメイン名およ
びメッセージ識別子を確定したならば、制御は前述のよ
うに図３のステップ２１０に戻る。

【００７０】本発明の好ましい一実施例においては、分
散オブジェクトは、１台のコンピュータまたはネットワ
ークによりリンクされた複数のコンピュータに配置され
ている。ネットワークは何らかの適切な形態であれば良
い。一例として、代表的なネットワーク構成を図７に示
す。ネットワーク構成２は、伝送線路４に結合する第１
のコンピュータ３を含む。ネットワーク２はサーバ、ル
ータ等５と、他のコンピュータ６、７および８とを更に
含み、データや命令をネットワーク化コンピュータの間
で通信できるようになっている。コンピュータネットワ
ークの設計、構成および実現は当業者には周知である。

【００７１】図７のコンピュータ３、６、７および８と
して使用するのに適する代表的なコンピュータ１０を図
８に概略的に示す。コンピュータ１０は、ランダムアク
セスメモリ（ＲＡＭ）１４と双方向的に結合すると共
に、リードオンリメモリ（ＲＯＭ）１６とは単方向的に
結合する中央処理装置（ＣＰＵ）１２を含む。通常、Ｒ
ＡＭ１４は「スクラッチパッド(scratch pad）」メモリ
として使用され、現在ＣＰＵ１２で動作中であるプロセ
スに関わるプログラミング命令およびデータ（分散オブ
ジェクトおよびその関連データと命令を含む）を格納し
ている。ＲＯＭ１６は、通常、コンピュータがその機能
を実行するために使用する基本的動作命令、データおよ
びオブジェクトを格納している。更に、ハードディス
ク、ＣＤＲＯＭ、光磁気（フロプティカル(floptical))
ドライブ、テープドライブ等の大容量記憶装置１８がＣ
ＰＵ１２と双方向的に結合している。大容量記憶装置１
８は、一般に、通常はＣＰＵにより能動的には使用され
ていない付加的なプログラミング命令、データおよびオ
ブジェクトを格納しているが、そのアドレススペース
は、例えば、仮想メモリなどとしてＣＰＵによりアクセ
スできる。上記のコンピュータは、何れも、通常はキー
ボード、ポインタ装置(例えば、マウスまたはスタイラ
ス)および／またはネットワーク接続などの入力媒体を
含む入出力源１９を更に含んでいる。別の大容量記憶装
置(図示せず)をネットワーク接続を介してＣＰＵ１２に
接続しても良い。上述のハードウェア素子およびソフト
ウェア素子、ならびにネットワークか装置は標準の設計
構成であり、当業者には良く知られていることが当業者
には理解されるであろう。

【００７２】本発明のいくつかの実施例を詳細に説明し
たが、本発明の趣旨または範囲から逸脱することなく、
本発明を数多くの特定の形態で具現化しうることを理解
すべきである。本発明は、コンピュータシステムに格納
されたデータを必要とする様々なプロセスステップを採
用する。それらのステップは、物理的量の物理的操作を
必要とするステップである。通常、それらの量は記憶、
転送、組み合わせ及びその他の方法による操作が可能で
ある電気信号または磁気信号の形態をとるが、必ずしも
この形態に限定されるわけではない。場合によっては、
主に共通して使用される用語であるという理由により、
それらの信号をビット、値、要素、変数、文字、データ
構造などと呼ぶと好都合である。しかしながら、それら
の用語およびそれに類する用語は、全て、適切な物理的
量と関連させるべきものであり、単に、それらの量に便
宜上付されたラベルであるに過ぎないことを忘れてなら
ない。

【００７３】更に、実行される操作を、識別、実行、ま
たは比較などの用語で呼ぶことが多い。ここで説明す
る、本発明の一部を形成する動作の何れにおいても、動
作は機械の動作である。本発明の動作を実行するのに有
用な機械は、汎用デジタルコンピュータまたは他の同様
な装置がある。あらゆる場合に、コンピュータを動作さ
せるときの動作の方法と、計算それ自体の方法との区別
に留意すべきである。本発明は、電気信号または他の物
理的信号を処理して、他の所望の物理量的信号を発生す
るに際してコンピュータを動作させる方法ステップに関
する。

【００７４】また、本発明は、それらの動作を実行する
ための装置にも関する。この装置は要求されている目的
に合わせて特別に構成されても良いが、汎用コンピュー
タに記憶させたコンピュータプログラムによってコンピ
ュータを選択的に起動または再構成しても良い。ここで
提示するプロセスは、本来、何らかの特定コンピュータ
または他の特定の装置と関連するものではない。すなわ
ち、ここで示す教示にしたがって様々な汎用機械を使用
できるであろうし、あるいは、要求される方法ステップ
を実行するためには、より特殊化された装置を構成する
方が便利であるかもしれない。それらの多種多様な機械
に要求される構造は、以下の説明から明らかになるであ
ろう。したがって、ここで示した例は単なる例示で、限
定的な意味を持たず、本発明は詳細な説明に限定されな
い。

【図面の簡単な説明】

【図１】分散オブジェクトシステムの構成図である。

【図２】例外メッセージファイルおよび外国語例外メッ
セージファイルを生成するために使用されるステップを
示すフローチャートである。

【図３】例外識別子を説明メッセージストリングに変換
する方法を示すフローチャートである。

【図４】例外タグ及びメッセージ識別子を生成するため
にシステム例外を処理する方法を示すフローチャートで
ある。

【図５】オブジェクトの分散へのインストール中に発生
する例外処理に関連するステップを示すフローチャート
である。

【図６】ユーザ例外タグの潜在内容の説明図である。

【図７】オブジェクトクライアントとサーバの両方を実
行していても良いコンピュータを含む、コンピュータネ
ットワークシステムの構成図である。

【図８】図７のコンピュータの構成図である。

【符号の説明】

３，５，６，７，８…コンピュータ、４…ネットワーク
接続、１２…中央処理装置（ＣＰＵ）、１４…ＲＡＭ、
１６…ＲＯＭ、１８…大容量記憶装置、１９…入出力
源、２０…分散オブジェクトシステム、２２…クライア
ントコンピュータ、２４…サーバコンピュータ、２６…
ＯＲＢ、２８…クライアントプロセス、２９…クライア
ントオブジェクト、３２…ＩＦＲ、３８…サーバプロセ
ス、４０，４１…サーバオブジェクト。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ケン エム． カバナフ スリー アメリカ合衆国， カリフォルニア州 94037， モンタラ， フィフス ストリ ート 357 (72)発明者 マーク ダブリュー． ハプナー アメリカ合衆国， カリフォルニア州 95125， サン ノゼ， ブルックス ア ベニュー 595

Claims (17)

【特許請求の範囲】
1. 【請求項１】 分散オブジェクトコンピューティング環
   境で使用するホストコンピューティングシステムにより
   受信された例外を解釈する、コンピュータに実装される
   方法であって、コンピュータ制御のもとで、 遠隔の場所に位置する装置により発生した例外を、ユニ
   ークに識別する例外識別子を受信するステップと、 前記例外識別子に対応するメッセージストリングを位置
   づける、ホストコンピュータシステムが使用可能なドメ
   イン名と、メッセージ識別子とを含む例外タグの識別を
   助けるために、前記例外識別子を利用するステップと、 前記遠隔の場所に位置する装置に対応する前記ホストコ
   ンピューティングシステムに常駐する例外メッセージフ
   ァイルの識別を助けるために、前記ドメイン名を利用す
   るステップと、 前記例外識別子に対応するメッセージストリングを位置
   づけるために、前記メッセージ識別子を利用して、前記
   例外メッセージをアクセスするステップと、 を備えるコンピュータに実装される方法。
2. 【請求項２】 コンピュータの制御のもとで、前記例外
   識別子がシステム例外を表わすか、または、ユーザ例外
   を表わすかを判定するステップを更に備える、請求項１
   記載のコンピュータに実装される方法。
3. 【請求項３】 前記例外識別子がシステム例外を表わす
   と判定されたときに応じて、前記例外タグを識別するス
   テップは、コンピュータの制御のもとで、前記例外タグ
   を導出する、例外識別子を分析するサブステップを備え
   る、請求項２記載のコンピュータに実装される方法。
4. 【請求項４】 前記例外識別子がユーザ例外を表わすと
   きに応じて、前記例外タグを識別するステップは、コン
   ピュータの制御のもとで、 前記例外識別子を前記例外タグに関連付ける情報を含む
   インターフェイスレポジトリ機構を位置づけるステップ
   と、 前記例外タグを確定するために、前記例外識別子を使用
   してインターフェイスレポジトリ機構をアクセスするス
   テップとを備える請求項２記載のコンピュータに実装さ
   れる方法。
5. 【請求項５】 分散オブジェクトコンピューティング環
   境で使用するホストコンピューティングシステムにより
   受信される例外を解釈するコンピュータに実装される方
   法であって、コンピュータの制御のもとで、 遠隔の場所に位置するサーバ装置から、前記遠隔の場所
   に位置する前記サーバ装置により発生した例外を、ユニ
   ークに識別する例外識別子を受信するステップと、 前記サーバ装置のインターフェイスに対応する例外メッ
   セージファイルを識別するドメイン名と、前記例外メッ
   セージファイル中のメッセージストリングを識別するよ
   うに配列されているメッセージ識別子とを含む例外タグ
   であって、前記例外識別子に対応するメッセージストリ
   ングを位置づけるため、ホストコンピュータシステムが
   使用可能な例外タグを導出するために、前記例外識別子
   を利用して、インターフェイスレポジトリ機構をアクセ
   スするステップと、 前記例外識別子に対応する前記メッセージストリングを
   位置づけるために、前記メッセージ識別子を利用して、
   前記例外メッセージファイルをアクセスするステップと
   を備える方法。
6. 【請求項６】 前記インターフェイスレポジトリをアク
   セスするステップは、前記例外タグの第１の部分を得る
   ために、前記例外識別子を使用してインターフェイスレ
   ポジトリ機構をアクセスするステップと、前記例外タグ
   の全ての部分が確定されるまで、例外タグの残る部分を
   得るために、インターフェイスレポジトリ機構に対する
   コールを繰り返すステップとを備える、請求項５記載の
   コンピュータに実装される方法。
7. 【請求項７】 前記例外メッセージファイルは、前記ホ
   ストコンピュータシステムのメモリに常駐する、請求項
   ６記載のコンピュータに実装される方法。
8. 【請求項８】 前記例外識別子は、前記ホストコンピュ
   ータシステムに常駐するクライアントによるサーバリク
   エストに応答して受信されており、前記インターフェイ
   スレポジトリ機構をアクセスするステップおよび前記例
   外メッセージファイルをアクセスするステップはクライ
   アントにより実行されている場合に、コンピュータの制
   御のもとで、第１の言語のテキストストリングを含むメ
   ッセージストリングを、前記例外メッセージファイルか
   ら前記クライアントに戻すステップを更に備える、請求
   項５記載のコンピュータに実装される方法。
9. 【請求項９】 コンピュータの制御のもとで、前記メッ
   セージストリングを、第２の言語によるメッセージスト
   リングのメッセージを提供する翻訳ストリングをクライ
   アントに戻す国際サービス機能に渡すステップを更に備
   える、請求項８記載のコンピュータに実装される方法。
10. 【請求項１０】 前記翻訳ストリングは、前記ホスト例
    外メッセージファイルに対応する例外翻訳ファイルに常
    駐する、請求項９記載のコンピュータに実装される方
    法。
11. 【請求項１１】 分散オブジェクトオペレーティング環
    境で使用するコンピュータシステムにであって、 データを格納するメモリと、 遠隔の場所に位置する装置へリクエストを発信し、前記
    遠隔の場所に位置する前記装置により、または、前記装
    置に関して発生した例外を指示し、ユニークな例外識別
    子の形態の応答であって、前記リクエストに対する応答
    を受信する接続機構と、 前記例外識別子とは明確に異なり、ドメイン名と、メッ
    セージ識別子とを含む例外タグを導出するために、前記
    例外識別子を処理する例外処理機構と、 遠隔の場所に位置する装置に対応した前記ホストメモリ
    に常駐し、前記遠隔の場所にある前記装置により、また
    は、前記装置に関して発生し得る例外に対応する複数の
    メッセージストリングを含み、前記ドメイン名を使用し
    て識別され、メッセージ識別子を使用して、前記遠隔の
    場所にある前記装置により、または、前記装置に関して
    発生した例外と関連する前記メッセージストリングの中
    の選択された１つのメッセージストリングが識別される
    例外メッセージファイルとを備えるコンピュータシステ
    ム。
12. 【請求項１２】 前記例外識別子がシステム例外を表わ
    すか、または、ユーザ例外を表わすかを判定する判定機
    構を更に備える、請求項１１記載のコンピュータシステ
    ム。
13. 【請求項１３】 前記例外タグを導出するために、前記
    例外識別子を分析する分析機構を更に備える、請求項１
    ２記載のコンピュータシステム。
14. 【請求項１４】 リクエストの生成および応答の受信に
    責任のあるコンピュータシステムに配置されたオブジェ
    クトにより支持されているインターフェイスに関連する
    情報を有するインターフェイスレポジトリを更に備え
    る、請求項１２記載のコンピュータシステム。
15. 【請求項１５】 前記メッセージストリングは、前記メ
    ッセージストリングの関連例外を表示する第１の言語の
    テキスト説明を含み、コンピュータシステムは、前記メ
    ッセージストリングに対応する第２の言語の翻訳ストリ
    ングを識別することができる国際サービス装置を更に備
    える、請求項１２記載のコンピュータシステム。
16. 【請求項１６】 前記翻訳ストリングは、メモリに常駐
    する例外翻訳ファイルの中に常駐している、請求項１５
    記載のコンピュータシステム。
17. 【請求項１７】 請求項１１に記載されるような複数の
    コンピュータと、それらのコンピュータを接続するネッ
    トワークとを備える分散オブジェクトコンピューティン
    グシステム。