通信サービス及びネットワーク管理のうちの一方または双方のプラットフォームにおけるリソース管理ための方法、対応するプラットフォーム及びコンピュータ・プログラム製品
【課題】本発明は、通信サービスおよびネットワークのリソースを管理する方法およびシステムに関する。
【解決手段】本方法およびシステムは、ネットワーク上で所定のタスクを実行すべくプロセス機械（Ｈ）上の分散エージェント（Ａ１、Ａ２、Ａ３）によるプロセス（ＷＦ１、．．．、ＷＦｎ）の実行に関するものであり、プロセス（ＷＦ１、．．．、ＷＦｎ）におけるシステムが達成すべき目標およびリソース使用に対する制約を含む目標データを設定するステップと、エージェントによる計算リソースの使用状況およびプロセスの実行を監視するステップと、リソース使用状況およびプロセスの実行を表す性能データを収集するステップと、収集された性能データを設定データと比較して、性能データが目標データを達成していない場合に違約を規定するステップと、前記比較に基づいて決定された違約を最小化すべくエージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを再割り当てするステップとにより特徴付けられる。
【解決手段】本方法およびシステムは、ネットワーク上で所定のタスクを実行すべくプロセス機械（Ｈ）上の分散エージェント（Ａ１、Ａ２、Ａ３）によるプロセス（ＷＦ１、．．．、ＷＦｎ）の実行に関するものであり、プロセス（ＷＦ１、．．．、ＷＦｎ）におけるシステムが達成すべき目標およびリソース使用に対する制約を含む目標データを設定するステップと、エージェントによる計算リソースの使用状況およびプロセスの実行を監視するステップと、リソース使用状況およびプロセスの実行を表す性能データを収集するステップと、収集された性能データを設定データと比較して、性能データが目標データを達成していない場合に違約を規定するステップと、前記比較に基づいて決定された違約を最小化すべくエージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを再割り当てするステップとにより特徴付けられる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークおよびサービスのうちの一方または双方の管理を目的とするプラットフォームにおけるリソース管理方法に関する。特に、本発明は、通信ネットワークおよびサービスのうちの一方または双方の管理用プラットフォームにおけるリソース割り当て方法および対応する管理プラットフォームに関する。
【背景技術】
【０００２】
通信ネットワーク／サービス分野において、階層的アーキテクチャで構成され、時としてエージェントを利用する動作支援システム（ＯＳＳ）等、複数の構成要素を含む管理用プラットフォームが提供されている。
【０００３】
例えば米国特許第６，２４３，３９６号明細書に、通信ネットワーク・リソースを制御する相互接続された管理局の多層階層アーキテクチャを有する通信ネットワーク管理システムまたはプラットフォームが開示されている。各々の局は、プロセスの実行に責任を負う多数のエージェントを有しており、これらは知的または単なる応答的エージェントであってよい。
【０００４】
公知のアーキテクチャにおいて、応答的エージェントは局のプラットフォーム部分に置かれ、知的エージェントは局の制御部分に置かれる。知的および応答的エージェントは、当該プラットフォームにＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）に機能を提供すべく機能構成要素に分類される。
【０００５】
国際公開第０１／０２９７３号パンフレットは、分散エージェントを調整するための集中型プロセス・コーディネータを含むプラットフォームの利用を教示しており、これは典型的には構成要素（エージェント）へのジョブの委譲、エージェントからの応答の収集等を含むワークフロー記述（フロー図と同様）を実行するワークフロー・エンジンにより実現される。
【特許文献１】米国特許第６，２４３，３９６号明細書
【特許文献２】国際公開第０１／０２９７３号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００６】
出願人は、上記のアーキテクチャでは、エージェントがワークフロー・エンジンにより委譲されたジョブを実行することが保障されないと考える。実際に、計算能力等、エージェントが利用できるＩＴリソースには限界があり、プラットフォームに求められる業務目標や作業負荷に合致するにはＩＴリソースが十分であるとは限らない。
【０００７】
換言すれば、エージェントが利用できるＩＴリソース如何により、例えば顧客へのサービス提供等、エージェントにより実行されるタスクを必要とする所定の業務目標の達成が妨げられる場合がある。
【０００８】
例えば、タスクとして、規定されたプロセスを所定の持続期間より短い平均時間で完了すること、または一定の期限内に所定数のプロセスを完了することが挙げられる。
【０００９】
エージェントにかかる膨大な作業負荷により、エージェントが所定の平均時間または定められた期限内にタスクを完了することができなくなり、従って業務目標が達成されない恐れがある。
【００１０】
集中型プロセス・コーディネータを用いるエージェントに基づくアーキテクチャの別の問題は、国際公開第０１／０２９７３号パンフレットに開示されているように、コーディネータ自体がプラットフォームの動作のボトルネックになる点であり、柔軟性を向上させるべくコーディネータにワークフローを加えるエージェントから外出しされたプロセスロジックが増えるほど、コーディネータが遅くなる。これにより、実行に期限を有するプロセス等、業務性能目標を達成するためのアーキテクチャの能力が低下する恐れがある。
【００１１】
ＩＴリソース管理分野において、米国特許出願公開第２００３／０１６７２７０号明細書に、スケーラブルなアプリケーションのコピーのインスタンス生成を行なうホスト機を含む分散環境におけるリソース管理システムが開示されている。当該リソース管理システムは、アプリケーションのコピーに関する情報およびホストの性能に基づいて、ホスト群をまたがってスケーラブルなアプリケーションの選択されたコピーを起動、停止、または移動させる信号を生成する。
【００１２】
この種のソリューションは、少なくとも以下の理由により、プロセス・コーディネータまたはワークフロー・エンジンにより調整される分散型エージェント・アーキテクチャを含むプラットフォームには適していない。
− 全てのエージェントが既にいくつかのタスクを実行している場合、緊急のタスクまたはアプリケーションを新たに実行するための空きエージェントが存在する余地がない。
− 新規ワークフロー（すなわち新たな機能）が規定される都度、業務目標（例：業務プロセスの期限）を実現すべく、既知のシステムはアプリケーションのパラメータを測定して、全てのエージェントの挙動を調整すべく新たなモデルを構築する必要がある。
− 既知のリソース管理システムは、複数のコピーにインスタンスが生成され得るアプリケーションまたは機能に対してのみ作用する。
【００１３】
本発明の目的は従って、通信サービスおよびネットワークのうちの一方または双方を管理するエージェント利用プラットフォームにおけるリソースを管理する方法を提供することであり、これにより所定の業務目標を達成すべくリソース使用状況における最適な性能を実現してプラットフォームの効率を向上させる。
【００１４】
本発明の他の目的は、プラットフォームの柔軟性を向上させながら性能向上を実現するために分散型プロセスロジックを有する管理プラットフォームである。
【００１５】
本発明によれば、これらの目的は、通信サービスおよびネットワークのうちの一方または双方を管理するプラットフォームにおけるリソース管理の方法により、かつ独立請求項に記述された特徴を有する管理プラットフォームにより実現される。
【００１６】
本発明のさらなる目的は、特許請求の範囲に記述されるように、通信管理プラットフォームの設定および運転を行なうコンピュータ・プログラム製品またはコンピュータ・プログラムの組、通信ネットワークおよび方法である。
【課題を解決するための手段】
【００１７】
要約すれば、従来技術の短所を克服すべく、本発明は、所定の指標（例：主要業務指標）および目標により駆動される、予測および適応型の機構に基づく方法および対応プラットフォームを開示するものであり、管理プラットフォームにおけるＩＴリソースの使用状況の測定および自動制御を行なう。
【００１８】
好適には、本発明によるプラットフォームのアーキテクチャの特徴は以下の通りである。
− エージェントが提供する全ての機能を実装するエージェント内部のプロセス（ワークフローおよびルール）エンジンを提供することにより、エージェントが実行しなければならないジョブがワークフローの実行となる。ルールエンジンは、特定種類のジョブを実行すべくワークフロー・エンジンに結合することができる。
− プロセス記述を定義および保存してこれらの記述をエージェントに分散するための集中型プロセス記述データベースの提供、
− 業務目標（例：ＳＬＡ、サービスレベル合意）および機能およびその集計（例：履行、保証、支払い請求等の業務プロセス領域への）の定義に基づく処理優先順位を含む目標データの指定を可能にする目標および制約コンソールの提供、
− プラットフォームの各エージェントにおける各々のプロセスの実行並びに業務プロセスによるワークフローの実行によるＩＴリソースの使用を監視、すなわち、例えば経過時間、実行頻度等を監視すべく構成された制御エージェントの提供、および、
− 業務目標を最大限に達成すべく、指定された目標データ（業務目標）およびリソースの使用状況を示す監視された性能データに基づいて、適応型の方法でプラットフォームの各エージェントにＩＴリソースを再割り当てすべく構成されたリソース割り当てモジュールの提供。
【００１９】
本発明の好適な実施形態によれば、リソースの再割り当てルールを規定すべくグラフィカル・ユーザー・インターフェースとしてリ−アロケータ・コンソールが提供されていると共に、監視コンソールが提供されていることにより、ＳＬＡの達成状況および対応ＩＴリソースの使用状況および関連コストの制御が可能になる点が好都合である。
【００２０】
エージェント内部にプロセス・エンジンを提供することが、全てのエンジンが集中型プロセス・コーディネータに置かれている場合にボトルネックを生じることなく柔軟性を向上させ、エージェント間でＩＴリソースを動的に割り当てる際に有利な特徴であることがわかる。エージェント内のプロセス・エンジンにより、各々の機能実行（すなわちプロセスの実行）に際してエージェント内でのリソース使用状況（例：使用されたＣＰＵ時間またはＲＡＭ）を分析的に測定することが可能になる。
【００２１】
集中型データベースにおけるプロセス記述は、プラットフォーム横断的に各エージェントへそれらのプロセス・エンジン内で利用すべく分散され、プラットフォームの全ての動作機能と自動的に同期化が行なわれるため、ジョブのセマンティクスと協働するリソースの管理プロシージャを調整することが可能である。
【００２２】
実際には、通信サービスおよびネットワークを管理するプラットフォームの管理者は、プロセス・データベース内で１個以上のワークフローおよびルールのうちの一方または双方を規定するかまたは既存のものの組み合わせる任意のＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）機能を構築することができ、次いで必要なときにエージェントが新規プロセス（ワークフローおよびルール）の定義を自動的に取得して実行することができる。自動的に、目標コンソールが新規プロセスに対するＳＬＡおよび優先順位の規定を可能にする。実行時に、制御エージェントは、新規プロセスのＳＬＡ傾向および対応ＩＴリソースの使用状況の制御を可能にして、リ−アロケータ・モジュールが全体構成を最適化できるように、すなわちエージェントにおけるワークフロー優先順位を変更するか、またはより多くの計算リソース（ＣＰＵ、メモリ等）を与える。
【００２３】
本発明によるリソース管理は好適には、分散されたモジュール（制御エージェント）と共に、集中型モジュール（マネージャ・モジュール）によりプラットフォーム内で実装される。集中および分散機能の組合せは、ソリューションの適応型機構の基礎となる。
【００２４】
本発明のさらなる特徴および利点を、添付図面に関して非限定的な例を用いて以下の記述においてさらに詳しく説明する。
【図面の簡単な説明】
【００２５】
【図１】本発明による通信ネットワークおよびサービスの管理システムまたはプラットフォームのアーキテクチャを示すブロック図である。
【図２】図１のマネージャ・モジュールの内部アーキテクチャを示すブロック図である。
【図３】エージェント・モジュールおよび制御エージェントと共に、図１のホスト機の内部アーキテクチャを示すブロック図である。
【図４】別の実施形態によるエージェント・モジュールの内部アーキテクチャを示すブロック図である。
【図５】本発明によるリソース管理方法のフロー図である。
【図６】本発明によるシステムを含む３層サービスプロビジョニングシナリオの模式図である。
【図７】図６のサービスプロビジョニングシナリオにおける多レベル・ワークフローを示す図である。
【発明を実施するための形態】
【００２６】
図１に、本発明による通信サービスおよびネットワーク管理システムの例証的なアーキテクチャを示す。本システムは好適には、各々が１個以上のソフトウェア・エージェント（Ａ１、Ａ２、Ａ３）を含み得る複数のプロセスホスト機Ｈを含む分散プロセスアーキテクチャに実装されている。
【００２７】
本システム（またはプラットフォーム）は、ホスト機上で動作してプロセス記述の分散、動作の起動、管理統制等、各種の協調動作のために分散エージェントと対話するプログラムまたはプログラムの組を含む集中型制御モジュールまたはマネージャ・モジュールＭＭを含んでいる。マネージャ・モジュールＭＭはまた、好適にはシステム管理者等のユーザーと対話するためのグラフィカル・ユーザー・インタフェースを含んでいてよい。
【００２８】
本明細書において、プロセスという用語は、１個以上のワークフロー、１個以上のルールまたは、好適には１個以上のワークフローと１個以上のルールの組合せを表すために用いられる。
【００２９】
ワークフローは、手続きのルールの組に従い、実行中にあるエージェントから別のエージェントへ情報またはタスクが渡される業務プロシージャの自動化されたものとして規定することができる。
【００３０】
ワークフローは、一連のタスク並びに代替的なまたは並列分枝を含むタスク間の時間的かつ論理的依存関係を有するフロー図を介して表すことができる。ワークフロー記述を定式化するＸＰＤＬ（ＸＭＬプロセス記述言語）等の特殊言語が存在する。これらのルールは特定の組の条件／イベントが発生した際に実行すべきアクションの宣言である。
【００３１】
マネージャ・モジュールＭＭは、全てのプロセス、すなわちプラットフォームの挙動および機能的態様を表すワークフローおよびルールを保存すべく構成されたプロセス記述データベースＰＤＢを含んでいる。
【００３２】
データベースＰＤＢはさらに、例えば、ワークフローおよびルールにより扱われるデータ・モデルを含んでいる。
【００３３】
当業者には知られているように、プロセス記述データベースＰＤＢは例えば、任意の従来型ネットワーク在庫管理システムのカタログ部分に関連付けられてよい。
【００３４】
図１のアーキテクチャは、多層エージェント・モジュール、例えば各々がいくつかのエージェントＡ１、Ａ２、Ａ３を含む３層を含んでいる。同一レベルに属しているエージェントは相互に接続していても、または互いに独立していてもよい。これらは、より高いレベルのエージェントがあれば、これに結合されている。より低いレベルにおいて、エージェントは、制御下にあるネットワーク要素（一般に通信ネットワークＮとして示す）、例えばＡＴＭスイッチ、あるいはメールサーバー・アプリケーションまたはＶＡＳサーバー・アプリケーション等の他のサービス・アプリケーションＡＰＰ、すなわち携帯電話の留守番電話サービス等の付加価値サービス・アプリケーションに結合されている。
【００３５】
マネージャ・モジュールＭＭは、例えば、通信バスＢを介してプラットフォームの他の動作支持システムＯＳＳに接続されている。
【００３６】
コーディネータとして機能しているマスター・エージェントＭＡ、あるいは実装方式の種類に応じて複数のマスター・エージェント群ＭＡ（図１に開示せず）が、マネージャ・モジュールＭＭに関連付けられた多層エージェント・アーキテクチャのルートに提供されている。
【００３７】
各エージェントＡ１、Ａ２、Ａ３は、プロセス・エンジンＰＥを含んでいて、プロセス・エンジンＰＥを用いるいくつかのプロセスの実行責任を負う。
【００３８】
プロセス・エンジンは、ワークフローおよびルールのうちの一方または双方を実行するソフトウェア・モジュールである。プロセス・エンジンの外部設置は性能低下を引き起こし得る遠隔起動を有することを意味するため、プロセス・エンジンＰＥは各エージェント内に埋め込まれていることが好都合である。
【００３９】
好適には、各エージェントのプロセスは、同レベルまたはより高いレベルを有する他のエージェントにより、外部から起動することができ、各エージェントが起動エージェントに提供するサービスに対応している。
【００４０】
任意の層におけるプロセス・エンジンは、例えば、ワークフローと、ワークフローおよびルールの各々を管理可能なルールエンジンの組合せであることを意図されている。例えば、プロビジョニングプロセスはワークフローとして表す方が適している一方、アラームコリレーションはルールの組合せとして表す方が適している。可能ならば、ワークフローを利用する方が、ルールの矛盾およびルールの管理を取扱う煩雑さが含まれないため好ましい。
【００４１】
図１に示す多層アーキテクチャは、異なるレベルでのプロセスの分割を可能にする。エージェントが配置可能であるレベルの数に制約がない。このように、可能な限り層の数を少なくすることと、分散型組織と集中型組織との間で自由にプロセスの割り当てを許すことのトレードオフを見つけるべくアーキテクチャを設定することが可能である。この分割はまた、業務ビューからシステム・ビューまで、異なるサービス・ビューを提供することも可能にする。
【００４２】
以下において、ワークフロー・エンジンが好ましいと思われるが、ルールエンジンもまた適用可能である。
【００４３】
エージェント（マスター・エージェントおよびサブレベル・エージェントの両方）を実行している各ホスト機は好適には、１個以上の制御エージェントＣＡを含んでいる。これらは、ローカル・エージェント（すなわち当該ホストで動作しているエージェント）のリソース使用状況および性能の測定、並びにリソース管理の局所最適化の実行に責任を負うモジュールである。制御エージェントＣＡは、マネージャ・モジュールおよび他の制御エージェントに結合されていて、測定されたデータをマネージャ・モジュールおよび他の制御エージェントのうちの一方または双方へ送信する。
【００４４】
以下にその構造を記述するマネージャ・モジュールＭＭは、プラットフォームの管理、構成、および制御に責任を負う。人間オペレータおよび外部ＯＳＳからの入力データを解析して、業績目標を満たすようにプラットフォームの構成を如何に調整するかを決定すべく構成されている。その主なタスクは以下の通りである。
プロセス記述およびデータ・モデルをプロセス・データベース（ＰＤＢ）からエージェントへ分散する、
制御エージェントから提供された情報を用いて、ホスト機上でのエージェントの分散、ドメイン管理（ネットワーク全体をエージェントに分割）、性能監視を含むプラットフォームの状態を監視する、
関連する制御エージェントとの対話を介してエージェントによるプロセスの実行用に割り当てられたリソースを最適に使用すべくアクションを実行する（これらのアクションの例として、エージェント間の負荷バランシングの変更およびワークフローの優先順位の変更、すなわち１個以上のエージェント内の待ち行列ジョブの再スケジューリングがある）、
他の動作支援システムと同様、外部システムとの対話。
【００４５】
以下にその構造を記述するマスター・エージェントＭＡは、プロセスの実行の最上位レベル調整の責任を負う。実際には、最上位層のエージェントに課せられたプロセスには、サブ層エージェントに課せられたサブプロセスが含まれていてよい。さらに、（エージェント以外の）外部エンティティとの対話または下位層エージェントにより分散的には容易にまたは効率的に実行することができないエージェント同士の調整を必要とする機能を提供すべく特徴付けられたプロセスが存在する。エージェントにより実行されるプロセスは、分散的に実行する必要があるものである。
【００４６】
各エージェント（Ａ１、Ａ２、Ａ３）は、任意のＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）機能等、任意のネットワークもおよびサービス管理機能（すなわちプロセス）を支援することができる。これにより、例えば、日中はサービスプロビジョニングにより多くのエージェントを投入し、夜間はネットワークの最適化により多くのエージェントを投入する等、タスクの優先順位およびリソースへのニーズに基づいてエージェントの実行時にタスクのカスタマイズおよびエージェントへの機能の再割り当てが可能になる。
【００４７】
エージェントにプロセス・エンジンＰＥの提供することにより、各機能（すなわちプロセス）によるリソースの使用状況並びに機能の起動生起を監視することが可能になる。これらのデータは、マネージャ・モジュールＭＭにより制御される自動プラットフォーム制御の主な情報源である。
【００４８】
各エージェント（Ａ１、Ａ２、Ａ３）は応答的および能動的な挙動の両方を示し、イベントにより生起されるだけでなく、プロセスを自発的に起動させる。
【００４９】
好適には、エージェント・モジュールは、例えばフォールト・トレランス問題に対応すべく配備が容易になるように制御エージェントまたはマネージャ・モジュールにより処理装置間を移動可能である。
【００５０】
図２に、本発明の好適な実施形態によるマネージャ・モジュールＭＭの内部構造を示す。
【００５１】
集中型マネージャ・モジュールＭＭは、例えばサブモジュールに編成されている。
【００５２】
サブモジュールのうち１個はＭＮＧ_ＣＮＳコンソールであり、一般に、管理コンソールＭＮＧ_ＣＮＳとして示される。好適な実施形態において、管理コンソールＭＮＧ_ＣＮＳは、以下のものを含んでいる。
− プラットフォーム性能データを保持している性能データベースＰＦＭ_ＤＢに関連付けられた監視コンソールＭＣ、
− 目標および制約コンソールＧＣ、
− リ−アロケータ・コンソールＲＣ、
− 管理用コンソールにより管理される管理データを含む管理データベースＡＤＢが関連付けられている管理用コンソールＡＣ、
− サービス生成環境コンソールＳＣＣ
並びに
− 容量計画モジュール（図示せず）、
− 予測コンソール（図示せず）。
【００５３】
目標コンソールＧＣ、管理用コンソールＡＣおよびサービス生成コンソールＳＣＣは全て、プロセス記述データベースＰＤＢに結合されている。
【００５４】
マネージャ・モジュールＭＭは、目標および制約コンソールＧＣおよびリ−アロケータ・コンソールＲＣに直接結合されたリソース割り当てＲＡを含んでいる。
【００５５】
リソース割り当てＲＡはまた、例えば管理用データベースＡＤＢ、並びにプラットフォーム性能データを保持している性能データベースＰＦＭ_ＤＢに結合されている。
【００５６】
好適な実施形態において、マネージャ・モジュールＭＭはさらに、監視データ取得モジュールＭＤＭおよびプラットフォーム・コントローラＰＣを含んでいる。
【００５７】
監視データ取得モジュールＭＤＭは、プラットフォーム・コントローラＰＣから性能データベースＰＦＭ_ＤＢへ性能データを転送すべく構成されている。
【００５８】
さらに、リソース割り当ては、例えば、外部ＯＳＳと管理プラットフォームとの間の対話を監視する外部インタフェース・モジュールＩに結合されていてよい。
【００５９】
プラットフォーム・コントローラＰＣは、一般に、マネージャ・モジュールとエージェントとの間のメディエーターとして動作する。
【００６０】
特に、プラットフォーム・コントローラＰＣは、マネージャ・モジュールの外部にあるマスター・エージェントＭＡ（図示せず）、およびリソース割り当てモジュールＲＡとの接続を実装し、監視コンソールＭＣ、監視データ取得モジュールＭＤＭ、管理用コンソールＡＣおよび管理用データベースＡＤＢ、並びにプロセス記述データベースＰＤＢに結合されている。
【００６１】
目標および制約コンソールＧＣは、プロセス記述データベースＰＤＢに保存されているプロセスに関連付けられていて、合わせて目標データと呼ばれる業務目標（例：サービスレベル合意すなわちＳＬＡ）および制約の規定を意図としている。
【００６２】
サービスレベル合意すなわちＳＬＡは、業務プロセス・レベル品質の（契約締結または単に同意された）定量化である。ＳＬＡは、性能指標（平均実行時間、パーセンタイル値等）に基づいており、これらの指標の値がプラットフォームで保証される旨を宣言する。一般に、ＳＬＡはＳＬＡ目標（性能指標）およびＳＬＡ違約条項（ＳＬＡ目標と収集された性能データとの比較に基づくＳＬＡコスト関数）、例えばＳＬＡ違反の経済的違約の見積、を識別する特定の言語（「文法」）により記述することができる。
【００６３】
ＳＬＡは一般的な業務プロセス（例：ワークフロー）または（１個以上のワークフロー属性において定義可能な）その特化されたものの１個に関連付けることができ、その場合、特化されたものに対するＳＬＡは通常、ルート業務プロセスのＳＬＡを上書きする。
【００６４】
制約は、リソース使用状況に関するデータに注目する。これらは、好適には以下のものを含んでいる。
− 保証すべき最低スループット、管理可能な最小数のネットワーク要素（より理解し易い業務測定基準を用いるために、パーセンテージではなく「スループット」という用語を用いるのが好適である）で表される、予め割り当られたリソース、
− 割り当て可能なリソースの最大数（大域的リソースのコストまたはパーセンテージで表され、デフォルト値は例えば５０％）。
業務制約を変更する際に、予め割り当られたリソースが割り当て可能な最大容量を上回るか否かを検証することが必要である。
【００６５】
本発明の好適な実施形態によるリソース・アロケータＲＡ（以下、リ−アロケータと呼ぶ）は集中型であって、プラットフォームを適応的に制御すべくエージェントへのリソース割り当てを管理する。これは、例えば以下を受容すべく構成されている。
ｉ） 目標コンソールＧＣからの業務目標。
ｉｉ） 全てのホスト機の性能データ（実行時間等）およびハードウェア・リソース使用状況を監視して、これらのデータを性能データベースＰＦＭ_ＤＢから取得する。
ｉｉｉ） オプションとして、負荷テストから得た情報、すなわちワークフローをより多く使用した場合のリソース使用状況に関する測定値。
ｉｖ） 利用可能なホスト機およびそれらのハードウェア特性（正規化されたＣＰＵ速度、例えば標準性能評価協会によるＳＰＥＣＩＮＴ２０００レートを用いたもの）に関するデータ。これは、全体的な処理能力（例えば基準ＣＰＵの１時間当たり秒数で測定）を監視する。
ｖ） 全てのホスト機のハードウェア・リソース使用状況（性能データベースＰＦＭ_ＤＢから）。
【００６６】
リ−アロケータＲＡは好適には、評価モジュールおよび決定モジュールの２個のサブモジュールを含んでいて、本明細書の以下にその例証的な記述および機能を述べる。
評価モジュールは、
− 最上位レベル（ＭＡ）ワークフロー実行要求、および
− 全てのエージェント内のワークフロー実行要求待ち行列
に関するデータを受信すべく構成されている。
【００６７】
さらに、評価モジュールは、過去のワークフロー実行要求の履歴的傾向および要素および複雑度に関する管理された通信ネットワークの傾向を分析すべく構成されている。
【００６８】
決定モジュールは、過去情報に基づいて、プラットフォームが後述するいくつかの基準に従い全ての要求に対応可能か否かを決定すべく構成されている。
【００６９】
プラットフォームが全ての要求を管理することが不可能な場合、決定モジュールは、例えば警告メッセージを送信、どのアクションが状況を改善できるかを決定すべく構成されている。
【００７０】
特に、リソースは十分あるが、ＳＬＡが完全に満足されていない場合、決定モジュールは処理（すなわちワークフロー実行）をプラットフォーム全体にわたり再配分させるべく構成されている。好適には、これらのアクションは、ワークフローの異なるインスタンスに関連付けられた制約および優先順位を考慮している。
【００７１】
管理用コンソールＡＣは、例えば、少なくとも以下のうち一組を定義および監視することを意図している。
ｉ） プラットフォーム、すなわち分散エージェントによるプロセスの実行の処理能力を保持するホストＨのハードウェア構成。例えば、新規のホスト機が所定のホスト群に追加された際に、自動的にプラットフォーム全体に結合される。これは、例えば、ホストが自身の存在を通知するか、または、管理用コンソールが例えばＧＵＩを介してオペレータにより入力されたコマンドを受信することによりホストＨを認識するためである。
ｉｉ） ソフトウェア分散／割り当てを規定するためのＧＵＩ（すなわち目標および制約コンソールＧＣにおける制約に関するデータを受信するインタフェース）。
特に、これを用いて、ホスト機群を例えば以下に基づいて設定する。
− 地理的制約（例えば、特定のワークフローは、ある領域にインストールされているが別の領域にはインストールされていないエージェントだけで実行することができ、あるいは、特定のホスト機だけで実行することができる）、
− 階層的制約（例えば、特定のマシンでは第２レベルのワークフローのみ動作可能である）。
− 業務制約（すなわち、特定の種類のプロセスに対する制約）。
ｉｉｉ） ワークフロー・スケジュール（例えば、サービスプロビジョニングワークフローは朝の時間帯にのみスケジュールされる）。
【００７２】
リ−アロケータ・コンソールＲＣは、リソース再割り当てポリシ、すなわち、業務制約および監視されたデータに基づいて業務目標の満足度を最適化すべくリソースをいつ、どのように再割り当てするか、の命令を規定すべく構成されている。リ−アロケータ・コンソールでは、集中型および分散型制御の両方のポリシを入力することができる。特に、以下の定義が可能である。
ｉ） 最高レベルのＳＬＡ満足度に達すべく、いつ、どのようにワークフロー優先順位に作用すべきかを規定する、集中制御用のルール。これらのルールは、管理されたプラットフォームを全体として見て（すなわち、マシンに対して直接的には作用しない）、リソース割り当てモジュールの全ての入力データおよび予測的データに基づいて作用する。
ｉｉ） ローカル・ソフトウェアおよびハードウェアのリソースの使用状況を最適化する目的で、関連ＣＡ（スレッド並列度およびロード・バランシング）を通じて単一エージェントに作用する、分散制御用のルール。
ｉｉｉ） ルールに関する複雑な式を計算する機能。
【００７３】
監視コンソールＭＣは、以下のような監視情報を閲覧すべく構成されている。
ｉ） 定時（例：１日当たり）平均スループット、待ち行列（例：１日当たり）の要求数、平均実行時間（例：１日当たり）、目標が設定された全ての業務トランザクションの期限。
ｉｉ） 合意されたＳＬＡ指標の測定値間の差違に関する、サンプリング期間にわたり計算されたＳＬＡの状況（違反したものは強調表示）、および関連コスト関数の評価。
ｉｉｉ） 全てのワークフローにおけるハードウェア・リソースの使用状況、例えば秒単位でのＣＰＵ使用量および使用ＲＡＭのうちの一方または双方（単一レベルおよびそれを下回る全てのレベルについて）。これは、全てのホスト機が他とは計算能力が異なるため、ハードウェア・リソースの使用状況、例えばＣＰＵ使用量、は基準ＣＰＵに正規化される。
ｉｖ） アカウント情報。全てのワークフローにおいて使用されたリソース（合計に対するパーセンテージ、およびコストに関して）。
【００７４】
監視コンソールＭＣにより、階層的に、ワークフロー（特に、ワークフローの全てのブロック）の性能およびリソース使用状況を閲覧することが可能になる。全てのＳＬＡについて、リソースの使用が多いために、最適化する価値があるワークフローについてレポートを提出することが可能である。ワークフローの異なるレベルに他の測定点が設定された場合、それらはＭＣにも提示される。また、ＭＣは、ワークフローにより使用されたリソースに関して、支払い請求に関する情報を表示する。
【００７５】
サービス生成環境コンソールＳＣＣは、ＰＤＢにおけるプロセス、すなわち管理プラットフォームにおいて提供される全ての業務機能を定義、生成、および変更すべく構成されている。これは、本タスクの実施を容易にすべく、グラフィック・インタフェースに基づいている。本コンソールもまた、ワークフローに新規の監視点を挿入可能にしている。
【００７６】
さらなる実施形態において、ＭＭモジュールにより管理されるデータはまた、ＭＭモジュールに予測コンソールおよび容量計画モジュールを追加することにより、有用な容量計画を実現するために用いられる。
【００７７】
予測コンソールは、有用な容量計画活動を実現するための使用状況予測を設定すべく構成されている。本コンソールの入力は以下の通りである。
ｉ） 期待スループット、および
ｉｉ） ネットワーク・ホストの期待個数および種類（この数値は、プロセス記述データベースにおけるデータの予測として計算することもできる）。
【００７８】
容量計画モジュールは、時間経過に伴いハードウェア・リソースを保証すべく構成されている。これは、予測コンソールおよび他のコンソール（目標および制約コンソール、管理用コンソールおよびリ−アロケータ・コンソール））から入力を受信して、リソースの可用性を確認すべく構成されている。
【００７９】
リソースが十分でない場合、容量計画モジュールは、予想される増加傾向に対処するために必要なハードウェアの量について、コンソールのオペレータに警告すべく構成されている。本モジュールは、以下のうち少なくとも１個を含む一組のパラメータに基づいて分析を行う。
ｉ） 期待スループット（履歴傾向に関して）、
ｉｉ） 全てのワークフロー（特に第一レベルのワークフロー）のリソース使用状況の情報、
ｉｉｉ） 地理的制約。
【００８０】
容量計画モジュールは不確実なデータ（特に長期データ）に基づいているため、主に通知目的で構成されている。将来のニーズを強調することができるが、好適には割り当てＲＡと対話することはない。
【００８１】
図３に、ホストの全体的な性能および当該ホストで動作する全てのエージェントの制御に責任を負うエージェント・モジュールＡおよび制御エージェントＣＡを含むホスト機の内部構造の例を示す。
【００８２】
各エージェントＡは、以下の構成要素のうち少なくとも一組を含んでいる。
− ワークフロー待ち行列または待ち行列ＷＦＱ。これは、各々の下位待ち行列が同一優先順位の要求を保持している多レベルの優先順位待ち行列である。エージェントへ送信された各々のワークフロー要求は、自身の優先順位に基づいて対応する下位待ち行列に挿入される。図３において、異なるワークフローをＷＦ１、．．．、ＷＦｎで示す。下位待ち行列内でワークフロー要求の欠乏を避けるため、待ち行列ＷＦＱは、例えばタイムアウト基準に基づいて、下位待ち行列内の要求について優先順位の更新を実施する。
【００８３】
待ち行列ＷＦＱ上の情報、特に以下のものが待ち行列ＷＦＱに関連付けられている。
【００８４】
各種のワークフローについて測定されたワークフローのＣＰＵ消費時間（これらのデータはＰＦＭ_ＤＢから取得された）を加算して計算された推定ＣＰＵ消費時間、
特定種類のワークフローが他のエージェントにより実行されることを要求される速度（例：ワークフロー／時間）（要求はエージェント内の待ち行列に入れられる）を統計的に推定する、要求入力速度、
− ワークフロー待ち行列ＷＦＱに関連付けられたワークフロー・スケジューラＷＦＳ。これは、待ち行列に含まれるワークフローＷＦｎをそれらの優先順位に基づいてスケジューリングすべく構成されている。エージェントの１個以上のプロセス・エンジンがワークフローを実行する準備ができる都度、スケジューラは、待機中のプロセス・エンジン・スレッドの１個へ待ち行列内でより高い優先順位のワークフローを送信する。
− ワークフロー・スケジューラＷＦＳにより制御される複数のプロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎ。全てのエージェントは、設定可能な個数のワークフローを同時に実行することが可能である。これは、エージェント内で複数のプロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎ（独立エグゼキュータ）を設定することにより実現される。各プロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎは、同時に１個のワークフロー、例えばＪａｖａ言語で実装されたスレッド、を実行することが可能である。
【００８５】
制御エージェントＣＡは、好適にはソフトウェアで実装された以下の構成要素の少なくとも一組を含んでいる。
− リソース・モニタＲＭ：本構成要素は、自身の制御下にあるエージェントにおけるハードウェアおよびソフトウェアのリソース使用状況に関するデータを監視および収集すべく構成されている。
【００８６】
その役割は、ホスト上でのエージェント（エージェントホスト）を含む現在のリソース使用状況およびワークフローの実行によるＣＰＵとメモリ消費の両方を測定することである。測定された値は、マネージャ・モジュールＭＭおよびスレッド・コントローラＴＣへ送信される。
− スレッド・コントローラＴＣ。これは、リソース・モニタＲＭおよびワークフロー待ち行列ＷＦＱに結合されていて、局所性能を制御すべく構成されている。これは、能動的にエージェント・スレッドの並列性を管理すること意図している。これは、入力として、待ち行列内で実行待ちであるワークフローの個数、実行中のマシンのＰＥスレッドのＣＰＵ使用量およびＰＥの総数を受信すべく構成されている。上記の入力に基づいて、スレッド・コントローラＴＣは、最適なワークフロー実行並列性を実現すべくプロセス・エンジン・スレッド（ＰＥスレッド）の個数を増減させる。これは、例えば、実行待ちであるワークフローを待ち行列が含んでいる場合、ＰＥスレッドの総数が許容された最大個数を下回る場合、かつＣＰＵ使用量が指定された閾値を下回る場合に、新規のＰＥスレッドを生成する。しかし、エージェントが、外部リソース（装置、ネットワーク機器等）との直接対話を担当している場合、ＰＥスレッドの許容最大個数は外部リソースの許容可能な並列性により制限される。さらに、いくつかのＰＥスレッドが所定の期間使用されていないことがわかった場合、スレッド・コントローラはＰＥスレッドのガーベージ・コレクタを実行する。
− プロセス・エンジン・スレッドに結合されたディスパッチャＤ。本構成要素は、他のエージェントへワークフロー実行要求を送信すべく構成されている。各ＰＥスレッドはディスパッチャＤを用いてそのような要求を送信する。
【００８７】
ディスパッチャは、例えば、以下のようにロード・バランシング・アルゴリズムを用いて、他のエージェントへ要求を送信する。これは、要求を送信するための最適なエージェントを、２段階で選択する。
【００８８】
第一に、ＣＰＵおよびメモリの観点から負荷がより少ないホストを選択する。第二に、エージェント待ち行列の推定ＣＰＵ消費時間の最小量に基づいて選択されたホストの利用可能なエージェントを選択する。
【００８９】
制御エージェントＣＡは、好適には自身の側に、好適な実施形態による重要な特徴を有している。これらは、自身のプロセス・スレッドの並列性を能動的に管理する（局所最適化）ことが可能である。待ち行列の再順序付けおよび並列性管理の二つの能力が合わさって、本発明の一態様による適応型機構の基礎をなす。
【００９０】
図４に示す本発明の別の実施形態によれば、例えば、ホスト機Ｈ上に単一のエージェント・モジュールＡが存在するならば、リソース・モニタＲＭ、スレッド・コントローラＴＣ、および、ディスパッチャＤをエージェント・モジュールに付加することができる。
【００９１】
本発明のシステムの好適な実施形態は、移動特性を有するエージェントを実装するＪＡＤＥ（Ｊａｖａエージェント開発フレームワーク）、プロセス定義を行なうＸＰＤＬ（ＸＭＬプロセス定義言語）、およびＳｈａｒｋなどのＸＰＤＬワークフロー・エンジンを使用して実装される。
【００９２】
以下に、動作を示す図と共に、リソース割り当てモジュールについてより詳細に記述する。
【００９３】
リ−アロケータＲＡは、制約プロセス、データ操作、および設定変更の機能を有するエキスパート・ルールベース・システムとして実装することができる。管理されたネットワーク、外部システム、人間の知識、および内部分析から得られた全てのデータ、制約、およびルールがその知識ベースを構成しており、これを関連する知識データベースにより具体的に表現することができる。
【００９４】
リ−アロケータ・モジュールＲＡは、シナリオの状況に応じてケース毎に設定可能な所定の分析期間で評価および決定モジュールを実行する。
【００９５】
第一に、リ−アロケータは、後続する期間のために予測されたサービス／機能要求の個数を評価すべくバスＢを介してプロセス要求に関するデータを外部システムから取得し、この情報を関連する知識データベースに保存する。
【００９６】
次いで、決定モジュールは、所定の業務目標を最適な仕方で達成すべく実行されるアクションを見出すためにリソース再割り当てルールを有効化する。
【００９７】
詳細には、各々の期間Ｔで、リソース割り当てモジュールは、履歴情報に基づいて、待ち行列に入れられた要求の個数および予測された要求の個数を考慮する。当該モジュールは、利用可能なハードウェア・リソース（主にＣＰＵとＲＡＭ）の量の第一の評価を実行する。これらのデータは、後述する「バックグラウンド・エラー訂正」を考慮しつつ、当該期間の終わりで実際に測定されたデータを使用して調整される。
【００９８】
以下のデータが統計方法で集められる。
− 各々のワークフローについて各々のレベルにおけるＣＰＵニーズ、および
− 下位ワークフロー要求の観点での最上位レベルのワークフローの合成（アーキテクチャの全てのレベルに関連付けられたＣＰＵニーズがあれば、この情報はまた、地理的制約があればこれを考慮しなければならない）。
【００９９】
収集された情報は、時刻ｔにおける待ち行列の長さと内容、および期間[ｔ，ｔ＋Ｔ]の間に（予想により）期待される要求の個数に相関付けられて、後続する期間の組または複数の期間の後に置かれた期間の組として意図される後続期間におけるＣＰＵ能力の合計必要量を計算する。
【０１００】
次いでＣＰＵの総量、すなわち新たな期間（レベルおよび地理的制約を考慮して）に対して要求される計算能力が、利用可能なＣＰＵ能力と比較される。これが十分でない場合、コンソールに警告（新規ハードウェアを要求する）が生成されて、ワークフローの優先順位により負荷をどのように扱うかが決定される。
【０１０１】
利用可能なハードウェア・リソースに関するデータを調整するために「バックグラウンド・エラー訂正」が考慮される場合、各期間毎に全てのワークフローについて、かつ全てのホスト機について、先行期間で使用されたＣＰＵの量が、異なるワークフローにより使用されたＣＰＵの量と比較される。この値を用いて、後続期間でのＣＰＵの実際の利用可能性を「修正する」ために用いる。
【０１０２】
本発明による方法およびシステムでは、優先順位に基づくポリシを使用することにより、異なるレベルの優先順位がある。各期間Ｔ毎に、決定モジュールは管理アルゴリズムに従い、業務目標を達成すべく優先順位付き待ち行列を操作することができる。欠乏を避けるために、ワークフロー要求が優先順位の低い待ち行列で過大な時間を消費した場合、その優先順位が自動的に更新されて、より高い優先順位付き待ち行列へ要求が移動されるようにする。
【０１０３】
本発明の好適な実施形態によれば、管理アルゴリズムは、ステップ毎にリソース設定を改良して、漸進的な挙動により最適設定に到達しようとする適応型ソリューションに基づいている。現行アプローチの結果は、平均的なワークフロー実行時間の少なくとも２〜３倍（合理的な期間は、アプリケーションの状況に応じて５分〜１時間以上の範囲で変動し得る）である分析の期間を用いて保証される。
【０１０４】
優先順位は、以下を考慮しつつ、ワークフローの全ての実行に関連付けられている。
− 同意されたＳＬＡ（リスクの大きいワークフローほど、高い重みを維持する）の状況、
− ワークフローの目標コンソールにおいて規定された初期優先順位、並びに各ＳＬＡの優先順位および経済的意味、
− ワークフロー用の予め割り当られた最小限のリソース量、
− 割り当て可能なリソース最大量（ＳＬＡの初期交渉の間に規定される）。
【０１０５】
これは、優先順位が時間依存であることを意味する。ワークフロー性能のインスタンスがＳＬＡに近づいている（すなわち、性能が低下している）場合、その優先順位がより高く設定される。
【０１０６】
プロセス・エンジンの代わりに、例えば統計技法によるＣＰＵ評価等、機能の実行を定義および測定する任意の手段を用いてもよい。
【０１０７】
以下において、提唱されたアーキテクチャに基づく性能適合シナリオの例を示す。最適化すべきリソースはＣＰＵ負荷である。
【０１０８】
現行シナリオによれば、最上位レベルのワークフローは、時間ｔ＞＞ΔＴ（ΔＴは観測期間）内に完了されるワークフローのパーセンテージで表現された優先順位特性により特徴付けられるＳＬＡが関連付けられた業務である。最後の仮定は、プラットフォームに対し期間ｔ内に再調整するのに十分な時間を与えるために必要である。
【０１０９】
最上位レベルのワークフローは、多くの下位ワークフローから構成されている。全てのワークフローは、実行前の待ち行列内での待ち時間およびワークフローＣＰＵ時間スライスに影響を及ぼす優先順位特性を有している。
【０１１０】
入力データは以下の通りである。
− 各ワークフローおよび各ホスト機のＣＰＵ負荷[秒]、
− 制約、すなわち同一ワークフローはホスト機郡の一部だけで実行可能である、
− 下位ワークフローの観点からの第一レベルのワークフロー構成、
− 過去のΔＴ期間におけるワークフロー到着数、
− 過去のΔＴ期間におけるワークフロー実行回数。
【０１１１】
目標は以下の通りである。
− 次のΔＴ期間で全てのワークフローを実行するのに計算リソースが十分であるか否かを予測する、
− 計算リソースがＳＬＡを遵守するのに十分であるか否かを予測する、
− ワークフローの実行優先順位がＳＬＡの遵守に到達するための適合。
【０１１２】
性能適合プロセスは、全てのΔＴ期間で実行された監視に基づいており、最短プラットフォーム適合時間を表す。
【０１１３】
図５のフロー図を参照するに、全てのΔＴ期間で実行された監視の例をレポートしており、割り当てＲＡにより各ΔＴについて以下のステップが管理される。
１） 各ホストでの各ワークフローのＣＰＵ負荷の評価（ステップ１００）。これは、ホスト・サンプル上でワークフローの負荷試験を実施して、ＣＰＵドキュメンテーションを用いることにより達成される（先験的予測）。得られた値は、ワークフロー実行に対する制約を考慮しつつ、先行ΔＴで実行された各ワークフローに関連付けられた実際のＣＰＵ時間を使用して微調整することができる、
２） 未だ待ち行列で待機しているワークフローに加え次のΔＴ内に到着が予想されるワークフローを実行するために必要なＣＰＵ時間の予測（ステップ１２０）、
３） 計算リソースの観点から必須であるホスト群を識別すべく、ステップ１２０で評価されたＣＰＵ時間を、利用可能なＣＰＵ時間と比較（ステップ１４０）して、影響を受けるＳＬＡに第一ワークフローを関連付ける。必要とされるＣＰＵリソースが利用可能なＣＰＵリソースより大きい場合、ＣＰＵリソース不足を通知する（ステップ１５０）、
４） 各ＳＬＡについて、ＳＬＡ要求を満たす最小数のワークフローを実行するために必要なＣＰＵ時間を予想（ステップ１６０）し、次いでこれを利用可能なＣＰＵ時間と比較（ステップ１７０）して、ＳＬＡを遵守するために計算リソースが十分か否か判定する、
５） 上のステップにおいて、ワークフローを実行する現行のプラットフォーム優先順位設定がＳＬＡ制約に対応できないとされた場合、（計算リソースの観点からワークフロー重みを考慮しつつ）ワークフロー優先順位のバランスを見直して、ワークフロー優先順位の適合手法（ステップ１８０）を通じて設定を調整しなければならない、
６） 優先順位の適合が必要でない場合、または、優先順位適合が実施された場合、システムは性能適合プロセスを終了させ、次のΔＴ監視期間を待つ。
【０１１４】
性能適合プロセスの予測手法の例を以下に詳述する。以下の定義を行なう。
− ΔＴ：監視期間および最短システム適合時間、
− ＬＷｆ（ｎ）：ホストｎ上でのワークフローｗｆの実行に要するＣＰＵ負荷[秒]。これらの値は、先験的に（または、自動学習方式を用いて）推定し、次いでプラットフォーム動作の間に調整することができる。例えば、ある時間にわたる移動平均による。
− ＶＷｆ（ｎ）：ホストｎ上のワークフローｗｆに対する制約であって、次式で与えられる。
【０１１５】
【数１】
【０１１６】
次のΔＴ内に予見される全てのワークフローを実行するために必要な予想ＣＰＵ時間は次式で計算される。
【０１１７】
【数２】
【０１１８】
ここで、
ｇは、集合ＷＦ（ｇ）内の全てのワークフローについて同等なホストのグループである。これは、集合ＷＦ（ｇ）に属する各ワークフローが、グループｇの中の１個のホストにより同じ確率で実行できることを意味している。
【０１１９】
ｌｗｆはグループｇのホスト上のワークフローｗｆを実行するために必要な予想ＣＰＵ時間であり、次式で与えられる。
【０１２０】
【数３】
【０１２１】
ＮＥＰｗｆはワークフローｗｆの予見される実行回数であり、次式で与えられる。
【０１２２】
ＮＥＰｗｆ（ｇ）＝ＮＱｗｆ＋ＮＡＰｗｆ（ｇ）
ここで、
ＮＱｗｆは、次式により第一のレベル・ワークフロー呼び出しの観点で表された実行待ち行列のワークフローｗｆの総数である。
【０１２３】
【数４】
【０１２４】
ＮＡＰｗｆ（ｇ）は後続するΔＴ期間において予見されるワークフローｗｆの総予想数であり、次式で与えられる。
【０１２５】
【数５】
【０１２６】
ここで、
Ｐｉは先行するΔＴｉに到着したワークフローの重みである。
【０１２７】
ＮＡｗｆ（ｌ１），ｉ（ｎ）は、期間ΔＴｉにホストｎに到達した、第一のレベルのワークフローｗｆｌ１の下位ワークフローであるワークフローｗｆの数である。
【０１２８】
上述の三種の目標を参照するに、予想および適合ステップは以下のように実行される。
【０１２９】
利用可能なＣＰＵ時間が後続するΔＴで予見されるワークフローを実行するのに十分であるか否かを予想すべく、各々のグループｇについて、以下のようにＣＰＵ時間ＣｐｕＴｉｍｅＰ（ｇ）と、グループｇで利用可能なＣＰＵ時間との比較が実行される。
【０１３０】
【数６】
【０１３１】
もし、
【０１３２】
【数７】
【０１３３】
ならば、システムは全てのタスクを実行するための十分な計算リソースを有している。
【０１３４】
【数８】
【０１３５】
ならば、システムはより多くのＣＰＵ時間を必要するため、
ａ） 計算リソースの観点から必須であるホストのグループｇ
ｂ） このようなリソース不足でより重大な影響を受ける恐れのあるＳＬＡに関連付けられた第一レベルのワークフローを含むメッセージを送信する。
【０１３６】
計算リソースがＳＬＡを遵守するのに十分であるか否かを予想すべく、第一レベルのワークフローｗｆｌ１で規定された各ＳＬＡについて、ＳＬＡを遵守するために後続するΔＴで実行されるｗｆｌ１の個数ＮＳＬＡｗｆｌ１が計算される。
【０１３７】
ＳＬＡが、時間ｔ（但しｔ＞＞ΔＴ）内に実行されるワークフローｗｆｌｌのパーセンテージｐ［％］として規定されている場合、ＮＳＬＡｗｆｌｌは次式で与えられる。
【０１３８】
【数９】
【０１３９】
ここで、
ＮＳＬＡＱｗｆｌ１は、各ΔＴｉについて、ΔＴｉ内に到着して未だ待ち行列内で待機しているワークフローｗｆｌ１の数と、ＳＬＡを遵守すべくこれらのワークフローを期限内に完了させるために依然として利用可能なΔＴｓの数ｎ＝（ｔ−ｋΔＴ）／ΔＴとの比の和により与えられる。ｋは、ワークフローが到着してから待ち行列内で待機している間のΔＴｓの数であり、
ＮＳＬＡＰｗｆｌｌは、次のΔＴに到着するワークフローｗｆｌｌの予想数と、ＳＬＡを遵守すべくこれらのワークフローを完了するために依然として利用可能なΔＴｓの数との比（すなわちｔ／ΔＴ）である。
【０１４０】
従って、ワークフローｗｆｌ１がＳＬＡを遵守すべく必要とされるＣＰＵ時間は、次式で与えられる。
【０１４１】
【数１０】
【０１４２】
ここで、
【０１４３】
【数１１】
【０１４４】
ここで
【０１４５】
【数１２】
【０１４６】
かつ
【０１４７】
【数１３】
【０１４８】
ここで、ＮＥｗｆ（ｗｆｌｌ）（ｇ）は、ワークフローｗｆｌ１の各々の実行に対してホスト・グループｇで実行されるワークフローｗｆの予想数であり、次式で与えられる。
【０１４９】
【数１４】
【０１５０】
再び、
【０１５１】
【数１５】
【０１５２】
ならば、システムはワークフローｗｆｌ１がＳＬＡを遵守すべく十分な計算リソースを有している。
【０１５３】
【数１６】
【０１５４】
である場合、システムは、ワークフローｗｆｌ１がＳＬＡを遵守させることができず、従って、以下の節に述べるワークフロー優先順位適合手法が適用される。
【０１５５】
ワークフロー優先順位適合手法は、ＳＬＡに関連付けられた少なくともタイプＡの第一レベル・ワークフローが存在する場合に適用され、このとき次式が成立する。
【０１５６】
【数１７】
【０１５７】
一方、他のタイプの第一レベル・ワークフローの場合、次式が成立する。
【０１５８】
【数１８】
【０１５９】
本手法は各種のアクションで構成され、以下にその少なくともいくつかの例を複雑度の順に記載する。
ａ） タイプＡワークフローの優先順位を上げる。
ｂ） タイプＢワークフローの優先順位を下げる
ｃ） 各々の第一のレベル・ワークフローに重みを関連付けてアクションａ）またはｂ）を実行すべく最も関連のあるものを選択する
ｄ） 違約条項が時間とともに増大しないＳＬＡについて、先行ΔＴにおいて既にＳＬＡの遵守に失敗したワークフローの優先順位を下げて、
ｅ） 違約条項が時間とともに増大するＳＬＡについて、先行ΔＴにおいてＳＬＡの遵守に失敗したワークフローの優先順位を上げる。
【０１６０】
アクションｄ）およびｅ）は、目標および制約コンソールＧＣで規定されたＳＬＡ違約のコスト影響を最小化しようと試みる機能に基づいている。
【０１６１】
本手法は便利な点として、各々のワークフローに割り当てられるＣＰＵ時間の最大量等、リソース使用に対する制約を考慮し続ける。これは、予約されたＣＰＵ時間の最大量を既に使用しているワークフローの優先順位をさらに上げることができないことを意味する。
【０１６２】
各ワークフローの正確なコストの集計が重過ぎる場合、別の可能な方法として、実行された「構築ブロック」の数をエージェントが所定の間隔（例えば５分毎）で集計してシステムのリソース使用状況（例えばＣＰＵ使用）との相関を求めることができる。
【０１６３】
負荷が過剰な状況下にあるコンピュータシステムの性能を推定するために多変量回帰技術がしばしば利用される。この選択は、容量を超えて実行された多くのインフィールドＯＳＳの回数の挙動の分析に基づいている。その結果、ＣＰＵ使用等、大多数のＯＳＳの共通の性能尺度を線形回帰によりモデル化できることがわかった。システム応答時間は、例えば、適度な指数法則に従い増大する。このように、システム性能予測の下限は、システム・リソースデータおよびワークフロー実行データに基づいて多変量線形回帰技術により得られる。
【０１６４】
簡単な多項式モデルの例を次式に示す。
【０１６５】
Ｕｃｐｕ＝ａ０＋ａ１・ＮＡ＋ａ２・ＮＢ＋ａ３・ＮＣ
ここで、
Ｕｃｐｕ ＝ エージェントのＣＰＵ使用
ＮＡ ＝ 構築ブロックＡの実行回数
ＮＢ ＝ 構築ブロックＢの実行回数
ＮＣ ＝ 構築ブロックＢの実行回数
である。
【０１６６】
好適には、全ての尺度（特にＳＬＡ定義）は、一貫した方法で適合を最適化するための経済的数量で表現すべきである。
【０１６７】
例えば図６に、本発明による柔軟性およびスケーラビリティに特徴を有する３層サービスプロビジョニングシナリオの設定を示す。
【０１６８】
この例では、最下位層のエージェントは、ネットワーク要素との対話の責任を負っており、リソース・プロキシと呼ばれ、ＲＰｌ、ＲＰ２、ＲＰ３で示す。
【０１６９】
「オファー１」と名付けられた広帯域サービスは、ＩＰ接続を得るべく、アクセス装置（例：ＡＤＳＬ設備）を含む通信ネットワーク、ＡＴＭバックボーンおよびＢＡＳ（広帯域アクセス・サービス）を介して提供される。
【０１７０】
ＲＰにより提供されるサービスの例として、ポートの設定、交差接続の生成、接続属性の変更がある。その各々は、設備へ／から、送信および受信のうちの一方または双方をされる一連の基本命令を含んでいてよい。
【０１７１】
ＡＡ１、ＡＡ２、ＡＡ３は各々、ＡＤＳＬ設備Ｅ（エンドツーエンド回路の端点Ａ）の画像を表すリソース・プロキシＲＰ１、ＡＤＳＬ設備Ｅに接続しているＡＴＭスイッチＳＷの画像を表すリソース・プロキシＲＰ２、およびＢＡＳ（エンドツーエンド回路の端点Ｚ）の画像を表すリソース・プロキシＲＰ３を管理するエージェントである。
【０１７２】
サービス「オファー１」の提供活動に関わる多レベル・ワークフローを図７に示す。
【０１７３】
レベル１すなわち最上位レベルのワークフローは、２個のステップまたはタスクを含んでいて、マスター・エージェントＭＡにより実行される。第一のもの（ＡＤＳＬ接続性）は、エージェント・レベル（ＡＡ１、ＡＡ２、ＡＡ３）で実行されるレベル２のワークフローの実行を必要とする一方、第２のもの、すなわちメールボックス・タスク（本例では詳述しない）は外部プラットフォームにより実行可能である。
【０１７４】
ＡＤＳＬ接続性タスクは従って、一連のレベル３ワークフローを含むレベル２ワークフローであり、リソース・プロキシレベル（ＲＰｌ、ＲＰ２、ＲＰ３）で実行されるベンダー依存の技術である。レベル３ワークフローは、リソース・プロキシにより通信ネットワーク設備側で実行する必要がある一連のコマンドを含んでいる。レベル２ワークフロー「ＡＤＳＬポート・ベンダーＡ生成」を拡張したことによるレベル３ワークフローの例を図７に示す。
【０１７５】
監視コンソールＭＣは、各ワークフローのリソース使用状況（ＣＰＵ、ＲＡＭ）および経過時間を測定して、特定のベンダーまたは特定のワークフローに問題があれば強調表示する。
【０１７６】
メールボックスが無い点以外はサービス「オファー１」と同様の別サービス「オファー２」が存在すると仮定すれば、目標コンソールは、ＳＬＡ制御ルールおよび関連コスト関数を用いてオファー１およびオファー２に対してＳＬＡを規定することができる。サービス「オファー２」に対するＳＬＡがより重要（例えば、「オファー２」に関連付けられたコスト関数は平均実行時間である１秒を超えた秒数に等しく、「オファー１」に関連付けられたコスト関数は平均実行時間である４秒を超えた秒数に等しい）場合、「オファー２」に対する優先順位は「オファー１」の優先順位より早く増大する。これは、同数の要求に対してハードウェア・リソース（例：ＣＰＵ）が不足している場合、「オファー２」のスループットが「オファー１」のスループットより高いことを意味する。
【０１７７】
従って、プラットフォームは、外部オペレータにより設定されたにせよ、またはエージェント飽和によるものにせよ、自身の目標に達するようリソース使用を調整する。
【０１７８】
当然ながら、本発明の原理は変わらず、実施形態の形式は単に非限定的な例として記述・図解されたものに関して各種の変更が可能であるが、これらは添付の特許請求の範囲により規定される本発明の保護範囲から逸脱するものではない。
【技術分野】
【０００１】
本発明は、通信ネットワークおよびサービスのうちの一方または双方の管理を目的とするプラットフォームにおけるリソース管理方法に関する。特に、本発明は、通信ネットワークおよびサービスのうちの一方または双方の管理用プラットフォームにおけるリソース割り当て方法および対応する管理プラットフォームに関する。
【背景技術】
【０００２】
通信ネットワーク／サービス分野において、階層的アーキテクチャで構成され、時としてエージェントを利用する動作支援システム（ＯＳＳ）等、複数の構成要素を含む管理用プラットフォームが提供されている。
【０００３】
例えば米国特許第６，２４３，３９６号明細書に、通信ネットワーク・リソースを制御する相互接続された管理局の多層階層アーキテクチャを有する通信ネットワーク管理システムまたはプラットフォームが開示されている。各々の局は、プロセスの実行に責任を負う多数のエージェントを有しており、これらは知的または単なる応答的エージェントであってよい。
【０００４】
公知のアーキテクチャにおいて、応答的エージェントは局のプラットフォーム部分に置かれ、知的エージェントは局の制御部分に置かれる。知的および応答的エージェントは、当該プラットフォームにＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）に機能を提供すべく機能構成要素に分類される。
【０００５】
国際公開第０１／０２９７３号パンフレットは、分散エージェントを調整するための集中型プロセス・コーディネータを含むプラットフォームの利用を教示しており、これは典型的には構成要素（エージェント）へのジョブの委譲、エージェントからの応答の収集等を含むワークフロー記述（フロー図と同様）を実行するワークフロー・エンジンにより実現される。
【特許文献１】米国特許第６，２４３，３９６号明細書
【特許文献２】国際公開第０１／０２９７３号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００６】
出願人は、上記のアーキテクチャでは、エージェントがワークフロー・エンジンにより委譲されたジョブを実行することが保障されないと考える。実際に、計算能力等、エージェントが利用できるＩＴリソースには限界があり、プラットフォームに求められる業務目標や作業負荷に合致するにはＩＴリソースが十分であるとは限らない。
【０００７】
換言すれば、エージェントが利用できるＩＴリソース如何により、例えば顧客へのサービス提供等、エージェントにより実行されるタスクを必要とする所定の業務目標の達成が妨げられる場合がある。
【０００８】
例えば、タスクとして、規定されたプロセスを所定の持続期間より短い平均時間で完了すること、または一定の期限内に所定数のプロセスを完了することが挙げられる。
【０００９】
エージェントにかかる膨大な作業負荷により、エージェントが所定の平均時間または定められた期限内にタスクを完了することができなくなり、従って業務目標が達成されない恐れがある。
【００１０】
集中型プロセス・コーディネータを用いるエージェントに基づくアーキテクチャの別の問題は、国際公開第０１／０２９７３号パンフレットに開示されているように、コーディネータ自体がプラットフォームの動作のボトルネックになる点であり、柔軟性を向上させるべくコーディネータにワークフローを加えるエージェントから外出しされたプロセスロジックが増えるほど、コーディネータが遅くなる。これにより、実行に期限を有するプロセス等、業務性能目標を達成するためのアーキテクチャの能力が低下する恐れがある。
【００１１】
ＩＴリソース管理分野において、米国特許出願公開第２００３／０１６７２７０号明細書に、スケーラブルなアプリケーションのコピーのインスタンス生成を行なうホスト機を含む分散環境におけるリソース管理システムが開示されている。当該リソース管理システムは、アプリケーションのコピーに関する情報およびホストの性能に基づいて、ホスト群をまたがってスケーラブルなアプリケーションの選択されたコピーを起動、停止、または移動させる信号を生成する。
【００１２】
この種のソリューションは、少なくとも以下の理由により、プロセス・コーディネータまたはワークフロー・エンジンにより調整される分散型エージェント・アーキテクチャを含むプラットフォームには適していない。
− 全てのエージェントが既にいくつかのタスクを実行している場合、緊急のタスクまたはアプリケーションを新たに実行するための空きエージェントが存在する余地がない。
− 新規ワークフロー（すなわち新たな機能）が規定される都度、業務目標（例：業務プロセスの期限）を実現すべく、既知のシステムはアプリケーションのパラメータを測定して、全てのエージェントの挙動を調整すべく新たなモデルを構築する必要がある。
− 既知のリソース管理システムは、複数のコピーにインスタンスが生成され得るアプリケーションまたは機能に対してのみ作用する。
【００１３】
本発明の目的は従って、通信サービスおよびネットワークのうちの一方または双方を管理するエージェント利用プラットフォームにおけるリソースを管理する方法を提供することであり、これにより所定の業務目標を達成すべくリソース使用状況における最適な性能を実現してプラットフォームの効率を向上させる。
【００１４】
本発明の他の目的は、プラットフォームの柔軟性を向上させながら性能向上を実現するために分散型プロセスロジックを有する管理プラットフォームである。
【００１５】
本発明によれば、これらの目的は、通信サービスおよびネットワークのうちの一方または双方を管理するプラットフォームにおけるリソース管理の方法により、かつ独立請求項に記述された特徴を有する管理プラットフォームにより実現される。
【００１６】
本発明のさらなる目的は、特許請求の範囲に記述されるように、通信管理プラットフォームの設定および運転を行なうコンピュータ・プログラム製品またはコンピュータ・プログラムの組、通信ネットワークおよび方法である。
【課題を解決するための手段】
【００１７】
要約すれば、従来技術の短所を克服すべく、本発明は、所定の指標（例：主要業務指標）および目標により駆動される、予測および適応型の機構に基づく方法および対応プラットフォームを開示するものであり、管理プラットフォームにおけるＩＴリソースの使用状況の測定および自動制御を行なう。
【００１８】
好適には、本発明によるプラットフォームのアーキテクチャの特徴は以下の通りである。
− エージェントが提供する全ての機能を実装するエージェント内部のプロセス（ワークフローおよびルール）エンジンを提供することにより、エージェントが実行しなければならないジョブがワークフローの実行となる。ルールエンジンは、特定種類のジョブを実行すべくワークフロー・エンジンに結合することができる。
− プロセス記述を定義および保存してこれらの記述をエージェントに分散するための集中型プロセス記述データベースの提供、
− 業務目標（例：ＳＬＡ、サービスレベル合意）および機能およびその集計（例：履行、保証、支払い請求等の業務プロセス領域への）の定義に基づく処理優先順位を含む目標データの指定を可能にする目標および制約コンソールの提供、
− プラットフォームの各エージェントにおける各々のプロセスの実行並びに業務プロセスによるワークフローの実行によるＩＴリソースの使用を監視、すなわち、例えば経過時間、実行頻度等を監視すべく構成された制御エージェントの提供、および、
− 業務目標を最大限に達成すべく、指定された目標データ（業務目標）およびリソースの使用状況を示す監視された性能データに基づいて、適応型の方法でプラットフォームの各エージェントにＩＴリソースを再割り当てすべく構成されたリソース割り当てモジュールの提供。
【００１９】
本発明の好適な実施形態によれば、リソースの再割り当てルールを規定すべくグラフィカル・ユーザー・インターフェースとしてリ−アロケータ・コンソールが提供されていると共に、監視コンソールが提供されていることにより、ＳＬＡの達成状況および対応ＩＴリソースの使用状況および関連コストの制御が可能になる点が好都合である。
【００２０】
エージェント内部にプロセス・エンジンを提供することが、全てのエンジンが集中型プロセス・コーディネータに置かれている場合にボトルネックを生じることなく柔軟性を向上させ、エージェント間でＩＴリソースを動的に割り当てる際に有利な特徴であることがわかる。エージェント内のプロセス・エンジンにより、各々の機能実行（すなわちプロセスの実行）に際してエージェント内でのリソース使用状況（例：使用されたＣＰＵ時間またはＲＡＭ）を分析的に測定することが可能になる。
【００２１】
集中型データベースにおけるプロセス記述は、プラットフォーム横断的に各エージェントへそれらのプロセス・エンジン内で利用すべく分散され、プラットフォームの全ての動作機能と自動的に同期化が行なわれるため、ジョブのセマンティクスと協働するリソースの管理プロシージャを調整することが可能である。
【００２２】
実際には、通信サービスおよびネットワークを管理するプラットフォームの管理者は、プロセス・データベース内で１個以上のワークフローおよびルールのうちの一方または双方を規定するかまたは既存のものの組み合わせる任意のＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）機能を構築することができ、次いで必要なときにエージェントが新規プロセス（ワークフローおよびルール）の定義を自動的に取得して実行することができる。自動的に、目標コンソールが新規プロセスに対するＳＬＡおよび優先順位の規定を可能にする。実行時に、制御エージェントは、新規プロセスのＳＬＡ傾向および対応ＩＴリソースの使用状況の制御を可能にして、リ−アロケータ・モジュールが全体構成を最適化できるように、すなわちエージェントにおけるワークフロー優先順位を変更するか、またはより多くの計算リソース（ＣＰＵ、メモリ等）を与える。
【００２３】
本発明によるリソース管理は好適には、分散されたモジュール（制御エージェント）と共に、集中型モジュール（マネージャ・モジュール）によりプラットフォーム内で実装される。集中および分散機能の組合せは、ソリューションの適応型機構の基礎となる。
【００２４】
本発明のさらなる特徴および利点を、添付図面に関して非限定的な例を用いて以下の記述においてさらに詳しく説明する。
【図面の簡単な説明】
【００２５】
【図１】本発明による通信ネットワークおよびサービスの管理システムまたはプラットフォームのアーキテクチャを示すブロック図である。
【図２】図１のマネージャ・モジュールの内部アーキテクチャを示すブロック図である。
【図３】エージェント・モジュールおよび制御エージェントと共に、図１のホスト機の内部アーキテクチャを示すブロック図である。
【図４】別の実施形態によるエージェント・モジュールの内部アーキテクチャを示すブロック図である。
【図５】本発明によるリソース管理方法のフロー図である。
【図６】本発明によるシステムを含む３層サービスプロビジョニングシナリオの模式図である。
【図７】図６のサービスプロビジョニングシナリオにおける多レベル・ワークフローを示す図である。
【発明を実施するための形態】
【００２６】
図１に、本発明による通信サービスおよびネットワーク管理システムの例証的なアーキテクチャを示す。本システムは好適には、各々が１個以上のソフトウェア・エージェント（Ａ１、Ａ２、Ａ３）を含み得る複数のプロセスホスト機Ｈを含む分散プロセスアーキテクチャに実装されている。
【００２７】
本システム（またはプラットフォーム）は、ホスト機上で動作してプロセス記述の分散、動作の起動、管理統制等、各種の協調動作のために分散エージェントと対話するプログラムまたはプログラムの組を含む集中型制御モジュールまたはマネージャ・モジュールＭＭを含んでいる。マネージャ・モジュールＭＭはまた、好適にはシステム管理者等のユーザーと対話するためのグラフィカル・ユーザー・インタフェースを含んでいてよい。
【００２８】
本明細書において、プロセスという用語は、１個以上のワークフロー、１個以上のルールまたは、好適には１個以上のワークフローと１個以上のルールの組合せを表すために用いられる。
【００２９】
ワークフローは、手続きのルールの組に従い、実行中にあるエージェントから別のエージェントへ情報またはタスクが渡される業務プロシージャの自動化されたものとして規定することができる。
【００３０】
ワークフローは、一連のタスク並びに代替的なまたは並列分枝を含むタスク間の時間的かつ論理的依存関係を有するフロー図を介して表すことができる。ワークフロー記述を定式化するＸＰＤＬ（ＸＭＬプロセス記述言語）等の特殊言語が存在する。これらのルールは特定の組の条件／イベントが発生した際に実行すべきアクションの宣言である。
【００３１】
マネージャ・モジュールＭＭは、全てのプロセス、すなわちプラットフォームの挙動および機能的態様を表すワークフローおよびルールを保存すべく構成されたプロセス記述データベースＰＤＢを含んでいる。
【００３２】
データベースＰＤＢはさらに、例えば、ワークフローおよびルールにより扱われるデータ・モデルを含んでいる。
【００３３】
当業者には知られているように、プロセス記述データベースＰＤＢは例えば、任意の従来型ネットワーク在庫管理システムのカタログ部分に関連付けられてよい。
【００３４】
図１のアーキテクチャは、多層エージェント・モジュール、例えば各々がいくつかのエージェントＡ１、Ａ２、Ａ３を含む３層を含んでいる。同一レベルに属しているエージェントは相互に接続していても、または互いに独立していてもよい。これらは、より高いレベルのエージェントがあれば、これに結合されている。より低いレベルにおいて、エージェントは、制御下にあるネットワーク要素（一般に通信ネットワークＮとして示す）、例えばＡＴＭスイッチ、あるいはメールサーバー・アプリケーションまたはＶＡＳサーバー・アプリケーション等の他のサービス・アプリケーションＡＰＰ、すなわち携帯電話の留守番電話サービス等の付加価値サービス・アプリケーションに結合されている。
【００３５】
マネージャ・モジュールＭＭは、例えば、通信バスＢを介してプラットフォームの他の動作支持システムＯＳＳに接続されている。
【００３６】
コーディネータとして機能しているマスター・エージェントＭＡ、あるいは実装方式の種類に応じて複数のマスター・エージェント群ＭＡ（図１に開示せず）が、マネージャ・モジュールＭＭに関連付けられた多層エージェント・アーキテクチャのルートに提供されている。
【００３７】
各エージェントＡ１、Ａ２、Ａ３は、プロセス・エンジンＰＥを含んでいて、プロセス・エンジンＰＥを用いるいくつかのプロセスの実行責任を負う。
【００３８】
プロセス・エンジンは、ワークフローおよびルールのうちの一方または双方を実行するソフトウェア・モジュールである。プロセス・エンジンの外部設置は性能低下を引き起こし得る遠隔起動を有することを意味するため、プロセス・エンジンＰＥは各エージェント内に埋め込まれていることが好都合である。
【００３９】
好適には、各エージェントのプロセスは、同レベルまたはより高いレベルを有する他のエージェントにより、外部から起動することができ、各エージェントが起動エージェントに提供するサービスに対応している。
【００４０】
任意の層におけるプロセス・エンジンは、例えば、ワークフローと、ワークフローおよびルールの各々を管理可能なルールエンジンの組合せであることを意図されている。例えば、プロビジョニングプロセスはワークフローとして表す方が適している一方、アラームコリレーションはルールの組合せとして表す方が適している。可能ならば、ワークフローを利用する方が、ルールの矛盾およびルールの管理を取扱う煩雑さが含まれないため好ましい。
【００４１】
図１に示す多層アーキテクチャは、異なるレベルでのプロセスの分割を可能にする。エージェントが配置可能であるレベルの数に制約がない。このように、可能な限り層の数を少なくすることと、分散型組織と集中型組織との間で自由にプロセスの割り当てを許すことのトレードオフを見つけるべくアーキテクチャを設定することが可能である。この分割はまた、業務ビューからシステム・ビューまで、異なるサービス・ビューを提供することも可能にする。
【００４２】
以下において、ワークフロー・エンジンが好ましいと思われるが、ルールエンジンもまた適用可能である。
【００４３】
エージェント（マスター・エージェントおよびサブレベル・エージェントの両方）を実行している各ホスト機は好適には、１個以上の制御エージェントＣＡを含んでいる。これらは、ローカル・エージェント（すなわち当該ホストで動作しているエージェント）のリソース使用状況および性能の測定、並びにリソース管理の局所最適化の実行に責任を負うモジュールである。制御エージェントＣＡは、マネージャ・モジュールおよび他の制御エージェントに結合されていて、測定されたデータをマネージャ・モジュールおよび他の制御エージェントのうちの一方または双方へ送信する。
【００４４】
以下にその構造を記述するマネージャ・モジュールＭＭは、プラットフォームの管理、構成、および制御に責任を負う。人間オペレータおよび外部ＯＳＳからの入力データを解析して、業績目標を満たすようにプラットフォームの構成を如何に調整するかを決定すべく構成されている。その主なタスクは以下の通りである。
プロセス記述およびデータ・モデルをプロセス・データベース（ＰＤＢ）からエージェントへ分散する、
制御エージェントから提供された情報を用いて、ホスト機上でのエージェントの分散、ドメイン管理（ネットワーク全体をエージェントに分割）、性能監視を含むプラットフォームの状態を監視する、
関連する制御エージェントとの対話を介してエージェントによるプロセスの実行用に割り当てられたリソースを最適に使用すべくアクションを実行する（これらのアクションの例として、エージェント間の負荷バランシングの変更およびワークフローの優先順位の変更、すなわち１個以上のエージェント内の待ち行列ジョブの再スケジューリングがある）、
他の動作支援システムと同様、外部システムとの対話。
【００４５】
以下にその構造を記述するマスター・エージェントＭＡは、プロセスの実行の最上位レベル調整の責任を負う。実際には、最上位層のエージェントに課せられたプロセスには、サブ層エージェントに課せられたサブプロセスが含まれていてよい。さらに、（エージェント以外の）外部エンティティとの対話または下位層エージェントにより分散的には容易にまたは効率的に実行することができないエージェント同士の調整を必要とする機能を提供すべく特徴付けられたプロセスが存在する。エージェントにより実行されるプロセスは、分散的に実行する必要があるものである。
【００４６】
各エージェント（Ａ１、Ａ２、Ａ３）は、任意のＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）機能等、任意のネットワークもおよびサービス管理機能（すなわちプロセス）を支援することができる。これにより、例えば、日中はサービスプロビジョニングにより多くのエージェントを投入し、夜間はネットワークの最適化により多くのエージェントを投入する等、タスクの優先順位およびリソースへのニーズに基づいてエージェントの実行時にタスクのカスタマイズおよびエージェントへの機能の再割り当てが可能になる。
【００４７】
エージェントにプロセス・エンジンＰＥの提供することにより、各機能（すなわちプロセス）によるリソースの使用状況並びに機能の起動生起を監視することが可能になる。これらのデータは、マネージャ・モジュールＭＭにより制御される自動プラットフォーム制御の主な情報源である。
【００４８】
各エージェント（Ａ１、Ａ２、Ａ３）は応答的および能動的な挙動の両方を示し、イベントにより生起されるだけでなく、プロセスを自発的に起動させる。
【００４９】
好適には、エージェント・モジュールは、例えばフォールト・トレランス問題に対応すべく配備が容易になるように制御エージェントまたはマネージャ・モジュールにより処理装置間を移動可能である。
【００５０】
図２に、本発明の好適な実施形態によるマネージャ・モジュールＭＭの内部構造を示す。
【００５１】
集中型マネージャ・モジュールＭＭは、例えばサブモジュールに編成されている。
【００５２】
サブモジュールのうち１個はＭＮＧ_ＣＮＳコンソールであり、一般に、管理コンソールＭＮＧ_ＣＮＳとして示される。好適な実施形態において、管理コンソールＭＮＧ_ＣＮＳは、以下のものを含んでいる。
− プラットフォーム性能データを保持している性能データベースＰＦＭ_ＤＢに関連付けられた監視コンソールＭＣ、
− 目標および制約コンソールＧＣ、
− リ−アロケータ・コンソールＲＣ、
− 管理用コンソールにより管理される管理データを含む管理データベースＡＤＢが関連付けられている管理用コンソールＡＣ、
− サービス生成環境コンソールＳＣＣ
並びに
− 容量計画モジュール（図示せず）、
− 予測コンソール（図示せず）。
【００５３】
目標コンソールＧＣ、管理用コンソールＡＣおよびサービス生成コンソールＳＣＣは全て、プロセス記述データベースＰＤＢに結合されている。
【００５４】
マネージャ・モジュールＭＭは、目標および制約コンソールＧＣおよびリ−アロケータ・コンソールＲＣに直接結合されたリソース割り当てＲＡを含んでいる。
【００５５】
リソース割り当てＲＡはまた、例えば管理用データベースＡＤＢ、並びにプラットフォーム性能データを保持している性能データベースＰＦＭ_ＤＢに結合されている。
【００５６】
好適な実施形態において、マネージャ・モジュールＭＭはさらに、監視データ取得モジュールＭＤＭおよびプラットフォーム・コントローラＰＣを含んでいる。
【００５７】
監視データ取得モジュールＭＤＭは、プラットフォーム・コントローラＰＣから性能データベースＰＦＭ_ＤＢへ性能データを転送すべく構成されている。
【００５８】
さらに、リソース割り当ては、例えば、外部ＯＳＳと管理プラットフォームとの間の対話を監視する外部インタフェース・モジュールＩに結合されていてよい。
【００５９】
プラットフォーム・コントローラＰＣは、一般に、マネージャ・モジュールとエージェントとの間のメディエーターとして動作する。
【００６０】
特に、プラットフォーム・コントローラＰＣは、マネージャ・モジュールの外部にあるマスター・エージェントＭＡ（図示せず）、およびリソース割り当てモジュールＲＡとの接続を実装し、監視コンソールＭＣ、監視データ取得モジュールＭＤＭ、管理用コンソールＡＣおよび管理用データベースＡＤＢ、並びにプロセス記述データベースＰＤＢに結合されている。
【００６１】
目標および制約コンソールＧＣは、プロセス記述データベースＰＤＢに保存されているプロセスに関連付けられていて、合わせて目標データと呼ばれる業務目標（例：サービスレベル合意すなわちＳＬＡ）および制約の規定を意図としている。
【００６２】
サービスレベル合意すなわちＳＬＡは、業務プロセス・レベル品質の（契約締結または単に同意された）定量化である。ＳＬＡは、性能指標（平均実行時間、パーセンタイル値等）に基づいており、これらの指標の値がプラットフォームで保証される旨を宣言する。一般に、ＳＬＡはＳＬＡ目標（性能指標）およびＳＬＡ違約条項（ＳＬＡ目標と収集された性能データとの比較に基づくＳＬＡコスト関数）、例えばＳＬＡ違反の経済的違約の見積、を識別する特定の言語（「文法」）により記述することができる。
【００６３】
ＳＬＡは一般的な業務プロセス（例：ワークフロー）または（１個以上のワークフロー属性において定義可能な）その特化されたものの１個に関連付けることができ、その場合、特化されたものに対するＳＬＡは通常、ルート業務プロセスのＳＬＡを上書きする。
【００６４】
制約は、リソース使用状況に関するデータに注目する。これらは、好適には以下のものを含んでいる。
− 保証すべき最低スループット、管理可能な最小数のネットワーク要素（より理解し易い業務測定基準を用いるために、パーセンテージではなく「スループット」という用語を用いるのが好適である）で表される、予め割り当られたリソース、
− 割り当て可能なリソースの最大数（大域的リソースのコストまたはパーセンテージで表され、デフォルト値は例えば５０％）。
業務制約を変更する際に、予め割り当られたリソースが割り当て可能な最大容量を上回るか否かを検証することが必要である。
【００６５】
本発明の好適な実施形態によるリソース・アロケータＲＡ（以下、リ−アロケータと呼ぶ）は集中型であって、プラットフォームを適応的に制御すべくエージェントへのリソース割り当てを管理する。これは、例えば以下を受容すべく構成されている。
ｉ） 目標コンソールＧＣからの業務目標。
ｉｉ） 全てのホスト機の性能データ（実行時間等）およびハードウェア・リソース使用状況を監視して、これらのデータを性能データベースＰＦＭ_ＤＢから取得する。
ｉｉｉ） オプションとして、負荷テストから得た情報、すなわちワークフローをより多く使用した場合のリソース使用状況に関する測定値。
ｉｖ） 利用可能なホスト機およびそれらのハードウェア特性（正規化されたＣＰＵ速度、例えば標準性能評価協会によるＳＰＥＣＩＮＴ２０００レートを用いたもの）に関するデータ。これは、全体的な処理能力（例えば基準ＣＰＵの１時間当たり秒数で測定）を監視する。
ｖ） 全てのホスト機のハードウェア・リソース使用状況（性能データベースＰＦＭ_ＤＢから）。
【００６６】
リ−アロケータＲＡは好適には、評価モジュールおよび決定モジュールの２個のサブモジュールを含んでいて、本明細書の以下にその例証的な記述および機能を述べる。
評価モジュールは、
− 最上位レベル（ＭＡ）ワークフロー実行要求、および
− 全てのエージェント内のワークフロー実行要求待ち行列
に関するデータを受信すべく構成されている。
【００６７】
さらに、評価モジュールは、過去のワークフロー実行要求の履歴的傾向および要素および複雑度に関する管理された通信ネットワークの傾向を分析すべく構成されている。
【００６８】
決定モジュールは、過去情報に基づいて、プラットフォームが後述するいくつかの基準に従い全ての要求に対応可能か否かを決定すべく構成されている。
【００６９】
プラットフォームが全ての要求を管理することが不可能な場合、決定モジュールは、例えば警告メッセージを送信、どのアクションが状況を改善できるかを決定すべく構成されている。
【００７０】
特に、リソースは十分あるが、ＳＬＡが完全に満足されていない場合、決定モジュールは処理（すなわちワークフロー実行）をプラットフォーム全体にわたり再配分させるべく構成されている。好適には、これらのアクションは、ワークフローの異なるインスタンスに関連付けられた制約および優先順位を考慮している。
【００７１】
管理用コンソールＡＣは、例えば、少なくとも以下のうち一組を定義および監視することを意図している。
ｉ） プラットフォーム、すなわち分散エージェントによるプロセスの実行の処理能力を保持するホストＨのハードウェア構成。例えば、新規のホスト機が所定のホスト群に追加された際に、自動的にプラットフォーム全体に結合される。これは、例えば、ホストが自身の存在を通知するか、または、管理用コンソールが例えばＧＵＩを介してオペレータにより入力されたコマンドを受信することによりホストＨを認識するためである。
ｉｉ） ソフトウェア分散／割り当てを規定するためのＧＵＩ（すなわち目標および制約コンソールＧＣにおける制約に関するデータを受信するインタフェース）。
特に、これを用いて、ホスト機群を例えば以下に基づいて設定する。
− 地理的制約（例えば、特定のワークフローは、ある領域にインストールされているが別の領域にはインストールされていないエージェントだけで実行することができ、あるいは、特定のホスト機だけで実行することができる）、
− 階層的制約（例えば、特定のマシンでは第２レベルのワークフローのみ動作可能である）。
− 業務制約（すなわち、特定の種類のプロセスに対する制約）。
ｉｉｉ） ワークフロー・スケジュール（例えば、サービスプロビジョニングワークフローは朝の時間帯にのみスケジュールされる）。
【００７２】
リ−アロケータ・コンソールＲＣは、リソース再割り当てポリシ、すなわち、業務制約および監視されたデータに基づいて業務目標の満足度を最適化すべくリソースをいつ、どのように再割り当てするか、の命令を規定すべく構成されている。リ−アロケータ・コンソールでは、集中型および分散型制御の両方のポリシを入力することができる。特に、以下の定義が可能である。
ｉ） 最高レベルのＳＬＡ満足度に達すべく、いつ、どのようにワークフロー優先順位に作用すべきかを規定する、集中制御用のルール。これらのルールは、管理されたプラットフォームを全体として見て（すなわち、マシンに対して直接的には作用しない）、リソース割り当てモジュールの全ての入力データおよび予測的データに基づいて作用する。
ｉｉ） ローカル・ソフトウェアおよびハードウェアのリソースの使用状況を最適化する目的で、関連ＣＡ（スレッド並列度およびロード・バランシング）を通じて単一エージェントに作用する、分散制御用のルール。
ｉｉｉ） ルールに関する複雑な式を計算する機能。
【００７３】
監視コンソールＭＣは、以下のような監視情報を閲覧すべく構成されている。
ｉ） 定時（例：１日当たり）平均スループット、待ち行列（例：１日当たり）の要求数、平均実行時間（例：１日当たり）、目標が設定された全ての業務トランザクションの期限。
ｉｉ） 合意されたＳＬＡ指標の測定値間の差違に関する、サンプリング期間にわたり計算されたＳＬＡの状況（違反したものは強調表示）、および関連コスト関数の評価。
ｉｉｉ） 全てのワークフローにおけるハードウェア・リソースの使用状況、例えば秒単位でのＣＰＵ使用量および使用ＲＡＭのうちの一方または双方（単一レベルおよびそれを下回る全てのレベルについて）。これは、全てのホスト機が他とは計算能力が異なるため、ハードウェア・リソースの使用状況、例えばＣＰＵ使用量、は基準ＣＰＵに正規化される。
ｉｖ） アカウント情報。全てのワークフローにおいて使用されたリソース（合計に対するパーセンテージ、およびコストに関して）。
【００７４】
監視コンソールＭＣにより、階層的に、ワークフロー（特に、ワークフローの全てのブロック）の性能およびリソース使用状況を閲覧することが可能になる。全てのＳＬＡについて、リソースの使用が多いために、最適化する価値があるワークフローについてレポートを提出することが可能である。ワークフローの異なるレベルに他の測定点が設定された場合、それらはＭＣにも提示される。また、ＭＣは、ワークフローにより使用されたリソースに関して、支払い請求に関する情報を表示する。
【００７５】
サービス生成環境コンソールＳＣＣは、ＰＤＢにおけるプロセス、すなわち管理プラットフォームにおいて提供される全ての業務機能を定義、生成、および変更すべく構成されている。これは、本タスクの実施を容易にすべく、グラフィック・インタフェースに基づいている。本コンソールもまた、ワークフローに新規の監視点を挿入可能にしている。
【００７６】
さらなる実施形態において、ＭＭモジュールにより管理されるデータはまた、ＭＭモジュールに予測コンソールおよび容量計画モジュールを追加することにより、有用な容量計画を実現するために用いられる。
【００７７】
予測コンソールは、有用な容量計画活動を実現するための使用状況予測を設定すべく構成されている。本コンソールの入力は以下の通りである。
ｉ） 期待スループット、および
ｉｉ） ネットワーク・ホストの期待個数および種類（この数値は、プロセス記述データベースにおけるデータの予測として計算することもできる）。
【００７８】
容量計画モジュールは、時間経過に伴いハードウェア・リソースを保証すべく構成されている。これは、予測コンソールおよび他のコンソール（目標および制約コンソール、管理用コンソールおよびリ−アロケータ・コンソール））から入力を受信して、リソースの可用性を確認すべく構成されている。
【００７９】
リソースが十分でない場合、容量計画モジュールは、予想される増加傾向に対処するために必要なハードウェアの量について、コンソールのオペレータに警告すべく構成されている。本モジュールは、以下のうち少なくとも１個を含む一組のパラメータに基づいて分析を行う。
ｉ） 期待スループット（履歴傾向に関して）、
ｉｉ） 全てのワークフロー（特に第一レベルのワークフロー）のリソース使用状況の情報、
ｉｉｉ） 地理的制約。
【００８０】
容量計画モジュールは不確実なデータ（特に長期データ）に基づいているため、主に通知目的で構成されている。将来のニーズを強調することができるが、好適には割り当てＲＡと対話することはない。
【００８１】
図３に、ホストの全体的な性能および当該ホストで動作する全てのエージェントの制御に責任を負うエージェント・モジュールＡおよび制御エージェントＣＡを含むホスト機の内部構造の例を示す。
【００８２】
各エージェントＡは、以下の構成要素のうち少なくとも一組を含んでいる。
− ワークフロー待ち行列または待ち行列ＷＦＱ。これは、各々の下位待ち行列が同一優先順位の要求を保持している多レベルの優先順位待ち行列である。エージェントへ送信された各々のワークフロー要求は、自身の優先順位に基づいて対応する下位待ち行列に挿入される。図３において、異なるワークフローをＷＦ１、．．．、ＷＦｎで示す。下位待ち行列内でワークフロー要求の欠乏を避けるため、待ち行列ＷＦＱは、例えばタイムアウト基準に基づいて、下位待ち行列内の要求について優先順位の更新を実施する。
【００８３】
待ち行列ＷＦＱ上の情報、特に以下のものが待ち行列ＷＦＱに関連付けられている。
【００８４】
各種のワークフローについて測定されたワークフローのＣＰＵ消費時間（これらのデータはＰＦＭ_ＤＢから取得された）を加算して計算された推定ＣＰＵ消費時間、
特定種類のワークフローが他のエージェントにより実行されることを要求される速度（例：ワークフロー／時間）（要求はエージェント内の待ち行列に入れられる）を統計的に推定する、要求入力速度、
− ワークフロー待ち行列ＷＦＱに関連付けられたワークフロー・スケジューラＷＦＳ。これは、待ち行列に含まれるワークフローＷＦｎをそれらの優先順位に基づいてスケジューリングすべく構成されている。エージェントの１個以上のプロセス・エンジンがワークフローを実行する準備ができる都度、スケジューラは、待機中のプロセス・エンジン・スレッドの１個へ待ち行列内でより高い優先順位のワークフローを送信する。
− ワークフロー・スケジューラＷＦＳにより制御される複数のプロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎ。全てのエージェントは、設定可能な個数のワークフローを同時に実行することが可能である。これは、エージェント内で複数のプロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎ（独立エグゼキュータ）を設定することにより実現される。各プロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎは、同時に１個のワークフロー、例えばＪａｖａ言語で実装されたスレッド、を実行することが可能である。
【００８５】
制御エージェントＣＡは、好適にはソフトウェアで実装された以下の構成要素の少なくとも一組を含んでいる。
− リソース・モニタＲＭ：本構成要素は、自身の制御下にあるエージェントにおけるハードウェアおよびソフトウェアのリソース使用状況に関するデータを監視および収集すべく構成されている。
【００８６】
その役割は、ホスト上でのエージェント（エージェントホスト）を含む現在のリソース使用状況およびワークフローの実行によるＣＰＵとメモリ消費の両方を測定することである。測定された値は、マネージャ・モジュールＭＭおよびスレッド・コントローラＴＣへ送信される。
− スレッド・コントローラＴＣ。これは、リソース・モニタＲＭおよびワークフロー待ち行列ＷＦＱに結合されていて、局所性能を制御すべく構成されている。これは、能動的にエージェント・スレッドの並列性を管理すること意図している。これは、入力として、待ち行列内で実行待ちであるワークフローの個数、実行中のマシンのＰＥスレッドのＣＰＵ使用量およびＰＥの総数を受信すべく構成されている。上記の入力に基づいて、スレッド・コントローラＴＣは、最適なワークフロー実行並列性を実現すべくプロセス・エンジン・スレッド（ＰＥスレッド）の個数を増減させる。これは、例えば、実行待ちであるワークフローを待ち行列が含んでいる場合、ＰＥスレッドの総数が許容された最大個数を下回る場合、かつＣＰＵ使用量が指定された閾値を下回る場合に、新規のＰＥスレッドを生成する。しかし、エージェントが、外部リソース（装置、ネットワーク機器等）との直接対話を担当している場合、ＰＥスレッドの許容最大個数は外部リソースの許容可能な並列性により制限される。さらに、いくつかのＰＥスレッドが所定の期間使用されていないことがわかった場合、スレッド・コントローラはＰＥスレッドのガーベージ・コレクタを実行する。
− プロセス・エンジン・スレッドに結合されたディスパッチャＤ。本構成要素は、他のエージェントへワークフロー実行要求を送信すべく構成されている。各ＰＥスレッドはディスパッチャＤを用いてそのような要求を送信する。
【００８７】
ディスパッチャは、例えば、以下のようにロード・バランシング・アルゴリズムを用いて、他のエージェントへ要求を送信する。これは、要求を送信するための最適なエージェントを、２段階で選択する。
【００８８】
第一に、ＣＰＵおよびメモリの観点から負荷がより少ないホストを選択する。第二に、エージェント待ち行列の推定ＣＰＵ消費時間の最小量に基づいて選択されたホストの利用可能なエージェントを選択する。
【００８９】
制御エージェントＣＡは、好適には自身の側に、好適な実施形態による重要な特徴を有している。これらは、自身のプロセス・スレッドの並列性を能動的に管理する（局所最適化）ことが可能である。待ち行列の再順序付けおよび並列性管理の二つの能力が合わさって、本発明の一態様による適応型機構の基礎をなす。
【００９０】
図４に示す本発明の別の実施形態によれば、例えば、ホスト機Ｈ上に単一のエージェント・モジュールＡが存在するならば、リソース・モニタＲＭ、スレッド・コントローラＴＣ、および、ディスパッチャＤをエージェント・モジュールに付加することができる。
【００９１】
本発明のシステムの好適な実施形態は、移動特性を有するエージェントを実装するＪＡＤＥ（Ｊａｖａエージェント開発フレームワーク）、プロセス定義を行なうＸＰＤＬ（ＸＭＬプロセス定義言語）、およびＳｈａｒｋなどのＸＰＤＬワークフロー・エンジンを使用して実装される。
【００９２】
以下に、動作を示す図と共に、リソース割り当てモジュールについてより詳細に記述する。
【００９３】
リ−アロケータＲＡは、制約プロセス、データ操作、および設定変更の機能を有するエキスパート・ルールベース・システムとして実装することができる。管理されたネットワーク、外部システム、人間の知識、および内部分析から得られた全てのデータ、制約、およびルールがその知識ベースを構成しており、これを関連する知識データベースにより具体的に表現することができる。
【００９４】
リ−アロケータ・モジュールＲＡは、シナリオの状況に応じてケース毎に設定可能な所定の分析期間で評価および決定モジュールを実行する。
【００９５】
第一に、リ−アロケータは、後続する期間のために予測されたサービス／機能要求の個数を評価すべくバスＢを介してプロセス要求に関するデータを外部システムから取得し、この情報を関連する知識データベースに保存する。
【００９６】
次いで、決定モジュールは、所定の業務目標を最適な仕方で達成すべく実行されるアクションを見出すためにリソース再割り当てルールを有効化する。
【００９７】
詳細には、各々の期間Ｔで、リソース割り当てモジュールは、履歴情報に基づいて、待ち行列に入れられた要求の個数および予測された要求の個数を考慮する。当該モジュールは、利用可能なハードウェア・リソース（主にＣＰＵとＲＡＭ）の量の第一の評価を実行する。これらのデータは、後述する「バックグラウンド・エラー訂正」を考慮しつつ、当該期間の終わりで実際に測定されたデータを使用して調整される。
【００９８】
以下のデータが統計方法で集められる。
− 各々のワークフローについて各々のレベルにおけるＣＰＵニーズ、および
− 下位ワークフロー要求の観点での最上位レベルのワークフローの合成（アーキテクチャの全てのレベルに関連付けられたＣＰＵニーズがあれば、この情報はまた、地理的制約があればこれを考慮しなければならない）。
【００９９】
収集された情報は、時刻ｔにおける待ち行列の長さと内容、および期間[ｔ，ｔ＋Ｔ]の間に（予想により）期待される要求の個数に相関付けられて、後続する期間の組または複数の期間の後に置かれた期間の組として意図される後続期間におけるＣＰＵ能力の合計必要量を計算する。
【０１００】
次いでＣＰＵの総量、すなわち新たな期間（レベルおよび地理的制約を考慮して）に対して要求される計算能力が、利用可能なＣＰＵ能力と比較される。これが十分でない場合、コンソールに警告（新規ハードウェアを要求する）が生成されて、ワークフローの優先順位により負荷をどのように扱うかが決定される。
【０１０１】
利用可能なハードウェア・リソースに関するデータを調整するために「バックグラウンド・エラー訂正」が考慮される場合、各期間毎に全てのワークフローについて、かつ全てのホスト機について、先行期間で使用されたＣＰＵの量が、異なるワークフローにより使用されたＣＰＵの量と比較される。この値を用いて、後続期間でのＣＰＵの実際の利用可能性を「修正する」ために用いる。
【０１０２】
本発明による方法およびシステムでは、優先順位に基づくポリシを使用することにより、異なるレベルの優先順位がある。各期間Ｔ毎に、決定モジュールは管理アルゴリズムに従い、業務目標を達成すべく優先順位付き待ち行列を操作することができる。欠乏を避けるために、ワークフロー要求が優先順位の低い待ち行列で過大な時間を消費した場合、その優先順位が自動的に更新されて、より高い優先順位付き待ち行列へ要求が移動されるようにする。
【０１０３】
本発明の好適な実施形態によれば、管理アルゴリズムは、ステップ毎にリソース設定を改良して、漸進的な挙動により最適設定に到達しようとする適応型ソリューションに基づいている。現行アプローチの結果は、平均的なワークフロー実行時間の少なくとも２〜３倍（合理的な期間は、アプリケーションの状況に応じて５分〜１時間以上の範囲で変動し得る）である分析の期間を用いて保証される。
【０１０４】
優先順位は、以下を考慮しつつ、ワークフローの全ての実行に関連付けられている。
− 同意されたＳＬＡ（リスクの大きいワークフローほど、高い重みを維持する）の状況、
− ワークフローの目標コンソールにおいて規定された初期優先順位、並びに各ＳＬＡの優先順位および経済的意味、
− ワークフロー用の予め割り当られた最小限のリソース量、
− 割り当て可能なリソース最大量（ＳＬＡの初期交渉の間に規定される）。
【０１０５】
これは、優先順位が時間依存であることを意味する。ワークフロー性能のインスタンスがＳＬＡに近づいている（すなわち、性能が低下している）場合、その優先順位がより高く設定される。
【０１０６】
プロセス・エンジンの代わりに、例えば統計技法によるＣＰＵ評価等、機能の実行を定義および測定する任意の手段を用いてもよい。
【０１０７】
以下において、提唱されたアーキテクチャに基づく性能適合シナリオの例を示す。最適化すべきリソースはＣＰＵ負荷である。
【０１０８】
現行シナリオによれば、最上位レベルのワークフローは、時間ｔ＞＞ΔＴ（ΔＴは観測期間）内に完了されるワークフローのパーセンテージで表現された優先順位特性により特徴付けられるＳＬＡが関連付けられた業務である。最後の仮定は、プラットフォームに対し期間ｔ内に再調整するのに十分な時間を与えるために必要である。
【０１０９】
最上位レベルのワークフローは、多くの下位ワークフローから構成されている。全てのワークフローは、実行前の待ち行列内での待ち時間およびワークフローＣＰＵ時間スライスに影響を及ぼす優先順位特性を有している。
【０１１０】
入力データは以下の通りである。
− 各ワークフローおよび各ホスト機のＣＰＵ負荷[秒]、
− 制約、すなわち同一ワークフローはホスト機郡の一部だけで実行可能である、
− 下位ワークフローの観点からの第一レベルのワークフロー構成、
− 過去のΔＴ期間におけるワークフロー到着数、
− 過去のΔＴ期間におけるワークフロー実行回数。
【０１１１】
目標は以下の通りである。
− 次のΔＴ期間で全てのワークフローを実行するのに計算リソースが十分であるか否かを予測する、
− 計算リソースがＳＬＡを遵守するのに十分であるか否かを予測する、
− ワークフローの実行優先順位がＳＬＡの遵守に到達するための適合。
【０１１２】
性能適合プロセスは、全てのΔＴ期間で実行された監視に基づいており、最短プラットフォーム適合時間を表す。
【０１１３】
図５のフロー図を参照するに、全てのΔＴ期間で実行された監視の例をレポートしており、割り当てＲＡにより各ΔＴについて以下のステップが管理される。
１） 各ホストでの各ワークフローのＣＰＵ負荷の評価（ステップ１００）。これは、ホスト・サンプル上でワークフローの負荷試験を実施して、ＣＰＵドキュメンテーションを用いることにより達成される（先験的予測）。得られた値は、ワークフロー実行に対する制約を考慮しつつ、先行ΔＴで実行された各ワークフローに関連付けられた実際のＣＰＵ時間を使用して微調整することができる、
２） 未だ待ち行列で待機しているワークフローに加え次のΔＴ内に到着が予想されるワークフローを実行するために必要なＣＰＵ時間の予測（ステップ１２０）、
３） 計算リソースの観点から必須であるホスト群を識別すべく、ステップ１２０で評価されたＣＰＵ時間を、利用可能なＣＰＵ時間と比較（ステップ１４０）して、影響を受けるＳＬＡに第一ワークフローを関連付ける。必要とされるＣＰＵリソースが利用可能なＣＰＵリソースより大きい場合、ＣＰＵリソース不足を通知する（ステップ１５０）、
４） 各ＳＬＡについて、ＳＬＡ要求を満たす最小数のワークフローを実行するために必要なＣＰＵ時間を予想（ステップ１６０）し、次いでこれを利用可能なＣＰＵ時間と比較（ステップ１７０）して、ＳＬＡを遵守するために計算リソースが十分か否か判定する、
５） 上のステップにおいて、ワークフローを実行する現行のプラットフォーム優先順位設定がＳＬＡ制約に対応できないとされた場合、（計算リソースの観点からワークフロー重みを考慮しつつ）ワークフロー優先順位のバランスを見直して、ワークフロー優先順位の適合手法（ステップ１８０）を通じて設定を調整しなければならない、
６） 優先順位の適合が必要でない場合、または、優先順位適合が実施された場合、システムは性能適合プロセスを終了させ、次のΔＴ監視期間を待つ。
【０１１４】
性能適合プロセスの予測手法の例を以下に詳述する。以下の定義を行なう。
− ΔＴ：監視期間および最短システム適合時間、
− ＬＷｆ（ｎ）：ホストｎ上でのワークフローｗｆの実行に要するＣＰＵ負荷[秒]。これらの値は、先験的に（または、自動学習方式を用いて）推定し、次いでプラットフォーム動作の間に調整することができる。例えば、ある時間にわたる移動平均による。
− ＶＷｆ（ｎ）：ホストｎ上のワークフローｗｆに対する制約であって、次式で与えられる。
【０１１５】
【数１】
【０１１６】
次のΔＴ内に予見される全てのワークフローを実行するために必要な予想ＣＰＵ時間は次式で計算される。
【０１１７】
【数２】
【０１１８】
ここで、
ｇは、集合ＷＦ（ｇ）内の全てのワークフローについて同等なホストのグループである。これは、集合ＷＦ（ｇ）に属する各ワークフローが、グループｇの中の１個のホストにより同じ確率で実行できることを意味している。
【０１１９】
ｌｗｆはグループｇのホスト上のワークフローｗｆを実行するために必要な予想ＣＰＵ時間であり、次式で与えられる。
【０１２０】
【数３】
【０１２１】
ＮＥＰｗｆはワークフローｗｆの予見される実行回数であり、次式で与えられる。
【０１２２】
ＮＥＰｗｆ（ｇ）＝ＮＱｗｆ＋ＮＡＰｗｆ（ｇ）
ここで、
ＮＱｗｆは、次式により第一のレベル・ワークフロー呼び出しの観点で表された実行待ち行列のワークフローｗｆの総数である。
【０１２３】
【数４】
【０１２４】
ＮＡＰｗｆ（ｇ）は後続するΔＴ期間において予見されるワークフローｗｆの総予想数であり、次式で与えられる。
【０１２５】
【数５】
【０１２６】
ここで、
Ｐｉは先行するΔＴｉに到着したワークフローの重みである。
【０１２７】
ＮＡｗｆ（ｌ１），ｉ（ｎ）は、期間ΔＴｉにホストｎに到達した、第一のレベルのワークフローｗｆｌ１の下位ワークフローであるワークフローｗｆの数である。
【０１２８】
上述の三種の目標を参照するに、予想および適合ステップは以下のように実行される。
【０１２９】
利用可能なＣＰＵ時間が後続するΔＴで予見されるワークフローを実行するのに十分であるか否かを予想すべく、各々のグループｇについて、以下のようにＣＰＵ時間ＣｐｕＴｉｍｅＰ（ｇ）と、グループｇで利用可能なＣＰＵ時間との比較が実行される。
【０１３０】
【数６】
【０１３１】
もし、
【０１３２】
【数７】
【０１３３】
ならば、システムは全てのタスクを実行するための十分な計算リソースを有している。
【０１３４】
【数８】
【０１３５】
ならば、システムはより多くのＣＰＵ時間を必要するため、
ａ） 計算リソースの観点から必須であるホストのグループｇ
ｂ） このようなリソース不足でより重大な影響を受ける恐れのあるＳＬＡに関連付けられた第一レベルのワークフローを含むメッセージを送信する。
【０１３６】
計算リソースがＳＬＡを遵守するのに十分であるか否かを予想すべく、第一レベルのワークフローｗｆｌ１で規定された各ＳＬＡについて、ＳＬＡを遵守するために後続するΔＴで実行されるｗｆｌ１の個数ＮＳＬＡｗｆｌ１が計算される。
【０１３７】
ＳＬＡが、時間ｔ（但しｔ＞＞ΔＴ）内に実行されるワークフローｗｆｌｌのパーセンテージｐ［％］として規定されている場合、ＮＳＬＡｗｆｌｌは次式で与えられる。
【０１３８】
【数９】
【０１３９】
ここで、
ＮＳＬＡＱｗｆｌ１は、各ΔＴｉについて、ΔＴｉ内に到着して未だ待ち行列内で待機しているワークフローｗｆｌ１の数と、ＳＬＡを遵守すべくこれらのワークフローを期限内に完了させるために依然として利用可能なΔＴｓの数ｎ＝（ｔ−ｋΔＴ）／ΔＴとの比の和により与えられる。ｋは、ワークフローが到着してから待ち行列内で待機している間のΔＴｓの数であり、
ＮＳＬＡＰｗｆｌｌは、次のΔＴに到着するワークフローｗｆｌｌの予想数と、ＳＬＡを遵守すべくこれらのワークフローを完了するために依然として利用可能なΔＴｓの数との比（すなわちｔ／ΔＴ）である。
【０１４０】
従って、ワークフローｗｆｌ１がＳＬＡを遵守すべく必要とされるＣＰＵ時間は、次式で与えられる。
【０１４１】
【数１０】
【０１４２】
ここで、
【０１４３】
【数１１】
【０１４４】
ここで
【０１４５】
【数１２】
【０１４６】
かつ
【０１４７】
【数１３】
【０１４８】
ここで、ＮＥｗｆ（ｗｆｌｌ）（ｇ）は、ワークフローｗｆｌ１の各々の実行に対してホスト・グループｇで実行されるワークフローｗｆの予想数であり、次式で与えられる。
【０１４９】
【数１４】
【０１５０】
再び、
【０１５１】
【数１５】
【０１５２】
ならば、システムはワークフローｗｆｌ１がＳＬＡを遵守すべく十分な計算リソースを有している。
【０１５３】
【数１６】
【０１５４】
である場合、システムは、ワークフローｗｆｌ１がＳＬＡを遵守させることができず、従って、以下の節に述べるワークフロー優先順位適合手法が適用される。
【０１５５】
ワークフロー優先順位適合手法は、ＳＬＡに関連付けられた少なくともタイプＡの第一レベル・ワークフローが存在する場合に適用され、このとき次式が成立する。
【０１５６】
【数１７】
【０１５７】
一方、他のタイプの第一レベル・ワークフローの場合、次式が成立する。
【０１５８】
【数１８】
【０１５９】
本手法は各種のアクションで構成され、以下にその少なくともいくつかの例を複雑度の順に記載する。
ａ） タイプＡワークフローの優先順位を上げる。
ｂ） タイプＢワークフローの優先順位を下げる
ｃ） 各々の第一のレベル・ワークフローに重みを関連付けてアクションａ）またはｂ）を実行すべく最も関連のあるものを選択する
ｄ） 違約条項が時間とともに増大しないＳＬＡについて、先行ΔＴにおいて既にＳＬＡの遵守に失敗したワークフローの優先順位を下げて、
ｅ） 違約条項が時間とともに増大するＳＬＡについて、先行ΔＴにおいてＳＬＡの遵守に失敗したワークフローの優先順位を上げる。
【０１６０】
アクションｄ）およびｅ）は、目標および制約コンソールＧＣで規定されたＳＬＡ違約のコスト影響を最小化しようと試みる機能に基づいている。
【０１６１】
本手法は便利な点として、各々のワークフローに割り当てられるＣＰＵ時間の最大量等、リソース使用に対する制約を考慮し続ける。これは、予約されたＣＰＵ時間の最大量を既に使用しているワークフローの優先順位をさらに上げることができないことを意味する。
【０１６２】
各ワークフローの正確なコストの集計が重過ぎる場合、別の可能な方法として、実行された「構築ブロック」の数をエージェントが所定の間隔（例えば５分毎）で集計してシステムのリソース使用状況（例えばＣＰＵ使用）との相関を求めることができる。
【０１６３】
負荷が過剰な状況下にあるコンピュータシステムの性能を推定するために多変量回帰技術がしばしば利用される。この選択は、容量を超えて実行された多くのインフィールドＯＳＳの回数の挙動の分析に基づいている。その結果、ＣＰＵ使用等、大多数のＯＳＳの共通の性能尺度を線形回帰によりモデル化できることがわかった。システム応答時間は、例えば、適度な指数法則に従い増大する。このように、システム性能予測の下限は、システム・リソースデータおよびワークフロー実行データに基づいて多変量線形回帰技術により得られる。
【０１６４】
簡単な多項式モデルの例を次式に示す。
【０１６５】
Ｕｃｐｕ＝ａ０＋ａ１・ＮＡ＋ａ２・ＮＢ＋ａ３・ＮＣ
ここで、
Ｕｃｐｕ ＝ エージェントのＣＰＵ使用
ＮＡ ＝ 構築ブロックＡの実行回数
ＮＢ ＝ 構築ブロックＢの実行回数
ＮＣ ＝ 構築ブロックＢの実行回数
である。
【０１６６】
好適には、全ての尺度（特にＳＬＡ定義）は、一貫した方法で適合を最適化するための経済的数量で表現すべきである。
【０１６７】
例えば図６に、本発明による柔軟性およびスケーラビリティに特徴を有する３層サービスプロビジョニングシナリオの設定を示す。
【０１６８】
この例では、最下位層のエージェントは、ネットワーク要素との対話の責任を負っており、リソース・プロキシと呼ばれ、ＲＰｌ、ＲＰ２、ＲＰ３で示す。
【０１６９】
「オファー１」と名付けられた広帯域サービスは、ＩＰ接続を得るべく、アクセス装置（例：ＡＤＳＬ設備）を含む通信ネットワーク、ＡＴＭバックボーンおよびＢＡＳ（広帯域アクセス・サービス）を介して提供される。
【０１７０】
ＲＰにより提供されるサービスの例として、ポートの設定、交差接続の生成、接続属性の変更がある。その各々は、設備へ／から、送信および受信のうちの一方または双方をされる一連の基本命令を含んでいてよい。
【０１７１】
ＡＡ１、ＡＡ２、ＡＡ３は各々、ＡＤＳＬ設備Ｅ（エンドツーエンド回路の端点Ａ）の画像を表すリソース・プロキシＲＰ１、ＡＤＳＬ設備Ｅに接続しているＡＴＭスイッチＳＷの画像を表すリソース・プロキシＲＰ２、およびＢＡＳ（エンドツーエンド回路の端点Ｚ）の画像を表すリソース・プロキシＲＰ３を管理するエージェントである。
【０１７２】
サービス「オファー１」の提供活動に関わる多レベル・ワークフローを図７に示す。
【０１７３】
レベル１すなわち最上位レベルのワークフローは、２個のステップまたはタスクを含んでいて、マスター・エージェントＭＡにより実行される。第一のもの（ＡＤＳＬ接続性）は、エージェント・レベル（ＡＡ１、ＡＡ２、ＡＡ３）で実行されるレベル２のワークフローの実行を必要とする一方、第２のもの、すなわちメールボックス・タスク（本例では詳述しない）は外部プラットフォームにより実行可能である。
【０１７４】
ＡＤＳＬ接続性タスクは従って、一連のレベル３ワークフローを含むレベル２ワークフローであり、リソース・プロキシレベル（ＲＰｌ、ＲＰ２、ＲＰ３）で実行されるベンダー依存の技術である。レベル３ワークフローは、リソース・プロキシにより通信ネットワーク設備側で実行する必要がある一連のコマンドを含んでいる。レベル２ワークフロー「ＡＤＳＬポート・ベンダーＡ生成」を拡張したことによるレベル３ワークフローの例を図７に示す。
【０１７５】
監視コンソールＭＣは、各ワークフローのリソース使用状況（ＣＰＵ、ＲＡＭ）および経過時間を測定して、特定のベンダーまたは特定のワークフローに問題があれば強調表示する。
【０１７６】
メールボックスが無い点以外はサービス「オファー１」と同様の別サービス「オファー２」が存在すると仮定すれば、目標コンソールは、ＳＬＡ制御ルールおよび関連コスト関数を用いてオファー１およびオファー２に対してＳＬＡを規定することができる。サービス「オファー２」に対するＳＬＡがより重要（例えば、「オファー２」に関連付けられたコスト関数は平均実行時間である１秒を超えた秒数に等しく、「オファー１」に関連付けられたコスト関数は平均実行時間である４秒を超えた秒数に等しい）場合、「オファー２」に対する優先順位は「オファー１」の優先順位より早く増大する。これは、同数の要求に対してハードウェア・リソース（例：ＣＰＵ）が不足している場合、「オファー２」のスループットが「オファー１」のスループットより高いことを意味する。
【０１７７】
従って、プラットフォームは、外部オペレータにより設定されたにせよ、またはエージェント飽和によるものにせよ、自身の目標に達するようリソース使用を調整する。
【０１７８】
当然ながら、本発明の原理は変わらず、実施形態の形式は単に非限定的な例として記述・図解されたものに関して各種の変更が可能であるが、これらは添付の特許請求の範囲により規定される本発明の保護範囲から逸脱するものではない。
【特許請求の範囲】
【請求項１】
通信サービスおよびネットワーク管理用プラットフォームにおけるリソースを管理する方法であって、前記プラットフォームが分散エージェント（Ａ１、Ａ２、Ａ３）により、処理優先順位を有するプロセスの実行を管理することが可能であり、
− 前記プラットフォームが達成すべき目標データを、前記目標データが前記分散エージェントによるプロセスの実行に対する目標およびプラットフォームのリソース使用に対する制約を含むように設定するステップと、
− 分散エージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行およびリソースの使用状況を監視するステップと、
− 前記プロセスの実行および前記リソース使用状況を表す性能データを収集するステップと、
− 前記収集された性能データを、前記設定済みの目標データと比較するステップと、
− 前記エージェントの収集された性能データと、前記設定済みの目標データとの比較に基づいて、少なくとも１個の違約条項を規定するステップと、
− 前記規定された少なくとも１個の違約条項に基づいて、エージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを前記エージェント（Ａ１、Ａ２、Ａ３）に再割り当てするステップと、により特徴付けられる方法。
【請求項２】
前記リソース再割り当てステップが、前記分散エージェント（Ａ１、Ａ２、Ａ３）におけるプロセスの優先順位を変更するステップを含む、請求項１に記載の方法。
【請求項３】
前記リソース再割り当てステップが、
− 所定の観測期間で評価ステップおよび決定ステップを実行するステップ
を含み、
− 前記評価ステップが、
− 少なくとも１個の後続する観測期間でのプロセスの実行および予想されるプロセスの実行回数の両方を表すデータを収集するステップと、
− 前記収集データに基づいて、前記エージェントが要求するリソースを評価するステップと
を含み、
− 前記決定ステップが、
− 要求されたリソースを、前記エージェント（Ａ１、Ａ２、Ａ３）の各々により利用可能なリソースと比較するステップと、
− 前記エージェント（Ａ１、Ａ２、Ａ３）間のリソース使用状況を改善、前記エージェント（Ａ１、Ａ２、Ａ３）におけるプロセスの優先順位を変更、および、前記エージェント（Ａ１、Ａ２、Ａ３）間でのプロセスの実行を再割り当てすることのうちの１以上をすべく、前記エージェント（Ａ１、Ａ２、Ａ３）に対して、決定されたリソース再割り当てルールを適用するステップと
を含む、請求項１に記載の方法。
【請求項４】
− 前記エージェント（Ａ１、Ａ２、Ａ３）に分散プロセス・エンジン（ＰＥ）を提供するステップと、
− プロセスを表すプロセス記述を、前記分散プロセス・エンジン（ＰＥ）に関連付けられたプロセス記述データベース（ＰＤＢ）に保存するステップと
により特徴付けられる、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記プロセス記述がワークフローおよびルールのうちの一方または双方を含む、請求項４に記載の方法。
【請求項６】
− 多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）に従い、前記エージェント（Ａ１、Ａ２、Ａ３）を階層レベルで提供するステップを含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記プロセスの実行が、集中型マネージャ・モジュール（ＭＭ）により前記多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）に割り当てられている、請求項６に記載の方法。
【請求項８】
− 前記性能データ収集ステップが、
− 前記性能データを、前記集中型マネージャ・モジュール（ＭＭ）および前記エージェント（Ａ１、Ａ２、Ａ３）のうちの一方または双方に関連付けられた複数のローカル性能制御エージェント（ＣＡ）へ送信するステップ
を含む、請求項７に記載の方法。
【請求項９】
− 前記多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）の最上位層に少なくとも１個のマスター・エージェント（ＭＡ）を置いて、前記マスター・エージェント（ＭＡ）が前記多層構成の下位層に置かれたエージェント（Ａ１、Ａ２、Ａ３）にプロセスを実行させるステップを含む、請求項７に記載の方法。
【請求項１０】
各エージェント（Ａ１、Ａ２、Ａ３）について、
− 優先順位基準に従い、プロセスの実行要求を多レベル優先順位処理待ち行列（ＷＦＱ）に挿入するステップと、
− 前記多レベル優先順位処理待ち行列（ＷＦＱ）に基づいてプロセスの実行をスケジューリングするステップと、を含む、請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
各エージェントに関連付けられた少なくとも１個のプロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）によりプロセスの実行をスケジューリングするステップを含む、請求項１０に記載の方法。
【請求項１２】
前記多レベル優先順位処理待ち行列（ＷＦＱ）内のプロセスの実行要求が、タイムアウト基準に基づいてアップグレードされる、請求項１０に記載の方法。
【請求項１３】
各制御エージェント（ＣＡ）が、プロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）の個数およびエージェントによるリソース使用を制御する、請求項８または１１に記載の方法。
【請求項１４】
− 前記制御エージェント（ＣＡ）が、エージェントの負荷を決定するロード・バランシング・アルゴリズムを実行し、
− 各エージェント（Ａ１、Ａ２、Ａ３）が他のエージェント（Ａ１、Ａ２、Ａ３）に対し、制御エージェント（ＣＡ）により決定された、少なくともエージェントの負荷の評価を含む基準に基づいてプロセスの実行要求を送信する、請求項８に記載の方法。
【請求項１５】
通信サービスおよびネットワークのうちの一方または双方のリソースを管理するプラットフォームであって、
− 処理優先順位を有するプロセスの実行（ＷＦ１、．．．、ＷＦｎ）を管理可能な複数の分散エージェント（Ａ１、Ａ２、Ａ３）を含み、
− 前記エージェントに関連付けられていて、前記分散エージェント（Ａ１、Ａ２、Ａ３）により、プロセスの実行およびリソース使用状況を監視すべく構成されたプロセス・エンジン（ＰＥ）と、
− 前記プラットフォームが達成すべき目標データを、前記目標データが前記分散エージェントによるプロセスの実行（ＷＦ１、．．．、ＷＦｎ）に対する目標および前記プラットフォームが達成すべきプラットフォームのリソース使用に対する制約を含むように設定し、
− 前記プロセスの実行および前記分散エージェント（Ａ１、Ａ２、Ａ３）によるリソース使用状況を表す性能データを収集し、
− 前記収集された性能データを、設定済みの目標データと比較し、
− 前記エージェントの収集された性能データと、設定済みの目標データとの比較に基づいて、少なくとも１個の違約条項を規定して、
− 前記規定された少なくとも１個の違約条項に基づいて、エージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを前記エージェント（Ａ１、Ａ２、Ａ３）に再割り当てすべく構成された集中型マネージャ・モジュール（ＭＭ）と、により特徴付けられるプラットフォーム。
【請求項１６】
前記集中型マネージャ・モジュール（ＭＭ）がリソース割り当てモジュール（ＲＡ）を含み、前記リソース割り当てモジュールが、
− 評価モジュールであって、
− 後続する観測期間でのプロセスの実行および予想されるプロセスの実行回数の両方を表すデータを収集し、
− 前記収集データに基づいて、前記エージェントが要求するリソースを評価すべく構成された前記評価モジュールと、
− 決定モジュールであって、
− 要求されたリソースを、前記エージェント（Ａ１、Ａ２、Ａ３）の各々により利用可能なリソースと比較し、
− 前記エージェント（Ａ１、Ａ２、Ａ３）間のリソース使用状況を改善、前記エージェント（Ａ１、Ａ２、Ａ３）におけるプロセスの優先順位を変更、および、前記エージェント（Ａ１、Ａ２、Ａ３）間でのプロセスの実行を再割り当てすることのうちの１以上をすべく、前記エージェント（Ａ１、Ａ２、Ａ３）に対して、決定されたリソース再割り当てルールを適用すべく構成された前記決定モジュールと
を含むことを特徴とする、請求項１５に記載のプラットフォーム。
【請求項１７】
前記集中型マネージャ・モジュール（ＭＭ）が、
− 前記プラットフォームの挙動および機能態様を表すプロセス記述を保存するためのプロセス記述データベース（ＰＤＢ）
を含むことを特徴とする、請求項１５〜１６のいずれか一項に記載のプラットフォーム。
【請求項１８】
前記集中型マネージャ・モジュール（ＭＭ）が、
− 前記プロセス記述データベース（ＰＤＢ）内のプロセス記述の定義、生成、および変更を行なうべく構成されたサービス生成コンソール（ＳＣＣ）
をさらに含むことを特徴とする、請求項１７に記載のプラットフォーム。
【請求項１９】
前記プロセス記述が、ワークフローおよびルールのうちの一方または双方を含むことを特徴とする、請求項１７に記載のプラットフォーム。
【請求項２０】
− 前記複数の分散エージェント（Ａ１、Ａ２、Ａ３）が、多層構成に従い階層的なレベルに編成されていて、かつ、
− 前記集中型マネージャ・モジュール（ＭＭ）が、前記多層構成をなすエージェントにプロセスの実行を割り当てるべく設定されていることを特徴とする、請求項１５〜１９のいずれか一項に記載のプラットフォーム。
【請求項２１】
− 少なくとも一組の分散エージェント（Ａ１、Ａ２、Ａ３）に関連付けられたローカル性能制御エージェント（ＣＡ）により特徴付けられていて、かつ、
− 前記プロセス・エンジン（ＰＥ）が、
− 前記性能データを前記集中型マネージャ・モジュール（ＭＭ）および前記エージェント（Ａ１、Ａ２、Ａ３）のうちの一方または双方に関連付けられた前記ローカル性能制御エージェント（ＣＡ）へ送信すべく設定されたリソース監視モジュール（ＲＭ）
を含むことを特徴とする、請求項１５〜２０のいずれか一項に記載のプラットフォーム。
【請求項２２】
− 前記多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）の最上位層に置かれていて、前記多層構成の下位層に置かれたエージェント（Ａ１、Ａ２、Ａ３）にプロセスを実行させるべく設定されている、少なくとも１個のマスター・エージェント（ＭＡ）により特徴付けられる、請求項２０に記載のプラットフォーム。
【請求項２３】
− 前記複数の分散エージェント（Ａ１、Ａ２、Ａ３）の少なくとも一組を含む少なくとも１個のプロセス機械（Ｈ）により特徴付けられる、請求項１５〜２２のいずれか一項に記載のプラットフォーム。
【請求項２４】
少なくとも１個のローカル性能制御エージェント（ＣＡ）が、前記少なくとも１個のプロセス機械（Ｈ）に関連付けられていることを特徴とする、請求項２３に記載のプラットフォーム。
【請求項２５】
前記少なくとも１個のローカル性能制御エージェント（ＣＡ）が、
− 前記エージェント（Ａ１、Ａ２、Ａ３）によるリソース使用状況およびプロセスの実行を表す性能データを収集して、前記性能データを前記集中型マネージャ・モジュール（ＭＭ）へ送信すべく構成された共通ローカル性能監視モジュール（ＲＭ）と、
− 前記リソース検出装置（ＲＭ）に結合されていて、待機中のプロセス（ＷＦ１、．．．、ＷＦｎ）を実行するプロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）を生成すべく構成された共通スレッド・コントローラ（ＴＣ）と、
− 前記プロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）に結合されていて、所定のロード・バランシング・アルゴリズムに従い他のエージェント（Ａ１、Ａ２、Ａ３）へプロセスの実行要求を送信すべく構成された共通ディスパッチャ・モジュール（Ｄ）と
を含むことを特徴とする、請求項２４に記載のプラットフォーム。
【請求項２６】
マネージャ・モジュール（ＭＭ）が、
− 容量計画モジュールであって、
− 履歴的な性能および現在のリソース使用状況を表すデータに基づく観察期間でリソースの利用可能性を予測すべく構成された前記容量計画モジュール
を含むことを特徴とする、請求項１５に記載のプラットフォーム。
【請求項２７】
前記マネージャ・モジュール（ＭＭ）が、
− 管理用コンソール（ＡＣ）であって、
− 前記プラットフォームのハードウェア構成を規定し、かつ
− プロセスの実行に対する制約を規定すべく構成された前記管理用コンソール（ＡＣ）
を含むことを特徴とする、請求項１５に記載のプラットフォーム。
【請求項２８】
請求項１５〜２７のいずれかに記載のプラットフォームにより管理される通信ネットワーク。
【請求項２９】
通信サービス、例えばＡＤＳＬ接続サービスを設定および管理する方法であって、請求項１〜１４のいずれかに記載の方法に従いリソースを管理するステップを含む方法。
【請求項３０】
少なくとも１個のコンピュータのメモリにロード可能であって、請求項１〜１４のいずれか一項に記載のステップを実行するソフトウェア・コード部分を含む、コンピュータ・プログラム製品またはコンピュータ・プログラム製品のコンピュータ・プログラムの組。
【請求項１】
通信サービスおよびネットワーク管理用プラットフォームにおけるリソースを管理する方法であって、前記プラットフォームが分散エージェント（Ａ１、Ａ２、Ａ３）により、処理優先順位を有するプロセスの実行を管理することが可能であり、
− 前記プラットフォームが達成すべき目標データを、前記目標データが前記分散エージェントによるプロセスの実行に対する目標およびプラットフォームのリソース使用に対する制約を含むように設定するステップと、
− 分散エージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行およびリソースの使用状況を監視するステップと、
− 前記プロセスの実行および前記リソース使用状況を表す性能データを収集するステップと、
− 前記収集された性能データを、前記設定済みの目標データと比較するステップと、
− 前記エージェントの収集された性能データと、前記設定済みの目標データとの比較に基づいて、少なくとも１個の違約条項を規定するステップと、
− 前記規定された少なくとも１個の違約条項に基づいて、エージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを前記エージェント（Ａ１、Ａ２、Ａ３）に再割り当てするステップと、により特徴付けられる方法。
【請求項２】
前記リソース再割り当てステップが、前記分散エージェント（Ａ１、Ａ２、Ａ３）におけるプロセスの優先順位を変更するステップを含む、請求項１に記載の方法。
【請求項３】
前記リソース再割り当てステップが、
− 所定の観測期間で評価ステップおよび決定ステップを実行するステップ
を含み、
− 前記評価ステップが、
− 少なくとも１個の後続する観測期間でのプロセスの実行および予想されるプロセスの実行回数の両方を表すデータを収集するステップと、
− 前記収集データに基づいて、前記エージェントが要求するリソースを評価するステップと
を含み、
− 前記決定ステップが、
− 要求されたリソースを、前記エージェント（Ａ１、Ａ２、Ａ３）の各々により利用可能なリソースと比較するステップと、
− 前記エージェント（Ａ１、Ａ２、Ａ３）間のリソース使用状況を改善、前記エージェント（Ａ１、Ａ２、Ａ３）におけるプロセスの優先順位を変更、および、前記エージェント（Ａ１、Ａ２、Ａ３）間でのプロセスの実行を再割り当てすることのうちの１以上をすべく、前記エージェント（Ａ１、Ａ２、Ａ３）に対して、決定されたリソース再割り当てルールを適用するステップと
を含む、請求項１に記載の方法。
【請求項４】
− 前記エージェント（Ａ１、Ａ２、Ａ３）に分散プロセス・エンジン（ＰＥ）を提供するステップと、
− プロセスを表すプロセス記述を、前記分散プロセス・エンジン（ＰＥ）に関連付けられたプロセス記述データベース（ＰＤＢ）に保存するステップと
により特徴付けられる、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記プロセス記述がワークフローおよびルールのうちの一方または双方を含む、請求項４に記載の方法。
【請求項６】
− 多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）に従い、前記エージェント（Ａ１、Ａ２、Ａ３）を階層レベルで提供するステップを含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記プロセスの実行が、集中型マネージャ・モジュール（ＭＭ）により前記多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）に割り当てられている、請求項６に記載の方法。
【請求項８】
− 前記性能データ収集ステップが、
− 前記性能データを、前記集中型マネージャ・モジュール（ＭＭ）および前記エージェント（Ａ１、Ａ２、Ａ３）のうちの一方または双方に関連付けられた複数のローカル性能制御エージェント（ＣＡ）へ送信するステップ
を含む、請求項７に記載の方法。
【請求項９】
− 前記多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）の最上位層に少なくとも１個のマスター・エージェント（ＭＡ）を置いて、前記マスター・エージェント（ＭＡ）が前記多層構成の下位層に置かれたエージェント（Ａ１、Ａ２、Ａ３）にプロセスを実行させるステップを含む、請求項７に記載の方法。
【請求項１０】
各エージェント（Ａ１、Ａ２、Ａ３）について、
− 優先順位基準に従い、プロセスの実行要求を多レベル優先順位処理待ち行列（ＷＦＱ）に挿入するステップと、
− 前記多レベル優先順位処理待ち行列（ＷＦＱ）に基づいてプロセスの実行をスケジューリングするステップと、を含む、請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
各エージェントに関連付けられた少なくとも１個のプロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）によりプロセスの実行をスケジューリングするステップを含む、請求項１０に記載の方法。
【請求項１２】
前記多レベル優先順位処理待ち行列（ＷＦＱ）内のプロセスの実行要求が、タイムアウト基準に基づいてアップグレードされる、請求項１０に記載の方法。
【請求項１３】
各制御エージェント（ＣＡ）が、プロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）の個数およびエージェントによるリソース使用を制御する、請求項８または１１に記載の方法。
【請求項１４】
− 前記制御エージェント（ＣＡ）が、エージェントの負荷を決定するロード・バランシング・アルゴリズムを実行し、
− 各エージェント（Ａ１、Ａ２、Ａ３）が他のエージェント（Ａ１、Ａ２、Ａ３）に対し、制御エージェント（ＣＡ）により決定された、少なくともエージェントの負荷の評価を含む基準に基づいてプロセスの実行要求を送信する、請求項８に記載の方法。
【請求項１５】
通信サービスおよびネットワークのうちの一方または双方のリソースを管理するプラットフォームであって、
− 処理優先順位を有するプロセスの実行（ＷＦ１、．．．、ＷＦｎ）を管理可能な複数の分散エージェント（Ａ１、Ａ２、Ａ３）を含み、
− 前記エージェントに関連付けられていて、前記分散エージェント（Ａ１、Ａ２、Ａ３）により、プロセスの実行およびリソース使用状況を監視すべく構成されたプロセス・エンジン（ＰＥ）と、
− 前記プラットフォームが達成すべき目標データを、前記目標データが前記分散エージェントによるプロセスの実行（ＷＦ１、．．．、ＷＦｎ）に対する目標および前記プラットフォームが達成すべきプラットフォームのリソース使用に対する制約を含むように設定し、
− 前記プロセスの実行および前記分散エージェント（Ａ１、Ａ２、Ａ３）によるリソース使用状況を表す性能データを収集し、
− 前記収集された性能データを、設定済みの目標データと比較し、
− 前記エージェントの収集された性能データと、設定済みの目標データとの比較に基づいて、少なくとも１個の違約条項を規定して、
− 前記規定された少なくとも１個の違約条項に基づいて、エージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを前記エージェント（Ａ１、Ａ２、Ａ３）に再割り当てすべく構成された集中型マネージャ・モジュール（ＭＭ）と、により特徴付けられるプラットフォーム。
【請求項１６】
前記集中型マネージャ・モジュール（ＭＭ）がリソース割り当てモジュール（ＲＡ）を含み、前記リソース割り当てモジュールが、
− 評価モジュールであって、
− 後続する観測期間でのプロセスの実行および予想されるプロセスの実行回数の両方を表すデータを収集し、
− 前記収集データに基づいて、前記エージェントが要求するリソースを評価すべく構成された前記評価モジュールと、
− 決定モジュールであって、
− 要求されたリソースを、前記エージェント（Ａ１、Ａ２、Ａ３）の各々により利用可能なリソースと比較し、
− 前記エージェント（Ａ１、Ａ２、Ａ３）間のリソース使用状況を改善、前記エージェント（Ａ１、Ａ２、Ａ３）におけるプロセスの優先順位を変更、および、前記エージェント（Ａ１、Ａ２、Ａ３）間でのプロセスの実行を再割り当てすることのうちの１以上をすべく、前記エージェント（Ａ１、Ａ２、Ａ３）に対して、決定されたリソース再割り当てルールを適用すべく構成された前記決定モジュールと
を含むことを特徴とする、請求項１５に記載のプラットフォーム。
【請求項１７】
前記集中型マネージャ・モジュール（ＭＭ）が、
− 前記プラットフォームの挙動および機能態様を表すプロセス記述を保存するためのプロセス記述データベース（ＰＤＢ）
を含むことを特徴とする、請求項１５〜１６のいずれか一項に記載のプラットフォーム。
【請求項１８】
前記集中型マネージャ・モジュール（ＭＭ）が、
− 前記プロセス記述データベース（ＰＤＢ）内のプロセス記述の定義、生成、および変更を行なうべく構成されたサービス生成コンソール（ＳＣＣ）
をさらに含むことを特徴とする、請求項１７に記載のプラットフォーム。
【請求項１９】
前記プロセス記述が、ワークフローおよびルールのうちの一方または双方を含むことを特徴とする、請求項１７に記載のプラットフォーム。
【請求項２０】
− 前記複数の分散エージェント（Ａ１、Ａ２、Ａ３）が、多層構成に従い階層的なレベルに編成されていて、かつ、
− 前記集中型マネージャ・モジュール（ＭＭ）が、前記多層構成をなすエージェントにプロセスの実行を割り当てるべく設定されていることを特徴とする、請求項１５〜１９のいずれか一項に記載のプラットフォーム。
【請求項２１】
− 少なくとも一組の分散エージェント（Ａ１、Ａ２、Ａ３）に関連付けられたローカル性能制御エージェント（ＣＡ）により特徴付けられていて、かつ、
− 前記プロセス・エンジン（ＰＥ）が、
− 前記性能データを前記集中型マネージャ・モジュール（ＭＭ）および前記エージェント（Ａ１、Ａ２、Ａ３）のうちの一方または双方に関連付けられた前記ローカル性能制御エージェント（ＣＡ）へ送信すべく設定されたリソース監視モジュール（ＲＭ）
を含むことを特徴とする、請求項１５〜２０のいずれか一項に記載のプラットフォーム。
【請求項２２】
− 前記多層構成をなすエージェント（Ａ１、Ａ２、Ａ３）の最上位層に置かれていて、前記多層構成の下位層に置かれたエージェント（Ａ１、Ａ２、Ａ３）にプロセスを実行させるべく設定されている、少なくとも１個のマスター・エージェント（ＭＡ）により特徴付けられる、請求項２０に記載のプラットフォーム。
【請求項２３】
− 前記複数の分散エージェント（Ａ１、Ａ２、Ａ３）の少なくとも一組を含む少なくとも１個のプロセス機械（Ｈ）により特徴付けられる、請求項１５〜２２のいずれか一項に記載のプラットフォーム。
【請求項２４】
少なくとも１個のローカル性能制御エージェント（ＣＡ）が、前記少なくとも１個のプロセス機械（Ｈ）に関連付けられていることを特徴とする、請求項２３に記載のプラットフォーム。
【請求項２５】
前記少なくとも１個のローカル性能制御エージェント（ＣＡ）が、
− 前記エージェント（Ａ１、Ａ２、Ａ３）によるリソース使用状況およびプロセスの実行を表す性能データを収集して、前記性能データを前記集中型マネージャ・モジュール（ＭＭ）へ送信すべく構成された共通ローカル性能監視モジュール（ＲＭ）と、
− 前記リソース検出装置（ＲＭ）に結合されていて、待機中のプロセス（ＷＦ１、．．．、ＷＦｎ）を実行するプロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）を生成すべく構成された共通スレッド・コントローラ（ＴＣ）と、
− 前記プロセス・エンジン・スレッド（ＴＨ１、．．．、ＴＨｎ）に結合されていて、所定のロード・バランシング・アルゴリズムに従い他のエージェント（Ａ１、Ａ２、Ａ３）へプロセスの実行要求を送信すべく構成された共通ディスパッチャ・モジュール（Ｄ）と
を含むことを特徴とする、請求項２４に記載のプラットフォーム。
【請求項２６】
マネージャ・モジュール（ＭＭ）が、
− 容量計画モジュールであって、
− 履歴的な性能および現在のリソース使用状況を表すデータに基づく観察期間でリソースの利用可能性を予測すべく構成された前記容量計画モジュール
を含むことを特徴とする、請求項１５に記載のプラットフォーム。
【請求項２７】
前記マネージャ・モジュール（ＭＭ）が、
− 管理用コンソール（ＡＣ）であって、
− 前記プラットフォームのハードウェア構成を規定し、かつ
− プロセスの実行に対する制約を規定すべく構成された前記管理用コンソール（ＡＣ）
を含むことを特徴とする、請求項１５に記載のプラットフォーム。
【請求項２８】
請求項１５〜２７のいずれかに記載のプラットフォームにより管理される通信ネットワーク。
【請求項２９】
通信サービス、例えばＡＤＳＬ接続サービスを設定および管理する方法であって、請求項１〜１４のいずれかに記載の方法に従いリソースを管理するステップを含む方法。
【請求項３０】
少なくとも１個のコンピュータのメモリにロード可能であって、請求項１〜１４のいずれか一項に記載のステップを実行するソフトウェア・コード部分を含む、コンピュータ・プログラム製品またはコンピュータ・プログラム製品のコンピュータ・プログラムの組。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−７４０５６（Ｐ２０１２−７４０５６Ａ）
【公開日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−２４６３５３（Ｐ２０１１−２４６３５３）
【出願日】平成２３年１１月１０日（２０１１．１１．１０）
【分割の表示】特願２００７−５３８２７４（Ｐ２００７−５３８２７４）の分割
【原出願日】平成１６年１０月２８日（２００４．１０．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０３１４８２７０）テレコム・イタリア・エッセ・ピー・アー (87)
【公開日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願番号】特願２０１１−２４６３５３（Ｐ２０１１−２４６３５３）
【出願日】平成２３年１１月１０日（２０１１．１１．１０）
【分割の表示】特願２００７−５３８２７４（Ｐ２００７−５３８２７４）の分割
【原出願日】平成１６年１０月２８日（２００４．１０．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０３１４８２７０）テレコム・イタリア・エッセ・ピー・アー (87)
[ Back to top ]