(57)【要約】【課題】複合Ｗｅｂサービスにおけるサービス相互の関係やフロー依存性を効率的に把握・解析することで複合Ｗｅｂサービスの障害管理、性能管理を改善する。【解決手段】サービス管理用サーバ１００において、サービス構成解析部１０３が、複合Ｗｅｂサービスのタスクフローが定義されているＢＰＥＬ等の定義情報を解析して、複合Ｗｅｂサービスを各々のプリミティブＷｅｂサービスに分割するとともに、タスクフローにおいて条件分岐により並列関係にある二つ以上のＷｅｂサービスを同一のグループに分類し、タスクフローにおいて並列関係にないタスクをそれぞれ個別のグループに分類し、更に、定義情報に基づき、グループ間のフロー依存関係を解析し、画面表示部１０８が、複数のタスクをサービス構成解析部１０３により分類されたグループごとに区分して表示し、また、グループ間のフロー依存関係を表示する。【選択図】図３
2008003709.tif 000002
【特許請求の範囲】
【請求項１】
複数のタスクを包含する複合タスクのタスクフローが定義されている定義情報を解析して、複合タスクを各々のタスクに分割するタスク分割部と、
前記定義情報に定義されているタスクフローにおいて同位にある二つ以上のタスクを同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて同位にないタスクをそれぞれ個別のタスクグループに分類して、前記複合タスクに包含される複数のタスクを二以上のタスクグループに分類するタスクグループ解析部とを有することを特徴とする管理装置。
【請求項２】
前記タスクグループ解析部は、
前記定義情報に定義されているタスクフローにおいて条件分岐により並列関係にある二つ以上のタスクを同位にあるタスクとして同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて並列関係にないタスクをそれぞれ個別のタスクグループに分類することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記タスクグループ解析部は、
前記定義情報に基づき、タスクグループ間のフロー依存関係を解析することを特徴とする請求項１に記載の管理装置。
【請求項４】
前記管理装置は、更に、
前記タスク分割部により分割された複数のタスクを前記タスクグループ解析部により分類されたタスクグループごとに区分して表示する表示部を有することを特徴とする請求項１に記載の管理装置。
【請求項５】
前記管理装置は、更に、
前記タスク分割部により分割された複数のタスクを前記タスクグループ解析部により分類されたタスクグループごとに区分して表示するとともに、前記タスクグループ解析部により解析されたタスクグループ間のフロー依存関係を表示する表示部を有することを特徴とする請求項３に記載の管理装置。
【請求項６】
前記タスクグループ解析部は、
各タスクが実現する機能及び各タスクグループが実現する機能の少なくともいずれかを解析し、
前記表示部は、
前記タスクグループ解析部により解析された各タスクが実現する機能及び各タスクグループが実現する機能の少なくともいずれかを表示することを特徴とする請求項４に記載の管理装置。
【請求項７】
前記管理装置は、更に、
前記複合タスクに包含される各タスクの状態を監視し、いずれかのタスクにおける障害を検知する状態監視部を有し、
前記表示部は、
前記状態監視部により障害が検知された場合に、対象となるタスクを明示して当該タスクに障害が発生した旨を表示することを特徴とする請求項４に記載の管理装置。
【請求項８】
前記管理装置は、更に、
前記複合タスクに包含される各タスクの実行頻度を計測する実行頻度計測部を有し、
前記表示部は、
前記実行頻度計測部により計測された各タスクの実行頻度を表示することを特徴とする請求項４に記載の管理装置。
【請求項９】
前記管理装置は、更に、
前記複合タスクに包含される各タスクの実行性能を計測する実行性能計測部を有し、
前記表示部は、
前記実行性能計測部により計測された各タスクの実行性能を表示することを特徴とする請求項４に記載の管理装置。
【請求項１０】
前記タスク分割部は、
複数のＷｅｂサービスを包含する複合Ｗｅｂサービスを、前記複合Ｗｅｂサービスのタスクフローが定義されているＢＰＥＬ４ＷＳ（Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ  ｆｏｒ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ）による定義情報を解析して、各々のＷｅｂサービスに分割し、
前記タスクグループ解析部は、
前記ＢＰＥＬ４ＷＳによる定義情報に定義されているタスクフローにおいて同位にある二つ以上のＷｅｂサービスを同一のタスクグループに分類し、前記ＢＰＥＬ４ＷＳによる定義情報に定義されているタスクフローにおいて同位にないＷｅｂサービスをそれぞれ個別のタスクグループに分類して、前記複合Ｗｅｂサービスに包含される複数のＷｅｂサービスを二以上のタスクグループに分類することを特徴とする請求項１に記載の管理装置。
【請求項１１】
複数のタスクを包含する複合タスクの各タスクの状態を監視し、いずれかのタスクにおける障害を検知する状態監視部と、
前記状態監視部によりいずれかのタスクにおける障害が検知された場合に、障害が検知された障害タスクを前記複合タスクを利用する端末装置に通知するための障害通知情報を生成する通知情報生成部と、
前記通知情報生成部により生成された障害通知情報を送信する送信部とを有することを特徴とする管理装置。
【請求項１２】
前記管理装置は、
前記端末装置の選択に基づいて前記複合タスクのいずれかのタスクを実行するサーバ装置に接続され、
前記状態監視部は、
前記端末装置により実行が選択される可能性のある選択可能性タスクを前記サーバ装置から通知され、前記サーバ装置から通知された前記選択可能性タスクに障害が発生しているか否かを検知し、
前記通知情報生成部は、
前記状態監視部により前記選択可能性タスクの障害が検知された場合に、前記選択可能性タスクを障害タスクとして示す障害通知情報を生成し、
前記送信部は、
前記サーバ装置から前記端末装置に前記選択可能性タスクを障害タスクとして通知させるために、前記通知情報生成部により生成された障害通知情報を前記サーバ装置に対して送信することを特徴とする請求項１１に記載の管理装置。
【請求項１３】
前記通知情報生成部は、
前記状態監視部により障害が検知された障害タスクとタスクフローにおいて並列関係にある他のタスクが存在する場合に、前記障害タスクの代替として前記他のタスクを前記端末装置に通知するための情報を前記障害通知情報として生成することを特徴とする請求項１１に記載の管理装置。
【請求項１４】
前記管理装置は、更に、
前記複合タスクに包含される各タスクの実行性能を計測する実行性能計測部を有し、
前記通知情報生成部は、
前記実行性能計測部により計測された各タスクの実行性能を前記端末装置に通知するための実行性能通知情報を生成し、
前記送信部は、
前記通知情報生成部により生成された実行性能通知情報を送信することを特徴とする請求項１１に記載の管理装置。
【請求項１５】
前記状態監視部は、
複数のＷｅｂサービスを包含する複合Ｗｅｂサービスの各Ｗｅｂサービスの状態を監視し、いずれかのＷｅｂサービスにおける障害を検知し、
前記通知情報生成部は、
前記状態監視部によりいずれかのＷｅｂサービスにおける障害が検知された場合に、障害が検知された障害Ｗｅｂサービスを前記複合Ｗｅｂサービスを利用する端末装置に通知するための障害通知情報を生成することを特徴する請求項１１に記載の管理装置。
【請求項１６】
複数のタスクを包含する複合タスクのタスクフローが定義されている定義情報を解析して、複合タスクを各々のタスクに分割するタスク分割ステップと、
前記定義情報に定義されているタスクフローにおいて同位にある二つ以上のタスクを同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて同位にないタスクをそれぞれ個別のタスクグループに分類して、前記複合タスクに包含される複数のタスクを二以上のタスクグループに分類するタスクグループ解析ステップとを有することを特徴とするタスク管理方法。
【請求項１７】
複数のタスクを包含する複合タスクの各タスクの状態を監視し、いずれかのタスクにおける障害を検知する状態監視ステップと、
前記状態監視ステップによりいずれかのタスクにおける障害が検知された場合に、障害が検知された障害タスクを前記複合タスクを利用する端末装置に通知するための障害通知情報を生成する通知情報生成ステップと、
前記通知情報生成ステップにより生成された障害通知情報を送信する送信ステップとを有することを特徴とするタスク管理方法。
【請求項１８】
複数のタスクを包含する複合タスクのタスクフローが定義されている定義情報を解析して、複合タスクを各々のタスクに分割するタスク分割処理と、
前記定義情報に定義されているタスクフローにおいて同位にある二つ以上のタスクを同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて同位にないタスクをそれぞれ個別のタスクグループに分類して、前記複合タスクに包含される複数のタスクを二以上のタスクグループに分類するタスクグループ解析処理とをコンピュータに実行させることを特徴とするプログラム。
【請求項１９】
複数のタスクを包含する複合タスクの各タスクの状態を監視し、いずれかのタスクにおける障害を検知する状態監視処理と、
前記状態監視処理によりいずれかのタスクにおける障害が検知された場合に、障害が検知された障害タスクを前記複合タスクを利用する端末装置に通知するための障害通知情報を生成する通知情報生成処理と、
前記通知情報生成処理により生成された障害通知情報を送信する送信処理とをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＷｅｂサービス（主にＷｅｂサービスを組み合わせて構築するコンポジットサービス）の管理・監視技術、およびＷｅｂサービス管理システムの管理情報の再利用技術に関する。
【背景技術】
【０００２】
Ｗｅｂサービスを利用したシステム構築では、プリミティブなビジネスロジックをＷｅｂサービスインタフェース（リモート呼び出し用のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ））として定義・公開しネットワーク上でプログラムのように組み合わせて新しいシステムを構築する方法がある。
また、このようにして構築したシステムをＷｅｂサービスとして公開することもできる（以下、「複合Ｗｅｂサービス」と呼ぶ）。このための仕様が標準化されつつある。
まず、プリミティブなＷｅｂサービス定義手法としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式の定義ファイルを利用したＷＳＤＬ（ＷＥＢ  ＳＥＲＶＩＣＥ  ＤＥＳＣＲＩＰＩＴＩＯＮ  ＬＡＮＧＵＡＧＥ）仕様があり、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ，ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／）で標準化作業が行われている。
また、Ｗｅｂサービスを組み合わせ、ビジネスフローを定義する言語としてＢＰＥＬ４ＷＳ（Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ  ｆｏｒ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ）（以下、単にＢＰＥＬともいう）があり、ＯＡＳＩＳ（ｈｔｔｐ：／／ｗｗｗ．ｏａｓｉｓ−ｏｐｅｎ．ｏｒｇ／）で標準化作業が進んでいる。
【０００３】
ビジネスプロセスを組み合わせて業務システムを構築する複合Ｗｅｂサービスの例が図１０である。
図１０は、書籍購入システムの複合Ｗｅｂサービスの例を示す。
以下単に「サービス」と書いた場合はＷｅｂサービスのことを指すこととする（但しＷｅｂプロトコルに限定されるものではない。定義されたコンピュータの機能インタフェースがネットワークを介して呼び出せるような仕組みのことを意味する）。
サービスＡは書籍（商品）を選択して確定するまでの受注サービス、サービスＢはクレジットにより決済手段を提供するサービス、サービスＣはダイレクトバンキングにより決済手段を提供するサービス、サービスＤは配送管理サービスであり、これらの複数のサービスをサービスＸが統合して、書籍販売システム（書籍販売サービス）が構成される。
ここで、サービスＡ〜Ｄの各サービスをプリミティブＷｅｂサービス又はファンクショナルＷｅｂサービスといい、サービスＸを複合Ｗｅｂサービスという。
プリミティブＷｅｂサービス又はファンクショナルＷｅｂサービスは、具体的な機能を提供するＷｅｂサービスである。上記の書籍販売サービス以外の例では、例えばプリンタ出力を提供するＷｅｂサービスなどである。
【０００４】
図１０では、サービスＡがサービスＡサーバ（商品（書籍）選択サービス用サーバ）、サービスＢがサービスＢサーバ（クレジット決済サービス用サーバ）、サービスＣがサービスＣサーバ（オンラインバンキング決済サービス用サーバ）、サービスＤがサービスＤサーバ（出荷処理受付サービス用サーバ）、サービスＸが書籍購入システム用サーバによりそれぞれ提供されている。
そして、この書籍購入システムを利用する利用者の端末装置が書籍購入システム用サーバと通信を行うことで、端末装置の画面には、サービスの提供段階に応じて、サービスＡ用の商品選択画面、サービスＢ又はサービスＣ用の決済手段選択画面及び決済情報入力画面、サービスＤ用の出荷処理指示画面が表示され、利用者がこれら画面情報に従って操作を行うことにより各サービスが実現され、最終的に書籍の購入を行うことができる。
【０００５】
また、定義されたサービスをリポジトリに登録し、公開・検索する仕組みも検討されており、ＵＤＤＩ仕様としてＯＡＳＩＳで検討が進んでいる（ｈｔｔｐ：／／ｗｗｗ．ｕｄｄｉ．ｏｒｇ）。
【０００６】
また、Ｗｅｂサービスを管理する手法としてＷＳＤＭ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｍａｎａｇｅｍｅｎｔ）仕様がＯＡＳＩＳを中心にすすめられている。ＷＳＤＭでは管理用のＷｅｂサービスインタフェースを実装・定義し、管理用Ｗｅｂサービスを介して、ファンクショナルＷｅｂサービスの管理情報を収集する。
【０００７】
また、Ｗｅｂサービスに関連する技術として、以下の特許文献１〜３及び非特許文献１に開示された技術がある。
【特許文献１】特開２００５−０６３４４０号公報
【特許文献２】特開２００２−２６８９７１号公報
【特許文献３】特開２００５−０５６４０５号公報
【非特許文献１】青木利晴  監修「Ｗｅｂサービスコンピューティング」、電子情報通信学会、２００５年２月１日、５２ｐ〜１２４ｐ
【発明の開示】
【発明が解決しようとする課題】
【０００８】
現状、単一のＷｅｂサービスの管理については検討はされているが、複合Ｗｅｂサービスの管理については具体的に検討されていない。このため複合Ｗｅｂサービスの一部となっている、ファンクショナルＷｅｂサービス（プリミティブＷｅｂサービス）に障害や性能劣化が起きた場合に、その影響範囲を迅速・的確に把握することが困難であるという課題がある。
【０００９】
そこで、本発明はこの課題を解決することを主な目的としており、複合Ｗｅｂサービスの構成管理（複合サービス間の依存管理）、すなわちサービス相互の関係やフロー依存性を効率的に把握・解析することで複合Ｗｅｂサービスの障害管理、性能管理を改善することを主な目的の一つとする。
【００１０】
また、従来、Ｗｅｂサービスに限らず、ネットワークの管理を行う管理システムは管理対象（アプリケーション、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）、サーバ、ネットワーク機器等）の状態を把握するため、管理サーバがＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）（ＰＩＮＧ）やＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）プロトコルやその他の方法（ＪＭＸ：Ｊａｖａ（登録商標）  Ｍａｎａｇｅｍｅｎｔ  ｅＸｔｅｎｓｉｏｎ等）等により管理データを収集、保存、解釈し、この情報をシステム管理者の管理画面上に表示していた。
これによって、システム管理者はシステム全体の構成を把握し、障害を切り分け、性能の劣化を発見しそれに対する対処を行う。
このように従来の考え方では管理情報は管理者がシステム管理するためだけに使うものであった。
【００１１】
すなわち、運用管理情報は、アプリケーションプログラム等の利用者のアプリケーション画面上に表示されないため、利用者はシステム利用前には、障害の発生やシステム性能の劣化を認識しえない。従って、システム障害時等において、システムに異常があるにもかかわらず、ユーザ操作や再試行操作を行うことにより、不要な負荷がシステムにかかり障害や性能劣化が拡大し、利用者からみるとシステム利用に対して不満がたまるという課題がある。
【００１２】
そこで、本発明では、管理サーバが収集した管理情報または管理用のＷｅｂサービスの管理データを利用者のアプリケーション画面に解析・表示しシステムの状況を適切に利用者に知らせることで、前述の課題を解決することを主な目的の一つとする。
【課題を解決するための手段】
【００１３】
本発明に係る管理装置は、
複数のタスクを包含する複合タスクのタスクフローが定義されている定義情報を解析して、複合タスクを各々のタスクに分割するタスク分割部と、
前記定義情報に定義されているタスクフローにおいて同位にある二つ以上のタスクを同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて同位にないタスクをそれぞれ個別のタスクグループに分類して、前記複合タスクに包含される複数のタスクを二以上のタスクグループに分類するタスクグループ解析部とを有することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、複合タスクの構成管理、すなわちタスク相互の関係やフロー依存性を効率的に把握・解析することが可能となる。
【発明を実施するための最良の形態】
【００１５】
実施の形態１．
図１は、本実施の形態に係る通信システムの構成例を示す。
図１において、サービス管理用サーバ装置１００（以下、サービス管理用サーバともいう）は、複合Ｗｅｂサービスの管理を行うサーバ装置である。サービス管理用サーバ装置１００は、管理装置の例である。
複合Ｗｅｂサービス用サーバ装置２００（以下、複合Ｗｅｂサービス用サーバともいう）は、複数のプリミティブＷｅｂサービスを統合するサーバ装置である。複合Ｗｅｂサービス用サーバ装置２００は、サーバ装置の例である。
プリミティブＷｅｂサービス用サーバ装置３００ａ及びプリミティブＷｅｂサービス用サーバ装置３００ｂ（以下、各々、プリミティブＷｅｂサービス用サーバともいう）は、複合Ｗｅｂサービスを構成するプリミティブＷｅｂサービスを提供するサーバ装置である。図１では、プリミティブＷｅｂサービス用サーバ装置３００ａは、サービスＡというＷｅｂサービスを提供し、プリミティブＷｅｂサービス用サーバ装置３００ｂは、サービスＢというＷｅｂサービスを提供する。
クライアント端末装置４００（以下、クライアント端末又はクライアントともいう）は、Ｗｅｂサービスを利用する利用者が用いる端末装置である。クライアント端末装置４００は、端末装置の例である。
これら、サービス管理用サーバ装置１００、複合Ｗｅｂサービス用サーバ装置２００、プリミティブＷｅｂサービス用サーバ装置３００ａ、プリミティブＷｅｂサービス用サーバ装置３００ｂ及びクライアント端末装置４００は、インターネット５００により接続されている。
【００１６】
まず、Ｗｅｂサービスの単体の管理を行う例を示す（ＷＳＤＭに準じた管理の例）。
これは、従来より存在するプリミティブＷｅｂサービス単体の管理技術である。
この場合は、サービス管理用サーバ装置１００に、管理対象のファンクショナルＷｅｂサービス（プリミティブＷｅｂサービス）の情報を収集するための管理インタフェースをＷｅｂサービスとして実装し、該インタフェースからファンクショナルＷｅｂサービスの管理情報を要求・応答型のメッセージにより収集する。
【００１７】
この際ファンクショナルＷｅｂサービスの管理情報を、どの管理用Ｗｅｂサービス（サービスのアドレス）から収集すれば良いかの対応付けは、関連付け情報（マネージメント・エンドポイント・リファレンス（Ｍ−ＥＰＲ））を管理することにより行う。
例えば、ファンクショナルＷｅｂサービスが実装されているエンドポイント（ＥＰ）に管理用Ｗｅｂサービスのエンドポイント情報を応答する機能を実装し、管理情報をどこから取得すれば良いかを解決する方法が考えら得る。
管理情報をどこから取得すればよいか（ＥＰＲ）がわかれば、あとはサービス管理用サーバ１００が管理用エンドポイントにファンクショナルＷｅｂサービスのリソース情報を指定して管理情報を収集する。
この際Ｍ−ＥＰＲがファンクショナルＷｅｂサービスと同じＥＰになっても良い。
他にも関連情報を管理する方法は考えられる。
【００１８】
Ｗｅｂサービスの管理項目として、例えば、Ｗｅｂサービスの可用性（Ｏｐｅｒａｔｉｏｎａｌ  Ｓｔａｔｕｓ）やＷｅｂサービスが呼び出された回数、そのうちの成功、失敗回数、最大遅延応答時間（最も応答に時間がかかった処理）、最新遅延応答時間、サービスの継続時間（起動からの時間）などを管理する。
【００１９】
次に、本実施の形態の目的の一つである複合Ｗｅｂサービスを管理する方法を説明する。
ここでは説明の都合上、図２のような複合Ｗｅｂサービスを考え、これに基づいて説明する。先に紹介したＢＰＥＬでは図２のようなフローをＸＭＬ形式のファイルで定義することが可能である。なお、本実施の形態は図２のような構成に限定されるものではなく、Ｗｅｂサービス（特に複合Ｗｅｂサービス）全般に適用できるものである。
【００２０】
Ｗｅｂサービスは狭義には各種Ｗｅｂサービス標準を利用してアクセス可能なプログラマブルなアプリケーション・コンポーネントへのインタフェースと考えられる。このようにＷｅｂサービスをプログラムのように組み合わせてシステムを構築するようなアーキテクチャにすると、プリミティブサービスの障害時において、Ｗｅｂサービスを利用して構築した業務システム（複合Ｗｅｂサービス）全体としてサービスを継続することが可能なのか否かが把握しにくくなる。すなわち複合Ｗｅｂサービスのアーキテクチャではシステム全体のサービスレベルの把握が困難になる傾向がある。このため本実施の形態ではサービス相互の関係やフロー依存性を考慮し、プリミティブサービスの障害によって複合サービスが影響受ける範囲等を適切に管理しシステム全体のサービスレベルの把握を容易にする。
【００２１】
図２は、書籍購入システムの複合Ｗｅｂサービスの例である。
以下単に「サービス」と書いた場合はＷｅｂサービスのことを指すこととする（但しＷｅｂプロトコルに限定されるものではない。定義されたコンピュータの機能インタフェースがネットワークを介して呼び出せるような仕組みのことを意味する）。
図１０の例と同様に、サービスＡは書籍（商品）を選択して確定するまでの受注サービス、サービスＢはクレジットにより決済手段を提供するサービス、サービスＣはダイレクトバンキングにより決済手段を提供するサービス、サービスＤは配送管理サービスであり、これらの複数のサービスをサービスＸが統合して、書籍販売システム（書籍販売サービス）が構成される。
ここで、サービスＡ〜Ｄの各サービスをプリミティブＷｅｂサービス又はファンクショナルＷｅｂサービスといい、サービスＸを複合Ｗｅｂサービスという。
【００２２】
また、図２では、サービスＡがサービスＡ用のプリミティブＷｅｂサービス用サーバ装置３００ａ、サービスＢがサービスＢ用のプリミティブＷｅｂサービス用サーバ装置３００ｂ、サービスＣがサービスＣ用のプリミティブＷｅｂサービス用サーバ装置３００ｃ、サービスＤがサービスＤ用のプリミティブＷｅｂサービス用サーバ装置３００ｄ、サービスＸが複合Ｗｅｂサービス用サーバ装置２００（書籍購入システム用サーバ）によりそれぞれ提供されている。
そして、この書籍購入システムを利用する利用者のクライアント端末装置４００が複合Ｗｅｂサービス用サーバ装置２００と通信を行うことで、クライアント端末装置４００の画面には、サービスの提供段階に応じて、サービスＡ用の商品選択画面、サービスＢ又はサービスＣ用の決済手段選択画面及び決済情報入力画面、サービスＤ用の出荷処理指示画面が表示され、利用者がこれら画面情報に従って操作を行うことにより各サービスが実現され、最終的に書籍の購入を行うことができる。
【００２３】
また、本実施の形態では、サービス管理用サーバ装置１００が、それぞれのプリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄと通信を行い、各プリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄの状態を管理している。また、同様に、サービス管理用サーバ装置１００は、複合Ｗｅｂサービス用サーバ装置２００とも通信を行い、複合Ｗｅｂサービス用サーバ装置２００の状態も管理している。
【００２４】
図２では、決済手段としてサービスＢ及びサービスＣの２種類が用意されており、決済手段が選択できるようになっている。具体的には、クレジットサービス決済（サービスＢ）又はオンラインバンキング決済（サービスＣ）が選択できるようになっているとする。すなわち、サービスＢ及びサービスＣは同位のサービス（タスク）であり、処理が並列的になっている。また、サービスＢとサービスＣを提供するサービス事業者は異なっているものとする。
ここで、図２において、クレジットサービスの障害が発生しているとする。
以下、この場合の管理手法（タスク管理方法）を上記の例に基づいて説明を進める。
【００２５】
図３は、本実施の形態に係るサービス管理用サーバ装置１００の構成例及びサービス管理用サーバ装置１００と管理対象のサービスとの関係を示す構成図である。
【００２６】
サービス管理用サーバ装置１００は、収集したい管理データに応じて、管理用のＳＯＡＰリクエストメッセージを、各サービスのマネージメントエンドポイント（ＭＥＰ：管理用ＳＯＡＰリクエストメッセージを送信するアドレス）にリクエスト（要求）する。すなわち、各サービスのサーバ装置（複合Ｗｅｂサービス用サーバ装置２００、プリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄ）に管理用ＳＯＡＰリクエストメッセージを送信する。
また、各サービスのサーバ装置２００、３００ａ〜３００ｄは、管理用ＳＯＡＰリクエストメッセージを受信した場合は内部の状態テーブル等を参照して要求された管理データを管理用ＳＯＡＰレスポンスメッセージとして応答する。
また、サービス管理用サーバ装置１００は、管理用ＳＯＡＰリクエストメッセージ及び管理用ＳＯＡＰレスポンスメッセージの送受信に代えて、各サーバ装置２００、３００ａ〜３００ｄが提供可能な管理情報の通知を受信する設定を事前に各サーバ装置２００、３００ａ〜３００ｄに設定しておくことで、各サーバ装置２００、３００ａ〜３００ｄから随時管理用通知メッセージを受信することもできる（図３の破線矢印）。つまり、管理用ＳＯＡＰリクエストメッセージとして管理情報の提供を要求することなく、各サーバ装置２００、３００ａ〜３００ｄから管理用ＳＯＡＰ通知メッセージとして管理情報を受信することができる。
【００２７】
なお、図３では、作図上の理由によりサービス管理用サーバ１００と複合Ｗｅｂサービス用サーバ装置２００の間のみ、管理用ＳＯＡＰリクエストメッセージ及び管理用ＳＯＡＰレスポンスメッセージとが明示されているが、サービス管理用サーバ装置１００と各サーバ装置３００ａ〜３００ｄの間の矢印のうち、一番上の矢印は、共通して管理用ＳＯＡＰリクエストメッセージを示しており、二番目の矢印は、共通して管理用ＳＯＡＰレスポンスメッセージを示している。
同様に、サービス管理用サーバ１００とプリミティブＷｅｂサービス用サーバ装置３００ｄの間のみ管理用ＳＯＡＰ通知メッセージとが明示されているが、サービス管理用サーバ装置１００と各サーバ装置２００、３００ａ〜３００ｃの間の矢印のうち、破線矢印は、共通して管理用ＳＯＡＰ通知メッセージを示している。
【００２８】
このような仕組みで、サービス管理用サーバ装置１００は、例えば各Ｗｅｂサービスの可用性情報、Ｗｅｂサービスの呼び出し回数（リクエスト回数）、呼び出されたＷｅｂサービスの成功、失敗回数、最大応答時間（最も応答が遅かった時間）、最新応答時間等の情報を収集する。
【００２９】
またＷｅｂサービスを管理する別の手法として、Ｗｅｂサービスの通信トラフィックのダミーデータ（図３のＷｅｂサービスリクエストメッセージ）を用意しておき、サービス管理用サーバ１００が、実際のクライアントマシンに成り代わって、このメッセージ（Ｗｅｂサービスリクエストメッセージ）を各サーバ装置２００、３００ａ〜３００ｃに送信し、各サーバ装置にＷｅｂサービスの実行を要求し、Ｗｅｂサービスリクエストメッセージに対するＷｅｂサービスレスポンスメッセージの応答状況、速度により障害、性能を検知、計測する手法もある。このような手法を利用しても良い。
【００３０】
以上のような方法により、サービス管理用サーバ装置１００は、個別のＷｅｂサービスの管理を行っているものとする。
【００３１】
また、複合Ｗｅｂサービス用サーバ２００は、ＢＰＥＬ等の定義ファイルに示されたタスクフローに従って、各プリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄの各Ｗｅｂサービスを呼び出して、図２に示したような複合Ｗｅｂサービス（サービスＸ）を実現する。
ＢＰＥＬはＸＭＬ形式のファイルでＷｅｂサービスの呼び出し依存関係（フロー依存関係）を定義しており、この定義に従ってＢＰＥＬサーバ（複合Ｗｅｂサービス用サーバ２００）がＷｅｂサービスを順次呼び出す。
【００３２】
本実施の形態では、後に詳述するように、サービス管理用サーバ装置１００において、複合Ｗｅｂサービスのタスクフローが定義されているＢＰＥＬ等の定義情報を解析して、複合Ｗｅｂサービス（複合タスク）を各々のプリミティブＷｅｂサービス（タスク）に分割するとともに、定義情報に示されたタスクフローにおいて条件分岐により並列関係（同位）にある二つ以上のＷｅｂサービスを同一のグループに分類し、タスクフローにおいて並列関係にないタスクをそれぞれ個別のグループに分類する。また、サービス管理用サーバ装置１００は、更に、定義情報に基づき、グループ間のフロー依存関係を解析する。更に、サービス管理用サーバ装置１００は、複数のプリミティブＷｅｂサービスを分類されたグループごとに区分して、システム管理者に対して表示し、また、グループ間のフロー依存関係を表示する。
【００３３】
このようなサービス管理用サーバ装置１００の機能を実現する手段として、図３に示した各要素がある。
【００３４】
ＳＯＡＰメッセージ解析部１０１は、各サーバ装置２００、３００ａ〜３００ｄからの管理用ＳＯＡＰレスポンスメッセージ又は管理用ＳＯＡＰ通知メッセージの内容を解析する。また、各サーバ装置２００、３００ａ〜３００にＷｅｂサービスリクエストメッセージが送信される場合は、ＳＯＡＰメッセージ解析部１０１は、各サーバ装置２００、３００ａ〜３００ｄからのＷｅｂサービスレスポンスメッセージの解析を行う。
【００３５】
定義ファイル記憶部１０２は、複合Ｗｅｂサービス用サーバ装置２００が用いるＢＰＥＬ等の定義ファイルを記憶している。
【００３６】
サービス構成解析部１０３は、定義ファイル記憶部１０２に記憶されている定義情報を解析して、複合Ｗｅｂサービスを各々のプリミティブＷｅｂサービスに分割するとともに、定義情報に示されたタスクフローにおいて条件分岐により並列関係（同位）にある二つ以上のＷｅｂサービスを同一のグループに分類し、タスクフローにおいて並列関係にないタスクをそれぞれ個別のグループに分類する。また、サービス構成解析部１０３は、更に、定義情報に基づき、グループ間のフロー依存関係を解析する。サービス構成解析部１０３は、タスク分割部及びタスクグループ解析部の例である。
【００３７】
エンドポイントリファレンス管理部１０４は、各サーバ装置２００、３００ａ〜３００ｄのマネージメントエンドポイント（ＭＥＰ：管理用ＳＯＡＰリクエストメッセージを送信するアドレス）を記憶している。
プリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄが提供するサービス（リモート呼び出し可能な機能）はＷＳＤＬ定義ファイルを用いて定義される。サービス利用者側は各サービスが公開するＷＳＤＬ定義ファイルを読み込み解析することで、どのようなサービスが（Ｗｓｄｌ：ＰｏｒｔＴｙｐｅ定義部）どこで提供されており（Ｗｓｄｌ：ｓｅｒｖｉｃｅ部）、どのようにアクセスすれば良いか（Ｗｓｄｌ：Ｂｉｎｄｉｎｇ定義部）を知ることができる。エンドポイントリファレンス管理部１０４はサービス用サーバ装置３００ａ〜３００ｄが公開するＷＳＤＬファイルを読み込み、まずサービスの種別と問い合わせ先等を管理する。
【００３８】
また、提供されているプリミティブＷｅｂサービスを管理するために、実サービスとは別に管理用のサービスが必要となる。一般的には図３の３００ａ〜３００ｄの各サーバ上に管理サービスが実装されると考えられるが、このような１対１の構成に限定されるわけではない。ここでは説明のため図３の構成を想定する。
先述の運用管理標準ＷＳＤＭでは、実サービスと当該実サービスの状態を管理するサービスの相関情報を得るために、＜ＧｅｔＭａｎａｇｅａｂｉｌｉｔｙＲｅｆｅｒｅｎｃｅｓ＞というメッセージを（元の実サービスに）送信し、その応答を得ることで管理サービスの情報を取得できるようにすることが考えられている。エンドポイントリファレンス管理部１０４は、実サービスと当該実サービスを管理するためのサービスとの対応付けを、当該メッセージを送信することにより取得し、取得した相関情報データを内部データベースに保存する。これにより管理すべきサービスとその管理状態を問い合わせる先のサービスがわかるため定期的にチェックする。
サービスのリポジトリへの登録・検索はＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）が標準化されている。エンドポイントリファレンス管理部１０４部はＵＤＤＩレジストリと同等の機能であるので、エンドポイントリファレンス管理部１０４は、ＵＤＤＩを一部拡張して実装してもよい。
【００３９】
サービス状態管理部１０５は、複合Ｗｅｂサービスに包含される各プリミティブＷｅｂサービスの状態を監視し、いずれかのプリミティブＷｅｂサービスにおける障害を検知する。サービス状態管理部１０５は、例えば、ＳＯＡＰメッセージ解析部１０１により解析された各サーバ装置２００、３００ａ〜３００ｄからの管理用ＳＯＡＰレスポンスメッセージ又は管理用ＳＯＡＰ通知メッセージの内容に基づいて、各プリミティブＷｅｂサービスの状態を監視することができる。サービス状態管理部１０５は、状態監視部の例である。
【００４０】
サービス性能管理部１０６は、複合Ｗｅｂサービスに包含される各プリミティブＷｅｂサービスの実行頻度又は実行性能を計測する。サービス性能管理部１０６は、例えば、Ｗｅｂサービスレスポンスメッセージにより各Ｗｅｂサービスの実行頻度、実行性能（応答速度等）を検知、計測することができる。サービス性能管理部１０６は、実行頻度計測部及び実行性能計測部の例である。
【００４１】
管理シナリオ実行部１０７は、各サーバ装置２００、３００ａ〜３００ｄに対する管理用ＳＯＡＰリクエストメッセージの送信手順、又は各サーバ装置２００、３００ａ〜３００ｄに対するＷｅｂサービスリクエストメッセージの送信手順が示された管理シナリオに従って、各サーバ装置２００、３００ａ〜３００ｄに対する管理用ＳＯＡＰリクエストメッセージを生成し、又は各サーバ装置２００、３００ａ〜３００に対するＷｅｂサービスリクエストメッセージを生成し、通信部１１１からこれらリクエストメッセージを送信させ、管理シナリオを実行する。
【００４２】
画面表示部１０８は、サービス構成解析部１０３により分割された複数のプリミティブＷｅｂサービス（タスク）をサービス構成解析部１０３により分類されたタスクグループごとに区分して管理者に対して表示する。また、グループ間のフロー依存関係も表示する。
また、画面表示部１０８は、サービス状態管理部１０５により障害が検知された場合に、対象となるＷｅｂサービスを明示して当該Ｗｅｂサービスに障害が発生した旨を表示し、更に、サービス性能管理部１０６により計測された各タスクの実行頻度又は実行性能を表示する。
【００４３】
内部データベース１０９は、サービス管理用サーバ装置１００で用いられる各種情報を格納しており、例えば、サービス状態管理部１０５が監視している各Ｗｅｂサービスの状態の履歴や、サービス性能管理部１０６が監視している各Ｗｅｂサービスの性能の履歴や、管理シナリオ実行部１０７が用いる管理シナリオ等の情報を格納する。
【００４４】
制御部１１０は、サービス管理用サーバ装置１００の各要素の制御を行う。
【００４５】
通信部１１１は、管理用ＳＯＡＰリクエストメッセージ又はＷｅｂサービスリクエストメッセージを各サーバ装置２００、３００ａ〜３００に送信し、各サーバ装置２００、３００ａ〜３００から管理用ＳＯＡＰレスポンスメッセージ又は管理用ＳＯＡＰ通知メッセージ、もしくはＷｅｂサービスレスポンスメッセージを受信する。
【００４６】
次に、サービス管理用サーバ装置１００、複合Ｗｅｂサービス用サーバ装置２００、プリミティブＷｅｂサービス用サーバ装置３００及びクライアント端末装置４００のハードウェア構成例について説明する。
図９は、本実施の形態及び以下に述べる実施の形態に示すサービス管理用サーバ装置１００、複合Ｗｅｂサービス用サーバ装置２００、プリミティブＷｅｂサービス用サーバ装置３００及びクライアント端末装置４００のハードウェア資源の一例を示す図である。
図９において、サービス管理用サーバ装置１００、複合Ｗｅｂサービス用サーバ装置２００、プリミティブＷｅｂサービス用サーバ装置３００及びクライアント端末装置４００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。
【００４７】
通信ボード９１５は、図１に示すように、インターネット５００に接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【００４８】
上記プログラム群９２３には、本実施の形態及び以下に述べる実施の形態の説明において「〜部」、「〜手段」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、以下に述べる説明において、「〜の判定結果」、「〜の計算結果」、「〜の処理結果」、「〜の評価結果」等として説明している情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、以下で説明するフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００４９】
また、本実施の形態及び以下に述べる実施の形態の説明において「〜部」、「〜手段」として説明しているものは、「〜回路」、「〜装置」、「〜機器」、「手段」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」、「〜手段」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、本実施の形態及び以下に述べる実施の形態の「〜部」、「〜手段」としてコンピュータを機能させるものである。あるいは、本実施の形態及び以下に述べる実施の形態の「〜部」、「〜手段」の手順や方法をコンピュータに実行させるものである。
【００５０】
このように、本実施の形態及び以下に述べる実施の形態に示すサービス管理用サーバ装置１００、複合Ｗｅｂサービス用サーバ装置２００、プリミティブＷｅｂサービス用サーバ装置３００及びクライアント端末装置４００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」、「〜手段」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【００５１】
次に、複合Ｗｅｂサービスの管理、特に、サービス構成解析部１０３による管理について説明する。
サービス構成解析部１０３による管理を説明する前に、まず、前提となる事項を説明する。
複合Ｗｅｂサービスを管理するためにはサービス間の依存関係を管理する必要がでてくる。このような管理の類似例としてアプリケーション管理の手法がある。このアプリケーション管理では、複数のアプリケーションを包含関係（親子関係）として管理する。
図４は、従来のアプリケーション管理における監視画面の表示例を示している。図４では、例えば、親ノード（アプリケーションＸ）を構成する子ノードとして、サーバＡ、サーバＢ、サーバＣ、サーバＤが表示され、また、一部の子ノードであるサーバＢに障害が発生した場合、以下に説明するように、子ノードの障害に基づく伝搬係数が一定の閾値を越えた場合は、アプリケーションＸ全体の障害（部分障害）として表示され、アプリケーションＸが全体として利用不可能と把握される。
【００５２】
図４に示すような従来の包含関係のモデルでは、子ノードの障害を親ノードに伝搬させることになる。子ノードの障害を親ノードに伝搬させる際には、一定の伝搬係数（０≦φ≦１）をかけて伝達する。伝搬係数の決め方は色々あるが、例えばノードの重要度を考慮にいれ事前に係数を定義ファイルに定義しておき、その値を参照する方法が考えられる。親ノードでは発火した子ノード（障害）とその伝搬係数をかけたものの総和を求め、それを親ノード発火閾値（アプリケーション障害閾値）と比較し、障害重要度を表示することが考えられる。
つまり、アプリケーション障害度数＝（子ノード障害度数＊（伝搬計数）φ）の総和となる。
また、アプリケーションＸが障害が否かの判断は、以下のようになる。
ｉｆ（アプリケーション障害度数≧アプリケーション障害閾値）｛障害｝
ｅｌｓｅ｛ＮＯＴ障害｝
【００５３】
上記の従前の方法では、親ノードと子ノードの関係は、管理用に独自のＸＭＬ形式の定義ファイルを決め、それに従って管理用のモデルを定義していることが多い。
【００５４】
これを、図３のような複合Ｗｅｂサービスの管理にあてはめると、連携を定義したシステムの定義と、管理用のモデル定義を別々に作成することになるため、定義ファイル間の不整合を起こしやすいという問題が出てくる。
【００５５】
本実施では、管理用の内部構成関係モデルを構築する際の定義ファイルとして、システムやアプリケーション用の定義ファイルそのまま利用ことで解決する。
このような例の最適例は、複合ＷｅｂサービスをＢＰＥＬに従って定義している場合である。ＢＰＥＬはＸＭＬ形式のファイルでＷｅｂサービスの呼び出し依存関係（フロー依存関係）を定義しており、この定義に従ってＢＰＥＬサーバ（複合Ｗｅｂサービス用サーバ２００）がＷｅｂサービスを順次呼び出す。
ＢＰＥＬ定義ファイルをそのままサービス管理用サーバ１００のサービス構成解析部１０３で解析し、サービス間の包含関係を構築することにすれば、アプリケーション（複合Ｗｅｂサービス用サーバ２００）と管理装置（サービス管理用サーバ１００）が参照する定義ファイルが同一になるため実システム（複合Ｗｅｂサービス用サーバ２００）と管理システム（サービス管理用サーバ１００）内の構成モデルが不整合を起こすことがなくなるという有意な効果がある（図５）。
【００５６】
ＢＰＥＬ定義を使った包含関係の解析はＢＰＥＬ定義の＜ｐａｒｔｎｅｒＬｉｎｋｓ＞部を解析することでわかる。
【００５７】
ただし、包含関係分析のみであると、コンポジットサービスの一部に障害があり部分障害があるという以上のことはわからず、影響範囲の把握にあいまいさが残ってしまうという問題がある。
そこで、本実施の形態におけるサービス管理用サーバ１００のサービス構成解析部１０３では個々のＷｅｂサービスをタスクノードとし、タスクフロー解析を行う。フロー解析の結果、タスク分割を行い同位のタスクはタスクグループに統合して複合Ｗｅｂサービスを管理する。ここで、同位のタスクとは、後述するように条件分岐により並列関係にある二つ以上のタスク（Ｗｅｂサービス）を意味する。
【００５８】
サービス構成解析部１０３におけるフロー解析は主としてＢＰＥＬ定義の＜ｓｅｑｕｅｎｃｅ＞部、＜ｆｌｏｗ＞部、＜ｓｗｉｔｃｈ＞部の解析を行うことにより行う。
ＢＰＥＬにおいて、＜ｓｅｑｕｅｎｃｅ＞部は順列実行するブロック定義部である。サービス構成解析部１０３は、この部分を順次読み出し、解析することにより、サービスの呼び出し順に管理することができる。
また、＜ｓｗｉｔｃｈ＞部は条件分岐を実行するブロック定義部である。サービス構成解析部１０３は、この部分を解析することにより、条件によって分岐することを管理することができる。
また、＜ｆｌｏｗ＞部は並列実行するブロック定義部である。サービス構成解析部１０３は、この部分を解析することにより、サービスが並列実行されることを内部的に管理することができる。
また、＜ｗｈｉｌｅ＞部は条件ループを実行するブロック定義部である。サービス構成解析部１０３は、この部分を解析することにより、サービスが繰り返し実行されることを内部的に管理することができる。
【００５９】
サービス構成解析部１０３によるＢＰＥＬ定義ファイルの解析の結果、図２のフローをタスクフロー解析した例が図５である。
ＢＰＥＬ定義ファイルに図２のフローが定義されているとすると、条件分岐部分で分岐した各ノードは同位であるので１つにまとめ、群（１）（サービスＡ）、群（２）（サービスＢ及びＣ）、群（３）（サービスＤ）に自動的に分離して構成管理し、また監視画面上に表示する。
群（２）は条件分岐であるので、あるトランザクションに着目するとどちらか一方のみの処理が利用される関係になる。
このように管理するとタスクフロー上どこに障害があるかが把握しやすくなり、単に包含関係を管理するよりも障害の切り分けがやりやすくなるというメリットがある。
【００６０】
つまり、図５のような管理画面を表示すれば、サービスＡ〜ＤがサービスＸに包含されることに加えて、各タスクグループが他のどのタスクグループと依存関係にあるかというフロー依存関係、すなわち、順次タスクグループ毎に処理が実行されること、および、このケースの場合銀行決済（サービスＣ）を行うユーザには影響がないことがサービス管理用サーバ１００において容易に把握できるようになる、という有意な効果がある。
また、図５のようなタスクグループ分解を行った後に、タスクグループ毎に管理しやすい名前を設けることでさらに管理性が高まる。タスクグループの名称は、例えば、ＢＰＥＬ定義において、コメントとして記述されている各々のタスクグループの名称をサービス構成解析部１０３が抽出することで、各タスクグループに付加することができる。
また、監視画面は図２のようにフロー形式に表示することも可能である。
【００６１】
また、図５のようなタスクフロー分析を行った管理データ・管理画面に、上述したサービス状態管理部１０５又はサービス性能管理部１０６が収集・管理しているＷｅｂサービスの利用・性能管理情報（Ｗｅｂサービスの可用性やＷｅｂサービスが呼び出された回数（実行頻度）、そのうちの成功、失敗回数、最大遅延応答時間（最も応答に時間がかかった処理）、最新遅延応答時間、サービスの継続時間（起動からの時間）等）を重ねて表示することもできる（図６）。
このようにするとサービスＢ（クレジット決済）を利用するユーザに影響が及ぶというのみならず、サービスの実行頻度（決済処理におけるサービスＢの選択率履歴）が３０％であり、この結果、サービスＢの障害の影響度が３０％程度であるということが定量的かつリアルタイムに判断することができるので有意である。
【００６２】
ここで、本実施の形態に係るタスクフロー（サービスフロー）解析の詳細を説明する。
サービスフローの依存関係を分析するための例として、ＢＰＥＬ４ＷＳ  ｖ．１．１仕様を例に説明する。なお本発明はＢＰＥＬに限定したものではなく、同等のフロー定義構造をもっていれば適用可能である。例えば対話型ワークフロー制御用定義言語のＸＰＤＬ（ＸＭＬ  ＰＲＯＣＥＳＳ  ＤＥＦＩＮＩＴＩＯＮ  ＬＡＮＧＵＡＧＥ）などや独自のタグ定義も考えられるであろう。
【００６３】
ＢＰＥＬでは基本アクティビティとして、
＜ｉｎｖｏｋｅ＞，＜ｒｅｃｅｉｖｅ＞，＜ｒｅｐｌｙ＞，＜ａｓｓｉｇｎ＞，＜ｔｈｒｏｗ＞，＜ｗａｉｔ＞
等のタグが定義されている。
主な基本アクティビティのタグ概略を説明すると以下の通りである。
＜ｒｅｃｅｉｖｅ＞はメッセージの受信待ちアクティビティである。指定のポートタイプとオペレーションを示すメッセージが到着するまでまつ。複合Ｗｅｂサービスではメッセージ受信をトリガーに処理が始まるためである。
＜ｉｎｖｏｋｅ＞はパートナーＷｅｂサービスポートタイプのオペレーションを呼び出すアクティビティである。すなわち、このタグ内で定義されたプリミティブサービスを呼び出す。
＜ｒｅｐｌｙ＞は＜ｒｅｃｅｉｖｅ＞アクティビティで受信したメッセージに対する返答メッセージを返送するアクティビティである。＜ｒｅｃｅｉｖｅ＞と＜ｒｅｐｌｙ＞の組み合わせでリクエスト／レスポンス型のオペレーションを形成する。
＜ｔｈｒｏｗ＞は例外発生を通知するアクティビティである。
＜ｔｅｒｍｉｎａｔｅ＞はプロセスを終了するアクティビティ（異常終了となる）である。実行可能プロセスでのみ利用可能である。
【００６４】
また、ＢＥＰＬでは構造化アクティビティ定義（ブロック定義）を行うためのＸＭＬのタグが決められている。主な構造化タグは以下の通りである。
＜ｓｅｑｕｅｎｃｅ＞タグは順列実行、すなわち順番に実行するブロックを定義するためのタグであり、＜ｓｅｑｕｅｎｃｅ＞＜／ｓｅｑｕｅｎｃｅ＞で囲まれる部分に記述された処理を順次実行する。
＜ｓｗｉｔｃｈ＞タグは条件分岐を実行するブロック定義であり、Ｊａｖａ（登録商標）言語などにおけるｓｗｉｔｃｈ〜ｃａｓｅ文と同様の処理を実現する。
＜ｆｌｏｗ＞タグは並列実行するブロック定義である。
＜ｓｃｏｐｅ＞タグは複数のアクティビティをまとめてスコープ（範囲）を形成するブロック定義である。スコープにはローカル変数や例外ハンドラなどの各種ハンドラを定義することができる。
＜ｗｈｉｌｅ＞タグは条件ループを実行するブロック定義である。Ｊａｖａ（登録商標）言語におけるｗｈｉｌｅ文と同様の処理を実現する。
【００６５】
図１１は図３のサービス構成解析部１０３にて行う、複合Ｗｅｂサービス解析の概要を示す図である。新しい複合Ｗｅｂサービスが定義されたとき、または既存の複合Ｗｅｂサービスの構成に変化があったときにサービス定義ファイルを入力として複合Ｗｅｂサービス構造の解析を行う。
具体的な実装手段としてはＪＡＶＡ（登録商標）言語等のコンピュータ言語用のＸＰＡＴＨ（ＸＭＬ  Ｐａｔｈ  Ｌａｎｇｕａｇｅ）ライブラリ、ＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）ライブラリ等を使ってＸＭＬタグによるタスク定義の解析を行う。また、ＸＳＬＴ（ＸＳＬ  Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ）プロセッサも利用することができる。以下、処理例を示す。ここでは説明の都合上、基本的なＸＭＬタグ定義を使って説明するがこれに限定されるものではない。
まず、対象となるコンポジットサービスのＢＰＥＬ定義をＸＳＬＴプロセッサで読み込み、管理用のフロー構造木生成には不要なＢＰＥＬ定義を削除する処理を行う（Ｓ１１０１）。たとえば、コメント用のタグやその他のフロー解析には関係の無いタグである。この処理はＤＯＭライブラリを使ったプログラムを作成することもできる。
次にタスク分割処理、すなわち処理タスクの単位となる要素の検出処理を行う。これは原則的にはＢＰＥＬ基本アクティビティタグ定義を検出し、管理対象とすべきかどうか（コンポジットサービスの管理用構成ツリーに含めるかどうか）を検査する。基本的な処理としては、当該基本アクティビティタグに管理対象として定義されているプリミティブＷｅｂサービスの呼び出しが含まれているか（最も一般的には＜ＩＮＶＯＫＥ＞タグによってＷＥＢサービスが呼び出される）を検査し、（図３の定義ファイル記憶部１０２において）管理対象に含める定義がされていればコンポジットサービスの管理用構成ツリー要素として含める（Ｓ１１０２）。他に複合ＷＥＢサービスの開始点（＜ＲＥＣＩＥＶＥ＞タグ）や終了点（＜ＲＥＰＬＹ＞タグ）なども管理用構成ツリーの要素として含める。
また、同時にタスクグループ解析処理、すなわちタスク単位の依存関係検出処理を行う（Ｓ１１０２）。これは原則的にはＢＰＥＬの構造化タグを検出し、タスク間の依存関係を解析する。例えば、構造化タグの＜ＳＷＩＴＣＨ＞タグは処理の分岐を示すタグでありこの中でＷＥＢサービスが呼び出されていれば、いずれか１のＷＥＢサービスが正常に動作していれば、複合ＷＥＢサービス全体としては、サービスの一部継続性が確保されている関係が成立する。
タスク分割処理とタスクグループ解析処理は、例えばＢＰＥＬのフロー定義をツリー解析することにより行うがこの場合２つの処理は管理用構成ツリーの生成処理中に同時に処理されることになる（Ｓ１１０２）。ＸＭＬのツリー構造解析は先に説明したＤＯＭライブラリを利用して処理することができるため、ＤＯＭライブラリを使って複合ＷＥＢサービスの管理に適したフロー構造解析木を生成する。ＢＰＥＬ定義からフロー構造解析を行った例が図１２である。
ＢＰＥＬ定義を使ったフロー構造解析結果は図３の内部ＤＢ１０９のフロー構造ＤＢに保存する（Ｓ１１０３）。構成の保存は複合サービス単位（定義のバージョン毎）に行う。
【００６６】
図１２はＢＰＥＬ定義を入力として、図３のサービス構成解析部１０３で複合サービスの解析を行い、内部ＤＢ１０９に保存された管理用フロー構造ツリーの例を概念的に表した図である。
フロー構造ツリーは単なる包含ツリーではなく、フロー上のノード位置によって先後があり、ツリーの左方ほど複合Ｗｅｂサービスのサービスフローの先頭に近いノードになる。
【００６７】
また、図３のサービス状態管理部１０５は次のように動作する。これを図１３のフローにより説明する。また、図１４は図１２のフロー構造解析結果例をつかって、図１３の処理がどのように処理されるかを示す概要図である。
サービス状態管理部１０５は事前に図３の定義ファイル記憶部１０２の内容により、管理対象のプリミティブＷｅｂサービスを指定された周期で、プリミティブサービス状態確認用の管理ＡＰＩにより確認する。管理ＡＰＩによる応答により管理対象のプリミティブサービスが障害であることを検出する（Ｓ１３０１）。また、プリミティブサービスの障害検出はプリミティブＷｅｂサービス管理用のサーバ装置からの管理用の通知メッセージにより検出することもある（Ｓ１３０１）。サービス状態管理部１０５がプリミティブサービスの障害を検出すると、複合ＷＥＢサービス全体の障害ステータスを求めるためにステータスの集約処理を行う。
【００６８】
複合Ｗｅｂサービスの状態集約処理は、内部ＤＢ内に保存された管理フロー構成ツリーＤＢのツリー内に該プリミティブサービスが含まれていないかどうかを検索し（Ｓ１３０２）、プリミティブサービスを含む複合Ｗｅｂサービスのフロー構成ツリーを抽出する（対象複合Ｗｅｂサービスのポインター群が抽出される）（Ｓ１３０２）。
抽出された複合Ｗｅｂサービスについて、複合Ｗｅｂサービス全体としての状態を決めるためにステータス集約操作を行う。このため、操作対象とする１つの複合Ｗｅｂサービスを順次取り出す（Ｓ１３０３）。
取り出した操作対象の複合Ｗｅｂサービスの管理用フローノードツリー（図１２）中のどこに該プリミティブサービス（障害中）が位置するかを特定する（Ｓ１３０４）。例えば、前述のＸＰＡＴＨ，ＤＯＭ等のライブラリを使うことにより当業者なら比較的容易に実装することが可能である。
まず、図１２において、障害プリミティブサービスを起点に障害状態を上方へ集約伝搬する操作を行う（Ｓ１３０５）。障害ノードであるカレントノードの親ノードを取得する。親ノードと子ノードが１対１であれば、子ノードの状態をそのまま伝搬する。親ノードからみて子ノードが複数であれば（図１２の＜Ｓｗｉｔｃｈ＞ノード）、親ノードに部分障害として集約状態を保存し、さらに、当該障害プリミティブノードが障害である旨、及び（このケースであれば）兄弟ノードについては正常（ｕｐ）である旨を保存し集約する。なお、ＢＰＥＬにおいては、複数の子ノードを持てるが、子ノードは先述の構造化アクティビティ定義タグを使って階層的な定義をすることで生成できる。図１２の例のように、構造化タグのうち分岐条件（例＜ｓｗｉｔｃｈ＞タグ）を示すノードがあると分岐がおこりえるが、分岐条件がＯＲ条件か、ＡＮＤ条件か等の情報も、この情報状態集約操作で付加する。特にＯＲ条件の場合は選択条件も集約する。
【００６９】
フロー最上位層（図１２の点線で囲んだ部分）まで状態の情報集約が進んだ場合は、そこで情報上方への状態伝搬操作は終了する。また、集約ステータス上方伝搬操作終了前に、当該最上位ノードのサブツリー部分に存在する個別のプリミティブサービスの状態も付加してもよい。
【００７０】
次に複合Ｗｅｂサービスのフロー前方に向かって、さらに状態伝搬操作を行う（Ｓ１３０６）。まず、操作対象のノードの前方ノードを取得する。カレントノードの集約状態を前方に伝搬させるにあたっては、集約ステータスは前方ノードの集約ステータスとカレントノードの集約ステータスを比較して悪い状態の方を伝搬させるのが一般的（デフォルト）であるが、伝搬のさせかたは外部定義で変えられるようにしてもよい。例えば、カレントノードの集約状態が部分障害、前方ノードの集約状態が正常であれば、部分障害の方が状態が悪いのでこちらが集約状態ステータスとして伝搬するのが通常である。また、集約ステータスを前方に伝搬させる際に、個別のプリミティブサービスの状態も付加してもよい。
【００７１】
前方に状態が伝搬したら、次は前方ノードをカレントノードとし、さらに一つ前のノードと比較する。このようにサービスの開始ノード（図の「サービスエントリ」（＜ＲＥＣＥＩＶＥ＞）に到達するまで、ステータスの前方伝搬操作を繰り返す。複合サービスのエントリポイントノードまで到達した場合は当該コンポジットサービスについてのステータス集約伝搬操作を終了する。
図１５は、複合Ｗｅｂサービス（Ｂｏｏｋ＿ｓｅｌｌｅｒ）のステータスを集約した結果の一例である。ここで用いているＸＭＬタグは説明のための便宜的なものであり、別のタグ定義により同様の手法を実現することは可能である。
ステータス集約操作の最後に、最終的な集約状態を（集約状態と個別のプリミティブサービスの状態）図３の内部ＤＢ１０９中にある障害ＤＢ領域に保存するとともに、フロー構成を表示する管理画面（図２のサービス管理画面）に反映する（Ｓ１３０７）。
当該複合サービスについての障害状態集約操作が終了した後は、他に対象となる複合Ｗｅｂサービスがあれば（Ｓ１３０８）同様の操作を繰り返し（Ｓ１３０９）、対象の複合Ｗｅｂサービスがなくなるまでこの操作を繰り返す（Ｓ１３０８）。
【００７２】
以上のように、本実施の形態に係る通信システムでは、Ｗｅｂサービスを監視する手段と、コンポジットＷｅｂサービスの監視において、階層化された個々のサービスの状態を集約計算して表示・監視する手段と、コンポジットＷｅｂサービスの監視において、コンポジットＷｅｂサービスの構成を定義ファイルを読み込み、サービスの階層構成を管理する手段とを備えている。
コンポジットサービスはＢＰＥＬに沿った標準形式で記述するのが一般的になりつつあるが、本実施の形態に係る通信システムでは、ＢＰＥＬで定義されたビジネスフロー定義ファイルをそのまま流用し、フロー依存関係のあるサービスを監視する画面を生成でき、監視用に新たな定義が必要がないというとう点が有利な効果である。ＢＰＥＬはＸＭＬ形式の定義であるため、障害伝搬係数定義のみを別のＸＭＬファイルに付加的に定義し、当該ＢＰＥＬサービス定義ファイルとＸＭＬ合成すると、定義が簡易化され管理が正確かつ容易になるという有意な効果がある。
【００７３】
また、本実施の形態に係る通信システムは、コンポジットＷｅｂサービスのフロー定義を読み込み、フローグループ毎にＷｅｂサービスを管理する手段を有する。
ビジネスフローを解析し、ビジネスフロー単位にグループ化し監視画面上に表示すると、どのビジネスフロー単位に障害があるかが画面上明らかになるため有意である。すなわち複数の決済手段から１つを選択して決済処理を行うような処理が分岐し分岐選択処理のビジネスフロー単位であることがわかると、決済手段サービスの１つに障害があっても、処理が全面に停止するわけではなく、影響度は当該決済手段を選択するユーザにのみ及ぶ。
このような並列化されたビジネスフロー単位が含まれる場合、予めビジネスフローを解析し、各ビジネスフロー単位で監視することができれば、障害時の影響度（範囲）をより把握しやすくなる。
さらに障害のないフロー（上記の例では、銀行決済）を行うユーザには影響がないことが容易に把握できるようになる、という有意な効果がある。
【００７４】
また、本実施の形態に係る通信ステムは、Ｗｅｂサービスの障害情報と品質（統計情報）監視し、これらを監視画面に同時に表示することで障害時の影響度を表示する手段を有する。
ビジネスフローを解析した画面に、過去の利用率情報や性能管理情報を表示することで障害の影響度を把握することができる、という有意な効果がある。図６の例の場合、３０％のユーザに影響があるなどである。
【００７５】
以上、本実施の形態では、複数のタスクを包含する複合タスクのタスクフローが定義されている定義情報を解析して、複合タスクを各々のタスクに分割するタスク分割部と、前記定義情報に定義されているタスクフローにおいて同位にある二つ以上のタスクを同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて同位にないタスクをそれぞれ個別のタスクグループに分類して、前記複合タスクに包含される複数のタスクを二以上のタスクグループに分類するタスクグループ解析部とを有する管理装置（サービス管理用サーバ装置）について説明した。
【００７６】
また、本実施の形態において、前記タスクグループ解析部は、前記定義情報に定義されているタスクフローにおいて条件分岐により並列関係にある二つ以上のタスクを同位にあるタスクとして同一のタスクグループに分類し、前記定義情報に定義されているタスクフローにおいて並列関係にないタスクをそれぞれ個別のタスクグループに分類することを説明した。
【００７７】
また、前記タスクグループ解析部が、前記定義情報に基づき、タスクグループ間のフロー依存関係を解析することを説明した。
【００７８】
また、管理装置（サービス管理用サーバ装置）は、更に、前記タスク分割部により分割された複数のタスクを前記タスクグループ解析部により分類されたタスクグループごとに区分して表示する表示部を有することを説明した。
【００７９】
また、管理装置（サービス管理用サーバ装置）は、更に、前記タスク分割部により分割された複数のタスクを前記タスクグループ解析部により分類されたタスクグループごとに区分して表示するとともに、前記タスクグループ解析部により解析されたタスクグループ間のフロー依存関係を表示する表示部を有することを説明した。
【００８０】
また、前記タスクグループ解析部が、各タスクが実現する機能及び各タスクグループが実現する機能の少なくともいずれかを解析し、前記表示部が、前記タスクグループ解析部により解析された各タスクが実現する機能及び各タスクグループが実現する機能の少なくともいずれかを表示することを説明した。
【００８１】
また、管理装置（サービス管理用サーバ装置）は、更に、複合タスクに包含される各タスクの状態を監視し、いずれかのタスクにおける障害を検知する状態監視部を有し、前記表示部が、前記状態監視部により障害が検知された場合に、対象となるタスクを明示して当該タスクに障害が発生した旨を表示することを説明した。
【００８２】
また、管理装置（サービス管理用サーバ装置）は、更に、複合タスクに包含される各タスクの実行頻度を計測する実行頻度計測部を有し、前記表示部が、前記実行頻度計測部により計測された各タスクの実行頻度を表示することを説明した。
【００８３】
また、管理装置（サービス管理用サーバ装置）は、更に、複合タスクに包含される各タスクの実行性能を計測する実行性能計測部を有し、前記表示部が、前記実行性能計測部により計測された各タスクの実行性能を表示することを説明した。
【００８４】
また、前記タスク分割部が、複数のＷｅｂサービスを包含する複合Ｗｅｂサービスを、前記複合Ｗｅｂサービスのタスクフローが定義されているＢＰＥＬ４ＷＳ（Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ  ｆｏｒ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ）による定義情報を解析して、各々のＷｅｂサービスに分割し、前記タスクグループ解析部が、前記ＢＰＥＬ４ＷＳによる定義情報に定義されているタスクフローにおいて同位にある二つ以上のＷｅｂサービスを同一のタスクグループに分類し、前記ＢＰＥＬ４ＷＳによる定義情報に定義されているタスクフローにおいて同位にないＷｅｂサービスをそれぞれ個別のタスクグループに分類して、前記複合Ｗｅｂサービスに包含される複数のＷｅｂサービスを二以上のタスクグループに分類することを説明した。
【００８５】
実施の形態２．
図７は、本実施の形態に係るシステム構成の概要を示す。
図７では、サービス管理用サーバ装置１００が収集した管理情報をシステム管理者に向けて表示するのではなく、管理情報を自動的に直接、複合Ｗｅｂサービスアプリケーション利用者の端末（クライアント端末４００）に表示する構成の概要を示している。
【００８６】
従来、運用管理システムで収集した管理情報はシステム管理者のためのものと考えられていたが、このように必要な管理情報を直接アプリケーション利用者に提示することができると、障害時における無駄な操作の抑止や性能データを参照した利用ができ、システム管理者とっても、利用者にとっても有意である。
【００８７】
利用者のクライアント端末装置４００の表示画面に表示させるための画面情報を作成するサーバ（図７では複合Ｗｅｂサービス用サーバ装置２００）が、サービス管理用サーバ装置１００が公開する（アプリケーション用）管理情報提供Ｗｅｂサービスにアクセスし、必要な情報を取得し、クライアント端末装置４００への画面情報を生成し、クライアント端末装置４００に送信する。クライアント端末装置４００では、複合Ｗｅｂサービス用サーバ装置２００からの画面情報を受信し、これを表示する。
なお、複合Ｗｅｂサービス用サーバ装置２００が直接サービスＡ〜Ｄを提供するプリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄの管理情報提供Ｗｅｂサービスにアクセスしても良いが、一般にはサービス管理用サーバ装置１００にアクセスするのが良い。
複合Ｗｅｂサービス用サーバ装置２００とサービス管理用サーバ装置１００は、図３に示すように、同じＢＰＥＬ定義ファイルをもとに、サービスフローを解析している。従って、複合Ｗｅｂサービス用サーバ装置２００では利用者のクライアント端末装置４００に次の画面に表示するＷｅｂサービスを知ることができるが、同じようにサービス管理用サーバ装置１００もフローベースでサービスを管理しているので、複合Ｗｅｂサービス用サーバ装置２００からの問い合わせに応じてサービスの状態や利用率・性能情報の適切に応答すること容易だからである。
【００８８】
図８は、本実施の形態に係るサービス管理用サーバ装置１００の構成例及び、サービス管理用サーバ装置１００と各サーバ装置２００、３００ａ〜３００ｄとの関係を示す。
図８において、サービス管理用サーバ装置１００に管理情報公開インタフェース１１２が追加されている以外は、図２と同様である。
管理情報公開インタフェース１１２は、複合Ｗｅｂサービス用サーバ装置２００に対して管理情報提供Ｗｅｂサービスを提供するインタフェースである。
管理情報公開インタフェース１１２は、通信情報生成部の例である。
【００８９】
本実施の形態では、実施の形態１と同様に、サービス状態管理部１０５（状態監視部）が複合Ｗｅｂサービス（複合タスク）の各Ｗｅｂサービス（タスク）の状態を監視する。
また、本実施の形態では、サービス状態管理部１０５は、クライアント端末装置４００（端末装置）により実行が選択される可能性のあるＷｅｂサービス（選択可能性タスク）が複合Ｗｅｂサービス用サーバ装置２００（サーバ装置）から通知され、通知されたＷｅｂサービス（選択可能性タスク）に障害が発生しているか否かを検知する。
管理情報公開インタフェース１１２（通知情報生成部）は、サービス状態管理部１０５によりＷｅｂサービス（選択可能性タスク）における障害が検知された場合に、障害が検知された障害Ｗｅｂサービス（障害タスク）をクライアント端末装置４００に通知するための情報（障害通知情報）を生成する。
そして、通信部１１１（送信部）が、管理情報公開インタフェース１１２により生成された情報（障害通知情報）を複合Ｗｅｂサービス用サーバ装置２００に送信する。
また、管理情報公開インタフェース１１２は、サービス状態管理部１０５により障害が検知された障害Ｗｅｂサービスとタスクフローにおいて並列関係にある他のＷｅｂサービスが存在する場合に、障害Ｗｅｂサービスの代替として前記他のＷｅｂサービスをクライアント端末装置４００に通知するための情報を生成するようにしてもよい。
【００９０】
また、サービス性能管理部１０６（実行性能計測部）が、実施の形態１と同様に、複合Ｗｅｂサービスに包含される各Ｗｅｂサービスの実行性能を計測し、管理情報公開インタフェース１１２が、サービス性能管理部１０６により計測された各Ｗｅｂサービスの実行性能をクライアント端末装置４００に通知するための情報（実行性能通知情報）を生成し、通信部１１１が、管理情報公開インタフェース１１２により生成された情報（実行性能通知情報）を複合Ｗｅｂサービス用サーバ装置２００に送信するようにしてもよい。
【００９１】
クライアント端末装置４００の画面へのサービス管理情報の表示例の最も簡単な例を図６及び図７を利用して説明する。
図７において、複合Ｗｅｂサービス用サーバ装置２００から、商品選択後の決済手段を選択するための画面情報を送信し、クライアント端末装置４００において当該決済手段の選択のための画面を表示する場合を考える。
（１）複合Ｗｅｂサービス用サーバ装置２００はＢＰＥＬ（またはその他のワークフロー定義）の定義ファイルの解析によって、商品選択後、次に決済手段選択画面の表示が行われることを認識する。
（２）複合Ｗｅｂサービス用サーバ装置２００は、サービス管理用サーバ装置１００の管理情報提供Ｗｅｂサービスに次の画面で使うサービス（決済サービス）のサービス稼働状況を問い合わせる。
（３）サービス管理用サーバ装置１００では、サービス状態管理部１０５が、内部のステータス管理ＤＢから（または決済サービスであるサービスＢ、Ｃを提供するプリミティブＷｅｂサービス用サーバ装置３００ｂ、３００ｃから直接）ステータス管理情報を収集し、サービスＢ（クレジットサービス）が障害中であることを判定し、管理情報公開インタフェース１１２が、サービスＢが障害中であることを通知する情報を生成し、通信部１１１がこの情報を複合Ｗｅｂサービス用サーバ装置２００に送信する。ここで、ステータス管理ＤＢとは、図３に示した内部データベース１０９の一部であり、管理用ＳＯＡＰリクエストメッセージ又は管理用ＳＯＡＰ通知メッセージの収集により得られる各プリミティブＷｅｂサービス用サーバ装置３００ａ〜３００ｄの状態を記録するためのデータベースである。
（４）複合Ｗｅｂサービス用サーバ装置２００は、サービス管理用サーバ装置１００からの応答によりサービスＢが障害中であることを知り、クライアント端末装置４００へのアプリケーション画面情報のインフォメーションフレームにクレジットサービス（サービスＢ）が障害中であることを表示したり、クレジット決済のラジオボタンをグレイアウトして選択できないような画面情報を生成することができる。
【００９２】
図１６を利用して、実施の形態２についてのサービス管理用サーバ装置１００の動作を説明する。
サービス管理用サーバ装置１００は、前述の通り各プリミティブＷｅｂサービスについての状態を周期的に確認し（状態監視ステップ）、内部ＤＢ１０９に保存している。また、各複合Ｗｅｂサービスの状態を集約して保存している。
サービス管理用サーバ装置１００は管理情報公開Ｉ／Ｆ１１２を介して、これらの情報を他のサーバに公開している。以下のように処理する。
管理情報公開Ｉ／Ｆ１１２（最も一般的にはＷＳＤＬでＩ／Ｆを公開）では、複合Ｗｅｂサービス用サーバ装置２００から複合Ｗｅｂサービス（又はプリミティブＷｅｂサービス）に関する状態の問い合わせ要求メッセージを受信する（Ｓ１６０１）。このメッセージには状態を知りたい複合Ｗｅｂサービスの名前や、取得する情報の詳細度を指示する情報（集約した情報のみか、プリミティブＷｅｂサービスの状態も含めて取得するか等）などが含まれている。
サービス管理用サーバ装置１００の管理情報公開Ｉ／Ｆ１１２、制御部１１０、通信部１１１が連動することにより、メッセージ中で指示された複合Ｗｅｂサービスについての状態情報を指示された詳細度で、内部ＤＢ１０９中から抽出し、抽出内容を示す管理情報（通知情報）を生成する（Ｓ１６０２）（通知情報生成ステップ）。
生成した複合Ｗｅｂサービスについての管理情報（通知情報）は、管理情報公開Ｉ／Ｆ部１１２より問い合わせ元の複合Ｗｅｂサービス用サーバ装置２００に返信される（Ｓ１６０３）（送信ステップ）。
【００９３】
図７、図１７を利用して、サービス管理用サーバ装置１００の管理情報公開Ｉ／Ｆ１１２を利用する複合Ｗｅｂサービス用サーバ装置２００についての一般的な動作概要を説明する。
【００９４】
複合Ｗｅｂサービス用サーバ装置２００は、ユーザとの対話画面を生成する機能と、複合Ｗｅｂサービスを順次呼び出す機能を持つ。
【００９５】
利用者（ユーザ）クライアント端末装置４００を利用して、図７のクライアント複合Ｗｅｂサービス用サーバ装置２００が提供するサービス画面のトップページにアクセスする。複合Ｗｅｂサーバ装置２００はＨＴＭＬ，ＸＨＴＭＬ等、Ｗｅｂブラウザが解釈・表示できる形式でコンテンツを出力し、クライアント端末装置４００に送信する。これをクライアント端末装置４００上のＷｅｂブラウザが受信し、コンテンツを画面に表示する。送信コンテンツにはディスプレイ上に表示される項目の他、リンク先（Ｗｅｂサービスの）アドレスなどが記載されている。
【００９６】
ユーザからリンクが付された画面上の構成要素（文字やボタン）が押されると（Ｓ１７０１）、複合Ｗｅｂサービス用サーバ装置２００は次ページの画面を出力しようとする。
【００９７】
ここで、複合Ｗｅｂサービス用サーバ装置２００は、次ページ出力前に次ページ出力の構成要素を解析し、画面構成要素（リンクやボタンなど）に関連付けられた複合Ｗｅｂサービス（の画面構成要素とリンク）があるかどうかどうかを判断する（Ｓ１７０２）。
状態をチェックすべき複合Ｗｅｂサービスがある場合（Ｓ１７０２でＹｅｓ）は、サービス管理用サーバ装置１００に当該複合Ｗｅｂサービスの状態を問い合わせ、応答を受け取る（Ｓ１７０３）。チェックすべきＷｅｂサービスが無い画面要素については、なにもしない（Ｓ１７０２でＮｏ）。
（Ｓ１７０２でＹｅｓの場合）その後、受け取ったＷｅｂサービスの状態情報に応じて当該画面の構成要素を最適に動的に変更する（Ｓ１７０６）。Ｗｅｂサービスの状態情報に応じて動的に画面要素を変更するもっとも簡単な例は、図７の決済方法選択画面のように、ＷＥＢブラウザ上の分割された画面フレームにＷｅｂサービス問い合わせの応答結果を表示する方法が考えられる。図７では決済方法を選択する画面が表示されているが、Ｗｅｂサービスの状態を示す管理用のフレーム中に選択可能な決済のうち使用できない手段を利用者に示すことができる。さらに高度な方法としては、図７の下位フレームの決済手段を選択するフレーム中で利用できなくなっているクレジット決済のボタンシステム側で選択不可として画面を表示することも考えられる。
最後にサービスの状態に応じて最適に変更された画面要素とそれ以外の画面要素を合成し１つの画面にまとめユーザに表示する（Ｓ１７０７）。
【００９８】
このようにリンク先のページを表示するにあたり、（その時稼働状況に応じて）動的に画面を構成するもっとも簡単な実装手段としては、例えばＪａｖａＳｃｒｉｐｔ（登録商標）を使って動的に画面を生成する手段が知られている。ＪａｖａＳｃｒｉｐｔ（登録商標）を使う場合は、予め表示コンテンツ中に管理状態の問い合わせロジックや画面変更ロジックを埋め込んでおく必要があるが、コンテンツ中にロジックを埋め込むのではなく、複合Ｗｅｂサービス用サーバ装置２００のフレームワーク側で状態をチェックしＷｅｂサービスの状態におうじてコンテンツを変更・付加することもできる。
たとえば複合Ｗｅｂサービス用サーバ装置２００中に管理すべきＷｅｂサービスおよび動的コンテンツの生成手段のパターンを定義ファイルとして設定しておく。複合Ｗｅｂサービス用サーバ装置２００上のＷｅｂアプリケーションのミドルウェア側では、Ｗｅｂアプリケーションのコンテンツの出力をフックし、（設定ファイルに指定された）状態をチェックすべき、（複合）Ｗｅｂサービスがあればサービス管理用サーバ装置１００に問い合わせ、定義ファイルに指定された方法で、元のコンテンツに管理情報を付加する実装方法も考えられる。
【００９９】
上記では、障害情報をクライアント端末装置４００への画面情報に再利用した例を説明したが、例えばクレジット決済サービスを複数の業者が提供している場合、最新のサービス応答時間や最遅延応答時間その他のサービスレベル情報を選択画面に表示し、ユーザのメニュー選択際の判断材料を提供することも同じしくみで可能である。
【０１００】
また、上記のような可用性情報のかわりに各サービスの応答時間（実行性能）を表示しても有用な場合がある。
同種のサービスを選択的に提供する場合において、利用時の予想応答時間としてアプリケーション画面の一部に表示すれば、ユーザにとっての利便性も高まる（例えば、大きなファイルのダウンロードを複数のサーバで提供する場合に、ダウンロードするのにかかる予想時間を事前に提示することもできる）。
【０１０１】
本実施の形態に係る通信システムは、サービス管理装置の収集した情報を、アプリケーションの画面遷移に合わせて確認、表示することで、利用可能なサービスのガイドをする手段と、クライアントコンピュータ上において、アプリケーション画面と当該アプリケーション管理情報を統合する手段と、Ｗｅｂアプリケーションの画面作成時において、Ｗｅｂサービス稼働・性能情報等を利用して、利用可能なＷｅｂサービスから構成されるアプリケーション画面を生成する手段とを有する。
本実施の形態では各サービスの状態を管理者の画面ではなく、利用者のアプリケーション画面の一部に関連する管理情報を表示することができ、利用者が稼働状況や性能情報をアプリケーション使用することができる。これにより、動作しないサービスや負荷の重いサーバがユーザ側で予想可能となりこれらのサービスの利用を控えることができ、システム全体として無駄なトラフィックの発生防止、無駄なＣＰＵの利用の防止が可能である。
【０１０２】
以上のように、本実施の形態では、複数のタスクを包含する複合タスクの各タスクの状態を監視し、いずれかのタスクにおける障害を検知する状態監視部と、前記状態監視部によりいずれかのタスクにおける障害が検知された場合に、障害が検知された障害タスクを前記複合タスクを利用する端末装置に通知するための障害通知情報を生成する通知情報生成部と、前記通知情報生成部により生成された障害通知情報を送信する送信部とを有する管理装置（サービス管理用サーバ装置）について説明した。
【０１０３】
また、前記管理装置（サービス管理用サーバ装置）は、前記端末装置の選択に基づいて前記複合タスクのいずれかのタスクを実行するサーバ装置に接続され、前記状態監視部は、前記端末装置により実行が選択される可能性のある選択可能性タスクを前記サーバ装置から通知され、前記サーバ装置から通知された前記選択可能性タスクに障害が発生しているか否かを検知し、前記通知情報生成部は、前記状態監視部により前記選択可能性タスクの障害が検知された場合に、前記選択可能性タスクを障害タスクとして示す障害通知情報を生成し、前記送信部は、前記サーバ装置から前記端末装置に前記選択可能性タスクを障害タスクとして通知させるために、前記通知情報生成部により生成された障害通知情報を前記サーバ装置に対して送信することを説明した。
【０１０４】
また、前記通知情報生成部が、前記状態監視部により障害が検知された障害タスクとタスクフローにおいて並列関係にある他のタスクが存在する場合に、前記障害タスクの代替として前記他のタスクを前記端末装置に通知するための情報を前記障害通知情報として生成することを説明した。
【０１０５】
また、前記管理装置（サービス管理用サーバ装置）は、更に、前記複合タスクに包含される各タスクの実行性能を計測する実行性能計測部を有し、前記通知情報生成部は、前記実行性能計測部により計測された各タスクの実行性能を前記端末装置に通知するための実行性能通知情報を生成し、前記送信部は、前記通知情報生成部により生成された実行性能通知情報を送信することを説明した。
【０１０６】
また、前記状態監視部は、複数のＷｅｂサービスを包含する複合Ｗｅｂサービスの各Ｗｅｂサービスの状態を監視し、いずれかのＷｅｂサービスにおける障害を検知し、前記通知情報生成部は、前記状態監視部によりいずれかのＷｅｂサービスにおける障害が検知された場合に、障害が検知された障害Ｗｅｂサービスを前記複合Ｗｅｂサービスを利用する端末装置に通知するための障害通知情報を生成することを説明した。
【図面の簡単な説明】
【０１０７】
【図１】実施の形態１に係る通信システムの構成例を示す図。
【図２】実施の形態１に係る複合Ｗｅｂサービスの管理例を示す図。
【図３】実施の形態１に係るサービス管理用サーバ装置の構成例を示す図。
【図４】従来の依存関係のあるＷｅｂアプリケーションの表示例を示す図。
【図５】実施の形態１に係る複合Ｗｅｂサービスのフロー解析表示例を示す図。
【図６】実施の形態１に係る性能情報を合成表示した例を示す図。
【図７】実施の形態２に係る通信システムの構成の概要を示す図。
【図８】実施の形態２に係るサービス管理用サーバ装置の構成例を示す図。
【図９】実施の形態１及び２に係る各装置のハードウェア構成例を示す図。
【図１０】従来の複合Ｗｅｂサービスの例を示す図。
【図１１】実施の形態１に係る複合Ｗｅｂサービスの解析動作の例を示すフローチャート図。
【図１２】実施の形態１に係るＢＰＥＬ定義を使ったフロー構造解析結果例を示す図。
【図１３】実施の形態１に係る複合Ｗｅｂサービス全体での障害状態決定方法を示すフローチャート図。
【図１４】実施の形態１に係るＢＰＥＬ定義を使ったフロー構造解析例を示す図。
【図１５】実施の形態１に係るステータス集約した結果の例を示す図。
【図１６】実施の形態２に係るサービス管理用サーバ装置の動作例を示すフローチャート図。
【図１７】実施の形態２に係る複合Ｗｅｂサービス用サーバ装置の動作例を示すフローチャート図。
【符号の説明】
【０１０８】
１００  サービス管理用サーバ装置、１０１  ＳＯＡＰメッセージ解析部、１０２  定義ファイル記憶部、１０３  サービス構成解析部、１０４  エンドポイントリファレンス管理部、１０５  サービス状態管理部、１０６  サービス性能管理部、１０７  管理シナリオ実行部、１０８  画面表示部、１０９  内部データベース、１１０  制御部、１１１  通信部、１１２  管理情報公開インタフェース、２００  複合Ｗｅｂサービス用サーバ装置、３００  プリミティブＷｅｂサービス用サーバ装置、４００  クライアント端末装置、５００  インターネット。
【図１】
2008003709.tif 000003
【図２】
2008003709.tif 000004
【図３】
2008003709.tif 000005
【図４】
2008003709.tif 000006
【図５】
2008003709.tif 000007
【図６】
2008003709.tif 000008
【図７】
2008003709.tif 000009
【図８】
2008003709.tif 000010
【図９】
2008003709.tif 000011
【図１０】
2008003709.tif 000012
【図１１】
2008003709.tif 000013
【図１２】
2008003709.tif 000014
【図１３】
2008003709.tif 000015
【図１４】
2008003709.tif 000016
【図１５】
2008003709.tif 000017
【図１６】
2008003709.tif 000018
【図１７】
2008003709.tif 000019