JPH0926890A - オブジェクトを管理するための方法、装置、および、データ構造 - Google Patents

Abstract

(57)【要約】 【課題】 一時的分散オブジェクトおよび不変分散オブ
ジェクトを管理するための様々な方法、装置、およびデ
ータ構造を提供する。 【解決手段】 一時的オブジェクトに関するオブジェク
トレファレンスとして用いることを意図したデータ構造
を、エンドポイントアドレスのセット、具体化番号、お
よびオブジェクトキーを持つ。これらの要素は、一時的
オブジェクトを一義的に識別し場所を見いだす役割を果
たす。また、不変オブジェクトに関するオブジェクトレ
ファレンスとして用いることを意図したオブジェクト
を、ホストコンピュータ名、ロケーター同定事項、オブ
ジェクトキー、およびサブオブジェクト識別子を持つ。
最初の三つの要素は不変オブジェクトへのインディレク
ションの役割を果たし、第３の要素は不変オブジェクト
用である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散コンピューテ
ィングシステム、クライアント-サーバーコンピューテ
ィング（cliant-server computing）、およびオブジェ
クト指向プログラミングの分野に係わり、特に、一時的
および不変オブジェクトを管理するための方法、装置お
よびデータ構造に関するものである。

【０００２】

【従来の技術および発明が解決しようとする課題】ここ
数年来、従来のプログラミング方法で開発されたソフト
ウェアの納期遅れと予算超過の傾向が強まるにつれて、
オブジェクト指向プログラミング方法論への関心が高ま
っている。このことは、手順モデルと「線形」コードを
強調する従来のプログラミング技法が多くの状況下にお
いて設計と保守が困難であることに起因している。一般
的に、従来の方法を用いて作成された大きなプログラム
は「脆い（brittle）」、すなわち、わずかな変更でさ
えもプログラミングコードの多くの要素が影響を受け
る。従って、ユーザーの要望に応じたソフトウェアの小
規模な変更でも、全プログラムの大幅な再設計と書き換
えが必要になることがある。

【０００３】オブジェクト指向プログラミング戦略は、
これらの問題を回避する傾向がある。その理由は、オブ
ジェクト方法論は、手順よりもむしろデータの取扱いに
重点を置き、従って、プログラマーに現実世界の問題を
モデル化するためのより直感的アプローチを提供するか
らである。更に、オブジェクトは、オブジェクトのイン
ターフェースを介してのみデータおよび手順へのアクセ
スを可能にすることによって、関連データと手順をカプ
セルに入れた状態にしてプログラムの他の部分からその
情報を隠しておく。したがって、オブジェクトのデータ
およびまたは手順への変更はプログラムの他の部分から
比較的隔離された状態にある。これにより、従来の方法
を用いて書かれたコードに比べて保守の容易なコードが
提供され、特定のオブジェクトのコードへの変更が他の
オブジェクトのコードに影響を及ぼすことがない。更
に、オブジェクトが本来モジュール的な性質であるの
で、個々のオブジェクトを種々のプログラムに再使用す
ることができる。したがって、プログラマーは、種々の
用途に反復使用することができる。「試行正」オブジェ
クトのライブラリーとインターフェイスとを作成するこ
とができる。これによりソフトウェアの信頼性が高まる
一方、信頼性のあるプログラミングコードが繰り返し用
いられるので、開発時間が短縮される。

【０００４】オブジェクト指向技法の分野におけるごく
最近の進展は、コンピュータネットワークを介して相互
接続されたコンピュータへの分散オブジェクトオペレー
ティング環境の実装である。ここで用いる場合、「分散
オブジェクト」または「オブジェクト」は、インターフ
ェイスを介したオペレーティングによって操作され得る
コードとデータのカプセル化されたパッケージをいう。
したがって、オブジェクト指向プログラミング（ＯＯ
Ｐ）に係わる当業者には、分散オブジェクトは、従来の
プログラミングオブジェクトを定義する基本的特性を含
むものと思われるであろう。しかし、分散オブジェクト
は、ふたつの重要な特徴を含むことによって、従来のプ
ログラミングオブジェクトとは異なる。第１の特徴は、
分散オブジェクトは多言語的である。すなわち、分散オ
ブジェクトのインターフェイスは、様々な異なる言語へ
マップすることのできるインターフェイス定義言語（Ｉ
ＤＬ）を用いて定義される。そうしたインターフェイス
定義言語のひとつがオブジェクト管理グループ（Object
Management Group's；ＯＭＧ）のＩＤＬである。第２
の特徴は、分散オブジェクトは場所独立性である、すな
わち、分散オブジェクトはネットワーク内のどこででも
在り場所を見いだすことができる。このことは、複数の
クライアントによって共有される単一のアドレススペー
ス内に存在するのが普通である従来のプログラミングオ
ブジェクトとは著しい対照をなす。

【０００５】分散オブジェクトは、他のオブジェクトへ
リクエストを送っているか、あるいはクライアントから
のリクエストに回答しているかによって、オブジェクト
クライアントあるいはオブジェクトサーバーとなり得
る。分散オブジェクト環境においては、リクエストと回
答は、オブジェクトの場所と状態を認識しているオブジ
ェクトリクエストブローカ（Object Request Broker）
を介して行われる。そうしたＯＲＢに適したひとつのア
ーキテクチャが、共通オブジェクトリクエストブローカ
アーキテクチャ（ＣＯＲＢＡ）仕様によって提供され
る。ＣＯＲＢＡ仕様は、サービスをリクエストするオブ
ジェクトへサーバーオブジェクトがサービスを提供する
ことのできる分散クライアントサーバー環境におけるオ
ブジェクトに関して分散コンピューティング環境を定義
するため、ＯＭＧ（Object Management Group）によっ
て開発された。以下の考察においては、「オブジェク
ト」と「分散オブジェクト」とは互換性をもって用いら
れる。

【０００６】分散オブジェクト環境においては、一時的
（transient）オブジェクトと不変（persistent）オブ
ジェクトの、ふたつの優勢なオブジェクトがある。一時
的オブジェクトは普通、寿命が短く、単一のホストプロ
セスに限られる。すなわち、あるホストプロセスが終了
すると、そのプロセスのもとで実行されていた全ての一
時的オブジェクトも終了する。したがって、一時的オブ
ジェクトの同一性は、あるプロセスから他のプロセスへ
連続して行かない。一時的オブジェクトは単一のホスト
プロセスに限られるので、一時的オブジェクトは本質的
にその場所を変えることができない。また、一時的オブ
ジェクトのアドレスは変らないので、「インモービル
（immobile）」オブジェクトと呼び替えることができ
る。

【０００７】これとは対照的に、不変オブジェクトは単
一のプロセスに限られず、その場所は時間とともに変化
し得る。従って、不変オブジェクトはそのアドレスが変
化し得るので「モービル（mobile）」オブジェクトと呼
ばれる。不変オブジェクトにおける同一性は、あるプロ
セスから他のプロセスへ連続して行く。しかし不変オブ
ジェクトは、一時にひとつのプロセス内にしか存在でき
ない。

【０００８】あるオブジェクトの一時性または不変性を
論じる際に、通常、想定されることは、そのオブジェク
トの状態の一時性または不変性である。当業者には周知
のように、プロセスあるいはオブジェクト等のコンピュ
ータエンティティは、実行可能コードと状態（executab
le code and state）という、ふたつの要素（component
s）を持っている。実行可能コードは、本質的には、そ
れによってエンティティが作用する（operates）命令
（instructions）である。したがって、コードでないデ
ータ等、残りの部分が状態である。異なる種類の状態、
すなわち一時的と不変、の背景にある動機は、かなり単
純明解である。不変状態は、不変性維持のため大容量記
憶装置および対応する管理資源のような追加のシステム
資源を必要とするが、追加のシステム資源は必要かも知
れないし、必要でないかも知れない。例えば、データベ
ースに格納された情報は、長期にわたる格納を目的とす
るのが普通であり、したがって不変性が要求される。こ
のような状況においては、このデータを維持するため、
追加のシステム資源は設けるに値する。

【０００９】しかし、不変性が必要でなく、したがって
不変性のために必要な追加のシステム資源が無駄になる
ような状況も数多くある。状態が短期間のみ必要である
か、および／または、もし必要ならば後で容易に再構成
可能な何れの状況も一時的状態になりそうである。この
周知の例としては、多くのウィンドウ系のワードプロセ
ッシングプログラムのフォーマット用ボタンや編集用ボ
タンのようなアイコンがある。このようなボタンを実装
する際には、（大ざっぱに言って）それを作用させるコ
ードと、それに外観を与える状態とがある。この状態に
はアイコンのビットマップが含まれる。ワードプロセッ
シングウィンドウを閉じるとアイコンは消え、その他の
アイコンのビットマップを保持しておく必要はない。一
時的状態を用いれば、システムはこれらのビットマップ
の保持のことは、再度必要になるまで忘れてよく、必要
になった時点で再形成すればよい。

【００１０】一時的状態および／または不変状態を処理
するための従来の解決法は、分散オブジェクトオペレー
ティング環境の範囲内において一時的オブジェクトおよ
び不変オブジェクトの統合を効果的に可能ならしめるフ
レームワークを提供することができなかった。例えば、
オブジェクト指向技法を含むデータベース技術は、総じ
て不変状態の維持のみを取り扱ってきた。更にひとつの
例として、パーソナルコンピューティングシステムは、
不変状態を用いて、すべての資源とサービスが同時スタ
ートするように設計されている。周知の分散コンピュー
ティング環境（Distributed Computing Environment =
DCE）は、各個別のオブジェクトを管理するのに１２８
ビット識別子を用いて不変分散オブジェクトのみを実装
する。一般に、従来技術はほとんど不変オブジェクトの
みを取扱い、一時的オブジェクトを取り扱う場合には一
時的オブジェクトのみに焦点を絞る傾向がある。分散オ
ブジェクトオペレーティング環境のもとで一時的オブジ
ェクトおよび不変オブジェクトを効果的に統合するため
のフレームワークこそが求められている。そのために
は、両者間の差を許容し、なおかつ統合されたフレーム
ワークを提供するデータ構造が必要である。更に、これ
ら不変オブジェクトと一時的オブジェクトを管理するた
めの効果的方法も必要である。

【００１１】

【課題を解決するための手段】上記およびその他の目的
を達成するため、また、本発明の目的に従って、一時的
オブジェクトおよび不変オブジェクトを管理するための
方法、装置、およびデータ構造を説明する。本発明は、
一時的オブジェクト用のオブジェクトレファレンスとし
ての使用が意図されているデータ構造は、１セットのエ
ンドポイントアドレスと、具体化番号（incarnation nu
mber）、およびオブジェクトキーを含む。エンドポイン
トアドレスのセットは、一時的オブジェクトが存在する
サーバーホストコンピュータに対応するように編成され
ている。具体化番号は、ホストコンピュータ上で実行さ
れているサーバーホストプロセスに対応するように編成
されている。一時的サーバーオブジェクトは、このサー
バーホストプロセス内においてのみ走ることができる。
オブジェクトキーは、一時的サーバーオブジェクトに対
応する識別子である。これら三つの要素、エンドポイン
トアドレスのセット、具体化番号、およびオブジェクト
キーは、一時的サーバーオブジェクトを一義的に（uniq
uely）同定（識別）し、その場所を見いだす。更に、サ
ービスをリクエストするクライアントと一時的サーバー
オブジェクトとの間の効果的な対話を可能にするため、
これら要素のひとつ以上を用いるための様々な実施例と
様々な方法も説明する。

【００１２】これらデータ要素の長さは、いくつかの用
途においては可変長であり、また他の用途においては固
定長である。固定長の場合、１ないし１２８バイトの範
囲の長さが好ましい。ひとつの特定の実施例において
は、エンドポイントアドレスのセットからのひとつのア
ドレスは４バイト長のサーバーホストネットワークアド
レスと２バイト長のサーバープロセスネットワークポー
ト番号とを含む。更にひとつの特定の実施例において
は、具体化番号は本質的には日付スタンプである。すな
わち、サーバープロセスの形成時刻を示す、単調に増加
する番号である。その他の実施例においては、具体化番
号は、サーバープロセスに対して予め定義された意味を
有する、予め定義された番号である。

【００１３】ひとつの特定の実施例において、オブジェ
クトキーは、一時的サーバーオブジェクトのホストとな
るサーバープロセス内において一義的である識別番号で
ある。更にひとつの実施例において、オブジェクトキー
は、別の分散オブジェクトオペレーティング環境のプロ
トコルに従ってフォーマットされたオブジェクトレファ
レンスの転送に用いられる。

【００１４】本発明では、オブジェクトレファレンスの
データ構造は、オブジェクトの種類が一時的であること
を示す内部名（internal name）を含む。

【００１５】本発明では、上記のオブジェクトレファレ
ンスに対応する一時的オブジェクトが考慮される。この
一時的オブジェクトは状態を持っているが、この状態は
厳密には一時的状態である。その他の実施例において
は、一時的オブジェクトはサーバープロセスに限定さ
れ、したがって、サーバープロセス内においてのみ同一
性が連続している。

【００１６】本発明では、分散オブジェクトオペレーテ
ィング環境は、複数のコンピュータシステム、コンピュ
ータシステムどうしを接続するコンピュータネットワー
ク、および一時的サーバーオブジェクトのためのオブジ
ェクトレファレンスとして用いられる少なくともひとつ
のオブジェクトとを含む。装置の別の実施例において、
分散オブジェクトオペレーティング環境は、また、不変
サーバーオブジェクトのためのオブジェクトレファレン
スとして用いられる第２のオブジェクトも含む。第２の
オブジェクトは、ホストコンピュータ名、ロケーターア
イデンティフィケーション（locator identificatio
n）、オブジェクトキー、およびサブオブジェクト識別
子を含むデータ構造を持つ。第２のオブジェクトのデー
タ構造はオプションとして、場所ヒント（location hin
t）と、オブジェクトの種類が不変であることを示す種
類フィールド（kind field）とを含むことができる。

【００１７】第２のオブジェクトのデータ構造におい
て、ホストコンピュータ名は、ホストコンピュータ上で
実行されるサーバーオブジェクトロケーターサービスを
有するホストコンピュータに対応する。ロケーターアイ
デンティフィケーションは、サーバーオブジェクトロケ
ーターオブジェクトが内在するプロセスに対応する。ロ
ケーターオブジェクトは、ロケーターサービスの１コン
ポーネントであり、第２のオブジェクトに関する場所情
報を確定するための問い合わせを受ける。場所情報は、
エンドポイントアドレスのセットおよび具体化番号のよ
うな、第１のオブジェクトデータ構造に類似したデータ
を含む。

【００１８】本発明は、サーバーホストコンピュータ上
に存在するサーバープロセス上で走る分散サーバーオブ
ジェクトをコールする際、一時的オブジェクトと不変オ
ブジェクトを管理するための様々な方法を提供する。ひ
とつの方法面において、クライアントはサーバーオブジ
ェクトへのオブジェクトレファレンスを持ち、クライア
ントのコールは、分散サーバーオブジェクトに関するア
ドレシング情報を獲得するステップ、分散サーバーオブ
ジェクトに関するひとつのアドレスを選択するステッ
プ、および分散サーバーオブジェクトへリクエストを送
るステップを含む。更に追加の実施例において、この方
法は、分散サーバーオブジェクトから応答を受けるステ
ップを含む。

【００１９】更に、ひとつの方法面において、アドレス
情報獲得ステップは、一時的、不変、ナル、および無効
の各種類を含む、分散サーバーオブジェクトの種類を判
定するサブステップを含む。次に、分散サーバーオブジ
ェクトの種類次第で、様々な方法が実行できる。種類が
ナルまたは無効の場合、エラーメッセージが返される。
種類が一時的である場合、アドレシング情報がオブジェ
クトレファレンスから直接返される。種類が不変である
場合、アドレシング情報獲得ステップは更に、アドレシ
ング情報がクライアントホストコンピュータ上のキャッ
シュメモリに格納されているか否かを判定するサブステ
ップおよびアドレシング情報を直接キャッシュメモリか
ら返すサブステップを更に含む。アドレシング情報がキ
ャッシュメモリに格納されていない場合、アドレシング
情報は、分散オブジェクトオペレーティング環境内から
獲得され、キャッシュメモリに格納され、次に直接キャ
ッシュメモリから返される。

【００２０】方法の更にひとつの面において、アドレス
選択ステップは、前記クライアントと前記サーバーが同
じプロセスに含まれているか否かを判定するステップを
含み、含まれている場合、ローカルアドレスとローカル
トランスポートモードが選択される。方法の更にひとつ
の面において、クライアントとサーバーが異なるプロセ
スに含まれている場合、サーバーホストコンピュータが
クライアントホストコンピュータと同一であれば、共有
メモリーアドレシングと共有メモリートランスポートが
選択される。しかし、共有メモリーアドレシングを利用
できないか、あるいは、サーバーホストコンピュータが
クライアントホストコンピュータと同一でない場合、リ
モートアドレシングとリモートトランスポートが選択さ
れる。

【００２１】方法の別の面においては、分散オブジェク
トオペレーティング環境におけるホストコンピュータ上
のキャッシュメモリ内の分散オブジェクトアドレシング
情報を保守するための方法を提供する。この方法は、分
散オブジェクトに対応するオブジェクトレファレンスが
受信されると開始される。次に、このオブジェクトレフ
ァレンスが分散オブジェクトに関するアドレシング情報
を含んでいれば、このアドレシング情報はキャッシュメ
モリへ書き込まれる。いくつかの実施例においては、オ
ブジェクトレファレンスは目標オブジェクトコールの一
部として受信され、また、他の実施例においては、目標
オブジェクトコールに応答して受信される。いずれにし
ても、受信ステップは、アドレシング情報が利用可能で
あるかどうか判定する前に、オブジェクトレファレンス
のマーシャリングを含むことができる。

【００２２】関連した方法面において、分散オブジェク
トオペレーティング環境の一部である複数のホストコン
ピュータの各々は、それ自体のキャッシュメモリを持っ
ている。これら各コンピュータの各々が、自らのキャッ
シュメモリ内で利用可能なアドレシング情報を増やすた
め、前のパラグラフの方法を実行する。更に、ホストコ
ンピュータのいずれかひとつが新しいアドレシング情報
の場所を見いだした場合、そのコンピュータは、その情
報をオブジェクトレファレンスへとマーシャルし、分散
オブジェクトオペレーティング環境の一部である他のホ
ストコンピュータへ分配することによって、本発明の利
点を永続させる。

【００２３】

【発明の実施の形態】本発明は、オブジェクト指向プロ
グラミング（ＯＯＰ）に基づく分散オペレーティング環
境に関し、更に特定すれば、オブジェクトを管理するた
めの方法、装置およびデータ構造を提供する。考察の対
象となるオブジェクトの種類は、一時的オブジェクトお
よび不変オブジェクトを含む。一時的オブジェクトは不
変状態を維持せず、オブジェクトを走らせるプロセスの
寿命に直接結びついている。いわば、不変状態とは、あ
るプロセスから別のプロセスへと持続（つまり橋渡し）
する状態である。他方、不変オブジェクトは不変状態と
一時的状態の両方を持つことができ、ある時間持続する
のが普通である。以下の考察においては、様々な種類の
オブジェクトを更に詳細に説明するが、まず本発明に適
したコンピュータシステムの例を考察し、次に、本発明
の装置およびデータ構造の実施例のいくつかを詳細に説
明し、次に本発明の方法面を詳細に説明する。

【００２４】Ｉ．用語の定義 ここで用いる場合、「分散オブジェクト」または「オブ
ジェクト」という用語は、ひとつのオブジェクトに関連
付けられている定義されたインターフェイスを介したオ
ペレーションによって操作することのできるコードとデ
ータのカプセル化されたパッケージをいう。したがって
当業者は、分散したオブジェクトを、従来のプログラミ
ングオブジェクトを定義する基本的特性を含むものと見
なすであろう。しかし、分散したオブジェクトは、ふた
つの重要な特徴を含むことによって従来のプログラミン
グオブジェクトとは異なる。第１に、分散したオブジェ
クトは多言語的である。分散オブジェクトのインターフ
ェイスは様々なプログラミング言語にマップされ得るイ
ンターフェイス定義言語を用いて定義される。そのよう
なインターフェイス定義言語のひとつがＯＭＧ ＩＤＬ
である。第２に、分散オブジェクトは場所独立性であ
る、すなわち、分散オブジェクトはネットワーク内のど
こでもその場所を見いだすことができる。このことは、
単一のアドレススペースすなわち「クライアント」のア
ドレススペース内に存在する従来のプログラミングオブ
ジェクトに対して著しく対照的である。分散オブジェク
トは、リクエストを他のオブジェクトへ送っているか、
他のオブジェクトからのリクエストに答えているかによ
って、オブジェクトクライアントかオブジェクトサーバ
ーかのいずれかとなる。リクエストおよび回答は、オブ
ジェクトの場所と状態を認識しているオブジェクトリク
エストブローカ（ＯＲＢ）を介して行われる。

【００２５】「分散オブジェクトシステム」または「分
散オブジェクトオペレーティング環境」とは、ＯＲＢを
介して通信を行う分散オブジェクトから成るシステムを
いう。

【００２６】「オブジェクトレファレンス」または「オ
ブジェレフ(objref)」とは、他のオブジェクトへのポイ
ンタを含むデータ構造（従来のプログラミング言語オブ
ジェクトであってもよい）をいう。オブジェクトレファ
レンスの形成と定義は当業者にとっては周知であろう。

【００２７】ここで定義する「クライアント」はいずれ
かのオブジェクトへリクエストを送るエンティティのこ
とである。このモデルにおいては、このオブジェクトは
サービスを提供し、「サーバーオブジェクト」または
「目標オブジェクト」と呼ばれる。クライアントは、サ
ーバーからオペレーションまたは実行（implementation
s）を発動させる。クライアント自体がオブジェクトで
ある場合もある。分散オブジェクト環境においては、当
該オブジェクトの要件が多言語性であるので、クライア
ントは、実装プログラミング言語の知識を持つ必要がな
く、実装もクライアントのプログラミング言語の知識を
持つ必要がない。分散オブジェクトオペレーティング環
境におけるクライアントとサーバーは、インターフェイ
ス定義言語のみを用いて通信すればよい。上に述べたよ
うに、クライアントによるサーバーへのリクエストとク
ライアントへのサーバーの回答はＯＲＢによって処理さ
れる。クライアントとサーバーは、同じプロセス内、同
じホストコンピュータ上、または２台の異なるコンピュ
ータ上に存在できることを指摘しておく。

【００２８】「オブジェクトインターフェイス」とは、
あるオブジェクトが提供するオペレーション、属性、お
よび例外の仕様のことである。分散オブジェクトのオブ
ジェクトインターフェイスはＩＤＬを用いて書くことが
望ましい。上に述べたように、オブジェクトはそれらの
インターフェイスを介して処理を行う。従って、インタ
ーフェイスを使用することにより、処理の際の方法とオ
ブジェクトのデータを定義するプログラミング言語をク
ライアントが認識する必要性がなくなる。

【００２９】情報のパケットを「マーシャル（整頓）す
る」とは、この情報を共有メモリ通信チャネルまたはネ
ットワーク通信ラインを介して転送するように準備する
ことである。これはしばしば、使用するネットワーク通
信プロトコルに従ってデータを系統化することを意味す
る。

【００３０】情報のパケットを「アンマーシャル（整頓
解除）する」とは、本質的にマーシャリング手順を逆に
することであって、適当な環境において意味をもつフォ
ーマットにおいてデータを作成することである。

【００３１】ＩＩ．オブジェクトの管理 本発明は、分散コンピューティングシステム、クライア
ントサーバーコンピューティング、およびオブジェクト
指向プログラミングに関する。更に特定すれば、本発明
は、一時的オブジェクトおよび不変分散オブジェクトを
管理するための方法、装置、およびデータ構造を提供す
る。

【００３２】ここで用いる場合、「分散オブジェクト」
または「オブジェクト」とは、インターフェイスを介し
たオペレーションによって操作され得るコードとデータ
のカプセル化されたパッケージをいう。また、本発明の
分散オブジェクトは、背景で記載したような特徴を含む
ことができる。例えば、分散オブジェクトは、他のオブ
ジェクトへリクエストを送っているか、あるいはクライ
アントからのリクエストに回答しているかによって、オ
ブジェクトクライアントあるいはオブジェクトサーバー
となり得る。

【００３３】分散オブジェクト環境においては、リクエ
ストと回答は、オブジェクトの場所と状態を認識してい
るオブジェクトリクエストブローカ（ＯＲＢ）を介して
行われる。そのようなＯＲＢの実装に適した１つのアー
キテクチャが、共通オブジェクトリクエストブローカア
ーキテクチャ（ＣＯＲＢＡ）仕様によって提供される。
ＣＯＲＢＡ仕様は、サービスをリクエストするクライア
ントへサーバーオブジェクトがサービスを提供すること
ができる、分散クライアント-サーバー環境におけるオ
ブジェクトに関して分散コンピューティング環境世界を
定義するため、オブジェクト管理グループ（ＯＭＧ）に
よって開発された。以下の考察において、「オブジェク
ト」および「分散オブジェクト」は、以下の発明が両者
に向けられているので互換性をもって用いられる。

【００３４】本発明の好ましい実施例において、分散オ
ブジェクトはネットワークによって相互接続された１台
以上のコンピュータ上にある。このネットワークは任意
の適当な形式を取ることができる。例を用いて、代表的
なネットワーク編成１０を図１に示す。このネットワー
ク編成１０は、伝送線１４に結合された第１のコンピュ
ータ１２を含む。このネットワーク１０は、更に、デー
タや命令をネットワーク化されたコンピュータ間でやり
とりできるように、他のコンピュータ１８、２０および
２２に加えてサーバー、ルーター等１６も含む。コンピ
ュータネットワークの設計、構成、および実装は当業者
にはなじみである。

【００３５】図１のコンピュータ１２、１８、２０、お
よび／または２２としての使用に適した代表的なコンピ
ュータ３０の概略を図２に示す。コンピュータ３０は、
中央処理装置（ＣＰＵ）３２を含み、これはランダムア
クセスメモリ（ＲＡＭ）３４と双方向的に、またリード
オンリーメモリ（ＲＯＭ）３６と一方向的に結合されて
いる。通常、ＲＡＭ３４は「スクラッチパッド」メモリ
として用いられ、現在ＣＰＵ３２上で作動中のプロセス
のための、分散オブジェクトおよびそれらに関連するコ
ードと状態を含むプログラミング命令とデータを含む。
一時的状態はＲＡＭ３４のような一時的メモリにしばし
ば格納されることに注意されたい。ＲＯＭ３６は、通
常、コンピュータがその機能を実行するためにコンピュ
ータが用いる基本的なオペレーティング命令、データお
よびオブジェクトを含む。更に、ハードディスク、ＣＤ
ＲＯＭ、磁気光（フロプティカル）ドライブ、テープ
ドライブ等の大容量記憶装置３８がＣＰＵ３２へ双方向
的に接続されている。大容量記憶装置３８は、通常はＣ
ＰＵによって頻繁に用いられない追加のプログラミング
命令、データ、およびオブジェクトを含むが、アドレス
スペースはＣＰＵによる、例えばバーチャルメモリ等の
ためのアクセスが可能である。不変状態は、しばしば記
憶装置３８等の不変メモリに格納されることに注目され
たい。上記の各コンピュータは、オプションとしてキー
ボード、ポインタ器具（例えばマウスまたはスタイラ
ス）および／またはネットワーク接続のような入力媒体
を含む入出力媒体４０を含む。追加の大容量記憶装置
（図示せず）をネットワーク接続を介してＣＰＵ３２に
接続することもできる。上記のハードウェア要素および
ソフトウェア要素、更にネットワーキング装置の設計と
構造は標準的なものであり、当業者にはなじみのもので
あることが、当業者には理解されるであろう。

【００３６】クライアントおよびサーバーについての考
察に戻ると、分散オブジェクト環境を支えるもののひと
つは、ここでサービスをリクエストするエンティティと
して定義されるクライアントと、普通はサービスを提供
するオブジェクトであるサーバーとの間の対話である。
例えば、クライアントとサーバーが、同じプロセス内、
同じホストコンピュータ上の別々のプロセス内、および
別々のホストコンピュータ上で走る別々のプロセス上に
あるという、様々なシナリオがある。このクライアント
-オブジェクト対話は、クライアント-サーバーモデルに
関して考察することができる。例えば、クライアント
は、遠隔のコンピュータ１８上で走る別のプロセス内の
サーバーオブジェクトからサービスをリクエストするコ
ンピュータ１２のようなネットワークコンピュータ上で
実行されるプロセス中にあってもよい。

【００３７】同じく当業者が理解するであろうように、
上記のエンティティ（これはクライアントであることが
できる）は、ホストコンピュータ上で実行されるプロセ
ス（以下それぞれクライアントプロセスおよびクライア
ントホストという）およびオブジェクト（以下クライア
ントオブジェクトという）を、これらに限定せずに、含
む。したがって、クライアントは、エンティティのタイ
プに係わらず、サービスをリクエストするエンティティ
である。明瞭にするために、サービスを提供するオブジ
ェクトを以下、目標オブジェクトまたはサーバーオブジ
ェクトと互換可能に用いる。したがって、以下の説明に
おいてクライアントが目標オブジェクトを発動する場
合、クライアントはクライアントプロセスまたはクライ
アントオブジェクトなど、任意のエンティティであり得
る。

【００３８】クライアント-サーバー対話の用語を更に
説明すると、クライアントは、目標オブジェクトによっ
て実行される「方法」を「発動する（invoke）」ために
目標オブジェクトを「コール」する。「コール」と「発
動」とは意味が多少異なるが、ここではふたつの語は互
換性をもって用いられ、両語の意味はここでの考察の文
脈から理解される。当業者にはよく知られているよう
に、方法はオブジェクト内に含まれている手順であっ
て、このオブジェクトが当該オブジェクトのサービスを
リクエストする目的のために他のエンティティ（例えば
クライアント）に利用可能とされている。従って、クラ
イアントのためにサービスを行うオブジェクトはサーバ
ーであり、ここからクライアント-サーバー（client-se
rver）なる用語が生まれる。方法をコールする際、クラ
イアントは、また、リクエストされた方法を目標オブジ
ェクトが実行するのに必要な、パラメーターとも呼ばれ
るアーギュメントを転送してもよい。先の用語「方法」
は、オブジェクト指向プログラミングの技術の用語であ
って、特許出願の作成で伝統的に用いられる用語の「方
法」とは異なることに注目されたい。以下の考察におい
て、用語「方法」がどちらの意味において用いられてい
るか（文脈上または本出願人の示唆により）明らかにさ
れている。

【００３９】次に、図３ないし図５を参照し、分散オブ
ジェクト環境をまさしく表すクライアント-サーバーモ
デルの２，３の可能例を列挙し考察する。常にそうであ
るが、クライアント-サーバーモデルはクライアントエ
ンティティと、サーバーエンティティである目標オブジ
ェクトとを有する。下記のクライアント-サーバーモデ
ルのためのそのような編成のひとつは、図１に示したネ
ットワーク１４を介して相互接続された図２のコンピュ
ータ３０のようなコンピュータを含む。

【００４０】まず、図３を参照すると、分散オブジェク
トオペレーティング環境３０１内の別々のホストコンピ
ュータ上にクライアント３０２と目標オブジェクト３０
４が存在する「ホストからホストへ」と呼ばれるクライ
アント-サーバーモデル３００が示されている。クライ
アント３０２はクライアントホストコンピュータ３０８
上で走っているクライアントプロセス３０６内に存在す
る。クライアント３０２は、オブジェクトレファレンス
３１４を保持する（すなわちオブジェクトレファレンス
３１４への第１のインディレクション３１２を有する）
第１の代理オブジェクト３１０を用いる。一方、オブジ
ェクトレファレンス３１４は目標オブジェクト３０４へ
第２のインディレクション３１６を与える。ここで用い
る場合、あるオブジェクトへのインディレクションと
は、多分オブジェクトとの直接対話によらないかも知れ
ないが、オブジェクトの場所を見いだすのに十分なだけ
の情報である。図３の場合、第１のインディレクション
３１２は、通常、オブジェクトレファレンスへの単なる
直接ポインタであるが、第２のインディレクション３１
６はしばしば更に複雑である。インディレクション３１
６のようなインディレクションについては、後に図７
（ａ）および図７（ｂ）を参照して更に詳細に説明す
る。また、クライアントプロセス３０６内には、同じく
オブジェクトレファレンス３１４を保持することがある
第２の代理オブジェクト３１１のような、他の代理オブ
ジェクトがクライアントプロセス３０６内に存在するこ
とがある。いくつかの場合、代理オブジェクト３１０お
よび３１１は、従来のプログラミング言語オブジェクト
であり得る。しかし、いくつかの分散オブジェクトオペ
レーティング環境は代理オブジェクトを含んではいない
ことがある。このような場合、クライアント３０２は代
理オブジェクトを伴わないオブジェクトレファレンス３
１４を使うことになろう。

【００４１】クライアント３０２と同様に、図３の目標
オブジェクト３０４は、サーバーホスト３２０上で実行
されているサーバープロセス３１８内に存在することが
できる。他のエンティティは、サーバーホスト３０８と
クライアントホスト３２０のいずれにも存在することが
できる。これらは、クライアントプロセス、サーバープ
ロセス、および／または追加のプロセスのもとで走る追
加のプロセスおよび／またはオブジェクトを、これらに
限定せずに含む。２つの適当なプロセスは、クライアン
トホスト３０８上で実行される daemon 1 プロセス３１
７と、サーバーホスト３２０上で実行される daemon 2
プロセス３２１である。普通、デーモンプロセスはバッ
クグラウンドで実行され、当業者には周知である。

【００４２】図３に示すように、ホストからホストへの
場合、クライアント３０２は、そのコールをいくつかの
「層」、すなわち、目標オブジェクトに対してリクエス
トされるサービスに直接関係のない複雑なものを通って
目標オブジェクト３０４へ転送しなければならない。ホ
ストからホストへの例においては、クライアント３０２
と目標オブジェクト３０４との間にネットワーク接続を
形成しなければならない。クライアントホスト３０８と
サーバーホスト３２０、およびクライアントプロセス３
０６とサーバープロセス３１８等のように、層は異なる
ので、クライアント-サーバーネットワーク接続を直接
形成することはできない。むしろ、クライアントプロセ
ス３０６はコールを解釈し、それを代理オブジェクト３
１０に転送する。代理オブジェクト３１０は、ＯＲＢを
用いてまずサーバーホスト３２０を見いだし、次に、サ
ーバープロセス３１８と目標オブジェクト３１４を識別
する。更に、このデータがネットワークを介して転送さ
れる際、このデータはマーシャル（すなわち、ネットワ
ークを介した転送の準備として、ネットワーク通信プロ
トコルに従ってフォーマット）され、送られ、受信さ
れ、最後にアンマーシャルされねばならない。したがっ
て、ホストからホストへ、はクライアント-サーバー対
話の複雑なケースである。したがって、追加の層とその
結果としてのステップが、ホストからホストへのクライ
アント-サーバー対話を、システム資源活用の面におい
て、しばしば最も高価になる可能性のある対話にしてい
る。

【００４３】図４は、クライアント３０２と目標オブジ
ェクト３０４が同じホストコンピュータ、クライアント
／サーバーホスト３２２を共有している「プロセスから
プロセスへの」クライアント-サーバーモデルを示す。
しかし、クライアント３０２と目標オブジェクト３０４
は、別々のプロセス内に存在する。図３と同様に、クラ
イアント３０２は、クライアント／サーバーホスト３２
２上で走っているクライアントプロセス３０６内に存在
する。クライアント３０２は、オブジェクトレファレン
ス３１４を保持する（すなわちオブジェクトレファレン
ス３１４への第１のインディレクション３１２を有す
る）第１の代理オブジェクト３１０を用いる。一方、オ
ブジェクトレファレンス３１４は目標オブジェクト３０
４へ第２のインディレクション３１６を与える。目標オ
ブジェクト３０４は、クライアント／サーバーホスト３
２２上で走っているサーバープロセス３１８内に存在す
る。「ホストからホストへ」の場合と同様に、プロセス
および／またはオブジェクト等の追加のエンティティが
クライアント／サーバーホスト３２２上に存在すること
ができる。例えば、同じくオブジェクトレファレンス３
１４を保持するかもしれない第２の代理オブジェクト３
１１のような、クライアントプロセス３０６内に存在す
る他の代理オブジェクトが存在してもよい。しかし、い
くつかの分散オブジェクトオペレーティング環境は、代
理オブジェクトを含まない。そのような場合、クライア
ント３０２は代理オブジェクトを伴わないオブジェクト
レファレンス３１４を用いる。いずれにしても、プロセ
スからプロセスへの対話は、ホストからホストへの対話
よりもはるかによい。これは、ネットワーク通信ステッ
プが不要であることが一因である。

【００４４】図５は、クライアント３０２と目標オブジ
ェクト３０４が共に同じプロセス、クライアント／サー
バープロセス３２４内に存在するクライアントサーバー
モデルを示す。ここでも、クライアント３０２は、オブ
ジェクトレファレンス３１４を保持する（すなわちオブ
ジェクトレファレンス３１４への第１のインディレクシ
ョン３１２を有する）第１の代理オブジェクト３１０を
用いる。一方、オブジェクトレファレンス３１４は目標
オブジェクト３０４へ第２のインディレクション３１６
を与える。この場合、第２のインディレクション３１６
は、共有メモリへのポインタでありさえすればよい。こ
の状況は、多分前記三つのケースのうちで最良のもので
あろう。ネットワーク通信が不要であり、また、両オブ
ジェクトがひとつのプロセスのもとにあるので、両者は
クライアント／サーバープロセス３２４に割り当てられ
たメモリ内に共存する。図５の状況においては、オブジ
ェクト等、他のエンティティは、クライアント／サーバ
ープロセス３２４内に存在することができる。例えば、
クライアントプロセス３０６内には、第２の代理オブジ
ェクト３１１のような他の代理オブジェクトが存在して
もよく、この第２の代理オブジェクト３１１は、同じく
オブジェクトレファレンス３１４を保持する。しかし、
いくつかの分散オブジェクトオペレーティング環境は、
代理オブジェクトを含まない。そのような場合、クライ
アント３０２は代理オブジェクトを伴わないオブジェク
トレファレンス３１４を用いる。

【００４５】上記図面に示さなかった他の２つの代表的
なクライアント-サーバーシナリオについて、以下に簡
単に説明する。第１のシナリオは、クライアントがオブ
ジェクトである実施例に係わる。当業者には理解できる
ように、クライアントがオブジェクトであってもサービ
スをリクエストする他のエンティティであっても、発生
する問題は非常に似ている（しばしば同一である）。他
のシナリオは、クライアントオブジェクトと目標オブジ
ェクトが自己同一オブジェクトであるシナリオでる。こ
れは、オブジェクトがそれ自身に対して再帰コールを行
う場合に起こり得る。再帰コールは異常と思われるかも
知れないが、このクライアント-サーバー対話はかなり
ありふれたもので、強力な手段であり、クライアントオ
ブジェクトと目標オブジェクトがユニークであるが同じ
プロセス内に存在する場合と類似の（あるいは多分同一
の）方法で、処理することができる。

【００４６】図６（ａ）は、不変オブジェクト４０１が
三つの異なる状態にわたる経緯を示す。最初の移行４０
０によって、不変オブジェクト４０１は前の状態から状
態１になる。オブジェクト４０１の状態１は、一時的状
態４０２と不変状態４０４の両方を含む。移行４０６に
よって、不変オブジェクト４０１は状態１から状態２に
なる。状態１と同様に、オブジェクト４０１の状態２
も、一時的状態４０８と不変状態４１０の両方を含む。
最後に、移行４１２によって、不変オブジェクト４０１
は状態２から状態３になる。ここでも、オブジェクト４
０１の状態３は、一時的状態４１４と不変状態４１６の
両方を含む。不変オブジェクト４０１に関して、移行４
００、４０６、および４１２は、オブジェクトが存在し
ている状態でのプロセス終了を含めて、オブジェクト４
０１の状態を変える任意のオペレーションであればよ
い。不変オブジェクトは各段階において不変状態を含ん
でいるので、それはプロセスどうしを橋渡しするととも
に、長期間にわたって自己を維持する能力を持つ。

【００４７】これと対照的に、図６（ｂ）は一時的オブ
ジェクト４１７の三つの異なる状態にわたる経過を示
す。最初の移行４１８によって、一時的オブジェクト４
１７は、前の状態から状態Ａになる。一時的オブジェク
ト４１７の状態Ａは、一時的状態４２０を含むが、何ら
の不変状態も含まない。移行４２２によって、一時的オ
ブジェクト４１７は、状態Ａから状態Ｂになる。状態Ａ
と同様に、一時的オブジェクト４１７の状態Ｂは、一時
的状態４２４を含み、何らの不変状態も含まない。最後
に、移行４２６によって、一時的オブジェクト４１７は
状態Ｂから状態Ｃになる。ここでも、一時的オブジェク
ト４１７の状態Ｃは、一時的状態４２８を含み、何らの
不変状態も含まない。一時的オブジェクト４１７に関し
て、移行４１８、４２２、および４２６は、一時的オブ
ジェクト４１７が存在しているプロセスの終了を含むオ
ペレーションを除き、一時的オブジェクト４１７の状態
を変化させる任意のオペレーションであればよい。一時
的オブジェクト４１７は不変メモリを含まないので、プ
ロセスどうしを橋渡しすることはできない。したがっ
て、一時的オブジェクトは、唯一のプロセス内に存在
し、プロセスが終了するときに消滅する。また、プロセ
スの場所とアドレスは変更できないので、一時的オブジ
ェクトの場所とアドレスも変更できないことに注目され
たい。

【００４８】クライアント-サーバーモデルと、一時的
オブジェクトと不変オブジェクトへの関連性の上記考察
から、クライアント-サーバー対話を効率的にかつ融通
性をもって処理するためのフレームワークが好ましいこ
とが明らかである。装置とデータ構造を提供するひとつ
のフレームワークをここで説明する。

【００４９】前記クライアント-サーバー対話を容易に
するため、分散オブジェクトオペレーティングステム
（ＣＯＲＢＡによって定義される分散アーキテクチャを
含む）は、通常「オブジェクトレファレンス」と称する
オブジェクトを組み込んでいる。オブジェクトレファレ
ンスは、オペレーションの一般的パラメータを提供する
ほか、個々のオペレーションリクエストの目標オブジェ
クトの場所を見いだし識別する役割を果たす。様々な種
類のオブジェクトの処理は異なるので、同じフレームワ
ークのもとで、一時的オブジェクトと不変オブジェクト
を組み込んだ従来の技術には何の示唆もない。しかし、
本発明は、一時的オブジェクトと不変オブジェクトを統
合する分散オブジェクトオペレーティング環境内で用い
るためのフレームワークを含んでいる。一時的オブジェ
クトレファレンスと不変オブジェクトレファレンスを組
み込んだ実施例を後で更に詳細に説明する。

【００５０】オブジェクトレファレンスは、クライアン
トをその対応する目標オブジェクトへ指向させるので、
「オブジェクトレファレンス」という用語を修飾するの
に用いられる際、「一時的な」と「不変の」という形容
詞に対する別の有意義な見方がある。不変オブジェクト
レファレンスは、同一性が連続している分散オブジェク
トへのインディレクションである（分散オブジェクトの
場所を見いだし識別する）。したがって、不変オブジェ
クトレファレンスのインディレクションは、それが常に
有効（不変オブジェクトの同一性が破壊されない限り）
であるので、不変インディレクションである。これとは
対照的に、一時的オブジェクトレファレンスは、同一性
が連続していない分散オブジェクトへのディレクション
である。したがって、一時的オブジェクトレファレンス
のディレクションは、一時的ディレクションである。

【００５１】一時的オブジェクトレファレンスと不変オ
ブジェクトレファレンスの他に、更に二種類のオブジェ
クトレファレンスを挙げなければならない。ひとつは
「ナル（ゼロ）」オブジェクトレファレンスであり、も
うひとつは「無効」オブジェクトレファレンスである。
一時的オブジェクトレファレンスと不変オブジェクトレ
ファレンスと同様に、ナルオブジェクトレファレンスと
無効オブジェクトレファレンスとはナルオブジェクトと
無効オブジェクトとに対応する。ナルオブジェクトは、
インターフェイスを持たないか、あるいは、クライアン
トにサービスを提供しないオブジェクトであるかもしれ
ない。好ましい実施例においては、ナルオブジェクトレ
ファレンスはサポートされるので、」コード化できる。
無効オブジェクトは普通、非存在オブジェクトまたは不
適当に形成されたオブジェクトであり、通常はサポート
されない。したがって、無効オブジェクトは普通はコー
ド化しなくてもよい。

【００５２】図７（ａ）は、本発明の一実施例による一
時的オブジェクトレファレンス５００に関するデータ構
造の説明図である。オブジェクトレファレンス５００
は、種類フィールド５０１、１セットのエンドポイント
アドレス５０２、具体化番号５０４、およびオブジェク
トキー５０６を含む。好ましい実施例においては、種類
フィールド５０１は、それに向かってオブジェクトレフ
ァレンス５００がインディレクトするオブジェクトの種
類を表すデータ要素である。他の実施例において、種類
フィールド５０１は、オブジェクトレファレンス５００
に含まれず、オブジェクトの種類は、オブジェクトレフ
ァレンス５００のデータ構造の顕著な特徴（distinguis
hing features）によって判定される。すなわち、オブ
ジェクトレファレンスがインディレクトする対象である
オブジェクトの種類は、オブジェクトレファレンスのデ
ータ構造によって一義的に判定される。

【００５３】図７（ａ）の考察を続けると、エンドポイ
ントアドレスのセット５０２は、クライアントがサーバ
ーホストと、目標オブジェクトが内在するかもしれない
サーバープロセスの場所を見いだすために必要なアドレ
シング情報を含む。この情報は、サーバーホストネット
ワークアドレス、サーバープロセスネットワークポート
番号、および／または目標オブジェクトのメモリ場所等
の要素を含むことができる。更に、エンドポイントアド
レスのセットは、それぞれ有効な複数のアドレスを含む
ことができる。エンドポイントアドレスのセットは、可
変長または固定長のデータ要素を含むことができる。固
定長データ要素の適切な長さの範囲は約１ないし１２８
バイトであるが、好ましい長さの範囲は約２４ないし９
６バイト、更に好ましい長さは約６４バイトである。例
えば、ネットワークプロトコルが、周知の通信制御プロ
トコル／インターネットプロトコル（ＴＣＰ／ＩＰ）で
あれば、アドレシング情報５０２のセット内のひとつの
アドレスは６バイトのデータ要素を含むことができ、そ
のうち最初の４バイトはネットワーク順のＴＣＰ／ＩＰ
サーバーホストネットワークアドレスで、あとの２バイ
トは同じくネットワーク順のＴＣＰ／ＩＰサーバープロ
セスネットワークポート番号である。

【００５４】図７（ａ）のオブジェクトレファレンス５
００のもうひとつの要素である具体化番号５０４は、ア
ドレスを再使用する際、ＯＲＢリクエストを間違った宛
先へ誤発送しないための識別子である。言い換えれば、
たとえサーバーホストアドレスとサーバープロセス同定
事項（identification）を正確に指示するアドレシング
情報のセットを用いても、サーバープロセスが依然とし
て一義的に識別されない可能性がある。以下で考察する
ように、本発明の具体化番号はＯＲＢの誤発送の可能性
を克服する。

【００５５】誤発送が一見あり得ないように思われて
も、一時的オブジェクトとそれらのホストサーバープロ
セスがどのように管理されるかを注意深く考慮しなけれ
ばならない。一時的オブジェクトはプロセスからプロセ
スへは存在せず、それらのサーバープロセスが終了する
とき終了する。しかし当業者が理解するように、作動中
のコンピュータはコンピュータプロセスを常に作成しま
た削除しており、その各プロセスは特定のネットワーク
アドレスを持っている。したがって、ひとつのプロセス
が終了することによって、そのプロセス内に存在するす
べてのユニークな一時的オブジェクトを終了させるとと
もにネットワークアドレスを解放する可能性が、確実に
ある。利用可能なネットワークアドレスの量は有限であ
るので（普通は 32,768 すなわち 32k）、このネットワ
ークアドレスは再使用される可能性がある。したがっ
て、終了したばかりの一時的オブジェクトへのリクエス
トは、他の何らかの顕著な同定事項（distinguishing i
dentification）を付与してやらなければ、ＯＲＢによ
って誤った宛先へ向けられる可能性がある。

【００５６】ＯＲＢが具体化番号５０４を解釈する役割
を果たすので、ＯＲＢ、より具体的にはオブジェクトア
ダプタ（ＯＡ）が普通は具体化番号５０４を割り当てる
役割を果たす。この番号は、ＯＲＢによって識別可能で
ありさえすれば、任意である。具体化番号５０４の様々
な実施例が考慮されている。例えば、具体化番号５０４
に、タイムスタンプのような何らかの単調増加値を割り
当てれば、同時には存在しないが、偶然に同じアドレス
を受信する別々のプロセスどうしをＯＲＢが区別するこ
とができる。その他の場合、区別不可能な（indistingu
ishable）ふたつ以上のプロセスを持つことが望まし
い。この場合、同一の具体化番号を意図的に割り当てる
ことが可能である。具体化番号５０４にゼロ等の予め定
められた番号を割り当てることが望ましい場合、更に追
加の状況が発生するかも知れない。いずれにしても、具
体化番号５０４は、所定のプロトコル次第で可変長か固
定長のデータ要素を含むことができる。固定長データ要
素の適切な長さは約１ないし１６バイトであるが、好ま
しい長さは約２ないし６バイト、更に好ましい長さは約
４バイトである。

【００５７】当業者には理解できるように、上記または
他の実施例において説明した具体化番号は、分散オブジ
ェクトオペレーティング環境が一時的オブジェクトを間
違いなく区別することを可能にする。具体化番号は、本
発明には新規であり、分散オブジェクト環境の範囲内に
おける不変オブジェクトと一時的オブジェクトの使用を
可能にする。

【００５８】図７（ａ）の一時的オブジェクトレファレ
ンス５００の最後に示した要素はオブジェクトキー５０
６である。一実施例においてオブジェクトキー５０６
は、サーバープロセス内のオブジェクトどうし間で区別
する役割を果たす。所定のプロトコル次第で、オブジェ
クトキー５０６は、固定長または可変長のデータ要素を
含むことができる。固定長データ要素の適切な長さは約
１ないし１６バイトであるが、好ましい長さは約４ない
し８バイト、更に好ましい長さは約６バイトである。

【００５９】図７（ｂ）は、本発明の一実施例による不
変オブジェクトレファレンス５１０の説明図である。不
変オブジェクトレファレンス５１０は、不変サーバーオ
ブジェクトへ指向するオブジェクトであって、種類フィ
ールド５１１、ホスト名５１２、ロケータ識別番号（ロ
ケータ id）５１４、オブジェクトキー５１６、および
サブオブジェクト識別子５１８を含む。図示のように、
不変オブジェクトレファレンスはオプションの場所ヒン
ト５２０を含むことができる。図７（ａ）に関して上に
説明したように、種類フィールド５１１は、オブジェク
トレファレンス５１０がインディレクトする対象である
オブジェクトの種類を表すデータ要素である。ホスト名
５１２は、目標オブジェクトの場所を維持する役割を果
たすロケータサービス（これはロケータプロセスまたは
ロケータオブジェクト等のエンティティである）を有す
るホストコンピュータを表す。例えば、ホスト名５１２
はネットワークアドレスを含むことができる。好ましい
実施例において、ホスト名５１２によって表されるホス
トコンピュータは、内在する目標オブジェクトを有す
る。

【００６０】次に、図７（ｂ）の不変オブジェクトレフ
ァレンス５１０の三番目に示した要素を参照すると、ロ
ケータ id ５１４は、ホスト名によって定義されるホス
ト上のロケータサービスを一義的に識別する。一実施例
においては、ロケータ id は固定長データ要素を含む。
例えば、ロケータ id ５１４の適切な一実施例は、当該
ロケータに関するリモート手順コール（ＲＰＣ）プログ
ラム番号である。ＲＰＣプロトコルと、ＲＰＣプログラ
ム番号の形成とは、当業者にはなじみである。一般的
に、ＲＰＣサービスは、一定のＲＰＣプログラム番号と
所望のサーバープロセスアドレシング情報との間の対応
（correspondence）を維持する。すなわち、ＲＰＣサー
ビスは、サーバープロセスアドレシング情報が変更され
ると、常に更新される。したがって、分散オブジェクト
システムは、不変オブジェクトレファレンスを更新する
必要がない。この場合、ロケータ id ５１４は４バイト
の固定長データ要素とすることができる。次に図７
（ｂ）の四番目の要素に目を向けると、一実施例のオブ
ジェクトキー５１６は、ロケータに関する目標オブジェ
クトを一義的に定義する。したがって、ロケータは、オ
ブジェクトキー５１６を用いて、どの所望の目標オブジ
ェクトがリクエストされてるかを判定する。

【００６１】組合わせされたデータ要素５１２ないし５
１６は、この技術分野で「インディレクション」として
当業者は周知な一例を構成する。「インディレクショ
ン」とは、クライアントエンティティを（ロケーターオ
ブジェクト等の）ソースへ差し向ける情報、ポインタ等
のセットであって、このソースがクライアントエンティ
ティをオブジェクトへ指向させることができる。たとえ
話をすると、あるクライアントが地理的方向をリクエス
トしたとすると、インディレクションは、クライアント
を現在の地図の場所を向かせるか、あるいは多分、地理
に詳しい個人の電話番号を教えるであろう。（直接のア
ドレシングよりもむしろ）インディレクションを用いる
というアイデアは、不変オブジェクトがプロセス同士
間、ホストコンピュータ同士間を移動するので、不変オ
ブジェクトには有利である。

【００６２】引き続き図７（ｂ）を参照すると、サブオ
ブジェクト識別子５１８は、普通は、より細かいオブジ
ェクトを管理するため、普通は目標オブジェクトによっ
てのみ用いられるデータ要素である。たとえ話をする
と、スプレッドシートがひとつのオブジェクトであると
すると、スプレッドシートのセルがサブオブジェクトで
ある。オブジェクトの細かさ（granularity）、サブオ
ブジェクト、およびサブオブジェクトを管理する方法と
装置については、本出願人の別出願である「弁理士書類
番号：P/717/SUN1P023、発明の名称：オブジェクトの集
合を管理するための方法および装置、発明者：Vanderbi
lt 他」に詳細に記載されている。不変オブジェクト５
１０にオプションとして含まれるもうひとつの要素は場
所（ロケーション）ヒント５２０である。場所ヒント５
２０は、目標オブジェクトの最後に知られた場所に関す
る詳細を与える、オプションとしてのデータ要素であ
る。場所ヒント５２０は、期限切れタイムスタンプも含
むことができる。説明のため、ターオブジェクトが前も
ってコールされると、目標オブジェクトのためのアドレ
シング情報は早めに検索される。この場所ヒント５２０
を用いて、分散オペレーティングシステムは、ロケータ
へのコールを回避することができる。もちろん、場所ヒ
ント５２０が期限切れであるか、あるいは存在しない場
合、いずれにしてもロケータに対して問い合わせをしな
ければならない。

【００６３】図７（ａ）と図７（ｂ）とに関して、以上
説明した本発明の実施例は、様々な種類のオブジェクト
レファレンスをひとつの分散オペレーティング環境フレ
ームワークへと全体的に統合する役割を果たす。上記の
ように、分散オブジェクト環境は、ふたつの基本的種類
のオブジェクトレファレンスを区別することができ、な
おかつ、それぞれの種類に与えられた利点を保持するこ
とができる。

【００６４】本発明が提供するデータ要素を用いれば、
更なる統合ができる。例えば、一時的オブジェクトレフ
ァレンスおよび不変オブジェクトレファレンスにおける
オブジェクトキーを用いて、第１の分散システムの第１
のプロトコルに従ってフォーマットされたオブジェクト
レファレンスを第２のプロトコルを用いて第２の分散シ
ステムへ転送することができる。このことは、第２のオ
ブジェクトレファレンスを第２のプロトコルに従ってフ
ォーマットし、これを第１のオブジェクトレファレンス
の可変長オブジェクトキーに格納することによって行う
ことができる。オブジェクトレファレンスを受信した時
点で、第２の分散システムは、オブジェクトキーをスト
リップアウト（strip out）し、第２の分散システム用
に適したフォーマットの目標オブジェクト用のオブジェ
クトレファレンスを発生させる。このようにして、一時
的オブジェクトレファレンスおよび不変オブジェクトレ
ファレンスはともに、同一の機構であるオブジェクトキ
ーによって、複数のプロトコルにわたって転送可能であ
る。

【００６５】本発明が提供する全体的に統合されたフレ
ームワークの更なる証拠は、不変オブジェクトレファレ
ンスデータ構造の場所のヒントを考慮して見いだすこと
ができる。明らかなように、場所ヒントの適切な実施例
は、アドレシング情報のセット、具体化番号、および期
日（expiration date）を含む。場所ヒントが利用可能
で、最新で、かつ有効である場合、不変オブジェクトレ
ファレンスは、その不変オブジェクトへ、一時的オブジ
ェクトレファレンスがその一時的オブジェクトへ指向す
るのと全く同じ機構によって、インディレクトする。こ
の組合わせは、二種類のオブジェクトレファレンスの統
合にとって有効であるのみならず、不変目標オブジェク
トのコールのための（システム資源活用に関して）新規
かつコスト効果のある方法（この方法は、ロケーターの
使用を介してでなく直接不変分散オブジェクトをコール
することである）のためのフレームワークを設定する。

【００６６】ここに開示した一時的および不変オブジェ
クトレファレンスの実施例は、本発明のデータ構造面を
実装するための、いくつかの好ましいフレームワークを
提供するが、その他にも多くの適切な実施例がある。例
えば、いくつかの実施例においては、不変オブジェクト
がその場所を移動すると、分散オペレーティングシステ
ムは個々のオブジェクトレファレンスをすべて更新する
ことができる。したがって、不変および一時的オブジェ
クトレファレンスはともに、図７（ｂ）の不変オブジェ
クトレファレンス５１０の実施例で説明したインディレ
クションではなく、直接的アドレシング情報を持つこと
ができる。更に例を挙げると、いくつかの実施例は、イ
ンディレクションのみに基づいて、直接的アドレシング
を完全に削除することができる。この場合、一時的オブ
ジェクトレファレンスは、不変オブジェクトレファレン
ス５１０に類似の形で現れるかも知れない。更に別の実
施例は、特別のネットワーク通信プロトコルによって要
求される特徴を、それらの特定のフレームワークのもと
におけるオペレーションを可能にするため、組み込むで
あろう。

【００６７】上記の考察から明らかなように、一時的お
よび不変オブジェクトと、一時的および不変オブジェク
トレファレンスとを含む、オブジェクトの上記構造を用
いる分散オペレーティングシステムは、従来技術を超え
る多くの利点を有する。これら利点は、本発明の方法面
を利用するクライアント-サーバー対話に関する以下の
考察の中で更に明らかになる。

【００６８】次に、図８を参照して、本発明の一実施例
によるクライアント-サーバー対話の実装方法６００を
説明する。クライアント-サーバー対話は、ステップ６
０２において、クライアントがサーバーオブジェクト
（目標オブジェクトとも呼ばれる）を発動すると開始す
る。クライアントは、クライアントプロセスまたはクラ
イアントオブジェクト等、適切なエンティティであれば
よい。次のステップ６０４において、クライアントはサ
ーバーオブジェクトに関するアドレシング情報を獲得す
る。例えば、獲得されたアドレシング情報は、一時的お
よび不変オブジェクトレファレンスに関する上記の考察
で述べたようなデータを含むことができる。このアドレ
シング情報は複数のアドレスを含むことができ、その中
からひとつの特定のアドレスを選択できると理解すべき
である。アドレス選択のひとつの基準は、クライアント
とサーバーとの間で最も速い転送モードを可能にすると
いうことである。アドレス選択のための一般に用いられ
るもうひとつの基準は、セキュリティである。また、こ
のアドレシング情報の獲得には、情報が様々なソースに
存在するという事実のため、様々なステップが含まれ
る。

【００６９】ステップ６０４において一旦アドレシング
情報が獲得されると、クライアントはステップ６０６に
おいて、アドレシング情報を評価して特定のアドレスを
選択する。ステップ６０６において、クライアントは、
クライアントとサーバーとの間の転送速度、ロードシェ
アリング（load sharing）、セキュリティ、および／ま
たはアドレシング情報の完全性への懸念等の目的を含む
様々な理論的根拠に基づいてひとつのアドレスを選択で
きる。ステップ６０６のサブステップの一実施例の詳細
を、図１０を参照して以下に詳細に説明する。

【００７０】引き続き、図８の方法６００において、ク
ライアントは、ステップ６０６で選択されたアドレスへ
リクエストをステップ６０８で送る。このアドレスがリ
モート（遠隔）アドレスである場合、ステップ６０８
は、選択されたアドレスを、方法およびアーギュメント
とともに、マーシャルし、遠隔目標オブジェクトとのネ
ットワーク接続を形成し、目標オブジェクトへリモート
コールを行うという、各ステップを含むことができる。
ここで用いる場合、データを「マーシャルする」とは、
ネットワーク転送の準備として、所定のネットワーク通
信プロトコルに従ってデータをフォーマットすることで
ある。ステップ６１０において、クライアントが応答を
期待するか否か判定し、期待する場合、プロセス制御は
ステップ６１２へ進み、そこでクライアントは目標オブ
ジェクトから応答を受信する。ステップ６０８と同様
に、目標オブジェクトが遠隔である場合、クライアント
は目標オブジェクトからの応答を「アンマーシャル」す
ることができる。すなわち、データは所定のネットワー
ク通信プロトコルからクライアントにとって意味のある
フォーマットへ翻訳される。応答を受信した後、あるい
は応答が期待できない場合、制御はステップ６１４へ進
み、そこで図８のクライアント-サーバー対話は完了す
る。

【００７１】次に、図９を参照して、本発明のひとつの
方法面によるステップ６０４を更に詳細に説明する。当
業者には理解できるように、図９の方法は一般的に、図
７（ａ）および図７（ｂ）のオブジェクトレファレンス
またはそれに類似のオブジェクトレファレンスを用いる
分散オブジェクトシステム用である。しかし、明らかに
なるであろうように、本発明の範囲は、オブジェクトレ
ファレンスの追加の実施例により適した、ステップ６０
４の他の実施例を含む。

【００７２】図９のフローチャートは、ステップ７０２
において、制御が図８のステップ６０４へ送られたとき
に開始する。図９の最初の実質的ステップ、すなわちス
テップ７０４は、オブジェクトの種類が一時的か否かを
判定する。図７（ａ）と図７（ｂ）に関して先に考察し
たように、オブジェクトの種類判定は、内部名の調査な
ど、様々な方法によって行うことができる。オブジェク
トの種類が一時的である場合、制御はステップ７０６へ
分岐し、そこでアドレシング情報は直接、オブジェクト
レファレンスから返される。このことは、図７（ａ）に
よる一時的オブジェクトレファレンスが、インディレク
ションと異なり、直接的アドレシング情報をもっている
ゆえ可能である。ステップ７０６において一旦アドレシ
ング情報が返されると、制御はステップ７０８へ進み、
そこでアドレシング情報獲得ステップ６０４は完了す
る。

【００７３】ステップ７０４の他の分岐を下へたどり、
オブジェクトの種類が一時的でない場合、制御はステッ
プ７１０へ進み、そこでオブジェクトの種類が不変であ
るか否か判定される。オブジェクトの種類が不変でない
場合（オブジェクトはナルまたは無効である）、制御は
ステップ７１２へ進み、そこでエラーメッセージが形成
され、ステップ６０４は完了する。明らかなように、オ
ブジェクトが一時的でも不変でもない場合（それはナル
または無効の何れかであるので）、リクエストを目標オ
ブジェクトへ送ることは適切でなく、したがって、エラ
ーメッセージが適切である。

【００７４】他方、ステップ７１０においてオブジェク
トの種類が不変であると判定された場合、次にステップ
７１４において、目標オブジェクトアドレシング情報が
内在するか否かを見るため、メモリーキャッシュ−１が
チェックされる。内在する場合、制御はステップ７２０
へ進み、そこでアドレシング情報はキャッシュ−１から
直接返され、次にステップ７０８へ進み、そこで（アド
レシング情報を獲得した）ステップ６０４は完了する。
キャッシュメモリは、図２で説明したローカルＲＡＭ３
８のような任意の適切なメモリでよい。アドレシング情
報をメモリーキャッシュ−１に格納して検索することに
より、この情報への直接かつ迅速なアクセスが可能にな
る。

【００７５】アドレシング情報がキャッシュ−１内に存
在しない場合、制御はステップ７１６へ進み、そこでク
ライアントはアドレシング情報を獲得する。普通、アド
レシング情報は、図７ａと５（ｂ）を参照して先に説明
したように、ロケーターサービスを用いるインディレク
ションによってステップ７１６において獲得される。図
１１を参照して、ステップ７１６の一実施例を更に詳細
に以下説明する。ステップ７１６においてアドレシング
情報が獲得された後、その情報はステップ７１８におい
てキャッシュ−１に格納され、このことによって、この
方法の効率が永続する。更に、キャッシュ−１において
利用可能なアドレシング情報を増やすための、もうひと
つの機構を、図１３を参照して以下に説明する。次に、
ステップ７２０において、アドレシング情報がキャッシ
ュ−１から返されて、制御はステップ７０８へ進み、そ
こでアドレシング情報獲得ステップ６０４が完了する。

【００７６】次に、図１０を参照して、図８のアドレス
選択ステップ６０６の一実施例を更に詳細に説明する。
この実施例は主として、クライアントとサーバーとの間
で最も速い転送モードを与えるアドレシング情報を選択
する役割を果たす。ここで説明する三つの異なる転送モ
ードは、（転送速度が下がる順に）ローカル、共有メモ
リ、およびリモート転送である。ローカル転送は、同じ
プロセス内で発生し、同じアドレススペース内でデータ
をコピーすることによって実行される。共有メモリ転送
（同一ホストとも呼ばれる）は、ホストオペレーティン
グシステムプロセス内通信手順（host operating syste
m inter-process communication procedures）を用いて
実行される。リモート転送は、ネットワーキング施設を
用いて実行される。これらの各々は、オペレーティング
システムやネットワーク通信プロトコル等の要因によっ
て異なる。ローカル、共有メモリ、およびリモート転送
の設計と実装は、当業者にはなじみである。

【００７７】図１０のフローチャートは、ステップ８０
２において制御が図８のステップ６０６へ進んだとき始
まる。次にステップ８０４において、目標オブジェクト
がクライアントプロセス内で走っているか否かを判定す
る。走っている場合、ステップ８０６において、クライ
アントとサーバーを接続するため、ローカルアドレスと
ローカル転送が選択される。他方、目標オブジェクトが
クライアントプロセス内で走っていない場合、ステップ
８１０において、サーバーオブジェクトが同じホスト上
でクライアントとして走っているか否か、また、共有メ
モリーアドレシング情報が利用可能か否かを判定する。
そうであれば、ステップ８１２において、クライアント
とサーバーを接続するため、共有メモリーアドレシング
と共有メモリ転送が選択される。そうでない場合、目標
オブジェクトがクライアントプロセスにもクライアント
ホストにも存在しなければ、ステップ８１４は、クライ
アントとサーバーを接続するため、リモートアドレスと
リモート転送を選択する。いずれにしても、アドレシン
グが選択された後、制御はステップ８０８へ進み、そこ
で図８のステップ６０６が完了する。

【００７８】次に、図１１を参照して、図９のステップ
７１６の一実施例を更に詳細に説明する。図１１の方法
は、ステップ９０２においてアドレシング獲得ステップ
７１６が制御を受けるとき始まる。次にステップ９０４
において、ＯＲＢデーモンプロセスに関する一時的オブ
ジェクトレファレンスがロケータ id とホスト名を用い
て得られる。一実施例において、ＯＲＢデーモンプロセ
スは、分散オブジェクト環境の各コンピュータシステム
上に存在する。特にステップ９０４で見られるＯＲＢデ
ーモンは、サーバーホストコンピュータ上の背景を走る
プロセスであり、そのもとでロケーターオブジェクトが
活動している（active）。デーモンプロセスは当業者に
は周知である。次にステップ９０６において、クライア
ントはルックアップ手法を発動するためにロケーターオ
ブジェクトをコールし、目標オブジェクト用のオブジェ
クトキーを含むアーギュメントを転送する。ＯＲＢデー
モンは、応答として目標オブジェクト用の直接的アドレ
シング情報を返す。好ましい実施例においては、デーモ
ンプロセスは追加的にサーバープロセスの状態を確認
し、必要ならばプロセスを起動する。サーバープロセス
起動に関する好ましい一実施例は、本出願人の別出願で
ある、「弁理士書類番号：P747/SUN1P030、発明の名
称：コンピュータプロセスの管理方法と装置、発明者：
Vanderbilt 他」に見られる。直接的アドレシング情報
を受信した後、制御はステップ９０８へ進み、そこで図
９のステップ７１６は完了する。

【００７９】次に、図１２を参照して、図１１のステッ
プ９０４の一実施例を更に詳細に説明する。図１２の方
法は、ステップ１００２において、ＯＲＢデーモンに関
して一時的オブジェクトレファレンス獲得ステップ９０
４が制御を受けると始まる。ステップ１００４におい
て、ＯＲＢデーモンに関する一時的オブジェクトレファ
レンスがメモリーキャッシュ−２内に存在するか否かを
判定する。存在する場合、制御はステップ１０１２へ分
岐し、そこでＯＲＢデーモンに関する一時的オブジェク
トレファレンスがキャッシュ−２から直接返される。一
時的オブジェクトレファレンスが返された後、制御はス
テップ１０１４へ進み、そこで図１１のステップ９０４
は完了する。

【００８０】ＯＲＢデーモンに関する一時的オブジェク
トレファレンスがキャッシュ−２内に存在しない場合、
制御はステップ１００６へ分岐し、そこでクライアント
はサーバーホスト上のリモート手順コール（remote pro
cedure call = ＲＰＣ）バインダをコールし、ロケータ
id と具体化番号をアーギュメントとしてコールへ転送
する。応答として、ＲＰＣバインダはアドレシング情報
を返し、ステップ１００８においてクライアントは返さ
れたＯＲＢデーモンアドレシング情報を利用して一時的
オブジェクトレファレンスを作成する。ＲＰＣバインダ
の実装と構造は当業者には周知である。一旦一時的オブ
ジェクトレファレンスが作成されると、クライアント
は、それをステップ１０１０においてキャッシュ−２に
格納し、それによってこの方法の効率を永続させる。次
に制御はステップ１０１２へ進み、そこでＯＲＢデーモ
ンに関する一時的オブジェクトレファレンスがキャッシ
ュ−２から直接返される。一時的オブジェクトレファレ
ンスが返された後、制御はステップ１０１４へ進み、そ
こで図１１のステップ９０４は完了する。

【００８１】キャッシュ−１において利用可能なアドレ
シング情報を増やすための、ひとつの方法を、図１３を
参照して以下に説明する。背景として、不変オブジェク
トに関するのオブジェクトレファレンスは、（図７
（ｂ）等を参照して説明したように）オプションとして
の場所ヒントを含むことができる。場所ヒントは、目標
オブジェクトに関する直接的アドレシング情報を含む。
各場所ヒントは、キャッシュ−１内を探す、図９のアド
レス情報ステップ７１４を有する。更に、当業者には理
解されるように、オブジェクトレファレンスは、オブジ
ェクトコールを介して、あるいはオブジェクトコールへ
応答して、ホストコンピュータによって受信され得る。
したがって、オブジェクトレファレンスが受信されるた
びにアドレシング情報を増やす可能性がある。

【００８２】図１３の方法において、第１のステップ１
１００は、前のパラグラフで述べた二つの理由のような
何らかの理由で受信したオブジェクトレファレンスをア
ンマーシャルする。次にステップ１１０２において、オ
ブジェクトレファレンスが場所ヒントを持っているか否
かを判定する。持っている場合、ステップ１１０４にお
いて、アドレシング情報とロケーションヒントからの期
日（もしあれば）がキャッシュ−１に格納される。場所
ヒントがない場合、あるいはキャッシュ−１の更新後、
図１３の方法はステップ１１０６において行われ、オブ
ジェクトレファレンスは当初意図された目的のために使
用可能である。

【００８３】本発明の、図１３の方法に密接に関連し
た、もうひとつの方法面において、分散オブジェクトオ
ペレーティング環境の別々のコンピュータは、アドレシ
ング情報を共有するために共働する（work togethe
r）。したがって、いずれかのコンピュータが目標オブ
ジェクトに関するアドレシング情報を得るためにロケー
ターサービスを用いるとき、このコンピュータは他方で
はこの情報を、分散オブジェクトオペレーティング環境
内の他の複数のコンピュータへ分配することができる。
この情報を転送するための適当な方法のひとつは、オブ
ジェクトレファレンスによる方法であろう。次に各コン
ピュータはこのアドレシング情報を期日とともにキャッ
シュ−１メモリに格納する。

【００８４】次に、本発明の更にひとつの利点を考察す
る。当業者には理解できるように、ひとつのモデル（こ
の考察に好都合）は、ＯＲＢをここで、アプリケーショ
ンレベルＯＲＢ、転送レベルＯＲＢ、および通信レベル
ＯＲＢ、と定義する三つの異なる抽象的レベルに分け
る。低い通信レベルＯＲＢを表すコンポーネントとして
は、図１０に関連して考察した、共有、ローカル、およ
びリモートの、アドレシングおよび転送の活動を含む。
高いアプリケーションレベルＯＲＢを表すコンポーネン
トとしては、サーバーへの初期クライアントコールがあ
り、ここではサーバーの場所とオブジェクト種類はクラ
イアントに対して不透明である。中間レベルである転送
レベルＯＲＢは、サーバーオブジェクトの種類に係わる
必要のあるＯＲＢのごく一部である。したがって、本発
明は、分散オブジェクト環境内において一時的および不
変オブジェクトを統合するタスクを、ＯＲＢ全体を通じ
て不当な負荷を導入することなく達成し、それによって
分散オブジェクト環境の効率を確保する。

【００８５】本発明のほんの数実施例のみを説明した
が、本発明はその精神または範囲から逸脱することな
く、他の多くの形態において実施可能であることを理解
すべきである。図３と図４を参照して説明したクライア
ント−サーバーモデルは、単なる見本であって、決して
限定するものと解釈してはならない。例えば、「ホスト
からホストへ」モデルは、複数の目標オブジェクトを含
むように外挿（拡張）が可能である。すなわち、第１の
目標オブジェクト３０４は、多分他の分散オブジェクト
環境内の他の目標オブジェクトへインディレクトするオ
ブジェクトレファレンスに過ぎないであろう。あるい
は、この第１の目標オブジェクトは、リクエストされた
サービスの一部分を実行し、第１のクライアント３０２
に応答する前に、自分のコールを第２の目標オブジェク
トに対して行う。理解できるように、可能なものを列挙
すると多くの実施例があり、それらはすべて本発明の範
囲内に入る。

【００８６】更に、図７（ａ）と図７（ｂ）のデータ構
造は、本発明の範囲内においてなお、大幅に変更するこ
とができる。第１の例としては、一時的および不変オブ
ジェクトレファレンスに関するデータ構造は、種類フィ
ールドなしで実施可能である。更に追加の例は、複数の
ネットワーク通信プロトコル、オペレーティングシステ
ム、およびアプリケーションプログラムを考慮すること
によって見いだすことができる。これらの各々には、説
明したデータ構造の特定の編成が必要となるだろう。こ
れら数多くの実施例のそれぞれの構成と実装は当業者に
は自明であり、したがって本発明の範囲内に入る。

【００８７】分散オブジェクトシステムの技術に精通し
た者には理解できるように、一時的および不変オブジェ
クトを処理する上記方法の基礎をなすアイデアは、広範
囲の代替実施例として実施することができ、詳細に考察
するには余りにも数が多い。しかし、基礎となる考え方
は説明したので、様々な変形は当業者には明らかであろ
う。例えば、図１０に関連して説明した一実施例である
転送モードの選択方法は、多くの変形を持つことができ
る。選択基準は負荷分担欲求（load sharing desire）
を強調することができるので、この基準のもとでは、リ
モートアドレスが最良のアドレスであろう。他の面から
は、説明しなかった他の転送形式もあり得る。しかし、
他の転送形式が利用可能であれば、この技術に精通した
者は、他の転送形式を利用するために本発明の教示をど
のように適用するか理解するであろう。

【００８８】したがって、これらの例は説明的なもので
あって制限的なものではなく、本発明はここに示した例
に限定されない。

【図面の簡単な説明】

【図１】相互接続された様々なコンピュータを備えるコ
ンピュータネットワークの構成図である。

【図２】図１の１台のコンピュータの構成図である。

【図３】分散オブジェクトオペレーティング環境におけ
る、クライアントホストコンピュータ上で走るクライア
ントと、別のサーバーホストコンピュータ上で走るサー
バーオブジェクトとの間の関連性を示す、ホストからホ
ストへのクライアント-サーバーモデルの説明図であ
る。

【図４】クライアント／サーバーホストコンピュータ上
の別々のプロセス内で走るクライアントとサーバーとの
間の関連性を示す、プロセスからプロセスへのクライア
ント-サーバーモデルの説明図である。

【図５】単一のクライアント／サーバープロセス内で走
るクライアントとサーバーとの間の関連性を示す説明図
である。

【図６】（ａ）は、三つの異なるオブジェクト状態を経
過する不変オブジェクトの説明図であって、各状態は本
発明の第１の面による一時的状態および不変状態を含
む。（ｂ）は、本発明の第２の実施例による三つの異な
る状態を経過する一時的オブジェクトの説明図であっ
て、各状態は本発明の第２の面による一時的状態を含
む。

【図７】（ａ）は、一時的オブジェクトに関するオブジ
ェクトレファレンスの説明図であって、オブジェクトレ
ファレンスは、本発明の第２の実施例による種類フィー
ルド、オブジェクトキー、１セットのエンドポイントア
ドレス、および具体化番号を含む。（ｂ）は、不変オブ
ジェクトに関するオブジェクトレファレンスの説明図で
あって、オブジェクトレファレンスは、本発明の第１の
実施例による種類フィールド、ホスト名、ロケーターア
イデンティフィケーション、オブジェクトキー、サブオ
ブジェクト識別子、および場所ヒントを含む。

【図８】本発明のひとつの方法面に従って、分散サーバ
ーオブジェクトを発動するため、クライアントによって
実行されるプロセスを示すフローチャートである。

【図９】図８のステップ６０４を更に詳細に説明するフ
ローチャートである。

【図１０】図８のステップ６０６を更に詳細に説明する
フローチャートである。

【図１１】図９のステップ７１６を更に詳細に説明する
フローチャートである。

【図１２】図１１のステップ９０４を更に詳細に説明す
るフローチャートである。

【図１３】キャッシュメモリ内で利用可能なアドレシン
グ情報を増やすことによって本発明の利点を永続させる
プロセスの説明図である。

【符号の説明】

１０…ネットワーク、１２，１６，１８，２０，２２…
コンピュータ、１４…ネットワーク接続、３０…コンピ
ュータ、３２…中央処理装置（ＣＰＵ）、３４…ＲＡ
Ｍ、３６…ＲＯＭ、３８…大容量記憶装置、４０…入出
力源。

フロントページの続き (72)発明者 パヴァーニ ディワンジ アメリカ合衆国， カリフォルニア州 94305， スタンフォード， エスコンデ イド ビレッジ 29シー

Claims (52)

【特許請求の範囲】
1. 【請求項１】 複数の分散された一時的オブジェクトを
   想定する分散オブジェクトオペレーティング環境におい
   て、サーバーコンピュータシステム上に実装されるサー
   バーコンピュータプロセス内に存在する一時的オブジェ
   クトに関するオブジェクトレファレンスとして用いるオ
   ブジェクトであって、 前記サーバーコンピュータシステムに対応するエンドポ
   イントアドレスのセットと、 前記サーバーコンピュータプロセスに対応する具体化番
   号と、 前記一時的サーバーオブジェクトに対応するオブジェク
   トキーと、 を備え、前記エンドポイントアドレスのセットと、前記
   具体化番号と、前記オブジェクトキーとが、前記一時的
   サーバーオブジェクトを一義的に識別するデータ構造を
   有するオブジェクト。
2. 【請求項２】 前記データ構造は、前記一時的オブジェ
   クトの種類が一時的であることを示す種類フィールドを
   更に備える、請求項１記載のオブジェクト。
3. 【請求項３】 前記エンドポイントアドレスのセット
   は、可変長のデータ要素である、請求項１記載のオブジ
   ェクト。
4. 【請求項４】 前記エンドポイントアドレスのセット
   は、固定長のデータ要素である、請求項１記載のオブジ
   ェクト。
5. 【請求項５】 前記エンドポイントアドレスのセットの
   アドレスの１つは、２４ないし１２８バイト長のデータ
   要素である、請求項４記載のオブジェクト。
6. 【請求項６】 前記１つのアドレスの４バイトは、サー
   バーコンピュータシステムネットワークアドレスであ
   り、前記１つのアドレスの２バイトは、サーバーコンピ
   ュータプロセスネットワークポート番号である、請求項
   ５記載のオブジェクト。
7. 【請求項７】 前記エンドポイントアドレスのセット
   は、サーバーコンピュータシステムネットワークアドレ
   スとサーバーコンピュータプロセスネットワークポート
   番号とを含む、請求項１記載のオブジェクト。
8. 【請求項８】 前記分散オブジェクトオペレーティング
   環境は、クライアントコンピュータシステム上で実行さ
   れるクライアントコンピュータプロセス内に存在するク
   ライアントを備え、前記エンドポイントアドレスのセッ
   トと前記具体化番号とが、前記サーバーコンピュータプ
   ロセスが前記クライアントコンピュータプロセスである
   ことを示す、請求項１記載のオブジェクト。
9. 【請求項９】 前記分散オブジェクトオペレーティング
   環境は、クライアントコンピュータシステム上で実行さ
   れるクライアントコンピュータプロセス内に存在するク
   ライアントを備え、前記エンドポイントアドレスのセッ
   トと前記具体化番号とが、前記サーバーコンピュータシ
   ステムが前記クライアントコンピュータシステムである
   ことを示す、請求項１記載のオブジェクト。
10. 【請求項１０】 前記具体化番号は、可変長のデータ要
    素である、請求項１記載のオブジェクト。
11. 【請求項１１】 前記具体化番号は、固定長のデータ要
    素である、請求項１０記載のオブジェクト。
12. 【請求項１２】 前記具体化番号は、１ないし１６バイ
    ト長のデータ要素である、請求項１１記載のオブジェク
    ト。
13. 【請求項１３】 前記具体化番号は、前記サーバーコン
    ピュータプロセスの形成時刻を示す番号である、請求項
    １記載のオブジェクト。
14. 【請求項１４】 前記具体化番号は、サーバーコンピュ
    ータプロセスにとって予め定義された意味を有する、予
    め定義された番号である、請求項１記載のオブジェク
    ト。
15. 【請求項１５】 前記オブジェクトキーは、前記アドレ
    シング情報のセットおよび前記具体化番号とともに、前
    記一時的サーバーオブジェクトを一義的に定義する識別
    子である、請求項１記載のオブジェクト。
16. 【請求項１６】 前記オブジェクトキーは、前記サーバ
    ーコンピュータプロセス内において一義的な識別番号で
    ある、請求項１５記載のオブジェクト。
17. 【請求項１７】 前記分散オブジェクトオペレーティン
    グ環境が、第１の分散オブジェクトオペレーティング環
    境であって、前記オブジェクトキーは、第２の分散オブ
    ジェクトオペレーティング環境の一時的オブジェクトに
    関する第２のオブジェクトレファレンスとして用いる第
    ２のオブジェクトを備える、請求項１記載のオブジェク
    ト。
18. 【請求項１８】 前記オブジェクトキーは、前記第１の
    分散オブジェクトオペレーティング環境内のクライアン
    トが、前記第２の分散オブジェクトオペレーティング環
    境の前記一時的オブジェクトをコールすることを可能に
    する、請求項１７記載のオブジェクト。
19. 【請求項１９】 前記サーバーコンピュータシステム上
    の一時的メモリに格納されている、関連した一時的状態
    を有する、請求項１記載のオブジェクトレファレンスに
    対応する、一時的サーバーオブジェクト。
20. 【請求項２０】 前記サーバーコンピュータプロセスが
    終了すると、前記一時的サーバーオブジェクトが存在し
    なくなるように、前記サーバーコンピュータプロセスに
    直接結び付けられている、請求項１９記載の一時的サー
    バーオブジェクト。
21. 【請求項２１】 複数のコンピュータシステムと、 前記複数のコンピュータシステムを相互接続するコンピ
    ュータネットワークと、 前記複数のコンピュータシステムのひとつに存在する少
    なくともひとつの請求項１記載の前記オブジェクトと、 を備える分散オブジェクトオペレーティング環境。
22. 【請求項２２】 ロケータ−サービスが存在するコンピ
    ュータシステムに対応するコンピュータシステム名と、 前記ロケータサービスが存在するデーモンコンピュータ
    プロセスに対応するロケータ同定事項と、 前記不変オブジェクトに対応するオブジェクトキーと、 サブオブジェクト識別子と、 を含むデータ構造を備える第２のオブジェクトであっ
    て、第２のサーバーコンピュータシステム上で実行する
    第２のサーバープロセス内に存在する不変オブジェクト
    のために、オブジェクトレファレンスとして用いる第２
    のオブジェクトを更に備える、請求項２１記載の分散オ
    ブジェクトオペレーティング環境。
23. 【請求項２３】 前記第２のオブジェクトの前記データ
    構造は、前記オブジェクトの種類が不変であることを示
    す種類フィールドを更に備える、請求項２２記載の分散
    オブジェクトオペレーティング環境。
24. 【請求項２４】 前記第２のオブジェクトの前記データ
    構造は、場所ヒントを更に備える、請求項２２記載の分
    散オブジェクトオペレーティング環境。
25. 【請求項２５】 前記場所ヒントは、 前記不変サーバーオブジェクトが存在する前記第２のサ
    ーバーコンピュータシステムに対応するエンドポイント
    アドレスのセットと、 前記第２のサーバーコンピュータプロセスに対応する具
    体化番号とを備え、前記エンドポイントアドレスのセッ
    トと、前記具体化番号と、前記オブジェクトキーとが、
    前記不変サーバーオブジェクトを一義的に識別して場所
    を見いだす、請求項２３記載の分散オブジェクトオペレ
    ーティング環境。
26. 【請求項２６】 ナルオブジェクトに関するオブジェク
    トレファレンスとして用いる第３のオブジェクト種類
    と、 無効オブジェクトに関するオブジェクトレファレンスと
    して用いるための第４のオブジェクト種類とを更に備え
    る請求項２２記載の分散オブジェクトオペレーティング
    環境。
27. 【請求項２７】 複数の分散された一時的オブジェクト
    を想定する分散オブジェクトオペレーティング環境にお
    いて、サーバーコンピュータシステム上に実装されるサ
    ーバーコンピュータプロセス内に存在する不変オブジェ
    クトに関するオブジェクトレファレンスとして用いるオ
    ブジェクトであって、 ロケータ−サービスが存在するコンピュータシステムに
    対応するコンピュータシステム名と、 前記ロケータ−サービスが存在しているデーモンコンピ
    ュータプロセスに対応するロケータ同定事項と、 前記不変オブジェクトに対応するオブジェクトキーと、 サブオブジェクト識別子と、 場所ヒントとを備えるデータ構造を有するオブジェク
    ト。
28. 【請求項２８】 前記場所ヒントは、 前記サーバーコンピュータシステムに対応するエンドポ
    イントアドレスのセットと、 前記サーバーコンピュータプロセスに対応する具体化番
    号とを備え、前記エンドポイントアドレスのセットと、
    前記具体化番号と、前記オブジェクトキーとが、前記不
    変オブジェクトを一義的に識別して場所を見いだす、請
    求項２７記載のオブジェクト。
29. 【請求項２９】 ロケータ−サービスが存在している前
    記コンピュータシステムは、前記サーバーコンピュータ
    システムである、請求項２８記載のオブジェクト。
30. 【請求項３０】 前記オブジェクトの前記データ構造
    は、前記不変オブジェクトの種類が不変であることを示
    す種類フィールドを更に含む、請求項２７記載のオブジ
    ェクト。
31. 【請求項３１】 複数のコンピュータシステムと、 前記複数のコンピュータシステムを相互接続するコンピ
    ュータネットワークと、 前記複数のコンピュータシステムのひとつに存在する少
    なくともひとつの、請求項２７記載のオブジェクトとを
    備える分散オブジェクトオペレーティング環境。
32. 【請求項３２】 前記サーバーコンピュータシステム上
    の不変メモリ内に格納されるとともに、対応する不変状
    態を有する、請求項２７記載のオブジェクトレファレン
    スに対応する不変サーバーオブジェクト。
33. 【請求項３３】 前記サーバーコンピュータプロセスが
    終了しても、その状態を維持して、作用可能である、請
    求項３２記載の不変サーバーオブジェクト。
34. 【請求項３４】 分散オブジェクトオペレーティング環
    境において用いるためのコンピュータシステム上のキャ
    ッシュメモリ内に分散オブジェクトアドレシング情報を
    維持するためのコンピュータに実装される方法であっ
    て、 コンピュータ制御のもとで、分散オブジェクトに対応す
    るオブジェクトレファレンスを受信するステップと、 コンピュータ制御のもとで、前記オブジェクトレファレ
    ンスが、前記分散オブジェクトに対応するアドレシング
    情報を含むか否かを判定し、含む場合に、コンピュータ
    制御のもとで、前記アドレシング情報を前記キャッシュ
    に書き込むステップと、 を備える方法。
35. 【請求項３５】 前記オブジェクトレファレンス受信ス
    テップは、コンピュータ制御のもとで、前記オブジェク
    トレファレンスをアンマーシャルするステップを更に備
    える、請求項３４記載の方法。
36. 【請求項３６】 前記オブジェクトレファレンス受信ス
    テップは、目標オブジェクトコールの一部である、請求
    項３５記載の方法。
37. 【請求項３７】 前記オブジェクトレファレンス受信ス
    テップは、目標オブジェクトコールへの応答の一部であ
    る、請求項３５記載の方法。
38. 【請求項３８】 前記アドレシング情報書き込みステッ
    プは、コンピュータ制御のもとで前記アドレシング情報
    に関する失効日を前記キャッシュに書き込むステップを
    備える、請求項３４記載の方法。
39. 【請求項３９】 クライアントコンピュータシステム上
    で実行されるクライアントプロセス内に存在する対応オ
    ブジェクトレファレンスを有し、サーバーコンピュータ
    システム上で実行されるサーバープロセス上に存在す
    る、分散されたサーバーオブジェクトをコールするた
    め、コンピュータに実装される方法であって、 コンピュータ制御のもとで、前記分散されたサーバーオ
    ブジェクトに関するアドレシング情報を獲得するステッ
    プと、 コンピュータ制御のもとで、前記分散されたサーバーオ
    ブジェクトに関する１つのアドレスを選択するステップ
    と、 コンピュータ制御のもとで、前記分散されたサーバーオ
    ブジェクトへリクエストを送るステップとを備えるコン
    ピュータに実装される方法。
40. 【請求項４０】 コンピュータ制御のもとで、前記分散
    されたサーバーオブジェクトから応答を受けるステップ
    を更に備える、請求項３９記載の方法。
41. 【請求項４１】 コンピュータ制御のもとで、前記アド
    レシング情報獲得ステップが、前記分散されたサーバー
    オブジェクトの、一時的および不変の種類を判定するサ
    ブステップを備える、請求項３９記載の方法。
42. 【請求項４２】 前記種類がナルと無効とを更に含むと
    ともに、コンピュータ制御のもとで、前記分散されたサ
    ーバーオブジェクトの種類がナルまたは無効である場合
    に、前記アドレシング情報獲得ステップがエラーメッセ
    ージを返すサブステップを更に備える、請求項４１記載
    の方法。
43. 【請求項４３】 前記アドレシング情報獲得ステップ
    が、前記分散されたサーバーオブジェクトの種類が一時
    的である場合に、コンピュータ制御のもとで、前記アド
    レス情報を前記オブジェクトレファレンスから直接返す
    サブステップを更に備える、請求項４１記載の方法。
44. 【請求項４４】 前記アドレシング情報獲得ステップ
    は、 前記アドレス情報がクライアントコンピュータシステム
    上にあるキャッシュメモリに格納されているか否かをコ
    ンピュータ制御のもとで判定するサブステップと、 前記分散されたサーバーオブジェクトの種類が不変であ
    る場合に、コンピュータ制御のもとで前記アドレス情報
    を前記キャッシュメモリから返すサブステップとを更に
    備える請求項４１記載の方法。
45. 【請求項４５】 前記アドレシング情報が当初前記キャ
    ッシュメモリに格納されていないと判定された結果に応
    じて、前記アドレシング情報獲得ステップは、 コンピュータ制御のもとで、前記アドレシング情報を前
    記分散オブジェクトオペレーティング環境内から獲得す
    る中間サブステップと、 コンピュータ制御のもとで、前記アドレシング情報を前
    記キャッシュメモリに格納する中間サブステップとを更
    に備える請求項４４記載の方法。
46. 【請求項４６】 前記オブジェクトレファレンスが、ロ
    ケータ同定事項、ホスト名、およびオブジェクトキーを
    含み、前記アドレシング情報獲得ステップは、 コンピュータ制御のもとで、サーバーコンピュータシス
    テム上を走るデーモンプロセスとコンピュータ通信を形
    成するサブステップと、 コンピュータ制御のもとで、前記デーモンプロセスへル
    ックアップオペレーションを発行し、前記オブジェクト
    キーを前記デーモンへ転送するサブステップとを備える
    請求項４５記載の方法。
47. 【請求項４７】 デーモンプロセスとの前記コンピュー
    タ通信形成ステップは、前記デーモンに関する一時的オ
    ブジェクトレファレンスが、前記クライアントコンピュ
    ータシステム上に見いだされるキャッシュメモリに格納
    されているか否かをコンピュータ制御のもとで判定する
    ステップを含み、格納されている場合、前記通信形成ス
    テップが、コンピュータ制御のもとで、前記一時的オブ
    ジェクトレファレンスを前記キャッシュメモリから返す
    ステップを更に備える、請求項４６記載の方法。
48. 【請求項４８】 前記一時的オブジェクトレファレンス
    がキャッシュメモリに格納されていないと判定された結
    果に応じて、デーモンプロセスとの前記通信形成ステッ
    プは、 コンピュータ制御のもとで、前記ロケータ同定事項を、
    所定の具体化番号とともに転送するステップを含む、前
    記ホスト名を用いてサーバーコンピュータシステム上の
    リモート手順コールバインダーをコールする中間ステッ
    プを含み、 コンピュータ制御のもとで、前記リモート手順コールバ
    インダからのアドレスを受信する中間ステップと、 コンピュータ制御のもとで、前記デーモンに関する一時
    的オブジェクトレファレンスを、前記アドレスと前記所
    定の具体化番号とから構成する中間ステップと、 コンピュータ制御のもとで、前記一時的オブジェクトレ
    ファレンスを前記キャッシュメモリに格納するステップ
    とを更に備える請求項４７記載の方法。
49. 【請求項４９】 前記アドレス選択ステップは、コンピ
    ュータ制御のもとで、前記サーバープロセスと前記クラ
    イアントプロセスが同一のプロセスであるか否かを判定
    するステップを備える、請求項３９記載の方法。
50. 【請求項５０】 前記サーバープロセスと前記クライア
    ントプロセスが同一のプロセスである場合、コンピュー
    タ制御のもとで、ローカルアドレスとローカル転送を選
    択するステップを更に備える、請求項４９記載の方法。
51. 【請求項５１】 前記サーバープロセスと前記クライア
    ントプロセスが同一のプロセスでないと判定された場合
    に応じて、 コンピュータ制御のもとで、前記サーバーコンピュータ
    システムが前記クライアントコンピュータシステムと同
    じであるか否かを判定するステップと、 前記サーバーコンピュータシステムが前記クライアント
    コンピュータシステムと同じである場合、コンピュータ
    制御のもとで、共有メモリアドレスと共有メモリ転送を
    選択するステップと、 前記サーバーコンピュータシステムが前記クライアント
    コンピュータシステムと同じでない場合、コンピュータ
    制御のもとで、リモートアドレスとリモート転送を選択
    するステップとを更に備える請求項４９記載の方法。
52. 【請求項５２】 分散オブジェクトオペレーティング環
    境において用いる各対応コンピュータシステム上に存在
    する複数の各キャッシュ内の分散オブジェクトに関する
    アドレシング情報を維持するコンピュータに実装される
    方法であって、 コンピュータ制御のもとで、前記複数のキャッシュ内の
    利用可能な分散オブジェクトに関するすべてのアドレシ
    ング情報を、少なくとも１つのコンピュータシステムへ
    複数のオブジェクトレファレンスの形式で分散するステ
    ップと、 前記少なくとも１つのコンピュータシステムが、分散さ
    れた複数のオブジェクトレファレンスに関して請求項３
    ４のコンピュータに実装された方法を実行するステップ
    とを備える方法。