JP6329547B2 - クラウドコンピューティング環境で使用するサービス管理エンジンを提供するためのシステムおよび方法 - Google Patents

Description

著作権に関する注意
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。

発明の分野
本発明の実施の形態は、概してクラウドコンピューティングに関し、具体的にはクラウドコンピューティング環境で使用するサービス管理エンジンを提供するためのシステムおよび方法に関する。

背景
一般的に「クラウドコンピューティング」という用語を用いて説明される計算モデルは、コンピュータネットワーク、サーバ、ソフトウェアアプリケーション、およびサービス等の計算リソースの共有プールに対するオンデマンドのアクセスを可能にするとともに、管理の手間またはサービスプロバイダの対話は最小でありながらリソースを高速で提供（provisioning）し解放する。

クラウドコンピューティング環境（クラウド環境またはクラウドと呼ばれることもある）は、さまざまな要求に最適なものとなるように多種多様のやり方で実装することができる。たとえば、パブリッククラウド環境において、基礎をなす計算インフラストラクチャを所有する組織は、自身のクラウドサービスを、他の組織または公衆が利用できるようにする。一方、プライベートクラウド環境は一般的に、１つの組織によってまたは１つの組織内で使用されることだけを意図したものである。コミュニティクラウドは、１つのコミュニティ内のいくつかの組織によって共有されることを意図したものであるのに対し、ハイブリッドクラウドは、データおよびアプリケーションの移植性によって結び付けられる２種以上のクラウド（たとえばプライベート、コミュニティ、またはパブリック）を含む。

一般的に、クラウドコンピューティングモデルは、以前は組織自身の情報技術部門によって提供されていたであろう責務のうちのいくつかを、その代わりに、（クラウドのパブリック／プライベート性に応じて組織の内部または外部で）消費者が使用するクラウド環境内のサービスレイヤとして与えることができるようにする。個々の実装に応じて、各クラウドサービスレイヤによってまたは各クラウドサービスレイヤ内で提供されるコンポーネントまたは特徴の、正確な定義は異なり得るが、一般的な例には以下のものが含まれる。

サービスとしてのソフトウェア（Software as a Service）（ＳａａＳ）。消費者は、クラウドインフラストラクチャ上で実行しているソフトウェアアプリケーションを使用するのに対し、ＳａａＳプロバイダは、基礎をなすクラウドインフラストラクチャおよびアプリケーションを管理または制御する。

サービスとしてのプラットフォーム（Platform as a Service）（ＰａａＳ）。消費者は、ＰａａＳプロバイダによってサポートされるソフトウェアプログラミング言語および開発ツールを使用して、消費者自身のアプリケーションを開発、配備（deploy）、さもなければ制御できるのに対し、ＰａａＳプロバイダは、クラウド環境のその他の側面（すなわちランタイム実行環境よりも下にあるものすべて）を管理または制御する。

サービスとしてのインフラストラクチャ（Infrastructure as a Service）（ＩａａＳ）。消費者は、任意のソフトウェアアプリケーション、および／または提供処理、記憶、ネットワーク、およびその他の基本的な計算リソースを配備し実行することができるのに対し、ＩａａＳプロバイダは、基礎をなす物理的なクラウドインフラストラクチャ（すなわちオペレーティングシステムレイヤよりも下にあるものすべて）を管理または制御する。

上記例は、一般的に本発明の実施の形態を使用することができる環境の種類のうちのいくつかを説明するために設けたものである。さまざまな実施の形態に応じて、本明細書に記載のシステムおよび方法を、他の種類のクラウドまたはコンピューティング環境で使用することもできる。

概要
本明細書に記載されているのは、クラウドコンピューティング環境で使用するサービス管理エンジンを提供するためのシステムおよび方法である。ある実施の形態に従うと、企業ソフトウェアアプリケーション（たとえばFusion Middlewareアプリケーション）を、クラウドプラットフォーム内でサービスとしてインスタンス化することができ、次に、クラウドプラットフォームにおけるこのアプリケーションを他の（たとえば顧客）アプリケーションからアクセスできるようにする。ある実施の形態において、オーケストレーションエンジンと通信するサービス管理エンジン（service management engine）（ＳＭＥ）を用いて、サービス定義パッケージ（service definition package）（ＳＤＰ）に従い１つ以上の異なるサービスタイプとしてサービスを提供することができる。サービスタイプを、クラウドプラットフォーム自体の構成に従い、かつサービスタイプの発見、提供、およびサービスタイプとシステムリソースとの対応付けを含むＳＤＰの内容に従いインスタンス化することにより、さまざまな顧客要求に対応することができる。

ある実施の形態に従う、サービスレイヤを含むクラウドコンピューティング環境を示す。 ある実施の形態に従う環境をさらに示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントを含み得るクラウドコンピューティング環境を示す。 ある実施の形態に従う、アドミニストレーションサーバおよびサービスドメインを含むＰａａＳプラットフォームコンポーネントをさらに示す。 ある実施の形態に従う、アドミニストレーションサーバとともにサービス定義パッケージおよびサービス管理エンジンを使用することを含む、ＰａａＳプラットフォームコンポーネントをさらに示す。 ある実施の形態に従う、アドミニストレーションサーバと仮想化マネージャの間の対話を含む、ＰａａＳプラットフォームコンポーネントをさらに示す。 ある実施の形態に従う、マルチテナントサービスドメインを含むＰａａＳプラットフォームコンポーネントをさらに示す。 ある実施の形態に従う、クラウドアカウントマネージャを含むＰａａＳプラットフォームコンポーネントをさらに示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるサービス定義パッケージの使用を示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでサービス定義パッケージを使用するためのプロセスのフローチャートである。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるサービス管理エンジンの使用をさらに示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでサービス管理エンジンを使用するためのプロセスのフローチャートである。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるオーケストレーションエンジンの使用をさらに示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでオーケストレーションエンジンを使用するためのプロセスのフローチャートである。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるエラスティシティ（elasticity）マネージャの使用をさらに示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでエラスティシティマネージャを使用するためのプロセスのフローチャートである。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおいてサービス定義パッケージをパッチすることをさらに示す。 ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでサービス定義パッケージをパッチするためのプロセスのフローチャートである。

詳細な説明
上記のように、クラウドコンピューティング環境（クラウド環境またはクラウド）は、たとえばパブリッククラウド、プライベートクラウド、コミュニティクラウド、またはハイブリッドクラウドといったさまざまな要求に最適なものとなるように多種多様のやり方で実装することができる。クラウドコンピューティングモデルは、以前は組織自身の情報技術部門によって提供されていたであろう責務のうちのいくつかを、その代わりに、（クラウドのパブリック／プライベート性に応じて組織の内部または外部で）消費者が使用するクラウド環境内のサービスレイヤとして与えることができるようにする。

本明細書に記載されているのは、インフラストラクチャ、プラットフォーム、および／またはアプリケーションを与える際に使用されてクラウドコンピューティング環境をサポートすることができる、種々のハードウェアおよび／またはソフトウェアコンポーネントおよび特徴である。さまざまな実施の形態に応じて、このシステムはまた、Oracle Exalogicおよび／またはExadataマシン、WebLogicおよび／またはFusion Middleware、ならびにその他のハードウェアおよび／またはソフトウェアコンポーネントおよび特徴といった、ハードウェアおよびソフトウェアを利用して、クラウドコンピューティング環境を提供することができる。このクラウドコンピューティング環境は、企業グレードであり、プラットフォームを配備に適したものにしてアプリケーションを配備することができ、現代のアーキテクチャ上に構築された一組の企業アプリケーションおよびユースケースを提供し、および／またはフレキシブルな消費選択を提供する。

図１は、ある実施の形態に従う、サービスレイヤを含むクラウドコンピューティング環境を示す。図１に示されるように、ある実施の形態に従うと、クラウドコンピューティング環境（クラウド環境またはクラウド）１００は一般的に、１つ以上の、サービスとしてのインフラストラクチャ（ＩａａＳ）レイヤ１１０、サービスとしてのプラットフォーム（ＰａａＳ）レイヤ１６０、および／またはサービスとしてのソフトウェア（ＳａａＳ）レイヤ１７０を組合わせたものを含み得る。これらレイヤは、各々クラウド環境内のサービスレイヤとして与えられ、用いられる個々のクラウド計算モデルに応じて組織の内部または外部で消費者によって使用されることができる。

ある実施の形態に従うと、クラウドコンピューティング環境は、１つ以上の従来の汎用もしくは専用デジタルコンピュータ、コンピューティングデバイス、マシン、マイクロプロセッサ、メモリおよび／またはコンピュータ読取可能な記録媒体、たとえば、コンピュータハードウェア、ソフトウェア、およびOracle Exalogic、Exadata、または同様のマシンによって提供されるリソースを含むシステムとして、実装することができる。

図１にさらに示されるように、ある実施の形態に従うと、クラウドコンピューティング環境は、以下でより詳細に説明される、共有イネーブルメントおよび管理インフラストラクチャ１２０を含み得る。このインフラストラクチャは、さまざまなサービスレイヤをサポートするために使用できるイネーブルメントおよび管理ツールを提供する。

図１に示される例は、一般的に本発明の実施の形態を使用することができる一種のクラウドコンピューティング環境を説明するものとして設けたものである。さまざまな実施の形態に応じて、本明細書に記載のシステムおよび方法を、異なるおよび／または他の種類のクラウドまたはコンピューティング環境で使用することもできる。

図２は、ある実施の形態に従う環境をさらに示す。図２に示されるように、ある実施の形態に従うと、ＩａａＳ、ＰａａＳ、および／またはＳａａＳレイヤは各々、一般的に種々のコンポーネントを含み得る。たとえば、ある実施の形態に従うと、ＩａａＳレイヤは、共有データベースハードウェア（たとえばExadataマシン）１１２、および／または共有アプリケーションサーバハードウェア（たとえばExalogicマシン）を含み得る。ＰａａＳレイヤは、データベースサービス１６２、アプリケーションサーバサービス１６４、および／またはWebCenterサービス１６６等の、１つ以上のＰａａＳサービスを含み得る。ＳａａＳレイヤは、企業アプリケーション（たとえばOracle Fusion SaaS）１７２、および／またはＩＳＶまたはカスタムアプリケーション１７６等のさまざまなＳａａＳサービスを含み得る。

上記のように、ある実施の形態に従うと、クラウドコンピューティング環境は、共有イネーブルメントおよび管理インフラストラクチャも含み得る。たとえば、図２に示されるように、共有イネーブルメントおよび管理インフラストラクチャは、１つ以上の、アイデンティティ管理１２２、データインテグレーション１２４、複製（たとえばOracle GoldenGate）１２６、仮想アセンブリビルダ（builder）１２８、システム提供１３０、テナント管理１３２、および／または企業マネージャコンポーネント１３４を含み得る。

図２にさらに示されるように、ある実施の形態に従うと、共有イネーブルメントおよび管理インフラストラクチャはまた、ウイルススキャン１４２、セキュアファイル転送１４４、ＨＴＴＰルーティング１４６、ホワイトリスト１４８、通知１５０、セキュアバックアップ１５２、インテグレーションゲートウェイ１５４、および／または使用＆課金１５６コンポーネント等の、その他のコンポーネントを含み得る。

図２に示される例は、クラウドコンピューティング環境に、または共有イネーブルメントおよび管理インフラストラクチャ内に含めることができる種類のコンポーネントのうちのいくつか説明するものとして設けたものである。他の実施の形態に従って、異なるおよび／またはその他の種類または配置のコンポーネントを含めてもよい。

ＰａａＳプラットフォームコンポーネント
ある実施の形態に従うと、クラウドコンピューティング環境は、クラウド環境内で企業ソフトウェアアプリケーションを提供できるようにするＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム）を含み得る。

図３は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントを含み得るクラウドコンピューティング環境を示す。図３に示されるように、ある実施の形態に従うと、ＰａａＳプラットフォーム５００は、Fusion Middlewareまたはその他の企業アプリケーション等の企業アプリケーションに関するセルフサービス提供体験を提供する、インストール可能なソフトウェアスイートとして提供することができる。

一般的に、組織のオンプレミスまたはプライベートクラウド環境用に企業アプリケーションをインストールし構成する場合には、相当な量の管理作業を伴なうことがある。これには、増大する作業負荷需要に見合うように環境を水平方向にスケーリングしようとしたときに管理者が直面する課題が含まれる。ある実施の形態に従うと、ＰａａＳプラットフォームコンポーネントを拡張して、必要に応じて新たな企業アプリケーションスイートをホストし、その後負荷の増大に応じインスタンス化されたランタイムの量をスケーリングすることができるようにするのは、簡単である。

図３に示されるように、ある実施の形態に従うと、ＰａａＳプラットフォームは、１つ以上の、サービス定義パッケージ（ＳＤＰ）５０２、サービス管理エンジン（ＳＭＥ）５０４、仮想アセンブリ（virtual assembly）（ＶＡ）５０６、ＰａａＳアドミニストレーションサーバ５０８、サービスドメイン５１０（１つ以上のクラウドアカウントまたはテナント５１３が使用する１つ以上のサービスアプリ５１２を含む）、および／またはクラウドエラスティシティマネージャ５１４コンポーネントを含み得る。これらコンポーネント各々は、他のコンポーネントおよび特徴とともに以下でより詳細に説明される。

用語解説
ある実施の形態に従い、本明細書では以下の用語が使用される。他の実施の形態に従い、異なるおよび／またはその他の用語が使用される場合もある。

ＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム、プラットフォーム）：ある実施の形態に従うと、ＰａａＳプラットフォームコンポーネント（ＰａａＳ、プラットフォーム）は、Fusion Middlewareまたはその他の企業アプリケーション等の企業アプリケーションに関するセルフサービス提供体験を提供する、インストール可能なソフトウェアスイートである。

クラウドアカウント（テナント）：ある実施の形態に従うと、クラウドアカウント（テナント）は、ＰａａＳプラットフォームをサービスとして消費するユーザ／消費者と対応付けられたエンティティである。クラウドアカウントは管理範囲を定め、これをアカウントアドミニストレータが用いてＰａａＳサービスにアクセスすることができる。たとえば、クラウドアカウントを、パブリックＰａａＳプロバイダからＰａａＳサービスを購入している組織または会社に対して作成することができる。別の例として、クラウドアカウントを、プライベートＰａａＳプロバイダとして機能する内部の情報技術部門からのＰａａＳサービスを消費している部門またはグループに対して作成することができる。ある実施の形態に従うと、以下で説明されるクラウドアカウントアドミニストレータロール等の異なるＰａａＳユーザロールをクラウドアカウントと対応付けてもよい。ある実施の形態に従うと、ＰａａＳプラットフォーム内において、消費されるリソース、たとえばサービスとその仮想マシン、データベース、ＤＮＳエントリ、ロードバランサ、およびその他の構成を、クラウドアカウントと対応付けてもよい。同様に、１人以上のユーザおよびゼロ以上のサービスをクラウドアカウントと対応付けてもよい。１つのＰａａＳプラットフォームドメインを、１つまたは複数のクラウドアカウント（テナント）と対応付けてもよい。

サービス定義パッケージ：ある実施の形態に従うと、サービス定義パッケージ（ＳＤＰ）は、ＰａａＳプラットフォームが特定の種類のサービスを提供するのに必要なすべての情報を含むパッケージである。たとえば、Fusion Middlewareとともに使用される場合、各々の種類のFusion Middlewareサービスは、自身のＳＤＰを提供することができる。ある実施の形態に従うと、ＳＤＰは、一組の仮想マシン（virtual machine）（ＶＭ）上に配備されるとサービスの実行インスタンスを含むことになる一組の仮想アプライアンスのトポロジおよび構成を含む仮想アセンブリ（たとえばＯＶＡＢアセンブリ）を含み、それとともに、プラットフォームにインストールされたカスタムコードを含む。たとえば、Fusion MiddlewareアプリケーションのＳＤＰは、Fusion Middlewareアプリケーションの実行インスタンスをサービスとして配備するのに必要なトポロジおよび構成を含むFusion Middleware ＯＶＡＢアセンブリとともに、カスタムコードを含み得る。

サービスタイプ：ある実施の形態に従うと、サービスタイプは、クラウドアカウントに対しＰａａＳプラットフォーム内でインスタンス化できるソフトウェア機能を表わしたものである。ある実施の形態に従うと、サービスタイプは、ＳＤＰに基づき、システムアドミニストレータから供給される追加の構成情報を用いて作成することができる。この構成情報の一部が、プラットフォームプロダクトのインストールまたはそれが実行されている企業に特有の値を供給してもよく、その他の構成情報が、ＳＤＰによってサポートされるオプションの、システムアドミニストレータによる選択を反映してもよい。ある実施の形態に従うと、異なる構成選択を行なうことによって１つのＳＤＰから複数の（異なる）サービスタイプを作成することができる。

サービス：ある実施の形態に従うと、サービスは、サービスタイプをインスタンス化したものである。１つのクラウドアカウントを複数のサービスと対応付けることができる。１つのクラウドアカウント内に、１つのサービスタイプについての複数のサービスがあってもよい。ある実施の形態に従うと、サービスは、サービスアドミニストレーションインターフェイスおよびエンドユーザインターフェイス双方を提供する。サービスは、アイデンティティ、データベース、またはこのサービスが必要とする他のサービス特徴と対応付けることができる。サービスは、１つ以上のＶＭ上で実行するサービスランタイムと対応付けられる。

プロバイダタイプ：ある実施の形態に従うと、プロバイダタイプは、サービスではなくプロバイダをサポートする特殊なサービスタイプである。プロバイダタイプは、システムアドミニストレータによって、サービスタイプと同じやり方で作成される。上記サービスタイプと同様、プロバイダタイプは、ＳＤＰに基づき、システムアドミニストレータから供給される追加の構成情報を用いて作成することができる。同様に、この構成情報の一部が、プラットフォームプロダクトのインストールまたはそれが実行されている企業に特有の値を供給してもよく、その他の構成情報が、ＳＤＰによってサポートされるオプションの、システムアドミニストレータによる選択を反映してもよい。ある実施の形態に従うと、異なる構成選択を行なうことによって１つのＳＤＰから複数の（異なる）プロバイダタイプを作成することができる。

プロバイダ：ある実施の形態に従うと、プロバイダは、サービスを特殊化したものである。サービスは一般的にクラウドアカウントアドミニストレータの明示的動作によって作成されるものであるが、プロバイダは、サービスとは異なり、オンデマンドで作成されてサービスの依存性を満たすことができる。ある実施の形態に従うと、プロバイダは、プロバイダタイプをインスタンス化したものであり、サービスタイプの特定のインスタンスによる、プロバイダタイプによって管理されるリソースの使用を表わす。サービスは複数のプロバイダと対応付けることができる。ある実施の形態に従うと、サービスを作成するとき、オーケストレーションエンジンが、所望のサービスタイプの要求を、構成されたプロバイダタイプの能力と突合せる。次に、オーケストレーションエンジンは、サービスタイプに対し、サービスのインスタンスの作成を要求し、プロバイダタイプに対し、このサービスのインスタンスが使用するプロバイダのインスタンスの作成を要求し、このサービスをプロバイダと関連付ける。

対応付けリソース：ある実施の形態に従うと、対応付けリソース（プロバイダリソース）は、サービスが、特定の対応付けに関する構成情報を追跡できるようにする。たとえば、Ｊａｖａ（登録商標）サービスが２つの異なるデータベースプロバイダと対応付けられている場合、各データベースに対して接続プールを作成する必要がある場合がある。対応付けリソースは、どの接続プールがどのデータベースと対応付けられているかをＪａｖａサービスが追跡することによって、その後オーケストレーションエンジンが対応付けのうちの１つを変更することが必要になった場合に、Ｊａｖａサービスはどの接続プールを変更すればよいかわかっていることになる。

ランタイム：ある実施の形態に従うと、ランタイムは、サービスまたはプロバイダの機能を提供するインストールされた運用ソフトウェアアプリケーションを表わしたものである。ある実施の形態に従うと、ランタイムは、場合によっては仮想化および提供サポート等のＰａａＳプラットフォームによって提供されるファシリティを用いて、ＳＤＰに含まれるカスタムコードによって管理される。

環境：ある実施の形態に従うと、環境は、まとめてグループとして管理できるサービスおよびこれらサービスに対応付けられたプロバイダの集合体である。環境は、アプリケーションの実行のためまたはより高いレベルのサービスの提供のために作成することができる。環境は、開始、停止、バックアップ、または破壊等の動作を含めて、サービス全体の集合体に対して動作する能力を提供する。ある実施の形態に従うと、環境は、「対応付けグループ」および「管理グループ」の機能を提供することができる。

システムアドミニストレータ（ロール）：ある実施の形態に従うと、システムアドミニストレータは、環境内で実行しているアプリケーションによって利用できるようにされたリソースを含む、クラウド環境および／またはＰａａＳプラットフォームインフラストラクチャおよび環境の、インストール、構成、管理、および維持という役割を担う。たとえば、ある実施の形態に従うと、システムアドミニストレータは、ＳＤＰをダウンロードおよびインストールして新規／追加のサービスタイプをサポートし、使用するＰａａＳプラットフォームに対して仮想化技術をセットアップまたは構成し、プロバイダをインストールして構成するという役割を担う。

クラウドアカウントアドミニストレータ（ロール）：ある実施の形態に従うと、クラウドアカウントアドミニストレータは、新規サービスの提供、包括的なサービスプロパティ（これらのサービス品質（Quality of Service）／ＱｏＳ設定等）の管理とそれらの対応付け、およびサービスのロックと終了という役割を担う。ある実施の形態に従うと、クラウドアカウントアドミニストレータは、各サービスにサービスアドミニストレータを割当てることができる。

サービスアドミニストレータ（ロール）：ある実施の形態に従うと、サービスアドミニストレータは、提供後の特定のサービスの管理運営という役割を担う。サービスアドミニストレータは、サービスのアドミニストレーションインターフェイスと対話して管理運営動作を実行することができる。

アプリケーションデプロイヤ（ロール）：ある実施の形態に従うと、アプリケーションデプロイヤは、提供されたサービスに対してアプリケーションを配備し、このアプリケーションのインストール、構成、および実行という役割を担う。アプリケーションを実行するとこのアプリケーションをエンドユーザが利用できるようにしてもよい。

エンドユーザ（ロール）：ある実施の形態に従うと、エンドユーザは、アプリケーションデプロイヤがサービスに対して配備したアプリケーションのユーザである。エンドユーザは、サービスに対して配備されたアプリケーションによって提供されるユーザインターフェイスと対話することができる。サービスが公開する機能をユーザが消費するためのインターフェイスをサービスが提供するのであれば、アプリケーションデプロイヤがアプリケーションを配備しなくても、エンドユーザは、サービスが提供するこのインターフェイスを使用することができる。

図４は、ある実施の形態に従う、アドミニストレーションサーバおよびサービスドメインを含むＰａａＳプラットフォームコンポーネントをさらに示す。図４に示されるように、ある実施の形態に従うと、インストールされたＰａａＳプラットフォーム（プラットフォーム）は、アドミニストレーションコンソール５２０、クラウドプラットフォーム提供／管理ロジック５２１、および仮想アセンブリビルダ（virtual assembly builder）（ＶＡＢ）デプロイヤ５２２を、アセンブリまたはＶＡＢリポジトリとともにサポートする、ＰａａＳアドミニストレーションサーバ５０８を含む。

ある実施の形態に従うと、ＶＡＢデプロイヤは、機能、コンポーネント、またはOracle Virtual Assembly Builder（ＯＶＡＢ）等のプロダクトによって提供することができる。このＶＡＢデプロイヤ（たとえばＯＶＡＢデプロイヤ）を、ＰａａＳプラットフォームが使用して、サービスしているアプリケーションをホストするＶＭを管理することができる。他の実施の形態に従い、アセンブリビルダの機能またはコンポーネントを提供する他の手段を用いてもよい。

ある実施の形態に従うと、ＰａａＳアドミニストレーションサーバは、WebLogic（ＷＬＳ）サーバアプリケーションとして、たとえばそこに埋込まれてクラウドプラットフォーム機能を提供するGlassfishモジュールとともに、実装することができる。サービスアプリおよびサービスコンソール５３２を含むサービスドメイン５１０は、最終的にユーザリクエストをサービスする、Fusion Middlewareアプリケーション等の企業アプリケーションを収容するために設けることができる。ある実施の形態に従うと、サービスドメインコンポーネントを、提供リクエストの一部として複数回インスタンス化してもよい。

ある実施の形態に従うと、ＰａａＳアドミニストレーションサーバおよびサービスドメインによって使用されることになるプロバイダサーバタイプ（その例はＬＤＡＰ５２６、データベース５２７、およびロードバランサ５２８プロバイダを含み得る）を、アドミニストレーションサーバによって提供されていないプールに提供することができる。なぜなら、これらはクラウド環境に登録された外部サービスであるからである。ある実施の形態に従うと、ＰａａＳプラットフォームは、１つのロードバランサプロバイダを利用して、入来するすべての、たとえばサービスに向けられたウェブリクエストを、転送することができる。たとえば、各サービスを、サービス提供中にロードバランサプロバイダに登録される仮想ホストネームと対応付けることができ、ＰａａＳプラットフォームは、これらサービスが利用できるデータベースプロバイダのプールを含み得る。その後サービスが提供されるときに、データベースサービスに対するすべての外部参照を解決することによって、データベースプロバイダプール内の１つ以上のインスタンスを指示する。

図５は、ある実施の形態に従う、アドミニストレーションサーバとともにサービス定義パッケージおよびサービス管理エンジンを使用することを含む、ＰａａＳプラットフォームコンポーネントをさらに示す。図５に示されるように、ある実施の形態に従うと、ＰａａＳプラットフォーム内での使用に利用できるようにすることをアドミニストレータが希望する新規企業アプリケーションサービスタイプ（たとえば新規Fusion Middlewareサービスタイプ）を、ＳＤＰからインストールすることができる。

ある実施の形態に従うと、ＳＤＰは、インターネットを通してダウンロードされてもよく、またはその他の手段によって提供されてもよい。各ＳＤＰは、一組の仮想アプライアンスのトポロジおよび構成を含むアセンブリ（たとえばＯＶＡＢアセンブリ）を含み、これは、アセンブリが一組のＶＭ上に配備されると企業アプリケーションサービスの実行インスタンスを含むことになる。各ＳＤＰはこのアセンブリを含むとともに、たとえばエラスティシティおよび提供をサポートする際に使用するためにＰａａＳプラットフォームに注入することができるカスタムコードを含む。ＰａａＳアドミニストレータが対話するサービスタイプ／プロバイダ各々をこのようにしてシステムに登録できる。外部サービス等のその他のプロバイダサービスタイプは、一般的に予めインストールしておくことができる。

図６は、ある実施の形態に従う、アドミニストレーションサーバと仮想化マネージャの間の対話を含む、ＰａａＳプラットフォームコンポーネントをさらに示す。図６に示されるように、ある実施の形態に従うと、ＶＭマネージャコンポーネント５４１（たとえばＯＶＭマネージャ）は、ＰａａＳプラットフォームによって使用されて、次にサービスアセンブリのインスタンス化に使用されるＶＭ５４２、５４３、５４４のプール５４０を管理することができる。

ＰａａＳプラットフォームモジュールから、アセンブリ（または、スケールアップリクエストの場合は１つのアプライアンス）のインスタンス化のリクエストがなされると、ＶＡＢデプロイヤアプリケーション（たとえばＯＶＡＢデプロイヤ）は、ＶＭマネージャ（たとえばＯＶＭマネージャ）と対話することによって、リクエストに応えることができる。インフラストラクチャ／仮想化の責務をこのようにしてＶＭマネージャおよびＶＡＢデプロイヤに委任することによって、ＰａａＳプラットフォームを、ターゲットデプロイメントプラットフォームから取出すことができる。

図７は、ある実施の形態に従う、マルチテナントサービスドメインを含むＰａａＳプラットフォームコンポーネントをさらに示す。

図７に示されるように、サービスドメインは、サービスコンソールを用いて構成可能な複数のテナント５５０、５５１、５５２を含み得る。マルチテナント形態は、仮想化と同様に、より少ないリソースを用いてより多くのクライアントをサポートできるようにする、密度の最適化であり、仮想化と同様に、アプリケーションそのものに対して透明でなければならない。マルチテナント形態には共有リソースの使用が必要であるが、この共有がアプリケーションの論理モデルの一部である必要はない。これらモデルのことを、「マルチテナント」および「専用」リソースを使用するものであると言う。

それとは別に、ある意味アプリケーションの論理モデルの一部であるリソースをアプリケーションが共有してもよい。たとえば、２つのアプリケーションが、同一データ上で動作しようとしていることを理由に、意図的に共有データベースにアクセスしてもよい。これらモデルのことを、「共有」および「非共有」リソースを使用するものであると言う。

ある実施の形態に従うと、いくつかのサービスタイプは、その特定の構成に基づいて、専用用途およびマルチテナント用途双方をサポートしてもよい。それ以外のサービスタイプは、専用用途のみまたはマルチテナント用途のみをサポートしてもよい。同一のランタイム上の複数のテナントをサポートすることができるサービスタイプは、サービスタイプの構成に基づいて、インスタンス化プロセスの間に、そのランタイムをマルチテナント式で提供することができる。マルチテナント対応であるものとして既にマーキングされている、インスタンス化された１つのサービスランタイムを、サービスタイプによって決まりその構成に基づく有限数の追加のサービス提供リクエストに対して再使用する。一般的に、このテナント形態モードのサポートはサービスアプリケーションに委ねられ、マルチテナントでないサービスアプリケーションは、各サービスインスタンスに対して１つのアカウントしかサポートすることができない。

サービスが、そのＶＭアセンブリから一旦インスタンス化されると、エンドユーザ５４６は、このサービスのオンプレミスバージョンと対話するのと同じやり方で、システムおよびインスタンス化されたサービスと対話することができる。

図８は、ある実施の形態に従う、クラウドアカウントマネージャを含むＰａａＳプラットフォームコンポーネントをさらに示す。図８に示されるように、ある実施の形態に従うと、ＰａａＳプラットフォームは、クラウドアカウントマネージャ５７０とともに、クラウドプラットフォームアドミニストレーションサービス（cloud platform administration service）（ＣＰＡＳ）５６０を含み得る。クラウドアカウントマネージャは、アカウント管理等の機能をサポートする役割を担うとともに、特定アカウント用データにアクセスするまたはこれを持続するためにＰａａＳプラットフォームのその他モジュール（たとえばオーケストレーションエンジン／ＳＭＥ５６２、ＣＥＭ５６４、またはアイデンティティ管理サービス５６６）が使用できるフレームワークを提供する役割を担う。

ある実施の形態に従うと、構成管理コンポーネント５７３は、構成レイヤ５８０を用いることによって、アカウント記憶装置５８２に特定アカウント用構成５８３を持続し、その他のファイル５８４を持続することができる。これにより、ＣＰＡＳのさまざまなサービスおよびその他のコンポーネントが、特定アカウント用データにアクセスしこれを操作することができる。

ある実施の形態に従うと、アカウント管理モジュール５７４はまた、ＣＰＡＳドメインに対するアカウントを管理する機能を提供する。これは、コマンドライン、ＲＥＳＴ、またはその他のアイデンティティ管理アプリケーションプログラムインターフェイス（application program interface）（ＡＰＩ）５８１の使用を通して公開することができる。各アカウントは複数のユーザを有し得る。ある実施の形態に従うと、ユーザは、ＰａａＳプラットフォームによって管理されるアイデンティティ記憶装置５８６において管理されてもよく、これに代えて、外部（たとえば企業）ＬＤＡＰからまたはユーザＩＤの別の手段から提供されてもよい。

ある実施の形態に従うと、ユーザは、アドミニストレーションインターフェイス５７２を通してクラウドアカウントマネージャにアクセスできる。アカウントおよび構成データを、ＣＰＡＳクラスタのすべてのノードからアクセス可能なファイルシステムまたはその他の記憶手段に格納することもできる。

サービス定義パッケージ（ＳＤＰ）
図９は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるサービス定義パッケージの使用を示す。ある実施の形態に従うと、サービス定義パッケージ（ＳＤＰ）は、特定の企業アプリケーションコンポーネント（たとえばFusion Middlewareコンポーネント）をサービスタイプとしてＰａａＳプラットフォームに与えるために用いる手段である。

ある実施の形態に従うと、ＳＤＰは一般的に以下の特性を有する。すなわち、ＳＤＰは、特定の企業アプリケーションコンポーネントに対して容易に作成することができ、さまざまな仮想化技術（たとえばＯＶＭ、Amazon、ＫＶＭ、またはVirtualBox）に対して配備することができ、非仮想化環境（たとえばラップトップモード）に対して配備することができ、予め提供されたサービスタイプまたはプロバイダに対するサポートを含む。

図９に示されるように、ある実施の形態に従うと、各ＳＤＰ５９２、５９６は、バイナリ５９３、５９７と、メタデータ５９４、５９８（たとえばＳＤＡの名称、サービスタイプ、バージョン、ベンダ、または、ＳＤＰがＯＶＡＢ、ＥＣ２もしくはNativeをサポートするか否かの表示等の仮想化サポートメタデータ）と、ＰａａＳプラットフォームまたはクラウド環境内でＳＤＰを使用できるようにする１つ以上のプラグイン５９５、５９６とを含み得る。ある代表的な実施の形態に従うと、各ＳＤＰは以下のものも含み得る。

特定の仮想化プロバイダ（たとえばＯＶＡＢ）上にサービスをインストールするために使用できる、アセンブリ、リファレンス、パッケージ、アーカイブまたはテンプレート、ＳＤＰ内でバンドルされたアセンブリ、または、アセンブリに対するリファレンス（たとえばＥＣ２固有のリファレンス）。

エラスティシティメトリック収集部またはアラート等のＰａａＳプラットフォーム機能をサービスとともに使用できるようにする、サービスタイプに対するサービス管理プラグインまたはＳＭＥプラグイン。

そのアセンブリおよびリハイドレーション（rehydration）プロセス中にＶＡＢデプロイヤ（たとえばＯＶＡＢデプロイヤ）とともに使用するプラグイン。

対応付けルールまたは対応付けに関する他のアーティファクト（artifact）等の、サービスプロバイダに関する依存性情報、たとえば、データベースプロバイダとの対応付けにはデータベーススキーマまたは適切なテーブル等の情報が必要な場合がある。

場合によってはさらにサービス構成およびサービスランタイム構成メタデータに細分され得る構成メタデータ。

サービスアドミニストレータ（たとえばＷＬＳアドミニストレーションサーバＵＲＬ）によって使用されるサービスアドミニストレーションインターフェイスまたはＵＲＬパターン等のアクセスインターフェイス。

サービスおよびそのランタイムとともに使用するサービスメタデータの品質。
異なるコンポーネントに対するスケーラビリティ限度等のスケーラビリティメタデータ、たとえば、アセンブリ内の異なるアプライアンスに対するスケーラビリティ限度を定めることができ、これらスケーラビリティ限度は、適切なスケーリングおよびハンドリングのために、システムアドミニストレータまたはクラウドアカウントアドミニストレータおよびエラスティシティマネージャに公開される。

サービスがマルチテナントサービスなのか専用サービスなのか等の、サポートされるテナント形態モデルの表示。

サービスとともに使用するセキュリティテンプレート／証明。
ＳＤＰの内容の代表的な実施の形態の上記説明は、ＳＤＰの中に含めることができる種類の情報のうちのいくつかを説明するものとして設けている。他の実施の形態に従い、異なるおよび／またはその他の種類の情報をＳＤＰに含めてもよい。

ある実施の形態に従うと、ＰａａＳシステムアドミニストレータがサービスタイプとしての特定の企業アプリケーションまたはその他のソフトウェアコンポーネントに対するサポートを提供するために、このシステムアドミニストレータは、特定のサービスタイプに対するＳＤＰをダウンロードしてこのＳＤＰをＰａａＳプラットフォームにインストールすることができる。

ある実施の形態に従うと、ＳＤＰをインストールすると、たとえばＯＶＡＢアセンブリをＯＶＡＢリポジトリにインストールすることになり、適切なＳＭＥプラグインがクラウドプラットフォームに登録され、メトリック収集部、アラート、および動作がＰａａＳプラットフォームにインストールされる。システムアドミニストレータがＳＤＰをインストールすると、その後、クラウドアカウントアドミニストレータが、クラウドアカウントアドミニストレーションインターフェイスを用いてそのタイプのサービスをリクエストすることができる。サービスとは特定のサービスタイプを実現したものである。

たとえば、Fusion Middlewareコンポーネントの場合、Fusion Middlewareコンポーネントの各バージョンは、別々のＳＤＰを有し得る。クラウドアカウントアドミニストレータ／サービスアドミニストレータが、Fusion Middlewareコンポーネントの新バージョンにアップグレードしようとする場合、ＳＤＰの新バージョンを選択すればよい。たとえば、ＳＯＡスイート１１ｇ、およびＳＯＡスイート１２．１．３をサポートできるようにするには、ＳＯＡスイートプロダクトのこれら２つのバージョンに対して別々のＳＤＰがあればよい。

ある実施の形態に従うと、たとえば以下のようにしてＳＤＰをｚｉｐまたはｊａｒファイルとしてパッケージングすることができる。

個々の実装に応じて、ＳＤＰを他のファイルフォーマットとしてパッケージングすることもできる。図９に示されるように、ある実施の形態に従うと、ＳＤＰがＰａａＳプラットフォームドメインにインストールされると、これはその後ＳＤＰマネージャ５９０によって消費される。ＳＤＰマネージャは、ローカルシステムへのインストールに利用できるＳＤＰのリストを取得し、必要であればＳＤＰをダウンロードしてこのＳＤＰのパーツを正しい場所にインストールし、インストール済のＳＤＰのリストを維持し、必要であればインストールされている／前にインストールされていた場所からＳＤＰのパーツすべてをアンインストールすることによってＳＤＰをアンインストールする、という役割を担う。

ある実施の形態に従うと、ＳＤＰマネージャは、既存バージョンのＳＤＰをパッチすることに加えて、複数バージョンの所与のＳＤＰ（たとえばＳＯＡ１１およびＳＯＡ１２）をサポートする。一般的に、（以下でさらに詳細に説明されるように）ＳＤＰがパッチされると、これは、ＰａａＳインフラストラクチャ内のＳＤＰに関連するインストール済のコンポーネントにしか影響せず、そのサービスタイプのサービスには影響しない。

ある実施の形態に従うと、ＳＤＰマネージャは、ＰａａＳシステムを、ＳＤＰファイルのフォーマットから分離する。ＰａａＳプラットフォームアーキテクチャの他のパーツが正確なＳＤＰファイルフォーマットを認識している必要はない。ＳＤＰマネージャは、ＳＭＥプラグインをＣＰＡＳにインストールすることによって、他のシステムコンポーネントとインターフェイスすることができ、そうすると、ＣＰＡＳが担い得る役割は、ＳＭＥプラグインをクラスタ内の他のＣＰＡＳインスタンスに複製し、ＶＡＢアセンブリ６０２、６０４（たとえばＯＶＡＢアセンブリ）をＶＡＢデプロイヤ（たとえばＯＶＡＢデプロイヤ）にインストールし、Enterprise Manager等の他のツールとインターフェイスして、サービスに対するカスタマイズされたコンソールインターフェイスを、サービスがそれを提供するのであれば、提供し、サービスに対する構成データをＣＰＡＳにインストールすることである。

その後、サービスの実現化６０６中に、サービス６１０を、ＳＤＰによって定義されるサービスタイプのインスタンスとして実現しアセンブリとしてＶＡＢリポジトリにインストールすることができる。

図１０は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでサービス定義パッケージを使用するためのプロセスのフローチャートである。図１０に示されるように、ステップ６１２で、クラウド環境と、そこで実行するＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム）とを含む、１つ以上のコンピュータを提供する。

ステップ６１４で、プラットフォームコンポーネントで使用する１つ以上のサービス定義パッケージを提供し、各サービス定義パッケージは、アプリケーションバイナリコンポーネントとメタデータとを含む。

ステップ６１６で、上記１つ以上のサービス定義パッケージをパースして、如何にして特定の企業アプリケーションコンポーネントをプラットフォームコンポーネント内のサービスタイプとして与えることができるかを決める、この特定の企業アプリケーションコンポーネントについてのサービス特性および要求を求める。

ステップ６１８で、クラウド環境内で使用するために、対応する企業アプリケーションコンポーネントをサービスタイプとしてプラットフォームコンポーネント内に提供する。

サービス管理エンジン（ＳＭＥ）
図１１は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるサービス管理エンジンの使用をさらに示す。

一般的に説明すると、ある実施の形態に従い、サービス管理エンジン（ＳＭＥ）は、任意のサービスタイプをシステム内にプラグする包括的な手段を提供する。たとえば、ＳＭＥは、特定サービス向けの、サービスタイプまたはプロバイダタイプに関する、提供、ライフサイクル、管理、およびモニタリングサポートすべてを処理する。オーケストレーションエンジン（orchestration engine）（ＯＥ、以下でさらに詳細に説明）は、特定のサービスにとらわれずに、完全にＳＭＥに依存してすべてのサービス関連動作を扱う。

ある実施の形態に従うと、ＰａａＳプラットフォームドメイン内に、いくつかの異なるクラスのＳＭＥが存在する場合がある。たとえば、プロバイダＳＭＥを提供して、ＰａａＳプラットフォームドメイン内でサポートされる異なるプロバイダを扱うことができる。サポートできるプロバイダのタイプの例は、Database、Web-Tire、およびIdentity-Managementプロバイダを含む。ある実施の形態に従うと、プロバイダＳＭＥは、プロバイダＳＤＰからプロバイダタイプを作成することによって、企業内の既存の外部サービスを指示するように構成される。プロバイダＳＭＥも、作成しているサービスとの対応付けおよび対応付け解除の一部として必要となり得るスキーマ管理等のすべての動作の責任を担う。プロバイダＳＭＥは、一般的にはプロバイダタイプによって指示された外部サービスの提供（provisioning）、提供解除（unprovisioning）、または管理を扱うように構成されていないが、プロバイダＳＭＥを、そのように構成することもできる。

ある実施の形態に従うと、サービスＳＭＥをＳＤＰを用いてＰａａＳプラットフォームドメインに追加することができる。たとえば、サービスＳＭＥを、適切なＳＤＰをインストールすることによって、ＰａａＳプラットフォームドメイン内に動的に取込むことができる。ある実施の形態に従うと、ＳＤＰマネージャは、ＳＤＰ内でＰａａＳプラットフォームドメインとバンドルされたサービスＳＭＥのインストール／登録を扱う。そうすると、登録された一組のサービスＳＭＥは、クラウドアカウントアドミニストレータが利用できるサービスタイプとなりサービスを作成する。

ある実施の形態に従うと、ＰａａＳプラットフォームドメイン内でサポートされる各サービスタイプは、特定のサービスＳＭＥにマップする。サービスＳＭＥは、そのサービスに関する、スパニング作成、モニタリング、管理、パッチ、アップグレード、および削除等のサービス関連アクティビティすべてを扱う。ある実施の形態に従うと、ＳＭＥによって実装される契約を、サービス管理インターフェイス（service management interface）（ＳＭＩ）と呼び、これは、サービスのモニタリング、パッチ、およびアップグレードに対するサポートを定義する。

ある実施の形態に従うと、オーケストレーションエンジンは、プロバイダおよびサービスＳＭＥと対話することによって、ＰａａＳプラットフォームドメイン内のサービスを作成する。オーケストレーションエンジンは、サービスの作成を「振り付け（choreograph）」するが、すべてのサービスレベルアクティビティはＳＭＥによって扱われる。図１１に示される例では、ＯＶＡＢを仮想化プロバイダとして用いるとき、ＯＶＡＢデプロイヤとの対話はすべて仮想化ＡＰＩ（たとえばＯＶＡＢクライアントＡＰＩ）によって扱われる。ある実施の形態に従うと、オーケストレーションプロセスはしたがって次のように進行する。

クラウドアカウントアドミニストレータが、たとえばＰａａＳプラットフォームドメイン内の利用できるＳＯＡサービス６２０、６２２を発見し、この例ではＳＯＡサービスの作成を開始する。

オーケストレーションエンジンは、システム内の利用できるサービスＳＭＥすべてについて処理を繰返し、どのサービスＳＭＥがこのサービスタイプ６２４を扱うことができるか判断する。この例において、オーケストレーションエンジンは、この例ではＳＯＡ ＳＭＥがＳＯＡサービスの作成を扱うものであることを発見する。

次に、オーケストレーションエンジンは、ＳＯＡ ＳＭＥに、ＳＭＥ６２５に関するすべてのプロバイダ依存性を取得させる。この例において、ＳＯＡ ＳＭＥは、データベースおよびロードバランサプロバイダ依存性をリターンする。

次に、オーケストレーションエンジンは、ＳＯＡ ＳＭＥについて、ゲットユーザ（get-user）または同様の構成可能なプロパティ関数をコールし、これらプロパティをユーザインターフェイスまたはＧＵＩ内で公開して、クラウドアカウントアドミニストレータが必要に応じてプロパティを編集できるようにする。

次に、ユーザ提供入力が、ＳＯＡ ＳＭＥに与えられる。この例ではＯＶＡＢが使用されているので、ユーザが提供した入力を用いてＯＶＡＢデプロイメントプランをアップデートすることができる。

オーケストレーションエンジンは、ＳＯＡ ＳＭＥと、それが依存するプロバイダＳＭＥとの間の予備提供（preprovisioning）の対応付けを実行する。たとえば、オーケストレーションエンジンは、ＳＯＡ ＳＭＥとデータベースプロバイダＳＭＥとの間の予備提供の対応付けを実行し、その結果、デプロイメントプランにデータベースプロバイダ構成が含められ、それに加えて、ＳＯＡサービスが必要とするスキーマおよびテーブルが作成される。

予備提供の対応付けが完了すると、オーケストレーションエンジンは、ＳＯＡ ＳＭＥ６２６に、ＳＯＡサービスを提供させる。この時点で、デプロイメントプランは、ネットワーク構成を除いて概ね完成している。アップデートされたデプロイメントプランは、アセンブリＩＤとともに、ＯＶＡＢ ＡＰＩに渡すことができ、これは、デプロイメントプランを、残りのネットワーク構成で埋める処理を行なう。次に、オーケストレーションエンジンは、ＯＶＡＢデプロイヤのウェブサービスＡＰＩをコールしてＯＶＡＢアセンブリを提供することができる。アセンブリが提供されると、仮想マシン情報すべてが取出されてＳＯＡ ＳＭＥに戻され、そうすると、ＳＯＡ ＳＭＥはこの情報をオーケストレーションエンジンに戻す。オーケストレーションエンジンは、後に使用するためにこの情報を持続してもよい。

次に、オーケストレーションエンジンは、ＳＯＡ ＳＭＥとこれが依存するプロバイダＳＭＥとの間の事後提供（post-provisioning）の対応付けを実行する。たとえば、ＳＯＡ ＳＭＥとロードバランサプロバイダＳＭＥとの間の事後提供の対応付けにより、仮想サーバが作成されて、このＳＯＡサービスに対するリクエストを処理しこれらを適切にルーティングする。

最後に、サービス作成のステータスがクラウドアカウントアドミニストレータにリターンされる。

ＯＶＡＢデプロイヤをデプロイアセンブリの手段として用いＳＯＡサービスおよびＳＯＡ ＳＭＥをＳＭＥの例として用いるオーケストレーションプロセス、ならびにデータベースとロードバランサプロバイダとの対応付けに関する上記説明は、代表的なオーケストレーションプロセスを説明するために設けたものである。他の実施の形態に従い、異なるおよび／または他の種類の、たとえば、ＶＡＢデプロイヤ、ＳＭＥ，およびプロバイダを使用してもよい。

図１２は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでサービス管理エンジンを使用するためのプロセスのフローチャートである。図１２に示されるように、ステップ６３０で、クラウド環境と、そこで実行するＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム）とを含む、１つ以上のコンピュータを提供する。

ステップ６３２で、オーケストレーションエンジンと通信し、１つ以上の、サービスタイプの提供、ライフサイクル管理、およびモニタリングを含む、サービスタイプとしてサービスを提供することに使用される、１つ以上のサービス管理エンジンを提供する。

ステップ６３４で、特定のサービスタイプをクラウド環境内で使用するために提供すると判断する。

ステップ６３６で、サービス管理エンジンを用いて、プラットフォームコンポーネント自体の構成および／またはサービス定義パッケージをパースし、プラットフォームコンポーネントの構成および／またはサービス定義パッケージの内容に従って、１つ以上の異なるサービスタイプとしてサービスを提供する。

ステップ６３８で、対応するサービス管理エンジンを、プラットフォームコンポーネント内で上記特定のサービスタイプをサポートするように構成する。

オーケストレーションエンジン
図１３は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるオーケストレーションエンジンの使用をさらに示す。

ある実施の形態に従うと、オーケストレーションエンジン（ＯＥ）は、サービス作成、プロバイダ依存性の解決、サービスとプロバイダの対応付け、および一般的にはＰａａＳプラットフォーム内におけるサービスの最初から最後までのライフサイクル管理を可能にする。特に、オーケストレーションエンジンは、サービスを作成または管理しながら、ＰａａＳプラットフォームドメイン内のさまざまなコンポーネントの間の対話すべてをコーディネートし、プラットフォーム内のさまざまなサービスタイプに関するＳＭＥのプラガビリティを可能にし、プラットフォーム内の利用できるものの中から適切なＳＭＥを選択することによってサービスの提供を支援する。オーケストレーションエンジンはまた、ＤＢプロバイダ、ＩＤＭプロバイダ、およびＬＢプロバイダ等のプロバイダの構成の管理を支援する。

ある実施の形態に従うと、オーケストレーションエンジンは、サービス作成の一部として、適切なプロバイダ（プロバイダＳＭＥ）を選択しプロバイダとサービスの間の対応付けをコーディネートすることによって、サービスのプロバイダ依存性等のサービスの依存性すべてが確実に満たされるようにする。対応付けという作業は、予備提供および／または事後提供フェイズ中に実行できる。ＳＭＥのインストールおよび構成と言う作業は、ＳＤＰマネージャによって、予めパッケージングされたサービスタイプまたはカスタマイズされたサービスタイプの登録の一部として実行できる。オーケストレーションエンジンは、サービスの提供作業中にコンソールを通してクラウドアカウントアドミニストレータによって構成できるデプロイメントプラン構成の公開を支援する。

ある実施の形態に従うと、オーケストレーションエンジンは、その「サービス作成」作業およびその他のライフサイクル関連活動についてのＰａａｓプラットフォームの要求に一致する一組のフェイズおよびタスクを認識する。また、オーケストレーションエンジンは、拡張可能に、かつ、オーケストレーションエンジンによって管理されるすべての動作におけるフェイズおよびタスクの構成を可能にするように、設計されている。

仮想化環境内でのサービスの提供および管理は、時間がかかる作業であることが多く、一般的には非同期方式で実行する必要がある。システムはまた、過渡的な（または再試行可能な）失敗を処理し提供活動を継続することができなければならない。ある実施の形態に従うと、アドミニストレータはオンデマンドでこのような非同期活動のいずれかをクエリまたはモニタリングすることができる。開始された作業すべての進行状態を判断、表示、および記録するために、提供、提供解除等の作業に対して一意識別子を与えてもよい。

ある実施の形態に従うと、オーケストレーションエンジンはまた、タスクのレジリエンシに基づいてタスクの再試行または作業のロールバックを助ける。このタスクまたはフェイズにマーカ（注釈）を付けてレジリエンシレベルおよび補償作業を示してもよい。

ある実施の形態に従うと、オーケストレーションエンジンは、ＰａａＳプラットフォームドメイン内の他のコンテナによってまたはアドミニストレータによって開始できるすべてのサービス管理、モニタリング、スケーリング作業に対するゲートウェイとして機能する。たとえば、エラスティシティエンジン（以下でさらに詳細に説明）は、オーケストレーションエンジンと通信して、サービスのＱｏＳ構成に基づき、サービスを管理、モニタリング、およびスケーリングする。オーケストレーションエンジンはまた、サービスのダウンタイムの回避に役立つローリング方式でアクティブシステム内で実行することができるパッチおよびアップグレード等のサービスメンテナンス作業において、役割を果たすこともできる。このような作業は、段階的に対応付けの解除または再対応付けを必要とする場合がある。

ある実施の形態に従うと、クラウドアカウントアドミニストレータによって作成されたサービスは、特定のクラウドアカウント（テナント）にとってのみ、可視でアクセス可能であり、ＰａａＳプラットフォームドメイン内の他のクラウドアカウントからは分離される。ある実施の形態に従うと、このような分離は、クラウドアカウント管理モジュールによって支援されてオーケストレーションエンジンが提供できるものである。サービス構成、ステータスおよびアクセシビリティの格納および管理は、クラウドアカウントデータ記憶装置を別々にすることによって行なうことができる。マルチテナントモデルおよび専用テナント形態モデル双方を１つのプラットフォームドメイン内でサポートすることができる。オーケストレーションエンジンは、サービスメタデータ内に与えられたプリファレンスに基づいて、必要なテナント形態レベルをサポートする適切なプロバイダタイプを選択する。同様に、マルチテナントモデルおよび専用テナント形態モデルは、サービスに関して、マルチテナントサービスランタイプに基づいて、または、サービス毎の専用サービスランタイムに基づいてサポートすることができる。

ある実施の形態に従うと、ＳＭＥをオーケストレーションエンジンに登録して、サービスの所与の「ファミリー」（たとえば「データベース」）に対する複数のＳＭＥがシステム内に存在するようにしてもよい。クラウド毎のアカウントベースで特定のサービスファミリーに対してデフォルトＳＭＥを構成することも可能である。

図１３に示されるように、ある実施の形態に従うと、ＣＰＡＳの仮想化特徴は主としてＶＡＢデプロイヤ（たとえばＯＶＡＢデプロイヤ）の周りに構築され、ＶＡＢアセンブリ（たとえばＯＶＡＢアセンブリ）は提供ユニットである。他の実施の形態に従い、ＣＰＡＳがこれに代わる仮想化ソリューションをサポートしてもよい。

ある実施の形態に従うと、オーケストレーションおよびサービス管理コンポーネントは、仮想化サービス６４０、プラグイン６４２、およびサポートされる基本的な仮想化作業を抽出する仮想化ＡＰＩ６４６を通して、仮想化レイヤとインターフェイスすることができる。ＯＶＡＢを使用するある実施の形態に従うと、このＡＰＩは、ＯＶＡＢデプロイヤがアセンブリ作成のタスクを実行できるようにするＯＶＡＢデプロイヤインターフェイスであってもよい。ＯＶＡＢ等のプロダクトは、ExaLogic等のコンピュータハードウェアマシンに加えてＯＶＭ等の仮想化プロバイダをサポートする。ＯＶＡＢデプロイヤ等のプロダクトはまた、プラグインの開発によりＥＣ２等のさらに他の仮想化技術をサポートできるようにするＳＰＩを提供する。ある実施の形態に従うと、オーケストレーションエンジン／ＳＭＥは、アセンブリのアップロードおよび配備を、そのライフサイクルの管理に加えて、ＯＶＡＢ仮想化ＡＰＩを通して行なうことができる。

ある実施の形態に従い、開発者／デモのシナリオをサポートするために、システムは、本来のＯＳプロセス（すなわち仮想化なし）上で実行できる限定されたソリューションを実現することもできる。この機能は、仮想アセンブリサービスＳＰＩの一部を実現する物理的プラグインを提供することによって実現できる。

図１４は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでオーケストレーションエンジンを使用するためのプロセスのフローチャートである。図１４に示されるように、ステップ６５０で、クラウド環境と、そこで実行するＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム）とを含む、１つ以上のコンピュータを提供する。

ステップ６５２で、プラットフォームコンポーネントで使用する、１つ以上のサービス定義パッケージを受け、各サービス定義パッケージは、特定の企業アプリケーションコンポーネントについて、如何にしてこの特定の企業アプリケーションコンポーネントをプラットフォームコンポーネント内のサービスタイプとして与えることができるかを定義する。

ステップ６５４で、プロセスは、サービス定義パッケージ内で、一組の仮想アプライアンスについてのトポロジおよび構成を定義する仮想アセンブリを決定する。

ステップ６５６で、特定のサービスタイプが、クラウド環境内で使用するために提供されるものであると判断し、対応するサービス管理エンジンを、プラットフォームコンポーネント内でこれら特定のサービスタイプをサポートするように構成する。

ステップ６５８で、プロセスは複数のサービス管理エンジンと通信して、サービス作成の流れ、プロバイダ依存性の解決、サービスとプロバイダの対応付け、およびクラウド環境内でのサービスのライフサイクル管理を制御する。

エラスティシティマネージャ
図１５は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおけるエラスティシティマネージャの使用をさらに示す。

図１５に示されるように、ある実施の形態に従うと、環境マネージャ６６２を含むクラウドエラスティシティマネージャ６６０は、メトリック収集部６６４、６６５およびアラート６７０を使用することによって、環境内で実行しているサービスの健全度を求めることができる。環境の状態が求められると、クラウドエラスティシティマネージャは適切なアクション６７２を起こすことができる。ある実施の形態に従うと、これらメトリック収集部、アラート、およびアクションを、ＨＫ２契約として提供して、これら一組のメトリック収集部、アラート、およびアクションを拡張可能にしてもよい。

ある実施の形態に従うと、メトリック収集部は、サービスに関するメトリックデータを周期的に集めて維持するオブジェクトである。たとえば、メトリック収集部は、使用メモリおよびコミットメモリ等のヒープ統計を周期的に集めるものであってもよい。別のメトリック収集部は、ＣＰＵ使用に関するメトリックを周期的に収集するものであってもよい。一般的に、メトリック収集部は、何らかのリソース使用状態に関する情報を提供する。メトリックは、外部モニタリングツールによって提供されてもよく、メトリック収集部オブジェクトでなくてもよい。ある実施の形態に従うと、クラウドエラスティシティマネージャは、任意のＪａｖａビーンコンポーネントが、アラート生成に使用するメトリックデータを提供できるようにする。

ある実施の形態に従うと、アラートオブジェクトは、ある期間にわたり１つ以上のメトリック収集部によって収集されたメトリックデータを解析することにより、環境内のサービスの健全度を周期的に検査する。たとえば、アラートは、過去１０分間のＣＰＵの使用を調べることによって環境がストレスを受けているか否か判断してもよい。アラートは、サービスまたは環境の状態を判断した後、電子メールの送信、メッセージのロギング、イベントの送信、またはサービスのスケールアップもしくはスケールダウン等の何等かのアクションを実行することができる。ある実施の形態に従うと、アラートは複数のアクションを起こすことができる。

ある実施の形態に従うと、クラウドエラスティシティマネージャは、アラートをＥＬ表現として特定できるようにする統一表現言語（Expression Language）（ＥＬ）エンジン６６８を含み得る。ＥＬ表現はまた、その表現の中でメトリック収集部およびアラートを使用することができる。ある実施の形態に従うと、クラウドエラスティシティマネージャはまた、外部ＥＬリゾルバオブジェクト６６７を登録できるようにし、これにより、MBeanまたはPOJO等の他のタイプのオブジェクトを表現内で使用できる。

メトリック収集部、アラートおよびアクションは通常、何らかの構成データを必要とする。たとえば、メトリック収集部は、メトリックデータを保持すべき期間を特定する何らかの構成データを必要とする場合がある。同様に、アラートは、しきい値を特定する何らかの構成データを必要とする場合がある。ある実施の形態に従うと、クラウドエラスティシティマネージャは、クラウドアカウントマネージャに依存してこのような構成データを持続する。ここでも、構成データは、ＨＫ２に基づくことによって容易に拡張できるようにしてもよい。

図１６は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでエラスティシティマネージャを使用するためのプロセスのフローチャートである。図１６に示されるように、ステップ６７３で、クラウド環境と、そこで実行するＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム）とを含む、１つ以上のコンピュータを提供する。

ステップ６７４で、オーケストレーションエンジンは、クラウド環境内で使用する提供すべき特定のサービスタイプを決定し、プラットフォームコンポーネント内で対応するサービス管理エンジンを構成することによって、これら特定のサービスタイプをサポートする。

ステップ６７６で、エラスティシティマネージャは、プラットフォームコンポーネント内のサービスの健全度を求め、イベントの検出、アラートの発行、および／またはオーケストレーションエンジンに対しサービスライフサイクルを管理するよう通知することを含む、適切なアクションを起こす。

ステップ６７７で、１つ以上のメトリック収集部オブジェクトは、サービスリソースの使用に関するメトリックデータを周期的に集めて維持し、一方、１つ以上のアラートオブジェクトは、ある期間にわたり１つ以上のメトリック収集部によって収集されたメトリックデータを解析することにより、環境内のサービスの健全度を周期的に検査する。

ステップ６７９で、エラスティシティマネージャは、サービスライフサイクルを管理して特定のサービスに対する増大した需要を含む要求に応えるように構成される。

ＳＤＰのアップデートおよびパッチ
図１７は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントにおいてサービス定義パッケージをパッチすることをさらに示す。ある実施の形態に従うと、サービスを周期的にメンテナンスすることによって、これらサービスが、たとえばバグの修復、セキュリティアップデートおよび構成変更に対して最新状態であることを保証することができる。均一環境の保証を支援するためには、サービスを同じ組のパッチおよび構成アップデートによって適時アップデートする必要がある。

ある実施の形態に従うと、アップデートは、システムに対して行なわねばならない変更であると定義される。アップデートの例は、セキュリティパッチの適用、コンポーネントのアップグレード、または構成値の変更を含む。アップデートの種類に応じて、ダウンタイムを必要とするアップデートと、ダウンタイムを必要としないアップデートがある場合がある。システムはこれらの状況双方を考慮すればよい。

ある実施の形態に従うと、アップデートは、ハードアップデート、すなわちサービスダウンタイムを必要とするアップデート（たとえばミドルウェアに対するパッチ、オペレーティングシステム（ＯＳ）のアップデート等）、またはサービス再起動と、ソフトアップデート、すなわちシステムダウンタイムを必要としないアップデート（たとえば何らかの構成変更）とを含み得る。

ソフトアップデートはダウンタイムを回避するが、それと引き換えにサービス安定性が犠牲になる。この点で、システムアドミニストレータがアップデートを適切にカテゴライズすることが重要である。すべてのサービスがアップデートされて環境を均一に保ち、かつ、メンテナンスウィンドウが制限されてサービスすべてが適切にアップデートされることを保証することも重要である。

ある実施の形態に従うと、メンテナンスウィンドウは、アップデートが特定のサービスに適用されるときの時間枠であると定義される。異なるサービスそれぞれに異なるメンテナンスウィンドウがあってもよい。一般的に、アップデートの種類に応じて、メンテナンスウィンドウの中で以下のアクションのうちの１つ以上が起こる、すなわち、サービスのロックアウト（通常はハードアップデートの場合のみ）、サービスのバックアップ、ＯＳアップデートのうちいずれかまたはすべての適用、システム構成変更の実行、企業アプリケーション、たとえばFusion Middlewareコンポーネントに対するパッチの適用、サービス構成変更の実行（たとえばスレッドのチューニング、ＩＯタイムアウト等）、他の非標準コンポーネントに対するアップデートの実行、サービスＶＭの再起動、健全度検査の実行、および／またはパブリックアクセスに対するサービスの開放のうちの、１つ以上が起こる。

ソフトアップデートの場合、上記ステップすべてが必要とは限らないであろう。しかしながら、ソフトアップデートは、サービスアクセスが最小のとき（たとえば夜間）に適用することがやはり好ましい。アップデートの中にはサービスランタイムの再始動または再起動を必要としないものもあるが、一般的にはサービスをホストするＶＭを再起動してクリーンな状態を提供することが推奨される。

ある実施の形態に従うと、サービスのアップグレードは、コンポーネントのうちの１つ以上に主要な変更がなされることを除いて、ハードアップグレードと同様である。この主要な変更は、異なるバージョンのソフトウェアコンポーネントのインストール、ソフトウェアコンポーネントのマイナーなバージョンアップグレード、または構成のマイグレーションのうちの１つ以上を含み得る。

ある実施の形態に従うと、アップグレードされているコンポーネントが、必要なツールを提供しマイグレーションのシナリオを自動化する機能を提供するのであれば、サービスはアップグレードされるであろう。

ある実施の形態に従うと、サービスランタイム上のローカル（またはマウントされた）ファイルシステムとしてリポジトリを利用できると想定する。リポジトリを用いて、メンテナンスウィンドウの中で必要になるコンポーネント（パッチ、構成ファイル、スクリプト等）すべてを保持することができる。たとえば、リポジトリは、例として以下に示す異なるバージョンのサービスに対するアーティファクトを保持することができる。

図１７に示されるように、ある実施の形態に従うと、メンテナンスウィンドウに先立って、リポジトリが、必要なコンポーネント６８２、たとえばパッチ、Puppetマニフェスト、またはシェルスクリプトでアップデートされる。アップデートは、Puppetまたは同様の機能を提供するツールもしくはコンポーネント等の構成ツールを用いて進めることができる。ある実施の形態に従うと、サービスがPuppetまたは適切な構成ツールをインストールさせていなければ、パッチインフラストラクチャが、構成ツールをインストールしリポジトリ内で利用できるようにされたマニフェストを適用する。

また、サービスアドミニストレータが、アップデートを扱うために異なる自動化フレームワークを選択してもよい。すべてのアップデートは、トランザクション的でなければならずかつ失敗の場合はロールバックできるものでなければならない。

ある実施の形態に従うと、システムアドミニストレータは次に、サービスアップデートロジック６８４が使用するメンテナンスウィンドウ６８５を定める。ある実施の形態に従うと、クラウドアドミニストレーションコンソールを用いてメンテナンスウィンドウを定めることができる。次に、システムアドミニストレータは、パッチするサービスについてのサービス名およびＳＤＰのバージョン、メンテナンスウィンドウがハードウィンドウなのかソフトウィンドウなのか、メンテナンスウィンドウの長さ（通常、ハードアップデートの場合６０分）、アップデートをスケジューリングするための時間枠（通常、ハードアップデートの場合一週間）、およびアップデートの適切な時間を限定するその他のパラメータ等の情報を、構成する。

ある実施の形態に従うと、次に、サービスアップデートロジックは、各サービスに対しデフォルトタイムスロットを割当てる。「ハード」アップデートの場合はサービスアドミニストレータに対してシステムダウンタイムを通知する電子メール通知を送信してもよい。ある実施の形態に従うと、サービスアドミニストレータには、そのサービスがダウンタイムおよびアップデートを招くときに３つのタイムスロットの中から選択するというオプションがある。

アップデート時、アップデートは、サービスアップデートロジックによってリクエストされ６８７、リポジトリ内の情報を用いて、サービスをその元の構成６８６から修正後の構成６８９にパッチまたはアップデートする。

図１８は、ある実施の形態に従う、ＰａａＳプラットフォームコンポーネントでサービス定義パッケージをパッチするためのプロセスのフローチャートである。図１８に示されるように、ステップ６９０で、クラウド環境と、そこで実行するＰａａＳプラットフォームコンポーネント（ＰａａＳプラットフォーム）とを含む、１つ以上のコンピュータを提供する。

ステップ６９１で、プラットフォームコンポーネントで使用する、１つ以上のサービス定義パッケージを提供する。各サービス定義パッケージは、特定の企業アプリケーションコンポーネントについて、如何にしてその特定の企業アプリケーションコンポーネントをプラットフォームコンポーネント内のサービスタイプとして与えることができるかを定義する。

ステップ６９２で、サービス定義パッケージと対応付けられた１つ以上のパッチまたはアップデートに従って、メンテナンスウィンドウの中で１つ以上のサービス定義パッケージを修正するためにサービスアップデートロジックを提供する。

ステップ６９４で、サービスランタイムにおけるローカルまたはマウントされたファイルシステムのうちの１つとしてリポジトリを提供し、これは、サービスアップデートロジックによってメンテナンスウィンドウの中で使用されてサービス定義パッケージを修正するためのパッチ、構成ファイル、スクリプト、および／またはその他のコンポーネントを含む。

ステップ６９６で、プラットフォームコンポーネント自体を再構成することにより、および／またはサービスのサービス定義パッケージに対応するディスクボリュームをマウントしてそのファイルシステムコンテンツを直接修正することによって、サービスの特性および／または要求を動的に修正またはアップデートする。

本発明は、本開示の教示に従いプログラムされた、１つ以上のプロセッサ、メモリ、および／またはコンピュータ読取可能な記録媒体を含む、従来の汎用もしくは専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを１つ以上用いて、適宜実現し得る。適切なソフトウェアコーディングは、熟練したプログラマが本開示の教示に基づいて容易に準備できるものである。これはソフトウェア技術における当業者には明らかであろう。

実施の形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された非一時的な記録媒体または（１つまたは複数の）コンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。この記録媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／またはデータを格納するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。

ある実施の形態に従い、クラウドコンピューティング環境で使用するサービス管理エンジンを提供するための装置が提供される。この装置は、クラウド環境内のインストール可能なソフトウェアスイートとして提供され企業アプリケーションに関するセルフサービス提供をサポートするプラットフォームコンポーネントと、オーケストレーションエンジンと通信し、１つ以上の、サービスタイプの提供、ライフサイクル管理、およびモニタリングを含む、サービスタイプとしてサービスを提供することに使用される、１つ以上のサービス管理エンジンとを含む。この装置は、クラウド環境内で使用する提供すべき特定のサービスタイプを決定し、プラットフォームコンポーネント内で対応するサービス管理エンジンを構成してこの特定のサービスタイプをサポートする。

別の実施の形態に従うと、上記１つ以上のサービス管理エンジン各々を用いて、サービス定義パッケージをパースし、サービス定義パッケージの内容に従って、１つ以上の異なるサービスタイプとしてサービスを提供する。

別の実施の形態に従うと、プラットフォームコンテンツは、プラットフォームコンポーネント自体の構成に従って、プロバイダサービス管理エンジンとしての１つ以上のサービス管理エンジンによって、サービスタイプをインスタンス化できるようにする。

本発明に関するこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。変更および変形は、開示されている特徴の適切な組合せを含む。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって他の当業者が本発明のさまざまな実施の形態および意図している特定の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は、以下の特許請求の範囲およびその均等物によって定められることが意図されている。

Claims (7)

1. クラウドコンピューティング環境で使用するサービス管理エンジンを提供するためのシステムであって、
   １つ以上のコンピュータを備え、前記コンピュータは前記コンピュータ上で実行するクラウド環境を含み、
   前記クラウド環境内のインストール可能なソフトウェアスイートとして提供されるプラットフォームコンポーネントを備え、
   前記プラットフォームコンポーネントは、
   オーケストレーションエンジンと、
   前記オーケストレーションエンジンと通信し、サービスタイプの提供、ライフサイクル管理、および／またはモニタリングを含む、サービスタイプとしてサービスを提供することに使用される、１つ以上のサービス管理エンジンと、
   １つ以上のサービス定義パッケージとを備え、
   各サービス定義パッケージは企業アプリケーションのバイナリコンポーネントを含み、各サービスタイプは対応するサービス定義パッケージに基づいて作成され、
   前記オーケストレーションエンジンは、前記クラウド環境内で使用する提供すべき特定のサービスタイプを決定し、前記プラットフォームコンポーネント内で対応するサービス管理エンジンを構成して前記特定のサービスタイプをサポートし、
   前記対応するサービス管理エンジンを用いて、前記特定のサービスタイプを作成する基になるサービス定義パッケージをパースし、前記パースしたサービス定義パッケージの内容に従って前記特定のサービスタイプとしてサービスを提供する、システム。
2. 前記プラットフォームコンポーネントは、前記プラットフォームコンポーネント自体の構成に従って、プロバイダサービス管理エンジンとしての前記１つ以上のサービス管理エンジンによって、サービスタイプをインスタンス化できるようにする、請求項１に記載のシステム。
3. クラウドコンピューティング環境で使用するサービス管理エンジンを提供する方法であって、
   １つ以上のコンピュータを提供することを含み、前記コンピュータは前記コンピュータ上で実行するクラウド環境を含み、
   前記方法は、さらに、前記クラウド環境内のインストール可能なソフトウェアスイートとして提供されるプラットフォームコンポーネントを提供することを含み、
   前記プラットフォームコンポーネントは、
   オーケストレーションエンジンと、
   前記オーケストレーションエンジンと通信し、サービスタイプの提供、ライフサイクル管理、および／またはモニタリングを含む、サービスタイプとしてサービスを提供することに使用される、１つ以上のサービス管理エンジンと、
   １つ以上のサービス定義パッケージとを備え、各サービス定義パッケージは企業アプリケーションのバイナリコンポーネントを含み、各サービスタイプは対応するサービス定義パッケージに基づいて作成され、
   前記方法は、さらに、
   前記オーケストレーションエンジンによって、前記クラウド環境内で使用する提供すべき特定のサービスタイプを決定し、前記プラットフォームコンポーネント内で対応するサービス管理エンジンを構成して前記特定のサービスタイプをサポートすることと、
   前記対応するサービス管理エンジンを用いて、前記特定のサービスタイプを作成する基になるサービス定義パッケージをパースし、前記パースしたサービス定義パッケージの内容に従って前記特定のサービスタイプとしてサービスを提供することとを含む、方法。
4. 前記プラットフォームコンポーネントは、前記プラットフォームコンポーネント自体の構成に従って、プロバイダサービス管理エンジンとしての前記１つ以上のサービス管理エンジンによって、サービスタイプをインスタンス化できるようにする、請求項３に記載の方法。
5. １つ以上のコンピュータシステムによって実行されると前記１つ以上のコンピュータシステムに請求項３または４に記載の方法を実行させるマシン読取可能な命令を含むコンピュータプログラム。
6. クラウドコンピューティング環境で使用するサービス管理エンジンを提供するための装置であって、
   クラウド環境内のインストール可能なソフトウェアスイートとして提供されるプラットフォームコンポーネントを備え、前記プラットフォームコンポーネントは、
   オーケストレーションエンジンと、
   前記オーケストレーションエンジンと通信し、１つ以上の、サービスタイプの提供、ライフサイクル管理、およびモニタリングを含む、サービスタイプとしてサービスを提供することに使用される、１つ以上のサービス管理エンジンと、
   １つ以上のサービス定義パッケージとを備え、
   各サービス定義パッケージは企業アプリケーションのバイナリコンポーネントを含み、各サービスタイプは対応するサービス定義パッケージに基づいて作成され、
   前記オーケストレーションエンジンは、前記クラウド環境内で使用する提供すべき特定のサービスタイプを決定し、前記プラットフォームコンポーネント内で対応するサービス管理エンジンを構成して前記特定のサービスタイプをサポートし、
   前記対応するサービス管理エンジンを用いて、前記特定のサービスタイプを作成する基になるサービス定義パッケージをパースし、前記パースしたサービス定義パッケージの内容に従って前記特定のサービスタイプとしてサービスを提供する、装置。
7. 前記プラットフォームコンポーネントは、前記プラットフォームコンポーネント自体の構成に従って、プロバイダサービス管理エンジンとしての前記１つ以上のサービス管理エンジンによって、サービスタイプをインスタンス化できるようにする、請求項６に記載の装置。

Images