(57)【要約】      （修正有）【課題】ビジネス環境の変化やＳＬＡの充足状況に応じて柔軟に機能・性能・信頼性といったサービスレベルを制御するアプリケーション運用管理方法を得る。【解決手段】業務アプリケーション100全体またはその一部は、部品であるソフトウェア・コンポーネントC1〜C3の組み合わせで構成される。個々のコンポーネントは、コンポーネントDBに格納されており、必要に応じて稼動環境にローディングされる。アプリケーションによるサービスは、システム運用ポリシー管理部300によりそのポリシーが管理されて実施される。アプリケーションの稼動状況は、コンポーネント毎にランタイム・アプリケーション運用管理部200により監視され、結果が監視履歴として蓄積される。監視履歴とシステム運用ポリシーとを照らし合わせて業務アプリケーションの状態を診断し、この診断結果にもとづいてアプリケーションを構成するコンポーネントの制御を行う。【選択図】図１
2006252189.tif 000002
【特許請求の範囲】
【請求項１】
業務アプリケーションの全体またはその一部をソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構成した業務アプリケーションの運用管理を行うアプリケーション運用管理システムにおいて、個々のコンポーネントをコンポーネントＤＢに格納しておき、必要に応じてアプリケーションの実行環境にローディングしたり、実行環境からコンポーネントＤＢに保存するコンポーネント保存手段と、コンポーネント毎の運用履歴を蓄積・管理するコンポーネント管理手段と、業務アプリケーションの提供者であるサービス提供者と業務アプリケーションの利用者であるサービス利用者との間で取り決めた業務アプリケーションが提供する機能・性能・信頼性の品質であるサービスレベルに関する合意契約に基づいて、稼動中の業務アプリケーションの品質をコンポーネント毎に監視する業務アプリケーション監視手段と、前記合意契約に基づいて監視結果を診断するコンポーネント診断手段と、診断結果に従ってコンポーネントを制御するコンポーネント制御手段とを備えることを特徴とするアプリケーション運用管理システム。
【請求項２】
前記業務アプリケーション監視手段は、前記合意契約に基づいて、前記ソフトウェア・コンポーネントの状態値あるいは状態値の履歴を計測・解析することにより、当該コンポーネントを監視することを特徴とする請求項１記載のアプリケーション運用管理システム。
【請求項３】
前記業務アプリケーション監視手段は、前記合意契約及び監視結果に基づいて、前記ソフトウェア・コンポーネント毎の監視頻度や監視方法を調整することを特徴とする請求項１記載のアプリケーション運用管理システム。
【請求項４】
前記業務アプリケーション監視手段は、前記合意契約に基づいて、ソフトウェア・コンポーネントの稼動状況をコンポーネント自身が監視し、その監視結果に基づいて当該コンポーネントが自身の監視頻度や監視方法を調整することを特徴とする請求項１記載のアプリケーション運用管理システム。
【請求項５】
前記コンポーネント診断手段は、前記合意契約、個々のソフトウェア・コンポーネントの状態値、状態値の履歴、システム運用者が定めたシステム運用ルールを照合することにより、当該コンポーネントに対して制御を行うべきか否かを判断することを特徴とする請求項１記載のアプリケーション運用管理システム。
【請求項６】
前記コンポーネント制御手段は、診断結果によって特定された稼動中のコンポーネントと予め作成しておいた代替コンポーネントとを交換する制御、診断によって特定された稼動中のコンポーネントを複製し複製元コンポーネントと複製されたコンポーネントとを並列稼動する制御、診断によって特定された稼動中の複数コンポーネントの配置を互いに交換する制御、診断によって特定された稼動中の複数コンポーネントを閉塞または再起動する制御、あるいは、診断によって特定された連続する２つのコンポーネント間に予め作成しておいたコンポーネントを挿入する制御を行うことを特徴とする請求項１記載のアプリケーション運用管理システム。
【請求項７】
業務アプリケーションの全体またはその一部をソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構成した業務アプリケーションの運用管理を行うアプリケーション運用管理システムによって実行されるアプリケーション運用管理方法において、個々のコンポーネントをコンポーネントＤＢに格納しておき、必要に応じてアプリケーションの実行環境にローディングしたり、実行環境からコンポーネントＤＢに保存するステップと、コンポーネント毎の運用履歴を蓄積・管理するステップと、業務アプリケーションの提供者であるサービス提供者と業務アプリケーションの利用者であるサービス利用者との間で取り決めた業務アプリケーションが提供する機能・性能・信頼性の品質であるサービスレベルに関する合意契約に基づいて、稼動中の業務アプリケーションの品質をコンポーネント毎に監視するステップと、前記合意契約に基づいて監視結果を診断するステップと、診断結果に従ってコンポーネントを制御するステップとを有することを特徴とするアプリケーション運用管理方法。
【請求項８】
業務アプリケーションの全体またはその一部をソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構成した業務アプリケーションの運用管理を行う処理をコンピュータに実行させるためのアプリケーション運用管理プログラムであって、個々のコンポーネントをコンポーネントＤＢに格納しておき、必要に応じてアプリケーションの実行環境にローディングしたり、実行環境からコンポーネントＤＢに保存する処理と、コンポーネント毎の運用履歴を蓄積・管理する処理と、業務アプリケーションの提供者であるサービス提供者と業務アプリケーションの利用者であるサービス利用者との間で取り決めた業務アプリケーションが提供する機能・性能・信頼性の品質であるサービスレベルに関する合意契約に基づいて、稼動中の業務アプリケーションの品質をコンポーネント毎に監視する処理と、前記合意契約に基づいて監視結果を診断する処理と、診断結果に従ってコンポーネントを制御する処理とをコンピュータに実行させることを特徴とするアプリケーション運用管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション運用管理システム及び方法に係り、特に、コンポーネント化されたソフトウェア部品（ソフトウェア・コンポーネント）を組み合わせて開発されたアプリケーションの稼動状況を監視し、監視結果を診断し、診断結果に基づいてアプリケーションを制御するアプリケーション運用管理システム及び方法に関する。
【背景技術】
【０００２】
近年、企業情報システムにおいて、アウトソーシングやＳＬＡ(Service Level Agreement）の普及と多様化に伴い、ビジネス環境変化やＳＬＡの充足状況に対して柔軟性の高いシステムの実現が望まれている。これらを実現するためには、再利用可能なソフトウェア・コンポーネントの疎結合によって業務アプリケーションを構成すると共に、業務アプリケーションの稼動状況を監視、診断、制御することにより、状況に応じて動的にアプリケーションが提供する機能や性能などのサービスレベルを柔軟に制御することが必要になる。
【０００３】
情報システムの稼動状況を監視して状況に応じた制御を行う従来技術として、例えば、特許文献１、特許文献２、特許文献３等に記載された技術が知られている。
【０００４】
特許文献１に記載の従来技術は、アプリケーションを構成するオブジェクト・インスタンス毎に監視プロセスを割り当て、これにより全てのオブジェクト・インスタンスの実行状況を監視する方法に関するものである。そして、この従来技術は、監視プロセスが、オブジェクト・インスタンスの異常を検出すると、これを管理システムに通知し、管理システムが当該オブジェクト・インスタンスの試験を行い、試験の結果、異常と診断されたオブジェクト・インスタンスに対して、当該オブジェクト・インスタンスを代用オブジェクト・インスタンスと交換するというものである。
【０００５】
特許文献２に記載の従来技術は、マルチプロセス・マルチスレッド構成のシステムにおいて、動作中のスレッドを動作終了を待って待機させ、動作中でないスレッドをそのまま待機させておき、全てのスレッドが待機状態となった後にコンポーネントの動的な置換の処理を行うというものである。
【０００６】
さらに、特許文献３に記載の従来技術は、コンポーネントベース・アプリケーションにおいて、システム運用時に、システムの信頼性と性能とを監視するために、ソフトウェア・コンポーネントに処理時間を測定するコードを埋め込み、これにより処理時間を測定し、測定された処理時間が予め設定された閾値を超過した場合に、当該コンポーネントを異常状態と判定し、当該コンポーネントを閉塞したり、再起動する等の対処を行うというものである。
【特許文献１】特開平８−７７１２０号公報
【特許文献２】特開２００１−２９０６３７号公報
【特許文献３】特開２００２−８２９２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
前述した従来技術による情報システム運用管理技術は、いずれも、アプリケーションが正常に稼動しているか否かといった観点でのアプリケーションの異常監視と、異常検出時の再起動や閉塞制御等のリカバリ制御とに限定されており、アプリケーションの機能や処理性能を状況に応じて適切に切り替えるといった要求に対応できていないというう問題点を有している。
【０００８】
本発明の目的は、前述した従来技術の問題点を解決し、ビジネス環境の変化やＳＬＡの充足状況に応じて柔軟に機能・性能・信頼性といったサービスレベルを制御することを可能としたアプリケーション運用管理システム及び方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明によれば前記目的は、業務アプリケーションの全体またはその一部をソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構成した業務アプリケーションの運用管理を行うアプリケーション運用管理システムにおいて、個々のコンポーネントをコンポーネントＤＢに格納しておき、必要に応じてアプリケーションの実行環境にローディングしたり、実行環境からコンポーネントＤＢに保存するコンポーネント保存手段と、コンポーネント毎の運用履歴を蓄積・管理するコンポーネント管理手段と、業務アプリケーションの提供者であるサービス提供者と業務アプリケーションの利用者であるサービス利用者との間で取り決めた業務アプリケーションが提供する機能・性能・信頼性の品質であるサービスレベルに関する合意契約に基づいて、稼動中の業務アプリケーションの品質をコンポーネント毎に監視する業務アプリケーション監視手段と、前記合意契約に基づいて監視結果を診断するコンポーネント診断手段と、診断結果に従ってコンポーネントを制御するコンポーネント制御手段とを備えることにより達成される。
【００１０】
また、前記目的は、業務アプリケーションの全体またはその一部をソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構成した業務アプリケーションの運用管理を行うアプリケーション運用管理システムにおいて、個々のコンポーネントをコンポーネントＤＢに格納しておき、必要に応じてアプリケーションの実行環境にローディングしたり、実行環境からコンポーネントＤＢに保存するステップと、コンポーネント毎の運用履歴を蓄積・管理するステップと、業務アプリケーションの提供者であるサービス提供者と業務アプリケーションの利用者であるサービス利用者との間で取り決めた業務アプリケーションが提供する機能・性能・信頼性の品質であるサービスレベルに関する合意契約に基づいて、稼動中の業務アプリケーションの品質をコンポーネント毎に監視するステップと、前記合意契約に基づいて監視結果を診断するステップと、診断結果に従ってコンポーネントを制御するステップとを有することにより達成される。
【００１１】
さらに、前記目的は、業務アプリケーションの全体またはその一部をソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構成した業務アプリケーションの運用管理を行うアプリケーション運用管理プログラムであって、個々のコンポーネントをコンポーネントＤＢに格納しておき、必要に応じてアプリケーションの実行環境にローディングしたり、実行環境からコンポーネントＤＢに保存する処理と、コンポーネント毎の運用履歴を蓄積・管理する処理と、業務アプリケーションの提供者であるサービス提供者と業務アプリケーションの利用者であるサービス利用者との間で取り決めた業務アプリケーションが提供する機能・性能・信頼性の品質であるサービスレベルに関する合意契約に基づいて、稼動中の業務アプリケーションの品質をコンポーネント毎に監視する処理と、前記合意契約に基づいて監視結果を診断する処理と、診断結果に従ってコンポーネントを制御する処理とを実行させることにより達成される。
【発明の効果】
【００１２】
本発明によれば、ＩＴベンダが業務アプリケーションを提供・運用するアウトソーシングビジネスを顧客とのＳＬＡ契約にもとづいて実施する際に、ビジネス環境やＳＬＡの充足状況に応じて業務アプリケーションのサービスレベルを柔軟に制御することが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明によるアプリケーション運用管理システム及び方法の実施形態を図面により詳細に説明する。以下に説明する本発明の実施形態は、企業情報システムを構成する業務アプリケーション・コンポーネントをアプリケーションの稼動状況とシステム運用ポリシーとに応じて自動的に制御するものとした例である。
【００１４】
図１は本発明の一実施形態によるアプリケーション運用管理システムの構成を示すブロック図であり、本発明を企業情報システムに適用し、業務アプリケーションのサービスレベルを制御可能とした例である。図１において、１００は業務アプリケーション、２００はランタイム・アプリケーション運用管理部、２１０はアプリケーション監視部、２２０はアプリケーション診断部、２３０はアプリケーション制御部、３００はシステム運用ポリシー管理部、４００はアプリケーション・ライフサイクル管理部、５００はシステムプラットフォーム運用管理部、６００は業務データベース（ＤＢ）、７００はシステム運用管理端末、８００はシステム運用ポリシー管理端末、Ｃ１、Ｃ２、Ｃ２’、Ｃ３はソフトウェア・コンポーネントである。
【００１５】
図１に示す本発明の実施形態は、ソフトウェア・コンポーネントＣ１、Ｃ２、Ｃ３等から構成される業務アプリケーション１００、業務アプリケーションを構成する個々のアプリケーション・コンポーネントを監視・診断・制御するランタイム・アプリケーション運用管理部２００、経営ポリシーやＳＬＡにもとづいて策定した運用ポリシーを管理するシステム運用ポリシー管理部３００、業務アプリケーションを構成する個々のコンポーネントの属性情報や運用履歴等を管理するアプリケーション・ライフサイクル管理部４００、ハードウェアやＯＳ等のシステムプラットフォームの稼動状況を運用管理するシステムプラットフォーム運用管理部５００、業務アプリケーションが利用する様々な企業情報を管理する業務ＤＢ６００、ランタイム・アプリケーション運用管理部の監視、診断、制御の状況を監視し、オペレータが必要に応じて介入するためのシステム運用管理端末７００、システム運用ポリシーの充足状況を表示し、また、必要に応じてオペレータによりポリシー変更の設定を行うことができるシステム運用ポリシー管理端末８００から構成される。そして、本発明の実施形態での中枢を成すランタイム・アプリケーション運用管理部２００は、アプリケーション監視部２１０、アプリケーション診断部２２０、アプリケーション制御部２３０を備えて構成されている。
【００１６】
前述において、システム運用管理端末７００、システム運用ポリシー管理端末８００及びその他の部分のそれぞれは、ＣＰＵ、主メモリ、ＨＤＤ等の記憶装置を備えて構成されるよく知られたコンピュータの中に構築されており、以下に説明する本発明の実施形態での各種の処理は、ＣＰＵが主メモリにロードされた処理プログラムを実行することにより実施される。また、システム運用管理端末７００、システム運用ポリシー管理端末８００は、１つの管理端末として構成されていてもよい。
【００１７】
以下、まず、ランタイム・アプリケーション運用管理部２００の構成要素であるアプリケーション監視部２１０、アプリケーション診断部２２０、アプリケーション制御部２３０の機能概要を説明する。
【００１８】
（１）アプリケーション監視部
アプリケーション監視部２１０は、監視対象の業務コンポーネント（以下、アプリケーション・コンポーネントまたはコンポーネントという）群とそれぞれ双方向通信を行い、監視対象のコンポーネントが必要に応じて生成する監視オブジェクトからの監視結果の報告メッセージを受信することにより、コンポーネント毎の状態値や稼動履歴を収集・蓄積する。また、蓄積した監視履歴から何らかの問題を検出した場合にはアプリケーション診断部２２０に対して検出した問題点の診断を要求する。
【００１９】
図２はアプリケーション監視部２１０の構成を示すブロックである。図２において、２１１は対業務アプリケーション通信制御部、２１２は対システム運用管理端末通信制御部、２１３は対アプリケーション診断部通信制御部、２１４はアプリケーション監視プログラム、２１５はアプリケーション監視履歴ＤＢ、２１６はアプリケーション監視履歴管理部、２１７はアプリケーション監視条件管理プログラム、２１８はアプリケーション監視条件ＤＢ、２１９はアプリケーション監視条件管理部である。
【００２０】
アプリケーション監視部２１０は、業務アプリケーション１００との通信を制御する対業務アプリケーション通信制御部２１１と、システム運用管理端末７００との通信を制御する対システム運用管理端末通信制御部２１２と、アプリケーション診断部２２０との通信を制御する対アプリケーション診断部通信制御部２１３と、アプリケーション監視プログラム２１４及びアプリケーション監視履歴ＤＢ２１５からなるアプリケーション監視履歴管理部２１６と、アプリケーション監視条件管理プログラム２１７及びアプリケーション監視条件ＤＢ２１８からなるアプリケーション監視条件管理部２１９とにより構成される。なお、オペレータは、必要に応じて、システム運用管理端末７００からアプリケーション監視条件管理プログラム２１７を利用して、個々のコンポーネントの監視条件を修正することができる。
【００２１】
図３はアプリケーション監視部２１０の処理動作を説明するフローチャートであり、次に、図３に示すフローを参照してアプリケーション監視部２１０の処理の概要について説明する。なお、ここでは、アプリケーション監視処理を、アプリケーション監視部側の処理１０００と、監視対象となるコンポーネント側の処理２０００とに分割して説明する。
【００２２】
（１）まず、アプリケーション監視条件プログラム２１７は、アプリケーション監視条件ＤＢ２１８を参照して、監視対象コンポーネントを決定する。なお、ここでは、業務コンポーネントＣ２を監視対象に選定したことを想定する（ステップ１００１、１００２）。
【００２３】
図４はアプリケーション監視条件ＤＢ２１８の構成例を示す図であり、ここで、アプリケーション監視条件ＤＢ２１８について説明する。アプリケーション監視条件ＤＢ２１８には、アプリケーション監視条件がコンポーネントを特定するコンポーネントＩＤ毎に定義されており、監視条件の項目としては、図４に示すように、監視要否を設定する「監視要否フラグ」、緊急・通常など監視の重要度を設定する「監視モード」、監視モード毎の監視時隔を設定する「監視時隔」、「前回監視時刻」、「次回監視予定時刻」、監視メソッド名を設定する「監視メソッド」、値を取得する変数名を設定する「監視対象変数」、診断要求の要否判断の指標を設定する「判断基準」等が定義されている。
【００２４】
なお、説明している実施形態においては、監視条件ＤＢに設定された監視予定時刻に従って監視対象を決定しているが、全コンポーネントに対して周期的に監視を行う方法や、監視優先度のようなパラメータによって監視する順序を決定する方法であってもよい。
【００２５】
（２）次に、アプリケーション監視プログラム２１７は、監視対象コンポーネント、ここでは、コンポーネントＣ２に対して監視要求メッセージを送信する。なお、監視要求メッセージには、コンポーネントＩＤを検索キーとしてアプリケーション監視条件ＤＢ２１８から取得した各種の監視条件が含まれる（ステップ１００３）。
【００２６】
（３）一方、監視対象の業務コンポーネントＣ２は、ステップ１００３の処理でアプリケーション監視プログラム２１７から送信されてきた監視要求メッセージを受信すると、受信したメッセージに含まれる監視方法に基づいて監視メソッドを起動し、自コンポーネントの稼動情報を収集する（ステップ２００１、２００２）。
【００２７】
（４）次に、監視対象の業務コンポーネントＣ２は、ステップ２００２の処理により収集した稼動情報を監視結果メッセージとしてアプリケーション監視部２１０に送信する（ステップ２００３）。
【００２８】
（５）アプリケーション監視部２１０は、ステップ２００３での処理により業務コンポーネントＣ２から送信されてきた監視結果メッセージを受信すると、その受信内容をアプリケーション監視プログラム２１４、アプリケーション監視条件管理プログラム２１７の双方に通知する（ステップ１００４）。
【００２９】
（６）ステップ１００４の処理での通知をトリガーとして、アプリケーション監視条件管理プログラム２１７は、アプリケーション監視条件ＤＢ２１８の前回監視時刻と次回監視予定時刻とを更新すると共に、監視結果に監視条件の変更要求が含まれる場合には、その要求に従ってアプリケーション監視条件ＤＢ２１８を更新する。なお、アプリケーションの監視条件は、対システム運用管理端末通信制御部２１２を介して、システム運用管理端末７００からオペレータが適宜修正することも可能である（ステップ１００５）。
【００３０】
（７）次に、アプリケーション監視プログラム２１４は、業務コンポーネントＣ２から送信されてきた監視結果メッセージに従って、アプリケーション監視履歴ＤＢ２１５を更新する（ステップ１００６）。
【００３１】
図５はアプリケーション監視履歴ＤＢ２１５の構成例を示す図であり、ここで、アプリケーション監視履歴ＤＢ２１５について説明する。アプリケーション監視履歴は、コンポーネントを特定するコンポーネント毎、かつ、時系列に設定される監視ＩＤ毎に管理される。監視結果情報としては、図５に示すように、処理種別毎の平均処理時間を示す「平均処理時間」、入力元コンポーネントからの受信したメッセージキューの状態を示す「入力メッセージキュー情報」、出力先コンポーネントへ送信するメッセージキューの状態を示す「出力メッセージキュー情報」、個々のコンポーネント毎に定義された監視対象変数の値を示す「監視対象変数情報」等がある。
【００３２】
（８）次に、アプリケーション監視プログラム２１４は、アプリケーション監視履歴ＤＢ２１５を参照し、監視対象コンポーネントの最新の監視結果と監視履歴及び他コンポーネントの監視履歴を参照して、監視対象コンポーネントの診断要否を判断する。診断要否の判断に際しては、対システム運用管理端末通信制御部２１２を介してシステム運用管理端末７００からオペレータが適宜介入することも可能である。ここで、診断不要と判断された場合、ステップ１００１からの処理に戻って処理を繰り返す（ステップ１００７）。
【００３３】
（９）ステップ１００７の判断で、診断が必要と判断された場合、監視対象コンポーネントの監視結果や監視履歴をもとに診断要求メッセージを作成し、作成した診断メッセージを対アプリケーション診断部通信制御部２１３を介してアプリケーション診断部２２０に送信する（ステップ１００８）。
【００３４】
なお、ここで説明している実施形態では、監視スケジュール及び監視対象の決定を業務コンポーネント外で行い、監視処理を業務コンポーネント内のメソッドを利用して行うものとしているが、監視対象や監視方法の決定を業務コンポーネント自身が自己判断する構成としてもよい。
【００３５】
図６は前述の処理でアプリケーション診断部２２０に送信する診断要求メッセージの構成例を説明する図である。診断要求メッセージは、コンポーネントの識別子である「コンポーネントＩＤ」、監視情報の識別子である「監視ＩＤ」、処理種別毎の平均処理時間を示す「平均処理時間」、監視対象コンポーネントが入力元コンポーネントから受信したメッセージキューの状態を示す「入力メッセージキュー」、監視対象コンポーネントが出力先コンポーネントへ送信したメッセージキューの状態を示す「出力メッセージキュー」、個々のコンポーネント毎に定義された監視対象となる変数名を定義する「監視対象」、監視対象の変数値の変動履歴を示す「監視履歴」、「診断要求理由」、「監視条件変更要求」等から構成される。
【００３６】
（２）アプリケーション診断部
アプリケーション診断部２２０は、アプリケーション監視部２１０から受信した診断要求メッセージ、業務サービスの提供者と利用者との間で取り決めた業務アプリケーションのサービスレベルに関する合意契約に基づいて定められたシステム運用ポリシー、及び、アプリケーション診断ルールに基づいてアプリケーションの制御要否を判断する。また、アプリケーション診断部２２０は、アプリケーションの制御が必要な場合、必要に応じてオペレータ判断を加味しながら制御内容を決定し、アプリケーション制御部２３０に対してアプリケーションの制御遂行を要求する。
【００３７】
図７はアプリケーション診断部２２０の構成例を示すブロック図である。図７において、２２１は対システム運用管理端末通信制御部、２２２は対システム運用ポリシー管理部通信制御部、２２３は対アプリケーション監視部通信制御部、２２４は対アプリケーション制御部通信制御部、２２５はアプリケーション診断プログラム、２２６はアプリケーション診断履歴ＤＢ、２２７はアプリケーション診断管理部、２２８はアプリケーション診断ルール管理プログラム、２２９はアプリケーション診断ルールＤＢ、２２Ａはアプリケーション診断ルール管理部である。
【００３８】
アプリケーション診断部２２０は、システム運用管理端末７００との通信を制御する対システム運用管理端末通信制御部２２１と、システム運用ポリシー管理部３００との通信を制御する対システム運用ポリシー管理部通信制御部２２２と、アプリケーション監視部２１０との通信を制御する対アプリケーション監視部通信制御部２２３と、アプリケーション制御部２３０との通信を制御する対アプリケーション制御部通信制御部２２４と、アプリケーション診断プログラム２２５及びアプリケーション診断履歴ＤＢ２２６からなるアプリケーション診断管理部２２７と、アプリケーション診断ルール管理プログラム２２８及びアプリケーション診断ルールＤＢ２２９からなるアプリケーション診断ルール管理部２２Ａとにより構成される。なお、オペレータは必要に応じて、システム運用管理端末７００からアプリケーション診断ルール管理プログラム２３０を利用することによりアプリケーション診断ルールを修正することができる。
【００３９】
図８はアプリケーション診断部２２０の処理動作を説明するフローチャートであり、次に、図８に示すフローを参照して、アプリケーション診断部での処理動作を説明する。
【００４０】
（１）アプリケーション診断部２２０の対アプリケーション監視部通信制御部２２３は、アプリケーション監視部２１０から送信された診断要求メッセージを受信すると、受信した診断要求メッセージをアプリケーション診断プログラム２２５に渡す（ステップ１００９）。
【００４１】
（２）次に、アプリケーション診断プログラム２２５は、ステップ１００９の処理で渡された診断要求メッセージを受領すると対システム運用ポリシー管理部通信制御部２２２を介して、システム運用ポリシー管理部３００のシステム運用ポリシーＤＢを参照する（ステップ１０１０）。
【００４２】
図９はシステム運用ポリシー管理部３００の構成例を示すブロック図、図１０はシステム運用ポリシーＤＢの構成例を説明する図であり、ここで、システム運用ポリシー管理部３００の構成例とシステム運用ポリシーＤＢの構成例とについて説明する。図９において、３０１は対ランタイム・アプリケーション運用管理部通信制御部、３０２は対システム運用ポリシー管理端末通信制御部、３０３は対システムプラットホーム運用管理部通信制御部、３０４はシステム運用ポリシー管理プログラム、３０５はシステム運用ポリシーＤＢ、３０６はシステム運用ポリシー制御部である。
【００４３】
システム運用ポリシー管理部３００は、図９に示すように、ランタイム・アプリケーション運用管理部２００との通信を制御する対ランタイム・アプリケーション運用管理部通信制御部３０１と、システム運用ポリシー管理端末８００との通信を制御する対システム運用ポリシー管理端末通信制御部３０２と、システムプラットホーム運用管理部５００との通信を制御する対システムプラットホーム運用管理部通信制御部３０３と、システム運用ポリシー管理プログラム３０４及びシステム運用ポリシーＤＢ３０５からなるシステム運用ポリシー制御部３０６とにより構成される。
【００４４】
前述において、システム運用ポリシーＤＢ３０５は、業務アプリケーションによるサービスの提供者とサービス利用者との間で取り決めた業務アプリケーションのサービスレベルに関する合意内容にもとづいて設定されるものである。そして、個々のポリシーは、図１０に示すように、各ポリシーを特定するポリシーＩＤによって管理され、ポリシーＩＤ毎に、ポリシー項目、目標値、目標達成時のボーナス規約、目標未達時のペナルティ規約が設定される。具体的なポリシー項目としては、サービス稼動率、平均応答時間、平均スループット等のようなシステムの信頼性、処理性能の指標だけでなく、エンドユーザーによるサービスへのアクセス数や、エンドユーザによる注文件数といったシステムの収益性の指標を設定することもできる。なお、オペレータは、必要に応じて、システム運用ポリシー管理端末８００からシステム運用ポリシー管理プログラム３０４を利用して、システム運用ポリシーを修正することができる。
【００４５】
（３）次に、アプリケーション診断プログラム２２５は、アプリケーション診断ルール管理プログラム２２８を介してアプリケーション診断ルールＤＢ２２９の格納情報を参照する（ステップ１０１１）。
【００４６】
図１１はアプリケーション診断ルールＤＢ２２９の構成例を説明する図であり、ここで、アプリケーション診断ルールＤＢ２２９について説明する。個々のアプリケーション診断ルールは、図１１に示すように、各診断ルールを特定するルールＩＤによって管理されており、ルールＩＤ毎にＩＦ−ＴＨＥＮ形式の診断ルール、他ルールと競合した場合の優先度を決定するルール優先度、ルール適用時のオペレータによる判断の要否など、ルールを適用する際の制限事項を設定するルール使用制限事項が設定される。
【００４７】
（４）次に、アプリケーション診断プログラム２２５は、診断要求メッセージとシステム運用ポリシーとをアプリケーション診断ルールの条件（ＩＦ）部と照合することにより、アプリケーションの診断を実施する。照合の結果、適合するルールが存在した場合、当該ルールのＩＦ部の記載内容が診断理由となり、ＴＨＥＮ部の記載内容が診断結果となる。なお、複数の診断ルールを同時に満足する場合、優先度に従って診断内容を１つに限定してもよいし、また、複数の診断内容をオペレータに提示し、オペレータが診断内容を判断することとしてもよい（ステップ１０１２）。
【００４８】
なお、ここで説明している本発明の実施形態においては、ルールＩＤが０００１のルールが条件に合致し、被制御コンポーネントと代替コンポーネントとを置換する制御を行う場合を想定する。
【００４９】
（５）次に、アプリケーション診断プログラム２２５は、診断内容をアプリケーション診断履歴ＤＢ２２６に格納して更新を行う（ステップ１０１３）。
【００５０】
図１２はアプリケーション診断履歴ＤＢ２２６の構成例を説明する図であり、ここで、アプリケーション診断履歴ＤＢについて説明する。アプリケーション診断履歴ＤＢ２２６は、図１２に示すように、各診断を特定する診断ＩＤによって管理され、診断ＩＤ毎に、それに対応する監視ＩＤ及び監視に関する付随情報、診断ＩＤ及び診断に関する付随情報、制御情報を格納している。
【００５１】
（６）次に、アプリケーション診断プログラム２２５は、診断内容の適用ルールＩＤを参照し、適用ルールＩＤのルール使用制限事項からオペレータによる判断要否を判定する。ここでオペレータによる判断が必要と判定された場合、アプリケーション診断部２２０は、対システム運用管理端末通信制御部２２１を介してシステム運用管理端末７００にオペレータによる判断の指示を要求する（ステップ１０１４、１０１５）。
【００５２】
（７）その後、アプリケーション診断プログラム２２５は、オペレータからの回答が入力されると、オペレータからの入力情報に従って制御要求メッセージ作成し、作成した制御要求メッセージを対アプリケーション制御部通信制御部２２４を介してアプリケーション制御部２３０に送信する（ステップ１０１６）。
【００５３】
（８）一方、ステップ１０１４の判定でオペレータによる判断が不要と判定された場合、ステップ１０１５の処理をパスし、ステップ１０１６の処理に移行して、制御要求メッセージをそのまま対アプリケーション制御部通信制御部２２４を介してアプリケーション制御部２３０に送信する。
【００５４】
図１３は制御要求メッセージの構成例を示す図である。制御要求メッセージは、前述のステップ１０１６の処理で作成されるものであり、図１３に示すように、コンポーネントＩＤ、置換、挿入、変則等の制御種別、置換コンポーネント等の制御に必要な制御付随情報、オペレータ介入情報等から構成される。
【００５５】
（３）アプリケーション制御部
アプリケーション制御部２３０は、アプリケーション診断部２２０から受信した制御要求メッセージとコンポーネント毎に設定された制御条件とに基づいて、制御対象の業務コンポーネント群と双方向通信を行うと共に、必要に応じてアプリケーションライフサイクル管理部４００からコンポーネントをローディングすることにより、置換、挿入、閉塞などの各種のコンポーネント制御を行う。また、制御実行結果を制御実行履歴として蓄積して管理する。
【００５６】
図１４はアプリケーション制御部２３０の構成を示すブロック図である。図１４において、２３１は対業務アプリケーション通信制御部、２３２は対システム運用管理端末通信制御部、２３３は対アプリケーションライフサイクル管理部通信制御部、２３４は対アプリケーション診断部通信制御部、２３５はアプリケーション制御プログラム、２３６はアプリケーション制御履歴ＤＢ、２３７はアプリケーション制御実行管理部、２３８はアプリケーション制御条件管理プログラム、２３９はアプリケーション制御条件ＤＢ、２４０はアプリケーション制御条件管理部である。
【００５７】
アプリケーション制御部２３０は、図１４に示すように、業務アプリケーション１００との通信を制御する対業務アプリケーション通信制御部２３１と、システム運用管理端末７００との通信を制御する対システム運用管理端末通信制御部２３２と、アプリケーションライフサイクル管理部４００との通信を制御する対アプリケーションライフサイクル管理部通信制御部２３３と、アプリケーション診断部２２０との通信を制御する対アプリケーション診断部通信制御部２３４と、アプリケーション制御プログラム２３５及びアプリケーション制御履歴ＤＢ２３６からなるアプリケーション制御実行管理部２３７と、アプリケーション制御条件管理プログラム２３８及びアプリケーション制御条件ＤＢ２３９からなるアプリケーション制御条件管理部２４０とにより構成される。なお、オペレータは、必要に応じて、システム運用管理端末７００からアプリケーション制御条件管理プログラム２３８を利用することにより、アプリケーションの制御条件を修正することができる。
【００５８】
図１５はアプリケーション制御部２３０の処理動作を説明するフローチャートであり、次に、図１５に示すフローを参照して、アプリケーション制御部での処理動作を説明する。
【００５９】
（１）アプリケーション制御部２３０の対アプリケーション診断部通信制御部２３４は、アプリケーション診断部２２０から送信された制御要求メッセージを受信すると、受信した制御要求メッセージをアプリケーション制御プログラム２３５に渡す（ステップ１０１７）。
【００６０】
（２）アプリケーション制御プログラム２３５は、制御要求メッセージを受け取ると、アプリケーション制御条件管理プログラム２３８を介してアプリケーション制御条件ＤＢの格納情報を参照する（ステップ１０１８）。
【００６１】
図１６はアプリケーション制御条件ＤＢ２３９の構成例を説明する図であり、ここで、アプリケーション制御条件ＤＢ２３９の構成について説明する。アプリケーション制御条件とは、コンポーネント開発フェーズにおいて、コンポーネント開発サイドの立場から個々のコンポーネントに対して設定される制御時に留意すべき制約条件であり、コンポーネントを特定するコンポーネントＩＤ毎かつ制御種別毎に制約条件が設定・管理される。これにより、アプリケーション運用者の立場から立案されたコンポーネントの制御要求を、コンポーネント開発者の立場からチェックすることが可能になり、制御を実施する上での様々なリスクを抑止する効果を期待することができる。
【００６２】
アプリケーション制御条件ＤＢ２３９は、コンポーネント毎かつ制御種別毎に制御実行時の各種の条件を格納したＤＢであり、図１６に示すように具体的な制御種別の例としては、「置換」、「複製」、「再起動」、「閉塞」等が設定され、また、具体的な条件としては、制御実行可、制御実行不可、オペレータ判断要のいずれかの条件を設定する「制御可否フラグ」、自動制御または手動制御を設定する「制御モード」、制御時の「エラー対処方法」、制御実行に要する許容時間を定義する「制御タイムアウト」等が設定される。
【００６３】
（３）次に、アプリケーション制御プログラム２３５は、制御要求メッセージの内容とアプリケーション制御条件ＤＢ２３９の内容とを照合して制御内容を最終的に確定する制御条件の検証を行う。このため、制御要求メッセージに含まれるコンポーネントＩＤと、制御種別とを参照し、当該コンポーネントＩＤと制御種別を検索キーとして制御条件ＤＢから該当する制約条件を検証する（ステップ１０１９）。
【００６４】
（４）ステップ１０１９での検証で、制約条件の制御可否フラグが制御実行可であった場合、指定された制御条件に従って制御を実行し、また、制御可否フラグが制御実行不可であった場合、制御中止の処理を行う（ステップ１０２１、１０２２）。
【００６５】
（５）また、ステップ１０１９での検証で、制御可否フラグが、オペレータ判断要であった場合、システム運用管理端末７００を介してオペレータの判断を要求する。ここで、オペレータが制御内容を承認した場合、ステップ１０２１の処理で指定された制御条件に従って制御を実行し、オペレータが制御内容を承認しなかった場合、ステップ１０２２の処理で制御中止処理を実行する（ステップ１０２０〜１０２２）。
【００６６】
（６）ステップ１０２１での処理により制御を実行した場合、制御実行結果をアプリケーション制御履歴ＤＢ２３６に格納して該アプリケーション制御履歴ＤＢ２３６更新する（ステップ１０２３）。
【００６７】
図１７はアプリケーション制御履歴ＤＢ２３６の構成例を説明する図である。アプリケーション制御履歴ＤＢ２３６は、制御ＩＤにより管理されており、制御ＩＤ毎に、コンポーネントＩＤ、制御種別、制御付随情報、オペレータ介入情報、制御結果等を格納している。
【００６８】
次に、本発明の実施形態で想定しているコンポーネント置換の処理を例として、被置換対象コンポーネントＣ２を代替コンポーネントＣ２’に置換する処理について説明する。
【００６９】
図１８はコンポーネント置換の処理動作を説明するフローチャートであり、次に、このフローを参照して、コンポーネント置換の処理動作について説明する。なお、ここでは、コンポーネント置換処理を被置換対象コンポーネントの処理３０００と、代替コンポーネントの処理４０００とに分割して説明する。また、ここでの処理において、非稼動中のコンポーネントは、アプリケーションライフサイクル管理部４００内のコンポーネントＤＢに格納され、稼動を開始する際にコンポーネントＤＢからローディングされるものとしている。
【００７０】
図１９はアプリケーションライフサイクル管理部４００の構成を示すブロック図、図２０はコンポーネントＤＢ４０４の構成例を説明する図であり、図１８に示すフローについての説明を行う前に、図１９、図２０を参照して、アプリケーションライフサイクル管理部４００の構成とコンポーネントＤＢの構成とについて説明する。図１９において、４０１は対業務アプリケーション通信制御部、４０２は対ランタイム・アプリケーション運用制御部通信制御部、４０３はコンポーネント管理プログラム、４０４はコンポーネントＤＢ、４０５はコンポーネント管理部である。
【００７１】
アプリケーションライフサイクル管理部４００は、図１９に示すように、業務アプリケーションとの通信を制御する対業務アプリケーション通信制御部４０１、ランタイム・アプリケーション運用管理部との通信を制御する対ランタイム・アプリケーション運用制御部通信制御部４０２、コンポーネント管理プログラム４０３及びコンポーネントＤＢ４０４からなるコンポーネント管理部４０５から構成される。
【００７２】
コンポーネントＤＢ４０４は、図２０に示すように、コンポーネントの作成、運用制御、改修、削除といったコンポーネントのライフサイクルを管理するＤＢであり、コンポーネントＩＤによって管理される。そして、図２０に示すコンポーネントＤＢ４０４でのコンポーネントＩＤ毎に設定されるデータ項目としては、コンポーネント名、作成者、作成日時等の属性情報、入出力データ、処理内容、代替／被代替コンポーネント等の仕様情報、運用履歴情報、コンポーネントの実体から構成される。
【００７３】
（１）図１８に示す処理フローにおいて、非稼動中のコンポーネントは、アプリケーションライフサイクル管理部４００内のコンポーネントＤＢに格納され、稼動を開始する際にコンポーネントＤＢからローディングされるものとしているので、被置換対象コンポーネント、ここでは、コンポーネントＣ２は、コンポーネントＤＢ４０４からローディングされ、稼動を開始して稼働しているものとする（ステップ３００１、３００２）。
【００７４】
（２）ランタイム・アプリケーション運用管理部２００からの置換命令に対して、被置換コンポーネントＣ２は、コンポーネントの全てまたは一部のステートを保存する等のコンポーネント置換準備を行い、コンポーネントの運用履歴をＤＢに格納する（ステップ３００３、３００４）。
【００７５】
（３）一方、代替コンポーネントＣ２’は、置換命令をトリガーとして、コンポーネントＤＢ４０４からローディングされる（ステップ４００１）。
【００７６】
（４）被置換コンポーネントＣ２は、ステップ３００４の処理でコンポーネントの運用履歴をＤＢに格納した後、関連するコンポーネントを休止させ、自コンポーネントを閉塞すると共に、閉塞実行報告をランタイム・アプリケーション運用管理部２００に報告する（ステップ３００５）。
【００７７】
（５）ランタイム・アプリケーション運用管理部２００は、ステップ３００５での閉塞実行の報告を受けて、代替コンポーネントＣ２’の起動を行い、休止していた関連コンポーネントと代替コンポーネントＣ２’とのコネクションを確立した上で、代替コンポーネントの稼動を開始させる（ステップ４００２、４００３）。
【００７８】
（６）最後に、ステップ３００６にて、ランタイム・アプリケーション運用管理部２００は、被置換コンポーネントＣ２をコンポーネントＤＢ４０４に格納する（ステップ３００６）。
【００７９】
前述した本発明の実施形態における各処理は、処理プログラムとして構成してコンピュータに実行させることができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【産業上の利用可能性】
【００８０】
本発明で示したコンポーネントベース・アプリケーションのシステム運用管理システム及び方法は、アプリケーションの監視、運用、制御を行うアプリケーション・プラットフォーム・ソフトウェアとして利用することが可能である。
【図面の簡単な説明】
【００８１】
【図１】本発明の一実施形態によるアプリケーション運用管理システムの構成を示すブロック図である。
【図２】アプリケーション監視部の構成を示すブロックである。
【図３】アプリケーション監視部の処理動作を説明するフローチャートである。
【図４】アプリケーション監視条件ＤＢの構成例を示す図である。
【図５】アプリケーション監視履歴ＤＢの構成例を示す図である。
【図６】アプリケーション診断部に送信する診断要求メッセージの構成例を説明する図である。
【図７】アプリケーション診断部の構成例を示すブロック図である。
【図８】アプリケーション診断部の処理動作を説明するフローチャートである。
【図９】システム運用ポリシー管理部の構成例を示すブロック図である。
【図１０】システム運用ポリシーＤＢの構成例を説明する図である。
【図１１】アプリケーション診断ルールＤＢの構成例を説明する図である。
【図１２】アプリケーション診断履歴ＤＢの構成例を説明する図である。
【図１３】制御要求メッセージの構成例を示す図である。
【図１４】アプリケーション制御部の構成を示すブロック図である。
【図１５】アプリケーション制御部の処理動作を説明するフローチャートである。
【図１６】アプリケーション制御条件ＤＢの構成例を説明する図である。
【図１７】アプリケーション制御履歴ＤＢの構成例を説明する図である。
【図１８】コンポーネント置換の処理動作を説明するフローチャートである。
【図１９】アプリケーションライフサイクル管理部の構成を示すブロック図である。
【図２０】コンポーネントＤＢの構成例を説明する図である。
【符号の説明】
【００８２】
１００  業務アプリケーション
２００  ランタイム・アプリケーション運用管理部２００
２１０  アプリケーション監視部
２２０  アプリケーション診断部
２３０  アプリケーション制御部
３００  システム運用ポリシー管理部
４００  アプリケーション・ライフサイクル管理部
５００  システムプラットフォーム運用管理部
６００  業務データベース（ＤＢ）
７００  システム運用管理端末
８００  システム運用ポリシー管理端末
Ｃ１、Ｃ２、Ｃ２’、Ｃ３  ソフトウェア・コンポーネント
２１１、２３１、４０１  対業務アプリケーション通信制御部
２１２、２３２  対システム運用管理端末通信制御部
２１３、２３４  対アプリケーション診断部通信制御部
２１４  アプリケーション監視プログラム
２１５  アプリケーション監視履歴ＤＢ
２１６  アプリケーション監視履歴管理部
２１７  アプリケーション監視条件管理プログラム
２１８  アプリケーション監視条件ＤＢ
２１９  アプリケーション監視条件管理部
２２１  対システム運用管理端末通信制御部
２２２  対システム運用ポリシー管理部通信制御部
２２３  対アプリケーション監視部通信制御部
２２４  対アプリケーション制御部通信制御部
２２５  アプリケーション診断プログラム
２２６  アプリケーション診断履歴ＤＢ
２２７  アプリケーション診断管理部
２２８  アプリケーション診断ルール管理プログラム
２２９  アプリケーション診断ルールＤＢ
２２Ａ  アプリケーション診断ルール管理部
２３３  対アプリケーションライフサイクル管理部通信制御部
２３５  アプリケーション制御プログラム
２３６  アプリケーション制御履歴ＤＢ
２３７  アプリケーション制御実行管理部
２３８  アプリケーション制御条件管理プログラム
２３９  アプリケーション制御条件ＤＢ
２４０  アプリケーション制御条件管理部
３０１、４０２  対ランタイム・アプリケーション運用管理部通信制御部
３０２  対システム運用ポリシー管理端末通信制御部
３０３  対システムプラットホーム運用管理部通信制御部
３０４  システム運用ポリシー管理プログラム
３０５  システム運用ポリシーＤＢ
３０６  システム運用ポリシー制御部
４０３  コンポーネント管理プログラム
４０４  コンポーネントＤＢ
４０５  コンポーネント管理部
【図１】
2006252189.tif 000003
【図２】
2006252189.tif 000004
【図３】
2006252189.tif 000005
【図４】
2006252189.tif 000006
【図５】
2006252189.tif 000007
【図６】
2006252189.tif 000008
【図７】
2006252189.tif 000009
【図８】
2006252189.tif 000010
【図９】
2006252189.tif 000011
【図１０】
2006252189.tif 000012
【図１１】
2006252189.tif 000013
【図１２】
2006252189.tif 000014
【図１３】
2006252189.tif 000015
【図１４】
2006252189.tif 000016
【図１５】
2006252189.tif 000017
【図１６】
2006252189.tif 000018
【図１７】
2006252189.tif 000019
【図１８】
2006252189.tif 000020
【図１９】
2006252189.tif 000021
【図２０】
2006252189.tif 000022