WO2009096519A1

WO2009096519A1 - フィードフォーワード制御方法、サービス提供品質制御装置、システム、プログラム及びその記録媒体

Info

Publication number: WO2009096519A1
Application number: PCT/JP2009/051573
Authority: WO
Inventors: Shinji Kikuchi; Yoshihiro Kanna; Yohsuke Isozaki
Original assignee: Nec Corporation
Priority date: 2008-01-31
Filing date: 2009-01-30
Publication date: 2009-08-06
Also published as: JPWO2009096519A1; JP5212381B2; US8966492B2; US20110004885A1

Abstract

　「適正制御案の評価機能の欠如」、「制御指向の評価機能・実行機能の欠如」、「制御案の補正・検証機能の欠如」という課題を解決したフィードフォーワード制御方法、サービス提供品質制御装置、システム、プログラム、記録媒体を提供する。　計測統計量の現状態及び履歴状態のベクトル値を基に状態推定ベクトル値群を未来時刻で補償した上で推定するシミュレーション処理部５０４と、推定した状態推定ベクトル値と合意サービス水準情報を制御目標とする目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作が必要か否かを判断する判断部５０６とを有し、ワークフローの記述の実行環境を自装置内で仮想的に変化させつつ、シミュレーション及び制御操作が必要か否かの判断を繰り返し行い、所定回数を上限として制御偏差が所定値以下となるまで実行環境の評価条件を調整部５０７で調整する。

Description

フィードフォーワード制御方法、サービス提供品質制御装置、システム、プログラム及びその記録媒体

　本発明は、インターネットの利用の有無を問わず、複数の業務アプリケーションシステム群をサービス群として定義し、これらをワークフロー管理システム、ビジネスプロセス管理システムを用いて任意に連携させ、ビジネスプロセスとして実施・運用する際に、当該ビジネスプロセスを起動するサービス利用者とビジネスプロセス並びにそこから呼び出されるサービス群を提供するサービス提供者との間で契約として取り決められた合意サービス水準に基づくサービス提供品質を維持するためのフィードフォーワード制御方法、サービス提供品質制御装置、システム、プログラム及びその記録媒体に関する。

　複数の業務アプリケーションシステム群をサービス群として定義し、これらをワークフロー管理システム、ビジネスプロセス管理システムを用いて任意に連携させ、ビジネスプロセスとして実施・運用する際に、ビジネスプロセスを起動するサービス利用者とビジネスプロセス及びそこから呼び出されるサービス群を提供するサービス提供者との間で契約として取り決められた合意サービス水準に基づくサービス提供品質を維持するためには、単なる処理要求に応じて発生する通信のトラフィック制御のみならず、複数の通信関係を束ね、複合的に組み合わせて実施される複雑な構造を持つサービス、ビジネスプロセスの安定化が必要である。

　このためには、トラヒック制御技術、シミュレーション技術及び制御方法技術という三つの技術の融合が必要となる。

　特許文献１に開示される「ビジネスプロセス定義を用いた事前リソース割り当て方法」は、将来の計算機リソース使用量を予測して、事前に計算機リソースを適切に割り当てるものである。すなわち、特許文献１には、将来の計算機リソース使用量の予測方法に関する発明が開示されている。

　特許文献１に開示される発明は、ビジネスプロセス定義から抽出するサービスの呼出関係を用いた計算機リソース使用量の予測方法を備え、計算機リソース使用量予測ステップにおいて、新たなビジネスプロセスをシステムに配布するよりも前に計算機リソース予測使用量を計算し、計算機リソース予測使用量が所定値を超えるサービス実行計算機に対して、そのサービス実行計算機とは異なる計算機を新たなサービス実行計算機として割り当てるものである。

　特許文献１に開示される発明によれば、ビジネスプログラムの配布時に従来の計算機リソース使用量を適切に予測でき、予測した計算機リソース使用量からリソースが不足する計算機を見つけ出し、計算機リソースを追加するような運用を実現できる。

　特許文献２に開示される「サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体」は、サービス提供装置あるいはサービスコーディネータ装置、又はサービス提供方法あるいはサービスコーディネート方法に関するもので、特にサービス連携制御に関するものである。

　特許文献２に開示される発明は、複数のサービスのサービス提供条件を示すＳＬＡ（Service Level Agreement）情報を記憶する記憶装置と、複数のサービスのうちいくつかをグループとして組み合わせた連携サービスの各サービスを提供することを求めるリクエスト情報を受信する受信部と、連携サービスの各サービスの現在の提供状況を管理し、記憶装置に記憶されたＳＬＡ情報が示す条件に基づいて、受信されたリクエスト情報が求める連携サービスの各サービスを提供することが可能か否かを判断する連携サービス管理部と、判断された結果に基づいて、受信部によって受信されたリクエスト情報が求める連携サービスの各サービスの提供を実行する実行部とを備えるものであり、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる装置を提供することを目的としている。

　特許文献３に開示される「自律管理システム向けポリシシミュレータ」は、計算機群を自律的に管理するシステム、特に、自律管理ポリシのシミュレーション手段に関するものである。

　特許文献３に開示される発明は、自律管理システムの挙動を分析するシミュレータにおいて、システム構成、負荷分散設定、システムの負荷条件、ソフトウェアの性能情報、ソフトウェアの過渡的な挙動、及び検証対象の自律管理ポリシを入力とし、ある時刻のシステムの過渡現象を考慮した挙動（リソース使用量、応答時間、処理量）を計算し、その挙動に自律管理ポリシを適用し、次時刻のシステム構成、負荷分散設定を判断し、変更されたシステム構成、負荷分散設定を使用して次時刻のシミュレーションを行うもので、ポリシ制御による自律管理システムにおいて、ポリシ作成時に低コスト、迅速にポリシの妥当性を検証することを目的としている。

　特許文献４に開示される「トラフィック制御装置およびそれを用いたサービスシステム」は、分散情報システムにおけるクライアント装置とサーバ装置データ通信中継システムとを用いたクライアント装置とサーバ装置との間のデータ通信方法と、それを用いたサーバアクセスのサービスに関するものである。

　特許文献４に開示される発明は、クライアントからサーバへの要求を、トラフィック制御装置を経由して行い、トラフィック制御装置は、クライアントからの要求を制御する手段と、クライアントのデータ受信能力を判定する手段と、サーバに対する同時接続数を制御する手段とを持ち、サーバのリソースを十分に利用できるように、かつ、サーバの性能以上に要求を転送しないように、サーバの同時接続数を制御する。そして、クライアントに対しては、要求のあったサービスの提供にある一定時間以上かかることが予想される場合には、要求を拒否し、ある一定時間以内にサービスを提供できることが予想された場合には、要求を受け付ける。これにより、クライアントのネットワーク特性が多様な状況下で、サーバのスループットを維持し、かつサーバがダウンしないようにする。さらに、アクセス集中時にクライアントが不確定な長時間サービス待ち状態にならないようなサービス提供を可能としている。

　特許文献５に開示される「トラフィック制御方法およびそのシステム」は、ネットワークのサービス品質維持に関するものである。これは、ネットワーク上の機器間のサービス品質を維持することを目的とし、少なくとも一つのクライアントと該クライアントにネットワークを介してサービスを提供する少なくとも一つのサーバ群との間にトラフィック制御装置を置き、そのクライアントとサーバ装置群間に存在する複数回線の回線使用率及びその間のデータ通信能力を監視し、そのデータ通信能力が低下した場合には、トラフィック制御装置が回線使用率の監視情報に基づいて各回線の中からボトルネックとなる回線を特定し、ボトルネック回線に対してトラフィック制御を行うものである。

　特許文献６に開示される「監視制御システム、制御装置のシミュレーション方法及び記録媒体」は、監視制御システムにおけるデータの授受や各装置の演算実行状態の管理及び協調を行う機能を持った監視制御システム及び制御装置のシミュレーション方法に関するものである。

　特許文献６に開示される発明は、監視制御システムの品質や信頼性向及び制御性能向上のために、シミュレーション試験や制御設計結果の反映を容易に且つ安定して実行することを目的としている。そして、プラントなどの制御対象からの制御量を入力とし監視及び制御を行う制御装置と制御パラメータ及び制御ソフトウェアを設計する制御設計部と、設計された制御パラメータ及び制御ソフトウェアを制御装置へ入力するための保守ツールと、設計された制御ソフトウェア及び制御パラメータを模擬して制御する制御装置モデルと制御対象の動特性の模擬演算結果を実行する制御対象モデルと、制御対象の運転データ及び制御装置モデルや、制御対象モデルの実行結果となるデータを保存し表示するデータ表示部、及び制御設計部、制御装置モデル、制御対象モデル及びデータ表示部と必要に応じて一部または全部を組み合わせ、協調して動作させる管理部とがネットワークを介して接続された監視制御システムを提供するものである。
特開２００７－１４８４６９号公報特開２００４－３６２４４９号公報特開２００５－１９６６０１号公報特開２００５－１８４１６５号公報特許第３７５０６２１号公報特開２００１－２９０５１６号公報

　上記特許文献１～６は、トラフィック制御技術に関するもの、シミュレーション技術に関するもの及び制御方式に関するものの三つに大別される。そして、これらのそれぞれについて課題が存在する。

　１番目の課題は、異なった制御対象を前提としたために所望の制御を実現できない「適正制御案の評価機能の欠如」という課題である。

　２番目の課題は、一部の機能が欠落しているために所望の制御を実現できない「制御指向の評価機能・実行機能の欠如」という課題である。

　３番目の課題は、複雑な制御案について妥当性を立証できないために所望の制御の実行を保証できない「制御案の補正・検証機能の欠如」という課題である。

　特許文献１に開示される発明は、サービス呼出関係を把握した上で現状の計算機リソースの利用状況を把握し、その上で将来の計算機リソースの需要についても算出し、その上で計算機リソースが不足する事態となれば、計算機リソースを追加する運用を行う。ただし、特許文献１に開示される発明は、取り扱う計測量が計算機リソースの予想使用量のみであり、計算機利用者とサービス提供者とが合意するべきＳＬＡではない。

　このため、シミュレーション等のしくみが簡単な構造であり、予め定義されているアクションをイベント時の実行条件に設定して、あるタイミングでイベントが指し示す値が実行条件を満足しているかのみを判定してアクションを実施しているに留まっている。

　しかし、ＳＬＡを想定する場合、サービス品質は種々の構成要素から定義され、計算機リソースだけを制御対象とするわけではない。

　このため、あるタイミングでイベントが指し示す値が実行条件を満足しているかの判定のみならず、その実施結果について結果をシミュレーションして推定・検証する必要があるが、特許文献１にはそのような構成要素は定義されていない。これは、「制御案の補正・検証機能の欠如」に該当する。

　特許文献２に開示される発明は、ＳＬＡで定義された処理件数をサービスコーディネータとサービスプロバイダとの間で交換し、その枠内で処理する方式である。

　しかし、特許文献２に開示される発明は、実現するべきＳＬＡは、単位時間当たりの処理件数のみであり、平均応答時間や要求の棄却率、ＭＴＢＦ（Mean Time Between Failures）等の他の一般的なＳＬＡは対象となっていない。
　さらに、特許文献１にて想定しているサービス品質や呼び出し関係に関連する複雑な構造や、平均応答時間、要求棄却率の時間変動を計測し、制御対象の状態を推定するためのシミュレーション等の仕組みは、この構成要素として定義されていない。

　複雑なものを対象とする場合、シミュレーション等の仕組みが必要になる。しかし、特許文献２に開示される発明は、制御を実施する上で状況計測～制御対象の状態推定という一連のプロセスを実現できず、ある任意時間のサービス品質状態に基づいた適切な制御を実現できない。これは、「適正制御案の評価機能の欠如」に該当する。

　特許文献３に開示される発明は、システムの状態把握を行うためのシミュレータに関するものであり、特に時間に応じて変動する状態、過渡現象も取り扱える。

　しかし、取り扱っている情報はサーバ、ストレージに関するものが中心であり、計算機利用者とサービス提供者とが合意すべきＳＬＡではなく、サービス提供品質の制御というよりも適用ポリシの検証を目的としている。

　このため、ポリシについて具体的な定義がなく、かつ、サービス提供品質の制御に関連する機能は含んでいない。このため、シミュレーション結果として求めた状況計測～制御対象の状態推定、制御実施の具体的な手順が明確化されておらず、ＳＬＡ維持の施策案が不明確である。これは、「制御指向の評価機能・実行機能の欠如」に該当する。

　特許文献４に開示される発明は、クライアント装置とサーバ装置データ通信中継システムとを用い、発生する通信メッセージを全て捕捉し、その計測結果を基に通信メッセージの棄却、待ち合わせ、同時接続数の制御を行う。
　そして、評価の一つとして宛先が指定されている処理要求の平均応答時間と内部キューに保持されている処理要求数の積算結果とを最大待ち時間と比較して制御内容を決めることが可能である。

　しかし、評価方式、制御内容の簡潔な方法では、サービス品質や呼び出し関係に関連する複雑な構造への対応は難しい。

　複雑なものを対象とする場合、シミュレーションが必要となる。しかし、特許文献４に開示される発明で実現できるのは、個々の処理要求を単純に合わせた際のトラフィック制御に留まり、それらを複合的に組み合わせて実施される複雑な構造を持つサービスに対して、ある任意時点での品質状態に基づいた制御は困難である。制御対象が目的に対して限定されてしまうことから、特許文献４の課題も「適正制御案の評価機能の欠如」に該当する。

　特許文献５に開示される発明は、特許文献４と同様に中継を行うトラフィック制御装置を置き、発生する通信メッセージを捕捉し、複数回線の回線使用率及びその間のデータ通信能力を監視して帯域を確保することで、ネットワーク上の機器間のサービス品質を維持する制御を行うものである。
　しかし、特許文献５のような簡潔な評価方式及び制御内容では、サービス品質や呼び出し関係に関連する複雑な構造への対応が難しい。

　複雑なものを対象とする場合、シミュレーションが必要となる。しかし、特許文献５に開示される発明で実現できるのは、データ通信回線のトラフィック制御に留まり、それらを複合的に組み合わせて実施される複雑な構造を持つサービスに対して、ある任意時点での品質状態に基づいた制御実施は困難である。制御対象が目的に対して限定されてしまうことから、特許文献５の課題も「適正制御案の評価機能の欠如」に該当する。

　特許文献６に開示される発明は、主にプラントにおける制御を対象としており、情報・通信分野のサービス品質に関する制御とは狙いが異なる。したがって、シミュレーション試験は必要に応じて適宜実施できるものの、制御を目的として実施することは想定されていない。

　例えば、シミュレーション試験には一定の計算コストが発生するが、そのための制約を定義する機能が存在していない。さらに、制御を行う上でどの施策を優先的に行うかについてポリシを与える機能が存在していない。

　このため、特許文献６に開示される発明は、状況計測～制御対象の状態推定、制御実施の具体的な手順が明確化されていないため、ＳＬＡ維持の施策案が不明確である。これは、「制御指向の評価機能・実行機能の欠如」に該当する。

　このように、合意サービス水準に基づくサービスを提供するに当たっては、「適正制御案の評価機能の欠如」、「制御指向の評価機能・実行機能の欠如」、「制御案の補正・検証機能の欠如」という課題を解決する技術は提供されていなかった。

　本発明は係る問題に鑑みてなされたものであり、インターネットの利用の有無を問わず、複数の業務アプリケーションシステム群をサービス群として定義し、これらをワークフロー管理システム、ビジネスプロセス管理システムを用いて任意に連携させ、ビジネスプロセスとして実施・運用する際に、当該ビジネスプロセスを起動するサービス利用者と、ビジネスプロセス並びにそこから呼び出されるサービス群を提供するサービス提供者との間で契約として取り決められた合意サービス水準に基づくサービス提供品質を維持するための制御機能を、「適正制御案の評価機能の欠如」、「制御指向の評価機能・実行機能の欠如」、「制御案の補正・検証機能の欠如」という課題を解決して実現するフィードフォーワード制御方法、サービス提供品質制御装置、システム、プログラム及び及びそれを記録した記録媒体を提供することを目的とする。

　上記目的を達成するため、本発明は、第１の態様として、複数の業務アプリケーションシステム群の起動状態及び操作順序の定義を維持管理し、制御するワークフローのそれぞれの要素ワークフロー部分を、ワークフローエンジンを実装した複数のワークフロー管理システムが独立・分散して管理及び実行している環境下で、分散された要素ワークフロー部分の実行を統合監視する機能に伴い、全体ワークフローの記述に関するサービス提供品質、又は複数利用者ごとに取り決めた合意サービス水準を維持することを目的とする合意サービス水準制御装置であって、全体ワークフローの記述ごとに制御目標の目標状態ベクトル値として定義された、全体ワークフローのサービス提供条件を示す合意サービス水準情報を格納する手段と、可計測かつ統計処理のみで計算可能な要素ワークフロー部分又は当該要素ワークフロー部分から呼び出されるサービスに関する計測統計量を算出する計測統計量データ計算手段と、計測統計量から所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する状態観測手段と、計測統計量の現状態ベクトル値及び履歴状態ベクトル値を基に、目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上で推定するシミュレーション処理手段と、制御操作に関するポリシ記述を管理するポリシ記述管理手段と、シミュレーション処理手段が推定した状態推定ベクトル値と合意サービス水準情報を制御目標とする目標状態ベクトル値とを順次比較した上で制御偏差を算出し、制御操作が必要か否かを判断する判断手段と、制御操作が必要と判断される場合には、ポリシ記述管理手段が管理するポリシ記述に基づいて全体ワークフローの記述の実行環境を自装置内で仮想的に変化させた上で、シミュレーション処理手段及び判断手段を再実行し、所定回数を上限として制御偏差が所定値以下となるまで実行環境の評価条件を調整する調整手段と、調整手段による評価条件の調整の結果、もはや制御操作が必要と判断されない場合に、実行環境の変化を確定させる手段とを有することを特徴とする合意サービス水準に基づくサービス提供品質制御装置を提供するものである。

　また、上記目的を達成するため、本発明は、第２の態様として、要素ワークフロー部分の記述を格納する手段及び該要素ワークフロー部分を実行するワークフローエンジンを備えた複数のワークフロー処理装置と、上記本発明の第１の態様に係る合意サービス水準に基づくサービス提供品質制御装置とを有することを特徴とするサービス提供品質制御システムを提供するものである。

　また、上記目的を達成するため、本発明は、第３の態様として、明確に定義された制御対象及びそれに関係する物理事象のうち、可計測かつ統計処理のみで計算可能な計測統計量データ及び制御対象の制御目標で直接計測不可能な目標状態ベクトル値を定義する手順と、計測制御量データから所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する手順と、計測統計量の現状態ベクトル値及び履歴状態ベクトル値を基に、目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上でシミュレーションして推定する手順と、シミュレーションによって推定された状態推定ベクトル値と目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作が必要であるか否かを判断する手順と、制御操作が必要な場合に、制御偏差を満たすための制御操作量を仮決めする手順と、仮決めした制御操作量を追加して、シミュレーションと同義の新たなシミュレーションを実施し、目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値を算出した後、該状態推定ベクトル値を目標状態ベクトル値と比較して新たな制御偏差を算出し、更に制御操作量が必要な場合は、所定回数を上限として制御操作量が確定するまで、仮決めする制御操作量を追加・条件を厳しくする手順と、制御操作量を追加する必要のない場合に、制御操作を実施する手順を含むことを特徴とするフィードフォワード制御方法を提供するものである。

　また、上記目的を達成するため、本発明は、第４の態様として、可計測かつ統計処理のみで計算可能なサービスに関する計測統計量データを持ち、サービス提供条件を示す合意サービス水準情報を制御目標の目標状態ベクトル値として定義する手順と、サービスに関する計測制御量データを基に直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する手順と、計測統計量の現状態ベクトル値及び履歴状態ベクトル値を基に、目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上でシミュレーションして推定する手順と、推定された状態推定ベクトル値と目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作の必要有無を判断する手順と、制御操作が必要な場合に、制御偏差を満たすための制御操作として、サービス実行処理系の処理系の数、ハードウェア資源の割付け量増減、メッセージ投入抑制量の増減を仮決めする手順と、仮決めされた当該処理系の数、ハードウェア資源の割付け量増減や、メッセージ投入抑制量増減の操作を仮想的に追加して、シミュレーションと同等の新たなシミュレーションによる推定を改めて実施し、サービス提供条件を示す合意サービス水準情報と比較し、これを満足するか否かを判断し、更に新たな処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減の操作が必要と判断される場合は、所定回数を上限として合意サービス水準情報を満足するまで、当該新たな処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減を仮想的に実施する手順と、合意サービス水準情報を満足する場合に、実際に処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減を実施する制御操作を実施する手順とを実行することを特徴とする合意サービス水準に基づくサービス提供品質制御方法を提供するものである。

　また、上記目的を達成するため、本発明は、第５の態様として、コンピュータを、複数業務アプリケーションシステム群の起動状態、操作順序の定義を維持管理し、制御するワークフローのそれぞれの要素ワークフロー部分を、ワークフローエンジンを実装した複数のワークフロー管理システムが独立・分散して管理、実行している環境下で、要素ワークフロー部分を実施する際に発生するイベント群を当該全体のワークフローの記述に明確に位置付け、当該イベント群以外のイベント群と関連付けてイベント格納手段に記録する手段と、分散された要素ワークフロー部分の実行を統合監視する機能に伴い、全体のワークフローの記述ごとに、そのサービス提供条件を示す合意サービス水準情報を制御目標の目標状態ベクトル値として定義する手段と、可計測かつ統計処理のみで計算可能な要素ワークフロー部分や当該要素ワークフロー部分から呼び出されるサービスに関する計測統計量データの計算手段と、計測統計量データの計算手段が算出するデータから、所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する状態観測に関する手段と、計測統計量の現状態ベクトル値、及び履歴状態ベクトル値を基に、目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって所定回数未来時刻で補償した上で推定するシミュレーション処理手段と、制御操作に関するポリシ記述を管理する手段と、シミュレーション処理によって推定した当該状態推定ベクトル値と合意サービス水準情報を制御目標とする目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作が必要であるか否かを判断する手段と、制御操作が必要と判断される場合、ポリシ記述から、複数ワークフロー管理システムの内の特定要素ワークフロー部分を実行するワークフローエンジン数を仮決めで増減し、仮決めされた当該ワークフローエンジン数を仮想的に増減した上でシミュレーションと制御操作が必要であるか否かの判断とを再実行し、更に新たなワークフローエンジン数の増減が必要と判断される場合には、所定回数を上限として、制御偏差が満足できるまで、当該新たなワークフローエンジン数を増減する評価条件を調整する手段と、調整手段による評価条件の調整の結果、もはや制御操作が必要でないと判断する場合、実際に当該ワークフローエンジン数を増減するための手続きに変換する調整操作に関する手段と、として機能させることを特徴とする合意サービス水準に基づくサービス提供品質制御プログラムを提供するものである。

　また、上記目的を達成するため、本発明は、第６の態様として、上記本発明の第５の態様に係るサービス提供品質制御プログラムを記録した記録媒体を提供するものである。

　本発明によれば、複数の業務アプリケーションシステム群をサービス群として定義し、これらをワークフロー管理システム、ビジネスプロセス管理システムを用いて任意に連携させ、ビジネスプロセスとして実施・運用する際に、当該ビジネスプロセスを起動するサービス利用者と、ビジネスプロセス並びにそこから呼び出されるサービス群を提供するサービス提供者との間で契約として取り決められた合意サービス水準に基づくサービス提供品質を維持するフィードフォーワード制御方法、サービス提供品質制御装置、システム、プログラム及び及びそれを記録した記録媒体を提供できる。

　図１に示すように、本発明に係るサービス提供品質制御装置５００は、複数の業務アプリケーションシステム群の起動状態及び操作順序の定義を維持管理し、制御するワークフローのそれぞれの要素ワークフロー部分を、ワークフローエンジンを実装した複数のワークフロー管理システムが独立・分散して管理及び実行している環境下で、分散された要素ワークフロー部分の記述を収集・管理し、収集した分散された要素ワークフロー部分の記述を合成し、全体ワークフローの記述を再生し、分散された要素ワークフロー部分の実行を統合監視する機能に伴い、全体ワークフローの記述に関するサービス提供品質、又は複数利用者ごとに取り決めた合意サービス水準を維持することを目的とし、全体ワークフローの記述ごとに制御目標の目標状態ベクトル値として定義された、全体ワークフローのサービス提供条件を示す合意サービス水準情報を格納する合意サービス水準情報格納部５０１と、可計測かつ統計処理のみで計算可能な要素ワークフロー部分又は当該要素ワークフロー部分から呼び出されるサービスに関する計測統計量を算出する計測統計量データ計算部５０２と、計測統計量から所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する状態観測部５０３と、計測統計量の現状態ベクトル値及び履歴状態ベクトル値を基に、目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上で推定するシミュレーション処理部５０４と、制御操作に関するポリシ記述を管理するポリシ記述管理部５０５と、シミュレーション処理部５０４が推定した状態推定ベクトル値と合意サービス水準情報を制御目標とする目標状態ベクトル値とを順次比較した上で制御偏差を算出し、制御操作が必要か否かを判断する判断部５０６と、制御操作が必要と判断される場合には、ポリシ記述管理部５０５が管理するポリシ記述に基づいて全体ワークフローの記述の実行環境を仮想的に変化させた上で、シミュレーション処理部５０４及び判断部５０５を再実行し、所定回数を上限として制御偏差が所定値以下となるまで実行環境の評価条件を調整する調整部５０７と、調整部５０６による評価条件の調整の結果、もはや制御操作が必要と判断されない場合に、実行環境の変化を確定させる確定部５０８とを有する。

　図２に示すように、サービス提供品質制御装置５００は、要素ワークフロー部分の記述を格納するｗｆ定義６０２及び要素ワークフロー部分を実行するワークフローエンジン６０１を備えた複数のワークフロー処理装置６００に接続されてサービス提供品質制御システムを構成する。

　このような構成をとることにより、「適正制御案の評価機能の欠如」、「制御指向の評価機能・実行機能の欠如」、「制御案の補正・検証機能の欠如」という課題を解決しつつ、複数の業務アプリケーションシステム群をサービス群として定義し、これらをワークフロー管理システム、ビジネスプロセス管理システムを用いて任意に連携させ、ビジネスプロセスとして実施・運用する際に、当該ビジネスプロセスを起動するサービス利用者と、ビジネスプロセス並びにそこから呼び出されるサービス群を提供するサービス提供者との間で契約として取り決められた合意サービス水準に基づくサービス提供品質を維持できる。

　以下、本発明の好適な実施の形態について説明する。

　〔第１の実施形態〕
　本発明を好適に実施した第１の実施形態について説明する。
　図３に、本実施形態に係るサービス提供品質制御装置が適用される環境の一例を示す。本実施形態に係るサービス提供品質制御装置が適用されるのは、インターネットを含めた複数のサブネットワークが、そのサブネットワークの持つ管理ポリシ、セキュリティポリシの集合の下で、ルータ等によって結合されて大きなネットワークを構成している一般的なネットワーク環境である。

　サブネットワーク１０１は、サブネットワーク１０２及びサブネットワーク１０３とルータ１０６を介して連結されている。また、サブネットワーク１０２は、サブネットワーク１０５とルータ１０８を介して連結されている。さらに、サブネットワーク１０５は、サブネットワーク１０４とルータ１０７を介して連結されている。

　サブネットワーク１０１～１０５は、インターネットを構成するものであっても良いし、企業や団体が管理するローカルなネットワークであっても良い。

　また、ルータ１０６～１０８は、独自のポリシに基づくものであり、インターネットとローカルネットワークとを連結する場合には、ファイヤウォールとしての機能を備えていても良い。

　業務アプリケーションシステム７～１２は、サブネットワーク１０１～１０５のいずれかに接続される。また、業務アプリケーションシステム７～１２の間を連結してワークフロー処理を実施するワークフローシステム１～３及びネットワーク上の構成で種々の制御などを行うProxyシステム４も同様に、サブネットワーク１０１～１０５のいずれかに接続される。さらに、合意サービス水準に基づくサービス提供品質制御装置の主要な機能を提供するモニタシステム５も、サブネットワーク１０１～１０５のいずれかに接続される。

　図３においては、業務アプリケーションシステム７、８及びワークフローシステム１が接続されているサブネットワーク１０１が一つの組織内、部門内に配置されていると想定している。

　また、図３においては、業務アプリケーションシステム９、１０及びワークフローシステム２がサブネットワーク１０３に接続されているサブネットワーク１０３が一つの組織内、部門内に配置されていることを想定している。

　さらに、図３においては、業務アプリケーションシステム１１、１２とProxyシステム４とが接続されているサブネットワーク１０４と、ワークフローシステム３が接続されているサブネットワーク５とが、各々一つの部門内に配置されていると想定している。

　また、図３においては、サブネットワーク１０２がインターネットなどの組織外ネットワークであると想定しており、共通的な機能を提供するモニタシステム５はサブネットワーク１０２に接続されている。

　図４に、本実施形態に係るサービス提供品質制御装置の構成を示す。
　サービス提供品質制御装置は、分散ワークフロー管理方式に基づく複数のワークフローシステム１、２、及び独自実装で配置されるワークフローシステム３、並びにワークフローシステム３の分散ワークフロー管理方法への仲介を行うProxyシステム４、ワークフローシステム１、２及びProxyシステム４から各種イベント情報を収集した後、整理、統合、格納するための管理コンソール８１、関連するリポジトリ６を有する。なお、独自実装のワークフローシステム３を複数備え、これらをProxyシステム４がまとめて仲介するようにしても良い。

　図４に示すように、ワークフローシステム１は、複数の業務アプリケーションシステム７、８と通信する。また、ワークフローシステム２は、複数の業務アプリケーションシステム９、１０と通信する。さらに、ワークフローシステム３は、複数の業務アプリケーションシステム１１、１２とProxyシステム４を介して通信する。

　業務アプリケーションシステム７～１２は、それぞれデータ通信部１３～１８を有する。

　図５に示すように、ワークフローシステム１は、データ通信部１３と通信するためのアダプタ１９を有するとともに、データ通信部１４と通信するためにアダプタ２０を別に有する。これらのアダプタは、ワークフローシステム１に含まれるワークフローエンジン２９、２９’が操作順序を制御した結果、必要な通信を業務アプリケーションシステム７、８と行う際に通信プロトコル上の差異、並びに操作を扱う。

　なお、ワークフローエンジン２９、２９’がアダプタ１９、２０を介して通信する場合、操作プロキシ４８を介在させて実施する。これは、制御を実施する際の制御装置部の一つとして作用するものである。なお、アダプタ１９、２０の機能を操作プロキシ４８に含めて実装するようにしても良い。

　同様に、図６に示すように、ワークフローシステム２は、データ通信部１５と通信するためのアダプタ２１を有するとともに、データ通信部１６と通信するためにアダプタ２２を別に有する。これらのアダプタは、ワークフローシステム２に含まれるワークフローエンジン３２が操作順序を制御した結果、必要な通信を業務アプリケーションシステム９、１０と行う際に通信プロトコル上の差異、並びに操作を扱う。

　なお、ワークフローエンジン３２がアダプタ２１、２２を介して通信する場合、操作プロキシ４９を介在させて実施する。これは、制御を実施する際の制御装置部の一つとして作用するものである。なお、アダプタ２１、２２の機能を操作プロキシ４９に含めて実装するようにしても良い。

　同様に、図７に示すように、ワークフローシステム３は、データ通信部１７と通信するためのアダプタ２３を有するとともに、データ通信部１８と通信するためにアダプタ２４を別に有する。これらのアダプタは、ワークフローシステム３に含まれるワークフローエンジン３７が操作順序を操作した結果、必要な通信を業務アプリケーションシステム１１、１２と行う際に通信プロトコルの差異、並びに操作を扱うものである。

　なお、ワークフローシステム３は、独自実装の既存ワークフローエンジンであるため、データ通信部１７とアダプタ２３との間の通信、及びデータ通信部１８とアダプタ２４との間の通信は、Proxyシステム４内のプロキシ部３５を介して行われる。

　ワークフローシステム１～３は、一つの計算機上に構成されてもよいし、複数の計算機上に分散して構成されても良い。

　ワークフローエンジン２９、２９’の挙動は、ワークフローシステム１に含まれるワークフロー定義３１で定義される。ワークフローエンジン２９、２９’は、仮想化技術又はグリッドにて実装された別のプログラム実行体でも良い。また、スレッド、プログラムプロセスのように一つの実行体イメージの中で複数起動するものでも良い。また、ワークフローエンジン２９、２９’は、同じワークフロー定義を実施しても良く、あるワークフロー定義の部分を分担して実施しても良い。その形態は、ワークフローシステム１に応じて決まる。なお、ワークフローエンジン２９、２９’の起動、停止は、ワークフローシステム１の環境によって制御される。

　ワークフロー定義３１は、分散配置されている他のワークフローシステム２、Proxyシステム４を介して通信されるワークフローシステム３からの処理要求・処理応答メッセージに関するイベント、及び複数の業務アプリケーションシステム７、８との通信の結果発生する処理要求・処理応答メッセージに関するイベントが発生した場合に、ワークフローエンジン２９、２９’がどのような次状態となり、どのような処理要求、処理応答メッセージを発するかを規定している。
　通常、ワークフロー定義３１は、ワークフローエンジン２９、２９’の実施する挙動のみを記述し、標準化された形式であるWS-BPEL（Web Service Business Process Execution Language）及びWDSL（Web Service Definition Language）を始めとするプロセス、サービス記述等で記述される。

　ワークフローエンジン３２の挙動は、ワークフローシステム２に含まれるワークフロー定義３４で定義される。ここでは、分散配置されている他のワークフローシステム１、Proxyシステム４を介して通信されるワークフローシステム３からの処理要求・処理応答メッセージに関するイベント、及び複数の業務アプリケーションシステム９、１０との通信の結果発生する処理要求・処理応答メッセージに関するイベントが発生した場合に、ワークフローエンジン３２がどのような次状態となり、どのような処理要求、処理応答メッセージを発するかを規定している。
　通常、ワークフロー定義３４は、ワークフローエンジン３２の挙動のみを記述し、標準化された形式であるWS-BPELとWSDLを始めとするプロセス、サービス記述等で記述される。

　ワークフローエンジン３７の挙動は、ワークフローシステム３に含まれるワークフロー定義３９で定義される。ここでは、他のワークフローシステム１、２からProxyシステム４を介して通信される処理要求、処理応答メッセージに関するイベント、及び業務アプリケーションシステム１１、１２からProxyシステム４を介して通信される処理要求、処理応答メッセージに関するイベントが発生した場合に、ワークフローエンジン３７がどのような次状態となり、どのような処理要求・処理応答メッセージを発するかを規定している。
　なお、ワークフローシステム３は、独自実装の既存のワークフローエンジンであるため、ワークフロー定義３９は、標準化された形式であるWS-BPEL及びWSDLで記述されるとは限らない。その場合、後述するワークフロー定義・サービス定義取得部５９が、それらを標準化された形式、例えばWS-BPEL及びWSDLなどに変換する。

　ワークフローシステム１で発生する処理要求・処理応答メッセージに関するイベントは、ワークフローシステム１内に複数存在するイベント抽出部によって検出される。データ通信部１３とアダプタ１９との間の通信は、アダプタ１９内に仕込まれたMsgイベント抽出部２５によって全て検出される。同様に、データ通信部１４とアダプタ２０との間の通信は、アダプタ２０内に仕込まれたMsgイベント抽出部２６によって全て検出される。ワークフローエンジン２９、２９’の挙動は、Engイベント抽出部３０によって検出される。

　Msgイベント抽出部２５、２６及びEngイベント抽出部３０によって抽出されたイベント情報は、ワークフローシステム１内のイベントデータ保持部４０に一時的に保管され、適宜、共通データ送信部４１によってモニタリングシステム５へ転送される。

　ワークフローシステム２で発生する処理要求・処理応答メッセージに関するイベントは、ワークフローシステム２内に複数存在するイベント抽出部によって検出される。データ通信部１５とアダプタ２１との間の通信は、アダプタ２１内に仕込まれたMsgイベント抽出部２７によって全て検出される。同様に、データ通信部１６とアダプタ２２との間の通信は、アダプタ２２内に仕込まれたMsgイベント抽出部２８によって全て検出される。ワークフローエンジン３２の挙動は、Engイベント抽出部３３によって検出される。

　Msgイベント抽出部２７、２８及びEngイベント抽出部３３によって抽出されたイベント情報は、ワークフローシステム２内のイベントデータ保持部４２に一時的に保管され、適宜、共通データ送信部４３によってモニタシステム５へ転送される。

　ワークフローシステム３で発生する処理要求・処理応答メッセージに関するイベント群の収集は、独自実装の既存ワークフローエンジンであるため、ワークフローシステム１や２で発生する処理要求・処理応答メッセージに関するイベントとは処理方式が異なる。データ通信部１７とアダプタ２３との間の通信は、プロキシ部３５を介して行われるため、発生する処理要求・処理応答メッセージに関するイベントは、Proxyシステム４内のプロキシ部３５に連結された、Prxイベント抽出部３６によって検出される。データ通信部１８とアダプタ２４との間の通信で発生する処理要求・処理応答メッセージに関するイベントも、Prxイベント抽出部３６によって検出される。

　イベント検出部３６によって抽出されたイベント情報は、Proxyシステム４内のイベントデータ保持部４５に一時的に保管される。

　これに対して、ワークフローエンジン３７の挙動は、ワークフローシステム３内に配置されたEngイベント抽出部３８によって検出される。その後、ワークフローシステム３内に配置された共通データ送信部４７を用いて、イベントに関するデータを適宜、Proxyシステム４へ送信する。

　その後、Proxyシステム４は、自身の共通データ受信部４６を用いて、イベントに関するデータを収集し、Proxyシステム４内のイベントデータ保持部４５に一時的に保管する。

　イベントデータ保管部４５に一時的に保管したイベントに関する全てのデータは、適宜、共通データ送信部４４によってモニタシステム５へ転送される。

　図８に示すように、モニタシステム５は、ワークフロー定義・サービス定義取得部５９、ワークフロー定義合成部６０、合成ワークフロー定義６１、イベントデータ受信部６２、イベントデータ関係付け部６３、計測制御量管理部６４、イベント・統計格納データデータベース（ＤＢ）６５、メタデータ管理部６６、計測統計量データ計算部６７、パフォーマンスデータ管理部６８、起動制御部６９、状態観測部７０、補償機能付きシミュレーション処理部７１、目標状態ベクトル値管理部７２、検出部７３、評価条件調整部７４、ポリシ記述管理部７５、調整操作部７６、計測状態ベクトル値処理部７７、長期補償検出部７８、バッファ部７９及び実施条件指定部８０を有する。

　ワークフロー定義・サービス定義取得部５９は、ワークフロー定義３１、３４、３９を受信し、一部変換を施す。ワークフロー定義・サービス定義取得部５９は、外部に置かれたリポジトリ６へのアクセスが可能である。ワークフロー定義合成部６０は、ワークフロー定義・サービス定義取得部５９が得た全てのワークフロー定義から統合されたワークフロー定義を合成する。合成ワークフロー定義６１は、合成したワークフロー定義を格納管理する。

　イベントデータ受信部６２は、ワークフローシステム１、２及びProxyシステム４からイベントに関する全てのデータを受信する。イベント・統計格納ＤＢ６５は、統合・合成したワークフロー定義を格納管理する合成ワークフロー定義６１を参照し、イベントデータ受信部６２が受ける全てのイベントデータを整理、関係付けて保持する。計測制御量管理部６４は、イベント・統計格納ＤＢ６５を管理する。イベントデータ関係付け部６３は、先の関係付けの実処理を行う。

　メタデータ管理部６６は、単位時間当たりのメッセージ流通量や、通信失敗によって棄却されたメッセージ数や、統合・合成ワークフローの処理件数等のシミュレーションを利用して推定することなく統計処理のみで事実事項を導出把握できる各種パラメータ群に相当する計測統計量群を計算する際に、計算能力を向上する目的で、合成ワークフロー定義６１やリポジトリ６から統合・合成したワークフロー定義とその要素記述とを取り出してメモリ上に管理する。

　計測統計量データ計算部６７は、イベント・統計格納ＤＢ６５に格納されている全てのイベントデータのうち、関連するイベントデータを取り出し、メタデータ管理部６６上にて管理される統合・合成したワークフロー定義とその要素記述を参照して計測統計量群を算出する。パフォーマンスデータ管理部６８は、計測統計量群を算出したのち、その算出結果を後続の評価・計算で高速に処理するため、メモリ上に管理する。計測統計量データ計算部６７は、図１に示した構成における計測統計量データ計算部５０２に相当する。

　起動制御部６９は、管理コンソール８１から指定され、サービス提供品質制御装置２を運用する際に参照される各種実行条件、各種パラメータ値群を管理している実施条件指定部８０、及び計測統計量群を元にシミュレーションを実施して状態推定を行い、それをもとに制御を行うためにサンプリング周期を指定して、後述する補償機能付きシミュレーション処理部７１などを起動する。

　状態観測部７０は、制御対象である合意サービス水準に関する任意時点の状態推定のため、制御のサンプリング周期で直前の、及び１サンプリング周期以前に計測された計測統計量群から成るベクトル値群を、メタデータ管理部６６から入手した情報と関連させ、パフォーマンスデータ管理部６８から入手するとともに、それらを維持管理する。状態観測部７０は、図１に示した構成における状態観測部５０３に相当する。

　目標状態ベクトル値管理部７２は、サービス提供品質制御装置によって実現されるべき、合意サービス水準に関する目標値群やベクトル値群で管理する。目標状態値ベクトル値管理部７２は、図１に示した構成における合意サービス水準格納部５０１に相当する。補償機能付きシミュレーション処理部７１は、計測統計量群からなるベクトル値群や後述する各種制御装置部に与えるべき操作量を指定した後、それらを元に任意時点の合意サービス水準に関する状態推定・評価を行う。補償機能付きシミュレーション処理部７１は、図１に示した構成におけるシミュレーション処理部５０４に相当する。検出部７３は、補償機能付きシミュレーション処理部７１が推定・評価する任意の時点の合意サービス水準に関する状態についてのベクトル値群と目標状態ベクトル管理部７２が管理する合意サービス水準に関する目標値群のベクトル値群とを比較して制御偏差を求める。検出部７３は、図１に示した構成における判断部５０６に相当する。

　評価条件調整部７４は、検出部７３が計算する制御偏差が合意サービス水準に関する目標値群のベクトル値群を満足できない水準の場合、各種制御装置部に与えるべき操作量を随時仮決めし、改めて補償機能付きシミュレーション処理部７１を使って許容指定回数まで推定・評価し、合意サービス水準に関する目標値群のベクトル値群を満足できるように制御施策上の調整を行う。評価条件調整部７４は、図１に示した構成における調整部５０７に相当する。ポリシ記述管理部７５は、評価条件調整部７４が操作量を仮決めする際に参照するべきポリシ等を管理する。ポリシ記述管理部７５は、図１に示した構成におけるポリシ記述管理部５０５に相当する。

　調整操作部７６は、検出部７３が計算する制御偏差が複数のサービス利用者ごとに取り決めた合意サービス水準（以下、合意サービス水準）に関する目標値群のベクトル値群を満足する水準、又は評価条件調整部７４が調整し、各種制御装置部に与えるべき操作量を取り決めた後、合意サービス水準に関する目標値群のベクトル値群を満足する水準の場合に、各種制御装置部に実際の操作量を指示する。調整操作部７６は、図１に示した構成における確定部５０８に相当する。バッファ部７９は、調整操作部７６が実際の操作量を指示する際に補償機能付きシミュレーション処理部７１が推定・評価した指定時点の合意サービス水準に関する状態についてのベクトル値群を保持する。

　計測状態ベクトル値処理部７７は、補償機能付きシミュレーション処理部７１が指定時点で合意サービス水準に関する状態についてのベクトル値群を推定・評価する段階で参照する固定的なパラメータ値群を正しく維持できるように、補償機能付きシミュレーション処理部７１が推定・評価した合意サービス水準に関する状態についてのベクトル値群に相当する実測のベクトル値群を過去に遡って、イベント・統計格納ＤＢ６５に格納されている全てのイベントデータから計算し、管理する。

　長期補償検出部７８は、計測状態ベクトル値処理部７７が管理する合意サービス水準に関する状態についてのベクトル値群に相当する実測のベクトル値群と、補償機能付きシミュレーション処理部７１による推定・評価の後でバッファ部７９に保持された複数時点の合意サービス水準に関する状態についてのベクトル値群とを比較して、ポリシ記述管理部７５が管理し、評価条件調整部７４が操作量を仮決めする際に参照するポリシ等を更新、維持する。

　合意サービス水準に関する状態についてのベクトル値群は、通常、ワークフロー定義３１、３４、３９等の全てのワークフロー定義から、ワークフロー合成部６０が合成・定義し、合成ワークフロー定義６１として管理される単位で定義されることとなる。従って、ワークフロー定義３１レベルのワークフローが一部異なるため、サービス利用者が複数存在する場合は、複数のベクトル値群を持つこととなる。

　調整操作部７６が各種制御装置部に実際の操作量を指示する場合、複数制御操作が実施されることもあり得る。例えば、ワークフローシステム１の場合、ワークフローエンジン２９と同等な別のワークフローエンジン２９’が存在するため、処理負荷の状況に応じて、ワークフローエンジン２９’の追加起動や、停止について制御されることもある。

　さらに、ワークフローシステム１の場合、操作プロキシ４８も制御装置部の一つとして作用する。このために、操作プロキシ４８には強制棄却部５０と投入抑制部５１と、キュー管理部５２とが設けられている。

　ワークフローシステム１中のワークフローエンジン２９、２９’がアダプタ１９、２０を介して通信する場合、操作プロキシ４８を介在させて実行する。そこで、通信上のメッセージの流通を投入抑制部５１によって一時的に抑制したり、キュー管理部５２に含めたり、又はキュー管理部５２に含まれる通信上のメッセージを合意サービス水準を維持する範囲で強制棄却部５０を用いて棄却したりする。

　これにより、例えば業務アプリケーションシステム７、８などが処理上のボトルネックとなっている場合、抑制・棄却等により整流化を実現できる。そして、同じく制御装置部として作用する操作プロキシ４９、後述のプロキシ部３５と合わせて、合成ワークフロー定義６１にて管理される単位全体を実施する上で、ボトルネック箇所を特定し、整流化を促進することで、単位全体のスループットを改善できる。

　ワークフローシステム１と同様の目的で、ワークフローシステム２の操作プロキシ４９も制御装置部の一つとして作用する。このため、操作プロキシ４９には強制棄却部５３と、投入抑制部５４とキュー管理部５５とが設けられている。

　ワークフローシステム１と同様の目的で、ワークフローシステム３内のアダプタ２３とデータ通信部１７との間の通信、ワークフローシステム３内のアダプタ２４とデータ通信部１８との間の通信に介在するProxyシステム４内のプロキシ部３５も制御装置部の一つとして作用する。

　このために、プロキシ部３５には、強制棄却部５０に相当する強制脚部５６と、投入制御部５１に相当する投入制御部５７と、キュー管理部５２に相当するキュー管理部５８とが設けられている。

　本実施形態に係るサービス提供品質制御装置の動作について以下に説明する。

　〈定義事項〉
　ここで、ワークフロー定義３１、３４等から呼び出される全てのサービス集合を下記記号（Ａ）で表現する。また、行列式の成分表示等で利用される自然数集合を下記記号（Ｂ）で表現する。これに対して、時刻や各種パラメータ値が実数を取る場合、その実数集合を下記記号（Ｃ）で表現する。

　ワークフロー定義３１、３４等やワークフロー合成部６０によって合成されるワークフロー定義を構成するワークフロー要素とは、下記式（１）のタプルで表現される直積の部分集合である。

　また、どのワークフロー定義の下での起動かを意味するコンテキスト集合を下記記号（Ｄ）で表現し、発呼側サービス集合を下記記号（Ｅ）、着呼側サービス集合を下記記号（Ｆ）で表現する。さらに、下記記号（Ｇ）に示す０以上の自然数集合は呼出のべ回数、下記記号（Ｈ）に示す０以上の自然数集合は呼出繰り返し回数を意味する。また、発呼側サービス集合と着呼側サービス集合とには下記式（２）の関係が成り立つ。

　ワークフロー定義は、ワークフロー要素の冪集合を用いて下記式（３）で表現される。

　ここで、任意ワークフロー定義を特定するプロセス定義関数:nameとは、下記式（４）で与えられる１対１写像である。

　〈計測時の動作〉
　図９、図１０、図１１及び図１５を用いて、合意サービス水準に基づくサービス提供品質制御装置の計測時の動作を説明する。

　サービスの品質を計測するため、分散配置された通常のワークフローエンジンからイベント情報を収集する際の手順について図９を用いて説明する。

　ワークフローエンジン２９、２９’が、業務アプリケーションシステム７に通信する場合、ワークフロー定義３１に基づいて操作プロキシ４８に向け、処理要求メッセージｍ１を送信する。処理要求メッセージｍ１は、Webサービス等で成される場合もあり、ＸＭＬ（eXtensible Markup Language）等を用いて定義される。

　操作プロキシ４８は、処理要求メッセージｍ１を受信すると、投入抑制部５１により一時的に抑制してから処理要求メッセージｍ１をキュー管理部５２に含めるか、キュー管理部５２に含めた後で強制棄却部５０を用いて棄却するか、処理要求メッセージｍ１と同等内容の処理要求メッセージｍ２をアダプタ１９へ送信するかのいずれかを、処理要求メッセージｍ１の内容に応じて行う。

　操作プロキシ４８が、抑制、棄却、アダプタ１９への送信のいずれを行うかは、調整操作部７６が各種制御装置部に指示する操作量に関する制御メッセージ群の内容に依存して決まる。

　投入抑制部５１に対しては、抑制する処理要求メッセージ群、処理応答メッセージ群の種類の指定、抑制の定量的な程度を表現する操作量等が、調整操作部７６から抑制メッセージｃ５２によって指定される。

　強制棄却部５０に対しては、棄却する処理要求メッセージ群、処理応答メッセージ群の種類の指定、棄却率等の定量的な程度を表現する操作量等が、調整操作部７６から制御メッセージｃ５１によっての指定される。

　制御メッセージｃ５１、ｃ５２によって何も指定されていない処理要求メッセージ群、処理応答メッセージ群は、特に操作なく通常の通信を実施することを指定していると見なされる。

　調整操作部７６が各種制御装置部に指示する操作量に関する制御メッセージ群には、ワークフローシステム１の環境に対して指示する制御メッセージｃ５０も含まれる。

　ワークフローシステム１の環境は、制御メッセージｃ５０を受信すると、ワークフローエンジン２９、２９’の起動・停止について評価し、必要に応じてワークフローエンジン２９を起動、停止、処理内容の変更等の制御を行う制御コマンドｃ５３を送信するとともに、ワークフローエンジン２９’を起動、停止、処理内容の変更等の制御を行う制御コマンド５４も送信する。

　アダプタ１９では、処理要求メッセージｍ２を、業務アプリケーションシステム７が受け入れられるような通信プロトコル並びに手順へ変換し、新たな処理要求メッセージｍ３として業務アプリケーションシステム７内のデータ通信部１３へ送信する。

　データ通信部１３は、処理要求メッセージｍ３を受信し、業務アプリケーションシステム７に引き渡す。その結果、必要であれば新たな処理応答メッセージｍ４が生成され、データ通信部１３からアダプタ１９へと戻される。

　アダプタ１９は、処理応答メッセージｍ４を予め規定されている通信プロトコル並びに手順へ変換し、処理応答メッセージｍ５として操作プロキシ４８へ戻す。

　操作プロキシ４８は、処理応答メッセージｍ５を受信すると、投入抑制部５１によって一時的に抑制してから処理応答メッセージｍ５をキュー管理部５２に含めるか、キュー管理部５２に含めた後で強制棄却部５０を用いて棄却するか、処理応答メッセージｍ５と同等内容の処理応答メッセージｍ６として処理要求メッセージｍ１を送信後に受信待ち状態となっているワークフローエンジン２９又は２９’に戻すかのいずれかを、処理応答メッセージｍ５の内容に応じて行う。

　ワークフローエンジン２９が処理応答メッセージｍ６を受信した場合は、ワークフロー定義３１に基づき、次の挙動を決定する。例えば、その結果、業務アプリケーションシステム８に通信する場合、ワークフロー定義３１に基づいて、今度は操作プロキシ４８に処理要求メッセージｍ７を送信する。処理要求メッセージｍ７も、Webサービス等で成される場合もあり、XML等を用いて定義される。

　操作プロキシ４８は、処理要求メッセージｍ７を受信すると、投入抑制部５１によって一時的に抑制してから処理要求メッセージｍ７をキュー管理部５２に含めるか、キュー管理部５２に含めた後で強制棄却部５０を用いて棄却するか、処理要求メッセージｍ７と同等の内容の処理要求メッセージｍ８としてアダプタ２０へ送信するかのいずれかを、処理要求メッセージｍ７の内容に応じて行う。

　アダプタ２０では、処理要求メッセージｍ８を業務アプリケーションシステム８が受け入れられるような通信プロトコル及び手順へ変換し、新たな処理要求メッセージｍ９として業務アプリケーションシステム８内のデータ通信部１４へ送信する。

　データ通信部１４は、処理要求メッセージｍ９を受信し、業務アプリケーションシステム８に引き渡す。その結果必要であれば、新たな処理応答メッセージｍ１０が生成され、データ通信部１４からアダプタ２０へ戻される。

　アダプタ２０内では、処理応答メッセージｍ１０を予め規定されている通信プロトコル、並びに手順へ変換し、処理応答メッセージｍ１１として操作プロキシ４８に戻す。

　操作プロキシ４８は、処理応答メッセージｍ１１を受信すると、投入抑制部５１によって一時的に抑制してから処理応答メッセージｍ１１をキュー管理部５２に含めるか、キュー管理部５２に含めた後で強制棄却部５０を用いて棄却するか、処理応答メッセージｍ１１と同等内容の処理応答メッセージｍ１２として、処理要求メッセージｍ７の送信後に受信待ち状態となっているワークフローエンジン２９に戻すかのいずれかを、処理応答メッセージｍ１１の内容に応じて行う。

　ワークフローエンジン２９は、ワークフロー定義３１に基づいて次の挙動を決定するが、別のワークフローシステム２と通信する場合がある。その場合は、ワークフロー定義３１に基づいてワークフローシステム２を目的先として操作プロキシ４８に処理要求メッセージｍ８６を送信する。処理要求メッセージｍ８６もWebサービス等で成される場合もあり、XML等を用いて定義される。

　操作プロキシ４８は、処理要求メッセージｍ８６を受信すると、投入抑制部５１によって一時的に抑制してから処理要求メッセージｍ８６をキュー管理部５２に含めるか、キュー管理部５２に含めた後で強制棄却部５０を用いて棄却するか、処理要求メッセージｍ８６と同等の内容の処理要求メッセージｍ２５としてワークフローシステム２へ送信するかのいずれかを、処理要求メッセージｍ８６の内容に応じて行う。

　処理要求メッセージｍ２５に応じて、ワークフローシステム２からは処理応答メッセージｍ２６が送信され、操作プロキシ４８へ送られる。

　操作プロキシ４８は、処理応答メッセージｍ２６を受信すると、投入抑制部５１によって一時的に抑制してから処理応答メッセージｍ２６をキュー管理部５２に含めるか、キュー管理部５２に含めた後で強制棄却部５０を用いて棄却するか、処理応答メッセージｍ２６と同等の内容の処理応答メッセージｍ８７として、処理要求メッセージｍ８６の送信後に受信待ち状態となっているワークフローエンジン２９へ戻すかのいずれかを、処理応答メッセージｍ２６の内容に応じて行う。

　ワークフローシステム１で発生する処理要求・処理応答メッセージに関するイベントは、ワークフローシステム１内に複数存在するイベント抽出部によって抽出される。具体的には、アダプタ１９にはMsgイベント抽出部２５が仕込まれている。

　Msgイベント抽出部２５は、アダプタ１９が処理要求メッセージｍ２を受信した段階でこれを検出し、メッセージに関するイベントｍ１７として記録する。また、Msgイベント抽出部２５は、アダプタ１９が処理要求メッセージｍ２を業務アプリケーションシステム７が受け入れられるような通信プロトコル及び手順へ変換し、処理要求メッセージｍ３として送信した段階でこれを検出し、メッセージに関するイベントｍ１８として記録する。

　同様に、Msgイベント抽出部２５は、アダプタ１９が処理応答メッセージｍ４をデータ通信部１３から受信した段階でこれを検出し、メッセージに関するイベントｍ１９として記録する。また、Msgイベント抽出部２５は、アダプタ１９が処理応答メッセージｍ４を変換して処理応答メッセージｍ５として操作プロキシ４８へ送信した段階でこれを検出し、メッセージに関するイベントｍ２０として記録する。

　同様に、アダプタ２０にはMsgイベント抽出部２６が仕込まれている。

　Msgイベント抽出部２６は、Msgイベント抽出部２５と同じ要領で、処理要求メッセージｍ８を検出し、メッセージに関するイベントｍ２１として記録する。さらに、処理要求メッセージｍ９を検出し、メッセージに関するイベントｍ２２として記録する。さらに、処理応答メッセージｍ１０を検出し、メッセージに関するイベントｍ２３として記録する。さらに、処理応答メッセージｍ１１を検出し、メッセージに関するイベントｍ２４として記録する。

　ワークフローエンジン２９、２９’の挙動は、Engイベント抽出部３０によって検出される。ワークフローエンジン２９、２９’から発生したメッセージ及び受信されたメッセージに関する一連のイベントは、全てEngイベント抽出部３０が扱う。

　アダプタ１９に向けてワークフローエンジン２９から操作プロキシ４８へ引き渡された処理要求メッセージｍ１は、Engイベント抽出部３０で検出され、エンジンにおけるメッセージに関するイベントｍ１３として記録される。同様に、アダプタ１９から操作プロキシ４８を介してワークフローエンジン２９に戻された処理応答メッセージｍ６はEngイベント抽出部３０で検出され、エンジンにおけるメッセージに関するイベントｍ１４として記録される。

　さらに、アダプタ２０にワークフローエンジン２９から操作プロキシ４８へ引き渡された処理要求メッセージｍ７は、Engイベント抽出部３０で検出され、エンジンにおけるメッセージに関するイベントｍ１５として記録される。同様に、アダプタ２０から操作プロキシ４８を介してワークフローエンジン２９へ戻された処理応答メッセージｍ１２はEngイベント抽出部３０で検出され、エンジンにおけるメッセージに関するイベントｍ１６として記録される。

　さらに、別のワークフローシステム２と通信する場合も同様に扱う。ワークフローシステム２との通信のために、ワークエンジン２９から操作プロキシ４８へ送信された処理要求メッセージｍ８６はEngイベント抽出部３０で検出され、エンジンにおけるメッセージに関するイベントｍ２７として記録される。また、ワークフローエンジン２からの処理応答メッセージｃ５２に対応する処理応答メッセージｍ８７もEngイベント抽出部３０で検出され、エンジンにおけるメッセージに関するイベントｍ２８として記録される。

　Msgイベント抽出部２５で記録されたメッセージに関するイベントｍ１７～ｍ２０、及びMsgイベント抽出部２６で記録されたメッセージに関するイベントｍ２１～ｍ２４、並びにEngイベント抽出部３０で検出したエンジンにおけるメッセージに関するイベントｍ１３～ｍ１５、ｍ２７、ｍ２８の各々は、ワークフローシステム１内のイベントデータ保持部４０に記録され、一時的に保管される。その後、共通データ送信部４１によって所定のフォーマットでイベントデータ転送メッセージｍ２９が適宜作成され、モニタシステム５へ転送される。

　モニタシステム５は、イベントに関する全てのデータを受信するイベントデータ受信部６２を有しており、イベントデータ転送メッセージｍ２９を受信する。

　ここではワークフローシステム１におけるイベントに関するデータの収集及び、イベントデータのモニタシステム５への転送について説明したが、ワークフローシステム２においても同様である。

　次に、サービスの品質を計測するため、独自実装の既存ワークフローエンジン３７からProxyシステム４を介してイベント情報を収集する手順について図１０を用いて説明する。

　ワークフローエンジン３７が、業務アプリケーションシステム１１に通信する場合、ワークフロー定義３９に基づいてアダプタ２３に処理要求メッセージｍ３０を送信する。処理要求メッセージｍ３０は、Webサービスで成される場合もあり、その場合にはXML等を用いて定義されるが、ワークフローシステム３は独自実装の既存ワークフローエンジンであることから、データ通信部１７とアダプタ２３との間の通信、及びデータ通信部１８とアダプタ２４との間の通信はProxyシステム４内のプロキシ部３５を介して実現され、必ずしもWebサービス等で成されるとは限らない。

　アダプタ２３では、処理要求メッセージｍ３０を業務アプリケーションシステム１１が受け入れられるような通信プロトコル及び手順に変換し、新たな処理要求メッセージｍ３１として、業務アプリケーションシステム１１内のデータ通信部１７に向けて送信する。

　ワークフローシステム３と業務アプリケーションシステム１１との通信はProxyシステム４内のプロキシ部３５を介して実現されるため、プロキシ部３５が処理要求メッセージｍ３１を一旦受け、データ通信部１７に向けて処理要求メッセージｍ３２として送信し直すことによって、アダプタ２３からデータ通信部１７への処理要求メッセージの送信が実現される。

　プロキシ部３５は、処理要求メッセージｍ３１を受信すると、投入制御部５７によって一時的に抑制してから処理要求メッセージｍ３１をキュー管理部５８に含めるか、キュー管理部５８に含めた後で強制棄却部５６を用いて棄却するか、処理要求メッセージｍ３２として送信し直すかのいずれかを、処理要求メッセージｍ３１の内容に応じて行う。

　プロキシ部３５が抑制、棄却、データ通信部１７への処理要求メッセージｍ３２の送信のいずれを行うかは、調整操作部７６が各種制御装置部に指示する操作量に関する制御メッセージ群の内容に依存して決まる。

　投入抑制部５７に対しては、抑制する処理要求メッセージ群、処理応答メッセージ群の種類の指定、抑制の定量的な程度を表現する操作量等が、調整操作部７６から制御メッセージｃ５６によって指定される。

　強制棄却部５６に対しては、棄却する処理要求メッセージ群、処理応答メッセージ群の種類の指定、棄却率等の定量的な程度を表現する操作量等が、調整操作部７６から制御メッセージｃ５５によって指定される。

　制御メッセージｃ５５、ｃ５６によって何も指定されていない処理要求メッセージ群、処理応答メッセージ群は、特に操作なく通常の通信を実施することが指定されているものとする。

　データ通信部１７は、処理要求メッセージｍ３２を受信すると、業務アプリケーションシステム１１に引き渡す。その結果、必要であれば、新たな処理応答メッセージｍ３３が生成され、データ通信部１７からアダプタ２３に向けて応答される。

　この場合も業務アプリケーションシステム１１とワークフローシステム３との通信はProxyシステム４のプロキシ部３５を介して実現されるため、プロキシ部３５が処理応答メッセージｍ３３を一旦受け、さらにアダプタ２３に向けて処理応答メッセージｍ３４として送信し直すことによって、データ通信部１７からアダプタ２３への処理応答メッセージの送信が実現される。

　プロキシ部３５は、処理応答メッセージｍ３３を受信すると、投入抑制部５７によって一時的に抑制してから応答メッセージｍ３３をキュー管理部５８に含めるか、応答メッセージｍ３３をキュー管理部５８に含めた後で強制棄却部５６を用いて棄却するか、処理応答メッセージｍ３４として送信し直すかのいずれかを、処理応答メッセージｍ３３の内容に応じて行う。

　アダプタ２３は、プロキシ部３５から処理応答メッセージｍ３４を受信したら、それを予め規定されている通信プロトコル及び手順に変換し、処理応答メッセージｍ３５としてワークフローエンジン３７に戻す。

　ワークフローエンジン３７は、ワークフロー定義３９に基づいて次の挙動を決定する。その結果、業務アプリケーションシステム１２と通信する場合は、ワークフロー定義３９に基づいて今度はアダプタ２４に処理要求メッセージｍ３６を送信する。

　アダプタ２４では、処理要求メッセージｍ３６を業務アプリケーションシステム１２が受け入れられるような通信プロトコル及び手順に変換し、新たな処理要求メッセージｍ３７として業務アプリケーションシステム１２内のデータ通信部１８に向けて送信する。

　ワークフローシステム３と業務アプリケーションシステム１１との通信はProxyシステム４内のプロキシ部３５を介して実現されるため、プロキシ部３５が処理要求メッセージｍ３７を一旦受け、データ通信部１８に向けて新処理要求メッセージｍ３８として送信し直すことによってアダプタ２４からデータ通信部１８への処理要求メッセージの送信が実現される。

　プロキシ部３５は、処理要求メッセージｍ３７を受信すると、投入制御部５７によって一時的に抑制してから処理要求メッセージｍ３７をキュー管理部５８に含めるか、処理要求メッセージｍ３７をキュー管理部５８に含めた後で強制棄却部５６を用いて棄却するか、処理要求メッセージｍ３８として送信し直すかのいずれかを、処理要求メッセージｍ３７の内容に応じて行う。

　データ通信部１８は、処理要求メッセージｍ３８を受信したら、業務アプリケーションシステム１２に引き渡す。その結果、必要であれば新たな処理応答メッセージｍ３９が生成され、データ通信部１８からアダプタ２４に向けて応答される。

　この場合も、業務アプリケーションシステム１２とワークフローシステム３との通信はProxyシステム４内のプロキシ部３５を介して実現されるため、プロキシ部３５が処理応答メッセージｍ３９を一旦受け、さらにアダプタ２４に向けて処理応答メッセージｍ４０として送信し直すことによって、データ通信部１８からアダプタ２４への処理応答メッセージの送信が実現される。

　プロキシ部３５は、処理応答メッセージｍ３９を受信すると、投入抑制部５７によって一時的に抑制してから処理応答メッセージｍ３９をキュー管理部５８に含めるか、処理応答メッセージｍ３９をキュー管理部５８に含めた後で強制棄却部５６を用いて棄却するか、処理応答メッセージｍ４０として送信し直すかのいずれかを、処理応答メッセージｍ３９の内容に応じて行う。

　アダプタ２４内は、プロキシ部３５から処理応答メッセージｍ４０を受信したら、それを予め規定されている通信プロトコル及び手順に変換し、処理応答メッセージｍ４１としてワークフローエンジン３７に戻す。

　ワークフローエンジン３７は、ワークフロー定義３９に基づいて次の挙動を決定するが、その際に別のワークフローシステム２と通信する場合がある。その場合は、ワークフロー定義３９に基づいて今度はワークフローシステム２を目的先としてプロキシ部３５に処理要求メッセージｍ８８を送信する。処理要求メッセージｍ８８は、Webサービス等で成されるとは限らず、任意の表現によって定義される。

　プロキシ部３５は、処理要求メッセージｍ８８を受信すると、投入抑制部５７によって一時的に抑制してから処理要求メッセージｍ８８をキュー管理部５８に含めるか、処理要求メッセージｍ８８をキュー管理部５８に含めた後で強制棄却部５６を用いて棄却するか、処理要求メッセージｍ４８としてワークフローシステム２へ送信するかのいずれかを、処理要求メッセージｍ８８の内容に応じて行う。

　処理要求メッセージｍ４８の結果は、処理応答メッセージｍ４９としてプロキシ部３５に戻される。

　プロキシ部３５は、処理応答メッセージｍ４９を受信すると、投入抑制部５７によって一時的に抑制してから処理応答メッセージｍ４９をキュー管理部５８に含めるか、処理応答メッセージｍ４９をキュー管理部５８に含めた後で強制棄却部５６を用いて棄却するか、又は処理応答メッセージｍ４９と同等の内容の処理応答メッセージｍ８９として処理要求メッセージｍ８８の送信後に受信待ち状態となっているワークフローエンジン３７に戻すかのいずれかを、処理応答メッセージｍ４９の内容に応じて行う。

　ワークフローシステム３で発生する処理要求・処理応答メッセージに関するイベント群の検出は、独自実装の既存のワークフローエンジンであるため、通常の処理方式とは異なる方法（ワークフローシステム１、２とは異なる方法）が採用される。

　データ通信部１７とアダプタ２３との間の通信は、プロキシ部３５を介して行われるため、発生する処理要求・処理応答メッセージに関するイベントは、Proxyシステム４内のプロキシ部３５に連結されたPrxイベント抽出部３６によって検出される。データ通信部１８とアダプタ２４との間の通信で発生する処理要求・処理応答メッセージに関するイベントもPrxイベント抽出部３６によって検出される。

　Prxイベント抽出部３６は、アダプタ２３が処理要求メッセージｍ３１を送信し、プロキシ部３５が受信し、それをデータ通信部１７に向けて処理要求メッセージｍ３２として送信した段階でこれを検出し、メッセージに関するイベントｍ５０として記録する。また、Prxイベント抽出部３６は、データ通信部１７が処理応答メッセージｍ３３を送信し、プロキシ部３５が受信し、それをアダプタ２３に向けて処理応答メッセージｍ３４として送信した段階でこれを検出し、メッセージに関するイベントｍ５１として記録する。

　同様に、Prxイベント抽出部３６は、アダプタ２４が処理要求メッセージｍ３７を送信し、プロキシ部３５が受信し、それをデータ通信部１８に向けて処理要求メッセージｍ３８として送信した段階でこれを検出し、メッセージに関するイベントｍ５２として記録する。また、Prxイベント抽出部３６は、データ通信部１８が処理応答メッセージｍ３９を送信し、プロキシ部３５が受信し、それをアダプタ２４に向けて処理応答メッセージｍ４０として送信した段階でこれを検出し、メッセージに関するイベントｍ５３として記録する。

　Prxイベント抽出部３６によって抽出されたイベント情報は、Proxyシステム４内のイベントデータ保持部４５に一時的に保管される。

　これに対して、ワークフローエンジン３７の挙動は、ワークフローシステム３内に配置されたEngイベント抽出部３８によって検出される。

　例えば、アダプタ２３に引き渡された処理要求メッセージｍ３０はEngイベント抽出部３８で検出され、エンジンにおけるメッセージに関するイベントｍ４２として記録され。同様に、アダプタ２３から引き渡された処理応答メッセージｍ３５はEngイベント抽出部３８で検出され、エンジンにおけるメッセージに関するイベントｍ４３として記録される。

　さらに、アダプタ２４に引き渡された処理要求メッセージｍ３６は、Engイベント抽出部３８で検出され、エンジンにおけるメッセージに関するイベントｍ４４として記録される。同様に、アダプタ２４から引き渡された処理応答メッセージｍ４１はEngイベント検出部３８で検出され、エンジンにおけるメッセージに関するイベントｍ４５として記録される。

　さらに、別のワークフローシステム２と通信する場合も同様に扱い、ワークフローシステム２に送信した処理要求メッセージｍ８８はEngイベント抽出部３８で検出され、エンジンにおけるメッセージに関するイベントｍ４６として記録される。また、処理要求メッセージｍ８８の結果として戻される処理応答メッセージｍ８９もEngイベント抽出部３８で検出され、エンジンにおけるメッセージに関するイベントｍ４７として記録される。

　その後、ワークフローシステム３内に配置された共通データ送信部４７を用いて、所定のフォーマットにてイベントデータ転送メッセージｍ５４が作成され、イベントに関するデータはProxyシステム４に適宜転送される。

　その後、Proxyシステム４は自身の共通データ受信部４６を用いて、イベントに関するイベントデータ転送メッセージｍ５４を受信し、Proxyシステム４内のイベントデータ保持部４５に一時的に保管する。

　その後、共通データ送信部４４によって、所定のフォーマットにてイベントデータ転送メッセージｍ５５が作成され、モニタシステム５に適宜転送される

　モニタシステム５には、イベントに関する全てのデータを受信するイベントデータ受信部６２が設けられており、イベントデータ転送メッセージｍ５５を受信する。

　図１１に、分散配置されたワークフローエンジンに独自に保持されているワークフロー定義を収集し、統合・合成されたワークフロー定義を生成する際の手順、及び計測したデータを加工して制御目的で供するための手順の概要を示す。

　また、図１５に、本実施形態に係るサービス提供品質制御装置の制御手順を示す。図１１及び図１５を用いて、計測したデータを加工して制御目的で供するための手順について説明する。

　ワークフローシステム１に含まれるワークフローエンジン２９、２９’の挙動は、ワークフロー定義３１で定義される。通常、ワークフロー定義３１は、ワークフローエンジン２９、２９’の挙動のみを記述し、標準化された形式であるWS-BPEL及びWSDLを始めとするプロセス、サービス記述等で記述される。

　ワークフローシステム２に含まれるワークフローエンジン３２の挙動は、ワークフロー定義３４で定義される。通常、ワークフロー定義３４は、ワークフローエンジン３２の挙動のみを記述し、標準化された形式であるWS-BPEL及びWSDLを始めとするプロセス、サービス記述等で記述される。

　ワークフローシステム３に含まれるワークフローエンジン３７の挙動は、ワークフロー定義３９で定義される。ここで、ワークフローシステム３は独自実装の既存ワークフローエンジンであるため、ワークフロー定義３９は、標準化された形式であるWS-BPEL及びWSDLで記述されるとは限らない。

　ワークフロー定義３１は定義転送メッセージｍ６０として、ワークフロー定義３４は定義転送メッセージｍ６１として、ワークフロー定義３９は定義転送メッセージｍ６２として、モニタシステム５内のワークフロー定義・サービス定義取得部５９へ適宜転送される。

　ワークフロー定義・サービス定義取得部５９は、定義転送メッセージｍ６０、ｍ６１、ｍ６２を受信すると、その定義転送メッセージの形式を判断する。標準化された形式であるWS-BPELやWSDLではない他の形式の定義転送メッセージｍ６２を受信したのであれば、予めワークフロー定義・サービス定義取得部５９内部に設けられている処理系によって、標準化された形式であるWS-BPEL及びWSDLに等価変換した後で保持・管理する。

　WS-BPEL及びWSDLのような標準記述以外の形式でワークフロー定義３９が記述される形式でも、通常はWS-BPEL及びWSDLの標準形式とほぼ等価な情報項目を持つことが一般的である。

　以上から、本実施形態に係るサービス提供品質制御装置では、WS-BPEL及びWSDLの標準形式に等価的に変換可能なもののみを対象としている。

　その後、ワークフロー定義・サービス定義取得部５９は、定義転送メッセージｍ６０、ｍ６１、ｍ５２を受信又は変換にすることよって得られた、標準化形式であるWS-BPEL及びWSDLによるワークフロー定義３１、３４、３９相当の情報を全て内部に保持する。なお、外部に設けられたリポジトリ６に保存することも可能である。

　モニタシステム５内には、ワークフロー定義・サービス定義取得部５９が管理するワークフロー定義３１、３４、３９相当の情報や他の情報を元に、統合されたワークフロー定義を新たに合成するワークフロー合成部６０と、合成したワークフロー定義を格納管理する合成ワークフロー定義６１とが設けられている。

　ワークフロー合成部６０は、要素となる全てのワークフロー定義を得るため、ワークフロー定義・サービス定義取得部５９を適宜起動する。ワークフロー定義・サービス定義取得部５９は、リポジトリ６に対して問い合わせｍ８５を実施することにより、既に内部で保持しているワークフロー定義３１、３４、３９相当の情報の他に、統合・合成ワークフローの要素となる残りの全てのワークフロー定義・サービス定義情報ｍ６４を入手する。リポジトリ６を備えない構成の場合には、この問い合わせは行わない。

　その後、ワークフロー定義・サービス定義取得部５９は、統合・合成ワークフローの要素となるワークフロー定義３１、３４、３９相当の情報及び、ワークフロー定義・サービス定義情報ｍ６４相当の情報を、全てのワークフロー定義・サービス定義情報ｍ６５として、ワークフロー合成部６０に引き渡す。

　ワークフロー合成部６０は、統合・合成されたワークフロー定義を生成するとともに、統合・合成されたワークフロー定義を生成するための元情報になった全てのワークフロー定義・サービス定義情報ｍ６５とともに統合・合成されたワークフロー定義の一式ｍ６６を合成ワークフロー定義６１へ渡す。なお、ワークフロー合成部６０が、統合・合成されたワークフロー定義を生成する手順は、特開２００７－２５７５１３号公報に開示されているような公知の方法を適用可能である。

　従って、合成ワークフロー定義６１には、ワークフロー定義３１、３４、３９相当の情報と、全てのワークフロー定義・サービス定義情報ｍ６４相当の情報と、統合・合成されたワークフロー定義とが含まれて管理されている。

　ワークフローシステム１の各種イベント抽出部によって抽出されたイベント情報は、ワークフローシステム１内のイベントデータ保持部４０に一時的に保管され、適宜、共通データ送信部４１によってイベントデータ転送メッセージｍ２９としてモニタシステム５へ転送される。モニタシステム５では、イベントに関する全てのデータを受信するイベントデータ受信部６２がイベントデータ転送メッセージｍ２９を受信して処理する。

　ワークフローシステム２の各種イベント抽出部によって抽出されたイベント情報は、ワークフローシステム２内のイベントデータ保持部４２に一時的に保管され、適宜、共通データ送信部４３によってイベントデータ転送メッセージｍ６３としてモニタシステム５へ転送される。モニタシステム５では、イベントデータ受信部６２がイベントデータ転送メッセージｍ６３を受信して処理する。

　これに対して、Proxyシステム４の各種イベント抽出部によって抽出されたイベント情報は、Proxyシステム４内のイベントデータ保持部４５に一時的に保管される。

　また、Proxyシステム４と連携するワークフローシステム３内の各種イベント抽出部によって抽出されたイベント情報は、ワークフローシステム３内の共通データ送信部４７からイベントデータ転送メッセージｍ５４としてProxyシステム４へ送信される。

　Proxyシステム４には、共通データ受信部４６が設けられており、これを用いてイベントデータ転送メッセージｍ５４を受信する。その後、イベントデータ転送メッセージｍ５４に記載された全てのイベント情報は、イベントデータ保持部４５に一時的に保管される。

　イベントデータ保持部４５内に一時的に保管した、イベントに関する全てのデータは、適宜、共通データ送信部４４によってイベントデータ転送メッセージｍ５５としてモニタシステム５へ転送される。モニタシステム５では、イベントデータ受信部６２がイベントデータ転送メッセージｍ５５を受信して処理する。

　イベントデータ受信部６２は、イベントに関する全てのデータｍ６７を、イベントデータ関係付け部６３に引き渡す。イベントデータ関係付け部６３は、統合・合成したワークフロー定義を格納管理する合成ワークフロー定義６１を参照し、内部に管理されるサービス定義・プロセス定義情報ｍ６８を検索、参照しながら、イベントに関する全てのデータｍ６７の各々がどのサービス・プロセスのメッセージインスタンスに相当するかを整理、関係付け、かつ現在イベント・統計格納ＤＢ６５にて管理されるメッセージインスタンス群ｍ６９を検索の上で、関係付ける。その後、新たなメッセージインスタンスｍ７０のレコードとしてイベント・統計格納ＤＢ６５に格納する。

　イベント・統計格納ＤＢ６５には、イベントに関する全てのデータｍ６７の各々のみが保持・管理されるだけではなく、サービスごとの単位時間当たりのメッセージ流通量や、通信失敗によって棄却されたメッセージ数等の統計処理のみで事実事項を導出把握できる各種パラメータ群に相当する計測統計量群が計算された後、保持・管理される。これらは、サービスの挙動を表すパラメータを意味する。

　ここでのサービスとは、業務アプリケーションシステム７を呼び出すためのデータ通信部１３、及び業務アプリケーションシステム８を呼び出すためのデータ通信部１４を、WSDLのサービス記述等で仮想化して定義したインタフェースを意味する。

　同様に、業務アプリケーションシステム９を呼び出すためのデータ通信部１５、及び業務アプリケーションシステム１０を呼び出すためのデータ通信部１６、並びに業務アプリケーションシステム１１を呼び出すためのデータ通信部１８をWSDLのサービス記述等で仮想化して定義したインタフェースもサービスに相当する。

　サービスごとの各種パラメータ群に相当する計測統計量群は、サービスのいくつかを選択して組み合わせて構成される複雑な構造を持つ統合・合成ワークフローの処理件数等、シミュレーションを利用して推定しなければ算出できない性質のものではなく、計測できるものに限る。さらに、時刻的な要素に依存して決まる場合も存在する。

　スカラ量を持つサービスごとの各種パラメータ群を任意時刻ｔの下で定式化すると、下記式（５）のような、行列式（Ｚ）で与えられる。これは、時刻ｔにおいてスカラ量を持つ全ての可観測（厳密には「可計測」）な選択パラメータの集合を構成し、可観測である記号（Ａ）で表した上記全てのサービス集合に対して行列表現したものである。

　これに対して、後述する合意サービス水準に関するパラメータ群を意味するベクトル値群は、時刻ｔに対する行列式γ_(i,s)(t)から非線形写像を通して求められ、下記記号（Ｉ）で表される全てのワークフロー定義集合の要素におけるスカラ量を持つワークフローに関する評価パラメータの集合を下記式（６）の行列式（Ｙ）で表現したものとして定義される。

　なお、式（６）のワークフロー定義とは、ワークフロー定義３１、３４やワークフロー合成部６０によって合成・統合されたワークフロー定義のいずれでも良い。

　以上の計算の処理能力を向上するため、いくつかの前処理が実施される。この前処理は、図１５のステップＳ１０１に相当する。

　図１１において、メタデータ管理部６６は、統合・合成されたワークフロー定義ｍ７３や、それを生成するための元情報となった全てのワークフロー定義３１、３４、３９相当の情報及び他の全てのワークフロー定義・サービス定義情報ｍ６４の情報を定義情報一式ｍ７４として合成ワークフロー定義６１やリポジトリ６から取り出し、メモリ上に管理する。

　その後、メタデータ管理部６６は、全ての統合・合成されたワークフロー定義ｍ７３と末端のサービス定義との関係を定義情報一式ｍ７４から求める。これは、例えばWhileループ、条件分岐等を加味して累積呼出度数として定義される。Whileループの最大数を度数とカウントし、条件分岐をそれぞれ１度数としてカウントし、最大度数で規格化したもので計算され、統合・合成されたワークフロー定義と末端のサービス定義とに応じた行列式で表現される。その後、この情報もメモリ上に管理する。

　この行列式は、度数を変数ｄで表すと、式（７）、（８）で表される。

　図１１において、計測統計量群を算出する計測統計量データ計算部６７は、サービス定義ごとに、計測統計量群を求める。統合・合成されたワークフロー定義が別のワークフロー要素と一致するような場合は、必要かつ可能であれば、要素ワークフロー定義ごと、統合・合成されたワークフロー定義ごとにも、該当する計測統計量群を求める。このため、計測統計量データ計算部６７は、統合・合成されたワークフロー定義の一覧ｍ７５と、一覧ｍ７５の各々を生成するための元情報となった全てのワークフロー定義・サービス定義ｍ７６とをメタデータ管理部６６から入手し、メモリ上に管理する。

　その後、イベント・統計格納ＤＢ６５に格納されている全てのイベントデータの中から算出対象に関係するイベントデータを取り出すため、計測統計量データ計算部６７は、イベント・統計格納ＤＢ６５を管理する計測制御量データ管理部６４に検索要求ｍ７１を適宜送信する。検索要求ｍ７１は、計算内容に依存するため、常に同じ内容になるとは限らない。計測制御量データ管理部６４は、検索要求ｍ７１を受信すると、イベント・統計格納ＤＢ６５を検索し、その結果を計測統計量データ計算部６７へ送信する。これにより、計測統計量データ計算部６７は、算出対象に関係するイベントデータの一覧ｍ７２を得る。これは、図１５のステップＳ１０２に相当する。

　その後、計測統計量データ計算部６７は、統合・合成されたワークフロー定義の一覧ｍ７５と、一覧ｍ７５の各々を生成するための元情報となった全てのワークフロー定義・サービス定義ｍ７６とを参照して、計測統計量群として算出されるパラメータ群を順次算出する。これは、図１５のステップＳ１０３に相当する。

　その後、算出された計測統計量群は、計測制御量データ管理部６４及びパフォーマンスデータ管理部６８に格納される。これは、図１５のステップＳ１０４に相当する。以上の処理は、図１５にも示すように、計測統計量群を構成・定義するパラメータ数分だけ実施される（ステップＳ１０５）。

　ここで、具体例として、パラメータ１、２の現時点での算出値、時刻的な要素を含んだ算出値等を求める場合を例示する。計測統計量データ計算部６７は、パラメータ１の算出から実施する。

　現時点でのパラメータ１を算出するため、計測統計量データ計算部６７は、イベント・統計格納ＤＢ６５を管理する計測制御量データ管理部６４に検索要求ｍ７１を送信する。この結果、計測制御量データ管理部６４は、イベント・統計格納ＤＢ６５を検索し、その結果計測統計量データ計算部６７は、算出対象に関係するイベントデータの一覧ｍ７２を得る（ステップＳ１０２）。その後、計測統計量データ計算部６７は、現時点のパラメータ１の値を算出する（ステップＳ１０３）。

　その後、パラメータ１の算出結果を揮発させることなく維持・管理するため、イベント・統計格納ＤＢ６５に格納する。このため、計測統計量データ計算部６７は、算出結果を含めた更新要求ｍ７７を計測制御量データ管理部６４へ送信する。これにより、パラメータ１の算出結果は、イベント・統計格納ＤＢ６５に時刻情報とともに格納される（ステップＳ１０４）。

　また、当該パラメータ１を算出した後、その算出結果を後続の評価・計算で高速に処理するため、計測統計量データ計算部６７はメモリ上に値を管理するパフォーマンスデータ管理部６８に対して、算出結果を含めた更新要求ｍ７７に相当する管理要求ｍ８１を送信する。これによりパフォーマンスデータ管理部６８において、パラメータ１の算出結果が時刻情報とともに管理される（ステップＳ１０４）。

　同様に、現時点のパラメータ２を算出するため（ステップＳ１０５／Ｎｏ）、計測統計量データ計算部６７は、イベント・統計格納ＤＢ６５を管理する計測制御量データ管理部６４に検索要求ｍ７１とは異なる検索要求ｍ７１’を送信する。この結果、計測制御量データ管理部６４は、イベント・統計格納ＤＢ６５を検索し、その結果、計測統計量データ計算部６７は算出対象に関係するイベントデータの一覧ｍ７２’を得る（ステップＳ１０２）。その後、計測統計量データ計算部６７は、現時点でのパラメータ２の値を算出する（ステップＳ１０３）。

　パラメータ２の算出結果もイベント・統計格納ＤＢ６５に格納するため、計測統計量データ計算部６７は、算出結果を含めた更新要求ｍ７８を計測制御量データ管理部６４に送信する。これにより、パラメータ２の算出結果は、イベント・統計格納ＤＢ６５に時刻情報とともに格納される（ステップＳ１０４）。

　パラメータ２を算出した後も、その算出結果を後続の評価・計算で高速に処理するため、計測統計量データ計算部６７は、メモリ上に値を管理するパフォーマンスデータ管理部６８に対して、算出結果を含めた更新要求ｍ７８に相当する管理要求ｍ８２を送信する。これにより、パフォーマンスデータ管理部６８にて、パラメータ２の算出結果が時刻情報とともに管理される（ステップＳ１０４）。

　同様に、指定時刻時点または現時点までのパラメータ１の累積値・平均値を算出するため（ステップＳ１０５／Ｎｏ）、計測統計量データ計算部６７は、イベント・統計格納ＤＢ６５を管理する計測制御量データ管理部６４に検索要求ｍ７１の一部を変更した新たな検索要求ｍ７１を送信する。これを受けて計測制御量データ管理部６４はイベント・統計格納ＤＢ６５を検索し、その結果、計測統計量データ計算部６７は算出対象に関係するイベントデータの一覧ｍ７２を得る（ステップＳ１０２）。その後、計測統計量データ計算部６７は、パラメータ１の各種の値を算出する（ステップＳ１０３）。

　パラメータ１の指定時刻時点の算出結果及び統計処理に関する算出結果も、イベント・統計格納ＤＢ６５に格納するため、計測統計量データ計算部６７は、算出結果を含めた更新要求ｍ７９を計測制御量データ管理部６４に送信する。これにより、パラメータ１の指定時刻時点の算出結果及び統計処理に関する算出結果は、イベント・統計格納ＤＢ６５に時刻情報とともに格納される（ステップＳ１０４）。

　パラメータ１の指定時刻時点の算出結果及び統計処理に関する算出結果も、その結果を後続の評価・計算で高速に処理するため、計測統計量データ計算部６７は、メモリ上に値を管理するパフォーマンスデータ管理部６８に対して計測統計量算出結果を含めた更新要求ｍ７９に相当する管理要求ｍ８３を送信する。これによりパフォーマンスデータ管理部６８において、パラメータ１の指定時刻時点の算出結果及び統計処理に関する算出結果が時刻とともに管理される（ステップＳ１０４）。

　同様に、指定時刻時点又は現時点までのパラメータ２の累積値・平均値等を算出するため（ステップＳ１０５／Ｎｏ）、計測統計量データ計算部６７は、イベント・統計格納ＤＢ６５を管理する計測制御量データ管理部６４に検索要求ｍ７１’の一部を変更した新たな検索要求ｍ７１’を送信する。これを受けて計測制御量データ管理部６４はイベント・統計格納ＤＢ６５を検索し、その結果、計測統計量データ計算部６７は算出対象に関係するイベントデータの一覧ｍ７２’を得る（ステップＳ１０２）。その後、計測統計量データ計算部６７は、パラメータ２の各種の値を算出する（ステップＳ１０３）。

　パラメータ２の指定時刻時点の算出結果及び統計処理に関する算出結果も、イベント・統計格納ＤＢ６５に格納するため、計測統計量計算部６７は、算出結果を含めた更新要求ｍ８０を計測制御量データ管理部６４に送信する。これにより、パラメータ２の指定時刻時点の算出結果及び統計処理に関する算出結果は、イベント・統計格納ＤＢ６５に時刻情報とともに格納される（ステップＳ１０４）。

　パラメータ２の指定時刻時点の算出結果及び統計処理に関する算出結果も、その結果を後続の評価・計算で高速に処理するために、計測統計量計算部６７は、メモリ上に値を管理するパフォーマンスデータ管理部６８に対して、算出結果を含めた更新要求ｍ８０に相当する管理要求ｍ８４を送信する。これにより、パフォーマンスデータ管理部６８にて、パラメータ２の指定時刻時点の算出結果及び統計処理に関する算出結果が時刻情報とともに管理される（ステップＳ１０４）。

　上記の事項を、計測統計量群を構成・定義するパラメータ数分だけ（ステップＳ１０５／Ｙｅｓとなるまで）繰り返し適宜実施する。特に、時刻に関連するパラメータを扱うので定期的に計算を行う。

　〈制御時の動作〉
　本実施形態に係るサービス提供品質制御装置の制御時の動作について、図１２～図２１を用いて説明する。
　図１２、１３に、本実施形態に係るサービス品質制御装置のサービス品質制御時の動作を示す。図１５～１７は、制御手順を示すフローチャートである。図１８は、操作候補を選別する際の手順を示すフローチャートである。図１９～２１は、制御操作策定を実施する手順を示すフローチャートである。

　状態観測部７０は、起動制御部６９からサンプリング周期に応じた起動要求ｃ１を受けると、パフォーマンスデータ管理部６８がメモリ上で管理している複数のパラメータ群に関する現在の値及び累積値・平均値等を得る。例えば、現時点のパラメータ１の算出結果ｃ４、現時点までのパラメータ１の累積値・平均値ｃ５、現時点のパラメータ２の算出結果ｃ６、現時点までのパラメータ２の累積値・平均値ｃ７である。上記のように、パラメータ１、パラメータ２は、統計処理のみで事実事項を把握できる性質のものであり、サービスの挙動を意味するパラメータ群である。

　さらに、状態観測部７０は、メタデータ管理部６６がメモリ上に管理している統合・合成されたワークフロー定義の一覧ｃ２と、一覧ｃ２の各々を生成するための元情報となった全てのワークフロー定義・サービス定義の定義情報一式ｃ３とを入手する。その後、パラメータ１及びパラメータ２をサービス定義ごとに集計し、パラメータ１及びパラメータ２等を要素元とするベクトル値を定義する。その後、サービス群のベクトル値を全てのサービスで序列化した上記式（５）で表現される行列を定義する。

　そして、サンプリングした時刻の状態を意味する行列をサンプリング時刻の状態行列ｃ８として保持する。これに対して、状態行列ｃ８のサンプリング時刻よりも１サンプリング周期遡り、算出され保持管理されている行列ｃ８と同等のサンプリング時刻１周期前の状態行列ｃ９も引き続き保持される。これは図１５のステップＳ１０６に相当する。

　その後、状態観測部７０は、「サンプリング時刻の状態行列ｃ８」及び「サンプリング時刻１周期前の状態行列ｃ９」と、「全てのサービスを呼び出している要素ワークフローについて定義し、ワークフロー定義３１、３４、３９に相当してサービス群と要素ワークフロー群との関係を示し、定義情報一式ｃ３に相当する定義情報一式ｃ１０」と、「統合・合成されたワークフロー定義の一覧ｃ２に相当する統合・合成されたワークフロー定義の一式ｃ１１」とを引数・入力として、補償機能付きシミュレーション処理部７１を起動するための起動（Invoke）コマンドｃ１２を送信する。

　補償機能付きシミュレーション処理部７１は、サンプリング時刻の状態行列ｃ８及びサンプリング時刻１周期前の状態行列ｃ９から導出される時間補正後の同等行列を元に、統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４を推定計算する。なお、この値はシミュレーション時間の補償を実施した形で複数算出される。

　補償機能付きシミュレーション処理部７１の構成を図１４に示す。補償機能付きシミュレーション処理部７１は、内部に挙動関数を１以上有する。そしてシミュレーション処理時間に応じて、同じイメージを持つ挙動関数１２０が複数生成される。挙動関数１２０では、フィードフォーワード制御に伴う推定のための手続きや、シミュレーションに伴う演算時間遅れ補償を含んでのシミュレーションの実行回数等の管理等の起動管理も行う。

　挙動関数１２０は、三つの部分から構成される。
　一つ目は、定義情報一式ｃ１０のうち、要素ワークフローについて定義及び統合・合成されたワークフロー定義の一覧ｃ１１に関連し、ワークフローの持つ順序機械的な挙動をシミュレートする順序機械シミュレーション部１２１、１２１’である。

　二つ目は、定義情報一式ｃ１０のうち、全ての末端のサービス群の挙動特性を表現し、指定条件下での挙動をシミュレートするサービス特性関数計算部１２４である。

　三つ目は、補償機能付きシミュレーション処理部７１が、シミュレーション実施後に外部に戻す合意サービス水準に関するパラメータに基づくベクトル値群を計算処理するために挙動関数１２０内に設けられた処理系１３０である。

　サービス特性関数計算部１２４は、可観測で線形性を持つ末端のサービス群を、等価な振る舞いを定義して扱うのに対して、順序機械シミュレーション部１２１、１２１’は、ワークフローの持つ順序機械的な挙動をシミュレートし、その動作タイミングのみを等価的に扱う。

　この動作は、Seiichi Koizumi, Kazuya Koyama, “Workload-aware Business Process Simulation with Statistical Service Analysis and Timed Petri Net”, Proceedings of the 2007 IEEE International Conference on Web Service (ICWS 2007), 2007.　に参照される公知の原理に基づいた動作を適用可能である。

　順序機械シミュレーション部１２１、１２１’は、統合・合成されたワークフロー定義の一式ｃ１１の定義数に応じて複数生成され、処理上の待ち合わせ制約以外は独立に実行される。これに対して、サービス特性関数計算部１２４は一つのみ生成される。

　サービス特性関数計算部１２４には、全ての末端サービス群の挙動に関する事前計測の特性データを保持している。例えば、業務アプリケーションシステム７の挙動に関する特性データは業務アプリケーションシステム挙動特性定数１２５で表現される。これは単純なスカラ量の場合もあるし、決められたパラメータ値の組み合わせであるベクトル量やテンソル量の場合もある。

　同様に、業務アプリケーションシステム８の挙動に関する特性データは、業務アプリケーションシステム挙動特性定数１２６で表現される。同様に、業務アプリケーションシステム９の挙動に関する特性データは、業務アプリケーションシステム挙動特性定数１２７で表現される。同様に、業務アプリケーションシステム１０の挙動に関する特性データは、業務アプリケーションシステム挙動特性定数１２８で表現される。

　そして、サービス特性関数計算部１２４に、ある時点の計測統計量群のパラメータ群を与えると、業務アプリケーションシステム挙動特性定数１２５～１２８に基づいて、評価対象とする別パラメータ群が算出される。例えば、サービスごとに要求されるサービス要求到着率というパラメータ群をサービス特性関数計算部１２４に与えることで、平均応答時間などのパラメータ群が算出される。

　サービス特性関数計算部１２４は、等価的な振る舞いを算出する関数である。このため、サービスが複雑な構成を持つ場合でもモデルとしては対応可能となる。ただし、線形性を持ち可観測で等価的な振る舞い定義ができる特性を持つもののみが対象となる。例えば、業務アプリケーションシステム７と業務アプリケーションシステム１０とで、表だって定義されていない何らかの関連があり、業務アプリケーションシステム７のパラメータ群の変動に応じて、因果関係として何らかの変動が、業務アプリケーションシステム１０に見られる場合、その挙動特性等を取り扱うことができるようになる。

　業務アプリケーションシステム挙動特性定数１２５～１２８は、固定的に保持することも可能であるが、通常は起動時に設定され、補償機能付きシミュレーション処理部７１の起動中はメモリ上に適当な定数として保持される。

　順序機械シミュレーション部１２１、１２１’の各々は、統合・合成されたワークフロー定義の各々に基づいて生成される。それらは、統合・合成されたワークフロー定義が呼び出している要素ワークフローモデル群１２２、１２３を内部に有する。要素ワークフローモデル群１２２、１２３は、WS-BPELで記載される情報であるワークフロー定義３１、３４、３９を等価変換して定義される。

　要素ワークフローモデル群１２２、１２３の記述方法は、ペトリネットや順序機械などで定義されるが、ここではペトリネットを利用するものとする。なお、順序機械など他の方法で要素ワークフローモデル１２２、１２３を実現しても良い。

　補償機能付きシミュレーション処理部７１が動作する場合は、起動コマンドｃ１２を受け付けた後、統合・合成されたワークフロー定義の一式ｃ１１の定義数に応じて順序機械シミュレーション部１２１、１２１’が複数生成され、その各々に定義情報一式ｃ１０に基づいて統合・合成されたワークフロー定義が呼び出している要素ワークフローモデル群１２２、１２３が生成される。

　補償機能付きシミュレーション処理部７１における処理を開始する場合、順序機械シミュレーション部１２１が起動し、先頭に位置付けられる要素ワークフローモデル群１２２に対して、統合・合成されたワークフロー定義の一式ｃ１１の各々に対して期待されるサービス要求到着率に応じたペトリネットのトークンを発火させる。このトークンは複数発生する。

　任意のトークンが任意のプレースに到着し、次のアクションの発火条件が揃った場合、順序機械シミュレーション部１２１はその際のアクションを実施させる。アクションの一つが業務アプリケーションシステム８を呼び出す場合、サンプリング時刻１周期前の状態行列ｃ９と、サンプリング時刻の状態行列ｃ８とから導出される時刻補償後の同等行列を元にサービス特性関数計算部１２４を呼び出す。その後、サービス特性関数計算部１２４は、評価対象とする別パラメータ群を算出し、処理系１３０にトークンの指定とともにパラメータ群ｃ８０を送付する。その後、サービス特性関数計算部１２４は、処理を順序機械シミュレーション部１２１へ戻す。

　パラメータ群ｃ８０は、サービスごとに要求されるサービス要求到着率に対する平均応答時間などが相当する。

　上記の手順で、一つのトークンに対してペトリネット終了状態になるまでアクションを実施する。そして、上記処理を複数のトークンに対して並行して実施する。

　処理系１３０は、算出されたパラメータ群ｃ８０をトークンの指定とともに受信する。その後、複数発生するパラメータ群ｃ８０をトークンごとにとりまとめ、パラメータ群ｃ８０の要素ごとに総和などの計算処理を行い、計算パラメータ群ｃ８１を求める。この計算処理は、パラメータの内容に応じて利用する数式が異なる。以上の一連の手続を繰り返すことで、ある統合・合成されたワークフロー定義の処理一つに対する実行内容をシミュレートできる。

　トークンが複数発生するため、計算パラメータ群ｃ８１に対する統計処理を実施することで、処理系１３０は統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４を計算できることになる。

　これは、順序機械シミュレーション部１２１、１２１’は、統合・合成されたワークフロー定義の一式ｃ１１の定義数に応じて複数生成されるので、統合・合成されたワークフロー定義の一式ｃ１１に含まれる総数分の計算を補償機能付きシミュレーション処理部７１の１回のシミュレーションで実行することになるためである。

　この結果を受けて、補償機能付きシミュレーション処理部７１は、合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４をシミュレーション実施後に外部に戻すことになる。

　なお、補償機能付きシミュレーション処理部７１内部の挙動関数１２０は、シミュレーションに伴う演算時間遅れ補償、及びフィードフォーワードに伴う推定のための手続を行う。ここで補償の際に参照される補償条件に応じて、統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４の値も変わってくる。

　以上の補償機能付きシミュレーション処理部７１の起動に伴う一連の手続は、図１５のステップＳ１０７及びＳ１０８に相当する。

　なお、合意サービス水準に関するパラメータ群は、上記式（６）と同型を持つ行列式で定義されるが、シミュレーションに伴う演算時間遅れ補償、及びフィードフォーワードに伴う推定を含む。シミュレーションに伴う演算時間遅れ補償及びフィードフォーワードに伴う推定の方法と時間軸に対する振る舞い定義については、図２２を用いて後段で説明する。

　その後、補償機能付きシミュレーション処理部７１は、図１５のステップＳ１０７、Ｓ１０８について、ｐ回（ｐは１以上の整数）だけ繰り返し実施する（ステップＳ１０９）。サービス提供品質制御装置では、補償機能付きシミュレーション処理部７１による推定計算総数は、制御の１サンプリング周期で最大２ｐ回実施されることになるが、そのうちの前半のｐ回をこの段階で連続的に実施する。

　その後、後の評価に利用するため、「統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４」と同じ値を持つベクトル値群ｃ１４’をバッファ部７９に時刻とともに出力し、管理・保持する。図１５のステップＳ１１０に相当する。

　その後、「統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群」を意味するベクトル値群ｃ１４を評価する目的で、補償機能付きシミュレーション処理部７１は、ベクトル値群ｃ１４を引数・入力として、検出部７３を起動するための再起動コマンドｃ１５を検出部７３へ送信する。

　検出部７３は、起動後の初期化処理にて、目標状態ベクトル値管理部７２が管理する複数サービス利用者ごとに取り決めた「合意サービス水準に関する目標値群のベクトル値群ｃ１６」を事前に読み込んでいる。

　合意サービス水準に関する目標値群のベクトル値群ｃ１６は、大きく三つの部分から構成される。一つ目は、合意サービス水準に関する目標値群のベクトル値群そのもの、二つ目は、目標状態ベクトル値管理部７２が合意サービス水準に関する目標値群のベクトル群ｃ１６を管理コンソール８１にて登録する際に入力される相対優先度に関する情報ｃ６２に相当する情報、三つ目は、合意サービス水準に関する目標値群のベクトル値群を構成するパラメータ値群間の相対情報に相当する情報である。

　一つ目の部分を定式化すると、下記式（９）で与えられる。

　ここではスカラ量を持つ全てのワークフローの評価パラメータ集合全ての要素に関して何らかの評価値が指定され、時間変動なく一定と見なされる。これがＳＬＡ情報を制御目標とする目標状態ベクトル値として定義される。

　二つ目の部分を任意の優先度関数ｐｔ（ｍ）を用いて定式化すると、下記式（１０）で与えられる。

　三つ目の部分を任意のパラメータ間の優先度関数pp(j,m)を用いて定式化すると、下記式（１１）で与えられる。

　上記の三つの部分を元に検出部７３は、優先度評価の固有値を事前に計算する。

　図１３において、検出部７３は、再起動コマンドｃ１５を補償機能付きシミュレーション処理部７１から受信すると、合意サービス水準に関する目標値群のベクトル値群ｃ１６から計算される優先度評価の固有値（式（９））と、ベクトル値群ｃ１４（式（６））とをもとに、新たに制御偏差行列を推定計算する。

　ただし、これには推定値が含まれるため、単純に式（６）の形式を用いることができず、式（１２）に記す同型の推定値にて表現される。（下記（Ｊ）に示す表示形式が、シミュレーション時間を補償した、補償時刻Δｔにおける推定値を意味する。）

　式（１２）において、制御偏差は式（９）で表現される目標値に対するずれ幅として表現される。ここで偏差の計算にあたっては特別な評価関数は用いない。逆に単純差分で定義できるように各種パラメータの定義が工夫される。

　式（１２）などで計算される制御偏差に基づき、制御条件を判定する。これは図１６のステップＳ１１１に相当する。この手順では、ベクトル値群ｃ１４が十分であり、かつ目標値群のベクトル値群ｃ１６の全てを上回っているか否かを評価するため、全てのベクトル値群の成分に対して実施する（ステップＳ１１２）。

　なお、ベクトル値群ｃ１４が十分であっても目標値群のベクトル値群ｃ１６の全てを上回っていない場合も存在する。この場合は、例えば、合意サービス水準に関する目標値群のベクトル値群ｃ１６を構成するパラメータ値群間の相対情報を用いて、重大な影響を与えるか否かを判断しても良い。

　検出部７３は、制御条件を判定した結果、制御偏差が満足できるものではない場合、又は事前に制御偏差を満足していても制御条件の変更がなされていない場合は、評価条件調整部７４を起動することになる（ステップＳ１１３／Ｎｏ）。なお、図１６においては、制御偏差が満足できるものでない場合に［Ｎｏ］となる。さらに、事前に制御偏差を満足していても制御条件の変更がなされていない場合は［ＹＥＳ｛制御条件変更フラグ未セット｝］となる（ステップＳ１１３／Ｙｅｓ）。

　図１３においては、評価条件調整部７４を起動するため、検出部７３は起動コマンドｃ１７を送信する。送信においては、下記式（１３）で与えられる優先度評価の固有値や、上記式（１２）で与えられる制御偏差行列のシミュレーション時間の補償推定値などの必要な情報を引数で渡す。なお、起動コマンドｃ１７の送信に先立ち、制御の１サンプリング周期内で補償機能付きシミュレーション処理部７１を規定回数以上実施しているか否かの判定を行う（ステップＳ１１４）。

　上記判定の結果、既に規定回数のｐ以上実施していた場合は（ステップＳ１１４／Ｙｅｓ）、操作失敗とみなす。この結果、図１６のステップＳ１１５で記されたように、制御条件の変更が成されていない状態に戻し、図１６のステップＳ１１６を実施するためのアラームｃ９１を送信する。

　これに対して、補償機能付きシミュレーション処理部７１を規定回数以上実施しておらず（ステップＳ１１４／Ｎｏ）、起動コマンドｃ１７を受けて評価条件調整部７４が起動すると、制御のための操作を開始する。評価条件調整部７４は、図１８に示す手順に基づき、図１６のステップＳ１１７に相当する処理を実施する。

　ステップＳ１１７での処理を詳細に説明する。
　評価条件調整部７４は、統合・合成されたワークフロー定義と全てのワークフロー定義・サービス定義の一覧とから個々のサービス定義に関する呼出度数について計算した行列値（上記式（７）で定義される行列値）に関するデータｃ８２をメタデータ管理部６６から取り出して読み込む。これは図１８のステップＳ２０１に相当する。

　また、評価条件調整部７４は、検出部７３が起動コマンドｃ１７を送信する際に引数として指定した、式（１２）で表現される制御偏差行列のシミュレーション時間の補償の推定値を入手する。これは図１８のステップＳ２０２に相当する。

　また、評価条件調整部７４は、検出部７３が起動コマンドｃ１７を送信する際に引数として指定した式（１３）で表現される優先度評価の固有値を入手する。ここで式（１３）は評価を重畳するので、式（１０）と式（１１）との単純積で計算される。これは図１８のステップＳ２０３に相当する。

　評価条件調整部７４が制御操作対象を選定するため、統合・合成されたワークフロー定義レベルの統合プロセスの全体評価を鳥瞰する必要がある。これは任意時刻ｔにて下記式（１４）で表現される。

　式（１４）では式（１３）の転置行列をもとに、下記式（１５）で与えられるクロネッカーのδ_(u,v）を関数に持つ特殊行列を掛けている。この特殊行列は、計算された結果生成される新たな行列に対して、対角部分の要素であるときは１を、それ以外は０の値を持つ。この結果、作成される（ｍ，ｍ）行列の対角部分の値を取ることで、実数値を持つ任意時刻ｔ時の統合プロセスの評価済み偏差ベクトルは下記式（１６）のように定義できる。なお、偏差行列は推定値偏差行列（式（１２））を用いる。

　この結果、評価条件調整部７４は、上記式（１６）と式（７）とを通して補償された任意時刻ｔ＋Δｔに対するサービスの影響度を推定できる。これは図１８のステップＳ２０４に相当する。

　また、評価条件調整部７４は、評価感度・ボトルネックの評価のため、パフォーマンスデータ管理部６８に管理されている該当する計測統計量データｃ８３を取り出す。これは図１８のステップＳ２０５に相当する。

　その後、評価条件調整部７４は、評価済み偏差ベクトル（式（１６））と呼出度数について計算した行列値（式（７））とを基に、サービス影響度のモデル化の計算を下記式（１７）によって行う。これは、図１８のステップＳ２０６に相当する

　その後、評価条件調整部７４は、式（１７）によって計算されるサービス影響度のモデル化と計測統計量データｃ８３とを基に一次結合した評価式を下記式（１８）のように定義する。上記式（１７）は、総合プロセスの論点から、サービスの影響度を推定しているが、感度・ボトルネックの点で妥当でない場合も存在する。そこで、式（５）からボトルネックを意味する妥当なスカラ量であるパラメータを選択し、末端サービスに関するベクトルとして式（１８）のように表現する。一次結合の際の重み付けパラメータは、制御を実施する前段階で実施されるキャリブレーション時に計測、指定されたもので固有値、又は後述する自律調整時の対象パラメータである。これは図１８のステップＳ２０７に相当する。

　その後、評価条件調整部７４は、ある順序で並び替える非線形写像を定義する。そして、サービスのベクトル値として表現される評価式（１８）に対して、各成分間の比較を行い、相互比較等を通してサービス評価を実施する。

　相互比較の方式は、評価式のベクトル成分をスカラ量として見なし、単純に大小ソートする方法でも構わない。これにより評価条件調整部７４は、制御操作対象とするサービスを特定する。これは図１８のステップＳ２０８に相当する。

　続けて評価条件調整部７４は、操作候補のサービスを選定・指定する。これは、図１８のステップＳ２０９に相当する。以上により、制御操作対象の選定手順を終了する（ステップＳ２１０）。

　その後、評価条件調整部７４は、図１６のステップＳ１１８に相当する処理を実施する。これは、適正な操作量を決定するために、補正機能付きシミュレーション処理部７１を使ってｐ回評価する場合、成功するまで毎回、追加する仮操作量の記録を取っておき、失敗時にさらに追加する仮操作量を指定することで、仮操作条件を厳しいものにするためのものである。ここでは、仮操作したサービスの位置に関する情報も読み込まれる。

　その後、評価条件調整部７４は、図１６のステップＳ１１９に相当する処理を実施する。処理の詳細については、図１９～２１のフローチャートに示す。評価条件調整部７４は、制御操作に対する適用順番、及び評価関数を得るためにポリシ記述管理部７５から、制御操作に対するポリシ定義情報ｃ１９を得る。

　その後、評価条件調整部７４は、図１９のステップＳ３０１から処理を開始すると、図１６のステップＳ１１８時に把握した、仮操作したサービスの位置に関する情報を取得する。これは、図１８のステップＳ２０８で特定した操作対象のサービス群から選択されるものである。この動作は、図１９ではステップＳ３０２に相当する。

　その後、評価条件調整部７４は、図１６のステップＳ１１８時に得た、実施済み操作量についての指定の有無を判断する（ステップＳ３０３）。１回目の操作の場合（ステップＳ３０３／Ｎｏ）、特に実施済み操作量についての指定は存在しないので、次の判断である図１６のステップＳ１１１における検出部による制御偏差の条件判定（ステップＳ３０７）まで進む。

　これに対して、１回以上の操作を実施している場合は（ステップＳ３０３／Ｙｅｓ）、さらに、実施済み操作条件の次にできる操作を判定する（ステップＳ３０４）。この判定は、制御操作に対するポリシ定義情報ｃ１９を元に判定する。

　ここで、次に実施できる操作が存在する場合は（ステップＳ３０４／存在）、評価条件調整部７４は、次の判断である図１６のステップＳ１１１における検出部による制御偏差の条件判定（ステップＳ３０７）まで進む。

　これに対して、既に仮操作したサービスの位置を変えても、次に実施できる操作が存在しない場合（ステップＳ３０４／存在せず）、図１９のステップＳ３０５に進む。この状態で、実施済みの操作量についての指定は存在していないが、１度シミュレーションによる推定計算、及び検出部７３による制御条件の判定した結果、実施できる操作が存在しうる可能性も残るので、図１９のステップＳ３０５を実施するためのアラームｃ８４を送信する。その後、評価条件調整部７４は、図１９のステップＳ３０６に処理を移し、一連の制御装置部群の仮設定量設定を終了する。

　実施済み操作条件の次にできる操作が存在する場合、評価条件調整部７４は、図１６のステップＳ１１１における検出部による制御偏差の条件判定で、適合しているか否かを判断する（ステップＳ３０７）。

　条件判定で適合していない場合は（ステップＳ３０７／Ｎｏ）、［ＮＯ］が選択され、さらに次の判断であるデフォルト指定よりも制御操作に対するポリシ定義情報ｃ１９を優先して判定するか否かについて判断する（ステップＳ３１２）。なお、デフォルト指定の意味については後段で説明する。優先する場合は（ステップＳ３１２／Ｙｅｓ）［ＹＥＳ］を選択して図２０のステップＳ３１３に進む。これに対して、優先しない場合は（ステップＳ３１２／Ｎｏ）、［ＮＯ］を選択し、図２０のステップＳ３１５に進む。

　図１６のステップＳ１１１における検出部７３による制御偏差の条件判定で、適合しているか否かを判断した結果、適合している場合は［ＹＥＳ］が選択され（ステップＳ３０７／Ｙｅｓ）、さらに次の判断であるデフォルト指定よりも制御操作に対するポリシ定義情報ｃ１９を優先して判定するか否かについて判断する（ステップＳ３０８）。優先する場合は（ステップＳ３０８／Ｙｅｓ）、［ＹＥＳ］を選択し、図１９のステップＳ３０９に進む。これに対して優先しない場合は（ステップＳ３０８／Ｎｏ）［ＮＯ］を選択し、図２１のステップＳ３２２に進む。

　図１６のステップＳ１１１における検出部による制御偏差の条件判定で適合している場合（ステップＳ３０７／Ｙｅｓ）、十二分な実施環境であることとなる。そこで、さらに効率的なサービス実行ができるか否かを判断することが必要となる。そのため、サービス実行処理系のＣＰＵ資源・メモリ資源等を削減することで有効利用を実施できるか否かを評価する。

　ここで、制御操作には少なくとも４種類の操作手法が存在する。

　一番目のものは、サービス実行処理系のＣＰＵ資源・メモリ資源等の追加など資源操作に関するものである。これを“資源操作による制御操作手法”と称することとする。これは具体的には、図１２のワークフローシステム１の環境が制御メッセージｃ５０を受信するとワークフローエンジン２９、２９’の起動・停止について評価し、必要に応じてワークフローエンジン２９を起動・停止、処理内容の変更等の制御を行う制御コマンドｃ５３を送信するととともに、同様にワークフローエンジン２９’を起動・停止、処理内容の変更等の制御を行う制御コマンドｃ５４を送信することなどが相当する。

　二番目のものは、サービス実行処理系に対するメッセージ投入抑制を実施することに関するものであり、ボトルネックとなっている処理よりも上流側にあるサービス処理群の整流化に基づくものである。これを、“制約に対する整流化による制御操作手法”と称することとする。具体的には、プロキシ部３５の任意メッセージ受信後、相当するメッセージを送信する前に、その内容に応じて、投入抑制部５７によって一時的に抑制し、受信した任意のメッセージをキュー管理部５８に含めることなどが相当する。

　三番目のものは、実施状況中のサービスを取り決められた範囲で強制的に棄却することによってサービス実行処理系のＣＰＵ資源・メモリ資源等の開放を行うことである。これは具体的には、プロキシ部３５の任意メッセージ受信後相当するメッセージを送信する前にその内容に応じて投入抑制部５７によって一時的に抑制し、強制棄却部５６を用いて強制的に棄却することなどが相当する。これを、“強制棄却による制御操作手法”と称する。

　四番目のものは、末端のサービスの呼出順序を合意サービス水準に関する目標値群のベクトル値群ｃ１６を満足するように動的に変更することである。この方法の具体例については、統合・合成したワークフローを定義する段階で、変更を加え再配布することで末端のサービス呼出定義を並行可能化し、これによって実現する。これを“再編成による制御操作手法”と呼ぶ。

　前述のデフォルト指定とは、上記の４種類の操作手法のうち、一番目、二番目、三番目のものを図２０、図２１のステップＳ３１７、ステップＳ３２１、ステップＳ３１９、ステップＳ３２０、ステップＳ３２４、ステップＳ３２５のように組織したものを意味する。

　これに対して、制御操作に対するポリシ定義情報ｃ１９では、上記の４種類の操作手法を含んだ任意の評価関数として定義される。デフォルト指定よりも制御操作に対するポリシ定義情報ｃ１９を優先して判定するか否かについて判断する際に優先の［ＹＥＳ］を選択し、図２０のステップＳ３１３、Ｓ３１４に進んだ場合も、デフォルト指定と同じく上記４種類の操作手法のうち、一番目、二番目、三番目のものも実施されるとともに、より効果的な操作手法が存在する場合は、操作手法を利用することが可能となる。

　図２０のステップＳ３１３に進むと、図１６のステップＳ１１８時に把握した制御操作に対するポリシ定義情報ｃ１９を基に実施済み操作量について判定する。その後、制御操作に対するポリシ定義情報ｃ１９を改めて参照し、次操作を特定し、図２０のステップＳ３１４に進む。

　図１９のステップＳ３０９に進むと、図１６のステップＳ１１８時に把握した制御操作に対するポリシ定義情報ｃ１９を元に実施済み操作量について判定する。その後、制御操作に対するポリシ定義情報ｃ１９を改めて参照し、次操作を特定し、図１９のステップＳ３１０に進む。

　図１６のＳ１１１における検出部７３による制御偏差の条件判定で、適合しておらず（ステップＳ３０７／Ｎｏ）、かつ制御操作に対するポリシ定義情報ｃ１９を優先せずにデフォルト指定を優先した場合（ステップＳ３１２／Ｎｏ）、評価条件調整部７４は、図２０のステップＳ３１５に処理を進める。

　ステップＳ３１５に進むと、図１６のステップＳ１１８時に把握した、制御操作に対するポリシ定義情報ｃ１９を基に実施済み操作量について判定する。その後、制御操作に対するポリシ定義情報ｃ１９を改めて参照し、次操作・仮操作したサービス位置に関する情報も判定する。

　デフォルト指定の場合、仮操作を施すサービスに対して通信を行うワークフローエンジンや関連する処理系に対して、その処理台数を追加することで、単位ワークフローエンジン当たりの処理サービス件数を減じることが構成上可能か否かを判断する（ステップＳ３１６）。ここで、処理台数を追加することが可能な場合（ステップＳ３１６／Ｙｅｓ）［ＹＥＳ］を選択し、図２０のステップＳ３１７に進む。

　仮操作を施すサービスに対して通信を行うワークフローエンジンや関連する処理系に対して、処理台数を追加することが不可能な場合（ステップＳ３１６／Ｎｏ）、［ＮＯ］を選択し、抑制操作に関する判断を行う（ステップＳ３１８）。抑制操作とは、上記の４種類の操作手法のうち、二番目の“制約に対する整流化による制御操作方法”に相当する。

　抑制操作に関する判断において、仮操作を施すサービスに対して抑制操作を既に実施していない場合は（ステップＳ３１８／Ｎｏ）、まず抑制操作を優先的に実施するため、［ＮＯ］を選択し、ステップＳ３２１に進む。抑制操作はサービス実行処理系に対するメッセージ投入抑制を実施するため、メッセージの棄却等が発生せず、より安全なため、優先的に実施を試みる。

　ここで、抑制操作に関する判断において、仮操作を施すサービスに対して抑制操作を既に実施している場合は（ステップＳ３１８／Ｙｅｓ）、これ以上の抑制操作が効果的でないと判断し、強制棄却操作を実施するため［ＹＥＳ］を選択し、図２０のステップＳ３１９に進む。ここで、強制棄却操作とは、上記の４種類の操作手法のうち、三番目の“強制棄却による制御操作手法”に相当する。

　図１６のステップＳ１１１における検出部７３による制御偏差の条件判定で適合しており（ステップＳ３０７／Ｙｅｓ）、かつ制御操作に対するポリシ定義情報ｃ１９を優先せずにデフォルト指定を優先した場合（ステップＳ３０８／Ｎｏ）、評価条件調整部７４は、図２１のステップＳ３２２に処理を進める。

　ステップＳ３２２に進むと、図１６のステップＳ１１８時に把握した制御操作に対するポリシ定義情報ｃ１９を基に実施済み操作量について判定する。その後、制御操作に対するポリシ定義情報ｃ１９を改めて参照し、次操作、仮操作したサービスの位置に関する情報も判定する。

　ステップＳ３２２では、前述のように十二分な実施環境である。そのため、デフォルト指定の場合、仮操作を施すサービスに対して通信を行うワークフローエンジンや関連する処理系に対して、その処理台数を削減し、単位ワークフローエンジン当たりの処理サービス件数を効率化することが構成上可能か否かを判断する（ステップＳ３２３）。ここで、処理台数を削減することが可能な場合（ステップＳ３２３／Ｙｅｓ）、［ＹＥＳ］を選択し、図２１のステップＳ３２４に進む。

　仮操作を施すサービスに対して通信を行うワークフローエンジンや関連する処理系に対して処理台数を削減することが不可能な場合（ステップＳ３２３／Ｎｏ）、［ＮＯ］を選択し図２１のステップＳ３２５に進む。

　評価条件調整部７４は、図２０のステップＳ３１４において、制御操作に対するポリシ定義情報ｃ１９で指定される次操作を指定し、追加する仮操作量記述を仮制御操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　図２０のステップＳ３２１において、評価条件調整部７４は、仮操作を施すサービス実行処理系に対するメッセージ投入抑制を実施するため、抑制操作を指定する。その際、任意の評価関数に基づいて抑制操作に関するパラメータである抑制時間、抑制に関する比率等が決定される。その後、評価条件調整部７４は、追加する仮操作量記述を仮操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　図２０のステップＳ３１９において、評価条件調整部７４は、仮操作を施すサービスに対して強制棄却操作を行うため、強制棄却操作を指定する。その際、任意の評価関数に基づいて、許容しうる強制棄却数等のパラメータが決定される。その後、評価条件調整部７４は、追加する仮操作量記述を仮制御操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　図２０のステップＳ３２０において、評価条件調整部７４は、強制棄却操作によって引き起こされる補償動作に関する見積もりを行う。その後、評価条件調整部７４は、追加する仮操作量記述として、追加のシミュレーション条件を仮制御操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　評価条件調整部７４は、図１９のステップＳ３１０において、制御操作に対するポリシ定義情報ｃ１９で指定される次操作を指定し、追加する仮操作量記述を仮制御操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　図２１のステップＳ３２４において、評価条件調整部７４は、仮操作を施すサービスに対して通信を行うワークフローエンジン、関連する処理系に対する処理台数削減操作を指定する。その際、任意の評価関数に基づいて処理台数が決定される。その後、評価条件調整部７４は、追加する仮操作量記述を仮制御操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　図２１のステップＳ３２５において、評価条件調整部７４は、仮操作を施すサービス実行処理系に対するメッセージ投入抑制を変更するため、指定サービスへの到着率抑制解除操作を指定する。その際、任意の評価関数に基づいて解除操作に関する評価を行い、解除操作の内容を決定する。抑制の解除を行うことで整流化が崩れるため、ボトルネックとなっているサービスの位置が変化することが起こりうる。しかし、不必要な抑制を解除することで、仮操作を施すサービスに対して通信を行うワークフローエンジンや、関連する処理系に関する利用可能な容量を相対的に増加することができる。

　その後、評価条件調整部７４は、変更・解除する仮操作量記述を仮制御操作一覧指定情報ｃ２１に追加する。その後、図１９のステップＳ３１１に進む。

　図１９のステップＳ３１１では、ステップＳ３１４、Ｓ３１７、Ｓ３２１、Ｓ３１９、Ｓ３２０、Ｓ３１０、Ｓ３２４、Ｓ３２５によって処理された結果、更新された仮操作サービス位置に関する情報を仮制御操作一覧指定情報ｃ２１に追加する。その後、ステップＳ３０６に進む。

　図１９のステップＳ３０６では、既に評価した回数がｐ回に達していない場合、次回目の評価を行うため、評価条件調整部７４は、時刻補償を行った上で、仮制御操作一覧指定情報ｃ２１を引数に追加して、補償機能付きシミュレーション処理部７１を再起動する再起動コマンドｃ２０を送信する。これにより、図１６のステップＳ１１９に相当する処理を終了させる。

　その後、評価条件調整部７４は、図１６のステップＳ１２０として、仮制御操作一覧指定情報ｃ２１に相当する情報を、内部的に保存する。これにより、適正な操作量を決定するために、補償機能付きシミュレーション処理部７１を使ってｐ回評価する場合、各回で追加した仮操作量の記録、及び仮操作したサービス位置の記録が取られ、図１６のステップＳ１１８時に得た実施済み操作量についての指定を特定することが可能となる。

　その後、評価条件調整部７４は、制御条件の変更がなされていることを記すため、図１６のステップＳ１２１にて制御条件変更フラグをセットする。そして、評価条件調整部７４は、処理を終了する。

　補償機能付きシミュレーション処理部７１が、再起動コマンドｃ２０によって再起動すると、既に引数として与えられていた「サンプリング時刻状態行列ｃ８」、「サンプリング時刻１周期前の状態行列ｃ９」、「全てのサービスを呼び出している要素ワークフローについて定義し、ワークフロー定義３１、３４、３９に相当してサービス群と要素ワークフロー群との関係について定義し、定義情報一式ｃ３に相当する定義情報一式ｃ１０」、「統合・合成されたワークフロー定義の一覧ｃ２に相当する統合・合成されたワークフロー定義の一式ｃ１１」を継承し、さらに仮制御操作一覧指定情報ｃ２１が参照されることになる。

　さらに、補償機能付きシミュレーション処理部７１は、必要に応じて仮制御操作一覧指定情報ｃ２１の参照先情報であり、ポリシ記述管理部７５が管理する制御操作に対するポリシ定義情報ｃ１３を得る。

　補償機能付きシミュレーション処理部７１は、その後、統合・合成されたワークフロー定義の一覧ｃ２に相当する統合・合成されたワークフロー定義の一式ｃ１１に基づいて、全ての統合・合成されたワークフロー定義に対して、図１６のステップＳ１２２を実施する。

　この結果、下記式（１９）で表される行列式を得る。これは、補償された時刻ｔ＋Δｔ_１に対してスカラ量を持つ全ての可観測（厳密には「可計測」）な選択パラメータ集合を構成し可観測である全てのサービス集合（上記記号（Ａ））に対して行列表現した式γ_(I,s)(t+Δt₁)に対してあるポリシに従って作為変動させ、上記式（６）と同一の非線形写像を通して求められ、全ての評価パラメータ集合（スカラ量）、全てのプロセス定義集合（上記記号（Ｉ））の要素に対して、実数推定値を持つことを意味する。その場合、時刻補償値は、図２０で後述するように変化するため、時刻t+Δt₂となる。なお、識別子Ｃは、制御操作後の評価を意味する。

　その後、仮制御操作一覧指定情報ｃ２１に基づき、新たに計算された「統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群」を意味するベクトル値群ｃ１４を再評価する目的で、ベクトル値群ｃ１４を引数・入力として検出部７３を起動するための再起動コマンドｃ１５を再送信する（ステップＳ１２３／Ｙｅｓ）。

　検出部７３は、起動後の初期化処理にて、複数サービス利用者ごとに取り決められた「合意サービス水準に関する目標値群のベクトル値群ｃ１６」を、前回と同様に目標状態ベクトル値管理部７２から事前に読み込んでいる。そして、前回と同様に、新たな制御偏差行列を計算し、新規制御偏差に基づき、制御条件を判定する。これは、図１６のステップＳ１１１に戻されるループに相当する。

　検出部７３は、仮制御操作一覧指定情報ｃ２１に基づく制御条件を判定した結果、制御偏差を満足し、制御条件の変更がなされている場合は（ステップＳ１１３／Ｙｅｓ）、評価条件調整部７４を起動する代わりに、調整操作部７６を起動する。図１３では、調整操作部７６を起動するために、検出部７３は、起動コマンドｃ１８を送信する。この場合、図１６では［ＹＥＳ｛制御条件変更フラグセット｝］という形で指定される。

　調整操作部７６は、起動後、各種制御装置部群に実際の操作量を指示するため、評価条件調整部７４が内部保存している仮制御操作一覧指定情報ｃ２１に相当する仮制御操作一覧指定情報ｃ２２を読み出し、仮制御操作一覧指定情報ｃ２２を確定し、実際の操作量を扱う制御メッセージ等に変換した後で送信する。これは、図１６のステップＳ１２４に相当する。

　その後、調整制御部７６は、一連の制御操作を終了したため、図１６のステップＳ１２５によって制御条件変更フラグをリセットし、初期状態に戻す。そして、調整操作部７６は、処理を終了する。

　その後、各種制御装置部群は、制御メッセージを受信すると、図１６のステップＳ１２６にて、実際の制御操作を実行する。

　制御メッセージの具体例として、図２０のステップＳ３２１において指定される抑制操作の場合、操作プロキシ４８内の投入抑制部５１に対して送信される制御メッセージｃ５２、又は、プロキシ部３５内の投入抑制部５７に対して送信される制御メッセージｃ５６等がある。制御メッセージｃ５２、ｃ５６では、抑制する処理要求メッセージ群、処理応答メッセージ群の種類の指定、抑制の定量的な程度を表現するメトリクス等が指定され、これを受けて実際の制御操作が実施される。

　制御メッセージの別の具体例として、図２０のステップＳ３１９において指定される強制棄却操作の場合、操作プロキシ４８内の強制棄却部５０に対して送信される制御メッセージｃ５１、又は、プロキシ部３５内の強制棄却部５６に対して送信される制御メッセージｃ５５などがある。

　制御メッセージｃ５１、ｃ５５は、棄却する処理要求メッセージ群、処理応答メッセージ群の種類の指定、棄却率等の定量的な程度を表現するメトリクス等が指定され、これを受けて実際の制御操作が実施される。

　さらに、制御メッセージの別の具体例として、図２０のステップＳ３１７において指定されるワークフローエンジン、関連する処理系に対する処理台数加減操作の場合、ワークフローシステム１の環境に対して、送信される制御メッセージｃ５０がある。

　その結果、ワークフローシステムの環境は、制御メッセージｃ５０を受信すると、ワークフローエンジン２９、２９’の起動・停止について評価し、必要に応じてワークフローエンジン２９を起動・停止、処理内容の変更等の制御を行う制御コマンドｃ５３を送信するとともに、同様にワークフローエンジン２９’を起動・停止、処理内容の変更等の制御を行う制御コマンドｃ５４も送信する。

　その後、合意サービス水準に基づくサービス提供品質制御装置の処理は、図１５のステップＳ１０１直後に戻される。そして、この１周期はデジタル制御の１サンプリング周期内で実施される。

　〈最適実施例の自律調整時の動作説明〉
　図１３において、起動制御部６９は、補償機能付きシミュレーション処理部７１が指定時点で複数サービス利用者ごとに取り決めた合意サービス水準に関する状態についてのベクトル値群を推定・評価する段階で参照する固定的なパラメータ値群を正しく維持できるように、自律調整の一つである長期補償処理を起動する。

　起動制御部６９は、長期補償処理のため、計測状態ベクトル値処理部７７を起動する起動コマンドｃ２３を送信する。図１５のステップＳ１０４が終了したことを受けて実行される図１５のステップＳ４０１に相当する動作である。この動作は図１３の動作とは並行して行われる動作である。なお、手順２１は、全てのサンプリング周期に従って起動されるとは限らず、複数サンプリング周期に１度の起動も考えられる。

　図１３において、計測状態ベクトル値処理部７７は、補償機能付きシミュレーション処理部７１が推定・評価した合意サービス水準に関する状態についてのベクトル値群に相当する実測のベクトル値群を、イベント・統計格納ＤＢ６５に格納されている全てのイベントデータ、又は任意の有効なイベントデータから遡って計算する。

　以上のような処理を行うために、計測状態ベクトル値処理部７７は、起動コマンドｃ２３を受信すると、メタデータ管理部６６がメモリ上に管理している統合・合成されたワークフロー定義の一覧ｃ２４と、一覧ｃ２４の各々を生成するための元情報となった全てのワークフロー定義・サービス定義の定義情報一式ｃ２５を入手する。

　さらに計測状態ベクトル値処理部７７は、パフォーマンスデータ管理部６８がメモリ上で管理している複数のパラメータ群に関する現在の値、及び累積値・平均値等を得る。例えば、現時点のパラメータ１の算出結果及び現時点までのパラメータ１の累積値・平均値ｃ２６、現時点のパラメータ２の検出結果及び現時点までのパラメータ２の累積値・平均値ｃ２７である。

　さらに、計測状態ベクトル値処理部７７は、統合・合成されたワークフロー定義の一覧ｃ２４と、一覧ｃ２４の各々を生成するための元情報となった全てのワークフロー定義・サービス定義の定義情報一式ｃ２５とを元にして、イベント・統計格納ＤＢ６５に検索をかけ、関連する全てのイベントデータｃ８５を入手し、これを遡って統合・合成されたワークフロー定義の一覧ｃ２４相当のパラメータ群を計算した後、合意サービス水準に関する状態に関する実測ベクトル値群ｃ８６に変換する。

　合意サービス水準に関する状態に関する実測ベクトル値群ｃ８６は、補償機能付きシミュレーション処理部７１が推定・評価する指定時点の複数サービス利用者ごとに取り決めた合意サービス水準に関する状態についてのベクトル値群とは異なり、別の任意の方法で求めた実測のベクトル値群を意味する。

　その後、計測状態ベクトル値処理部７７は、合意サービス水準に関する状態に関する実測ベクトル値群ｃ８６を自ら記録・保持する。図１７ではステップＳ４０２に相当する。

　その後、計測状態ベクトル値処理部７７は、長期補償検出部７８を起動する起動コマンドｃ２８を送信する。起動の際には、実測ベクトル値群ｃ８６相当の情報が引数、実測ベクトル値群ｃ２９として渡される。これは、図１７ではステップＳ４０３に相当する。

　長期補償検出部７８は、計測状態ベクトル値処理部７７が管理する合意サービス水準に関する状態に関する実測ベクトル値群ｃ８６相当の実測ベクトル値群ｃ２９と、バッファ部７９に保持され、補償機能付きシミュレーション処理部７１が推定・評価した、複数サービス利用者ごとに取り決められた合意サービス水準に関する状態についてのベクトル値群と比較する。

　長期補償検出部７８は、バッファ部７９から合意サービス水準に関するパラメータを意味するベクトル値群ｃ３０を入手する。ベクトル値群ｃ３０は、統合・合成されたワークフロー定義の一式ｃ１１ごとに対する合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４’と同一の内容を持つ。これは、図１７では、図１３のステップＳ１１０が完了したことを受けて実行されるステップＳ４０４に相当する。

　その後、長期補償検出部７８は、実測ベクトル値群ｃ２９と、合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ３０とを比較する。その結果、ポリシ記述管理部７５にて管理され、４種類の操作手法を含んだ任意の評価関数と記録される制御操作に対するポリシ定義情報ｃ１９の同定パラメータや、補償の条件式等に、経時変化等による誤差が認められる場合は、ポリシ記述更新コマンドｃ３１や補償条件更新コマンドｃ３２をポリシ記述管理部７５に送信する。

　これは、上記式（１８）指定される１次結合の際の重み付けパラメータ等である。

　ポリシ記述管理部７５は、ポリシ記述更新コマンドｃ３１や補償条件式更新コマンドｃ３２を受信すると、制御操作に対するポリシ定義情報ｃ１９の同定パラメータや補償の条件式等を更新維持する。これにより、補償機能付きシミュレーション処理部７１の推定・評価は一定の精度を維持することが可能となる。これは、図１７ではステップＳ４０５に相当する。

　以上により、起動制御部６９が起動し、長期補償検出部７８によって実施された長期補償処理は終了する。

　〈最適実施例の初期設定時、及び設定時の動作説明〉
　図１２、１３を用いて、本実施形態に係る合意サービス水準に基づくサービス提供品質制御装置の初期設定時、設定時の動作を具体的に説明する。

　モニタシステム５には、サービス提供品質制御装置を運用する際に参照される各種実行条件、各種パラメータ値群を管理している実施条件指定部８０が設けられている。実施条件指定部８０では、起動制御部６９がデジタル制御を行うためにサンプリング周期等の一連のパラメータ等や、アドレス情報等が管理される。

　管理コンソール８１を用いて、実施条件指定部８０が管理するパラメータを更新する場合は、実施条件指定部８０に対して、起動コマンドｃ６５が送信され、更新する旨のコマンド内容と更新するべきパラメータ名群とパラメータ値群ｃ６６等とが指定される。更新の結果は、実施条件指定部８０で管理され、管理コンソール８１に表示される。

　管理コンソール８１を用いて、実施条件指定部８０の管理するパラメータを確認する場合は、実施条件指定部８０に対して起動コマンドｃ６５が送信され、検索する旨のコマンド内容と検索するパラメータ名群やその応答形式を指定した情報ｃ６７とが指定される。検索の結果は、管理コンソール８１に表示される。

　サービス提供品質制御装置によって実現されるべき、複数サービス利用者ごとに取り決めた合意サービス水準に関する目標値群は、目標状態ベクトル値管理部７２にてベクトル値群で管理される。これは、通常SLAと称されるものの一部である。

　合意サービス水準に関する目標値群のベクトル値群は、合意サービス水準に関する目標値群のベクトル値群ｃ１６と等価の構造をもち、大きく三つの部分から構成される。

　一番目は、合意サービス水準に関する目標値群のベクトル値群そのもの、二番目は、相対優先度に関する情報に相当するもの、三番目は、合意サービス水準に関する目標値群のベクトル値群を構成するパラメータ値群間の相対情報に相当するものである。

　管理コンソール８１を用いて、目標状態ベクトル値管理部７２の管理するパラメータを更新する場合は、目標状態ベクトル値管理部７２に対して、起動コマンドをｃ６４が送信される。更新の結果は目標状態ベクトル値管理部７２に管理され、管理コンソール８１に表示される。

　起動コマンドｃ６４は引数として、合意サービス水準に関する目標値群のベクトル値群ｃ６３、その特定情報ｃ８７等を含む。この場合、特定情報ｃ８７は、メタデータ管理部６６が管理する統合・合成されたワークフロー定義ｍ７３や、これを生成するための元情報となった全てのワークフロー定義・サービス定義情報に相当する。

　さらに、起動コマンドｃ６４の引数としては、特定情報ｃ８７に関連付けられ、特定情報ｃ８７が指し示す統合・合成されたワークフローや、他ワークフロー・他サービスに関する相対優先度に関する情報ｃ６２、及び、特定情報ｃ８７に関連付けられ合意サービス水準に関する目標値群のベクトル値群ｃ６３を構成するパラメータ値群間の相対情報ｃ８８が存在する。

　管理コンソール８１を用いて、目標状態ベクトル管理部７２の管理するパラメータを検索する場合は、目標状態ベクトル値管理部７２に対して起動コマンドｃ８９が送信される。

　起動コマンドｃ８９は、特定情報ｃ８７やその応答形式を指定した情報ｃ９０を引数として含む。検索の結果は管理コンソール８１に表示される。

　サービス提供品質制御装置によって実現されるべき制御内容は、ポリシ記述管理部７５にて管理され、４種類の操作手法を含んで構成される。ポリシ記述管理部７５では、制御操作に対するポリシ定義情報ｃ１９として定義され、同定パラメータや補償の条件式等で表現される。サービス提供品質制御装置の初期制御データについては、外部から指定する必要がある。

　管理コンソール８１を用いて、ポリシ記述管理部７５にて管理される初期制御データを更新する場合は、ポリシ記述管理部７５に対して、起動コマンドｃ６０が送信される。起動コマンドｃ６０には、指定パラメータ値群ｃ６１が引数として含まれる。更新の結果は、ポリシ記述管理部７５で管理され、管理コンソール８１に表示される。

　〈制御方法の説明〉
　本実施形態に係る合意サービス水準に基づくサービス提供品質制御を実現するため制御方法を実行する機能モジュール構成を図２３に示す。

　制御方法を実行する機能モジュールとして、サービス提供品質、または複数サービス利用者ごとに取り決めた合意サービス水準等の制御対象２００、実際に決められた操作を実施することで制御対象２００に対して制御・維持を働きかける制御装置部２２３、単位時間当たりのメッセージ流通量等の制御対象２００に関する物理現象のうち、シミュレーションを利用して推定せずに統計処理のみで計測できる物理現象を表現する各種計測統計量群を算出する計測統計量データ計算部２０３、物理現象を意味するイベントに関する形式的な意味等を管理するメタデータ管理部２０１、発生する全てのイベントを関連づけて管理する計測制御量データ管理部２０４、計測統計量群を算出した後、その算出結果を後続計算で利用するため管理するパフォーマンスデータ管理部２０２を含む。

　さらに、制御方法を実行する機能モジュールとして、デジタル制御を行うためにサンプリング周期を指定して、種々のモジュールを起動する起動制御部２０５、制御対象２００に対する任意時点の状態推定のため、パフォーマンスデータ管理部２０２から各種情報を入手し、デジタル制御のサンプリング周期で直前に計測された計測統計量群から成るベクトル値群を現状態ベクトル値２０７、及び１サンプリング周期以前に計測された計測統計量から成るベクトル値群を履歴状態ベクトル値２０８として算出・保持する状態観測部２０６を含む。

　さらに、制御方法を実行する機能モジュールとして、制御対象２００の制御目標に関する目標値群をベクトル値群で表現する目標状態ベクトル値２１６、及び現状態ベクトル値２０７、履歴状態ベクトル値２０８や、後述する各種制御装置部２２３に与えるべき操作量を仮決めした後、それらを元に制御対象２００に関する任意時点の状態推定・評価を行う補償機能付きシミュレーション処理部２１１、補償機能付きシミュレーション処理部２１１が推定する制御対象２００の任意時点の状態に関する推定状態ベクトル値２１５と、推定状態ベクトル値２１５と目標状態ベクトル値２１６とを比較して制御偏差を求め、判断実施する検出部２１７も含む。

　さらに、制御方法を実行する機能モジュールとして、制御偏差が制御操作を必要とする場合、制御装置部２２３に与えるべき制御操作量を随時仮決めし、候補操作ベクトル量２２１として一時的に保存するとともに、これから変更条件ベクトル値２１２を計算し、改めて補償機能付きシミュレーション処理部２１１を使って許容指定回数まで推定・評価し、制御偏差が制御操作を必要としない水準まで、制御操作量の指定調整を行う評価条件調整部２１８と、評価条件調整部２１８が制御操作量を仮決めする際に参照されるポリシ記述部２１９とを含む。

　さらに、制御方法を実行する機能モジュールとして、検出部２１７が求める制御偏差が制御操作を必要としない状況にある場合に、仮決めした制御操作量である候補操作ベクトル量２２１を最終的な制御操作量である確定操作ベクトル２２２に変換する調整操作部２２０を含む。

　さらに、制御方法を実行する機能モジュールとして、補償機能付きシミュレーション処理部２１１が指定時点で精度良く制御対象に関する状態推定・評価できるように推定段階で参照される補償条件２１０と、ポリシ記述部２１９等を適切に維持できるように、制御対象の状態ベクトル値に相当する実測ベクトル値群を過去に遡って、全てのイベントから検算し、計測状態ベクトル２１３を算出する計測状態ベクトル値処理部２０９と、計測状態ベクトル２１３を元に、補償条件２１０やポリシ記述部２１９を更新、維持する長期補償検出部２１４とを含む。

　この制御方法を実行する機能モジュールを、さらに大きな機能モジュールと定義する場合は、計測器２２４、状態推定器２２５、調整器２２６、制御器２２７、長期補償器２２８に分類される。計測器２２４には、メタデータ管理部２０１、パフォーマンスデータ管理部２０２、計測統計量データ計算部２０３、及び計測制御量データ管理部２０４がそれぞれ一つの機能モジュールとして分類される。

　状態推定器２２５には、起動制御部２０５、状態観測部２０６、現状態ベクトル値２０７、履歴状態ベクトル値２０８、補償機能付きシミュレーション処理部２１１の一部の機能、補償条件２１０が含まれる。

　調整器２２６には、補償機能付きシミュレーション処理部２１１の一部の機能、補償条件２１０、推定状態ベクトル２１５、目標状態ベクトル２１６、検出部２１７、変更条件ベクトル２１２、評価条件調整部２１８、ポリシ記述部２１９が含まれる。

　制御器２２７には、制御装置部２２３、候補操作ベクトル２２１、確定操作ベクトル２２２、調整操作部２２０が含まれる。

　長期補償器２２８には、計測状態ベクトル２１３、計測状態ベクトル値処理部２０９、補償条件２１０、長期補償検出部２１４、推定状態ベクトル値２１５が含まれる。

　メタデータ管理部２０１は、図１３でのモニタシステム５内のメタデータ管理部６６に相当する。

　パフォーマンスデータ管理部２０２は、図１３でのモニタシステム５内のパフォーマンスデータ管理部６８に相当する。

　計測統計量データ計算部２０３は、図１３でのモニタシステム５内の計測統計量データ計算部６７に相当する。

　計測統計量データ管理部２０４は、図１３でのモニタシステム５内の計測制御量データ管理部６４に相当する。

　起動制御部２０５は、図１３でのモニタシステム５内の起動制御部６９に相当する。

　状態観測部２０６は、図１３でのモニタシステム５内の状態観測部７０に相当する。

　現状態ベクトル値２０７は、図１３のモニタシステム５内のサンプリング時刻状態行列ｃ８に相当する。

　履歴状態ベクトル値２０８は、図１３のモニタシステム５内のサンプリング時刻１周期前の状態行列ｃ９に相当する。

　補償機能付きシミュレーション処理部２１１は、図１３でのモニタシステム５内の補償機能付きシミュレーション処理部７１に相当する。

　補償条件２１０は、図１３のモニタシステム５内の同名の補償機能付きシミュレーション処理部７１が利用するもので、図１３では特に明示的に定義はされていない。

　推定状態ベクトル値２１５は、図１３のモニタシステム５内のベクトル値群ｃ１４に相当する。

　目標状態ベクトル値２１６は、図１３のモニタシステム５内の目標状態ベクトル値管理部７２の管理する複数サービス利用者ごとに取り決められた合意サービス水準に関する目標値群のベクトル群ｃ１６に相当する。

　検出部２１７は、図１３でのモニタシステム５内の検出部７３に相当する。

　変更条件ベクトル値２１２は、図１３のモニタシステム５内の評価条件調整部７４が扱う仮操作量記述の仮制御操作一覧指定情報ｃ２１の一部に相当する。

　評価条件調整部２１８は、図１３でのモニタシステム５内の評価条件調整部７４に相当する。

　ポリシ記述部２１９は、図１３のモニタシステム５内のポリシ記述管理部７５が管理し、評価条件調整部７４が操作量を仮決めする際に参照するポリシ等に相当する。

　制御装置部２２３は、図１３でのProxyシステム４内の強制棄却部５６や、投入抑制部５７に相当する。

　候補操作ベクトル量２２１は、図１３のモニタシステム５内の評価条件調整部７４が扱う仮制御操作一覧指定情報ｃ２２に相当する。

　確定操作ベクトル量２２２は、図１３のモニタシステム５内の評価条件調整部７４が扱う仮制御操作一覧指定情報ｃ２２に相当する。

　調整操作部２２０は、図１３のモニタシステム５内の調整操作部７６に相当する。

　計測状態ベクトル値２１３は、図１３のモニタシステム５内の実測ベクトル値群ｃ２９に相当する。

　計測状態ベクトル値処理部２０９は、図１３のモニタシステム５内の計測状態ベクトル値処理部７７に相当する。

　長期補償検出部２１４は、図１３のモニタシステム５内の長期補償検出部７８に相当する。

　各機能モジュールの動作について説明する。
　計測制御量データ管理部２０４は、制御対象２００に関する物理現象のうち、シミュレーションを利用して推定せずに、統計処理のみで計測できる物理事象を意味するイベントを時刻とともにスカラ量として、かつ、任意のコンテキストに従って関連づけてイベント情報ｉ３０として取り込む。

　計測統計量データ計算部２０３は、制御対象２００に関する物理事象のうち、シミュレーションを利用して推定せずに、統計処理のみで計測できる物理事象を表現する各種計測統計量群を算出する。算出は、メタデータ管理部２０１が管理する物理事象を意味するイベントが所属するカテゴリ単位で実施される。図１３の場合は、これがサービス定義ごととなる。
　計測統計量計算部２０３は、カテゴリ単位ごとに計測統計量群を求める。このため、メタデータ管理部２０１からカテゴリ単位や、制御対象２００で扱う管理単位に関する形式的な意味の情報ｉ３を入手する。これらの情報はベクトル値の次元数に相当する。また、情報ｉ４は、図１３では統合・合成されたワークフロー定義一覧ｍ７５と、これを生成するための元情報となった全てのワークフロー定義・サービス定義ｍ７６に相当する。

　その後、計測統計量データ計算部２０３は、情報ｉ４に相当する形式的な意味等の情報ｉ３ごとに管理されているイベントを関係付けて管理する計測統計量データ管理部２０４から、イベントに関するデータｉ１を取り出し、計測統計量群として定義されるパラメータ群として定義されるパラメータ群ｉ２を順次算出する。イベントに関するデータｉ１は、図１３での算出対象に関係するイベントのデータ一覧ｍ７２に相当する。

　その後、算出された計測統計量群として定義されるパラメータ群ｉ２は、パフォーマンスデータ管理部２０２に渡される。算出された計測統計量群として定義されるパラメータ群ｉ２は、図１３での更新要求ｍ７７に相当する。この処理は、計測統計量群を構成・定義するパラメータ数分だけ実施され、時刻を含めて管理される。

　状態観測部２０６は、起動制御部２０５からサンプリング周期に応じた起動要求ｉ９を受けると、パフォーマンスデータ管理部２０２が管理している複数の計測統計量を構成・定義するパラメータ群に関する現在の値、及び累積値・平均値等ｉ６を得る。起動要求ｉ９は、図１３では起動要求ｃ１に相当し、パラメータ群に関する現在の値及び累積値・平均値等ｉ６は、図１３では算出結果ｃ４等に相当する。

　さらに、状態観測部２０６は、メタデータ管理部２０１からカテゴリ単位や、制御対象２００で扱う管理単位に関する形式的な意味等を情報ｉ５を得る。情報ｉ５は、図１３では統合・合成されたワークフロー定義の一覧ｃ２と、一覧ｃ２の各々を生成するための元情報となった全てのワークフロー定義・サービス定義の定義情報一式ｃ３に相当する。

　その後、パラメータ群に関する現在の値、及び累積値・平均値等ｉ６をカテゴリ単位ごとに集計し、カテゴリ単位ごとに計測統計量群から成るベクトル値群を算出し、ベクトル値群を全てのカテゴリ単位で序列化した行列を上記式（５）のように定義する。

　そして、サンプリングした時間周期で直前に計測された計測統計量群から成る現状態ベクトル値２０７と同値の現状状態ベクトル値ｉ７、及び１サンプリング周期以前に計測された計測統計量群から成る履歴状態ベクトル２０８と同値の履歴状態ベクトル値ｉ８を生成・保持する。

　その後、状態観測部２０６は、現状態ベクトル値２０７と同値の現状状態ベクトル値ｉ１１、履歴状態ベクトル値２０８と同値の履歴状態ベクトル値ｉ１２と、カテゴリ単位や制御対象２００で扱う管理単位に関する形式的な意味等の情報ｉ５と等価な情報ｉ１０を引数・入力として、補償機能付きシミュレーション処理部２１１を起動する。情報ｉ１０は、図１３の起動コマンドｃ１２の引数に相当する。

　補償機能付きシミュレーション処理部２１１は、補償条件２１０の設定定常値ｉ１３を参照し、フィードフォーワードに伴う推定のための手続き、シミュレーションにともなう演算時間遅れ補償を含み、規定回数以内でシミュレーションを実行し、推定値ｉ１４を計算し、制御対象２００の任意時点の状態に関する推定状態ベクトル値２１５を生成する。これは図１３での合意サービス水準に関するパラメータ群を意味するベクトル値群ｃ１４に相当する。

　補償機能付きシミュレーション処理部２１１は、シミュレーションに伴う演算時間遅れ補償、及びフィードフォーワードに伴う推定のための計算を行う。図２２に、時間軸に対する処理の振る舞いを概念的に示す。

　図２２の横軸２５０は、可観測な実数実連続時間を意味し、実数変数ｔで表現される。これに対して、曲線２５１は、制御対象２００の状態を示す可観測な実数実連続時間ｔに対するベクトル関数のうち、任意の一成分を取り出したスカラ関数の記すスカラ量遷移の軌跡である。

　期間２５３は、デジタル制御のサンプリング周期を意味し、定数Ｔで定義される。時刻２５２は、サンプリング周期Ｔに対して変数ｑで表現されるｑ回目のサンプリング時刻を表す時刻値であり、下記式（２０）で表される。これに対して時刻２５４は、（ｑ＋１）回目のサンプリング時刻を表す時刻値であり、下記式（２１）で表される。
　ｔ（ｑ＋１）＝ｔ_０＋Ｔ（ｑ－１）　・・・（２０）
　ｔ（ｑ）＝ｔ_０＋Ｔｑ　・・・（２１）

　時刻２５５は、平均の計測評価時間を意味し、補償機能付きシミュレーション処理部２１１を使って制御操作に関する条件を算出するのに要する平均時間コストを意味する。これを定数Ｔ_ｅ ^{（ａｖｅ）}で表現する。これに対して、制御操作期間を定数ｆ￠で表現する。定数ｆ￠は０であることが好ましい。時刻２５６は、通常、平均の計測期間と制御操作期間の和を表し、下記式（２２）で表される。
　Δ＋Ｔ_ｅ ^{（ａｖｅ）}　・・・（２２）

　本実施形態においては、補償機能付きシミュレーション処理部２１１は、推定のための計算は１サンプリング周期に対して任意の２ｐ回を総数として実施する。

　この場合、定数ｐとは、検出部２１７を使って補償機能付きシミュレーション処理部２１１が推定する制御対象２００の任意時点での状態に関する推定状態ベクトル２１５と、推定状態ベクトル２１５と目標状態ベクトル２１６とを比較して制御偏差を求め、判断するための最大ループ回数とに相当する。

　この制御方式で検出部２１７を使って最大ｐ回の制御偏差を算出、判断するのは、制御対象２００の任意時点の状態が、例えば非線形性を持ち簡単には定式化されないため、推定値算出が極めて難しく、ある程度のポリシを持つものの、制御操作について試行錯誤を許容することを前提としているためである。

　検出部２１７による判断の結果、ｐ回までに制御偏差の判断条件を満足できない場合もある。この場合、時刻２５６は、最大許容計測評価期間を意味することになり、補償機能付きシミュレーション処理部２１１を規定回数実施しうるのに許容できる限界時間を意味する。これを定数Ｔ_ｅ ^{（ｍａｘ）}で表現すると、時刻２５６は下記式（２３）で表される。
　ｔ＝ｔ_０＋Ｔ（ｑ－１）＋Ｔ_ｅ ^{（ｍａｘ）}　・・・（２３）

　この制御方式では、補償機能付きシミュレーション処理部２１１のような計算量を要する構成モジュールが存在する。このため演算時間遅れに対して、なんらかの補正を行う必要がある。これを「演算時間遅れ補償」と称する。これは、二つの点で重要である。

　一つは、定数ｐの設定条件であり、定数ｐが成立するためには、演算時間遅れを考慮して上限を設ける必要がある。補償機能付きシミュレーション処理部２１１、検出部２１７、評価条件調整部２１８の全てを含んだ平均演算時間を定数Ｔ_ｃとした場合、下記式（２４）が成立するように定数ｐが設定される必要がある。
　Ｔ_ｅ ^{（ａｖｅ）}／２ｐ＜Ｔ_ｃ　・・・（２４）

　もう一つは、検出部２１７を使って制御偏差を算出・判断するため、補償機能付きシミュレーション処理部２１１が起動する時刻についても時間補償を行う必要がある。補償機能付きシミュレーション処理部２１１の演算コストの影響が大きいほど重要となってくる。

　このため、本実施形態の制御方式では、平均計測評価期間Ｔ_ｅ ^{（ａｖｅ）}を、補償機能付きシミュレーション処理部２１１による推定計算総数２ｐで分割した時間を単位時間として定義する。１回目の単位時間２５８は下記式（２５）で表される。
　ｔ＝ｔ_０＋Ｔ（ｑ－１）＋Ｔ_ｅ ^{（ｍａｘ）}／２ｐ　・・・（２５）

　この制御方式では、補償機能付きシミュレーション処理部２１１による推定計算総数２ｐのうち、前半のｐ回では連続的に推定計算を実施し、後半のｐ回で評価条件調整部２１８が制御操作量を仮設定する時刻時点の制御対象２００に関する状態推定の計算を行う。

　これに対して後半のｐ回では、前半のｐ回で推定計算した指定時点の制御対象２００に関する状態を入力として、評価条件調整部２１８が制御操作量を仮設定した状況下の、制御対象２００に関する状態を推定計算する。

　具体的には、下記式（２６）で計算される時刻２５９において、ｔ＝ｔ_０＋Ｔ（ｑ－２）ｔ_０＋Ｔ（ｑ－１）時点の上記式（５）の行列値（Ｋ）、（Ｌ）をもとに、線形外挿を用いて補償し、補償機能付きシミュレーション処理部２１１を用いて下記式（２７）で表現される値を推定する。なお、表示形式（Ｚ）は推定値を意味する。
　ｔ＝ｔ_０＋Ｔ（ｑ－１）＋Ｔ_ｅ ^{（ａｖｅ）}／２ｐ　・・・（２６）

　また、下記式（２８）で計算される時刻２６０において、上記式（５）のもとに、線形外挿を用いて補償し、補償機能付きシミュレーション処理部２１１を用いて、下記式（２９）で表される値を推定する。なお、表示形式（Ｚ）は、シミュレーション時間を補償した補償時刻Δｔにおける推定値を意味する。
　ｔ＝ｔ_０＋Ｔ（ｑ－１）＋Ｔ_ｅ ^{（ａｖｅ）}／ｐ　・・・（２８）

　一般には式（３０）で計算される時刻において、上記式（５）をもとに線形外挿を用いて補償し、補償機能付きシミュレーション処理部２１１を用いて下記式（３１）で表される値を推定する。なお、上記表示形式（Ｚ）は、シミュレーション時間を補償した補償時刻Δｔにおける推定値を意味する。
　ｔ＝ｔ_０＋Ｔ（ｑ－１）＋ｒ・Ｔ_ｅ ^{（ａｖｅ）}／２ｐ　・・・（３０）

　また、下記式（３２）で計算される時刻２６１において、上記式（２６）で計算される時刻２５９で推定した上記式（２７）をもとに、検出部２１７が判断し、上記式（１２）、式（１７）、式（１８）を用いて制御するべきサービスを判定した上、評価条件調整部２１８が制御操作量を仮決めし、補償機能付きシミュレーション処理部２１１を用いて下記式（３３）を再推定する。なお、上記表示形式（Ｚ）は、シミュレーション時間を補償した補償時刻Δｔにおける推定値を意味し、識別子Ｃは制御操作後の評価を意味する。

　その後、上記式（１２）と同型で制御操作御の評価を意味し、下記記号（Ｍ）であらわされる制御偏差を評価する。制御偏差の全ての成分が負となる場合は制御する必要はない。異なる場合は、下記式（３４）を実施し、次の制御操作量を評価する。

　ｑ←ｑ＋１　・・・（３４）

　一般に、下記式（３５）で表される時刻で推定した下記式（３６）をもとに検出部２１７が判断し、上記式（１２）、式（１７）、式（１８）を用いて制御するべきサービスを判定した上、評価条件調整部２１８が制御操作量を仮決めし、補償機能付きシミュレーション処理部２１１を用いて下記式（３７）で再推定する。なお、表示形式（Ｊ）は、シミュレーション時間を補償した補償時刻Δｔにおける推定値を意味し、識別子Ｃは制御操作後の評価を意味する。

　その後、上記式（１２）と同型で制御操作後の評価を意味する制御偏差（表示形式（Ｍ））を評価する。制御偏差の全ての成分が負となる場合は制御する必要はない。

　図２０での過渡現象について説明する。通常、制御対象に制御操作を実施しても、即座に望ましい状態になるとは限らない。このため、時間に対して過渡現象が発生する。制御操作を実行してからスカラ関数で示すスカラ量遷移が安定するまでを過渡期間と呼ぶ。これは、制御対象２００でも同様であり、過渡期間を定数τで表現する。時刻２５７は、過渡現象安定化までのみなし時刻を意味し、下記式（３８）で表される。
　ｔ＝ｔ_０＋Ｔ（ｑ－１）＋Ｔ_ｅ ^{（ｍａｘ）}＋τ　・・・（３８）

　上記式（２５）から式（３７）の各式を算出する処理は、図１５ではステップＳ１０８に相当する。上記式（６）と同型の式にて表現されるが、時間補償値となる。

　その後、補償機能付きシミュレーション処理部２１１は、図１５のステップＳ１０７、Ｓ１０８相当の処理について、全回数繰り返し実施する。なお、図２２に示すとおり、制御対象２００の任意時点の状態に関する推定状態ベクトル値２１５は、補償条件２１０の設定定常値ｉ１３に応じて値が変わってくる。

　補償機能付きシミュレーション処理部２１１は、推定状態ベクトル２１５を評価する目的で、検出部２１７を起動する。その際の引数・入力は図１３では再起動コマンドｃ１５の引数に相当する。

　検出部２１７は、制御対象２００で扱う管理単位ごとに定義される目標状態ベクトル値２１６を事前に保持する。検出部２１７は、優先度の固有値を事前に計算している。

　その後、検出部２１７は、目標値群のベクトル値群２１６と同値なベクトル値ｉ１７と、推定状態ベクトル値２１５と同値なベクトル値ｉ１６とからシミュレーション時間の補償を実施した形で、制御偏差行列を推定計算する。

　検出部２１７は、制御偏差に基づいて制御条件を判定する。この判定基準はいくつか存在しうる。制御条件を判定した結果制御偏差が満足できるものでない場合は、評価条件調整部２１８を起動する。

　評価条件調整部２１８の起動においては、制御偏差行列のシミュレーション時間の補償の推定値等の必要情報は引数ｉ１８で渡される。また、評価条件調整部２１８の起動に先立ち、１回の制御のサンプリング周期内で、補償機能付きシミュレーション処理部２１１を規定回数以上実施しているか否かを判定する。引数ｉ１８は、図１３では起動コマンドｃ１７の引数に相当する。

　上記判定の結果、既に規定回数のｐ以上実施している場合は、操作失敗と見なす。操作失敗時の挙動についてはここでは規定しない。

　これに対して、補償機能付きシミュレーション処理部２１１を規定回数以上実施していない場合、補償機能付きシミュレーション処理部２１１が起動される。その際、評価条件調整部２１８は、ポリシ記述部２１９を元に制御操作量を仮決めする。

　制御操作量を仮決めするにあたっては、複数の制御装置群の中から制御候補とする制御装置部２２３を選択する方法と、操作方法の内容について選択する方法とが重要となる。

　複数の制御装置部群の中から、制御候補とする制御装置部２２３を選択する方法については、例えば、制御偏差値を並び替え、制御対象２００で扱う管理単位のうち最も大きな制御偏差値に関係した管理単位を扱う制御装置部２２３を選択することが一例として挙げられる。ただし、これ以外の方法も適用可能である。

　さらに、操作方法の内容について選択する方法では、制御操作量そのものの種類と大きさとを決定する方法が重要となる。制御操作量そのものの種類は、ポリシ記述部２１９に記載され、主に四つの方法から選択される。

　一番目は、制御対象２００で扱う管理単位のうち、最も大きな制御偏差値に関係した管理単位を移動させるか、又は制御偏差値を現象させることにより、その管理単位に関係する物理事象の処理能力を局所的に強化することである。これは、上記の“資源操作による制御操作手法”に相当する。

　二番目は、制御対象２００で扱う管理単位のうち、最も大きな制御偏差値に関係した管理単位を移動させることによって、その管理単位以外の管理単位に関係する物理事象の処理能力を平滑化し、制御対象２００に関する物理事象の処理能力を全体的に向上させる方法である。これは、上記の“制約に対する整流化による制御操作手法”に相当する。

　三番目は、制御対象２００に関する物理事象が許容できる以上の発生が確認される場合に、制御対象２００で扱う管理単位のうち、最も大きな制御偏差値を減少させることによって、制御対象２００に関する物理事象を強制的に一部放棄し、処理能力を許容できる程度に保つ方法である。これは、上記の“強制棄却による制御操作手法”に相当する。

　四番目は、制御対象２００で扱う管理単位のうち、最も大きな制御偏差値に関係した管理単位を移動させるか、または制御偏差値を減少させることによって、その管理単位に関係する処理手順を変更し、物理事象の処理能力を時間的に分散化させることである。これは、上記の“再編成による制御操作手法”に相当する。

　制御操作量の手続の例は、図１８の手順に相当する。また、仮決めされた制御操作量は全て候補操作ベクトル２２１として保持するため、更新情報ｉ２３によって最新のものが記録される。

　更新情報ｉ２３は、補償機能付きシミュレーション処理部２１１を規定回数まで繰り返して呼び出すたびに、その指定内容を追加し、厳しくしていく。

　仮決めされた制御操作量はｉ２１として算出され、その後、評価条件調整部２１８は変更条件ベクトル値２１２を生成する。その後、変更条件ベクトル２１２を参照させるように、引数ｉ１９で参照先を指定し、補償機能付きシミュレーション処理部２１１を再起動する。

　再起動した結果、補償機能付きシミュレーション処理部２１１は、変更条件ベクトル値２１２から同値のベクトル値ｉ２２を参照し、シミュレーション時間を補償した補償時刻時点での制御操作後の制御対象２００の状態に関する推定状態ベクトル値２１５を再計算する。

　検出部２１７は、再度起動され、再計算された制御偏差に基づき、制御条件を判定する。制御条件の判定の結果、制御偏差が満足するものであり、制御条件の変更がなされている場合は、評価条件調整部２１８を起動する代わりに調整操作部２２０を起動する。その際の必要情報は引数ｉ２４で渡される。引数ｉ２４は、図１３では起動コマンドｃ１８の引数に相当する。

　調整操作部２２０は、起動後、各種制御装置部群に実際の操作量を指示するため、候補操作ベクトル量２２１からベクトル値ｉ２５を得る。その後、調整操作部２２０は、ベクトル値ｉ２５から最終的な制御操作量である確定操作ベクトル量２２２と同値なベクトル値ｉ２６に変換する。そして、必要情報を引数ｉ２７として制御装置部２２３を起動する。

　制御装置部２２３は、通常、複数存在しており、確定操作ベクトル量２２２から必要なスカラ量、又はベクトル値ｉ２８を取り出し、各制御操作を実施する。各制御装置部２２３の制御操作量ｉ２９に応じて、制御対象２００が制御され、所望の状態を得る。

　必要なスカラ値又はベクトル値ｉ２８は、図１２では操作プロキシ４８内の強制棄却部５０に対して送信される制御メッセージｃ５１、又はプロキシ部３５内の強制棄却部５６に対して送信される制御メッセージｃ５５となる。

　起動制御部２０５は、補償機能付きシミュレーション処理部２１１が指定時点で精度良く制御対象に関する状態推定・評価できるように、推定段階で参照される補償条件２１０、ポリシ記述部２１９等に適切に維持できるように計測状態ベクトル値処理部２０９を指定時間周期で起動する。その際に必要な引数はｉ３３で渡される。

　計測状態ベクトル値処理部２０９は、起動すると、パフォーマンスデータ管理部２０２が管理している複数の計測統計量群を構成・定義するパラメータ群に関する現在の値、及び累積値・平均値等ｉ３１を得る。さらに、計測状態ベクトル値処理部２０９は、メタデータ管理部２０１からカテゴリ単位や制御対象２００で扱う管理単位に関する形式的な意味等の情報ｉ３２を得る。

　その後、計測状態ベクトル値処理部２０９は、制御対象２００の状態ベクトル値に相当する実測ベクトル値群を過去に遡って全てのイベントから検算し、計測状態ベクトル２１３と同値のベクトル値ｉ３４を算出する。その後、計測状態ベクトル値２１３を生成する。

　その後、計測状態ベクトル値処理部２０９は、長期補償検出部２１４を起動する。その際に必要な引数はｉ３６で渡される。長期補償検出部２１４は、計測状態ベクトル２１３と同値のベクトル値ｉ３４と、補償機能付きシミュレーション処理部２１１が生成した制御対処２００の該当時点の状態に関する推定状態ベクトル値２１５と同値のベクトル値ｉ３７とを各々読み込み両者を比較する。

　比較の結果、ポリシ記述部２１９、補償条件２１０に経時変化等による誤差が認められる場合は、補償条件２１０を補正更新する情報ｉ３８及びポリシ記述部２１９を補正更新する情報ｉ３９を生成し、長期補償検出部２１４は、補償条件２１０及びポリシ記述部２１９を補正更新する。

　このように、本実施形態においては、シミュレーション処理機能が未来時刻でｐ回の推定・算出した状態推定ベクトル値とＳＬＡ情報を制御目標とする目標状態ベクトル値とを順次比較、制御偏差を算出し、制御操作の必要有無を判断・検出する方法で制御を行うため、複雑な実行条件も取り扱える。また、制御対象及び評価機能・実行機能の構造が明確である。このため、上記「制御案の補正・検証機能の欠如」、「適正制御案の評価機能の欠如」、「制御指向の評価機能・実行機能の欠如」という各問題を解決できる。

　なお、ここではリポジトリ６を有する構成を例としたが、必ずしもこれを備えている必要はない。

　〔第２の実施形態〕
　本発明を好適に実施した第２の実施形態について説明する。
　図２４に、本実施形態に係るサービス提供品質制御装置の構成を示す。本実施形態においては、合意サービス水準に基づくサービス提供品質制御装置をサービスプロバイダ運営体が保持して、サービスとして定義する場合の例である。

　ワークフローシステム１、ワークフローシステム２、ワークフローシステム３、Proxyシステム４、及びモニタシステム５の構成は、第１の実施形態と同様である。これらは、サービスデリバリプラットフォーム運営体・マッシュアップサービス運営体１１０によって管理される。

　サービス提供品質管理装置は、業務アプリケーションシステム７～１２に接続されている。

　サービス提供品質制御装置の動作は第１の実施形態と同様であり、サービス提供品質制御装置をサービスプロバイダ運営体が保持して、サービスとして定義する場合においても上記「制御案の補正・検証機能の欠如」、「適正制御案の評価機能の欠如」、「制御指向の評価機能・実行機能の欠如」という各問題を解決しつつ、複数の業務アプリケーションシステム群をサービス群として定義し、これらをワークフロー管理システム、ビジネスプロセス管理システムを用いて任意に連携させ、ビジネスプロセスとして実施・運用する際に、当該ビジネスプロセスを起動するサービス利用者と、ビジネスプロセス並びにそこから呼び出されるサービス群を提供するサービス提供者との間で契約として取り決められた合意サービス水準に基づくサービス提供品質を維持できる。

　〔第３の実施形態〕
　本発明を好適に実施した第３の実施形態について説明する。
　図２５に、本実施形態に係るサービス提供品質制御装置の構成を示す。本実施形態においては、合意サービス水準に基づくサービス提供品質制御装置をサービスプロバイダ運営体が保持して、サービスとして定義する場合の例である。

　ワークフローシステム１、ワークフローシステム２、ワークフローシステム３、Proxyシステム４、モニタシステム５、及び業務アプリケーションシステム７～１２の構成は、第１の実施形態と同様である。これらは、アプリケーションサービスプロバイダ・サービスプロバイダ運営体１１１によって管理される。

　なお、上記各実施形態は本発明の好適な実施の一例であり、本発明はこれらに限定されることはない。
　例えば、上記実施形態においては、サンプリング時刻１周期前の計測統計量の履歴状態を用いてシミュレーションを行う場合を例としたが、サンプリング時刻の１周期前に限定されることはなく、規定周期前の計測統計量の履歴状態を用いてシミュレーションを行うことも可能である。
　このように、本発明は様々な変形が可能である。

　この出願は、２００８年１月３１日に出願された日本出願特願２００８－０２１５４４を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明に係る合意サービス水準に基づくサービス提供品質制御装置の構成を示す図である。本発明に係るサービス提供品質制御システムの構成を示すずである。本発明が実施される環境について、一般的に記した図である。本発明の好適な形態である合意サービス水準に基づくサービス提供品質制御装置の構成を記した図である。本発明の好適な形態である合意サービス水準に基づくサービス提供品質制御装置の構成を記した図である。本発明の好適な形態である合意サービス水準に基づくサービス提供品質制御装置の構成を記した図である。本発明の好適な形態である合意サービス水準に基づくサービス提供品質制御装置の構成を記した図である。本発明の好適な形態である合意サービス水準に基づくサービス提供品質制御装置の構成を記した図である。本発明の好適な形態であるサービス提供品質制御装置の内、サービスの品質を計測するため、分散配置された通常のワークフローエンジンからイベント情報を収集する際の手順概要を記した図である。本発明の好適な形態であるサービス提供品質制御装置の内、サービスの品質を計測するため、独自実装の既存ワークフローエンジンからProxyシステムを介してイベント情報を収集する際の手順概要を記した図である。本発明の好適な形態であるサービス提供品質制御装置の内、分散配置されたワークフローエンジンに独自に保持されているワークフロー定義を収集し、統合・合成されたＷｆ定義を生成する際の手順、並びに計測したデータを加工して、制御目的で供するための手順概要を記した図である。本発明の好適な形態であるサービス提供品質制御装置の内、合意サービス水準に基づくサービス提供品質制御を実施する際の手順概要を記した図である。本発明の好適な形態であるサービス提供品質制御装置の内、合意サービス水準に基づくサービス提供品質制御を実施する際の手順概要を記した図である。本発明の好適な形態であるサービス提供品質制御装置で用いる補償機能付きシミュレーション処理部の構成について記した概要図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて、実施される制御手順の概要を記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて、実施される制御手順の概要を記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて実施される、操作候補を選別する際の手順について記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて実施される、制御操作策定を実施する手順について記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて実施される、制御操作策定を実施する手順について記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて実施される、制御操作策定を実施する手順について記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法に基づいて実施される、制御操作策定を実施する手順について記したフローチャート図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法について、時間軸に対する処理の振る舞いを概念的に表した図である。本発明である合意サービス水準に基づくサービス提供品質制御を実施する上での制御方法を定義したブロック線図である。本発明の別形態である合意サービス水準に基づくサービス提供品質制御機能・システムを提供するサービスプロバイダ運営体の内、サービスデリバリプラットフォーム(SDP)を運営する場合の構成概要例を記した図である。本発明の別形態である合意サービス水準に基づくサービス提供品質制御機能・システムを提供するサービスプロバイダ運営体の内、アプリケーションサービスプロバイダ(ASP)を運営する場合の構成概要例を記した図である。

符号の説明

　１、２、３　　ワークフローシステム
　４　　Proxyシステム
　５　　モニタシステム
　６　　リポジト、
　７、８、９、１０、１１、１２　　業務アプリケーションシステム
　１３、１４、１５、１６、１７、１８　　データ通信部
　１９、２０、２１、２２、２３、２４　　アダプタ
　２５、２６、２７、２８Msgイベント抽出部
　２９、２９’、３２、３７　　ワークフローエンジン
　３０、３３、３８　　Engイベント抽出部
　３１、３４、３９、　　ワークフロー定義
　３５　　プロキシ部
　３６　　Prxイベント抽出部
　４０、４２、４５、４７　　イベントデータ保持部
　４１、４３、４４、４６　　共通データ送信部
　４８、４９操作プロキシ
　５０、５３、５６　　強制棄却部
　５１、５４、５７　　投入抑制部
　５２、５５、５８　　キュー管理部
　５９　　ワークフロー定義・サービス定義取得部
　６０　　Wf合成部
　６１　　合成Wf定義
　６２　　イベントデータ受信部
　６３　　イベントデータ関係付け部
　６４　　計測制御量データ管理部
　６５　　イベント・統計格納DB
　６６　　メタデータ管理部
　６７　　計測統計量データ計算部
　６８　　パフォーマンスデータ管理部
　６９　　起動制御部
　７０　　状態観測部
　７１　　補償機能付きシミュレーション処理部
　７２　　目標状態ベクトル値管理部
　７３　　検出部
　７４　　評価条件調整部
　７５　　ポリシ記述管理部
　７６　　調整操作部
　７７　　計測状態ベクトル値処理部
　７８　　長期補償検出部
　７９　　バッファ部
　８０　　実施条件指定部
　８１　　管理コンソール
　１０１、１０２、１０３、１０４、１０５　　サブネットワーク
　１０６、１０７、１０８　　ルータ
　１１０　　サービスデリバリプラットフォーム運営体・マッシュアップサービス運営体
　１１１　　アプリケーションサービスプロバイダ・サービスプロバイダ運営体
　１２０　　挙動関数
　１２１、１２１’　　順序機械シミュレーション部
　１２２　　要素ワークフローモデル群
　１２３　　要素ワークフローモデル群
　１２４　　サービス特性関数計算部
　１２５、１２６、１２７、１２８　　業務アプリケーションシステム挙動特性定数
　１３０　　処理系
　２００　　制御対象
　２０１　　メタデータ管理部
　２０２　　パフォーマンスデータ管理部
　２０３　　計測統計量データ計算部
　２０４　　計測制御量データ管理部
　２０５　　起動制御部
　２０６　　状態観測部
　２０７　　現状態ベクトル値
　２０８　　履歴状態ベクトル値
　２０９　　計測状態ベクトル値処理部
　２１０　　補償条件
　２１１　　補償機能付きシミュレーション処理部
　２１２　　変更条件ベクトル値
　２１３　　計測状態ベクトル値
　２１４　　長期補償検出部
　２１５　　推定状態ベクトル値
　２１６　　目標状態ベクトル値
　２１７　　検出部
　２１８　　評価条件調整部
　２１９　　ポリシ記述部
　２２０　　調整操作部
　２２１　　候補操作ベクトル量
　２２２　　確定操作ベクトル量
　２２３　　制御装置部
　２２４　　計測器
　２２５　　状態推定器
　２２６　　調整器
　２２７　　制御器
　２２８　　長期補償器
　２５０　　横軸
　２５１　　曲線
　２５２、２５４、２５５、２５６、２５７、２５９、２６０、２６１　　時刻
　２５３　　期間
　２５８　　１回目の単位時刻
　ｃ１　　起動要求
　ｃ２、ｃ２４　　統合・合成されたワークフロー定義の一覧
　ｃ３、ｃ２５　　全てのワークフロー定義・サービス定義の定義情報一式
　ｃ４　　現時点のパラメータ１の算出結果
　ｃ５　　現時点迄のパラメータ1の累積値、平均値
　ｃ６　　現時点のパラメータ2の算出結果
　ｃ７　　現時点迄のパラメータ2の累積値、平均値
　ｃ８　　サンプリング時刻状態行列
　ｃ９　　サンプリング時刻１周期前の状態行列
　ｃ１０　　定義情報一式
　ｃ１１　　統合・合成されたワークフロー定義の一式
　ｃ１２、ｃ１７、ｃ１８、ｃ２３、ｃ２８、ｃ６０、ｃ６４、ｃ６５、ｃ８９　　起動(Invoke)コマンド
　ｃ１３、ｃ１９　　制御操作に対するポリシ定義情報
　ｃ１４、ｃ１４’、ｃ３０　　合意サービス水準に関するパラメータ群を意味するベクトル値群
　ｃ１５、ｃ２０　　再起動(Invoke)コマンド
　ｃ１６、ｃ６３　　合意サービス水準に関する目標値群のベクトル値群
　ｃ２１、ｃ２２　　仮制御操作一覧指定情報
　ｃ２６　　現時点のパラメータ１算出結果、現時点迄のパラメータ1累積値、平均値
　ｃ２７　　現時点のパラメータ2算出結果、現時点迄のパラメータ2累積値、平均値
　ｃ２９　　実測ベクトル値群
　ｃ３１　　ポリシ記述更新コマンド
　ｃ３２　　補償条件式更新コマンド
　ｃ５０、ｃ５１、ｃ５２、ｃ５５、ｃ５６　　制御メッセージ
　ｃ５３、ｃ５４　　制御コマンド
　ｃ６１　　指定パラメータ値群
　ｃ６２　　相対優先度に関する情報
　ｃ６６　　更新するべきパラメータ名群とパラメータ値群
　ｃ６７　　応答形式を指定した情報
　ｃ８０　　パラメータ群
　ｃ８１　　算パラメータ群
　ｃ８２　　サービス定義に関する呼出度数について計算した行列値に関するデータ
　ｃ８３　　計測統計量データ
　ｃ８４、ｃ９１　　アラーム
　ｃ８５　　全てのイベントデータ
　ｃ８６　　合意サービス水準に関する状態に関する実測ベクトル値群
　ｃ８７　　特定情報
　ｃ８８　　パラメータ値群間の相対情報
　ｃ９０　　応答形式を指定した情報
　ｉ１　　イベントに関するデータ
　ｉ２　　パラメータ群
　ｉ３　　形式的な意味等の情報
　ｉ４、ｉ１０　　情報
　ｉ５　　形式的な意味等の情報
　ｉ６　　パラメータ群に関する現在の値、並びに累積値、平均値等
　ｉ７、ｉ１１　　現状状態ベクトル値
　ｉ８、ｉ１２　　履歴状態ベクトル値
　ｉ９　　起動要求
　ｉ１３　　設定定常値
　ｉ１４　　推定値
　ｉ１６、ｉ３７　　推定状態ベクトル値と同値なベクトル値
　ｉ１７　　目標値群のベクトル値と同値なベクトル値
　ｉ１８、ｉ１９、ｉ２４、ｉ２７、ｉ３３、ｉ３６　　引数
　ｉ２１　　仮決めされた制御操作量
　ｉ２３　　更新情報
　ｉ２５　　該当ベクトル値
　ｉ２６　　ベクトル値
　ｉ２８　　必要なスカラ値、もしくはベクトル値
　ｉ２９　　制御操作量
　ｉ３０　　イベント情報
　ｉ３１　　現在の値、並びに累積値、平均値等
　ｉ３２　　管理単位に関する形式的な意味等の情報
　ｉ３４　　計測状態ベクトル値と同値のベクトル値
　ｉ３８、ｉ３９　　補正更新する情報
　ｍ１、ｍ２、ｍ３、ｍ７、ｍ８、ｍ９、ｍ２５、ｍ３０、ｍ３１、ｍ３２、ｍ３６、ｍ３７、ｍ３８、ｍ４８、ｍ８６、ｍ８８　　処理要求メッセージ
　ｍ４、ｍ５、ｍ６、ｍ１０、ｍ１１、ｍ１２、ｍ２６、ｍ３３、ｍ３４、ｍ３５、ｍ４９、ｍ８７、ｍ８９　　処理応答メッセージ
　ｍ１３、ｍ１４、ｍ１５、ｍ１６、ｍ１７、ｍ１８、ｍ１９、ｍ２０、ｍ２１、ｍ２２、ｍ２３、ｍ２４、ｍ２７、ｍ２８、ｍ３９、ｍ４０、ｍ４１、ｍ４７　　イベント
　ｍ２９、ｍ５４、ｍ５５、ｍ６３　　イベントデータ転送メッセージ
　ｍ４２、ｍ４３、ｍ４４、ｍ４５、ｍ４６、ｍ５０、ｍ５１、ｍ５２、ｍ５３　　メッセージに関するイベント
　ｍ６０、ｍ６１、ｍ６２　　定義転送メッセージ
　ｍ６４　　ワークフロー定義・サービス定義情報
　ｍ６５　　ワークフロー定義情報・サービス定義
　ｍ６６　　統合・合成されたワークフロー定義の一式
　ｍ６７　　イベントに関する全てのデータ
　ｍ６８　　サービス定義・プロセス定義情報
　ｍ６９　　メッセージインスタンス群
　ｍ７０　　メッセージインスタンス
　ｍ７１、ｍ７１’　　検索要求
　ｍ７２、ｍ７２’　　イベントデータの一覧
　ｍ７３　　統合・合成されたワークフロー定義
　ｍ７４　　定義情報一式
　ｍ７５　　統合・合成されたワークフロー定義の一覧
　ｍ７６　　全てのワークフロー定義・サービス定義
　ｍ７７、ｍ７８、ｍ７９、ｍ８０　　更新要求
　ｍ８１、ｍ８２、ｍ８３、ｍ８４　　管理要求
　ｍ８５　　問い合わせ

Claims

　複数の業務アプリケーションシステム群の起動状態及び操作順序の定義を維持管理し、制御するワークフローのそれぞれの要素ワークフロー部分を、ワークフローエンジンを実装した複数のワークフロー管理システムが独立・分散して管理及び実行している環境下で、分散された前記要素ワークフロー部分の実行を統合監視する機能に伴い、全体ワークフローの記述に関するサービス提供品質、又は複数利用者ごとに取り決めた合意サービス水準を維持することを目的とする合意サービス水準制御装置であって、
　前記全体ワークフローの記述ごとに制御目標の目標状態ベクトル値として定義された、前記全体ワークフローのサービス提供条件を示す合意サービス水準情報を格納する手段と、
　可計測かつ統計処理のみで計算可能な要素ワークフロー部分又は当該要素ワークフロー部分から呼び出されるサービスに関する計測統計量を算出する計測統計量データ計算手段と、
　前記計測統計量から所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する状態観測手段と、
　前記計測統計量の現状態ベクトル値及び前記履歴状態ベクトル値を基に、前記目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上で推定するシミュレーション処理手段と、
　制御操作に関するポリシ記述を管理するポリシ記述管理手段と、
　前記シミュレーション処理手段が推定した状態推定ベクトル値と前記合意サービス水準情報を制御目標とする目標状態ベクトル値とを順次比較した上で制御偏差を算出し、制御操作が必要か否かを判断する判断手段と、
　前記制御操作が必要と判断される場合には、前記ポリシ記述管理手段が管理する前記ポリシ記述に基づいて前記全体ワークフローの記述の実行環境を自装置内で仮想的に変化させた上で、前記シミュレーション処理手段及び前記判断手段を再実行し、所定回数を上限として前記制御偏差が所定値以下となるまで前記実行環境の評価条件を調整する調整手段と、
　前記調整手段による評価条件の調整の結果、もはや前記制御操作が必要と判断されない場合に、実行環境の変化を確定させる手段とを有することを特徴とする合意サービス水準に基づくサービス提供品質制御装置。
　前記分散された要素ワークフロー部分の記述を収集・管理する手段と、
　収集した前記分散された要素ワークフロー部分の記述を合成し、前記全体ワークフローの記述を再生するワークフロー合成手段を含むことを特徴とする、請求項１記載のサービス提供品質制御装置。
　前記シミュレーション処理手段は、前記サンプリング周期のうち、計測に許容される平均計測評価期間を2p（pは１以上の整数）に等期間で時分割して、p回未来時刻で補償した上で前記状態推定ベクトル値群を推定し、
　前記調整手段は、前記p回を上限として実行環境の評価条件を調整することを特徴と請求項１又は２記載のサービス提供品質制御装置。
　前記要素ワークフロー部分のうち、前記標準形式で記述されていないものを前記標準形式に変換する手段と、
　前記要素ワークフロー部分の記述を所定の標準形式で管理する手段とを有することを特徴とする請求項１から３のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御装置。
　前記シミュレーション処理手段とは別の手順にて、該シミュレーション処理手段の推定結果と等価な等価データを算出する手段と、
　前記シミュレーション処理手段の推定結果と前記等価データとを比較し、前記ポリシ記述及び前記シミュレーション処理手段が参照する補償条件の少なくとも一方を補償する必要があるか否かを判断する手段と、
　前記ポリシ記述及び前記シミュレーション処理手段が参照する補償条件の少なくとも一方を定期的に捕正する長期補償手段とを有することを特徴とする請求項１から４のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御装置。
　前記目標状態ベクトル値と前記状態推定ベクトル値とを順次比較して制御偏差を算出する場合に、前記合意サービス水準情報に関する優先度、並びに、全体ワークフローの記述を構成する複数の要素ワークフロー部分の記述及びそこから呼び出されるサービス群の構成上の複雑さを評価した値、並びに、可計測かつ統計処理のみで計算可能な要素ワークフロー部分や該要素ワークフロー部分から呼び出されるサービスに関する計測統計量データの値を考慮して、ボトルネック箇所を特定する手段を有することを特徴とする請求項１から５のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御装置。
　前記ポリシ記述として、ワークフローエンジン数を仮決めで増減すること、当該ワークフローエンジンのサービス実行処理系に対するメッセージの投入を一時的に抑制し、ボトルネックとなっている処理を整流化すること、及び前記メッセージを棄却することの少なくともいずれかを含み、
　当該ワークフローエンジンが実装された複数のワークフロー管理システム内、もしくは隣接する形で、前記メッセージの投入を一時的に抑制する手段、及び前記メッセージを棄却する手段を有することを特徴とする請求項１から６のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御装置。
　前記ポリシ記述において、前記全体ワークフローの記述ごとに、前記合意サービス水準情報を制御目標として満足できるように、前記要素ワークフロー部分の呼び出し部分、及びそこから呼び出されるサービス呼出定義部分を動的に並行可能化することを含むとともに、
　末端のサービス呼出定義を並行可能化する手段を有することを特徴とする請求項７に記載の合意サービス水準に基づくサービス提供品質制御装置。
　前記要素ワークフロー部分の記述を格納する手段及び該要素ワークフロー部分を実行するワークフローエンジンを備えた複数のワークフロー処理装置と、請求項１から８のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御装置とを有することを特徴とするサービス提供品質制御システム。
　明確に定義された制御対象及びそれに関係する物理事象のうち、可計測かつ統計処理のみで計算可能な計測統計量データ及び前記制御対象の制御目標で直接計測不可能な目標状態ベクトル値を定義する手順と、
　前記計測制御量データから所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する手順と、
　前記計測統計量の前記現状態ベクトル値及び前記履歴状態ベクトル値を基に、前記目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上でシミュレーションして推定する手順と、
　前記シミュレーションによって推定された前記状態推定ベクトル値と前記目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作が必要であるか否かを判断する手順と、
　前記制御操作が必要な場合に、前記制御偏差を満たすための制御操作量を仮決めする手順と、
　仮決めした前記制御操作量を追加して、前記シミュレーションと同義の新たなシミュレーションを実施し、前記目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値を算出した後、該状態推定ベクトル値を前記目標状態ベクトル値と比較して新たな制御偏差を算出し、更に制御操作量が必要な場合は、所定回数を上限として前記制御操作量が確定するまで、仮決めする制御操作量を追加・条件を厳しくする手順と、
　前記制御操作量を追加する必要のない場合に、制御操作を実施する手順を含むことを特徴とするフィードフォワード制御方法。
　サービス提供条件を示す合意サービス水準情報を制御目標の目標状態ベクトル値として定義し、
　前記制御偏差を満たすための制御操作として、サービス実行処理系の処理系の数、ハードウェア資源の割付け量増減、メッセージ投入抑制量の増減のいずれか一つ以上を含むことを特徴とする請求項１０記載のフィードフォワード制御方法。
　可計測かつ統計処理のみで計算可能なサービスに関する計測統計量データを持ち、サービス提供条件を示す合意サービス水準情報を制御目標の目標状態ベクトル値として定義する手順と、
　前記サービスに関する計測制御量データを基に直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する手順と、
　前記計測統計量の前記現状態ベクトル値及び前記履歴状態ベクトル値を基に、前記目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって未来時刻で補償した上でシミュレーションして推定する手順と、
　推定された状態推定ベクトル値と前記目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作の必要有無を判断する手順と、
　前記制御操作が必要な場合に、前記制御偏差を満たすための制御操作として、サービス実行処理系の処理系の数、ハードウェア資源の割付け量増減、メッセージ投入抑制量の増減を仮決めする手順と、
　仮決めされた当該処理系の数、ハードウェア資源の割付け量増減や、メッセージ投入抑制量増減の操作を仮想的に追加して、前記シミュレーションと同等の新たなシミュレーションによる推定を改めて実施し、前記サービス提供条件を示す合意サービス水準情報と比較し、これを満足するか否かを判断し、更に新たな処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減の操作が必要と判断される場合は、所定回数を上限として前記合意サービス水準情報を満足するまで、当該新たな処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減を仮想的に実施する手順と、
　前記合意サービス水準情報を満足する場合に、実際に処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減を実施する制御操作を実施する手順とを実行することを特徴とする合意サービス水準に基づくサービス提供品質制御方法。
　コンピュータを、
　複数業務アプリケーションシステム群の起動状態、操作順序の定義を維持管理し、制御するワークフローのそれぞれの要素ワークフロー部分を、ワークフローエンジンを実装した複数のワークフロー管理システムが独立・分散して管理、実行している環境下で、要素ワークフロー部分を実施する際に発生するイベント群を当該全体のワークフローの記述に明確に位置付け、当該イベント群以外のイベント群と関連付けてイベント格納手段に記録する手段と、
　分散された要素ワークフロー部分の実行を統合監視する機能に伴い、前記全体のワークフローの記述ごとに、そのサービス提供条件を示す合意サービス水準情報を制御目標の目標状態ベクトル値として定義する手段と、
　可計測かつ統計処理のみで計算可能な要素ワークフロー部分や当該要素ワークフロー部分から呼び出されるサービスに関する計測統計量データの計算手段と、
　前記計測統計量データの計算手段が算出するデータから、所定のサンプリング周期でサンプリングを実施し、直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する状態観測に関する手段と、
　前記計測統計量の前記現状態ベクトル値、及び前記履歴状態ベクトル値を基に、前記目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって所定回数未来時刻で補償した上で推定するシミュレーション処理手段と、
　制御操作に関するポリシ記述を管理する手段と、
　前記シミュレーション処理によって推定した当該状態推定ベクトル値と前記合意サービス水準情報を制御目標とする目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作が必要であるか否かを判断する手段と、
　前記制御操作が必要と判断される場合、前記ポリシ記述から、複数ワークフロー管理システムの内の特定要素ワークフロー部分を実行するワークフローエンジン数を仮決めで増減し、仮決めされた当該ワークフローエンジン数を仮想的に増減した上で前記シミュレーションと前記制御操作が必要であるか否かの判断とを再実行し、更に新たなワークフローエンジン数の増減が必要と判断される場合には、所定回数を上限として、前記制御偏差が満足できるまで、当該新たなワークフローエンジン数を増減する評価条件を調整する手段と、
　前記調整手段による評価条件の調整の結果、もはや前記制御操作が必要でないと判断する場合、実際に当該ワークフローエンジン数を増減するための手続きに変換する調整操作に関する手段と、として機能させることを特徴とする合意サービス水準に基づくサービス提供品質制御プログラム。
　前記コンピュータを、
　分散する要素ワークフロー部分の記述を収集・管理する手段と、
　複数の当該分散する要素ワークフロー部分の記述を合成し、全体のワークフローの記述を再生するワークフロー合成手段と、として機能させることを特徴とする請求項１３記載の合意サービス水準に基づくサービス提供品質制御プログラム。
　前記コンピュータを、
　前記要素ワークフロー部分の記述を収集する手段と、
　前記要素ワークフロー部分の記述を所定の標準形式で管理する手段と、
　前記要素ワークフロー部分のうち、前記標準形式で記述されていないものを前記標準形式に変換する手段と、として機能させることを特徴とする請求項１３又は１４記載の合意サービス水準に基づくサービス提供品質制御プログラム。
　前記コンピュータを、
　前記シミュレーション処理手段とは別の手順にて、該シミュレーション処理手段の推定結果と等価な等価データを算出する手段と、
　前記推定結果と前記等価データとを比較して、前記ポリシ記述及び前記シミュレーション処理手段が参照する補償条件の少なくとも一方を補償する必要があるか否かを判断する手段と、
　前記ポリシ記述及び前記シミュレーション処理手段が参照する補償条件の少なくとも一方を定期的に捕正する長期補償手段と、として機能させることを特徴とする請求項１３から１５のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御プログラム。
　前記コンピュータを、
　前記目標状態ベクトル値と前記状態推定ベクトル値とを順次比較して制御偏差を算出する場合に、前記合意サービス水準情報に関する優先度、並びに、全体ワークフローの記述を構成する複数の要素ワークフロー部分の記述及びそこから呼び出されるサービス群の構成上の複雑さを評価した値、並びに、可計測で統計処理のみで計算できる要素ワークフロー部分や該要素ワークフロー部分から呼び出されるサービスに関する計測統計量データの値を考慮して、ボトルネック箇所を特定する手段として機能させることを特徴とする請求項１３から１６のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御プログラム。
　前記ポリシ記述において、ワークフローエンジン数を仮決めで増減すること、当該ワークフローエンジンのサービス実行処理系に対するメッセージの投入を一時的に抑制し、ボトルネックとなっている処理を整流化すること、前記メッセージを棄却することを含み、
　前記コンピュータを、
　当該ワークフローエンジンが実装された複数のワークフロー管理システム内、もしくは隣接する形で、前記メッセージの投入を一時的に抑制する手段、及び前記メッセージを棄却する手段として機能させることを特徴とする請求項１３から１７のいずれか１項記載の合意サービス水準に基づくサービス提供品質制御プログラム。
　前記ポリシ記述において、前記全体ワークフローの記述ごとに、前記合意サービス水準情報を制御目標として満足できるように、前記要素ワークフロー部分の呼び出し部分、及びそこから呼び出されるサービス呼出定義部分を動的に並行可能化することを含むとともに、
　前記ワークフロー合成手段は、末端のサービス呼出定義を並行可能化する機能を有することを特徴とする請求項１８に記載の合意サービス水準に基づくサービス提供品質制御プログラム。
　コンピュータに、
　サービス提供品質、もしくは複数サービス利用者ごとに取り決めた合意サービス水準等を制御対象とし、可計測かつ統計処理のみで計算できるサービスに関する計測統計量データを持ち、サービス提供条件を示す合意サービス水準情報を制御目標の目標状態ベクトル値として定義する手順と、
　前記サービスに関する計測制御量データを基に直前のサンプリング時刻における計測統計量の現状態ベクトル値及び規定周期前のサンプリング時刻における計測統計量の履歴状態ベクトル値を算出する手順と、
　前記計測統計量の前記現状態ベクトル値及び前記履歴状態ベクトル値を基に、前記目標状態ベクトル値と同義の状態ベクトル成分からなる状態推定ベクトル値群を、外挿によって所定回数未来時刻で補償した上で推定する推定手順と、
　推定された前記状態推定ベクトル値と前記目標状態ベクトル値とを順次比較して制御偏差を算出し、制御操作が必要か否かを判断する手順と、
　前記制御操作が必要な場合に、制御操作として、サービス実行処理系の数、ハードウェア資源の割付け量増減、メッセージ投入抑制量の増減を仮決めする手順と、
　仮決めされた前記処理系の数、ハードウェア資源の割付け量増減、メッセージ投入抑制量増減の操作を仮想的に追加して、前記推定手順と同義の新たな推定を改めて実施する手順と、
　前記新たな推定結果が、前記合意サービス水準情報を満足するか否かを判断する手順と、
　更に新たな処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減等の操作が必要と判断した場合に、所定回数を上限として前記合意サービス水準情報を満足するまで、当該新たな処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減を仮想的に実施する手順と、
　前記合意サービス水準情報を満足する場合は、実際に処理系の数、ハードウェア資源の割付け量増減や、新たなメッセージ投入抑制量増減を実施する制御操作を実施する手順と、を実行させることを特徴とする合意サービス水準に基づくサービス提供品質制御プログラム。
　請求項１３から２０のいずれか１項記載のサービス提供品質制御プログラムを記録した記録媒体。