JP7291854B2 - サービス統合としてのソフトウェアのコードレス仕様 - Google Patents

Description

クラウドコンピューティングプロバイダは、コンピューティングサービス（例えば、データベース、仮想マシン、ソフトウェアアプリケーション、及び／又はその他のサービス）を、静的に又はオンデマンドでユーザがリモートで利用することを可能にし得る。典型的には、これらのコンピューティングサービスは、クラウドコンピューティングプロバイダが提供する統合ポイントを介してアクセスされ得る。ユーザと統合ポイントとの間の相互作用は、インターネットを介して発生し得る。

例示的なユーザは企業であり得る。企業は、ファイル共有、ワークフロー管理、及びデータベース計画等の動作をサポートするために、コンピューティングサービスを使用し得る。クラウドコンピューティングプロバイダのコンピューティングサービスを使用することによって、企業はコンピューティングサービスの開発及び／又は保守に関連するコストを回避又は削減し得る。更に、企業のニーズの変化に応じて、企業は、追加の動作をサポートするために、クラウドコンピューティングプロバイダが提供する新たなコンピューティングサービス又は様々なコンピューティングサービスを利用し得る。

管理されたネットワークは、その動作をサポートするために様々なコンピューティングサービスを使用し得る。時折、これらのコンピューティングサービスは、クラウドコンピューティングプロバイダによって“サービスとしてのソフトウェア”（“ＳａａＳ”としても知られ得る）の形式で提供される。ＳａａＳパラダイムの下では、クラウドコンピューティングプロバイダは、コンピューティングサービスを実行し、管理されたネットワークがコンピューティングサービスにリモートでアクセスし得るアプリケーションプログラミングインターフェース（ＡＰＩ）エンドポイント等の統合ポイントをその後公開するために必要なハードウェア／ソフトウェアを提供する。

管理されたネットワークは、クラウドコンピューティングプロバイダによって提供される数千とは言わないまでも数百のコンピューティングサービスを使用し得る。したがって、管理されたネットワークがこれらのコンピューティングサービスの消費を監視することは興味深いことであり得る。リモートネットワーク管理プラットフォームは、管理されたネットワーク内で動作するコンピューティングサービスについての情報を収集するように既に構成され得るので、このタスクに特に適し得る。クラウドコンピューティングサービスの消費情報を取得するために、リモートネットワーク管理プラットフォームは、クラウドコンピューティングプロバイダにより提供される統合ポイントを介して、特定のコンピューティングサービスに対応する消費情報をリクエストし得る。応答を受信すると、リモートネットワーク管理プラットフォームは消費情報をデータベース内に格納し得る。この情報は、情報技術サービス及び運用管理、ソフトウェア資産管理、並びに／又はその他の様々なネットワークサービス及び運用の基礎としてその後使用され得る。

それでも、新たなコンピューティングサービスと相互作用するようにリモートネットワーク管理プラットフォームを構成することは困難であり得る。コンピューティングサービスは個別の構成の詳細をしばしば有するので、新たなコンピューティングサービスに対するサポートを追加するには、アプリケーション開発者のチームが、これらの個別の構成の詳細をリモートネットワーク管理プラットフォームに組み込むカスタムソフトウェアを創出することを伴い得る。開発プロセスは厳密な統合テストを伴い得るため、これには数週間又は数か月かかり得る。また、リモートネットワーク管理プラットフォームが幾つかの新たなコンピューティングサービスと相互作用する場合、プロセスは甚だしい時間を消費し得る。

本開示は、これら及びその他の問題に対処し得るリモートネットワーク管理プラットフォームへの改善を提供する。具体的には、リモートネットワーク管理プラットフォームは、リモートネットワーク管理プラットフォームがクラウドコンピューティングプロバイダにより提供されるコンピューティングサービスと容易に統合することを可能にするコンピューティングサービスニュートラル（ＣＳＮ）クラウド統合アプリケーションを含み得る。実行中、ＣＳＮクラウド統合アプリケーションには、管理されたネットワーク又は別のサービスにより提供される仕様からのデータがポピュレートされる。こうしたデータは、１つ以上のコンピューティングサービスに対する個別の構成の詳細を含み得る。有利なことに、管理されたネットワークが新たなコンピューティングサービスを統合した場合、リモートネットワーク管理プラットフォームへの追加のソフトウェアの更新は必要なくてもよい。むしろ、管理されたネットワークは、例えば、グラフィカルユーザインターフェース（ＧＵＩ）を介して仕様を単に更新し得、ＣＳＮクラウド統合アプリケーションはそれに応じて再構築され得る。このフレームワークを使用すると、新たなコンピューティングサービスを統合するためのサポートは、リモートネットワーク管理プラットフォームに迅速に追加され得、これらの新たなコンピューティングサービスにより提供される動作を企業が迅速に監視することが可能である。その他の利点も可能である。

したがって、第１の例示的実施形態は、管理されたネットワークに専用の計算インスタンスを含み得る。計算インスタンスは永続ストレージを含み得、永続ストレージは、リモートネットワークにより提供されるコンピューティングサービスの表現をデータベーステーブル内に含む。計算インスタンスは、コンピューティングサービスニュートラルクラウド統合アプリケーションに動作を実施させるように構成された１つ以上のプロセッサを更に含み得る。該動作は、リモートネットワークに関連する仕様を取得することを含み得、該仕様は、（ｉ）リモートネットワークに対する統合ポイント、（ｉｉ）統合ポイントにより提供される応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）応答に現れるリモートネットワークにより提供されるコンピューティングサービスの記述とデータベーステーブルのフィールドとの間のマッピングを定義する。動作は、リモートネットワークにより提供されるコンピューティングサービスの第１の記述を、統合ポイントを介してリクエスト及び受信することを更に含み得る。動作は、リモートネットワークに対する第２の統合ポイントを、ページネーションタイプ及び統合ポイントから判定することを更に含み得る。動作は、リモートネットワークにより提供されるコンピューティングサービスの第２の記述を、第２の統合ポイントを介してリクエスト及び受信することを更に含み得る。動作は、マッピングに従って第１の記述及び第２の記述をデータベーステーブルのフィールド内に格納することを更に含み得る。

第２の例示的実施形態では、製品は、コンピューティングシステムにより実行されると、コンピューティングシステムに第１の例示的実施形態に従った動作を実施させるプログラム命令をその上に格納した、非一時的コンピュータ可読媒体を含み得る。

第３の例示的実施形態では、コンピューティングシステムは、少なくとも１つのプロセッサ、並びにメモリ及びプログラム命令を含み得る。プログラム命令は、メモリ内に格納され得、少なくとも１つのプロセッサにより実行されると、第１の例示的実施形態に従った動作をコンピューティングシステムに実施させ得る。

第４の例示的実施形態では、システムは、第１の例示的実施形態の動作の各々を実行するための様々な手段を含み得る。

これらの並びにその他の実施形態、態様、利点、及び代替物は、添付の図面を適切に参照して、以下の詳細な説明を読むことによって当業者に明らかになるであろう。更に、この発明の概要並びに本明細書で提供されるその他の説明及び図は、例としてのみ実施形態を説明することを意図しており、したがって、多くの変形が可能である。実例として、構造要素及びプロセスステップは、請求されるような実施形態の範囲内にとどまりながら、再配置され得、組み合わされ得、分散され得、省略され得、さもなければ変更され得る。

例示的実施形態に従ったコンピューティングデバイスの概略図を説明する。 例示的実施形態に従ったサーバデバイスクラスタの概略図を説明する。 例示的実施形態に従ったリモートネットワーク管理アーキテクチャを描写する。 例示的実施形態に従ったリモートネットワーク管理アーキテクチャを含む通信環境を描写する。 例示的実施形態に従ったリモートネットワーク管理アーキテクチャを含む別の通信環境を描写する。 例示的実施形態に従ったフローチャートである。 例示的実施形態に従ったネットワークアーキテクチャを説明する。 例示的実施形態に従ったユニフォームリソースロケータ（ＵＲＬ）を描写する。 例示的実施形態に従ったグラフを描写する。 例示的実施形態に従ったメッセージフローを描写する。 例示的実施形態に従ったウェブページを描写する。 例示的実施形態に従ったウェブページを描写する。 例示的実施形態に従ったウェブページを描写する。 例示的実施形態に従ったウェブページを描写する。 例示的実施形態に従ったフローチャートである。

例示的な方法、デバイス、及びシステムが本明細書に説明される。本明細書では、単語“例”及び“例示的”は、“例、実例、又は例証として役立つ”ことを意味するために使用されることを理解すべきである。“例”又は“例示的”であるとして本明細書に説明する任意の実施形態又は機構は、そのように述べられない限り、必ずしも他の実施形態又は機構よりも好ましい又は有利であると解釈すべきではない。したがって、本明細書に提示される主題の範囲から逸脱することなく、他の実施形態が利用され得、他の変更がなされ得る。

したがって、本明細書に説明する例示的実施形態は、限定することを意図しない。本明細書に一般的に説明され、図に説明するような本開示の態様が、多種多様な異なる構成で配置され得、置換され得、組み合わされ得、分離され得、及び設計され得ることは容易に理解されるであろう。例えば、“クライアント”コンポーネントと“サーバ”コンポーネントとへの機構の分離は、様々な方法で生じ得る。

更に、文脈が他のことを示唆しない限り、図の各々に説明する機構は、相互に組み合わせて使用され得る。したがって、図は、一般的に、全ての説明する機構が実施形態毎に必要であるとは限らないことを理解すると共に、１つ以上の全体的な実施形態のコンポーネントの態様としてみなされるべきである。

また、この明細書又は特許請求の範囲における要素、ブロック、又はステップの任意の列挙は、明確にする目的のためのものである。したがって、そうした列挙は、これらの要素、ブロック、又はステップが特定の配置に準拠すること、又は特定の順序で実行されることを必要とする又は暗示するものとして解釈されるべきではない。

Ｉ． はじめに
大企業は、多くの相互に関連する動作を伴う複合的なエンティティである。これらの内の幾つかは、人材（ＨＲ）、サプライチェーン、情報技術（ＩＴ）、及び財務等、企業全体で見られる。しかしながら、各企業はまた、本質的な能力を提供し、及び／又は競争上の優位性を創出する独自の動作を有する。

広く実装された動作をサポートするために、企業は、典型的には、顧客関係管理（ＣＲＭ）及び人的資本管理（ＨＣＭ）パッケージ等の既製のソフトウェアアプリケーションを使用する。しかしながら、それらの独自のユニークな要件を満たすためにカスタムソフトウェアアプリケーションを必要とすることもあり得る。大企業は、数十又は数百のこれらのカスタムソフトウェアアプリケーションをしばしば有する。それにもかかわらず、本明細書の実施形態により提供される利点は、大企業に限定されず、任意の規模の企業又は任意の他のタイプの組織に適用可能であり得る。

多くのそうしたソフトウェアアプリケーションは、企業内の個々の部門によって開発される。これらは、単純なスプレッドシートからカスタムビルドのソフトウェアツール及びデータベースにまで及ぶ。しかしながら、サイロ化されたカスタムソフトウェアアプリケーションの急増は、多くの欠点を有する。そのことは、その動作を運営及び拡大し、革新し、規制要件を満たす企業の能力に悪影響を及ぼす。企業は、そのサブシステムとデータとを統合する単一のシステムを欠くことに起因して、その動作を統合、合理化、及び強化することが難しいと感じることがある。

カスタムアプリケーションを効率的に創出するために、企業は、不必要な開発の複雑さを排除する、リモートでホストされたアプリケーションプラットフォームからの利益を得るであろう。そうしたプラットフォームの目標は、ソフトウェアエンジニア及びその他の役割の個人がユニークな高価値の機構の開発に集中し得るように、時間のかかる反復的なアプリケーション開発タスクを削減することであろう。

この目標を達成するために、企業全体のワークフローをインテリジェントに自動化するように、サービスとしてのアプリケーションプラットフォーム（ａＰａａＳ）の概念が導入される。ａＰａａＳシステムは、企業からリモートでホストされるが、安全な接続を介して企業内のデータ、アプリケーション、及びサービスにアクセスし得る。そうしたａＰａａＳシステムは、幾つかの有利な能力及び特徴を有し得る。これらの利点及び特徴は、ＩＴ、ＨＲ、ＣＲＭ、顧客サービス、アプリケーション開発、及びセキュリティに対する企業の動作とワークフローとを改善することが可能であり得る。

ａＰａａＳシステムは、モデルビューコントローラ（ＭＶＣ）アプリケーションの開発及び実行をサポートし得る。ＭＶＣアプリケーションは、情報の表現を、ユーザに情報が提示される方法から分離するために、それらの機能を３つの相互接続された部分（モデル、ビュー、及びコントローラ）に分割し、それによって、効率的なコードの再利用と並列開発とを可能にする。これらのアプリケーションは、ウェブベースであり得、創出、読み出し、更新、削除（ＣＲＵＤ）機能を提供し得る。このことは、新たなアプリケーションが共通のアプリケーションインフラストラクチャ上に構築されることを可能にする。

ａＰａａＳシステムは、グラフィカルユーザインターフェース（ＧＵＩ）開発のためのウィジェットの標準化されたセット等の標準化されたアプリケーションコンポーネントをサポートし得る。このように、ａＰａａＳシステムを使用して構築されたアプリケーションは、共通のルックアンドフィールを有する。他のソフトウェアコンポーネント及びモジュールも標準化され得る。幾つかの場合、このルックアンドフィールは、企業のカスタムロゴ及び／又は配色でブランド化又はスキン化され得る。

ａＰａａＳシステムは、メタデータを使用してアプリケーションの挙動を構成する能力をサポートし得る。このことは、アプリケーションの挙動が特定のニーズに合わせて迅速に適応されることを可能にする。こうしたアプローチは、開発時間を削減し、柔軟性を増加させる。更に、ａＰａａＳシステムは、メタデータの創出と管理とを容易にするＧＵＩツールをサポートし得、したがって、メタデータのエラーを削減する。

ａＰａａＳシステムは、ソフトウェア開発者が望ましくないアプリケーション間の依存性を回避し得るように、アプリケーション間の明確に定義されたインターフェースをサポートし得る。したがって、ａＰａａＳシステムは、永続的な状態情報及びその他のデータが格納されるサービス層を実装し得る。

ａＰａａＳシステムは、その上のアプリケーションが従来のアプリケーション及びサードパーティアプリケーションと相互作用し得るように、統合機構の豊富なセットをサポートし得る。実例として、ａＰａａＳシステムは、従来のＨＲ、ＩＴ、及び会計システムと統合するカスタム社員オンボーディングシステムをサポートし得る。

ａＰａａＳシステムは、企業グレードのセキュリティをサポートし得る。更に、ａＰａａＳシステムはリモートでホストされ得るので、それは、企業内のシステムと、又は企業外でホストされたサードパーティのネットワーク及びサービスと相互作用する場合に、セキュリティ手順を利用すべきである。例えば、ａＰａａＳシステムは、一般的なセキュリティの脅威を検出及び識別するために、企業及びその他の関係者の間でデータを共有するように構成され得る。

ａＰａａＳシステムのその他の機構、機能、及び利点が存在し得る。この説明は例を目的としており、限定することを意図しない。

ａＰａａＳ開発プロセスの例として、ソフトウェア開発者は、ａＰａａＳシステムを使用して新たなアプリケーションを創出するようにタスクを課され得る。まず、開発者は、アプリケーションが使用するデータのタイプとそれらの間の関係とを特定するデータモデルを定義し得る。その後、ａＰａａＳシステムのＧＵＩを介して、開発者はデータモデルを入力（例えば、アップロード）する。ａＰａａＳシステムは、対応するデータベーステーブル、フィールド、及び関係の全てを自動的に創出し、それらは、オブジェクト指向サービス層を介してその後アクセスされ得る。

また、ａＰａａＳシステムは、クライアント側インターフェース及びサーバ側ＣＲＵＤロジックを備えた完全に機能するＭＶＣアプリケーションをも構築し得る。この生成されたアプリケーションは、ユーザに対して更なる開発の基礎として役立ち得る。有利なことに、開発者は基本的なアプリケーション機能に多くの時間を費やす必要がない。更に、アプリケーションはウェブベースであり得るので、それは、インターネット対応の任意のクライアントデバイスからアクセスされ得る。代替的又は追加的に、実例としてインターネットサービスが利用可能ではない場合、アプリケーションのローカルコピーにアクセスすることが可能であり得る。

ａＰａａＳシステムは、アプリケーションに追加され得る事前定義された機能の豊富なセットをもサポートし得る。これらの機構は、検索、電子メール、テンプレート、ワークフロー設計、レポート、分析、ソーシャルメディア、スクリプト、モバイルフレンドリーな出力、及びカスタマイズされたＧＵＩに対するサポートを含む。

そうしたａＰａａＳシステムは、様々な方法でＧＵＩを表し得る。例えば、ａＰａａＳシステムのサーバデバイスは、ＨＴＭＬとＪＡＶＡＳＣＲＩＰＴ（登録商標）との組み合わせを使用してＧＵＩの表現を生成し得る。ＪＡＶＡＳＣＲＩＰＴ（登録商標）は、クライアント側実行可能コード、サーバ側実行可能コード、又はそれらの両方を含み得る。サーバデバイスは、クライアントデバイスがローカルに定義されたルックアンドフィールに従って画面に表示するように、この表現をクライアントデバイスに送信又は提供し得る。或いは、ＧＵＩの表現は、クライアントデバイスがそこからグラフィカル出力を直接生成するために使用し得る中間形式（例えば、ＪＡＶＡ（登録商標）バイトコード）等の他の形式をとり得る。その他の可能性が存在する。

更に、ボタン、メニュー、タブ、スライダー、チェックボックス、トグル等のＧＵＩ要素とのユーザの相互作用は、それらの“選択”、“アクティブ化”、又は“作動”と称され得る。これらの用語は、ＧＵＩ要素がキーボード、ポインティングデバイス、タッチスクリーン、又は別のメカニズムを介して相互作用されているかどうかに関係なく使用され得る。

ａＰａａＳアーキテクチャは、企業のネットワークと統合され、そうしたネットワークを管理するために使用される場合に、特に強力である。以下の実施形態は、例示的なａＰａａＳシステムのアーキテクチャ及び機能の態様、並びにその機構及び利点を説明する。

ＩＩ． コンピューティングデバイス及びクラウドベースのコンピューティング環境の例
図１は、コンピューティングデバイス１００を例示する簡略化されたブロック図であり、本明細書の実施形態に従って動作するように配置されたコンピューティングデバイス内に含まれ得るコンポーネントの内の幾つかを説明する。コンピューティングデバイス１００は、クライアントデバイス（例えば、ユーザによってアクティブに動作されるデバイス）、サーバデバイス（例えば、クライアントデバイスに計算サービスを提供するデバイス）、又はその他の何らかのタイプの計算プラットフォームであり得る。幾つかのサーバデバイスは、特定の動作を実施するためにクライアントデバイスとして時折動作し得、幾つかのクライアントデバイスはサーバの機構を組み込み得る。

この例では、コンピューティングデバイス１００は、プロセッサ１０２、メモリ１０４、ネットワークインターフェース１０６、及び入力／出力ユニット１０８を含み、それらの全ては、システムバス１１０又は同様のメカニズムによって結合され得る。幾つかの実施形態では、コンピューティングデバイス１００は、他のコンポーネント及び／又は周辺デバイス（例えば、取り外し可能なストレージ及びプリンタ等）を含み得る。

プロセッサ１０２は、中央処理装置（ＣＰＵ）、コプロセッサ（例えば、数学、グラフィクス、又は暗号化コプロセッサ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、及び／又はプロセッサの動作を実施する集積回路若しくはコントローラの形式等の任意のタイプのコンピュータ処理要素の内の１つ以上であり得る。幾つかの場合、プロセッサ１０２は、１つ以上のシングルコアプロセッサであり得る。他の場合、プロセッサ１０２は、複数の独立した処理ユニットを備えた１つ以上のマルチコアプロセッサであり得る。プロセッサ１０２はまた、実行されている命令及び関連データを一時的に格納するためのレジスタメモリ、並びに最近使用された命令及びデータを一時的に格納するためのキャッシュメモリを含み得る。

メモリ１０４は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、及び不揮発性メモリ（例えば、フラッシュメモリ、ハードディスクドライブ、ソリッドステートドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、及び／又はテープストレージ）を含むがそれらに限定されない任意の形式のコンピュータ使用可能メモリであり得る。したがって、メモリ１０４は、メインメモリユニットと長期ストレージとの両方を表す。その他のタイプのメモリは、生体メモリを含み得る。

メモリ１０４は、プログラム命令及び／又はプログラム命令が動作し得るデータを格納し得る。例として、メモリ１０４は、この明細書又は添付の図面に開示する方法、プロセス、又は動作の内の何れかを実行するためにプロセッサ１０２によって命令が実行可能であるように、これらのプログラム命令を非一時的コンピュータ可読媒体上に格納し得る。

図１に示すように、メモリ１０４は、ファームウェア１０４Ａ、カーネル１０４Ｂ、及び／又はアプリケーション１０４Ｃを含み得る。ファームウェア１０４Ａは、コンピューティングデバイス１００の内の幾つか又は全てをブート、さもなければ開始するために使用されるプログラムコードであり得る。カーネル１０４Ｂは、メモリ管理、プロセスのスケジューリング及び管理、入力／出力、並びに通信のためのモジュールを含むオペレーティングシステムであり得る。カーネル１０４Ｂはまた、オペレーティングシステムがコンピューティングデバイス１００のハードウェアモジュール（例えば、メモリユニット、ネットワークインターフェース、ポート、及びバス）と通信することを可能にするデバイスドライバを含み得る。アプリケーション１０４Ｃは、ウェブブラウザ又は電子メールクライアント等の１つ以上のユーザ空間ソフトウェアプログラム、並びにこれらのプログラムにより使用される任意のソフトウェアライブラリであり得る。メモリ１０４はまた、これらの及びその他のプログラム及びアプリケーションにより使用されるデータを格納し得る。

ネットワークインターフェース１０６は、イーサネット（例えば、ファストイーサネット及びギガビットイーサネット等）等の１つ以上の有線インターフェースの形式を取り得る。ネットワークインターフェース１０６はまた、同軸ケーブル若しくは電力線等の１つ以上の非イーサネット媒体を介した、又は同期光ネットワーク（ＳＯＮＥＴ）若しくはデジタル加入者線（ＤＳＬ）技術等の広域媒体を介した通信をサポートし得る。ネットワークインターフェース１０６は更に、ＩＥＥＥ ８０２．１１（Ｗｉｆｉ）、ＢＬＵＥＴＯＯＴＨ（登録商標）、全地球測位システム（ＧＰＳ）、又は広域無線インターフェース等の１つ以上の無線インターフェースの形式を取り得る。しかしながら、他の形式の物理層インターフェース及び他のタイプの標準又は独自仕様の通信プロトコルがネットワークインターフェース１０６を介して使用され得る。更に、ネットワークインターフェース１０６は、複数の物理インターフェースを含み得る。実例として、コンピューティングデバイス１００の幾つかの実施形態は、イーサネット、ＢＬＵＥＴＯＯＴＨ（登録商標）、及びＷｉｆｉインターフェースを含み得る。

入力／出力ユニット１０８は、コンピューティングデバイス１００とのユーザ及び周辺デバイスの相互作用を容易にし得る。入力／出力ユニット１０８は、キーボード、マウス、及びタッチスクリーン等の１つ以上のタイプの入力デバイスを含み得る。同様に、入力／出力ユニット１０８は、スクリーン、モニタ、プリンタ、及び／又は１つ以上の発光ダイオード（ＬＥＤ）等の１つ以上のタイプの出力デバイスを含み得る。追加的又は代替的に、コンピューティングデバイス１００は、例えば、ユニバーサルシリアルバス（ＵＳＢ）又は高品位マルチメディアインターフェース（ＨＤＭＩ）ポートインターフェースを使用して他のデバイスと通信し得る。

幾つかの実施形態では、コンピューティングデバイス１００のような１つ以上のコンピューティングデバイスは、ａＰａａＳアーキテクチャをサポートするように配備され得る。これらのコンピューティングデバイスの正確な物理的な位置、接続、及び構成は、クライアントデバイスにとって不明であり得、及び／又は重要でなくてもよい。したがって、コンピューティングデバイスは、様々なリモートデータセンタの位置にホストされ得る“クラウドベースの”デバイスと称され得る。

図２は、例示的実施形態に従ったクラウドベースのサーバクラスタ２００を描写する。図２では、コンピューティングデバイス（例えば、コンピューティングデバイス１００）の動作は、サーバデバイス２０２、データストレージ２０４、及びルータ２０６の間で分散され得、これらの全ては、ローカルクラスタネットワーク２０８によって接続され得る。サーバクラスタ２００内のサーバデバイス２０２、データストレージ２０４、及びルータ２０６の数は、サーバクラスタ２００に割り当てられたコンピューティングタスク及び／又はアプリケーションに依存し得る。

例えば、サーバデバイス２０２は、コンピューティングデバイス１００の様々なコンピューティングタスクを実施するように構成され得る。したがって、コンピューティングタスクは、サーバデバイス２０２の内の１つ以上の間で分散され得る。これらのコンピューティングタスクが並行して実施され得る範囲で、タスクのこうした分散は、これらのタスクを完了して結果を返すための合計時間を削減し得る。簡単にする目的のために、サーバクラスタ２００及び個々のサーバデバイス２０２の両方は、“サーバデバイス”と称され得る。この命名法は、１つ以上の別個のサーバデバイス、データストレージデバイス、及びクラスタルータがサーバデバイスの動作に関与し得ることを意味すると理解すべきである。

データストレージ２０４は、ハードディスクドライブ及び／又はソリッドステートドライブのグループへの読み出し及び書き込みアクセスを管理するように構成されたドライブアレイコントローラを含むデータストレージアレイであり得る。ドライブアレイコントローラはまた、単独で、又はサーバデバイス２０２と組み合わせて、サーバデバイス２０２の内の１つ以上がデータストレージ２０４のユニットにアクセスすることを妨げるドライブの障害又はその他のタイプの障害から保護するように、データストレージ２０４内に格納されたデータのバックアップ又は冗長コピーを管理するように構成され得る。ドライブ以外のその他のタイプのメモリが使用されてもよい。

ルータ２０６は、サーバクラスタ２００に内部及び外部の通信を提供するように構成されたネットワーク機器を含み得る。例えば、ルータ２０６は、（ｉ）ローカルクラスタネットワーク２０８を介したサーバデバイス２０２とデータストレージ２０４との間のネットワーク通信、及び／又は（ｉｉ）ネットワーク２１２への通信リンク２１０を介したサーバクラスタ２００と他のデバイスとの間のネットワーク通信を提供するように構成された１つ以上のパケットスイッチング及び／又はルーティングデバイス（スイッチ及び／又はゲートウェイを含む）を含み得る。

また、ルータ２０６の構成は、サーバデバイス２０２及びデータストレージ２０４のデータ通信要件、ローカルクラスタネットワーク２０８のレイテンシ及びスループット、通信リンク２１０のレイテンシ、スループット、及びコスト、並びに／又はシステムアーキテクチャのコスト、速度、フォールトトレランス、復元性、効率、及び／若しくはその他の設計目標に寄与し得るその他の要因に少なくとも部分的に基づき得る。

可能な例として、データストレージ２０４は、ストラクチャードクエリ言語（ＳＱＬ）データベース等の任意の形式のデータベースを含み得る。テーブル、アレイ、リスト、ツリー、及びタプル等を含むがこれらに限定されない様々なタイプのデータ構造がこうしたデータベース内に情報を格納し得る。更に、データストレージ２０４内の任意のデータベースは、モノリシックであり得、又は複数の物理デバイスに渡って分散され得る。

サーバデバイス２０２は、データストレージ２０４へデータを送信し、データストレージ２０４からデータを受信するように構成され得る。この送信及び検索は、ＳＱＬクエリ又はその他のタイプのデータベースクエリ、及びそうしたクエリの出力の形式を夫々取り得る。追加のテキスト、画像、ビデオ、及び／又は音声も含まれ得る。更に、サーバデバイス２０２は、受信したデータをウェブページ又はウェブアプリケーション表現に編成し得る。こうした表現は、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張可能マークアップ言語（ＸＭＬ）、又はその他の何らかの標準化された若しくは独自のフォーマット等のマークアップ言語の形式を取り得る。更に、サーバデバイス２０２は、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＰＨＰハイパーテキストプリプロセッサ（ＰＨＰ）、アクティブサーバページ（ＡＳＰ）、及びＪＡＶＡＳＣＲＩＰＴ（登録商標）等であるがこれらに限定されない、様々なタイプのコンピュータ化されたスクリプト言語を実行する能力を有し得る。これらの言語で書き込まれたコンピュータプログラムコードは、クライアントデバイスへのウェブページの提供、及びウェブページとのクライアントデバイスの相互作用を容易にし得る。代替的又は追加的に、ＪＡＶＡ（登録商標）は、ウェブページの生成を容易にするため、及び／又はウェブアプリケーション機能を提供するために使用され得る。

ＩＩＩ． リモートネットワーク管理アーキテクチャの例
図３は、例示的実施形態に従ったリモートネットワーク管理アーキテクチャを描写する。このアーキテクチャは、３つの主要なコンポーネント、管理されたネットワーク３００と、リモートネットワーク管理プラットフォーム３２０と、パブリッククラウドネットワーク３４０とを含み、全てはインターネット３５０を介して接続される。

Ａ． 管理されたネットワーク
管理されたネットワーク３００は、例えば、データの格納と共に、コンピューティング及び通信タスクのためにエンティティによって使用される企業ネットワークであり得る。したがって、管理されたネットワーク３００は、クライアントデバイス３０２、サーバデバイス３０４、ルータ３０６、仮想マシン３０８、ファイアウォール３１０、及び／又はプロキシサーバ３１２を含み得る。クライアントデバイス３０２は、コンピューティングデバイス１００によって具現化され得、サーバデバイス３０４は、コンピューティングデバイス１００又はサーバクラスタ２００によって具現化され得、ルータ３０６は、任意のタイプのルータ、スイッチ、又はゲートウェイであり得る。

仮想マシン３０８は、コンピューティングデバイス１００又はサーバクラスタ２００の内の１つ以上によって具現化され得る。一般的に、仮想マシンは、コンピューティングシステムのエミュレーションであり、物理的コンピュータの機能（例えば、プロセッサ、メモリ、及び通信リソース）を模倣する。サーバクラスタ２００等の１つの物理的コンピューティングシステムは、最大数千の個々の仮想マシンをサポートし得る。幾つかの実施形態では、仮想マシン３０８は、個々の仮想マシンへの物理的コンピューティングリソースの割り当て、並びに性能及びエラーレポートを容易にする集中型サーバデバイス又はアプリケーションによって管理され得る。企業は、必要に応じて効率的にコンピューティングリソースを割り当てるために、仮想マシンをしばしば用いる。仮想化コンピューティングシステムのプロバイダは、ＶＭＷＡＲＥ（登録商標）及びＭＩＣＲＯＳＯＦＴ（登録商標）を含む。

ファイアウォール３１０は、管理されたネットワーク３００から開始される許可された通信を可能にしつつ、管理されたネットワーク３００をその中のデバイス、アプリケーション、及びサービスへの不正なアクセスの試みから保護する１つ以上の特殊なルータ又はサーバデバイスであり得る。ファイアウォール３１０は、侵入検出、ウェブフィルタリング、ウイルススキャン、アプリケーション層ゲートウェイ、及びその他のアプリケーション又はサービスをも提供する。図３に示されていない幾つかの実施形態では、管理されたネットワーク３００は、リモートネットワーク管理プラットフォーム３２０と通信する１つ以上の仮想プライベートネットワーク（ＶＰＮ）ゲートウェイを含み得る（以下を参照）。

管理されたネットワーク３００はまた、１つ以上のプロキシサーバ３１２を含み得る。プロキシサーバ３１２の実施形態は、管理されたネットワーク３００、リモートネットワーク管理プラットフォーム３２０、及びパブリッククラウドネットワーク３４０の間の通信及びデータの移動を容易にするサーバアプリケーションであり得る。特に、プロキシサーバ３１２は、リモートネットワーク管理プラットフォーム３２０の１つ以上の計算インスタンスとの安全な通信セッションを確立及び維持することが可能であり得る。そうしたセッションを介して、リモートネットワーク管理プラットフォーム３２０は、管理されたネットワーク３００及びそのコンポーネントのアーキテクチャ及び構成の態様を発見及び管理することが可能であり得る。可能性としてプロキシサーバ３１２の助けを借りて、リモートネットワーク管理プラットフォーム３２０はまた、管理されたネットワーク３００により使用されるパブリッククラウドネットワーク３４０の態様を発見及び管理することが可能であり得る。

ファイアウォール３１０等のファイアウォールは、そうしたセッションがファイアウォールの背後から（すなわち、管理されたネットワーク３００上のデバイスから）最終的に開始されない限り、又はファイアウォールがセッションをサポートするように明示的に構成されていない限り、典型的には、インターネット３５０を介して着信する全ての通信セッションを拒否する。プロキシサーバ３１２を（例えば、管理されたネットワーク３００内に、ファイアウォール３１０によって保護される）ファイアウォール３１０の背後に配置することによって、プロキシサーバ３１２は、ファイアウォール３１０を通じてこれらの通信セッションを開始することが可能であり得る。したがって、ファイアウォール３１０は、リモートネットワーク管理プラットフォーム３２０からの着信セッションをサポートするように特別に構成される必要がなくてもよく、それによって、管理されたネットワーク３００に対する潜在的なセキュリティリスクを回避する。

幾つかの場合、管理されたネットワーク３００は、僅かなデバイスと少数のネットワークとからなり得る。他の配備では、管理されたネットワーク３００は、複数の物理的な位置に及び得、数百のネットワークと数十万のデバイスとを含み得る。したがって、図３に描写されたアーキテクチャは、桁違いにスケールアップ又はスケールダウンすることが可能である。

更に、管理されたネットワーク３００のサイズ、アーキテクチャ、及び接続に依存して、様々な数のプロキシサーバ３１２がその中に配備され得る。例えば、プロキシサーバ３１２の各々１つは、管理されたネットワーク３００の一部に関してリモートネットワーク管理プラットフォーム３２０と通信することに責任に負い得る。代替的に又は追加的に、２つ以上のプロキシサーバのセットは、負荷分散、冗長性、及び／又は高可用性の目的で、管理されたネットワーク３００のそうした部分に割り当てられ得る。

Ｂ． リモートネットワーク管理プラットフォーム
リモートネットワーク管理プラットフォーム３２０は、ユーザ、特に管理されたネットワーク３００のオペレータにａＰａａＳサービスを提供するホストされた環境である。これらのサービスは、例えば、前述のウェブベースのテクノロジーを使用してウェブベースのポータルの形式を取り得る。したがって、ユーザは、例えば、クライアントデバイス３０２から、又は潜在的に、管理されたネットワーク３００の外部のクライアントデバイスから、リモートネットワーク管理プラットフォーム３２０に安全にアクセスし得る。ウェブベースのポータルを介して、ユーザは、アプリケーションを設計、テスト、及び展開し得、レポートを生成し得、分析を表示し得、その他のタスクを実施し得る。

図３に示すように、リモートネットワーク管理プラットフォーム３２０は、４つの計算インスタンス３２２、３２４、３２６、及び３２８を含む。これらの計算インスタンスの各々は、ａＰａａＳソフトウェアの専用コピーを動作する１つ以上のサーバノード及び／又は１つ以上のデータベースノードを表し得る。物理サーバデバイス及び／又は仮想マシン上のサーバノード及びデータベースノードの配置は柔軟であり得、企業のニーズに応じて変化し得る。組み合わせて、これらのノードは、特定の企業が利用可能であるウェブポータル、サービス、及びアプリケーション（例えば、完全に機能するａＰａａＳシステム）のセットを提供し得る。幾つかの場合、単一の企業は、複数の計算インスタンスを使用し得る。

例えば、管理されたネットワーク３００は、リモートネットワーク管理プラットフォーム３２０の企業顧客であり得、計算インスタンス３２２、３２４、及び３２６を使用し得る。１人の顧客に複数の計算インスタンスを提供する理由は、顧客がそのアプリケーションとサービスを独自に開発、テスト、及び展開したいことである。したがって、計算インスタンス３２２は、管理されたネットワーク３００に関連するアプリケーション開発に専用であり得、計算インスタンス３２４は、これらのアプリケーションのテストに専用であり得、計算インスタンス３２６は、テストされるアプリケーション及びサービスのライブ動作に専用であり得る。計算インスタンスは、ホストインスタンス、リモートインスタンス、顧客インスタンスと称され得、又はその他の指定により称され得る。計算インスタンスに展開されるアプリケーションは、計算インスタンス内のデータベースへのアクセスをその中の幾つかの要素（例えば、１つ以上の特定のデータベーステーブル又は１つ以上のデータベーステーブル内の特定の行）に制限し得るいう点で、スコープ付きアプリケーションであり得る。

明確にするために、本明細書の開示は、アプリケーションノード、データベースノード、それら上で実行されるａＰａａＳソフトウェア、及び“計算インスタンス”としての基礎となるハードウェアの配置を指す。ユーザは、それによって提供されるグラフィカルユーザインターフェースを口語的に“インスタンス”と称し得ることに留意されたい。しかしながら、本明細書で別段の定義がない限り、“計算インスタンス”は、リモートネットワーク管理プラットフォーム３２０内に配備されたコンピューティングシステムである。

リモートネットワーク管理プラットフォーム３２０のマルチインスタンスアーキテクチャは、マルチインスタンスアーキテクチャが幾つかの利点を示す従来のマルチテナントアーキテクチャとは対照的である。マルチテナントアーキテクチャでは、異なる顧客（例えば、企業）からのデータが単一のデータベースに混合される。これらの顧客のデータは相互に分離されるが、該分離は単一のデータベースを動作するソフトウェアによって実施される。結果として、このシステムにおけるセキュリティ違反は、全ての顧客のデータに影響を与え得、特に政府、医療、及び／又は金融規制の対象となるエンティティに追加のリスクを創出する。更に、１人の顧客に影響を与える任意のデータベース動作は、そのデータベースを共有する全ての顧客におそらく影響を与えるであろう。したがって、ハードウェア又はソフトウェアのエラーに起因する停止がある場合、この停止はそうした全ての顧客に影響を与える。同様に、１人の顧客のニーズを満たすためにデータベースがアップグレードされる場合、それは、アップグレードプロセス中、全ての顧客にとって利用不可能であろう。多くの場合、共有されるデータベースのサイズに起因して、こうしたメンテナンスウィンドウは長いであろう。

対照的に、マルチインスタンスアーキテクチャは、各顧客に、専用のコンピューティングインスタンス内の独自のデータベースを提供する。このことは、顧客データの混合を防止し、各インスタンスが独立して管理されることを可能にする。例えば、ある顧客のインスタンスがエラー又はアップグレードに起因する停止を経験した場合、他の計算インスタンスは影響を受けない。データベースは１人の顧客のデータのみを含むので、メンテナンスのダウン時間は限定される。更に、マルチインスタンスアーキテクチャのよりシンプルな設計は、各顧客データベース及びインスタンスの冗長コピーが地理的に多様な方法で展開されることを可能にする。このことは、高可用性を容易にし、障害が検出された場合、又はメンテナンスが実施されている場合に、顧客のインスタンスのライブバージョンは移動され得る。

幾つかの実施形態では、リモートネットワーク管理プラットフォーム３２０は、このプラットフォームを動作するエンティティによって制御される１つ以上の中央インスタンスを含み得る。計算インスタンスと同様に、中央インスタンスは、幾つかの物理サーバデバイス又は仮想マシン上に配備された幾つかのアプリケーション及びデータベースノードを含み得る。こうした中央インスタンスは、計算インスタンスの特定の構成、及び計算インスタンスの少なくとも幾つかの間で共有され得るデータのリポジトリとして機能し得る。実例として、計算インスタンス上で発生し得る一般的なセキュリティ脅威の定義、計算インスタンス上で一般的に発見されるソフトウェアパッケージ、及び／又は計算インスタンスに展開され得るアプリケーションに対するアプリケーションストアは、中央インスタンス内に存在し得る。計算インスタンスは、このデータを取得するために、明確に定義されたインターフェースを介して中央インスタンスと通信し得る。

効率的な方法で複数の計算インスタンスをサポートするために、リモートネットワーク管理プラットフォーム３２０は、単一のハードウェアプラットフォーム上に複数のこれらのインスタンスを実装し得る。例えば、ａＰａａＳシステムがサーバクラスタ２００等のサーバクラスタ上に実装される場合、それは、様々な量の計算、ストレージ、及び通信リソースをインスタンス専用にする仮想マシンを動作し得る。しかしながら、サーバクラスタ２００の完全な仮想化は必要なくてもよく、インスタンスを分離するためにその他のメカニズムが使用され得る。幾つかの例では、各インスタンスは、サーバクラスタ２００上に専用のアカウント及び１つ以上の専用のデータベースを有し得る。或いは、計算インスタンス３２２等の計算インスタンスは、複数の物理デバイスに及び得る。

幾つかの場合、リモートネットワーク管理プラットフォーム３２０の単一のサーバクラスタは、複数の独立した企業をサポートし得る。更に、以下で説明するように、リモートネットワーク管理プラットフォーム３２０は、負荷分散、冗長性、及び／又は高可用性を容易にするために、地理的に多様なデータセンタ内に配備された複数のサーバクラスタを含み得る。

Ｃ. パブリッククラウドネットワーク
パブリッククラウドネットワーク３４０は、外部委託された計算、データストレージ、通信、及びサービスホスト動作に使用され得るリモートサーバデバイス（例えば、サーバクラスタ２００等の複数のサーバクラスタ）であり得る。これらのサーバは仮想化され得る（すなわち、サーバは仮想マシンであり得る）。パブリッククラウドネットワーク３４０の例は、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（登録商標）及びＭＩＣＲＯＳＯＦＴ（登録商標）ＡＺＵＲＥ（登録商標）を含み得る。リモートネットワーク管理プラットフォーム３２０と同様に、パブリッククラウドネットワーク３４０をサポートする複数のサーバクラスタは、負荷分散、冗長性、及び／又は高可用性の目的で、地理的に異なる位置に配備され得る。

管理されたネットワーク３００は、そのクライアント及び顧客にアプリケーション及びサービスを展開するために、パブリッククラウドネットワーク３４０の内の１つ以上を使用し得る。実例として、管理されたネットワーク３００がオンライン音楽ストリーミングサービスを提供する場合、パブリッククラウドネットワーク３４０は、音楽ファイルを格納し得、ウェブインターフェース及びストリーミング能力を提供し得る。このようにして、管理されたネットワーク３００の企業は、これらの動作のために独自のサーバを構築及び維持する必要がない。

リモートネットワーク管理プラットフォーム３２０は、仮想マシンとそれらの中の管理されるサービスとを管理されたネットワーク３００に公開するために、パブリッククラウドネットワーク３４０と統合するモジュールを含み得る。モジュールは、ユーザが仮想リソースをリクエストし、割り当てられたリソースを発見し、パブリッククラウドネットワーク３４０に柔軟なレポートを提供することを可能にし得る。この機能を確立するために、管理されたネットワーク３００のユーザは、パブリッククラウドネットワーク３４０を用いてアカウントを最初に確立し、関連付けられたリソースのセットをリクエストし得る。その後、ユーザは、リモートネットワーク管理プラットフォーム３２０の適切なモジュールにアカウント情報を入力し得る。これらのモジュールは、アカウント内の管理可能なリソースを自動的にその後発見し得、使用、性能、及び支払い請求に関連するレポートをも提供し得る。

Ｄ． 通信サポート及びその他の動作
インターネット３５０は、グローバルインターネットの一部分を表し得る。しかしながら、インターネット３５０は、代わりに、プライベートワイドエリア又はローカルエリアパケット交換ネットワーク等の異なるタイプのネットワークを表し得る。

図４は、管理されたネットワーク３００と計算インスタンス３２２との間の通信環境を更に説明し、追加の機構及び代替の実施形態を紹介する。図４では、計算インスタンス３２２は、データセンタ４００Ａ及び４００Ｂに渡って複製されている。これらのデータセンタは、おそらく異なる都市又は異なる国に、相互に地理的に離れていてもよい。各データセンタは、管理されたネットワーク３００及びリモートユーザとの通信を容易にするサポート機器を含む。

データセンタ４００Ａでは、外部デバイスとの間のネットワークトラフィックは、ＶＰＮゲートウェイ４０２Ａ又はファイアウォール４０４Ａの何れかを通じて流れる。ＶＰＮゲートウェイ４０２Ａは、インターネットプロトコルセキュリティ（ＩＰＳＥＣ）又はトランスポートレイヤセキュリティ（ＴＬＳ）等のセキュリティプロトコルを介して、管理されたネットワーク３００のＶＰＮゲートウェイ４１２とピアリングされ得る。ファイアウォール４０４Ａは、ユーザ４１４及びリモートユーザ４１６等の許可されたユーザからのアクセスを可能にし、許可されていないユーザへのアクセスを拒否するように構成され得る。ファイアウォール４０４Ａを介して、これらのユーザは、計算インスタンス３２２、及び可能性としてその他の計算インスタンスにアクセスし得る。ロードバランサ４０６Ａは、計算インスタンス３２２をホストする１つ以上の物理又は仮想サーバデバイス間でトラフィックを分散するために使用され得る。ロードバランサ４０６Ａは、データセンタ４００Ａ（例えば、計算インスタンス３２２）の内部構成をクライアントデバイスから隠すことによってユーザアクセスを単純化し得る。実例として、計算インスタンス３２２が、複数のデータベースへのアクセスを共有する複数の物理的又は仮想コンピューティングデバイスを含む場合、ロードバランサ４０６Ａは、あるコンピューティングデバイス又はデータベースがその他よりも著しく多忙にならないように、ネットワークトラフィック及び処理タスクをこれらのコンピューティングデバイス及びデータベースに渡って分散し得る。幾つかの実施形態では、計算インスタンス３２２は、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、及びロードバランサ４０６Ａを含み得る。

データセンタ４００Ｂは、データセンタ４００Ａ内のコンポーネントの独自のバージョンを含み得る。したがって、ＶＰＮゲートウェイ４０２Ｂ、ファイアウォール４０４Ｂ、及びロードバランサ４０６Ｂは、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、及びロードバランサ４０６Ａと同じ又は同様の動作を夫々実施し得る。更に、リアルタイム又は凡そリアルタイムのデータベースの複製及び／又はその他の動作を介して、計算インスタンス３２２は、データセンタ４００Ａ及び４００Ｂ内に同時に存在し得る。

図４に示すようなデータセンタ４００Ａ及び４００Ｂは、冗長性及び高可用性を容易にし得る。図４の構成では、データセンタ４００Ａはアクティブであり、データセンタ４００Ｂはパッシブである。したがって、データセンタ４００Ａは、管理されたネットワーク３００との間の全てのトラフィックに仕えているが、データセンタ４００Ｂ内の計算インスタンス３２２のバージョンは、凡そリアルタイムで更新されている。両方のデータセンタがアクティブな構成等、その他の構成がサポートされ得る。

データセンタ４００Ａが何らかの方法で故障するか、さもなければユーザにとって利用不可能になった場合、データセンタ４００Ｂがアクティブなデータセンタとして引き継ぎ得る。例えば、計算インスタンス３２２のドメイン名をデータセンタ４００Ａの１つ以上のインターネットプロトコル（ＩＰ）アドレスと関連付けるドメイン名システム（ＤＮＳ）サーバは、ドメイン名をデータセンタ４００Ｂの１つ以上のＩＰアドレスと関連付け直し得る。この関連付け直しが完了した後（これには１秒又は数秒未満かかり得る）、ユーザは、データセンタ４００Ｂを介して計算インスタンス３２２にアクセスし得る。

図４はまた、管理されたネットワーク３００の可能な構成を説明する。上記のように、プロキシサーバ３１２及びユーザ４１４は、ファイアウォール３１０を通じて計算インスタンス３２２にアクセスし得る。プロキシサーバ３１２はまた、構成アイテム４１０にアクセスし得る。図４では、構成アイテム４１０は、クライアントデバイス３０２、サーバデバイス３０４、ルータ３０６、及び仮想マシン３０８の内の何れか又は全て、それらの上で実行する任意のアプリケーション又はサービス、並びにデバイス、アプリケーション、及びサービス間の関係の内の何れか又は全てを指し得る。したがって、用語“構成アイテム”は、任意の物理デバイス若しくは仮想デバイス、又は計算インスタンス３２２によりリモートで発見可能な又は管理される任意のアプリケーション若しくはサービス、又は発見されたデバイス、アプリケーション、及びサービス間の関係の省略表現であり得る。構成アイテムは、計算インスタンス３２２の構成管理データベース（ＣＭＤＢ）内で表され得る。

上記のように、ＶＰＮゲートウェイ４１２は、ＶＰＮゲートウェイ４０２Ａに、専用のＶＰＮを提供し得る。こうしたＶＰＮは、管理されたネットワーク３００と計算インスタンス３２２との間に大量のトラフィックがある場合、又はセキュリティポリシーがこれらのサイト間のＶＰＮの使用を提案する又は必要とする場合に役立ち得る。幾つかの実施形態では、ＶＰＮを介して直接通信する、管理されたネットワーク３００及び／又は計算インスタンス３２２内の任意のデバイスには、パブリックＩＰアドレスが割り当てられる。管理されたネットワーク３００及び／又は計算インスタンス３２２内のその他のデバイスには、プライベートＩＰアドレス（例えば、サブネット１０．０．０．０／８及び１９２．１６８．０．０／１６として夫々省略表現で表される、１０．０．０．０～１０．２５５．２５５．２５５又は１９２．１６８．０．０～１９２．１６８．２５５．２５５の範囲から選択されるＩＰアドレス）が割り当てられ得る。

ＩＶ． デバイス、アプリケーション、及びサービス発見の例
リモートネットワーク管理プラットフォーム３２０が、管理されたネットワーク３００のデバイス、アプリケーション、及びサービスを管理するために、リモートネットワーク管理プラットフォーム３２０は、如何なるデバイスが管理されたネットワーク３００内に存在するか、これらのデバイスの構成及び動作ステータス、並びにデバイスにより提供されるアプリケーション及びサービス、並びに発見されたデバイス、アプリケーション、及びサービス間の関係をまず判定し得る。上記のように、各デバイス、アプリケーション、サービス、及び関係は、構成アイテムと称され得る。管理されたネットワーク３００内で構成アイテムを定義するプロセスは、発見と称され、プロキシサーバ３１２によって少なくとも部分的に容易にされ得る。

本明細書の実施形態の目的のために、“アプリケーション”は、１つ以上のプロセス、スレッド、プログラム、クライアントモジュール、サーバモジュール、又はデバイス若しくはデバイスのグループ上で実行する任意のその他のソフトウェアを指し得る。“サービス”は、相互に連携して働く１つ以上のデバイス上で実行する複数のアプリケーションによって提供される高レベルの能力を指し得る。例えば、高レベルのウェブサービスは、あるデバイス上で実行する複数のウェブアプリケーションサーバスレッドと、別のデバイス上で実行するデータベースアプリケーションからのアクセス情報とを含み得る。

図５Ａは、構成アイテムがどのように発見され得るか、並びに発見された構成アイテムに関連する情報がどのように格納され得るかについての論理的描写を提供する。簡単にするために、リモートネットワーク管理プラットフォーム３２０、パブリッククラウドネットワーク３４０、及びインターネット３５０は示されていない。

図５Ａでは、ＣＭＤＢ５００及びタスクリスト５０２は、計算インスタンス３２２内に格納される。計算インスタンス３２２は、発見コマンドをプロキシサーバ３１２へ送信し得る。応答において、プロキシサーバ３１２は、管理されたネットワーク３００内の様々なデバイス、アプリケーション、及びサービスへプローブを送信し得る。これらのデバイス、アプリケーション、及びサービスは、プロキシサーバ３１２へ応答を送信し得、プロキシサーバ３１２は、発見された構成アイテムに関する情報を、その中への格納のためにＣＭＤＢ５００にその後提供し得る。ＣＭＤＢ５００内に格納された構成アイテムは、管理されたネットワーク３００の環境を表す。

タスクリスト５０２は、プロキシサーバ３１２が計算インスタンス３２２に代わって実施する活動のリストを表す。発見が行われると、タスクリスト５０２はポピュレートされる。プロキシサーバ３１２は、タスクリスト５０２を繰り返し照会し、その中の次のタスクを取得し、タスクリスト５０２が空になる、又は別の停止条件に達するまで、このタスクを実施する。

発見を容易にするために、プロキシサーバ３１２は、プロキシサーバ３１２を介して到達可能な管理されたネットワーク３００内の１つ以上のサブネットに関する情報で構成され得る。実例として、プロキシサーバ３１２には、サブネットとしてＩＰアドレス範囲１９２．１６８．０／２４が与えられ得る。その後、計算インスタンス３２２は、この情報をＣＭＤＢ５００内に格納し得、これらのアドレスの各々でのデバイスの発見のためにタスクリスト５０２内にタスクを配置し得る。

図５Ａはまた、構成アイテム５０４、５０６、５０８、５１０、及び５１２として、管理されたネットワーク３００内のデバイス、アプリケーション、及びサービスを描写する。上記のように、これらの構成アイテムは、物理及び／又は仮想デバイス（例えば、クライアントデバイス、サーバデバイス、ルータ、又は仮想マシン）、それらの上で実行するアプリケーション（例えば、ウェブサーバ、電子メールサーバ、データベース、又はストレージアレイ）、それらの間の関係、並びに複数の個々の構成アイテムを含むサービスのセットを表す。

タスクをタスクリスト５０２内に配置することは、発見を発動し得、さもなければプロキシサーバ３１２に発見を開始させ得る。代替的又は追加的に、発見は、手動で発動され得、又は発動イベントに基づいて自動的に発動され得る（例えば、発見は、特定の時間に１日１回自動的に開始し得る）。

一般的に、発見は、スキャン、分類、識別、及び探索の４つの論理フェーズで進行し得る。発見の各フェーズは、プロキシサーバ３１２によって、管理されたネットワーク３００内の１つ以上のデバイスへ送信される様々なタイプのプローブメッセージを含む。これらのプローブへの応答は、プロキシサーバ３１２によって受信及び処理され得、それらの表現はＣＭＤＢ５００へ送信され得る。したがって、各フェーズは、より多くの構成アイテムが発見され、ＣＭＤＢ５００内に格納されることをもたらし得る。

スキャンフェーズにおいて、プロキシサーバ３１２は、デバイスの一般的なタイプを判定するために、オープンな伝送制御プロトコル（ＴＣＰ）及び／又はユーザデータグラムプロトコル（ＵＤＰ）ポートに対する指定された範囲のＩＰアドレス内の各ＩＰアドレスを精査し得る。ＩＰアドレスにおけるこうしたオープンなポートの存在は、ＩＰアドレスが割り当てられるデバイス上で特定のアプリケーションが動作していることを指し示し得、このことは、順に、デバイスにより使用されるオペレーティングシステムを識別し得る。例えば、ＴＣＰポート１３５がオープンである場合、デバイスはＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムを実行している可能性がある。同様に、ＴＣＰポート２２がオープンである場合、デバイスはＬＩＮＵＸ（登録商標）等のＵＮＩＸ（登録商標）オペレーティングシステムを実行している可能性がある。ＵＤＰポート１６１がオープンである場合、デバイスは簡易ネットワーク管理プロトコル（ＳＮＭＰ）を通じて更に識別可能であり得る。その他の可能性が存在する。特定のＩＰアドレスとそのオープンなポートとにおけるデバイスの存在が一旦発見されると、これらの構成アイテムはＣＭＤＢ５００内に保存される。

分類フェーズにおいて、プロキシサーバ３１２は、そのオペレーティングシステムのバージョンを判定するために、発見された各デバイスを更に精査し得る。特定のデバイスに対して使用されるプローブは、スキャンフェーズ中にデバイスについて収集された情報に基づく。例えば、ＴＣＰポート２２がオープンであるデバイスが見つかった場合、ＵＮＩＸ（登録商標）固有のプローブのセットが使用され得る。同様に、ＴＣＰポート１３５がオープンであるデバイスが見つかった場合、ＷＩＮＤＯＷＳ（登録商標）固有のプローブのセットが使用され得る。何れの場合にも、プロキシサーバ３１２が実行するために、タスクの適切なセットがタスクリスト５０２内に配置され得る。これらのタスクは、プロキシサーバ３１２がログオンすること、さもなければ特定のデバイスからの情報にアクセスすることをもたらし得る。実例として、ＴＣＰポート２２がオープンである場合、プロキシサーバ３１２は、特定のデバイスへのセキュアシェル（ＳＳＨ）接続を開始して、ファイルシステム内の特定の位置からその上のオペレーティングシステムについての情報を取得するように命令され得る。この情報に基づいて、オペレーティングシステムが判定され得る。例として、ＴＣＰポート２２がオープンであるＵＮＩＸ（登録商標）デバイスは、ＡＩＸ（登録商標）、ＨＰＵＸ、ＬＩＮＵＸ（登録商標）、ＭＡＣＯＳ（登録商標）、又はＳＯＬＡＲＩＳ（登録商標）として分類され得る。この分類情報は、１つ以上の構成アイテムとしてＣＭＤＢ５００内に格納され得る。

識別フェーズにおいて、プロキシサーバ３１２は、分類されたデバイスについての具体的詳細を判定し得る。このフェーズ中に使用されるプローブは、分類フェーズ中に特定のデバイスについて収集された情報に基づき得る。例えば、デバイスがＬＩＮＵＸ（登録商標）として分類された場合、ＬＩＮＵＸ（登録商標）固有のプローブのセットが使用され得る。同様に、デバイスがＷＩＮＤＯＷＳ（登録商標）２０１２として分類された場合、ＷＩＮＤＯＷＳ（登録商標）２０１２固有のプローブのセットとして使用され得る。分類フェーズの場合と同様に、プロキシサーバ３１２が実行するために、タスクの適切なセットがタスクリスト５０２内に配置され得る。これらのタスクは、ベーシック入力／出力システム（ＢＩＯＳ）情報、シリアル番号、ネットワークインターフェース情報、これらのネットワークインターフェースに割り当てられたメディアアクセス制御アドレス、及び特定のデバイスにより使用されるＩＰアドレス等の情報を特定のデバイスからプロキシサーバ３１２が読み出すことをもたらし得る。この識別情報は、１つ以上の構成アイテムとしてＣＭＤＢ５００内に格納され得る。

探索フェーズにおいて、プロキシサーバ３１２は、分類されたデバイスの動作状態についての更なる詳細を判定し得る。このフェーズ中に使用されるプローブは、分類フェーズ及び／又は識別フェーズ中に特定のデバイスについて収集された情報に基づき得る。この場合も、プロキシサーバ３１２が実行するために、タスクの適切なセットがタスクリスト５０２内に配置され得る。これらのタスクは、プロセッサ情報、メモリ情報、及び実行中のプロセス（アプリケーション）のリスト等の追加情報を特定のデバイスからプロキシサーバ３１２が読み出すことをもたらし得る。再度、発見された情報は、１つ以上の構成アイテムとしてＣＭＤＢ５００内に格納され得る。

ルータ等のネットワークデバイス上で発見を実行することは、ＳＮＭＰを利用し得る。実行中のプロセス又はその他のアプリケーション関連情報のリストを判定することの代わりに、又はそのことに加えて、発見は、ルータに認識されている追加のサブネットと、ルータのネットワークインターフェースの動作状態（例えば、アクティブ、非アクティブ、キューの長さ、ドロップしたパケット数等）とを判定し得る。追加のサブネットのＩＰアドレスは、更なる発見手順に対する候補であり得る。したがって、発見は、反復的又は再帰的に進行し得る。

発見が一旦完了すると、発見された各デバイス、アプリケーション、及びサービスのスナップショット表現がＣＭＤＢ５００内で利用可能である。例えば、発見後、管理されたネットワーク３００内のクライアントデバイス、サーバデバイス、及びルータに対するオペレーティングシステムのバージョン、ハードウェア構成、及びネットワーク構成の詳細、並びにそれらの上で実行するアプリケーションが格納され得る。この収集された情報は、デバイスのハードウェア構成及び動作ステータス、並びに複数のデバイス及びアプリケーションに及ぶサービスの特徴をユーザが見ることを可能にするように、様々な方法でユーザに提示され得る。

更に、ＣＭＤＢ５００は、構成アイテム間の依存性及び関係に関するエントリを含み得る。より具体的には、特定のサーバデバイス上で実行しているアプリケーション、及びこのアプリケーションに依存するサービスは、ＣＭＤＢ５００内等で表され得る。例えば、データベースアプリケーションがサーバデバイス上で実行していると仮定し、並びにこのデータベースアプリケーションが新入社員オンボーディングサービス及び給与サービスにより使用されると仮定する。したがって、サーバデバイスがメンテナンスのために動作を停止した場合、社員オンボーディングサービス及び給与サービスが影響を受けるであろうことは明らかである。同様に、構成アイテム間の依存性及び関係は、特定のルータが故障した場合に影響を受けるサービスを表すことが可能であり得る。

一般的に、構成アイテム間の依存性及び関係は、ウェブベースのインターフェース上に表示され得、階層的方法で表され得る。したがって、こうした依存性及び関係の追加、変更、又は削除は、このインターフェースを介して達成され得る。

更に、管理されたネットワーク３００からのユーザは、ある一定の調整された活動が複数の発見されたデバイスに渡って行われることを可能にするワークフローを開発し得る。実例として、ＩＴワークフローは、単一の動作で、全ての発見されたＬＩＮＵＸ（登録商標）デバイスに共通の管理者パスワードをユーザが変更することを可能にし得る。

上で説明した方法で発見が行われるために、プロキシサーバ３１２、ＣＭＤＢ５００、及び／又は１つ以上のクレデンシャルストアは、発見されるデバイスの内の１つ以上に対するクレデンシャルで構成され得る。クレデンシャルは、デバイスにアクセスするために必要な任意のタイプの情報を含み得る。これらは、ユーザＩＤ／パスワードの対及び資格証明書等を含み得る。幾つかの実施形態では、これらのクレデンシャルは、ＣＭＤＢ５００の暗号化されたフィールド内に格納され得る。プロキシサーバ３１２は、発見されているデバイスにログオンするため、さもなければアクセスするためにこれらのクレデンシャルをプロキシサーバ３１２が使用し得るように、クレデンシャルに対する復号化キーを含み得る。

発見プロセスは、図５Ｂにフローチャートとして描写されている。ブロック５２０において、計算インスタンス内のタスクリストは、実例として、ＩＰアドレスの範囲でポピュレートされる。ブロック５２２において、スキャンフェーズが行われる。したがって、プロキシサーバは、これらのＩＰアドレスを使用してデバイスに対するＩＰアドレスを精査し、これらのデバイス上で実行しているオペレーティングシステムの判定を試みる。ブロック５２４において、分類フェーズが行われる。プロキシサーバは、発見されたデバイスのオペレーティングシステムのバージョンの判定を試みる。ブロック５２６において、識別フェーズが行われる。プロキシサーバは、発見されたデバイスのハードウェア及び／又はソフトウェア構成の判定を試みる。ブロック５２８において、探索フェーズが行われる。プロキシサーバは、発見されたデバイス上で実行している動作状態及びアプリケーションの判定を試みる。ブロック５３０において、発見されたデバイス及びアプリケーションを表す構成アイテムの更なる編集が行われ得る。この編集は、本質的に自動化され得、及び／又は手動で行われ得る。

図５Ｂに表したブロックは例である。発見は、より多くの又はより少ないフェーズを有し得る高度に構成可能な手順であり得、各フェーズの動作は変更し得る。幾つかの場合、１つ以上のフェーズがカスタマイズされ得、さもなければ上記の例示的な説明から逸脱し得る。

このようにして、リモートネットワーク管理プラットフォームは、管理されたネットワーク上に展開され、管理されたネットワークによって提供されるハードウェア、ソフトウェア、及びサービスを発見し得、インベントリし得る。上記のように、このデータは、構成アイテムとして、関連する計算インスタンスのＣＭＤＢ内に格納され得る。例えば、個々のハードウェアコンポーネント（例えば、コンピューティングデバイス、仮想サーバ、データベース、ルータ等）はハードウェア構成アイテムとして表され得る一方、その上にインストール及び／又は実行されるアプリケーションはソフトウェア構成アイテムとして表され得る。

ハードウェア構成アイテムにインストール又は実行されるソフトウェア構成アイテム間の関係は、“ホストされる”、“実行される”、又は“依存する”等の様々な形式を取り得る。したがって、サーバデバイス上にインストールされたデータベースアプリケーションは、データベースアプリケーションがサーバデバイス上にホストされることを指し示すために、サーバデバイスと“ホストされる”関係を有し得る。幾つかの実施形態では、サーバデバイスがデータベースアプリケーションにより使用されることを指し示すために、サーバデバイスは、データベースアプリケーションにより“使用される”相互関係を有し得る。これらの関係は、上に説明した発見手順を使用して自動的に見つけられ得るが、手動で関係をセットすることも可能であり得る。

サービスと１つ以上のソフトウェア構成アイテムとの関係も様々な形式を取り得る。一例として、ウェブサービスは、ウェブサーバソフトウェア構成アイテム及びデータベースアプリケーションソフトウェア構成アイテムを含み得、異なるハードウェア構成アイテムに各々インストールされる。ウェブサービスは、これらのソフトウェア構成アイテムの両方と“依存する”関係を有し得る一方、ソフトウェア構成アイテムは、ウェブサービスと“使用される”相互関係を有する。サービスは、発見手順により完全には判定可能ではないことがあり、代わりに、サービスマッピング（例えば、構成アイテム間のサービスレベルの関係を判定するために、構成ファイルを精査すること及び／又はネットワークトラフィック分析を実行すること）及び可能性としてある程度の手動構成に依存し得る。

関係情報がどのように取得されるかに関係なく、それは、管理されたネットワークの動作にとって価値がある。特に、ＩＴ担当者は、幾つかのソフトウェアアプリケーションが展開されている場所、及びどの構成アイテムがサービスを構成しているかを迅速に判定し得る。このことは、サービスの停止又は低下の根本原因を迅速に特定可能である。例えば、２つの異なるサービスが遅い応答時間に悩まされる場合、両サービスが高いプロセッサの利用を有することにより使用されるデータベースアプリケーションが根本的な原因であると判定するために、（おそらく他のアクティビティの中でも）ＣＭＤＢが照会され得る。したがって、ＩＴ担当者は、サービスを構成する他の構成アイテムの正常性及び性能を考慮する時間を無駄にすることなく、データベースアプリケーションに対処し得る。

Ｖ. クラウドベースのコンピューティングサービスの例
前述したように、クラウドコンピューティングプロバイダは、コンピューティングサービス（データベース、仮想マシン、ソフトウェアアプリケーション、及び／又はその他のサービス）を静的に又はオンデマンドでユーザがリモートで利用可能し得る。これらのコンピューティングサービスは、オンラインデータストレージサービス、ドキュメントコラボレーションサービス、仮想マシンサービス、及びウェブホスティングサービス等を含み得る。クラウドコンピューティングプロバイダはコンピューティングサービスに必要なハードウェア及びソフトウェアを提供するため、管理されたネットワークは、コンピューティングサービスを管理するために独自のインフラストラクチャをプロビジョニング又は展開するために時間を費やす必要がなくてもよい。

クラウドコンピューティングプロバイダは、パブリッククラウドネットワーク３４０の文脈で上で論じられた。したがって、クラウドコンピューティングプロバイダ（ここでは“リモートネットワーク”と称され得る）の例には、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（登録商標）、ＭＩＣＲＯＳＯＦＴ（登録商標）ＡＺＵＲＥ（登録商標）、ＩＢＭ ＣＬＯＵＤ（登録商標）、ＤＲＯＰＢＯＸ（登録商標）、及びＳＬＡＣＫ ＴＥＣＨＮＯＬＯＧＩＥＳ（登録商標）を含み得る。これらのクラウドコンピューティングプロバイダにより利用可能にされるコンピューティングサービスの例は、ＡＭＡＺＯＮ ＡＵＲＯＲＡ（登録商標）（リレーショナルデータベース管理サービス）、ＡＺＵＲＥ（登録商標）Ｂｌｏｂ Ｓｔｏｒａｇｅ（非構造化データストレージサービス）、及びＳＬＡＣＫ（登録商標）（コラボレーティブメッセージングサービス）等を含み得る。その他のクラウドコンピューティングプロバイダ及びコンピューティングサービスが存在し得る。

追加の動作に対する需要の増加に対応するために、クラウドコンピューティングプロバイダは、コンピューティングサービスの提供を定期的に更新し得る。すなわち、クラウドコンピューティングプロバイダは、新たなコンピューティングサービスを開発し得、古いコンピューティングサービスを調整し得、古いコンピューティングサービスを削除し得る。こうした更新は、毎週、数ヶ月毎、又は毎年発生し得る。また、新たなコンピューティングサービスの異なるセットを各々提供する新たなクラウドコンピューティングプロバイダが設立され得る。

管理されたネットワーク３００は、新たなコンピューティングサービス及び／又は新たなクラウドコンピューティングプロバイダにより提供される機能を利用可能であることが有利であり得る。更に、情報技術サービス及び運用管理、ソフトウェア資産管理、並びに／又はその他の様々なネットワークサービス及び運用へのより大きなコンテンツを獲得するように、管理されたネットワーク３００がこれらの新たなコンピューティングサービスの消費を監視することが有利であり得る。更に、リモートネットワーク管理プラットフォーム３２０を操作するエンティティは、管理されたネットワーク３００に代わって、これらの新たなコンピューティングサービス及び／又は新たなクラウドコンピューティングプロバイダと相互作用することが望ましいことがある。

それでも、新たなコンピューティングサービスと相互作用するようにリモートネットワーク管理プラットフォーム３２０を構成することは難しいことがある。コンピューティングサービスは明確な構成の詳細をしばしば有するので、新たなコンピューティングサービスのためのサポートを追加するには、アプリケーション開発者のチームが、これらの明確な構成の詳細をリモートネットワーク管理プラットフォーム３２０に組み込むカスタムソフトウェアを創出することを伴い得る。開発プロセスは厳密な統合テストを含み得るので、これには数週間又は数ヶ月かかり得る。また、リモートネットワーク管理プラットフォーム３２０が複数の新たなコンピューティングサービスと相互作用する場合、プロセスは過度に時間がかかり得る。

この問題又はその他の問題に対処するために、リモートネットワーク管理プラットフォーム３２０を操作するエンティティは、新たなコンピューティングサービス及び／又は新たなクラウドコンピューティングプロバイダと迅速に統合するためのクラウド統合アプリケーションを提供し得る。有利には、そうしたクラウド統合アプリケーションは、管理されたネットワーク３００により提供される仕様を介して構成可能であり得、カスタムソフトウェアを開発する必要をなくす。一旦構成されると、クラウド統合アプリケーションは、リモートネットワーク管理プラットフォーム３２０が、新たなコンピューティングサービス及び／又はクラウドコンピューティングプロバイダと相互作用すること／それらの消費情報を取得することを可能にし得る。取得された消費情報は、後で分析するために、ＣＭＤＢ５００又はリモートネットワーク管理プラットフォーム３２０上の別のデータベース内にその後ポピュレートされ得る。

コンピューティングサービスと相互作用するための本明細書の実施形態を使用することによって、クラウド統合アプリケーションは、“コンピューティングサービスニュートラル”（本明細書ではＣＳＮと短縮される）とみなされ得る。これは、クラウド統合アプリケーションが、コンピューティングサービス及び／又はクラウドコンピューティングプロバイダ上に特定の構成の詳細を含まず、むしろ、クラウド統合アプリケーションが実行される場合に管理されたネットワーク３００又は別のエンティティからこれらの詳細を取得するためでる。この特徴のため、クラウド統合アプリケーションは“コンピューティングサービスニュートラル（ＣＳＮ）クラウド統合アプリケーション”と称され得る。

図６は、例示的実施形態に従ったネットワークアーキテクチャ６００を描写する。ネットワークアーキテクチャ６００は、３つの主要な構成要素、管理されたネットワーク３００、計算インスタンス３２２、及びクラウドコンピューティングプロバイダ６１０を含み、全ては、インターネット３５０等のネットワークを介して通信可能に接続される。上記のように、クラウドコンピューティングプロバイダ６１０は、パブリッククラウドネットワーク３４０について論じたプロパティの内の幾つか又は全部を請け得る。

計算インスタンス３２２は、リモートネットワーク管理プラットフォーム３２０内に配備され得、管理されたネットワーク３００に専用であり得る。計算インスタンス３２２は、管理されたネットワーク３００の環境を表す発見された構成アイテムをＣＭＤＢ５００内に格納し得る。また、計算インスタンス３２２は、計算インスタンス３２２をクラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスと統合するために使用されるコンピューティングサービスニュートラル（ＣＳＮ）クラウド統合アプリケーション６２０を含み得る。統合時に、計算インスタンス３２２は、クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスの使用量、性能、及び課金統計を含む消費情報を取得し得る。

管理されたネットワーク３００は、データの記憶だけではなく、コンピューティング及び通信タスクのためにエンティティにより使用される企業ネットワークであり得る。例では、管理されたネットワーク３００は、クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスの内の１つ以上の加入者であり得る。これらは、計算、データストレージ、通信、及び／又はホスティングサービスを含み得る。実例として、管理されたネットワーク３００がオンライン音楽ストリーミングサービスを提供する場合、音楽ファイルを格納するコンピューティングサービスが使用され得る。管理されたネットワーク３００は、１つ以上のプロキシサーバ３１２を含み得る。おそらくプロキシサーバ３１２の助けを借りて、計算インスタンス３２２は、管理されたネットワーク３００によって使用される、クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスと統合し得る。

クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスを使用するために、管理されたネットワーク３００は、最初に、コンピューティングサービスの内の１つ以上がリクエストされるクラウドコンピューティングプロバイダ６１０の各々とのアカウントを確立し得る。アカウントを確立した後、管理されたネットワーク３００は、ＣＳＮクラウド統合アプリケーション６２０が統合することを望むであろうコンピューティングサービスのサブセットを指定し得る。実例として、管理されたネットワーク３００は、これらのアカウントと関連付けられたデータベースサービスのみと統合することに関心があり得る。このことを行うために、管理されたネットワーク３００は、ＣＳＮクラウド統合アプリケーション６２０に仕様６３０を提供し得る。

仕様６３０は、クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスのためのアカウント情報の詳細（例えば、パスワード、ユーザ名）及びアクセスの詳細を含むファイル、データベーステーブル、又は関連のセットであり得る。実例として、コンピューティングサービスがＡＰＩエンドポイント等の統合ポイントを通じてアクセスされ得ると仮定すると、仕様６３０は、コンピューティングサービスのためのＡＰＩエンドポイントのリストを含み得る。例では、これらのＡＰＩエンドポイントは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ＡＰＩ、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）ＡＰＩ、ＧｒａｐｈＱＬ ＡＰＩ、又はその他のタイプのＡＰＩアーキテクチャを含み得る。ＣＳＮクラウド統合アプリケーション６２０は、Ｈｙｐｔｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）、Ｈｙｐｔｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、又はその他のアプリケーション層プロトコルを介してこれらのＡＰＩエンドポイントを照会し得る。また、仕様６３０は、クラウドコンピューティングプロバイダ６１０から受信したコンピューティングサービスの記述とＣＭＤＢ５００内の構成アイテムとの間の１つ以上のマッピングを含み得る。これらのマッピングは、クラウドコンピューティングプロバイダ６１０から受信した記述（例えば、消費情報）がＣＭＤＢ５００又は別のデータベースの特定のフィールド及びテーブルに正しく格納されることを確実にするために使用され得る。例示的実施形態では、コンピューティングサービスの記述は、ＸＭＬ、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、又はＹＡＭＬ Ａｉｎ´t Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＹＡＭＬ）形式であり得る。

仕様６３０が一旦提供されると、ＣＳＮクラウド統合アプリケーション６２０は、クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスと相互作用し始め得る。有利には、管理されたネットワーク３００がクラウドコンピューティングプロバイダ６１０により提供される新たなコンピューティングサービスの使用を開始した場合、計算インスタンス３２２又はＣＳＮクラウド統合アプリケーション６２０への追加のソフトウェアの更新は必要でなくてもよい。むしろ、管理されたネットワーク３００は、（例えば、ＧＵＩを介して）仕様６３０を単に更新し得、ＣＳＮクラウド統合アプリケーション６２０は、それに応じて構成され得る。

時折、クラウドコンピューティングプロバイダ６１０は、コンピューティングサービスの記述を複数の統合ポイントに分割する。すなわち、単一の統合ポイント（例えば、単一のＡＰＩエンドポイント）を介して記述を提供する代わりに、クラウドコンピューティングプロバイダは、記述を複数の統合ポイント（例えば、複数のＡＰＩエンドポイント）に分割し得、それらの各々は、“ページ”として知られている。この技法は、コンピューティングサービスの記述が過度に大きい場合に一般的である。したがって、コンピューティングサービスの完全な記述を取得するために、複数の統合ポイントの各々（例えば、ページの各々）に対するリクエストがなされるべきである。

記述が複数の統合ポイントに分割されているコンピューティングサービスと統合するために、仕様６３０は“ページネーションタイプ”を含み得る。特に、ユーザは、仕様６３０に第１の統合ポイント及びページネーションタイプを提供し得る。仕様６３０を受信すると、ＣＳＮクラウド統合アプリケーション６２０は、第１の統合ポイントを後続の統合ポイントに変更するために、ページネーションタイプを使用し得る。その後、ＣＳＮクラウド統合アプリケーション６２０は、コンピューティングサービスの完全な記述を取得するために、これらの後続の統合ポイントの各々にリクエストをなし得る。

ページネーションタイプの理念を概念的に説明するために、図７はＵＲＬ７００を描写する。図示するように、ＵＲＬ７００は、スキーム７０２、ホスト７０４、パス７０６、及びクエリ文字列７０８で構成される。

スキーム７０２は、コンピューティングサービスにアクセスするために使用されるプロトコルを識別する。ＵＲＬ７００では、スキーム７０２はＨＴＴＰＳプロトコルが使用されることを示すが、ＨＴＴＰ等のその他のプロトコルも可能である。

ホスト７０４は、コンピューティングサービスを提供するサーバデバイスの名前を識別する。ＵＲＬ７００では、ホスト７０４は“ｆｏｏｂａｒ．ｃｏｍ”がホストであることを示すが、その他のホストも可能である。

パス７０６は、コンピューティングサービスが配置されているサーバデバイス上のパスを識別する。ＵＲＬ７００では、パス７０６は“／ａｐｉ／ｖ２”がパスであることを示すが、その他のパスも可能である。

クエリ文字列７０８は、パス７０６に続くオプションの文字列である。クエリ文字列７０８は、コンピューティングリソースが何らかの目的で使用し得る情報の文字列を提供する。例えば、クエリ文字列７０８は、コンピューティングリソースが検索に使用するパラメータを含み得る。クエリ文字列７０８は、アンパサンドにより各々区切られた名前／値のペアの文字列として構成される。ＵＲＬ７００では、クエリ文字列７０８は、“ｉｄ＝１２３＆ｔｏｋｅｎ＝３２２３”がクエリ文字列であることを示すが、その他のクエリ文字列も可能である。

ここで、ページネーションタイプに戻り、統合ポイントがＵＲＬの形式を取り得ると仮定すると、ページネーションタイプは、一般的に、後続のＵＲＬを取得するために、最初のＵＲＬのパス又はクエリ文字列の何れかを修正する。

特定のクラウドコンピューティングプロバイダがコンピューティングサービスの記述をどのように配置するかに依存して、様々なページネーションタイプが使用され得る。例えば、クラウドコンピューティングプロバイダＡ＿１は、記述を５００個のアイテムページに分割し得る一方、クラウドコンピューティングプロバイダＢ＿１は、記述を１０００個のアイテムページに分割し得る。多種多様な配置をサポートするために、ＣＳＮクラウド統合アプリケーション６２０は、可能性の中でもとりわけ、次のエンドポイントページネーション、次のリンクページネーション、オフセットページネーション、及びページベースのページネーションをサポートし得る。

次のエンドポイントページネーションタイプを使用する場合、管理されたネットワーク３００のユーザは、仕様６３０に新たなパスを提供する。後続の統合ポイントを取得するために、ＣＳＮクラウド統合アプリケーション６２０は、最初の統合ポイントのパスを新たなパスで修正するであろう。例えば、最初の統合ポイントが“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２”の場合、２番目の統合ポイントは“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ３”の形式を取り得る。

次のリンクページネーションタイプを使用する場合、管理されたネットワーク３００のユーザは、仕様６３０に新たなクエリ文字列を提供し得る。後続の統合ポイントを取得するために、ＣＳＮクラウド統合アプリケーション６２０は、最初の統合ポイントのクエリ文字列を新たなクエリ文字列で修正し得る。例えば、最初の統合ポイントが“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｌｉｎｋ＝１”である場合、２番目の統合ポイントは“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｌｉｎｋ＝２”の形式を取り得る。

幾つかの実施形態では、次のリンクページネーションタイプに対する新たなクエリ文字列は、最初の統合ポイントを介して提供される記述に基づいて判定され得る。例えば、ＣＳＮクラウド統合アプリケーション６２０が“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｌｉｎｋ＝Ａ２４”からの記述をリクエストすると、対応する応答は、以下のＪａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）オブジェクトとして表示され得る。

このシナリオでは、ＣＳＮクラウド統合アプリケーション６２０は、ｎｅｘｔＬｉｎｋキー（この例では“Ｂ５３”）の値を取得するために応答を解析し得、２番目の統合ポイント（“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｌｉｎｋ＝Ｂ５３”）を取得するためにこの値を使用し得る。続いて、２番目の統合ポイントにより提供される応答は、３番目の統合ポイントを取得するために使用され得る値を提供し得る等々。

オフセットページネーションタイプを使用する場合、管理されたネットワーク３００のユーザは、仕様６３０にサイズパラメータ及びオフセットパラメータを提供し得る。一般的に、サイズパラメータはページ上に返されるアイテムの数を指し示す一方、オフセットパラメータは特定のアイテムのインデックスを指し示す。例えば、“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２”が１００個のアイテムを含むと仮定すると、クエリ“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｏｆｆｓｅｔ＝０＆ｓｉｚｅ＝２５”はアイテム１～２５を返すであろうし、クエリ“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｏｆｆｓｅｔ＝２５＆ｓｉｚｅ＝２５”はアイテム２５～５０を返すであろう、等々。

その結果、ＣＳＮクラウド統合アプリケーション６２０は、仕様６３０で提供されるオフセット／サイズパラメータパスを用いて最初の統合ポイントのクエリ文字列を修正するように構成され得る。例えば、最初の統合ポイントが“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｏｆｆｓｅｔ＝｛Ｘ｝＆ｓｉｚｅ＝｛Ｙ｝”である場合、２番目の統合ポイントは“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｏｆｆｓｅｔ＝｛Ｘ＋Ｙ｝＆ｓｉｚｅ＝｛Ｙ｝”と表示され得、Ｘ及びＹは整数である（括弧｛｝はプレースホルダーとして使用され、ＵＲＬの一部として意図されていることに留意されたい）。

ページベースのページネーションタイプを使用する場合、管理されたネットワーク３００のユーザは、仕様６３０にページパラメータを提供し得る。一般的に、ページパラメータはページのインデックス番号を指し示す。これは、クラウドコンピューティングプロバイダがコンピューティングサービスの記述を段階的に増加するページに分割する場合に有用であり得る。例えば、クラウドコンピューティングプロバイダは、コンピューティングサービスの記述を１０個の段階的に増加するページに分割し得、最初のページは“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｐａｇｅ＝１”であり、２番目のページは“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｐａｇｅ＝２”である等々。

その結果、ＣＳＮクラウド統合アプリケーション６２０は、ページパラメータパスを用いて最初の統合ポイントのクエリ文字列を修正するように構成され得る。例えば、最初の統合ポイントが“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｐａｇｅ＝｛Ｙ｝”である場合、２番目の統合ポイントは“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｐａｇｅ＝｛Ｙ＋１｝”と表示され得、Ｙは整数である（括弧｛｝はプレースホルダーとして使用され、ＵＲＬ文字列の一部ではないことに留意されたい）。

特に、上記の例示的なページネーションのタイプは、限定することを意図しない。その他のページネーションタイプが存在し得、ＣＳＮクラウド統合アプリケーション６２０によりサポートされ得る。

時折、管理されたネットワーク３００は、第１の統合ポイントから受信した記述を、１つ以上の後続の統合ポイントへの入力として使用し得る。この例として、クラウドコンピューティングプロバイダ６１０により提供される特定のコンピューティングサービスが、管理されたネットワーク３００の複数のユーザによって使用されると仮定する。特定のコンピューティングサービスの使用についてのより大きなコンテキストを得るために（例えば、特定のコンピューティングサービスが管理されたネットワーク３００のユーザによって十分に利用されているか否かを確認するために、特定のコンピューティングサービスが管理されたネットワーク３００等のユーザによって過度に利用されているか否かを確認するために）ＣＳＮクラウド統合アプリケーション６２０がこれらのユーザの各々に関連するライセンスサブスクリプション情報を取得することは興味深いかもしれない。したがって、ＣＳＮクラウド統合アプリケーション６２０は、最初に全てのユーザのリストを取得し得、次に、各ユーザに関連するライセンスサブスクリプション情報を取得するためにこのリストを入力として使用し得る。

グラフ８００は、この概念を説明するために提供される。ユーザの統合ポイントの取得８１０はグラフ８００の上部にある。この統合ポイントは、ＣＳＮクラウド統合アプリケーション６２０が全てのユーザのリストを取得することを可能にする。上で論じたように、全てのユーザのリストは、１つ以上のページに分割され得、それらは、ユーザリスト８１２、ユーザリスト８１４、及びユーザリスト８１６としてグラフ８００上に表されている。言い換えると、ユーザリスト８１２、８１４、及び８１６は、全てのユーザのリストからの個々のユーザのサブリストを各々含み得る。

スペースの複雑さを節約するために、ＣＳＮクラウド統合アプリケーション６２０は、深さ優先サーチ（ＤＦＳ）に従ってグラフ８００上で動作し得る。すなわち、ＣＳＮクラウド統合アプリケーション６２０は、ユーザリスト８１４又はユーザリスト８１６を同時に検索することなく、ユーザリスト８１２を検索し得る。その後、ＣＳＮクラウド統合アプリケーション６２０は、ユーザリスト８１２内のユーザ毎のライセンスサブスクリプション情報を検索するためにユーザリスト８１２をループし得る。このことは、全てのライセンスの取得８１８と全てのライセンスの取得８２０とによってグラフ８００上に表されている。

ユーザリスト８１２のユーザ毎のライセンスサブスクリプション情報を受信した後、ＣＳＮクラウド統合アプリケーション６２０はユーザリスト８１４を検索し得、ユーザリスト８１４のユーザ毎のライセンスサブスクリプション情報を検索するためにユーザリスト８１４をループし得る。このことは、全てのライセンスの取得８２２と全てのライセンスの取得８２４とによりグラフ８００上に表されている。

ユーザリスト８１４のユーザ毎のライセンスサブスクリプション情報が検索された後、ＣＳＮクラウド統合アプリケーション６２０は、ユーザリスト８１６を検索し、ユーザリスト８１６のユーザ毎のライセンスサブスクリプション情報を検索するためにユーザリスト８１６をループし得る。ＣＳＮクラウド統合アプリケーション６２０は、全てのユーザに対するライセンスサブスクリプション情報が検索されるまで、このプロセスを繰り返し続け得る。

図９は、例示的実施形態に従ったメッセージフロー９００を描写する。メッセージフロー９００において、計算インスタンス３２２は、管理されたネットワーク３００から仕様を受信し、１つ以上の統合ポイントを判定するために該仕様をその後使用する。例として、メッセージフロー９００は、動作中に、計算インスタンス３２２、管理されたネットワーク３００、及びクラウドコンピューティングプロバイダ６１０を利用し得る。しかしながら、追加のコンポーネント、ステップ、又はブロックがメッセージフロー９００に追加され得る。

ステップ９０２において、管理されたネットワーク３００のユーザは、仕様６３０を計算インスタンス３２２に提供し得る。仕様６３０は、（ｉ）クラウドコンピューティングプロバイダ６１０により提供される１つ以上の統合ポイント、（ｉｉ）１つ以上の統合ポイントにより提供される応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）応答に現れるクラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスの記述とＣＭＤＢ５００内のデータベーステーブルのフィールドとの間のマッピングを定義し得る。仕様６３０は、グラフィカルインターフェースを介して、管理されたネットワーク３００から計算インスタンス３２２へ送信され得る。

ステップ９０４において、計算インスタンス３２２は、ＣＳＮクラウド統合アプリケーション６２０を呼び出す。呼び出されると、ＣＳＮクラウド統合アプリケーション６２０は、（ｉ）クラウドコンピューティングプロバイダ６１０で認証するため、及び（ｉｉ）クラウドコンピューティングプロバイダ６１０により提供される第１の統合ポイントを判定するために、仕様６３０からデータを収集し得る。例として、クラウドコンピューティングプロバイダ“ＦＯＯＢＡＲ”により提供されるコンピューティングサービスに対する第１の統合ポイントは、“ｈｔｔｐｓ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｌｉｎｋ＝１”の形式を取り得る。

ステップ９０６において、ＣＳＮクラウド統合アプリケーション６２０は、ステップ９０４で判定された第１の統合ポイントを使用して、クラウドコンピューティングプロバイダ６１０により提供されるコンピューティングサービスの第１の記述をリクエストし得る。幾つかの場合、計算インスタンス３２２からクラウドへのリクエストは、管理されたネットワーク３００上のプロキシサーバ３１２を介して促進される。クラウドコンピューティングプロバイダ６１０からＣＳＮクラウド統合アプリケーション６２０により受信される応答は、管理されたネットワーク３００に利用可能な又は使用されるコンピューティングリソースの第１の記述を含み得る。幾つかの例では、第１の記述は、ＸＭＬ、ＪＳＯＮ、又はＹＡＭＬの形式にあり得る。

図９に示すように、ステップ９０４及び９０６は、任意の数の統合ポイントに対して繰り返され得る。図７で上に説明したように、後続の統合ポイントは、仕様６３０で提供されるページネーションタイプによって判定され得る。例えば、ステップ９０８において、ＣＳＮクラウド統合アプリケーション６２０は、統合ポイントＮを判定する。この統合ポイントは、“ｈｔｔｐ：／／ｆｏｏｂａｒ．ｃｏｍ／ａｐｉ／ｖ２？ｌｉｎｋ＝ｎ”の形式を取り得る。ステップ９１０において、ＣＳＮクラウド統合アプリケーション６２０は、統合ポイントＮを介してクラウドコンピューティングプロバイダ６１０からコンピューティングリソースのＮ番目の記述をリクエスト及び受信し得る。

ステップ９１２において、ＣＳＮクラウド統合アプリケーション６２０は、Ｎ個の統合ポイントの各々から受信した記述を整理し得、該記述を構成アイテムとしてＣＭＤＢ５００又は別のデータベース内に格納し得る。

ＶＩ． 構成インターフェースの例
メッセージフロー９００を有効にするために、リモートネットワーク管理プラットフォーム３２０は、管理されたネットワーク３００のユーザに、仕様６３０に適切なデータを入力するように促し得る。このことは、計算インスタンス３２２によりホストされるウェブページ又は一連のウェブページを介して達成され得、リクエストに応じて管理されたネットワーク３００からユーザに提供される。特に、ウェブページの以下の例は、単に説明を目的とし、限定することを意図しない。情報の代替的配置を含むその他のウェブページが存在し得る。

図１０Ａは、例示的実施形態に従ったウェブページ１０００を説明する。ウェブページ１０００は、特定のコンピューティングサービスに関連する構成の詳細をユーザが指定することを可能にすることによって、特定のコンピューティングサービスの識別、構成、及び管理を容易にする。ウェブページ１０００を介して構成された詳細は、仕様６３０に含まれ得る。

名前フィールド１００２は、ユーザが特定のコンピューティングサービスにユニークな名前を割り当てることを可能にし得る。このユニークな名前は、特定のコンピューティングサービスを他のコンピューティングサービスから区別するためにその後使用され得る。

ベースＵＲＬフィールド１００４は、ユーザが特定のコンピューティングサービスのベースＵＲＬを指定することを可能にする。ベースＵＲＬは、特定のコンピューティングサービスに対するスキーム及びホスト（又はホストのみ）を含み得る。図７で上に説明したように、ＣＳＮクラウド統合アプリケーション６２０は、このベースＵＲＬを変更し、異なる統合ポイントを取得するために、異なるページネーションタイプを使用し得る。

認証ＵＲＬ１００６は、特定のコンピューティングサービスを提供するクラウドコンピューティングプロバイダに対する認証ＵＲＬをユーザが指定することを可能にし得る。実行中、ＣＳＮクラウド統合アプリケーション６２０は、特定のクラウドプロバイダで認証するために、認証情報を検索し得、認証情報をＡＰＩリクエストにパッケージ化し得、ＡＰＩリクエストを認証ＵＲＬへ送信し得る。

統合アクションリスト１００８は、ＣＳＮクラウド統合アプリケーション６２０が特定のコンピューティングサービスに関連する記述を受信するために実施し得る統合アクションのリストを含み得る。図１０Ａに説明するように、統合アクションリスト１００８は、“最後のアクティビティの取得”アクションを含み、これは、特定のコンピューティングサービスの最新のアクティビティを取得するように動作し得る。例では、最新のアクティビティは、特定のコンピューティングサービスに最近アクセスしたユーザに関連する詳細を含み得る。

統合アクションリスト１００８はまた、特定のコンピューティングサービスからサブスクリプション情報を取得するように動作し得るプルサブスクリプションアクション１０１０を含む。例では、サブスクリプション情報は、管理されたネットワーク３００が特定のコンピューティングサービスに関して有するアカウントの数、及び管理されたネットワーク３００が特定のコンピューティングサービスに関して有するライセンスの数等に関連する詳細を含み得る。

ユーザは、統合アクションリスト１００８から各統合アクションを更に構成し得る。例えば、ユーザがプルサブスクリプションアクション１０１０をクリックし、さもなければ選択する場合、ユーザは、プルサブスクリプションアクション１０１０に対する構成の詳細をユーザが編集することを可能にする構成ページに導かれ得る。

図１０Ｂは、例示的実施形態に従ったウェブページ１０２０を説明する。ウェブページ１０２０は、ユーザが特定の統合アクションに関連する詳細を指定することを可能にすることによって、特定の統合アクションの構成を容易する。例示的実施形態では、ウェブページ１０２０は、統合アクションリスト１００８から統合アクションをクリックし、さもなければ選択する時に、管理ネットワーク３００からユーザに提供され得る。ウェブページ１０２０を介して構成された詳細は、仕様６３０内に含まれ得る。

統合名フィールド１０２２は、ウェブページ１０２０を介して構成されている特定の統合アクションにユニークな名前をユーザが割り当てることを可能にし得る。このユニークな名前は、特定の統合アクションを他の統合アクションから区別するために使用され得る。

統合ポイントリスト１０２４は、ＣＳＮクラウド統合アプリケーション６２０が特定の統合アクションを実行する場合に照会すべき全ての統合ポイントのリストを含む。統合ポイントリスト１０２４は、各統合ポイントがいつ照会されるかについての論理的な順序をユーザが構成することを可能にし得る。図８に説明したように、このことは、第１の統合ポイントから受信した記述を１つ以上の後続の統合ポイントに入力することを可能にし得る。例えば、ユーザ統合ポイント１０２６は順序の１番目として示され、ライセンス統合ポイント１０２８は順序の２番目として表示される。

ユーザは、統合ポイントリスト１０２４から各統合ポイントを更に構成し得る。例えば、ユーザがユーザ統合ポイント１０２６をクリックし、さもなければ選択する場合、ユーザは、ユーザ統合ポイント１０２６に対する構成をユーザが編集可能にする構成ページに誘導され得る。

図１０Ｃは、例示的実施形態に従ったウェブページ１０３０を説明する。ウェブページ１０３０は、特定の統合ポイントに関連する詳細をユーザが指定することを可能にすることによって、特定の統合ポイントの構成を容易にする。例示的実施形態では、ウェブページ１０３０は、統合ポイントリスト１０２４から統合ポイントをクリックし、さもなければ選択する時に、管理されたネットワーク３００からユーザに提供され得る。ウェブページ１０３０を介して構成された詳細は、仕様６３０内に含まれ得る。

名前フィールド１０３２は、ユーザがウェブページ１０３０を介して構成されている統合ポイントにユニークな名前を割り当てることを可能にし得る。このユニークな名前は、特定の統合ポイントを他の統合ポイントから区別するために使用され得る。

幾つかの場合、クラウドコンピューティングプロバイダ６１０から受信したコンピューティングサービスの記述は、管理されたネットワーク３００が格納したくない無関係な情報を含み得る。関連するデータのみを取得するために、応答パス１０３４が使用され得る。応答パス１０３４は、受信した記述内の特定の要素を配置し得るネストされたオブジェクト及び／又はアレイの連結を含み得る。全ての要素が対象とならなくてもよく、パスが対象の要素を定義するために使用され得るため、こうしたパスを使用することは、記述を解析する場合に有利であり得る。例えば、コンピューティングサービスの記述は、以下のＪＳＯＮ形式で表され得る。

“名前（ｎａｍｅ）”オブジェクトが、関連する管理されたネットワーク３００である場合、応答パス１０３４は、名前“オブジェクト（ｏｂｊｅｃｔｓ）”への構造化されたパスを含み得る。このパスは、“ｒｅｓｐｏｎｓｅ．ｍｅｍｂｅｒｓ［］．ｎａｍｅｓ”のように表示され得る。動作中、ＣＳＮクラウド統合アプリケーション６２０は、記述から値を抽出し、それらをファイル及び／又はデータベーステーブルに書き込むために、応答パス１０３４を利用し得る。

テストモードフラグ１０３６は、ウェブページ１０３０を介して定義された特定の統合ポイントがテストに使用されているか否かを指し示すチェックボックスであり得る。テストに使用される（例えば、テストモードフラグ１０３６がチェックされる）ことは、ＣＳＮクラウド統合アプリケーション６３０が、ユーザが見るためにクラウドコンピューティングプロバイダ６１０から受信した記述を表示することを意味する。幾つかの場合、テストに使用されることは、ＣＳＮクラウド統合アプリケーション６２０がクラウドコンピューティングプロバイダ６１０から受信した記述をＣＭＤＢ５００中に格納しないことを意味する。テストモードについての詳細は、以下の図１０Ｄの論考で説明される。

エンドポイント１０３８は、ウェブページ１０３０を介して定義された特定の統合ポイントに対するＡＰＩエンドポイント／ＵＲＬをユーザが指定することを可能にし得る。エンドポイント１０３８は、最初／第１の統合ポイントに対応し得る。

ページネーションボックス１０４０は、エンドポイント１０３８に使用するページネーションタイプをユーザが構成することを可能にする。図１０Ｃに示すように、ページネーションボックス１０４０は、ユーザが複数のページネーションタイプから１つを選択することを可能にするページネーションタイプドロップダウン１０４２を含む。ウェブページ１０３０は、“オフセット”ページネーションタイプが現在選択されていることを示す。このことは、“オフセットパラメータ名”、“オフセットパラメータ値”、“サイズパラメータ名”、及び“サイズパラメータ値”フィールドがページネーションボックス１０４０に示されることをもたらす。ユーザは“オフセット”ページネーションタイプを構成するために、これらのフィールドにポピュレートし得る。

応答スキーママップ１０４４は、ユーザがクラウドコンピューティングプロバイダ６１０から受信したコンピューティングサービスの記述をＣＭＤＢ５００内のテーブル／フィールドにマッピングすることを可能にする。例えば、応答スキーママップ１０４４は、“ユーザ名（ｕｓｅｒ＿ｎａｍｅ）”フィールドがＣＭＤＢ５００の“プロファイル（ｐｒｏｆｉｌｅ）”内の“ｎａｍｅ”フィールドにマッピングされることを示す。更に、応答スキーママップ１０４４は、“ユーザＩＤ（ｕｓｅｒ＿ＩＤ）”フィールドがＣＭＤＢ５００の“プロファイル”テーブル内の“ＩＤ”フィールドにマッピングされることを示す。特に、その他のマッピングも可能である。

図１０Ｄは、例示的実施形態に従ったウェブページ１０５０を説明する。ウェブページ１０５０は、（おそらく、ユーザが“テストモード”ボタンをクリックし、さもなければ選択することを介して）アクティブ化されるように図１０Ｄに示されたテストボックス１０５２を除いて、一般的にウェブページ１０３０と同じコンテンツを含む。したがって、簡潔にするために、ウェブページ１０３０と重複する項目の記述は、ウェブページ１０５０から省略されている。

図１０Ｄにおいて、応答フィールド１０５４は、エンドポイント１０３８を照会する時にクラウドコンピューティングプロバイダ６１０から受信され得るコンピューティングリソースのサンプル応答／記述を示す。次に、マッピングされたデータフィールド１０５６は、サンプル応答のマッピングを示し得る。特に、マッピングされたデータフィールド１０５６に示されるマッピングは、応答パス１０３４で提供されたパスに対応し得る。

有利なことに、応答フィールド１０５４／マッピングされたデータフィールド１０５６を示すことは、クラウドコンピューティングプロバイダ６１０から受信した応答をＣＭＤＢ５００内のフィールド／テーブルに適切にマッピングすることでユーザを支援し得る（例えば、ユーザが応答パス１０３４／応答スキーママップ１０４４を適切に構成することを助力する）。

ＶＩＩ． 動作例
図１１は、例示的実施形態を説明するフローチャートである。図１１により説明するプロセスは、コンピューティングデバイス１００等のコンピューティングデバイス、及び／又はサーバクラスタ２００等のコンピューティングデバイスのクラスタによって実行され得る。しかしながら、プロセスは、その他のタイプのデバイス又はデバイスサブシステムによって実行され得る。例えば、このプロセスは、ラップトップ又はタブレットデバイス等のポータブルコンピュータによって実行され得る。

図１１の実施形態は、そこに示された機構の内の何れか１つ以上を削除することによって簡略化され得る。更に、これらの実施形態は、以前の図又は本明細書で説明した何れかの機構、態様、及び／又は実装と組み合わされ得る。

ブロック１１００は、コンピューティングサービスニュートラルクラウド統合アプリケーションによって、リモートネットワークに関連する仕様を取得することを含む。コンピューティングサービスニュートラルクラウド統合アプリケーションは、計算インスタンス内に配備された１つ以上のプロセッサ上で実行可能であり得る。計算インスタンスは、管理されたネットワークに専用であり得、計算インスタンス内に配備された永続ストレージは、データベーステーブル内に、リモートネットワークにより提供されるコンピューティングサービスの表現を含む。仕様は、（ｉ）リモートネットワークに対する統合ポイント、（ｉｉ）統合ポイントにより提供される応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）応答に現れるリモートネットワークにより提供されるコンピューティングサービスの記述とデータベーステーブルのフィールドとの間のマッピングを定義し得る。

ブロック１１１０は、コンピューティングサービスニュートラルクラウド統合アプリケーションによって統合ポイントを介して、リモートネットワークにより提供されるコンピューティングサービスの第１の記述をリクエスト及び受信することを含む。

ブロック１１２０は、コンピューティングサービスニュートラルクラウド統合アプリケーションによってページネーションタイプ及び統合ポイントから、リモートネットワークに対する第２の統合ポイントを判定することを含む。

ブロック１１３０は、コンピューティングサービスニュートラルクラウド統合アプリケーションによって第２の統合ポイントを介して、リモートネットワークにより提供されるコンピューティングサービスの第２の記述をリクエスト及び受信することを含む。

ブロック１１４０は、コンピューティングサービスニュートラルクラウド統合アプリケーションによってデータベーステーブルのフィールド内に、マッピングに従って第１の記述及び第２の記述を格納することを含む。

幾つかの実施形態は、コンピューティングサービスニュートラルクラウド統合アプリケーションによってページネーションタイプ及び第２の統合ポイントから、リモートネットワークに対する第３の統合ポイントを判定することを含む。実施形態は、コンピューティングサービスニュートラルクラウド統合アプリケーションによって第３の統合ポイントを介して、リモートネットワークにより提供されるコンピューティングサービスの第３の記述をリクエスト及び受信することを更に含み得る。実施形態は、コンピューティングサービスニュートラルクラウド統合アプリケーションによってデータベーステーブルのフィールド内に、マッピングに従って第３の記述を格納することを更に含み得る。

幾つかの実施形態は、第２のリモートネットワークに関連する第２の仕様を取得することを含み、第２の仕様は、（ｉ）第２のリモートネットワークに対する第３の統合ポイント、（ｉｉ）第３の統合ポイントにより提供される第２の応答と関連付けられた第２のページネーションタイプ、及び（ｉｉｉ）第２の応答に現れる第２のリモートネットワークにより提供される第２のコンピューティングサービスの記述とデータベーステーブルのフィールドとの間の第２のマッピングを定義する。実施形態は、第３の統合ポイントを介して、第２のリモートネットワークにより提供されるコンピューティングサービスの第３の記述をリクエスト及び受信することを更に含み得る。実施形態は、ページネーションタイプ及び第３の統合ポイントから、第２のリモートネットワークに対する第４の統合ポイントを判定することを更に含み得る。実施形態は、第４の統合ポイントを介して、第２のリモートネットワークにより提供されるコンピューティングサービスの第４の記述をリクエスト及び受信することを更に含み得る。実施形態は、データベーステーブルのフィールド内に、第２のマッピングに従って第３の記述及び第４の記述を格納することを更に含み得る。

幾つかの実施形態では、リモートネットワークは、コンピューティングシステム及び管理されたネットワークとは物理的に異なり、コンピューティングシステム及び管理されたネットワークは、広域ネットワークを介してリモートネットワークにアクセスする。

幾つかの実施形態では、仕様はまた、リモートネットワークに対する認証メカニズムを定義し、リモートネットワークにより提供されるコンピューティングサービスの第１の記述をリクエスト及び受信することは、認証メカニズムを介して第１の記述をリクエスト及び受信することを含む。

幾つかの実施形態では、統合ポイントはＵＲＬを含み、ＵＲＬは、リモートネットワークと関連付けられたホスト及びパスを含む。これらの実施形態では、ページネーションタイプは、新たなパスを指定する次のエンドポイントページネーションを含み、第２の統合ポイントは第２のＵＲＬを含み、第２のＵＲＬは、リモートネットワークと関連付けられたホスト及び新たなパスを含む。

幾つかの実施形態では、統合ポイントはＵＲＬを含み、ＵＲＬは、リモートネットワークと関連付けられたホスト、パス、及びクエリ文字列を含む。これらの実施形態では、ページネーションタイプは、新たなクエリ文字列を指定する次のリンクページネーションを含み、第２の統合ポイントは第２のＵＲＬを含み、第２のＵＲＬは、リモートネットワークと関連付けられたホスト、パス、及び新たなクエリ文字列を含む。

幾つかの実施形態では、新たなクエリ文字列は、リモートネットワークにより提供されるコンピューティングサービスの第１の記述内の情報に基づいて判定されるキーと値のペアを含む。

幾つかの実施形態では、統合ポイントはＵＲＬを含み、ＵＲＬは、リモートネットワークと関連付けられたホスト、パス、並びにオフセットパラメータ及びサイズパラメータを含むクエリ文字列を含む。これらの実施形態では、ページネーションタイプは、新たなクエリ文字列を指定するオフセットページネーションを含み、新たなクエリ文字列は、第２のオフセットパラメータ及びサイズパラメータを含み、第２の統合ポイントは第２のＵＲＬを含み、第２のＵＲＬは、リモートネットワークと関連付けられたホスト、パス、及び新たなクエリ文字列を含む。

幾つかの実施形態では、統合ポイントはＵＲＬを含み、ＵＲＬは、リモートネットワークと関連付けられたホスト、パス、並びにページパラメータを含むクエリ文字列を含む。これらの実施形態では、ページネーションタイプは、新たなクエリ文字列を指定するページベースのページネーションを含み、新たなクエリ文字列は第２のページパラメータを含み、新たなクエリ文字列は第２のページパラメータを含み、第２の統合ポイントは、第２のＵＲＬを含み、第２のＵＲＬは、リモートネットワークと関連付けられたホスト、パス、及び新たなクエリ文字列を含む。

幾つかの実施形態では、リモートネットワークにより提供されるコンピューティングサービスの記述は、コンピューティングサービスニュートラルクラウド統合アプリケーションによって、複合的なデータオブジェクトとして受信される。これらの実施形態では、仕様は、リモートネットワークにより提供されるコンピューティングサービスの特定の記述が配置される複合的なデータオブジェクト内のパスを更に定義し、コンピューティングサービスの記述を格納することは、パスを参照してコンピューティングサービスの記述を格納することを含む。

幾つかの実施形態では、複合的なデータオブジェクトは、ＪＳＯＮ又はＸＭＬに従ってフォーマット化される。

幾つかの実施形態では、仕様は、テストオプションを更に定義し、コンピューティングサービスニュートラルクラウド統合アプリケーションは、格納する前に、テストオプションがアクティブ化されると判定することと、テストオプションがアクティブ化されることに基づいて、（ｉ）第１の記述及び第２の記述に対応する要素を有する１つ以上のグラフィカルユーザインターフェースを生成すること、及び（ｉｉ）管理されたネットワークと関連付けられたクライアントデバイスに１つ以上のグラフィカルユーザインターフェースを提供することを含む動作を更に実施する。

幾つかの実施形態では、コンピューティングサービスの第１の記述は、記述のアレイを含み、コンピューティングサービスの第２の記述をリクエスト及び受信することは、記述のアレイ内の個別の記述毎に、個別の記述内で提供されるパラメータを用いて第２の統合ポイントを修正することと、修正された第２の統合ポイントを介して、第２の記述のサブセットをリクエスト及び受信することを含む。

幾つかの実施形態では、第２の記述のサブセットは記述の第２のアレイを含み、コンピューティングサービスニュートラルクラウド統合アプリケーションは、ページネーションタイプ及び第２の統合ポイントから、リモートネットワークに対する第３の統合ポイントを判定することと、第３の統合ポイントを介して、リモートネットワークにより提供されるコンピューティングサービスの第３の記述をリクエスト及び受信することを含む動作を更に実施する。これらの実施形態では、第３の記述をリクエスト及び受信することは、記述の第２のアレイ内の個別の記述毎に、個別の記述で提供されるパラメータを用いて第３の統合ポイントを修正することと、修正された第３の統合ポイントを介して、第３の記述のサブセットをリクエスト及び受信することを含む。

ＶＩＩＩ． 結論
本開示は、様々な態様の例証として意図されている、この出願で説明する特定の実施形態に関して限定されるべきではない。当業者には明らかであるように、その範囲から逸脱することなく、多くの修正及び変形がなされ得る。本明細書に説明したものに加えて、開示の範囲内の機能的に同等の方法及び装置は、前述の説明から当業者には明らかであろう。そうした修正及び変形は、添付の特許請求の範囲内にあることが意図されている。

上記の詳細な説明は、添付の図を参照して、開示されたシステム、デバイス、及び方法の様々な機構及び動作を説明している。本明細書及び図で説明した例示的実施形態は、限定することを意味しない。本明細書に提示される主題の範囲から逸脱することなく、他の実施形態が利用され得、他の変更がなされ得る。本明細書に一般的に説明され、図に説明されるような本開示の態様が、多種多様な異なる構成で配置され得、置換され得、組み合され得、分離され得、設計され得ることは容易に理解されるであろう。

図中のメッセージフロー図、シナリオ、及びフローチャートの内の何れか又は全てに関して、本明細書で論じたように、各ステップ、ブロック、及び／又は通信は、例示的実施形態に従った情報の処理及び／又は情報の送信を表し得る。代替的実施形態は、これらの例示的実施形態の範囲内に含まれる。これらの代替的実施形態では、例えば、ステップ、ブロック、送信、通信、リクエスト、応答、及び／又はメッセージとして説明される動作は、関係する機能に依存して、実質的に同時又は逆の順序を含め、示された又は論じられた順序とは異なる順序で実行され得る。更に、より多くの又はより少ないブロック及び／又は動作は、本明細書で論じられるメッセージフロー図、シナリオ、及びフローチャートの内の何れかと共に使用され得、これらのメッセージフロー図、シナリオ、及びフローチャートは、部分的に又は全体的に相互に組み合され得る。

情報の処理を表すステップ又はブロックは、本明細書で説明する方法又は技術の具体的な論理機能を実施するように構成され得る回路に対応し得る。代替的又は追加的に、情報の処理を表すステップ又はブロックは、モジュール、セグメント、又はプログラムコードの一部（関連データを含む）に対応し得る。プログラムコードは、方法又は技術において具体的な論理演算又は活動を実装するためにプロセッサにより実行可能な１つ以上の命令を含み得る。プログラムコード及び／又は関連データは、ＲＡＭ、ディスクドライブ、ソリッドステートドライブ、又は別のストレージ媒体を含むストレージデバイス等の任意のタイプのコンピュータ可読媒体上に格納され得る。

コンピュータ可読媒体はまた、レジスタメモリ及びプロセッサキャッシュのようなデータを短期間格納するコンピュータ可読媒体等の非一時的コンピュータ可読媒体を含み得る。コンピュータ可読媒体は、プログラムコード及び／又はデータをより長期間格納する非一時的コンピュータ可読媒体を更に含み得る。したがって、コンピュータ可読媒体は、例えば、ＲＯＭ、光又は磁気ディスク、ソリッドステートドライブ、コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）のような二次的又は永続的な長期ストレージを含み得る。コンピュータ可読媒体はまた、その他の任意の揮発性又は不揮発性のストレージシステムであり得る。コンピュータ可読媒体は、例えば、コンピュータ可読ストレージ媒体、又は有形ストレージデバイスとみなされ得る。

更に、１つ以上の情報送信を表すステップ又はブロックは、同じ物理デバイス内のソフトウェア及び／又はハードウェアモジュール間の情報送信に対応し得る。しかしながら、その他の情報送信は、異なる物理デバイス内のソフトウェアモジュール及び／又はハードウェアモジュール間であり得る。

図に示される特定の配置は、限定的とみなされるべきではない。他の実施形態は、所与の図に示される各要素の内の多少を含み得ることを理解すべきである。更に、説明された要素の内の幾つかは、組み合わされ得、又は省略され得る。更に、例示的実施形態は、図に説明されない要素を含み得る。

様々な態様及び実施形態が本明細書に開示されているが、他の態様及び実施形態は当業者には明らかであろう。本明細書に開示される様々な態様及び実施形態は、例証を目的とし、限定することを意図せず、真の範囲は、以下の特許請求の範囲によって示される。

Claims (40)

1. 永続ストレージを含む計算インスタンスであって、前記永続ストレージは、データベーステーブル内に、リモートネットワークにより提供されるコンピューティングサービスの表現を含み、前記計算インスタンスは、管理されたネットワークに専用である、前記計算インスタンスと、
   前記計算インスタンス内に配備され、
   リモートネットワークに関連する仕様を取得することであって、前記仕様は、（ｉ）前記リモートネットワークに対する統合ポイント、（ｉｉ）前記統合ポイントにより提供される応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記リモートネットワークにより提供される前記コンピューティングサービスの記述と前記データベーステーブルのフィールドとの間のマッピングを定義することと、
   前記統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
   前記ページネーションタイプ及び前記統合ポイントから、前記リモートネットワークに対する第２の統合ポイントを判定することと、
   前記第２の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
   前記データベーステーブルの前記フィールド内に、前記マッピングに従って前記第１の記述及び前記第２の記述を格納すること
   を含む動作をコンピューティングサービスニュートラルクラウド統合アプリケーションに実施させるように構成された１つ以上のプロセッサと
   を含むコンピューティングシステム。
2. 前記コンピューティングサービスニュートラルクラウド統合アプリケーションは、
   前記ページネーションタイプ及び前記第２の統合ポイントから、前記リモートネットワークに対する第３の統合ポイントを判定することと、
   前記第３の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第３の記述をリクエスト及び受信することと、
   前記データベーステーブルの前記フィールド内に、前記マッピングに従って前記第３の記述を格納すること
   を含む動作を更に実施する、請求項１に記載のコンピューティングシステム。
3. 前記コンピューティングサービスニュートラルクラウド統合アプリケーションは、
   第２のリモートネットワークに関連する第２の仕様を取得することであって、前記第２の仕様は、（ｉ）前記第２のリモートネットワークに対する第３の統合ポイント、（ｉｉ）前記第３の統合ポイントにより提供される第２の応答と関連付けられた第２のページネーションタイプ、及び（ｉｉｉ）前記第２の応答に現れる前記第２のリモートネットワークにより提供される第２のコンピューティングサービスの記述と前記データベーステーブルのフィールドとの間の第２のマッピングを定義することと、
   前記第３の統合ポイントを介して、前記第２のリモートネットワークにより提供される前記コンピューティングサービスの第３の記述をリクエスト及び受信することと、
   前記ページネーションタイプ及び前記第３の統合ポイントから、前記第２のリモートネットワークに対する第４の統合ポイントを判定することと、
   前記第４の統合ポイントを介して、前記第２のリモートネットワークにより提供される前記コンピューティングサービスの第４の記述をリクエスト及び受信することと、
   前記データベーステーブルの前記フィールド内に、前記第２のマッピングに従って前記第３の記述及び前記第４の記述を格納すること
   を含む動作を更に実施する、請求項１に記載のコンピューティングシステム。
4. 前記リモートネットワークは、前記コンピューティングシステム及び前記管理されたネットワークとは物理的に異なり、前記コンピューティングシステム及び前記管理されたネットワークは、広域ネットワークを介して前記リモートネットワークにアクセスする、請求項１に記載のコンピューティングシステム。
5. 前記仕様はまた、前記リモートネットワークに対する認証メカニズムを定義し、前記リモートネットワークにより提供される前記コンピューティングサービスの前記第１の記述をリクエスト及び受信することは、
   前記認証メカニズムを介して前記第１の記述をリクエスト及び受信すること
   を含む、請求項１に記載のコンピューティングシステム。
6. 前記統合ポイントはユニフォームリソースロケータ（ＵＲＬ）を含み、前記ＵＲＬは、前記リモートネットワークと関連付けられたホスト及びパスを含み、前記ページネーションタイプは、新たなパスを指定する次のエンドポイントページネーションを含み、前記第２の統合ポイントは第２のＵＲＬを含み、前記第２のＵＲＬは、前記リモートネットワークと関連付けられた前記ホスト及び前記新たなパスを含む、請求項１に記載のコンピューティングシステム。
7. 前記統合ポイントはユニフォームリソースロケータ（ＵＲＬ）を含み、前記ＵＲＬは、前記リモートネットワークと関連付けられたホスト、パス、及びクエリ文字列を含み、前記ページネーションタイプは、新たなクエリ文字列を指定する次のリンクページネーションを含み、前記第２の統合ポイントは第２のＵＲＬを含み、前記第２のＵＲＬは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む、請求項１に記載のコンピューティングシステム。
8. 前記新たなクエリ文字列は、前記リモートネットワークにより提供される前記コンピューティングサービスの前記第１の記述内の情報に基づいて判定されるキーと値のペアを含む、請求項７に記載のコンピューティングシステム。
9. 前記統合ポイントはユニフォームリソースロケータ（ＵＲＬ）含み、前記ＵＲＬは、前記リモートネットワークと関連付けられたホスト、パス、並びにオフセットパラメータ及びサイズパラメータを含むクエリ文字列を含み、前記ページネーションタイプは、新たなクエリ文字列を指定するオフセットページネーションを含み、前記新たなクエリ文字列は、第２のオフセットパラメータ及び前記サイズパラメータを含み、前記第２の統合ポイントは第２のＵＲＬを含み、前記第２のＵＲＬは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む、請求項１に記載のコンピューティングシステム。
10. 前記統合ポイントはユニフォームリソースロケータ（ＵＲＬ）を含み、前記ＵＲＬは、前記リモートネットワークと関連付けられたホスト、パス、及びページパラメータを含むクエリ文字列を含み、前記ページネーションタイプは、新たなクエリ文字列を指定するページベースのページネーションを含み、前記新たなクエリ文字列は第２のページパラメータを含み、前記第２の統合ポイントは第２のＵＲＬを含み、前記第２のＵＲＬは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む、請求項１に記載のコンピューティングシステム。
11. 前記リモートネットワークにより提供される前記コンピューティングサービスの前記記述は、前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、複合的なデータオブジェクトとして受信され、前記仕様は、前記リモートネットワークにより提供される前記コンピューティングサービスの特定の記述が配置される前記複合的なデータオブジェクト内のパスを更に定義し、前記コンピューティングサービスの記述を格納することは、前記パスを参照して前記コンピューティングサービスの記述を格納することを含む、請求項１に記載のコンピューティングシステム。
12. 前記複合的なデータオブジェクトは、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）又はｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）に従ってフォーマット化される、請求項１１に記載のコンピューティングシステム。
13. 前記仕様はテストオプションを更に定義し、前記格納する前に、前記コンピューティングサービスニュートラルクラウド統合アプリケーションは、
    前記テストオプションがアクティブ化されると判定することと、
    前記テストオプションがアクティブ化されることに基づいて、（ｉ）前記第１の記述及び前記第２の記述に対応する要素を用いて１つ以上のグラフィカルユーザインターフェースを生成し、（ｉｉ）前記管理されたネットワークと関連付けられたクライアントデバイスに前記１つ以上のグラフィカルユーザインターフェースを提供すること
    を含む動作を更に実施する、請求項１に記載のコンピューティングシステム。
14. 前記コンピューティングサービスの前記第１の記述は記述のアレイを含み、前記コンピューティングサービスの前記第２の記述をリクエスト及び受信することは、
    記述の前記アレイ内の個別の記述毎に、
    前記個別の記述で提供されるパラメータを用いて前記第２の統合ポイントを修正することと、
    修正された前記第２の統合ポイントを介して、前記第２の記述のサブセットをリクエスト及び受信すること
    を含む、請求項１に記載のコンピューティングシステム。
15. 前記第２の記述の前記サブセットは、記述の第２のアレイを含み、前記コンピューティングサービスニュートラルクラウド統合アプリケーションは、
    前記ページネーションタイプ及び前記第２の統合ポイントから、前記リモートネットワークに対する第３の統合ポイントを判定することと、
    前記第３の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第３の記述をリクエスト及び受信することであって、前記第３の記述をリクエスト及び受信することは、
    記述の前記第２のアレイ内の個別の記述毎に、
    前記個別の記述で提供されるパラメータを用いて前記第３の統合ポイントを修正することと、
    修正された前記第３の統合ポイントを介して、前記第３の記述のサブセットをリクエスト及び受信すること
    を含むこと
    を含む更なる動作を実施する、請求項１４に記載のコンピューティングシステム。
16. コンピューティングサービスニュートラルクラウド統合アプリケーションによって、リモートネットワークに関連する仕様を取得することであって、前記コンピューティングサービスニュートラルクラウド統合アプリケーションは、計算インスタンス内に配備された１つ以上のプロセッサ上で実行可能であり、前記計算インスタンスは管理されたネットワークに専用であり、前記計算インスタンス内に配備された永続ストレージは、データベーステーブル内に、リモートネットワークにより提供されるコンピューティングサービスの表現を含み、前記仕様は、（ｉ）前記リモートネットワークに対する統合ポイント、（ｉｉ）前記統合ポイントにより提供される応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記リモートネットワークにより提供される前記コンピューティングサービスの記述と前記データベーステーブルのフィールドとの間のマッピングを定義することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記ページネーションタイプ及び前記統合ポイントから、前記リモートネットワークに対する第２の統合ポイントを判定することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記第２の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記データベーステーブルの前記フィールド内に、前記マッピングに従って前記第１の記述及び前記第２の記述を格納すること
    を含む、コンピュータ実装方法。
17. 前記統合ポイントはユニフォームリソースロケータ（ＵＲＬ）を含み、前記ＵＲＬは、前記リモートネットワークと関連付けられたホスト、パス、及びクエリ文字列を含み、前記ページネーションタイプは、新たなクエリ文字列を指定する次のリンクページネーションを含み、前記第２の統合ポイントは第２のＵＲＬを含み、前記第２のＵＲＬは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む、請求項１６に記載のコンピュータ実装方法。
18. 前記コンピューティングサービスの前記第１の記述は記述のアレイを含み、前記コンピューティングサービスの前記第２の記述をリクエスト及び受信することは、
    記述の前記アレイ内の個別の記述毎に、
    前記個別の記述で提供されるパラメータを用いて前記第２の統合ポイントを修正することと、
    修正された前記第２の統合ポイントを介して、前記第２の記述のサブセットをリクエスト及び受信すること
    を含む、請求項１６に記載のコンピュータ実装方法。
19. 前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記ページネーションタイプ及び前記第２の統合ポイントから、前記リモートネットワークに対する第３の統合ポイントを判定することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記第３の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第３の記述をリクエスト及び受信することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記データベーステーブルの前記フィールド内に、前記マッピングに従って前記第３の記述を格納すること
    を更に含む、請求項１６に記載のコンピュータ実装方法。
20. 計算インスタンス内に配備された１つ以上のプロセッサによる実行時に、
    コンピューティングサービスニュートラルクラウド統合アプリケーションによって、リモートネットワークに関連する仕様を取得することであって、前記コンピューティングサービスニュートラルクラウド統合アプリケーションは、前記１つ以上のプロセッサ上で実行可能であり、前記計算インスタンスは管理されたネットワークに専用であり、前記計算インスタンス内に配備された永続ストレージは、データベーステーブル内に、リモートネットワークにより提供されるコンピューティングサービスの表現を含み、前記仕様は、（ｉ）前記リモートネットワークに対する統合ポイント、（ｉｉ）前記統合ポイントにより提供される応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記リモートネットワークにより提供される前記コンピューティングサービスの記述と前記データベーステーブルのフィールドとの間のマッピングを定義することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記ページネーションタイプ及び前記統合ポイントから、前記リモートネットワークに対する第２の統合ポイントを判定することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記第２の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
    前記コンピューティングサービスニュートラルクラウド統合アプリケーションによって、前記データベーステーブルの前記フィールド内に、前記マッピングに従って前記第１の記述及び前記第２の記述を格納すること
    を含む動作を前記１つ以上のプロセッサに実施させるプログラム命令をその上に格納した、非一時的なコンピュータ可読媒体を含む製品。
21. リモートネットワークにより提供されるコンピューティングサービスの表現をデータベーステーブル内に格納するように構成された永続ストレージを含む計算インスタンスと、
    前記計算インスタンス内に配備され、
    リモートネットワークの仕様のパラメータに対応するユーザインターフェース要素を有するグラフィカルユーザインターフェース（ＧＵＩ）を生成することと、
    前記ＧＵＩをクライアントデバイスに提供することと、
    前記ＧＵＩを介して前記クライアントデバイスから前記仕様の前記パラメータを受信することであって、前記仕様の前記パラメータは、（ｉ）前記リモートネットワークの統合ポイント、（ｉｉ）前記統合ポイントから受信した応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記リモートネットワークにより提供される前記コンピューティングサービスの記述と前記データベーステーブルのフィールドとの間のマッピングのセットを含むことと、
    前記仕様を前記永続ストレージ内に格納すること
    を含む動作をクラウド統合アプリケーションに実施させるように構成された１つ以上のプロセッサと
    を含むコンピューティングシステム。
22. 前記１つ以上のプロセッサは、
    前記永続ストレージから前記統合ポイント、前記ページネーションタイプ、及び前記仕様のマッピングの前記セットを検索することと、
    前記統合ポイントから、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
    前記データベーステーブルの前記フィールド内に、マッピングの前記セットに従って前記第１の記述を格納すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２１に記載のコンピューティングシステム。
23. 前記仕様の前記パラメータは、前記リモートネットワークにアクセスするための認証クレデンシャルを含み、前記リモートネットワークにより提供される前記コンピューティングサービスの前記第１の記述をリクエスト及び受信するために、前記１つ以上のプロセッサは、
    前記認証クレデンシャルを使用して前記リモートネットワークで認証すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２２に記載のコンピューティングシステム。
24. 前記１つ以上のプロセッサは、
    前記ページネーションタイプ及び前記統合ポイントから、前記リモートネットワークの第２の統合ポイントを判定すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２２に記載のコンピューティングシステム。
25. 前記統合ポイントは、前記リモートネットワークと関連付けられたホスト及びパスを含むユニフォームリソースロケータ（ＵＲＬ）を含み、前記ページネーションタイプは、新たなパスを指定する次のエンドポイントページネーションを含み、前記第２の統合ポイントは、前記リモートネットワークと関連付けられた前記ホスト及び前記新たなパスを含む第２のＵＲＬを含む、請求項２４に記載のコンピューティングシステム。
26. 前記統合ポイントは、前記リモートネットワークと関連付けられたホスト、パス、及びクエリ文字列を含むＵＲＬを含み、前記ページネーションタイプは、新たなクエリ文字列を指定する次のリンクページネーションを含み、前記第２の統合ポイントは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む第２のＵＲＬを含み、前記新たなクエリ文字列は、前記リモートネットワークにより提供される前記コンピューティングサービスの前記第１の記述内の情報に基づいて判定されるキーと値のペアを含む、請求項２４に記載のコンピューティングシステム。
27. 前記統合ポイントは、前記リモートネットワークと関連付けられたホスト、パス、並びにオフセットパラメータ及びサイズパラメータを含むクエリ文字列を含むＵＲＬを含み、前記ページネーションタイプは、第２のオフセットパラメータ及び前記サイズパラメータを含む新たなクエリ文字列を指定するオフセットページネーションを含み、前記第２の統合ポイントは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む第２のＵＲＬを含む、請求項２４に記載のコンピューティングシステム。
28. 前記統合ポイントは、前記リモートネットワークと関連付けられたホスト、パス、及びページパラメータを含むクエリ文字列を含むＵＲＬを含み、前記ページネーションタイプは、第２のページパラメータを含む新たなクエリ文字列を指定するページベースのページネーションを含み、前記第２の統合ポイントは、前記リモートネットワークと関連付けられた前記ホスト、前記パス、及び前記新たなクエリ文字列を含む第２のＵＲＬを含む、請求項２４に記載のコンピューティングシステム。
29. 前記１つ以上のプロセッサは、
    前記第２の統合ポイントから、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
    前記データベーステーブルの前記フィールド内に、マッピングの前記セットに従って前記第２の記述を格納すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２４に記載のコンピューティングシステム。
30. 前記コンピューティングサービスの前記第１の記述は、記述のアレイを含み、前記コンピューティングサービスの前記第２の記述をリクエスト及び受信するために、前記１つ以上のプロセッサは、
    記述の前記アレイ内の個別の記述毎に、
    前記個別の記述で提供されるパラメータを用いて前記第２の統合ポイントを修正することと、
    修正された前記第２の統合ポイントから、前記第２の記述のサブセットをリクエスト及び受信すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２９に記載のコンピューティングシステム。
31. 前記第２の記述の前記サブセットは、記述の第２のアレイを含み、前記１つ以上のプロセッサは、
    前記ページネーションタイプ及び前記第２の統合ポイントから、前記リモートネットワークの第３の統合ポイントを判定することと、
    前記第３の統合ポイントから、前記リモートネットワークにより提供される前記コンピューティングサービスの第３の記述をリクエスト及び受信することであって、前記第３の記述をリクエスト及び受信することは、
    記述の前記第２のアレイ内の個別の記述毎に、
    前記個別の記述で提供されるパラメータを用いて前記第３の統合ポイントを修正することと、
    修正された前記第３の統合ポイントから、前記第３の記述のサブセットをリクエスト及び受信すること
    を含むこと
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項３０に記載のコンピューティングシステム。
32. 前記ＧＵＩのユーザインターフェース要素はテストオプションを含み、前記テストオプションの選択を受信することに応答して、前記１つ以上のプロセッサは、
    前記統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
    前記ページネーションタイプ及び前記統合ポイントから、前記リモートネットワークの第２の統合ポイントを判定することと、
    前記第２の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
    前記クライアントデバイス上に前記第１の記述及び前記第２の記述を提示するために前記ＧＵＩを更新すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２１に記載のコンピューティングシステム。
33. 前記１つ以上のプロセッサは、
    前記ＧＵＩを介して前記クライアントデバイスから第２の仕様の第２のパラメータを受信することであって、前記第２の仕様の前記第２のパラメータは、（ｉ）第２のリモートネットワークの第３の統合ポイント、（ｉｉ）前記第３の統合ポイントから受信した応答と関連付けられた第２のページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記第２のリモートネットワークにより提供される前記コンピューティングサービスの記述と前記データベーステーブルの前記フィールドとの間のマッピングの第２のセットを含むことと、
    前記第２の仕様を前記永続ストレージ内に格納すること
    を含む動作を前記クラウド統合アプリケーションに実施させるように構成される、請求項２１に記載のコンピューティングシステム。
34. リモートネットワークの仕様のパラメータに対応するユーザインターフェース要素を有するグラフィカルユーザインターフェース（ＧＵＩ）を生成することと、
    前記ＧＵＩをクライアントデバイスに提供することと、
    前記ＧＵＩを介して前記クライアントデバイスから前記仕様の前記パラメータを受信することであって、前記仕様の前記パラメータは、（ｉ）前記リモートネットワークの統合ポイント、（ｉｉ）前記統合ポイントから受信した応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記リモートネットワークにより提供されるコンピューティングサービスの記述と永続ストレージ内のデータベーステーブルのフィールドとの間のマッピングのセットを含み、前記データベーステーブルは、前記リモートネットワークにより提供される前記コンピューティングサービスの表現を格納するように構成されることと、
    前記仕様を前記永続ストレージ内に格納すること
    を含む、コンピュータ実装方法。
35. 前記永続ストレージから前記統合ポイント、前記ページネーションタイプ、及び前記仕様のマッピングの前記セットを検索することと、
    前記ページネーションタイプ及び前記統合ポイントから、前記リモートネットワークの第２の統合ポイントを判定することであって、前記統合ポイントは、第１のパス、若しくは第１のクエリ文字列、又はそれらの組み合わせを含むユニフォームリソースロケータ（ＵＲＬ）を含み、前記ページネーションタイプは、第２のパス又は第２のクエリ文字列を指定し、前記第２の統合ポイントは、前記第２のパス、若しくは前記第２のクエリ文字列、又はそれらの組み合わせを含む第２のＵＲＬを含むこと
    を含む、請求項３４に記載の方法。
36. 前記統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
    前記第２の統合ポイントを介して、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
    前記データベーステーブルの前記フィールド内に、マッピングの前記セットに従って前記第１の記述及び前記第２の記述を格納すること
    を含む、請求項３５に記載の方法。
37. コンピューティングシステムの１つ以上のプロセッサにより実行可能な命令を格納する非一時的コンピュータ可読媒体であって、前記コンピューティングシステムは、リモートネットワークにより提供されるコンピューティングサービスの表現を格納するように構成されたデータベーステーブルを有する永続ストレージを含み、前記命令は、
    リモートネットワークの仕様のパラメータに対応するユーザインターフェース要素を有するグラフィカルユーザインターフェース（ＧＵＩ）を生成することと、
    前記ＧＵＩをクライアントデバイスに提供することと、
    前記ＧＵＩを介して前記クライアントデバイスから前記仕様の前記パラメータを受信することであって、前記仕様の前記パラメータには、（ｉ）第１のパス、第１のクエリ文字列、又はそれらの組み合わせを含む前記リモートネットワークの統合ポイントの第１のユニフォームリソースロケータ（ＵＲＬ）、（ｉｉ）前記統合ポイントから受信した応答と関連付けられたページネーションタイプ、及び（ｉｉｉ）前記応答に現れる前記リモートネットワークにより提供される前記コンピューティングサービスの記述と前記データベーステーブルのフィールドとの間のマッピングのセットを含み、前記ページネーションタイプは、第２のパス、若しくは第２のクエリ文字列、又はそれらの組み合わせを指定することと、
    前記統合ポイント及び前記ページネーションタイプに基づいて、前記リモートネットワークの第２の統合ポイントの第２のＵＲＬを判定することであって、前記第２のＵＲＬは、前記第２のパス、若しくは前記第２のクエリ文字列、又はそれらの組み合わせを含むことと、
    前記仕様を前記永続ストレージ内に格納すること
    のための命令を含む、非一時的コンピュータ可読媒体。
38. 前記命令は、
    前記第１のＵＲＬから、前記リモートネットワークにより提供される前記コンピューティングサービスの第１の記述をリクエスト及び受信することと、
    前記第１の記述に基づいて、前記第２のクエリ文字列のキーと値のペアを判定することと、
    前記第２のクエリ文字列を含む前記第２のＵＲＬから、前記リモートネットワークにより提供される前記コンピューティングサービスの第２の記述をリクエスト及び受信することと、
    前記データベーステーブルの前記フィールド内に、マッピングの前記セットに従って前記第１の記述及び前記第２の記述を格納すること
    のための命令を含む、請求項３７に記載の非一時的コンピュータ可読媒体。
39. 前記第１のＵＲＬの前記第１のクエリ文字列は、第１のオフセットパラメータ値及びサイズパラメータ値を含み、前記第２のＵＲＬの前記第２のクエリ文字列は、第２のオフセットパラメータ値及び前記サイズパラメータ値を含む、請求項３７に記載の非一時的コンピュータ可読媒体。
40. 前記第１のＵＲＬの前記第１のクエリ文字列は第１のページパラメータ値を含み、前記第２のＵＲＬの前記第２のクエリ文字列は第２のページパラメータ値を含む、請求項３７に記載の非一時的コンピュータ可読媒体。

Images