(57)【特許請求の範囲】
【請求項１】
以下の(a)から(g)を設け複数のオブジェクト・モデルをサポートするオブジェクト指向分散コンピューティング・システムにおけるオブジェクト指向分散コンピューティング方法であって、
(a) 第１のコンピュータ；
(b) 第２のコンピュータ；
(c) 前記第１のコンピュータに設けられたオブジェクト・マネージャのマネージャ；
(d) 前記第２のコンピュータに設けられたオブジェクト・マネージャのマネージャ；
(e) 前記第１のコンピュータに設けられ、それぞれが異なるオブジェクト・モデルに基づいた複数のオブジェクト・マネージャ；
(f) 前記第２のコンピュータに設けられ、オブジェクト・モデルに基づいた少なくとも１つのオブジェクト・マネージャ；
(g) 以下の特徴(g-1)から(g-4)を有し、永続状態及び実行モデルを含み、１つのオブジェクト・モデルに基づく複数のオブジェクト：
(g-1) 当該オブジェクトは前記システム内での呼び出しを行うことにより、操作のリクエストを別のオブジェクト・モデルに基づくオブジェクトへ伝える；
(g-2) 前記リクエストの各々は以下の(g-2-1)及び(g-2-2)を含む：
(g-2-1) 対象となるオブジェクトを示すオブジェクト識別子；
(g-2-2) 前記対象となるオブジェクトに実行することを求める操作の指示；
(g-3) 前記オブジェクト・マネージャの各々は、当該オブジェクト・マネージャのオブジェクト・モデルに従って当該オブジェクト・モデルに関連付けられたオブジェクトの操作及び存在の態様を管理する；
(g-4) 前記オブジェクト・マネージャのマネージャの各々は、前記リクエストが伝えられるべきオブジェクトを突き止めるために、前記オブジェクト・マネージャのオブジェクト・モデルの夫々の操作の呼び出しに当たって予めプログラムされたコードが不要な態様で、関連する前記オブジェクト・マネージャの夫々と通信する；
前記複数のオブジェクト・モデルの各々は、
当該オブジェクト・モデルに基づくオブジェクトの永続状態の管理の態様及び
当該オブジェクト・モデルに基づくオブジェクトに対する操作を当該操作を実行するコードへ対応付ける態様である実行モデル
によって定義される
とともに、
前記第１のコンピュータ上の前記複数のオブジェクト・マネージャのうちの第１のオブジェクト・マネージャによって管理されている第１のオブジェクトによって発行されたリクエストが、
前記第１のコンピュータ上の前記複数のオブジェクトのうちの第２のオブジェクト・マネージャによって管理されている第２のオブジェクト上で操作を行うことを求める第１のリクエストである場合には、以下の(A)から(C)のステップを行い、
前記第２のコンピュータ上の前記複数のオブジェクトのうちの第３のオブジェクト・マネージャによって管理されている第３のオブジェクト上で操作を行うことを求める第２のリクエストである場合には、以下の(D)から(F)のステップを行う
ことを特徴とするオブジェクト指向分散コンピューティング方法：
(A) 前記第１のリクエストが前記第１のオブジェクトから前記第１のコンピュータ上の前記オブジェクト・マネージャのマネージャに伝えられ、次に前記第２のオブジェクト・マネージャに伝えられる；
(B) 前記第１のコンピュータ上の前記オブジェクト・マネージャのマネージャは、前記第１のオブジェクトの前記第１のリクエストに応答して、以下の(B-1)及び(B-2)を行う：
(B-1) 前記第２のオブジェクトに対するオブジェクト識別子に応答するが前記第２のオブジェクトのタイプ及び前記第２のオブジェクト・マネージャのオブジェクト・モデルからは独立に、前記第２のオブジェクトが前記第２のオブジェクト・マネージャによって管理されているか否かを判定する；
(B-2) 前記第１のリクエストを前記第２のオブジェクト・マネージャに伝える；
(C) 前記第２のオブジェクト・マネージャは、前記第１のリクエストを受け取ると、自分のオブジェクト・モデルに従って、前記第２のオブジェクトの前記永続状態及び実行モデルを獲得し、前記第２のオブジェクトをアクティブにして前記第１のリクエストを前記第２のオブジェクトに渡す；
(D) 前記第２のリクエストが前記第１のオブジェクトから前記第２のコンピュータ上の前記オブジェクト・マネージャのマネージャに伝えられ、次に前記第３のオブジェクト・マネージャに伝えられる；
(E) 前記第２のコンピュータ上の前記オブジェクト・マネージャのマネージャは、前記第１のオブジェクトの前記第２のリクエストに応答して、以下の(E-1)及び(E-2)を行う：
(E-1) 前記第３のオブジェクトに対するオブジェクト識別子に応答するが前記第３のオブジェクトのタイプ及び前記第３のオブジェクト・マネージャのオブジェクト・モデルからは独立に、前記第３のオブジェクトが前記第３のオブジェクト・マネージャによって管理されているか否かを判定する；
(E-2) 前記第２のリクエストを前記第３のオブジェクト・マネージャに伝える；
(F) 前記第３のオブジェクト・マネージャは、前記第２のリクエストを受け取ると、自分のオブジェクト・モデルに従って、前記第３のオブジェクトの前記永続状態及び実行モデルを獲得し、前記第３のオブジェクトをアクティブにして前記第２のリクエストを前記第２のオブジェクトに渡す。
【請求項２】
前記オブジェクト・マネージャのマネージャの各々は、共通のインターフェイスを使用して、同一コンピュータ上に存在する前記オブジェクト・マネージャの各々と通信することを特徴とする請求項１に記載のオブジェクト指向分散コンピューティング方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明はオブジェクト指向コンピューティング・システムに関する。
【０００２】
【従来技術及びその問題点】
「分散コンピューティング（ｄｉｓｔｒｉｂｕｔｅｄ  ｃｏｍｐｕｔｉｎｇ）」はコンピュータ処理の分野において周知の概念である。基本的に、分散コンピューティングを用いることにより、コンピュータ・ネットワーク中のさまざまなコンピュータのプロセス間で通信し、互いにサービスを提供することができる。ネットワーク内の複数のコンピュータは別々のマシン・アーキテクチャやオペレーティング・システムであってもよい。
【０００３】
分散コンピューティングの最も一般的なパラダイムは「クライアント・サーバ・モデル」として知られている。サービスの消費者すなわちクライアントはサービスの提供者すなわちサーバにリクエストを行う。
【０００４】
クライアント・サーバ分散コンピューティングにはさまざまな欠点がある。例えば、現在のシステムでは、使用したいサーバのロケーションを明示的に捕捉する（すなわち「知る」）ようにクライアントのプロセスをコーディングする必要がある。更に、クライアントがサーバを使用している間にそのサーバが自分のロケーションを変化させるならば、サーバのロケーションを再度見い出すようにクライアントのプロセスをコードディングしなければならない。こうした再度のロケーション探索を行わなければ、クライアントはサーバと通信しようとしても失敗してしまう。
【０００５】
ほとんどのシステムでは、クライアントがサーバを使用しようとする前に、そのサーバがアクティブでなければならない。クライアントがアクティブでないサーバを使用しようとすると、必要なサービスを得ようしても失敗してしまう。
【０００６】
別の分散コンピューティング・システムは「オブジェクト」と呼ばれるコンピュータ・プログラミング・エンティティの概念を持たないか、あるいはシステムが命じる特定のオブジェクト・モデルに適合するオブジェクトを必要とする。どのシステムにも少なくとも１つのオブジェクト・モデルが存在するが、システム全体に共通したモデルは存在しないので、こうした分散コンピューティング・システムは不必要に制限がきつい。すなわちこうした分散形システムは新しいテクノロジーを取り入れ、システムの当初の設計対象ではなかった問題領域にまで拡張する能力が制限されている。
【０００７】
本願明細書で用いられているように、「オブジェクト」とはある状態及び定義された挙動の集合を持つプログラミング・エンティティである。状態はオブジェクトが保持するデータによって表される。挙動はオブジェクトが実行できる操作として指定される。この操作は実行可能コードによって実現される。これらのデータとコードは、概念上、オブジェクト中で分離不能に結びついている。オブジェクトは「永続的（ｐｅｒｓｉｓｔｅｎｔ）」であってよい。すなわちオブジェクトが非アクティブであっても、あるいはそれが存在するコンピュータが故障またはオフになったとしても存続し続けることができる。更に、オブジェクトは他のオブジェクトに対してサービスを要求しまたサービスの提供も行うこともできる。
【０００８】
本願明細書で用いられているように、「クラス」はオブジェクトのタイプを表し、それがどんな種類のオブジェクトであるかを指定する。例えば、ＧａｒｆｉｅｌｄとＳｎｏｏｐｙは別個の「オブジェクト」であるが、両方とも「漫画のキャラクタ」である。「漫画のキャラクタ」は両者のクラスである。異なる種類のエンティティ、例えば世界貿易センタは異なるクラスである（この場合のクラスはおそらく「ビルディング」）。
【０００９】
本願明細書で用いられているように、「オブジェクト・マネージャ」は各オブジェクトのグループ分けを管理し、これらの存在及び操作をサポートするエンティティである。
【００１０】
また、本願明細書で用いられるように、「オブジェクト・モデル」は特定のクラスのオブジェクト・マネージャが実行する活動及びその実行の方法の抽象（ａｂｓｔｒａｃｔｉｏｎ）である。これらの活動には、
（ｉ）オブジェクトの永続状態の管理、
（ｉｉ）オブジェクトに対する操作をコードへマッピングすること
が含まれる。
【００１１】
以上述べたことから、分散コンピューティングを改良することが必要とされる。
【００１２】
【目的】
本発明は先行技術の問題を解決する分散コンピューティング・システムを提供することを目的とする。とりわけ、本発明は他の分散コンピューティング・システムとは異なり、サービスを求めるクライアントが、サービス提供側のロケーションを知る、すなわち捕捉するようにコーディングされる必要がない分散コンピューティング・システムを提供することを目的とする。更に、本システムは、他のオブジェクト指向コンピューティング・システムと異なり、多様なオブジェクト・モデルに適合するオブジェクトを認識する。
【００１３】
【概要】
本発明の一実施例によれば、オブジェクト指向分散コンピューティング・システムのための管理装置が提供される。この管理装置はリクエストを出しているオブジェクトまたはプロセス（すなわちリクエスト元）に代わって、システム内の望まれているオブジェクトがどこにあるかを見い出すロケーション・サービスを採用している。リクエスト元はロケーション・サービスを（ましてロケーション・サービスの詳細を）認識するようにコーディングされている必要はない。
【００１４】
もっと具体的に言えば、リクエスト元がサービスを提供するオブジェクトすなわち「ターゲット・オブジェクト」にリクエストを出すと、自動的にロケーション・サービスに連絡が付けられる。望ましい実施例では、ロケーション・サービスを呼び出す処理手段を自動的に生成されたスタブ内に設けている。更に、各オブジェクトがシステム内で固有のアイデンティティを持って場合、ロケーション・サービスはオブジェクトのアイデンティティに基づいてオブジェクトのロケーションを見つけ出す。この固有のアイデンティティによって、当該オブジェクトがそこで生成されたコンピュータの識別情報をコード化している。
【００１５】
ロケーション・サービスはシステム内の各種エンティティから構成されている。それぞれが自分に関連付けられたオブジェクトの存在及び操作をサポートするいくつかのオブジェクト・マネージャがある。また、それぞれがオブジェクト・マネージャのグループ分けを管理するオブジェクト・マネージャのマネージャ（ＭＯＭ）がいくつかある。更に、それぞれ、システム内のコンピュータについてオブジェクトのロケーションを掌握しているオブジェクト領域マネージャがいくつか設けられている。コンピュータの各種のグループの各々に付いて、別個のオブジェクト領域が定義され、各領域は自分用のオブジェクト領域マネージャを持っている。コンピュータとオブジェクト領域マネージャの間のマッピングを行うため、ロケーション・サービスはマッピング手段を用いる。
【００１６】
本発明の一態様によれば、オブジェクト・マネージャ、ＭＯＭ、オブジェクト領域マネージャ及びマッピング手段とのまたこれらの間での通信ができるようにする共通手段を設けることができるようにする共通の一般インターフェイス（ｃｏｍｍｏｎ  ｇｅｎｅｒｉｃ  ｉｎｔｅｒｆａｃｅ）が採用される。
【００１７】
更に、いくつかあるオブジェクト・マネージャは各々のオブジェクト・モデルに基づいている。あるオブジェクト・モデルに基づくオブジェクト・マネージャに対応するオブジェクトは、別のオブジェクト・モデルに基づく別個のオブジェクト・マネージャに対応するオブジェクトに対してリクエストを送信することができる。
【００１８】
更に、ある実施例では、いくつかのオブジェクト・マネージャの共通のＭＯＭが管理しているオブジェクト・マネージャにより、このＭＯＭがオブジェクト・マネージャの具体的なオブジェクト・モデルに付いて明確な知識を持っていない状態でそのようなオブジェクト・マネージャの各々と通信できるようにサポートされる一般的なインターフェイスが存在する。
【００１９】
各オブジェクト・マネージャは、好ましくは自分に関連付られたいくつかのオブジェクト・グループをそれぞれ等価なクラスとして取り扱う。このようにするため、オブジェクト・マネージャはオブジェクト−プロセス対応関係を、個別的にではなくグループとして掌握している。更に、オブジェクト・マネージャはシステムが資源を必要とすることに自動的に応答してプロセスを非アクティブにするのが望ましい。
【００２０】
本発明のもう１つの態様によれば、管理装置は、更にリクエスト時点でのターゲット・オブジェクトとプロセスの関連には関係なく、ターゲット・オブジェクトに対するリクエストのサービスを行う手段を採用している。このようにするため、リクエスト時点で所与のターゲット・オブジェクトがプロセスに関連付られていなくても、システム内の全てのオブジェクトがリクエストの処理に使用できるように見える。
【００２１】
これを言い方を変えてみれば、本発明のオブジェクト指向分散コンピューティング・システムは、システムの複数のプロセスの１つの中に、ターゲット・オブジェクトの操作及びデータを、当該ターゲット・オブジェクトに対するリクエストに応答して実現するコンピュータ手段を提供する。その結果、各オブジェクトの可用性はリクエスト時点での当該オブジェクトとプロセスの関連付けに関係なく定義される。
【００２２】
【実施例】
図１及び図２は本発明の一実施例であるオブジェクト指向コンピューティング・システム１１を示す。システム１１はネットワークを形成する複数の疎結合されたコンピュータ３７ａ、３７ｂ・・・から構成される。各コンピュータ３７上には、各種オブジェクト１３ａ、１３ｂ、１３ｃ・・・が各々の操作を実行する１つあるいは複数のプロセス３９が存在して良い。図１のオブジェクト１３ａ、１３ｂはオブジェクト指向分散コンピューティング・システム１１を定義する同一のあるいは別々のコンピュータ３７上の同一のあるいは別々のプロセス３９上にある。
【００２３】
システム１１の核心には本発明のオブジェクト／プロセス管理装置１５がある。概括すると、オブジェクト／プロセス管理装置１５は以下のオブジエクト挙動を取り扱う：
（１）システム１１中の全ての既存のオブジェクト１３を登録する。
（２）オブジェクト１３ａが他のオブジェクト１３ｂ（両オブジェクトは別々のアドレス空間及び／または別々のコンピュータ中にある可能性がある）にリクエストを出せるようにする。
（３）リクエストを送り届け、その実行を管理する。
オブジェクト／プロセス管理装置１５は、オブジェクト１３が他のオブジェクトにリクエストを出す前にこれらのオブジェクトをまとめたりリンクすることは要しない。オブジェクト１３は、システム中の他のオブジェクト１３に対する参照情報を持っていれば、そのオブジェクトに対してリクエストを出すことができる。
【００２４】
更に、本発明のオブジェクト／プロセス管理装置１５は、システム１１中のいくつかのプロセスにいくつかのオブジェクト１３を分散することをサポートする。オブジェクトやプロセスはネットワーク中の他のコンピュータのオブジェクトにリクエストを出すことができる。リクエストを出すオブジェクトまたはプロセス（すなわちリクエスト側あるいはクライアント）は、どのコンピュータでターゲット・オブジェクトを発見できるかについて知る必要はないし、増してや、ターゲット・オブジェクトが別のコンピュータ中にあるのかどうかということさえ知る必要がない。本発明のオブジェクト／プロセス管理装置１５は、ロケーション・サービスに対するクライアントの呼び出しを人間が明示的にコーディングせずに、クライアントに代わって、自動的にターゲット・オブジェクトのロケーションを判定する（後述する）。ローカル・エリア・ネットワーク（ＬＡＮ）のような同報通信ネットワーク（ｂｒｏａｄｃａｓｔｉｎｇ  ｎｅｔｗｏｒｋ）や、多くの広域ネットワーク（ＷＡＮ）のような接続指向ネッワトーク（ｃｏｎｎｅｃｔｉｏｎ−ｏｒｉｅｎｔｅｄ  ｎｅｔｗｏｒｋ）を含む各種ネットワークをサポートすることができる。
【００２５】
更に、オブジェクト／プロセス管理装置１５は異質性（ｈｅｔｅｒｏｇｅｎｅｉｔｙ）をサポートする。ネットワーク中にさまざまなタイプのコンピュータを混合することが可能である。本発明のオブジェクト／プロセス管理装置１５は、リクエストを出すオブジェクト（送信側）を含むコンピュータと、リクエストを実行するオブジェクト（受信側）を含むコンピュータとの相違にかんする面倒を見る。２つのコンピュータがデータの表現を異にするプロセッサを備えている場合、よくある問題が起こる。例えば、  Ｍｏｔｏｒｏｌａ  ６８ＸＸＸ  シリーズとＩｎｔｅｌ  ８０ＸＸＸ  シリーズは整数を異なる形式でメモリに記憶する。本発明のオブジェクト／プロセス管理装置１５は、必要な場合、２つのコンピュータのフォーマット間でリクエストのパラメータ変換を管理する。
【００２６】
本発明のオブジェクト／プロセス管理装置１５はまた、多重のユーザ・セッションを同時にサポートする。オブジェクト／プロセス管理装置１５は、パーソナル・コンピュータまたは単一のユーザ・ワークステーションといった単一ユーザ・コンピュータ上でのオブジェクトを管理できる。同様に、オブジェクト／プロセス管理装置１５はマルチユーザ・コンピュータ上でのオブジェクトを管理できる。オブジェクト／プロセス管理装置１５が管理するオブジェクトは何人かの異なるユーザのために同時にサービスを行なうことができる。オブジェクト／プロセス管理装置１５は、許されていないサービスの使用を防ぐための機密保護メカニズムも持っている。
【００２７】
更に、オブジェクト／プロセス管理装置１５は規模の拡大／縮小が可能である。コンピュータ・ネットワークにおいて、各コンピュータは本発明のオブジェクト／プロセス管理装置１５を具現化したものを実行している。ロー・エンド側では、オブジェクト／プロセス管理装置１５は独立した単一のユーザ・コンピュータで効率的に機能することができる。ハイ・エンド側では、オブジェクト／プロセス管理装置１５は多国籍の大企業の全コンピュータを含むネットワーク全体の中での各マシン上で効率的に動作することができる。
【００２８】
上記を達成するため、本発明のオブジェクト／プロセス管理装置１５は２層構造を有している。下位側の層は、オブジェクト１３間でリクエストを発行し配送するための均一なメカニズムを提供する通信サービス１９から形成される。通信サービス層１９は、とりわけ、リクエスト元オブジェクトとターゲット・オブジェクトが異なる種類のコンピュータである場合にデータ表現の変換を行うことによって、オブジェクト間でのリクエストの配送ができるようにする。また、オブジェクトに対する許可されていないアクセスを防止するために、機密保護メカニズムも設けられている。通信サービス１９は、また、異なるネットワーク・トポロジ、プロトコル及びソフトウエアの影響から、オブジェクト／プロセス管理装置１５及びオブジェクト１３の残りの部分を隔離する。
【００２９】
オブジェクト／プロセス管理装置１５の上位側の層はオブジェクト・マネージャ２３、２５を含むオブジェクト管理サービス１７及びロケーション・サービス２１から形成されている。オブジェクト・マネージャ２３、２５はオブジェクトをアクティブ／非アクティブにすることや、オブジェクト・クラスのインストールといったサービスを提供する。ロケーション・サービス２１はオブジェクト／プロセス管理装置が特定のオブジェクト１３への通信経路を決定できるようにする。従って、オブジェクト管理サービス層１７はオブジェクトのライフ・サイクル（生成、インストール及び削除）及びロケーションを管理する。
【００３０】
望ましい実施例では、通信サービス１９及びオブジェクト管理サービス１７は、図２に示すライタイム（ｒｕｎｔｉｍｅ）ライブラリ２７、オブジェクト・マネージャ２３、オブジェクト・マネージャのマネージャ（ＭＯＭ）２９及びロケーション・サービス２１によって実現される。ランタイム・ライブラリ２７はコンピューティング・システム１１が管理しているオブジェクト１３のアドレス空間に入っており、オブジェクト全体の一部とみなすことができる。ランタイム・ライブラリ２７はコンピューティング・システム１１内での通信に当たって全オブジェクトによって使用される基本インターフェイスを提供する。ランタイム・ライブラリ２７には、永続記憶マネージャ（ｐｅｒｓｉｓｔｅｎｔ  ｓｔｏｒａｇｅ  ｍａｎａｇｅｒ）（後述する）との通信を可能にするコード及びロケーション・サービス２１によって用いられるオブジェクト参照（ｏｂｊｅｃｔ  ｒｅｆｅｒｅｎｃｅ）の生成を可能にするコードが含まれている。
【００３１】
オブジェクト・マネージャ２３には、オブジェクト１３を直接管理し、オブジェクトの存在の態様を管理したり（つまり、オブジェクトをアクティブにしたりまた非アクティブにしたりすること）、メッセージをオブジェクトに配送し、これらのオブジェクトの活動にとっていったいどんな状態が必要とされるのかを常時掌握しておくことを担当する。そのため、各オブジェクト１３とオブジェクト・マネージャ２３は、複数の異なるオブジェクトが異なるオブジェクト・マネージャによって管理されるように関係付けられている。本発明では、オブジェクト／プロセス管理装置１５に少なくとも１つのデフォルト・オブジェクト指向コンピューティング・システム・マネージャ２５を設ける。デフォルト・オブジェクト・マネージャ２５の最小サブセットの操作インターフェイスが、他の全てのオブジェクト・マネージャ２３が提供しなければならないサービスを定義する。これらのインターフェイス及びＭＯＭ２９によって使用される共通の一般インターフェイス（後述する）の後に引き続いて、新しいオブジェクト・マネージャを追加することが可能である。
【００３２】
各オブジェクト・マネージャ２３はＭＯＭ２９に関連付けられている。また、デフォルト・オブジェクト・マネージャ２５もこのようなＭＯＭ２９に関連付けられている。各ＭＯＭ２９は当該ＭＯＭが管理しているオブジェクト・マネージャ２３と関連付けられたオブジェクト１３に向けられたメッセージを受信することを担当している。各ＭＯＭ２９は所与のオブジェクトが関連付けられているオブジェクト・マネージャ２３を見つけ出すことを担当しており、従ってＭＯＭ２９はリクエストに関するローカルな情報センタの働きをする。言い方を変えれば、ＭＯＭ２９はＭＯＭ２９によって管理されている（関連付けられている）オブジェクト・マネージャ２３の管理下にあるいずれかのオブジェクトに向けて送られてくるリクエストのための既知の受信点として設計されている。
【００３３】
ロケーション・サービス２１はオブジェクト指向分散コンピューティング・システム１１内の任意のオブジェクト１３の現在のロケーションを見い出すことを担当している。これらのサービス２１はシステムによって自動的に用いられ、システム１１内でアプリケーションを書いているプログラマ、またはシステム１１内でオブジェクト１３を使用しているユーザに対しては完全に隠されている。すなわち本発明は、ターゲット・オブジェクトに対するリクエストに応答し、リクエスト元オブジェクト（またはプロセス）のためにロケーション・サービス２１を自動的に呼び出す処理手段を提供する。その結果、リクエスト元オブジェクト（またはプロセス）は、先行技術において必要とされたように、ロケーション・サービス２１を呼び出すように明示的にコーディングしておく必要がない。
【００３４】
ランタイム・ライブラリ及びＭＯＭ２９はオブジェクト／プロセス管理装置１５の通信サービス層１９とオブジェクト管理層の両方で機能する。通信サービス層１９では、ランタイム・ライブラリ２７は１つのオブジェクト１３からもう１つのオブジェクトへメッセージを送る処理を行い、ＭＯＭ２９は最下位レベルのオブジェクト・ロケーション・サービスとしての働きをする。オブジェクト管理サービス層１７では、ランタイム・ライブラリ２７は、オブジェクト・マネージャの２３の集合と共に、主としてオブジェクトのライフ・サイクルを取り扱う。
【００３５】
オブジェクト１３の視点に立つと、通信は層１７、１９のランタイム部分によって行われる。ライタイム２７は、ロケーション・サービス２１と連絡を取ってターゲット・オブジェクト１３ｂを見つけ出し、次に述べるように、オブジェクト１３ａからオブジェクト１３ｂにメッセージを送る。注目されるのは、ロケーション・サービス２１がシステム１１全体の中のある１つまたは複数のコンピュータ上で実行される。しかし、オブジェクト１３の観点からすると、サービス２１はどの特定のコンピュータ３７にも配置されているわけではない。従って、図１及び図２には、存在はしているが特定のマシン３７上には配置されてはいないサービス２１を示している。
【００３６】
図２を参照すると、ロケーション・サービス２１は構成要素の階層を採用している。前述のように、オブジェクト１３ａ、１３ｂ、１３ｃ、１３ｄ・・・は同じコンピュータまたは異なるコンピュータ３７上の１つまたは複数のプロセス中で動作している。複数のオブジェクトつまりオブジェクト・グループがオブジェクト１３の管理を担当するオブジェクト・マネージャ２３に関連付けられている。これら複数個のオブジェクト・マネージャ２３もグループ分けされ、ＭＯＭ２９と関連付けられる。各オブジェクト・マネージャ２３はそれぞれのオブジェクト・モデルに基づいており、システム１１は任意の数のオブジェクト・モデルが含まれている。異なるオブジェクト・モデルのオブジェクト・マネージャ２３は後述の一般インターフェイスを用いて共通のＭＯＭ２９によって管理することができる。更に、オブジェクト・モデルの１つに基づくオブジェクト・マネージャ２３に関連付けられたオブジェクトは、更に詳細に後述するように、異なるオブジェクト・モデルに基づく別のオブジェクト・マネージャに関連付けられたオブジェクトにリクエストを送ることができる。
【００３７】
更に、各ＭＯＭ２９は、以下で述べるように、オブジェクト領域マネージャ３１に関連付けられている。異なるオブジェクト領域は、管理目的のためにグループとされているコンピュータ３７の集合によって定義される。各オブジェクト領域毎にオブジェクト領域マネージャ３１がある。オブジェクト領域マネージャ３１の役割は、ターゲット・オブジェクト１３ｂについて知っているかもしれないＭＯＭの（空であるかもしれない）集合へオブジェクト参照をマッピングすることである。オブジェクト領域マネージャ３１は、単一のデータ・ベース及びこのデータ・ベースに対する照会と操作ができるようにするプロセスの集合から構成される。可用性（ａｖａｉｌａｂｉｌｉｔｙ）を高くするため、オブジェクト領域内において、論理的に単一のオブジェクト領域マネージャ３１を複製する（ｒｅｐｌｉｃａｔｅ）ことが望ましい。各オブジェクト領域は自分自身の固有のオブジェクト領域マネージャ３１を持っている。
【００３８】
ロケーション・サービス２１の構成要素の階層の次のレベルは、メタ・オブジェクト領域マネージャ３３である。これらのマネージャは、オブジェクト参照をそのオブジェクトについて知っている適切なオブジェクト領域マネージャ３１の識別子にマッピングする。個々のメタ・オブジェクト領域マネージャ３３は、オブジェクト領域間でオブジェクト１３のロケーションを見い出すことができるように、互いに通信する。オブジェクト領域マネージャ３１と同様、各オブジェクト領域マネージャ３３は、単一のデータ・ベースと、このデータ・ベースに対する照会及び操作を行うプロセスの集合を有している。論理的に単一の各メタ・オブジェクト領域マネージャ３３は複製してもよい。各システムは自分自身の固有のメタ・オブジェクト領域マネージャ３１を持っている。
【００３９】
階層の末端のレベルには、２つあるいはもっと多くの固有のメタ・オブジェクト領域マネージャ３３のリストを維持している同胞メタ・オブジェクト領域マネージャ（ｓｉｂｌｉｎｇ  ｍｅｔａ  ｏｂｊｅｃｔ  ｒｅｇｉｏｎ  ｍａｎａｇｅｒ）３５がある。
【００４０】
望ましい実施例では、上述した階層構造の異なるエンティティ間に共通の一般インターフェイスがある。共通の一般インターフェイスによって、オブジェクト・マネージャ２３、ＭＯＭ２９、オブジェクト領域マネージャ３１及びマッピング・マネージャ３３との及びその間における共通の手段による通信が可能になる。
【００４１】
オブジェクト１３間での相互作用は、あるリクエスト元（すなわちオブジェクトまたはプロセス）からターゲット・オブジェクトに送られる、このターゲット・オブジェクトに対して何らかの操作を求めるリクエストによって行われる。操作呼び出し（ｏｐｅｒａｔｉｏｎ  ｃａｌｌ）は、本発明のオブジェクト／プロセス管理装置１５が定義した枠組み内に置かれているオブジェクト１３間での通信の基本形態である。基本的に、操作とは、何らかの情報を供給し、このターゲットオブジェクトの状態に関する何らかの操作を引き受け及び／または他のオブジェクトを操作するようにターゲット・オブジェクトに対してリクエストする態様である。操作は、その呼び出しサインによって定義される。サインは、戻り値の型（空かもしれない）、パラメータ指定のリスト及び同期（デフォルト）と非同期のいずれの操作であるか、から構成される。
【００４２】
本発明のオブジェクト／プロセス管理装置１５はオブジェクトに対する操作呼び出しは皆下記の構文形式を備えるものと定義している：
【００４３】
0003573762.tif 000002
【００４４】
ｏｂｊｒｅｆ＿ｔと称する不透明な（ｏｐａｑｕｅ）ハンドルを使用して、リクエストが送られるべきオブジェクト（すなわちターゲット・オブジェクト）が識別される。望ましい実施例では、ｏｂｊｒｅｆ＿ｔは、実装に依存するところの、システムが定義する構造体へのポインタである。こうしたハンドルの内部構造はシステム１１のユーザかは見えないしまた使用することもできない。システム１１のユーザは、ランタイム・ライブラリ２７を呼び出すことによってｏｂｊｒｅｆ＿ｔハンドルを生成し削除する。
【００４５】
あるパラメータは、概念上、参照渡しされる。すなわちこのようなパラメータは出力または入出力パラメータのステータスを持っている。全ての操作についての第１のパラメータは、リクエストを受けるべきターゲット・オブジェクトに対してシステムが定義するオブジェクト参照である。呼び出しによって呼び出されるメソッドが単一の値を返すと、その値は操作に関する戻り値として返される。メソッドが複数値を返すと、その値は値を戻すことの可能なパラメータに入れてこの操作に返される。また、全てのオブジェクト／プロセス管理装置１５の操作は操作がうまくいったか否かを判定するために用いることの可能なステータス値を返すように定義されている。操作が失敗すると、ステータス値は失敗の性質を表示する。
【００４６】
インターフェイスは、論理的に関連しまた一つの意味の単位を形成する操作の空ではない集合である。オブジェクト／プロセス管理装置１５はインターフェイスに関して以下の要件を設けている：オブジェクト・クラスがインターフェイス中である操作をサポートするなら、そのオブジェクト・クラスはインターフェイスを構成する操作の集合の全てのメンバをサポートしなければならない。更に、各インターフェイスは、最初にそのインターフェイスを設計した実装者が割り当てたインターフェイス識別子によって識別される。
【００４７】
メソッドは操作を実装するコードである。所与の操作に関して、そのコードは、コンピュータ・アーキテクチャあるいはその他の理由により、オブジェクト１３毎に異なるかも知れない。操作は、オブジェクト１３上で実行すべきアクションの指定に用いられる。オブジェクト１３へのリクエストは、そのオブジェクト１３上のメソッドにマッピングされる。このマッピングによって、特定の実装を、当該オブジェクト１３がサポートするインターフェイスで定義されている操作に対応付ける。操作リクエストに対応付られたメソッドが、意図された意味をこのリクエストに付与するように適切に動作するようにすることを保証するのは、クラスを実装する者の責任である。
【００４８】
これにより、リクエスト元からのオブジェクト操作呼び出しに応答し、ターゲット・オブジェクトのオブジェクト・マネージャのＭＯＭがこのオブジェクト・マネージャと相互作用し、このリクエストをターゲット・オブジェクト１３ｂへ送り出す。操作呼び出しを受信するターゲット・オブジェクト１３ｂと関連付けられたオブジェクト・マネージャ２３は、また、ターゲット・オブジェクト１３ｂがリクエストを受信できることを保証する。
【００４９】
ＭＯＭ２９はコンピューティング・システム１１の存続している間中、複数のオブジェクト・マネージャ２３を追加できるように設計されている。これは、共通のＭＯＭ２９によって管理されている一群のオブジェクト・マネージャ２３によってサポートされる共通の一般インターフェイスによって達成されており、ＭＯＭ２９は、オブジェクト・マネージャが基づいているオブジェクト・モデルに関する明確な知識がなくても、各オブジェクト・マネージャとの通信を行うことができるようになっている。ＭＯＭ２９と特定のオブジェクト・マネージャ２３が通信を行う具体的なやり方はＭＯＭ２９のどの特定の実装を取ってみても同じであるが、実装毎に異なっていてもよい。
【００５０】
ＭＯＭ２９と個々のオブジェクト・マネージャ２３とを分離することによって、大きく異なる属性を有する諸オブジェクト１３が、相互に作用する能力に制限を受けることなくコンピューティング・システム１１内で共存できるようになる。また、このような分離によって、ＭＯＭ２９はシステム１１全体で使用される通信サービスについて知ることができ、個々のオブジェクト・マネージャ２３は、それに関連付けられているオブジェクト１３の詳細について知る。
【００５１】
更に、このように知識を切り分けることによって、ＭＯＭ２９は任意のタイプのオブジェクト１３へのリクエストを受信することが可能になる。リクエストの受信に応答し、ＭＯＭ２９はリクエストのターゲットであるオブジェクト１３ｂが当該ＭＯＭ２９に関連付けられているオブジェクト・マネージャ２３の内の１つによって管理されるものであるか否かを判定する。次に、ターゲット・オブジェクト１３ｂの個別のオブジェクト・マネージャ２３によって、そのターゲット・オブジェクト１３ｂがそのリクエストを受信する用意が整っていることを保証する。オブジェクト・マネージャは、管理されるターゲット・オブジェクト１３ｂに関する特定の知識を有していることによって、あるいは獲得することによって、これを行うことができる。場合によっては、ターゲット・オブジェクト１３ｂがリクエストを受信する用意の整っていることを保証するには、それに関連付けられているオブジェクト・マネージャ２３がターゲット・オブジェクト１３ｂをアクティブにする必要がある。これを行うには、関連付けられているオブジェクト・マネージャ２３が、ターゲット・オブジェクトによって用いられる実行モデル及び永続記憶スキームについて知る必要がある。
【００５２】
ＭＯＭ２９と個々のオブジェクト・マネージャ２３との間でのこの役割分担による正味の効果は、次のように言い換えることができる。ＭＯＭ２９はリクエストの既知の受信点及びその取り次ぎエージェントとして行動し、ＭＯＭ２９に関連付けられたオブジェクト・マネージャはオブジェクト１３ｂについてのオブジェクト・モデル固有の起動者及び操作者として行動する。
【００５３】
オブジェクト／プロセス管理装置１５によって定義された分散コンピューティング・システム中で機能を果たすため、オブジェクト１３はいくつかの操作をサポートする。望ましい実施例では全てのオブジェクト１３が以下の関数をサポートする。
【００５４】
0003573762.tif 000003
【００５５】
関数ｇｅｔ＿ａｃｌは、パラメータ”ｏｂｊｅｃｔ”によって参照されるオブジェクトに対応したアクセス制御リストを返す。
【００５６】
0003573762.tif 000004
【００５７】
関数ｓｅｔ＿ａｃｌは、ｔｏ＿ａｃｌによって参照されるアクセス制御リストを、パラメータｏｂｊｅｃｔによって参照されるオブジェクトに関連付ける。この関数は、この設定がうまくいけば値「真」を返し、うまくいかなければ値「偽」を返す。パラメータｏｂｊｅｃｔに現在関連付けられているアクセス制御リストは、操作がうまくいくようにアクセス制御リストをセットする権利をリクエストの送信元に対して与えなければならないことに注意されたい。
【００５８】
0003573762.tif 000005
【００５９】
関数ｓｅｔ＿ｃｌａｓｓ＿ｉｄは、パラメータｏｂｊｅｃｔによって参照されるオブジェクトと関連付けられたしたクラス識別子をｔｏ＿ｃａｌｓｓで指定された値に変える。この関数は、設定がが成功すれば値「真」を返し、うまくいかなければ値「偽」を返す。
【００６０】
0003573762.tif 000006
【００６１】
関数ｉｎｑ＿ｃｏｌｏｃａｔｉｏｎは、ｏｆ＿ｏｂｊｅｃｔによって参照されるオブジェクトが、ｗｉｔｈ＿ｏｂｊｅｃｔによって参照されるオブジェクトと同じロケーションに配置されているか否かについて問い合わせる。この関数は、両オブジェクトが同じロケーションに配置されていれば「真」を戻し、そうでなければ「偽」を戻す。同一位置に配置されていることの意味は、永続記憶メカニズム及び／またはこれらのオブジェクトに関連付けられたオブジェクト・マネージャに依存する。
【００６２】
実行中、呼び出し及び操作リクエストは以下のように処理される。ランタイム・ライブラリ２７は全てのオブジェクト１３に結び付けられている。ランタイム・ライブラリ２７は、リクエストを送り出す発送点とリクエストを受信する最終目的地の両方の働きをする。この機能の一部として、ランタイム・ライブラリ２７は、ロケーション・サービス２１における基本的なエンティティである、オブジェクト参照を構築するためのインターフェイスを提供する。ランタイム・ライブラリ２７はまた、永続記憶マネージャへのインターフェイスを提供する。このインターフェイスは、後述するように、オブジェクトがデフォルト・オブジェクト・マネージャ２５の助けを借りて永続状態（ｐｅｒｓｉｓｔｅｎｔ  ｓｔａｔｅ）を管理できるようにする。
【００６３】
リクエストの送受信はシステム１１のユーザやオブジェクト１３を書く人間、あるいはもっと正確に言えばオブジェクトのクラスを書く人間にとっては透過的である。リクエストの送信は、内部的な実行時の機能及びクラスの操作インターフェイスを処理するときにインターフェイス・コンパイラが生成するスタブ（すなわちインターフェイス・コード片）によって定義される。ただし、３つの関数がランタイム・ライブラリ２７からエクスポートされる。第１の関数は、２つのオブジェクト参照ハンドル（ｏｂｊｅｃｔ  ｒｅｆｅｒｅｎｃｅ  ｈａｎｄｌｅ）を比較することによってそれらが同じオブジェクトを表しているか否かを判定できるようにする。第２の関数は、クラス・オブジェクトへのオブジェクト参照を生成できるようにする。第３の関数は、オブジェクト参照ハンドルを破棄（ｄｅｓｔｒｕｃｔ）できるようにする。
【００６４】
望ましい実施例においてエクスポートされる第１のランタイム関数は、次の通りである：
【００６５】
0003573762.tif 000007
【００６６】
関数ｏｍｆ＿ｏｂｊｒｅｆ＿ｅｑｕａｌは、ｒｅｆ１及びｒｅｆ２の各オブジェクト参照ハンドルが同じオブジェクトを表している場合値「真」を返し、そうでなければ値「偽」を返す。
【００６７】
望ましい実施例においてエクスポートされる第２のランタイム関数は次の通りである：
【００６８】
0003573762.tif 000008
【００６９】
ｏｍｆ＿ｄｕｐ＿ｏｂｊｒｅｆの呼び出しによって、パラメータｔｏ＿ｄｕｐが供給するオブジェクト参照の複製が生成される。その結果生じるオブジェクト参照は他のオブジェクトに与えることができる。
【００７０】
望ましい実施例においてエクスポートされる第３のランタイム関数は次の通りである：
【００７１】
0003573762.tif 000009
【００７２】
関数ｏｍｆ＿ｆｒｅｅ＿ｏｂｊｒｅｆは記憶からオブジェクト参照ハンドルを削除する。
【００７３】
ランタイム・インターフェイスで用いられている他の関数は次の通りである：
【００７４】
0003573762.tif 000010
【００７５】
関数ｏｍｆ＿ｃｒｅａｔｅは、あるオブジェクトが存在していることをオブジェクト・マネージャに知らせる。これに応答して、オブジェクト・マネージャが新しいオブジェクトに対してこのオブジェクトへの参照を返す。このオブジェクトは返された参照情報を使用して自分を他のオブジェクトから区別することができる。この呼び出しでは、新しいオブジェクトのクラスをｏｂｊ＿ｃｌａｓｓに入れて指定する。更に、パラメータｇｒｏｕｐ＿ｗｉｔｈは、生成されたオブジェクトをこのパラメータによって参照されるオブジェクトと同じグループに属するものとして登録できるようにする。２つのオブジェクトが同じグループに属する場合、オブジェクト・マネージャは、オブジェクトが互いに当てにする（ｔｒｕｓｔ）と仮定して最適化できるようにするある仮定を行うことができる。例えば、アクティブなオブジェクトをプロセスに割り当てることを実現する際、同じグループに属するオブジェクトは同じプロセス中に置くことができる。このようにするため、オブジェクト・マネージャ２３は自分に関連付けられたオブジェクトの諸グループをそれぞれ同値類として扱う。これにより、オブジェクト・マネージャ２３は実際上自分に関連付けられたオブジェクト・グループの状態を常時掌握しているようにするだけであり、グループ内の個々のオブジェクト１３の状態を掌握しているのではない。
【００７６】
0003573762.tif 000011
【００７７】
関数ｏｍｆ＿ｄｅｌｅｔｅは、あるオブジェクトに関連付けられたオブジェクト・マネージャに対し、ｔｏ＿ｄｅｌｅｔｅによって参照されるオブジェクトが削除されていることを知らせる。この呼び出しの実際上の結果は、そのオブジェクト・マネージャからそのオブジェクトの全ての記録が除去されることである。この呼び出しはオブジェクトに関連付けられた永続記憶を開放するのではない点に注意されたい。この関数は、実行が成功すると値「真」を返し、うまくいかなければ値「偽」を返す
。
【００７８】
0003573762.tif 000012
【００７９】
関数ｏｍｆ＿ｃｈａｎｇｅ＿ｉｄｅｎｔｉｔｙは、パラメータｏｂｊｅｃｔによって参照されるオブジェクトが依って立つアイデンティティをｎｅｗ＿ｉｄによって与えられるアイデンティティに変更する。この呼び出しは、基本的には、ｎｅｗ＿ｉｄによって以前に参照されたオブジェクトがもしあったとしてそれが削除されたあるいは削除されようとしている場合に限って用いられる。この関数は、実行が成功すれば値「真」を返し、うまくいかなければ値「偽」を返す。
【００８０】
永続記憶マネージャ（ＰＳＭ）は、オブジェクトが自分の永続状態を管理できるようにする。ＰＳＭはデフォルト・オブジェクト・マネージャに関連付けられており、システム１１中の全オブジェクト１３にアクセス可能なランタイム・インターフェイスを介してアクセスされる。ＰＳＭインターフェイスに関連付けられた呼び出し集合によって、オブジェクト１３は、当該オブジェクトのオブジェクト・アイデンティティから「ファイルへのポインタ」（ＰＯＳＩＸ規格で定義されている）型を持つオブジェクトを得ることができる。オブジェクト１３は、次に、ポインタで参照されたファイルを好みの方法で用いて、その永続状態を読み取ったりあるいは書き込んだりすることができる。
【００８１】
デフォルト・オブジェクト・マネージャ２５によって管理されるオブジェクト１３は、ＰＳＭを使用して自分の永続状態を記憶する必要はないという点に注意されたい。ただし、ＰＳＭを使用しないことを選択したオブジェクトは、デフォルト・オブジェクト・マネージャ２５の助けを借りずにオブジェクト１３の永続状態の全操作を行う必要がある。
【００８２】
ＰＳＭへのインターフェイスは以下のような呼び出しから構成される。これらの呼び出しは、あるオブジェクト１３に向けられたものではないが、全オブジェクト１３にアクセス可能であって、呼び出し元のオブジェクト１３と同じプロセス空間３９で走るシステム・ランタイム中に実装されているローカルな呼び出しである。これらの関数は、オブジェクト１３とそのオブジェクトのオブジェクト・マネージャ２５を結び付ける接着剤を提供するライブラリと考えるのが最も良い。
【００８３】
0003573762.tif 000013
【００８４】
関数ｐｓｍ＿ｃｒｅａｔｅは、パラメータｌｏｃａｔｉｏｎによって参照されるオブジェクトと同じロケーションにファイルを生成する。生成されたオブジェクトのオブジェクト・アイデンティティはパラメータｏｂｊ＿ｃｒｅａｔｅｄに入れて返される。望ましい実施例では、オブジェクト・アイデンティティは、オブジェクトがそこで生成されたコンピュータ３７の識別情報をコード化したものである。操作の一部として生成されたファイルへのポインタは、関数の戻り値として返される。オブジェクト及び返される戻されるファイルは両方ともｉｎｉｔ＿ａｃｌ中に与えられた初期アクセス制御リスト（ｉｎｉｔｉａｌ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ  ｌｉｓｔ、ＡＣＬ）を有しており、またこのファイルはｃｒ＿ｍｏｄｅで指示されるモードで生成される。
【００８５】
重要なのは、ｐｓｍ＿ｃｒｅａｔｅはオブジェクトを生成するのではなく、単に永続記憶と初期オブジェクト参照を提供し、あるオブジェクト・マネージャにオブジェクトの存在を登録するだけであるということを理解することである。完全なオブジェクト生成は、オブジェクト状態の初期設定といった他の活動を必要とするかもしれない。これは実際にオブジェクトを生成するコードによって処理される。ｐｓｍ＿ｃｒｅａｔｅの呼び出しはそのようなコードが新しいオブジェクトの存在をシステムに知らせるために行われる。
【００８６】
0003573762.tif 000014
【００８７】
関数ｐｓｍ＿ｏｐｅｎは、パラメータｏｂｊｅｃｔのオブジェクト・アイデンティティによって識別されるオブジェクトに関連付けられており、パラメータｏｐｅｎ＿ｍｏｄｅによって指定されるモードでオープンされたファイルへのポインタを返す。このファイルはｐｓｍ＿ｃｒｅａｔｅへの呼び出しによって生成されたものでなければならない。
【００８８】
0003573762.tif 000015
【００８９】
関数ｐｓｍ＿ｄｅｌｅｔｅはパラメータｏｂｊｅｃｔ中に入れて渡されるオブジェクト・アイデンティティによって識別されるオブジェクトに関連付けられたファイルを削除し、更にオブジェクト・マネージャ中のこのオブジェクトへの参照も皆削除する。この関数は、うまく削除できたら値「真」を返し、うまくいかなければ値「偽」を返す。
【００９０】
0003573762.tif 000016
【００９１】
関数ｐｓｍ＿ｃｒｅａｔｅ＿ｌｉｎｋは、パラメータｔｏ＿ｏｂｊｅｃｔによって参照されるオブジェクトに永久的に関連付けられたオブジェクトを生成する。生成されたオブジェクトはｃｌａｓｓ＿ｉｄ中に指定したクラスを有している。このオブジェクトは、もし指定されたなら、ｉｎｔ＿ａｃｌのアクセス制御リストを持つし、指定されなければ、ｔｏ＿ｏｂｊｅｃｔによって参照されるオブジェクトのＡＣＬ（アクセス制御リスト）を持つ。この新たに生成されたオブジェクトはｔｏ＿ｏｂｊｅｃｔの永続記憶に関連付けられており、この呼び出しが返したオブジェクト参照に対してその後にｐｓｍ＿ｏｐｅｎを実行すると、ｔｏ＿ｏｂｊｅｃｔに対してｐｓｍ＿ｏｐｅｎを実行したのと同じ値を返す。この関数はまた、生成されたオブジェクトをｔｏ＿ｏｂｊｅｃｔと同じプロセス・グループにあるものとして登録する。
【００９２】
0003573762.tif 000017
【００９３】
関数ｐｓｍ＿ｇｅｔ＿ａｃｌはパラメータｆｏｒ＿ｏｂｊｅｃｔによって識別されるオブジェクトに関するアクセス制御リストを返す。
【００９４】
0003573762.tif 000018
【００９５】
関数ｐｓｍ＿ｓｅｔ＿ａｃｌはパラメータｆｏｒ＿ｏｂｊｅｃｔによって識別されるオブジェクトについてのＡＣＬをｎｅｗ＿ａｃｌにセットする。この関数は、実行が成功すれば「真」を返し、うまくいかなければ「偽」を返す。
【００９６】
0003573762.tif 000019
【００９７】
関数ｐｓｍ＿ｃｈａｎｇｅ＿ｉｄｅｎｔｉｔｙはパラメータｏｂｊｅｃｔによって識別されるオブジェクト・アイデンティティのオブジェクトをパラメータｎｅｗ＿ｉｄに入れて渡されるオブジェクトの新しいオブジェクト・アイデンティティに変更する。この呼び出しが用いられるのは、ｎｅｗ＿ｉｄによって以前に参照されたオブジェクトがもしあったとして、それが削除されたかあるいは削除されようとしている場合に限られる。この関数は、実行が成功すれば値「真」を返し、うまくいかなければ値「偽」を返す。
【００９８】
0003573762.tif 000020
【００９９】
関数ｐｓｍ＿ｉｎｑ＿ｃｏｌｏｃａｔｉｏｎは、パラメータｏｂｊｅｃｔによって識別されるオブジェクトが呼び出しを行ったオブジェクトと同じ永続記憶ロケーションにあるか否かを判定するために用いられる。この関数は、両オブジェクトが同じロケーションにあれば「真」を返し、そうでない場合は「偽」を返す。
【０１００】
0003573762.tif 000021
【０１０１】
関数ｐｓｍ＿ｇｅｔ＿ｐａｔｈは、ローカルなファイル・システム中でパラメータｏｂｊｅｃｔによって参照されるオブジェクトの永続状態を含んでいるファイルのパス名がもしあれば、それに対応するところの、実装に依存している、ｎｕｌｌで終端された文字列を返す。オブジェクト／プロセス管理装置はこの文字列を解釈しない。このローカルなシステムという前提条件の下でこの文字列を理解し、このローカルなシステム上ではこのような文字列によってどんな操作がサポートされるのかを判断するのはプログラマの責任である。ローカルなシステムがファイル・パス名の概念をサポートしていなければ、ｐｓｍ＿ｇｅｔ＿ｐａｔｈはエラー・ステータス・コードと共にＮＵＬＬを返す。
【０１０２】
［オブジェクトをアクティブにすること］
ほとんどのシステムでは、オブジェクト（またはプログラム）は使用前に明示的に呼び出さなければならない。本発明のオブジェクト指向分散コンピューティング・システムでは、オブジェクト１３はそれらをアクティブにする明示的な操作を必要とせずに、必要に応じてアクティブになる。リクエストをすることによってオブジェクトを使用するだけで、そのオブジェクトはまだアクティブでなかったとしたらアクティブになる。
【０１０３】
ここでは、リクエストに応答可能なオブジェクトは「アクティブ」であると定義する。オブジェクト１３がリクエストに応答するためには、オブジェクトのクラスに関するコードをプロセス３９にロードし、サポートされているリクエスト・インターフェイスをコードによるその実装に対応付け、オブジェクト１３の永続データをロードしなければならない。上述した内の最後の２つのステップは、それぞれ「クラス初期設定」ルーチン及び「オブジェクト復元（ｏｂｊｅｃｔ  ｒｅｓｔｏｒｅ）」ルーチンによって行われる。クラス・コードのロードはマシンに依存したやりかたで処理しなければならない。これらのステップが完了すると、オブジェクト１３はそれがサポートするどんなリクエストにも応答する用意が整い、応答することができる。
【０１０４】
望ましい実施例では、オブジェクトをアクティブにすることに関わるエンティティは、「Ｇｅｎｏｂｊ」と呼ばれるプログラム５５、デフォルト・オブジェクト・マネージャ２５、クラス・エキスパートと呼ばれるエンティティ５７及びランタイム・ライブラリ２７である。Ｇｅｎｏｂｊ５５（図３（ｂ））は、オブジェクト１３にリクエストを受信する準備を整えさせることをその機能とするプロセスである。こうして準備を整えられたオブジェクトはアクティブであるとみなされる。Ｇｅｎｏｂｊ５５は以下のようにしてオブジェクトの準備を整える：
（ｉ）（もし必要なら）このオブジェクトのクラス・コードをＧｅｎｏｂｊ５５のアドレス空間にロードし、
（ｉｉ）このオブジェクトのクラスに関する「クラス初期設定」関数を呼び出し、
（ｉｉｉ）オブジェクト永続データに関して「オブジェクト復元」関数を呼び出す。
Ｇｅｎｏｂｊと同様の関数をを備えた他のプログラムも使える。
【０１０５】
これに関して、デフォルト・オブジェクト・マネージャ２５はオブジェクト集合とプロセス集合を管理する。デフォルト・オブジェクト・マネージャ２５のオブジェクトは多かれ少なかれほとんど永久的であるが、プロセスは必要に応じて開始されまた終了させられる。デフォルト・オブジェクト・マネージャはその自分のオブジェクト各々のクラス及び各オブジェクトの永続データのロケーションを知っている。デフォルト・オブジェクト・マネージャ２５はまた、所与のオブジェクト１３（または関係するオブジェクト・グループ）が現在デフォルト・オブジェクト・マネージャ２５によって管理されるプロセスの１つと関連付けられている否かを知っている。デフォルト・オブジェクト・マネージャ２５は、プロセスに関連付けられたしたオブジェクトまたはオブジェクト・グループはメッセージを受信することができ従って「アクティブ」であると考える。オブジェクト１３を「アクティブ」にしようとするデフォルト・オブジェクト・マネージャ２５は、そのオブジェクトのクラスに適合するプロセスを開始する。クラスが開始させるためのプログラム３９を指定しなければ、デフォルト・オブジェクト・マネージャ２５はＧｅｎｏｂｊ５５を開始させる。
【０１０６】
クラス・エキスパート５７（図３（ｂ））は、オブジェクト・クラス（またはクラスの集合）に関する情報を管理するエンティティである。この情報には、クラスがサポートする操作インターフェイス及びそのクラスに関するある初期設定関数名が含まれている。クラス・エキスパート５７はまた、オブジェクト・クラスの実装に関する情報（コードによる）を保持している。
【０１０７】
ランタイム・ライブラリ２７については既に説明した。要するに、ランタイム・ライブラリ２７は全てのオブジェクト１３に、従って全てのプロセスに置かれている。Ｇｅｎｏｂｊ５５に置かれているランタイム・ライブラリ２７は、更にＧｅｎｏｂｊ５５と相互作用して、オブジェクト１３をアクティブ／非アクティブにすることを統合管理する。
【０１０８】
以下の説明では、「ユーザ」とは本発明のオブジェクト指向分散コンピューティング・システム１１を使用する人間である。「クライアント」とはシステム１１中の別のオブジェクトにリクエスト（またはメソッド呼び出し）を行うプログラムまたはオブジェクトである。「クライアント」はまた、ユーザが通常キー・ボードとマウスの両方または一方を用いて対話するエンティティとも考えられる。オブジェクト１３がまだアクティブになっていなくても、クライアントがそのオブジェクト１３を使用しようとすることによってアクティブになる。更に、この説明において、「関数」、「ルーチン」、「ハンドラ」及び「手順」は交換可能に用いられる。
【０１０９】
制限のためではなく例示のため、ユーザＭが別のユーザＪの電話番号を知りたがっているものと仮定する。ユーザＭはコンピュータ・アプリケーションを通じてユーザＪの「電話情報」を尋ねるだけである。この際、通常、ユーザＭはメニュー選択すなわちコンピュータ・アプリケーションによって表示される書式にユーザＪの名前をタイプする。図２に示すように、コンピュータ・アプリケーションは次に、システム１１のどこかに置かれている電話情報（「ｐｉ」）オブジェクト１３ａがエクスポートしているリクエスト側バージョンの”ｇｅｔ  ｐｈｏｎｅ＿ｉｎｆｏ”リクエストを実行する。リクエスト側バージョンのリクエストは、リクエスト元プロセス３９ａに置かれているランタイム・ライブラリ２７と相互作用する。ランタイム・ライブラリ２７はまずロケーション・サービス２１に連絡を取って、ｐｉオブジェクト１３ａのオブジェクト・マネージャ２５のロケーションを見い出す。ランタイム・ライブラリ２７は次に、このオブジェクトのオブジェクト・マネージャ２５を管理するＭＯＭ２９ａに実際の”ｇｅｔ  ｐｈｏｎｅ＿ｉｎｆｏ”操作リクエストを送る。
【０１１０】
ＭＯＭ２９ａのランタイム・ライブラリ２７はユーザＭのコンピュータ・アプリケーション３９ａによって送られてくるリクエストを含むパケットを受信する。ランタイム・ライブラリ２７は、ＭＯＭ２９ａに対して、このパケットをどこに送るべきか知っているか否かどうか問い合わせる。もっと具体的に言えば、ランタイム・ライブラリ２７は、このパケット中の個々のパラメータの項目中に見出されるオブジェクト・アイデンティティ及びインターフェイス識別子を送り、そのパケットを送りつけることの可能な「エンドポイント（ｅｎｄｐｏｉｎｔ）」（すなわちローカル・ソケット・アドレス）の返報を受信することを期待する。
【０１１１】
これに応答し、ＭＯＭ２９ａは、そのオブジェクト・マネージャ２３のそれぞれについて、そのオブジェクト・マネージャがリクエストの宛て先のオブジェクト（すなわちランタイム・ライブラリ２７が送ってきたオブジェクト・アイデンティティによって指定されるオブジェクト）を管理しているか否かを問い合わせる。デフォルト・オブジェクト・マネージャ２５は、その内部のオブジェクト・グループ・テーブル５１（図３（ａ））をチェックし、それがオブジェクト１３ａを管理しているか否かを確認する。管理していれば、デフォルト・オブジェクト・マネージャ２５は、指定されたオブジェクト１３ａが属しているオブジェクト・グループの識別子を保持している。（１つのオブジェクトしか含んでいないオブジェクト・グループも認められる。）次に、デフォルト・オブジェクト・マネージャ２５は、このオブジェクト・グループの状態を参照する。オブジェクト・グループは以下の３つの状態のいずれかを取ると考えられる：
「アクティブ」−オブジェクト・グループが既にプロセス３９と関連付けられている。このプロセスについての少なくとも１つのエンドポイントが使用できパケットを送り出せる。
「保留（ｐｅｎｄｉｎｇ）」−グループについて当該プロセス３９を開始しているが、このプロセスはまだ、デフォルト・オブジェクト・マネージャ２５に自分のエンドポイントを登録していない。
「非アクティブ」−オブジェクト・グループに関連付けられたプロセス３９がない。
【０１１２】
グループが「アクティブ」である場合、デフォルト・オブジェクト・マネージャ２５はそのグループに関連付けられたプロセス３９のエンドポイントを返す。グループが「保留」の場合、デフォルト・オブジェクト・マネージャ２５は、まだ、エンドポイントを有していないのでエンドポイントを返さないが、指定されたオブジェクトを管理している旨の表示を戻す。グループが「非アクティブ」である場合、デフォルト・オブジェクト・マネージャ２５はそのグループに関するプロセス３９を獲得する。
【０１１３】
望ましい実施例では、デフォルト・オブジェクト・マネージャ２５は、以下に説明しまた図３（ａ）に示すようにして、グループに関するプロセスを獲得する。まず、デフォルト・オブジェクト・マネージャ２５ａは「使用可能な」プロセス３９ｄ、３９ｅの入っている使用可能プロセス・プール４７をチェックする。使用可能なプロセスとは、デフォルト・オブジェクト・マネージャ２５に１つまたは複数のエンドポイントを登録したが、まだどのオブジェクト・グループとも関連付けられていないプロセスである。デフォルト・オブジェクト・マネージャ２５はプール４７内の各プロセス３９をチェックし、指定されたオブジェクトのクラスに適合する（ｃｏｍｐａｔｉｂｌｅ）プロセスを見つけ出す。プロセスの中には（例えば、Ｇｅｎｏｂｊの場合）多くのクラスと適合するものもあるが、特定のクラスのオブジェクトに対するサービスだけに限定されるものもある。デフォルト・オブジェクト・マネージャ２５は、プール４７内で適合するプロセス３９ｅを見つけ出すと、デフォルト・オブジェクト・マネージャの内部テーブル５１中でこのオブジェクト・グループを「アクティブ」である旨マークする。デフォルト・オブジェクト・マネージャ２５はまた、見出されたプロセス３９ｅのエンドポイント及びプロセスのオペレーティング・システム識別子をこのグループに関連付ける。デフォルト・マネージャ２５は次に、新たに関連付けられたエンドポイントをＭＯＭ２９ａに返し、使用可能プロセス・プール４７からプロセス３９ｅを除去する。
【０１１４】
デフォルト・オブジェクト・マネージャ２５が使用可能プロセスのプール４７中で適合するプロセスを見つけ出すことができない場合、デフォルト・オブジェクト・マネージャ２５は適合するプロセス３９ｆを開始させる。これを行うため、デフォルト・オブジェクト・マネージャ２５は、このオブジェクトのクラスに関連付けられた情報を参照して、適合するプロセス３９ｆのパスを決定する。既に述べたように、クラスがプロセスの指定していない場合、デフォルト・オブジェクト・マネージャ２５はＧｅｎｏｂｊ５５を開始させる。プロセス３９ｆの開始後、デフォルト・オブジェクト・マネージャ２５は、その内部テーブル５１内部に、オブジェクト・グループが「アクティブ化を保留」している旨マークする。デフォルト・オブジェクト・マネージャ２５はまた「保留プロセス」のプール５３に項目３９ｆを入れる。プロセス３９ｆの項目には、このプロセスのオペレーティング・システム識別子及びプロセス３９ｆが意図しているグループの識別子が含まれている。
【０１１５】
プロセス３９ｆがそのエンドポイントを（デフォルト・オブジェクト・マネージャ２５上でのｒｅｇｉｓｔｅｒ＿ｅｎｄｐｏｉｎｔｓリクエストを介して）登録すると、その項目は保留プロセス・プール５３から除去され、このプロセスが意図しているグループには、デフォルト・オブジェクト・マネージャ２５が内部テーブル５１中で「アクティブ」である旨マークする。デフォルト・オグジェクト・マネージャ２５はまた、このグループを内部テーブル５１中のプロセスのエンドポイント及びプロセスの識別子に関連付ける。グループ関連付けなしで開始されるプロセスが自分のエンドポイントを登録すると、このプロセスは保留プロセス・プール５３から使用可能プロセス・プール４７に移ることに注意されたい。
【０１１６】
Ｇｅｎｏｂｊ５５がデフォルト・オブジェクト・マネージャ２５によって開始される場合、Ｇｅｎｏｂｊは、図３（ｂ）に示すように、以下のように動作する。Ｇｅｎｏｂｊ５５は、デフォルト・オブジェクト・マネージャ２５による開始直後に、ランタイム・ライブラリ２７に対しエンドポイントの問い合わせを行う。エンドポイントを獲得すると、Ｇｅｎｏｂｊ５５はデフォルト・オブジェクト・マネージャ２５上で”ｒｅｇｉｓｔｅｒ＿ｅｎｄｐｏｉｎｔｓ”リクエストを実行する。このリクエストのパラメータにはＧｅｎｏｂｊ５５のこのインスタンスについてのオペレーティング・システム・プロセス識別子及びランタイム・ライブラリ２７から得たエンドポイントが含まれる。
【０１１７】
Ｇｅｎｏｂｊ５５はデフォルト・オブジェクト・マネージャ２５にエンドポイントを登録するだけでなく、（別の種類の）登録をランタイム・ライブラリ２７に行う。Ｇｅｎｏｂｊ５５は「未知オブジェクト」関数６１（ランタイム・ライブラリ２７が処理方法の分からないリクエストを受信した際に呼び出される関数）を登録する。両方の登録の実行後、Ｇｅｎｏｂｊ５５は、制御をランタイム・ライブラリ２７に委譲し、これによってランタイム・ライブラリはリクエスト（デフォルト・オブジェクト・マネージャ２５によって送り出される、あるいはリクエスト元が直接送ってくるかもしれない）の受信を開始できるようになる。ランタイム・ライブラリ２７は、処理方法の分からないリクエストを受信すると、未知オブジェクト関数６１を呼び出す。
【０１１８】
Ｇｅｎｏｂｊの未知オブジェクト関数（またはハンドラ）６１は、リクエストｇｅｔ＿ｏｂｊ＿ｉｎｆｏ（）を介してデフォルト・オブジェクト・マネージャ２５と相互作用し、オブジェクトのクラス及びオブジェクトの永続データのロケーションを判定する。未知オブジェクト関数６１は、獲得したばかりのクラス識別子を使用して、そのクラスに関するエキスパート５７のロケーションを見い出して連絡を取る。未知オブジェクト関数は、クラス・エキスパート５７から、図３（ｂ）に示すように、ｇｅｔ＿ｃｌａｓｓ＿ｉｎｆｏ（）リクエストを介してクラス初期設定関数及びオブジェクト復元関数の名前を見つけ出す。未知オブジェクト関数６１はまた、関数のアドレス空間にクラスの実装をロードするのに必要な情報を得るかもしれない。クラスの実装をロードすると、未知オブジェクト関数６１はクラス初期設定関数を呼び出す。クラス初期設定関数の主な目的は、クラスの操作インターフェイス及び非アクティブ化ハンドラをランタイム・ライブラリ２７に登録することである。次に、未知オブジェクト関数６１は、このオブジェクトの永続データのロケーションを渡すこと等を行うこのクラスのオブジェクト復元関数を呼び出す。復元ルーチンが完了すると、未知オブジェクト関数６１はランタイム・ライブラリ２７にオブジェクト及びクラスを登録する。最後に、未知オブジェクト関数６１は制御をランタイム・ライブラリ２７に戻す。
【０１１９】
ランタイム・ライブラリは今やリクエスト（パケット）の適切な処理に充分な情報（リクエストの登録とオブジェクト／クラスの登録から得られた）を有している。復元が完了したオブジェクトは、かくして、パケットによって指定されたリクエストを受け取る準備が整っている。ランタイム・ライブラリ２７は単に、オブジェクトがそのリクエストについて登録したスタブを呼び出し、リクエスト・パケット中に見つけたデータを渡す。スタブはそのデータを取り出してそのオブジェクトの適切なメソッドを呼び出す。
【０１２０】
オブジェクト１３への次のリクエストがパケットの形で到着すると、このオブジェクトはその時点で「既知」になっているので、ランタイム・ライブラリ２７は未知オブジェクト関数に頼らずに直接スタブを呼び出すことができる。
【０１２１】
上述した手続の利点は、この手続がユーザやクライアント・プログラムに対しては透過的であることである。オブジェクトへのリクエストを呼び出したクライアントは、オブジェクト１３がそのリクエストを出した以前にアクティブであったか否かについては全く分からない。そのため、全オブジェクトは、たとえそれが現在のところ何かのプロセスに関連付けられていなくても、見かけ上はリクエストの処理のために使用可能であるように、すなわちアクティブである。従って、本発明はリクエストが出された時点のターゲット・オブジェクトとプロセスとの関連付けには関係なく、ターゲット・オブジェクトについて、ターゲット・オグジェクトの操作及びデータを実現する（更にリクエストを受信してサービスを行う）ためのコンピュータ手段を提供するものである。
【０１２２】
［オブジェクトを非アクティブにすること］
オブジェクトのクラスのクラス初期化ルーチンは非アクティブ化ハンドラをランタイムに登録することを担当する。好ましい実施例では、オブジェクト・マネージャ２３はシステム１１が資源を必要とすることに自動的に応答して非アクティブ化を行う。Ｇｅｎｏｂｊ５５がデフォルト・オブジェクト・マネージャ２５からプロセス終結要求を受信すると、Ｇｅｎｏｂｊ５５は登録されているオブジェクトの各々についてランタイム・ライブラリ２７に非アクティブ化ハンドラの呼び出しを求める。デフォルト・オブジェクト・マネージャ２５からの終結要求は、プロセス３９を終結させることがどの位重要かを示す「優先度」パラメータを持っている。このパラメータが取ることのできる優先度の値は、「動作中でなければ終結してください」から「終結しないと不都合な状態でキルされるぞ」まで、少なくとも３つある。Ｇｅｎｏｂｊ５５は優先度パラメータを非アクティブ化ハンドラを呼び出すランタイム・ルーチンｄｅａｃｔｉｖａｔｅ＿ｏｂｊｅｃｔｓに渡す。非アクティブ化ハンドラを呼び出す前に、ルーチンｄｅａｃｔｉｖａｔｅ＿ｏｂｊｅｃｔは優先度パラメータの値をオブジェクト１３毎に登録されている「終結不服」レベルと比較する。優先度レベルが各「不服」レベルよりも高ければ非アクティブ化ハンドラが呼び出される。そうでない場合には、ルーチンｄｅａｃｔｉｖａｔｅ＿ｏｂｊｅｃｔはＧｅｎｏｂｊへリターンし、現在の最大の不服レベルを渡す。するとＧｅｎｏｂｊ５５はこの値をデフォルト・オブジェクト・マネージャ２５に渡す。
【０１２３】
オブジェクト１３は、必要なときにはいつでも自分の不服レベルを変更することができる。例えば、ある期間メソッド要求を何も受け取っていないオブジェクト１３はランタイム・ライブラリに対して、自分の不服レベルは低いと告げるかもしれない。このオブジェクト１３がつぎにメソッド要求を受け取ったら、オブジェクト１３は、ランタイム・ライブラリ２７に対して、自分の不服レベルは高いと告げることであろう。ランタイム・ライブラリ２７は各オブジェクト１３の現在の不服レベルを常時掌握している。
【０１２４】
［自分のグループ中の他のオブジェクトをアクティブにするオブジェクト］
オブジェクトの復元ルーチンは（自分の永続データに基づいて）、自分のグループ中の他のオブジェクトをＧｅｎｏｂｊ中でアクティブにする必要があると判断することがある。復元ルーチンは、Ｇｅｎｏｂｊの未知オブジェクト関数（ハンドラ）６１を呼び出して所望のオブジェクト１３のアイデンティティを渡すことによって、他のオブジェクトをアクティブにすることができる。復元ルーチンは必要とするだけいくらでも多くのオブジェクトについてこれを行うことができる。未知オブジェクト・ハンドラ６１はこの所望のオブジェクトがまたアクティブでないことを確認する。このオブジェクトがアクティブでない場合には、未知オブジェクト・ハンドラは上述したようにランタイム・ライブラリ２７から呼び出されたときとほとんど同様な挙動を取る。相違点は、端効果（ｅｎｄ  ｅｆｆｅｃｔ）における違いにあるのではなく、同時性制御（ｃｏｎｃｕｒｒｅｎｃｙ  ｃｏｎｔｒｏｌ）に関するものである。未知オブジェクト・ハンドラ６１への呼び出しはリカーシブである可能性があることに注意されたい。例えば、未知オブジェクト・ハンドラはあるオブジェクト「Ａ」上のランタイム・ライブラリ２７から呼ばれ、このオブジェクトの復元ルーチンはオブジェクト「Ｂ」上の未知オブジェクト・ハンドラを呼ぶかもしれない。「Ｂ」についての復元ルーチンは今度はオブジェクト「Ｃ」上のハンドラを呼ぶかもしれず、以下同様である。最後には、必要とされる全てのオブジェクトが自分のクラスを初期化し、自分の状態を復元する。最終的には制御はランタイム・ライブラリ２７に戻る。
【０１２５】
［クラスのローディング及び初期化の制御］
一つのオブジェクト・グループ内の任意の個数のオブジェクトが同じクラスに属することができる。各オブジェクト１３がＧｅｎｏｂｊ５５でアクティブにされたとき、Ｇｅｎｏｂｊは自分がそのオブジェクトのクラスを既にロードし初期化しているか否かをチェックする。もしそうであれば、Ｇｅｎｏｂｊ５５は再ロードを取りやめてそのクラスを再び初期化する。しかし、Ｇｅｎｏｂｊはそのクラスが以前にロードされているかどうかにはかかわりなく、復元関数を呼び出す。これは、復元関数がクラスではなくオブジェクト１３の状態を復元する役割を持っているからである（また、これはオブジェクト毎に必要である）。
【０１２６】
本発明を特定の実施例を参照して開示し説明したが、当業者には、本願特許請求の範囲に定義された本発明の精神及び範囲から逸脱することなく、その具体的形態や細部についての種々の変更を成しうることが理解できるであろう。
【０１２７】
【効果】
以上詳細に説明したように、本発明によれば、ターゲット・オブジェクトのロケーション、現在アクティブかどうか、等のターゲット側についての詳細な知識が不要であり、またそのような知識の欠如に対処するための明示的な手当も必要ではない、分散環境におけるオブジェクト指向システムが構築できる。
【図面の簡単な説明】
【図１】本発明の一実施例を説明する図。
【図２】本発明の一実施例を説明する図。
【図３】本発明の一実施例を説明する図。
【符号の説明】
１１：オブジェクト指向コンピューティング・システム
１３：オブジェクト
１５：オブジェクト／プロセス管理装置
１７：オブジェクト管理サービス層
１９：通信サービス層
２１：ロケーション・サービス
２３：オブジェクト・マネージャ
２５：デフォルト・オブジェクト・マネージャ
２７：ランタイム・ライブラリ
２９：ＭＯＭ
３１：オブジェクト領域マネージャ
３３：マッピング・マネージャ
３５：同胞メタ・オブジェクト領域マネージャ
３７：コンピュータ
３９：プロセス
４７：使用可能プロセス・プール
５１：オブジェクト・グループ・テーブル
５３：保留プロセス・プール
５５：Ｇｅｎｏｂｊ
５７：クラス・エキスパート
６１：未知オブジェクト・ハンドラ
【図１】
0003573762.tif 000022
【図２】
0003573762.tif 000023
【図３】
0003573762.tif 000024