JPH10161960A - モニタシステム及び制御方法及び情報処理装置 - Google Patents

Abstract

(57)【要約】 【課題】任意のサービスシステムの各構成要素間に適用
可能なモニタ機構を提供する。 【解決手段】コンピュータ・ネットワーク上で所定のサ
ービスを提供するサービスシステムにモニタサーバ１１
３を導入する。モニタサーバは、サービスシステムに参
入している映像サーバ１１０、中継サーバ１１１、映像
ビューワ１１２とは別個に設けられるが、各サーバには
モニタサーバと通信可能なモニタ埋め込みモジュールが
組み込まれる。モニタサーバは、サービスシステムに参
入しているサーバのモニタ埋め込みモジュールに対して
対応するサーバの動作状況の報告を要求するとともに、
その応答を受信してこれに対応する処理を実行する。例
えば、応答内容を映像ビューワ１１２の埋め込みもジュ
ールに通知し、ユーザインターフェース・モジュール１
２２によって通知内容を表示させる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、インターネットや
ＬＡＮなどのコンピュータ・ネットワークにおける画像
／音声／文書情報等のサービスの実現方法に関するもの
である。特に、映像／音声などのアクティブに変化する
情報を扱うためにクライアント・サーバ方式で実現され
たサービスにおける、動作状況の監視機構を実現する情
報処理装置システム及び方法に関するものである。

【０００２】

【従来の技術】近年の高速ＬＡＮおよびインターネット
利用の一般化により、遠隔地のコンピュータが提供して
いるさまざまなサービス（情報提供やゲームなど）を、
コンピュータネットワークを介して利用することが可能
になりつつある。このようなサービスの代表的な例とし
ては、ＷＷＷ（World WＩＤe Web）による文書情報提供
サービス、動画と音声を放送するＶＯＤ（VＩＤeo on D
emand）サービスなどが挙げられる。

【０００３】通常、これらのサービスを提供するシステ
ム（以降、サービス・システムという）はサーバ・クラ
イアント方式のシステムとして実現される。この種のサ
ービスシステムにおいては、サーバ・プログラム（以
降、サーバ）はネットワークに結合された適当なコンピ
ュータ（以降、ホスト）上で動作し、情報提供等のサー
ビスを実行する。また、サービスの利用者（以降、ユー
ザ）は、最寄りのホストでクライアント・プログラム
（以降、クライアント）を起動して、サーバが提供する
サービスを利用する。

【０００４】上記のような構成で実現されているサービ
ス・システムの多くは、インターネット／ＬＡＮの大規
模化に対応すべくサーバとクライアントの間に、データ
の中継を行う中継サーバを設置する方式を採用してい
る。コンピュータネットワークの大規模化は、クライア
ント数の増大やネットワークを流れるデータ量の増加を
もたらし、その結果、サーバ（以降、中継サーバと区別
するためにメイン・サーバと呼ぶ）に大きな負荷がかか
ることになる。

【０００５】ところで、中継サーバを導入することによ
り、以下のようなメリットが発生する。すなわち、 ●メイン・サーバの負荷の軽減 ●ネットワーク負荷の軽減 ●クライアントの負荷の軽減 である。以下、上記各メリットについて説明を加える。

【０００６】●メイン・サーバの負荷の軽減 中継サーバの導入により、メイン・サーバの機能の一部
を中継サーバに代行させることができる。このため、サ
ービスを利用するクライアントの管理機能を中継サーバ
に組み込むことにより、クライアントの数が非常に多く
なっても、メイン・サーバの負荷を増加させずにすむよ
うになる。

【０００７】●ネットワーク負荷の軽減 インターネット等の大規模コンピュータ・ネットワーク
は、物理的には帯域の異なるさまざまな回線（電話線、
光ファイバ等）が相互に接続されることによって実現さ
れている。このため、ある回線では非常に高速にデータ
を送信することができるが、別の回線はその１００分の
１程度の処理能力しかないような状況が発生する。この
違いを考慮せずにメイン・サーバからクライアントにデ
ータ送信を行うと、高速な回線を利用することのできる
クライアントは十分な品質のデータを得ることができる
が、低速な回線しか利用できないクライアントでは、デ
ータが部分的に欠落したり全く失われてしまうような状
況が発生する。このような状況に対し、中継サーバがネ
ットワークや回線の処理能力にあわせたデータ量やデー
タ品質の調整を行うことにより、すべてのクライアント
が最善のサービスを受けることを可能にすることができ
る。

【０００８】たとえば、ＶＯＤシステムにおける動画配
送サービスを考える。サーバに２つのクライアントがア
クセスしており、一方は１０Ｍｂｐｓ（Mega-bits per
second）の通信が可能だが、もう一方とは６４Ｋｂｐｓ
（Kilo-bits per second）でしか通信ができないとす
る。この状況で、１フレームが５００Ｋｂｉｔｓの画像
を１秒間に２０フレーム送信した場合、１０Ｍｂｐｓの
通信が可能な方では問題無くデータを受信することがで
きる。しかしながら、６４Ｋｂｐｓの通信しかできない
方では、１フレーム分のデータ送信のために約８秒もの
時間が必要となってしまう。

【０００９】そこで、中継サーバがメイン・サーバから
送信されてきた動画データを、１フレームあたり１６Ｋ
ｂｐｓで毎秒４フレームのデータに変換することで、６
４Ｋｂｐｓの回線側のクライアントでもある程度の品質
のサービスを受けることが可能となる。

【００１０】●クライアントの負荷の軽減 中継サーバでは、メイン・サーバの機能を代行するだけ
でなく、クライアントが行う処理を代行させることも可
能である。たとえば、メイン・サーバから送信されてき
た画像等のデータを表示可能な形式に変換する処理は、
通常はクライアントで行われる。しかしながら、クライ
アントの内部構造に依存しないタイプのデータ変換であ
ったり、同一形式のデータを利用するクライアントが複
数存在する場合、上記の変換処理を中継サーバで行うこ
とができる。このようにすると、個々のクライアントが
別々に行っていた処理を集中化することができるので、
クライアントの負荷を軽減することが可能となる。

【００１１】

【発明が解決しようとする課題】しかしながら、中継サ
ーバの導入は、一方で以下のような解決すべき課題を生
み出している。すなわち、 ●サービス・システムの大規模化によるメンテナンスの
困難性 ●複数サービス統合のニーズ である。以下、上記２つのアイテムについて説明を加え
る。

【００１２】●サービス・システムの大規模化によるメ
ンテナンスの困難性 ネットワークが大規模化すると、それに対応するために
中継サーバの数も多くする必要がある。場合によっては
中継サーバ同士が階層的に配置されるような構成をとる
状況も考えられる。このような状況では、中継サーバが
ネットワーク上に分散してしまうため管理が難しくな
る。

【００１３】例えば、中継サーバに障害が発生し処理が
停止してしまったとする。このときその中継サーバの管
理下に置かれていたクライアントはメイン・サーバのサ
ービスを利用することができなくなる。サービス停止の
原因としては、 ・メイン・サーバの障害によるサービス停止 ・メイン・サーバの負荷増大による一時的なサービスの
遅滞 ・中継サーバの障害による中継処理の停止 ・中継サーバの負荷増大による一時的な中継処理の遅滞 などが想定できる。

【００１４】十分な情報を得る手段があれば、上述の各
原因にあわせて ・サービス元の責任者に電話する ・他の中継サーバを利用する。別経路／別回線を利用す
る ・しばらく様子を見る などの対処を行うことができるはずである。

【００１５】しかし、本ケースでは、なぜサービスを利
用することができなくなったのかの情報を提供してくれ
るはずの中継サーバが停止しているので、ユーザはサー
ビス停止の原因を特定することができず、有効な対処を
行うことが困難となる状況が発生してしまう。

【００１６】●複数サービス統合のニーズ ネットワーク環境では、あるサービスが単独で利用され
るだけでなく複数のサービスを同時に利用するような状
況が想定される。たとえば、動画送信サービスと音声送
信サービスを同時に使用することによりテレビ電話サー
ビスを実現することが可能である。

【００１７】この点を考えると、「サービス・システム
の大規模化によるメンテナンスの困難」を解決する上
で、個々のサービス・システムで個別に対処するのでは
なく、より汎用性の高い機構／手段を提供することが望
ましい。また中継サーバ等のバージョンアップや異なる
メーカーによる中継サーバ／メイン・サーバ／クライア
ントの提供が行われるような状況においても、汎用性の
高い機構／手段の提供は有用である。

【００１８】現在、ＷＷＷの分野では複数のメーカーが
開発したクライアント（Webブラウザ）が混在してお
り、ブラウザ間の非互換性が問題となっている。ＷＷＷ
以外のサービス・システムでも同様な状況が発生する可
能性がある。

【００１９】本発明は上記の問題に鑑みてなされたもの
であり、任意のサービスシステムの各構成要素間に適用
可能なモニタ機構を提供するモニタシステム及び制御方
法及び情報処理装置を提供することを目的とする。

【００２０】また、複数サービスが統合された場合に
も、当該サービスシステムを構成する各モジュールの動
作状況を適切に監視するモニタシステム及び制御方法及
び情報処理装置を提供することを目的とする。

【００２１】

【課題を解決するための手段】上記の目的を達成するた
め、例えば本発明のモニタシステムは以下のような構成
を備える。即ち、コンピュータ・ネットワーク上で所定
のサービスを提供するサービスシステムの動作状況をモ
ニタするモニタシステムであって、前記サービスシステ
ムに参入しているモジュールとは別個に設けられ、該モ
ジュールと通信可能なモニタモジュールを有し、前記モ
ニタモジュールより前記サービスシステムに参入してい
るモジュールに対して動作状況を要求する要求手段と、
前記モニタモジュールにおいて前記要求手段による要求
に対する応答を受信し、該応答に対応する処理を実行す
る処理手段とを備える。

【００２２】

【発明の実施の形態】以下、添付の図面を参照して本発
明の好適な実施形態を説明する。

【００２３】＜第１の実施形態＞ここでは、第１の実施
形態として、インターネットを介したリモート映像サー
ビス・システムへの本発明の適用について説明する。

【００２４】リモート映像サービス・システムは、動画
データをコンピュータネットワークを使用して放送す
る。ユーザは、専用のビューワ・ソフトを起動すること
により、放送されている動画を鑑賞することができる。
放送される動画データは、ビデオカメラからのライブ映
像やビデオテープ等に録画された映像をMotionJPEGやMP
EG等の動画データフォーマットに変換したものである。
このリモート映像サービス・システムは、一般的な大規
模ネットワーク上で動作するサービス・システムと同様
に、メイン・サーバ／中継サーバ／クライアントから構
成される。

【００２５】図１は、本実施形態によるリモート映像サ
ービス・システムの構成を示すブロック図である。この
理モード映像サービス／システムには、本発明に関るサ
ービス・モニタシステムが適用されている。

【００２６】図１において、ワークステーション１０１
は本実施形態における処理の実行をおこなうＣＰＵ１０
２と、本実施形態における主なソフトウェア群（１１
０、１１１、１１２、１１３）を保持する主記憶１０３
を計算機バス１０４で結合することにより構成されてい
る。また、主記憶１０３内のソフトウェア群（１１０、
１１１、１１２、１１３）のプログラムを保持するため
の２次記憶装置であるハードディスク１０５、映像入出
力のためのビデオカメラ１０６、ディスプレイ１０７、
キーボード１０８、マウス１０９もワークステーション
１０１に設置されている。

【００２７】映像サーバ１１０はリモート映像サービス
・システムにおけるメイン・サーバである。このソフト
ウェアは、ビデオカメラ１０６から取得したビデオ信号
の動画データへの変換と、動画データのコンピュータ・
ネットワーク等への放送を行う。

【００２８】中継サーバ１１１は、映像サーバ１１０か
ら動画データを受信して他の中継サーバや映像ビューワ
１１２に中継する。中継サーバ１１０の機能としては、
主に映像ビューワ１１２からの要求に応じて動画データ
の品質（フレームレポートや画像のサイズ、色数）の変
換をおこなう。

【００２９】映像ビューワ１１２はユーザが放送されて
いる動画データを鑑賞するためのクライアントである。
映像ビューワ１１２は、映像サーバ１１０から直接に、
あるいは中継サーバ１１１を介して動画データを受信
し、その内容をディスプレイ１０７に表示する。

【００３０】モニタ・サーバ１１３は独立したサーバ・
プログラムとして提供される、リモート映像サービス・
システムの動作状況監視手段である。モニタ・サーバ１
１３は、映像サーバ１１０／中継サーバ１１１／映像ビ
ューワ１１２（以降、これらをまとめて被モニタ・モジ
ュールとよぶ）の動作状況情報の収集と障害発生時の対
処を行う。

【００３１】なお、図１においては、上記のソフトウェ
ア群（１１０、１１１、１１２、１１３）は同一ホスト
上で動作しているが、実際の運用上は、各ソフトウェア
は異なるホスト上で起動される。この場合は、各ホスト
がコンピュータ・ネットワークを介して相互に通信が可
能でなければならない。

【００３２】図９は各ソフトウエア群を異なるコンピュ
ータで実現した状態を示す図である。同図において、コ
ンピュータ１００１は映像サーバ１１０を実現し、カメ
ラ１１００によって撮影した映像を中継サーバ或いはク
ライアントへネットワーク１０１０、１０１１等を介し
て送信する。コンピュータ１００２はモニタサーバ１１
３を実現する。コンピュータ１００３、１００６は中継
サーバ１１１を実現する。コンピュータ１００４、１０
０５、１００７は夫々映像ビューワ１１２を実現する。

【００３３】なお、以下で説明している本実施形態の実
現方法および動作は、コンピュータ・ネットワークを介
した場合とそうでない場合との相違は全くないので、図
１の構成に基づいて説明を行う。

【００３４】また、図１に示した構成において、ビデオ
カメラ１０６の姿勢（パン、チルト）や、ズームの変更
を、ネットワークを介して遠隔から操作可能に構成する
ことも可能である。即ち、図９において、コンピュータ
１００４、１００５、１００７から映像サーバ１００１
のカメラ１１００の姿勢や、ズームの変更を操作するこ
とが可能である。

【００３５】［モニタ・サーバ１１３の構成について］
モニタ・サーバ１１３は内部的には以下のソフトウェア
・モジュールから構成されている。

【００３６】●通知メッセージ送信モジュール１１４ 通知メッセージ送信モジュール１１４は、モニタ・サー
バ１１３から被モニタ・モジュール（映像サーバ１１
０，中継サーバ１１１，映像ビューワ１１２）に「通知
メッセージ」を送信するために使用されるモジュールで
ある。なお、通知メッセージは、主に、モニタ・サーバ
１１３が収集した各被モニタ・モジュールの動作状況に
関する情報の伝達のために使用される。

【００３７】被モニタ・モジュールは通知メッセージに
付加された情報を利用して、夫々適当な処理をおこな
う。例えば、映像ビューワ１１２なら、映像サーバ１１
０や中継サーバ１１１等の動作状況をユーザにメッセー
ジ等で表示するなどの処理を行うことができる。通知メ
ッセージの詳細については後述する。

【００３８】●要求メッセージ受信モジュール１１５ 要求メッセージ受信モジュール１１５は、被モニタ・モ
ジュール（１１０、１１１、１１２）から送信されてく
る「要求メッセージ」を受信するモジュールである。被
モニタ・モジュールは、要求メッセージをモニタ・サー
バに送信することによって、あるプログラムの動作確認
や動作状況に関する情報を取得することができる。

【００３９】●被モニタ・モジュール管理テーブル１１
８ 要求メッセージ受信モジュール１１５及び通知メッセー
ジ送信モジュール１１４は、一般的なオペレーティング
・システムが提供するプロセス間通信の機構を用いて実
現される。このプロセス間通信を行うために必要となる
アドレスやポート番号等の情報は、被モニタ・モジュー
ル管理テーブル１１８で管理される。被モニタ・モジュ
ール管理テーブル１１８は、一般的なハッシュ表等の簡
易データベース管理機構を用いて実現される。また、本
格的なリレーショナル・データベースなどのデータベー
スシステムを利用しても実現可能である。なお、このモ
ジュールは本発明における必須構成要素ではないが、本
実施形態における実現方法上必要となる。

【００４０】●要求メッセージ解釈／実行モジュール１
１６ モニタ・サーバ１１３に送信された要求メッセージを解
釈し、対応する処理を実行するモジュールである。要求
メッセージ解釈／実行モジュール１１６の詳しい動作に
ついては後述する。

【００４１】●イベント検知／処理モジュール１１７ このモジュールは、要求メッセージや通知メッセージ等
の処理過程で検出された「イベント」の検知および識別
と、検知した「イベント」に対する対処を実行する。こ
こで、「イベント」とは被モニタ・モジュールに発生し
たさまざまな障害をあらわすものである。イベント検知
／処理モジュール１１７の詳しい動作についても後述す
る。

【００４２】［被モニタ・モジュールの構成について］
夫々の被モニタ・モジュールは、モニタ埋め込みモジュ
ール１２４を備えている。なお、図１では、映像ビュー
ワ１１２の内部にのみモニタ埋め込みモジュール１２４
を示してあるが、同様のモジュールが中継サーバ１１
１、映像サーバ１１０にも備わっている。すなわち、す
べての被モニタ・モジュール（１１０、１１１、１１
２）には、モニタ・サーバ１１３の提供するモニタ機能
を利用するために、モニタ埋め込みモジュール１２４が
組み込まれている。このモニタ埋め込みモジュール１２
４は、各被モニタ・プログラムの作成時に組み込まれる
ライブラリ・ルーチンとして提供される。モニタ埋め込
みモジュール１２４は以下のモジュールから構成されて
いる。

【００４３】●通知メッセージ受信モジュール１１９ モニタ・サーバ１１３から送信されてきた通知メッセー
ジを受信する。なお、受信された通知メッセージは通知
メッセージ解釈／実行モジュール１２１に渡される。

【００４４】●要求メッセージ送信モジュール１２０ モニタ・サーバ１１３に送信する要求メッセージの生成
および送信を行う。要求メッセージ送信モジュール１２
０及び通知メッセージ受信モジュール１１９もプロセス
間通信の機構を用いて実現可能である。なお、具体的に
どのような要求メッセージを使用するか等の詳細につい
ては後述する。

【００４５】●通知メッセージ解釈／実行モジュール１
２１ 通知メッセージ解釈／実行モジュール１２１は通知メッ
セージを解釈し、メッセージの付加情報を抽出する。ま
た、その付加情報に基づいた処理を実行する。例えば、
映像ビューワならば、情報をグラフの形で表示したり、
映像情報の取得を一時的に停止する、或いはエラーメッ
セージを表示するなどの処理が可能である。

【００４６】なお、通知メッセージに対して実行される
処理内容は、各被モニタ・モジュールの作成時に決定
し、各被モニタ・モジュールのプログラムに埋め込んで
おく必要がある。

【００４７】また、映像サーバ１１０に組み込まれたモ
ニタ埋め込みモジュールには、ネゴシエーション処理モ
ジュール１２３が存在する。ネゴシエーション処理モジ
ュール１２３は、後述するネゴシエーション・メッセー
ジを使用して、モニタ・サーバ１１０が監視すべき項目
やイベントの定義および、通知メッセージや要求メッセ
ージに付加される情報の種類を指定する。

【００４８】また、映像ビューワ１１２に組み込まれた
モニタ埋め込みモジュール１２４には、ユーザインタフ
ェース・モジュール１２２が追加されている。ユーザイ
ンタフェース・モジュール１２２は、リモート映像サー
ビス全体の動作情報をグラフィカルに表示するためのモ
ジュールである。ユーザインタフェース・モジュール１
２２は通知メッセージ解釈／実行モジュールによって制
御される。

【００４９】図２はユーザインタフェース・モジュール
１２２が提供する「動作状況表示ウィンドウ２０１」の
インタフェース表示例を示す図である。

【００５０】動作状況表示ウィンドウは、映像サーバ１
１０／中継サーバ１１１／映像ビューワ１１２の関係を
グラフィカルに表示する。各モジュール（映像サーバ、
中継サーバ等）の動作状況は、そのモジュールをあらわ
す図形（２０２、２０３、２０４、２０５）上の暗色部
分によって表現される。本例では、暗い部分が多いほ
ど、そのモジュールには負荷がかかっていることを示
す。

【００５１】また、モジュール（２０２、２０３、２０
４、２０６）間をつないでいる矢印（２０７、２０８、
２０９）の太さは、モジュール間で送受信されているデ
ータ量を表している。本例では、太いものほど多くのデ
ータが流れていることを示す。

【００５２】また、モジュールをあらわす図形は赤／緑
／黄で塗り分けられており、 ・緑は正常に動作していることを、 ・赤はそのモジュールがトラブル等により停止している
ことを、 ・黄は動作状況が不明であることを夫々示している。な
お、図２中では、説明のために色の名前を付記してあ
る。

【００５３】本実施形態における動作状況表示ウィンド
ウ２０１は、モニタ埋め込みモジュール１２４の一部
（ユーザインタフェース・モジュール１２２）として提
供されるが、この部分は独立したプログラムとして（動
作状況表示ウィンドウ・プログラムとして）実現するこ
とも可能である。この場合、この動作状況表示ウィンド
ウ・プログラムは映像ビューワといっしょに起動され同
じ環境で動作する。

【００５４】また、動作状況表示ウィンドウ・プログラ
ムはモニタ・サーバと映像ビューアの間でメッセージ送
受信の仲介プロセスとして機能する。

【００５５】本実施形態で提供したユーザインタフェー
スは、単にシステムの動作状況をモニタするだけではな
く、動作状況を操作するためのユーザインタフェースと
しても使用できる。例えば、図２の暗色部の広さや矢印
の太さをユーザが操作すると、その操作を要求メッセー
ジ作成モジュールは要求メッセージに変換する。要求は
モニタ・サーバ１１３を介して、中継サーバ１１１や映
像サーバ１１０へ通知され、各動作状況を決定するパラ
メータを変更する。

【００５６】[モニタ・プロトコル]ここではモニタ・サ
ーバ１１３と被モニタ・クライアント（１１０、１１
１、１１２）間の通信プロトコルについて説明する。本
実施形態における通信プロトコルは、 ・ネゴシエーション・メッセージ ・通知メッセージ ・要求メッセージ の３種類のメッセージから構成される。

【００５７】また、以下の説明ではメッセージを、 ［メッセージ名][付加情報名]=[値][付加情報名]=
[値]... という形式で表記する。ここで、"..."は同一項目（こ
こでは[付加情報名]=[値]）の繰り返しをあらわしてい
る。

【００５８】例えば、映像サーバＡの動作確認要求メッ
セージは、 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] という述語を使用することが可能である。ここで「clie
nt-type」はmain-server/proxy-server/clientのいずれ
かの文字列であり、この述語を指定すると「client-typ
e」に属するすべての被モニタ・モジュールに通知メッ
セージを送信することができる。

【００７８】（４）要求リプライメッセージ この通知はモニタ・サーバに送信された要求メッセージ
に対する返答に使用される特殊な通知メッセージであ
る。このメッセージは、 reply-request for=[要求メッセージＩＤ][付加情報名]
=[値].... という形式で表記される。なお、「要求メッセージＩ
Ｄ」は、要求メッセージに自動的に割り当てられる一意
な識別子である。要求リプライメッセージは例えばrepl
y-request for="Request-100" "クライアントの数"="10
00"のように表記される。

【００７９】（５）パラメータ設定メッセージ この通知は被モニタ・モジュールに、パラメータの設定
を指示するために使用される通知である。このメッセー
ジは notice-set-parameter target=[動作確認対象のモジュ
ール名] [設定するパラメータ名]＝[値]... の形式で表記される。このメッセージは設定するパラメ
ータ名として、後述するようにＣＰＵ占有率や画像のデ
ータ量などを指定して、被モニタ・モジュールの動作状
況を変更する場合に使用する。

【００８０】●要求メッセージ 要求メッセージとしては以下の６つのメッセージがあら
かじめ定義されている。

【００８１】（１）被モニタ・モジュール登録メッセー
ジ モニタ・サーバのクライアントとなる被モニタ・モジュ
ールを被モニタ・モジュール管理テーブルに登録するた
めのメッセージである。付加情報としてプロセス間通信
に必要なアドレス、ポート番号等の情報が追加される。
登録された被モニタ・モジュールには一意なクライアン
トＩＤが割り当てられる。クライアントＩＤは被モニタ
・モジュール登録メッセージに対するリプライ通知メッ
セージに付加されて被モニタ・モジュールに返される。

【００８２】このメッセージは、 req-register type=[被モニタ・モジュールの種類] nam
e=[モジュール名] 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=[動作確認対象のモジュール名]a
bout=[動作状況情報名] という形式で表記される。なお、結果は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=" 映像サーバに障害が発生しました。しばらくお待ちくだ
さい。" ・イベント処理定義 define-event-handler name=映像サーバのサービス停止{ notice-event name=映像サーバのサービス停止 target=all-proxy-server mes sage="" notify-event name=映像サーバのサービス停止 target=all-viewer-client message={映像サーバのサービス停止.default-message} } のようになる。

【０１０７】すべての中継サーバおよび映像ビューワに
イベントの発生を通知する。映像ビューワには、表示す
べきメッセージ文字列として、イベント情報のdefault-
messageの値を与える。

【０１０８】また、"映像サーバのサービス停止"に対応
するイベント発生条件を示すと以下の通りである。 ・イベント発生条件 define-event-condition name=映像サーバのサービス停止（ ping target="映像サーバＡ"、 result=TIMEOUT ） 即ち、動作確認メッセージを"映像サーバＡ"に送った結
果がTIMEOUTならば"映像サーバのサービス停止"イベン
トを発生させる。

【０１０９】図４ではネゴシエーション処理モジュール
は１つしか存在しないので以上のような単純な手順でネ
ゴシエーション処理が終了する。２つ以上のネゴシエー
ション処理モジュールが存在する場合は、一方が定義し
たイベントに他方が処理定義を追加したり、発生条件を
変更する等の複雑なネゴシエーション処理を行うことが
できる。

【０１１０】さて、以上の様にして登録されたイベント
の発生検知およびイベント処理は以下の様にして処理さ
れる。

【０１１１】イベントの発生検知処理は、定期通知イベ
ントとそれ以外のタイプ（障害イベントと非定期通知イ
ベント）とでは大きく異なる。

【０１１２】まず、定期通知イベントの場合は、イベン
ト登録後からの経過時間を逐次チェックし、指定された
インターバル・タイムが経過するごとにイベントの処理
を開始する。この処理は、イベント検知／処理モジュー
ル１１７が実行する。また、この経過時間のチェックの
実現では、一般的なオペレーティングシステムが提供す
るタイマー機構を使用することもできる。この場合は、
逐次チェックが不要となるのでＣＰＵ時間の無駄な消費
を押さえることが出来るというメリットがある。

【０１１３】障害イベントと非定期通知イベントの発生
検知は、定期通知イベントや被モニタ・モジュールから
送信されてきた要求メッセージによって行われる通知メ
ッセージ処理が開始点となる。図５は被モニタ・モジュ
ールから要求メッセージが送信された場合の処理を説明
する図である。以下、図５を参照して、被モニタ・モジ
ュール（ここでは、映像ビューワ１１２）から要求メッ
セージ５１２が送信されたものとして、処理の流れを説
明する。

【０１１４】被モニタ・モジュールからの要求メッセー
ジ５１２を受信した要求メッセージ受信モジュール１１
５は、メッセージを要求メッセージ解釈／実行モジュー
ル１１６に転送する（ステップＳ７０１、Ｓ７０２）。
この要求メッセージ５１２がイベント定義プロトコル以
外の要求メッセージであった場合は（ステップＳ７０
３）、通知メッセージを、要求メッセージ５１２に記述
された「target」に送信するための依頼を、通知メッセ
ージ送信モジュール１１４に発行する。

【０１１５】通知メッセージ送信モジュール１１４は、
要求に対応する通知メッセージ５１３を送信する。その
後、送信したメッセージをイベント検知／処理モジュー
ル１１７に転送する（ステップＳ７１２）。なお、図中
では、たまたま通知メッセージ５１３のtargetが、最初
に要求メッセージ５１２を送信した被モニタ・モジュー
ル（即ち、映像ビューワ１１２自身）になっている。

【０１１６】通知メッセージの転送を受けたイベント検
知／処理モジュール１１７は、イベント・テーブル４１
１を走査して、マッチする通知メッセージ・パターンが
ないかチェックする（ステップＳ７１３）。マッチする
通知メッセージ・パターンが無い場合は、イベント検知
／処理モジュール１１７は何もしない。一方、マッチす
る通知メッセージ・パターンが存在した場合は、その通
知メッセージのメッセージＩＤを要求メッセージ受信モ
ジュール１１５に通知する（ステップＳ７１４、Ｓ７１
５）。

【０１１７】要求メッセージ受信モジュール１１５は通
常の場合、通知メッセージに対する通知リプライ・メッ
セージ５１４を受け取ると、そのままそのメッセージを
要求メッセージ解釈／実行モジュール１１６に転送する
（ステップＳ７１６、Ｓ７１７、Ｓ７１８）。要求メッ
セージ解釈／実行モジュール１１６は、通知メッセージ
送信モジュール１１４を使用して、さらに通知リプライ
・メッセージ５１４を要求リプライ・メッセージ５１５
に変換し、元の被モニタ・モジュールに送り返す（ステ
ップＳ７１８）。

【０１１８】一方、要求メッセージ受信モジュール１１
５がイベント検知／処理モジュール１１７からの通知を
受けた場合、通知リプライ・メッセージ５１４は、まず
イベント検知／処理モジュール１１７で処理される（ス
テップＳ７１７）。イベント検知／処理モジュール１１
７は、要求リプライ・メッセージの付加情報をチェック
し、先ほどマッチした通知メッセージ・パターンのイベ
ント発生条件にマッチするか調べる（ステップＳ７１
９）。マッチしなかった場合は、要求リプライ・メッセ
ージは要求メッセージ解釈／実行モジュール１１６に再
転送され、通常通りに被モニタ・モジュールに送り返さ
れる（ステップＳ７２０、Ｓ７１８）。

【０１１９】これに対し、マッチした場合は、イベント
の発生処理が行われ通常のリプライは行われない。この
場合、イベント検知／処理モジュール１１７は発生した
イベントをイベント・テーブル４１１を走査して、イベ
ント処理定義を取り出す（ステップＳ７２０、Ｓ７２
１）。さらにイベント処理定義の内容を解釈／実行する
（ステップＳ７２２）。

【０１２０】以上のようにして、ネゴシエーションで定
義されたイベントの検知および処理が行われる。

【０１２１】最後に、クライアント内に特有のユーザイ
ンタフェース・モジュールの動作について説明する。

【０１２２】モニタ・サーバ１１３は、定期通知イベン
トや動作状況取得要求メッセージをきっかけとして映像
サーバおよび中継サーバの動作状況通知メッセージをク
ライアントに送信する。クライアントは、この動作状況
通知メッセージから必要な付加情報を取り出し、その値
に基づいて、ユーザインタフェース・モジュールによる
表示情報を更新する。定期通知イベントを利用すること
によって、定期的な動作状況の更新が行われるので、ユ
ーザはその時々で最新の動作状況を得ることが可能とな
る。

【０１２３】また、上述したように、図２に示したよう
なユーザインターフェースにおいて矢印の太さや、暗部
の広さを変更することによってシステムの動作状況を変
更することができる。

【０１２４】●暗部の広さの変更 暗部の広さを変更することにより、図形に対応する映像
サーバの被モニタ・モジュールがＣＰＵを占有できる割
合い（ＣＰＵ占有率）を変更する。

【０１２５】本実施形態では、暗色部の大きさの図形全
体に対する割合を、ＣＰＵ占有率とみなす。ＣＰＵ占有
率の指定が１００％ならば、その被モニタ・モジュール
が完全にＣＰＵを占有することになり、ＣＰＵ占有率の
指定が０％ならば、その被モニタ・モジュールは全く動
作しないことになる。

【０１２６】図形の半分が暗色部になるように指定すれ
ば、ＣＰＵ占有率５０％を指定したことになる。例とし
て、映像サーバＡを表す図形２０２の暗色部の広さを８
０％に変更すると、この操作は以下のような要求メッセ
ージに変換される。即ち、 req-set-parameter target=映像サーバＡ ＣＰＵ占有
率=８０％ となる。この要求メッセージは、モニタ・サーバ内の通
常の要求メッセージの処理手順に従って以下の通知メッ
セージに変換され、映像サーバＡに送信される。即ち、 notice-set-parameter target=映像サーバＡ ＣＰＵ占
有率=８０％ となる。受信した映像サーバＡは、notice-set-paramet
erメッセージのＣＰＵ占有率の指示に従い、ＯＳが提供
する機能（例えば、ＵＮＩＸならniceシステムコールな
ど´を使用して、自身のＣＰＵの占有率を変更する。

【０１２７】●矢印の太さの変更 矢印の太さを変更することにより、矢印に対応する通信
路に流れるデータ量を変更する。本実施形態では、矢印
の太さの変更の割合を、データ量の変更の割合とみな
す。例えば、矢印の太さを２倍にすれば、データ量を２
倍にすることを指定したことになる。

【０１２８】例として、映像サーバＡと中継サーバａの
間の通信路を表す図形２０７の太さを２倍にするとこの
操作は以下のような要求メッセージに変換される。即
ち、 req-set-parameter target=映像サーバＡ データ量変
更率=２００％ となる。ここでの、targetはデータ量を制御する映像サ
ーバＡとする。異なる実現方式により中継サーバａが制
御するならば、targetに中継サーバａを指定することも
可能である。この要求メッセージは、モニタ・サーバ内
の通常の要求メッセージの処理手順に従って、 notice-set-parameter target=映像サーバＡ データ量
変更率=２００％ という通知メッセージに変換され、映像サーバＡに送信
される。このメッセージを受信した映像サーバＡは、デ
ータ量変更率の指定に従い、画像の圧縮率や色数を変更
することにより、通信路に流れるデータ量を変更する。

【０１２９】なお、以上の矢印の太さ、暗色部の大きさ
の設定に限らず、本発明の実施に際しては、種々の設定
の方法を用いることができる。

【０１３０】以上のようにして本実施形態によれば、イ
ベント検知／処理モジュールを有する動作状況監視機構
をモニタ・サーバとして提供し、その他の被モニタ・モ
ジュール（映像サーバ、中継サーバ、映像ビューワ）に
動作状況処理機構を組み込んでいる。

【０１３１】また、動作状況監視機構による動作状況監
視や障害時の対処を行うために必要なイベント定義のた
めのプロトコルを規定し、映像サーバのネゴシエーショ
ン処理モジュールとモニタ・サーバ間でのネゴシエーシ
ョン処理を実現している。

【０１３２】さらに、モニタ・サーバと被モニタ・モジ
ュール間で要求メッセージ／通知メッセージを交換する
ことで、システム全体の動作状況に関する情報を各被モ
ニタ・モジュールが獲得することを可能にし、かつその
情報に基づき動作状況をグラフィカルにユーザに提示す
るためのユーザインタフェースを提供している。

【０１３３】なお、本実施形態では、リモート映像サー
ビス・システムを適用対象としたが、同様なメイン・サ
ーバ／中継サーバ／クライアントから構成される他の音
声、文字ベースのサービスにおいても本実施形態と全く
同じ方法で動作状況のモニタが可能である。

【０１３４】また、上述のメイン・サーバ、中継サー
バ、クライアント（映像ビューワ）は複数であってもよ
く、中継サーバは無くてもよい。

【０１３５】本実施形態特有の効果としては、動作状況
監視機構をモニタ・サーバとして独立させることによ
り、被モニタ・モジュール側のモニタ関連部分が小規模
で済む。このため、既存のサービス・システムにモニタ
機構を組み込むことが容易である。

【０１３６】また、ユーザインタフェースの提供により
ユーザがシステム全体の動作状況を把握できるので、シ
ステム側による障害対策が十分でない場合も、ユーザが
適切な処理が行われるよう対処することが可能となる。

【０１３７】＜第２の実施形態＞次に本発明の第２の実
施形態について説明する。なお、第２の実施形態でも発
明の適用対象として実施形態１と同じリモート映像サー
ビス・システムをあつかう。ただし、図８に示す様に実
施形態１とは異なった実現方法を採用している。すなわ
ち本実施形態では、モニタ・サーバに相当する部分を独
立したサーバとして実現するのではなく、各被モニタ・
モジュール内のライブラリルーチンとして実現する。

【０１３８】図８における各構成要素は、モニタ・サー
バ１１３（図１）の提供する機能が図８ではモニタ・モ
ジュール６１３として映像ビューワに組み込まれている
ことをのぞき、図１にける同一番号の構成要素と同じ機
能をもっている。また、図８においても図１と同様に、
モニタ埋め込みモジュール１２４は映像サーバ１１０、
中継サーバ１１１にも組み込まれている。ただし、第２
の実施形態におけるモニタ埋め込みモジュール１２４
は、ネゴシエーション処理モジュール１２３とユーザ・
インタフェースモジュール１２２の両方を備えている。
また、モニタ・モジュール６１３も、モニタ埋め込みモ
ジュール１２４と同様に、映像サーバ１１０、中継サー
バ１１１にも組み込まれているものとする。

【０１３９】このため、本実施形態における各構成要素
の行う処理は、第１の実施形態とほぼ同様に動作する。
従って、以下では第１の実施形態との相違点について説
明することにする。

【０１４０】（１）ブロードキャスト機構の利用 第２の実施形態では、起動処理等で発行される要求メッ
セージは、システム中のすべての構成要素（映像サーバ
１１０、中継サーバ１１１、映像ビューワ１１２）にブ
ロードキャストされる。この点を除くと、各構成要素の
行う処理は図３〜図７で説明したものと全く同じ処理を
行うことになる。

【０１４１】（２）ネゴシエーション処理 第１の実施形態では、映像サーバ１１０のみがネゴシエ
ーション処理モジュール１２３を備えていたが、第２の
実施形態ではすべての構成要素がネゴシエーション処理
モジュール１２３を備える。各ネゴシエーション処理モ
ジュールは、任意の構成要素上のモニタ・モジュールと
第１実施形態で説明したプロトコルを用いてネゴシエー
ションを行うことができる。

【０１４２】このため、各モニタ・モジュール内のイベ
ント検知・処理モジュール１１６には、それぞれ異なっ
たイベントが登録され得る。たとえば、中継サーバ１１
１には映像ビューワ１１２と映像サーバ１１０に関する
イベントが定義されるが、映像サーバ１１０と映像ビュ
ーワ１１２には中継サーバ１１１に関するイベントのみ
が定義される、といった切り分けを行うことができる。

【０１４３】また、特殊な機能をもつサーバ（たとえば
画像の蓄積サーバ）を導入して、独自のイベント定義を
追加することも可能である。

【０１４４】以上の様に、第２の実施形態では、動作状
況監視機構としてのモニタ・モジュールをサービス・シ
ステムの各構成要素に組み込むことにより、個々の構成
要素が独自の動作状況モニタを行うことが可能となる。
このことにより、サービス・システムに新たな機能を持
つ構成要素を追加する場合、他の構成要素に修正を加え
る必要がなくなるという効果をもつ。

【０１４５】以上説明したように、上記各実施形態によ
れば、任意のサービスに適用可能なモニタ機構の提供が
可能となる。また、システムの起動時あるいは動作中に
適切な障害対策処理を指定することが可能となる。更
に、複数のサービスを組み合わせて使用する場合にも適
用可能なモニタ機構の提供が可能となる。

【０１４６】なお、上記第１及び第２の実施形態のサー
ビスシステムにおいて、各被モニタ・モジュールはモニ
タサーバへアクセスを行うためのアドレスを知っておく
必要がある。これを実現する方法としては、たとえば、
モニタ埋め込みモジュールを被モニタ・モジュールに組
み込む際に、モニタモジュールのアドレスを決めてしま
う、或いは、システム内でブロードキャストを行って、
モニタモジュールのアドレスを通知してもらう等が挙げ
られる。特に第２の実施形態では、ブロードキャスト機
構が備わっているので、これを利用してモニタサーバの
アドレスの通知要求をブロードキャストするようにして
もよい。

【０１４７】なお、本発明は、複数の機器（例えばホス
トコンピュータ，インタフェイス機器，リーダ，プリン
タなど）から構成されるシステムに適用しても、一つの
機器からなる装置（例えば、複写機，ファクシミリ装置
など）に適用してもよい。

【０１４８】また、本発明の目的は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体を、システムあるいは装置に供給し、そ
のシステムあるいは装置のコンピュータ（またはＣＰＵ
やＭＰＵ）が記憶媒体に格納されたプログラムコードを
読出し実行することによっても、達成されることは言う
までもない。

【０１４９】この場合、記憶媒体から読出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。

【０１５０】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピディスク，ハードディス
ク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ
−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭな
どを用いることができる。

【０１５１】また、コンピュータが読出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているＯＳ（オペレ
ーティングシステム）などが実際の処理の一部または全
部を行い、その処理によって前述した実施形態の機能が
実現される場合も含まれることは言うまでもない。

【０１５２】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るＣＰＵなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。

【０１５３】

【発明の効果】以上説明したように、本発明によれば、
任意のサービスシステムの各構成要素間に適用可能なモ
ニタ機構が提供され、サービスシステムにおける操作性
が向上する。

【０１５４】また、本発明によれば、複数サービスが統
合された場合にも、当該サービスシステムを構成する各
モジュールの動作状況を適切に監視することが可能とな
る。

【図面の簡単な説明】

【図１】第１の実施形態によるリモート映像サービス・
システムの構成を示すブロック図である。

【図２】ユーザインタフェース・モジュール１２２が提
供する「動作状況表示ウィンドウ２０１」のインタフェ
ース表示例を示す図である。

【図３】装置立ち上げ時における被モニタ・モジュール
とモニタ・サーバの動作を表す図である。

【図４】映像サーバとモニタ・サーバとの間のネゴシエ
ーション処理を説明する図である。

【図５】被モニタ・モジュールから要求メッセージが送
信された場合の処理を説明する図である。

【図６】モニタ・サーバの動作手順を表すフローチャー
トである。

【図７】モニタ・サーバの動作手順を表すフローチャー
トである。

【図８】第２の実施形態によるリモート映像サービス・
システムの構成を示すブロック図である。

【図９】映像サーバ、中継サーバ、クライアント（映像
ビューワ）を、ネットワーク接続された独立したコンピ
ュータによって実現した状態を示す図である。

Claims (28)

【特許請求の範囲】
1. 【請求項１】 コンピュータ・ネットワーク上で所定の
   サービスを提供するサービスシステムの動作状況をモニ
   タするモニタシステムであって、 前記サービスシステムに参入しているモジュールとは別
   個に設けられ、該モジュールと通信可能なモニタモジュ
   ールを有し、 前記モニタモジュールより前記サービスシステムに参入
   しているモジュールに対して動作状況を要求する要求手
   段と、 前記モニタモジュールにおいて前記要求手段による要求
   に対する応答を受信し、該応答に対応する処理を実行す
   る処理手段とを備えることを特徴とするモニタシステ
   ム。
2. 【請求項２】 前記モニタモジュールにおいて、モジュ
   ールを指定するとともにその動作状態の通知を要求する
   要求情報を受信する受信手段を更に備え、前記要求手段
   は、前記要求情報で指定されたモジュールに動作状況を
   要求することを特徴とする請求項１に記載のモニタシス
   テム。
3. 【請求項３】 前記処理手段は、前記要求手段に対する
   応答を受信し、該応答に基づいて前記要求情報の発行元
   のモジュールへ通知を行うことを特徴とする請求項２に
   記載のモニタシステム。
4. 【請求項４】 検知すべきイベントとこれに対応する処
   理内容を登録したイベントテーブルと、 前記イベントテーブルに登録されたイベントの発生を検
   知する検知手段と、 前記検知手段によってイベントの発生が検知された場
   合、前記イベントテーブルに登録された処理を実行する
   イベント実行手段とを更に備えることを特徴とする請求
   項３に記載のモニタシステム。
5. 【請求項５】 前記サービスに参入しているモジュール
   からイベント及びこれに対応する処理内容を示す情報を
   受信し、これを前記イベントテーブルに登録する登録手
   段を更に備えることを特徴とする請求項４に記載のモニ
   タシステム。
6. 【請求項６】 前記検知手段は、前記要求手段に対する
   応答に基づいて、前記イベントテーブルに登録されたイ
   ベントが発生したか否かを検知することを特徴とする請
   求項５に記載のモニタシステム。
7. 【請求項７】 前記サービスシステムはクライアントサ
   ーバ型システムであり、前記登録手段は該サービスシス
   テムのサーバよりイベント及びこれに対応する処理内容
   を示す情報を受信し、これを前記イベントテーブルに登
   録することを特徴とする請求項５に記載のモニタシステ
   ム。
8. 【請求項８】 前記モニタモジュールより、前記イベン
   トテーブルに登録されたイベントに係る動作状況の要求
   を、前記サービスシステムに参入しているモジュールに
   対して所定の時間隔で要求する定期要求手段を更に備
   え、 前記検知手段は、前記定期要求手段に対する応答に基づ
   いて、前記イベントテーブルに登録されたイベントが発
   生したか否かを検知することを特徴とする請求項４に記
   載のモニタシステム。
9. 【請求項９】 前記モニタモジュールは、独立したサー
   バ・プログラムとして提供されることを特徴とする請求
   項１に記載のモニタシステム。
10. 【請求項１０】 前記サービスシステムに参入する各モ
    ジュールは被モニタモジュールを有し、該被モニタモジ
    ュールは、 前記要求手段において動作状況を要求すべきモジュール
    とその内容を前記モニタモジュールに対して指定する指
    定手段と、 前記処理手段における前記モニタモジュールよりの動作
    状況の通知を受信する受信手段と、 前記受信手段で受信した情報に基づいてユーザへの表示
    を行う表示手段とを備えることを特徴とする請求項６に
    記載のモニタシステム。
11. 【請求項１１】 前記被モニタモジュールは、前記要求
    手段による前記モニタモジュールからの要求に応答し
    て、該モニタモジュールに動作状況を通知する状況通知
    手段を更に備えることを特徴とする請求項１０に記載の
    モニタシステム。
12. 【請求項１２】 前記被モニタモジュールは、動作状況
    モニタの対象となるモジュールの組み込みモジュールと
    して提供されることを特徴とする請求項１０または１１
    に記載のモニタシステム。
13. 【請求項１３】 前記表示手段は、前記受信手段で受信
    した動作状況を、各モジュールを表す図形を色分けする
    ことにより表示することを特徴とする請求項１１に記載
    のモニタシステム。
14. 【請求項１４】 前記表示手段は、前記受信手段によっ
    て受信された各モジュールの動作状況に基づいて、当該
    サービスシステムの各モジュール間のコネクションの関
    係とコネクション間のデータ通信の状況を、各モジュー
    ル表す図形を結ぶ線とその太さで表示することを特徴と
    する請求項１３に記載のモニタシステム。
15. 【請求項１５】 前記各モジュールの動作状況と、モジ
    ュール間のコネクションのデータ通信の状況を、上記表
    示手段で表示されている図形や矢印を操作することによ
    って指定する操作手段を更に備えることを特徴とする請
    求項１４に記載のモニタシステム。
16. 【請求項１６】 前記被モニタモジュールが、前記モニ
    タモジュールにおける前記登録手段によって登録される
    べきイベントを通知するイベント通知手段を更に備える
    ことを特徴とする請求項１０に記載のモニタシステム。
17. 【請求項１７】 前記イベント通知手段は、前記モニタ
    モジュールに対して、イベントの発生する条件とイベン
    ト発生時に行われる処理およびイベントに付加されるべ
    き情報を指定することを特徴とする請求項１６に記載の
    モニタシステム。
18. 【請求項１８】 前記サービスシステムはサーバクライ
    アント型のシステムであり、前記イベント通知手段はサ
    ーバの被モニタモジュールに組み込まれることを特徴と
    する請求項１６に記載のモニタシステム。
19. 【請求項１９】 前記モニタモジュールが前記サービス
    システムに参入する各モジュールの組み込みモジュール
    として提供されることを特徴とする請求項６に記載のモ
    ニタシステム。
20. 【請求項２０】 前記サービスシステムにおける各モジ
    ュールのれぞれが前記イベント通知手段を備えることを
    特徴とする請求項１９に記載のモニタシステム。
21. 【請求項２１】 前記サービスシステムが、クライアン
    ト装置よりの指示に基づいてカメラを制御して映像を獲
    得し、該獲得した映像をクライアント装置へ送信する映
    像配信サービスであることを特徴とする請求項１乃至２
    ０の何れかに記載のモニタシステム。
22. 【請求項２２】 コンピュータ・ネットワーク上で所定
    のサービスを提供するサービスシステムにおいて、該サ
    ービスシステムに参入しているモジュールとは別個に設
    けられ、該モジュールと通信可能なモニタモジュールに
    よって該サービスシステムの動作状況をモニタする方法
    であって、 前記モニタモジュールより前記サービスシステムに参入
    しているモジュールに対して動作状況を要求する要求工
    程と、 前記要求工程による要求に対する応答を受信し、該応答
    に対応する処理を実行する処理工程とを備えることを特
    徴とするモニタシステムの制御方法。
23. 【請求項２３】 コンピュータ・ネットワーク上におい
    て所定のサービス提供するサービスシステムにおいて、
    該サービスシステムの動作状況をモニタする情報処理装
    置であって、 前記サービスシステムに参入しているモジュールとは別
    個に設けられ、該モジュールと通信可能なモニタモジュ
    ールと、 前記モニタモジュールより前記サービスシステムに参入
    しているモジュールに対して動作状況を要求する要求手
    段と、 前記モニタモジュールによって前記要求手段による要求
    に対する応答を受信し、該応答に対応する処理を実行す
    る処理手段とを備えることを特徴とする情報処理装置。
24. 【請求項２４】 前記モニタモジュールによって要求情
    報を受信する受信手段と、概要求情報は、モジュールを
    指定するとともにその動作状態の通知を要求するもので
    あり、 前記要求手段は前記要求情報で指定されたモジュールに
    動作状況を要求することを特徴とする請求項２３に記載
    の情報処理装置。
25. 【請求項２５】 前記処理手段は、前記要求手段に対す
    る応答を受信し、該応答に基づいて前記要求情報の発行
    元のモジュールへ通知を行うことを特徴とする請求項２
    ４に記載の情報処理装置。
26. 【請求項２６】 コンピュータ・ネットワーク上のサー
    ビスシステムによって提供されるサービスを享受する情
    報処理装置であって、 該サービスシステムの動作状況をモニタするモニタモジ
    ュールとの通信を行う被モニタモジュールと、 前記被モニタモジュールによって、動作状況を要求すべ
    きモジュールとその内容を前記モニタモジュールに対し
    て指定する指定手段と、 前記モニタモジュールよりの動作状況の通知を受信する
    受信手段と、 前記受信手段で受信した情報に基づいてユーザへの表示
    を行う表示手段とを備えることを特徴とする情報処理装
    置。
27. 【請求項２７】 コンピュータ・ネットワーク上におい
    て所定のサービス提供するサービスシステムにおいて、
    該サービスシステムに参入するモジュールとは独立して
    機能するモニタモジュールプログラムを格納するコンピ
    ュータ可読メモリであって、該モニタモジュールプログ
    ラムは、コンピュータを前記サービスシステムに参入し
    ているモジュールに対して動作状況を要求する要求手段
    と、 前記モニタモジュールによって前記要求手段による要求
    に対する応答を受信し、該応答に対応する処理を実行す
    る処理手段として機能させることを特徴とするコンピュ
    ータ可読メモリ。
28. 【請求項２８】 コンピュータ・ネットワーク上におい
    て所定のサービス提供するサービスシステムにおいて、
    該サービスシステムに参入するモジュールとは独立して
    機能する被モニタモジュールプログラムを格納するコン
    ピュータ可読メモリであって、該被モニタモジュールプ
    ログラムは、コンピュータを該サービスシステムの動作
    状況をモニタするモニタモジュールとの通信を行う通信
    手段と、 前記通信手段によって、動作状況を要求すべきモジュー
    ルとその内容を前記モニタモジュールに対して指定する
    指定手段と、 前記通信手段により前記モニタモジュールよりの動作状
    況の通知を受信する受信手段と、 前記受信手段で受信した情報に基づいてユーザへの表示
    を行う表示手段として機能させることを特徴とするコン
    ピュータ可読メモリ。