(57)【特許請求の範囲】
【請求項１】
コンピュータ・ネットワーク上で所定のサービスを提供するサービスシステムの動作状況をモニタするモニタシステムであって、
前記サービスシステムに参入しているモジュールとは別個に設けられ、該モジュールと通信可能なモニタモジュールを有し、
該モニタモジュールは、
前記サービスシステムに参入している他のモジュールを指定するとともに、その動作状況の通知を要求する前記モジュールからの要求情報を受信する第１の受信手段と、
前記要求情報で指定された前記サービスシステムに参入しているモジュールに対して、動作状況を要求する要求手段と、
検知すべきイベントとこれに対応する処理内容を登録したイベント・テーブルと、
前記要求手段による要求で指定したモジュールからの応答を受信する第２の受信手段と、
前記第２の受信手段で受信した応答に基づいて、前記イベント・テーブルに登録されたイベントの発生を検知する検知手段と、
前記検知手段によってイベントの発生が検知された場合、前記イベント・テーブルに登録された処理を実行する処理手段と、
前記第２の受信手段で受信した応答に基づいて、前記要求情報の発信元のモジュールへ通知を行う通知手段とを備えることを特徴とするモニタシステム。
【請求項２】
前記モニタモジュールが、前記サービスシステムに参入している各モジュールからイベント及びこれに対応する処理内容を示す情報を受信し、これを前記イベント・テーブルに登録する登録手段を更に備えることを特徴とする請求項１に記載のモニタシステム。
【請求項３】
前記サービスシステムに参入しているモジュールが被モニタモジュールとして機能する埋め込みモジュールを有し、
前記埋め込みモジュールが、
前記モニタモジュールへの前記要求情報において動作状況を要求すべきモジュールとその内容を指定する指定手段と、
前記モニタモジュールの前記通知手段からの通知を受信する第３の受信手段と、
前記第３の受信手段で受信した通知に基づいてユーザへの表示を行う表示手段とを備えることを特徴とする請求項１に記載のモニタシステム。
【請求項４】
コンピュータ・ネットワーク上で所定のサービスを提供するサービスシステムの動作状況をモニタする情報処理装置であって、
前記サービスシステムに参入しているモジュールとは別個に設けられ、該モジュールと通信可能なモニタモジュールを有し、
該モニタモジュールは、
前記サービスシステムに参入している他のモジュールを指定するとともに、その動作状態の通知を要求する前記モジュールからの要求情報を受信する第１の受信手段と、
前記要求情報で指定された前記サービスシステムに参入しているモジュールに対して、動作状況を要求する要求手段と、
検知すべきイベントとこれに対応する処理内容を登録したイベント・テーブルと、
前記要求手段による要求で指定したモジュールからの応答を受信する第２の受信手段と、
前記第２の受信手段で受信した応答に基づいて、前記イベント・テーブルに登録されたイベントの発生を検知する検知手段と、
前記検知手段によってイベントの発生が検知された場合、前記イベント・テーブルに登録された処理を実行する処理手段と、
前記第２の受信手段で受信した応答に基づいて、前記要求情報の発信元のモジュールへ通知を行う通知手段とを備えることを特徴とする情報処理装置。
【請求項５】
コンピュータ・ネットワーク上で所定のサービスを提供するサービスシステムの動作状況をモニタするモニタシステムにおいて、
前記サービスシステムに参入しているモジュールとは別個に設けられ、該モジュールと通信可能なモニタモジュールによって前記サービスシステムの動作状況をモニタする方法であって、
該モニタモジュールの制御方法は、
前記サービスシステムに参入している他のモジュールを指定するとともに、その動作状況の通知を要求する前記モジュールからの要求情報を受信する第１の受信工程と、
前記要求情報で指定された前記サービスシステムに参入しているモジュールに対して、動作状況を要求する要求工程と、
検知すべきイベントとこれに対応する処理内容を登録したイベント・テーブルと、
前記要求工程による要求で指定したモジュールからの応答を受信する第２の受信工程と、
前記第２の受信工程で受信した応答に基づいて、前記イベント・テーブルに登録されたイベントの発生を検知する検知工程と、
前記検知工程によってイベントの発生が検知された場合、前記イベント・テーブルに登録された処理を実行する処理工程と、
前記第２の受信工程で受信した応答に基づいて、前記要求情報の発信元のモジュールへ通知を行う通知工程とを備えることを特徴とするモニタシステムの制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インターネットやＬＡＮなどのコンピュータ・ネットワークにおける画像／音声／文書情報等のサービスの実現方法に関するものである。特に、映像／音声などのアクティブに変化する情報を扱うためにクライアント・サーバ方式で実現されたサービスにおける、動作状況の監視機構を実現する情報処理装置システム及び方法に関するものである。
【０００２】
【従来の技術】
近年の高速ＬＡＮおよびインターネット利用の一般化により、遠隔地のコンピュータが提供しているさまざまなサービス（情報提供やゲームなど）を、コンピュータネットワークを介して利用することが可能になりつつある。このようなサービスの代表的な例としては、ＷＷＷ（World WＩＤe Web）による文書情報提供サービス、動画と音声を放送するＶＯＤ（VＩＤeo on Demand）サービスなどが挙げられる。
【０００３】
通常、これらのサービスを提供するシステム（以降、サービス・システムという）はサーバ・クライアント方式のシステムとして実現される。この種のサービスシステムにおいては、サーバ・プログラム（以降、サーバ）はネットワークに結合された適当なコンピュータ（以降、ホスト）上で動作し、情報提供等のサービスを実行する。また、サービスの利用者（以降、ユーザ）は、最寄りのホストでクライアント・プログラム（以降、クライアント）を起動して、サーバが提供するサービスを利用する。
【０００４】
上記のような構成で実現されているサービス・システムの多くは、インターネット／ＬＡＮの大規模化に対応すべくサーバとクライアントの間に、データの中継を行う中継サーバを設置する方式を採用している。コンピュータネットワークの大規模化は、クライアント数の増大やネットワークを流れるデータ量の増加をもたらし、その結果、サーバ（以降、中継サーバと区別するためにメイン・サーバと呼ぶ）に大きな負荷がかかることになる。
【０００５】
ところで、中継サーバを導入することにより、以下のようなメリットが発生する。すなわち、
●メイン・サーバの負荷の軽減
●ネットワーク負荷の軽減
●クライアントの負荷の軽減
である。以下、上記各メリットについて説明を加える。
【０００６】
●メイン・サーバの負荷の軽減
中継サーバの導入により、メイン・サーバの機能の一部を中継サーバに代行させることができる。このため、サービスを利用するクライアントの管理機能を中継サーバに組み込むことにより、クライアントの数が非常に多くなっても、メイン・サーバの負荷を増加させずにすむようになる。
【０００７】
●ネットワーク負荷の軽減
インターネット等の大規模コンピュータ・ネットワークは、物理的には帯域の異なるさまざまな回線（電話線、光ファイバ等）が相互に接続されることによって実現されている。このため、ある回線では非常に高速にデータを送信することができるが、別の回線はその１００分の１程度の処理能力しかないような状況が発生する。この違いを考慮せずにメイン・サーバからクライアントにデータ送信を行うと、高速な回線を利用することのできるクライアントは十分な品質のデータを得ることができるが、低速な回線しか利用できないクライアントでは、データが部分的に欠落したり全く失われてしまうような状況が発生する。このような状況に対し、中継サーバがネットワークや回線の処理能力にあわせたデータ量やデータ品質の調整を行うことにより、すべてのクライアントが最善のサービスを受けることを可能にすることができる。
【０００８】
たとえば、ＶＯＤシステムにおける動画配送サービスを考える。サーバに２つのクライアントがアクセスしており、一方は１０Ｍｂｐｓ（Mega-bits per second）の通信が可能だが、もう一方とは６４Ｋｂｐｓ（Kilo-bits per second）でしか通信ができないとする。この状況で、１フレームが５００Ｋｂｉｔｓの画像を１秒間に２０フレーム送信した場合、１０Ｍｂｐｓの通信が可能な方では問題無くデータを受信することができる。しかしながら、６４Ｋｂｐｓの通信しかできない方では、１フレーム分のデータ送信のために約８秒もの時間が必要となってしまう。
【０００９】
そこで、中継サーバがメイン・サーバから送信されてきた動画データを、１フレームあたり１６Ｋｂｐｓで毎秒４フレームのデータに変換することで、６４Ｋｂｐｓの回線側のクライアントでもある程度の品質のサービスを受けることが可能となる。
【００１０】
●クライアントの負荷の軽減
中継サーバでは、メイン・サーバの機能を代行するだけでなく、クライアントが行う処理を代行させることも可能である。たとえば、メイン・サーバから送信されてきた画像等のデータを表示可能な形式に変換する処理は、通常はクライアントで行われる。しかしながら、クライアントの内部構造に依存しないタイプのデータ変換であったり、同一形式のデータを利用するクライアントが複数存在する場合、上記の変換処理を中継サーバで行うことができる。このようにすると、個々のクライアントが別々に行っていた処理を集中化することができるので、クライアントの負荷を軽減することが可能となる。
【００１１】
【発明が解決しようとする課題】
しかしながら、中継サーバの導入は、一方で以下のような解決すべき課題を生み出している。すなわち、
●サービス・システムの大規模化によるメンテナンスの困難性
●複数サービス統合のニーズ
である。以下、上記２つのアイテムについて説明を加える。
【００１２】
●サービス・システムの大規模化によるメンテナンスの困難性
ネットワークが大規模化すると、それに対応するために中継サーバの数も多くする必要がある。場合によっては中継サーバ同士が階層的に配置されるような構成をとる状況も考えられる。このような状況では、中継サーバがネットワーク上に分散してしまうため管理が難しくなる。
【００１３】
例えば、中継サーバに障害が発生し処理が停止してしまったとする。このときその中継サーバの管理下に置かれていたクライアントはメイン・サーバのサービスを利用することができなくなる。サービス停止の原因としては、
・メイン・サーバの障害によるサービス停止
・メイン・サーバの負荷増大による一時的なサービスの遅滞
・中継サーバの障害による中継処理の停止
・中継サーバの負荷増大による一時的な中継処理の遅滞
などが想定できる。
【００１４】
十分な情報を得る手段があれば、上述の各原因にあわせて
・サービス元の責任者に電話する
・他の中継サーバを利用する。別経路／別回線を利用する
・しばらく様子を見る
などの対処を行うことができるはずである。
【００１５】
しかし、本ケースでは、なぜサービスを利用することができなくなったのかの情報を提供してくれるはずの中継サーバが停止しているので、ユーザはサービス停止の原因を特定することができず、有効な対処を行うことが困難となる状況が発生してしまう。
【００１６】
●複数サービス統合のニーズ
ネットワーク環境では、あるサービスが単独で利用されるだけでなく複数のサービスを同時に利用するような状況が想定される。たとえば、動画送信サービスと音声送信サービスを同時に使用することによりテレビ電話サービスを実現することが可能である。
【００１７】
この点を考えると、「サービス・システムの大規模化によるメンテナンスの困難」を解決する上で、個々のサービス・システムで個別に対処するのではなく、より汎用性の高い機構／手段を提供することが望ましい。また中継サーバ等のバージョンアップや異なるメーカーによる中継サーバ／メイン・サーバ／クライアントの提供が行われるような状況においても、汎用性の高い機構／手段の提供は有用である。
【００１８】
現在、ＷＷＷの分野では複数のメーカーが開発したクライアント（Webブラウザ）が混在しており、ブラウザ間の非互換性が問題となっている。ＷＷＷ以外のサービス・システムでも同様な状況が発生する可能性がある。
【００１９】
本発明は上記の問題に鑑みてなされたものであり、任意のサービスシステムの各構成要素間に適用可能なモニタ機構を提供するモニタシステム及び制御方法及び情報処理装置を提供することを目的とする。
【００２０】
また、複数サービスが統合された場合にも、当該サービスシステムを構成する各モジュールの動作状況を適切に監視するモニタシステム及び制御方法及び情報処理装置を提供することを目的とする。
【００２１】
【課題を解決するための手段】
上記の目的を達成するため、例えば本発明のモニタシステムは以下のような構成を備える。即ち、
コンピュータ・ネットワーク上で所定のサービスを提供するサービスシステムの動作状況をモニタするモニタシステムであって、
前記サービスシステムに参入しているモジュールとは別個に設けられ、該モジュールと通信可能なモニタモジュールを有し、
該モニタモジュールは、
前記サービスシステムに参入している他のモジュールを指定するとともに、その動作状況の通知を要求する前記モジュールからの要求情報を受信する第１の受信手段と、
前記要求情報で指定された前記サービスシステムに参入しているモジュールに対して、動作状況を要求する要求手段と、
検知すべきイベントとこれに対応する処理内容を登録したイベント・テーブルと、
前記要求手段による要求で指定したモジュールからの応答を受信する第２の受信手段と、
前記第２の受信手段で受信した応答に基づいて、前記イベント・テーブルに登録されたイベントの発生を検知する検知手段と、
前記検知手段によってイベントの発生が検知された場合、前記イベント・テーブルに登録された処理を実行する処理手段と、
前記第２の受信手段で受信した応答に基づいて、前記要求情報の発信元のモジュールへ通知を行う通知手段とを備える。
【００２２】
【発明の実施の形態】
以下、添付の図面を参照して本発明の好適な実施形態を説明する。
【００２３】
＜第１の実施形態＞
ここでは、第１の実施形態として、インターネットを介したリモート映像サービス・システムへの本発明の適用について説明する。
【００２４】
リモート映像サービス・システムは、動画データをコンピュータネットワークを使用して放送する。ユーザは、専用のビューワ・ソフトを起動することにより、放送されている動画を鑑賞することができる。放送される動画データは、ビデオカメラからのライブ映像やビデオテープ等に録画された映像をMotionJPEGやMPEG等の動画データフォーマットに変換したものである。このリモート映像サービス・システムは、一般的な大規模ネットワーク上で動作するサービス・システムと同様に、メイン・サーバ／中継サーバ／クライアントから構成される。
【００２５】
図１は、本実施形態によるリモート映像サービス・システムの構成を示すブロック図である。このリモート映像サービス・システムには、本発明に関るサービス・モニタシステムが適用されている。
【００２６】
図１において、ワークステーション１０１は本実施形態における処理の実行をおこなうＣＰＵ１０２と、本実施形態における主なソフトウェア群（１１０、１１１、１１２、１１３）を保持する主記憶１０３を計算機バス１０４で結合することにより構成されている。また、主記憶１０３内のソフトウェア群（１１０、１１１、１１２、１１３）のプログラムを保持するための２次記憶装置であるハードディスク１０５、映像入出力のためのビデオカメラ１０６、ディスプレイ１０７、キーボード１０８、マウス１０９もワークステーション１０１に設置されている。
【００２７】
映像サーバ１１０はリモート映像サービス・システムにおけるメイン・サーバである。このソフトウェアは、ビデオカメラ１０６から取得したビデオ信号の動画データへの変換と、動画データのコンピュータ・ネットワーク等への放送を行う。
【００２８】
中継サーバ１１１は、映像サーバ１１０から動画データを受信して他の中継サーバや映像ビューワ１１２に中継する。中継サーバ１１０の機能としては、主に映像ビューワ１１２からの要求に応じて動画データの品質（フレームレポートや画像のサイズ、色数）の変換をおこなう。
【００２９】
映像ビューワ１１２はユーザが放送されている動画データを鑑賞するためのクライアントである。映像ビューワ１１２は、映像サーバ１１０から直接に、あるいは中継サーバ１１１を介して動画データを受信し、その内容をディスプレイ１０７に表示する。
【００３０】
モニタ・サーバ１１３は独立したサーバ・プログラムとして提供される、リモート映像サービス・システムの動作状況監視手段である。モニタ・サーバ１１３は、映像サーバ１１０／中継サーバ１１１／映像ビューワ１１２（以降、これらをまとめて被モニタ・モジュールとよぶ）の動作状況情報の収集と障害発生時の対処を行う。
【００３１】
なお、図１においては、上記のソフトウェア群（１１０、１１１、１１２、１１３）は同一ホスト上で動作しているが、実際の運用上は、各ソフトウェアは異なるホスト上で起動される。この場合は、各ホストがコンピュータ・ネットワークを介して相互に通信が可能でなければならない。
【００３２】
図９は各ソフトウエア群を異なるコンピュータで実現した状態を示す図である。同図において、コンピュータ１００１は映像サーバ１１０を実現し、カメラ１１００によって撮影した映像を中継サーバ或いはクライアントへネットワーク１０１０、１０１１等を介して送信する。コンピュータ１００２はモニタサーバ１１３を実現する。コンピュータ１００３、１００６は中継サーバ１１１を実現する。コンピュータ１００４、１００５、１００７は夫々映像ビューワ１１２を実現する。
【００３３】
なお、以下で説明している本実施形態の実現方法および動作は、コンピュータ・ネットワークを介した場合とそうでない場合との相違は全くないので、図１の構成に基づいて説明を行う。
【００３４】
また、図１に示した構成において、ビデオカメラ１０６の姿勢（パン、チルト）や、ズームの変更を、ネットワークを介して遠隔から操作可能に構成することも可能である。即ち、図９において、コンピュータ１００４、１００５、１００７から映像サーバ１００１のカメラ１１００の姿勢や、ズームの変更を操作することが可能である。
【００３５】
［モニタ・サーバ１１３の構成について］
モニタ・サーバ１１３は内部的には以下のソフトウェア・モジュールから構成されている。
【００３６】
●通知メッセージ送信モジュール１１４
通知メッセージ送信モジュール１１４は、モニタ・サーバ１１３から被モニタ・モジュール（映像サーバ１１０，中継サーバ１１１，映像ビューワ１１２）に「通知メッセージ」を送信するために使用されるモジュールである。なお、通知メッセージは、主に、モニタ・サーバ１１３が収集した各被モニタ・モジュールの動作状況に関する情報の伝達のために使用される。
【００３７】
被モニタ・モジュールは通知メッセージに付加された情報を利用して、夫々適当な処理をおこなう。例えば、映像ビューワ１１２なら、映像サーバ１１０や中継サーバ１１１等の動作状況をユーザにメッセージ等で表示するなどの処理を行うことができる。通知メッセージの詳細については後述する。
【００３８】
●要求メッセージ受信モジュール１１５
要求メッセージ受信モジュール１１５は、被モニタ・モジュール（１１０、１１１、１１２）から送信されてくる「要求メッセージ」を受信するモジュールである。被モニタ・モジュールは、要求メッセージをモニタ・サーバに送信することによって、あるプログラムの動作確認や動作状況に関する情報を取得することができる。
【００３９】
●被モニタ・モジュール管理テーブル１１８
要求メッセージ受信モジュール１１５及び通知メッセージ送信モジュール１１４は、一般的なオペレーティング・システムが提供するプロセス間通信の機構を用いて実現される。このプロセス間通信を行うために必要となるアドレスやポート番号等の情報は、被モニタ・モジュール管理テーブル１１８で管理される。被モニタ・モジュール管理テーブル１１８は、一般的なハッシュ表等の簡易データベース管理機構を用いて実現される。また、本格的なリレーショナル・データベースなどのデータベースシステムを利用しても実現可能である。なお、このモジュールは本発明における必須構成要素ではないが、本実施形態における実現方法上必要となる。
【００４０】
●要求メッセージ解釈／実行モジュール１１６
モニタ・サーバ１１３に送信された要求メッセージを解釈し、対応する処理を実行するモジュールである。要求メッセージ解釈／実行モジュール１１６の詳しい動作については後述する。
【００４１】
●イベント検知／処理モジュール１１７
このモジュールは、要求メッセージや通知メッセージ等の処理過程で検出された「イベント」の検知および識別と、検知した「イベント」に対する対処を実行する。ここで、「イベント」とは被モニタ・モジュールに発生したさまざまな障害をあらわすものである。イベント検知／処理モジュール１１７の詳しい動作についても後述する。
【００４２】
［被モニタ・モジュールの構成について］
夫々の被モニタ・モジュールは、モニタ埋め込みモジュール１２４を備えている。なお、図１では、映像ビューワ１１２の内部にのみモニタ埋め込みモジュール１２４を示してあるが、同様のモジュールが中継サーバ１１１、映像サーバ１１０にも備わっている。すなわち、すべての被モニタ・モジュール（１１０、１１１、１１２）には、モニタ・サーバ１１３の提供するモニタ機能を利用するために、モニタ埋め込みモジュール１２４が組み込まれている。このモニタ埋め込みモジュール１２４は、各被モニタ・プログラムの作成時に組み込まれるライブラリ・ルーチンとして提供される。モニタ埋め込みモジュール１２４は以下のモジュールから構成されている。
【００４３】
●通知メッセージ受信モジュール１１９
モニタ・サーバ１１３から送信されてきた通知メッセージを受信する。なお、受信された通知メッセージは通知メッセージ解釈／実行モジュール１２１に渡される。
【００４４】
●要求メッセージ送信モジュール１２０
モニタ・サーバ１１３に送信する要求メッセージの生成および送信を行う。要求メッセージ送信モジュール１２０及び通知メッセージ受信モジュール１１９もプロセス間通信の機構を用いて実現可能である。なお、具体的にどのような要求メッセージを使用するか等の詳細については後述する。
【００４５】
●通知メッセージ解釈／実行モジュール１２１
通知メッセージ解釈／実行モジュール１２１は通知メッセージを解釈し、メッセージの付加情報を抽出する。また、その付加情報に基づいた処理を実行する。例えば、映像ビューワならば、情報をグラフの形で表示したり、映像情報の取得を一時的に停止する、或いはエラーメッセージを表示するなどの処理が可能である。
【００４６】
なお、通知メッセージに対して実行される処理内容は、各被モニタ・モジュールの作成時に決定し、各被モニタ・モジュールのプログラムに埋め込んでおく必要がある。
【００４７】
また、映像サーバ１１０に組み込まれたモニタ埋め込みモジュールには、ネゴシエーション処理モジュール１２３が存在する。ネゴシエーション処理モジュール１２３は、後述するネゴシエーション・メッセージを使用して、モニタ・サーバ１１０が監視すべき項目やイベントの定義および、通知メッセージや要求メッセージに付加される情報の種類を指定する。
【００４８】
また、映像ビューワ１１２に組み込まれたモニタ埋め込みモジュール１２４には、ユーザインタフェース・モジュール１２２が追加されている。ユーザインタフェース・モジュール１２２は、リモート映像サービス全体の動作情報をグラフィカルに表示するためのモジュールである。ユーザインタフェース・モジュール１２２は通知メッセージ解釈／実行モジュールによって制御される。
【００４９】
図２はユーザインタフェース・モジュール１２２が提供する「動作状況表示ウィンドウ２０１」のインタフェース表示例を示す図である。
【００５０】
動作状況表示ウィンドウは、映像サーバ１１０／中継サーバ１１１／映像ビューワ１１２の関係をグラフィカルに表示する。各モジュール（映像サーバ、中継サーバ等）の動作状況は、そのモジュールをあらわす図形（２０２、２０３、２０４、２０５）上の暗色部分によって表現される。本例では、暗い部分が多いほど、そのモジュールには負荷がかかっていることを示す。
【００５１】
また、モジュール（２０２、２０３、２０４、２０６）間をつないでいる矢印（２０７、２０８、２０９）の太さは、モジュール間で送受信されているデータ量を表している。本例では、太いものほど多くのデータが流れていることを示す。
【００５２】
また、モジュールをあらわす図形は赤／緑／黄で塗り分けられており、
・緑は正常に動作していることを、
・赤はそのモジュールがトラブル等により停止していることを、
・黄は動作状況が不明であることを夫々示している。なお、図２中では、説明のために色の名前を付記してある。
【００５３】
本実施形態における動作状況表示ウィンドウ２０１は、モニタ埋め込みモジュール１２４の一部（ユーザインタフェース・モジュール１２２）として提供されるが、この部分は独立したプログラムとして（動作状況表示ウィンドウ・プログラムとして）実現することも可能である。この場合、この動作状況表示ウィンドウ・プログラムは映像ビューワといっしょに起動され同じ環境で動作する。
【００５４】
また、動作状況表示ウィンドウ・プログラムはモニタ・サーバと映像ビューアの間でメッセージ送受信の仲介プロセスとして機能する。
【００５５】
本実施形態で提供したユーザインタフェースは、単にシステムの動作状況をモニタするだけではなく、動作状況を操作するためのユーザインタフェースとしても使用できる。例えば、図２の暗色部の広さや矢印の太さをユーザが操作すると、その操作を要求メッセージ作成モジュールは要求メッセージに変換する。要求はモニタ・サーバ１１３を介して、中継サーバ１１１や映像サーバ１１０へ通知され、各動作状況を決定するパラメータを変更する。
【００５６】
[モニタ・プロトコル]
ここではモニタ・サーバ１１３と被モニタ・モジュール（１１０、１１１、１１２）間の通信プロトコルについて説明する。本実施形態における通信プロトコルは、
・ネゴシエーション・メッセージ
・通知メッセージ
・要求メッセージ
の３種類のメッセージから構成される。
【００５７】
また、以下の説明ではメッセージを、
［メッセージ名][付加情報名]=[値][付加情報名]=[値]...
という形式で表記する。ここで、"..."は同一項目（ここでは[付加情報名]=[値]）の繰り返しをあらわしている。
【００５８】
例えば、映像サーバＡの動作確認要求メッセージは、
do-ping to="映像サーバＡ"timeout=１０００msec
のように表記される。以下、各メッセージ毎に説明を行う。
【００５９】
●ネゴシエーション・メッセージ
要求／通知メッセージおよび障害の発生をあらわす「イベント」を決定するためのモニタ・サーバ１１３と被モニタ・モジュール間のネゴシエーション処理のためのメッセージである。厳密には要求メッセージの一種であり、要求メッセージ送信モジュール１２０／要求メッセージ受信モジュール１１５によってやり取りが行われる。ネゴシエーション処理は以下のネゴシエーション・メッセージを使用する。
【００６０】
（１）イベント定義メッセージ
映像サーバ１１０の停止等の障害の発生をあらわす「イベント」を定義するためのメッセージである。このメッセージをモニタ・サーバに送信すると、イベントが定義される。このメッセージは、
define-eventname=[イベント名]type=[イベントのタイプ][付加情報名]=（[付加情報のタイプ],[タイプ情報]...）...
という形式で表記される。
【００６１】
ここで、「イベント名」は定義されるイベントの名前である。また、「イベントのタイプ」は、そのイベントがあらわす事項の大まかな分類であり以下の３種類が定義されている。
○  障害：障害をあらわすイベント
○  定期通知：定期的に通知の送信をおこなわせるためのイベントである。タイマ・イベントとも呼ぶ。
○  非定期通知：定期的通知にも障害にも分類されないイベントには、このタイプを指定する。
【００６２】
また、「付加情報のタイプ」としては以下の４種類のタイプが指定できる。
○  文字列--文字列：タイプ情報として初期値を指定できる。例えば、
Messgage=（文字列,"イベントが発生しました。"）
のように使用できる。
○  整数値--整数の値：タイプ情報として初期値、最小値と最大値を指定できる。例えば、
SAMPLENUMBER=（整数値,０,-１００,１００）
のように使用できる。
○  実数値--実数の値：タイプ情報として初期値、最小値と最大値を指定できる。例えば、
SAMPLEVALUE=（実数値,０.５,-１０.９９,１００.０）
のように使用できる。
○  時刻--時刻をあらわす文字列：タイプ情報として"現在時刻"を指定するとイベントが発生した時刻が値として与えられる。例えば、
Time=（時刻,"TueNov１９１８:３１:０３JST１９９６"）
のように使用できる。
【００６３】
（２）イベント処理定義メッセージ
イベント発生時にモニタ・サーバ１１３が実行すべき処理を定義する。このメッセージは、
define-event-handler name=[イベント名]\{[通知メッセージ記述]...\}
という形式で表記される。なお、この記述からわかるように、モニタ・サーバ１１３がイベント発生時に行う処理は、各被モニタ・モジュールに通知メッセージを送ることのみである。
【００６４】
また、ここで指定される「通知メッセージ記述」は、
[通知メッセージ・ラベル][通知メッセージ名][付加情報名]=[付加情報の値]...
という形式で表記される。
【００６５】
「通知メッセージ・ラベル」はイベント処理定義メッセージ内の通知メッセージ記述にラベルをつけるために使用する。この項目は省略可能である。また、「付加情報の値」には、以下の様に記述することで、定義済みのイベント定義や通知メッセージの結果を利用することができる。すなわち、
[イベント名].[付加情報名]
[通知メッセージ・ラベル].[付加情報名]
という記述を行う。例えば、
"映像サーバＡの致命的障害"."発生時刻"
と記述することができる。
【００６６】
（３）イベント発生条件定義メッセージ
このメッセージは、イベントが発生する条件を定義する。このメッセージは以下の形式で表記される。すなわち、
define-event-condition name=[イベント名]（[通知メッセージ・パターン],[通知メッセージ条件]...）...
となる。
【００６７】
「通知メッセージ・パターン」にマッチする通知メッセージの結果が、同一括弧内に置かれている通知メッセージ条件を満たすとイベントが発生したものと判断される。通知メッセージ・パターンは、後述する通知メッセージ記述と同じ形式で記述する。
【００６８】
ただし、付加情報の値として以下の形式の指定が可能である。すなわち、
[付加情報名]=[付加情報の値]
という形式で記述する。上記の「付加情報の値」に一致した通知メッセージは、上記の通知メッセージ・パターンにマッチするとみなされる。通知メッセージ・パターンの例としては、例えば、
notice-want-info target="映像サーバＡ" about="クライアント数"
となる。
【００６９】
また、「通知メッセージ条件」は、イベントが発生する条件を指定するもので、以下の形式で記述される。すなわち、
[付加情報名]=[付加情報の値]
[付加情報名]=[付加情報の値の下限]-[付加情報の値の上限]
となる。ただし、上記記述において指定されている[付加情報の値]や[付加情報の値の下限]-[付加情報の値の上限]の範囲は、通知メッセージの結果に対して適用される。ただし、この形式で発生条件が指定されるのは障害タイプと非定期通知タイプのイベントのみである。
【００７０】
定期通知タイプのイベントでは以下の様に指定される。すなわち、
define-event-condition name=[イベント名] interval-time=[インターバル・タイム]
となる。
【００７１】
「インターバル・タイム」の単位はmsecであり、指定された時間が経過するごとにイベントが発生することになる。例えば、
define-event-condition name=定期メッセージinterval-time=60000
と記述することで、６０秒毎にイベントが発生することになる。
【００７２】
（４）イベント定義取得メッセージ
以下のメッセージを使用して、定義されたイベントの情報をモニタ・サーバから取得することが可能である。すなわち、
○  get-event-list：-定義された全イベントの名前を得ることができる。
○  get-event-definition name=イベント名：指定された名前のイベント定義、発生条件、イベント処理を得ることができる。
【００７３】
●通知メッセージ
通知メッセージとしては以下の５つのメッセージがあらかじめ定義されている。
【００７４】
（１）動作確認通知メッセージ
被モニタ・モジュールの動作確認のための通知である。この通知メッセージを受信した被モニタ・モジュールは要求リプライメッセージを返さなければならない。このメッセージは、
notice-ping
という形式で表記される。
【００７５】
（２）動作状況取得通知メッセージ
この通知は被モニタ・モジュールの動作状況に関する情報の取得のための通知である。このメッセージは、
notice-want-info target=[動作確認対象のモジュール名]about=[動作状況情報名]
という形式で表記される。例えば、
notice-want-info target="映像サーバＡ"about="クライアントの数"
と表記することができる。
【００７６】
（３）イベント通知メッセージ
この通知はイベント発生を被モニタ・モジュールに通知するメッセージである。このメッセージは、
notice-event name=[イベント名]target=[送り先][イベント関連情報]...
という形式で表記される。
【００７７】
ここで、「イベント関連情報」は、イベント定義時に指定される。また、notice-eventでは通知メッセージのtragetの値として、
all-[client-type]
という述語を使用することが可能である。ここで「client-type」はmain-server/proxy-server/clientのいずれかの文字列であり、この述語を指定すると「client-type」に属するすべての被モニタ・モジュールに通知メッセージを送信することができる。
【００７８】
（４）要求リプライメッセージ
この通知はモニタ・サーバに送信された要求メッセージに対する返答に使用される特殊な通知メッセージである。このメッセージは、
reply-request for=[要求メッセージＩＤ][付加情報名]=[値]....
という形式で表記される。なお、「要求メッセージＩＤ」は、要求メッセージに自動的に割り当てられる一意な識別子である。要求リプライメッセージは例えば
reply-request for="Request-100" "クライアントの数"="1000"
のように表記される。
【００７９】
（５）パラメータ設定メッセージ
この通知は被モニタ・モジュールに、パラメータの設定を指示するために使用される通知である。このメッセージは
notice-set-parameter target=[動作確認対象のモジュール名] [設定するパラメータ名]＝[値]...
の形式で表記される。このメッセージは設定するパラメータ名として、後述するようにＣＰＵ占有率や画像のデータ量などを指定して、被モニタ・モジュールの動作状況を変更する場合に使用する。
【００８０】
●要求メッセージ
要求メッセージとしては以下の６つのメッセージがあらかじめ定義されている。
【００８１】
（１）被モニタ・モジュール登録メッセージ
モニタ・サーバのクライアントとなる被モニタ・モジュールを被モニタ・モジュール管理テーブルに登録するためのメッセージである。付加情報としてプロセス間通信に必要なアドレス、ポート番号等の情報が追加される。登録された被モニタ・モジュールには一意なクライアントＩＤが割り当てられる。クライアントＩＤは被モニタ・モジュール登録メッセージに対するリプライ通知メッセージに付加されて被モニタ・モジュールに返される。
【００８２】
このメッセージは、
req-register type=[被モニタ・モジュールの種類] name=[モジュール名] addr=[アドレス] port=[ポート番号]
という形式で表記される。ここで、「被モニタ・モジュールの種類」では、
○  monitor-server
○  main-server
○  proxy-server
○  client
の４種類の値が指定され得る。それぞれ、モニタ・サーバ、メイン・サーバ、中継サーバ、クライアントのいずれかであることを示している。
【００８３】
また、「モジュール名」は登録される被モニタ・モジュールの名前であり、アドレス、ポート番号はプロセス間通信のために使用されるＩＰアドレスとポート番号である。
【００８４】
被モニタ・モジュール登録メッセージの表記例を示すと、
req-register type="main-server"name="映像サーバＡ"addr="192.168.111.111"port="123456"
となる。
【００８５】
（２）被モニタ・モジュール登録抹消メッセージ
この要求は被モニタ・モジュール管理モジュールから登録を抹消する。このメッセージは、
req-un-register client-ＩＤ=[クライアントＩＤ]
という以下の形式で表記される。被モニタ・モジュール登録抹消メッセージの表記例を示すと、
un-register client-ID="10"
となる。
【００８６】
（３）動作確認要求メッセージ
この要求は他の被モニタ・モジュールが動作しているか否かの確認処理を要求する。このメッセージは、
req-pingtarget=[動作確認対象のモジュール名]
という形式で用いられる。動作確認要求メッセージの表記例を示すと、
req-pingtarget="映像サーバＡ"
となる。
【００８７】
（４）動作状況取得要求メッセージ
この要求は他の被モニタ・モジュールの動作状況に関する情報の取得を要求する。このメッセージは、
req-want-info target=[動作確認対象のモジュール名]about=[動作状況情報名]
という形式で表記される。なお、結果はaboutで指定した動作状況情報名の現在の値がリプライ通知メッセージに付加されて返送される。動作状況取得要求メッセージの表記例を示すと、
req-want-info target="映像サーバＡ"about="クライアントの数"
となる。
【００８８】
（５）通知リプライメッセージ
この要求はモニタ・サーバから送信された通知メッセージに対する返答を行うための特殊な要求メッセージである。このメッセージは、
reply-notice for=[通知メッセージID] [付加情報名]=[値]....
という形式で表記される。「通知メッセージID」は、通知メッセージ送信モジュールによって通知メッセージに自動的に割り当てられる一意な識別子である。通知リプライメッセージの表記例を示すと、
reply-notice for="Notice-100" "クライアントの数"="1000"
となる。
【００８９】
（６）パラメータ設定要求メッセージ
この要求は被モニタ・モジュールから他の被モニタ・モジュールに、パラメータの設定を指示するために使用される要求である。このメッセージは、
req-set-parameter target=[動作確認対象のモジュール名] [設定するパラメータ名]=[値]...
という形式で表記される。このメッセージは設定するパラメータ名として、後述するようにＣＰＵ占有率や画像のデータ量等を設定して、被モニタ・モジュールの動作状況を変更する場合に使用する。
【００９０】
それでは、以上のモジュール構成とプロトコルによって実現される本実施形態の動作について説明する。なお、以下の説明では、初期状態ではモニタ・サーバ１１３のみが起動されている状態から、映像サーバ１１０、中継サーバ１１１、映像ビューワ１１２の順番で起動が行われたものとして説明を行う。
【００９１】
以下、図３〜図７を参照して、本実施形態におけるモニタ・サーバ及び被モニタ・モジュールの動作を説明する。なお、図６及び図７はモニタ・サーバの動作手順を表すフローチャートである。
【００９２】
まず図３および、図６、７を用いて被モニタ・モジュールの起動時および終了時の処理について説明する。図３は、装置立ち上げ時における被モニタ・モジュールとモニタ・サーバの動作を表す図である。
【００９３】
モニタ・サーバ１１３が起動されると、まず要求メッセージ待ちループに入る（ステップＳ７０１）。それから被モニタ・モジュール（ここでは、映像ビューワ１１２で説明するが、他のいかなる被モニタ・モジュールであってもよい）が起動されると、被モニタ・モジュール内の要求メッセージ送信モジュール１２０は被モニタ・モジュール登録メッセージ３１２をモニタ・サーバ１１３に送信する。送信された被モニタ・モジュール登録メッセージ３１２は、モニタ・サーバ内の要求メッセージ受信モジュール１１５によって受信される（ステップＳ７０１）。
【００９４】
要求メッセージ受信モジュール１１５は被モニタ・モジュール登録メッセージ３１２を受信すると、そのメッセージの内容を要求メッセージ解釈／実行モジュール１１６に転送する。要求メッセージ解釈／実行モジュール１１６は、送られてきた要求メッセージを解釈する（ステップＳ７０２）。そして、それが被モニタ・モジュール登録メッセージであることを検知すると（ステップＳ７０３）、新たな被モニタ・モジュールとして当該被モニタ・モジュール（映像ビューワ１１２）にクライアントＩＤを割り当てる（ステップＳ７０４）。それから、要求メッセージ３１２に付加されているアドレスとポート番号とを抽出し（ステップＳ７０５）、その結果を被モニタ・モジュール管理テーブル１１８に登録する（ステップＳ７０６）。
【００９５】
登録が終了すると、新しく生成されたクライアントＩＤを通知メッセージ送信モジュール１１４に転送して、登録完了を示す要求リプライ・メッセージ３１３を被モニタ・モジュール（映像ビューワ１１２）の通知メッセージ受信モジュール１１９に返送する（ステップＳ７０７）。
【００９６】
なお、以上では、被モニタ・モジュールとして映像ビューワ１１２を挙げて説明したが、他の被モニタ・モジュールである映像サーバ１１０／中継サーバ１１１のいずれにおいても、その起動時において上記処理が実行される。
【００９７】
同様にして、被モニタ・モジュールの終了処理時においても共通な処理が行われる。すなわち、被モニタ・モジュールは終了処理の直前に、モニタ・サーバ１１３に対して被モニタ・モジュール登録抹消メッセージ３１１を送信する。この要求メッセージ３１１をモニタ・サーバ１１３内の要求メッセージ受信モジュール１１５が受信すると（ステップＳ７０１）、登録処理と同様に要求メッセージ解釈／実行モジュール１１６に転送され、解釈／実行される（ステップＳ７０２）。
【００９８】
要求メッセージ解釈／実行モジュール１１６は要求メッセージ３１１が被モニタ・モジュール登録抹消メッセージであることを検知すると（ステップＳ７０３）、メッセージからクライアントＩＤを取り出す（ステップＳ７０８）。そしてその値をキーとして被モニタ・モジュール管理テーブル１１８から終了する被モニタ・モジュールの登録を削除する（ステップＳ７０９）。
【００９９】
さて、本実施形態では、映像サーバの登録が終了すると、モニタ・サーバと映像サーバ間でのネゴシエーション処理が開始される。図４は映像サーバとモニタ・サーバとの間のネゴシエーション処理を説明する図である。
【０１００】
上述した処理によって映像サーバ１１０の登録処理が終了し、映像サーバ１１０内の通知メッセージ受信モジュール１１９ａが要求リプライ・メッセージ４１４を受信すると、ネゴシエーション処理モジュール１２３によってネゴシエーション処理が開始される。
【０１０１】
この処理においてまず、ネゴシエーション処理モジュール１２３はリモート映像サービス・システムで必要となる「映像サーバのクラッシュ」、「中継サーバのクラッシュ」などのイベントを定義すべく、一連のイベント定義メッセージ４１５を要求メッセージ送信モジュール１２０ａを介してモニタ・サーバ１１３に送信する。
【０１０２】
以下、イベント定義メッセージに対する処理について説明を行う。ただし、以下に説明する処理は、イベント定義メッセージ／イベント処理定義メッセージ／イベント発生条件定義メッセージのいずれの対しても同様に行われる処理である。
【０１０３】
イベント定義メッセージ４１３は、要求メッセージと同様に要求メッセージ受信モジュール１１５によって受信される（ステップＳ７０１）。要求メッセージ受信モジュールは、要求メッセージ解釈／実行モジュール１１６に転送されるが（ステップＳ７０２）、要求メッセージ解釈／実行モジュール１１６ではイベント定義メッセージを処理できないので、このメッセージはさらにイベント検知／処理モジュール１１７に転送される（ステップＳ７０３、Ｓ７１０）。イベント検知／処理モジュール１１７は、内部的にイベントのテーブル（イベント・テーブル４１１）を保持しており、送られてきたイベントに関する情報をこのテーブルに登録する（ステップＳ７１１）。
【０１０４】
ネゴシエーション処理モジュール１２３において、各種イベント定義メッセージの送信が終了すると、引き続きイベント発生条件定義メッセージおよびイベント処理定義メッセージが送信され、イベント定義メッセージと同じ手順を繰り返して、イベント・テーブル４１１にイベント発生条件およびイベント処理を登録する。
【０１０５】
本実施形態における映像サーバ１１０のネゴシエーション処理では、以下のイベントが定義される。すなわち、
○"映像サーバのサービス停止"
○"映像サーバの一時的なbusy状態"
○"中継サーバのサービス停止"
○"中継サーバの一時的なbusy状態"
○"映像サーバのサービス再開"
○"中継サーバのサービス再開"
である。
【０１０６】
以下に例として"映像サーバのサービス停止"に対応するイベント定義及び、イベント処理定義を示すと、
・イベント定義
define-event name=映像サーバのサービス停止 type=障害 default-message="映像サーバに障害が発生しました。しばらくお待ちください。"
0003740233.tif 000002
のようになる。
【０１０７】
すべての中継サーバおよび映像ビューワにイベントの発生を通知する。映像ビューワには、表示すべきメッセージ文字列として、イベント情報のdefault-messageの値を与える。
【０１０８】
また、"映像サーバのサービス停止"に対応するイベント発生条件を示すと以下の通りである。
0003740233.tif 000003
即ち、動作確認メッセージを"映像サーバＡ"に送った結果がTIMEOUTならば"映像サーバのサービス停止"イベントを発生させる。
【０１０９】
図４ではネゴシエーション処理モジュールは１つしか存在しないので以上のような単純な手順でネゴシエーション処理が終了する。２つ以上のネゴシエーション処理モジュールが存在する場合は、一方が定義したイベントに他方が処理定義を追加したり、発生条件を変更する等の複雑なネゴシエーション処理を行うことができる。
【０１１０】
さて、以上の様にして登録されたイベントの発生検知およびイベント処理は以下の様にして処理される。
【０１１１】
イベントの発生検知処理は、定期通知イベントとそれ以外のタイプ（障害イベントと非定期通知イベント）とでは大きく異なる。
【０１１２】
まず、定期通知イベントの場合は、イベント登録後からの経過時間を逐次チェックし、指定されたインターバル・タイムが経過するごとにイベントの処理を開始する。この処理は、イベント検知／処理モジュール１１７が実行する。また、この経過時間のチェックの実現では、一般的なオペレーティングシステムが提供するタイマー機構を使用することもできる。この場合は、逐次チェックが不要となるのでＣＰＵ時間の無駄な消費を押さえることが出来るというメリットがある。
【０１１３】
障害イベントと非定期通知イベントの発生検知は、定期通知イベントや被モニタ・モジュールから送信されてきた要求メッセージによって行われる通知メッセージ処理が開始点となる。図５は被モニタ・モジュールから要求メッセージが送信された場合の処理を説明する図である。以下、図５を参照して、被モニタ・モジュール（ここでは、映像ビューワ１１２）から要求メッセージ５１２が送信されたものとして、処理の流れを説明する。
【０１１４】
被モニタ・モジュールからの要求メッセージ５１２を受信した要求メッセージ受信モジュール１１５は、メッセージを要求メッセージ解釈／実行モジュール１１６に転送する（ステップＳ７０１、Ｓ７０２）。この要求メッセージ５１２がイベント定義プロトコル以外の要求メッセージであった場合は（ステップＳ７０３）、通知メッセージを、要求メッセージ５１２に記述された「target」に送信するための依頼を、通知メッセージ送信モジュール１１４に発行する。
【０１１５】
通知メッセージ送信モジュール１１４は、要求に対応する通知メッセージ５１３を送信する。その後、送信したメッセージをイベント検知／処理モジュール１１７に転送する（ステップＳ７１２）。なお、図中では、たまたま通知メッセージ５１３のtargetが、最初に要求メッセージ５１２を送信した被モニタ・モジュール（即ち、映像ビューワ１１２自身）になっている。
【０１１６】
通知メッセージの転送を受けたイベント検知／処理モジュール１１７は、イベント・テーブル４１１を走査して、マッチする通知メッセージ・パターンがないかチェックする（ステップＳ７１３）。マッチする通知メッセージ・パターンが無い場合は、イベント検知／処理モジュール１１７は何もしない。一方、マッチする通知メッセージ・パターンが存在した場合は、その通知メッセージのメッセージＩＤを要求メッセージ受信モジュール１１５に通知する（ステップＳ７１４、Ｓ７１５）。
【０１１７】
要求メッセージ受信モジュール１１５は通常の場合、通知メッセージに対する通知リプライ・メッセージ５１４を受け取ると、そのままそのメッセージを要求メッセージ解釈／実行モジュール１１６に転送する（ステップＳ７１６、Ｓ７１７、Ｓ７１８）。要求メッセージ解釈／実行モジュール１１６は、通知メッセージ送信モジュール１１４を使用して、さらに通知リプライ・メッセージ５１４を要求リプライ・メッセージ５１５に変換し、元の被モニタ・モジュールに送り返す（ステップＳ７１８）。
【０１１８】
一方、要求メッセージ受信モジュール１１５がイベント検知／処理モジュール１１７からの通知を受けた場合、通知リプライ・メッセージ５１４は、まずイベント検知／処理モジュール１１７で処理される（ステップＳ７１７）。イベント検知／処理モジュール１１７は、通知リプライ・メッセージの付加情報をチェックし、先ほどマッチした通知メッセージ・パターンのイベント発生条件にマッチするか調べる（ステップＳ７１９）。マッチしなかった場合は、要求リプライ・メッセージは要求メッセージ解釈／実行モジュール１１６に再転送され、通常通りに被モニタ・モジュールに送り返される（ステップＳ７２０、Ｓ７１８）。
【０１１９】
これに対し、マッチした場合は、イベントの発生処理が行われ通常のリプライは行われない。この場合、イベント検知／処理モジュール１１７は発生したイベントをイベント・テーブル４１１を走査して、イベント処理定義を取り出す（ステップＳ７２０、Ｓ７２１）。さらにイベント処理定義の内容を解釈／実行する（ステップＳ７２２）。
【０１２０】
以上のようにして、ネゴシエーションで定義されたイベントの検知および処理が行われる。
【０１２１】
最後に、クライアント内に特有のユーザインタフェース・モジュールの動作について説明する。
【０１２２】
モニタ・サーバ１１３は、定期通知イベントや動作状況取得要求メッセージをきっかけとして映像サーバおよび中継サーバの動作状況通知メッセージをクライアントに送信する。クライアントは、この動作状況通知メッセージから必要な付加情報を取り出し、その値に基づいて、ユーザインタフェース・モジュールによる表示情報を更新する。定期通知イベントを利用することによって、定期的な動作状況の更新が行われるので、ユーザはその時々で最新の動作状況を得ることが可能となる。
【０１２３】
また、上述したように、図２に示したようなユーザインターフェースにおいて矢印の太さや、暗部の広さを変更することによってシステムの動作状況を変更することができる。
【０１２４】
●暗部の広さの変更
暗部の広さを変更することにより、図形に対応する映像サーバの被モニタ・モジュールがＣＰＵを占有できる割合い（ＣＰＵ占有率）を変更する。
【０１２５】
本実施形態では、暗色部の大きさの図形全体に対する割合を、ＣＰＵ占有率とみなす。ＣＰＵ占有率の指定が１００％ならば、その被モニタ・モジュールが完全にＣＰＵを占有することになり、ＣＰＵ占有率の指定が０％ならば、その被モニタ・モジュールは全く動作しないことになる。
【０１２６】
図形の半分が暗色部になるように指定すれば、ＣＰＵ占有率５０％を指定したことになる。例として、映像サーバＡを表す図形２０２の暗色部の広さを８０％に変更すると、この操作は以下のような要求メッセージに変換される。即ち、
req-set-parameter target=映像サーバＡ  ＣＰＵ占有率=８０％
となる。この要求メッセージは、モニタ・サーバ内の通常の要求メッセージの処理手順に従って以下の通知メッセージに変換され、映像サーバＡに送信される。即ち、
notice-set-parameter target=映像サーバＡ  ＣＰＵ占有率=８０％
となる。受信した映像サーバＡは、notice-set-parameterメッセージのＣＰＵ占有率の指示に従い、ＯＳが提供する機能（例えば、ＵＮＩＸならniceシステムコールなど´を使用して、自身のＣＰＵの占有率を変更する。
【０１２７】
●矢印の太さの変更
矢印の太さを変更することにより、矢印に対応する通信路に流れるデータ量を変更する。本実施形態では、矢印の太さの変更の割合を、データ量の変更の割合とみなす。例えば、矢印の太さを２倍にすれば、データ量を２倍にすることを指定したことになる。
【０１２８】
例として、映像サーバＡと中継サーバａの間の通信路を表す図形２０７の太さを２倍にするとこの操作は以下のような要求メッセージに変換される。即ち、
req-set-parameter target=映像サーバＡ  データ量変更率=２００％
となる。ここでの、targetはデータ量を制御する映像サーバＡとする。異なる実現方式により中継サーバａが制御するならば、targetに中継サーバａを指定することも可能である。この要求メッセージは、モニタ・サーバ内の通常の要求メッセージの処理手順に従って、
notice-set-parameter target=映像サーバＡ  データ量変更率=２００％
という通知メッセージに変換され、映像サーバＡに送信される。このメッセージを受信した映像サーバＡは、データ量変更率の指定に従い、画像の圧縮率や色数を変更することにより、通信路に流れるデータ量を変更する。
【０１２９】
なお、以上の矢印の太さ、暗色部の大きさの設定に限らず、本発明の実施に際しては、種々の設定の方法を用いることができる。
【０１３０】
以上のようにして本実施形態によれば、イベント検知／処理モジュールを有する動作状況監視機構をモニタ・サーバとして提供し、その他の被モニタ・モジュール（映像サーバ、中継サーバ、映像ビューワ）に動作状況処理機構を組み込んでいる。
【０１３１】
また、動作状況監視機構による動作状況監視や障害時の対処を行うために必要なイベント定義のためのプロトコルを規定し、映像サーバのネゴシエーション処理モジュールとモニタ・サーバ間でのネゴシエーション処理を実現している。
【０１３２】
さらに、モニタ・サーバと被モニタ・モジュール間で要求メッセージ／通知メッセージを交換することで、システム全体の動作状況に関する情報を各被モニタ・モジュールが獲得することを可能にし、かつその情報に基づき動作状況をグラフィカルにユーザに提示するためのユーザインタフェースを提供している。
【０１３３】
なお、本実施形態では、リモート映像サービス・システムを適用対象としたが、同様なメイン・サーバ／中継サーバ／クライアントから構成される他の音声、文字ベースのサービスにおいても本実施形態と全く同じ方法で動作状況のモニタが可能である。
【０１３４】
また、上述のメイン・サーバ、中継サーバ、クライアント（映像ビューワ）は複数であってもよく、中継サーバは無くてもよい。
【０１３５】
本実施形態特有の効果としては、動作状況監視機構をモニタ・サーバとして独立させることにより、被モニタ・モジュール側のモニタ関連部分が小規模で済む。このため、既存のサービス・システムにモニタ機構を組み込むことが容易である。
【０１３６】
また、ユーザインタフェースの提供によりユーザがシステム全体の動作状況を把握できるので、システム側による障害対策が十分でない場合も、ユーザが適切な処理が行われるよう対処することが可能となる。
【０１３７】
＜第２の実施形態＞
次に本発明の第２の実施形態について説明する。なお、第２の実施形態でも発明の適用対象として実施形態１と同じリモート映像サービス・システムをあつかう。ただし、図８に示す様に実施形態１とは異なった実現方法を採用している。すなわち本実施形態では、モニタ・サーバに相当する部分を独立したサーバとして実現するのではなく、各被モニタ・モジュール内のライブラリルーチンとして実現する。
【０１３８】
図８における各構成要素は、モニタ・サーバ１１３（図１）の提供する機能が図８ではモニタ・モジュール６１３として映像ビューワに組み込まれていることをのぞき、図１にける同一番号の構成要素と同じ機能をもっている。また、図８においても図１と同様に、モニタ埋め込みモジュール１２４は映像サーバ１１０、中継サーバ１１１にも組み込まれている。ただし、第２の実施形態におけるモニタ埋め込みモジュール１２４は、ネゴシエーション処理モジュール１２３とユーザ・インタフェースモジュール１２２の両方を備えている。また、モニタ・モジュール６１３も、モニタ埋め込みモジュール１２４と同様に、映像サーバ１１０、中継サーバ１１１にも組み込まれているものとする。
【０１３９】
このため、本実施形態における各構成要素の行う処理は、第１の実施形態とほぼ同様に動作する。従って、以下では第１の実施形態との相違点について説明することにする。
【０１４０】
（１）ブロードキャスト機構の利用
第２の実施形態では、起動処理等で発行される要求メッセージは、システム中のすべての構成要素（映像サーバ１１０、中継サーバ１１１、映像ビューワ１１２）にブロードキャストされる。この点を除くと、各構成要素の行う処理は図３〜図７で説明したものと全く同じ処理を行うことになる。
【０１４１】
（２）ネゴシエーション処理
第１の実施形態では、映像サーバ１１０のみがネゴシエーション処理モジュール１２３を備えていたが、第２の実施形態ではすべての構成要素がネゴシエーション処理モジュール１２３を備える。各ネゴシエーション処理モジュールは、任意の構成要素上のモニタ・モジュールと第１実施形態で説明したプロトコルを用いてネゴシエーションを行うことができる。
【０１４２】
このため、各モニタ・モジュール内のイベント検知・処理モジュール１１６には、それぞれ異なったイベントが登録され得る。たとえば、中継サーバ１１１には映像ビューワ１１２と映像サーバ１１０に関するイベントが定義されるが、映像サーバ１１０と映像ビューワ１１２には中継サーバ１１１に関するイベントのみが定義される、といった切り分けを行うことができる。
【０１４３】
また、特殊な機能をもつサーバ（たとえば画像の蓄積サーバ）を導入して、独自のイベント定義を追加することも可能である。
【０１４４】
以上の様に、第２の実施形態では、動作状況監視機構としてのモニタ・モジュールをサービス・システムの各構成要素に組み込むことにより、個々の構成要素が独自の動作状況モニタを行うことが可能となる。このことにより、サービス・システムに新たな機能を持つ構成要素を追加する場合、他の構成要素に修正を加える必要がなくなるという効果をもつ。
【０１４５】
以上説明したように、上記各実施形態によれば、任意のサービスに適用可能なモニタ機構の提供が可能となる。また、システムの起動時あるいは動作中に適切な障害対策処理を指定することが可能となる。更に、複数のサービスを組み合わせて使用する場合にも適用可能なモニタ機構の提供が可能となる。
【０１４６】
なお、上記第１及び第２の実施形態のサービスシステムにおいて、各被モニタ・モジュールはモニタサーバへアクセスを行うためのアドレスを知っておく必要がある。これを実現する方法としては、たとえば、モニタ埋め込みモジュールを被モニタ・モジュールに組み込む際に、モニタモジュールのアドレスを決めてしまう、或いは、システム内でブロードキャストを行って、モニタモジュールのアドレスを通知してもらう等が挙げられる。特に第２の実施形態では、ブロードキャスト機構が備わっているので、これを利用してモニタサーバのアドレスの通知要求をブロードキャストするようにしてもよい。
【０１４７】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
【０１４８】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１４９】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１５０】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１５１】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５２】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５３】
【発明の効果】
以上説明したように、本発明によれば、任意のサービスシステムの各構成要素間に適用可能なモニタ機構が提供され、サービスシステムにおける操作性が向上する。
【０１５４】
また、本発明によれば、複数サービスが統合された場合にも、当該サービスシステムを構成する各モジュールの動作状況を適切に監視することが可能となる。
【図面の簡単な説明】
【図１】第１の実施形態によるリモート映像サービス・システムの構成を示すブロック図である。
【図２】ユーザインタフェース・モジュール１２２が提供する「動作状況表示ウィンドウ２０１」のインタフェース表示例を示す図である。
【図３】装置立ち上げ時における被モニタ・モジュールとモニタ・サーバの動作を表す図である。
【図４】映像サーバとモニタ・サーバとの間のネゴシエーション処理を説明する図である。
【図５】被モニタ・モジュールから要求メッセージが送信された場合の処理を説明する図である。
【図６】モニタ・サーバの動作手順を表すフローチャートである。
【図７】モニタ・サーバの動作手順を表すフローチャートである。
【図８】第２の実施形態によるリモート映像サービス・システムの構成を示すブロック図である。
【図９】映像サーバ、中継サーバ、クライアント（映像ビューワ）を、ネットワーク接続された独立したコンピュータによって実現した状態を示す図である。
【図１】
0003740233.tif 000004
【図２】
0003740233.tif 000005
【図３】
0003740233.tif 000006
【図４】
0003740233.tif 000007
【図５】
0003740233.tif 000008
【図６】
0003740233.tif 000009
【図７】
0003740233.tif 000010
【図８】
0003740233.tif 000011
【図９】
0003740233.tif 000012