JPH1063523A - マルチスレッド環境においてサーバの活動化を制御する方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 古いサーバのシャットダウンと新しいサーバ
の始動との間に競合状態が存在し、さらに、デーモン・
サーバなど、高速に再始動するサーバはスラッシング動
作を行う傾向がある。それを解決したサーバの活動化を
制御する方法を提案する。 【解決手段】 ＯＲＢデーモン内で実行されるサーバ有
限状態マシンに追加「シャットダウン中」状態を設ける
ことによってこの望ましくない動作を回避する。この追
加状態によって、古いサーバは、新しいサーバが始動す
る前に必要なシャットダウン手続きを完了することがで
きる。また、速度が低すぎてシャットダウンまたは始動
できないサーバを処理するサーバも設けられる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチスレッド・
オブジェクト指向コンピュータ環境の分野に関する。

【０００２】

【従来の技術】従来技術のマルチスレッド・オブジェク
ト指向コンピュータ環境では、オブジェクト・サーバが
シャットダウンし、新しいオブジェクト・サーバがクラ
イアントによる呼出しに対する応答として始動されてい
るときに問題が生じる。新しいサーバを始動する責任を
負うデーモン・プロセスは、古いサーバが瞬間的にシャ
ットダウンすると仮定する。実際には、新しいオブジェ
クト・サーバが始動される際には、データベース・ロッ
クの解除などある種のクリーンナップ・プロセスが依然
として実行中である。このようなクリーンナップ・プロ
セスのために、新しいオブジェクト・サーバが始動を中
断することがある。したがって、古いオブジェクト・サ
ーバのシャットダウンと新しいオブジェクト・サーバの
始動との間には望ましくない競合状態が存在する。

【０００３】ネットワーク化オブジェクト環境 ネットワーク化オブジェクト環境では、オブジェクト・
サーバは、サーバ・プロセスとも呼ばれ、マルチスレッ
ド・プロセスであり、そのドメイン内のオブジェクトで
具体化されるメソッド、データなどへのアクセス、その
インスタンス化、その削除を制御する。オブジェクトと
は、明確に定義された自己完結型ソフトウェア・モジュ
ールであり、営業慣習などの手続きおよびそのデータを
カプセル化する。オブジェクトは、慎重に定義されたイ
ンタフェースを通じて互いに通信し、標準化電子構成要
素からコンピュータを製造するのと同様に複雑な解を構
築することができる。多重再使用・標準化レベルが可能
になり、それによってエンジニアは、再使用可能性およ
び向上可能性の非常に高いモジュール、アプリケーショ
ン、システム全体を作成することができる。

【０００４】ネットワーク化オブジェクト技法によっ
て、アプリケーションまたはオブジェクトがどこに存在
するかにかかわらずに、ネットワーク内の任意の場所に
あるオブジェクトおよびその共用サービスへのアプリケ
ーション・アクセスが可能になる。ネットワーク化オブ
ジェクトでは、アプリケーションまたはアプリケーショ
ンがモデル化する営業プロセスを妨害することなしに個
別のオブジェクトを更新することもでき、複雑なシステ
ムを円滑にかつ徐々に向上させることが容易である。た
とえば、新しいコンポーネントが失敗した場合、そのコ
ンポーネントの先行オペレーションを迅速にかつ透過的
に再開することができる。

【０００５】ネットワーク化オブジェクト環境の例は、
ネットワークおよびそれぞれの異なるコンピューティン
グ・プラットフォームを介してオブジェクトを共用でき
るようにするＳｕｎＳｏｆｔＴＭのＣＯＲＢＡ準拠ＮＥ
Ｏ製品ファミリである。

【０００６】オブジェクト・マネジメント・グループ
（ＯＭＧ）は、６００社以上のソフトウェア・ベンダ、
ディベロッパ、エンド・ユーザ団体からなり、異種分散
オブジェクト指向アプリケーションをサポートする共通
アーキテクチャの標準をすでに開発し、さらに引き続き
開発を進めている。ＯＭＧ共通オブジェクト要求ブロー
カ・アーキテクチャ（ＣＯＲＢＡ）は、複数のベンダの
それぞれの異なるオブジェクト・システムがネットワー
ク上で互いに対話できるようにするように設計されてい
る。ＣＯＲＢＡ仕様は、下記の４つのコンポーネントを
備える。

【０００７】ｉ）ネットワーク化環境でオブジェクトを
管理するためのオブジェクト要求ブローカ（ＯＲＢ） ii）ＯＲＢ−ＯＲＢ間通信のための相互運用性 iii)共通オブジェクト・サービス（ＣＯＲＢＡサービ
ス） iv）共通に使用されるプログラミング言語に関するマッ
ピング

【０００８】ネットワーク・オブジェクト要求ブローカ
（ＯＲＢ）は、ＣＯＲＢＡ準拠ネットワーク・ベース・
ソフトウェア・システムであり、標準インタフェース・
プロトコルを通じてオブジェクトを見つけて実行し、オ
ブジェクトおよびプログラムがネットワークを介して互
いに対話できるようにする。ＮＥＯ ＯＲＢは、１つま
たは複数のマルチスレッドＵＮＩＸプロセスとして実施
され、必要に応じてスケーリング可能な性能および使用
可能性を与える。

【０００９】ＯＭＧは、異種オブジェクト相互運用性を
推進するために、ＣＯＲＢＡ２．０インターネットＯＲ
Ｂ間プロトコルの移植可能なソース・コード基準処理系
を提供し、ソフトウェア・ベンダがＯＭＧ準拠製品を試
験し配布するのを助けている。インターネットＯＲＢ間
プロトコル（インターネットＩＯＰ）は、それぞれの異
なるＣＯＲＢＡ２．０準拠ベンダのＯＲＢを接続し、そ
れらのＯＲＢが互いに通信できるようにする標準化方法
を与える。現行のインターネットＩＯＰはＴＣＰ／ＩＰ
プロトコルに基づくものである。

【００１０】ＯＭＧ ＣＯＲＢＡサービス定義は、ネー
ミング・サービス、イベント・サービス、プロパティ・
サービス、ライフサイクル・サービス、リレーションシ
ップ・サービスなど、オブジェクトを用いて分散システ
ムを構築するのに必要な基本動作を説明するものであ
る。

【００１１】いくつかの異なるオブジェクト・システム
が対話できるようにするには、言語独立性が重要であ
る。インタフェース定義言語（ＩＤＬ）によって、イン
タフェースと処理系を分離し、オブジェクトのプラグ・
アンド・プレイ特性を損なわずにオブジェクト処理系の
詳細を変更することができる。ＯＭＧ ＩＤＬは、オブ
ジェクトの動作の中立的なインタフェース定義であり、
オブジェクトの動作をＩＤＬで定義できるようにする
が、インタフェースのＣ言語、Ｃ＋＋言語、オブジェク
ティブＣ言語、またはＳｍａｌｌｔａｌｋ言語への自動
変換を可能にする。

【００１２】ＵＮＩＸから与えられるようなマルチスレ
ッド環境は通常、ネットワーク化オブジェクトをサポー
トするために使用される。スレッドとは、たとえば印刷
プロセスを実行することや、データベース・オブジェク
トに作用することなど、ある種の機能を実行する大規模
なプロセスから生成されるサブプロセスである。複数の
スレッドをサポートすることによって、システムは多数
のクライアントおよびプロセスに対して同時にサービス
を提供することができる。これによって、ネットワーク
上でオブジェクトおよびサービスを共用することができ
る。

【００１３】ＣＯＲＢＡ環境では、オブジェクト要求ブ
ローカ・デーモン・プロセス（ＯＲＢＤ）が、それに登
録されているクライアント・プロセスから、メソッド呼
出しとも呼ばれるオブジェクト要求を受け取る。ＯＲＢ
デーモンは次いで、ネットワーク上でオブジェクトを見
つけ、このクライアント・プロセスとこのネットワーク
化オブジェクトとの間のインタフェースとして働く。Ｎ
ＥＯ環境では、ＯＲＢデーモンは、ＮＥＯオブジェクト
を活動化させ、そのオブジェクト、すなわち標準ＮＥＯ
オブジェクト、または場合によってはＮＥＯオブジェク
トとして実行させるためにＮＥＯシェルにカプセル化さ
れたレガシー・プロセスの別のインタフェースとして働
く。ＮＥＯオブジェクト・サーバは、必要に応じてオブ
ジェクトをインスタンス化し、ＯＲＢデーモンから転送
された要求に応答するように働く。

【００１４】システム・ブロック図 図１は、ＣＯＲＢＡ準拠ネットワーク化オブジェクト・
システムのブロック図である。複数のスレッドが要素１
００ないし１０３で表されており、スレッド１００ない
し１０１は第１のクライアント・プロセス、すなわちク
ライアント・プロセス１から生成されるスレッドであ
り、スレッド１０２ないし１０３は第２のクライアント
・プロセス、すなわちクライアント・プロセスＮから生
成されるスレッドである。図１に示したように、単一の
クライアント・プロセスは任意の数のスレッドを生成す
ることができる。各スレッド１００ないし１０３は、オ
ブジェクト要求ブローカ・デーモン（ＯＲＢＤ）プロセ
ス１０４にリンクされる。ＯＲＢＤプロセス１０４は、
オブジェクト・サーバ１０５およびオブジェクト・サー
バ１０７で表される複数のオブジェクト・サーバにリン
クされる。第２のＯＲＢＤプロセス、すなわちＯＲＢＤ
プロセス１１０はさらにＯＲＢＤプロセス１０４にリン
クされる。ＯＲＢＤプロセス１１０は、他のオブジェク
ト・サーバまたはクライアント・プロセス（図示せ
ず）、あるいはその両方に結合することもできる。オブ
ジェクト・サーバ１０５はオブジェクト１０６にリンク
される。オブジェクト・サーバ１０７はオブジェクト１
０８および１０９にリンクされる。

【００１５】ＯＲＢＤプロセス１０４は、クライアント
・プロセス・スレッド１００ないし１０３からメソッド
呼出しなどのオブジェクト要求をロケート要求の形で受
け取り、どのオブジェクト・サーバが適当なオブジェク
トをサポートしているかを判定する。必要なサーバが現
在動作していない場合、そのサーバが活動化されオブジ
ェクトがインスタンス化される。ロケート要求に応答し
てオブジェクトの位置に関する情報が返され、この位置
情報によってスレッドとオブジェクトとの間で他の要求
が送られる。ロケート要求によって他のスレッドから同
じオブジェクトを同様に呼び出し、このオブジェクトと
すべての適用可能なスレッドとの間に並行して対話を確
立することができる。

【００１６】ＯＲＢデーモン１１０は、インターネット
など大規模なネットワークを介してネットワーク化オブ
ジェクト環境用のゲートウェイを形成することも、ある
いはそれ自体のドメイン内のクライアントおよびオブジ
ェクト・サーバとのプラットフォーム依存インタフェー
スを形成し、同時にＯＲＢＤ１０４との標準化インタフ
ェースを形成することによってクロス・プラットフォー
ム対話を行うこともできる。

【００１７】オブジェクト・サーバ１０５および１０７
は、オブジェクト１０６や１０８ないし１０９で示した
ようなオブジェクトまたはオブジェクト・ライブラリに
アクセスする。レガシー・オブジェクト、すなわち独立
型アプリケーションと、基本的にネットワーク化オブジ
ェクト環境向けには設計されていない他のオブジェクト
とを備えるオブジェクトは、オブジェクト・サーバがレ
ガシー・オブジェクトの機能にアクセスできるようにす
るインタフェースを形成するＩＤＬシェルを備える。Ｏ
ＲＢデーモンと共に動作するパシスタント・ストア・マ
ネージャ・プロセスはロックを追跡し、オブジェクト・
サーバがサーバ専用アクセスを維持するにはオン・オブ
ジェクト、たとえばデータベース・オブジェクトを有す
ることができる。

【００１８】ネットワークはハードウェア境界からほぼ
独立しているので、オブジェクトおよびオブジェクト・
サーバは、クライアント・プロセスおよびＯＲＢデーモ
ンと同じコンピュータ上に存在することも、あるいはネ
ットワーク内の別々のコンピュータ上に存在することも
できる。同様に、ネットワーク化オブジェクト環境は、
ネットワークのベース・レベル処理系からほぼ独立して
いる。

【００１９】シャットダウン・プロトコル オブジェクト・サーバに関するシャットダウン・プロト
コルの従来技術の処理系を下記に示す。オブジェクト・
サーバは、たとえばアイドル時間のために、あるいは場
合によってはクライアントの呼出しに応答してシャット
ダウンすることを決定する。オブジェクト・サーバは次
いで、すべてのアクティブ・オブジェクトのシャットダ
ウンを開始し、すべてのメソッド呼出しが終了するのを
待つ。オブジェクト・サーバに結合されたすべてのオブ
ジェクトがシャットダウンすると、オブジェクト・サー
バはそのサーバ状態を「シャットダウン中」にセット
し、シャットダウン中であることをＯＲＢデーモンに知
らせる。ＯＲＢデーモンが首尾良く、オブジェクト・サ
ーバがシャットダウン中であることを知ると、サーバは
そのサーバ状態を「終了」にセットし、ＯＲＢデーモン
との接続を終了する。最後に、オブジェクト・サーバ
は、シャットダウンが完了したことをメイン・スレッド
に知らせ、メイン・スレッドは、オブジェクト・サーバ
がパーシスタント・ストア・マネージャ内に有すること
のできるロックの解放など、最後のクリーンナップを実
行する。

【００２０】オブジェクト・サーバ内で動作するオブジ
ェクト・サーバ有限状態マシンを図２の状態図に示す。
サーバ状態マシンは、「非実行中」、「実行中」、「シ
ャットダウン中」、「終了」の４つの状態からなる。サ
ーバが始動すると、サーバは状態２００、すなわち「非
実行中」になり、矢印２０４で示したように、メソッド
の呼出しは待機させられる。オブジェクト・サーバがＯ
ＲＢデーモンに登録され、矢印２０５で示したようにオ
ブジェクト・サーバが実行表示を受け取った後、オブジ
ェクト・メソッドがイネーブルされ、サーバ状態は状態
２０１、すなわち「実行中」へ進む。

【００２１】状態２０１では、矢印２０６で示したよう
に新しい呼出しによってアクティブ・メソッド・カウン
タが増分し、矢印２０７で示したようにメソッド呼出し
が終了することによってアクティブ・メソッド・カウン
タが減分する。オブジェクト・サーバが、アイドル時間
が長すぎるためにシャットダウンするとき、クライアン
ト、たとえばオブジェクト・サーバからの呼出しは、矢
印２０８で示したようにすべてのメソッド呼出しがクリ
アされるまで待ち、次いで、シャットダウン中であるこ
とをＯＲＢデーモンに知らせ、他のクライアントからの
新しい呼出しを待機させ、サーバ状態を状態２０２、す
なわち「シャットダウン中」にセットする。

【００２２】矢印２０９で示したように、状態２０２中
の他の呼出しは待機させられる。ＯＲＢデーモンが首尾
良く、サーバがシャットダウン中であることを知った
後、矢印２１０で示したように、オブジェクト・サーバ
はすべての待機中のクライアントにエラーを返し、クラ
イアントにリバインドさせ、すなわち新しいオブジェク
ト・サーバを見つけさせる。次いで、サーバ状態は状態
２０３、すなわち「終了」へ進み、ロックの除去など最
後のクリーンナップ動作が実行される。

【００２３】第２のサーバ有限状態マシンは、ＯＲＢデ
ーモン内で動作し、ＯＲＢデーモンによってサーバ上で
行われる活動化／非活動化制御を判定する。この第２の
有限状態マシンは、「始動」、「始動中」、「実行中」
の３つの状態を有する。この３状態有限状態マシンの状
態図を図３に示す。矢印３０３で示したように「始動」
状態３００のサーバ宛のロケート要求がＯＲＢデーモン
に到着すると、サーバは、新しいプロセスとして分岐
し、要求側メソッド呼出しがブロックされ、サーバ状態
が「始動」状態３０１を開始する。

【００２４】状態３０１では、矢印３０５で示したよう
に、すべてのロケート要求がブロックされ、サーバの登
録を待たされる。矢印３０４で表したようにサーバＰＩ
Ｄ（プロセスＩＤ）が終了した場合、待機中のメソッド
呼出しがブロック解除され、サーバが「始動」状態３０
０に戻り、待機中のあるメソッド呼出しがサーバの始動
を再試行する。「始動中」状態３０１の間に、矢印３０
６で示したようにサーバがＯＲＢデーモンに登録した場
合、すべての待機中のメソッド呼出しがブロック解除さ
れ、サーバ状態が「実行中」状態３０２を開始する。

【００２５】矢印３０７で示したように、「実行中」状
態３０２の間に受け取るすべてのその後のロケート要求
は、サーバがその登録の一部として与えたアドレス情報
を返す。矢印３０８で示したように、サーバがシャット
ダウン・プロトコルの一部として、シャットダウン中で
あることを知らせると、ＯＲＢデーモンがクリーンナッ
プし、サーバ状態が「始動」状態３００に戻る。

【００２６】図２および３のサーバ活動化／非活動化プ
ロトコルに関する主要な問題は、サーバをシャットダウ
ンしている間に競合状態が起こることである。ロックの
除去などのシャットダウン手続きは、サーバがシャット
ダウンしたことをＯＲＢデーモンに知らせた後にサーバ
において行われる。しかし、ＯＲＢデーモンは、サーバ
からシャットダウン信号を受け取ると、サーバが完全に
シャットダウンした場合と同様に動作する。これは、Ｏ
ＲＢデーモンには、新しいサーバがロケート要求の結果
としてただちに始動できることを意味する。

【００２７】新しいサーバが、古いサーバに依然として
ロックされている資源にアクセスしようとすると、競合
が起こる。古いサーバがまだロックを除去していない場
合、新しいサーバは、ロックされている資源へのアクセ
スを拒否され、新しいサーバは始動を中止する。したが
って、古いサーバが保持している資源に対するすべての
ロック解除と新しいサーバによる同じ資源のアクセスと
の間に競合状態が存在する。まずロックが解除された場
合、他の問題を除いて、新しいサーバは首尾良く始動を
完了する。先に新しいサーバが資源にアクセスしようと
すると、新しいサーバは中止される。新しいサーバ・プ
ロセスを分岐させ、単に始動の途中で中止させること
は、ＣＰＵ処理時間の無駄であり、ＣＰＵ処理時間は古
いサーバのシャットダウンなど他のプロセスに費やした
方が良い。

【００２８】

【発明が解決しようとする課題】問題は、ＯＲＢデーモ
ン内のサーバ有限状態マシン（すなわち、図３）にあ
る。この状態マシンは、シャットダウン・プロセス（す
なわち、サーバが「実行中」状態３０７から「始動」状
態３００へ移る時間）を考慮していない。「シャットダ
ウン中の」サーバが完全にシャットダウンしていなくて
も新しいサーバをただちに始動することができる。この
場合、古いサーバのシャットダウンと新しいサーバの始
動との間に競合状態が起こる。

【００２９】既存のプロトコルは、登録なしに開始し、
あるいは登録に時間がかかりすぎるサーバ、およびシャ
ットダウンの速度が低すぎるサーバも取り扱わない。た
とえば、サーバがハングしているためにサーバの速度が
低すぎてＯＲＢデーモンに登録できない場合、処置を施
すべきである。同様に、サーバがハングしているために
サーバの速度が低すぎてシャットダウンできない場合、
新しいサーバが始動できるようにする処置を施すべきで
ある。現在の所、これらの問題を処理する機構は存在し
ない。

【００３０】さらに、現在の所、スラッシング状態を処
理する機構はない。スラッシング状態は、サーバが始動
および再始動を連続的に中断されたときに起こる。これ
は、サーバが過度に高い速度で再始動しようとするとき
に起こる。たとえば、終了時にＯＲＢデーモンによって
自動的に再始動されるデーモン・サーバは、スラッシン
グ動作の影響を強く受ける。スラッシングは、サーバの
始動プロセスの回復できないエラーを示すこともある。
スラッシング状態を処理する機構がない場合、この問題
が将来再発するのを防止することはできない。

【００３１】最後に、ＯＲＢは現在の所、状態マシン内
の「自己始動サーバ」（「ユーザ・サーバ」とも呼ばれ
る）を処理することはできない。自己始動サーバとは、
ＯＲＢデーモンとの間で登録および登録解除を行うが、
呼出しの結果としてＯＲＢデーモンによって生成される
ことのないサーバである。

【００３２】

【課題を解決するための手段】サーバの活動化を制御す
る方法および装置を提供する。サーバ状態マシン内のサ
ーバ状態はサーバ・プロセスに関連付けられる。このサ
ーバ状態は、サーバ・プロセスからシャットダウン表示
が返されたときに実行中状態からシャットダウン中状態
に変更される。シャットダウン中状態では、サーバ・プ
ロセス宛のメソッド呼出しがブロックされ、そのため、
この状態中の新しいサーバ・プロセスの活動化が妨げら
れる。サーバ状態は、サーバ・プロセスのシャットダウ
ンが完了したことを示す表示を受け取ったときにシャッ
トダウン中から始動状態に変更される。

【００３３】ハングしているサーバ・プロセスを処理す
るために、サーバ状態が始動状態から始動中状態へ、あ
るいは実行中状態からシャットダウン中状態へ変化した
ときにタイマが始動される。タイマがサーバの登録また
は終了前に満了した場合、サーバ・プロセスが終了さ
れ、エラーが記録される。サーバ・プロセスが終了する
と、サーバ状態が始動状態に戻る。

【００３４】一実施態様では、自己始動サーバ・プロセ
スに適応するためにサーバ状態マシンに自己始動実行中
状態が含まれる。自己始動サーバ・プロセスに関連付け
られたサーバ状態は、自己始動サーバ・プロセスが登録
されると始動状態から自己始動実行中状態へ変更され
る。自己始動サーバ・プロセスが登録解除されると、サ
ーバ状態は始動状態に戻る。自己始動サーバ・プロセス
宛のロケート要求には、自己始動実行中状態時にサーバ
・アドレス情報が返される。

【００３５】他の実施態様では、スラッシュしているサ
ーバ・プロセスを処理するために独立のホールドダウン
状態マシンが設けられる。ホールドダウン状態はサーバ
・プロセスに関連付けられ、サーバ宛のロケート要求
は、ホールドダウン状態マシンに対して応答に関する問
い合わせを行う。ロケート要求は、ホールドダウン状態
マシンに問い合わせた後、サーバ状態マシンに問い合わ
せる。

【００３６】

【発明の実施の形態】サーバ活動化を制御する方法につ
いて説明する。下記の説明では、本発明をより完全に説
明するために多数の特定の詳細について詳しく述べてい
る。しかし、当業者には、これらの特定の詳細なしで本
発明を実施できることが明らかになろう。他の例では、
本発明を不必要に曖昧にしないように周知の特徴は詳し
く記載されていない。

【００３７】本発明の実施形態は、サーバ活動化を制御
する方法および装置を提供する。従来技術では、古いサ
ーバのシャットダウンと新しいサーバの始動との間に競
合状態が存在する。しかし、本発明のこの実施形態は、
ＯＲＢデーモン内で動作するサーバ有限状態マシンに追
加「シャットダウン中」状態を与えることによって望ま
しくないこの状態を回避する。この追加状態によって、
古いサーバは、新しいサーバが始動する前に必要なシャ
ットダウン手続きを完了することができる。速度が低す
ぎてシャットダウンすることも、あるいは始動すること
もできないサーバを処理するプロセスも設けられ、自己
始動サーバを処理するためにサーバ有限状態マシンに第
２の追加状態が設けられる。スラッシュしているサーバ
は、独立のホールドダウン状態マシンによって処理され
る。

【００３８】本発明の一実施形態では、ＯＲＢデーモン
内で動作するサーバ状態マシンは、「始動」状態、「始
動中」状態、「実行中」状態、「シャットダウン中」状
態、「自己始動実行中」状態の５つの状態を備える。始
動時に、新しいサーバは、「始動」状態から「始動中」
状態へ進み、ＯＲＢデーモンに登録されるまでそのまま
であり、登録された時点で「実行中」状態を開始する。
始動するまでに時間がかかりすぎるサーバは、「始動
中」状態でタイムアウトし、「始動」状態に戻り、この
状態で、待機中のクライアントがこのサーバを再始動し
ようとする。古いサーバは、シャットダウンすると、
「実行中」状態から「シャットダウン中」状態に入り、
必要なクリーンナップ動作を実行する。サーバは、終了
すると、「始動」状態に戻り、新しいサーバが始動する
ことができる。終了するまでに時間がかかりすぎるサー
バ・プロセスは、ＯＲＢデーモンによって「終了」さ
れ、「始動」状態に戻る。サーバが「シャットダウン
中」状態の間に受け取った呼出しはブロックされる。

【００３９】「自己始動実行中」状態は、単にＯＲＢデ
ーモンとの間で登録および登録解除を行う自己始動サー
バまたはユーザ・サーバを処理するために実施される。
自己始動サーバがＯＲＢデーモンに登録されると、サー
バの状態が「始動」状態から「自己始動実行中」状態へ
移る。サーバが「自己始動実行中」状態の間に受け取っ
た呼出しは、サーバのアドレス情報を返す。自己始動サ
ーバがＯＲＢデーモンから登録解除されると、サーバ状
態は「始動」状態に戻り、ＯＲＢデーモンは、サーバが
シャットダウンしたと仮定する。

【００４０】本発明の他の実施形態では、サーバがスラ
ッシュしているインスタンスでサーバのホールドダウン
を制御するために独立の状態マシンが実施される。した
がって、サーバ始動プロセスの回復できないエラーが処
理される。

【００４１】本発明の実施形態は、図４に示したような
汎用コンピュータ上で実行されるコンピュータ読取り可
能なプログラム・コードの形のコンピュータ・ソフトウ
ェアとして実施することができる。キーボード４１０お
よびマウス４１１は二方向システム・バス４１８に結合
される。キーボードおよびマウスは、コンピュータ・シ
ステムにユーザ入力を導入しそのユーザ入力を中央演算
処理装置（ＣＰＵ）４１３に伝達するためのものであ
る。図４のコンピュータ・システムは、ビデオ・メモリ
４１４と、メイン・メモリ４１５と、大容量記憶域４１
２とを含み、これらはすべて、キーボード４１０、マウ
ス４１１、ＣＰＵ４１３と共に二方向システム・バス４
１８に結合される。大容量記憶域４１２は、磁気記憶シ
ステムや、光学記憶システムや、磁気光学記憶システム
や、その他の使用可能な大容量記憶技術など、固定媒体
と取り外し可能な媒体の両方を含むことができる。バス
４１８は、たとえばビデオ・メモリ４１４またはメイン
・メモリ４１５にアドレスする３２本のアドレス線を含
むことができる。システム・バス４１８はたとえば、Ｃ
ＰＵ４１３、メイン・メモリ４１５、ビデオ・メモリ４
１４、大容量記憶域４１２などの構成要素間でデータを
転送する３２ビット・データ・バスを含むこともでき
る。別法として、別々のデータ線およびアドレス線では
なく多重化データ／アドレス線を使用することができ
る。

【００４２】本発明の一実施形態では、ＣＰＵ４１３
は、６８０Ｘ０プロセッサなど、Ｍｏｔｏｒｏｌａ社に
よって製造されている３２ビット・マイクロプロセッ
サ、または８０Ｘ８６やＰｅｎｔｉｕｍプロセッサな
ど、Ｉｎｔｅｌ社によって製造されているマイクロプロ
セッサである。しかし、他の適当なマイクロプロセッサ
またはマイクロコンピュータを使用することができる。
メイン・メモリ４１５は、ダイナミック・ランダム・ア
クセス・メモリ（ＤＲＡＭ）で構成される。ビデオ・メ
モリ４１４は、二重ポート・ビデオ・ランダム・アクセ
ス・メモリである。ビデオ・メモリ４１４の１つのポー
トはビデオ増幅器４１６に結合される。ビデオ増幅器４
１６は、陰極管（ＣＲＴ）ラスタ・モニタ４１７を駆動
するために使用される。ビデオ増幅器４１６は、良く知
られており、任意の適当な装置によって実施することが
できる。この回路は、ビデオ・メモリ４１４に記憶され
ている画素データを、モニタ４１７で使用するのに適し
たラスタ信号に変換する。モニタ４１７は、グラフィッ
ク画像を表示するのに適したある種のモニタである。

【００４３】ネットワーク環境では、図４の装置は、当
技術分野で知られているように適当な通信ハードウェア
およびソフトウェアを使用する他の同様な装置に結合さ
れる。ネットワークの共用サービスにアクセスするフロ
ント・エンド・システムは、ＷｉｎｄｏｗｓＴＭを実行
するＰＣシステム、またはＪａｖａＴＭアプリケーショ
ン・インタフェースをサポートするウェブ・ブラウザ、
またはＳｏｌａｒｉｓＴＭを実行するワークステーショ
ン、またはそれらの組合せを含め他の適当なシステムを
備えることができる。

【００４４】前述のコンピュータ・システムは、例示の
みのためのものである。本発明の実施形態は、任意のタ
イプのコンピュータ・システム、あるいはプログラミン
グ環境または処理環境で実施することができる。前述の
ＮＥＯ環境以外のマルチスレッド環境のクライアント・
サーバ・システムも、ＯＲＢデーモンと同様なサーバ制
御プロセスを使用してサーバ有限状態マシンの実施形態
を実施することによって本発明の方法および装置を実施
することができる。

【００４５】従来技術では、マルチスレッド環境の新し
いサーバの活動化または始動が、シャットダウン中の古
いサーバの動作の影響を受けることがある。データベー
ス・ロックおよびその他のサーバ特有の機能は依然とし
て古いサーバに対してアクティブであり、そのため新し
いサーバの活動化が異常終了または中断することがあ
る。

【００４６】本発明の実施形態は、古いサーバがシャッ
トダウン・プロセスを完了する前に新しいサーバが始動
するのを妨げることによって従来技術の問題を回避す
る。これは、ＯＲＢデーモンに追加「シャットダウン
中」状態を与え、古いサーバがシャットダウンの途中で
あることを示すことによって行われる。古いサーバがシ
ャットダウンを終了し、サーバ状態が「シャットダウン
中」状態を終了した後、新しいサーバを活動化すること
ができる。したがって、競合状態が回避される。

【００４７】従来技術のマルチスレッド環境では、サー
バが「ハング」し、すなわちサーバ・プロセスの問題の
ためにサーバがシャットダウンまたは始動するまでの時
間がかかりすぎる傾向がある。本発明の実施形態は、始
動プロセスおよびシャットダウン・プロセス用のタイマ
を確立することによってこの問題を回避する。サーバが
タイムアウトを有し、すなわちタイマが事前に設定され
た限界を超えた場合、サーバは「始動」状態に戻り、エ
ラーが記録される。

【００４８】従来技術のシステムでは、ある種のサーバ
・プロセスは再始動の速度が高すぎ、サーバが始動を完
了する前に終了し、スラッシングと呼ばれるサイクルで
再始動する。これは、サーバの始動プロセスの回復でき
ないエラーによって起こる。本発明の一実施形態では、
スラッシング動作は、サーバ・ホールドダウン状態マシ
ンを追加することによって処理される。

【００４９】最後に、従来技術では、自己始動サーバ
は、ＯＲＢデーモン内の状態マシンからは予期されな
い。本発明の実施形態は、自己始動サーバ用の追加実行
中状態を含む。自己始動サーバは、ＯＲＢデーモンに登
録されたときに「自己始動実行中」状態になり、次いで
登録解除されたときに「始動」状態になる。自己始動サ
ーバは、「始動」状態を開始したときにＯＲＢデーモン
からシャットダウンしたとみなされる。

【００５０】本発明の実施形態の有限状態マシンは、サ
ーバの現在の状態の表現を含む状態変数を含むＯＲＢデ
ーモン内のソフトウェア・プロセスを用いて実施するこ
とができる。状態マシン・プロセスは、指定された入力
に応答する際、状態変数から現在の状態を判定し、その
状態に対する適当な処置を判定する。状態変数の内容
は、「始動」には「０００」、「始動中」には「００
１」、「実行中」には「０１０」、「シャットダウン
中」には「０１１」、「自己始動実行中」には「１０
０」など現在の状態の簡単なバイナリ値表現でも、ある
いはその他の適当な状態表現でもよい。各サーバごとの
状態変数を含む状態テーブルを使用してＯＲＢデーモン
によって複数のサーバを処理することができる。状態マ
シンは、各状態ごとに別々のモジュールを有する分岐ソ
フトウェア・コード・モジュールを用いて実施すること
もできる。そのような実施態様では、サーバの状態を明
示的に表す必要はない。当技術分野で知られている標準
タイマ関数を使用して「タイムアウト」手続きを実施す
ることができる。

【００５１】通常のサーバ・ライフサイクルは下記のと
おりである。サーバに対する第１のロケート要求は、サ
ーバを始動し、サーバがＯＲＢデーモンに登録されるの
を待ち、次いでサーバの位置またはアドレス情報をクラ
イアントに返す。サーバは、シャットダウンすることを
決定すると、サーバのオブジェクトを非活動化し、次い
で、シャットダウンすることをＯＲＢデーモンに知らせ
る。この点で、ＯＲＢデーモンは、サーバへのすべての
ロケート要求をブロックし、サーバがシャットダウンの
途中であるとみなす。サーバは、シャットダウン・プロ
セスを完了し、オブジェクト・データベースおよびパシ
スタント・ストア・マネージャに対するすべてのロック
を解除する。サーバ・プロセスが終了すると、ＯＲＢデ
ーモンが通知を受ける。ＯＲＢデーモンは、終了を通知
された後、サーバが完全にシャットダウンしたものとみ
なし、新しいサーバが再始動できるようにする。

【００５２】図５は本発明の一実施形態の状態図を示
す。図５に表した有限状態マシンは、ＯＲＢデーモン又
はその他の同様なサーバ監視・制御プロセスで実施され
る。

【００５３】図５で、「始動」状態５００に未活動化サ
ーバが存在する。矢印５０５で示したように、未活動化
サーバがロケート要求または呼出しを受け取ると、サー
バ・プロセスが分岐し、クライアントからのメソッド呼
出しが待機させられ、始動タイマがトリガされる。サー
バは次いで、「始動中」状態５０１を開始する。矢印５
０７で示したように、「始動中」状態５０１で受け取っ
たすべてのメソッド呼出しがブロックされる（すなわ
ち、待機させられる）。

【００５４】サーバ・プロセスが終了し、あるいは始動
タイマが、「始動中」状態５０１でタイムアウト条件を
示した場合、矢印５０６で示したように、始動タイマが
取り消され、待機中のメソッド呼出しがブロック解除さ
れ、ログ・ファイルにおいて適当なエラー・メッセージ
が報告され、サーバが「始動」状態５００に戻る。ブロ
ック解除されたメソッド呼出しは次いで、サーバを再始
動しようとする。サーバが「始動中」状態５０１から首
尾良くＯＲＢデーモンに登録された場合、矢印５０８で
示したように、始動タイマが取り消され、待機中のメソ
ッド呼出しがブロック解除され、サーバが「実行中」状
態５０２を開始する。

【００５５】矢印５１７で示したように、サーバが「実
行中」状態５０２の間に突然終了すると、サーバ状態が
「始動」状態５００に戻りエラーが記録される。「実行
中」状態５００で受け取ったロケート要求は、矢印５０
９で示したように、サーバのアドレス情報を返す。サー
バが、アイドル・タイマの満了や、クライアント要求な
どのために、矢印５１０で示したように、シャットダウ
ンすることを決定すると、サーバ状態が「シャットダウ
ン中」状態５０３を開始し、シャットダウン・タイマが
トリガされる。

【００５６】「シャットダウン中」状態５０３の間に受
け取ったすべてのメソッド呼出しは、矢印５１１で示し
たようにブロックされる。サーバが終了し、すなわちシ
ャットダウン手続きを終了すると、シャットダウン・タ
イマが取り消され、待機中のメソッド呼出しがブロック
解除され、矢印５１２で示したようにサーバ状態が「始
動」状態５００に戻る。矢印５１３は、シャットダウン
・タイマが満了したシャットダウン・タイムアウト状態
を示す。シャットダウン・タイマが満了した場合、ＯＲ
Ｂデーモンは、サーバ・プロセスがハングしていると仮
定し、サーバを終了させ、サーバ状態を「始動」状態５
００に戻す。待機中のメソッド呼出しはブロック解除さ
れエラーが記録される。サーバが「始動」状態５００に
戻ると、ブロック解除されたメソッド呼出しはサーバを
再始動しようとする。

【００５７】矢印５１４で示したように自己始動サーバ
またはユーザ・サーバがＯＲＢデーモンに登録される
と、サーバの状態が「自己始動実行中」状態５０４にな
り、ＯＲＢデーモンとサーバがセットアップ情報を交換
する。「自己始動実行中」状態５０４では、呼出しは、
矢印５１６で示したように、サーバのアドレス情報を返
す。自己始動サーバは、矢印５１５で示したようにＯＲ
Ｂデーモンから登録解除することができ、その時点でＯ
ＲＢデーモンは、サーバがシャットダウンしたと仮定
し、クリーンナップ動作が実行される。登録解除時に、
自己始動サーバは「始動」状態５００に戻る。自己始動
サーバへシャットダウン要求が送られると、サーバが登
録解除される。

【００５８】本発明の一実施形態では、ホールドダウン
条件を制御するために独立の状態マシンが実施される。
時には、たとえばささいな矛盾を解決できるように一時
的に、あるいは補正を必要とする回復不能なエラーを管
理者に知らせるためにより長い持続期間にわたって、サ
ーバ・プロセスを停止させる必要がある。短いホールド
ダウン時には、サーバは短時間中のみ使用不能になると
予想され、したがってサーバ宛のロケート要求は、この
短いホールドダウンが終了するまでブロックされるに過
ぎない。しかし、長いホールドダウン時には、サーバは
長時間にわたって使用不能になると予想される。したが
って、長いホールドダウン中のロケート要求は、サーバ
が使用不能であることを反映するためにエラーを返す。

【００５９】再始動の速度が高すぎ、すなわち再始動回
数が、刻時カウンタ関数によって決定される単位時間当
たりの構成可能な回数よりも多いサーバを「スラッシン
グ」サーバと呼ぶ。スラッシング状態が検出されると、
サーバは長いホールドダウン状態になる。

【００６０】ホールドダウン条件は、「非ホールドダウ
ン」状態と、「短いホールドダウン」状態と、「長いホ
ールドダウン」状態とを有する３状態状態マシンで制御
される。ロケート要求はまず、ホールドダウン状態に基
づいて適当な処置を実行するホールドダウン状態マシン
で処理され、次いでサーバ状態マシンによって処理され
る。

【００６１】ホールドダウン状態マシンの実施形態を図
６に示す。図６で、「非ホールドダウン」状態６００
は、サーバが現在停止されていないことを示す。矢印６
０３で示したように、「非ホールドダウン」状態６００
で受け取ったロケート要求によってホールドダウン状態
マシンから動作が生成されることはない。さらに、矢印
６０９で示したように、「長いホールドダウン」状態６
０２で受け取ったロケート要求はエラーを返す。

【００６２】ホールドダウン状態間の遷移に関しては、
それぞれ、矢印６０４、６１１、６１０、６０８で表し
た、「非ホールドダウン」状態６００から「短いホール
ドダウン」状態６０１への遷移、「非ホールドダウン」
状態６００から「長いホールドダウン」状態６０２への
遷移、「長いホールドダウン」状態６０２から「非ホー
ルドダウン」状態６００への遷移、「長いホールドダウ
ン」状態６０２から「短いホールドダウン」状態６０１
への遷移によって動作が実行されることはない。それぞ
れ、矢印６０５および６０７で表した、「短いホールド
ダウン」状態６０１から「非ホールドダウン」状態６０
０への遷移および「短いホールドダウン」状態６０１か
ら「長いホールドダウン」状態６０２への遷移では、待
機中のメソッド呼出しがブロック解除される。状態間の
遷移は、ＯＲＢデーモンによって制御される。

【００６３】図７は、前述の状態マシンを使用してロケ
ート要求に応答するプロセスの一実施形態を示す。ステ
ップ７００で、状態マシン・プロセスが、クライアント
・スレッドからロケート要求の形のメソッド呼出しを受
け取る。ステップ７０１で、ホールドダウン状態マシン
が問い合わせを受け、ホールドダウン条件がロケート要
求に対する応答に影響を及ぼすかどうかが判定される。
ホールドダウン状態に応じてステップ７０２で分岐が行
われる。ホールドダウン状態が「短いホールドダウン」
である場合、ステップ７０３で、ロケート要求で表され
た呼出しがブロックされる。ホールドダウン状態が「長
いホールドダウン」である場合、ステップ７０４で、プ
ロセスは、サーバが使用不能であることを反映するエラ
ーをクライアントに返す。ホールドダウン状態が「非ホ
ールドダウン」である場合、ステップ７０５で、サーバ
状態マシンが問い合わせを受け、現サーバ状態が判定さ
れる。

【００６４】ステップ７０６で、現サーバ状態に応じて
分岐が行われる。現サーバ状態が「始動中」または「シ
ャットダウン中」である場合、ステップ７０７で呼出し
がブロックされる。現サーバ状態が「実行中」または
「自己始動実行中」である場合、ステップ７０８で、ク
ライアントにサーバ・アドレス情報が返される。現サー
バ状態が「始動」である場合、ステップ７０９で、サー
バ・プロセスが分岐し、始動タイマが始動され、クライ
アントからのメソッド呼出しが待機させられる。ステッ
プ７１０で、サーバ状態が「始動中」に変更される。

【００６５】図８は、前述のサーバ状態マシンを使用し
てサーバ・プロセス終了通知に応答するプロセスの一実
施形態を示す。ステップ７１１で、プロセスが、サーバ
・プロセスが終了したことを示す表示を受け取る。ステ
ップ７１２で、サーバ状態マシンが問い合わせを受け、
現サーバ状態情報が判定される。現サーバ状態に応じて
ステップ７１３で分岐が行われる。現サーバ状態が「始
動中」である場合、ステップ７１４で、始動タイマが取
り消され、待機中のメソッド呼出しがブロック解除さ
れ、エラーが記録される。現サーバ状態が「実行中」で
ある場合、ステップ７１５で、エラーが記録される。現
サーバ状態が「シャットダウン中」である場合、ステッ
プ７１６で、シャットダウン・タイマが取り消され、待
機中のメソッド呼出しがブロック解除される。ステップ
７１４、７１５、７１６はすべてステップ７１７へ進
み、サーバ状態が「始動」にセットされる。

【００６６】図９は、タイムアウトに応答するプロセス
の一実施形態を示す。ステップ７１８で、プロセスがタ
イムアウト表示を受け取る。ステップ７１９で、サーバ
・プロセスが終了し、待機中のメソッド呼出しがブロッ
ク解除され、エラーが記録される。ステップ７２０で、
サーバ状態が「始動」にセットされる。

【００６７】図１０は、前述のサーバ状態マシンを使用
してサーバの登録に応答するプロセスの一実施形態を示
す。ステップ７２１で、プロセスがサーバから登録要求
を受け取る。ステップ７２２で、サーバ状態マシンが問
い合わせを受け、サーバ状態情報が得られる。ステップ
７２３で、現サーバ状態に応じて分岐が行われる。現サ
ーバ状態が「始動中」である場合、ステップ７２４で、
始動タイマが取り消され、待機中のメソッド呼出しがブ
ロック解除される。ステップ７２５で、現サーバ状態が
「実行中」にセットされる。現サーバ状態が「始動」で
ある場合、ステップ７２６で、サーバとＯＲＢデーモン
との間でセットアップ情報が交換される。ステップ７２
７で、サーバ状態が「自己始動実行中」に変更される。

【００６８】図７Ｅは、前述のサーバ状態マシンを使用
してサーバ・シャットダウン表示に応答するプロセスの
一実施形態を示す。ステップ７２８で、プロセスがシャ
ットダウン表示を受け取る。ステップ７２９で、サーバ
状態マシンがサーバ状態情報に関する問い合わせを受け
る。現サーバ状態に応じてステップ７３０で分岐が行わ
れる。現サーバ状態が「実行中」である場合、ステップ
７３１で、シャットダウン・タイマが始動される。ステ
ップ７３２で、現サーバ状態が「シャットダウン中」に
セットされる。現サーバ状態が「自己始動実行中」であ
る場合、ステップ７３３で、ＯＲＢデーモンがサーバ・
データ構造のクリーンナップを実行する。ステップ７３
４で、サーバ状態が「始動」にセットされる。

【００６９】上記実施形態は、コンピュータのハードウ
エアによって実施される。そのハードウエアシステムで
用いられるプログラムは当然のことながら記録媒体に記
録された状態で提供される。このプログラムを記憶させ
た媒体としては、例えばフレキシブルディスク、ＣＤ−
ＲＯＭ、メモリカードその他あらゆる媒体を使用でき
る。媒体に記録されたプログラムは、ハードウエアに組
み込まれている記憶装置、例えばハードディスクなどに
インストールされることにより、プログラムが実行でき
るようになる。

【００７０】したがって、サーバ活動化を制御する方法
および装置を１つまたは複数の特定の実施形態に関連し
て説明した。本発明は、特許請求の範囲およびその全範
囲の等価物によって定義される。

【図面の簡単な説明】

【図１】 ネットワーク化オブジェクト環境の例のブロ
ック図である。

【図２】 オブジェクト・サーバ内で実行されるサーバ
有限状態マシン・プロセスの状態図である。

【図３】 ＯＲＢデーモン内で実行されるサーバ有限状
態マシン・プロセスの状態図である。

【図４】 ネットワーク化オブジェクト環境をサポート
するのに適したコンピュータ・システムのブロック図で
ある。

【図５】 本発明の実施形態によるＯＲＢデーモン内で
動作する有限状態マシンの一実施形態の状態図である。

【図６】 本発明の一実施形態に関するホールドダウン
状態マシンの状態図である。

【図７】 ロケート要求に応答するプロセスの一実施形
態を示す図である。

【図８】 サーバ終了通知に応答するプロセスの一実施
形態を示す図である。

【図９】 タイムアウトに応答するプロセスの一実施形
態を示す図である。

【図１０】 サーバ登録に応答するプロセスの一実施形
態を示す図である。

【図１１】 サーバ・シャットダウン表示に応答するプ
ロセスの一実施形態を示す図である。

【符号の説明】

４１０ キーボード ４１１ マウス ４１２ 大容量記憶域 ４１３ 中央処理演算装置（ＣＰＵ） ４１４ ビデオ・メモリ ４１５ メイン・メモリ ４１６ ビデオ増幅器 ４１７ 陰極管ラスタ・モニタ ４１８ 二方向システム・バス ５００ 始動状態 ５０１ 始動中状態 ５０２ 実行中状態 ５０３ シャットダウン中状態 ５０４ 自己始動実行中状態 ６００ 非ホールドダウン状態 ６０１ 短いホールドダウン状態 ６０２ 長いホールドダウン状態

フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者 ケン・エム・カヴァナー アメリカ合衆国・94037・カリフォルニア 州・モンタナ・フィフス・357

Claims (12)

【特許請求の範囲】
1. 【請求項１】 サーバの活動化を制御する方法であっ
   て、 サーバ状態マシン内のサーバ状態を第１のサーバに関連
   付けるステップと、 前記サーバからシャットダウン表示を受け取ったときに
   前記サーバ状態を実行中状態からシャットダウン中状態
   に変更するステップと、 前記第１のサーバが前記シャットダウン中状態である
   間、第２のサーバの始動を妨げるステップと、 前記第１のサーバがシャットダウン・プロセスが完了し
   たことを示したときに前記状態を前記シャットダウン中
   状態から始動状態に変更するステップとを含むことを特
   徴とする方法。
2. 【請求項２】 さらに、シャットダウン中状態の間サー
   バの呼出しをブロックするステップを含むことを特徴と
   する請求項１に記載の方法。
3. 【請求項３】 さらに、自己始動サーバが登録されたと
   きに前記サーバ状態を前記始動状態から自己始動実行中
   状態に変更するステップを含むことを特徴とする請求項
   １に記載の方法。
4. 【請求項４】 さらに、前記サーバ状態が前記始動状態
   から始動中状態に変化したときにタイマを始動するステ
   ップを含むことを特徴とする請求項１に記載の方法。
5. 【請求項５】 さらに、前記サーバ状態が前記実行中状
   態から前記シャットダウン中状態に変化したときにタイ
   マを始動するステップを含むことを特徴とする請求項１
   に記載の方法。
6. 【請求項６】 さらに、 ロケート要求を受け取ったときに、ホールドダウン状態
   マシンに問い合わせるステップと、 前記ホールドダウン状態マシンに問い合わせた後、前記
   サーバ状態マシンに問い合わせるステップとを含むこと
   を特徴とする請求項１に記載の方法。
7. 【請求項７】 さらに、前記サーバ状態が前記実行中状
   態および前記自己始動実行中状態であるときにロケート
   要求に応答してサーバ・アドレス情報を返すステップを
   含むことを特徴とする請求項１に記載の方法。
8. 【請求項８】 サーバを制御する装置であって、 中央処理演算装置（ＣＰＵ）と、 前記ＣＰＵによって実行され、始動状態と、始動中状態
   と、実行中状態と、シャットダウン中状態とを有するサ
   ーバ状態マシンを備える制御プロセスとを備えることを
   特徴とする装置。
9. 【請求項９】 コンピュータ・プログラムを記録し、サ
   ーバを制御するためにコンピュータで使用可能な媒体自
   体内で具体化されるコンピュータ読取り可能なプログラ
   ムを記録したコンピュータ使用可能媒体において、 コンピュータに、サーバ状態をサーバと関連付けるよう
   に構成されたコンピュータ読取り可能なプログラムと、 コンピュータに、前記サーバからのシャットダウン表示
   に応答して前記サーバ状態を実行中状態からシャットダ
   ウン中状態に変更させるように構成されたコンピュータ
   読取り可能なプログラムと、 コンピュータに、前記サーバからのシャットダウン完了
   表示に応答して前記サーバ状態を前記シャットダウン中
   状態から始動状態に変更させるように構成されたコンピ
   ュータ読取り可能なプログラムと、 コンピュータに、前記シャットダウン中状態中の前記サ
   ーバへの呼出しをブロックさせるように構成されたコン
   ピュータ読取り可能なプログラムと記録したことを特徴
   とする記録媒体。
10. 【請求項１０】 さらに、 コンピュータに、自己始動サーバからの登録に応答して
    前記サーバ状態を前記始動状態から自己始動実行中状態
    に変更させるコンピュータ読取り可能なプログラムと、 コンピュータに、前記サーバ状態が前記実行中状態また
    は前記自己始動実行中状態であるときにロケート要求に
    応答してサーバ・アドレス情報を返させるコンピュータ
    読取り可能なプログラムとを記録してあることを特徴と
    する請求項９に記載の記録媒体。
11. 【請求項１１】 さらに、 コンピュータに、前記サーバ状態が前記始動状態である
    ときにロケート要求に応答し、前記シャットダウン表示
    に応答して、タイマ・プロセスを開始させるコンピュー
    タ読取り可能なプログラムと、 コンピュータに、前記タイマ・プロセスが満了したとき
    に前記サーバを終了させ前記サーバ状態を前記始動状態
    に変更させるコンピュータ読取り可能なプログラムとを
    記録してあることを特徴とする請求項９に記載の記録媒
    体。
12. 【請求項１２】 さらに、 コンピュータに、前記サーバにホールドダウン状態を関
    連付けさせるコンピュータ読取り可能なプログラムと、 前記ホールドダウン状態に基づいてロケート要求に対す
    る応答を判定するコンピュータ読取り可能なプログラム
    とを記録した請求項９に記載の記録媒体。