JPH10133877A - マーシャリングフレームワークを使用して分散オブジェクトネットワーク上に不変オブジェクトを格納するためのメソッドと装置 - Google Patents

Abstract

(57)【要約】 【課題】分散クライアント／サーバー・コンピューティ
ングシステムにおいて不変オブジェクトが効率的に作成
され、かつアクセスされるように不変データ記憶を実装
するためのデータ構造、メソッド、および装置、を開示
する。 【解決手段】発明の一側面では、インストールされた不
変オブジェクト用の不変データを管理するためのメソッ
ドは、不変オブジェクト属性値をマーシャルバッファに
マーシャルして、コード化された不変オブジェクト属性
値を提供すること；不変オブジェクト属性値を更新し
て、更新された不変オブジェクト属性値を提供するこ
と；更新された不変オブジェクト属性値をマーシャルバ
ッファからアンマーシャルして、デコードされた更新済
不変オブジェクト属性値を提供すること；およびデコー
ドされた更新済不変オブジェクト属性値をデータストア
に書き込むこと；を含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する分野】本発明は分散オブジェクトコンピ
ューティングシステム、クライアント−サーバーコンピ
ューティング、およびオブジェクト指向プログラミング
の分野に関する。更に詳細には、本発明は分散オブジェ
クトシステムにおける不変(persistent)オブジェクトで
ある分散オブジェクト用のデータを格納するためのメソ
ッドと装置に関する。

【０００２】

【従来の技術】オブジェクト指向プログラミングメソッ
ド論は、従来のプログラミングメソッドを用いて開発さ
れたソフトウェアの納期遅れや予算超過の傾向の増大に
つれて、過去数年の間に益々注目されるようになった。
一般に、従来のメソッドを使って作成される大型プログ
ラムは「脆い」。従って、ユーザーの要求に応じたソフ
トウェアに対する小変更が、大きな設計変更や全プログ
ラムのリライティングを必要とする場合がある。オブジ
ェクト指向プログラミング戦略は、手順よりもデータの
取扱に重点を置いているのでこの問題を避ける傾向があ
り、従って現実世界の問題に対するより直観的アプロー
チをプログラムに提供する。更にオブジェクトは、関連
データと手順をカプセル化して、データと手順へのアク
セスをオブジェクトのインタフェースを介してのみ可能
にすることによって、その情報をプログラムの残部から
隠す。従って、オブジェクトのデータおよび／または手
順の変更は、プログラムの残部から比較的隔離されてい
る。

【０００３】

【発明が解決しようとする課題】オブジェクト指向メソ
ッド論の分野における最近の進歩は、コンピュータネッ
トワークを介して相互接続されたコンピュータに対する
分散オブジェクトオペレーティング環境の実装(impleme
ntation)であった。ここで使われる場合、用語の「分散
オブジェクト」または「オブジェクト」は、インタフェ
ースを介したオペレーションによって操作できるコード
とデータのカプセル化されたパッケージのことである。
従って、分散オブジェクトは、オブジェクト指向プログ
ラミング（ＯＯＰ）の当業者には、従来のプログラミン
グオブジェクトを定義する基本的特徴を含む点で従来の
プログラミングのオブジェクトとは異なる。まず第１
に、分散オブジェクトは多言語的である。すなわち、分
散オブジェクトのインタフェースは、様々なプログラミ
ング言語にマップ化できるインタフェース定義言語を使
って定義される。第２に分散オブジェクトは場所独立的
である、つまり分散オブジェクトはネットワークのどこ
にでも配置できる。これは、通常、単一アドレススペー
スに存在する従来のプログラミングオブジェクトとは明
らかに異なる。

【０００４】分散オブジェクトオペレーティング環境に
ついて更に詳述すると、分散オブジェクトは、他のオブ
ジェクトにリクエストを送っているか、クライアントか
らのリクエストに回答しているかによって、クライアン
トオブジェクトにもサーバーオブジェクトにもなれる。
クライアントが目標オブジェクトをコールするとき、リ
クエストされたサービスを目標オブジェクトが確実に実
行できるように、一定の手順を実行しなければならな
い。これらの手順は、目標オブジェクトを識別して場所
を特定すること、目標オブジェクトが存在するサーバー
プロセスを開始すること（必要な場合）、目標オブジェ
クトを活性化すること（必要な場合）、および最後に、
その目標オブジェクトとの接続を確立して、コールをパ
スすることを含む。オブジェクトリクエストブローカー
（ＯＲＢ）は、オブジェクトアダプタ（ＯＡ）と共に、
これらのサービスを実行するために、クライアントおよ
び目標オブジェクトと共働しなくてはならない。

【０００５】分散オブジェクトのライフサイクルの展望
から、オブジェクトは過渡または不変の２つのカテゴリ
ーの一つに分類される。オブジェクトの過渡と不変の性
質を検討する場合、言及されるのは、オブジェクトの状
態の過渡的性質や不変的性質である。オブジェクト指向
プログラミング（ＯＯＰ）の当業者には周知のように、
オブジェクトは２つのコンポーネント、すなわち実行可
能コードおよび状態によって記述される。実行可能コー
ドは、本質的に、それによってオブジェクトが動作する
命令であり、それはオブジェクトの「挙動(behavior)」
を定義する。状態は、オブジェクトの現行動作パラメー
タを定義するデータ等のコードではない、オブジェクト
の単なる残部である。

【０００６】過渡(transient)オブジェクトは、通常、
ライフスパンが短く、単一のホストコンピュータプロセ
スに拘束される。従って、プロセス間を移動する過渡オ
ブジェクトのアイデンティティ、つまり状態、の連続性
は存在しない。それと対照的に、不変オブジェクトは単
一プロセスに拘束されず、そのアドレスとメモリの場所
は時間と共に変化する（例えば多くの「ライフ」サイク
ルを持つ）。不変オブジェクトでは、プロセスからプロ
セスへのアイデンティティと状態の連続性が存在する。
簡単に言えば、不変オブジェクトは、オブジェクトの特
定インスタンスの寿命を超え得る状態を持つオブジェク
トである。よく理解されるように、不変オブジェクトは
オブジェクトディベロッパに対して多くの利点を提供す
る。

【０００７】不変オブジェクトを提供するための一つの
アプローチでは、オブジェクトに関する「不変」の質
が、既存のオブジェクトプログラミング言語に導入され
た。或るアプローチでは、既存のプログラム言語への拡
張が、不変オブジェクトの「不変的」質を構成する状態
データが書き込まれたデータベースの機能性に対するイ
ンタフェースを提供する。例えば、このメソッドを使用
した拡張言語用のコンパイラは、データベースと共に使
用するための特殊化されたコマンドのセットを受け入れ
るかもしれない。これらのメソッドと共に、使用される
最も一般的なタイプのデータベースはリレーショナル(r
elational)データベースである。しかしながら、リレー
ショナルデータベースは、オブジェクト状態が通常記載
されるフォーマットでデータを格納するように設計され
ていないので、これはそれ自体にジレンマを抱えてい
る。オブジェクト指向データベースは利用可能だが、オ
ブジェクト指向データベースによって作成されるオブジ
ェクトはＣＯＲＢＡオブジェクトではなく、従って、Ｃ
ＯＲＢＡの指針によって提供される機能性とサービスを
利用できない。更に、現行のメソッド論を使用した不変
オブジェクト用の不変データの検索は速度が遅く、従っ
てシステム性能を劣化させる。

【０００８】従来のインタフェース定義言語（ＩＤＬ）
インタフェースでは、不変データオブジェクトは、ＩＤ
Ｌのサブセット、つまりデータベース記述言語（ＤＤ
Ｌ）によって記述されるデータベース（通常、ディスク
上に常駐する）に格納される。不変オブジェクトが使用
される度毎にディスク上のデータベースから直接読み取
ったりそれに書き込むプロセスは非効率な傾向がある。
一般に、ディスク上に格納されるデータベースからの読
取りとそれへの書込のプロセスは速度が遅い。更に、通
常、不変記憶マネジャ、つまりデータベースマネジャ
が、プロセスに適した不変オブジェクトを発見するため
にデータベースの検索に使用される。データベースマネ
ジャの使用は、しばしば、速度が遅いことがわかってい
る。従って、不変オブジェクトが容易に作成されてプロ
セスが分散オブジェクトシステム上で動作する間の任意
の時点でアクセスできるように、不変データ記憶を実装
するメソッドと装置を実装することが、有利となるだろ
う。

【０００９】

【課題を解決するための手段】前記およびその他の目的
を達成すると共に本発明の目的に従って、分散クライア
ント／サーバー・コンピューティングシステムにおいて
不変オブジェクトが効率的に作成され、かつアクセスさ
れるように不変データ記憶を実装するためのメソッドと
装置が開示される。

【００１０】本発明の一側面では、インストールされた
不変オブジェクト用の不変データを管理するためのメソ
ッドは、不変オブジェクト属性値をマーシャルバッファ
にマーシャルすることによって、コード化された不変オ
ブジェクト属性値を提供すること、不変オブジェクト属
性値を更新することによって、更新された不変オブジェ
クト属性値を提供すること、更新された不変オブジェク
ト属性値をマーシャルバッファからアンマーシャルする
ことによって、デコードされた更新済不変オブジェクト
属性値を提供すること、およびデコードされた更新済不
変オブジェクト属性値をデータストアに書き込むことを
含む。

【００１１】本発明の別の側面では、デコードされた更
新済不変オブジェクト属性値をデータストアに書き込む
ためのメソッドは、データ構造内に格納された不変オブ
ジェクト属性のインデックスを抽出すること、データベ
ースの中の不変オブジェクト属性の場所を発見するこ
と、不変オブジェクト属性がインデックスの中で発見で
きない場合は不変オブジェクト属性をデータストアに加
えること、および不変オブジェクト属性に対応する場所
で不変オブジェクト属性値をデータストアに書き込むこ
とを含む。

【００１２】本発明の上記その他の特徴および利点は、
下記の発明の詳細な説明と関連図面の中で更に詳しく提
示される。

【００１３】本発明は、その更なる利点と共に、添付の
図面に関する下記説明を参照することによって最もよく
理解されるであろう。

【００１４】

【発明の実施の形態】

１． 分散オブジェクトシステムの背景 本発明を、添付図面に示された発明の実施例に関して詳
しく説明する。本発明の一実施例では、分散オブジェク
トとコンピュータプロセスは、ネットワークで相互に連
結された一つ以上のコンピュータ上に常駐している。ネ
ットワークは適切な任意の形を取ることができる。例と
して、代表的なネットワーク構成１１０を図１Ａに示
す。ネットワーク構成１１０は伝送ライン１１４に接続
された第１コンピュータ１１２を含む。ネットワーク構
成１１０は、更に、ネットワークコンピュータ間でデー
タと命令がパスされるように、他のコンピュータ１１
８、１２０、および１２２に加えて、サーバー、ルータ
ー等１１６を含む。コンピュータネットワークの設計、
構造、および実装は、当業者には周知であろう。

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

【００１６】本発明は、ＣＯＲＢＡによって定義された
もの、または他の任意の適切な仕様を含め、任意の適切
な分散オブジェクトシステムの関連において実行するこ
とができる。しかしながら、説明の目的に対しては、本
発明は、主として、１９９５年７月のオブジェクト管理
グループ（ＯＭＧ）からののＣＯＲＢＡ仕様、改訂版
２．０、に基づいて実装されたオブジェクトリクエスト
ブローカー（ＯＲＢ）の関連において説明される。

【００１７】図３は、本発明の実装に適した代表的な分
散オブジェクトシステムの全体的アーキテクチャを概略
説明する。分散オブジェクトシステム１０は、通常、オ
ブジェクトリクエストブローカー（ＯＲＢ）１１を含
む。ＯＲＢ１１は、クライアントからのコールをサーバ
ント（目標オブジェクト）に伝達してそのクライアント
に応答を返すのに必要な場所と輸送メカニズムと設備の
すべてを提供する。クライアントとサーバントは、同一
プロセス内、同一マシン上の異なるプロセス内、または
全く異なるマシン上に配置できる。この検討の目的に対
しては、クライアント２０は、分散オブジェクト上のオ
ペレーションを呼び出す任意のコードでよいので、分散
オブジェクトまたはプロセスの形を取ることもできる
し、取らなくてもよい。分散オブジェクトは様々な表示
が可能である。例として、オブジェクトはアプリケーシ
ョンディベロッパによって提供されたＣ＋＋でもよい。
そのほか、オブジェクトのための実装は、分散オブジェ
クトを生成するために有効な開発ツールを使用して開発
してもよい。

【００１８】クライアント２０は、スタブ２１、サブコ
ントラクト層３６、あるいはフィルタ４０、およびトラ
ンスポート層３８を介してサーバントと通信する。スタ
ブ２１はサロゲート２２、メソッドテーブル２４、およ
びスタブ関数２５を含む。クライアント２０は、最初、
クライアントにはサーバーオブジェクトに見えるサロゲ
ート２２と通信する。そのほかに、クライアント２０
は、サロゲート２２、メソッドテーブル２４、およびス
タブ関数２５の代わりに、動的呼出インタフェース（Ｄ
ＩＩ）を介してサーバーオブジェクトと直接に通信して
もよい。動的呼出インタフェース２６を使用して、クラ
イアントは動的リクエストを構築できる。クライアント
がコールを開始した後、コールはメソッドテーブルディ
スパッチメカニズム２４を使って処理される。このよう
な技術は米国特許出願第０８／３０７，９２９号で開示
されている。

【００１９】サブコントラクト層３６は、サブコントラ
クトを利用して特定のサブコントラクトによって指名(n
amed) された各種サービス（または特徴やオブジェクト
メカニズム）を実装するために、オブジェクトによって
要求された機能を提供するが、これについては１９９５
年１１月７日申請の米国特許出願第０８／５５４，７９
４号に更に詳しく記載されている。サブコントラクト
は、個々のオブジェクトによって利用される分散オブジ
ェクトシステムによって提供されるサービスの質を識別
する。例えば、サブコントラクトは、特定のオブジェク
トのために安全性の特徴が使用されることを識別するこ
とができる。

【００２０】フィルタ４０が使用される場合、それは圧
縮、暗号化、トレース、またはデバッグ等の、オブジェ
クトに出入りする通信に適用すべき様々なタスクを実行
することができる。トランスポート層３８は、通常はク
ライアントと同一プロセスを共有しないサーバントに出
入りする情報を、マーシャルし、アンマーシャルし、お
よび物理的に輸送するために動作する。

【００２１】標準実装スイート２８（またはオブジェク
トアダプタ）は、同一の方式でＯＲＢオブジェクト１４
とインタフェースする一組のサブコントラクト、例えば
オブジェクトキーマネージメントを表す。当然のことな
がら、サブコントラクトは多重実装スイートに属するこ
とができる。また、インプリメンテーションスイートは
異なるサブコントラクトを利用してもよい。スケルトン
は、静的スケルトン３２や動的スケルトン３０の形を取
り得るが、これは、サーバントオブジェクトによってリ
クエストされるフォーマットにリクエストを変換するた
めに使用される。かくして、スケルトン３、３２は適切
なサーバントオブジェクトをコールする。静的スケルト
ン３２はインタフェース固有のオブジェクトインプリメ
ンテーション１４をコールするために使用され、動的ス
ケルトン３０は、一般に、インタフェース固有のオブジ
ェクトが利用できないときに使用される。ＯＲＢインタ
フェース３４は、すべてのＯＲＢに対して同一なＯＲＢ
に直接進むインタフェースで、オブジェクトアダプタの
オブジェクトインタフェースに依存しない。

【００２２】ＯＲＢデーモン(daeman)４６は、オブジェ
クトサーバーがクライアントによって呼び出されたとき
にアクティブである旨保証しなければならない。オブジ
ェクトサーバーを始動する技術は米国特許出願第０８／
４０８，６４５号に開示されている。

【００２３】安全プロトコル４２は、インターネットイ
ンターＯＲＢプロトコルを保証して、トランスポート層
３８を介して確実に情報を伝達するのに役立つ安全イン
タオペラビリティプロトコルである。これは安全性保
護、機密性等を意味することができる。インターネット
インターＯＲＢプロトコルは、通常、異なるマシン上の
プロセス間で通信するプロトコルである。しかしなが
ら、場合によって、インターネットインターＯＲＢプロ
トコルは同一マシン上のプロセス間で通信することがで
きる。セキュリティサーバー５４は、異なるコンピュー
タ上のプロセス間で使用されるサービスを保証するセキ
ュリティアドミニストレーションサーバーである。

【００２４】タイプコード／Ａｎｙモジュール４４は
「タイプコード」と「Ａｎｙ」オブジェクトとを実装す
る。タイプコードはインタフェース定義言語（ＩＤＬ）
データタイプを記述し、クライアントとサーバー間のタ
イプ記述の伝達を可能にする。ＩＤＬデータタイプのイ
ンスタンスをＡｎｙオブジェクトによってカプセル化す
ることができる。Ａｎｙオブジェクトは、カプセル化さ
れたデータのタイプコードと、データの総称的コード化
を参照する。

【００２５】インプリメンテーションレポジトリ５０
は、オブジェクトサーバーに関する情報を格納するため
に使用される。具体的には、インプリメンテーションレ
ポジトリ５０は、サーバープロセスを開始するのに必要
な情報を格納する。例えば、インプリメンテーションレ
ポジトリ５０は、サーバープログラムの場所、プログラ
ムに対する任意の引数、およびプログラムに渡すべき任
意の環境変数等の情報を格納する。

【００２６】シンプルパーシステンス５６は、追加コー
ドの一部と共に、インタフェース定義言語（ＩＤＬ）定
義タイプと、ＩＤＬコンパイラを介してそのＩＤＬタイ
プを実行する出力形とを使用するので、ＩＤＬ定義タイ
プをディスクから読み取ったりディスクへ書き込むこと
ができる。ネーミングサービス５２は、ＯＲＢオブジェ
クトを指名(name)するために使用される。クライアント
はネーミングサービス５２を使って希望のオブジェクト
を名前で発見することができる。ネーミングサービス５
２はオブジェクトレファレンスを返し、次にそのレファ
レンスを使ってそのオブジェクトにリクエストを送るこ
とができる。インタフェースレポジトリ４８（ＩＦＲ）
は、分散オブジェクトシステム内のすべてのオブジェク
トに対するすべてのインタフェースについて知識を持
つ。

【００２７】２． 本発明による不変データ記憶メカニ
ズムの説明 分散オブジェクトのライフサイクルの展望から、オブジ
ェクトは過渡的または不変的品質を持つことができる。
オブジェクトの過渡的な性質や不変的な性質を検討する
場合、言及されるのは、オブジェクトの状態の過渡的性
質や不変的性質である。先に議論したように、状態は、
実行可能なコードではない、データ等の、単なるオブジ
ェクトの部分である。従って、本明細書で使用する場
合、用語の「不変性」および「不変データ」は、不変オ
ブジェクトの状態を定義するのに必要なデータのことを
指す。不変データは、不変オブジェクト属性値を有する
不変オブジェクト属性を備えている。

【００２８】不変データ自体は、本明細書で「不変デー
タ」と呼ぶオブジェクトを備えることができる。不変デ
ータオブジェクトは、データストア、つまりデータベー
スに格納されるが、適切なインタフェース定義言語、例
えば周知のインタフェース定義言語（ＩＤＬ）のサブセ
ットであるデータベース記述言語（ＤＤＬ）で記述でき
る。ここで使用する場合、「データストア」とは、不変
オブジェクトおよびそのオブジェクトに関連する属性に
関係する情報を含むデータベースである。更に具体的に
は、データストアは、それぞれが名前と値を持つ関連属
性を有する不変データおよび／または不変データオブジ
ェクトのリスト、つまりシーケンスを含む。これらのデ
ータストアは、通常、ＲＡＭ等の作業用メモリの記憶に
対して永久と見做されるディスクや類似の記憶装置に格
納される。現行メソッドを使用したデータストアからの
読取りとそれへの不変データの書込のプロセスは、しば
しば、非効率であることが分かっており、従ってシステ
ム性能を低下させる。

【００２９】或る側面では、本発明は、オブジェクト属
性が効率的に検索されて不変記憶メカニズム（すなわ
ち、データストア）に書込できるように、不変オブジェ
クトをマーシャル、すなわちカプセル化したフレームワ
ークを提供するので、ディスク等の永久記憶媒体上に格
納されたファイルに対する属性の読取りと書込に関連す
る性能ペナルティが削減される。上記のフレームワーク
の使用も、分散オブジェクトに対するオブジェクト不変
性能力の円滑な統合を提供する。例として、本発明によ
って提供されるフレームワークは、データタイプが過渡
分散オブジェクトに固有のものか不変分散オブジェクト
に固有のものかにかかわらず、すべてのＩＤＬデータタ
イプに対して同一マッピングの使用を可能にする。従っ
て、様々なオブジェクトを記述するための共通コードベ
ースを開発できるので、分散オブジェクトシステムの総
合性能が向上して、コードの再使用による信頼性が増加
する。

【００３０】図４は、本発明の一実施例による、オブジ
ェクトモデル化技術（ＯＭＴ）のクラス図表の概略表示
である。ＯＭＴクラス図表２００は不変オブジェクトの
サポートに使用される総合フレームワークメカニズムを
表す。背景として、クラスとは、それからオブジェクト
を作成できるテンプレートである。クラスは、そのクラ
スのすべてのインスタンスに共通の挙動と属性を規定す
る。既存のクラスから新クラスを定義するメカニズムは
「インヘリタンス(inheritance) 」である。「インヘリ
タンス」は、再使用性を促進するメカニズムとしてよく
知られている。クラスの「サブクラス」は、その親クラ
スのオペレーションを相続(inherit) する。オブジェク
ト思考プログラミングの当業者にはよく理解されるよう
に、クラスの新しいインスタンスが作成されると、その
インスタンス変数用のメモリが自動的に割り当てられ
る。

【００３１】図４は、不変オブジェクトの定義に使用さ
れる様々な関係データ構造２０２を示す。クラス２０２
は、クラス名２０４、関連属性２０６、および関連メソ
ッド２０８を含む。クラス間の無装飾の各ライン、例え
ばライン２２２は、接続された２つのデータ構造間の１
対１の関係を示す。ラインの一端の円２２０と他端の菱
形は、関係クラス間の多数対１の関係を示す。例とし
て、クラス「タイプ」２２１とＳＯＰ＿ＤＢ：：Ｒｏｏ
ｔ(Simple Persistent Object_Data Base::Root)クラス
２４０のインスタンスとの間の関係は、多数対１の関係
である。ライン上の三角形、例えば三角形２１２は、ク
ラス間の相続関係を示し、三角形の底辺に面するクラス
が三角形の頂点に面するクラスから相続する。或るメソ
ッド名の前に見られるドル記号（例えばＮＥＯ＿ＳＰＯ
＿ＤＢクラス２３８のメソッド「＄ｃｒｅａｔｅ」２１
４）は静的メソッドまたはクラスメソッド、すなわち実
行時に関連オブジェクト状態を持たないメソッドを示
す。ゼロに等しくセットされるように図示されたメソッ
ド、例えばｇｅｔ＿ｔｒａｎｓ＿ｓｔａｔｅメソッド２
１６は、含有(containing)クラスで定義されないが現行
状態から相続するクラスで定義される抽象メソッド(abs
tract method) である。抽象メソッドを含むクラスのイ
ンスタンスは、通常、存在しないが、抽象クラスから導
かれたクラスのインスタンスは抽象クラスのインスタン
スと見做されることを理解しなければならない。

【００３２】一実施例では、ＯＭＴクラス図表２００を
構成するクラスは３グループ、すなわち不変オブジェク
トと、不変性(persistence) ２２４を実装するためのメ
ソッドとを定義するクラス、不変データ記憶メカニズム
２２５を定義するクラス、および不変性から書込、検索
される、データストア２２６を定義するクラスを含む。
不変オブジェクトクラス２２４は、属性を備えた不変デ
ータを定義する不変クラス２５０を含む。不変クラス２
５０はメソッドテーブル（ｍテーブル）クラス２５２
（このクラスは、データストア２２６から不変データを
書込、検索するオペレーションを実行するためにクラス
２５０のインスタンス上で呼び出し得るメソッドを定義
する）に関係し、これについては本明細書で更に説明す
る。不変データ記憶メカニズム２２５は、ＮＥＯ＿ＳＰ
Ｏ＿ＤＢクラス２３８、ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿Ｄ
Ｂクラス２３９、ＮＥＯ＿ＳＰＯ＿Ｏｂｊｅｃｔクラス
２３２、ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿Ｏｂｊクラス２１
０、ＮＥＯ＿ＳＰＯＭａｎａｇｅｒクラス２４２、Ｒｅ
ａｌ＿ＳＰＯＭａｎａｇｅｒ２４３、ＮＥＯ＿ＳＰＯ＿
ＳＣＲｅｐクラス２２８、およびＮＥＯ＿ＲｅｆＣｏｕ
ｎｔｅｄＳＣＲｅｐクラス２２８を含む。これらのクラ
スは不変データ記憶メカニズムを備えたオペレーション
を定義するが、そのメカニズムを介して不変クラス２５
０のインスタンスからの不変データがデータストア２２
６から書込および／または検索される。

【００３３】図示の実施例によれば、ＮＥＯ＿ＳＰＯ＿
ＤＢクラス２３８のインスタンス(instance)は、データ
ストア、つまりデータベースを作成、オープンするため
に使用される静的クリエートアンドオープンメソッドを
持つ。ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢクラス２３９の
インスタンスはＮＥＯ＿ＳＰＯ＿ＤＢクラス２３８のイ
ンスタンスから抽出されるが、その静的メソッドはイン
ヘリタンスによって置き換えられない。静的クリエート
アンドオープン関数は、ＮＥＯ＿ＳＰＯ＿ＤＢクラス２
３８に関連する他のメソッドのすべてに先立って使用さ
れる。ＮＥＯ＿ＳＰＯ＿ＤＢクラス２３８は、データの
読取り、書込、開閉を管理するデータベースマネジャを
表す。ＮＥＯ＿ＳＰＯ＿ＤＢクラス２３８のインスタン
スはＮＥＯ＿ＳＰＯ＿Ｏｂｊｅｃｔクラス２３２に関連
しており、それは、次にオブジェクト呼出をサポートす
るメソッドを持ったサブコントラクト表示であるＮＥＯ
＿ＳＰＯ＿ＳＣＲｅｐクラス２２８のインスタンスに関
連する。ＮＥＯ＿ＳＰＯ＿Ｏｂｊｅｃｔクラス２３２
は、メモリに保持されたオブジェクト表示を更新する実
際的機能を提供するデータベースオブジェクトを表す。
ＮＥＯ＿ＳＰＯ＿Ｏｂｊｅｃｔクラス２３２に関連する
ゲットアトリビュート(get attribute) 、すなわちｇｅ
ｔ＿ａｔｔｒメソッドと、セットアトリビュート(set a
ttribute) 、すなわちｓｅｔ＿ａｔｔｒメソッドは不変
オブジェクトの呼出に使用され、これについては図５に
関して以下に説明する。

【００３４】或る実施例では、ＮＥＯ＿ＳＰＯ＿Ｍａｎ
ａｇｅｒクラス２４２に関連する静的クリエートアンド
オープンメソッドを使ってデータストアが作成、オープ
ンされる。しかし、多重バックエンドが不変データ記憶
メカニズム２２５に接続された場合、ＮＥＯ＿ＳＰＯ＿
Ｍａｎａｇｅｒクラス２４２に関連する静的クリエート
アンドオープンメソッドは、更に、特定目的に合った適
切なバックエンドを選択するために使用される。ＮＥＯ
＿ＳＰＯ＿Ｍａｎａｇｅｒクラス２４２は、同時性を管
理し、オブジェクトを作成し、オブジェクトを破壊し、
ディスク上のオブジェクトに対して行なわれた変更をセ
ーブするために使用されるインタフェースを提供する。
一般に、ＮＥＯ＿ＳＰＯ＿Ｍａｎａｇｅｒクラス２４２
はシンプル不変オブジェクトアダプタとして役立つ。

【００３５】データストア２２６は、その中で不変デー
タがメモリに書き込まれるデータ構造である。データス
トア２２６は、通常、これに限定されるものではない
が、ＤＢＶｅｒｓｉｏｎクラス２５４、ＳＰＯ＿Ｄ
Ｂ：：Ｏｂｊｅｃｔクラス２３４、ＳＰＯ＿ＤＢ：：Ａ
ｔｔｒｉｂｕｔｅ２３６、ＳＰＯ＿ＤＢ：：Ｒｏｏｔ２
４０、およびタイプクラス２２１を含む。ＳＰＯ＿Ｄ
Ｂ：：Ａｔｔｒｉｂｕｔｅｓ２３６は、単一データスト
アの表示であるＳＰＯ＿ＤＢ：：Ｒｏｏｔ２４０に関連
するＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔ２３４に関連する属
性である。或る実施例では、データストア２２６は不変
データ記憶メカニズム２２５から連結解除されることに
よって、不変データ記憶メカニズム２２５に影響するこ
となく容易に変更できる「接続可能なバックエンド」を
定義する。データストア用のデータ構造は、データスト
アが関連する特定のフレームワークによって幅広く変化
する。データストアのデータ構造の一つを、図７に関し
て以下に説明する。

【００３６】図５は、本発明の一実施例による、データ
ストアに対する不変データの読取りと書込に関するステ
ップを説明するプロセス流れ図である。プロセスの流れ
はステップ３０２で開始され、そこで、属性のセット
（書込）または受取（作成）のいずれかのコールが行な
われる。ここで使用される場合、「属性」は値を持った
インタフェース定義言語（ＩＤＬ）で規定されたオブジ
ェクトであるか、あるいは属性自体が値である。属性が
オブジェクトの場合、データストア不変データもここで
は「属性」と呼ぶ。或る実施例では、このコールはオブ
ジェクトレファレンスを使って行なわれる。

【００３７】記載の実施例では、オブジェクトレファレ
ンスは、多くのフレームワーク内、例えばＣＯＲＢＡフ
レームワーク内で役立つオブジェクトレファレンスを表
すメカニズムのファットポインタ(fat pointer)でもよ
い。ファットポインタは、２つの「正常」ポインタを含
む構造と見做される。ファットポインタの第１ポインタ
は、クライアント表示を指示する表示ポインタであり、
ファットポインタの第２ポインタは、クライアント表示
に関連するメソッドテーブル、あるいはｍテーブルを指
示するポインタである。クライアント表示は、記載の実
施例のサブコントラクト表示としても知られているが、
オブジェクト呼出をサポートするメソッドを持つオブジ
ェクトである。或る実施例では、各クライアント表示は
ｍテーブルに関連しており、ｍテーブルは、ファットポ
インタを用いて、コールされたメソッドを呼び出す場合
に使用する適切なディスパッチメソッドの決定に使用さ
れるスタブ関数に関連する。関連ｍテーブルはローカル
ｍテーブルでもリモートｍテーブルでも標準ｍテーブル
でもよい。標準ｍテーブルはデータのマーシャリングと
結果のアンマーシャリングに使用されるコードに関連す
る。つまり、標準ｍテーブルは、不変オブジェクト用の
データをデータストアに書き込むために使用されるコー
ドと、不変オブジェクト用のコードをデータストアから
検索するために使用されるコードとを持つ。或る実施例
では、不変オブジェクトは標準ｍテーブルに関連する。

【００３８】ステップ３０４では、データストア上でオ
ペレーションを実行するメソッドがオブジェクトレファ
レンスを使って呼び出される。記載の実施例では、呼び
出されたメソッドは属性をセットするメソッド（「セッ
トアトリビュート」メソッド）か、属性を受け取るメソ
ッド（「ゲットアトリビュート」メソッド）のいずれか
になる。或る実施例では、非属性メソッドはサポートさ
れないので、非属性メソッドを含むリクエストとはエラ
ーをして処理される。リクエストをマーシャルするため
の標準ｍテーブルメソッドを使用する実施例や、オペレ
ーションを局所的に実行するためのローカルｍテーブル
メソッドを使用する実施例等の他の実施例も可能であ
る。後者の実施例では、オブジェクト表示は「混合」ｍ
テーブル、つまり属性用の標準ｍテーブルメソッドと、
メソッド用のローカルｍテーブル属性とを含むｍテーブ
ル、を含むことができる。

【００３９】ステップ３０４でメソッドが呼び出された
後、メソッドの呼出に使用される適切なスタブ関数が、
適切なｍテーブルを使ってステップ３０６で識別され
る。次にステップ３０８では、識別されたスタブ関数
が、一部には呼び出すべきサーバントを識別するため
に、サブコントラクト、つまりサブコントラクト表示の
上で呼び出される。一旦、識別されたスタブ関数がサブ
コントラクト表示上で呼び出されると、メソッドは「セ
ットアトリビュート」オペレーションか「ゲットアトリ
ビュート」オペレーションかに関する決定がステップ３
１０で行なわれる。オペレーションがセットアトリビュ
ートオペレーションである旨決定された場合、呼び出さ
れたメソッドにパスされるオブジェクトレファレンスは
属性値を含むことを示し、プロセスの流れはステップ３
１２に進み、そこで、属性値がマーシャルバッファにマ
ーシャル、つまりコード化される。一旦、新属性値がマ
ーシャルバッファにマーシャルされると、セットアトリ
ビュートメソッドを用いて新属性値がデータストアに書
き込まれる。図４のＯＭＴ２００を再び参照すると、セ
ットアトリビュートメソッドはＮＥＯ＿ＳＰＯ＿Ｏｂｊ
ｅｃｔクラス２３２（「ｓｅｔ＿ａｔｔｒ」) のインス
タンスであるオブジェクトに関連するメソッドであり、
これについては図６に関して以下に説明する。セットア
トリビュートメソッドを使ってデータがデータストアに
書き込まれた後、データストアへのデータ書込のプロセ
スはステップ３２６で完了する。

【００４０】オペレーションはゲットアトリビュートオ
ペレーションである旨ステップ３１０で決定された場
合、プロセス制御はステップ３１８に進み、そこで、ゲ
ットアトリビュートメソッドを使ってデータストアから
の属性が検索される。上述のセットアトリビュートメソ
ッドと同様、ゲットアトリビュートメソッド（「ｇｅｔ
＿ 」で始まるメソッド名とそれに続く属性の名前を持
ち、図４のＮＥＯ＿ＳＰＯ＿Ｏｂｊｅｃｔ２３２に関連
する）は、ステップ３２０で、データストアからデータ
をマーシャルバッファに読み取るために使用される。デ
ータストアからのデータの読取りに関連するステップ
は、図９に関して以下に説明する。ステップ３２２で
は、マーシャルバッファ内のデータが、コーラーによっ
てリクエストされた属性値、つまりコールされたメソッ
ドに関連するオブジェクトレファレンスを取得するため
に、アンマーシャルされる。属性値が取得された後、そ
の属性値はステップ３２４でコーラーに返される。その
後、不変オブジェクトのフレームワークの中でデータス
トアからデータを読み取るプロセスは、ステップ３２６
で完了する。

【００４１】次に図６を参照して、本発明の一実施例に
よる、新属性値（図５のステップ３１４）をセットする
ためにセットアトリビュートメソッドを使用するプロセ
ス、を説明する。プロセスの流れ４００はステップ４０
２で開始され、そこでセットアトリビュートメソッドが
コールされる。ステップ４０４で、不変データ（すなわ
ち属性値）がデータストアからマーシャルバッファに読
み取られる。或る実施例では、データストアから読み取
られた不変データは、すでにマーシャルされた形、例え
ばオクテットの二進ストリームである。データストアか
らデータを読み取るために使用される一メソッドを、図
９に関して以下に説明する。不変データがデータストア
から読み取られた後、ステップ４０６で属性値がマーシ
ャルバッファにマーシャルされる。ステップ４０８で
は、その属性値を含むマーシャルバッファがデータスト
アに書き込まれる。データをデータストアに書き込むた
めに使用されるメソッドを、図８に関して以下に説明す
る。マーシャルバッファがデータストアに書き込まれた
後、セットアトリビュートメソッドを使用するプロセス
はステップ４１０で完了する。

【００４２】図７は、本発明の一実施例による、データ
ストアのためのデータ構造５００の概略表示である。図
７は、図４に関して上述したクラスの一部のインスタン
スの表示を示す。より詳細には、図７は、図４のグルー
プ２２６に含まれるクラスの表示を示す。データ構造５
００は、データストアに関連するバージョンと特性とを
識別するルートノード(root node) ５０２を含む。すな
わち、ルートノード５０２はデータストア用の識別子で
ある。図４を再び参照すると、ルートノード５０２はＳ
ＰＯ＿ＤＢ：：Ｒｏｏｔクラス２４０のインスタンス
で、そこから由来した少なくとも一つの関連データスト
アオブジェクト５０４を持つ。データストアオブジェク
ト５０４はＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔクラス２３４
のインスタンス、例えば「Ｏｂｊ１」である。各データ
ストアオブジェクト５０４は、ＳＰＯ＿ＤＢ：：Ａｔｔ
ｒｉｂｕｔｅクラス２３６のインスタンス、例えば「Ａ
ｔｔｒ１」である属性５０６を含む。各属性５０６は、
名前５０８とバリュー５１０に関連しており、不変デー
タを表す。名前５０８は、オブジェクト５０４の属性５
０６とバリュー５１０用の独特な識別子として役立つ
が、本発明の一実施例によるオクテットのシーケンスで
ある。

【００４３】或る実施例では、各オブジェクト５０４も
オブジェクト識別子（ＯＩＤ）５１２および抹消フラグ
５１４と関連している。ＯＩＤ５１２は、それが関連す
るオブジェクト５０４を独特のメソッドで識別するが、
図１２に関して以下に説明する。抹消フラグ５１４（デ
ィレーテッドフラグとも呼ぶ）は、それが関連するオブ
ジェクトの抹消によって、他のオブジェクトを挿入でき
る利用可能スペースが作成されたか否かを識別する。上
記の識別を行なう他のメソッドについては、分散オブジ
ェクトプログラミングの当業者には自明であろう。

【００４４】或る実施例では、ルートノード５０２もタ
イプ５１６の関連リストを持ち、各タイプ５１６はイン
タフェース識別子と関連する独特のタイプ識別子（Ｉ
Ｄ）５１８を持つ。各タイプ５１６は対応するオブジェ
クト５０４と関連することができる。タイプ５１６は、
図４に示すタイプ２２１と等価である。この実施例によ
れば、各オブジェクト５０４は、一つのタイプ５１６に
対応するが、各タイプ５１６は一つ以上のオブジェクト
５０４に対応する。タイプＩＤ５１８は、特殊な呼出に
適したインタフェースを識別するために、「インタフェ
ースレポジトリ」の中で、つまり利用可能なインタフェ
ースのリストアップに使用できる。図２に関して、タイ
プＩＤ５１８は、呼出中のメソッドと共に使用する標準
ｍテーブルを識別するために、ｍテーブルレジストリ２
３０で使用できる。

【００４５】次に図８を参照して、本発明の一実施例に
よる、データストアにデータを書き込むメソッド、すな
わち図６のステップ４０８を説明する。データストアに
データを書き込むプロセスはステップ６０２で開始され
てステップ６０４に進み、そこで、書込先のデータスト
アが書込オペレーションを許すか否かの決定が行なわれ
る。この決定は、多重の読取りと書込のオペレーション
の同時発生を防ぐ何らかのメカニズムがデータストアへ
の書込を許すためにセットされるか否か、の決定を含
む。一部の実施例では、データストアが書込オペレーシ
ョンを許すか否かの決定は、そのデータストアに関連す
る書込ロックが、データストアに書込できるようにセッ
トされるか否かの決定を伴う。データストアが書込オペ
レーションを許さないと決定された場合、ステップ６０
６で例外が放棄されて(thrown)、ステップ６２４でプロ
セスが終了する。

【００４６】データストアが書込オペレーションを許す
旨ステップ６０４で決定された場合、プロセス制御はス
テップ６０８に移り、そこで、インデックスがＮＥＯ＿
Ｒｅａｌ＿ＳＰＯ＿Ｏｂｊｅｃｔ（図２でＮＥＯ＿Ｒｅ
ａｌ＿ＳＰＯ＿Ｏｂｊ２１０として識別されている）で
抽出される。インデックスがそこから抽出されるＮＥＯ
＿Ｒｅａｌ＿ＳＰＯ＿ＤＢ＿Ｏｂｊｅｃｔは、オブジェ
クトレファレンスによって指示されるＮＥＯ＿Ｒｅａｌ
＿ＳＰＯ＿ＤＢ＿Ｏｂｊｅｃｔクラスの内部インスタン
スで、これについては図１１に関して以下に説明する。
インデックスが抽出された後、ステップ６１０におい
て、その抽出されたインデックスを使って、データスト
アでＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔが発見される。ＳＰ
Ｏ＿ＤＢ：：Ｏｂｊｅｃｔは、図２でＳＰＯ＿ＤＢ：：
Ｏｂｊｅｃｔ２３４として識別されている。抽出された
インデックスは、通常、整数なので、様々な探索、例え
ばルックアップテーブルとリニアサーチを使った探索
が、データストアで適切なＳＰＯ＿ＤＢ：：Ｏｂｊｅｃ
ｔを発見するために使用される。ＳＰＯ＿ＤＢ：：Ｏｂ
ｊｅｃｔが発見された後、ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃ
ｔは、セットすべき属性の名前に対するマッチ(match)
を発見するためにステップ６１２で使用される。言い換
えれば、データストア内の対応するＳＰＯ＿ＤＢ：：Ｏ
ｂｊｅｃｔに関連するＳＰＯ＿ＤＢ：：Ａｔｔｒｉｂｕ
ｔｅが、データストアに書込中の属性の名前、すなわち
属性名に対するマッチを発見するために探索される。Ｓ
ＰＯ＿ＤＢ：：Ａｔｔｒｉｂｕｔｅは図２でＳＰＯ＿Ｄ
Ｂ：：Ａｔｔｒｉｂｕｔｅ２３６として識別され、ま
た、図７に関して上述したように、データストア内の各
オブジェクトは関連属性を持つ。属性名は、通常、スト
リング、つまりオクテットのシーケンスなので、マッチ
を発見するために通常用いれられる探索メソッドは、リ
ニア探索メソッドと二進(binary)探索メソッドを含む。

【００４７】一旦、データストア内の既存の属性名によ
る探索が行なわれると、セットすべき属性の名前に対応
するマッチが発見されたか否かに関する決定がステップ
６２４で行なわれる。属性名に対するマッチが発見され
なかった場合、プロセス制御はステップ６１６に進み、
そこで、新しいＳＰＯ＿ＤＢ：：Ａｔｔｒｉｂｕｔｅが
属性リストの末尾に加えられる。新ＳＰＯ＿ＤＢ：：Ａ
ｔｔｒｉｂｕｔｅがステップ６１６で属性リストの末尾
に加えられた後、ステップ６１８においてその属性名が
新属性に格納される。次に、ステップ６２０で、データ
ストアに書き込むべきデータが新属性に格納される。

【００４８】属性名に対するマッチが発見された旨ステ
ップ６１４で決定された場合、プロセス制御は直接にス
テップ６２０に移り、そこで、マーシャルバッファの内
容、すなわちマーシャルバッファにデータとして含まれ
る属性値がその属性に格納される。言い換えれば、マー
シャルバッファ内でカプセル化されたデータが新属性に
格納される。最後に、マーシャルバッファ内でカプセル
化されたデータをデータストアに書き込むプロセスはス
テップ４１０で完了する。

【００４９】次に図９を参照して、本発明の一実施例に
よる、データストアからデータを読み取るメソッド、す
なわち図５のステップ３２０と図６のステップ４０４を
説明する。データストアからのデータをマーシャルバッ
ファに読み取るプロセスはステップ７０２で開始され
る。ステップ７０４では、データの読取り先のデータス
トアが読取りを許すか否かに関する決定が行なわれる。
この決定は、或る実施例では、データストアから読取り
できるようにセットされた、データストアに関連する共
同読取りロック(shared read lock)が存在するか否かの
決定を含む。読取りロックが読取りオペレーションを許
さないと決定された場合、７０６で例外が放棄され、デ
ータストアからデータを読取りできないことを示す。デ
ータストアからデータを読み取るプロセスはステップ７
２４で終了する。

【００５０】データストアが読取りオペレーションを許
す旨ステップ７０４で決定された場合、プロセス制御は
ステップ７０８に移り、そこで、インデックスがＮＥＯ
＿Ｒｅａｌ＿ＳＰＯ＿Ｏｂｊｅｃｔ（図４でＮＥＯ＿Ｒ
ｅａｌ＿ＳＰＯ＿Ｏｂｊ２１０と識別されている）から
抽出される。インデックスは、オブジェクトレファレン
スによって指示されたＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿Ｏｂ
ｊｅｃｔクラスの内部インスタンスから抽出されるが、
これについては図１３に関して以下に説明する。インデ
ックスが抽出された後、抽出されたインデックスは、ス
テップ７１０で、対応するＳＰＯ＿ＤＢ：：Ｏｂｊｅｃ
ｔを発見するために使用される。ＳＰＯ＿ＤＢ：：Ｏｂ
ｊｅｃｔは図２で２３４ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔ
２３４として識別されている。抽出されたインデックス
は、通常、整数なので、様々な探索メソッド論、例えば
ルックアップテーブルとリニアサーチとを使用した探索
が、適切なＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔを発見するた
めに使用される。ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔが発見
された後、ＳＰＯ＿ＤＢ：：ＯＢｊｅｃｔは、ステップ
７１１で、読み取るべき属性の名前に対するマッチを発
見するために使用される。或る実施例では、リニア探索
メソッドを使って、データストアから読み取るべき属性
の名前、すなわち属性名に対するマッチを発見するため
に、対応するＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔに関連する
これらのＳＰＯ＿ＤＢ：：Ａｔｔｒｉｂｕｔｅ（図４の
クラス２３６）が配置される。他のメカニズム、例えば
ハッシングや二進探索が使用されるが、オブジェクトが
少数の属性しか持たない普通のケースでは、リニア探索
が最善の選択であることをよく理解しなければならな
い。図７に関して上述したように、各データストアオブ
ジェクトは一つ以上の関連属性を持つ。

【００５１】一旦、データストアの既存の属性名による
探索が行なわれると、読み出すべき属性の名前に対応す
るマッチが発見されたか否かに関する決定がステップ７
１２で行なわれる。属性名に対するマッチが発見されな
かった場合、読み取るべき属性は、ステップ７１０で識
別されたデータストアオブジェクトに対して存在しない
と決定される。プロセス制御は次にステップ７１４に進
み、そこで、一実施例によれば、例外の代わりに、空デ
ータ(null data) がコーラーまたはリクエストプロセス
に返される。或る場合には、空データは単に属性がセッ
トされていないことを意味するだけなので、空データは
エラーを表示しないかもしれない。空データがコーラー
に返された後、データをデータストアからマーシャルバ
ッファに読み取るプロセスは、ステップ７２２で完了し
たものと見做される。

【００５２】属性名に対するマッチが発見された旨ステ
ップ７１２で決定された場合、ステップ７１６におい
て、属性の値に対応するデータが、適切なＳＰＯ＿Ｄ
Ｂ：：Ａｔｔｒｉｂｕｔｅ（読み取るべき属性の名前に
一致する名前を持つ属性）から取得される。属性の値に
対応するデータがＳＰＯ＿ＤＢ：：Ａｔｔｒｉｂｕｔｅ
から取得された後、データはステップ７１８でコーラー
に返される。データストアからマーシャルバッファにデ
ータを読み取るプロセスは、その後ステップ７２２で完
了する。

【００５３】属性をデータストアから読み取ったりデー
タストアへ書き込むには、まず、データストアを開かな
ければならない。或る実施例では、データストアを開く
ために、そのデータストアに関係する情報を含むファイ
ルが識別される。分散オブジェクトシステム上で動作中
のプロセスは、一般に一つ以上のデータストアを利用し
ているので、まずデータストアから読み取ったりデータ
ストアに書き込むべき特定の属性に適したファイルが識
別される。図７に示す実施例に関して上述したように、
属性はオブジェクトと関連し、その各オブジェクトが次
にオブジェクト識別子と関連する。オブジェクト識別子
は、データストアと、従ってオブジェクトとそれに関連
する属性が属するファイル、とを識別する情報を含む。
オブジェクト識別子を図１２に関して以下に更に詳しく
説明する。或る実施例では、特定のデータストアを開く
ために用いられる適切なファイルが、データストアから
読み取ったりデータストアに書き込むべき属性に関連す
るオブジェクトのオブジェクト識別子を使って、独特な
メソッドで識別される。

【００５４】図１０は、本発明の一実施例による、デー
タストアのオープニングに関連するステップを示すプロ
セス流れ図である。プロセスはステップ８０２で開始さ
れてステップ８０３に進み、そこで、データ記憶用の適
切なファイルが選択される。すなわち、データファイル
は、例えば開かれる記憶ディスク上に配置されたファイ
ルから選択される。適切なファイルを選択するメソッド
を図１１に関して以下に説明する。適切なファイルが選
択された後、マーシャルバッファが、データ記憶用の選
択されたファイルを使ってステップ８０４で作成され
る。このマーシャルバッファはデータをメモリに保持す
るために使用され、「ファイルマーシャルバッファ」ま
たは「マーシャルバッファファイル」と見做される。次
に、ステップ８０６で、データストアバージョンレコー
ドが、データストアに対応するアンマーシャルメソッド
を使って、データファイルからアンマーシャルされる。
通常、バージョンレコードのフォーマットは変化しない
ので、データファイルに格納されたデータフォーマット
を識別するためにそのバージョンレコードを使用でき
る。

【００５５】データストアバージョンレコードがデータ
ファイルからアンマーシャルされた後、そのバージョン
レコードによって識別されたバージョンタイプがシンプ
ル不変コードのバージョンでサポートされるか否かに関
して、ステップ８０８で決定が行なわれる。例として、
図４のデータストア２２６のスキーマを更新するとき
は、ＤＢＶｅｒｓｉｏｎ２５４に関連するバージョン
は、データストア２２６を実装するコードがすべてのサ
ポートされたバージョンを認識して正しく解釈するよう
に変更される。すなわち、データストアバージョンレコ
ードは、ファイルがデータストアとしてサポートされる
か否かを決定するためにチェックされる。或る実施例で
は、バージョンレコードをチェックするプロセスも、適
切なファイルがデータストアとして役立つように開かれ
ているか否かを確かめるチェックを伴う。例として、そ
のチェックは、電子メールファイルがデータベースとし
て不注意に開かれているか否か決定することができる。
バージョンタイプがサポートされない場合、プロセス制
御はステップ８１０に進み、そこで、バージョンタイプ
がサポートされないことを示すために例外が放棄され
る。その後、データストアを開くプロセスがステップ８
２０で終了する。

【００５６】データファイルのバージョンレコードによ
って指示されたバージョンタイプがサポートされている
旨ステップ８０８で決定された場合、ステップ８１２に
おいてＳＰＯ＿ＤＢ：：Ｒｏｏｔタイプオブジェクトが
作成される。一旦、ＳＰＯ＿ＤＢ：：Ｒｏｏｔオブジェ
クトが作成されると、ステップ８１４において、データ
がファイルからＳＰＯ＿ＤＢ：：Ｒｏｏｔオブジェクト
に関連する構造、すなわちマーシャルバッファファイル
にアンマーシャルされる。すなわち、データは、ファイ
ルからデータストアルートオブジェクトに関連する構造
にアンマーシャルされる。インタフェース定義言語（Ｉ
ＤＬ）コンパイラは、ファイルからのデータをアンマー
シャルするために使用されるコンパイル済のアンマーシ
ャル関数を生成する。従って、ファイルからのデータを
ルート構造にアンマーシャルするために使用される実際
のアンマーシャルメソッドが分かっている。データがマ
ーシャルバッファファイルからアンマーシャルされた
後、ファイルはステップ８１６で閉じられる。

【００５７】ステップ８１７では、データストアが、デ
ータストアレジストリによって登録されるが、それは、
或る実施例では分散オブジェクトシステム上の特定プロ
セスに関連するデータストアのリストを含む。データス
トアがデータストアレジストリによって登録された後、
ステップ８１８でルートがコーラーに返される、すなわ
ちステップ２１８で作成されたＳＰＯ＿ＤＢ：：Ｒｏｏ
ｔがコーラーに返される。その後、データストアを開く
プロセスはステップ８２２で完了する。データストアル
ートオブジェクトは、データストアルートオブジェクト
を破壊するためにコマンドが発行されるまでメモリの中
に残ることをよく理解しなければならない。従って、特
定プログラムを実行する間の任意の時点で、いくつもの
データストアを開けることができる。

【００５８】次に図１１を参照して、本発明の一実施例
による、データ記憶用の適切なファイルの選択メソッ
ド、すなわち図１０のステップ８０３を説明する。記載
の実施例では、「適切なファイル」とは、所定の呼出に
関連する情報の格納を含むかその受け入れが可能なファ
イルの無傷なバージョン(intact version)のことを指
す。通常の状況、すなわち分散オブジェクトシステム上
のプロセスが適切に実行されている場合、ファイル
「Ｆ」はデータ記憶用に選択すべき適切なファイルであ
る。しかしながら、ファイルへの書込プロセスの実行時
に、ファイルが改竄(corrupted) されるような問題が起
こった場合、ファイル「Ｆ」よりもファイル「Ｆ」に関
係するファイルの方が選択すべき適切なファイルにな
る。例として、新ファイルのＦ．ＮＥＷが準備されるま
でファイルＦが無傷に保たれるのを保証するために、新
ファイル「Ｆ．ＮＥＷ」（ファイルＦに書き込むための
変更を含む）をファイルＦへの書込プロセスで作成でき
る。更に、システム破壊がファイルＦへの書込プロセス
の間に起こった場合にバックアップデータを確実に利用
できるように、バックアップファイル「Ｆ．ＢＡＣＫ」
もファイルＦへの書込のプロセスで作成される。ファイ
ルＦ．ＮＥＷが作成された後、ファイルＦはファイル
Ｆ．ＢＡＣＫと改名され、ファイルＦ．ＮＥＷはファイ
ルＦと改名される。その後、ファイルＦ．ＢＡＣＫは抹
消される。

【００５９】適切なファイルを選択するプロセスはステ
ップ９０２で開始される。ステップ９０４では、通常、
適切なファイルを求める探索の目標ファイルになるはず
のファイルＦが存在するか否かを確かめるためにチェッ
クが行なわれる。次に、ファイルＦ．ＮＥＷのための探
索がステップ９０６で行なわれる。ファイルＦ．ＮＥＷ
のための探索が行なわれた後、ファイルＦ．ＢＡＣＫを
求める探索がステップ９０８で行なわれる。次に、ステ
ップ９１０で、ファイルＦが存在するか否かの決定が行
なわれる。ファイルＦが存在する場合、ファイルＦは無
傷であると予想され、ステップ９１２で適切なファイル
として選択される。ステップ９０２でファイルＦが存在
しないと決定された場合、プロセス制御はステップ９１
６に進み、ファイルＦ．ＮＥＷとＦ．ＢＡＣＫが共に存
在するか否か決定される。Ｆ．ＮＥＷとＦ．ＢＡＣＫが
共に存在すると決定された場合、ファイルＦ．ＮＥＷは
無傷と予想され、ステップ９１８で適切なファイルとし
て選択される。ファイルＦが存在しないのに、Ｆ．ＮＥ
ＷとＦ．ＢＡＣＫの両ファイルが存在することは、ファ
イルＦが置き換えられたこと、およびファイルＦ．ＮＥ
ＷをファイルＦと改名してファイルＦ．ＢＡＣＫを抹消
するステップが起こらなかったと想定されることを示
す。従って、ファイルＦ．ＮＥＷは、そのファイルが存
在した場合、ファイルＦに含まれるはずの情報を含むも
のと想定される。ファイルＦ．ＮＥＷは、従って、選択
すべき適切なファイルと想定される。ファイルＦ．ＮＥ
Ｗがステップ９１８で選択された後、適切なファイルを
選択するプロセスはステップ９２２で終了する。

【００６０】ステップ９１６に戻って、ファイルＦが存
在しないとステップ９１０で先に決定されていたとし
て、ステップ９１６においてファイルＦ．ＮＥＷとファ
イルＦ．ＢＡＣＫが共に存在しないと決定された場合、
ステップ９２０で例外が放棄され、適切なファイルが存
在しないことを示す。その後、適切なファイルを選択す
るプロセスはステップ９２２で終了する。

【００６１】上述のように、オブジェクト識別子を使っ
て、オブジェクトが関連するデータストアオブジェクト
とデータストアが独特なメソッドで識別される。図１２
は、本発明の一実施例によるオブジェクト識別子の概略
表示である。オブジェクト識別子（ＯＩＤ）１００２
は、ＯＩＤ１００２が関連するオブジェクトを独特なメ
ソッドで識別する情報を含むデータ構造で、オブジェク
トレファレンスをマーシャルおよびアンマーシャルする
プロセスで使用されるが、これについては図１４と１５
に関して以下に説明する。記載の実施例では、ＯＩＤ１
００２はサブコントラクト識別子（ＳＣＩＤ）１００
４、データストア識別子、つまりデータベース識別子
（ＤＢＩＤ）１００６、およびＯＩＤインデックス１０
０８を含む。

【００６２】或る実施例では、ＳＣＩＤ１００４はタイ
プ「ロング」、すなわち長い整数で、ＯＩＤ１００２に
よって識別されたオブジェクトに関連するサブコントラ
クトを独特なメソッドで識別する。ＯＩＤ１００２によ
って識別されたオブジェクトのための適切なデータスト
アは、ＤＢＩＤ１００６の使用によって決定される。Ｄ
ＢＩＤ１００６は、タイプスタンプ１０１０、プロセス
識別子１０１２、およびカウント変数１０１４を含む入
れ子構造(nested structure)である。図示の実施例で
は、タイムスタンプ１０１０はタイプロングで、特定の
データストアがアクセスされた最終時点に関する情報を
提供する。プロセス識別子１０１２はタイプ「ショー
ト」、すなわち短い整数で、ＯＩＤ１００２によって識
別されたオブジェクトに関連するデータストアを作成し
たプロセスを識別する。またタイプショートであるカウ
ント変数１０１４は、データストアが作成される度毎に
増分されるカウンタである。プロセス識別子１０１２
は、データストアを同時に作成する多重プロセスが、他
のプロセスによってオープン可能な独特のＤＢＩＤ１０
０６を作成するのをチェックするために使用される。フ
ァイルが作成された後は、プロセス識別子１０１２は最
早プロセスに関連しない。一般に、タイムスタンプ１０
１０、プロセス識別子１０１２、およびカウント変数１
０１４は、同一ホスト上の一つ以上のデータストアが同
一ＤＢＩＤ１００６を持つ可能性が低くなるように、指
定される。

【００６３】本発明の一実施例によれば、ＯＩＤインデ
ックス１００８は、インデックス１０１６とユーズカウ
ント１０１８とを含む構造である。ＯＩＤインデックス
１００８はオブジェクトレファレンスと直接に関連し、
そのオブジェクトレファレンスを適切なオブジェクトと
関連させるために使用される。インデックス１０１６
（図示の実施例ではタイプロング）は、ＯＩＤ１００２
によって識別されたオブジェクトを発見するために、デ
ータストアに関連するオブジェクトのリストによるクイ
ックインデクシングを見込む。言い換えれば、インデッ
クス１０１６は、ＤＢＩＤ１００６によって識別された
データストアに関連するオブジェクトのリスト、つまり
シーケンスの中のオブジェクトの相対位置を決める。カ
ウント１０１８は、ユーズカウントとしても知られてい
るが、インデックス１０１６が再使用される度毎に増分
される。カウント１０１８（図示の実施例ではロングタ
イプ）は、インデックス１０１６に関連するオブジェク
トレファレンスの有効性を決定するために使用できる。
例として、オブジェクトレファレンスは、オブジェクト
のリストの所定の場所、つまりスロットに配置されたオ
ブジェクトに関連することができる。そのオブジェクト
が抹消されると、抹消されたオブジェクトに関連するす
べてのオブジェクトレファレンスは最早有効でない。カ
ウント１０１８の旧値(outdated value)は、通常、関連
オブジェクトレファレンスが無効であることを示す。

【００６４】図１３は、本発明の一実施例によるオブジ
ェクトレファレンスの概略表示である。オブジェクトレ
ファレンス１１０２は、メソッドテーブル、つまりｍテ
ーブル１１０４、およびサブコントラクト表示１１０６
に関連する。ｍテーブル１１０４は、呼出可能なメソッ
ドに関連するスタブ関数へのポインタを含み、ローカル
ｍテーブルまたはリモートｍテーブルのいずれでもよ
い。ローカルｍテーブルは、ローカルプロセスで使用さ
れるメソッドに関連するが、リモート、すなわち標準ｍ
テーブルは、リモートプロセスで使用されるメソッドに
関連する。或る実施例では、オブジェクトレファレンス
がローカルのプロセスに関連する場合、ｍテーブル１１
０４はローカルｍテーブルとなる。同様に、オブジェク
トレファレンス１１０２がリモートプロセスに関連する
場合、ｍテーブル１１０４はリモート、つまり標準ｍテ
ーブルになる。前述したように、不変オブジェクトはリ
モートｍテーブルに関連する。

【００６５】サブコントラクト表示、つまりＮＥＯ＿Ｓ
ＰＯ＿ＳＣＲｅｐ１１０６（図４ではＮＥＯ＿ＳＰＯ＿
ＳＣＲｅｐ２２８と表示）は、ＮＥＯ＿Ｒｅａｌ＿ＳＰ
Ｏ＿Ｏｂｊｅｃｔ１１０８（図４ではＮＥＯ＿Ｒｅａｌ
＿ＳＰＯ＿Ｏｂｊ２１０と表示）に関連する。ＮＥＯ＿
ＳＰＯ＿ＳＣＲｅｐ１１０６によって引照されたＮＥＯ
＿Ｒｅａｌ＿ＳＰＯ＿ＯｂｊはＯＩＤインデックス１１
１２（図１２に関してＯＩＤインデックス１００８とし
て記載）と、ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢとに関連
する。ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢは、図４でＮＥ
Ｏ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢ２３９として表される。

【００６６】分散オブジェクトは、不変であるかないか
を問わず、基本的な「ライフサイクルオペレーション」
を持ち、それは、通常、これに限定されるわけではない
が、呼出、マーシャリング、アンマーシャリング、作
成、および破壊を含む。オブジェクト呼出は、サーバン
トに或るオペレーションを実行させるためにサーバント
オブジェクトを呼び出すプロセスである。オブジェクト
呼出の例は、ゲットアトリビュートまたはセットアトリ
ビュートメソッドのいずれかの呼出であり、これについ
ては先に図５に関して述べた。不変オブジェクトのマー
シャリング、アンマーシャリング、作成、および破壊の
オペレーションについは、それぞれ図１４〜１８に関し
て説明する。

【００６７】図１４は、本発明の一実施例による、マー
シャルバッファへのオブジェクトレファレンスのマーシ
ャリングに関連するステップを説明するプロセス流れ図
である。具体的には、不変オブジェクトに関連するオブ
ジェクトレファレンスをマーシャルするプロセスについ
て説明する。プロセスはステップ１２０２で開始されて
ステップ１２０４に進み、そこで、そのオブジェクトレ
ファレンスに関連するデータストアが読取状態にあるか
否か決定される。データストアが読取状態にない場合、
ステップ１２０６で例外が放棄され、マーシャリングプ
ロセスはステップ１２２４で終了する。一方、データス
トアが読取状態にある場合、図１２と１３に関して上述
したように、ＯＩＤインデックスがオブジェクトレファ
レンスから取得されて、ステップ１２０８でＳＰＯ＿Ｄ
Ｂ：：Ｏｂｊｅｃｔのインスタンスに変換される。ステ
ップ１２１０において、ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔ
のインスタンスへのＯＩＤインデックスの変換が成功し
たか否かに関する決定が行なわれる。或る実施例では、
この決定は、マーシャルすべきオブジェクトレファレン
スが有効か否かを決定するために用いられるエラーチェ
ックである。ＯＩＤインデックスへの変換が成功しなか
った場合、オブジェクトレファレンスは最早有効でない
ことを示すために、例外がステップ１２０６で放棄され
て、マーシャリングプロセスがステップ１２２４で終了
する。

【００６８】ＯＩＤインデックスがＳＰＯ＿ＤＢ：：Ｏ
ｂｊｅｃｔのインスタンスに首尾よく変換された場合、
プロセス制御はステップ１２１２に進み、そこで、図１
２に関して上述したように、ＯＩＤが作成される。ＯＩ
Ｄが作成された後、サブコントラクト識別子（ＳＣＩ
Ｄ）（ＯＩＤによって識別されたオブジェクトに関連す
るサブコントラクトに対応）がステップ１２１４でＯＩ
Ｄに格納される。ＳＣＩＤによって識別されたこのサブ
コントラクトは、図１３のオブジェクトレファレンスに
対して記載されたサブコントラクト表示に関連するサブ
コントラクトである。通常、ＯＩＤに関連するサブコン
トラクトは一つしか存在しないのでＳＣＩＤが固定され
る。ＳＣＩＤがＯＩＤに格納された後、データストア識
別子、つまりデータベース識別子（ＤＢＩＤ）が、ステ
ップ１２０８のＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔに関連す
るＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢのインスタンスから
抽出される。ＤＢＩＤの一部として含まれる情報は、こ
れに限定されるわけではないが、先に図１２に関して記
載したように、タイプスタンプ、プロセス識別子、およ
びカウンタを含む。ＤＢＩＤはステップ１２１８でＯＩ
Ｄに挿入、つまり格納される。

【００６９】ＤＢＩＤがＯＩＤに格納された後、オブジ
ェクトレファレンスに関連するＯＩＤインデックスがス
テップ１２２０でＯＩＤにコピーされる。次に、ＯＩＤ
がステップ１２２２でマーシャルバッファにマーシャル
される。ＯＩＤをマーシャルするために使用されるマー
シャリング関数はＩＤＬコンパイラから取得され、ＯＩ
ＤのためのＩＤＬ定義に基づく。最後に、マーシャリン
グプロセスはステップ１２２４で完了する。

【００７０】一旦、オブジェクトレファレンスが或る領
域でマーシャルバッファにマーシャルされると、それは
他の領域のマーシャルバッファからアンマーシャルでき
る。オブジェクトレファレンスをアンマーシャルするプ
ロセスは、オブジェクトレファレンスをマーシャルする
プロセスの逆と見做すことができる。言い換えれば、オ
ブジェクトレファレンスをマーシャルすることはマーシ
ャルバッファでオブジェクトレファレンスをコード化す
ることを意味するのに対して、マーシャルバッファから
オブジェクトレファレンスをアンマーシャルすること
は、マーシャルされたオブジェクトレファレンスをデコ
ードすることを意味する。

【００７１】次に図１５を参照して、本発明の一実施例
による、マーシャルバッファからデータをアンマーシャ
ルするプロセスを説明する。マーシャルバッファに含ま
れたオブジェクトレファレンスをアンマーシャルするプ
ロセスはステップ１３０２で開始されてステップ１３０
４に進み、そこで、ＯＩＤが、それがカプセル化される
マーシャルバッファからアンマーシャルされる。ＯＩＤ
がアンマーシャルされた後、ＯＩＤに対応するＳＣＩＤ
が正しいか否か、すなわちＳＣＩＤが期待される値を持
つか否かに関する決定が行なわれる。ＳＣＩＤは正しく
ないと決定された場合、例外がステップ１３０７で放棄
されて、データをアンマーシャルするプロセスはステッ
プ１３０９で終了する。

【００７２】ステップ１３０６で、ＳＣＩＤが正しいと
決定された場合、次にステップ１３０８でＤＢＩＤがＯ
ＩＤから取得される。多重データストアは、所定のプロ
セスの進行中、開いているので、マーシャルバッファに
含まれるオブジェクトレファレンスに関係する特定のデ
ータストアは、しばしば、先験的に未知である。ＤＢＩ
Ｄは、オブジェクトレファレンスに対応するデータスト
アを決定するために使用される。記載の実施例では、Ｄ
ＢＩＤは、同一プロセス内で開かれているすべてのデー
タストアに関係する情報を含むデータストアレジストリ
でキーとして使用される。或る実施例では、データスト
アレジストリは、ＤＢＩＤをインデックスとして使用し
てデータストアレコードを格納するルックアップテーブ
ルとし使用される。

【００７３】ＤＢＩＤがＯＩＤから取得された後、プロ
セス制御はステップ１３１０に移り、そこで、ＤＢＩＤ
によって識別されるデータストアが発見されたか否かに
関する決定が行なわれる。適切なデータストアが発見さ
れなかった場合、ステップ１３０７で例外が放棄され
て、手順はステップ１３０９で終了する。他方、適切な
データストアが発見された場合、次にステップ１３１２
において、データストアが読取オペレーションを許すか
否か決定される。記載の実施例では、データストアが読
取オペレーションを許すか否かの決定は、読取ロックが
保持されているか否かの決定である。データストアが読
取オペレーションに対して開いていない場合、ステップ
１３０７で例外が放棄される。そうでなく、データスト
アが読取オペレーションに対して開いている場合、ステ
ップ１３１４において、ＯＩＤから取得されるＯＩＤイ
ンデックスが有効か否かに関する決定が行なわれる。Ｏ
ＩＤインデックスが有効でない場合、ステップ１３０７
で例外が放棄される。

【００７４】ＯＩＤインデックスが有効である旨ステッ
プ１３１４で決定された場合、プロセス制御はステップ
１３１６に進み、そこで、データストアオブジェクトラ
ッパーがＯＩＤインデックスを使って構築されるが、そ
れは、図４で識別されたＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿Ｏ
ｂｊ２１０である。データストアオブジェクトラッパー
は、真のオブジェクトを作成するために使用し得るコー
ドを「ラップ(wrap)」またはパッケージするために使用
される。言い換えれば、オブジェクトラッパーを使用し
て、ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＯｂｊへのＳＰＯ＿Ｄ
Ｂ：：Ｏｂｊｅｃｔのインスタンスの変換に関係するコ
ードがラップされる、すなわちＮＥＯ＿Ｒｅａｌ＿ＳＰ
Ｏ＿Ｏｂｊは、ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔである実
際のオブジェクト表示を囲むラッパーである。一般に、
オブジェクトラッパーの機能は、同一のサブコントラク
トが異なるデータストアに対して使用できるように、関
連サブコントラクトの実装をデータストアの実装から分
離することである。データストアオブジェクトラッパー
が構築された後、ステップ１３１８でタイプ識別子がオ
ブジェクトラッパーから取得される。次に、ステップ１
３２０で、データストアオブジェクトがオブジェクトラ
ッパーから取得される。

【００７５】データストアオブジェクトがオブジェクト
ラッパーから取得された後、ステップ１３２２でインタ
フェース識別子（ＩＤ）がデータストアから取得され
る。インタフェースＩＤはステップ１３１８で取得され
たタイプＩＤを引数として使用して発見してもよい。ス
テップ１３２４では、オブジェクトレファレンスの構築
で使用し得る適切なｍテーブルを発見するために、イン
タフェースＩＤがｍテーブルレジストリでキーとして使
用される。ｍテーブルレジストリは、ｍテーブルのリス
トを含むデータ構造である。或る実施例では、不変オブ
ジェクトに関係するオブジェクトレファレンスに対し
て、適切なｍテーブルはリモートｍテーブルである。適
切なｍテーブルがｍテーブルレジストリで発見された
後、プロセス制御はステップ１３２６に進み、そこで、
オブジェクトレファレンスの作成に使用すべきサブコン
トラクト表示が、ラッパーとリモートｍテーブルとを使
用して構築される。ステップ１３２８では、図１３に関
して上述したオブジェクトレファレンスが、サブコント
ラクト表示とリモートｍテーブルとを使って構築され
る。最後に、ステップ１３３０で、オブジェクトレファ
レンスが、アンマーシャルメソッドを呼び出したプロセ
スに返される。

【００７６】図１６は、本発明の一実施例による、オブ
ジェクトレファレンスの作成に関連するステップを示す
プロセス流れ図である。図４に関して、クリエートメソ
ッドがＮＥＯ＿ＳＰＯＭａｎａｇｅｒ２４２上で定義さ
れる。オブジェクトレファレンスを作成するプロセスは
ステップ１４０２で開始され、そこで、クリエートプロ
セスがタイプ識別子を引数としてコールされる。タイプ
識別子は、インタフェース識別子が既知の場合に決定さ
れる。例として、インタフェース識別子をインタフェー
スレポジトリ、すなわちインタフェースのリストの中で
インデックスとして使用して、インタフェース識別子を
対応するタイプ識別子に関連させることができる。ステ
ップ１４０４では、ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔのイ
ンスタンスを真のオブジェクトに変換するためのＮＥＯ
＿Ｒｅａｌ＿ＳＰＯ＿Ｏｂｊが作成されるが、これにつ
いては図１７に関して以下に説明する。

【００７７】このオブジェクトラッパーが構築された
後、ステップ１４０６でインタフェース識別子がデータ
ストア、すなわちＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢから
取得される。インタフェースＩＤは、クリエートプロセ
スがコールされたときに、図４のＮＥＯ＿ＳＰＯ＿Ｍａ
ｎａｇｅｒ２４４のクリエートメソッドに引数としてパ
スされたタイプＩＤを使って発見される。ステップ１４
０８では、返されたインタフェースＩＤが、不変オブジ
ェクト用のオブジェクトレファレンスの構築に適したｍ
テーブルを発見するために、ｍテーブルレジストリの中
でキーとして使用される。先に述べたように、或る実施
例では、適切なｍテーブルはリモートｍテーブルであ
る。適切なｍテーブルがｍテーブルレジストリで発見さ
れた後、プロセス制御はステップ１４１０に進み、そこ
で、サービス用のリクエストを示すサブコントラクト表
示が、オブジェクトラッパーとリモートｍテーブルとを
使って構築される。ステップ１４１２では、図１３に関
して上述したオブジェクトレファレンスがサブコントラ
クト表示とリモートｍテーブルとを使って構築される。
最後に、ステップ１４１４で、新しく作成されたオブジ
ェクトレファレンスが、クリエートプロセスをコールし
たプロセスに返される。

【００７８】次に図１７を参照して、本発明の一実施例
による、タイプＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿Ｏｂｊ（図
１６のステップ１４０４）のオブジェクトラッパーを作
成するメソッドを説明する。オブジェクトラッパーを作
成するプロセスは、ステップ１５０２で、オブジェクト
ラッパーを作成するためのコールで開始される。オブジ
ェクト用の新スロットがＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔ
リストまたはシーケンスで利用可能か否かに関して、ス
テップ１５０４で決定が行なわれる。図７に関して先に
記載したように、各ＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔに関
連する抹消フラグは、データストアに関連するオブジェ
クトのリストの中の空、つまり未使用スロットを識別す
るためにセットされる。或る実施例では、空スロットが
利用可能か否かの決定は、真(true)にセットされる抹消
フラグのためのオブジェクトのリストによる探索を含
む。他の、より効率的な実施例は、二次データ構造、例
えば空スロットのフリーリストの作成を含む。そのよう
な実施例は、空スロットを探索するコストを回避する。
このような多数の二次構造が可能であり、これに限定さ
れるわけではないが、リスト、ビットマップ、テーブル
とツリーの各種形態を含む。

【００７９】利用可能な空スロットが存在しない旨ステ
ップ１５０４で決定された場合、ステップ１５０８で、
新しいスロットがＳＰＯ＿ＤＢ：：Ｏｂｊｅｃｔのリス
トの末尾に追加さえる。オブジェクトに関連するユーズ
カウント変数が、新しく追加されたスロットを初期化す
るために、ステップ１５１０でゼロにセットされる。図
７と１１に関して先に述べたように、各ＳＰＯ＿Ｄ
Ｂ：：ＯｂｊｅｃｔはＯＩＤに関連し、オブジェクトに
よって占拠されるスロットが再使用される度毎に増分す
るユーズカウント変数を含む。スロットが初期化される
と、スロット内のオブジェクトに関連する抹消フラグ
が、スロットが使用中であることを示すために、ステッ
プ１５１２で偽(false) にセットされる。

【００８０】オブジェクトのリストの中に利用可能な空
スロットが存在する旨ステップ１５０４で決定された場
合、プロセスの流れはステップ１５０６に進み、そこ
で、そのスロットに関連するユーズカウントが、スロッ
トが再使用されたことを示すために増分される。一旦、
ユーズカウントが増分されると、スロット内のオブジェ
クトに関連する抹消フラグがステップ１５１２で偽にセ
ットされる。次にステップ１５１４で、タイプ識別子が
スロットに格納される。タイプ識別子がスロットに格納
された後、ステップ１５１６で、スロットに対応するＯ
ＩＤインデックスが構築される。ＯＩＤインデックス
は、図１２に関して先に記載したように、オブジェクト
のリストとユーズカウントとの効率的なインデックスを
可能にするために使用されるインデックスを含む。ステ
ップ１５１８では、ＯＩＤインデックスに対応するオブ
ジェクトラッパーが、分散オブジェクトプログラミング
の当業者には周知のメソッドを使って構築される。その
後、オブジェクトラッパーはステップ１５２０でコーラ
ーに返される。

【００８１】図１８は、本発明の一実施例による、デー
タストアオブジェクトの破壊に関連するステップを示す
プロセス流れ図である。プロセスはステップ１６０４で
開始され、データストアに格納されたオブジェクトを破
壊するためのコールが行なわれる。ステップ１６０４
で、オブジェクトが格納されるデータストアがオペレー
ションの書込のために開いているか否かに関して決定が
行なわれる。データストアが書込可能でない場合、オブ
ジェクトが破壊できなかったことを示すためにステップ
１６０６で例外が放棄され、プロセスはステップ１６０
７で終了する。他方、データストアが書込可能な場合、
プロセスの流れはステップ１６０８に進み、そこで、破
壊すべきオブジェクトに対応するＳＰＯ＿ＤＢ：：Ｏｂ
ｊｅｃｔリストの中のスロットが発見される。破壊すべ
きオブジェクトに対応するＯＩＤインデックスは、オブ
ジェクトのリストの中にインデックスとして使用でき
る。ステップ１６１０において、破壊すべきオブジェク
ト用のＯＩＤインデックスに対応するスロットが発見さ
れたか否か決定される。適切なスロットが発見されなか
った場合、オブジェクトが破壊できなかったことを示す
ために、ステップ１６０６で例外が放棄されて、プロセ
スはステップ１６０７で終了する。

【００８２】破壊すべきオブジェクト用のＯＩＤインデ
ックスに対応するスロットが発見された旨ステップ１６
１０で決定された場合、スロット用の抹消フラグが、ス
ロットが空であることを示すために、ステップ１６１２
で真に等しくセットされる。抹消フラグがセットされた
後、プロセス制御はステップ１６１６に進み、そこで、
スロットに関連するメモリが属性に対して解放される。
すなわち、スロットに関連するメモリがクリアーされ
る。最後に、メモリが開放された後、プロセスはステッ
プ１６１８でコーラーに返る。

【００８３】当業者にはよく理解されるように、データ
ストアは、通常、コンピュータディスク、ＣＤ−ＲＯＭ
等の上のファイルに格納される。ファイルのデータスト
アがアクセスされて修正されるときは、データストアフ
ァイル（ここではファイル「Ｘ」と呼ぶ）は、通常、デ
ータストアに加えられる変更を反映するために修正さな
ければならない。システム破壊時のデータストアの完全
性を保護するために、まず、修正済データストアがファ
イルＸ以外のファイルに書き込まれる。ファイルＸを別
のファイルと交換する前に修正済データストアをその別
のファイルに書き込むと共にＸ用のバックアップファイ
ルを作成することによって、万一システム破壊が起こっ
た場合でも、通常、データストアの何らかのバージョン
を含む無傷(intact)のファイルが常に存在することにな
る。このように、データストアをコンピュータディスク
等の上のファイルに付託(committing)するプロセスは、
通常、データストアを改竄(corrupting)する可能性から
保護するために一時的なデータファイルの作成を伴う。

【００８４】図１９は、本発明の一実施例による、デー
タストアファイルを更新するデータストア付託メカニズ
ムに関連するステップを示すプロセス流れ図である。プ
ロセスはステップ１７０２で開始され、そこで付託プロ
セスがコールされる。ステップ１７０３では、付託プロ
セスの目標であるデータストアが書込オペレーションに
対して開いているか否かに関して決定が行なわれる。デ
ータストアが書込可能でない場合、データストアに書込
できなかったことを示すためにステップ１７１２で例外
が放棄されて、ステップ１７１３において付託プロセス
が終了する。他方、データストアが書込可能な場合、プ
ロセスの流れはステップ１７０４に進み、そこで、デー
タストアの変更版に対応するＳＰＯ＿ＤＢ：：Ｒｏｏｔ
クラスのインスタンスが新ファイルに書き込まれ、それ
をファイル「Ｘ．ＮＥＷ」と呼ぶ。ＳＰＯ＿ＤＢ：：Ｒ
ｏｏｔクラスのインスタンスをファイルＸ．ＮＥＷに書
き込むプロセスを、図２０に関して以下に説明する。フ
ァイルＸ．ＮＥＷが作成された後、プロセス制御はステ
ップ１７０６に進み、そこでファイルＸがファイル
「Ｘ．ＢＡＣＫ」と改名される。次にステップ１７０８
で、ファイルＸ．ＮＥＷがファイルＸと改名される。フ
ァイルＸをファイルＸ．ＢＡＣＫと改名することによっ
て、ファイルＸ．ＮＥＷをファイルＸと改名するプロセ
スで万一システムエラーが起こっても、ファイルＸ．Ｂ
ＡＣＫは未改竄(uncorrupted) の、より旧版のデータス
トアを含むことになる。

【００８５】ファイルＸ．ＮＥＷがファイルＸと改名さ
れた後、ファイルＸ．ＢＡＣＫがステップ１７１０で抹
消される。次にステップ１７１４で、データストアの書
込状態、すなわちファイルＸを含む修正されたデータス
トアが「無(none)」にクリアーされる。データストア
と、従って、データストアファイルの書込状態とを無に
クリアーすることは、コールのプロセスがデータストア
ファイルからの読取りまたは書込のいずれかに対する許
可をリクエストするまで、書込または読取りオペレーシ
ョンがデータストア上で起こらないことを示す。一旦、
書込状態が無にクリアーされると、付託プロセスの結果
がステップ１７１６でコーラーに返される。

【００８６】次に図２０を参照して、本発明の一実施例
による、新ファイルへのＳＰＯ＿ＤＢ：：Ｒｏｏｔクラ
スのインスタンスの書込メソッド、すなわち図１９のス
テップ１７０４を説明する。プロセスはステップ１７２
０で開始され、新ファイル、すなわちファイルＸ．ＮＥ
Ｗへのルートオブジェクト、すなわちＳＰＯ＿ＤＢ：：
Ｒｏｏｔクラスのインスタンスの書込がリクエストされ
る。ステップ１７２２で、ファイルＸ．ＮＥＷを開く試
みが行なわれる。ステップ１７２３において、ファイル
Ｘ．ＮＥＷが首尾よく開かれたか否かに関する決定が行
なわれる。、ファイルＸ．ＮＥＷが首尾よく開かれなか
った旨決定された場合、ステップ１７２５で例外が放棄
されて、ルートオブジェクトをファイルＸ．ＮＥＷに書
き込む試みはステップ１７２７で終了する。

【００８７】或る実施例では、ファイルＸ．ＮＥＷが首
尾よく開かれた旨ステップ１７２３で決定された場合、
プロセス制御はステップ１７２６に進み、そこで、ファ
イルＸ．ＮＥＷに対応する共通データ表示（ＣＤＲ）マ
ーシャルバッファが作成される。ＣＤＲは、インターネ
ットインタオペラブルプロトコル（ＩＩＯＰ）によって
規定されたコード化ルールの名前である。ＣＤＲマーシ
ャルバッファが作成された後、データストアバージョン
構造が「マジックナンバー」と大小の両バージョンナン
バーとを使ってステップ１７２８で作成される。データ
ストアバージョン構造、つまりレコードは、データスト
アの特殊バージョンに関係する情報を提供する。或る実
施例では、データストアの特殊バージョンは、データス
トアが最後にアクセスまたは修正された時に関係するか
もしれない。データストアバージョンレコードを使っ
て、データストアとして現在使用中のファイルが実際に
有効なデータストアか否かを決定することができる。マ
ジックナンバーはハードワイヤード(hard-wired)ナンバ
ーまたはその他の一定の記述で、特殊なタイプのデータ
ファイルの特徴を示すために使用される。例として、記
号「％！」で始まるファイルは、通常、ポストスクリプ
トファイルと理解される。同様の慣行が他の多くのファ
イルタイプに対して使用される。バージョンナンバー
は、しばしば、２つのコンポーネント、例えば大バージ
ョンナンバーと、小バージョンナンバーとを使用して表
現される。大小のバージョンナンバーの正確な解釈はア
プリケーション固有のものだが、大小のバージョンナン
バーは、一般に、バージョン間の差の程度を反映するよ
うに設計されている。

【００８８】データストアバージョン構造が作成された
後、データストアバージョン構造はステップ１７３０で
ＣＤＲマーシャルバッファにマーシャルされる。記載の
実施例では、データストアバージョンレコードは、ＣＤ
Ｒマーシャルバッファによって表されるファイルＸ．Ｎ
ＥＷに直接マーシャルされる。大部分の通常ケースで
は、データがファイルに直接マーシャルされないことを
よく理解しなければならない。ステップ１７３２におい
て、ルートオブジェクトがＣＤＲマーシャルバッファに
マーシャルされる。すなわち、データストアは、ファイ
ルＸ．ＮＥＷを表すＣＤＲマーシャルバッファにマーシ
ャルされる。記載の実施例では、ＩＤＬ生成マーシャリ
ング関数がマーシャルバッファを使って、より原始的な
データタイプの用語でＩＤＬ定義データタイプをマーシ
ャルする。最後に、ファイルＸ．ＮＥＷがステップ１７
３４で閉じられて、ファイルＸ．ＮＥＷへのＳＰＯ＿Ｄ
Ｂ：：Ｒｏｏｔクラスのインスタンスをストリング(str
ing)するプロセスがステップ１７３６で終了する。

【００８９】図４に関して先に説明したように、本発明
の不変データ記憶メカニズムは、「接続可能な(pluggab
le) バックエンド」、すなわち異なるデータストアを不
変フレームワークと共に使用できるようにするインタフ
ェース、を持つ。サブコントラクトは、対応するバック
エンド表示、すなわちデータストア、に対してオブジェ
クトレファレンスを関連させるために使用されるインタ
フェースの一部として利用される。接続可能なバックエ
ンドを持つ不変データ記憶メカニズムはフレキシブルだ
が、それは、所定の不変フレームワークと共に様々なバ
ックエンド表示が使用できるからである。接続可能バッ
クエンドはデータストアの作成とオープンのために使用
される関数を含むデータ構造、例えばデータストアイン
プリメンテーションのレジストリであるデータ構造を利
用できる。というのは、データストアは、適切なデータ
ストアの作成やオープニングのための適切なメカニズム
に写像(map) する識別子に関連する必要があるからであ
る。

【００９０】図２１は、本発明の一実施例による、デー
タストア実装レジストリであるデータ構造の概略表示で
ある。データストア実装レジストリ１８０２は、データ
ストアの作成とオープニングに使用される情報を収容す
る。データストア実装レジストリ１８０２と、図１５に
関して上述したデータストアレジストリとは同一である
ことをよく理解しなければならない。データストア実装
レジストリ１８０２がデータストアの作成とオープンに
使用される情報を含むのに対して、データストアレジス
トリは、現時点で存在するデータストアのリストを含
む。データストア実装レジストリ１８０２は、特殊なデ
ータストアインプリメンテーションを発見するために使
用され、次に、そのインプリメンテーションを使って、
特殊なデータストアを作成するかオープンするための適
切な関数がコールされる。

【００９１】データストア実装レジストリ１８０２は、
通常、キー１８０４、データストアの作成に用いられる
関数１８０６、およびデータストアのオープニングに用
いられる関数１８０８のリストを含む。キー１８０４
は、通常、データストアインプリメンテーションに関連
するタイプの識別に役立つストリングである。すなわ
ち、キー１８０４は、通常、所定のインプリメンテーシ
ョンに用いられるメカニズムの名前を提供する。幾つか
の実施例では、キー１８０４は、ＵＮＩＸｄｂｍが利用
される場合、ＵＮＩＸデータベースマネジャ（ｄｂｍ）
に対応する名前である。データストア作成関数１８０６
は、データストア識別子であるストリングを引数と見做
す。データストア識別子はデータストア用のファイル名
でもよいし、リレーショナルデータベース識別子でもよ
い。データストア開関数１８０８は、データストア作成
関数１８０６と同様、データストア識別子であるストリ
ングを引数と見做す。データストア開関数１８０８の一
つのバージョンは、図１０に関して先に説明した。デー
タストア作成関数１８０６とデータストア開関数１８０
８は、それぞれ、任意数の引数を取り、データストア識
別子である引数に限定されないことをよく理解しなけれ
ばならない。例として、キー１８０４はそれらの関数の
一方または両方に対する引数になることができる。

【００９２】データストア作成関数１８０６を用いて、
データストアに関係する情報を収容するファイルを開く
（作成するのではない）場合、データストア作成関数１
８０６はそのファイルを置き換える。言い換えると、デ
ータストア作成関数１８０６は、すでに存在するファイ
ルを開くために使うことはできない。というのは、デー
タストア作成関数１８０６はその代わりに同じ名前を持
つ新ファイルを作成するからである。データストア開関
数１８０８の用途は、データストアに関係する情報を収
容するファイルがすでに存在している場合に使用され
る。存在しない(non-existent)ファイルを開けようとし
てデータストア開関数１８０８を使用した場合、その試
みは失敗するだろう。或る実施例では、データストア作
成関数１８０６とデータストア開関数１８０８とは単一
の関数に合併できることをよく理解しなければならな
い。しかしながら、便宜と明快さのために、データスト
ア作成関数１８０６とデータストア開関数１８０８と
は、通常、独立の関数である。

【００９３】データストア作成関数１８０６またはデー
タストア開関数１８０８のいずれかを使用することは、
図４に関して説明したＮＥＯ＿ＳＰＯ＿ＤＢクラスのイ
ンスタンスの作成に役立つ。ＮＥＯ＿ＳＰＯ＿ＤＢクラ
スに関係する静的クリエートアンドオープン関数を使用
してオブジェクトを作成するとき、オブジェクトはＮＥ
Ｏ＿ＳＰＯ＿Ｏｂｊｅｃｔクラスのインスタンスを表す
が、これについても図２に関して先に説明した。接続可
能なバックエンドも、ＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿ＤＢ
とＮＥＯ＿Ｒｅａｌ＿ＳＰＯ＿Ｏｂｊに似た新しいクラ
スを定義する。このようなクラスのインスタンスは、い
ずれも、図２の矢印２２１と２１１で示される相続関係
によって、それぞれＮＥＯ＿ＳＰＯ＿ＤＢまたはＮＥＯ
＿ＳＰＯ＿Ｏｂｊのインスタンスである。

【００９４】本発明の実施例を一つだけ説明したが、本
発明は、その精神と範囲から逸脱することなく、他の多
くの形式で具体化し得ることは言うまでもない。記載の
実施例では、オブジェクト識別子データ構造の一構成の
みを説明したが、オブジェクト識別子データ構造が本発
明の範囲内で幅広い変化が可能なことは明らかであろ
う。同様に、データストアの構造も幅広く変化する。更
に、データストアからのデータ読取りとデータストアへ
のデータ書込をコールするメソッドやデータストアを作
成、付託するメソッドに伴うステップは再構成が可能で
ある。これらのステップも、本発明の精神と範囲から逸
脱することなく追加、除去することができる。従って、
記載の実施例は説明のためであって、限定のためではな
いと見做すべきであり、本発明は下記クレームならびに
それらに相当する仕様によって定義されるものとする。

【図面の簡単な説明】

【図１】本発明による分散オブジェクトシステムの実装
に適したコンピュータネットワークの説明図である。

【図２】図１に示されるコンピュータの主要コンポーネ
ントの概略説明図である。

【図３】本発明による、分散オブジェクトシステムの象
徴的概要図である。

【図４】本発明の一実施例による、オブジェクトモデル
化技術（ＯＭＴ）のクラス図表の概略表示図である。

【図５】本発明の一実施例による、不変オブジェクトフ
レームワークにおけるデータの読取りと書込に関連する
ステップを説明するプロセス流れ図である。

【図６】本発明の一実施例による、図３のステップ３１
４を説明するプロセス流れ図である。

【図７】本発明の一実施例による、不変オブジェクトフ
レームワークにおいて使用されるデータストア構造の概
略表示図である。

【図８】本発明の一実施例による、図６のステップ４０
８を説明するプロセス流れ図である。

【図９】本発明の一実施例による、図５のステップ３２
０および図６のステップ４０４を説明するプロセス流れ
図である。

【図１０】本発明の一実施例による、データストアのオ
ープニングに関連するステップを説明するプロセス流れ
図である。

【図１１】本発明の一実施例による、図８のステップ８
０３に関連するステップを説明するプロセス流れ図であ
る。

【図１２】本発明の一実施例による、オブジェクト識別
子（ＯＩＤ）の概略表示図である。

【図１３】本発明の一実施例による、オブジェクトレフ
ァレンスに関連するオブジェクトレファレンスとエレメ
ントの概略表示図である。

【図１４】本発明の一実施例による、マーシャリングプ
ロセスに関連するステップを説明するプロセス流れ図で
ある。

【図１５】本発明の一実施例による、アンマーシャリン
グプロセスに関連するステップを説明するプロセス流れ
図である。

【図１６】本発明の一実施例による、オブジェクト作成
プロセスに関連するステップを説明するプロセス流れ図
である。

【図１７】本発明の一実施例による、図１４のステップ
１４０４を説明するプロセス流れ図である。

【図１８】本発明の一実施例による、オブジェクトを破
壊するためのプロセスに関連するステップを説明するプ
ロセス流れ図である。

【図１９】本発明の一実施例による、付託プロセスに関
連するステップを説明するプロセス流れ図である。

【図２０】本発明の一実施例による、図１７Ａのステッ
プ１７０４を説明するプロセス流れ図である。

【図２１】本発明の一実施例による、データストア実装
レジストリの概略表示図である。

Claims (28)

【特許請求の範囲】
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. 【請求項２８】 該データストアが、該データストア内
    に収容されたルートオブジェクトクラスと該不変データ
    記憶メカニズムの間の相続関係を含む少なくとも一つの
    相続関係を介して、該不変データ記憶メカニズムと連結
    されている、請求項２７に記載のコンピュータシステ
    ム。