(57)【特許請求の範囲】
【請求項１】
方法であって、
１つ以上の演算装置を備えるクラウドインフラストラクチャシステムが、前記クラウドインフラストラクチャシステムによって提供される一組のクラウドサービスに対応する一組のサービス宣言を格納するステップと、
前記クラウドインフラストラクチャシステムの前記１つ以上の演算装置のうちの演算装置が、顧客からサブスクリプションオーダー情報を受取るステップとを備え、前記サブスクリプションオーダー情報は、前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスから、選択されたサービスを特定し、
前記クラウドインフラストラクチャシステムが、前記一組のサービス宣言から、前記選択されたサービスのために特定のサービス宣言を決定するステップと、
前記クラウドインフラストラクチャシステムが、前記特定のサービス宣言における情報に基づいて、前記選択されたサービスをプロビジョニングするステップと、
前記クラウドインフラストラクチャシステムが、提供している前記一組のクラウドサービスにサービスを追加するためのサービス宣言テンプレートを提供するステップと、
前記クラウドインフラストラクチャシステムが、新たなサービスを前記クラウドインフラストラクチャシステムに登録するための変更されたサービス宣言を受取るステップと、
前記クラウドインフラストラクチャシステムが、提供している前記一組のクラウドサービスに前記新たなサービスを追加するステップとを備え、
前記特定のサービス宣言は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、
前記変更されたサービス宣言は、前記新たなサービスを可能化するために一組のリソースをプロビジョニングするための一組のプロシージャを示す情報を備える、方法。
【請求項２】
システムであって、
一組のクラウドサービスを提供するように構成可能な１つ以上の演算装置と、
クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに対応する一組のサービス宣言を格納するように構成可能なメモリとを備え、
前記１つ以上の演算装置は、
顧客からサブスクリプションオーダー情報を受取るように構成可能であり、前記サブスクリプションオーダー情報は、前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスから、選択されたサービスを特定し、
前記選択されたサービスのために特定のサービス宣言を決定するように構成可能であり、
前記特定のサービス宣言における情報に基づいて、前記選択されたサービスをプロビジョニングするように構成可能であり、
前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスにサービスを追加するためのサービス宣言テンプレートを提供するように構成可能であり、
新たなサービスを前記クラウドインフラストラクチャシステムに登録するための変更されたサービス宣言を受取るようにさらに構成可能であり、
前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに前記新たなサービスを追加するように構成可能であり、
前記特定のサービス宣言は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、
前記変更されたサービス宣言は、前記新たなサービスを可能化するために一組のリソースをプロビジョニングするための一組のプロシージャを示す情報を備える、システム。
【請求項３】
前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスは、サービスに特有のカスタムコードなしでプロビジョニングされる、請求項２に記載のシステム。
【請求項４】
前記サービス宣言テンプレートは、拡張マークアップ言語（ＸＭＬ）文書またはＸＭＬスキーマ定義（ＸＳＤ）文書であり、前記サービス宣言テンプレートは、クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに追加されるサービスをプロビジョニングするための特定のスキーマおよび実行フローに関する情報を提供するための部分を提供する、請求項３に記載のシステム。
【請求項５】
前記顧客から１つ以上の入力要件を受取るようにさらに構成され、前記１つ以上の入力要件は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするために、前記特定のサービス宣言によって順番に必要とされる、請求項２〜４のいずれか１項に記載のシステム。
【請求項６】
前記一組のサービス宣言は、さまざまなサービス提供、サービス関連付け、超過、使用メトリック、顧客通知テンプレート、課金情報、物理的ストレージ、物理的コンポーネント、ユニフォーム・リソース・ロケータ（ＵＲＬ）ルーティング、モニタリング構成またはネットワーク構成についての情報を含む拡張マークアップ言語（ＸＭＬ）文書である、請求項２〜５のいずれか１項に記載のシステム。
【請求項７】
前記選択されたサービスをプロビジョニングするためにビジネスプロセス実行言語（ＢＰＥＬ）ベースの要求処理エンジンが使用され、前記ＢＰＥＬベースの要求処理エンジンは、前記特定のサービス宣言に定義されたタスクを実行するように構成される、請求項２〜６のいずれか１項に記載のシステム。
【請求項８】
一組のクラウドサービスを提供するためのシステムであって、
クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに対応する一組のサービス宣言を格納するための手段と、
顧客からサブスクリプションオーダー情報を受取るための手段とを備え、前記サブスクリプションオーダー情報は、前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスから、選択されたサービスを特定し、
前記選択されたサービスのために特定のサービス宣言を決定するための手段を備え、
前記特定のサービス宣言における情報に基づいて、前記選択されたサービスをプロビジョニングするための手段と、
前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスにサービスを追加するためのサービス宣言テンプレートを提供するための手段と、
新たなサービスを前記クラウドインフラストラクチャシステムに登録するための変更されたサービス宣言を受取るための手段と、
前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに前記新たなサービスを追加するための手段をさらに備える、
前記特定のサービス宣言は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、
前記変更されたサービス宣言は、前記新たなサービスを可能化するために一組のリソースをプロビジョニングするための一組のプロシージャを示す情報を備える、システム。
【請求項９】
前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスは、サービスに特有のカスタムコードなしでプロビジョニングされる、請求項８に記載のシステム。
【請求項１０】
前記サービス宣言テンプレートは、拡張マークアップ言語（ＸＭＬ）文書またはＸＭＬスキーマ定義（ＸＳＤ）文書であり、前記サービス宣言テンプレートは、クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに追加されるサービスをプロビジョニングするための特定のスキーマおよび実行フローに関する情報を提供するための部分を提供する、請求項９に記載のシステム。
【請求項１１】
前記顧客から１つ以上の入力要件を受取るための手段をさらに備え、前記１つ以上の入力要件は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするために、前記特定のサービス宣言によって順番に必要とされる、請求項８〜１０のいずれか１項に記載のシステム。
【請求項１２】
一組のクラウドサービスを提供するように構成されたクラウドインフラストラクチャシステムのためのコンピュータ読取可能プログラムであって、前記コンピュータ読取可能プログラムは、
前記クラウドインフラストラクチャシステムに、前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスに対応する一組のサービス宣言を格納させるステップと、
前記クラウドインフラストラクチャシステムに、顧客からサブスクリプションオーダー情報を受取らせるステップとを実行させ、前記サブスクリプションオーダー情報は、前記クラウドインフラストラクチャシステムによって提供される前記一組のクラウドサービスから、選択されたサービスを特定し、
前記クラウドインフラストラクチャシステムに、前記選択されたサービスのために特定のサービス宣言を決定させるステップと、
前記クラウドインフラストラクチャシステムに、前記特定のサービス宣言における情報に基づいて、前記選択されたサービスをプロビジョニングさせるステップと、
前記クラウドインフラストラクチャシステムに、提供している前記一組のクラウドサービスにサービスを追加するためのサービス宣言テンプレートを提供させるステップと、
前記クラウドインフラストラクチャシステムに、新たなサービスを前記クラウドインフラストラクチャシステムに登録するための変更されたサービス宣言を受取らせるステップと、
前記クラウドインフラストラクチャシステムに、提供している前記一組のクラウドサービスに前記新たなサービスを追加させるステップとを実行させ、
前記特定のサービス宣言は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、
前記変更されたサービス宣言は、前記新たなサービスを可能化するために一組のリソースをプロビジョニングするための一組のプロシージャを示す情報を備える、コンピュータ読取可能プログラム。
【請求項１３】
前記クラウドインフラストラクチャシステムに、前記顧客から１つ以上の入力要件をさらに受取らせ、前記１つ以上の入力要件は、前記選択されたサービスを可能化するためにリソースをプロビジョニングするために、前記特定のサービス宣言によって順番に必要とされる、請求項１２に記載のコンピュータ読取可能プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、以下の出願の利益および優先権を主張し、以下の出願の内容全体は、全ての目的で引用によって本明細書に援用される：
（１）「テナント自動化システム」と題される２０１２年９月７日に出願された米国仮出願番号第６１／６９８，４１３号
（２）「サービス開発インフラストラクチャ」と題される２０１２年９月７日に出願された米国仮出願番号第６１／６９８，４５９号
（３）「クラウドインフラストラクチャ」と題される２０１３年３月１４日に出願された米国仮出願番号第６１／７８５，２９９号
（４）「クラウドベースのサービスのプロビジョニングのための宣言的かつ拡張可能なモデル」と題される２０１３年３月１５日に出願された米国仮出願番号第６１／７９４，２６９号
（５）「クラウドインフラストラクチャ」と題される２０１３年３月１５日に出願された米国仮出願番号第６１／７９４，４２７号、および
（６）上記の米国仮出願の優先権を主張する、「クラウドベースのサービスのプロビジョニングのための宣言的かつ拡張可能なモデル」と題される２０１３年５月３１日に出願された米国通常出願番号第１３／９０７，６１６号。
【背景技術】
【０００２】
背景
本開示は、コンピュータシステムおよびソフトウェアに関し、より特定的には、クラウド環境でのサービスのプロビジョニング（provision）を容易にして自動化するための技術に関する。
【０００３】
クラウドコンピューティングは、構成可能な演算リソース（例えばネットワーク、サーバ、ストレージ、アプリケーションおよびサービス）の共有プールへの便利なオンデマンドのネットワークアクセスを可能にするためのモデルである。クラウド（またはネットワーク）を介して提供またはアクセスされるサービスは、クラウドサービスと称される。サブスクライブを行う顧客がクラウドサービスを利用できるようにするためにクラウドサービスプロバイダが行う必要がある処理は数多くある。その複雑さのために、この処理の多くは依然として手動でなされている。例えば、このようなクラウドサービスを提供するためのプロビジョニングリソースは、非常に労働集約型のプロセスであり得る。
【発明の概要】
【課題を解決するための手段】
【０００４】
概要
この概要は、クレームされている主題の重要なまたは必須の特徴を特定することを意図したものではなく、クレームされている主題の範囲を決定するために単独で使用されるよう意図したものでもない。主題は、本特許の明細書全体の適切な箇所、任意のまたは全ての図面および各々の請求項を参照することによって理解されるべきである。
【０００５】
いくつかの実施例に従って、一組のサービスを提供するための方法が開示される。当該方法は、クラウドインフラストラクチャシステムが、上記クラウドインフラストラクチャシステムによって提供される一組のサービスからサービスを特定するサブスクリプションオーダー情報を格納するステップを備え得て、上記クラウドインフラストラクチャシステムは、１つ以上の演算装置を備える。上記１つ以上の演算装置からの演算装置は、上記サービスのためにサービス宣言を決定し得て、上記サービス宣言は、上記サービスを可能化するためにリソースをプロビジョニングするためのプロシージャを示す情報を備える。上記１つ以上の演算装置からの演算装置は、上記サービス宣言に基づいて上記サービスをプロビジョニングし得る。
【０００６】
いくつかの実施例によれば、システムは、一組のクラウドサービスを提供するように構成可能な１つ以上の演算装置と、上記一組のクラウドサービスからサービスを特定するサブスクリプションオーダー情報を格納するように構成可能なメモリとを備え得て、上記１つ以上の演算装置からの演算装置は、上記サービスのためにサービス宣言を決定するように構成可能であり、上記サービス宣言は、上記サービスを可能化するためにリソースをプロビジョニングするためのプロシージャを示す情報を備え、上記１つ以上の演算装置からの演算装置はさらに、上記サービス宣言に基づいて上記サービスをプロビジョニングするように構成可能である。
【０００７】
いくつかの実施例によれば、一組のクラウドサービスを提供するように構成されたクラウドインフラストラクチャシステムのためのコンピュータによって実行可能な命令を格納する１つ以上のコンピュータ読取可能媒体であって、上記コンピュータによって実行可能な命令は、実行されると、上記クラウドインフラストラクチャシステムにおける１つ以上の演算装置に、上記一組のクラウドサービスからサービスを特定するサブスクリプションオーダー情報を格納させ、上記クラウドインフラストラクチャシステムにおける１つ以上の演算装置に、上記サービスのためにサービス宣言を決定させ、上記サービス宣言は、上記サービスを可能化するためにリソースをプロビジョニングするためのプロシージャを示す情報を備え、上記コンピュータによって実行可能な命令はさらに、上記クラウドインフラストラクチャシステムにおける１つ以上の演算装置に、上記サービス宣言に基づいて上記サービスをプロビジョニングさせ得る。
【０００８】
いくつかの実施例によれば、一組のクラウドサービスを提供するためのシステムは、クラウドインフラストラクチャシステムによって提供される上記一組のクラウドサービスを特定するカタログ情報と、各サービスごとに上記サービスに関連付けられたサービス宣言とを格納するための手段と、顧客からサブスクリプションオーダー情報を受取るための手段とを備え、上記サブスクリプションオーダー情報は、上記クラウドインフラストラクチャシステムによって提供される上記一組のクラウドサービスから、選択されたサービスを特定し、上記システムはさらに、上記カタログ情報に基づいて、上記一組のサービス宣言から、上記選択されたサービスのために特定のサービス宣言を決定するための手段を備え、上記特定のサービス宣言は、上記選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、上記システムはさらに、上記特定のサービス宣言における上記情報に基づいて、上記選択されたサービスをプロビジョニングするための手段を備える。
【０００９】
いくつかの実施例によれば、一組のクラウドサービスを提供するように構成されたクラウドインフラストラクチャシステムのためのコンピュータ読取可能プログラムであって、上記コンピュータ読取可能プログラムは、上記クラウドインフラストラクチャシステムに、上記クラウドインフラストラクチャシステムによって提供される上記一組のクラウドサービスを特定するカタログ情報と、各サービスごとに上記サービスに関連付けられたサービス宣言とを格納させ、上記クラウドインフラストラクチャシステムに、顧客からサブスクリプションオーダー情報を受取らせ、上記サブスクリプションオーダー情報は、上記クラウドインフラストラクチャシステムによって提供される上記一組のクラウドサービスから、選択されたサービスを特定し、上記コンピュータ読取可能プログラムはさらに、上記クラウドインフラストラクチャシステムに、上記カタログ情報に基づいて、上記一組のサービス宣言から、上記選択されたサービスのために特定のサービス宣言を決定させ、上記特定のサービス宣言は、上記選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、上記コンピュータ読取可能プログラムはさらに、上記クラウドインフラストラクチャシステムに、上記特定のサービス宣言における上記情報に基づいて、上記選択されたサービスをプロビジョニングさせる。
【００１０】
本発明の例示的な実施例について、以下の図面を参照して以下で詳細に説明する。
【図面の簡単な説明】
【００１１】
【図１Ａ】本発明の一実施例に係るクラウドインフラストラクチャシステムの論理図である。
【図１Ｂ】本発明の実施例に係るクラウドインフラストラクチャシステムを実現するために使用され得るハードウェア／ソフトウェアスタックの簡略ブロック図である。
【図２】図１Ａに示されるクラウドインフラストラクチャシステムを実現するためのシステム環境の簡略ブロック図である。
【図３Ａ】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールによって実行され得る処理を示す簡略化されたフローチャート３００を示す。
【図３Ｂ】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。
【図４】本発明の実施例に係るＴＡＳコンポーネントの例示的な分散デプロイメントを示す。
【図５】本発明の実施例に係るクラウドインフラストラクチャシステムにおける１つ以上のモジュールとのＳＤＩモジュールのインタラクションを示す簡略ブロック図である。
【図６】本発明の実施例に係るＳＤＩモジュールのサブモジュールの簡略化された高レベル図を示す。
【図７Ａ】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＳＤＩコンポーネントによって実行され得る処理を示す簡略化されたフローチャートを示す。
【図７Ｂ】本発明の実施例に係るＮｕｖｉａｑシステム７１０および他のクラウドインフラストラクチャコンポーネントとのその関係の高レベルアーキテクチャを示す簡略ブロック図を示す。
【図７Ｃ】本発明の実施例に係るＮｕｖｉａｑシステムを使用するプロビジョニングプロセスのステップを示す例示的なシーケンス図を示す。
【図７Ｄ】本発明の実施例に係るＮｕｖｉａｑシステムを使用するデプロイメントプロセスのステップを示す例示的なシーケンス図を示す。
【図７Ｅ】本発明の実施例に係るデータベースサービスのためにプロビジョニングされたデータベースインスタンスの例を示す。
【図８】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。
【図９】本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。
【図１０】本発明の実施例に係るサービスブループリントコンポーネントの簡略化された高レベル図を示す。
【図１１】本発明の実施例に係るオーケストレーション（orchestration）エンジンを示す。
【図１２】本発明の実施例に係る実行フローを示す。
【図１３】本発明の実施例に係る非同期的なタスクの実行に関わる処理の一例を示す。
【図１４】本発明の実施例に従って実行され得るサービス宣言関連の処理を示す簡略化されたフローチャートを示す。
【図１５】本発明の実施例に従って実行され得るサービス宣言関連の処理を示す簡略化されたフローチャートを示す。
【図１６】本発明の実施例に従って使用され得る演算システム１０００の簡略ブロック図である。
【図１７】本発明の実施例に係る電子デバイス１８００の簡略ブロック図である。
【発明を実施するための形態】
【００１２】
詳細な説明
以下の説明では、本発明の実施例が十分に理解されるようにするために、説明の目的で具体的詳細を記載する。しかし、これらの具体的詳細がなくてもさまざまな実施例を実施できることは明らかであろう。図面および説明は、限定的であるよう意図されるものではない。
【００１３】
本発明の特定の実施例は、クラウドインフラストラクチャシステムによって提供されるサービスのプロビジョニング、管理および追跡を自動化するための技術を提供する。
【００１４】
特定の実施例では、クラウドインフラストラクチャシステムは、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に与えられる一連のアプリケーション、ミドルウェアおよびデータベースサービス提案を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウドである。
【００１５】
クラウドインフラストラクチャシステムは、クラウドインフラストラクチャシステムにおいてサービスおよびリソースについての顧客のサブスクリプションをプロビジョニング、管理および追跡する機能、クラウドインフラストラクチャシステムにおいてサービスを利用する顧客に予測可能な作業費用を提供する機能、クラウドインフラストラクチャシステムにおいて顧客のデータのロバストなアイデンティティドメインの分離および保護を提供する機能、クラウドインフラストラクチャシステムの設計の透過的なアーキテクチャおよび制御を顧客に提供する機能、データ保護の保証とデータプライバシ基準および規制の順守とを顧客に提供する機能、クラウドインフラストラクチャシステムにおいてサービスを構築およびデプロイするための統合された開発経験を顧客に提供する機能、ならびにクラウドインフラストラクチャシステムにおいてビジネスソフトウェア、ミドルウェア、データベースおよびインフラストラクチャサービスの間のシームレスな統合を顧客に提供する機能を含むがこれらに限定されない多くの機能を提供することができる。
【００１６】
特定の実施例では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な多数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書ではサービスインスタンスと称される。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザが利用可能なサービスはいずれも、クラウドサービスと称される。一般に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。例えば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得て、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションをオーダーし、使用し得る。
【００１７】
コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダによってユーザに提供されるかまたはそうでなければ当該技術分野において公知のストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーションまたは他のサービスへの保護されたコンピュータネットワークアクセスを含む。例えば、サービスは、インターネットを介したクラウド上のリモートストレージへの、パスワードによって保護されたアクセスを含んでいてもよい。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含んでいてもよい。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含んでいてもよい。
【００１８】
図１Ａは、本発明の一実施例に係るクラウドインフラストラクチャシステムの論理図である。クラウドインフラストラクチャシステム１００は、クラウドまたはネットワーク化された環境を介してさまざまなサービスを提供し得る。これらのサービスは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される１つ以上のサービスを含んでいてもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスをオーダーし得る。次いで、クラウドインフラストラクチャシステム１００は、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。
【００１９】
クラウドインフラストラクチャシステム１００は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。例えば、サービスは、クラウドインフラストラクチャシステム１００が（例えばオラクルによって所有される）クラウドサービスを販売する組織によって所有され、サービスが一般的な公営企業またはさまざまな産業企業が利用可能であるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１００が単一の組織のために単独で運営され、当該組織内の１つ以上のエンティティにサービスを提供することができるプライベートクラウドモデルの下で提供されてもよい。また、クラウドサービスは、クラウドインフラストラクチャシステム１００およびシステム１００によって提供されるサービスが関連のコミュニティの中のいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。
【００２０】
図１Ａに示されるように、クラウドインフラストラクチャシステム１００は、クラウドインフラストラクチャシステム１００によって提供されるサービスのプロビジョニングを可能にする、連携して動作する複数のコンポーネントを備えていてもよい。図１Ａに示される実施例では、クラウドインフラストラクチャシステム１００は、ＳａａＳプラットフォーム１０２と、ＰａａＳプラットフォーム１０４と、ＩａａＳプラットフォーム１１０と、インフラストラクチャリソース１０６と、クラウド管理機能１０８とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
【００２１】
ＳａａＳプラットフォーム１０２は、ＳａａＳカテゴリに入るクラウドサービスを提供するように構成される。例えば、ＳａａＳプラットフォーム１０２は、統合された開発およびデプロイメントプラットフォーム上で一連のオンデマンドのアプリケーションを構築および供給するための機能を提供し得る。ＳａａＳプラットフォーム１０２は、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォーム１０２によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム１００上で実行されるアプリケーションを利用することができる。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。
【００２２】
さまざまな異なるＳａａＳサービスが提供され得る。例としては、大きな組織に販売実績管理、企業統合およびビジネスの柔軟性などのためのソリューションを提供するサービスが挙げられるが、これに限定されるものではない。一実施例では、ＳａａＳサービスは、顧客関係管理（Customer Relationship Management：ＣＲＭ）サービス１１０（例えばオラクルクラウドによって提供されるフュージョンＣＲＭサービス）、人材管理（Human Capital Management：ＨＣＭ）／才能管理サービス１１２などを含んでいてもよい。ＣＲＭサービス１１０は、顧客への販売活動サイクルの報告および管理に向けられるサービスなどを含んでいてもよい。ＨＣＭ／才能サービス１１２は、顧客へのグローバルな労働力ライフサイクル管理および才能管理サービスの提供に向けられるサービスを含んでいてもよい。
【００２３】
標準化された、共有の、弾性的にスケーラブルなアプリケーション開発およびデプロイメントプラットフォームにおけるＰａａＳプラットフォーム１０４によって、さまざまな異なるＰａａＳサービスが提供され得る。ＰａａＳサービスの例としては、共有される共通のアーキテクチャ上で既存のアプリケーションを（オラクルなどの）組織が集約することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能が挙げられ得るが、これらに限定されるものではない。ＰａａＳプラットフォーム１０４は、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム１００によって提供されるＰａａＳサービスを取得することができる。ＰａａＳサービスの例としては、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクルデータベースクラウドサービス（Oracle Database Cloud Service：ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。
【００２４】
ＰａａＳプラットフォーム１０４によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム１００によってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施例では、クラウドインフラストラクチャシステム１００によって提供されるＰａａＳサービスは、データベースクラウドサービス１１４と、ミドルウェアクラウドサービス（例えばオラクルフュージョンミドルウェアサービス）１１６と、Ｊａｖａクラウドサービス１１７とを含んでいてもよい。一実施例では、データベースクラウドサービス１１４は、組織がデータベースリソースをプールし、データベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートし得て、ミドルウェアクラウドサービス１１６は、さまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し、Ｊａｖａクラウドサービス１１７は、クラウドインフラストラクチャシステム１００においてＪａｖａアプリケーションをデプロイするために顧客にプラットフォームを提供する。図１Ａに示されるＳａａＳプラットフォーム１０２およびＰａａＳプラットフォーム１０４におけるコンポーネントは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例では、ＳａａＳプラットフォーム１０２およびＰａａＳプラットフォーム１０４は、クラウドインフラストラクチャシステム１００の顧客に追加のサービスを提供するための追加のコンポーネントを含んでいてもよい。
【００２５】
ＩａａＳプラットフォーム１１０によってさまざまな異なるＩａａＳサービスが提供され得る。ＩａａＳサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のために、ストレージ、ネットワークおよび他の基礎的な演算リソースなどの基本的な演算リソースの管理および制御を容易にする。
【００２６】
特定の実施例では、クラウドインフラストラクチャシステム１００は、クラウドインフラストラクチャシステム１００の顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１０６を含む。一実施例では、インフラストラクチャリソース１０６は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め統合された、最適化された組み合わせを含む。
【００２７】
特定の実施例では、クラウド管理機能１０８は、クラウドインフラストラクチャシステム１００においてクラウドサービス（例えばＳａａＳ、ＰａａＳ、ＩａａＳサービス）の包括的な管理を提供する。一実施例では、クラウド管理機能１０８は、クラウドインフラストラクチャシステム１００によって受取られた顧客のサブスクリプションをプロビジョニング、管理および追跡するための機能などを含む。
【００２８】
図１Ｂは、本発明の実施例に係るクラウドインフラストラクチャシステム１００を実現するために使用され得るハードウェア／ソフトウェアスタックの簡略ブロック図である。図１Ｂに示される実現例は、図１Ｂに示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図１Ｂに示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム１００は、図１Ｂに示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。特定の実施例では、最適な性能を提供する垂直統合を提供するようにハードウェアおよびソフトウェアコンポーネントが積層される。
【００２９】
さまざまなタイプのユーザがクラウドインフラストラクチャシステム１００と対話し得る。これらのユーザは、例えば、デスクトップ、モバイル機器、タブレットなどのさまざまなクライアント装置を使用してクラウドインフラストラクチャシステム１００と対話し得るエンドユーザ１５０を含んでいてもよい。また、ユーザは、さまざまな統合された開発環境（integrated development environment：ＩＤＥ）を介して、および他のアプリケーションを介して、コマンドラインインターフェース（command line interface：ＣＬＩ）、アプリケーションプログラミングインターフェース（application programming interface：ＡＰＩ）を使用してクラウドインフラストラクチャシステム１００と対話し得る開発者／プログラマ１５２を含んでいてもよい。また、ユーザは、オペレーションスタッフ１５４を含んでいてもよい。これらは、クラウドサービスプロバイダのスタッフまたは他のユーザのスタッフを含んでいてもよい。
【００３０】
アプリケーションサービス層１５６は、クラウドインフラストラクチャシステム１００によって提供され得るさまざまなクラウドサービスを特定する。これらのサービスは、サービス統合および連結層１５８を介してそれぞれのソフトウェアコンポーネント１６０（例えばＪａｖａサービスを提供するためのオラクルウェブロジックサーバ、データベースサービスを提供するためのオラクルデータベースなど）にマッピングされるか、または関連付けられ得る。
【００３１】
特定の実施例では、クラウドインフラストラクチャシステム１００のさまざまなコンポーネントまたはモジュールおよびクラウドインフラストラクチャシステム１００によって提供されるサービスによって共有されるいくつかの内部サービス１６２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、ＩＤＥにおいてクラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。
【００３２】
ランタイムインフラストラクチャ層１６４は、さまざまな他の層およびコンポーネントが構築されるハードウェア層を表わす。特定の実施例では、ランタイムインフラストラクチャ層１６４は、ストレージ、処理およびネットワーキングリソースを提供するための１つのオラクルのExadataマシンを備えていてもよい。Exadataマシンは、さまざまなデータベースサーバ、ストレージサーバ、ネットワーキングリソース、およびクラウドサービス関連のソフトウェア層をホストするための他のコンポーネントから構成され得る。特定の実施例では、Exadataマシンは、ストレージ、演算、ネットワークおよびソフトウェアリソースの集合体を提供するエンジニアド・システムであるOracle Exalogicと連携するように設計され得る。ExadataおよびExalogicの組み合わせは、クラウドサービスを提供するための高性能で、高可用性で、スケーラブルで、安全な、管理されたプラットフォームを与える完全なハードウェアおよびソフトウェアエンジニアドソリューションを提供する。
【００３３】
図２は、本発明の実施例に係る図１Ａに示されるクラウドインフラストラクチャシステムを実現するためのシステム環境の簡略ブロック図である。示される実施例では、システム環境２３０は、クラウドインフラストラクチャシステム１００と対話するためにユーザによって使用され得る１つ以上のクライアント演算装置２２４，２２６および２２８を含む。クライアント装置は、クラウドインフラストラクチャシステム１００によって提供されるサービスを利用するためにクラウドインフラストラクチャシステム１００と対話するようにクライアント装置のユーザによって使用され得る、ウェブブラウザ、プロプライエタリクライアントアプリケーション（例えばOracle Forms）またはその他のアプリケーションなどのクライアントアプリケーションを動作させるように構成され得る。
【００３４】
図２に示されるクラウドインフラストラクチャシステム１００は、図２に示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２に示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム１００は、図２に示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。
【００３５】
クライアント演算装置２２４，２２６および２２８は、汎用パーソナルコンピュータ（一例として、マイクロソフトウィンドウズ（登録商標）および／またはアップルマッキントッシュオペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む）、（マイクロソフトウィンドウズモバイルなどのソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリーまたは使用可能な他の通信プロトコルである）携帯電話もしくはＰＤＡ、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むがこれに限定されるものではない）のいずれかを実行するワークステーションコンピュータ、またはその他の演算装置であってもよい。例えば、クライアント演算装置２２４，２２６および２２８は、ネットワーク（例えば下記のネットワーク２３２）を介して通信することができる、シン・クライアントコンピュータ、インターネットへの接続が可能なゲーム機および／またはパーソナルメッセージング装置などのその他の電子装置であってもよい。例示的なシステム環境２３０が３つのクライアント演算装置とともに示されているが、いかなる数のクライアント演算装置がサポートされてもよい。センサを有する装置などの他の装置がクラウドインフラストラクチャシステム１００と対話してもよい。
【００３６】
ネットワーク２３２は、クライアント２２４，２２６および２２８とクラウドインフラストラクチャシステム１００との間でのデータの通信および交換を容易にし得る。ネットワーク２３２は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋなどを含むがこれらに限定されるものではないさまざまな市販のプロトコルのいずれかを使用してデータ通信をサポートし得る、当業者になじみのある任意のタイプのネットワークであってもよい。単に一例として、ネットワーク２３２は、イーサネット（登録商標）ネットワーク、トークン・リング・ネットワークなどのローカルエリアネットワーク（local area network：ＬＡＮ）、広域ネットワーク、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を含むがこれに限定されるものではない仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えばＩＥＥＥ８０２．１Ｘの一連のプロトコル、当該技術分野において公知のブルートゥース（登録商標）プロトコルおよび／またはその他の無線プロトコルのいずれかの下で動作するネットワーク）、ならびに／または、これらのおよび／もしくは他のネットワークの任意の組み合わせであってもよい。
【００３７】
クラウドインフラストラクチャシステム１００は、汎用コンピュータ、特化サーバコンピュータ（一例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式のサーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／もしくは組み合わせであり得る１つ以上のコンピュータおよび／またはサーバを備えていてもよい。クラウドインフラストラクチャシステム１００を構成する演算装置は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、データベースサーバなどを含む、オペレーティングシステムまたはさまざまな追加のサーバアプリケーションおよび／もしくは中間層アプリケーションのいずれかを実行し得る。例示的なデータベースサーバとしては、オラクル、マイクロソフト、サイベース、ＩＢＭなどから市販されているものが挙げられるが、これらに限定されるものではない。
【００３８】
さまざまな実施例では、クラウドインフラストラクチャシステム１００は、クラウドインフラストラクチャシステム１００によって提供されるサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理および追跡するように適合され得る。一実施例では、図２に示されるように、クラウドインフラストラクチャシステム１００におけるコンポーネントは、アイデンティティ管理（Identity Management：ＩＤＭ）モジュール２００と、サービスモジュール２０２と、テナント自動化システム（Tenant Automation System：ＴＡＳ）モジュール２０４と、サービスデプロイメントインフラストラクチャ（Service Deployment Infrastructure：ＳＤＩ）モジュール２０６と、エンタープライズマネージャ（Enterprise Manager：ＥＭ）モジュール２０８と、ストアユーザインターフェース（user interface：ＵＩ）２１０、クラウドユーザインターフェース（ＵＩ）２１２およびサポートユーザインターフェース（ＵＩ）２１６などの１つ以上のフロントエンドウェブインターフェースと、オーダー管理モジュール２１４と、販売スタッフ２１８と、オペレータスタッフ２２０と、オーダーデータベース２２２とを含む。これらのモジュールは、汎用コンピュータ、特化サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および／もしくは組み合わせであり得る１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、またはそれらを使用して提供されてもよい。一実施例では、これらのモジュールのうちの１つ以上は、クラウドインフラストラクチャシステム１００におけるクラウド管理機能１０８またはＩａａＳプラットフォーム１１０によって提供され得る。図２に示されるクラウドインフラストラクチャシステム１００のさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図２に示されるものよりも多くのまたは少ないモジュールを含んでいてもよい。
【００３９】
例示的なオペレーションにおいて、（１）において、クライアント装置２２４または２２６などのクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム１００によって提供されるさまざまなサービスをブラウズし、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスについてのサブスクリプションのオーダーを行うことによって、クラウドインフラストラクチャシステム１００と対話し得る。特定の実施例では、顧客は、ストアＵＩ２１０またはクラウドＵＩ２１２にアクセスし、これらのユーザインターフェースを介してサブスクリプションオーダーを行い得る。
【００４０】
顧客がオーダーを行ったことに応答してクラウドインフラストラクチャシステム１００によって受取られるオーダー情報は、顧客と、顧客がサブスクライブする予定の、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスとを特定する情報を含んでいてもよい。単一のオーダーは、複数のサービスのオーダーを含んでいてもよい。例えば、顧客は、クラウドＵＩ２１２にログインして、同一のオーダーにおいてＣＲＭサービスおよびＪａｖａクラウドサービスについてのサブスクリプションを要求し得る。
【００４１】
さらに、オーダーは、オーダーされたサービスについての１つ以上のサービスレベルも含んでいてもよい。本明細書で使用され、以下でより詳細に説明されるように、サービスについてのサービスレベルは、ストレージの量、演算リソースの量、データ転送設備などの、サブスクリプションの文脈において要求されたサービスを提供するために割り当てられるリソースの量を決定する。例えば、ベーシックなサービスレベルは、最小レベルのストレージ、データ伝送またはユーザの数を提供することができ、より高いサービスレベルは、さらなるリソースを含み得る。
【００４２】
また、いくつかの例では、クラウドインフラストラクチャシステム１００によって受取られるオーダー情報は、顧客レベルおよびサービスが求められる期間を示す情報を含んでいてもよい。顧客レベルは、サブスクリプション要求を行う顧客の優先度を規定する。一例では、優先度は、顧客とクラウドサービスのプロバイダとの間で合意されたサービスレベル合意書（Service Level Agreement：ＳＬＡ）によって規定されるようにクラウドインフラストラクチャシステム１００が顧客に保証または約束するサービスの質に基づいて決定され得る。一例では、さまざまな顧客レベルは、ベーシックレベル、シルバーレベルおよびゴールドレベルを含む。サービスの期間は、当該サービスの開始日および時刻と、当該サービスが求められる期間とを規定し得る（例えばサービス終了日および時刻が規定されてもよい）。
【００４３】
一実施例では、顧客は、ストアＵＩ２１０を介して新たなサブスクリプションを要求するか、またはクラウドＵＩ２１２を介してトライアルサブスクリプションを要求し得る。特定の実施例では、ストアＵＩ２１０は、サービスプロバイダの電子商取引ストアフロントに相当し得る（例えばオラクルクラウドサービスのためのwww.oracle.com/store）。クラウドＵＩ２１２は、サービスプロバイダのためのビジネスインターフェースに相当し得る。顧客は、クラウドＵＩ２１２を介して、利用可能なサービスを調査し、関心のあるサービスにサインアップすることができる。クラウドＵＩ２１２は、クラウドインフラストラクチャシステム１００によって提供されるトライアルサブスクリプションをオーダーするのに必要なユーザ入力を取込む。また、クラウドＵＩ２１２は、アカウント機能を閲覧し、クラウドインフラストラクチャシステム１００内に位置するランタイム環境を構成するために使用され得る。新たなサブスクリプションのオーダーを行うことに加えて、ストアＵＩ２１０は、サブスクリプションのサービスレベルの変更、サブスクリプションの期間の延長、サブスクリプションのサービスレベルの向上、既存のサブスクリプションの終了などの他のサブスクリプション関連のタスクを顧客が実行できるようにもし得る。
【００４４】
（１）につきオーダーが行われた後、（２）において、ストアＵＩ２１０またはクラウドＵＩ２１２のいずれかを介して受取られるオーダー情報がオーダーデータベース２２２に格納され、当該オーダーデータベース２２２は、クラウドインフラストラクチャシステム１００によって操作されて他のシステム要素と連携して利用されるいくつかのデータベースのうちの１つであり得る。オーダーデータベース２２２は図２では単一のデータベースとして論理的に示されているが、実際の実現例では、これは１つ以上のデータベースを備えていてもよい。
【００４５】
（３）において、オーダーはオーダー管理モジュール２１４に送られる。オーダー管理モジュール２１４は、オーダーの検証および検証時のオーダーの予約などのオーダーに関連する課金およびアカウンティング機能を実行するように構成される。特定の実施例では、オーダー管理モジュール２１４は、契約管理モジュールと、インストールベースモジュールとを含んでいてもよい。契約管理モジュールは、クラウドインフラストラクチャシステム１００との顧客のサービスレベル合意書（ＳＬＡ）などの顧客のサブスクリプションオーダーに関連付けられた契約情報を格納し得る。インストールベースモジュールは、顧客のサブスクリプションオーダーにおけるサービスの詳細な説明を含み得る。オーダー情報に加えて、インストールベースモジュールは、サービスに関連するインストールの詳細、製品状態およびサービスに関連するサポートサービス履歴を追跡し得る。顧客が新たなサービスをオーダーするかまたは既存のものをアップグレードすると、インストールベースモジュールは、新たなオーダー情報を自動的に追加し得る。
【００４６】
（４）において、オーダーに関する情報は、ＴＡＳモジュール２０４に通信される。一実施例では、ＴＡＳモジュール２０４は、顧客によって行われたオーダーについてのサービスおよびリソースのプロビジョニングをオーケストレートするためにオーダー情報を利用する。（５）において、ＴＡＳコンポーネント２０４は、ＳＤＩモジュール２０６のサービスを使用してサブスクライブされたサービスをサポートするために、リソースのプロビジョニングをオーケストレートする。（６）において、ＴＡＳモジュール２０４は、ＳＤＩモジュール２０６から受取られた、プロビジョニングされたオーダーに関連する情報をサービスモジュール２０２に提供する。いくつかの実施例では、（７）において、ＳＤＩモジュール２０６は、顧客のサブスクリプションオーダーを実現するために必要なリソースを割り当てて構成するために、サービスモジュール２０２によって提供されるサービスも使用し得る。
【００４７】
（８）において、サービスモジュール２０２は、オーダーの状態に関する通知をクライアント装置２２４，２２６および２２８上の顧客に送る。
【００４８】
特定の実施例では、ＴＡＳモジュール２０４は、互いに関連付けられたビジネスプロセスを管理し、ビジネスロジックを適用してオーダーがプロビジョニングに進むべきか否かを判断するオーケストレーションコンポーネントとして機能する。一実施例では、新たなサブスクリプションのオーダーを受取ると、ＴＡＳモジュール２０４は、リソースを割り当てて、当該サブスクリプションオーダーを実現するために必要なそれらのリソースを構成するために、ＳＤＩモジュール２０６に要求を送る。ＳＤＩモジュール２０６は、顧客によってオーダーされたサービスのためのリソースの割り当てを可能にする。ＳＤＩモジュール２０６は、クラウドインフラストラクチャシステム１００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。したがって、ＴＡＳモジュール２０４は、サービスおよびリソースがオンザフライで実際にプロビジョニングされるか否か、または予めプロビジョニングされて要求時に単に配分／割り当てられるか否かなどの実装詳細から切離され得る。
【００４９】
特定の実施例では、ユーザは、オーダー管理モジュール２１４と直接対話して、オーダーの検証および検証時のオーダーの予約などの課金およびアカウンティング関連機能を実行するためにストアＵＩ２１０を使用し得る。いくつかの実施例では、顧客がオーダーを行う代わりに、（９）において、オーダーはその代わりに、顧客のサービス担当者または販売担当者などの顧客を代表する販売スタッフ２１８によって行われてもよい。販売スタッフ２１８は、オーダーを行うためまたは顧客に見積もりを提供するためにオーダー管理モジュール２１４によって提供されるユーザーインターフェース（図２には図示せず）を介して、オーダー管理モジュール２１４と直接対話し得る。例えば、これは、オーダーがオーダー管理モジュール２１４を介して顧客の販売担当者によって行われ得る大口顧客のためになされ得る。販売担当者は、顧客を代表してサブスクリプションを準備し得る。
【００５０】
ＥＭモジュール２０８は、クラウドインフラストラクチャシステム１００における顧客のサブスクリプションの管理および追跡に関連するアクティビティをモニタリングするように構成される。ＥＭモジュール２０８は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップ時間およびシステムダウン時間の量などのサブスクリプションオーダーにおけるサービスについての使用統計を収集する。（１０）において、クラウドインフラストラクチャシステム１００のプロバイダの従業員であってもよいホストオペレータスタッフ２２０は、サービスがクラウドインフラストラクチャシステム１００内でプロビジョニングされるシステムおよびリソースを管理するために、エンタープライズマネージャユーザインターフェース（図２には図示せず）を介してＥＭモジュール２０８と対話し得る。
【００５１】
アイデンティティ管理（ＩＤＭ）モジュール２００は、クラウドインフラストラクチャシステム１００においてアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成される。一実施例では、ＩＤＭモジュール２００は、クラウドインフラストラクチャシステム１００によって提供されるサービスを利用したい顧客についての情報を制御する。このような情報は、このような顧客のアイデンティティを認証する情報、および、さまざまなシステムリソース（例えばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを実行することが認可されるかを表わす情報を含み得る。また、ＩＤＭモジュール２００は、各顧客についての記述的情報および当該記述的情報がどのようにして誰によってアクセスおよび修正され得るかについての記述的情報の管理を含み得る。
【００５２】
一実施例では、アイデンティティ管理モジュール２００によって管理される情報は、別個のアイデンティティドメインを作成するために分割可能である。特定のアイデンティティドメインに属する情報は、全ての他のアイデンティティドメインから切離されることができる。また、アイデンティティドメインは、複数の別個のテナントによって共有可能である。各々のこのようなテナントは、クラウドインフラストラクチャシステム１００においてサービスにサブスクライブする顧客であり得る。いくつかの実施例では、顧客は、１つまたは多くのアイデンティティドメインを有することができ、各アイデンティティドメインは、１つ以上のサブスクリプションに関連付けられ得て、各サブスクリプションは、１つまたは多くのサービスを有する。例えば、単一の顧客は大規模事業体に相当し得て、この大規模事業体内の部門／部署についてアイデンティティドメインが作成されてもよい。さらに、ＥＭモジュール２０８およびＩＤＭモジュール２００は、クラウドインフラストラクチャシステム１００において顧客のサブスクリプションを管理および追跡するために、それぞれ（１１）および（１２）においてオーダー管理モジュール２１４と対話し得る。
【００５３】
一実施例では、（１３）において、サポートＵＩ２１６を介してサポートサービスも顧客に提供され得る。一実施例では、サポートＵＩ２１６は、サポートスタッフが（１４）においてサポートサービスを実行するようにサポートバックエンドシステムを介してオーダー管理モジュール２１４と対話することを可能にする。クラウドインフラストラクチャシステム１００におけるサポートスタッフおよび顧客は、サポートＵＩ２１６を介して、バグ報告を提出し、これらの報告の状態を確認することができる。
【００５４】
図２に図示されない他のインターフェースもクラウドインフラストラクチャシステム１００によって提供されてもよい。例えば、アイデンティティドメイン管理者は、ドメインおよびユーザアイデンティティを構成するためにＩＤＭモジュール２００へのユーザインターフェースを使用し得る。また、顧客は、利用したい各サービスのための別個のインターフェースにログインし得る。特定の実施例では、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスにサブスクライブしたい顧客は、さまざまな役割および任務も割り当てられ得る。一実施例では、顧客に割り当てられ得るさまざまな役割および任務は、バイヤ、アカウント管理者、サービス管理者、アイデンティティドメイン管理者、またはクラウドインフラストラクチャシステム１００によって提供されるサービスおよびリソースを利用するユーザの役割および任務を含んでいてもよい。さまざまな役割および任務は、以下の図４にさらに十分に示されている。
【００５５】
図３Ａは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールによって実行され得る処理を示す簡略化されたフローチャート３００を示す。図３Ａに示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（例えばコード、命令、プログラム）、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、（例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の）メモリに格納されてもよい。図３Ａに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図３Ａに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図３Ａに示される処理は、図３Ｂに詳細に示されるように、ＴＡＳコンポーネント２０４における１つ以上のコンポーネントによって実行され得る。
【００５６】
３０２において、顧客のサブスクリプションオーダーが処理される。当該処理は、一例ではオーダーの認証を含んでいてもよい。オーダーの認証は、顧客がサブスクリプションの代金を支払ったことを保証すること、および、顧客が同一の名前を備えたサブスクリプションをまだ有していないことを保証すること、または、（ＣＲＭサービスの場合など）許可されないサブスクリプションタイプについて同一のアイデンティティドメインにおいて同一タイプの複数のサブスクリプションを顧客が作成しようと試みていないことを保証することを含む。また、処理は、クラウドインフラストラクチャシステム１００によって処理されている各オーダーについてのオーダーの状態の追跡を含んでいてもよい。
【００５７】
３０４において、オーダーに関連付けられたビジネスプロセスが特定される。いくつかの例では、複数のビジネスプロセスがオーダーについて特定され得る。各ビジネスプロセスは、オーダーのさまざまな局面を処理するための一連のステップを特定する。一例として、第１のビジネスプロセスは、オーダーのための物理的リソースのプロビジョニングに関連する１つ以上のステップを特定し得て、第２のビジネスプロセスは、オーダーについての顧客アイデンティティとともにアイデンティティドメインを作成することに関連する１つ以上のステップを特定し得て、第３のビジネスプロセスは、ユーザについての顧客記録の作成などのバックオフィス機能の実行、オーダーに関連するアカウンティング機能の実行などに関連する１つ以上のステップを特定し得る。特定の実施例では、オーダーにおけるさまざまなサービスを処理するためにさまざまなビジネスプロセスも特定されてもよい。例えば、ＣＲＭサービスおよびデータベースサービスを処理するためにさまざまなビジネスプロセスが特定されてもよい。
【００５８】
３０６において、３０４でオーダーについて特定されたビジネスプロセスが実行される。オーダーに関連付けられたビジネスプロセスの実行は、ステップ３０４において特定されたビジネスプロセスに関連付けられた一連のステップのオーケストレートを含んでいてもよい。例えば、オーダーのための物理的リソースのプロビジョニングに関連するビジネスプロセスの実行は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成するために、ＳＤＩモジュール２０６に要求を送ることを含んでいてもよい。
【００５９】
３０８において、プロビジョニングされたオーダーの状態に関する通知が顧客に送られる。ステップ３０２，３０４，３０６および３０８の実行に関連するさらなる説明については、図３Ｂに詳細に記載されている。
【００６０】
図３Ｂは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。一実施例では、図３Ｂに示されるモジュールは、図３Ａに示されるステップ３０２〜３０８に記載された処理を実行する。示される実施例では、ＴＡＳモジュール２０４は、オーダー処理モジュール３１０と、ビジネスプロセス識別子３１２と、ビジネスプロセスエクセキュータ３１６と、超過フレームワーク３２２と、ワークフロー特定モジュール３２４と、バンドルされたサブスクリプション生成モジュール３２６とを備える。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。図３Ｂに示されるＴＡＳモジュールのさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図３Ｂに示されるものよりも多くのまたは少ないモジュールを含んでいてもよい。
【００６１】
一実施例では、オーダー処理モジュール３１０は、顧客からのオーダーを１つ以上の入力ソース３２１から受取る。例えば、オーダー処理モジュール３１０は、一実施例ではクラウドＵＩ２１２またはストアＵＩ２１０を介してオーダーを直接受取ってもよい。代替的に、オーダー処理モジュール３１０は、オーダー管理モジュール２１４またはオーダーデータベース２２２からオーダーを受取ってもよい。次いで、オーダー処理モジュール３１０は、オーダーを処理する。特定の実施例では、オーダーの処理は、サービスタイプ、サービスレベル、顧客レベル、リソースのタイプ、サービスインスタンスに割り当てられるリソースの量、およびサービスが求められる期間などのオーダーについての情報を含む顧客記録の生成を含む。処理の一部として、オーダー処理モジュール３１０は、オーダーが有効なオーダーであるか否かも判断する。これは、顧客が同一の名前を備えたサブスクリプションをまだ有していないことを保証すること、または、（フュージョンＣＲＭサービスの場合など）許可されないサブスクリプションタイプについて同一のアイデンティティドメインにおいて同一タイプの複数のサブスクリプションを顧客が作成しようと試みていないことを保証することを含む。
【００６２】
また、オーダー処理モジュール３１０は、オーダーについてのさらなる処理を実行し得る。処理は、クラウドインフラストラクチャシステム１００によって処理されている各オーダーについてのオーダーの状態の追跡を含んでいてもよい。一実施例では、オーダー処理モジュール３１０は、オーダーに関係するいくつかの状態を特定するために各オーダーを処理し得る。一例では、オーダーのさまざまな状態は、初期化状態、プロビジョニング状態、アクティブ状態、管理が必要な状態、エラー状態などであり得る。初期化状態は、新たなオーダーの状態を指し、プロビジョニング状態は、オーダーについてのサービスおよびリソースがプロビジョニングされた時点のオーダーの状態を指す。オーダーがＴＡＳモジュール２０４によって処理され、その趣旨の通知が顧客に与えられると、オーダーはアクティブ状態になる。問題を解決するために管理者による介入が必要な場合、オーダーは管理が必要な状態である。オーダーを処理できない場合、オーダーはエラー状態である。オーダー進捗状態の維持に加えて、オーダー処理モジュール３１０は、プロセスの実行中に遭遇するいかなる障害についても詳細な情報を維持する。他の実施例では、以下で詳細に記載されるように、オーダー処理モジュール３１０によって実行されるさらなる処理は、サブスクリプションにおけるサービスのサービスレベルの変更、サブスクリプションに含まれるサービスの変更、サブスクリプションの期間の延長、およびサブスクリプションのキャンセルまたはサブスクリプションにおけるさまざまな期間にわたるさまざまなサービスレベルの指定も含んでいてもよい。
【００６３】
オーダーがオーダー処理モジュール３１０によって処理された後、オーダーがプロビジョニングに進むべきか否かを判断するためにビジネスロジックが適用される。一実施例では、オーダーのオーケストレートの一部として、ビジネスプロセス識別子３１２は、処理されたオーダーをオーダー処理モジュール３１０から受取って、ビジネスロジックを適用して、処理中のオーダーで使用されるべき特定のビジネスプロセスを特定する。一実施例では、ビジネスプロセス識別子３１２は、オーダーで使用されるべき特定のビジネスプロセスを決定するために、サービスカタログ３１４に格納されている情報を利用し得る。一実施例では、図３Ａに示されるように、オーダーについて複数のビジネスプロセスが特定されてもよく、各ビジネスプロセスは、オーダーのさまざまな局面を処理するための一連のステップを特定する。別の実施例では、上記のように、ＣＲＭサービスまたはデータベースサービスなどのさまざまなタイプのサービスまたはサービスの組み合わせについてさまざまなビジネスプロセスが規定されてもよい。一実施例では、サービスカタログ３１４は、オーダーを特定のタイプのビジネスプロセスにマッピングする情報を格納し得る。ビジネスプロセス識別子３１２は、処理中のオーダーについての特定のビジネスプロセスを特定するためにこの情報を使用し得る。
【００６４】
ビジネスプロセスが特定されると、ビジネスプロセス識別子３１２は、実行されるべき特定のビジネスプロセスをビジネスプロセスエクセキュータ３１６に通信する。次いで、ビジネスプロセスエクセキュータ３１６は、クラウドインフラストラクチャシステム１００における１つ以上のモジュールと連携して動作することによって、特定されたビジネスプロセスのステップを実行する。いくつかの実施例では、ビジネスプロセスエクセキュータ３１６は、ビジネスプロセスに関連付けられたステップを実行するためのオーケストレータの役割を果たす。例えば、ビジネスプロセスエクセキュータは、オーダーに関連するワークフローを特定して、オーダーにおけるサービスの超過を判断するか、またはオーダーに関連するサービスコンポーネントを特定するビジネスプロセスにおけるステップを実行するようにオーダー処理モジュール３１０と対話し得る。
【００６５】
一例では、ビジネスプロセスエクセキュータ３１６は、サブスクリプションオーダーにおいて要求されたサービスのためにリソースを割り当ててプロビジョニングするためのビジネスプロセスにおけるステップを実行するようにＳＤＩモジュール２０６と対話する。この例では、ビジネスプロセスにおける各ステップごとに、ビジネスプロセスエクセキュータ３１６は、リソースを割り当てて、特定のステップを実現するために必要なリソースを構成するために、ＳＤＩコンポーネント２０６に要求を送り得る。ＳＤＩコンポーネント２０６は、リソースの実際の割り当てを担当する。オーダーのビジネスプロセスの全てのステップが実行されると、ビジネスプロセスエクセキュータ３１６は、サービスコンポーネント２０２のサービスを利用することによって、処理されたオーダーの通知を顧客に送り得る。通知は、処理されたオーダーの詳細を有する電子メール通知を顧客に送ることを含んでいてもよい。また、電子メール通知は、顧客がサブスクライブされたサービスにアクセスすることを可能にするための、オーダーに関連するデプロイメント情報も含んでいてもよい。
【００６６】
特定の実施例では、ＴＡＳモジュール２０４は、ＴＡＳモジュール２０４がクラウドインフラストラクチャシステム１００における他のモジュールと対話し、他のモジュールがＴＡＳモジュール２０４と対話することを可能にする１つ以上のＴＡＳアプリケーションプログラミングインターフェース（Application Programming Interface：ＡＰＩ）３１８を提供し得る。例えば、ＴＡＳ  ＡＰＩは、顧客のサブスクリプションオーダーのためのリソースをプロビジョニングするために、非同期シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol：ＳＯＡＰ）ベースのウェブサービスコールを介してＳＤＩモジュール２０６と対話するシステムプロビジョニングＡＰＩを含んでいてもよい。一実施例では、ＴＡＳモジュール２０４は、システムおよびサービスインスタンスの作成および削除を達成し、サービスインスタンスを向上したサービスレベルに切替え、サービスインスタンスを関連付けるためにも、システムプロビジョニングＡＰＩを利用し得る。この一例は、安全なウェブサービス通信を可能にするためのフュージョンアプリケーションサービスインスタンスへのＪａｖａサービスインスタンスの関連付けである。また、ＴＡＳ  ＡＰＩは、処理されたオーダーを顧客に通知するためにサービスモジュール２０２と対話する通知ＡＰＩも含んでいてもよい。特定の実施例では、ＴＡＳモジュール２０４は、サブスクリプション情報、機能停止および通知（例えば計画されたダウンタイム）もサービスコンポーネント２０２に定期的に伝える。
【００６７】
特定の実施例では、ＴＡＳモジュール２０４は、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などのプロビジョニングされたサービスの各々についての使用統計をＥＭモジュール２０８から定期的に受取る。超過フレームワーク３２２は、サービスの過剰使用が生じたか否かを判断し、生じた場合には超過に対してどれぐらい課金されるかを判断するために当該使用統計を利用し、この情報をオーダー管理モジュール２１４に提供する。
【００６８】
特定の実施例では、ＴＡＳモジュール２０４は、顧客のサブスクリプションオーダーの処理に関連付けられた１つ以上のワークフローを特定するように構成されるオーダーワークフロー特定モジュール３２４を含む。特定の実施例では、ＴＡＳモジュール２０４は、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスについてのサブスクリプションオーダーを顧客が行うと顧客のためにサブスクリプションオーダーを生成するためのサブスクリプションオーダー生成フレームワーク３２６を含んでいてもよい。一実施例では、サブスクリプションオーダーは、当該サブスクリプションオーダーにおいて顧客によって要求されたサービスを提供することを担当する１つ以上のサービスコンポーネントを含む。
【００６９】
さらに、ＴＡＳモジュール２０４は、もしあれば顧客が利用可能な履歴情報を考慮に入れながら、顧客によってサブスクライブされた１つ以上のサービスのためのリソースのプロビジョニングを可能にするために、テナント情報システム（Tenant Information System：ＴＩＳ）データベース３２０などの１つ以上のさらなるデータベースとも対話し得る。ＴＩＳデータベース３２０は、顧客によってサブスクライブされたオーダーに関係する履歴オーダー情報および履歴使用情報を含んでいてもよい。
【００７０】
ＴＡＳモジュール２０４は、さまざまなデプロイメントモデルを使用してデプロイされ得る。特定の実施例では、デプロイメントは、１つ以上の分散されたコンポーネントと遣り取りする中心コンポーネントを含む。分散されたコンポーネントは、例えばさまざまなデータセンタとしてデプロイされてもよく、したがってデータセンタコンポーネントとも称されてもよい。中心コンポーネントは、クラウドインフラストラクチャシステム１００においてオーダーを処理してサービスをまとめるための機能を含み、データセンタコンポーネントは、サブスクライブされたサービスのためにリソースを提供するランタイムシステムをプロビジョニングして動作させるための機能を提供する。
【００７１】
図４は、本発明の実施例に係るＴＡＳモジュールの例示的な分散型デプロイメントを示す。図４に示される実施例では、ＴＡＳモジュール２０４の分散型デプロイメントは、ＴＡＳ中心コンポーネント４００と、１つ以上のＴＡＳデータセンタ（Data Center：ＤＣ）コンポーネント４０２，４０４および４０６とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
【００７２】
一実施例では、ＴＡＳ中心コンポーネント４００の任務は、顧客オーダーを受取って、新たなサブスクリプションの作成、サブスクリプションにおけるサービスのサービスレベルの変更、サブスクリプションに含まれるサービスの変更、およびサブスクリプションの期間の延長、またはサブスクリプションのキャンセルなどのオーダー関連のビジネスオペレーションを実行するための集中型コンポーネントを提供することを含むが、これに限定されるものではない。また、ＴＡＳ中心コンポーネント４００の任務は、クラウドインフラストラクチャシステム１００によって必要とされるサブスクリプションデータを維持および供給すること、ならびに、全てのバックオフィスインタラクションに対処するためにオーダー管理モジュール２１４、サポートＵＩ２１６、クラウドＵＩ２１２およびストアＵＩ２１０と遣り取りすることも含んでいてもよい。
【００７３】
一実施例では、ＴＡＳ  ＤＣ４０２，４０４および４０６の任務は、顧客によってサブスクライブされた１つ以上のサービスのためのリソースのプロビジョニングをオーケストレートするためのランタイムオペレーションを実行することを含むが、これに限定されるものではない。また、ＴＡＳ  ＤＣ４０２，４０４および４０６は、サブスクリプションオーダーのロッキング、アンロッキング、可能化または不可能化、オーダーに関連するメトリックの収集、オーダーの状態の判断、およびオーダーに関連する通知イベントの送信などのオペレーションを実行するための機能も含む。
【００７４】
図４に示される分散型ＴＡＳシステムの例示的なオペレーションでは、ＴＡＳ中心コンポーネント４００は、最初に、クラウドＵＩ２１２、ストアＵＩ２１０を介して、オーダー管理モジュール２１４を介して、またはオーダーデータベース２２２を介して、顧客からオーダーを受取る。一実施例では、顧客は、財務情報ならびにサブスクリプションをオーダーおよび／または変更するための権限を有するバイヤに相当する。一実施例では、オーダー情報は、顧客、顧客がサブスクライブしたいサービスのタイプ、および要求への対処を担当するアカウント管理者を特定する情報を含む。特定の実施例では、アカウント管理者は、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスへのサブスクリプションについてのオーダーを顧客が行うと、顧客によって任命され得る。オーダー情報に基づいて、ＴＡＳ中心コンポーネント４００は、オーダーが発生するアメリカ、ＥＭＥＡまたはアジア太平洋などの世界のデータ領域、およびオーダーをプロビジョニングするためにデプロイされる特定のＴＡＳ  ＤＣ（例えば４０２，４０４または４０６）を特定する。一実施例では、オーダーをプロビジョニングするためにデプロイされる（例えばＤＣ４０２，４０４または４０６の中からの）特定のＴＡＳ  ＤＣは、要求が発生した地理的なデータ領域に基づいて決定される。
【００７５】
次いで、ＴＡＳ中心コンポーネント４００は、オーダー要求についてのサービスをプロビジョニングするためにオーダー要求を特定のＴＡＳ  ＤＣに送る。一実施例では、ＴＡＳ  ＤＣ４０２，４０４または４０６は、特定のＴＡＳ  ＤＣにおいてオーダー要求を処理することを担当するサービス管理者およびアイデンティティドメイン管理者を特定する。サービス管理者およびアイデンティティ管理者は、サブスクリプションオーダーにおいて特定されるアカウント管理者によって任命され得る。ＴＡＳ  ＤＣ４０２，４０４または４０６は、オーダーのための物理的リソースのプロビジョニングをオーケストレートするためにＳＤＩモジュール２０６と通信する。それぞれのＴＡＳ  ＤＣ４０２，４０４または４０６におけるＳＤＩモジュール２０６は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成する。
【００７６】
特定の実施例では、ＴＡＳ  ＤＣ４０２，４０４または４０６は、サブスクリプションに関連付けられたアイデンティティドメインを特定する。ＳＤＩコンポーネント２０６は、既存のアイデンティティドメインの特定または新たなアイデンティティドメインの作成のためにアイデンティティドメイン情報をＩＤＭコンポーネント２００（図２に図示）に提供し得る。オーダーがそれぞれのＴＡＳ  ＤＣ４０２，４０４または４０６におけるＳＤＩモジュールによってプロビジョニングされると、ＴＡＳ中心コンポーネント４００は、サポートシステムにおけるプロビジョニングされたリソースに関する情報をサポートＵＩ２１６を介して配置し得る。情報は、例えばサービスに関連するリソースメトリックおよびサービスの使用統計の表示を含んでいてもよい。
【００７７】
オペレーション時に、各データセンタにおいて、ＥＭモジュール２０８は、当該データセンタにおいてプロビジョニングされたプロビジョニングされたサービスの各々について、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などの使用統計を定期的に収集する。これらの統計は、ＥＭモジュール２０８にローカルな（すなわち、同一のデータセンタにおける）ＴＡＳ  ＤＣに提供される。実施例では、ＴＡＳ  ＤＣは、サービスの過剰使用が生じたか否かを判断し、生じた場合には超過に対してどれぐらい課金されるかを判断するために使用統計を使用し、課金情報をオーダー管理モジュール２１４に提供し得る。
【００７８】
図５は、本発明の実施例に係るクラウドインフラストラクチャシステムにおける１つ以上のモジュールとのＳＤＩモジュールのインタラクションを示す簡略ブロック図である。一実施例では、ＳＤＩモジュール２０６は、ＴＡＳモジュール２０４によって受取られたサブスクリプションオーダーにおけるサービスのためのリソースをプロビジョニングするためにＴＡＳモジュール２０４と対話する。特定の実施例では、図５に示されるモジュールのうちの１つ以上は、クラウドインフラストラクチャシステム１００内のモジュールであってもよい。他の実施例では、ＳＤＩモジュール２０６と対話するモジュールのうちの１つ以上は、クラウドインフラストラクチャシステム１００の外側にあってもよい。また、代替的な実施例は、図５に示されるものよりも多くのまたは少ないモジュールを有していてもよい。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
【００７９】
一実施例では、ＳＤＩモジュール２０６におけるモジュールは、クラウドインフラストラクチャシステム１００内のＳａａＳプラットフォーム１０２およびＰａａＳプラットフォーム１０４における１つ以上のモジュールを含んでいてもよい。さまざまなサービスのためのリソースのプロビジョニングを行うために、ＳＤＩモジュール２０６は、各々が特定のタイプのサービスのためのリソースのプロビジョニングに役立つようにカスタマイズされるさまざまな他のモジュールと対話し得る。例えば、図５に示されるように、ＳＤＩモジュール２０６は、ＪａｖａクラウドサービスをプロビジョニングするためにＪａｖａサービスプロビジョニング制御モジュール５００と対話し得る。一実施例では、Ｊａｖａサービスプロビジョニング制御コンポーネント５００は、Ｊａｖａクラウドサービスをプロビジョニングするために実行される一組のタスクを含む、ＳＤＩモジュール２０６によって規定されるＪａｖａクラウドサービス（Java Cloud Service：ＪＣＳ）アセンブリをデプロイし得る。次いで、インフラストラクチャリソース１０６は、Ｊａｖａクラウドサービスをプロビジョニングするために必要なリソースを決定する。
【００８０】
他の例として、ＳＤＩモジュール２０６は、バーチャル・アセンブリ・ビルダ（Virtual Assembly Builder：ＶＡＢ）モジュール５０２、アプリケーション・エクスプレス（Application Express：ＡＰＥＸ）デプロイヤモジュール５０４、仮想マシン（Virtual Machine：ＶＭ）モジュール５０６、ＩＤＭモジュール２００およびデータベースマシンモジュール１１８などの１つ以上のモジュールと対話し得る。ＶＡＢモジュール５０２は、完全な複数層アプリケーション環境を構成およびプロビジョニングするための機能を含む。一実施例では、ＶＡＢモジュール５０２は、ＶＭモジュール５０６によって提供されるサービスを使用してクラウドインフラストラクチャシステム１００においてミドルウェア（Middleware：ＭＷ）サービスをプロビジョニングするために、ＳＤＩモジュール２０６によって規定されるＭＷサービスアセンブリをデプロイする。ＡＰＥＸデプロイヤモジュール５０４は、データベースサービスを構成およびプロビジョニングするための機能を含む。一実施例では、ＡＰＥＸデプロイヤモジュール５０４は、インフラストラクチャリソース１０６によって提供されるリソースを使用してクラウドインフラストラクチャシステム１００においてデータベースサービスをプロビジョニングするために、ＳＤＩモジュール２０６によって規定されるデータベースサービスアセンブリをデプロイする。ＳＤＩモジュール２０６は、クラウドインフラストラクチャシステム１００において複数のアプリケーションにまたがるアクセス管理などのアイデンティティサービスを提供するためにＩＤＭモジュール２００と対話する。
【００８１】
図６は、本発明の実施例に係るＳＤＩモジュールのサブモジュールの簡略化された高レベル図を示す。図６に示される実施例では、ＳＤＩモジュール２０６は、ＳＤＩ−ウェブサービス（Web Service：ＷＳ）モジュール６００と、ＳＤＩ要求コントローラモジュール６０２と、ＳＤＩタスクマネージャモジュール６０４と、ＳＤＩモニタリングモジュール６０６と、ＳＤＩデータアクセスモジュール６０８と、ＳＤＩ共通ライブラリモジュール６１０と、ＳＤＩコネクタモジュール６１２とを含む。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。図６に示されるＳＤＩモジュール２０６およびそのさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図６に示されるものよりも多くのまたは少ないモジュールを有していてもよい。これらのモジュールおよびそれらの機能については、以下で詳細に説明する。
【００８２】
ＳＤＩ−ＷＳモジュール６００は、ＴＡＳコンポーネント２０４のビジネスプロセスエクセキュータ３１６から、オーダーに関連付けられたビジネスにおけるステップを受取るための機能を含む。一実施例では、ＳＤＩ−ＷＳモジュール６００は、ビジネスプロセスの各ステップを構文解析し、当該ステップをＳＤＩモジュール２０６によって使用される内部表現に変換する。一実施例では、オーダーに関連付けられたビジネスプロセスの各ステップは、ＳＤＩ−ＷＳモジュール６００へのＳＯＡＰ要求の形態で、ウェブサービス処理層を介して（例えば図３Ｂに示されるシステムプロビジョニングＡＰＩを介して）到着する。
【００８３】
ＳＤＩ要求コントローラモジュール６０２は、ＳＤＩモジュール２０６における内部要求処理エンジンであり、非同期要求処理、同時要求処理、同時タスク処理、オーダー要求に関連するフォールト・トレラントな回復およびプラグインサポートを実行するための機能を含む。一実施例では、ＳＤＩ要求コントローラモジュール６０２は、オーダーに関連付けられたビジネスプロセスの各ステップをＳＤＩ−ＷＳモジュール６００から受入れ、当該ステップをＳＤＩタスクマネージャモジュール６０４に提出する。
【００８４】
ＳＤＩタスクマネージャモジュール６０４は、ビジネスプロセスにおいて規定された各ステップを、特定のステップをプロビジョニングするための一連のタスクに変換する。特定のステップのための一組のタスクがプロビジョニングされると、ＳＤＩタスクマネージャモジュール６０４は、特定のステップを実現するためにプロビジョニングされたリソースの詳細を有するオーダーペイロードを含むオペレーション結果により、ＴＡＳモジュール２０４におけるビジネスプロセスエクセキュータ３１６に応答する。ＳＤＩタスクマネージャモジュール６０４は、オーダーに関連付けられた特定のビジネスプロセスの全てのステップが完了するまで、このプロセスを繰返す。
【００８５】
特定の実施例では、ＳＤＩタスクマネージャモジュール６０４は、ＳＤＩコネクタモジュール６１２のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換する。ＳＤＩコネクタモジュール６１２は、オーダー要求に関連する１つ以上のサービスをプロビジョニングするために、ＳＤＩタスクマネージャモジュール６０４によって規定されるタスクのデプロイメントに対処するための１つ以上のコネクタを含む。特定の実施例では、コネクタのうちの１つ以上は、特定のサービスタイプに特有のタスクに対処することができ、他のコネクタは、さまざまなサービスタイプにわたって共通のタスクに対処することができる。一実施例では、ＳＤＩコネクタモジュール６１２は、オーダー要求に関連するサービスおよびリソースをプロビジョニングするためにクラウドインフラストラクチャシステム１００における外部モジュール（図５に図示）のうちの１つ以上と遣り取りする一組のコネクタ（ラッパーＡＰＩ）を含む。例えば、アプリケーション・エクスプレス（ＡＰＥＸ）コネクタ６１４は、データベースサービスをプロビジョニングするために、ＡＰＥＸデプロイヤモジュール５０４と遣り取りする。ウェブセンタコネクタ６１６（Web Center Connector：ＷＣＣ）は、ウェブサービスをプロビジョニングするために、クラウドインフラストラクチャシステム１００におけるウェブセンタモジュールと遣り取りする。ウェブセンタモジュールは、ユーザエンゲージメントプラットフォームであり、クラウドインフラストラクチャシステム１００において人々と情報とのコネクティビティを与えるための機能を含む。
【００８６】
特定の実施例では、ミドルウェアアプリケーション（Middleware Application：ＭＡ）コネクタ６１８は、ミドルウェアアプリケーションサービスをプロビジョニングするために、クラウドインフラストラクチャシステム１００におけるＶＡＢモジュール５０２と遣り取りする。ＮＵＶＩＡＱコネクタ６２０は、Ｊａｖａサービスをプロビジョニングするために、ＶＡＢモジュール５０２と遣り取りする。ＩＤＭコネクタ６２２は、クラウドインフラストラクチャシステム１００においてサービスおよびリソースにサブスクライブするユーザにアイデンティティおよびアクセス管理を提供するために、ＩＤＭモジュール２００と遣り取りする。バーチャル・アセンブリ・ビルダ（ＶＡＢ）コネクタ６２４は、完全な複数層アプリケーション環境を構成およびプロビジョニングするために、クラウドインフラストラクチャシステム１００におけるＶＡＢモジュール５０２と遣り取りする。プラグインコネクタ６２６は、クラウドインフラストラクチャシステム１００におけるコンポーネントを管理およびモニタリングするために、ＥＭモジュール２０８と遣り取りする。ＨＴＴＰサーバコネクタ６２８は、クラウドインフラストラクチャシステム１００においてユーザに接続サービスを提供するために、ＰａａＳプラットフォームにおける１つ以上のウェブサーバと遣り取りする。
【００８７】
ＳＤＩモジュール２０６におけるＳＤＩモニタリングモジュール６０６は、Ｊａｖａ管理拡張（Java Management Extensions：ＪＭＸ）要求を受取るためのインバウンドインターフェースを提供する。また、ＳＤＩモニタリングモジュール６０６は、クラウドインフラストラクチャシステム１００においてアプリケーション、システムオブジェクトおよび装置を管理およびモニタリングするためのツールも提供する。ＳＤＩデータアクセスモジュール６０８は、Ｊａｖａデータベースコネクティビティ（Java Database Connectivity：ＪＤＢＣ）要求を受取るためのインバウンドインターフェースを提供する。ＳＤＩデータアクセスモジュール６０８は、クラウドインフラストラクチャシステム１００において、データアクセスをサポートし、オブジェクト関係マッピング、ｊａｖａトランザクションＡＰＩサービス、データアクセスオブジェクトおよび接続プーリングを提供する。ＳＤＩ共通ライブラリモジュール６１０は、ＳＤＩモジュール２０６におけるモジュールのための構成サポートを提供する。
【００８８】
上記の図６の実施例は、本発明の実施例に係るＳＤＩモジュールにおけるモジュールを記載している。図７Ａは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＳＤＩモジュールのモジュールによって実行され得る処理を示す簡略化されたフローチャート７００を示す。図７Ａに示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（例えばコード、命令、プログラム）、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、（例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の）メモリに格納されてもよい。図７Ａに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図７Ａに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図７Ａに示される処理は、図６に詳細に示されるＳＤＩモジュール２０６における１つ以上のモジュールによって実行され得る。
【００８９】
７０２において、サブスクリプションオーダーに関連付けられたビジネスプロセスが受取られる。一実施例では、ＳＤＩモジュール２０６におけるＳＤＩ−ＷＳモジュール６００は、サブスクリプションオーダーに関連付けられたビジネスプロセスにおける１つ以上のステップをビジネスプロセスエクセキュータ３１６から受取る。７０４において、ビジネスプロセスにおける各ステップは、サブスクリプションオーダーのためのリソースをプロビジョニングするための一連のタスクに変換される。一実施例では、ＳＤＩモジュール２０６におけるＳＤＩタスクマネージャモジュール６０４は、ＳＤＩコネクタモジュール６１２のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換する。７０６において、サブスクリプションオーダーは、一連のタスクに基づいてプロビジョニングされる。一実施例では、図６に示されるように、ＳＤＩコネクタモジュール６１２は、サブスクリプションオーダーにおけるサービスのためのリソースをプロビジョニングするために、ＳＤＩタスクマネージャモジュール６０４によって規定されるタスクのデプロイメントに対処するための１つ以上のコネクタを含む。
【００９０】
図６に関して上記したように、ＳＤＩタスクマネージャモジュール６０４は、ＳＤＩコネクタモジュール６１２のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換し、ＳＤＩコネクタモジュール６１２は、オーダー要求に関連する１つ以上のサービスをプロビジョニングするために、ＳＤＩタスクマネージャモジュール６０４によって規定されるタスクのデプロイメントに対処するための１つ以上のコネクタを含んでいてもよい。コネクタのうちの１つ以上は、特定のサービスタイプに特有のタスクに対処することができ、他のコネクタは、さまざまなサービスタイプにわたって共通のタスクに対処することができる。一実施例では、ＳＤＩコネクタモジュール６１２は、オーダー要求に関連するサービスおよびリソースをプロビジョニングするためにクラウドインフラストラクチャシステム１００における外部モジュール（図５に図示）のうちの１つ以上と遣り取りする一組のコネクタ（ラッパーＡＰＩ）を含む。例えば、ＮＵＶＩＡＱコネクタ６２０は、ＪａｖａサービスをプロビジョニングするためにＶＡＢモジュール５０２と遣り取りする。
【００９１】
図７Ｂは、本発明の実施例に係るＮｕｖｉａｑシステム７１０および他のクラウドインフラストラクチャコンポーネントとのその関係の高レベルアーキテクチャを示す簡略ブロック図を示す。図７Ｂに示されるＮｕｖｉａｑシステム７１０は、図７Ｂに示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図７Ｂに示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、Ｎｕｖｉａｑシステム７１０は、図７Ｂに示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。
【００９２】
特定の実施例では、Ｎｕｖｉａｑシステム７１０は、ＰａａＳオペレーションをオーケストレートするためのランタイムエンジンを提供するように構成され得る。Ｎｕｖｉａｑシステム７１０は、他の製品およびサービスとの統合を容易にするためにウェブサービスＡＰＩを提供し得る。また、Ｎｕｖｉａｑシステム７１０は、システムプロビジョニング、アプリケーションデプロイメントおよび関連付けられたライフサイクルオペレーションにおける複雑なワークフローのためのサポートを提供し、管理およびモニタリングソリューションと統合する。
【００９３】
図７Ｂに示される実施例では、Ｎｕｖｉａｑシステム７１０は、Ｎｕｖｉａｑプロキシ７１２と、Ｎｕｖｉａｑマネージャ７１４と、Ｎｕｖｉａｑデータベース７１６とを備える。特定の実施例では、Ｎｕｖｉａｑマネージャ７１４は、Ｎｕｖｉａｑシステム７１０へのエントリポイントを提供し、ウェブサービスＡＰＩを介してＰａａＳオペレーションへの安全なアクセスを提供する。内部では、Ｎｕｖｉａｑマネージャ７１４は、データベースにおいてシステム状態を追跡し、ワークフローエンジン上でジョブの実行を制御する。パブリッククラウドでは、Ｎｕｖｉａｑマネージャ７１４は、プロビジョニングオペレーションおよびデプロイメントオペレーションをそれぞれ駆動するために、テナントプロビジョニングシステム（ＳＤＩ２０６）およびテナントコンソールによってアクセスされ得る。
【００９４】
一実施例では、Ｎｕｖｉａｑマネージャ７１４は、内部ワークフローエンジンを介して非同期にジョブを実行する。ジョブは、所与のＰａａＳワークフローに特有のアクションのシーケンスであってもよい。アクションは、順番に実行されてもよく、任意のステップにおける障害は、結果としてジョブ全体の障害になる。多くのワークフローアクションは、ＥＭコマンドラインインターフェース（ｃｌｉ）などのワークフローに関連する外部システムに権限を委任する。一実現例では、Ｎｕｖｉａｑマネージャ７１４アプリケーションは、ファイアウォール内で実行される関連付けられたＨＴＴＰサーバ（例えばオラクルＨＴＴＰサーバまたはＯＨＳ）インスタンスを有する２ノードウェブロジッククラスタにおいてホストされ得る。
【００９５】
特定の実施例では、Ｎｕｖｉａｑプロキシ７１２は、Ｎｕｖｉａｑ  ＡＰＩへのパブリックアクセスポイントである。一実施例では、パブリックＡＰＩのみがここで公開され得る。プロキシ７１２によって受取られた要求は、Ｎｕｖｉａｑマネージャ７１４に送られ得る。一実施例では、Ｎｕｖｉａｑプロキシ７１２はファイアウォールの外側で実行される一方、マネージャ７１４はファイアウォール内で実行される。一実現例では、Ｎｕｖｉａｑプロキシ７１２アプリケーションは、ファイアウォールの外側で実行されるウェブロジッククラスタ上で実行される。
【００９６】
特定の実施例では、Ｎｕｖｉａｑデータベース７１６は、プラットフォームインスタンス、デプロイメント計画、アプリケーション、ウェブロジックドメイン、ジョブ、アラーとなどであるがこれらに限定されないさまざまなドメインエンティティを追跡する。必要に応じて、主キーがサービスデータベースと整合させられてもよい。
【００９７】
一実施例では、プラットフォームインスタンス７１８は、所与のテナントのためのウェブロジックサービスに必要な全てのリソースを含んでいてもよい。
【００９８】
Ｎｕｖｉａｑシステム７１０は、ウェブロジッククラウドサービスによって使用されるワークフローを実行するために、クラウドインフラストラクチャシステム１００のさらなるシステムに依拠し得る。これらの依存性は、ＳＤＩ２０６、ＩＤＭ２００、ウイルススキャンシステム、サービスデータベース、ＣＲＭインスタンスなどへの依存性を含んでいてもよい。例えば、Ｎｕｖｉａｑシステム７１０は、ＳＤＩ２０６におけるアセンブリデプロイヤによって実行される機能に依存し得る。一実施例では、アセンブリデプロイヤは、ＯＶＡＢ（オラクルバーチャル・アセンブリ・ビルダ）およびＯＶＭ（オラクル仮想マシン）とのインタラクションを管理するためのシステムである。Ｎｕｖｉａｑシステム７１０によって使用されるアセンブリデプロイヤの機能は、アセンブリをデプロイするための機能、アセンブリをアンデプロイするための機能、アセンブリデプロイメントを説明するための機能、アプライアンスをスケーリングするための機能などを含み得るが、これらに限定されるものではない。一実現例では、Ｎｕｖｉａｑシステム７１０は、ウェブサービスＡＰＩを介してアセンブリデプロイヤにアクセスする。
【００９９】
特定の実施例では、セキュリティポリシは、アプリケーションにデプロイされる前に特定のアーティファクトがウイルススキャンされることを必要とし得る。クラウドインフラストラクチャシステム１００は、この目的でウイルススキャンシステムを提供し得て、パブリッククラウドの複数のコンポーネントのためのサービスとしてスキャンを提供する。
【０１００】
特定の実施例では、パブリッククラウドインフラストラクチャは、テナント（例えば顧客）およびそれらのサービスサブスクリプションについての情報を含むサービスデータベースを維持し得る。Ｎｕｖｉａｑワークフローは、テナントもサブスクライブする他のサービスに対するクライアントとしてウェブロジックサービスを適切に構成するために、このデータにアクセスし得る。
【０１０１】
Ｎｕｖｉａｑシステム７１０は、そのセキュリティ統合のためにＩＤＭ２００に依存し得る。特定の実施例では、Ｊａｖａサービスインスタンスは、ＣＲＭインスタンスに関連付けられ得る。当該関連付けにより、Ｊａｖａサービスインスタンスにデプロイされたユーザアプリケーションは、ウェブサービスコールを介してＣＲＭインスタンスにアクセスできる。
【０１０２】
Ｎｕｖｉａｑシステム７１０によって提供されるサービスをさまざまなエンティティが使用し得る。Ｎｕｖｉａｑシステム７１０のこれらのクライアントは、プラットフォームインスタンス上でアプリケーションを管理するために顧客がアクセスし得る管理サーバ（例えばオラクル管理サーバ）ベースのユーザインターフェースであるテナントコンソールと、アプリケーションライフサイクル管理オペレーションへのアクセスを提供するように拡張されたオラクルＩＤＥ（JDeveloper、NetBeansおよびＯＥＰＥ）などのいくつかのＩＤＥと、プラットフォームインスタンス上のライフサイクルオペレーションにアクセスするために利用可能な１つ以上のコマンドラインインターフェース（Command Line Interface：ＣＬＩ）とを含んでいてもよい。
【０１０３】
Ｎｕｖｉａｑシステム７１０についてのプロビジョニング使用事例、すなわちプロビジョニングプラットフォームインスタンスの使用事例は、Ｎｕｖｉａｑ  ＡＰＩの作成プラットフォームインスタンスオペレーションによって実現される。クラウドインフラストラクチャシステム１００の文脈では、Ｎｕｖｉａｑシステムに対するサービスインスタンスは、Ｎｕｖｉａｑプラットフォームインスタンスに対応する。プラットフォームインスタンスは、このインスタンスに関連する全ての後続のオペレーション上で使用される独自の識別子を割り当てられる。作成プラットフォームインスタンスアクションに提供されるプラットフォームデプロイメント記述子により、テナントのサブスクリプション要件を満たすようにプラットフォームインスタンスの構成を修正するプロパティを設定することができる。これらのプロパティは、例えば以下を含んでいてもよい：
プロパティ＃１：oracle.cloud.service.weblogic.size
値：ベーシック、標準、エンタープライズ
説明：サブスクリプションタイプを規定する。これは、サーバの数、データベース限度およびサービス設定の質に影響を及ぼす。
プロパティ＃２：oracle.cloud.service.weblogic.trial
値：真、偽
説明：これがトライアルサブスクリプションであるか否かを示す。
プロパティ＃３：oracle.cloud.service.weblogic.crm
値：ＣＲＭサービスＩＤ
説明：このウェブロジックサービスインスタンスに関連付けられるべきＣＲＭサービスを特定する。
【０１０４】
図７Ｃは、本発明の実施例に係るＮｕｖｉａｑシステムを使用するプロビジョニングプロセスのステップを示す例示的なシーケンス図を示す。図７Ｃに示されるシーケンス図は、一例に過ぎず、限定的であるよう意図されるものではない。
【０１０５】
インストール／更新アプリケーションの使用事例、すなわちインストールアプリケーションオペレーションは、アプリケーションアーカイブがパブリッククラウドのセキュリティ要件を満たすことを確認した後に、実行中のウェブロジックサーバにアプリケーションをデプロイする。一実施例では、インストールアプリケーションアクションに提供されるアプリケーションデプロイメント記述子により、テナントのサブスクリプション要件を満たすようにアプリケーションの構成を修正するプロパティを設定することができる。これらのプロパティは、例えば以下を含んでいてもよい：
プロパティ：oracle.cloud.service.weblogic.state
値：実行、停止
説明：デプロイメント後のアプリケーションの初期状態を規定する。
【０１０６】
図７Ｄは、本発明の実施例に係るＮｕｖｉａｑシステムを使用するデプロイメントプロセスのステップを示す例示的なシーケンス図を示す。図７Ｄに示されるシーケンス図は、一例に過ぎず、限定的であるよう意図されるものではない。
【０１０７】
図２に戻って、特定の実施例では、協働して動作するＴＡＳ２０４およびＳＤＩ２０６は、クラウドインフラストラクチャシステム１００によって提供される一組のサービスから顧客によってオーダーされた１つ以上のサービスのためにリソースをプロビジョニングすることを担当する。例えば、一実施例では、データベースサービスをプロビジョニングするために、自動化されたプロビジョニングフローは、有料サブスクリプションについては以下のようなものであってもよい：
（１）顧客は、ストアＵＩ２１０を介して、サービスの有料サブスクリプションのオーダーを行う。
（２）ＴＡＳ２０４がサブスクリプションオーダーを受取る。
（３）サービスが利用可能であると、ＴＡＳ２０４は、ＳＤＩ２０６のサービスを使用することによってプロビジョニングを開始する。ＴＡＳ２０４は、ビジネスプロセスのオーケストレーションを実行してもよく、関連のビジネスプロセスを実行してオーダーのプロビジョニング局面を完了する。一実施例では、ＴＡＳ２０４は、プロビジョニングに関わるステップをオーケストレートして、ライフサイクルオペレーションを処理するために、ＢＰＥＬ（ビジネスプロセス実行言語：Business Process Execution Language）プロセスマネージャを使用し得る。
（４）一実施例では、データベースサービスをプロビジョニングするために、ＳＤＩ２０６は、要求を行っている顧客にスキーマを関連付けるようにＣＬＯＵＤ＿ＵＩにおけるＰＬＳＱＬ  ＡＰＩを呼出し得る。
（５）顧客へのスキーマの関連付けが成功した後、ＳＤＩはＴＡＳに知らせて、ＴＡＳは、データベースサービスが現在顧客によって使用可能な状態にあるという通知を顧客に送る。
（６）顧客は、（例えばcloud.oracle.comなどのＵＲＡＬを使用して）クラウドインフラストラクチャシステム１００にログインし、サービスを起動し得る。
【０１０８】
いくつかの実施例では、顧客は、トライアルベースでサービスにサブスクライブすることも許可されてもよい。例えば、このようなトライアルオーダーは、（例えばcloud.oracle.comを使用して）クラウドＵＩ２１２を介して受取られ得る。
【０１０９】
特定の実施例では、クラウドインフラストラクチャシステム１００は、顧客またはテナント同士の間で基本的なハードウェアおよびサービスインスタンスが共有されることを可能にする。例えば、データベースサービスは、一実施例では、図７Ｅに示されるようにプロビジョニングされ得る。図７Ｅは、複数のExadata演算ノード７３０および７３２を示し、演算ノード７３０および７３２の各々が、データベースサービスのためにプロビジョニングされたデータベースインスタンスを提供する。例えば、演算ノード７３０は、データベースサービスのためのデータベースインスタンス７３４を提供する。各々のExadata演算ノードは、複数のデータベースインスタンスを有していてもよい。
【０１１０】
特定の実施例では、各データベースインスタンスは、複数のスキーマを備えていてもよく、当該スキーマは、異なる顧客またはテナントに関連付けられてもよい。例えば、図７Ｅでは、データベースインスタンス７３４は、２つのスキーマ７３６および７３８を提供し、スキーマ７３６および７３８の各々は、それ自体のテーブルを有する。スキーマ７３６は、データベースサービスにサブスクライブする第１の顧客またはテナントに関連付けられ得て、スキーマ７３８は、データベースサービスにサブスクライブする第２の顧客またはテナントに関連付けられ得る。各テナントは、完全に切離されたスキーマを得る。各スキーマは、関連付けられたテナントについてのテーブル、ビュー、格納されたプロシージャ、トリガなどを含むデータベースオブジェクトを管理できる容器のように動作する。各スキーマは、１つの専用のテーブル領域を有し得て、各々のテーブル領域は、１つのデータファイルを有する。
【０１１１】
このように、単一のデータベースインスタンスは、複数のテナントにデータベースサービスを提供することができる。これは、基本的なハードウェアリソースの共有を可能にするだけでなく、テナント同士の間でのサービスインスタンスの共有も可能にする。
【０１１２】
特定の実施例では、このようなマルチテナンシシステムは、ＩＤＭ２００によって容易になり、これにより、各々がそれ自体の別個のアイデンティティドメインを有する複数の別個の顧客が、クラウドにおいて共有されるハードウェアおよびソフトウェアを使用することが有利に可能になる。その結果、各顧客が自身の専用のハードウェアまたはソフトウェアリソースを有する必要がなくなり、場合によっては、特定の時点で一部の顧客によって使用されていないリソースが、他の顧客によって使用可能になり、それによってそれらのリソースが無駄になることを防止する。例えば、図７Ｅに示されるように、データベースインスタンスは、各々がそれぞれのアイデンティティドメインを有する複数の顧客に供給されることができる。各々のこのようなデータベースサービスインスタンスは、多くの別個のアイデンティティドメインの中で共有される単一の物理的なマルチテナントデータベースシステムの別個の抽象化またはビューであり得るが、各々のこのようなデータベースサービスインスタンスは、各々の他のデータベースサービスインスタンスが有するものとは別個の、場合によっては異なるスキーマを有することができる。したがって、マルチテナントデータベースシステムは、顧客指定のデータベーススキーマとそれらのデータベーススキーマが関係するアイデンティティドメインとの間のマッピングを格納し得る。マルチテナントデータベースシステムは、特定のアイデンティティドメインのためのデータベースサービスインスタンスに、当該特定のアイデンティティドメインにマッピングされるスキーマを使用させ得る。
【０１１３】
また、マルチテナンシは、Ｊａｖａサービスなどの他のサービスに拡張可能である。例えば、複数の顧客は、それぞれのアイデンティティドメイン内に配置されたＪＡＶＡサービスインスタンスを有し得る。各々のこのようなアイデンティティドメインは、ハードウェアの仮想的な「スライス」と見なされることができるＪＡＶＡ仮想マシンを有し得る。一実施例では、ジョブモニタリングサービス（例えばハドソン）は、各々の別個のアイデンティティドメインがＪＡＶＡエンタープライズ版プラットフォームのそれ自体の別個の仮想的な「スライス」を有することを可能にするように、クラウドにおけるＪＡＶＡエンタープライズ版プラットフォーム（例えばオラクルウェブロジック）と組み合わせられてもよい。このようなジョブモニタリングサービスは、例えばオペレーティングシステムの時間ベースのジョブスケジューラによって実行されるソフトウェアプロジェクトまたはジョブの構築などの繰返されるジョブの実行をモニタリングし得る。このような繰返されるジョブは、ソフトウェアプロジェクトの連続的な構築および／またはテストを含んでいてもよい。さらにまたは代替的に、このような繰返されるジョブは、ジョブモニタリングサービスが実行されるマシンから離れたマシン上で実行されるオペレーティングシステム起動ジョブの実行のモニタリングを含んでいてもよい。
【０１１４】
図８は、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるＴＡＳモジュールにおける１つ以上のサブモジュールの簡略化された高レベル図を示す。図８は図２と類似しているが、サービスブループリントコンポーネント２０１が追加されている。
【０１１５】
サービスブループリントコンポーネントは、１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、当該１つ以上のコンピュータおよび／またはサーバは、汎用コンピュータ、特化サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および／もしくは組み合わせであってもよい。図８に示されるクラウドインフラストラクチャシステム１００のさまざまなコンポーネントは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図８に示されるものよりも多くのまたは少ないコンポーネントを含んでいてもよい。
【０１１６】
この実施例によれば、（５）において、ＴＡＳコンポーネント２０４は、サービスブループリントコンポーネント２０１のサービスを使用して、サブスクライブされたサービスをサポートするために、リソースのプロビジョニングをオーケストレートする。（６）において、ＴＡＳモジュール２０４は、サービスブループリントコンポーネント２０１から受取られた、プロビジョニングされたオーダーに関連する情報をサービスモジュール２０２に提供する。いくつかの実施例では、（７）において、サービスブループリントコンポーネント２０１は、顧客のサブスクリプションオーダーを実現するために必要なリソースを割り当てて構成するために、サービスモジュール２０２によって提供されるサービスも使用し得る。
【０１１７】
（８）において、サービスモジュール２０２は、オーダーの状態に関する通知をクライアント装置２２４，２２６および２２８上の顧客に送る。
【０１１８】
特定の実施例では、サービスブループリントコンポーネント２０１は、各オーダーに関連付けられたビジネスプロセスを管理し、ビジネスロジックを適用してオーダーがプロビジョニングに進むべきか否かを判断するオーケストレーションコンポーネントとして機能する。一実施例では、新たなサブスクリプションのオーダーを受取ると、サービスブループリントコンポーネント２０１は、リソースを割り当てて、当該サブスクリプションオーダーを実現するために必要なそれらのリソースを構成する。サービスブループリントコンポーネント２０１は、顧客によってオーダーされたサービスのためのリソースの割り当てを可能にする。サービスブループリントコンポーネント２０１は、クラウドインフラストラクチャシステム１００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。
【０１１９】
一実施例では、図３Ａに示される処理は、図９に詳細に示されるように、ＴＡＳコンポーネント２０４における１つ以上のコンポーネントおよびサービスブループリントコンポーネント２０１によって実行され得る。ステップ３０２，３０４，３０６および３０８の実行に関連するさらなる説明については、図９に詳細に記載されている。図９は図３Ｂと類似しているが、サービスブループリントコンポーネント２０１が追加されている。
【０１２０】
一実施例では、図９に示されるコンポーネントは、図３Ａに示されるステップ３０２〜３０８に記載されている処理を実行する。
【０１２１】
いくつかの例では、オーダーがオーダー処理システム３１０によって処理された後、ＴＡＳコンポーネント２０４およびサービスブループリントコンポーネント２０１は、ビジネスロジックを適用して、オーダーがプロビジョニングに進むべきか否かを判断する。一実施例では、サービスブループリントコンポーネント２０１は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成する。サービスブループリントコンポーネント２０１は、顧客によってオーダーされたサービスのためのリソースの割り当てを可能にする。
【０１２２】
上記のように、クラウドインフラストラクチャシステム１００は、顧客によってオーダーまたはサブスクライブされ得る１つ以上のクラウドサービスを提供することができる。一般に、各サービスは、サービスを提供するために必要な演算リソースをプロビジョニングするための関連付けられたパラメータおよびプロシージャを有する。例えば、パラメータは、サービスのさまざまなビジネス処理局面に関連し得て、当該さまざまなビジネス処理局面は、さまざまなサービス提案、サービスによって使用されるプロプライエタリクライアント情報、サービスについてのオーダー詳細、超過（すなわちサービスの過剰使用）を演算するためのプロシージャ、サービスのために使用される使用メトリック、さまざまなカスタム属性、サービスの関連付け、顧客通知テンプレート、価格決定情報、課金情報などであるが、これらに限定されるものではない。演算リソースをプロビジョニングするためのプロシージャは、物理ストレージ、物理コンポーネント、ＥＭ統合、ＩＤＭフットプリントの作成、ＵＲＬルーティング、ポッド定義、テナント配置プラグイン、テナント当たりのフットプリント作成プラグイン、モニタリング構成、アイデンティティ管理フットプリント構成、ネットワーク構成などの割り当てのためのプロシージャを含み得るが、これらに限定されるものではない。
【０１２３】
クラウドインフラストラクチャシステム１００が、サービスをオーダーする顧客からサブスクリプションオーダーを受取ると、クラウドインフラストラクチャシステム１００は、オーダーされたサービスに関連付けられたさまざまなパラメータ（例えば、オーダーされたサービスのビジネス処理局面に関連するパラメータ）に関連する情報を集めるために処理を実行し、次いで、オーダーされたサービスのためのプロビジョニングプロシージャを使用して、サービスをオーダーする。１つのクラウドサービスが別のクラウドサービスとは異なっているので、パラメータ（例えば、ビジネス処理局面に関連するパラメータ）および異なるサービスのためのプロビジョニングプロシージャは一般には非常に異なっている。サービス当たりのこの多様性のために、クラウドインフラストラクチャシステム１００がサービスプロビジョニングを自動化することが相当困難かつ複雑になる。また、これにより、それ自体の新たなパラメータおよびプロビジョニングプロシージャを有する新たなクラウドサービスをクラウドインフラストラクチャシステム１００によって提供されるサービスに追加するプロセスが、困難かつ複雑になる。
【０１２４】
特定の実施例では、クラウドインフラストラクチャシステム１００によってサービス宣言テンプレートが提供され、当該サービス宣言テンプレートは、特定のサービスのプロバイダによって「記入される」ことができ、サービス関連のパラメータ（例えばビジネスプロセス局面パラメータ）、プロビジョニング局面またはプロシージャ、および当該特定のサービスのための他の可能な局面をサービスプロバイダが宣言的に規定することを可能にする。そして、特定のサービスのための記入されたテンプレートは、特定のサービスのためのサービス宣言（また、サービスのためのサービスブループリントと称されることもある）に相当する。特定の実施例では、サービスのためのサービス宣言は、サービスのためのビジネス処理局面情報、および、サービスのためのリソースプロビジョニング局面を駆動するバイナリを備える。
【０１２５】
サービスのためのサービス宣言は、サービスプロバイダと、サービスをプロビジョニングするクラウドインフラストラクチャシステム１００との間のインターフェースを提供する。サービス宣言テンプレートスキーマは、サービスをプロビジョニングするためのプロシージャに関連するサービス関連のパラメータおよび情報をサービスプロバイダが規定することを可能にする。サービスのためのサービス宣言は、顧客のサブスクリプションオーダーに応答してサービスをプロビジョニングするためにクラウドインフラストラクチャシステム１００によって必要とされる全ての情報をクラウドインフラストラクチャシステム１００が利用できるようにする。クラウドサービスのサブスクリプションオーダーを受取ると、クラウドインフラストラクチャシステム１００は、オーダーされたサービスのためのサービス宣言にアクセスし、次いでサービス宣言からの情報を使用してサービスをプロビジョニングするように構成される。したがって、サービス宣言は、プロビジョニングインフラストラクチャを完全に宣言的なモデルに発展させるのに役立つ。
【０１２６】
一実施例では、サービス宣言テンプレートはＸＳＤ文書であり、サービス宣言はＸＭＬ文書である。別の実施例では、サービス宣言テンプレートはＸＭＬ文書である。サービス宣言テンプレートは、テナントの新たなサブスクリプションの作成、既存のサブスクリプションの解約、サブスクリプションの変更などのサービスについてのさまざまなプロビジョニングライフサイクルオペレーションのための実行フローをクラウドサービスのプロバイダが宣言的に規定することを可能にするための特定のスキーマを提供する。
【０１２７】
サービス宣言テンプレートは、クラウドインフラストラクチャシステム１００自体によって提供される「内部」クラウドサービス、または、クラウドインフラストラクチャシステム１００を介してサードパーティサービスプロバイダによって（例えばアプリケーションストアを介して）提供される「外部」クラウドサービスのために使用され得る。例えば、サービスプロバイダが、クラウドインフラストラクチャシステム１００によって提供されるサービスに新たなクラウドサービスを追加したい場合、サービスプロバイダは、サービス宣言テンプレートに記入することによって新たなサービスのためのサービス宣言を作成する。次いで、サービス宣言がクラウドインフラストラクチャシステム１００に提供され、クラウドインフラストラクチャシステム１００は次いで、サービス宣言を使用してサービスを顧客に提供し、新たなサービスがサブスクリプションオーダーによってオーダーされるとプロビジョニング関連の処理を実行する。
【０１２８】
サービス宣言は、新たなサービスをクラウドインフラストラクチャシステム１００のサービス提案に追加するための容易かつ柔軟な方法を提供する。新たなサービスは、動的な態様でクラウドインフラストラクチャシステム１００に追加され、クラウドインフラストラクチャシステム１００のサービス提案に反映されることができる。
【０１２９】
さらに、サービス宣言は、クラウドインフラストラクチャシステム１００のコンポーネント（例えばＴＡＳ、ＳＤＩ、ＥＭ、ＩＤＭ、ＵＲＬルーティング）が、当該コンポーネントに必要とされるいかなるコード変更もなしに、クラウドインフラストラクチャシステム１００に追加される新たなサービスをサポートできるようにすることを可能にする。いくつかの例では、インフラストラクチャコンポーネントは全て、宣言型モデルに基づき得て、いかなるサービス特有のカスタムコードも有することはできない。
【０１３０】
例えば、サービスのためのサービス宣言において規定されるＸＭＬベースのプロビジョニングプロシージャは、ＴＡＳビジネス処理およびマルチテナントポッドプロビジョニングを含んでいてもよい。ＴＡＳビジネス処理は、サービス提案、カスタム属性、メトリック、超過、関連付けおよび通知テンプレートを含んでいてもよい。マルチテナントポッドプロビジョニングの例としては、物理的フットプリント定義、関連のポッド情報（例えばサービスタイプ当たりのポッド、ポッドにおけるインスタンス、ポッドの物理的レイアウト）を追跡するための永続的なスキーマ、およびテナント当たりのサービスプロビジョニングが挙げられ得る。さらに、テナント当たりのサービスプロビジョニングは、プロビジョニング中に実行されるタスク（例えばＩＤＭフットプリント、ＥＭターゲットの作成、ＵＲＬルーティング、サービスに特有のプラグインの呼出し）、任意のテナント当たりの物理的フットプリント、およびサービスインスタンスフットプリントを追跡するための永続的なスキーマ、およびｉｄドメイン情報を含んでいてもよい。
【０１３１】
特定の実施例では、サービス宣言に関連する処理は、サービスブループリントコンポーネント２０１によって実行される。サービスブループリントコンポーネント２０１は、サービスプロバイダがサービス宣言テンプレートにアクセスして、サービス宣言を送信することを可能にするように構成され得る。一実施例では、サービスブループリントコンポーネント２０１は、ＳＤＩコンポーネント２０６の役割を担い、ＳＤＩコンポーネント２０６に取って代わることができる。いくつかの他の実施例では、サービスブループリントコンポーネント２０１は、ＳＤＩコンポーネント２０６とともにプロビジョニングを実行し得る。
【０１３２】
特定の実施例では、クラウドインフラストラクチャシステム１００によって提供されるサービスは、サービスカタログにリストアップされる。サービスがサービスカタログを介して顧客に提供され得る前に、サービスはまずクラウドインフラストラクチャシステム１００に登録されなければならない。新たなサービスの登録の一部として、サービスをいかにプロビジョニングすべきかについての全ての局面を取込むサービス宣言がサービスに提供され得る。例えば、ＸＭＬサービス宣言が提供されてもよい。
【０１３３】
例えば、サービスプロバイダが新たなデータベースサービスを登録し得る。当該新たなサービスのためのサービス宣言は、データベースサービスに関連するさまざまなパラメータおよびプロビジョニングプロシージャを規定し得る。パラメータは、さまざまなサービスレベル、サービスに関連するメトリックなどを特定し得る。例えば、パラメータは、サービスをプロビジョニングするためにサービス名、パスワードなどの特定の顧客関連情報が必要とされ得ることを示し得る。したがって、サービス宣言におけるビジネス要件関連のパラメータは、データベースサービスを得るために必要とされる情報を特定し得る。また、サービス宣言は、サービスをプロビジョニングするために使用されるプロシージャを特定する情報を備えていてもよい。プロビジョニングの際、クラウドインフラストラクチャシステム１００は、サービスをプロビジョニングするために（例えばＢＰＥＬベースのオーケストレータを介して）バックエンドオーケストレーションを実行し得る。また、サービス宣言は、データベースサービスのためのプロビジョニング要件が、要求される仮想マシン（ＶＭ）の数、ＶＭ上で必要とされるスクリプト、データベースサービスと他のサービスとの間の必要なインターフェースなどについての情報を含むことを規定し得る。いくつかの例では、プロビジョニングは、ＡＰＩを使用してなされることができる。
【０１３４】
サービスがクラウドインフラストラクチャシステム１００に登録されると、当該サービスはサービスカタログに追加され、顧客に提供されて、例えばクラウドＵＩを介してオーダーされる。サービスカタログに入ると、サービスは直ちにオーダー可能になり、クラウドにデプロイ可能になる。
【０１３５】
例えば、クラウドインフラストラクチャシステム１００は、ウェブサービス、Ｊａｖａサービス、データベースサービスなどを提供し得る。これまで、データベースサービス開発者は、クラウド上で利用可能であるようにデータベースサービスを登録してきたかもしれない。要求されるパラメータをブループリントにおいて提供することによって、開発者は、ブループリントにおけるデータベースサービスを定義し、データベースを登録することができる。その結果、データベースサービスは、クラウドＵＩからの顧客のオーダーに利用可能になり得る。
【０１３６】
したがって、サービス宣言は、クラウドサービスを追加して、クラウドインフラストラクチャシステム１００を介してそれらを利用可能にするための拡張可能なモデルを提供する。いかなる新たなサービスもサービス宣言を使用して登録することができる。当該サービスがオーダー可能になると、サービスは、サービス宣言を使用してクラウドインフラストラクチャシステム１００によってプロビジョニングされ得る。サービス宣言は、新たなオーダーのために各サービスを拡張可能にすることによってサービスのプロビジョニングを自動化するのに役立つ。例えば、顧客は、クラウドインフラストラクチャシステム１００によって提供されるクラウドサービスをオーダーし得る。要求されたサービスのためのサービス宣言は、サービス関連のビジネスプロセス局面およびプロビジョニングプロシージャが後に続くことを保証することを含む、サービスをプロビジョニングするために使用されるものを提供する。
【０１３７】
特定の実施例では、サービスブループリントコンポーネント２０１は、サービスプロバイダがサービス宣言テンプレートを埋めることを可能にするインターフェースを提供し得る。例えば、サービスプロバイダは、記入されるべきＸＭＬフォーマットのテンプレートを提供され得る。テンプレートのスキーマは、テンプレートが複数のサービスで使用できるようにサービス関連のパラメータを一般化する。
【０１３８】
特定の実施例では、サービス宣言は、サービスをプロビジョニングする際に可能なさまざまなオペレーションを全て取込むことができる。例えば、サービスのためのサービス宣言は、サービスのためのオンボーディングオペレーションがサービスのインスタンスの作成を含み、特定のパラメータ（例えば、サービスがスケールアウトする必要がある場合、ユーザ要件）を規定する必要があることを示す情報を提供し得る。また、サービス宣言は、今日は５０人のユーザのためにサービスがオーダーされるが将来的には５０００人のユーザにまで増大する可能性がある場合などにサービスをスケーリングするためのプロシージャを特定し得る。サービスプロビジョニングの一部として、ＴＡＳコンポーネント２０４は、オンボーディングおよびスケールアップ機能を自動的に実行するために、サービスのためのサービス宣言からの情報を使用し得る。
【０１３９】
図１０は、本発明の実施例に係るサービスブループリントコンポーネントの簡略化された高レベル図を示す。図１０に示されるように、サービスブループリントコンポーネント２０１は、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよいさまざまなコンポーネントを含む。図１０に示されるサービスブループリントコンポーネント２０１およびそのさまざまなコンポーネントは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図６に示されるものよりも多くのまたは少ないコンポーネントを有していてもよい。これらのコンポーネントおよびそれらの機能については、以下で詳細に説明する。
【０１４０】
図１０に示されるように、サービス宣言テンプレートに関連する情報および１つ以上の登録されたサービスのためのサービス宣言がブループリントデータベース６６８に格納され得る。データベース６６８は、要求／応答スキーマ６７０、ポッドスキーマ６７２、ブループリントレジストリ６７４およびサービスインスタンススキーマ６７６を格納し得る。
【０１４１】
図１０に示される実施例では、サービスブループリントコンポーネント２０１は、ＴＡＳコンポーネント２０４およびＤｅｖＯｐｓ（開発およびオペレーションインフラストラクチャ）と遣り取りする。ＴＡＳ２０４は、サービスブループリント２０１と対話するためにサービスプロバイダＡＰＩ６５２を使用し得る。ＤｅｖＯｐｓは、サービスブループリントコンポーネント２０１と対話するためにポッド管理ＡＰＩ６５４を使用し得る。サービスプロビジョニングＡＰＩ６５２およびポッド管理ＡＰＩ６５４は、オーダーに関連付けられたビジネスプロセスに関連する情報をＴＡＳコンポーネント２０４のビジネスプロセスエクセキュータ３１６から受取るための機能を含む。一実施例では、サービスプロビジョニングＡＰＩ６５２およびポッド管理ＡＰＩ６５４は、ビジネスプロセスの各ステップを構文解析して、ステップをサービスブループリントコンポーネント２０１によって使用される内部表現に変換し得る。この内部表現は、サービス宣言におけるスキーマ表現に基づき得る。一実施例では、オーダーに関連付けられたビジネスプロセスの各ステップは、サービスプロビジョニングＡＰＩ６５２およびポッド管理ＡＰＩ６５４へのＳＯＡＰ要求の形態で、ウェブサービス処理層を介して（例えば図９に示されるＴＡＳ  ＡＰＩ３１８を介して）到着する。
【０１４２】
いくつかの例では、サービスプロビジョニングＡＰＩ６５２およびポッド管理ＡＰＩ６５４は、共通のＡＰＩを介して提供されることができる。しかし、特定の実施例では、ポッド作成対サービスインストール作成のための異なるポッドインスタンスが存在し得る。サービスプロビジョニングＡＰＩ６５２は、顧客の要求に基づいてサービスインスタンスを起動し得る。ポッド管理ＡＰＩ６５４は、ポッド作成を起動し得る。
【０１４３】
ポッド管理ＡＰＩ６５４は、単一の物理的デプロイメントがクラウド上の多数のテナントをサポートするマルチテナントサービスの作成において使用可能である。いくつかの例では、ポッド管理ＡＰＩ６５４下のポッドが予め作成され、顧客のオーダーが入ってくると使用可能になる。例えば、メッセージングサービスでは、１０００のテナントを供給することができるメッセージングポッドが顧客の要求なしに作成可能である。したがって、顧客の要求が入ってくると、メッセージングポッドは使用できる状態になり得る。
【０１４４】
特定の実施例では、サービスＡＰＩ６５２またはポッド管理ＡＰＩ６５４を使用してＴＡＳ２０４またはＤｅｖＯｐｓから受取られた要求は、サービスブループリント２０１によって提供される１つ以上の入力キューに並べられ得る。例えば、ＴＡＳ２０４から受取られた要求（または代替的には、構文解析されたビジネスプロセスにおけるステップ）が、キュー６５６に並べられ得る。例えば、顧客によってオーダーされた特定のサービスをプロビジョニングするためにサービス要求がＴＡＳ２０４から受取られ得る。ＴＡＳ２０４は、サービスのプロビジョニングを実行するためにサービスブループリントコンポーネント２０１を使用し得る。その趣旨の要求は、ＴＡＳ２０４からサービスブループリント２０１によって受取られ、入力要求キュー６５６に並べられ得る。要求プロセッサ６５８は、キューに並べられた要求をピックアップして、各要求をオーケストレータ６６０に提供するように構成され得る。ポッド管理ＡＰＩ６５４を介して受取られた要求は、対応する入力キューに並べられ得て、ポッド管理６５４に対応する要求プロセッサは、当該キューから要求をピックアップして、それをオーケストレータ６６０に提供して実現するように構成され得る。
【０１４５】
要求キュー６５６および要求プロセッサ６５８は、サービスブループリントコンポーネント２０１における内部要求処理エンジンの役割を果たし、非同期要求処理、同時要求処理、同時タスク処理、オーダー要求に関連するフォールトトレラントな評価および回復およびプラグインサポートを実行するための機能を含んでいてもよい。一実施例では、要求キュー６５６および要求プロセッサ６５８は、オーダーに関連付けられたビジネスプロセスの各ステップをサービスプロビジョニングＡＰＩ６５２および／またはポッド管理ＡＰＩ６５４から受入れ、ステップをオーケストレータ６６０に送信し得る。
【０１４６】
要求プロセッサは、入ってくる要求の状態ライフサイクルを管理しながらこれらの入ってくる要求をキューに格納することによって信頼性のある非同期メッセージ処理を可能にする一般的なコンポーネントであり得る。例えば、要求プロセッサは、ＪＭＳキューにおいて要求のキューを維持し、要求テーブルにおいてもこれらの要求を維持する。これらの要求のライフサイクルを制御することによって、要求プロセッサは、スケールアウトデプロイメントをサポートしながらこれらの要求の信頼性のある処理を保証する。
【０１４７】
特定の実施例では、要求キューにおける要求をモニタリングして要求を処理するポーリングスレッドであってもよい要求ポーラが提供され得る。いくつかの例では、あらゆるオーケストレーションエンジンインスタンスが、要求ポーラのプールを有し得る。
【０１４８】
特定の実施例では、サービスプロビジョニングＡＰＩ６５２またはポッド管理ＡＰＩ６５４のいずれかに要求が入ってくることができ、当該要求は、その発生元に基づいて異なる要求キュー６５６に入ることができる。要求プロセッサ６５８は、処理のための要求をオーケストレータ６６０に送ることによって、要求をピックアップし得る。
【０１４９】
オーケストレータ６６０は、要求プロセッサから受取られた要求を実行するように構成される。特定の実施例では、オーケストレータ６６０は、ＢＰＥＬ（ビジネスプロセス実行言語）に基づき得る。ＢＰＥＬオーケストレータ６６０は、要求が関連するサービスを判断し、要求サービスのためのサービス宣言に基づいて要求を実行するように構成される。
【０１５０】
一実施例では、オーケストレーションエンジン６６０は、以下のコンポーネント、すなわち、オーケストレーションエンジンエンドポイント、要求プロセッサ、要求ポーラおよびＢＰＥＬベースの要求処理エンジンを含んでいてもよい。オーケストレーションエンジン６６０は、２つのエンドポイント、すなわち（ａ）ビジネスオーケストレーション層が（例えば作成、削除、関連付け、アーカイブなどのオペレーションのために）サービスをプロビジョニングおよび管理することを可能にするためのサービスプロビジョニングエンドポイント、および、（ｂ）（例えばキャンセル要求、中断要求などのオペレーションのために）オーケストレーションエンジンサービス自体を管理するための管理エンドポイントを公開し得る。サービスプロビジョニングのための要求は、非同期要求であり得て、要求プロセッサによって並べられる。既存のビジネスオーケストレーション層（ＴＡＳ）との適合性を維持するために、オーケストレーションエンジンは、既存のＳＤＩと同一のウェブサービスを公開し得る。
【０１５１】
特定の実施例では、オーケストレータ６６０は、ブループリントデータベース６６８に格納されたサービス宣言情報にアクセスして、ＴＡＳ２０４から受取られた要求を実現するために実行されるべき一連のタスクを当該サービス宣言から決定するように構成され得る。例えば、一実施例では、ＢＰＥＬベースの要求処理エンジンは、要求をオーダーして、要求をＢＰＥＬオーケストレータ６６０に送信し得る。ＢＰＥＬオーケストレータ６６０のプロセスは、サービスブループリントエンドポイントからサービス宣言サービスブループリントをフェッチし、サービスｉｄのための実行テンプレートを抽出し、テンプレートに規定されたタスクを実行するためにタスクエクセキュータサービスエンドポイントを非同期的に呼出すように構成される。
【０１５２】
別の実施例では、オーケストレータ６６０は、サービスのためのサービス宣言に格納された情報をブループリントパーサ６６２を介して受取り得る。ＢＰＥＬベースのオーケストレータ６６０は、特定のサービスについてＴＡＳ２０４から受取られた要求を実現するために実行されるべきタスクを要求するメッセージをパーサ６６２に送り得る。
【０１５３】
一実施例では、ブループリントパーサ６６２は、プロビジョニングされるサービスのためのサービス宣言にブループリントデータベース６６８からアクセスし、サービス宣言における情報に基づいて、プロビジョニング要求を実現するために実行されるべき一連のタスクを決定するように構成される。一実施例では、パーサ６６２は、サービス宣言に規定されたビジネスプロセスを特定し得て、当該プロセスに規定された各ステップを、特定のステップをプロビジョニングするための一連のタスクに変換し得る。また、ブループリントパーサ６６２は、タスク実行テンプレートの形態でタスクのリストをオーケストレータ６６０に送り得て、当該タスク実行テンプレートは、（例えばＸＭＬ  ｄｏｃのような）ＸＭＬベースであり得て、スキーマを有し得る。一実施例では、タスク実行テンプレートは、プロビジョニングされるサービスのためのサービス宣言に規定され得る。
【０１５４】
特定の実施例では、プロビジョニングオペレーションは、タスク実行のシーケンスであってもよい。当該オペレーションは、決まった一組のアクションを定義するシードタスク実行テンプレートによってＯＯＴＢで駆動される。サービスのためのテンプレートは、サービスのためのサービス宣言に定義され得て、特定のタスクおよびこれらのタスクが実行される必要があるオーダーを特定し得る。ライフサイクルオペレーションに応じて、サービスをプロビジョニングするために一組の標準的なタスクが実行されてもよい。さらに、サービスは、サービス自体によって最良に処理される特定のタスクを実行するためにプラグインを提供する必要があり得る。プラグインは、オーケストレーションエンジン６６０によってブラックボックスとして扱われる。サービスプロビジョニングプラグインのセクションに記載されるように、サービスは、タスク実行テンプレート全体を無効にするか、または、実行フローにおける制御されたポイントにおいて実行されるカスタムタスクを提供し得る。タスク実行テンプレートは、下記のタスクおよびタスクエクセキュータモデルを活用し得る。
【０１５５】
特定の実施例では、サービスについての所与のプロビジョニングライフサイクルオペレーションのためのフロー全体は、タスク実行のシーケンスとして実行されることができる。アクションのシーケンスは、サービスのためのサービス宣言におけるサービスのためのタスク実行テンプレートに取込まれ得る。図１１に示されるように、オーケストレーションエンジンは、サービス宣言に定義されたいかなるサービス特有のタスクとも交互配置される一組のサービスに依存しないタスク（例えば「ＩＤＭフットプリントの作成」タスク）を整理する。一実施例によれば、タスクは、タスクエクセキュータサービスを呼出すことによってシーケンシャルに実行可能である。
【０１５６】
特定の実施例では、特定のステップのための一組のタスクがプロビジョニングされると、ブループリントパーサ６６２は、特定のステップを実現するためにプロビジョニングされたリソースの詳細を有するオーダーペイロードを含むオペレーション結果により、ＴＡＳコンポーネント２０４におけるビジネスプロセスエクセキュータ３１６に応答する。
【０１５７】
ＢＰＥＬベースのオーケストレータ６６０は、パーサ６６２から受取られたタスク実行におけるタスクを実行するように構成される。タスク実行フレームワークは、同期または非同期の態様でタスクを実行するための機構を提供し得る。例えば、図１１に示されるように、タスク実行フレームワークは、タスクの同期実行のための同期タスクエクセキュータと、タスクの非同期実行のための非同期タスクエクセキュータとを含んでいてもよい。
【０１５８】
特定の実施例では、タスク実行フレームワークは、タスクを実行するために他のモジュールによって全面的に使用される共通のコンポーネントであってもよい。例えば、所与のサービスのための各々のプロビジョニングライフサイクルオペレーションごとに、タスク実行テンプレートは、実行される必要がある一組のタスクを封入し得る。テンプレートは、タスク実行サービスを使用してオーケストレーションエンジン６６０によって実行され得る。このテンプレートは、関連付けられたタスクエクセキュータによりタスクのシーケンスとしてモデル化され得る。
【０１５９】
いくつかの実施例によれば、同期タスクエクセキュータ６６４および／または非同期タスクエクセキュータ６６６は、サービスを作成するために実行されるべきタスクを特定するＸＭＬ文書を取得し得る。ＸＭＬを構文解析することによって、タスクエクセキュータは、サービスを作成するためにアクションのシーケンスを実行し得る。いくつかの例では、アクションのシーケンスは、シーケンシャルになされてもよい。他の例では、イベントのシーケンスは、順番にまたはばらばらになされてもよい。
【０１６０】
非同期タスクでは、アクション自体がポーリングをサポートし得る。したがって、非同期タスクエクセキュータ６６６は、アクションをディスパッチして、アクションがなされるまでポーリングし続けることができる。代替的に、アクションはコールバック可能であってもよい。例えば、ＢＰＥＬベースのオーケストレータ６６０は、アクションをディスパッチして、次いで非同期タスクエクセキュータ６６６のためのコールバックポイントを送ってコールバックし得る。
【０１６１】
タスク実行フレームワークは、同期または非同期タスク実行要求を受入れるファサードサービスと、一組のタスクエクセキュータと、タスクを実行するためのリソースのライブラリとを含んでいてもよい。タスクを受取ると、サービスは、システムおよびサービスプロパティのバッグを有する、タスクに規定されたタスクエクセキュータを呼出し得る。完了後、サービスは、一組の予め規定された{キー，値}の対を返し、当該対は呼出し元によって次のタスクに伝えられ得る。
【０１６２】
特定の実施例では、図１２に示されるように、タスク実行フレームワークは、タスクと、タスクエクセキュータと、タスク実行テンプレートと、タスクエクセキュータサービスとを含んでいてもよい。一実施例では、タスクは、ワークのユニットを封入し得る。タスクは、固有の名前、および、タスクが封入するワークのユニットを行うことを担当するエクセキュータへの参照を含んでいてもよい。このモデルにより、サービスが当該特定のタスクのためのエクセキュータを定義することによって必要なプラグインを提供することができるようになる。例えば、ＩＤＭにおいてシステムフットプリントを作成するためのタスクは、ＯＯＴＢ実行テンプレートによって決定される実行シーケンスにおけるポイントにおいてCreateSystemInIDMExecutorを実行することによって実行可能である。
【０１６３】
特定の実施例では、タスクエクセキュータは、タスクを実行するために呼出される必要がある実行可能ファイルを封入し得る。タスクエクセキュータ定義は、固有の名前と、内蔵型エクセキュータタイプと、エクセキュータタイプに基づいて解釈可能な位置パラメータとを含んでいてもよい。また、当該定義は、実行後に{キー，値}の対として返される任意の出力パラメータも規定し得る。
【０１６４】
図１２に示されるように、エクセキュータタイプは、Ｊａｖａ、ウェブサービスおよびシェルスクリプトなどであるがこれらに限定されない予め規定されたタイプであってもよい。Ｊａｖａタイプでは、エクセキュータは、実行時にＪａｖａライブラリに対して呼出しを行い得る。位置パラメータは、ClassName#MethodNameの形態であり得る。オブジェクトを構築して方法を呼出すためにリフレクションが使用可能である。呼出される方法は、単一の要求パラメータを受入れて、応答オブジェクトを返し得る。ウェブサービスタイプでは、エクセキュータは、サービスによって供給されるウェブサービスエンドポイントに対して呼出しを行い得る。シェルスクリプトタイプでは、エクセキュータは、シェルスクリプトを実行し得る。
【０１６５】
タスクエクセキュータによって使用されるリソースは、例えばｊａｒファイル、ｗａｒファイルおよびシェルスクリプトであってもよい。
【０１６６】
図１２は、一実施例に係る実行フローを示す。タスクエクセキュータサービスへの各要求は、タスクエクセキュータを規定するタスクと、各サービスごとに１つの、複数の要求項目を有する要求バッグと、処理される要求項目のインデックスとを封入し得る。要求は、全ての要求項目に共通の、システムに特有のプロパティを含み、要求項目は、サービスに特有のプロパティを含む。タスクエクセキュータは、システムプロパティおよびサービスプロパティを受け渡すことによって規定されるタスクを実行し得る。
【０１６７】
タスク実行フレームワークからの応答は、オーケストレータ６６０に提供され得る。当該応答は、サービスブループリントコンポーネント２０１によって提供される１つ以上の出力キューに並べられ得る。１つ以上の応答プロセッサは、出力キューから応答を選択して、ＡＰＩ６５２または６５４を使用して応答を要求発生元に戻すように構成され得る。
【０１６８】
特定の実施例では、物理的プロビジョニングのためのブループリントデータベース６６８は、サービスの物理的フットプリントを定義するためのポッド定義スキーマ（例えばポッドスキーマ６７２）と、サービスに特有のプラグインを取込むためのサービス定義スキーマ（例えば要求／応答スキーマ６７０）と、ＥＭ、ＩＤＭ、ＵＲＬルーティングおよび他のサービスに特有の構成を取込むためのサービス構成スキーマ（例えばサービスインスタンススキーマ）とを含んでいてもよい。ビジネス処理ブループリントの下では、ブループリントデータベース６６８は、ブループリントレジストリ６７４も含んでいてもよい。さらに、ブループリントデータベース６６８は、要求応答、状態変化および移行に関する情報を含んでいてもよい。例えば、ポッドが作成されると、ポッドの定義全体がブループリントデータベース６６８に格納され得る。
【０１６９】
図１２に関連して上記したように、オーケストレータ６６０は、タスクを実行するためにタスク実行フレームワークのサービスを使用し得る。このタスク実行フレームワークは、非同期の態様でタスクを実行するように構成された非同期タスクエクセキュータ６６６を含んでいてもよい。図１３は、本発明の実施例に係る非同期的なタスクの実行に関わる処理の一例を示す。この例では、特定のタスクは、サービスのためのＶＭの作成であってもよい。
【０１７０】
７５１において、ＢＰＥＬベースのオーケストレータ６６０から入ってくる要求が非同期タスクエクセキュータ６６６によって受取られる。例えば、ＢＰＥＬベースのオーケストレータ６６０は、ＶＭ作成タスクのために非同期タスクエクセキュータ６６６を呼出し得る。
【０１７１】
７５２において、非同期タスクエクセキュータ６６６は、当該要求を要求／応答スキーマ６７０に格納し、要求／応答スキーマ６７０からＢＰＥＬコールバックＵＲＬを要求し得る。例えば、ＶＭ作成タスクはコールバック作成タスクであり得るため、非同期タスクエクセキュータ６６６は、ＶＭを作成するためのプラグインを呼出すことができる。
【０１７２】
７５３において、ＶＭクリエータは、サーバを作成するためにオープンスタックＲＥＳＴ  ＡＰＩを使用し得る。７５４において、オープンスタックＲＥＳＴ  ＡＰＩは、ポーリングＵＲＬをＶＭクリエータに返し得る。７５５において、ポーリングＵＲＬは、データベースに格納され得る。７５６において、非同期タスクエクセキュータ６６６は、ポーリングＵＲＬを入手し得る。
【０１７３】
７５７において、非同期タスクエクセキュータ６６６は、ＶＭ作成状態についてオープンスタックＲＥＳＴ  ＡＰＩに対してポーリングし得る。７５８において、非同期タスクエクセキュータ６６６は、応答をブループリントデータベース６６８に格納し得る。７５９において、非同期タスクエクセキュータ６６６は、ＢＰＥＬコールバックＵＲＬ上でＢＰＥＬベースのオーケストレータ６７０に応答を書込み得る。
【０１７４】
上記の図１２および図１３は、本発明の実施例を組込むことができるサービスブループリントコンポーネントにおけるコンポーネントを示している。
【０１７５】
図１４および図１５は、本発明の実施例に従って実行され得るサービス宣言関連の処理を示す簡略化されたフローチャートを示す。図１４に示される処理８００および図１５に示される処理９００は、１つ以上のプロセッサによって実行されるソフトウェア（例えばコード、命令、プログラム）、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、（例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の）メモリに格納されてもよい。図１４および図１５に示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図１４および図１５に示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図１４および図１５に示される処理は、図１０に詳細に示されるサービスブループリントコンポーネント２０１における１つ以上のコンポーネントによって実行され得る。
【０１７６】
図１４は、いくつかの実施例に係る、サービスを利用可能にするための処理を示す。
８０２において、クラウドインフラストラクチャシステム１００は、新たなクラウドサービスを登録するための要求を受取る。８０４において、クラウドインフラストラクチャシステム１００は、新たなサービスのためのサービス宣言を受取る。８０６において、サービス宣言がクラウドインフラストラクチャシステム１００によって格納され、サービスが登録される。８０８において、登録されたサービスがサービスカタログに追加され、顧客によるオーダー発注に利用可能になる。
【０１７７】
例えば、開発者は、特定のサービスのためのサービス宣言を提供することによって、当該特定のサービスをサービスカタログに登録し得る。いくつかの例では、サービスは、そのプロビジョニングの全ての局面を取込むサービスブループリント（例えばＸＭＬスキーマ）に適合するＸＭＬ文書を供給することによってサービスカタログに登録され得る。サービスがサービスカタログに登録されると、当該サービスは直ちにオーダー可能になり、クラウドにデプロイ可能になり得て、それによって、サービスがクラウドにおいて利用可能になるための拡張可能なモデルが提供される。
【０１７８】
図１５は、いくつかの実施例に係る、サブスクリプションオーダーを得ると実行される処理を示す。
【０１７９】
９０２において、サービスブループリントコンポーネント２０１は、顧客によってオーダーされたサービスを特定するサブスクリプションオーダー情報を受取り得る。９０４において、サービスブループリントコンポーネント２０１は、要求されたサービスに対応するサービス宣言を特定し得る。９０６において、サービスブループリントコンポーネントは、９０４において特定されたサービスのためのサービス宣言における情報に従って、要求されたサービスをプロビジョニングし得る。
【０１８０】
例えば、サービスカタログは、顧客によってオーダー可能な登録されたサービスのメニュを含む。いくつかの例では、顧客は、サービスカタログから新たなサービスを要求（例えばオーダー）し得る。さらに、一実施例によれば、顧客がサービスを要求するようにするためにサービス開発者が顧客から必要とし得る特定の要件がある。サービスブループリントコンポーネント２０１は、要求されたサービスに対応するサービス宣言に基づいて、要求されたサービスをプロビジョニングし得る。
【０１８１】
上記のように、サービスのためのサービス宣言は、リソースのプロビジョニングを自動化してサービスを可能化するためにサービスブループリントコンポーネントによって使用されるさまざまな情報を備えていてもよい。特定の実施例では、サービスのためのサービス宣言は、以下に関連する情報を備える：
（１）サービスのためのビジネス処理局面
（２）サービスの物理的プロビジョニング、および
（３）ポッドプロビジョニング。
【０１８２】
（１）ビジネス処理局面情報
特定の実施例では、サービス宣言におけるビジネス処理局面情報は、サービスのビジネスレベル属性に関連する情報を特定し得て、当該情報は、サービスカタログ登録情報、カスタム属性情報、関連付け情報、サービスランタイム情報（例えばメトリック、計画的な停電）、購買情報、超過情報などに関連する情報を含むが、これらに限定されるものではない。これらのうちのいくつかについて、以下で説明する。
【０１８３】
（ａ）サービスカタログ登録情報
クラウドインフラストラクチャシステム１００のためのサービスカタログは、各サービスが提供し得る全てのオプションを含む、クラウドインフラストラクチャシステム１００によって提供される全てのサービスを特定する。（例えばブループリントレジストリ６２４として格納された）サービスのためのサービス宣言におけるサービスカタログ情報は、特定のサービスと、サービスのためのサービスカタログにおいて使用され、サービスカタログに取込まれるさまざまなサービス関連の情報とを特定する。例えば、サービスのためのサービス宣言は、サービス詳細（例えばさまざまなサービスコンポーネント）、サービス構成、サービスのためのトライアル構成などの情報を備えていてもよい。
【０１８４】
例えば、サービス詳細は、サービスについての詳細（例えば名前、表示名、説明、マーケティング資料）を特定し得る。この情報は、新たなオーダー可能なサービスを動的に反映するためにクラウドインフラストラクチャシステム１００によって消費され得る。サービス構成情報は、ベーシック、標準およびエンタープライズなどのさまざまなサポートされた構成を特定し得る。サービスによってサポートされたさまざまな構成は、ＴＡＳに登録され、これは、サービス宣言において<serviceCatalog>要素を使用することによりなされ得る。この構成のための（クラウドインフラストラクチャシステム１００による通知において使用される）簡単な説明および表示名も提供され得る。サービス宣言におけるトライアル構成要素情報は、サービス関連のトライアルの局面を制御するためにサービスプロバイダによって使用可能であり、トライアル期間、過少利用構成および延長などの情報を含んでいてもよい。過少利用構成局面は、利用確認に使用されるメトリックと、過少利用警告通知で使用される期間とを含んでいてもよい。延長局面は、延長が許可されるか否か、許可される延長の数、延長の期間、および延長に関係する他の関連情報を判断し得る。
【０１８５】
（ｂ）カスタム属性情報
いくつかの実施例によれば、クラウドインフラストラクチャシステム１００に登録されたあらゆるサービスは、一組のカスタム属性を規定し得て、当該一組のカスタム属性の値は、顧客がサービスを購入またはオーダーすると顧客によって提供されなければならない。例えば、ＣＲＭおよびＨＣＭサービスは、顧客の企業名、言語パック、企業の住所などのサービス関連の属性の値が、サービスをオーダーする顧客によって供給されることを必要とする。サービスのためのサービス宣言におけるカスタム属性情報は、これらのカスタム属性を特定する。一実施例では、属性は、ＴＡＳに格納され得て、クラウドインフラストラクチャシステム１００ポータルが、モデル駆動のユーザインターフェースを使用して、サービスに特有のＵＩを顧客に提供することを可能にし得る。ＵＩに収集された属性値は全て、ＴＡＳを介して物理的プロビジョニングインフラストラクチャ（例えばサービスブループリントコンポーネントまたはＳＤＩ）に伝えられ得る。
【０１８６】
（ｃ）関連付け情報
クラウドインフラストラクチャシステム１００にデプロイされるサービスのためのサービスインスタンスは、他のサービスインスタンスとの関連付けをサポートし得る。いくつかの例では、当該関連付けは、ターゲットサービスインスタンスに対するユーザの権限に準拠し得る。当該関連付けは、必須または任意であるように宣言され得る。サービスのためのサービス宣言における関連付け情報は、サービスプロバイダがこのような関連付けを特定することを可能にする。関連付けがサービス宣言において宣言されると、クラウドインフラストラクチャシステム１００は、サービス作成購買フローの一部として、可能な関連付けをＵＩに動的に反映させ得る。
【０１８７】
（ｄ）通知テンプレート情報
特定の実施例では、ＴＡＳは、オーダー起動、オーダー完了、パスワードなどであるがこれらに限定されないさまざまなインタラクションのための通知を顧客に送り得る。顧客に送られる通知メッセージは、各サービスごとにカスタマイズされることができる。いくつかの実施例によれば、カスタマイズは、差し込み可能な通知内容と、カスタマイズされた通知本体とに分類可能である。
【０１８８】
通知モジュールは、サービス表示名および説明を含むがこれらに限定されない情報をＴＡＳサービスカタログから検索するように提供され得る。また、サービス宣言および関連のＸＭＬベースのプロビジョニングを使用して、そのブループリントの一部としてサービスによって供給され得る、ロゴおよびマーケティング宣伝文などであるがこれらに限定されない差し込み可能な通知内容があってもよい。
【０１８９】
さらに、いくつかのまれなケースでは、サービスは、通知メッセージの構造全体を変更したい場合もある。例えば、ＨＣＭサービスは、２つのＳＦＴＰアカウントを必要とし得て、顧客に送られる通知は、大半の他のサービスのための１つだけのアカウントとは対照的に、両方のアカウントについて情報を提供する必要がある。
【０１９０】
サービスのためのサービス宣言は、サービスに使用される通知を特定する通知テンプレート情報を含んでいてもよい。これにより、サービスプロバイダは、サービスについての通知を制御およびカスタマイズすることができる。
【０１９１】
（ｅ）サービスランタイム情報
サービスプロバイダは、サービスのためのサービス宣言におけるサービスについてのサービスランタイム情報を供給し得る。これは、サービスについてのランタイム情報を処理および提供するためにクラウドインフラストラクチャシステム１００によって使用される。クラウドインフラストラクチャシステム１００によって処理されたサービスについてのランタイム情報は、サービスメトリックデータ、サービス状態、サービス可用性データ、サービスに影響を及ぼすイベントなどを含んでいてもよい。
【０１９２】
サービスメトリックデータは、全体に及ぶ情報（例えばＥＭウェブサービスによって使用されるタグ名などのサービスの全てのメトリックに適用可能な情報）と、メトリックに特有の情報（例えばメトリックＩｄ、タイプ、ユニット、現在／履歴、IsVisibleInPortal、表示情報、表示名、表示説明）とを含んでいてもよい。いくつかの例では、メトリックがポータルにおいて報告される場合、または、メトリックが派生メトリックの中間演算にのみ使用される場合に、IsVisibleInPortalが規定され得る。さらに、表示順序および表示カテゴリのようなさらなる表示に特有の要素が、メトリックに特有の情報に含まれていてもよい。
【０１９３】
特定の実施例では、派生の演算もメトリックに特有の情報に含まれていてもよい。派生の演算は、派生メトリックをサービスのためのさまざまなソースメトリックから演算するために使用される情報であり得る。これらの演算は、複数のソースメトリック上でのいくつかの基準にわたる集約であり得る（例えばａｖｇ、ｍｉｎ、ｍａｘ、ｓｕｍ、ｌａｓｔ）。集約方法についてのさらなるパラメータまたは詳細は、プロパティのリストによって取込まれることができる。プロパティの正確な詳細、名前および値は、集約方法および集約が必要とされるフィールドに依存し得る。
【０１９４】
サービス状態（例えばサービスインスタンス状態）は、ＥＭエージェントを介してこの情報を収集した後にＴＡＳに押しやられ得る。ＥＭエージェントは、サービス状態をＴＡＳに押しやるためにサービス提供メトリック収集ＡＰＩを使用し得て、当該サービス提供メトリック収集ＡＰＩは、他の使用メトリックとともにサービス状態のためのメトリックを含んでいてもよい。例えば、ＴＡＳウェブサービスを介した一般的なオペレーションが、そのサービスインスタンス状態を更新することができる任意のサービスプロバイダを使用する全てのサービスタイプに適用可能である。いくつかの例では、ＥＭは、サービスインスタンス状態をＴＡＳに押しやるためにＴＡＳウェブサービスＡＰＩを使用し得る。
【０１９５】
したがって、サービスのためのサービス宣言は、本明細書に記載されているＥＭ統合が、サービスインスタンス状態をＴＡＳリポジトリ、したがってクラウドポータルに反映させるのに十分であり得ることを規定する情報を備えていてもよい。
【０１９６】
特定の実施例では、サービス可用性情報は、サービスのタイプから独立しているウェブサービスＡＰＩを使用してＥＭからＴＡＳによって検索され得る。したがって、サービス宣言は、サービス可用性をカバーする必要はないかもしれない。サービスに影響を及ぼすイベントは、サービスのタイプから独立しているウェブサービスＡＰＩを使用してＥＭからＴＡＳによって検索され得る。したがって、サービス宣言は、計画的な停電をカバーする必要はないかもしれない。
【０１９７】
（ｆ）購買情報
サービスのためのサービス宣言は、サービスのための購買情報を規定し得る。購買情報は、バックオフィスアカウンティングシステム（ＧＳＩ）においてサービスを構成するために使用され得る。サービスの各々の提案またはサービスレベルごとに、サービスブループリントは、ＢＯＭ（部品表）を規定し得る。ＢＯＭは、サービス部分名および説明、ライセンス部分名および説明、ならびに価格決定情報などの情報を含んでいてもよい。ＢＯＭの価格決定セクションは、通貨コード、国コード、価格およびメトリック（例えば「ユーザ／月」）などの情報を含んでいてもよい。
【０１９８】
（ｇ）超過情報
各リソース（例えばファイルストレージ、データ転送）ごとに、サービスの特定の提案によって使用可能な当該リソースの量には限度があり得る。サービスインスタンスは、当該サービスインスタンスの提供レベルについて許可される量を超えて任意のリソースを使用すると、超過を招く。サービスのためのサービス宣言は、サービスの超過を演算するために必要な情報を規定し得る。
【０１９９】
サービス宣言の超過セクションは、超過限度、超過バンド定義、超過集約規則などの情報を含んでいてもよい。超過限度は、超過を招くことなくサービスによって使用可能なリソースの量を規定し得る。超過バンド定義は、１つの超過ユニットが許可するリソースの量を規定し得る。例えば、１つの超過ユニットは、提供レベルについて許可されるストレージの量を超えて、５ＧＢの追加のストレージを許可し得る。超過集約規則は、超過を演算しながらリソース使用値を集約するために使用される集約オペレーションを規定し得る。例えば、ストレージでは、集約オペレーションは「ｍａｘ」であり得て、データ転送では、超過オペレーションは「ｓｕｍ」であり得る。
【０２００】
（ｈ）サービスインスタンス関係／依存性サービスインスタンス情報
いくつかのサービスは、一次サービスインスタンスの作成の副生成物として暗黙の依存性サービスインスタンスを作成させるための要件を有している。例えば、ＦＡサービスでは、生成サービスインスタンスが作成されると、事前生成インスタンスが暗黙的に作成される。このようなシナリオでは、ＴＡＳは、サービスインスタンス同士の依存関係を把握し得て、２つのサービスインスタンスのライフサイクルが同期されることを保証する（例えば、生成インスタンスが削除されると事前生成インスタンスを暗黙的に削除し、単独での事前生成インスタンスの削除を防止する）。また、ＴＡＳは、クラウドポータルにおけるサービスインスタンス同士の関係を規定し得る。
【０２０１】
サービスのためのサービス宣言は、このような関係を規定する情報を備えていてもよい。特定の実施例では、サービス宣言は、一般的な関係モデルとして当該関係をモデル化することができ、事前生成／段階インスタンスの明示的なハードコードされた概念を有していないかもしれない。
【０２０２】
（２）物理的プロビジョニング情報
物理的プロビジョニングのためのブループリントデータベース６１８は、サービスの物理的フットプリントを定義するためのポッド定義スキーマ（例えばポッドスキーマ６２２）と、サービスに特有のプラグインを取込むためのサービス定義スキーマ（例えば要求／応答スキーマ６２０）と、ＥＭ、ＩＤＭ、ＵＲＬルーティングおよび他のサービスに特有の構成を取込むためのサービス構成スキーマ（例えばサービスインスタンススキーマ）とを含んでいてもよい。上記のように、ビジネス処理ブループリントの下では、ブループリントデータベース６１８は、ブループリントレジストリ６２４も含んでいてもよい。
【０２０３】
ポッド定義
サービスのためのサービス宣言におけるポッド定義は、サービスのためのポッドを構成するさまざまな局面を表わし得る。特定の実施例では、ポッド定義を構成する要素は、物理的フットプリント（例えばオラクルバーチャル・アセンブリ・ビルダ（ＯＶＡＢ）アセンブリ＋ＯＶＡＢデプロイメント計画）、テナンシタイプ、オンデマンドプロビジョニング選択およびカスタム属性であり得る。
【０２０４】
物理的フットプリント
いくつかの例では、ポッドのための物理的フットプリントは、ＯＶＡＢアセンブリベースの定義またはＶＭテンプレートベースの定義に規定され得る。ＯＶＡＢアセンブリベースの定義は、その物理的フットプリントをモデル化するためにサービスによって使用可能である。代替的に、サービスは、ＶＭテンプレートおよび関連付けられたリハイドレーションスクリプトを使用してその物理的フットプリントを宣言し得る。これは、ＯＰＣインフラストラクチャがクラウドスタックまたはオープンスタックなどの一般的なＩａａＳスタックをサポートする場合に有用であり得る。この情報は、サービス宣言に含まれていてもよい。
【０２０５】
さらに、サービスがそのブループリントにおいて物理的フットプリントを宣言しない場合、当該サービスはバンド外でそのポッドをセットアップし、登録ポッドＡＰＩを使用してポッドをクラウドインフラストラクチャシステム１００に登録し得る、ということが想定され得る。
【０２０６】
物理的フットプリントを定義する際、サービスは、ＯＶＡＢアセンブリの詳細、デプロイメント計画テンプレート、テナンシタイプ、およびポッドがオンデマンドでプロビジョニングされることができるべきか否かを規定し得る。
【０２０７】
アセンブリ位置に関して、構築されたＯＶＡＢベースのアセンブリを使用して物理的フットプリントをデプロイするサービスは、それらのアセンブリをアセンブリレジストリにアップロードし得て、次いでそれらのサービス宣言定義においてアセンブリを参照し得る。例えば、アセンブリレジストリ内のアセンブリの位置を規定するために、要素<assemblyLocation>が使用可能である。ＳＤＩは、所与のＯＰＣデプロイメントのために、アップロードされたアセンブリをＯＶＡＢに登録する任務を担い得る。当該要素は、サービスがサポートする（ベーシック、標準、エンタープライズなどの）各構成ごとに１つである。
【０２０８】
さらに、アセンブリレジストリは、大きなバイナリをアップロードして、アップロードされたバイナリに固有の識別子を提供するためにファイルシステムストアを使用するコンポーネントであり得て、当該固有の識別子は次いで、ブループリントなどの他のモジュールにおいてバイナリを参照するために使用可能である。
【０２０９】
特定の実施例では、デプロイメント計画およびＯＶＡＢベースのアセンブリに関して、ＯＶＡＢは、サービスのデプロイメントおよびリハイドレーションの面でＯＶＡＢを助けるデプロイメント計画を必要とし得る。サービスは、プロビジョニング層がサービスプロビジョニング中に実際のデプロイメント計画を作成するために使用し得るサービスアーカイブパッケージ全体の一部として、デプロイメント計画テンプレートを供給する必要があり得る。デプロイメント計画テンプレートは、ＯＶＡＢデプロイメント計画を生成するためにプロビジョニング中に実際の値と置換され得る、予め規定されたプレースホルダタグを有していてもよい。
【０２１０】
テナンシタイプは、サービスがマルチテナントサービスであるかシングルテナントサービスであるかを規定し得る。
【０２１１】
オンデマンドプロビジョニングは、サービスをオンデマンドでプロビジョニングできるか否かを規定し得る。例えば、当該サービスのために利用可能な容量がなければ、オンデマンドプロビジョニング要素は、プロビジョニングインフラストラクチャがサービス作成フロー中にオンザフライでポッドをデプロイすべきか否かを判断する。いくつかの例では、この要素が偽に設定され、利用可能な容量がなければ、プロビジョニング要求は中断され得て、管理者が追加の容量をプロビジョニングすることを可能にするようにアラートが生成され得る。
【０２１２】
カスタム属性
サービス宣言におけるカスタム属性情報は、サービスがポッド定義のために使用し得る一組のキーおよび値を取込み得る。属性は、キー／値の対、または、値がプロビジョニングインフラストラクチャによってデプロイメント時に認識される単なるキーであってもよい。値がデプロイメント時に認識されるカスタム属性の一例は、ポッド使用であってもよい。これらの属性は、ポッドスキーマの一部として格納され、サービスがカスタム属性値に基づいてテナント配置決定を駆動することを可能にするために、テナント配置セクションに規定されたポッドＡＰＩに渡され得る。
【０２１３】
ポッドのプール
クラウドインフラストラクチャシステム１００におけるポッドマネージャコンポーネントは、ポッドのプールの形式概念をサポートし得る。ＤｅｖＯｐｓ／オンデマンドサービスインスタンス作成フローは、ポッドを作成し、ポッドプールを作成し、ポッドをポッドプールに位置付けるために、ポッドマネージャＡＰＩを使用し得る。ポッドがポッドプールに位置付けられると、デプロイされたポッド／ポッドプールについての情報を引っ張ってくるようにサービスがＡＰＩに提供され得て、そのためプラグインにおけるテナント配置などの局面について十分な情報を得たうえでの判断を行うことができる。代替的に、ポッドのプールの情報は、サービスプラグインに渡されてもよい。
【０２１４】
ポッドおよびポッドプール関係
所与のサービスのために、複数のポッドがＤｅｖＯｐｓによって推測的に作成され得るか、または、（オンデマンドポッド作成がブループリントにおいて可能化される場合には）サービス作成フローによって実行時に作成され得る。いくつかのシナリオでは、これらのポッドは、何らかの方法で互いに関連付けることができる。このような関係の典型的な例は、一次ポッドのためにＤＲポッドが作成される場合である。この関係は、（ＤＲフローに対応するために）物理的プロビジョニング層によって追跡される必要があり、（クラウドポータルを介してＤＲインスタンスを公開するために）ビジネス処理層によって追跡される必要がある。
【０２１５】
サービスのためのサービス宣言は、サービスのための一次ポッドの作成の一部として作成される必要があるいかなる関連のポッドも宣言し得る。それは、（ＤＲの明示的なハードコードされた概念をサポートすることとは対照的に）他のタイプの関係のための余地を認めるために一般的なポッド関係としてモデル化され得る。
【０２１６】
ポッドプール関係は、どちらかというとデプロイメント局面であり、ＤｅｖＯｐｓによって構築および維持され得る。例えば、ＤｅｖＯｐｓは、所与のポッドプールのためのＤＲプールであるように特定のポッドプールを指定し得る。これは、一次ポッドがプール−１において作成されると、そのＤＲ関連のポッドがプール−１のためのＤＲプールに収容され得ることを暗に示しているであろう。この例では、ポッドをＤＲプールに配置する決定は、サービスのテナント配置規則／プラグインを使用して実現され得る。
【０２１７】
サービス定義
カスタムプラグインは、テナント配置プラグインおよびサービスプロビジョニングプラグインなどのサービスによって提供され得る。さらに、サービスによって提供されるプラグインは、タスク実行フレームワークセクションに記載されているようにタスクおよびタスクエクセキュータからなる共通のアーキテクチャに準拠し得る。この情報は、サービスのためのサービス宣言に規定され得る。
【０２１８】
テナント配置
テナント配置モジュールは、インスタンス作成中に新たなサービスインスタンスを収容するように最良のポッドを決定することを担当する。この配置は、（ゴールドの顧客、ＳＬＡ要件などの）ビジネス要件または（利用可能な容量、ＨＡ／ＤＲサポートなどの）物理的制約などのさまざまな要因に基づき得る。
【０２１９】
サービスプロビジョニングプラグイン
クラウドインフラストラクチャシステム１００のプロビジョニングインフラストラクチャは、サービス宣言提供プラグイン（すなわちコールバック）と連携して各サービスごとにさまざまなライフサイクルオペレーションを自動化することができる。例えば、サービスのためのサービス宣言は、プロビジョニングライフサイクルオペレーションプラグイン、プロビジョニングフローを変更するためのプラグイン、テナント配置のためのプラグイン、ＤｅｖＯｐｓによって起動されるオペレーションのためのプラグインなどのプラグインを提供し得る。プロビジョニングライフサイクルオペレーションプラグインは、createService、deleteService、upsizeService、関連付けおよびロックなどであるがこれらに限定されないさまざまなオペレーションのためのプラグインであってもよい。
【０２２０】
プロビジョニングフローを変更するためのプラグインは、タスク実行テンプレートによって駆動され得る。プロビジョニングフローは、細かい設定なしに（out-of-the-box：ＯＯＴＢ）シードされ、さらに物理的プロビジョニングオーケストレーションエンジンセクションに記載され得るさまざまなライフサイクルオペレーションのためのプロビジョニングフロー全体を含んでいてもよい。サービスは、新たなタスク実行テンプレート全体を提供することによって、または、明確に規定された実行ポイントにおいてカスタムタスクを実行フローに注入することによって、この実行フローをカスタマイズすることができる。いくつかの例では、カスタマイズされた実行フローは、最初の公開後にサポートされ得る。さらに、予め規定されたプロビジョニングフローは、各ライフサイクルオペレーションごとに実行される一組のタスクの概要を示すことができる一般的なタスク実行テンプレートとしてモデル化され得る。この情報は、サービスのためのサービス宣言に規定され得る。
【０２２１】
テナント配置のためのプラグインは、新たに作成されたサービスインスタンスを収容するように最良のポッドを決定するためにカスタムプラグインを提供し得る。ＤｅｖＯｐｓによって起動されるオペレーションのためのプラグインは、ＤｅｖＯｐｓがサービスを管理することを可能にするためにカスタムプラグインを提供し得る。これらは、開始／停止、RelocateInstanceおよび隔離などであるがこれらに限定されないオペレーションを含む。さらに、プラグインは、ＥＭ統合セクションに記載されているようにＥＭフレームワークを使用するＥＭカスタムジョブとして公開され得る。
【０２２２】
標準化されたプラグインアーキテクチャにより、サービスチームがさまざまなプロビジョニングアクションのための実現例を提供することが可能になり得る。プラグインは、サービスのためのサービス宣言におけるタスクとして表わされることができる。サービス提供プラグインの呼出しの一部として、ランタイム文脈およびライブラリを有する形式化されたランタイム実行環境も提供され得る。
【０２２３】
ライフサイクルプロビジョニングのためのプラグインは、シードされたタスク実行テンプレートによってＯＯＴＢで駆動され得る。当該テンプレートは、特定のタスクおよびオーダーを決定し得る。オペレーションに応じて、実行される一組の標準的なタスクが存在し得る。さらに、特定のタスクを実行するためのプラグインを提供するためにサービスが必要とされ得て、当該プラグインは、サービス自体によって最良に処理され、オーケストレーションエンジンによってブラックボックスとして扱われることができる。
【０２２４】
例えば、作成、アップサイズおよび終了オペレーションの各々について、決まった一組のタスクがサービスチームからプラグインとして必要とされ得る。いくつかの実施例によれば、作成サービスに関して、それが新たなシステムであれば、プラグインは、システムのためのＩＤＭフットプリントおよびＳＦＴＰアカウント作成を作成し得る。さらに、作成サービスプラグインは、サービスのためのＩＤＭフットプリントを作成し得る。サービス供給プラグインは、マルチテナントポッドにおいてテナント当たりのフットプリントを作成する（例えばデータベースサービス）か、予めプロビジョニングされた匿名のインスタンスにポッドのプールから「パーソナリティ」を注入する（例えばＪａｖａサービス）か、またはオンデマンドでポッドを作成し得る（例えばＦＡ）。いくつかの例では、入力パラメータは、サービス名、アイデンティティドメイン名、サイズ（例えばミニ／ベーシック／標準／エンタープライズ）、サブスクリプションタイプ（例えばトライアル／有料）および全ての他のプロパティをキー−値の対のリストとして含んでいてもよい。
【０２２５】
さらに、サービスのためのサービス宣言に規定されるように、サービス供給プラグインは、ＦＡのために言語パックをインストールすることまたはエンタープライズマネージャグリッド制御（Enterprise Manager Grid Control：ＥＭＧＣ）にデータベースを発見させることのようなデプロイ後プロセスに使用可能である。ＳＦＴＰアカウント作成は、サービスレベルでなされ得る。さらに、ネットワーク構成要素が必要とすれば、サービス宣言は、ＵＲＬルーティングのためにＯＨＳ構成の変更を可能にし得る。
【０２２６】
アップサイズサービスのために、追加のリソースのブックキーピングを取っておいてもよい。ブループリント当たり、サービスがプロビジョニングインフラストラクチャによって追跡されるリソース（例えばＩＰアドレス）のうちのいずれかを使用する場合に、アップサイズプラグインが必要とされ得る。スケールアップのためのサービス供給プラグインは、以下の入力パラメータ、すなわち新たなサイズおよび全ての他のプロパティ、をキー−値の対のリストとして含んでいてもよい。
【０２２７】
終了サービスに関して、切離しを行うために関連付けサービス供給プラグインが使用可能である。例えば、Ｊａｖａとデータベースとが関連付けられ、データベースが終了中である場合、ウェブロジックサーバからデータソースを除去するためにＪａｖａサービスからのプラグインが使用され得る。サービス宣言に規定される入力パラメータは、サービス名、終了中のサービスのアイデンティティドメイン名および全ての他のプロパティをキー−値の対のリストとして含んでいてもよい。
【０２２８】
さらに、ブループリントにおけるネットワーク構成要素が必要とすれば、終了プラグインは、ＵＲＬルーティングのためにＯＨＳ構成を除去し得る。アーカイバルが可能化されると、終了プラグインは、サービスアーカイブをＳＦＴＰアカウントに移動させることができる。アーカイバルが可能化されなければ、終了プラグインは、全てのデータを削除して、ＳＦＴＰアカウントを除去することができる。さらに、終了プラグインは、ＥＭＧＣからターゲットを除去し得る。
【０２２９】
さらに、サービスは、クリーンアップのためのプラグインを供給し得る。入力パラメータは、プロパティをキー−値の対のリストとして含んでいてもよい。クリーンアッププラグインは、プロビジョニングインフラストラクチャによって追跡されている全てのリソース（例えばＩＰアドレス、ボリューム、仮想ＯＶＡＢホーム）を破壊および回復させ得る。
【０２３０】
必要なプラグインに加えて、プロビジョニングライフサイクルオペレーションの一部として、サービスはカスタムプラグインも提供し得る。カスタムオペレーションフローのためのプラグインは、カスタムタスクを実行フローに注入し得る。これは、タスク実行シーケンスにおいて許可された特定のポイントにおいて、制御された態様でなされ得る。サービスは、サービスに特有のアクションを行うためにこれらのカスタムタスクを使用してプロビジョニングフローを自由に強化または変更できる。例えば、ＳＦＴＰアカウントの作成前にシステムのためのＩＤＭフットプリントを作成した後で、カスタムタスクを実行することができるであろう。さらに、任意のオペレーションのためのフロー全体は、新たなタスク実行テンプレートを提供することによって無効にされ得る。
【０２３１】
サービス構成
サービスのためのサービス宣言におけるサービス構成情報は、サービスプロバイダがサービスのためのさまざまな構成要素を定義することを可能にする。サービス構成情報は、ネットワークを構成するために、例えばＥＭ統合セクションと、ＩＤＭ統合セクションと、ネットワーク構成セクションとを含んでいてもよい。
【０２３２】
ＥＭ統合
サービス宣言におけるＥＭ統合情報は、ＥＭを介してサービスのモニタリングおよび管理を可能にするエンタープライズマネージャクラウド制御（Enterprise Manager Cloud Control：ＥＭＣＣ）と統合するために必要な定義を提供し得る。
【０２３３】
各サービスがサービス宣言に規定し得るＥＭ統合の主要な局面は、ターゲットタイプ、ターゲット発見属性およびスクリプト、メトリック収集プラグイン、メトリック収集間隔、モニタリングアカウントならびにカスタムジョブを含んでいてもよい。
【０２３４】
ターゲットタイプは、新たなモニタリング可能なターゲットをモデル化するためにＥＭによって必要とされるメタデータを定義し得る。サービスブループリントに規定される情報は、ＥＭターゲットメタデータＸＭＬスキーマに適合するターゲットタイプＸＭＬ文書を生成するために使用され得る。次いで、ターゲットタイプＸＭＬ文書は、ＥＭ  ＡＰＩを使用してＥＭに登録され得る。いくつかの例では、ターゲットタイプテンプレートは、ＥＭツールを使用して生成され、必要に応じて手作業で編集され、ＥＭ拡張性開発キット（Extensibility development Kit：ＥＤＫ）を介してＥＭＣＣおよびＥＭＣＣエージェントに登録され得る。さらに、ブループリントは、サービスがサービスレジストリに登録されるとサービス公開プロセス中にプロビジョニングインフラストラクチャから呼出され得るクリーナ／より単純なプログラムＡＰＩを使用して、ターゲットタイプを自動化することができる。
【０２３５】
ターゲット発見属性およびスクリプトは、ＥＭにおいてターゲットを作成するために使用されるサービスインスタンスに特有の属性であってもよい。サービス宣言に規定される情報は、ＥＭ  ＡＰＩを呼出してサービスインスタンス作成フロー中にターゲットを作成するために使用され得る。いくつかの例では、ターゲットの作成は、ＥＭ  ＣＬＩを使用して、（例えばデータベースサービスの場合のように）ＳＤＩによって、または（例えばＮｕｖｉａｑがこの機能を実行するＪａｖａサービスの場合のように）サービス自体によってなされる。サービス宣言は、これを、全てのサービスにわたって共通の方法でプロビジョニングインフラストラクチャから呼出され得るＲＥＳＴ  ＡＰＩに発展させることができる。
【０２３６】
メトリック収集プラグインは、ＥＭが特定のサービスインスタンスのためのメトリックを収集することを可能にし得るプラグインＸＭＬへの経路を定義する。ＥＭは、サービスがＪＭＸ、ＲＥＳＴ、ウェブサービス、スクリプトなどのさまざまな機構を使用してプラグインを定義することを可能にする。ＯＰＣサービスブループリントは、メトリック収集プラグインの定義を取込むために、ＥＭによって定義されるＸＭＬスキーマを公開し得る。
【０２３７】
メトリック収集間隔局面は、ＥＭＣＣがサービスインスタンスターゲットのためのメトリックを収集するスケジュールを制御し得る。
【０２３８】
モニタリングアカウント局面は、サービス提供メトリック収集プラグインを使用してサービスインスタンスターゲットのためのメトリックを収集するためにＥＭＣＣエージェントによって使用されるアカウントをサービスにおいて定義し得る。
【０２３９】
カスタムジョブ局面では、ＥＭは、サービスの開始／停止などのカスタム機能を実行するためにサービスによって登録されるカスタムジョブの概念をサポートし得る。次いで、当該カスタム機能は、ＥＭコンソールを介してＤｅｖＯｐｓに公開される。ＯＰＣプロビジョニングフレームワークは、標準的な一組の動詞（例えば開始、停止、リロケート、隔離）を定義し得て、当該標準的な一組の動詞は、全てのサービスにわたって共通の一組のインターフェースをＤｅｖＯｐｓに提供してＥＭコンソールを介してサービス管理機能を実行するためにＥＭカスタムジョブフレームワークを活用し得る。
【０２４０】
ＩＤＭ統合
これらのサービス定義は、サービスのためのサービス宣言に規定され得る要素であり、サービス作成の一部として、共有のＩＤＭインフラストラクチャにおいて作成されるサービスインスタンス当たりのフットプリントの作成を可能にする。これは、例えばサービス名、役割テンプレートおよびアイデンティティドメイン／サービス管理役割マッピングを含んでいてもよい。例えば、サービス名は、ＴＡＳおよびＳＤＩに登録されたサービス名と一致し得る。
【０２４１】
役割テンプレートは、サービス作成の一部としてインスタンス化される必要がある一組のサービスインスタンス当たりの役割であってもよい。次いで、これらの役割の各々は、ＩＤＭコンソールを介してサービスインスタンスのための割当て可能な役割になり得る。
【０２４２】
アイデンティティドメイン管理／サービス管理役割マッピングは、アイデンティティドメインユーザ／サービス管理ユーザがサービスインスタンス作成の一部として作成したときにこれらのユーザに付与される必要がある一組の役割を定義し得る。
【０２４３】
いくつかの例では、サービス宣言における以下の局面が、ＩＤＭ統合に関してまとめられ得る。これは、ＸＭＬスキーマを規定して、ＯＡＭポリシ、ＣＳＲ権限、関連付け中のＳＡＭＬ  ＩＤの伝搬、ＡｐｐＩＤ、ＩＤストア／ＯＰＳＳストアにアクセスするためのサービスランタイムコードのバインド証明書、およびＯＰＣキーリフレッシュ自動化を活用するための証明書／キーのライフサイクルを取込むためになされる。
【０２４４】
ネットワーク構成（ＵＲＬルーティング）
ネットワーク構成は、ファイヤウォール規則、ＵＲＬルーティング、および一貫したクラウドＵＲＬ名前スペースを定義するために必要な情報を定義する要素を含んでいてもよい。さらに、プロビジョニングインフラストラクチャ層は、サービスのためのＵＲＬをルーティングするように、ＢｉｇＩＰロードバランサおよびＯＨＳノードのプールを構成し得る。
【０２４５】
（３）ポッドプロビジョニング情報
特定の実施例では、サービスのためのポッドの作成および使用に関連する情報が、サービスのためのサービス宣言に規定され得る。次いで、この情報は、サービスプロビジョニング中にポッドマネージャによって使用される。
【０２４６】
特定の実施例では、ポッドマネージャは、全てのサービスにわたるポッドの作成および管理を担当するモジュールである。いくつかの実施例によれば、ポッドマネージャは、オブジェクトを管理し、永続的なスキーマを維持し、利用可能なポッドの容量をモニタリングし、ＤｅｖＯｐｓによって使用されるプログラムＡＰＩをサポートし得る。いくつかの例では、ポッドマネージャは、ポッドまたはポッドプールを管理し得る。
【０２４７】
例えば、ポッドは、（例えばＪａｖａサービスの場合のように）予めプロビジョニングされた匿名のシングルテナントデプロイメント、または（例えばデータベースサービスの場合のように）複数のテナントを供給するマルチテナントスタック（すなわち物理的または仮想化された）に相当し得る論理的エンティティであってもよい。換言すれば、ポッドは、物理的なスタック上でのサービスのデプロイメントであり得る。ポッドは、１つ以上のサービスインスタンスを収容し得る。ポッドは、推測的に作成され得るか、またはサービスインスタンスが所与の顧客のために作成されるとオンデマンドで作成され得る。
【０２４８】
例えば、ポッドプールは、シングルテナントまたはマルチテナントポッドのプールであり得る。プールは、多くの理由（例えばさまざまなＳＬＡ要件、好ましい顧客、サービス構成における変動）でポッドの集合体を分離するために作成され得る。サービスインスタンスが所与の顧客のために作成されると、当該サービスインスタンスは、テナント配置セクションに定義されるさまざまな基準に基づいて、所与のプールからポッドに収容され得る。
【０２４９】
さらに、ポッドマネージャは、他のポッド関連情報の中で、サービス当たりのポッドのリスト、ポッドにおけるサービスインスタンスのリスト、ポッドプールのリスト、各ポッドの物理的フットプリント、および各ポッドについての容量情報を追跡するための永続的なスキーマを維持し得る。
【０２５０】
さらに、ポッドマネージャは、利用可能なポッドおよび各ポッド内のリソースの容量をモニタリングして、容量閾値に達するとアラートを生成し得る。
【０２５１】
さらに、ポッドマネージャは、ＤｅｖＯｐｓによって使用されるプログラムＡＰＩをサポートし得る。プログラムＡＰＩは、createpod、createpodPool、listpods、listpodPools、（バンド外で作成されるポッドのための）registerpod、listServiceInstancesInpodおよびscalepodを含んでいてもよい。
【０２５２】
図１６は、本発明の実施例に従って使用され得る演算システム１０００の簡略ブロック図である。例えば、クラウドインフラストラクチャシステム１００は、１つ以上の演算装置を備えていてもよい。図１０に示されるシステム１０００は、１つのこのような演算装置の一例であってもよい。バス１０２４を介して電気的に結合され得るハードウェア要素を備えるコンピュータシステム１０００が示されている。コンポーネントは、１つ以上の処理ユニット１００２と、入力サブシステム１００４と、出力サブシステム１００６と、記憶装置１００８と、コンピュータ読取可能記憶媒体１０１０に接続されるコンピュータ読取可能記憶媒体リーダ１０１２と、通信サブシステム１０１４と、処理加速サブシステム１０１６と、ワーキングメモリ１０１８とを含んでいてもよい。
【０２５３】
バスサブシステム１０２４は、コンピュータシステム１０００のさまざまなコンポーネントおよびサブシステムを意図されたように互いに通信させるための機構を提供する。バスサブシステム１０２４は単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施例は、複数のバスを利用してもよい。
【０２５４】
入力サブシステム１００４は、マウス、キーボード、ポインティングデバイス、タッチパッドなどの１つ以上の入力装置を含んでいてもよい。一般に、入力サブシステム１００４は、情報をコンピュータシステム１０００に入力するための任意の装置または機構を含んでいてもよい。
【０２５５】
出力サブシステム１００６は、コンピュータシステム１０００から情報を出力するための１つ以上の出力装置を含んでいてもよい。出力装置の例としては、ディスプレイ装置、プリンタ、プロジェクション装置などが挙げられるが、これらに限定されるものではない。一般に、出力サブシステム１００６は、コンピュータシステム１０００から情報を出力するための任意の装置または機構を含んでいてもよい。
【０２５６】
処理ユニット１００２は、１つ以上のプロセッサ、プロセッサの１つ以上のコア、それらの組み合わせなどを含んでいてもよい。いくつかの実施例では、処理ユニット１００２は、汎用一次プロセッサと、グラフィックスプロセッサ、デジタル信号プロセッサなどの１つ以上の特殊用途コプロセッサとを含んでいてもよい。いくつかの実施例では、いくつかのまたは全ての処理ユニット１００２は、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）またはフィールド・プログラマブル・ゲート・アレイ（field programmable gate array：ＦＰＧＡ）などのカスタマイズされた回路を使用して実現されてもよい。いくつかの実施例では、このような集積回路は、回路自体に格納されている命令を実行する。他の実施例では、処理ユニット１００２は、ワーキングメモリ１０１８または記憶装置１００８に格納された命令を実行し得る。さまざまな実施例では、処理ユニット１００２は、さまざまなプログラムまたはコード命令を実行し得て、複数の同時実行プログラムまたはプロセスを維持し得る。任意の所与の時間に、実行されるべきプログラムコードのうちのいくつかまたは全ては、システムワーキングメモリ１０１８、記憶装置１００８および／またはコンピュータ読取可能記憶媒体１０１０に存在し得る。好適なプログラミングを介して、処理ユニット１００２は、イベントストリーム関連の処理を実行するための上記のさまざまな機能を提供し得る。いくつかの実施例では、コンピュータシステム１０００は、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、特殊用途プロセッサなどを含み得る処理加速ユニット１０１６も含んでいてもよい。
【０２５７】
記憶装置１００８は、ディスクドライブ、光学記憶装置、およびランダムアクセスメモリ（random access memory：ＲＡＭ）および／またはリードオンリメモリ（read-only memory：ＲＯＭ）などの、プログラム可能、フラッシュ更新可能などであり得るソリッドステート記憶装置、などのメモリ装置を含んでいてもよい。処理ユニット１００２によって実行されると上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が記憶装置１００８に格納され得る。また、記憶装置１００８は、本発明の実施例に従って使用されるデータを格納するためのリポジトリも提供し得る。
【０２５８】
さらに、コンピュータ読取可能記憶媒体リーダ１０１２は、ともに（および任意に、記憶装置１００８と組み合わせて）一時的および／またはより永久的にコンピュータ読取可能な情報を含むためのリモートの、ローカルの、固定されたおよび／または取外し可能なメモリ記憶装置プラス記憶媒体を包括的に表わすコンピュータ読取可能記憶媒体１０１０に接続可能である。
【０２５９】
通信サブシステム１０１４は、ネットワークおよび／またはその他のコンピュータとデータを遣り取りすることを可能にし得る。通信サブシステム１０１４は、コンピュータシステム１０００からデータを受取り、コンピュータシステム１０００から他のシステムにデータを送信するためのインターフェースの働きをする。通信は、有線または無線プロトコルを使用して行われてもよい。例えば、通信サブシステム１０１４は、コンピュータ１０００がインターネットを介してクライアント装置に接続することを可能にし得る。通信サブシステム１０１４は、モデム、ネットワークカード（無線または有線）、赤外線通信装置、ＧＰＳ受信機などを備えていてもよい。
【０２６０】
ワーキングメモリサブシステム１０１８は、プログラムの実行中に命令およびデータを格納するためのメインランダムアクセスメモリ（ＲＡＭ）および決まった命令が格納されるリードオンリメモリ（ＲＯＭ）を含むいくつかのメモリを含んでいてもよい。オペレーティングシステム１０２０、および／または、（クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、ＲＤＢＭＳなどであってもよい）アプリケーションプログラムなどの他のコード１０２２などのソフトウェア要素が、ワーキングメモリ１０１８に格納され得る。例示的な実施例では、ワーキングメモリ１０１８は、実行可能なコードと、上記のようにイベントを処理して可変期間ウィンドウ処理を可能にするために使用される（キャッシュなどの）関連付けられたデータ構造とを含んでいてもよい。
【０２６１】
コンピュータシステム１０００の代替的な実施例は、上記のものからの多数の変更例を備えたより多くのまたはより少ないコンポーネントを有していてもよいということが理解されるべきである。例えば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素がハードウェア、（アプレットなどの高移植性ソフトウェアを含む）ソフトウェアまたはそれら両方で実現されてもよい。さらに、ネットワーク入力／出力装置などの他の演算装置への接続が利用されてもよい。
【０２６２】
本発明の特定の実施例について説明してきたが、さまざまな変形例、変更例、代替的な構成および等価物も本発明の範囲内に包含される。本発明の実施例は、特定の具体的なデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自由に動作できる。さらに、特定の一連のトランザクションおよびステップを使用して本発明の実施例について説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されるものではないということが当業者に明らかであるべきである。
【０２６３】
さらに、ハードウェアおよびソフトウェアの特定の組み合わせを使用して本発明の実施例について説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本発明の範囲内であることが認識されるべきである。本発明の実施例は、ハードウェアのみで実現されてもよく、またはソフトウェアのみで実現されてもよく、またはそれらの組み合わせを使用して実現されてもよい。本明細書に記載されているさまざまなプロセスは、任意の組み合わせで、同一のプロセッサまたは異なるプロセッサ上で実現されてもよい。したがって、コンポーネントまたはモジュールは特定のオペレーションを実行するように構成されるものとして記載されているが、このような構成は、例えばオペレーションを実行するように電子回路を設計することによって、オペレーションを実行するように（マイクロプロセッサなどの）プログラム可能な電子回路をプログラミングすることによって、またはそれらの任意の組み合わせによって、実現可能である。プロセスは、従来のプロセス間通信技術を含むがこれに限定されないさまざまな技術を使用して通信可能であり、プロセスの異なる対は異なる技術を使用してもよく、またはプロセスの同一の対は異なる時間に異なる技術を使用してもよい。
【０２６４】
したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかし、特許請求の範囲に記載されているより広範な精神および範囲から逸脱することなく、追加、削減、削除ならびに他の変形および変更がそれに対してなされてもよいということは明白であろう。したがって、特定の本発明の実施例について説明してきたが、これらは限定的であるよう意図されるものではない。さまざまな変形例および等価物も以下の特許請求の範囲の範囲内である。
【０２６５】
図１７は、本発明のさまざまな実施例に係る一組のクラウドサービスを提供するように構成されたクラウドインフラストラクチャシステム１７００の図である。図１７に示されるように、クラウドインフラストラクチャシステム１７００は、クラウドインフラストラクチャシステムによって提供される一組のクラウドサービスに対応する一組のサービス宣言を格納するように構成された格納ユニット１７０１と、顧客からサブスクリプションオーダー情報を受取るように構成された受取ユニット１７０３とを備え、当該サブスクリプションオーダー情報は、クラウドインフラストラクチャシステムによって提供される一組のクラウドサービスから、選択されたサービスを特定し、クラウドインフラストラクチャシステム１７００はさらに、選択されたサービスのために特定のサービス宣言を決定するように構成された決定ユニット１７０５を備え、当該特定のサービス宣言は、選択されたサービスを可能化するためにリソースをプロビジョニングするための１つ以上のプロシージャを示す情報を備え、クラウドインフラストラクチャシステム１７００はさらに、特定のサービス宣言における情報に基づいて、選択されたサービスをプロビジョニングするように構成されたプロビジョニングユニット１７０７を備える。
【０２６６】
一実施例によれば、クラウドインフラストラクチャシステム１７００はさらに、クラウドインフラストラクチャシステムによって提供される一組のクラウドサービスにサービスを追加するためのサービス宣言テンプレートを提供するように構成された提供ユニット１７０９と、新たなサービスをクラウドインフラストラクチャシステムに登録するための変更されたサービス宣言を受取るように構成された受取ユニット１７１１とを備え、当該変更されたサービス宣言は、新たなサービスを可能化するために一組のリソースをプロビジョニングするための一組のプロシージャを示す情報を備え、クラウドインフラストラクチャシステム１７００はさらに、クラウドインフラストラクチャシステムによって提供される一組のクラウドサービスに新たなサービスを追加するように構成された追加ユニット１７１３を備える。
【０２６７】
一実施例によれば、クラウドインフラストラクチャシステム１７００はさらに、顧客から１つ以上の入力要件を受取るように構成された受取ユニット１７１５を備え、当該１つ以上の入力要件は、選択されたサービスを可能化するためにリソースをプロビジョニングするために、特定のサービス宣言によって順番に必要とされる。
【０２６８】
クラウドインフラストラクチャシステムの機能ブロックは、本発明の原理を実施するために、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせによって実現されてもよい。図１７に示される機能ブロックは、上記の本発明の原理を実現するために、組み合わせられてもよく、またはサブブロックに分けられてもよい、ということが当業者によって理解される。したがって、本明細書における説明は、本明細書に記載されている機能ブロックの任意の可能な組み合わせまたは分離またはさらなる定義をサポートすることができる。
【図１Ａ】
0006326417.tif 000002
【図１Ｂ】
0006326417.tif 000003
【図２】
0006326417.tif 000004
【図３Ａ】
0006326417.tif 000005
【図３Ｂ】
0006326417.tif 000006
【図４】
0006326417.tif 000007
【図５】
0006326417.tif 000008
【図６】
0006326417.tif 000009
【図７Ａ】
0006326417.tif 000010
【図７Ｂ】
0006326417.tif 000011
【図７Ｃ】
0006326417.tif 000012
【図７Ｄ】
0006326417.tif 000013
【図７Ｅ】
0006326417.tif 000014
【図８】
0006326417.tif 000015
【図９】
0006326417.tif 000016
【図１０】
0006326417.tif 000017
【図１１】
0006326417.tif 000018
【図１２】
0006326417.tif 000019
【図１３】
0006326417.tif 000020
【図１４】
0006326417.tif 000021
【図１５】
0006326417.tif 000022
【図１６】
0006326417.tif 000023
【図１７】
0006326417.tif 000024