JP2024105342A - Ａｐｉレジストリにおけるバックエンドサービスエンドポイントからａｐｉ関数へのバインディング - Google Patents

Abstract

【課題】コンテナ環境内の登録されたサービスエンドポイントに対するアプリケーションプログラミングインターフェイス（ＡＰＩ）関数を与える方法を提供する。【解決手段】方法は、ＡＰＩレジストリにおいてＡＰＩ定義のアップロードを受けるステップを含む。ＡＰＩ定義は、コンテナ環境にデプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、１つ以上のＡＰＩ関数と、を含む。方法はまた、ＡＰＩレジストリが、１つ以上のＡＰＩ関数とサービスのエンドポイントとの間のバインディングを作成するステップと、ＡＰＩレジストリが、第１のサービスの使用を求める要求を第２のサービスから受けるステップと、ＡＰＩレジストリが、１つ以上のＡＰＩ関数を第２のサービスに与えるステップと、を含む。【選択図】図７Ａ

Description

関連出願の相互参照
本願は、本明細書に引用により援用する２０１７年９月３０日出願の米国仮出願第６２／５６６，３５１号に基づく利益を主張する。本願はまた、本願と同日に出願され本願と共通の譲受人に譲渡された以下の出願に関連し、これらの出願各々も本明細書に引用により援用する。
・２０１８年９月２８日に出願されAPI REGISTRY IN A CONTAINER PLATFORM PROVIDING PROPERTY-BASED API FUNCTIONALITYと題された米国特許出願第１６／１４７，３０５号（
代理人整理番号０８８３２５－１０９０７４６）
・２０１８年９月２８日に出願されDYNAMIC NODE REBALANCING BETWEEN CONTAINER PLATFORMSと題された米国特許出願１６／１４７，３４３号（代理人整理番号０８８３２５－１０９０７４７）
・２０１８年９月２８日に出願されOPTIMIZING REDEPLOYMENT OF FUNCTIONS AND SERVICES ACROSS MULTIPLE CONTAINER PLATFORMS AND INSTALLATIONSと題された米国特許出願第
１６／１４７，３３２号（代理人整理番号０８８３２５－１０９０７４８）
・２０１８年９月２８日に出願されREAL-TIME DEBUGGING INSTANCES IN A DEPLOYED CONTAINER PLATFORMと題された米国特許出願１６／１４７，３５１号（代理人整理番号０８８３２５－１０９０７５３）

背景
理論上、任意の形態のコンテナは、情報のパッケージングおよび情報との対話のための標準化された方法を表している。コンテナは、互いに分離することが可能であり、相互汚染（コンタミネーション）のいかなるリスクも伴うことなく並列に使用することが可能である。現代のソフトウェアの世界において、「コンテナ」という用語は固有の意味を獲得している。Docker（登録商標）コンテナのようなソフトウェアコンテナは、１つのソフトウェアを論理的にカプセル化し定義するソフトウェア構造である。コンテナにカプセル化される最も一般的なタイプのソフトウェアは、アプリケーション、サービス、またはマイクロサービスである。現代のコンテナはまた、オペレーティングシステム、ライブラリ、ストレージボリューム、構成ファイル、アプリケーションバイナリ、および、典型的なコンピューティング環境において見出されるであろうテクノロジースタックのその他の部分のような、アプリケーション／サービスが動作するのに必要なソフトウェアサポートすべてを含む。そのため、このコンテナ環境を使用することにより、各々が自身のサービスを任意の環境で実行する複数のコンテナを作成することができる。コンテナは、プロダクションデータセンター、オンプレミスデータセンター、クラウドコンピューティングプラットフォームなどにおいて、いかなる変更も伴うことなくデプロイすることができる。クラウド上にコンテナを立ち上げることは、ローカルワークステーション上にコンテナを立ち上げることと同一である。

現代のサービス指向アーキテクチャおよびクラウドコンピューティングプラットフォームは、大きなタスクを多数の小さな特定のタスクに分割する。コンテナをインスタンス化することによって個々の特定のタスクに集中することができ、さらに、複数のコンテナが協働することによって高度なアプリケーションを実現することができる。これはマイクロサービスアーキテクチャと呼ばれることがあり、各コンテナは、独立してアップグレードすることが可能なさまざまなバージョンのプログラミング言語およびライブラリを使用することができる。コンテナ内の処理には分離されているという性質があるので、コンテナ
は、より大きくよりモノリシックなアーキテクチャに対して行われる変更と比較すると、手間またはリスクがほとんどない状態でアップグレードおよびリプレイスが可能である。コンテナプラットフォームを実行するために仮想マシンを使用できるが、このマイクロサービスアーキテクチャの実行において、コンテナプラットフォームは従来の仮想マシンよりも遥かに効率的である。

簡単な概要
いくつかの実施形態において、コンテナ環境内の登録されたサービスエンドポイントに対するアプリケーションプログラミングインターフェイス（Application Programming Interface）（ＡＰＩ）関数を与える方法は、ＡＰＩレジストリにおいて、コンテナ環境に
デプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、１つ以上のＡＰＩ関数とを含み得る、ＡＰＩ定義を受けるステップを含み得る。この方法はまた、ＡＰＩレジストリが、１つ以上のＡＰＩ関数とサービスのエンドポイントとの間のバインディングを作成するステップと、ＡＰＩレジストリが、第１のサービスの使用を求める要求を第２のサービスから受けるステップと、ＡＰＩレジストリが、１つ以上のＡＰＩ関数を第２のサービスに与えるステップとを含み得る。

いくつかの実施形態において、１つ以上のプロセッサによって実行されると当該１つ以上のプロセッサに動作を実行させる命令を含み得る非一時的なコンピュータ読取可能媒体において、当該動作は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、１つ以上のＡＰＩ関数とを含み得る、ＡＰＩ定義を受けることを含み得る。上記動作はまた、ＡＰＩレジストリが、１つ以上のＡＰＩ関数とサービスのエンドポイントとの間のバインディングを作成することと、ＡＰＩレジストリが、第１のサービスの使用を求める要求を第２のサービスから受けることと、ＡＰＩレジストリが、１つ以上のＡＰＩ関数を第２のサービスに与えることとを含み得る。

いくつかの実施形態において、システムは、１つ以上のプロセッサと、１つ以上のメモリデバイスとを含み得る。１つ以上のメモリデバイスは、１つ以上のプロセッサによって実行されると当該１つ以上のプロセッサに動作を実行させる命令を含み、当該動作は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、１つ以上のＡＰＩ関数とを含み得る、ＡＰＩ定義を受けることを含む。上記動作はまた、ＡＰＩレジストリが、１つ以上のＡＰＩ関数とサービスのエンドポイントとの間のバインディングを作成することと、ＡＰＩレジストリが、第１のサービスの使用を求める要求を第２のサービスから受けることと、ＡＰＩレジストリが、１つ以上のＡＰＩ関数を第２のサービスに与えることとを含み得る。

いずれの実施形態にも、以下の特徴のうちのいずれかまたはすべてが、限定されることなく任意の組み合わせで含まれ得る。上記方法／動作はまた、１つ以上のＡＰＩ関数を含む第２のサービスのためのクライアントライブラリを生成することを含み得る。クライアントライブラリは、ＡＰＩ関数を実現するメンバ関数とともにオブジェクトクラスを含み得る。クライアントライブラリは、第１のサービスのエンドポイントに対するダイレクトコールを含み得る。クライアントライブラリは、１つ以上のＡＰＩ関数のうちの１つが第２のサービスによってコールされたときに第１のサービスのエンドポイントを実行時にアップデートするコードを含み得る。クライアントライブラリは、１つ以上のＡＰＩ関数の１つ以上のパラメータとして受けたデータを、第１のサービスのエンドポイントに対するＨＴＴＰコールに再フォーマットし得る。クライアントライブラリは、第１のサービスのエンドポイントのＨＴＴＰコールに加えるための追加情報を第３のサービスに要求し得る
。クライアントライブラリは、第１のサービスに対する失敗コールをリトライするコードを含み得る。クライアントライブラリは、結果値を第１のサービスの結果セットから抽出し当該結果値を１つ以上のＡＰＩ関数に対するリターン値としてパッケージングするコードを含み得る。第１のサービスのエンドポイントは、ＩＰアドレスとポート番号とを含み得る。コンテナ環境は、コンテナにカプセル化された複数のサービスを含み得る。ＡＰＩレジストリは、コンテナ環境内のコンテナにカプセル化されたサービスとしてデプロイされ得る。ＡＰＩレジストリは、統合開発環境（Integrated Development Environment）（ＩＤＥ）において開発中のサービスと、コンテナ環境において既にデプロイされているサービスとが、利用できる。上記方法／動作はまた、ＡＰＩレジストリが、コンテナ環境にデプロイされているコンテナ化されたサービスの任意の利用できるエンドポイントを識別することを含み得る。上記方法／動作はさらに、ＡＰＩレジストリに登録されたすべてのサービスに対するＡＰＩ関数のリストをユーザインターフェイスに表示させることを含み得る。第１のサービスの使用を求める第２のサービスからの要求は、ユーザインターフェイスに表示された１つ以上のＡＰＩ関数のうちの１つの選択を受けることによって受けることができる。ユーザインターフェイスはコマンドラインインターフェイスを含み得る。ユーザインターフェイスはグラフィカルユーザインターフェイスを含み得る。

本発明の性質および利点の一層の理解は、本明細書の残りの部分および図面を参照することによって実現するであろう。いくつかの図面で使用されている同様の参照番号は、同様の構成要素を示す。いくつかの例では、参照番号に添字を対応付けることにより、同様の複数の構成要素のうちの１つを示している。既存の添字を示すことなく参照番号に言及している場合は、そのような同様の複数の構成要素すべてに言及することを意図している。

いくつかの実施形態に係る、コンテナプラットフォームにおけるサービスのための開発およびランタイム環境のソフトウェア構造および論理構成を示す図である。 本明細書に記載の実施形態を実行するために特別に設計された専用コンピュータハードウェアシステムを示す図である。 本明細書に記載の実施形態のうちのいくつかで使用されるコンテナプラットフォームに固有であってもよいデータ組織を示す図である。 いくつかの実施形態に係る、ＩＤＥおよびプロダクション／ランタイム環境にデプロイすることができるＡＰＩレジストリを示す図である。 いくつかの実施形態に係る、実行時にコンテナプラットフォームとともに使用されるＡＰＩレジストリのデプロイを示す図である。 いくつかの実施形態に係る、ＡＰＩレジストリをデプロイする方法のフローチャートを示す図である。 いくつかの実施形態に係る、ＡＰＩレジストリが図６Ａのフローチャートを用いてデプロイされるときのコンテナプラットフォームのソフトウェア構造を示す図である。 いくつかの実施形態に係る、ＡＰＩレジストリにサービスを登録する方法のフローチャートを示す図である。 いくつかの実施形態に係る、ＡＰＩレジストリにＡＰＩを登録するためのステップのハードウェア／ソフトウェア図を示す。 いくつかの実施形態に係る、ＡＰＩレジストリに登録されたＡＰＩをブラウズおよび選択するためのグラフィカルインターフェイスおよびコマンドラインインターフェイスの例を示す図である。 いくつかの実施形態に係る、ＡＰＩレジストリに登録されたサービスおよびその対応する関数を使用する方法のフローチャートを示す図である。 ＡＰＩレジストリが如何にしてCreateUser( )関数の選択をグラフィカルインターフェイスを介して受けることができるかを示す図である。 いくつかの実施形態に係る、ＡＰＩレジストリがあるサービスのために自動的に生成したクライアントライブラリの一例を示す図である。 いくつかの実施形態に係る、サービスエンドポイントとＡＰＩ関数との間の動的バインディングを含むクライアントライブラリの実施形態を示す図である。 いくつかの実施形態に係る、サービスコールのための入力データセットを完成させるために追加データを配置できるクライアントライブラリの実施形態を示す図である。 いくつかの実施形態に係る、サービスをコールするときにリトライを処理することができるクライアントライブラリを示す図である。 実施形態のうちのいくつかを実現するための分散型システムの簡略化されたブロック図を示す。 実施形態の構成要素が提供するサービスをクラウドサービスとして提供し得るシステム環境の構成要素の簡略化されたブロック図を示す。 各種実施形態を実現し得る具体例としてのコンピュータシステムを示す図である。

詳細な説明
開発者が開発中にサービスを登録することを可能にするとともにデプロイ中およびデプロイ後双方においてこれらのサービスを他のサービスが利用できるようにする、統合開発環境（ＩＤＥ）の一部であるアプリケーションプログラミングインターフェイス（ＡＰＩ）レジストリの実施形態について説明する。ＡＰＩレジストリは、コンテナプラットフォーム上のコンテナ化されたアプリケーションとして動作するオーケストレーションされたコンテナプラットフォームの一部としてデプロイすることが可能である。サービスまたはマイクロサービスが開発されコンテナプラットフォーム上のコンテナにデプロイされると、ＡＰＩレジストリは、ディスカバリプロセスを実行することにより、利用できるサービスに対応するコンテナプラットフォーム内の利用できるエンドポイント（たとえばＩＰアドレスおよびポート番号）の場所を特定することができる。ＡＰＩレジストリはまた、ＡＰＩ定義ファイルのアップロードを受け入れることができ、ＡＰＩ定義ファイルは、生のサービスエンドポイントを、ＡＰＩレジストリを介して利用できるようにされるＡＰＩ関数にするために使用することができる。ＡＰＩレジストリは、発見されたエンドポイントを、最新状態に保たれコンテナプラットフォーム内の他のサービスが利用できるようにされたＡＰＩ関数に動的にバインドすることができる。これは、ＡＰＩ関数とサービスエンドポイントとの間のバインディングに対する任意の変更をＡＰＩレジストリが管理している間、他のサービスが静的にコールできる安定したエンドポイントを提供する。これはまた、コンテナプラットフォーム内のサービスを使用するプロセスを簡略化する。ＨＴＴＰコールに対するコードを記述する代わりに、新たなサービスは、ＡＰＩインターフェイスを使用するだけで、登録されたサービスにアクセスすることができる。

いくつかの実施形態において、ＩＤＥは、コンテナプラットフォーム内で利用することが可能でありＡＰＩレジストリに登録されているサービスの場所を開発者が特定するための、ナビゲーション／ブラウズインターフェイスを提供することができる。開発中の新たなサービスのために、ＡＰＩレジストリが既存のサービスにコールするとき、ＡＰＩレジストリは、登録されているサービスとのやり取りのために必要なすべての機能を含む一組のクライアントライブラリを自動的に生成することができる。たとえば、いくつかの実施形態は、ＡＰＩコールに対応するメンバ関数を含むオブジェクトクラスを生成することができる。開発中、新たなサービスは、これらのオブジェクトをインスタンス化するおよび／またはそれらのメンバ関数を使用するだけで、対応するＡＰＩにコールすることができる。クライアントライブラリにおけるコードは、呼び出し側サービスと登録されたサービ
スのエンドポイントとの間の直接接続を支配し、このやり取りに必要なすべての機能を扱うコードを含み得る。たとえば、自動的に生成されたクライアントライブラリは、ＡＰＩコールからのパラメータをサービスエンドポイントへのＨＴＴＰコールにパッケージングしフォーマットするためのコード、コールのためのパラメータセットを完成させるためにデータを配置するためのコード、情報を互換パケット（ＪＳＯＮ、ＸＭＬなど）にパッケージングするためのコード、結果パケットを受けてパースするためのコード、リトライおよびエラー条件を扱うためのコードなどを含み得る。呼び出し側サービスの観点からすると、この機能すべてを扱うためのコードは、ＡＰＩレジストリによって自動的に生成され、したがって、サービスコールの詳細を要約しカプセル化してクライアントライブラリオブジェクトにする。呼び出し側サービスに要求されるのは、ＡＰＩレジストリが作成したクライアントライブラリオブジェクトのメンバ関数を実行することだけである。

いくつかの実施形態において、ＡＰＩレジストリは、登録されたサービスのランタイム実行を定義し得る一組のプロパティのアップロードを受け入れることもできる。この一組のプロパティは、開発中に、ＡＰＩ定義ファイルとともにアップロードすることができる。これらのプロパティは、エンドツーエンド暗号化、使用／ロギング要件、ユーザ認証、オンデマンドサービスインスタンス化、高可用性のための複数のサービスデプロイメントインスタンス、レート／使用制限、およびその他のランタイム特徴等の、ランタイム特徴を定義することができる。ＡＰＩレジストリは、開発中、デプロイ中、およびランタイム中に、コンテナ環境とやり取りすることによってこれらのプロパティが満たされることを保証できる。開発中、呼び出し側サービスのために自動的に生成されたクライアントライブラリは、暗号化コード、使用ロギングコード、および／またはユーザ認証サービスとのやり取り等の、これらのプロパティの実行に必要となり得るコードを含むことができる。登録されたサービスがデプロイされているとき、ＡＰＩレジストリは、コンテナプラットフォームに対し、サービスおよび／または追加のロードバランシングモジュールの複数のインスタンスをインスタンス化することによってランタイム中のサービスの高い信頼性を保証するよう指示することができる。ランタイム中にサービスがコールされると、ＡＰＩレジストリは、オンデマンドインスタンス化のためにサービスをインスタンス化させ、使用を抑えるために行うことができるＡＰＩコールの数を制限し、その他のランタイム関数を実行することができる。

図１は、いくつかの実施形態に係る、コンテナプラットフォームにおけるサービスのための開発およびランタイム環境のソフトウェア構造および論理構成を示す。この環境は、コンテナプラットフォーム上にデプロイされるサービスおよびマイクロサービスを開発するために使用し得るＩＤＥ１０２を含み得る。ＩＤＥは、新たなサービスの記述およびテストのためにサービス開発者が使用できる基本ツールすべてを統合し提供するソフトウェアスイートである。ＩＤＥ１０２は、開発者がソースコード記述プロセスの記述、ナビゲート、統合、および視覚化を行うことを可能にする、グラフィカルユーザインターフェイス（ＧＵＩ）、コード補完機能、およびナビゲート／ブラウズインターフェイスとともに、ソースコードエディタ１０６を含み得る。ＩＤＥ１０２はまた、可変インターフェイス、即時可変インターフェイス、表現評価インターフェイス、メモリコンテンツインターフェイス、ブレークポイント可視化および機能、ならびにその他のデバッグ関数を含む、デバッガ１１０を含み得る。ＩＤＥ１０２はまた、マシンコードをコンパイルしコンパイルしたマシンコードまたは解釈されたバイトコードを実行するためのコンパイラおよび／またはインタプリタ１０８を含み得る。コンパイラ／インタプリタ１０８は、開発者が別のビルド自動化構成のためのメイクファイル（makefiles）を使用／生成することを可能に
するビルドツールを含み得る。ＩＤＥ１０２のいくつかの実施形態は、コードライブラリ１１２を含み得る。コードライブラリは、一般的なコード関数、オブジェクト、インターフェイス、および／または、開発中のサービスにリンクさせることができ複数の開発で再使用できるその他の構造を含む。

サービスは、ＩＤＥ１０２内で、開発することができ、デプロイの準備が整うまで徹底的にテストすることができる。サービスはその後、プロダクション／デプロイメント環境１０４にデプロイすることができる。プロダクション／デプロイメント環境１０４は、専用ハードウェア、仮想マシン、およびコンテナ化されたプラットフォームを含む、多数の異なるハードウェアおよび／またはソフトウェア構造を含み得る。本開示よりも前において、サービス１１４がプロダクション／デプロイメント環境１０４にデプロイされたとき、サービス１１４は、ＩＤＥ１０２で使用されるツールの多くに対するランタイムアクセスを行うことができない。サービス１１４がプロダクション／デプロイメント環境１０４で実行するのに必要ないずれの機能も、コードライブラリ１１２からパッケージングしサービス１１４とともにプロダクション／デプロイメント環境１０４にデプロイする必要があった。加えて、一般的にサービス１１４は、デバッガ１１０の機能またはソースコードエディタ１０６からのソースコードのコピーのうちのいずれも伴うことなくデプロイされる。実際、サービス１１４は、ランタイム動作に必要な機能すべてとともにプロダクション／デプロイメント環境１０４にデプロイされるが、開発中にだけ使用された情報は取り除かれる。

図２は、本明細書に記載の実施形態を実行するために特別に設計された専用コンピュータハードウェアシステムを示す。一例として、サービス１１４は、サービスとしてのインフラストラクチャ（Infrastructure as a Service）（ＩａａＳ）クラウドコンピューテ
ィング環境２０２にデプロイすることができる。これは、ネットワーク上に仮想化または共有コンピューティングリソースを提供するクラウドコンピューティングの一形態である。ＩａａＳクラウドコンピューティング環境２０２はまた、サービスとしてのソフトウェア（Software as a Service）（ＳａａＳ）および／またはサービスとしてのプラットフ
ォーム（Platform as a Service）（ＰａａＳ）アーキテクチャとして構成されたその他
のクラウドコンピューティング環境を含み得る、または当該環境に結合し得る。この環境において、クラウドプロバイダは、従来オンプレミスデータセンターに存在していたハードウェアおよび／またはソフトウェアコンポーネントのインフラストラクチャをホストすることができる。このハードウェアは、サーバ、ストレージ、ネットワーキングハードウェア、ディスクアレイ、ソフトウェアライブラリ、および、ハイパーバイザレイヤのような仮想化ユーティリティを含み得る。ＩａａＳ環境２０２は、Oracle（登録商標）またはその他一般に利用できるクラウドプラットフォームのような商用ソースによって提供されることができる。ＩａａＳ環境２０２はまた、ハードウェアおよびソフトウェアのプライベートインフラストラクチャを用いてプライベートクラウドとしてデプロイすることもできる。

クラウド環境のタイプとは関係なく、サービス１１４は、複数種類のハードウェア／ソフトウェアシステムにデプロイすることができる。たとえば、サービス１１４は、専用ハードウェア２０６にデプロイすることができる。専用ハードウェア２０６は、サービス１１４に特別に割り当てられたサーバ、ディスク、オペレーティングシステム、ソフトウェアパッケージなどのようなハードウェアリソースを含み得る。たとえば、特定のサーバが、サーバ１１４との間で流れるトラフィックを処理するように割り当てられていてもよい。

別の例において、サービス１１４は、１つ以上の仮想マシン２０８として動作させるハードウェア／ソフトウェアにデプロイすることができる。仮想マシンは、専用コンピュータハードウェア２０６の機能を提供するコンピュータシステムをエミュレートしたものである。しかしながら、特定の関数専用にする代わりに、物理ハードウェアを複数の異なる仮想マシンが共有してもよい。各仮想マシンは、完全なオペレーティングシステムを含む、実行する必要があるすべての機能を提供することができる。これにより、異なるオペレ
ーティングシステムを有する複数の仮想マシンが、同一の物理ハードウェア上で実行することができ、複数のサービスが１つのハードウェアを共有することができる。

別の例において、サービス１１４はコンテナプラットフォーム２１０にデプロイすることができる。コンテナプラットフォームは、仮想マシン２０８と、複数の重要な点において異なっている。第１に、以下図３で詳述するように、コンテナプラットフォーム２１０は、個々のサービスをコンテナにパッケージングする。各コンテナは、ホストオペレーティングシステムカーネルを共有するとともに、バイナリ、ライブラリ、およびその他の読取専用コンポーネントを共有する。これにより、コンテナを極めて軽くすることができ、わずか数メガバイトのサイズであることも多い。加えて、軽量コンテナは、仮想マシンのブートアップに数分を要するのに対して起動にわずか数秒しかかからず、非常に効率的である。また、コンテナは、オペレーティングシステム、および、コンテナプラットフォーム２１０内の一組のコンテナセットに対してともに管理できるその他のライブラリを共有することにより、管理オーバーヘッドを減じる。コンテナは同じオペレーティングシステムを共有するものの、オペレーティングシステムは分離のために仮想メモリサポートを提供するので、分離されたプラットフォームを提供する。コンテナ技術は、Docker（登録商標）コンテナ、Linux（登録商標） Libcontainer（登録商標）、オープンコンテナイニシアティブ（Open Container Initiative）（ＯＣＩ）、Kubernetes（登録商標）、Ｃｏｅ
ＯＳ、Apache（登録商標） Mesosを、それ以外のものともに含み得る。これらのコンテナは、本明細書では簡単に「コンテナプラットフォーム２１０」と呼ぶ場合があるコンテナオーケストレーションプラットフォームにデプロイすることができる。コンテナプラットフォームは、デプロイされたソフトウェアコンテナの自動化された構成、調整、および管理を維持する。コンテナプラットフォーム２１０は、サービスディスカバリ、ロードバランシング、ヘルスチェック、マルチデプロイメントなどを提供することができる。コンテナプラットフォーム２１０は、ノードおよびポッドで構成されたコンテナを実行する、Kubernetesのような一般に利用できるコンテナプラットフォームによって実現し得る。

サービス１１４をデプロイするプラットフォーム２０６、２０８、２１０とは関係なく、プラットフォーム２０６、２０８、２１０は各々、サービス１１４をコールするためのパブリックアクセスを提供するサービスエンドポイント２１２、２１４、２１６を提供できる。一般的に、これらのエンドポイントには、ＨＴＴＰコールを通してアクセスでき、これらのエンドポイントは、ＩＰアドレスおよびポート番号に対応付けられる。正しいＩＰアドレスおよびポート番号に接続することにより、その他のサービスは、公的に利用できるようにされたときにプラットフォーム２０６、２０８、２１０のうちのいずれかにデプロイされるサービスをコールすることができる。サービス１１４等の各サービスは、サービスをコールするための自身のプロプライエタリフォーマットとデータ要件とを含み得る。同様に、各サービスは、フォーマットおよびデータタイプがそのサービス１１４に固有である結果を返すことができる。サービス固有の要件に加えて、特定のデプロイメントプラットフォーム２０６、２０８、２１０はまた、サービスと適切にやり取りするために準拠する必要がある、プログラミング言語、パッケージフォーマット（ＪＳＯＮ、ＸＭＬなど）その他のような、サービス１１４とやり取りするための追加要件を含み得る。

上述の例は、サービス１１４を上記プラットフォーム２０６、２０８、２１０のうちのいずれかにデプロイすることを可能にするが、本明細書に記載の実施形態は、上記コンテナプラットフォーム２１０のために特別に設計される。よって、「コンテナプラットフォーム」にデプロイされると具体的に記載された実施形態は、仮想マシンプラットフォームに、サーバもしくは専用ハードウェアプラットフォーム上に、または一般的にＩａａＳ環境にデプロイされると具体的に記載された実施形態と区別することができる。

図３は、本明細書に記載の実施形態のうちのいくつかが使用するコンテナプラットフォ
ーム２１０に固有であってもよいデータ組織を示す。一般的に、コンテナプラットフォームへのサービスのいかなるデプロイメントもポッド３０４、３０６にデプロイされる。ポッドは、１つ以上のアプリケーションコンテナ（たとえばDockerまたはrkt）からなるグ
ループを表す抽象概念である。ポッドはまた、当該ポッド内のすべてのコンテナが共通して利用できるいくつかの共有リソースを含み得る。たとえば、ポッド３０４はコンテナ３１０とコンテナ３１２とを含む。ポッド３０４はまた、共有リソース３０８を含む。このリソースは、ストレージボリューム、またはコンテナが如何にしてポッド３０４内で実行されるかまたは接続されるかに関するその他の情報を含み得る。ポッド３０４は、比較的密接に結合された異なるサービスコンテナ３１０、３１２を含むアプリケーション専用論理ホストをモデル化することができる。たとえば、コンテナ３１０内のサービス３２６は、リソース３０８を利用することができ、コンテナ３１２内のサービス３２０をコールすることができる。サービス３２０もサービス３２２をコールすることができ、サービス３２２もサービス３２４をコールすることができ、これらのサービスは各々コンテナ３１２にデプロイされている。サービス３２４の出力はネットワークＩＰアドレスおよびポート３１８に与えることができ、これはポッド３０４が共有する別の共通リソースである。このように、サービス３２０、３２２、３２４、３２６すべてが共有リソース３０８と協働することにより、他のコンテナで実行されるサービスがＩＰアドレスおよびポート番号３１８によってアクセスすることができる、１つのサービスを提供する。このサービスは、コンテナプラットフォームまたはＩａａＳ環境の一部ではない、ワークステーション、ラップトップコンピュータ、スマートフォンまたはその他のコンピューティングデバイスのような、コンテナプラットフォームの外部のコンピュータシステムが、ＩＰアドレスポート３１８を介してアクセスすることもできる。

最も単純なデプロイメントの場合、各コンテナは１つのサービスを含むことができ、各ポッドはサービスをカプセル化する１つのコンテナを含むことができる。たとえば、ポッド３０６は１つのサービス３２８のみを有する１つのコンテナ３１４のみを含む。この１つのサービスは、ポッド３０６のＩＰアドレスおよびポート番号３１６を通してアクセスできる。典型的に、サービスがコンテナプラットフォームにデプロイされるとき、コンテナおよびポッドがインスタンス化されてこのサービスを保持する。複数の異なるポッドをコンテナノード３０２にデプロイすることができる。一般的に、ポッドはノード内で実行される。ノードはコンテナプラットフォーム内のワーカーマシン（仮想または物理いずれか）を表す。各ノードは、各ノード内のスケジューリングポッドを自動的に扱う「マスタ」によって管理される。各ノードは、マスタとノードとの間の通信を担い、かつ当該ノードによって表されるマシン上のコンテナ内でポッドを管理するためのプロセスを実行することができる。各ノードはまた、レジストリからコンテナ画像を引き出すこと、コンテナを解凍すること、およびサービスを実行することを担うコンテナランタイムを含み得る。

図４は、いくつかの実施形態に係る、ＩＤＥ１０２およびプロダクション／デプロイメント環境１０４にデプロイすることができるＡＰＩレジストリ４０４を示す。上述のように、サービス１１４がＩＤＥ１０２からプロダクション／デプロイメント環境１０４にデプロイされるとき、ＩＤＥ１０２内で独占的に利用できる情報へのランタイムアクセスをサービス１１４が失うという、技術的課題がある。ＡＰＩレジストリ４０４に対し、サービス１１４は、プロダクション／デプロイメント環境１０４にデプロイされこの環境でランタイム中に動作している間、アクセスすることができる。開発関数がランタイム関数から分離されるという過去の技術的課題は、開発中にサービスをＡＰＩレジストリ４０４に登録しＡＰＩ定義および／またはＡＰＩプロパティをＡＰＩレジストリ４０４に与えることにより、ＡＰＩレジストリ４０４によって克服される。ＡＰＩを定義する情報は、ＩＤＥ１０２内の開発中の新たなサービス、および、プロダクション／デプロイメント環境１０４に既にデプロイされているサービスが、使用できる。この登録プロセスの完了後、サービス１１４はクライアントライブラリを用いて動作することができ、クライアントライ
ブラリは、ランタイム中にＡＰＩレジストリ４０４にアクセスすることにより、ＡＰＩ関数が、対応するサービスの現在のＩＰアドレスおよびポート番号に正しくバインドされていることを保証する。ＡＰＩレジストリ４０４は、これらの技術的課題を解決するために特別に設計された新たなデータ構造および処理ユニットを表す。

当該技術に存在していたもう１つの技術的課題は、サービスプロパティがプロダクション／デプロイメント環境１０４にデプロイされるときの、サービスプロパティの実現であった。たとえば、サービスを高可用性を伴ってデプロイしようとする場合、開発者は、コンテナプラットフォーム内でサービスの複数のインスタンスを特別にインスタンス化したコンテナデプロイメントファイルと、バランスが取れたトラフィックとを、サービスが常に利用できるように構築する必要がある。サービス開発者は必ずしもこの専門知識を有していた訳ではなく、それらのサービスのデプロイメントを大抵は管理できた訳でもない。上述のように、ＡＰＩレジストリ４０４により、サービスは、ＡＰＩレジストリ４０４が自動的に実現できる高可用性のようなプロパティを単純に選択することができる。この技術的解決策が可能な理由は、ＡＰＩレジストリ４０４がＩＤＥ１０２とプロダクション／デプロイメント環境１０４との間の隙間の架け橋となるからである。

図５は、いくつかの実施形態に係る、実行時にコンテナプラットフォーム２１０とともに使用されるＡＰＩレジストリ４０４のデプロイメントを示す。ＡＰＩレジストリ４０４が提供する、既存の技術に対する技術的解決策および改善のうちの１つは、サービスコールのための安定したエンドポイントの維持、ならびにサービスコールへのアクセスの簡略化およびサービスコールへのアクセスのための自動コード生成である。本開示よりも前において、サービス間のコールは、たとえばＩＰアドレスおよびポート番号に対するＨＴＴＰコールを用いるポイントツーポイント接続であった。サービスがアップデート、リプレイス、リロケート、およびコンテナプラットフォーム２１０に再デプロイされるときに、ＩＰアドレスおよびポート番号が頻繁に変わる可能性がある。この場合、アップデートされたサービスをコールしたすべてのサービスが、そのサービスをコールした実際のコードのＩＰアドレスおよびポート番号をアップデートする必要があった。ＡＰＩレジストリ４０４は、この技術的課題を、サービスのＩＰアドレスおよびポート番号と、ＡＰＩレジストリを介して利用できるようにされるＡＰＩ関数との間の動的バインディングを提供することによって解決する。ＡＰＩレジストリ４０４が自動的に生成するクライアントライブラリは、ＡＰＩレジストリ４０４にアクセスすることにより特定のサービスの現在のＩＰアドレスおよびポート番号を取り出すおよび／または検証する関数を含み得る。したがって、第２のサービスに接続する第１のサービスは、クライアントライブラリを一度生成するだけで、第２のサービスへの、存続期間にわたって安定した接続を提供する。

ＡＰＩレジストリ４０４が解決する別の技術的課題は、クライアントライブラリの自動生成である。本開示よりも前において、第２のサービスにアクセスする第１のサービスは、第２のサービスにアクセスするためのカスタムコードを開発者が記述することを必要としていた。このコードは時間の経過に伴って変化する可能性があるので、どちらもアップデートを必要とする第１のサービスと第２のサービスとの間に非互換性が生じることになる。ＡＰＩレジストリ４０４は、この技術的課題を、サービスをコールするためにクライアントライブラリを自動的に生成するのに使用されるＡＰＩ定義ファイルをアップロードすることによって解決する。したがって、サービスは、その他いずれかのサービスにおけるコーリングコードが如何にして動作すべきかを具体的に指定することができ、これが互換性を保証する。これらのクライアントライブラリはまた、サービスをコールするためのコードを大幅に簡略化しカプセル化する。以下で述べるように、ＩＰアドレスおよびポート番号を使用する複雑なＨＴＴＰコールは、呼び出し側サービスに固有の言語（たとえばＪａｖａ（登録商標）、Ｃ＃など）の単純なメンバ関数に置き換えることができる。これにより、呼び出し側サービスは、ＡＰＩレジストリ４０４からＡＰＩ関数を選択すること
ができ、関数で実現するコードは、クライアントライブラリとして呼び出し側サービスダウンロードすることができる。

図６Ａは、いくつかの実施形態に係る、ＡＰＩレジストリ４０４をデプロイする方法のフローチャートを示す。この方法は、ＡＰＩレジストリサービスをコンテナ環境にデプロイすることを含み得る（６０１）。ＡＰＩレジストリは、コンテナ環境においてコンテナ内で動作するサービスとして実現することができる。よって、ＡＰＩレジストリは、実行時にアクセスされることができるよう、コンテナ環境内にサービスがデプロイされた後で能動的に実行することができる。ＡＰＩレジストリは、上記既存のＩＤＥにリンクさせることもできる。この方法はさらに、コンテナプラットフォーム内の利用できるサービスのためのポートを発見することを含み得る（６０３）。サービスがコンテナプラットフォームにデプロイされると、ＡＰＩレジストリは、コンテナプラットフォームにデプロイされたサービス各々を逐次的にトラバースするディスカバリプロセスを開始することができる。サービスごとに、ＡＰＩレジストリはＩＰアドレスおよびポート番号を検出して記録することができる。このプロセスによって発見されたＩＰアドレスおよびポート番号の一覧表は、ＡＰＩレジストリに対応付けられたテーブル等のデータ構造に格納することができる。また、各ＩＰアドレスおよびポート番号は、そのサービスの名称とともに、または、コンテナプラットフォーム上のサービスを一意に識別するその他の識別子とともに、格納することができる。図６Ａのフローチャートに示されるこれらの初期ステップは、ＡＰＩレジストリがコンテナプラットフォームのランタイム環境内で動作を開始するため、かつ、ＩＤＥ内で開発中のサービスがＡＰＩレジストリを利用できるようにするための、出発点を提供する。

図６Ｂは、いくつかの実施形態に係る、図６Ａのフローチャートを用いてＡＰＩレジストリをデプロイするときのコンテナプラットフォーム２１０のソフトウェア構造を示す。先に述べたように、ＡＰＩレジストリ４０４はコンテナプラットフォーム２１０内のコンテナ６２０にデプロイすることができる。先に図３で説明したように、コンテナ６２０は、あるノードにおいて１つ以上のポッド内で動作することができる。ＡＰＩレジストリ４０４を、コンテナプラットフォーム２１０内の他のコンテナのうちのいずれかが非公式に利用できるようにすることができる。いくつかの実施形態において、ＡＰＩレジストリ４０４を、コンテナプラットフォーム２１０の一部ではない他のデバイスが公的に利用できるようにすることもできる。コンテナ化されたサービスとして、ＡＰＩレジストリ４０４は他のサービスが利用できるＩＰアドレスおよびポート番号を有することができる。しかしながら、ＡＰＩレジストリ４０４のＩＰアドレスおよびポート番号は、クライアントライブラリで自動的に生成されたコードのみによって使用されるので、いくつかの実施形態はＡＰＩレジストリ４０４のＩＰアドレスおよびポート番号を公開する必要はない。その代わりに、ＩＤＥ自身のクライアントライブラリが、他のサービスの開発、デプロイ、および実行中にコンタクトできるよう、ＡＰＩレジストリ４０４のＩＰアドレスおよびポート番号の最新一覧表を管理することができる。

ＡＰＩレジストリ４０４は、コンテナ６２０にデプロイされた後に、ディスカバリプロセスを実行することができる。ディスカバリプロセスは、コンテナプラットフォームにおけるノードのディレクトリ一覧表を用いることにより、ＩＰアドレスおよびポート番号で、サービスを実現するポッドを特定することができる。そうすると、ＡＰＩレジストリ４０４は、利用できる各サービスの番号または名称等の固有識別子にアクセスし、識別子を各ＩＰアドレスおよびポート番号とともにコンテナプラットフォーム２１０に格納することができる。このディスカバリプロセスを周期的に実行することにより、コンテナプラットフォーム２１０に追加された新たなサービスを検出することができるとともに、コンテナプラットフォーム２１０から削除された既存のサービスを特定することができる。以下で述べるように、このディスカバリプロセスを用いることにより、既存のサービスについ
てＩＰアドレスおよびポート番号がいつ変化したかを検出することもできる。たとえば、ＡＰＩレジストリ４０４は、エンドポイント６０２、６０４、６０６、６０８を有するサービスを発見することができる。下記プロセスにおいて、ＡＰＩレジストリ４０４は、これらのエンドポイント６０２、６０４、６０６、６０８各々を、ＡＰＩレジストリ４０４に登録されたＡＰＩ関数にバインドすることができる。この最初の発見後のある時点で、エンドポイント６０２のＩＰアドレスおよび／またはポート番号が、エンドポイント６０２に対応付けられたサービスがリプレイス、アップデート、またはリバイズされたときに、変更される場合がある。ＡＰＩレジストリ４０４は、このエンドポイント６０２に対する変更を検出し、ＡＰＩレジストリ４０４が提供する既存のＡＰＩ関数へのバインディングをアップデートすることができる。

同様に、ＡＰＩレジストリ４０４は、ディスカバリプロセスを用いることにより、いつエンドポイントが利用できなくなったかを検出し、その後、サービスに対応付けられたＡＰＩ関数を削除することができる。いくつかの実施形態において、サービスはＡＰＩレジストリ４０４に登録されているものの、対応するＡＰＩ関数が現在有効なエンドポイントにバインドされていないとき、ＡＰＩレジストリ４０４は、対応するＡＰＩ関数をコールしているいずれかのサービスにモックレスポンス（mock response）を与えることができ
る。たとえば、エンドポイント６０４に対応するサービスについてＡＰＩが登録されているものの、エンドポイント６０４は現在利用できない場合、ＡＰＩレジストリ４０４は、エンドポイント６０４に対するコールをインターセプトしそれに応じてデフォルトまたはダミーデータを与えることができる。これにより、エンドポイント６０４に対応付けられているサービスをコールするサービスは、機能を維持する、および／またはこの特定のサービスに対する接続を「切断する」ことなく設計プロセスを続けることができる。モック／テストデータシナリオについては以下でより詳細に説明する。

図７Ａは、いくつかの実施形態に係る、ＡＰＩレジストリ４０４にサービスを登録する方法のフローチャートを示す。この方法は、ＡＰＩ定義のアップロードを受けることを含み得る（７０１）。ＡＰＩ定義は、データパケット、ファイル、または情報リポジトリに対するリンクの形態で提供し得る。ＡＰＩ定義は、サービスに対応付けられたエンドポイントにバインドすべきＡＰＩ関数を特定し定義するために使用できる任意の情報を含み得る。たとえば、ＡＰＩ定義のいくつかの実施形態は、以下のデータを、すなわち、サービス名またはその他の固有識別子、サービスエンドポイントおよびコールに対応する関数名、対応する記述およびデータタイプでサービスにコールするのに必要なデータ入力、結果データフォーマットおよびデータタイプ、現在のＩＰアドレスおよび／またはポート番号、エンドポイントに対応付けられることになるＡＰＩ関数の機能を記述する文書、モック／テストシナリオ中に返すべきデフォルトまたはダミーデータ値、ならびに、ＡＰＩレジストリ４０４が、エンドポイントが受けたＨＴＴＰ要求を、クラスデータオブジェクトのＡＰＩ関数コールを使用するクライアントライブラリに変換するために使用し得るその他任意の情報を、含み得る。

この方法はまた、アップロードされたＡＰＩ定義に基づいて対応するＡＰＩ関数を作成することを含み得る（７０３）。これらのＡＰＩ関数はＡＰＩ定義に基づいて自動的に生成することができる。サービスの各エンドポイントは複数の異なるＡＰＩ関数に対応付けることができる。たとえば、ＲＥＳＴｆｕｌインターフェイスを実現するエンドポイントは、同一のＩＰアドレスおよびポート番号のＰＯＳＴ、ＧＥＴ、ＰＵＴ、およびＤＥＬＥＴＥ関数に対するＨＴＴＰコールを受けることができる。これは結果としてたとえば異なるＡＰＩ関数に対するものになり得る。たとえば、このインターフェイスがユーザのリストを表す場合、これは、GetUser( )、AddUser( )、RemoveUser( )、およびUpdateUser( )のような、少なくとも４つの異なるＡＰＩ関数に対応し得る。加えて、各ＡＰＩ関数は、UpdateUser(id)、UpdateUser(name)、UpdateUser(firstname, lastname)などのような、
複数の異なるパラメータリストを含み得る。これらのＡＰＩ関数を生成し、生成されたＡＰＩ関数をＡＰＩレジストリを介して他のサービスが利用できるようにすることができる。以下でより詳細に説明するように、これらの関数をＡＰＩレジストリを介してコールするためにサービスは必要ではないことに注意する必要がある。代わりに、これらの関数は、ＡＰＩレジストリにおいてブラウズするのに利用できるようにされ、選択されると、ＡＰＩレジストリは、呼び出し側サービスにおいてこれらの関数を実現するクライアントライブラリを生成することができる。

この方法はさらに、ＡＰＩレジストリにおいて、ＡＰＩ関数と、対応するサービスのエンドポイントとの間のバインディングを作成することを含み得る（７０５）。上記ディスカバリプロセスおよびステップ７０１の登録プロセスに基づいて、ＡＰＩレジストリは、コンテナプラットフォームにおけるサービスのエンドポイントと、ＡＰＩレジストリが作成したＡＰＩ関数との間の動的バインディングを作成することができる。利用できるエンドポイントおよびサービスを発見したときに形成される上記データ構造に、ＡＰＩレジストリは、各エンドポイントの対応する関数または一組の関数を格納することができる。上述のように、このバインディングは、サービスがいつアップデート、移動、リプレイス、またはコンテナプラットフォームに追加されるかがディスカバリプロセスによって判断されたときに、常にアップデートすることができる。これにより、呼び出し側サービスにおいて作成されたクライアントライブラリは、先ずＡＰＩレジストリを調べることにより、サービスの現在のＩＰアドレスおよびポート番号を検証するまたは受けることができる。

図７Ｂは、いくつかの実施形態に係る、ＡＰＩレジストリ４０４にＡＰＩを登録するためのステップのハードウェア／ソフトウェア図を示す。上述のように、ＡＰＩレジストリ４０４をインスタンス化しコンテナプラットフォーム２１０におけるコンテナ６２０内で実行することができる。コンテナプラットフォーム２１０はプロダクション／デプロイメント環境を表しているが、ＡＰＩレジストリ４０４はそれでもなお、サービスを開発するために使用されるＩＤＥ１０２からアクセスすることができる。よって、ＩＤＥ１０２は、ＡＰＩ定義ファイル７０２をＡＰＩレジストリ４０４にアップロードするメカニズムを提供することができる。具体的には、ＩＤＥ１０２のユーザインターフェイスは、開発者がＡＰＩ定義ファイル７０２のフィールドを定義するおよび／またはフィールドにポピュレートすることを可能にするウィンドウまたはインターフェイスを含み得る。上述のこの情報は、関数名、パラメータリスト、データタイプ、フィールド長、オブジェクトクラス定義、ＩＰアドレスおよびポート番号、サービス名またはその他の固有識別子などを、含み得る。この情報は、ＡＰＩレジストリ４０４にアップロードすることができ、動的バインディングによって、エンドポイント６０２の特定のＩＰアドレスおよびポート番号にリンクさせることができる。最後に、ＡＰＩレジストリ４０４は、ＡＰＩレジストリ４０４を介して利用できるようにすることができる１つ以上のＡＰＩ関数７０４を生成することができる。

サービスがＡＰＩレジストリ４０４に登録され１つ以上のＡＰＩ関数が生成された後に、ＡＰＩレジストリは、開発者がサービスを設計する際にこれらの関数を利用できるようにすることができる。図８は、いくつかの実施形態に係る、ＡＰＩレジストリ４０４に登録されたＡＰＩをブラウズし選択するためのグラフィカルインターフェイス８０２およびコマンドラインインターフェイス８０４の例を示す。コンテナプラットフォームに対して新たなサービスをプログラミングおよび開発するときに、開発者は、グラフィカルインターフェイス８０２にアクセスすることにより、それらのサービスで使用できるＡＰＩ関数をブラウズし選択することができる。このグラフィカルインターフェイス８０２は、一例にすぎず、ＡＰＩ関数をブラウズし選択するために使用できるグラフィカルインターフェイスのタイプを限定することを意図している訳ではない。

この実施形態において、ＩＤＥ１０２は、ＡＰＩレジストリに登録されているＡＰＩのリストを提供するようグラフィカルインターフェイス８０２に命じることができる。この実施形態において、ＡＰＩはエンドポイントに基づいてカテゴライズされる。たとえば、あるサービスに対応する１つのエンドポイントは、ユーザ記録を格納するためのＲＥＳＴｆｕｌインターフェイスを提供し得る（たとえば「UserStorage」）。グラフィカルイン
ターフェイス８０２は、選択されたエンドポイントを介して利用できるすべてのＡＰＩ関数（たとえば「CreateUser」、「DeleteUser」、「UpdateUser」など）を表示することができる。その他の実施形態は、サービスが複数のエンドポイントを提供する場合、サービス全体に基づいて関数をグループ分けすることができる。グラフィカルインターフェイス８０２は、呼び出し側サービスで使用される１つ以上のＡＰＩ関数の選択を受けることができる。ＡＰＩレジストリは次に、必要なパラメータおよびリターン値を含む、ＡＰＩ関数の使用方法を示す文書を提供することができる。当業者は、コマンドラインインターフェイス８０４がグラフィカルインターフェイス８０２と同様の情報を提供することができかつ同様の入力を受けることができることを、理解するであろう。

図８に示されるインターフェイス８０２、８０４は複数の技術的利点を提供する。第１に、これらのインターフェイス８０２、８０４は、ＡＰＩレジストリに登録されているすべてのＡＰＩの最新一覧表を提供する。これは、コンテナプラットフォームで現在利用できるすべてのサービスのリストに相当する。文書を調べること、サービス開発者にコンタクトすること、および／または利用できるサービスのリストの場所を特定するためのその他の非効率的なタスクを実行することが要求されるのではなく、サービス開発者はこの情報をリアルタイムで取り出して表示することができる。加えて、サービスがアップデートされると、ＡＰＩ定義ファイルを対応するやり方でアップデートすることができる。これにより、次に図８に示されるディスプレイがアップデートされて各ＡＰＩ関数の最新の可用性情報を提供する。

図９は、いくつかの実施形態に係る、ＡＰＩレジストリに登録されたサービスおよびその対応する関数を使用する方法のフローチャートを示す。この方法は、登録されたＡＰＩの一覧表を提供することを含み得る（９０１）。所望のサービスが既にわかっている場合はこのステップを省略してもよい。しかしながら、一般的に、サービスは、上述の図８のインターフェイスを用いたブラウズおよびナビゲーションのために表示することができる。この方法はまた、ＡＰＩ関数の選択を受けることを含み得る（９０３）。この選択は、ＡＰＩレジストリがサービスの開発者から受けることができるものである。たとえば、開発者は、上記CreateUser( )関数を用いてユーザ記録のデータベースをアップデートする
と決定する場合がある。図１０は、ＡＰＩレジストリが如何にしてCreateUser( )関数の
選択１００２をグラフィカルインターフェイス８０２を介して受けることができるかを示す。他の実施形態は、この選択を、コマンドラインインターフェイスを介してまたはＩＤＥが提供するその他の入力方法を介して受けることができる。

再び図９を参照して、ＡＰＩレジストリは、ＡＰＩ関数の選択を受けると、呼び出し側サービスのための１つ以上のクライアントライブラリを生成することができる（９０５）。クライアントライブラリを生成することにより、呼び出し側サービスに、ＡＰＩ関数に動的にバインドされたサービスエンドポイントを提供することができる。具体的には、ＩＤＥは、コンテナプラットフォームにおけるサービスエンドポイントと直接インターフェイスするのに必要な機能をカプセル化する一組のクラスオブジェクトをＩＤＥに生成することができる。いくつかの実施形態において、クライアントライブラリは、サービスとの通信に必要なコードを実施するメンバ関数をコールするためにインスタンス化または使用することができるオブジェクトクラスを含み得る。これらのクライアントライブラリの例については以下でより詳細に説明する。

この方法はさらに、テストデータを提供することを含み得る（９０７）。サービスは、ＡＰＩレジストリに登録されるとき、完全である必要はない。代わりに、サービスは、呼び出し側サービスに対する機能的レスポンスを提供する準備がまだ整っていないことをＡＰＩレジストリに対して示すことができる。いくつかの実施形態において、ＡＰＩレジストリにアップロードされたＡＰＩ定義ファイルは、サービスが機能的になる前に返す必要がある情報のタイプの明細を含み得る。呼び出し側サービスがＡＰＩ関数をコールすると、ＡＰＩレジストリが生成したクライアントライブラリは、サービスエンドポイントではなくＡＰＩレジストリに要求をルーティングすることができる。そうすると、ＡＰＩレジストリは、ダミー、ヌル、またはデフォルト値を用いてレスポンスを提供することができる。これに代えて、クライアントライブラリ自身の中にあるコードが、呼び出し側サービスに返されるデフォルトデータを生成してもよい。

図９に示される具体的なステップが本発明の各種実施形態に係るＡＰＩレジストリの特定の使用方法を提供することが理解されるはずである。代替実施形態に従いステップの他のシーケンスを実行することもできる。たとえば、本発明の代替実施形態は、概要を述べた上記ステップを異なる順序で実行し得る。加えて、図９に示される個々のステップは、個々のステップに適したさまざまなシーケンスで実行し得る複数のサブステップを含み得る。さらに、特定のアプリケーションに応じてその他のステップを追加または削除する場合もある。当業者は、多数の変形、修正、および代替形を認識するであろう。

図１１は、いくつかの実施形態に係る、ＡＰＩレジストリがあるサービスのために自動的に生成したクライアントライブラリの一例を示す。このクライアントライブラリ１１０２は、ユーザ記録を格納するサービスに対応し得る。このクライアントライブラリ１１０２ならびに対応するクラスおよびサービスは、例示のために提供されているにすぎず、限定を意図している訳ではない。先に述べたように、各ＡＰＩ関数およびサービスは、ＡＰＩレジストリにアップロードされたＡＰＩ定義ファイルによって如何にしてクライアントライブラリが生成されるべきかを指定することができる。したがって、「Ｕｓｅｒ（ユーザ）」サービスに関して以下で述べる原理は、その他のサービスにも適用し得る。

Ｕｓｅｒサービスを表すために、ＡＰＩレジストリはＵｓｅｒのクラスを生成することができる。呼び出し側サービスは、ＡＰＩレジストリによるクライアントライブラリの生成を要求するとき、呼び出し側サービスが使用しているプログラミング言語を指定することができる。たとえば、呼び出し側サービスがＪａｖａでＩＤＥに記述されている場合、ＡＰＩレジストリはＪａｖａプログラミング言語でクラスライブラリを生成することができる。これに代えて、呼び出し側サービスがＣ＃で記述されている場合、ＡＰＩレジストリはＣ＃プログラミング言語でクラスライブラリを生成することができる。Ｕｓｅｒクラスは、サービスエンドポイントを介して実行することができる異なる動作に対応するメンバ関数を有するように生成することができる。これらのメンバ関数は、スタティックメンバ関数にすることにより、Ｕｓｅｒクラスのインスタンス化されたインスタンスを必要としないようにすることができる、または、インスタンス化されたＵｓｅｒオブジェクトとともに使用されてもよい。

この例において、Ｕｓｅｒサービスは、ＲＥＳＴｆｕｌインターフェイスを使用することにより、サービスによって格納された個々のユーザ記録を編集することができる。たとえば、ＡＰＩレジストリは、CreateUser( )関数を生成することにより、Ｕｓｅｒサービ
スに対するＰＯＳＴコールを実現することができる。クラスライブラリが実行できる機能のうちの１つは、サービスに対してデータパケットとして直接送られるＡＰＩ関数に対してパラメータとして提供されるデータを、パースし、フィルタリングし、フォーマットすることである。この例において、CreateUser( )関数は、呼び出し側サービスの便宜のた
めにフォーマットされたパラメータを受け入れることができる。たとえば、呼び出し側サ
ービスは、ユーザの名（first name）およびユーザの姓（last name）のストリングを別
々に格納することができる。しかしながら、ＰＯＳＴコマンドは、名と姓との連結ストリングを必要とする場合がある。ユーザーフレンドリーなパラメータセットを受け入れるために、クライアントライブラリ１１０２は、関数に対するパラメータとして受けたデータを、サービスエンドポイントと互換性のあるフォーマットにフォーマットする一組の動作を実行することができる。これは、ヘッダ情報の生成、特定のデータフィールドのフォーマットの変更、データフィールドの連結、その他のソースからの追加データを要求すること、計算またはデータ変換の実行などを含み得る。これはまた、再フォーマットされたパラメータを、ＪＳＯＮ、ＸＭＬなどのようなフォーマットにパッケージングすることを含み得る。

パラメータがサービスエンドポイントのためのパッケージに正しくフォーマットされると、クライアントライブラリ１１０２は、サービスに対するＰＯＳＴコールを扱うこともできる。クライアントライブラリが生成されるときに、サービスのＩＰアドレスおよびポート番号を、サービスに対するＨＴＴＰ要求で使用されるCreateUser( )関数に挿入する
ことができる。なお、ＨＴＴＰ要求の詳細は、CreateUser( )関数にカプセル化される。
呼び出し側サービスのための開発者が、サービスによって利用できるようにされたＰＯＳＴ関数の使用を所望する場合、コードをライブラリ１１０２自身に書き込む代わりに、ＡＰＩレジストリからＵｓｅｒサービスを選択することができる。そうすると、ＡＰＩレジストリは、Ｕｓｅｒクラスを含むクライアントライブラリ１１０２を自動的に生成する。次に、ＰＯＳＴ関数を使用するために、サービス開発者は、User.CreateUser(“John”, “Smith”, 2112)関数を使用するだけで、ユーザであるJohn Smithをサービスに追加することができる。

図１２は、いくつかの実施形態に係る、サービスエンドポイントとＡＰＩ関数との間の動的バインディングを含むクライアントライブラリ１２０２の実施形態を示す。この例において、ＡＰＩレジストリがクライアントライブラリ１２０２を生成するとき、CreateUser( )関数は、サービスのＩＰアドレスおよびポート番号を動的に取り出すコード１２０
４を含み得る。呼び出し側サービス１１４は、呼び出し側サービス１１４がコンテナプラットフォームのようなプロダクション／デプロイメント環境１０４で動作しているときに、GetIPPort( )関数を用いることにより実行時に要求をＡＰＩレジストリ４０４に送ることができる。ＡＰＩレジストリ４０４は、ＡＰＩ関数とサービスエンドポイントとの間の最新バインディングを維持するために常にアップデートされるその内部テーブルにアクセスすることができる。次に、ＡＰＩレジストリ４０４は、現在のＩＰアドレスおよびポート番号を呼び出し側サービス１１４に返すことができる。次に、クライアントライブラリ１２０２は、ＩＰアドレスおよびポート番号を、サービスに接続するＨＴＴＰ ＰＯＳＴコードに挿入することができる。ＡＰＩレジストリ４０４に対しては、コンテナプラットフォームにおける任意の呼び出し側サービスが実行時にアクセスできるので、コールされているサービスのポート番号についてのＩＰアドレスが変化したとき、これらのサービスのうちのいずれのサービスも、アップデートまたはパッチは不要である。代わりに、ＡＰＩレジストリ４０４は、サービスがコールされるたびに最新情報を提供することができる。いくつかの実施形態において、GetIPPort( )関数は、１時間に１度、１日に１度、１週間に１度など、ＡＰＩレジストリ４０４をコールするだけで、サービスエンドポイントはプロダクション環境において頻繁に変わるものではないという仮定のもとでサービス１１４についてコンテナの外部で行われる関数コールの数を最小にすることができる。

図１３は、いくつかの実施形態に係る、サービスコールのための入力データセットを完成させる追加データを配置できるクライアントライブラリ１３０２の実施形態を示す。クライアントライブラリ１３０２を用いた簡略化のために、クライアントライブラリ１３０２はサービス開発者に要求されるパラメータの数を最小にすることができる。サービスコ
ールを行うために必要であろう追加データは、他のソースから取り出すことができ、したがって、パラメータリストから省略してもよい。代わりに、これらの追加パラメータは、クライアントライブラリ１３０２がこれらの他のソースから直接取り出してもよい。たとえば、新たなユーザの作成は、このユーザのユーザロールを指定することを含み得る。パラメータのうちの１つとしてユーザロールを提供することをサービス開発者に要求する代わりに、クライアントライブラリ１３０２は、他のいずれかのソースからユーザのロールを自動的に取り出すコード１３０４を含み得る。この例において、ユーザロールは、データベースから、コンテナプラットフォーム内の別のサービスから、または呼び出し側サービス内のユーザロールを格納する別のクラスから、取り出すことができる。これらの場合のうちのいずれの場合でも、コード１３０４は、自動的にユーザロールを取り出し、これを、サービスに送られるＨＴＴＰ ＰＯＳＴコマンドのための入力データの一部としてパッケージングすることができる。

サービスに対する入力のためにデータを配置しフォーマットすることに加えて、クライアントライブラリ１３０２は、サービスから受けたデータをパースして返し、エラー条件を処理することができる。この例において、ＰＯＳＴコマンドはデータパケットをＲｅｓｕｌｔ（結果）変数に返すことができる。しばしば、サービスは、呼び出し側サービスが必要とする情報よりも多くの情報を含むデータパケットを返すことができる。したがって、クライアントライブラリ１３０２は、Ｒｅｓｕｌｔ変数におけるデータフィールドをパースし、データをＲｅｓｕｌｔ変数から抽出し、ユーザクラスによって予想されるより使い易いフォーマットにフォーマットしパッケージングすることができる。この例において、コード１３０６は、Ｒｅｓｕｌｔ変数からフィールドを抽出して使用することにより、ＡＰＩ関数から返される新たなＵｓｅｒオブジェクトを作成することができる。ＧＥＴコマンドを使用する別の例において、個々のＡＰＩ関数は、ＧＥＴコマンドからのＲｅｓｕｌｔ変数から異なるフィールドを抽出するＵｓｅｒクラスで生成することができる。たとえば、Ｕｓｅｒクラスは、GetFirstName(id)関数、GetLastName(id)関数、GetRole(id)関数などを提供することができる。これらの関数は各々、Ｒｅｓｕｌｔ変数から異なるフィールドを返す間、非常によく似たコードを含み得る。

結果をパースすることに加えて、クライアントライブラリ１３０２はまた、サービスの使用に対応付けられたエラー条件を処理するコード１３０８を生成することができる。この例において、コード１３０８は、Ｒｅｓｕｌｔ変数におけるステータス（status）フィールドをテストすることにより、ＰＯＳＴコマンドが成功したか否かを判断することができる。コマンドが成功していた場合、CreateUser( )関数は新たなＵｓｅｒオブジェクト
を返すことができる。Ｐｏｓｔコマンドが失敗した場合、関数は、代わりにヌルオブジェクトを返すことおよび／またはサービス対するコールをリトライすることが可能である。

図１４は、いくつかの実施形態に係る、サービスをコールするときにリトライを処理することができるクライアントライブラリ１４０２を示す。図１３の例と同様に、クライアントライブラリ１４０２は、ＰＯＳＴ ＨＴＴＰコールによってポピュレートされたＲｅｓｕｔ変数におけるステータスを使用することにより、このコールが成功したか否かを判断する。その結果が不成功である間、クライアントライブラリ１４０２は、コールが成功するまでリトライを続けることができる。いくつかの実施形態は、カウンターまたはその他のメカニズムを使用することにより、リトライの数を制限するまたはリトライとリトライとの間に待ち時間を追加することができる。

本明細書に記載の各方法は、専用コンピュータシステムによって実現することができる。これらの方法の各ステップは、当該コンピュータシステムが自動的に実行してもよく、および／またはユーザを必要とする入力／出力が与えられてもよい。たとえば、ユーザが方法の各ステップに対して入力を与えてもよく、これらの入力は各々、このような入力を
要求する、コンピュータシステムが生成した特定の出力に応じて与えられてもよい。各入力は、対応する要求出力に応じて受けられてもよい。さらに、入力は、ユーザから受けられてもよく、別のデータシステムからデータストリームとして受けられてもよく、メモリロケーションから取り出されてもよく、ネットワークを介して取り出されてもよく、ウェブサービスから要求されてもよく、および／またはその他であってもよい。同様に、出力は、ユーザに与えられてもよく、データストリームとして別のコンピュータシステムに与えられてもよく、メモリロケーションに保存されてもよく、ネットワークを介して送られてもよく、ウェブサービスに与えられてもよく、および／またはその他であってもよい。すなわち、本明細書に記載の方法の各ステップは、コンピュータシステムが実行し得るものであり、かつ、ユーザを必要とするもしくは必要としないかもしれないコンピュータシステムに対する、任意の数の入力、当該コンピュータシステムからの出力、および／または当該コンピュータシステムへの／からの要求を必要とし得るものである。ユーザを必要としないステップは、人の介入なしでコンピュータシステムが自動的に実行し得ると言える。したがって、本開示に照らして、本明細書に記載の各方法の各ステップは、ユーザへのおよびユーザからの入力および出力を含むように変更されてもよく、または、プロセッサが何らかの判断を行う場合は人の介入なしでコンピュータシステムが自動的に行ってもよい。さらに、本明細書に記載の各方法のいくつかの実施形態は、有形の非一時的な記憶媒体に格納されて有形のソフトウェアプロダクトを形成する一組の命令として実現されてもよい。

図１５は、上記実施形態のうちのいずれかとのやり取りが可能な分散型システム１５００の簡略図を示す。示されている実施形態において、分散型システム１５００は１つ以上のクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８を含み、これらのクライアントコンピューティングデバイスは、１つ以上のネットワーク１５１０を介してウェブブラウザ、専用クライアント（たとえばOracle Forms）などのようなクライアントアプリケーションを実行し操作するように構成されている。サーバ１５１２が、ネットワーク１５１０を介してリモートクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８に対して通信可能に結合されていてもよい。

各種実施形態において、サーバ１５１２は、このシステムのコンポーネントのうちの１つ以上が提供する１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされてもよい。いくつかの実施形態において、これらのサービスは、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８のユーザに対し、ウェブベースのもしくはクラウドサービスとして、またはサービスとしてのソフトウェア（ＳａａＳ）モデルのもとで、提供されてもよい。そうすると、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８を操作しているユーザは、１つ以上のクライアントアプリケーションを利用してサーバ１５１２とやり取りすることにより、これらのコンポーネントが提供するサービスを利用することができる。

図面に示される構成において、システム１５００のソフトウェアコンポーネント１５１８、１５２０および１５２２は、サーバ１５１２上に実装されたものとして示されている。他の実施形態において、システム１５００のコンポーネントおよび／またはこれらのコンポーネントが提供するサービスのうちの１つ以上が、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８のうちの１つ以上によって実装されてもよい。そうすると、クライアントコンピューティングデバイスを操作しているユーザは、１つ以上のクライアントアプリケーションを利用することにより、これらのコンポーネントが提供するサービスを使用することができる。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはその組み合わせで実装され
てもよい。分散型システム１５００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるはずである。図面に示される実施形態はしたがって、実施形態のシステムを実装するための分散型システムの一例であって、限定を意図したものではない。

クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８は、Microsoft Windows Mobile（登録商標）等のソフトウェア、および／またはiOS、Windows Phone、Android、BlackBerry 10、Palm OSその他等のさまざまなモバ
イルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、Blackberry（登録商標）、またはその他の通信プロトコルに接続可能な、ポータブルハンドヘルドデバイス（たとえばiPhone（登録商標）、携帯電話、iPad（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）であってもよい。クライアントコンピューティングデバイスは、例として、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステムを実行するパーソナルコンピュータお
よび／またはラップトップコンピュータを含む汎用パーソナルコンピュータであってもよい。クライアントコンピューティングデバイスは、限定されないがたとえばGoogle Chrome OS等のさまざまなGNU/Linux（登録商標）オペレーティングシステムを含む市場で入手
可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであってもよい。これに代えてまたはこれに加えて、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８は、ネットワーク１５１０を介して通信可能な、シンクライアントコンピュータ、インターネット接続可能なゲームシステム（たとえばKinect（登録商標）ジェスチャー入力デバイスを有するまたは有しないMicrosoft Xboxゲームコンソール）、および／またはパーソナルメッセージングデバイス等の、電子デバイスであってもよい。

具体例としての分散型システム１５００が４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートすることができる。センサなどを有するデバイスのようなその他のデバイスがサーバ１５１２とやり取りしてもよい。

分散型システム１５００のネットワーク１５１０は、限定されないがＴＣＰ／ＩＰ（transmission control protocol/Internet protocol）、ＳＮＡ（systems network architecture）、ＩＰＸ（Internet packet exchange）、AppleTalk（登録商標）などを含む、市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。一例にすぎないが、ネットワーク１５１０は、たとえばイーサネット（登録商標）、トークンリングおよび／または同様のものに基づく、ローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク１５１０は、広域ネットワークおよびインターネットであってもよい。これは、限定されないが仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえばInstitute of Electrical and Electronics（ＩＥＥＥ）８０２．１１プロト
コルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのう
ちのいずれかの下で動作するネットワーク）、および／または上記および／またはその他のネットワークの任意の組み合わせを含む、仮想ネットワークを含み得る。

サーバ１５１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジ
サーバ、メインフレームコンピュータ、ラックマウントサーバなどを含む）、サーバファーム、サーバクラスタ、または、その他任意の適切な構成および／または組み合わせからなるものであってもよい。各種実施形態において、サーバ１５１２は、上の開示で説明した１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。たとえば、サーバ１５１２は、本開示の実施形態に係る上記処理を実行するためのサーバに対応していてもよい。

サーバ１５１２は、上記オペレーティングシステムのうちのいずれかおよび市場で入手可能なサーバオペレーティングシステムを含むオペレーティングシステムを実行し得る。また、サーバ１５１２は、ＨＴＴＰ（hypertext transport protocol）サーバ、ＦＴＰ（file transfer protocol）サーバ、ＣＧＩ（common gateway interface）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、さまざまな付加的なサーバアプリケーションおよび／またはミッドティアアプリケーションのうちのいずれかを実行し得る。具体例としてのデータベースサーバは、Oracle、Microsoft、Sybase、ＩＢＭ（International Business Machines）などから市販されているものを含むが、これらに限定されない。

いくつかの実装例において、サーバ１５１２は、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８のユーザから受信したデータフィードおよび／またはイベントアップデートを分析し統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、限定されないが、１つ以上の第三者情報源および連続データストリームから受信したTwitter（登録商標）フィード、Facebook（登録商標）アップデートまたはリアルタイムアッ
プデートを含み得る。これらはセンサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る。また、サーバ１５１２は、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８の１つ以上のディスプレイデバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含み得る。

分散型システム１５００は、１つ以上のデータベース１５１４および１５１６も含み得る。データベース１５１４および１５１６はさまざまな場所に存在し得る。一例として、データベース１５１４および１５１６のうちの１つ以上は、サーバ１５１２に対してローカルな場所にある（および／またはサーバ内にある）非一時的な記憶媒体上にあってもよい。これに代えて、データベース１５１４および１５１６は、サーバ１５１２から遠隔の場所に位置してネットワークベースのまたは専用接続を介してサーバ１５１２と通信してもよい。一組の実施形態において、データベース１５１４および１５１６は、ストレージエリアネットワーク（ＳＡＮ）内にあってもよい。同様に、サーバ１５１２に帰する機能を実行するために必要な任意のファイルを、適宜、サーバ１５１２にローカルにおよび／またはサーバ１５１２から遠隔の場所に格納してもよい。一組の実施形態において、データベース１５１４および１５１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、アップデートし、取り出すようにされた、Oracleが提供するデータベース等のリレーショナルデータベースを含み得る。

図１６は、本開示の実施形態に係る、実施形態のシステムの１つ以上のコンポーネントがサービスをクラウドサービスとして提供し得るシステム環境１６００の１つ以上のコンポーネントの簡略化されたブロック図である。示されている実施形態において、システム環境１６００は、クラウドサービスを提供するクラウドインフラストラクチャシステム１６０２とやり取りするためにユーザが使用し得る１つ以上のクライアントコンピューティ
ングデバイス１６０４、１６０６、および１６０８を含む。クライアントコンピューティングデバイスは、クライアントコンピューティングデバイスのユーザがクラウドインフラストラクチャシステム１６０２とやり取りすることによってクラウドインフラストラクチャシステム１６０２が提供するサービスを使用するために用いることができる、ウェブブラウザ、専用クライアントアプリケーション（たとえばOracle Forms）、またはその他何らかのアプリケーション等のクライアントアプリケーションを操作するように構成されてもよい。

図面に示されているクラウドインフラストラクチャシステム１６０２は示されているもの以外のコンポーネントを有し得ることが理解されるはずである。さらに、図面に示されている実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一例にすぎない。他のいくつかの実施形態において、クラウドインフラストラクチャシステム１６０２は、図示されているものよりも多いまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成または配置を有していてもよい。

クライアントコンピューティングデバイス１６０４、１６０６、および１６０８は、１５０２、１５０４、１５０６、および１５０８について先に述べたものと同様のデバイスであってもよい。

具体例としてのシステム環境１６００は３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートすることができる。センサなどを有するデバイスのようなその他のデバイスがクラウドインフラストラクチャシステム１６０２とやり取りしてもよい。

ネットワーク１６１０は、クライアント１６０４、１６０６、および１６０８とクラウドインフラストラクチャシステム１６０２との間におけるデータの通信および交換を容易にすることができる。各ネットワークは、ネットワーク１５１０について先に述べたものを含む市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム１６０２は、１つ以上のコンピュータ、および／またはサーバ１５１２について先に述べたものを含み得るサーバを含み得る。

特定の実施形態において、クラウドインフラストラクチャシステムが提供するサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされているオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理された技術サポートサービスなどのような、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用できるようにされる多数のサービスを含み得る。クラウドインフラストラクチャシステムが提供するサービスは、そのユーザのニーズに合わせて動的にスケーリングすることができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものを本明細書では「サービスインスタンス」と呼ぶ。一般的に、クラウドサービスプロバイダのシステムからの、インターネットのような通信ネットワークを介してユーザが利用できるようにされる任意のサービスを、「クラウドサービス」と呼ぶ。典型的に、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストすることができ、ユーザは、インターネットのような通信ネットワークを介して、オンデマンドでこのアプリケーションをオーダーし使用することができる。

いくつかの例において、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってまたは当該技術において周知の他のやり方でユーザに提供される、ストレージ、ホストされているデータベース、ホストされているウェブサーバ、ソフトウェアアプリケーション、またはその他のサービスに対する保護されたコンピュータネットワークアクセスを含み得る。たとえば、サービスは、インターネットを介した、クラウド上の遠隔ストレージに対するパスワードで保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク化された開発者の私的使用のための、ウェブサービスベースのホストされているリレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされている電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。

特定の実施形態において、クラウドインフラストラクチャシステム１６０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼性が高く、可用性が高く、かつ安全なやり方で顧客に与えられる、アプリケーション、ミドルウェア、およびデータベースサービス提供物一式を含み得る。そのようなクラウドインフラストラクチャシステムの一例は、本願の譲受人が提供するOracle Public Cloudである。

各種実施形態において、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステム１６０２が提供するサービスに対する顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するようにされていてもよい。クラウドインフラストラクチャシステム１６０２は、異なるデプロイメントモデルを介してクラウドサービスを提供することができる。たとえば、（例としてOracle所有の）クラウドサービスを販売する組織がクラウドインフラストラクチャシステム１６０２を所有しており一般の人々または異なる産業企業がサービスを利用できるようにされるパブリッククラウドモデルの下で、サービスが提供されてもよい。別の例として、クラウドインフラストラクチャシステム１６０２が１つの組織のためにのみ運営されこの組織内の１つ以上のエンティティのためにサービスを提供し得るプライベートクラウドモデルの下で、サービスが提供されてもよい。また、クラウドインフラストラクチャシステム１６０２およびクラウドインフラストラクチャシステム１６０２が提供するサービスを関連するコミュニティー内のいくつかの組織が共有するコミュニティークラウドモデルの下で、クラウドサービスが提供されてもよい。また、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で、クラウドサービスが提供されてもよい。

いくつかの実施形態において、クラウドインフラストラクチャシステム１６０２が提供するサービスは、サービスとしてのソフトウェア（ＳａａＳ）カテゴリ、サービスとしてのプラットフォーム（ＰａａＳ）カテゴリ、サービスとしてのインフラストラクチャ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される、１つ以上のサービスを含み得る。顧客は、クラウドインフラストラクチャシステム１６０２が提供する１つ以上のサービスを、サブスクリプションオーダーを通じてオーダーすることができる。そうすると、クラウドインフラストラクチャシステム１６０２は、この顧客のサブスクリプションオーダーのサービスを提供するために処理を実行する。

いくつかの実施形態において、クラウドインフラストラクチャシステム１６０２が提供するサービスは、限定されないが、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得る。いくつかの例において、アプリケーションサービスは、クラウドインフラストラクチャシステムがＳａａＳプラットフォームを介して提供することができる。ＳａａＳプラットフォームは、ＳａａＳカテゴリに含ま
れるクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合開発およびデプロイメントプラットフォーム上でオンデマンドアプリケーション一式を構築し配信する機能を提供することができる。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理し制御することができる。ＳａａＳプラットフォームが提供するサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用することが可能である。顧客は、顧客が別々のライセンスおよびサポートを購入しなくても、アプリケーションサービスを得ることが可能である。さまざまな異なるＳａａＳサービスを提供することができる。例は、限定されないが、大組織向けの販売実績管理、企業統合、およびビジネスフレキシビリティのためのソリューションを提供するサービスを含む。

いくつかの実施形態において、プラットフォームサービスは、クラウドインフラストラクチャシステムがＰａａＳプラットフォームを介して提供することができる。ＰａａＳプラットフォームは、ＰａａＳカテゴリに含まれるクラウドサービスを提供するように構成し得る。プラットフォームサービスの例は、限定されないが、共有されている共通アーキテクチャ上の既存のアプリケーションを組織（Oracle等）が統合することを可能にするサービスと、当該プラットフォームが提供する共有サービスを推進する新たなアプリケーションを構築する機能とを含み得る。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理し制御することができる。顧客は、顧客が別々のライセンスおよびサポートを購入しなくても、クラウドインフラストラクチャシステムが提供するＰａａＳサービスを得ることが可能である。プラットフォームサービスの例は、限定されないが、Oracle Java Cloud Service（ＪＣＳ
）、Oracle Database Cloud Service（ＤＢＣＳ）その他を含む。

ＰａａＳプラットフォームが提供するサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態において、クラウドインフラストラクチャシステムが提供するプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばOracle Fusion Middlewareサービス）、およびＪａｖａクラウドサービスを含み得る。一実施形態において、データベースクラウドサービスは、組織がデータベースリソースをプールしデータベースクラウドの形態でサービスとしてのデータベース（Database as a Service）
を顧客に提供することを可能にする共有サービスデプロイメントモデルをサポートすることができる。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発しデプロイするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいて顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームを提供してもよい。

さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおいてＩａａＳプラットフォームが提供してもよい。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームが提供するサービスを利用する顧客のためのストレージ、ネットワーク、および他の基本的なコンピューティングリソース等の、基礎となるコンピューティングリソースの管理および制御を容易にする。

特定の実施形態において、クラウドインフラストラクチャシステム１６０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために用いられるリソースを提供するためのインフラストラクチャリソース１６３０を含み得る。一実施形態において、インフラストラクチャリソース１６３０は、ＰａａＳプラットフォー
ムおよびＳａａＳプラットフォームが提供するサービスを実行するためのサーバ、ストレージ、およびネットワーキングリソース等のハードウェアの、予め統合し最適化した組み合わせを含み得る。

いくつかの実施形態において、クラウドインフラストラクチャシステム１６０２におけるリソースは、複数のユーザによって共有され要求ごとに動的に再割り当てされてもよい。加えて、リソースは、異なるタイムゾーンのユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム１６０２は、第１のタイムゾーンの第１組のユーザが指定された時間数だけクラウドインフラストラクチャシステムのリソースを利用することを可能にし、それから、異なるタイムゾーンにいる別の１組のユーザに対して同じリソースを再割り当てすることにより、リソースの利用を最大化することができる。

特定の実施形態において、クラウドインフラストラクチャシステム１６０２の異なるコンポーネントまたはモジュールによって共有され、クラウドインフラストラクチャシステム１６０２が提供するサービスによって共有される、複数の内部共有サービス１６３２を提供することができる。これらの内部共有サービスは、限定されないが、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャーサービス、ウィルススキャンおよびホワイトリストサービス、高可用性、バックアップおよびリカバリサービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得る。

特定の実施形態において、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえばＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供し得る。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム１６０２が受けた顧客のサブスクリプションをプロビジョニング、管理、および追跡する機能を含み得る。

一実施形態において、図面に示されるように、クラウド管理機能は、オーダー管理モジュール１６２０、オーダーオーケストレーションモジュール１６２２、オーダープロビジョニングモジュール１６２４、オーダー管理およびモニタリングモジュール１６２６、ならびにアイデンティティ管理モジュール１６２８等の、１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他任意の適切な構成および／または組み合わせであってもよい、１つ以上のコンピュータおよび／またはサーバを含み得る、または、これらを用いて提供し得る。

具体例としての動作１６３４において、クライアントデバイス１６０４、１６０６または１６０８等のクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム１６０２が提供する１つ以上のサービスを要求すること、および、クラウドインフラストラクチャシステム１６０２が提示する１つ以上のサービスのサブスクリプションをオーダーすることにより、クラウドインフラストラクチャシステム１６０２とやり取りしてもよい。特定の実施形態において、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ １６１２、クラウドＵＩ １６１４および／またはクラウドＵＩ １６１６にアクセスしこれらのＵＩを介してサブスクリプションオーダーを行ってもよい。顧客がオーダーを行ったことに応じてクラウドインフラストラクチャシステム１６０２が受けるオーダー情報は、顧客を特定する情報と、クラウドインフラストラクチャシステム１６０２が提供する、顧客がサブスクライブする予定の１つ以上のサービスとを含み得る。

顧客がオーダーを行った後に、オーダー情報は、クラウドＵＩ １６１２、１６１４および／または１６１６を介して受信される。

動作１６３６において、オーダーはオーダーデータベース１６１８に格納される。オーダーデータベース１６１８は、クラウドインフラストラクチャシステム１６０２によって運営され他のシステム要素とともに運営されるいくつかのデータベースのうちの１つであってもよい。

動作１６３８において、オーダー情報はオーダー管理モジュール１６２０に転送されてもよい。いくつかの例において、オーダー管理モジュール１６２０は、オーダーを確認し確認後にオーダーを記入する等の、オーダーに関連する課金および会計機能を行うように構成されてもよい。

動作１６４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール１６２２に伝えられる。オーダーオーケストレーションモジュール１６２２は、オーダー情報を利用することにより、顧客によって行われたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするように構成されてもよい。いくつかの例において、オーダーオーケストレーションモジュール１６２２は、リソースのプロビジョニングをオーケストレーションすることにより、オーダープロビジョニングモジュール１６２４のサービスを使用するサブスクライブされたサービスを、サポートしてもよい。

特定の実施形態において、オーダーオーケストレーションモジュール１６２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用することにより、オーダーがプロビジョニングに進むべきか否かを判断する。動作１６４２において、新規サブスクリプションのオーダーを受けると、オーダーオーケストレーションモジュール１６２２は、サブスクリプションオーダーを遂行するのに必要なリソースを割り当てて構成することを求める要求を、オーダープロビジョニングモジュール１６２４に送る。オーダープロビジョニングモジュール１６２４は、顧客がオーダーしたサービスのためのリソースの割当を可能にする。オーダープロビジョニングモジュール１６２４は、クラウドインフラストラクチャシステム１６０２が提供するクラウドサービスと、要求されたサービスを提供するためのリソースのプロビジョニングに使用される物理実装層との間の抽象化レベルを提供する。このようにして、オーダーオーケストレーションモジュール１６２２を、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または、予めプロビジョニングされており要求後に割り当て／アサインされるか否か等の、実装の詳細から切り離すことができる。

動作１６４４において、サービスおよびリソースがプロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム１６０２のオーダープロビジョニングモジュール１６２４によってクライアントデバイス１６０４、１６０６および／または１６０８の顧客に送信されてもよい。

動作１６４６において、顧客のサブスクリプションオーダーは、オーダー管理およびモニタリングモジュール１６２６によって管理および追跡されてもよい。いくつかの例において、オーダー管理およびモニタリングモジュール１６２６は、ストレージ使用量、転送データ量、ユーザ数、ならびにシステムアップタイムおよびシステムダウンタイムの量等の、サブスクリプションオーダーにおけるサービスの使用統計を収集するように構成されてもよい。

特定の実施形態において、クラウドインフラストラクチャシステム１６０２はアイデンティティ管理モジュール１６２８を含み得る。アイデンティティ管理モジュール１６２８は、クラウドインフラストラクチャシステム１６０２におけるアクセス管理および認可サ
ービス等のアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態において、アイデンティティ管理モジュール１６２８は、クラウドインフラストラクチャシステム１６０２が提供するサービスの利用を所望する顧客に関する情報を管理してもよい。そのような情報は、このような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に関してこれらの顧客が実行を認可されるアクションを記述する情報とを含み得る。アイデンティティ管理モジュール１６２８は、各顧客に関し、かつ、誰が如何にしてこの記述情報にアクセスし修正することができるかに関する記述情報の管理も含み得る。

図１７は、本発明の各種実施形態を実現し得る具体例としてのコンピュータシステム１７００を示す。システム１７００を用いることにより、上記コンピュータシステムのうちのいずれかを実現することができる。図面に示されるように、コンピュータシステム１７００は、バスサブシステム１７０２を介して複数の周辺サブシステムと通信する処理ユニット１７０４を含む。これらの周辺サブシステムは、処理加速ユニット１７０６と、入出力サブシステム１７０８と、記憶サブシステム１７１８と、通信サブシステム１７２４とを含み得る。記憶サブシステム１７１８は、有形のコンピュータ読取可能記憶媒体１７２２とシステムメモリ１７１０とを含み得る。

バスサブシステム１７０２は、コンピュータシステム１７００の各種コンポーネントおよびサブシステムを目的に合わせて互いに通信させるためのメカニズムを提供する。バスサブシステム１７０２は１つのバスとして概略的に示されているが、バスサブシステムの代替実施形態は複数のバスを利用し得る。バスサブシステム１７０２は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、Industry Standard Architecture（ＩＳＡ）バス、Micro Channel Architecture（ＭＣＡ）バス、Enhanced ISA（ＥＩＳＡ）バス、Video Electronics Standards Association（ＶＥＳＡ）ローカルバス、および、Ｉ
ＥＥＥ Ｐ１３８６．１規格に準拠して製造されたMezzanineバスとして実装することが
できるPeripheral Component Interconnect（ＰＣＩ）バスを含み得る。

１つ以上の集積回路（たとえば従来のマイクロプロセッサまたはマイクロコントローラ）として実現することができる処理ユニット１７０４は、コンピュータシステム１７００の動作を制御する。１つ以上のプロセッサが処理ユニット１７０４に含まれていてもよい。これらのプロセッサはシングルコアまたはマルチコアプロセッサを含み得る。特定の実施形態において、処理ユニット１７０４は、１つ以上の独立した処理ユニット１７３２および／または１７３４として、各処理ユニットに含まれるシングルまたはマルチコアプロセッサとともに実現されてもよい。他の実施形態において、処理ユニット１７０４はまた、２つのデュアルコアプロセッサを１つのチップに統合することによって形成されるクアッドコア処理ユニットとして実現されてもよい。

各種実施形態において、処理ユニット１７０４は、プログラムコードに応じてさまざまなプログラムを実行することができ、かつ、同時に実行している複数のプログラムまたはプロセスを管理することができる。ある所定の時点で、実行すべきプログラムコードのうちの一部またはすべてが、プロセッサ１７０４および／または記憶サブシステム１７１８にあってもよい。適切なプログラミングを通して、プロセッサ１７０４は上記各種機能を提供することができる。コンピュータシステム１７００はさらに、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／またはその他同様のものを含むことができる、処理加速ユニット１７０６を含み得る。

入出力サブシステム１７０８は、ユーザインターフェイス入力デバイスと、ユーザインターフェイス出力デバイスとを含み得る。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボール等のポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付きの音声入力デバイス、マイク、およびその他のタイプの入力デバイスを含み得る。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャーおよび発話コマンドを使用するナチュラルユーザインターフェイスを通してユーザが入力デバイスを制御し入力デバイスとやり取りすることを可能にする、Microsoft Xbox（登録商標）３６０ゲームコントローラ等のMicrosoft Kinect（登録商標）モーションセンサのような、モーション検知および／またはジェスチャー認識デバイスを含み得る。ユーザインターフェイス入力デバイスはまた、ユーザの目の活動（たとえば写真撮影中および／またはメニュー選択中の「まばたき」）を検出し目のジェスチャーを入力デバイス（たとえばGoogle Glass（登録商標）)への入力
として変換する、Google Glass（登録商標）まばたき検出器等のアイジェスチャー認識デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを通して音声認識システム（たとえばSiri（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識検知デバイスを含み得る。

ユーザインターフェイス入力デバイスはまた、限定されないが、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカ等のオーディオ／ビジュアルデバイス、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレイヤー、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダー３Ｄスキャナ、３Ｄプリンタ、レーザ測距装置、および視線追跡デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン断層撮影装置、医療用超音波検査装置等の医療用撮像入力デバイスを含み得る。ユーザインターフェイス入力デバイスはまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などのような音声入力装置を含み得る。

ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、表示灯、または音声出力装置等の非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを用いるもの等のフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般的に、「出力デバイス」という用語を使用する場合は、コンピュータシステム１７００からユーザまたは他のコンピュータに情報を出力するための可能なすべてのタイプのデバイスおよびメカニズムを含むことを意図している。たとえば、ユーザインターフェイス出力デバイスは、限定されないが、モニタ、プリンタ、スピーカ、ヘッドホン、カーナビゲーションシステム、プロッタ、音声出力デバイス、およびモデム等の、テキスト、図形、およびオーディオ／ビデオ情報を視覚的に伝えるさまざまなディスプレイデバイスを含み得る。

コンピュータシステム１７００は、現在はシステムメモリ１７１０内にあるものとして示されているソフトウェア要素を含むストレージサブシステム１７１８を含み得る。システムメモリ１７１０は、処理ユニット１７０４上にローディング可能であり処理ユニット上で実行可能なプログラム命令と、これらのプログラムの実行中に生成されたデータとを格納することができる。

コンピュータシステム１７００の構成および種類に応じて、システムメモリ１７１０は、揮発性（たとえばランダムアクセスメモリ（ＲＡＭ））であってもよく、および／または不揮発性（たとえば読出専用メモリ（ＲＯＭ）、フラッシュメモリなど）であってもよ
い。典型的に、ＲＡＭは、処理ユニット１７０４が直ちにアクセス可能でありおよび／または現在操作し実行している、データおよび／またはプログラムモジュールを含む。いくつかの実装例において、システムメモリ１７１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の複数の異なる種類のメモリを含み得る。いくつかの実装例において、たとえば起動中のコンピュータシステム１７００内の要素間の情報の転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、典型的にはＲＯＭに格納することができる。例として、限定されないが、システムメモリ１７１０はまた、クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１７１２と、プログラムデータ１７１４と、オペレーティングシステム１７１６とを示している。例として、オペレーティングシステム１７１６は、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステム、市
場で入手可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステム（限定されないが多様なGNU/Linux（登録商標）オペレーティングシステム、Google Chrome（登録商標）OSなどを含む）、および／またはiOS、Windows（登録商標）Phone、Android（登録商標） OS、BlackBerry（登録商標） 10 OS、およびPalm（登録商標） OSオペレーティングシステム等のモバイルオペレーティングシステムを含み得る。

ストレージサブシステム１７１８はまた、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能記憶媒体を提供することができる。プロセッサによって実行されると上記機能を実行するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム１７１８に格納することができる。これらのソフトウェアモジュールまたは命令は、処理ユニット１７０４によって実行されてもよい。ストレージサブシステムｙ１７１８はまた、本発明に従い使用されるデータを格納するためのリポジトリを提供することができる。

ストレージサブシステム１７１８はまた、コンピュータ読取可能記憶媒体１７２２にさらに接続することが可能なコンピュータ読取可能記憶媒体リーダー１７２０を含み得る。システムメモリ１７１０とともに、また、任意でシステムメモリ１７１０と組み合わされて、コンピュータ読取可能記憶媒体１７２２は、コンピュータ読取可能情報を一時的におよび／またはより恒久的に含む、格納する、送信する、および取り出すための、リモート、ローカル、固定、および／またはリムーバブル記憶装置プラス記憶媒体を包括的に表すことができる。

コードまたはコードの一部を含むコンピュータ読取可能記憶媒体１７２２はまた、限定されないが、情報の記憶および／または送信のための任意の方法または技術で実現される、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体等の、記憶媒体および通信媒体を含む、当該技術において周知のまたは使用されている適切な任意の媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的に消去可能プログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリまたはその他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）、もしくはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくはその他の磁気記憶装置、または、他の有形のコンピュータ読取可能媒体等の、有形のコンピュータ読取可能記憶媒体を含み得る。これはまた、所望の情報を送信するために使用することができコンピューティングシステム１７００がアクセスすることができる、データ信号、データ送信、またはその他任意の媒体等の、非有形コンピュータ読取可能媒体を含み得る。

例として、コンピュータ読取可能記憶媒体１７２２は、非リムーバブル不揮発性磁気媒体からの読取およびこの媒体への書込を行うハードディスクドライブ、リムーバブル不揮
発性磁気ディスクからの読取およびこのディスクへの書込を行う磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、Blu-Ray（登録商標）ディスク、またはその他の光学
媒体等のリムーバブル不揮発性光ディスクからの読取およびこのディスクへの書込を行う光ディスクドライブを含み得る。コンピュータ読取可能記憶媒体１７２２は、限定されないが、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得る。コンピュータ読取可能記憶媒体１７２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどのような、不揮発性メモリベースのソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ等の揮発性メモリベースのＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、ならびにＤＲＡＭおよびフラッシュメモリベースのＳＳＤの組み合わせを用いるハイブリッドＳＳＤを、含み得る。ディスクドライブおよびこれらに対応付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、およびコンピュータシステム１７００のためのその他のデータの不揮発性ストレージを提供することができる。

通信サブシステム１７２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム１７２４は、他のシステムからデータを受信し、コンピュータシステム１７００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム１７２４は、コンピュータシステム１７００がインターネットを介して１つ以上のデバイスに接続することを可能にする。いくつかの実施形態において、通信サブシステム１７２４は、（たとえば携帯電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（enhanced data rates for global evolution）等の高度データネットワーク技術、ＷｉＦｉ（登録商標）（ＩＥＥＥ ８０２．１１系規格、または他の移動通信技術、またはそれらの任意の組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバーコンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、および／またはその他のコンポーネントを含み得る。いくつかの実施形態において、通信サブシステム１７２４は、無線インターフェイスに加えてまたはその代わりに、有線ネットワークコネクティビティ（たとえばイーサネット（登録商標））を提供することができる。

いくつかの実施形態において、通信サブシステム１７２４は、コンピュータシステム１７００を使用し得る１人以上のユーザの代わりに、構造化および／または非構造化データフィード１７２６、イベントストリーム１７２８、イベントアップデート１７３０などの形態の入力通信を受けることもできる。

例として、通信サブシステム１７２４は、Twitter（登録商標）フィード、Facebook（
登録商標）アップデート、Rich Site Summary（ＲＳＳ）フィード等のウェブフィード、
および／または１つ以上の第３者情報源からのリアルタイムアップデート等の、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード１７２６をリアルタイムで受信するように構成されてもよい。

加えて、通信サブシステム１７２４は、明確な終わりがない本質的に連続しているまたは無限である可能性があるリアルタイムイベントのイベントストリーム１７２８および／またはイベントアップデート１７３０を含み得る、連続データストリームの形態のデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含み得る。

通信サブシステム１７２４はまた、構造化および／または非構造化データフィード１７２６、イベントストリーム１７２８、イベントアップデート１７３０などを、コンピュータシステム１７００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム１７００は、ハンドヘルドポータブルデバイス（たとえばiPhone（登録商標）携帯電話、iPad（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他任意のデータ処理システムを含む、さまざまなタイプのうちの１つであってもよい。

コンピュータおよびネットワークには常に変化しているという性質があるので、図面に示されるコンピュータシステム１７００の説明は、具体的な一例を意図しているにすぎない。図面に示されるシステムよりも多くのまたは少ないコンポーネントを有するその他多数の構成が可能である。たとえば、カスタマイズされたハードウェアが使用されてもよく、および／または特定の要素がハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実現されてもよい。さらに、ネットワーク入出力デバイスのようなその他のコンピューティングデバイスに対する接続を用いてもよい。本明細書で提供される開示および教示に基づいて、当業者は、各種実施形態を実現するためのその他のやり方および／または方法を理解するであろう。

上述の記載では、説明のために、本発明の各種実施形態の十分な理解が得られるよう、数多くの具体的な詳細を述べている。しかしながら、当業者には、本発明の実施形態はこれらの具体的な詳細のうちの一部がなくても実施し得ることが明らかであろう。その他の例では、周知の構造およびデバイスはブロック図の形態で示されている。

上述の記載は、具体例としての実施形態を提供しているだけであって、本開示の範囲、利用可能性、または構成を限定することを意図しているのではない。むしろ、具体例としての実施形態の上述の記載は、具体例としての実施形態を実現することを可能にする説明を当業者に提供するであろう。以下の請求項に記載の本発明の精神および範囲から逸脱することなく、要素の機能および構成に各種変更を加え得ることが理解されるはずである。

上述の記載において、具体的な詳細は、実施形態の十分な理解を得るために提供されている。しかしながら、当業者は、実施形態はこれらの具体的な詳細がなくても実現し得ることを理解するであろう。たとえば、回路、システム、ネットワーク、プロセス、およびその他のコンポーネントは、実施形態を不必要な詳細で不明瞭にすることがないよう、ブロック図の形態のコンポーネントとして示されている場合がある。その他の例において、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態を不明瞭にすることを避けるために不必要な詳細なしで示されている場合がある。

また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして記載されている場合があることが注目される。フローチャートは動作を逐次プロセスとして説明している場合があるが、動作のうちの多くは並列または同時に実行することができる。加えて、動作の順序は構成し直してもよい。プロセスは、その動作が完了すると終了するが、図面に含まれていない追加のステップを有する可能性がある。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応する場合、その終了は、この関数が呼び出し側関数またはメイン関数に戻ることに相当し得る。

「コンピュータ読取可能媒体」という用語は、携帯型または固定記憶装置、光記憶装置、無線チャネル、ならびに、命令および／またはデータを格納する、含む、または保持することが可能なその他の各種媒体を含むが、これらに限定される訳ではない。コードセグメントまたはマシン実行可能命令は、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または、命令、データ構造、もしくはプログラムステートメントの任意の組み合わせを表し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリコンテンツを送ることおよび／または受けることにより、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む任意の適切な手段を介して、送る、転送する、または送信することができる。

さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはその任意の組み合わせによって実現することができる。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実現するとき、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、マシン読取可能媒体に格納されていてもよい。プロセッサ（複数のプロセッサ）が必要なタスクを実行してもよい。

上述の明細書では、本発明の局面を、その具体的な実施形態を参照しながら説明しているが、本発明がこれらの実施形態に限定される訳ではないことを当業者は認識するであろう。上記発明の各種特徴および局面は、個別に使用されてもよく、またはともに使用されてもよい。さらに、実施形態は、本明細書のより広い精神および範囲から逸脱することなく、本明細書に記載の環境およびアプリケーションを超える、任意の数の環境およびアプリケーションで利用することができる。したがって、本明細書および図面は、限定的なものではなく例示的なものであるとみなされねばならない。

加えて、説明のために、方法は特定の順序で記載されている。代替実施形態においてこれらの方法は記載されている順序と異なる順序で実行され得ることが理解されるはずである。上記方法は、ハードウェアコンポーネントによって実行されてもよく、またはマシン実行可能命令のシーケンスで実施されてもよいことも、理解されるはずである。マシン実行可能命令は、当該命令でプログラミングされた汎用もしくは専用プロセッサまたは論理回路のようなマシンに当該方法を実行させるために使用することができる。これらのマシン実行可能命令は、ＣＤ－ＲＯＭもしくはその他のタイプの光ディスク、フロッピー（登録商標）ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、フラッシュメモリ、または、電子命令を格納するのに適したその他のタイプのマシン読取可能媒体等の、１つ以上のマシン読取可能媒体に、格納されてもよい。これに代えて、当該方法はハードウェアとソフトウェアとの組み合わせによって実行されてもよい。

Claims (20)

1. コンテナ環境内の登録されたサービスエンドポイントに対するアプリケーションプログラミングインターフェイス（ＡＰＩ）関数を与える方法であって、前記方法は、
   ＡＰＩレジストリにおいてＡＰＩ定義を受けるステップを含み、前記ＡＰＩ定義は、
   コンテナ環境にデプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、
   １つ以上のＡＰＩ関数とを含み、前記方法はさらに、
   前記ＡＰＩレジストリが、前記１つ以上のＡＰＩ関数と前記サービスのエンドポイントとの間のバインディングを作成するステップと、
   前記ＡＰＩレジストリが、前記第１のサービスの使用を求める要求を第２のサービスから受けるステップと、
   前記ＡＰＩレジストリが、前記１つ以上のＡＰＩ関数を前記第２のサービスに与えるステップとを含む、方法。
2. 前記１つ以上のＡＰＩ関数を含む前記第２のサービスのためのクライアントライブラリを生成するステップをさらに含む、請求項１に記載の方法。
3. 前記クライアントライブラリは、前記ＡＰＩ関数を実現するメンバ関数とともにオブジェクトクラスを含む、請求項２に記載の方法。
4. 前記クライアントライブラリは、前記第１のサービスのエンドポイントに対するダイレクトコールを含む、請求項２に記載の方法。
5. 前記クライアントライブラリは、前記１つ以上のＡＰＩ関数のうちの１つが前記第２のサービスによってコールされたときに前記第１のサービスのエンドポイントを実行時にアップデートするコードを含む、請求項２に記載の方法。
6. 前記クライアントライブラリは、前記１つ以上のＡＰＩ関数の１つ以上のパラメータとして受けたデータを、前記第１のサービスのエンドポイントに対するＨＴＴＰコールに再フォーマットする、請求項２に記載の方法。
7. 前記クライアントライブラリは、前記第１のサービスのエンドポイントの前記ＨＴＴＰコールに加えるための追加情報を第３のサービスに要求する、請求項６に記載の方法。
8. 前記クライアントライブラリは、前記第１のサービスに対する失敗コールをリトライするコードを含む、請求項２に記載の方法。
9. 前記クライアントライブラリは、結果値を前記第１のサービスの結果セットから抽出し前記結果値を前記１つ以上のＡＰＩ関数に対するリターン値としてパッケージングするコードを含む、請求項２に記載の方法。
10. １つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む非一時的なコンピュータ読取可能媒体であって、前記動作は、
    ＡＰＩレジストリにおいてＡＰＩ定義を受けることを含み、前記ＡＰＩ定義は、
    コンテナ環境にデプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、
    １つ以上のＡＰＩ関数とを含み、前記動作はさらに、
    前記ＡＰＩレジストリが、前記１つ以上のＡＰＩ関数と前記サービスのエンドポイントとの間のバインディングを作成することと、
    前記ＡＰＩレジストリが、前記第１のサービスの使用を求める要求を第２のサービスから受けることと、
    前記ＡＰＩレジストリが、前記１つ以上のＡＰＩ関数を前記第２のサービスに与えることとを含む、非一時的なコンピュータ読取可能媒体。
11. 前記第１のサービスのエンドポイントは、
    ＩＰアドレスと、
    ポート番号とを含む、請求項１０に記載の非一時的なコンピュータ読取可能媒体。
12. 前記コンテナ環境は、コンテナにカプセル化された複数のサービスを含む、請求項１０に記載の非一時的なコンピュータ読取可能媒体。
13. 前記ＡＰＩレジストリは、前記コンテナ環境内のコンテナにカプセル化されたサービスとしてデプロイされる、請求項１０に記載の非一時的なコンピュータ読取可能媒体。
14. 前記ＡＰＩレジストリは、
    統合開発環境（ＩＤＥ）において開発中のサービスと、
    前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項１０に記載の非一時的なコンピュータ読取可能媒体。
15. 前記動作はさらに、前記ＡＰＩレジストリが、前記コンテナ環境にデプロイされているコンテナ化されたサービスの任意の利用できるエンドポイントを識別することを含む、請求項１０に記載の非一時的なコンピュータ読取可能媒体。
16. １つ以上のプロセッサと、
    １つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
    ＡＰＩレジストリにおいてＡＰＩ定義を受けることを含み、前記ＡＰＩ定義は、
    コンテナ環境にデプロイされたコンテナにカプセル化された第１のサービスのエンドポイントと、
    １つ以上のＡＰＩ関数とを含み、前記動作はさらに、
    前記ＡＰＩレジストリが、前記１つ以上のＡＰＩ関数と前記サービスのエンドポイントとの間のバインディングを作成することと、
    前記ＡＰＩレジストリが、前記第１のサービスの使用を求める要求を第２のサービスから受けることと、
    前記ＡＰＩレジストリが、前記１つ以上のＡＰＩ関数を前記第２のサービスに与えることとを含む、システム。
17. 前記動作はさらに、前記ＡＰＩレジストリに登録されたすべてのサービスに対するＡＰＩ関数のリストをユーザインターフェイスに表示させることを含む、請求項１６に記載のシステム。
18. 前記第１のサービスの使用を求める前記第２のサービスからの要求は、前記ユーザインターフェイスに表示された前記１つ以上のＡＰＩ関数のうちの１つの選択を受けることによって受ける、請求項１７に記載のシステム。
19. 前記ユーザインターフェイスはコマンドラインインターフェイスを含む、請求項１７に記載のシステム。
20. 前記ユーザインターフェイスはグラフィカルユーザインターフェイスを含む、請求項１７に記載のシステム。

Images