(57)【特許請求の範囲】
【請求項１】
クラウドベースのサービス交換システムであって、
複数のネットワークが接続するスイッチングファブリックのそれぞれのポートを含む、ネットワークデータセンターであって、前記ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客及びクラウドサービスプロバイダのうちの異なる一つと関連し、クラウドサービスプロバイダに関連する各ネットワークは、クラウドサービスプロバイダに関連する各ネットワークのためのコンピュータ資源であって、前記複数の顧客に関連する１つ以上の前記ネットワークに少なくとも１つのクラウドサービスを提供する、前記ネットワークデータセンター内にコロケーションされる、コンピューティング資源、を含む、ネットワークデータセンターと、
前記ネットワークデータセンター内にあり、前記ネットワークデータセンターの前記スイッチングファブリックを通って、前記クラウドベースのサービス交換システムの前記複数の顧客と関連する前記ネットワークの各々を、前記クラウドサービスプロバイダと関連する前記ネットワークのうちの一つ以上に接続するように構成される、複数の相互接続資産であって、前記複数の相互接続資産は、前記複数の顧客と関連する前記ネットワークの各々に対する、一つ以上の仮想回路であって、前記スイッチングファブリックを通るエンドツーエンドインターネットプロトコル（ＩＰ）経路を含み、前記複数の顧客と関連する前記ネットワークにより、前記複数のクラウドサービスプロバイダと関連する前記ネットワーク内で実行されるクラウドサービスに対する、前記ネットワークデータセンター内での、レイヤ３のネットワーク接続性を提供する一つ以上の仮想回路のそれぞれの１組を含む、複数の相互接続資産と、
一つ以上の管理デバイスによって実行するように構成される相互接続プラットフォームであって、アプリケーションからの要求の受信に応じて、前記要求を満たすように、前記複数の相互接続資産にアクセスするように構成されるソフトウェアインタフェースを提示する、相互接続プラットフォームと、
を備える、クラウドベースのサービス交換システム。
【請求項２】
前記ソフトウェアインタフェースは、前記アプリケーションからの前記要求に応じて、前記複数の相互接続資産の利用可能な相互接続資産を示すデータを返送するように構成される、少なくとも一つの方法を含む、検出アプリケーションプログラミングインタフェースを備える、請求項１に記載のクラウドベースのサービス交換システム。
【請求項３】
前記ソフトウェアインタフェースは、前記アプリケーションからの前記要求に応じて、前記相互接続プラットフォームに、前記仮想回路のうちの一つをプロビジョニングさせ、前記仮想回路のうちの一つを検証し、又は前記仮想回路のうちの一つの削除を確認するように構成される方法を含む、処理アプリケーションプログラミングインタフェースを備える、請求項１〜２のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項４】
前記ソフトウェアインタフェースは、前記アプリケーションからの前記要求に応じて、クラウドサービスに推奨される設定情報、並びにクラウドサービスに関する競合他社の存在、クラウドサービスの存在、クラウドサービスの可用性、顧客の存在、顧客の獲得可能性、及び稼働率統計に関するカスタマイズされた分析のうちの一つを返送するように構成される、少なくとも一つの方法を含む、使用アプリケーションプログラミングインタフェースを備える、請求項１〜３のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項５】
前記要求は、前記顧客のうちの一つの顧客を指定し、
前記ソフトウェアインタフェースは、前記アプリケーションからの前記要求に応じて、アカウントの管理のうちの少なくとも一つを実施し、前記顧客に請求書を送付し、前記顧客のクレジットを検証し、前記アプリケーションと関連するエンティティのプロファイルを構成し、前記アプリケーションと関連するエンティティのポリシーを構成するように構成される、少なくとも一つの方法を含む、支援アプリケーションプログラミングインタフェースを備える、
請求項１〜４のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項６】
前記ソフトウェアインタフェースは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴｆｕｌ）インタフェースを備え、
前記要求は、前記複数の相互接続資産のうちの一つの相互接続資産に対して、インタフェース方法及びリソース識別子を指定する、アプリケーションデータを備える、
請求項１〜５のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項７】
前記複数の相互接続資産は、ポート、クラウドサービス、前記仮想回路の帯域幅、及び前記仮想回路のうちの少なくとも一つをさらに含む、請求項１〜６のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項８】
前記相互接続プラットフォームは、
前記相互接続資産を管理するために、少なくとも一つのクラウドエクスチェンジプラットフォームサービスを実行するように構成される、オーケストレーションエンジンと、
前記要求を受信するように、前記ソフトウェアインタフェースを実行し、
前記要求を満たすよう、前記複数の相互接続資産にアクセスするように、前記少なくとも一つのクラウドエクスチェンジプラットフォームサービスを呼び出し、
前記クラウドエクスチェンジプラットフォームサービスから応答を受信し、
前記アプリケーションに前記応答の表示を送信するように構成される、アプリケーションプログラミングインタフェースゲートウェイと、
を備える、請求項１〜７のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項９】
前記相互接続プラットフォームは、
クラウドエクスチェンジサービスを実行するように構成される、複数のマイクロサービスと、
前記要求を満たすようにワークフローに従って前記クラウドエクスチェンジサービスを実行するよう、前記複数のマイクロサービスを調整するように構成されるオーケストレーションエンジンと、
を備える、請求項１に記載のクラウドベースのサービス交換システム。
【請求項１０】
前記オーケストレーションエンジンは、ポリシー及びクラウドサービスプロファイルのうちの少なくとも一つを、前記要求に含まれる顧客識別子に適用することによって、前記ワークフローを識別するように構成され、
前記ワークフローは、前記複数のクラウドエクスチェンジサービスの一連の要求を備える、
請求項９に記載のクラウドベースのサービス交換システム。
【請求項１１】
前記要求を満たすよう前記複数の相互接続資産にアクセスするために、前記相互接続プラットフォームは、前記仮想回路のうちの一つをプロビジョニングするように構成される、請求項１〜１０のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項１２】
前記相互接続プラットフォームは、
クラウドサービスのクエリサービスと、
オーケストレーションエンジンと、
前記要求の受信に応じて、クラウドサービスを示すデータを取得するよう、前記オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、を備え、
前記オーケストレーションエンジンは、前記クラウドサービスのクエリサービスを呼び出すように、ワークフローを生成及び実行し、
前記クラウドサービスのクエリサービスは、前記オーケストレーションエンジンに、前記クラウドサービスを示す前記データを返送し、
前記オーケストレーションエンジンは、前記アプリケーションプログラミングインタフェースゲートウェイに、前記クラウドサービスを示す前記データを返送し、
前記要求に応答して、前記アプリケーションプログラミングインタフェースゲートウェイは、前記アプリケーションに、前記クラウドサービスを示す前記データを返送する、
請求項１〜９のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項１３】
前記相互接続プラットフォームは、
仮想回路クエリサービスと、
オーケストレーションエンジンと、
前記要求の受信に応じて、仮想回路を示すデータを取得するよう、前記オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、
前記オーケストレーションエンジンは、前記仮想回路クエリサービスを呼び出すように、ワークフローを生成及び実行し、
前記仮想回路クエリサービスは、前記オーケストレーションエンジンに、前記仮想回路を示す前記データを返送し、
前記オーケストレーションエンジンは、前記アプリケーションプログラミングインタフェースゲートウェイに、前記仮想回路を示す前記データを返送し、
前記要求に応答して、前記アプリケーションプログラミングインタフェースゲートウェイは、前記アプリケーションに、前記仮想回路を示す前記データを返送する、
請求項１〜９のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項１４】
前記要求は、顧客にクラウドサービスプロバイダネットワークへのアクセスを提供するように、仮想回路をプロビジョニングする要求を備え、
前記相互接続プラットフォームは、
ネットワークサービスのプロビジョニングサービスと、
オーケストレーションエンジンと、
前記要求の受信に応じて、前記仮想回路をプロビジョニングするよう、前記オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、
をさらに備え、
前記オーケストレーションエンジンは、前記ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行し、
前記ネットワークサービスのプロビジョニングサービスは、前記要求のパラメータに従って前記仮想回路を確立する、
請求項１〜９のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項１５】
前記相互接続プラットフォームは、
前記オーケストレーションエンジンが、前記クラウドサービスプロバイダネットワークの一つ以上のクラウドサービスプロバイダのうちの一つのクラウドサービスプロバイダによる前記仮想回路の確認を要求するように、前記ワークフローを生成及び実行し、
前記オーケストレーションエンジンが、前記クラウドサービスプロバイダによる前記仮想回路の確認の受信に応答する、前記ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行する、請求項１４に記載のクラウドベースのサービス交換システム。
【請求項１６】
前記顧客は、ネットワークサービスプロバイダ及び企業のうちの一つを備える、請求項１〜１５のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項１７】
データセンター内に設置される、レイヤ３（Ｌ３）自律システムであって、
前記Ｌ３自律システムが、前記複数のネットワークのうちの複数のクラウドサービスプロバイダネットワークの各々から、少なくとも一つのクラウドサービス、及び前記複数のネットワークのうちの一つ以上の顧客ネットワークへの配信のためのクラウドサービストラフィックを受信するように構成される、レイヤ３（Ｌ３）自律システムと、
前記データセンター内で、前記それぞれの複数のクラウドサービスプロバイダネットワークを、前記Ｌ３自律システムに接続するように構成される、複数の連結回路と、
前記データセンター内で、前記一つ以上の顧客ネットワークそれぞれを前記Ｌ３自律システムに接続するように構成される、一つ以上の連結回路と、
をさらに備え、
前記Ｌ３自律システムは、前記複数のクラウドサービスプロバイダネットワークと前記一つ以上の顧客ネットワークとの間に、前記仮想回路の前記エンドツーエンドＩＰ経路を確立することによって、前記複数のクラウドサービスプロバイダネットワークと前記一つ以上の顧客ネットワークとを相互接続するように構成され、各エンドツーエンドＩＰ経路は、前記複数のクラウドサービスプロバイダネットワークそれぞれを前記Ｌ３自律システムに接続する、前記複数の連結回路のうちの一つを含み、また前記一つ以上の顧客ネットワークそれぞれを前記Ｌ３自律システムに接続する、前記一つ以上の連結回路のうちの一つも含み、
前記Ｌ３自律システムは、前記複数のクラウドサービスプロバイダネットワークそれぞれを前記エンドツーエンドＩＰ経路に沿って接続する、前記複数の連結回路上で受信されるクラウドサービストラフィックを、前記一つ以上の顧客ネットワークそれぞれを前記Ｌ３自律システムに接続する前記一つ以上の連結回路に転送するように構成される、
請求項１〜１６のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項１８】
前記Ｌ３自律システムのルータに記憶されたＬ３ルートは、前記複数のクラウドサービスプロバイダネットワーク及び前記一つ以上の顧客ネットワーク以外のネットワークへのＬ３到達可能性を指定しない、
請求項１７に記載のクラウドベースのサービス交換システム。
【請求項１９】
前記Ｌ３自律システムの自律システム境界ルータは、Ｌ３ルートで構成されるＢＧＰルーティングテーブルを含み、
前記Ｌ３ルートは、ＢＧＰルートを備え、
前記ＢＧＰルーティングテーブルは、完全なＢＧＰテーブルではなく、インターネットへの接続性を提供しない、
請求項１７に記載のクラウドベースのサービス交換システム。
【請求項２０】
クラウドベースのサービス交換システムのスイッチングファブリックを通って、前記スイッチングファブリックに結合された顧客ネットワークを、前記スイッチングファブリックに結合された一つ以上のクラウドサービスプロバイダネットワークに接続するように構成され、前記クラウドベースのサービス交換システムを有するデータセンター内にコロケーションされる複数の相互接続資産であって、前記顧客ネットワークが、前記一つ以上のクラウドサービスプロバイダネットワークのコンピューティング資源上で実行されるクラウドサービスによって生じるトラフィックを受信するための仮想回路であって、前記スイッチングファブリックを通るエンドツーエンドインターネットプロトコル（ＩＰ）経路を含み、前記クラウドサービスから前記顧客ネットワークへのレイヤ３のネットワーク接続性を提供する仮想回路を含む、複数の相互接続資産と、
前記複数の相互接続資産を修正するように構成される、オーケストレーションエンジンと、
を備える、クラウドベースのサービス交換システム。
【請求項２１】
クラウドエクスチェンジサービスを実行するように構成される、複数のマイクロサービス、をさらに備え、
前記複数の相互接続資産を修正するために、前記オーケストレーションエンジンは、ワークフローに従って、前記複数のクラウドエクスチェンジサービスを調整するように構成される、
請求項２０に記載のクラウドベースのサービス交換システム。
【請求項２２】
アプリケーションによって発行される要求の受信に応じて、前記要求を満たすよう、前記複数の相互接続資産にアクセスするように構成される、ソフトウェアインタフェースを有する、相互接続プラットフォームと、
前記要求に少なくとも基づいて、前記オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、
をさらに備え、
前記複数の相互接続資産を修正するために、前記オーケストレーションエンジンは、前記オーケストレーションエンジンを呼び出す前記アプリケーションプログラミングインタフェースゲートウェイに応じて、前記複数の相互接続資産を修正するように構成される、
請求項２０〜２１のいずれか一項に記載のクラウドベースのサービス交換システム。
【請求項２３】
一つ以上の管理デバイスを使用するクラウドベースのサービス交換システムによって、複数の顧客と関連するネットワークが到達可能なソフトウェアインタフェースを提示するように、相互接続プラットフォームを実行することと、
アプリケーションからの要求の受信に応じる前記相互接続プラットフォームによって、前記要求を満たすように、ネットワークデータセンターの複数の相互接続資産にアクセスすることと、
を含み、
前記ネットワークデータセンターは、複数のネットワークが接続するスイッチングファブリックのそれぞれのポートを含み、前記ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客及びクラウドサービスプロバイダのうちの異なる一つと関連し、
前記ネットワークデータセンター内にある複数の相互接続資産は、前記ネットワークデータセンターの前記スイッチングファブリックを通って、前記クラウドベースのサービス交換システムの前記複数の顧客と関連する前記ネットワークの各々を、前記クラウドサービスプロバイダと関連する前記ネットワークのうちの一つ以上に接続し、
クラウドサービスプロバイダに関連する各ネットワークは、前記ネットワークデータセンター内にコロケーションされるコンピューティング資源であって、前記複数の顧客に関連する一つ以上の前記ネットワークに少なくとも一つのクラウドサービスを提供する、前記クラウドサービスプロバイダに関連する各ネットワークに対するコンピューティング資源、を含み、
前記複数の相互接続資産は、前記複数の顧客と関連する前記ネットワークの各々に対する、一つ以上の仮想回路であって、前記スイッチングファブリックを通るエンドツーエンドインターネットプロトコル（ＩＰ）経路をそれぞれ含み、前記複数の顧客に関連する前記ネットワークによって、前記複数のクラウドサービスプロバイダに関連する前記ネットワーク内で実行されるクラウドサービスへの前記ネットワークデータセンター内のレイヤ３のネットワーク接続性を提供する一つ以上の仮想回線のそれぞれの１組を含む、  方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１４年１０月３０日出願の米国特許仮出願番号第６２／０７２，９７６号、２０１５年９月２８日出願の米国特許仮出願番号第６２／２３３，９３３号、及び２０１５年１０月２９日出願の米国出願番号第１４／９２７，４５１号の利益を主張するものであり、それらの各々の内容は参照により全て本発明に援用される。
【０００２】
本発明は、コンピュータネットワークに関し、より具体的には、クラウドサービスの顧客とクラウドサービスプロバイダとの間の相互接続性を促進するプラットフォームに関する。
【背景技術】
【０００３】
クラウドコンピューティングとは、インターネットなどのネットワークを介してアクセス可能な、動的に拡張可能なコンピューティングリソースの使用を指す。よく「クラウド」と呼ばれるコンピューティングリソースは、一つ以上のサービスをユーザに提供する。これらのサービスは、サービスタイプに従って分類されてもよく、例えば、アプリケーション／ソフトウェア、プラットフォーム、インフラ、仮想化、並びにサーバ及びデータ記憶部を含んでもよい。サービスタイプ名は、「ａｓ‐ａ‐Ｓｅｒｖｉｃｅ」という語句の前に追加されることが多く、例として、アプリケーション／ソフトウェア及びインフラのデリバリは、それぞれＳｏｆｔｗａｒｅ‐ａｓ‐ａ‐Ｓｅｒｖｉｃｅ（ＳａａＳ）及びＩｎｆｒａｓｔｒｕｃｔｕｒｅ‐ａｓ‐ａ‐Ｓｅｒｖｉｃｅ（ＩａａＳ）と呼んでもよい。
【０００４】
用語「クラウドベースのサービス」又はより簡単に「クラウドサービス」は、クラウドによって提供されるサービスだけでなく、クラウドの顧客が、クラウドにより提供されるサービスのオンラインデリバリのために、クラウドサービスプロバイダと契約するサービスプロビジョニングの形態も指す。クラウドサービスプロバイダは、パブリッククラウド、プライベートクラウド、又はハイブリッドクラウドを管理し、一つ以上のクラウドの顧客へのクラウドサービスのオンラインデリバリを促進する。
【発明の概要】
【０００５】
概して、本開示は、複数のクラウドサービスプロバイダから一つ以上のクラウドの顧客へのクラウドサービスデリバリのための仮想接続を促進するように、クラウドベースのサービス交換、すなわち「クラウドエクスチェンジ」を動的に構成及び管理する、相互接続プラットフォームについて記載する。クラウドエクスチェンジによって、クラウドの顧客が、性能を向上させ、費用を削減し、接続のセキュリティ及びプライバシーを高め、クラウドコンピューティングをさらなる用途に利用するために、パブリックインターネットを迂回して、クラウドサービスプロバイダに直接接続することが可能となってもよい。このように、企業、ネットワーク回線事業者、及びＳａａＳ顧客は、例えば、クラウドサービスを、当該サービスが自身のデータセンターネットワークの一部であるか、又はそうでなければ自身のデータセンターネットワークに直接連結しているかのように、内部アプリケーションと統合できる。
【０００６】
いくつかの実施例では、クラウドエクスチェンジの相互接続プラットフォームにより、本明細書でも言及され、アプリケーションプログラミングインタフェース（ＡＰＩ）に従って記載され、プログラム可能な様式で相互接続プラットフォームの機能及び資産へのアクセスを可能にする、ソフトウェアインタフェースの一群が公開される。そのため、ソフトウェアインタフェースは、エクスチェンジの顧客及びパートナーと関連するソフトウェア開発者が、相互接続プラットフォームに参加する複数のクラウドサービスプロバイダとの相互接続を自動で管理する、相互接続プラットフォームにアクセスする、ソフトウェアアプリケーションを構築することを可能にする、拡張可能なフレームワークを提供する。言い換えると、ネットワークサービスプロバイダ、クラウドサービスプロバイダ、マネージドサービスプロバイダ、及びその他企業の開発者は、クラウドサービスプロバイダからクラウドサービスの顧客へのクラウドサービスのデリバリを促進するよう、相互接続プラットフォームとシームレスに相互作用するために、カスタムアプリケーション及びフレームワークを構築するように、相互接続プラットフォームによって公開され、ＡＰＩによって定義されるソフトウェアインタフェースを使用してもよい。
【０００７】
ＡＰＩによって定義されるこれらのソフトウェアインタフェースにより、相互接続をほぼリアルタイムで設定及び修正するための、マシンツーマシン通信が可能になり、また相互接続の設定及び管理プロセス全体に対して、人との相互作用の必要性が排除又は削減されてもよい。このように、ソフトウェアインタフェースは、相互接続プラットフォームに参加する複数のクラウドプロバイダとの相互接続を確立、削除、及び管理する、自動化されたシームレスな手段を提供する。
【０００８】
一実施例では、相互接続プラットフォームは、クラウドエクスチェンジのための相互接続の様々な態様を管理する、基になるソフトウェア及びネットワークサブシステムを構築、運営、及び統合する、内部オーケストレーションエンジンを含む。例えば、オーケストレーションエンジンは、エクスチェンジのＡＰＩと基になる相互接続プラットフォームとの間で動作する、ルール駆動型のワークフローエンジンを提供してもよい。このように、オーケストレーションエンジンは、クラウドエクスチェンジの相互接続プラットフォーム内で直接参加するために、顧客専用のアプリケーション及びＡＰＩによって使用できる。
【０００９】
本明細書に記載する通り、オーケストレーションエンジンは、顧客アプリケーションによってなされる動的な要求に対して、インテリジェントな次のステップ及び応答を組み立てるように、情報及び操作を合成する。そうして、オーケストレーションエンジンは、相互接続プラットフォームにアクセスする均一で簡易化された安全な手段を提供することによって、クラウドエクスチェンジの基になるソフトウェア及びネットワークサブシステムの複雑さを取り除く。
【００１０】
いくつかの実施例では、クラウドベースのサービス交換は、複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含む、ネットワークデータセンターであって、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連する、ネットワークデータセンターと、ネットワークデータセンター内にあり、ネットワークデータセンターのスイッチングファブリックを通って、クラウドベースのサービス交換の複数の顧客と関連するネットワークの各々を、クラウドサービスプロバイダと関連するネットワークのうちの一つ以上に接続するように構成される、複数の相互接続資産であって、複数の顧客と関連するネットワークの各々に対する、一つ以上の仮想回路のそれぞれの１組を含み、複数の顧客と関連するネットワークと、複数のクラウドサービスプロバイダと関連するネットワーク内から実行されるクラウドサービスとの間のネットワークデータセンター内に、ネットワーク接続性を提供する、複数の相互接続資産と、ネットワークデータセンター内の一つ以上の管理デバイス上で実行され、複数の顧客と関連するネットワークによって到達可能で、顧客と関連するネットワークのいずれか内で実行されるアプリケーションによって発行される要求の受信に応じて、要求を満たすよう、複数の相互接続資産にアクセスするように構成される、ソフトウェアインタフェースを提示する、相互接続プラットフォームとを備える。
【００１１】
いくつかの実施例では、クラウドベースのサービス交換は、クラウドベースのサービス交換の顧客を、一つ以上のクラウドサービスプロバイダに接続するように構成される、複数の相互接続資産であって、顧客が一つ以上のクラウドサービスプロバイダからクラウドサービスにアクセスするのに利用する仮想回路を含む、複数の相互接続資産と、複数の相互接続資産を修正するように構成される、オーケストレーションエンジンとを備える。
【００１２】
いくつかの実施例では、方法は、ネットワークデータセンター内の一つ以上の管理デバイス上におけるクラウドベースのサービス交換によって、複数の顧客と関連するネットワークが到達可能なソフトウェアインタフェースを提示するように、相互接続プラットフォームを実行することと、顧客と関連するネットワークのいずれか内で実行されるアプリケーションによって発行される要求の受信に応じて、要求を満たすよう、ネットワークデータセンターの複数の相互接続資産にアクセスすることと、を含み、ネットワークデータセンターは、複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含み、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連し、ネットワークデータセンター内にある複数の相互接続資産は、ネットワークデータセンターのスイッチングファブリックを通って、クラウドベースのサービス交換の複数の顧客と関連するネットワークの各々を、クラウドサービスプロバイダと関連するネットワークのうちの一つ以上に接続し、複数の相互接続資産は、複数の顧客と関連するネットワークの各々に対する、一つ以上の仮想回路のそれぞれの１組を含み、複数の顧客と関連するネットワークと、複数のクラウドサービスプロバイダと関連するネットワーク内から実行されるクラウドサービスとの間のネットワークデータセンター内に、ネットワーク接続性を提供する。
【００１３】
本発明の一つ以上の実施形態の詳細は、添付図面及び以下の記述において説明する。本発明の他の特徴、目的、及び利点は、本明細書及び図面、並びに請求項より明らかである。
【図面の簡単な説明】
【００１４】
【図１Ａ】クラウドベースのサービス交換に動作環境を提供する、データセンターの上位レベル図を示すブロック図である。
【図１Ｂ】本明細書に記載するいくつかの例示の実装に従う、クラウドベースのサービス交換を示すブロック図である。
【図１Ｃ】クラウドベースのサービス交換の別の例示の実装を示す。
【図１Ｄ】本開示の技術に従い、相互接続プラットフォームによって管理されるクラウドエクスチェンジの複数のクラウドエクスチェンジポイントが、地理的に分散する回線事業者間での交差接続を利用可能とする実施例を示すブロック図である。
【図２】本明細書に記載する技術に従う、クラウドエクスチェンジの例示アーキテクチャの詳細を示すブロック図である。
【図３Ａ】本明細書に記載する技術に従う、相互接続ソフトウェアインタフェースのフロー図を示す。
【図３Ｂ】本明細書に記載する技術に従う、相互接続ソフトウェアインタフェースのフロー図を示す。
【図４】本開示に記載する技術に従う、クラウドエクスチェンジ用の相互接続プラットフォーム１０３の代替の説明を示すブロック図である。
【図５】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図６】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図７】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図８】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図９】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図１０】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図１１】本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。
【図１２】本開示の一つ以上の技術に従い動作する、コンピュータデバイスの一実施例のさらなる詳細を示すブロック図である。
【図１３】本明細書に記載する技術に従い、さらに詳細にオーケストレーションエンジンの論理アーキテクチャを示す、例示のシステムを図示するブロック図である。
【図１４】本明細書に記載する技術に従い、さらに詳細にオーケストレーションエンジンの参照アーキテクチャを示す、例示のシステムを図示するブロック図である。
【図１５】本開示の例示的態様に従い、オーケストレーションエンジンによって実施される例示のワークフローを示すフローチャートである。
【図１６】本開示の例示的態様に従う、仮想回路の作成に関係する例示のオーケストレーションエンジンのワークフローを示す、例示の論理図である。
【図１７】本開示の例示的態様に従う、従業員の給与情報取得に関係する例示のオーケストレーションエンジンのワークフローを示す、例示の論理図である。
【図１８Ａ】本開示に記載する技術に従い、クラウドエクスチェンジプロバイダの顧客に対するプロビジョニングのために、複数のクラウドサービスプロバイダのクラウドサービスを集約し、一つ以上のクラウドサービスプロバイダへの複数の顧客のアクセスを集約する、クラウドエクスチェンジ用のプログラム可能なネットワークプラットフォームによる、例示のネットワークインフラ及びサービスプロビジョニングを示すブロック図である。
【図１８Ｂ】本開示に記載する技術に従い、クラウドエクスチェンジプロバイダの顧客に対するプロビジョニングのために、複数のクラウドサービスプロバイダのクラウドサービスを集約し、一つ以上のクラウドサービスプロバイダへの複数の顧客のアクセスを集約する、クラウドエクスチェンジ用のプログラム可能なネットワークプラットフォームによる、例示のネットワークインフラ及びサービスプロビジョニングを示すブロック図である。
【図１９】本明細書に記載する技術に従い、クラウドエクスチェンジポイントのルータが、複数のクラウドサービスプロバイダネットワークから顧客ネットワークへ集約されたサービストラフィックをルーティング及び転送するために、仮想プライベートネットワークのルーティング及び転送インスタンスを用いて、相互接続プラットフォームによって構成される、データセンターをベースとするクラウドエクスチェンジポイントの実施例を示すブロック図である。
【図２０】本開示に記載する技術に従う、開発フレームワークの論理的な考え方を示す概念図である。
【図２１】本開示に記載する技術に従い、マイクロサービスをベースとするアプリケーションのスキャフォールディング、構築、テスト、及び配備を促進する、開発フレームワークの構成要素をさらに詳細に示すブロック図である。
【図２２】本開示に記載する開発フレームワーク及び技術を使用して、マイクロサービスをベースとするアプリケーションアーキテクチャに従い、アプリケーションを開発する例示の開発プロセスを示すフロー図である。
【図２３】本開示に記載する技術に従い、開発フレームワークによって実施され、オーケストレーション定義及びマイクロサービス定義を通じて実行される、開発フレームワークプロジェクト及びエンドツーエンドのスキャフォールディングプロセスの構成要素を示す概念図である。
【図２４】本明細書に記載する技術に従う、開発フレームワーク用の例示のインタフェース及び入力／出力を示す。
【図２５】本明細書に記載する技術に従う、開発フレームワーク用の例示のインタフェース及び入力／出力を示す。
【図２６】本明細書に記載する技術に従う、開発フレームワーク用の例示のインタフェース及び入力／出力を示す。
【図２７】本開示に記載する技術に従う開発フレームワークを使用して開発される、クラウドベースのサービス交換用相互接続プラットフォームの構成要素を示すブロック図である。
【図２８】本開示の一つ以上の技術に従い動作する、コンピュータデバイスの一実施例のさらなる詳細を示すブロック図である。
【発明を実施するための形態】
【００１５】
図及び文章中では、同様の参照符号は同様の要素を示す。
【００１６】
概して、本開示は、クラウドベースのサービス交換（「クラウドエクスチェンジ」）をリアルタイムで構成及び管理するための、相互接続プラットフォームについて記載する。本明細書に記載する通り、相互接続プラットフォームは、例えば、企業、ネットワーク回線事業者、及びＳａａＳ顧客といったエクスチェンジの顧客に、複数のクラウドサービスプロバイダ（ＣＳＰ）への安全な仮想プライベート接続をグローバルに提供する。複数のＣＳＰは、顧客が、ＣＳＰによって提供される一つ以上のクラウドサービスに接続できるクラウドエクスチェンジにおいて、それぞれ少なくとも一つのアクセス可能なポートを有することから、クラウドエクスチェンジに参加する。
【００１７】
本明細書に記載する様々な実施例に従い、いずれの顧客のプライベートネットワークも、共有ポイントでいかなる他の顧客にも直接交差接続が可能となり、それによって、顧客ネットワーク間のネットワークトラフィックの直接交換が可能となる、クラウドエクスチェンジについて記載する。顧客には、ネットワーク回線事業者（又はネットワークサービスプロバイダ）、企業、及び一つ以上のクラウドサービスプロバイダによって提供されるクラウドサービスのその他ユーザを含んでもよい。
【００１８】
図１Ａは、クラウドベースのサービス交換１００に動作環境を提供する、データセンター１０１の上位レベル図を示すブロック図である。クラウドベースのサービス交換１００（「クラウドエクスチェンジ１００」）によって、いずれの回線事業者１０６Ａ〜１０６Ｃ（総称して「回線事業者１０６」）又は顧客１０７Ａ、１０７Ｂを含むその他のクラウドの顧客の顧客ネットワーク１０４Ｄ、１０４Ｅ、及び回線事業者ネットワーク１０４Ａ〜１０４Ｃ（総称して「プライベートネットワーク１０４」）のうちの対応する一つを、仮想レイヤ２（Ｌ２）又はレイヤ３（Ｌ３）接続で、いかなる他の顧客ネットワーク及び／又はクラウドサービスプロバイダ１１０Ａ〜１１０Ｎ（総称して「ＣＳＰ１１０」）のうちのいずれかへ直接交差接続することが可能となり、それによって、顧客ネットワークとＣＳＰ１１０との間でネットワークトラフィックの直接交換が可能になる。
【００１９】
回線事業者１０６は各々、回線事業者１０６のネットワーク加入者が、クラウドエクスチェンジ１００を経由してＣＳＰ１１０によって提供されるクラウドサービスにアクセスできる、トランジットネットワークと関連するネットワークサービスプロバイダを表してもよい。概して、ＣＳＰ１１０の顧客は、ネットワーク回線事業者、大企業、マネージドサービスプロバイダ（ＭＳＰ）だけでなく、クラウドエクスチェンジ１００を経由してＣＳＰ１１０によって提供されるクラウドベースのサービスのような、Ｓｏｆｔｗａｒｅ‐ａｓ‐a‐Ｓｅｒｖｉｃｅ（ＳａａＳ）、Ｐｌａｔｆｏｒｍ-ａａＳ（ＰａａＳ）、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ-ａａＳ（ＩａａＳ）、Ｖｉｒｔｕａｌｉｚａｔｉｏｎ-ａａＳ（ＶａａＳ）、及びｄａｔａ  Ｓｔｏｒａｇｅ-ａａＳ（ｄＳａａＳ）の顧客も含んでもよい。
【００２０】
このように、クラウドエクスチェンジ１００は、透過的かつ中立的に、ＣＳＰ１１０及び顧客と（回線事業者１０６を経由して又は直接）提携するプロセスを簡素化及び簡易化する。クラウドエクスチェンジ１００の一例示的用途は、ＣＳＰ１１０及び回線事業者１０６並びに／又は顧客１０７が、一つ以上のアクセス可能なポートをデータセンター内で相互接続に利用可能にすることによってなど、既にネットワークが存在していてもよい、コロケーションで相互接続するデータセンターである。これによって、参加する回線事業者、顧客、及びＣＳＰが、同じ施設において幅広い相互接続性の選択肢を有することが可能になる。データセンター１０１のクラウドエクスチェンジ１００は、ＣＳＰ１１０及び顧客／回線事業者が相互に接続する、Ｌ２／Ｌ３スイッチングファブリックを提供するネットワークインフラ１２２を含む。これによって、回線事業者／顧客が、クラウドエクスチェンジ１００のスイッチファブリックの基本相互接続プラットフォーム１０３への一度のみの接続で、多対多の相互接続を作成する選択肢を有することが可能になる。言い換えると、一つ以上のクラウドサービスプロバイダのうちの異なるクラウドサービスプロバイダ又は異なるクラウドサービスにアクセスするように、トランジットネットワーク上で別々の接続を確立しなくてはならないということの代わりに、クラウドエクスチェンジ１００によって、顧客は、データセンター１０１内のネットワークインフラ１２２を使用して、複数のＣＳＰ及びクラウドサービスに相互接続することが可能になる。
【００２１】
クラウドエクスチェンジ１００に接続して利用することによって、顧客は、複数のＣＳＰ１１０との複数の仮想接続を組み込み維持することと通常関連する、同じ出費を負担することなく、多くの地理上異なる地域で、サービスを購入し多くのエンドユーザに接触できる。例えば、回線事業者１０６Ａは、回線事業者１０６Ｄのネットワーク１０４Ｄを使用して、自身のサービスを拡大できる。クラウドエクスチェンジ１００に接続することによって、回線事業者１０６は、その他の回線事業者に自身のネットワークサービスの販売を提供することによって、さらなる収入を生み出すことができてもよい。例えば、回線事業者１０６Ｄは、その他の回線事業者に、回線事業者ネットワーク１０４Ｄを使用する機会を提供できる。
【００２２】
本明細書に記載するいくつかの例示の実装では、クラウドエクスチェンジ１００は、ソフトウェアインタフェースの一群を公開する、相互接続プラットフォーム１０３を含み、ソフトウェアインタフェースの一群は、アプリケーションが相互接続プラットフォーム１０３を呼び出すことができる方法、フィールド、及び／又はその他のソフトウェア基本要素を定義する点から、アプリケーションプログラミングインタフェース（ＡＰＩ）１１４とも称される。ソフトウェアインタフェースによって、回線事業者１０６及び顧客１０７は、クラウドエクスチェンジ１００の機能及び資産へのプログラム可能なアクセスが可能になる。
【００２３】
買い手側では、基になる相互接続プラットフォームによって提示されるソフトウェアインタフェースは、クラウドエクスチェンジ１００の顧客と関連するソフトウェア開発者に、ＣＳＰ１１０のうちのいずれかによって提供されるクラウドサービスへの接続性をクラウドエクスチェンジが確立するようにアプリケーションが要求するのに利用してもよい、相互接続プラットフォームへのアクセスを可能にして利用する、ソフトウェアアプリケーションを作成することを可能にする、拡張可能なフレームワークを提供する。例えば、これら買い手側のソフトウェアインタフェース（又はＡＰＩ１１４の「買い手ＡＰＩ」）によって、ＮＳＰ及び企業顧客用の顧客アプリケーションが、例えば、クラウドエクスチェンジにアクセスする承認を取得し、利用可能なクラウドサービスに関する情報を取得し、顧客にアクティブなポート及び大都市圏の詳細を取得し、クラウドサービスにアクセスするように、異なる帯域幅の仮想回路を作成し（クラウドサービスプロバイダへのオンデマンド及び必要性に基づいた仮想回路を作成する、購入したクラウドサービスに基づく、帯域幅の動的な選択を含む）、仮想回路を削除し、アクティブな仮想回路の情報を取得し、クラウドエクスチェンジプロバイダと提携するＣＳＰを取り巻く詳細を取得し、カスタマイズされた分析データを取得し、相互接続資産への提携相手のアクセスを検証することを可能にしてもよい。
【００２４】
クラウドプロバイダ（売り手）側では、ソフトウェアインタフェースによって、クラウドプロバイダと関連するソフトウェア開発者が、自身のクラウドサービスを管理し、顧客が自身のクラウドサービスに接続できるようにすることを可能にしてもよい。例えば、これら売り手側のソフトウェアインタフェース（又はＡＰＩ１１４の「売り手ＡＰＩ」）によって、クラウドプロバイダアプリケーションが、クラウドエクスチェンジにアクセスする承認を取得し、利用可能なクラウドサービスに関する情報を取得し、プロバイダにアクティブなポート及び大都市圏の詳細を取得し、プロバイダに所与のデータセンターにおけるアクティブなポートの詳細を取得し、顧客によって作成されるクラウドサービスにアクセスする、異なる帯域幅の仮想回路を承認又は拒絶し、保留中の仮想回路の追加を取得して仮想回路の追加を確認し、保留中の仮想回路の削除を取得して仮想回路の削除を確認し、カスタマイズされた分析データを取得し、相互接続資産への提携相手のアクセスを検証することを可能にしてもよい。
【００２５】
本明細書にさらに記載する通り、ＡＰＩ１１４は、マシンツーマシン通信を促進し、顧客とプロバイダネットワークとを相互接続するために、クラウドエクスチェンジにおいて仮想回路を動的にプロビジョニングすることを可能にする。このように、相互接続プラットフォーム１０３によって、クラウドサービスのプロビジョニングの態様を自動化することが可能である。例えば、ソフトウェアインタフェースは、クラウドエクスチェンジに参加する複数の異なるクラウドプロバイダとの相互接続を顧客が確立、削除、及び管理する、自動化されたシームレスな手段を提供してもよい。
【００２６】
いくつかの実施例では、クラウドエクスチェンジ１００は、ＡＰＩ１１４に従って定義されるソフトウェアインタフェースを公開する、一つ以上のアプリケーションを実行する、一つ以上のプロセッサを有するＡＰＩゲートウェイ１１２を含む。アプリケーションは、ＡＰＩ１１４のエンドポイントに相当するサービスを呼び出してもよく、サービスは、オーケストレーションエンジン１１８のクラウドエクスチェンジプラットフォームサービスを自ら呼び出してもよい。ＡＰＩゲートウェイ１１２は、一つ又は複数の仮想マシン及び／又はデータセンター１０１の一つ又は複数の現実のサーバなど、管理デバイス上で実行されてもよい。図１Ａでは単一要素として示しているものの、ＡＰＩゲートウェイ１１２は、一つ以上の物理プロセッサ上で実行される、一つ以上の物理計算機及び／又は仮想計算機の集まりを備えてもよい。
【００２７】
いくつかの実施例では、クラウドエクスチェンジは、クラウドサービス管理だけでなく、ネットワークインフラ１２２内における相互接続の様々な態様をも管理する、基になるソフトウェアサブシステム１２０を構築、運営及び統合する、オーケストレーションエンジン１１８を含む。例えば、オーケストレーションエンジン１１８は、ＡＰＩ１１４と、サブシステム１２０及びネットワークインフラ１２２を含む、クラウドエクスチェンジ１００の基になる相互接続プラットフォームとの間で動作する、ルール駆動のワークフローエンジンを提供してもよい。このように、オーケストレーションエンジン１１８は、クラウドエクスチェンジ１００の相互接続プラットフォーム１０３を用いて直接参加するために、顧客専用のアプリケーション及びＡＰＩ１１４によって使用できる。言い換えると、オーケストレーションエンジン１１８は、ＡＰＩゲートウェイ１１２のサービス要求を処理するように、様々なアプリケーションエンジン又はワークフローを有する「クラウドエクスチェンジプラットフォームサービス」を提供する。
【００２８】
サブシステム１２０及びオーケストレーションエンジン１１８は各々、集中型又は分散型アプリケーションであってもよく、一つ又は複数の仮想マシン及び／又はデータセンター１０１の現実のサーバなど、管理デバイス上で実行されてもよい。
【００２９】
ネットワークインフラ１２２は、クラウドエクスチェンジのスイッチングファブリックを表し、本明細書に記載する技術に従ってＡＰＩ１１４を呼び出すことによって使用する、仮想回路と動的に相互接続されうる複数のポートを含む。ポートの各々は、回線事業者１０６、顧客１０７、及びＣＳＰ１１０のうちの一つと関連する。仮想回路は、レイヤ２のＶＰＮ又は仮想プライベートＬＡＮ（例えば、Ｅ−ＬＩＮＥ、Ｅ−ＬＡＮ、Ｅ−ＴＲＥＥ、又はＥ−Ａｃｃｅｓｓ）などのイーサネット（登録商標）接続、相互に接続された顧客のそれぞれのルータが直接ピアリングし、エクスチェンジ１００経由で交換されるサービストラフィック用のレイヤ３のルートを交換する、インターネットエクスチェンジに基づく相互接続、及び顧客のルータが、その他の顧客と直接ではなく、エクスチェンジ１００（又は「プロバイダ」）のルータとピアリングする、クラウドエクスチェンジを指してもよい。クラウドエクスチェンジの実施例の詳細は、図１８Ａ、１８Ｂ、及び１９に関連して以下に提供する。
【００３０】
レイヤ３又はそれより上位での相互接続では、顧客１０７及び回線事業者１０６は、レイヤ３のピアリングとエクスチェンジ１００への物理的接続とによって直接、又は回線事業者１０６のうちの一つを経由して間接的に、サービスを受け取ってもよい。回線事業者１０６は、エクスチェンジのうちの一つ以上の内部に物理的存在を維持し、一つ又は複数の顧客１０７からのレイヤ３アクセスを集約することによって、「トランジット」を提供する。回線事業者１０６は、レイヤ３で、一つ以上のエクスチェンジと直接ピアリングし、それを行う際に、顧客１０７がエクスチェンジ１００からサービスを取得するのに利用できる、間接的なレイヤ３の接続性及びピアリングを、一つ以上の顧客１０７に提供してもよい。
【００３１】
図１Ｂは、本明細書に記載するいくつかの例示の実装に従う、クラウドベースのサービス交換１００を示すブロック図である。本実施例のアーキテクチャでは、クラウドエクスチェンジ１００は、大都市圏内に地理的に分散するデータセンターを表してもよく、クラウドエクスチェンジ１００が、直接又は（ＮＳＰ１０６を経由して）間接的に、クラウドサービスプロバイダ１１０をクラウドサービスにアクセスするクラウドの顧客１０８と相互接続させてもよい、複数のクラウドエクスチェンジポイント１２８Ａ〜１２８Ｃ（「クラウドエクスチェンジポイント」とも記載し、「クラウドエクスチェンジポイント１２８」と総称する）を含む。
【００３２】
ＣＳＰ１１０、ＮＳＰ１０６、及び顧客１０８によって開発及び配備されるアプリケーション１３０は、相互接続プラットフォーム１０３のＡＰＩ１１４を呼び出し、例えば、（１）相互接続のプロビジョニング、（２）回線事業者の識別及び承認、（３）注文の管理及び遂行、（４）ネットワークサービスのデリバリ、（５）インベントリ及び容量の管理、（６）インシデントの管理及びレポート／警告、並びに（７）コンテンツ管理を含む、一つ以上のクラウドプロバイダ／顧客との相互接続の態様に対して、自動でクラウドエクスチェンジ１００のプロビジョニングを制御し、態様を管理する。
【００３３】
本実施例では、ＡＰＩ１１４は、各々が相互接続プラットフォーム１０３によって公開されるリソースを表す、エンドポイント１１６Ａ〜１１６Ｋ（総称して「エンドポイント１１６」）を含む。エンドポイントの例は、図３Ａに関して以下にさらに詳細に記載する。アプリケーション１３０は、クライアント／サーバモデルに従って、ＡＰＩゲートウェイ１１２と相互作用してもよい。アプリケーション１３０は、ＡＰＩ１１４のエンドポイント１１６のうちのいずれかに向けて要求を送ってもよい。要求に応じて、ＡＰＩゲートウェイ１１２は、要求を満たすように、基になるサブシステム１２０に対してサービスタスクのワークフローを調整してもよい、オーケストレーションエンジン１１８のクラウドエクスチェンジプラットフォームサービスを呼び出す。要求に応じて、例えば、ワークフローが完了すると、ＡＰＩゲートウェイ１１２は、呼び出されたエンドポイント１１６から要求アプリケーション１３０に応答を送信してもよい。
【００３４】
いくつかの実施例では、ＡＰＩ１１４は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒモデルへ準拠してもよい、すなわち、ＲＥＳＴｆｕｌインタフェースの異なる方法を表すエンドポイント１１６を用いたＲＥＳＴｆｕｌインタフェースであってもよい。アプリケーション１３０は、方法、リソースの統一資源識別子（ＵＲＩ）、及び随意で方法のパラメータを指定する、アプリケーションデータを伝達する通信プロトコル（例えば、ＨＴＴＰ）を使用して、エンドポイント１１６のうちのいずれかを呼び出してもよい。ＡＰＩゲートウェイ１１２は、リソースのＵＲＩ及び随意のパラメータを、クラウドエクスチェンジプラットフォームに関係するコンストラクトに変換し、作成、読み出し、更新、削除（ｃｒｅａｔｅ、ｒｅａｄ、ｕｐｄａｔｅ、ｄｅｌｅｔｅ：ＣＲＵＤ）又はアプリケーションデータによって指定されるエンドポイント１１６に対応する確認操作のうちの一つに従って、オーケストレーションエンジン１１８のクラウドエクスチェンジプラットフォームを呼び出す。ＨＴＴＰ用語において、例えば、作成操作はＰＯＳＴメソッド、読み出しはＧＥＴメソッド、及び確認はＰＡＴＣＨメソッドに対応する。
【００３５】
サブシステム１２０は、オーケストレーションエンジン１１８によって調整されるサービスタスクを適用してもよく、例えば、ＣＳＰ１１０と顧客１０８との間に仮想回路のオンデマンド設定を実施するように、又は、そうでなければ、ポート、大都市、データセンター、仮想回路及び仮想回路帯域幅、プロファイル、並びに構成など、相互接続資産のクラウドエクスチェンジポイント１２８を管理するように、クラウドエクスチェンジポイント１２８のいずれかを修正することを含んでもよい。
【００３６】
図１Ｂのクラウドエクスチェンジ１００は、本明細書に記載する技術に従い、複数のクラウドエクスチェンジポイントを提供する、大都市をベースとするクラウドエクスチェンジを示す。クラウドベースのサービス交換１００のクラウドベースのサービス交換ポイント１２８Ａ〜１２８Ｃの各々は、クラウドをベースとするサービスの顧客（「クラウドの顧客」）及びクラウドベースのサービスプロバイダ（「クラウドプロバイダ」）が、クラウドサービスをそれぞれ受け取り提供するために接続する、回復力があり独立したクラウドベースのサービス交換を提供する、地理的に同じ大都市圏（「大都市をベースとする」、例えば、ニューヨーク州ニューヨーク市、カリフォルニア州シリコンバレー、ワシントン州シアトル・タコマ、ミネソタ州ミネアポリス・セントポール、英国ロンドンなど）内に設置される異なるデータセンターを表してもよい。様々な実施例において、クラウドエクスチェンジ１００は、より多くの又はより少ないクラウドエクスチェンジポイント１２８を含んでもよい。いくつかの例では、クラウドエクスチェンジ１００は、一つのみのクラウドエクスチェンジポイント１２８を含む。本明細書に使用する通り、「クラウドエクスチェンジ」又は「クラウドベースのサービス交換」への言及は、クラウドエクスチェンジポイントを指してもよい。クラウドエクスチェンジプロバイダは、複数の異なる大都市圏にクラウドエクスチェンジ１００のインスタンスを配備してもよく、クラウドエクスチェンジ１００の各インスタンスは、一つ以上のクラウドエクスチェンジポイント１２８を有する。
【００３７】
クラウドエクスチェンジポイント１２８の各々は、クラウドの顧客１０８Ａ〜１０８Ｄ（総称して「クラウドの顧客１０８」）が、複数のクラウドサービスプロバイダ１１０Ａ〜１１０Ｎ（総称して「クラウドサービスプロバイダ１１０」）からクラウドサービスを受け取る、ネットワークインフラ及び動作環境を含む。クラウドの顧客１０８は、クラウドエクスチェンジポイント１２８のうちの一つへのレイヤ３ピアリング及び物理的接続を経由して直接、又はネットワークサービスプロバイダ１０６Ａ〜１０６Ｂ（総称して「ＮＳＰ１０６」又は代替として「回線事業者１０６」）のうちの一つを経由して間接的に、クラウドサービスを受け取ってもよい。ＮＳＰ１０６は、クラウドエクスチェンジポイント１２８のうちの一つ以上の内部に物理的存在を維持し、一つ又は複数の顧客１０８からのレイヤ３アクセスを集約することによって、「クラウドトランジット」を提供する。ＮＳＰ１０６は、レイヤ３で、一つ以上のクラウドエクスチェンジポイント１２８と直接ピアリングし、それを行う際に、顧客１０８がクラウドエクスチェンジ１００からクラウドサービスを取得できる、間接的なレイヤ３の接続性及びピアリングを、一つ以上の顧客１０８に提供してもよい。クラウドエクスチェンジポイント１２８の各々は、図１Ｂの実施例において、異なる自律システム番号（ＡＳＮ）を付与されてもよい。例えば、クラウドエクスチェンジポイント１２８ＡがＡＳＮ１を付与され、クラウドエクスチェンジポイント１２８ＢがＡＳＮ２を付与される、などとしてもよい。したがって、各クラウドエクスチェンジポイント１２８は、クラウドサービスプロバイダ１１０から顧客１０８へのパスベクタ型ルーティングプロトコル（例えば、ＢＧＰ）経路における次のホップである。結果として、各クラウドエクスチェンジポイント１２８は、一つ以上の広域ネットワークリンク、並びに同時インターネットアクセス及びトランジットポリシーを有するトランジットネットワークではないにもかかわらず、一つ以上のクラウドサービスプロバイダ１１０から顧客へのサービストラフィックを交換し、集約し、ルーティングするために、外部ＢＧＰ（ｅＢＧＰ）又はその他の外部ゲートウェイルーティングプロトコルによって、複数の異なる自律システムとピアリングしてもよい。言い換えると、クラウドエクスチェンジポイント１２８は、クラウドサービスプロバイダ１１０及び顧客１０８が一対ごとに維持するであろう、ｅＢＧＰピアリング関係を内在化してもよい。代わりに、顧客１０８は、クラウドエクスチェンジポイント１２８と単一のｅＢＧＰピアリング関係を構成し、クラウドエクスチェンジによって、一つ以上のクラウドサービスプロバイダ１１０から複数のクラウドサービスを受け取ってもよい。主にクラウドエクスチェンジポイントと顧客、ＮＳＰ又はクラウドサービスプロバイダネットワークとの間のｅＢＧＰ又はその他のレイヤ３ルーティングプロトコルのピアリングに関して、本明細書に記載するものの、クラウドエクスチェンジポイントは、静的構成によって、又はＲｏｕｔｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＲＩＰ）、Ｏｐｅｎ  Ｓｈｏｒｔｅｓｔ  Ｐａｔｈ  Ｆｉｒｓｔ（ＯＳＰＦ��、Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｓｙｓｔｅｍ‐ｔｏ‐Ｉｎｔｅｒｍｅｄｉａｔｅ（ＩＳ‐ＩＳ）、若しくはその他のルート配信プロトコルによってなど、その他の手段でこれらのネットワークからのルートを学習してもよい。
【００３８】
上記の実施例の通り、顧客１０８Ｄは、クラウドエクスチェンジポイント１２８Ｃ、１２８Ｄによってレイヤ３のクラウドサービスに直接アクセスするように、クラウドエクスチェンジ１００のクラウドエクスチェンジプロバイダと契約していると示される。このように、顧客１０８Ｄは、例えば、クラウドサービスプロバイダ１１０Ａへの冗長なレイヤ３接続性を受け取る。対照的に顧客１０８Ｃは、クラウドエクスチェンジポイント１２８Ｃを経由してレイヤ３のクラウドサービスに直接アクセスし、またＮＳＰ１０６Ｂのトランジットネットワークを経由してレイヤ３のクラウドサービスにアクセスするよう、ＮＳＰ１０６Ｂと契約しているように、クラウドエクスチェンジ１００のクラウドエクスチェンジプロバイダと契約していると示される。顧客１０８Ｂは、ＮＳＰ１０６Ａ、１０６Ｂのそれぞれのトランジットネットワークを経由して、クラウドエクスチェンジポイント１２８Ａ、１２８Ｂへの冗長なクラウドアクセスを有するように、複数のＮＳＰ１０６Ａ、１０６Ｂと契約していると示される。上に記載する契約は、クラウドエクスチェンジポイント１２８のネットワークインフラにおいて、ＮＳＰ１０６及びクラウドエクスチェンジポイント１２８のスイッチングデバイス内のＬ３ピアリング構成によって、並びに例えばレイヤ３の仮想回路といった、クラウドサービスプロバイダ１１０のネットワークをＮＳＰ１０６のネットワーク及び顧客１０８のネットワークに相互接続するように、クラウドエクスチェンジポイント１２８内に確立されるＬ３接続によって、インスタンスを作成され、全ては、クラウドエクスチェンジポイント１２８のうちの一つ以上の内部に接続性を提供する少なくとも一つのポートを有する。
【００３９】
レイヤ３のクラウドサービスに対して、仮想回路は、顧客ネットワークをクラウドエクスチェンジポイントに接続する連結回路と、クラウドサービスプロバイダネットワークをクラウドエクスチェンジポイントに接続する連結回路との間の、クラウドエクスチェンジポイント１２８のうちの一つ以上のＩＰ／ＭＰＬＳファブリックによるレイヤ３経路を表してもよい。各仮想回路は、クラウドエクスチェンジポイントのプロバイダエッジ／自律システムの境界にエンドポイントを有する、少なくとも一つのトンネル（例えば、ＬＳＰ及び／又はＧｅｎｅｒｉｃ  Ｒｏｕｔｅ  Ｅｎｃａｐｓｕｌａｔｉｏｎ（ＧＲＥ）トンネル）を含んでもよい。
【００４０】
クラウドエクスチェンジポイント１２８は、顧客／ＮＳＰネットワーク及びクラウドサービスプロバイダネットワークをエンドツーエンドのＩＰ経路で相互接続するように、複数のレイヤ３の仮想回路を実装するように構成されてもよい。クラウドサービスプロバイダ及び顧客／ＮＳＰの各々は、複数の仮想回路に対するエンドポイントであってもよく、複数の仮想回路は、エンドポイントを接続するように、一つ以上のクラウドエクスチェンジポイント１２８を横断する。クラウドエクスチェンジポイントの例示的実装については、図１８Ａ〜１８Ｂ及び図１９に関して以下にさらに詳細に記載する。
【００４１】
図１Ｃは、クラウドベースのサービス交換の別の例示の実装を示す。本実施例では、クラウドエクスチェンジ１００は、高速連結回路２０８、２１３、２１８及び２２３、並びに相互接続プラットフォームと総称される仮想回路１５０、１５５、１６０、１６５、１７０を直接プロビジョニングするルーティング及びスイッチングインフラを、交差接続する回線事業者ネットワーク２０５、２１０、２１５及び２２０に提供する。
【００４２】
図１Ｂの実施例に示す通り、クラウドエクスチェンジ１００は、本明細書でアプリケーションプログラミングインタフェース（ＡＰＩ）とも称し、顧客システム１９６に、クラウドエクスチェンジ１００の相互接続プラットフォーム１０３の機能及び資産へのプログラムによるアクセスを可能にする、ソフトウェアインタフェース１１４の一群を公開する。すなわち、ソフトウェアインタフェース１１４は、クラウドエクスチェンジ１００の顧客と関連するソフトウェア開発者が、エクスチェンジ１００のアクセスサブシステム１２０を許可及び利用する顧客システム１９６上で、実行可能なソフトウェアアプリケーションを作成することを可能にする、拡張可能なフレームワークを提供する。エクスチェンジ１００の基になるサブシステム１２０は、例えば、（１）顧客システム１９６間の相互接続のプロビジョニング、（２）回線事業者の識別及び承認、（３）注文の管理及び遂行、（４）ネットワークサービスのデリバリ、（５）インベントリ及び容量の管理、（６）インシデントの管理及びレポート／警告、並びに（７）コンテンツ管理を含む、エクスチェンジ１００の全態様のプロビジョニング及び管理を制御してもよい。
【００４３】
そのため、回線事業者１０６、並びにネットワークサービスプロバイダ、クラウドサービスプロバイダ、マネージドサービスプロバイダ、及びその他の企業など、クラウドエクスチェンジ１００のその他の顧客は、その他の回線事業者との直接的な交差接続を管理するように、相互接続プラットフォームによって公開されるソフトウェアインタフェースを利用してもよい。すなわち、ソフトウェアインタフェース１１４によって、図１Ｃに点線の矢印として示す、ネットワークインフラと、直接的な交差接続を確立及び管理する回線事業者１０６用の異なる回線事業者ネットワーク２０５、２１０、２１５、及び２２０内に位置するプロビジョニング／支払請求／会計／ＡＡＡシステムとの間のマシンツーマシン通信が可能になる。そうして、ソフトウェアインタフェース１１４によって、例えば、図１Ｃの仮想回路のような、相互接続をほぼリアルタイムで設定及び修正することが可能になり、また、相互接続の設定及び管理プロセス全体で人との相互作用の必要性が排除又は減少されてもよい。このように、ソフトウェアインタフェースは、相互接続プラットフォーム１０３に参加する複数の異なる顧客との相互接続を確立、削除、及び管理するように、自動化されたシームレスな手段を回線事業者１０６に提供する。
【００４４】
その上、さらに図１Ｂの実施例に示す通り、クラウドエクスチェンジ１００は、基になるソフトウェアを構築、運営、及び統合する内部オーケストレーションエンジン１１８と、クラウドエクスチェンジ１００によって提供される相互接続サービスの様々な態様を管理する、ネットワークサブシステム１２０とを含む。例えば、オーケストレーションエンジン１１８は、ＡＰＩ１１４と、クラウドエクスチェンジ１００のサブシステム１２０によって提供される、基になる相互接続プラットフォームとの間で動作する、ルール駆動のワークフローエンジンを提供してもよい。このように、オーケストレーションエンジン１１８は、クラウドエクスチェンジの相互接続プラットフォーム内に直接参加するために、ＡＰＩ１９０を経由して顧客システム１９６上で実行される顧客専用のアプリケーションによって呼び出すことができる。
【００４５】
本明細書に記載する通り、オーケストレーションエンジン１１８は、顧客アプリケーションに対する、インテリジェントな次のステップ及び応答を組み立てるように、相互接続プラットフォームの基になるサブシステム１２０からの情報及び操作を合成する。そうして、オーケストレーションエンジン１１８は、相互接続プラットフォームにアクセスする均一で簡易化された安全な手段を提供することによって、クラウドエクスチェンジ１００の基になるソフトウェア及びネットワークサブシステム１２０の複雑さを取り除く。
【００４６】
図１Ｄは、本開示の技術に従い、相互接続プラットフォームが管理するクラウドエクスチェンジ１００の複数のクラウドエクスチェンジポイントによって、地理的に分散する回線事業者間での交差接続を利用可能とする実施例を示すブロック図である。図示しないものの、クラウドエクスチェンジポイントの各々は、図１Ｂのクラウドエクスチェンジポイント１２８を含む図１Ａ〜１Ｃのクラウドエクスチェンジ１００に関して記載する例示の技術を実装してもよい。
【００４７】
図２は、本明細書に記載する技術に従う、クラウドエクスチェンジの例示アーキテクチャの詳細を示すブロック図である。本実施例に示す通り、例示のクラウドエクスチェンジ１００は、ＡＰＩ１１４、内部オーケストレーションエンジン１１８、及びサブシステム１２０をさらに詳細に示す。
【００４８】
開発者コミュニティー３００は、クラウドエクスチェンジ１００の相互接続プラットフォームにアクセスするために、ＡＰＩ１１４を使用するアプリケーションを開発できるエンティティを示す。これらのエンティティは、ネットワークサービスプロバイダ３００Ａ、マネージドサービスプロバイダ３００Ｂ、企業３００Ｃ、クラウドサービスプロバイダ３００Ｄ、第三者開発者３００Ｅ、及びその他３００Ｆを含む。これらのエンティティにより開発されるアプリケーションは、様々なエンティティの方針及びプロファイルに従って、クラウドサービスプロバイダにより提供されるクラウドサービスに顧客を相互接続させる相互接続プラットフォームとして、クラウドエクスチェンジ１００を利用する。
【００４９】
本実施例では、ＡＰＩ１１４は、機能により様々なＡＰＩの方法又はエンドポイントのかたまりを含む。検出ＡＰＩ３０４Ａは、場所の検出、資産の検出、及びクラウドサービスの検出を利用可能にするように使用できてもよい。検出可能な情報には、利用可能な大都市圏、データセンター、ポート、サービス、仮想回路、及び顧客がクラウドサービスを取得又は管理できるその他の相互接続資産を含んでもよい。処理ＡＰＩ３０４Ｂは、例えば、マシンツーマシンの相互作用を通して異なる帯域幅のエンドツーエンド仮想回路を動的にプロビジョニングし、顧客によって要求される仮想回路を検証し、仮想回路の削除を確認するのに使用可能であってもよい。使用ＡＰＩ３０４Ｃは、プロバイダ及び顧客が、例えば、クラウドエクスチェンジ１００の推奨エンジンによって実施されるような推奨情報を取得し、競合他社の存在、クラウドサービスの存在／可用性、及び顧客の存在／獲得可能性に関するカスタマイズされた分析を取得し、稼働率の統計を取得し、コンテンツを管理することが可能となるように使用可能であってもよい。支援ＡＰＩ３０４Ｄは、例えば、アカウントを管理し、支払請求／請求書の送付の自動化を実施し、クレジットを検証し、エンティティに対するプロファイル及び構成情報を構成するように、顧客又はプロバイダによって使用可能であってもよい。
【００５０】
本実施例では、オーケストレーションエンジン１１８（「相互接続オーケストレーションエンジン１１８」として示す）は、相互接続の様々な態様を管理する、基になるソフトウェア及びネットワークサブシステム１２０を構築、運営、及び統合する。例えば、オーケストレーションエンジン１１８は、顧客アカウント及びプロフィール管理システム、顧客資産管理システム、インベントリ管理システム、容量管理システム、ネットワークシステム、クレジット管理システム、コンテンツ管理システム、並びにトラブルチケット管理システム（図２に全ては図示せず）など、相互接続を実施可能にする無数のサブシステム１２０と通信することによって、相互接続資産のプロビジョニングのために、見積から入金までのサイクル全体を処理してもよい。そのために、オーケストレーションエンジン１１８は、ＡＰＩ１１４を介して受信した要求に対して、インテリジェントな次のステップ及び応答を組み立てるよう、サブシステム１２０からの情報及び操作を合成するように、構成した交換ポリシー３０８Ａ、プロファイル３０８Ｂ、及び構成３０８Ｃに従ってレスポンシブに動作する、ワークフロー及びルールエンジン３０６を含む。マイクロサービス構成要素３０８Ｄは、水平スケーラビリティ、性能効率、並びに短時間からゼロのダウンタイムでの機能アップグレード・強化を向上させるように、相互接続サービスのうちの多く、及びいくつかの場合には全てを構成要素に分ける。このように、オーケストレーションエンジン１１８が、相互接続資産にアクセス及び管理するため、相互接続プラットフォームにアクセスする、均一で簡易化された安全な手段を提供することによって、基になるソフトウェア及びサブシステム１２０の複雑さを取り除いてもよい。
【００５１】
図２の実施例においてオーケストレーションエンジン１１８によって調整されるサブシステム１２０は、識別（ＩＤ）及びアクセス管理システム３１０Aを含む。いくつかの実施例では、ＩＤ及びアクセス管理システム３１０Ａは、顧客、資産、及びパーミッションの階層を収容するパーミッションデータ記憶部（ＰＤＳ）を含む。ＩＤ及びアクセス管理システム３１０Ａは、Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＳＡＭＬ）アサーションを生成する第三者システムを使用して、連携を達成することも可能で、またＳｉｎｇｌｅ  Ｓｉｇｎ−Ｏｎ（ＳＳＯ）機能も提供できる。
【００５２】
オーケストレーションエンジン１１８は、（例えば、アジア太平洋、欧州、中東及びアフリカ、並びに北米など異なる地域向けの）複数の注文管理システム３１０Ｂを調整してもよい。オーケストレーションエンジン１１８は、提携企業に請求書を送付できるように、関連する仮想回路の注文作成情報をこれらの注文管理システム３１０Ｂに渡す。オーケストレーションエンジン１１８は、基になるネットワークシステムと相互作用するように、ネットワークサービスシステム３１０Ｃとシームレスに統合することによって、基になるネットワークシステムの複雑さを取り除いてもよい。オーケストレーションエンジン１１８は、顧客ポートのインベントリについて情報を取得するように、パーミッションデータ記憶部と連動する資産インベントリ及び容量管理システム３１０Ｄを利用してもよい。オーケストレーションエンジン１１８は、この情報を利用して、適切なポートに対して仮想回路要求を出してもよい。資産インベントリ及び容量管理システム３１０Ｄは、仮想回路をプロビジョニングする前に、各ポートの利用可能な帯域幅を評価するのに使用してもよい。
【００５３】
オーケストレーションエンジン１１８は、提携企業及び顧客からのインシデント要求を受け入れ、基になるインシデント管理システム３１０Ｅと通信して、サービスチケットを提出する。オーケストレーションエンジン１１８は、コンテンツ管理システム３１０Ｆと通信し、例えば、顧客の言語選択に基づいて、顧客のために国際化及びローカライズされたコンテンツを表示する。コンテンツ管理システム３１０Fは、ウェブポータル、モバイルデバイス上で、又はＡＰＩ１１４を介するマシンツーマシン通信で表示されるラベル、エラーメッセージ、成功メッセージ、及び応答の全てを透過的に翻訳するのに役立つ。
【００５４】
図３Ａ及び３Ｂは、本明細書に記載する技術に従う、相互接続ソフトウェアインタフェースのフロー図を示す。本実施例では、ＡＰＩゲートウェイ４０３は、ＡＰＩコンシューマ４０２が、クラウドエクスチェンジの相互接続を管理するのに利用してもよい、複数のエンドポイント４０６Ａ〜４０６Ｌ（総称して「エンドポイント４０６」）を有する、ＡＰＩ１１４を公開する。そして、ＡＰＩゲートウェイ４０３は、クラウドエクスチェンジのＡＰＩサービス４０９によって、図３Ａ〜３Ｂに表すサービスタスクのワークフローを調整する、オーケストレーションエンジン４０７のクラウドサービスプラットフォームを呼び出す。ＡＰＩゲートウェイ４０３は、図１Ａ〜１ＤのＡＰＩゲートウェイ１１２の例示的インスタンスを表してもよく、オーケストレーションエンジン４０７は、図１Ａ〜１Ｄのオーケストレーションゲートウェイ１１８の例示的インスタンスを表してもよく、図１〜２のサブシステム１２０は、クラウドエクスチェンジのＡＰＩサービス４０９を提供してもよい。
【００５５】
ＡＰＩコンシューマ４０２は、買い手アプリケーション４０２Ａ及び売り手アプリケーション４０２Ｂだけでなく、当該アプリケーションを開発してもよいＡＰＩ開発者４０２Ｃも含んでもよい。ＡＰＩゲートウェイ４０３は、ＡＰＩゲートウェイ４０３の動作を促進する、いくつかのカスタムアダプタ４０４を含む。カスタムアダプタ４０４は、セキュリティ４０４A、ＡＰＩキーの検証４０４Ｂ、変換４０４Ｃ、キャッシング４０４Ｄ、脅威からの保護４０４Ｅ、スパイクの抑制４０４Ｆ、カスタム分析４０４Ｇ、及びＨＴＴＰコールアウト４０４Ｈを含む。
【００５６】
エンドポイント４０６は、ＡＰＩコンシューマ４０２がアクセスできる、利用可能な論理及び／又は物理リソースを表す。すなわち、ＡＰＩコンシューマ４０６は、クラウドエクスチェンジの対応するリソースの要求に関する情報を得て、クラウドエクスチェンジの対応するリソースの要求を作成、修正、削除、及び／又確認するため、クラウドエクスチェンジの相互接続プラットフォームにアクセスするように、エンドポイント４０６にアクセスしてもよい。エンドポイント４０６は、図１Ｂ〜１Ｃのエンドポイント１１６の例示的インスタンスを表してもよい。
【００５７】
本実施例では、エンドポイント４０６は、ログイン４０６Ａ、ポート４０６Ｂ、大都市４０６Ｃ、資産４０６Ｄ、仮想回路４０６Ｅ、クラウドサービス４０６Ｆ、サービスプロファイル４０６Ｇ、分析４０６Ｈ、トラフィック統計４０６Ｉ、帯域幅４０６Ｊ、サービスチケット４０６Ｋ、及び推奨事項４０６Ｌを含む。概して、ＡＰＩコンシューマ４０６は、対応する方法を使用してエンドポイント４０６、及びいくつかの場合、相互接続プラットフォームがどのように方法を実行するかを判定するパラメータのうちのいずれかを呼び出してもよい。
【００５８】
エンドポイント４０６は、ＲＥＳＴｆｕｌインタフェースの異なる方法を表してもよい。ＡＰＩコンシューマ４０２は、方法、リソースのＵＲＩ、及び随意で方法のパラメータを指定する、アプリケーションデータを伝達する通信プロトコル（例えば、ＨＴＴＰ）を使用して、エンドポイント１１６のうちのいずれかを呼び出してもよい。ＡＰＩゲートウェイ４０３は、エンドポイント４０６のリソースのＵＲＩ及び随意のパラメータを、クラウドエクスチェンジプラットフォームに関係するコンストラクトに変換し、アプリケーションデータによって指定されるエンドポイント４０６に対応する操作の作成、読み出し、更新、削除、又は確認のうちの一つに従って、オーケストレーションエンジン４０７のクラウドエクスチェンジプラットフォームを呼び出す。
ＡＰＩ―実施例
【００５９】
以下のセクションは、クラウドエクスチェンジ１００用のＡＰＩ１１４の選択されたエンドポイント４０６に関する詳細な実施例を包含する。ＡＰＩ１１４は、開発者が、仮想回路を注文し、見るために相互接続プラットフォームにアクセスすることを可能にする機能性を提供する。このＡＰＩの機能性は、ログイン４０６Ａ、ポート４０６Ｂ、仮想回路４０６Ｅ、大都市４０６Ｃ、及びクラウドサービス４０６Ｆに関する情報を得ること、並びにそれらの動作を行うことを含む。
【００６０】
一実施例では、ＡＰＩ１１４のエンドポイント４０６は、次の三つの主要カテゴリに分類されてもよい。
・基本的ＡＰＩ―これらのＡＰＩは、買い手及び売り手の両方に共通する。
・買い手ＡＰＩ―これらは、異なるクラウドサービスプロバイダ（ＣＳＰ）によって提供されるクラウドサービスへの接続性を確立するように、企業、ネットワークサービスプロバイダ（ＮＳＰ）、及びマネージドサービスプロバイダ（ＭＳＰ）によって使用されるＡＰＩである。
・売り手ＡＰＩ―これらは、クラウドエクスチェンジ１００で売り手のクラウドサービスを管理し、買い手が売り手のサービスに接続することが可能になるように、ＣＳＰによって使用される。
【００６１】
ＡＰＩは、異なるリソース上で実施できる動作に広く分類される。本セクションも、全ての要求の一部として含まれることが要求される共通の要求ヘッダ、及びまた各ＡＰＩ応答と共に返送して戻される応答ヘッダについて詳述する。加えて、本セクションでは、いずれのエラー状況の場合には、ＡＰＩ応答の一部として使用される、ＨＴＴＰ状態及びカスタムエラーコードについて記載する。
【００６２】
以下の表は、ＡＰＩリソース、ＡＰＩリソースそれぞれのＵＲＩ、各リソース上のサポートされる動作の概要を示す。ＡＰＩは、買い手、売り手、及び基本的ＡＰＩの三つの主要セクションに分かれる。本明細書におけるＸＭＬへの参照は、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅを指し、ＪＳＯＮは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎを指す。
【００６３】
基本的ＡＰＩの概要
【表１】
0006495948.tif 000002
【００６４】
買い手ＡＰＩの概要
【表２】
0006495948.tif 000003
【００６５】
売り手ＡＰＩの概要
【表３】
0006495948.tif 000004
ＨＴＴＰ状態コード
【００６６】
以下の表は、ＡＰＩ１１４が利用できる例示的なＨＴＴＰ状態コードの一覧である。適切なＡＰＩの仕様に沿って定義されたエラーのシナリオにおいて返送される、特定のエラーコード及びメッセージがある。
【表４】
0006495948.tif 000005
【００６７】
共通の要求ヘッダ
【００６８】
以下のヘッダは、全ＡＰＩに対する要求で必要とされる。
【表５】
0006495948.tif 000006
【００６９】
共通の応答ヘッダ
【００７０】
以下のヘッダが、全ＡＰＩ応答の一部として含まれる。
【表６】
0006495948.tif 000007
【００７１】
エラー応答の構文
【００７２】
全ＡＰＩからのエラー応答は、以下に示す共通構文に従う。
｛
"errors": [
｛
"status": "string",
"code": "string",
"property": "string",
"message": "string",
"more_info": "string"
｝  ] ｝
【００７３】
エラー応答のメッセージフィールド
errors
【表７】
0006495948.tif 000008
status
【表８】
0006495948.tif 000009
code
【表９】
0006495948.tif 000010
property
【表１０】
0006495948.tif 000011
message
【表１１】
0006495948.tif 000012
more_info
【表１２】
0006495948.tif 000013
エラー応答のサンプル：
Content-Type: application/json
｛
"errors": [
｛
"code": 40007,
"message": "Invalid Field Value",
"more_info": "The field value port_name already exists for the
specified profile name",
"property": "port_name",
"status": 400
｝
]
｝
いくつかの実施例では、ＡＰＩを呼び出す前に、開発者が開発者プラットフォームを使用して、ＡＰＩコンシューマキー及びコンシューマシークレットを生成すると期待してもよい。
【００７４】
認証
【００７５】
開発者は、いかなるＡＰＩ１１４を呼び出す前にも、有効なログインによってアクセストークンを獲得する。詳細はログイン４０６Ａについて記載するセクションを参照のこと。
【００７６】
基本的ＡＰＩ
【００７７】
リソース：アクセストークン又はログイン４０６Ａ
【００７８】
説明：ＡＰＩ１１４にアクセスするためのＯＡｕｔｈ２．０トークン
【表１３】
0006495948.tif 000014
【００７９】
ＰＯＳＴ  アクセストークン
【００８０】
説明：このＡＰＩは、ＡＰＩ開発者の認証及び承認を処理する。認証に成功すると、ａｃｃｅｓｓ＿ｔｏｋｅｎが応答の一部として返送される。失敗のときにはエラーメッセージが返送される。
要求
要求ＵＲＩ：POST http://<HostName>/ecx/v1/oauth/token
フィルタパラメータ：
なし
要求ヘッダ：
なし
要求フィールド：
grant_type
【表１４】
0006495948.tif 000015
user_name
【表１５】
0006495948.tif 000016
user_password
【表１６】
0006495948.tif 000017
client_id
【表１７】
0006495948.tif 000018
password_encoding
【表１８】
0006495948.tif 000019
【００８１】
要求のサンプル
POST http://<HostName>/ecx/v2/oauth/token
プレーンテキストとしてのパスワード：
｛
"grant_type":"client_credentials",
"user_name": "tempuser1",
"user_password": "xxxxxxx",
"client_id": "QWERTY1234567abcdefg",
"client_secret": "tstCLNT123scrt"
｝
【００８２】
ｍｄ５、それからｂ６４で符号化されたパスワード：
｛
"grant_type":"password",
"user_name": "tempuser1",
"user_password": "xxxxxxxxxxxx",
"client_id": "QWERTY1234567abcdefg",
"client_secret": "tstCLNT123scrt",
"password_encoding": "md5-b64"
｝
【００８３】
応答：
応答フィールド：
access_token
【表１９】
0006495948.tif 000020
token_timeout
【表２０】
0006495948.tif 000021
user_name
【表２１】
0006495948.tif 000022
token_type
【表２２】
0006495948.tif 000023
refresh_token
【表２３】
0006495948.tif 000024
refresh_token_timeout
【表２４】
0006495948.tif 000025
【００８４】
応答のサンプル：
HTTP/1.1 200 OK
API-Version: v1
Content-Type: application/json
Accept: application/json
｛
"access_token": "HihiOtaY2JAT0QaTFaYYyzHOqqmb",
"token_timeout": "3599",
"user_name": "tempuser1",
"token_type": "Bearer",
"refresh_token": "QvJdZg7nMSTNYBfeDLgECpe5b9FvgWgdpZRwv4u0nZ",
"refresh_token_timeout": "86376"
｝
【００８５】
応答のエラーコード：
【表２５】
0006495948.tif 000026
【００８６】
ＰＯＳＴ更新トークン：説明：このＡＰＩによって、開発者は、更新しなくても６０分後には期限切れとなる、発行済みの既存のＯＡｕｔｈトークンを更新することが可能になる。認証に成功し、応答の一部として返送される、新しいａｃｃｅｓｓ＿ｔｏｋｅｎを引き出すために、有効な更新トークンが必要とされる。
要求
要求ＵＲＩ：POST http://<HostName>/oauth2/v1/refreshaccesstoken
フィルタパラメータ：
なし
要求ヘッダ：
なし
要求フィールド：
grant_type
【表２６】
0006495948.tif 000027
client_id
【表２７】
0006495948.tif 000028
refresh_token
【表２８】
0006495948.tif 000029
【００８７】
要求のサンプル
POST http://<HostName>/oauth2/v1/refreshaccesstoken
更新トークン
｛
"grant_type":"refresh_token", 
"client_id": "QWERTY1234567abcdefg", 
"client_secret": "tstCLNT123scrt", 
"refresh_token": "5f752714hsdf07a3e41c2a3311f514e1"
｝
【００８８】
応答：
応答フィールド：
access_token
【表２９】
0006495948.tif 000030
token_timeout
【表３０】
0006495948.tif 000031
user_name
【表３１】
0006495948.tif 000032
token_type
【表３２】
0006495948.tif 000033
refresh_token
【表３３】
0006495948.tif 000034
refresh_token_timeout
【表３４】
0006495948.tif 000035
【００８９】
リソース：大都市
説明：クラウドエクスチェンジサービスが提供される大都市
【表３５】
0006495948.tif 000036
【００９０】
ＧＥＴ  大都市：
説明：このGET動作の実装により、ユーザがポートを有するか、又はクラウドエクスチェンジが使用可能であるかのいずれかである、全大都市のリストが返送される。
【００９１】
要求
要求ＵＲＩ：GET http://<HostName>/ecx/v1/metros
フィルタパラメータ：
cloud_exchange_enabled
【表３６】
0006495948.tif 000037
【００９２】
要求ヘッダ：
【表３７】
0006495948.tif 000038
【００９３】
要求のサンプル
GET http://<HostName>/ecx/v1/metros?cloud_exchange_enable=true
【００９４】
応答：
応答フィールド：
metros
【表３８】
0006495948.tif 000039
name
【表３９】
0006495948.tif 000040
code
【表４０】
0006495948.tif 000041
【００９５】
応答のサンプル：
Content-Type: application/json
｛
“metros”: [
｛
“code”: “SV”,
“name”: “Silicon Valley”, 
｝,
｛
“code”: “SG”,
“name”: “Singapore”
｝   ] ｝ 
【００９６】
応答のエラーコード：
【表４１】
0006495948.tif 000042
【００９７】
リソース：クラウドサービス
説明：クラウドエクスチェンジ１００におけるクラウドサービス
【表４２】
0006495948.tif 000043
【００９８】
ＧＥＴ  クラウドサービス
【００９９】
説明：このＧＥＴ動作の実装により、クラウドサービスエクスチェンジ１００における全クラウドサービスのリストが返送される。
【０１００】
要求
要求ＵＲＩ：GET http://<HostName>/ecx/v1/cloudservices, 
GET http://<HostName>/ecx/v1/cloudservices/｛cloud_service_name ｝
【０１０１】
フィルタパラメータ：
なし
【０１０２】
要求ヘッダ：
【表４３】
0006495948.tif 000044
【０１０３】
要求のサンプル
GET http://<HostName>/ecx/v1/cloudservices
【０１０４】
応答：
応答フィールド：
cloud_services
【表４４】
0006495948.tif 000045
name
【表４５】
0006495948.tif 000046
metros
【表４６】
0006495948.tif 000047
name
【表４７】
0006495948.tif 000048
code
【表４８】
0006495948.tif 000049
ibxs
【表４９】
0006495948.tif 000050
【０１０５】
応答のサンプル：
HTTP/1.1 200 OK
Content-Type: application/json
｛
“cloud_services”: [
｛
“name”: “CSP1”,
“metros”: [
｛
“code”: “SG”,
“name”: “Singapore”,
“ibxs”: [
“SV1”,
“SV2”
]        ｝       ]     ｝   ] ｝
【０１０６】
応答のエラーコード：
【表５０】
0006495948.tif 000051
【０１０７】
買い手ＡＰＩ
【０１０８】
本セクションでは、買い手に関連するＡＰＩについて記載する。
【０１０９】
リソース：ポート
説明：クラウドエクスチェンジのスイッチファブリック上のポート
【表５１】
0006495948.tif 000052
【０１１０】
ＧＥＴ  ポート：
【０１１１】
説明：このＧＥＴ動作の実装により、認証された要求の送信元が所有する全ポートのリストが返送される。ポートは、大都市及びＩＢＸ名によってフィルタリングできる。条件に合致するポートが見つからない場合、２０４ＨＴＴＰコード応答が、ペイロードなしで返送される。
【０１１２】
要求
要求ＵＲＩ：
GET http://<HostName>/ecx/v1/ports?metro_code=SV&ibx_name=SV1
【０１１３】
フィルタパラメータ：
metro_code
【表５２】
0006495948.tif 000053
ibx_name
【表５３】
0006495948.tif 000054
bandwidth
【表５４】
0006495948.tif 000055
encapsulation
【表５５】
0006495948.tif 000056
is_buyout
【表５６】
0006495948.tif 000057
【０１１４】
要求ヘッダ：
【表５７】
0006495948.tif 000058
【０１１５】
要求のサンプル
GET http://<HostName>/ecx/v1/ports?metro_code=SV&ibx=SV1
GET http://<HostName>/ecx/v1/ports?bandwidth=100 
GET http://<HostName>/ecx/v1/ports?encapsulation=Dot1Q 
GET http://<HostName>/ecx/v1/ports?is_buyout=Y
【０１１６】
応答
応答フィールド：
ports
【表５８】
0006495948.tif 000059
name
【表５９】
0006495948.tif 000060
metro_code
【表６０】
0006495948.tif 000061
metro_name
【表６１】
0006495948.tif 000062
ibx_name
【表６２】
0006495948.tif 000063
【０１１７】
bandwidths
【表６３】
0006495948.tif 000064
【０１１８】
encapsulation
【表６４】
0006495948.tif 000065
【０１１９】
is_buyout
【表６５】
0006495948.tif 000066
【０１２０】
cross_connect_ids
【表６６】
0006495948.tif 000067
【０１２１】
応答のサンプル１：
HTTP/1.1 200 OK
Content-Type: application/json
｛     
“ports”: [
｛
“name”: “GSE_QA-R-EE-02”,
“metro_code” : “SV”,
“metro_name” : “Silicon Valley”,
“ibx_name” : “SV1”
｝,
｛
“name”: “GSE_QA-R-EE-01”,
“metro_code”: “SG”,
“metro_name”: “Singapore”,
“ibx_name” : “SG1”
｝   ] ｝
【０１２２】
応答のサンプル２：  
HTTP/1.1 200 OK 
Content-Type: application/json 
｛ "ports":[ 
｛"bandwidth":"10 G", 
"bandwidths":[ 
"10 G", "10 G" ], 
"cross_connect_ids":[ 
"123456" 
"100000", ],
"encapsulation":"Qinq", 
"ibx_name":"SV3", 
"is_buyout":"N", 
"metro_code":"SV", 
"metro_name":"BAYM", 
"name":"QinqVirtualPort" 
｝
【０１２３】
応答のエラーコード：
【表６７】
0006495948.tif 000068
【０１２４】
リソース：売り手のサービス
説明：クラウドエクスチェンジにおける売り手のサービス
ＨＴＴＰメソッド                        要求ＵＲＩ
ＧＥＴ                              /ecx/v1/sellerservices
/ecx/v1/sellerservices/｛seller_service_name｝
【０１２５】
ＧＥＴ  売り手のサービス
説明：このＧＥＴ動作の実装により、クラウドエクスチェンジにおける全売り手のサービスのリストが返送される。
要求
要求ＵＲＩ：GET  http://<HostName>/ecx/v1/sellerservices,
GET  http://<HostName>/ecx/v1/sellerservices/｛seller_service_name｝
【０１２６】
フィルタパラメータ：大都市での結果のフィルタリング。このパラメータが含まれていない場合には、応答は、クラウドエクスチェンジにおける全売り手サービスを包含する。
【０１２７】
要求のサンプル
GET  http://<HostName>/ecx/v1/sellerservices/｛seller_service_name｝
http://<HostName>/ecx/v1/sellerservices?metro_code=SV
【０１２８】
応答：
応答フィールド：
seller_services
【表６８】
0006495948.tif 000069
allow_custom_speed
【表６９】
0006495948.tif 000070
【０１２９】
availability_status：「トライアルテスト中」又は注文が利用可能である、サービスプロファイルの可用性状態
encapsulation
【表７０】
0006495948.tif 000071
【０１３０】
require_redudancy
【表７１】
0006495948.tif 000072
【０１３１】
standard_speeds：カスタマイズされた速度が売り手によって認められていない場合の、サービスプロファイルと関連する、可能な標準速度。
seller service name
metros：売り手がサービスを提供している大都市のリスト。大都市の名前。大都市コード。大都市におけるＩＢＸ名のリスト。
【０１３２】
応答のサンプル：
HTTP/1.1 200 OK
Content-Type: application/json
｛
"seller_services": [
｛
"allow_custom_speed": 
"N", "encapsulation": 
"Dot1q", "metros": [
｛
"code": "DC", 
"ibxs": [
"DC5",
"DC6"
],
"name": "Ashburn"
｝,
｛
"code": "SV", 
"ibxs": [
"SV1"
],
"name": "SiliconValley"
｝
],
"name": "test1",
"availability_status": "in_trial_testing",
"require_redundancy": "N",
"standard_s
peeds": 
[ "Upto10G", 
"Upto200MB", 
"Upto500MB", 
"Upto1G"
]
｝
]
｝
【０１３３】
リソース：ユーザ資産
説明：所与の大都市所在地において、買い手が所有する資産の詳細を取得する。
ＨＴＴＰメソッド                          要求ＵＲＩ
ＧＥＴ                                          /ecx/v1/assets
【０１３４】
ＧＥＴ  資産
説明：この買い手に対するＧＥＴ動作の実装により、所与の大都市におけるポート及び仮想回路を含む、買い手の全資産のリストが返送される。
【０１３５】
要求
要求ＵＲＩ：GET  http://<HostName>/ecx/v1/assets
フィルタパラメータ：
metro_code
【表７２】
0006495948.tif 000073
asset_type
【表７３】
0006495948.tif 000074
【０１３６】
要求ヘッダ：
ヘッダ属性                  説明
承認                        必須ＯＡｕｔｈベアラトークンを指定する
【０１３７】
要求
GET  http://<HostName>/ecx/v1/assets?metro_code=SV&asset_type=buyer
応答：
応答フィールド：
buyer_assets
【表７４】
0006495948.tif 000075
seller_assets
【表７５】
0006495948.tif 000076
ports
【表７６】
0006495948.tif 000077
name
【表７７】
0006495948.tif 000078
cross_connect_ids
【表７８】
0006495948.tif 000079
metro_code
【表７９】
0006495948.tif 000080
metro_name
【表８０】
0006495948.tif 000081
ibx_name
【表８１】
0006495948.tif 000082
bandwidths
【表８２】
0006495948.tif 000083
encapsulation
【表８３】
0006495948.tif 000084
is_buyout
【表８４】
0006495948.tif 000085
virtual_circuits
【表８５】
0006495948.tif 000086
id  仮想回路のＩＤ。このＩＤは、ＤＥＬＥＴＥ又はＧＥＴ  仮想回路のように、仮想回路ＡＰＩ上で動作することが必要とされる。
redundant_id
【表８６】
0006495948.tif 000087
cross_connect_id［非推奨。代わりにフィールド「Ports」「cross_connect_ids」を参照］
【表８７】
0006495948.tif 000088
port_speed［非推奨。代わりにフィールド「Ports」「port_speeds」を参照］
【表８８】
0006495948.tif 000089
name
【表８９】
0006495948.tif 000090
created_by
【表９０】
0006495948.tif 000091
email
【表９１】
0006495948.tif 000092
created_date
【表９２】
0006495948.tif 000093
seller_service_name
【表９３】
0006495948.tif 000094
availability_status―「トライアルテスト中」である、サービスプロファイルの可用性状態
service_key
【表９４】
0006495948.tif 000095
state
【表９５】
0006495948.tif 000096
status
【表９６】
0006495948.tif 000097
【０１３８】
応答のサンプル：
HTTP/1.1 200 OK
Content-Type: application/json
[
｛
"buyer_asset"
: ｛"ports": [
｛
"bandwidth": "1 G", 
"bandwidths": [
"1 G, 1 G"
],
"cross_connect_ids": [
"123456", 
"123457"
],
"encapsulation": "Qinq",
"ibx_name": "SV3",
"is_buyout": "N", 
"metro_code": "SV", 
"metro_name": "BAYM", 
"name": 
"QinqVirtualPort", 
"virtualcircuits": [
｛
"bandwidth": "Up to 200MB", 
"cloud_service_name": "CSP1", 
"seller_service_name": "CSP1", 
"availability_status": 
"in_trial_testing", "created_by": 
"reliance user", "created_date": 
"12-12-2014 22:08:06", 
"cross_connect_id": "123456",
"email": "relianceuser@reliance.com",
"id": "5566417575566047323754",
"redundant_id": 
"6939666E3693916437C576", "name": 
"TestCSP1vc2",
"port_speed": 100000000,
"service_key": "87f4f12c-420a-4b3c-9087-c4f82071fd7e",
"state": "Provisioned",
"status": "Enabled"
｝
]
｝
]
｝
｝,
｛
"seller_asset": ""
｝
]
【０１３９】
リソース：仮想回路
説明：仮想回路
【表９７】
0006495948.tif 000098
【０１４０】
ＧＥＴ  仮想回路：
【０１４１】
説明：このＧＥＴ動作の実装により、認証された要求の送信元が所有する全仮想回路のリストが返送される。送信元が仮想回路を有していない場合には、ＨＴＴＰコード２０４を伴う応答が、ペイロードなしで返送される。
【０１４２】
要求
要求ヘッダ：
【表９８】
0006495948.tif 000099
【０１４３】
要求ＵＲＩ：/ecx/v1/virtualcircuits
【０１４４】
フィルタパラメータ
なし
【０１４５】
要求フィールド
なし
【０１４６】
要求のサンプル
GET http://<HostName>/ecx/v1/virtualcircuits/｛virtual_circuit_id｝
【０１４７】
応答
応答フィールド
id
【表９９】
0006495948.tif 000100
redundant_id
【表１００】
0006495948.tif 000101
name
【表１０１】
0006495948.tif 000102
buyer_port
【表１０２】
0006495948.tif 000103
cross_connect_id
【表１０３】
0006495948.tif 000104
port_speed
【表１０４】
0006495948.tif 000105
cloud_service_name
【表１０５】
0006495948.tif 000106
service_key
【表１０６】
0006495948.tif 000107
buyer_vlan
【表１０７】
0006495948.tif 000108
bandwidth
【表１０８】
0006495948.tif 000109
state
【表１０９】
0006495948.tif 000110
status
【表１１０】
0006495948.tif 000111
created_date
【表１１１】
0006495948.tif 000112
created_by
【表１１２】
0006495948.tif 000113
email
【表１１３】
0006495948.tif 000114
seller_port
【表１１４】
0006495948.tif 000115
metro_code
【表１１５】
0006495948.tif 000116
ibx_name
【表１１６】
0006495948.tif 000117
seller_service_name
【表１１７】
0006495948.tif 000118
metadata
【表１１８】
0006495948.tif 000119
“key:value”
【表１１９】
0006495948.tif 000120
【０１４８】
応答のサンプル：
HTTP/1.1 200 OK
Content-Type: application/json
｛
“virtualcircuits”: [
｛
“id” : “4D34239266A3952695956A”,
“name”: “Sample Test VC-7”,
“buyer_port”: “GSE_QA-R-EE-01”,
“cross_connect_id”: “14395166”,
“port_speed”: “1G”,
“cloud_service_name”: “CSP_A_1”,
“service_key”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“buyer_vlan”: “2004.*”,
“bandwidth”: “Up to 200MB”,
“state”: “PROVISIONED”,
“status”: “BILLED”,
“created_date”: “05/23/2014 01:21:54”,
“created_by”: “testuser1”,
“email”: “test@cloudexchange.com”,
“seller_port”: “GSE_QA-SJC-06GMR-CIS-2-SEC-A”,
“metro_code” : “SV”,
“ibx_name” : “SV1” 
"seller_service_name": "cspcreatetest",
"metadata": ｛ 
"key1": "value1", 
"key2": "value2", 
"key3": "value3", 
"key4": "value4", 
"key5": "value5"
｝,
｛
“id” : “1432”,
“name”: “Steve CSP_A Test VC-5”,
“buyer_port”: “GSE_QA-R-EE-01”,
“cross_connect_id”: “14395166”,
“port_speed”: “1G”,
“cloud_service_name”: “CSP_A_1”,
“service_key”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“buyer_vlan”: “2004.*”,
“bandwidth”: “Up to 200MB”,
“state”: “PROVISIONED”,
“status”: “BILLED”,
“created_date”: “05/23/2014 01:21:54”,
“created_by”: “testuser1”,
“email”: “test@cloudexchange.com”,
“seller_port”: “GSE_QA-SJC-1234-CIS-2-SEC-A”,
“metro_code” : “SV”,
“ibx_name” : “SV1” 
｝
]
｝
【０１４９】
応答のエラーコード：
【表１２０】
0006495948.tif 000121
【０１５０】
ＰＯＳＴ  仮想回路:
【０１５１】
説明：仮想回路を作成
【０１５２】
要求
要求ヘッダ：
【表１２１】
0006495948.tif 000122
【０１５３】
要求ＵＲＩ：POST http://<hostname>/ecx/v1/virtualcircuits
【０１５４】
フィルタパラメータ
なし
【０１５５】
要求フィールド
metro_name
【表１２２】
0006495948.tif 000123
metro_code
【表１２３】
0006495948.tif 000124
cloud_service_name
【表１２４】
0006495948.tif 000125
seller_service_name
【表１２５】
0006495948.tif 000126
primary_vc_name
【表１２６】
0006495948.tif 000127
primary_port_name
【表１２７】
0006495948.tif 000128
secondary_vc_name
【表１２８】
0006495948.tif 000129
secondary_port_name
【表１２９】
0006495948.tif 000130
secondary_vlan_id
【表１３０】
0006495948.tif 000131
service_key
【表１３１】
0006495948.tif 000132
virtual_circuit_speed
【表１３２】
0006495948.tif 000133
email
【表１３３】
0006495948.tif 000134
【０１５６】
その他の例示のフィールドは、売り手のサービスプロバイダアカウント番号、売り手のサービスから取得されるデジタル承認キー、境界ゲートウェイプロトコル構成番号、ＶＰＣへの仮想プライベートゲートウェイのＩＤ、買い手のピアＩＰ（買い手／クライアントのインタフェースに付与されるＩＰアドレス）、売り手のサービスプロバイダインタフェースに付与されるＩＰアドレス、ユーザの電子メール、メタデータ（上の記載した通り）、キー（このキー、すなわちＡＰＩユーザがＶＣ作成中にメタデータオブジェクトにおいて渡したその関連値）、及び仮想回路の速度を含んでもよい。
【表１３４】
0006495948.tif 000135
【０１５７】
要求のサンプル
POST http://<HostName>/ecx/v1/virtualcircuits
Authorization: Bearer <accessToken>
Accept: application/xml or application/json
｛
“metro_name”:”Silicon Valley”,
“metro_code”:”SV”,
“cloud_service_name”:” CSP_A_1”,
“primary_vc_name”:”twtca93”,
“primary_port_name”:” GSE_QA-SJC-06GMR-CIS-2-SEC-A”,
“primary_vlan_id”:”188”,
“secondary_vc_name”:”twtcp94”,
“secondary_port_name”:”GSE_QA-SJC-06GMR-CIS-2-SEC-B”,
“secondary_vlan_id”:”188”,
“service_key”:” xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”, 
“virtual_circuit_speed”:”Up to 200MB”,
“email”:test@cloudexchange.com
“metadata”
｝
【０１５８】
応答
【０１５９】
応答フィールド：
result
【表１３５】
0006495948.tif 000136
message
【表１３６】
0006495948.tif 000137
【０１６０】
その他の例示のフィールドは、１次仮想回路ＩＤ、２次仮想回路ＩＤなど、「より多くの情報」を含んでもよい。
【０１６１】
応答のサンプル：
HTTP/1.1 201 CREATED
Location: 4D34239266A3952695956A
｛
"result": "SUCCESS"
"message": "Your Virtual Circuit request was successful."
"more_info": "https://api.developer.cloudexchange.com/docs/api/messages/xx"
｝
【０１６２】
応答のエラーコード：
【表１３７】
0006495948.tif 000138
【０１６３】
いくつかの実施例では、ＡＰＩは、仮想回路を削除するために提供されてもよい。ＤＥＬＥＴＥ動作により、提供された仮想回路が除去され、動作が成功した場合には、ＨＴＴＰコード２００を伴う応答が返送される。仮想回路が、ある売り手のサービスプロバイダに属する場合、それらの売り手のサービスプロバイダは、仮想回路の削除を確認する必要があるであろう。
要求のサンプル
DELETE http://<HostName>/ecx/v1/virtualcircuits/｛virtual_circuit_id｝ 
応答のサンプル：
｛ 
"result": "SUCCESS" 
"message": "Your Virtual Circuit has been deleted successfully." 
"more_info": "" 
｝
【０１６４】
いくつかの実施例では、ＡＰＩに、ＰＡＴＣＨ対応の接続を提供してもよい。売り手が、買い手の接続要求を有効にする前に、さらなる認証段階を必要とする場合には、このＰＡＴＣＨ動作の実装により、ユーザが仮想回路を使用可能にすることができる。
応答のサンプル：
HTTP/1.1 201 CREATED 
｛ 
"result": "SUCCESS", 
"message": "Connection enabling request successful" 
"more_info": ""
【０１６５】
いくつかの実施例では、ＡＰＩは、クラウドエクスチェンジの売り手によって作成されるように、売り手のサービスプロファイルに提供される。クラウドエクスチェンジの売り手は、自身の売り手のサービスに対するプロファイルへの接続性を定義し、設定することが必要とされる。売り手は、自身が提供する各個別サービスのプロファイルを作成できる。
【０１６６】
いくつかの実施例では、ＧＥＴ動作の「仮想回路のペイロードメタデータを取得」の実装によって、所与の売り手のサービスプロファイルに対して仮想回路を作成するのに必要となる、ペイロードメタデータが返送される。
要求のサンプル
GET http://<HostName>/ecx/v1/sellerserviceprofiles/CloudSigma Profile/metadata 
応答のサンプル：
HTTP/1.1 200 OK 
Content-Type: application/json 
｛
"fields": [ 
｛ 
"description": "Code of the metro in which this virtual circuit will be created", 
"name": "metro_code", 
"type": "string" 
｝, 
｛
"description": "Seller Service Name", 
"name": "seller_service_name", 
"type": "string" 
｝, 
｛
"description": "Primary virtual circuit name", 
"name": "primary_vc_name", 
"type": "string" 
｝, 
｛ 
"description": "Buyers primary port name", 
"name": "primary_port_name", 
"type": "string" 
｝, 
｛
"description": "Buyers primary VLAN Id", 
"name": "primary_vlan_id", 
"type": "string" 
｝, 
｛ 
"description": "Secondary virtual circuit name", 
"name": "secondary_vc_name", 
"type": "string" 
｝, 
｛ 
"description": "Buyers secondary port name", 
"name": "secondary_buyer_port_name", 
"type": "string" 
｝, 
｛ 
"description": "Buyers secondary VLAN Id", 
"name": "secondary_buyer_vlan_id", 
"type": "string" 
｝, 
｛ 
"description": "Service Key or Digital Authorization Key obtained from CSP", 
"name": "service_key", 
"type": "string" 
｝, 
｛ 
"description": "Speed of the virtual circuit", 
"name": "virtual_circuit_speed", 
"type": "string" 
｝, 
｛ 
"description": "Email of the user", 
"name": "email", 
"type": "string"
｝ 
] 
｝
【０１６７】
売り手のＡＰＩ
【０１６８】
リソース：ポート
説明：クラウドエクスチェンジのスイッチファブリック上のポート
【表１３８】
0006495948.tif 000139
【０１６９】
ＧＥＴ  ポート：
【０１７０】
説明：このＧＥＴ動作の実装により、認証された要求の送信元が所有する全ポートのリストが返送される。ポートは大都市及びＩＢＸ名でフィルタリングできる。条件に合致するポートが見つからない場合、２０４ＨＴＴＰ応答が、ペイロードなしで返送される。
【０１７１】
要求
【０１７２】
要求ＵＲＩ：
GET http://<HostName>/ecx/v1/ports?metro_code=SV&ibx_name=SV1
【０１７３】
フィルタパラメータ：
metro_code
【表１３９】
0006495948.tif 000140
ibx_name
【表１４０】
0006495948.tif 000141
bandwidth
ポートの帯域幅。帯域幅が提供されない場合には、いかなる帯域幅の容量を伴うポートも返送される。
【０１７４】
要求ヘッダ：
【表１４１】
0006495948.tif 000142
【０１７５】
要求のサンプル：
GET http://<HostName>/ecx/v1/ports?metro_code=SV&ibx=SV1
【０１７６】
応答
応答フィールド：
ports
【表１４２】
0006495948.tif 000143
name
【表１４３】
0006495948.tif 000144
metro_code
【表１４４】
0006495948.tif 000145
metro_name
【表１４５】
0006495948.tif 000146
ibx_name
【表１４６】
0006495948.tif 000147
【０１７７】
その他の例示的フィールド：bandwidths、encapsulation、is_buyout、cross_connect_ids（交差接続のシリアル番号）
【０１７８】
応答のサンプル：
HTTP/1.1 200 OK
Content-Type: application/json
"ports": [
｛
"name": "GSE_QA-R-EE-02",
"metro_code" : “SV”,
"metro_name" : "Silicon Valley",
"ibx_name" : “SV1”
｝,
｛
"name": "GSE_QA-R-EE-01",
"metro_code": "SG",
"metro_name": "Singapore",
"ibx_name" : "SG1"
｝   ] ｝
【０１７９】
応答のエラーコード：
【表１４７】
0006495948.tif 000148
【０１８０】
リソース：売り手のサービスプロファイル
【０１８１】
説明：Ｅｑｕｉｎｉｘクラウドエクスチェンジの売り手によって作成された、売り手のサービスプロファイル。Ｅｑｕｉｎｉｘクラウドエクスチェンジの売り手は、自身の売り手のサービスへの接続性に対するサービスプリファイルを定義し、設定することが必要とされる。売り手は、自身が提供する各個別サービスのプロファイルを作成できる。
【表１４８】
0006495948.tif 000149
【０１８２】
ＰＯＳＴ  売り手のサービスプロファイル。このＰＯＳＴ動作の実装により、ログインユーザ向けに新しい売り手のサービスプロファイルが作成される。例示的要求フィールドは、名前、可用性状態（「トライアルテスト中」又は「注文が利用可能」といった、サービスプロファイルの可用性状態）、仮想回路のラベル、サービスタイプ、ＡＰＩ利用可能（ＡＰＩの統合がこのサービスに利用可能であるか否かを示す）を含む。ＡＰＩの統合により、仮想サービスプロビジョニングの完了が可能である。受諾可能な値は、ＴＲＵＥ及びＦＡＬＳＥ（真偽）、承認キーラベル（これは、売り手の組織が承認キーを何と呼称しているかである）、売り手側に使用されるポートカプセル化の方法、この接続が到達できる売り手のサービスの種類、冗長性の必要（これは、買い手がこの売り手のサービスプロバイダからの仮想回路を要求するときに、２次仮想回路の作成が必要か否かを定義するであろう）である。「はい」の場合、買い手は、１次ポート及び２次ポートの両方、並びにＶＬＡＮのＩＤを提供する必要があるであろう。受諾可能な値は、ＴＲＵＥ（真）及びＦＡＬＳＥ（偽）で、secondary_vlan_same（このフィールドが「ＴＲＵＥ（真）」の値を有する場合、買い手は１次仮想回路及び２次仮想回路の両方に同じＶＬＡＮのＩＤを提供させられるであろう）、capture_buyer_peer_ip（買い手のピアＩＰアドレスを捕捉するか否かを示す）がある。受諾可能な値は、ＴＲＵＥ（真）及びＦＡＬＳＥ（偽）で、買い手のＢＧＰ  ＡＳＮの捕捉、仮想プライベートゲートウェイの捕捉、capture_seller_peer_ip（買い手のピアＩＰアドレスを捕捉するか否かを示す）がある。受諾可能な値はＴＲＵＥ（真）及びＦＡＬＳＥ（偽）である。
【０１８３】
その他の例示の要求フィールドは、帯域幅の閾値警告連絡先を含む。複数の電子メールアドレスは、コンマで区切ることができる。通知連絡先は、仮想回路の要求及び削除を通知されるであろう連絡先である。警告の割合については、帯域幅の閾値はポートごとであり、売り手のサービスプロバイダが使用可能にするであろうポートは、買い手が仮想回路の接続を確立するためであり、提供される仮想回路の速度はallow_custom_speedである。売り手は、買い手がバイアウトポートを有する場合には、買い手はカスタマイズされた速度を選択可能となるように選択できる。
【０１８４】
要求のサンプル
POST http://<HostName>/ecx/v1/sellerserviceprofiles
｛
"name": "TestService123", "availability_status":
"In_Trial_Testing", "virtual_circuit_label": "Virtual
Connection Name", "service_type": "Seller Service
Connectivity", "api_available": "TRUE",
"auth_key_label": "Authorization Key",
"port_encapsulation": "QNQ",
"connection_service_type": "Hybrid",
"require_redundancy": "TRUE",
"secondary_vlan_same": "TRUE",
"capture_buyer_bgp_asn": "FALSE",
"capture_buyer_peer_ip": "TRUE",
"capture_seller_peer_ip": "TRUE",
"capture_virtual_private_gateway": "TRUE",
"threshold_alert_contacts": "user1@equinix.com,user@equinix.com",
"notification_contacts": "user2@equinix.com", "allow_custom_speed":
"TRUE",
"ports": [
"GSE_Test-02",
"GSE_Test-03"
],
"vlan_speeds": [
"Up to 200MB",
"Up to 500MB",
"Up to 1G"
],
"alert_percentage": "90"
｝
【０１８５】
応答フィールド：
【０１８６】
result
【表１４９】
0006495948.tif 000150
【０１８７】
message
【表１５０】
0006495948.tif 000151
【０１８８】
more_info
【表１５１】
0006495948.tif 000152
【０１８９】
応答のサンプル：
HTTP/1.1 200 Created
｛
"result": "SUCCESS",
"message": "The Seller Service Profile has been Created successfully",
"more_info": ""
｝
【０１９０】
ＰＯＳＴ  売り手のサービスプロファイルへのポート
【０１９１】
説明：このＰＯＳＴ動作の実装により、売り手のエクスチェンジのサービス内容に対する所与のポート（ユーザが所有）が使用可能になる。特に、動作によって既存の売り手のサービスプロファイルにポートが追加される。
【０１９２】
注：売り手のサービスプロファイルは、この動作が可能であると承認される必要があるであろう。拒絶又は保留される売り手のサービスプロファイルは、編集が許可されず、承認状態になるまで、ポートを追加することができない。
【０１９３】
要求ＵＲＩ：
【０１９４】
POST http://<HostName>/ecx/v1/sellerserviceprofiles/｛profile_name｝/ports
【０１９５】
別の実施例として、ＤＥＬＥＴＥ動作によって、売り手のサービスプロファイルからポートが除去され、動作が成功した場合には、ＨＴＴＰコード２００を伴う応答が返送される。削除しているポートに関連する、アクティブなＶＣは存在することができず、仮想回路が既にポート上に存在する場合には、ポート上に既存の仮想回路があることを示す、エラーメッセージが表示される。
【０１９６】
少なくとも一つのポートが、サービスプロファイルに存在しなくてはならない。
【０１９７】
別の実施例として、ＰＵＴ動作は、既存の売り手のサービスプロファイルを編集するように使用され、動作が成功した場合には、ＨＴＴＰコード２００を伴う応答が返送される。プロファイルの状態（承認済み又は承認の保留）は、編集動作中には変わらないであろう。
【０１９８】
ＰＵＴ動作で更新できるフィールドは以下の通りである。
【表１５２】
0006495948.tif 000153
【０１９９】
別の例として、「売り手のサービスプロファイルを取得（ＧＥＴ）」は、売り手が作成した売り手の全てのサービスプロファイルのリストを得るように、売り手が使用できる。このＧＥＴ動作の実装により、profile_nameの経路パラメータの一部として渡される、売り手のサービスプロファイルが返送される。売り手のサービス状態によるフィルタリングもまた、パラメータの設定によって利用可能である。
【０２００】
要求のサンプル：
GET  http://<HostName>/ecx/v1/sellerserviceprofiles  （自身の売り手のサービスプロファイル全てを取得）
GET  http://<HostName>/ecx/v1/sellerserviceprofiles/｛profile_name｝  （名前によって売り手のサービスプロファイルを取得）
GET http://<HostName>/ecx/v1/sellerserviceprofiles/｛profile_name｝?status=｛valid_status｝  （名前及び状態によって売り手のサービスプロファイルを取得）
GET  http://<HostName>/ecx/v1/sellerserviceprofiles?status=｛valid_status｝ （状態によって売り手のサービスプロファイルを取得）
【０２０１】
別の実施例として、ＧＥＴ資産は、所与の大都市所在地にある売り手が所有する資産の詳細を取得するように、売り手が使用できる。この売り手に対するＧＥＴ動作の実装により、所与の大都市におけるポート及び仮想回路を含む、全ての資産のリストが返送される。また、売り手も買い手であり得るため、したがって、売り手に対する「資産の種類」は「買い手」及び「売り手」の両方であり得る。
【０２０２】
リソース：仮想回路
【０２０３】
説明：仮想回路
【表１５３】
0006495948.tif 000154
【０２０４】
ＧＥＴ  仮想回路：
【０２０５】
説明：このＧＥＴ動作の実装により、ユーザが所有する仮想回路のリストが返送される。仮想回路は、状態に基づいてフィルタリングできる。仮想回路が条件に合致して見つからない場合には、ＨＴＴＰコード２０４を伴う応答が、ペイロードなしで返送される。
【０２０６】
要求
【０２０７】
要求ＵＲＩ：
GET http://<HostName>/ecx/v1/virtualcircuits?pending=add
フィルタパラメータ：
【０２０８】
pending
【表１５４】
0006495948.tif 000155
【０２０９】
要求ヘッダ：
【表１５５】
0006495948.tif 000156
【０２１０】
要求フィールド：
なし
【０２１１】
要求のサンプル：
GET http://<HostName>/ecx/v1/virtualcircuits?pending=add
【０２１２】
応答
【０２１３】
応答フィールド
id
【表１５６】
0006495948.tif 000157
name
【表１５７】
0006495948.tif 000158
buyer_port
【表１５８】
0006495948.tif 000159
cross_connect_id
【表１５９】
0006495948.tif 000160
port_speed
【表１６０】
0006495948.tif 000161
cloud_service_name
【表１６１】
0006495948.tif 000162
service_key
【表１６２】
0006495948.tif 000163
buyer _vlan
【表１６３】
0006495948.tif 000164
bandwidth
【表１６４】
0006495948.tif 000165
status
【表１６５】
0006495948.tif 000166
created_date
【表１６６】
0006495948.tif 000167
created_by
【表１６７】
0006495948.tif 000168
email
【表１６８】
0006495948.tif 000169
seller_port
【表１６９】
0006495948.tif 000170
metro_code
【表１７０】
0006495948.tif 000171
ibx_name
【表１７１】
0006495948.tif 000172
その他の実施例において上記に含まれるような、その他の例示的フィールドが使用されてもよい。
【０２１４】
応答のサンプル：
HTTP/1.1 200 OK
Content-Type: application/json
｛
“virtualcircuits”: [
｛
“id” : “4D34239266A3952695956A”,
“name”: “Test Virtual Circuit”,
“buyer_port”: “GSE_QA-R-EE-01”,
“cross_connect_id”: “11111111”,
“port_speed”: “1G”,
“cloud_service_name”: “CSP_A_1”,
“service_key”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“buyer_vlan”: “2004.*”,
“bandwidth”: “Up to 200MB”,
“status”: “BILLED”,
“created_date”: “05/23/2014 01:21:54”,
“created_by”: “temp user”,
“email”: “test@cloudexchange.com”,
“seller_port”: “sellerport”,
“metro_code” : “SV”,
ibx_name” : “SV1” 
｝   ] ｝
【０２１５】
応答のエラーコード：
【表１７２】
0006495948.tif 000173
【０２１６】
ＰＡＴＣＨ  仮想回路：
【０２１７】
説明：ＰＡＴＣＨ動作は、売り手による仮想回路上での以下の３つの種類の動作を行うために使用できる。
・買い手によって作成される仮想回路を受諾
・買い手によって作成される仮想回路を拒絶
・買い手による仮想回路の削除を確認
【０２１８】
要求
【０２１９】
要求ＵＲＩ：
PATCH http://<HostName>/ecx/v1/virtualcircuits/｛virtual_circuit_id｝
要求ヘッダ：
【表１７３】
0006495948.tif 000174
【０２２０】
要求フィールド：
action
【表１７４】
0006495948.tif 000175
port_name
【表１７５】
0006495948.tif 000176
vlan_id
【表１７６】
0006495948.tif 000177
redundant_vlan_id
reject_comment―仮想回路の拒絶を説明する、売り手側のコメント
【０２２１】
要求のサンプル
PATCH http://<hostname>/ecx/vc2/virtualcircuit/4D34239266A3952695956A 
｛
“action” : “approve”,
“port_name” : “GSE_QA-SJC-06GMR-CIS-2-SEC-A”,
“vlan_id” : “188”
｝
【０２２２】
応答：
【０２２３】
応答フィールド：
result
【表１７７】
0006495948.tif 000178
【０２２４】
応答のサンプル：
HTTP/1.1 200 OK
｛
"result": "SUCCESS",
"message": "The requested virtual circuit has been rejected and the buyer 
has been notified.",
"more_info": 
"https://api.developer.cloudexchange.com/docs/api/messages/vcs/2”
｝
【０２２５】
応答のエラーコード：
【表１７８】
0006495948.tif 000179
【０２２６】
全エラーコード
【表１７９】
0006495948.tif 000180
【０２２７】
その他のエンドポイント４０６は、ログイン４０６Ａ、ポート４０６Ｂ、大都市４０６Ｃ、仮想回路４０６Ｅ、クラウドサービス４０６Ｆに対して上記で提供されるのと類似する、要求／応答方式を有してもよい。
【０２２８】
ログイン４０６Ａによって、認証及び承認された提携企業及び顧客による相互接続資産へのアクセスのための安全なチャネルを有効にする。その上、相互接続プラットフォームは、セキュリティ問題（脅威からの保護、ＳＱＬインジェクションからの保護、ＤＤｏＳ攻撃の防止、ＪＳＯＮ爆弾の防止など）に対処するために、追加設定不要の機能を提供する。いくつかの実施例では、エンティティは、ログイン４０６Ａを使用して、セキュリティトークン（例えば、ＯＡｕｔｈ２．０トークン）を取得するために、認証情報（例えば、ユーザ名、パスワード、ＡＰＩキー、及び／又はＡＰＩシークレット）を使用し、セキュリティトークンはその後、現在承認されているエンティティによってその他のエンドポイント４０６に発行される要求が、承認された顧客又は提携企業からであることを保証する。
【０２２９】
いくつかの実施例では、ＡＰＩゲートウェイ４０３は、エンドポイント４０６のいずれへの要求に従ったフォーマットのアプリケーションデータを変換し、変換されたアプリケーションデータを使用して、オーケストレーションエンジン４０７へ呼び出しを行う。オーケストレーションエンジン４０７は、本実施例において、クラウドエクスチェンジプラットフォームサービス４０８Ａ〜４０８Ｈ（総称して「プラットフォームサービス４０８」）を実装するように構成される、一つ以上の現実のサーバ及び／又は仮想マシンを表してもよい。ＡＰＩゲートウェイ４０３Ａによる呼び出しに応じて、オーケストレーションエンジン４０７のワークフロー及びルールエンジン（図３Ｂには図示せず）は、概して、プラットフォームサービス４０８のうちの一つと関連する全体の機能内に合う、クラウドエクスチェンジのＡＰＩサービス４０９のワークフローを生成するように、定義されたルール及びポリシーを適用してもよい。示す通り、プラットフォームサービス４０８は、ポリシー管理４０８Ａ、プロファイル及び構成４０８Ｂ、支払請求及び請求書の送付４０８Ｃ、売り手のＡＰＩ統合４０８Ｄ、仮想回路管理４０８Ｅ、ネットワークインタフェース管理４０８Ｆ、検索及び推奨４０８Ｇ、インベントリ及び場所検出４０８Ｈを含む。プラットフォームサービスの各々は、クラウドサービスのプロビジョニングの異なる態様に対する、ワークフロー及びルールエンジンを表してもよい。
【０２３０】
クラウドエクスチェンジのＡＰＩサービス４０９Ａ〜４０９Ｒ（総称して「クラウドエクスチェンジサービス４０９」）は、実施例の通り、プロバイダ及び顧客に対して、クラウドエクスチェンジのネットワークインフラを修正し、コンテンツを管理し、インシデントを管理し、インベントリ及び容量を管理し、安全なアクセスを保証し、注文／支払請求を管理するように、相互接続プラットフォームによって提供されるサービスを表す。クラウドエクスチェンジサービス４０９のいずれも、ワークフローを管理するオーケストレーションエンジン４０７によって呼び出し可能な要求／応答トランザクションに対するマイクロサービスのかたまりを、それ自体で表してもよい。
【０２３１】
クラウドエクスチェンジサービス４０９は、要求の検証４０９Ａ、承認及び監査４０９Ｂ、アカウント及びプロファイル管理４０９Ｃ、インベントリ管理４０９Ｄ、容量管理４０９Ｅ、ネットワークのプロビジョニング４０９Ｆ、信用調査検証ツール４０９Ｇ、支払請求４０９Ｈ、売り手のＡＰＩ統合４０９Ｉ、場所４０９Ｊ、トラブルチケット管理４０９Ｋ、ローカライズ４０９Ｌ、稼働率統計４０９Ｍ、推奨４０９Ｎ、スケジューラ及びバッチプロセッサ４０９Ｏ、通知４０９Ｐ、エラーパーサ４０９Ｑ、並びにコンテンツ管理４０９Ｒを含む。売り手の統合４０９Ｉによって、オーケストレーションエンジン４０７が、ＣＳＰの売り手アプリケーションのソフトウェアインタフェースを呼び出すこと、例えば、売り手アプリケーションが、売り手の代わりに仮想回路の追加及び削除（ＮＳＰ／顧客によって要求される通り）を確認することを要求することが可能になってもよい。
【０２３２】
図４は、本開示に記載する技術に従う、クラウドエクスチェンジ用の相互接続プラットフォーム１０３の代替の説明を示すブロック図である。この図において、相互接続プラットフォーム１０３の技術アーキテクチャは、ＡＰＩクエリを検証して満たし、ＡＰＩコマンドを検証して満たし、サブシステム１２０を相互接続オーケストレーションエンジン４０７と統合する、ＡＰＩサービス層４２０を含む。データセンターの一つ以上の現実のサーバ及び／又は仮想マシンは、相互接続オーケストレーションエンジン４０７、ＡＰＩサービス層４２０のサービス、及びサブシステム１２０の各々を実行してもよい。相互接続ＡＰＩエンドポイント４０６は、ＡＰＩコンシューマ４０２（図３Ａ）がクラウドエクスチェンジの相互接続の管理に利用してもよい、例示のＡＰＩエンドポイントである。
【０２３３】
ワークフロー管理及びルーティング構成要素４１０は、ワークフローを管理し、ＡＰＩの呼び出しを、ＡＰＩサービス層４２０の様々なマイクロサービスを呼び出すことによって、連結された機能性を実施する、エンジン４１２Ａ〜４１２Ｊ（総称して「エンジン４１２」）へのエンドポイント４０６にルーティングする。エンジン４１２は、認証及び承認エンジン４１２Ａ、構成、監査、及び追跡エンジン４１２Ｂ、ＡＰＩコマンドコントローラ４１２Ｃ、ＡＰＩクエリコントローラ４１２Ｄ、サービス合成エンジン４１２Ｅ、注文管理エンジン４１２Ｆ、通知エンジン４１２Ｇ、推奨及び分析エンジン４１２Ｈ、相互接続インタフェースエンジン４１２Ｉ、並びにＡＰＩワークフロー及びルールリポジトリ４１２Ｊを含む。
【０２３４】
ＡＰＩサービス層の例示のＡＰＩサービスは、示す通り、要求パラメータ検証サービス４２４Ａ及びクエリ提供サービス４２４Ｂを有するＡＰＩクエリサービス４２２Ａと、要求本体検証サービス４２４Ｃ及びコマンド提供サービス４２４Ｄを有するＡＰＩコマンドサービス４２２Ｂと、要求委譲及びサービスアダプタ４２４Ｅ並びに応答解析及び変換４２４Ｆを有する統合ファサードサービス４２２Ｃとを含む。
【０２３５】
サブシステム１２０の実施例を図４に示す。ＩＤ及びアクセス管理システム４２６Ａは、相互接続プラットフォームサービスへの有効なアクセスに対する認証及び承認を実施する。本明細書の他の箇所に記載する通り、売り手のＡＰＩ統合モジュール４２６Ｂは、クラウドサービスプロバイダネットワークとの相互接続を作成及び検証するために、相互接続プラットフォーム１０３のクラウドサービスプロバイダＡＰＩとの統合を促進する。クラウドエクスチェンジデータベース４２８は、相互接続プラットフォーム１０３によって管理されるクラウドエクスチェンジの構成を記述する、構成データベースを表す。ネットワークシステム４２６Ｃは、相互接続プラットフォーム１０３によって管理されるクラウドエクスチェンジのネットワークインフラをプロビジョニングし、構成し、問い合わせ、そうでなければ制御する。注文管理システム４２６Ｄは、例えば、仮想回路に対する顧客の注文のエンドツーエンド管理を実施する。インシデント管理システム４２６Ｅは、クラウドエクスチェンジプロバイダへの警告や、顧客への通知などによって、相互接続プラットフォームによって管理されるクラウドエクスチェンジにおけるエラーの処理を促進する。コンテンツ管理システム４２６Ｆは、相互接続プラットフォーム１０３用のコンテンツを管理する。
【０２３６】
図５〜１１は、本開示に記載する通り、クラウドエクスチェンジの相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示す。
【０２３７】
図５の実施例において、ＡＰＩ開発者４０２（例えば、買い手／売り手／第三者）は、クラウドエクスチェンジの相互接続を管理するように、サービス４０９を利用できる。図５は、全てのクラウドサービスプロバイダ（ＣＳＰ）に適用可能な仮想回路の作成に使用できるプロセスを示す。例えば、ＡＰＩ開発者４０２のうちの一人は、ユーザ名、パスワード、ＡＰＩキー、及びＡＰＩシークレットのうちの一つ以上などのログイン情報を、ＡＰＩゲートウェイ４０３に渡すことができる（４５４Ａ）。ＡＰＩゲートウェイ４０３は、ＡＰＩキー及びＡＰＩシークレットの検証を実施し（４５４Ｂ）、ＩＤ管理及び連携４５０と相互作用し（４５４Ｃ、４５４Ｄ）、ＯＡｕｔｈ２．０トークンをＡＰＩ開発者４０２に戻して提供する（４５４Ｅ）。ＡＰＩ開発者４０２は、ＯＡｕｔｈ２．０トークンを受信し、ＯＡｕｔｈ２．０トークン及び一つ以上のパラメータをＡＰＩゲートウェイ４０３に提供する（４５４Ｆ）ことによって、ＡＰＩエンドポイント（例えば、ＡＰＩエンドポイント４０６のうちの一つ）を呼び出すことができる。ＡＰＩゲートウェイ４０３は、データ形式の変換（例えば、ＸＭＬ、ＪＳＯＮ）（４５４Ｇ）及びＯＡｕｔｈ２．０トークンの検証（４５４Ｈ）を実施してもよい。その後ＡＰＩゲートウェイ４０３は、クラウドエクスチェンジプラットフォームサービスを呼び出す（４５６Ａ）ように、オーケストレーションエンジン４０７に連絡する。
【０２３８】
オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整する。例えば、オーケストレーションエンジン４０７のワークフロー及びルールエンジン３０６は、ポリシー３０８Ａ、プロファイル３０８Ｂ、構成３０８Ｃ、及びマイクロサービス３０８Ｄ（図２）のうちの一つ以上に基づいて、ＡＰＩワークフローを調整できる。一般的に言えば、オーケストレーションエンジン４０７は、並行して、又は構成されたルール及び／若しくはポリシーに基づき定義された順序で、一つ以上のサービス４０９を呼び出せる。図５の実施例では、オーケストレーションエンジン４０７は、サービス４０９のサービスＡ及びサービスＢを呼び出し（４６０Ａ、４６０Ｂ）、その後サービスＡからの応答を受信し（４６０C）、サービスＢからの応答を受信する（４６０Ｄ）。それからオーケストレーションエンジン４０７は、サービスＣを呼び出し（４６０Ｅ）、サービスＣからの応答を受信する（４６０Ｆ）。オーケストレーションエンジン４０７は、ＡＰＩゲートウェイ４０３に、クラウドエクスチェンジプラットフォームサービスからの応答を送信する（４５６Ｂ）。ＡＰＩゲートウェイ４０３は、クラウドエクスチェンジプラットフォームサービスからの応答を受信し、応答の中で受信した情報のデータ形式の変換（例えば、ＸＭＬ、ＪＳＯＮ）（４５４Ｉ）を実施してもよい。ＡＰＩゲートウェイ４０３は、ＡＰＩエンドポイントを呼び出したＡＰＩ開発者４０２に、一つ以上の応答ヘッダ及び本体を送信する（４５４Ｊ）。
【０２３９】
このように、オーケストレーションエンジン４０７は、クラウドエクスチェンジに相互接続プラットフォームを提供し、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に相互接続資産情報の利用を可能にする。図５で概要を述べたプロセスは、ＡＰＩ開発者に一つ以上の仮想回路について情報を取得することを可能とする場合、ＡＰＩ開発者に一つ以上の相互接続資産（例えば、大都市をベースとするクラウドエクスチェンジ、クラウドエクスチェンジポイント、クラウドエクスチェンジのポート）について情報を取得することを可能とする場合、売り手が接続性のパラメータを定義することを可能とする場合、ＡＰＩ開発者に、買い手による仮想回路の作成、又は仮想回路のほぼリアルタイムでの削除において予期される、クラウドサービスプロファイル及び属性について情報を取得することを可能とする場合など、異なるユースケースに適用されてもよい。
【０２４０】
図６は、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に相互接続資産情報の利用を可能とする際に、クラウドエクスチェンジ用の相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。図６は、図５に関して上に記載したものと類似のいくつかの動作を含む。クラウドエクスチェンジプラットフォームサービスを呼び出すＡＰＩゲートウェイ４０３からの要求の受信に応じて、オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整できる。例えば、図６では、ＡＰＩ開発者４０２が、マシンツーマシンの相互作用によって、パーミッションデータ記憶部４５２からＯＡｕｔｈ２．０トークンなどの情報を取得することが可能になる。具体的には、ＡＰＩゲートウェイ４０３は、ＡＰＩ開発者４０２からユーザ名及びパスワードを受信し（４５４Ａ）、検証（４５４Ｂ）後に、受信したユーザ名及びパスワードをＩＤ管理及び連携４５０に送信する（４５４Ｃ）ことができ、そうすることによってＩＤ管理及び連携４５０はパーミッションデータ記憶部４５２にこの情報を提供し（４６２Ａ）、パーミッションデータ記憶部４５２はユーザ名及びユーザキーをＩＤ管理及び連携４５０に返送する（４６２Ｂ）。ＩＤ管理及び連携４５０は、ＳＡＭＬからＯＡｕｔｈへのマッピング（４６２Ｃ）を実施してもよく、ＯＡｕｔｈトークンをＡＰＩゲートウェイ４０３に提供する（４５４Ｄ）。ＡＰＩゲートウェイ４０３は、ＯＡｕｔｈトークンからゲートウェイへのＯＡｕｔｈ２．０マッピング（４６２Ｄ）を実施でき、随意でＸＭＬ／ＪＳＯＮ変換（４６２Ｅ）を実施してもよい。その後ＡＰＩゲートウェイ４０３は、ＯＡｕｔｈ２．０トークンをＡＰＩ開発者４０２に提供する（４５４Ｅ）。
【０２４１】
図7は、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に相互接続資産情報の利用を可能とする際に、クラウドエクスチェンジ用の相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。図７は、図５に関して上に記載したものと類似のいくつかの動作を含む。ＡＰＩゲートウェイ４０３からのクラウドエクスチェンジプラットフォームサービスを呼び出す要求の受信（４７０Ｅ）に応じて、オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整できる。例えば、図７は、ポートのエンドポイントを呼び出す、ＡＰＩ開発者４０２からの最初の要求に含まれていたポートのパラメータを指定する、サービス４０９のポート要求パラメータ検証サービスを、オーケストレーションエンジン４０７がどのように呼び出す（４７０Ｆ）ことができるのかを示す。オーケストレーションエンジン４０７は、ポートの要求パラメータが有効か否かを示す、ポートの要求パラメータ検証サービスからの応答を受信する（４７０Ｇ）。その後オーケストレーションエンジン４０７は、ポートのクエリサービスを呼び出し（４７０Ｈ）、例えば、ポートの要求パラメータに基づいて、特定のポート情報を指定する、ポートのクエリサービスからの応答を受信できる（４７０Ｉ）。オーケストレーションエンジン４０７は、クラウドエクスチェンジプラットフォームサービスからＡＰＩゲートウェイ４０３への応答（４７０Ｊ）にポート情報を含めることができ、そしてＡＰＩゲートウェイ４０３は、ポート情報をＡＰＩ開発者４０２に提供できる（４７０Ｌ）。
【０２４２】
図８は、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に相互接続資産情報の利用を可能とする際に、クラウドエクスチェンジ用の相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。図８は、図５に関して上に記載したものと類似のいくつかの動作を含む。ＡＰＩゲートウェイ４０３からのクラウドエクスチェンジプラットフォームサービスを呼び出す要求の受信（４７０Ｅ）に応じて、オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整できる。例えば、図８は、大都市のエンドポイントを呼び出す、ＡＰＩ開発者４０２からの最初の要求に含まれていた都市のパラメータを指定する、サービス４０９の大都市要求パラメータ検証サービスを、オーケストレーションエンジン４０７がどのように呼び出す（４７２Ｆ）ことができるのかを示す。オーケストレーションエンジン４０７は、例えば、大都市の要求パラメータが有効か否かを示す、大都市の要求パラメータ検証サービスからの応答を受信する（４７２Ｇ）。その後オーケストレーションエンジン４０７は、大都市のクエリサービスを呼び出し（４７２Ｈ）、例えば、大都市の要求パラメータに基づいて、特定の大都市情報を指定する、大都市のクエリサービスからの応答を受信できる（４７２Ｉ）。オーケストレーションエンジン４０７は、クラウドエクスチェンジプラットフォームサービスからＡＰＩゲートウェイ４０３への応答（４７２Ｊ）に大都市情報を含めることができ、そしてＡＰＩゲートウェイ４０３は、大都市情報をＡＰＩ開発者４０２に提供できる（４７２Ｌ）。
【０２４３】
図９は、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に相互接続資産情報の利用を可能とする際に、クラウドエクスチェンジ用の相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。図９は、図５に関して上に記載したものと類似のいくつかの動作を含む。ＡＰＩゲートウェイ４０３からのクラウドエクスチェンジプラットフォームサービスを呼び出す要求の受信（４７４Ｅ）に応じて、オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整できる。例えば、図９は、クラウドサービスのエンドポイントを呼び出す、ＡＰＩ開発者４０２からの最初の要求に含まれていたクラウドサービスのパラメータを指定する、サービス４０９のクラウドサービスの要求パラメータ検証サービスを、オーケストレーションエンジン４０７がどのように呼び出す（４７４Ｆ）ことができるのかを示す。オーケストレーションエンジン４０７は、例えば、クラウドサービスの要求パラメータが有効か否かを示す、クラウドサービスの要求パラメータ検証サービスからの応答を受信する（４７４Ｇ）。その後オーケストレーションエンジン４０７は、クラウドサービスのクエリサービスを呼び出し（４７４Ｈ）、例えば、クラウドサービスの要求パラメータに基づいて、特定のクラウドサービス情報を指定する、クラウドサービスのクエリサービスからの応答を受信できる（４７４Ｉ）。オーケストレーションエンジン４０７は、クラウドエクスチェンジプラットフォームサービスからＡＰＩゲートウェイ４０３への応答（４７４Ｊ）にクラウドサービス情報を含めることができ、そしてＡＰＩゲートウェイ４０３は、クラウドサービス情報をＡＰＩ開発者４０２に提供できる（４７４Ｌ）。
【０２４４】
図１０は、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に相互接続資産情報の利用を可能とする際に、クラウドエクスチェンジ用の相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。図１０は、図５に関して上に記載したものと類似のいくつかの動作を含む。ＡＰＩゲートウェイ４０３からの仮想回路の閲覧の要求、及びクラウドエクスチェンジプラットフォームサービスの呼び出し（４７６Ｅ）に応じて、オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整できる。例えば、図１０は、仮想回路のエンドポイントを呼び出す、ＡＰＩ開発者４０２からの最初の要求（４７６Ａ）に含まれていた仮想回路のパラメータを指定する、サービス４０９の仮想回路の要求パラメータ検証サービスを、オーケストレーションエンジン４０７がどのように呼び出す（４７６Ｆ）ことができるのかを示す。オーケストレーションエンジン４０７は、例えば、仮想回路の要求パラメータが有効か否かを示す、仮想回路の要求パラメータ検証サービスからの応答を受信する（４７６Ｇ）。その後オーケストレーションエンジン４０７は、仮想回路のクエリサービスを呼び出し（４７６Ｈ）、例えば、仮想回路の要求パラメータに基づいて、特定の仮想回路情報を指定する、仮想回路のクエリサービスからの応答を受信できる（４７６Ｉ）。オーケストレーションエンジン４０７は、クラウドエクスチェンジプラットフォームサービスからＡＰＩゲートウェイ４０３への応答（４７６Ｊ）に仮想回路情報を含めることができ、そしてＡＰＩゲートウェイ４０３は、仮想回路情報をＡＰＩ開発者４０２に提供できる（４７６Ｌ）。
【０２４５】
図１１は、マシンツーマシンの相互作用によって、ＡＰＩ開発者４０２に代わって相互接続資産を動的に管理する際に、クラウドエクスチェンジ用の相互接続プラットフォームの例示構成要素によって実施される、コールフロー及び動作を示すフロー図である。図１１は、図５に関して上に記載したものと類似のいくつかの動作を含む。ＡＰＩゲートウェイ４０３からのクラウドエクスチェンジプラットフォームサービスを呼び出す要求の受信（４８０Ｅ）に応じて、オーケストレーションエンジン４０７は、定義されたルール及び応答に基づいてＡＰＩワークフローを調整できる。例えば、図１１は、仮想回路のエンドポイントを呼び出す、ＡＰＩ開発者４０２からの最初の要求（４８０Ａ）に含まれる大都市コードを検証するように、大都市のサービスを、オーケストレーションエンジン４０７がどのように呼び出す（４８０Ｆ）ことができるのかを示す。オーケストレーションエンジン４０７は、大都市のサービスからの応答を受信する（４８０Ｇ）。
【０２４６】
その後オーケストレーションエンジン４０７は、クラウドサービスでクラウドサービスプロバイダ名を検証（４８０Ｈ）し、クラウドサービスからの応答を受信できる（４８０Ｉ）。それからオーケストレーションエンジン４０７は、売り手及び買い手のポートを検証するように、ポートのサービスを呼び出し（４８０Ｊ）、ポートが、要求された仮想回路に対して有効か否かを指定する、ポートのサービスからの応答を受信できる（４８０Ｋ）。その後オーケストレーションエンジン４０７は、クラウドエクスチェンジ内に自動で仮想回路を構成するように、ネットワークサービスのプロビジョニングサービス（例えば、図３Ｂのネットワークプロビジョニングサービス４０９Ｆ）を呼び出し（４８０Ｌ）、ネットワークサービスのプロビジョニングサービスからの応答を受信できる（４８０Ｍ）。それからオーケストレーションエンジン４０７は、支払請求サービス（例えば、図３Ｂの支払請求サービス４０９Ｈ）を呼び出し（４８０Ｎ）、支払請求サービスからの応答を受信できる（４８０Ｏ）。その後オーケストレーションエンジン４０７は、仮想回路の作成を完了するように、ＣＳＰのＡＰＩを呼び出し（４８０Ｐ）、ＣＳＰのＡＰＩからの応答を受信できる（４８０Ｑ）。オーケストレーションエンジン４０７は、クラウドエクスチェンジプラットフォームサービスからＡＰＩゲートウェイ４０３への応答（４８０Ｒ）の中に、例えば、仮想回路が正常に作成されたか否かを記述する仮想回路情報、確認パラメータ、及び接続性パラメータを含めることができ、そしてＡＰＩゲートウェイ４０３は、要求するＡＰＩ開発者４０２に仮想回路情報を提供できる（４８０Ｔ）。
【０２４７】
このように、本開示の技術は、マシンツーマシンの相互作用によって、仮想回路及びポートの情報などの相互接続資産情報を、開発者が利用可能とするように使用できる。いくつかの実施例では、本開示の技術は、相互接続プラットフォームへのアクセスを、マシンツーマシンの相互作用によって、異なる帯域幅の仮想回路を作成又は修正することを可能にできる。いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用によって、異なる大都市及びデータセンターにおける競合他社の存在についてカスタマイズされた分析を取得するように、売り手（例えば、ＣＳＰ、ＮＳＰ、及びマネージドＳＰ（ＭＳＰ））を相互接続プラットフォームにアクセス可能にできる。
【０２４８】
いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用によって、既にポートの存在を有する地域にあるクラウドサービスの存在についてカスタマイズされた分析を取得するように、買い手（例えば、ＮＳＰ、企業）を相互接続プラットフォームにアクセス可能にできる。いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用によって、異なる大都市及びデータセンターにわたる買い手のポート密度についてカスタマイズされた分析を取得するように、売り手（ＣＳＰ、ＮＳＰ、及びＭＳＰ）を相互接続プラットフォームにアクセス可能にできる。いくつかの実施例では、本開示の技術は、相互接続資産への提携企業のアクセスを検証するように、自動化されたＡＰＩ要求の遮断を可能にし、その結果マシンツーマシンの相互作用によって、提携企業の資産のセキュリティを保証できる。いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用及び相互接続プラットフォームリソースへの直接アクセスによって、オンデマンドのアクセスで、仮想回路を動的に設定し解体することを可能にできる。いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用及び相互接続プラットフォームリソースへの直接アクセスによって、オンデマンドのアクセスで、事前に定義された間隔で、仮想回路を設定及び解体する予定を決めることを可能にできる。いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用によって、より低い帯域幅の使用率を充分に利用して、データのバックアップ又は復元など、バッチ処理タスクのより速い完了を可能にする（速度のバースト）ように、事前に予定を決められたある時間に、買い手（ＮＳＰ及び企業）に対して仮想回路の速度バーストの要求を受諾し許可することができる。
【０２４９】
いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用によって、データセンター、大都市、及び区域にわたる仮想回路のトラフィック使用率に関するカスタマイズされた詳細な分析を可能にできる。いくつかの実施例では、本開示の技術は、マシンツーマシンの相互作用によって、ＡＰＩを経由して提携企業の開発者及びビジネスチームに、最適な性能、低遅延、及びより優れた相互接続性のための、ポート及び仮想回路の設定に関するカスタマイズされた詳細な推奨を提供できる。いくつかの実施例では、本開示の技術は、ＡＰＩの使用によって、相互接続資産へのマシンに基づくアクセスを可能にできる。いくつかの実施例では、本開示の技術は、ＡＰＩのエコシステムを使用することで、買い手と売り手との間に仮想回路をオンデマンドで設定することを可能にできる。いくつかの場合では、ＡＰＩは、相互接続プラットフォーム全体の複雑さを取り除きながら、場所の検出、資産の検出、クラウドサービスの検出、カスタマイズされたトラフィック分析、カスタマイズされた稼働率分析、優れた推奨エンジン、及びエンドツーエンドの自動化された仮想回路プロビジョニングシステムを利用可用とすることによって、買い手と売り手との間にさらにより良い接続性を可能にしてもよい。またＡＰＩによって、認証及び承認された提携企業及び顧客による、クラウドエクスチェンジのドメインの外側にある相互接続資産へのアクセスに対して、安全なチャネルを使用可能にできる。ＡＰＩプラットフォームは、セキュリティ問題（例えば、脅威からの保護、ＳＱＬインジェクションからの保護、ＤＤｏＳ攻撃の防止、ＪＳＯＮ爆弾の防止など）に対処するために、追加設定不要の機能を提供する。
【０２５０】
クラウドベースのサービス交換の実施例の詳細は、２０１５年４月１７日出願の米国特許仮出願番号第６２／１４９，３７４号「Cloud-based Services Exchange」において見つけられ、参照により全て本発明に援用される。
【０２５１】
直接的なＬ３／ＢＧＰピアリングによるイーサネット（登録商標）及びＬ３／インターネットに対するサービス交換のさらなる実施例の詳細は、２０１２年９月１３日出願の米国特許第８，５３７，８４５号「REAL TIME CONFIGURATION AND PROVISIONING FOR A CARRIER ETHERNET（登録商標） EXCHANGE」、１）参照により全て本発明に援用される、２００９年１２月１０日出願の米国特許仮出願番号第６１／２８５，３７１号「ETHERNET（登録商標） EXCHANGE」、２）参照により全て本発明に援用される、２００９年９月４日出願の米国特許仮出願番号第６１／２３９，９９７号「PRIVATE NETWORK CONNECTIVITY PLATFORM」、及び３）参照により全て本発明に援用される、２０１０年４月１２日出願の米国特許仮出願番号第６１／３２３，０６６号「ETHERNET（登録商標） EXCHANG」、以上三つ全ての利益及び優先権を主張する、２０１０年９月２日出願の米国特許出願番号第１２／８７５，０５４号「REAL TIME CONFIGURATION AND PROVISIONING FOR A CARRIER ETHERNET（登録商標） EXCHANGE」、並びに２０１０年９月２日出願の米国特許出願番号第１２／８７５，０５４号「REAL TIME CONFIGURATION AND PROVISIONING FOR A CARRIER ETHERNET（登録商標） EXCHANGE」において見つけられる。上の特許及び特許出願の各々は、参照によりそれぞれ全て本発明に援用される。
【０２５２】
図１２は、本開示の一つ以上の技術に従い動作する、コンピュータデバイスの一実施例のさらなる詳細を示すブロック図である。図１２は、ＡＰＩゲートウェイ１１２／４０３、オーケストレーションエンジン１１８／４０７、サブシステム１２０、又は本明細書に記載するいかなる他のコンピュータデバイスのうちのいずれか一つ以上を実行する、一つ以上のプロセッサ５０２を含む、サーバ又はその他のコンピュータデバイス５００の特定の一実施例を示してもよい。コンピュータデバイス５００のその他の実施例は、その他の例において使用してもよい。例示のためスタンドアローンのコンピュータデバイス５００として図１２に示すものの、コンピュータデバイスは、ソフトウェア命令を実行する、一つ以上のプロセッサ又はその他の好適なコンピュータ環境を含む、いかなる構成要素又はシステムであってもよく、例えば、必ずしも図１２に示す一つ以上の要素を含む必要はない（例えば、通信部５０６、及びいくつかの実施例では、記憶デバイス５０８などの構成要素は、同じ場所に設置されなくてもよく、又はその他の構成要素として同じ筐体の中になくてもよい）。コンピュータデバイス５００は、例えば、クラウドエクスチェンジポイント１２８のうちのいずれかの内部、別の相互接続施設内、又は支部若しくはクラウドエクスチェンジプロバイダによって採用若しくは使用されるクラウドコンピューティング環境に設置され、実行されてもよい。
【０２５３】
図１２の特定の実施例に示す通り、コンピュータデバイス５００は、一つ以上のプロセッサ５０２、一つ以上の入力デバイス５０４、一つ以上の通信部５０６、一つ以上の出力デバイス５１２、一つ以上の記憶デバイス５０８、並びにユーザインタフェース（ＵＩ）デバイス５１０及び通信部５０６を含む。コンピュータデバイス５００は、一実施例では、コンピュータデバイス５００によって実行可能である、一つ以上のアプリケーション５２２、仮想概念構築アプリケーション５２４、及びオペレーティングシステム５１６をさらに含む。構成要素５０２、５０４、５０６、５０８、５１０、及び５１２の各々は、構成要素間通信のために（物理的に、通信可能に、及び／又は動作可能に）結合される。いくつかの実施例では、通信チャネル５１４は、システムバス、ネットワーク接続、プロセス間通信データ構造、又はデータを伝達するいかなる他の方法を含んでもよい。一実施例として、構成要素５０２、５０４、５０６、５０８、５１０、及び５１２は、一つ以上の通信チャネル５１４によって結合されてもよい。コンピュータデバイス５００は、例えば、クラウドエクスチェンジポイント１２８のうちのいずれかの内部、別の相互接続施設内、又は支部若しくはクラウドエクスチェンジプロバイダによって採用若しくは使用されるクラウドコンピューティング環境に設置され、実行されてもよい。
【０２５４】
プロセッサ５０２は、一実施例では、コンピュータデバイス５００内で実行する機能性及び／又はプロセス命令を実装するように構成される。例えば、プロセッサ５０２は、記憶デバイス５０８に記憶される命令の処理を行うことが可能であってもよい。プロセッサ５０２の実施例には、マイクロプロセッサ、コントローラ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は同等の個別若しくは統合論理回路のうちのいかなる一つ以上を含んでもよい。
【０２５５】
一つ以上の記憶デバイス５０８は、動作中コンピュータデバイス５００内に情報を記憶するように構成されてもよい。記憶デバイス５０８は、いくつかの実施例では、コンピュータで読み取り可能な記憶媒体として記載される。いくつかの実施例では、記憶デバイス５０８は一時メモリであり、記憶デバイス５０８の主要な目的が長期間の記憶ではないことを意味する。記憶デバイス５０８は、いくつかの実施例では、揮発性メモリとして記載され、コンピュータの電源が切れると、記憶デバイス５０８は記憶したコンテンツを維持しないことを意味する。揮発性メモリの実施例には、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、及び当該技術分野で既知であるその他の形態の揮発性メモリを含む。いくつかの実施例では、記憶デバイス５０８は、プロセッサ５０２によって実施するプログラム命令を記憶するように使用される。記憶デバイス５０８は、一実施例では、プログラム実行中一時的に情報を記憶するように、コンピュータデバイス５００上で動作されるソフトウェア又はアプリケーションによって使用される。
【０２５６】
また記憶デバイス５０８は、いくつかの実施例では、一つ以上のコンピュータで読み取り可能な記憶媒体を含む。記憶デバイス５０８は、揮発性メモリよりも大きい情報量を記憶するように構成されてもよい。記憶デバイス５０８はさらに、長期間情報を記憶するように構成されてもよい。いくつかの実施例では、記憶デバイス５０８は不揮発性記憶要素を含む。当該不揮発性記憶要素の実施例には、磁気ハードディスク、光ディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、又は電気的にプログラム可能なメモリ（ＥＰＲＯＭ）若しくは電気的に消去及びプログラム可能なメモリ（ＥＥＰＲＯＭ）の形態を含む。
【０２５７】
コンピュータデバイス５００も、いくつかの実施例では、一つ以上の通信部５０６を含む。コンピュータデバイス５００は、一実施例では、一つ以上の有線／無線／モバイルネットワークなど、一つ以上のネットワークを介して外部デバイスと通信するように、通信部５０６を利用する。通信部５０６は、イーサネット（登録商標）カードなどのネットワークインタフェースカード、光送受信機、無線周波数送受信機、又は情報を送受信できる、いかなる他の種類のデバイスを含んでもよい。当該ネットワークインタフェースの一実施例には、３Ｇ及びＷｉＦｉ無線を含んでもよい。いくつかの実施例では、コンピュータデバイス５００は、外部デバイスと通信するように、通信部５０６を使用する。
【０２５８】
コンピュータデバイス５００も、一実施例では、一つ以上のユーザインタフェースデバイス５１０を含む。ユーザインタフェースデバイス５１０は、いくつかの実施例では、触覚、音声、又はビデオによるフィードバックによって、ユーザからの入力を受信するように構成される。ユーザインタフェースデバイス５１０の実施例には、存在を感知するディスプレイ、マウス、キーボード、声に反応するシステム、ビデオカメラ、マイク、又はユーザからのコマンドを発見する、いかなる他の種類のデバイスを含む。いくつかの実施例では、存在を感知するディスプレイはタッチスクリーンを含む。
【０２５９】
また、一つ以上の出力デバイス５１２も、コンピュータデバイス５００の中に含まれてもよい。出力デバイス５１２は、いくつかの実施例では、触覚、音声、又はビデオによる刺激を使用して、ユーザへの出力を提供するように構成される。出力デバイス５１２は、一実施例では、存在を感知するディスプレイ、サウンドカード、ビデオグラフィックスアダプタカード、又は人若しくはマシンが理解可能である適切な形態に信号を変換する、いかなる他の種類のデバイスを含む。出力デバイス５１２のさらなる実施例には、スピーカ、陰極管（ＣＲＴ）モニタ、液晶ディスプレイ（ＬＣＤ）、又はユーザへの分かりやすい出力を生成できる、いかなる他の種類のデバイスを含む。
【０２６０】
コンピュータデバイス５００は、オペレーティングシステム５１６を含んでもよい。オペレーティングシステム５１６は、いくつかの実施例では、コンピュータデバイス５００の構成要素の動作を制御する。例えば、一実施例では、オペレーティングシステム５１６によって、一つ以上のアプリケーション５２２と、プロセッサ５０２、通信部５０６、記憶デバイス５０８、入力デバイス５０４、ユーザインタフェースデバイス５１０、及び出力デバイス５１２を伴う相互接続プラットフォームアプリケーション５２４との通信が促進される。
【０２６１】
また、アプリケーション５２２及び相互接続プラットフォームアプリケーション５２４は、コンピュータデバイス５００によって実行可能なプログラム命令及び／又はデータを含んでもよい。コンピュータデバイス５００によって実行可能な例示の相互接続プラットフォームアプリケーション５２４は、オーケストレーションエンジンモジュール５５０、ＡＰＩゲートウェイモジュール５５２、及びサブシステム５５４のうちのいずれか一つ以上を含んでもよく、各々は、これらがコンピュータデバイス５００のいかなる所与の実施例によって実行可能であってもよく、又は実行可能でなくてもよいことを示す点線で示される。
【０２６２】
オーケストレーションエンジンモジュール５５０は、コンピュータデバイスに、オーケストレーションエンジン１１８及びオーケストレーションエンジン４０７に関して本開示に記載する、動作及び操作のうちの一つ以上を実施させる命令を含んでもよい。一実施例として、オーケストレーションエンジンモジュール５５０は、ネットワークインフラ内の相互接続及びクラウドサービス管理の様々な態様を管理する、クラウドエクスチェンジ用の相互接続プラットフォームの、基になるソフトウェアサブシステムを、コンピュータデバイス５００に構築、運営、及び統合させる命令含んでもよい。例えば、オーケストレーションエンジンモジュール５５０は、ＡＰＩと、サブシステム及びネットワークインフラを含むクラウドエクスチェンジの、基になる相互接続プラットフォームとの間で動作する、ルール駆動のワークフローエンジンを提供してもよい。
【０２６３】
ＡＰＩゲートウェイモジュール５５２は、コンピュータデバイスに、ＡＰＩゲートウェイ１１２及びＡＰＩゲートウェイ４０３に関して本開示に記載する、動作及び操作のうちの一つ以上を実施させる命令を含んでもよい。一実施例として、ＡＰＩゲートウェイモジュール４０３は、例えば、ＡＰＩ１１４といった、方法、フィールド、及び／又はアプリケーションが相互接続プラットフォームを呼び出すのに利用してもよい、その他のソフトウェア基本要素を定義する、ソフトウェアインタフェースの一群を、コンピュータデバイス５００に公開させる命令を含んでもよい。これらのソフトウェアインタフェースによって、回線事業者及び顧客は、クラウドエクスチェンジの機能及び資産へのプログラム可能なアクセスが可能になる。
【０２６４】
サブシステム５５４は、コンピュータデバイスに、サブシステム１２０に関して本開示に記載する、動作及び操作のうちの一つ以上を実施させる命令を含んでもよい。
【０２６５】
図１３は、さらに詳細に、オーケストレーションエンジン７０４の例示の論理アーキテクチャを示す、例示のクラウドエクスチェンジシステム７００を示すブロック図である。オーケストレーションエンジン７０４は、例えば、オーケストレーションエンジン１１８（図１Ａ〜１Ｃ及び図２）、オーケストレーションエンジン４０７（図３Ａ〜３Ｂ、図４〜５、図７〜１１）、及びコンピュータデバイス５００のオーケストレーションエンジンモジュール５５０（図１２）のうちのいずれかを表してもよい。
【０２６６】
オーケストレーションエンジン７０４は、企業とクラウドサービスプロバイダとの間など、買い手と売り手との間の仮想接続（例えば、仮想回路）を含む相互接続資産をシームレスに設定するように、全体の相互接続プラットフォーム（例えば、図１Ｂ、１Ｃの相互接続プラットフォーム１０３）の一部として動作する。図１３の実施例では、オーケストレーションエンジン７０４は、クラウドエクスチェンジシステム７００によって提供される、オーケストレータ７０６及びマイクロサービス７０８という、二つの主要構成要素を含む。オーケストレーションエンジン７０４はまた、サービス検出エンジン７１０及びプロセス管理ツール７１２を含む。オーケストレーションエンジン７０４は、集中型又は分散型アプリケーションを表してもよく、一つまたは複数の仮想マシン及び／又はデータセンター１０１の現実のサーバ（図１Ａ）など、管理デバイス上で実行されてもよい。
【０２６７】
マイクロサービス７０８は各々、焦点を合わせた個別の特徴及び機能の１組を実装し、マイクロサービスは、多くの何十又はさらに何百ものマイクロサービスを独立して開発及び配備できる、アーキテクチャのパターンに準拠する（又はアーキテクチャのパターンで使用可能である）。マイクロサービス７０８は、ビジネス機能（例えば、ＡＰＩドックのエンジン７２６、ＲＥＳＴインタフェース７２８、ソケット接続７３０、監視７３２、及び通知７３４）を中心に構築されてもよく、永続的記憶部及びいかなる外部協業を含む、ビジネス機能向けソフトウェアの「幅広い積み重ね」を実装してもよい。様々なマイクロサービス７０８は、マイクロサービス７０８が、全体のアプリケーションを作成するために、データを交換してそれぞれの機能の組を実施するように、互いを呼び出すことを可能にする、インタフェースを公開する。いくつかの実施例では、マイクロサービス７０８は、例えば、クラウドエクスチェンジサービス４０９、ＡＰＩクエリサービス４２２Ａ、ＡＰＩコマンドサービス４２２Ｂ、統合ファサードサービス４２２Ｃ、サブシステム１２０によって提供されるいかなるマイクロサービス、及びマイクロサービス３０８Ｄを実装するマイクロサービスといった、本開示に記載するその他のマイクロサービスの実施例を表してもよく又は含んでもよい。
【０２６８】
マイクロサービス７０８の各々は、明確に定義されたアプリケーションプログラミングインタフェース（ＡＰＩ）を忠実に守ってもよく、マイクロサービス７０８のＡＰＩを呼び出すことによって、オーケストレータ７０６により実施されるワークフローに従って調整されてもよい。オーケストレータ７０６の構成要素は、オーケストレータ７０６によって公開され（例えば、ＡＰＩゲートウェイ１１２、４０３、及び７１８など、ＡＰＩサーバ／ゲートウェイを介して）、それぞれのＡＰＩコントラクトに準拠するＡＰＩ要求によって呼び出し可能な、様々なＡＰＩに対して定義されるルール又はワークフローに基づいて、マイクロサービス７０６を「調整する」。オーケストレータ７０６は、例えば、ポータル、モバイルアプリケーション、又は開発者ＡＰＩのいずれかといった、ＡＰＩコンシューマへの各外部チャネルに対する完全にカスタマイズされたＡＰＩコントラクトを可能にする、確立された１組のルール又はワークフローに従うことによって、ＡＰＩ要求を一般的に処理してもよい。ワークフローは、いくつかの実施例においてはステートマシンとして実装されてもよい。各チャネルに対する要求／応答のコントラクトが可変であるため、本開示に記載するオーケストレータ７０６は、異なるチャネルにわたって差異に対する平等な支援を受け入れ提供してもよい。
【０２６９】
オーケストレーションエンジン７０４は、クラウドエクスチェンジに対する相互接続の様々な態様を管理する、基になるソフトウェア及びネットワークサブシステムを管理、運営及び統合する。オーケストレーションエンジン７０４のオーケストレータ７０６は、例えば、ＡＰＩとエクスチェンジの基になる相互接続プラットフォームとの間で動作する、ルール駆動型のワークフローエンジンを実行してもよい。例えば、オーケストレータ７０６は、ポリシー３０８Aに従って動作する、図２のワークフロー及びルールエンジン３０６に相当してもよい。このように、オーケストレーションエンジン７０４は、クラウドエクスチェンジの相互接続プラットフォーム内で直接参加するために、顧客専用のアプリケーション及びＡＰＩによって使用できる。
【０２７０】
本明細書に記載する通り、オーケストレーションエンジン７０４は、顧客アプリケーションが行う動的要求に対して、インテリジェントな次のステップ及び応答を組み立てるように、相互接続プラットフォームの基になるサブシステムからの情報及び操作を合成する。そのため、オーケストレーションエンジン７０４は、相互接続プラットフォームにアクセスする均一で簡易化された安全な手段を提供することによって、クラウドエクスチェンジの基になるソフトウェア及びネットワークサブシステムの複雑さを取り除く。
【０２７１】
図１３の実施例では、クラウドエクスチェンジシステム７００は、ウェブプロキシ７１４、ＳａａＳウェブポータル７１６、及びＡＰＩゲートウェイ７１８を含む、クラウドエクスチェンジシステム７００によって提供されるクラウドエクスチェンジの機能性へのアクセスを可能にする、複数のプラットフォームを提供する。オーケストレーションエンジン７０４は、要求が、クラウドエクスチェンジポータル７１３、クラウドエクスチェンジプロバイダによって開発されるが顧客の名前が付けられるホワイトラベルポータル７１５、及びＡＰＩ７１７を介してなされたか否かに関わらず、これらのプラットフォームから入ってくる全ての要求にサービスを提供する。例えば、ウェブプロキシ７１４、ＳａａＳウェブポータル７１６及びウェブプロキシ７１４、ＳａａＳウェブポータル７１６、並びにＡＰＩゲートウェイ７１８は、オーケストレータ７０６にアクセスする要求に対する異なるチャネルを表す。例えば、顧客は、ポータル７１３にログインして、相互接続プラットフォームのサービスにアクセスするために、ウェブアプリケーションを使用してもよい。別の実施例として、顧客又は開発者は、クラウドエクスチェンジのデータにアクセスするために、ＡＰＩを使用してもよい。オーケストレーションエンジン７０４は、ウェブプロキシ７１４を介してクラウドエクスチェンジポータル７１３を使用して入ってくる要求を受信できる。オーケストレーションエンジン７０４は、ＳａａＳウェブポータル７１６を介してホワイトラベルポータル７１５を使用して入ってくる要求を受信できる。オーケストレーションエンジン７０４は、例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、又はその他のネットワークプロトコルなど、ネットワークプロトコルを使用して、ＳａａＳウェブポータル７１６（例えば、ＣＳＰポータル）と通信してもよい。オーケストレーションエンジン７０４は、ＡＰＩゲートウェイ７１８を介してＡＰＩ７１７を使用して入ってくる要求を受信できる。ＡＰＩゲートウェイ７１８は、本明細書に記載するＡＰＩゲートウェイのいずれを表してもよく、ＡＰＩ７１７を介して受信する要求をどちらにルーティングするかについてサービスインスタンスを識別するために、サービス検出エンジン７１０を使用する。
【０２７２】
上に簡潔に記載する通り、マイクロサービス７０８は、ビジネス機能を中心に整理される、より小さなサービス（マイクロサービス）に分けられるクラウドエクスチェンジ機能を表す。マイクロサービス７０８は、永続的記憶部、及び第三者システム７２４などとのいかなる外部協業を含む、そのビジネス領域に対して幅広く積み重ねたソフトウェアの実装を実行してもよい。
【０２７３】
オーケストレータ７０６は、ウェブプロキシ７１４、ポータル７１６、又はＡＰＩゲートウェイ７１８から要求を受信し、要求にサービスを提供するように、マイクロサービス７０８のうちの複数のマイクロサービスをシームレスに連携させる。例えば、受信した要求に基づいて、オーケストレータ７０６は、要求にサービスを提供する必要のあるマイクロサービスを自動的に呼ぶ、ワークフローを判定してもよい。例えば、ＡＰＩゲートウェイ７１８が入力を渡し、オーケストレーションエンジン７０４が、入力の処理を行い、複数のマイクロサービス７０８を呼び、ＡＰＩが必要とするコントラクトを満たす必要のあるデータを取得して、ＡＰＩが必要とするデータを含め、ＡＰＩに応答を送信する。例えば、仮想回路を作成するために、オーケストレータ７０６は複数のマイクロサービスのエンドポイントを必要とする。例えば、オーケストレータ７０６は、大都市、ポート、及び支払請求情報を必要とする。これらは全て、本明細書に記載する通り、オーケストレータ７０６を通してシームレスに調整される、個々の内部ＡＰＩである。要求／応答動作で、（例えば）ＡＰＩは大都市のマイクロサービスを呼び出し、オーケストレーションエンジンは、管理された大都市のルーチン（ワークフロー）を呼び出し、その大都市のルーチンに関する要求を遂行するように、マイクロサービスによって必要なサービスを実施し、動作に関連するいかなるデータをも送信し返す。オーケストレーションエンジン７０４は、マイクロサービスのうちの一つから、クラウドサービスプロバイダのコネクタを呼び出してもよい。このように、オーケストレーションエンジン７０４は、顧客の要求にサービスを提供するために、オーケストレータ７０６が選択するワークフローに従って呼び出されている個々のマイクロサービスの基になる詳細を顧客に気付かせないように、途切れのなく顧客が要求するサービス又はデータを提供する。
【０２７４】
いくつかの実施例では、マイクロサービス７０８は、クラウドサービスプロバイダによって開発及び提供されるマイクロサービスを表してもよい。すなわち、オーケストレータ７０６は、マイクロサービスのうちの一つによってアクセス可能なクラウドサービスプロバイダのインタフェースを呼び出してもよい。例えば、Ａｚｕｒｅ（Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎが提供）は、クラウドサービスを提供し、クラウドサービスを管理するために開発されたマイクロサービス７０８のうちの一つがアクセス可能なインタフェースを公開してもよい。オーケストレータ７０６は、Ａｚｕｒｅが提供するマイクロサービスに対するＲＥＳＴｆｕｌインタフェース（本明細書の別の場所に記載する「ＣＳＰのＡＰＩ」の一実施例）を呼び、機能性のうちのいくつかを遂行することができる。例えば、クラウドエクスチェンジのアプリケーションからクラウドサービスプロバイダへの仮想接続を作成するために、オーケストレーションエンジン７０４は、Ａｚｕｒｅが提供するマイクロサービスを呼び出して、ポートを使用可能にするなど、機能のうちのいくつかを実施してもよい。Ａｚｕｒｅが提供するマイクロサービスを呼び出した後、オーケストレータは、全体のワークフローを実装するように、その他のマイクロサービスを呼び出してもよい。例えば、その後オーケストレータは、注文、検証、及び／又は認証マイクロサービスを呼び出してもよい。ＲＥＳＴｆｕｌ  ＡＰＩエンドポイント／チャネルは、マイクロサービスへのアクセスのしやすさを提供してもよい。
【０２７５】
図１３の実施例では、マイクロサービス７０８は、内部ＡＰＩドキュメントエンジンＡＰＩ７２６（「ＡＰＩ  Ｄｏｃエンジン」）、ＲＥＳＴインタフェースマイクロサービス７２８、ソケット接続マイクロサービス７３０、監視マイクロサービス７３２、通知マイクロサービス７３４、及びＡＰＩサービスフレームワーク７２２を含む。オーケストレーションエンジン７０４はまた、マイクロサービス７０８のうちの一つ以上を呼び出すとき、ＡＰＩを介して様々な内部システム又は第三者システムと相互作用するように、内部ＡＰＩサービスフレームワーク７２２を使用する。マイクロサービス７０８は、オーケストレータ７０６に対するＡＰＩインタフェースを表し、ＡＰＩサービスフレームワーク７２２において実行されてもよい。ＡＰＩ７２１Ａ〜７２１Ｃ（「ＡＰＩ７２１」）は、オーケストレーションエンジン７０４のマイクロサービス層の構成要素によって呼ばれてもよく、マイクロサービスのエンドポイントとみなされてもよい。ＡＰＩ７２１は顧客に対面するＡＰＩではない。
【０２７６】
図１３の実施例では、オーケストレーションエンジン７０４は、プライベートＡＰＩ７２１Ａを介して企業システム７２０と相互作用するように、ＡＰＩサービスフレームワーク７２２を使用する。オーケストレーションエンジン７０４は、プライベートＡＰＩ７２１Ｂを介してその他のシステム７２３と相互作用するように、ＡＰＩサービスフレームワーク７２２を使用する。オーケストレーションエンジン７０４は、パブリックＡＰＩ７２１Ｃを介して第三者システムと相互作用し、クラウドベースのサービスプラットフォームをクラウドエクスチェンジに統合するように、ＡＰＩサービスフレームワーク７２２を使用する。
【０２７７】
図１４は、さらに詳細に、オーケストレーションエンジン７０４に対する参照アーキテクチャを示す、例示のシステム８００を示すブロック図である。オーケストレーションエンジン７０４は、例えば、オーケストレーションエンジン１１８（図１Ａ〜１Ｃ及び図２）、オーケストレーションエンジン４０７（図３Ａ〜３Ｂ、図４〜５、図７〜１１）、コンピュータデバイス５００のオーケストレーションエンジンモジュール５５０（図１２）、及び図１３のオーケストレーションエンジン７０４のうちのいずれかを表してもよい。一実施例として、システム８００は、図１３のクラウドエクスチェンジシステム７００の異なる論理的な考え方を表してもよい。
【０２７８】
オーケストレーションエンジン７０４は、企業８４０とクラウドサービスプロバイダ８４２との間など、買い手と売り手との間の仮想接続（例えば、仮想回路）を含む相互接続資産をシームレスに設定するように、全体の相互接続プラットフォーム（例えば、図１Ｂ、１Ｃの相互接続プラットフォーム１０３）の一部として動作する。例えば、オーケストレーションエンジン７０４は、図１Ｃの顧客システム１９６間の仮想回路１５０、１５５、１６０、１６５、１７０をシームレスに設定してもよい。
【０２７９】
オーケストレーションエンジン７０４は、集中型又は分散型アプリケーションを表してもよく、一つまたは複数の仮想マシン及び／又はデータセンター１０１の現実のサーバ（図１Ａ）など、管理デバイス上で実行されてもよい。オーケストレーションエンジン７０４は、様々な顧客システムから相互接続資産の要求を受信してもよい。例えば、オーケストレーションエンジン７０４は、内部管理者（すなわち、オーケストレーションエンジン７０４と同じエンティティに属する管理者）（「ａｄｍｉｎ」）、ネットワークサービスプロバイダ（ＮＳＰ）、クラウドサービスプロバイダ（ＣＳＰ）８４２、企業８４０、及び開発者から要求を受信してもよい。オーケストレーションエンジン８０４は、ブラウザ８１２Ａを介してウェブプロキシ８１０で、ブラウザ８１２Ｂを介してホワイトラベルＳａａＳ８１４で、又はＡＰＩ８１８を介してＡＰＩゲートウェイ８１６で要求を受信してもよい。
【０２８０】
オーケストレータ８０６は、例えば、ポートの管理、大都市の管理、ＣＳＰ詳細、注文管理、仮想回路の閲覧、仮想回路の削除、検索、支援及びチケット、監視及び統計、分析及び推奨のような機能を実施するワークフローを管理できる。オーケストレータ８０６はまた、オーケストレーションエンジン４０７に関して上に記載する機能を含む、図示しないさらなる機能を実施できる。いくつかの実施例では、オーケストレータ８０６は、オーケストレータが、上で言及するチャネルのうちのいずれかを介する要求の受信に応じて、好適なワークフローを選択及びロードできる、ワークフローのライブラリを維持してもよい。
【０２８１】
いくつかの実施例では、オーケストレーションエンジン７０４は、サーバネットワークのデバイス上で実行される１組の仮想マシンとして動作されてもよい。オーケストレーションエンジン７０４は、Ｎｏｄｅ．ｊｓなどのソフトウェアアプリケーションプラットフォーム上で構築され動作してもよい。マイクロサービスは、ウェブアプリケーションフレームワークを使用して使用可能になってもよい。マイクロサービス及びワークフローは、ソフトウェアコンテナにおける分散型アプリケーションとして構築され動作してもよい。オーケストレーションエンジン７０４は、インメモリの永続的ディスクデータベースを使用して、インメモリのグリッドキャッシュを使用してもよい。
【０２８２】
オーケストレーションエンジン７０４の態様は、Ｎｏｄｅ．ｊｓ上、又は例えば、イベント駆動型アーキテクチャと、リアルタイムのウェブアプリケーションに対してアプリケーションのスループット及びスケーラビリティを最適化するように設計される、ノンブロッキングI／O  ＡＰＩとを提供するその他の類似のプラットフォーム上で構築されてもよい。Ｎｏｄｅ．ｊｓは、例えば、Ｎｏｄｅ．ｊｓに組み込まれている、ＨＴＴＰ及びＪＳＯＮを使用して通信する、緩やかに結合された拡張可能なシステムを促進する、軽量なオープンソースのプラットフォームである。これによって、マイクロサービス７０８を作成及び配備する、マイクロサービスの設計原理が容易になってもよい。
【０２８３】
オーケストレータ７０６は、ＡＰＩコントラクトを満たすよう、定義された順序で複数のマイクロサービス７０６を呼び出すワークフローを実装するように、ステートマシンを使用してもよい。マイクロサービス７０６（及びマイクロサービス７０６の各々の複数のインスタンス）は、統合されたテスト、ロギング、監視、及び診断戦略で品質及び信頼性の強化を提供しながらも、分離性及びモジュール性のために別個のコンテナの中に配備されてもよい。コンテナ技術は、計算リソースの巨大なプールにわたって、何単位もの作業を配備するための機構であり、スケーラビリティのための極めて重要な配備戦略となっている。マイクロサービス及びコンテナによって、拡張可能なシステム構築への技術的手法の収束が提供される。Ｎｏｄｅ．ｊｓは、高度に拡張可能で軽量な非同期の通信プロセスを構築し、ＡＰＩをいかなるウェブコンシューマにも公開するために最適化される、オープンソースのプラットフォームである。オーケストレーションエンジン７０４は、クラウドベースのサービス交換に対するマイクロサービスベースの相互接続プラットフォームとして実装及び配備するために、Ｎｏｄｅ．ｊｓ、マイクロサービス、及びコンテナを利用してもよい。
【０２８４】
オーケストレーションエンジン７０４はまた、例えば、エラーフレームワーク、ロギング、管理、通知、監査、及び監視を含む、ユーティリティ機能８１９を呼ぶための機能性を含む。ユーティリティ機能８１９は、アプリケーションをダウンタイムなしで動作したままにし、プロセス監視、プロセスログの監視、メモリ管理、及び同種のものを実施する、プロセス管理ツールを含んでもよい。
【０２８５】
図１４はまた、例えば、仮想回路、ポート、リンク集約グループ（ＬＡＧ）、大都市、ＣＳＰ詳細、サービス品質（ＱｏＳ）、顧客サービス及びチケット発行、検索（例えば、ＣＳＰ、ＮＳＰ、場所、ポート、仮想回路）、資産及びネットワークインベントリ、言語、並びにサービス設定を含む、オーケストレーションエンジン７０４の複数の内部マイクロサービス７０８を示す。マイクロサービス７０８は、個々の内部ＡＰＩ（すなわち、オーケストレーションエンジン７０６の内部にあり、例えば、ＡＰＩ８１８を介して公開されてはいない）又はマイクロサービスのエンドポイントを表す。いくつかの実施例では、マイクロサービス７０８は、図２のマイクロサービス３０８Ｄに相当してもよい。例えば、マイクロサービス７０８の「大都市」の内部ＡＰＩは、オーケストレーションエンジン７０４の内部にある大都市の動作に対する、マイクロサービスのインタフェースに相当する。ＡＰＩコンシューマ４０２（図３Ａ）のうちの一人などのＡＰＩコンシューマは、ＡＰＩ１１４のうちの顧客に対面する大都市ＡＰＩ４０６Ｃ（図３Ａ）を介して、大都市を要求してもよく、オーケストレータ７０６は、顧客に対面する大都市ＡＰＩ４０６Ｃから内部の大都市マイクロサービス８０６に変換するであろう。オーケストレータ７０６は、顧客に対面する大都市ＡＰＩ動作を満たすために必要とされる、個々のマイクロサービスを束ねるワークフローを選択できる。
【０２８６】
オーケストレーションエンジン７０４はまた、例えば、手動によるプロビジョニング／プロビジョニング解除、注文スケジューラ、注文状態更新ツール、稼働率統計、クラウドサービスプロバイダの場所検出を含む、非同期ジョブ８１７を呼ぶ機能性を含む。オーケストレータ７０６は、非同期でこれらのジョブを呼んでもよい。
【０２８７】
オーケストレーションエンジン７０４は、例えば、コンテンツ管理システム８２０Ａ、トラフィック管理システム８２０Ｂ、インシデント管理システム８２０Ｃ、ポート管理システム８２０Ｄ、ＩＤ及びアクセス管理システム８２０Ｅ、並びに注文管理システム８２０Ｆなど、様々なサブシステム８２０Ａ〜８２０Ｆ（「サブシステム８２０」）と結び付くことができる。サブシステム８２０は、例えば、図１Ｂ、図１Ｃ、図２、及び図４のサブシステム１２０に相当してもよい。例えば、コンテンツ管理システム８２０Ａは、ＳａａＳウェブポータル７１６など、ウェブアプリケーションポータルを介して配信されてもよいコンテンツと関連するデータを含む。例えば、トラフィック管理システム８２０Ｂは、ポートレベル又は仮想回路レベルでなど、内部クラウドエクスチェンジプラットフォームのトラフィックにトラフィックに関係するデータを提供する。一実施例では、オーケストレータ７０６が、支援及びチケットに関係する機能を提供するようにワークフローを選択するとき、オーケストレータ７０６は、選択したワークフローに従って、インシデント管理システム８２０Ｃなど、サブシステム８２０のうちの一つと結び付くように、マイクロサービス７０８のうちの一つ（例えば、顧客サービス及びチケット発行マイクロサービス）を使用する。マイクロサービスは、サブシステム８２０と結び付くように、データベースに接続してもよく、ＲＥＳＴ  ＡＰＩを使用して接続してもよく、ＪＳＯＮの呼び出しを使用して接続してもよく、又はその他の機構を使用して接続してもよい。
【０２８８】
いくつかの実施例では、サブシステム８２０は、オーケストレーションエンジン１１８によって調整されるサービスタスクを適用してもよく、例えば、ＣＳＰ８４２と企業８４０との間に仮想回路のオンデマンド設定を実施するように、又は、そうでなければ、ポート、大都市、データセンター、仮想回路及び仮想回路帯域幅、プロファイル、並びに構成など、クラウドエクスチェンジの相互接続資産を管理するように、クラウドエクスチェンジポイント１２８のうちのいずれをも修正することを含んでもよい。
【０２８９】
オーケストレーションエンジン７０４は、クラウドベースのサービス交換のネットワークインフラ用の一つ以上のＳＤＮコントローラ８３２と結び付くことができる。ＳＤＮコントローラ８３２は、図１のデータセンター１０１など、クラウドエクスチェンジプラットフォームのデータセンター内に存在してもよい。ＳＤＮコントローラ８３２を、クラウドエクスチェンジネットワークのインフラ内のＡ地点からＢ地点の間のスイッチを接続するように使用してもよい。クラウドベースのサービス交換という状況でＳＤＮコントローラを調整する技術は、２０１５年５月２１日出願の米国特許仮出願番号第６２／１６４，９６５号「Active Panel Demarcation」、及び２０１５年９月１０日出願の米国特許仮出願番号第６２／２１６，８０４号「Automated Fiber Cross-connect Service within a Multi-tenant Interconnection Facility」にさらに詳細に記載され、各々は参照により全て本発明に援用される。
【０２９０】
図１５は、本開示の例示的態様に従い、オーケストレーションエンジンによって実施される例示のワークフローを示すフローチャートである。例示のため、図１５には、図１３及び図１４のオーケストレーションエンジン７０４に関して記載するが、本明細書に記載するオーケストレーションエンジンのその他の実施例に同じく適用されてもよい。
【０２９１】
オーケストレーションエンジン７０４は、クラウドエクスチェンジポータル８１４又はＡＰＩゲートウェイ８１６を介するなどにより、クラウドエクスチェンジプラットフォームサービスのクライアント要求を受信する（１５００）。オーケストレーションエンジン７０４は、クラウドエクスチェンジプラットフォームサービスへのクライアント要求を、オーケストレータ７０６に送信する（１５０２）。クライアント要求に基づいて、オーケストレータ７０６は、ワークフローライブラリ又はフォルダ（例えば、ワークフローＷＦ１、ＷＦ２、ＷＦ３、及びＷＦ４を含む図１６のワークフローフォルダ１６１２）よりワークフローを選択し、選択されたワークフローは、マイクロサービスの呼び出しによって要求を遂行するのに必要な１組のタスクを包含する（１５０４）。例えば、オーケストレータ７０６は、構成されるルール若しくはポリシー（例えば、図２のポリシー３０８Ａ）に基づいて、及び／又はクライアントと関連するプロファイル（例えば、図２のプロファイル３０８Ｂ）に基づいてワークフローを選択してもよい。オーケストレータ７０６は、選択したワークフローを自動的にロードするであろうし、マイクロサービスはワークフローに従って（例えば、連続して及び／又は並行して）実行される（１５０６）。ワークフローフォルダ１６１２は、各顧客のエンドポイントに対して（例えば、クラウドエクスチェンジ開発者によって）事前に定義されていたワークフローを包含する。例えば、大都市の顧客エンドポイントに対して定義された第１のワークフロー、及びポートの顧客エンドポイントに対して定義された第２のワークフローがあってもよい。ワークフローは、要求を遂行するために一つの状態から別の状態にどのように移行するかを示すガイドとして、一つ以上のステートマシンを使用する１組の論理を提供する。ワークフローは、タスクのオーケストレーションを定義する。ワークフローは、ポータル及びＡＰＩのような異なる要求チャネルを介して受信される要求を満たすように、一続きの複雑な動作を、ステートマシン内にあり、マイクロサービスによって実行される、一連の個別タスクにまで分解する手段を提供する。各要求は、異なる関連ドメインコントラクトを有することができる。所与の要求に対して、オーケストレータ７０６は、要求と関連するドメインコントラクトを満たすように、ステートマシン内で一連の個別タスクを使用するワークフローを選択する。
【０２９２】
その後マイクロサービスは、それぞれの応答をオーケストレータ７０６に返送する（１５０８）。応答は、マイクロサービスによって提供されるデータを含んでもよい。オーケストレータ７０６は、クライアント要求を遂行するのに必要な通り、ワークフローの各々からの応答で受信されるデータを連結する（１５１０）。それからオーケストレーションエンジン７０４は、クラウドエクスチェンジサービスのクライアント要求に応答する（１５１２）。
【０２９３】
このような関係において、マイクロサービスはエンドポイントであり、タスクは要求を遂行するために現在実行されている操作である。一つの例示的タスクは、まとめて１組のマイクロサービス（エンドポイント）を呼ぶことであり得る。一つの特定のエンドポイントを呼ぶと、あるデータが返送され、それはチェーンにおいて、次のエンドポイントによって使用されるデータであってもよい。このように、ワークフローは、完了すべきタスクのチェーンを定義してもよく、一つのタスクにおいて取得されるデータは、次のタスクで使用されてもよく、及び／又は次のタスクを判定してもよい。
【０２９４】
一実施例として、クラウドエクスチェンジの顧客は、クラウドエクスチェンジプラットフォームを介して、複数の異なるクラウドサービスプロバイダに接続することを欲してもよい。この状況において、オーケストレータ７０６は複数のＡＰＩを呼ぶ必要がある。別の実施例では、クラウドサービスプロバイダは、新しい顧客へのガイド用のテンプレートを作成し、テンプレートをオーケストレータに提供することができ、オーケストレータは、クラウドサービスプロバイダと接続したい新しい顧客へのガイド用のテンプレートを容易に使用できる。オーケストレータ７０６はいかなる種類のワークフローを調整でき、二人以上の顧客がワークフローを使用できる。同じワークフローが、顧客が必要とする機能性（例えば、仮想回路の作成）を実行するために、異なる顧客によって使用できる。様々な例示のワークフローを、図５〜１１及び図１６〜１７に関して示し記載する。
【０２９５】
図１６は、仮想回路の作成に関係する例示のオーケストレーションエンジンのワークフローを示す、例示の論理図である。本実施例では、オーケストレータ７０６は、「/virtual circuit」のＡＰＩエンドポイントを呼び出し、オーケストレータ７０６によって公開されるクライアント要求１６２２を受信して、クライアントとクラウドサービスプロバイダとの間のクラウドベースのサービス交換で仮想回路をプロビジョニングする。オーケストレータ７０６は、仮想回路をプロビジョニングするワークフローを、ワークフローフォルダ１６１２より選択し、選択したワークフローをロードし、データ構造記憶部１６１０に新しいジョブを押し出す。またオーケストレータ７０６は、ジョブの状態に関する出版‐購読型サーバ１６２０に加入する。
【０２９６】
ワークフローは１組のタスクを指定する。例えば、仮想回路をプロビジョニングするワークフローは、（ｉ）ポートの詳細を取得、（ｉｉ）大都市の詳細を取得、並びに（ｉｉｉ）ポートの詳細及び大都市の詳細に基づいて、仮想回路を作成、を備える１組のタスクを指定する。オーケストレータ７０６は、タスクを実施するように、マイクロサービス１６３０Ａ〜１６３０Ｄ（エンドポイント）のうちの一つ以上にアクセスする、複数のワークフロー実行ツール１６１６Ａ〜１６１６Ｄにわたって、１組のタスクの中からタスクを配信できる。ワークフロー実行ツール１６１６は、データ構造記憶部１６１０によって維持されるキューからジョブを選んでもよい。いくつかの実施例では、選択されたワークフローの各タスクは、異なるスレッド上で実行されてもよい。タスクは、平行して又は連続して実行されてもよい。各タスクが終了すると、出版‐購読型サーバ１６２０が更新されて、出版‐購読型サーバ１６２０がオーケストレータ７０６に通知する。例えば、「Ｊｏｂ  Ｆｉｎｉｓｈｅｄ（ジョブの終了）」は、ワークフローの実行が終了すると呼ばれる方法である。オーケストレータ７０６は、仮想回路が確立されたと判定すると、例えば、ＨＴＴＰ応答を返送することによって、要求を行ったクライアントに通知してもよい。
【０２９７】
いくつかの場合では、ワークフローにおける一連のタスクは、一続きで実施されるタスクのみよりも複雑であってもよい。タスクは失敗し得るため、オーケストレータ７０６は時々、タイムアウト、リトライ、「停止した（ｓｔｕｃｋ）」流れなどを扱う必要があってもよい。ワークフロー及びそのタスクを定義する一つの手段は、任意の複雑さの言語を使用することである。別の手段には、以下のようないくつかの前提を伴ってもよい。（１）コードは定義言語である。（２）タスクは独立し、異なるワークフローの中に使用できる。（３）タスク間で通信する唯一の手段はワークフローである。タスクは、ワークフローの特性を追加、除去、又は修正できる。（４）タスクは、ワークフローの特定の性質が存在することを必要とする場合、タスクを失敗とする、又はワークフロー内でタスク自体のスケジュールを変更することができる。システムは、失敗を考慮して設計されなくてはならない。タスクは失敗し得るため、結果として、ワークフローが失敗してもよい。オーケストレータ７０６は、タスクの失敗又はワークフロー全体の失敗から回復する必要があってもよい。いくつかの実施例では、オーケストレータ７０６は、マイクロサービスが適切に応答しない又はエラーメッセージを返送するため、第１のタスクが失敗するときに使用するように、代替のマイクロサービスを検出する、サービス検出エンジン７１０（図１３）を使用する。
【０２９８】
例えば、オーケストレータ７０６が、クラウドエクスチェンジサービスを提供するために実行する必要がある、五つのマイクロサービスのタスクがある場合、オーケストレーションエンジン７０４のプロセス管理ツール７１２は、並行して又は連続してタスクを実行することを決定できる。オーケストレータ７０６は、特定のマイクロサービスが適切に応答していない、又はマイクロサービスがエラーメッセージを返送すると判定する場合、マイクロサービスを再び実行するか否か、又はオーケストレータ７０６が代わりに使用できる、いかなる他の予備のマイクロサービスがあるか否かを判定する。オーケストレータ７０８は、代替のマイクロサービス（例えば、異なるユニフォームリソースロケータ（ＵＲＬ）を有する）を検出するように、サービス検出エンジン７１０（図１３）を使用する。
【０２９９】
オーケストレータ７０６は、マイクロサービスに対する第１のＵＲＬを呼んでもよいが、そのマイクロサービスはエラーコードを返送する。オーケストレータ７０６は、代替のマイクロサービス（例えば、異なるユニフォームリソースロケータ（ＵＲＬ）を有する）を検出すべきであるか否かを判定するように、サービス検出エンジン７１０を使用する。例えば、オーケストレータ７０６は、ポートのマイクロサービスを実施する、異なるポートのアプリケーションに対するインタフェースである、複数の異なるＵＲＬを含む、ポートのマイクロサービスを呼び出してもよい。
【０３００】
図１７は、従業員の給与情報取得に関係する例示のオーケストレーションエンジンのワークフローを示す、例示の論理図である。本実施例では、オーケストレータ７０６は、従業員の給与情報を取得するように、オーケストレータ７０６によって公開され、「/employee payroll」のＡＰＩのエンドポイントを呼び出すクライアント要求１６４２を受信する。オーケストレータ７０６は、ワークフローフォルダ１６１２から従業員の給与情報を取得し、選択したワークフローをロードし、データ構造記憶部１６１０に新しいジョブを押し出すワークフローを選択する。またオーケストレータ７０６は、ジョブの状態に関する出版‐購読型サーバ１６２０に加入する。
【０３０１】
ワークフローは１組のタスクを指定する。例えば、従業員の給与情報を取得するワークフローは、（ｉ）ユーザの詳細を取得、（ｉｉ）ユーザの詳細に基づいて、ユーザの給与の詳細を取得、を備える、１組のタスクを指定する。オーケストレータ７０６は、タスクを実施するように、マイクロサービス１６５０Ａ〜１６５０Ｄ（エンドポイント）のうちの一つ以上にアクセスする、複数のワークフロー実行ツール１６１６Ａ〜１６１６Ｄにわたって、１組のタスクの中からタスクを配信できる。図１７の実施例のワークフロー実行ツール１６１６Ａ〜１６１６Ｄによってアクセスされるマイクロサービス１６５０Ａ〜１６５０Ｄは、図１６の実施例のマイクロサービス１６３０Ａ〜１６３０Ｄとは異なるマイクロサービスであってもよい。ワークフロー実行ツール１６１６は、データ構造記憶部１６１０によって維持されるキューからジョブを選んでもよい。いくつかの実施例では、選択されたワークフローの各タスクは、異なるスレッド上で実行されてもよい。タスクは、平行して又は連続して実行されてもよい。各タスクが終了すると、出版‐購読型サーバ１６２０が更新されて、出版‐購読型サーバ１６２０がオーケストレータ７０６に通知する。例えば、「Ｊｏｂ  Ｆｉｎｉｓｈｅｄ（ジョブの終了）」は、ワークフローの実行が終了すると呼ばれる方法である。オーケストレータ７０６は、従業員の給与情報が取得されたと判定すると、例えば、ＨＴＴＰ応答を返送することによって、要求を行ったクライアントに通知してもよい。
【０３０２】
図１８Ａ〜１８Ｂは、本開示に記載する技術に従い、クラウドエクスチェンジプロバイダの顧客に対するプロビジョニングのために、複数のクラウドサービスプロバイダのクラウドサービスを集約し、一つ以上のクラウドサービスプロバイダへの複数の顧客のアクセスを集約する、クラウドエクスチェンジ用の相互接続プラットフォームによる、例示のネットワークインフラ及びサービスプロビジョニングを示すブロック図である。本実施例では、各々が異なる顧客と関連する、顧客ネットワーク１８０８Ａ〜１８０８Ｃ（総称して「顧客ネットワーク１８０８」）は、各々が異なるクラウドサービスプロバイダ１１０と関連する、一つ以上のクラウドサービスプロバイダネットワーク１８２０から、集約されるクラウドサービスを受信するために、データセンター１８００内のクラウドエクスチェンジポイントにアクセスする。顧客ネットワーク１８０８は各々、クラウドサービスプロバイダネットワーク１８２０によって提供されるクラウドサービスを購入する、エンドポイントのデバイスを含む。例示のエンドポイントのデバイスは、サーバ、スマートフォン、テレビのセットトップボックス、ワークステーション、ノートパソコン／タブレットコンピュータ、テレビゲームシステム、テレビ会議システム、メディアプレーヤーなどを含む。
【０３０３】
顧客ネットワーク１８０８Ａ〜１８０８Ｂは、それぞれのプロバイダエッジ／自律システムの境界ルータ（ＰＥ／ＡＳＢＲ）１８１０Ａ〜１８１０Ｂを含む。ＰＥ／ＡＳＢＲ１８１０Ａ、１８１０Ｂの各々は、アクセスリンク１８１６Ａ〜１８１６Ｂ（総称して「アクセスリンク１８１６」）のうちの一つにわたって、ＰＥルータ１８０２Ａ〜１８０２Ｂ（「ＰＥルータ１８０２」又はより単純に「ＰＥ１８０２」）のうちの一つとピアリングするように、外部ゲートウェイのルーティングプロトコルを実行してもよい。示す実施例では、アクセスリンク１８１６の各々は、顧客ネットワーク１８０８のエッジルータと、クラウドエクスチェンジポイント１８０３のエッジルータ（又は自律システムの境界ルータ）との間のトランジットリンクを表す。例えば、ＰＥ１８１０Ａ及びＰＥ１８０２Ａは、アクセスリンク１８１６Ａ上のＬ３ルートを交換し、かつ顧客ネットワーク１８０８Ａとクラウドサービスプロバイダネットワーク１８２０との間のＬ３データトラフィックを交換するように、例えば、外部ＢＧＰといった外部ゲートウェイプロトコルによって直接ピアリングしてもよい。アクセスリンク１８１６は、いくつかの場合には、以下にさらに詳細に記載する通り、ＩＰ／ＭＰＬＳファブリック１８０１において構成されるＩＰ‐ＶＰＮ用の連結回路を表してもよく、代替として、連結回路と称してもよい。アクセスリンク１８１６は各々、顧客ネットワーク１８０８の少なくとも一つのポートと、クラウドエクスチェンジポイント１８０３の少なくとも一つのポートとの間の、トランジットネットワークが介在しない直接的な物理的接続を含んでもよい。アクセスリンク１８１６は、ＶＬＡＮ若しくは積層されたＶＬＡＮ（例えば、ＱｉｎＱ）、ＶｘＬＡＮ、ＬＳＰ、ＧＲＥトンネル、又はその他の種類のトンネル上で動作してもよい。
【０３０４】
Ｌ３の接続性に関して示し、主に記載しているものの、ＰＥルータ１８０２は、アクセスリンク１８１６を介して、顧客ネットワーク１８０８とクラウドサービスプロバイダネットワーク１８２０との間に、Ｌ２の接続性を追加として提供してもよい。例えば、ＰＥルータ１８０２Ａのポートは、顧客ネットワーク１８０８Ａに、アクセスリンク１８１６Ａを介するクラウドサービスプロバイダ１８２０ＡへのＬ２の接続性を提供する、Ｌ２のサブインタフェースで構成されてもよい。ＰＥルータ１８０２Ａのポートは、顧客ネットワーク１８０８Ａに、アクセスリンク１８１６Ａを介するクラウドサービスプロバイダ１８２０ＢへのＬ３の接続性を提供する、Ｌ３のインタフェースで追加として構成されてもよい。
【０３０５】
アクセスリンク１８１６及び集約リンク１８２２の各々は、顧客ネットワーク１８０８又はクラウドサービスプロバイダ１８２８を、ネットワークインタフェースデバイス（ＮＩＤ）と、ＰＥルータ１８０２、１８０４のうちの一つとの間のネットワークリンクに接続するＮＩＤを含んでもよい。アクセスリンク１８１６及び集約リンク１８２２の各々は、Ｌ３／ネットワークの接続性を提供する、いくつかの異なるタイプのリンクのうちのいずれかを表してもよく、又は含んでもよい。
【０３０６】
本実施例では、顧客ネットワーク１８０８Ｃは、自律システム番号を有する自律システムではない。顧客ネットワーク１８０８Ｃは、企業、ネットワークサービスプロバイダ、又はクラウドエクスチェンジポイントのルーティングの範囲内にある、その他の顧客ネットワークを表してもよい。顧客ネットワークは、アクセスリンク１８１６Ｃ上でＰＥルータ１８０２Ｂとピアリングするように、外部ゲートウェイのルーティングプロトコルを実行してもよい、顧客のエッジ（ＣＥ）デバイス１８１１を含む。様々な実施例では、ＰＥ１８１０Ａ〜１８１０Ｂのうちのいずれも、代替としてＣＥデバイスであってもよく、そうでなければＣＥデバイスを表してもよい。
【０３０７】
アクセスリンク１８１６は物理的なリンクを含む。ＰＥ／ＡＳＢＲ１８１０Ａ〜１８１０Ｂ、ＣＥデバイス１８１１、及びＰＥルータ１８０２Ａ〜１８０２Ｂは、アクセスリンク１８１６を介して、Ｌ２／Ｌ３パケットを交換する。この点において、アクセスリンク１８１６は、クラウドエクスチェンジポイント１８０３を介するクラウドアクセス用の伝送リンクを構成する。クラウドエクスチェンジポイント１８０３は、クラウドエクスチェンジポイント１２８のうちのいずれの実施例を表してもよい。データセンター１８００は、データセンター２０１の実施例を表してもよい。
【０３０８】
クラウドエクスチェンジポイント１８０３は、いくつかの実施例では、クラウドエクスチェンジポイント１８０３、及びそこからいかなる一つ以上のクラウドサービスプロバイダ１８２０への顧客１８０８のアクセスを集約する。図１８Ａ〜１８Ｂは、例えば、それぞれの顧客ネットワーク１８０８Ａ〜１８０８Ｂをクラウドエクスチェンジポイント１８０３のＰＥルータ１８０２Ａに接続するアクセスリンク１８１６Ａ〜１８１６Ｂと、顧客ネットワーク１８０８ＣをＰＥルータ１８０２Ｂに接続するアクセスリンク１８１６Ｃとを示す。ＰＥルータ１８０２、１８０４のうちのいかなる一つ以上が、ＡＳＢＲを備えてもよい。ＰＥルータ１８０２、１８０４及びＩＰ／ＭＰＬＳファブリック１８０１は、アクセスリンク１８１６のうちのいずれかを、クラウド集約リンク１８２２のうちのいずれかに相互接続するように、本明細書に記載する技術に従って構成されてもよい。結果として、クラウドサービスプロバイダネットワーク１８２０Ａは、例えば、サービスを複数の顧客ネットワーク１８０８に提供するために、単一のクラウド集約リンク（ここでは、アクセスリンク１８２２Ａ）を構成しておく必要のみがあった。すなわち、クラウドサービスプロバイダネットワーク１８０２Ａを操作するクラウドサービスプロバイダは、例えば、顧客ネットワーク１８０８の各々にサービスを提供するために、クラウドサービスプロバイダネットワーク１８０２Ａから、ＰＥルータ１８１０、１８１１の各々への別個のサービスリンクをプロビジョニングし構成する必要はない。クラウドエクスチェンジポイント１８０３は、代わりに、レイヤ３のピアリング及びクラウドサービスのデリバリに対するネットワーク到達可能性を提供するように、クラウドサービスプロバイダネットワーク１８２０Ａのクラウド集約リンク１８２２Ａ及びＰＥ１８１２Ａを、複数のクラウドアクセスリンク１８１６に交差接続してもよい。
【０３０９】
加えて、単一の顧客ネットワーク、例えば、顧客ネットワーク１８０８Ａは、クラウドサービスを提供する複数のクラウドサービスプロバイダネットワーク１８２０から、クラウドエクスチェンジポイント１８０３を介してサービスを取得するために、データセンター１８００内でクラウドエクスチェンジポイント１８０３への単一のクラウドアクセスリンク（ここでは、アクセスリンク１８１６Ａ）を構成しておく必要のみがある。すなわち、顧客又は顧客ネットワーク１８０８Ａを操作するネットワークサービスプロバイダは、例えば、複数のクラウドサービスプロバイダネットワーク１８２０からサービスを取得するために、顧客ネットワーク１８０８Ａを異なるＰＥルータ１８１２に接続する、別個のサービスリンクをプロビジョニングし構成する必要はない。クラウドエクスチェンジポイント１８０３は、代わりに、レイヤ３のピアリングと、顧客ネットワーク１８０８Ａへのクラウドサービスのデリバリに対するネットワーク到達可能性とを提供するように、クラウドアクセスリンク１８１６Ａ（再び、一実施例として）を、複数のクラウド集約リンク１８２２に交差接続してもよい。
【０３１０】
クラウドサービスプロバイダネットワーク１８２０は各々、一つ以上のクラウドサービスをユーザに提供するように構成されるサーバを含む。これらのサービスは、サービスタイプに従って分類されてもよく、例えば、アプリケーション／ソフトウェア、プラットフォーム、インフラ、仮想化、並びにサーバ及びデータ記憶部を含んでもよい。例示のクラウドサービスは、コンテンツ／メディアのデリバリ、クラウドベースの記憶部、クラウドコンピューティング、オンラインゲーム、ITサービスなどを含んでもよい。
【０３１１】
クラウドサービスプロバイダネットワーク１８２０は、クラウドエクスチェンジポイント１８０３のＰＥルータ１８０４Ａ〜１８０４Ｂ（総称して「ＰＥルータ１８０４」）とルートを交換するように、外部ゲートウェイのルーティングプロトコル、例えば、ｅＢＧＰを各々実行する、ＰＥルータ１８１２Ａ〜１８１２Ｄを含む。クラウドサービスプロバイダネットワーク１８２０の各々は、パブリッククラウド、プライベートクラウド、又はハイブリッドクラウドを表してもよい。クラウドサービスプロバイダネットワーク１８２０の各々は、付与される自律システム番号を有してもよく、又はクラウドエクスチェンジポイント１８０３の自律システムの範囲の一部であってもよい。
【０３１２】
示す実施例では、インターネットプロトコル／マルチプロトコルラベルスイッチング（ＩＰ／ＭＰＬＳ）ファブリック１８０１は、ＰＥ１８０２及びＰＥ１８０４を相互接続する。ＩＰ／ＭＰＬＳファブリック１８０１は、ＩＰバックボーンを形成するように、ＩＰパケットのＩＰ／ＭＰＬＳスイッチング及びルーティングを提供し、ＰＥ１８０２、１８０４を含む、一つ以上のスイッチング及びルーティングデバイスを含む。いくつかの実施例では、ＩＰ／ＭＰＬＳファブリック１８０１は、ＰＥルータ間のトラフィックをルーティングし、及び／又はトラフィックを異なるＩＰ‐ＶＰＮと関連付けるように、一つ以上の異なるトンネリングプロトコル（すなわち、ＭＰＬＳ以外）を実装してもよい。本明細書に記載する技術に従い、ＩＰ／ＭＰＬＳファブリック１８０１は、データセンターをベースとする「伝送」及びレイヤ３の交差接続を提供するように、顧客１８０８のうちのいずれかを、複数のクラウドサービスプロバイダネットワーク１８２０に接続する、ＩＰ仮想プライベートネットワーク（ＩＰ‐ＶＰＮ）を実装する。サービスプロバイダをベースとするＩＰバックボーンネットワークが、レイヤ３のサービスプロバイダから顧客へサービストラフィックを伝送するように、限定された帯域幅での広域ネットワーク（ＷＡＮ）接続を必要とするのに対して、本明細書に記載する通りのクラウドエクスチェンジポイント１８０３は、サービストラフィックを「伝送」し、データセンターをベースとするＩＰ／ＭＰＬＳファブリック１８０１によって提供されるデータセンター１８００の高帯域幅の構内環境内で、クラウドサービスプロバイダ１８２０を顧客１８０８に交差接続する。いくつかの実施例では、ＩＰ／ＭＰＬＳファブリック１８０１は、２００６年２月、Internet Engineering Task Force (IETF) Network Working Group発行、Rosen & Rekhterの「BGP/MPLS IP Virtual Private Networks (VPNs)」、Request for Comments 4364に記載される技術を使用してＩＰ‐ＶＰＮを実装し、その内容は、参照により全て本発明に援用される。いくつかの例示的構成において、顧客ネットワーク１８０８及びクラウドサービスプロバイダネットワーク１８２０は、それぞれのリンクを介して、ＩＰ／ＭＰＬＳファブリック１８０１の同じＰＥルータに接続してもよい。
【０３１３】
アクセスリンク１８１６及び集約リンク１８２２は、接続された顧客ネットワーク１８０８又はクラウドサービスプロバイダネットワーク１８２０と交換するトラフィックを、ＰＥ１８０２、１８０４において構成され、ＩＰ／ＭＰＬＳファブリック１８０１上で動作するＩＰ‐ＶＰＮに相当する、仮想ルーティング及び転送インスタンス（ＶＲＦ）と関連付ける、連結回路を含んでもよい。例えば、ＰＥ１８０２Ａは、アクセスリンク１８１６Ａ上を動作する双方向のラベルスイッチパス（ＬＳＰ）上のＰＥ１８１０Ａと、ＩＰパケットを交換してもよく、ＬＳＰは、ＰＥ１８０２Ａに構成されるＶＲＦ用の連結回路である。別の実施例として、ＰＥ１８０４Ａは、アクセスリンク１８２２Ａ上を動作する双方向のラベルスイッチパス（ＬＳＰ）上のＰＥ１８１２Ａと、ＩＰパケットを交換してもよく、ＬＳＰは、ＰＥ１８０４Ａに構成されるＶＲＦ用の連結回路である。各ＶＲＦは、個別のルートによる異なるルーティング及び転送テーブルを含んでもよいか、又は表してもよい。
【０３１４】
ＩＰ／ＭＰＬＳファブリック１８０１のＰＥルータ１８０２、１８０４は、クラウドサービス向けにそれぞれのハブアンドスポーク型の配置で構成されてもよく、ＰＥ１８０４はクラウドサービスハブを実装し、ＰＥ１８０２はハブのスポークとして構成される（様々なハブアンドスポーク型のインスタンス／配置のため）。ハブアンドスポーク型の配置によって、サービストラフィックが、直接異なるスポークＰＥ間ではなく、ハブＰＥと、スポークＰＥのいずれかとの間を流れることが可能となることを保証する。さらに下に記載する通り、データセンターをベースとするＩＰ／ＭＰＬＳファブリック１８０１用及びサウスバウンドのサービストラフィック（すなわち、ＣＳＰから顧客へ）用のハブアンドスポーク型の配置において、ＰＥ１８０２は、ＰＥ１８１０から受信されるルートをＰＥ１８０４に公示し、それによってＰＥ１８１２にルートを公示する。ノースバウンドのサービストラフィック（すなわち、顧客からＣＳＰへ）に対しては、ＰＥ１８０４は、ＰＥ１８１２から受信されるルートをＰＥ１８０２に公示し、それによってＰＥ１８１０にルートを公示する。
【０３１５】
クラウドエクスチェンジポイント１８０３の幾人かの顧客に対して、クラウドエクスチェンジポイント１８０３のプロバイダは、フルメッシュの配置を構成してもよく、それによって、１組のＰＥ１８０２、１８０４の各々が、顧客用の異なる顧客のサイトネットワークに結合する。そのような場合には、ＩＰ／ＭＰＬＳファブリック１８０１は、ラックからラック又は冗長なトラフィック（東西又は水平トラフィックとしても知られる）に対して、レイヤ３のＶＰＮ（Ｌ３ＶＰＮ）を実装する。Ｌ３ＶＰＮは、閉じられたユーザグループを有効化してもよく、それによって、各顧客サイトネットワークは、トラフィックを互いに送信できるが、Ｌ３ＶＰＮの外側ではトラフィックを送受信できない。
【０３１６】
ＰＥルータは、オーバーレイネットワークを使用せずに、ピアモデルに従って互いに結合してもよい。すなわち、ＰＥ１８１０及びＰＥ１８１２は、ルートを交換するために互いに直接ピアリングするのではなく、むしろＩＰ／ＭＰＬＳファブリック１８０１を介して間接的にルートを交換してもよい。図１８Ｂの実施例において、クラウドエクスチェンジポイント１８０３は、顧客ネットワーク１８０８及びクラウドサービスプロバイダネットワーク１８２２を、エンドツーエンドのＩＰ経路と相互接続させるように、複数のレイヤ３の仮想回路１８３０Ａ〜１８３０Ｃ（総称して「仮想回路１８３０」）を実装するように構成される。クラウドサービスプロバイダ１８２０及び顧客１８０８の各々は、複数の仮想回路１８３０のエンドポイントであってもよく、複数の仮想回路１８３０は、ＩＰ／ＭＰＬＳファブリック１８０１のＰＥ／ＰＥ又はＰＥ／ＣＥの１対と、ＣＳＰ／顧客との間に一つ以上の連結回路を横断させる。仮想回路１８３０は、顧客ネットワークをファブリック１８０１に接続する連結回路と、クラウドサービスプロバイダネットワークをファブリック１８０１に接続する連結回路との間で、ＩＰ／ＭＰＬＳファブリック１８０１を介するレイヤ３経路を表す。各仮想回路１８３０は、ＰＥ１８０２、１８０４にエンドポイントを有する、少なくとも一つのトンネル（例えば、ＬＳＰ及び／又は総称ルーティングカプセル化（ＧＲＥ）トンネル）を含んでもよい。ＰＥ１８０２、１８０４は、互いに相互接続するフルメッシュ型トンネルを確立してもよい。
【０３１７】
各仮想回路１８３０は、フルメッシュ型又は一部メッシュ型の境界ゲートウェイプロトコルのピアリングセッション、本実施例の場合には、フルメッシュ型のマルチプロトコル内部境界ゲートウェイプロトコル（ＭＰ‐ｉＢＧＰ）のピアリングセッションを使用して、ルートを交換するＰＥルータ１８０２、１８０４を有する、ＩＰ／ＭＰＬＳネットワーク１８０１に構成される、異なるハブアンドスポーク型のネットワークを含んでもよい。ＭＰ‐ｉＢＧＰ又は単純にＭＰ‐ＢＧＰは、ルータが、ＭＰＬＳベースのＶＰＮを実装するようにラベル付きルートを交換する、プロトコルの一実施例である。しかしながら、ＰＥ１８０２、１８０４は、その他の技術及び／又はプロトコルを使用してＩＰ‐ＶＰＮを実装するように、ルートを交換してもよい。
【０３１８】
仮想回路１８３０Ａの実施例では、クラウドサービスプロバイダネットワーク１８２０ＡのＰＥルータ１８１２Ａは、ＰＥ１８０４Ａでのルーティングプロトコル（例えば、ｅＢＧＰ）のピアリング接続によって、クラウドサービスプロバイダネットワーク１８２０Ａ用のルートを、ＰＥ１８０４Ａに送信してもよい。ＰＥ１８０４Ａは、関連するＶＲＦを有してもよく、スポークＰＥルータ１８０２Ａを含む、ハブアンドスポーク型のネットワークに、ルートを関連付ける。その後ＰＥ１８０４Ａは、ルートをＰＥルータ１８０２Ａにエクスポートするため、ＰＥルータ１８０４Ａは、ハブアンドスポーク型のネットワークを識別するラベルと共に、ＰＥルータ１８０４Ａを次のホップルータとして指定するルートを、エクスポートしてもよい。ＰＥルータ１８０２Ａは、ＰＥ１８１０Ｂでのルーティングプロトコルによる接続によって、ＰＥルータ１８１０Ｂにルートを送信する。ＰＥルータ１８０２Ａは、クラウドエクスチェンジポイント１８０３の（例えば、ＢＧＰ自律システム経路（ＡＳ＿ＰＡＴＨ）属性に対する）自律システム番号を追加し、ＰＥルータ１８０２Ａを次のホップルータとして指定した後に、ルートを送信してもよい。それゆえ、クラウドエクスチェンジポイント１８０３が、データセンター内をベースとしてもよいものの、クラウドエクスチェンジポイント１８０３は、顧客１８０８からクラウドサービスプロバイダ１８２０（逆の場合も同様）への自律システムの経路における、自律システムの「ホップ」である。ＰＥルータ１８１０Ｂは、クラウドサービスプロバイダネットワーク１８２０Ａへのレイヤ３での到達可能性を提供する、ＢＧＰルーティング情報ベース（ＲＩＢ）など、ルーティングデータベースへのルートを設ける。このように、直接的な層でのピアリング接続を必要とする、顧客ネットワーク１８０８へのクラウドサービスプロバイダネットワーク１８２０がない場合には、クラウドエクスチェンジポイント１８０３は、クラウドサービスプロバイダネットワーク１８２０から顧客ネットワーク１８０８へのルートを「漏洩する」。
【０３１９】
ＰＥルータ１８１０Ｂ、１８０２Ａ、１８０４Ａ、及び１８１２Ａは、顧客ネットワーク１８０８Ｂによって創出されるルートを、ＰＥ１８１２Ａに転送するのと反対の方向で類似の動作を実施することで、クラウドサービスプロバイダネットワーク１８２０Ａから顧客ネットワーク１８０８Ｂへの接続性を提供してもよい。仮想回路１８３０Ｂの実施例では、ＰＥルータ１８１２Ｂ、１８０４Ａ、１８０２Ａ、及び１８１０Ｂは、仮想回路１８３０Ｂを確立するための上に記載したものと類似する方式で、顧客ネットワーク１８０８Ｂ及びクラウドサービスプロバイダ１８２０Ｂ用のルートを交換する。結果として、データセンター１８００内のクラウドエクスチェンジポイント１８０３は、異なるクラウドサービスプロバイダネットワーク１８２０Ａ、１８２０Ｂによって提供される複数のレイヤ３のクラウドサービスに対して、クラウド集約を実施し、クラウドエクスチェンジポイント１８０３への単一のアクセスリンク１８１６Ｂを有する顧客ネットワーク１８０８Ｂに、複数の集約されたレイヤ３のクラウドサービスを送達するために、他の場合には、ＰＥ１８１０ＢとＰＥ１８１２Ａ、１８１２Ｂの各々との間に確立されるであろう、ピアリング接続を内在化する。本明細書に記載する技術がなければ、完全に相互接続する顧客ネットワーク１８０８及びクラウドサービスプロバイダネットワーク１８２０は、クラウドサービスプロバイダネットワーク１８２０の各々に対して、ＰＥ１８１０の各々と、ＰＥ１８１２のうちの少なくとも一つとの間に、３×３ピアリング接続を必要とするであろう。例えば、ＰＥ１８１０Ａは、ＰＥ１８１２の各々を伴うレイヤ３のピアリング接続を必要とするであろう。本明細書に記載する技術によって、クラウドエクスチェンジポイント１８０３は、レイヤ３のピアリングを内在化し、クラウドアクセスとクラウド集約インタフェースとの間で、データセンターをベースとする「伝送」を提供することによって、顧客ネットワーク１８０８及びクラウドサービスプロバイダネットワーク１８２０を、サイトのＰＥごとに（すなわち、ＰＥ１８１０及びＰＥ１８１２の各々に対して）一つのピアリング接続で完全に相互接続してもよい。
【０３２０】
ＩＰ／ＭＰＬＳファブリック１８０１が、ＢＧＰ／ＭＰＬＳのＩＰ‐ＶＰＮ、又はＩＰバックボーン内でのルート配信を制御するように、ルートターゲットを使用する、その他のＩＰ‐ＶＰＮを実装する実施例において、ＰＥ１８０４は、異なる非対称のルートターゲットを使用して、ＰＥ１８０２からルートをインポートし、ＰＥ１８１２から受信したルートをエクスポートするように構成されてもよい。同様に、ＰＥ１８０２は、非対称のルートターゲットを使用して、ＰＥ１８０４からルートをインポートし、ＰＥ１８１０から受信したルートをエクスポートするように構成されてもよい。したがって、ＰＥ１８０２、１８０４は、顧客ネットワーク１８０８のうちのいずれかのエクストラネットと、基本バックボーンＬ３ＶＰＮに連結する、クラウドサービスプロバイダネットワーク１８２０のうちのいずれかと共に、ＩＰ／ＭＰＬＳファブリック１８０１の基本バックボーンＬ３ＶＰＮを各々含む、先進的なＬ３ＶＰＮを実装するように構成されてもよい。各先進的なＬ３ＶＰＮは、クラウドサービスプロバイダネットワーク１８２０から一つ以上の顧客ネットワーク１８０８、及びその反対の方向のクラウドサービスのデリバリネットワークを構成する。このように、クラウドエクスチェンジポイント１８０３によって、何対かの顧客ネットワーク１８０８と、所与の一対の間のいかなるクラウドサービス接続用のクラウドサービスプロバイダネットワーク１８２０との間に、他の場合であれば確立されるであろう、レイヤ３ルーティングプロトコルのピアリング接続を内在化しながら、クラウドサービスプロバイダネットワーク１８２０が、クラウドサービストラフィックを、いかなる顧客ネットワーク１８０８とも交換することを可能にする。言い換えると、クラウドエクスチェンジポイント１８０３によって、顧客ネットワーク１８０８及びクラウドサービスプロバイダネットワーク１８２０の各々が、データセンターをベースとするレイヤ３の交差接続への、単一の（又は冗長性若しくはその他の理由のために一つ以上の）レイヤ３ルーティングプロトコルのピアリング接続を確立することを可能にする。クラウドサービスプロバイダネットワーク１８２０から顧客ネットワーク１８０８へ及びその反対の方向のルートをフィルタリングすることによって、ＰＥ１８０２、１８０４は、仮想回路１８３０の確立、及び顧客ネットワーク１８０８とデータセンター１８００内のクラウドサービスプロバイダネットワーク１８２０との間の関連するクラウドサービストラフィックの流れを、それによって制御する。ＭＰ‐ｉＢＧＰメッシュ１８３に配信されるルートは、ＶＰＮ-ＩＰv４ルートであり、重複するアドレス空間を有する異なるサイトよりルートを区別する、ルート識別子と関連付けられてもよい。
【０３２１】
相互接続プラットフォーム１０３は、クラウドエクスチェンジポイント１８０３のエンドツーエンドサービスを作成、読み取り、更新、及び／又は削除するサービス要求を受信してもよい。それに応じて、相互接続プラットフォーム１０３は、ＰＥ１８０２、１８０４、及び／又はＩＰ／ＭＰＬＳファブリック１８０１のその他のネットワークインフラを、サービスに関する性能又はその他の動作情報をプロビジョニング又は取得するように構成してもよい。サービスをプロビジョニングし、相互接続プラットフォーム１０３によって実施される動作は、ＶＲＦを構成若しくは更新し、ＳＤＮの転送情報を組み込み、ＬＳＰ又はその他のトンネルを構成し、ＢＧＰを構成し、アクセスリンク１８１６及び集約リンク１８２２を構成し、又はそうでなければＩＰ／ＭＰＬＳファブリック１８０１の構成を修正することを含んでもよい。以下にさらに詳細に記載する通り、その他の動作は、クラウドサービスプロバイダネットワーク１８２０用のオーケストレーションシステムにサービス要求を行うことを含んでもよい。
【０３２２】
図１９は、本明細書に記載する技術に従い、クラウドエクスチェンジポイントのルータが、複数のクラウドサービスプロバイダネットワークから顧客ネットワークへ集約されたサービストラフィックをルーティング及び転送するために、ＶＰＮのルーティング及び転送インスタンスを用いて、相互接続プラットフォーム１０３によって構成される、データセンターをベースとするクラウドエクスチェンジポイントの実施例を示すブロック図である。本実施例では、仮想回路１８３０Ａ〜１８３０Ｂを確立するために、ＩＰ／ＭＰＬＳファブリック１８０１のＰＥルータ１８０２Ａ及び１８０４Ａは、ＶＲＦで構成される。ＰＥ１８０２Ａは、ＶＲＦ１９０２Ａ及び１９０４Ａで構成される一方、ＰＥ１８０４Ａは、ＶＲＦ１９０２Ｂ及び１９０４Ｂで構成される。ＶＲＦ１９０２Ａは、ＶＲＦ１９０２Ｂによってエクスポートされるルートをインポートするように構成され、ＶＲＦ１９０２Ｂは、ＶＲＦ１９０２Ａによってエクスポートされるルートをインポートするように構成される。構成は、ＶＲＦ１９０２ＡとＶＲＦ１９０２Ｂとの間のインポート／エクスポート用の非対称のルートターゲットを含んでもよい。ＶＲＦ１９０４Ａは、ＶＲＦ１９０２Ｂによってエクスポートされるルートをインポートするように構成され、ＶＲＦ１９０２Ｂは、ＶＲＦ１９０２Ａによってエクスポートされるルートをインポートするように構成される。構成は、ＶＲＦ１９０２ＡとＶＲＦ１９０２Ｂとの間のインポート／エクスポート用の非対称のルートターゲットを含んでもよい。
【０３２３】
本実施例では、ＰＥ１８０４Ａは、それぞれのクラウドサービスプロバイダネットワーク１８２０Ａ、１８２０Ｂとルートを交換するように、ＢＧＰ、又はそれぞれのＰＥ１８１２Ａ、１８１２Ｂを伴う、その他のルート配信プロトコルのピアリング接続１９０６Ｂ、１９０８Ｂを操作する。ＰＥ１８０２Ａは、顧客ネットワーク１８０８Ｂとルートを交換するように、ＢＧＰ、又はＰＥ１８１０Ｂを伴う、その他のルート配信プロトコルのピアリング接続４１０を操作する。いくつかの実施例では、ＰＥ１８０２Ａ、１８０４Ａは、サイトネットワーク用のルートで静的に構成されてもよい。
【０３２４】
クラウドエクスチェンジポイント１８０３に対する、本明細書に記載する管理者又は相互接続プラットフォームは、データセンターをベースとする接続性又は少なくとも大都市をベースとする接続性を発展させることによって、エンドツーエンドのＩＰ経路を潜在的に最適化しながら、ＰＥ１８１２とＰＥ１８１０Ｂとの間のルートを漏えいし、仮想回路１８３０によって図中に示すエンドツーエンドのＩＰ経路に対するレイヤ３の接続性を促進するために、ＰＥ１８０２Ａ、１８０４ＡをＶＲＦ１９０２Ａ〜１９０２Ｂ、１９０４Ａ〜１９０４Ｂで構成してもよい。したがって、クラウドエクスチェンジポイント１８０３は、クラウドサービスプロバイダネットワーク１８２０のプライベート及び／又はパブリックルートを経由する、顧客ネットワーク１８０８Ｂへのクラウドサービスプロバイダ専用アクセスを提供してもよい。ノースバウンド方向では、クラウドエクスチェンジポイント１８０３は、顧客ネットワーク１８０８のプライベート及び／又はパブリックルートを経由する、複数の顧客ネットワーク１８０８へのクラウドサービスプロバイダ専用配信を提供してもよい。ＰＥ１８１０ＢもＰＥ１８０２Ａ、１８０４Ａのうちのいずれも、クラウドサービスプロバイダネットワーク１８２０又は顧客ネットワーク１８０８に到達するために、完全なインターネットのＢＧＰルーティングテーブルにアクセスする必要はない。その上、ＰＥ１８０２Ａ、１８０４Ａは、物理的なＩＰ、サービス、及びＶＲＦのうちのいかなる一つ以上に基づいて、顧客／ＣＳＰのルート及び／又はサービストラフィックを集約するように構成されてもよい。
【０３２５】
図２０は、本開示に記載する技術に従う、開発フレームワークの設計手法と、開発フレームワークを使用することによって実現されてもよい利益とを示す概念図である。開発フレームワークによって、ドメイン駆動型設計を施行し、テスト駆動型開発を可能にする、マイクロサービスをベースとするアプリケーションのアーキテクチャが容易になる。また開発フレームワークによって、開発者が最初にマイクロサービス用のＡＰＩ定義を作成／改良し、開発フレームワークがソフトウェアサービスインフラのスキャフォールディングを生成する、「ＡＰＩコントラクトを第１」とする手法が容易になる。その後開発者は、ビジネス論理をインフラに具現化することによって、マイクロサービスを実装してもよい。
【０３２６】
さらにまた、この開発フレームワークは、モジュール式設計手法を促進し、最高のコード生成のプラクティスを使用して、「定型」コードを生成する。開発フレームワークは、開発者によって最初に指定されるＡＰＩコントラクトの定義に基づいて、偽者及びスタブの述語を生成することによってなど、相互に作用するスキャフォールディングに対する、エンドツーエンドのＡＰＩ生成を促進する。いくつかの実施例では、開発フレームワークは、ｎｏｄｅｓｅｃｕｒｉｔｙ．ｉｏを使用して、一つ以上のモジュールを監査する。
【０３２７】
開発フレームワークの態様は、Ｎｏｄｅ．ｊｓ上、又は例えば、イベント駆動型アーキテクチャと、リアルタイムのウェブアプリケーションに対してアプリケーションのスループット及びスケーラビリティを最適化するように設計される、ノンブロッキングI／OのＡＰＩとを提供する、その他の類似のプラットフォーム上で構築されてもよい。Ｎｏｄｅ．ｊｓは、例えば、Ｎｏｄｅ．ｊｓに組み込まれている、ＨＴＴＰ及びＪＳＯＮを使用して通信する、緩やかに結合された拡張可能なシステムを促進する、軽量なオープンソースのプラットフォームである。これによって、マイクロサービスの設計原理が容易になってもよい。ウェブアプリケーションのフレームワークについて、開発フレームワークは、いくつかの実施例では、Ｅｘｐｒｅｓｓ．ｊｓの冒頭及び既存のノード／自身で作成したモジュール上で構築されてもよい。
【０３２８】
オーケストレータは、ＡＰＩコントラクトを満たすよう、定義された順序で複数のマイクロサービスを呼び出すワークフローを実装するように、ステートマシンを利用してもよい。開発フレームワークは、Ｗａｔｅｒｌｉｎｅ及び／若しくはＰｅｒｓｉｓｔのオブジェクト関係マッピング（ＯＲＭ）、又はデータベースの相互作用のためのその他のＯＲＭフレームワークを使用してもよい。開発フレームワークは、スキャフォールディングのその他の態様に伴って生成される、統合されたロギングの特徴を提供してもよい。開発フレームワークは、スキャフォールディングのその他の態様に伴って、統合された監視及びユニット、並びに統合テストモジュールを提供してもよい。
【０３２９】
開発フレームワークは、「ｃｌｏｕｄ−ｉｎ−ａ−ｂｏｘ（箱に入ったクラウド）」開発環境を提供するように、迅速で拡張可能な配備及び実行時間の開発／テストを促進してもよい。開発フレームワークは、統合されたテスト、ロギング、監視、及び診断戦略で強化された品質及び信頼性を提供しながらも、分離性及びモジュール性のために別個のコンテナに各マイクロサービスを配備してもよい。また開発フレームワークは、動的及び／又は静的なクロスオリジンリソース共有（ＣＯＲＳ）を促進してもよい。
【０３３０】
コンテナ技術は、計算リソースの巨大なプールにわたって、何単位もの作業を配備するための機構であり、スケーラビリティのための極めて重要な配備戦略となっている。インターネットにアクセスするデバイスが激増し、それらが焦点を狭く絞り、独立して配備可能で、維持するのが容易で、かつ拡張可能であることに一部起因して、マイクロサービスが主要なアーキテクチャパターンになりつつある。マイクロサービス及びコンテナによって、拡張可能なシステム構築への技術手法の収束が提供される。Ｎｏｄｅ．ｊｓは、高度に拡張可能で軽量な非同期の通信プロセスを構築し、ＡＰＩをいかなるウェブコンシューマにも公開するために最適化される、オープンソースのプラットフォームである。本開示に記載する開発フレームワークは、マイクロサービスをベースとするアプリケーション（クラウドベースのサービス交換用の相互接続プラットフォームなど）のエンドツーエンドでの作成、実装、及び配備に、全体の開発フレームワークを提供するように、Ｎｏｄｅ．ｊｓ、マイクロサービス、及びコンテナを利用する。
【０３３１】
開発フレームワークによって容易になる上記の設計原理により、市場投入までの時間の短縮、より良い性能、より優れたユーザ体験、より容易な構築、よりレスポンシブで拡張可能なマイクロサービスベースのアプリケーション、開発時間の削減、及び疎結合のシステム設計といった利益のうちの一つ以上を提供してもよい。開発フレームワークは、一つ以上のサーバ、ワークステーション、及び／又は開発フレームワークの構成要素を実行するように構成される、一つ以上のプロセッサを含む、クラウドベースの環境を含む、いかなる好適な実行環境上で実行されてもよい。
【０３３２】
図２０は、本開示に記載する技術に従う、開発フレームワークの論理的な考え方を示す概念図である。開発フレームワークは、ＲＥＳＴｆｕｌ  ＡＰＩ１９２０が、マイクロサービスをベースとするアプリケーションに対して、異なるユーザ基盤へのマルチチャネルインタフェースを表す、六角形の表示を使用して概念的に示される。開発フレームワークは、ＡＰＩコントラクトのモデル化（「モデル」）１９２２、通知１９２４のデータベース、又はインメモリデータベース１９０４Ａ、外部ソースへのＲＥＳＴｆｕｌインタフェース１９０４Ｂ、Ｏｒａｃｌｅ／ＳＱＬサーバ／ＳＱＬベースのデータベース１９０４Ｃ、及びＮｏＳＱＬデータベース１９０４Ｄ（総称して「データベース１９０４」）を含む、その他の永続的記憶部接続性（「データ」）１９２６、自動スキャフォールディング１９２８、リポジトリ１９０８のパターンを使用するテスト駆動型開発１９３０、エディタ１９１０によって（少なくともいくつかの例では）設計されるワークフローを実行するワークフローエンジン１９３２（例えば、少なくともいくつかの例において、コンテナベースのフレームワーク１９０６を使用して達成される配備を伴う、コマンドラインインタフェース（ＣＬＩ））の複数の概念的構成要素を含む。
【０３３３】
ＲＥＳＴｆｕｌ  ＡＰＩ１９２０は、各チャネル１９０２に対して完全にカスタマイズ可能なＡＰＩコントラクトを提示するように、開発フレームワークを使用して構成されてもよい。図２０に示す例示のチャネル１９０２は、ウェブソケット１９０２Ａ、Ａｊａｘ要求１９０２Ｂ、ＡＰＩ１９０２Ｃ、モノのインターネット（ＩｏＴ）１９０２Ｄ、及びＨＴＭＬ５アプリケーション１９０２Ｅを含む。オーケストレーションは、チャネル１９０２ごとの各ＡＰＩコントラクト要求に対して定義されたルール及び／又はワークフローに基づいて、マイクロサービスを調整するように使用される。オーケストレータは、一般的にはＡＰＩ要求を処理してもよいが、しかしながら、チャネル１９０２の各々に対して完全にカスタマイズ可能なＡＰＩコントラクトを許可する１組のルールを実行することによって行われる。図２０に概念的に示し、本明細書に記載する、開発フレームワーク及びマイクロサービスをベースとするアプリケーションアーキテクチャは、ＡＰＩ要求／応答のコントラクトの可変性に対応してもよい。いくつかの実施例では、オーケストレータ設計は、異なるチャネル１９０２にわたる差異を受け入れながら、当該差異に対して平等の対応を提供する。より具体的には、オーケストレータ開発プラットフォーム／フレームワークによって、チャネル１９０２の各々に対してカスタマイズされたエンドポイントの作成が可能となってもよい。それゆえ、要求／応答モデルは、特殊化され、いくつかの場合には、固有又は個別の要件から成るように、チャネル１９０２の各々に合わせて最適化されてもよい。開発プラットフォーム／フレームワークを使用して構築されるオーケストレータは、異なるチャネルで全てのネットワーク通信を直接及び透過的に処理してもよい。要求に基づいて、オーケストレータは、関連するワークフローをロードし、コントラクトを遂行するように、異なるマイクロサービスを調整する。異なるチャネルに対して効率的に相互作用することを保証するために、開発フレームワークオーケストレータは、様々な異なる最適化を適用してもよい。
【０３３４】
図２１は、本開示に記載する技術に従い、マイクロサービスをベースとするアプリケーションのスキャフォールディング、構築、テスト、及び配備を促進する、開発フレームワークの構成要素をさらに詳細に示すブロック図である。本実施例における開発フレームワークは、三つの構成要素、オーケストレータプラットフォーム２０００、マイクロサービスプラットフォーム２０１８、及びプラグイン２０３８を含む。オーケストレータプラットフォーム２０００は、マイクロサービスの検出（サービス検出エンジン２００２、インタフェース文書化／発行（ＡＰＩ文書化エンジン２００４）、コードの生成（コード生成ツール２００６）、応答の集約及びルーティング（応答アグリゲータ２０１０）、ステートマシンの配置（ステートマシン２０１２）、及びワークフローの実行（ワークフロー実行ツール２０１４）の構成要素／アプリケーションを含む。
【０３３５】
サービス検出エンジン２００２は、Ｎｏｄｅ．ｊｓ及び／又はｅｘｐｒｅｓｓ．ｊｓを拡張してもよい。ＡＰＩ文書化エンジン２００４は、ｅｘｐｒｅｓｓ．ｊｓ及び／又はＳｗａｇｇｅｒを拡張してもよい。コード生成ツール２００６は、Ｓｗａｇｇｅｒ及び／又はｓｏｃｋｅｔ．ｉｏを拡張してもよい。ワークフロー実行ツール２０１４はPM２を拡張してもよい。
【０３３６】
ワークフロー実行ツール２０１４は、マイクロサービスが、全体のサービスを生み出し、オーケストレータプラットフォーム２０００によって公開されるコントラクトを遂行するための順序及びイベントを定義する、ステートマシンから成るワークフローを実行する。ワークフロー実行ツールは、適切な時間に適切な入力で各マイクロサービスを呼び出すことによって、マイクロサービスを調整し、ワークフローの状態を維持し、データを渡し、ワークフローの実行に信頼性及び透過性を提供する。
【０３３７】
マイクロサービスを開発、監視、及び実行するマイクロサービスプラットフォーム２０１８は、コードの生成（コード生成ツール２０２０）、インタフェースの文書化／発行（ＡＰＩ文書化エンジン２０２２）、ロギング（ログアグリゲータ２０２４）、処理の監視（プロセス監視２０２６）、通知（通知サービス２０２８）、ＡＰＩ開発及び実行（ＡＰＩフレームワーク２０３０）、並びにセキュリティ（セキュリティＣＯＲＳ検査２０３２）の構成要素／アプリケーションを含む。
【０３３８】
コード生成ツール２０２０はＹＡＭＬを拡張してもよい。ＡＰＩ文書化エンジン２０２２はＳｗａｇｇｅｒを拡張してもよい。ログアグリゲータ２０２４はＬｏｇｓｔａｓｈを拡張してもよい。プロセス監視２０２６はPM２を拡張してもよい。通知サービス２０２８はＮｏｄｅ．ｊｓを拡張してもよい。ＡＰＩフレームワーク２０３０はＮｏｄｅ．ｊｓ及び／又はｅｘｐｒｅｓｓ．ｊｓを拡張してもよい。セキュリティＣＯＲＳ検査２０３２はｅｘｐｒｅｓｓ．ｊｓを拡張してもよい。
【０３３９】
プラグイン構成要素２０３８は、図２１の例示のインスタンスでは、構成要素の接続（共通コネクタ２０４０）、ＯＲＭ２０４２、開発フレームワークアダプタ（Ａｑｕａアダプタ２０４４）、フレームワークがマイクロサービス用にスキャフォールディングを生成し、本開示に記載するその他のステップを実施するように、開発者が要求するのに利用してもよい、開発フレームワーク（Ａｑｕａ  ＣＬＩ２０４６）用のコマンドラインインタフェース（ＣＬＩ）、企業のシステムに接続する企業システムコネクタ２０４８、開発フレームワークのコアモジュール（Ａｑｕａコアモジュール２０５０）、プラグイン２０５２、テンプレートエンジン２０５４、及びイベントアグリゲータ２０５６を促進する要素／アプリケーションを含む。
【０３４０】
ユーザ／開発者は、プラグイン（ノードモジュール）をロードすることによって、開発フレームワークの機能を拡張できる。コア開発フレームワークの特徴は、プラグインとして開発されており、そのため、ユーザはさらに、プラグインとしていかなる第三者ノードモジュールを拡張してもよい。プラグイン機構によって、Ｎｏｄｅ．ｊｓが提供するコアの機能性のうちの一つが拡張され、ユーザが、新しく興味のある手段で、そのコアの機能性を拡張するプラグインを開発及び／又はロードすることが可能になる。
【０３４１】
図２２は、本開示に記載する開発フレームワーク及び技術を使用して、マイクロサービスをベースとするアプリケーションアーキテクチャに従い、アプリケーションを開発する例示の開発プロセスを示すフロー図である。最初に、開発者は、開発フレームワークを組み込み／設定し（２１０１）、ＡＰＩを公開し、要求を受信すべきＡＰＩサーバを作成し（２１０２）、基になるマイクロサービスの実行フレームワーク（本実施例ではＮｏｄｅ．ｊｓ）への依存性を組み込む（２１０３）。その後開発者は、例えば、Ｓｗａｇｇｅｒ又はＹＡＭＬを使用して、ＡＰＩ定義を編集する（２１０４）ことによって、アプリケーションの開発を始めてもよい。ＡＰＩ定義は、ＡＰＩ経路に関する情報だけでなく、ＡＰＩ経路に対する応答クラスのモデルスキーマ、及び関連する要求（例えば、作成、読み出し、更新、削除）を含んでもよい。それから開発者は、ＡＰＩ定義を入力するように、開発フレームワークＣＬＩ又はその他のインタフェースを使用して、ＡＰＩサーバアプリケーションをスキャフォールディングするように、開発フレームワークを実行してもよい（２１０５）。それに応じて、開発フレームワークは、例えば、コントローラ、ルータ、モデルスキーマに従うモデル、構成及び検証データ、サンプルデータ、テストケース、並びにＡＰＩサーバアプリケーション用の実装ファイルを自動的に生成する。その時点で、スキャフォールディングされたＡＰＩサーバは、開発者から、論理を実装し、インタフェースを束ね、ルーティング及び制御を設定するなどのさらなる操作はないまま、実行されてもよい。代わりに、開発者は、スキャフォールディングされたＡＰＩサーバアプリケーションを実行するように、ステップ２１０２で作成されたＡＰＩサーバを単純に動作させてもよい（２１０６）。実行されたＡＰＩサーバアプリケーションのＡＰＩ経路を呼び出すことによって、開発者は、ＡＰＩを探究して、ＡＰＩを改良してもよい（２１０７）。開発者が、ＡＰＩ定義を修正すると判定した場合（２１５０の「はい」の分岐）、開発者は、必要に応じて反復して、ステップ２１０４〜２１０７を再び実施してもよい。
【０３４２】
続いて開発者は、ＡＰＩのエンドポイントを実装し（２１０８）、スキャフォールディングに伴って自動的に生成される、自動テストを実行してもよい（２１０９）。ＡＰＩのエンドポイントを実装したら、開発者はＡＰＩを探索してテストしてもよい（２１１０）。開発者が、ＡＰＩ定義を修正すると判定した場合（２１５２の「はい」の分岐）、開発者は、必要に応じて反復して、ステップ２１０４〜２１１０を再び実施してもよい。開発者が、エンドポイントを修正すると判定した場合（２１５２の「はい」の分岐）、開発者は、必要に応じて、ＡＰＩのエンドポイント（マイクロサービス）の実装を修正するのを反復して、ステップ２１０８〜２１１０を再び実施してもよい。
【０３４３】
開発者はまた、開発フレームワークを使用して、調整されたワークフロー、例えば、図１６〜１７のワークフローＷＤ１〜ＷＤ４を定義して（２１１１）、調整されたワークフローを探索しテストしてもよい（２１１２）。開発者が、エンドポイントを修正すると判定した場合（２１５８の「はい」の分岐）、開発者は、必要に応じて、ＡＰＩのエンドポイント（マイクロサービス）の実装を修正するのを反復して、ステップ２１０８〜２１１０を再び実施してもよい。開発者が、ＡＰＩ定義を修正すると判定した場合（２１５６の「はい」の分岐）、開発者は、必要に応じて反復して、ステップ２１０４〜２１１０を再び実施してもよい。開発者はさらに、ステップ２１１１〜２１１２を反復して、ステップ２１０４〜２１１２を繰り返し実施することによって、基になるマイクロサービスのインタフェース／埋め込みを変更してもよい。このように、開発者は、マイクロサービスをベースとするＡＰＩサーバアプリケーションを素早くスキャフォールディングするように、本明細書に記載する開発フレームワークを使用してもよい。開発フレームワークによって、ＡＰＩ定義を迅速に一新することが可能になるため、開発フレームワークは、ＡＰＩ定義を変更するたびに、開発者が、サービスインフラを手動で再度作成する、又は少なくとも修正する必要を避けることが可能になるように、ＡＰＩ及び基になる実装へのより容易な変更及びその反復を促進してもよい。
【０３４４】
図２３は、本開示に記載する技術に従い、開発フレームワークによって実施され、オーケストレーション定義及びマイクロサービス定義を通じて実行される、開発フレームワークプロジェクト及びエンドツーエンドのスキャフォールディングプロセスの構成要素を示す概念図である。開発フレームワーク及び本明細書に記載する技術を使用して開発される、マイクロサービスをベースとするアプリケーションは、少なくとも一つのワークフロー及び少なくとも一つのマイクロサービスを含む。したがって、ワークフロープロジェクト２２０７は、マイクロサービスＡＰＩプロジェクト２２０１及びオーケストレーションＡＰＩプロジェクト２２０９の依存性を含む（配備のためにＤｏｃｋｅｒインフラ２２０８を伴う）。開発者は、オーケストレーションＡＰＩプロジェクト２２０９に対して、少なくとも一つのオーケストレーション／ワークフロースキーマ（定義）２２１０を定義し、またマイクロサービスＡＰＩプロジェクト２２０１に対して、少なくとも一つのマイクロサービススキーマ（定義）２２０２を定義する。スキーマ２２１０は、一つ以上のマイクロサービススキーマ２２０２であってもよい（又は一つ以上のマイクロサービススキーマ２２０２から導かれてもよい）。多目的スキャフォールディングプロセス２２０３は、オーケストレータ用のルート２２１２、コントローラ２２１３、及びワークフロー２２１４を含む、ワークフローのスキャフォールディングを生成するように、少なくとも一つのオーケストレーション／ワークフロースキーマ２２１０の処理を行う。多目的スキャフォールディングプロセス２２０３は、ルート２２０４、コントローラ２２０５、及び実装ファイル２２０６を含む、マイクロサービスのスキャフォールディングを生成するように、少なくとも一つのマイクロサービススキーマ２２０２の処理を行う。
【０３４５】
マイクロサービスをベースとするアプリケーションのルータは、例えば、パケットをルーティングするネットワークルータとは異なる。マイクロサービスをベースとするアプリケーションのルータは、本明細書に記載する技術に従って、経路に従うＡＰＩ要求が、属性、クライアントのアプリケーション、顧客ＩＤ、及びその他のパラメータを要求する、アプリケーション及びルートに発行されるＡＰＩ要求を受信する。パラメータの各々は、スキャフォールディングプロセスが自動的に生成される、一つ以上のルート２２１２によって指定又は参照されてもよい。ルートは、スキャフォールディングプロセスによっても自動的に生成される、コントローラ２２１３に決定する。コントローラは、ルータがルートに従ってコントローラへルーティングするＡＰＩ要求によって呼び出される、ＡＰＩのエンドポイントと関連する機能性を実施するように、ビジネス論理を実行して、一つ以上のワークフローを実行及び調整する。例えば、コントローラは、相互接続プラットフォームに対する「仮想回路の作成」のＡＰＩのエンドポイントと関連する機能性を実行するように構成されてもよい。マイクロサービスをベースとするアプリケーション用のルータは、コントローラへの「仮想回路の作成」のＡＰＩのエンドポイントを呼び出す要求をルーティングし、それによって、要求を遂行するように、一つ以上のワークフローが実行される。
【０３４６】
図２４〜２６は、本明細書に記載する技術に従う、開発フレームワーク用の例示のインタフェース及び入力／出力を示す。
【０３４７】
図２４のインタフェース２３００及び２３０２は、開発フレームワークＣＬＩの実行、及び開発フレームワークＣＬＩのスプラッシュスクリーンをそれぞれ示す。またインタフェース２３００は、マイクロサービスのスタブを容易かつ迅速に作成するのに使用可能な開発フレームワークＣＬＩのコマンドを示す。
【０３４８】
図２５のインタフェース２４００は、開発者によって作成された、例示のＡＰＩコントラクトを示す。
【０３４９】
図２５のインタフェース２４０２は、インタフェース２４００において示されるＡＰＩコントラクトに対して実行される、スキャフォールディングプロセスを示す。スキャフォールディングプロセスによって、コントローラ及びルータ、ＡＰＩコントラクトにおけるモデルスキーマの各々に対するモデル、マイクロサービス用実装ファイル、サンプルデータ、テストケース、検証ファイル、並びに開発、ＵＡＴ、ＱＡ、生産、及び地域情報用の構成が生成される。開発フレームワークによって自動的に生成される、このマイクロサービスの設計図によって、開発者は、マイクロサービスに対するビジネス論理の実装を素早く開始し、マイクロサービスの設計図のこれらの態様を手動で作成するのを避けることが可能になる。すなわち、開発フレームワークによって、マイクロサービスをベースとするアプリケーションの開発を開始する、整理された迅速な手段が提供され、開発者が、ソフトウェアのインフラを構築するのに時間を費やす代わりに、再利用可能なアプリケーション又はビジネス論理を書くことに集中することが可能になってもよい。
【０３５０】
本明細書に記載する開発フレームワークは、相互接続プラットフォーム１０３など、クラウドベースのサービス交換のための相互接続プラットフォームを開発するように使用されてもよい。図３Ａ〜３Ｂ及びその他の箇所に関して記載する通り、相互接続プラットフォームは、例えば、モバイル、ウェブ、ＡＰＩ４０２Ｃ、買い手アプリケーション４０２Ａ、売り手アプリケーション４０２Ｂといった、複数のチャネルの特殊インタフェースを公開する、ＡＰＩゲートウェイ４０３を含んでもよい。相互接続プラットフォームは、本開示の図１、２、３Ａ〜３Ｂ、４、１３、１４、及びその他の箇所の相互接続プラットフォームの異なる描写に関して記載する通り、オーケストレータ（例えば、オーケストレータ７０６）及び複数のマイクロサービス（例えば、マイクロサービス４０８Ｄ、７０８、１６３０）を含む。オーケストレータ（及び関連するワークフロー）及びマイクロサービスは、クラウドベースのサービスを相互接続し、クラウドベースのサービス交換で当該相互接続を管理する、相互接続プラットフォームによって実施される、特徴及びサービスの迅速な開発を促進するように、本開示に記載する開発フレームワークを使用してスキャフォールディングされてもよい。
【０３５１】
図２６は、インタフェース２４００に示されるＡＰＩコントラクトから生成される、マイクロサービスのインタフェース用の文書化及びテストページを示す、インタフェース２５００を示す。開発フレームワークは、アプリケーション向けのマイクロサービス／ＡＰＩカタログを自動的に生成してもよい。複数のＨＴＴＰベースのマイクロサービスでは、様々なインタフェース内で実に容易に迷うが、開発フレームワークは、全てのマイクロサービス及びそれらの公開される機能性を記述するＹＡＭＬのＡＰＩコントラクトに基づいて、ＡＰＩカタログを自動的に構築する。ＡＰＩカタログは検索可能であってもよい。フレームワークは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）の記述が利用可能である、各エンドポイントに対して/api-docsのエンドポイントを自動的に作成する。
【０３５２】
この例示のモデルでは、「注文」モデルスキーマが、注文モデルのフィールドを定義する。開発フレームワークによって生成されるインタフェース２５００は、注文のモデルスキーマの実施を行うと、開発フレームワークによって自動的に生成される、ＨＴＴＰ動作２５００Ａ〜２５００Ｄを提示する。ＰＯＳＴ動作ボタン２５００Ａによって、ユーザが、開発フレームワークにより再び自動的に生成される注文のマイクロサービスに対して、自動的に生成されるエンドポイントを使用して、インタフェース２５００から新しい注文インスタンスを入力及び追加することが可能になる。ＧＥＴ動作ボタン２５００Ｂ、ＤＥＬＥＴＥ動作ボタン２５００Ｃ、及びＰＵＴ動作ボタン２５００Ｄは、注文のインスタンスに対応するＧＥＴ、ＤＥＬＥＴＥ、及びＰＵＴテスト機能性を提供する。インタフェース２５００を使用することによって、ユーザはマイクロサービスのテストを実施し、開発を反復することができる。
【０３５３】
図２７は、本開示に記載する技術に従う開発フレームワークを使用して開発される、クラウドベースのサービス交換用相互接続プラットフォームの構成要素を示すブロック図である。オーケストレータ２６３０は、マイクロサービスの管理２６０６を実施し、ワークフローに従ってマイクロサービスを実行するように、ワークフロー管理ツール及び実行エンジン２６０８を含む。複数のマイクロサービス２６３２が、クラウドエクスチェンジにおいて仮想回路の相互接続を設定及び管理する仮想回路２６１０、並びに外部のクラウドサービス２６１８、２６２０への外部接続用のその他のマイクロサービス２６１２、２６１４を含めて示される。またその他のマイクロサービスは、マイクロサービス７０８、８１７、８１９、クラウドエクスチェンジのＡＰＩサービス４０９、及び本明細書に記載する相互接続プラットフォーム用のマイクロサービスのその他の実施例に相当してもよい。オーケストレータ２６３０は、顧客ポータル２６０２及び外部ＡＰＩ２６０４を介して、異なるカテゴリのユーザ２６００Ａ〜２６００Ｄに対して、特殊ＡＰＩチャネルを提示する。当該ＡＰＩチャネルの各々は、上に記載する通り、完全にカスタマイズされたＡＰＩコントラクトを使用して開発されてもよい。
【０３５４】
図２８は、本開示の一つ以上の技術に従い動作する、コンピュータデバイスの一実施例のさらなる詳細を示すブロック図である。図２８は、サーバ、ワークステーション、ノート型コンピュータデバイス、若しくはマイクロサービスをベースとするアプリケーションの開発フレームワークを実行する、一つ以上のプロセッサ２８０２を含むその他のコンピュータデバイス２８００、又は本明細書に記載するいかなる他のコンピュータデバイスのうちの特定の例を示してもよい。コンピュータデバイス２８００のその他の実施例は、その他の例において使用してもよい。例示のためスタンドアローンのコンピュータデバイス２８００として図２８に示すものの、コンピュータデバイスは、ソフトウェア命令を実行する、一つ以上のプロセッサ又はその他の好適なコンピュータ環境を含む、いかなる構成要素又はシステムであってもよく、例えば、必ずしも図２８に示す一つ以上の要素を含む必要はない（例えば、通信部２８０６、及びいくつかの実施例では、記憶デバイス２８０８などの構成要素は、同じ場所に設置されなくてもよく、又はその他の構成要素として同じ筐体の中になくてもよい）。コンピュータデバイス2800は、例えば、クラウドエクスチェンジポイント１２８のうちのいずれかの内部、別の相互接続施設内、又は支部若しくはクラウドエクスチェンジプロバイダによって採用若しくは使用されるクラウドコンピューティング環境に設置され、実行されてもよい。コンピュータデバイス２８００の例は、クラウドエクスチェンジ用の相互接続プラットフォームの開発者によって使用されてもよい。このように、コンピュータデバイス２８００は、アプリケーションフレームワークの開発システムを表してもよい。
【０３５５】
図２８の特定の実施例に示す通り、コンピュータデバイス２８００は、一つ以上のプロセッサ２８０２、一つ以上の入力デバイス２８０４、一つ以上の通信部２８０６、一つ以上の出力デバイス２８１２、一つ以上の記憶デバイス２８０８、並びにユーザインタフェース（ＵＩ）デバイス２８１０及び通信部２８０６を含む。コンピュータデバイス２８００は、一実施例では、コンピュータデバイス２８００によって実行可能である、一つ以上のアプリケーション２８２２、仮想概念構築アプリケーション２８２４、及びオペレーティングシステム２８１６をさらに含む。構成要素２８０２、２８０４、２８０６、２８０８、２８１０、及び２８１２の各々は、構成要素間通信のために（物理的に、通信可能に、及び／又は動作可能に）結合される。いくつかの実施例では、通信チャネル２８１４は、システムバス、ネットワーク接続、プロセス間通信データ構造、又はデータを伝達するいかなる他の方法を含んでもよい。一実施例として、構成要素２８０２、２８０４、２８０６、２８０８、２８１０、及び２８１２は、一つ以上の通信チャネル２８１４によって結合されてもよい。
【０３５６】
プロセッサ２８０２は、一実施例では、コンピュータデバイス２８００内で実行する機能性及び／又はプロセス命令を実装するように構成される。例えば、プロセッサ２８０２は、記憶デバイス２８０８に記憶される命令の処理を行うことが可能であってもよい。プロセッサ２８０２の実施例には、マイクロプロセッサ、コントローラ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は同等の個別若しくは統合論理回路のうちのいかなる一つ以上を含んでもよい。
【０３５７】
一つ以上の記憶デバイス２８０８は、動作中コンピュータデバイス２８００内に情報を記憶するように構成されてもよい。記憶デバイス２８０８は、いくつかの実施例では、コンピュータで読み取り可能な記憶媒体として記載される。いくつかの実施例では、記憶デバイス２８０８は一時メモリであり、記憶デバイス２８０８の主要な目的が長期間の記憶ではないことを意味する。記憶デバイス２８０８は、いくつかの実施例では、揮発性メモリとして記載され、コンピュータの電源が切れると、記憶デバイス２８０８は記憶したコンテンツを維持しないことを意味する。揮発性メモリの実施例には、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、及び当該技術分野で既知であるその他の形態の揮発性メモリを含む。いくつかの実施例では、記憶デバイス２８０８は、プロセッサ２８０２によって実施するプログラム命令を記憶するように使用される。記憶デバイス２８０８は、一実施例では、プログラム実行中一時的に情報を記憶するように、コンピュータデバイス２８００上で動作されるソフトウェア又はアプリケーションによって使用される。
【０３５８】
また記憶デバイス２８０８は、いくつかの実施例では、一つ以上のコンピュータで読み取り可能な記憶媒体を含む。記憶デバイス２８０８は、揮発性メモリよりも大きい情報量を記憶するように構成されてもよい。記憶デバイス２８０８はさらに、長期間情報を記憶するように構成されてもよい。いくつかの実施例では、記憶デバイス２８０８は不揮発性記憶要素を含む。当該不揮発性記憶要素の実施例には、磁気ハードディスク、光ディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、又は電気的にプログラム可能なメモリ（ＥＰＲＯＭ）若しくは電気的に消去及びプログラム可能なメモリ（ＥＥＰＲＯＭ）の形態を含む。
【０３５９】
コンピュータデバイス２８００も、いくつかの実施例では、一つ以上の通信部２８０６を含む。コンピュータデバイス２８００は、一実施例では、一つ以上の有線／無線／モバイルネットワークなど、一つ以上のネットワークを介して外部デバイスと通信するように、通信部２８０６を利用する。通信部２８０６は、イーサネット（登録商標）カードなどのネットワークインタフェースカード、光送受信機、無線周波数送受信機、又は情報を送受信できる、いかなる他の種類のデバイスを含んでもよい。当該ネットワークインタフェースの一実施例には、３Ｇ及びＷｉＦｉ無線を含んでもよい。いくつかの実施例では、コンピュータデバイス２８００は、外部デバイスと通信するように、通信部２８０６を使用する。
【０３６０】
コンピュータデバイス２８００も、一実施例では、一つ以上のユーザインタフェースデバイス２８１０を含む。ユーザインタフェースデバイス２８１０は、いくつかの実施例では、触覚、音声、又はビデオによるフィードバックによって、ユーザからの入力を受信するように構成される。ユーザインタフェースデバイス２８１０の実施例には、存在を感知するディスプレイ、マウス、キーボード、声に反応するシステム、ビデオカメラ、マイク、又はユーザからのコマンドを発見する、いかなる他の種類のデバイスを含む。いくつかの実施例では、存在を感知するディスプレイはタッチスクリーンを含む。
【０３６１】
また、一つ以上の出力デバイス２８１２も、コンピュータデバイス２８００に含まれてもよい。出力デバイス２８１２は、いくつかの実施例では、触覚、音声、又はビデオによる刺激を使用して、ユーザへの出力を提供するように構成される。出力デバイス２８１２は、一実施例では、存在を感知するディスプレイ、サウンドカード、ビデオグラフィックスアダプタカード、又は人若しくはマシンが理解可能である適切な形態に信号を変換する、いかなる他の種類のデバイスを含む。出力デバイス２８１２のさらなる実施例には、スピーカ、陰極管（ＣＲＴ）モニタ、液晶ディスプレイ（ＬＣＤ）、又はユーザへの分かりやすい出力を生成できる、いかなる他の種類のデバイスを含む。
【０３６２】
コンピュータデバイス２８００は、オペレーティングシステム２８１６を含んでもよい。オペレーティングシステム２８１６は、いくつかの実施例では、コンピュータデバイス２８００の構成要素の動作を制御する。例えば、一実施例では、オペレーティングシステム２８１６によって、一つ以上のアプリケーション２８２２と、プロセッサ２８０２、通信部２８０６、記憶デバイス２８０８、入力デバイス２８０４、ユーザインタフェースデバイス２８１０、及び出力デバイス２８１２を伴う相互接続プラットフォームアプリケーション２８２４との通信が促進される。
【０３６３】
また、アプリケーション２８２２及びマイクロサービスをベースとする開発フレームワークアプリケーション２８２４（「開発フレームワークアプリケーション２８２４」）は、コンピュータデバイス２８００によって実行可能なプログラム命令及び／又はデータを含んでもよい。コンピュータデバイス２８００によって実行可能な例示の開発フレームワークアプリケーション２８２４は、ＡＰＩサーバ２８５０、オーケストレーション開発及び実行アプリケーション２８５２、マイクロサービス開発及び実行アプリケーション２８５４、並びにプラグイン２８５６のうちのいずれか一つ以上を含んでもよく、各々は、これらがコンピュータデバイス２８００のいかなる所与の実施例により実行可能であってもよく、又は実行可能でなくてもよいことを示す点線で示される。
【０３６４】
ＡＰＩサーバ２８５０は、本明細書に記載する技術に従ってスキャフォールディングされる、マイクロサービス及びオーケストレータに対するＡＰＩを公開するように構成されてもよい。オーケストレーション開発及び実行アプリケーション２８５２は、図２１のオーケストレータプラットフォーム２０００の構成要素／アプリケーションを含んでもよい。マイクロサービス開発及び実行アプリケーション２８５２は、図２１のマイクロサービスプラットフォーム２０１８の構成要素／アプリケーションを含んでもよい。プラグイン２８５６は、図２１のプラグイン２０３８の構成要素／アプリケーションを含んでもよい。
【０３６５】
本明細書に記載する技術は、ハードウェア、ソフトウェア、ファームウェア、又はそれらのいかなる組み合わせにおいて実装されてもよい。モジュール、ユニット、又は構成要素として記載する様々な特徴は、統合された論理デバイスにおいて共に、若しくは個別であるが相互運用可能な論理デバイスとして別個に、又はその他のハードウェアデバイスにおいて実装されてもよい。いくつかの場合では、電子回路の様々な特徴は、集積回路チップ又はチップセットなど、一つ以上の集積回路デバイスとして実装されてもよい。
【０３６６】
ハードウェアの中に実装される場合には、本開示は、例えば、プロセッサ、又は集積回路チップ若しくはチップセットなどの集積回路デバイスといった装置を対象としてもよい。代替として又は追加として、ソフトウェア又はファームウェアにおいて実装される場合、技術は、実行されるとき、上に記載する方法のうちの一つ以上をプロセッサに実施させる命令を備える、コンピュータで読み取り可能なデータ記憶媒体によって、少なくとも一部を実現されてもよい。例えば、コンピュータで読み取り可能なデータ記憶媒体は、プロセッサによる実行の当該命令を記憶してもよい。
【０３６７】
コンピュータで読み取り可能な媒体は、パッケージ化された道具を含んでもよい、コンピュータプログラム製品の一部を形成してもよい。コンピュータで読み取り可能な媒体は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的に消去可能でプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、磁気又は光学データ記憶媒体、及び同種のものなど、コンピュータデータ記憶媒体を備えてもよい。いくつかの実施例では、製造品は、一つ以上のコンピュータで読み取り可能な記憶媒体を備えてもよい。
【０３６８】
いくつかの実施例では、コンピュータで読み取り可能な記憶媒体は、非一時的な媒体を備えてもよい。用語「非一時的」は、記憶媒体が、搬送波又は伝播信号においては具体化されないことを示してもよい。ある実施例では、非一時的な記憶媒体は、経時変化し得るデータを（例えば、ＲＡＭ又はキャッシュの中に）記憶してもよい。
【０３６９】
コード又は命令は、一つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又はその他の同等の集積若しくは個別の論理回路など、一つ以上のプロセッサを含む処理回路によって実行される、ソフトウェア及び／又はファームウェアであってもよい。したがって、本明細書で使用する通り、用語「プロセッサ」は、前述の構造のうちのいずれか、又は本明細書に記載する技術の実装に好適ないかなる他の構造を指してもよい。加えて、いくつかの態様では、本開示に記載の機能性は、ソフトウェアモジュール又はハードウェアモジュール内に提供されてもよい。
【０３７０】
上記の代替物に加えて、又は上記の代替物として、以下の実施例を記載する。以下の実施例のうちのいずれかに記載する特徴は、本明細書に記載する他の実施例のうちのいずれかで利用されてもよい。
【０３７１】
実施例１
複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含む、ネットワークデータセンターであって、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連する、ネットワークデータセンターと、ネットワークデータセンター内にあり、ネットワークデータセンターのスイッチングファブリックを通って、クラウドベースのサービス交換の複数の顧客と関連するネットワークの各々を、クラウドサービスプロバイダと関連するネットワークのうちの一つ以上に接続するように構成される、複数の相互接続資産であって、複数の顧客と関連するネットワークの各々に対する、一つ以上の仮想回路のそれぞれの１組を含み、複数の顧客と関連するネットワークと、複数のクラウドサービスプロバイダと関連するネットワーク内から実行されるクラウドサービスとの間のネットワークデータセンター内に、ネットワーク接続性を提供する、複数の相互接続資産と、ネットワークデータセンター内の一つ以上の管理デバイス上で実行され、複数の顧客と関連するネットワークによって到達可能で、顧客と関連するネットワークのいずれか内で実行されるアプリケーションによって発行される要求の受信に応じて、要求を満たすよう、複数の相互接続資産にアクセスするように構成される、ソフトウェアインタフェースを提示する、相互接続プラットフォームと、を備える、クラウドベースのサービス交換。
【０３７２】
実施例２
ソフトウェアインタフェースは、第２のアプリケーションによる方法の呼び出しに応じて、複数の相互接続資産の記述を返送するように構成される、少なくとも一つの方法を含む、検出アプリケーションプログラミングインタフェースを備える、実施例１のクラウドベースのサービス交換。
【０３７３】
実施例３
ソフトウェアインタフェースは、第２のアプリケーションによる方法の呼び出しに応じて、仮想回路のうちの一つをプロビジョニングし、仮想回路のうちの一つを検証し、仮想回路のうちの一つの削除を確認するように構成される、少なくとも一つの方法を含む、処理アプリケーションプログラミングインタフェースを備える、実施例１〜２のいずれかに記載のクラウドベースのサービス交換。
【０３７４】
実施例４
ソフトウェアインタフェースは、アプリケーションによる方法の呼び出しに応じて、クラウドサービスに推奨される設定情報、並びにクラウドサービスに関する競合他社の存在、クラウドサービスの存在、クラウドサービスの可用性、顧客の存在、顧客の獲得可能性、及び稼働率統計に関するカスタマイズされた分析のうちの一つを返送するように構成される、少なくとも一つの方法を含む、使用アプリケーションプログラミングインタフェースを備える、実施例１〜３のいずれかに記載のクラウドベースのサービス交換。
【０３７５】
実施例５
ソフトウェアインタフェースは、第２のアプリケーションによる方法の呼び出しに応じて、アカウントの管理のうちの少なくとも一つを実施し、顧客に請求書を送付し、顧客のクレジットを検証し、アプリケーションと関連するエンティティのプロファイルを構成し、アプリケーションと関連するエンティティのポリシーを構成するように構成される、少なくとも一つの方法を含む、支援アプリケーションプログラミングインタフェースを備える、実施例１〜４のいずれかに記載のクラウドベースのサービス交換。
【０３７６】
実施例６
第２のアプリケーションは、顧客と関連するアプリケーションのうちの一つと、一つ以上のクラウドサービスプロバイダのうちの一つのクラウドサービスプロバイダと関連するアプリケーションと、を備える、実施例２〜５のいずれかに記載のクラウドベースのサービス交換。
【０３７７】
実施例７
ソフトウェアインタフェースは、アプリケーションプログラミングインタフェースを備え、顧客と関連するネットワークのいずれか内で実行されるアプリケーションによって発行される要求を受信することは、アプリケーションプログラミングインタフェースの方法に対して、方法の呼び出しを受信することを含む、実施例１に記載のクラウドベースのサービス交換。
【０３７８】
実施例８
ソフトウェアインタフェースは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴｆｕｌ）インタフェースを備え、要求は、複数の相互接続資産のうちの一つの相互接続資産に対する、インタフェース方法及びリソース識別子を指定する、アプリケーションデータを備える、実施例１〜７のいずれかに記載のクラウドベースのサービス交換。
【０３７９】
実施例９
複数の相互接続資産は、ポート、場所、注文、クラウドサービス、仮想回路の帯域幅、及び仮想回路のうちの少なくとも一つをさらに含む、実施例１〜８のいずれかに記載のクラウドベースのサービス交換。
【０３８０】
実施例１０
相互接続プラットフォームは、要求を受信するように、ソフトウェアインタフェースを実行し、要求に含まれるセキュリティ認証情報に基づいて、顧客を検証するように構成される、アプリケーションプログラミングインタフェースゲートウェイを備える、実施例１〜９のいずれかに記載のクラウドベースのサービス交換。
【０３８１】
実施例１１
相互接続プラットフォームは、要求を受信するように、ソフトウェアインタフェースを実行し、要求を満たすよう、複数の相互接続資産にアクセスするように、クラウドエクスチェンジプラットフォームサービスを呼び出し、クラウドエクスチェンジプラットフォームサービスから応答を受信し、顧客と関連するネットワークのいずれか内で実行されるアプリケーションに、応答の表示を送信するように構成される、アプリケーションプログラミングインタフェースゲートウェイを備える、実施例１〜９のいずれかに記載のクラウドベースのサービス交換。
【０３８２】
実施例１２
相互接続プラットフォームは、複数のクラウドエクスチェンジサービスを実行するように構成される、少なくとも一つのサブシステムであって、複数のクラウドエクスチェンジサービスの各クラウドエクスチェンジサービスが、仮想回路のプロビジョニングタスクを実施するように構成される、少なくとも一つのサブシステムと、要求を満たすようにワークフローに従って複数のクラウドエクスチェンジサービスを調整するように構成される、オーケストレーションエンジンと、を備える、実施例１〜９のいずれかに記載のクラウドベースのサービス交換。
【０３８３】
実施例１３
オーケストレーションエンジンは、ワークフロー及びルールエンジンを、要求に、並びにポリシー及びクラウドサービスプロファイルのうちの少なくとも一つに適用することによって、ワークフローを生成するように構成され、ワークフローは、複数のクラウドエクスチェンジサービスの一連の要求を備える、実施例１２に記載のクラウドベースのサービス交換。
【０３８４】
実施例１４
相互接続プラットフォームは、要求に少なくとも基づいて、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイを備える、実施例１２に記載のクラウドベースのサービス交換。
【０３８５】
実施例１５
要求を満たすよう複数の相互接続資産にアクセスするために、相互接続プラットフォームは、仮想回路のうちの一つをプロビジョニングするように構成される、実施例１に記載のクラウドベースのサービス交換。
【０３８６】
実施例１６
相互接続プラットフォームは、クラウドサービスのクエリサービスと、オーケストレーションエンジンと、要求の受信に応じて、クラウドサービスの記述を取得するよう、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、を備え、オーケストレーションエンジンは、クラウドサービスのクエリサービスを呼び出すように、ワークフローを生成及び実行し、クラウドサービスのクエリサービスは、オーケストレーションエンジンに、クラウドサービスの記述を返送し、オーケストレーションエンジンは、アプリケーションプログラミングインタフェースゲートウェイに、クラウドサービスの記述を返送し、要求に応答して、アプリケーションプログラミングインタフェースゲートウェイは、顧客と関連するネットワークのいずれか内で実行されるアプリケーションに、クラウドサービスの記述を返送する、実施例１〜９のいずれかに記載のクラウドベースのサービス交換。
【０３８７】
実施例１７
相互接続プラットフォームは、仮想回路のクエリサービスと、オーケストレーションエンジンと、要求の受信に応じて、仮想回路の記述を取得するよう、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、オーケストレーションエンジンは、仮想回路のクエリサービスを呼び出すように、ワークフローを生成及び実行し、仮想回路のクエリサービスは、オーケストレーションエンジンに、仮想回路の記述を返送し、オーケストレーションエンジンは、アプリケーションプログラミングインタフェースゲートウェイに、仮想回路の記述を返送し、要求に応答して、アプリケーションプログラミングインタフェースゲートウェイは、顧客と関連するネットワークのいずれか内で実行されるアプリケーションに、仮想回路の記述を返送する、実施例１〜９のいずれかに記載のクラウドベースのサービス交換。
【０３８８】
実施例１８
要求は、顧客にクラウドサービスへのアクセスを提供するように、仮想回路をプロビジョニングする要求を備え、相互接続プラットフォームは、ネットワークサービスのプロビジョニングサービスと、オーケストレーションエンジンと、要求の受信に応じて、仮想回路をプロビジョニングするよう、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、オーケストレーションエンジンは、ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行し、ネットワークサービスのプロビジョニングサービスは、要求のパラメータに従って仮想回路を確立する、実施例１〜９のいずれかに記載のクラウドベースのサービス交換。
【０３８９】
実施例１９
相互接続プラットフォームは、クラウドサービスプロバイダ統合サービスをさらに備え、オーケストレーションエンジンは、一つ以上のクラウドサービスプロバイダのうちの一つのクラウドサービスプロバイダによる、仮想回路の確認を要求するよう、クラウドサービスプロバイダ統合サービスを呼び出すように、ワークフローを生成及び実行し、オーケストレーションエンジンは、クラウドサービスプロバイダによる仮想回路の確認の受信に応答する、ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行する、実施例１８に記載のクラウドベースのサービス交換。
【０３９０】
実施例２０
要求のパラメータは、ポートのうちの買い手のポート、及びポートのうちの売り手のポートを指定し、相互接続プラットフォームは、ポートのサービスをさらに備え、オーケストレーションエンジンは、買い手のポート及び売り手のポートを検証するよう、ポートのサービスを呼び出すように、ワークフローを生成及び実行し、オーケストレーションエンジンは、買い手のポート及び売り手のポートの検証の受信に応答する、ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行する、実施例１９に記載のクラウドベースのサービス交換。
【０３９１】
実施例２１
要求のパラメータは、仮想回路の帯域幅を指定し、要求のパラメータに従って仮想回路を確立するために、ネットワークサービスのプロビジョニングサービスは、仮想回路の帯域幅を有する仮想回路を確立する、実施例１８に記載のクラウドベースのサービス交換。
【０３９２】
実施例２２
顧客は、ネットワークサービスプロバイダ及び企業のうちの一つを備える、実施例１〜２１のいずれかに記載のクラウドベースのサービス交換。
【０３９３】
実施例２３
複数のネットワークの各々は、パブリックにアドレス指定可能で、異なるパブリックネットワークのアドレス空間を有する、実施例１〜２２のいずれかに記載のクラウドベースのサービス交換。
【０３９４】
実施例２４
クラウドベースのサービス交換の顧客を、一つ以上のクラウドサービスプロバイダに接続するように構成される、複数の相互接続資産であって、顧客が一つ以上のクラウドサービスプロバイダからクラウドサービスにアクセスする仮想回路を含む、複数の相互接続資産と、複数の相互接続資産を修正するように構成される、オーケストレーションエンジンと、を備える、クラウドベースのサービス交換。
【０３９５】
実施例２５
複数のクラウドエクスチェンジサービスを実行するように構成される、少なくとも一つのサブシステムを、さらに備え、複数のクラウドエクスチェンジサービスの各クラウドエクスチェンジサービスが、仮想回路のプロビジョニングタスクを実施するように構成され、複数の相互接続資産を修正するために、オーケストレーションエンジンが、要求を満たすようにワークフローに従って、複数のクラウドエクスチェンジサービスを調整するように構成される、実施例２４に記載のクラウドベースのサービス交換。
【０３９６】
実施例２６
オーケストレーションエンジンは、ワークフロー及びルールエンジンを、要求に、並びにポリシー及びクラウドサービスプロファイルのうちの少なくとも一つに適用することによって、ワークフローを生成するように構成され、ワークフローは、複数のクラウドエクスチェンジサービスの一連の要求を備える、実施例２５に記載のクラウドベースのサービス交換。
【０３９７】
実施例２７
顧客と関連するアプリケーションによって発行される要求の受信に応じて、要求を満たすよう複数の相互接続資産にアクセスするように構成される、ソフトウェアインタフェースを有する、相互接続プラットフォームと、要求に少なくとも基づいて、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、複数の相互接続資産を修正するために、オーケストレーションエンジンは、オーケストレーションを呼び出すアプリケーションプログラミングインタフェースゲートウェイに応じて、複数の相互接続資産を修正するように構成される、実施例２４〜２６のいずれかに記載のクラウドベースのサービス交換。
【０３９８】
実施例２８
ネットワークデータセンター内の一つ以上の管理デバイス上におけるクラウドベースのサービス交換によって、複数の顧客と関連するネットワークによって到達可能なソフトウェアインタフェースを提示するように、相互接続プラットフォームを実行することと、顧客と関連するネットワークのいずれか内で実行されるアプリケーションによって発行される要求の受信に応じて、要求を満たすよう、ネットワークデータセンターの複数の相互接続資産にアクセスすることと、を含み、ネットワークデータセンターは、複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含み、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連し、ネットワークデータセンター内にある複数の相互接続資産は、ネットワークデータセンターのスイッチングファブリックを通って、クラウドベースのサービス交換の複数の顧客と関連するネットワークの各々を、クラウドサービスプロバイダと関連するネットワークのうちの一つ以上に接続し、複数の相互接続資産は、複数の顧客と関連するネットワークの各々に対する、一つ以上の仮想回路のそれぞれの１組を含み、複数の顧客と関連するネットワークと、複数のクラウドサービスプロバイダと関連するネットワーク内から実行されるクラウドサービスとの間のネットワークデータセンター内に、ネットワーク接続性を提供する、方法。
【０３９９】
実施例２９
ソフトウェアインタフェースは、少なくとも一つの検出方法を備える、検出アプリケーションプログラミングインタフェースを備え、方法は、第２のアプリケーションによる検出方法の呼び出しに応じる検出方法によって、複数の相互接続資産の記述を返送することを、さらに含む、実施例２８に記載の方法。
【０４００】
実施例３０
ソフトウェアインタフェースは、少なくとも一つの処理方法を備える、処理アプリケーションプログラミングインタフェースを備え、方法は、第２のアプリケーションによる処理方法の呼び出しに応じる処理方法によって、仮想回路のうちの一つをプロビジョニングすることと、仮想回路のうちの一つを検証することと、仮想回路のうちの一つの削除を確認することとを、さらに含む、実施例２８〜２９のいずれかに記載の方法。
【０４０１】
実施例３１
ソフトウェアインタフェースは、少なくとも一つの使用方法を備える、使用アプリケーションプログラミングインタフェースを備え、方法は、アプリケーションによる使用方法の呼び出しに応じる使用方法によって、クラウドサービスに推奨される設定情報、並びにクラウドサービスに関する競合他社の存在、クラウドサービスの存在、クラウドサービスの可用性、顧客の存在、顧客の獲得可能性、及び稼働率統計に関するカスタマイズされた分析のうちの一つを返送することをさらに含む、実施例２８〜３０のいずれかに記載の方法。
【０４０２】
実施例３２
ソフトウェアインタフェースは、少なくとも一つの支援方法を備える、支援アプリケーションプログラミングインタフェースを備え、方法は、第２のアプリケーションによる支援方法の呼び出しに応じる支援方法によって、アカウントの管理のうちの少なくとも一つを実施することと、顧客に請求書を送付することと、顧客のクレジットを検証することと、アプリケーションと関連するエンティティのプロファイルを構成することと、アプリケーションと関連するエンティティのポリシーを構成することと、をさらに含む、実施例２８〜３１のいずれかに記載の方法。
【０４０３】
実施例３３
第２のアプリケーションは、顧客と関連するアプリケーションのうちの一つと、一つ以上のクラウドサービスプロバイダのうちの一つのクラウドサービスプロバイダと関連するアプリケーションと、を備える、実施例２９〜３２のいずれかに記載の方法。
【０４０４】
実施例３４
ソフトウェアインタフェースは、アプリケーションプログラミングインタフェースを備え、顧客と関連するネットワークのいずれか内で実行されるアプリケーションによって発行される要求を受信することは、アプリケーションプログラミングインタフェースの方法に対して、方法の呼び出しを受信することを含む、実施例２８に記載の方法。
【０４０５】
実施例３５
ソフトウェアインタフェースは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴｆｕｌ）インタフェースを備え、要求は、複数の相互接続資産のうちの一つの相互接続資産に対する、インタフェース方法及びリソース識別子を指定する、アプリケーションデータを備える、実施例２８〜３４のいずれかに記載の方法。
【０４０６】
実施例３６
複数の相互接続資産は、ポート、場所、注文、クラウドサービス、仮想回路の帯域幅、及び仮想回路のうちの少なくとも一つをさらに含む、実施例２８〜３５のいずれかに記載の方法。
【０４０７】
実施例３７
相互接続プラットフォームは、アプリケーションプログラミングインタフェースゲートウェイを備え、要求を受信することは、要求を受信するように、ソフトウェアインタフェースを実行することを含み、方法は、要求に含まれるセキュリティ認証情報に基づいて、顧客を検証することをさらに含む、実施例２８〜３６のいずれかに記載の方法。
【０４０８】
実施例３８
相互接続プラットフォームは、アプリケーションプログラミングインタフェースゲートウェイを備え、要求を受信することは、要求を受信するように、ソフトウェアインタフェースを実行することを含み、方法は、アプリケーションプログラミングインタフェースゲートウェイによって、要求を満たすよう、複数の相互接続資産にアクセスするように、クラウドエクスチェンジプラットフォームサービスを呼び出すことと、クラウドエクスチェンジプラットフォームサービスからのアプリケーションプログラミングインタフェースゲートウェイによって、応答を受信することと、顧客と関連するネットワークのいずれか内で実行されるアプリケーションへの、アプリケーションプログラミングインタフェースゲートウェイによって、応答の表示を送信することと、をさらに含む、実施例２８〜３６のいずれかに記載の方法。
【０４０９】
実施例３９
相互接続プラットフォームの少なくとも一つのサブシステムによって、複数のクラウドエクスチェンジサービスを実行することであって、複数のクラウドエクスチェンジサービスの各クラウドエクスチェンジサービスが、仮想回路のプロビジョニングタスクを実施するように構成される、ことと、相互接続プラットフォームのオーケストレーションエンジンによって、要求を満たすようにワークフローに従って複数のクラウドエクスチェンジサービスを調整することと、をさらに含む、実施例２８〜３６のいずれかに記載の方法。
【０４１０】
実施例４０
オーケストレーションエンジンによって、要求、並びにポリシー及びクラウドサービスプロファイルのうちの少なくとも一つに、ワークフロー及びルールエンジンを適用することによって、ワークフローを生成することを、さらに含み、ワークフローは、複数のクラウドエクスチェンジサービスの一連の要求を備える、実施例３９に記載の方法。
【０４１１】
実施例４１
相互接続プラットフォームのアプリケーションプログラミングインタフェースゲートウェイによって、要求に少なくとも基づいて、オーケストレーションエンジンを呼び出す、実施例３９に記載の方法。
【０４１２】
実施例４２
要求を満たすよう複数の相互接続資産にアクセスするために、相互接続プラットフォームは、仮想回路のうちの一つをプロビジョニングする、実施例２８に記載の方法。
【０４１３】
実施例４３
相互接続プラットフォームは、クラウドサービスのクエリサービスと、オーケストレーションエンジンと、要求の受信に応じて、クラウドサービスの記述を取得するよう、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、を備え、オーケストレーションエンジンは、クラウドサービスのクエリサービスを呼び出すように、ワークフローを生成及び実行し、クラウドサービスのクエリサービスは、オーケストレーションエンジンに、クラウドサービスの記述を返送し、オーケストレーションエンジンは、アプリケーションプログラミングインタフェースゲートウェイに、クラウドサービスの記述を返送し、要求に応答して、アプリケーションプログラミングインタフェースゲートウェイは、顧客と関連するネットワークのいずれか内で実行されるアプリケーションに、クラウドサービスの記述を返送する、実施例２８〜３６のいずれかに記載の方法。
【０４１４】
実施例４４
相互接続プラットフォームは、仮想回路のクエリサービスと、オーケストレーションエンジンと、要求の受信に応じて、仮想回路の記述を取得するよう、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、オーケストレーションエンジンは、仮想回路のクエリサービスを呼び出すように、ワークフローを生成及び実行し、仮想回路のクエリサービスは、オーケストレーションエンジンに、仮想回路の記述を返送し、オーケストレーションエンジンは、アプリケーションプログラミングインタフェースゲートウェイに、仮想回路の記述を返送し、要求に応答して、アプリケーションプログラミングインタフェースゲートウェイは、顧客と関連するネットワークのいずれか内で実行されるアプリケーションに、仮想回路の記述を返送する、実施例２８〜３６のいずれかに記載の方法。
【０４１５】
実施例４５
要求は、顧客にクラウドサービスへのアクセスを提供するように、仮想回路をプロビジョニングする要求を備え、相互接続プラットフォームは、ネットワークサービスのプロビジョニングサービスと、オーケストレーションエンジンと、要求の受信に応じて、仮想回路をプロビジョニングするよう、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、オーケストレーションエンジンは、ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行し、ネットワークサービスのプロビジョニングサービスは、要求のパラメータに従って仮想回路を確立する、実施例２８〜３６のいずれかに記載の方法。
【０４１６】
実施例４６
相互接続プラットフォームは、クラウドサービスプロバイダ統合サービスをさらに備え、オーケストレーションエンジンは、一つ以上のクラウドサービスプロバイダのうちの一つのクラウドサービスプロバイダによる、仮想回路の確認を要求するよう、クラウドサービスプロバイダ統合サービスを呼び出すように、ワークフローを生成及び実行し、オーケストレーションエンジンは、クラウドサービスプロバイダによる仮想回路の確認の受信に応答する、ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行する、実施例４５に記載の方法。
【０４１７】
実施例４７
要求のパラメータは、ポートのうちの買い手のポート、及びポートのうちの売り手のポートを指定し、相互接続プラットフォームは、ポートのサービスをさらに備え、オーケストレーションエンジンは、買い手のポート及び売り手のポートを検証するよう、ポートのサービスを呼び出すように、ワークフローを生成及び実行し、オーケストレーションエンジンは、買い手のポート及び売り手のポートの検証の受信に応答する、ネットワークサービスのプロビジョニングサービスを呼び出すように、ワークフローを生成及び実行する、実施例４６に記載の方法。
【０４１８】
実施例４８
要求のパラメータは、仮想回路の帯域幅を指定し、要求のパラメータに従って仮想回路を確立するために、ネットワークサービスのプロビジョニングサービスは、仮想回路の帯域幅を有する仮想回路を確立する、実施例４５に記載の方法。
【０４１９】
実施例４９
顧客は、ネットワークサービスプロバイダ及び企業のうちの一つを備える、実施例２８〜４８に記載の方法。
【０４２０】
実施例５０
複数のネットワークの各々は、パブリックにアドレス指定可能で、異なるパブリックネットワークのアドレス空間を有する、実施例２８〜４９のいずれかに記載の方法。
【０４２１】
実施例５１
クラウドベースのサービス交換の顧客を、一つ以上のクラウドサービスプロバイダに接続するように構成される、複数の相互接続資産であって、顧客が一つ以上のクラウドサービスプロバイダからクラウドサービスにアクセスする仮想回路を含む、複数の相互接続資産と、複数の相互接続資産を修正するように構成される、オーケストレーションエンジンと、を備える、クラウドベースのサービス交換。
【０４２２】
実施例５２
複数のクラウドエクスチェンジサービスを実行するように構成される、少なくとも一つのサブシステムを、さらに備え、複数のクラウドエクスチェンジサービスの各クラウドエクスチェンジサービスが、仮想回路のプロビジョニングタスクを実施するように構成され、複数の相互接続資産を修正するために、オーケストレーションエンジンが、要求を満たすようにワークフローに従って、複数のクラウドエクスチェンジサービスを調整するように構成される、実施例５１に記載のクラウドベースのサービス交換。
【０４２３】
実施例５３
オーケストレーションエンジンは、要求に、並びにポリシー及びクラウドサービスプロファイルのうちの少なくとも一つに、ワークフロー及びルールエンジンを適用することによって、ワークフローを生成するように構成され、ワークフローは、複数のクラウドエクスチェンジサービスの一連の要求を備える、実施例５２に記載のクラウドベースのサービス交換。
【０４２４】
実施例５４
顧客と関連するアプリケーションによって発行される要求の受信に応じて、要求を満たすよう複数の相互接続資産にアクセスするように構成される、ソフトウェアインタフェースを有する、相互接続プラットフォームと、要求に少なくとも基づいて、オーケストレーションエンジンを呼び出すように構成される、アプリケーションプログラミングインタフェースゲートウェイと、をさらに備え、複数の相互接続資産を修正するために、オーケストレーションエンジンは、オーケストレーションを呼び出すアプリケーションプログラミングインタフェースゲートウェイに応じて、複数の相互接続資産を修正するように構成される、実施例５１〜５３のいずれかに記載のクラウドベースのサービス交換。
【０４２５】
実施例５５
実行されるとき、一つ以上のプロセッサに、実施例２８〜５０に記載の方法のうちのいずれかを実施させる、命令を備える、コンピュータで読み取り可能な記憶媒体。
【０４２６】
実施例５６
実施例２８〜５０のうちのいずれかに記載の方法を実施するための手段を備える、ネットワークデータセンター。
【０４２７】
実施例５７
実施例２８〜５０のうちのいずれかに記載の方法を実施するように構成される、デバイス。
【０４２８】
実施例５８
実施例２８〜５０のいずれかに記載の方法を実施するための手段を備える、デバイス。
【０４２９】
実施例５９
クラウドベースのサービス交換のオーケストレーションエンジンによって、クラウドベースのサービス交換によって提供される、クラウドエクスチェンジサービスに対するクライアント要求の指標を受信することと、オーケストレーションエンジンによって、クラウドエクスチェンジサービスを提供するワークフローを選択することであって、ワークフローが、クラウドエクスチェンジサービスのクライアント要求を遂行するように実施される１組のタスクを指定する、ことと、オーケストレーションエンジンによって、選択されるワークフローによって指定される通りの、１組のタスクの中からタスクを実施するように、一つ以上のマイクロサービスを呼ぶことと、オーケストレーションエンジンによって、タスクを実施した後に、マイクロサービスから受信する応答を連結することと、オーケストレーションエンジンによって、連結された応答に基づいて、クラウドエクスチェンジサービスのクライアント要求に対する応答を送信することと、を含む、方法。
【０４３０】
実施例６０
クライアント要求の指標を受信することは、クラウドベースのサービス交換において設置される顧客ネットワークと、クラウドベースのサービス交換において設置されるクラウドサービスプロバイダネットワークとの間で、クラウドサービスのデータを交換するため、仮想回路をプロビジョニングするように、クライアント要求の指標を受信することを含み、ワークフローを選択することは、仮想回路をプロビジョニングするために、ワークフローを選択することを含み、仮想回路をプロビジョニングするワークフローは、（ｉ）ポートの詳細を取得することと、（ｉｉ）大都市の詳細を取得することと、（ｉｉｉ）ポートの詳細及び大都市の詳細に基づいて、仮想回路を作成することと、を備える１組のタスクを指定する、実施例５９に記載の方法。
【０４３１】
実施例６１
オーケストレーションエンジンは、タスクを実施するよう、一つ以上のマイクロサービスにアクセスするように、複数のワークフロー実行ツールスレッドにわたって、１組のタスクの中からタスクを配信する、実施例５９〜６０のいずれかに記載の方法。
【０４３２】
実施例６２
オーケストレーションエンジンは、クラウドベースのサービス交換のネットワークデータセンター内の一つ以上の管理デバイス上で実行され、ネットワークデータセンターは、複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含み、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連する、実施例５９〜６１のいずれかに記載の方法。
【０４３３】
実施例６３
一つ以上のマイクロサービスの各マイクロサービスは、エンドポイントを介して到達可能な、対応するアプリケーションプログラミングインタフェースを備え、一つ以上のマイクロサービスを呼ぶことは、オーケストレーションエンジンによって、アプリケーションデータをマイクロサービス用のエンドポイントに送信することを含む、実施例５９〜６２のいずれかに記載の方法。
【０４３４】
実施例６４
アプリケーションデータは、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ及びＪａｖａ（登録商標）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎのうちの一つを使用して、符号化されるアプリケーションデータを備える、実施例６３に記載の方法。
【０４３５】
実施例６５
クライアント要求の指標を受信することは、クラウドベースのサービス交換において設置される顧客ネットワークと、クラウドベースのサービス交換において設置されるクラウドサービスプロバイダネットワークとの間で、クラウドサービスのデータを交換するため、クラウドベースのサービス交換において仮想回路をプロビジョニングするように、クライアント要求の指標を受信することを含み、仮想回路をプロビジョニングすることは、オーケストレータエンジンによって、指標の中で識別されるクラウドサービスプロバイダネットワークのクラウドサービスプロバイダを検証するように、マイクロサービスのうちの第１のマイクロサービスを呼び出すことと、顧客ネットワークに対するクラウドエクスチェンジの第１のポート、及びクラウドサービスプロバイダネットワークに対するクラウドエクスチェンジの第２のポートを検証するように、マイクロサービスのうちの第２のマイクロサービスを呼び出すことと、クラウドエクスチェンジの第１のポートと、クラウドエクスチェンジの第２のポートとの間に仮想回路を作成するよう、クラウドベースのサービス交換を構成するように、マイクロサービスのうちの第３のマイクロサービスを呼び出すことと、を含む、実施例５９〜６４のいずれかに記載の方法。
【０４３６】
実施例６６
仮想回路は、エンドツーエンドレイヤ１経路及びイーサネット（登録商標）仮想回路のうちの一つを備える、実施例５９〜６５のいずれかに記載の方法。
【０４３７】
実施例６７
オーケストレーションエンジンによって、一つ以上のマイクロサービスのうちの第１のマイクロサービスが、オーケストレーションエンジンによって送信された要求を遂行するのに失敗したと判定するのに応じて、第１のマイクロサービスで要求を再試行するか否かを判定することと、オーケストレーションエンジンによって、第１のマイクロサービスで要求を再試行することを判定するのに応じて、第１のマイクロサービスに要求を送信することと、オーケストレーションエンジンによって、第１のマイクロサービスで要求を再試行しないことを判定するのに応じて、要求を実行するように、一つ以上のマイクロサービスのうちの第２のマイクロサービスを識別し、第２のマイクロサービスに要求を送信することと、をさらに含む、実施例５９〜６５のいずれかに記載の方法。
【０４３８】
実施例６８
オーケストレーションエンジンは、クラウドベースのサービス交換において設置され、それぞれの顧客と関連する、複数のネットワークによって到達可能なソフトウェアインタフェースによって、クライアント要求の指標を受信する、実施例５９〜６７のいずれかに記載の方法。
【０４３９】
実施例６９
クライアント要求の指標を受信することは、クラウドベースのサービス交換において設置される顧客ネットワークと、クラウドベースのサービス交換において設置されるクラウドサービスプロバイダネットワークとの間で、クラウドサービスのデータを交換するため、クラウドベースのサービス交換において仮想回路を見るように、クライアント要求の指標を受信することを含み、仮想回路を見るようにクライアント要求を満たすことは、オーケストレータエンジンによって、指標の中で識別される仮想回路の要求パラメータを検証するように、マイクロサービスのうちの第１のマイクロサービスを呼び出すことと、仮想回路を記述するデータを取得するよう、仮想回路に問い合わせるように、マイクロサービスのうちの第２のマイクロサービス呼び出すことと、第２のマイクロサービスから、仮想回路を記述するデータを受信することと、仮想回路を記述するデータを含むクライアント要求に対する応答を出力することと、を含む、実施例５９〜６８のいずれかに記載の方法。
【０４４０】
実施例７０
ワークフローを選択することは、オーケストレーションエンジンによって、クライアント要求を発行したクライアントを判定することと、クライアントと関連するプロファイルに基づいてワークフローを選択することと、を含む、実施例５９に記載の方法。
【０４４１】
実施例７１
クラウドベースのサービス交換の少なくとも一つの顧客を、複数のクラウドサービスプロバイダに接続するように構成される、複数の相互接続資産と、クラウドベースのサービス交換によって提供される、クラウドエクスチェンジサービスに対するクライアント要求の指標を受信することと、クラウドエクスチェンジサービスを提供するワークフローを選択することであって、ワークフローが、クラウドエクスチェンジサービスのクライアント要求を遂行するように実施される１組のタスクを指定する、ことと、選択されるワークフローによって指定される通りの、１組のタスクの中からタスクを実施するように、一つ以上のマイクロサービスを呼ぶことと、タスクを実施した後に、マイクロサービスから受信する応答を連結することと、連結された応答に基づいて、クラウドエクスチェンジサービスのクライアント要求に対する応答を送信することとによって、複数の相互接続資産を修正するように構成される、オーケストレーションエンジンとを、備える、クラウドベースのサービス交換。
【０４４２】
実施例７２
【０４４３】
クライアント要求の指標は、クラウドベースのサービス交換において設置される顧客ネットワークと、クラウドベースのサービス交換において設置されるクラウドサービスプロバイダネットワークとの間で、クラウドサービスのデータを交換するために、仮想回路をプロビジョニングする、クライアント要求の指標を備え、ワークフローを選択するために、オーケストレーションエンジンは、仮想回路をプロビジョニングするために、ワークフローを選択するように構成され、仮想回路をプロビジョニングするワークフローは、（ｉ）ポートの詳細を取得することと、（ｉｉ）大都市の詳細を取得することと、（ｉｉｉ）ポートの詳細及び大都市の詳細に基づいて、仮想回路を作成するように、相互接続資産を構成することと、を備える、１組のタスクを指定する、実施例７１に記載のクラウドベースのサービス交換。
【０４４４】
実施例７３
オーケストレーションエンジンは、タスクを実施するよう、一つ以上のマイクロサービスにアクセスするように、複数のワークフロー実行ツールスレッドにわたって、１組のタスクの中からタスクを配信するように構成される、実施例７１に記載のクラウドベースのサービス交換。
【０４４５】
実施例７４
オーケストレーションエンジンは、クラウドベースのサービス交換のネットワークデータセンター内の一つ以上の管理デバイス上で実行されるように構成され、ネットワークデータセンターは、複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含み、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連する、実施例７１に記載のクラウドベースのサービス交換。
【０４４６】
実施例７５
一つ以上のマイクロサービスの各マイクロサービスは、エンドポイントを介して到達可能な、対応するアプリケーションプログラミングインタフェースを備え、一つ以上のマイクロサービスを呼ぶために、オーケストレーションエンジンは、アプリケーションデータをマイクロサービス用のエンドポイントに送信するように構成される、実施例７１に記載のクラウドベースのサービス交換。
【０４４７】
実施例７６
クライアント要求の指標を受信することは、クラウドベースのサービス交換において設置される顧客ネットワークと、クラウドベースのサービス交換において設置されるクラウドサービスプロバイダネットワークとの間で、クラウドサービスのデータを交換するため、クラウドベースのサービス交換において仮想回路をプロビジョニングする、クライアント要求の指標を含み、仮想回路をプロビジョニングするために、オーケストレータエンジンは、指標の中で識別されるクラウドサービスプロバイダネットワークのクラウドサービスプロバイダを検証するように、マイクロサービスのうちの第１のマイクロサービスを呼び出し、顧客ネットワークに対するクラウドエクスチェンジの第１のポート、及びクラウドサービスプロバイダネットワークに対するクラウドエクスチェンジの第２のポートを検証するように、マイクロサービスのうちの第２のマイクロサービスを呼び出し、クラウドエクスチェンジの第１のポートと、クラウドエクスチェンジの第２のポートとの間に仮想回路を作成するよう、クラウドベースのサービス交換を構成するように、マイクロサービスのうちの第３のマイクロサービスを呼び出すように構成される、実施例７１に記載のクラウドベースのサービス交換。
【０４４８】
実施例７７
仮想回路は、エンドツーエンドレイヤ１経路及びイーサネット（登録商標）仮想回路のうちの一つを備える、実施例７６に記載のクラウドベースのサービス交換。
【０４４９】
実施例７８
複数のネットワークが、ネットワークデータセンターに接続する、それぞれのポートを含む、ネットワークデータセンターであって、ネットワークの各々は、異なるネットワークアドレス空間を有し、複数の顧客又はクラウドサービスプロバイダのうちの異なる一つと関連する、ネットワークデータセンターと、ネットワークデータセンター内にあり、ネットワークデータセンターのスイッチングファブリックを通って、クラウドベースのサービス交換の複数の顧客と関連するネットワークの各々を、クラウドサービスプロバイダと関連するネットワークのうちの一つ以上に接続するように構成される、複数の相互接続資産であって、複数の顧客と関連するネットワークの各々に対する、一つ以上の仮想回路のそれぞれの１組を含み、複数の顧客と関連するネットワークと、複数のクラウドサービスプロバイダと関連するネットワーク内から実行されるクラウドサービスとの間のネットワークデータセンター内に、ネットワーク接続性を提供する、複数の相互接続資産と、ネットワークデータセンター内の一つ以上の管理デバイスによる実行のために構成される、相互接続プラットフォームであって、オーケストレーションエンジンに、仮想回路を管理するよう、複数のマイクロサービスを呼び出させる、少なくとも一つのワークフローを実行するように構成される、オーケストレーションエンジンと、複数の顧客と関連するネットワークによって到達可能で、クライアント要求の受信に応じて、オーケストレーションエンジンに、少なくとも一つのワークフローを実行するように指図するように構成される、ソフトウェアインタフェースとを備える、相互接続プラットフォームと、を備える、クラウドベースのサービス交換。
【０４５０】
実施例７９
複数のマイクロサービスを開発及び実行するために、マイクロサービスプラットフォームを実行するように構成される、一つ以上のプログラム可能なプロセッサを備え、マイクロサービスの各マイクロサービスは、マイクロサービス用のインタフェースに対して、インタフェースコントラクトを遂行するよう、一つ以上の機能を実行するように構成される、独立して配備可能なサービスを備え、一つ以上のプログラム可能なプロセッサは、マイクロサービスをベースとするアプリケーションを実行するよう、マイクロサービスを調整する、オーケストレータを開発及び実行するために、オーケストレーションプラットフォームを実行するように構成される、アプリケーション開発フレームワークシステム。
【０４５１】
実施例８０
マイクロサービスプラットフォームは、複数のマイクロサービスのうちの一つのマイクロサービスのために、インタフェースコントラクトをマイクロサービスに対して定義する、マイクロサービス定義に少なくとも基づいて、マイクロサービスのサービスインフラのスキャフォールディングを生成するように構成される、実施例７９に記載のアプリケーション開発フレームワークシステム。
【０４５２】
実施例８１
サービスインフラのスキャフォールディングは、少なくとも一つのコントローラ、ルータ、少なくとも一つの実装ファイル、マイクロサービス定義によって定義される各モデルスキーマのモデル、サンプルデータ、及び検証ファイルのうちの一つ以上を備える、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５３】
実施例８２
サービスインフラのスキャフォールディングは、少なくとも一つのコントローラ及びルータを備え、ルータが、マイクロサービス用のインタフェースを呼び出す要求を受信し、要求に基づいて、要求の処理を行うよう、少なくとも一つのコントローラのうちの一つのコントローラを判定するように構成される、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５４】
実施例８３
マイクロサービスプラットフォームは、マイクロサービス定義に基づいて、マイクロサービスに対して実行可能なコードを生成する、コード生成ツールを備える、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５５】
実施例８４
マイクロサービスプラットフォームは、インタフェースコントラクトに基づいて、インタフェースコントラクトを記述する、ユーザが読み取り可能なデータを生成し、ユーザインタフェースデバイスによって、ユーザが読み取り可能なデータの表示を出力する、アプリケーションプログラミングインタフェース（ＡＰＩ）文書化エンジンを備える、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５６】
実施例８５
マイクロサービスプラットフォームは、マイクロサービスに対してログ情報を集約するログアグリゲータを備える、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５７】
実施例８６
マイクロサービスプラットフォームは、プロセス監視を備える、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５８】
実施例８７
マイクロサービスプラットフォームは、アプリケーションプログラミングインタフェース（ＡＰＩ）のフレームワークを備える、実施例８０に記載のアプリケーション開発フレームワークシステム。
【０４５９】
実施例８８
ＡＰＩのフレームワークは、イベント駆動型アーキテクチャ及びノンブロッキングI／OのＡＰＩを提供する、実施例７９に記載のアプリケーション開発フレームワークシステム。
【０４６０】
実施例８９
マイクロサービスプラットフォームは、複数のマイクロサービスのうちの一つのマイクロサービスのために、インタフェースコントラクトをマイクロサービスに対して定義する、マイクロサービス定義に少なくとも基づいて、マイクロサービスが永続動作を実施するのに用いる、外部データベースのコネクタを生成するように構成される、実施例７９に記載のアプリケーション開発フレームワーク。
【０４６１】
実施例９０
オーケストレーションプラットフォームは、マイクロサービスに対してそれぞれのインタフェースコントラクトを定義する、それぞれのマイクロサービス定義に少なくとも基づいて、オーケストレータに対するサービスインフラのスキャフォールディングを生成するように構成される、実施例７９に記載のアプリケーション開発フレームワークシステム。
【０４６２】
実施例９１
サービスインフラのスキャフォールディングは、マイクロサービス用の少なくとも一つのコントローラ、ルータ、及び少なくとも一つのワークフローのうちの一つ以上を備える、実施例９０に記載のアプリケーション開発フレームワークシステム。
【０４６３】
実施例９２
オーケストレーションプラットフォームは、マイクロサービスへ要求をルーティングするよう、利用可能なマイクロサービスを検出するように構成される、サービス検出エンジンを備える、実施例９０に記載のアプリケーション開発フレームワークシステム。
【０４６４】
実施例９３
オーケストレーションプラットフォームは、オーケストレータに対してインタフェースを定義するインタフェースコントラクトに基づいて、インタフェースコントラクトを記述する、ユーザが読み取り可能なデータを生成し、ユーザインタフェースデバイスによって、表示用にユーザが読み取り可能なデータを出力するように、アプリケーションプログラミングインタフェース（ＡＰＩ）文書化エンジンを備える、実施例９０に記載のアプリケーション開発フレームワークシステム。
【０４６５】
実施例９４
オーケストレーションプラットフォームは、マイクロサービス定義に基づいて、オーケストレータに対して実行可能なコードを生成するように、コード生成ツールを備える、実施例９０に記載のアプリケーション開発フレームワークシステム。
【０４６６】
実施例９５
オーケストレータは、複数のマイクロサービスを呼び出し、複数のマイクロサービスからそれぞれの応答を受信し、オーケストレーションプラットフォームは、応答を集約し、オーケストレータによって受信される要求への均一な応答を提示するように、応答アグリゲータを備える、実施例９０に記載のアプリケーション開発フレームワークシステム。
【０４６７】
実施例９６
複数のマイクロサービスを開発及び実行するために、マイクロサービスプラットフォームを実行するように構成される、一つ以上のプログラム可能なプロセッサを備え、マイクロサービスの各マイクロサービスは、マイクロサービス用のインタフェースに対して、インタフェースコントラクトを遂行するよう、一つ以上の機能を実行するように構成される、独立して配備可能なサービスを備え、一つ以上のプログラム可能なプロセッサは、一つ以上の仮想回路を使用して、クラウドベースのサービス交換の顧客を相互接続するように構成される、クラウドベースのサービス交換に対して、相互接続プラットフォームを実行するよう、マイクロサービスを調整するオーケストレータを開発及び実行するために、オーケストレーションプラットフォームを実行するように構成される、アプリケーション開発フレームワークシステム。
【０４６８】
実施例９７
マイクロサービスは、クラウドベースのサービス交換の企業の顧客及びクラウドベースのサービス交換のクラウドサービスプロバイダの顧客を相互接続するように、仮想回路を作成及び管理するマイクロサービスを備える、実施例９６に記載のアプリケーション開発フレームワークシステム。
【０４６９】
実施例９８
マイクロサービスは、仮想回路のマイクロサービス、ポートのマイクロサービス、リンク集約グループのマイクロサービス、大都市のマイクロサービス、クラウドサービスプロバイダ詳細のマイクロサービス、サービス品質のマイクロサービス、顧客サービス及びチケット発行のマイクロサービス、検索のマイクロサービス、資産及びネットワークインベントリのマイクロサービス、言語のマイクロサービス、並びにサービス設定のマイクロサービスのうちの一つ以上を備える、実施例９７に記載のアプリケーション開発フレームワークシステム。
【０４７０】
実施例９９
オーケストレーションエンジンは、相互接続プラットフォームによって提供されるサービスを遂行するように、ワークフローを調整する、実施例９７に記載のアプリケーション開発フレームワークシステム。
【０４７１】
実施例１００
サービスは、ポート管理サービス、大都市管理サービス、クラウドサービスプロバイダ詳細サービス、注文管理サービス、仮想回路閲覧サービス、仮想回路削除サービス、検索サービス、ネットワークサービスプロバイダサービス、クラウドサービスプロバイダ構成サービス、支援及びチケットサービス、監視及び統計サービス、並びに分析及び推奨サービスのうちの一つ以上を備える、実施例９９に記載のアプリケーション開発フレームワークシステム。
【０４７２】
実施例１０１
サービスは、一つ以上のＡＰＩゲートウェイのＡＰＩに相当する、実施例９９に記載のアプリケーション開発フレームワークシステム。
【０４７３】
実施例１０２
実行環境による実行のためにアプリケーション開発フレームワークを構成することと、アプリケーションプログラミングインタフェース（ＡＰＩ）サーバを作成することと、少なくとも一つの定義ファイルを編集することであって、少なくとも一つの定義ファイルの各々が、オーケストレータに対してインタフェースを定義する、ことと、アプリケーション開発フレームワークを使用して、一つ以上のマイクロサービスを含む、マイクロサービスをベースとするアプリケーションに対してサービスインフラを生成するように、少なくとも一つの定義ファイルの処理を行うことと、ＡＰＩサーバによって、マイクロサービスをベースとするアプリケーションを実行することと、を含む、方法。
【０４７４】
実施例１０３
一つ以上のマイクロサービスの各々に対して、１組のＡＰＩのエンドポイントを実装することと、ワークフローを定義することとを、さらに含み、オーケストレータが、一つ以上のマイクロサービスの各々に対して、ＡＰＩのエンドポイントのそれぞれの組を呼び出すことによって、ＡＰＩサーバが受信する要求を遂行するように、一つ以上のマイクロサービスを調整するワークフローを実行する、実施例１０２に記載の方法。
【０４７５】
実施例１０４
ワークフローを定義することを、さらに含み、オーケストレータが、ＡＰＩサーバによって受信される要求を遂行するように、一つ以上のマイクロサービスを調整するワークフローを実行する、実施例１０２に記載の方法。
【０４７６】
実施例１０５
マイクロサービスをベースとするアプリケーションは、クラウドベースのサービス交換用の相互接続プラットフォームを備える、実施例１０２に記載の方法。
【０４７７】
その上、上に記載する実施例のいずれかに説明する、特定の特徴のうちのいずれも、記載する技術の有益な実施例の中に組み合わされてもよい。すなわち、特定の特徴のいずれも、概して、本発明の全ての実施例に適用可能である。本発明の様々な実施例について記載してきた。
【０４７８】
様々な実施形態について記載してきた。これらの及びその他の実施形態は、以下の実施例の範囲内である。
【符号の説明】
【０４７９】
１００  クラウドエクスチェンジ
１０１  データセンター
１０３  相互接続プラットフォーム
１０４Ａ  回線事業者ネットワーク
１０４Ｂ  回線事業者ネットワーク
１０４Ｃ  回線事業者ネットワーク
１０４Ｄ  回線事業者ネットワーク、顧客ネットワーク
１０４Ｅ  顧客ネットワーク
１０６Ａ  ＮＳＰ、回線事業者
１０６Ｂ  ＮＳＰ、回線事業者
１０６Ｃ  回線事業者
１０６Ｄ  回線事業者
１０７Ａ  顧客
１０７Ｂ  顧客
１０８Ａ  クラウドの顧客
１０８Ｂ  クラウドの顧客
１０８Ｃ  クラウドの顧客
１０８Ｄ  クラウドの顧客
１１０Ａ  クラウドサービスプロバイダ
１１０Ｂ  クラウドサービスプロバイダ
１１０Ｃ  クラウドサービスプロバイダ
１１０Ｄ  クラウドサービスプロバイダ
１１０Ｅ  クラウドサービスプロバイダ
１１０Ｆ  クラウドサービスプロバイダ
１１０Ｇ  クラウドサービスプロバイダ
１１０Ｈ  クラウドサービスプロバイダ
１１０Ｉ  クラウドサービスプロバイダ
１１０Ｊ  クラウドサービスプロバイダ
１１０Ｋ  クラウドサービスプロバイダ
１１０Ｌ  クラウドサービスプロバイダ
１１０Ｎ  クラウドサービスプロバイダ
１１２  ＡＰＩゲートウェイ
１１４  ソフトウェアインタフェース、ＡＰＩ
１１８  オーケストレーションエンジン
１２０  サブシステム
１２２  ネットワークインフラ
１２８Ａ  クラウドエクスチェンジポイント
１２８Ｂ  クラウドエクスチェンジポイント
１２８Ｃ  クラウドエクスチェンジポイント
１２８Ｄ  クラウドエクスチェンジポイント
１３０  アプリケーション
１５０  仮想回路
１５５  仮想回路
１６０  仮想回路
１６５  仮想回路
１７０  仮想回路
１９６  顧客システム
２０５  異なる回線事業者ネットワーク
２１０  異なる回線事業者ネットワーク
２１５  異なる回線事業者ネットワーク
２２０  異なる回線事業者ネットワーク
３００  開発者コミュニティー
３００Ａ  ネットワークサービスプロバイダ
３００Ｂ  マネージドサービスプロバイダ
３００Ｃ  企業
３００Ｄ  クラウドサービスプロバイダ
３００Ｅ  第三者開発者
３００Ｆ  その他
３０４Ａ  検出ＡＰＩ
３０４Ｂ  処理ＡＰＩ
３０４Ｃ  使用ＡＰＩ
３０４Ｄ  支援ＡＰＩ
３０６  ワークフロー及びルールエンジン
３０８Ａ  交換ポリシー
３０８Ｂ  プロファイル
３０８Ｃ  構成
３０８Ｄ  マイクロサービス構成要素
３１０Ａ  識別（ＩＤ）及びアクセス管理システム
３１０Ｂ  注文管理システム
３１０Ｃ  ネットワークサービスシステム
３１０Ｄ  資産インベントリ及び容量管理システム
３１０Ｅ  インシデント管理システム
３１０Ｆ  コンテンツ管理システム
４０２  ＡＰＩコンシューマ
４０２Ａ  買い手アプリケーション
４０２Ｂ  売り手アプリケーション
４０２Ｃ  ＡＰＩ開発者
４０３  ＡＰＩゲートウェイ
４０４  カスタムアダプタ
４０４Ａ  セキュリティ
４０４Ｂ  ＡＰＩキーの検証
４０４Ｃ  変換
４０４Ｄ  キャッシュ
４０４Ｅ  脅威からの保護
４０４Ｆ  スパイクの抑制
４０４Ｇ  カスタム分析
４０４Ｈ  ＨＴＴＰコールアウト
４０６  エンドポイント、ＡＰＩコンシューマ
４０６Ａ  ログイン
４０６Ｂ  ポート
４０６Ｃ  大都市
４０６Ｄ  資産
４０６Ｅ  仮想回路
４０６Ｆ  クラウドサービス
４０６Ｇ  サービスプロファイル
４０６Ｈ  分析
４０６Ｉ  トラフィック統計
４０６Ｊ  帯域幅
４０６Ｋ  サービスチケット
４０６Ｌ  推奨事項
４０７  相互接続オーケストレーションエンジン
４０８  プラットフォームサービス
４０８Ａ  ポリシー管理
４０８Ｂ  プロファイル及び構成
４０８Ｃ  支払請求及び請求書の送付
４０８Ｄ  売り手のＡＰＩ統合、マイクロサービス
４０８Ｅ  仮想回路管理
４０８Ｆ  ネットワークインタフェース管理
４０８Ｇ  検索及び推奨
４０８Ｈ  インベントリ及び場所検出
４０９  クラウドエクスチェンジのＡＰＩサービス、クラウドエクスチェンジサービス
４０９Ａ  要求の検証
４０９Ｂ  承認及び監査
４０９Ｃ  アカウント及びプロファイル管理
４０９Ｄ  インベントリ管理
４０９Ｅ  容量管理
４０９Ｆ  ネットワークのプロビジョニング
４０９Ｇ  信用調査検証ツール
４０９Ｈ  支払請求
４０９Ｉ  売り手のＡＰＩ統合
４０９Ｊ  場所
４０９Ｋ  トラブルチケット管理
４０９Ｌ  ローカライズ
４０９Ｍ  稼働率統計
４０９Ｎ  推奨
４０９Ｏ  スケジューラ及びバッチプロセッサ
４０９Ｐ  通知
４０９Ｑ  エラーパーサ
４０９Ｒ  コンテンツ管理
４１０  ワークフロー管理及びルーティング構成要素
４１２  エンジン
４１２Ａ  認証及び承認
４１２Ｂ  構成、監査、及び追跡
４１２Ｃ  ＡＰＩコマンドコントローラ
４１２Ｄ  ＡＰＩクエリコントローラ
４１２Ｅ  サービス合成エンジン
４１２Ｆ  注文管理エンジン
４１２Ｇ  通知エンジン
４１２Ｈ  推奨及び分析エンジン
４１２Ｉ  相互接続インタフェースエンジン
４１２Ｊ  ＡＰＩワークフロー及びルールリポジトリ
４２２Ａ  ＡＰＩクエリサービス
４２２Ｂ  ＡＰＩコマンドサービス
４２２Ｃ  統合ファサードサービス
４２４Ａ  要求パラメータ検証サービス
４２４Ｂ  クエリ提供サービス
４２４Ｃ  要求本体検証サービス
４２４Ｄ  コマンド提供サービス
４２４Ｅ  要求委譲及びサービスアダプタ
４２４Ｆ  応答解析及び変換
４２６Ａ  ＩＤ及びアクセス管理システム
４２６Ｂ  売り手のＡＰＩ統合モジュール
４２６Ｃ  ネットワークシステム
４２６Ｄ  注文管理システム
４２６Ｅ  インシデント管理システム
４２６Ｆ  コンテンツ管理システム
４２８  クラウドエクスチェンジデータベース
４５０  ＩＤ管理及び連携
４５２  パーミッションデータ記憶部
５００  コンピュータデバイス
５０２  プロセッサ、構成要素
５０４  入力デバイス、構成要素
５０６  通信部、構成要素
５０８  記憶デバイス、構成要素
５１０  ユーザインタフェースデバイス、構成要素
５１２  出力デバイス、構成要素
５１４  通信チャネル
５１６  オペレーティングシステム
５２２  アプリケーション
５２４  相互接続プラットフォームアプリケーション、仮想概念構築アプリケーション
５５０  オーケストレーションエンジンモジュール
５５２  ＡＰＩゲートウェイモジュール
５５４  サブシステム
７０６  オーケストレータ
７０８  マイクロサービス
７１０  サービス検出エンジン
７１２  プロセス管理ツール
７１３  クラウドエクスチェンジポータル
７１４  ウェブプロキシ
７１６  ＳａａＳウェブポータル
７１７  ＡＰＩ
７１８  ＡＰＩゲートウェイ
７２０  企業システム
７２２  ＡＰＩサービスフレームワーク
７２３  その他システム
７２４  第三者システム
７２６  ＡＰＩ  Ｄｏｃエンジン
７２８  ＲＥＳＴインタフェースマイクロサービス
７３０  ソケット接続
７３２  監視マイクロサービス
７３４  通知マイクロサービス
８１０  ウェブプロキシ
８１２Ａ  ブラウザ
８１２Ｂ  ブラウザ
８１４  ホワイトラベルＳａａＳポータル、クラウドエクスチェンジポータル
８１６  ＡＰＩゲートウェイ
８１７  非同期ジョブ、マイクロサービス
８１９  ユーティリティ機能、マイクロサービス
８２０  サブシステム
８２０Ａ  コンテンツ管理システム
８２０Ｂ  トラフィック管理システム
８２０Ｃ  インシデント管理システム
８２０Ｄ  ポート管理システム
８２０Ｅ  ＩＤ及びアクセス管理システム
８２０Ｆ  注文管理システム
８３２  ＳＤＮコントローラ
８４０  企業
１６１０  データ構造記憶部
１６１２  ワークフローフォルダ
１６１６Ａ  ワークフロー実行ツール
１６１６Ｂ  ワークフロー実行ツール
１６１６Ｃ  ワークフロー実行ツール
１６１６Ｄ  ワークフロー実行ツール
１６２０  出版‐購読型サーバ
１６２２  ／ｖｉｒｔｕａｌ  ｃｉｒｃｕｉｔ
１６３０Ａ  マイクロサービス
１６３０Ｂ  マイクロサービス
１６３０Ｃ  マイクロサービス
１６３０Ｄ  マイクロサービス
１６４２  ／ｅｍｐｌｏｙｅｅ  ｐａｙｒｏｌｌ
１６５０Ａ  マイクロサービス
１６５０Ｂ  マイクロサービス
１６５０Ｃ  マイクロサービス
１６５０Ｄ  マイクロサービス
１８００  データセンター
１８０１  ＩＰ／ＭＰＬＳファブリック
１８０２Ａ  ＰＥルータ、ＰＥ
１８０２Ｂ  ＰＥルータ、ＰＥ
１８０３  クラウドエクスチェンジポイント
１８０４Ａ  ＰＥルータ、ＰＥ
１８０４Ｂ  ＰＥルータ、ＰＥ
１８０８  顧客、顧客ネットワーク
１８０８Ａ  顧客ネットワーク
１８０８Ｂ  顧客ネットワーク
１８０８Ｃ  顧客ネットワーク
１８１０Ａ  ＰＥルータ、ＰＥ
１８１０Ｂ  ＰＥルータ、ＰＥ
１８１１  顧客のエッジ（ＣＥ）デバイス、ＰＥルータ
１８１２Ａ  ＰＥルータ、ＰＥ
１８１２Ｂ  ＰＥルータ、ＰＥ
１８１２Ｃ  ＰＥルータ、ＰＥ
１８１２Ｄ  ＰＥルータ、ＰＥ
１８２０Ａ  クラウドサービスプロバイダネットワーク
１８２０Ｂ  クラウドサービスプロバイダネットワーク
１９０２  チャネル
１９０２Ａ  ウェブソケット、ＶＲＦ
１９０２Ｂ  Ａｊａｘ要求、ＶＲＦ
１９０２Ｃ  ＡＰＩ
１９０２Ｄ  モノのインターネット（ＩｏＴ）
１９０２Ｅ  ＨＴＭＬ５アプリケーション
１９０４  データベース
１９０４Ａ  インメモリデータベース、ＶＲＦ
１９０４Ｂ  ＲＥＳＴｆｕｌインタフェース、ＶＲＦ
１９０４Ｃ  Ｏｒａｃｌｅ／ＳＱＬサーバ／ＳＱＬベースのデータベース、ＶＲＦ
１９０４Ｄ  ＮｏＳＱＬデータベース、ＶＲＦ
１９０６  コンテナベースのフレームワーク
１９０６Ｂ  その他のルート配信プロトコルのピアリング接続
１９０８  リポジトリ
１９０６Ｂ  その他のルート配信プロトコルのピアリング接続
１９１０  エディタ、その他のルート配信プロトコルのピアリング接続
１９２０  ＲＥＳＴｆｕｌ  ＡＰＩ
１９２２  ＡＰＩコントラクトのモデル化（「モデル」）
１９２４  通知
１９２６  その他の永続的記憶部接続性（「データ」）
１９２８  自動スキャフォールディング
１９３０  テスト駆動型開発
１９３２  ワークフローエンジン
２０００  オーケストレータプラットフォーム
２００２  サービス検出エンジン
２００４  ＡＰＩ文書化エンジン
２００６  コード生成ツール
２０１０  応答アグリゲータ
２０１２  ステートマシン
２０１４  ワークフロー実行ツール
２０１８  マイクロサービスプラットフォーム
２０２０  コード生成ツール
２０２２  ＡＰＩ文書化エンジン
２０２４  ログアグリゲータ
２０２６  プロセス監視
２０２８  通知サービス
２０３０  ＡＰＩフレームワーク
２０３２  セキュリティＣＯＲＳ検査
２０３８  プラグイン構成要素
２０４０  共通コネクタ
２０４２  ＯＲＭ
２０４４  ＡＱＵＡアダプタ
２０４６  Ａｑｕａ  ＣＬＩ
２０４８  企業システムコネクタ
２０５０  ＡＱＵＡコアモジュール
２０５２  プラグイン
２０５４  テンプレートエンジン
２０５６  イベントアグリゲータ
２２０１  マイクロサービスＡＰＩプロジェクト
２２０２  マイクロサービススキーマ
２２０３  多目的スキャフォールディングプロセス
２２０４  ルート
２２０５  コントローラ
２２０６  実装ファイル
２２０７  ワークフロープロジェクト
２２０８  Ｄｏｃｋｅｒインフラ
２２０９  オーケストレーションＡＰＩプロジェクト
２２１０  オーケストレーション／ワークフロースキーマ
２２１２  ルート
２２１３  コントローラ
２２１４  ワークフロー
２５００  インタフェース
２５００Ａ  ＰＯＳＴ動作ボタン
２５００Ｂ  ＧＥＴ動作ボタン
２５００Ｃ  ＤＥＬＥＴＥ動作ボタン
２５００Ｄ  ＰＵＴ動作ボタン
２６００Ａ  ユーザ
２６００Ｂ  ユーザ
２６００Ｃ  ユーザ
２６００Ｄ  ユーザ
２６０２  顧客ポータル
２６０４  外部ＡＰＩ
２６０６  マイクロサービスの管理
２６０８  ワークフロー管理ツール及び実行エンジン
２６１０  仮想回路
２６１２  その他のマイクロサービス
２６１４  その他のマイクロサービス
２６１８  外部のクラウドサービス
２６２０  外部のクラウドサービス
２６３０  オーケストレータ
２６３２  マイクロサービス
２８００  コンピュータデバイス
２８０２  プロセッサ、構成要素
２８０４  入力デバイス、構成要素
２８０６  通信部、構成要素
２８０８  記憶デバイス、構成要素
２８１０  ユーザインタフェース（ＵＩ）デバイス、構成要素
２８１２  出力デバイス
２８１４  通信チャネル
２８１６  オペレーティングシステム
２８  ２２  アプリケーション
２８２４  開発フレームワークアプリケーション
２８５０  ＡＰＩサーバ
２８５２  オーケストレーション開発及び実行アプリケーション
２８５４  マイクロサービス開発及び実行アプリケーション
２８５６  プラグイン
【図１Ａ】
0006495948.tif 000181
【図１Ｂ】
0006495948.tif 000182
【図１Ｃ】
0006495948.tif 000183
【図１Ｄ】
0006495948.tif 000184
【図２】
0006495948.tif 000185
【図３Ａ】
0006495948.tif 000186
【図３Ｂ】
0006495948.tif 000187
【図４】
0006495948.tif 000188
【図５】
0006495948.tif 000189
【図６】
0006495948.tif 000190
【図７】
0006495948.tif 000191
【図８】
0006495948.tif 000192
【図９】
0006495948.tif 000193
【図１０】
0006495948.tif 000194
【図１１】
0006495948.tif 000195
【図１２】
0006495948.tif 000196
【図１３】
0006495948.tif 000197
【図１４】
0006495948.tif 000198
【図１５】
0006495948.tif 000199
【図１６】
0006495948.tif 000200
【図１７】
0006495948.tif 000201
【図１８Ａ】
0006495948.tif 000202
【図１８Ｂ】
0006495948.tif 000203
【図１９】
0006495948.tif 000204
【図２０】
0006495948.tif 000205
【図２１】
0006495948.tif 000206
【図２２】
0006495948.tif 000207
【図２３】
0006495948.tif 000208
【図２４】
0006495948.tif 000209
【図２５】
0006495948.tif 000210
【図２６】
0006495948.tif 000211
【図２７】
0006495948.tif 000212
【図２８】
0006495948.tif 000213