▶ オラクル・インターナショナル・コーポレイションの特許一覧
特開2023-27098マイクロサービスの構成および管理を可能にするＡＰＩリポジトリ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023027098
(43)【公開日】2023-03-01
(54)【発明の名称】マイクロサービスの構成および管理を可能にするＡＰＩリポジトリ
(51)【国際特許分類】
G06F 8/60 20180101AFI20230221BHJP
【ＦＩ】
G06F8/60
【審査請求】有
【請求項の数】20
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2022185721
(22)【出願日】2022-11-21
(62)【分割の表示】P 2020518487の分割
【原出願日】2018-09-28
(31)【優先権主張番号】62/566,351
(32)【優先日】2017-09-30
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ ＰＨＯＮＥ
２．ｉＯＳ
３．ＰＡＬＭ ＯＳ
(71)【出願人】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】カルダト，クラウディオ
(72)【発明者】
【氏名】ショール，ボリス
(57)【要約】 （修正有）
【課題】コンテナ環境におけるサービスのデプロイメントおよび動作をカスタマイズする方法、システム及び非一時的なコンピュータ読取可能媒体を提供する。
【解決手段】方法は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受け、コンテナ環境へのサービスのデプロイメントにサービスのプロパティが影響するか否かを判断し、サービスのデプロイメントにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスをデプロイする。さらに、コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成する。
【選択図】図１５Ａ
【解決手段】方法は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受け、コンテナ環境へのサービスのデプロイメントにサービスのプロパティが影響するか否かを判断し、サービスのデプロイメントにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスをデプロイする。さらに、コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成する。
【選択図】図１５Ａ
【特許請求の範囲】
【請求項1】
コンテナ環境におけるサービスのデプロイメントおよび動作をカスタマイズする方法であって、前記方法は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断し、前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成するステップと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理するステップとを含む、方法。
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断し、前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成するステップと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理するステップとを含む、方法。
【請求項2】
前記プロパティは、前記ＡＰＩレジストリが実行するコードを含む、請求項１に記載の方法。
【請求項3】
前記プロパティは、実行する予め定められたプロセスを選択するために前記ＡＰＩレジストリが使用するフラグを含む、請求項１に記載の方法。
【請求項4】
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断するステップは、前記サービスは高可用性を有するように前記コンテナ環境にデプロイされねばならないことを前記プロパティが示していると判断するステップを含む、請求項１に記載の方法。
【請求項5】
前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップは、前記サービスのコンテナ化された複数のインスタンスを前記コンテナ環境にデプロイするステップを含む、請求項４に記載の方法。
【請求項6】
前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断するステップは、前記サービスはエンドツーエンド暗号化を必要とすることを前記プロパティが示していると判断するステップを含む、請求項１に記載の方法。
【請求項7】
前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成するステップは、サービスコールにおいて前記サービスのエンドポイントに送られる前にデータを暗号化するコードを前記クライアントライブラリに生成するステップを含む、請求項６に記載の方法。
【請求項8】
前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断するステップは、呼び出し側サービスが前記サービスの使用をロギングしなければならないことを前記プロパティが示していると判断するステップを含む、請求項１に記載の方法。
【請求項9】
前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成するステップは、前記サービスのエンドポイントに対するコールの使用情報をロギングするコードを前記クライアントライブラリに生成するステップを含む、請求項８に記載の方法。
【請求項10】
前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断するステップは、前記コンテナ環境において前記サービスはオンデマンドでインスタンス化されねばならないことを前記プロパティが示していると判断するステップを含む、請求項１に記載の方法。
【請求項11】
前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理するステップは、前記ＡＰＩレジストリが、前記サービスに対して呼び出し側サービスが要求を送るという表示を受けたことに応じて、前記サービスのコンテナ化されたインスタンスを生成するステップを含む、請求項１０に記載の方法。
【請求項12】
１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む非一時的なコンピュータ読取可能媒体であって、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイすることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断し、前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、非一時的なコンピュータ読取可能媒体。
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイすることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断し、前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、非一時的なコンピュータ読取可能媒体。
【請求項13】
前記クライアントライブラリは、前記サービスのエンドポイントに対するダイレクトコールを行うためにＡＰＩ関数を実現するメンバ関数とともにオブジェクトクラスを含む、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
【請求項14】
前記動作はさらに、前記ＡＰＩレジストリにおいて、前記コンテナ環境における前記サービスのエンドポイントと１つ以上のＡＰＩ関数とを含むＡＰＩ定義を受けることを含む、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
【請求項15】
前記サービスの前記プロパティを前記ＡＰＩ定義とともに受ける、請求項１４に記載の非一時的なコンピュータ読取可能媒体。
【請求項16】
前記コンテナ環境は、コンテナにカプセル化された複数のサービスを含む、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
【請求項17】
前記ＡＰＩレジストリは、前記コンテナ環境内のコンテナにカプセル化されたサービスとしてデプロイされる、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
【請求項18】
前記ＡＰＩレジストリは、
統合開発環境（ＩＤＥ）において開発中のサービスと、
前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
統合開発環境（ＩＤＥ）において開発中のサービスと、
前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
【請求項19】
１つ以上のプロセッサと、
１つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイすることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断し、前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、システム。
１つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイすることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響するか否かを判断し、前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断し、前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、システム。
【請求項20】
前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響するか否かを判断することは、前記コンテナ環境において前記サービスがコールされたときに前記サービスはレート制限されねばならないことを前記プロパティが示していると判断することを含む、請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本願は、本明細書に引用により援用する２０１７年９月３０日出願の米国仮出願第６２／５６６，３５１号に基づく利益を主張する。本願はまた、本願と同日に出願され本願と共通の譲受人に譲渡された以下の出願に関連し、これらの出願各々も本明細書に引用により援用する。
・２０１８年９月２８日に出願されAPI REGISTRY IN A CONTAINER PLATFORM FOR AUTOMATICALLY GENERATING CLIENT CODE LIBRARIESと題された米国特許出願第１６／１４７，３
３４号（代理人整理番号０８８３２５－１０９０７４５）
・２０１８年９月２８日に出願され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と題された米国特許出願１６／１４７，３５１号（代理人整理番号０８８３２５－１０９０７５３）
本願は、本明細書に引用により援用する２０１７年９月３０日出願の米国仮出願第６２／５６６，３５１号に基づく利益を主張する。本願はまた、本願と同日に出願され本願と共通の譲受人に譲渡された以下の出願に関連し、これらの出願各々も本明細書に引用により援用する。
・２０１８年９月２８日に出願されAPI REGISTRY IN A CONTAINER PLATFORM FOR AUTOMATICALLY GENERATING CLIENT CODE LIBRARIESと題された米国特許出願第１６／１４７，３
３４号（代理人整理番号０８８３２５－１０９０７４５）
・２０１８年９月２８日に出願され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と題された米国特許出願１６／１４７，３５１号（代理人整理番号０８８３２５－１０９０７５３）
【背景技術】
【0002】
背景
理論上、任意の形態のコンテナは、情報のパッケージングおよび情報との対話のための標準化された方法を表している。コンテナは、互いに分離することが可能であり、相互汚染（コンタミネーション）のいかなるリスクも伴うことなく並列に使用することが可能である。現代のソフトウェアの世界において、「コンテナ」という用語は固有の意味を獲得している。Docker（登録商標）コンテナのようなソフトウェアコンテナは、１つのソフトウェアを論理的にカプセル化し定義するソフトウェア構造である。コンテナにカプセル化される最も一般的なタイプのソフトウェアは、アプリケーション、サービス、またはマイクロサービスである。現代のコンテナはまた、オペレーティングシステム、ライブラリ、ストレージボリューム、構成ファイル、アプリケーションバイナリ、および、典型的なコンピューティング環境において見出されるであろうテクノロジースタックのその他の部分のような、アプリケーション／サービスが動作するのに必要なソフトウェアサポートすべてを含む。そのため、このコンテナ環境を使用することにより、各々が自身のサービスを任意の環境で実行する複数のコンテナを作成することができる。コンテナは、プロダクションデータセンター、オンプレミスデータセンター、クラウドコンピューティングプラットフォームなどにおいて、いかなる変更も伴うことなくデプロイすることができる。クラウド上にコンテナを立ち上げることは、ローカルワークステーション上にコンテナを立ち上げることと同一である。
理論上、任意の形態のコンテナは、情報のパッケージングおよび情報との対話のための標準化された方法を表している。コンテナは、互いに分離することが可能であり、相互汚染（コンタミネーション）のいかなるリスクも伴うことなく並列に使用することが可能である。現代のソフトウェアの世界において、「コンテナ」という用語は固有の意味を獲得している。Docker（登録商標）コンテナのようなソフトウェアコンテナは、１つのソフトウェアを論理的にカプセル化し定義するソフトウェア構造である。コンテナにカプセル化される最も一般的なタイプのソフトウェアは、アプリケーション、サービス、またはマイクロサービスである。現代のコンテナはまた、オペレーティングシステム、ライブラリ、ストレージボリューム、構成ファイル、アプリケーションバイナリ、および、典型的なコンピューティング環境において見出されるであろうテクノロジースタックのその他の部分のような、アプリケーション／サービスが動作するのに必要なソフトウェアサポートすべてを含む。そのため、このコンテナ環境を使用することにより、各々が自身のサービスを任意の環境で実行する複数のコンテナを作成することができる。コンテナは、プロダクションデータセンター、オンプレミスデータセンター、クラウドコンピューティングプラットフォームなどにおいて、いかなる変更も伴うことなくデプロイすることができる。クラウド上にコンテナを立ち上げることは、ローカルワークステーション上にコンテナを立ち上げることと同一である。
【0003】
現代のサービス指向アーキテクチャおよびクラウドコンピューティングプラットフォームは、大きなタスクを多数の小さな特定のタスクに分割する。コンテナをインスタンス化することによって個々の特定のタスクに集中することができ、さらに、複数のコンテナが協働することによって高度なアプリケーションを実現することができる。これはマイクロサービスアーキテクチャと呼ばれることがあり、各コンテナは、独立してアップグレードすることが可能なさまざまなバージョンのプログラミング言語およびライブラリを使用することができる。コンテナ内の処理には分離されているという性質があるので、コンテナは、より大きくよりモノリシックなアーキテクチャに対して行われる変更と比較すると、
手間またはリスクがほとんどない状態でアップグレードおよびリプレイスが可能である。コンテナプラットフォームを実行するために仮想マシンを使用できるが、このマイクロサービスアーキテクチャの実行において、コンテナプラットフォームは従来の仮想マシンよりも遥かに効率的である。
手間またはリスクがほとんどない状態でアップグレードおよびリプレイスが可能である。コンテナプラットフォームを実行するために仮想マシンを使用できるが、このマイクロサービスアーキテクチャの実行において、コンテナプラットフォームは従来の仮想マシンよりも遥かに効率的である。
【発明の概要】
【課題を解決するための手段】
【0004】
簡単な概要
いくつかの実施形態において、コンテナ環境におけるサービスのデプロイメントおよび動作をカスタマイズする方法は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップを含み得る。この方法はまた、ＡＰＩレジストリが、コンテナ環境へのサービスのデプロイメントにサービスの前記プロパティが影響するか否かを判断し、サービスのデプロイメントにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスをデプロイするステップを含み得る。この方法はさらに、ＡＰＩレジストリが、コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成するステップを含み得る。この方法はさらに、ＡＰＩレジストリが、コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断し、サービスに対するコールが如何にして処理されるかにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスに対するコールを処理するステップを含み得る。
いくつかの実施形態において、コンテナ環境におけるサービスのデプロイメントおよび動作をカスタマイズする方法は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップを含み得る。この方法はまた、ＡＰＩレジストリが、コンテナ環境へのサービスのデプロイメントにサービスの前記プロパティが影響するか否かを判断し、サービスのデプロイメントにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスをデプロイするステップを含み得る。この方法はさらに、ＡＰＩレジストリが、コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成するステップを含み得る。この方法はさらに、ＡＰＩレジストリが、コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断し、サービスに対するコールが如何にして処理されるかにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスに対するコールを処理するステップを含み得る。
【0005】
いくつかの実施形態において、１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む非一時的なコンピュータ読取可能媒体において、当該動作は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることを含み得る。この動作はまた、ＡＰＩレジストリが、コンテナ環境へのサービスのデプロイメントにサービスの前記プロパティが影響するか否かを判断し、サービスのデプロイメントにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスをデプロイすることを含み得る。この動作はさらに、ＡＰＩレジストリが、コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成することを含み得る。この動作はさらに、ＡＰＩレジストリが、コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断し、サービスに対するコールが如何にして処理されるかにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスに対するコールを処理することを含み得る。
【0006】
いくつかの実施形態において、システムは、１つ以上のプロセッサと、１つ以上のメモリデバイスとを含み得る。１つ以上のメモリデバイスは、１つ以上のプロセッサによって実行されると当該１つ以上のプロセッサに動作を実行させる命令を含み、当該動作は、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることを含み得る。この動作はまた、ＡＰＩレジストリが、コンテナ環境へのサービスのデプロイメントにサービスの前記プロパティが影響するか否かを判断し、サービスのデプロイメントにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスをデプロイすることを含み得る。この動作はさらに、ＡＰＩレジストリが、コ
ンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成することを含み得る。この動作はさらに、ＡＰＩレジストリが、コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断し、サービスに対するコールが如何にして処理されるかにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスに対するコールを処理することを含み得る。
ンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断し、クライアントライブラリの生成にプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてクライアントライブラリを生成することを含み得る。この動作はさらに、ＡＰＩレジストリが、コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断し、サービスに対するコールが如何にして処理されるかにプロパティが影響するという判断に応じて、プロパティに少なくとも一部基づいてサービスに対するコールを処理することを含み得る。
【0007】
いずれの実施形態にも、以下の特徴のうちのいずれかまたはすべてが、限定されることなく任意の組み合わせで含まれ得る。プロパティは、ＡＰＩレジストリが実行するコードを含み得る。プロパティは、実行する予め定められたプロセスを選択するためにＡＰＩレジストリが使用するフラグを含み得る。ＡＰＩレジストリが、コンテナ環境へのサービスのデプロイメントにサービスのプロパティが影響するか否かを判断するステップは、サービスは高可用性を有するようにコンテナ環境にデプロイされねばならないことをプロパティが示していると判断するステップを含み得る。プロパティに少なくとも一部基づいてサービスをデプロイするステップは、サービスのコンテナ化された複数のインスタンスをコンテナ環境にデプロイするステップを含み得る。コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断するステップは、サービスはエンドツーエンド暗号化を必要とすることをプロパティが示していると判断するステップを含み得る。プロパティに少なくとも一部基づいてクライアントライブラリを生成するステップは、サービスコールにおいてサービスのエンドポイントに送られる前にデータを暗号化するコードをクライアントライブラリに生成するステップを含み得る。コンテナ環境内のサービスをコールするクライアントライブラリの生成にサービスのプロパティが影響するか否かを判断するステップは、呼び出し側サービスがサービスの使用をロギングしなければならないことをプロパティが示していると判断するステップを含み得る。プロパティに少なくとも一部基づいてクライアントライブラリを生成するステップは、サービスのエンドポイントに対するコールの使用情報をロギングするコードをクライアントライブラリに生成するステップを含み得る。コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断するステップは、コンテナ環境においてサービスはオンデマンドでインスタンス化されねばならないことをプロパティが示していると判断するステップを含み得る。プロパティに少なくとも一部基づいてサービスに対するコールを処理するステップは、ＡＰＩレジストリが、サービスに対して呼び出し側サービスが要求を送るという表示を受けたことに応じて、サービスのコンテナ化されたインスタンスを生成するステップを含み得る。クライアントライブラリは、サービスのエンドポイントに対するダイレクトコールを行うためにＡＰＩ関数を実現するメンバ関数とともにオブジェクトクラスを含み得る。動作はさらに、ＡＰＩレジストリにおいて、コンテナ環境におけるサービスのエンドポイントと１つ以上のＡＰＩ関数とを含むＡＰＩ定義を受けることを含み得る。サービスのプロパティをＡＰＩ定義とともに受けてもよい。コンテナ環境は、コンテナにカプセル化された複数のサービスを含み得る。ＡＰＩレジストリは、コンテナ環境内のコンテナにカプセル化されたサービスとしてデプロイされてもよい。ＡＰＩレジストリは、統合開発環境（ＩＤＥ）において開発中のサービスと、コンテナ環境において既にデプロイされているサービスとが、利用できる。コンテナ環境においてサービスに対するコールが如何にして処理されるかにサービスのプロパティが影響するか否かを判断することは、コンテナ環境においてサービスがコールされたときにサービスはレート制限されねばならないことをプロパティが示していると判断することを含み得る。
【0008】
本発明の性質および利点の一層の理解は、本明細書の残りの部分および図面を参照することによって実現するであろう。いくつかの図面で使用されている同様の参照番号は、同
様の構成要素を示す。いくつかの例では、参照番号に添字を対応付けることにより、同様の複数の構成要素のうちの１つを示している。既存の添字を示すことなく参照番号に言及している場合は、そのような同様の複数の構成要素すべてに言及することを意図している。
様の構成要素を示す。いくつかの例では、参照番号に添字を対応付けることにより、同様の複数の構成要素のうちの１つを示している。既存の添字を示すことなく参照番号に言及している場合は、そのような同様の複数の構成要素すべてに言及することを意図している。
【図面の簡単な説明】
【0009】
【図1】いくつかの実施形態に係る、コンテナプラットフォームにおけるサービスのための開発およびランタイム環境のソフトウェア構造および論理構成を示す図である。
【図2】本明細書に記載の実施形態を実行するために特別に設計された専用コンピュータハードウェアシステムを示す図である。
【図3】本明細書に記載の実施形態のうちのいくつかで使用されるコンテナプラットフォームに固有であってもよいデータ組織を示す図である。
【図4】いくつかの実施形態に係る、ＩＤＥおよびプロダクション／ランタイム環境にデプロイすることができるＡＰＩレジストリを示す図である。
【図5】いくつかの実施形態に係る、実行時にコンテナプラットフォームとともに使用されるＡＰＩレジストリのデプロイを示す図である。
【図6A】いくつかの実施形態に係る、ＡＰＩレジストリをデプロイする方法のフローチャートを示す図である。
【図7A】いくつかの実施形態に係る、ＡＰＩレジストリにサービスを登録する方法のフローチャートを示す図である。
【図7B】いくつかの実施形態に係る、ＡＰＩレジストリにＡＰＩを登録するためのステップのハードウェア／ソフトウェア図を示す。
【図8】いくつかの実施形態に係る、ＡＰＩレジストリに登録されたＡＰＩをブラウズおよび選択するためのグラフィカルインターフェイスおよびコマンドラインインターフェイスの例を示す図である。
【図9】いくつかの実施形態に係る、ＡＰＩレジストリに登録されたサービスおよびその対応する関数を使用する方法のフローチャートを示す図である。
【図10】ＡＰＩレジストリが如何にしてCreateUser( )関数の選択をグラフィカルインターフェイスを介して受けることができるかを示す図である。
【図11】いくつかの実施形態に係る、ＡＰＩレジストリがあるサービスのために自動的に生成したクライアントライブラリの一例を示す図である。
【図12】いくつかの実施形態に係る、サービスエンドポイントとＡＰＩ関数との間の動的バインディングを含むクライアントライブラリの実施形態を示す図である。
【図13】いくつかの実施形態に係る、サービスコールのための入力データセットを完成させるために追加データを配置できるクライアントライブラリの実施形態を示す図である。
【図14】いくつかの実施形態に係る、サービスをコールするときにリトライを処理することができるクライアントライブラリを示す図である。
【図15A】いくつかの実施形態に係る、ＡＰＩプロパティをＡＰＩレジストリに与える方法を示す図である。
【図15B】いくつかの実施形態に係る、如何にしてサービスがＡＰＩプロパティをＡＰＩレジストリに与えることができるかについてのハードウェア／ソフトウェア図を示す。
【図16】いくつかの実施形態に係る、ＡＰＩレジストリがプロパティを用いて高可用性のサービスをデプロイする場合のハードウェア／ソフトウェア図を示す。
【図17】いくつかの実施形態に係る、ＡＰＩレジストリを通じてエンドツーエンド暗号化を実施するプロパティのハードウェア／ソフトウェア図を示す。
【図18】いくつかの実施形態に係る、ＡＰＩレジストリがサービス１８０８の使用ロギングを実現するためのプロパティを示す図である。
【図19】いくつかの実施形態に係る、サービスの認証プロトコルを実施することが可能なプロパティのハードウェア／ソフトウェア図を示す。
【図20】いくつかの実施形態に係る、サービスのランタイムインスタンス化を可能にするプロパティのハードウェア／ソフトウェア図を示す。
【図21】いくつかの実施形態に係る、サービスのレート制限関数を実現するプロパティのハードウェア／ソフトウェア図を示す。
【図22】実施形態のうちのいくつかを実現するための分散型システムの簡略化されたブロック図を示す。
【図23】実施形態のシステムの構成要素が提供するサービスをクラウドサービスとして提供し得るシステム環境の構成要素の簡略化されたブロック図を示す。
【図24】各種実施形態を実現し得る具体例としてのコンピュータシステムを示す図である。
【発明を実施するための形態】
【0010】
詳細な説明
開発者が開発中にサービスを登録することを可能にするとともにデプロイ中およびデプロイ後双方においてこれらのサービスを他のサービスが利用できるようにする、統合開発環境（ＩＤＥ）の一部であるアプリケーションプログラミングインターフェイス（ＡＰＩ）レジストリの実施形態について説明する。ＡＰＩレジストリは、コンテナプラットフォーム上のコンテナ化されたアプリケーションとして動作するオーケストレーションされたコンテナプラットフォームの一部としてデプロイすることが可能である。サービスまたはマイクロサービスが開発されコンテナプラットフォーム上のコンテナにデプロイされると、ＡＰＩレジストリは、ディスカバリプロセスを実行することにより、利用できるサービスに対応するコンテナプラットフォーム内の利用できるエンドポイント（たとえばＩＰアドレスおよびポート番号）の場所を特定することができる。ＡＰＩレジストリはまた、ＡＰＩ定義ファイルのアップロードを受け入れることができ、ＡＰＩ定義ファイルは、生のサービスエンドポイントを、ＡＰＩレジストリを介して利用できるようにされるＡＰＩ関数にするために使用することができる。ＡＰＩレジストリは、発見されたエンドポイントを、最新状態に保たれコンテナプラットフォーム内の他のサービスが利用できるようにされたＡＰＩ関数に動的にバインドすることができる。これは、ＡＰＩ関数とサービスエンドポイントとの間のバインディングに対する任意の変更をＡＰＩレジストリが管理している間、他のサービスが静的にコールできる安定したエンドポイントを提供する。これはまた、コンテナプラットフォーム内のサービスを使用するプロセスを簡略化する。ＨＴＴＰコールに対するコードを記述する代わりに、新たなサービスは、ＡＰＩインターフェイスを使用するだけで、登録されたサービスにアクセスすることができる。
開発者が開発中にサービスを登録することを可能にするとともにデプロイ中およびデプロイ後双方においてこれらのサービスを他のサービスが利用できるようにする、統合開発環境（ＩＤＥ）の一部であるアプリケーションプログラミングインターフェイス（ＡＰＩ）レジストリの実施形態について説明する。ＡＰＩレジストリは、コンテナプラットフォーム上のコンテナ化されたアプリケーションとして動作するオーケストレーションされたコンテナプラットフォームの一部としてデプロイすることが可能である。サービスまたはマイクロサービスが開発されコンテナプラットフォーム上のコンテナにデプロイされると、ＡＰＩレジストリは、ディスカバリプロセスを実行することにより、利用できるサービスに対応するコンテナプラットフォーム内の利用できるエンドポイント（たとえばＩＰアドレスおよびポート番号）の場所を特定することができる。ＡＰＩレジストリはまた、ＡＰＩ定義ファイルのアップロードを受け入れることができ、ＡＰＩ定義ファイルは、生のサービスエンドポイントを、ＡＰＩレジストリを介して利用できるようにされるＡＰＩ関数にするために使用することができる。ＡＰＩレジストリは、発見されたエンドポイントを、最新状態に保たれコンテナプラットフォーム内の他のサービスが利用できるようにされたＡＰＩ関数に動的にバインドすることができる。これは、ＡＰＩ関数とサービスエンドポイントとの間のバインディングに対する任意の変更をＡＰＩレジストリが管理している間、他のサービスが静的にコールできる安定したエンドポイントを提供する。これはまた、コンテナプラットフォーム内のサービスを使用するプロセスを簡略化する。ＨＴＴＰコールに対するコードを記述する代わりに、新たなサービスは、ＡＰＩインターフェイスを使用するだけで、登録されたサービスにアクセスすることができる。
【0011】
いくつかの実施形態において、ＩＤＥは、コンテナプラットフォーム内で利用することが可能でありＡＰＩレジストリに登録されているサービスの場所を開発者が特定するための、ナビゲーション／ブラウズインターフェイスを提供することができる。開発中の新たなサービスのために、ＡＰＩレジストリが既存のサービスにコールするとき、ＡＰＩレジストリは、登録されているサービスとのやり取りのために必要なすべての機能を含む一組のクライアントライブラリを自動的に生成することができる。たとえば、いくつかの実施形態は、ＡＰＩコールに対応するメンバ関数を含むオブジェクトクラスを生成することができる。開発中、新たなサービスは、これらのオブジェクトをインスタンス化するおよび／またはそれらのメンバ関数を使用するだけで、対応するＡＰＩにコールすることができる。クライアントライブラリにおけるコードは、呼び出し側サービスと登録されたサービスのエンドポイントとの間の直接接続を支配し、このやり取りに必要なすべての機能を扱うコードを含み得る。たとえば、自動的に生成されたクライアントライブラリは、ＡＰＩ
コールからのパラメータをサービスエンドポイントへのＨＴＴＰコールにパッケージングしフォーマットするためのコード、コールのためのパラメータセットを完成させるためにデータを配置するためのコード、情報を互換パケット（ＪＳＯＮ、ＸＭＬなど）にパッケージングするためのコード、結果パケットを受けてパースするためのコード、リトライおよびエラー条件を扱うためのコードなどを含み得る。呼び出し側サービスの観点からすると、この機能すべてを扱うためのコードは、ＡＰＩレジストリによって自動的に生成され、したがって、サービスコールの詳細を要約しカプセル化してクライアントライブラリオブジェクトにする。呼び出し側サービスに要求されるのは、ＡＰＩレジストリが作成したクライアントライブラリオブジェクトのメンバ関数を実行することだけである。
コールからのパラメータをサービスエンドポイントへのＨＴＴＰコールにパッケージングしフォーマットするためのコード、コールのためのパラメータセットを完成させるためにデータを配置するためのコード、情報を互換パケット（ＪＳＯＮ、ＸＭＬなど）にパッケージングするためのコード、結果パケットを受けてパースするためのコード、リトライおよびエラー条件を扱うためのコードなどを含み得る。呼び出し側サービスの観点からすると、この機能すべてを扱うためのコードは、ＡＰＩレジストリによって自動的に生成され、したがって、サービスコールの詳細を要約しカプセル化してクライアントライブラリオブジェクトにする。呼び出し側サービスに要求されるのは、ＡＰＩレジストリが作成したクライアントライブラリオブジェクトのメンバ関数を実行することだけである。
【0012】
いくつかの実施形態において、ＡＰＩレジストリは、登録されたサービスのランタイム実行を定義し得る一組のプロパティのアップロードを受け入れることもできる。この一組のプロパティは、開発中に、ＡＰＩ定義ファイルとともにアップロードすることができる。これらのプロパティは、エンドツーエンド暗号化、使用／ロギング要件、ユーザ認証、オンデマンドサービスインスタンス化、高可用性のための複数のサービスデプロイメントインスタンス、レート／使用制限、およびその他のランタイム特徴等の、ランタイム特徴を定義することができる。ＡＰＩレジストリは、開発中、デプロイ中、およびランタイム中に、コンテナ環境とやり取りすることによってこれらのプロパティが満たされることを保証できる。開発中、呼び出し側サービスのために自動的に生成されたクライアントライブラリは、暗号化コード、使用ロギングコード、および／またはユーザ認証サービスとのやり取り等の、これらのプロパティの実行に必要となり得るコードを含むことができる。登録されたサービスがデプロイされているとき、ＡＰＩレジストリは、コンテナプラットフォームに対し、サービスおよび／または追加のロードバランシングモジュールの複数のインスタンスをインスタンス化することによってランタイム中のサービスの高い信頼性を保証するよう指示することができる。ランタイム中にサービスがコールされると、ＡＰＩレジストリは、オンデマンドインスタンス化のためにサービスをインスタンス化させ、使用を抑えるために行うことができるＡＰＩコールの数を制限し、その他のランタイム関数を実行することができる。
【0013】
図１は、いくつかの実施形態に係る、コンテナプラットフォームにおけるサービスのための開発およびランタイム環境のソフトウェア構造および論理構成を示す。この環境は、コンテナプラットフォーム上にデプロイされるサービスおよびマイクロサービスを開発するために使用し得るＩＤＥ１０２を含み得る。ＩＤＥは、新たなサービスの記述およびテストのためにサービス開発者が使用できる基本ツールすべてを統合し提供するソフトウェアスイートである。ＩＤＥ１０２は、開発者がソースコード記述プロセスの記述、ナビゲート、統合、および視覚化を行うことを可能にする、グラフィカルユーザインターフェイス（ＧＵＩ）、コード補完機能、およびナビゲート／ブラウズインターフェイスとともに、ソースコードエディタ１０６を含み得る。ＩＤＥ１０２はまた、可変インターフェイス、即時可変インターフェイス、表現評価インターフェイス、メモリコンテンツインターフェイス、ブレークポイント可視化および機能、ならびにその他のデバッグ関数を含む、デバッガ１１０を含み得る。ＩＤＥ１０２はまた、マシンコードをコンパイルしコンパイルしたマシンコードまたは解釈されたバイトコードを実行するためのコンパイラおよび／またはインタプリタ１０８を含み得る。コンパイラ／インタプリタ１０８は、開発者が別のビルド自動化構成のためのメイクファイル（makefiles）を使用／生成することを可能に
するビルドツールを含み得る。ＩＤＥ１０２のいくつかの実施形態は、コードライブラリ１１２を含み得る。コードライブラリは、一般的なコード関数、オブジェクト、インターフェイス、および／または、開発中のサービスにリンクさせることができ複数の開発で再使用できるその他の構造を含む。
するビルドツールを含み得る。ＩＤＥ１０２のいくつかの実施形態は、コードライブラリ１１２を含み得る。コードライブラリは、一般的なコード関数、オブジェクト、インターフェイス、および／または、開発中のサービスにリンクさせることができ複数の開発で再使用できるその他の構造を含む。
【0014】
サービスは、ＩＤＥ１０２内で、開発することができ、デプロイの準備が整うまで徹底
的にテストすることができる。サービスはその後、プロダクション／デプロイメント環境１０４にデプロイすることができる。プロダクション／デプロイメント環境１０４は、専用ハードウェア、仮想マシン、およびコンテナ化されたプラットフォームを含む、多数の異なるハードウェアおよび／またはソフトウェア構造を含み得る。本開示よりも前において、サービス１１４がプロダクション／デプロイメント環境１０４にデプロイされたとき、サービス１１４は、ＩＤＥ１０２で使用されるツールの多くに対するランタイムアクセスを行うことができない。サービス１１４がプロダクション／デプロイメント環境１０４で実行するのに必要ないずれの機能も、コードライブラリ１１２からパッケージングしサービス１１４とともにプロダクション／デプロイメント環境１０４にデプロイする必要があった。加えて、一般的にサービス１１４は、デバッガ１１０の機能またはソースコードエディタ１０６からのソースコードのコピーのうちのいずれも伴うことなくデプロイされる。実際、サービス１１４は、ランタイム動作に必要な機能すべてとともにプロダクション／デプロイメント環境１０４にデプロイされるが、開発中にだけ使用された情報は取り除かれる。
的にテストすることができる。サービスはその後、プロダクション／デプロイメント環境１０４にデプロイすることができる。プロダクション／デプロイメント環境１０４は、専用ハードウェア、仮想マシン、およびコンテナ化されたプラットフォームを含む、多数の異なるハードウェアおよび／またはソフトウェア構造を含み得る。本開示よりも前において、サービス１１４がプロダクション／デプロイメント環境１０４にデプロイされたとき、サービス１１４は、ＩＤＥ１０２で使用されるツールの多くに対するランタイムアクセスを行うことができない。サービス１１４がプロダクション／デプロイメント環境１０４で実行するのに必要ないずれの機能も、コードライブラリ１１２からパッケージングしサービス１１４とともにプロダクション／デプロイメント環境１０４にデプロイする必要があった。加えて、一般的にサービス１１４は、デバッガ１１０の機能またはソースコードエディタ１０６からのソースコードのコピーのうちのいずれも伴うことなくデプロイされる。実際、サービス１１４は、ランタイム動作に必要な機能すべてとともにプロダクション／デプロイメント環境１０４にデプロイされるが、開発中にだけ使用された情報は取り除かれる。
【0015】
図２は、本明細書に記載の実施形態を実行するために特別に設計された専用コンピュータハードウェアシステムを示す。一例として、サービス１１４は、サービスとしてのインフラストラクチャ（Infrastructure as a Service）（ＩａａＳ）クラウドコンピューテ
ィング環境２０２にデプロイすることができる。これは、ネットワーク上に仮想化または共有コンピューティングリソースを提供するクラウドコンピューティングの一形態である。ＩａａＳクラウドコンピューティング環境２０２はまた、サービスとしてのソフトウェア（Software as a Service）（ＳａａＳ）および／またはサービスとしてのプラットフ
ォーム（Platform as a Service）（ＰａａＳ）アーキテクチャとして構成されたその他
のクラウドコンピューティング環境を含み得る、または当該環境に結合し得る。この環境において、クラウドプロバイダは、従来オンプレミスデータセンターに存在していたハードウェアおよび／またはソフトウェアコンポーネントのインフラストラクチャをホストすることができる。このハードウェアは、サーバ、ストレージ、ネットワーキングハードウェア、ディスクアレイ、ソフトウェアライブラリ、および、ハイパーバイザレイヤのような仮想化ユーティリティを含み得る。ＩａａＳ環境２０２は、Oracle（登録商標）またはその他一般に利用できるクラウドプラットフォームのような商用ソースによって提供されることができる。ＩａａＳ環境２０２はまた、ハードウェアおよびソフトウェアのプライベートインフラストラクチャを用いてプライベートクラウドとしてデプロイすることもできる。
ィング環境２０２にデプロイすることができる。これは、ネットワーク上に仮想化または共有コンピューティングリソースを提供するクラウドコンピューティングの一形態である。ＩａａＳクラウドコンピューティング環境２０２はまた、サービスとしてのソフトウェア（Software as a Service）（ＳａａＳ）および／またはサービスとしてのプラットフ
ォーム（Platform as a Service）（ＰａａＳ）アーキテクチャとして構成されたその他
のクラウドコンピューティング環境を含み得る、または当該環境に結合し得る。この環境において、クラウドプロバイダは、従来オンプレミスデータセンターに存在していたハードウェアおよび／またはソフトウェアコンポーネントのインフラストラクチャをホストすることができる。このハードウェアは、サーバ、ストレージ、ネットワーキングハードウェア、ディスクアレイ、ソフトウェアライブラリ、および、ハイパーバイザレイヤのような仮想化ユーティリティを含み得る。ＩａａＳ環境２０２は、Oracle（登録商標）またはその他一般に利用できるクラウドプラットフォームのような商用ソースによって提供されることができる。ＩａａＳ環境２０２はまた、ハードウェアおよびソフトウェアのプライベートインフラストラクチャを用いてプライベートクラウドとしてデプロイすることもできる。
【0016】
クラウド環境のタイプとは関係なく、サービス１１４は、複数種類のハードウェア／ソフトウェアシステムにデプロイすることができる。たとえば、サービス１１４は、専用ハードウェア２０６にデプロイすることができる。専用ハードウェア２０６は、サービス１１４に特別に割り当てられたサーバ、ディスク、オペレーティングシステム、ソフトウェアパッケージなどのようなハードウェアリソースを含み得る。たとえば、特定のサーバが、サーバ１１４との間で流れるトラフィックを処理するように割り当てられていてもよい。
【0017】
別の例において、サービス１１４は、１つ以上の仮想マシン２０８として動作させるハードウェア／ソフトウェアにデプロイすることができる。仮想マシンは、専用コンピュータハードウェア２０６の機能を提供するコンピュータシステムをエミュレートしたものである。しかしながら、特定の関数専用にする代わりに、物理ハードウェアを複数の異なる仮想マシンが共有してもよい。各仮想マシンは、完全なオペレーティングシステムを含む、実行する必要があるすべての機能を提供することができる。これにより、異なるオペレーティングシステムを有する複数の仮想マシンが、同一の物理ハードウェア上で実行することができ、複数のサービスが１つのハードウェアを共有することができる。
【0018】
別の例において、サービス１１４はコンテナプラットフォーム２１０にデプロイすることができる。コンテナプラットフォームは、仮想マシン２０８と、複数の重要な点において異なっている。第１に、以下図３で詳述するように、コンテナプラットフォーム２１０は、個々のサービスをコンテナにパッケージングする。各コンテナは、ホストオペレーティングシステムカーネルを共有するとともに、バイナリ、ライブラリ、およびその他の読取専用コンポーネントを共有する。これにより、コンテナを極めて軽くすることができ、わずか数メガバイトのサイズであることも多い。加えて、軽量コンテナは、仮想マシンのブートアップに数分を要するのに対して起動にわずか数秒しかかからず、非常に効率的である。また、コンテナは、オペレーティングシステム、および、コンテナプラットフォーム２１０内の一組のコンテナセットに対してともに管理できるその他のライブラリを共有することにより、管理オーバーヘッドを減じる。コンテナは同じオペレーティングシステムを共有するものの、オペレーティングシステムは分離のために仮想メモリサポートを提供するので、分離されたプラットフォームを提供する。コンテナ技術は、Docker（登録商標）コンテナ、Linux（登録商標） Libcontainer（登録商標）、オープンコンテナイニシアティブ（Open Container Initiative）（ＯＣＩ）、Kubernetes（登録商標）、Ｃｏｅ
ＯＳ、Apache（登録商標） Mesosを、それ以外のものともに含み得る。これらのコンテナは、本明細書では簡単に「コンテナプラットフォーム２１０」と呼ぶ場合があるコンテナオーケストレーションプラットフォームにデプロイすることができる。コンテナプラットフォームは、デプロイされたソフトウェアコンテナの自動化された構成、調整、および管理を維持する。コンテナプラットフォーム２１０は、サービスディスカバリ、ロードバランシング、ヘルスチェック、マルチデプロイメントなどを提供することができる。コンテナプラットフォーム２１０は、ノードおよびポッドで構成されたコンテナを実行する、Kubernetesのような一般に利用できるコンテナプラットフォームによって実現し得る。
ＯＳ、Apache（登録商標） Mesosを、それ以外のものともに含み得る。これらのコンテナは、本明細書では簡単に「コンテナプラットフォーム２１０」と呼ぶ場合があるコンテナオーケストレーションプラットフォームにデプロイすることができる。コンテナプラットフォームは、デプロイされたソフトウェアコンテナの自動化された構成、調整、および管理を維持する。コンテナプラットフォーム２１０は、サービスディスカバリ、ロードバランシング、ヘルスチェック、マルチデプロイメントなどを提供することができる。コンテナプラットフォーム２１０は、ノードおよびポッドで構成されたコンテナを実行する、Kubernetesのような一般に利用できるコンテナプラットフォームによって実現し得る。
【0019】
サービス１１４をデプロイするプラットフォーム２０６、２０８、２１０とは関係なく、プラットフォーム２０６、２０８、２１０は各々、サービス１１４をコールするためのパブリックアクセスを提供するサービスエンドポイント２１２、２１４、２１６を提供できる。一般的に、これらのエンドポイントには、ＨＴＴＰコールを通してアクセスでき、これらのエンドポイントは、ＩＰアドレスおよびポート番号に対応付けられる。正しいＩＰアドレスおよびポート番号に接続することにより、その他のサービスは、公的に利用できるようにされたときにプラットフォーム２０６、２０８、２１０のうちのいずれかにデプロイされるサービスをコールすることができる。サービス１１４等の各サービスは、サービスをコールするための自身のプロプライエタリフォーマットとデータ要件とを含み得る。同様に、各サービスは、フォーマットおよびデータタイプがそのサービス１１４に固有である結果を返すことができる。サービス固有の要件に加えて、特定のデプロイメントプラットフォーム２０６、２０８、２１０はまた、サービスと適切にやり取りするために準拠する必要がある、プログラミング言語、パッケージフォーマット（ＪＳＯＮ、ＸＭＬなど）その他のような、サービス１１４とやり取りするための追加要件を含み得る。
【0020】
上述の例は、サービス１１４を上記プラットフォーム２０６、２０８、２１０のうちのいずれかにデプロイすることを可能にするが、本明細書に記載の実施形態は、上記コンテナプラットフォーム２１０のために特別に設計される。よって、「コンテナプラットフォーム」にデプロイされると具体的に記載された実施形態は、仮想マシンプラットフォームに、サーバもしくは専用ハードウェアプラットフォーム上に、または一般的にＩａａＳ環境にデプロイされると具体的に記載された実施形態と区別することができる。
【0021】
図３は、本明細書に記載の実施形態のうちのいくつかが使用するコンテナプラットフォーム２１０に固有であってもよいデータ組織を示す。一般的に、コンテナプラットフォームへのサービスのいかなるデプロイメントもポッド３０４、３０６にデプロイされる。ポ
ッドは、１つ以上のアプリケーションコンテナ（たとえばDockerまたはrkt）からなるグ
ループを表す抽象概念である。ポッドはまた、当該ポッド内のすべてのコンテナが共通して利用できるいくつかの共有リソースを含み得る。たとえば、ポッド３０４はコンテナ３１０とコンテナ３１２とを含む。ポッド３０４はまた、共有リソース３０８を含む。このリソースは、ストレージボリューム、またはコンテナが如何にしてポッド３０４内で実行されるかまたは接続されるかに関するその他の情報を含み得る。ポッド３０４は、比較的密接に結合された異なるサービスコンテナ３１０、３１２を含むアプリケーション専用論理ホストをモデル化することができる。たとえば、コンテナ３１０内のサービス３２６は、リソース３０８を利用することができ、コンテナ３１２内のサービス３２０をコールすることができる。サービス３２０もサービス３２２をコールすることができ、サービス３２２もサービス３２４をコールすることができ、これらのサービスは各々コンテナ３１２にデプロイされている。サービス３２４の出力はネットワークＩＰアドレスおよびポート３１８に与えることができ、これはポッド３０４が共有する別の共通リソースである。このように、サービス３２０、３２２、３２４、３２６すべてが共有リソース３０８と協働することにより、他のコンテナで実行されるサービスがＩＰアドレスおよびポート番号３１８によってアクセスすることができる、１つのサービスを提供する。このサービスは、コンテナプラットフォームまたはＩａａＳ環境の一部ではない、ワークステーション、ラップトップコンピュータ、スマートフォンまたはその他のコンピューティングデバイスのような、コンテナプラットフォームの外部のコンピュータシステムが、ＩＰアドレスポート３１８を介してアクセスすることもできる。
ッドは、１つ以上のアプリケーションコンテナ（たとえばDockerまたはrkt）からなるグ
ループを表す抽象概念である。ポッドはまた、当該ポッド内のすべてのコンテナが共通して利用できるいくつかの共有リソースを含み得る。たとえば、ポッド３０４はコンテナ３１０とコンテナ３１２とを含む。ポッド３０４はまた、共有リソース３０８を含む。このリソースは、ストレージボリューム、またはコンテナが如何にしてポッド３０４内で実行されるかまたは接続されるかに関するその他の情報を含み得る。ポッド３０４は、比較的密接に結合された異なるサービスコンテナ３１０、３１２を含むアプリケーション専用論理ホストをモデル化することができる。たとえば、コンテナ３１０内のサービス３２６は、リソース３０８を利用することができ、コンテナ３１２内のサービス３２０をコールすることができる。サービス３２０もサービス３２２をコールすることができ、サービス３２２もサービス３２４をコールすることができ、これらのサービスは各々コンテナ３１２にデプロイされている。サービス３２４の出力はネットワークＩＰアドレスおよびポート３１８に与えることができ、これはポッド３０４が共有する別の共通リソースである。このように、サービス３２０、３２２、３２４、３２６すべてが共有リソース３０８と協働することにより、他のコンテナで実行されるサービスがＩＰアドレスおよびポート番号３１８によってアクセスすることができる、１つのサービスを提供する。このサービスは、コンテナプラットフォームまたはＩａａＳ環境の一部ではない、ワークステーション、ラップトップコンピュータ、スマートフォンまたはその他のコンピューティングデバイスのような、コンテナプラットフォームの外部のコンピュータシステムが、ＩＰアドレスポート３１８を介してアクセスすることもできる。
【0022】
最も単純なデプロイメントの場合、各コンテナは１つのサービスを含むことができ、各ポッドはサービスをカプセル化する１つのコンテナを含むことができる。たとえば、ポッド３０６は１つのサービス３２８のみを有する１つのコンテナ３１４のみを含む。この１つのサービスは、ポッド３０６のＩＰアドレスおよびポート番号３１６を通してアクセスできる。典型的に、サービスがコンテナプラットフォームにデプロイされるとき、コンテナおよびポッドがインスタンス化されてこのサービスを保持する。複数の異なるポッドをコンテナノード３０２にデプロイすることができる。一般的に、ポッドはノード内で実行される。ノードはコンテナプラットフォーム内のワーカーマシン（仮想または物理いずれか）を表す。各ノードは、各ノード内のスケジューリングポッドを自動的に扱う「マスタ」によって管理される。各ノードは、マスタとノードとの間の通信を担い、かつ当該ノードによって表されるマシン上のコンテナ内でポッドを管理するためのプロセスを実行することができる。各ノードはまた、レジストリからコンテナ画像を引き出すこと、コンテナを解凍すること、およびサービスを実行することを担うコンテナランタイムを含み得る。
【0023】
図４は、いくつかの実施形態に係る、ＩＤＥ１０２およびプロダクション／デプロイメント環境１０４にデプロイすることができるＡＰＩレジストリ４０４を示す。上述のように、サービス１１４がＩＤＥ１０２からプロダクション／デプロイメント環境１０４にデプロイされるとき、ＩＤＥ１０２内で独占的に利用できる情報へのランタイムアクセスをサービス１１４が失うという、技術的課題がある。ＡＰＩレジストリ４０４に対し、サービス１１４は、プロダクション／デプロイメント環境１０４にデプロイされこの環境でランタイム中に動作している間、アクセスすることができる。開発関数がランタイム関数から分離されるという過去の技術的課題は、開発中にサービスをＡＰＩレジストリ４０４に登録しＡＰＩ定義および／またはＡＰＩプロパティをＡＰＩレジストリ４０４に与えることにより、ＡＰＩレジストリ４０４によって克服される。ＡＰＩを定義する情報は、ＩＤＥ１０２内の開発中の新たなサービス、および、プロダクション／デプロイメント環境１０４に既にデプロイされているサービスが、使用できる。この登録プロセスの完了後、サービス１１４はクライアントライブラリを用いて動作することができ、クライアントライブラリは、ランタイム中にＡＰＩレジストリ４０４にアクセスすることにより、ＡＰＩ関数が、対応するサービスの現在のＩＰアドレスおよびポート番号に正しくバインドされて
いることを保証する。ＡＰＩレジストリ４０４は、これらの技術的課題を解決するために特別に設計された新たなデータ構造および処理ユニットを表す。
いることを保証する。ＡＰＩレジストリ４０４は、これらの技術的課題を解決するために特別に設計された新たなデータ構造および処理ユニットを表す。
【0024】
当該技術に存在していたもう１つの技術的課題は、サービスプロパティがプロダクション／デプロイメント環境１０４にデプロイされるときの、サービスプロパティの実現であった。たとえば、サービスを高可用性を伴ってデプロイしようとする場合、開発者は、コンテナプラットフォーム内でサービスの複数のインスタンスを特別にインスタンス化したコンテナデプロイメントファイルと、バランスが取れたトラフィックとを、サービスが常に利用できるように構築する必要がある。サービス開発者は必ずしもこの専門知識を有していた訳ではなく、それらのサービスのデプロイメントを大抵は管理できた訳でもない。上述のように、ＡＰＩレジストリ４０４により、サービスは、ＡＰＩレジストリ４０４が自動的に実現できる高可用性のようなプロパティを単純に選択することができる。この技術的解決策が可能な理由は、ＡＰＩレジストリ４０４がＩＤＥ１０２とプロダクション／デプロイメント環境１０４との間の隙間の架け橋となるからである。
【0025】
図５は、いくつかの実施形態に係る、実行時にコンテナプラットフォーム２１０とともに使用されるＡＰＩレジストリ４０４のデプロイメントを示す。ＡＰＩレジストリ４０４が提供する、既存の技術に対する技術的解決策および改善のうちの１つは、サービスコールのための安定したエンドポイントの維持、ならびにサービスコールへのアクセスの簡略化およびサービスコールへのアクセスのための自動コード生成である。本開示よりも前において、サービス間のコールは、たとえばＩＰアドレスおよびポート番号に対するＨＴＴＰコールを用いるポイントツーポイント接続であった。サービスがアップデート、リプレイス、リロケート、およびコンテナプラットフォーム２１０に再デプロイされるときに、ＩＰアドレスおよびポート番号が頻繁に変わる可能性がある。この場合、アップデートされたサービスをコールしたすべてのサービスが、そのサービスをコールした実際のコードのＩＰアドレスおよびポート番号をアップデートする必要があった。ＡＰＩレジストリ４０４は、この技術的課題を、サービスのＩＰアドレスおよびポート番号と、ＡＰＩレジストリを介して利用できるようにされるＡＰＩ関数との間の動的バインディングを提供することによって解決する。ＡＰＩレジストリ４０４が自動的に生成するクライアントライブラリは、ＡＰＩレジストリ４０４にアクセスすることにより特定のサービスの現在のＩＰアドレスおよびポート番号を取り出すおよび／または検証する関数を含み得る。したがって、第２のサービスに接続する第１のサービスは、クライアントライブラリを一度生成するだけで、第２のサービスへの、存続期間にわたって安定した接続を提供する。
【0026】
ＡＰＩレジストリ４０４が解決する別の技術的課題は、クライアントライブラリの自動生成である。本開示よりも前において、第２のサービスにアクセスする第１のサービスは、第２のサービスにアクセスするためのカスタムコードを開発者が記述することを必要としていた。このコードは時間の経過に伴って変化する可能性があるので、どちらもアップデートを必要とする第１のサービスと第２のサービスとの間に非互換性が生じることになる。ＡＰＩレジストリ４０４は、この技術的課題を、サービスをコールするためにクライアントライブラリを自動的に生成するのに使用されるＡＰＩ定義ファイルをアップロードすることによって解決する。したがって、サービスは、その他いずれかのサービスにおけるコーリングコードが如何にして動作すべきかを具体的に指定することができ、これが互換性を保証する。これらのクライアントライブラリはまた、サービスをコールするためのコードを大幅に簡略化しカプセル化する。以下で述べるように、ＩＰアドレスおよびポート番号を使用する複雑なＨＴＴＰコールは、呼び出し側サービスに固有の言語（たとえばＪａｖａ（登録商標）、Ｃ＃など）の単純なメンバ関数に置き換えることができる。これにより、呼び出し側サービスは、ＡＰＩレジストリ４０４からＡＰＩ関数を選択することができ、関数で実現するコードは、クライアントライブラリとして呼び出し側サービスダウンロードすることができる。
【0027】
図６Ａは、いくつかの実施形態に係る、ＡＰＩレジストリ４０４をデプロイする方法のフローチャートを示す。この方法は、ＡＰＩレジストリサービスをコンテナ環境にデプロイすることを含み得る（６０１）。ＡＰＩレジストリは、コンテナ環境においてコンテナ内で動作するサービスとして実現することができる。よって、ＡＰＩレジストリは、実行時にアクセスされることができるよう、コンテナ環境内にサービスがデプロイされた後で能動的に実行することができる。ＡＰＩレジストリは、上記既存のＩＤＥにリンクさせることもできる。この方法はさらに、コンテナプラットフォーム内の利用できるサービスのためのポートを発見することを含み得る（６０３）。サービスがコンテナプラットフォームにデプロイされると、ＡＰＩレジストリは、コンテナプラットフォームにデプロイされたサービス各々を逐次的にトラバースするディスカバリプロセスを開始することができる。サービスごとに、ＡＰＩレジストリはＩＰアドレスおよびポート番号を検出して記録することができる。このプロセスによって発見されたＩＰアドレスおよびポート番号の一覧表は、ＡＰＩレジストリに対応付けられたテーブル等のデータ構造に格納することができる。また、各ＩＰアドレスおよびポート番号は、そのサービスの名称とともに、または、コンテナプラットフォーム上のサービスを一意に識別するその他の識別子とともに、格納することができる。図６Ａのフローチャートに示されるこれらの初期ステップは、ＡＰＩレジストリがコンテナプラットフォームのランタイム環境内で動作を開始するため、かつ、ＩＤＥ内で開発中のサービスがＡＰＩレジストリを利用できるようにするための、出発点を提供する。
【0028】
図６Ｂは、いくつかの実施形態に係る、図６Ａのフローチャートを用いてＡＰＩレジストリをデプロイするときのコンテナプラットフォーム２１０のソフトウェア構造を示す。先に述べたように、ＡＰＩレジストリ４０４はコンテナプラットフォーム２１０内のコンテナ６２０にデプロイすることができる。先に図３で説明したように、コンテナ６２０は、あるノードにおいて１つ以上のポッド内で動作することができる。ＡＰＩレジストリ４０４を、コンテナプラットフォーム２１０内の他のコンテナのうちのいずれかが非公式に利用できるようにすることができる。いくつかの実施形態において、ＡＰＩレジストリ４０４を、コンテナプラットフォーム２１０の一部ではない他のデバイスが公的に利用できるようにすることもできる。コンテナ化されたサービスとして、ＡＰＩレジストリ４０４は他のサービスが利用できるＩＰアドレスおよびポート番号を有することができる。しかしながら、ＡＰＩレジストリ４０４のＩＰアドレスおよびポート番号は、クライアントライブラリで自動的に生成されたコードのみによって使用されるので、いくつかの実施形態はＡＰＩレジストリ４０４のＩＰアドレスおよびポート番号を公開する必要はない。その代わりに、ＩＤＥ自身のクライアントライブラリが、他のサービスの開発、デプロイ、および実行中にコンタクトできるよう、ＡＰＩレジストリ４０４のＩＰアドレスおよびポート番号の最新一覧表を管理することができる。
【0029】
ＡＰＩレジストリ４０４は、コンテナ６２０にデプロイされた後に、ディスカバリプロセスを実行することができる。ディスカバリプロセスは、コンテナプラットフォームにおけるノードのディレクトリ一覧表を用いることにより、ＩＰアドレスおよびポート番号で、サービスを実現するポッドを特定することができる。そうすると、ＡＰＩレジストリ４０４は、利用できる各サービスの番号または名称等の固有識別子にアクセスし、識別子を各ＩＰアドレスおよびポート番号とともにコンテナプラットフォーム２１０に格納することができる。このディスカバリプロセスを周期的に実行することにより、コンテナプラットフォーム２１０に追加された新たなサービスを検出することができるとともに、コンテナプラットフォーム２１０から削除された既存のサービスを特定することができる。以下で述べるように、このディスカバリプロセスを用いることにより、既存のサービスについてＩＰアドレスおよびポート番号がいつ変化したかを検出することもできる。たとえば、ＡＰＩレジストリ４０４は、エンドポイント６０２、６０４、６０６、６０８を有するサ
ービスを発見することができる。下記プロセスにおいて、ＡＰＩレジストリ４０４は、これらのエンドポイント６０２、６０４、６０６、６０８各々を、ＡＰＩレジストリ４０４に登録されたＡＰＩ関数にバインドすることができる。この最初の発見後のある時点で、エンドポイント６０２のＩＰアドレスおよび／またはポート番号が、エンドポイント６０２に対応付けられたサービスがリプレイス、アップデート、またはリバイズされたときに、変更される場合がある。ＡＰＩレジストリ４０４は、このエンドポイント６０２に対する変更を検出し、ＡＰＩレジストリ４０４が提供する既存のＡＰＩ関数へのバインディングをアップデートすることができる。
ービスを発見することができる。下記プロセスにおいて、ＡＰＩレジストリ４０４は、これらのエンドポイント６０２、６０４、６０６、６０８各々を、ＡＰＩレジストリ４０４に登録されたＡＰＩ関数にバインドすることができる。この最初の発見後のある時点で、エンドポイント６０２のＩＰアドレスおよび／またはポート番号が、エンドポイント６０２に対応付けられたサービスがリプレイス、アップデート、またはリバイズされたときに、変更される場合がある。ＡＰＩレジストリ４０４は、このエンドポイント６０２に対する変更を検出し、ＡＰＩレジストリ４０４が提供する既存のＡＰＩ関数へのバインディングをアップデートすることができる。
【0030】
同様に、ＡＰＩレジストリ４０４は、ディスカバリプロセスを用いることにより、いつエンドポイントが利用できなくなったかを検出し、その後、サービスに対応付けられたＡＰＩ関数を削除することができる。いくつかの実施形態において、サービスはＡＰＩレジストリ４０４に登録されているものの、対応するＡＰＩ関数が現在有効なエンドポイントにバインドされていないとき、ＡＰＩレジストリ４０４は、対応するＡＰＩ関数をコールしているいずれかのサービスにモックレスポンス（mock response）を与えることができ
る。たとえば、エンドポイント６０４に対応するサービスについてＡＰＩが登録されているものの、エンドポイント６０４は現在利用できない場合、ＡＰＩレジストリ４０４は、エンドポイント６０４に対するコールをインターセプトしそれに応じてデフォルトまたはダミーデータを与えることができる。これにより、エンドポイント６０４に対応付けられているサービスをコールするサービスは、機能を維持する、および／またはこの特定のサービスに対する接続を「切断する」ことなく設計プロセスを続けることができる。モック／テストデータシナリオについては以下でより詳細に説明する。
る。たとえば、エンドポイント６０４に対応するサービスについてＡＰＩが登録されているものの、エンドポイント６０４は現在利用できない場合、ＡＰＩレジストリ４０４は、エンドポイント６０４に対するコールをインターセプトしそれに応じてデフォルトまたはダミーデータを与えることができる。これにより、エンドポイント６０４に対応付けられているサービスをコールするサービスは、機能を維持する、および／またはこの特定のサービスに対する接続を「切断する」ことなく設計プロセスを続けることができる。モック／テストデータシナリオについては以下でより詳細に説明する。
【0031】
図７Ａは、いくつかの実施形態に係る、ＡＰＩレジストリ４０４にサービスを登録する方法のフローチャートを示す。この方法は、ＡＰＩ定義のアップロードを受けることを含み得る（７０１）。ＡＰＩ定義は、データパケット、ファイル、または情報リポジトリに対するリンクの形態で提供し得る。ＡＰＩ定義は、サービスに対応付けられたエンドポイントにバインドすべきＡＰＩ関数を特定し定義するために使用できる任意の情報を含み得る。たとえば、ＡＰＩ定義のいくつかの実施形態は、以下のデータを、すなわち、サービス名またはその他の固有識別子、サービスエンドポイントおよびコールに対応する関数名、対応する記述およびデータタイプでサービスにコールするのに必要なデータ入力、結果データフォーマットおよびデータタイプ、現在のＩＰアドレスおよび／またはポート番号、エンドポイントに対応付けられることになるＡＰＩ関数の機能を記述する文書、モック／テストシナリオ中に返すべきデフォルトまたはダミーデータ値、ならびに、ＡＰＩレジストリ４０４が、エンドポイントが受けたＨＴＴＰ要求を、クラスデータオブジェクトのＡＰＩ関数コールを使用するクライアントライブラリに変換するために使用し得るその他任意の情報を、含み得る。
【0032】
この方法はまた、アップロードされたＡＰＩ定義に基づいて対応するＡＰＩ関数を作成することを含み得る（７０３）。これらのＡＰＩ関数はＡＰＩ定義に基づいて自動的に生成することができる。サービスの各エンドポイントは複数の異なるＡＰＩ関数に対応付けることができる。たとえば、ＲＥＳＴｆｕｌインターフェイスを実現するエンドポイントは、同一のＩＰアドレスおよびポート番号のＰＯＳＴ、ＧＥＴ、ＰＵＴ、およびＤＥＬＥＴＥ関数に対するＨＴＴＰコールを受けることができる。これは結果としてたとえば異なるＡＰＩ関数に対するものになり得る。たとえば、このインターフェイスがユーザのリストを表す場合、これは、GetUser( )、AddUser( )、RemoveUser( )、およびUpdateUser( )のような、少なくとも４つの異なるＡＰＩ関数に対応し得る。加えて、各ＡＰＩ関数は、UpdateUser(id)、UpdateUser(name)、UpdateUser(firstname, lastname)などのような、
複数の異なるパラメータリストを含み得る。これらのＡＰＩ関数を生成し、生成されたＡＰＩ関数をＡＰＩレジストリを介して他のサービスが利用できるようにすることができる
。以下でより詳細に説明するように、これらの関数をＡＰＩレジストリを介してコールするためにサービスは必要ではないことに注意する必要がある。代わりに、これらの関数は、ＡＰＩレジストリにおいてブラウズするのに利用できるようにされ、選択されると、ＡＰＩレジストリは、呼び出し側サービスにおいてこれらの関数を実現するクライアントライブラリを生成することができる。
複数の異なるパラメータリストを含み得る。これらのＡＰＩ関数を生成し、生成されたＡＰＩ関数をＡＰＩレジストリを介して他のサービスが利用できるようにすることができる
。以下でより詳細に説明するように、これらの関数をＡＰＩレジストリを介してコールするためにサービスは必要ではないことに注意する必要がある。代わりに、これらの関数は、ＡＰＩレジストリにおいてブラウズするのに利用できるようにされ、選択されると、ＡＰＩレジストリは、呼び出し側サービスにおいてこれらの関数を実現するクライアントライブラリを生成することができる。
【0033】
この方法はさらに、ＡＰＩレジストリにおいて、ＡＰＩ関数と、対応するサービスのエンドポイントとの間のバインディングを作成することを含み得る（７０５）。上記ディスカバリプロセスおよびステップ７０１の登録プロセスに基づいて、ＡＰＩレジストリは、コンテナプラットフォームにおけるサービスのエンドポイントと、ＡＰＩレジストリが作成したＡＰＩ関数との間の動的バインディングを作成することができる。利用できるエンドポイントおよびサービスを発見したときに形成される上記データ構造に、ＡＰＩレジストリは、各エンドポイントの対応する関数または一組の関数を格納することができる。上述のように、このバインディングは、サービスがいつアップデート、移動、リプレイス、またはコンテナプラットフォームに追加されるかがディスカバリプロセスによって判断されたときに、常にアップデートすることができる。これにより、呼び出し側サービスにおいて作成されたクライアントライブラリは、先ずＡＰＩレジストリを調べることにより、サービスの現在のＩＰアドレスおよびポート番号を検証するまたは受けることができる。
【0034】
図７Ｂは、いくつかの実施形態に係る、ＡＰＩレジストリ４０４にＡＰＩを登録するためのステップのハードウェア／ソフトウェア図を示す。上述のように、ＡＰＩレジストリ４０４をインスタンス化しコンテナプラットフォーム２１０におけるコンテナ６２０内で実行することができる。コンテナプラットフォーム２１０はプロダクション／デプロイメント環境を表しているが、ＡＰＩレジストリ４０４はそれでもなお、サービスを開発するために使用されるＩＤＥ１０２からアクセスすることができる。よって、ＩＤＥ１０２は、ＡＰＩ定義ファイル７０２をＡＰＩレジストリ４０４にアップロードするメカニズムを提供することができる。具体的には、ＩＤＥ１０２のユーザインターフェイスは、開発者がＡＰＩ定義ファイル７０２のフィールドを定義するおよび／またはフィールドにポピュレートすることを可能にするウィンドウまたはインターフェイスを含み得る。上述のこの情報は、関数名、パラメータリスト、データタイプ、フィールド長、オブジェクトクラス定義、ＩＰアドレスおよびポート番号、サービス名またはその他の固有識別子などを、含み得る。この情報は、ＡＰＩレジストリ４０４にアップロードすることができ、動的バインディングによって、エンドポイント６０２の特定のＩＰアドレスおよびポート番号にリンクさせることができる。最後に、ＡＰＩレジストリ４０４は、ＡＰＩレジストリ４０４を介して利用できるようにすることができる１つ以上のＡＰＩ関数７０４を生成することができる。
【0035】
サービスがＡＰＩレジストリ４０４に登録され１つ以上のＡＰＩ関数が生成された後に、ＡＰＩレジストリは、開発者がサービスを設計する際にこれらの関数を利用できるようにすることができる。図８は、いくつかの実施形態に係る、ＡＰＩレジストリ４０４に登録されたＡＰＩをブラウズし選択するためのグラフィカルインターフェイス８０２およびコマンドラインインターフェイス８０４の例を示す。コンテナプラットフォームに対して新たなサービスをプログラミングおよび開発するときに、開発者は、グラフィカルインターフェイス８０２にアクセスすることにより、それらのサービスで使用できるＡＰＩ関数をブラウズし選択することができる。このグラフィカルインターフェイス８０２は、一例にすぎず、ＡＰＩ関数をブラウズし選択するために使用できるグラフィカルインターフェイスのタイプを限定することを意図している訳ではない。
【0036】
この実施形態において、ＩＤＥ１０２は、ＡＰＩレジストリに登録されているＡＰＩのリストを提供するようグラフィカルインターフェイス８０２に命じることができる。この
実施形態において、ＡＰＩはエンドポイントに基づいてカテゴライズされる。たとえば、あるサービスに対応する１つのエンドポイントは、ユーザ記録を格納するためのＲＥＳＴｆｕｌインターフェイスを提供し得る（たとえば「UserStorage」）。グラフィカルイン
ターフェイス８０２は、選択されたエンドポイントを介して利用できるすべてのＡＰＩ関数（たとえば「CreateUser」、「DeleteUser」、「UpdateUser」など）を表示することができる。その他の実施形態は、サービスが複数のエンドポイントを提供する場合、サービス全体に基づいて関数をグループ分けすることができる。グラフィカルインターフェイス８０２は、呼び出し側サービスで使用される１つ以上のＡＰＩ関数の選択を受けることができる。ＡＰＩレジストリは次に、必要なパラメータおよびリターン値を含む、ＡＰＩ関数の使用方法を示す文書を提供することができる。当業者は、コマンドラインインターフェイス８０４がグラフィカルインターフェイス８０２と同様の情報を提供することができかつ同様の入力を受けることができることを、理解するであろう。
実施形態において、ＡＰＩはエンドポイントに基づいてカテゴライズされる。たとえば、あるサービスに対応する１つのエンドポイントは、ユーザ記録を格納するためのＲＥＳＴｆｕｌインターフェイスを提供し得る（たとえば「UserStorage」）。グラフィカルイン
ターフェイス８０２は、選択されたエンドポイントを介して利用できるすべてのＡＰＩ関数（たとえば「CreateUser」、「DeleteUser」、「UpdateUser」など）を表示することができる。その他の実施形態は、サービスが複数のエンドポイントを提供する場合、サービス全体に基づいて関数をグループ分けすることができる。グラフィカルインターフェイス８０２は、呼び出し側サービスで使用される１つ以上のＡＰＩ関数の選択を受けることができる。ＡＰＩレジストリは次に、必要なパラメータおよびリターン値を含む、ＡＰＩ関数の使用方法を示す文書を提供することができる。当業者は、コマンドラインインターフェイス８０４がグラフィカルインターフェイス８０２と同様の情報を提供することができかつ同様の入力を受けることができることを、理解するであろう。
【0037】
図８に示されるインターフェイス８０２、８０４は複数の技術的利点を提供する。第１に、これらのインターフェイス８０２、８０４は、ＡＰＩレジストリに登録されているすべてのＡＰＩの最新一覧表を提供する。これは、コンテナプラットフォームで現在利用できるすべてのサービスのリストに相当する。文書を調べること、サービス開発者にコンタクトすること、および／または利用できるサービスのリストの場所を特定するためのその他の非効率的なタスクを実行することが要求されるのではなく、サービス開発者はこの情報をリアルタイムで取り出して表示することができる。加えて、サービスがアップデートされると、ＡＰＩ定義ファイルを対応するやり方でアップデートすることができる。これにより、次に図８に示されるディスプレイがアップデートされて各ＡＰＩ関数の最新の可用性情報を提供する。
【0038】
図９は、いくつかの実施形態に係る、ＡＰＩレジストリに登録されたサービスおよびその対応する関数を使用する方法のフローチャートを示す。この方法は、登録されたＡＰＩの一覧表を提供することを含み得る（９０１）。所望のサービスが既にわかっている場合はこのステップを省略してもよい。しかしながら、一般的に、サービスは、上述の図８のインターフェイスを用いたブラウズおよびナビゲーションのために表示することができる。この方法はまた、ＡＰＩ関数の選択を受けることを含み得る（９０３）。この選択は、ＡＰＩレジストリがサービスの開発者から受けることができるものである。たとえば、開発者は、上記CreateUser( )関数を用いてユーザ記録のデータベースをアップデートする
と決定する場合がある。図１０は、ＡＰＩレジストリが如何にしてCreateUser( )関数の
選択１００２をグラフィカルインターフェイス８０２を介して受けることができるかを示す。他の実施形態は、この選択を、コマンドラインインターフェイスを介してまたはＩＤＥが提供するその他の入力方法を介して受けることができる。
と決定する場合がある。図１０は、ＡＰＩレジストリが如何にしてCreateUser( )関数の
選択１００２をグラフィカルインターフェイス８０２を介して受けることができるかを示す。他の実施形態は、この選択を、コマンドラインインターフェイスを介してまたはＩＤＥが提供するその他の入力方法を介して受けることができる。
【0039】
再び図９を参照して、ＡＰＩレジストリは、ＡＰＩ関数の選択を受けると、呼び出し側サービスのための１つ以上のクライアントライブラリを生成することができる（９０５）。クライアントライブラリを生成することにより、呼び出し側サービスに、ＡＰＩ関数に動的にバインドされたサービスエンドポイントを提供することができる。具体的には、ＩＤＥは、コンテナプラットフォームにおけるサービスエンドポイントと直接インターフェイスするのに必要な機能をカプセル化する一組のクラスオブジェクトをＩＤＥに生成することができる。いくつかの実施形態において、クライアントライブラリは、サービスとの通信に必要なコードを実施するメンバ関数をコールするためにインスタンス化または使用することができるオブジェクトクラスを含み得る。これらのクライアントライブラリの例については以下でより詳細に説明する。
【0040】
この方法はさらに、テストデータを提供することを含み得る（９０７）。サービスは、ＡＰＩレジストリに登録されるとき、完全である必要はない。代わりに、サービスは、呼
び出し側サービスに対する機能的レスポンスを提供する準備がまだ整っていないことをＡＰＩレジストリに対して示すことができる。いくつかの実施形態において、ＡＰＩレジストリにアップロードされたＡＰＩ定義ファイルは、サービスが機能的になる前に返す必要がある情報のタイプの明細を含み得る。呼び出し側サービスがＡＰＩ関数をコールすると、ＡＰＩレジストリが生成したクライアントライブラリは、サービスエンドポイントではなくＡＰＩレジストリに要求をルーティングすることができる。そうすると、ＡＰＩレジストリは、ダミー、ヌル、またはデフォルト値を用いてレスポンスを提供することができる。これに代えて、クライアントライブラリ自身の中にあるコードが、呼び出し側サービスに返されるデフォルトデータを生成してもよい。
び出し側サービスに対する機能的レスポンスを提供する準備がまだ整っていないことをＡＰＩレジストリに対して示すことができる。いくつかの実施形態において、ＡＰＩレジストリにアップロードされたＡＰＩ定義ファイルは、サービスが機能的になる前に返す必要がある情報のタイプの明細を含み得る。呼び出し側サービスがＡＰＩ関数をコールすると、ＡＰＩレジストリが生成したクライアントライブラリは、サービスエンドポイントではなくＡＰＩレジストリに要求をルーティングすることができる。そうすると、ＡＰＩレジストリは、ダミー、ヌル、またはデフォルト値を用いてレスポンスを提供することができる。これに代えて、クライアントライブラリ自身の中にあるコードが、呼び出し側サービスに返されるデフォルトデータを生成してもよい。
【0041】
図９に示される具体的なステップが本発明の各種実施形態に係るＡＰＩレジストリの特定の使用方法を提供することが理解されるはずである。代替実施形態に従いステップの他のシーケンスを実行することもできる。たとえば、本発明の代替実施形態は、概要を述べた上記ステップを異なる順序で実行し得る。加えて、図９に示される個々のステップは、個々のステップに適したさまざまなシーケンスで実行し得る複数のサブステップを含み得る。さらに、特定のアプリケーションに応じてその他のステップを追加または削除する場合もある。当業者は、多数の変形、修正、および代替形を認識するであろう。
【0042】
図１１は、いくつかの実施形態に係る、ＡＰＩレジストリがあるサービスのために自動的に生成したクライアントライブラリの一例を示す。このクライアントライブラリ１１０２は、ユーザ記録を格納するサービスに対応し得る。このクライアントライブラリ１１０２ならびに対応するクラスおよびサービスは、例示のために提供されているにすぎず、限定を意図している訳ではない。先に述べたように、各ＡＰＩ関数およびサービスは、ＡＰＩレジストリにアップロードされたＡＰＩ定義ファイルによって如何にしてクライアントライブラリが生成されるべきかを指定することができる。したがって、「Ｕｓｅｒ（ユーザ）」サービスに関して以下で述べる原理は、その他のサービスにも適用し得る。
【0043】
Ｕｓｅｒサービスを表すために、ＡＰＩレジストリはＵｓｅｒのクラスを生成することができる。呼び出し側サービスは、ＡＰＩレジストリによるクライアントライブラリの生成を要求するとき、呼び出し側サービスが使用しているプログラミング言語を指定することができる。たとえば、呼び出し側サービスがＪａｖａでＩＤＥに記述されている場合、ＡＰＩレジストリはＪａｖａプログラミング言語でクラスライブラリを生成することができる。これに代えて、呼び出し側サービスがＣ＃で記述されている場合、ＡＰＩレジストリはＣ＃プログラミング言語でクラスライブラリを生成することができる。Ｕｓｅｒクラスは、サービスエンドポイントを介して実行することができる異なる動作に対応するメンバ関数を有するように生成することができる。これらのメンバ関数は、スタティックメンバ関数にすることにより、Ｕｓｅｒクラスのインスタンス化されたインスタンスを必要としないようにすることができる、または、インスタンス化されたＵｓｅｒオブジェクトとともに使用されてもよい。
【0044】
この例において、Ｕｓｅｒサービスは、ＲＥＳＴｆｕｌインターフェイスを使用することにより、サービスによって格納された個々のユーザ記録を編集することができる。たとえば、ＡＰＩレジストリは、CreateUser( )関数を生成することにより、Ｕｓｅｒサービ
スに対するＰＯＳＴコールを実現することができる。クラスライブラリが実行できる機能のうちの１つは、サービスに対してデータパケットとして直接送られるＡＰＩ関数に対してパラメータとして提供されるデータを、パースし、フィルタリングし、フォーマットすることである。この例において、CreateUser( )関数は、呼び出し側サービスの便宜のた
めにフォーマットされたパラメータを受け入れることができる。たとえば、呼び出し側サービスは、ユーザの名（first name）およびユーザの姓（last name）のストリングを別
々に格納することができる。しかしながら、ＰＯＳＴコマンドは、名と姓との連結ストリ
ングを必要とする場合がある。ユーザーフレンドリーなパラメータセットを受け入れるために、クライアントライブラリ１１０２は、関数に対するパラメータとして受けたデータを、サービスエンドポイントと互換性のあるフォーマットにフォーマットする一組の動作を実行することができる。これは、ヘッダ情報の生成、特定のデータフィールドのフォーマットの変更、データフィールドの連結、その他のソースからの追加データを要求すること、計算またはデータ変換の実行などを含み得る。これはまた、再フォーマットされたパラメータを、ＪＳＯＮ、ＸＭＬなどのようなフォーマットにパッケージングすることを含み得る。
スに対するＰＯＳＴコールを実現することができる。クラスライブラリが実行できる機能のうちの１つは、サービスに対してデータパケットとして直接送られるＡＰＩ関数に対してパラメータとして提供されるデータを、パースし、フィルタリングし、フォーマットすることである。この例において、CreateUser( )関数は、呼び出し側サービスの便宜のた
めにフォーマットされたパラメータを受け入れることができる。たとえば、呼び出し側サービスは、ユーザの名（first name）およびユーザの姓（last name）のストリングを別
々に格納することができる。しかしながら、ＰＯＳＴコマンドは、名と姓との連結ストリ
ングを必要とする場合がある。ユーザーフレンドリーなパラメータセットを受け入れるために、クライアントライブラリ１１０２は、関数に対するパラメータとして受けたデータを、サービスエンドポイントと互換性のあるフォーマットにフォーマットする一組の動作を実行することができる。これは、ヘッダ情報の生成、特定のデータフィールドのフォーマットの変更、データフィールドの連結、その他のソースからの追加データを要求すること、計算またはデータ変換の実行などを含み得る。これはまた、再フォーマットされたパラメータを、ＪＳＯＮ、ＸＭＬなどのようなフォーマットにパッケージングすることを含み得る。
【0045】
パラメータがサービスエンドポイントのためのパッケージに正しくフォーマットされると、クライアントライブラリ１１０２は、サービスに対するＰＯＳＴコールを扱うこともできる。クライアントライブラリが生成されるときに、サービスのＩＰアドレスおよびポート番号を、サービスに対するＨＴＴＰ要求で使用されるCreateUser( )関数に挿入する
ことができる。なお、ＨＴＴＰ要求の詳細は、CreateUser( )関数にカプセル化される。
呼び出し側サービスのための開発者が、サービスによって利用できるようにされたＰＯＳＴ関数の使用を所望する場合、コードをライブラリ１１０２自身に書き込む代わりに、ＡＰＩレジストリからＵｓｅｒサービスを選択することができる。そうすると、ＡＰＩレジストリは、Ｕｓｅｒクラスを含むクライアントライブラリ１１０２を自動的に生成する。次に、ＰＯＳＴ関数を使用するために、サービス開発者は、User.CreateUser(“John”, “Smith”, 2112)関数を使用するだけで、ユーザであるJohn Smithをサービスに追加することができる。
ことができる。なお、ＨＴＴＰ要求の詳細は、CreateUser( )関数にカプセル化される。
呼び出し側サービスのための開発者が、サービスによって利用できるようにされたＰＯＳＴ関数の使用を所望する場合、コードをライブラリ１１０２自身に書き込む代わりに、ＡＰＩレジストリからＵｓｅｒサービスを選択することができる。そうすると、ＡＰＩレジストリは、Ｕｓｅｒクラスを含むクライアントライブラリ１１０２を自動的に生成する。次に、ＰＯＳＴ関数を使用するために、サービス開発者は、User.CreateUser(“John”, “Smith”, 2112)関数を使用するだけで、ユーザであるJohn Smithをサービスに追加することができる。
【0046】
図１２は、いくつかの実施形態に係る、サービスエンドポイントとＡＰＩ関数との間の動的バインディングを含むクライアントライブラリ１２０２の実施形態を示す。この例において、ＡＰＩレジストリがクライアントライブラリ１２０２を生成するとき、CreateUser( )関数は、サービスのＩＰアドレスおよびポート番号を動的に取り出すコード１２０
４を含み得る。呼び出し側サービス１１４は、呼び出し側サービス１１４がコンテナプラットフォームのようなプロダクション／デプロイメント環境１０４で動作しているときに、GetIPPort( )関数を用いることにより実行時に要求をＡＰＩレジストリ４０４に送ることができる。ＡＰＩレジストリ４０４は、ＡＰＩ関数とサービスエンドポイントとの間の最新バインディングを維持するために常にアップデートされるその内部テーブルにアクセスすることができる。次に、ＡＰＩレジストリ４０４は、現在のＩＰアドレスおよびポート番号を呼び出し側サービス１１４に返すことができる。次に、クライアントライブラリ１２０２は、ＩＰアドレスおよびポート番号を、サービスに接続するＨＴＴＰ ＰＯＳＴコードに挿入することができる。ＡＰＩレジストリ４０４に対しては、コンテナプラットフォームにおける任意の呼び出し側サービスが実行時にアクセスできるので、コールされているサービスのポート番号についてのＩＰアドレスが変化したとき、これらのサービスのうちのいずれのサービスも、アップデートまたはパッチは不要である。代わりに、ＡＰＩレジストリ４０４は、サービスがコールされるたびに最新情報を提供することができる。いくつかの実施形態において、GetIPPort( )関数は、１時間に１度、１日に１度、１週間に１度など、ＡＰＩレジストリ４０４をコールするだけで、サービスエンドポイントはプロダクション環境において頻繁に変わるものではないという仮定のもとでサービス１１４についてコンテナの外部で行われる関数コールの数を最小にすることができる。
４を含み得る。呼び出し側サービス１１４は、呼び出し側サービス１１４がコンテナプラットフォームのようなプロダクション／デプロイメント環境１０４で動作しているときに、GetIPPort( )関数を用いることにより実行時に要求をＡＰＩレジストリ４０４に送ることができる。ＡＰＩレジストリ４０４は、ＡＰＩ関数とサービスエンドポイントとの間の最新バインディングを維持するために常にアップデートされるその内部テーブルにアクセスすることができる。次に、ＡＰＩレジストリ４０４は、現在のＩＰアドレスおよびポート番号を呼び出し側サービス１１４に返すことができる。次に、クライアントライブラリ１２０２は、ＩＰアドレスおよびポート番号を、サービスに接続するＨＴＴＰ ＰＯＳＴコードに挿入することができる。ＡＰＩレジストリ４０４に対しては、コンテナプラットフォームにおける任意の呼び出し側サービスが実行時にアクセスできるので、コールされているサービスのポート番号についてのＩＰアドレスが変化したとき、これらのサービスのうちのいずれのサービスも、アップデートまたはパッチは不要である。代わりに、ＡＰＩレジストリ４０４は、サービスがコールされるたびに最新情報を提供することができる。いくつかの実施形態において、GetIPPort( )関数は、１時間に１度、１日に１度、１週間に１度など、ＡＰＩレジストリ４０４をコールするだけで、サービスエンドポイントはプロダクション環境において頻繁に変わるものではないという仮定のもとでサービス１１４についてコンテナの外部で行われる関数コールの数を最小にすることができる。
【0047】
図１３は、いくつかの実施形態に係る、サービスコールのための入力データセットを完成させる追加データを配置できるクライアントライブラリ１３０２の実施形態を示す。クライアントライブラリ１３０２を用いた簡略化のために、クライアントライブラリ１３０２はサービス開発者に要求されるパラメータの数を最小にすることができる。サービスコールを行うために必要であろう追加データは、他のソースから取り出すことができ、したがって、パラメータリストから省略してもよい。代わりに、これらの追加パラメータは、
クライアントライブラリ１３０２がこれらの他のソースから直接取り出してもよい。たとえば、新たなユーザの作成は、このユーザのユーザロールを指定することを含み得る。パラメータのうちの１つとしてユーザロールを提供することをサービス開発者に要求する代わりに、クライアントライブラリ１３０２は、他のいずれかのソースからユーザのロールを自動的に取り出すコード１３０４を含み得る。この例において、ユーザロールは、データベースから、コンテナプラットフォーム内の別のサービスから、または呼び出し側サービス内のユーザロールを格納する別のクラスから、取り出すことができる。これらの場合のうちのいずれの場合でも、コード１３０４は、自動的にユーザロールを取り出し、これを、サービスに送られるＨＴＴＰ ＰＯＳＴコマンドのための入力データの一部としてパッケージングすることができる。
クライアントライブラリ１３０２がこれらの他のソースから直接取り出してもよい。たとえば、新たなユーザの作成は、このユーザのユーザロールを指定することを含み得る。パラメータのうちの１つとしてユーザロールを提供することをサービス開発者に要求する代わりに、クライアントライブラリ１３０２は、他のいずれかのソースからユーザのロールを自動的に取り出すコード１３０４を含み得る。この例において、ユーザロールは、データベースから、コンテナプラットフォーム内の別のサービスから、または呼び出し側サービス内のユーザロールを格納する別のクラスから、取り出すことができる。これらの場合のうちのいずれの場合でも、コード１３０４は、自動的にユーザロールを取り出し、これを、サービスに送られるＨＴＴＰ ＰＯＳＴコマンドのための入力データの一部としてパッケージングすることができる。
【0048】
サービスに対する入力のためにデータを配置しフォーマットすることに加えて、クライアントライブラリ１３０２は、サービスから受けたデータをパースして返し、エラー条件を処理することができる。この例において、ＰＯＳＴコマンドはデータパケットをＲｅｓｕｌｔ（結果）変数に返すことができる。しばしば、サービスは、呼び出し側サービスが必要とする情報よりも多くの情報を含むデータパケットを返すことができる。したがって、クライアントライブラリ１３０２は、Ｒｅｓｕｌｔ変数におけるデータフィールドをパースし、データをＲｅｓｕｌｔ変数から抽出し、ユーザクラスによって予想されるより使い易いフォーマットにフォーマットしパッケージングすることができる。この例において、コード１３０６は、Ｒｅｓｕｌｔ変数からフィールドを抽出して使用することにより、ＡＰＩ関数から返される新たなＵｓｅｒオブジェクトを作成することができる。ＧＥＴコマンドを使用する別の例において、個々のＡＰＩ関数は、ＧＥＴコマンドからのＲｅｓｕｌｔ変数から異なるフィールドを抽出するＵｓｅｒクラスで生成することができる。たとえば、Ｕｓｅｒクラスは、GetFirstName(id)関数、GetLastName(id)関数、GetRole(id)関数などを提供することができる。これらの関数は各々、Ｒｅｓｕｌｔ変数から異なるフィールドを返す間、非常によく似たコードを含み得る。
【0049】
結果をパースすることに加えて、クライアントライブラリ１３０２はまた、サービスの使用に対応付けられたエラー条件を処理するコード１３０８を生成することができる。この例において、コード１３０８は、Ｒｅｓｕｌｔ変数におけるステータス（status）フィールドをテストすることにより、ＰＯＳＴコマンドが成功したか否かを判断することができる。コマンドが成功していた場合、CreateUser( )関数は新たなＵｓｅｒオブジェクト
を返すことができる。Ｐｏｓｔコマンドが失敗した場合、関数は、代わりにヌルオブジェクトを返すことおよび／またはサービス対するコールをリトライすることが可能である。
を返すことができる。Ｐｏｓｔコマンドが失敗した場合、関数は、代わりにヌルオブジェクトを返すことおよび／またはサービス対するコールをリトライすることが可能である。
【0050】
図１４は、いくつかの実施形態に係る、サービスをコールするときにリトライを処理することができるクライアントライブラリ１４０２を示す。図１３の例と同様に、クライアントライブラリ１４０２は、ＰＯＳＴ ＨＴＴＰコールによってポピュレートされたＲｅｓｕｔ変数におけるステータスを使用することにより、このコールが成功したか否かを判断する。その結果が不成功である間、クライアントライブラリ１４０２は、コールが成功するまでリトライを続けることができる。いくつかの実施形態は、カウンターまたはその他のメカニズムを使用することにより、リトライの数を制限するまたはリトライとリトライとの間に待ち時間を追加することができる。
【0051】
上述のように、いくつかの実施形態はまた、ＡＰＩ定義とともに一組のＡＰＩプロパティをＡＰＩレジストリに与えてもよい。図１５Ａは、いくつかの実施形態に係る、ＡＰＩプロパティをＡＰＩレジストリに与える方法を示す。この方法はまた、ＡＰＩ定義のアップロードを受けることを含み得る（１５０１）。この方法はまた、ＡＰＩプロパティのアップロードを受けることを含み得る（１５０３）。プロパティのアップロードはＡＰＩ定義のアップロードと同じ送信の一部であってもよい。いくつかの実施形態において、ＡＰ
ＩプロパティはＡＰＩ定義の一部であってもよい。いくつかの実施形態において、ＡＰＩプロパティは、プロパティがＡＰＩレジストリによって設定されねばならないことを示すためにチェックされる１つ以上のフラグまたは予め定められたデータフィールドであってもよい。いくつかの実施形態において、ＡＰＩプロパティは、何らかの予め構築されたフォーマットに従う必要はないが、代わりに、認証、暗号化などのような以下で説明する特徴をＡＰＩレジストリに実現させる命令コードで表すことができる。ＡＰＩプロパティは、各サービスごとにＡＰＩ定義とともに格納することができる。
ＩプロパティはＡＰＩ定義の一部であってもよい。いくつかの実施形態において、ＡＰＩプロパティは、プロパティがＡＰＩレジストリによって設定されねばならないことを示すためにチェックされる１つ以上のフラグまたは予め定められたデータフィールドであってもよい。いくつかの実施形態において、ＡＰＩプロパティは、何らかの予め構築されたフォーマットに従う必要はないが、代わりに、認証、暗号化などのような以下で説明する特徴をＡＰＩレジストリに実現させる命令コードで表すことができる。ＡＰＩプロパティは、各サービスごとにＡＰＩ定義とともに格納することができる。
【0052】
この方法はさらに、サービスとＡＰＩとの間のＡＰＩバインディングを作成することを含み得る（１５０５）。この動作は先に詳述したように実行されてもよい。加えて、この方法は、ＡＰＩプロパティを用いて、サービスに対応付けられた１つ以上の動作を実行することを含み得る（１５０７）。ＡＰＩプロパティは、サービスのライフサイクル中のさまざまなフェーズで使用されてもよい。一般的に、これは、サービスのデプロイメント中、サービスのクライアントライブラリを生成するとき、および／またはサービスをコールするときに、プロパティに対応付けられた関数をＡＰＩプロパティを用いて実現することであると、説明することができる。これらの関数各々の例を以下でより詳細に説明する。
【0053】
図１５Ａに示される具体的なステップが本発明の各種実施形態に係るＡＰＩプロパティをＡＰＩレジストリに与える特定の方法を提供することが理解されるはずである。代替実施形態に従いステップの他のシーケンスを実行することもできる。たとえば、本発明の代替実施形態は、概要を述べた上記ステップを異なる順序で実行し得る。加えて、図１５Ａに示される個々のステップは、個々のステップに適したさまざまなシーケンスで実行し得る複数のサブステップを含み得る。さらに、特定のアプリケーションに応じてその他のステップを追加または削除する場合もある。当業者は、多数の変形、修正、および代替形を認識するであろう。
【0054】
図１５Ｂは、いくつかの実施形態に係る、如何にしてサービスがＡＰＩプロパティをＡＰＩレジストリに与えることができるかについてのハードウェア／ソフトウェア図を示す。ＩＤＥ１０２においてサービスを開発しているとき、サービス開発者は、ＡＰＩ定義ファイル１５０２と１つ以上のプロパティ１５０４とをＡＰＩレジストリ４０４に与えることができる。ＡＰＩレジストリ４０４は、ＩＤＥ１０２でもコンテナプラットフォームでも実行時にアクセスできるので、ＡＰＩレジストリ４０４は、プロパティ１５０４を格納しこれらのプロパティを使用することにより、開発シナリオ中およびランタイムシナリオ中いずれにおいても、如何にしてサービスがデプロイされ、コールされ、および／またはクライアントライブラリを生成するために使用されるかに、影響を与えることができる。
【0055】
図１６は、いくつかの実施形態に係る、ＡＰＩレジストリがプロパティを用いて高可用性のサービスをデプロイする場合のハードウェア／ソフトウェア図を示す。ＡＰＩレジストリ４０４は、特定のサービスのＡＰＩ定義ファイル１５０５に加えて、サービスが高いレジリエンスまたは高可用性を有するようにデプロイされねばならないことを示すプロパティ１６０２を受けてもよい。このプロパティ１６０２を、サービスを高可用性を有するようにデプロイするためにＡＰＩレジストリ４０４が実行する一組の命令として受けてもよい。この選択肢により、開発者は、このサービスについて「高可用性」を有するということが何を意味するかを定義することができる。たとえば、プロパティ１６０２は、ＡＰＩレジストリ４０４に、サービスの複数のインスタンス６０２、６０４をコンテナプラットフォーム２１０にデプロイさせる命令を含み得る。ＡＰＩレジストリ４０４は、これらの命令を実行することにより、自身で決定または判断を行う必要はなくなるが、代わりに、プロパティ１６０２の一部として与えられたデプロイメントコードを実行するだけでよい。
【0056】
プロパティ１６０２を、高可用性のサービスをデプロイするためにＡＰＩレジストリ４０４において既存の命令を実行するという選択肢をＡＰＩレジストリ４０４に対して示す、フラグまたは設定として受けることもできる。この選択肢の場合、ＡＰＩレジストリ４０４は、プロパティ１６０２として、実行すべき任意のコードを受ける必要はない。むしろ、ＡＰＩレジストリ４０４は、高可用性プロパティ１６０２を認識し、ＡＰＩレジストリ４０４で保持されているコードを実行することにより、サービスの複数のインスタンス６０２、６０４をデプロイすることができる。これにより、ＡＰＩレジストリ４０４は、ＡＰＩレジストリ４０４に登録された任意のサービスのデプロイメントについて、「高可用性」であるということは何を意味するのかを定義することができる。
【0057】
ＡＰＩレジストリ４０４はコンテナプラットフォーム２１０のランタイム環境に接続されているので、ＡＰＩレジストリ４０４は、コンテナプラットフォーム２１０とやり取りすることにより、サービスのランタイム可用性を決定するインスタンス６０２、６０４をデプロイすることができる。なお、図１６に示されるサービスの２つのインスタンス６０２、６０４は一例として与えられているにすぎず、限定を意図している訳ではない。高可用性サービスは、コンテナプラットフォームにデプロイされているサービスの３つ以上の冗長インスタンスを含み得る。
【0058】
いくつかの実施形態は、デフォルトとして実行することが可能なコードをＡＰＩレジストリ４０４において含み得る。高可用性が望ましいという簡単な表示のみをプロパティ１６０２が含んでいる場合、ＡＰＩレジストリ４０４は自身のコードを実行することができる。サービスをデプロイするためのデプロイメントコードをプロパティ１６０２が含んでいる場合、ＡＰＩレジストリ４０４は代わりにプロパティ１６０２のコードを実行することができる。いくつかの場合において、プロパティ１６０２は、高可用性のサービスをデプロイするのに必要なコードの一部のみを含み得る。ＡＰＩレジストリ４０４は、プロパティ１６０２から与えられたコードの一部を実行し、次に、プロパティ１６０２から与えられない任意のコードをＡＰＩレジストリ４０４におけるコードを用いてを実行することができる。これにより、開発者らは、ＡＰＩレジストリ４０４において高可用性等のプロパティを如何にして実行するかについての既存の定義を上書きしつつも、登録されたサービスによって使用されることができるプロパティを実行するための統一された定義をＡＰＩレジストリ４０４が提供できるようにすることができる。
【0059】
いくつかの実施形態において、高可用性プロパティはまた、サービスの複数のインスタンス６０２、６０４に要求を分散させるロードバランシングサービス６０６を、コンテナプラットフォーム２１０にデプロイさせてもよい。ロードバランシングサービス６０６のエンドポイントを、ＡＰＩレジストリ４０４に登録し、他のサービスが利用できるようにすることができる。これに代えてまたはこれに加えて、サービス６０２、６０４の複数のインスタンス各々をサービスエンドポイントとしてＡＰＩレジストリ４０４に登録してもよい。
【0060】
以下で説明する各々の例において、図１６に関して説明したものと同じ原理を適用することができる。たとえば、下記のいずれかのプロパティにコードが伴っていてもよく、このコードをＡＰＩレジストリ４０４が受け、そうでなければＡＰＩレジストリ４０４が実行するであろうコードを無効にするために使用することができる。本開示よりも前においては、プロパティを実行する一方で同時にサービス開発者が必要に応じてこれらのプロパティを無効にできるようにするための統一されたデフォルトを作成する方法は存在していなかった。よって、ＡＰＩレジストリ４０４は、デフォルトとしてＡＰＩレジストリ４０４でコードを実行できるようにしつつ、開発者から受けたプロパティ１６０２によってこのコードを無効にすることもできるようにすることで、技術的課題を克服する。
【0061】
図１７は、いくつかの実施形態に係る、ＡＰＩレジストリを通じてエンドツーエンド暗号化を実施するプロパティのハードウェア／ソフトウェア図を示す。ＡＰＩレジストリ４０４は、ＡＰＩ定義ファイル１５０５とともに、サービス１７０８をコールするためにエンドツーエンド暗号化を生じさせるコードを示すまたは含むプロパティ１７０４を受けてもよい。開発中、サービス１７０８は、サービス１７０８が受けたパケットを復号しサービス１７０８が返すパケットを暗号化する、自身の復号／暗号化コード１７１０を含むことができる。本開示よりも前においては、サービス１７０８のユーザがサービス１７０８と互換性のある暗号化を提供する必要があることを示す仕様書を、開発者が提供しなければならなかった。本実施形態は、呼び出し側サービス１７０６においてクライアントライブラリが如何にして生成されるかをサービス１７０８が規定できるようにしてサービス１７０８の暗号化との互換性を保証することにより、技術的課題を解決する。
【0062】
いくつかの実施形態において、サービス１７０８の開発者は、暗号化／復号コード１７１０をサービス１７０８に含める必要はない。代わりに、サービス１７０８のエンドツーエンド暗号化を実施するよう、プロパティ１７０４がＡＰＩレジストリ４０４に命令するだけでよい。サービス１７０８がコンテナプラットフォーム２１０にデプロイされるとき、ＡＰＩレジストリ４０４は、デプロイ時にサービス１７０８に暗号化／復号コード１７１０が挿入されるようにすることができる。これにより、開発者が、プロパティ１７０４に基づいて異なる暗号化制度からの選択を行うことができる、および／または、ＡＰＩレジストリ４０４が、デフォルトとして好ましい暗号化制度を選択することができる。
【0063】
エンドツーエンド暗号化には、サービス１７０８がデプロイされるときまたはその開発中に暗号化／復号コード１７１０をサービス１７０８に挿入することが必要なだけでなく、互換性のある暗号化／復号コードを呼び出し側サービス１７０６が含むことも必要である。先に述べたように、呼び出し側サービス１７０６がサービス１７０８を使用する必要があるとき、ＡＰＩレジストリ４０４は、簡単で効率的なやり方でサービス１７０８とやり取りするのに必要なコードを完全に実現する１つ以上のクライアントライブラリ１７０２を生成することができる。このクライアントライブラリ１７０２が生成されるとき、ＡＰＩレジストリ４０４は、プロパティ１７０４を分析することにより、サービス１７０８が使用する暗号化制度を判断することができる。次に、このプロパティ１７０４に基づいて、ＡＰＩレジストリ４０４は、呼び出し側サービス１７０６のために互換性のある暗号化／復号コードをクライアントライブラリ１７０２に追加することができる。よって、呼び出し側サービス１７０６が要求をサービス１７０８に送るとき、情報は呼び出し側サービス１７０６で暗号化されサービス１７０８がこの情報を受けたときに復号されてもよい。同様に、サービス１７０８は、呼び出し側サービス１７０６に送られる前のレスポンスを暗号化することができ、そうすると、呼び出し側サービス１７０６は、このレスポンスを、クライアントライブラリ１７０２の外部に送る前に復号することができる。これにより、この暗号化プロセス全体を呼び出し側サービス１７０６の開発者にとって完全にトランスペアレントなものにすることができる。サービス１７０６をコールするときに互換性のある暗号化／復号制度を実現することが要求されるのではなく、プロパティ１７０４は、ＡＰＩレジストリ４０４が互換性のある暗号化／復号コードをクライアントライブラリ１７０２に既に生成していることを保証し、エンドツーエンド暗号化プロパティを実現することができる。
【0064】
図１８は、いくつかの実施形態に係る、ＡＰＩレジストリがサービス１８０８の使用ロギングを実現するためのプロパティ１８０４を示す。本開示よりも前においては、サービスに対する要求の頻度、ソース、成功率などをモニタリングしロギングするためには、サービス自身がこの情報をロギングする必要があった。これに代わるものとしては、コンテナ環境がサービスをモニタリングしその使用情報をロギングする必要があった。サービス１８０８自体において情報をロギングすることは、極めて非効率であり、このサービスが
扱うすべての要求についてのスループットを減速させる。同様に、特定のサービスに対して行われるコールすべてをモニタリングしロギングすることをコンテナプラットフォームに求めるときのオーバーヘッドも、コンテナサービスのスケジューリングおよびオーケストレーションに対する極めて大きなオーバーヘッドを表している。本実施形態は、この技術的課題を、サービス１８０８をコールするサービスのためのクライアントライブラリにコードを直接挿入することによって解決する。これにより、メモリの使用またはＣＰＵの使用という点でサービス１８０８のパフォーマンスに全く影響を与えることなく、サービス１８０８の使用をロギングしモニタリングすることができる。
扱うすべての要求についてのスループットを減速させる。同様に、特定のサービスに対して行われるコールすべてをモニタリングしロギングすることをコンテナプラットフォームに求めるときのオーバーヘッドも、コンテナサービスのスケジューリングおよびオーケストレーションに対する極めて大きなオーバーヘッドを表している。本実施形態は、この技術的課題を、サービス１８０８をコールするサービスのためのクライアントライブラリにコードを直接挿入することによって解決する。これにより、メモリの使用またはＣＰＵの使用という点でサービス１８０８のパフォーマンスに全く影響を与えることなく、サービス１８０８の使用をロギングしモニタリングすることができる。
【0065】
ＡＰＩレジストリ４０４は、ＡＰＩ定義ファイル１５０５に加えて、使用ロギング１８０４を実現するコードを示すまたは含むプロパティ１８０４を受けることができる。呼び出し側サービス１８０６の開発者が要求をサービス１８０８に出すことを所望するとき、ＡＰＩレジストリ４０４は、サービス１８０８に関するアクティビティをロギングするためのコードを含むクライアントライブラリ１８０２を自動的に生成することができる。先に述べたように、このコードは、ＡＰＩレジストリ４０４が管理し実行するデフォルトコードに基づいて生成することができる、または、プロパティ１８０４とともに受けてＡＰＩレジストリ４０４が実行するコードによって生成することができる。
【0066】
クライアントライブラリ１８０２における、アクティビティをロギングするためのコードは、サービス１８０８がコールされるたびにインクリメントされるカウンターと、サービス１８０８がコールされたときにアクティビティをログファイルにロギングさせる関数と、サービス１８０８に送られた要求およびサービス１８０８から受けたレスポンスの特徴をモニタリングし記録するその他の関数とを、含み得る。特定の実施形態に応じて、このコードは、サービス１８０８に対して行われる要求に対応付けられた多数の異なる種類の特徴をモニタリングしてもよい。たとえば、いくつかの実施形態は、サービス１８０８に対して行われたコールの総数をロギングしてもよい。いくつかの実施形態は、サービス１８０８から受けたレスポンスの成功率をロギングしてもよい。いくつかの実施形態は、サービス１８０８に対する要求において送られたデータのタイプをロギングしてもよい。いくつかの実施形態は、サービス１８０８がコールされた時刻またはサービス１８０８がコールされたときについてのその他の外部情報をロギングしてもよい。いくつかの実施形態は、サービス１８０８をデバッグするために使用することが可能なサービス１８０８への／からの入力および出力をロギングしてもよい。いくつかの実施形態は、限定されることなく、これらの特徴のうちのいずれかまたはすべてを、任意の組み合わせでロギングしてもよい。
【0067】
図１９は、いくつかの実施形態に係る、サービス１９０８の認証プロトコルを実施することが可能なプロパティ１９０４のハードウェア／ソフトウェア図を示す。いくつかのサービスは、要求に応答する前に、ユーザアイデンティティが認証されることおよびユーザがサービスの使用を認可されることを必要とする場合がある。本開示よりも前においては、認証および認可の手続がサービス１９０８自体で行われるという技術的課題があった。これは、サービス１９０８が受けるすべてのコールについてメモリの使用およびＣＰＵの使用という点でオーバーヘッドを増加させ、レスポンスにおけるサービスのレイテンシを大きくした。その結果、スループットが減少し、所定の期間中にサービス１９０８が処理できる要求の数が制限された。これらの実施形態は、この技術的課題を、認証／認可コードを、ＡＰＩレジストリ１４０４が自動的に生成するクライアントライブラリ１９０２に移動させることによって解決する。
【0068】
呼び出し側サービス１９０６がサービス１９０８の使用を所望するとき、ＡＰＩレジストリ４０４は、認可および／認証を実行するためのコードを含むクライアントライブラリ１９０２を生成することができる。いくつかの実施形態において、これは、ユーザアイデ
ンティティを特別に検証するおよび／またはユーザがサービス１９０８の使用を認可されるか否かを判断する外部認証／認可サービス１９２０にコンタクトすることを含み得る。外部認証／認可サービス１９２０は、アクセスマネージャ、ライトウェイトディレクトリアクセスプロトコル（Lightweight Directory Access Protocol）（ＬＤＡＰ）マネージ
ャ、アクセスコントロールリスト（Access Control List）（ＡＣＬ）、ネットワーク認
証プロトコルマネージャなどを、含み得る。そうすると、クライアントライブラリ１９０２内のコードは、認証／認可手続が成功したときにコールをサービス１９０８に送ることができる。
ンティティを特別に検証するおよび／またはユーザがサービス１９０８の使用を認可されるか否かを判断する外部認証／認可サービス１９２０にコンタクトすることを含み得る。外部認証／認可サービス１９２０は、アクセスマネージャ、ライトウェイトディレクトリアクセスプロトコル（Lightweight Directory Access Protocol）（ＬＤＡＰ）マネージ
ャ、アクセスコントロールリスト（Access Control List）（ＡＣＬ）、ネットワーク認
証プロトコルマネージャなどを、含み得る。そうすると、クライアントライブラリ１９０２内のコードは、認証／認可手続が成功したときにコールをサービス１９０８に送ることができる。
【0069】
認証／認可の実施をＡＰＩレジストリ４０４およびクライアントライブラリ１９０２にオフロードすることにより、このコードをサービス１９０８から完全に除去することができる。外部認証／認可サービス１９２０とのやり取りには多大な遅延が伴うことが頻繁に生じ得るので、この遅延をサービス１９０８から取り除くことによってスループットを高めることができる。加えて、認証／認可の実施をサービス１９０８にハードコーディングするのではなく、サービス１９０８の開発者が、その代わりにＡＰＩレジストリ４０４に送られたプロパティ１９０４を用いて予め定められた認証／認可制度を選択するだけでよい。ＡＰＩレジストリ４０４は、認可／認証の予め定められたリストを、クライアントライブラリ１９０２の添付のインプリメンテーションコードとともに管理することができる。これはまた、認可および／または認証されることができないサービス１９０８に対して呼び出し側サービス１９０６が要求を送ることを防止する。代わりに、認証および／または認可ルーチンが失敗した場合はクライアントライブラリ１９０２でコールを中止してもよい。これにより、認証および／または認可された要求のみをサービス１９０８が受けることを保証する。
【0070】
ＡＰＩレジストリ４０４が提供するもう１つの技術的改善は、登録されたいずれかのサービスのコードのうちのいずれかを変更することを要求されることなく、プロパティ１９０４が提供する機能のいずれかをアップグレードする機能である。たとえば、認証／認可コードは、ＡＰＩレジストリ１４０４が生成したクライアントライブラリ１９０２にオフロードされているので、クライアントライブラリ１９０２をアップデートすることにより、認証／認可制度を変更することが可能である。呼び出し側サービス１９０６またはサービス１９０８におけるコードのうちのいずれもモニタリングする必要はない。コードは１つの場所でしか変更されないので、これは、そうでなければすべての個別サービスに送られる分散型パッチを伴うコード統合エラーの確率を大幅に減じる。
【0071】
図２０は、いくつかの実施形態に係る、サービスのランタイムインスタンス化を可能にするプロパティ２００４のハードウェア／ソフトウェア図を示す。いくつかのサービスは、滅多に使用されない、または所定の期間中にしか使用されない場合がある。したがって、サービスをコンテナプラットフォームにデプロイすることが、常に、即時利用可能なサービスのインスタンスを実際にコンテナにインスタンス化することにつながる必要はない。仮想マシンとは異なり、コンテナは非常に素早くインスタンス化し作動させることが可能である。そのため、サービス開発者は、コールされたときにのみサービスをインスタンス化させることを所望する場合がある。サービス開発者はまた、所定の期間内においてのみサービスをインスタンス化させることを所望する場合がある。同じく、サービス開発者は、サービスインスタンスは所定の休止期間が過ぎると削除されねばならないと明示する場合がある。
【0072】
ＡＰＩレジストリ４０４は、ＡＰＩ定義ファイル１５０５を受けることに加えて、ランタイムインスタンス化またはその他のインスタンス化パラメータを指定するプロパティ２００４を受けることができる。たとえば、このプロパティは、サービス２００８をデプロイ後にインスタンス化すべき１つ以上の期間の指定を含み得る。別の例において、このプ
ロパティは、サービス２００８はオンデマンドでのみインスタンス化されねばならないという表示を含み得る。別の例において、このプロパティは、タイムアウト期間を指定してもよく、インスタンス化されたサービス２００８はこのタイムアウト期間後にコンテナプラットフォームから削除されねばならない。
ロパティは、サービス２００８はオンデマンドでのみインスタンス化されねばならないという表示を含み得る。別の例において、このプロパティは、タイムアウト期間を指定してもよく、インスタンス化されたサービス２００８はこのタイムアウト期間後にコンテナプラットフォームから削除されねばならない。
【0073】
呼び出し側サービス２００６がサービス２００８の使用を所望するとき、ＡＰＩレジストリ４０４は、サービス２００８のランタイムインスタンス化を処理するコードをクライアントライブラリ２００２に生成することができる。たとえば、クライアントライブラリ２００２のCreateInstance( )関数コールは、ＡＰＩレジストリ４０４に対するコールを
作成することができる。そうすると、ＡＰＩレジストリはコンテナプラットフォーム２１０とやり取りすることにより、サービス２００８のオペレーティングインスタンスを利用できるか否かを判断することができる。利用できない場合、ＡＰＩレジストリ４０４は、コンテナプラットフォーム２０１０のコンテナにサービス２００８のインスタンスをインスタンス化するようコンテナプラットフォーム２１０に命令することができる。そうすると、コンテナプラットフォーム２１０は、エンドポイント（たとえばＩＰアドレスおよびポート番号）をＡＰＩレジストリ４０４に返すことができる。次に、ＡＰＩレジストリ４０４は、エンドポイントと、クライアントライブラリ２００２に作成されたＡＰＩ関数コールとの間のバインディングを作成することができる。次に、ＡＰＩレジストリ４０４は、このエンドポイントをクライアントライブラリ２００２に返すことができ、これを用いることにより、呼び出し側サービス２００６と新たにインスタンス化されたサービス２００８との間の直接接続を作成することができる。
作成することができる。そうすると、ＡＰＩレジストリはコンテナプラットフォーム２１０とやり取りすることにより、サービス２００８のオペレーティングインスタンスを利用できるか否かを判断することができる。利用できない場合、ＡＰＩレジストリ４０４は、コンテナプラットフォーム２０１０のコンテナにサービス２００８のインスタンスをインスタンス化するようコンテナプラットフォーム２１０に命令することができる。そうすると、コンテナプラットフォーム２１０は、エンドポイント（たとえばＩＰアドレスおよびポート番号）をＡＰＩレジストリ４０４に返すことができる。次に、ＡＰＩレジストリ４０４は、エンドポイントと、クライアントライブラリ２００２に作成されたＡＰＩ関数コールとの間のバインディングを作成することができる。次に、ＡＰＩレジストリ４０４は、このエンドポイントをクライアントライブラリ２００２に返すことができ、これを用いることにより、呼び出し側サービス２００６と新たにインスタンス化されたサービス２００８との間の直接接続を作成することができる。
【0074】
所定の期間中のみインスタンス化されるべきサービスの場合、ＡＰＩレジストリ４０４は、特定のサービスのインスタンス化および削除時間のテーブルを構築してもよい。格納されたこれらのインスタンス化／削除時間に基づいて、ＡＰＩレジストリ４０４は、サービス２００８のインスタンスをインスタンス化または削除するようコンテナプラットフォーム２１０に命令することができる。ＡＰＩレジストリ４０４は、これらの所定期間中にインスタンス化すべきインスタンスの数を指定することもできる。たとえば、プロパティ２００４は、午後５時から午後１０時まで、サービス２００８の少なくとも１０のインスタンスがコンテナプラットフォーム２１０上でアクティブであることを明示してもよい。この期間になると、ＡＰＩレジストリ４０４は、追加のインスタンスを作成するようコンテナプラットフォーム２１０に命令することができる。
【0075】
図２１は、いくつかの実施形態に係る、サービス２１０８のレート制限関数を実現するプロパティ２１０４のハードウェア／ソフトウェア図を示す。いくつかのサービスは、要求を受けるレートを制限する必要がある場合がある。その他のサービスは、特定の送信者または特定のタイプのサービスからの要求を制限する必要がない場合がある。本開示よりも前においては、この関数は、サービス自体が、各要求のソースを判断し、このソースをホワイトリスト／ブラックリストと比較し、これらの要求をサービスするレートを絞ることにより、実行しなければならなかった。上記例のうちのほとんどと同様、このオーバーヘッドをサービス自体に課すと、サービスが使用するメモリおよびＣＰＵパワーの量が増し、サービスのスループットが制限される。これらの実施形態は、この技術的課題を、ＡＰＩレジストリが生成したクライアントライブラリにレート制限コードを自動的に生成することによって解決する。これにより、サービス２１０８がその関係するオーバーヘッドすべてを伴ってこの機能を実現しなくても、サービスはプロパティ２１０４によってレート制限を指定することができる。
【0076】
呼び出し側サービス２１０６が要求をサービス２１０８に送ることを所望するとき、ＡＰＩレジストリ４０４は、レート制限コードを含むクライアントライブラリ２１０２を自動的に生成することができる。クライアントライブラリ２１０２が生成されると、ＡＰＩ
レジストリ４０４は、特定のサービス２１０６のレート制限が必要か否かを判断することができる。必要でなければ、クライアントライブラリ２１０２を通常通り生成することができる。ＡＰＩレジストリ４０４が、呼び出し側サービス２１０６をレート制限すべきであると判断した場合（たとえばホワイトリスト／ブラックリストとの比較によって）、ＡＰＩレジストリ４０４は、遅延を追加する、カウンターを追加する、および／またはそうでなければレート制限関数を実現するコードをクライアントライブラリ２１０２に挿入することにより、所定のレートに従って任意の所定期間において呼び出し側サービス２１０６が所定の最大数の要求を行うことを保証することができる。このコードは、その間はレート制限関数がアクティブである時間ウィンドウを実現してもよい。これにより、サービス２１０８は、高トラフィック期間中レート制限を自動的に実施することができる。
レジストリ４０４は、特定のサービス２１０６のレート制限が必要か否かを判断することができる。必要でなければ、クライアントライブラリ２１０２を通常通り生成することができる。ＡＰＩレジストリ４０４が、呼び出し側サービス２１０６をレート制限すべきであると判断した場合（たとえばホワイトリスト／ブラックリストとの比較によって）、ＡＰＩレジストリ４０４は、遅延を追加する、カウンターを追加する、および／またはそうでなければレート制限関数を実現するコードをクライアントライブラリ２１０２に挿入することにより、所定のレートに従って任意の所定期間において呼び出し側サービス２１０６が所定の最大数の要求を行うことを保証することができる。このコードは、その間はレート制限関数がアクティブである時間ウィンドウを実現してもよい。これにより、サービス２１０８は、高トラフィック期間中レート制限を自動的に実施することができる。
【0077】
本明細書に記載の各方法は、専用コンピュータシステムによって実現することができる。これらの方法の各ステップは、当該コンピュータシステムが自動的に実行してもよく、および／またはユーザを必要とする入力／出力が与えられてもよい。たとえば、ユーザが方法の各ステップに対して入力を与えてもよく、これらの入力は各々、このような入力を要求する、コンピュータシステムが生成した特定の出力に応じて与えられてもよい。各入力は、対応する要求出力に応じて受けられてもよい。さらに、入力は、ユーザから受けられてもよく、別のデータシステムからデータストリームとして受けられてもよく、メモリロケーションから取り出されてもよく、ネットワークを介して取り出されてもよく、ウェブサービスから要求されてもよく、および／またはその他であってもよい。同様に、出力は、ユーザに与えられてもよく、データストリームとして別のコンピュータシステムに与えられてもよく、メモリロケーションに保存されてもよく、ネットワークを介して送られてもよく、ウェブサービスに与えられてもよく、および／またはその他であってもよい。すなわち、本明細書に記載の方法の各ステップは、コンピュータシステムが実行し得るものであり、かつ、ユーザを必要とするもしくは必要としないかもしれないコンピュータシステムに対する、任意の数の入力、当該コンピュータシステムからの出力、および／または当該コンピュータシステムへの／からの要求を必要とし得るものである。ユーザを必要としないステップは、人の介入なしでコンピュータシステムが自動的に実行し得ると言える。したがって、本開示に照らして、本明細書に記載の各方法の各ステップは、ユーザへのおよびユーザからの入力および出力を含むように変更されてもよく、または、プロセッサが何らかの判断を行う場合は人の介入なしでコンピュータシステムが自動的に行ってもよい。さらに、本明細書に記載の各方法のいくつかの実施形態は、有形の非一時的な記憶媒体に格納されて有形のソフトウェアプロダクトを形成する一組の命令として実現されてもよい。
【0078】
図２２は、上記実施形態のうちのいずれかとのやり取りが可能な分散型システム２２００の簡略図を示す。示されている実施形態において、分散型システム２２００は１つ以上のクライアントコンピューティングデバイス２２０２、２２０４、２２０６、および２２０８を含み、これらのクライアントコンピューティングデバイスは、１つ以上のネットワーク２２１０を介してウェブブラウザ、専用クライアント（たとえばOracle Forms）などのようなクライアントアプリケーションを実行し操作するように構成されている。サーバ２２１２が、ネットワーク２２１０を介してリモートクライアントコンピューティングデバイス２２０２、２２０４、２２０６、および２２０８に対して通信可能に結合されていてもよい。
【0079】
各種実施形態において、サーバ２２１２は、このシステムのコンポーネントのうちの１つ以上が提供する１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされてもよい。いくつかの実施形態において、これらのサービスは、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および／または２２０８のユーザに対し、ウェブベースのもしくはクラウドサービスとして、またはサービスとしての
ソフトウェア（ＳａａＳ）モデルのもとで、提供されてもよい。そうすると、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および／または２２０８を操作しているユーザは、１つ以上のクライアントアプリケーションを利用してサーバ２２１２とやり取りすることにより、これらのコンポーネントが提供するサービスを利用することができる。
ソフトウェア（ＳａａＳ）モデルのもとで、提供されてもよい。そうすると、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および／または２２０８を操作しているユーザは、１つ以上のクライアントアプリケーションを利用してサーバ２２１２とやり取りすることにより、これらのコンポーネントが提供するサービスを利用することができる。
【0080】
図面に示される構成において、システム２２００のソフトウェアコンポーネント２２１８、２２２０および２２２２は、サーバ２２１２上に実装されたものとして示されている。他の実施形態において、システム２２００のコンポーネントおよび／またはこれらのコンポーネントが提供するサービスのうちの１つ以上が、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および／または２２０８のうちの１つ以上によって実装されてもよい。そうすると、クライアントコンピューティングデバイスを操作しているユーザは、１つ以上のクライアントアプリケーションを利用することにより、これらのコンポーネントが提供するサービスを使用することができる。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはその組み合わせで実装されてもよい。分散型システム２２００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるはずである。図面に示される実施形態はしたがって、実施形態のシステムを実装するための分散型システムの一例であって、限定を意図したものではない。
【0081】
クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および／または２２０８は、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ゲームコンソール）、および／またはパーソナルメッセージングデバイス等の、電子デバイスであってもよい。
イルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、Blackberry（登録商標）、またはその他の通信プロトコルに接続可能な、ポータブルハンドヘルドデバイス（たとえばiPhone（登録商標）、携帯電話、iPad（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）であってもよい。クライアントコンピューティングデバイスは、例として、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステムを実行するパーソナルコンピュータお
よび／またはラップトップコンピュータを含む汎用パーソナルコンピュータであってもよい。クライアントコンピューティングデバイスは、限定されないがたとえばGoogle Chrome OS等のさまざまなGNU/Linux（登録商標）オペレーティングシステムを含む市場で入手
可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであってもよい。これに代えてまたはこれに加えて、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および２２０８は、ネットワーク２２１０を介して通信可能な、シンクライアントコンピュータ、インターネット接続可能なゲームシステム（たとえばKinect（登録商標）ジェスチャー入力デバイスを有するまたは有しないMicrosoft Xboxゲームコンソール）、および／またはパーソナルメッセージングデバイス等の、電子デバイスであってもよい。
【0082】
具体例としての分散型システム２２００が４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートすることができる。センサなどを有するデバイスのようなその他のデバイスがサーバ２２１２とやり取りしてもよい。
【0083】
分散型システム２２００のネットワーク２２１０は、限定されないがＴＣＰ／ＩＰ（transmission control protocol/Internet protocol）、ＳＮＡ（systems network archite
cture）、ＩＰＸ（Internet packet exchange）、AppleTalk（登録商標）などを含む、市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。一例にすぎないが、ネットワーク２２１０は、たとえばイーサネット（登録商標）、トークンリングおよび／または同様のものに基づく、ローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク２２１０は、広域ネットワークおよびインターネットであってもよい。これは、限定されないが仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえばInstitute of Electrical and Electronics（ＩＥＥＥ）８０２．１１プロト
コルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのう
ちのいずれかの下で動作するネットワーク）、および／または上記および／またはその他のネットワークの任意の組み合わせを含む、仮想ネットワークを含み得る。
cture）、ＩＰＸ（Internet packet exchange）、AppleTalk（登録商標）などを含む、市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。一例にすぎないが、ネットワーク２２１０は、たとえばイーサネット（登録商標）、トークンリングおよび／または同様のものに基づく、ローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク２２１０は、広域ネットワークおよびインターネットであってもよい。これは、限定されないが仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえばInstitute of Electrical and Electronics（ＩＥＥＥ）８０２．１１プロト
コルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのう
ちのいずれかの下で動作するネットワーク）、および／または上記および／またはその他のネットワークの任意の組み合わせを含む、仮想ネットワークを含み得る。
【0084】
サーバ２２１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを含む）、サーバファーム、サーバクラスタ、または、その他任意の適切な構成および／または組み合わせからなるものであってもよい。各種実施形態において、サーバ２２１２は、上の開示で説明した１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。たとえば、サーバ２２１２は、本開示の実施形態に係る上記処理を実行するためのサーバに対応していてもよい。
【0085】
サーバ２２１２は、上記オペレーティングシステムのうちのいずれかおよび市場で入手可能なサーバオペレーティングシステムを含むオペレーティングシステムを実行し得る。また、サーバ２２１２は、ＨＴＴＰ（hypertext transport protocol）サーバ、ＦＴＰ（file transfer protocol）サーバ、ＣＧＩ（common gateway interface）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、さまざまな付加的なサーバアプリケーションおよび／またはミッドティアアプリケーションのうちのいずれかを実行し得る。具体例としてのデータベースサーバは、Oracle、Microsoft、Sybase、ＩＢＭ（International Business Machines）などから市販されているものを含むが、これらに限定されない。
【0086】
いくつかの実装例において、サーバ２２１２は、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および２２０８のユーザから受信したデータフィードおよび／またはイベントアップデートを分析し統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、限定されないが、１つ以上の第三者情報源および連続データストリームから受信したTwitter（登録商標）フィード、Facebook（登録商標）アップデートまたはリアルタイムアッ
プデートを含み得る。これらはセンサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る。また、サーバ２２１２は、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および２２０８の１つ以上のディスプレイデバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含み得る。
プデートを含み得る。これらはセンサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る。また、サーバ２２１２は、クライアントコンピューティングデバイス２２０２、２２０４、２２０６、および２２０８の１つ以上のディスプレイデバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含み得る。
【0087】
分散型システム２２００は、１つ以上のデータベース２２１４および２２１６も含み得る。データベース２２１４および２２１６はさまざまな場所に存在し得る。一例として、データベース２２１４および２２１６のうちの１つ以上は、サーバ２２１２に対してローカルな場所にある（および／またはサーバ内にある）非一時的な記憶媒体上にあってもよ
い。これに代えて、データベース２２１４および２２１６は、サーバ２２１２から遠隔の場所に位置してネットワークベースのまたは専用接続を介してサーバ２２１２と通信してもよい。一組の実施形態において、データベース２２１４および２２１６は、ストレージエリアネットワーク（ＳＡＮ）内にあってもよい。同様に、サーバ２２１２に帰する機能を実行するために必要な任意のファイルを、適宜、サーバ２２１２にローカルにおよび／またはサーバ２２１２から遠隔の場所に格納してもよい。一組の実施形態において、データベース２２１４および２２１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、アップデートし、取り出すようにされた、Oracleが提供するデータベース等のリレーショナルデータベースを含み得る。
い。これに代えて、データベース２２１４および２２１６は、サーバ２２１２から遠隔の場所に位置してネットワークベースのまたは専用接続を介してサーバ２２１２と通信してもよい。一組の実施形態において、データベース２２１４および２２１６は、ストレージエリアネットワーク（ＳＡＮ）内にあってもよい。同様に、サーバ２２１２に帰する機能を実行するために必要な任意のファイルを、適宜、サーバ２２１２にローカルにおよび／またはサーバ２２１２から遠隔の場所に格納してもよい。一組の実施形態において、データベース２２１４および２２１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、アップデートし、取り出すようにされた、Oracleが提供するデータベース等のリレーショナルデータベースを含み得る。
【0088】
図２３は、本開示の実施形態に係る、実施形態のシステムの１つ以上のコンポーネントがサービスをクラウドサービスとして提供し得るシステム環境２３００の１つ以上のコンポーネントの簡略化されたブロック図である。示されている実施形態において、システム環境２３００は、クラウドサービスを提供するクラウドインフラストラクチャシステム２３０２とやり取りするためにユーザが使用し得る１つ以上のクライアントコンピューティングデバイス２３０４、２３０６、および２３０８を含む。クライアントコンピューティングデバイスは、クライアントコンピューティングデバイスのユーザがクラウドインフラストラクチャシステム２３０２とやり取りすることによってクラウドインフラストラクチャシステム２３０２が提供するサービスを使用するために用いることができる、ウェブブラウザ、専用クライアントアプリケーション（たとえばOracle Forms）、またはその他何らかのアプリケーション等のクライアントアプリケーションを操作するように構成されてもよい。
【0089】
図面に示されているクラウドインフラストラクチャシステム２３０２は示されているもの以外のコンポーネントを有し得ることが理解されるはずである。さらに、図面に示されている実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一例にすぎない。他のいくつかの実施形態において、クラウドインフラストラクチャシステム２３０２は、図示されているものよりも多いまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成または配置を有していてもよい。
【0090】
クライアントコンピューティングデバイス２３０４、２３０６、および２３０８は、２２０２、２２０４、２２０６、および２２０８について先に述べたものと同様のデバイスであってもよい。
【0091】
具体例としてのシステム環境２３００は３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートすることができる。センサなどを有するデバイスのようなその他のデバイスがクラウドインフラストラクチャシステム２３０２とやり取りしてもよい。
【0092】
ネットワーク２３１０は、クライアント２３０４、２３０６、および２３０８とクラウドインフラストラクチャシステム２３０２との間におけるデータの通信および交換を容易にすることができる。各ネットワークは、ネットワーク２２１０について先に述べたものを含む市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。
【0093】
クラウドインフラストラクチャシステム２３０２は、１つ以上のコンピュータ、および／またはサーバ２２１２について先に述べたものを含み得るサーバを含み得る。
【0094】
特定の実施形態において、クラウドインフラストラクチャシステムが提供するサービス
は、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされているオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理された技術サポートサービスなどのような、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用できるようにされる多数のサービスを含み得る。クラウドインフラストラクチャシステムが提供するサービスは、そのユーザのニーズに合わせて動的にスケーリングすることができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものを本明細書では「サービスインスタンス」と呼ぶ。一般的に、クラウドサービスプロバイダのシステムからの、インターネットのような通信ネットワークを介してユーザが利用できるようにされる任意のサービスを、「クラウドサービス」と呼ぶ。典型的に、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストすることができ、ユーザは、インターネットのような通信ネットワークを介して、オンデマンドでこのアプリケーションをオーダーし使用することができる。
は、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされているオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理された技術サポートサービスなどのような、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用できるようにされる多数のサービスを含み得る。クラウドインフラストラクチャシステムが提供するサービスは、そのユーザのニーズに合わせて動的にスケーリングすることができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものを本明細書では「サービスインスタンス」と呼ぶ。一般的に、クラウドサービスプロバイダのシステムからの、インターネットのような通信ネットワークを介してユーザが利用できるようにされる任意のサービスを、「クラウドサービス」と呼ぶ。典型的に、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストすることができ、ユーザは、インターネットのような通信ネットワークを介して、オンデマンドでこのアプリケーションをオーダーし使用することができる。
【0095】
いくつかの例において、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってまたは当該技術において周知の他のやり方でユーザに提供される、ストレージ、ホストされているデータベース、ホストされているウェブサーバ、ソフトウェアアプリケーション、またはその他のサービスに対する保護されたコンピュータネットワークアクセスを含み得る。たとえば、サービスは、インターネットを介した、クラウド上の遠隔ストレージに対するパスワードで保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク化された開発者の私的使用のための、ウェブサービスベースのホストされているリレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされている電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。
【0096】
特定の実施形態において、クラウドインフラストラクチャシステム２３０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼性が高く、可用性が高く、かつ安全なやり方で顧客に与えられる、アプリケーション、ミドルウェア、およびデータベースサービス提供物一式を含み得る。そのようなクラウドインフラストラクチャシステムの一例は、本願の譲受人が提供するOracle Public Cloudである。
【0097】
各種実施形態において、クラウドインフラストラクチャシステム２３０２は、クラウドインフラストラクチャシステム２３０２が提供するサービスに対する顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するようにされていてもよい。クラウドインフラストラクチャシステム２３０２は、異なるデプロイメントモデルを介してクラウドサービスを提供することができる。たとえば、（例としてOracle所有の）クラウドサービスを販売する組織がクラウドインフラストラクチャシステム２３０２を所有しており一般の人々または異なる産業企業がサービスを利用できるようにされるパブリッククラウドモデルの下で、サービスが提供されてもよい。別の例として、クラウドインフラストラクチャシステム２３０２が１つの組織のためにのみ運営されこの組織内の１つ以上のエンティティのためにサービスを提供し得るプライベートクラウドモデルの下で、サービスが提供されてもよい。また、クラウドインフラストラクチャシステム２３０２およびクラウドインフラストラクチャシステム２３０２が提供するサービスを関連するコミュニティー内のいくつかの組織が共有するコミュニティークラウドモデルの下で、クラウドサービスが提供されてもよい。また、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で、クラウドサービスが提供されてもよい。
【0098】
いくつかの実施形態において、クラウドインフラストラクチャシステム２３０２が提供するサービスは、サービスとしてのソフトウェア（ＳａａＳ）カテゴリ、サービスとしてのプラットフォーム（ＰａａＳ）カテゴリ、サービスとしてのインフラストラクチャ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される、１つ以上のサービスを含み得る。顧客は、クラウドインフラストラクチャシステム２３０２が提供する１つ以上のサービスを、サブスクリプションオーダーを通じてオーダーすることができる。そうすると、クラウドインフラストラクチャシステム２３０２は、この顧客のサブスクリプションオーダーのサービスを提供するために処理を実行する。
【0099】
いくつかの実施形態において、クラウドインフラストラクチャシステム２３０２が提供するサービスは、限定されないが、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得る。いくつかの例において、アプリケーションサービスは、クラウドインフラストラクチャシステムがＳａａＳプラットフォームを介して提供することができる。ＳａａＳプラットフォームは、ＳａａＳカテゴリに含まれるクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合開発およびデプロイメントプラットフォーム上でオンデマンドアプリケーション一式を構築し配信する機能を提供することができる。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理し制御することができる。ＳａａＳプラットフォームが提供するサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用することが可能である。顧客は、顧客が別々のライセンスおよびサポートを購入しなくても、アプリケーションサービスを得ることが可能である。さまざまな異なるＳａａＳサービスを提供することができる。例は、限定されないが、大組織向けの販売実績管理、企業統合、およびビジネスフレキシビリティのためのソリューションを提供するサービスを含む。
【0100】
いくつかの実施形態において、プラットフォームサービスは、クラウドインフラストラクチャシステムがＰａａＳプラットフォームを介して提供することができる。ＰａａＳプラットフォームは、ＰａａＳカテゴリに含まれるクラウドサービスを提供するように構成し得る。プラットフォームサービスの例は、限定されないが、共有されている共通アーキテクチャ上の既存のアプリケーションを組織（Oracle等）が統合することを可能にするサービスと、当該プラットフォームが提供する共有サービスを推進する新たなアプリケーションを構築する機能とを含み得る。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理し制御することができる。顧客は、顧客が別々のライセンスおよびサポートを購入しなくても、クラウドインフラストラクチャシステムが提供するＰａａＳサービスを得ることが可能である。プラットフォームサービスの例は、限定されないが、Oracle Java Cloud Service（ＪＣＳ
）、Oracle Database Cloud Service（ＤＢＣＳ）その他を含む。
）、Oracle Database Cloud Service（ＤＢＣＳ）その他を含む。
【0101】
ＰａａＳプラットフォームが提供するサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態において、クラウドインフラストラクチャシステムが提供するプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばOracle Fusion Middlewareサービス）、およびＪａｖａクラウドサービスを含み得る。一実施形態において、データベースクラウドサービスは、組織がデータベースリソースをプールしデータベースクラウドの形態でサービスとしてのデータベース（Database as a Service）
を顧客に提供することを可能にする共有サービスデプロイメントモデルをサポートすることができる。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーシ
ョンを開発しデプロイするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいて顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームを提供してもよい。
を顧客に提供することを可能にする共有サービスデプロイメントモデルをサポートすることができる。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーシ
ョンを開発しデプロイするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいて顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームを提供してもよい。
【0102】
さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおいてＩａａＳプラットフォームが提供してもよい。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームが提供するサービスを利用する顧客のためのストレージ、ネットワーク、および他の基本的なコンピューティングリソース等の、基礎となるコンピューティングリソースの管理および制御を容易にする。
【0103】
特定の実施形態において、クラウドインフラストラクチャシステム２３０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために用いられるリソースを提供するためのインフラストラクチャリソース２３３０を含み得る。一実施形態において、インフラストラクチャリソース２３３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームが提供するサービスを実行するためのサーバ、ストレージ、およびネットワーキングリソース等のハードウェアの、予め統合し最適化した組み合わせを含み得る。
【0104】
いくつかの実施形態において、クラウドインフラストラクチャシステム２３０２におけるリソースは、複数のユーザによって共有され要求ごとに動的に再割り当てされてもよい。加えて、リソースは、異なるタイムゾーンのユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム２３０２は、第１のタイムゾーンの第１組のユーザが指定された時間数だけクラウドインフラストラクチャシステムのリソースを利用することを可能にし、それから、異なるタイムゾーンにいる別の１組のユーザに対して同じリソースを再割り当てすることにより、リソースの利用を最大化することができる。
【0105】
特定の実施形態において、クラウドインフラストラクチャシステム２３０２の異なるコンポーネントまたはモジュールによって共有され、クラウドインフラストラクチャシステム２３０２が提供するサービスによって共有される、複数の内部共有サービス２３３２を提供することができる。これらの内部共有サービスは、限定されないが、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャーサービス、ウィルススキャンおよびホワイトリストサービス、高可用性、バックアップおよびリカバリサービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得る。
【0106】
特定の実施形態において、クラウドインフラストラクチャシステム２３０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえばＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供し得る。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム２３０２が受けた顧客のサブスクリプションをプロビジョニング、管理、および追跡する機能を含み得る。
【0107】
一実施形態において、図面に示されるように、クラウド管理機能は、オーダー管理モジュール２３２０、オーダーオーケストレーションモジュール２３２２、オーダープロビジョニングモジュール２３２４、オーダー管理およびモニタリングモジュール２３２６、ならびにアイデンティティ管理モジュール２３２８等の、１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他任意の適切な構成および／または組み合わせであってもよい、１つ以上のコンピュータおよび／またはサーバを含み得る、または、これらを用いて提供し得る。
【0108】
具体例としての動作２３３４において、クライアントデバイス２３０４、２３０６または２３０８等のクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム２３０２が提供する１つ以上のサービスを要求すること、および、クラウドインフラストラクチャシステム２３０２が提示する１つ以上のサービスのサブスクリプションをオーダーすることにより、クラウドインフラストラクチャシステム２３０２とやり取りしてもよい。特定の実施形態において、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ ２３１２、クラウドＵＩ ２３１４および／またはクラウドＵＩ ２３１６にアクセスしこれらのＵＩを介してサブスクリプションオーダーを行ってもよい。顧客がオーダーを行ったことに応じてクラウドインフラストラクチャシステム２３０２が受けるオーダー情報は、顧客を特定する情報と、クラウドインフラストラクチャシステム２３０２が提供する、顧客がサブスクライブする予定の１つ以上のサービスとを含み得る。
【0109】
顧客がオーダーを行った後に、オーダー情報は、クラウドＵＩ ２３１２、２３１４および／または２３１６を介して受信される。
【0110】
動作２３３６において、オーダーはオーダーデータベース２３１８に格納される。オーダーデータベース２３１８は、クラウドインフラストラクチャシステム２３０２によって運営され他のシステム要素とともに運営されるいくつかのデータベースのうちの１つであってもよい。
【0111】
動作２３３８において、オーダー情報はオーダー管理モジュール２３２０に転送されてもよい。いくつかの例において、オーダー管理モジュール２３２０は、オーダーを確認し確認後にオーダーを記入する等の、オーダーに関連する課金および会計機能を行うように構成されてもよい。
【0112】
動作２３４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール２３２２に伝えられる。オーダーオーケストレーションモジュール２３２２は、オーダー情報を利用することにより、顧客によって行われたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするように構成されてもよい。いくつかの例において、オーダーオーケストレーションモジュール２３２２は、リソースのプロビジョニングをオーケストレーションすることにより、オーダープロビジョニングモジュール２３２４のサービスを使用するサブスクライブされたサービスを、サポートしてもよい。
【0113】
特定の実施形態において、オーダーオーケストレーションモジュール２３２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用することにより、オーダーがプロビジョニングに進むべきか否かを判断する。動作２３４２において、新規サブスクリプションのオーダーを受けると、オーダーオーケストレーションモジュール２３２２は、サブスクリプションオーダーを遂行するのに必要なリソースを割り当てて構成することを求める要求を、オーダープロビジョニングモジュール２３２４に送る。オーダープロビジョニングモジュール２３２４は、顧客がオーダーしたサービスのためのリソースの割当を可能にする。オーダープロビジョニングモジュール２３２４は、クラウドインフラストラクチャシステム２３０２が提供するクラウドサービスと、要求されたサービスを提供するためのリソースのプロビジョニングに使用される物理実装層との間の抽象化レベルを提供する。このようにして、オーダーオーケストレーションモジュール２３２２を、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または、予めプロビジョニングされており要求後に割り当て／アサインされるか否か等の、実装の詳細から切り離すことができる。
【0114】
動作２３４４において、サービスおよびリソースがプロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム２３０２のオーダープロビジョニングモジュール２３２４によってクライアントデバイス２３０４、２３０６および／または２３０８の顧客に送信されてもよい。
【0115】
動作２３４６において、顧客のサブスクリプションオーダーは、オーダー管理およびモニタリングモジュール２３２６によって管理および追跡されてもよい。いくつかの例において、オーダー管理およびモニタリングモジュール２３２６は、ストレージ使用量、転送データ量、ユーザ数、ならびにシステムアップタイムおよびシステムダウンタイムの量等の、サブスクリプションオーダーにおけるサービスの使用統計を収集するように構成されてもよい。
【0116】
特定の実施形態において、クラウドインフラストラクチャシステム２３０２はアイデンティティ管理モジュール２３２８を含み得る。アイデンティティ管理モジュール２３２８は、クラウドインフラストラクチャシステム２３０２におけるアクセス管理および認可サービス等のアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態において、アイデンティティ管理モジュール２３２８は、クラウドインフラストラクチャシステム２３０２が提供するサービスの利用を所望する顧客に関する情報を管理してもよい。そのような情報は、このような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に関してこれらの顧客が実行を認可されるアクションを記述する情報とを含み得る。アイデンティティ管理モジュール２３２８は、各顧客に関し、かつ、誰が如何にしてこの記述情報にアクセスし修正することができるかに関する記述情報の管理も含み得る。
【0117】
図２４は、本発明の各種実施形態を実現し得る具体例としてのコンピュータシステム２４００を示す。システム２４００を用いることにより、上記コンピュータシステムのうちのいずれかを実現することができる。図面に示されるように、コンピュータシステム２４００は、バスサブシステム２４０２を介して複数の周辺サブシステムと通信する処理ユニット２４０４を含む。これらの周辺サブシステムは、処理加速ユニット２４０６と、入出力サブシステム２４０８と、記憶サブシステム２４１８と、通信サブシステム２４２４とを含み得る。記憶サブシステム２４１８は、有形のコンピュータ読取可能記憶媒体２４２２とシステムメモリ２４１０とを含み得る。
【0118】
バスサブシステム２４０２は、コンピュータシステム２４００の各種コンポーネントおよびサブシステムを目的に合わせて互いに通信させるためのメカニズムを提供する。バスサブシステム２４０２は１つのバスとして概略的に示されているが、バスサブシステムの代替実施形態は複数のバスを利用し得る。バスサブシステム２４０２は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、Industry Standard Architecture（ＩＳＡ）バス、Micro Channel Architecture（ＭＣＡ）バス、Enhanced ISA（ＥＩＳＡ）バス、Video Electronics Standards Association（ＶＥＳＡ）ローカルバス、および、Ｉ
ＥＥＥ Ｐ１３８６．１規格に準拠して製造されたMezzanineバスとして実装することが
できるPeripheral Component Interconnect（ＰＣＩ）バスを含み得る。
ＥＥＥ Ｐ１３８６．１規格に準拠して製造されたMezzanineバスとして実装することが
できるPeripheral Component Interconnect（ＰＣＩ）バスを含み得る。
【0119】
１つ以上の集積回路（たとえば従来のマイクロプロセッサまたはマイクロコントローラ）として実現することができる処理ユニット２４０４は、コンピュータシステム２４００の動作を制御する。１つ以上のプロセッサが処理ユニット２４０４に含まれていてもよい。これらのプロセッサはシングルコアまたはマルチコアプロセッサを含み得る。特定の実
施形態において、処理ユニット２４０４は、１つ以上の独立した処理ユニット２４３２および／または２４３４として、各処理ユニットに含まれるシングルまたはマルチコアプロセッサとともに実現されてもよい。他の実施形態において、処理ユニット２４０４はまた、２つのデュアルコアプロセッサを１つのチップに統合することによって形成されるクアッドコア処理ユニットとして実現されてもよい。
施形態において、処理ユニット２４０４は、１つ以上の独立した処理ユニット２４３２および／または２４３４として、各処理ユニットに含まれるシングルまたはマルチコアプロセッサとともに実現されてもよい。他の実施形態において、処理ユニット２４０４はまた、２つのデュアルコアプロセッサを１つのチップに統合することによって形成されるクアッドコア処理ユニットとして実現されてもよい。
【0120】
各種実施形態において、処理ユニット２４０４は、プログラムコードに応じてさまざまなプログラムを実行することができ、かつ、同時に実行している複数のプログラムまたはプロセスを管理することができる。ある所定の時点で、実行すべきプログラムコードのうちの一部またはすべてが、プロセッサ２４０４および／または記憶サブシステム２４１８にあってもよい。適切なプログラミングを通して、プロセッサ２４０４は上記各種機能を提供することができる。コンピュータシステム２４００はさらに、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／またはその他同様のものを含むことができる、処理加速ユニット２４０６を含み得る。
【0121】
入出力サブシステム２４０８は、ユーザインターフェイス入力デバイスと、ユーザインターフェイス出力デバイスとを含み得る。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボール等のポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付きの音声入力デバイス、マイク、およびその他のタイプの入力デバイスを含み得る。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャーおよび発話コマンドを使用するナチュラルユーザインターフェイスを通してユーザが入力デバイスを制御し入力デバイスとやり取りすることを可能にする、Microsoft Xbox（登録商標）３６０ゲームコントローラ等のMicrosoft Kinect（登録商標）モーションセンサのような、モーション検知および／またはジェスチャー認識デバイスを含み得る。ユーザインターフェイス入力デバイスはまた、ユーザの目の活動（たとえば写真撮影中および／またはメニュー選択中の「まばたき」）を検出し目のジェスチャーを入力デバイス（たとえばGoogle Glass（登録商標）)への入力
として変換する、Google Glass（登録商標）まばたき検出器等のアイジェスチャー認識デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを通して音声認識システム（たとえばSiri（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識検知デバイスを含み得る。
として変換する、Google Glass（登録商標）まばたき検出器等のアイジェスチャー認識デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを通して音声認識システム（たとえばSiri（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識検知デバイスを含み得る。
【0122】
ユーザインターフェイス入力デバイスはまた、限定されないが、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカ等のオーディオ／ビジュアルデバイス、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレイヤー、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダー３Ｄスキャナ、３Ｄプリンタ、レーザ測距装置、および視線追跡デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン断層撮影装置、医療用超音波検査装置等の医療用撮像入力デバイスを含み得る。ユーザインターフェイス入力デバイスはまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などのような音声入力装置を含み得る。
【0123】
ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、表示灯、または音声出力装置等の非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを用いるもの等のフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般的に、「出力デバイス」という用語を使用する場合は、コンピュータシステム２４００からユーザまたは他のコンピュータに情報を出力するための可能なすべてのタイプの
デバイスおよびメカニズムを含むことを意図している。たとえば、ユーザインターフェイス出力デバイスは、限定されないが、モニタ、プリンタ、スピーカ、ヘッドホン、カーナビゲーションシステム、プロッタ、音声出力デバイス、およびモデム等の、テキスト、図形、およびオーディオ／ビデオ情報を視覚的に伝えるさまざまなディスプレイデバイスを含み得る。
デバイスおよびメカニズムを含むことを意図している。たとえば、ユーザインターフェイス出力デバイスは、限定されないが、モニタ、プリンタ、スピーカ、ヘッドホン、カーナビゲーションシステム、プロッタ、音声出力デバイス、およびモデム等の、テキスト、図形、およびオーディオ／ビデオ情報を視覚的に伝えるさまざまなディスプレイデバイスを含み得る。
【0124】
コンピュータシステム２４００は、現在はシステムメモリ２４１０内にあるものとして示されているソフトウェア要素を含むストレージサブシステム２４１８を含み得る。システムメモリ２４１０は、処理ユニット２４０４上にローディング可能であり処理ユニット上で実行可能なプログラム命令と、これらのプログラムの実行中に生成されたデータとを格納することができる。
【0125】
コンピュータシステム２４００の構成および種類に応じて、システムメモリ２４１０は、揮発性（たとえばランダムアクセスメモリ（ＲＡＭ））であってもよく、および／または不揮発性（たとえば読出専用メモリ（ＲＯＭ）、フラッシュメモリなど）であってもよい。典型的に、ＲＡＭは、処理ユニット２４０４が直ちにアクセス可能でありおよび／または現在操作し実行している、データおよび／またはプログラムモジュールを含む。いくつかの実装例において、システムメモリ２４１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の複数の異なる種類のメモリを含み得る。いくつかの実装例において、たとえば起動中のコンピュータシステム２４００内の要素間の情報の転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、典型的にはＲＯＭに格納することができる。例として、限定されないが、システムメモリ２４１０はまた、クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含み得るアプリケーションプログラム２４１２と、プログラムデータ２４１４と、オペレーティングシステム２４１６とを示している。例として、オペレーティングシステム２４１６は、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステム、市
場で入手可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステム（限定されないが多様なGNU/Linux（登録商標）オペレーティングシステム、Google Chrome（登録商標）OSなどを含む）、および／またはiOS、Windows（登録商標）Phone、Android（登録商標） OS、BlackBerry（登録商標） 10 OS、およびPalm（登録商標） OSオペレーティングシステム等のモバイルオペレーティングシステムを含み得る。
場で入手可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステム（限定されないが多様なGNU/Linux（登録商標）オペレーティングシステム、Google Chrome（登録商標）OSなどを含む）、および／またはiOS、Windows（登録商標）Phone、Android（登録商標） OS、BlackBerry（登録商標） 10 OS、およびPalm（登録商標） OSオペレーティングシステム等のモバイルオペレーティングシステムを含み得る。
【0126】
ストレージサブシステム２４１８はまた、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能記憶媒体を提供することができる。プロセッサによって実行されると上記機能を実行するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム２４１８に格納することができる。これらのソフトウェアモジュールまたは命令は、処理ユニット２４０４によって実行されてもよい。ストレージサブシステムｙ２４１８はまた、本発明に従い使用されるデータを格納するためのリポジトリを提供することができる。
【0127】
ストレージサブシステム２４１８はまた、コンピュータ読取可能記憶媒体２４２２にさらに接続することが可能なコンピュータ読取可能記憶媒体リーダー２４２０を含み得る。システムメモリ２４１０とともに、また、任意でシステムメモリ２４１０と組み合わされて、コンピュータ読取可能記憶媒体２４２２は、コンピュータ読取可能情報を一時的におよび／またはより恒久的に含む、格納する、送信する、および取り出すための、リモート、ローカル、固定、および／またはリムーバブル記憶装置プラス記憶媒体を包括的に表すことができる。
【0128】
コードまたはコードの一部を含むコンピュータ読取可能記憶媒体２４２２はまた、限定されないが、情報の記憶および／または送信のための任意の方法または技術で実現される、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体等の、記憶媒体および通信媒体を含む、当該技術において周知のまたは使用されている適切な任意の媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的に消去可能プログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリまたはその他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）、もしくはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくはその他の磁気記憶装置、または、他の有形のコンピュータ読取可能媒体等の、有形のコンピュータ読取可能記憶媒体を含み得る。これはまた、所望の情報を送信するために使用することができコンピューティングシステム２４００がアクセスすることができる、データ信号、データ送信、またはその他任意の媒体等の、非有形コンピュータ読取可能媒体を含み得る。
【0129】
例として、コンピュータ読取可能記憶媒体２４２２は、非リムーバブル不揮発性磁気媒体からの読取およびこの媒体への書込を行うハードディスクドライブ、リムーバブル不揮発性磁気ディスクからの読取およびこのディスクへの書込を行う磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、Blu-Ray（登録商標）ディスク、またはその他の光学
媒体等のリムーバブル不揮発性光ディスクからの読取およびこのディスクへの書込を行う光ディスクドライブを含み得る。コンピュータ読取可能記憶媒体２４２２は、限定されないが、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得る。コンピュータ読取可能記憶媒体２４２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどのような、不揮発性メモリベースのソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ等の揮発性メモリベースのＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、ならびにＤＲＡＭおよびフラッシュメモリベースのＳＳＤの組み合わせを用いるハイブリッドＳＳＤを、含み得る。ディスクドライブおよびこれらに対応付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、およびコンピュータシステム２４００のためのその他のデータの不揮発性ストレージを提供することができる。
媒体等のリムーバブル不揮発性光ディスクからの読取およびこのディスクへの書込を行う光ディスクドライブを含み得る。コンピュータ読取可能記憶媒体２４２２は、限定されないが、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得る。コンピュータ読取可能記憶媒体２４２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどのような、不揮発性メモリベースのソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ等の揮発性メモリベースのＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、ならびにＤＲＡＭおよびフラッシュメモリベースのＳＳＤの組み合わせを用いるハイブリッドＳＳＤを、含み得る。ディスクドライブおよびこれらに対応付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、およびコンピュータシステム２４００のためのその他のデータの不揮発性ストレージを提供することができる。
【0130】
通信サブシステム２４２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム２４２４は、他のシステムからデータを受信し、コンピュータシステム２４００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム２４２４は、コンピュータシステム２４００がインターネットを介して１つ以上のデバイスに接続することを可能にする。いくつかの実施形態において、通信サブシステム２４２４は、（たとえば携帯電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（enhanced data rates for global evolution）等の高度データネットワーク技術、ＷｉＦｉ（登録商標）（ＩＥＥＥ ８０２．１１系規格、または他の移動通信技術、またはそれらの任意の組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバーコンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、および／またはその他のコンポーネントを含み得る。いくつかの実施形態において、通信サブシステム２４２４は、無線インターフェイスに加えてまたはその代わりに、有線ネットワークコネクティビティ（たとえばイーサネット（登録商標））を提供することができる。
【0131】
いくつかの実施形態において、通信サブシステム２４２４は、コンピュータシステム２４００を使用し得る１人以上のユーザの代わりに、構造化および／または非構造化データフィード２４２６、イベントストリーム２４２８、イベントアップデート２４３０などの
形態の入力通信を受けることもできる。
形態の入力通信を受けることもできる。
【0132】
例として、通信サブシステム２４２４は、Twitter（登録商標）フィード、Facebook（
登録商標）アップデート、Rich Site Summary（ＲＳＳ）フィード等のウェブフィード、
および／または１つ以上の第３者情報源からのリアルタイムアップデート等の、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード２４２６をリアルタイムで受信するように構成されてもよい。
登録商標）アップデート、Rich Site Summary（ＲＳＳ）フィード等のウェブフィード、
および／または１つ以上の第３者情報源からのリアルタイムアップデート等の、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード２４２６をリアルタイムで受信するように構成されてもよい。
【0133】
加えて、通信サブシステム２４２４は、明確な終わりがない本質的に連続しているまたは無限である可能性があるリアルタイムイベントのイベントストリーム２４２８および／またはイベントアップデート２４３０を含み得る、連続データストリームの形態のデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含み得る。
【0134】
通信サブシステム２４２４はまた、構造化および／または非構造化データフィード２４２６、イベントストリーム２４２８、イベントアップデート２４３０などを、コンピュータシステム２４００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。
【0135】
コンピュータシステム２４００は、ハンドヘルドポータブルデバイス（たとえばiPhone（登録商標）携帯電話、iPad（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他任意のデータ処理システムを含む、さまざまなタイプのうちの１つであってもよい。
【0136】
コンピュータおよびネットワークには常に変化しているという性質があるので、図面に示されるコンピュータシステム２４００の説明は、具体的な一例を意図しているにすぎない。図面に示されるシステムよりも多くのまたは少ないコンポーネントを有するその他多数の構成が可能である。たとえば、カスタマイズされたハードウェアが使用されてもよく、および／または特定の要素がハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実現されてもよい。さらに、ネットワーク入出力デバイスのようなその他のコンピューティングデバイスに対する接続を用いてもよい。本明細書で提供される開示および教示に基づいて、当業者は、各種実施形態を実現するためのその他のやり方および／または方法を理解するであろう。
【0137】
上述の記載では、説明のために、本発明の各種実施形態の十分な理解が得られるよう、数多くの具体的な詳細を述べている。しかしながら、当業者には、本発明の実施形態はこれらの具体的な詳細のうちの一部がなくても実施し得ることが明らかであろう。その他の例では、周知の構造およびデバイスはブロック図の形態で示されている。
【0138】
上述の記載は、具体例としての実施形態を提供しているだけであって、本開示の範囲、利用可能性、または構成を限定することを意図しているのではない。むしろ、具体例としての実施形態の上述の記載は、具体例としての実施形態を実現することを可能にする説明を当業者に提供するであろう。以下の請求項に記載の本発明の精神および範囲から逸脱することなく、要素の機能および構成に各種変更を加え得ることが理解されるはずである。
【0139】
上述の記載において、具体的な詳細は、実施形態の十分な理解を得るために提供されている。しかしながら、当業者は、実施形態はこれらの具体的な詳細がなくても実現し得る
ことを理解するであろう。たとえば、回路、システム、ネットワーク、プロセス、およびその他のコンポーネントは、実施形態を不必要な詳細で不明瞭にすることがないよう、ブロック図の形態のコンポーネントとして示されている場合がある。その他の例において、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態を不明瞭にすることを避けるために不必要な詳細なしで示されている場合がある。
ことを理解するであろう。たとえば、回路、システム、ネットワーク、プロセス、およびその他のコンポーネントは、実施形態を不必要な詳細で不明瞭にすることがないよう、ブロック図の形態のコンポーネントとして示されている場合がある。その他の例において、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態を不明瞭にすることを避けるために不必要な詳細なしで示されている場合がある。
【0140】
また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして記載されている場合があることが注目される。フローチャートは動作を逐次プロセスとして説明している場合があるが、動作のうちの多くは並列または同時に実行することができる。加えて、動作の順序は構成し直してもよい。プロセスは、その動作が完了すると終了するが、図面に含まれていない追加のステップを有する可能性がある。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応する場合、その終了は、この関数が呼び出し側関数またはメイン関数に戻ることに相当し得る。
【0141】
「コンピュータ読取可能媒体」という用語は、携帯型または固定記憶装置、光記憶装置、無線チャネル、ならびに、命令および／またはデータを格納する、含む、または保持することが可能なその他の各種媒体を含むが、これらに限定される訳ではない。コードセグメントまたはマシン実行可能命令は、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または、命令、データ構造、もしくはプログラムステートメントの任意の組み合わせを表し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリコンテンツを送ることおよび／または受けることにより、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む任意の適切な手段を介して、送る、転送する、または送信することができる。
【0142】
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはその任意の組み合わせによって実現することができる。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実現するとき、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、マシン読取可能媒体に格納されていてもよい。プロセッサ（複数のプロセッサ）が必要なタスクを実行してもよい。
【0143】
上述の明細書では、本発明の局面を、その具体的な実施形態を参照しながら説明しているが、本発明がこれらの実施形態に限定される訳ではないことを当業者は認識するであろう。上記発明の各種特徴および局面は、個別に使用されてもよく、またはともに使用されてもよい。さらに、実施形態は、本明細書のより広い精神および範囲から逸脱することなく、本明細書に記載の環境およびアプリケーションを超える、任意の数の環境およびアプリケーションで利用することができる。したがって、本明細書および図面は、限定的なものではなく例示的なものであるとみなされねばならない。
【0144】
加えて、説明のために、方法は特定の順序で記載されている。代替実施形態においてこれらの方法は記載されている順序と異なる順序で実行され得ることが理解されるはずである。上記方法は、ハードウェアコンポーネントによって実行されてもよく、またはマシン実行可能命令のシーケンスで実施されてもよいことも、理解されるはずである。マシン実行可能命令は、当該命令でプログラミングされた汎用もしくは専用プロセッサまたは論理回路のようなマシンに当該方法を実行させるために使用することができる。これらのマシン実行可能命令は、ＣＤ－ＲＯＭもしくはその他のタイプの光ディスク、フロッピー（登録商標）ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード
、フラッシュメモリ、または、電子命令を格納するのに適したその他のタイプのマシン読取可能媒体等の、１つ以上のマシン読取可能媒体に、格納されてもよい。これに代えて、当該方法はハードウェアとソフトウェアとの組み合わせによって実行されてもよい。
、フラッシュメモリ、または、電子命令を格納するのに適したその他のタイプのマシン読取可能媒体等の、１つ以上のマシン読取可能媒体に、格納されてもよい。これに代えて、当該方法はハードウェアとソフトウェアとの組み合わせによって実行されてもよい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6A】
【図6B】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15A】
【図15B】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【手続補正書】
【提出日】2022-12-14
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
コンテナ環境におけるサービスのデプロイメントおよび動作をカスタマイズする方法であって、前記方法は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響すると判断するステップと、
前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップとを含む、方法。
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップと、
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響すると判断するステップと、
前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップとを含む、方法。
【請求項2】
前記プロパティは、前記ＡＰＩレジストリが実行するコードを含む、請求項１に記載の方法。
【請求項3】
前記プロパティは、実行する予め定められたプロセスを選択するために前記ＡＰＩレジストリが使用するフラグを含む、請求項１または２に記載の方法。
【請求項4】
前記ＡＰＩレジストリが、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響すると判断するステップは、前記サービスは高可用性を有するように前記コンテナ環境にデプロイされねばならないことを前記プロパティが示していると判断するステップを含む、請求項１から３のいずれか１項に記載の方法。
【請求項5】
前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップは、前記サービスのコンテナ化された複数のインスタンスを前記コンテナ環境にデプロイするステップを含む、請求項４に記載の方法。
【請求項6】
前記コンテナ環境は、コンテナにカプセル化された複数のサービスを含む、請求項１から５のいずれか１項に記載の方法。
【請求項7】
前記ＡＰＩレジストリは、前記コンテナ環境内のコンテナにカプセル化されたサービスとしてデプロイされる、請求項１から６のいずれか１項に記載の方法。
【請求項8】
プロセッサに動作を実行させるプログラムであって、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することと、
前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することとを含む、プログラム。
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することと、
前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することとを含む、プログラム。
【請求項9】
前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することは、前記サービスはエンドツーエンド暗号化を必要とすることを前記プロパティが示していると判断することを含む、請求項８に記載のプログラム。
【請求項10】
前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することは、サービスコールにおいて前記サービスのエンドポイントに送られる前にデータを暗号化するコードを前記クライアントライブラリに生成することを含む、請求項９に記載のプログラム。
【請求項11】
前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することは、呼び出し側サービスが前記サービスの使用をロギングしなければならないことを前記プロパティが示していると判断することを含む、請求項８から１０のいずれか１項に記載のプログラム。
【請求項12】
前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することは、前記サービスのエンドポイントに対するコールの使用情報をロギングするコードを前記クライアントライブラリに生成することを含む、請求項１１に記載のプログラム。
【請求項13】
前記クライアントライブラリは、前記サービスのエンドポイントに対するダイレクトコールを行うためにＡＰＩ関数を実現するメンバ関数とともにオブジェクトクラスを含む、請求項８から１２のいずれか１項に記載のプログラム。
【請求項14】
前記ＡＰＩレジストリは、
統合開発環境（ＩＤＥ）において開発中のサービスと、
前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項８から１３のいずれか１項に記載のプログラム。
統合開発環境（ＩＤＥ）において開発中のサービスと、
前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項８から１３のいずれか１項に記載のプログラム。
【請求項15】
１つ以上のプロセッサと、
１つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することと、
前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、システム。
１つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することと、
前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、システム。
【請求項16】
前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することは、前記コンテナ環境において前記サービスはオンデマンドでインスタンス化されねばならないことを前記プロパティが示していると判断することを含む、請求項１５に記載のシステム。
【請求項17】
前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することは、前記ＡＰＩレジストリが、前記サービスに対して呼び出し側サービスが要求を送るという表示を受けたことに応じて、前記サービスのコンテナ化されたインスタンスを生成することを含む、請求項１６に記載のシステム。
【請求項18】
前記動作はさらに、
前記ＡＰＩレジストリにおいて、ＡＰＩ定義を受けることを含み、前記ＡＰＩ定義は、
前記コンテナ環境における前記サービスのエンドポイントと、
１つ以上のＡＰＩ関数とを含む、請求項１５から１７のいずれか１項に記載のシステム。
前記ＡＰＩレジストリにおいて、ＡＰＩ定義を受けることを含み、前記ＡＰＩ定義は、
前記コンテナ環境における前記サービスのエンドポイントと、
１つ以上のＡＰＩ関数とを含む、請求項１５から１７のいずれか１項に記載のシステム。
【請求項19】
前記サービスの前記プロパティを前記ＡＰＩ定義とともに受ける、請求項１８に記載のシステム。
【請求項20】
前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することは、前記コンテナ環境において前記サービスがコールされたときに前記サービスはレート制限されねばならないことを前記プロパティが示していると判断することを含む、請求項１５から１９のいずれか１項に記載のシステム。
【手続補正書】
【提出日】2022-12-21
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
コンテナ環境におけるサービスのデプロイメントおよび動作をカスタマイズする方法であって、当該方法は、１つ以上のプロセッサが１つ以上のメモリデバイスに含まれる命令を実行すると、当該１つ以上のプロセッサが実施する方法であって、当該方法は、
前記１つ以上のプロセッサが、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップと、
前記１つ以上のプロセッサが、前記ＡＰＩレジストリを用いて、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響すると判断するステップと、
前記１つ以上のプロセッサが、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップとを含む、方法。
前記１つ以上のプロセッサが、ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けるステップと、
前記１つ以上のプロセッサが、前記ＡＰＩレジストリを用いて、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響すると判断するステップと、
前記１つ以上のプロセッサが、前記サービスのデプロイメントに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップとを含む、方法。
【請求項2】
前記プロパティは、前記ＡＰＩレジストリが実行するコードを含む、請求項１に記載の方法。
【請求項3】
前記プロパティは、実行する予め定められたプロセスを選択するために前記ＡＰＩレジストリが使用するフラグを含む、請求項１または２に記載の方法。
【請求項4】
前記１つ以上のプロセッサが、前記ＡＰＩレジストリを用いて、前記コンテナ環境への前記サービスのデプロイメントに前記サービスの前記プロパティが影響すると判断するステップは、前記１つ以上のプロセッサが、前記サービスは高可用性を有するように前記コンテナ環境にデプロイされねばならないことを前記プロパティが示していると判断するステップを含む、請求項１から３のいずれか１項に記載の方法。
【請求項5】
前記１つ以上のプロセッサが、前記プロパティに少なくとも一部基づいて前記サービスをデプロイするステップは、前記１つ以上のプロセッサが、前記サービスのコンテナ化された複数のインスタンスを前記コンテナ環境にデプロイするステップを含む、請求項４に記載の方法。
【請求項6】
前記コンテナ環境は、コンテナにカプセル化された複数のサービスを含む、請求項１から５のいずれか１項に記載の方法。
【請求項7】
前記ＡＰＩレジストリは、前記コンテナ環境内のコンテナにカプセル化されたサービスとしてデプロイされる、請求項１から６のいずれか１項に記載の方法。
【請求項8】
プロセッサに動作を実行させるプログラムであって、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することと、
前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することとを含む、プログラム。
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することと、
前記クライアントライブラリの生成に前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することとを含む、プログラム。
【請求項9】
前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することは、前記サービスはエンドツーエンド暗号化を必要とすることを前記プロパティが示していると判断することを含む、請求項８に記載のプログラム。
【請求項10】
前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することは、サービスコールにおいて前記サービスのエンドポイントに送られる前にデータを暗号化するコードを前記クライアントライブラリに生成することを含む、請求項９に記載のプログラム。
【請求項11】
前記コンテナ環境内の前記サービスをコールするクライアントライブラリの生成に前記サービスの前記プロパティが影響すると判断することは、呼び出し側サービスが前記サービスの使用をロギングしなければならないことを前記プロパティが示していると判断することを含む、請求項８から１０のいずれか１項に記載のプログラム。
【請求項12】
前記プロパティに少なくとも一部基づいて前記クライアントライブラリを生成することは、前記サービスのエンドポイントに対するコールの使用情報をロギングするコードを前記クライアントライブラリに生成することを含む、請求項１１に記載のプログラム。
【請求項13】
前記クライアントライブラリは、前記サービスのエンドポイントに対するダイレクトコールを行うためにＡＰＩ関数を実現するメンバ関数とともにオブジェクトクラスを含む、請求項８から１２のいずれか１項に記載のプログラム。
【請求項14】
前記ＡＰＩレジストリは、
統合開発環境（ＩＤＥ）において開発中のサービスと、
前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項８から１３のいずれか１項に記載のプログラム。
統合開発環境（ＩＤＥ）において開発中のサービスと、
前記コンテナ環境において既にデプロイされているサービスとが、利用できる、請求項８から１３のいずれか１項に記載のプログラム。
【請求項15】
１つ以上のプロセッサと、
１つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することと、
前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、システム。
１つ以上のメモリデバイスとを備えるシステムであって、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
ＡＰＩレジストリにおいて、コンテナ環境にデプロイされているまたはされることになるコンテナにカプセル化されているまたはされることになるサービスのプロパティを受けることと、
前記ＡＰＩレジストリが、前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することと、
前記サービスに対するコールが如何にして処理されるかに前記プロパティが影響するという判断に応じて、前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することとを含む、システム。
【請求項16】
前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することは、前記コンテナ環境において前記サービスはオンデマンドでインスタンス化されねばならないことを前記プロパティが示していると判断することを含む、請求項１５に記載のシステム。
【請求項17】
前記プロパティに少なくとも一部基づいて前記サービスに対するコールを処理することは、前記ＡＰＩレジストリが、前記サービスに対して呼び出し側サービスが要求を送るという表示を受けたことに応じて、前記サービスのコンテナ化されたインスタンスを生成することを含む、請求項１６に記載のシステム。
【請求項18】
前記動作はさらに、
前記ＡＰＩレジストリにおいて、ＡＰＩ定義を受けることを含み、前記ＡＰＩ定義は、
前記コンテナ環境における前記サービスのエンドポイントと、
１つ以上のＡＰＩ関数とを含む、請求項１５から１７のいずれか１項に記載のシステム。
前記ＡＰＩレジストリにおいて、ＡＰＩ定義を受けることを含み、前記ＡＰＩ定義は、
前記コンテナ環境における前記サービスのエンドポイントと、
１つ以上のＡＰＩ関数とを含む、請求項１５から１７のいずれか１項に記載のシステム。
【請求項19】
前記サービスの前記プロパティを前記ＡＰＩ定義とともに受ける、請求項１８に記載のシステム。
【請求項20】
前記コンテナ環境において前記サービスに対するコールが如何にして処理されるかに前記サービスの前記プロパティが影響すると判断することは、前記コンテナ環境において前記サービスがコールされたときに前記サービスはレート制限されねばならないことを前記プロパティが示していると判断することを含む、請求項１５から１９のいずれか１項に記載のシステム。
【外国語明細書】