(57)【要約】      （修正有）【課題】アプリケーションを介してフローを追跡することによってコンピュータシステムにおける問題を診断する。【解決手段】ウェブブラウザ１０２からのユーザからのリクエストは、ネットワーククラウド１０４を介して受信され、任意のコンピューティングデバイス１０６、１１０および１１４に送られる。コンピューティングデバイス上のエージェントソフトウェアＡ１（１０８）、Ａ２（１１２）およびＡ３（１１６）は、コンピューティングデバイス上で実行されている、アプリケーション、ミドルウェアまたはその他のソフトウェアから、情報を収集する。エージェントは、マネージャ１２０と通信してデータをまとめ最適化する。マネージャは、エージェントから受信したデータに基づく情報をユーザインタフェース１２２に表示し、データベース１１８に格納する。【選択図】図１
2012221499.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを介してフローをたどるためにコンピュータに実装される方法であって、その方法は：
アプリケーションに関与するトランザクション（３０４、３０６、３０８、３１０、３１２）の中で呼び出される複数のソフトウェアコンポーネントを特定する複数の頂点レコード（頂点、８００、８０２、８０４、８０６、８１２、８２０、８２４）を提供すること；
頂点レコードにリンクされており、ソフトウェアコンポーネント間の呼び出しを特定する複数の辺レコード（辺、８２２）を提供すること； 
辺レコードにリンクされており、複数のトランザクションを特定する複数のトランザクションレコード（トランザクション）を提供すること；トランザクションレコードはトランザクションの階層を表し、トランザクションの階層はトランザクションの階層の一つのレベルにおけるトランザクションおよびトランザクションの階層の第１の高位レベルにおけるトランザクションのグループ分けを有する；
ユーザインタフェースディスプレィ（１２２）に有向グラフ（５００、５０５、５２０、５２５、５３０、５４０、５５０、５５５、５５６、５６０、５７０、５９０、６１０）を提供すること；有向グラフは、頂点レコードに基づく複数の頂点（３１０、３１２、３０４、３０６、３０８、３４０、３４２、３４４、３２０、３５０、３２２、３６０、３６２、３２４、３２１、３４１、３４３、３４５、３４７、３４９、３５１、３４９、３５１、３２７、３２６、３３４、３３２、３２９、３２８、３３６、３３１、３３０および３３８）、および、辺レコードに基づく複数の辺（Ｅｓ１からＥｓ１８）を有し、複数の頂点はトランザクションの階層に従って配置されている；
を有する。
【請求項２】
コンピュータに実装される請求項１の方法であり、
複数のソフトウェアコンポーネントの一つは、複数の異なるエージェント（１０８、１１２、１１６）によって監視されている複数のインスタンスを有し；
複数の異なるエージェントによって監視されている複数のインスタンスを有する複数のソフトウェアコンポーネントの一つに対して、辺レコードは、複数の異なるエージェントのための異なる複数の頂点レコード、および複数の異なる頂点レコードの集合体を表す共通頂点レコードを有する。
【請求項３】
コンピュータに実装される請求項２の方法であり、
有効グラフにおける複数の頂点は、共通頂点レコードに基づいており、複数の異なるエージェントに亘る集合体に基づいてアプリケーションを介してフローをユーザが見ることを許容する。
【請求項４】
コンピュータに実装される請求項３の方法であり、
有向グラフにおける複数の頂点は、複数の異なる頂点レコードの一つに基づいており、アプリケーションを介して、複数の異なるエージェントの一つに対して特有であるフローをユーザが見ることを許容する。
【請求項５】
コンピュータに実装される請求項４の方法であり、
複数の頂点の一つが有向グラフにおいてトランザクションの階層の一つのレベルに関連付けられて特定され、複数の頂点のもう一つが有向グラフにおいてトランザクションの階層の第１の高位レベルに関連付けられて特定されるように、複数の頂点がトランザクションの階層に従って配置される。
【請求項６】
コンピュータに実装される請求項１から５のいずれか一項の方法であり、
トランザクションレコードの一つにリンクされており、トランザクションの前記グループ分けを特定する業務トランザクションレコード（業務トランザクション）を提供すること；
トランザクションの階層の第１の高位レベルよりも上でトランザクションの階層の第２の高位レベルのトランザクションの階層を表し、かつトランザクションの階層の第１の高位レベルにおいてトランザクションのグループ分けを特定する業務トランザクションレコードにリンクされている、業務サービスレコード（業務サービス）を提供すること；
をさらに有する。
【請求項７】
コンピュータに実装される請求項１から６のいずれか一項の方法であり、
ソフトウェアコンポーネントを監視するエージェント（１０８、１１２、１１６）からのデータを受信すること；そのデータはソフトウェアコンポーネントの一つに対する情報のフィールドを有し、頂点レコードを提供することは情報のフィールドと一致する頂点のレコードをモデルが有するか否かを判断することを有し、そしてモデルが頂点レコードを有しない場合にはソフトウェアコンポーネントの一つを表すモデルにおける情報のフィールドと一致する頂点のレコードを提供すること、をさらに有し、辺レコードおよびトランザクションレコードを提供することは、情報のフィールドに基づく。
【請求項８】
コンピュータに実装される請求項７の方法であり、モデルが頂点レコードを有するか否かを決定することを含むモデルが頂点レコードを有するか否かを決定することは、
ソフトウェアコンポーネントの名称であって情報のフィールドと一致する名称（Vertex_Name）；
ソフトウェアコンポーネントの型であって情報のフィールドと一致する型（Vertex_Type_Name）；
情報のフィールドと一致する階層レベル（Hierarchy_level）；
情報のフィールドと一致するエージェントの識別子（Agent_ID）；
を有する。
【請求項９】
コンピュータに実装される請求項１から８のいずれか一項の方法であり、
ソフトウェアコンポーネントの一つは子のコンポーネントで、ソフトウェアコンポーネントのもう一つは関連付けられた親のコンポーネントであり；
頂点レコードの一つは関連付けられた親のコンポーネントのためにあり、頂点レコードのもう一つは子のコンポーネントのためにあり関連付けられた親のコンポーネントの識別子を有し；
有向グラフにおける複数の頂点は、子のコンポーネント、および、関連付けられた親のコンポーネントの親子関係を示す。
【請求項１０】
コンピュータに実装される請求項１から９のいずれか一項の方法であり、
辺レコードの一つは：（ａ）複数の呼び出しの一つの呼び出し元としてソフトウェアコンポーネントの一つを識別する尾部の識別子（Tail_vertex_ID）、（ｂ）呼び出し元から呼び出し先の辺（Ｅｓ１からＥｓ１８）を有向グラフに表示させるために、複数の呼び出しの一つの呼び出し先として別のソフトウェアコンポーネントの一つを識別する頭部の識別子（Head_vertex_ID）、および、（ｃ）呼び出し元のオーナの名称と呼び出し先のオーナの名称を有向グラフに表示させる、呼び出し元のオーナの名称（Tail_owner_ID）、および呼び出し先のオーナの名称（Head_owner_ID）を有する。
【請求項１１】
コンピュータに実装される請求項１から１０のいずれか一項の方法であり、
辺レコードの一つは、名称と値の組を示す辺のプロパティの識別子（Edge_properties）を有し；
頂点レコードの一つは、名称と値の組を示す頂点のプロパティの識別子（Vertex_properties）を有し；
有向グラフは辺のプロパティの識別子および頂点のプロパティの識別子によって示される名称と値の組を使用して提供される。
【請求項１２】
コンピュータに実装される請求項１から１１のいずれか一項の方法であり、
（ａ）辺レコードおよび（ｂ）頂点レコードの一つが、関連付けられたユニフォームリソースロケータをユーザインタフェースに表示させるために、その関連付けられたユニフォームリソースロケータの識別子（Context_URL）を有する。
【請求項１３】
コンピュータに実装される請求項１から１２のいずれか一項の方法であり、
頂点レコードは、型をユーザインタフェースに表示させるためにソフトウェアコンポーネントの型を特定し、型は、少なくとも一つのサーブレット、ＥＪＢ、データベース、データベースソケット、ソケット、ウェブサービス、メッセージサーバおよびＥＪＢクライアントを有する。
【請求項１４】
コンピュータに実装される請求項１から１３のいずれか一項の方法であり、
頂点レコードの一つは、ソフトウェアコンポーネントの階層における関連付けられたレベルを示す識別子（Hierarchy_level）を有し、ソフトウェアコンポーネントの階層は、少なくとも一つのクラス、クラスメソッドの組、プロセスおよびＪＶＭを有し、識別子は頂点のレコードの一つにおける情報の精度を示す。
【請求項１５】
コンピュータに実装される請求項１から１４のいずれか一項の方法であり、実行されるその方法は、
ソフトウェアコンポーネントのための性能メトリックに対するパスを特定するメトリックパスのレコード（Metric_path）を提供すること、をさらに有し、
ソフトウェアコンポーネントを特定する各頂点レコードは、メトリックパスのレコードの一つにリンクされている。
【請求項１６】
コンピュータに実装される請求項１から１５のいずれか一項の方法であり、実行されるその方法は、
ユーザインタフェース表示の使用のために、呼び出しのオーナを特定するオーナのレコード（Edge_owner_ID）をさらに有し、オーナのレコードは辺レコードの一つにリンクされている。
【請求項１７】
コンピュータに実装される請求項１から１６のいずれか一項の方法であり、
トランザクションレコードの一つは、辺の集合がトランザクションの一つを表現すると考慮されるためには特定の順序で発生しなければならないことを示す、辺レコードの順序集合（６００）のレコードにリンクされている。
【請求項１８】
コンピュータに実装される請求項１から１７のいずれか一項の方法であり、複数の異なるエージェントによって監視される複数のインスタンスを有するソフトウェアコンポーネントの一つために、
辺レコードは、複数の異なる頂点レコードに関連付けられた複数の異なる辺レコード、および複数の異なる辺レコードの集合を表し共通の頂点レコードにリンクされている共通の辺レコードを有する。
【請求項１９】
アプリケーションを介してフローをたどるためのシステムであり、
コンピュータで読み取り可能なコードを記憶する記憶装置（２１０、２４０）；および
前記記憶装置と通信するプロセッサ（２３０）を有し、前記プロセッサはコンピュータで読み取り可能な以下のコードを実行する：
アプリケーションに関与するトランザクションの中で呼び出されるソフトウェアコンポーネントを識別する複数の頂点レコード（頂点、８００、８０２、８０４、８０６、８１２、８２０、８２４）を提供するため；
ソフトウェアコンポーネント間の呼び出しを識別する辺レコード（辺、８２２）を提供するため；辺レコードは頂点レコードにリンクされている；
トランザクションを識別し、辺レコードにリンクされている、トランザクションのレコード（トランザクション）を提供するため；トランザクションのレコードはトランザクションの階層を表し、トランザクションの階層はトランザクションの階層の一つのレベルにおけるトランザクションおよびトランザクションの階層の第１の高位レベルにおけるトランザクションのグループ分けを有する；および
ユーザインタフェースディスプレィ（１２２）における有向グラフ（５００、５０５、５２０、５２５、５３０、５４０、５５０、５５５、５５６、５６０、５７０、５９０、６１０）を提供するため；有向グラフは、頂点レコードに基づく頂点（３１０、３１２、３０４、３０６、３０８、３４０、３４２、３４４、３２０、３５０、３２２、３６０、３６２、３２４、３２１、３４１、３４３、３４５、３４７、３４９、３５１、３４９、３５１、３２７、３２６、３３４、３３２、３２９、３２８、３３６、３３１、３３０および３３８）、および、辺レコードに基づく辺（Ｅｓ１からＥｓ１８）を有し、頂点はトランザクションの階層によって配置されている。
【請求項２０】
アプリケーションを介してフローをたどるためのコンピュータプログラム製品は：
コンピュータで読み取り可能なプログラムコードが具現化されている、コンピュータで読み取り可能な記憶媒体（２１０、２４０）を有し、そのコンピュータで読み取り可能なプログラムコードは：
アプリケーションに関与するトランザクションの中で呼び出されるソフトウェアコンポーネントを特定する頂点レコード（頂点、８００、８０２、８０４、８０６、８１２、８２０、８２４）を提供するために構成されたコンピュータで読み取り可能なプログラムコード；
ソフトウェアコンポーネント間の呼び出しを特定する辺レコード（辺、８２２）を提供するために構成されたコンピュータで読み取り可能なプログラムコード；辺レコードは頂点レコードにリンクされている；
トランザクションを特定し、辺レコードにリンクされているトランザクションのレコード（トランザクション）を提供するために構成されたコンピュータで読み取り可能なプログラムコード；トランザクションのレコードはトランザクションの階層を表し、トランザクションの階層はトランザクションの階層の一つのレベルにおけるトランザクションおよびトランザクションの階層の第１の高位レベルにおけるトランザクションのグループ分けを有する；および
ユーザインタフェースディスプレィ（１２２）における有向グラフ（５００、５０５、５２０、５２５、５３０、５４０、５５０、５５５、５５６、５６０、５７０、５９０、６１０）を提供するために構成されたコンピュータで読み取り可能なプログラムコード；有向グラフは、頂点レコードに基づく頂点（３１０、３１２、３０４、３０６、３０８、３４０、３４２、３４４、３２０、３５０、３２２、３６０、３６２、３２４、３２１、３４１、３４３、３４５、３４７、３４９、３５１、３４９、３５１、３２７、３２６、３３４、３３２、３２９、３２８、３３６、３３１、３３０および３３８）および辺レコードに基づく辺（Ｅｓ１からＥｓ１８）を有し、頂点はトランザクションの階層に従って配置されている；
を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティング環境におけるソフトウェアを監視する技術に関する。
【背景】
【０００２】
インターネットの存在が増長するにつれて、イントラネット、エクストラネットなどの他のコンピュータネットワークと同様に、電子商取引、教育、他の分野において多くの新しいアプリケーションをもたらした。組織は、ビジネスやその他目的を行うのにそのようなアプリケーションへの依存を深めており、期待通りの成果を確実に得るために相当の資源を投入している。このような状況のもと、様々なアプリケーションの管理技術が開発されている。
【０００３】
１つのアプローチとして、アプリケーションで呼び出される個々のソフトウェアコンポーネントに関するアプリケーションの実行データを集めることにより、アプリケーションの基礎構造を監視することが挙げられる。このアプローチでは、監視されるシステムに元来、存在するエージェントを用いることができる。例えば、ソフトウェアによる計測を用いることによって、呼び出される個々のコンポーネントを特定するためや、個々のコンポーネントの実行時間のような実行データを得るために、スレッドまたはプロセスがトレースされ得る。コンピュータプログラムが実行するステップの詳細なレコード、またはトレースを得ることをトレーシングという。トレースのタイプの１つにスタックトレースがある。トレースはデバッグにおける補助の役目を果たし得る。
【０００４】
しかし、問題の診断は依然として難しく時間がかかっている。例えば、トランザクションまたはアプリケーションに障害が生じている場合、プロバイダは起きつつある故障とその原因を正確に知りたい。改善された診断技術が必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、コンピュータシステムの少なくとも１つのアプリケーションを介してフローを追跡することによってコンピュータシステムにおける問題を診断するための方法を提供する。
【課題を解決するための手段】
【０００６】
一実施形態では、少なくとも１つのアプリケーションを介してフローを追跡するためのモデルを提供するため少なくとも１つのプロセッサをプログラミングするために、プロセッサで読み取り可能なソフトウェアを有している少なくとも１つの有体の、一時的でないプロセッサで読み取り可能な記憶装置が具現化されて提供される。モデルは、（ａ）少なくとも一つのアプリケーションに関与するトランザクション中で呼び出されるソフトウェアコンポーネントを識別する頂点レコード、（ｂ）ソフトウェアコンポーネント間の呼び出しを識別する辺レコード；辺レコードは頂点レコードにリンクされている、（ｃ）トランザクションを特定し、辺レコードにリンクされているトランザクションレコード；トランザクションレコードはトランザクションの階層を表し、トランザクションの階層はトランザクションの階層の一つのレベルにおけるトランザクションとトランザクションの階層の第１の高位レベルにおけるトランザクションの１以上のグループ分けを有する、（ｄ）複数の異なるエージェントによって監視されている複数のインスタンスを有する少なくとも一つのソフトウェアコンポーネント、および（ｅ）少なくとも一つのソフトウェアコンポーネントのために複数の異なるエージェントによって監視されている複数のインスタンスを有すること；頂点レコードは、複数の異なるエージェントに対する複数の異なる頂点レコードと、複数の異なる頂点レコードの集約を表す共通の頂点のレコードと、を含む。
【０００７】
別の実施形態では、少なくとも１つのアプリケーションを介してフローを追跡するためのモデルを提供するための方法を実行するように少なくとも１つのプロセッサをプログラミングするために、プロセッサで読み取り可能なソフトウェアを有している少なくとも１つの有体の、一時的でないプロセッサで読み取り可能な記憶装置が具現化されて提供される。この方法は、（ａ）少なくとも１つのアプリケーションに関与するトランザクションの中で呼び出されるソフトウェアコンポーネントを監視するエージェントからのデータを受信すること；データは少なくとも１つのソフトウェアコンポーネントに対する情報のフィールドを含む、（ｂ）情報のフィールドと一致する頂点レコードをモデルが含むか否かを判断すること、（ｃ）モデルが頂点レコードを含まない場合には少なくとも１つのソフトウェアコンポーネントを表すためにモデルにおける頂点レコードを提供すること、（ｄ）情報のフィールドに基づいて少なくとも１つのソフトウェアコンポーネントに関与する呼び出しを識別する辺レコードを提供すること、（ｅ）辺レコードを頂点レコードにリンクすること、（ｆ）情報のフィールドに基づいて少なくとも１つのソフトウェアコンポーネントに関与するトランザクションの一つを識別するトランザクションレコードを提供すること、および（ｇ）そのトランザクションレコードを辺レコードにリンクすること、を含む。
【０００８】
別の実施形態では、少なくとも１つのアプリケーションを介してフローを追跡するための方法を実行するように少なくとも１つのプロセッサをプログラミングするために、プロセッサで読み取り可能なソフトウェアを有している少なくとも１つの有体の、一時的でないプロセッサで読み取り可能な記憶装置が具現化されて提供される。この方法は、（ａ）少なくとも１つのアプリケーションに関与するトランザクションの中で呼び出されるソフトウェアコンポーネントを識別する頂点レコードを提供すること、（ｂ）ソフトウェアコンポーネント間の呼び出しを識別する辺レコードを提供すること；辺レコードは頂点レコードにリンクされている、（ｃ）トランザクションを識別するレコードであって辺レコードにリンクされているトランザクションレコードを提供すること；トランザクションレコードはトランザクションの階層を表し、トランザクションの階層は、トランザクションの階層の１つのレベルにおけるトランザクションと、トランザクションの階層の第１の高位レベルにおけるトランザクションの１以上のグループ分けと、を有する、および（ｄ）ユーザインタフェースディスプレィにおいて有向グラフを提供すること；有向グラフは頂点レコードに基づく頂点および辺レコードに基づく辺を含み、それらの頂点は、トランザクションの階層によって配置されている、を含む。
【０００９】
方法に対応して、実行時に、本明細書で提供される方法を実行する命令がエンコードされた記憶媒体を含むシステムおよびコンピュータもしくはプロセッサで読み取り可能な記憶装置が提供される。
【図面の簡単な説明】
【００１０】
【図１】管理されたアプリケーションを含むシステムを示す。
【図２Ａ】トランザクショントレースを開始するためのプロセス［処理］の一実施形態を説明するフローチャートである。
【図２Ｂ】トランザクショントレースを終了するためのプロセス［処理］の一実施形態を説明するフローチャートである。
【図２Ｃ】図１のネットワークのコンピューティングデバイスを示す。
【図３】１以上のアプリケーションの動作を説明する際に使用する階層を示す。
【図４Ａ】トランザクション内で呼び出されるコンポーネントのシーケンスの例における依存関係を示す。
【図４Ｂ１】図４Ａのコンポーネントの１つの可能なシーケンスに基づいて、トランザクション内で呼び出されたコンポーネントのシーケンスのためのトランザクショントレースの例を示す。
【図４Ｂ２】図４Ｂ１のトランザクショントレースの例における待機期間を示す。
【図４Ｂ３】依存性のある計測されたサブシステムのシーケンスのための、合計時間幅、正味の時間幅、待機時間およびサブシステム相互の通信時間を決定する方法を示す。
【図５Ａ】詳細表示において、業務サービスがユーザによって選択された場合におけるサブシステムのユーザインタフェース（ＵＩ）および業務トランザクションを示す。
【図５Ｂ】図５ＡのＵＩに代わるものである概要表示において、業務サービスがユーザによって選択された場合におけるサブシステムのユーザインタフェース（ＵＩ）および業務トランザクションを示す。
【図５Ｃ】ログイン業務トランザクション３０４のためのメトリックを示すホバーボックスを付加した図５Ｂのユーザインタフェースを示す。
【図５Ｄ】認証サービスサブシステム３２２のためのメトリックを示すホバーボックスを付加した図５Ｂのユーザインタフェースを示す。
【図５Ｅ】ログイン業務トランザクション３０４のためのオプションを示すコンテキストメニュー５３２を付加した図５Ｂのユーザインタフェースを示す。
【図５Ｆ】図５Ｅのユーザインタフェースのコンテキストメニュー５３２から起動されるログイン業務トランザクションのマップのユーザインタフェースを示す。
【図５Ｇ】図５Ｅのユーザインタフェースのコンテキストメニュー５３２から起動されるログイン業務トランザクションに一致するトランザクションを検索するユーザインタフェースを示す。
【図５Ｈ】選択された業務トランザクションのコンテキストにおける認証サービスサブシステムに一致するトランザクションを検索するユーザインタフェースを示す。
【図５Ｉ】複数の業務トランザクションのコンテキストにおける認証サービスサブシステムに一致するトランザクションを検索するユーザインタフェースを示す。
【図５Ｊ】ログインのすべてよりも少ないサブシステムが選択された業務トランザクションのインスタンスによって呼び出される、ユーザインタフェースを示す。
【図５Ｋ】図５Ｅのユーザインタフェースのコンテキストメニュー５３２から起動されるログインのための場所を有するユーザインタフェースを示す。
【図５Ｌ】図５Ｅのユーザインタフェースのコンテキストメニュー５３２から起動されるログイン業務トランザクションの正常性メトリックのユーザインタフェースを示す。
【図５Ｍ】頂点３２２と補助領域５６２から「詳細」のタブをユーザが選択した後の図５Ｋのユーザインタフェースを示す。
【図５Ｎ】図５Ｇのユーザインタフェースから起動される選択されたトランザクションのインスタンスのためのトランザクショントレースを示す。
【図６Ａ】少なくとも１つのアプリケーションを介してフローを追跡するためのモデルを示す。
【図６Ｂ】図６Ａのモデルによる頂点レコードの例を示す。
【図６Ｃ】図６Ａのモデルによる辺レコードの例を示す。
【図６Ｄ】図６Ａのモデルによるエージェントレコードの例を示す。
【図６Ｅ】図６Ａのモデルによるメトリックパスレコードの例を示す。
【図６Ｆ】図６Ａのモデルによる辺のオーナのレコードの例を示す。
【図６Ｇ】図６Ａのモデルによるトランザクションのレコードの例を示す。
【図６Ｈ】図６Ａのモデルによる業務トランザクションのレコードの例を示す。
【図６Ｉ】図６Ａのモデルによる業務サービスのレコードの例を示す。
【図７Ａ１】図５Ａにおける有向グラフの詳細表示のための頂点のテーブルの例を示す。
【図７Ａ２】図７Ａ１の頂点のテーブルの例の続きを示す。
【図７Ｂ】図５Ｂにおける有向グラフの概要表示のための頂点のテーブルの例を示す。
【図７Ｃ１】図５Ａにおける有向グラフの詳細表示のための辺のテーブルの例を示す。
【図７Ｃ２】図５Ｂにおける有向グラフの概要表示のための辺のテーブルの例を示す。
【図７Ｄ】図５Ａの有向グラフのための辺のオーナのテーブルの例を示す。
【図７Ｅ】図５Ａの有向グラフのためのトランザクションのテーブルの例を示す。
【図７Ｆ】図５Ａの有向グラフのための業務トランザクションのテーブルの例を示す。
【図７Ｇ】図５Ａの有向グラフのための業務サービスのテーブルの例を示す。
【図８Ａ】図５Ａの取引サービスのアプリケーションの複数のインスタンスのための物理的な頂点レコードの例を示す。
【図８Ｂ】図５Ａのオプション取引｜サービスのコンポーネントのインスタンスのための頂点レコードの例を示し、図８Ａから親の頂点レコード８０２の例を示す。
【図８Ｃ】図５Ａにおいて、オプション取引｜サービスのコンポーネントがウェブサービスのウェブサービス１を呼び出す場合における頂点のレコードおよび辺レコードの例を示す。
【図９】ユーザインタフェースを提供するための方法を示す。
【図１０】図９のステップ９０７にあるようにモデルを更新するための方法の例を示す。
【発明を実施するための形態】
【００１１】
本発明は、コンピュータシステムの少なくとも１つのアプリケーションを介してフローを追跡することによってコンピュータシステムにおける問題を診断する方法を提供する。
【００１２】
業務トランザクションまたはアプリケーションに障害が生じている場合、プロバイダは起きつつある故障とその原因を正確に知りたい。業務トランザクションは、ウェブサイトにログインしてアイテムを発注するなどのように、クライアントの観点からタスクを表すことが可能である。時には問題は一般的であり、トランザクションは毎回障害を起こし、そして時にはそれがより限定的である。例えば、一定のユーザがそれを試みるときにだけに、またはアイテムの一定の種類が要求されたときにだけにトランザクションが障害を起こすことがある。問題が一般的であるかまたは限定的であるかを決定することは困難で、問題の発生源を区分けすることはさらに難しい。
【００１３】
別の診断ツールが一般的および限定的なケースのために提供される。例えば、有向グラフ（トリアージマップまたはアプリケーションマップとも称される）は、トランザクションを集約するように、および関連付けられた論理的なサブシステムが相互作用し得るすべての可能な方法を表示するように、一般的なケースに対処するために使用される。またそれは、各サブシステムの全体的な正常性を表示する。トランザクショントレースのツールは最も具体的なケースを扱うために使用される。トランザクションツールは、システムを通過するものとして個々のトランザクションを記録し、指定時刻に作動する低レベルのメソッド呼び出しのシーケンスとしてそれらを表示する。問題は２つのツール間に大きな隔たりがあることである。有向グラフが大まかで粗い粒度であれば、トランザクショントレーサは限定的で粗くなる。有向グラフで始めたユーザは、一般的な傾向がなく何の故障も発見することなく、トランザクショントレースを引っ張ることを開始してパターンを識別するためにそれらを拾い読みしなければならない。サブシステムレベルに戻って問題をマッピングすることは、ソフトウェアと根底にある基盤との両方に精通していることを必要とする。
【００１４】
したがって、論理的なサブシステムを介して時刻を決められた一連のステップとして個々のトランザクションを表示するためには、２つの視覚化を組み合わせることが本当に必要となる。１つの可能な解決策は、関連付けられている有向グラフ上の個々のトランザクショントレース（または関連したトレースの集合）を、ユーザが「重ね合わせる」ことを許容する。それゆえ、問題が特定の業務トランザクションで報告される場合には、ユーザは業務トランザクションのための有向グラフを最初に見ることができる。関係付けられたサブシステムの全体的な正常性が平常に現れる場合、ユーザは、問題が一般的なものではないと認識することができる。その後、ユーザは、業務トランザクションのためのトランザクショントレースを要求する。トランザクショントレーサが記録をし、業務トランザクションのパラメータ（例えば、特定のＵＲＬおよびＰＯＳＴのパラメータ）と一致する最新のトランザクションの一覧表を返して、指定された期間を超えると、ユーザは「マッピング」するために１以上を選択する。パターンが出現するかどうか、例えば、ある特定のホストから生じたデータベース呼び出しが遅延の原因であるか否かを見る場合、ユーザはすべての最長のトランザクションを１つずつ（または同時に）マッピングすることを選択する。
【００１５】
マッピングされたトランザクションは、各頂点上および関連のある各辺の横に記載されている時間幅で、現在のマップの強調表示部分として現れる。辺は、サブシステム間の遷移を表し、矢印で表される。つまり、トランザクション内でアクティブになっているそれらのサブシステムは、あるサブシステムから次のサブシステムの呼び出しを表す辺に従ってマップ内で強調表示される。サブシステム間の呼び出しの長さは、辺の横に現される一方で、サブシステム内で費やされた合計時間は頂点上に現される。マップ内の最長の合計時間幅を有するコンポーネントは、時計記号などの特殊なアイコンでマークされている。複数の重ね合わせられたトランザクションの場合では、平均時間幅が表示されることに注意されたい。個々の時間幅は、ツールチップのホバー［ホバーボックス］で提供される。
【００１６】
さらに、ユーザインタフェースの補助領域は、付加的なオプションや情報を提供する。最初のタブは返されたトランザクションの一覧表（トランザクション一覧表）を含むので、ユーザはどのアイテムが選択された（およびマップ上に重ね合わせられた）か、を見て変更できる。「さらに検索」ボタンは、ユーザが同じパラメータを使用してより多くのトランザクションを記録することを許容する。詳細のタブは、特定のサブシステムに関連付けられたトランザクショントレースからのメソッド呼び出しを一覧表にする。トレース表示のタブはトランザクショントレースを提供する。さらに後述するように、様々な種類のデザインの画面またはユーザインタフェースが提供される。
【００１７】
ユーザインタフェースを介して、ユーザは、サブシステムと有向グラフのトランザクションとの間、およびサブシステムとトランザクションのインスタンスデータとの間、の関係を容易に検知できる。
【００１８】
図１は、複数の異なるコンピューティングデバイスがマネージャにデータを提供するネットワーク１００を示す。コンピューティングデバイス１０６、１１０および１１４の例は、アプリケーションサーバまたは必要な機能を実現するためのコードを実行するプロセッサを有するコンピューティングデバイスの他の種類を含む。コンピューティングデバイスは、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、コンピューティングデバイス１０６、１１０および１１４は、ローカルのマネージャコンピュータ１２０と通信する。マネージャコンピュータ１２０は、代わりにコンピューティングデバイス１０６、１１０および１１４から離れることが可能で、そのような場合の通信はネットワーククラウド１０４を介して行われる。
【００１９】
例えば、ウェブベースの電子商取引アプリケーションなどの企業のアプリケーションを実行している会社は、負荷分散のために１つの場所で複数のアプリケーションサーバを使用する。例えば、ユーザのウェブブラウザ１０２からのようなユーザからのリクエストは、インターネットのようなネットワーククラウド１０４を介して受信され、任意のコンピューティングデバイス１０６、１１０および１１４に送られる。ウェブブラウザ１０２は、図示していないインターネットサービスプロバイダを介してネットワーククラウド１０４に、通常、アクセスする。コンピューティングデバイス１０６、１１０および１１４上で実行するエージェントソフトウェアは、エージェントＡ１（１０８）、エージェントＡ２（１１２）およびエージェントＡ３（１１６）によってそれぞれ表され、ある可能なアプローチとして、それぞれのコンピューティングデバイス１０６、１１０および１１４上で実行されている、アプリケーション、ミドルウェアまたはその他のソフトウェアから、情報を収集する。例えば、そのような情報は、計測を用いることによって得ることができ、その一例はバイトコードの計測である。しかしながら、集められたデータは他の方法でも得ることができる。エージェントは、監視するコンピューティングデバイスに元来存在してデータの取得ポイントを提供する。エージェントは、マネージャ１２０と通信してデータをまとめ最適化する。
【００２０】
マネージャ１２０は、エージェントから受信したデータに基づく情報を表示するため、例えばモニタなどのユーザインタフェース１２２と通信するワークステーションのような分離したコンピューティングデバイス上に提供され得る。マネージャは、またエージェントから受信したデータを格納するためデータベース１１８にアクセスする。提示された例では、コンピューティングデバイスは、ネットワーククラウド１０４にアクセスすることなく、マネージャ１２０と通信する。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ１２０は、ネットワーククラウド１０４を介して複数のコンピューティングデバイスのエージェントからデータを受信する。例えば、大きな組織は、セントラルネットワークオペレーションセンタを運用する。そこでは、１以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、ウェブベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得することがある。支払いを処理するサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ１２０およびユーザインタフェースディスプレィ１２２は、企業の本社の場所で提供され得る。必ずしも、ウェブベースまたは小売、もしくはその他の販売に関する必要はなく、他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを利用する。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数コンピュータのデバイスアレンジに加えて、１以上のエージェントによって単一のコンピュータデバイスが同様に監視されることがある。
【００２１】
監視を実行するソフトウェアを計測するのに、様々なアプローチが知られている。例えば、最初に述べたように、トレーシングはソフトウェアの実行を追跡するために用いることができる。トレーシングの例が、”Transaction Tracer”と題する米国特許出願公開番号２００４／００７８６９１（２００４年４月２２日公開）に記載されている。その内容は参照により本明細書に組み込まれる。その中で述べられているアプローチにおいては、監視すべきアプリケーションのオブジェクトコードまたはバイトコードが計測され、例えばプローブにより変更される。アプリケーションのジョブまたは他のロジックを変更することなくアプリケーションについての特定の情報をプローブが測定する。一旦、プローブがアプリケーションのバイトコードにインストールされると、管理されたアプリケーションと称される。エージェントソフトウェアは、プローブからの情報を受信し、その情報を、例えばマネージャ１２０において、別のプロセスに伝達することがある。また、情報が異常状況を示すか否かを判定するなど、情報をローカルで処理する。エージェントは、このようにプローブから受信した情報を収集し要約する。指示ファイルによって定義されるように、プローブは、情報を収集する。例えば、プローブからの情報は、トランザクションまたは他の実行フローの開始や停止の回数、またはトランザクション／実行フロー内の個々のコンポーネントの開始や停止の回数を示す場合がある。この情報は、それが範囲内にあるかどうかを判定するために予め決められた基準と比較される。もし情報が範囲内にない場合には、エージェントは適切なトラブルシューティングが実行できるようにこの事実をマネージャに報告する。エージェント１０８、１１２および１１６は、それぞれが関連付けられているローカルコンピューティングデバイス１０６、１１０および１１４上でソフトウェアが実行中であることを通常認識している。
【００２２】
プローブは、ＣＯＲＢＡメソッドタイマ、リモートメソッドインボケーション（ＲＭＩ）メソッドタイマ、スレッドカウンタ、ネットワークバンド幅、ＪＤＢＣ更新およびクエリタイマ、サーブレットタイマ、Javaサーバページズ（ＪＳＰ）タイマ、システムログ、ファイルシステム入出力バンド幅メータ、使用可能および使用済メモリ、ならびにＥＢＪ（エンタープライズJavaビーンズ）タイマを含むメトリックの標準セットを報告する。メトリックは、特定のアプリケーションのアクティビティの計測値である。
【００２３】
エージェントは、アプリケーションによってアクセスされるリソースを識別するトランザクションに関する情報を報告する。１つのアプローチでは、トランザクションについて報告する場合における「呼び出された」という語はリソースを指す。このリソースは、消費者が親のコンポーネントであるところのリソース（またはサブリソース）である。例えば、トランザクションで呼び出される最初のコンポーネントがサーブレットＡであると仮定する。消費者のサーブレットＡ（下記参照）の下には、ＥＪＢと称されるサブリソースがある。消費者とリソースは、ツリーのような形でエージェントよって報告される。トランザクションのデータは、またツリーに従って格納される。例えば、もしサーブレット（例えばサーブレットＡ）が、ネットワークのソケット（例えば、ソケットＣ）の消費者であり、かつＥＪＢ（例えば、ＥＪＢ  Ｂ）の消費者でもあるとすれば、次にはＪＤＢＣ（例えば、ＪＤＢＣ  Ｄ）の消費者であり、ツリーは以下のように見える。
【００２４】
Servlet A（サーブレットＡ）
【００２５】
Data for Servlet A（サーブレットＡのデータ）
【００２６】
Called EJB B（呼び出されたＥＪＢ  Ｂ）
【００２７】
Data for EJB B（ＥＪＢ  Ｂのデータ）
【００２８】
Called JDBC D（呼び出されたＪＤＢＣ  Ｄ）
【００２９】
Data for JDBC D（ＪＤＢＣ  Ｄのデータ）
【００３０】
Called Socket C（呼び出されたソケットＣ）
【００３１】
Data for Socket C（ソケットＣのデータ）
【００３２】
一実施形態では、上記ツリーは、ブレイムスタックと称されるスタックにエージェントによって格納される。トランザクションが開始すると、トランザクションはスタックへプッシュされる。トランザクションが完了すると、トランザクションはスタックからポップされる。一実施形態では、スタック上の各トランザクションは、次に続く情報、トランザクションの型、トランザクションのためにシステムで使用される名称、パラメータのハッシュマップ、トランザクションがスタックへプッシュされたときのタイムスタンプおよびサブエレメント、が格納されている。サブエレメントは、注目すべきトランザクション内から開始されている他のコンポーネント（例えば、メソッド、プロセス、プロシージャ、関数、スレッド、命令セットなど）のためのブレイムスタックのエントリである。上記の例のようにツリーを使用すると、サーブレットＡのためのブレイムスタックのエントリは２つのサブエレメントを有する。第１サブエレメントは、ＥＪＢ  Ｂへのエントリで、第２サブエレメントは、ソケットスペースＣへのエントリである。サブエレメントは特定のトランザクションのためのエントリの一部であるにもかかわらず、サブエレメントはまた独自のブレイムスタックのエントリを有する。上記のツリーに示されるように、ＥＪＢ  ＢはサーブレットＡのサブエレメントであり、また独自のエントリを有する。トランザクションに対する一番上（最初）のエントリ（例えばサーブレットＡ）は、ルートコンポーネントと称される。スタック上の各エントリはオブジェクトである。
【００３３】
図２Ａは、トランザクショントレースを開始するための処理の一実施形態を説明するフローチャートである。ステップは適切な（複数の）エージェントにより実行される。ステップ１３０ではトランザクションを開始する。一実施形態では、プロセス［処理］は、メソッド（例えば、“loadTracer”メソッドの呼び出し）の開始によってトリガ（起動）される。ステップ１３２において、エージェントは所望のパラメータ情報を取得する。一実施形態では、ユーザは、構成ファイルまたはＵＩを介して、どのパラメータ情報を取得するかを設定することができる。取得されたパラメータは、ブレイムスタックへプッシュされるオブジェクトの一部であり、ハッシュマップに格納される。他の実施形態では、パラメータの識別は、予め設定されている。格納されるパラメータには様々なものがある。一実施形態では、使用されるパラメータの実際の一覧表は、監視されるアプリケーションに依存している。以下の表は、取得され得るいくつかのパラメータの例を示す。
【００３４】
【表１】
2012221499.tif 000003
【００３５】
パラメータは、クエリ、クッキー、ＰＯＳＴ、ＵＲＬおよびセッションの型の名称／値の組を含む。
【００３６】
ステップ１３４では、システムは現在の時刻を示すタイムスタンプを取得する。ステップ１３６ではスタックエントリが作成される。ステップ１３８において、スタックエントリはブレイムスタックへプッシュされる。一実施形態では、タイムスタンプがステップ１３８の一部として付加される。トランザクションが開始されるときにプロセス［処理］が実行される。同様のプロセス［処理］が、トランザクションのサブコンポーネントが開始するときに実行される（例えば、ＥＪＢ  ＢはサーブレットＡのサブコンポーネントである−上述したツリーを参照のこと）。
【００３７】
図２Ｂは、トランザクショントレースを終了するためのプロセス［処理］の一実施形態を説明するフローチャートである。トランザクションが終了するときにエージェントによりプロセス［処理］が実行される。ステップ１４０において、プロセス［処理］がトランザクション（例えばメソッド）の終了（例えば、“finishTrace”メソッドの呼び出し）によってトリガされる。ステップ１４２では、システムは現在の時刻を取得する。ステップ１４４では、スタックエントリが削除される。ステップ１４６において、トランザクションの実行時間は、ステップ１４２からのタイムスタンプをスタックエントリに格納されているタイムスタンプと比較することによって算出される。ステップ１４８では、トレースのためのフィルタが適用される。例えば、フィルタは１秒の閾値期間を含む。したがって、ステップ１４８は、ステップ１４６から算出された時間幅が１秒よりも大きいか否かを決定することを含む。閾値を超えない場合（ステップ１５０）、トランザクションのデータは破棄される。一実施形態では、スタックエントリの全体が破棄される。別の実施形態では、パラメータとタイムスタンプだけが破棄される。他の実施形態では、データの様々なサブセットが破棄される。いくつかの実施形態では、閾値の時間幅を超えていない場合には、エージェントにより、データは図１のシステム内の他のコンポーネントに送信されない。時間幅が閾値を超える場合（ステップ１５０）、ステップ１６０においてエージェントがコンポーネントデータを組み立てる。コンポーネントデータは、報告されるトランザクションに関するデータである。一実施形態では、コンポーネントデータは、トランザクションの名称、トランザクションの型、トランザクションの開始時刻、トランザクションの時間幅、パラメータのハッシュマップ、およびサブエレメント（エレメントの帰納的なリスト）のすべてを含む。その他の情報もまたコンポーネントデータの一部である。ステップ１６２において、エージェントは、マネージャ１２０にＴＣＰ／ＩＰプロトコルによりコンポーネントデータを送信することによってコンポーネントデータを報告する。
【００３８】
図２Ｂは、トランザクションが終了すると何が起こるかを表している。しかしながら、サブコンポーネントが終了すると、実行されるステップは、タイムスタンプを取得すること、サブコンポーネントのためのスタックエントリを削除することおよび完了したサブエレメントを以前のスタックエントリに加えることを含む。一実施形態では、フィルタおよび判断ロジックは、特定のサブコンポーネントというよりも、トランザクションの開始および終了に適用される。
【００３９】
一実施形態では、トランザクショントレーサがオフになっている場合、システムは依然としてブレイムスタックを使用するが、しかし、パラメータは格納されことなく、コンポーネントデータは作成されないことに注意されたい。いくつかの実施形態では、トレーシング技術をオフにすることによってシステムはトレーシングを開始しない。トレーシングは上述したように、ユーザが要求した後にだけ開始する。
【００４０】
図２Ｃは、図１のネットワークのコンピューティングデバイスを示す。コンピューティングデバイス２００は、図１に関連して説明したように、ウェブブラウザ、アプリケーションサーバ、マネージャおよび／またはユーザインタフェースで使用されるシステムを簡略化して表したものである。コンピューティングデバイス２００は、ハードディスクまたはポータブルメディアのような記憶装置２１０、他のコンピューティングデバイスと通信するためのネットワークインタフェース２２０、ソフトウェアの命令を実行するためのプロセッサ２３０、例えば、記憶装置２１０からロードされた後にソフトウェアの命令を格納するためのＲＡＭのような作業メモリ２４０、および１以上のビデオモニタのようなユーザインタフェースディスプレィ２５０を含むものである。ユーザインタフェースは１以上のモニタを提供する。記憶装置２１０は、本明細書で説明した機能を提供するための方法を実行するのにプロセッサ２３０をプログラミングするために具現化されているプロセッサ読み取り可能なコードを有する、プロセッサまたはコンピュータで読み取り可能な有体であり一時的でない記憶装置と考えることができる。ユーザインタフェースディスプレィ２５０は、１以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供する。ユーザインタフェースディスプレィ２５０は、グラフィカルまたは表形式のような既知の任意の表示方式を使用する。画面上の表示に加えて、プリンタからのハードコピーなどの出力も提供する。
【００４１】
記憶装置２１０がアプリケーションサーバ、マネージャおよび／またはユーザインタフェースのようなコンピューティングデバイス２００の一部である場合、データベース１１８は記憶装置２１０に含まれる。記憶装置２１０は、１以上のエージェントから受信したデータを格納し、本明細書で説明したようにユーザインタフェースを提供するためにデータを取得するためにアクセスされる、１以上の記憶装置を表し得る。記憶装置２１０は、データストアを表し得る。
【００４２】
また、本明細書で説明した機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、１以上のプロセッサをプログラミングするために具現化されているプロセッサで読み取り可能なコードを有する、プロセッサで読み取り可能な１以上の一時的でない有体の記憶装置が使用される。プロセッサ読み取り可能な一時的でない有体の記憶装置は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアなどのコンピュータで読み取り可能な媒体を含む。例えば、コンピュータにより読み取り可能な一時的でない有体の媒体には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータなどの情報を記憶するために、任意の方法や技術で実装された、揮発性、不揮発性、リムーバブルや非リムーバブルメディアが含まれ得る。コンピュータにより読み取り可能な一時的でない有体の媒体の例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタルバーサタイルディスク（ＤＶＤ）、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムＩＣ、ゲートアレイ、ＦＰＧＡ、ＰＬＤや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、１以上の実施形態を実装するソフトウェア（記憶装置に格納されている）は、１以上のプロセッサをプログラムするために用いられる。１以上のプロセッサは、コンピュータにより読み取り可能な有体の媒体／記憶装置、周辺機器および／または通信インタフェースと通信することができる。
【００４３】
図３は、１以上のアプリケーションの操作を示す際に用いられる階層を示す。複数の異なるレベルの階層が必要な組織構造に基づいて定義され得る。例えば、階層は、人間が理解し易い用語を含み、その用語は、クライアントの、監視されるアプリケーションとの相互関係の理解を容易にするものである。階層は、例えば、電子商取引のトランザクション、教育組織または政府組織などの営利目的の業務の領域にある、アプリケーションとの相互関係の類型を包含する。さらに、１以上の階層は、各ノードが記述名を持つ１以上の階層の複数の異なるレベルにおけるノードを含む。階層は、人間のオペレータにいっそう理解され易い仕方でアプリケーションを実行するやり方についての情報を、体系化する方法を提供する抽象的な構成であると考えられる。
【００４４】
階層の最上位レベルは、「ドメイン」と名付けられたドメインレベル３００である。階層の次のレベルは、業務サービスレベル３０２である。業務サービスの例は、ウェブサイトを用いた株式やその他の金融商品を扱う取引に関連する。このように「取引」は、階層の業務サービスレベルにおけるノードの名称である。取引業務サービスの特定のインスタンスは、例えば、特定のユーザが取引を実行すると発生する。他の業務サービスの例には、書籍販売のウェブサイトのための「書籍購入」、および福利厚生制度における従業員登録のための「福利厚生に登録」などがある。
【００４５】
階層の次のレベルは、業務トランザクションレベルである。前述したように、業務トランザクションは、ウェブサイトにログインしてアイテムを発注するなどのように、クライアントの観点からタスクを表す。業務サービスは、複数の業務トランザクションで構成され得る。例えば、取引に対しては、業務トランザクションは、ログイン３０４（例えば、ウェブサイトにログイン）、残高３０６（例えば、口座の残高を取得する）、取引概要３０８（例えば、最近の売買活動の報告を取得する）、発注３１０（例えば、オプション以外の株または債権のような証券を売買するために発注する）、およびオプション取引３１２（リサーチおよび／またはオプション取引を行う）を含む。ユーザがアカウントにログインしようとすると、ログインの特定のインスタンスが発生する。
【００４６】
さらに業務トランザクションは、１以上の業務トランザクションコンポーネントに関連付けられる。１つのアプローチでは、業務トランザクションは、唯一の識別コンポーネントを有する。業務トランザクションコンポーネントは、サーブレットまたはＥＪＢのように、サーバによって認識可能かつ測定可能なアプリケーションのコンポーネントの型である。１つのアプローチでは、アプリケーションのコンポーネントの１つは、業務トランザクションのためのトランザクションコンポーネントを識別する、業務トランザクションコンポーネントとして設定される。業務トランザクションコンポーネントは、業務トランザクションのためのトランザクションを識別するトランザクションのためにトランザクションコンポーネントを識別する。トランザクションは、クライアントに対応するレスポンスを提供するために、クライアントからのリクエストに応答して呼び出されるソフトウェアコンポーネントのシーケンスを表す。例えば、業務トランザクションコンポーネントは、エージェントによって報告されたコンポーネントデータが一セットのルールに一致する時期を判定することによって識別される。この定義は、例えば、特定のＵＲＬのホスト名称、ＵＲＬのパラメータ、ＨＴＴＰポストのパラメータ、クッキーおよび／またはセッションマネージャのパラメータなどを含む。加えて、またはその代わりに、定義は、特定のＵＲＬのホスト名称で開始するトランザクションを要求する場合もある。エージェントまたはマネージャは、例えば、業務トランザクションコンポーネントが業務トランザクション内に存在している時期を判定するために、コンポーネントデータと一セットのルールを比較する。業務トランザクションコンポーネントが検出される場合、関係付けられた業務トランザクションは特定の型のものである。例えば、業務トランザクションコンポーネント３０５、３０７、３０９、３１１または３１３が検出される場合、関係付けられた業務トランザクションは、それぞれログイン３０４、残高３０６、取引概要３０８、発注３１０またはオプション取引３１２である。
【００４７】
例えば、サーブレットに関係付けられているトランザクションのために、業務トランザクションコンポーネントは、セカンダリフレーム内にロードされているJavaサーバページズ（ＪＳＰ）に接続して呼び出される。
【００４８】
加えて、１以上のアプリケーションは、複数の異なるサブシステム、例えば、特定のタスクを実行するソフトウェアコンポーネントを含む。通常、業務トランザクションの各インスタンスは、１以上のサブシステムのシーケンスのコードの実行に関与する。サブシステムは、互いに依存し、例えば、直列または分岐した連鎖で互いに呼び出す。異なる業務トランザクションが共通のサブシステムを使用することもある。
【００４９】
サブシステムの例には、破線のボックスによって表される計測されたサブシステムがあり、これは、通常、フロントエンドのサブシステムである。同様に、点線のボックスによって表される未計測のサブシステムがあり、これは、通常、バックエンドのサブシステムである。本明細書で使用されるように、フロントエンドのサブシステムは、通常、計測され、バックエンドのサブシステムは、通常、計測されない。さらに、あるフロントエンドのサブシステムは、ウェブサービスの呼び出しなどを介して別のフロントエンドのサブシステムを呼び出す。また、フロントエンドのサブシステムは、バックエンドのサブシステムを呼び出す。性能メトリックの全範囲は、計測されたサブシステムから取得される。限定された情報は、計測されたサブシステムからメソッドに呼び出されて使用されるメソッドから、未計測のサブシステムに着目して得られる。未計測のデータベースの場合、例えば、ＪＤＢＣドライバ（呼び出しフロントエンドと同じJavaバーチャルマシン（ＪＶＭ）に位置する）は、データベースの応答性についての見解を与えるメトリックを提供する。未計測のメインフレームの場合、通常、メインフレームの特定のポートにメインフレームを呼び出すメソッドが存在し、その呼び出しにどのくらい時間がかかるか、またはそれがストールするか否かもしくはエラーを報告するか否かを評価できる。
【００５０】
多くの場合、未計測のサブシステムは、メインフレーム、データベース、または他の未計測のコンピューティングデバイスなどのバックエンドのサブシステムである。これらは不明のコンポーネント／宛先である。計測されたサブシステムは、取引サービス３２０、注文エンジン３２６、認証エンジン３２８、報告サービス３２４、認証サービス３２２および報告エンジン３３０を含む。未計測のサブシステムは、注文レコードデータベース３３２、報告レコードデータベース３３８、ポート番号６５４３を経由してアクセスされるシステムのローカルホスト３３４、ポート番号３４５６を経由してアクセスされるシステムのローカルホスト３２１および顧客レコードデータベース３３６を含む。その名称にＳＱＬを含むサブシステムは、ストラクチャードクエリランゲージ（ＳＱＬ）のデータベースである。「？」は、サブシステム３３４および３２１が不明であることを示す。
【００５１】
図４Ａは、業務トランザクション内で呼び出されるコンポーネントのシーケンスの例における依存関係を示す。コンポーネント指向のプログラミングモデルは、プログラマに、コンポーネントに関係する構成要素からアプリケーションや他のプログラムを構築させるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行する。さらに、コンポーネントは、コンポーネントのシーケンスがプログラム内で呼び出されるように、他のコンポーネントを呼び出し、同様に、再帰呼び出しでは自分自身を呼び出す。コンポーネント指向のプログラミングモデルの一例は、Ｊ２ＥＥであるが、Javaサーバページズ、エンタープライズJavaビーンズ（ＥＪＢ）、サーブレットおよびJavaデータベースコネクティビティ（ＪＤＢＣ）のコンポーネントといったコンポーネントを用いることができる。ＪＤＢＣは、クライントがいかにデータベースにアクセスするかを定義するJava（登録商標）プログラミング言語のためのアプリケーションプログラミングインタフェース（ＡＰＩ）である。それは、データベース内のデータを照会や更新する方法を提供する。しかしながら、.NETのような他のコンポーネント指向のプログラミングモデルを使用することもできる。また、プログラミングモデルは、オブジェクト指向である必要はない。
【００５２】
この例では、前述のログイン業務トランザクションの詳細を提供する。１つの可能な実装では、ログインの各コンポーネントは、クラスメソッド（ＣＭ）の組である。例えば、サーブレットはJavaクラスである。リクエストを受信し、対応するレスポンスを生成するのはオブジェクトである。クラスメソッドの組は、class.methodの表記により表される。ログインは、ログイン名やパスワードなどのユーザのログイン認証情報を取得する１番目のクラスメソッドの組ＣＭ１を含む。ＣＭ１の書式の例は、ServletA1.ObtainLoginCredentialsである。
【００５３】
例として、ＣＭ１は、ログインの業務トランザクションコンポーネントである。したがって、エージェントは、ＣＭ１が呼び出されたことを検出するたびに、現在のトランザクションは、ログインの一部でありそのコンポーネントデータはログインと関連付けられると結論する。
【００５４】
２番目のクラスメソッドの組ＣＭ２（例えばServletA2.CheckLoginCredentials）は、ログイン認証情報の書式を調べる。
【００５５】
ログイン認証情報が適式でない場合、ＣＭ２は、ユーザに正しい入力をするように促すエラーメッセージを表示する、３番目のクラスメソッドの組ＣＭ３（例えば、ServletA3.DisplayErrorMessage）を呼び出す。ログイン認証情報が適式である場合、ＣＭ２は、ＣＭ４ａ（例えば、ServletA4.ValidateLoginCredentials）を呼び出す。ＣＭ４ａは、ＣＭ７（例えば、ServletB1.ReceiveLoginCredentials）を呼び出し、その際にログイン認証情報をＣＭ７に渡す。
【００５６】
ＣＭ７はユーザのログイン認証情報が顧客レコードと一致するか否かを判定するデータベースにアクセスするＣＭ８（例えば、ＪＤＢＣドライバの呼び出し／CheckCredentialRecordsのＳＱＬ文）を呼び出す。一致することをＣＭ８がＣＭ７に返答した場合、ＣＭ７はユーザのアカウントが有効であるか否かを判定するためにデータベースにアクセスするＣＭ９を呼び出す（例えば、ＪＤＢＣドライバの呼び出し／CheckAccountStandingのＳＱＬ文）。アカウントが有効であることを示すレスポンスをＣＭ９がＣＭ７に提供した場合、ＣＭ７は、ユーザがログインしていることを示すようにデータを更新するためにＣＭ１０（例えば、ＪＤＢＣドライバの呼び出し／UpdateLoginRecordsのＳＱＬ文）を呼び出し、ＣＭ１０はＣＭ７にlogin status=trueを返す。ＣＭ８において認証情報が一致しない場合、またはＣＭ９においてアカウントが有効ではない場合、デフォルトのlogin status=falseが残るように、ＣＭ７はlogin status=falseを設定し、ＣＭ１０が呼び出されることはない。
【００５７】
例示の実装では、ＣＭ８からＣＭ１０は、データベース内にテーブルエントリを作成したりエントリにデータを付加したりするなどのように、１以上のＳＱＬ文を呼び出すＪＤＢＣドライバの呼び出しを含む。また、必要に応じて、各ＳＱＬ文はＪＤＢＣドライバの呼び出しによって呼び出される分離したコンポーネントとして特定される。図５Ｒを参照されたい。
【００５８】
ＣＭ７はＣＭ４ａにリプライを返し、ＣＭ４ａはlogin status=true または login status=falseのいずれかでＣＭ２にリプライを返す。login status=trueであれば、ＣＭ２はＣＭ４ｂを呼び出し、ＣＭ４ｂはアクセスが許可されたことをユーザに示すメッセージを表示するＣＭ５（例えば、ServletA5.DisplayMessageAccessGranted）を呼び出す。またlogin status=falseであれば、ＣＭ２はＣＭ４ｂを呼び出し、ＣＭ４ｂはアクセスが拒否されたことをユーザに示すメッセージを表示するＣＭ６（例えば、ServletA6.DisplayMessageAccessDenied）を呼び出す。
【００５９】
分離したコンポーネントＣＭ４ａおよびＣＭ４ｂは、ＣＭ４ａによるＣＭ７への呼び出しや、ＣＭ４ｂによるＣＭ５またはＣＭ６への呼び出し、といった別々の計測を可能にするために使用されることに注意されたい。あるいは１つのコンポーネント、ＣＭ４がＣＭ４ａおよびＣＭ４ｂの機能を扱う。この１つのコンポーネントは、同じアプリケーションサーバ内の別のメソッド（ＣＭ５またはＣＭ６）と、ウェブサービスコール（ＣＭ７）の両方を呼び出す。
【００６０】
説明のように、ＣＭ１からＣＭ６は認証サービスサブシステム内で実行され、一方、ＣＭ７からＣＭ１０は認証エンジンサブシステム内で実行される。ログインは、このようにこれらのサブシステムの両方で実行し、または呼び出す。
【００６１】
コンポーネントは、非同期、マルチスレッドまたはマルチプロセスのモードで実行を開始する別のコンポーネントを呼び出した後、実行を継続できることに注意されたい。または、この呼び出されたコンポーネントが同期モード、シングルスレッドまたはシングルプロセスのモードで実行を終了するまで、コンポーネントを一時的に休止できる。休止しているコンポーネントは、待機期間にあると考えられ、一方、実行されているコンポーネントはアクティブで、実行モードであると考えられる。コンポーネントは、トランザクションの間中、２回以上呼び出されることが可能である。
【００６２】
図４Ｂ１は、図４Ａのコンポーネントの１つの可能なシーケンスに基づいて、トランザクション内で呼び出されたコンポーネントのシーケンスのためのトランザクショントレースの例を示す。水平方向は時間を表し、垂直方向は呼び出しスタックの深さや位置を表す。また、呼び出しスタックと称されるトランザクショントレースは、１以上のプログラム、プロセスまたはスレッドの実行中に、呼び出されるかまたは起動される計測されたコンポーネントを識別する。計測されたコンポーネントのトレースデータは、アプリケーションを理解したりデバッグしたりするために依存データとともに使用される。トランザクショントレースは、トレースまたはトランザクションの全部もしくは一部とすることができ、それぞれのエージェントを有する１以上のコンピューティングデバイスに及ぶ。
【００６３】
特に、分離したトランザクショントレースは、別々のスレッドが別々のトランザクショントレースに分離されるように各エージェントに対し提供される。さらに、各トランザクショントレースは、分離して水平に拡張した領域、または図の「スイムレーン」で表される。この図では、認証サービスサブシステムのためのエージェントのトランザクショントレース４０１が一番上の水平に拡張する領域にあり、認証エンジンサブシステムのためのエージェントのトランザクショントレース４０３が一番下の水平に拡張する領域にある。２つのトランザクショントレースは、関係のあるタイミングの一層の理解を可能にするため、一緒に表される。別々のエージェントの時計が十分に同期すると知られている場合には、別々のトランザクショントレースの関連性のあるタイミングについて正確な結論が得られる。矢印４００および４０２は、個々に、トランザクショントレース４０１および４０３に対するそれぞれの呼び出しスタックの深さを表す。
【００６４】
ユーザインタフェースディスプレイ上で提供されるグラフ表示において、コンポーネントＣＭ１は、トランザクショントレース４０１の第１またはルートのコンポーネントである。トランザクショントレースは、第２層でＣＭ２、第３層でＣＭ４ａおよびＣＭ４ｂならびに第４層でＣＭ５を含む。トランザクショントレース４０３において、ＣＭ７は第１レベルにあり、ＣＭ８、ＣＭ９およびＣＭ１０は第２レベルにある。オプションとして、トランザクショントレース４０３は、さらに詳細を示すこともできる。例えば、後述のように、図５Ｒに示されるように、ＣＭ８、ＣＭ９ およびＣＭ１０が各ＪＤＢＣドライバの呼び出しである場合、トランザクショントレース４０３は、子のＳＱＬ文６９１、６９２および６９３をそれぞれ示すように変更可能である。
【００６５】
時間のスケールは０−ｔ１３に延びており、例えば１３００ミリ秒（ｍｓ．）を表す。トランザクショントレースは、コンポーネントが実行する時間間隔、およびコンポーネント間の呼び出し関係を示す。例えば、ＣＭ１がｔ０からｔ１３で実行し、ＣＭ２がｔ１からｔ１２．５で実行し、ＣＭ４ａがｔ２からｔ１０（およそ）で実行し、ＣＭ４ｂがｔ１０（およそ）からｔ１２で実行し、およびＣＭ５がｔ１１からｔ１１．５で実行する。さらに、ＣＭ１はＣＭ２を呼び出し、ＣＭ２はＣＭ４ａおよびＣＭ４ｂを呼び出し、ならびにＣＭ４ｂはＣＭ５を呼び出す。
【００６６】
図４Ｂ２は、図４Ｂ１のトランザクショントレースの例における待機期間を示す。同期のトランザクションは、例えばＣＭ１のような１つのコンポーネントが、例えばＣＭ２のような別のコンポーネントの呼び出し、および継続／再開の実行の前に応答するＣＭ２のための待機を含む。呼び出しメソッドによって要求される時間が呼び出しメソッドのための「待機時間」であると仮定する。非同期のトランザクションもまたトレースすることが可能であり、図４Ｂ１に類似したトランザクショントレースの表示に示すことができる。待機時間プラス正味の時間幅が実行または応答時間の合計時間幅に等しくなるように、待機時間外のコンポーネントにより消費される時間は、実行または応答時間の正味の時間幅であると考えられる。コンポーネントの合計時間幅は、コンポーネントによって直接呼び出されるすべてのメソッドに対する時間幅を合計し、コンポーネントに対する合計記録時間幅からの合計を減算することによって算出される。
【００６７】
グラフ中の水平の各棒ついて、無地の部分は呼び出されたコンポーネントからの応答を待たないことを示し、斜線模様のある棒はコンポーネントが呼び出されたコンポーネントからの応答を待つことを示す。たとえコンポーネントの計測がコンポーネントの実行中または待機中であるかを明示的に示さないとしても、同期の場合には、先のコンポーネントはそれらが呼び出したメソッドが実行している間は待機するものと推測できる。コンポーネントによって消費される時間内に、その一部は、ネットワークまたはＣＰＵの遅延などによって遅れて、応答するために呼び出されたコンポーネントを実行や待機するのに費やされる。
【００６８】
この例では、ＣＭ１は、ログイン業務トランザクションのインスタンスの開始時のｔ０において実行を始め、ｔ１においてＣＭ２を呼び出す。ＣＭ２は、ｔ１において実行を始め、ｔ２においてＣＭ４ａを呼び出す。ＣＭ４ａはｔ２において実行を始める。この例では、ＣＭ７は、異なるエージェントに関連付けられて異なるサブシステム上にあることから、トランザクショントレース４０１は、ＣＭ４ａがｔ３においてＣＭ７を呼び出したことを特定しない。また、例えば、ネットワーク通過時間、処理遅延、またはその他の要因によって、ＣＭ４ａがＣＭ７を呼び出すこととＣＭ７の実行を開始することとの間に遅れが生じることがある。しかしながら、トランザクショントレース４０３は、ＣＭ７がｔ３．５において実行を開始し、ＣＭ４ａによって、例えばクロスプロセスの呼び出しにおいて呼び出されたことを示す。つまり、ＣＭ７は、ＣＭ４ａの呼び出しの結果として実行を開始する。ＣＭ７はｔ４においてＣＭ８を呼び出し、ＣＭ８はｔ４からｔ５で実行する。ＣＭ７はｔ６においてＣＭ９を呼び出し、ＣＭ９はｔ６からｔ７で実行する。ＣＭ７はｔ８においてＣＭ１０を呼び出し、ＣＭ１０はｔ８からｔ９で実行する。ｔ９において制御フローはＣＭ７に戻り、ｔ９．５においてＣＭ７は実行を停止する。制御フローは、上記の要因によってｔ１０までＣＭ４ａに戻らない。ｔ１０において制御フローは、ＣＭ４ａに短時間戻って、ｔ１０の直後にＣＭ２がＣＭ４ｂを呼び出すときにＣＭ２に短時間戻る。トランザクショントレース４０１では、ＣＭ４ｂはｔ１１においてＣＭ５を呼び出し、ＣＭ５はｔ１１からｔ１１．５で実行する。ｔ１１．５において制御フローはＣＭ４ｂに戻り、ｔ１２において、制御フローはＣＭ２に戻る。そしてｔ１２．５において制御フローはＣＭ１に戻る。
【００６９】
ＣＭ８、ＣＭ９およびＣＭ１０はそれぞれデータベース（顧客レコードデータベース)を呼び出す。しかし、データベースは未計測であることから、データベースによって消費される時間の量は、トランザクショントレース４０３のＣＭ８、ＣＭ９またはＣＭ１０の合計実行時間から区別されない。
【００７０】
この例では、ＣＭ１ついては、合計時間幅はｔ１３−ｔ０＝１３００ミリ秒で、待機時間はｔ１２．５−ｔ１＝１１５０ミリ秒、そして、正味の時間幅は１３００−１１５０＝１５０ミリ秒である。ＣＭ２については、合計時間幅は１１５０ミリ秒で、待機時間はｔ１２−ｔ２＝１０００ミリ秒、そして、正味の時間幅は１１５０−１０００＝１５０ミリ秒である。ＣＭ４ａについては、合計時間幅はｔ１０−ｔ２＝８００ミリ秒で、待機時間はｔ１０−ｔ３＝７００ミリ秒、そして、正味の時間幅は８００−７００＝１００ミリ秒である。ＣＭ４ｂについては、合計時間幅はｔ１２−ｔ１０＝２００ミリ秒、待機時間はｔ１１．５−ｔ１１＝５０ミリ秒、そして、正味の時間幅は２００−５０＝１５０ミリ秒である。ＣＭ５については、合計時間幅はｔ１１．５−ｔ１１＝５０ミリ秒で、待機時間は０ミリ秒、そして、正味の時間幅は５０−０＝５０ミリ秒である。
【００７１】
同様に、トランザクショントレース４０３では、ＣＭ７については、合計時間幅はｔ９．５−ｔ３．５＝６００ミリ秒で、バックエンドの呼び出し時間はｔ５−ｔ４＋ｔ７−ｔ６＋ｔ９−ｔ８＝１００＋１００＋１００＝３００ミリ秒、そして、認証エンジンサブシステムで費やされる時間は６００−３００＝３００ミリ秒である。この費やされた時間は正味の時間幅に類似している。ＣＭ８については、合計時間幅はｔ５−ｔ４＝１００ミリ秒で、待機時間は０ミリ秒であると仮定して、正味の時間幅は１００ミリ秒となる。ＣＭ９については、合計時間幅はｔ７−ｔ６＝１００ミリ秒で、待機時間は０ミリ秒であると仮定して、そして正味の時間幅は１００ミリ秒になる。ＣＭ１０については、合計時間幅はｔ９−ｔ８＝１００ミリ秒で、待機時間は０ミリ秒であると仮定して、そして正味の時間幅は１００ミリ秒である。
【００７２】
認証エンジンサブシステムのルートコンポーネント、ＣＭ７の合計時間幅に基づく、認証エンジンサブシステムの合計時間は６００ミリ秒である。サブシステム（例えば、最下位レベルのコンポーネント、ＣＭ８、ＣＭ９およびＣＭ１０のｔ４、ｔ６、ｔ８におけるそれぞれの呼び出し）の外側で呼び出しが行われる時間に基づき、呼び出しに対応する応答が受信された時間（例えば、それぞれｔ５、ｔ７およびｔ９）に基づく、認証エンジンサブシステムのバックエンドの呼び出し時間は、１００＋１００＋１００＝３００ミリ秒である。そして、認証エンジンサブシステムで費やされる時間は、バックエンドの呼び出し時間を除いた合計時間幅、つまり６００−３００＝３００ミリ秒である。バックエンドの呼び出し時間は、呼び出された１以上の計測または未計測のサブシステムに割り当てられる。この例では、１つの未計測のサブシステムが呼び出され（顧客レコードデータベース）、３００ミリ秒がそれによるものと考えられる。
【００７３】
認証エンジンサブシステムは、全体として機能的に、１つの実装においては認識される「待機時間」が存在しない。ＣＭ８、ＣＭ９およびＣＭ１０は、「バックエンド呼び出し」時間に対応している。トレースの３つのコンポーネントが、１以上のバックエンドへの呼び出しを表すが、呼び出しを実行する際に費やされた時間と、応答するためのバックエンドの待機に費やされた時間とを区別することができない。認証エンジンの「フロントエンド」で費やされた時間と「バックエンド呼び出し」で費やされた時間との区別をすることができるように、認証エンジンに対する合計時間からバックエンドの時間を減算する。この場合、すべてのバックエンドの呼び出しは、同じバックエンドに向かうので、単一の値、即ち顧客レコードデータベースの呼び出しで費やされる合計時間に集約することができる。他の場合には、分離したバックエンドの呼び出し時間は、複数のバックエンドにそれぞれ集約可能である。
【００７４】
同様に、認証サービスサブシステムの合計時間幅は、ルートコンポーネントＣＭ１の合計時間幅から１３００ミリ秒と決定することができる。サブシステムの外側で最下位レベルのコンポーネントの呼び出し（例えば、最下位レベルのコンポーネントＣＭ４ａによる、ｔ３におけるＣＭ７の呼び出し）が行われる時間と、呼び出しに対応するレスポンスが受信された時間（例えばｔ１０）と、に基づく認証サービスサブステムの待機時間は７００ミリ秒である。そして、認証サービスサブシステムの正味の時間幅は、待機時間を除いた合計時間幅、つまり１３００−７００＝６００ミリ秒である。
【００７５】
さらに、認証サービスサブシステムの７００ミリ秒の待機時間は、認証サービスサブシステムが呼び出す１以上のサブシステムによるものであると考えられる。認証エンジンサブシステムは、認証サービスサブシステムによって呼び出される唯一のサブシステムであることから、７００ミリ秒は認証エンジンサブシステムによるものであると考える。しかしながら、認証エンジンサブシステムの合計時間幅は、６００ミリ秒しかないと判定された。したがって、７００−６００＝１００ミリ秒が、認証サービスサブシステムから認証エンジンサブシステムへのリクエストを伝達し、認証エンジンサブシステムから認証サービスサブシステムへの対応するリプライを伝達するのに消費される時間によるものであると考えることができる。サブシステム間のリクエストやリプライを伝達することには、ネットワーク遅延およびＣＰＵ遅延に加えて、ウェブサービスなどのサービスにアクセスすることを含むことに注意されたい。
【００７６】
このように、合計時間幅、サブシステムで費やされた正味の時間幅または時間、待機時間、バックエンドの呼び出し時間（または未計測のサブシステムへの他の呼び出し）、およびサブシステム相互通信の時間を判定するために、最後に呼び出されたサブシステムから最初に呼び出されたトランザクションのサブシステムまで過去に遡って作業をする。バックエンドの呼び出し時間を表すという点では、いつ、どのようにして正味の時間幅に対する全時間幅を使用するかという問題がある。より高い粒度が提供され得ることから正味の時間幅が好ましいが、呼び出しが未計測のバックエンドに行われる場合には全時間幅しかない。正味の時間幅が利用できるルールを設定したが、時間が未計測のバックエンドのものを含む場合、グループ分けした大括弧または類似のもので示すことができる。手順の例を次に説明する。
【００７７】
図４Ｂ３は、従属する計測されたサブシステムのシーケンスのための、合計時間幅、正味の時間幅、待機時間、およびサブシステム相互の通信時間を決定する方法を示す。計測されたサブシステムのシーケンスは直列であることから、シーケンス内には唯一の分岐または連鎖があるので、１つのサブシステムが１番目の次のサブシステムを呼び出し、１番目の次のシステムが２番目の次のサブシステム、等々を呼び出す。また、シーケンスは、例えば、１つのサブシステムが１番目の次のサブシステムおよび２番目の次のサブシステムを呼び出すときのように、１以上の並列分岐を有する。例えば、図５Ａにおいて後述するように、計測されたサブシステムの直列シーケンスは、認証サービスが認証エンジンを呼び出すログインのために提供される。さらに、計測されたサブシステムの複数分岐シーケンスは発注に提供され、そこでは、取引サービスが、別々の分岐において注文エンジンおよび認証エンジンの両方を呼び出す。さらに、従属するサブシステムのシーケンスの段階が定義される。例えば、ログインについては、認証サービスは第１段階で、認証エンジンは第２（および最終）段階である。発注については、取引サービスは第１段階で、注文エンジンおよび認証エンジンは共に第２（および最終）段階である。
【００７８】
これらの概念の表示では、図４Ｂ３のステップ４２２は、トレースがサブシステムによって呼び出されたコンポーネントから得られている計測されたサブシステムを選択することを含む。例えば、図４Ｂ２では、認証サービスサブシステムとそのトレース４０１を選択する。ステップ４２４は、サブシステムのルートコンポーネントの時間幅からサブシステムの合計時間幅Ｔ１を決定する。例えば、トレース４０１におけるＣＭ１に基づいてＴ１＝１３００ミリ秒になる。ステップ４２６は、サブシステムから計測または未計測の宛先サブシステムに向かう呼び出し（例えば、クロスプロセス呼び出し）に対応するトレースにおけるすべてのコンポーネントを識別する。例えば、トレース４０１においてはＣＭ４ａを識別する。サブシステムの外部の全ての呼び出しの合計時間幅Ｔ２を得るために、ステップ４２８は、識別されたコンポーネントの時間を合計する。ここで、Ｔｃ１＝７００ミリ秒を有するＣＭ４ａのような特定されたコンポーネントが唯一存在し、Ｔ２＝Ｔｃ１＝７００ミリ秒になる。ステップ４３０は、フロントエンド時間とも称される、サブシステムの正味の時間幅Ｔ３を得るため、サブシステムの合計時間幅Ｔ１からサブシステムの外部のすべての呼び出しの合計時間幅Ｔ２を減算する。トレース４０１については、Ｔ３＝Ｔ１−Ｔ２＝１３００−７００＝７００＝６００ミリ秒になる。
【００７９】
ステップ４３２は、識別されたコンポーネントをコンポーネントの宛先サブシステム別によってグループ分けして、各グループ分の時間（例えば、ステップ４２８のＴｃ１、Ｔｃ２．．．のような時間）を合計する。これらの合計は、宛先サブシステムへの呼び出しに対する全時間幅ＴＦである。トレース４０１については、例えば、認証エンジンサブシステムのような宛先サブシステムが１つしかないので、グループは１つしか存在しない。認証エンジンサブシステムの時間の合計は、ＴＦ＝７００ミリ秒である。判断ステップ４３４が、分析するための次のサブシステムが存在するか否かを判定する。分析するための次のサブシステムがある場合は、ステップ４２２から４３２は、次のサブシステムのために繰り返される。例えば、分析するための次のサブシステムは、ステップ４２６で識別される宛先サブシステムを含む。プロセスは、サブシステムのシーケンスの最前段で開始し、１以上の直列パスで呼び出されたサブシステムに連続して入っていく。例えば、認証エンジンサブシステムは、認証サービスサブシステムの宛先サブシステムである。
【００８０】
したがって、図４Ｂ２の認証エンジンサブシステムとそのトレース４０３は、ステップ４２２で選択されている。ステップ４２４は、サブシステムのルートコンポーネントＣＭ７の時間幅からサブシステムの合計時間幅Ｔ１＝６００ミリ秒を決定する。ステップ４２６は、この場合、未計測のバックエンドの顧客レコードデータベースに対して、サブシステムからの呼び出しに対応するＣＭ８、ＣＭ９およびＣＭ１０を識別する。サブシステムの外部のすべての呼び出しの合計時間幅Ｔ２を得るため、ステップ４２８は、識別されたコンポーネントの時間を合計する。ここで、ＣＭ８についてはＴｃ１＝１００ミリ秒で、ＣＭ９についてはＴｃ２＝１００ミリ秒およびＣＭ１０についてはＴｃ３＝１００ミリ秒で、そしてＴ２＝３００秒である。ステップ４３０は、トレース４０３について、Ｔ３＝Ｔ１−Ｔ２＝６００−３００＝３００ミリ秒を提供する。
【００８１】
ステップ４３２は、識別されたコンポーネントをコンポーネントの宛先サブシステム別にグループ分けし、各グループ分の時間（ＴＦ＝Ｔｃ１＋Ｔｃ２＋Ｔｃ３＝３００ミリ秒）を合計する。判断ステップ４３４は、分析するための次のサブシステムが存在するか否かを判定する。判断ステップ４３４で、分析するための次のサブシステムがない場合には、プロセスは、計測され、各エージェントと関連付けられた宛先サブシステムへの各呼び出しを再度行う。具体的には、ステップ４３６は、計測された宛先サブシステムを選択する。図４Ｂ２の例では、認証エンジンサブシステムが再度行われている。ステップ４３８は、宛先サブシステムへの呼び出しのための正味の時間幅ＴＮ＝１００を得るために、宛先サブシステムへの呼び出しの全時間幅ＴＦ＝７００ミリ秒から合計時間幅（Ｔ１＝６００ミリ秒）を減算する。
【００８２】
図５Ａは、詳細表示において、取引の業務サービスがユーザによって選択された場合におけるサブシステムのユーザインタフェース（ＵＩ）および業務トランザクションを示す。ＵＩ５００は、サブシステムが相互に依存する様子、例えばサブシステムを示す頂点と頂点を接続する辺を用いてサブシステムが互いに呼び出す順序等を、図表を用いて示す有向グラフを提供する。さらに、マップは、どのサブシステムが特定の業務トランザクションに関連付けられているかを示す。業務トランザクションは、１以上のコンピューティングデバイスで１以上のサブシステムに関連付けられたコンポーネントを呼び出す。どのサブシステムが潜在的に互いに呼び出すかを判定するために、１以上の管理されたアプリケーションの分析に基づいてマップが作成される。この分析は、管理されたアプリケーションの特定の時間間隔においてコンポーネントデータが得られる前に行われる。マップは、１以上の業務トランザクションのサブシステムを含む。
【００８３】
ユーザインタフェースの領域５０４は、使用可能な業務サービスの表示を提供するために開放されるノード、および使用可能なフロントエンドの表示を提供するために開放されるノードを含むノードのツリーを提供する。業務サービスによるノードは、取引と称される業務サービスのノードを含み、取引は、前述したように、業務トランザクションを構成するためのノード、即ち、残高、ログイン、オプション取引、発注、取引概要を含む。取引はユーザによって選択され、現在の表示はこの選択に基づくものである。この選択は、領域５０４のツリーにおける「取引」に下線を引くことにより示される。
【００８４】
この選択に応答して、多く（１以上）の関連付けられた業務トランザクション、業務トランザクションのサブシステムおよびサブシステム間の依存関係を示す辺が、有向グラフの領域に示されるようにユーザインタフェースのメインエリア５０２に表示される。左側の楕円形の頂点３０４、３０６、３０８、３１０および３１２は、それぞれ業務トランザクションの名称を含んで表す。辺は、業務トランザクションのためにどのサブシステムが最初に呼び出されるか、および、続いて呼び出されるサブシステムを示す。辺は、識別子Ｅｄ１−Ｅｄ２６を示すラベルが付されており、表記「ｄ」が、ＵＩの詳細表示において辺であることを指す。これらの識別子はＵＩに表示されるが、必ずしもそうする必要はない。ある場合には、共通のサブシステムが別々の業務トランザクションのインスタンスのために呼び出される。例えば、認証サービスはオプション取引やログイン業務トランザクションによって呼び出される。
【００８５】
与えられた業務トランザクションのインスタンスに呼び出されたコンポーネントは、コンポーネントが同じサブシステムにあったとしても、一意の識別子を用いて個別に追跡することができる。また、コンポーネントの分離したインスタンスは、別々の業務トランザクションのインスタンスにおいて（単一の）サブシステムで呼び出される可能性もある。これらの分離したインスタンスは、再度、別々に追跡することができる。
【００８６】
また、同じ業務トランザクションの分離した複数のインスタンスは、同じサブシステムを呼び出す必要はないことに注意されたい。例えば、業務トランザクションのインスタンスは、エラーまたはネットワークの障害によっては、エラーが生じなかった場合に呼び出される特定のサブシステムを呼び出すことはない。また、時刻や使用可能なリソースに起因して、同じ業務トランザクションの分離した複数のインスタンスは、別々のサブシステムを呼び出す。これらの簡略化された例には示されていないが、様々なバリエーションが可能である。
【００８７】
頂点の枠は、頂点が強調表示されているか否かを示すために使用されており、強調表示の一種になる場合もある。強調表示は、ある頂点を他の頂点から視覚的に区別する方法である。異なる色が使用されることもある。あるアプローチでは、実線が強調を示す一方で、点線または破線の枠は強調を示さない。二重の枠も同様に使用される。あるアプローチでは、実線の外側の枠は、頂点がユーザによって選択されたことを示し、破線の外側の枠は、ユーザによる他のコマンドに基づいて頂点が視覚的に区別されていることを示す。頂点の強調表示は、領域５０４におけるユーザの選択、およびＵＩにおける頂点そのもののユーザの選択、に反応する。様々な強調表示、色分けおよび他の視覚的な効果が、ユーザに情報を伝達するために提供される。サブシステムのいくつかの頂点は、（ａ）フロントエンドまたは集約されたフロントエンド（例えば、同じアプリケーションコンテキストを共有するすべてのサーブレット）を示す２つの重複する画面のような記号、（ｂ）データベースを表す円筒形の記号、または（ｃ）サブシステムの種類を識別するためにソケット呼び出しの宛先である不明の（未計測の）サブシステムを表す記号を、含む。
【００８８】
他の種類の表記には、メトリックと警告がある。警告は、業務トランザクション（関連付けられたコンポーネントデータに基づくもの）のため、フロントエンドの全体的なパフォーマンス（「正常性」）のため、およびフロントエンドによって未計測のバックエンドまたは別のフロントエンドにされるバックエンドの呼び出しのため、に使用可能である。別のフロントエンドに行われる呼び出しは、マップ上に現われるように、ウェブサービスまたはＥＪＢクライアントを介して行われる。これらの警告は、ユーザによって作成および設定される。したがって、ある与えられた業務トランザクション、フロントエンドもしくはバックエンドの呼び出しは、業務トランザクションのために明示された警告を有する、または有しない。警告が明示される場合、いくつかの状態、即ち、正常（緑色）、注意（黄色）、危険（赤色）、データなし（灰色）、計画的な停止時間（黒色および灰色）が現れる。警告が明示されない場合、業務トランザクションまたはフロントエンド内にはアイコンは現れることなく、小さな「メトリックアイコン」が、メトリックデータはここで使用可能であることを示すために、バックエンドの呼び出しの終点で現れる。
【００８９】
１つのサブシステムから別のサブシステムの呼び出しを表す矢印の終わりに現れる円は、呼び出しのために使用可能な最新のデータが存在するが警告は明示されてはいないことを示している。バックエンドの呼び出しのために警告が明示されている場合には、警告アイコンが重ね合わせられて実質的にメトリックアイコンを置き換える。すべての円／警告のアイコンの欠如は、マップはロードされているので、呼び出しのための見えるメトリックが存在しないことを意味する。メソッド呼び出しのための警告アイコンは、メソッド呼び出しの合計時間幅に基づいて設定される。円は、呼び出されたサブシステムの隣に、矢印の先端に配置される。わかり易くすると、この例では、全体が暗色に着色に着色された円は危険の警告状態を示し、白丸は正常の警告状態を示し、そして半分が暗色に着色された円はメトリックが使用可能で警告が明示されていないことを示す。領域５０４は、どの警告レベルが関連付けられた階層レベルのために表示されるかを示すために、業務サービスおよび業務トランザクションの名称の隣に警告表記を提供している。業務トランザクションのための領域５０４において、円表記（図示せず）が頂点３０４、３０６、３０８、３１０および３１２のための円表記と一致している。対象のサブシステムの関連付けられたすべての宛先サブシステムと同様に、対象のサブシステムの警告レベルは、サブシステムの正常性メトリックに基づいて、最高の警告レベルを表す。また、業務サービスの警告レベルが任意の業務トランザクションの最高の警告レベルとして設定される。
【００９０】
フロントエンドのサブシステムは、ソケットを介してアプリケーションサーバからの呼び出しを行う。これらの呼び出しは、ウェブサービスの呼び出し、ＪＤＢＣドライバの呼び出しまたはその他の呼び出しである。ウェブサービスは、通常、アプリケーションプログラミングインタフェース（ＡＰＩ）またはハイパーテキストトランスファープロトコル（ＨＴＴＰ）を介してアクセスされたウェブＡＰＩであり、リクエストされたサービスをホスティングするリモートシステムにおいて実行される。これらの呼び出し、およびＪＤＢＣドライバの呼び出しのようなその他の呼び出しは、呼び出しを検出して呼び出しに関するメトリックを取得するため、依然としてアプリケーションサーバにあるが、しかしアプリケーションサーバから呼び出すことから、バックエンドコールと称される。したがって、図５Ａにあるように全体のマップは、検出されたフロントエンドおよびフロントエンドがバックエンドに対して行う呼び出しを示す。これらのバックエンド呼び出しの宛先は、他のフロントエンド（ウェブサービスやいくつかのＥＪＢ呼び出しの場合）または未計測のバックエンドのコンポーネントのいずれかである。これらの未計測のコンポーネントのほとんどは、少なくとも部分的にはバックエンド呼び出しから識別される。例えば、ＪＤＢＣドライバの呼び出しは、その宛先データベースの名称でラベルが付されており、デフォルトのソケット呼び出しは、宛先ホストおよびポートでラベル付けされている。他の場合では、ユーザはカスタム呼び出しを定義しその宛先でラベル付けをする。これらのすべての場合で、ＵＩは、データベースまたはコンポーネントの他の適切な型を示すアイコンで適切にラベル付けされたバックエンドの宛先を表すボックスを提供する。
【００９１】
例えば、ソケットを介して呼び出しがあり、その呼び出しは計測されていて５６ミリ秒かかることが判明しているが、その宛先（どのサブシステムをそれが呼び出したか）が不明である場合、ＵＩ内に、バックエンドの頂点と並んで「不明のコンポーネント」のアイコンを示し、システムのホスト名称とポートによってラベル付けされた時間メトリックを表示し得る。バックエンド３２１、３３２、３３４、３３６および３３８は、計測されていない宛先を表しており、宛先としての情報が何も報告されていないので、それらは実質的にマップ内のダミーの頂点である。これらの頂点に隣接した円のアイコンは、フロントエンドからの呼び出しを表す辺の端で、バックエンド呼び出しのメトリックおよびそれに関連付けられた警告のプレースホルダとして機能する。
【００９２】
１つのフロントエンドから別のフロント（３２０から３２６へ、または３２２から３２８へ、または３２４から３３０へなど）への呼び出しには、十分な計測が可能である。呼び出しは、例えば、ウェブサービスまたはＥＪＢクライアントを介して行われる。この例では、詳細表示はボタン３６３を介してユーザによって選択され、ウェブサービス１  ３４１、ウェブサービス２  ３４３、ウェブサービス３ａ  ３４５、ウェブサービス３ｂ  ３４７、ウェブサービス３ｃ  ３４９およびウェブサービス４  ３５１などのように、各ウェブサービスの結果が個別に表される。ウェブサービスはＵＲＬで表される。例えば、ウェブサービス１  ３４１は、http//127.0.0.1:7080/OrderEngine/services/OrderService|getService1のようなＵＲＬで表示される。ウェブサービス２  ３４３は、http//127.0.0.1:7080/OrderEngine/services/OrderService|getService2のようなＵＲＬで表される。ウェブサービス３ａ  ３４５は、http//127.0.0.1:7080/AuthenticateEngine/services/AuthenticationService|getService2のようなＵＲＬで表される。ウェブサービス３ｂ  ３４７およびウェブサービス３ｃ  ３４９のようなＵＲＬは、ウェブサービス３ａ  ３４５と同じＵＲＬで表される。ウェブサービス４  ３５１は、http//127.0.0.1:7080/ReportingEngine/services/ReportingService|getService2のようなＵＲＬで表される。この詳細表示では、同じウェブサービスが、ウェブサービスを呼び出す異なる各サブシステムのために独立したアイコンによって表されている。例えば、ウェブサービス３ａ、３ｂおよび３ｃは、同じウェブサービスの異なるインスタンスであるが、サブシステム３２０によって呼び出されるときにアイコン３４５で、サブシステム３２８によって呼び出されるときにアイコン３４７で、サブステム３２２によって呼び出されるときにアイコン３４９で、表される。別のアプローチでは、１つの共通のアイコンが同じウェブサービスの複数のインスタンスを表すために使用される。図５Ｂを参照されたい。
【００９３】
また、詳細表示で、子および親のコンポーネントを識別する頂点が提供されている。例えば、親の取引サービス３２０内で、頂点３４０は子のサーブレット  発注｜サービスを表し、頂点３４２は子のサーブレット  表示｜サービスを表し、そして頂点３４４は、子のサーブレット  オプション取引｜サービスを表す。発注｜サービスは、発注と名付けられたクラスおよびサービスと名付けられたメソッドを表し、注文表示｜サービスは、注文表示と名付けられたクラスとサービスと名付けられたメソッドを表し、そしてオプション取引｜サービスは、オプション取引と名付けられたクラスとサービスと名付けられたメソッドを表す。すべてのこれらのクラスは、同じアプリケーションである取引サービスの一部である。これらは、アプリケーションサーバに展開される前に、同じアーカイブファイル、ウェブアーカイブファイル（ＷＡＲ）またはエンタープライズアーカイブファイル（ＥＡＲ）にパッケージされ得る。頂点３４０、３４２および３４４は、取引サービスの頂点３２０の子の頂点であることから、頂点３２０内にグループ分けされている。
【００９４】
認証サービス３２２内で、頂点３５０は子のサーブレット  サーブレットＡ｜サービスを表す。報告サービス３２４内で、頂点３６０は子のサーブレット  サーブレットＡ｜サービスを表し、そして頂点３６２は子のサーブレット  サーブレットＢ｜サービスを表す。注文エンジン３２６内で、頂点３２７は子のサーブレット  アクシスサーブレット｜サービスを表す。認証エンジン３２８内で、頂点３２９はサーブレット  アクシスサーブレット｜サービスを表す。報告エンジン３３０内で、頂点３３１は子のサーブレット  アクシスサーブレット｜サービスを表す。
【００９５】
サーブレットまたはサーブレットＡ｜サービスやアクシスサーブレット｜サービスのような他のクラスは、異なるアプリケーションまたはサブシステムによって共有され得ることに注意されたい。例えば、同じJavaアーカイブ（.ＪＡＲ）ファイルまたはライブラリに属するクラスは異なるアプリケーションまたはサブシステムによって共有可能である。この例では、サーブレットＡと名付けられたクラスは、認証サービスおよび報告サービスの両方によって共有された共通ライブラリに属する。「サービス」は、トランザクションに参加するクラスのメソッド名を指す。同様に、アクシスサーブレットと名付けられたクラスは、注文エンジン、認証エンジンおよび報告エンジンによって共有される共通ライブラリに属する。
【００９６】
ユーザがボタン３６１を選択することにより概要表示を選択する場合、子のコンポーネントは表示されない。詳細は図５Ｂを参照されたい。
【００９７】
図５Ｂは、図５ＡのＵＩに代わる概要表示において、業務サービスがユーザによって選択された場合におけるサブシステムのユーザインタフェース（ＵＩ）５０５および業務トランザクションを示す。ここで、単一のフロントエンドから発しているすべてのウェブサービスの呼び出しは、集約され、単一の「ウェブサービス」のバックエンド呼び出しとして表されている。このように、他の種類の呼び出しとは異なり、ウェブサービスの呼び出しは、２以上の宛先を有する。この場合、バックエンド呼び出しは、マップ内の二股分岐または枝分岐の矢印として現れる。１セットのデータだけがこの呼び出しに関連付けられており、２以上の宛先ノードが存在し、１つのアプローチでは、マップにおいて、円に「Ｗ」のアイコンが宛先ノードの横ではなく二股分岐の基部に現れる。
【００９８】
具体的には、図５Ａから、ウェブサービスの頂点５１０は、頂点３４１、３４３および３４５を表す。ウェブサービスの頂点５１０は、二股分岐の基部にあり、宛先ノード３２６および３２８の横にはないため、ウェブサービスの頂点５１０への呼び出しに関連付けられたデータの１つのセットが存在する。図５Ａから、ウェブサービスの頂点５１５は頂点３４７を表す。呼び出しのためには宛先は１つしか存在しないことから、ウェブサービスの頂点５１５は、宛先ノード３２８の横にあるかまたは隣接してある。必要に応じて、ウェブサービスの頂点５１５は、Ｅｓ１１がノード３２２とウェブサービスの頂点５１５との間で依然として延長するようにノード３２２と３２８の間に存在する。しかし、追加の辺（図示せず）がウェブサービスの頂点５１５とノード３２８の間で延長する。ウェブサービスの頂点５１２は、図５Ａから、頂点３４９および３５１を表す。ウェブサービスの頂点５１２は、二股分岐の基部にあり、宛先ノード３２８および３３０の横にはないため、ウェブサービスの頂点５１２への呼び出しに関連付けられたデータの１つのセットが存在する。
【００９９】
ウェブサービス５１０および５１２は、同じくウェブサービスの呼び出しであるが単一の宛先を有するもので、認証サービス３２２と認証エンジン３２８と間の呼び出しの対比として、２つの二股分岐のウェブサービスの呼び出しを示す。さらに、複数の辺は、多くの場合、１つの辺に折り畳まれるので、図５ＡのＵＩ５００よりも辺が少ない。また、辺の識別子は、番号の再割り当てされるか、もしくは、概要表示のために変更される。例えば、ＵＩ５００のＥｄ１およびＥｄ２はＵＩ５０５のＥｓ１に折り畳まれ、ＵＩ５００のＥｄ３およびＥｄ４はＵＩ５０５のＥｓ２に折り畳まれ、ＵＩ５００のＥｄ５はＵＩ５０５のＥｓ４に、ＵＩ５００のＥｄ６はＵＩ５０５のＥｓ５に、ＵＩ５００のＥｄ７はＵＩ５０５のＥｓ６に、ＵＩ５００のＥｄ８はＵＩ５０５のＥｓ７に、ＵＩ５００のＥｄ９からＥｄ１３はＵＩ５０５のＥｓ８に折り畳まれ、ＵＩ５００のＥｄ１７およびＥｄ１８はＵＩ５０５のＥｓ９に折り畳まれ、ＵＩ５００のＥｄ２３はＵＩ５０５のＥｓ１５に、ＵＩ５００のＥｄ２４はＵＩ５０５のＥｓ１６に、ＵＩ５００のＥｄ１９はＵＩ５０５のＥｓ１０に、ＵＩ５００のＥｄ１４およびＥｄ２０はＵＩ５０５のＥｓ１１に折り畳まれ、ＵＩ５００のＥｄ１５およびＥｄ１６はＵＩ５０５のＥｓ１２に折り畳まれ、ＵＩ５００のＥｄ２１はＵＩ５０５のＥｓ１３に、ＵＩ５００のＥｄ２２はＵＩ５０５のＥｓ１４に、ＵＩ５００のＥｄ１７はＵＩ５０５のＥｓ２７に、ＵＩ５００のＥｄ２５はＵＩ５０５のＥｓ１７に、そしてＵＩ５００のＥｄ２６はＵＩ５０５のＥｓ１８に折り畳まれる。表記「ｓ」はＵＩの概要表示における辺を指す。レコードまたはマッピングが維持されて、詳細表示の辺の識別子に対する概要表示の辺の識別子を相互参照する。例えば、Ｅｄ１およびＥｄ２は、Ｅｓ１に対応付け［マッピング］される。詳細レベルの頂点は、例えば、頂点３４０、３４２、３４４、３５０、３６０、３６２、３２７、３２９および３３１が削除される。
【０１００】
さらに、頂点はサブシステムの複数のインスタンスを表すことを想起されたい。例えば、取引サービスの頂点３２０は、複数のマシンにまたがって実行する取引サービスのサブシステムの複数のインスタンスの概要を表す。ウェブサービス５１０は、取引サービス３２０のサブシステムが実行する１以上のコンピューティングデバイス／マシンに関連付けられており、ウェブサービス５１２は、報告サービス３２４のサブシステムが実行する１以上のコンピューティングデバイス／マシンに関連付けられている。ウェブサービス５１０および５１２のメトリックまたは警告のアイコンは、１つのコンピューティングデバイスから次のコンピューティングデバイスへ行われるメソッド呼び出しの性能または正常性を表す。
【０１０１】
１つのアプローチでは、警告は、応答時間などの時間メトリックに関連している。警告は、正常状態が第１レベルＬ１未満の応答時間に対して示されるように設定可能で、注意状態がＬ１から第２レベルＬ２の間の応答時間に対して示され、危険状態がＬ２よりも大きい応答時間に対して示される。警告は、性能メトリックのどんな種類に基づいても設定可能である。例えば、計測は多くの種類の性能メトリックを生成することができ、それらには、コンポーネントの平均実行時間または応答時間、毎秒または間隔ごとの呼び出し率、呼び出し回数、開始したが終了していない間隔ごとの呼び出しの回数を示す同時実行のメトリック、および呼び出しを開始した間隔ごとのメソッド呼び出しの回数が特定の閾値を超えた呼び出し回数を示すストール状態のメトリックが含まれる。これらは、アプリケーション実行時間において取得され、エージェントによって報告された、コンポーネントデータの例である。警告は、どんな種類のアイテムにも提供可能である。
【０１０２】
また、サブシステムをサポートするコンピューティングマシン上で使用されるリソースに対して、計測は、例えば、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定するようなデータを生成する。警告は、またどんな種類のアイテムにも提供可能である。
【０１０３】
さらに、警告は、特定のパラメータを有するＵＲＬのような業務トランザクションコンポーネントための１以上の性能メトリックに基づいて設定可能である。例えば、警告は、特定の時間を超えた業務トランザクションコンポーネントの平均応答時間を表す。
【０１０４】
後述するように、警告およびメトリックアイコンに基づいて、ユーザは、ＵＩに示された、業務トランザクション、サブシステムおよび呼び出し、に関するさらなる情報を取得するために様々な手段を得ることができる。１つのアプローチでは、ユーザは、警告およびメトリックアイコンの存在によって案内され、関連付けられた、業務トランザクション、サブシステムおよび呼び出しに関するさらなる情報を、例えば問題を診断するために取得しようとする。また、後述するように、他の種類の情報が、診断を支援するためにＵＩに表示される。一般的に、本明細書で提供される様々なＵＩが１以上のウィンドウで提供され、情報にアクセスするための、ポップアップウィンドウ、マウスオーバーもしくはホバーボックス、ツールチップならびに右クリックのような既知のＵＩの技術をＵＩが使用する。
【０１０５】
特定の業務トランザクションおよびそのサブシステムについて、ＵＩは、発注３１０、およびオプション取引３１２の両方が、フロントエンドのサブシステム、即ち取引サービス３２０を呼び出すことを示している。ある設定例では、例えば、株や債権の売買をするため、発注される注文を決めることにより、ユーザは発注３１０を開始する。すべての、ユーザ入力ならびにユーザに与えられる情報もしくは指示が、ウェブページまたは他のＵＩを介して提供される。または、プットオプションやコールオプションのようなオプションに関係する取引を決めることによって、ユーザはオプション取引３１２を開始する。いずれの場合も取引サービスが使用される。取引サービスは、例えば、注文／取引を処理するために付加的な情報を取得するシステムローカルホスト３２１を呼び出す。システムローカルホスト３２１は、計測されていないことからそれについてはあまり知られておらず、その頂点は単なるプレースホルダである。取引サービスのインスタンスにより呼び出されるコンピューティングデバイス３２１のポートが知られており（例えば、ポート３４５６）、この情報が頂点３２１を修飾するために使用される。システムローカルホスト３２１は、別のホストまたはリソース（図示せず）を呼び出し得るが、これは図示されていない。
【０１０６】
コンピュータネットワークでは、ポートは、通信のエンドポイントとして貢献するアプリケーション固有またはプロセス固有のソフトウェアの構成である。例えば、トランスミッションコントロールプロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）のようなインターネットプロトコルスイートのトランスポート層のプロトコルによって使用される。特定のポートは、一般にポート番号として知られている番号、関連付けられたＩＰアドレス、および通信に使用されるプロトコルによって識別される。ＴＣＰおよびＵＤＰは、パケットのヘッダ内の送信元と宛先のポート番号を特定する。プロセスは、バインディングとして知られるプロセスで、ネットワークを介してデータを送受信するため、その入出力チャンネルのファイル記述子（ソケット）をポート番号およびＩＰアドレスと関連付ける。オペレーティングシステムのネットワーキングソフトウェアは、すべてのアプリケーションのポートからネットワークへの出て行くデータを送信するとともにパケットのＩＰアドレスとポート番号を一致させることによって到着するネットワークパケットをプロセスに転送する、タスクを有する。
【０１０７】
プロセスは、ソケットを用いて転送プロトコルのポートとの関連付けを作成する。ソケットは、転送のエンドポイントとして使用されるソフトウェア構造である。プロセスのためにオペレーティングシステムによって作成され、ポート番号とＩＰアドレスの組み合わせで構成されたソケットのアドレスに結び付けられている。ソケットは、一度に一方向に（半二重）または同時に双方向に（全二重）データを送受信するために設定される。
【０１０８】
取引サービス３２０は、注文／取引をリクエストするために、１以上のウェブサービス（ウェブサービスの頂点５１０に集約されている）を使用する。ウェブサービス５１０は、ユーザの認証情報を検証するために、（ａ）注文／取引を処理する注文エンジンサブシステム３２６、および／または、（ｂ）注文／取引を認証する認証エンジンサブシステム３２８、を順々に呼び出す。マップは、ほぼ同じ時間にまたは異なる時間（例えば、注文レコードデータベースへの呼び出しが行われた後）に、同じ業務トランザクションの一部または異なる業務トランザクションの一部（結局、取引サービスに関連付けられた２つの業務トランザクションが存在する）等として、これらの他サブシステムの両方を取引サービスが呼び出すことを必ずしも示すわけではない。他サブシステムは、同じ業務トランザクションの一部として呼び出されることも可能であるが、それは異なるインスタンス間である。マップは、特定された期間のあるポイントで、取引サービスがウェブサービス５１０を用いてこれらのフロントエンドの両方を呼び出したことを伝えている。
【０１０９】
ウェブサービス５１０からの１以上の呼び出しを処理するために、注文エンジンサブシステム３２６は、２つのバックエンド、即ちＳＱＬ文を使用して注文レコードを格納する注文レコードデータベース３３２とシステムローカルホスト３３４を呼び出す。システムローカルホスト３３４は、例えば、ＪＤＢＣドライバの一部としてマークされていない管理ハンドシェイクまたはその他のタスクのために使用される。認証エンジンサブシステム３２８は、例えば、ユーザ／顧客が注文／取引を行うことについて認証されていることを確認するため、顧客レコードを格納する顧客レコードデータベース３３６を呼び出す。
【０１１０】
ログイン３０４の業務トランザクションは、フロントエンドのサブシステム、即ち認証サービス３２２を含む。設定例では、前述したように、ログインは、認証サービスサブシステム３２２においてコンポーネントＣＭ１からＣＭ４ａを呼び出し、認証エンジンサブシステム３２８においてＣＭ７からＣＭ１０を呼び出す。
【０１１１】
辺５１３（Ｅｓ１１）によって示されるように、認証サービスサブシステム３２２よりも同じサーバまたは異なるサーバになる認証エンジンサブシステム３２８において、ＣＭ４ａはＣＭ７を呼び出す。ＣＭ７はＣＭ８を呼び出し、ＣＭ８は、ユーザのログインがパスワードと一致することを確認するための顧客レコードにアクセスするために顧客レコードデータベース３３６を呼び出す。これが成功すると仮定すれば、制御フローはＣＭ７に戻り、ＣＭ７がＣＭ９を呼び出す。ＣＭ９は、アカウントを維持するため、例えば、ユーザが料金を支払ったり最低限度の取引を行ったりするなどして、ユーザのアカウントが有効であることを確認するために顧客レコードに再びアクセスして、顧客レコードデータベース３３６（または別のデータベース）を呼び出す。これが成功すると仮定すれば、制御フローはＣＭ７に戻り、ＣＭ７はＣＭ１０を呼び出す。ＣＭ１０は、ユーザが現在ログインしていることを示すため、レコードを更新するために顧客レコードに再びアクセスして顧客レコードデータベース３３６（または別のデータベース）を呼び出し、login status=trueをＣＭ７に返す。制御フローは、次にＣＭ２に戻り、ＣＭ２はＣＭ４ｂを呼び出してＣＭ４ｂがＣＭ５を順々に呼び出す。制御フローは、次にＣＭ４ｂに戻り、その次にＣＭ２に戻って最後にログイン業務トランザクションのインスタンスが終了するポイントであるＣＭ１に戻る。
【０１１２】
残高３０６および取引概要３０８の両方が、共通のフロントエンドのサブシステム、即ち報告サービス３２４を呼び出す。設定例では、ユーザは、例えば、特定のアカウントでの資金量を知るために口座残高を取得するリクエストを行うことによって、残高を開始する。また、ユーザは、例えば注文／残高、送金などの最近のトランザクションの報告（例えばステートメント）を取得するためにリクエストを行うことによって取引概要３０８を開始する。いずれの場合も、報告サービス３２４はウェブサービス５１２を呼び出すことによって報告のリクエストを処理し、同様に、ウェブサービス５１２は認証エンジンサブシステム３２８を呼び出して、認証エンジンサブシステム３２８は、ユーザ／顧客が報告を取得することを承認されていることを確認するために顧客レコードにアクセスするため、顧客レコードデータベース３３６を呼び出す。
【０１１３】
一実施形態では、制御フローは報告サービス３２４に戻り、報告サービス３２４はウェブサービス５１２を介して報告エンジンサブシステム３３０への別の呼び出しをして、報告エンジンサブシステム３３０は報告を提供するために使用されるレコードを取得するため、報告レコードデータベース３３８を呼び出すことによって報告のリクエストを遂行する。ウェブサービス５１２へのこの呼び出しには、必要とされる報告の種類、アカウントの識別子、関連する時間フレームなどを特定する情報を含む。
【０１１４】
図４Ｂ１から図４Ｂ３に関連して説明したように計算された時間メトリックは、対応する頂点の上に表されるようにＵＩ５０５に表示される。つまり、ＵＩおよびその頂点（子および親の頂点を含む）と辺は、メトリックによって修飾されている。合計時間幅、正味の時間幅および／または待機時間が表示される。ここで、ログインの合計時間幅（１３００ミリ秒またはミリ秒）がログインの頂点３０４の上に、６００ミリ秒の正味の時間幅が認証サービスの頂点３２２の上に、認証エンジン３２８への呼び出しのためサブシステム相互の通信時間（１００ミリ秒）が辺５１３の上に表示され、時間幅３００ミリ秒が認証エンジンの頂点３２８の上に表示され、顧客レコードに割り当てられる３００ミリ秒の待機時間が辺６１３の上に表示される。頂点と辺はこのようにメトリックで修飾されている。これらのメトリックは、ログインのような業務トランザクションの単一のインスタンスに対するものであるか、またはより一般的には、特定の時間間隔に亘る業務トランザクションの複数のインスタンスの平均である。
【０１１５】
ログインの頂点３０４に対して表示されている危険レベルの警告は、例えば１０００ミリ秒のような閾値レベルを超える１３００ミリ秒の時間に基づくものである。認証サービスの頂点３２２に対して表示されている危険レベルの警告は、例えば３００ミリ秒のような閾値レベルを超える６００ミリ秒の時間に基づくものである。辺５１３に対して表示されている危険レベルの警告は、例えば５０ミリ秒のような閾値レベルを超える１００ミリ秒の時間に基づくものである。認証エンジンの頂点３２８に対して表示される正常レベルの警告は、例えば５００ミリ秒のような閾値レベルを超えない３００ミリ秒の時間に基づくものである。辺６１３の先端（例えば、バックエンド呼び出しの終点）の半分が暗色に着色された円が、関連したメトリックが使用可能であって警告が定義されていないことを示している。
【０１１６】
一般的に、ＵＩ５１０には、様々な業務トランザクション、サブシステムおよび呼び出しに対する時間メトリックが付加される。時間メトリックは、ログイン業務トランザクション３０４に対して単純に示されているにすぎないが、実際には、すべての業務トランザクションに対して同時に表示可能である。複数の時間メトリックが異なる業務トランザクション（例として、発注３１０およびオプション取引３１２によって呼び出される取引サービス３２０）によって呼び出されるサブシステムと関連付けられている場合、各時間メトリックは、色分けまたは他の可視化技術によって業務トランザクションの１つに関連付けられる。例えば、発注と関係付けられた時間メトリックは、取引サービスの頂点３２０の上にある一色で表示され、一方、オプション取引に関連付けられた別の時間メトリックは、取引サービスの頂点３２０の上に別の色で表示される。
【０１１７】
時計のアイコン５１１は、ログイン業務トランザクションのすべてサブシステムの間において、最長の正味の時間幅（または合計時間幅、または待機時間）を有するサブシステムに提供される。２つの正味の時間幅が許容範囲内で同じの場合、高いレベルのサブシステムがアイコンを受け、アイコンは両方のサブシステムで表示される。またはアイコンは表示される必要はない。
【０１１８】
このようにして、ユーザは、与えられたサブシステムに問題があることを迅速に確認でき、そのサブシステムに関する診断に重点的に取り組むことができる。問題のある複数のサブシステムもまた特定される。また、警告の重大度はユーザに指針を与える。例えば、通常レベルの警告が認証エンジンサブシステムに表示され、危険レベルの警告が認証サービスサブシステムに表示される場合、ユーザは、最初に認証サービスサブシステムを調査するように導かれる。様々な技術が提供され、それによってユーザはサブシステムとそれが呼び出すコンポーネントに関する付加的な詳細を取得可能となる。
【０１１９】
ＵＩ上で提供されているメトリックは、特定の時間間隔で、管理されたアプリケーションからのデータに基づいている。１つのアプローチでは、ＵＩは、最初はメトリックなしで表示され、例えば、ユーザに規定されたフィルタ基準と一致するトランザクションを見つけることによってメトリックを取得するためのコマンドをユーザが入力する。ユーザは、手動で基準を規定でき、または１以上の基準のデフォルトセットが使用される。そして、ＵＩには、基準と一致するトランザクションによるメトリックが付加される。別のアプローチでは、ＵＩは、フィルタ基準のデフォルトセットに基づいてキャプチャされたメトリックを最初に表示する。
【０１２０】
図５Ｃは、ログイン業務トランザクション３０４のためのメトリックを示すホバーボックスを付加した図５Ｂのユーザインタフェースを示す。ユーザは、関連した性能メトリックを表示するため、業務トランザクション、サブシステムもしくはウェブサービスの呼び出しの頂点の上または辺の上にカーソル（角度のある矢印で表される）を指すように、例えばマウスのようなポインティングデバイスを使用する。一般的に、ユーザは、後述するように、ＵＩの補助領域に関連情報を表示させるため、選択を入力するために頂点を指してクリックする。エレメントを指すと、通常、上に重なるツールチップが出現し、エレメントをクリックすると（例えば選択すること）、通常、ＵＩの別の部分に関連した情報を表示する。頂点は、例えば、業務トランザクションの全体または業務トランザクションのサブシステムに関連付けられている。特定の性能メトリックおよびその形式は設定することができる。ここで、カーソルがログインの頂点をしばらく指したままでいると、ホバーボックス５２２が出現する。そして、ユーザは、選択された業務トランザクションと関連付けられたメトリックを表示するためにコマンドを提供する。
【０１２１】
ホバーボックスは、警告レベルおよび関連した時間間隔の性能メトリックと同様に、業務トランザクション（ログイン）の名称を特定する。警告レベルは危険な状態を示す。次に、１３００ミリ秒の平均応答時間（合計時間幅）が表示される。この設定では、一例として、ログインの応答時間は、ログインの４つのインスタンスの平均である。「カウント」は、分析対象の時間間隔である最新の時間間隔でのログインのインスタンスまたは呼び出しの回数を示す。ここで、カウント＝４は、４つの呼び出しを示す。「最小」は、最小応答時間、例えば１１００ミリ秒を示し、「最大」は、最大応答時間、例えば１５００ミリ秒を示す。「間隔ごとのエラー数」は、最新の時間間隔におけるログインでのエラーの数を特定する。「間隔ごとの応答数」は、４つの応答のようにログインに関連付けられた応答の数を特定する。「ストールカウント」は、ゼロストールのように最新の時間間隔におけるログインでのストール数を特定する。ホバーボックスは、選択された業務トランザクションを報告する、すべてのコンピューティングデバイス／エージェントに亘る概要性能データを提供する。
【０１２２】
図５Ｄは、認証サービスサブシステム３２２のためのメトリックを示すホバーボックスを付加した図５Ｂのユーザインタフェースを示す。ＵＩ５２５において、例えば、頂点３０４を経由した業務トランザクションのためにホバーボックスを提供することに加え、メトリックを有するホバーボックスがログインの任意のサブシステムのために同様に提供される。例えば、認証サービスサブシステム３２２のためのホバーボックス５２３は、サブシステムに特有のメトリック、例えば、警告レベル、平均応答時間、同時呼び出しの回数、間隔ごとのエラー、間隔ごとの応答およびストールカウントを示す。
【０１２３】
したがって、与えられたサブシステムに対して、ユーザは、関連付けられた性能メトリックの表示を起動する。これは、サブシステムを通過するすべてのトランザクションに亘るもので、そのため一般的な正常性または全体のパフォーマンスを表す。
【０１２４】
さらなる例として、ウェブサービス３４２ためのホバーボックスが、取引サービス３２０によって行われた呼び出しに特有の類似したメトリック、例えば、警告レベル、平均応答時間、間隔ごとのエラー、ストールカウントを示す。
【０１２５】
また、ユーザは、エージェントおよびエージェントごとのデータを報告する一覧表の表示を起動させる。エージェントごとのデータとともに、依存関係マップは、例えば、特定の業務トランザクションを報告するすべてのコンピューティングデバイス／エージェントに亘る全体の正常性データのような概要性能データを表示する。現在値がホバーボックスで表示されて、時間的傾向も、例えば、下方のタブに、トランザクションの一覧表、詳細およびトレース表示のラベルが付けられ、補助領域において使用可能である。最終的に、同じ種類の概要データもまた、ホバーボックスのスナップショットと時間的傾向の両者に対して特定されたサブシステム（フロントエンドとそれらのバックエンドの呼び出し）のためにも使用可能である。
【０１２６】
ツールチップのデータ（および図５Ｌに示されるデータチャート）は、すべてのエージェントにおいて関連したすべてのトランザクションに亘って要約されるので、「一般的な正常性」または「全体的な性能」に対応する。寄与エージェントおよびバイエージェントの性能メトリックを一覧表にする場合（図５Ｋにあるように）、表にされたエージェント（例えば、特定のＪＶＭで実行される）によって報告された関連したすべてのトランザクションに亘って要約する。これをサブシステムの単一の「ロケーション」と称し、場所の正常性メトリックについて説明する。
【０１２７】
図５Ｅは、ログインためのオプションを示すコンテキストメニュー５３２を付加した図５Ｂのユーザインタフェースを示す。一般的に、頂点３０４のような業務トランザクションの頂点は、ポインティングデバイスを介して入力されるコマンドのような頂点に関連付けられたユーザコマンドを提供するために使用される。ユーザは、頂点に特有のオプションの一覧表をＵＩ５３０に表示させるため、頂点を指してマウスを右クリックする。そして、１つの可能なアプローチとして、カーソルでオプションを指定して左クリックすることによってオプションが選択される。
【０１２８】
例えば、コンテキストメニュー５３２は、ログイン３０４に関する付加的な情報を取得するため、ユーザが４つのオプションから選択することを許容する。第１のオプションは、図５Ｆのインタフェースとなるログインのマップを表示することである。第２のオプションは、図５Ｇのインタフェースとなる一致するトランザクションを検索することである。第３のオプションは、図５Ｋのインタフェースとなるログインのためのロケーション（例えば、寄与エージェントおよびそれらと関連付けられた正常性メトリックのデータ）を検索することである。第４のオプションは、図５Ｌのインタフェースとなるログインのための正常性メトリックを表示することである。例えば、正常性メトリック、性能メトリックのセットは、ログインの全体的な正常性を示す。
【０１２９】
図５Ｆは、図５ＥのＵＩのコンテキストメニュー５３２から起動されるログイン業務トランザクションのマップのユーザインタフェースを示す。「ログインのマップを表示する」が選択される場合、領域５０４のツリーは、ログインが選択されたことを示すために自動的に更新され（例えば下線により）、ＵＩ５４０は、この選択された業務トランザクションについての詳細を提供する。あるいは、ユーザは、コンテキストメニュー５３２を使用する代わりに、ツリーにおいて、対応する頂点を選択することによって領域５０４からログインを選択することができる。また、ユーザは、矢印のカーソル（図示された）を使用することによってログインの頂点３０４でダブルクリックする。頂点３０４でシングルクリックすることにより、頂点を選択して、補助表示領域または下部の表示枠５６２（後述）を出現させることができる。
【０１３０】
ここで、ユーザの選択によりＵＩは、ログイン３０４を表す頂点３０４ならびに関連したサブシステムの頂点３２２、３２８および３３６を太実線枠で強調表示する。また、頂点の枠を変更することで強調表示することは１つのオプションで、色の使用や影および／または他の視覚的効果も可能である。ログインに関連付けられた辺もまた、例えば、線幅を増やすなど他の可視化技術によって強調表示される。この強調表示によって、ユーザは、サブシステム間の依存関係の呼び出しと同様に、ユーザが選択した業務トランザクションに関与するサブシステムを容易に識別して集中することができる。ユーザが選択した業務トランザクションに関与していないサブシステムの頂点は、強調表示されることなく、例えば、破線や点線の枠により重視されない。強調表示は、１つの頂点または辺を別の頂点または辺から視覚的に区別する１つの方法である。
【０１３１】
図５Ｇは、図５ＥのＵＩのコンテキストメニュー５３２から起動されるログイン業務トランザクションに一致するトランザクションを検索するユーザインタフェースを示す。ＵＩ５５０において、ウィンドウ５６４が表示され、例えばログインのような現在選択されている業務トランザクションのために一致するトランザクションのインスタンスをユーザが検索することを許容する。ウィンドウは、トランザクションのマッピングモードにおいて、将来のある期間にアプリケーションの計測からデータを取得するのに使用される１以上のフィルタ基準でユーザがコマンド入力することを許容する。例えば、ログインが異常に長いログイン時間を要する場合のようなクライアントのコンピューティングデバイスのユーザがアプリケーションにログインの問題を抱えている状況を考える。ユーザは、ヘルプセンターの担当者に電話して問題を説明する。ヘルプセンターの担当者は、トランザクションからのメトリックの新しい記録を開始する一方、問題が起きた同じ手順をユーザに繰り返すように指示するなどして問題を診断する措置をとる。これは、ヘルプセンターの担当者が、問題がそのユーザにいつも起きるといった特定のユーザに固有のものであるか、またはログインを試みるすべてまたは大半で起きるといった一般的なものであるか、を判断するのに役立つ。問題がユーザに固有のものである場合、追加の一致するトランザクションがそのユーザに対してだけ設置される。ウィンドウ５６４は、フィルタ基準としてクライアントのコンピューティングデバイスのユーザを識別するフィールド（ユーザＩＤ）を含む。問題が一般的であるかまたは限定的であるかを決定することは、問題の発生源を区分けするのに有用である。
【０１３２】
ヘルプセンターの担当者は、例えば、次の数秒または数分のようなその後の監視期間におけるデータの記録を構成することによって追加のデータを取得することができる。ヘルプセンターの担当者は、ミリ秒またはそれ以上の特定の時間である、トランザクションに対する閾値の時間幅を入力する。これは、閾値を超えたその後のログイン業務トランザクション（例えばＣＭ１を呼び出すトランザクション）について、コンポーネントデータだけがＵＩを介してキャプチャされて表示されることを意味する。場合によっては、１つのアプローチでは、業務トランザクションは、最初のスレッドがキャプチャされて表示されるケースでは、複数のスレッドを含む。構成に応じて、すべてのスレッドをキャプチャし得るが、通常、最初のスレッドの最初のコンポーネントによってトレースを一覧表にしたり／ラベルを付けしたりする。
【０１３３】
さらに、ヘルプセンターの担当者は、（ａ）特定の秒数、および（ｂ）一致するトランザクション（例えば、一致するインスタンスまたはトレース）の特定の数が検出された後よりも早い時期の後に終了する期間を設定する。例として、ヘルプセンターの担当者は、１０００ミリ秒の閾値に設定し、１８０秒（３分）後、または一致するトランザクションが１０になった後、のいずれか早く到来する方で停止する。ヘルプセンターの担当者は、その監視期間を開始するために「ＯＫ」ボタンを選択するか、または新しい監視期間を開始することなくウィンドウを閉じるために「閉じる」ボタンを選択する。
【０１３４】
ウィンドウ５６４は、エージェントもしくはホスト識別子、または他の要因によってフィルタリングするのと同様に、最小値および最大値のトランザクションの時間幅を含む任意のフィルタ基準を設定するために使用される。
【０１３５】
一致するトランザクションについての情報は、補助領域５６２に示されている。補助領域５６２は、合計時間幅、または各トランザクションのインスタンスの、報告エージェント識別子の、エージェントが実行するホストの識別子の、およびトランザクションの開始時刻のタイムスタンプの、その他の時間メトリックを一覧表にするテーブルを提供する。時刻は、時間、分および秒で載せられている。秒の小数点以下の桁も提供されている。補助領域５６２は、トランザクションのインスタンスに関連付けられた性能メトリックの任意の型を提供する。
【０１３６】
例えば、１５秒ごとに収集するメトリックは、このトランザクショントレースのデータと異なる。トランザクショントレースは、一致するトランザクションを記録すること、および呼び出しシーケンスと各呼び出しの合計時間幅（とシーケンスの合計時間幅）を識別することに関与する。また、特定のトランザクションがエラーを報告したか否かについての情報を取得する。
【０１３７】
補助領域５６２は、例えば、ウィンドウまたはＵＩ５５０の他の部分として、または分離したディスプレィ画面に表示される。補助領域が有向グラフの領域５０２と同時に表示されると有用である。補助領域はＵＩの任意の部分に現れる。
【０１３８】
ユーザは、補助領域５６２のテーブルエントリをソートするために、列の見出しをクリックする。別のアプローチでは、補助領域５６２は、１つの軸が時間を表し、１以上の他の軸が他のテーブルの見出し、例えば、時間幅、トランザクションＩＤ、エージェントＩＤおよびホストＩＤを表す、２以上の軸に基づいて結果を表す。棒グラフ、円グラフなどのその他の視覚的な表示も可能である。最長の時間幅のトランザクションが、例えば診断などのために迅速に識別される。
【０１３９】
ここでは、４つのトランザクションが設置されており、２つはホストＡにおけるエージェントＡからで、また２つはホストＢにおけるエージェントＢからである。エージェントＡにおけるトランザクションの応答時間（合計時間幅）は、平均１１５０ミリ秒の、１１００ミリ秒と１２００ミリ秒である。エージェントＢにおけるトランザクションの応答時間（合計時間幅）は、平均１４５０ミリ秒の、１５００ミリ秒と１４００ミリ秒である。４つのトランザクションの平均応答時間は、従って１３００ミリ秒である。ユーザは、補助領域５６２に現在表示されている同じ型のトランザクションのインスタンスをもっと取得するため、「さらに検索」ボタンを選択することができる。１つのアプローチでは、この検索は、ユーザが基準を再入力することを要求されないように、ウィンドウ５６４によって設定された同じフィルタ基準を自動的に使用する。つまり、「さらに検索」コマンドは、以前と同じ基準を使用してトランザクショントレースのセッションを繰り返す。または、ユーザは新しい基準で再び検索可能である。いずれの場合も補助領域５６２は、以前の結果の代わりにまたは加えて、新しい結果で更新する。
【０１４０】
補助領域５６２は、付加的な一致するトランザクションが識別されると、リアルタイムで更新される。さらに、領域５６６は、完了以前に検索の進行状況をユーザに知らせる。ここで、ユーザは、時間幅における１０００ミリ秒を超える４つのトランザクションが今のところトレースされ／割り当てられ、検索における残り時間は５３秒であることを知らされる。領域５６６のボタンは、ユーザが現在の検索を停止または再開することを許容する。付加的なトランザクションが割り当てられているので、補助領域５６２の相対的な大きさは、あるポイントまで拡張される。すべての結果を同時に表示するには画面上に十分なスペースがない場合、スクロール機構は、ユーザが付加的なトランザクションを見ることを許容する。あるアプローチでは、結果は、テーブルのエントリや行として表示される。「クリア」ボタンは、一覧表から古いトランザクションのインスタンスのすべて、つまり以前の記録のセッションからのすべてのトレースをユーザが削除することを許容する。エントリの隣のチェックボックスを選択し、次に「削除」ボタンを選択することにより、個々のエントリはユーザによって削除される。
【０１４１】
記録のセッションが終了し、補助領域５６２において選択されたトランザクションがない場合、ログインの頂点の近くに配置されたタイミングデータは、メトリックの現在のセットを反映するために更新される。例えば、ログインの平均時間幅（１３００ミリ秒）が表示される。関連付けられたサブシステムの頂点３２２、３２８および３３６の平均合計時間幅およびサブシステム相互の通信時間もまた表示される。ユーザが、補助領域５６２における１以上のトランザクションをチェックボックスで選択し、その後で「マップで表示」ボタンを選択する場合には、有向グラフの領域５０２が対応するメトリックで更新される。例えば、最初の２つのエントリが選択される場合、１１５０ミリ秒の時間幅が、ログインの頂点３０４に提供され、応答するメトリックが他の頂点に任意に提供される。
【０１４２】
いくつかのトランザクションに対しては、すべてよりも少ない業務トランザクションが呼び出されることが可能であることに注意されたい。ユーザが「マップで表示」に続いて補助領域５６２からそのトランザクションのインスタンスを選択する場合、これは、有向グラフの補助領域５０２の他のサブシステムではなく、呼び出されたサブシステムだけを強調表示することによって反映される。例えば、図５Ｊに示すように、トランザクションのインスタンスの１つは、認証エンジンまたは顧客レコードではなく、認証サービスを呼び出す。その場合、頂点３０４および３２２は強調表示されるが、頂点３２８および３３６、または辺５１３および６１３は強調表示されない。
【０１４３】
図５Ｈは、選択された業務トランザクションのコンテキストにおける認証サービスサブシステムに一致するトランザクションを検索するユーザインタフェースを示す。業務トランザクションに関係付けられているトランザクショントレースを検索することに代わるものとして、選択された業務トランザクションのコンテキストにおける、ユーザが選択した１以上のサブシステムに関連付けられたトランザクションのトレースを検索することが可能である。この例では、ユーザがＵＩ５５５における認証サービスサブシステムのために領域５０４のフロントエンドの表示を選択する。フロントエンドの表示は、フロントエンドサブシステムから発しているすべてのトランザクションを表す。この選択により、選択されたサブシステムに関係付けられていない領域５０２における頂点は削除される。必要に応じて、関係付けられた業務トランザクション３０４および３１２の頂点は残る。さらに、認証サービスサブシステムに依存する１以上の付加的なサブシステムが表示される。例えば、別の不明のコンポーネント（ソケット）３２３が示される。認証サービスは、取引業務サービスの一部であると定義されるどんな業務トランザクションも含まないバックアップシステムを時々呼び出す。この場合、そのバックアップシステムは、フロントエンド表示に現れるが、取引業務サービスのマップには現れない。
【０１４４】
ここで、ユーザは、コンテキストメニュー（図５Ｅにおけるコンテキストメニュー５３２のような）を呼び出すためにアイコンを指すことによってアイコン３２２を選択し、一致するトランザクションを検索するために「一致するトランザクションを検索する」を選択し、その結果、ウィンドウ５６５が表示される。この例では、ログイン業務トランザクションが選択され、ログイン業務トランザクション内でのみ認証サービスを呼び出すトランザクションが一致するトランザクションとして検索される。閾値は、サブシステムの合計時間幅と比較して実行される。閾値は、再びこの例では、１０００ミリ秒と設定されている。このように、フロントエンドに関係なく特定の業務トランザクションのためのトランザクションを検索する以前の例と同様に、フロントエンドと業務トランザクションのためにフィルタと合致するトランザクションのインスタンスを検索する。換言すると、最初のサブシステムが認証サービスである、ログインのすべての業務トランザクションを探す。
【０１４５】
上記の例では、３以上の業務トランザクションがサブシステムを呼び出す場合に拡張可能である。例えば、ユーザは、第３ではなく、第１および第２の業務トランザクションをフィルタ基準として選択する。
【０１４６】
図５Ｉは、複数の業務トランザクションのコンテキストにおける認証サービスサブシステムに一致するトランザクションを検索するユーザインタフェースを示す。図５Ｈとは対象的に、ユーザインタフェース５５６は、すべての関連付けられた業務トランザクションに亘って認証サービスのための一致するトランザクションをユーザが設定することを許容する。ここで、ログインやオプション取引のためのアイコンが選択されることなく、認証サービスのアイコン３２２が選択される場合、ウィンドウ５６７は、フィルタ基準が特定の業務トランザクションを特定しないということを示す。必要に応じて、例えば、図５Ｇのような業務トランザクションの表示から、ユーザは、業務トランザクションから独立し選択されたサブシステムに一致するトランザクションをリクエストすることができる（業務サービスがツリー内から選択された場合、これはデフォルトになる）。その後、図５Ｉにあるように、トレースを実行する前にユーザをそのサブシステムのためにフロントエンド表示にジャンプさせる。
【０１４７】
図５Ｊは、ログインのすべてよりも少ないサブシステムが選択された業務トランザクションのインスタンスによって呼び出される、ユーザインタフェース５６０を示す。時間幅のようなメトリックは、呼び出されていないサブシステムには提供されない。業務トランザクションの特定のインスタンスが、集約された業務トランザクションにおいて呼び出されるサブシステムのサブセットだけを呼び出す状況が、例えば、発生したエラーによって起こされる、またはフローに影響を与えた時間幅のいくつかのパラメータによって生じる。また、エラーの状況においては、補助領域５６２におけるトランザクションの一覧表は、例えば、異なるフォントや色を使用してエラーを含んだトランザクションを識別する。フローに影響を与える業務トランザクションのパラメータの例が表示されており、例えば、ユーザＩＤに不正な文字があるとＵＩは認証エンジンが呼び出される前にエラーを返す。
【０１４８】
図５Ｋは、図５ＥのＵＩのコンテキストメニュー５３２から起動されるログインの場所を有するユーザインタフェース５７０を示す。ＵＩは、ログインのインスタンスが呼び出されたロケーション、つまりエージェントおよびコンピューティングデバイス（コンピューティングマシン）が特定の期間内にログインの１以上のインスタンスを報告したロケーションを表示する。この選択に応答して、コンテキストメニュー５３２の中で、「ログインのロケーションを示す」を選択することによって、補助領域５６２が提供される。コンテキストメニュー５３２は、ユーザが補助領域５６２にリンクすることを許容する。ロケーションは、ソフトウェアの計測からメトリックを取得する関連付けられたエージェントと同様に、ログインのソフトウェアが実行するホストコンピューティングデバイスを一覧表にすることによって識別される。現在の時間間隔のためのメトリック、例えば、応答時間（Ｒ／Ｔ）（合計時間幅）、ログインの同時呼び出しの回数、エラーの回数、応答回数およびストールの回数など、もまた提供される。エージェントおよびホストのロケーションには、メトリックにインデックスが付けられている。
【０１４９】
この例では、２つのエージェント／コンピューティングデバイスは、それぞれログインの２つのインスタンスを報告し、ログインするためのロケーションを報告する。具体的には、ホストＡにおけるエージェントＡは２つのログイントランザクションのインスタンスを検出し、平均応答時間または時間幅は１１５０ミリ秒（例えば、１１００ミリ秒のあるインスタンスと１２００ミリ秒の別のインスタンスとの平均）である。ホストＢにおけるエージェントＢは２つの他のログイントランザクションのインスタンスを検出し、平均応答時間または時間幅は１４５０ミリ秒（例えば、１４００ミリ秒のあるインスタンスと１５００ミリ秒の別のインスタンスとの平均）である。必要に応じて、補助領域５６２は、各エージェント／ホストのインスタンスを集約する代わりに、ログインの各インスタンスに対するエントリを表示する。ホストは、テキスト名称またはインターネットプロトコル（ＩＰ）アドレスや他のネットワークアドレスによって識別される。これら両方のホストは、ログイントランザクションのトリガ要求を記録したコンピューティングデバイスを表し、したがって両方が認証サービスに関連付けられている。しかし、これらの番号は、業務トランザクションを定義する特定の業務トランザクションコンポーネントのためのメトリック、即ち認証サービスのフロントエンドのために測定された合計のアクティビティのサブセットを表す。
【０１５０】
ログインを実装するためのソフトウェアは、１つだけのコンピューティングデバイスにインストールされることが可能である。または、ログインを実装するためのソフトウェアは、複数のコンピューティングデバイスにインストールされるが、そのうちの１つだけが、情報が報告される特定の期間内にログインを呼び出す。この情報は、補助領域５６２において明らかにされる。報告されたメトリックは、１つの実装において、ＵＩを提供するセントラルマネージャについてのエージェントによって提供される。
【０１５１】
図５Ｌは、図５ＥのＵＩのコンテキストメニュー５３２から起動されるログインの正常性メトリックのユーザインタフェース５８０を示す。領域５０４では、ツリーは、正常性メトリックが使用可能であるコンポーネントを識別するために拡張されている。ここで業務トランザクションおよび他のサブシステムに示されるメトリックのグラフは、すべてのエージェント上のすべてのトランザクションのインスタンスにわたって要約されている。１つのアプローチでは、ツリーは、各業務トランザクションのための単一の子の頂点を有する。そのようなそれぞれの子の頂点は、１つの実装において、計測によって実際に測定される唯一のコンポーネントである関連付けられた業務トランザクションコンポーネント（ＢＴＣ）のために名前を付けられる。ツリーのＢＴＣを選択するとグラフが表示される。
【０１５２】
正常性メトリックは、平均応答時間、間隔ごとの応答、同時呼び出し、間隔ごとのエラーおよびストールカウントなどのメトリックを提供する、グラフ、テーブルまたは他の視覚的表現も含む。ＵＩ５５０は、例えば、ＵＩ５３０上で新しいウィンドウやポップアップウィンドウとして、または分離したディスプレィ画面で、起動される。
【０１５３】
ツリーの頂点は、各オプションを表示するために拡張され、またはオプションを非表示にするために折り畳まれる。「業務サービスによるもの」および「フロントエンドによるもの」は、マップのツリーの異なる部分（異なるサブツリー）で、アプリケーションを介してトランザクションをグループ分けしたりマッピングしたりするのに使用される異なるオブジェクト（業務トランザクションおよびフロントエンド）を表している。つまり、トランザクションは、特定の業務トランザクションに一致するものとして分類されるか、またはサブシステムのフロントエンド（または両方）のように特定のサブシステムを有するものとして分類される。業務トランザクションとその依存物（例えば、業務トランザクションに一致するトランザクションによって呼び出されるすべてのサブシステム）、またはフロントエンドとその依存物（例えば、そのフロントエンドから発しているトランザクションによって呼び出されるすべてのサブシステム）をマッピングする。
【０１５４】
ツリー領域５０４の「業務サービスによるもの」または「フロントエンドによるもの」を選択すると、第１のケースにおいては特定の業務サービスまたは業務トランザクションを検索する検索ユーティリティを提供し、また第２のケースにおいてはフロントエンドまたはバックエンドの呼び出しを提供する。ツリーで業務サービスまたは業務トランザクションを選択することは、有向グラフの「業務表示」、つまり業務サービスのすべての業務トランザクションのマップが表示される（業務トランザクションが選択されている場合にはそれらのいずれかが強調表示される）。ツリーにおいてフロントエンドを選択することは、有向グラフの「フロントエンド表示」、つまりそのフロントエンドの有向グラフとその依存物を表示する。業務トランザクションのまたはフロントエンドのレベルの下位のものをどれか選択することは、選択された項目またはその子の頂点についてのメトリックの情報を生成する。
【０１５５】
性能メトリックは、業務トランザクション（実際には、業務トランザクションコンポーネント）のために、またはフロントエンドの全体的な正常性やその様々なバックエンドの呼び出しのために、収集される。業務サービスのツリーの頂点は、関連付けられた業務トランザクションをグループ分けするためのフォルダ（それらをすべてまとめてマッピングする）で、業務トランザクションの頂点は、業務トランザクションのマップを示し、フロントエンドの頂点は、フロントエンドのマップを示し、そして他のすべての頂点は関連するパフォーマンスデータを示す。
【０１５６】
したがって、領域５０４におけるエレメント「業務サービスによるもの」は、例えば、ユーザが業務サービスおよび業務トランザクションの階層的な配置の観点からデータを見ることを許容する。
【０１５７】
領域５０４におけるエレメント「フロントエンドによるもの」は、ユーザがフロントエンドサブシステムの観点からデータを見ることを許容する。これは、「業務サービスによるもの」という表示のように同じデータを調べるための異なった方法である。例えば、ツリーの頂点は、前述したものとは違ったサブシステムを含む。報告サービスの頂点は、正常性メトリックにアクセス可能であることを示すために拡張されている。この頂点は、平均応答時間、同時呼び出し、間隔ごとのエラー、間隔ごとの応答時間およびストールカウントなどのサブ頂点を提供するために拡張される。「バックエンド呼び出し」の頂点は、ウェブサービスとその性能メトリックのためのサブ頂点を示すために拡張されている。前述したように、円が警告レベル（正常レベルための白および危険レベルのための暗色）を区別する。これは、ユーザが問題を迅速に診断することを許容している。
【０１５８】
特に、警告は、親の頂点が子の頂点のいずれかの最悪ケースの警告状態を示すようにツリーにおいて「バブルアップ」する。そのため、報告サービスのウェブサービスのバックエンド呼び出しは危険レベルの警告を有し、その上の「バックエンド呼び出し」の頂点も危険レベルの警告を有し、そして報告サービスの頂点自身もそのようになる。（「正常性」の頂点はフロントエンドそのものの正常性を表し、その一方で、その上の頂点は、項目のフルセット、つまりそのアプリケーションのフロントエンドおよびバックエンド呼び出し、を表す。）実際の警告の閾値は、フロントエンドの「正常性」、バックエンド呼び出し、および業務トランザクションコンポーネント、に関連付けられている個々のメトリックに対して規定されている。残りは、これらに基づく概要の警告である（最悪のケース、「バブルアップ」の警告）。
【０１５９】
図５Ｍは、頂点３２２と補助領域５６２から「詳細」タブをユーザが選択した後の図５Ｋのユーザインタフェースを示す。ＵＩ５９０で選択されたサブシステム３２２（認証サービス）に関する詳細が提供されている。ユーザがサブシステム（例えば二重の枠）を選択する場合、業務トランザクションのパス（例えば単一の実線の枠）を示すためにサブシステムが強調表示されたときとは対照的に、異なる種類の強調表示が使用されることに注意されたい。
【０１６０】
例えば、領域５６２は、ログインの一部としてサブシステムで呼び出されるコンポーネントの各インスタンスを特定する。単純な例では、各コンポーネントの唯一のインスタンスが示される。実際には、各コンポーネントの複数のインスタンスが示される。例としては、ＣＭ１、ＣＭ２、ＣＭ４ａ、ＣＭ４ｂおよびＣＭ５の応答時間（合計時間幅）は、それぞれ、１３００ミリ秒、１１５０ミリ秒、８００ミリ秒、２００ミリ秒および５０ミリ秒である。ＣＭはクラスのメソッドの組であることを想起されたい。さらに、ホストＡのエージェントＡは、各コンポーネントに関連付けられており、各コンポーネントの実行開始時間が明示されている。正味の時間幅もまた付加的にまたは選択的に提供される。詳細タブが、今、アクティブで選択されているので、それが有向グラフにおいて、認証サービスの頂点３２２と関連付けられているトランザクショントレースからのメソッド呼び出しを一覧表示にする。
【０１６１】
必要に応じて、対象のサブシステムの頂点だけがユーザにより選択された場合、従属的なサブシステムを呼び出す対象のサブシステムのコンポーネントは、補助領域５６２において提供されない。例えば、サブシステムの頂点３２２だけが選択される場合、ＣＭ１、ＣＭ２、ＣＭ４ａおよびＣＭ５は、補助領域５６２で一覧表にされるが、ＣＭ４ａはサブシステム３２８おいてＣＭ７を呼び出すため、ＣＭ４ａは表に載らない。このアプローチにおいて、従属的なサブシステム（例えばＣＭ４ａ）への呼び出しコンポーネントは、ユーザが辺５１３だけを選択する場合、補助領域内でそれ自体によって一覧表にされる。ユーザが、頂点３２２を選択する場合も、付加的なコンポーネントＣＭ１、ＣＭ２、ＣＭ４ａおよびＣＭ５は一覧表にされる。これは、ユーザが粒度の大きい有向グラフを調査することを許容する。
【０１６２】
サブシステムによって呼び出されて他のサブシステムを呼び出すコンポーネント（呼び出しコンポーネント）も、サブシステムによって呼び出され、他のサブシステムを呼び出さないコンポーネントと視覚的に（例えば、色、フォント、アイコン、注釈などで）補助表示領域５６２において識別される。例えば、呼び出しコンポーネントＣＭ４ａは、図５Ｍにおいてイタリック体によって識別される。
【０１６３】
ユーザは、任意のタブから閉じるボタンを選択し、「トランザクションマッピングモード」を終了させ、マップをその標準的な外観および動作に戻す。
【０１６４】
別のオプションでは、１以上の「トランザクション一覧表」、「詳細」および「トレース表示」のタブのもとでの情報が、タブ付きの表示を使用する代わりに、ユーザインタフェースで同時に提供される。
【０１６５】
図５Ｎは、図５Ｇのユーザインタフェースから起動される選択されたトランザクションのインスタンスのためのトランザクショントレースを示す。例えば、ユーザは、図５Ｇの補助領域５６２の「トランザクション一覧表」のタブからトランザクションのインスタンスの１つを選択し、次に「トレース表示」のタブを選択する。トレース表示は、選択されたトランザクションのインスタンスのための１以上のトランザクショントレースを提供する。図４Ｂ１および図４Ｂ２のトランザクショントレースは詳細が述べられており、図５Ｇにおけるトランザクションの代表的なものであるので、この例では、図４Ｂ１および図４Ｂ２のトランザクショントレースが繰り返されている。
【０１６６】
ＵＩ６１０の補助領域５６２において、トランザクショントレース６４１は、認証サービスに関連付けられたエージェントからのコンポーネントデータに基づいて提供され、トランザクショントレース６５１は、認証エンジンに関連付けられたエージェントからのコンポーネントデータに基づいて提供される。トランザクショントレース６４１は、ＣＭ１、ＣＭ２、ＣＭ４ａ、ＣＭ４ｂおよびＣＭ５をそれぞれ表すために、グラフ部分６４２、６４３、６３９、６４４および６４５を含む。トランザクショントレース６５１は、ＣＭ７、ＣＭ８、ＣＭ９およびＣＭ１０をそれぞれ表すために、グラフ部分６４６、６４７、６４８および６４９をそれぞれ含む。
【０１６７】
ユーザは、１以上の画面の同じＵＩにおいて、有向グラフ領域５０２とトランザクショントレースを同時に見ることができ、そのうえ両者の相互関係を調査する。ユーザは、トランザクショントレースを全体として（例えば、ポインティングデバイスを使用して）選択可能であるか、または有向グラフの領域５０２において１以上の対応する頂点を視覚的に区別できるようにそのグラフ領域６３９および６４２から６４９を選択可能である。
【０１６８】
ユーザが１番目のトランザクショントレース６４１を選択する場合、頂点３２２は、頂点３２８および他の頂点と視覚的に区別される。そして、ユーザが２番目のトランザクショントレース６５１を選択する場合、頂点３２８は、頂点３２２および他の頂点から視覚的に区別される。別の可能なアプローチでは、ユーザが１番目のトランザクショントレース６４１を選択する場合、頂点３２２およびすべての依存性のある頂点（３２８、３３６）ならびに関連付けられた辺（５１３、６１３）は、他の頂点および辺から視覚的に区別される。そして、ユーザが２番目のトランザクショントレース６５１を選択する場合、頂点３２８およびすべての従属的な頂点（３３６）ならびに関連付けられた辺（６１３）は、他の頂点および辺から視覚的に区別される。
【０１６９】
図６Ａは、少なくとも１つのアプリケーションを介してフローを追跡するためのモデルを示す。モデルまたはスキーマは、本明細書で表示されるようにユーザインタフェース表示を提供するために使用される。モデルは、２つの部分、即ち動作部分および構造部分を含む。動作部分は、ビジネスプロセスエクスキューションランゲージ（ＢＰＥＬ）のような既存の動作記述子［behavioral descriptor］の理解を通して生成された、ユーザによる手動または自動的のいずれかで定義される方法で、トランザクションの集約のセットを表す。またウェブサービスビジネスプロセスエクスキューションランゲージ（ＷＳ−ＢＰＥＬ）として知られている、ＢＰＥＬは、ウェブサービスを有する業務プロセス内での振る舞いを特定するための実行可能な言語に対するＯＡＳＩＳ標準である。構造部分は、ソフトウェアコンポーネントを介したトランザクションの実際のフローを表す。
【０１７０】
モデルは、（ａ）特定の構造のコンポーネントが正常に実行されない場合にどんな業務サービスまたはトランザクションが影響を受けるのか、（ｂ）業務サービスが障害を発生する寸前の場合にどんな構造のコンポーネントがこの業務サービスまたはトランザクションに影響を与えているか、というような疑問に対する答えを提供するため、動作部分と構造部分の間を埋める。モデルの構造部分に対するもう１つの重要な役割は、ソフトウェアコンポーネントと下層の物理的基盤とのさらなる相関を可能にすることである。各ボックスがモデルのレコードを表し、そこでは各レコードは、各ボックスに一覧表にされたように情報のフィールドを有する。場合によっては、レコードのフィールドは、別のレコードに複製することが可能で、またはモデルは、提供されている例とは異なるレコードのフィールドを配置することにより修正できる。例えば、Vertex_type_nameおよびVertex_type_IDは、頂点のレコードから、別の頂点の型のレコード（図示せず）に移動させ、Vertex_owner_IDおよびVertex_owner_nameは、頂点のレコードから、別の頂点のオーナのレコード（図示せず）に移動させてもよい。多くの他のバリエーションが可能である。
【０１７１】
モデルの構造部分は、破線の右下で、辺、頂点、エージェント、メトリックパスおよび辺オーナのレコードを含む。モデルの動作部分は、破線の左上で、トランザクション、業務トランザクションおよび業務サービスのレコードを含む。頂点は、エージェントと多対一の関係にあり、複数の頂点のレコードが１つのエージェントのレコードに関連付けられていることを意味する。メトリックパスは、頂点と多対一の関係にあり、複数のメトリックパスのレコードが１つの頂点のレコードに関連付けられていることを意味する。辺は、辺のオーナと多対一の関係にあり、複数の辺のレコードが１つの辺のオーナのレコードに関連付けられていることを意味する。１つのアプローチでは、辺は、頂点と一対一の関係にあり、辺のレコードが１つだけの頂点のレコードに関係付けられていることを意味する。
【０１７２】
「順序付けられた」というラベルの付いたボックス６００は、辺（辺のレコード）の順序集合がトランザクションのレコードに関連付けられていることを示している。これは、辺の集合がトランザクションを表現すると考慮されるためには、特定の順序で発生しなければならないことを意味する。「順序付けられた」というラベルの付いた他のボックス６０２は、トランザクションのレコードのフィールドの順序に関係性があるということを示す。例えば、業務トランザクションはトランザクションの順序集合によって表され、業務サービスは業務トランザクションの順序集合によって表される。１つのアプローチでは、トランザクションは、業務トランザクションと一対一の関係にあり、トランザクションのレコードが１つだけの業務トランザクションに関連付けられていることを意味する。業務トランザクションは、業務サービスと多対一の関係にあり、複数の業務トランザクションのレコードが１つの業務サービスのレコードに関連付けられていることを意味する。この例は、図５Ｂにおける取引に関係付けられた、発注、オプション取引、ログイン、残高および取引概要である。レコードを接続する多対一の表記において、円アイコンは順序付けが重要であることを示す。
【０１７３】
一般的に、トランザクションは、アプリケーション／サービスの１以上のコンポーネントを呼び出す一意のフローを表す。これらのコンポーネントは、クラス、クラスメソッドの組、プロセスおよびＪＶＭのような計測されたソフトウェアコンポーネント含む。トランザクションは、辺がコンポーネントのシーケンス内の呼び出しを表す場合、辺の順序集合によって定義される。またトランザクションは他のトランザクションを含む。これらのトランザクションの一覧表も、同様に順序付けされている。１つのアプローチでは、トランザクションは業務階層の最下位レベルにあり、業務トランザクションは第１の高位レベルにあり、そして業務サービスは第２の高位レベルにある。階層のこの例は３つのレベルを含むが、２つだけまたはそれ以上提供される必要がある。業務トランザクションは、明確に定義された業務機能を表し、１以上のトランザクションを含む。業務サービスは、明確に定義されたアプリケーション／サービス、またはアプリケーション／サービスの集合を表し、業務に経済的に意味があり区別されて管理されている。さらに、業務プロセスは、１以上の業務サービスの順序付けされたまたは順序付けされてないコレクションを含んで定義される。
【０１７４】
モデルは、ＵＩを提供するために使用される。例えば、図５ＡのＵＩの例では、頂点のレコードは、各頂点３１０、３１２、３０４、３０６、３０８、３４０、３４２、３４４、３２０、３５０、３２２、３６０、３６２、３２４、３２１、３４１、３４３、３４５、３４７、３４９、３５１、３４９、３５１、３２７、３２６、３３４、３３２、３２９、３２８、３３６、３３１、３３０および３３８に提供される。辺のレコードは、辺Ｅｄ１からＥｄ２６の各辺に提供される。業務サービスのレコードは取引に提供され、業務トランザクションのレコードは、発注、オプション取引、ログイン、残高および取引概要のそれぞれに提供される。同様に、図５ＢのＵＩの例では、頂点のレコードは、各頂点３１０、３１２、３０４、３０６、３０８、３２０、３２２、３２４、３２１、５１０、５１５、５１２、３２６、３３４、３３２、３２８、３３６、３３０および３３８に提供される。辺のレコードは、辺Ｅｓ１からＥｓ１８の各辺に提供される。前述したように、詳細表示の辺のレコードと、概要表示の辺のレコードが相互参照されている。
【０１７５】
さらに、有向グラフの頂点は、同じ頂点のレコードの複数のインスタンスを表す。例えば、図５Ｂにおいて、取引サービスの頂点３２０は、１以上のホストマシンで実行する、アプリケーションの取引サービスの複数のインスタンスまたは展開［デプロイメント］を表す。同様に、有向グラフの辺は、同じ辺のレコードの複数のインスタンスを表す。例えば、図５Ｂにおいて、辺Ｅｓ７は、頂点３２１により表されるバックエンドを呼び出すアプリケーションの取引サービスの複数のインスタンスを表す。レコードのこの集約を得るために、「論理的」抽象レベルを有する頂点のレコードが「物理的」抽象レベルを有する１以上の頂点のレコードに提供される。論理的頂点のレコードは、複数のインスタンスのためのレコードの集約を表す共通のレコードである。ＵＩは、この頂点のレコードを使用して作成される。
【０１７６】
例えば、取引サービスの１番目のインスタンスが最初に呼び出される場合（例えば、１番目のホストマシン上で実行する取引サービスのアプリケーションのインスタンスが業務トランザクションにおいて最初に呼び出される場合）、取引サービスの１番目の頂点のレコードは、「物理的」抽象レベルを有して作成される。
【０１７７】
取引サービスの１番目のインスタンスが二度目に呼び出される場合（例えば、１番目のホストマシン上で実行する取引サービスのアプリケーションのインスタンスが業務トランザクションで二度目に呼び出される場合）、アプリケーションのインスタンスの呼び出しは既にわかっているので、新しい頂点のレコードは作成されない。取引サービスの２番目のインスタンスが最初に呼び出される場合（例えば、１番目のマシンまたは別のホストマシンで実行される、取引サービスのアプリケーションの別のインスタンスまたはデプロイメントが業務トランザクションで最初に呼び出される場合）、取引サービスの２番目の頂点のレコードは、「物理的」抽象レベルを有して作成され、取引サービスの既存の頂点のレコードに必要に応じてリンクされる。レコードは、例えば、データベース内のデータを体系化するために使用される技術を使用してリンクされる。
【０１７８】
このように、１つのアプローチにおいて、「物理的」レコードは、アプリケーションの各インスタンスまたは他のコンポーネントのために作成され、その一方で、１つの共通のまたは「論理的」レコードは、コンポーネントの複数のインスタンスの集約を表すために複数の「物理的」レコードにリンクされる。１つのアプローチにおいて、コンポーネントの同じインスタンスの複数の呼び出しは、付加的な「物理的」頂点のレコードの作成に終わることなく、コンポーネントのインスタンスの最初の呼び出しだけが「物理的」頂点のレコードの作成で終わる。詳細は図８Ａおよび図８Ｂを参照されたい。１つのアプローチにおいて、コンポーネントの別々のインスタンスは、例えば、別々のホストマシン上でコンポーネントの異なるデプロイメントを表し、それぞれが各エージェントに関連付けられている。
【０１７９】
モデルの各レコードの詳細を次に説明する。
【０１８０】
図６Ｂは、図６Ａのモデルによる頂点のレコードの例を示す。頂点のレコードは、モデルの構造部分の中央のエンティティであり、特定の操作を実行する責任を負うソフトウェアコンポーネント表す。ソフトウェアコンポーネントは、例えば、クラスがメソッドの親であるクラスメソッドの組のような別のソフトウェアコンポーネントと親子関係（フィールドのParent_IDにより識別される）を有する。頂点のレコードは有向グラフの頂点で表される。本明細書でのレコードの記述は、フィールド名、フィールドの説明およびフィールドの型を特定する。可変長文字列または可変長文字フィールドは、不定長の文字データの集合である。それは、データベース管理システムにおけるフィールドまたはカラムのデータ型を示す。文字列は、固定長の文字データの集合である。整数は整数の数である。頂点のレコードのフィールドは、Vertex_Name、Vertex_ID、Parent_ID、Abstraction_Level、Hierarchy_Level、Agent_ID、Vertex_Properties、Context_URL、Vertex_Type_Name、Vertex_Type_ID、Vertex_Owner_ID、Creation_Date、Update_DateおよびUser_Nameを含む。各頂点のレコードは一意の識別子（Vertex_ID）を有する。
【０１８１】
Vertex_Propertiesについては、名称と値の組のリストが、例えば、特定の頂点の特別な表示のために使用される。これらのプロパティは、ユニファイドサービスモデル（ＵＳＭ）の物理的な部分に相互に関連付けられて使用される。例えば、ＪＤＢＣの接続文字列のコンポーネントは、名前と値の組のリストにある。Vertex_Type_Nameの例は、ＥＪＢ、データベース、データベースソケット、ソケット、ウェブサービス、メッセージを送信するためのサーバ（例えば、Java（登録商標）メッセージサーバまたはＪＭＳ）、外部およびＥＪＢのクライアントを含む。各頂点は頂点の型を有する。
【０１８２】
Hierarchy_Levelについては、頂点の情報はエージェントにより収集される。一般的に、エージェントはクラスのメソッド上の情報を収集する。例えば、クラスClass1のメソッドmethod1がトランザクションTran1に加わると仮定する。クラスClass1の別のメソッドmethod2もまたトランザクションTran1に加わると仮定する。エージェントにより送信される情報は、１以上の頂点のレコードに対する情報を含む。例えば、Hierarchy_Levelがクラスメソッドに設定される場合、エージェントはClass1.method1およびClass1.method2と名付けられた２つの頂点を送信する。両方のメソッドが同じクラスに属しているため、それらも同じ頂点の型に属する。これは、これらの両頂点が同じ論理的頂点（バケット）に配置されることを意味する。もし、Hierarchy_Levelがクラスに設定されているのであれば、エージェントはClass1と名付けられた１つの頂点にだけ送信を行う。これは、依然として同じ論理的頂点（バケット）に行くが、エージェントとサーバの間のネットワークトラフィックを減らす。すべての頂点がクラスまたはクラスのメソッドに関連している必要はない。例えば、頂点の情報はサーバコンテナまたはＪＶＭに関連する。頂点Class1.method1またはClass1は、アプリケーションサーバServer1からHierarchy_Level=processで送信されると仮定する。頂点Server1は、頂点Class1.method1またはClass1に対する親になる。Hierarchy_Levelは、このようにエージェントによってマネージャに設定されている情報の型や粒度を特定する。
【０１８３】
図６Ｃは、図６Ａのモデルによる辺のレコードの例を示す。トランザクションのセグメント（１つの頂点から別の頂点へのリクエスト、および対応する応答）を表す辺は、２つの頂点間の関係を提供する。有向グラフでは、辺は２つの頂点間の矢印で表される。各辺は、Tail_Vertex_ID（辺の尾部における頂点を特定する）およびHead_Vertex_ID（辺の頭部における頂点を特定する）を有する。Edge_Propertiesフィールドは、ＵＩの表示中で使用されるための辺のプロパティを表す。Head_Owner_IDおよびTail_Owner_IDについて、例として、図５Ａの辺Ｅｄ８が取引サービスのHead_Owner_IDおよびTail_Owner_IDを有する。詳細は図７Ｃ１および図７Ｃ２を参照されたい。
【０１８４】
図６Ｄは、図６Ａのモデルによるエージェントのレコードの例を示す。通常、図１に示されるように、エージェントは、計測されたアプリケーションを監視するために、およびマネージャに報告を返すために、ホストマシンに提供されている。エージェントはコンポーネントのインスタンスに関連付けられている。
【０１８５】
図６Ｅは、図６Ａのモデルによるメトリックパスのレコードの例を示す。メトリックパスは、関連したメトリック名で頂点のレコードをリンクする内部のレコードである。１つの頂点のレコードは複数のメトリックパスを有する。通常、メトリックは、Vertex_IDまたは他の識別子に基づいて探し出される。メトリックパスは、メトリックが定義され収集される方法を表す文字列である。このレコードは、これらのメトリックと、発見されてモデルの一部として使用される強い型のオブジェクトとの関係をレコードすることを許容する。メトリックパスの例は、（ａ）|MyDomain|MyHost|MyAgent|MyProcess|EJB|MyMetric|および（ｂ）|SuperDomain|app.company.com|Agent1|Process1|DataAccessEJB|ResponseTime|である。
【０１８６】
図６Ｆは、図６Ａのモデルによる辺の所有者［オーナ］のレコードの例を示す。これは辺のオーナを表す。複数の辺が同じEdge_Ownerにより所有される。さらに、Edge_Ownerは、それ自身の親または子のEdge_Ownerを有する。子のEdge_Ownerは唯一の親のEdge_Ownerを有するが、親のEdge_Ownerは複数の子のEdge_Ownerを有し得る。Transaction_IDは、モデルの動作部分をモデルの構造部分でリンクする識別子であり、トランザクションレコードと同じフィールドである（図６Ａ）。これは、辺または辺の集合をトランザクションに関連付けることができ、それにより辺または辺の集合が、トランザクションが関連付けられている業務トランザクションに関連付けられ、かつ業務トランザクションが関連付けられている業務サービスに関連付けられる。
【０１８７】
共通の辺のレコードは、同じ辺を示す異なる辺のレコードの集約を表すために提供される。この辺のレコードは、複数のインスタンスのレコードの集約を表す共通のレコードである。ＵＩは、この辺のレコードを用いて作成される。さらに、この共通の辺のレコードは、共通の頂点のレコードにリンクされる。
【０１８８】
図６Ｇは、図６Ａのモデルによるトランザクションのレコードの例を示す。前述したように、トランザクションのレコードは、階層の第１の高位レベルにおいて、業務トランザクション（トランザクションはその一部である）の名称を含み、第１の高位レベルよりも上で第２の高位レベルにおいて、業務サービス（業務トランザクションはその一部である）の名称を含む。１以上の異なるトランザクションのレコードは、同じ業務トランザクションのレコードに関連付けられており、１以上の異なる業務トランザクションのレコードは、同じ業務サービスのレコードに関連付けられている。
【０１８９】
図６Ｈは、図６Ａのモデルによる業務トランザクションのレコードの例を示す。業務トランザクションのレコードは、階層の第２の高位レベルにおいて、業務サービス（業務トランザクションが一部である）の名称を含む。１以上の異なる業務トランザクションのレコードは、同じ業務サービスのレコードに関連付けられている。
【０１９０】
図６Ｉは、図６Ａのモデルによる業務サービスのレコードの例を示す。
【０１９１】
モデルを使用して、エージェントにより収集される情報は体系化されてＵＩ上に表示される。レコードのフィールドのいくつかは、モデル内で例えばレコードのリンクを許可したりするために内部的に使用される。一方、名称フィールドなどの他のフィールドは、例えば、有向グラフの、または有向グラフから分離した表示エリアの、頂点や辺を修飾するためにＵＩ上に表示される。ＵＩは、必要に応じて任意のフィールドにアクセスするためのコマンドを出すオプションをユーザに提供する。
【０１９２】
図７Ａ１は、図５Ａにおける有向グラフの詳細表示のための頂点のテーブルの例を示す。テーブルの各エントリは、それぞれ異なる頂点のレコードから派生する。モデルは実際に本明細書で示されるテーブルを作成する必要はないが、テーブルはレコードにより格納されているものを簡潔に伝達するために提供されている。独立したエントリは、図５ＡのＵＩのためにコンポーネントの各インスタンスに対して提供される。リファレンス番号は、頂点のための図５Ａの参照番号［符号番号］を指す。実際には、識別子は整数を指定可能であるが、ここでのおよび他のテーブルでの識別子については、識別子は理解の助けとして記述的なテキストを使用する。例えば、記述的テキストPlaceOrderIDは、これが発注の頂点のレコードに対する識別子であるという意味を伝える。
【０１９３】
エントリ１から５は、外部の型を有する業務トランザクションの頂点を提供する。エントリ６から９は、業務サービスとその子のコンポーネントの最初のインスタンスのための頂点を提供する。この例では、３つのインスタンスまたは業務サービスとその子のコンポーネントのデプロイメントがあり、それらはAgent1a、Agent1bおよびAgent1cにそれぞれ関連付けられている。エントリ１０から１３は、取引サービスとその子のコンポーネントのインスタンスの最初の付加的（add.）インスタンスのためのもので、そして、エントリ１４から１７は、取引サービスとその子のコンポーネントの２番目の付加的（add.）インスタンスのためのものである。独立した頂点は、付加的なインスタンスのためのＵＩでは示されていない。エントリ１８および１９は、認証サービスアプリケーションおよびその子のコンポーネントのためのものである。エントリ２０から２２は、報告サービスアプリケーションおよびその子のコンポーネントのためのものである。
【０１９４】
図７Ａ２は、図７Ａ１の頂点のテーブルの例の続きを示す。エントリ２３から２９は、ポート３４５６のシステムローカルホストへのバックエンド呼び出しのためのもので、ウェブサービスのためのものである。エントリ３０および３１は、注文エンジンのアプリケーションとその子のコンポーネントのためのものである。エントリ３２および３３は、認証エンジンのアプリケーションとその子のコンポーネントのためのものである。エントリ３４および３５は、報告エンジンのアプリケーションとその子のコンポーネントのためのものである。エントリ３６から３９は、ポート６５４３のシステムローカルホストへのバックエンド呼び出しのためのもので、データベースのためのものである。
【０１９５】
図７Ａ１および図７Ａ２のテーブルは、図５ＡのＵＩを提供するために使用される詳細図における、物理的頂点のレコードを表すといえる。それ以外同様である論理的頂点のレコードを表す対応するテーブルは、図７Ａ１の付加的（add.）なエントリ１０から１７またはエージェントの識別子を含まない。論理的頂点のレコードはエージェントの識別子から独立している。また、図５ＢのＵＩの概要図を提供するために使用される、対応するテーブルは、詳細レベルの頂点（例えば、子のコンポーネント３４０、３４２、３４４、３５０、３６０、３６２、３２７、３２９および３３１を省略しウェブサービスの頂点を統合する）を省略したり統合したりして、図７Ｂに示されるように提供される。図７Ｂは、図５Ｂにおける有向グラフの概要表示のための頂点のテーブルの例を示す。
【０１９６】
図７Ｃ１は、図５Ａにおける有向グラフの詳細表示のための辺のテーブルの例を示す。テーブルの各エントリは、それぞれ異なる辺のレコードから派生する。Edge_IDsは、図５Ａに示すように、Ｅｄ１からＥｄ２６である。
【０１９７】
尾部の頂点のＩＤ［Tail_vertex_ID］は、辺の尾部が始まるコンポーネントの識別子である。同様に、頭部の頂点のＩＤ［Head_vertex_ID］は、辺の頭部が終わるコンポーネントの識別子である。これらのコンポーネントは、計測されたコンポーネントまたは未計測のコンポーネント（例えば、未計測のローカルホストまたはウェブサービス）である。しかしながら、１つのアプローチでは、尾部のオーナまたは頭部のオーナは計測されたコンポーネントのオーナであることが要求される。このアプローチは、情報が未計測のコンポーネントのオーナを識別するために使用可能ではないことから、有用である。計測されたコンポーネントについては、情報は、辺の頭部と尾部の両方に別々のオーナを識別するために使用可能である。
【０１９８】
このように、辺が計測されたコンポーネントから始まる場合、尾部のオーナのＩＤ［Tail_owner_ID］は、計測されたコンポーネントのオーナの識別子に設定される。辺が未計測のコンポーネント（例えば、Ｅｄ１７、Ｅｄ１８、Ｅｄ１９、Ｅｄ２０、Ｅｄ２１、Ｅｄ２２）から始まる場合、尾部のオーナのＩＤ［Tail_owner_ID］は、辺の頭部が終わる計測されたコンポーネントのオーナの識別子に設定される（頭部および／または尾部のコンポーネントが計測されていると仮定される）。このように尾部のオーナは、頭部のオーナに基づいて設定される。同様に、辺が計測されたコンポーネントで終了する場合、頭部のオーナのＩＤ［Head_owner_ID］は、計測されたコンポーネントのオーナの識別子に設定される。辺が未計測のコンポーネント（例えば、Ｅｄ８からＥｄ１６、Ｅｄ２３からＥｄ２６）において終了する場合、頭部のオーナのＩＤ［Head_owner_ID］は、辺の尾部が始まる計測されたコンポーネントのオーナの識別子に設定される。したがって、頭部のオーナは、尾部のオーナに基づいて設定される。
【０１９９】
さらに、計測されたコンポーネントのオーナは、親のコンポーネントが存在しない場合、コンポーネントに一対一の基準で関連付けられているオーナとして定められる。それ以外では、オーナはコンポーネントの最上位の親のオーナ（例えば、親、親の親など）とすることができる。例えば、図５Ａの辺Ｅｄ１からＥｄ７のそれぞれに対し、尾部の頂点は、業務トランザクション３１０、３１２、３０４、３０６および３０８を表し、外部の型を有する。頭部の頂点は、サブシステム内の子のコンポーネントで、即ちサブシステム３２０内の子のコンポーネント３４０、３４２および３４４であり、サブシステム３２２内の子のコンポーネント３５０であり、そしてサブシステム３２４内の子のコンポーネント３６０および３６２である。その結果、Ｅｄ１からＥｄ３の頭部のオーナは、取引サービス（TradeServiceIDの識別子を有する）で、子のコンポーネント３４０、３４２および３４４の親である。Ｅｄ４およびＥｄ５の頭部のオーナは、認証サービス（AuthenticationServiceIDの識別子を有する）で、子のコンポーネント３５０の親である。Ｅｄ６およびＥｄ７の頭部のオーナは、報告サービス（ReportingServiceIDの識別子を有する）で、子のコンポーネント３６０および３６２の親である。
【０２００】
Ｅｄ８からＥｄ１６は、親のコンポーネントが尾部のオーナである計測されたコンポーネントから始まっている辺の例である。Ｅｄ８からＥｄ１６もまた頭部のオーナが尾部のオーナと同じようになるように設定されている、未計測のコンポーネントで終わる辺の例である。Ｅｄ１７からＥｄ２２は、未計測のコンポーネントから始まる辺の例で、尾部のオーナが頭部のオーナと同じになるように設定されているので、計測されたコンポーネントで終了する。Ｅｄ１７からＥｄ２２は、親のコンポーネントが頭部のオーナである計測されたコンポーネントで終わる辺の例である。Ｅｄ２３からＥｄ２６は、親のコンポーネントが尾部のオーナである計測されたコンポーネントから始まっている辺の例である。Ｅｄ２３からＥｄ２６もまた頭部のオーナが尾部のオーナと同じようになるように設定さている、未計測のコンポーネントで終わる辺の例である。図５Ａの詳細図に、子のコンポーネントおよび関連付けられた辺が示されている。
【０２０１】
図７Ｃ２は、図５Ｂにおける有向グラフの概要表示のための辺のテーブルの例を示す。ここでは、辺の数が減らされ、それらの定義は、子のコンポーネントおよび各ローカルホストおよびウェブサービスに対する個々の頂点がないので簡略化されている。
【０２０２】
図７Ｄは、図５Ａの有向グラフのための辺のオーナのテーブルの例を示す。１つのアプローチでは、グラフは領域５０４における取引の業務サービスの選択に基づいているので、取引はグラフの各辺のオーナである。トランザクションについては、前述したように、トランザクションは、コンポーネントのシーケンスの呼び出しおよびコンポーネント間の呼び出しを表す辺の集合（例えば辺のレコード）含む。トランザクションは異なる方法で定義することができる。例としては、トランザクションは、トランザクション１−Ｅｓ１、Ｅｓ７；トランザクション２−Ｅｓ１、Ｅｓ８、Ｅｓ９、Ｅｓ１５；トランザクション３−Ｅｓ１、Ｅｓ８、Ｅｓ１０、Ｅｓ１７；トランザクション４−Ｅｓ２、Ｅｓ８、Ｅｓ９、Ｅｓ１６；トランザクション５−Ｅｓ４、Ｅｓ１１、Ｅｓ１７；トランザクション６−Ｅｓ５、Ｅｓ１２、Ｅｓ１３、Ｅｓ１７；トランザクション７−Ｅｓ６、Ｅｓ１２、Ｅｓ１４、Ｅｓ１８、のように図５Ｂの辺に関連付けられる。
【０２０３】
図７Ｅは、図５Ａの有向グラフのためのトランザクションのテーブルの例を示す。図７Ｄのトランザクションの例が提供される。さらに、トランザクション１からトランザクション３は、発注に関連付けられており、トランザクション４はオプション取引に関連付けられており、トランザクション５はログインに関連付けられており、トランザクション６は残高に関連付けられており、そして、トランザクション７は取引概要に関連付けられている。さらに、ＵＲＬ１からＵＲＬ７のコンテキストのＵＲＬは、トランザクション１からトランザクション７にそれぞれ関連付けられている。
【０２０４】
図７Ｆは、図５Ａの有向グラフのための業務トランザクションのテーブルの例を示す。図７Ｅの業務トランザクションはこのテーブルに含まれる。
【０２０５】
図７Ｇは、図５Ａの有向グラフのための業務サービスのテーブルの例を示す。この例では、取引の１つの業務サービスが提供される。しかし、他の業務サービスを提供することもまた可能である。
【０２０６】
図８Ａは、図５Ａの取引サービスのアプリケーションの複数のインスタンスのための物理的頂点のレコードの例を示す。前述したように、計測されたコンポーネントのインスタンスの最初の呼び出しが検出される場合、コンポーネントための物理的頂点のレコードが作成される。コンポーネントの同じインスタンスが続いて呼び出される場合、新しい頂点のレコードは作成されない。計測されたコンポーネントの別のインスタンスの最初の呼び出しが検出される場合、別の物理的頂点のレコードが計測されたコンポーネントの別のインスタンスのために作成される。このレコードは、必要に応じて既存の頂点のレコードにリンクされている。
【０２０７】
１つのアプローチでは、同じコンポーネントの複数のインスタンスのための物理的頂点のレコードの集約を表す、論理的頂点のレコードは、オンザフライで作成されてテーブルなどのデータベースへの恒久的な格納はされない。いずれにしても、そのような頂点のレコードはモデルの一部である。このケースでは、論理的頂点は、Vertex_ID、Creation_Date、Update_DateおよびUser_Nameのフィールドを有する必要はない。
【０２０８】
この例では、コンポーネントは業務サービスのアプリケーションである。各エージェント、即ちAgent 1、Agent2およびAgent3に関連付けられているコンポーネントの３つのインスタンスが存在する。例えば、これらのエージェントは、各サーバ１０６、１１０および１１４上にある（図１）。頂点のレコード８００は、Abstraction_Level=論理によって示されるように、論理的頂点のレコードである。関連付けのあるエージェントは存在しない。例としては、階層レベルはクラスである。頂点のプロパティは各レコードで同じで、表記「TrdSvcProp」によって一般的に示される。一例としては、サーブレットの頂点の型は、servletIDの関連付けのある識別子を有する。頂点のレコードのオーナは、取引業務サービスの名称（ＩＤは、TradingBusServである）を有する。コンポーネントの３つの各インスタンスの最初の呼び出し日付／時刻が異なるため、作成の日付／時刻は、物理的頂点のレコードごとに異なることに注意されたい。頂点のレコード８０２、８０４および８０６は、Abstraction_Level=物理で示されるように、それぞれのサーバ１０８、１１２および１１６における取引サービスのインスタンスのための物理的レコードである。各物理的頂点のレコードは、異なる識別子、Vertex_IDを有する。それぞれのエージェントは、Agent_IDによって識別される。この例では、取引サービスは親を持たないことから、Parent_ID=nullであることに注意されたい。物理的頂点のレコード８０２、８０４および８０６は、共通の論理的頂点のレコード８００にリンクされる。
【０２０９】
図８Ｂは、図５Ａのオプション取引｜サービスのコンポーネントのインスタンスのための頂点のレコードの例を示し、図８Ａから親の頂点のレコード８０２の例を示す。オプション取引｜サービスのインスタンスは、Agent1に関連付けられており、オプション取引｜サービスは、Hierarchy_Levelによってサーブレットとして特定される。レコード８１２のParent_IDのフィールドは、オプション取引｜サービスの親コンポーネントとして取引サービスを特定する。具体的には、頂点のレコード８０２のTradeService1IDの識別子は、頂点のレコード８１２のParent_Idのフィールドに存在する。モデルのこの側面は、図５Ａでオプション取引｜サービスの頂点３４４が取引サービスの頂点３２０の子のコンポーネントとして提供されることを可能にしている。つまり、子のコンポーネントの頂点が、入れ子のように、親のコンポーネントの頂点の中に表示される。
【０２１０】
図８Ｃは、図５Ａにおいて、オプション取引｜サービスのコンポーネントがウェブサービスのウェブサービス１を呼び出す場合における頂点のレコードおよび辺のレコードの例を示す。この呼び出しは、図５Ａで、頂点３４４、辺Ｅｄ１１および頂点３４１によって表される。さらに、頂点３４４は頂点のレコード８２０によって表され、辺Ｅｄ１１は辺のレコード８２２によって表され、頂点３４１は頂点のレコード８２４によって表される。レコード８２０は、オプション取引｜サービスの頂点を識別し、一方で、レコード８２４は、ウェブサービス１の頂点を識別する。レコード８２２は、辺の頭部および尾部のオーナだけでなく（取引サービス）、Ｅｄ１１の頭部および尾部の頂点も識別する。レコード８２４におけるAgent_ID=nullは、ウェブサービス１が計測されたコンポーネントではないため、エージェントを持たない。
【０２１１】
図９は、ユーザインタフェースを提供するための方法を示す。前述のように、管理されたアプリケーションを実行すると、関連するコンポーネントデータは、アプリケーションの計測から取得される。この情報は、エージェントによってセントラルマネージャに報告される。マネージャにおけるデータは、記憶装置２１０（図２Ｃ）のようなデータベース１１８（図１）に提供される。データは、様々なデータフィールドを含むことができ、そのデータフィールドは、本明細書で説明した機能を達成するために、複数の異なる方法でデータを問い合わせアクセスさせるようにすることができる。
【０２１２】
ステップ９００において、データは、例えば１５分といったデフォルトの値、またはユーザによって指定されるように設定された分析のもとで、指定された時間間隔でアクセスされる。１つのアプローチにおいて、このステップは、前述したように「さらに検索」コマンドを含む。データは、例えば、データストアからアクセスされる。大量なトランザクショントレースのデータを収集して格納することは、処理時間および記憶容量の点でコストがかかるが、過去のデータ（過去の数日または数ヶ月）も使用される。また、より高い周波数に設定したサンプリングにより、進行中のトランザクショントレースのサンプリングに頼ることも可能である。
【０２１３】
通常、３つの分離した処理経路が続く。第１の処理経路では、ステップ９０２にて、応答時間および時間幅のような性能メトリックがのトランザクショントレース／呼び出しスタックから計算される。ステップ９０４は、例えば、性能メトリックを個々の閾値と比較することによって警告レベルを決定する。警告は、サブシステムの全体的な性能メトリックに基づいて計算される。トランザクショントレースの時間幅に対する閾値については、トランザクショントレースで測定された対応する時間幅を閾値に適用することによって、サブシステムの「平均応答時間」の警告のための閾値を再利用できる。これらの閾値は、単一のトランザクションの使用に対しては過度に反応し、多くの黄色や赤の警告といった結果を招き得る。１つのアプローチにおいて、性能メトリックおよび警告は、有向グラフの構造に直接依存しているわけではなく、有向グラフの構造から独立して計算される。性能メトリックは、業務トランザクションコンポーネントのパフォーマンス、即ちフロントエンドおよびバックエンド呼び出しを全体として記述する。つまり、特定の時間間隔に亘る、通常は１５秒ごとに観察されたトランザクションである。このデータは現在および過去のモードで、有向グラフで使用される。
【０２１４】
性能メトリックは、平均応答時間、同時呼び出し、間隔ごとのエラー、間隔ごとの応答およびストールカウントを含む。さらに、特定のトランザクションのインスタンスに対して、トランザクショントレーサは、各業務トランザクション、例えば、図４Ｂ１および関連した考察に基づくようなトランザクションおよびコンポーネントに対する実行時間および呼び出し時間幅を算出する。
【０２１５】
第２の処理経路において、２つの異なるデータのセット、即ち有向グラフの構造を特定するためのデータと、そのマップ構造に特定のトランザクションのトレースをマッピングするためのデータ、が提供される。これらは、有向グラフ上にトランザクショントレースの情報の重ね合わせを提供するために使用される。これらのデータのセットを提供するために、ステップ９０６において、期間内に呼び出された業務トランザクションとフロントエンドサブシステムとを特定する。有向グラフのデータは、すべてのトランザクションに亘って提供される。有向グラフを構築するために使用されるデータは、キャプチャされ、継続的に（データのサンプリングとともに）格納される。各マップは−デフォルトで−例えばリアルタイムで更新しつつ過去３日間のデータを表す。構成設定は、このデフォルトの時間ウィンドウを変更することができ、ユーザも過去の時間範囲を指定することができる。どちらのケースでも、マップを構築するための情報はデータストアから取得される。
【０２１６】
業務トランザクションへのサブシステムの関連付けは、発生しているトランザクションについての情報を返す報告をする特別のマップトレーサを使用して実現する。トランザクションが業務トランザクションコンポーネントに一致する場合、そのトランザクションは、業務トランザクションコンポーネントの名称でラベルが付けられ、そのトランザクション内で呼び出されるすべての下位レベルのコンポーネントが業務トランザクションコンポーネント（つまりその業務トランザクション）に関連付けられる。これらの下位レベルのコンポーネントは、後に特定のルールに基づいて「サブシステム」に集約される。
【０２１７】
業務トランザクションは、選択された業務トランザクションコンポーネントまたはフロントエンドの識別子をスレッドの最初のセグメントとして探すことによって特定される。一旦、サブシステムの識別子がトランザクショントレースで発見されると、サブシステムは呼び出されたと結論付けられる。トランザクション内でその時点から行われたすべての呼び出しは、次の認識されるサブシステムが呼び出されるまで（フロントエンドまたはバックエンド呼び出し）、同じサブシステムの必要な部分となる。
【０２１８】
また、個々のトランザクショントレース内で、マップとツリーに現れる、フロントエンドおよびバックエンドの呼び出しは、そのコンポーネントがトレースされたトランザクションの一部としてヒットされる場合にセグメントに関連付けられている特定のメトリックパス（識別子）に関連付けられる。
【０２１９】
第３の処理経路では、ステップ９１２は、有向グラフ上のサブシステムのための付加的なデータのセットにおける正常性メトリックを算出する。図５Ｌを参照されたい。これらのメトリックは、トランザクショントレースから取得される応答時間などの性能メトリックと対照的である。
【０２２０】
ステップ９０７は、本明細書で説明されたモデルを更新する。さらなる詳細が図１０で提供される。
【０２２１】
ステップ９０８は、ユーザコマンドを受信することを含む。ユーザコマンドは、本明細書で説明されるように、ツリー領域５０４、メインエリア５０２および補助領域５６２のようなユーザインタフェースの様々な部分における選択および／またはエントリを含む。ステップ９１０は、例えば、モデルを使って、ユーザインタフェースを分析対象の時間間隔についての関連する情報で更新するような表示をすることを含む。
【０２２２】
図１０は、図９のステップ９０７にあるようにモデルを更新するための方法の例を示す。ステップ１０００は、エージェントによって受信されるデータから、コンポーネントの対象のインスタンスのための情報のフィールドを取得することを含む。フィールドは、例えば、名称、型、階層レベルおよびエージェントの識別子を含む。判断ステップ１００２は、例えば、モデルが情報のフィールド（例えば、同じ名称、型、階層レベルおよびエージェントの識別子）と一致する頂点のレコードを含むか否かを決定することによって、頂点のレコードがコンポーネントのインスタンスのために存在するか否かを判断する。頂点のレコードがモデル内に存在する場合は、判断ステップ１０１４に到達する。
【０２２３】
判断ステップ１０１４は、新しい辺がコンポーネントのインスタンスに関連付けられているか否かを判定する。これは、辺のレコードのTail_Owner_IDおよびHead_Owner_IDを情報のフィールドにおけるコンポーネントのインスタンスの呼び出し元または呼び出し先のコンポーネントの識別子と比較することを含む。例えば、コンポーネントのインスタンスを図５Ａの発注｜サービスと仮定すると、フィールドは、それがポート３４５６のシステムローカルホストを呼び出したことを示している。
この呼び出しに対する辺が存在しない場合（Tail_Vertex_ID= PlaceOrderServiceIDおよび Head_Vertex_ID= SystemLocalHost1IDの辺のレコード）、そのような辺のレコードが作成される。辺が新しい場合には、ステップ１０１６は新しい辺を作成し、それを頂点のレコード、辺のオーナのレコードおよびトランザクションのレコードにリンクする。判断ステップ１０１４が偽［ノー］の場合、再びステップ１０００に至る。
【０２２４】
判断ステップ１００２が偽［ノー］の場合、判断ステップ１００４は頂点のレコードが対象のコンポーネントの別のインスタンスのために存在するか否かを判定する。例えば、コンポーネントのインスタンスは、それらが異なるエージェントの識別子のフィールドを有する場合、コンポーネントのインスタンスが異なると考えられるようなエージェントの識別子に結び付けられる。判断ステップ１００４は、モデルがエージェントの識別子（例えば、同じ名称、型および階層レベルだが異なるエージェントの識別子）以外の情報のフィールドと一致する頂点のレコードを含むか否かを判定することによって頂点のレコードがコンポーネントの別のインスタンスのために存在するか否かを判定する。頂点のレコードがモデルに存在する場合、ステップ１０１８は、コンポーネントの対象のインスタンスのために新しい頂点のレコードを作成し、必要に応じてそれを既存の頂点のレコードまたは他のインスタンスのレコードにリンクする。次に判断ステップ１０１０に至る。
【０２２５】
判断ステップ１００４が偽［ノー］の場合、コンポーネントのための任意のインスタンスのモデルには頂点のレコードが存在しないことを意味する。したがって、ステップ１００６は、コンポーネントのための新しい頂点のレコードを作成する。ステップ１００８は、メトリックパスのレコードを作成し、それを新しく作成された頂点のレコードにリンクする。次に判断ステップ１０１０に至る。判断ステップ１０１０は、コンポーネントのインスタンスのエージェントがエージェントのレコードの存在しない新しいエージェントであるか否かを判定する。これは、エージェントのレコードのAgent_IDをコンポーネントの各頂点のレコードのAgent_IDと比較することを含む。コンポーネントの頂点のレコードに一致するAgent_IDが存在しない場合、エージェントは新しいものであり、ステップ１０１２は、新しいエージェントのレコードを作成し、それをコンポーネントのインスタンスのための頂点のレコードにリンクする。図６Ａを参照されたい。判断ステップ１０１０が偽［ノー］の場合、上述の判断ステップ１０１４に至る。
【０２２６】
以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。
【図１】
2012221499.tif 000004
【図２Ａ】
2012221499.tif 000005
【図２Ｂ】
2012221499.tif 000006
【図２Ｃ】
2012221499.tif 000007
【図３】
2012221499.tif 000008
【図４Ａ】
2012221499.tif 000009
【図４Ｂ１】
2012221499.tif 000010
【図４Ｂ２】
2012221499.tif 000011
【図４Ｂ３】
2012221499.tif 000012
【図５Ａ】
2012221499.tif 000013
【図５Ｂ】
2012221499.tif 000014
【図５Ｃ】
2012221499.tif 000015
【図５Ｄ】
2012221499.tif 000016
【図５Ｅ】
2012221499.tif 000017
【図５Ｆ】
2012221499.tif 000018
【図５Ｇ】
2012221499.tif 000019
【図５Ｈ】
2012221499.tif 000020
【図５Ｉ】
2012221499.tif 000021
【図５Ｊ】
2012221499.tif 000022
【図５Ｋ】
2012221499.tif 000023
【図５Ｌ】
2012221499.tif 000024
【図５Ｍ】
2012221499.tif 000025
【図５Ｎ】
2012221499.tif 000026
【図６Ａ】
2012221499.tif 000027
【図６Ｂ】
2012221499.tif 000028
【図６Ｃ】
2012221499.tif 000029
【図６Ｄ】
2012221499.tif 000030
【図６Ｅ】
2012221499.tif 000031
【図６Ｆ】
2012221499.tif 000032
【図６Ｇ】
2012221499.tif 000033
【図６Ｈ】
2012221499.tif 000034
【図６Ｉ】
2012221499.tif 000035
【図７Ａ１】
2012221499.tif 000036
【図７Ａ２】
2012221499.tif 000037
【図７Ｂ】
2012221499.tif 000038
【図７Ｃ１】
2012221499.tif 000039
【図７Ｃ２】
2012221499.tif 000040
【図７Ｄ】
2012221499.tif 000041
【図７Ｅ】
2012221499.tif 000042
【図７Ｆ】
2012221499.tif 000043
【図７Ｇ】
2012221499.tif 000044
【図８Ａ】
2012221499.tif 000045
【図８Ｂ】
2012221499.tif 000046
【図８Ｃ】
2012221499.tif 000047
【図９】
2012221499.tif 000048
【図１０】
2012221499.tif 000049
【手続補正書】
【提出日】平成24年6月6日(2012.6.6)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００２２
【補正方法】変更
【補正の内容】
【００２２】
プローブは、ＣＯＲＢＡメソッドタイマ、リモートメソッドインボケーション（ＲＭＩ）メソッドタイマ、スレッドカウンタ、ネットワークバンド幅、ＪＤＢＣ更新およびクエリタイマ、サーブレットタイマ、Java（登録商標）サーバページズ（ＪＳＰ）タイマ、システムログ、ファイルシステム入出力バンド幅メータ、使用可能および使用済メモリ、ならびにＥＢＪ（エンタープライズJava（登録商標）ビーンズ）タイマを含むメトリックの標準セットを報告する。メトリックは、特定のアプリケーションのアクティビティの計測値である。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００４７
【補正方法】変更
【補正の内容】
【００４７】
例えば、サーブレットに関係付けられているトランザクションのために、業務トランザクションコンポーネントは、セカンダリフレーム内にロードされているJava（登録商標）サーバページズ（ＪＳＰ）に接続して呼び出される。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００４９
【補正方法】変更
【補正の内容】
【００４９】
サブシステムの例には、破線のボックスによって表される計測されたサブシステムがあり、これは、通常、フロントエンドのサブシステムである。同様に、点線のボックスによって表される未計測のサブシステムがあり、これは、通常、バックエンドのサブシステムである。本明細書で使用されるように、フロントエンドのサブシステムは、通常、計測され、バックエンドのサブシステムは、通常、計測されない。さらに、あるフロントエンドのサブシステムは、ウェブサービスの呼び出しなどを介して別のフロントエンドのサブシステムを呼び出す。また、フロントエンドのサブシステムは、バックエンドのサブシステムを呼び出す。性能メトリックの全範囲は、計測されたサブシステムから取得される。限定された情報は、計測されたサブシステムからメソッドに呼び出されて使用されるメソッドから、未計測のサブシステムに着目して得られる。未計測のデータベースの場合、例えば、ＪＤＢＣドライバ（呼び出しフロントエンドと同じJava（登録商標）バーチャルマシン（ＪＶＭ）に位置する）は、データベースの応答性についての見解を与えるメトリックを提供する。未計測のメインフレームの場合、通常、メインフレームの特定のポートにメインフレームを呼び出すメソッドが存在し、その呼び出しにどのくらい時間がかかるか、またはそれがストールするか否かもしくはエラーを報告するか否かを評価できる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００５１
【補正方法】変更
【補正の内容】
【００５１】
図４Ａは、業務トランザクション内で呼び出されるコンポーネントのシーケンスの例における依存関係を示す。コンポーネント指向のプログラミングモデルは、プログラマに、コンポーネントに関係する構成要素からアプリケーションや他のプログラムを構築させるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行する。さらに、コンポーネントは、コンポーネントのシーケンスがプログラム内で呼び出されるように、他のコンポーネントを呼び出し、同様に、再帰呼び出しでは自分自身を呼び出す。コンポーネント指向のプログラミングモデルの一例は、Ｊ２ＥＥであるが、Java（登録商標）サーバページズ、エンタープライズJava（登録商標）ビーンズ（ＥＪＢ）、サーブレットおよびJava（登録商標）データベースコネクティビティ（ＪＤＢＣ）のコンポーネントといったコンポーネントを用いることができる。ＪＤＢＣは、クライントがいかにデータベースにアクセスするかを定義するJava（登録商標）プログラミング言語のためのアプリケーションプログラミングインタフェース（ＡＰＩ）である。それは、データベース内のデータを照会や更新する方法を提供する。しかしながら、.NETのような他のコンポーネント指向のプログラミングモデルを使用することもできる。また、プログラミングモデルは、オブジェクト指向である必要はない。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００５２
【補正方法】変更
【補正の内容】
【００５２】
この例では、前述のログイン業務トランザクションの詳細を提供する。１つの可能な実装では、ログインの各コンポーネントは、クラスメソッド（ＣＭ）の組である。例えば、サーブレットはJava（登録商標）クラスである。リクエストを受信し、対応するレスポンスを生成するのはオブジェクトである。クラスメソッドの組は、class.methodの表記により表される。ログインは、ログイン名やパスワードなどのユーザのログイン認証情報を取得する１番目のクラスメソッドの組ＣＭ１を含む。ＣＭ１の書式の例は、ServletA1.ObtainLoginCredentialsである。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００９５
【補正方法】変更
【補正の内容】
【００９５】
サーブレットまたはサーブレットＡ｜サービスやアクシスサーブレット｜サービスのような他のクラスは、異なるアプリケーションまたはサブシステムによって共有され得ることに注意されたい。例えば、同じJava（登録商標）アーカイブ（.ＪＡＲ）ファイルまたはライブラリに属するクラスは異なるアプリケーションまたはサブシステムによって共有可能である。この例では、サーブレットＡと名付けられたクラスは、認証サービスおよび報告サービスの両方によって共有された共通ライブラリに属する。「サービス」は、トランザクションに参加するクラスのメソッド名を指す。同様に、アクシスサーブレットと名付けられたクラスは、注文エンジン、認証エンジンおよび報告エンジンによって共有される共通ライブラリに属する。
【外国語明細書】
2012221499000001.pdf
2012221499000002.pdf
2012221499000003.pdf
2012221499000004.pdf