(57)【特許請求の範囲】
【請求項１】
ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述する依存データを収集すること（６０２）；
依存データには、順序付けられた一対のソフトウエアコンポーネントの依存関係を表す複数の辺の情報、及び、当該辺の所属先であるソフトウエアアプリケーションあるいはトランザクションのタイプを特定する情報が含まれており、
ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように前記依存データを集約すること（６０４）；
前記依存データを集約することは、前記複数の辺の中から、ユーザによって指定されたソフトウエアアプリケーションあるいはトランザクションのタイプに所属する特定の辺を抽出すること、及び、前記特定の辺の最初のインスタンスに対して論理辺を作成するとともに前記特定の辺の付加的なインスタンスの情報を前記論理辺に付加すること、を含み、
前記有向グラフに基づいて、ユーザによって指定されたソフトウエアアプリケーションあるいはトランザクションのタイプについて依存マップであってトランザクションが処理されるときの依存関係を表す依存マップをディスプレィの画面上に表示すること（６０６）；
を備える、コンピュータに実装される方法。
【請求項２】
収集された依存データは、複数の頂点のデータであって各頂点が複数のソフトウェアコンポーネントの中の一つのソフトウエアコンポーネントに関連付けられている頂点データを含む、
請求項１のコンピュータに実装される方法。
【請求項３】
依存データを収集することは、複数のソフトウェアコンポーネントのいずれかに対するソフトウェアコンポーネントを記述する情報を収集することを含む、
請求項２のコンピュータに実装される方法。
【請求項４】
有向グラフを形成するように前記依存データを集約することは、
依存データにおける最初のソフトウェアコンポーネントの最初のインスタンスに対する最初の論理的頂点を生成すること；および
依存データにおける最初のソフトウェアコンポーネントの付加的インスタンスに対する最初の論理的頂点に情報を付加すること、
を含む請求項２または３のコンピュータに実装される方法。
【請求項５】
有向グラフに基づいてディスプレィの画面上に依存マップを表示することは、時間が経過していることを示すように最初のソフトウェアアプリケーションを表示することを含む、請求項４のコンピュータに実装される方法。
【請求項６】
ソフトウェアコンポーネントによって処理されるトランザクションをトレースすること、をさらに備える請求項１から５のいずれか１項のコンピュータに実装される方法。
【請求項７】
依存マップは、複数のソフトウェアコンポーネントを含むアプリケーション間の依存関係を表す、請求項１から６のいずれか１項のコンピュータに実装される方法。
【請求項８】
１以上のコンピューティングデバイス（１１０Ａ，１１０Ｂ）上で実行されるソフトウェアコンポーネント（モジュールＡ１，Ａ２，Ａ３，Ｂ１）によって処理されるトランザクションのトレースを開始する少なくとも一つのプロセッサ（５３０）を有しており、
その少なくとも一つのプロセッサは、トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を記述する依存データであって順序付けられた一対のソフトウエアコンポーネントの依存関係を表す辺の情報、及び、当該辺の所属先であるソフトウエアアプリケーションあるいはトランザクションのタイプを特定する情報が含まれている依存データを収集し、
その少なくとも一つのプロセッサは、トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように依存関係を記述する前記依存データを集約し、
前記依存データを集約することは、前記複数の辺の中から、ユーザによって指定されたソフトウエアアプリケーションあるいはトランザクションのタイプに所属する特定の辺を抽出すること、及び、前記特定の辺の最初のインスタンスに対して論理辺を作成するとともに前記特定の辺の付加的なインスタンスの情報を前記論理辺に付加すること、を含み、
その少なくとも一つのプロセッサは、前記有向グラフに基づいて、ユーザによって指定されたソフトウエアアプリケーションあるいはトランザクションのタイプについて依存マップであってトランザクションが処理されるときの依存関係を表す依存マップをディスプレィの画面上に表示する、
システム。
【請求項９】
少なくとも一つのプロセッサに接続されたディスプレィ（５５０）をさらに有し、その少なくとも一つのプロセッサは、複数のソフトウェアコンポーネント間の依存関係を表す依存マップをディスプレィ上に表示する、請求項８のシステム。
【請求項１０】
収集された依存データは、複数のソフトウェアコンポーネントを記述する頂点データを含む、請求項８または９のシステム。
【請求項１１】
収集された依存データは、複数のソフトウェアコンポーネントのいずれかに対するソフトウェアコンポーネントを記述する情報を含む、請求項８から１０のいずれか一項のシステム。
【請求項１２】
ソフトウェアコンポーネントがトランザクションを処理するときの、複数のソフトウェアコンポーネント間の依存関係を記述する依存データであって順序付けられた一対のソフトウエアコンポーネントの依存関係を表す辺の情報、及び、当該辺の所属先であるソフトウエアアプリケーションあるいはトランザクションのタイプを特定する情報が含まれている依存データを収集する手段（５３０）；
トランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように前記データを集約する手段（５３０）；
前記依存データを集約する手段は、前記複数の辺の中から、ユーザによって指定されたソフトウエアアプリケーションあるいはトランザクションのタイプに所属する特定の辺を抽出すること、及び、前記特定の辺の最初のインスタンスに対して論理辺を作成するとともに前記特定の辺の付加的なインスタンスの情報を前記論理辺に付加することを含んでおり；および
前記有向グラフに基づいて、ユーザによって指定されたソフトウエアアプリケーションあるいはトランザクションのタイプについて依存マップであってトランザクションが処理されるときの依存関係を表す依存マップをディスプレィの画面上に表示する手段（５５０、５３０）；
を備えるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンピューティング環境におけるソフトウェアを監視する技術に関する。
【背景技術】
【０００２】
インターネットの存在が増長するにつれて、イントラネット、エクストラネットなどの他のコンピュータネットワークと同様に、電子商取引、教育、他の分野において多くの新しいアプリケーションをもたらした。組織は、ビジネスやその他目的を成し遂げるためにそのようなアプリケーションに益々依拠し、期待通りの成果を確実に得るために相当の資源を投入している。このような状況のもと、様々なアプリケーションの管理技術が開発されている。
【０００３】
１つのアプローチとして、アプリケーション内で呼び出される個々のソフトウェアコンポーネントに関するアプリケーションの実行データを集めることにより、アプリケーションのインフラストラクチャを監視することが挙げられる。このアプローチでは、監視されるシステムに元々に存在するエージェントを用いることができる。例えば、ソフトウェアによる計測を用いることによって、呼び出される個々のコンポーネントを特定するため、あるいは、個々のコンポーネントの実行時間のような実行データを得るために、スレッドまたはプロセスがトレースされ得る。コンピュータプログラムが実行するステップの詳細な記録またはトレースを得ることをトレーシングという。トレースは、デバッグの補助として使用することができる。
【発明の概要】
【０００４】
通常、いくつかのタイプのレポートがトレーシングの結果に基づいてユーザに提示される。この情報は、容易に理解される方法でユーザに提示されるべきである。情報があまりにも詳細である場合には、ユーザは、問題がどこにあるのかを正確に判断することは難しい。あまり詳細でないとしても、問題を迅速に可視化するのに役立つ情報が提供されないことがある。例えば、トレーシングの情報は、異なるコンピューティングデバイス上で実行するソフトウェアアプリケーションからデータを収集することがある。場合によっては、様々なエンティティが種々のソフトウェアアプリケーションを維持する責任を持つ。例えば、あるエンティティがユーザのリクエストを受信するWebサーバアプリケーションを維持する一方で、別のエンティティがバックエンドデータベースを維持する。適切なエンティティにコンタクトできれば、問題（例えば、実行が遅くなる）がWebサーバまたはバックエンドデータベースのどちらで起こっているのかをユーザが迅速に確認するのに役立つ。
【０００５】
本明細書で開示される一実施形態は、ディスプレィの画面上に依存マップを表示するために、装置に実装される方法（コンピュータに実装される方法）を含む。当該方法は、ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること；ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように上記のデータを集約すること；有向グラフに基づいて、ディスプレィの画面上に依存マップを表示すること、を有する。この依存マップは、トランザクションが処理されるときの依存関係を示す。
【０００６】
本明細書で開示される一実施形態は、１以上のプロセッサを有するシステムを含み、コンピュータで読み取り可能な記憶装置が１以上のプロセッサに結合されている。コンピュータで読み取り可能な記憶装置は、それに格納されたコンピュータで読み取り可能な命令を有し、１以上のプロセッサ上で実行されると、１以上のプロセッサにシステム内のソフトウェアコンポーネントによって処理されるトランザクションのトレースを開始させ；トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を記述するデータを収集し；トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように依存関係を記述するデータを集約し；トランザクションが処理されるときのソフトウェアコンポーネント、またはソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を記述する有向グラフに基づいて依存マップを表示する。
【０００７】
本明細書に開示される一実施形態は、「ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること；ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように上記のデータを集約すること；および、有向グラフに基づいてディスプレィの画面上に依存マップを表示することを有する。ここで、その依存マップは、トランザクションが処理されるときのソフトウェアコンポーネントのセットまたは複数のソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を示す。」方法：を実行するための少なくとも１つのプロセッサをプログラムするためのコンピュータで読み取り可能な命令を格納する、コンピュータで読み取り可能な記憶装置を含む。
【図面の簡単な説明】
【０００８】
【図１】管理されたアプリケーションを含むシステムを示す。
【図２】ディスプレィの画面上に提示され得る依存マップの例を示す。
【図３】ディスプレィの画面上に提示され得る依存マップの例を示す。
【図４】ディスプレィの画面上に提示され得る依存マップの例を示す。
【図５Ａ】図１のネットワークで使用されるコンピュータシステムの一実施形態を示す。
【図５Ｂ】監視アプリケーションの処理の一実施形態のフローチャートを示す。
【図６】ダイグラフに基づく依存マップを表示する処理の一実施形態を示すフローチャートである。
【図７】依存データを収集する処理の一実施形態を示すフローチャートである。
【図８】ダイグラフのデータ構造の一実施形態のブロック図である。
【図９】ダイグラフを作成するときにおける辺の処理の一実施形態を示すフローチャートである。
【図１０Ａ】ダイグラフを作成するときにおける頂点の処理の一実施形態を示すフローチャートである。
【図１０Ｂ】ダイグラフを作成するときにおける頂点の処理の一実施形態を示すフローチャートである。
【図１１】依存データの存在時間に基づいて表示するためのダイグラフを変更する処理の一実施形態を示すフローチャートである。
【発明を実施するための形態】
【０００９】
本明細書では、データに基づく依存マップを表示するだけでなく、トランザクションが処理される場合にソフトウェアコンポーネント間の依存関係を記述するデータを生成する技術を開示する。データは、ソフトウェアコンポーネントによって処理されるトランザクションを監視またはトレースするエージェントによって収集される。収集されたデータは、ソフトウェアコンポーネント間の依存関係を記述する有向グラフを形成するために集約される。依存マップは、その有向グラフに基づいて表示される。トランザクションが処理される場合、依存マップはソフトウェアコンポーネント間の依存関係を示す。依存マップは、またソフトウェアコンポーネントを含むアプリケーション間の依存関係を示すこともある。依存マップによって、問題がどこに発生しているかをユーザは簡単かつ迅速に確認できるようになる。例えば、ユーザは、フロントエンドのアプリケーションサーバにではなく、バックエンドのデータベースに問題があることを迅速に判定することができる。
【００１０】
図１は、異なったコンピュータシステムがマネージャにデータを提供するネットワーク１００を示す。例示のコンピュータシステムには、アプリケーションサーバ１１０ａ，１１０ｂ、または、所望の機能を実現するためのコードを実行するのに適したプロセッサを有する他のタイプのコンピュータシステムを含む。アプリケーションサーバ１１０は、異なったアプリケーションを実行でき、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ１１０は、互いに離れて設置されてもよいし、または同じ場所に設置されてもよい。この例では、アプリケーションサーバ１１０は、マネージャコンピュータ１２０と通信する。マネージャ１２０は、アプリケーションサーバ１１０と同じ場所にあってもよいし、離れた場所にあってもよい。
【００１１】
例えば、Webベースの電子商取引アプリケーションなど企業アプリケーション（enterprise application）を実行している会社は、負荷分散のために１つの場所で複数のアプリケーションサーバを使用する。例えば、ユーザのWebブラウザ１０２のようなユーザからのリクエストは、インターネットのようなネットワーク１０４を介して受信され、いずれかのアプリケーションサーバ１１０に送られる。Webブラウザ１０２は、通常、図示していないインターネットサービスプロバイダーを介してネットワーククラウド１０４にアクセスする。
【００１２】
アプリケーションサーバ１１０ａ，１１０ｂは、管理されたアプリケーションＡ  １５１Ａおよび管理されたアプリケーションＢ  １５１Ｂを含み、それらは、エージェント１１２Ａ，１１２Ｂおよび例示のプローブ１５３Ａ，１５３Ｂを含む。プローブの数は、任意である。符号中に文字を持つ構成要素（例えば、アプリケーションサーバ１１０ａ，１１０ｂ）は、説明用に区別するためである。ここでは、「ａ」または「ｂ」のない符号の使用は、特定のサーバまたは他の構成要素に言及しないことを示す。アプリケーション１５１は、Java（登録商標）アプリケーションまたはアプリケーションの異なるタイプである。このように、アプリケーションサーバ１１０で実行されるエージェントソフトウェアは、エージェント１１２によって表され、ある可能なアプローチとして、アプリケーションサーバ１１０上で実行されている、管理されたアプリケーション１５１、ミドルウェアまたはその他のソフトウェアから、情報を収集する。例えば、アプリケーション１５１からの情報は、プローブ１５３を使用して得られる。実際には、多くのそのようなプローブは、アプリケーション１５１の様々なコンポーネントに関する情報を得るために使用することができる。いくつかの実施形態では、プローブは、計測を用いることによってアプリケーション１５１に付加され、その一例にはバイトコード計測がある。ただし、収集されたデータは、他の方法でも得ることができる。エージェント１１２は、監視対象となるコンピュータシステムに元々に存在しており、データの取得ポイントを提供する。エージェントは、マネージャ１２０と通信してデータをまとめ、最適化する。
【００１３】
トランザクションの流れを記述する目的のため、トランザクションを処理するソフトウェアコンポーネントは、管理されたアプリケーション１５１に示される。ソフトウェアコンポーネントは、管理されたアプリケーション１５１内の任意のコードの部分（例えば、モジュール）を、または管理されたアプリケーション外の任意のコードの部分を含む。例えば、管理されたアプリケーション１５１内のソフトウェアコンポーネントは、サーブレット、Plain Old Java Objects（ＰＯＪＯ）、Enterprise Java Beans（登録商標）(ＥＪＢ（登録商標））、ソケットなどを含むが、これらに限定されない。管理されたアプリケーション１５１外のソフトウェアコンポーネントは、管理されたアプリケーション１５１と相互に作用するものを含むが、直接的な相互作用までは必要とされない。管理されたアプリケーション１５１外のソフトウェアコンポーネントは、データベース、Webサービス、Webブラウザなどを含むが、これらに限定されない。
【００１４】
３つのトランザクションが図１に示される。トランザクションＢＴＡ１は、一例として、Webブラウザ１０２からのＨＴＴＰリクエストに応答して開始される。トランザクションＢＴＡ１の場合、その流れは、モジュールＡ１からモジュールＡ２、データベースＸ  １１３へとなる。実際には、トランザクションＢＴＡ１に関与する多くのソフトウェアコンポーネントが存在することに留意されたい。しかし、すべてのソフトウェアコンポーネントがユーザに注目されるわけではない。例えば、モジュールＡ１とモジュールＡ２との間のトランザクションに伴って、１以上のソフトウェアコンポーネントが存在する可能性がある。また、モジュールＡ２とデータベースＸ  １３３との間のトランザクションに伴って、１以上のコンポーネントが存在する可能性がある。例えば、モジュールＡ２とデータベースＸ  １１３との間にソケットが存在し得る。しかしながら、そのソケットはユーザに注目されるわけではない。トランザクションＢＴＡ２の場合、その流れは、モジュールＡ３からWebサービス１０９、モジュールＢ１へとなる。モジュールＢ１からデータベースＹ  １１４への流れは、例えば、それがモジュールＡ３からモジュールＢ１への呼び出しを原因としている場合には、トランザクションＢＴＡ２の一部とも考えられる。トランザクションＢＴＡ２は、アプリケーションＢに対するトランザクションＢＴＢ１を生成する。具体的には、トランザクションＢＴＢ１の流れは、モジュールＢ１からデータベースＹ  １１４へとなる。
【００１５】
説明のため、トランザクションＢＴＡ１は、ユーザが（Webブラウザ１０２で）本または他のアイテムを購入する「購入トランザクション」となり得る。説明のため、トランザクションＢＴＡ２は、本を購入するためのクレジットカードの使用を承認する「クレジット確認トランザクション」となり得る。様々なユーザがWebサイトを訪れると、時間の経過とともに、トランザクションＢＴＡの多くの異なるインスタンスが出現することに留意されたい。したがって、トランザクションＢＴＡ１は、多くのインスタンスが存在する「トランザクションのタイプ」と称することが可能となる。
【００１６】
複数の実施形態において、エージェント１１２は、トランザクションが処理されてマネージャ１２０へデータが供給される場合、ソフトウェアコンポーネント間の依存関係を記述するデータを収集する。マネージャ１２０は、ソフトウェアコンポーネントがトランザクションを処理するときにソフトウェアコンポーネント間の依存関係を示す有向グラフ（「ダイグラフ」）を形成するためにそのデータを集約する。例えば、ダイグラフは、コンポーネントを表す頂点とコンポーネント間の依存関係を表す辺とを有する。依存マップは、ダイグラフに基づいて、ユーザインタフェース１２２のようなディスプレィの画面上に表示されることがある。トランザクションが処理される場合、依存マップが依存関係を示す。依存マップは、様々な詳細レベルを持つことがあり得る。例えば、それはソフトウェアコンポーネント間の依存関係を表す。しかし、依存マップは、より一般的になると、アプリケーション１５１間の依存関係を示す（おそらくソフトウェアコンポーネントさえも示さない）。以下は、図示目的のためのいくつかの依存マップの例である。これらのマップは、図１のシステム１００によって処理されるトランザクションの例に対応している。
【００１７】
図２は、ディスプレィの画面（例えばユーザインタフェース１２２）上に表示可能な依存マップ２００ａの一例を示す。依存マップ２００ａの例は、トランザクション処理におけるシステム１００のソフトウェアコンポーネント間の依存関係を示す。この例では、依存マップ２００ａはアプリケーションＡによって処理されるトランザクションに関係する。この依存マップ２００ａは、管理されたアプリケーションＡ  １５１Ａの詳細な依存マップのユーザリクエストに応答して表示可能である。トランザクションＢＴＡ１およびＢＴＡ２は、管理されたアプリケーションＡの依存マップの一部と考えられる。両トランザクションは、アプリケーションＡの依存マップを形成するために互いに結合されている。例えば、モジュールＡ１、モジュールＡ２およびデータベースＸ  １１３の間の依存関係は、これらのコンポーネントを繋ぐ矢印で示される。これは、トランザクションＢＴＡ１に対応することに留意されたい。モジュールＡ３、Webサービス１０９、モジュールＢ１およびデータベースＹ  １１４の間の依存関係は、これらの構成要素を繋ぐ矢印で示される。これは、トランザクションＢＴＡ２に対応することに留意されたい。別の可能性としては、ユーザがアプリケーションＡの詳細のみを要求することにより、管理されたアプリケーションＢ  １５１ｂの細部がわずかに示される。例えば、モジュールＢ１および／またはデータベースＹ  １１４は、示されない。代わりに、Webサービス１０９から管理されたアプリケーションＢ  １５１ｂへの矢印のみがある。
【００１８】
依存マップ２００は、頂点と辺を含む。頂点は、ソフトウェアコンポーネントに対応する。例えば、図２では、頂点は、「外部頂点」、モジュールＡ１、モジュールＡ２、モジュールＡ３、データベースＸ、Webサービス、モジュールＢ１およびデータベースＹである。場合によっては、管理されたアプリケーションＡおよび管理されたアプリケーションＢが頂点になることに留意されたい。また、「外部頂点」という用語は、アプリケーションサーバ外にある頂点のタイプを示すのに使われていることにも留意されたい。この場合、外部頂点は、管理されたアプリケーションＡ  １５１ＡにＨＴＴＰリクエストを送信するソフトウェアコンポーネントを表す。ユーザは、正確にどのソフトウェアコンポーネントがＨＴＴＰリクエストを送信したかには注目しないことに留意されたい。したがって、一般的な用語「外部頂点」を使用することで十分な説明を提供することができる。
【００１９】
図２では、辺２５１ａ〜２５１ｆに符号が付けられている。辺は、一対のソフトウェアコンポーネントの間の依存関係を表す。一般的に、辺は２つのソフトウェアコンポーネントの順序付けられた対として記述される。図２において、辺は、矢印で表現される。矢印の尾部と頭部は、順序付けられた対のソフトウェアコンポーネントの順序を定義するために使用される。例えば、辺２５１ａは、（モジュールＡ１、モジュールＡ２）として記述される。辺２５１ｂは、（モジュールＡ２、データベースＸ）として記述される。
【００２０】
一実施形態では、依存マップ２００は、図２で示すものよりも上位レベルのサマリーが含まれることもある。アプリケーションおよび／またはソフトウェアコンポーネントの数が多い場合には、アプリケーションのより詳細な表示としては複雑になることがある。図３は、ディスプレィの画面上に示されるサマリーの依存マップ２００ｂの一例を示す。この例は、図２の例よりも上位レベルのサマリーであり、アプリケーションＡの概要である。この例では、管理されたアプリケーションＡ  １５１ａ、管理されたアプリケーションＢ  １５１ｂ、データベースＸ  １１３およびデータベースＹ  １１４の間の依存関係がトランザクションＢＴＡ１およびＢＴＡ２に対して示されている。管理されたアプリケーション１５１内のソフトウェアコンポーネントは示されていないことに留意されたい。しかし、依存マップ２００ｂは、図２の依存マップ２００ａに使用されたエージェント１１２によって収集されたものと同じデータから生成されていることがある。
【００２１】
依存マップ２００は、また前例のような管理されたアプリケーションの代わりに、特定のトランザクションに向けられることもある。図４は、トランザクションＢＴＡ１のサマリーを示す一例を示している。このような依存マップ２００ｃは、トランザクションＢＴＡ１の依存マップに対するユーザのリクエストに対応して示されることがある。業務トランザクションのサマリービューは、トランザクションの流れを表示する。この例では、トランザクションＢＴＡ１の一部である辺だけが強調されている（太い実線の矢印）。他の辺はトランザクションＢＴＡ１の一部ではないことを示すために破線になっている。例えば、辺（アプリケーションＡ、Webサービス）および（Webサービス、アプリケーションＢ）は、ＢＴＡ１の一部ではないが、強調されることなく依然として表示はされている。辺（ＢＴＡ１、アプリケーションＡ）および（アプリケーションＡ、データベースＸ）は、ＢＴＡ１の一部であるので強調されている。アプリケーションＢは、ＢＴＡ１の一部ではないことから、辺（アプリケーションＢ、データベースＸ）は表示されていない。
【００２２】
ＢＴＡ２などのその他のトランザクションのサマリービューもまた表示され得る。共通の目的を達成するための互いに作用するトランザクションから構成されている業務サービスの依存マップ２００を表示する別の可能性もある。一例として、ＢＴＡ１およびＢＴＡ２は、同じ業務サービスの一部と考えることができる。業務サービスのサマリーは、ＢＴＡ１およびＢＴＡ２に含まれるすべての頂点と辺の結合であり得る。
【００２３】
図１の説明に再び戻ると、一実施形態では、プローブビルダー（図１には図示されない）は、プローブ１５３および付加的なコードを付加し、管理されたアプリケーション１５１のためにバイトコードを計測（例えば変更）する。プローブ１５３は、アプリケーションの業務ロジックを変更することなく、管理されたアプリケーション１５１についての情報の特定部分を測定する。あるタイプのプローブは、コンポーネントが実行に費やす時間を測定する。時間には、プローブを有するコンポーネントによって呼び出されたコンポーネントによる実行に費やす時間を含めることができるが、これは必須ではない。プローブ１５３は、コンポーネントの入口における始点およびコンポーネントの各出口における終点を有する。一実施形態では、始点ではタイマを起動し、終点ではタイマを止める。プローブ１５３は、タイミング情報に加えて他の情報も収集する。
【００２４】
プローブビルダーは、アプリケーション１５１または別のマシン（コンピュータ）と同じマシン（コンピュータ）上にインストールされるエージェント１１２もまた付加する。一旦、プローブ１５３がアプリケーション１５１にインストールされると、または監視機能が別に提供されると、そのアプリケーションは管理されたアプリケーションと称される。バイトコードを計測することについて、さらなる情報として、Lewis K. Cirneによる“System For Modifying Object Oriented Code”と題する米国特許番号６，２６０，１８７や、２００１年２月２８日に出願された“Adding Functionality To Existing Code At Exits,”と題する米国特許出願番号０９／７９５，９０１があり、それぞれその全体が参照により本明細書に組み込まれる。
【００２５】
管理されたアプリケーション１５１が実行されると、プローブ１５３がエージェント１１２にデータを送信する。例えば、プローブからの情報は、トランザクションまたは他の実行フローの開始および停止回数、またはトランザクション／実行フロー内の個々のコンポーネントの開始および停止回数、のようなパフォーマンスデータを示す。一実施形態では、プローブ１５３は、またはデータを書いたり、データを変更したり、そうでなければアプリケーションサーバの状態を変更する原因となったりする他のコードやオブジェクトに実装される。このデータは、アプリケーション実行データと称される。エージェント１２２は、またトランザクションが処理される場合にコンポーネント間の依存関係を記述した依存データを収集する。エージェント１１２は、その後、アプリケーション実行データおよび依存データを収集し、要約してマネージャ１２０に送信する。それに呼応して、マネージャ１２０は要求された計算を実行し、アプリケーション実行データをユーザインタフェース１１２で使用可能にして、必要に応じて、後で解析するためにデータベース１１８へアプリケーション実行データを送信する。また、マネージャ１２０は、ダイグラフを形成し、そのダイグラフに基づいて１以上の依存マップを表示するため、依存データを集約する。プローブを用いてアプリケーションを監視することに関するさらなる情報として、２００４年４月２２日に公開された、Lewis K. Cirneによる“User Interface For Viewing Performance Information About Transactions”と題する米国特許出願公開番号２００４／００７５６９０があり、その内容は参照により本明細書に組み込まれる。
【００２６】
マネージャ１２０は、エージェントから受信したデータに基づいて情報を表示するために、例えばモニタのようなユーザインタフェース１２２と通信するワークステーションのような独立したコンピュータシステム上に提供される。マネージャ１２０は、またエージェントから受信したデータを格納するためにデータベース１１８へアクセスする。提示された例では、アプリケーションサーバは、ネットワーク１０４にアクセスすることなくマネージャ１２０と通信する。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ１２０は、ネットワーク１０４を介して複数のアプリケーションサーバのエージェントからデータを受信することができる。例えば、大規模な組織は、セントラルネットワークオペレーションセンタを運用しており、そこでは、１以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得することがある。支払い処理をするサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ１２０およびユーザインタフェースディスプレィ１２２は、企業の本社の場所で提供される。必ずしも、Webベース、または、小売り、若しくはその他の販売に関する必要はない他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを利用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数のコンピュータのシステムアレンジに加えて、エージェントによって単一のコンピュータシステムが同様に監視されることがある。
【００２７】
図５Ａは、図１のネットワークで使用されるコンピュータシステムの一実施形態を示す。コンピュータシステム５００は、図１に関連して説明したように、Webブラウザ１０２、ホスト（例えばアプリケーションサーバ１１０）、マネージャ１２０および／またはユーザインタフェース１２２で使用されるシステムを簡略化して表したものである。コンピュータシステム５００は、ハードディスクまたはポータブルメディアのような記憶装置５１０、他のコンピュータと通信するためのネットワークインタフェース５２０、ソフトウェアの命令を実行するためのプロセッサ５３０、例えば、記憶装置５１０からロードされた後にソフトウェアの命令を格納するためのＲＡＭのような作業メモリ５４０およびユーザインタフェースディスプレィ５５０を含むものである。記憶装置５１０は、ここで説明した機能を提供するための方法を実行するのにプロセッサ５３０をプログラムするために具現化されているプロセッサ読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ５５０は、１以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ５５０は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。
【００２８】
また、ここで説明した機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、１以上のプロセッサをプログラムするために具現化されているプロセッサの読み取り可能に格納されたコードを有する、１以上のプロセッサにより読み取り可能な記憶装置を使用することができる。プロセッサにより読み取り可能な記憶装置は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な記憶装置を含むことが可能である。例えば、コンピュータにより読み取り可能な記憶装置には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な記憶装置の例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタルバーサタイルディスク（ＤＶＤ）、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムＩＣ、ゲートアレイ、ＦＰＧＡ、ＰＬＤや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、１以上の実施形態を実装するソフトウェア（記憶装置に格納されている）は、１以上のプロセッサをプログラムするために用いられる。１以上のプロセッサは、１以上のコンピュータにより読み取り可能な記憶装置、周辺機器および／または通信インタフェースと通信することができる。
【００２９】
いくつかの実施形態では、エージェント１１２は、アプリケーション１５１を監視してアプリケーション実行データをマネージャ１２０に転送し、そこでデータが解析されユーザに報告される。図５Ｂは、アプリケーション１５１を監視する処理の一実施形態のフローチャートを示している。当該処理は、図１のシステム１００の例において実行される。アプリケーション１５１は、ステップ５０２でエージェント１５２に監視される。監視は、エージェント１１２が、アプリケーションサーバ１１０のどのトランザクションが処理されるのかを判定すること、及び、アプリケーションがクライアントの要求を処理するときにエージェント１１２が呼び出されている間の時間を決定することを含む。監視は、また、エージェント１１２が、コンポーネントがトランザクションを処理するときの依存データを特定することを含む。依存データのいくつかの例は、以下に説明される。ステップ５０２は、データを収集するために実行するアプリケーション１５１内のプローブを含む。
【００３０】
アプリケーションの監視に基づくアプリケーション実行データは、ステップ５０４で生成される。生成されたアプリケーション実行データは、リクエストの処理に関わるアプリケーションのコンポーネント、リクエストの処理中に各コンポーネントが消費する時間幅、およびその他の情報を示す。アプリケーション実行データは、プローブの実行により結果として生じるデータに基づいてエージェント１１２により生成され、その後、エージェント１１２が、生成されたアプリケーション実行データをマネージャ１２０に転送する。一般的に、アプリケーション実行データには、平均的なコンポーネント（例えば、メソッド）の実行時間、毎秒または間隔ごとのコンポーネントの呼び出し率、コンポーネントの呼び出し回数、開始したが終了していない間隔ごとのコンポーネントの呼び出し回数を示す同時実行のメトリック、および呼び出しを開始した間隔ごとのコンポーネントの呼び出し回数が特定の閾値を超えたコンポーネントの呼び出し回数を示すストール状態のメトリックなどの情報が含まれる。また、アプリケーション実行データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定する。アプリケーション実行データは、管理されたアプリケーション１５１によって処理されている特定のトランザクションにリンクされることに留意されたい。
【００３１】
アプリケーション実行データは、データを集約したり、データを格納したり、インタフェースまたは他のユーザインタフェース１１２を介してオペレータにデータを提供するなど、ステップ５０６でマネージャ１２０により処理されて報告される。
【００３２】
図６は、ダイグラフに基づいて依存マップ２００を表示するための処理６００の一実施形態を示すフローチャートである。処理６００は、システム１００のようなシステムで使用される。図２〜４は、処理６００を使用して表示される依存マップ２００のいくつかの例を示す。ステップ６０２で、依存データが収集される。依存データは、エージェント１１２によって収集される。一実施形態では、依存データは、ソフトウェアコンポーネントを記述する頂点データとソフトウェアコンポーネント間の依存関係を記述する辺データを含む。
【００３３】
依存データは、管理されたアプリケーション１５１（例えば、管理されたアプリケーションＡ １５１Ａ）の多数の異なるインスタンスのデータを含むことに留意されたい。例えば、システム１００は、管理されたアプリケーションＡ  １５１Ａの異なるインスタンスをそれぞれ実行する多くのサーバを有することがある。場合によっては、単一のサーバが、管理されたアプリケーションＡ  １５１Ａの異なるインスタンスを実行することがある。同様のファクターが、管理されたアプリケーションＢ  １５１Ｂにも適用される。また、トランザクションの特定のタイプについても多数の異なるインスタンスが存在することに留意されたい。前述のように、トランザクションＢＴＡ１について多数の異なるインスタンスが存在する場合があり、別々のユーザが購入を行うことに対応している。このように、依存データは、トランザクションの各タイプの多数の異なるインスタンスに対するデータを含み得る。ステップ６０２の一実施形態のさらなる詳細を以下に述べる。
【００３４】
ステップ６０４で、依存データは、トランザクションを処理するソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するために集約される。いくつかの実施形態では、対になるソフトウェアコンポーネント間の辺と同様に、有向グラフは、種々のソフトウェアコンポーネント（例えば、サーブレット、ＥＪＢ、デバイスドライバ、ＤＢＭＳ、ソケットなど）に対応する頂点を含む。依存データを集約することは、依存データにおける重複する頂点を探すことと、ソフトウェアコンポーネントの重複データを表す単一の「論理的頂点」を生成すること、を伴う。同様に、依存データを集約することは、依存データにおける重複する辺を探すことと、ソフトウェアコンポーネント間の依存関係に対する重複データを表す単一の「論理的辺」を生成すること、を伴う。ステップ６０４の一実施形態のさらなる詳細を以下に述べる。
【００３５】
ステップ６０６では、依存マップ２００が有向グラフに基づいて表示される。いくつか例を図２〜４に示す。依存マップ２００は、有向グラフの複雑さを減少させることに留意されたい。例えば、有向グラフのすべての頂点が依存マップ２００で表示される必要はない。同様に、有向グラフのすべての辺も依存マップに表示される必要はない。典型的な一例として、管理されたアプリケーション１５１のサマリーは、管理されたアプリケーション１５１の内部のコンポーネントを示すことなく表示可能である。
【００３６】
図７は、依存データを収集する処理７００の一実施例を示すフローチャートである。処理７００は、処理６００のステップ６０２の一実施形態である。ステップ７０２で、トランザクショントレースを開始する。一実施形態では、特定のソフトウェアコンポーネントがトランザクションの呼び出しスタック内の最初の構成要素として特定されるときに、トランザクショントレースを開始する。これらのソフトウェアコンポーネントは、いくつかの点で注目すべきものとして特定されるものである。いくつかの実施形態では、トランザクショントレースはトランザクションの境界を捉える。境界の下限値は、呼び出しスタック内で注目される最初の構成要素によって定義される。注目される構成要素は、一例として、注目されると考えられるサーブレットなどのコンポーネントのタイプを指定することによって事前に定義され得る。一実施形態では、上側の境界は、ＪＶＭ（Java Virtual Machine）の外部のトランザクション呼び出しによって制御されることがある。スタック内の下側の境界は、フロントエンドと呼ばれる一方で、上側の境界は、バックエンドと呼ばれる。一例として図１を参照すると、モジュールＡ１はフロントエンドとなり、モジュールＡ２はバックエンドとなる。
【００３７】
ステップ７０４では、トランザクションを処理するソフトウェアコンポーネント間の依存関係を表す依存データを１以上のエージェント１１２が収集する。例えば、依存データはフロントエンドとバックエンドとの間の辺を含む。図１のトランザクションＢＴＡ１を参照すると、モジュールＡ１とモジュールＡ２との間の矢印は、そのような辺である。開始辺も、また外部エンティティとフロントエンドの頂点との間に生成される。図１を参照すると、ネットワーク１０４（またはWebブラウザ１０２）は、外部頂点であると考えられる。「外部頂点」としてネットワーク１０４を参照する理由の１つは、アプリケーションサーバ１１０ａ上の仮想マシン（例えばＪＶＭ）の外部に存在するからである。このように、開始辺は、ネットワーク１０４とモジュールＡ１の間に存在する。また、モジュールＡ２とデータベースＸ  １１３との間にも辺が存在する。１以上のエージェントが単一のトランザクションに対する依存データを収集するということに留意されたい。例えば、エージェント１１２ａおよび１１２ｂの両方がトランザクションＢＴＡ２に対するデータを収集する。
【００３８】
ステップ７０６では、エージェント１１２は、依存データがマネージャ１２０に提供されるべきか否かを判定する。依存データは、任意の時間に任意の頻度で提供される。依存データは、マネージャ１２０からのリクエストに応答して、あるいは、リクエストなしで提供される。依存データがマネージャ１２０に提供されるものでないのであれば、処理７００はステップ７０２に戻って別のトランザクションのトレースを開始する。別のトランザクションをトレースすることは、トランザクションＢＴＡ１の別のインスタンスをトレースすること、または別のタイプのトランザクション（例えば、ＢＴＡ２）をトレースすることである。
【００３９】
ある時点で、依存データは、エージェント１１２からマネージャ１２０へ送信される（ステップ７０８）。前述のとおり、依存データは、辺と頂点を記述する。ステップ７１０において、マネージャ１２０は依存データを格納する。一実施形態では、マネージャ１２０は、到着タイムスタンプを依存データに付加する。一実施形態では、エージェント１１２は、マネージャ１２０に送信する前に収集タイムスタンプ（例えば、依存データが収集された時間）をデータに付加する。マネージャ１２０は、多数のエージェント１１２から依存データを受け取ることに留意されたい。様々なエージェント１１２からのこのデータは結合される。
【００４０】
前述したように、エージェント１１２は、依存データを収集してマネージャ１２０に送信する。表１は、頂点について収集され得る依存データの例を示している。前述のとおり、頂点はソフトウェアコンポーネントに対応する。この例では、各頂点は、１セットの「頂点プロパティ」を有する。
【００４１】
【表１】
0005431430.tif 000002
【００４２】
タイププロパティについては、開始ノードはトランザクションの開始時のコンポーネントである。開始ノードは、アプリケーションサーバ１１０の内部、またはサーバ１１０の外部に存在し得る。「外部頂点」の抽象レベルは、アプリケーションサーバ１１０の外部にある少なくともいくつかのコンポーネントに付与される。一実施形態では、管理されたアプリケーション１５１を外部から呼び出すコンポーネントが「外部頂点」である。ただし、データベースなどのバックエンドの外部コンポーネントは、外部頂点とみなされる必要はない。
【００４３】
表２は、辺に対して収集され得る依存データのタイプの例を示す。前述のように、トランザクションが処理される場合、辺データは、ソフトウェアコンポーネント（または頂点）間の依存関係に付随する。この例では、各辺は、１セットの「辺プロパティ」を有する。
【００４４】
【表２】
0005431430.tif 000003
【００４５】
以下に辺プロパティの例について詳しく述べる。図１を参照すると、モジュールＡ１とモジュールＡ２との間の辺は、次のように記述される。頭部頂点は、モジュールＡ２である。尾部頂点は、モジュールＡ１である。辺の所属先は、管理されたアプリケーション１５１  Ａである。頭部頂点の所属先は、管理されたアプリケーションＡ  １５１Ａである。尾部頂点の所属先は、管理されたアプリケーションＡ  １５１Ａである。
【００４６】
別の例としては、モジュールＡ３とWebサーバ１０９との間の辺は、次のように記述される。頭部頂点は、Webサーバ１０９である。尾部頂点は、モジュールＡ３である。辺の所属先、頭部頂点の所属先および尾部頂点の所属先は、すべて管理されたアプリケーションＡ  １５１Ａである。
【００４７】
さらに別の例として、Webサービス１０９とモジュールＢ１との間の辺は、次のように記述される。頭部頂点は、モジュールＢ１である。尾部頂点は、Webサーバ１０９である。辺の所属先、頭部頂点の所属先および尾部頂点の所属先は、すべて管理されたアプリケーションＢ  １５１Ｂである。いくつかの実施形態では、データのもう１つのセット（セカンドセット；a second set of data）は、この辺を形成する。セカンドセットは、管理されたアプリケーションＡ  １５１Ａを辺の所属先および尾部頂点の所属先として、頭部頂点の所属先である管理されたアプリケーションＡ  １５１Ａとともにリストアップする。この辺に対するデータのセカンドセットの１つの理由は、依存マップ２００を異なるアプリケーション１５１の観点から表示させることにある。この例では、辺の情報は、管理されたアプリケーションＡ  １５１Ａが辺の所属先であるときに、アプリケーションＡ  １５１Ａの観点から依存マップ２００を表示するのに使われる。同様の理由付けが、管理されたアプリケーションＢ  １５１Ｂに対しても依存マップ２００を表示するために適用される。
【００４８】
エージェント１１２は、「外部頂点」のように、いくつかのコンポーネントへの特別な名称の割り当てが可能であることに留意されたい。例えば、最後の例では、Webサービス１０９のソフトウェアコンポーネントが、「外部頂点」と称される。モジュールＡ１にリクエストを送信するネットワーク１０４（またはWebブラウザ１０２）もまた「外部頂点」と呼ばれる。この命名法の１つの理由は、アプリケーション１５１を呼び出す実際のソフトウェアコンポーネントがユーザに注目されないことにある。したがって、「外部頂点」などのより一般的な用語で十分な詳細を提供する。
【００４９】
図８は、ダイグラフのデータ構造８００の一実施形態のブロック図である。ダイグラフのデータ構造８００は、エージェント１１２により収集された依存データに基づいてマネージャ１２０によって形成される。ダイグラフ８００は、頂点のセット（ノードとも呼ばれる）および辺のセットを含む。各辺は、別個の頂点の一対を表現する。有向グラフの辺は、順序付けられた対である。
【００５０】
ダイグラフのデータ構造８００の一番下から始めると、そこには、物理的頂点を集めたものおよび物理的辺を集めたものが存在する。これらは、エージェント１１２によって収集された実際の依存データである。図示されているように、物理的頂点と物理的辺との間（辺に対して順序付けられたコンポーネントの対に対応する）には、２：１の関係がある。次の上位レベルには、論理的頂点の集まりと論理的辺の集まりがある。一般的には、特定の物理的頂点について、すべてのインスタンスに対応する１つの論理的頂点が存在し得る。一般的には、特定の物理的辺について、すべてのインスタンスに対応する１つの論理的辺が存在し得る。辺に対して順序付けられたコンポーネントの対に対応して、論理的頂点と論理的辺との間には２：１の関係がある。以下に述べるように、依存データは、物理的頂点（生の依存データ）からの論理的頂点を形成するために集約される。同様に、依存データは、物理的辺から論理的辺を形成するために集約される。論理的頂点と物理的頂点（論理的辺と物理的辺も同様）との間には１：Ｎの関係があることに留意されたい。
【００５１】
表１で述べたように、頂点には、種々のプロパティ、例えば、「タイプ」、「抽象レベル」や「階層レベル」などがある。論理的頂点の上位にあるダイグラフ８００の次の上位レベルは、これらのプロパティのためのコンテナである。例えば、「サーブレット」、「ＥＪＢ」および／または「データベース」に対する個々のタイプのコンテナがある。別の例として、「クラス」、「クラスメソッド」に対する個々の階層レベルのコンテナがある。別の例として、頂点は、「抽象レベル」に基づいて分類される。一実施形態では、「外部頂点」のコンテナがあり、それは、アプリケーションサーバ１１０の外部に存在する少なくとも一部のコンポーネントに対するものである。一実施形態では、管理されたアプリケーション１５１を外部から呼び出すコンポーネントは「外部頂点」である。ただし、データベースのようなバックエンドの外部コンポーネントは、外部頂点として考慮する必要はない。これらのプロパティは例であり、他のプロパティも使用され得る。また、プロパティが異なる順序（例えば、異なるレベル）で配置される可能性があることにも留意されたい。
【００５２】
最上位レベルにおけるダイグラフのデータ構造８００は、依存マップの頂点および依存マップの辺をセットで含んでいる。依存マップは、依存マップの頂点と依存マップの辺とに基づいて描かれる。例えば、図２〜４に見られる種々の構成要素は、依存マップの頂点と依存マップの辺とに基づくものである。
【００５３】
依存マップの頂点は、類似した物理的頂点の集まりを表す。物理的頂点は、頂点の所属先とプロパティ（例えば、カテゴリ、階層レベル、抽象レベル、タイプ、名称など）に基づいて互いにグループ化される。依存マップの辺は、依存マップの頂点の順序付けられた対である。それぞれの依存マップの辺は、論理的辺の集まりを維持することによって元の物理的辺の関係を維持する。
【００５４】
図９は、ダイグラフを作成するときに辺を処理するための処理９００の一実施形態を示すフローチャートである。処理９００は、マネージャ１２０によって実行されるが、別のコンピュータノードが処理９００を実行してもよい。一般的に、処理９００は、ダイグラフを形成するために依存データを集約することを含む。処理９００では、「物理的」および「論理的」という用語が使用される。処理９００で、「物理的」という用語は、収集されるデータを指す。例えば、「物理的頂点」および「物理的辺」という用語は、エージェント１１２によって収集されるデータを指すために使用される。依存データには、所定の物理的頂点についての多くのインスタンスが存在することに留意されたい。例えば、依存データには、モジュールＡ１についての多くのインスタンスが存在する。同様に、依存データには、所定の物理的辺の多くのインスタンスが存在する。処理９００で、「論理的」という用語は、物理的頂点や辺を表すダイグラフの中で作成されたノードを示す。所定の物理的頂点のすべてのインスタンスに対して、単一の論理的頂点が存在することに留意されたい。例えば、モジュールＡ１について単一の論理的頂点が存在する。同様に、所定の物理的辺のすべてのインスタンスに対して、単一の論理的辺が存在する。処理９００は、ユーザのリクエストに応答して実行される。ユーザは、依存データが特定のアプリケーションまたはトランザクションの観点から示されることを要求する。図２０４にこの例をいくつか示す。
【００５５】
処理９００は、ユーザが依存マップ２００を表示するためにリクエスト中で特定したアプリケーションまたはトランザクションが有する辺を処理する。ステップ９０２では、処理するための依存データに物理的辺が他に存在するか否かの判定が行われる。他に存在する場合、次の物理的辺はステップ９０４で依存データからアクセスされる。本明細書で述べたように、辺は、頭部頂点と尾部頂点とにより記述される。ステップ９０６では、マネージャ１２０は、頭部頂点が既に検出されているか否かを判定する。換言すると、マネージャ１２０は、ダイグラフが頭部頂点についての論理的頂点を既に有するか否かを判定する。そうでない場合には、ステップ９０８において、新しい論理的頂点が当該頭部頂点のためにダイグラフ中で作成される。一実施形態では、マネージャ１２０は、依存データの頭部頂点に対して１以上のプロパティを調べる。例えば、表１を参照すると、タイプ、名称、所属先、階層レベル、および抽象レベルというような１以上のプロパティが、既にダイグラフに存在する論理的頂点と比較される。これらのプロパティは、例示であることに留意されたい。
【００５６】
頭部頂点が既に検出されている場合には、ダイグラフに新しい論理的頂点を作成する必要はない。ただし、頭部頂点のこのインスタンスに関する情報は、ステップ９１０においてダイグラフに付加される。例えば、頭部頂点のこのインスタンスは、エージェント１１２が収集したデータの時間、またはマネージャ１２０が受信したこのインスタンスを含むデータの時間など、それに関係付けられた時間情報を有することがある。この時間情報は、ダイグラフに付加され得る。時間情報を含む１つの理由は、いくつかの実施形態では、依存マップは依存データの存在時間に基づいて表示されることである。例えば、ユーザは、特定のタイムスライスに発生したトランザクションに注目する場合がある。一実施形態では、論理的頂点は、検出された頭部頂点の各インスタンスを含むバケットを有する。様々なインスタンスは、時間情報に基づいて順序づけられる。
【００５７】
頭部頂点の処理後、尾部頂点が処理される。尾部頂点の処理は、頭部頂点と類似している。ステップ９１２では、マネージャ１２０は、尾部頂点が既に検出されているか否かを判定する。換言すれば、マネージャ１２０は、ダイグラフが尾部頂点についての論理的頂点を既に有するか否かを判定する。そうでない場合、ステップ９１４において、新しい論理的頂点が当該尾部頂点のためにダイグラフ中で作成される。一実施形態では、マネージャ１２０は、依存データの尾部頂点に対して１以上のプロパティを調べる。尾部頂点が既に検出されている場合には、ダイグラフに新しい論理的頂点を作成する必要はない。ただし、尾部頂点のこのインスタンスに関する情報は、ステップ９１６においてダイグラフに付加される。一実施形態では、論理的頂点は検出された尾部頂点の各インスタンスを含むバケットを有する。異なるインスタンスは、時間情報に基づいて順序づけられる。
【００５８】
尾部頂点の処理後、辺が処理される。ステップ９１８では、マネージャ１２０は、辺が既に検出されているか否かを判定する。換言すると、マネージャ１２０は、ダイグラフが辺についての論理的辺を既に有するか否かを判定する。本明細書に記載したように、辺は、尾部頂点と頭部頂点の順序付けられた対で記述される。一実施形態では、マネージャ１２０は、頭部と尾部のプロパティを有する辺が検出されたか否かを判定するため、辺のプロパティを調べる。ただし、別の技術を辺の等価性を調べるために使用することもできる。
【００５９】
辺が検出されていない場合、ステップ９２０において、新しい論理的辺が当該辺のためにダイグラフ中で作成される。この論理的辺は、論理的頭部と論理的尾部との間に作成される。辺が既に検出されている場合には、ダイグラフに新しい論理的辺を作成する必要はない。ただし、辺のこのインスタンスに関する情報は、ステップ９２２においてダイグラフに付加される。例えば、辺に関係付けられた時間情報が付加されることがある。一実施形態では、論理的辺は、検出された辺の各インスタンスを含むバケットを有する。異なるインスタンスは、時間情報に基づいて順序づけられる。一実施形態では、格納される辺は、それを有しているエージェントに基づいてソートされる。
【００６０】
図１０Ａおよび１０Ｂは、ダイグラフを形成するときに頂点を処理する処理１０００の一実施形態のフローチャートを示す。いくつかの実施形態では、論理的頂点は、タイプ、抽象レベル、階層などのプロパティを有することを想起されたい。処理１０００は、ダイグラフデータ構造８００にこれらのプロパティを付加する詳細を記述する。一般的に、処理１０００は、単一の頂点の処理を記述する。したがって、処理１０００は、各頂点（尾部および頭部の両方）のために繰り返される。処理１０００は、マネージャ１２０によって実行されるが、別のノードも処理１０００を実行し得る。
【００６１】
ステップ１００２では、マネージャ１２０は、依存データから物理的頂点にアクセスする。ステップ１００４では、物理的頂点は、論理的なダイグラフ８００に付加される。
【００６２】
処理１０００で、頂点は、「フロントエンド」、「バックエンド」および「バックエンドファミリのカテゴリ」に分類される。処理は、物理的頂点のあるカテゴリに基づいて続けられる。フロントエンドは、一般的に、トランザクションの開始（または前面）またはそれに近いコンポーネントを参照する。例えば、モジュールＡ１は、トランザクションＢＴＡ１のためのフロントエンドである（図１を参照のこと）。バックエンドは、一般的に、トランザクションの背面またはそれに近いコンポーネントを参照する。一実施形態では、バックエンドは、パフォーマンスメトリクスの可用性に応じて、２つのカテゴリに分けられる。例えば、モジュールＡ２がデータベースＸ  １１３を呼び出すとき、呼び出しのためのパフォーマンスメトリクスがあることがある。したがって、データベースＸ  １１３は、「バックエンドのカテゴリ」と呼ばれることがある。一方、モジュールＡ３がモジュールＢ１を呼び出すWebサービス１０９を呼び出すとき、Webサービス１０９への呼び出しのためのパフォーマンスメトリクスがあるが、モジュールＢ１を呼び出すためのものではない。したがって、Webサービス１０９は、「バックエンドファミリのカテゴリ」と呼ばれることがある。
【００６３】
ステップ１００６は、物理的頂点がフロントエンドのカテゴリに属しているか否かを判定するテストである。コンポーネントがどのカテゴリに属するかを判定するために使用される１つのファクターは、リストを調べることである。例えば、リストは、あるタイプのソフトウェアコンポーネントが「フロントエンド」と考えられるということを特定する。例えば、サーブレットはフロントエンドであると考えられる。データベースは、バックエンドであると考えられる。他のプロパティも、またカテゴリを判定するために使用され得る。一実施形態では、ユーザは、種々のコンポーネントのカテゴリを定義することができる。物理的頂点がフロントエンドのカテゴリにあると仮定すると、マネージャ１２０は、物理的頂点の所属先のための依存マップの頂点が存在するか否かを判定する。もし存在しない場合には、依存マップの頂点は、ステップ１０１０で作成される。その後、物理的頂点は、ステップ１０１２において依存マップの頂点に付加される。依存マップの頂点が物理的頂点の所属先のために既に存在している場合には、ステップ１０１０はスキップされる。
【００６４】
ステップ１０１４では、マネージャ１２０は、物理的頂点の親が存在するか否かを判定する。頂点の１つのプロパティは、階層レベルになっていることを想起されたい（例えば、クラス、クラスメソッド）。階層レベルは、有向グラフに既に存在する親があるか否かを判定するために検査される。親が存在する場合には、マネージャ１２０は、ステップ１０１６において、親の物理的頂点のための論理的頂点が存在するか否かを判定する。親の物理的頂点のための論理的頂点が存在しない場合には（ステップ１０１６はＮＯ）、ステップ１０１７において、親の頂点が依存マップの頂点に付加される。ステップ１０１６がＹＥＳの場合には、ステップ１０１８にて、以下で説明する処理が続行される。
【００６５】
物理的頂点のための親が存在しない場合（ステップ１０１４はＮＯ）、ステップ１０１８において、マネージャは、物理的頂点の階層レベルのためのコンテナが存在するか否かを判定する。存在しない場合には、マネージャ１２０は、階層のコンテナを作成し（ステップ１０２０）、階層のコンテナに物理的頂点を付加する（ステップ１０２２）。一方、コンテナが物理的頂点の階層レベルのために既に存在する場合には、新しいコンテナは作成される必要はなく（ステップ１０２０はスキップされる）、ステップ１０２２において既に存在している階層のコンテナに物理的頂点が付加される。
【００６６】
次に、抽象レベルの処理が実行される。マネージャ１２０は、ステップ１０２４において、物理的頂点の抽象レベルのためのコンテナが存在するか否かを判定する。存在しない場合には、マネージャ１２０は、抽象レベルのコンテナを作成し（ステップ１０２６）、抽象レベルに物理的頂点を付加する（ステップ１０２８）。一方、コンテナが物理的頂点の抽象レベルのために既に存在する場合には、新しいコンテナは作成される必要はなく（ステップ１０２６はスキップされる）、ステップ１０２８において既に存在している抽象レベルのコンテナに物理的頂点が付加される。
【００６７】
次に、タイプの処理が実行される。マネージャ１２０は、ステップ１０３０において、物理的頂点のタイプのためのコンテナが存在するか否かを判定する。存在しない場合には、マネージャ１２０は、タイプのコンテナを作成し（ステップ１０３２）、タイプのコンテナに物理的頂点を付加する（ステップ１０３４）。一方、コンテナが物理的頂点のタイプのために既に存在する場合には、新しいコンテナは作成される必要はなく（ステップ１０３２はスキップされる）、ステップ１０３４において既に存在しているタイプのコンテナに物理的頂点が付加される。
【００６８】
次に、論理的頂点の処理が実行される。マネージャ１２０は、ステップ１０３６において、物理的頂点の名称が付いた論理的頂点が存在するか否かを判定する。存在しない場合には、マネージャ１２０は、論理的頂点を作成し（ステップ１０３８）、論理的頂点に物理的頂点を付加する（ステップ１０４０）。一方、論理的頂点が物理的頂点のために既に存在する場合には、新しい論理的頂点は作成される必要はなく（ステップ１０３８はスキップされる）、ステップ１０４０において既に存在している論理的頂点に物理的頂点が付加される。これで、物理的頂点がフロントエンドのカテゴリに存在する場合の処理を終了する。
【００６９】
物理的頂点がバックエンドファミリのカテゴリにある場合には（ステップ１０５０はＹＥＳ）、処理は以下の通りである。マネージャ１２０は、頂点の所属先とバックエンドのファミリ名のための依存マップの頂点が既に存在するか否かを確認する（ステップ１０５２）。存在しない場合には、マネージャ１２０は、ステップ１０５４でそのような依存マップの頂点を作成する。次に、処理１０００は、ステップ１０１２で依存マップの頂点に物理的頂点を付加する。依存マップの頂点が既に存在する場合には、処理１０００は、ステップ１０１２に進んで依存マップの頂点に物理的頂点を付加する。そして、処理１０００は、フロントエンドのカテゴリのために、上述したように続く。
【００７０】
物理的頂点がバックエンドファミリのカテゴリに存在しない場合には（ステップ１０５０はＮＯ）、マネージャ１２０は、物理的頂点がバックエンドのカテゴリに存在するか否かを判定する（ステップ１０６０）。存在する場合には、マネージャ１２０は、頂点のタイプと名称のための依存マップの頂点が既に存在するか否かを判定する（ステップ１０６２）。存在しない場合には、マネージャ１２０は、ステップ１０６４でそのような依存マップの頂点を作成する。次に、処理１０００は、ステップ１０１２で依存マップの頂点に物理的頂点を付加する。依存マップの頂点が既に存在する場合には、処理１０００は、ステップ１０１２に進んで依存マップの頂点に物理的頂点を付加する。そして、処理１０００は、フロントエンドのカテゴリのために上述したように続く。物理的な頂点がバックエンドのカテゴリに存在しない場合には（ステップ１０６０はＮＯ）、処理は終了する。
【００７１】
一実施形態では、依存マップ２００は、依存データの存在時間に基づいて表示される。例えば、いくつかのコンポーネントおよび／または辺のデータがユーザの指定時間の範囲外にある場合には、依存マップの中のコンポーネントおよび／または辺の一部が灰色で表示され得る。図１１は、依存データの存在時間に基づいて依存マップを表示する処理１１００の一実施形態のフローチャートである。処理１１００の一実施形態では、有向グラフは入力であり、時間が経過したとマークされる特定の頂点および／または辺を持つ有向グラフは出力である。
【００７２】
ステップ１１０２では、時間範囲が受信される。一実施形態では、ユーザは、インタフェース１２２などのユーザインタフェースに時間範囲を入力する。ユーザは、また、１以上の管理されたアプリケーション１５１および／または依存データが１以上のトランザクションを特定する。
【００７３】
一般的に、処理１１００は、入力の有向グラフから辺および頂点を処理する。ステップ１１０４において、さらに辺が処理されるべきであるか否かの判定が行われる。もしそうであれば、次の辺は、ステップ１１０６において有向グラフからアクセスされる。例えば、有向グラフに格納された時間情報がアクセスされる。時間情報は、エージェント１１２が物理的辺のためにデータを収集した時間、および／または、マネージャ１２０が依存データを格納した時間、を含むことを想起されたい。ただし、時間情報は、これらの例に限定されるものではないことに留意されたい。
【００７４】
ステップ１１０８においては、辺の存在時間がステップ１１０２で受信された期間外であるか否かの判定が行われる。例えば、ユーザが最後の２４時間以内のデータを見たいだけの場合に、２４時間以前に収集された辺のデータであれば、その辺はステップ１１１０において灰色にマークされる。灰色にマークすることは、依存マップが表示されるときに、辺が灰色で表示されるように辺がマークされるということである。灰色でマークするとは、存在時間が古いときの辺のマークの一例で、他の技術を使用することもできることに留意されたい。そうでなければ、ステップ１１１２において、辺は灰色でないようにマークされる。処理１１１０は、すべての辺が処理されるまで処理を続ける。次に、頂点の処理がステップ１１１４で開始される。
【００７５】
ステップ１１１４で、有向グラフにさらに多くの頂点が存在するか否かの判定が行われる。もしそうであれば、その後、次の頂点は、有向グラフからアクセスされる。例えば、頂点に関する情報は、頂点を灰色にするか否かの判定を行い得る有向グラフからアクセスされる。一実施形態では、当該判定は、頂点に接続されている辺が灰色にされているか否かに基づく。
【００７６】
ステップ１１１８では、頂点に接続されているすべての辺が灰色にマークされているか否かについて判定が行われる。もしそうであれば、ステップ１１２０において、頂点は灰色にマークされる。そうでなければ、ステップ１１２２において、頂点は灰色でないようにマークされる。頂点を灰色にマークするか否かを判定するために、異なるテストが行われ得ることに留意されたい。すべての頂点が処理された後、処理１００は終了する。処理１１１０の処理結果は、灰色／灰色ではない、いずれかが注釈された辺および頂点を有する有向グラフとなる。したがって、依存関係が適切に表示される。上述のように、灰色表示することは、ある意味で依存データの時間経過を示すためのやり方でマークする一例である。
【００７７】
本明細書で開示される一実施形態は、ディスプレィの画面上に依存マップを表示するために、装置に実装される方法（コンピュータに実装される方法）を含む。当該方法は、ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること；ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように上記のデータを集約すること；有向グラフに基づいて、ディスプレィの画面上に依存マップを表示すること、を有する。この依存マップは、トランザクションが処理されるときの依存関係を示す。
【００７８】
本明細書で開示される一実施形態は、１以上のプロセッサを有するシステムを含み、コンピュータで読み取り可能な記憶装置が１以上のプロセッサに結合されている。コンピュータで読み取り可能な記憶装置は、それに格納されたコンピュータで読み取り可能な命令を有し、１以上のプロセッサ上で実行されると、１以上のプロセッサにシステム内のソフトウェアコンポーネントによって処理されるトランザクションのトレースを開始させ；トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を記述するデータを収集し；トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように依存関係を記述するデータを集約し；トランザクションが処理されるときのソフトウェアコンポーネント、またはソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を記述する有向グラフに基づいて依存マップを表示する。
【００７９】
本明細書に開示される一実施形態は、「ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること；ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように上記のデータを集約すること；および、有向グラフに基づいてディスプレィの画面上に依存マップを表示することを有する。ここで、その依存マップは、トランザクションが処理されるときのソフトウェアコンポーネントのセットまたは複数のソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を示す。」方法：を実行するための少なくとも１つのプロセッサをプログラムするためのコンピュータで読み取り可能な命令を格納する、コンピュータで読み取り可能な記憶装置を含む。
【００８０】
以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。
【図１】
0005431430.tif 000004
【図２】
0005431430.tif 000005
【図３】
0005431430.tif 000006
【図４】
0005431430.tif 000007
【図５Ａ】
0005431430.tif 000008
【図５Ｂ】
0005431430.tif 000009
【図６】
0005431430.tif 000010
【図７】
0005431430.tif 000011
【図８】
0005431430.tif 000012
【図９】
0005431430.tif 000013
【図１０Ａ】
0005431430.tif 000014
【図１０Ｂ】
0005431430.tif 000015
【図１１】
0005431430.tif 000016