JP5278924B2 - データ処理環境における動的プロビジョニングのための方法および装置 - Google Patents

Description

本発明は、一般に、データ処理システム、サービス指向アーキテクチャ、およびユーザ・インターフェースに関する。より具体的に言えば、本発明は、サービス送達環境などのデータ処理システム環境において、ソリューションのプロビジョニング（provisioning）中に使用されることになる、新しいコンポーネントの動的導入のための装置およびコンピュータ方法を提供する。

サービス指向アーキテクチャの人気が高まるにつれて、サービス中心モデルを備えたソリューションが開発されてきている。データセンタ環境においてサービス・ベースのソリューションを開発する必要がある場合、プロビジョニングは、ソリューションが使用するすべてのサービスが提供および開始されていることを確認しなければならない。これを実行しないと、ソリューションはランタイム時に障害を起こすことになる。

既存のシステムは、システムが実装された時点で定義されているコンポーネントをサポートする。これらのコンポーネントでは、パラメータと依存性の両方がよく知られている。しかしながら、ソリューションが複雑になると、ホスティング環境が出荷された時点での、すべての必須コンポーネントおよびそれらの要件を統計的に定義できなくなる。

各必須条件およびそのパラメータに関する情報を収集するために使用される画面が、従来のユーザ・インターフェースを介して定義される場合、コンポーネントが導入され、その後、プロビジョニング要求の提出時にユーザに提示される選択画面でこの情報を使用する際に、各サービス／コンポーネントの要件を指定できることが必要である。要求を提出するユーザが、サービス／コンポーネントを定義するユーザとは異なる役割および専門知識を有することから、必要な知識を持たない可能性があるため、サービスが導入される際に各パラメータに関する規制も定義しなければならない。

残念ながら、従来のプロビジョニング・システムおよびユーザ・インターフェースは、実行時のコンポーネントの追加に適切に対処していない。

本発明の原理は、サービス送達環境などのデータ処理システム環境においてソリューションのプロビジョニング時に使用されることになる、新しいコンポーネントの動的導入に関する技法を提供する。

たとえば、データ処理システムにおけるコンポーネントのプロビジョニングを管理するプロビジョニング・システムでは、データ処理システムにおいて１つまたは複数の新しいコンポーネントを動的にプロビジョニングする自動的な方法が、以下のステップを実行するプロビジョニング・システムを備える。プロビジョニング・システムは、データ処理システムのランタイム期間中に新しいコンポーネントの登録を受け入れるが、この新しいコンポーネントは、ランタイム期間以前にはデータ処理システムに登録されておらず、さらにこの登録は、１つまたは複数の必須条件のうちの少なくとも１つと新しいコンポーネントに関連付けられた構成とに関する情報を得ることを含む。プロビジョニング・システムは、プロビジョニング要求に応答して、登録済みの新しいコンポーネントの選択を許可する。プロビジョニング・システムは、登録済みの新しいコンポーネントの内部での使用を可能にすることによって、データ処理システムへの修正（たとえば拡張）を生じさせる。

例を挙げると、サービス送達環境におけるプロビジョニング要求の提出には、ホストされたソリューションによって要求されたサービスおよびミドルウェア・コンポーネントの選択が含まれる。これらの要件は、必須ミドルウェア（たとえばデータベース、プロセス、およびポータル・サーバなど）ならびにサービス・コンポーネント（セキュリティ、モニタリングなど）の指定を含むことができる。これらの必須コンポーネントおよびサービスのそれぞれを指定する場合、ユーザは、構成パラメータ（たとえばサーバの位置、ポート、ユーザ識別子、パスワードなど）を指定する。これらのパラメータは、各ミドルウェア・コンポーネントによって異なる。

有利なことに、本発明の原理は、サービス送達環境においてソリューションのプロビジョニング時に使用されることになる新しいコンポーネントを動的に導入するための技法を提供するため、結果として既存の技法の欠点が緩和または除去される。たとえばこれは、コンポーネントの必須条件および構成のメタデータ記述を提供し、その後、この情報をコンポーネントのプロビジョニングで使用する一方で、ランタイム時に新しいプロビジョニング・コンポーネントの動的導入を可能にする、プロビジョニング・システムによって実施される。

本発明のこれらおよび他の目的、特徴、および利点は、添付の図面に関連して読まれることになる、その例示的諸実施形態についての以下の詳細な説明から明らかとなろう。

内部で例示的諸実施形態が実装可能なデータ処理システムのネットワークを示す模式図である。 内部で例示的諸実施形態が実装可能なデータ処理システムを示すブロック図である。 例示的実施形態に従った、管理システムの論理アーキテクチャを示す概略図である。 例示的実施形態に従った、プロビジョニング・システムへの新しいコンポーネントの導入時に使用される、サンプルＸＭＬ記述子の例を示す図である。 例示的実施形態に従った、プロビジョニング・システムへの新しいコンポーネントの導入時に使用される、サンプルＸＭＬ記述子の例を示す図である。 例示的実施形態に従った、新しいコンポーネントおよびサービスの登録時に実行される諸ステップを示す流れ図である。 例示的実施形態に従った、プロビジョニング要求の提出のユーザ・インターフェース提出において、登録済みのコンポーネントおよびサービスの選択時に実行される諸ステップを示す流れ図であり、フロー全体を実証する。 例示的実施形態に従った、プロビジョニング要求の提出のユーザ・インターフェース提出において、登録済みのコンポーネントおよびサービスの選択時に実行される諸ステップを示す流れ図であり、例示的実施形態に従った、個々のコンポーネントについてそれぞれ反復される諸ステップに関する、図６のステップ６０６をさらに詳細に示す。 例示的実施形態に従った、既存の環境の拡張時に実行される諸ステップを示す流れ図である。

「ランタイム」という用語は、一般に、プログラムが実行を開始した時間から終了した時間までの、コンピュータ・プログラム（またはシステム）の動作を言い表すことを理解されよう。具体的に言えば、本発明の原理により、「ランタイム」という用語は、依然として設計および開発されている期間ではなく、（その設計および実装に対する変更がもはや実行できない製品において）システムが実際に顧客によって使用された時間を言い表す。

好ましい実施形態では、「コンポーネント」という用語は、１つまたは複数のコンピュータ上に別々にインストール可能であり、その後、他のミドルウェア・コンポーネントまたはアプリケーションによって使用可能な、１片のミドルウェアを言い表す。たとえば、コンポーネントは、Ｏｒａｃｌｅ（Ｒ）データベース・サーバ、ＩＢＭ Ｆｉｌｅｎｅｔ（Ｒ）、またはＷｅｂｌｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（Ｒ）などによって実行される、ソフトウェアとすることができる。より一般的なケースでは、「コンポーネント」は、他のコンポーネントまたはソリューションによる使用のためにインストールおよび構成可能ないずれのものにも適用可能である。

好ましい実施形態では、「ソリューション」という用語は、Ｈｕｍａｎ Ｒｅｓｏｕｒｃｅ（Ｒ）アプリケーション、オンライン・バンキング・アプリケーション、またはローン承認アプリケーションなどの、特定のビジネス機能を提供するソフトウェア・アプリケーションを言い表す。ソリューションは、通常、すでにインストールされたミドルウェア・コンポーネントのトップの１つまたは複数のコンピュータ・システム上に配置される。より一般的なケースでは、「ソリューション」という用語は、特定のビジネス機能を提供する、他のすでにプロビジョニング済みのコンポーネントを必須条件として使用する、コンポーネント・セットを言い表すことができる。

諸図面を参照、特に図１〜図２を参照すると、内部で諸実施形態が実装可能なデータ処理環境の例示的な図が提供されている。図１〜図２は単なる例であり、内部で諸実施形態が実装可能な環境に関して、いかなる制限もアサートまたは示唆する旨を意図していないことを理解されたい。示された諸実施形態への多くの修正が、例示的諸実施形態の趣旨および範囲を逸脱することなく実行可能である。

次に図面を参照すると、図１は、内部で諸実施形態が実装可能な、データ処理システムのネットワークの絵画図を示す。ネットワーク・データ処理システム１００はネットワーク１０２を含み、これは、ネットワーク・データ処理システム１００内で共に接続された様々なデバイスとコンピュータとの間に通信リンクを提供するために使用される媒体である。ネットワーク１０２は、有線、無線通信リンク、または光ファイバ・ケーブルなどの、接続を含むことができる。

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

示された例では、ネットワーク・データ処理システム１００は、互いに通信するためのプロトコルの伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）スイートを使用する、ネットワークおよびゲートウェイの世界規模の集まりを表すネットワーク１０２を備えたインターネットである。インターネットの中心は、データおよびメッセージをルーティングする何千もの商用、公用、教育用、およびその他のコンピュータ・システムからなる主要ノードまたはホスト・コンピュータ間の、高速データ通信回線のバックボーンである。もちろん、ネットワーク・データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）などの、多数の異なるタイプのネットワークとしても実装可能である。図１は例として意図され、様々な諸実施形態に対するアーキテクチャ上の制限として意図されるものではない。

次に図２を参照すると、内部で例示的諸実施形態が実装可能なデータ処理システムのブロック図が示されている。データ処理システム２００は、諸実施形態に関するプロセスを実装するコンピュータ使用可能コードまたは命令が内部に配置可能な、図１におけるサーバ１０４またはクライアント１１０などの、コンピュータの例である。

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

示された例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２はサウス・ブリッジおよびＩ／Ｏコントローラ・ハブ２０４に結合され、オーディオ・アダプタ２１６、キーボードおよびマウス・アダプタ２２０、モデム２２２、読み取り専用メモリ（ＲＯＭ）２２４、ユニバーサル・シリアル・バス（ＵＳＢ）ポートおよび他の通信ポート２３２、ならびにＰＣＩ／ＰＣＩｅデバイス２３４は、バス２３８を介してサウス・ブリッジおよびＩ／Ｏコントローラ・ハブ２０４に結合され、ハード・ディスク・ドライブ（ＨＤＤ）２２６およびＣＤ−ＲＯＭドライブ２３０はバス２４０を介してサウス・ブリッジおよびＩ／Ｏコントローラ・ハブ２０４に結合される。ＰＣＩ／ＰＣＩｅデバイスは、たとえばＥｔｈｅｒｎｅｔ（Ｒ）アダプタ、アドイン・カード、およびノートブック・コンピュータ用のＰＣカードを含むことができる。ＰＣＩはカード・バス・コントローラを使用するが、ＰＣＩｅは使用しない。ＲＯＭ ２２４は、たとえばフラッシュ・バイナリ入力／出力システム（ＢＩＯＳ）とすることができる。ハード・ディスク・ドライブ２２６およびＣＤ−ＲＯＭドライブ２３０は、たとえばインテグレーテッド・ドライブ・エレクトロニクス（ＩＤＥ）またはシリアル・アドバンスト・テクノロジ・アタッチメント（ＳＡＴＡ）インターフェースを使用することができる。スーパＩ／Ｏ（ＳＩＯ）デバイス２３６は、サウス・ブリッジおよびＩ／Ｏコントローラ・ハブ２０４に結合することができる。

オペレーティング・システムはプロセッサ２０６上で実行され、図２のデータ処理システム２００内の様々なコンポーネントの制御を調整および提供する。オペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ（Ｒ） Ｗｉｎｄｏｗｓ（Ｒ） ＸＰ（ＭｉｃｒｏｓｏｆｔおよびＷｉｎｄｏｗｓは、米国、諸外国、またはその両方における、マイクロソフト社の商標である）などの、市販のオペレーティング・システムとすることができる。Ｊａｖａ（ＴＭ）プログラミング・システムなどのオブジェクト指向プログラミング・システムは、オペレーティング・システムに関して実行可能であり、データ処理システム２００上で実行中のＪａｖａのプログラムまたはアプリケーションからオペレーティング・システムへの呼び出しを提供する（ＪａｖａおよびすべてのＪａｖａベースの商標は、米国、諸外国、またはその両方における、サン・マイクロシステムズ社の商標である）。

オペレーティング・システムに関する命令、オブジェクト指向プログラミング・システム、およびアプリケーションまたはプログラムは、ハード・ディスク・ドライブ２２６などのストレージ・デバイス上に配置され、プロセッサ２０６による実行のためにメイン・メモリ２０８へロードすることができる。例示的諸実施形態のプロセスは、たとえばメイン・メモリ２０８、読み取り専用メモリ２２４、または１つまたは複数の周辺デバイスなどの、メモリ内に配置することが可能な、コンピュータ実装命令を使用して、プロセッサ２０６によって実行可能である。

図１〜図２のハードウェアは、実装によって変更可能である。図１〜図２に示されたハードウェアに加えて、またはこれに代わって、フラッシュ・メモリ、等価の不揮発性メモリ、または光ディスク・ドライブなどの、他の内部ハードウェアまたは周辺デバイスを使用することができる。また、例示的諸実施形態のプロセスは、マルチプロセッサ・データ処理システムに適用することもできる。

いくつかの例では、データ処理システム２００は、オペレーティング・システム・ファイルあるいはユーザ生成データまたはその両方を格納するための不揮発性メモリを提供するために一般にフラッシュ・メモリを用いて構成される、携帯情報端末（ＰＤＡ）とすることができる。バス・システムは、システム・バス、Ｉ／Ｏバス、およびＰＣＩバスなどの、１つまたは複数のバスからなるものとすることができる。もちろん、バス・システムは、ファブリックまたはアーキテクチャに接続された異なるコンポーネント間またはデバイス間にデータの転送を提供する、任意のタイプの通信ファブリック（communications fabric）またはアーキテクチャを使用して実装することができる。通信ユニットは、モデムまたはネットワーク・アダプタなどの、データの送受信に使用される１つまたは複数のデバイスを含むことができる。メモリは、たとえば、メイン・メモリ２０８、またはノース・ブリッジおよびメモリ・コントローラ・ハブ２０２内に見られるようなキャッシュとすることができる。処理ユニットは、１つまたは複数のプロセッサまたは中央処理ユニット（ＣＰＵ）を含むことができる。図１〜図２に示された例および前述の例は、アーキテクチャ上の制限を示唆することを意味するものではない。たとえば、データ処理システム２００は、ＰＤＡの形を取ることに加えて、タブレット・コンピュータ、ラップトップ・コンピュータ、または電話デバイスとすることもできる。

例示的諸実施形態は、コンピュータ実装方法、データ処理システム、および、ソース・コードをコンパイルするためのコンピュータ使用可能プログラム・コードを提供する。例示的諸実施形態のコンピュータ実装方法は、図１に示されたデータ処理システム１００、または図２に示されたデータ処理システム２００などの、データ処理システム内で実行可能である。

図３は、例示的実施形態に従ったシステムの論理アーキテクチャの概略図を示す。処理は、（１）新しいコンポーネントおよびサービスの登録、（２）プロビジョニング要求の提出におけるユーザ・インターフェース内の登録済みコンポーネントおよびサービスの選択、ならびに（３）既存の環境の拡張という、３つのメイン・セクションに分けられる。ユーザは、管理ユーザ・インターフェース（３０１）を介して、または、事前に定義されたフォーマットでコンポーネント記述子をコンポーネント登録マネージャ（３０４）に直接提供することによって、新しいコンポーネントをシステムに導入する。好ましい実施形態では、コンポーネント記述はＸＭＬ（拡張可能マークアップ言語）で指定されるが、当業者であれば、コンポーネントを記述する他の方法（たとえば、統一モデリング言語すなわちＵＭＬ、テキスト、ＪＡＶＡ（Ｒ）プロパティ・ファイル）も見つけられよう。新しいコンポーネントがユーザ・インターフェースすなわちＵＩ（３０１）を介して導入された場合、管理ユーザ・インターフェース（３０１）のコンポーネント登録処理サブコンポーネント（３０２）は情報を処理し、コンポーネント記述子をコンポーネント登録マネージャ（３０４）に渡す。コンポーネント登録マネージャ（３０４）は、データ・マネージャ（３０５）を使用して、コンポーネント記述子を処理し、新しいコンポーネントと既存のコンポーネントとの間の相互参照を生成し、この情報をデータベース（３０６）に格納する。さらにポリシー・マネージャ（３０７）を使用して、新しいコンポーネントのポリシーを処理し、それらをリポジトリ（３０８）に保存する。コンポーネント記述子内に存在可能なポリシーの例は、単一ミドルウェア・スタック上に配置されたすべてのソリューション（オファリング）にわたって、または単一ソリューションのすべてのテナント（tenant）（ユーザ）にわたって、プロビジョニング・システム内のすべてのミドルウェア・スタックでコンポーネントが共有可能であるかどうかを指定する、共有ポリシーである。他のポリシーの例は、コンポーネントを他のコンポーネントと同じブレード上に配置できるかどうか、および配置できる場合はどのコンポーネントと連結できるかを記述する、連結（collocation）ポリシーである。

前述のようにコンポーネントがシステムに導入された後、新しいミドルウェア・スタックのプロビジョニングのため、または既存の環境の拡張のために、選択することができる。ユーザは、管理ユーザ・インターフェース（３０１）のプロビジョニング画面（３０３）を使用して、完全なミドルウェア・スタックをプロビジョニングするか、または新しいコンポーネントを用いて既存のスタックを拡張する。好ましい実施形態では、プロビジョニングＵＩ（３０３）は、各コンポーネントの情報が別々の画面上に表示されるウィザードと共に実装されるが、当業者であれば他の実装も実現可能である。

コンポーネントが選択され、それらの構成が選択されると、選択されたサーバ上に選択されたそれぞれのコンポーネントをプロビジョニングする旨の要求が、プロビジョニング・マネージャ（３０９）に渡される。たとえば図３では、ユーザは、プロセス・サーバ（３１０）、ＤＢ２を使用するポータル・サーバ（３１５）、コンテンツ・マネージャおよびその必須条件（３１２）、ＷｅｂＳｐｈｅｒｅ Ｅｄｇｅ（Ｒ）コンポーネント（３１３）をプロビジョニングし、リモートの測定および監視サービス（３１４）を使用するように選択した。

図４Ａおよび図４Ｂは、新しいコンポーネントまたはサービスの登録時に使用可能な、コンポーネント記述子の例を示す。それぞれの新しいコンポーネントまたはサービスは、（ＵＩ上にパラメータを入力すること、または配置記述子を含めること、あるいはそれら両方の組み合わせによって）登録時に指定された以下の情報を有することになる。
−サービス／コンポーネント名およびバージョン
−プロビジョニング要求をどのように提出する必要があるかを示す、共有サービス／ミドルウェア・コンポーネント・フラグ。共有サービスはリモート・サービスとすることが可能であるため、それらのためのサーバはリモートＵＲＬ（ユニフォーム・リソース・ロケータ）とすることができる。
−共有ポリシー オファリング／テナントにわたって、すべてのミドルウェア・スタックにわたって、など。
−ＵＩでは、プロビジョニング用のサーバを選択する場合、すでにコンポーネントをインストールしてあるサーバを使用できるかどうかを決定するために、具体的に使用される。
−事前インストール済みフラグ 事前にインストールされた新しいコンポーネントであるか、または、ソリューション・ホスティングのためにミドルウェア・スタックがプロビジョニングされる場合にプロビジョニングする／できる必要がある。
−ミドルウェア・スタックのインストール時にこのコンポーネントが選択された場合、どのサーバが表示されるかに影響を与える。
−必須要件
−ローカル必須条件 同じマシン上にインストールされている。必須条件はすでにＵＩにとって「既知」であり、コンポーネントが導入される場合に選択されなければならない。
−リモートにアクセス可能な必須条件／依存性 セル内（たとえばＷｅｂＳＥＡＬおよびＴＡＭ）に存在しなければならない他のコンポーネント（名前およびバージョン）のリスト。（他の実施形態では、関係コンポーネントのグループをまとめて導入することができる。）
−連結ポリシー 他のコンポーネントと同じサーバ上に配置可能である、たとえば必須バージョンが競合する場合は動的に決定することも可能である、あるいはハードウェア要件に基づくことができる。
−ハードウェア要件（連結ポリシーの決定時に使用可能）
−必要なサーバのタイプ：好ましい実施形態では、サーバはそれらの使用、連結、および配置（たとえばファイアウォール背後）に基づいて、３つのプールに分けられる−ＴＰＭ（プロビジョニングに使用されるサーバ）、ＷｅｂＳｅａｌサーバ（ファイアウォール背後であり、ＷｅｂＳｅａｌをホストするためにのみ使用される）。
−追加サーバの数： プロビジョニング時にこのコンポーネントに必要な、１、「０またはそれ以上」など（ＵＩは複数選択が可能となる）。
−従来技術に存在するＵＩタイプ定義と同様に、入力妥当性検査に関するタイプ（ｉｎｔ／ｕｒｌ／ｅｍａｉｌ／ｍａｘ ｌｅｎｇｔｈ／ｐｏｒｔ）を備えた、ＵＩ（サーバ以外）上に提供される必要のある追加パラメータのリスト。
−すでにプロビジョニングされたミドルウェア・スタックに追加することが可能であるか？

追加のパラメータについて考慮することができる。いくつかの実施形態では、前述のパラメータのうちの一部のみを入力すればよく、その他はデフォルトに設定することができる。他の実施形態では、ＵＩ内に配置記述子の位置を指定することが可能であり、追加のパラメータはこの記述子から読み取る。さらに複雑なケースでは、記述子は、ユーザ・インターフェース上にフィールドを提示する（またはフィールド情報を得るためにアプリケーション・プログラミング・インターフェースすなわちＡＰＩを提供する）こと、あるいはそれ自体の妥当性検査またはサーバ選択手順を実行することの、両方が可能な、プロセッサへのリンク（たとえばＪａｖａクラス）を含むことができる。

図５は、新しいコンポーネント処理の第１の選択、新しいコンポーネントまたはサービスの登録を示す流れ図である。

図５の５Ａに示されたＵＩベースの登録では、ステップ（５０１）で、ユーザは、管理ＵＩ（３０１）の新しいコンポーネントの特徴を定義するように選択し、前述のようにコンポーネント情報を入力し、ＵＩ（３０１）によって提供されたすでに登録済みのコンポーネントのリストから必須条件を選択する（５０２）。必要な必須条件が見つからない場合、このステップでも登録することができる。管理ＵＩのコンポーネント登録サブコンポーネント（３０２）は、情報の最低処理を実行した後、コンポーネント登録マネージャ（３０４）に渡す（５０３）。コンポーネント登録マネージャは、ステップ５０４で、この情報を処理し、新しいコンポーネントおよびその必須条件を相互参照し、関連ポリシーを抽出した後、ポリシー・マネージャ（３０７）およびデータ・マネージャ（３０５）を使用して情報をデータベース（３０６、３０８）に格納する。代替実施形態では、すべての処理をユーザ・インターフェースによって実行すること、または追加のプロセッサを使用することができる。

図５の５Ｂのように、配置記述子およびコマンド行インターフェースを使用する登録では、ユーザは配置記述子を作成し（５０５）、コマンドを発行してコンポーネントを登録する（５０６）。コマンドは、前述のようにコンポーネントを登録する（５０４）コンポーネント登録マネージャ（３０４）を呼び出す。

図６および図７は、コンポーネント処理の第２セクション、すなわちプロビジョニング要求提出時のＵＩにおける登録済みコンポーネントおよびサービスの選択を示す流れ図である。図６は処理全体を示し、図７は個々のコンポーネントそれぞれの処理（ステップ６０６）の詳細である。

図６では、ユーザはステップ６０１で、プロビジョニング要求を提出するためのオプションを使用する。ステップ６０２では、ユーザは、管理ＵＩ（３０１）を使用して必要なコンポーネントおよびサービスを選択することができる。ユーザがコンポーネントおよびサービスを選択（６０２）した後、管理ＵＩ（３０１）は、各コンポーネントに関する必須条件を検証し、必要であれば、必須のコンポーネントをリストに追加する（６０３）。その後、管理ＵＩ（３０１）は、ユーザから必要な構成情報を引き出すために必要なウィザード画面を決定する（６０４）。好ましい実施形態では、各コンポーネントを選択すると、結果としてウィザード画面が生じることになる。代替実施形態では、情報を単一ページ上に提示することができる。さらに他の実施形態では、関連するコンポーネントは単一画面上にグループ化する一方で、関連しないコンポーネントには異なる画面を使用することができる。物理サーバごとまたは必須条件ごとにグループ化するなどの、他の実施形態も可能である。各コンポーネントおよびサービスについて、コンポーネントの画面コンテンツは登録時（図５）に供給されたメタデータによって定義される。その後、ユーザには、個々の画面がそれぞれ提示される（６０５〜６０７）。次のコンポーネントの画面に関する情報が取得され（６０６）、画面コンテンツが決定され、ユーザ入力が取得される（６０７、図７）。すべてのコンポーネントが処理された場合（６０８）、プロビジョニング・マネージャ（３０９）にプロビジョニング要求が提出される（６０９）。

図７は、図６のステップ６０６で参照された個々のコンポーネントそれぞれの処理を詳細に示す。個々のコンポーネントそれぞれについて、図５で説明されたように登録時に供給されたメタデータに基づいて画面コンテンツが定義される。第１に、データ・マネージャ（３０５）からコンポーネント・メタデータが取得される（６０９）。「事前インストール済み」フラグが「ｔｒｕｅ」に設定されている場合、コンポーネントはすでにインストールされている。この場合、ユーザがコンポーネントのサーバ名またはＵＲＬ（メタデータに定義されているとおり）を入力できる入力フィールドが、画面上に表示される（６１１）。メタデータ内の「事前インストール済み」フラグが「ｆａｌｓｅ」に設定されている場合（６１０）、サーバ選択ウィジェットが提供される。選択に使用可能なサーバのリストは、メタデータ設定値によってフィルタリングされるサーバのリストを含む。ステップ６１２で、データ・マネージャ（３０５）およびポリシー・マネージャ（３０７）を使用して、コンポーネント・サーバ選択メタデータおよび共有ポリシーが取得される。ステップ６１３で、指定されたグループ（たとえば、ＤＭＺ、アプリケーション・ゾーン、管理ゾーンなど）内で使用可能なサーバのリストが、データ・マネージャ（３０５）を介してデータベース（３０６）から取得され、このリストは、ステップ６１２でデータベースから取得されるＯＳおよび容量の要件によって、さらに制限することができる。加えて、このリストは、使用可能な各サーバ上にすでにインストールされているソフトウェアおよびこの要求において計画された配置に照らした必須条件チェックによって、さらに限定することができる。たとえば、Ｌｉｎｕｘ（Ｒ）サーバのみ、または特定の容量を備えたサーバ、またはすでに必須条件がインストールされたサーバを、受け入れることができる。ポリシー・マネージャ（３０７）から取得されたポリシーが、コンポーネントに関する「共有」フラグが「ｔｒｕｅ」に設定されていることを示す場合（６１４）、このコンポーネントまたはサービスの既存のインストレーションを備えたサーバがリストに追加される（６１５）。既存のインストレーションを備えたサーバのリストも、ロードおよびセキュリティなどの管理ポリシーによって、潜在的に制限される。リストが最終決定されると、選択ウィジェットが作成される（６１６）。代替実施形態では、ステップ６１１の入力フィールドを、このコンポーネントまたはサービスをインストールしているローカル・サーバのリスト、ならびに入力としてリモート・サーバに入るための機能を含む、選択ウィジェットに置き換えることも可能である。当業者であれば、他の諸実施形態も明らかであろう。

ステップ６１７で、ユーザ入力を必要とするコンポーネントまたはサービスのパラメータおよびそれらのタイプが、データ・マネージャ（３０５）から取得され、サーバ入力フィールド（ステップ６１１から）または選択ウィジェット（６１６）の両方ならびに追加パラメータ（ステップ６１７から）を含む最終画面がユーザに提示され（６１８）、ユーザ入力が取得および妥当性検査される（６１９）。フィールドの形式ならびに妥当性検査は、配置記述子内に指定されデータベース（３０６）に格納されたコンポーネント属性記述に基づく。属性の提示および妥当性検査に関する方法は本開示の範囲外であり、たとえばＸＦｏｒｍまたは他の知られた方法などの従来の作業を使用することができる。

環境が（図６および図７に示されたように）プロビジョニングされると、ソリューションがその環境を共有するが、追加の登録済みコンポーネントまたはサービスを用いて拡張することになる場合が生じる可能性がある。図８は、コンポーネント処理の第３セクション、すなわち既存環境の拡張を示す流れ図である。ここでユーザは、現在配置されているミドルウェア・スタックを検査し、新しいソリューションのプロビジョニングにとって望ましいターゲット環境を選択する（７０１）。ＵＩは、この配置で強化可能な登録済みコンポーネント／サービスのリストを制限する（７０２）。このリストは、記述に従って既存のセルに追加可能であり、現在のセル構成と競合しない、ミドルウェア・コンポーネントを含むことになる。これらは、依然としてプロビジョニングが必要な新しいコンポーネント、あるいは既存の共有コンポーネントまたはサービスの可能性がある。その後、ユーザは、それらのリストされた中から新しいコンポーネントを選択し（７０３）、図６のステップ６０３から、図６および図７に示されたような選択されたコンポーネントに対するパラメータの指定を続行する。

本発明は、完全な異なるハードウェア実施形態、完全なソフトウェア実施形態、またはハードウェアおよびソフトウェアの両方の要素を含む実施形態の形を取ることができる。好ましい実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されない、ソフトウェア内に実装される。

さらに本発明は、コンピュータまたは任意の命令実行システムによって、またはこれらに関連して使用するための、プログラム・コードを提供する、コンピュータ使用可能またはコンピュータ読み取り可能のストレージ媒体からアクセス可能な、コンピュータ・プログラム製品の形を取ることができる。本明細書では、コンピュータ使用可能またはコンピュータ読み取り可能のストレージ媒体は、命令実行システム、装置、またはデバイスによって、またはこれらに関連して使用するための、プログラムを含むかまたは格納することが可能な、任意の有形の装置とすることができる。

媒体は、電子、磁気、光、電磁、赤外線、または半導体のシステム（あるいは装置またはデバイス）とすることができる。コンピュータ読み取り可能ストレージ媒体の例には、半導体またはソリッド・ステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクが含まれる。現行の光ディスクの例には、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが含まれる。

プログラム・コードの格納あるいは実行またはその両方に好適なデータ処理システムは、システム・バスを介してメモリ要素に直接または間接的に結合された、少なくとも１つのプロセッサを含むことになる。メモリ要素は、プログラム・コードの実際の実行時に採用されるローカル・メモリ、大容量ストレージ、および、実行時に大容量ストレージからコードを取り出さなければならない回数を減らすために少なくとも一部のプログラム・コードの一時ストレージを提供するキャッシュ・メモリを、含むことができる。

入力／出力すなわちＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイスなどを含むがこれらに限定されない）は、直接、または介在するＩ／Ｏコントローラを通じて、システムに結合することができる。

データ処理システムを、介在する専用または公衆のネットワークを通じて、他のデータ処理システムあるいはリモートのプリンタまたはストレージ・デバイスに結合できるようにするために、ネットワーク・アダプタをシステムに結合することもできる。モデム、ケーブル・モデム、およびＥｔｈｅｒｎｅｔ（Ｒ）カードは、現在使用可能なネットワーク・アダプタのタイプのごく一部である。

以上、本発明について例示および説明の目的で提示してきたが、本発明を開示された形によって網羅することまたはこの形に限定することは意図していない。当業者であれば、多くの修正および変形が明らかとなろう。実施形態は、本発明の原理、実際の応用例を最も良く説明するため、および、当業者が企図された特定の使用に好適な様々な修正を伴う様々な実施形態に関して本発明を理解できるようにするために、選択および説明されたものである。

本明細書では、本発明の例示的な諸実施形態について添付の図面を参照しながら説明してきたが、本発明はこれらの精密な諸実施形態に限定されるものではないこと、および、当業者であれば、本発明の範囲または趣旨を逸脱することなく様々な変更および修正が可能であることが理解されよう。

Claims (25)

1. データ処理システムにおけるコンポーネントのプロビジョニングを管理するプロビジョニング・システムにおいて、前記データ処理システム内で１つまたは複数の新しいコンポーネントを動的にプロビジョニングする方法であって、前記プロビジョニング・システムが、
   前記データ処理システムのランタイム期間中に、前記データ処理システムに追加されうる新しいコンポーネントの登録を受け入れるステップであって、前記新しいコンポーネントは、前記ランタイム期間以前には前記データ処理システムに登録されていないソフトウェア・コンポーネントであり、及び前記新しいコンポーネントの前記登録は、前記新しいコンポーネントの１つまたは複数の必須条件のうちの少なくとも１つと前記新しいコンポーネントに関連付けられた構成とに関する情報を取得することを含む、前記受け入れるステップと、
   プロビジョニング要求に応答して、前記登録済みの新しいコンポーネントの選択を許可するステップと、
   前記データ処理システムにおいて前記登録済みの新しいコンポーネントの使用を可能にすることによって、前記データ処理システムへの修正を生じさせるステップと
   を実行することを含み、
   前記新しいコンポーネントの前記登録が、
   前記データ処理システム内の既存のすでに登録済みのコンポーネントに関連付けられた対応情報を用いて、前記新しいコンポーネントに関連付けられた前記取得された情報の少なくとも一部を、前記プロビジョニング・システムに関連付けられたコンポーネント登録管理モジュールが相互参照すること
   をさらに含む、前記方法。
2. 前記プロビジョニング・システムが、
   前記１つまたは複数の必須条件のうちの少なくとも１つと前記新しいコンポーネントに関連付けられた前記構成とに関する前記情報を、前記ユーザ・インターフェースを介して前記プロビジョニング・システムにユーザが入力するように、前記新しいコンポーネントの前記登録が、前記プロビジョニング・システムに関連付けられたユーザ・インターフェースを介して、ユーザが前記新しいコンポーネントを登録することを可能にするステップ
   をさらに実行することを含む、請求項１に記載の方法。
3. 前記新しいコンポーネントの前記登録が、
   配置記述子の入力を介して、ユーザが前記新しいコンポーネントを登録することを可能にすること
   をさらに含む、請求項１に記載の方法。
4. 前記コンポーネント登録管理モジュールが、
   前記新しいコンポーネントに適用可能な少なくとも１つのポリシーを決定する、
   請求項１〜３のいずれか一項に記載の方法。
5. 前記適用可能なポリシーが、前記新しいコンポーネントをどのように前記データ処理システム内で共有するかを示す１つまたは複数のポリシーをさらに含む、請求項４に記載の方法。
6. 前記許可するステップが、
   前記プロビジョニング・システムに関連付けられたユーザ・インターフェースを介して、ユーザが前記登録済みの新しいコンポーネントを選択することを可能にするステップ
   をさらに含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記選択に使用される前記ユーザ・インターフェースが、前記ユーザが選択を許可された各登録済みコンポーネントに関する別々の画面をさらに備えている、請求項６に記載の方法。
8. 前記プロビジョニング・システムが、
   前記新しいコンポーネントを、他の新しいコンポーネントをプロビジョニングするための必須条件として使用する、
   請求項１〜７のいずれか一項に記載の方法。
9. 前記新しいコンポーネントが、ミドルウェア・コンポーネント、オペレーティング・システム・コンポーネント、およびハードウェア・コンポーネントのうちの少なくとも１つを含む、請求項１〜８のいずれか一項に記載の方法。
10. 前記取得された情報が、拡張マークアップ言語で記述されたメタデータの形である、請求項１〜９のいずれか一項に記載の方法。
11. 前記必須条件が、ローカル必須条件およびリモート必須条件のうちの少なくとも１つを含む、請求項１〜１０のいずれか一項に記載の方法。
12. 前記必須条件が、前記コンポーネントのプロビジョニングに必要なサーバのタイプおよび数のうちの少なくとも１つの指定を含む、請求項１〜１０のいずれか一項に記載の方法。
13. 前記指定が、サーバの選択を狭めるフィルタをさらに備えている、請求項１２に記載の方法。
14. データ処理システムにおけるコンポーネントのプロビジョニングを管理するプロビジョニング・システムを介して、前記データ処理システム内の１つまたは複数の新しいコンポーネントを動的にプロビジョニングするためのコンピュータ・プログラムであって、前記プロビジョニング・システムに、請求項１〜１３のいずれか一項に記載の方法の各ステップを実行させる、前記コンピュータ・プログラム。
15. データ処理システムにおけるコンポーネントのプロビジョニングを管理するプロビジョニング・システムにおいて、前記データ処理システム内で１つまたは複数の新しいコンポーネントを動的にプロビジョニングするための装置であって、
    メモリと、
    前記メモリに動作可能に結合されたプロセッサと
    を備えており、
    前記プロセッサが、
    前記データ処理システムのランタイム期間中に、前記データ処理システムに追加されうる新しいコンポーネントの登録を受け入れるステップであって、前記新しいコンポーネントは、前記ランタイム期間以前には前記データ処理システムに登録されていないソフトウェア・コンポーネントであり、及び、前記新しいコンポーネントの前記登録は、前記新しいコンポーネントの１つまたは複数の必須条件のうちの少なくとも１つと前記新しいコンポーネントに関連付けられた構成とに関する情報を取得することを含む、前記受け入れることと、
    プロビジョニング要求に応答して、前記登録済みの新しいコンポーネントの選択を許可することと、
    前記データ処理システムにおいて前記登録済みの新しいコンポーネントの使用を可能にすることによって、前記データ処理システムへの修正を生じさせることと
    を実行するように構成されている、前記装置。
16. 前記１つまたは複数の必須条件のうちの少なくとも１つと前記新しいコンポーネントに関連付けられた前記構成とに関する前記情報を、前記ユーザ・インターフェースを介して前記プロビジョニング・システムにユーザが入力するように、前記新しいコンポーネントの前記登録が、前記プロビジョニング・システムに関連付けられたユーザ・インターフェースを介して、ユーザが前記新しいコンポーネントを登録することを可能にすることをさらに含む、請求項１５に記載の装置。
17. 前記新しいコンポーネントの前記登録が、
    配置記述子の入力を介して、ユーザが前記新しいコンポーネントを登録することを可能にすること
    をさらに含む、請求項１５に記載の装置。
18. 前記コンポーネント登録管理モジュールが、
    前記新しいコンポーネントに適用可能な少なくとも１つのポリシーを決定する、
    請求項１５〜１７のいずれか一項に記載の装置。
19. 前記適用可能なポリシーが、前記新しいコンポーネントをどのように前記データ処理システム内で共有するかを示す１つまたは複数のポリシーをさらに含む、請求項１８に記載の装置。
20. 前記許可することが、
    前記プロビジョニング・システムに関連付けられたユーザ・インターフェースを介して、ユーザが前記登録済みの新しいコンポーネントを選択することを可能にすること
    さらに含む、請求項１５〜１９のいずれか一項に記載の装置。
21. 前記選択に使用される前記ユーザ・インターフェースが、前記ユーザが選択を許可された各登録済みコンポーネントに関する別々の画面をさらに備えている、請求項２０に記載の装置。
22. 前記プロビジョニング・システムが、
    前記新しいコンポーネントを、他の新しいコンポーネントをプロビジョニングするための必須条件として使用する、
    請求項１５〜２１のいずれか一項に記載の装置。
23. 前記必須条件が、ローカル必須条件およびリモート必須条件のうちの少なくとも１つを含む、請求項１５〜２２のいずれか一項に記載の装置。
24. 前記必須条件が、前記コンポーネントのプロビジョニングに必要なサーバのタイプおよび数のうちの少なくとも１つの指定を含む、請求項１５〜２２のいずれか一項に記載の装置。
25. 前記指定が、サーバの選択を狭めるフィルタをさらに備えている、請求項２４に記載の装置。

Images