JP6698806B2 - クラスタ化されたアプリケーションの負荷分散のためのロング・ポーリング - Google Patents

Description

Ｔｗｉｌｉｏ（登録商標）およびＺａｎｇ（登録商標）などのサービスとしての通信プラットフォーム（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ：ＣＰａａＳ）を提供するクラウド・サービスは、現在、企業データ・センタで稼働するアプリケーションによるセキュリティの課題を有している。ＣＰａａＳは、音声、ビデオ、およびメッセージングなどの特徴をアプリケーションに追加するために使用される開発フレームワークである。現在のＣＰａａＳシステムは、ＨＴＴＰ要求を送信して、企業データ・センタにおけるデータにアクセスする。着信ＨＴＴＰ ＰＯＳＴまたはＨＴＴＰ ＧＥＴ要求は、企業データ・センタが取り扱わなければならない。

企業データ・センタは、着信メッセージがセキュリティの問題を引き起こすことがあるという理由で、着信メッセージに神経質である。結果として、企業は、外部のインターネットから通信を開始するアプリケーションの数を最小限にしようとする。システム管理者は、企業への着信要求を嫌い、特に、要求を、クラウド・サービスに向けたアウトバウンド・メッセージに限定したいと望んでいる。システム管理者は、着信トラフィックがファイヤーウォールに穴を作成し、それが悪用され得るという理由で、着信トラフィックに対してネットワークを開放することを望んでいない。

インバウンドＨＴＴＰ問題に対処する１つのやり方が、ウェブソケットを使用することである。ウェブソケットは、企業からのアウトバウンドＨＴＴＰ要求で確立することができる。最初のアウトバウンドＨＴＴＰ要求の後、メッセージは、ウェブソケットをまたいだ両方向でフローすることができる。

いくつかの企業は、ウェブソケットを使用することに神経質である。一定のリバース・プロキシおよびアプリケーション・フレームワークは、ウェブソケットをサポートすることができない。加えて、いくつかの企業は、アプリケーション認識型のリバース・プロキシおよびアプリケーション配信コントローラを有しており、これらは、ＨＴＴＰメッセージとそのコンテンツの深部点検を提供する。メッセージは、開発者が選んだ任意のやり方でフォーマットされ得るので、ウェブソケットは、その能力を無効にしてしまう。それらの理由により、ＨＴＴＰを介したイベント配信のためのユビキタスに利用可能な技術として、ロング・ポーリングをサポートすることが必要である。

ロング・ポーリングは、クライアントがＨＴＴＰ ＧＥＴ要求をサーバに送信し、アプリケーションに返すべきイベントが存在する場合にイベントが即座に送信され、別の要求が送信される、よく理解された方法である。イベントが存在しない場合、返すべきイベントが存在するまで、またはタイムアウトが発生するまで（たとえば、６０秒）、ＨＴＴＰ ＧＥＴ要求はオープンにされたままである。これにより、非同期イベントの印象および特性が得られ、企業データ・センタへのインバウンド要求がないこともまた満たされる。着信メッセージは、もっぱらアウトバウンド要求に応答して送信される。

ロング・ポーリングによる難点は、多数のアプリケーションが提供されているクラスタ化された環境において生じる。現在のソリューションは、クラスタ化された環境におけるロング・ポーリングをサポートしていない。

これらの、および他のニーズは、本開示のさまざまな実施形態および構成によって対処される。複数のロング・ポールＨＴＴＰ ＧＥＴ要求が、複数のクラスタ化されたアプリケーションから受信される。複数のロング・ポールＨＴＴＰ ＧＥＴ要求は、複数のクラスタ化されたアプリケーションのための複数の識別子を含む。複数の識別子に基づいて、複数のイベント・キューが複数のクラスタ化されたアプリケーションのために作成される。複数の通信セッションに基づいて、複数のイベントが複数のイベント・キューに追加される。たとえば、複数の着信コールに基づいて、多数のイベントを複数のイベント・キューに追加することができる。複数のロング・ポールＨＴＴＰ ＧＥＴ要求に対する複数の応答が送信される。複数の応答は、複数のイベントを含む。このプロセスにより、通信セッションを管理している、対応するクラスタ化されたアプリケーションの識別が可能になる。

語句「少なくとも１つ」、「１つまたは複数」、「または」、ならびに「および／または」は、動作において接続的および離接的の両方である、制約のない表現である。たとえば、表現「Ａ、Ｂ、およびＣのうちの少なくとも１つ」、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」、「Ａ、Ｂ、およびＣのうちの１つまたは複数」、「Ａ、Ｂ、またはＣのうちの１つまたは複数」、「Ａ、Ｂ、および／またはＣ」、ならびに「Ａ、Ｂ、またはＣ」のそれぞれは、Ａ単独で、Ｂ単独で、Ｃ単独で、ＡとＢとが一緒に、ＡとＣとが一緒に、ＢとＣとが一緒に、またはＡ、Ｂ、およびＣが一緒であることを意味する。

用語「１つの（ａまたはａｎ）」実体は、その実体の１つまたは複数を指す。したがって、用語「１つの（ａまたはａｎ）」、「１つまたは複数」、および「少なくとも１つ」を、本明細書で交換可能に使用することができる。用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、および「有する（ｈａｖｉｎｇ）」もまた、交換可能に使用することができることに留意されたい。

本明細書で使用されるとき、用語「自動的（ａｕｔｏｍａｔｉｃ）」およびその変形は、プロセスまたは動作が実施されるとき、物質的な人間の入力なしに行われる、通常は連続的または半連続的な任意のプロセスまたは動作を指す。しかしながら、プロセスまたは動作の実施前に入力が受信される場合は、プロセスまたは動作の実施が物質的または非物質的な人間の入力を使用したとしても、プロセスまたは動作は自動的であってよい。人間の入力が、プロセスまたは動作がどのように実施されることになるかに影響を与える場合、そのような入力は、物質的であるとみなされる。プロセスまたは動作の実施を承諾する人間の入力は、「物質的」であるとはみなされない。

本開示の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード、その他を含む）、またはソフトウェアとハードウェアとの態様を組み合わせた実施形態の形式を取ることができ、本明細書ではこれらすべてを概して、「回路」、「モジュール」、または「システム」と呼ぶことがある。１つまたは複数のコンピュータ可読媒体の任意の組合せが利用されてよい。コンピュータ可読媒体は、コンピュータ可読信号媒体であっても、またはコンピュータ可読記憶媒体であってもよい。

コンピュータ可読記憶媒体は、たとえば、電子、磁気、光学、電磁気、赤外線、または半導体のシステム、装置、もしくはデバイス、または上記の任意の好適な組合せであってよいが、これらに限定はされない。コンピュータ可読記憶媒体のより具体的な例（非包括的なリスト）は、１つまたは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光学ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光学記憶デバイス、磁気記憶デバイス、または上記の任意の好適な組合せを含むことになる。本文書のコンテキストにおいて、コンピュータ可読記憶媒体は、命令実行システム、装置、もしくはデバイスによる使用のための、またはそれらに関係したプログラムを、収容する、または記憶することができる任意の有形な媒体であってよい。

コンピュータ可読信号媒体は、たとえば、ベースバンドにおいて、または搬送波の一部として、コンピュータ可読プログラム・コードがその中に具現化された伝搬データ信号を含むことができる。そのような伝搬信号は、電磁気、光学、またはそれらの任意の好適な組合せを含む多様な形態のうちのいずれかを取ることができるが、限定はされない。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではない媒体であって、命令実行システム、装置、もしくはデバイスによる使用のための、またはそれらに関係したプログラムを、通信、伝搬、もしくは移送することができる、任意のコンピュータ可読媒体であってよい。コンピュータ可読媒体上に具現化されたプログラム・コードは、ワイヤレス、ワイヤ線、光学ファイバ・ケーブル、ＲＦ、その他、または上記の任意の好適な組合せを含むがこれらに限定はされない任意の適切な媒体を使用して伝送することができる。

本明細書で使用されるとき、用語「判定する（ｄｅｔｅｒｍｉｎｅ）」、「計算する（ｃａｌｃｕｌａｔｅ）」、および「コンピュータで計算する（ｃｏｍｐｕｔｅ）」、ならびにそれらの変形は、交換可能に使用され、任意のタイプの方法論、プロセス、数学的演算または技法を含む。

本明細書で使用されるとき、用語「手段」は、米国特許法第１１２条（ｆ）および／または第１１２条第６項に従って、その最も広い可能な解釈が与えられるものとする。したがって、用語「手段」を組み込む請求項は、本明細書に記載されるすべての構造、材料、または行為、およびその等価物のすべてを包含するものとする。さらに、構造、材料、または行為およびその等価物は、発明の概要、図面の簡単な説明、詳細な説明、要約、および特許請求の範囲それ自体で説明されたすべてのものを含むものとする。

前述は、本開示のいくつかの態様の理解を提供するための簡略化した概要である。この概要は、本開示およびそのさまざまな実施形態の広範な概説でも、包括的な概説でもない。それは、本開示の重要なまたは不可欠な要素を識別することも、本開示の範囲を明らかにすることも意図せず、しかし本開示の選択された概念を、以下に提示されるより詳細な説明への導入として、簡略化した形式で提示することを意図している。認識されるように、上に記載される、または下で詳細に説明される特徴のうちの１つまたは複数を、単独で、または組み合わせて利用する本開示の他の実施形態が可能である。また、本開示は例示的な実施形態に関して提示されているが、本開示の個々の態様は、別々に特許請求され得ることを認識されたい。

クラスタ化されたアプリケーションのロング・ポーリングのための第１の例証となるシステムのブロック図である。 クラスタ化されたアプリケーションのためのイベント・キューを作成および削除するためのプロセスの流れ図である。 通信セッション識別子に基づいて、イベントをイベント・キューに割り当てるためのプロセスの流れ図である。 クラスタ化されたアプリケーションからのＨＴＴＰロング・ポーリングを取り扱うためのプロセスの流れ図である。 ロング・ポールＨＴＴＰ ＧＥＴ要求ごとに送信されるイベントの数を管理するためのプロセスの流れ図である。 クラウド・サービスとクラスタ化されたアプリケーションとの間をブリッジするためのプロセスの流れ図である。

図１は、クラスタ化されたアプリケーション１２２のロング・ポーリングのための第１の例証となるシステム１００のブロック図である。第１の例証となるシステム１００は、通信エンドポイント１０１Ａ〜１０１Ｎと、ネットワーク１１０と、企業データ・センタ１２０と、クラウド・サービス１３０とを備える。

通信エンドポイント１０１Ａ〜１０１Ｎは、パーソナル・コンピュータ（ＰＣ）、電話、ビデオ・システム、セルラ電話、携帯情報端末（ＰＤＡ）、タブレット・デバイス、ノートブック・デバイス、ウェブ・サーバ、メディア・サーバ、スマートフォン、カンファレンス・ブリッジ、その他などの、ネットワーク１１０上で通信することができる任意の通信エンドポイント・デバイスであってもよいし、または任意の通信エンドポイント・デバイスを含んでもよい。通信エンドポイント１０１Ａ〜１０１Ｎは、そこで通信セッションが終了するデバイスである。通信エンドポイント１０１Ａ〜１０１Ｎは、通信マネジャまたはルータなどの、ネットワーク１１０において通信セッションを促進する、および／または中継するネットワーク要素ではない。図１に示すように、任意の数の通信エンドポイント１０１Ａ〜１０１Ｎを、ネットワーク１１０に接続することができる。

ネットワーク１１０は、インターネット、ワイド・エリア・ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、ボイス・オーバＩＰネットワーク（ＶｏＩＰ）、公衆交換電話ネットワーク（ＰＳＴＮ）、パケット交換ネットワーク、回線交換ネットワーク、セルラ・ネットワーク、これらの組合せ、その他などの、電子通信を送信し、受信することができる任意の通信機器の集まりであってもよいし、または任意の通信機器の集まりを含んでもよい。ネットワーク１１０は、イーサネット、インターネット・プロトコル（ＩＰ）、セッション開始プロトコル（ＳＩＰ）、統合サービス・デジタル・ネットワーク（ＩＳＤＮ）、ハイパー・テキスト・トランスポート・プロトコル（ＨＴＴＰ）、ウェブ・リアルタイム通信（ＷｅｂＲＴＣ）プロトコル、および／または同種のものなどの多様な電子プロトコルを使用することができる。このように、ネットワーク１１０は、パケットおよび／または回線交換通信を介してメッセージを搬送するように構成された電子通信ネットワークである。

企業データ・センタ１２０は、法人、統治機関、パートナーシップ、グループ、協会、組織、人、および／または同種のものなどの任意のエンティティのためのデータ・センタであってもよいし、または任意のエンティティのためのデータ・センタを含んでもよい。企業データ・センタ１２０は、同じエンティティによって、または異なるエンティティによって所有される複数の企業データ・センタ１２０を含むことができる。多数の企業データ・センタ１２０が存在する一実施形態においては、個々のデータ・センタ１２０のための識別子に基づいて、企業データ・センタ１２０を識別することができる。

企業データ・センタ１２０は、ファイヤーウォール１２１と、クラスタ化されたアプリケーション１２２と、１つまたは複数のデータベース１２３とをさらに備える。ファイヤーウォール１２１は、ネットワーク・アドレス・トランスレータ（ＮＡＴ）、プロキシ・サーバ、セッション・ボーダー・コントローラ、および／または同種のものなどの、クラスタ化されたアプリケーション１２２／データベース１２３への認可されないアクセスを防ぐために使用され得る任意のハードウェア／ソフトウェアであってもよいし、または任意のハードウェア／ソフトウェアを含んでもよい。

クラスタ化されたアプリケーション１２２は、クラウド・サービス１３０によって提供される通信セッション／通信サービスのために、サービス／情報を提供するために使用され得るアプリケーションのグループである。クラスタ化されたアプリケーション１２２は、データベース・サービス、双方向音声応答（ＩＶＲ）サービス、エージェント識別サービス、コール管理サービス、および／または同種のものなどのさまざまなサービスを提供することができる。クラスタ化されたアプリケーション１２２は、冗長サービスを提供する。たとえば、クラスタ化されたアプリケーション１２２は、クラスタ化されたＩＶＲアプリケーションであってもよい。

データベース１２３は、リレーショナル・データベース、ディレクトリ・サービス、ファイル・システム、オブジェクト指向データベース、および／または同種のものなどの任意のタイプのデータベース１２３であってもよいし、または任意のタイプのデータベース１２３を含んでもよい。データベース１２３は、クラウド・サービス１３０からの通知／要求を受信した結果として、クラスタ化されたアプリケーション１２２によって使用される。たとえば、データベース１２３は、企業の顧客についての情報（たとえば、アドレス、電話番号、クレジット・カード番号、その他）を収容するデータベース１２３であってもよい。

クラウド・サービス１３０は、サービスとしての通信プラットフォーム（ＣＰａａＳ）、サービスとしてのコンタクトセンタ（ＣＣａａＳ）、アプリケーション管理サービス、消費者サービス、および／または同種のものなどのネットワーク・ベースのサービスを提供することができる任意のサービスであってもよいし、または任意のサービスを含んでもよい。クラウド・サービス１３０は、多数の企業データ・センタ１２０から送信されたロング・ポールＨＴＴＰ ＧＥＴに基づいて、多数の企業にクラウド・サービスを提供することができる。クラウド・サービス１３０は、ブリッジ１３１をさらに備える。

ブリッジ１３１は、クラウド・サービス１３０とクラスタ化されたアプリケーション１２２との間にブリッジを提供するシステム／アプリケーションである。ブリッジ１３１は、キュー・マネジャ１３２と、イベント・キュー１３３とをさらに備える。

キュー・マネジャ１３２は、クラウド・サービス１３０と企業データ・センタ１２０との間の情報のフローを管理することができるソフトウェアに結合された任意のハードウェアであってもよいし、または任意のハードウェアを含んでもよい。キュー・マネジャ１３２は、イベント・キュー１３３を介して、イベントおよびデータを管理する。

イベント・キュー１３３は、個々のクラスタ化されたアプリケーション１２２のためのイベントを管理するソフトウェアに結合された任意のハードウェアであってもよいし、または任意のハードウェアを含んでもよい。たとえば、企業データ・センタ１２０が３つのアクティブなクラスタ化されたアプリケーション１２２（すなわち、同じアプリケーションの異なるインスタンス）を有する場合、クラウド・サービス１３０は、３つの対応するイベント・キュー１３３を有することになる。クラウド・サービス１３０が、それぞれ３つのクラスタ化されたアプリケーション１２２を有する２つの企業データ・センタ１２０をサポートした場合、ブリッジ１３１は、２つの企業データ・センタ１２０をサポートするために、６つのイベント・キュー１３３（３つのイベント・キュー１３３の２つのグループ）を有することになる。図２〜図６で説明されるメッセージにおいて使用される企業データ・センタ識別子に基づいて、別個の企業データ・センタ１２０を識別することができる。

図１には示されていないが、ブリッジ１３１は、クラウド・サービス１３０とは別個であってもよい。たとえば、ブリッジ１３１は、別個のサーバ上で稼働する別個のアプリケーションであってもよい。あるいは、ブリッジ１３１は、クラウド・サービス１３０から別個のプロセッサ・スレッド上で稼働することができる。

図２は、クラスタ化されたアプリケーション１２２のためのイベント・キュー１３３を作成および削除するためのプロセスの流れ図である。例証として、通信エンドポイント１０１Ａ〜１０１Ｎ、企業データ・センタ１２０、ファイヤーウォール１２１、クラスタ化されたアプリケーション１２２、データベース１２３、クラウド・サービス１３０、ブリッジ１３１、キュー・マネジャ１３２、およびイベント・キュー１３３は、コンピュータまたはマイクロプロセッサなどの、記憶されたプログラムで制御されるエンティティであり、これらは、メモリ（すなわち、コンピュータ・メモリ、ハード・ディスク、および／または同種のもの）などのコンピュータ可読記憶媒体に記憶されたプログラム命令を実行することによって、図２〜図６の方法および本明細書で説明されるプロセスを実施する。図２〜図６で説明される方法は特定の順序で示されているが、当業者であれば、図２〜図６におけるステップが、異なる順序で実装されてもよい、および／またはマルチスレッド環境において実装されてもよいことに気付くであろう。その上、実装に基づいて、さまざまなステップが省略されても、または追加されてもよい。

図２のプロセスは、クラウド・サービス１３０（すなわち、ブリッジ１３１）の観点からである。プロセスは、ステップ２００で開始する。ステップ２０２で、キュー・マネジャ１３２は、クラスタ化されたアプリケーション１２２から登録／登録解除メッセージが受信されているかどうかを判定する。たとえば、クラスタ化されたアプリケーション１２２が最初にロードされるとき、クラスタ化されたアプリケーション１２２は、キュー・マネジャ１３２に登録する。あるいは、クラスタ化されたアプリケーション１２２が取り外されるとき、クラスタ化されたアプリケーション１２２は、登録解除メッセージを送信する。一実施形態において、登録メッセージ／登録解除メッセージは、（たとえば、図４および図６で説明されるように）クラスタ化されたアプリケーション１２２から送信されたロング・ポールＨＴＴＰ ＧＥＴ要求であってよい。あるいは、登録／登録解除メッセージは、ＨＴＴＰ ＰＯＳＴまたは他のタイプのメッセージであってもよい。

ステップ２０２で登録／登録解除メッセージが受信されない場合、ステップ２０４で、クラウド・サービス１３０は、プロセスが完了するかどうかを判定する。ステップ２０４でプロセスが完了した場合、ステップ２０６で、プロセスは終了する。そうではなく、ステップ２０４でプロセスが完了していない場合、ステップ２０２のプロセスが繰り返される。

ステップ２０２で登録／登録解除メッセージ（たとえば、クラスタ化されたアプリケーション１２２からの第１のロング・ポールＨＴＴＰ ＧＥＴ要求）が受信されている場合、ステップ２０８で、キュー・マネジャ１３２は、クラスタ化されたアプリケーションの識別子を入手する。クラスタ化されたアプリケーションの識別子は、クラスタ化されたアプリケーション１２２のグループにおける特定のクラスタ化されたアプリケーション１２２を一意に識別する。クラスタ化されたアプリケーションの識別子は、ステップ２０２の受信されたメッセージにある。ステップ２１０で、受信されたメッセージが登録メッセージである場合、ステップ２１４で、キュー・マネジャ１３２は、クラスタ化されたアプリケーションの識別子に基づいて、クラスタ化されたアプリケーション１２２のためのイベント・キュー１３３を作成する。プロセスは次いで、ステップ２０２に戻る。

ステップ２１４で作成されたイベント・キュー１３３は、クラスタ化されたアプリケーション１２２によって使用されるイベントを保持するために使用されるキューである。イベント・キュー１３３におけるイベントは、通常、特定の通信セッションに関連付けられたセッション識別子（たとえば、特定の音声通信セッションに関連付けられたセッション識別子）を含む。このやり方で、特定のクラスタ化されたアプリケーション１２２は、多数の通信セッションを同時にサポートすることができる。一実施形態において、通信セッション／クラスタ化されたアプリケーション１２２ごとに、別個のイベント・キュー１３３を作成することができる。たとえば、個々のクラスタ化されたアプリケーション１２２は、多数の通信セッション（たとえば、個々のクラスタ化されたアプリケーション１２２によって取り扱われている２つの別個の音声通信セッション）についての多数のイベント・キュー１３３を有することができる。

ステップ２１０でメッセージが登録解除メッセージである場合、ステップ２１２で、キュー・マネジャ１３２は、クラスタ化されたアプリケーションの識別子に関連付けられたクラスタ化されたアプリケーション１２２のためのイベント・キュー１３３を削除する。プロセスは次いで、ステップ２０２に進む。

図３は、通信セッション識別子に基づいて、イベントをイベント・キュー１３３に割り当てるためのプロセスの流れ図である。図３のプロセスは、ブリッジ１３１の観点からである。ステップ３０２で、キュー・マネジャ１３２は、通信セッションについてのイベントが受信されているかどうかを判定する。通信セッションについてのイベントは、新しいコールの受信の指摘、アナウンスの再生の完了、収集したデュアル・トーン・マルチ周波数（ＤＴＭＦ）トーン、話し言葉の検出、参加者がコールからドロップされること、および／または同種のものなどの、通信セッションに関連付けられてよい任意のタイプのイベントであってもよいし、または任意のタイプのイベントを含んでもよい。

ステップ３０２で通信セッションについてのイベントが受信されない場合、ステップ３０４で、プロセスは、プロセスが完了するかどうかを判定する。ステップ３０４でプロセスが完了した場合、ステップ３０６で、プロセスは終了する。そうではなく、ステップ３０４でプロセスが完了していない場合、プロセスは、ステップ３０２に戻って、通信セッションについてのイベントを受信するのを待つ。

ステップ３０２で通信セッションについてのイベントが受信された場合、ステップ３０８で、キュー・マネジャ１３２は、通信セッションのためのセッション識別子を入手する。セッション識別子は、グローバルに一意の識別子（ＧＵＩＤ）、一意のコール識別子、および／または同種のものなどの、通信セッションを一意に識別するために使用される一意の識別子である。キュー・マネジャ１３２は、セッション識別子を、特定のクラスタ化されたアプリケーション１２２に関連付けられた特定のイベント・キュー１３３にマップする。これは、個々の通信セッションに関連付けられた多数のイベントが存在し得るケースについて必要である。たとえば、音声コールが、音声コールが最初に確立されたときに第１のイベントを、音声コールが転送または記録されたときに第２のイベントを有することができる。ステップ３１０で、キュー・マネジャ１３２は、そのセッション識別子が新しい通信セッションのためであるかどうかを判定する。セッション識別子が新しい通信セッションのためである場合、ステップ３１２で、キュー・マネジャ１３２は、イベントをイベント・キュー１３３に割り当てる。イベント・キュー１３３への割り当ては、ローディング、ラウンド・ロビン・スキーム、および／または同種のものなどの、さまざまなタイプの情報に基づくことができる。キュー・マネジャ１３２がセッション識別子に基づいてイベントをイベント・キュー１３３に割り当てるとき、キュー・マネジャ１３２は、通信セッションを、個別のクラスタ化されたアプリケーション１２２に割り当てている。同じクラスタ化されたアプリケーション１２２は、通常、個々の通信セッションについてのすべてのイベントを管理する。プロセスは次いで、ステップ３０２に戻る。

そうではなく、ステップ３１０でセッション識別子が既存の通信セッションのためである場合（すなわち、その通信セッションについての以前のイベントがイベント・キュー１３３に既に割り当てられていて、なおもアクティブである場合）、ステップ３１４で、キュー・マネジャ１３２は、イベントを、（セッション識別子に基づいて）同じ通信セッションについての以前のイベントと同じイベント・キュー１３３に割り当てる。プロセスは次いで、ステップ３０２に進む。

図４は、クラスタ化されたアプリケーション１２２からのＨＴＴＰロング・ポーリングを取り扱うためのプロセスの流れ図である。プロセスは、ステップ４００で開始する。ステップ２１４でイベント・キュー１３３が作成されるとき、一実施形態において、ステップ４０２で、キュー・マネジャ１３２は、作成されたイベント・キュー１３３ごとに別個のプロセッサ・スレッドを作成する。ステップ４０４で、キュー・マネジャ１３２は、イベント・キュー１３３に割り当てられたクラスタ化されたアプリケーション１２２から、ロング・ポールＨＴＴＰ ＧＥＴ要求を受信するのを待つ。

ロング・ポールＨＴＴＰ ＧＥＴ要求は、ここで、クラスタ化されたアプリケーション１２２が、ＨＴＴＰ ＧＥＴ要求を送信し、キュー・マネジャ１３２からの応答を受信するための時間期間（たとえば、２分）の間待つ。応答が時間期間内に受信されない場合、新しいＨＴＴＰ ＧＥＴ要求がクラスタ化されたアプリケーション１２２によって送信される。ＨＴＴＰ ＧＥＴ要求を使用する目的は、クラスタ化されたアプリケーション１２２が、発信ＨＴＴＰソケット（ポート８０）を使用してクラウド・サービス１３０との通信セッションを開始するようにすることである。これにより、通信セッションは企業内（信頼できる発信元）から開始されるので、ファイヤーウォール１２１までの強化されたセキュリティを提供する。通信セッションがクラウド・サービス１３０から開始された場合、ファイヤーウォール１２１上に新しいポートを開かなければならないことがある。これは、別のエンティティが（たとえば、中間者攻撃を使用して）着信ＨＴＴＰ ＧＥＴ要求／ＰＯＳＴを含む場合に、潜在的なセキュリティ侵害をもたらす。ＨＴＴＰ ＧＥＴ要求のアドレスが中間者攻撃者によって変更されている可能性があるため、結果的に中間者攻撃者へのデータの損害となることがある。

ステップ４０４でロング・ポールＨＴＴＰ ＧＥＴ要求が受信されない場合、ステップ４０６で、プロセスは、プロセスが完了するかどうか（たとえば、イベント・キュー１３３がステップ２１２で削除される）を判定する。ステップ４０６でプロセスが完了した場合、ステップ４０８で、プロセスは終了する。そうではなく、ステップ４０６でプロセスが完了していない場合、プロセスはステップ４０４を繰り返す。

ステップ４０４でロング・ポールＨＴＴＰ ＧＥＴ要求が受信された場合、ステップ４１０で、キュー・マネジャ１３２は、イベント・キュー１３３になんらかのイベントが存在するかどうかを判定する。ステップ４１０でイベント・キュー１３３に何のイベントも存在しない場合、ステップ４１２で、キュー・マネジャ１３２は、タイムアウト（ロング・ポールＨＴＴＰ ＧＥＴ要求を受信しない時間期間）が存在しているかどうか、またはイベント・キュー１３３に関連付けられたクラスタ化されたアプリケーション１２２から新しいロング・ポールＨＴＴＰ ＧＥＴ要求が受信されているかどうかを判定する。ステップ４１２で新しいロング・ポールＨＴＴＰ ＧＥＴ要求が受信されており、タイムアウトが発生していない場合、プロセスは、ステップ４１０に戻る。そうではなく、ステップ４１２でタイムアウトが発生している場合、プロセスは、ステップ４０４に戻る。

ステップ４１０でイベント・キュー１３３に１つまたは複数のイベントが存在する場合、ステップ４１４で、キュー・マネジャ１３２は、イベント・キュー１３３における１つまたは複数のイベントを、クラスタ化されたアプリケーション１２２に送信する。プロセスは次いで、ステップ４１２に戻る。

図５は、ロング・ポールＨＴＴＰ ＧＥＴ要求ごとに送信されるイベントの数を管理するためのプロセスの流れ図である。図５のプロセスは、図４のステップ４１４の一例示的な実施形態である。ステップ４１０でイベント・キュー１３３に１つまたは複数のイベントが存在すると判定した後、ステップ５００で、キュー・マネジャ１３２は、イベント・キュー１３３におけるイベントの数を判定する。ステップ５０２で、キュー・マネジャ１３２は、イベント・キュー１３３におけるイベントの数が、送信する最大数よりも大きいかどうかを判定する。イベント・キュー１３３におけるイベントの最大数は、１からＮまでの任意の数であってよく、ここで、Ｎは整数である。イベントの最大数は、管理者または他のエンティティによって定義されてよい。

イベント・キュー１３３におけるイベントの数がイベントの最大数よりも大きい場合、ステップ５０４で、キュー・マネジャ１３２は、イベント・キュー１３３にある最大数までのイベントを、クラスタ化されたアプリケーション１２２に送信する。プロセスは次いで、ステップ４１２に進む。

そうではなく、イベント・キュー１３３におけるイベントの数がイベントの最大数よりも大きくない場合、ステップ５０６で、キュー・マネジャ１３２は、イベント・キュー１３３にある全部のイベントを、クラスタ化されたアプリケーション１２２に送信する。プロセスは次いで、ステップ４１２に進む。

ステップ５０４およびステップ５０６で送信されるイベントのタイプは、同じ通信セッションについての、および／または多数の通信セッションについてのイベントであってよい。たとえば、ステップ５０４／５０６で送信されるイベントは、同じ通信セッションについてであってよい。一実施形態において、イベントの最大数はまた、個々の通信セッションに基づくことができる。たとえば、個々のクラスタ化されたアプリケーション１２２が現在２つの通信セッションを取り扱っている場合、クラスタ化されたアプリケーション１２２が取り扱っているそれぞれの通信セッションに基づいて、最大数が存在してよい（たとえば、第１の通信セッションについては１つのイベント、および第２の通信セッションについては２つのイベント）。

図５のプロセスは、異なるイベント・キュー１３３について異なる最大数を有してもよい。たとえば、第１のイベント・キュー１３３は、１つのイベントという最大数を有してよく、第２のイベント・キュー１３３は、２つのイベントという最大数を有してもよい。一実施形態において、異なる最大数は、同じタイプのクラスタ化されたアプリケーション１２２についてであっても、または同じ企業データ・センタ１２０における異なるタイプのクラスタ化されたアプリケーション１２２についてであってもよい。

一実施形態において、最大数の違いは、異なる２つの企業データ・センタ１２０に基づくことができる。たとえば、第１の企業データ・センタ１２０におけるクラスタ化されたアプリケーション１２２は、１つのイベントという最大数を有してよく、第２の企業データ・センタにおけるクラスタ化されたアプリケーション１２２は、２つのイベントという最大数を有してもよい。第１のデータ・センタ１２０におけるクラスタ化されたアプリケーション１２２は、同じタイプのクラスタ化されたアプリケーション１２２であっても、または異なるタイプのクラスタ化されたアプリケーション１２２であってもよい。たとえば、第１および第２の企業データ・センタ１２０におけるクラスタ化されたアプリケーション１２２が、同じクラスタ化されたＩＶＲアプリケーションであってもよい。あるいは、第１のデータ・センタ１２０におけるクラスタ化されたアプリケーション１２２は、クラスタ化されたデータベース・アプリケーションであってよく、第２のデータ・センタ１２０におけるクラスタ化されたアプリケーション１２２は、クラスタ化されたコール記録アプリケーションであってもよい。これらの例において、それぞれの企業データ・センタ１２０は、一意の企業識別子を使用して、異なる企業・データ・センタ１２０におけるクラスタ化されたアプリケーション１２２同士を区別する。

図６は、クラウド・サービス１３０とクラスタ化されたアプリケーション１２２との間をブリッジするためのプロセスの流れ図である。ブリッジ１３１の目的は、クラウド・サービス１３０およびクラスタ化されたアプリケーション１２２についてソフトウェアへの要求される必要な変更を最小限にすることである。

ステップ６００で、クラスタ化されたアプリケーション１２２が最初にロング・ポールＨＴＴＰ ＧＥＴ要求（一実施形態において、これは、ロング・ポールＨＴＴＰ ＰＯＳＴ要求であってもよい）を送信するとき、プロセスが開始する。ステップ６００のロング・ポールＨＴＴＰ ＧＥＴ要求が送信されて、クラスタ化されたアプリケーション１２２に送信されることになるデータ（すなわち、イベント／データ）の準備ができるまで待つ。ステップ６０２で、クラウド・サービス１３０で着信コールが受信される。たとえば、着信コールは、通信エンドポイント１０１Ａからの着信コールであってもよい。着信コールは、音声コール、ビデオ・コール、マルチメディア・コール、インスタント・メッセージング（ＩＭ）コール、および／または同種のものであってもよい。

ステップ６０４で、着信コールの受信に応答して、クラウド・サービス１３０は、ルールに基づいて、どのクラスタ化されたアプリケーション１２２が着信コール（イベント）を通知されなければならないのかを判定する。たとえば、着信コールは、クラスタ化されたＩＶＲアプリケーション１２２への音声コールであってもよい。どのクラスタ化されたアプリケーション１２２が呼び出されなければならないかが判定されると、ステップ６０６で、クラウド・サービス１３０は、ＨＴＴＰ ＰＯＳＴをブリッジ１３１に送信する。ステップ６０６のＨＴＴＰ ＰＯＳＴはまた、着信コールのセッション識別子を含む。セッション識別子は、着信コールを一意に識別する。

一実施形態において、ステップ６０６のＨＴＴＰ ＰＯＳＴはまた、（たとえば、拡張マークアップ言語（ＸＭＬ）フォーマットで）データを含むことができる。データ（この例ではＸＭＬ）の存在は、クラウド・サービス１３０が、クラスタ化されたアプリケーション１２２からの応答データ（ステップ６１４で送信される）を予期していることを指し示す。ＸＭＬを使用することが説明されているが、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）などの、データの他のフォーマットを使用することができる。応答データは、異なるタイプの応答データであってもよい。たとえば、応答データは、データベース１２３からのデータ、ＩＶＲシステムから集められたデータ、エージェント識別子、および／または同種のものであってもよい。

ステップ６０８で、ブリッジ１３１は、セッション識別子に基づいて、イベントをイベント・キュー１３３に（すなわち、図３のステップ３１２／３１４で説明されたように）割り当てる。ステップ６００のロング・ポールＨＴＴＰ ＧＥＴ要求に基づいて、ステップ６１０で、ブリッジ１３１は、セッション識別子／イベントを含む２００ＯＫを、クラスタ化されたアプリケーション１２２に（すなわち、ステップ４１４で説明されたように）送信する。ステップ６０６のＨＴＴＰ ＰＯＳＴがＸＭＬデータを収容する場合、ステップ６１０での２００ＯＫもまたＸＭＬデータを含む。ステップ６１２で、クラスタ化されたアプリケーション１２２は次いで、ステップ６１０で送信されたイベント／ＸＭＬデータに基づいて実行する。たとえば、クラスタ化されたアプリケーション１２２は、ステップ６１２で、新しいコール通知メッセージから発呼者ＩＤを取り、データベース１２３から発呼者についてのなんらかの情報をルックアップし、その情報を使用して、発呼者へのカスタム・グリーティングを再生するためのＸＭＬコマンドを作成することができる。

ステップ６１４で、クラスタ化されたアプリケーション１２２は、ＸＭＬデータ／セッション識別子を有するＨＴＴＰ ＰＯＳＴをブリッジ１３１に送信する。ステップ６１６で、ブリッジ１３１は、ＨＴＴＰ ＰＯＳＴから、セッション識別子／ＸＭＬデータを入手する。ステップ６１８で、ブリッジ１３１は、２００ＯＫを送信する。ステップ６０６のＨＴＴＰ ＰＯＳＴがＸＭＬデータ（すなわち、カスタム・グリーティングを再生するためのコマンド）を収容していた場合、２００ＯＫもまた、ＸＭＬデータ（たとえば、データベース１２３からのデータ）を含む。ステップ６２０で、クラウド・サービス１３０は次いで、ＸＭＬデータを使用する。ステップ６２２で、ブリッジ１３１はまた、２００ＯＫメッセージをクラスタ化されたアプリケーション１２２に送信して、ステップ６１４のＨＴＴＰ ＰＯＳＴを肯定応答する。

ステップ６２２で、着信コールにおける第２のイベントが発生する。たとえば、着信コールのメディア・ストリームにおいて、話し言葉またはジェスチャが検出される。これにより、ステップ６２４で、クラウド・サービス１３０が（定義されたルールに基づいて）イベントを有するＨＴＴＰ ＰＯＳＴをブリッジ１３１に送信することをもたらす。ステップ６２６で、ブリッジ１３１は、イベントを、クラスタ化されたアプリケーション１２２（同じクラスタ化されたアプリケーション１２２）のためのイベント・キュー１３３に置く。ステップ６２８で、クラスタ化されたアプリケーション１２２は、別のロング・ポールＨＴＴＰ ＧＥＴ（一実施形態において、これは、ロング・ポールＨＴＴＰ ＰＯＳＴ要求であってもよい）を送信する。ステップ６２８のロング・ポールＨＴＴＰ ＧＥＴの受信に応答して、ステップ６３２で、ブリッジは、イベント・キュー１３３にある（ステップ６２４のＨＴＴＰ ＰＯＳＴの）イベントを取って、そのイベントを２００ＯＫメッセージにおいてクラスタ化されたアプリケーション１２２に送信する。ステップ６３４で、クラスタ化されたアプリケーションは次いで、そのイベントを処理する。ステップ６３６で、ブリッジ１３１はまた、２００ＯＫをクラウド・サービス１３０に送信して、ステップ６２４のＨＴＴＰ ＰＯＳＴを肯定応答する。

一実施形態において、ステップ６２４のＨＴＴＰ ＰＯＳＴは、ステップ６２８のロング・ポールＨＴＴＰ ＧＥＴの後に送信されてもよい。この実施形態において、ステップ６２６は、ステップ６２８の後に発生することになる。

図６のプロセスは、クラウド・サービス１３０が、ＸＭＬでデータを送信することによって、クラスタ化されたアプリケーション１２２に指示を要求する場合を説明している。一実施形態において、クラウド・サービス１３０は、ステップ６０６のＨＴＴＰ ＰＯＳＴでイベントを送信するだけでよく、いかなるＸＭＬデータを送信しなくてもよい。この例示的な実施形態において、クラウド・サービス１３０は、ステップ６１８の２００ＯＫにおいて、いかなるＸＭＬデータを受信することも予期していない。たとえば、ステップ６０６のＨＴＴＰ ＰＯＳＴ／ステップ６１０の２００ＯＫは、ステップ６０２の着信コールがクラスタ化されたアプリケーション１２２が追跡している特定の発呼者からであることを、クラスタ化されたアプリケーション１２２に通知するためであってよい。この例において、ステップ６１４のＨＴＴＰ ＰＯＳＴ（またはＨＴＴＰ ＧＥＴ）はいかなるＸＭＬデータも収容しない。同様に、ステップ６１８の２００ＯＫもいかなるＸＭＬデータを収容しない。

一実施形態において、ステップ６１０の２００ＯＫにおけるＸＭＬデータ（必ずしもＸＭＬデータそれ自体に限らない）が存在しているだけで、応答が必要であることを、クラスタ化されたアプリケーション１２２に指し示す。たとえば、ＸＭＬデータは、データなしでタグのみを含んでもよい。このケースにおいて、クラスタ化されたアプリケーション１２２は、イベントのタイプに基づいて、何のデータが送信されることになるかを既に知っている。あるいは、ＸＭＬデータそれ自体が、ステップ６１４のＨＴＴＰ ＰＯＳＴメッセージにおいて、クラスタ化されたアプリケーション１２２が何のデータを送信するのかを指し示すことができる。

図６のプロセスは、単一のクラスタ化されたアプリケーション１２２について説明している。しかしながら、当業者であれば、図６のプロセスがまた、多数のクラスタ化されたアプリケーション１２２と連携するように設計されることを理解するであろう。たとえば、多数のクラスタ化されたアプリケーション１２２は、多数の着信コールのためのサービスを並行して提供することができる。

加えて、図６のプロセスは、異なる企業データ・センタ１２０における異なるクラスタ化されたアプリケーション１２２と連携することができる。この実施形態において、ブリッジ１３１は、ステップ６０６のＨＴＴＰ ＰＯＳＴにおけるイベントのタイプに基づいて、または企業データ・センタのための識別子に基づいて、個々の企業データ・センタ１２０を識別することができる。クラスタ化されたアプリケーションは、企業データ・センタ識別子を使用して、ステップ６１４で応答する。

本明細書で説明されるプロセッサの例には、限定はされないが、Ｑｕａｌｃｏｍｍ（登録商標）Ｓｎａｐｄｒａｇｏｎ（登録商標）８００および８０１、４Ｇ ＬＴＥ統合および６４ビット・コンピューティングによるＱｕａｌｃｏｍｍ（登録商標）Ｓｎａｐｄｒａｇｏｎ（登録商標）６１０および６１５、６４ビット・アーキテクチャによるＡｐｐｌｅ（登録商標）Ａ７プロセッサ、Ａｐｐｌｅ（登録商標）Ｍ７モーション・コプロセッサ、Ｓａｍｓｕｎｇ（登録商標）Ｅｘｙｎｏｓ（登録商標）シリーズ、Ｉｎｔｅｌ（登録商標）Ｃｏｒｅ（登録商標）プロセッサのファミリ、Ｉｎｔｅｌ（登録商標）Ｘｅｏｎ（登録登録商標）プロセッサのファミリ、Ｉｎｔｅｌ（登録商標）Ａｔｏｍ（登録商標）プロセッサのファミリ、Ｉｎｔｅｌ Ｉｔａｎｉｕｍ（登録商標）プロセッサのファミリ、Ｉｎｔｅｌ（登録商標）Ｃｏｒｅ（登録商標）ｉ５−４６７０Ｋおよびｉ７−４７７０Ｋ ２２ｎｍ Ｈａｓｗｅｌｌ、Ｉｎｔｅｌ（登録商標）Ｃｏｒｅ（登録商標）ｉ５−３５７０Ｋ ２２ｎｍ Ｉｖｙ Ｂｒｉｄｇｅ、ＡＭＤ（登録商標）ＦＸ（登録商標）プロセッサのファミリ、ＡＭＤ（登録商標）ＦＸ−４３００、ＦＸ−６３００、およびＦＸ−８３５０ ３２ｎｍ Ｖｉｓｈｅｒａ、ＡＭＤ（登録商標）Ｋａｖｅｒｉプロセッサ、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ（登録商標）Ｊａｃｉｎｔｏ Ｃ６０００（登録商標）オートモーティブ・インフォテインメント・プロセッサ、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ（登録商標）ＯＭＡＰ（登録商標）オートモーティブ・グレード・モバイル・プロセッサ、ＡＲＭ（登録商標）Ｃｏｒｔｅｘ（登録商標）−Ｍプロセッサ、ＡＲＭ（登録商標）Ｃｏｒｔｅｘ−ＡおよびＡＲＭ９２６ＥＪ−Ｓ（登録商標）プロセッサ、他の業界等価なプロセッサのうちの少なくとも１つが含まれてよく、任意の知られた、または将来開発される、標準、命令セット、ライブラリ、および／またはアーキテクチャを使用して、コンピュータ計算機能を実施することができる。

本明細書で議論されたステップ、機能、および動作のいずれも、連続的かつ自動的に実施することができる。

しかしながら、本開示を不必要に曖昧にすることを避けるために、前述の説明は、いくつかの知られた構造およびデバイスを省略している。この省略は、特許請求される開示の範囲を限定するものとして解釈されるべきではない。特定の詳細は、本開示の理解を提供するために記載される。しかしながら、本開示は、本明細書に記載された特定の詳細を越えて多様なやり方で実践され得ることを認識されたい。

さらに、本明細書で例証した例示的な実施形態は、システムの並置されたさまざまなコンポーネントを示しているが、システムの一定のコンポーネントは、ＬＡＮおよび／もしくはインターネットなどの分散ネットワーク１１０の遠隔部分に、または専用システム内にリモートに設置されてもよい。したがって、システムのコンポーネントは、１つまたは複数のデバイスに組み合わされても、または、アナログおよび／もしくはデジタル電気通信ネットワーク、パケット交換ネットワーク、または回線交換ネットワークなどの分散ネットワークの個別のノード上に並置されてもよいことを認識されたい。前述の説明から、およびコンピュータ計算上の効率の理由で、システムのコンポーネントは、システムの動作に影響することなく、コンポーネントの分散ネットワーク内の任意の場所に配置されてもよいことを認識されたい。たとえば、さまざまなコンポーネントを、ＰＢＸおよびメディア・サーバなどのスイッチに、ゲートウェイに、１つまたは複数の通信デバイスに、１つもしくは複数のユーザの構内に、またはそれらのなんらかの組合せで設置することができる。同様に、システムの１つまたは複数の機能性部分が、電気通信デバイスと関連付けられたコンピューティング・デバイスとの間で分散されてもよい。

さらに、要素を接続するさまざまなリンクは、ワイヤード・リンクもしくはワイヤレス・リンク、またはそれらの任意の組合せ、または接続された要素へと、および接続された要素からデータを供給する、および／または通信することが可能な任意の他の知られた、または後に開発される要素であってもよいことを認識されたい。これらのワイヤード・リンクまたはワイヤレス・リンクはまた、セキュアなリンクであってよく、暗号化した情報を通信することが可能であってよい。リンクとして使用される伝送媒体は、たとえば、同軸ケーブル、銅ワイヤ、および光ファイバを含む、電気信号のための任意の好適な搬送体であってよく、無線波および赤外線データ通信の間に生成されるような音響または光波の形態を取ることができる。

また、流れ図は、イベントの個別のシーケンスに関係して議論され、例証されてきたが、このシーケンスへの変更、追加、および省略は、本開示の動作に実質的に影響することなく行われてもよいことを認識されたい。

本開示のいくつかの変形形態および修正形態を使用することができる。本開示のいくつかの特徴について提供することは、他の特徴を提供することなく可能であるだろう。

さらに別の実施形態において、本開示のシステムおよび方法を、特殊目的コンピュータ、プログラムされたマイクロプロセッサまたはマイクロコントローラおよび周辺集積回路素子、ＡＳＩＣまたは他の集積回路、デジタル信号プロセッサ、ディスクリート素子回路などのハードワイヤード電子回路または論理回路、ＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬなどのプログラマブル論理デバイスまたはゲートアレイ、特殊目的コンピュータ、任意の同等の手段、その他と共に実装することができる。一般に、本明細書で例証した方法論の実装することが可能なあらゆるデバイスまたは手段を、本開示のさまざまな態様を実装するために使用することができる。本開示のために使用することができる例示的なハードウェアには、コンピュータ、ハンドヘルド・デバイス、電話（たとえば、セルラ、インターネット対応、デジタル、アナログ、ハイブリッド、およびその他）、ならびに本技術分野で知られた他のハードウェアが含まれる。これらのデバイスのうちのいくつかは、プロセッサ（たとえば、単一のまたは多数のマイクロプロセッサ）、メモリ、不揮発性記憶装置、入力デバイス、および出力デバイスを含む。さらに、限定はしないが、分散処理もしくはコンポーネント／オブジェクト分散処理、並列処理、または仮想マシン処理を含む代替的なソフトウェア実装がまた、本明細書で説明された方法を実装するために構築されてもよい。

さらに別の実施形態において、開示される方法を、多様なコンピュータまたはワークステーション・プラットフォーム上で使用することができるポータブル・ソース・コードを提供するオブジェクトまたはオブジェクト指向のソフトウェア開発環境を使用するソフトウェアと共に容易に実装することができる。あるいは、開示されるシステムを、標準的な論理回路またはＶＬＳＩ設計を使用するハードウェアで、部分的に、または全体的に実装することができる。本開示に従ってシステムを実装するために、ソフトウェアが使用されるのか、ハードウェアが使用されるのかは、システムの速度および／もしくは効率要件、個別の機能、ならびに利用される個別のソフトウェア・システムもしくはハードウェア・システム、またはマイクロプロセッサ・システムもしくはマイクロコンピュータ・システムに依存する。

さらに別の実施形態において、開示される方法を、コントローラおよびメモリと協働するプログラムされた汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ、その他の上で実行され、記憶媒体上に記憶することができるソフトウェアで部分的に実装することができる。これらの実例において、本開示のシステムおよび方法を、アプレット、ＪＡＶＡ（登録商標）、またはＣＧＩスクリプトなどの、パーソナル・コンピュータ上に埋め込まれたプログラムとして、サーバもしくはコンピュータ・ワークステーション上に常駐するリソースとして、専用の測定システム、システム・コンポーネント、その他に埋め込まれたルーチンとして実装することができる。システムはまた、ソフトウェアおよび／またはハードウェア・システムの中に、システムおよび／または方法を物理的に組み込むことによって実装することもできる。

本開示は、個別の標準およびプロトコルを参照して実施形態において実装されるコンポーネントおよび機能を説明しているが、本開示は、そのような標準およびプロトコルに限定はされない。本明細書で言及していない他の同様の標準およびプロトコルが存在し、本開示に含まれるものと考えられる。その上、本開示で言及した標準およびプロトコル、ならびに本明細書で言及していない他の同様の標準およびプロトコルは、本質的に同じ機能を有するより速い、またはより効率的な等価物に定期的に取って代わる。同じ機能を有するそのような置き換えられた標準およびプロトコルは、本開示に含まれる等価物と考えられる。

本開示は、さまざまな実施形態、構成、および態様において、さまざまな実施形態、部分組合せ、およびその部分集合を含む、実質上本明細書で図示され、説明されたようなコンポーネント、方法、プロセス、システム、および／または装置を含む。当業者であれば、本開示を理解した後で、本明細書で開示されたシステムおよび方法をどのように作り出し、使用するかを理解するであろう。本開示は、さまざまな実施形態、構成、および態様において、本明細書に、またはさまざまな実施形態、構成、もしくはその態様に図示および／または説明されていない項目がない場合のデバイスおよびプロセスを提供することを含み、たとえば、性能を向上させ、実装の容易さを達成し、および／または実装のコストを削減するために、以前のデバイスまたはプロセスで使用されていた可能性があるそのような項目がない場合のデバイスおよびプロセスを提供することを含む。

本開示の上記の議論は、例証および説明を目的として提示されてきた。上記は、本開示を、本明細書で開示した形式に限定することを意図していない。たとえば、上記の詳細な説明において、本開示のさまざまな特徴は、本開示を合理化する目的のために、１つまたは複数の実施形態、構成、または態様に一緒にグループ化されている。本開示の実施形態、構成、または態様の特徴は、上で議論された以外の代替実施形態、構成、または態様に組み合わされてもよい。この開示の方法は、特許請求される開示が各請求項に明示的に列挙されているよりも多くの特徴を要するという意図を反映しているものとして解釈されるべきではない。むしろ、以下の特許請求の範囲が反映するように、発明の態様は、単一の上記に開示された実施形態、構成、または態様のすべての特徴よりも少ないところにある。したがって、以下の特許請求の範囲はこれにより、この詳細な説明に組み込まれ、各請求項は、本開示の別個の好ましい実施形態としてそれ自体で成り立っている。

その上、本開示の説明は、１つもしくは複数の実施形態、構成、または態様、ならびに一定の変形形態および修正形態の説明を含んできたが、他の変形形態、組合せ、および修正形態は、たとえば、本開示を理解した後での当業者の技術および知識の範囲内にあり得るように、本開示の範囲内である。特許請求されるものに対して代替的で、交換可能な、および／または等価な構造、機能、範囲、またはステップが本明細書に開示されているか否かにかかわらず、かついかなる特許性のある主題も公に捧げることを意図することなく、そのような代替的で、交換可能な、および／または等価な構造、機能、範囲、またはステップを含む、代替実施形態、構成、または態様を許容される程度まで含む権利を取得することが意図される。

Claims (10)

1. マイクロプロセッサと、
   前記マイクロプロセッサに結合されたコンピュータ可読媒体であって、前記マイクロプロセッサを実行させるようにプログラムするマイクロプロセッサ可読命令および実行可能命令を含むコンピュータ可読媒体と、
   複数のクラスタ化されたアプリケーションから、前記複数のクラスタ化されたアプリケーションの複数の識別子を含む複数のロング・ポール・ハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）要求を受信するキュー・マネジャであって、前記複数の識別子のそれぞれに基づいて、前記複数のクラスタ化されたアプリケーションのための複数のイベント・キューのそれぞれを作成し、複数の通信セッションのそれぞれに基づいて、複数のイベントを前記複数のイベント・キューのそれぞれに追加し、前記複数のイベント・キューにおける前記複数のイベントに基づいて、前記複数のイベントを含む、前記複数のロング・ポールＨＴＴＰ要求に対する複数の応答を送信する、キュー・マネジャと
   を備えるシステム。
2. 前記キュー・マネジャが、クラウド・サービスから、前記複数の通信セッションのうちの個々の通信セッションについてのイベントを含むＨＴＴＰ ＰＯＳＴを受信し、前記キュー・マネジャが、前記複数の通信セッションのうちの前記個々の通信セッションの識別子を使用して、個々のクラスタ化されたアプリケーションのための個々のイベント・キューを識別し、前記ＨＴＴＰ ＰＯＳＴはまた、拡張マークアップ言語（ＸＭＬ）データおよびＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）データのうちの少なくとも１つを含み、前記ＸＭＬ／ＪＳＯＮデータの存在が、前記クラウド・サービスが前記個々のクラスタ化されたアプリケーションから、データを有する応答メッセージを予期していることを指し示す、請求項１に記載のシステム。
3. 前記複数のイベント・キューのうちの個々のイベント・キューが、前記複数の通信セッションのうちの個々の通信セッションについての複数のイベントを含み、前記キュー・マネジャが、前記個々の通信セッションについて送信するイベントの最大数に基づいて、前記複数のイベントを前記クラスタ化されたアプリケーションに単一のメッセージで送信すること、および前記個々の通信セッションについての前記イベント・キューにおける前記複数のイベントのうちの一部のみを単一のメッセージで送信することのうちの少なくとも１つを行う、請求項１に記載のシステム。
4. 前記複数のイベント・キューが、第１のイベント・キューと第２のイベント・キューとを含み、前記第１のイベント・キューが、第１の通信セッションに関連付けられた複数のイベントを含み、前記第２のイベント・キューが、第２の通信セッションに関連付けられた複数のイベントを含み、前記第１のイベント・キューが、第１のロング・ポールＨＴＴＰ ＧＥＴ要求に応答して送信され得るイベントの第１の最大数を有し、前記第２のイベント・キューが、第２のロング・ポールＨＴＴＰ ＧＥＴ要求に応答して送信され得るイベントの第２の最大数を有し、イベントの前記第１の最大数が、イベントの前記第２の最大数とは異なる、請求項１に記載のシステム。
5. 企業データ・センタをさらに備え、
   前記企業データ・センタが、前記複数のクラスタ化されたアプリケーションを含み、前記複数のクラスタ化されたアプリケーションが、
   前記複数のロング・ポールＨＴＴＰ要求を送信し、
   前記複数の応答を受信し、
   受信された複数の応答に基づいて、複数のアクションを実装する、
   請求項１に記載のシステム。
6. マイクロプロセッサによって、複数のクラスタ化されたアプリケーションから、複数のロング・ポール・ハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）ＧＥＴ要求を受信することであって、前記複数のロング・ポールＨＴＴＰ要求が、前記複数のクラスタ化されたアプリケーションの複数の識別子を含む、受信することと、
   前記マイクロプロセッサによって、前記複数の識別子のそれぞれに基づいて、前記複数のクラスタ化されたアプリケーションのための複数のイベント・キューのそれぞれを作成することと、
   前記マイクロプロセッサによって、複数の通信セッションのそれぞれに基づいて、複数のイベントを前記複数のイベント・キューのそれぞれに追加することと、
   前記マイクロプロセッサによって、前記複数のイベント・キューにおける前記複数のイベントに基づいて、前記複数のイベントを含む、前記複数のロング・ポールＨＴＴＰ要求に対する複数の応答を送信することと
   を含む方法。
7. 前記マイクロプロセッサが、クラウド・サービスから、前記複数の通信セッションのうちの個々の通信セッションについてのイベントを含むＨＴＴＰ ＰＯＳＴを受信し、前記マイクロプロセッサが、前記複数の通信セッションのうちの前記個々の通信セッションの識別子を使用して、個々のクラスタ化されたアプリケーションのための個々のイベント・キューを識別し、前記ＨＴＴＰ ＰＯＳＴはまた、拡張マークアップ言語（ＸＭＬ）データおよびＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）データのうちの少なくとも１つを含み、前記ＸＭＬ／ＪＳＯＮデータの存在が、前記クラウド・サービスが前記個々のクラスタ化されたアプリケーションから、データを有する応答メッセージを予期していることを指し示す、請求項６に記載の方法。
8. 前記複数のイベント・キューのうちの個々のイベント・キューが、前記複数の通信セッションのうちの個々の通信セッションについての複数のイベントを含み、前記マイクロプロセッサが、前記個々の通信セッションについて送信するイベントの最大数に基づいて、前記複数のイベントを前記クラスタ化されたアプリケーションに単一のメッセージで送信すること、および前記個々の通信セッションについての前記イベント・キューにおける前記複数のイベントのうちの一部を単一のメッセージで送信することのうちの少なくとも１つを行う、請求項６に記載の方法。
9. 前記複数のイベント・キューが、第１のイベント・キューと第２のイベント・キューとを含み、前記第１のイベント・キューが、第１の通信セッションに関連付けられた複数のイベントを含み、前記第２のイベント・キューが、第２の通信セッションに関連付けられた複数のイベントを含み、前記第１のイベント・キューが、第１のＨＴＴＰ ＧＥＴ要求に応答して送信され得るイベントの第１の最大数を有し、前記第２のイベント・キューが、第２のＨＴＴＰ ＧＥＴ要求に応答して送信され得るイベントの第２の最大数を有し、イベントの前記第１の最大数が、イベントの前記第２の最大数とは異なる、請求項６に記載の方法。
10. 企業データ・センタをさらに含み、
    前記企業データ・センタが、前記複数のクラスタ化されたアプリケーションを含み、前記複数のクラスタ化されたアプリケーションが、
    前記複数のロング・ポールＨＴＴＰ要求を送信し、
    前記複数の応答を受信し、
    受信された複数の応答に基づいて、複数のアクションを実装する、
    請求項６に記載の方法。