"通信サービスおよびネットワーク管理用プラットフォームにおけるリソースを管理する方法であって、前記プラットフォームが分散エージェントA1、A2、A3により、処理優先順位を有するプロセスの実行を管理することが可能であり、-前記プラットフォームが達成すべき目標データを、前記目標データが前記分散エージェントによるプロセスの実行に対する目標およびプラットフォームのリソース使用に対する制約を含むように設定するステップと、-分散エージェントA1、A2、A3によるプロセスの実行およびリソースの使用状況を監視するステップと、-前記プロセスの実行および前記リソース使用状況を表す性能データを収集するステップと、-前記収集された性能データを、前記設定済みの目標データと比較するステップと、-前記エージェントの収集された性能データと、前記設定済みの目標データとの比較に基づいて、少なくとも1個の違約条項を規定するステップと、-前記規定された少なくとも1個の違約条項に基づいて、エージェントA1、A2、A3によるプロセスの実行のためのリソースを前記エージェントA1、A2、A3に再割り当てするステップと、により特徴付けられる方法。前記リソース再割り当てステップが、前記分散エージェントA1、A2、A3におけるプロセスの優先順位を変更するステップを含む、請求項1に記載の方法。前記リソース再割り当てステップが、-所定の観測期間で評価ステップおよび決定ステップを実行するステップを含み、-前記評価ステップが、-少なくとも1個の後続する観測期間でのプロセスの実行および予想されるプロセスの実行回数の両方を表すデータを収集するステップと、-前記収集データに基づいて、前記エージェントが要求するリソースを評価するステップとを含み、-前記決定ステップが、-要求されたリソースを、前記エージェントA1、A2、A3の各々により利用可能なリソースと比較するステップと、-前記エージェントA1、A2、A3間のリソース使用状況を改善、前記エージェントA1、A2、A3におけるプロセスの優先順位を変更、および、前記エージェントA1、A2、A3間でのプロセスの実行を再割り当てすることのうちの1以上をすべく、前記エージェントA1、A2、A3に対して、決定されたリソース再割り当てルールを適用するステップとを含む、請求項1に記載の方法。-前記エージェントA1、A2、A3に分散プロセスエンジンPEを提供するステップと、-プロセスを表すプロセス記述を、前記分散プロセスエンジンPEに関連付けられたプロセス記述データベースPDBに保存するステップとにより特徴付けられる、請求項1~3のいずれか一項に記載の方法。前記プロセス記述がワークフローおよびルールのうちの一方または双方を含む、請求項4に記載の方法。-多層構成をなすエージェントA1、A2、A3に従い、前記エージェントA1、A2、A3を階層レベルで提供するステップを含む、請求項1~5のいずれか一項に記載の方法。前記プロセスの実行が、集中型マネージャモジュールMMにより前記多層構成をなすエージェントA1、A2、A3に割り当てられている、請求項6に記載の方法。-前記性能データ収集ステップが、-前記性能データを、前記集中型マネージャモジュールMMおよび前記エージェントA1、A2、A3のうちの一方または双方に関連付けられた複数のローカル性能制御エージェントCAへ送信するステップを含む、請求項7に記載の方法。-前記多層構成をなすエージェントA1、A2、A3の最上位層に少なくとも1個のマスターエージェントMAを置いて、前記マスターエージェントMAが前記多層構成の下位層に置かれたエージェントA1、A2、A3にプロセスを実行させるステップを含む、請求項7に記載の方法。各エージェントA1、A2、A3について、-優先順位基準に従い、プロセスの実行要求を多レベル優先順位処理待ち行列WFQに挿入するステップと、-前記多レベル優先順位処理待ち行列WFQに基づいてプロセスの実行をスケジューリングするステップと、を含む、請求項1~9のいずれか一項に記載の方法。各エージェントに関連付けられた少なくとも1個のプロセスエンジンスレッドTH1、...、THnによりプロセスの実行をスケジューリングするステップを含む、請求項10に記載の方法。前記多レベル優先順位処理待ち行列WFQ内のプロセスの実行要求が、タイムアウト基準に基づいてアップグレードされる、請求項10に記載の方法。各制御エージェントCAが、プロセスエンジンスレッドTH1、...、THnの個数およびエージェントによるリソース使用を制御する、請求項8または11に記載の方法。-前記制御エージェントCAが、エージェントの負荷を決定するロードバランシングアルゴリズムを実行し、-各エージェントA1、A2、A3が他のエージェントA1、A2、A3に対し、制御エージェントCAにより決定された、少なくともエージェントの負荷の評価を含む基準に基づいてプロセスの実行要求を送信する、請求項8に記載の方法。通信サービスおよびネットワークのうちの一方または双方のリソースを管理するプラットフォームであって、-処理優先順位を有するプロセスの実行WF1、...、WFnを管理可能な複数の分散エージェントA1、A2、A3を含み、-前記エージェントに関連付けられていて、前記分散エージェントA1、A2、A3により、プロセスの実行およびリソース使用状況を監視すべく構成されたプロセスエンジンPEと、-前記プラットフォームが達成すべき目標データを、前記目標データが前記分散エージェントによるプロセスの実行WF1、...、WFnに対する目標および前記プラットフォームが達成すべきプラットフォームのリソース使用に対する制約を含むように設定し、-前記プロセスの実行および前記分散エージェントA1、A2、A3によるリソース使用状況を表す性能データを収集し、-前記収集された性能データを、設定済みの目標データと比較し、-前記エージェントの収集された性能データと、設定済みの目標データとの比較に基づいて、少なくとも1個の違約条項を規定して、-前記規定された少なくとも1個の違約条項に基づいて、エージェントA1、A2、A3によるプロセスの実行のためのリソースを前記エージェントA1、A2、A3に再割り当てすべく構成された集中型マネージャモジュールMMと、により特徴付けられるプラットフォーム。前記集中型マネージャモジュールMMがリソース割り当てモジュールRAを含み、前記リソース割り当てモジュールが、-評価モジュールであって、-後続する観測期間でのプロセスの実行および予想されるプロセスの実行回数の両方を表すデータを収集し、-前記収集データに基づいて、前記エージェントが要求するリソースを評価すべく構成された前記評価モジュールと、-決定モジュールであって、-要求されたリソースを、前記エージェントA1、A2、A3の各々により利用可能なリソースと比較し、-前記エージェントA1、A2、A3間のリソース使用状況を改善、前記エージェントA1、A2、A3におけるプロセスの優先順位を変更、および、前記エージェントA1、A2、A3間でのプロセスの実行を再割り当てすることのうちの1以上をすべく、前記エージェントA1、A2、A3に対して、決定されたリソース再割り当てルールを適用すべく構成された前記決定モジュールとを含むことを特徴とする、請求項15に記載のプラットフォーム。前記集中型マネージャモジュールMMが、-前記プラットフォームの挙動および機能態様を表すプロセス記述を保存するためのプロセス記述データベースPDBを含むことを特徴とする、請求項15~16のいずれか一項に記載のプラットフォーム。前記集中型マネージャモジュールMMが、-前記プロセス記述データベースPDB内のプロセス記述の定義、生成、および変更を行なうべく構成されたサービス生成コンソールSCCをさらに含むことを特徴とする、請求項17に記載のプラットフォーム。前記プロセス記述が、ワークフローおよびルールのうちの一方または双方を含むことを特徴とする、請求項17に記載のプラットフォーム。-前記複数の分散エージェントA1、A2、A3が、多層構成に従い階層的なレベルに編成されていて、かつ、-前記集中型マネージャモジュールMMが、前記多層構成をなすエージェントにプロセスの実行を割り当てるべく設定されていることを特徴とする、請求項15~19のいずれか一項に記載のプラットフォーム。-少なくとも一組の分散エージェントA1、A2、A3に関連付けられたローカル性能制御エージェントCAにより特徴付けられていて、かつ、-前記プロセスエンジンPEが、-前記性能データを前記集中型マネージャモジュールMMおよび前記エージェントA1、A2、A3のうちの一方または双方に関連付けられた前記ローカル性能制御エージェントCAへ送信すべく設定されたリソース監視モジュールRMを含むことを特徴とする、請求項15~20のいずれか一項に記載のプラットフォーム。-前記多層構成をなすエージェントA1、A2、A3の最上位層に置かれていて、前記多層構成の下位層に置かれたエージェントA1、A2、A3にプロセスを実行させるべく設定されている、少なくとも1個のマスターエージェントMAにより特徴付けられる、請求項20に記載のプラットフォーム。-前記複数の分散エージェントA1、A2、A3の少なくとも一組を含む少なくとも1個のプロセス機械Hにより特徴付けられる、請求項15~22のいずれか一項に記載のプラットフォーム。少なくとも1個のローカル性能制御エージェントCAが、前記少なくとも1個のプロセス機械Hに関連付けられていることを特徴とする、請求項23に記載のプラットフォーム。前記少なくとも1個のローカル性能制御エージェントCAが、-前記エージェントA1、A2、A3によるリソース使用状況およびプロセスの実行を表す性能データを収集して、前記性能データを前記集中型マネージャモジュールMMへ送信すべく構成された共通ローカル性能監視モジュールRMと、-前記リソース検出装置RMに結合されていて、待機中のプロセスWF1、...、WFnを実行するプロセスエンジンスレッドTH1、...、THnを生成すべく構成された共通スレッドコントローラTCと、-前記プロセスエンジンスレッドTH1、...、THnに結合されていて、所定のロードバランシングアルゴリズムに従い他のエージェントA1、A2、A3へプロセスの実行要求を送信すべく構成された共通ディスパッチャモジュールDとを含むことを特徴とする、請求項24に記載のプラットフォーム。マネージャモジュールMMが、-容量計画モジュールであって、-履歴的な性能および現在のリソース使用状況を表すデータに基づく観察期間でリソースの利用可能性を予測すべく構成された前記容量計画モジュールを含むことを特徴とする、請求項15に記載のプラットフォーム。前記マネージャモジュールMMが、-管理用コンソールACであって、-前記プラットフォームのハードウェア構成を規定し、かつ-プロセスの実行に対する制約を規定すべく構成された前記管理用コンソールACを含むことを特徴とする、請求項15に記載のプラットフォーム。請求項15~27のいずれかに記載のプラットフォームにより管理される通信ネットワーク。通信サービス、例えばADSL接続サービスを設定および管理する方法であって、請求項1~14のいずれかに記載の方法に従いリソースを管理するステップを含む方法。少なくとも1個のコンピュータのメモリにロード可能であって、請求項1~14のいずれか一項に記載のステップを実行するソフトウェアコード部分を含む、コンピュータプログラム製品またはコンピュータプログラム製品のコンピュータプログラムの組。出願人は、上記のアーキテクチャでは、エージェントがワークフローエンジンにより委譲されたジョブを実行することが保障されないと考える。実際に、計算能力等、エージェントが利用できるITリソースには限界があり、プラットフォームに求められる業務目標や作業負荷に合致するにはITリソースが十分であるとは限らない。換言すれば、エージェントが利用できるITリソース如何により、例えば顧客へのサービス提供等、エージェントにより実行されるタスクを必要とする所定の業務目標の達成が妨げられる場合がある。例えば、タスクとして、規定されたプロセスを所定の持続期間より短い平均時間で完了すること、または一定の期限内に所定数のプロセスを完了することが挙げられる。エージェントにかかる膨大な作業負荷により、エージェントが所定の平均時間または定められた期限内にタスクを完了することができなくなり、従って業務目標が達成されない恐れがある。集中型プロセスコーディネータを用いるエージェントに基づくアーキテクチャの別の問題は、国際公開第01/02973号パンフレットに開示されているように、コーディネータ自体がプラットフォームの動作のボトルネックになる点であり、柔軟性を向上させるべくコーディネータにワークフローを加えるエージェントから外出しされたプロセスロジックが増えるほど、コーディネータが遅くなる。これにより、実行に期限を有するプロセス等、業務性能目標を達成するためのアーキテクチャの能力が低下する恐れがある。ITリソース管理分野において、米国特許出願公開第2003/0167270号明細書に、スケーラブルなアプリケーションのコピーのインスタンス生成を行なうホスト機を含む分散環境におけるリソース管理システムが開示されている。当該リソース管理システムは、アプリケーションのコピーに関する情報およびホストの性能に基づいて、ホスト群をまたがってスケーラブルなアプリケーションの選択されたコピーを起動、停止、または移動させる信号を生成する。この種のソリューションは、少なくとも以下の理由により、プロセスコーディネータまたはワークフローエンジンにより調整される分散型エージェントアーキテクチャを含むプラットフォームには適していない。-全てのエージェントが既にいくつかのタスクを実行している場合、緊急のタスクまたはアプリケーションを新たに実行するための空きエージェントが存在する余地がない。-新規ワークフローすなわち新たな機能が規定される都度、業務目標例:業務プロセスの期限を実現すべく、既知のシステムはアプリケーションのパラメータを測定して、全てのエージェントの挙動を調整すべく新たなモデルを構築する必要がある。-既知のリソース管理システムは、複数のコピーにインスタンスが生成され得るアプリケーションまたは機能に対してのみ作用する。本発明の目的は従って、通信サービスおよびネットワークのうちの一方または双方を管理するエージェント利用プラットフォームにおけるリソースを管理する方法を提供することであり、これにより所定の業務目標を達成すべくリソース使用状況における最適な性能を実現してプラットフォームの効率を向上させる。本発明の他の目的は、プラットフォームの柔軟性を向上させながら性能向上を実現するために分散型プロセスロジックを有する管理プラットフォームである。本発明によれば、これらの目的は、通信サービスおよびネットワークのうちの一方または双方を管理するプラットフォームにおけるリソース管理の方法により、かつ独立請求項に記述された特徴を有する管理プラットフォームにより実現される。本発明のさらなる目的は、特許請求の範囲に記述されるように、通信管理プラットフォームの設定および運転を行なうコンピュータプログラム製品またはコンピュータプログラムの組、通信ネットワークおよび方法である。要約すれば、従来技術の短所を克服すべく、本発明は、所定の指標例:主要業務指標および目標により駆動される、予測および適応型の機構に基づく方法および対応プラットフォームを開示するものであり、管理プラットフォームにおけるITリソースの使用状況の測定および自動制御を行なう。好適には、本発明によるプラットフォームのアーキテクチャの特徴は以下の通りである。-エージェントが提供する全ての機能を実装するエージェント内部のプロセスワークフローおよびルールエンジンを提供することにより、エージェントが実行しなければならないジョブがワークフローの実行となる。ルールエンジンは、特定種類のジョブを実行すべくワークフローエンジンに結合することができる。-プロセス記述を定義および保存してこれらの記述をエージェントに分散するための集中型プロセス記述データベースの提供、-業務目標例:SLA、サービスレベル合意および機能およびその集計例:履行、保証、支払い請求等の業務プロセス領域へのの定義に基づく処理優先順位を含む目標データの指定を可能にする目標および制約コンソールの提供、-プラットフォームの各エージェントにおける各々のプロセスの実行並びに業務プロセスによるワークフローの実行によるITリソースの使用を監視、すなわち、例えば経過時間、実行頻度等を監視すべく構成された制御エージェントの提供、および、-業務目標を最大限に達成すべく、指定された目標データ業務目標およびリソースの使用状況を示す監視された性能データに基づいて、適応型の方法でプラットフォームの各エージェントにITリソースを再割り当てすべく構成されたリソース割り当てモジュールの提供。本発明の好適な実施形態によれば、リソースの再割り当てルールを規定すべくグラフィカルユーザーインターフェースとしてリ-アロケータコンソールが提供されていると共に、監視コンソールが提供されていることにより、SLAの達成状況および対応ITリソースの使用状況および関連コストの制御が可能になる点が好都合である。エージェント内部にプロセスエンジンを提供することが、全てのエンジンが集中型プロセスコーディネータに置かれている場合にボトルネックを生じることなく柔軟性を向上させ、エージェント間でITリソースを動的に割り当てる際に有利な特徴であることがわかる。エージェント内のプロセスエンジンにより、各々の機能実行すなわちプロセスの実行に際してエージェント内でのリソース使用状況例:使用されたCPU時間またはRAMを分析的に測定することが可能になる。集中型データベースにおけるプロセス記述は、プラットフォーム横断的に各エージェントへそれらのプロセスエンジン内で利用すべく分散され、プラットフォームの全ての動作機能と自動的に同期化が行なわれるため、ジョブのセマンティクスと協働するリソースの管理プロシージャを調整することが可能である。実際には、通信サービスおよびネットワークを管理するプラットフォームの管理者は、プロセスデータベース内で1個以上のワークフローおよびルールのうちの一方または双方を規定するかまたは既存のものの組み合わせる任意のFCAPS故障、設定、課金、性能、セキュリティ機能を構築することができ、次いで必要なときにエージェントが新規プロセスワークフローおよびルールの定義を自動的に取得して実行することができる。自動的に、目標コンソールが新規プロセスに対するSLAおよび優先順位の規定を可能にする。実行時に、制御エージェントは、新規プロセスのSLA傾向および対応ITリソースの使用状況の制御を可能にして、リ-アロケータモジュールが全体構成を最適化できるように、すなわちエージェントにおけるワークフロー優先順位を変更するか、またはより多くの計算リソースCPU、メモリ等を与える。本発明によるリソース管理は好適には、分散されたモジュール制御エージェントと共に、集中型モジュールマネージャモジュールによりプラットフォーム内で実装される。集中および分散機能の組合せは、ソリューションの適応型機構の基礎となる。本発明のさらなる特徴および利点を、添付図面に関して非限定的な例を用いて以下の記述においてさらに詳しく説明する。図1に、本発明による通信サービスおよびネットワーク管理システムの例証的なアーキテクチャを示す。本システムは好適には、各々が1個以上のソフトウェアエージェントA1、A2、A3を含み得る複数のプロセスホスト機Hを含む分散プロセスアーキテクチャに実装されている。本システムまたはプラットフォームは、ホスト機上で動作してプロセス記述の分散、動作の起動、管理統制等、各種の協調動作のために分散エージェントと対話するプログラムまたはプログラムの組を含む集中型制御モジュールまたはマネージャモジュールMMを含んでいる。マネージャモジュールMMはまた、好適にはシステム管理者等のユーザーと対話するためのグラフィカルユーザーインタフェースを含んでいてよい。本明細書において、プロセスという用語は、1個以上のワークフロー、1個以上のルールまたは、好適には1個以上のワークフローと1個以上のルールの組合せを表すために用いられる。ワークフローは、手続きのルールの組に従い、実行中にあるエージェントから別のエージェントへ情報またはタスクが渡される業務プロシージャの自動化されたものとして規定することができる。ワークフローは、一連のタスク並びに代替的なまたは並列分枝を含むタスク間の時間的かつ論理的依存関係を有するフロー図を介して表すことができる。ワークフロー記述を定式化するXPDLXMLプロセス記述言語等の特殊言語が存在する。これらのルールは特定の組の条件/イベントが発生した際に実行すべきアクションの宣言である。マネージャモジュールMMは、全てのプロセス、すなわちプラットフォームの挙動および機能的態様を表すワークフローおよびルールを保存すべく構成されたプロセス記述データベースPDBを含んでいる。データベースPDBはさらに、例えば、ワークフローおよびルールにより扱われるデータモデルを含んでいる。当業者には知られているように、プロセス記述データベースPDBは例えば、任意の従来型ネットワーク在庫管理システムのカタログ部分に関連付けられてよい。図1のアーキテクチャは、多層エージェントモジュール、例えば各々がいくつかのエージェントA1、A2、A3を含む3層を含んでいる。同一レベルに属しているエージェントは相互に接続していても、または互いに独立していてもよい。これらは、より高いレベルのエージェントがあれば、これに結合されている。より低いレベルにおいて、エージェントは、制御下にあるネットワーク要素一般に通信ネットワークNとして示す、例えばATMスイッチ、あるいはメールサーバーアプリケーションまたはVASサーバーアプリケーション等の他のサービスアプリケーションAPP、すなわち携帯電話の留守番電話サービス等の付加価値サービスアプリケーションに結合されている。マネージャモジュールMMは、例えば、通信バスBを介してプラットフォームの他の動作支持システムOSSに接続されている。コーディネータとして機能しているマスターエージェントMA、あるいは実装方式の種類に応じて複数のマスターエージェント群MA図1に開示せずが、マネージャモジュールMMに関連付けられた多層エージェントアーキテクチャのルートに提供されている。各エージェントA1、A2、A3は、プロセスエンジンPEを含んでいて、プロセスエンジンPEを用いるいくつかのプロセスの実行責任を負う。プロセスエンジンは、ワークフローおよびルールのうちの一方または双方を実行するソフトウェアモジュールである。プロセスエンジンの外部設置は性能低下を引き起こし得る遠隔起動を有することを意味するため、プロセスエンジンPEは各エージェント内に埋め込まれていることが好都合である。好適には、各エージェントのプロセスは、同レベルまたはより高いレベルを有する他のエージェントにより、外部から起動することができ、各エージェントが起動エージェントに提供するサービスに対応している。任意の層におけるプロセスエンジンは、例えば、ワークフローと、ワークフローおよびルールの各々を管理可能なルールエンジンの組合せであることを意図されている。例えば、プロビジョニングプロセスはワークフローとして表す方が適している一方、アラームコリレーションはルールの組合せとして表す方が適している。可能ならば、ワークフローを利用する方が、ルールの矛盾およびルールの管理を取扱う煩雑さが含まれないため好ましい。図1に示す多層アーキテクチャは、異なるレベルでのプロセスの分割を可能にする。エージェントが配置可能であるレベルの数に制約がない。このように、可能な限り層の数を少なくすることと、分散型組織と集中型組織との間で自由にプロセスの割り当てを許すことのトレードオフを見つけるべくアーキテクチャを設定することが可能である。この分割はまた、業務ビューからシステムビューまで、異なるサービスビューを提供することも可能にする。以下において、ワークフローエンジンが好ましいと思われるが、ルールエンジンもまた適用可能である。エージェントマスターエージェントおよびサブレベルエージェントの両方を実行している各ホスト機は好適には、1個以上の制御エージェントCAを含んでいる。これらは、ローカルエージェントすなわち当該ホストで動作しているエージェントのリソース使用状況および性能の測定、並びにリソース管理の局所最適化の実行に責任を負うモジュールである。制御エージェントCAは、マネージャモジュールおよび他の制御エージェントに結合されていて、測定されたデータをマネージャモジュールおよび他の制御エージェントのうちの一方または双方へ送信する。以下にその構造を記述するマネージャモジュールMMは、プラットフォームの管理、構成、および制御に責任を負う。人間オペレータおよび外部OSSからの入力データを解析して、業績目標を満たすようにプラットフォームの構成を如何に調整するかを決定すべく構成されている。その主なタスクは以下の通りである。プロセス記述およびデータモデルをプロセスデータベースPDBからエージェントへ分散する、制御エージェントから提供された情報を用いて、ホスト機上でのエージェントの分散、ドメイン管理ネットワーク全体をエージェントに分割、性能監視を含むプラットフォームの状態を監視する、関連する制御エージェントとの対話を介してエージェントによるプロセスの実行用に割り当てられたリソースを最適に使用すべくアクションを実行するこれらのアクションの例として、エージェント間の負荷バランシングの変更およびワークフローの優先順位の変更、すなわち1個以上のエージェント内の待ち行列ジョブの再スケジューリングがある、他の動作支援システムと同様、外部システムとの対話。以下にその構造を記述するマスターエージェントMAは、プロセスの実行の最上位レベル調整の責任を負う。実際には、最上位層のエージェントに課せられたプロセスには、サブ層エージェントに課せられたサブプロセスが含まれていてよい。さらに、エージェント以外の外部エンティティとの対話または下位層エージェントにより分散的には容易にまたは効率的に実行することができないエージェント同士の調整を必要とする機能を提供すべく特徴付けられたプロセスが存在する。エージェントにより実行されるプロセスは、分散的に実行する必要があるものである。各エージェントA1、A2、A3は、任意のFCAPS故障、設定、課金、性能、セキュリティ機能等、任意のネットワークもおよびサービス管理機能すなわちプロセスを支援することができる。これにより、例えば、日中はサービスプロビジョニングにより多くのエージェントを投入し、夜間はネットワークの最適化により多くのエージェントを投入する等、タスクの優先順位およびリソースへのニーズに基づいてエージェントの実行時にタスクのカスタマイズおよびエージェントへの機能の再割り当てが可能になる。エージェントにプロセスエンジンPEの提供することにより、各機能すなわちプロセスによるリソースの使用状況並びに機能の起動生起を監視することが可能になる。これらのデータは、マネージャモジュールMMにより制御される自動プラットフォーム制御の主な情報源である。各エージェントA1、A2、A3は応答的および能動的な挙動の両方を示し、イベントにより生起されるだけでなく、プロセスを自発的に起動させる。好適には、エージェントモジュールは、例えばフォールトトレランス問題に対応すべく配備が容易になるように制御エージェントまたはマネージャモジュールにより処理装置間を移動可能である。図2に、本発明の好適な実施形態によるマネージャモジュールMMの内部構造を示す。集中型マネージャモジュールMMは、例えばサブモジュールに編成されている。サブモジュールのうち1個はMNGCNSコンソールであり、一般に、管理コンソールMNGCNSとして示される。好適な実施形態において、管理コンソールMNGCNSは、以下のものを含んでいる。-プラットフォーム性能データを保持している性能データベースPFMDBに関連付けられた監視コンソールMC、-目標および制約コンソールGC、-リ-アロケータコンソールRC、-管理用コンソールにより管理される管理データを含む管理データベースADBが関連付けられている管理用コンソールAC、-サービス生成環境コンソールSCC並びに-容量計画モジュール図示せず、-予測コンソール図示せず。目標コンソールGC、管理用コンソールACおよびサービス生成コンソールSCCは全て、プロセス記述データベースPDBに結合されている。マネージャモジュールMMは、目標および制約コンソールGCおよびリ-アロケータコンソールRCに直接結合されたリソース割り当てRAを含んでいる。リソース割り当てRAはまた、例えば管理用データベースADB、並びにプラットフォーム性能データを保持している性能データベースPFMDBに結合されている。好適な実施形態において、マネージャモジュールMMはさらに、監視データ取得モジュールMDMおよびプラットフォームコントローラPCを含んでいる。監視データ取得モジュールMDMは、プラットフォームコントローラPCから性能データベースPFMDBへ性能データを転送すべく構成されている。さらに、リソース割り当ては、例えば、外部OSSと管理プラットフォームとの間の対話を監視する外部インタフェースモジュールIに結合されていてよい。プラットフォームコントローラPCは、一般に、マネージャモジュールとエージェントとの間のメディエーターとして動作する。特に、プラットフォームコントローラPCは、マネージャモジュールの外部にあるマスターエージェントMA図示せず、およびリソース割り当てモジュールRAとの接続を実装し、監視コンソールMC、監視データ取得モジュールMDM、管理用コンソールACおよび管理用データベースADB、並びにプロセス記述データベースPDBに結合されている。目標および制約コンソールGCは、プロセス記述データベースPDBに保存されているプロセスに関連付けられていて、合わせて目標データと呼ばれる業務目標例:サービスレベル合意すなわちSLAおよび制約の規定を意図としている。サービスレベル合意すなわちSLAは、業務プロセスレベル品質の契約締結または単に同意された定量化である。SLAは、性能指標平均実行時間、パーセンタイル値等に基づいており、これらの指標の値がプラットフォームで保証される旨を宣言する。一般に、SLAはSLA目標性能指標およびSLA違約条項SLA目標と収集された性能データとの比較に基づくSLAコスト関数、例えばSLA違反の経済的違約の見積、を識別する特定の言語文法により記述することができる。SLAは一般的な業務プロセス例:ワークフローまたは1個以上のワークフロー属性において定義可能なその特化されたものの1個に関連付けることができ、その場合、特化されたものに対するSLAは通常、ルート業務プロセスのSLAを上書きする。制約は、リソース使用状況に関するデータに注目する。これらは、好適には以下のものを含んでいる。-保証すべき最低スループット、管理可能な最小数のネットワーク要素より理解し易い業務測定基準を用いるために、パーセンテージではなくスループットという用語を用いるのが好適であるで表される、予め割り当られたリソース、-割り当て可能なリソースの最大数大域的リソースのコストまたはパーセンテージで表され、デフォルト値は例えば50。業務制約を変更する際に、予め割り当られたリソースが割り当て可能な最大容量を上回るか否かを検証することが必要である。本発明の好適な実施形態によるリソースアロケータRA以下、リ-アロケータと呼ぶは集中型であって、プラットフォームを適応的に制御すべくエージェントへのリソース割り当てを管理する。これは、例えば以下を受容すべく構成されている。i目標コンソールGCからの業務目標。ii全てのホスト機の性能データ実行時間等およびハードウェアリソース使用状況を監視して、これらのデータを性能データベースPFMDBから取得する。iiiオプションとして、負荷テストから得た情報、すなわちワークフローをより多く使用した場合のリソース使用状況に関する測定値。iv利用可能なホスト機およびそれらのハードウェア特性正規化されたCPU速度、例えば標準性能評価協会によるSPECINT2000レートを用いたものに関するデータ。これは、全体的な処理能力例えば基準CPUの1時間当たり秒数で測定を監視する。v全てのホスト機のハードウェアリソース使用状況性能データベースPFMDBから。リ-アロケータRAは好適には、評価モジュールおよび決定モジュールの2個のサブモジュールを含んでいて、本明細書の以下にその例証的な記述および機能を述べる。評価モジュールは、-最上位レベルMAワークフロー実行要求、および-全てのエージェント内のワークフロー実行要求待ち行列に関するデータを受信すべく構成されている。さらに、評価モジュールは、過去のワークフロー実行要求の履歴的傾向および要素および複雑度に関する管理された通信ネットワークの傾向を分析すべく構成されている。決定モジュールは、過去情報に基づいて、プラットフォームが後述するいくつかの基準に従い全ての要求に対応可能か否かを決定すべく構成されている。プラットフォームが全ての要求を管理することが不可能な場合、決定モジュールは、例えば警告メッセージを送信、どのアクションが状況を改善できるかを決定すべく構成されている。特に、リソースは十分あるが、SLAが完全に満足されていない場合、決定モジュールは処理すなわちワークフロー実行をプラットフォーム全体にわたり再配分させるべく構成されている。好適には、これらのアクションは、ワークフローの異なるインスタンスに関連付けられた制約および優先順位を考慮している。管理用コンソールACは、例えば、少なくとも以下のうち一組を定義および監視することを意図している。iプラットフォーム、すなわち分散エージェントによるプロセスの実行の処理能力を保持するホストHのハードウェア構成。例えば、新規のホスト機が所定のホスト群に追加された際に、自動的にプラットフォーム全体に結合される。これは、例えば、ホストが自身の存在を通知するか、または、管理用コンソールが例えばGUIを介してオペレータにより入力されたコマンドを受信することによりホストHを認識するためである。iiソフトウェア分散/割り当てを規定するためのGUIすなわち目標および制約コンソールGCにおける制約に関するデータを受信するインタフェース。特に、これを用いて、ホスト機群を例えば以下に基づいて設定する。-地理的制約例えば、特定のワークフローは、ある領域にインストールされているが別の領域にはインストールされていないエージェントだけで実行することができ、あるいは、特定のホスト機だけで実行することができる、-階層的制約例えば、特定のマシンでは第2レベルのワークフローのみ動作可能である。-業務制約すなわち、特定の種類のプロセスに対する制約。iiiワークフロースケジュール例えば、サービスプロビジョニングワークフローは朝の時間帯にのみスケジュールされる。リ-アロケータコンソールRCは、リソース再割り当てポリシ、すなわち、業務制約および監視されたデータに基づいて業務目標の満足度を最適化すべくリソースをいつ、どのように再割り当てするか、の命令を規定すべく構成されている。リ-アロケータコンソールでは、集中型および分散型制御の両方のポリシを入力することができる。特に、以下の定義が可能である。i最高レベルのSLA満足度に達すべく、いつ、どのようにワークフロー優先順位に作用すべきかを規定する、集中制御用のルール。これらのルールは、管理されたプラットフォームを全体として見てすなわち、マシンに対して直接的には作用しない、リソース割り当てモジュールの全ての入力データおよび予測的データに基づいて作用する。iiローカルソフトウェアおよびハードウェアのリソースの使用状況を最適化する目的で、関連CAスレッド並列度およびロードバランシングを通じて単一エージェントに作用する、分散制御用のルール。iiiルールに関する複雑な式を計算する機能。監視コンソールMCは、以下のような監視情報を閲覧すべく構成されている。i定時例:1日当たり平均スループット、待ち行列例:1日当たりの要求数、平均実行時間例:1日当たり、目標が設定された全ての業務トランザクションの期限。ii合意されたSLA指標の測定値間の差違に関する、サンプリング期間にわたり計算されたSLAの状況違反したものは強調表示、および関連コスト関数の評価。iii全てのワークフローにおけるハードウェアリソースの使用状況、例えば秒単位でのCPU使用量および使用RAMのうちの一方または双方単一レベルおよびそれを下回る全てのレベルについて。これは、全てのホスト機が他とは計算能力が異なるため、ハードウェアリソースの使用状況、例えばCPU使用量、は基準CPUに正規化される。ivアカウント情報。全てのワークフローにおいて使用されたリソース合計に対するパーセンテージ、およびコストに関して。監視コンソールMCにより、階層的に、ワークフロー特に、ワークフローの全てのブロックの性能およびリソース使用状況を閲覧することが可能になる。全てのSLAについて、リソースの使用が多いために、最適化する価値があるワークフローについてレポートを提出することが可能である。ワークフローの異なるレベルに他の測定点が設定された場合、それらはMCにも提示される。また、MCは、ワークフローにより使用されたリソースに関して、支払い請求に関する情報を表示する。サービス生成環境コンソールSCCは、PDBにおけるプロセス、すなわち管理プラットフォームにおいて提供される全ての業務機能を定義、生成、および変更すべく構成されている。これは、本タスクの実施を容易にすべく、グラフィックインタフェースに基づいている。本コンソールもまた、ワークフローに新規の監視点を挿入可能にしている。さらなる実施形態において、MMモジュールにより管理されるデータはまた、MMモジュールに予測コンソールおよび容量計画モジュールを追加することにより、有用な容量計画を実現するために用いられる。予測コンソールは、有用な容量計画活動を実現するための使用状況予測を設定すべく構成されている。本コンソールの入力は以下の通りである。i期待スループット、およびiiネットワークホストの期待個数および種類この数値は、プロセス記述データベースにおけるデータの予測として計算することもできる。容量計画モジュールは、時間経過に伴いハードウェアリソースを保証すべく構成されている。これは、予測コンソールおよび他のコンソール目標および制約コンソール、管理用コンソールおよびリ-アロケータコンソールから入力を受信して、リソースの可用性を確認すべく構成されている。リソースが十分でない場合、容量計画モジュールは、予想される増加傾向に対処するために必要なハードウェアの量について、コンソールのオペレータに警告すべく構成されている。本モジュールは、以下のうち少なくとも1個を含む一組のパラメータに基づいて分析を行う。i期待スループット履歴傾向に関して、ii全てのワークフロー特に第一レベルのワークフローのリソース使用状況の情報、iii地理的制約。容量計画モジュールは不確実なデータ特に長期データに基づいているため、主に通知目的で構成されている。将来のニーズを強調することができるが、好適には割り当てRAと対話することはない。図3に、ホストの全体的な性能および当該ホストで動作する全てのエージェントの制御に責任を負うエージェントモジュールAおよび制御エージェントCAを含むホスト機の内部構造の例を示す。各エージェントAは、以下の構成要素のうち少なくとも一組を含んでいる。-ワークフロー待ち行列または待ち行列WFQ。これは、各々の下位待ち行列が同一優先順位の要求を保持している多レベルの優先順位待ち行列である。エージェントへ送信された各々のワークフロー要求は、自身の優先順位に基づいて対応する下位待ち行列に挿入される。図3において、異なるワークフローをWF1、...、WFnで示す。下位待ち行列内でワークフロー要求の欠乏を避けるため、待ち行列WFQは、例えばタイムアウト基準に基づいて、下位待ち行列内の要求について優先順位の更新を実施する。待ち行列WFQ上の情報、特に以下のものが待ち行列WFQに関連付けられている。各種のワークフローについて測定されたワークフローのCPU消費時間これらのデータはPFMDBから取得されたを加算して計算された推定CPU消費時間、特定種類のワークフローが他のエージェントにより実行されることを要求される速度例:ワークフロー/時間要求はエージェント内の待ち行列に入れられるを統計的に推定する、要求入力速度、-ワークフロー待ち行列WFQに関連付けられたワークフロースケジューラWFS。これは、待ち行列に含まれるワークフローWFnをそれらの優先順位に基づいてスケジューリングすべく構成されている。エージェントの1個以上のプロセスエンジンがワークフローを実行する準備ができる都度、スケジューラは、待機中のプロセスエンジンスレッドの1個へ待ち行列内でより高い優先順位のワークフローを送信する。-ワークフロースケジューラWFSにより制御される複数のプロセスエンジンスレッドTH1、...、THn。全てのエージェントは、設定可能な個数のワークフローを同時に実行することが可能である。これは、エージェント内で複数のプロセスエンジンスレッドTH1、...、THn独立エグゼキュータを設定することにより実現される。各プロセスエンジンスレッドTH1、...、THnは、同時に1個のワークフロー、例えばJava言語で実装されたスレッド、を実行することが可能である。制御エージェントCAは、好適にはソフトウェアで実装された以下の構成要素の少なくとも一組を含んでいる。-リソースモニタRM:本構成要素は、自身の制御下にあるエージェントにおけるハードウェアおよびソフトウェアのリソース使用状況に関するデータを監視および収集すべく構成されている。その役割は、ホスト上でのエージェントエージェントホストを含む現在のリソース使用状況およびワークフローの実行によるCPUとメモリ消費の両方を測定することである。測定された値は、マネージャモジュールMMおよびスレッドコントローラTCへ送信される。-スレッドコントローラTC。これは、リソースモニタRMおよびワークフロー待ち行列WFQに結合されていて、局所性能を制御すべく構成されている。これは、能動的にエージェントスレッドの並列性を管理すること意図している。これは、入力として、待ち行列内で実行待ちであるワークフローの個数、実行中のマシンのPEスレッドのCPU使用量およびPEの総数を受信すべく構成されている。上記の入力に基づいて、スレッドコントローラTCは、最適なワークフロー実行並列性を実現すべくプロセスエンジンスレッドPEスレッドの個数を増減させる。これは、例えば、実行待ちであるワークフローを待ち行列が含んでいる場合、PEスレッドの総数が許容された最大個数を下回る場合、かつCPU使用量が指定された閾値を下回る場合に、新規のPEスレッドを生成する。しかし、エージェントが、外部リソース装置、ネットワーク機器等との直接対話を担当している場合、PEスレッドの許容最大個数は外部リソースの許容可能な並列性により制限される。さらに、いくつかのPEスレッドが所定の期間使用されていないことがわかった場合、スレッドコントローラはPEスレッドのガーベージコレクタを実行する。-プロセスエンジンスレッドに結合されたディスパッチャD。本構成要素は、他のエージェントへワークフロー実行要求を送信すべく構成されている。各PEスレッドはディスパッチャDを用いてそのような要求を送信する。ディスパッチャは、例えば、以下のようにロードバランシングアルゴリズムを用いて、他のエージェントへ要求を送信する。これは、要求を送信するための最適なエージェントを、2段階で選択する。第一に、CPUおよびメモリの観点から負荷がより少ないホストを選択する。第二に、エージェント待ち行列の推定CPU消費時間の最小量に基づいて選択されたホストの利用可能なエージェントを選択する。制御エージェントCAは、好適には自身の側に、好適な実施形態による重要な特徴を有している。これらは、自身のプロセススレッドの並列性を能動的に管理する局所最適化ことが可能である。待ち行列の再順序付けおよび並列性管理の二つの能力が合わさって、本発明の一態様による適応型機構の基礎をなす。図4に示す本発明の別の実施形態によれば、例えば、ホスト機H上に単一のエージェントモジュールAが存在するならば、リソースモニタRM、スレッドコントローラTC、および、ディスパッチャDをエージェントモジュールに付加することができる。本発明のシステムの好適な実施形態は、移動特性を有するエージェントを実装するJADEJavaエージェント開発フレームワーク、プロセス定義を行なうXPDLXMLプロセス定義言語、およびSharkなどのXPDLワークフローエンジンを使用して実装される。以下に、動作を示す図と共に、リソース割り当てモジュールについてより詳細に記述する。リ-アロケータRAは、制約プロセス、データ操作、および設定変更の機能を有するエキスパートルールベースシステムとして実装することができる。管理されたネットワーク、外部システム、人間の知識、および内部分析から得られた全てのデータ、制約、およびルールがその知識ベースを構成しており、これを関連する知識データベースにより具体的に表現することができる。リ-アロケータモジュールRAは、シナリオの状況に応じてケース毎に設定可能な所定の分析期間で評価および決定モジュールを実行する。第一に、リ-アロケータは、後続する期間のために予測されたサービス/機能要求の個数を評価すべくバスBを介してプロセス要求に関するデータを外部システムから取得し、この情報を関連する知識データベースに保存する。次いで、決定モジュールは、所定の業務目標を最適な仕方で達成すべく実行されるアクションを見出すためにリソース再割り当てルールを有効化する。詳細には、各々の期間Tで、リソース割り当てモジュールは、履歴情報に基づいて、待ち行列に入れられた要求の個数および予測された要求の個数を考慮する。当該モジュールは、利用可能なハードウェアリソース主にCPUとRAMの量の第一の評価を実行する。これらのデータは、後述するバックグラウンドエラー訂正を考慮しつつ、当該期間の終わりで実際に測定されたデータを使用して調整される。以下のデータが統計方法で集められる。-各々のワークフローについて各々のレベルにおけるCPUニーズ、および-下位ワークフロー要求の観点での最上位レベルのワークフローの合成アーキテクチャの全てのレベルに関連付けられたCPUニーズがあれば、この情報はまた、地理的制約があればこれを考慮しなければならない。収集された情報は、時刻tにおける待ち行列の長さと内容、および期間t,tTの間に予想により期待される要求の個数に相関付けられて、後続する期間の組または複数の期間の後に置かれた期間の組として意図される後続期間におけるCPU能力の合計必要量を計算する。次いでCPUの総量、すなわち新たな期間レベルおよび地理的制約を考慮してに対して要求される計算能力が、利用可能なCPU能力と比較される。これが十分でない場合、コンソールに警告新規ハードウェアを要求するが生成されて、ワークフローの優先順位により負荷をどのように扱うかが決定される。利用可能なハードウェアリソースに関するデータを調整するためにバックグラウンドエラー訂正が考慮される場合、各期間毎に全てのワークフローについて、かつ全てのホスト機について、先行期間で使用されたCPUの量が、異なるワークフローにより使用されたCPUの量と比較される。この値を用いて、後続期間でのCPUの実際の利用可能性を修正するために用いる。本発明による方法およびシステムでは、優先順位に基づくポリシを使用することにより、異なるレベルの優先順位がある。各期間T毎に、決定モジュールは管理アルゴリズムに従い、業務目標を達成すべく優先順位付き待ち行列を操作することができる。欠乏を避けるために、ワークフロー要求が優先順位の低い待ち行列で過大な時間を消費した場合、その優先順位が自動的に更新されて、より高い優先順位付き待ち行列へ要求が移動されるようにする。本発明の好適な実施形態によれば、管理アルゴリズムは、ステップ毎にリソース設定を改良して、漸進的な挙動により最適設定に到達しようとする適応型ソリューションに基づいている。現行アプローチの結果は、平均的なワークフロー実行時間の少なくとも2~3倍合理的な期間は、アプリケーションの状況に応じて5分~1時間以上の範囲で変動し得るである分析の期間を用いて保証される。優先順位は、以下を考慮しつつ、ワークフローの全ての実行に関連付けられている。-同意されたSLAリスクの大きいワークフローほど、高い重みを維持するの状況、-ワークフローの目標コンソールにおいて規定された初期優先順位、並びに各SLAの優先順位および経済的意味、-ワークフロー用の予め割り当られた最小限のリソース量、-割り当て可能なリソース最大量SLAの初期交渉の間に規定される。これは、優先順位が時間依存であることを意味する。ワークフロー性能のインスタンスがSLAに近づいているすなわち、性能が低下している場合、その優先順位がより高く設定される。プロセスエンジンの代わりに、例えば統計技法によるCPU評価等、機能の実行を定義および測定する任意の手段を用いてもよい。以下において、提唱されたアーキテクチャに基づく性能適合シナリオの例を示す。最適化すべきリソースはCPU負荷である。現行シナリオによれば、最上位レベルのワークフローは、時間t>>ΔTΔTは観測期間内に完了されるワークフローのパーセンテージで表現された優先順位特性により特徴付けられるSLAが関連付けられた業務である。最後の仮定は、プラットフォームに対し期間t内に再調整するのに十分な時間を与えるために必要である。最上位レベルのワークフローは、多くの下位ワークフローから構成されている。全てのワークフローは、実行前の待ち行列内での待ち時間およびワークフローCPU時間スライスに影響を及ぼす優先順位特性を有している。入力データは以下の通りである。-各ワークフローおよび各ホスト機のCPU負荷秒、-制約、すなわち同一ワークフローはホスト機郡の一部だけで実行可能である、-下位ワークフローの観点からの第一レベルのワークフロー構成、-過去のΔT期間におけるワークフロー到着数、-過去のΔT期間におけるワークフロー実行回数。目標は以下の通りである。-次のΔT期間で全てのワークフローを実行するのに計算リソースが十分であるか否かを予測する、-計算リソースがSLAを遵守するのに十分であるか否かを予測する、-ワークフローの実行優先順位がSLAの遵守に到達するための適合。性能適合プロセスは、全てのΔT期間で実行された監視に基づいており、最短プラットフォーム適合時間を表す。図5のフロー図を参照するに、全てのΔT期間で実行された監視の例をレポートしており、割り当てRAにより各ΔTについて以下のステップが管理される。1各ホストでの各ワークフローのCPU負荷の評価ステップ100。これは、ホストサンプル上でワークフローの負荷試験を実施して、CPUドキュメンテーションを用いることにより達成される先験的予測。得られた値は、ワークフロー実行に対する制約を考慮しつつ、先行ΔTで実行された各ワークフローに関連付けられた実際のCPU時間を使用して微調整することができる、2未だ待ち行列で待機しているワークフローに加え次のΔT内に到着が予想されるワークフローを実行するために必要なCPU時間の予測ステップ120、3計算リソースの観点から必須であるホスト群を識別すべく、ステップ120で評価されたCPU時間を、利用可能なCPU時間と比較ステップ140して、影響を受けるSLAに第一ワークフローを関連付ける。必要とされるCPUリソースが利用可能なCPUリソースより大きい場合、CPUリソース不足を通知するステップ150、4各SLAについて、SLA要求を満たす最小数のワークフローを実行するために必要なCPU時間を予想ステップ160し、次いでこれを利用可能なCPU時間と比較ステップ170して、SLAを遵守するために計算リソースが十分か否か判定する、5上のステップにおいて、ワークフローを実行する現行のプラットフォーム優先順位設定がSLA制約に対応できないとされた場合、計算リソースの観点からワークフロー重みを考慮しつつワークフロー優先順位のバランスを見直して、ワークフロー優先順位の適合手法ステップ180を通じて設定を調整しなければならない、6優先順位の適合が必要でない場合、または、優先順位適合が実施された場合、システムは性能適合プロセスを終了させ、次のΔT監視期間を待つ。性能適合プロセスの予測手法の例を以下に詳述する。以下の定義を行なう。-ΔT:監視期間および最短システム適合時間、-LWfn:ホストn上でのワークフローwfの実行に要するCPU負荷秒。これらの値は、先験的にまたは、自動学習方式を用いて推定し、次いでプラットフォーム動作の間に調整することができる。例えば、ある時間にわたる移動平均による。-VWfn:ホストn上のワークフローwfに対する制約であって、次式で与えられる。次のΔT内に予見される全てのワークフローを実行するために必要な予想CPU時間は次式で計算される。ここで、gは、集合WFg内の全てのワークフローについて同等なホストのグループである。これは、集合WFgに属する各ワークフローが、グループgの中の1個のホストにより同じ確率で実行できることを意味している。lwfはグループgのホスト上のワークフローwfを実行するために必要な予想CPU時間であり、次式で与えられる。NEPwfはワークフローwfの予見される実行回数であり、次式で与えられる。NEPwfg=NQwfNAPwfgここで、NQwfは、次式により第一のレベルワークフロー呼び出しの観点で表された実行待ち行列のワークフローwfの総数である。NAPwfgは後続するΔT期間において予見されるワークフローwfの総予想数であり、次式で与えられる。ここで、Piは先行するΔTiに到着したワークフローの重みである。NAwfl1,inは、期間ΔTiにホストnに到達した、第一のレベルのワークフローwfl1の下位ワークフローであるワークフローwfの数である。上述の三種の目標を参照するに、予想および適合ステップは以下のように実行される。利用可能なCPU時間が後続するΔTで予見されるワークフローを実行するのに十分であるか否かを予想すべく、各々のグループgについて、以下のようにCPU時間CpuTimePgと、グループgで利用可能なCPU時間との比較が実行される。もし、ならば、システムは全てのタスクを実行するための十分な計算リソースを有している。ならば、システムはより多くのCPU時間を必要するため、a計算リソースの観点から必須であるホストのグループgbこのようなリソース不足でより重大な影響を受ける恐れのあるSLAに関連付けられた第一レベルのワークフローを含むメッセージを送信する。計算リソースがSLAを遵守するのに十分であるか否かを予想すべく、第一レベルのワークフローwfl1で規定された各SLAについて、SLAを遵守するために後続するΔTで実行されるwfl1の個数NSLAwfl1が計算される。SLAが、時間t但しt>>ΔT内に実行されるワークフローwfllのパーセンテージp[]として規定されている場合、NSLAwfllは次式で与えられる。ここで、NSLAQwfl1は、各ΔTiについて、ΔTi内に到着して未だ待ち行列内で待機しているワークフローwfl1の数と、SLAを遵守すべくこれらのワークフローを期限内に完了させるために依然として利用可能なΔTsの数n=t-kΔT/ΔTとの比の和により与えられる。kは、ワークフローが到着してから待ち行列内で待機している間のΔTsの数であり、NSLAPwfllは、次のΔTに到着するワークフローwfllの予想数と、SLAを遵守すべくこれらのワークフローを完了するために依然として利用可能なΔTsの数との比すなわちt/ΔTである。従って、ワークフローwfl1がSLAを遵守すべく必要とされるCPU時間は、次式で与えられる。ここで、ここでかつここで、NEwfwfllgは、ワークフローwfl1の各々の実行に対してホストグループgで実行されるワークフローwfの予想数であり、次式で与えられる。再び、ならば、システムはワークフローwfl1がSLAを遵守すべく十分な計算リソースを有している。である場合、システムは、ワークフローwfl1がSLAを遵守させることができず、従って、以下の節に述べるワークフロー優先順位適合手法が適用される。ワークフロー優先順位適合手法は、SLAに関連付けられた少なくともタイプAの第一レベルワークフローが存在する場合に適用され、このとき次式が成立する。一方、他のタイプの第一レベルワークフローの場合、次式が成立する。本手法は各種のアクションで構成され、以下にその少なくともいくつかの例を複雑度の順に記載する。aタイプAワークフローの優先順位を上げる。bタイプBワークフローの優先順位を下げるc各々の第一のレベルワークフローに重みを関連付けてアクションaまたはbを実行すべく最も関連のあるものを選択するd違約条項が時間とともに増大しないSLAについて、先行ΔTにおいて既にSLAの遵守に失敗したワークフローの優先順位を下げて、e違約条項が時間とともに増大するSLAについて、先行ΔTにおいてSLAの遵守に失敗したワークフローの優先順位を上げる。アクションdおよびeは、目標および制約コンソールGCで規定されたSLA違約のコスト影響を最小化しようと試みる機能に基づいている。本手法は便利な点として、各々のワークフローに割り当てられるCPU時間の最大量等、リソース使用に対する制約を考慮し続ける。これは、予約されたCPU時間の最大量を既に使用しているワークフローの優先順位をさらに上げることができないことを意味する。各ワークフローの正確なコストの集計が重過ぎる場合、別の可能な方法として、実行された構築ブロックの数をエージェントが所定の間隔例えば5分毎で集計してシステムのリソース使用状況例えばCPU使用との相関を求めることができる。負荷が過剰な状況下にあるコンピュータシステムの性能を推定するために多変量回帰技術がしばしば利用される。この選択は、容量を超えて実行された多くのインフィールドOSSの回数の挙動の分析に基づいている。その結果、CPU使用等、大多数のOSSの共通の性能尺度を線形回帰によりモデル化できることがわかった。システム応答時間は、例えば、適度な指数法則に従い増大する。このように、システム性能予測の下限は、システムリソースデータおよびワークフロー実行データに基づいて多変量線形回帰技術により得られる。簡単な多項式モデルの例を次式に示す。Ucpu=a0a1NAa2NBa3NCここで、Ucpu=エージェントのCPU使用NA=構築ブロックAの実行回数NB=構築ブロックBの実行回数NC=構築ブロックBの実行回数である。好適には、全ての尺度特にSLA定義は、一貫した方法で適合を最適化するための経済的数量で表現すべきである。例えば図6に、本発明による柔軟性およびスケーラビリティに特徴を有する3層サービスプロビジョニングシナリオの設定を示す。この例では、最下位層のエージェントは、ネットワーク要素との対話の責任を負っており、リソースプロキシと呼ばれ、RPl、RP2、RP3で示す。オファー1と名付けられた広帯域サービスは、IP接続を得るべく、アクセス装置例:ADSL設備を含む通信ネットワーク、ATMバックボーンおよびBAS広帯域アクセスサービスを介して提供される。RPにより提供されるサービスの例として、ポートの設定、交差接続の生成、接続属性の変更がある。その各々は、設備へ/から、送信および受信のうちの一方または双方をされる一連の基本命令を含んでいてよい。AA1、AA2、AA3は各々、ADSL設備Eエンドツーエンド回路の端点Aの画像を表すリソースプロキシRP1、ADSL設備Eに接続しているATMスイッチSWの画像を表すリソースプロキシRP2、およびBASエンドツーエンド回路の端点Zの画像を表すリソースプロキシRP3を管理するエージェントである。サービスオファー1の提供活動に関わる多レベルワークフローを図7に示す。レベル1すなわち最上位レベルのワークフローは、2個のステップまたはタスクを含んでいて、マスターエージェントMAにより実行される。第一のものADSL接続性は、エージェントレベルAA1、AA2、AA3で実行されるレベル2のワークフローの実行を必要とする一方、第2のもの、すなわちメールボックスタスク本例では詳述しないは外部プラットフォームにより実行可能である。ADSL接続性タスクは従って、一連のレベル3ワークフローを含むレベル2ワークフローであり、リソースプロキシレベルRPl、RP2、RP3で実行されるベンダー依存の技術である。レベル3ワークフローは、リソースプロキシにより通信ネットワーク設備側で実行する必要がある一連のコマンドを含んでいる。レベル2ワークフローADSLポートベンダーA生成を拡張したことによるレベル3ワークフローの例を図7に示す。監視コンソールMCは、各ワークフローのリソース使用状況CPU、RAMおよび経過時間を測定して、特定のベンダーまたは特定のワークフローに問題があれば強調表示する。メールボックスが無い点以外はサービスオファー1と同様の別サービスオファー2が存在すると仮定すれば、目標コンソールは、SLA制御ルールおよび関連コスト関数を用いてオファー1およびオファー2に対してSLAを規定することができる。サービスオファー2に対するSLAがより重要例えば、オファー2に関連付けられたコスト関数は平均実行時間である1秒を超えた秒数に等しく、オファー1に関連付けられたコスト関数は平均実行時間である4秒を超えた秒数に等しい場合、オファー2に対する優先順位はオファー1の優先順位より早く増大する。これは、同数の要求に対してハードウェアリソース例:CPUが不足している場合、オファー2のスループットがオファー1のスループットより高いことを意味する。従って、プラットフォームは、外部オペレータにより設定されたにせよ、またはエージェント飽和によるものにせよ、自身の目標に達するようリソース使用を調整する。当然ながら、本発明の原理は変わらず、実施形態の形式は単に非限定的な例として記述図解されたものに関して各種の変更が可能であるが、これらは添付の特許請求の範囲により規定される本発明の保護範囲から逸脱するものではない。"