JPH11212831A - オブジェクト間協調動作のログ管理およびイベント追跡のための方式および方法 - Google Patents

Abstract

(57)【要約】 【課題】 ネットワーク上に散在する複数のオブジェク
ト間の協調動作に関するログ回収やイベント追跡を容易
にする。 【解決手段】 各ノード２２０にイベントトラッカ２６
０が配置される。各イベントトラッカ２６０は、自ノー
ド内の全てのオブジェクトの行ったイベントのログを、
各オブジェクト別にログファイルに記録する。各イベン
トログには、書き込み時刻と、オブジェクト名と、トラ
ンザクションＩＤと、そのオブジェクトがトランザクシ
ョンの起点から数えて何番目の中継点であるかを示す中
継点カウンタと、イベント種別とが含まれている。イベ
ントトラッカ２６０はまた、必要に応じ、トランザクシ
ョンＩＤを頼りに自ノード内のログファイルから検索し
且つ他のノードのイベントトラッカに検索を依頼するこ
とによって、特定のトランザクションの全イベントのロ
グを収集する。そして、イベントトラッカ２６０は、収
集したイベントログのプロセス名と中継点カウンタとイ
ベント種別とにより、そのトランザクションの経過を解
明する。

Description

【発明の詳細な説明】

【０００１】

【発明の技術分野】本発明は、通信ネットワーク上に散
在する複数のオブジェクト間で非同期協調動作が行われ
る環境におけるログ管理およびイベント追跡のための方
式および方法に関する。

【０００２】

【従来の技術】ネットワーク上で複数のオブジェクトが
協調動作を行う環境において、従来は各マシン（ノー
ド）単位で個別に通信ログが取得されている。

【０００３】

【発明が解決しようとする課題】しかし、単純に各マシ
ン単位で通信ログを取得する従来技術においては、或る
マシン上の通信ログを頼りに、協調動作を行った他の全
てのマシンのログを探し出して回収することが困難であ
る。そのため、特に不特定多数のオブジェクト間で非同
期協調動作が行われる一層高度な分散環境においては、
トランザクションのイベントを追跡して障害解析やデバ
ッグを行うことが難しい。

【０００４】従って、本発明の目的は、オブジェクト間
の協調動作に関するログ回収やイベント追跡を容易にす
ることにある。

【０００５】

【課題を解決するための手段】本発明の第１の側面に従
うオブジェクト間協調動作のログ管理方式は、複数のノ
ードを有する通信ネットワークと、複数のノードに分散
して配置された複数のオブジェクトと、各ノードに配置
されたログファイルと、各ノードに配置され、各ノード
内のオブジェクトが実行したイベントのイベントログを
ログファイルに記録するログライタとを備える。複数の
オブジェクトは、相互間で協調動作を依頼しながら１つ
のトランザクションを連携して処理することができる。
各オブジェクトは、他のオブジェクトに協調動作を依頼
するとき、トランザクションを識別するためのトランザ
クションＩＤと、そのトランザクションの処理経路にお
ける各オブジェクトの位置を示すカウンタ情報とを他の
オブジェクトに伝える。また、ログライタが記録した各
イベントログには、対応するイベントに関わるトランザ
クションＩＤと、対応するイベントを実行したオブジェ
クトのプロセス名及びカウンタ情報と、対応するイベン
トの種別とが含まれている。

【０００６】このログ管理方式によれば、１つのトラン
ザクションのイベントログは複数のノードのログファイ
ルに分散して記録される。しかし、それらのイベントロ
グにはトランザクションＩＤが含まれているため、この
トランザクションＩＤを頼りに、特定のトランザクショ
ンのイベントログを検索することが可能である。そし
て、検索したログに含まれているプロセス名、カウンタ
情報及びイベント種別に基づいて、そのトランザクショ
ンのイベントの相互関係が把握できるので、トランザク
ションの経過を解明することが可能である。

【０００７】本発明の第２の側面に従うオブジェクト間
協調動作のイベント追跡方式は、複数のノードを有する
通信ネットワークと、複数のノードに分散して配置され
た複数のオブジェクトと、各ノードに配置され、各ノー
ド内のオブジェクトが実行したイベントのイベントログ
が格納されているログファイルと、少なくとも１つのノ
ードに配置され、指定されたトランザクションのイベン
トを追跡するイベントトラッカとを備える。複数のオブ
ジェクトは、相互間で協調動作を依頼しながら１つのト
ランザクションを連携して処理することができる。各オ
ブジェクトは、他のオブジェクトに協調動作を依頼する
とき、トランザクションＩＤと、そのトランザクション
の処理経路における各オブジェクトの位置を示すカウン
タ情報とを、他のオブジェクトに伝える。ログファイル
内の各イベントログには、対応するイベントに関わるト
ランザクションＩＤと、対応するイベントを実行したオ
ブジェクトのプロセス名及びカウンタ情報と、対応する
イベントの種別とが含まれる。各イベントトラッカはロ
グコレクタを有しており、このログコレクタは複数のノ
ード内のログファイルから、指定されたトランザクショ
ンＩＤをもったイベントログを収集することができる。

【０００８】このイベント追跡方式によれば、イベント
トラッカは、トランザクションＩＤを頼りに特定のトラ
ンザクションのイベントログをネットワークから収集す
ることができる。そして、収集した検索したログに含ま
れているプロセス名、カウンタ情報及びイベント種別に
基づいて、イベントトラッカは、そのトランザクション
のイベントを追跡することができる。

【０００９】望ましくは、前記イベントトラッカは更に
ログアナライザを有することができる。このログアナラ
イザは、収集されたイベントログに含まれるプロセス
名、カウンタ情報、及びイベント種別に基づいて、トラ
ンザクションの経過を解明してユーザに提示する。

【００１０】前記イベントトラッカは、ネットワーク上
の全てのノードに配置してもよい。また、このイベント
トラッカには、各ノード内のオブジェクトが実行したイ
ベントのイベントログをログファイルに記録するログラ
イタも含ませることができる。

【００１１】望ましくは、各イベントトラッカのために
イベントログの収集を代行するログコレクションエージ
ェントを、各物理ネットワーク毎に設けることができ
る。このログコレクションエージェントは、イベントト
ラッカからログ収集依頼を受けると、同じ物理ネットワ
ーク内の全てのノード内のログファイルから、指定され
たトランザクションＩＤをもったイベントログを収集
し、更に、他の物理ネットワーク内の別のログコレクシ
ョンエージェントへもログ収集依頼を送る。そして、こ
のログコレクションエージェントは、同じ物理ネットワ
ーク内の全てのノードから収集したイベントログと、別
のログコレクションエージェントに収集してもらった他
の物理ネットワーク上とを、依頼元のイベントトラッカ
に返送する。

【００１２】上述したログライタ、イベントトラッカ、
ログコレクタ、ログアナライザ、およびログコレクショ
ンエージェントは、典型的にはコンピュータがそれらの
プログラムを実行することによって実現される。それら
のプログラムは、各種のディスク型ストレージ、半導体
メモリ、通信ネットワークなどの様々な媒体を通じてコ
ンピュータにインストール又はロードすることができ
る。

【００１３】

【発明の実施の形態】本発明の通信ログ管理及びイベン
ト追跡方式の実施形態の説明に入る前に、この実施形態
を適用することが有用な、新規の２種類のネットワーク
環境について説明する。１つ目は新規なクライアント／
サーバ環境であり、２つ目は、新規なマルチキャストの
ためのネットワーク環境である。

【００１４】〔新規なクライアント／サーバ環境〕図１
は、このクライアント／サーバ環境の全体構成を示す。
この環境では、クライアントオブジェクトの知らない
（つまり、クライアントオブジェクトにとって不特定
の）１個以上のサーバオブジェクトが、そのクライアン
トオブジェクトと非同期で協調動作を行って或るトラン
ザクションを遂行することができるようになっている。
以下、詳細に説明する。

【００１５】ネットワーク上に、少なくとも１つのクラ
イアントオブジェクト（以下、単にクライアントとい
う）１と、「サービスエージェント」と呼ばれる１セッ
ト又は複数セットのオブジェクトセット３、７と、複数
のサーバオブジェクト（以下、単にサーバという）５
Ａ、５Ｂ、５Ｃ、…（これを纏めてサーバ群５ともい
う）、別の１群以上のサーバ群９などが散在している。
クライアント１は、原則として１つの特定のサービスエ
ージェント３の傘下におかれている。サーバ群５も、原
則として１つの特定のサービスエージェント３の傘下に
おかれ、同様に、別のサーバ群９も、原則として１つの
別の特定のサービスエージェント７に傘下におかれてい
る。ネットワークにおける各オブジェクトの場所は、ネ
ットワーク上のノードを示すノード名と、ノード内のオ
ブジェクト（プロセス）を示すプロセス名とにより特定
される。

【００１６】なお、図１では１つのクライアント１しか
図示してないが、実際には、多くの他のクライアントも
同じネットワーク上に存在しているのが普通である。し
かし、１つのクライアント１に関する説明は他のクライ
アントにも同様にあてはまるので、他のクライアントに
ついての図示および説明は省略する。

【００１７】サービスエージェント３は、傘下の各サー
バ５Ａ、５Ｂ、５Ｃ、…のサービス名、場所及びステー
タスを知ってそれを管理している。別のサービスエージ
ェント７も、傘下のサーバ群９に属する各サーバのサー
ビス名、場所及びステータスを同様に管理している。一
方、クライアント１は、ネットワーク上に散在するサー
バ５Ａ、５Ｂ、５Ｃ、…、９の個数、場所（ノード名、
プロセス名）、ステータス（アイドル、処理中、故障な
どの現在状態）及び提供するサービス名ついて全く関知
しない。

【００１８】各オブジェクトの動作の概要は次の通りで
ある。

【００１９】各サーバ５Ａ、５Ｂ、５Ｃ、…は、自己を
傘下におさめるサービスエージェント３に対し、サービ
ス開始時に自己のサービス名及び場所（ノード名とプロ
セス名）を知らせる（通信Ｃ１）。サービスエージェン
ト３は、各サーバ５Ａ、５Ｂ、５Ｃ、…から通知された
サービス名及び場所を記憶し、また、各サーバ５Ａ、５
Ｂ、５Ｃ、…のステータスも以後監視する。同様に、別
のサーバ群９に属する各サーバもサービスエージェント
７に自己のサービス名及び場所を通知し（通信Ｃ２）、
それをサービスエージェント７が同様に管理する。

【００２０】クライアント１は、サービス名を指定した
サービス要求をサービスエージェント３に送る（通信Ｃ
３）。サービスエージェント３は、サービス要求に応じ
られるサーバをサーバ群５内から探し、そのサーバ（例
えばサーバ５Ｂとする）にサービス要求を送る（通信Ｃ
４）。サーバ５Ｂは、要求されたサービスの処理を実行
し、その処理結果をサービスエージェント３に返送する
（通信Ｃ５）。サービスエージェント３は、その処理結
果をクライアント１に送る（通信Ｃ６）。なお、この通
信Ｃ６では、サービスエージェント３は、予めクライア
ント１から教えられているコールバック（ＣＢ）を用い
てクライアント１を呼んで処理結果を渡す。

【００２１】ところで、サービスエージェント３は、ク
ライアント１からのサービス要求に応じられるサーバが
サーバ群５内に無い場合、その旨をクライアント１に通
知することもできるが、その代わりに、別のサービスエ
ージェント７にサーバを照会することもできる（通信Ｃ
７）。別のサービスエージェント７は、傘下のサーバ群
９から要求に応じられるサーバを探し、そのサーバの場
所をサービスエージェント３に通知する（通信Ｃ８）。
サービスエージェント３は、その通知されたサーバにサ
ービス要求を送り（通信Ｃ９）、その結果を受信し（通
信Ｃ１０）、それをクラアント１に送る（通信Ｃ６）。

【００２２】以上のように、サービスエージェント３が
クライアント１とサーバ５Ａ、５Ｂ、５Ｃ、…間の通信
を仲介することにより、クライアント１は、サーバとの
通信に必要な情報（例えばサーバの個数や場所など）に
関知することなしに、所望のサービス名を指定するだけ
でそのサービスの提供を受けることができる。つまり、
クライアント１はサーバとの通信という問題から解放さ
れるのである。このことにより、クライアント１のプロ
グラム構築は、サーバの事情を考慮せずにすむため、非
常に容易になる。

【００２３】また、サービスエージェント３は、通信Ｃ
６でクライアント１に処理結果を返すとき、所定のＣＢ
を用いてクライアント１を呼び出す。そのためクライア
ント１は、要求を送る通信Ｃ３から結果を受ける通信Ｃ
６までの間ずっと待っている必要はなく、通信Ｃ３が終
わり次第別の処理に移行することができる。つまり、オ
ブジェクト間の非同期協調動作が可能である。

【００２４】図２は、サービスエージェント３の構成と
働きをより詳細に示している。

【００２５】サービスエージェント３は、サービスエー
ジェントのデーモンプロセスとして提供されるサービス
マネージャ３１と、サービスマネージャ３１内に唯一存
在するサービステーブル３３と、クライアント１及びサ
ーバ５Ａ、５Ｂ、…の各々に組み込まれ又は付属したサ
ービス・アプリケーションインタフェース（サービスＡ
ＰＩ）３５、３７Ａ、３７Ｂ、３７Ｃ、…とを含む。サ
ービスマネージャ３１は、サービスＡＰＩ３５、３７
Ａ、３７Ｂ、…が知っている特定場所のノードにおかれ
る。各サービスＡＰＩ３５、３７Ａ、３７Ｂ、…は、当
然、それぞれが組み込まれ又は付属したクライアント１
及びサーバ５Ａ、５Ｂ、５Ｃ、…と同じノードにおかれ
る。

【００２６】サービスマネージャ３１の主たる機能は、
傘下の全てのサーバ５Ａ、５Ｂ、…のサービス名、ノー
ド名、プロセス名及びステータス（以下、これらを総称
してサービス情報という）をサービステーブル３３上で
管理し、クライアント１からのサービス要求を受ける
と、サービステーブル３３を参照して傘下のサーバ群５
内から、そのサービス要求に応えられるサーバを傘下の
サーバ群５から探すことである。

【００２７】各サービスＡＰＩ３５、３７Ａ、３７Ｂ、
…の主たる機能は、対応するクライアント１及びサーバ
５Ａ、５Ｂ、５Ｃ、…のために、サービスマネージャ３
１との通信や他のサーバ又はクライアントとの通信を代
行することである。

【００２８】図３及び図４は、図２に示した各オブジェ
クトの動作の流れを示す。また、図５は、サービステー
ブル３１の内容例を示す。以下、図２〜図５を参照し
て、各部の動作を説明する。

【００２９】各サーバ５Ａ、５Ｂ、…は、各々の起動時
などに、各々のサービスＡＰＩ３７Ａ、３７Ｂ、…に対
しサービス提供宣言を送る（通信Ｃ２１）。このサービ
ス提供宣言には、それぞれのサーバのサービス処理を識
別するためのサービス名と、所定の提供ＣＢの指定とが
含まれる。ここで、提供ＣＢとは、各サーバ５Ａ、５
Ｂ、…内のサービス処理の実行主体であり、これを呼ぶ
ことにより、各サーバ５Ａ、５Ｂ、…にサービス処理を
実行させることができる。サービス提供宣言が各サービ
スＡＰＩ３７Ａ、３７Ｂ、…に受け付けられると、その
旨の確認応答が各サーバ５Ａ、５Ｂ、…に返される。

【００３０】各サービスＡＰＩ３７Ａ、３７Ｂ、…は、
各サーバ５Ａ、５Ｂ、…からの上記サービス提供宣言に
応答して、サービスマネージャ３１に対し、各サーバの
サービス名、ノード名およびプロセス名を含んだサービ
ス提供宣言を送る（通信Ｃ２２）。

【００３１】サービスマネージャ３１は、各サービスＡ
ＰＩ３７Ａ、３７Ｂ、…からサービス提供宣言を受ける
と、サービステーブル３３に、宣言に含まれているサー
ビス名、ノード名およびプロセス名を登録する（ステッ
プＳ１）。この登録時、サービスマネージャ３１は、サ
ーバの状態を示すテーブル３３上のステータスを「アイ
ドル」に設定する。従って、サービステーブル３３に
は、図５に例示するように、既に起動した全てのサーバ
５Ａ、５Ｂ、…のサービス名、ノード名、プロセス名お
よびステータスが記録されることになる。

【００３２】クライアント１は、自己のサービスＡＰＩ
３５に対しサービス要求を送る（通信Ｃ２３）。このサ
ービス要求には、要求するサービスを識別するためのサ
ービス名と、所定の応答ＣＢの指定とが含まれる。ここ
で、応答ＣＢとは、クライアント１内のサービス処理結
果を受信する主体であり、これを呼ぶことによりクライ
アント１にサービス処理結果を受け取らせることができ
る。サービス要求がサービスＡＰＩ３５に受け付けられ
ると、その旨の確認応答がサービスＡＰＩ３５からクラ
イアント１に返される。この確認応答を受けた後は、サ
ービス処理の結果が来ればサービスＡＰＩ３５が応答Ｃ
Ｂを呼んでくれるので、クライアント１はサービス処理
の結果を待つことなく、別の処理に移行することができ
る。

【００３３】サービスＡＰＩ３５は、クライアント１か
らサービス要求を受けると、サービス名をキーとして、
サービス情報の照会をサービスマネージャ３１に対して
行う（通信Ｃ２４）。

【００３４】サービスマネージャ３１は、サービステー
ブル３３を参照して、そのサービス名を現在提供するこ
とができるサーバを探す（ステップＳ２）。具体的に
は、テーブル３３上のサービス名が照会にかかるサービ
ス名と一致し、かつ、テーブル３３上のステータスが
「アイドル」であるサーバを探す。この条件を満たすサ
ーバが見つかれば、サービスマネージャ３１は、そのサ
ーバの場所を示すノード名とプロセス名をテーブル３３
から読み出し、照会元のサービスＡＰＩ３５に返送する
（通信２５）。

【００３５】サービスＡＰＩ３５は、サービスマネージ
ャ３１から受け取ったノード名とプロセス名とを宛先に
して（例えば、サーバ３Ａとする）、クライアント１の
要求したサービス名を含んだサービス要求を送信する
（通信Ｃ２６）。

【００３６】サーバ３ＡのサービスＡＰＩ３７Ａは、サ
ービス要求を受信すると、予めサーバ３Ａから指定され
ている提供ＣＢを呼ぶ（通信Ｃ２７）。これにより、サ
ーバ３Ａのサービス処理が開始される。サービス処理が
開始されると、サービスＡＰＩ３７Ａは、ステータスを
「処理中」に変更する旨のステータス変更通知をサービ
スマネージャ３１に送る（通信Ｃ２８）。このステータ
ス変更通知には、サーバ３Ａのノード名及びプロセス名
が含まれている。サービスマネージャ３１は、そのステ
ータス変更通知を受けると、そのノード名及びプロセス
名に該当するサービステーブル３３上のステータスを
「アイドル」から「処理中」に変更する（ステップＳ
３）。

【００３７】サービス処理が終わって提供ＣＢが終了す
ると、サーバ３Ａは提供ＣＢの終了宣言をサービスＡＰ
Ｉ３７Ａに送る（通信Ｃ２９）。この終了宣言には、実
行したサービス処理の結果（例えば、データベース検索
を行った場合の検索結果など）が含まれている。

【００３８】サービスＡＰＩ３７Ａは、提供ＣＢ終了宣
言を受けると、ステータスを「アイドル」に変更する旨
のステータス変更通知をサービスマネージャ３１に送る
（通信Ｃ３０）。サービスマネージャ３１は、その通知
を受けて、サービステーブル３３上の該当するステータ
スを「処理中」から「アイドル」に変更する（ステップ
Ｓ４）。

【００３９】提供ＣＢ終了宣言を受けたサービスＡＰＩ
３７Ａは、さらに、サービス処理結果をサービス要求元
のクライアント１に宛てて返送する（通信Ｃ３１）。ク
ライアント１のサービスＡＰＩ３５は、そのサービス処
理結果を受信すると、応答ＣＢを呼ぶ（通信Ｃ３２）。
これにより、クライアント１は、サービス処理結果を受
け取る。

【００４０】ところで、サービスマネージャ３１は、ク
ライアント１のサービスＡＰＩ３５からサービス情報照
会を受けたとき（通信Ｃ２４）、条件を満たすサーバが
サービステーブル３３から見つからなかった場合、図２
に示すように、別のサービスエージェントのサービスマ
ネージャに対して、同内容のサービス情報照会を送るこ
とができる（通信Ｃ３３）。すると、その別のサービス
マネージャは、自己のサービステーブルから条件を満た
すサーバを探して、そのノード名とプロセス名を照会元
のサービスマネージャ３１に返送する（通信Ｃ３４）。
サービスマネージャ３１は、そのノード名とプロセス名
とをクライアント１のサービスＡＰＩ３５に送り（通信
２５）、サービスＡＰＩ３５はそのノード名とプロセス
名を宛先にしてサービス要求を発し（通信Ｃ３５）、そ
してその結果を受けることができる（通信Ｃ３６）。

【００４１】以上のような具体的な構成及び動作によ
り、図１を参照して既に説明した通りの、クライアント
１はサーバを意識する必要が無い、オブジェクト間の非
同期協調動作が可能である、という利点が得られる。

【００４２】図６は、オブジェクト間非同期協調動作が
可能であることによって得られる一つの具体的な利点の
例を示している。

【００４３】例えば、次のようなケースを想定する。す
なわち、クライアント１は、特定の計算をなるべく速く
行うことを欲している。その特定の計算を行う方法には
アルゴリズムＡとＢの２種類があり、いずれの方法がよ
り速いかは、入力データの値に依存する。アルゴリズム
Ａ又はＢを実装したサーバ５Ａ、５Ｂ、５Ｃ、…がネッ
トワーク上に散在しており、それぞれのアルゴリズムに
ついて図示のように多重にサーバが存在している。

【００４４】このようなケースでは、クライアント１は
サービスエージェント３に対し、「アルゴリズムＡによ
る計算要求」と「アルゴリズムＢによる計算要求」とい
う２つのサービス要求をたて続けに発することができる
（通信Ｃ４１、Ｃ４２）。非同期処理が可能であるか
ら、一方の計算が完了する前に、他方の計算要求を発す
ることができるからである。

【００４５】すると、サービスエージェント３は、即座
に、アルゴリズムＡ、Ｂの各々についてステータスがア
イドルのサーバ（例えば、サーバ５Ａとサーバ５Ｃとす
る）を見つけ、それらに対し、その特定の計算を依頼す
る（通信Ｃ４３、Ｃ４４）。サーバ５Ａとサーバ５Ｃは
アルゴリズムＡとＢでそれぞれ計算を行い、いずれか早
く計算を完了した方（例えばサーバ５Ａ）が先に、計算
結果を返す（通信Ｃ４５）。従って、クライアント１
は、労せずして、速いほうの計算結果を受け取ることが
できる（通信Ｃ４６）。

【００４６】なお、上記説明では、個々のクライアント
および個々のサーバは、１つのサービスエージェントの
傘下におかれており、その１つのサービスエージェント
とのみ通信している。しかし、必ずしもそうである必要
はなく、或るクライアント又は或るサーバが、２つ以上
のサービスエージェントの傘下におかれていてもよい。
その場合、そのクライアントのサービスＡＰＩ又はその
サーバのサービスＡＰＩは、自分が傘下にある２つ以上
のサービスエージェントのサービスマネージャの場所を
知っている必要がある。こうすることにより、サービス
マネージャの負荷分散を図ることが可能である。また、
例えば、或るサービスエージェントは或る特定種類のサ
ービスを提供するサーバ群を傘下におさめ、別のサービ
スエージェントはまた別の特定種類のサービスを提供す
るサーバ群を傘下におさめているような場合、双方のサ
ービスを受けたい１つのクライアントが、その２つのサ
ービスエージェントの傘下に入って、ほしいサービスに
応じてサービスエージェントを使い分けるといった構成
も可能である。

【００４７】ところで、上記説明では、クライアントや
サーバのサービスＡＰＩを、サービスエージェントの一
部という位置づけで説明したが、これは一つの説明の方
法又は概念化の方法に過ぎないものであって、別の説明
も可能であることに注意されたい。すなわち、例えば、
各クライアントや各サーバのサービスＡＰＩを、サービ
スエージェントの一部ではなく、各クライアントや各サ
ーバの一部という位置づけで理解することもできるし、
或いは、サービスエージェント、クライアント及びサー
バのいずれにも属さない独立したオブジェクトとして理
解することも可能である。

【００４８】〔新規なマルチキャスト環境〕図７は、こ
のマルチキャスト環境の全体構成を示す。この環境で
は、メッセージの送信元のオブジェクトが指定する特定
のドメインに参加してはいるが、送信元オブジェクトが
具体的に知ってはいない（つまり、送信元オブジェクト
にとって不特定の）複数のオブジェクトにたいして、メ
ッセージをマルチキャストできるよになっている。以
下、詳細に説明する。

【００４９】図７に示すように、或る通信ネットワーク
１００が、ルータ１３０−１、１３０−２、…などによ
って相互接続された多数の物理的なネットワークセグメ
ントの集合体として構成されている。この通信ネットワ
ーク１００上に、１以上の論理ネットワーク１１０−
１、１１０−２、…が定義されている。各論理ネットワ
ーク１１０−１、１１０−２、…には、通常、多数のノ
ード（＝ホスト）１２０−１、１２０−２、…が含まれ
ている。

【００５０】ノード１２０−１、１２０−２、…の各々
は、１つ又はそれ以上の数のアプリケーション（ＡＰ）
オブジェクト（＝プロセス）１４０−１、１４０−２、
…を有している（図７では、ノード１２０−１以外の他
のノード内のＡＰオブジェクトの図示は省略してあ
る）。ＡＰオブジェクト１４０−１、１４０−２、…
は、それぞれ特定の業務に関わる処理を行うが、業務の
種類又は内容に応じて予め定義された幾つかの業務グル
ープのいずれかに参加している。例えば、ＡＰオブジェ
クト１４０−１は特定のデータベースの検索を行う業務
グループに参加し、別のＡＰオブジェクト１４０−２は
計算を行う業務グループに参加する、などというように
である。個々の業務グループはドメインと呼ばれる。な
お、本実施形態では業務の種類又は内容に応じてドメイ
ンを定義しているが、これは説明上の一例に過ぎない。
別の観点（例えばコストの観点、管理形態の観点、処理
速度の観点など）からドメインを定義しても勿論構わな
い。

【００５１】図８は、このシステムの論理的な構成を示
している。図中の菱形と黒ドットとを線で結んだシンボ
ルは、菱形マーク側の要素１個に黒ドットマーク側の要
素がＮ個（１つ以上）所属しているという「１対Ｎ」の
所属関係を表している。

【００５２】論理ネットワーク１１０は、物理ネットワ
ークに設置されている多数のノード１２０の集合体であ
る。この論理ネットワーク１１０は、論理的に定義され
たものであり、物理的なセグメント構成やＬＡＮ／ＷＡ
Ｎなどの定義とは無関係である。１つのノード１２０内
では１つ以上のＡＰオブジェクト１４０が動作する。従
って、各ＡＰオブジェクト１４０は、１つのネットワー
ク１１０と１つのノード１２０とに所属する。また、１
つのドメイン１７０には、１つ以上のＡＰオブジェクト
１４０が参加している。但し、各ＡＰオブジェクト１４
０は、必ずしもドメイン１７０に参加する必要はない。
つまり、何のドメインにも属さないＡＰオブジェクト１
４０が存在してもよい。

【００５３】再び図７を参照する。各論理ネットワーク
１１０−１、１１０−２、…では、所定の１つのノード
に、ネットワークアクタ（ＮＷＡ）と呼ばれるデーモン
プロセスが配置される。例えば、論理ネットワーク１１
０−１では、ノード１２０−２にネットワークアクタ１
５０−１が配置され、論理ネットワーク１１０−２で
は、ノード１２０−６にネットワークアクタ１５０−２
が配置されている。このネットワークアクタ１５０−
１、１５０−２、…は、それぞれの論理ネットワーク１
１０−１、１１０−２、…における全体のメッセージ配
信制御を行うものである。

【００５４】また、個々のノード１２０−１、１２０−
２、…には、ノードアクタ（ＮＤＡ）と呼ばれるデーモ
ンプロセス１６０−１、１６０−２、…が１つづつ配置
されている。このノードアクタ１６０−１、１６０−
２、…は、それぞれのノード１２０−１、１２０−２、
…内でのメッセージ配信制御を行うものである。

【００５５】図９は、ネットワークアクタ１５０とノー
ドアクタ１６０の機能を具体的に示している。

【００５６】特定のドメインに参加しているＡＰオブジ
ェクト群へメッセージをマルチキャストしたいＡＰオブ
ジェクト１４０は、自分の所属する論理ネットワーク上
のネットワークアクタ１５０に配信の都度テンポラリな
パス１８１を張って、そのメッセージを送出する。送出
後、パス１８１は直ちに切断される。

【００５７】ネットワークアクタ１５０とそれが所属す
る論理ネットワーク１１０上の個々のノードアクタ１６
０との間には、そのノードアクタ１６０の起動（典型的
にはマシンブート）タイミングで、配信パス１８３が張
られる。そして、そのノードアクタ１６０の終了（典型
的にはマシンのシャットダウン）タイミングで、それぞ
れの配信パス１８３は切断される。そのノードアクタ１
６０の動作中、その配信パス１８３は張られたままであ
る。

【００５８】ネットワークアクタ１５０は、それが所属
する論理ネットワーク１１０上の稼動中のノード１２０
を管理するためのノードアクタテーブル１５１を、その
ネットワークアクタ１５０のメモリ上に有している。こ
のノードアクタテーブル１５１には、図１０に例示する
ように、その論理ネットワーク１１０上の全ての稼動中
のノード１２０のノード名と、そのノード１２０への配
信パス１８３の識別番号（配信パスＩＤ、例えばファイ
ルディスクリプタ）とが登録されている。個々のノード
アクタ１５１が起動した時に、そのノードアクタ１６０
が自分のノード名と配信パスとを示した起動通知をネッ
トワークアクタ１５０へ送り、この起動通知に基づい
て、ネットワークアクタ１５０が、その起動したノード
アクタ１６０のノード名と配信パスＩＤとをノードアク
タテーブル１５１に登録することができる。

【００５９】特定ドメインへマルチキャストされるべき
メッセージをＡＰオブジェクト１４０から受けたネット
ワークアクタ１５０は、ノードアクタテーブル１５１を
参照して、その論理ネットワーク１１０上で稼働中の全
てのノードアクタ１６０に対して、そのメッセージを配
信する。

【００６０】ノードアクタ１６０と、同じノード内の個
々のＡＰオブジェクト１４０との間には、そのＡＰオブ
ジェクト１４０の起動タイミングで配信パス１８５が張
られる。そして、そのＡＰオブジェクト１４０の終了タ
イミングで、その配信パス１８５は切断される。そのＡ
Ｐオブジェクト１４０の動作中、その配信パス１８５は
張られたままである。

【００６１】ノードアクタ１６０は、それと同じノード
上の稼働中のＡＰオブジェクト１４０を管理するための
ＡＰオブジェクト管理テーブル１６１及びドメインテー
ブル１６３を有している。ＡＰオブジェクトテーブル１
６１には、図１１に例示するように、そのノード内で稼
働中の全てのＡＰオブジェクト１４０のオブジェクト名
と、その稼働中のＡＰオブジェクト１４０への配信パス
１８５の配信パスＩＤとが登録されている。ドメインテ
ーブル１６３には、図１２に例示するように、その稼働
中の全てのＡＰオブジェクト１４０のオブジェクト名
と、その稼働中のＡＰオブジェクト１４０が参加してい
るドメインの名称（ドメイン名）とが登録されている。
個々のＡＰオブジェクト１４０が起動した時に、そのＡ
Ｐオブジェクト１４０が自分のオブジェクト名と配信パ
スとドメイン名とを示した起動通知をノードアクタ１６
０へ送り、この起動通知に基づいて、ノードアクタ１６
０が、その起動したＡＰオブジェクト１４０のオブジェ
クト名と配信パスＩＤとをＡＰアプリケーションテーブ
ル１６１とドメインテーブル１６３とに登録することが
できる。

【００６２】特定のドメインへマルチキャストされるべ
きメッセージをネットワークアクタ１５０から受けたノ
ードアクタ１６０は、ＡＰオブジェクトテーブル１６１
とドメインテーブル１６３とを参照して、指定されたド
メインに参加している稼働中のＡＰオブジェクト１４０
に対してのみ、そのメッセージを配信する。

【００６３】図１３は、ＡＰオブジェクト１４０から送
出されるメッセージのフォーマットを示している。

【００６４】メッセージ１９０のパケットには、通信制
御のための情報を表すヘッダ１９１と、メッセージの正
味の内容であるユーザデータ１９３とが含まれている。
ヘッダ１９０には、送信元のＡＰオブジェクト１４０を
示すオブジェクト名、ネットワーク名、ノード名及びド
メイン名と、送信先のＡＰオブジェクト名１４０を示す
いオブジェクト名、ネットワーク名、ノード名及びドメ
イン名とが含まれている。

【００６５】特定のドメインに参加しているＡＰオブジ
ェクト群にメッセージをマルチキャストしたいＡＰオブ
ジェクト１４０は、その特定のドメインの名称を、メッ
セージ１９０のヘッダ１９１の送信先ドメイン名にセッ
トする。このとき、ヘッダ１９１の送信先オブジェクト
名や送信先ノード名には、何のデータもセットしない
（＝ＮＵＬＬデータをセットする）。このメッセージ
は、図１４に例示するようにしてマルチキャストされ
る。

【００６６】図１４の例は、ＡＰオブジェクト１４０−
１が、特定のドメインＤ１に参加しているＡＰオブジェ
クト群にメッセージをマルチキャストする場合を想定し
ている。図中の矢印はメッセージの流れを示している。
送信元のＡＰオブジェクト１４０−１は、自分の所属す
る論理ネットワーク上のネットワークアクタ１５０−１
にテンポラリパス１８１を張って、そのネットワークア
クタ１５０−１にメッセージを送信する。このメッセー
ジのヘッダ１９１には、送信先ドメイン名として「Ｄ
１」がセットされている。そのメッセージを受信したネ
ットワークアクタ１５０−１は、同じ論理ネットワーク
上で稼働中の全てのノードアクタ１６０−１、１６０―
２、１６０−３に、そのメッセージを配信する。そのメ
ッセージを受信した各ノードアクタ１６０−１、１６０
―２、１６０−３は、同じノード内の稼働中のＡＰオブ
ジェクトの中で、指定されたドメインＤ１に参加してい
るＡＰアプリケーション１４０−２、１４０−３、１４
０−６に対してのみ、そのメッセージをそれぞれ配信す
る。

【００６７】以上のようにして、特定のドメインに参加
しているＡＰオブジェクトに対してのみメッセージがマ
ルチキャストされる。その際、送信元のＡＰアプリケー
ション１４０−１は、１回だけメッセージを送信すれば
よい。論理ネットワーク上では、稼働中のノードに対し
てのみ、そのメッセージが送られる。ノード内では、稼
働中で且つ指定されたドメインに参加しているＡＰオブ
ジェクトに対してのみ、そのメッセージが送られる。こ
のマルチキャスト方式によれば、従来のＩＰブロードキ
ャストによる方法に比較して、トラヒックは少なくて済
み、且つ、そのメッセージが不要なＡＰオブジェクトに
余計な負担をかけることもない。さらに、論理ネットワ
ークが物理的なセグメント構成とは無関係に、ルータや
ゲートウェイを跨いで定義できるから、ルータやゲート
ウェイを跨いだメッセージ配信が可能である。また、従
来のユニキャストによる方法に比較して、ネットワーク
の構成やノードは一などの変更やＡＰオブジェクトの追
加、削除に対してより柔軟に対応でき、且つ、休止中の
ノードやオブジェクトに無駄な送信を行うこともない。

【００６８】上記では、送信元ＡＰオブジェクトが自分
の所属する論理ネットワーク上の特定ドメインのオブジ
ェクト群に対してマルチキャストする場合を説明した
が、他のパターンのキャストも可能である。

【００６９】例えば、メッセージヘッダ１９１において
送信先ネットワーク名は指定するが、送信先のオブジェ
クト名、ノード名及びドメイン名は指定しないことによ
り、論理ネットワーク内の全ての稼働中ＡＰオブジェク
トにメッセージを配信することができる。また、送信先
のネットワーク名とノード名は指定するが、送信先のオ
ブジェクト名及びドメイン名は指定しないことにより、
指定したノード内の全ての稼働中ＡＰオブジェクトにメ
ッセージを配信することができる。また、送信先のネッ
トワーク名とノード名とドメイン名は指定するが、送信
先のオブジェクト名は指定しないことにより、指定した
ノード内の指定したドメインに参加している稼働中ＡＰ
オブジェクトにのみメッセージを配信することができ
る。また、送信先のオブジェクト名とネットワーク名と
ノード名とを指定することにより、指定したノード内の
指定した１つのオブジェクトにのみメッセージをおくす
ることができる。さらに、別の論理ネットワーク上のネ
ットワークアクタの場所を知っているならば、その別の
論理ネットワーク上のAPオブジェクトに対しても、上記
のような種々のパターンでメッセージをキャストするこ
とができる。

【００７０】ところで、論理ネットワークはネットワー
クの物理的構成とは無関係に論理的に定義できるから、
或る論理ネットワークが他の論理ネットワークと一部の
領域で重なり合うように設定することもできる。する
と、その重なり領域に存在するＡＰオブジェクトは複数
の論理ネットワークに所属することになる。また、ドメ
インも自由に定義できるから、１つのＡＰオブジェクト
１４０が複数のドメイン１７０に参加する（例えば、計
算処理ドメインと高速処理ドメインの双方に参加する）
こともあり得る。このようなケースにおいても本発明は
問題無く適用することができる。

【００７１】また、例えば、１つの広域の論理ネットワ
ーク内に狭域の論理ネットワークを定義することもでき
る。その場合、それらのネットワークにそれぞれ１つづ
つネットワークアクタを配置し、広域のネットワークア
クタと狭域のネットワークアクタとの間に配信パスを張
り、広域のネットワークアクタが狭域のネットワークア
クタの配信パスIDを管理するというような、階層的なネ
ットワークアクタのシステムを採用することができる。

【００７２】〔本発明に従うログ管理及びイベント追跡
方式の実施形態〕以下に、上述のような環境に好適な本
発明に従う方式の一実施形態を説明する。なお、以下の
説明には、上記環境におけるこの方式の具体的動作につ
いての解説が含まれるが、それは例示に過ぎず、他の環
境であってもこの方式が十分に動作し相応の効果を発揮
し得る得ることを認識されたい。

【００７３】図１５にこの実施形態の全体を示す。

【００７４】図１５に示すように、通信ネットワーク２
００は、ルータ２３０−１、２３０−２、…などを介し
て相互接続された多数の物理的なネットワークセグメン
ト（以下、物理ネットワークという）２１０−１、２１
０−２、２１０−３、…に分けられる。それら物理ネッ
トワーク２１０−１、２１０−２、２１０−３、…の各
々では、所定の一つのノード（＝マシン）２２０−２、
２２０−６、２２０−４、…に、ログコレクションエー
ジェント（ＬＣＡ）と呼ばれるデーモンプロセスのオブ
ジェクト２５０−１、２５０−２、２５０−３、…が配
置されている。また、各ノード２２０−１、２２０−
２、…には、イベントトラッカ（ＥＴＲ）と呼ばれるオ
ブジェクト２６０−１、２６０−２、…が配置されてい
る。

【００７５】上述した環境では、各ノード２２０−１、
２２０−２、…には、例えばアプリケーション（ＡＰ）
オブジェクト（例えば、クライアント、サーバなど）ま
たはデーモンプロセスのオブジェクト（例えば、サービ
スマネージャ、ネットワークアクタ、ノードアクタな
ど）のような、種々のオブジェクト２４０−１、２４０
−２、…が含まれている。各イベントトラッカ（ＥＴ
Ｒ）２６０−１、２６０−２、…は、各々のノードに含
まれるそれらのオブジェクト２４０−１、２４０−２、
…の通信ログを取得して各オブジェクト別にその通信ロ
グを記録すること、および、或るトランザクションで通
信障害のような問題が発生した場合、そのトランザクシ
ョンに関係した全オブジェクトの通信ログを収集し分析
して、そのトランザクションを構成するイベントを追跡
することを行う。各ログコレクションエージェント（Ｌ
ＣＡ）２５０−１、２５０−２、２５０−３、…は、各
々の物理ネットワーク２１０−１、２１０−２、２１０
−３、…内の各イベントトラッカ（ＥＴＲ）２６０−
１、２６０−２、…のために、ネットワーク２００全体
からの必要な通信ログの収集を代行する。

【００７６】図１６は、この実施形態の説明で用いる重
要な幾つかの概念について説明している。図中、線で結
んだ黒丸と菱形のシンボルは、菱形側の１つの概念が黒
丸側のｎ個の概念から構成されるという「１対ｎ」の所
属関係を示しており、また、三角形のシンボルは、その
三角形の頂点側の１つの概念の具体例として、その三角
形の底辺側の複数の概念があるという「抽象−具体」の
関係を示している。

【００７７】図１６に示すように、１つのトランザクシ
ョン２７０は、複数のイベント２８０から構成される。
トランザクション２７０とは、オブジェクト間の協調動
作（この実施形態では非同期協調動作）の１単位であ
り、その具体例には、クライアントからサーバへサービ
スを要求しサーバがクライアントとにサービスを提供す
るという一連の処理である「サービス」２７１、および
一つのオブジェクトから複数のオブジェクトへ同じメッ
セージがキャストされる一連の処理である「マルチキャ
スト」２７３などがある。イベント２８０とは、トラン
ザクションの構成要素であり、その具体例には、「開
始」２８１、「依頼」２８３、および「受付」３８５な
どがある（その詳細は後に説明する）。

【００７８】図１７は、イベントトラッカ２６０とログ
コレクションエージェント２５０に関してより詳細に示
している。

【００７９】１つのイベントトラッカ２６０−１は、ロ
グコレクタ２６１、ログアナライザ２６３およびログラ
イタ２６５という３種類のオブジェクトを有している
（他の各イベントトラッカ２６０−２、２６０−３、…
も同様である）。ログライタ２６５は、そのノード内の
全てのオブジェクトのトランザクションに関わる動作を
監視して各イベントのログを取得し、そのイベントログ
をそのノードのストレージ２９０内の２種類のイベント
ログファイル２９１又は２９３のいずれかに記録する。
ログライタ２６５は、具体的には、各ＡＰオブジェクト
にリンクされたライブラリ内のモジュール（例えば、図
２に示すクライアント１やサーバ５のためのログを書く
モジュールは、そのクライアント１やサーバ５にリンク
されたサービスＡＰＩ３７内に設けられる）、及び各デ
ーモンプロセス内部のモジュール（例えば、図２に示し
たサービスマネージャ３１のログを書くモジュールは、
そのサービスマネージャ内部に設けられる）に分散して
実装され得る。２種類のイベントログファイル２９１又
は２９３の内の一方のイベントログファイル２９１は、
ＡＰオブジェクトのイベントログを記録するためのもの
であり、他方のイベントログファイル２９３はデーモン
プロセスのイベントログを記録するためのものである。
なお、図１７では、全てのノードに２種類のイベントロ
グファイル２９１、２９３が１つづつ存在するかのよう
に示されているが、必ずしもそうではない。例えば、Ａ
Ｐオブジェクトが存在しないノードにはＡＰ用イベント
ログファイル２９１は存在せず、また、複数のデーモン
プロセス（例えばノードアクタとネットワークアクタの
双方）が存在するノードにはそれらに対応する複数のデ
ーモンプロセス用イベントログファイル２９３が存在す
る。

【００８０】図１８および図１９はそれぞれ、ＡＰ用イ
ベントログファイル２９１とデーモンプロセス用イベン
トログファイル２９３の構成を示している。

【００８１】図１８に示すように、ＡＰ用イベントログ
ファイル２９１は、ノード名などが書かれたヘッダと、
そのノードで起動できるＡＰオブジェクト（例えば、Ａ
Ｐ１、ＡＰ２およびＡＰ３など）の最大個数分のＡＰ別
ログ領域２９５−１、２９５−２、…とを、各ＡＰ別ロ
グ領域２９５−１、２９５−２、…は、メモリマッピン
グの方法によってそのノード内の個々のＡＰオブジェク
トに割り当てられている。各ＡＰ別ログ領域２９５−
１、２９５−２、…には、割り当てられたＡＰオブジェ
クトのプロセス名などが書かれたヘッダと、ＡＰオブジ
ェクトのイベントログレコード２９７−１、２９７−
２、…を書き込むための一定サイズの領域とがある。こ
の一定サイズの領域にサイクリックに、新しいイベント
ログレコードが書き込まれていく。

【００８２】図１９に示すように、デーモンプロセス用
イベントログファイル２９３には、割り当てられた特定
のデーモンプロセス(例えば、ノードアクタ、ネットワ
ークアクタ又はサービスエージェント)のプロセス名な
どが書かれたヘッダと、そのデーモンプロセスのイベン
トログレコード２９７−４、２９７−３、…を書き込む
ための領域とがある。この一定サイズの領域にサイクリ
ックに、新しいイベントログレコードが書き込まれてい
く。

【００８３】図２０は、個々のイベントログレコード２
９７の構成を示す。

【００８４】イベントログレコード２９７は固定の長さ
を有し、そこには書き込み時刻、トランザクションＩ
Ｄ、中継点カウンタ、イベント種別などが記述される。
トランザクションＩＤとは、個々のトランザクションに
与えられるシステム内でユニークな識別番号である。中
継点カウンタとは、トランザクションの処理経路におい
て当該イベントを実行したオブジェクトが何番目のオブ
ジェクトであるか（つまり、そのオブジェクトの順位）
を示す数値である。マルチキャストのように複数のオブ
ジェクト（枝）に処理経路が分岐するトランザクション
では、その枝を識別するための枝番が中継点カウンタに
追加される（この場合、中継点カウンタ内のオブジェク
ト順位を数値を「幹番」とよぶ）。換言すれば、中継点
カウンタは、そのイベント又はそのイベントを実行した
オブジェクトの、トランザクション処理経路における位
置を示す情報である。

【００８５】イベント種別とは、図１６に示した「開
始」、「依頼」、「受付」などの具体的なイベント種類
を識別するコードである。イベント種別には例えば次の
ようなものがある。

【００８６】「ＳＴＲ」（start）：オブジェクト間の
協調の「開始」である。中継点カウンタは「０１」とな
る。

【００８７】「ＰＲＯ」（propose）：他のオブジェク
トに対する協調の「依頼」である。マルチキャストで
は、このイベントにおいて、中継点カウンタに枝番が追
加される。

【００８８】「ＡＣＣ」（accept）：他のオブジェクト
から依頼された協調を「受け付け」たことである。中継
点カウンタは「ＰＲＯ」に等しい。

【００８９】「ＸＣＧ」（exchange）：「変換」、つま
り依頼された処理を行うという意味である。中継点カウ
ンタはインクリメントされる。

【００９０】「ＤＩＳ」（discard）：協調の「放
棄」、つまり、そのオブジェクトはこの先更なる協調を
行なう必要が無い、または、依頼に対しての処理は行え
ないという意味である。

【００９１】「ＥＮＤ」（end）：協調の「終了」であ
る。

【００９２】図２１および図２２は、或るトランザクシ
ョンにおけるイベントの発生とイベントログの書き込み
の様子の具体例をそれぞれ示す。なお、これらの図及び
以下の説明では、オブジェクトは「ノード名．オブジェ
クト名」の形式で、イベントは「中継点カウンタ．イベ
ント種別」の形式で示す。また、枝番が追加された中継
点カウンタは「幹番．第１の枝番．第２の枝番．第３の
枝番」の形式で示す。図中の破線で囲いは、１つのトラ
ンザクションを意味する。

【００９３】図２１は、「サービス」のトランザクショ
ンの例を示しており、ここでは、クライアント「ＮＣ．
ＡＰ１」がサービスマネージャ「ＮＭ．ＳＭＧ」の仲介
でサーバ「ＮＳ．ＡＰ２」から或るサービスを提供され
る。この種のトランザクションの動作の詳細は、既に図
３および図４を参照して説明してある。なお、ログ処理
では、クライアントやサーバに付属するＡＰＩインタフ
ェースは、それぞれのクライアント及びサーバの一部で
あるとされる。

【００９４】最初に、クライアント「ＮＣ．ＡＰ１」に
おいて、開始イベント「０１．ＳＴＲ」が発生し、続い
て、サーバ照会のための依頼イベント「０１．ＰＲＯ」
が発生する。この２つのイベントのログレコードが、ノ
ード「ＮＣ」内のＡＰ用イベントログファイル２９１内
のクライアント「ＮＣ．ＡＰ１」に割り当てられた領域
に書き込まれる。

【００９５】サービスマネージャ「ＮＭ．ＳＭＧ」で
は、サーバ照会の依頼に対応した受付イベント「０１．
ＡＣＣ」が発生し、続いて、適当なサーバを探す変換イ
ベント「０２．ＸＣＧ」が発生し、ここで中継点カウン
タがインクレメントされる。続いて、サービスマネージ
ャ「ＮＭ．ＳＭＧ」では、クライアント「ＮＣ．ＡＰ
１」（正確には、このクライアントに付属するＡＰＩイ
ンタフェース）に照会結果を返答するための依頼イベン
ト「０２．ＰＲＯ」が発生する。これら３つのイベント
のログレコードが、ノード「ＮＭ」内のサービスマネー
ジャ用のイベントログファイル２９３に書き込まれる。

【００９６】クライアント「ＮＣ．ＡＰ１」では、照会
結果を受ける受付イベント「０２．ＡＣＣ」、サービス
要求を生成する変換イベント「０３．ＸＣＧ」（ここ
で、中継点カウンタがインクレメントされる）及びサー
バ「ＮＳ．ＡＰ２」へサービス要求を送る依頼イベント
「０３．ＰＲＯ」が発生する。これらのイベントのログ
レコードが、ノード「ＮＣ」内のＡＰ用イベントログフ
ァイル２９１に書き込まれる。

【００９７】以下、サーバ「ＮＳ．ＡＰ２」、サービス
マネージャ「ＮＭ．ＳＭＧ」及びクライアント「ＮＣ．
ＡＰ１」において、図３、４を参照して既に説明したよ
うな種々のイベントが発生し、それらイベントのログレ
コードが各ノード「ＮＳ」、「ＮＭ」、「ＮＣ」内のイ
ベントログファイルに書き込まれる。

【００９８】図２２は、「マルチキャスト」のトランザ
クションの例を示しており、ここでは、メッセージが１
つのＡＰオブジェクト「ＮＳ．ＡＰ１」から１つのネッ
トワークアクタ「ＮＮ．ＮＷＡ」へ送られ、そこから３
つのノードへ送られ、それらのノード内でノードアクタ
「Ｎ１．ＮＤＡ」、「Ｎ２．ＮＤＡ」、「Ｎ３．ＮＤ
Ａ」からＡＰオブジェクト「Ｎ１．ＡＰ２」、「Ｎ２．
ＡＰ３」、「Ｎ３．ＡＰ６」へ送られる。この種のトラ
ンザクションの処理の詳細は、既に図９から図１４を参
照して詳細に説明してある。

【００９９】まず、送信オブジェクト「ＮＳ．ＡＰ１」
において、開始イベント「０１．００．００．００．Ｓ
ＴＲ」が発生し、次いでネットワークアクタ「ＮＮ．Ｎ
ＷＡ」へメッセージを発信する依頼イベント「０１．０
１．００．００．ＰＲＯ」が発生し、ここで第１の枝番
「０１」が幹番「０１」の後に追加される。この２つの
イベントのログレコードが、ノード「ＮＳ」内のＡＰ用
イベントログファイル２９１に書き込まれる。なお、依
頼イベント「ＰＲＯ」については、それが多重に発生し
たときに書き込むべきログレコードの個数を最小にする
ために、最初の依頼イベントと最後の依頼イベントのロ
グレコードのみを書き込むこととする。従って、この送
信オブジェクト「ＮＳ．ＡＰ１」では、１つの依頼イベ
ント「０１．０１．００．００．ＰＲＯ」のみが発生し
ているが、その１つの依頼イベント「０１．０１．０
０．００．ＰＲＯ」のログレコードは最初の依頼イベン
ト及び最後の依頼イベントの双方のログレコードとし
て、二重に書き込まれる。

【０１００】ネットワークアクタ「ＮＮ．ＮＷＡ」で
は、依頼イベント「０１．０１．００．００．ＰＲＯ」
に対応する受付イベント「０１．０１．００．００．Ａ
ＣＣ」が発生し、次いで、キャスト先のノードアクタを
選択するといった変換イベント「０２．０１．００．０
０．ＸＣＧ」が発生し、ここで幹番がインクレメントさ
れる。次いで、ネットワークアクタ「ＮＮ．ＮＷＡ」で
は、選択された３つのノードアクタ「Ｎ１．ＮＤＡ」、
「Ｎ２．ＮＤＡ」、「Ｎ３．ＮＤＡ」へそのメッセージ
をマルチキャストする３つの依頼イベント「０２．０
１．０１．００．ＰＲＯ」、「０２．０１．０２．０
０．ＰＲＯ」（図示省略）及び「０２．０１．０３．０
０．ＰＲＯ」が発生し、その各々では、第２の枝番「０
１」、「０２」、「０３」が第１の枝番「０１」の後に
追加される。これらのイベントのログレコードが、この
ノード「ＮＮ」内のネットワークアクタ「ＮＮ．ＮＷ
Ａ」用のイベントログファイル２９３も書き込まれる。
このとき、前述したように、発生した３つの依頼イベン
トのうち、最初の依頼イベント「０２．０１．０１．０
０．ＰＲＯ」と最後の依頼イベント「０２．０１．０
３．００．ＰＲＯ」のログレコードだけが書き込まれ
る。

【０１０１】以下、選択された３つのノードアクタ「Ｎ
１．ＮＤＡ」、「Ｎ２．ＮＤＡ」、「Ｎ３．ＮＤＡ」、
および選択された受信オブジェクト「Ｎ１．ＡＰ２」、
「Ｎ２．ＡＰ３」、「Ｎ３．ＡＰ６」の各々において、
所要のイベントが発生し、各イベントのログレコードが
それぞれのオブジェクト用のログ領域に書き込まれる。
この過程で、中継点の番目が増えるに伴って、中継点カ
ウンタでは、幹番がインクレメントされるだけでなく、
より下位の枝番が追加されていく。

【０１０２】ところで、図２１及び図２２では図示を省
略してあるが、トランザクションＩＤも、中継点カウン
タのようなイベント自体の情報と一緒に、オブジェクト
間で受け渡しされる。したがって、同じトランザクショ
ンに含まれる全てのイベントのログデータには、その同
じトランザクションのＩＤが受け継がれる。

【０１０３】図２１および図２２に示した２つの例から
分かるように、１つのトランザクションを構成する複数
のイベントのログレコードは、そのトランザクションに
関与した複数のノード内のイベントログファイルに分散
して管理される。しかし、それら分散した複数のイベン
トログレコードは、それらに含まれる同じトランザクシ
ョンＩＤによって論理的にリンクされ、そして、それら
に含まれる中継点カウンタとイベント種別によってイベ
ント間の相互関係が理解され得るようになっている。

【０１０４】再び図１７を参照する。各ノードでは、普
段は各イベントトラッカ２６０内のログライタ２６５
が、上述したようにしてイベントログを取得しこれをイ
ベントログファイル２９１、２９３に書き込んでいる。
一方、或るトランザクションにおいて何らかの障害が発
生したときには、その障害解析やデバッグを行うため
に、ユーザはその目的のトランザクションに関係した或
るノード（典型的には、その目的トランザクションが発
生したノード）のイベントトラッカのログコレクタ２６
１を起動する。

【０１０５】ここで、例えば、図１７に示すイベントト
ラッカ２６０−１のログコレクタ２６１が起動されたと
仮定する。このログコレクタ２６１は、まず、そのノー
ドのディスプレイ装置４００に、検索キー入力画面を表
示する（ステップＳ１２）。この検索キー入力画面は、
例えば図２３に示すようなものである。ユーザはキーボ
ードなどの入力装置３００から、この検索キー入力画面
に、検索キーとして、目的トランザクションを発生させ
たノード名、プロセス名および目的トランザクションの
発生時刻（又は障害発生時刻）を入力することができる
（ステップＳ１３）。

【０１０６】検索キーが入力されそしてユーザより検索
が命じられると、ログコレクタ２６１は、まず、その検
索キーを用いて、自ノード内のイベントログファイル２
９１、２９３内のイベントログをスキャンすることによ
り（ステップＳ１４）、目的トランザクションの候補を
抽出し、そして、そのトランザクション候補のリストを
ディスプレイ装置４００に出力する（ステップＳ１
５）。そのトランザクション候補リストは例えば図２４
に示すようなもので、そこには、各トランザクション候
補のトランザクションＩＤ、発生時刻、トランザクショ
ン種別などが示される。ユーザは、このリストの中か
ら、入力装置３００のマウス又はキーボードを用いて、
目的トランザクションを決定することができる（Ｓ１
６）。

【０１０７】目的トランザクションが決定されると、ロ
グコレクタ２６１は、自ノード内のイベントログファイ
ル２９１、２９３から目的トランザクションのログファ
イルを検索する（Ｓ１７）。更に、ログコレクタ２６１
は、自分の物理ネットワーク２１０−１上のログコレク
ションエージェント２５０−１に対して、そのトランザ
クションに関わる他の全てのログファイルを収集するこ
とを依頼するメッセージを送る（Ｓ１８）。すると、そ
のログコレクションエージェント２５０−１は、自分の
物理ネットワーク２１０−１上の全てのノードのイベン
トトラッカ２６０−２、２６０−３、…に対して、その
依頼メッセージをＩＰブロードキャストの方法で配信す
る（Ｓ１９）。更に、ログコレクションエージェント２
５０−１は、他の全ての物理ネットワーク２１０−２、
…上の他のログコレクションエージェント２５０−２、
…の各々に対して、その依頼メッセージをユニキャスト
の方法で個別に送る（ステップＳ２０）。他のログコレ
クションエージェント２５０−２、…も、同様にして、
自分の物理ネットワーク２１０−２、…上の全てのノー
ドのイベントトラッカ２２０−６、２２０−７、…へ、
その依頼メッセージをブロードキャストする（ステップ
Ｓ２１）。

【０１０８】その依頼メッセージを受けた他のノードの
イベントトラッカ２６０−２、２６０−３、…、２６０
−６、２６０−７、…の各々では、各ログコレクタ２６
１が各ノード内のイベントログファイル２９１、２９３
から目的のトランザクションＩＤをもったイベントログ
レコードを検索し（ステップＳ２２）、検索したレコー
ドを依頼元である各ログコレクションエージェント２５
０−１、２５０−２、…へ送信する（ステップＳ２
３）。これにより、各ログコレクションエージェント２
５０−１、２５０−２、…には、各物理ネットワーク２
１０−１、２１０−２上で多数のノードに分散していた
目的トランザクションに関わるイベントログコードが収
集される。各ログコレクションエージェント２５０−
１、２５０−２、…は、収集されたイベントログコード
を各依頼元へ送る（ステップＳ２４、Ｓ２５）。結果と
して、イベントトラッカ２６０−１のログコレクタ２６
１は、目的トランザクションに関わる全てのイベントロ
グレコードを収集する。

【０１０９】次に、イベントトラッカ２６０−１のログ
コレクタ２６１は、こうして収集したイベントログレコ
ードを、リストの形でディスプレイする（ステップＳ２
６）と共に、ログアナライザ２６３に渡す（ステップＳ
２７）。ディスプレイされたイベントログレコードのリ
ストは、例えば図２５に示すようなものである。図２５
は、図２２に示したトランザクションのログレコードを
収集した場合を例示している。このレコードリストに
は、収集された各イベントログレコードの、トランザク
ションＩＤ、オブジェクト、中継点カウンタ、イベント
種別およびが書き込み時刻などが示されている。なお、
図２５では、書き込み時刻を簡略的に「分」までしか示
してないが、実際には各イベントの発生時刻を区別でき
る「ミリ秒」のオーダまで書き込まれている。なお、ロ
グコレクタ２６１は、例えば、上述したログコレクタ２
６１の殆どの機能を受け持つデーモンプロセスと、ログ
アナライザ２６３とのインタフェースを受け持つユーテ
ィリティ（コマンド）とのセットととして実装され得
る。

【０１１０】ログアナライザ２６３は、それらのイベン
トログレコードの中継点カウンタとイベント種別とに基
づいて、それらイベントを相互に関連付け、それによっ
て、目的トランザクションにおいてどのオブジェクトが
どのように連携動作したかという経過を明らかにし、そ
の経過を表現したテキスト又はグラフィックスを編集し
てディスプレイ装置４００に出力する。この経過表示画
面は例えば図２６に示すようなものであり、それによ
り、ユーザは目的トランザクションの経過を容易に把握
することができる。なお、ログアナライザ２６３は、例
えば、ユーティリティ（コマンド）として実装され得
る。

【０１１１】以上、本発明の一実施形態を説明したが、
本発明はこの実施形態にのみ限定されるものではなく、
他の種々の形態でも実施することが可能である。例え
ば、本発明の方式は、オブジェクト間の非同期協調動作
だけでなく同期協調動作についても適用できる。

【図面の簡単な説明】

【図１】本発明の一実施形態の構成を示すブロック図。

【図２】同実施形態のより具体的な構成を示すブロック
図。

【図３】同実施形態の動作を示すシーケンス図。

【図４】同実施形態の動作を示すシーケンス図。

【図５】サービステーブルの例を示す図。

【図６】オブジェクト間非同期協調動作による一つの利
点を説明する図。

【図７】本発明の一実施形態の概略的な全体構成を示し
たブロック図。

【図８】同実施形態の概念的な構成を示したブロック
図。

【図９】ネットワークアクタ１５０とノードアクタ１６
０の機能を具体的に示したブロック図。

【図１０】ノードアクタテーブルの一例を示した図。

【図１１】ＡＰオブジェクトテーブルの一例を示した
図。

【図１２】ドメインテーブルの一例を示した図。

【図１３】ＡＰオブジェクト１４０から送出されるメッ
セージの構成を示したデータフォーマット図。

【図１４】特定ドメインへのメッセージ配信の階層を示
したブロック図。

【図１５】本発明に従うログ管理及びイベント追跡方式
の一実施形態の全体構成を示すブロック図。

【図１６】この実施形態の説明で用いる重要な幾つかの
概念の説明図。

【図１７】イベントトラッカ２６０とログコレクション
エージェント２５０の構成および関係を示すブロック
図。

【図１８】ＡＰ用イベントログファイル２９１の構成を
示す図。

【図１９】デーモンプロセス用イベントログファイル２
９３の構成を示す図。

【図２０】イベントログレコード２９７の構成を示す
図。

【図２１】「サービス」におけるイベントの例を示すシ
ーケンス図。

【図２２】「マルチキャスト」におけるイベントの例を
示すシーケンス図。

【図２３】検索キー入力画面の例を示す図。

【図２４】トランザクション候補リストの例を示す図。

【図２５】イベントログレコードリストの例を示す図。

【図２６】経過表示画面の例を示す図。

【符号の説明】

２００ 通信ネットワーク ２１０ 物理ネットワーク ２２０ ノード ２５０ ログコレクションエージェント ２６０ イベントトラッカ ２７０ トランザクション ２８０ イベント ２６１ ログコレクタ ２６３ ログアナライザ ２６５ ログライタ ２９１ アプリケーション用イベントログファイル ２９３ デーモンプロセス用イベントログファイル ２９７ イベントログレコード

フロントページの続き (72)発明者 山本 英明 東京都江東区豊洲三丁目３番３号 エヌ・ ティ・ティ・データ通信株式会社内 (72)発明者 増木 亮介 東京都江東区豊洲三丁目３番３号 エヌ・ ティ・ティ・データ通信株式会社内 (72)発明者 内川 淳 東京都千代田区丸の内一丁目３番２号 株 式会社住友銀行内 (72)発明者 市来 伸彦 東京都千代田区丸の内一丁目３番２号 株 式会社住友銀行内

Claims (26)

【特許請求の範囲】
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. 【請求項２６】 前記各ノード内の前記オブジェクトが
    イベントを実行したとき、実行したイベントのイベント
    ログを前記各ノード内の前記ログファイルに記録するロ
    グライタを、前記イベントトラッカが更に有する請求項
    ２４記載の記録媒体。