JP5068313B2 - サービス・インフラストラクチャのオン・デマンド合成及び分解のための方法及び装置 - Google Patents

Description

本発明は、ネットワーク化コンピュータ・システムに係り、さらに詳細に説明すれば、ネットワーク化コンピュータ環境内のソフトウェア及びシステム管理に係る。

コンピューティング・システムのクラスタ、データ・センタ及びグリッド・システムのような分散環境は、多数の資源及びサービス・コンポーネントを管理することを必要とする。かかるシステムのユーザに対し提供される典型的なエンド・サービスは、当該ユーザにとって関心の高いエンド・サービスを連携して提供する、複数の資源及びサービス・コンポーネントの合成（composition）を必要とする。かかる複数のコンポーネントの合成、すなわち複合サービス（composite services）は、これらのコンポーネントが整合的な態様でインタフェースするように、これらのコンポーネントの注意深い構成（configuration）及び配備（deployment）を必要とする。その結果、かかる複合サービスが配備され、初期化されると、ユーザによって提供されたワークロードを処理し、コンポーネント・レベルの障害を優雅に処理し、当該ワークロードの変動を処理しつつ堅固なサービスを提供することができる。

コンポーネントからかかる合成を実現することは、多数の異種の資源及びサービス・コンポーネントの調整（orchestration）を必要とする。種々のタスクを手動的に管理することは、面倒であるばかりか、間違いを起こしやすい。資源が複数の管理可能ドメインに属する場合、複雑さの度合いが増加する。グリッド・ベース・システムは、複数の管理可能ドメインにわたる資源共有を促進することができるという利点があるが、システム管理者の観点からすると、グリッド・ベース・システムは、管理するのが遙かに困難である。その１つの理由は、最新のシステム管理技術が、ミドルウェア及びグリッド技術の進歩に対応していないということにある。単一又はクラスタ・ベース・システムの管理については、一定の成果が得られた。しかし、かかるシステムについてさえ、システム管理者は、既存のインフラストラクチャ上に新しいサービスを構成し且つ配備するか、又は既存のサービス及びソフトウェア・スタックのライフサイクルを管理する場合に、遙かに高いレベルの複雑さに直面する。複雑なアプリケーション環境、例えば、複数のビジネス・プロセスによって形成されたワークフローの調整を必要とする環境では、状況は遙かに悪くなる。このような場合、配備及びライフサイクル管理のソリューションは、関係する複数の層の総合的ビューを取る必要があるが、現在のシステム管理技術は、かかるソリューションを構築するのに必要な手段を提供しない。

ソフトウェア・コンポーネントの構成及び配備用の伝統的な方法は、コンポーネントの要件に関するドメイン・エキスパートの知識、ミドルウェア及び基礎をなすインフラストラクチャの使用可能性、並びに全体的なＩＴ環境に大きく依存する。システム管理者は、この背景的知識を使用して、先ず、既存のインフラストラクチャを構成し、次に、新しいコンポーネントを成功裡に配備することができるように、当該新しいコンポーネント用の構成及び配備ステップをカスタマイズしなければならない。分散コンポーネントの場合には、かかるアプローチは、多大な時間を要し、間違いを起こしやすく、しかも大規模なインストールに拡張できないことがある。さらに、かかるアプローチは、システム管理者が配備ワークフロー内の重要な要素であるために、自動化には適していない。

システムの大きなインストールを構成し且つ管理する能力は、情報技術コミュニティにおける活発な研究領域であった。ローカル構成（LCFG）は、現用中のスクリプト・ベース・システムであって、中央データベース内に格納された構成情報に基づいて機械を動的に構成するものである（Anderson, P., "Towards a High-Level MachineConfiguration," LISA, 1994）。この情報は、システム上に構成すべきネットワーク、システム及びサービスに関係する。Smart Framework for Object Groups（SmartFrog）は、分散アプリケーションの構成及び配備を指定するための公知のシステムである（Goldsack, P, Guijarro, J, Mecheneau, G, Murray, P, Toft, P,"SmartFrog: Configuration and Automatic Iginition of DistributedApplications," HP OVUA 2003）。SmartFrog は、アプリケーションの構成及びアプリケーション間の依存関係を指定するための言語を提供する。SmartFrog は、分散システム上でアプリケーションを処理及び配備するためのインフラストラクチャを提供する。GridWeaver プロジェクトは、大規模システムの構成管理を行うために LCFG 及び SmartFrog 技術を組み合わせるという概念を調査中である。Organization for the Advancement of Structured Information Standards（OASIS）は、ウェブ・サービスを利用して、分散資源を管理することを調査中である。グリッド・フォーラムは、Configuration Description, Deployment, and Lifecycle Management（CDDLM）活動の一部として、仕様言語を標準化することを試行中である。

幾つかの技術は、サービスを提供することに関与中の、個別的な Java 2 Platform Enterprise Edition（J2EE）コンポーネントをモニタするための手段を提供する（「Java」は、サン・マイクロシステムズ社の登録商標）。この技術は、システム管理者が性能をモニタし、障害を識別し、性能ボトルネックを検査することを支援する。
Anderson, P., "Towards a High-Level MachineConfiguration," LISA, 1994 Goldsack, P, Guijarro, J, Mecheneau, G, Murray, P, Toft, P,"SmartFrog: Configuration and Automatic Iginition of DistributedApplications," HP OVUA 2003

従って、当分野では、前述の従来技術に関連する問題を解決することが要請されている。

実施形態は、一の複合サービスを作成するためのコンピュータ実装方法、装置及びコンピュータ使用可能なプログラム・コードを提供する。前記複合サービス用の一の要求を受け取ることに応答して、サービスを管理するために使用される１セットのアクティブ・オブジェクトを利用して依存関係（dependency）を識別することにより、識別された依存関係を形成する。前記識別された依存関係は、前記複合サービスの要件を指定する。前記複合サービスは、複数のコンポーネントを有する。前記識別された依存関係を使用して前記複合サービス用のコンポーネントを識別することにより、識別されたコンポーネントを形成する。前記識別されたコンポーネントを使用して、前記複合サービスを作成する。

本明細書で使用する「物理資源」又は「資源」という用語は、コンピュータ・サーバ、コンピュータ・ネットワーク、ファイル・システム等のハードウェア資源を意味する。かかる資源は、オン又はオフに切り替えたり、共有されるか又は専用モードで使用したり、物理的位置を有することができる。「コンピュータ・サービス」という用語は、１つ以上の資源上で動作するコンピュータ・プログラムによって提供されるサービスを意味する。

実施形態は、ソフトウェア・コンポーネント及びサービスの管理に対するソリューションを提供する。図１及び図２は、実施形態を実装することができるデータ処理環境を例示する。図１及び図２は、単に例示的なものであって、異なる実施形態を実装することができる環境に関する如何なる制限をも意味するものではない。図示の環境に対し多くの修正を施すことができる。

図１は、実施形態を実装することができるデータ処理システムのネットワーク図である。ネットワーク・データ処理システム１００は、コンピュータのネットワークであって、その内部で実施形態を実装することができる。ネットワーク・データ処理システム１００内に含まれるネットワーク１０２は、ネットワーク・データ処理システム１００内で相互に接続される、種々の装置及びコンピュータの間の通信リンクを提供するために使用される媒体である。ネットワーク１０２は、有線、無線通信リンク又は光ファイバ・ケーブルのような接続を含むことができる。

サーバ１０４及び１０６は、ストレージ・ユニット１０８と共にネットワーク１０２に接続される。また、クライアント１１０〜１１４が、ネットワーク１０２に接続される。クライアント１１０〜１１４は、パーソナル・コンピュータ又はネットワーク・コンピュータとすることができる。サーバ１０４は、ブート・ファイル、オペレーティングシステム・イメージ及びクライアント１１０〜１１４に対するアプリケーションのようなデータを提供する。この例では、クライアント１１０〜１１４は、サーバ１０４に対するクライアントである。ネットワーク・データ処理システム１００は、図示されていない追加のサーバ、クライアント及び他の装置を含むことができる。

ネットワーク・データ処理システム１００は、ネットワーク１０２を有するインターネットである。周知のように、インターネットは、ネットワーク及びゲートウェイの世界的な集合を表し、互いに通信するために伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）スイートを使用する。インターネットの中心は、データ及びメッセージを経路指定する、何千もの商用、政府用、教育用及び他のコンピュータ・システムから成る、主要ノード又はホスト・コンピュータ間の高速データ通信回線のバックボーンである。もちろん、ネットワーク・データ処理システム１００は、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）等の、多くの異なるタイプのネットワークとしても実装することができる。図１は、１例として図示されたものであって、異なる実施形態のアーキテクチャ上の制限を示すことを意図するものではない。

図２は、実施形態を実装することができるデータ処理システムのブロック図を示す。データ処理システム２００は、図１のサーバ１０４又はクライアント１１０のようなコンピュータの１例であり、その内部には実施形態用のプロセスを実装するコンピュータ使用可能なプログラム・コードすなわち命令が存在する。

データ処理システム２００は、ノース・ブリッジ兼メモリ・コントローラ・ハブ（ＮＢ／ＭＣＨ）２０２及びサウスブリッジ兼入出力コントローラ・ハブ（ＳＢ／ＩＣＨ）２０４を含む、ハブ・アーキテクチャを使用する。処理ユニット２０６、主メモリ２０８及びグラフィックス・プロセッサ２１０は、ＮＢ／ＭＣＨ２０２に結合される。グラフィックス・プロセッサ２１８は、例えば、アクセラレィテッド・グラフィックス・ポート（ＡＧＰ）を介して、ＮＢ／ＭＣＨ２０２に結合することができる。

ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２は、ＳＢ／ＩＣＨ２０４に結合される。オーディオ・アダプタ２１６、キーボード及びマウス・アダプタ２２０、モデム２２２、読み取り専用メモリ（ＲＯＭ）２２４、ユニバーサル・シリアル・バス（ＵＳＢ）ポート及び他の通信ポート２３２、ＰＣＩ／ＰＣＩｅ装置２３４は、バス２３８を通して、ＳＢ／ＩＣＨ２０４に結合される。ハード・ディスク・ドライブ（ＨＤＤ）２２６及びＣＤ−ＲＯＭドライブ２３０は、バス２４０を通して、ＳＢ／ＩＣＨ２０４に結合される。ＰＣＩ／ＰＣＩｅ装置２３４は、例えば、イーサネット（登録商標）・アダプタ、アドイン・カード、ノート型コンピュータ用のＰＣカードを含むことができる。ＰＣＩはカード・バス・コントローラを使用するが、ＰＣＩｅはこれを使用しない。ＲＯＭ２２４は、例えば、フラッシュ型の基本入出力システム（ＢＩＯＳ）とすることができる。ＨＤＤ２２６及びＣＤ−ＲＯＭドライブ２３０は、例えば、統合ドライブ・エレクトロニクス（ＩＤＥ）又はシリアル・アドバンスト・テクノロジ・アタッチメント（ＳＡＴＡ）インタフェースを使用することができる。ＳＩＯ（Super I/O）装置２３６は、ＳＢ／ＩＣＨ２０４に結合することができる。

オペレーティング・システムは、処理ユニット２０６上で動作し、データ処理システム２００内の種々のコンポーネントを統制及び制御する。オペレーティング・システムは、Microsoft Windows XP（「Microsoft」及び「Windows」は、マイクロソフト社の登録商標）のような市販のオペレーティング・システムとすることができる。Java プログラミング・システムのようなオブジェクト指向のプログラミング・システムは、オペレーティング・システムと共に動作することができ、データ処理システム２００上で実行中の Java プログラム又はアプリケーションからオペレーティング・システムへの呼び出しを提供する。

オペレーティング・システム、オブジェクト指向のプログラミング・システム及びアプリケーション又はプログラム用の命令は、ＨＤＤ２２６のようなストレージ装置に置かれ、処理ユニット２０６による実行のために主メモリ２０８にロードすることができる。実施形態のプロセスは、例えば、主メモリ２０８、ＲＯＭ２２４のようなメモリ内、又は１つ以上の周辺装置内に置かれたコンピュータ実装命令を使用する、処理ユニット２０６によって実行することができる。

図１及び図２のハードウェアは、実装に応じて変わることがある。図１及び図２に示すハードウェアに加えて、又はそのハードウェアに代えて、フラッシュ・メモリ、それと同等の不揮発性メモリ、光ディスク・ドライブ等の、他の内部ハードウェア又は周辺装置を使用することができる。また、実施形態のプロセスは、多重プロセッサ・データ処理システムにも適用することができる。

幾つかの例では、データ処理システム２００は、オペレーティング・システムのファイル及び／又はユーザ生成データを格納するための不揮発性メモリ又はフラッシュ・メモリで構成される、パーソナル・デジタル・アシスタント（ＰＤＡ）とすることができる。バス・システムは、システム・バス、Ｉ／Ｏバス及びＰＣＩバスのような、１つ以上のバスから構成することができる。もちろん、このバス・システムは、異なるコンポーネント又は装置の間でデータを転送するための、任意のタイプの通信ファブリック又はアーキテクチャを使用して実装することができる。通信ユニットは、モデム又はネットワーク・アダプタのような、データを送信及び受信するために使用される１つ以上の装置を含むことができる。メモリは、例えば、主メモリ２０８又はＮＢ／ＭＣＨ２０２内にあるキャッシュとすることができる。処理ユニットは、１つ以上のプロセッサ又はＣＰＵを含むことができる。図１及び図２に示した例及び前述の例は、アーキテクチャ上の制限を意味するものではない。例えば、データ処理システム２００は、ＰＤＡの形式を取ることに加えて、タブレット・コンピュータ、ラップトップ・コンピュータ又は電話機の形式を取ることができる。

実施形態は、サービス・インフラストラクチャのオン・デマンド合成及び分解（teardown）のためのコンピュータ実装方法、装置及びコンピュータ使用可能なプログラム・コードを提供する。本方法は、クラスタ環境、データ・センタ環境及び共有グリッド環境のような分散環境上で、ソフトウェア・サービス及び資源コンポーネントを構成し且つ配備する。その結果、コンポーネントが互いに連携して、期待される態様で振る舞う一の複合サービスを提供する。自動管理及び制御は、コンポーネント・レベル及び合成フェデレーテッド・レベルで行われる。

一のソフトウェア・サービスは、ローカル及び／又は遠隔コンピュータ・ネットワーク上で動作するプログラム又はプログラムの集合によって提供されるサービスであって、一のサービス要求に対する部分的又は完全なソリューションを提供するが、要求元が当該サービスに関連する任意の管理タスク（例えば、構成、配備及びライフサイクル管理タスク）を実行することを必要としない。ソフトウェア・サービスの幾つかの例は、給与計算サービス、顧客関係サービス、サプライチェーン管理サービス、検索エンジン・サービス、電子メール・サービス、認証サービス、メッセージ・サービス、WebSphere（登録商標）アプリケーション・サーバによって提供されるような汎用アプリケーション管理サービス、データベース・サービス、ネットワーク接続サービス等を含む。

ソフトウェア・サービス管理は、サービス依存関係の分析、資源及び配備されるサービスの計画及びスケジューリング、構成管理、配備管理及び配備後のライフサイクル管理を含む。これらの管理機能は、それら自体がソフトウェア・サービスである。実施形態は、ユーザからのサービス要求に応答して、ソフトウェア・サービスの必要なインストール、構成及び配備が系統的に且つ制御された態様で実行されるように、これらの管理サービスを提供する。さらに、実施形態は、配備されたサービスが現に要求されたワークロード及び／又は期待される将来のワークロードによって望まれるレベルで実行され、そして当該配備されたサービスが必要とされないか又は保守が必要となる場合には、当該配備されたサービスがオフライン化されるか又は終了されるように、当該配備されたサービスを管理する。

実施形態が提供する管理サービスは、配備されたサービスを一の所望の状態に維持し且つそのサービス状態が当該所望の状態から逸脱する場合は、修正アクションを取る。実施形態内の管理サービスは、特定のサービスに関係する一のアラートに応答して、分析を自動的にトリガすることにより、当該アラートの原因を決定し、一の代替資源又はサポーティング・サービスを使用する必要があるか否かを決定し、代替資源及び／又はサービスを使用して管理されるサービス（以下「管理対象サービス」とも称する）を再配備する。これらの管理サービスは、拡張可能であり、本質的に自律型であり、複数のプラットフォーム用のサービスを管理することができる。

図３は、実施形態に従った、構成及び配備用のアクティブ・リポジトリを使用する、合成ベースのサービス管理インフラストラクチャ３００を示す。この合成ベースのサービス管理インフラストラクチャ３００では、新しいタイプのサービス要求３０２及び現にサポートされる要求タイプのサービス要求３０４は、サービス・インフラストラクチャ・マネージャ・インタフェース３０６に到着する。一のサービス要求は、（i）エンド・ユーザ、（ii）当該システム内の他のサービス、又は（iii）ネットワーク内のどこかにある他のサービスの何れかからのサービスの要求である。当該要求されたサービスは、１つ以上のソフトウェア・サービス及び当該システムによってサポートされる物理資源を使用して、当該システムが提供することができるサービスである。

一の要求は、完了前に複数のソフトウェア・サービスによって処理することが可能であり、そして全てのかかるサービスは、実行時における構成、配備及び管理により使用可能にされなければならないことに留意されたい。一のソフトウェア・サービスは、当該システムによってサポートされることがあるが、当該ソフトウェア・サービスは、常に構成され且つ配備されるとは限らない。たとえ、当該ソフトウェア・サービスが構成され且つ配備されるとしても、当該ソフトウェア・サービスは、所望の性能及び／又は提供すべきサービスの態様の観点から、一のサービス要求の要件を満たすように構成されないことがある。例えば、一の要求は、セキュア又は専用サービス提供モードで一のサービスを提供することを求めることがある。

新しいタイプのサービス要求３０２は、当該システム内で現に構成され且つ配備されていない、ソフトウェア・サービスの要求から成る。現にサポートされる要求タイプのサービス要求３０４は、当該システム内で既に構成され且つ配備されたサービスを要求する要求である。新しいタイプのサービス要求３０２又は現にサポートされる要求タイプのサービス要求３０４は、エンド・ポイント資源３１４上で動作するソフトウェア・サービスによってサービスされる。サービス・インフラストラクチャ・マネージャ・インタフェース３０６におけるこれらの要求の処理は、サービス要求元に対し透過的に行われる。

管理者は、管理者インタフェース３０８を使用して、資源状態を構成し又は再構成するためのポリシを設定したり、デフォルト設定値を変更指定することによりソフトウェア・サービスを構成し且つ配備するなどのアクションや、これと同様の動作を実行するために、当該システムと対話することができる。管理者によって発行されるコマンドは、管理者インタフェース３０８を介して、インフラストラクチャ・マネージャ・インタフェース３０６に送られる。バック・エンドでは、サービス・インフラストラクチャ・マネージャ・インタフェース３０６は、調整兼管理サービス３１０及びアクティブ・リポジトリ３１２と対話する。アクティブ・リポジトリ３１２は、アクティブ・オブジェクト及びアクティブ・テンプレートから成る。アクティブ・オブジェクトは、エンド・ポイント管理インタフェース３１６を介して、エンド・ポイント資源３１４と対話するか、又はエンド・ポイント資源上で動作するソフトウェア・サービスと対話する。また、調整兼管理サービス３１０は、アクティブ・リポジトリ３１２と対話する。前述のように、要求は、エンド・ポイント資源３１４において実際に処理される。

図４は、実施形態に従った、アクティブ・リポジトリ４０２のコンポーネントを示す。アクティブ・リポジトリ４０２は、図３のアクティブ・リポジトリ３１２のようなアクティブ・リポジトリとすることができる。前述のように、アクティブ・リポジトリ４０２は、アクティブ・テンプレート４０４及びアクティブ・オブジェクト４０６から成る。一のアクティブ・テンプレートは、一のアクティブ・オブジェクト用の一のテンプレートである。一のアクティブ・オブジェクトは、使用可能な資源及び他の管理対象サービス・インスタンスを使用して、インスタンス化された又はインスタンス化すべき一のサービス・インスタンス（例えば、管理対象サービス・コンポーネント４０８のうちの１つ）を管理するために使用される一の管理オブジェクトである。当該システム内の各物理資源及びサービス・コンポーネントは、アクティブ・リポジトリ４０２内に一の代表的なアクティブ・オブジェクトを有する。当該アクティブ・オブジェクトは、その資源又はそのサービスを管理する。資源及びサービス、すなわちサポーティング資源及びサポーティング・サービスは、一の複合サービスを構築するためのコンポーネントと呼ばれる。管理対象サービスの各タイプごとに、アクティブ・リポジトリ４０２の一のアクティブ・テンプレート４０４内に一のアクティブ・テンプレートが存在する。

また、一のサービスの一の新しいインスタンスがインスタンス化される場合は常に、インスタンス化されているサービスのタイプを表す、アクティブ・テンプレート４０４内の一のアクティブ・テンプレートからの一の新しいアクティブ・オブジェクトが、アクティブ・オブジェクト４０６内でインスタンス化される。しかし、アクティブ・テンプレート４０４内の全てのアクティブ・テンプレートが、アクティブ・オブジェクト４０６内でインスタンス化された一のアクティブ・オブジェクトを常に有するとは限らない。

新しいアクティブ・オブジェクトは、管理されている物理資源及びこれらの物理資源を使用して合成された現在の１セットのサービスに基づいて、アクティブ・オブジェクト４０６内でインスタンス化される。資源は、サービスを実装するために必要とされるコンポーネントである。例えば、一の資源は、一の物理的コンピューティング・サーバ、一のアプリケーション・サーバ又は一のウェブ・サーバとすることができる。一のサービスは、一の論理的コンポーネントによって提供される一の機能である。例えば、一のコンピューティング・サービスが、計算機能を提供することができるのに対し、一のデータベース・サービスは、一のストレージ機能を提供することができる。資源は、完全なハードウェア資源、ソフトウェア資源又はハードウェア及びソフトウェアの組み合わせとすることができる。

新しいサービスが既存のサービス及び／又は物理資源上で合成され且つインスタンス化される場合、アクティブ・オブジェクト４０６内で新しいアクティブ・オブジェクトをインスタンス化することができる。同様に、一の複合サービスがもはや必要とされない場合には、当該複合サービス及び当該複合サービスを管理するために使用されたアクティブ・オブジェクトの両方が終了される。終了されるアクティブ・オブジェクトは、ガーベジ・コレクションの対象となる。また、終了中のサービスをサポートし且つ合成するために使用されたコンポーネント・サービス又は資源に対応するアクティブ・オブジェクト４０６内のアクティブ・オブジェクトは、それらの全てがもはや当該複合サービスをサポートしていないという事実を反映するように更新される。一のコンポーネントがもはや必要とされない場合、アクティブ・オブジェクト４０６内の対応するアクティブ・オブジェクトが破棄され且つガーベジ・コレクションの対象となる。

アクティブ・テンプレート４０４は、それらの範囲が変わるか、又は対応するアクティブ・オブジェクトによって制御される環境が固定される際に、更新されるか、さもなければ展開される。また、新しいタイプの資源又はサービスが管理対象環境内に導入される場合は、新しいアクティブ・テンプレートがアクティブ・テンプレート４０４内に導入される。例えば、WebSphere 6.0 が Enterprise JavaBeans（ＥＪＢ）コンテナ・サービスとして当該システム内に導入される場合、一の新しいテンプレートがアクティブ・テンプレート４０４内に導入される。アクティブ・テンプレート４０４内に WebSphere 5.x 用の一のアクティブ・テンプレートが存在していたとしても、このことが行われる。なぜなら、WebSphere 6.0 の管理は、WebSphere 5.x コンテナの管理とは著しく相違しているからである。このアクティブ・テンプレートは、提供中のサービス及び依存関係の要件に関する情報を有するとともに、１つ以上のプラットフォーム用の構成及び配備情報を有する。

WebSphere 6.01 がサポートされる場合、新しいテンプレートは導入されないが、その相違に対応するように既存のテンプレートが更新される。WebSphere 6.0 コンテナ用のテンプレートへの更新が適用される理由は、管理上の観点からすると、２つのリリースされたバージョンの相違が小さいためである。このテンプレートから派生したアクティブ・オブジェクトは、WebSphere 6.01 コンテナを管理するとともに、WebSphere 6.0 コンテナをも管理することができる。同様に、当初は WebSphere 6.0 を Linux（登録商標）プラットフォーム上にのみ配備するのであれば、WebSphere 6.0 用のテンプレートは、Linux プラットフォーム上のコンテナのみを管理するための情報を有する。その後、WebSphere 6.0 を Windowsプラットフォーム上に配備し且つサポートするのであれば、WebSphere 6.0 用のテンプレートを更新することにより、この能力を追加しなければならない。これは、テンプレートの範囲を変更する１例である。

新しいサービス・コンポーネントを配備し且つイネーブルする場合、一のアクティブ・オブジェクトの形態を有する新しいサービス・インスタンス・オブジェクトが、アクティブ・リポジトリ４０２内でインスタンス化される。このアクティブ・オブジェクトは、当該システム内で合成され、構成され且つ配備される実際のサービス・インスタンスを管理する。成功裡の配備及び機能のためには、一のサービス・インスタンスは、他のサービス及び資源インスタンスからのサポートを必要とすることがある。当該必要とされるサポートは、当該サービス・インスタンスの依存関係及びアクティブ・リポジトリ４０２内の対応するアクティブ・オブジェクトのための依存関係要件と呼ばれる。

アクティブ・リポジトリ４０２のアクティブ・オブジェクト４０６内にある各アクティブ・オブジェクトは、一の所望の状態を達成することによりコンポーネント特有のサービスを提供すべく、一の特定の資源又はサービス・コンポーネントを管理するようにプログラムされる。一の所望の状態は、当該アクティブ・オブジェクトによって管理される実際のサービス・インスタンスから、一の所望の結果又は振る舞いを達成するのに必要とされる状態である。アクティブ・オブジェクト４０６内の各アクティブ・オブジェクトは、これが管理責任を有する、管理対象資源又はサービス・コンポーネントの現在の状態及び所望の状態を知っている。当該所望の状態は、当該システム内のシステム管理者、ポリシ・マネージャ又は他のオブジェクトによって影響を受けることがある。もし、一のアクティブ・オブジェクトが満たされていない依存関係要件を有していれば、当該アクティブ・オブジェクトの現在の状態は、この依存関係が成功裡に満たされるまで、所望の状態に遷移しない。もし、そのサービス・インスタンスの観察された状態が所望の状態と一致しなければ、当該アクティブ・オブジェクトは、アクティブ・リポジトリ４０２内の追加処理用の１セットのアクションをトリガする。アクティブ・リポジトリ４０２は、ルックアップや、サービス／資源のブローカリングを実行したり、グループ・メンバーシップを作成したり、ポリシを設定する等の機能を提供する。

各アクティブ・オブジェクト４０６は、次のエンティティをモニタする。
１．提供されるサービスの状態、
２．サポーティング・サービスの状態、
３．サポートされるサービスの状態。

構成及び配備用の制御は、マイクロ・レベル及びマクロ・レベルの２つのレベルで実行される。マイクロ・レベル制御は、サービス・テンプレート及びサービス・インスタンス・オブジェクトのレベルで動作する。１つ以上の比較的高レベルのサービスをサポートするための複数のサービスを調整するのに必要な全体的な制御は、マクロ・レベル制御によって促進される。マクロ・レベル制御は、管理サービスが、フェデレーテッド・サービス構成及び配備のようなアクションを整合的に調整することを可能にする。マクロ・レベル制御は、マイクロ・レベル制御を活用するように、その上部に構築される。

依存関係の解決及びサポーティング・サービスの共有のような計画に関係する全ての論理は、アクティブ・オブジェクト４０６内にカプセル化される。この論理は、動的に更新可能であり、以前に存在しなかった機能を追加するためにプラグ・インを挿入することができる。

各アクティブ・オブジェクト４０６は、当該アクティブ・オブジェクトがアクティブ・リポジトリ４０２内で表すサービスを管理するための４つの機能コンポーネントを有する。これらの４つの管理機能は、モニタし、分析し、構成し、実行すること（ＭＡＣＥ）を含むことができる。

これらの例において、モニタ機能は、次のエンティティをモニタする。
（１）管理対象サービスの状態、
（２）管理対象サービス・コンポーネントが依存するサービスの状態、すなわち管理対象サービス（存在する場合）に対しサポートを提供するサービス・コンポーネントの状態、
（３）管理対象コンポーネントによってサポートされるサービス・コンポーネントの状態、すなわち管理対象サービス・コンポーネント（存在する場合）に依存するサービス・コンポーネントの状態、
（４）管理入力。

分析機能は、一のアクティブ・オブジェクトに対し意思決定能力を提供する。分析機能は、次のイベントのうちの１つによってアクションをトリガする。
（１）管理対象オブジェクトの観察された状態及び所望の状態の不均衡、
（２）サポーティング・コンポーネントによって提供される機能及びサービス・レベルの不均衡、
（３）このコンポーネントがサポートするコンポーネントによって要求された機能及びサービス・レベルの不均衡。

前述の不均衡の任意のものは、（i）現在の状態内の変更、又は（ii）所望の状態内の変更が原因で生じることがある。例えば、一のWebSphere アプリケーション・サーバが一のサーバ上にインストールされているが、現に起動されていないものとする。このアプリケーション・サーバの現在の状態は、「オフライン」である。もし、所望の状態が、バッファ・サイズ、処理すべき要求の数及び特定のデータベースへの接続のような属性を伴って、「オンライン」に設定されるならば、これは一の不均衡に帰着し、対応するアクティブ・オブジェクト内の分析コンポーネントをトリガする。このアプリケーション・サーバが所望の属性を有するように「オンライン」化された後、その現在の状態が「オンライン」及び「データベースへの接続消失」に変わるものとする。これは、再び一の不均衡に帰着し、分析コンポーネントのアクションをトリガする。現在の状態内の変更は、モニタ機能コンポーネントを介して、通知される。所望の状態内の変更は、（i）調整兼管理サービスによって、（ii）管理インタフェースを介する管理アクションによって、又は（iii）既存のポリシの下でのアクションを必要とする他のアクティブ・オブジェクトからの一のサービス要求によってもたらされる。

分析コンポーネントが、管理対象オブジェクトの現在の状態及び所望の状態の間に不均衡が存在することを認識する場合、分析コンポーネントは、一の分析を実行することにより、管理対象サービスが遷移することができる最適の構成可能な状態を確立する。分析コンポーネントは、この分析を実行するために、当該システム内の他のサービス及び資源の状態及び使用可能性を考慮するとともに、現在及びサポートすべきコンポーネント又はワークロードのデマンド及び優先順位をも考慮する。この分析ステップの終わりには、サポーティング資源及びソフトウェア・サービスが完全に決定され、当該サポートを特徴づけるパラメータが確定される。例えば、当該サポートを特徴づけるパラメータは、接続の数、ポート番号、期待される応答時間及び最低保証帯域幅とすることができる。同様に、サポートされるサービスの特性も確定される。

分析の複雑さ及び性質は、分析コンポーネントに対し使用可能な意思決定の選択肢に依存する。所望の状態は、高い精度で指定することができる。例えば、所望の状態は、イネーブルされた特定のネットワーク・アダプタを有し、特定のＩＰアドレスを有し且つ特定の態様で配備された特定のウェブ・サービスを有する、一の特定サーバ上の「オンライン」WebSphere インスタンスの特定のバージョン、リリース及びパッチ・レベルを詳述することがある。このような場合において、選択肢が存在しなければ、分析コンポーネントは、管理対象サービスが規定されるような所望の状態を達成するように、使用すべき資源及びサービス並びにサポーティング・サービスに適用すべき構成パラメータを識別する。

他方、所望の状態は、或る範囲の可能な状態又は或る程度の自由度を以て指定することができる。例えば、所望の状態は、特定のネットワーク・サブドメインにおける任意のサーバ上の、バージョン６.０に準拠する「オンライン」WebSphere インスタンスを詳述することができるし、或いはアプリケーション・サーバの所望の状態は、当該アプリケーション・サーバが起動されるサーバに関し何らの制約なしに「オンライン」に設定することができる。その結果、最初に使用可能なサーバを使用することができる。他の例では、制約により、１セットのサーバからの最大量のメモリを有するサーバを使用することが必要になることがある。サポーティング・サービス及び資源を選択し且つ構成することに選択肢が存在する場合、分析コンポーネントは、他のアクティブ・テンプレート及び／又はアクティブ・オブジェクトとの対話を通して、意思決定を行う。

この対話は、使用可能なキャパシティ及び性能レベル並びに構成及び配備のために考慮中の既存及び新しいサービスによる対応するデマンドに基づき、一の最適化問題を策定し且つ解決することにより達成することができる。この最適化問題の目的は、管理対象オブジェクトに関連するポリシによって管理される。一の管理対象サービスに関連するポリシの幾つかの例は、指定された期間に特定のユーザ・グループによって当該サービスを排他的に使用すること、保守目的用の時間を取っておくこと、サポート資源として推奨される資源インスタンスを使用すること等である。

分析コンポーネントは、これらのポリシを考慮に入れて、当該システム内で可能な限り多くの不均衡を解決することを試みる。もし、不均衡を完全に排除することができなければ、分析コンポーネントは、依存関係を満たすように試みることにより、使用可能な新しい状態が所望の状態に最も近くなり且つ現在の状態からこの新しい状態への遷移が可能になるようにする。この分析の結果は、当該システム内の不均衡を修正するために使用すべき実際のサポーティング・サービス及び資源を決定する。これらのサポーティング・サービス及び資源の状態は、管理対象サービスが遷移可能な最終的な状態を決定するから、管理対象サービスは、常に実際の所望の状態を実現するとは限らないが、準最適な状態を実現することができる。実現された状態が所望の状態からどれだけ離れているかに依存して、前記分析ステップや後続の構成及び配備ステップを反復することができる。

構成機能は、分析機能からの出力を取り、次のタスクを実行する。
（１）管理対象サービス・コンポーネントが最適な態様でその現在の状態から新しい状態へ遷移することができるように、管理対象サービス・コンポーネントの既存の状態を構成し又は再構成するためのアクションの計画を作成する、
（２）コンポーネント内に実際の変更をもたらすように、実行すべき実際のコマンド、スクリプト及び手順を決定する、
（３）自己構成の前にサポーティング・サービス・コンポーネントに対し要求メッセージを送り、構成変更の後に依存サービスに対し確認メッセージを送る。

実行機能は、次のタスクを実行する。
（１）障害のリスクがポリシによって管理されるように、構成機能によって決定されたアクションの計画を実行する、
（２）所望の変更が生じたことを確認する検証ステップを実行する、
（３）初期の計画が成功しない場合は、代替的なアクションの計画を実行する、
（４）構成変更の後に、サポーティング・コンポーネント及び依存性コンポーネントとの対話を検証する。

ＭＡＣＥ機能を各アクティブ・オブジェクト４０６内にカプセル化すると、当該アクティブ・オブジェクトによって表される管理対象ソフトウェア・サービス・コンポーネントが独立的に展開することが可能となり、しかも当該システムで生じている変更に適応することが可能となる。当分野における現在の技術とは異なり、実施形態は、サービス・コンポーネントを管理するために当該サービス・コンポーネントの完全に集中化された評価を必要としない。本明細書に開示するシステムは、集中化された意思決定及び実行能力を必要とすることなく、当該システムの総合的な管理を指示するためのグローバル・ポリシを許容する。一のアクティブ・オブジェクトが管理対象オブジェクトを操作する必要がある場合は常に、当該アクティブ・オブジェクトは、一のシステム実行時間をトリガする。このシステム実行時間は、単に当該アクティブ・オブジェクトの状態を調べ、当該アクティブ・オブジェクト内に保持されるアクションを実行する。これらのアクションのうちの或るものは、管理対象サービスに作用し、他のものは、アクティブ・リポジトリ４０２内の他のアクティブ・オブジェクトに作用する。

例えば、一のアクティブ・オブジェクトは、管理対象オブジェクトを「オフライン化する」ことを求める、一のコマンドを発行することがある。他の例では、当該アクティブ・オブジェクトは、他のアクティブ・オブジェクトに通知を送ることにより、当該他のアクティブ・オブジェクトによって管理されるサービスからのサポート・サービスがもはや必要ではないことを指示することがある。当該アクティブ・オブジェクトの状態は、資源モニタ、サービス・モニタ及び管理アクションを要求する比較的高レベルのアクティブ・オブジェクトのような、外部イベントによって影響されることがある。一のイベントが当該アクティブ・オブジェクトの状態を変更する場合、前述の管理コンポーネントがアクティブ化され、そして当該アクティブ・オブジェクトは、当該管理対象サービスをより安定した状態へ導くことを開始する。

アクティブ・リポジトリ４０２内の各アクティブ・オブジェクト４０６は、当該アクティブ・オブジェクトが管理する資源又はサービスの振る舞いを制御し且つモニタするために、管理インタフェースに関連する。当該管理インタフェースは、実際の資源コンポーネント又はサービス・コンポーネント用のものであって、当該コンポーネントをどのように構成し、インストールし、配備し、テストし、そしてそのライフサイクルのイベントをどのように管理するかということに係る手順を含む。また、当該管理インタフェースは、各管理対象サービス・コンポーネントごとに、現在のステータス情報及び当該管理対象サービスが遷移することができる可能な状態用の依存関係情報を維持する。例えば、図４において、アクティブ・オブジェクト４１０は、アプリケーション・サーバ４１２に関連し、アクティブ・オブジェクト４１４は、サーバ上のオペレーティング・システム・プラットフォーム４１６に関連し、アクティブ・オブジェクト４１８は、データベース・サーバ４２０に関連する。

既存のサービス又は複合サービスを使用して一のサービス要求にサービスを提供することができない場合、当該要求されたサービスのタイプを表すアクティブ・テンプレートが通知される。次に、当該アクティブ・テンプレートは、この要求を評価して、そのサービスの一の新しいインスタンスを管理すべき一の新しいアクティブ・オブジェクトをインスタンス化するか、又は管理対象オブジェクトを再構成して当該新しい要求に対応するように既存の一のアクティブ・オブジェクトに命令する。当該再構成用の命令は、単に管理対象サービスの所望の状態を変更することにより行われる。このような場合の後続するアクションは、一の新しいアクティブ・オブジェクトが作成される場合に後続するアクションのサブセットである。以下では、新しくインスタンス化された一のアクティブ・オブジェクトによって実行される１セットのアクションであって、その結果が、コンポーネント・サービスから一の複合サービスを構成及び配備することにつながるような、１セットのアクションについて説明する。この過程では、依存関係ツリーが下方に再帰的に探索され、そして全体的な複合サービスが完全に構成され且つ配備されるまで、コンポーネント・サービス・ツリーが構築される。

アクティブ・リポジトリ４０２内の生成時には、一のアクティブ・オブジェクトの直接依存関係は知られているが、満たされていない。アクティブ・リポジトリ４０２内で一のアクティブ・オブジェクトがインスタンス化される場合、当該アクティブ・オブジェクトには、所望の状態と呼ばれる一の状態及び現在の状態と呼ばれる他の状態が割り振られる。現在の状態は、当該アクティブ・オブジェクトによって管理されるサービス又は資源の状態である。所望の状態は、当該管理対象サービス又は資源の期待される状態である。

当該アクティブ・オブジェクト内の分析コンポーネントは、これらの２つの状態を連続的にモニタする。もし、これらの２つの状態が一致しなければ、分析コンポーネントは、現在の状態を所望の状態に遷移させるための可能な代替方法を分析するとともに、所望の状態を達成するために任意の依存関係要件が満たされなければならないか否かを決定する。従って、一のアクティブ・オブジェクトがインスタンス化される時に、もし、現在の状態が「オフライン」で且つ所望の状態が「オンライン」であれば、当該アクティブ・オブジェクト内の分析コンポーネントは、管理対象資源／サービスをオンライン化するために満たさなければならないような依存関係を調べる。この依存関係情報は、管理対象オブジェクト用の６つの管理インタフェースのうちの１つである、依存関係要件インタフェース内に格納される。各依存関係は、必要とされるサービス又は資源のタイプに従って表現される。依存関係の分析は、現在の状態を所望の状態に遷移させるのに必要とされるサービス又は資源の特定のタイプを識別する。また、分析コンポーネントは、依存関係を満たすのに必要とされる、性能及び他のサービス／資源に関する任意の位置制約をも決定する。これは、所望の状態の一の機能である。

例えば、一のウェブ・サービスの所望の状態が毎分当たりｍ個のトランザクションを処理することを必要としていれば（但し、ｍの値は既知である）、分析コンポーネントは、最初に、当該ウェブ・サービスが一のデータベース・サービスに依存するであろうということを決定し、次に、性能要件を満たすことができる当該データベース・サービスの特性を定量化する。当該データベース・サービスは、データベース・レコードの読み取り速度及び更新速度によって特徴づけられるから、分析コンポーネントは、一のデータベース・サービスを適格なサポーティング・サービスとして見なすための条件である、当該データベース・サービスの最小の読み取り速度（ｒ）及び最小の更新速度（ｕ）を計算する。言いかえれば、分析コンポーネントは、当該サポーティング・データベース・サービスの１セットの性能制約を計算する。ｍ、ｕ及びｒの間の関係は、単純な代数式によって表現されることがあり、又は当該データベースシステムの近似的な振る舞いを表す多項式の評価を必要とすることがある。

或る所望の状態を達成するために必要とされる、サポーティング・サービスからの性能のレベルを決定するための性能特有の特性は、依存関係要件インタフェース内で符号化される。分析コンポーネントは、特定の依存関係を満たすために使用すべきサポーティング・サービス／資源の正確なインスタンスを識別しないことに留意されたい。分析コンポーネントは、単に必要とされる資源／サービスのタイプ及び性能、サポーティング・コンポーネントに関する位置及びセキュリティ制約を定量化するに過ぎない。次に、所望の状態、その状態に到達するのに満たすべき依存関係及びサポーティング・サービス／資源に関する制約についての情報は、構成コンポーネントに渡される。

構成コンポーネントは、実際のコンポーネントを決定するとともに、依存関係を満たすために使用すべきそれらのキャパシティの部分を決定する。構成コンポーネントは、その依存関係を満たすために必要とされるサービスのタイプ／資源を表すアクティブ・テンプレートと接触することにより、満たされていない各依存関係について決定を行う。かかる各アクティブ・テンプレートに対し、構成コンポーネントは、それが探しているサービスのタイプの要求及び満たされねばならない関連する制約を送る。かかる各アクティブ・テンプレートは、次の３つの方法のうちの１つで、この要求を満たすことを試みる。すなわち、（i）必要なサポートを提供すべき既存のサービス／資源を割り振る方法、（ii）この新しいデマンドに対応するように既存のサービスを再構成する方法、又は（iii）必要なサポートを提供すべき一の新しいサービス・インスタンスを構成し且つ配備する方法。これらの代替方法のどれもが可能でなければ、構成コンポーネントは、否定確認を返送する。このサポートを提供することが可能であれば、構成コンポーネントは、サポーティング・サービスを管理する対応するアクティブ・オブジェクトのアドレスを返送する。この依存関係に関する性能制約は、一の許容範囲として表現されることがあることに留意されたい。例えば、許容範囲は、当該範囲内でサービスを提供することが期待される、識別されたサポーティング・サービスによって表現される。ポリシも、制約を決定することに関与する。一のポリシは、制約が緩和可能である条件を指定するとともに、制約が緩和可能なエクステントを指定することがある。意思決定を行う際に、当該サポーティング・アクティブ・テンプレートは、これらのポリシを考慮に入れる。

各サポーティング・アクティブ・テンプレートにおける後続ステップは、指示されたアクティブ・オブジェクトにおけるアクションをトリガした最初の要求に関連して説明した前述のステップと同じである。これらのステップは、全ての依存関係が解決されるか、又は１セットのシステム資源及び現在の１セットのポリシを前提として、依存関係を解決することができなくなるまで、再帰的に行われる。従って、任意のサービス・コンポーネントに対しサポートを提供するための依存関係ツリー全体は、アクティブ・テンプレートからサポーティング・アクティブ・テンプレートやアクティブ・オブジェクト等に至るまで、トップ・ダウン式に探索される。実際のサービスの依存関係ツリーは、依存関係グラフの並行式縦型探索（concurrent depth-first traversal）に従うことにより、ボトム・アップ式の態様で構築される。サポーティング・ノードから発する全ての経路は、同時に探索される。

一旦サポーティング・サービスが構成され且つ必要なサポートを提供する準備が完了した一の状態で配備されると、要求元のアクティブ・オブジェクトは、肯定確認に加えて、当該サポーティング・サービスを管理するアクティブ・オブジェクトの詳細を通知される。確認の後、全てのサポーティング・サービス／資源コンポーネント並びにそれらの使用可能なキャパシティを含む、それらの現在の構成は、依存関係グラフ内の各ノードごとに知られている。構成コンポーネントは、この情報を使用して、当該サービスを当該サポーティング・サービス上に構成する際に使用すべき実際のパラメータを定量化する。これらのパラメータは、ＩＰアドレス、使用すべき通信ポート、サポーティング・サービスへのアクセスを許可されたユーザＩＤ及びパスワード、バッファ・サイズ等を含むことができる。これらのパラメータの詳細は、サービスのタイプに依存する。次に、構成情報が実行コンポーネントに渡される。

実行コンポーネントは、管理対象サービスがその所望の状態でサポーティング・サービス上にインスタンス化されるように、設定及びインストール手順を実行するとともに、コマンドを送る。これらのコマンド及び手順は、当該アクティブ・オブジェクトのサービス配備管理インタフェース内に格納される。この結果、コンポーネント・サービスの合成として、当該サービスの配備が完了する。配備に続いて、ユーザ要求が処理されるか、又は比較的高レベルのサービスがかかる複合サービス上に合成される。

要約すると、一の複合サービスは、当該複合サービスを集合的に形成するサービス・コンポーネントを構成し且つ配備することにより形成される。正確なサービス・コンポーネントが、動的に決定されるのに対し、コンポーネント間の依存関係ツリーは、トップ・ダウン式に探索される。当該複合サービスの最高レベルにおけるサービス・タイプ用のアクティブ・テンプレートから開始して、アクティブ・リポジトリ内のアクティブ・テンプレート及びアクティブ・オブジェクトを調べることにより、依存関係ツリーがトップ・ダウン式に探索される。アクティブ・リポジトリにおいて、アクティブ・オブジェクトは、依存関係ツリー内のノードである。依存関係ツリーがトップ・ダウン式に探索されるにつれて、各ノードにおけるアクティブ・オブジェクトが識別される。また、同じ依存関係ツリーが、当該アクティブ・オブジェクトによって管理される実際のサービス・コンポーネント間で形成される。依存関係グラフ内の実際のサービス・コンポーネントは、当該依存関係グラフの並行式縦型探索に従うことにより、ボトム・アップ式の態様で構成され且つ配備される。

複合サービスの合成中に、もし、任意のサービス・コンポーネントが必要とされる構成を持たないで既に配備されていれば、対応するアクティブ・オブジェクトは、当該コンポーネント内に所望の構成変更をもたらすために、特定のアクションを呼び出す。一旦当該サービス・コンポーネントが再構成され且つ配備され、そして性能が満足できるものであれば、依存関係グラフ内の比較的高レベルのアクティブ・オブジェクトが通知される。一旦必要とされる全てのサポーティング・コンポーネントが準備を完了しており且つ機能的であることが知られていれば、次のレベルのオブジェクトは、実際のサービス・コンポーネントを構成し且つ配備する。このことは、最上位レベルのサービス・コンポーネントを含む全てのコンポーネントが構成され、配備され、所望のサービス提供状態がもたらされるまで、継続的に行われる。

分解プロセスが生じるのは、一のサービスがもはや必要とされない場合、管理者が一のサービス分解コマンドを発行する場合、当該サービスをオフにすることを必要とする一のポリシが実施される場合、又は現在の１セットの条件の下では当該サービスを維持することができない場合である。分解プロセスに関係するステップは、一のサービスを合成する際に取られたステップの正反対である。この状況では、先ず、最上位レベルにあるサービスのアクティブ・テンプレートは、アクティブ・オブジェクト内の所望の状態をオフラインに設定する。次に、そのアクティブ・オブジェクト用の分析コンポーネントは、構成コンポーネントに対し、構成をオフラインに変更するように通知する。これに応じて、構成コンポーネントは、先ず、サポートされるサービス・コンポーネントのアクティブ・テンプレート（存在する場合）に対し、サービス終了を通知する。構成コンポーネントは、サポートされるコンポーネントのアクティブ・テンプレートから、肯定応答を受け取ることを待機する。当該アクティブ・テンプレートから、当該アクティブ・テンプレートがサービス・コンポーネントに関するそれらの依存関係を終了したという応答を受け取った後、構成コンポーネントは、実行コンポーネントに対し、当該アクティブ・オブジェクトによって管理されるサービスを終了するように通知する。当該管理対象サービスが終了した後、構成コンポーネントは、このサービスにサポートを提供している当該サービスに対応するアクティブ・テンプレート（存在する場合）に対し、サポート・サービスがもはや必要とされないことを通知する。当該アクティブ・テンプレートから肯定応答を受け取った後、構成コンポーネントは、それ自体のアクティブ・テンプレートに対し、当該サービスの成功裡の終了を通知し、その後、当該アクティブ・オブジェクトは、自己終了する。

複合サービスの分解は、複合サービス管理ツリーの一部である各アクティブ・オブジェクトにおいて行われた同じステップの再帰的プロセスである。この分解プロセスは、依存関係ツリー内の必ずしも最上位レベルにではない任意のノードにおいて開始することができる。一旦依存関係グラフ内の任意のノードにおける一のアクティブ・オブジェクトがオフラインに移行するように通知されると、当該アクティブ・オブジェクトは、当該アクティブ・オブジェクトがサポートする全てのサービスが終了したか、又は他の代替サポーティング・サービス・コンポーネントを検出した後にのみ、当該管理対象サービスを終了させる。同様に、かかるサポートされるサービスのそれぞれは、当該サービスに依存する全てのサービスが自己終了したか、又は代替サポートを検出した後にのみ、終了することになる。検証プロセスは、実際の目標サービスの最初の分解が生じる、依存関係グラフの最上部に至るまで、再帰的に継続する。これに続いて、比較的低レベルのサービス・コンポーネントが、トップ・ダウン式に終了される。当該再帰的プロセスは、依存する各アクティブ・オブジェクトにおいて開始する並行な経路に沿って、分解を同時的に行うことに留意されたい。一のソフトウェア・コンポーネントが、分解の一部としてそれ自体をアンインストール又は再構成するのに対し、ハードウェア・コンポーネントは、使用可能な資源プールの一部になる。

図５は、実施形態に従った、一のサービス用の一のオブジェクト依存関係グラフを例示する。オブジェクト依存関係グラフ５００は、一の企業のような高レベルのサービスの依存関係を記述することができる。オブジェクト依存関係グラフ５００は、コンポーネント間の依存関係を一の有向グラフとして捕捉する。オブジェクト依存関係グラフ５００の各ノードは、一の資源又はサービス・コンポーネントを表す。オブジェクト依存関係グラフ５００における各ノード間の線は、比較的低レベルのサポーティング・コンポーネントに関する高レベル・コンポーネントの依存関係を表す。例えば、一の高レベル又は複合サービスは、複数の個別サービス及び個別資源に依存することがある。

例えば、オブジェクト依存関係グラフ５００のルートに含まれる一のノードは、サービス５０２を表し、foobar.redbank.com:80/AccountServiceとして示されている。例えば、サービス５０２は、インターネットを介してユーザがアクセス可能なオン・ライン銀行用の高レベル・サービスとすることができる。１つの例では、サービス５０２は、統一資源識別子（ＵＲＩ）、ハイパーリンク、ハイパーテキスト転送プロトコル（ＨＴＴＰ）又は他のフォーマットの形式でアクセスすることができる。ハイパーテキスト転送プロトコルとは、一のクライアント装置と一のサーバの間のウェブ・ブラウジングを可能にする実際の通信プロトコルである。統一資源識別子は、例えば、インターネット上にある一の資源用の識別子として作用する、フォーマットされたストリングである。統一資源識別子は、ハイパーリンクのアンカを識別するために、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）のようなソフトウェア言語内で使用される。

この例に示すように、サービス５０２は、プレゼンテーション及び認証サービス機能を含む追加サービスのために、AccountService ５０４及び Apache Web Server ５０８と呼ばれる、一のウェブ・サービスに依存する。ウェブ・サービスである AccountService ５０４は、IBM WebSphere Application Server ５０６及び IBM DB2 database server ５１４への依存関係を有する。IBMWebSphere Application Server ５０６は、マイクロソフト社の Windows 2003 server ５１６への依存関係を有する。IBM DB2 database server ５１４は、Windows 2003 server ５１８に依存する。さらに、サービス５０２は、abc.payment.com:9080/Pyment 及び abc.broker.com:9080/Portfolio としてそれぞれ示された、外部的にホストされるサービス５１０及び５１２に依存する。例えば、外部的にホストされるサービス５１０は、サービス５０２によって提供されるサービス用の支払いを受け取るために使用することができる。外部的にホストされるサービス５１２は、ポートフォリオ内の金融資産に関するデータを保存するために使用することができる。オブジェクト依存関係グラフ５００内のオブジェクトに対して変更及び更新を最も有効に実装する方法を決定するために、変更管理システムをユーザ定義のポリシと共に使用することができる。

前述の複合サービスの合成及び分解は、アクティブ・リポジトリ内のアクティブ・オブジェクト及びアクティブ・テンプレートによって行われるマイクロ・レベル制御を使用して、サービス・コンポーネントを管理することを例証する。そうする際に、アクティブ・オブジェクト及びテンプレートは、サポーティング及びサポートされるサービス又は資源インスタンスの振る舞いにも影響を及ぼす。さらに、アクティブ・オブジェクト及びテンプレートは、サポーティング及びサポートされる資源の振る舞いの変更に応答する。しかし、マイクロ・レベル制御は、グローバルな制約及びポリシを考慮に入れて同時的なグローバルの変更をもたらさない。かかる変更は、マクロ・レベル制御によってもたらされる。例えば、マクロ・レベル制御は、グローバル・ポリシ（例えば、重要な資源が共有される態様、デマンドが優先順位付けされ且つサービスされる態様）を実施するために必要とされる。かかるポリシが必要であるのは、資源が不十分であり、そしてデマンドがサプライを超過することがあるような場合である。さらに、かかるポリシが必要であるのは、複雑な意思決定が行われ、そしてトレードオフが明確でないような場合である。

図６は、実施形態に従った、複合サービスを管理するためのマクロ・レベル制御を示す。調整兼管理サービス６００は、図３の調整兼管理サービス３１０のような、調整兼管理サービスである。調整兼管理サービス６００は、複合サービスを管理するためにマクロ・レベル制御を提供する管理サービスから成る。

調整兼管理サービス６００は、分析兼計画エンジン６０２、構成エンジン６０４、配備エンジン６０６、モニタ・エンジン６０８及びライフサイクル・エンジン６１０を備える。これらのエンジンの各々は、アクティブ・リポジトリ６１２及びアクティブ・リポジトリ６１２内に表される管理オブジェクトと対話する。図示の５つのエンジンによって提供されるマクロ・レベル制御は、マイクロ・レベル制御に変換される。アクティブ・リポジトリ６１２内のアクティブ・オブジェクト（例えば、図４のアクティブ・オブジェクト４０６に相当）は、マクロ・レベル制御の所望の効果がマイクロ・レベルで実現されるように、対応する資源及びコンポーネント・サービスを制御する。

前述のように、アクティブ・リポジトリ６１２は、サービス要求に応答してソリューションを提供するように、ソフトウェア・サービス・コンポーネントの全てのライフサイクル側面を管理する。アクティブ・リポジトリ６１２は、関係するシステム管理ポリシ及び物理資源の使用可能性によって課される制約を考慮に入れて、この機能を実行する。後述するように、このライフサイクル管理の１つの側面は、一の複合サービスに対する一のデマンドがある場合は常に、かかる複合サービスを合成することである。他の側面は、デマンドが存在しない場合、ポリシが必要とする場合、又は１つ以上のサポーティング・サービスが使用不能である場合に、一の複合サービスを分解することである。

前述のように、アクティブ・リポジトリ６１２内の一のアクティブ・オブジェクトは、１セットの依存性コンポーネントをサポートするため又は１クラスの要求を処理するために、管理対象サービスを構成することができる。サポーティング・サービス及び資源コンポーネントを複数のエンティティ間で共有すべき場合、これらのコンポーネントが異種である場合、又はこれらが不十分である場合には、これらのサービス及び資源のブローカリングを行って、１つ以上の比較的高レベルの依存サービスに割り振る必要がある。一のサービス及び資源コンポーネントは、１つ以上の属性キャパシティにおいて他のコンポーネントとは異なる。不十分なコンポーネントは、同じサポーティング資源をめぐって競合する複数の依存性コンポーネントを有する、一のコンポーネントである。サポーティング資源は、一の高レベル・サービスの機能を提供するために、当該高レベル・サービスによって使用されるものである。例えば、もし、当該高レベル・サービスが銀行であれば、そのサポーティング資源は、ユーザ用のインターネット・ポータル、信用調査サービス及び顧客情報を有するデータベースを含むことができる。調整兼管理サービス６００は、必要なブローカリング、割り振り、整合化（matching）、構成及び配備サービスを提供する。

分析兼計画エンジン６０２は、サービス及び資源のブローカリング、整合化及び割り振り機能を提供する。サービス及び資源キャパシティが不十分である場合、又はアクティブ・テンプレートが既存のポリシの結果として共有問題を解決することができない場合には、サポーティング・コンポーネントを必要とする比較的高レベルのアクティブ・オブジェクトは、依存関係グラフを構築し、それらの要件を、依存関係グラフと共に、分析兼計画エンジン６０２に渡す。分析兼計画エンジン６０２は、アクティブ・リポジトリ６１２内で未解決の全てのかかる要件及び依存関係を収集する。分析兼計画エンジン６０２は、現に使用可能な資源及びサービス・コンポーネントのキャパシティ、資源及びサービスに特有のポリシ、優先順位、プリファレンス及び全体的なビジネス目標を収集する。分析兼計画エンジン６０２は、この情報を、サービス仕様書、サービス構成及び分析中のアクティブ・オブジェクトのサービス状態セクション内で見つける。

分析兼計画エンジン６０２は、依存関係グラフ内の依存関係及び使用可能なキャパシティを制約としてモデル化し且つビジネス目標を目的関数としてモデル化することにより、一の最適化問題を策定する。この最適化問題のソリューションは、分析される依存関係グラフ内の各ノードでどのサポーティング・コンポーネントを使用すべきかを正確に決定する。

また、分析兼計画エンジン６０２は、一のサポーティング・コンポーネントを複数の依存サービスによって共有すべきか否か、又は当該サポーティング・コンポーネントを専用モードで使用すべきか否かを決定し、共有のために使用すべき任意の優先順位方式を決定し、そして一の依存性コンポーネントが一のサポーティング・コンポーネントを使用すべき正確な時間を決定する。もし、一のサポーティング・コンポーネントがアクティブ・リポジトリ６１２内に存在しないか、又は既存のポリシが共有を許可しなければ、アクティブ・リポジトリ６１２内の対応するアクティブ・テンプレートを使用して、当該オブジェクトの新しいインスタンスが作成される。既存の及び新しく作成されるインスタンス・オブジェクトの所望の状態は、依存関係グラフ内に配置される新しいデマンドを反映するように設定される。

分析兼計画エンジン６０２は、満たされていない依存関係を有する各アクティブ・オブジェクトごとに、一のソリューション依存関係グラフを準備する。このソリューション依存関係グラフは、対応するアクティブ・オブジェクトのサービス構成セクション内に書き込まれる。また、分析兼計画エンジン６０２は、依存関係ツリーにおいてサポーティング・サービスを提供する、アクティブ・オブジェクトの所望の状態を更新する。

もし、分析兼計画エンジン６０２が、当該アクティブ・オブジェクトの依存関係を満たすことができなければ、現在の状態は所望の状態と一致しない。かかる場合、当該アクティブ・オブジェクトの要件は、次の評価段階中に、分析兼計画エンジン６０２によって再考される。かかる再考は、必要な資源及びサービスが使用可能になるまで、又は当該アクティブ・オブジェクトに対応するサービスがもはや必要とされなくなるまで、継続的に行われる。

構成エンジン６０４は、サービス依存関係グラフを使用することにより、比較的高レベルのサービスの要件を満たすために必要とされるサービスの構成記述を生成する。構成エンジン６０４が生成する一の構成依存関係グラフは、依存関係ツリー内の各コンポーネント用の構成設定を記述するとともに、コンポーネント・サービス及び資源を配備及び構成すべき順序を記述する。この構成依存関係グラフも、問題となっているオブジェクトの配備セクション内に格納され、配備エンジン６０６によって使用される。また、構成エンジン６０４は、構成依存関係グラフ内の各アクティブ・オブジェクト用の構成設定を更新する。これらの更新は、対応するアクティブ・オブジェクトに対し、コンポーネントが必要なサポートを提供することができるように、それらが管理するオブジェクト内に所望の変更をもたらすことを指示する。

次に、配備エンジン６０６は、構成依存関係グラフを使用することにより、要求を満たすために必要とされる資源を要求する。配備エンジン６０６は、一の内部ワークフローに従うことにより、資源を割り振り且つ提供するとともに、提供され且つ構成されるサービスについて単体及び統合テストを実行する。配備エンジン６０６は、各資源ごとに、構成依存関係グラフを使用することにより、当該資源のインストール及び構成を開始する。このインストール及び構成の進行状況は、モニタ・エンジン６０８により連続的にモニタされる。モニタ・エンジン６０８は、リポジトリ内の代表的な各オブジェクトのステータスを更新する責任を有する。もし、単体又は統合テストの間に障害に遭遇すれば、新しい１セットの資源を獲得することを含むことがある、回復アクションを実行することにより、ワークフローが再開する。

図７は、実施形態に従った、一の複合ソフトウェア・サービスを合成し且つ管理するために使用される動作のフローチャートである。図７のプロセスが開始する前に、一のコンピュータ・ネットワーク内に一のソフトウェア・サービスを配備するための一の要求が受け取られる。もし、当該要求されたソフトウェア・サービスが一の新しいソフトウェア・サービスであれば、図３のサービス・インフラストラクチャ・マネージャ・インタフェース３０６のようなサービス・インフラストラクチャ・マネージャ・インタフェースは、図３のアクティブ・リポジトリ３１２のようなアクティブ・リポジトリに対し、当該要求を通知する。当該サービス・インフラストラクチャ・マネージャは、アクティブ・リポジトリからの応答を待機する。

この通知に応答して、アクティブ・リポジトリは、通知された要求タイプを処理するための一のサービスの管理を提供することができる、アクティブ・リポジトリ内の一のアクティブ・テンプレートを識別する（ステップ７０２）。次に、アクティブ・リポジトリは、当該識別されたアクティブ・テンプレートに対し、一のサービス要求通知を送る（ステップ７０４）。次に、アクティブ・リポジトリは、識別されたアクティブ・テンプレートからの、要求されたサービスの使用可能性に関する肯定確認を待機する（ステップ７０６）。要求されたサービスが使用可能になった後、アクティブ・テンプレートは、アクティブ・リポジトリに対し、当該サービスの使用可能性及び位置を通知する（ステップ７０８）。これに応じて、アクティブ・リポジトリは、サービス・インフラストラクチャ・マネージャに対し、サービス合成を伴う当該サービスの使用可能性及び位置を通知し（ステップ７１０）、その後このプロセスが終了する。

図８は、実施形態に従った、一のアクティブ・テンプレート用のサービス合成のためのフローチャートである。図８のプロセスは、図３のアクティブ・リポジトリ３１２のようなアクティブ・リポジトリ内に存在する、図４のアクティブ・テンプレート４０４のような一のアクティブ・テンプレートによって実装することができる。図７のステップ７０４で通知を受け取った後、当該アクティブ・テンプレートは、それが作成した既存のアクティブ・オブジェクトのうちの任意のものが未解決の通知イベントを処理することができるか、又は一の新しいアクティブ・オブジェクトをインスタンス化する必要があるかを決定する（ステップ８０２）。ステップ８０２の決定を行う際には、当該新しい要求の要件及び当該既存のアクティブ・オブジェクトが管理する既存のサービスによってそれらの要件を処理する能力が考慮される。当該要求を処理するために既存のサービスが使用されるのは、当該既存のサービスが現在のコミットメントに影響せず、しかも既存のポリシに違反しない場合に限られる。さもなければ、一の新しいサービス・インスタンスを作成し且つこれを管理しなければならない。

もし、当該アクティブ・テンプレートが、新しいアクティブ・オブジェクトをインスタンス化することを決定すれば、当該アクティブ・テンプレートは、一の新しいアクティブ・オブジェクトをアクティブ・リポジトリ内に作成するとともに、必要とされるサービス・インスタンスの成功裡のインスタンス化に帰着するような状態に所望の状態を設定する（ステップ８０６）。例えば、当該アクティブ・テンプレートは、アカウント更新の一の要求に応答して、図５のサービス５０２のような AccoutService web service を管理するための一のアクティブ・オブジェクトを作成するとともに、所望の状態を AccountService に関する「オンラインに移行」に設定することができる。次に、当該アクティブ・テンプレートは、管理対象サービス内で所望の状態を達成する、当該アクティブ・オブジェクトからの肯定確認を待機する（ステップ８０８）。次に、当該アクティブ・テンプレートは、要求されたサービスの使用可能性に関する肯定確認をアクティブ・リポジトリに送り（ステップ８１０）、その後このプロセスが終了する。アクティブ・リポジトリは、図８のプロセスのサービス要求元である。

もし、ステップ８０２で、当該アクティブ・テンプレートが一の新しいアクティブ・オブジェクトをインスタンス化しないことを決定すれば、このプロセスは、再構成すべき既存の一のアクティブ・オブジェクトを識別し、その所望の状態を変更する（ステップ８１２）。次に、当該アクティブ・テンプレートは、管理対象サービス内で所望の状態を達成する、当該アクティブ・オブジェクトからの肯定確認を待機する（ステップ８０８）。

図９は、実施形態に従った、一のアクティブ・オブジェクト用のサービス合成のためのフローチャートである。図９のプロセスは、図４のアクティブ・オブジェクト４１０のような一のアクティブ・オブジェクトによって実装することができる。図８のステップ８０６及び８１２の後、当該インスタンス化されたアクティブ・オブジェクトは、現在の状態が所望の状態と同じであるか否かを決定する（ステップ９０２）。もし、現在の状態が所望の状態と同じであれば、当該インスタンス化されたアクティブ・オブジェクトは、所望の状態及び現在の状態を継続的にモニタし、ステップ９０２が反復される。さもなければ、当該インスタンス化されたアクティブ・オブジェクトは、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントの構成が所望の状態にあるか否かを決定する（ステップ９０４）。次に、このプロセスは、当該管理対象サービス・コンポーネントが所望の状態にある場合、他のサービス・コンポーネントへの依存関係を決定する（ステップ９０６）。次に、このプロセスは、サポーティング・サービス・コンポーネント用の構成パラメータに関する境界を決定する（ステップ９０８）。次に、このプロセスは、必要とされるサポーティング・サービスに関連するアクティブ・テンプレートに対し、サービス要求通知を送る（ステップ９１０）。

次に、このプロセスは、サポーティング・サービスのアクティブ・テンプレートからの、肯定確認を待機する（ステップ９１２）。次に、全てのサポーティング・サービス・コンポーネントがサービスを提供する準備を完了している場合、このプロセスは、サービス・コンポーネントが現在の状態から所望の状態に遷移することができるように、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントに対し、構成コマンドを送る（ステップ９１４）。次に、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントが所望の構成で動作している場合、このプロセスは、当該サービス・コンポーネントのアクティブ・テンプレートに対し肯定確認を送り（ステップ９１６）、その後このプロセスが終了する。図９のステップ９１０の後、このプロセスは図８のステップ８０２に進み、そこで図９のステップ９０６で識別されたサポーティング・サービス用のアクティブ・テンプレートが、必要なサポートをイネーブルするためのプロセス・ステップを実行する。

図１０は、実施形態に従った、一のアクティブ・テンプレート用のサービス分解のためのフローチャートである。このプロセスが開始されるのは、一のアクティブ・テンプレートがアクティブ・オブジェクトを介して管理する、１つ以上の管理対象サービス・インスタンスによって提供される一のサービスがもはや必要とされないという通知を、当該アクティブ・テンプレートが受け取る場合である。この通知は、一のポリシ、管理コマンド、期待されるワークロード減少、又は一の依存サービス・コンポーネントのオフライン化によってトリガすることができる。この通知の原因に拘わらず、当該アクティブ・テンプレートの観点からすれば、この通知は、サービス・コンポーネントによってサポートされるワークロードの減少を意味する。図１０のプロセスは、図４のアクティブ・テンプレート４０４のようなアクティブ・テンプレートによって実装することができる。

図１０のプロセスは、前記通知を分析することにより開始する。すなわち、当該アクティブ・テンプレートは、依存関係の終了によって影響されるであろう１つ以上のサービス・インスタンスを決定し、その決定から、それらのサービス・インスタンスに対応するアクティブ・オブジェクトを識別する（ステップ１００２）。次に、当該アクティブ・テンプレートは、当該１セットのアクティブ・オブジェクトによって管理されるサービス・コンポーネントへの現在のワークロードのマッピングに対する依存関係終了の影響を決定する（ステップ１００４）。たとえ終了されるサービス依存関係が、サービス・インスタンスのロード・バランス及びポリシ・ベースの整合化を維持するために、当該サービス・インスタンスのうちの１つによって処理されるとしても、当該アクティブ・テンプレートは、終了すべき依存関係を含めて又は終了すべき依存関係を含めないで、当該サービス・インスタンスの構成を集合的に分析する。総合的なワークロードの変更に起因して、当該サービス・インスタンスへの残存するサービス依存関係のマッピングのような新しい構成は、１つ以上のサービス・インスタンスの終了及び／又は再構成に帰着することがある。次に、当該アクティブ・テンプレートは、この新しい構成を使用して、影響される各アクティブ・オブジェクトが処理されるまで、影響されるサービス・インスタンスの識別されたリスト上をループする（ステップ１００６）。かかる各アクティブ・オブジェクトごとに、このプロセスは、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントを終了又は再構成すべき場合、古い構成及び新しい構成を比較することにより、当該アクティブ・テンプレートの構成を決定する。次に、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントを終了又は再構成すべきかという決定が行われる（ステップ１００８）。

もし、ステップ１００８で、サービス・インスタンスを終了すべきと決定されるならば、当該アクティブ・テンプレートは、当該影響されるアクティブ・オブジェクトの所望の状態を終了するように設定する（ステップ１０１０）。このステップ及びこのステップに至る全てのステップは、分解プロセスの一部である。

もし、ステップ１００８で、サービス・インスタンスを再構成すべきと決定されるならば、当該アクティブ・テンプレートは、当該影響されるアクティブ・オブジェクトの所望の状態を新しいワークロード及び新しい依存性サービス・コンポーネントで再構成するように設定する（ステップ１０１２）。ステップ１０１２の後、このプロセスは、図９のステップ９０２に示すようなサービス・インスタンスの再構成に進む。

図１１〜図１３は、実施形態に従った、一のアクティブ・オブジェクト用のサービス分解のためのフローチャートである。図１１〜図１３のプロセスは、図４のアクティブ・オブジェクト４１０のような一のアクティブ・オブジェクトによって実装される。図１０のステップ１０１０の後、このプロセスは、同様に影響される各アクティブ・オブジェクトについて、並行に実施される。これらのプロセス・ステップが当該影響されるアクティブ・オブジェクトにおいてトリガされるのは、当該アクティブ・オブジェクトが、管理対象サービス・インスタンス用の現在の状態及び所望の状態が一致しないことを決定する場合である（ステップ１１０２）。これらの２つの状態が一致する限り、ステップ１１０２が反復される。さもなければ、このプロセスは、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントの所望の状態における構成を決定する（ステップ１１０４）。

次に、当該管理対象サービス・コンポーネントによって現にサポートされる各サービス・コンポーネントごとに、このプロセスは、各サービス・コンポーネントが所望の状態でサポートされるかであろうか否かを決定する（ステップ１１０６）。次に、現在の状態ではサポートされるが、所望の状態ではサポートされない各サービス・コンポーネントごとに、このプロセスは、対応するアクティブ・テンプレートに対し、それらの依存関係を終了させるための通知を送る（ステップ１１０８）。

次に、このプロセスは、全ての依存性サービス・コンポーネントからの、依存関係終了の肯定確認を待機する（ステップ１１１０）。次に、当該管理対象サービス・コンポーネントが所望の状態にある場合、このプロセスは、他のサービス・コンポーネントへの依存関係を決定する（ステップ１１１２）。次に、このプロセスは、所望の状態では必要とされないサービス・コンポーネントへの依存関係を終了させるために、再構成コマンドを当該管理対象サービスに送る（ステップ１１１４）。次に、再構成コマンドが成功する場合、このプロセスは、所望の状態においてもはや必要とされないサービス・コンポーネント用のアクティブ・テンプレートに対し、情報通知を送る（ステップ１１１６）。

次に、このプロセスは、当該管理対象サービスを終了すべきか否かを決定する（図１２のステップ１１１８）。もし、当該管理対象サービスを終了すべきと決定すれば、このプロセスは、終了の準備をさせるために、再構成コマンドを当該管理対象サービスに送る（図１３のステップ１１２０）。次に、このプロセスは、当該管理対象サービスのアクティブ・テンプレートに通知を送ることにより、サービス・コンポーネントの終了を知らせる（ステップ１１２２）。次に、当該管理対象サービス・コンポーネントが終了する準備を完了している場合、このプロセスは、当該管理対象サービス・コンポーネントを終了させるためのコマンドを送る（ステップ１１２４）。次に、当該管理対象サービス・コンポーネントは、自己終了し（ステップ１１２６）、その後このプロセスが終了する。

もし、図１２のステップ１１１８で、当該管理対象サービスを終了すべきでないと決定すれば、当該管理対象サービスが所望の状態において継続的に依存するであろうサービス・コンポーネントについて、このプロセスは、依存関係を再構成する必要があるか否かを決定する（ステップ１１２８）。次に、再構成する必要がある各サポーティング・サービス・コンポーネントごとに、このプロセスは、その依存関係を保留し、サービス再構成通知要求を対応するアクティブ・テンプレートに送る（ステップ１１３０）。次に、当該管理対象サービスが所望の状態において依存するであろう任意の新しいサービス・コンポーネントについて、このプロセスは、必要とされるサービスに関連するアクティブ・テンプレートに対し、サービス要求通知を送る（ステップ１１３２）。

次に、このプロセスは、所望の状態において必要とされるサポーティング・サービスのアクティブ・テンプレートからの、肯定確認を待機する（ステップ１１３４）。次に、全てのサポーティング・サービス・コンポーネントが必要なサポートを提供する準備を完了している場合、このプロセスは、当該管理対象サービス・コンポーネントが現在の状態から所望の状態に遷移することができるように、再構成コマンドを当該管理対象サービス・コンポーネントに送る（ステップ１１３６）。次に、当該アクティブ・オブジェクトによって管理されるサービス・コンポーネントが所望の状態で動作している場合、このプロセスは、現在の状態を所望の状態に変更し、この状態変更を当該サービス・コンポーネントのアクティブ・テンプレートに知らせ（ステップ１１３８）、その後このプロセスが終了する。

図１１のステップ１１１０及び図１３のステップ１１２２の後、このプロセスは、図１０のステップ１００２に戻る。図１２のステップ１１３０及び１１３２の後、このプロセスは、図８のステップ８０２に戻る。

要するに、実施形態は、管理対象エンティティ間の依存関係を動的に且つ自律的に表すための、テンプレート及びオブジェクトの一のリポジトリを提供する。サービス・コンポーネントは、高レベルのサービスを構成し且つ配備するために必要とされる完全なサポート機構を形成するように、自己組織化される。満たされていない依存関係を有する高レベルのサービスは、自動的に検出される。適格性のあるサービス及び資源コンポーネントが識別され、１つ以上の高レベルのサービスの依存関係要件を部分的に又は完全に満たすように、部分的に又は完全に整合される。

計画の使用は、サポーティング・サービスがビジネス目標を有効に満たすことを可能にする。システム制約のグローバル最適化を実行するために、高レベルのサービスの依存関係及び要件、サポーティング・サービス及び資源コンポーネントの使用可能なキャパシティ、コンポーネントに特有のポリシ及びプリファレンス、指定されたビジネス目標に基づく目的関数が考慮に入れられる。

アクティブ・リポジトリ内にあるアクティブ・オブジェクト間の配備レディ依存関係は、一の分散環境内で使用可能な資源を使用して、複合サービス配備のために動的に合成される。資源プール内の変更には、自動的に応答する。例えば、一の機械がサービスのために除去される場合、その機械に依存する全てのワークフローが使用可能となるように再構成する必要があるとは限らない。一の間接レベルを使用するアクティブ・リポジトリ内のオブジェクト及びテンプレートを使用すると、システム管理者が合成内の各コンポーネントを追跡し、構成し且つ配備することを必要とすることなく、基礎をなす物理資源の容易な管理を可能にする。複合サービスは、高レベルのサービスの状態内に単一の変更を導入して、サポーティング・サービスを識別し且つ構成することにより合成され且つ分解される。

従って、実施形態は、サービス・インフラストラクチャのオン・デマンド合成及び分解のためのコンピュータ実装方法、装置及びコンピュータ使用可能なプログラム・コードを提供する。この方法は、コンポーネントが互いに連携して、期待される態様で振る舞う一の複合サービスを提供するように、ソフトウェア・サービス及び資源コンポーネントを構成し且つ配備する。自動管理及び制御は、コンポーネント・レベル及び合成フェデレーテッド・レベルで行われる。その結果、高レベルのサービスが、オンデマンドで、自動的に配備され、構成され、再構成され、分解されるから、管理者及び他のＩＴ担当者が高レベルのサービスを維持するのに必要な時間の量を減少させることができる。

本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はソフトウェア及びハードウェア要素の両方を含む実施形態の形式を取ることができる。推奨実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコード等を含む、ソフトウェアで実装される。

また、本発明は、コンピュータ又は任意の命令実行システムに関連して又はこれらによって使用するためのコンピュータ使用可能なプログラム・コードを提供する、コンピュータ使用可能な媒体又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラムの形式を取ることができる。この記載の目的上、コンピュータ使用可能な媒体又はコンピュータ可読媒体は、前記命令実行システム又は装置に関連して又はこれらによって使用するためのプログラムを保持し、格納し、通信し、伝送し、移送することができる、任意の有形的装置とすることができる。

媒体は、電子、磁気、光学、電磁気、赤外線又は半導体システム（若しくは装置）又は伝送媒体とすることができる。コンピュータ可読媒体の例には、半導体又は固体メモリ、磁気テープ、取り外し可能なフレキシブル・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛体磁気ディスク及び光ディスク等がある。光ディスクの例には、読み取り専用のＣＤ−ＲＯＭ、読み書き可能なＣＤ−Ｒ／Ｗ及びＤＶＤがある。

コンピュータ使用可能なプログラム・コードを格納及び／又は実行するのに適したデータ処理システムは、システム・バスを通してメモリ要素に直接的又は間接的に結合された少なくとも１つのプロセッサを含む。これらのメモリ要素は、コンピュータ使用可能なプログラム・コードの実行中に使用されるローカル・メモリ、バルク・ストレージ、コンピュータ使用可能なプログラム・コードの実行中にバルク・ストレージからの取り出し回数を減少させるために少なくとも或るコンピュータ使用可能なプログラム・コードの一時的記憶領域を提供するキャッシュ・メモリを含むことができる。

Ｉ／Ｏ装置（キーボード、ディスプレイ、ポインティング装置等を含む）は、システムに対し直接的に又は介在するＩ／Ｏコントローラを通して結合することができる。

また、ネットワーク・アダプタをデータ処理システムに対し結合することもできる。そのようにすると、当該データ処理システムは、介在する専用又は公衆ネットワークを通して、他のデータ処理システム、遠隔プリンタ又は記憶装置に結合されるようになる。ネットワーク・アダプタの例には、モデム、ケーブル・モデム及びイーサネット（登録商標）・カード等がある。

本発明に関する記述は、例示及び説明を目的として与えられたものであって、網羅的であること及び開示された形態に本発明を制限することを意図するものではない。当業者にとって、多くの修正及び変形が明らかであろう。実施形態は、本発明の原理及び実際的な応用を最もよく説明し、考えられる特定の用途に適するような種々の修正を伴う種々の実施形態に関して当業者が本発明を理解することを可能にするために、選択され説明されたものである。

実施形態を実装することができるデータ処理システムのネットワーク図である。 実施形態を実装することができるデータ処理システムのブロック図である。 実施形態に従った、構成及び配備用のアクティブ・リポジトリを使用する、合成ベースのサービス管理インフラストラクチャを示す図である。 実施形態に従った、アクティブ・リポジトリのコンポーネントを示す図である。 実施形態に従った、サービス用のオブジェクト依存関係グラフを例示する図である。 実施形態に従った、複合サービスを管理するためのマクロ・レベル制御を示す図である。 実施形態に従った、一の複合ソフトウェア・サービスを合成し且つ管理するために使用される動作のフローチャートである。 実施形態に従った、一のアクティブ・テンプレート用のサービス合成のためのフローチャートである。 実施形態に従った、一のアクティブ・オブジェクト用のサービス合成のためのフローチャートである。 実施形態に従った、一のアクティブ・オブジェクト用のサービス分解のためのフローチャートである。 実施形態に従った、一のアクティブ・オブジェクト用のサービス分解のためのフローチャートである。 実施形態に従った、一のアクティブ・オブジェクト用のサービス分解のためのフローチャートである。 実施形態に従った、一のアクティブ・オブジェクト用のサービス分解のためのフローチャートである。

Claims (15)

1. コンピュータの処理によって、一の複合サービスを作成するための方法であって、
   一のサービス要求通知を処理するようにインスタンス化された一のサービス・コンポーネントを管理すべき一のアクティブ・オブジェクト用の一のアクティブ・テンプレートにして、一のアクティブ・オブジェクトを含む一のアクティブ・テンプレートを識別するステップと、
   前記インスタンス化されたサービス・コンポーネントを管理すべき前記識別されたアクティブ・テンプレートにおいて一の新しいアクティブ・オブジェクトをインスタンス化するか否かを決定するステップと、
   一の新しいアクティブ・オブジェクトをインスタンス化するとの肯定的な決定に応答して、前記サービス要求通知のサービス状態を有する当該新しいアクティブ・オブジェクトを生成するステップと、
   前記サービス・コンポーネントを一の所望の状態、すなわち前記インスタンス化されたサービス・コンポーネントの一の所望の振る舞いを達成するために必要とされる前記サービス状態において、一の所望の状態を達成することによりコンポーネント特有のサービスを提供すべく管理するように、前記新しいアクティブ・オブジェクトの前記サービス状態を構成するステップと、
   前記インスタンス化されたサービス・コンポーネントから必要とされる一のサービスの使用可能性に基づく一の肯定確認を、前記新しいアクティブ・オブジェクトから送るステップと、
   一の新しいアクティブ・オブジェクトをインスタンス化しないとの否定的な決定に応答して、既存の一のアクティブ・オブジェクトの一のサービス状態を一の現在の状態からそれとは異なる一の所望の状態、すなわち前記インスタンス化されたサービス・コンポーネントの一の所望の振る舞いを達成するために必要とされる前記サービス状態に再構成するステップと、
   前記複合サービスの満たされていない依存関係を検出するステップと、
   前記複合サービスの前記満たされていない依存関係を分析するステップと、
   前記満たされていない依存関係を満たすように、使用可能なサポーティング・サービス及び使用可能なサポーティング資源を前記複合サービスと整合化させるステップと、
   を含む、方法。
2. 前記複合サービスに関連するサポーティング・サービス及びサポーティング資源をオンライン化するために満たさなければならないような依存関係を識別するステップをさらに含み、前記依存関係が、一の依存関係グラフを使用して識別される、請求項１に記載の方法。
3. 前記整合化させるステップが、
   前記使用可能なサポーティング・サービス及び前記使用可能なサポーティング資源を前記複合サービスと完全に又は部分的に整合化させるステップをさらに含む、請求項１に記載の方法。
4. ビジネス目標を満たすように、前記サポーティング・サービス及び前記サポーティング資源の一の使用を計画するステップと、
   制約に基づき一のグローバル最適化を実行するステップとをさらに含む、請求項２に記載の方法。
5. 前記依存関係、要件、使用可能なサポーティング・サービス、使用可能なサポーティング資源、ポリシ、コンポーネントのプリファレンス及びビジネス目標に基づき、前記制約を策定するステップをさらに含む、請求項４に記載の方法。
6. 前記依存関係を識別する一の依存関係グラフを作成するステップをさらに含む、請求項２に記載の方法。
7. 前記サポーティング・サービス及び一の資源プール内の前記サポーティング資源の変更に応答して、前記複合サービスを連続的にサポートするステップをさらに含む、請求項２に記載の方法。
8. 前記複合サービス、前記サポーティング・サービス及び前記サポーティング資源が、一の分散ネットワークの一部であり、アクティブ・オブジェクトが一のアクティブ・リポジトリ内に格納される、請求項２に記載の方法。
9. 前記複合サービスを分解するためのステップをさらに含み、
   当該分解するためのステップが、
   一のイベントを受け取ることに応答して、識別されたサービスを管理すべき１セットのアクティブ・オブジェクトを利用することにより、コンポーネント及び依存関係を識別するステップを含み、
   前記イベントが、一のポリシ、前記複合サービスを分解するための管理者コマンド及び一のコンポーネントの障害のうちの１つによってトリガされ、
   一のシステムによって提供される他の複合サービスに影響しないように、前記１セットのアクティブ・オブジェクトを使用して前記複合サービスを系統的に分解するステップをさらに含む、請求項１に記載の方法。
10. 前記複合サービスの一の状態内に一の変更を導入することにより、前記サポーティング・サービス及び前記サポーティング資源に関連する前記複合サービスを配備するステップと、
    前記複合サービスの前記状態内に前記変更を導入することにより、前記複合サービスを分解するステップとをさらに含む、請求項２に記載の方法。
11. データ処理システムであって、
    バス・システムと、
    前記バス・システムに接続された通信システムと、
    前記バス・システムに接続され且つ１セットの命令及び一の複合サービスを含むメモリと、
    前記メモリに通信可能に接続された処理ユニットとを備え、
    前記処理ユニットが、前記１セットの命令を実行することにより、
    一のサービス要求通知を処理するようにインスタンス化された一のサービス・コンポーネントを管理すべき一のアクティブ・オブジェクト用の一のアクティブ・テンプレートにして、一のアクティブ・オブジェクトを含む一のアクティブ・テンプレートを識別し、
    前記インスタンス化されたサービス・コンポーネントを管理すべき前記識別されたアクティブ・テンプレートにおいて一の新しいアクティブ・オブジェクトをインスタンス化するか否かを決定し、
    一の新しいアクティブ・オブジェクトをインスタンス化するとの肯定的な決定に応答して、前記サービス要求通知のサービス状態を有する当該新しいアクティブ・オブジェクトを生成するステップと、
    前記サービス・コンポーネントを一の所望の状態、すなわち前記インスタンス化されたサービス・コンポーネントの一の所望の振る舞いを達成するために必要とされる前記サービス状態において、一の所望の状態を達成することによりコンポーネント特有のサービスを提供すべく管理するように、前記新しいアクティブ・オブジェクトの前記サービス状態を構成し、
    前記インスタンス化されたサービス・コンポーネントから必要とされる一のサービスの使用可能性に基づく一の肯定確認を、前記新しいアクティブ・オブジェクトから送り、
    一の新しいアクティブ・オブジェクトをインスタンス化しないとの否定的な決定に応答して、既存の一のアクティブ・オブジェクトの一のサービス状態を一の現在の状態からそれとは異なる一の所望の状態、すなわち前記インスタンス化されたサービス・コンポーネントの一の所望の振る舞いを達成するために必要とされる前記サービス状態に再構成し、
    前記複合サービスの満たされていない依存関係を検出し、
    前記複合サービスの前記満たされていない依存関係を分析し、
    前記満たされていない依存関係を満たすように、使用可能なサポーティング・サービス及び使用可能なサポーティング資源を前記複合サービスと整合化させる、
    データ処理システム。
12. 一の複合サービスを作成する機能をコンピュータに実現させるためのコンピュータ・プログラムであって、
    一のサービス要求通知を処理するようにインスタンス化された一のサービス・コンポーネントを管理すべき一のアクティブ・オブジェクト用の一のアクティブ・テンプレートにして、一のアクティブ・オブジェクトを含む一のアクティブ・テンプレートを識別するためのコンピュータ使用可能なプログラム・コードと、
    前記インスタンス化されたサービス・コンポーネントを管理すべき前記識別されたアクティブ・テンプレートにおいて一の新しいアクティブ・オブジェクトをインスタンス化するか否かを決定するためのコンピュータ使用可能なプログラム・コードと、
    一の新しいアクティブ・オブジェクトをインスタンス化するとの肯定的な決定に応答して、前記サービス要求通知のサービス状態を有する当該新しいアクティブ・オブジェクトを生成するためのコンピュータ使用可能なプログラム・コードと、
    前記サービス・コンポーネントを一の所望の状態、すなわち前記インスタンス化されたサービス・コンポーネントの一の所望の振る舞いを達成するために必要とされる前記サービス状態において、一の所望の状態を達成することによりコンポーネント特有のサービスを提供すべく管理するように、前記新しいアクティブ・オブジェクトの前記サービス状態を構成するためのコンピュータ使用可能なプログラム・コードと、
    前記インスタンス化されたサービス・コンポーネントから必要とされる一のサービスの使用可能性に基づく一の肯定確認を、前記新しいアクティブ・オブジェクトから送るためのコンピュータ使用可能なプログラム・コードと、
    一の新しいアクティブ・オブジェクトをインスタンス化しないとの否定的な決定に応答して、既存の一のアクティブ・オブジェクトの一のサービス状態を一の現在の状態からそれとは異なる一の所望の状態、すなわち前記インスタンス化されたサービス・コンポーネントの一の所望の振る舞いを達成するために必要とされる前記サービス状態に再構成するためのコンピュータ使用可能なプログラム・コードと、
    前記複合サービスの満たされていない依存関係を検出するためのコンピュータ使用可能なプログラム・コードと、
    前記複合サービスの前記満たされていない依存関係を分析するためのコンピュータ使用可能なプログラム・コードと、
    前記満たされていない依存関係を満たすように、使用可能なサポーティング・サービス及び使用可能なサポーティング資源を前記複合サービスと整合化させるためのコンピュータ使用可能なプログラム・コードと、
    を含む、コンピュータ・プログラム。
13. 前記複合サービスのコンポーネントを識別するためのコンピュータ使用可能なプログラム・コードと、
    前記識別されたコンポーネントを構成することにより、前記複合サービスを一の現在の状態から一の所望の状態に変更するためのコンピュータ使用可能なプログラム・コードとをさらに含む、請求項１２に記載のコンピュータ・プログラム。
14. 一の依存関係ツリーから前記複合サービスを形成するためのコンピュータ使用可能なプログラム・コードをさらに含み、
    前記複合サービスの前記識別されたコンポーネントが、一のアクティブ・リポジトリ内のアクティブ・オブジェクト及びアクティブ・テンプレートである、請求項１３に記載のコンピュータ・プログラム。
15. 前記アクティブ・リポジトリが、１セットの複合サービスをアクティブに管理し、前記１セットの複合サービスが、デマンドに基づき、前記１セットの複合サービスを作成し、更新し、分解することにより管理される、請求項１４に記載のコンピュータ・プログラム。

Images