(57)【要約】【課題】サービスの実行順序の不正を効率的に検出する。【解決手段】複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶し、サービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶するサービス構成情報管理部１１１と、ログを記憶する統合ログ記憶部１１７と、新たな入力ログを入力し、統合ログ記憶部に記憶した複数のログから、入力ログが示すサービスより前に実行されたサービスの前ログを検出し、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか判断するサービス障害検出部１１５とを備え、サービス障害検出部１１５は、サービス構成情報管理部が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスのログに対して優先的に障害発生を検出する。【選択図】図１
2013003681.tif 000002
【特許請求の範囲】
【請求項１】
所定の順序で実行されるコンピュータソフトウェアにより提供されるサービスの障害を検出するサービス運用管理装置において、
複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶するとともに、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶するサービス構成情報管理部と、
サービス同士のメッセージを記録したメッセージログと上記メッセージのメッセージ中継を記録したトランザクションログとの少なくともいずれかのログを過去ログとして複数記憶する統合ログ記憶部と、
統合ログ記憶部に記憶する新たな入力ログを入力し、既に統合ログ記憶部に記憶した複数の過去ログの中から、入力ログが示すサービスより前に実行されたサービスのログを前ログとして検出し、サービス構成情報管理部に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出するサービス障害検出部と、
を備え、
サービス障害検出部は、サービス構成情報管理部が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスの入力ログに対して優先的に障害発生の検出をすることを特徴とするサービス運用管理装置。
【請求項２】
ログは、セッションＩＤと業務ＩＤとサービスＩＤを有し、
サービス構成情報管理部は、サービスを業務ＩＤとサービスＩＤとにより定義し、業務ＩＤとサービスＩＤとにより複数のサービスのサービス実行順序を記憶し、
サービス障害検出部は、既に統合ログ記憶部に記憶した複数の過去ログから、入力ログが有するセッションＩＤと同じセッションＩＤを有する過去ログであって、入力ログが示すサービスの直前に実行されたサービスの過去ログを前ログとして検出するとともに、サービス構成情報管理部に記憶したサービス実行順序定義情報からサービス実行順序を検索して、前ログが示すサービスの後に実行する可能性のあるサービスを候補サービスとして取得し、取得した候補サービスの業務ＩＤとサービスＩＤとが、入力ログが有する業務ＩＤとサービスＩＤとに一致するか判断してサービスの障害発生を検出することを特徴とする請求項１記載のサービス運用管理装置。
【請求項３】
サービス運用管理装置は、さらに、
サービス構成情報管理部に記憶したサービス実行順序定義情報からサービス実行順序を検索することにより、障害が発生した障害発生サービスから障害の影響を受ける他のサービスの範囲を特定し、障害の影響を受ける他のサービスの障害影響範囲を障害発生サービスの影響範囲情報として障害発生サービスに対応させてサービス構成情報管理部に記憶するサービス障害影響範囲特定部を備えたことを特徴とする請求項１又は２記載のサービス運用管理装置。
【請求項４】
サービス障害影響範囲特定部は、サービス間の呼び出し関係を階層情報として、階層情報に基づいてサービスの障害影響範囲を特定することを特徴とする請求項１〜３いずれかに記載のサービス運用管理装置。
【請求項５】
サービス障害影響範囲特定部は、障害発生サービスに初期値を付与し、障害発生サービスを呼ぶサービスおよび障害発生サービスから呼び出されるサービスに対しては、呼び出しごとに値が減算または加算される値を解析優先度スコアとして付与し、解析優先度スコアをもとに、サービスの障害影響範囲を算出することを特徴とする請求項４記載のサービス運用管理装置。
【請求項６】
サービス運用管理装置は、さらに、
サービスのメッセージに含まれる属性情報の属性値の異常範囲を障害基準値として定義したサービス障害定義情報を記憶するサービス障害定義管理部を備え、
メッセージは、サービスの属性値を含む属性情報を有し、
サービス障害検出部は、サービス障害定義管理部が記憶するサービス障害定義情報を参照して、サービス障害定義情報が定義した障害基準値とログのメッセージに含まれる属性情報の属性値とを比較してサービスの障害発生を検出することを特徴とする請求項１〜５いずれかに記載のサービス運用管理装置。
【請求項７】
メッセージは、サービスの重要度を示す属性値を含む属性情報を有し、
サービス障害検出部は、ログのメッセージが有する属性情報が示す重要度を参照して、重要度の高い属性情報を有するメッセージのサービスの障害発生を優先的に検出することを特徴とする請求項１〜６いずれかに記載のサービス運用管理装置。
【請求項８】
メッセージは、属性情報をメッセージから取り出すための属性クエリを有し、
サービス運用管理装置は、さらに、
ログのメッセージが有する属性クエリを実行して、ログのメッセージからから属性情報を取り出す属性クエリ部と、
属性クエリ解釈部が取り出した属性情報を記憶する属性管理部と
を備え、
サービス障害検出部は、属性管理部が記憶した属性情報を参照して、障害検出の判定をすることを特徴とする請求項６又は７いずれかに記載のサービス運用管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、機能をユーザに提供する過程でメッセージを交換するコンピュータソフトウェアであるサービスの障害を検出するサービス運用管理装置に関するものである。
【背景技術】
【０００２】
特許文献１に示すように、異なる記録内容を持つ複数種類のログデータを統合管理する装置が実現されている。この技術を用いて、サービス指向アーキテクチャ（ＳＯＡ）に基づくサービスシステムの基盤ミドルウェアであるＥＳＢのログをリアルタイムに監視し、サービスシステムを構成する個々のサービスの障害を検出するサービス運用管理装システムを構築することができる。ここで、ＥＳＢとは「Ｅｎｔｅｒｐｒｉｓｅ  Ｓｅｒｖｉｃｅ  Ｂｕｓ」の略であり、サービス間メッセージの中継に必要なルーティングやフォーマット変換などを行うミドルウェアである。
【０００３】
従来技術による、サービス、ＥＳＢ、サービス運用管理装置より構成されるサービス運用管理システムでは、複数のサービスがＥＳＢを経由しメッセージを授受し、利用者向けの機能を実現している。サービス運用管理装置は、ＥＳＢのログ（メッセージのログ、ＥＳＢ自身の行うメッセージルーティングなどの処理の記録であるトランザクションログ）をリアルタイムに監視し、サービスの障害を検出する。ＥＳＢは、ひとつのサービス運用管理システムにつき１つ用いられる場合もあるし、企業合併や提携などで複数のＥＳＢを並存させる場合もある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１８２１９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来技術には、複雑なシステムにおいてサービスの実行順序の不正を検出するには、実行され得る全てのサービス実行順序を実際に実行中のサービスのログと照合する必要があり、効率的に検出することが難しいという課題があった。
【０００６】
複雑な業務を多数含むサービス運用管理システムの場合、このマッチング対象となるサービス実行順序定義が膨大となり、多数のサービスを同時実行し短時間に大量のログが発生する場合など、ログ監視のリアルタイム性を損なう恐れがあった。
【０００７】
この発明は、サービス実行順序不正を効果的に検出するサービス運用管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
この発明のサービス運用管理装置は、
所定の順序で実行されるコンピュータソフトウェアにより提供されるサービスの障害を検出するサービス運用管理装置において、
複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶するとともに、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶するサービス構成情報管理部と、
サービス同士のメッセージを記録したメッセージログと上記メッセージのメッセージ中継を記録したトランザクションログとの少なくともいずれかのログを過去ログとして複数記憶する統合ログ記憶部と、
統合ログ記憶部に記憶する新たな入力ログを入力し、既に統合ログ記憶部に記憶した複数の過去ログの中から、入力ログが示すサービスより前に実行されたサービスのログを前ログとして検出し、サービス構成情報管理部に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出するサービス障害検出部と、
を備え、
サービス障害検出部は、サービス構成情報管理部が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスの入力ログに対して優先的に障害発生の検出をすることを特徴とする。
【発明の効果】
【０００９】
本発明は、サービス構成情報管理部が、障害の影響度を記憶しているので、サービス障害の影響度が大きいものについて優先的にサービス実行順序不正を検出することを可能にする。
【図面の簡単な説明】
【００１０】
【図１】実施の形態１〜３のサービス運用管理システムの構成図。
【図２】業務とサービスの説明図。
【図３】サービス構成情報管理部１１１が記憶するサービスの階層関係を示す図。
【図４】サービス構成情報管理部１１１が記憶するサービス障害の影響範囲情報を示す図。
【図５】サービス障害検出部１１５の動作フロー図。
【図６】サービス障害影響範囲特定部１１２の動作フロー図。
【図７】ログの種類を示す図。
【図８】実施の形態２と３のサービス部１０１が作成するメッセージの構成を示す図。
【図９】実施の形態３のサービス部１０１の動作フロー図。
【図１０】実施の形態３の属性クエリ解釈部１０９の動作フロー図。
【図１１】実施の形態３の属性クエリ解釈部１０９の動作フロー図。
【図１２】実施の形態１〜３におけるサービス部１０１、サービス運用管理装置１０３の外観の一例を示す図。
【図１３】実施の形態１〜３におけるサービス部１０１、ＥＳＢ１０２、サービス運用管理装置１０３、のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１はこの発明の実施の形態１〜３に係るサービス運用管理装置１０３を用いたサービス運用管理システム１００の構成図である。
【００１２】
≪サービス運用管理システム１００の説明≫
サービス運用管理システム１００は、管理対象となるサービス部１０１、ＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ  Ｓｅｒｖｉｃｅ  Ｂｕｓ）１０２、サービス運用管理装置１０３よりなる。
【００１３】
サービス部１０１は、計算機とアプリケーションプログラムとから構成される。サービス部１０１はサービスを提供する。サービスとは、計算機や専用機でアプリケーションプログラムを実行することにより達成されるものである。業務は、サービスが順次実行されて達成される仕事のことであり、例えば、在庫管理業務、予約業務、ネット検索業務などである。業務は複数のサービスが所定の実行順序で実行されることにより達成される。
サービス部１０１は、その機能の実現のためにメッセージ１０４をサービス間で授受する。
【００１４】
メッセージ１０４は、セッションＩＤと業務ＩＤとサービスＩＤと宛先アドレスと差出アドレスとメッセージ本文とを有している。
ここで、セッションとは、コンピュータシステムやネットワーク通信において、接続又はログインしてから、切断又はログオフするまでの、一連の操作や通信のことをいう。セッションＩＤとは、接続又はログインから切断又はログオフまでの間セッションを識別するために付与された識別子である。
業務ＩＤとは、業務を識別するために付与された識別子である。
サービスＩＤとは、サービスを識別するために付与された識別子である。
さらに、メッセージ１０４は、後述する実施の形態２，３で説明する属性情報１０５や属性クエリ１０６を属性情報として有している。
【００１５】
ＥＳＢ１０２は、メッセージログ１０７、トランザクションログ１０８を記憶するメモリ装置（図示せず）を備えている。メッセージログ１０７は、メッセージ１０４の内容をログとして記録したものである。ログは、年月日時分秒などのログ時刻を記録している。
【００１６】
トランザクションログ１０８は、ＥＳＢ１０２自身の行うメッセージルーティングなどの処理の記録である。トランザクションログ１０８は、メッセージ１０４とセッションＩＤと業務ＩＤとサービスＩＤとを含んでいる。
【００１７】
図１に示すように、複数のサービス部１０１が、ＥＳＢ１０２を経由しメッセージを授受し、利用者向けの機能を実現している。ＥＳＢ１０２は、ひとつのサービス運用管理システムにつき１つ用いられる場合もあるが、図１に示すように企業合併や提携などで複数のＥＳＢ１０２を並存させる場合もある。
【００１８】
≪サービス運用管理装置１０３の構成≫
サービス運用管理装置１０３は、サービス構成情報管理部１１１、サービス障害影響範囲特定部１１２、収集・蓄積部１１４、サービス障害検出部１１５、ログ管理部１１６、統合ログ記憶部１１７を備えている。さらに、サービス運用管理装置１０３は、後述する実施の形態２、３で説明する属性クエリ解釈部１０９や属性管理部１１０やサービス障害定義管理部１１３を有している。
【００１９】
サービス運用管理装置１０３は、ＥＳＢ１０２のログ（メッセージログ１０７、ＥＳＢ自身の行うメッセージルーティングなどの処理の記録であるトランザクションログ１０８）を入力してリアルタイムに監視し、サービスの障害を検出する。
【００２０】
サービス構成情報管理部１１１は、記憶装置であり、複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶する。サービス構成情報管理部１１１は、サービスを業務ＩＤとサービスＩＤとにより識別し、業務ＩＤとサービスＩＤとにより複数のサービスのサービス実行順序を記憶する。サービス構成情報管理部１１１は、さらに、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶する。
【００２１】
サービス障害影響範囲特定部１１２は、サービス構成情報管理部１１１に記憶したサービス実行順序定義情報からサービス実行順序を検索することにより、障害の影響を受けるサービスの範囲を特定し、障害の影響を受けるサービスの障害影響範囲を影響範囲情報としてサービス構成情報管理部１１１に記憶する。
【００２２】
収集・蓄積部１１４は、ＥＳＢ１０２から（後述する実施の形態３の場合は、属性クエリ解釈部１０９を経由して）、サービス同士のメッセージ中継を記録したトランザクションログ１０８とサービス同士のメッセージを記録したメッセージログとの少なくともいずれかのログを入力する。ログはログ管理部１１６に渡される。
【００２３】
ログ管理部１１６は、収集・蓄積部１１４が収集したログを統合ログ記憶部１１７に記憶するとともに、ログをサービス障害検出部１１５に引き渡す。
【００２４】
統合ログ記憶部１１７は、記憶装置であり、サービス同士のメッセージ中継を記録したトランザクションログ１０８とサービス同士のメッセージ１０４を記録したメッセージログ１０７との少なくともいずれかのログを過去ログとして複数記憶する。
【００２５】
サービス障害検出部１１５は、新たな入力ログを入力し、統合ログ記憶部に記憶した複数の過去ログの中から、入力ログが示すサービスより前に実行されたサービスの過去ログを前ログとして検出する。
【００２６】
サービス障害検出部１１５は、サービス構成情報管理部１１１に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出する。
【００２７】
さらに、サービス障害検出部１１５は、サービス構成情報管理部１１１が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスのログに対して優先的に障害発生の検出をする。
【００２８】
≪サービス運用管理装置１０３のサービス運用管理方法の概略動作≫
本実施の形態にかかるサービス運用管理装置１０３は、サービス構成情報管理部１１１、およびサービス障害影響範囲特定部１１２を備えることを特徴とする。本実施の形態１にかかるサービス運用管理装置１０３は、サービス構成情報管理部１１１、およびサービス障害影響範囲特定部１１２という従来技術にはない特徴的な構成要素を設け、サービス障害検出部１１５の実行の際に、サービス障害の影響範囲が広いものについて優先的に検出する。
【００２９】
≪サービス実行順序定義情報≫
業務とサービスとの例を図２に示す。
図２は、サービスの集合である業務（１）〜（ｎ）において、それぞれの業務がサービスを実行するサービス実行順序定義の例を示す。Ｗ１、Ｙ１などアルファベット（と添え字の組み合わせ）はサービスを示す。また矢印は、矢印左側のサービスが矢印右側のサービスを呼び出して実行することを示す。
【００３０】
図２において、サービスＸは、業務（１）〜（ｎ）で呼び出されており、サービスＸの実行時に実行順序不正が発生しているかどうかを厳密にチェックするためには、サービスＸの直前に実行されたサービスがＷ１〜Ｗｎのいずれかのサービスであるかどうか確認する必要がある。定義が複雑な業務を多数含むサービス運用管理システムの場合、このマッチング対象となるサービス実行順序定義が膨大となり、多数のサービスを同時実行し短時間に大量のログが発生する場合など、ログ監視のリアルタイム性を損なう恐れがある。
【００３１】
図３において、（１）（２）は業務を示す業務ＩＤである。Ａ〜Ｇはそれぞれサービスを示すサービスＩＤである。業務（１）は、サービスＡ、Ｂ、Ｃ、Ｄから構成されている。業務（２）は、サービスＥ、Ｂ、Ｆ、Ｇから構成されている。矢印は、サービスの呼び出しを示す。また、サービスＢを利用する業務は（１）（２）のみとする。サービス間の呼び出し関係を階層情報という。
【００３２】
サービス構成情報管理部１１１は、図３に示す階層情報を、業務ＩＤとサービスＩＤとを用いて複数のサービスのサービス実行順序定義情報（例えば図３の情報）として記憶している。サービス実行順序定義情報の記憶形式やデータ形式は問わない。
【００３３】
≪影響範囲情報≫
図３において、業務（１）のサービスＢで障害が発生したものとすると、サービスＢの障害の影響範囲はＡ、Ｃ、Ｄまで及ぶ。サービス障害影響範囲特定部１１２は、この影響範囲の大小を、サービス構成情報管理部１１１の持つサービス実行順序定義情報（例えば図３の情報）より算出して、影響範囲情報としてサービス構成情報管理部１１１に記憶する。影響範囲情報は、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を有している。
【００３４】
障害の影響度は、例えばサービスＩＤごとに固定の値を定義するように構成してもよい。例えば、サービスＡは５点、サービスＢは１０点、サービスＣは７点のように固定値を付与し、その固定値を影響範囲情報としてサービス構成情報管理部１１１に記憶する。
【００３５】
あるいは、図４に示すように、あるサービスで障害が発生した場合、障害のあったサービスのサービスＩＤに関係なく、そのサービスを含む業務の全てのサービスに影響が発生するものと仮定し、以下で説明する解析優先順スコアを各サービスに付与して、各サービスの解析優先順スコアの合計値を業務ごとの合計として表してもよい。
【００３６】
例えば、解析優先順スコアは、障害の発生したサービスＢに初期値１０点を与え、当該サービスＢを呼ぶサービスＡおよび当該サービスＢから呼び出されるサービスＣ、Ｄは呼び出しごとに解析優先度スコアが減算されるものとするよう構成してよい。また例えば減算の代わりに加算することにより解析優先度スコアを算出してもよい。図４においては、最も高い解析優先度スコアは１０で、呼び出しごとに解析優先度スコアが１ずつ減算されるよう構成した解析優先順スコアを用いて、図３の業務（１）、業務（２）ついてサービス障害影響範囲を算出した際の影響範囲情報構造体の例である。
【００３７】
図４は、業務（１）のサービスＢに対して記憶される影響範囲情報の例である。図４においては、影響範囲情報を単一の構造体（単一の値）としてではなく、
１．業務別の詳細影響度を保持する構造体、
２．業務毎の影響度をまとめて保持する構造体、
３．サービス別の影響度をまとめて保持する構造体、
の３種類の構造体として実現している。
【００３８】
「業務別の詳細影響度を保持する構造体」には、例えば、業務（１）の実行中にサービスＢに障害が発生した場合、業務（１）のサービスＢに付与された影響度と業務（１）のサービスＡ、Ｃ、Ｄに付与された影響度が保持される。また、業務（１）の実行中にサービスＢに障害が発生した場合、業務（２）のサービスＢに付与された影響度と業務（２）のサービスＥ、Ｆ、Ｇに付与された影響度が保持される。図４の場合は、業務（１）の実行中にサービスＢに障害が発生した場合、業務（２）には関係ないので業務（２）のサービスＢと業務（２）のサービスＥ、Ｆ、Ｇには影響がないので、影響度はゼロが保持される。
【００３９】
「業務毎の影響度をまとめて保持する構造体」には、業務毎の影響度をまとめて保持する。すなわち、「業務別の詳細影響度を保持する構造体」に保持されている各サービスの影響度の業務別合計が保持される。
【００４０】
「サービス別の影響度をまとめて保持する構造体」には、「業務別の詳細影響度を保持する構造体」に保持されている各サービスの影響度のサービス別合計が保持される。
【００４１】
図４の影響範囲情報から、業務（１）を実行中のサービスＢの影響範囲は、サービスＢ単独であれば１０点であり、サービスＢが属する業務（１）であれば３７点であり、サービスＢが属する業務（２）であれば０点であることが、わかる。
【００４２】
図４の影響範囲情報から、業務（２）を実行中のサービスＢの影響範囲は、サービスＢ単独であれば１０点であり、サービスＢが属する業務（１）であれば０点であり、サービスＢが属する業務（２）であれば３７点であることが、わかる。
【００４３】
サービス構成情報管理部１１１は、サービスＢに対応してそのサービスＢに障害が発生した場合に障害の影響度を示す影響範囲情報を図４に示すように記憶している。
【００４４】
≪サービス障害検出部１１５のサービス実行順序不正検出方法の動作≫
図５に、サービス障害検出部１１５におけるサービス実行順序不正検出処理の動作フローチャートを示す。
【００４５】
まず、サービス障害検出部１１５は、サービス同士のメッセージ中継を記録したトランザクションログ１０８とサービス同士のメッセージを記録したメッセージログとの少なくともいずれかのログをＥＳＢ１０２から入力する。
【００４６】
サービス障害検出部１１５は、入力としてログ（入力ログ）を受け取り（Ｓ１０１）、入力ログ中のサービスＩＤ、セッションＩＤ、業務ＩＤを取り出す（Ｓ１０２、Ｓ１０３、Ｓ１０４）。
【００４７】
サービス障害検出部１１５は、サービス構成情報管理部１１１を検索して、入力ログのサービス障害影響範囲を取り出す（Ｓ１９９）。サービス構成情報管理部１１１から入力ログのサービス障害影響範囲が検索できない場合は、Ｓ１０５に進む。サービス障害検出部１１５は、サービス障害影響範囲と比較する閾値を設定しておき、入力ログのサービス障害影響範囲が検索できた場合、サービス障害検出部１１５は、閾値以上の影響範囲を持つサービスのログを受け取った際には、他のサービスの障害よりも優先的に図５の実行順序不正検出の処理を実行する。閾値未満の影響範囲を持つサービスのログを受け取った際には、その入力ログを一時メモリに保管し、その入力ログに対する図５の実行順序不正検出の処理を後刻実行する。
【００４８】
Ｓ１０５において、サービス障害検出部１１５は、Ｓ１０３で取り出したセッションＩＤに関連付けられたログで最新のもの（直前のログ、前ログという）を、統合ログ記憶部１１７より取り出す（Ｓ１０５、Ｓ１０６）。サービス障害検出部１１５は、同一セッションＩＤを有するログであって、ログ時刻が最新のものを前ログとして取り出す。
【００４９】
サービス障害検出部１１５は、Ｓ１０５、Ｓ１０６の取り出しで、セッションＩＤに関連付けられた前ログがある場合は、Ｓ１０７以下の処理を行う。
【００５０】
まず、サービス障害検出部１１５は、サービス構成情報管理装置１１１に記憶されたサービス実行順序定義情報をサービスＩＤ、業務ＩＤで検索して前ログが示すサービスの次に実行する可能性のあるサービスを候補サービスとして取り出す。サービス障害検出部１１５は、Ｓ１０５で取り出した前ログに関連付けられた、次に実行する可能性のある候補サービスのサービスＩＤ・業務ＩＤのリストを作成する（Ｓ１０７）。Ｓ１１４において後述するが、Ｓ１０５で取り出した前ログにサービスＩＤ・業務ＩＤのリストが既に付随している場合には、Ｓ１０７の候補サービスのサービスＩＤ・業務ＩＤのリスト作成動作は省略することができる。
【００５１】
そして、Ｓ１０２、Ｓ１０３で取り出した入力ログのサービスＩＤ・業務ＩＤが、Ｓ１０７で取り出し作成した候補サービスのサービスＩＤ・業務ＩＤのリストに含まれるかどうか調べる（Ｓ１０９、Ｓ１１０）。サービス障害検出部１１５は、Ｓ１０９、Ｓ１１０で、候補サービスのサービスＩＤ・業務ＩＤが一致する場合、サービス実行順序不正は発生していないと判断し、Ｓ１１３以下の処理を行う。
【００５２】
Ｓ１０８〜Ｓ１１０で、候補サービスのサービスＩＤまたは業務ＩＤがＳ１０２、Ｓ１０３で取り出した入力ログのサービスのサービスＩＤ・業務ＩＤのいずれかと一致しない場合、サービス障害検出部１１５は、Ｓ１０９、Ｓ１１０の処理を、Ｓ１０７で取り出し作成した候補サービスのサービスＩＤ・業務ＩＤのリストに対して繰り返し実行し、候補サービスのサービスＩＤ・業務ＩＤのリストの中から、Ｓ１０２、Ｓ１０３で取り出した入力ログのサービスのサービスＩＤ・業務ＩＤと一致するものを探す。Ｓ１１１で、サービスＩＤ・業務ＩＤが候補サービスのサービスＩＤ・業務ＩＤのリストの最後の要素である場合、サービス障害検出部１１５は、サービス実行順序不正を検出したと判断し（Ｓ１１２）、あらかじめ定めたサービス実行順序不正への対処処理を行う。すなわち、サービス障害検出部１１５は、サービス障害影響範囲特定部１１２に対して、サービス障害情報を送る。このサービス障害情報は、障害を起こしたサービスの業務ＩＤ、サービスＩＤ、障害の原因を示す障害原因ＩＤなどを含む。
【００５３】
Ｓ１０８〜Ｓ１１０の処理でサービス実行順序不正を検出しなかった場合、またはＳ１０５、Ｓ１０６でセッションＩＤに関連付けられた前ログがない場合は、サービス障害検出部１１５は、Ｓ１１３以下の処理を行う。
【００５４】
まず、サービス障害検出部１１５は、サービス構成情報管理部１１１より、当該入力ログを生成したサービスの次に実行する可能性のある候補サービスのサービスＩＤ・業務ＩＤのリストを取り出し（Ｓ１１３）、Ｓ１０１で入力された入力ログと、Ｓ１１３で取り出した候補サービスのサービスＩＤ・業務ＩＤのリストを関連付け、ログ管理部１１６を通して統合ログ記憶部１１７に過去ログとして保管し（Ｓ１１４）、処理を完了する。
【００５５】
このように、統合ログ記憶部１１７に記憶された入力ログは、次回、過去ログとして検索されることになるが、過去ログに次に実行する可能性のある候補サービスのサービスＩＤ・業務ＩＤのリストが関連付けられて記憶されている場合はその過去ログが前ログとして検索された場合には、前ログと次に実行する可能性のあるサービスＩＤ・業務ＩＤのリストとが同時に検索できるのでＳ１０７の候補サービスのサービスＩＤ・業務ＩＤのリスト作成動作を省略することができる。
【００５６】
なお、サービス運用管理システム１００の実現上の都合によっては、サービス実行順序不正を検出したログに対しても、Ｓ１１３、Ｓ１１４の処理を行い、サービス実行順序不正を検出したログに候補サービスのサービスＩＤ・業務ＩＤのリストを関連付けて統合ログ記憶部１１７に記憶するようにしてもよい。
【００５７】
また、図５において、サービス運用管理システム１００の実現上の都合によっては、例えば、ユーザＩＤをセッションＩＤの代わりに用いることもできる。また、ユーザがサービスの集合としての業務単位でなく個別のサービスを実行するようなシステムの場合は、業務ＩＤの取り出しや比較を省略することもできる。
【００５８】
あるいは、例えば、Ｓ１０９・Ｓ１１０においてサービスＩＤ・業務ＩＤをペアとして比較し、いずれか一方が異なるときは一致しないと判断するよう構成することもできる。
【００５９】
以上のように、サービス障害検出部１１５は、統合ログ記憶部１１７に記憶した複数のログから、入力ログが有するセッションＩＤと同じセッションＩＤを有する過去ログであって入力ログが示すサービスの直前に実行されたサービスの過去ログを前ログとして検出し、サービス構成情報管理部１１１に記憶したサービス実行順序情報を検索して、前ログが示すサービスの後に実行する可能性のあるサービスを候補サービスとして取得し、取得した候補サービスの業務ＩＤとサービスＩＤとが、入力ログが有する業務ＩＤとサービスＩＤとに一致するか判断してサービスの障害発生を検出する。
【００６０】
≪サービス障害影響範囲特定部１１２のサービス障害影響範囲特定方法の動作≫
サービス障害影響範囲特定部１１２は、サービス障害影響範囲を特定するものである。  以下の説明では、サービス障害影響範囲特定部１１２が、サービス障害影響範囲を、サービス障害情報をサービス障害検出部１１５より受け取るたびに計算する場合を説明する。
【００６１】
図６に、サービス障害影響範囲特定部１１２の処理の動作フローチャートを示す。
サービス障害影響範囲特定部１１２は、まず、サービス障害情報をサービス障害検出部１１５より受け取る（Ｓ２０１）。このサービス障害情報は、障害を起こしたサービスの業務ＩＤ、サービスＩＤ、障害原因ＩＤなどを含む。
【００６２】
次に、サービス障害影響範囲特定部１１２は、障害を起こしたサービスのそれぞれについて業務ＩＤ、サービスＩＤを取り出し（Ｓ２０２）、サービス構成情報管理部１１１より、当該サービスの親サービス・親業務情報を取り出す（Ｓ２０３）。この親サービス情報は、親サービスのサービスＩＤを含み、親業務情報は親業務の業務ＩＤを含む。
【００６３】
サービス障害影響範囲特定部１１２は、Ｓ２０３で取り出した親業務のそれぞれに対して、図４に示すような、業務ごとの影響範囲情報を組み立て、業務ごとの影響範囲情報を当該サービス情報の一部として、障害を起こしたサービスに対応させてサービス構成情報管理部１１１に追加記憶する（Ｓ２０４）。
【００６４】
図６において、サービス障害影響範囲特定部１１２は、図６のＳ２０４の処理を、Ｓ２０３で取り出した全ての親業務について繰り返し（Ｓ２０５）、更に、Ｓ２０３で取り出した全ての親サービスについて、サービス間の階層情報を計算し、中間情報として記録する（Ｓ２０６）。サービス間の階層情報とは、あるサービス（親サービス）が他のサービス（子サービス）を呼び出す関係、および同じ親サービスに呼び出されたサービス群（兄弟サービス）の関係の情報、および、障害を起こしたサービスから各サービスまでの階層の深さを含む情報である。
【００６５】
サービス障害影響範囲特定部１１２は、Ｓ２０３〜Ｓ２０７までの処理を、Ｓ２０３で取り出した全ての親サービスおよびそれらから親子関係を辿れる全ての親サービス・親業務に対して再帰的に実行する（Ｓ２０７）。
【００６６】
また、サービス障害影響範囲特定部１１２は、Ｓ２０１で入力された全ての障害を起こしたサービスについて、当該サービスが呼び出す子サービスの情報をサービス構成情報管理部１１１より取り出し（Ｓ２０８）、それら全ての子サービスについて、サービス間の階層情報を計算し、中間情報に記録する（Ｓ２０９、Ｓ２１０）。
【００６７】
サービス障害影響範囲特定部１１２は、Ｓ２０８〜Ｓ２１０の処理を、Ｓ２０８で取り出した各サービスの全ての子サービスおよびそれらから親子関係を辿れる全ての子サービスに対し再帰的に実行する（Ｓ２１１）。
【００６８】
以上の処理を完了すると、サービス障害影響範囲特定部１１２は、Ｓ２０６およびＳ２０９で組み立てた中間情報をもとに、業務ごとに、また、更にサービス毎に、影響度を算出し（Ｓ２１２、Ｓ２１３）処理を完了する。
【００６９】
この影響範囲情報の構造体の詳細例は、図４に示したとおりである。図４の例では、更に業務ごと、且つ、業務を構成するサービスごとの詳細影響度を算出し、影響範囲情報構造体に加えている。サービス障害影響範囲は、障害を検出するたびに計算され、障害が発生したサービスに対してのみサービス障害影響範囲が計算されて記憶されることになる。
【００７０】
障害が発生したサービスに対してのみサービス障害影響範囲が計算されて記憶されている場合には、図５のＳ１９９において、すべての入力ログについてはサービス障害影響範囲を検索することができない。
【００７１】
図６においては、サービス障害検出部１１５が障害を検出するたびにサービス障害影響範囲特定部１１２がサービス障害影響範囲を計算する場合を示したが、サービス障害影響範囲特定部１１２は、サービス障害影響範囲をログ収集・蓄積のたびに計算してもよい。
【００７２】
また、例えば、サービス障害影響範囲特定部１１２は、サービス構成情報管理部１１１のサービス構成情報が更新されるたびにすべてのサービスについてサービス障害影響範囲を算出し、サービス障害影響範囲を業務・サービスと関連付けてサービス構成情報管理部１１１にあらかじめ記憶させておいてもよい。またはサービス障害影響範囲特定部１１２が、サービス障害影響範囲を業務・サービスと関連付けてメモリ装置に一時保管（キャッシュ）しておくように構成してもよい。すべてのサービスについてサービス障害影響範囲をあらかじめ算出しサービス構成情報管理部１１１にあらかじめ記憶させておく場合には、サービス障害検出部１１５は、図５のＳ１９９において、すべての入力ログについてサービス障害影響範囲を検索することができ、優先的なサービス実行順序不正の検出をするか否かをすべてのサービスについて判断することができる。
【００７３】
以上の構成および動作により、この実施の形態では以下のような効果を奏する。
サービス障害検出部１１５、サービス構成情報管理部１１１、サービス障害影響範囲特定部１１２の動作により、サービス障害影響範囲が広いものについて優先的にサービス実行順序不正を検出することを可能にする。
【００７４】
実施の形態２．
実施の形態１の説明ではサービス実行順序不正の検出について述べてきたが、サービス障害影響範囲による優先度付けは、サービス実行順序不正以外の障害検出についても適用可能である。
【００７５】
以下に、サービス運用管理装置１０３が、メッセージログ１０７およびトランザクションログ１０８から検出可能なサービス障害を示す。
【００７６】
１．実行順序不正（実施の形態１の場合）
実行順序不正とは、サービスの実行順序定義から逸脱したサービスの呼び出しが行われた場合をいう。
【００７７】
２．タイミングの不正
タイミングの不正とは、指定された時間間隔で応答されていない（早すぎ、遅すぎ）場合、あるいは、応答が欠落した（通信エラーを含む）場合をいう。
【００７８】
３．サービスエラー
サービスエラーとは、サービス自身にて検出済みのエラーをいう。ログに特定のエラーコードおよびメッセージが含まれている。
【００７９】
４．値の不正
値の不正とは、応答された値が正しい範囲内に収まっていない場合、又は、フォーマット不正の場合をいう。
【００８０】
これらの障害を検出するために、この実施の形態のサービス運用管理システムを構成するサービス運用管理装置１０３は、サービス障害定義管理部１１３を備えている。
サービス障害定義管理部１１３は、サービスの実行タイミング、パラメータの値のとりうる範囲の制限、パラメータの値のとりうる範囲の制限などのサービス障害定義（障害基準値）をあらかじめ保管する記憶部である。
【００８１】
これらの障害を検出するために、サービス部１０１は、障害を検出するのに必要な属性情報１０５の属性値を、メッセージ１０４に付加する。この属性情報１０５としては、一連の業務かどうかを示すセッションＩＤや業務ＩＤ、サービスの実行時刻などを付加することができる。例えば、サービス部１０１は、メッセージ１０４がＸＭＬである場合、後述する図８において、＜ｑｕｅｒｙ＞〜＜／ｑｕｅｒｙ＞で囲まれた部分（点線枠内）で示したＸＰａｔｈ記法の条件式として、サービスの実行タイミング、パラメータの値、サービスの戻り値などを属性として定義することができる。
【００８２】
サービス運用管理装置１０３のサービス障害検出部１１５は、入力ログに記録されたこれら属性情報１０５の属性値が、サービス障害定義管理部１１３が記憶したサービス障害定義情報の異常範囲に違反しているか否かにより、障害を検出することができる。
【００８３】
サービス障害検出部１１５は、入力ログに属性情報１０５として記録されたサービスの実行タイミングが、サービスの実行タイミングと一致しない場合は、そのサービスに障害が発生したものと判定する。
【００８４】
サービス障害検出部１１５は、入力ログに属性情報１０５として記録されたパラメータの値が、パラメータの値のとりうる範囲と一致しない場合は、そのサービスに障害が発生したものと判定する。
【００８５】
サービス障害検出部１１５は、入力ログに属性情報１０５として記録されたサービスの戻り値が。パラメータの値のとりうる範囲と一致しない場合は、そのサービスに障害が発生したものと判定する。
【００８６】
サービス障害検出部１１５は、サービス障害影響範囲特定部１１２の算出したサービス障害の影響範囲の広いサービスであって、且つ、サービス障害定義管理部１１３が記憶したサービス障害定義情報に違反しているサービスの障害を優先的に検出する。サービス障害検出部１１５は、サービス障害影響範囲特定部１１２の算出したサービス障害の影響範囲にかかわりなく、サービス障害定義管理部１１３が記憶したサービス障害定義情報に違反しているサービスの障害を優先的に検出するようにしてもよい。
【００８７】
以上の構成および動作により、この実施の形態のサービス運用管理システム１００は以下のような効果を奏する。
【００８８】
サービス障害検出部１１５が、メッセージログ１０７から属性情報１０５を抽出し、当該属性情報１０５の値を、サービス障害定義管理部１１３の保管するサービス障害定義情報と照合するので、サービス障害定義管理部１１３が記憶したサービス障害定義に違反しているサービスの障害を優先的に検出することができる。また、サービス障害影響範囲特定部１１２の算出するサービス障害の影響範囲をあわせて用いれば、さらに、重要なサービスの障害を優先的に検出することを可能にする。
【００８９】
実施の形態３．
実施の形態２において、メッセージからの属性抽出はＥＳＢ１０２のログの形式に依存する形で実現する必要がある。このため、企業合併や提携などで、図１のように、サービス運用管理システム１００が複数のＥＳＢ１０２のトランザクションログ１０８に対応しようとする場合、ＥＳＢ１０２を監視対象として追加したり、ＥＳＢ１０２をリプレースしたりするたびにサービス運用管理システム１００の修正が必要となり、ＳＯＡの目的である柔軟かつ迅速なサービス構成変更に支障をきたすという課題がある。
【００９０】
このＥＳＢ１０２の処理の記録は、ＥＳＢ１０２の種類により様々な形式がある。これらの例を図７に示す。
【００９１】
１．特殊な形式のＥＳＢログ（図７右側）
ＥＳＢ１０２の処理をテキスト形式のトランザクションログ１０８に記録し、これとは別にサービス間のメッセージをファイルとして保管し、トランザクションログ１０８中にメッセージのファイル名とメッセージセッションＩＤなどを記録するもの。
【００９２】
２．一般的なＥＳＢログ（図７左側）
ＥＳＢ１０２のトランザクションログ１０８がサービス間のメッセージ全文を包含するもの。
【００９３】
従来の技術によるサービス運用管理装置では、このようなＥＳＢ１０２のログの形式に応じて、メッセージのログまたはトランザクションログ１０８から属性を抽出するための仕組み（ロジック）を用意する必要があった。
【００９４】
図１において、この実施の形態のサービス運用管理システム１００ではサービス部１０１がメッセージ１０４に属性情報１０５を付加するほか、メッセージ中の属性抽出のための属性クエリ１０６を添付することにより対処する。また、サービス運用管理装置１０３には、ログ内のメッセージ中の属性クエリ１０６を解釈してメッセージ中の属性を抽出する属性クエリ解釈部１０９と、抽出した属性を保管する属性管理部１１０とを備えるようにする。
【００９５】
属性クエリ１０６の例を図８に示すメッセージ１０４に示す。図８において、＜ｑｕｅｒｙ＞〜＜／ｑｕｅｒｙ＞で囲まれた部分（点線枠内）が、ｓｅｓｓｉｏｎ（セッションＩＤ）、ｊｏｂ（業務ＩＤ）、ｓｅｒｖｉｃｅ（サービスＩＤ）、ｔｉｍｅ（実行時刻）の属性を抽出するための属性クエリである。この例では、メッセージ１０４がＸＭＬ形式であるため、ＸＭＬ文書内における情報の位置を記述する標準的なＸＰａｔｈ記法で記述したクエリを示す。属性には、当該メッセージが高重要度であることを示す値を含ませてもよい。その場合には、サービス部１０１は、重要度の属性を抽出するための属性クエリを付加する。
【００９６】
≪サービス部１０１の動作≫
図９に、サービス部１０１の処理の動作フローチャートを示す。まず、サービス部１０１は、ユーザに提供する機能（企業の業務サービスなど）を実行し（Ｓ３０１）、この結果をもとにメッセージ１０４を生成する（Ｓ３０２）。このメッセージ１０４の生成に当たり、サービス部１０１は、メッセージ１０４に属性情報１０５を添付する（Ｓ３０３、Ｓ３０４）。更に、サービス部１０１は、属性情報１０５をメッセージ１０４から取り出すための属性クエリ１０６を生成し、属性クエリ１０６をメッセージ１０４に添付する（Ｓ３０５、Ｓ３０６）。
【００９７】
なお、サービス運用管理システム実現上の都合によっては、属性クエリ１０６は属性情報１０５の全てに対して添付してもよく、一部に対して添付してもよい。
【００９８】
これらの処理を完了すると、サービス部１０１は、ＥＳＢ１０２または他のサービスに向けて当該メッセージ１０４を送付し（Ｓ３０７）、処理を終了する。
【００９９】
≪属性クエリ解釈部１０９の動作≫
図１０と図１１に、サービス運用管理装置１０３の属性クエリ解釈部１０９の処理の動作フローチャートを示す。
【０１００】
サービス運用管理装置１０３は、ＥＳＢ１０２のメッセージログ１０７またはトランザクションログ１０８を入力ログの入力として受け取り、入力した入力ログが、メッセージログ１０７であるか、トランザクションログ１０８であるかを識別する。
【０１０１】
入力ログがメッセージログ１０７である場合、Ｓ５０１〜Ｓ５０８の処理を行う。
【０１０２】
入力ログが一般的な形式のトランザクションログ１０８（図７左側）である場合、Ｓ４１０〜Ｓ４１７の処理を行う。
【０１０３】
入力ログが特殊な形式のトランザクションログ１０８（図７右側）である場合、Ｓ４０４〜Ｓ４０７の処理を行う。
【０１０４】
入力ログがトランザクションログ１０８である識別は、例えば、メッセージログ１０７（及びメッセージ１０４）がＸＭＬであり、トランザクションログ１０８が構造を持たないテキスト情報である場合、図８のメッセージの例において１行目が「＜？ＸＭＬ  ｖｅｒｓｉｏｎ  …？＞」であるかどうか判定することにより行うことができる。１行目が「＜？ＸＭＬ  ｖｅｒｓｉｏｎ  …？＞」であれば、メッセージログ１０７（及びメッセージ１０４）であると判断する。１行目が「＜？ＸＭＬ  ｖｅｒｓｉｏｎ  …？＞」でなければ、トランザクションログ１０８であると判断する。
【０１０５】
サービス運用管理装置１０３は、ＥＳＢ１０２のメッセージログ１０７またはトランザクションログ１０８を入力ログの入力として受け取り（Ｓ４０１）、入力した入力ログがメッセージログ１０７であるか否かを識別する。
【０１０６】
次に、入力ログが、メッセージログ１０７であるか、トランザクションログ１０８であるかを識別する（Ｓ４０２）。
【０１０７】
Ｓ４０２において入力ログがメッセージログ１０７でない場合、属性クエリ解釈部１０９は、図７の一般的なＥＳＢ１０２のログのようにトランザクションログ１０８がメッセージログ１０７（ＸＭＬ）を包含するかどうかを識別する（Ｓ４０３）。メッセージログ１０７（ＸＭＬ）を包含しない場合（特殊な形式のトランザクションログ１０８の場合）、属性クエリのうち、トランザクションログ１０８を対象としたものと解釈し、メッセージに含まれない属性情報を切り出し（Ｓ４０４）、入力ログに記録されているサービスを取り出し（Ｓ４０５）、サービス障害検出（優先実行されていないサービス障害の検出を含む）をサービス障害検出部１１５に実行させる（Ｓ４０６）。あるいは、属性クエリ解釈部１０９は、自らサービス障害検出部１１５と同様の処理を実行してサービス障害を検出する。
【０１０８】
属性クエリ解釈部１０９は、Ｓ４０５で取り出したサービスが、入力した入力ログに記録されている最後のサービスかどうか判断し（Ｓ４０７）、最後のサービスでない場合、入力した入力ログに記録されている次のサービスについてＳ４０６を実行する。Ｓ４０７で最後のサービスである場合、属性クエリ解釈部１０９は、当該入力をログ管理部１１６のログ保管機能により統合ログ記憶部１１７に格納し（Ｓ４０８）、処理を終了する。
【０１０９】
Ｓ４０３で、トランザクションログ１０８がメッセージログ１０７（ＸＭＬ）を包含する場合（一般的な形式のトランザクションログ１０８の場合）、属性クエリ解釈部１０９は、入力された入力ログからメッセージログ（ＸＭＬ）を切り出し（Ｓ４１０）、メッセージログのそれぞれから属性クエリ１０６を切り出す（Ｓ４１１）。これは例えば、サービス部１０１が、メッセージ中に属性クエリ１０６の始点・終点を示す予約語を挿入することにより実現できる。属性クエリ解釈部１０９は、Ｓ４１１で、入力ログ中の最後の属性クエリ１０６かどうか判定し（Ｓ４１２）、最後の属性クエリ１０６でない場合はＳ４１０で切り出したメッセージログから属性クエリ１０６を取り出すＳ４１１の処理を繰り返す。Ｓ４１２で入力中の最後の属性クエリである場合、属性クエリ解釈部１０９は、属性クエリ解釈を実行する（Ｓ４１３）。これは例えば、ＸＰａｔｈ処理系を起動し図８で示した属性クエリおよびメッセージログをＸＰａｔｈ処理系に入力することにより実現できる。この結果を受け、属性クエリ解釈部１０９は、属性中に当該メッセージが高重要度であることを示す値を含むかどうか確認する（Ｓ４１４）。ここで高重要度を示す値を含む場合、サービス運用管理装置１０３は、サービス障害検出部１１５によるサービス障害検出（サービス実行順序不正検出）を優先実行する（Ｓ４１６）。あるいは、属性クエリ解釈部１０９は、自らサービス障害検出部１１５と同様の処理を実行してサービス障害を検出する。
【０１１０】
Ｓ４１４で属性中に当該メッセージが高重要度を示す値を含まない場合、属性クエリ解釈部１０９は、当該サービスのサービス障害影響範囲をサービス障害影響範囲特定部１１２に算出させ、その値が閾値を超えるかどうか判断する（Ｓ４１５）。ここで閾値を超える場合、サービス運用管理装置１０３は、Ｓ４１６を実行する。すなわち、サービス運用管理装置１０３は、サービス障害検出部１１５によるサービス障害検出を優先実行する（Ｓ４１６）。あるいは、属性クエリ解釈部１０９は、自らサービス障害検出部１１５と同様の処理を実行してサービス障害を検出する。
【０１１１】
Ｓ４１５で閾値を超えない場合、またはＳ４１６の処理を終えた場合、属性クエリ解釈部１０９は、Ｓ４１０で取り出したメッセージが、入力中の最後のメッセージ本文であるかどうかを確認する（Ｓ４１７）。最後のメッセージでない場合、Ｓ４１０〜Ｓ４１７の処理を繰り返し、最後のメッセージである場合、属性クエリ解釈部１０９は、当該入力をログ管理部１１６のログ保管機能により統合ログ記憶部１１７に格納し（Ｓ４０８）処理を終了する。
【０１１２】
Ｓ４０２において、入力ログがメッセージログ１０７である場合、属性クエリ解釈部１０９は図１１の処理を行う。図１１においては、まず、属性クエリ解釈部１０９は入力ログから属性クエリを切り出す（Ｓ５０１）。これはＳ４１１と同じ処理として実現できる。この処理を、入力ログ中の最後の属性クエリを取り出すまで繰り返す（Ｓ５０２）。次に、属性クエリ解釈部１０９は、取り出した属性クエリのそれぞれに対し、属性クエリ解釈を実行する（Ｓ５０３）。この処理は、Ｓ４１３と同様な処理として実現できる。この処理を、最後の属性クエリになるまで繰り返す（Ｓ５０４）。この結果をもとに、属性クエリ解釈部１０９は、メッセージログ１０７の含む属性に高重要度を示す値が含まれるか判断する（Ｓ５０５）。ここで高重要度を示す値が含まれる場合、サービス運用管理装置１０３は、サービス障害検出を優先実行する（Ｓ５０７）。Ｓ５０５で属性中に高重要度を示す値を含まない場合、属性クエリ解釈部１０９は、当該サービスの影響範囲を算出し、その値が閾値を超えるかどうか判断する（Ｓ５０６）。ここで閾値を超える場合、サービス運用管理装置１０３は、サービス障害検出を優先実行する（Ｓ５０７）。Ｓ５０６で閾値を超えない場合、属性クエリ解釈部１０９は、このメッセージのログに関する情報を含むトランザクションログ１０８が入力されるまで、収集・蓄積部１１４またはログ管理部１１６でメッセージログ１０７を、また属性管理部１１０で属性の値を、それぞれ保管する（Ｓ５０８）。Ｓ５０７またはＳ５０８の後、属性クエリ解釈部１０９は図１０のＳ４０９以下の処理を行う。
【０１１３】
なお、図１０は、重要度の高いサービスの障害検出を、サービス障害影響範囲の広いサービスの障害検出よりもさらに優先して実行するように構成した例である。実施の都合によっては、例えばサービス障害影響範囲の広いサービスの障害検出を、重要度の高いサービスの障害検出よりも、優先して実行するように構成してもよい。
【０１１４】
また、図５のＳ１０２〜Ｓ１０４における入力ログ中のサービスＩＤ、業務ＩＤ、セッションＩＤの取り出しは、サービスＩＤ、セッションＩＤ、業務ＩＤをメッセージの属性としてメッセージ１０４に付加して、属性として取り出してもよい。または、図５のＳ１０２〜Ｓ１０４における入力ログ中のサービスＩＤ、業務ＩＤ、セッションＩＤの取り出しは、当該メッセージにサービスＩＤ、セッションＩＤ、業務ＩＤを取り出す属性クエリを付加し、図１０と図１１にかかる手順で属性クエリを実行することにより実現してもよい。
【０１１５】
以上の構成および動作により、この実施の形態は以下のような効果を奏する。
属性クエリ解釈部１０９による動作により、ＥＳＢ１０２の種類により異なるログ形式に依存せず属性情報を取り出し、メッセージ中の属性で示されたサービスの重要度とサービス障害影響範囲特定部１１２の算出するサービス障害の影響範囲との何れか又は両方をパラメータとして、サービス障害検出の優先度を決定することが可能となる。
【０１１６】
以上のように、実施の形態１〜３では、機能をユーザに提供する過程でメッセージを交換するコンピュータソフトウェアであるサービスの障害を検出するサービス運用管理装置１０３を説明した。サービス運用管理装置１０３は、
サービス実行順序の定義、およびサービスの集合である業務とサービスの対応関係の定義を管理するサービス構成情報管理部１１１と、
サービス構成情報管理部の情報をもとに、あるサービスにおいて障害が発生した場合に影響を受けるサービスの範囲を算出するサービス障害影響範囲特定部１１２と、
サービス同士のメッセージ中継を行うミドルウェアの処理の記録であるトランザクションログ１０８およびサービス同士のメッセージのログを収集蓄積する収集・蓄積部１１４と、
種類の異なるログと当該ログの属性情報を関連付けて蓄積し管理するログ管理部１１６と、
上記ログからサービスの実行された順序を検出し、サービスの実行された順序とサービス構成情報管理部の持つサービス実行順序の定義を比較することによりサービス実行順序不正を検出するサービス障害検出部１１５と
を備えたことを特徴とする。
【０１１７】
また、サービス運用管理装置１０３は、ログ本文と、当該ログを生成したサービスを識別する情報、および、連続して実行する一連のサービスを識別するセッションの情報、および、当該ログを生成したサービスの属す業務が次に実行する可能性のあるサービスの識別情報のリストをサービス構成情報管理部１１１に関連付けて保管している。
【０１１８】
サービス障害検出部１１５、あるログからサービス実行順序不正を検出する処理の際、不正検出処理対象となっているログと同じセッションで直前に実行したサービスのログに関連付けられた、当該直前に実行したサービスが次に実行する可能性のあるサービスおよび業務の識別情報のリストをサービス構成情報管理部１１１から取り出し、不正検出処理の対象となっているログのサービスおよび業務の識別情報と比較することにより、サービス実行順序不正を検出する。
【０１１９】
実施の形態１〜３では、サービス運用管理システム１００は、
機能をユーザに提供する過程でメッセージを交換するコンピュータソフトウェアとハードウェアであるサービス部１０１と、
サービス同士のメッセージ中継を行うとともに、個々の処理を記録するミドルウェアと、
前述したサービス運用管理装置と、
を持ち、
サービス運用管理装置１０３は、トランザクションログ１０８、メッセージのログを、サービス構成情報管理部１１１の保管するサービス実行順序定義情報と照合し、サービス障害影響範囲特定部１１２の算出するサービス障害の影響範囲の広いサービスの実行順序不正を優先的に検出することを特徴とする。
【０１２０】
サービス障害影響範囲特定部１１２は、サービス構成情報管理部１１１の情報をもとに、あるサービスにおいて障害が発生した場合に影響を受けるサービスの範囲を算出する。サービス障害影響範囲特定部１１２は、サービス間の階層情報（あるサービス（親サービス）が他のサービス（子サービス）を呼び出す関係、および同じ親サービスに呼び出されたサービス群（兄弟サービス）の関係の情報）をもとに、サービス障害影響範囲を特定する。
【０１２１】
サービス障害影響範囲特定部１１２は、障害の発生したサービスに初期値を付与し、また当該サービスを呼ぶサービスおよび当該サービスから呼び出されるサービスは呼び出しごとに値が減算または加算されるものとするよう構成した解析優先度スコアをもとに、サービス障害影響範囲を算出することを特徴とする。
【０１２２】
サービス運用管理装置は、
前述のミドルウェアのログおよびメッセージの属性からサービス障害を検出するのに必要な、サービス障害定義を保管するサービス障害定義管理部１１３と、
サービス障害定義管理部１１３よりサービス障害定義情報を取り出し、前述のログおよびメッセージおよびそれらの属性との照合を行いサービスで発生した障害を検出するサービス障害検出部１１５と、
を備え、
サービス部１０１はメッセージ１０４に、サービス障害を検出するのに必要な付加情報である属性情報１０５を付加し、
属性クエリ解釈部１０９において、メッセージのログから属性を抽出し、属性クエリ解釈部１０９が、当該属性情報およびトランザクションログ１０８、メッセージのログ、属性の値を、サービス障害定義管理部１１３の保管するサービス障害定義情報、およびサービス構成情報管理部１１１の保管するサービス実行順序定義情報と照合し、サービス障害影響範囲特定部１１２の算出するサービス障害の影響範囲の広いサービス、の障害を優先的に検出することを特徴とする。
【０１２３】
サービス部１０１がメッセージに付加する属性のうちに、当該サービスの重要度に関する情報を含み、サービス実行順序不正またはその他のサービス障害検出にあたっては、サービス障害影響範囲に加え、サービスの重要度を、サービス障害検出処理の優先度決定のパラメータとして用いることを特徴とする。
【０１２４】
属性クエリ解釈部１０９は、サービス同士の授受するメッセージに付加された属性、および当該属性をメッセージより抽出するための属性クエリを、当該メッセージより抽出し、また属性クエリを解釈し属性の値を抽出する。
【０１２５】
属性クエリ解釈部１０９は、ミドルウェアにおいてメッセージのログがトランザクションログ１０８本文に含まれていても、属性クエリを解釈することにより当該属性をメッセージより抽出する。また、メッセージのログがトランザクションログ１０８とは別のファイルとして管理されていても、明示的な設定変更を行わずに、当該属性をメッセージより抽出する。
【０１２６】
属性クエリ解釈部１０９は、メッセージ中の属性で示されたサービスの重要度、またはサービス障害影響範囲特定部の算出するサービス障害の影響範囲をパラメータとして算出した優先度に従いサービス障害を検出する。
【０１２７】
図１２は、実施の形態１〜３におけるサービス部１０１、サービス運用管理装置１０３の外観の一例を示す図である。
図１２において、サービス部１０１又はサービス運用管理装置１０３は、システムユニット９１０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置９０１、キーボード９０２（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス９０３、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。
【０１２８】
システムユニット９１０は、コンピュータであり、ファクシミリ機９３２、電話器９３１とケーブルで接続され、また、ローカルエリアネットワーク９４２（ＬＡＮ）、ゲートウェイ９４１を介してインターネット９４０に接続されている。
【０１２９】
図１３は、実施の形態１〜３におけるサービス部１０１、ＥＳＢ１０２、サービス運用管理装置１０３のハードウェア資源の一例を示す図である。
図１３において、サービス部１０１、ＥＳＢ１０２、サービス運用管理装置１０３は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３、ＲＡＭ９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５、プリンタ装置９０６、スキャナ装置９０７、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
【０１３０】
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
【０１３１】
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。
【０１３２】
通信ボード９１５は、ファクシミリ機９３２、電話器９３１、ＬＡＮ９４２等に接続されている。通信ボード９１５は、ＬＡＮ９４２に限らず、インターネット９４０、ＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。インターネット９４０或いはＩＳＤＮ等のＷＡＮに接続されている場合、ゲートウェイ９４１は不用となる。
【０１３３】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【０１３４】
上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【０１３５】
ファイル群９２４には、実施の形態１〜３の説明において、「〜の判定結果」、「〜の計算結果」、「〜の処理結果」として説明する情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【０１３６】
また、実施の形態１〜３の説明において説明したフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｋ）等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【０１３７】
また、実施の形態１〜３の説明において「〜部」として説明したものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明したものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１〜３で述べた「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜３で述べた「〜部」の手順や方法をコンピュータに実行させるものである。
【符号の説明】
【０１３８】
１００  サービス運用管理システム、１０１  サービス部、１０２  ＥＳＢ、１０３  サービス運用管理装置、１０４  メッセージ、１０５  属性情報、１０６  属性クエリ、１０７  メッセージログ、１０８  トランザクションログ、１０９  属性クエリ解釈部、１１０  属性管理部、１１１  サービス構成情報管理部、１１２  サービス障害影響範囲特定部、１１３  サービス障害定義管理部、１１４  収集・蓄積部、１１５  サービス障害検出部、１１６  ログ管理部、１１７  統合ログ記憶部、９０１  表示装置、９０２  キーボード、９０３  マウス、９０４  ＦＤＤ、９０５  コンパクトディスク装置、９０６  プリンタ装置、９０７  スキャナ装置、９１０  システムユニット、９１１  ＣＰＵ、９１２  バス、９１３  ＲＯＭ、９１４  ＲＡＭ、９１５  通信ボード、９２０  磁気ディスク装置、９２１  オペレーティングシステム、９２２  ウィンドウシステム、９２３  プログラム群、９２４  ファイル群、９３１  電話器、９３２  ファクシミリ機、９４０  インターネット、９４１  ゲートウェイ、９４２  ローカルエリアネットワーク。
【図１】
2013003681.tif 000003
【図２】
2013003681.tif 000004
【図３】
2013003681.tif 000005
【図４】
2013003681.tif 000006
【図５】
2013003681.tif 000007
【図６】
2013003681.tif 000008
【図７】
2013003681.tif 000009
【図８】
2013003681.tif 000010
【図９】
2013003681.tif 000011
【図１０】
2013003681.tif 000012
【図１１】
2013003681.tif 000013
【図１２】
2013003681.tif 000014
【図１３】
2013003681.tif 000015