"所定の順序で実行されるコンピュータソフトウェアにより提供されるサービスの障害を検出するサービス運用管理装置において、複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶するとともに、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶するサービス構成情報管理部と、サービス同士のメッセージを記録したメッセージログと上記メッセージのメッセージ中継を記録したトランザクションログとの少なくともいずれかのログを過去ログとして複数記憶する統合ログ記憶部と、統合ログ記憶部に記憶する新たな入力ログを入力し、既に統合ログ記憶部に記憶した複数の過去ログの中から、入力ログが示すサービスより前に実行されたサービスのログを前ログとして検出し、サービス構成情報管理部に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出するサービス障害検出部と、を備え、サービス障害検出部は、サービス構成情報管理部が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスの入力ログに対して優先的に障害発生の検出をすることを特徴とするサービス運用管理装置。ログは、セッションIDと業務IDとサービスIDを有し、サービス構成情報管理部は、サービスを業務IDとサービスIDとにより定義し、業務IDとサービスIDとにより複数のサービスのサービス実行順序を記憶し、サービス障害検出部は、既に統合ログ記憶部に記憶した複数の過去ログから、入力ログが有するセッションIDと同じセッションIDを有する過去ログであって、入力ログが示すサービスの直前に実行されたサービスの過去ログを前ログとして検出するとともに、サービス構成情報管理部に記憶したサービス実行順序定義情報からサービス実行順序を検索して、前ログが示すサービスの後に実行する可能性のあるサービスを候補サービスとして取得し、取得した候補サービスの業務IDとサービスIDとが、入力ログが有する業務IDとサービスIDとに一致するか判断してサービスの障害発生を検出することを特徴とする請求項1記載のサービス運用管理装置。サービス運用管理装置は、さらに、サービス構成情報管理部に記憶したサービス実行順序定義情報からサービス実行順序を検索することにより、障害が発生した障害発生サービスから障害の影響を受ける他のサービスの範囲を特定し、障害の影響を受ける他のサービスの障害影響範囲を障害発生サービスの影響範囲情報として障害発生サービスに対応させてサービス構成情報管理部に記憶するサービス障害影響範囲特定部を備えたことを特徴とする請求項1又は2記載のサービス運用管理装置。サービス障害影響範囲特定部は、サービス間の呼び出し関係を階層情報として、階層情報に基づいてサービスの障害影響範囲を特定することを特徴とする請求項1~3いずれかに記載のサービス運用管理装置。サービス障害影響範囲特定部は、障害発生サービスに初期値を付与し、障害発生サービスを呼ぶサービスおよび障害発生サービスから呼び出されるサービスに対しては、呼び出しごとに値が減算または加算される値を解析優先度スコアとして付与し、解析優先度スコアをもとに、サービスの障害影響範囲を算出することを特徴とする請求項4記載のサービス運用管理装置。サービス運用管理装置は、さらに、サービスのメッセージに含まれる属性情報の属性値の異常範囲を障害基準値として定義したサービス障害定義情報を記憶するサービス障害定義管理部を備え、メッセージは、サービスの属性値を含む属性情報を有し、サービス障害検出部は、サービス障害定義管理部が記憶するサービス障害定義情報を参照して、サービス障害定義情報が定義した障害基準値とログのメッセージに含まれる属性情報の属性値とを比較してサービスの障害発生を検出することを特徴とする請求項1~5いずれかに記載のサービス運用管理装置。メッセージは、サービスの重要度を示す属性値を含む属性情報を有し、サービス障害検出部は、ログのメッセージが有する属性情報が示す重要度を参照して、重要度の高い属性情報を有するメッセージのサービスの障害発生を優先的に検出することを特徴とする請求項1~6いずれかに記載のサービス運用管理装置。メッセージは、属性情報をメッセージから取り出すための属性クエリを有し、サービス運用管理装置は、さらに、ログのメッセージが有する属性クエリを実行して、ログのメッセージからから属性情報を取り出す属性クエリ部と、属性クエリ解釈部が取り出した属性情報を記憶する属性管理部とを備え、サービス障害検出部は、属性管理部が記憶した属性情報を参照して、障害検出の判定をすることを特徴とする請求項6又は7いずれかに記載のサービス運用管理装置。従来技術には、複雑なシステムにおいてサービスの実行順序の不正を検出するには、実行され得る全てのサービス実行順序を実際に実行中のサービスのログと照合する必要があり、効率的に検出することが難しいという課題があった。複雑な業務を多数含むサービス運用管理システムの場合、このマッチング対象となるサービス実行順序定義が膨大となり、多数のサービスを同時実行し短時間に大量のログが発生する場合など、ログ監視のリアルタイム性を損なう恐れがあった。この発明は、サービス実行順序不正を効果的に検出するサービス運用管理装置を提供することを目的とする。この発明のサービス運用管理装置は、所定の順序で実行されるコンピュータソフトウェアにより提供されるサービスの障害を検出するサービス運用管理装置において、複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶するとともに、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶するサービス構成情報管理部と、サービス同士のメッセージを記録したメッセージログと上記メッセージのメッセージ中継を記録したトランザクションログとの少なくともいずれかのログを過去ログとして複数記憶する統合ログ記憶部と、統合ログ記憶部に記憶する新たな入力ログを入力し、既に統合ログ記憶部に記憶した複数の過去ログの中から、入力ログが示すサービスより前に実行されたサービスのログを前ログとして検出し、サービス構成情報管理部に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出するサービス障害検出部と、を備え、サービス障害検出部は、サービス構成情報管理部が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスの入力ログに対して優先的に障害発生の検出をすることを特徴とする。本発明は、サービス構成情報管理部が、障害の影響度を記憶しているので、サービス障害の影響度が大きいものについて優先的にサービス実行順序不正を検出することを可能にする。実施の形態1.図1はこの発明の実施の形態1~3に係るサービス運用管理装置103を用いたサービス運用管理システム100の構成図である。≪サービス運用管理システム100の説明≫サービス運用管理システム100は、管理対象となるサービス部101、ESBEnterpriseServiceBus102、サービス運用管理装置103よりなる。サービス部101は、計算機とアプリケーションプログラムとから構成される。サービス部101はサービスを提供する。サービスとは、計算機や専用機でアプリケーションプログラムを実行することにより達成されるものである。業務は、サービスが順次実行されて達成される仕事のことであり、例えば、在庫管理業務、予約業務、ネット検索業務などである。業務は複数のサービスが所定の実行順序で実行されることにより達成される。サービス部101は、その機能の実現のためにメッセージ104をサービス間で授受する。メッセージ104は、セッションIDと業務IDとサービスIDと宛先アドレスと差出アドレスとメッセージ本文とを有している。ここで、セッションとは、コンピュータシステムやネットワーク通信において、接続又はログインしてから、切断又はログオフするまでの、一連の操作や通信のことをいう。セッションIDとは、接続又はログインから切断又はログオフまでの間セッションを識別するために付与された識別子である。業務IDとは、業務を識別するために付与された識別子である。サービスIDとは、サービスを識別するために付与された識別子である。さらに、メッセージ104は、後述する実施の形態2,3で説明する属性情報105や属性クエリ106を属性情報として有している。ESB102は、メッセージログ107、トランザクションログ108を記憶するメモリ装置図示せずを備えている。メッセージログ107は、メッセージ104の内容をログとして記録したものである。ログは、年月日時分秒などのログ時刻を記録している。トランザクションログ108は、ESB102自身の行うメッセージルーティングなどの処理の記録である。トランザクションログ108は、メッセージ104とセッションIDと業務IDとサービスIDとを含んでいる。図1に示すように、複数のサービス部101が、ESB102を経由しメッセージを授受し、利用者向けの機能を実現している。ESB102は、ひとつのサービス運用管理システムにつき1つ用いられる場合もあるが、図1に示すように企業合併や提携などで複数のESB102を並存させる場合もある。≪サービス運用管理装置103の構成≫サービス運用管理装置103は、サービス構成情報管理部111、サービス障害影響範囲特定部112、収集蓄積部114、サービス障害検出部115、ログ管理部116、統合ログ記憶部117を備えている。さらに、サービス運用管理装置103は、後述する実施の形態2、3で説明する属性クエリ解釈部109や属性管理部110やサービス障害定義管理部113を有している。サービス運用管理装置103は、ESB102のログメッセージログ107、ESB自身の行うメッセージルーティングなどの処理の記録であるトランザクションログ108を入力してリアルタイムに監視し、サービスの障害を検出する。サービス構成情報管理部111は、記憶装置であり、複数のサービスの実行順序を定義したサービス実行順序定義情報を記憶する。サービス構成情報管理部111は、サービスを業務IDとサービスIDとにより識別し、業務IDとサービスIDとにより複数のサービスのサービス実行順序を記憶する。サービス構成情報管理部111は、さらに、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を示す影響範囲情報を記憶する。サービス障害影響範囲特定部112は、サービス構成情報管理部111に記憶したサービス実行順序定義情報からサービス実行順序を検索することにより、障害の影響を受けるサービスの範囲を特定し、障害の影響を受けるサービスの障害影響範囲を影響範囲情報としてサービス構成情報管理部111に記憶する。収集蓄積部114は、ESB102から後述する実施の形態3の場合は、属性クエリ解釈部109を経由して、サービス同士のメッセージ中継を記録したトランザクションログ108とサービス同士のメッセージを記録したメッセージログとの少なくともいずれかのログを入力する。ログはログ管理部116に渡される。ログ管理部116は、収集蓄積部114が収集したログを統合ログ記憶部117に記憶するとともに、ログをサービス障害検出部115に引き渡す。統合ログ記憶部117は、記憶装置であり、サービス同士のメッセージ中継を記録したトランザクションログ108とサービス同士のメッセージ104を記録したメッセージログ107との少なくともいずれかのログを過去ログとして複数記憶する。サービス障害検出部115は、新たな入力ログを入力し、統合ログ記憶部に記憶した複数の過去ログの中から、入力ログが示すサービスより前に実行されたサービスの過去ログを前ログとして検出する。サービス障害検出部115は、サービス構成情報管理部111に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出する。さらに、サービス障害検出部115は、サービス構成情報管理部111が記憶する影響範囲情報を参照して、障害の影響度が大きいサービスのログに対して優先的に障害発生の検出をする。≪サービス運用管理装置103のサービス運用管理方法の概略動作≫本実施の形態にかかるサービス運用管理装置103は、サービス構成情報管理部111、およびサービス障害影響範囲特定部112を備えることを特徴とする。本実施の形態1にかかるサービス運用管理装置103は、サービス構成情報管理部111、およびサービス障害影響範囲特定部112という従来技術にはない特徴的な構成要素を設け、サービス障害検出部115の実行の際に、サービス障害の影響範囲が広いものについて優先的に検出する。≪サービス実行順序定義情報≫業務とサービスとの例を図2に示す。図2は、サービスの集合である業務1~nにおいて、それぞれの業務がサービスを実行するサービス実行順序定義の例を示す。W1、Y1などアルファベットと添え字の組み合わせはサービスを示す。また矢印は、矢印左側のサービスが矢印右側のサービスを呼び出して実行することを示す。図2において、サービスXは、業務1~nで呼び出されており、サービスXの実行時に実行順序不正が発生しているかどうかを厳密にチェックするためには、サービスXの直前に実行されたサービスがW1~Wnのいずれかのサービスであるかどうか確認する必要がある。定義が複雑な業務を多数含むサービス運用管理システムの場合、このマッチング対象となるサービス実行順序定義が膨大となり、多数のサービスを同時実行し短時間に大量のログが発生する場合など、ログ監視のリアルタイム性を損なう恐れがある。図3において、12は業務を示す業務IDである。A~Gはそれぞれサービスを示すサービスIDである。業務1は、サービスA、B、C、Dから構成されている。業務2は、サービスE、B、F、Gから構成されている。矢印は、サービスの呼び出しを示す。また、サービスBを利用する業務は12のみとする。サービス間の呼び出し関係を階層情報という。サービス構成情報管理部111は、図3に示す階層情報を、業務IDとサービスIDとを用いて複数のサービスのサービス実行順序定義情報例えば図3の情報として記憶している。サービス実行順序定義情報の記憶形式やデータ形式は問わない。≪影響範囲情報≫図3において、業務1のサービスBで障害が発生したものとすると、サービスBの障害の影響範囲はA、C、Dまで及ぶ。サービス障害影響範囲特定部112は、この影響範囲の大小を、サービス構成情報管理部111の持つサービス実行順序定義情報例えば図3の情報より算出して、影響範囲情報としてサービス構成情報管理部111に記憶する。影響範囲情報は、サービスに対応してそのサービスに障害が発生した場合に障害の影響度を有している。障害の影響度は、例えばサービスIDごとに固定の値を定義するように構成してもよい。例えば、サービスAは5点、サービスBは10点、サービスCは7点のように固定値を付与し、その固定値を影響範囲情報としてサービス構成情報管理部111に記憶する。あるいは、図4に示すように、あるサービスで障害が発生した場合、障害のあったサービスのサービスIDに関係なく、そのサービスを含む業務の全てのサービスに影響が発生するものと仮定し、以下で説明する解析優先順スコアを各サービスに付与して、各サービスの解析優先順スコアの合計値を業務ごとの合計として表してもよい。例えば、解析優先順スコアは、障害の発生したサービスBに初期値10点を与え、当該サービスBを呼ぶサービスAおよび当該サービスBから呼び出されるサービスC、Dは呼び出しごとに解析優先度スコアが減算されるものとするよう構成してよい。また例えば減算の代わりに加算することにより解析優先度スコアを算出してもよい。図4においては、最も高い解析優先度スコアは10で、呼び出しごとに解析優先度スコアが1ずつ減算されるよう構成した解析優先順スコアを用いて、図3の業務1、業務2ついてサービス障害影響範囲を算出した際の影響範囲情報構造体の例である。図4は、業務1のサービスBに対して記憶される影響範囲情報の例である。図4においては、影響範囲情報を単一の構造体単一の値としてではなく、1.業務別の詳細影響度を保持する構造体、2.業務毎の影響度をまとめて保持する構造体、3.サービス別の影響度をまとめて保持する構造体、の3種類の構造体として実現している。業務別の詳細影響度を保持する構造体には、例えば、業務1の実行中にサービスBに障害が発生した場合、業務1のサービスBに付与された影響度と業務1のサービスA、C、Dに付与された影響度が保持される。また、業務1の実行中にサービスBに障害が発生した場合、業務2のサービスBに付与された影響度と業務2のサービスE、F、Gに付与された影響度が保持される。図4の場合は、業務1の実行中にサービスBに障害が発生した場合、業務2には関係ないので業務2のサービスBと業務2のサービスE、F、Gには影響がないので、影響度はゼロが保持される。業務毎の影響度をまとめて保持する構造体には、業務毎の影響度をまとめて保持する。すなわち、業務別の詳細影響度を保持する構造体に保持されている各サービスの影響度の業務別合計が保持される。サービス別の影響度をまとめて保持する構造体には、業務別の詳細影響度を保持する構造体に保持されている各サービスの影響度のサービス別合計が保持される。図4の影響範囲情報から、業務1を実行中のサービスBの影響範囲は、サービスB単独であれば10点であり、サービスBが属する業務1であれば37点であり、サービスBが属する業務2であれば0点であることが、わかる。図4の影響範囲情報から、業務2を実行中のサービスBの影響範囲は、サービスB単独であれば10点であり、サービスBが属する業務1であれば0点であり、サービスBが属する業務2であれば37点であることが、わかる。サービス構成情報管理部111は、サービスBに対応してそのサービスBに障害が発生した場合に障害の影響度を示す影響範囲情報を図4に示すように記憶している。≪サービス障害検出部115のサービス実行順序不正検出方法の動作≫図5に、サービス障害検出部115におけるサービス実行順序不正検出処理の動作フローチャートを示す。まず、サービス障害検出部115は、サービス同士のメッセージ中継を記録したトランザクションログ108とサービス同士のメッセージを記録したメッセージログとの少なくともいずれかのログをESB102から入力する。サービス障害検出部115は、入力としてログ入力ログを受け取りS101、入力ログ中のサービスID、セッションID、業務IDを取り出すS102、S103、S104。サービス障害検出部115は、サービス構成情報管理部111を検索して、入力ログのサービス障害影響範囲を取り出すS199。サービス構成情報管理部111から入力ログのサービス障害影響範囲が検索できない場合は、S105に進む。サービス障害検出部115は、サービス障害影響範囲と比較する閾値を設定しておき、入力ログのサービス障害影響範囲が検索できた場合、サービス障害検出部115は、閾値以上の影響範囲を持つサービスのログを受け取った際には、他のサービスの障害よりも優先的に図5の実行順序不正検出の処理を実行する。閾値未満の影響範囲を持つサービスのログを受け取った際には、その入力ログを一時メモリに保管し、その入力ログに対する図5の実行順序不正検出の処理を後刻実行する。S105において、サービス障害検出部115は、S103で取り出したセッションIDに関連付けられたログで最新のもの直前のログ、前ログというを、統合ログ記憶部117より取り出すS105、S106。サービス障害検出部115は、同一セッションIDを有するログであって、ログ時刻が最新のものを前ログとして取り出す。サービス障害検出部115は、S105、S106の取り出しで、セッションIDに関連付けられた前ログがある場合は、S107以下の処理を行う。まず、サービス障害検出部115は、サービス構成情報管理装置111に記憶されたサービス実行順序定義情報をサービスID、業務IDで検索して前ログが示すサービスの次に実行する可能性のあるサービスを候補サービスとして取り出す。サービス障害検出部115は、S105で取り出した前ログに関連付けられた、次に実行する可能性のある候補サービスのサービスID業務IDのリストを作成するS107。S114において後述するが、S105で取り出した前ログにサービスID業務IDのリストが既に付随している場合には、S107の候補サービスのサービスID業務IDのリスト作成動作は省略することができる。そして、S102、S103で取り出した入力ログのサービスID業務IDが、S107で取り出し作成した候補サービスのサービスID業務IDのリストに含まれるかどうか調べるS109、S110。サービス障害検出部115は、S109、S110で、候補サービスのサービスID業務IDが一致する場合、サービス実行順序不正は発生していないと判断し、S113以下の処理を行う。S108~S110で、候補サービスのサービスIDまたは業務IDがS102、S103で取り出した入力ログのサービスのサービスID業務IDのいずれかと一致しない場合、サービス障害検出部115は、S109、S110の処理を、S107で取り出し作成した候補サービスのサービスID業務IDのリストに対して繰り返し実行し、候補サービスのサービスID業務IDのリストの中から、S102、S103で取り出した入力ログのサービスのサービスID業務IDと一致するものを探す。S111で、サービスID業務IDが候補サービスのサービスID業務IDのリストの最後の要素である場合、サービス障害検出部115は、サービス実行順序不正を検出したと判断しS112、あらかじめ定めたサービス実行順序不正への対処処理を行う。すなわち、サービス障害検出部115は、サービス障害影響範囲特定部112に対して、サービス障害情報を送る。このサービス障害情報は、障害を起こしたサービスの業務ID、サービスID、障害の原因を示す障害原因IDなどを含む。S108~S110の処理でサービス実行順序不正を検出しなかった場合、またはS105、S106でセッションIDに関連付けられた前ログがない場合は、サービス障害検出部115は、S113以下の処理を行う。まず、サービス障害検出部115は、サービス構成情報管理部111より、当該入力ログを生成したサービスの次に実行する可能性のある候補サービスのサービスID業務IDのリストを取り出しS113、S101で入力された入力ログと、S113で取り出した候補サービスのサービスID業務IDのリストを関連付け、ログ管理部116を通して統合ログ記憶部117に過去ログとして保管しS114、処理を完了する。このように、統合ログ記憶部117に記憶された入力ログは、次回、過去ログとして検索されることになるが、過去ログに次に実行する可能性のある候補サービスのサービスID業務IDのリストが関連付けられて記憶されている場合はその過去ログが前ログとして検索された場合には、前ログと次に実行する可能性のあるサービスID業務IDのリストとが同時に検索できるのでS107の候補サービスのサービスID業務IDのリスト作成動作を省略することができる。なお、サービス運用管理システム100の実現上の都合によっては、サービス実行順序不正を検出したログに対しても、S113、S114の処理を行い、サービス実行順序不正を検出したログに候補サービスのサービスID業務IDのリストを関連付けて統合ログ記憶部117に記憶するようにしてもよい。また、図5において、サービス運用管理システム100の実現上の都合によっては、例えば、ユーザIDをセッションIDの代わりに用いることもできる。また、ユーザがサービスの集合としての業務単位でなく個別のサービスを実行するようなシステムの場合は、業務IDの取り出しや比較を省略することもできる。あるいは、例えば、S109S110においてサービスID業務IDをペアとして比較し、いずれか一方が異なるときは一致しないと判断するよう構成することもできる。以上のように、サービス障害検出部115は、統合ログ記憶部117に記憶した複数のログから、入力ログが有するセッションIDと同じセッションIDを有する過去ログであって入力ログが示すサービスの直前に実行されたサービスの過去ログを前ログとして検出し、サービス構成情報管理部111に記憶したサービス実行順序情報を検索して、前ログが示すサービスの後に実行する可能性のあるサービスを候補サービスとして取得し、取得した候補サービスの業務IDとサービスIDとが、入力ログが有する業務IDとサービスIDとに一致するか判断してサービスの障害発生を検出する。≪サービス障害影響範囲特定部112のサービス障害影響範囲特定方法の動作≫サービス障害影響範囲特定部112は、サービス障害影響範囲を特定するものである。以下の説明では、サービス障害影響範囲特定部112が、サービス障害影響範囲を、サービス障害情報をサービス障害検出部115より受け取るたびに計算する場合を説明する。図6に、サービス障害影響範囲特定部112の処理の動作フローチャートを示す。サービス障害影響範囲特定部112は、まず、サービス障害情報をサービス障害検出部115より受け取るS201。このサービス障害情報は、障害を起こしたサービスの業務ID、サービスID、障害原因IDなどを含む。次に、サービス障害影響範囲特定部112は、障害を起こしたサービスのそれぞれについて業務ID、サービスIDを取り出しS202、サービス構成情報管理部111より、当該サービスの親サービス親業務情報を取り出すS203。この親サービス情報は、親サービスのサービスIDを含み、親業務情報は親業務の業務IDを含む。サービス障害影響範囲特定部112は、S203で取り出した親業務のそれぞれに対して、図4に示すような、業務ごとの影響範囲情報を組み立て、業務ごとの影響範囲情報を当該サービス情報の一部として、障害を起こしたサービスに対応させてサービス構成情報管理部111に追加記憶するS204。図6において、サービス障害影響範囲特定部112は、図6のS204の処理を、S203で取り出した全ての親業務について繰り返しS205、更に、S203で取り出した全ての親サービスについて、サービス間の階層情報を計算し、中間情報として記録するS206。サービス間の階層情報とは、あるサービス親サービスが他のサービス子サービスを呼び出す関係、および同じ親サービスに呼び出されたサービス群兄弟サービスの関係の情報、および、障害を起こしたサービスから各サービスまでの階層の深さを含む情報である。サービス障害影響範囲特定部112は、S203~S207までの処理を、S203で取り出した全ての親サービスおよびそれらから親子関係を辿れる全ての親サービス親業務に対して再帰的に実行するS207。また、サービス障害影響範囲特定部112は、S201で入力された全ての障害を起こしたサービスについて、当該サービスが呼び出す子サービスの情報をサービス構成情報管理部111より取り出しS208、それら全ての子サービスについて、サービス間の階層情報を計算し、中間情報に記録するS209、S210。サービス障害影響範囲特定部112は、S208~S210の処理を、S208で取り出した各サービスの全ての子サービスおよびそれらから親子関係を辿れる全ての子サービスに対し再帰的に実行するS211。以上の処理を完了すると、サービス障害影響範囲特定部112は、S206およびS209で組み立てた中間情報をもとに、業務ごとに、また、更にサービス毎に、影響度を算出しS212、S213処理を完了する。この影響範囲情報の構造体の詳細例は、図4に示したとおりである。図4の例では、更に業務ごと、且つ、業務を構成するサービスごとの詳細影響度を算出し、影響範囲情報構造体に加えている。サービス障害影響範囲は、障害を検出するたびに計算され、障害が発生したサービスに対してのみサービス障害影響範囲が計算されて記憶されることになる。障害が発生したサービスに対してのみサービス障害影響範囲が計算されて記憶されている場合には、図5のS199において、すべての入力ログについてはサービス障害影響範囲を検索することができない。図6においては、サービス障害検出部115が障害を検出するたびにサービス障害影響範囲特定部112がサービス障害影響範囲を計算する場合を示したが、サービス障害影響範囲特定部112は、サービス障害影響範囲をログ収集蓄積のたびに計算してもよい。また、例えば、サービス障害影響範囲特定部112は、サービス構成情報管理部111のサービス構成情報が更新されるたびにすべてのサービスについてサービス障害影響範囲を算出し、サービス障害影響範囲を業務サービスと関連付けてサービス構成情報管理部111にあらかじめ記憶させておいてもよい。またはサービス障害影響範囲特定部112が、サービス障害影響範囲を業務サービスと関連付けてメモリ装置に一時保管キャッシュしておくように構成してもよい。すべてのサービスについてサービス障害影響範囲をあらかじめ算出しサービス構成情報管理部111にあらかじめ記憶させておく場合には、サービス障害検出部115は、図5のS199において、すべての入力ログについてサービス障害影響範囲を検索することができ、優先的なサービス実行順序不正の検出をするか否かをすべてのサービスについて判断することができる。以上の構成および動作により、この実施の形態では以下のような効果を奏する。サービス障害検出部115、サービス構成情報管理部111、サービス障害影響範囲特定部112の動作により、サービス障害影響範囲が広いものについて優先的にサービス実行順序不正を検出することを可能にする。実施の形態2.実施の形態1の説明ではサービス実行順序不正の検出について述べてきたが、サービス障害影響範囲による優先度付けは、サービス実行順序不正以外の障害検出についても適用可能である。以下に、サービス運用管理装置103が、メッセージログ107およびトランザクションログ108から検出可能なサービス障害を示す。1.実行順序不正実施の形態1の場合実行順序不正とは、サービスの実行順序定義から逸脱したサービスの呼び出しが行われた場合をいう。2.タイミングの不正タイミングの不正とは、指定された時間間隔で応答されていない早すぎ、遅すぎ場合、あるいは、応答が欠落した通信エラーを含む場合をいう。3.サービスエラーサービスエラーとは、サービス自身にて検出済みのエラーをいう。ログに特定のエラーコードおよびメッセージが含まれている。4.値の不正値の不正とは、応答された値が正しい範囲内に収まっていない場合、又は、フォーマット不正の場合をいう。これらの障害を検出するために、この実施の形態のサービス運用管理システムを構成するサービス運用管理装置103は、サービス障害定義管理部113を備えている。サービス障害定義管理部113は、サービスの実行タイミング、パラメータの値のとりうる範囲の制限、パラメータの値のとりうる範囲の制限などのサービス障害定義障害基準値をあらかじめ保管する記憶部である。これらの障害を検出するために、サービス部101は、障害を検出するのに必要な属性情報105の属性値を、メッセージ104に付加する。この属性情報105としては、一連の業務かどうかを示すセッションIDや業務ID、サービスの実行時刻などを付加することができる。例えば、サービス部101は、メッセージ104がXMLである場合、後述する図8において、<query>~</query>で囲まれた部分点線枠内で示したXPath記法の条件式として、サービスの実行タイミング、パラメータの値、サービスの戻り値などを属性として定義することができる。サービス運用管理装置103のサービス障害検出部115は、入力ログに記録されたこれら属性情報105の属性値が、サービス障害定義管理部113が記憶したサービス障害定義情報の異常範囲に違反しているか否かにより、障害を検出することができる。サービス障害検出部115は、入力ログに属性情報105として記録されたサービスの実行タイミングが、サービスの実行タイミングと一致しない場合は、そのサービスに障害が発生したものと判定する。サービス障害検出部115は、入力ログに属性情報105として記録されたパラメータの値が、パラメータの値のとりうる範囲と一致しない場合は、そのサービスに障害が発生したものと判定する。サービス障害検出部115は、入力ログに属性情報105として記録されたサービスの戻り値が。パラメータの値のとりうる範囲と一致しない場合は、そのサービスに障害が発生したものと判定する。サービス障害検出部115は、サービス障害影響範囲特定部112の算出したサービス障害の影響範囲の広いサービスであって、且つ、サービス障害定義管理部113が記憶したサービス障害定義情報に違反しているサービスの障害を優先的に検出する。サービス障害検出部115は、サービス障害影響範囲特定部112の算出したサービス障害の影響範囲にかかわりなく、サービス障害定義管理部113が記憶したサービス障害定義情報に違反しているサービスの障害を優先的に検出するようにしてもよい。以上の構成および動作により、この実施の形態のサービス運用管理システム100は以下のような効果を奏する。サービス障害検出部115が、メッセージログ107から属性情報105を抽出し、当該属性情報105の値を、サービス障害定義管理部113の保管するサービス障害定義情報と照合するので、サービス障害定義管理部113が記憶したサービス障害定義に違反しているサービスの障害を優先的に検出することができる。また、サービス障害影響範囲特定部112の算出するサービス障害の影響範囲をあわせて用いれば、さらに、重要なサービスの障害を優先的に検出することを可能にする。実施の形態3.実施の形態2において、メッセージからの属性抽出はESB102のログの形式に依存する形で実現する必要がある。このため、企業合併や提携などで、図1のように、サービス運用管理システム100が複数のESB102のトランザクションログ108に対応しようとする場合、ESB102を監視対象として追加したり、ESB102をリプレースしたりするたびにサービス運用管理システム100の修正が必要となり、SOAの目的である柔軟かつ迅速なサービス構成変更に支障をきたすという課題がある。このESB102の処理の記録は、ESB102の種類により様々な形式がある。これらの例を図7に示す。1.特殊な形式のESBログ図7右側ESB102の処理をテキスト形式のトランザクションログ108に記録し、これとは別にサービス間のメッセージをファイルとして保管し、トランザクションログ108中にメッセージのファイル名とメッセージセッションIDなどを記録するもの。2.一般的なESBログ図7左側ESB102のトランザクションログ108がサービス間のメッセージ全文を包含するもの。従来の技術によるサービス運用管理装置では、このようなESB102のログの形式に応じて、メッセージのログまたはトランザクションログ108から属性を抽出するための仕組みロジックを用意する必要があった。図1において、この実施の形態のサービス運用管理システム100ではサービス部101がメッセージ104に属性情報105を付加するほか、メッセージ中の属性抽出のための属性クエリ106を添付することにより対処する。また、サービス運用管理装置103には、ログ内のメッセージ中の属性クエリ106を解釈してメッセージ中の属性を抽出する属性クエリ解釈部109と、抽出した属性を保管する属性管理部110とを備えるようにする。属性クエリ106の例を図8に示すメッセージ104に示す。図8において、<query>~</query>で囲まれた部分点線枠内が、sessionセッションID、job業務ID、serviceサービスID、time実行時刻の属性を抽出するための属性クエリである。この例では、メッセージ104がXML形式であるため、XML文書内における情報の位置を記述する標準的なXPath記法で記述したクエリを示す。属性には、当該メッセージが高重要度であることを示す値を含ませてもよい。その場合には、サービス部101は、重要度の属性を抽出するための属性クエリを付加する。≪サービス部101の動作≫図9に、サービス部101の処理の動作フローチャートを示す。まず、サービス部101は、ユーザに提供する機能企業の業務サービスなどを実行しS301、この結果をもとにメッセージ104を生成するS302。このメッセージ104の生成に当たり、サービス部101は、メッセージ104に属性情報105を添付するS303、S304。更に、サービス部101は、属性情報105をメッセージ104から取り出すための属性クエリ106を生成し、属性クエリ106をメッセージ104に添付するS305、S306。なお、サービス運用管理システム実現上の都合によっては、属性クエリ106は属性情報105の全てに対して添付してもよく、一部に対して添付してもよい。これらの処理を完了すると、サービス部101は、ESB102または他のサービスに向けて当該メッセージ104を送付しS307、処理を終了する。≪属性クエリ解釈部109の動作≫図10と図11に、サービス運用管理装置103の属性クエリ解釈部109の処理の動作フローチャートを示す。サービス運用管理装置103は、ESB102のメッセージログ107またはトランザクションログ108を入力ログの入力として受け取り、入力した入力ログが、メッセージログ107であるか、トランザクションログ108であるかを識別する。入力ログがメッセージログ107である場合、S501~S508の処理を行う。入力ログが一般的な形式のトランザクションログ108図7左側である場合、S410~S417の処理を行う。入力ログが特殊な形式のトランザクションログ108図7右側である場合、S404~S407の処理を行う。入力ログがトランザクションログ108である識別は、例えば、メッセージログ107及びメッセージ104がXMLであり、トランザクションログ108が構造を持たないテキスト情報である場合、図8のメッセージの例において1行目が<XMLversion...>であるかどうか判定することにより行うことができる。1行目が<XMLversion...>であれば、メッセージログ107及びメッセージ104であると判断する。1行目が<XMLversion...>でなければ、トランザクションログ108であると判断する。サービス運用管理装置103は、ESB102のメッセージログ107またはトランザクションログ108を入力ログの入力として受け取りS401、入力した入力ログがメッセージログ107であるか否かを識別する。次に、入力ログが、メッセージログ107であるか、トランザクションログ108であるかを識別するS402。S402において入力ログがメッセージログ107でない場合、属性クエリ解釈部109は、図7の一般的なESB102のログのようにトランザクションログ108がメッセージログ107XMLを包含するかどうかを識別するS403。メッセージログ107XMLを包含しない場合特殊な形式のトランザクションログ108の場合、属性クエリのうち、トランザクションログ108を対象としたものと解釈し、メッセージに含まれない属性情報を切り出しS404、入力ログに記録されているサービスを取り出しS405、サービス障害検出優先実行されていないサービス障害の検出を含むをサービス障害検出部115に実行させるS406。あるいは、属性クエリ解釈部109は、自らサービス障害検出部115と同様の処理を実行してサービス障害を検出する。属性クエリ解釈部109は、S405で取り出したサービスが、入力した入力ログに記録されている最後のサービスかどうか判断しS407、最後のサービスでない場合、入力した入力ログに記録されている次のサービスについてS406を実行する。S407で最後のサービスである場合、属性クエリ解釈部109は、当該入力をログ管理部116のログ保管機能により統合ログ記憶部117に格納しS408、処理を終了する。S403で、トランザクションログ108がメッセージログ107XMLを包含する場合一般的な形式のトランザクションログ108の場合、属性クエリ解釈部109は、入力された入力ログからメッセージログXMLを切り出しS410、メッセージログのそれぞれから属性クエリ106を切り出すS411。これは例えば、サービス部101が、メッセージ中に属性クエリ106の始点終点を示す予約語を挿入することにより実現できる。属性クエリ解釈部109は、S411で、入力ログ中の最後の属性クエリ106かどうか判定しS412、最後の属性クエリ106でない場合はS410で切り出したメッセージログから属性クエリ106を取り出すS411の処理を繰り返す。S412で入力中の最後の属性クエリである場合、属性クエリ解釈部109は、属性クエリ解釈を実行するS413。これは例えば、XPath処理系を起動し図8で示した属性クエリおよびメッセージログをXPath処理系に入力することにより実現できる。この結果を受け、属性クエリ解釈部109は、属性中に当該メッセージが高重要度であることを示す値を含むかどうか確認するS414。ここで高重要度を示す値を含む場合、サービス運用管理装置103は、サービス障害検出部115によるサービス障害検出サービス実行順序不正検出を優先実行するS416。あるいは、属性クエリ解釈部109は、自らサービス障害検出部115と同様の処理を実行してサービス障害を検出する。S414で属性中に当該メッセージが高重要度を示す値を含まない場合、属性クエリ解釈部109は、当該サービスのサービス障害影響範囲をサービス障害影響範囲特定部112に算出させ、その値が閾値を超えるかどうか判断するS415。ここで閾値を超える場合、サービス運用管理装置103は、S416を実行する。すなわち、サービス運用管理装置103は、サービス障害検出部115によるサービス障害検出を優先実行するS416。あるいは、属性クエリ解釈部109は、自らサービス障害検出部115と同様の処理を実行してサービス障害を検出する。S415で閾値を超えない場合、またはS416の処理を終えた場合、属性クエリ解釈部109は、S410で取り出したメッセージが、入力中の最後のメッセージ本文であるかどうかを確認するS417。最後のメッセージでない場合、S410~S417の処理を繰り返し、最後のメッセージである場合、属性クエリ解釈部109は、当該入力をログ管理部116のログ保管機能により統合ログ記憶部117に格納しS408処理を終了する。S402において、入力ログがメッセージログ107である場合、属性クエリ解釈部109は図11の処理を行う。図11においては、まず、属性クエリ解釈部109は入力ログから属性クエリを切り出すS501。これはS411と同じ処理として実現できる。この処理を、入力ログ中の最後の属性クエリを取り出すまで繰り返すS502。次に、属性クエリ解釈部109は、取り出した属性クエリのそれぞれに対し、属性クエリ解釈を実行するS503。この処理は、S413と同様な処理として実現できる。この処理を、最後の属性クエリになるまで繰り返すS504。この結果をもとに、属性クエリ解釈部109は、メッセージログ107の含む属性に高重要度を示す値が含まれるか判断するS505。ここで高重要度を示す値が含まれる場合、サービス運用管理装置103は、サービス障害検出を優先実行するS507。S505で属性中に高重要度を示す値を含まない場合、属性クエリ解釈部109は、当該サービスの影響範囲を算出し、その値が閾値を超えるかどうか判断するS506。ここで閾値を超える場合、サービス運用管理装置103は、サービス障害検出を優先実行するS507。S506で閾値を超えない場合、属性クエリ解釈部109は、このメッセージのログに関する情報を含むトランザクションログ108が入力されるまで、収集蓄積部114またはログ管理部116でメッセージログ107を、また属性管理部110で属性の値を、それぞれ保管するS508。S507またはS508の後、属性クエリ解釈部109は図10のS409以下の処理を行う。なお、図10は、重要度の高いサービスの障害検出を、サービス障害影響範囲の広いサービスの障害検出よりもさらに優先して実行するように構成した例である。実施の都合によっては、例えばサービス障害影響範囲の広いサービスの障害検出を、重要度の高いサービスの障害検出よりも、優先して実行するように構成してもよい。また、図5のS102~S104における入力ログ中のサービスID、業務ID、セッションIDの取り出しは、サービスID、セッションID、業務IDをメッセージの属性としてメッセージ104に付加して、属性として取り出してもよい。または、図5のS102~S104における入力ログ中のサービスID、業務ID、セッションIDの取り出しは、当該メッセージにサービスID、セッションID、業務IDを取り出す属性クエリを付加し、図10と図11にかかる手順で属性クエリを実行することにより実現してもよい。以上の構成および動作により、この実施の形態は以下のような効果を奏する。属性クエリ解釈部109による動作により、ESB102の種類により異なるログ形式に依存せず属性情報を取り出し、メッセージ中の属性で示されたサービスの重要度とサービス障害影響範囲特定部112の算出するサービス障害の影響範囲との何れか又は両方をパラメータとして、サービス障害検出の優先度を決定することが可能となる。以上のように、実施の形態1~3では、機能をユーザに提供する過程でメッセージを交換するコンピュータソフトウェアであるサービスの障害を検出するサービス運用管理装置103を説明した。サービス運用管理装置103は、サービス実行順序の定義、およびサービスの集合である業務とサービスの対応関係の定義を管理するサービス構成情報管理部111と、サービス構成情報管理部の情報をもとに、あるサービスにおいて障害が発生した場合に影響を受けるサービスの範囲を算出するサービス障害影響範囲特定部112と、サービス同士のメッセージ中継を行うミドルウェアの処理の記録であるトランザクションログ108およびサービス同士のメッセージのログを収集蓄積する収集蓄積部114と、種類の異なるログと当該ログの属性情報を関連付けて蓄積し管理するログ管理部116と、上記ログからサービスの実行された順序を検出し、サービスの実行された順序とサービス構成情報管理部の持つサービス実行順序の定義を比較することによりサービス実行順序不正を検出するサービス障害検出部115とを備えたことを特徴とする。また、サービス運用管理装置103は、ログ本文と、当該ログを生成したサービスを識別する情報、および、連続して実行する一連のサービスを識別するセッションの情報、および、当該ログを生成したサービスの属す業務が次に実行する可能性のあるサービスの識別情報のリストをサービス構成情報管理部111に関連付けて保管している。サービス障害検出部115、あるログからサービス実行順序不正を検出する処理の際、不正検出処理対象となっているログと同じセッションで直前に実行したサービスのログに関連付けられた、当該直前に実行したサービスが次に実行する可能性のあるサービスおよび業務の識別情報のリストをサービス構成情報管理部111から取り出し、不正検出処理の対象となっているログのサービスおよび業務の識別情報と比較することにより、サービス実行順序不正を検出する。実施の形態1~3では、サービス運用管理システム100は、機能をユーザに提供する過程でメッセージを交換するコンピュータソフトウェアとハードウェアであるサービス部101と、サービス同士のメッセージ中継を行うとともに、個々の処理を記録するミドルウェアと、前述したサービス運用管理装置と、を持ち、サービス運用管理装置103は、トランザクションログ108、メッセージのログを、サービス構成情報管理部111の保管するサービス実行順序定義情報と照合し、サービス障害影響範囲特定部112の算出するサービス障害の影響範囲の広いサービスの実行順序不正を優先的に検出することを特徴とする。サービス障害影響範囲特定部112は、サービス構成情報管理部111の情報をもとに、あるサービスにおいて障害が発生した場合に影響を受けるサービスの範囲を算出する。サービス障害影響範囲特定部112は、サービス間の階層情報あるサービス親サービスが他のサービス子サービスを呼び出す関係、および同じ親サービスに呼び出されたサービス群兄弟サービスの関係の情報をもとに、サービス障害影響範囲を特定する。サービス障害影響範囲特定部112は、障害の発生したサービスに初期値を付与し、また当該サービスを呼ぶサービスおよび当該サービスから呼び出されるサービスは呼び出しごとに値が減算または加算されるものとするよう構成した解析優先度スコアをもとに、サービス障害影響範囲を算出することを特徴とする。サービス運用管理装置は、前述のミドルウェアのログおよびメッセージの属性からサービス障害を検出するのに必要な、サービス障害定義を保管するサービス障害定義管理部113と、サービス障害定義管理部113よりサービス障害定義情報を取り出し、前述のログおよびメッセージおよびそれらの属性との照合を行いサービスで発生した障害を検出するサービス障害検出部115と、を備え、サービス部101はメッセージ104に、サービス障害を検出するのに必要な付加情報である属性情報105を付加し、属性クエリ解釈部109において、メッセージのログから属性を抽出し、属性クエリ解釈部109が、当該属性情報およびトランザクションログ108、メッセージのログ、属性の値を、サービス障害定義管理部113の保管するサービス障害定義情報、およびサービス構成情報管理部111の保管するサービス実行順序定義情報と照合し、サービス障害影響範囲特定部112の算出するサービス障害の影響範囲の広いサービス、の障害を優先的に検出することを特徴とする。サービス部101がメッセージに付加する属性のうちに、当該サービスの重要度に関する情報を含み、サービス実行順序不正またはその他のサービス障害検出にあたっては、サービス障害影響範囲に加え、サービスの重要度を、サービス障害検出処理の優先度決定のパラメータとして用いることを特徴とする。属性クエリ解釈部109は、サービス同士の授受するメッセージに付加された属性、および当該属性をメッセージより抽出するための属性クエリを、当該メッセージより抽出し、また属性クエリを解釈し属性の値を抽出する。属性クエリ解釈部109は、ミドルウェアにおいてメッセージのログがトランザクションログ108本文に含まれていても、属性クエリを解釈することにより当該属性をメッセージより抽出する。また、メッセージのログがトランザクションログ108とは別のファイルとして管理されていても、明示的な設定変更を行わずに、当該属性をメッセージより抽出する。属性クエリ解釈部109は、メッセージ中の属性で示されたサービスの重要度、またはサービス障害影響範囲特定部の算出するサービス障害の影響範囲をパラメータとして算出した優先度に従いサービス障害を検出する。図12は、実施の形態1~3におけるサービス部101、サービス運用管理装置103の外観の一例を示す図である。図12において、サービス部101又はサービス運用管理装置103は、システムユニット910、CRTCathodeRayTubeやLCD液晶の表示画面を有する表示装置901、キーボード902KeyBoard:K/B、マウス903、FDD904FlexibleDiskDrive、コンパクトディスク装置905CDD、プリンタ装置906、スキャナ装置907などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。システムユニット910は、コンピュータであり、ファクシミリ機932、電話器931とケーブルで接続され、また、ローカルエリアネットワーク942LAN、ゲートウェイ941を介してインターネット940に接続されている。図13は、実施の形態1~3におけるサービス部101、ESB102、サービス運用管理装置103のハードウェア資源の一例を示す図である。図13において、サービス部101、ESB102、サービス運用管理装置103は、プログラムを実行するCPU911CentralProcessingUnit、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいうを備えている。CPU911は、バス912を介してROM913、RAM914、通信ボード915、表示装置901、キーボード902、マウス903、FDD904、CDD905、プリンタ装置906、スキャナ装置907、磁気ディスク装置920と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置920の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、磁気ディスク装置920の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。通信ボード915、キーボード902、スキャナ装置907、FDD904などは、入力部、入力装置の一例である。また、通信ボード915、表示装置901、プリンタ装置906などは、出力部、出力装置の一例である。通信ボード915は、ファクシミリ機932、電話器931、LAN942等に接続されている。通信ボード915は、LAN942に限らず、インターネット940、ISDN等のWANワイドエリアネットワークなどに接続されていても構わない。インターネット940或いはISDN等のWANに接続されている場合、ゲートウェイ941は不用となる。磁気ディスク装置920には、オペレーティングシステム921OS、ウィンドウシステム922、プログラム群923、ファイル群924が記憶されている。プログラム群923のプログラムは、CPU911、オペレーティングシステム921、ウィンドウシステム922により実行される。上記プログラム群923には、実施の形態1~3の説明において~部として説明する機能を実行するプログラムが記憶されている。プログラムは、CPU911により読み出され実行される。ファイル群924には、実施の形態1~3の説明において、~の判定結果、~の計算結果、~の処理結果として説明する情報やデータや信号値や変数値やパラメータが、~ファイルや~データベースの各項目として記憶されている。~ファイルや~データベースは、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出検索参照比較演算計算処理出力印刷表示などのCPUの動作に用いられる。抽出検索参照比較演算計算処理出力印刷表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。また、実施の形態1~3の説明において説明したフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、RAM914のメモリ、FDD904のフレキシブルディスク、CDD905のコンパクトディスク、磁気ディスク装置920の磁気ディスク、その他光ディスク、ミニディスク、DVDDigitalVersatileDisk等の記録媒体に記録される。また、データや信号は、バス912や信号線やケーブルその他の伝送媒体によりオンライン伝送される。また、実施の形態1~3の説明において~部として説明したものは、~回路、~装置、~機器、~手段であってもよく、また、~ステップ、~手順、~処理であってもよい。すなわち、~部として説明したものは、ROM913に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子デバイス基板配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU911により読み出され、CPU911により実行される。すなわち、プログラムは、実施の形態1~3で述べた~部としてコンピュータを機能させるものである。あるいは、実施の形態1~3で述べた~部の手順や方法をコンピュータに実行させるものである。"