特表 2023-540757 マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップのためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-09-26

(54)【発明の名称】マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップのためのシステムおよび方法

(51)【国際特許分類】

   G06F 9/54 20060101AFI20230919BHJP

【ＦＩ】

G06F9/54 B

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023514979

(86)(22)【出願日】2021-09-01

(85)【翻訳文提出日】2023-03-16

(86)【国際出願番号】 US2021048734

(87)【国際公開番号】W WO2022051412

(87)【国際公開日】2022-03-10

(31)【優先権主張番号】63/074,886

(32)【優先日】2020-09-04

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/410,729

(32)【優先日】2021-08-24

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】オテンコ，オレクサンドル

(57)【要約】

ある実施形態に従い、本明細書では、マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップを提供するためのシステムおよび方法について説明する。クラウドコンピューティング環境において、リアクティブプログラミングをパブリッシャおよびサブスクライバとともに使用することにより、さまざまな状態遷移の厳密な調整を提供しながら、実行のスレッドから実行を抽象化することができる。説明するアプローチは、マルチフラットマップ・パブリッシャコンポーネントを用いて、１つ以上のパブリッシャおよびサブスクライバを伴うデータのストリームの処理へのサポートを提供することにより、複数のパブリッシャによって同時に発せられたイベントをフラット化するかそうでなければ組み合わせて、ダウンストリーム・サブスクライバが使用するイベントの単一のストリームにする。

【特許請求の範囲】

【請求項1】

マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップのためのシステムであって、
ソフトウェアアプリケーションで使用するマイクロサービスまたはその他のコンピューティング環境へのアクセスを提供する、１つ以上のプロセッサを含むコンピュータを備え、
前記システムは、１つ以上のパブリッシャおよびサブスクライバを伴うストリームの処理をサポートし、パブリッシャはデータのストリームを公開し、サブスクライバは前記データを消費し、
マルチフラットマップ・パブリッシャコンポーネントが、
アップストリーム・パブリッシャをドレインして、アップストリームによって生成された各アイテムから構築されたパブリッシャからのアイテムのストリームを生成するパブリッシャとして動作し、
前記システムが使用する、アイテムの複数のストリームからなるストリームをフラット化するように動作する、システム。

【請求項2】

前記マルチフラットマップ・パブリッシャは、チケットロックでドレインの呼び出しをガードすることによって、ダウンストリーム・サブスクライバとのやり取りをシリアライズする、請求項１に記載のシステム。

【請求項3】

アップストリーム・パブリッシャがアイテムを生成するたびに、そのアイテムからパブリッシャが構築され、これらのパブリッシャの各々に内部サブスクライバが与えられ、これにより、プリフェッチアイテムが要求されたことが保証される、請求項１に記載のシステム。

【請求項4】

各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納し、
前記読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、
読み取り可能な内部サブスクライバが取り出され、前記内部サブスクライバの内部キューの先頭からアイテムが削除される、請求項１に記載のシステム。

【請求項5】

各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する、請求項１に記載のシステム。

【請求項6】

アップストリーム・パブリッシャがアイテムを生成するたびに、そのアイテムからパブリッシャが構築され、これらのパブリッシャの各々に内部サブスクライバが与えられ、これにより、プリフェッチアイテムが要求されたことが保証され、
各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納し、
前記読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、
読み取り可能な内部サブスクライバが取り出され、前記内部サブスクライバの内部キューの先頭からアイテムが削除され、
各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する、請求項１に記載のシステム。

【請求項7】

前記マイクロサービスまたはその他のコンピューティング環境は、クラウド、データベース、またはその他のシステムもしくはサービスへのアクセスを提供するクラウドコンピューティング環境内に提供される、請求項１に記載のシステム。

【請求項8】

マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップを提供するための方法であって、
１つ以上のプロセッサを含むコンピュータにおいて、ソフトウェアアプリケーションで使用するマイクロサービスまたはその他のコンピューティング環境を提供することと、
１つ以上のパブリッシャおよびサブスクライバを伴うストリームを処理することとを備え、パブリッシャはデータのストリームを公開し、サブスクライバは前記データを消費し、前記方法はさらに、
マルチフラットマップ・パブリッシャコンポーネントを提供することを備え、前記マルチフラットマップ・パブリッシャコンポーネントは、
アップストリーム・パブリッシャをドレインして、アップストリームによって生成された各アイテムから構築されたパブリッシャからのアイテムのストリームを生成するパブリッシャとして動作し、
アイテムの複数のストリームからなるストリームをフラット化するように動作する、方法。

【請求項9】

前記マルチフラットマップ・パブリッシャは、チケットロックでドレインの呼び出しをガードすることによって、ダウンストリーム・サブスクライバとのやり取りをシリアライズする、請求項８に記載の方法。

【請求項10】

アップストリーム・パブリッシャがアイテムを生成するたびに、そのアイテムからパブリッシャが構築され、これらのパブリッシャの各々に内部サブスクライバが与えられ、これにより、プリフェッチアイテムが要求されたことが保証される、請求項８に記載の方法。

【請求項11】

各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納し、
前記読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、
読み取り可能な内部サブスクライバが取り出され、前記内部サブスクライバの内部キューの先頭からアイテムが削除される、請求項８に記載の方法。

【請求項12】

各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する、請求項８に記載の方法。

【請求項13】

アップストリーム・パブリッシャがアイテムを生成するたびに、そのアイテムからパブリッシャが構築され、これらのパブリッシャの各々に内部サブスクライバが与えられ、これにより、プリフェッチアイテムが要求されたことが保証され、
各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納し、
前記読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、
読み取り可能な内部サブスクライバが取り出され、前記内部サブスクライバの内部キューの先頭からアイテムが削除され、
各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する、請求項８に記載の方法。

【請求項14】

前記マイクロサービスまたはその他のコンピューティング環境は、クラウド、データベース、またはその他のシステムもしくはサービスへのアクセスを提供するクラウドコンピューティング環境内に提供される、請求項８に記載の方法。

【請求項15】

命令が格納された非一時的なコンピュータ読取可能記憶媒体であって、前記命令は、１つ以上のコンピュータによって読み取られて実行されると、前記１つ以上のコンピュータにステップを実行させ、前記ステップは、
ソフトウェアアプリケーションで使用するマイクロサービスまたはその他のコンピューティング環境を提供するステップと、
１つ以上のパブリッシャおよびサブスクライバを伴うストリームを処理するステップとを備え、パブリッシャはデータのストリームを公開し、サブスクライバは前記データを消費し、前記ステップはさらに、
マルチフラットマップ・パブリッシャコンポーネントを提供するステップを備え、前記マルチフラットマップ・パブリッシャコンポーネントは、
アップストリーム・パブリッシャをドレインして、アップストリームによって生成された各アイテムから構築されたパブリッシャからのアイテムのストリームを生成するパブリッシャとして動作し、
アイテムの複数のストリームからなるストリームをフラット化するように動作する、非一時的なコンピュータ読取可能記憶媒体。

【請求項16】

前記マルチフラットマップ・パブリッシャは、チケットロックでドレインの呼び出しをガードすることによって、ダウンストリーム・サブスクライバとのやり取りをシリアライズする、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項17】

各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納し、
前記読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、
読み取り可能な内部サブスクライバが取り出され、前記内部サブスクライバの内部キューの先頭からアイテムが削除される、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項18】

各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項19】

アップストリーム・パブリッシャがアイテムを生成するたびに、そのアイテムからパブリッシャが構築され、これらのパブリッシャの各々に内部サブスクライバが与えられ、これにより、プリフェッチアイテムが要求されたことが保証され、
各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納し、
前記読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、
読み取り可能な内部サブスクライバが取り出され、前記内部サブスクライバの内部キューの先頭からアイテムが削除され、
各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項20】

前記マイクロサービスまたはその他のコンピューティング環境は、クラウド、データベース、またはその他のシステムもしくはサービスへのアクセスを提供するクラウドコンピューティング環境内に提供される、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

著作権表示
本特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の特許ファイルまたは記録に掲載されるように特許文献または特許開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。

【0002】

優先権主張
本願は、２０２１年８月２４日に出願され「マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップのためのシステムおよび方法（SYSTEM AND METHOD FOR REACTIVE FLATTENING MAP FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT）」と題された米国特許出願第１７／４１０，７２９号と、２０２０年９月４日に出願され「マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップのためのシステムおよび方法（SYSTEM AND METHOD FOR REACTIVE FLATTENING MAP FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT）」と題された米国仮特許出願第６３／０７４，８８６号とに基づく優先権の利益を請求し、上記出願の各々を、本明細書に引用により援用する。

【0003】

技術分野
本明細書に記載の実施形態は、概して、クラウドコンピューティング、ソフトウェア開発、およびマイクロサービスアーキテクチャに関し、特に、マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップを提供することに向けられる。

【背景技術】

【0004】

背景
マイクロサービス環境は、ソフトウェアアプリケーションを、独立してデプロイ可能でありネットワーク上で互いに通信する、ゆるく結合されたサービスの集合体として提示することができる。マイクロサービスアプローチを使用して、たとえば、クラウドコンピューティング環境においてクラウドサービスとして提供されるソフトウェアアプリケーションを開発することができる。そのような環境では、マイクロサービスを使用して、弾力性を提供するとともに計算リソースを効率的に使用することができる。

【発明の概要】

【0005】

概要
ある実施形態に従い、本明細書では、マイクロサービスまたはその他のコンピューティング環境で使用するリアクティブなフラット化マップを提供するためのシステムおよび方法について説明する。クラウドコンピューティング環境において、リアクティブプログラミングをパブリッシャおよびサブスクライバとともに使用することにより、さまざまな状態遷移の厳密な調整を提供しながら、実行のスレッドから実行を抽象化することができる。説明するアプローチは、マルチフラットマップ（multi-flat-map）パブリッシャコンポーネントを用いて、１つ以上のパブリッシャおよびサブスクライバを伴うデータのストリームの処理へのサポートを提供することにより、複数のパブリッシャによって同時に発せられたイベントをフラット化するかそうでなければ組み合わせて、ダウンストリーム・サブスクライバが使用するイベントの単一のストリームにする。

【図面の簡単な説明】

【0006】

【図1】ある実施形態に係る、ソフトウェア開発フレームワークを提供するマイクロサービス環境の一例を示す図である。

【図2】ある実施形態に係る、Ｈｅｌｉｄｏｎ ＳＥマイクロサービス環境の一例を示す図である。

【図3】ある実施形態に係る、Ｈｅｌｉｄｏｎ ＭＰマイクロサービス環境の一例を示す図である。

【図4】ある実施形態に係る、マイクロサービス環境における通信を示す図である。

【図5】ある実施形態に係る、マイクロサービス環境におけるリアクティブ環境の使用を示す図である。

【図6】ある実施形態に係る、リアクティブ環境の使用をさらに示す図である。

【図7】ある実施形態に係る、リアクティブ環境の使用をさらに示す図である。

【図8】ある実施形態に係る、リアクティブ環境の使用をさらに示す図である。

【図9】ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャを示す図である。

【図10】ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャをさらに示す図である。

【図11】ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャをさらに示す図である。

【図12】ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャをさらに示す図である。

【図13】ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャをさらに示す図である。

【図14】ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャを提供するためのプロセスまたは方法を示す図である。

【発明を実施するための形態】

【0007】

詳細な説明
上述のように、マイクロサービスアーキテクチャは、ソフトウェアアプリケーションを、独立してデプロイ可能でありネットワーク上で互いに通信する、ゆるく結合されたサービスの集合体として提示することができる。マイクロサービスアプローチを使用して、たとえば、クラウドコンピューティング環境においてクラウドサービスとして提供されるソフトウェアアプリケーションを開発することができる。そのような環境では、マイクロサービスを使用して、弾力性を提供するとともに計算リソースを効率的に使用することができる。

【0008】

Ｈｅｌｉｄｏｎなどのソフトウェア開発フレームワークは、マイクロサービスの開発を支援する。たとえば、Ｈｅｌｉｄｏｎは、ＳＥ（Ｓｔａｎｄａｒｄ Ｅｄｉｔｉｏｎ）およびＭＰ（ＭｉｃｒｏＰｒｏｆｉｌｅ）プログラミングモデルまたは環境を提供し、これらの各々は、構成、セキュリティ、またはウェブサーバ機能などの特徴をサポートするソフトウェアライブラリのコレクションを含み、ソフトウェア開発者にマイクロサービスを作成するための土台を提供する。

【0009】

概説すると、Ｈｅｌｉｄｏｎは、ソフトウェア開発者が特定のツーリングまたはデプロイメントモデルに従ってプログラミングする必要性を低減し、アプリケーションサーバを必要としないマイクロサービスの実行を可能にする。Ｈｅｌｉｄｏｎライブラリは、たとえば、Ｄｏｃｋｅｒ、Ｋｕｂｅｒｎｅｔｅｓ、Ｐｒｏｍｅｔｈｅｕｓ、またはＯｐｅｎＴｒａｃｉｎｇなどのその他のソフトウェア開発、デプロイメント、および／または監視ツールとの相互運用が可能である。

【0010】

マイクロサービス環境（Ｈｅｌｉｄｏｎ）
図１は、ある実施形態に係る、ソフトウェア開発フレームワークを提供するマイクロサービス環境の一例を示す。

【0011】

図１に示すように、ある実施形態に従い、Ｈｅｌｉｄｏｎマイクロサービス環境１００は、ＳＥ（Ｓｔａｎｄａｒｄ Ｅｄｉｔｉｏｎ）およびＭＰ（ＭｉｃｒｏＰｒｏｆｉｌｅ）の両方のプログラミングモデルまたは環境を提供する。

【0012】

ある実施形態に従い、Ｈｅｌｉｄｏｎ ＳＥ環境１１０は、たとえば、ウェブアプリケーションを作成するための非同期かつリアクティブなＡＰＩを提供するリアクティブウェブサーバ１１１、キー／値形式の構成プロパティをロードおよび処理して、後でアプリケーションがコンフィグデータを取り出すために使用できるコンフィグオブジェクトにするためのＪａｖａ（登録商標）ＡＰＩを提供する構成ＡＰＩ１１２、ならびに、認証、承認、およびアウトバウンドセキュリティを提供するセキュリティコンポーネント１１３など、さまざまなライブラリ、ＡＰＩ、またはその他のコンポーネントを含むことができ、メトリクス１１４、ヘルスチェック１１５、およびトレース１１６またはその他のコンポーネントも含むことができる。

【0013】

ある実施形態に従い、Ｈｅｌｉｄｏｎ ＭＰ環境１２０は、たとえば、ＪＡＸ－ＲＳ１２２、ＪＳＯＮ－Ｐ１２６、ＣＤＩ１２４、メトリクス１２８、ヘルスチェック１３０、フォールトトレランス１３２、ＭｉｃｒｏＰｒｏｆｉｌｅ構成１３４、およびＪＷＴ認証１３６などのコンポーネントといった、さまざまなライブラリ、ＡＰＩ、またはその他のコンポーネントを含むことができる。ある実施形態に従い、ウェブサーバは、たとえばＮｅｔｔｙなどのノンブロッキングなクライアント／サーバ／ウェブフレームワーク１１８によって提供され得る。マイクロサービス環境は、クラウド、データベース、またはその他のシステムもしくはサービス１４０とのやり取りも可能にすることができる。

【0014】

図２は、ある実施形態に係る、Ｈｅｌｉｄｏｎ ＳＥマイクロサービス環境の一例を示す。

【0015】

図２に示されるように、ある実施形態に従い、Ｈｅｌｉｄｏｎ ＳＥ環境は、ウェブサーバ、セキュリティおよび構成コンポーネントを直接使用する関数型プログラミングスタイルをサポートし、ソフトウェア開発者に透明性および制御を提供し、リアクティブストリーム、および非同期な関数型プログラミングなどのＪａｖａ機能をサポートする。Ｈｅｌｉｄｏｎ ＳＥ環境は、ソフトウェア開発者が軽量のリアクティブマイクロサービスをビルドできるフレームワークを提供する。

【0016】

図３は、ある実施形態に係る、Ｈｅｌｉｄｏｎ ＭＰマイクロサービス環境の一例を示す。

【0017】

図３に示されるように、ある実施形態に従い、Ｈｅｌｉｄｏｎ ＭＰ環境は、Ｈｅｌｉｄｏｎライブラリの上にビルドされたＡＰＩのＭｉｃｒｏＰｒｏｆｉｌｅファミリーを使用することによって、宣言型プログラミングスタイルをサポートする。ＭｉｃｒｏＰｒｏｆｉｌｅ定義（たとえば、Ｅｃｌｉｐｓｅ ＭｉｃｒｏＰｒｏｆｉｌｅプロジェクトによって指定される）を使用して、複数のＭｉｃｒｏＰｒｏｆｉｌｅランタイムにわたってアプリケーションポータビリティをサポートすることができる。

【0018】

ある実施形態に従い、マイクロサービス環境は、ソフトウェアアプリケーションを、独立してデプロイ可能でありネットワーク上で互いに通信する、ゆるく結合されたサービスの集合体として提示することができる。たとえば、Ｈｅｌｉｄｏｎマイクロサービス環境は、リモートプロシージャコール（たとえばｇＲＰＣ）フレームワークまたはコンポーネントの使用をサポートすることができ、これにより、（クライアントおよび／またはサーバ）アプリケーションがマイクロサービス環境内で通信して、接続されたシステムをビルドすることが可能になる。

【0019】

図４は、ある実施形態に係る、マイクロサービス環境における通信を示す。
図４に示され説明される例は、マイクロサービス環境がサポートする１つのタイプの通信の例を示す目的で提供されており、他の実施形態および例に従い、他のタイプの通信がサポートされ得る。

【0020】

図４に示されるように、ある実施形態に従い、リモートプロシージャコール・フレームワークは、リモートで呼び出すことができるサービスおよびメソッドの定義を有効にする。サーバまたはサービスは、クライアントアプリケーションがサーバアプリケーション上のメソッドをローカルオブジェクトであるかのように直接呼び出すことを可能にするクライアントにあるローカルオブジェクト（ｓｔｕｂ）を介して、クライアントからの呼び出しを処理することができる。サーバ／サービスは、メソッドを実装することにより、送信されてくる要求の復号、サービスメソッドの実行、およびサービス応答の符号化を含むクライアント呼び出しに対処する。ローカルオブジェクト（ｓｔｕｂ）は、サービスと同じメソッドを実装し、呼び出しのためのパラメータを適切なプロトコルバッファメッセージタイプにラッピングする。これらのパラメータはその後、要求としてサーバに提供される。

【0021】

ある実施形態に従い、マイクロサービスライブラリは、データへのアクセス、トランザクションの処理、またはそれらのシステムもしくはサービスに関連するその他のオペレーションの実行を目的として、クライアントアプリケーションによるアクセスを可能にして、マイクロサービスと通信できるようにする、または、クラウド、データベース、もしくはその他のシステムやサービスとやり取りできるようにする。

【0022】

リアクティブ環境
従来のメッセージ駆動型環境では、プロデューサは、メッセージが利用可能になるとコンシューマに送信するが、コンシューマがメッセージをリアルタイムで処理できない場合は、受信したメッセージはバッファに格納され、パフォーマンス問題につながる可能性がある。

【0023】

ある実施形態に従い、マイクロサービス環境は、トランザクション処理、非同期メッセージングチャネル、またはリアクティブストリームなどのアクティビティで使用するリアクティブ環境、たとえばリアクティブエンジンまたはリアクティブメッセージングＡＰＩを提供することができる。

【0024】

図５は、ある実施形態に係る、マイクロサービス環境におけるリアクティブ環境の使用を示す。

【0025】

図５に示され説明される例は、マイクロサービス環境がサポートする１つのタイプまたは使用法のリアクティブ環境の例を示す目的で提供されており、他の実施形態および例に従い、他のタイプおよび使用法のリアクティブ環境が提供され得る。

【0026】

図５に示されるように、ある実施形態に従い、リアクティブ環境２００は、クライアントアプリケーション２２０が、マイクロサービス環境内で、パブリッシャおよびサブスクライバとして、サービスとリアクティブに通信することを可能にする。コネクタ２１２を使用して、パブリッシャおよびサブスクライバにリアクティブメッセージングチャネルへのアクセスを提供することができる、または、Ｋａｆｋａ、ＪＭＳ、またはその他のタイプのメッセージング、メッセージキューイング、もしくはストリーム処理環境とのリアクティブメッセージングの使用へのサポートを提供することができる。

【0027】

ある実施形態に従い、リアクティブ環境は、ノンブロッキングなバックプレッシャーで非同期ストリーム処理を可能にする。すなわち、サブスクライバは自身が処理可能なデータ量をパブリッシャに通知し、パブリッシャはサブスクライバの要求に応じて適切な量のデータを送信する。

【0028】

図６は、ある実施形態に係る、リアクティブ環境の使用をさらに示す。
図６に示されるように、ある実施形態に従い、パブリッシャ２３１（本明細書中のいくつかの例ではパブリッシャと呼ばれる）は、そのサブスクライバによってなされた要求に従って、データのプロデューサとして動作する。サブスクライバ２３２（本明細書中のいくつかの例ではサブスクライバと呼ばれる）は、パブリッシャによって生成されたデータのコンシューマとして動作する。サブスクリプション（本明細書中のいくつかの例ではサブスクリプションと呼ばれる）２３４は、サブスクライバがパブリッシャをサブスクライブする関係を定義し、サブスクライバが（パブリッシャに）より多くのデータを要求できるメカニズムを提供する。

【0029】

図７は、ある実施形態に係る、リアクティブ環境の使用をさらに示す。
図７に示されるように、ある実施形態に従い、プロセッサ２４０（本明細書中のいくつかの例ではプロセッサと呼ばれる）は、メッセージ／データ処理段階として、ならびに（サブスクリプション２４２、２４４を介して）サブスクライバおよびパブリッシャの両方として、動作する。

【0030】

図８は、ある実施形態に係る、リアクティブ環境の使用をさらに示す。
図８に示されるように、ある実施形態に従い、サブスクライバがパブリッシャに渡されると、サブスクライバはメソッドonSubscribe(Subscription)の呼び出しを受信するが、データアイテムまたはその他のイベントを直ちに受信し始めることはない。データアイテムがサブスクライバによって受信されるのは、サブスクライバが自身のサブスクリプション内でメソッドrequest(long)を呼び出して、より多くのデータの要求をパブリッシャに信号で知らせたときのみである。

【0031】

ある実施形態に従い、サブスクライバは、次のアイテムで呼び出されるメソッドSubscriber.onNextの呼び出しを通してデータを受信することができ、当該メソッドは、そのサブスクリプションのメソッドrequest(long)で渡されるlong値によって決まる回数（ｎ）だけ呼び出すことができる。メソッドSubscriber.onError()は、ストリームの処理中にエラーが発生したときに呼び出すことができる。メソッドSubscriber.onComplete()は、処理すべきデータがなくなったときに呼び出すことができる。onError()およびonComplete()の両方のイベントが呼び出された場合は、メソッドrequest(long)が再び呼び出されたとしても、パブリッシャから新たなデータは発せられない。

【0032】

効率的なリアクティブなフラット化マップ
ある実施形態に従い、マイクロサービスまたはその他のコンピューティング環境は、リアクティブなフラット化マップの使用を含むことができる。クラウドコンピューティング環境において、リアクティブプログラミングをパブリッシャおよびサブスクライバとともに使用することにより、さまざまな状態遷移の厳密な調整を提供しながら、実行のスレッドから実行を抽象化することができる。説明するアプローチは、マルチフラットマップ・パブリッシャコンポーネントを用いて、１つ以上のパブリッシャおよびサブスクライバを伴うデータのストリームの処理へのサポートを提供することにより、複数のパブリッシャによって同時に発せられたイベントをフラット化するかそうでなければ組み合わせて、ダウンストリーム・サブスクライバが使用するイベントの単一のストリームにする。

【0033】

ある実施形態に従い、説明するアプローチの技術的利点として、たとえば、同時エラーおよびキャンセルが存在する場合に複数の同時パブリッシャからのイベントの複数の全順序がイベントの１つの全順序に結合されることや、高速パスの存在や、同時イベントが複数のキューからなるキューに編成されること、および効率的に進行させるためのプリフェッチや、高速パスに入るための条件や、複数の同時サブスクリプションのリソースおよび状態の管理、ならびに、問題の詳細に基づいて、状態を捕捉するために使用されるキューの種類、などが挙げられる。

【0034】

図９～図１３は、ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャを示す。

【0035】

図９に示されるように、さまざまな実施形態に従い、システムは、マルチフラットマップ・パブリッシャコンポーネントまたはプロセス２５０（本明細書中のいくつかの例ではMultiFlatMapPublisherと呼ばれる）を含むか動作させ、当該コンポーネントまたはプロセス２５０は、アップストリーム・パブリッシャ（パブリッシャ）２５１によって発せられたイベント、たとえばデータアイテムＡ２６０、Ａ′２７０を、複数の内部パブリッシャＡ２６２、Ｂ２７２を介して、同時にフラット化するかそうでなければ組み合わせて、ダウンストリーム・サブスクライバ（サブスクライバ）２５２が使用するイベントの単一のストリームにする。

【0036】

ある実施形態に従い、マルチフラットマップ・パブリッシャは、アップストリーム・パブリッシャを効率的にドレインして、アップストリームによって生成された各アイテムから構築されたアイテムのストリームを生成するための１つ以上の内部パブリッシャとして動作し、かつ、アイテムの「複数のストリームからなるストリーム」をフラット化する（たとえば、［Ａ］→［［Ｂ］］→［Ｂ］のように、データアイテムＡのストリームがＢの複数のストリームからなるストリームに変換され、これがその後Ｂの単一のストリームにフラット化される）ように動作する。マルチフラットマップ・パブリッシャは、各内部パブリッシャが他のパブリッシャから独立して進行することが可能であると仮定しているので、生成されるアイテムの順序は部分的であり、１つの内部パブリッシャによって生成されたアイテムの順序のみが保存される。

【0037】

ある実施形態に従い、２８２で、マルチフラットマップ・パブリッシャは、通過したコンテンダの数をカウントするアトミックカウンタとして動作するチケットロック２５４でドレイン（drain()）の呼び出しをガードすることによって、ダウンストリーム・サブスクライバとのすべてのやり取りをシリアライズする。同時の状態変化は、一般に、最終的にdrain()を呼び出そうとするので、チケットロックを使用することで、すべての同時変化が観察され、適切な信号がダウンストリームに送られることが保証される。状態情報はスレッドセーフでない構造として維持され得るので、drain()を観察することによって正確さの保証およびリソース管理を提供することができる。

【0038】

ある実施形態に従い、２８３で、アップストリーム・パブリッシャがデータアイテムを生成するたびに、そのアイテムから内部パブリッシャが構築される。これらのパブリッシャの各々に内部サブスクライバ２６４、２７４が与えられ、これにより、任意のプリフェッチアイテムが要求されたことが保証される。これは、アップストリームにアイテムを要求するコストを削減するのに役立ち、アイテムを待つレイテンシが削減される。

【0039】

ある実施形態に従い、説明したアプローチを使用して、アップストリーム・パブリッシャ（２５１）は、複数の内部パブリッシャ（２６２、２７２）を順次構築することができる元となるデータアイテムを生成することができる。複数のパブリッシャは、互いに独立してアイテムを生成することができる。独立して動作する複数のパブリッシャによって生成されたアイテムはその後コンパイルされるかフラット化されて、ダウンストリーム・サブスクライバ（２５２）によって観察されるデータアイテムの単一のストリームになる。

【0040】

図１０～図１１に示されるように、ある実施形態に従い、２８４で、内部サブスクライバは、自身が受信するアイテムを、プライベートな内部キュー２６６、２７６に（たとえば、アイテムＢ２６１、Ｂ′２７１のストリームとして）格納し、自身への参照２６８、２７８を、すべての内部サブスクライバと共有される読み取り可能なキュー２５６（本明細書中のいくつかの例ではreadReadyと呼ばれる）に格納する。

【0041】

図１２に示されるように、ある実施形態に従い、２８５で、読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされる。２８６で、読み取り可能な内部サブスクライバを取り出す際に、その内部サブスクライバの内部キューの先頭からアイテムが削除される。

【0042】

図１３に示されるように、ある実施形態に従い、２８７で、同時に、内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が特定の閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する。内部サブスクライバが最終状態に入ると、同じ同時性レベルを維持するために、アップストリーム・パブリッシャ（たとえばアップストリーム・パブリッシャ２５１）に新たなアイテムを要求する。

【0043】

ある実施形態に従い、マルチフラットマップ・パブリッシャがエラーをレイジーに（lazily）信号で知らせるように構成されている場合、ダウンストリーム・サブスクライバにエラー（onError）が信号で知らされるのは、すべての内部サブスクライバが最終状態に入った場合のみである。

【0044】

ある実施形態に従い、マルチフラットマップ・パブリッシャがエラーをイーガーに（eagerly）信号で知らせるように構成されている場合、内部サブスクライバが自身の内部キューに保持している可能性のあるアイテムはすべて破棄され、onError信号が直ちにダウンストリームに伝達される。

【0045】

この挙動により、内部キューのクリーンアップ中に、またはonErrorが伝達された後に、内部キューからのアイテム、または内部パブリッシャからの将来のonNextから受信されるアイテムがダウンストリームに伝達されないことが保証される。それはパブリッシャの仕様に対して順序が狂った信号として観察されることになるからである。

【0046】

ある実施形態に従い、ダウンストリーム・サブスクライバが自身のサブスクリプションのキャンセルを要求すると、マルチフラットマップ・パブリッシャは如何なる信号の生成も最終的に停止し、すべての内部サブスクライバが順番になると如何なる信号の生成も最終的に停止することを要求する。内部サブスクライバによって保持されているリソースは廃棄される。このキャンセル挙動は、イーガーエラー伝達と同様のメカニズムを通して実装することができ、違いはonError信号が伝達されないことである。

【0047】

drain()
ある実施形態に従い、システムは、呼び出し側がチケットロックを取得したと仮定するdrain()関数またはコンポーネントを含むことができる。drain()の主な役割は、同時コンテンダが観察される限り状態を再検査することである。チケットロックに到達したスレッドが１つだけ存在すると仮定するループが構築され、各反復の後に、コンテンダカウンタのアトミック更新が実行されて、最後の反復の開始時に見られたコンテンダの数が減算される。

【0048】

そのような減算の結果が０である場合は、反復中にチケットロックを通過した新たなコンテンダがないという意味であり、最後の反復によって観察されなかった状態変化はいずれも、そのような状態変化の後にdrain()に入ることを試みる義務があるため、将来の反復において観察されることになる。そのような試みをもたらす変化は、cancelPendingの変化、パブリッシャおよびダウンストリーム・サブスクライバのキャンセルのいずれかによって捕捉されたイーガーエラー伝達、readReadyキューの変化、ダウンストリーム・サブスクライバからの要求の変化、またはMultiFlatMapPublisherが休止状態になったこと、である。

【0049】

ある実施形態に従い、状態遷移は以下のように動作する。
onNextの生成の停止要求がなく、readReadyキューが空ではなく、ダウンストリーム・サブスクライバの要求が満たされていない間、最初の読み取り可能な内部サブスクライバの内部キューの先頭からアイテムが取り出され、ダウンストリームに伝達される。cancelPendingが観察されると、onNextの呼び出しは到達不能になる。

【0050】

そのループがcancelPendingのために停止した場合、クリーンアップを行う。すなわち、readReadyキューおよび任意のアクティブな内部サブスクライバによってピン止めされたリソースを解放し、アップストリームが休止していることが分かっていない限り、サブスクリプションのキャンセルを信号で知らせ、任意のアクティブな内部サブスクライバのサブスクリプションのキャンセルを信号で知らせる。これは、新たな内部サブスクライバが作成されるのと同時に起こる可能性があるので、内部サブスクライバは、内部サブスクライバへの参照がクリーンアップルーチンによって観察できること、または、内部サブスクライバ自体がクリーンアップおよびサブスクリプションのキャンセルを実行すること、を保証する必要がある。

【0051】

イーガーエラー通知が要求される場合、またはすべてのパブリッシャが休止してreadReadyキューにアイテムがなくなった場合、ダウンストリーム・サブスクライバは通知を受ける。この後、MultiFlatMapPublisherはキャンセルされたように見えるので、onErrorおよびonCompleteは到達不能になる。これは、内部サブスクライバが新たなアイテムの伝達を試みるのと同時に起こる可能性があるので、クリーンアップルーチンは到達可能なままである。すなわち、そのような同時呼び出しによってreadReadyキューに追加されたアイテムはいずれも、そのような内部サブスクライバによって、またはそのような内部サブスクライバの代わりに、削除される。

【0052】

休止の検出
ある実施形態に従い、システムは、他の信号に対する終了信号の正しい順序を保証するために休止を検出する必要がある。これは、アップストリームを含む任意の信号をまだ伝達する可能性があるパブリッシャの数を追跡することによって達成される。すべてのパブリッシャが最終状態に達し、エラー信号がレイジーに伝達されたときにのみ、onErrorまたはonCompleteが伝達される。最初に、アップストリーム・パブリッシャを考慮するためにawaitingTerminationアトミックカウンタを０から１に進める。次に、アップストリームからonNextを受信するたびにアトミックカウンタをインクリメントし、終了信号をアップストリームまたは任意の内部パブリッシャから受信するとアトミックカウンタをデクリメントする。最終状態を信号で知らせるアップストリームは、（－１）ｍｏｄ２＾３１またはＭＡＸ＿ＶＡＬＵＥを加算することによりカウンタをデクリメントする。必ず正である３２ビット量にそのような数を加算すると、負の数になる。これは、サブスクリプション管理を助け、アップストリームへのアイテムの要求またはキャンセルが無駄であることを検出するのに役立つ。

【0053】

サブスクリプション管理
ある実施形態に従い、MultiFlatMapPublisherは、フラットマップサブスクライバ（FlatMapSubscriber）を使用して状態を管理する。FlatMapSubscriberは一度だけ使用することが許されているので、onSubscribeが一度（一度だけ）正常に呼び出されることが保証される。これは、awaitingTerminationカウンタの値を追跡することによって達成される。すなわち、サブスクリプションが受け付けられるのは、awaitingTerminationアトミックカウンタがゼロであり、０から１にアトミックに進めることができる場合のみである。これが失敗した場合、受け付けられたサブスクリプションが存在し、onSubscribeの呼び出しは失敗する。加えて、awaitingTerminationカウンタは、実際にはその寿命を通して０になることはないので、上記のプロセスにより、１つの（１つだけの）サブスクリプションが受け付けられることが保証される。これを達成するために、アップストリーム・パブリッシャが最終信号を生成すると最上位ビットが１に設定され、したがって、MultiFlatMapPublisherは、awaitingTerminationの値がＭＩＮ＿ＶＡＬＵＥになった後に休止する。awaitingTerminationの負の値が観察されると、アップストリームがその最終状態に達したときの条件が示される。

【0054】

ある実施形態に従い、ダウンストリーム・サブスクリプションは、アップストリーム・サブスクリプションが受け付けられたときに一度（一度だけ）実行される。onSubscribe信号は、アップストリームから受信したアイテムから任意のパブリッシャが生成される前に発生することができないため、他のダウンストリーム信号から相互に除外される。これは、ダウンストリームのonSubscribeが完了した後に実行されるアップストリーム・サブスクリプションに対する要求が呼び出されるまで起こらない。

【0055】

キャンセルおよびエラーの通知
ある実施形態に従い、ダウンストリーム・サブスクライバは、いつでも、かつ同時に、自身のサブスクリプションをキャンセルすることがある。エラーも、同時に、特にダウンストリーム・サブスクライバによって無効な要求がなされたときに、発生することがある。これら２つの条件は同様に追跡され、観察可能な唯一の違いはcanceledフラグが設定されているか否かであり、レイジーエラー通知が構成されている場合は、MultiFlatMapPublisherが休止するまでエラーは観察されない。drain()によって設定されたcanceledが観察されると、MultiFlatMapPublisherの状態はキャンセルされたと見なされ、エラーは発生しても無視される。

【0056】

ある実施形態に従い、キャンセルは、アップストリームに信号が不要になったことを通知するように、すべての内部サブスクライバに信号が不要になったことを通知するように、かつ任意のリソースを解放するように、動作する。

【0057】

ある実施形態に従い、内部サブスクライバに通知できるようにするために、FlatMapSubscriberは、サブスクライバセット内のすべての現在の内部サブスクライバを追跡する。キャンセルはその他のイベントと同時に起こることがあるので、内部サブスクライバは、サブスクライバセット内の自身の存在が観察可能であることを確認する必要がある。すなわち、内部サブスクライバをセットに追加した後にcancelPendingが偽であることが観察された場合、クリーンアップが将来行われることが保証され、そうでなければ、内部サブスクライバは自身のサブスクリプションおよびリソースのクリーンアップを行う必要がある。その結果、内部サブスクライバのonSubscribe()でこのチェックを一度実行すれば十分である。

【0058】

ある実施形態に従い、内部サブスクライバは、最終状態に到達するとサブスクライバセットから自身を削除する。内部サブスクリプションとのやり取りが不要になり、そのようなサブスクライバへの唯一の参照はreadReadyキュー内に見つけることができるからである。事実上、そのようなサブスクライバはキャンセルをまったく観察せず、そのようなサブスクライバが消費したリソースのクリーンアップは、クリーンアップ中にreadReadyキューからすべての参照をドロップすることに相当する。

【0059】

リソース管理
MultiFlatMapPublisherとのやり取りのリアクティブな性質のために、リアクティブな仕様に適合するパブリッシャが存在する場合、制限された量のリソースを保持する必要がある。また、不適合サブスクライバ、またはMultiFlatMapPublisherへの参照を無期限に保持し得る不正形式のパイプラインが存在する場合、リソースをできるだけ短い期間保持する義務もある。これらの課題により、ダウンストリーム・サブスクライバからの要求を追跡し、アップストリームおよび内部パブリッシャが制限された数のアイテムを保持することを保証する必要がある。より多くのアイテムをアップストリームに要求するのは、内部サブスクライバのキューから最後のアイテムが消費された場合のみであり、これにより、maxConcurrency * prefetchitems以下のアイテムがすべての内部サブスクライバによって保持されることが保証される。

【0060】

ある実施形態に従い、システムは、より多くのアイテムをエンキューする前にキャンセルまたはイーガーエラー伝達を観察しなかった同時の内部サブスクライバがある場合は、最終状態に入った後でも、cleanup()が常に到達可能であり続けることを保証することができる。さらに、内部パブリッシャは、直ちにキャンセルを観察する義務はなく、不特定の期間にわたってより多くのアイテムを生成してもよい（内部パブリッシャは、アイテムの生成を最終的に停止することが要求されるだけである）。

【0061】

キュー条件における最後のアイテムの検出
ある実施形態に従い、内部サブスクライバは、readReadyキューが生成する準備ができているアイテムごとに、自身をreadReadyキューに追加する。加えて、内部サブスクライバは、最終状態に達すると、自身をreadReadyキューに一度追加する。drain()ループは、readReadyキューの先頭にあるそのような内部サブスクライバを最終的に観察するが、その内部キューが空であることを観察する。これは、内部サブスクライバから最後のアイテムが消費されたことを示すものとしてdrain()ループによって扱われ、より多くのアイテムがアップストリームに要求されることにより、ちょうど終了したパブリッシャが新たな内部パブリッシャに効果的に置き換えられる。

【0062】

特に、ダウンストリーム・サブスクライバからの要求をチェックする前にreadReadyキューが空であるか否かをチェックする順序により、この条件が観察され、ダウンストリーム・サブスクライバが要求を信号で知らせなくてもアップストリームに対する要求が信号で知らされることが保証される。

【0063】

empty()
ある実施形態に従い、empty()のチェックは、内部キューが空である内部サブスクライバがreadReadyキューの先頭にある限り、readReadyキューの先頭を削除する。そして、readReadyキューの先頭に発見されたそのような内部サブスクライバと同数のアイテムをアップストリームに要求する。加えて、そのようなオペレーションの後、readReadyキューは空である、または、内部キューが空でない内部サブスクライバを先頭に含む。

【0064】

高速パス
ある実施形態に従い、readReadyキューとのやり取りをなくすことによって、たとえば、すべての内部パブリッシャの順次フラット化（たとえば、maxConcurrency＝１）や、調整された同時内部パブリッシャや、いくつかの内部パブリッシャが、帯域外の手段によって確立された何らかの全順序でアイテムを生成するなど、大幅なパフォーマンス向上を得ることができるユースケースがある。

【0065】

これらのケースにおいてダウンストリーム・サブスクライバがパブリッシャよりも高速である場合、または複数のアイテムを同時に消費できる場合、readReadyキューはほとんどの時間、空に見えることがある。この場合、パブリッシャは、最初のアイテムをreadReadyキューにしばしば追加し、すべてのアイテムの部分的な順序においてその後に現れるべきアイテムはすべて消費されている。ダウンストリーム・サブスクライバへのすべての信号の全順序が保存されている限り、readReadyキューを避けて、そのようなアイテムをダウンストリーム・サブスクライバに直接伝達することが可能である。

【0066】

ある実施形態に従い、内部サブスクライバのonNext、onErrorおよびonCompleteはチケットロックの取得を試み（コンテンダカウンタを０から１にアトミックに更新しようとし）、成功すると、drain()と同じ条件を検証する。すなわち、cancelPending、もしくはreadReadyキューが空でない場合、またはダウンストリーム・サブスクライバからの要求が不十分である場合、遅いパスにフォールバックし、内部キューにアイテムをエンキューし、readReadyキューで自身をエンキューし、drain()を呼び出し、そうでなければ、FlatMapSubscriberの状態およびダウンストリームへのシリアライズ信号への排他的アクセスを仮定し、最終的にdrain()に入って他の状態変化が同時に起こったか否かを観察することが安全である。

【0067】

ある実施形態に従い、onErrorおよびonCompleteは、内部キューがreadReadyキューではなく空であるという、より弱い条件を検証することができる。これらの信号は、ダウンストリームへの如何なる信号も生じないので、すでにキューにある任意の読み取り可能な内部サブスクライバの代わりに、信号に関して順序付ける必要はない。

【0068】

読み取り可能なキュー
ある実施形態に従い、readReadyキューおよび内部サブスクライバの内部キューの大部分は、シングルスレッドでアクセスされる。

【0069】

readReadyキューへのput()は、任意の内部サブスクライバによって同時に実行することができる。

【0070】

内部キューへのput()は、内部サブスクライバによって、シングルスレッドでのみ実行することができる。これは、内部パブリッシャが信号で知らせるイベントの全順序によって保証することができる。

【0071】

readReadyキューのpeek()、poll()、empty()、clear()は、チケットロックの所有者によって、シングルスレッドで呼び出される。

【0072】

内部サブスクライバの内部キューのpeek()、poll()、empty()、clear()は、チケットロックの所有者によって、シングルスレッドで呼び出される。

【0073】

ある実施形態に従い、readReadyキューの先頭にサブスクライバが発見されない限り、内部サブスクライバの内部キューのpoll()は到達不能である。内部サブスクライバおよびdrain()が内部キューの先頭および末尾に同時にアクセスしているように見えるが、drain()は、readReady.put()の前に観察され得るようなキューの末尾要素を超えるキューの部分にアクセスしようとはしていない。

【0074】

ある実施形態に従い、put()と同時に内部キューに対してclear()を呼び出すことができ、キャンセルされた時またはイーガーエラー伝達が行われた時にリソースをクリアするために実行される。clear()は、キューの末尾が更新されたことを観察しないかもしれないので、同時のclear()が存在し得ることを内部サブスクライバが観察すると、内部サブスクライバによって実行される追加のメソッドをclearTail()に提供することができる。

【0075】

put()
ある実施形態に従い、put()はConcurrentLinkedQueueのように動作し、readReadyキューに自身を追加する内部サブスクライバによって使用される。

【0076】

poll()、peek()、empty()およびclear()
ある実施形態に従い、これらの関数は、以下が存在しない場合は安全であることが保証される。

【0077】

同時のpoll()およびpeek()。
シリアライズされていないロードおよびストアを使用して先頭を読み取り更新する（不揮発性の読み取りおよび書き込み）。

【0078】

clear()におけるhead.tailを変更すると、同時のput()またはputNotSafe()が存在する場合、tail.vがpoll()、peek()およびclear()には見えなくなることがある。clear()が存在する場合にアイテムを追加する内部サブスクライバは、readReadyを通してサブスクライバに到達できないことがあるため、参照がドロップされることを保証する必要がある。内部サブスクライバへの参照は内部Publisher.subscribeを通ってエスケープし、無期限に到達可能であると想定すべきであるため、依然としてクリーンアップが必要である。readReadyキューにアイテムを追加する内部サブスクライバは、drain()に入り、cancelPendingを観察し、readReady.clear()を再び呼び出して、先頭を更新して参照をドロップする。

【0079】

putNotSafe()
ある実施形態に従い、この関数は、同時のput()および他のputNotSafe()の呼び出しが存在しない場合は安全であることが保証される。シリアライズされていないストアを使用してキューノードを初期化して末尾ポインタを更新する（不揮発性の書き込み）。

【0080】

clearTail()
ある実施形態に従い、キュー内の最後のアイテムへの参照がドロップされることを保証する。これにより、キューノードへの参照は保持され得るが、フットプリントは一定のままである（一定の上限を有する）。

【0081】

図１４は、ある実施形態に係る、マイクロサービスまたはその他のコンピューティング環境で使用するマルチフラットマップ・パブリッシャを提供するためのプロセスまたは方法を示す。

【0082】

図１４に示されるように、さまざまな実施形態に従い、この方法は、ステップ２９０で、１つ以上のプロセッサとメモリとを含むコンピュータにおいて、マイクロサービス環境（マイクロサービスライブラリ）と、マイクロサービス環境に関連して、クライアントアプリケーションとサーバアプリケーションとがマイクロサービス環境内で通信できるように、リアクティブストリームとともに使用できるリアクティブ環境とを提供することを含むことができる。

【0083】

ステップ２９１で、マルチフラットマップ・パブリッシャは、チケットロックでdrain()の呼び出しをガードすることによって、ダウンストリーム・サブスクライバとのやり取りをシリアライズする。

【0084】

ステップ２９２で、アップストリーム・パブリッシャがアイテムを生成するたびに、そのアイテムからパブリッシャが構築され、これらのパブリッシャの各々に内部サブスクライバが与えられ、これにより、プリフェッチアイテムが要求されたことが保証される。

【0085】

ステップ２９３で、各内部サブスクライバは、自身が受信するアイテムを、自身のプライベートな内部キューに格納し、自身への参照を、すべての内部サブスクライバと共有される読み取り可能なキューに格納する。

【0086】

ステップ２９４で、読み取り可能なキューは、ダウンストリーム・サブスクライバからの要求に応答してポーリングされ、読み取り可能な内部サブスクライバが取り出され、その内部サブスクライバの内部キューの先頭からアイテムが削除される。

【0087】

ステップ２９５で、各内部サブスクライバは、自身の内部キューから削除されるアイテムの数を追跡し、その数が閾値を超えると、自身がサブスクライブしている内部パブリッシャにより多くのアイテムを要求する。

【0088】

さまざまな実施形態に従い、本明細書における教示は、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用もしくは専用コンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを使用して好都合に実現され得る。適切なソフトウェアコーディングは、ソフトウェア技術分野の当業者に明らかであるように、本開示の教示に基づいて熟練のプログラマによって容易に準備することができる。

【0089】

いくつかの実施形態において、本明細書における教示は、本教示のプロセスのいずれかを実行するようにコンピュータをプログラムするのに使用することができる命令が格納された非一時的なコンピュータ読取可能記憶媒体（複数可）であるコンピュータプログラム製品を含むことができる。このような記憶媒体の例としては、ハードディスクドライブ、ハードディスク、ハードドライブ、固定ディスク、もしくは他の電気機械的データ記憶装置、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム、または、命令および／もしくはデータの非一時的な格納に適したその他のタイプの記憶媒体もしくはデバイスを挙げることができるが、これらに限定されるものではない。

【0090】

上記の記載は、例示および説明の目的で提供されている。それは、網羅的であるよう意図されたものではなく、開示されている厳密な形態に保護範囲を限定するよう意図されたものでもない。多くの変更例および変形例が当業者に明らかであろう。

【0091】

たとえば、本明細書に記載のシステムおよび方法のさまざまな実施形態は、Ｈｅｌｉｄｏｎマイクロサービス環境での使用を示しているが、さまざまな実施形態は、他のタイプのマイクロサービス環境またはその他のコンピューティング環境で使用することができる。

【0092】

実施形態は、本教示の原理およびそれらの実際の適用を最もよく説明することによって、当業者が、さまざまな実施形態および意図された特定の使用に適したさまざまな変更例を理解することができるように、選択され記載されている。範囲は以下の請求項およびその等価物によって規定されることが意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【国際調査報告】