JPH0916503A - コンピュータプロセスを管理する方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 コンピュータプロセスを管理するための多数
の方法、装置、およびデータ構造を提供する。 【解決手段】 サーバープロセスを管理するデーモンプ
ロセスは、活動サーバーテーブルとロケーターサービス
とを含み、ロケーターサービスは、活動サーバーテーブ
ル内のサーバープロセスをルックアップし登録すること
ができる。更に、ロケーターサービスはサーバープロセ
スを起動することができる。そして、ロケーターサービ
スはルックアップオブジェクトとサーバープロセス登録
オブジェクトとを含み、これらはロケーターサービスの
タスクを実行する。また、サーバープロセスの起動およ
び登録のような、サーバープロセスを管理するための方
法を提供する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

【０００４】しかし、最近、オブジェクト指向方法論の
分野で、コンピュータネットワークを通じて相互接続さ
れたコンピュータの分散オブジェクトオペレーテイング
環境の実装が大きく進展している。ここで使用する「分
散オブジェクト」または「オブジェクト」とは、オブジ
ェクトのインターフェイスを介する作用によって操作す
ることのできるカプセル化されたコードとデータとのパ
ッケージをいう。したがって、当業者にとっては、分散
オブジェクトは、従来のプログラミングオブジェクトを
定義する基本的特性を含むものと見えるであろう。しか
し、分散オブジェクトは、以下の二つの重要な特徴を含
むことにより、従来のプログラミングオブジェクトとは
異なる。第一の特徴は、分散オブジェクトが多言語的で
あることである。分散オブジェクトのインターフェイス
は、様々なプログラミング言語にマップされ得るインタ
ーフェイス定義言語を用いて定義される。こうしたイン
ターフェイス定義言語のひとつがＩＤＬである。第二の
特徴は、分散オブジェクトは場所独立性がある、すなわ
ち、分散オブジェクトはネットワーク内のどこにでも配
置され得ることである。このことは、単一のアドレス空
間内、例えばクライアントのアドレス空間内に存在する
従来のプログラミングオブジェクトに対して著しく対照
的である。

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

【０００６】クライアントが目標オブジェクトをコ−ル
する時、リクエストされたサービスをターゲットオブジ
ェクトが確実に実行できるように、特定の手順が実行さ
れなければならない。これらの手順は、ターゲットオブ
ジェクトを識別して場所を定め、ターゲットオブジェク
トが存在する条件でサーバープロセス（必要な場合）を
始動し、必要であればターゲットオブジェクトを活動化
し、最終的にターゲットオブジェクトとの接続を形成し
てコールを転送する。ＯＲＢはサーバプロセスの始動お
よび登録を含め全段階でサーバープロセスの管理にとっ
ては理想的であろう。分散オブジェクトオペレーテイン
グ環境でサーバプロセスを管理するために必要なのはフ
レームワークである。

【０００７】

【課題を解決するための手段】以下、本発明の目的に従
い、また上記およびその他の目的を達成するため、コン
ピュータプロセスを管理するための方法、装置およびデ
ータ構造を説明する。本発明では、分散オブジェクトオ
ペレーティング環境でのホストコンピュータシステム上
で実行されるデーモンプロセスは、活動サーバーテーブ
ルとロケータサービス (locator service) とを含む。
この活動サーバーテーブルは、現在ホストコンピュータ
上で実行されているサーバープロセスの多重度に関係す
るエントリを保守するためのデータ構造を持っている。
これらのエントリには、サーバー識別子、サーバプロセ
ス状態、およびサーバープロセスアドレシング情報が含
まれている。ロケータサービスは、活動サーバーテーブ
ルにアクセスして、サーバープロセスに関するアドレシ
ング情報をリクエストしているクライアントに、この情
報を提供する。その上、ロケータサービスは、サーバー
プロセスを活動サーバーテーブルに登録する。

【０００８】一実施例において、デーモンプロセスは、
その内部にオブジェクトアダプタデータベースを持って
いる。追加の実施例において、オブジェクトアダプタデ
ータベースは、分散オブジェクトオペレーティング環境
の中の何れかの場所に存在する。ひとつの特定の実施例
はホストコンピュータ上で実行される別のプロセス中に
オブジェクトアダプタデータベースを持っている。オブ
ジェクトアダプタデータベースは、目標オブジェクト識
別子、少なくともひとつの目標オブジェクト識別子に夫
々対応するサーバー識別子、目標オブジェクト識別子に
夫々対応するオブジェクトレファレンス、のようなデー
タ要素を含む。別の実施例において、ロケータサービス
は、２つのオブジェクトと、１つのロケータオブジェク
トと、サーバープロセス登録オブジェクトを含む。ロケ
ータオブジェクトは、サーバールックアップ機能を実行
し、サーバープロセス登録オブジェクトは、サーバープ
ロセス登録機能を実行する。更に別の実施例では、分散
オブジェクトオペレーティング環境が、各コンピュータ
システム上で実行される上記の個別のデーモンプロセス
とネットワークを介して接続した、様々なコンピュータ
システムを含むことを意図している。

【０００９】また、本発明では、分散オブジェクトオペ
レーティング環境で使用するためのコンピュータシステ
ムを意図している。このコンピュータシステムは、中央
処理装置と、この中央処理装置からアクセスされるメモ
リと、このコンピュータシステムへ実装されるロケータ
サービスを含む。複数の分散オブジェクトがメモリ内に
存在する。ロケータサービスは、これらの分散オブジェ
クトと、コンピュータ上を走る任意のサーバープロセス
を管理する。いくつかの関連実施例において、コンピュ
ータシステムは以下に記載した本発明の方法面を実行す
るための手段を有する。

【００１０】また、本発明の方法は、サーバープロセス
を起動し登録するようなサーバープロセスを管理する様
々な方法を提供する。これらのサーバープロセスは、サ
ーバーホストコンピュータ上に存在する。第１の方法で
は、サーバーホストコンピュータ上に存在するデーモン
プロセスは、目標オブジェクトに関すルックアップコー
ルを受けるステップ、前記目標オブジェクトに関するサ
ーバー識別子を獲得するステップ、サーバープロセスの
状態を判定するステップ、前記サーバープロセスに対応
するアドレシング情報を返すステップを実行する。この
サーバープロセスはサーバー識別子によりサーバーホス
トコンピュータ内で唯一性を以て定義される。ひとつの
方法面において、サーバープロセスで実行されている状
態であると判定されると、その結果として、直ちに前記
アドレシング情報を返すステップが実行される。また、
起動している状態にあると判定されると、その結果とし
て、アドレシング情報を返す前に、起動から実行へと状
態が移行するまでデーモンプロセスは待機する。

【００１１】また、本発明の方法では、目標オブジェク
トに関してサーバー識別子を獲得するステップは、第１
のデータベースにアクセスすることにより実行される。
例えば、第１のデータベースがオブジェクトアダプタデ
ータベースであってもよい。サーバープロセスの状態
は、それを第２のデータベース内にルックアップするこ
とにより判定される。一例として、第２のデータベース
が活動サーバーテーブルであってもよい。別の実施例で
は、第１と第２のデータベースは同一のデータベースで
ある。

【００１２】また、本発明の方法では、プロセスの状態
が活動していない状態（つまり、サーバープロセスが第
２のデータベース中で見い出されない）であると判定さ
れた場合、デーモンプロセスは第２のデータベース中に
サーバープロセスエントリを形成する。このエントリ
は、サーバー識別子とサーバープロセス状態を含む。そ
して、サーバープロセスを起動状態にし、第１のデータ
ベースにアクセスして目標オブジェクトに関する execd
ef（実行定義） を獲得し、execdef を用いてサーバー
プロセスを起動し、サーバープロセスアドレシング情報
をクライアントへ返す前に、サーバープロセスが起動状
態から実行状態へと移行するまで待機する、という以上
のステップによって、デーモンプロセスが継続する。例
えば、execdef はサーバーのプログラム名および任意の
必要なアーギュメントであってもよい。

【００１３】また、本発明の方法では、サーバープロセ
スは、ホストコンピュータのオペレーティングシステム
からサーバプロセス識別番号を獲得することによって起
動されていることに応答する。そして、それは、サーバ
ープロセスに関する通信ポートを生成し、サーバープロ
セスに関するアドレシング情報を形成して、デーモンプ
ロセス中に存在するサーバープロセス登録オブジェクト
をコールする。このコールのオペレーションにより登録
サーバーオペレーションが発動されることになる。この
コールへのアーギュメントとして、サーバープロセス
は、アドレシング情報と、サーバープロセス識別子番号
と、サーバー識別子を転送する。このコールに応答し
て、サーバープロセス登録オブジェクトはアドレシング
情報を第２のデータベースに格納し、サーバプロセス状
態エントリに、走行中とマーキングする。

【００１４】本発明では、サーバープロセスのための自
己起動（つまり自己起動および登録(self-start and re
gister)）を行う方法を提供する。この方法は、サーバ
ープロセスが、リクエストを受けて、所望の目標オブジ
ェクトに関するオブジェクトレファレンスを携えたサー
バーになるときに開始する。それに応答して、サーバー
プロセスが実行を開始して、ホストコンピュータのオペ
レ−テイングシステムからサーバープロセス識別子番号
を獲得する。次に、それは以下のステップを実行する。
サーバープロセスに関する通信ポートを生成するステッ
プ、サーバープロセスに関するアドレシング情報を形成
するステップ、オブジェクトリクエストブローカのオブ
ジェクトファイルから、サーバープロセス登録オブジェ
クトに関するオブジェクトレファレンスを獲得するステ
ップ。そして、サーバープロセス登録オブジェクトをコ
ールして登録新サーバーオペレーション (register new
server operation) を発動するステップである。そし
て、このコールに応答してサーバプロセスは、自らに対
応するサーバー識別子を受ける。

【００１５】

【課題を解決するための手段】本発明は、オブジェクト
指向プログラミング（ＯＯＰ）に基づく分散オペレーテ
ィング環境に係わり、特に、コンピュータプロセスを管
理するための方法、装置およびデ−タ構造に関するもの
である。以下の検討において、第１に、本発明に適した
例示のコンピュータシステムを検討することによって、
次に、本発明の装置とデータ構造のいくつかの実施例を
詳細に説明することによって、更に本発明の方法面の詳
細な説明によって本方法と装置が詳細に考察される。

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

【００１７】「分散オブジェクトシステム」または「分
散オブジェクトオペレ−ティング環境」とは、ＯＲＢを
介して通信を行う分散オブジェクトを備えるシステムの
ことである。

【００１８】「オブジェクトレファレンス」または「ob
jref」とは、他のオブジェクトへのポインタを含むオブ
ジェクトをいう。例えば、objref は、ホストコンピュ
ータネットワークアドレス、ＯＲＢデーモンネットワー
クポートアドレス、そしてオブジェクト識別子のような
アドレシング情報を含むかも知れない。オブジェクトレ
ファレンスの形成と定義は当業者にはよく知られてい
る。

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

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

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

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

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

【００２４】本発明によれば、ＯＲＢは、分散オブジェ
クトへのコールを伴うクライアント-サーバー対話を含
めて、分散オブジェクト、および分散オブジェクトオペ
レーティング環境内で見いだされたサーバープロセスの
多くの面の管理を担う。本発明が意図している分散オブ
ジェクトは、コンピュータプロセスの下で（ＯＲＢおよ
び／またはホストコンピュータにより）実装される。当
業者には公知であるように、コンピュータプロセスは、
コンピュータシステムが機能している時に共通フレーム
ワークを提供する。

【００２５】実際に、プロセスは、アドレススペース
（つまり、そのプロセスだけに割り当てられた、メモリ
の部分）、１セットのファイルディスクリプタ、プロセ
ス識別番号、およびひとつまたはそれ以上の実行のスレ
ッド（しばしばスレッドとも言う）を含む。当業者には
なじみであるが、実行の単一スレッドは、本質的にひと
つのプロセスを介する実行の点のシーケンスフローであ
る。本発明のようなマルチスレッドシステムは単一プロ
セス内で複数のスレッドが同時に走ることを可能にす
る。スレッドに関する更に詳細な説明は、SunSoft が刊
行した、「Dr. Robert Hagmann 著、Concurrency Withi
n DOE Object Implementation, Version 0.91, May 27,
l993」を参照されたい。

【００２６】コンピュータプロセスのフレームワークの
直接的な結果として、単一プロセスの下に存在する全て
のエンティティは資源（例えばメモリとファイル）を共
有する。従って、単一プロセス中に存在する多目標オブ
ジェクトは効率的な相互通信を行うことになろう。その
上、単一プロセス中に存在する全てのオブジェクトがア
クセスできるメモリへデータをロ−ドすることができ
る。しかしプログラマは、（効率的な転送とデータの共
有以外の）他の動機を持つかも知れず、そうすると、単
一のプロセス中に多数のオブジェクトを持つことによる
利点が打ち消されてしまう。例えば、種々のオブジェク
トが種々の目的を持ち、当該プロセスに関して種々の仮
定に依存する可能性がある。これらの動機により、本発
明で開示するような整然としたマルチプロセス分散オブ
ジェクトオペレーティング環境が必要になる。プログラ
マが別々のプロセス中にオブジェクトを保持することが
できる場合、ＯＲＢは別々のプロセスの相互矛盾を防
ぎ、プロセス中のオブジェクトの統一性を維持すること
ができる。適切な点として、第１のサーバープロセス中
のオブジェクトがエラー状態に入り、そのサーバープロ
セスメモリ内において無秩序に書き始めるかも知れな
い。それでもなお、別々のサーバープロセス中を走るオ
ブジェクトは、これらのプロセスが独自の、メモリ、フ
ァイル、およびフローコントロールを持っているので手
つかずのままである。

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

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

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

【００３０】当業者が理解するであろうように、上記の
エンティティ（これは、クライアントであることができ
る）は、ホストコンピュータ上で走るプロセス（以下、
夫々、クライアントプロセスおよびクライアントホスト
という）およびオブジェクト（以下、クライアントオブ
ジェクトという）を、これらに限定せずに、含む。した
がって、クライアントは、エンティティのタイプに係わ
らず、サービスをリクエストする任意のエンティティで
ある。明瞭性のため、サービスを提供する任意のオブジ
ェクトを以下、目標オブジェクトという。更に、目標オ
ブジェクトを存在させているコンピュータプロセスをサ
ーバープロセスという。。

【００３１】クライアント-サーバー対話の用語を更に
説明すると、クライアントは、目標オブジェクトによっ
て実行される「方法」を「発動する（invoke）」ために
目標オブジェクトを「コール」する。「コール」と「発
動」とは意味が多少異なるが、ここではふたつの語は互
換性をもって用いられ、両語の意味はここでの考察の文
脈から理解される。以前の用語「方法」は、オブジェク
ト指向プログラミングの用語であって、特許出願の作成
で伝統的に用いられる用語「方法」とは異なることに注
目されたい。以下の考察において本出願人は、用語「方
法」がどちらの意味において用いられているか（文脈上
または本出願人の示唆により）明らかにされていると考
える。

【００３２】当業者には周知なように、「オブジェクト
方法」（または「方法」）は、目標オブジェクト内に含
まれている手順であって、この目標オブジェクトが当該
オブジェクトのサービスをリクエストする目的のために
他のエンティティ（例えばクライアント）に利用可能と
されている。従って、クライアントのためにサービスを
行うオブジェクトはサーバーであり、ここからクライア
ント-サーバー（client-server）なる用語が生まれる。
オブジェクト方法をコールする際、クライアントは、リ
クエストされた方法を目標オブジェクトが実行するのに
必要な、パラメーターとも呼ばれるアーギュメントを転
送してもよい。

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

【００３４】まず図３を参照すると、別々のホストコン
ピュータ上にクライアントオブジェクト３０２とターゲ
ットオブジェクト３０４が存在する「ホストからホスト
へ」と呼ばれるクライアント-サーバーモデル３００が
示されている。クライアントオブジェクト３０２はクラ
イアントホストコンピュータ３０８上で実行中のクライ
アントプロセス３０６内に存在する。クライアント３０
２オブジェクトは代理オブジェクト３１０を含み、これ
は、第１のインディレクション３１２をオブジェクトレ
ファレンス３１４へ与え、これが今度は第２のインディ
レクション３１６を目標オブジェクト３０４へ与える。
一般に、代理オブジェクト３１０はクライアントプロセ
ス内に存在する。しかし、この技術分野に精通した者
は、他の構成が適していることを理解するであろう。例
えば、代理オブジェクトは、従来のプログラミング言語
オブジェクトでもよい。更に、単一のオブジェクトレフ
ァレンス３１４へインディレクトする他の代理オブジェ
クトがあるかも知れない。ここで用いる場合、「インデ
ィレクション」とは、クライアントエンティティをロケ
ーターサービスへ差し向ける情報、ポインター等のセッ
トであって、このロケータサービスがクライアントエン
ティティをオブジェクトへ指向させることができる。た
とえ話をすると、あるクライアントが地理的方向をリク
エストしたとすると、インディレクションは、クライア
ントを現在の場所を向かせるか、あるいは多分、地理に
詳しい個人の電話番号をクライアントに教えるであろ
う。（直接のアドレシングよりも、むしろ）インディレ
クションを用いるというアイデアは、分散オブジェクト
（不変種類のもの）がプロセス同士間、ホストコンピュ
ータ同士間を移動できるので、分散オブジェクトにとっ
ては有利である。

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

【００３６】図４は、クライアントオブジェクト３０２
と目標オブジェクト３０４が同じホストコンピュータ、
すなわちクライアント／サーバーホスト３２２を共有し
ている「プロセスからプロセスへの」クライアント-サ
ーバーモデルを示す。しかし、クライアントオブジェク
ト３０２と目標オブジェクト３０４は、別々のプロセス
内に存在する。図３と同様に、クライアントオブジェク
ト３０２は、クライアント／サーバーホスト３２２上で
実行されているクライアントプロセス３０６内に存在す
る。クライアントオブジェクト３０２は、代理オブジェ
クト３１０を含み、代理オブジェクト３１０はインディ
レクション３１２をオブジェクトレファレンス３１４へ
与え、オブジェクトレファレンス３１４はインディレク
ション３１６を目標オブジェクト３０４へ与える。目標
オブジェクト３０４は、クライアント／サーバーホスト
３２２上で実行されているサーバープロセス３１８内に
存在する。「ホストからホストへ」の場合と同様に、プ
ロセスおよび／またはオブジェクト等の追加のエンティ
ティがクライアント／サーバーホスト３２２上に存在す
ることができる。このような適切なプロセスのひとつが
デーモン―１プロセスである。

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

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

【００３９】図６は、ＯＲＢデーモンプロセスが複数の
サーバープロセスと目標オブジェクトを管理するクライ
アント-サーバー対話の説明図である。図６は、本発明
の具体的数例において用いるための一般的なパラダイム
を示す。図６のパラダイムは、クライアント３５０、サ
ーバープロセス３５２、およびＯＲＢデーモンプロセス
３５４を含む。ステップ３５６において、クライアント
３５０は、目標オブジェクトに関するアドレシング情報
をリクエストするため、ＯＲＢデーモンプロセス３５４
をコールする。次に、もし必要ならば、ＯＲＢデーモン
プロセス３５４は、ステップ３５８においてサーバープ
ロセス３５２を起動する。サーバープロセス３５２はリ
クエストされた目標オブジェクトに関するサーバープロ
セスに対応する。ステップ３６０において、サーバープ
ロセス３５２は、ＯＲＢデーモンプロセス３５４に、サ
ービス提供準備完了である旨を表示することによって、
ステップ３５８に応答する。ステップ３６２において、
ＯＲＢデーモンプロセス３５４は、アドレシング情報を
クライアント３５０へ返す。一旦サーバープロセス３５
２が準備完了し、クライアント３５０がアドレシング情
報を持つと、クライアント３５０は、ステップ３６４に
おいてサーバー３５２をコールすることができ、サーバ
ー３５２は、ステップ３６６においてステップ３６４の
コールの結果を転送することができる。

【００４０】図６のパラダイムは、本発明によるクライ
アント-サーバー対話の全体的概観図を示す。本発明の
教示は、一般的に、ステップ３５８、３６０、および３
６２に関するメカニズムを与える方法、装置、およびデ
ータ構造に向けられている。他のステップは、本出願人
の別出願である、「弁理士書類番号：P717/SUN1P023、
発明の名称：オブジェクトの集合を管理するための方法
および装置、発明者：Vanderbilt 他」に更に詳細に記
載されている。

【００４１】次に、図７を参照して、本発明の好ましい
実施例によるＯＲＢデーモンプロセス４００を説明す
る。ＯＲＢデーモンプロセス４００は、（図１のネット
ワーク１０のような）分散ネットワークの一部である
（図２のコンピュータシステム３０のような）コンピュ
ータシステム上で実行するバックグラウンドプロセスで
ある。例えば、ＯＲＢデーモンプロセス４００の適切な
実施例のひとつは、図３のプロセス２（３２１）であろ
う。本発明の一面によれば、分散オブジェクトオペレー
ティング環境内の各コンピュータシステムが、内在する
ＯＲＢデーモンプロセス４００を持つことを想定する。

【００４２】図７の実施例において、ＯＲＢデーモンプ
ロセス４００は活動サーバーテーブル４０２、ロケータ
ーオブジェクト４０４、およびサーバープロセス登録オ
ブジェクト４０６を含む。もちろん、ＯＲＢデーモンプ
ロセス４００は、多数のスレッドのほか、他の多数のオ
ブジェクトを含むことができる。ロケーターオブジェク
ト４０４とサーバープロセス登録オブジェクト４０６と
は、共働してロケーターサービスを提供するが、これに
ついては後に詳細に説明する。しかし、ロケーターオブ
ジェクト４０４とサーバープロセス登録オブジェクト４
０６とは、ひとつのロケーターサービスを提供する、ひ
とつのオブジェクトにまとめることができる。オブジェ
クトアダプターデータベース４０８が、オプションとし
てＯＲＢデーモンプロセス４００内に存在することがで
きる。他方、オブジェクトアダプターデータベース４０
８は分散オブジェクトオペレーティング環境内のどこに
存在してもよい。いずれにしても、オブジェクトアダプ
タデータベース４０８は普通、サーバー識別子、目標オ
ブジェクト識別子、サーバー識別子と目標オブジェクト
識別子との間の相関関係、各目標オブジェクトに関する
execdef、および目標オブジェクトに関するオブジェク
トレファレンス等の、複数のオブジェクトに関する情報
を含む。ロケーターオブジェクト４０４は、オブジェク
ト方法ルックアップ目標オブジェクト４１０を含み、サ
ーバープロセス登録オブジェクト４０６はオブジェクト
方法登録サーバー４１２と登録新サーバー４１４を含
む。これらのオブジェクト方法は、図８の考察の直後に
更に詳細に説明する。

【００４３】図８は、本発明の一実施例による活動サー
バーテーブル４０２に関するデータ構造を示す。活動サ
ーバーテーブル４０２は図２のＯＲＢデーモンプロセス
に割り当てられたＲＡＭ３４または大量記憶装置３８の
ようなメモリに格納され、当業者になじみの多くの方法
のひとつによって管理することができる。図８の実施例
においては、活動サーバーテーブル４０２は、複数のサ
ーバー要素４１９を含み、各要素４１９は、サーバー識
別子４２０のようなエントリ、サーバープロセス状態４
２２、アドレシング情報４２４、およびサーバープロセ
ス識別事項４２６を含む。サーバープロセス状態４２２
は「実行中」または「起動中」のいずれでもよい。しか
し、クライアントがリクエストしたプロセスが活動サー
バーテーブル４０２中に見いだされない場合、サーバー
プロセスは「非活動」であるという。

【００４４】アドレシング情報４２４は、ローカル転
送、共有メモリ、またはリモート転送等、（これらに限
られない）転送モード用の複数のアドレスを含む。ロー
カル転送は同じプロセス内で発生し、同じアドレススペ
ース内でデータをコピーすることによって実行される。
共有メモリ転送（「同一ホスト」転送とも呼ばれる）
は、ホストオペレーティングシステムインタープロセス
通信手順（host operatingsystem inter-process commu
nication procedure）を用いて実行される。リモート転
送はネットワーキング設備を用いて実行される。これら
の各々は、オペレーティングシステムやネットワーク通
信プロトコル等の要因によって変る。したがって、アド
レシング情報もそれに応じて変り得る。ローカル、共
有、およびリモートの各転送の設計と実装は、当業者に
はなじみである。転送モードと適当なアドレシング情報
は、本出願人の別出願である「弁理士書類番号：P721SU
N1P025、発明の名称：オブジェクト管理の方法、装置、
およびデータ構造、発明者： brownell 他」で更に詳細
に考察されている。

【００４５】サーバープロセス識別事項４２６は、普
通、プロセスが実行されているホストコンピューターの
オペレーティングシステムによって、あるプロセス（そ
の具体化のために）に割り当てられた識別番号である。
サーバープロセス識別事項４２６は、同じ識別番号とと
もにふたつのサーバープロセスが共存しないという意味
において、一義的である。しかし、サーバープロセス識
別番号の数は、普通は有限である（例えば、３２Ｋが適
当である）ので、サーバープロセス識別番号はリサイク
ルすることができる。サーバー識別子４２２は、ＯＲＢ
によって割り当てられ、ＯＲＢデーモンプロセス４００
に内では永久的に一義的なのが普通であるので、サーバ
ープロセス識別事項４２６とは異なる。

【００４６】再び、図７を参照すると、ロケーターオブ
ジェクト４０４の一実施例はルックアップ目標オブジェ
クト４１０と称するオブジェクト方法を持っている。ク
ライアントが（図６のステップ３５６のように）ルック
アップ目標オブジェクト４１０を発動するために、ロケ
ーターオブジェクト４０４をコールするとき、クライア
ントはリクエストされる目標オブジェクトを一義的に定
義するアーギュメントを転送する。アーギュメントとし
て適当なものは、サーバー識別事項４２０および／また
は目標オブジェクト識別子のようなデータがある。応答
として、ロケーターオブジェクト４０４はリクエストさ
れたサービスを実行するが、一実施例においては、この
サービスは、ターゲットオブジェクトが存在するサーバ
ープロセスが走っているか否かを判定するステップと、
サーバープロセスを起動する必要がある場合にサーバー
プロセスをフォーク（fork）し実行するステップと、サ
ーバープロセスが、（図６のステップ３６２におけるよ
うに）リクエストの受信準備完了になるとクライアント
へサーバープロセスアドレシング情報を返すステップと
を含む。ロケーターオブジェクト４０４のようなロケー
ターオブジェクトを用いる本発明の一方法面を、図１０
を参照して以下に更に詳細に説明する。

【００４７】更にひとつの実施例において、図７のサー
バープロセス登録オブジェクト４０６は、登録サーバー
４１２と登録新サーバー４１４のふたつのオブジェクト
方法を持つ。クライアントが登録サーバー４１２を発動
するためサーバープロセス登録オブジェクト４０６をコ
ールするとき、クライアントは、サーバー識別子、サー
バープロセス識別事項、およびアドレシング情報を含む
アーギュメントを転送する。サーバープロセス登録オブ
ジェクト４０６は、これらのアーギュメントを活動サー
バーテーブル４０２に格納し、サーバープロセス状態エ
ントリを「実行中」として活動サーバーテーブル内にマ
ークする。クライアントが登録新サーバー４１４を発動
するために、サーバープロセス登録オブジェクト４０６
をコールするとき、クライアントは、サーバープロセス
識別事項、アドレシング情報、およびオブジェクトレフ
ァレンスを含むアーギュメントを転送する。一実施例に
おいて、サーバープロセス登録オブジェクト４０６は、
オブジェクトアダプターデータベース４０８からサーバ
ー識別子を獲得し、活動サーバーテーブル４０２内にサ
ーバープロセスエントリを生成し、活動サーバーテーブ
ル４０２内にアドレシング情報を格納し、サーバープロ
セス状態を活動サーバーテーブル４０２内に「走行中」
としてマークし、サーバー識別子をサーバープロセスへ
返す。サーバープロセス登録オブジェクト４０６のよう
なオブジェクトを用いる本発明の方法面を図１１ないし
図１４を参照して更に詳細に説明する。

【００４８】本発明の方法面を主としてサーバーの観点
から考察し、実質的に２つのカテゴリに分ける。第１の
カテゴリにおいては、サーバープロセスを（フォークと
実行、および登録を含み）管理するための方法を開示す
る。それぞれ、図７のＯＲＢデーモン４００を用いる第
１のケースの好ましい実施例を図１０、１２、１３を参
照して以下に説明する。第２のカテゴリにおいては、サ
ーバープロセスを起動させる方法（図１０、１２、１３
の方法に対応）を開示する。好ましい実施例を図１２と
図１４を参照して以下に説明する。この方法の観点がサ
ーバーの観点であっても、本発明の方法に対する必要性
は、しばしばクライアントのコールに応じて発生する。
したがって、明瞭にするため、図１０ないし図１４の方
法を考察する前にクライアントの観点からのクライアン
ト-サーバー対話を簡単に考察する。

【００４９】次に、図９を参照して、本発明の一実施例
による目標オブジェクトを発動する方法１９６を説明す
る。目標オブジェクト発動方法は、ステップ１９８にお
いて、クライアントホスト上のクライアントプロセス内
で実行されているクライアントオブジェクトが目標オブ
ジェクトの発動を開始すると、開始される。しかし、よ
り一般的なケースにおいては、クライアントはオブジェ
クトである必要はない。普通、クライアントオブジェク
トは目標オブジェクト（すなわちオブジェクトレファレ
ンス）へのインディレクションをひとつだけ持ち、目標
オブジェクトのインターフェイス要件（あるいは、それ
が求めている情報に適用されるインターフェイス要件の
少なくとも一部）を知っている。したがって、発動は、
クライアントオブジェクトがオブジェクトレファレンス
を用いて目標オブジェクトを識別するコールを用いて目
標オブジェクトをコールするとき開始され、目標オブジ
ェクトのインターフェイス要件を充たすのに必要なアー
ギュメントを提供する。ステップ２００に示すように、
クライアントプロセスは、クライアントプロセス内に位
置する目標オブジェクトの代理へのコールによってクラ
イアントオブジェクトのコールに応答する。同一マシン
上でまた同一プロセス内で、目標オブジェクト代理の生
成および／またはクライアントオブジェクトと目標オブ
ジェクト代理との間の接続形成のための適切な方法は、
当業者には周知である。一例においては、オブジェクト
レファレンスは代理のメモリアドレスへのポインターで
よい。普通、代理は発動へのアーギュメントがアンマー
シャルされたとき、または発動からの回答がアンマーシ
ャルされたとき生成される。例えば、目標オブジェクト
代理を生成するための適切な方法は、本出願人の別出願
である、「弁理士書類番号：P721/SUN1P024、発明の名
称：分散オブジェクトシステムにおけるオブジェクトの
タイプ判定方法および装置、発明者：Vanderbilt 他」
に説明されている。。

【００５０】目標オブジェクト代理がコールを受信する
と、代理は、それが、サーバーホスト上に存在する目標
オブジェクトサーバントに関するアドレシング情報を既
に持っているか否かを判定する。代理がアドレシング情
報を持っている場合、プロセス制御は直接ステップ２１
６へ進み、必要ならば、サーバープロセスとの接続を
（以下に詳細に説明するように）形成する。他方、代理
が目標オブジェクトサーバントに関するアドレシング情
報を持っていない場合、接続を形成する前にこの情報を
獲得しなければならない。後者の場合、目標オブジェク
ト代理はステップ２０４へ進み、そこでサーバーホスト
の場所を見いだす。サーバーホストはオブジェクトレフ
ァレンスにおいて識別されることを理解すべきである。
したがって、目標オブジェクト代理がＯＲＢにコンタク
トし、ＯＲＢが目標オブジェクト代理に、サーバーホス
ト上で走っているＯＲＢデーモンプロセスに関するアド
レシング情報を提供する。

【００５１】次に、ステップ２０７において、目標オブ
ジェクト代理はサーバーホスト上でＯＲＢデーモンプロ
セスとのネットワーク接続を形成する。しかし、代理が
ＯＲＢデーモンプロセスとの間に既に形成された接続を
有する場合、第２の接続を形成する必要はない。いずれ
にしても、一旦適切な接続が形成されると、目標オブジ
ェクト代理はステップ２０９において、ＯＲＢデーモン
プロセスが、目標オブジェクトサーバントを実行してい
るサーバープロセスに関するアドレシング情報を返すよ
うにリクエストする。この情報をリクエストする適切な
方法のひとつは、ロケーターオブジェクトをコールして
ルックアップ方法を発動することである。もちろん、ス
テップ２０７と２０９は、論理的には別々のステップと
して説明したが、これらは単一のコールとして同時に実
行してもよい。プロセス間に接続を形成する方法は、こ
の技術分野においては周知である。前記プロセスを形成
するための適切な方法のひとつは、本出願人の別出願で
ある、「弁理士整理番号：P715/SUN1P018、発明の名
称：分散オブジェクトシステムにおけるオブジェクト間
の通信用接続管理の方法および装置、発明者：Brownell
他」に説明されている。

【００５２】ステップ２０７と２０９に応答して、ＯＲ
Ｂデーモンは起動し、サーバープロセスを登録し、そし
てアドレシング情報をクライアントへ返さねばならな
い。サーバーホストのＯＲＢデーモンプロセスが進むこ
とのできる適切な方法を以下に図１０ないし図１２を参
照して説明する。しかし、目標オブジェクト代理の観点
からは、それはリクエストされたサーバープロセスアド
レシング情報をステップ２１４において受け取るにすぎ
ない。保有するこの知識によって代理は、ステップ２１
６において適切なサーバープロセスとの直接的接続を形
成することができる。もちろん、サーバープロセス内で
実行されているもうひとつの目標オブジェクトへのそれ
以前のコールほか様々な理由で、クライアントプロセス
が予めこの同じサーバープロセスとの接続を形成した可
能性もある。この場合、サーバープロセスとの接続を形
成することが必要であるかもしれないし、ないかも（ま
たは望ましくないかも）しれない。

【００５３】ステップ２１６において接続が形成される
と、目標オブジェクト代理は、ステップ２１８において
目標オブジェクト識別子とコールのためのアーギュメン
トをマーシャルする。ここで、データを「マーシャルす
る」とは、ネットワーク転送のための準備として所定の
ネットワーク通信プロトコルに（例えば、よく知られて
いるＴＣＰ／ＩＰ）従ってデータをフォーマットするこ
とである。更に、データを「マーシャルする」とは、共
有メモリ転送のために所定のプロトコルに従って、デー
タをフォーマットすることでもあり得る。当業者には理
解されるように、ネットワークフォーマットと共有メモ
リフォーマットとは同一であり得る。マーシャリングの
性質は、オペレーション中の特定のネットワーク（また
は、共有メモリ）上の通信に用いられるプロトコルの性
質に全く依存し、その実装は当業者には明らかななずで
ある。次にステップ２２０において、目標オブジェクト
代理は、ステップ２１６において形成された接続を介し
て目標オブジェクトへリモートコールを行う。このコー
ルの結果、ステップ２２２において、目標オブジェクト
代理はステップ２１６の目標オブジェクトコールの結果
を受信しアンマーシャルする。結果がアンマーシャルさ
れると、目標オブジェクト代理はアンマーシャルされた
結果をステップ２２５においてクライアントオブジェク
トへ返す。そうすると、クライアントは返された結果を
適切に使用する。

【００５４】ここで、本発明のひとつの方法面を図１０
を参照して説明する。図１０の方法は図９のステップ２
０９への応答であり、一実施例においてＯＲＢデーモン
プロセスによって実行される。図１０の方法の実行のス
レッドは、ステップ５００においてロケーターオブジェ
クト４０４がターゲットオブジェクトへのルックアップ
コールを受けると開始される。このルックアップコール
は、（必要な場合）ロケーターオブジェクト４０４への
コールを準備するＯＲＢデーモンプロセスを介して受信
されることに注目されたい。例えば、ＯＲＢデーモンプ
ロセスはコールおよび任意のアーギュメントをアンマー
シャルすることができる。この発動の受信に加えて、ロ
ケーターオブジェクト４０４は目標オブジェクト識別子
のような必要なアーギュメントを受信する。次にステッ
プ５０２において、ロケーターオブジェクト４０４は、
リクエストされた目標オブジェクトに対応するサーバー
識別子を獲得するため、オブジェクトアダプターデータ
ベース４０８にアクセスする。適当な一実装において、
ロケーターオブジェクト４０４は、対応するサーバー識
別子を見いだすため、ステップ５００において受信した
目標オブジェクト識別子をキーとして用いて、オブジェ
クトアダプターデータベース４０８をサーチする。一旦
ロケーターオブジェクト４０４がサーバー識別子４２０
を持つと、それはステップ５０４においてサーバー状態
エントリ４２２を読んで、サーバープロセスの状態を判
定するために、活動サーバーテーブル４０２を通覧す
る。一実施例において、ロケーターオブジェクト４０４
は、活動サーバーテーブル４０２内の対応する状態エン
トリ４２２を見いだすため、サーバー識別子４２０をキ
ーとして用いる。図８に関して先に説明したように、サ
ーバープロセスのあり得る状態としては、実行中、起動
中、および非活動がある。

【００５５】ステップ５０６において、サーバープロセ
スが活動サーバーテーブル４０２に載っているか否かを
判定する。載っている場合、制御はステップ５０８へ分
岐し、そこでサーバープロセスの状態が起動中であるか
否かを判定する。サーバープロセスの状態が起動中でな
い場合、サーバープロセスは実行中であり、制御は５１
０へ進み、そこで活動サーバーテーブル４０２からアド
レシング情報４２４が読まれ、クライアントへ返され
る。クライアントは、ローカルまたはリモートのいずれ
かであり、したがって、転送はそれに応じて行われねば
ならないことに注目されたい。例えば、クライアントが
リモートである場合、アドレシング情報４２４はネット
ワーク転送のための準備としてマーシャルされねばなら
ない。

【００５６】ステップ５０８の ＹＥＳ 分岐（すなわち
サーバープロセスの状態が起動中）をステップ５１３へ
たどると、ロケーターオブジェクト４０４は、活動サー
バーテーブル４０２の状態エントリ４２２が起動中から
実行中に変化するのを待たねばならない。当業者には周
知であるように、この「待機状態」は、ロケーターオブ
ジェクト４０４に関する実行のスレッドを「ロックする
こと」によって行うことができる。ステップ５１３にお
いて、サーバープロセスの状態が実行中になるまでスレ
ッドがロックされている。たとえ、現在リクエストされ
た目標オブジェクトが予めリクエストされていなくて
も、サーバープロセスが実行中または起動中であり得る
ことに注目されたい。その理由は、単一のプロセスのも
とで複数のオブジェクトが存在し得るという本発明の教
示である。本発明は、リクエストされる各目標オブジェ
クトに関して、重複するプロセスが必ずしも起動されな
いようにサーバープロセスをチェックし、管理するとい
う特徴によって、このことを可能にしている。いずれに
しても、一旦サーバープロセスが走ると、制御はステッ
プ５１０に進み、そこでアドレシング情報がクライアン
トへ返される。ここでも、アドレシング情報はネットワ
ーク転送のための準備としてマーシャルされ得る。

【００５７】ステップ５００においてリクエストされた
目標オブジェクトが適正な既存の目標オブジェクトであ
った場合、対応するサーバー識別子がオブジェクトアダ
プターデータベース４０８内で見いだされる。しかし、
このサーバープロセス識別子に対応するサーバープロセ
ス内に存在する目標オブジェクトを、予めリクエストし
たクライアントがないこともあり得る。その場合、サー
バープロセスは非活動的で、そのサーバー識別子は、活
動サーバーテーブル４０２に載っていないであろう。そ
のため、サーバープロセスの状態は非活動的であるとい
われる。したがって、ステップ５０６の ＮＯ 分岐（す
なわちサーバー識別子が活動サーバーテーブル４０２に
載っていない）をステップ５１４へたどると、ロケータ
ーオブジェクト４０４は活動サーバーテーブル４０２内
にサーバープロセスエントリを生成し、サーバープロセ
ス４２２の状態を起動中とマークする。状態を起動中と
することによって、ロケーターオブジェクト４０４（51
4 は誤り）は、他のクライアントがこのサーバープロセ
スに係わるリクエストをした場合に起こり得るエラーを
防止する。

【００５８】次に、ステップ５１６でロケーターオブジ
ェクト４０４は、目標オブジェクトに関する execdef
を獲得するため、オブジェクトアダプターデータベース
４０８にアクセスする。他の実施例においては、execde
f はステップ５０２等、他のステップにおいて獲得する
ことができる。説明としては、execdef はサーバープロ
セスに関するスタートアップ手順と見なすことができ
る。例えば、execdef は、ディレクトリパス（director
y path）、実行可能なファイル名、およびアーギュメン
トのリストを含むことができる。ロケーターオブジェク
ト４０４が一旦目標オブジェクトに関する execdef を
持つと、ロケーターオブジェクト４０４はステップ５１
８において execdef を用いてサーバープロセスを 「フ
ォークし、実行する(fork and exec)」するように進
む。これは、図１０のスレッドからの新しいプロセス分
岐の実行の新しいスレッドであって、実行可能なファイ
ル名としてリストに載っているプログラムを実行するよ
うに進み、このことから「フォークし、実行する」とい
う語句が生まれた。この語句は、当業者にはなじみであ
る。ステップ５１８の「フォークし、実行する」の後、
ロケーターオブジェクト４０４はステップ５１３へ進
み、そこでロケーターオブジェクト４０４は活動サーバ
ーテーブル４０２のサーバープロセス状態エントリ４２
２が起動中から走行中に変化するのを待たねばならな
い。一旦サーバープロセスが走ると、制御はステップ５
１０に進み、そこでアドレシング情報がクライアントへ
返される。

【００５９】いずれにしても、ステップ５１０において
アドレシング情報がクライアントへ返されると、制御は
５１２へ進み、そこで目標オブジェクトをルックアップ
するオペレーションが完了する。図１０の他の実施例も
想定される。特に、サーバープロセス状態には、「利用
不可能」や「存在せず」といった、サーバープロセス状
態４２２に対応する、追加の状態が存在する可能性があ
る。いずれにしても、クライアントへエラーメッセージ
を返す等、適切なステップを、ロケーターオブジェクト
４０４が行うことができる。その外に、「すべてのリク
エストを前送りせよ」という状態もあり得る。その場
合、ロケーターオブジェクト４０４は、「入れ替え」目
標オブジェクトおよび／またはサーバープロセスに関す
るアドレシング情報を返すことができる。

【００６０】図１０の方法にその他の変形も想定され
る。分散オブジェクトオペレーティング環境の通常のオ
ペレーション中、目標オブジェクトおよび／またはサー
バープロセスが一時的に（または永続的に）利用不可能
なことがあるかも知れない。例えば、バックアップ、コ
ードの固定、または新しいオブジェクトのインストール
等のメインテナンスオペレーションは、目標オブジェク
トおよび／またはサーバープロセスを無効にする（disa
ble）かも知れない。本発明の一実施例によれば、三つ
の状態が可能である。すなわち、長時間ホールドダウ
ン、短時間ホールドダウン、およびホールドダウン無し
である。ホールドダウンが無い場合、目標オブジェクト
とサーバープロセスはともに利用可能であり、ロケータ
ーオブジェクト４０４の実行のスレッドは図１０に関し
て説明した通りに進むことができる。短時間ホールドダ
ウンの場合、実行のスレッドは、図１０のステップ５１
３のように、一時的に阻止される。このケースは、遅れ
が比較的短い場合に適当であろう。長時間ホールドダウ
ンの場合、クライアントへエラーメッセージが返される
であろう。これは、目標オブジェクトおよび／またはサ
ーバープロセスが永続的に利用不可能、あるいは比較的
長時間利用不可能であった場合に適当であろう。ホール
ドダウン情報を格納するのに適当な場所のひとつは exe
cdef 内である。次に、図１０のステップ５０４を拡張
し、ホールドダウンを判定し適切なステップを実行する
ステップを更に含めることができる。

【００６１】次に、図１１を参照して、本発明の一実施
例によるサーバープロセスの起動方法を説明する。例え
ば、サーバープロセスは、図１０の「フォークし、実行
する」ステップ５１８への応答としてステップ５５０で
起動することができる。次にステップ５５２において、
サーバープロセスは転送サービスをコールして、通信ポ
ートを生成し、そのアドレシング情報をサーバープロセ
スのために形成する。当業者には理解できるように、転
送サービスは、ホストコンピュータオペレーティングシ
ステムの一部または分散オブジェクトオペレーティング
環境の一部として実装することができる。次にステップ
５５４において、サーバープロセスは登録サーバーオペ
レーションを発動するため、サーバープロセス登録オブ
ジェクト４０６をコールし、アーギュメントとしてサー
バー識別子４２０、アドレシング情報４２４、およびサ
ーバープロセス識別子４２６を転送する。この情報を用
いて、サーバープロセス登録オブジェクト４０６は、図
１２に関して以下に更に詳細に説明するように、サーバ
ープロセスを一義的に登録することができ、それによっ
て本発明の利点が永続する。一旦このコールが行われて
サーバープロセスが登録されると、サーバープロセスは
ステップ５５６におけるリクエスト処理準備完了とな
る。

【００６２】次に、図１２を参照して、本発明の一実施
例に従ってサーバープロセスを活動サーバーテーブル４
０２へ登録する方法を説明する。例えば、サーバープロ
セス登録オブジェクトは、図１１のステップ５５４のよ
うに発動に応答して登録を実行することができる。ステ
ップ５７０において、サーバープロセス登録オブジェク
ト４０６は、サーバ識別子４２０、アドレシング情報４
２４、およびサーバープロセス識別事項４２６等のアー
ギュメントを含む登録サーバ発動を受ける。次に、ステ
ップ５７２において、サーバープロセス登録オブジェク
ト４０６は、アドレシング情報４２４を活動サーバーテ
ーブル４０２内へ格納する。このサーバプロセス（サー
バ識別子４２０によって識別される）に関するエントリ
は図１０のステップ５１４のようなステップにおいて生
成されたことに注目されたい。次に、ステップ５７４に
おいて、サーバープロセス登録オブジェクト４０６は、
サーバープロセス状態４２２を走行中であるとしてマー
キングする。この状態がマーキングされた実行中である
と、サーバープロセス登録オブジェクト４０６はリクエ
ストされたサービスを完了し、ステップ５７６において
行われる。

【００６３】理解されるように、図９ないし図１２のす
べての方法は、図６のクライアント-サーバーパラダイ
ムに関して説明したように、ステップ３５６ないし３６
２にまたがるひとつのクライアント-サーバー対話に組
み込むことができる。図９ないし図１２の各々は、実行
の別々のスレッドを表すものと解釈することができ、本
発明の一実施例はこのように実行することができる。更
に、これらのスレッドは単一スレッドのシステム上での
実行（implementation）用に単一スレッドへまとめる
（collapsed）ことができる。種々のスレッドによる手
法の利点は、それらの実行と構造とともに、当業者には
なじみであろう。代替として、様々な実施例が、図３な
いし図５に関して説明した様々なクライアント-サーバ
ー対話の方法を提供するであろう。上記に鑑み、上記お
よび更に追加の実施例をどのように作成し実行するか
は、当業者には明らかであり、それらはすべて本発明の
範囲内に入る。

【００６４】図９ないし図１２の上記考察の基礎は、Ｏ
ＲＢデーモンプロセス４００がサーバープロセスを起動
したという仮定である。しかし、必ずしも常にそうでは
ない。例えば、クライアントはコールを直接目標オブジ
ェクトへ転送することができるが、それでも目標オブジ
ェクトおよび／またはサーバープロセスは活動していな
いかも知れない。もうひとつの例において、分散オブジ
ェクトおよび／またはその対応するサーバープロセス
が、他の多くの理由によって起動したがるかも知れない
（例えば特定のオブジェクトおよび／またはプロセスは
常にパワーアップと同時に実行される）。いずれの例に
おいても、サーバープロセスが「自己起動」（すなわち
スタートアップし、登録）するためには、ひとつのメカ
ニズムが必要である。自己起動サーバーに関する二三の
方法を図１３と図１４を参照して以下に説明する。

【００６５】図１３を参照して、本発明の一実施例に従
ってサーバープロセスを自己起動（すなわち自分で起動
し、登録）する方法を説明する。第一のステップ６００
において、クライアントはオブジェクト方法を発動する
ためにコールするが、これは大ざっぱに「サーバーにな
る(become server)」と表現することができる。一実施
例において、クライアントはまた所望の目標オブジェク
トを識別するためオブジェクトレファレンスを転送し、
それによって対応するサーバープロセスを指定する。他
の実施例においては、最初のステップ６００は、自己起
動を開始するオブジェクトに対応するに過ぎないかも知
れない。いずれにしても、最初のステップ６００の後、
オブジェクトはステップ６０２において、転送をコール
してサーバープロセスのためのポートを生成しサーバー
プロセスに関するアドレシング情報を形成する。ここで
も、アドレシング情報は、リモートモード、共有メモリ
モード、およびローカルモードの各アドレスを含む。ス
テップ６０２は図１１のステップ５５２に類似であるこ
とに注目されたい。

【００６６】一旦サーバープロセスアドレシング情報が
形成されると、サーバープロセスはＯＲＢデーモンプロ
セスに登録する必要がある。したがって、サーバープロ
セスはステップ６０４においてサーバープロセス登録オ
ブジェクト４０６に関するオブジェクトレファレンスを
得る。サーバープロセス登録オブジェクト４０６に関す
るオブジェクトレファレンスは、サーバープロセス登録
オブジェクト４０６との通信に必要なインディレクショ
ンを与える。例えば、サーバープロセスは、このオブジ
ェクトレファレンスを獲得するためにＯＲＢを用いるこ
とができる。それが一旦オブジェクトレファレンスを持
つと、サーバープロセスはステップ６０６において、オ
ブジェクト方法登録新サーバー４１４を発動するため、
サーバープロセス登録オブジェクト４０６をコールし、
サーバープロセス識別事項４２６、アドレシング情報４
２４、および目標オブジェクトに関するオブジェクトレ
ファレンスとをアーギュメントとして転送する。サーバ
ープロセスは、そのサーバー識別子４２０を知っている
場合、それを目標オブジェクトのオブジェクトレファレ
ンスの代わりに転送する。この発動に対するサーバープ
ロセス登録オブジェクトの応答の一実施例を、図１４を
参照して以下に説明する。次に（もし必要ならば）、ス
テップ６０８において、サーバープロセスはそのサーバ
ー識別子４２０をサーバープロセス登録オブジェクト４
０６から戻し受ける。このようにして、サーバープロセ
スが登録され、一義的に定義され、ステップ６１０にお
けるリクエスト処理準備完了となる。

【００６７】ここで、図１４を参照して、新しいオブジ
ェクトを登録するためのサーバープロセス登録オブジェ
クト４０６に関するひとつの方法を考察する。ステップ
６２０において、サーバープロセス登録オブジェクト４
０６は、登録新サーバー４１４の発動を、サーバープロ
セス識別事項４２６、アドレシング情報４２４、および
目標オブジェクトに関するオブジェクトレファレンスを
含むアーギュメントとともに受け取る。例えば、この発
動は図１３のステップ６０６によって行うことができ
る。次にステップ６２２において、サーバープロセス登
録オブジェクト４０６は、オブジェクトアダプターデー
タベース４０８からサーバー識別子４２０を得るため、
目標オブジェクトに関するオブジェクトレファレンスを
用いる。次にステップ６２４において、サーバープロセ
ス登録オブジェクト４０６；活動サーバーテーブル４０
２内にサーバープロセスエントリを生成するステップ
と、活動サーバーテーブル４０２内にアドレシング情報
４２４を格納するステップと、サーバープロセス状態エ
ントリ４２２を走行中としてマーキングするステップと
を実行する。ここで新しいサーバープロセスが登録さ
れ、ステップ６２６において、サーバープロセス登録オ
ブジェクト４０６は、サーバー識別子４２０をサーバー
プロセスへ転送する。ステップ６２６が、図１３のステ
ップ６０８において得られた情報を送ることに注目され
たい。そして図１４の方法はステップ６２８で完了す
る。

【００６８】本発明のわずか数実施例を説明したが、本
発明はその精神または範囲から逸脱することなく他の多
くの具体的形態において実施可能であることを理解すべ
きである。図３ないし図５に関連して説明したクライア
ント-サーバーモデルは、単なる見本であって、決して
限定的なものと解釈してはならない。例えば、「ホスト
からホストへ」のモデルは、複数の目標オブジェクトを
含むように拡張可能である。すなわち、第一の目標オブ
ジェクト３０４は、多分もうひとつの分散オブジェクト
環境における、もうひとつの目標オブジェクトへインデ
ィレクトするオブジェクトレファレンスに過ぎないこと
があり得る。このようにして、複数のサーバープロセス
が、サービスを求める最初のリクエストの結果として起
動することができる。あるいは、第１の目標オブジェク
トはリクエストされたサービスの一部を実行し、第１の
クライアントオブジェクト３０２へ応答する前に、それ
自体のコールを第２の目標オブジェクトへ行うことがで
きる。理解できるように、多くの実施例を列挙すること
ができるが、すべて本発明の範囲内に入る。更に、これ
らの例の各々は、当業者には明らかな様々な実施例を介
して、ここに開示したＯＲＢデーモンによって管理する
ことができる。

【００６９】活動サーバーテーブル４０２のデータ構造
と場所は大幅に変更することができるが、それでもなお
本発明の範囲内に入る。第１の例として、活動サーバー
テーブル４０２はＯＲＢデーモンプロセスとは別のプロ
セス内に配置することができる。更に、活動サーバーテ
ーブル４０２内に格納された情報はオブジェクトアダプ
ターデータベース４０８内で保守することができるとと
もに、逆のことも可能である。更に、別々の分散オブジ
ェクトオペレーティング環境はサーバープロセスを一義
的に識別ための要件を持つことができる。これらの場
合、活動サーバーテーブル４０２内のエントリは相応に
拡張および／または縮小できる。更にまた、これらの各
々は、説明したデータ構造の特定の編成を必要とするか
も知れない。これら多数の実施例の各々の構成と実装
は、当業者には明らかである。

【００７０】分散オブジェクトシステムに精通した者に
は理解できるように、サーバープロセスおよび目標オブ
ジェクトを管理するための、上記の方法の背景に内在す
る思想は、非常に様々な実施例として実行することがで
き、詳細に考察するには余りにも多い。しかし、基礎に
なる哲学を説明したので、当業者には様々な代替例が明
らかであろう。例えば、ロケーターオブジェクト４０４
内に含まれるオブジェクト方法およびサーバープロセス
登録オブジェクト４０６を数個の追加のオブジェクトへ
拡散したり、あるいはロケーターサービスと呼ぶことが
できるひとつのオブジェクトへ組み合わせることもでき
る。更に、本発明を実行する(implement)ために、（ス
レッドの他に）実行制御用の他のプロセスも用いること
もできる。

【００７１】したがって、これらの例は説明のためであ
って、限定するためではないと考えるべきもので、本発
明はここに示された詳細事項に限定されない。

【図面の簡単な説明】

【図１】コンピュータネットワーク内で相互に接続され
た種々のコンピュータを示す図である。

【図２】図１の一台のコンピュータの主要なコンポーネ
ントの概略図である。

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

【図４】プロセス対プロセスのクライアント-サーバー
モデルであり、一台のクライアント／サーバーホストコ
ンピュータ上の異なったプロセス中を走るクライアント
とサーバーとの間の関連性の説明図である。

【図５】単一のクライアント／サーバープロセス中で実
行されるクライアントとサーバーとの間の関連性を表す
クライアント-サーバーモデルの説明図である。

【図６】ＯＲＢデーモンプロセスがサーバープロセスの
起動と登録を管理する、クライアント-サーバーの対話
パラダイムの説明図である。

【図７】本発明の一実施例に従うＯＲＢデーモンプロセ
スの説明図であり、このＯＲＢデーモンプロセスは、活
動サーバーテーブル、ロケ−タオブジェクト、サーバー
プロセス登録オブジェクト、および（任意に）オブジェ
クトアダプタデータベースを含む。

【図８】図７の活動サーバーテーブルに関するデータ構
造の一実施例の説明図であり、このデータ構造は、サー
バー識別子のようなエントリを各々が含む多数の活動サ
ーバーエレメントと、サーバープロセス状態と、サーバ
ーアドレシング情報と、サーバープロセス識別番号を有
している。

【図９】クライアントにより実行されて分散サーバーオ
ブジェクトを発動するプロセスを示すフローチャートで
ある。

【図１０】ルックアップの発動に応答してサービスを実
行中である、ロケ−タオブジェクトの、いくつかの可能
性のある実行のスレッドを示すフローチャートである。

【図１１】サーバープロセスの始動の実行のスレッドを
示すフローチャートである。

【図１２】登録サーバーの発動に応答してサービスを実
行中である、サーバープロセス登録オブジェクトの実行
のスレッドを示すフローチャートである。

【図１３】サーバープロセス「自己起動(self-startin
g)」の実行のスレッドを示すフローチャートである。

【図１４】登録新サーバー発動に応答してサービスを実
行中である、サーバープロセス登録オブジェクトの実行
のスレッドを示すフローチャートである。

【符号の説明】

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

フロントページの続き (72)発明者 ケニース エム． カバナフ スリー アメリカ合衆国， カリフォルニア州 94037−1480， モンタラ， フィフス アベニュー 357 (72)発明者 デイビッド エム． ブロウネル アメリカ合衆国， カリフォルニア州 94306， パロ アルト， パーク ブル バード 2569 ナンバーティー−201 (72)発明者 ロバート ビー． ハグマン アメリカ合衆国， カリフォルニア州 94303， パロ アルト， メイビュー アベニュー 749 (72)発明者 ドワイト エフ． ヘア アメリカ合衆国， カリフォルニア州 95076， ラ セルバ ビーチ， ブリー ブ アベニュー １ (72)発明者 ピーター ヴァンダービルト アメリカ合衆国， カリフォルニア州 94043， マウンテン ビュー， ボーメ コート 440

Claims (34)

【特許請求の範囲】
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. 【請求項３４】 請求項３３記載の新サーバー登録オペ
    レーションを発動するコールへの応答するサーバープロ
    セス登録オブジェクトに関しての、コンピュータに実装
    された方法であって、 コンピュータ制御のもとで、オブジェクトアダプタデー
    タベースからサーバー識別子を獲得するステップと、 コンピュータ制御のもとで、活動サーバーテーブル内に
    サーバープロセスエントリを生成するステップと、 コンピュータ制御のもとで、前記活動サーバーテーブル
    内に前記アドレシング情報を格納するステップと、 コンピュータ制御のもとで、前記活動サーバーテーブル
    内のサーバープロセス状態エントリを実行中にするステ
    ップと、 コンピュータ制御のもとで、前記サーバー識別子を前記
    サーバープロセスへ送信するステップと、 を備える方法。