JP6832347B2 - 分散型システムにおける多段階処理のためのイベント順序の保証 - Google Patents

Description

関連出願の相互参照
本願は、「分散型システムにおける多段階処理のためのイベント順序の保証（GUARANTEEING THE EVENT ORDER FOR MULTI-STAGE PROCESSING IN DISTRIBUTED SYSTEMS）」と題される２０１６年４月１１日に出願された米国特許出願番号第１５／０９５，７６６号からの優先権およびその利益を主張し、米国特許出願番号第１５／０９５，７６６号は、「分散型システムにおける多段階処理のためのイベント順序の保証（GUARANTEEING THE EVENT ORDER FOR MULTI-STAGE PROCESSING IN DISTRIBUTED SYSTEMS）」と題される２０１５年１０月２１日に出願された米国仮出願番号第６２／２４４，４５２号の非仮出願であり、米国特許法第１１９条（ｅ）のもとでその利益および優先権を主張し、どちらも内容全体が全ての目的で引用によって本明細書に援用される。

背景
従来のデータベースシステムでは、データは、通常はテーブルの形態の１つ以上のデータベースに格納される。格納されたデータは、次いで、構造化照会言語（structured query language：ＳＱＬ）などのデータ管理言語を使用して照会され操作される。たとえば、ＳＱＬクエリは、データベースに格納されたデータから関連データを識別するように定義され実行されてもよい。したがって、ＳＱＬクエリは、データベースに格納された有限のデータセットに対して実行される。さらに、ＳＱＬクエリが実行される場合、それは有限のデータセットに対して一度実行されて、有限の静的な結果を生成する。したがって、格納された有限のデータセットに対して照会を行うようにデータベースが最適に準備される。

しかし、多数の現代のアプリケーションおよびシステムは、有限のデータセットの代わりに、連続データまたはイベントストリームの形態のデータを生成する。このようなアプリケーションの例としては、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などが挙げられるが、それらに限定されるものではない。このようなアプリケーションは、データストリームを処理することができる新しいタイプのアプリケーションの必要性を生じさせてきた。たとえば、温度センサは、温度読取値を送信するように構成されてもよい。

これらのタイプのイベントストリームベースのアプリケーションのためのデータの管理および処理は、強力な時間的焦点を有するデータ管理および照会機能を構築することを必要とする。連続的な無限のデータセットに対して長期間照会を行うことを含む異なる種類の照会機構が必要である。イベントストリーム処理に適合した製品一式を提供しているベンダもいるが、これらの製品提供は、依然として、今日のイベント処理ニーズに対処するのに必要な処理柔軟性が欠如している。

概要
本開示の以下の部分は、少なくとも主題を基本的に理解できるようにする目的で、本開示に記載されている１つ以上の革新的技術、実施形態および／または実施例の簡略化された概要を提供する。この概要は、いずれかの特定の実施形態または実施例の広範囲にわたる概略を提供しようとしているわけではない。また、この概要は、ある実施形態または実施例の重要な／不可欠な要素を識別することを意図したものではなく、または本開示の主題の範囲を図示することを意図したものでもない。したがって、この概要の１つの目的は、簡略化した形で本開示に記載されているいくつかの革新的技術、実施形態および／または実施例を、以下に記載するより詳細な説明に対する前置きとして提供することであり得る。

本開示の主題の本質および等価物（ならびに、提供されるいずれの固有のまたは明確な利点および改良点も）のさらなる理解は、上記の段落に加えて、本開示の残りの部分、添付の図面および特許請求の範囲を参照することによって実現されるべきである。

いくつかの例では、方法、システム、およびコンピュータ読取可能な媒体が提供され得る。上記方法、システムおよび／またはコンピュータ読取可能な媒体は、イベントストリームの一部として受信される一連のイベントのうちの第１のイベントを判断すること、上記第１のイベントのタイムスタンプを有するイベントカウンタの値を初期化すること、および／または、上記イベントストリームのさらに他のイベントを処理することを備え得る。さらに他のイベントは、上記第１のイベント以外の、上記一連のイベントのうちのいずれかのイベントを含み得る。いくつかの例は、上記方法、システムおよび／またはコンピュータ読取可能な媒体は、上記イベントストリームのフィルタリングされたイベントを識別すること、上記フィルタリングされたイベントのためのスキップビートを生成すること、および／または、上記スキップビートを上記イベントストリームに挿入することも備え得る。さらに、いくつかの例では、上記方法、システムおよび／またはコンピュータ読取可能な媒体は、上記イベントストリームの後続のイベントを受信すること、上記イベントストリームの順序が狂ったイベントを識別すること、および／または、上記イベントストリームにおける次のイベントが実際のイベントであるかスキップビートであるかに関係なく、上記後続のイベントの各々に関連付けられた上記タイムスタンプの順序で後続のイベントを処理することも備え得る。後続のイベントは、上記スキップビートの挿入後に上記イベントストリームの一部として受信される、上記一連のイベントのうちのいずれかのイベントを含み得る。いくつかの例では、上記方法、システムおよび／またはコンピュータ読取可能な媒体は、タイマを開始すること、上記タイマが時間切れになるまで上記一連のイベントのうちの一組のイベントを受信すること、上記一組のイベントを時系列順に再配列すること、および上記第１のイベントを、最新のタイムスタンプを有する上記再配列された組のイベントとして識別すること、によって上記第１のイベントを判断することも備え得る。さらに他のイベントは、上記タイマが時間切れになる前にバッチ処理され得る。上記フィルタリングされたイベントは、上流の段階によってフィルタリングにより除去され得る。上記実際のイベントは、上記イベントストリームに対応するイベントデータを備え得る。

本開示に記載されている革新的技術、実施形態および／または実施例を合理的に説明し図示するために、１つ以上の添付の図面を参照し得る。１つ以上の添付の図面を説明するために使用されるさらなる詳細または例は、記載されている開示のいずれの範囲に対しても、ここに記載されている実施形態および／または実施例のいずれの範囲に対しても、または本開示に提示されている、現在のところ最良の形態であると理解されている革新的技術のいずれの範囲に対しても、限定として考えられるべきではない。

本開示の実施形態を組み込むことができるシステムの簡略図である。 本開示の実施形態を実現するための詳細の簡略ブロック図である。 本開示の実施形態を実現するための方法のフローチャートである。 本開示の実施形態を実現するための方法のフローチャートである。 本開示の実施形態を実現するための方法のフローチャートである。 本明細書に記載されている例のうちのいくつか実現するための、少なくとも１つの例に係る分散型システムの簡略図である。 本明細書に記載されている例のうちのいくつかに従って実施形態のシステムのコンポーネントによって提供されるサービスをクラウドサービスとして提供することができる、少なくとも１つの例に係るシステム環境のコンポーネントの簡略ブロック図である。 本明細書に記載されている例のうちのいくつかに従って本開示のさまざまな実施形態を実現することができる、少なくとも１つの例に係る例示的なコンピュータシステムを示す。

詳細な説明
複合イベント処理プラットフォームでは、正確な結果を達成するために、アプリケーションタイムスタンプの順序でイベントを処理すべきである。イベント「ａ」がイベント「ｂ」の前にアプリケーションによって生成された場合、イベント「ａ」は、「ｂ」の前に処理されるべきである。たとえば、現在の温度が以前の温度よりも高いデバイスを識別するために、データをデバイスＩＤによってパーティション化して順番に処理すべきである。いくつかの例では、現在のデータと以前のデータとの間の相違は、それらのイベントのタイムスタンプによって定義される。データが単一の時点から取り込まれるシステムでは、イベントの順序付けされた処理を確実にすることは、比較的容易である。たとえば、イベントのパーティション番号を識別してもよく、処理のためのパーティションに特有の待ち行列上にイベントを配置してもよい。しかし、分散型システムでは、特にデータがクラスタ内の任意のノードから取り込まれる場合に、イベントの順序付けされた処理は非常に複雑になる。場合によっては、順序付けされた処理を確実にするためにいくつかの出来事が起こらなければならない。（１）第一に、正しいシーケンス番号またはタイムスタンプを有する開始カウンタが初期化されるべきである。（２）第二に、順序が狂った状態でイベントが到着したか否かが検出されるべきである。（３）第三に、バッファリングされたがまだ処理されていないイベントが再配列されるべきである。（４）最後に、順序が狂った古いイベントが到着するのをいつまでも待つことがないように、いつ次に進むかが判断されるべきである。これは多段階処理に特に当てはまるであろう。なぜなら、それらはパイプライン内の前の処理段階によってフィルタリングにより除去された可能性があるからである。ウォームアップおよびスキップビートの技術によって、本開示は、イベントを順番に処理するための例、およびいくつかの例では、たとえ処理が複数の段階を伴うとしてもイベントが発生順に処理されることを保証するための例を提供する。

いくつかの例では、本開示の１つの特徴は、システム起動の冒頭におよびシステム起動時に、後続のイベントを明らかにするというものである。これは、ウォームアップ局面と呼ぶことができる。いくつかの例では、システムがまさに最初のイベントを受信するとクロックが開始され、クロックまたはタイマが時間切れになるまでイベントが収集される。タイマが時間切れになった後、イベントは再配列され、最高／最新のタイムスタンプを有するイベントを使用して、カウンタ「LAST_SEEN_TiMESTAMP」の値を初期化し、カウンタ「NEXT_EXPECTED_TIMESTAMP」は、LAST_SEEN_TiMESTAMP＋１に設定される。バッチ処理されたイベントが処理され、ウォームアップ局面が完了する。ウォームアップ局面後、上記の２つのカウンタを使用して順序付けが厳密に実施される。

本開示の別の特徴は、フィルタリングされたイベントと同一のタイムスタンプを使用してスキップビートを作動させるというものである。多段階処理では、上流の段階によってイベントがフィルタリングにより除去される可能性がある。このような場合、フィルタリングされたイベントは到着することがないので、処理システム（たとえば、複合イベント処理（ＣＥＰ）エンジン）は、いつまでも待つべきではなく、イベント順序付けを試みるべきである。上流の段階は、さまざまな方法でおよび／またはさまざまな理由でストリームのイベントをフィルタリングにより除去する可能性がある。いずれのイベントにおいても、イベントは、一旦フィルタリングにより除去されると、もはやストリームにおける一連のイベントの一部ではなくなってしまう。したがって、フィルタリングが行われた後は、パイプラインのどの段階にもイベントが到着することはないであろう（たとえば、イベントはＣＥＰエンジンに到着することはできない）。このような場合に対処するために、フィルタリングされたアプリケーションと同一のタイムスタンプを有するスキップビートを生成することができ、システムは、当該スキップビートを全ての下流の段階に伝搬させることができる。次いで、実際のイベントの代わりに当該スキップビートを使用して、多段階処理を展開するアプリケーションにおける順序付けを保証する。上記のウォームアップ局面が完了すると、入来イベントは正確な順序で処理することができる（たとえば、後続のイベントは、当該後続のイベントの各々に関連付けられたタイムスタンプの順序で処理される）。このようにして、以下の論理を使用して、後続のイベントの順序付けされた処理が保証される。

「NEXT_EXPECTED_TIMESTAMP」と同一のタイムスタンプを有する実際のイベントまたは「スキップビート」が到着すると、LAST_SEEN_TIMESTAMPは、NEXT_EXPECTED_TIMESTAMPの値を割り当てられ、NEXT_EXPECTED_TIMESTAMPはインクリメントされる。

NEXT_EXPECTED_TIMESTAMPよりも高いタイムスタンプを有する「スキップビート」または「実際のイベント」が到着すると、当該イベントはバッファに追加され、予め構成された時間切れ間隔を有するタイマが開始され、以下の動作が実施される。
・タイマが実行し続けるにつれて、NEXT_EXPECTED_TIMESTAMPよりも高いタイムスタンプを有するより多くの入来イベントまたはスキップビートがバッファリングされる。
・NEXT_EXPECTED_TIMESTAMPと同一のタイムスタンプを有する入来イベントまたはスキップビートが到着すると、タイマがオフにされ、バッファ内のイベントが再配列されて処理される。スキップビートは伝搬し続けることに留意されたい。
・NEXT_EXPECTED_TIMESTAMPよりも低いタイムスタンプを有する入来イベントまたはスキップビートが到着すると、当該イベントまたはビートは帯域外であるとして廃棄される。やはり、ウォームアップ局面の長さを長くすることにより、このシナリオの可能性を減少させることができる。
・タイマが時間切れになると、スキップビートの伝搬を継続しながら、バッファリングされたイベントが再配列されて処理される。

これらの技術により、カウンタの適切な初期化が可能であり、処理パイプライン内の上流の段階によってフィルタリングされ得るイベントが明らかにされる。

いくつかの例では、クエリは、イベントが前のイベントに対して高いか低いかを判断するタスクを備え得る。たとえば、温度がこの１時間（または、その他の期間）で上昇したか否かである。しかし、この質問に正確に答えるためには、（たとえば、温度に関連する）イベントを、当該イベントが生成された順序と同一の順序で処理しなければならない。これは、単一プロセッサシステムまたはデータが単一の時点から取り込まれるシステムでは、単に入来する通りにイベントを待ち行列に入れてそれらを順番に処理することによって、比較的容易にできる。しかし、分散型システムでは、イベントは、イベントプロセッサに到着する前に複数のノードを通過するため、順序が狂う可能性がある。

記載するように、１つの解決策は、イベントプロセッサが正確な始点を有するように正確な値で開始カウンタを初期化するというものである。さもなければ、システムが起動するときに（たとえば、再始動または再起動後に）、イベントプロセッサが正確な値で始動することになることを想定できない。したがって、システムが起動したときに、ウォームアップ期間を使用して、どのイベントが適切な開始イベントであるかを判断することができる。次いで、この開始イベントを使用して、配列を開始させることができる。次いで、イベントの処理が開始すると、システムは、あるものがいつ順序が狂うかを検出できる必要がある。場合によっては、イベントが順序が狂っていると判断されると、イベントは再順序付けされなければならない。しかし、順序が狂ったイベントがいつか到着することを保証することは、必ずしも可能であるとは限らない。たとえば、場合によっては、イベントは、分散型システムにおける前のノードまたはプロセスによってフィルタリングにより除去されているかもしれない。

いくつかの例では、イベントプロセッサが特定のイベントを待たなくてもいいことを示すために「スキップビート」（たとえば、システム中に伝搬されるダミーイベント）が使用される。たとえば、スキップビートは、イベントが到着することがないことを示してもよい。場合によっては、イベントが前のノードによってフィルタリングにより除去されている場合、適切なタイムスタンプ（たとえば、フィルタリングされたイベントに対応していたタイムスタンプと同一のタイムスタンプ）を有するストリームに「スキップビート」が挿入され得る。下流のプロセッサが当該「スキップビート」を受信すると、それは見つからないイベント（たとえば、順序が狂っているように見えるイベントのうちの、プロセッサが待っているイベント）として処理され、次のイベントが検出されると、プロセッサは、次のイベントの処理に移ることになる。いくつかの例では、イベントは、前のノードにおいて処理される条件によって、フィルタリングにより除去され場合がある。たとえば、特定の閾値を上回る（たとえば、７０度を超える、など）温度上昇をクエリが識別しているのみであれば、６０度未満の温度に関連付けられたイベントは全てフィルタリングにより除去されてもよい。イベントがフィルタリングにより除去されると、フィルタリングされたイベントの代わりに、「スキップビート」がストリームに挿入され得る。イベントプロセッサは、当該「スキップビート」を識別すると、上記のイベントを待つことをやめる。「スキップビート」イベントは、タイムスタンプ情報のみを含む空イベントを作成することによって生成され得る。空イベントを生成する際に、タプルは、フィルタリングされたイベントのタイムスタンプを含み得る。

イベントプロセッサは、どのイベントが上流でフィルタリングにより除去されたかが分からない可能性がある。そのため、イベントプロセッサは、「スキップビート」イベントを聞き取る場合、どのイベントを順番に処理しなくてもよいか（または、この場合、どのイベントも順番に処理しなくてもよいこと）が分かる。上記のように、「スキップビート」イベントは、本質的に、実際のイベントの代わりのダミーイベントである。そのため、本質的には、イベントプロセッサが正確な順序付けされたイベント処理を保証できるようにしたければ、システムは、少なくとも上記のウォームアップ期間および「スキップビート」の使用を利用しなければならない。また、イベントがいつ順序が狂うかを検出できることが重要であろう。

いくつかの例では、分散型システムにおいて多段階処理のためのイベント順序を保証する機構が提供され得る。一般に、連続的なデータストリーム（イベントストリームとも称される）は、明確な終端を持たない、本来は連続的または無限であり得るデータまたはイベントのストリームを含み得る。論理的には、イベントまたはデータストリームは、一連のデータ要素（イベントとも称される）であり得て、各データ要素は、関連付けられたタイムスタンプを有する。連続的なイベントストリームは、論理的には、一袋または一組の要素（ｓ，Ｔ）として表現され得て、「ｓ」はデータ部分を表わし、「Ｔ」は時間領域内にある。「ｓ」部分は、一般にタプルまたはイベントと称される。したがって、イベントストリームは、一連のタイムスタンプ付きタプルまたはイベントであり得る。

いくつかの局面では、ストリームにおけるイベントに関連付けられたタイムスタンプは、クロックタイムと同一であってもよい。しかし、他の例では、イベントストリームにおけるイベントに関連付けられた時間は、アプリケーションドメインによって定義されてもよく、クロックタイムに対応しているのではなくたとえば代わりにシーケンス番号によって表わされてもよい。したがって、イベントストリームにおけるイベントに関連付けられた時間情報は、番号、タイムスタンプ、または時間の概念を表わすその他の情報によって表わすことができる。入力イベントストリームを受信するシステムでは、イベントは、タイムスタンプが増加する順にシステムに到着する。同一のタイムスタンプを有する２つ以上のイベントがある場合もある。

いくつかの例では、イベントストリームにおけるイベントは、何らかの世俗的なイベントの発生（たとえば、いつ温度センサが値を新たな値に変更したか、いつ株式銘柄の価格が変化したか）を表わし得て、イベントに関連付けられた時間情報は、データストリームイベントによって表わされる世俗的なイベントがいつ発生したかを示し得る。

イベントがイベントストリームを介して受信される場合、イベントに関連付けられた時間情報を使用して、当該イベントストリームにおけるイベントが、タイムスタンプ値が増加する順に到着することを保証し得る。これにより、イベントストリームにおける受信したイベントは、それらの関連付けられた時間情報に基づいて順序付けすることが可能になり得る。この順序付けを可能にするために、後に生成されるイベントが前に生成されるイベントよりも遅いタイムスタンプを有するように、タイムスタンプは、減少しない態様でイベントストリームにおけるイベントに関連付けられ得る。別の例として、時間情報としてシーケンス番号が使用されている場合には、後に生成されるイベントに関連付けられたシーケンス番号は、前に生成されるイベントに関連付けられたシーケンス番号よりも大きくてもよい。いくつかの例では、たとえばデータストリームイベントによって表わされる世俗的なイベントが同時に発生する場合、複数のイベントが同一のタイムスタンプまたはシーケンス番号に関連付けられてもよい。同一のイベントストリームに属するイベントは、一般に、前のイベントが後のイベントよりも前に処理される状態で、関連付けられた時間情報によってイベントに対して課される順序で処理され得る。

イベントストリームにおけるイベントに関連付けられた時間情報（たとえば、タイムスタンプ）は、ストリームのソースによって設定されてもよく、または代替的に、ストリームを受信するシステムによって設定されてもよい。たとえば、特定の実施形態では、イベントストリームを受信するシステム上でハートビートが維持されてもよく、イベントに関連付けられた時間は、当該ハートビートによって測定されるシステムへのイベントの到着時間に基づいてもよい。イベントストリームにおける２つのイベントが同一の時間情報を有することが可能である。なお、タイムスタンプ順序付け要件は１つのイベントストリームに特有であるが、異なるストリームのイベントを任意にさしはさんでもよい。

イベントストリームは、関連付けられたスキーマ「Ｓ」を有し、当該スキーマは、時間情報と、一組の１つ以上の名前付き属性とを備える。特定のイベントストリームに属する全てのイベントは、当該特定のイベントストリームに関連付けられたスキーマに一致する。したがって、イベントストリーム（ｓ，Ｔ）では、イベントストリームは、（<time_stamp>, <attribute(s)>）としてスキーマ「Ｓ」を有し得て、<attributes>は、スキーマのデータ部分を表わし、１つ以上の属性を備え得る。たとえば、株式相場表示機イベントストリームのためのスキーマは、属性<stock symbol>および<stock price>を備えていてもよい。このようなストリームを介して受信した各イベントは、タイムスタンプと、２つの属性を有することになる。たとえば、株式相場表示機イベントストリームは、以下のイベントおよび関連付けられたタイムスタンプを受信し得る。

上記のストリームにおいて、ストリーム要素（<timestamp_N+l>, <ORCL,62>）では、イベントは、属性「stock_symbol」および「stock_value」を有する<ORCL,62>である。当該ストリーム要素に関連付けられたタイムスタンプは、「timestamp_N+l」である。したがって、連続的なイベントストリームはイベントのフローであり、各イベントは同一の一連の属性を有する。

上記のように、ストリームは、ＣＱＬクエリが作用し得る原理データソースであり得る。ストリームＳは、一袋の（「複数組の」とも称される）要素（ｓ，Ｔ）であり得て、「ｓ」はスキーマＳ内にあり、「Ｔ」は時間領域内にある。さらに、ストリーム要素は、一連のタイムスタンプ付きタプル挿入として表わすことができるタプル・タイムスタンプ対であり得る。言い換えれば、ストリームは、一連のタイムスタンプ付きタプルであり得る。場合によっては、同一のタイムスタンプを有する２つ以上のタプルがあってもよい。そして、入力ストリームのタプルは、タイムスタンプが増加する順にシステムに到着することを要求され得る。代替的に、関係（「時間変化関係」とも称され、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同すべきではない）は、時間領域からスキーマＲのタプルの無限の集合へのマッピングであってもよい。いくつかの例では、関係は、タプルの順序付けされていない、時間変化的な集合（すなわち、瞬間的な関係）であってもよい。場合によっては、時間の各インスタンスにおいて、関係は、有界集合であってもよい。また、関係は、関係の変化する状態を取り込むための挿入、削除および／または更新を含み得る一連のタイムスタンプ付きタプルとして表わすこともできる。ストリームと同様に、関係は、関係の各タプルが一致し得る固定のスキーマを有し得る。さらに、本明細書では、連続クエリは、一般に、ストリームおよび／または関係の（すなわち、ストリームおよび／または関係に対して照会される）データを処理することが可能であり得る。また、関係は、ストリームのデータを参照し得る。

いくつかの例では、ビジネスインテリジェンス（business intelligence：ＢＩ）が、特定の間隔で（たとえば、場合によっては毎日）ビジネス活動を駆動して最適化することを手助けし得る。このタイプのＢＩは、通常、オペレーショナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンス、またはオペレーショナルインテリジェンス（ＯＩ）と呼ばれる。いくつかの例では、オペレーショナルインテリジェンスは、ＢＩ間の回線およびビジネスアクティビティ監視（business activity monitoring：ＢＡＭ）を曖昧にする。たとえば、ＢＩは、履歴データの定期的なクエリに焦点を合わせてもよい。したがって、それは、後ろ向きの焦点を有し得る。しかし、ＢＩは、オペレーショナルアプリケーションにも配置され得て、そのため、単なる戦略分析ツールからビジネス活動の前線に拡大することができる。したがって、ＢＩシステムは、リアルタイムでイベントストリームを分析して総計を計算するようにも構成され得る。

さらに、いくつかの例では、ＯＩは、可視性およびビジネス活動への洞察を提供することができる一種のリアルタイムの動的ビジネス解析である。ＯＩは、ＢＩもリアルタイムＢＩも大量の情報を理解することを手助けするという意味で、しばしばＢＩまたはリアルタイムＢＩに結び付けられて比較される。しかし、いくつかの基本的な違いがある。すなわち、ＯＩは主にアクティビティ中心であるのに対して、ＢＩは主にデータ中心である、というものである。さらに、ＯＩは、事後の、報告ベースのパターン識別アプローチとして従来から使用されているＢＩとは異なって、展開中の状況（たとえば、トレンドおよびパターン）を検出して応答することにさらに適しているであろう。

いくつかの例では、ビジネスイベント分析および監視（business event analysis and monitoring：ＢＥＡＭ）システムは、流れている（in-flight）データを処理および／または受信するためにＣＱＬエンジンを含み得る。たとえば、ＣＱＬエンジンは、入来リアルタイム情報に照会するか、またはそうでなければ入来リアルタイム情報を処理するように構成されたインメモリリアルタイムイベント処理エンジン（たとえば、ＢＩまたはＯＩ）であってもよい。ＣＱＬエンジンは、時間意味論を利用または理解して、データのウィンドウの定義を処理することを可能にするように構成され得る。場合によっては、ＣＱＬエンジンを利用することは、入来データに対して常に照会することを含み得る。

いくつかの局面では、ＣＱＬエンジンは、本格的な照会言語を含み得る。したがって、ユーザは、クエリの観点から計算を指定し得る。さらに、ＣＱＬエンジンは、照会言語特徴、オペレータ共有、豊かなパターンマッチング、豊かな言語構造などを利用してメモリを最適化するように設計され得る。さらに、いくつかの例では、ＣＱＬエンジンは、履歴データもストリーミングデータも処理し得る。たとえば、ユーザは、カリフォルニアセールスが特定の目標値を上回ると警告を送信するようにクエリを設定してもよい。したがって、いくつかの例では、当該警告は、少なくとも一部には履歴販売データおよび入来ライブ（すなわち、リアルタイム）販売データに基づき得る。

いくつかの例では、ＣＱＬエンジンまたは以下で説明する概念の他の特徴は、リアルタイムの態様で履歴文脈（すなわち、倉庫データ）と入来データとを組み合わせるように構成され得る。したがって、場合によっては、本開示は、データベース格納情報および流れている情報の境界について説明することができる。データベース格納情報も流れている情報もＢＩデータを含み得る。したがって、いくつかの例では、データベースは、ＢＩサーバであってもよく、またはいずれかのタイプのデータベースであってもよい。さらに、いくつかの例では、本開示の特徴は、どのようにしてコードをプログラムするか、またはそうでなければどのようにしてコードを書込むかをユーザが知らなくても、上記の特徴を実現することを可能にし得る。言い換えれば、当該特徴は、非開発者が履歴データとリアルタイムデータとの組み合わせを実現することを可能にする機能豊富なユーザインターフェイス（ＵＩ）または他の態様で提供され得る。

上記および下記の技術は、多くの方法でおよび多くの文脈で実現することができる。以下でさらに詳細に説明するように、以下の図面を参照していくつかの例示的な実現例および文脈を提供する。しかし、以下の実現例および文脈は、多くのもののうちのいくつかに過ぎない。

図１は、イベント順序を保証するための技術を実現することができる簡略化された例示的なシステムまたはアーキテクチャ１００を示す。アーキテクチャ１００では、１人以上のユーザ１０２（たとえば、アカウント所有者）は、ユーザコンピューティングデバイス１０４（１）〜（Ｎ）（まとめて「ユーザデバイス１０４」）を利用して、１つ以上のネットワーク１０８を介して１つ以上のサービスプロバイダコンピュータ１０６にアクセスし得る。また、いくつかの局面では、サービスプロバイダコンピュータ１０６は、ネットワーク１０８を介して１つ以上のストリーミングデータソースコンピュータ１１０および／または１つ以上のデータベース１１２と通信し得る。たとえば、ユーザ１０２は、サービスプロバイダコンピュータ１０６を利用して、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２のデータにアクセスするか、またはそうでなければ当該データを管理してもよい（たとえば、１１０，１１２のいずれかまたは両方に対して照会が行われてもよい）。データベース１１２は、リレーショナルデータベース、ＳＱＬサーバなどであってもよく、いくつかの例では、ユーザ１０２の代わりに履歴データ、イベントデータ、関係、アーカイブされた関係などを管理し得る。さらに、データベース１１２は、ストリーミングデータソースコンピュータ１１０によって提供されるデータを受信するか、またはそうでなければ格納し得る。いくつかの例では、ユーザ１０２は、ユーザデバイス１０４を利用して、データ（たとえば、履歴イベントデータ、ストリーミングイベントデータなど）に対するクエリ（「クエリステートメント」とも称される）または他の要求を提供することによってサービスプロバイダコンピュータ１０６と対話し得る。次いで、このようなクエリまたは要求は、サービスプロバイダコンピュータ１０６によって実行されて、データベース１１２のデータおよび／またはストリーミングデータソースコンピュータ１１０からの入来データを処理し得る。さらに、いくつかの例では、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２は、サービスプロバイダコンピュータ１０６に関連付けられた統合分散環境の一部であってもよい。

いくつかの例では、ネットワーク１０８は、ケーブルネットワーク、インターネット、無線ネットワーク、セルラーネットワーク、イントラネットシステム、ならびに／または、他の私的ネットワークおよび／もしくは公共ネットワークなどの複数の異なるタイプのネットワークのいずれか１つまたは組み合わせを含み得る。示されている例は、ユーザ１０２がネットワーク１０８を介してサービスプロバイダコンピュータ１０６にアクセスすることを示しているが、記載されている技術は、ユーザ１０２が固定電話を介して、キオスクを介して、またはその他の態様で１つ以上のユーザデバイス１０４を介して１つ以上のサービスプロバイダコンピュータ１０６と対話する場合に等しく適用することができる。なお、また、記載されている技術は、他のクライアント／サーバ構成（たとえば、セットトップボックスなど）および非クライアント／サーバ構成（たとえば、ローカルに格納されたアプリケーションなど）において適用することもできる。

ユーザデバイス１０４は、携帯電話、スマートフォン、携帯情報端末（personal digital assistant：ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、シンクライアントデバイス、タブレットＰＣなどであるがそれらに限定されないいずれかのタイプのコンピューティングデバイスであってもよい。いくつかの例では、ユーザデバイス１０４は、ネットワーク１０８を介して、または他のネットワーク接続を介して、サービスプロバイダコンピュータ１０６と通信し得る。さらに、ユーザデバイス１０４は、処理すべきデータベース１１２（または、他のデータストア）のデータを要求するための１つ以上のクエリまたはクエリステートメントを提供するようにも構成され得る。

また、いくつかの局面では、サービスプロバイダコンピュータ１０６は、サーバなどの、モバイルコンピューティングデバイス、デスクトップコンピューティングデバイス、シンクライアントコンピューティングデバイスおよび／またはクラウドコンピューティングデバイスなどであるがそれらに限定されないいずれかのタイプのコンピューティングデバイスであってもよい。いくつかの例では、サービスプロバイダコンピュータ１０６は、ネットワーク１０８を介して、または他のネットワーク接続を介して、ユーザデバイス１０４と通信し得る。サービスプロバイダコンピュータ１０６は、サーバファームとして、または互いに関連付けられない個々のサーバとして、恐らくクラスタ状態で配置された１つ以上のサーバを含み得る。これらのサーバは、本明細書に記載されている特徴を実行するか、またはそうでなければ提供するように構成され得て、本明細書に記載されている特徴は、アーカイブされた関係の管理、アーカイブされた関係に関連付けられた構成可能なデータウィンドウ、および／または、本明細書に記載されているアーカイブされた関係の管理に関連付けられた変更イベントの正確な集計を含むが、それらに限定されるものではない。さらに、いくつかの局面では、サービスプロバイダコンピュータ１０６は、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２を含む統合分散コンピューティング環境の一部として構成され得る。

１つの例示的な構成では、サービスプロバイダコンピュータ１０６は、少なくとも１つのメモリ１３６と、１つ以上の処理ユニット（または、プロセッサ）１３８とを含み得る。プロセッサ１３８は、ハードウェア、コンピュータによって実行可能な命令、ファームウェア、またはそれらの組み合わせで適宜実現され得る。プロセッサ１３８のコンピュータによって実行可能な命令またはファームウェア実現例は、記載されているさまざまな機能を実行するために、任意の好適なプログラミング言語で書かれた、コンピュータによって実行可能なまたはマシンによって実行可能な命令を含み得る。

メモリ１３６は、プロセッサ１３８上でロード可能であり実行可能であるプログラム命令、および、これらのプログラムの実行中に生成されるデータを格納し得る。サービスプロバイダコンピュータ１０６の構成およびタイプに応じて、メモリ１３６は、揮発性であってもよく（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）、および／または、不揮発性であってもよい（リードオンリメモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）。サービスプロバイダコンピュータ１０６またはサーバは、リムーバブルストレージおよび／または非リムーバブルストレージを含み得るさらに他のストレージ１４０も含み得る。さらに他のストレージ１４０は、磁気ストレージ、光ディスクおよび／またはテープストレージを含み得るが、それらに限定されるものではない。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、およびコンピューティングデバイスのための他のデータの不揮発性ストレージを提供し得る。いくつかの実現例では、メモリ１３６は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）またはＲＯＭなどの複数の異なるタイプのメモリを含み得る。

メモリ１３６、さらに他のストレージ１４０は、全て、リムーバブルなものも非リムーバブルなものも、コンピュータ読取可能な記憶媒体の例である。たとえば、コンピュータ読取可能な記憶媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の格納のためのいずれかの方法または技術で実現される揮発性または不揮発性の、リムーバブルまたは非リムーバブルな媒体を含み得る。メモリ１３６およびさらに他のストレージ１４０は全て、コンピュータ記憶媒体の例である。

サービスプロバイダコンピュータ１０６は、アイデンティティインターフェイスコンピュータ１２０が、格納されたデータベース、別のコンピューティングデバイスまたはサーバ、ユーザ端末、および／または、ネットワーク１０８上の他のデバイスと通信することを可能にする通信接続１４２も含み得る。サービスプロバイダコンピュータ１０６は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、ディスプレイ、１つ以上のスピーカ、プリンタなどの入力／出力（Ｉ／Ｏ）デバイス１４４も含み得る。

メモリ１３６のコンテンツをさらに詳細に見てみると、メモリ１３６は、オペレーティングシステム１４６と、本明細書に開示されている特徴を実現するための１つ以上のアプリケーションプログラムまたはサービスとを含み得て、本明細書に開示されている特徴は、少なくとも、ウォームアップモジュール１４８、（たとえば、レスリー・ランポートアルゴリズムなどを利用した）順序狂い検出モジュール１５０、および／または、スキップビートモジュール１５２を含む。ウォームアップモジュール１４８は、上記のウォームアップ期間を可能にするように構成され得る。順序狂い検出モジュール１５０は、イベントを受信したときに順序が狂ったイベントの検出を可能にするように構成され得る。そして、スキップビートモジュール１５２は、いつイベントがフィルタリングにより除去されたかを判断して、スキップビートを生成し、それらを適宜ストリームに挿入するように構成され得る。本明細書では、モジュールは、サービスの一部である、サーバまたはサーバのクラスタによって実行されるプログラミングモジュールを指し得る。この特定の文脈において、モジュールは、サービスプロバイダコンピュータ１０６の一部であるサーバまたはサーバのクラスタによって実行され得る。

図２は、本開示の実施形態を組み込むことができるイベント処理システム２００の簡略化されたハイレベル図を示す。イベント処理システム２００は、１つ以上のイベントソース（２０４，２０６，２０８）と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバ（ＥＰＳ）２０２（ＣＱサービス２０２とも称される）と、１つ以上のイベントシンク（２１０，２１２）とを備え得る。イベントソースは、ＥＰＳ２０２によって受信されるイベントストリームを生成する。ＥＰＳ２０２は、１つ以上のイベントソースから１つ以上のイベントストリームを受信し得る。たとえば、図２に示されるように、ＥＰＳ２０２は、イベントソース２０４から入力イベントストリーム２１４を受信し、イベントソース２０６から第２の入力イベントストリーム２１６を受信し、イベントソース２０８から第３のイベントストリーム２１８を受信する。１つ以上のイベント処理アプリケーション（２２０，２２２および２２４）がＥＰＳ２０２上にデプロイされてＥＰＳ２０２によって実行され得る。ＥＰＳ２０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームを聞き取り、注目すべきイベントとして入力イベントストリームから１つ以上のイベントを選択する処理論理に基づいて、１つ以上のイベントストリームを介して受信したイベントを処理するように構成され得る。次いで、当該注目すべきイベントは、１つ以上の出力イベントストリームの形態で１つ以上のイベントシンク（２１０，２１２）に送信され得る。たとえば、図２では、ＥＰＳ２０２は、出力イベントストリーム２２６をイベントシンク２１０に出力し、第２の出力イベントストリーム２２８をイベントシンク２１２に出力する。特定の実施形態では、イベントソース、イベント処理アプリケーションおよびイベントシンクは、他のコンポーネントに対する変更を生じさせることなくこれらのコンポーネントのうちのいずれかを追加または除去することができるように互いに分離される。

一実施形態では、ＥＰＳ２０２は、共有サービスを有する、Equinox OSGiに基づくものなどの軽量Ｊａｖａ（登録商標）アプリケーションコンテナを備えるＪａｖａサーバとして実現され得る。いくつかの実施形態では、ＥＰＳ２０２は、たとえばJRockit Real Timeを使用してイベントを処理するための超高スループットおよびマイクロ秒待ち時間をサポートし得る。また、ＥＰＳ２０２は、イベント処理アプリケーションを開発するためのツール（たとえば、オラクルＣＥＰビジュアライザおよびオラクルＣＥＰ ＩＤＥ）を含む開発プラットフォーム（たとえば、完全なリアルタイムのエンドツーエンドＪａｖａイベント駆動アーキテクチャ（Event-Driven Architecture：ＥＤＡ）開発プラットフォーム）を提供し得る。

イベント処理アプリケーションは、１つ以上の入力イベントストリームを聞き取って、１つ以上の入力イベントストリームから１つ以上の注目すべきイベントを選択するための論理（たとえば、クエリ）を実行し、選択された注目すべきイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントソースに出力するように構成される。図２は、１つのこのようなイベント処理アプリケーション２２０のためのドリルダウンを提供する。図２に示されるように、イベント処理アプリケーション２２０は、入力イベントストリーム２１８を聞き取って、入力イベントストリーム２１８から１つ以上の注目すべきイベントを選択するための論理を備えるクエリ２３０を実行し、選択された注目すべきイベントを出力イベントストリーム２２８を介してイベントシンク２１２に出力するように構成される。イベントソースの例としては、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰおよびファイル）、チャネル、プロセッサ、テーブル、キャッシュなどが挙げられるが、それらに限定されるものではない。イベントシンクの例としては、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰおよびファイル）、チャネル、プロセッサ、キャッシュなどが挙げられるが、それらに限定されるものではない。

図２におけるイベント処理アプリケーション２２０は、１つの入力ストリームを聞き取って、選択されたイベントを１つの出力ストリームを介して出力するものとして示されているが、これは限定的であるよう意図されるものではない。代替的な実施形態では、イベント処理アプリケーションは、１つ以上のイベントソースから受信した複数の入力ストリームを聞き取って、監視されたストリームからイベントを選択し、選択されたイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントシンクに出力するように構成され得る。同一のクエリを２つ以上のイベントシンクおよび異なるタイプのイベントシンクに関連付けることができる。

無限の性質のために、イベントストリームを介して受信されるデータの量は、一般に非常に多い。その結果、照会目的で全てのデータを格納またはアーカイブすることは、一般に非現実的であり、望ましくない。イベントストリームの処理は、受信した全てのイベントデータを格納する必要なしにイベントがＥＰＳ２０２によって受信されるときにリアルタイムでイベントの処理を必要とする。したがって、ＥＰＳ２０２は、受信した全てのイベントを格納する必要なしにイベントがＥＰＳ２０２によって受信されるときにイベントの処理を実行することを可能にする特別な照会機構を提供する。

イベント駆動アプリケーションは、ルール駆動であり、これらのルールは、入力ストリームを処理するために使用される連続クエリの形態で表現され得る。連続クエリは、クエリ処理の結果として、どのイベントを注目すべきイベントとして選択して出力すべきかを含む、受信したイベントに対して実行される処理を識別する命令（たとえば、ビジネス論理）を備え得る。連続クエリは、データストアに留まって、イベントの入力ストリームの処理およびイベントの出力ストリームの生成に使用され得る。連続クエリは、一般に、フィルタリングおよび集約機能を実行して、入力イベントストリームから注目すべきイベントを発見して抽出する。その結果、出力イベントストリームにおける送信イベントの数は、一般に、イベントが選択される入力イベントストリームにおけるイベントの数よりもはるかに少なくなる。

有限のデータセットに対して一度実行されるＳＱＬクエリとは異なって、ＥＰＳ２０２を有するアプリケーションによって特定のイベントストリームのために登録された連続クエリは、当該イベントストリームにおいてイベントが受信されるたびに実行され得る。連続クエリの実行の一部として、ＥＰＳ２０２は、連続クエリによって指定された命令に基づいて、受信したイベントを評価して、連続クエリの実行の結果として、１つ以上のイベントを注目すべきイベントとして選択すべきか否かを判断して出力する。

連続クエリは、さまざまな言語を使用してプログラムされ得る。特定の実施形態では、連続クエリは、オラクル社によって提供されるＣＱＬを使用して構成され、オラクルの複合イベント処理（ＣＥＰ）製品提供によって使用され得る。オラクルのＣＱＬは、イベントストリームに対して実行可能なクエリ（ＣＱＬクエリと称される）をプログラムするために使用できる宣言型言語である。特定の実施形態では、ＣＱＬは、ストリーミングイベントデータの処理をサポートする追加の構造を有するＳＱＬに基づく。

一実施形態では、イベント処理アプリケーションは、以下のコンポーネントタイプで構成され得る。

（１）入力および出力ストリームならびにリレーションソースおよびシンクに直接接続する１つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを理解するように構成され、イベントデータを、アプリケーションプロセッサによって照会可能な正規化された形態に変換する役割を担う。アダプタは、正規化されたイベントデータをチャネルまたは出力ストリームおよびリレーションシンクに転送し得る。イベントアダプタは、さまざまなデータソースおよびシンクについて定義され得る。

（２）イベント処理終点の役割を果たす１つ以上のチャネル。とりわけ、チャネルは、イベント処理エージェントがイベントデータに対して作用することができるまでイベントデータを待ち行列に入れる役割を担う。

（３）１つ以上のアプリケーションプロセッサ（または、イベント処理エージェント）は、正規化されたイベントデータをチャネルから消費し、クエリを使用してそれを処理して注目すべきイベントを選択し、選択された注目すべきイベントを出力チャネルに転送（または、コピー）するように構成される。

（４）１つ以上のビーンは、出力チャネルを聞き取るように構成され、出力チャネルへの新たなイベントの挿入によって作動される。いくつかの実施形態では、このユーザコードは、プレーンオールドＪａｖａオブジェクト（plain-old-Java-object：ＰＯＪＯ）である。ユーザアプリケーションは、ＪＭＳ、ウェブサービスおよびファイルライタなどの外部サービス一式を活用して、生成されたイベントを外部イベントシンクに転送することができる。

（５）イベントビーンは、出力チャネルを聞き取るように登録され得て、出力チャネルへの新たなイベントの挿入によって作動される。いくつかの実施形態では、このユーザコードは、ビーンがオラクルＣＥＰによって管理できるようにオラクルＣＥＰイベントビーンＡＰＩを使用し得る。

一実施形態では、イベントアダプタは、イベントデータを入力チャネルに提供する。入力チャネルは、入力チャネルによって提供されるイベント上で動作する１つ以上のＣＱＬクエリに関連付けられたＣＱＬプロセッサに接続される。ＣＱＬプロセッサは、クエリ結果が書込まれる出力チャネルに接続される。

いくつかの実施形態では、イベント処理アプリケーションのさまざまなコンポーネント、コンポーネントがどのように接続されるか、アプリケーションによって処理されるイベントタイプを記述するアセンブリファイルがイベント処理アプリケーションに対して提供され得る。イベントの選択のために連続クエリまたはビジネス論理を指定するために別々のファイルが提供されてもよい。

図２に示されるシステム２００は、図２に示されているコンポーネント以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２に示される実施形態は、本開示の実施形態を組み込むことができるシステムの一例に過ぎない。いくつかの他の実施形態では、システム２００は、図２に示されるよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。システム２００は、パーソナルコンピュータ、ポータブルデバイス（たとえば、携帯電話またはデバイス）、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他のデータ処理システムを含むさまざまなタイプのシステムであってもよい。いくつかの他の実施形態では、システム２００は、システム２００の１つ以上のコンポーネントがクラウド内の１つ以上のネットワークにわたって分散される分散型システムとして構成されてもよい。

図２に示されるコンポーネントのうちの１つ以上は、ソフトウェア、ハードウェア、またはそれらの組み合わせで実現されてもよい。いくつかの実施形態では、ソフトウェアは、メモリ内に格納されてもよく（たとえば、非一時的なコンピュータ読取可能な媒体）、メモリデバイス上に格納されてもよく、または何らかの他の物理メモリ上に格納されてもよく、１つ以上の処理ユニット（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵなど）によって実行されてもよい。

連続的な予定されたクエリのハイブリッド実行を実現するための例示的な方法およびシステムについて上記した。これらのシステムおよび方法のうちのいくつかまたは全ては、少なくとも部分的に、少なくとも上記の図１〜図２に示されるようなアーキテクチャおよびプロセスによって実現されてもよいが、そうでなくてもよい。

図３〜図５は、それぞれ、本開示の実施形態に係る多段階処理のイベント順序を保証するための方法３００，４００および５００のフローチャートである。図３〜図５に示される方法３００，４００および５００の実現例または処理は、コンピュータシステムまたは情報処理デバイスなどの論理マシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行されたときにはソフトウェア（たとえば、命令またはコードモジュール）によって実行されてもよく、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行されてもよく、またはソフトウェアとハードウェア要素との組み合わせによって実行されてもよい。本明細書および以下に記載されているプロセスのうちのいずれかの各ステップは、所望のごとく、いかなる順序で実行されてもよく、省略（またはそうでなければスキップ）されてもよく、他のステップと置換されてもよく、および／または、繰返しもしくは再帰的に実行されてもよい。

図３に示される方法３００は、３０２から開始し得て、３０２において、少なくともタイマが時間切れになるまで起こるウォームアップ期間に少なくとも部分的に基づいてイベントストリームの第１のイベントを判断（または、識別）し得る。いくつかの例では、３０４において、第１のイベントのタイムスタンプでイベントカウンタを初期化し得る。３０６において、イベントストリームのさらに他のイベントを処理し得る。さらに他のイベントは、タイマが時間切れになる前にバッチ処理されているかもしれない。いくつかの例では、３０８において、フィルタリングされたイベントを識別し得る。フィルタリングされたイベントは、上流の段階によってフィルタリングにより除去されているかもしれない。３１０において、フィルタリングされたイベントのために、スキップビートを生成し、および／または、スキップビートをストリームに挿入し得る。３１２において、イベントストリームの後続のイベントを受信し得る。場合によっては、３１４において、順序が狂ったイベントを識別し得る。いくつかの例では、方法３００は、後続のイベントを順番に処理することによって、および／または、後続のイベントが順番に処理されることを保証することによって、３１６において終了し得る。これは、各々の入来イベントが実際のイベントであるかスキップビートであるかに関係なくなされ得る。言い換えれば、スキップビートが受信されると、各イベントは順番に処理されることになる。いくつかの例では、スキップビートは、イベントデータを含まないので実際のイベントではない（たとえば、それは、ＣＥＰエンジンが、フィルタリングされたイベントを待つことなくストリームを処理し続けることを可能にするダミーイベントである）。

図４は、本開示の実施形態に係る多段階処理のイベント順序を保証するための方法４００のフローチャートである。図４に示される方法４００は、４０２から開始し得て、４０２において、タイマを開始し得る。いくつかの例では、４０４において、タイマが時間切れになるまでストリームのイベントを受信し得る。４０６において、入来イベントを時系列順に再配列（または、配列）し得る（たとえば、順序が狂っている場合には並べる）。方法４００のウォームアップ期間は、第１のイベントを、少なくとも部分的に最高の（最古の、最新の、最も最近の）タイムスタンプを有するイベントに基づく第１のイベントとして識別する４０８において終了し得る。

図５は、本開示の実施形態に係る多段階処理のイベント順序を保証するための方法５００のフローチャートである。図５に示される方法５００は、５０２から開始し得て、５０２において、イベントを受信し、どのタイプのイベントが受信されたかおよびイベントのタイムスタンプを判断する。いくつかの例では、５０２において、次の予想されるタイムスタンプよりも高いタイムスタンプを有するスキップビートまたは実際のイベントが到着すると、当該イベントがバッファに追加され、タイマが開始される。タイマは、予め構成された時間切れ間隔を有し得る。５０４において、より多くの実際のイベントまたはスキップビートが受信される。それらが次の予想されるタイムスタンプよりも高いタイムスタンプを有する場合には、それらもバッファに追加され、タイマが動作し続ける。５０６において、次の予想されるタイムスタンプと同一のタイムスタンプを有する実際のイベントまたはスキップビートが到着すると、タイマがオフにされ得て、バッファ内のイベントが再配列および／または処理され得る。なお、スキップビートは適宜伝搬され続ける。５０８において、次の予想されるタイムスタンプよりも低いタイムスタンプを有する実際のイベントまたはスキップビートが到着すると、当該イベントは帯域外として廃棄され得る。いくつかの例では、方法５００は、タイマが時間切れになるとバッファリングされたイベントを再配列および／または処理することによって５１０において終了し得る。また、方法５００は、この間にスキップビートを所望のごとく伝搬し続け得る。

図６は、実施形態のうちの１つを実現するための分散型システム６００の簡略図を示す。示されている実施形態では、分散型システム６００は、１つ以上のクライアントコンピューティングデバイス６０２，６０４，６０６および６０８を含み、それらは、１つ以上のネットワーク６１０を介してウェブブラウザ、所有権付きクライアント（たとえばオラクルフォームズ（Oracle Forms））などのクライアントアプリケーションを実行および動作させるように構成される。サーバ６１２は、リモートクライアントコンピューティングデバイス６０２，６０４，６０６および６０８とネットワーク６１０を介して通信可能に結合されてもよい。

さまざまな実施形態では、サーバ６１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。当該サービスまたはソフトウェアアプリケーションは、非仮想および仮想環境を含み得る。仮想環境は、仮想イベント、展示会、シミュレータ、教室、ショッピングでのやりとり、企業、二次元または三次元（３Ｄ）表示、ページベースの論理環境などに使用されるものを含み得る。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（ＳａａＳ）モデルの下で、クライアントコンピューティングデバイス６０２，６０４，６０６および／または６０８のユーザに対して提供されてもよい。クライアントコンピューティングデバイス６０２，６０４，６０６および／または６０８を動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用してサーバ６１２と対話して、これらのコンポーネントによって提供されるサービスを利用してもよい。

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

クライアントコンピューティングデバイス６０２，６０４，６０６および／または６０８は、携帯可能な手持ち式のデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、セルラー電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）頭部装着型ディスプレイ）であってもよく、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ（登録商標）などのソフトウェア、および／もしくは、ｉＯＳ、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ ８、Ｐａｌｍ ＯＳなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（short message service：ＳＭＳ）、ＢｌａｃｋＢｅｒｒｙ（登録商標）、または他のイネーブルにされた通信プロトコルである。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータであってもよく、一例として、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む。クライアントコンピューティングデバイスは、たとえばＧｏｏｇｌｅ Ｃｈｒｏｍｅ ＯＳなどのさまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを限定を伴うことなく含む、さまざまな市場で入手可能なＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステムのいずれかを実行するワークステーションコンピュータであり得る。代替的に、または加えて、クライアントコンピューティングデバイス６０２，６０４，６０６および６０８は、ネットワーク６１０を介して通信することができる、シンクライアントコンピュータ、インターネットにより可能化されるゲームシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャ入力デバイスを伴うかまたは伴わないＭｉｃｒｏｓｏｆｔ Ｘｂｏｘゲームコンソール）および／または個人メッセージ伝達デバイスなどのその他の電子デバイスであってもよい。

例示的な分散型システム６００は４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなど、他のデバイスがサーバ６１２と対話してもよい。

分散型システム６００におけるネットワーク６１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋなどを限定を伴うことなく含む、さまざまな市場で入手可能なプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。単に一例として、ネットワーク６１０は、イーサネット（登録商標）、トークンリングなどに基づくものなどのローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク６１０は、ワイドエリアネットワークおよびインターネットであってもよい。ネットワーク６１０は、仮想ネットワークを含み得て、当該仮想ネットワークは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、米国電気電子学会（ＩＥＥＥ）６０２．１１のプロトコル一式、ブルートゥース（登録商標）、および／もしくはその他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、ならびに／またはこれらのいずれかの組み合わせおよび／もしくは他のネットワークを含むが、それらに限定されるものではない。

サーバ６１２は、１つ以上の汎用コンピュータ、専用のサーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な構成および／もしくは組み合わせで構成されてもよい。サーバ６１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理ストレージデバイスの１つ以上の柔軟なプールを仮想化してサーバのために仮想ストレージデバイスを維持することができる。仮想ネットワークを、サーバ６１２によって、ソフトウェア定義のネットワーク接続を用いて制御することができる。さまざまな実施形態において、サーバ６１２は、前述の開示に記載される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ６１２は、本開示の実施形態に従って上記の処理を実行するためのサーバに対応してもよい。

サーバ６１２は、上記のもののうちのいずれかを含むオペレーティングシステム、および任意の市場で入手可能なサーバオペレーティングシステムを実行してもよい。サーバ６１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡサーバ、データベースサーバなどを含むさまざまなさらに他のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかも実行してもよい。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース、ＩＢＭ（インターナショナルビジネスマシンズ）などから市場で入手可能なものを含むが、それらに限定されるものではない。

いくつかの実現例では、サーバ６１２は、クライアントコンピューティングデバイス６０２，６０４，６０６および６０８のユーザから受信されるデータフィードおよび／またはイベント更新情報を解析および整理統合するための１つ以上のアプリケーションを含んでもよい。一例として、データフィードおよび／またはイベント更新情報は、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などに関連するリアルタイムのイベントを含んでもよい、１つ以上の第三者情報源および連続データストリームから受信される、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報またはリアルタイムの更新情報を含んでもよいが、それらに限定されるものではない。サーバ６１２は、データフィードおよび／またはリアルタイムのイベントをクライアントコンピューティングデバイス６０２，６０４，６０６および６０８の１つ以上の表示デバイスを介して表示するための１つ以上のアプリケーションも含んでもよい。

分散型システム６００は、１つ以上のデータベース６１４および６１６も含んでもよい。データベース６１４および６１６は、さまざまな位置にあってもよい。一例として、データベース６１４および６１６のうちの１つ以上は、サーバ６１２に局在する（および／またはサーバ６１２に常駐する）非一時的な記憶媒体にあってもよい。代替的に、データベース６１４および６１６は、サーバ６１２から遠隔にあり、ネットワークベースまたは専用の接続を介してサーバ６１２と通信してもよい。一組の実施形態では、データベース６１４および６１６は、記憶域ネットワーク（storage-area network：ＳＡＮ）にあってもよい。同様に、サーバ６１２に帰する機能を実行するための任意の必要なファイルが、適宜、サーバ６１２上においてローカルに、および／または遠隔で格納されてもよい。一組の実施形態では、データベース６１４および６１６は、ＳＱＬフォーマットされたコマンドに応答してデータを格納、更新および検索取得するように適合される、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでもよい。

図７は、本開示の実施形態に従って、実施形態のシステムの１つ以上のコンポーネントによって提供されるサービスがクラウドサービスとして提供されてもよいシステム環境７００の１つ以上のコンポーネントの簡略ブロック図である。示されている実施形態では、システム環境７００は、１つ以上のクライアントコンピューティングデバイス７０４，７０６および７０８を含み、１つ以上のクライアントコンピューティングデバイス７０４，７０６および７０８は、クラウドサービスを提供するクラウドインフラストラクチャシステム７０２と対話するようにユーザによって使用されてもよい。クライアントコンピューティングデバイスは、ウェブブラウザ、所有権付きクライアントアプリケーション（たとえば、オラクルフォームズ）、または何らかの他のアプリケーションなどのクライアントアプリケーションを動作させるように構成されてもよく、当該クライアントアプリケーションは、クラウドインフラストラクチャシステム７０２と対話して、クラウドインフラストラクチャシステム７０２によって提供されるサービスを使用するようにクライアントコンピューティングデバイスのユーザによって使用されてもよい。

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

クライアントコンピューティングデバイス７０４，７０６および７０８は、６０２，６０４，６０６および６０８に対して上記したものと同様のデバイスであってもよい。

例示的なシステム環境７００が３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなどの他のデバイスがクラウドインフラストラクチャシステム７０２と対話してもよい。

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

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

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

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供されるかもしくは他の態様で当該技術分野において公知であるような他のサービスに対する保護されたコンピュータネットワークアクセスを含んでもよい。たとえば、サービスは、クラウド上のリモートストレージに対するインターネットを介してのパスワード保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク接続された開発者による個人的な使用のために、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイトにおいて運営管理される電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。

特定の実施形態では、クラウドインフラストラクチャシステム７０２は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルで、信頼性があり、高可用性の、安全な態様で顧客に対して配送される一連のアプリケーション、ミドルウェア、およびデータベースサービス提供を含んでもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウド（Oracle Public Cloud）である。

「ビッグデータ」は、多数のレベルにおいて、および異なるスケールで、インフラストラクチャシステムによって運営管理および／または操作され得る。大量のデータを視覚化し、傾向を検出し、および／またはその他の態様でデータと対話するように非常に大きなデータセットがアナリストおよび研究者によって格納および操作され得る。そのようなデータを表示するため、またはデータもしくはデータが表現するものに対する外部の力をシミュレートするために、並列に連結された何十、何百または何千ものプロセッサがそのようなデータに対して作用することができる。これらのデータセットは、データベース状にもしくはさもなければ構造モデルに従って編成されたものなどの構造化データ、および／または、非構造化データ（たとえば、電子メール、画像、データブロブ（バイナリラージオブジェクト）、ウェブページ、複合イベント処理）を含み得る。より多くの（またはより少ない）計算リソースを比較的迅速に対象に集中させることができる実施形態の機能を活用することによって、クラウドインフラストラクチャシステムは、会社、政府機関、研究組織、私人、同じ考えを持った個人もしくは組織のグループ、または他のエンティティからの要求に基づいて大きなデータセットに対してタスクを実行することにさらに利用できるであろう。

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

いくつかの実施形態では、クラウドインフラストラクチャシステム７０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含む他のサービスのカテゴリの下で提供される１つ以上のサービスを含んでもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム７０２によって提供される１つ以上のサービスをオーダーしてもよい。クラウドインフラストラクチャシステム７０２は、次いで、処理を実行して、顧客のサブスクリプションオーダーにおけるサービスを提供する。

いくつかの実施形態では、クラウドインフラストラクチャシステム７０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含んでもよいが、それらに限定されるものではない。いくつかの例では、アプリケーションサービスは、クラウドインフラストラクチャシステムによってＳａａＳプラットフォームを介して提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに入るクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、一連のオンデマンドアプリケーションを統合された開発およびデプロイメントプラットフォーム上で構築し配送する機能を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムにおいて実行されるアプリケーションを利用することができる。顧客は、別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。その例としては、大きな組織に販売実績管理、企業統合、およびビジネスの柔軟性のためのソリューションを提供するサービスが挙げられるが、それらに限定されるものではない。

いくつかの実施形態では、プラットフォームサービスは、クラウドインフラストラクチャシステムによってＰａａＳプラットフォームを介して提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに入るクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例としては、（オラクルなどの）組織が既存のアプリケーションを共有の共通のアーキテクチャにおいて整理統合することができるサービス、およびプラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能を挙げることができるが、それらに限定されるものではない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを、別個のライセンスおよびサポートを購入する必要なく取得することができる。プラットフォームサービスの例としては、オラクル・Ｊａｖａ・クラウド・サービス（Oracle Java Cloud Service：ＪＣＳ）、オラクル・データベース・クラウド・サービス（Oracle Database Cloud Service：ＤＢＣＳ）などが挙げられるが、それらに限定されるものではない。

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

さまざまな異なるインフラストラクチャサービスがＩａａＳプラットフォームによってクラウドインフラストラクチャシステムにおいて提供されてもよい。インフラストラクチャサービスは、ストレージ、ネットワーク、ならびにＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客に対する他の基礎的計算リソースなどの基本的な計算リソースの管理および制御を容易にする。

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

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

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

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

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

例示的な動作７３４では、クライアントデバイス７０４、７０６または７０８などのクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム７０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム７０２によって提供される１つ以上のサービスに対するサブスクリプションに対するオーダーを行なうことによって、クラウドインフラストラクチャシステム７０２と対話してもよい。特定の実施形態では、顧客は、クラウドＵＩ７１２、クラウドＵＩ７１４および／またはクラウドＵＩ７１６などのクラウドユーザインターフェイス（ＵＩ）にアクセスし、サブスクリプションオーダーをこれらのＵＩを介して行なってもよい。顧客がオーダーを行なうことに応答してクラウドインフラストラクチャシステム７０２によって受信されるオーダー情報は、顧客を識別する情報、およびクラウドインフラストラクチャシステム７０２によって提供される、その顧客が契約する予定の１つ以上のサービスを含んでもよい。

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

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

動作７３８において、オーダー情報は、オーダー管理モジュール７２０に転送される。いくつかの例では、オーダー管理モジュール７２０は、オーダーを検証すること、および検証次第そのオーダーを予約することなど、オーダーに関連する請求および課金機能を実行するように構成されてもよい。

動作７４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール７２２に通信される。オーダーオーケストレーションモジュール７２２は、オーダー情報を利用して、顧客によってなされたオーダーに対してサービスおよびリソースのプロビジョニングをオーケストレーションし得る。いくつかの例では、オーダーオーケストレーションモジュール７２２は、オーダープロビジョニングモジュール７２４のサービスを使用してサブスクライブされたサービスをサポートするようにリソースのプロビジョニングをオーケストレーションしてもよい。

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

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

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

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

図８は、本開示のさまざまな実施形態を実現することができる例示的なコンピュータシステム８００を示す。システム８００は、上記のコンピュータシステムのうちのいずれかを実現するよう用いられてもよい。図に示されるように、コンピュータシステム８００は、多数の周辺サブシステムとバスサブシステム８０２を介して通信する処理ユニット８０４を含む。これらの周辺サブシステムは、処理加速ユニット８０６、Ｉ／Ｏサブシステム８０８、ストレージサブシステム８１８および通信サブシステム８２４を含んでもよい。ストレージサブシステム８１８は、有形のコンピュータ読取可能な記憶媒体８２２およびシステムメモリ８１０を含む。

バスサブシステム８０２は、コンピュータシステム８００のさまざまなコンポーネントおよびサブシステムに意図されるように互いに通信させるための機構を提供する。バスサブシステム８０２は単一のバスとして概略的に示されているが、バスサブシステムの代替的実施例は、複数のバスを利用してもよい。バスサブシステム８０２は、さまざまなバスアーキテクチャのうちのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、エンハンストＩＳＡ（Enhanced ISA：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に従って製造される中二階バスとして実現され得る周辺コンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスを含んでもよい。

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

さまざまな実施形態では、処理ユニット８０４は、プログラムコードに応答してさまざまなプログラムを実行することができ、複数の同時に実行されるプログラムまたはプロセスを維持することができる。任意の所与の時点で、実行されるべきプログラムコードの一部または全ては、プロセッサ８０４、および／または、ストレージサブシステム８１８に常駐することができる。好適なプログラミングを介して、プロセッサ８０４は、上記のさまざまな機能を提供することができる。コンピュータシステム８００は、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、特殊目的プロセッサなどを含み得る処理加速ユニット８０６をさらに含んでもよい。

Ｉ／Ｏサブシステム８０８は、ユーザインターフェイス入力デバイスおよびユーザインターフェイス出力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャおよび話し言葉コマンドを用いて、ナチュラルユーザインターフェイスを介して、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラなどの入力デバイスをユーザが制御して対話することを可能にするＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサなどのモーション感知および／またはジェスチャ認識デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き（たとえば、写真を撮っている間および／またはメニュー選択を行なっている間の「まばたき」）を検出し、アイジェスチャを入力デバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標））への入力として変換するＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と対話することを可能にする音声認識感知デバイスを含んでもよい。

ユーザインターフェイス入力デバイスは、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスも含んでもよいが、それらに限定されるものではない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスも含んでもよい。

ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使うものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という語の使用は、コンピュータシステム８００からユーザまたは他のコンピュータに情報を出力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されるものではない。

コンピュータシステム８００は、現在のところシステムメモリ８１０内に位置しているものとして示されているソフトウェア要素を備えるストレージサブシステム８１８を備えてもよい。システムメモリ８１０は、処理ユニット８０４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納してもよい。

コンピュータシステム８００の構成およびタイプによって、システムメモリ８１０は、揮発性であってもよく（ランダムアクセスメモリ（ＲＡＭ）など）、および／または、不揮発性であってもよい（リードオンリメモリ（ＲＯＭ）、フラッシュメモリなど）。ＲＡＭは、一般に、処理ユニット８０４にすぐにアクセス可能であり、および／または、処理ユニット８０４によって現在動作および実行されているデータおよび／またはプログラムモジュールを含む。いくつかの実現例では、システムメモリ８１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでもよい。いくつかの実現例では、起動中などにコンピュータシステム８００内の要素間における情報の転送を助ける基本的なルーティンを含むベーシックインプット／アウトプットシステム（basic input/output system：ＢＩＯＳ）は、一般に、ＲＯＭに格納されてもよい。一例として、限定を伴うことなく、システムメモリ８１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含んでもよいアプリケーションプログラム８１２、プログラムデータ８１４およびオペレーティングシステム８１６も示す。一例として、オペレーティングシステム８１６は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／もしくはＬｉｎｕｘオペレーティングシステム、さまざまな市場で入手可能なＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むがそれらに限定されない）、ならびに／または、ｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標） Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標） ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標） ８ ＯＳ、およびＰａｌｍ（登録商標） ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムのさまざまなバージョンを含んでもよい。

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

ストレージサブシステム８１８は、コンピュータ読取可能な記憶媒体８２２にさらに接続可能なコンピュータ読取可能記憶媒体リーダ８２０も含んでもよい。システムメモリ８１０とともに、およびオプションとしてシステムメモリ８１０との組み合わせで、コンピュータ読取可能な記憶媒体８２２は、コンピュータ読取可能な情報を一時的および／またはより永久的に収容、格納、伝送および検索取得するための、遠隔の、ローカルな、固定された、および／またはリムーバブルなストレージデバイスに記憶媒体を加えたものを包括的に表わしてもよい。

コードまたはコードの一部を含むコンピュータ読取可能な記憶媒体８２２は、記憶媒体および通信媒体を含む、当該技術分野において公知であるまたは使用されるいずれかの適切な媒体も含んでもよく、当該媒体は、情報の格納および／または伝送のための任意の方法または技術において実現される揮発性および不揮発性の、リムーバブルおよび非リムーバブルな媒体などであるが、それらに限定されるものではない。これは、ＲＡＭ、ＲＯＭ、電気的に消去可能なプログラム可能ＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学式ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または他の有形のコンピュータ読取可能な媒体などの有形の非一時的なコンピュータ読取可能な記憶媒体を含んでもよい。指定される場合には、これは、データ信号、データ伝送、または所望の情報を伝送するために使用可能でありコンピューティングシステム８００によってアクセス可能であるその他の媒体などの無形の一時的なコンピュータ読取可能な媒体も含んでもよい。

一例として、コンピュータ読取可能な記憶媒体８２２は、非リムーバブル不揮発性磁気媒体に対して読み書きするハードディスクドライブ、リムーバブル不揮発性磁気ディスクに対して読み書きする磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクなどの、リムーバブル不揮発性光ディスクに対して読み書きする光ディスクドライブ、または他の光学式媒体を含んでもよい。コンピュータ読取可能な記憶媒体８２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、それらに限定されるものではない。コンピュータ読取可能な記憶媒体８２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも含んでもよい。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージをコンピュータシステム８００に提供してもよい。

通信サブシステム８２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム８２４は、他のシステムとコンピュータシステム８００との間のデータの送受のためのインターフェイスとして働く。たとえば、通信サブシステム８２４は、コンピュータシステム８００がインターネットを介して１つ以上のデバイスに接続することを可能にしてもよい。いくつかの実施形態では、通信サブシステム８２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ６０２．１１ファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）送受信機コンポーネント、グローバルポジショニングシステム（global positioning system：ＧＰＳ）受信機コンポーネント、ならびに／または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム８２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット）を提供することができる。

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

一例として、通信サブシステム８２４は、ソーシャルメディアネットワークおよび／またはＴｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報、Ｒｉｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィード、および／もしくは１つ以上の第三者情報源からのリアルタイム更新情報などの他の通信サービスのユーザからリアルタイムでデータフィード８２６を受信するように構成されてもよい。

さらに、また、通信サブシステム８２４は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム８２８および／またはイベント更新情報８３０を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などを挙げることができる。

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

コンピュータシステム８００は、手持ち式の携帯デバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標）頭部装着型ディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのもののうちの１つであり得る。

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

上記の明細書では、本開示の局面についてその具体的な実施形態を参照して説明しているが、本開示はそれに限定されるものではないということを当業者は認識するであろう。上記の開示のさまざまな特徴および局面は、個々にまたは一緒に用いられてもよい。また、さまざまな変形例、変更例、代替的な構造および等価物は、本開示の範囲内に包含される。変形例は、開示されている特徴のいずれかの関連の組み合わせを含む。さらに、実施形態は、明細書のさらに広い精神および範囲から逸脱することなく、本明細書に記載されているものを超えて、さまざまな環境およびアプリケーションで利用することができる。したがって、明細書および図面は、限定的ではなく例示的であると見なされるべきである。

Claims (11)

1. コンピュータによって実行される方法であって、
   イベントストリームの一部として受信される一連のイベントのうちの第１のイベントを判断するステップと、
   イベントカウンタの値を前記第１のイベントのタイムスタンプで初期化するステップと、
   前記イベントストリームのさらに他のイベントを処理するステップと、
   前記イベントストリームのフィルタリングされたイベントを識別するステップと、
   前記フィルタリングされたイベントのためのスキップビートを生成するステップとを備え、前記スキップビートは前記フィルタリングされたイベントのタイムスタンプを含み、
   前記スキップビートを前記イベントストリームに挿入するステップと、
   前記イベントストリームの後続のイベントを受信するステップと、
   前記イベントストリームの順序が狂ったイベントを識別するステップと、
   前記イベントストリームにおける次のイベントが実際のイベントであるかスキップビートであるかに関係なく、前記後続のイベントの各々に関連付けられた前記タイムスタンプの順序で後続のイベントを処理するステップとを備える、方法。
2. 前記第１のイベントは、
   タイマを開始すること、
   前記タイマが時間切れになるまで前記一連のイベントのうちの一組のイベントを受信すること、
   前記一組のイベントを時系列順に再配列すること、および
   前記第１のイベントを、最新のタイムスタンプを有する前記再配列された組のイベントとして識別すること、によって判断される、請求項１に記載の方法。
3. 前記さらに他のイベントは、前記タイマが時間切れになる前にバッチ処理される、請求項２に記載の方法。
4. 前記フィルタリングされたイベントは、上流の段階によってフィルタリングされて除去される、請求項１〜３のいずれか１項に記載の方法。
5. 前記実際のイベントは、前記イベントストリームに対応するイベントデータを備える、
   請求項１〜４のいずれか１項に記載の方法。
6. プログラムコードを格納するコンピュータ読取可能プログラムであって、前記プログラムコードは、コンピューティングシステムのプロセッサによって実行されたときに、前記プロセッサに動作を実行させ、前記動作は、
   一連のイベントのうちの第１のイベントを判断することと、
   イベントカウンタの値を前記第１のイベントのタイムスタンプで初期化することと、
   さらに他のイベントを処理することと、
   フィルタリングされたイベントを識別することと、
   前記フィルタリングされたイベントのためのスキップビートを生成することとを備え、前記スキップビートは前記フィルタリングされたイベントのタイムスタンプを含み、
   後続のイベントを受信することと、
   順序が狂ったイベントを識別することと、
   イベントストリームにおける次のイベントが実際のイベントであるかスキップビートであるかに関係なく、前記後続のイベントの各々に関連付けられた前記タイムスタンプの順序で後続のイベントを処理することとを備える、コンピュータ読取可能プログラム。
7. 前記第１のイベントは、イベントストリームの一部として受信される、請求項６に記載のコンピュータ読取可能プログラム。
8. 前記さらに他のイベントまたは前記フィルタリングされたイベントのうちの少なくとも１つは、前記イベントストリームの一部として受信される、請求項７に記載のコンピュータ読取可能プログラム。
9. 前記動作は、前記スキップビートを前記イベントストリームに挿入することをさらに備える、請求項７または８に記載のコンピュータ読取可能プログラム。
10. 前記順序が狂ったイベントは廃棄される、請求項６〜９のいずれか１項に記載のコンピュータ読取可能プログラム。
11. システムであって、
    コンピュータによって実行可能な命令を格納するように構成されたメモリと、
    前記メモリにアクセスして、前記コンピュータによって実行可能な命令を実行するように構成されたプロセッサとを備え、前記コンピュータによって実行可能な命令は、少なくとも、
    一連のイベントのうちの第１のイベントを判断する命令と、
    イベントカウンタの値を前記第１のイベントのタイムスタンプで初期化する命令と、
    さらに他のイベントを処理する命令と、
    フィルタリングされたイベントを識別する命令と、
    前記フィルタリングされたイベントのためのスキップビートを生成する命令とを備え、前記スキップビートは前記フィルタリングされたイベントのタイムスタンプを含み、
    後続のイベントを受信する命令と、
    順序が狂ったイベントを識別する命令と、
    イベントストリームにおける次のイベントが実際のイベントであるかスキップビートであるかに関係なく、前記後続のイベントの各々に関連付けられた前記タイムスタンプの順序で後続のイベントを処理する命令とを備える、システム。