(58)【調査した分野】(Int.Cl.,DB名)
前記クエリは、到来する前記データストリームのリアルタイムデータまたは前記データストリームのアーカイブされたリレーションを処理するように構成された連続クエリを含む、請求項1に記載のシステム。
前記データストリームは、ウィンドウを用いて構成されたリレーションを含み、前記ウィンドウは、前記ウィンドウの中の前記データストリームの一部を参照するためのものであり、前記ウィンドウは、時間の経過とともに前記データストリームに沿って移動するように構成される、請求項1〜3のいずれか一項に記載のシステム。
前記履歴データは、前記クエリの初期化前のある時点における前記データストリームからのビジネスイベントデータを含む、請求項1〜6のいずれか一項に記載のシステム。
前記クエリを評価することは、構成可能なウィンドウサイズに少なくとも部分的に基づいて前記データストリームに対して前記クエリを少なくとも適用することを含む、請求項1〜8のいずれか一項に記載のシステム。
前記データストリームは、第2のウィンドウの中の前記データストリームの一部を参照するための第2の構成可能なウィンドウサイズを用いて構成されたリレーションを含み、前記第2のウィンドウのサイズは、第2の構成可能なウィンドウサイズに少なくとも部分的に基づき、
第2のウィンドウは、時間の経過とともに前記データストリームに沿って移動するように構成される、請求項1〜11のいずれか一項に記載のシステム。
前記データ定義言語アノテーションは、前記履歴データの場所、前記データストリームのソース、前記データストリームに関連するデータオブジェクト、前記連続クエリの処理に関連する動作情報、前記履歴データに対応するデータベースの関連する1つ以上の列、前記連続クエリの出力に対応するデータオブジェクト、および、前記連続クエリの出力を提供するための場所のうちの少なくとも1つを識別する、請求項14に記載のコンピュータ読取可能なプログラム。
【発明を実施するための形態】
【0016】
詳細な説明
以下の説明では、さまざまな実施形態が説明される。これら実施形態が十分に理解されるよう、特定の構成および詳細事項が説明のために記載される。しかしながら、これらの具体的な詳細事項がなくとも実施形態を実行し得ることも当業者には明らかであろう。さらに、記載されている実施形態が不明瞭にならぬよう、周知の特徴は省略または簡略化される場合がある。
【0017】
いくつかの例において、1つ以上のアーカイブされたリレーションを有する連続クエリ言語(continuous query language)(CQL)クエリ(「クエリステートメント」とも呼ばれる)をサポートする機構を提供し得る。上記アーカイブされたリレーションは、たとえばCQLリレーションを含むがこれに限定されない。これは、作成された時点において空でなくてもよい。たとえば、シナリオによっては、CQLリレーションを、ストリーム上にウィンドウを適用することによって定義してもよい。言い換えると、リレーションは有界のデータ集合であってもよい。たとえば、あるイベントストリームに対して、リレーションを先ずウィンドウによって定義してもよく、このウィンドウは(たとえばこのウィンドウの中の)ストリームの特定の数の要素またはストリームの特定の集合の要素を含む。しかしながら、リレーションを場合によっては空の状態で作成してもよい。すなわち、ウィンドウを定義してもよいが、リレーションにイベントが含まれていない場合がある。一方、アーカイブされたリレーションは、作成時にイベントデータを含み得る。いくつかの例において、アーカイバ(archiver)または他のデータオブジェクトは、アーカイブされたリレーションの作成において利用されるリアルタイムデータの管理を担当してもよく、および/またはこのデータをアーカイブされたリレーションを生成するかそうでなければ管理するように構成されたエンジンに与えてもよい。
【0018】
加えて、いくつかの例において、アーカイブされたリレーションを有するCQLクエリをサポートするための機構はまた、アーカイブされたリレーションの特定のデータウィンドウの構成を可能にし得る。これらデータウィンドウは、ユーザによって、管理者によって、またはアーカイブされたリレーションおよび/またはユーザのイベントデータ(たとえばビジネスイベントデータ)に関連するその他のエンティティによって、構成、生成、管理、更新、および/または操作されてもよい。さらに、いくつかの例において、連続クエリの中のアーカイブされたリレーションは、変更通知の見落としおよび/または二重カウントを回避するように実装してもよい。たとえば、クエリを実行するときは、クエリを最初にデータオブジェクト補助記憶装置に対して実行してクエリの現在の状態を確立し、その後、このデータオブジェクトからの変更通知をリッスンし(listen for)処理してもよい。しかしながら、クエリを実装する複合イベント処理(CEP)が最初のクエリを実行している間、変更通知が見落とされる場合がある。加えて、変更通知は、変更が最初のクエリに既にある場合は二重カウントされる場合もある。しかし、いくつかの例において、変更通知の見落としおよび/または二重カウントは、最初のクエリの前にリスナー(listener)を確立し、および/またはトランザクション識別子(TID)、コンテキスト識別子(CID)、もしくは変更イベントを管理するための他の機構を利用することによって、回避し得る。
【0019】
一般的に、連続データストリーム(イベントストリームとも呼ばれる)は、明確な終わりがない連続するまたは本質的に無限であるデータまたはイベントのストリームを含み得る。論理的に、イベントまたはデータストリームは、一連のデータ要素(イベントとも呼ばれる)であってもよく、各データ要素は関連するタイムスタンプを有する。連続イベントストリームは、論理的には要素(s,T)のバッグ(bag)またはセットで表わすことができ、「s」はデータ部分を表わし「T」は時間ドメインにある。「s」部分は一般的にタプルまたはイベントと呼ばれる。イベントストリームはしたがってタイムスタンプされた一連のタプルまたはイベントであってもよい。
【0020】
いくつかの局面において、あるストリーム内のイベントに関連するタイムスタンプは、クロック時間と同等であり得る。しかしながら、他の例において、あるイベントストリーム内のイベントに関連する時間は、アプリケーションドメインによって定義してもよく、クロック時間に対応しなくてもよいが、たとえばその代わりに連続番号によって表わしてもよい。したがって、あるイベントストリーム内のイベントに関連する時間情報は、数字、タイムスタンプ、または時間の概念を表わす他の情報によって表わすことができる。入力イベントストリームを受けるシステムでは、イベントは、タイムスタンプが増す順序でシステムに到着する。同一のタイムスタンプを有する2つ以上のイベントがあってもよい。
【0021】
いくつかの例において、あるイベントストリーム内のイベントは、世の中の何らかのイベントの発生(たとえば、温度センサの値が新たな値に変化したとき、株式銘柄の価格が変化したとき)を表わしてもよく、このイベントに関連する時間情報が、データストリームイベントによって表わされる上記世の中のイベントが発生した時間を示してもよい。
【0022】
イベントストリームを介して受けるイベントについては、イベントに関連する時間情報を用いて、イベントストリーム内のイベントが、タイムスタンプの値が増す順序で到着することを保証してもよい。これにより、受けるイベントストリーム内のイベントを、それぞれのイベントに関連する時間情報に基づいて並べることができる。このように並べることを可能にするためには、後で生成されたイベントが、先に生成されたイベントよりも後のタイムスタンプを有するように、タイムスタンプを、イベントストリーム内のイベントと、タイムスタンプが減少しないやり方で関連付ければよい。別の例として、連続番号を時間情報として用いるのであれば、後に生成されたイベントに関連する連続番号を、先に生成されたイベントに関連する連続番号よりも大きくすればよい。いくつかの例において、たとえば、データストリームイベントで表わされる世の中のイベントが同時に発生するときには、複数のイベントを、同一のタイムスタンプまたは連続番号と関連付けてもよい。同一のイベントストリームに属するイベントは通常、関連する時間情報によってイベントに課される順序で処理すればよく、先のイベントは後のイベントよりも前に処理される。
【0023】
イベントストリーム内のイベントに関連する時間情報(たとえばタイムスタンプ)は、ストリームのソースによって設定されてもよく、その代わりに、このストリームを受けるシステムによって設定されてもよい。たとえば、いくつかの実施形態において、イベントストリームを受けるシステム上でハートビート(heartbeat)を管理してもよく、イベントに関連する時間が、ハートビートによって測定される、システムへのイベントの到着時間に基づいていてもよい。あるイベントストリーム内の2つのイベントが同一の時間情報を有することが起こり得る。なお、タイムスタンプの順序条件は、1つのイベントストリームに特有のものであるが、異なるストリームのそれぞれのイベントは、任意で交互配置してもよい。
【0024】
イベントストリームには、関連するスキーマ「S」があり、スキーマは、時間情報と、名前付きの1つ以上の属性からなる一組の属性とを含む。特定のイベントストリームに属するすべてのイベントは、この特定のイベントストリームに関連するスキーマに従う。したがって、イベントストリーム(s,T)の場合、このイベントストリームは、スキーマ「S]を、(<time_stamp>,<attribute(s)>)として有し得る。<attributes>は、スキーマのデータ部分を表わし1つ以上の属性を含み得る。たとえば、株式相場表示機のイベントストリームについてのスキーマは、<株式銘柄>および<株価>という属性を含み得る。このようなストリームを介して受ける各イベントは、1つのタイムスタンプと上記2つの属性とを有する。たとえば、株式相場表示機のイベントストリームは、以下のイベントおよび関連するタイムスタンプを受けることができる。
【0025】
...
(<timestamp_N>,<NVDA,4>)
(<timestamp_N+1>,<ORCL,62>)
(<timestamp_N+2>,<PCAR,38>)
(<timestamp_N+3>,<SPOT,53>)
(<timestamp_N+4>,<PDCO,44>)
(<timestamp_N+5>,<PTEN,50>)
...
上記ストリームにおけるストリーム要素(<timestamp_N+1>,<ORCL,62>)の場合、イベントは、「stock_symbol」(株式銘柄)および「stock_value」(株価)という属性を有する<ORCL,62>である。このストリーム要素に関連するタイムスタンプは「timestamp_N+1」である。このように、連続イベントストリームは、イベントのフローであり、各イベントは同じ一連の属性を有する。
【0026】
上記のように、ストリームは、CQLクエリが機能する対象であるデータの根本的ソースであってもよい。ストリームSは、要素(s,T)のバッグ(「マルチセット」とも呼ばれる)であってもよく、「s」はSのスキーマにあり、「T」は時間ドメインにある。加えて、ストリーム要素は、タイムスタンプされた一連のタプル挿入として表わすことができるタプル−タイムスタンプ対であってもよい。言い換えると、ストリームは、一連のタイムスタンプされたタプルであってもよい。場合によっては、同一のタイムスタンプを有するタプルが2つ以上ある可能性がある。また、入力ストリームのタプルは、タイムスタンプが増す順序でシステムに到着することが要求される場合がある。これに代えて、リレーション(「経時変化するリレーション」とも呼ばれ、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同されてはならない)は、時間ドメインからスキーマRのタプルの無限のバッグへのマッピングであってもよい。いくつかの例において、リレーションは、順序化されていない経時変化するタプルのバッグ(すなわち瞬間的リレーション)であってもよい。場合によっては、時間の各インスタンスにおいてリレーションは有界集合であってもよい。またこれは、リレーションの変化する状態を捕捉するための挿入、削除、および/または更新を含み得る、タイムスタンプを有する一連のタプルとして表わすことができる。ストリームと同様、リレーションは、リレーションの各タプルが従い得る固定スキーマを有し得る。さらに、本明細書で使用されるように、連続クエリは通常、ストリームおよび/またはリレーションのデータを処理することができる(クエリすることができる)。加えて、このリレーションはストリームの参照データであってもよい。
【0027】
いくつかの例において、ビジネスインテリジェンス(BI)は、特定の間隔で(たとえば場合によっては毎日)ビジネスオペレーションを推進し最適化するのを支援し得る。このタイプのBIは通常、オペレーショナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンス、またはオペレーショナルインテリジェンス(OI)と呼ばれる。いくつかの例において、オペレーショナルインテリジェンスは、BIとビジネスアクティビティモニタリング(BAM)との間の線引を曖昧にする。たとえば、BIは、履歴データの周期的クエリを重視するものであってもよい。したがって、これは過去を振り返ることを重視したものであってもよい。しかしながら、BIは、オペレーショナルアプリケーションの中に置くこともでき、したがって、単なる戦略的分析ツールから、ビジネスオペレーションの第一線まで拡張することができる。このため、BIシステムは、イベントストリームを分析し総計をリアルタイムで計算するように構成してもよい。
【0028】
いくつかの例において、連続クエリ言語サービス(CQサービス)は、BI分析サーバを拡張することにより、連続クエリを扱うとともにリアルタイムの警告を可能にするよう、構成し得る。CQサービスは、いくつかの局面において、BI分析サーバおよびCQLエンジンとの統合をもたらし得る。一例にすぎないが、BI分析サーバは、連続クエリをCQサービスに委託してもよく、CQサービスは、CQLエンジンに対する論理データベース(DB)ゲートウェイとして機能してもよい。このようにして、CQLエンジンは、BI分析サーバを、その分析機能およびセマンティックモデリングについて強化することができるであろう。
【0029】
いくつかの例において、CQサービスは、とりわけ以下の機能を提供し得る。
・BI分析サーバに対するサービスをCQLエンジンゲートウェイとしてリモート処理する。
・イベントソース/シンクアダプタ。
・論理的SQLに加えてCQL拡張からデータ定義言語(DDL)を生成する。
・すべての種類の連続クエリおよび実装選択に対して統一されたモデルを提供する。
・メタデータを維持し再始動能力をサポートする。
・高アベイラビリティおよびスケーラビリティのサポート。
【0030】
加えて、いくつかの例において、OIは、可視性およびビジネスオペレーションに対する洞察を与えることができる、リアルタイムの動的なビジネス分析論の一形態である。OIは、BIまたはリアルタイムBIに、どちらも大量の情報の意味を解明するのを支援するという点において、関連付けられるかまたはこれと比較されることが多い。しかしながら、根本的な相違があり、OIは主としてアクティビティ中心であり得るのに対し、BIは主としてデータ中心であり得る。加えて、パターンを識別するための、事後のかつ報告に基づく手法として従来使用されているBIと異なり、OIは、発展途上の状況(たとえば傾向およびパターン)を検出しこれに対応するのにより適している。
【0031】
いくつかの例において、ビジネスイベント分析およびモニタリング(BEAM)システムは、インフライト(in-flight)データを処理しおよび/または受けるCQLエンジンを含み得る。たとえば、CQLエンジンは、入ってくるリアルタイム情報(たとえばBIまたはOI)をクエリするかそうでなければ処理するように構成されたインメモリリアルタイムイベント処理エンジンであってもよい。CQLエンジンは、時間のセマンティクスを利用または理解することができ、データのウィンドウの定義を処理できるように構成し得る。CQLエンジンの利用は、場合によっては、入ってくるデータに対してクエリを常に実行することを必要とし得る。
【0032】
いくつかの局面において、CQLエンジンは、あらゆる特性を備えたクエリ言語を含み得る。このため、ユーザは、クエリという点から計算を指定し得る。加えて、CQLエンジンは、メモリを最適化し、クエリ言語の特徴、オペレータシェアリング、豊富なパターンマッチング、豊富な言語構築等を利用するように、設計してもよい。加えて、いくつかの例において、CQLエンジンは、履歴データおよびストリーミングデータ双方を処理してもよい。たとえば、ユーザは、カリフォルニアの売上高がある目標を超えたときに警告を送るようにクエリを設定してもよい。このように、いくつかの例において、警告は、履歴売上高データおよび入ってくる生(すなわちリアルタイム)の売上高データに少なくとも一部基づき得る。
【0033】
いくつかの例において、CQLエンジンまたは以下で説明する概念のその他の特徴は、履歴に関する文脈(すなわちウェアハウスデータ)を、入ってくるデータとリアルタイム方式で組合わせるように、構成してもよい。したがって、場合によっては、本開示は、データベース格納情報およびインフライト情報の境界について説明することがある。データベース格納情報およびインフライト情報はいずれもBIデータを含み得る。このため、データベースは、いくつかの例において、BIサーバであってもよく、または、何らかの種類のデータベースであってもよい。さらに、いくつかの例において、本開示の特徴により、上記特徴を、ユーザがコードをプログラムする、そうでなければ書込む方法を知らない状態で、実現することができる。言い換えると、上記特徴は、特徴が豊富なユーザインターフェイス(UI)に与えられてもよい、または、履歴データとリアルタイムデータの組合わせを非開発者が実現できるようにする他の手法に与えられてもよい。
【0034】
いくつかの例において、上記概念を利用することにより、複合イベント処理に関連する豊かなリアルタイムの連続イベント処理機能を強化してもよい。これに限定される訳ではないがアーカイブされたリレーション等のいくつかの特徴をサポートしてもよい。このため、このような特徴(たとえば豊かなリアルタイムの連続イベント処理)を強化するために、システムを、リレーショナルデータの始動状態および実行時状態を透明に扱うように構成してもよい。言い換えると、システムを、作成の時点で空でないクエリ(すなわちアーカイブされたリレーション)を管理するように構成してもよい。
【0035】
いくつかの例において、アーカイブされたリレーションを利用してもよい。このため、CQLエンジンが見るクエリが、このクエリがアーカイブされたリレーションに基づくことを示すとき、このアーカイブされたリレーションも、たとえば履歴コンテキストについてクエリするためにコールできる何等かのエンティティが存在することを示し得る。いくつかの例において、データ定義言語(DDL)は、アーカイブされたリレーションに関するアノテーションを示し得る。これは、如何にしてクエリを実行するか、何がテーブル内で重要な列か、および/または何処に残りのデータを送るか等であるが、これらに限定されない。いくつかの例において、CQLエンジンにおいて(たとえばグラフとして)クエリが構築されると、システムはこのクエリグラフを分析することができる。加えて、いくつかの局面において、「distinct」、「group aggr」、「pattern」、および/または「group by」のようなステートフルな特定の演算子がある。しかしながら、ステートレスな演算子は、入力を取込んで、親、たとえば下流の演算子に、送るだけでよい。このため、このテーブル全体をここで格納することが1つの手法である。しかしながら、システムは、アーカイブされたリレーションを利用して、クエリグラフを分析し、アーカイブにクエリするのに使用できる最下位のステートフル演算子がどれかを判断することができる。いくつかの例において、システム(またはコンピュータにより実装される1つ以上の方法)は、グラフをトラバースしている間に到達した最下位のステートフル演算子における状態を取出せばよい。たとえば、クエリグラフを、ソースからトポロジーの順序で分析してもよい。この第1のステートフル演算子に少なくとも一部基づいて、CQLエンジンは次に、アーカイブされたリレーションに対して定義されたクエリの演算子の状態を初期化するために、フェッチすべきデータの最適量を決定してもよい。
【0036】
限定されない少なくとも1つの例において、トポロジーに従ったトラバースにおいて、リレーションおよび/またはソースのようなソース演算子は最初に来るが、クエリ出力および/またはルートは最後に来る。たとえば、CQLクエリが、select sum(c1) from R1 where c2>c25のようなものである場合、このクエリについてのプランは、RelationSource→SELECT→GroupAggrのようなものであろう。したがって、トポロジーの順序に従うと、RelationSourceおよびSELECTはいずれもステートレスなので、最下位のステートフル演算子は、GroupAggrであろう。このようにして、クエリのステートフル演算子(この例ではGroupAggr)により、クエリエンジンは、ストリーミングデータを受ける前に、データ記憶装置からの履歴データをクエリエンジンに投入することができるであろう。これは、クエリがアーカイブされたリレーションを分析しておりアーカイブされたリレーションがそのようなものとして示されていることに少なくとも一部基づいて、可能になるであろう。
【0037】
いくつかの例において、所与のアーカイブリレーションについてのウィンドウサイズは、ユーザが指定してもよい。いくつかの局面において、アーカイブされたリレーションに関するウィンドウは、入ってくるストリーミングされた内容を分析するかそうでなければ評価するクエリグラフにおけるノードを含み得る。言い換えると、ウィンドウは、クエリエンジンによって分析されるおよび/または処理されるストリーミングされた内容の量、および/またはアーカイブされたリレーションに含まれる履歴データの量を定めることができる。
【0038】
高いレベルでは、ウィンドウがストリームに適用されると、これはリレーションになり、次に、リレーショナルデータベースと同様に、通常のリレーショナルロジックを適用すればよい。タプルがウィンドウに届いてウィンドウから出るとき、想定しているリレーションは、これに対してコンパイルされたクエリとともに変化し、同時に結果を出力する。CQLは、RANGE(ナノ秒の細分性まで)、ROWS、PARTITION BYおよび拡張可能なウィンドウをサポートし得る。これらウィンドウは、ストリーム−リレーション演算子の例である。一方、ISTREAM(すなわち挿入ストリーム)、DSTREAM(すなわち削除ストリーム)およびRSTREAM(すなわちリレーションストリーム)は、リレーション−ストリーム演算子である。いくつかの例において、ユーザ、開発者、および/または管理者は、クエリエンジンによってまたはクエリエンジンを機能させるもしくはホストする1つ以上の計算システムによって(たとえばUIを介して)与えられるウィンドウサイズを設定してもよい。いくつかの例において、ストリーム上のウィンドウは、時間に基づく範囲ウィンドウであってもよい。たとえば、アーカイブされたリレーションに対する構成可能な値のウィンドウは、ウィンドウサイズおよびウィンドウの計算の元になる属性を用いて指定してもよい。アーカイブされたリレーションの上に指定された構成可能な値のウィンドウがある場合、スナップショットクエリを計算してもよく、ウィンドウの境界内にあるスナップショットタプルを出力してもよい。加えて、状態の初期化後、値のウィンドウを、入ってくるアクティブデータに適用してもよい。いくつかの例では、入ってくるアクティブデータのみが、そのウィンドウ属性の値が現在のイベント時間と異なるウィンドウに、ウィンドウサイズよりも短い間、挿入されるであろう。
【0039】
加えて、いくつかの例において、本開示の特徴は、CQLエンジンおよび/またはCEPエンジンの連続クエリ処理機能を強化してリアルタイムデータ分析をサポートしてもよい。いくつかの局面において、CQLエンジンおよび/またはCEPエンジンは、従来はストリーム指向分析エンジンであったであろうが、永続的記憶装置によって支援されるストリーム指向データ(たとえば上記アーカイブされたリレーション)をサポートするように拡張してもよい。たとえば、本開示は、永続的記憶装置(データベースおよび/またはテーブル)であるデータオブジェクト(DO)の概念を裏付けることができる特徴を説明している。DOに対して修正がなされると、変更通知が、対象のリスナーにブロードキャストされて、事実上データストリームが作成されるであろう。このデータストリームは、実行しているクエリをサポートするCQLエンジンおよび/またはCEPエンジンによって消費されるであろう。しかしながら、CQLエンジンおよび/またはCEPエンジンは、DO補助記憶装置における既存のデータを考慮するように設計されてはいないかもしれない。たとえば、CQLエンジンおよび/またはCEPエンジンは、CQLエンジンおよび/またはCEPエンジンにおいて実行しているクエリの初期状態が、現在DO補助記憶装置にあるすべてのデータを含むDOの現在の状態を反映することを、要求するかもしれない。このクエリがそのように初期化されると、CQLエンジンおよび/またはCEPエンジンは、従来のストリーム指向方式におけるこの点からのDO変更通知のストリームを扱うだけでよい。
【0040】
いくつかの局面において、CQLエンジンおよび/またはCEPエンジンは、従来はストリームまたはアーカイブされていないリレーションを処理するものであろうため、初期状態はないかもしれない。たとえば、クエリがロードされる場合、これは、実行および変化をリッスンすること等を開始するであろう。場合によっては、棒グラフによる州ごとの売上をユーザが要求しその後誰かによる新たな売上があったとすると、テーブルは更新され、ユーザは、出されたグラフに変化がみられることを予想するであろう。しかしながら、彼らがダッシュボードを閉じて一週間後に戻り売上を報告した場合、ユーザは、合計された売上データのテーブルに示された売上の合計が得られることを予想するであろう。言い換えると、クエリは、アーカイブの状態に引上げられてからアクティブな変更をリッスンする必要があるであろう。
【0041】
たとえば、いくつかの局面において、CQLエンジンは、アーカイブされたデータを用いて予め初期化されてもよい。初期化されると、CQLエンジンは、(たとえば挿入、削除等についてのAPIコール、アーカイブからのデータに少なくとも一部基づく)変更通知があるか否か知るためにJava(登録商標)メッセージングサービス(JMS)またはその他のメッセンジャーをリッスンするであろう。したがって、サービスはリッスンすることができ、JMSが、リスニングサービスがリッスンしているのと同じトピックに関する発行を行なうと、データを受けることができる。サービスは、誰が発行しているのかまたは発行しているか否か知る必要はない。リスニングサービスはリッスンするだけでよく、何かが生じた場合にリスニングサービスはそれを聞けばよい。いくつかの例では、このようにして永続性がたとえばそのコンシューマから切離される。加えて、いくつかの例において、警告エンジンが、聞いたものに基づいて警告を発してもよく、場合によってはさらに、SQLエンジンが、リスナーに関連するプロセスクエリをリッスンしてもよい。
【0042】
いくつかの例において、クエリは、CQL、SQL、および/またはCEPエンジンにおいて開始されてもよく、命令は、アーカイブデータを(たとえばポンプ(pump)するために)取得した後にこれらJMSメッセージをリッスンし始めるように構成されてもよい。しかしながら、多数の挿入、削除等があるので、これは大量の情報を含み得る。加えて、リスナーがメッセージを聞く前に時間のずれがある可能性があり、いくつかの例において、リッスンすることは、割込み、アーカイブにクエリし、戻り、リッスンを開始することであろう。このため、イベントの見落としおよび/または二重カウントの可能性がある。
【0043】
加えて、エンジンがクエリを実行するだけであれば、エンジンがクエリを実行している間に、事実がJMSに入りエンジンがリッスンしていなかったところで発行されることがある。そこで、エンジンを、先ずリスナーをセットアップしアーカイブクエリを実行した後に戻って実際にキュー(queue)から出始めるように構成すれば、何の見落としもないであろう。このように、JMSは、事実をキューにしてもよく、エンジンがクエリを実行している間事実のバックアップがあればそれでよい。なぜなら、後で追い付くことが可能であり同期しているか否か心配する必要がないからである。もしここになければ、リッスン中、見落としはなく、リスナーが確立されている限り、エンジンが戻るまでキューにするだけでよい。
【0044】
加えて、いくつかの例において、システム列をユーザのデータに追加してもよい。このシステム列は、二重カウントおよび/または見落としという動作上の問題に対処する試みにおいて、トランザクションIDを示すためのものであってもよい。しかしながら、他の例において、システムは、トランザクションコンテキストテーブルを提供するかそうでなければ生成してもよい。加えて、2つの追加列としてTRANSACTION_CIDおよびTRANSACTION_TIDがあってもよい。コンテキストテーブルは、最後にコミットされたトランザクションIDのスレッド(コンテキスト)性を知るために、永続性サービスによって常に維持されていてもよい。トランザクションIDは、スレッド(コンテキスト)に対して昇順でコミットされることが保証されてもよい。たとえば、サーバは、立上ったときに、永続性サービスを実行してもよい。各々は、予め初期化された情報のデータがJMSを通過したデータすべてを含むか否か判断するために、コンテキストIDとトランザクションIDのセットを割当ててもよい。加えて、場合によっては、(JTAに準拠するおよび/または高アベイラビリティ(HA)を実現する)複数の出力サーバを利用してもよく、各サーバは、その他のサーバによって管理されるその他のテーブルと全く別の一組のコンテキスト/トランザクションテーブルを管理してもよい。
【0045】
上記および下記技術は、多数のやり方でおよび多数の文脈において実装し得る。以下において詳細に説明する、実装および文脈のいくつかの例を下記図面を参照しながら示す。しかしながら、以下の実装および文脈は、数あるうちのほんの一部にすぎない。
【0046】
図1は、アーカイブされたリレーションを有する連続クエリを管理するための技術を実装し得るシステムまたはアーキテクチャ100の簡略化された例を示す。アーキテクチャ100において、1人以上のユーザ102(たとえば口座所有者)は、ユーザの計算装置104(1)〜104(N)(まとめて「ユーザ装置104」とする)を利用して、1つ以上のサービスプロバイダコンピュータ106に、1つ以上のネットワーク108を介してアクセスし得る。いくつかの局面において、サービスプロバイダコンピュータ106も、1つ以上のストリーミングデータソースコンピュータ110および/または1つ以上のデータベース112とネットワーク108を介して通信し得る。たとえば、ユーザ102は、サービスプロバイダコンピュータ106を利用して、ストリーミングデータソースコンピュータ110および/またはデータベース112のデータにアクセスし得る、そうでなければこのデータを管理し得る(たとえば、クエリは、110、112のうちいずれかまたは双方に対して実行し得る)。データベース112は、リレーショナルデータベース、SQLサーバ等であってもよく、いくつかの例では、履歴データ、イベントデータ、リレーション、アーカイブされたリレーション等を、ユーザ102に代わって管理し得る。加えて、データベース112は、ストリーミングデータソースコンピュータ110から提供されるデータを受けることができ、そうでなければ格納することができる。いくつかの例において、ユーザ102は、ユーザ装置104を利用して、サービスプロバイダコンピュータ106と、クエリ(「クエリステートメント」とも呼ばれる)を与えることによりまたはデータ(たとえば履歴イベントデータ、ストリーミングイベントデータ等)に対する他の要求を与えることにより、対話し得る。このようなクエリまたは要求は次に、データベース112のデータおよび/またはストリーミングデータソースコンピュータ110から入ってくるデータを処理するサービスプロバイダコンピュータ106によって実行し得る。さらに、いくつかの例において、ストリーミングデータソースコンピュータ110および/またはデータベース112は、サービスプロバイダコンピュータ106に関連付けられた、一体化された分散環境の一部であってもよい。
【0047】
いくつかの例において、ネットワーク108は、ケーブルネットワーク、インターネット、無線ネットワーク、セルラーネットワーク、イントラネットシステム、および/またはその他の私的および/または公的ネットワーク等の、複数の異なる種類のネットワークのうちの1つまたはこれらを組合わせたものを含み得る。示されている例はユーザ102がネットワーク108を通してサービスプロバイダコンピュータ106にアクセスすることを示しているが、記載されている技術は、ユーザ102が、1つ以上のサービスプロバイダコンピュータ106と、1つ以上のユーザ装置104を介し固定電話を通して、またはキオスクを介して、または他のやり方で、対話する場合に、等しく適用し得る。また、記載されている技術は、他のクライアント/サーバ構成(たとえばセットトップボックス等)においても、および、非クライアント/サーバ構成(たとえばローカル格納アプリケーション等)においても、適用し得ることが注目される。
【0048】
ユーザ装置104は、携帯電話、スマートフォン、携帯情報端末(PDA)、ラップトップコンピュータ、デスクトップコンピュータ、シンクライアント(thin-client)装置、タブレットPC等の、任意の種類の計算装置であればよいが、これらに限定されない。いくつかの例において、ユーザ装置104は、サービスプロバイダコンピュータ106と、ネットワーク108を介してまたはその他のネットワーク接続を介して通信し得る。さらに、ユーザ装置104はまた、処理するデータベース112(またはその他のデータ記憶装置)のデータを要求するための、1つ以上のクエリまたはクエリステートメントを与えるように構成し得る。
【0049】
いくつかの局面において、サービスプロバイダコンピュータ106はまた、モバイル、デスクトップ、シンクライアント、および/またはサーバ等のクラウド計算装置といった、任意の種類の計算装置であればよいが、これらに限定されない。いくつかの例において、サービスプロバイダコンピュータ106は、ユーザ装置104と、ネットワーク108を介してまたはその他のネットワーク接続を介して通信し得る。サービスプロバイダコンピュータ106は、おそらくは、クラスタに、サーバファームとして、または、互いに関連がない個々のサーバとして配置された、1つ以上のサーバを含み得る。これらサーバは、本明細書に記載の特徴を実行するように、そうでなければホストするように、構成し得る。上記特徴は、本明細書に記載の、アーカイブされたリレーションの管理、アーカイブされたリレーションに関連する構成可能なデータウィンドウ、および/またはアーカイブされたリレーションの管理に関連する変更イベントの正確なカウントを含むが、これらに限定されない。加えて、いくつかの局面において、サービスプロバイダコンピュータ106は、ストリーミングデータソースコンピュータ110および/またはデータベース112を含む、一体化された分散計算環境の一部として構成し得る。
【0050】
例示としてのある構成において、サービスプロバイダコンピュータ106は、少なくとも1つのメモリ136と、1つ以上の処理部(またはプロセッサ)138とを含み得る。プロセッサ138は適宜、ハードウェア、コンピュータにより実行可能な命令、ファームウェア、またはこれらの組合わせにおいて実装し得る。コンピュータにより実行可能な命令またはファームウェアによる、プロセッサ138の実装は、記載されているさまざまな機能を実行するために、何らかの適切なプログラミング言語で書かれた、コンピュータにより実行可能なまたはマシンにより実行可能な命令を含み得る。
【0051】
メモリ136は、プロセッサ138にロード可能でかつプロセッサ138において実行可能なプログラム命令と、これらプログラムの実行中に生成されるデータとを格納し得る。サービスプロバイダコンピュータ106の構成および種類に応じて、メモリ136は、揮発性(ランダムアクセスメモリ(RAM)等)であってもよくおよび/または不揮発性(読出専用メモリ(ROM)、フラッシュメモリ他等)であってもよい。サービスプロバイダコンピュータ106またはサーバはまた、着脱可能な記憶装置および/または着脱不能な記憶装置を含み得る、その他の記憶装置140を含み得る。その他の記憶装置140は、磁気記憶装置、光ディスク、および/またはテープ記憶装置を含み得るがこれらに限定されない。ディスクドライブおよびこれらディスクドライブに関連するコンピュータ読取可能な媒体は、計算装置のための、コンピュータ読取可能な命令、データ構造、プログラムモジュール、およびその他のデータの、不揮発性記憶装置を提供し得る。実装によっては、メモリ136は、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、またはROM等の、複数の異なる種類のメモリを含み得る。
【0052】
着脱可能および着脱不能な、メモリ136およびその他の記憶装置140はすべて、コンピュータ読取可能な記録媒体の例である。たとえば、コンピュータ読取可能な記録媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、またはその他のデータ等の、情報の格納のための何等かの方法または技術において実装される、揮発性または不揮発性で着脱可能または着脱不能な媒体を含み得る。メモリ136およびその他の記憶装置140はすべて、コンピュータ記録媒体の例である。
【0053】
サービスプロバイダコンピュータ106はまた、アイデンティティインターフェイスコンピュータ120が、格納されているデータベース、別の計算装置もしくはサーバ、ユーザ端末、および/またはネットワーク108上のその他の装置と通信できるようにする、通信接続142を含み得る。サービスプロバイダコンピュータ106はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、ディスプレイ、1つ以上のスピーカ、プリンタ他等の、入出力(I/O)装置144を含み得る。
【0054】
次にメモリ136の内容の詳細について述べる。メモリ136は、オペレーティングシステム146と、アーカイブリレーションモジュール148、構成可能ウィンドウモジュール150、および/またはイベントカウントモジュール152を少なくとも含む、本明細書に開示される特徴を実装するための、1つ以上のアプリケーションプログラムまたはサービスとを含み得る。本明細書で使用されるモジュールは、サービスの一部であるサーバまたはサーバのクラスタによって実行されるプログラミングモジュールであってもよい。この特定の文脈において、モジュールを、サービスプロバイダコンピュータ106の一部であるサーバまたはサーバのクラスタによって実行してもよい。いくつかの例において、アーカイブリレーションモジュール148は、1つ以上のイベントストリームエントリs1、s2、…sNへの参照を含み得る1つ以上のアーカイブされたリレーション154を、受ける、識別する、生成する、そうでなければ提供するように構成し得る。たとえば、アーカイブされたリレーションは、これらエントリ(すなわちs1〜sN)を含むストリームにウィンドウを適用することによって定義してもよい。このため、アーカイブされたリレーションは、これらエントリを含む有界のデータ集合であってもよい。しかしながら、これらエントリは生成時に空でない場合がある。これには、限定ではないが、永続性または履歴データのその他のデータベースから予めロードされたリレーションのエントリのうちの1つ以上(たとえばs1および/またはs2、これよりも多いまたは少ないエントリ)を有することが含まれる。このため、これら予めロードされたエントリは履歴データを含み得る。リレーションの残りは入ってくるストリーミングデータを含み得る。いくつかの例において、アーカイブされたリレーション154は、最初に{s3,s4}として識別されるかもしれない。しかしながら、ウィンドウがw1からw2に移動すると、アーカイブされたリレーション154は、{s4,s5}として識別されs3の削除および/またはs5の挿入によって変更されているかもしれない。
【0055】
先に述べたように、アーカイブされたリレーション154は、その作成の「瞬間」において(おそらくは)空でないCQLリレーションであってもよい。これは、作成された「瞬間」において内容が空である「通常の」CQLリレーションと対照的である。いくつかの例において、アーカイブされたリレーション154の内容がその作成の瞬間において「時間の始まり」から存在していたと仮定する(Long.MIN_VALUE)。BEAMコンテキストにおいては、CQLエンジン156のオブジェクト(いくつかの例ではすべてのオブジェクト)をサーバの起動の度に作成し得る点に注目するのが有用である。いくつかの点で、アーカイブされたリレーション154は、「通常の」CQL内部リレーションに似ていることがある。特に、演算(JOIN、GROUP AGGR、ORDER BY TOP Nのようなリレーション−リレーション演算、および、I/D/RSTREAMのようなリレーション−ストリーム演算)は、「通常の」CQL内部リレーションに対して有するのと同一のセマンティクスを保持し得る。加えて、いくつかの例において、「アーカイバ」は、CQLエンジン156との特定のコントラクトを実装するJava(登録商標)クラスであってもよい。これは、アーカイバを可能にする機能を有するIArchiverインターフェイスまたはその他のインターフェイスを実装し得る。この「アーカイバ」は、アーカイブされたリレーション154に対応する「アーカイバ」によって管理される論理エンティティの識別子(たとえばデータオブジェクトの名称)とともに、アーカイブされたリレーション154を作成するのに使用されるDDLステートメントの一部として指定されてもよい。
【0056】
いくつかの局面において、アーカイバは、CQLエンジン156とのコントラクトに少なくとも一部基づいて実装されることにより、アーカイブされたリレーション154の内容をその作成時に少なくとも提供してもよい。加えて、アーカイバは、自身の(たとえばCQLエンジン156の外部の)アーカイブされたリレーション154の「経時変化する」内容を維持すると予想できる。しかしながら、いくつかの例において、アーカイバはステートレスであってもよい。この例において、アーカイバは、アーカイブされたリレーションのフレームワークによって渡されたクエリを実行する方法(たとえば「execute()」)を実装し得る。アーカイバは次に、この方法が実行されると内容をアーカイブされたリレーションのフレームワークに返してもよい。アーカイバはまた、アーカイブされたリレーション154に対するクエリ機能(たとえばSQL−99クエリとして表現される)を提供するように構成されてもよい。加えて、いくつかの例において、「アーカイバ」に提示されるクエリにおけるFROM句のアイテムは、「アーカイバ」エンティティの名称および/またはデータオブジェクトの名称(たとえば永続的記憶装置上で維持される)であってもよい。FROM句のアイテムがデータオブジェクトの名称の場合、これらは、作成DDLにおけるアーカイブされたリレーションにマッピングしてもよい。これに加えてまたはこれに代えて、アーカイバの名称を用いてアーカイバインスタンス(2つ以上のアーカイバがある可能性がある)をルックアップしてから、このアーカイバインスタンスに対する実行(クエリ)をコールしてもよい。クエリにおいて使用される属性名は、希望に応じて、CREATE ARCHIVED RELATION DDLまたはその他適切なDDLにおいて指定される列の名称であってもよい。クエリを実行する間、「アーカイバ」は、txn T_nの時点でコミットされた変更を含むデータオブジェクトのスナップショット上でクエリを実行してもよい。上記T_nは、データオブジェクトに対するイベントがストリーミング入力として提示された最新のトランザクションよりも前である。特に、「後の」トランザクションに対応する入力として与えられたストリーミングデータオブジェクトイベントはないであろう。
【0057】
さらに、「アーカイバ」は、このクエリが実行されたトランザクションのIDを返してもよい。このIDは、後のトランザクションのIDが前のトランザクションのIDよりも大きくなるように単調に増加する数字(必ずしも連続しない)であってもよい。更新イベントの場合、「アーカイバ」は、ストリーミングイベントの一部として、OLD値とNEW値を与えてもよい。これに加えてまたはこれに代えて、いくつかの例では、永続性サービスが、OLD値およびNEW値双方についての変更通知をCQサービスに送ってもよい。このようにして、CQサービスは、適切な動作をアーカイブされたリレーションに対して行なうことができるであろう。削除イベントの場合、「アーカイバ」は、削除イベントを、妥当性検査にパスした場合に(いくつかの例では「場合にのみ」)、ストリーミングイベントとして与えてもよい。いくつかの例において、アーカイバの機能は、クエリが処理しないデータオブジェクトイベントはないというシナリオを可能にし得る。CQLエンジン156も、すべてのデータオブジェクトイベントの処理をスキップすることによりイベントは重複して処理されないというシナリオを可能にし得る。この場合、トランザクション識別子<=「スナップショット」クエリの実行の一部として「アーカイバ」によって返されるトランザクション識別子である。いくつかの例において、アーカイバは永続性サービスと同等であり得る。これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、CQLエンジンにおいて維持されてもよく、スナップショットID(増大する識別子)はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル(全体)クエリプランに結合し得る場所を表わしてもよい。イベントがCQLエンジンに達すると、このイベントに対し、スナップショットIDを、その中のコンテキストIDおよびトランザクションIDの値を用いて計算してもよい。スナップショットIDは、CQLエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットIDは次に、入力キューのスナップショットIDと比較してもよい。イベントのID>キューのIDであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを避けるために無視してもよい。
【0058】
固有のCQLコンセプトとしてアーカイブされたリレーション154を導入することによって、CQLエンジン156は、アーカイブされたリレーション154に対して定義されたクエリの演算子の状態を初期化するためにフェッチする必要があるデータの最適量を決定することができる。いくつかの例において、クエリのコンパイルの最終ステップとして、クエリプラン生成(および/またはグローバルプランとのマージ)に従い、状態初期化フェイズを導入して、「アーカイバ」に対して実行する必要があるクエリの最適セットを決定してもよい(たとえば演算子の状態の初期化のために)。場合によっては、クエリのセット(たとえば最適セット)を決定するために使用される状態初期化アルゴリズムは、ステートフル演算子に遭遇するまで、一連の演算子の状態化の実現を遅らせるかもしれない(これはデータを集計ししたがってメモリ内のすべての詳細/事実の実現と比較すると取出すデータは少ないかもしれない)。クエリ実行の第1ステップは、状態初期化クエリが実行される前であっても、スナップショットクエリの実行および/またはクライアントへの結果の送達であろう。いくつかの例において、スナップショットクエリ(「アーカイバクエリ」とも呼ばれる)は、演算子を結果の内容によって初期化し得る状態初期化の一部であってもよい。次に、これら結果を下流の演算子(たとえば下流の演算子すべて)に伝搬することによって、結果を出力してもよい。次に、状態初期化アルゴリズムによって決定されたクエリを実行してもよい。この第1ステップの終了時に、すべての演算子それぞれの状態は適切に初期化されクエリはストリーミングイベントを処理できる状態になっているであろう。
【0059】
CQLクエリが、システム再起動中に、アーカイブされたリレーション154を参照するとき、CQLエンジン156は、クエリ内の実行演算子の状態がシャットダウン前に持っていた値に初期化されるというシナリオを可能にするように構成されてもよい。これに代えてまたはこれに加えて、クエリが(再)起動される度に、それがシャットダウンの一部であろうと自発的なものであろうと、クエリは、フレッシュなすなわち新たなアーカイバクエリを発行することによって状態を再び初期化してもよい。いくつかの例において、これは、t0+デルタの時点ではt0の時点と異なり得る。場合によっては、状態初期化アルゴリズムを、この機能を扱うように構成してもよい。いくつかの例において、各々(またはすべて)のアーカイブされたリレーション154は、リレーションを構成するイベントを追跡するアーカイバオブジェクトにマッピングしてもよく、自身に対して発行されたSQLクエリ(データベーステーブルと同様)に答えてもよい。加えて、CQLクエリにおける実行演算子の状態の初期化は、CQLクエリが依存するアーカイブされたリレーション154にマッピングするアーカイバに対して適切なSQLクエリを発行することと、戻された結果を使用して演算子の状態を初期化することとを少なくとも含む、2段階のプロセスであってもよい。(アーカイバから得た)イベントの実現を遅らせると、結果としてメモリおよび/または処理時間消費が削減されるかもしれない。これに加えてまたはこれに代えて、メモリの削減は、メモリを最小にする適切な演算子が発見されたためであるかもしれない。たとえば、集計された/要約されたデータをメモリに入れると、大幅なメモリの削減につながり得る。
【0060】
いくつかの例において、状態初期化プロセス(これは、全体のプロセスの中の1ステップであってもよく、CQLクエリの起動時に実装されてもよく、アーカイブされたリレーション(複数可)を参照する)は、メタデータオブジェクトを用いてクエリの論理プランを取得することと、論理プランから物理プランを構築することと、ローカル物理プランをオプティマイザを用いて最適化することと、オペレーションを共有してグローバル物理プランを得ることと、補助構造(たとえばシノプシス、記憶、キュー等)を追加することと、クエリをインスタンス化すること(実行演算子を構築しおよび/または実行構造をサポートする)とを、含み得る。加えて、状態初期化アルゴリズムをコールする適切な場所は、ローカル物理プラン最適化の直後であってもよい。いくつかの例において、状態初期化アルゴリズムは、クエリがアーカイブされた1以上のリレーション154に依存するときにコールされるだけであってもよい。
【0061】
いくつかの例において、バイナリ演算子の場合、子演算子をクエリ演算子としてマークしてもよい。また、クエリプラン全体のトラバース後にクエリ演算子が識別されない場合、ルートをクエリ演算子としてマークしてもよい。演算子がクエリ演算子として識別された後、インスタンス化フェイズの間にイズクエリ演算子(isQueryOperator)フラグがセットされた場合、構築されたアーカイバクエリを実行する方法が演算子ファクトリコードからコールされるであろう。次に、戻された結果セットをタプルのセットに変換すればよく、リストを実行演算子インスタンスにセットすればよい。このようにして、インスタンス化されると、状態を必要とする実行演算子は、その状態を初期化するのに十分であろうタプルのリストを有し得る。インスタンス化されると、これらタプルを用いて状態を初期化しこれを下流に伝搬する方法をコールするトポロジー順でクエリプランに対してもう1つのパスを行なえばよい。この方法は演算子固有であってもよく、および/または、初期化処理は、シノプシスの投入、内部データ構造の維持等と同様であってもよい。
【0062】
いくつかの例において、「売上高」のアーカイブされたリレーション154の上の下記CQLクエリを実装してもよい。
【0064】
いくつかの例において、CQLエンジン156においてコンパイルされたときのクエリプランは、次のように説明することができる。
【0066】
いくつかの例において、CQLエンジン156は、上記クエリをコンパイルするとき、このクエリは、その起動時の状態は外部から利用することができ潜在的に大きい可能性があるリレーション(たとえばアーカイブされたリレーション154)に対して表現されると、判断し得る。CQLには、ステートフルな演算子(たとえばGROUP BY、PATTERN)のセットがある一方で、ステートフルでない演算子(たとえばFILTER、PROJECT、OUTPUT)があるであろう。状態初期化アルゴリズムは、考慮するシナリオに対して次のように機能し得る。すなわち、REL_SOURCE演算子は、アーカイブされたリレーションに対してステートレスなので、アーカイバのコールをスキップし得る。次のFILTERも、ステートレスなので、状態に対するアーカイバのコールをスキップし得る。次に、GROUP BY演算子に遭遇する可能性があり、これは、アーカイバを呼出し、下記SQLクエリ(希望に応じてアーカイバクエリはサブクエリに基づく手法を用いて形成されたクエリであってもよく下記のものよりも複雑であってもよい)を用いて、その状態を満たしてもよい。
【0068】
なお、ユーザのクエリはCOUNT集計を含まないかもしれないが、GROUP BYはCOUNT集計を有するSQLクエリを発行し得る。その理由は次の通りである。この情報を、(その状態の一部としての)GROUP BY演算子によって要求して、グループ(この例では「productid」に対応する)が空になりグループに関連して使用し得る何等かのリソースを(メモリのように)解放するか否か、判断することができる。
【0069】
次に、−veタプルが到着した状況について考える。上記シナリオにおいて、REL_SOURCEは、状態を維持しないかもしれず、その場合、一連の演算子の中の次の演算子に判断させるであろう(「通常の」CQLリレーションのように例外をスローするのではなく)。FILTER演算子も、状態を維持しないかもしれず、その場合、同じようにするであろう。次に、GROUP BY演算子はタプルを見ることになるであろう。その状態は初期化されているので、対応するグループの位置を正しく確認し残りの処理を実行することができるであろう。たとえば、これが、region=「APAC」でproductid=「携帯電話」のタプルであれば、SUM集計関数は、タプルに存在する額だけ、「携帯電話」のその時点までの合計を減じるであろう。
【0070】
いくつかの例において、「売上高」のアーカイブされたリレーション154の上の下記CQLクエリを、上記例における合計ではなく中央値を求めるために実装してもよい。
【0072】
いくつかの例において、CQLエンジン156においてコンパイルされたときのクエリプランは、次のように説明することができる。
【0074】
いくつかの例において、状態初期化アルゴリズムは、考慮するシナリオに対して次のように機能する。REL_SOURCE演算子は、アーカイブされたリレーションに対してステートレスなので、アーカイバのコールをスキップし得る。次のFILTERも、ステートレスなので、状態に対するアーカイバのコールをスキップし得る。次に、GROUP BY演算子に遭遇する可能性がある。この演算子はステートフルなので状態の初期化を要求し得る。ここで、クエリは、少なくとも1つの包括的な(holistic)関数(MEDIAN)を必要とするので、集計された/要約状態をデータベースから得るだけでは十分でないかもしれない。MEDIANを計算する対象である値のセット全体を、GROUP BY状態に対して要求してもよい。
【0075】
したがって、この段階では、最下位のステートフル演算子を識別しており、かつ、より詳細な事項を要求してその状態を構成すると判断しているので、演算子プランを逆方向(すなわち「下に」)トラバースすればよい。すなわち、このプランをこの段階からは上から下にトラバースすればよい。いくつかの例において、状態を構築する責任は、ツリーにおいて下方向に次の演算子にある。この演算子はこの場合FILTERであり、これは、要求された値のセットをメモリに入れることができる以下のSQLクエリを(「アーカイバ」に)発行し得る。
【0077】
いくつかの例において、これらタプルが取出されると、FILTERは、これら値を上流に伝搬してもよく、GROUP BYは、その状態を、ツリーまたはグラフ(たとえば、限定されないが増強された赤黒ツリー等)を構成することによって構築してもよい。このデータ構造によって、次の(O(log n)時間)増分MEDIAN計算を非常に高速で行なうことができる。いくつかの例において、上記クエリにFILTERがない場合、状態を構築する責任はREL_SOURCE演算子にあり、リレーションの全内容(最適化のように、クエリによってアクセスされる関連フィールドのみが、行全体ではなく各行に対して取出される。当然ながら、すべてのフィールドがアクセスされる場合は行全体がフェッチされる)がメモリに取込まれているであろう。
【0078】
いくつかの局面において、アーカイブされたリレーション154に基づいてクエリに到達するマイナスイベントを処理するためには、他のサポートが有用であろう。結合のような射影、バイナリ演算子等のCQLエンジン156演算子の中には、系統(lineage)シノプシスを維持するものがある。この系統シノプシスにおけるルックアップは、タプルIDに基づく。プラスタプルが届くと、これをシノプシスに挿入すればよい。この演算子にマイナスタプルが届くと、タプルIDに生じる系統シノプシスをルックアップする。アーカイブされたリレーション154のコンテキストに生じ得る問題は次の通りである。
【0079】
1.クエリが起動したとき、系統シノプシスを維持する演算子はクエリ演算子として識別される場合があり、これは、アーカイバにクエリし返された結果をタプルに変換し系統シノプシスに入れる場合がある。
【0080】
2.加えて、クエリが実行を開始したとき、これが受ける最初のタプルは、アーカイブされたプラスタプルのうちの1つに対応するマイナスタプルの場合がある。ここで、プラスおよびマイナスタプルのIDは一致しない場合があり、このことは、ルックアップの失敗および間違った結果につながる。
【0081】
3.通常のリレーションの場合、リレーションソースは、プラスおよびマイナスタプルが同一のIDを確実に有するようにするのに役立つであろう。なぜならこれはシノプシスを維持し得るからである。しかしながら、アーカイブされる場合は、これが可能でないことがある。
【0082】
このため、BEAM永続性レイヤはイベントIDを各イベントに割当てればよく、イベントの挿入(プラス)、削除(マイナス)、および更新通知はすべてこのIDの同一の値を有するであろう。この機能を利用することによって、上記問題を回避すればよい。したがって、もう一つの句をアーカイブされたリレーション154のDDLに追加することにより、EVENT IDENTIFIER句を指定すればよい。これは、CQL bigint型の列であってもよく、この列は、イベントのプラス、マイナス、および更新タプルについて同じ値を有するであろう。
【0083】
場合によっては、CQLエンジン156内で、EVENT IDENTIFIER句において指定された列を利用してもよい。たとえば、アーカイバがクエリされるとき、このフィールドは、選択リストに存在するように強制されてもよく、このフィールドの値を使用することにより、記録をタプルに変換する一方でタプルIDを設定してもよい。また、通常の入力イベントが来たとき(たとえばクエリが実行しているとき)、このフィールドにおける値には、タプルの値をリレーションソースコードのITupleに変換する一方で、タプルIDが割当てられてもよい。こうすることにより、イベントのプラスおよびマイナスが確実に同じタプルIDを有するようにするための構成が可能になるであろう。
【0084】
いくつかの例において、以下の構文をアーカイブされたリレーションのDDLに利用してもよい。
【0086】
アーカイブされたリレーションを作成するためのこのDDLは、エンドユーザおよび他の構成要素からは見えない場合がある。たとえば、アーカイブされたリレーションの作成は、EPNがCQLプロセッサノードに接続されたデータオブジェクトノードを含むときに、CQLプロセッサコードにより、「隠れて」処理することができる。たとえば以下のEPNについて考える。
【0088】
このEPNコードは、CQLエンジン156において作成するアーカイブされたリレーションの列名としてデータオブジェクトのフィールド名を使用してもよい。そうすることにより、フィールドの名称とフィールドの順序が確実に一致する。
【0089】
加えて、いくつかの例において、アーカイブされたストリームを、CQLエンジン156および/またはその他のエンジンを介して可能にしてもよい。概念上、アーカイブされたストリームは、アーカイブされたリレーションの特徴によく似ているかもしれない。しかしながら、ストリームとリレーションの間には意味の相違があるので、アーカイブされたリレーションの特徴との比較で、何らかの変更を、アーカイブされたストリームの設計および構文に行なえばよい。たとえば、リレーションの内容には、加算、更新、または削除が発生したときに、変化が生じ得る。このため、この内容は、時間の経過とともに、サイズが大きくまたは小さくなる可能性がある。しかしながら、ストリームの場合、定義により、更新および削除は不可能である。よって、ストリームのサイズは大きくなり続けるしかない。したがって、ストリームの過去の内容のサイズは非常に大きく、ほとんどの場合、ユーザは、アーカイバによって維持される直近の過去のサブセットにしか興味がない。
【0090】
このため、以下の構文をアーカイブされたストリームのDDLに利用してもよい。
【0092】
ここで、ARCHIVERおよびENTITY句は、アーカイブされたリレーション154と同じ意味を有し得る。しかしながら、EVENT IDENTIFIER句は必要でないかもしれない。なぜなら、これは一般的に、ストリームに対して入力として到来することができないマイナスイベントを扱うだけだからである。加えて、REPLAY LAST句によって、ユーザは、興味ある直近の過去の部分を指定することができる。ユーザはこれを、時間範囲として、または行の数によって指定することができる。よって、たとえば、REPLAY句は、REPLAY LAST 30MINUTES(この場合過去30分において到達した記録をアーカイバからフェッチすればよい)、または、REPLAY LAST 50ROWS(この場合、到着時間で並べられた最新の50記録をアーカイバからフェッチすればよい)であってもよい。
【0093】
TIMESTAMP COLUMN句は、アーカイバにクエリしている間に返されるであろう記録の識別に利用してもよい。これは、アーカイバクエリの結果セットの一部である記録を決定するアーカイバクエリのWHERE句において使用してもよい。この列の値は、タイムスタンプをCQLエンジン156内部のタプル(アーカイバにクエリすることによって得られる)に割当てる間に利用してもよい。この列の名称は、BEAM永続性によって割当てられた作成タイムスタンプを有するDO内の列の名称である可能性がある。
【0094】
加えて、いくつかの例において、構成ウィンドウモジュール150は、CQLエンジン156の1つ以上のアーカイブされたリレーション154を構成するためのウィンドウサイズ158を、生成する、受ける、および/または決定するように構成されてもよい。しかしながら、いくつかの例において、アーカイブされたリレーションに対して異なるウィンドウサイズを定めても、アーカイブされたリレーションの別々のインスタンスは作成されないかもしれない。むしろ、ウィンドウが適用されたとき、アーカイブされたリレーションのインスタンスは1つしかないかもしれず、ウィンドウは、特定のクエリにとって「興味」があるアーカイブされたリレーションにおけるデータを求めればよい。上記のように、ウィンドウサイズ158は、アーカイブされたリレーション154のウィンドウw1、w2、および/またはwNのサイズを構成し得る。このようにして、ユーザは、ウィンドウサイズを制御することができ、希望に応じて、ビジネスイベントデータおよび/または個人的関心、ビジネスの目標、および/またはその他の要素に関連する情報に少なくとも基づいて、ウィンドウのサイズを指定すればよい。
【0095】
さらに、いくつかの例において、イベントカウントモジュール152は、CQLエンジン156内で、または、ストリームもしくはアーカイブされたリレーション154の中の変更イベントを正しくカウントできるように構成されたその他のエンジン内で、1つ以上のリスニングサービス160を実装するように構成されてもよい。簡単に述べたように、連続クエリ162が、CQLエンジン156によって管理されるストリームおよび/またはアーカイブされたリレーション164に対する従属性を示すとき、CQLエンジン156はリスニングサービス160を実装してもよい。少なくともいくつかの例において、リスニングサービスを実装するタイミングにより、ストリーム/リレーション164の中の変更イベントが正しくカウントされるか否かを判断することができる。加えて、上記のように、いくつかの例において、連続クエリ162は、履歴および/またはウェアハウスデータのデータ記憶装置166に対してクエリすることによって、アーカイブされたリレーション164のデータを初期化するように、構成されてもよい。
【0096】
いくつかの例において、クエリがCQLエンジン156内で実行されるとき、これは、最初にクエリをデータオブジェクト補助記憶装置に対して実行することによってデータオブジェクトの現在の状態を確立してからデータオブジェクトからの変更通知をリッスンし処理する場合がある。そうすると2つの問題が生じる。すなわち、CQLエンジン156が最初のクエリを実行している間に変更通知が見落とされるかもしれないことであり、もう1つは、最初のクエリに変更が既にあった場合変更通知が二重カウントされるかもしれないことである。
【0097】
変更通知の見落としは、最初のクエリが起動される前に変更通知リスナーを確立するが、アーカイバクエリ実行が完了するまでおよび/または状態初期化がなされるまでこれらを処理しないことによって、解消することができる。これら変更通知は、CQLエンジン156がこれらを処理する準備ができるまで、メッセージングサービス(JMS)にバッファすればよい。場合によっては、変更通知の二重カウントの解消を、追加情報を永続性サービスに提供することで、どの変更通知が最初のクエリ結果に含まれどの変更通知がこれに含まれていないかCQLエンジン156に判断させることにより、実行してもよい。
【0098】
いくつかの例において、最後のトランザクションのトランザクションIDを含む各データオブジェクトに、その他の列を追加する(たとえばDATAOBJECT_ID)ことにより、このデータオブジェクトのインスタンス(行)に影響を及ぼしてもよい。しかしながら、他の例では、その他の列は追加せず、その代わりにトランザクションのコンテキストを利用してもよい。このトランザクションIDは、JTAのような他のトランザクション機構と混同されない内部BEAMアーティファクトであってもよい。このトランザクションIDは、いくつかの例において、単調に増加する整数であってもよい。同一のJTAトランザクションによって修正されるいくつか(またはすべて)のデータオブジェクトインスタンス(たとえば行)を、同一のトランザクションIDでタグ付けしてもよい。加えて、トランザクションIDを昇順でコミットしてもよい。この同じ列は、データオブジェクト変更通知に含まれていてもよい。上述のことから、クエリがMAX(DATAOBJECT_TID)を含む場合、クエリ結果において最大のトランザクションIDはわかっているであろう。このため、変更通知におけるトランザクションIDの値を、最大値と比較すればよい。なぜなら、それよりも小さいかまたはそれに等しい値は無視すればよく(すなわち既にカウントされているであろうから)、それよりも大きな値を処理すればよい(まだカウントされていないであろうから)。
【0099】
しかしながら、場合によっては、トランザクションIDを昇順でコミットするために、データオブジェクトトランザクションを順番に並べてもよい。しかしながら、これは同時性に不利益な影響を与え得る。それでも、同時性は、コンテキストIDの概念を導入することによって高めることができる。いくつかの例において、各コンテキストIDはそれ自身のトランザクションIDを維持してもよい。BEAMデータオブジェクトに対して演算を実行するJTAトランザクションが、BEAMコンテキストへの包括的アクセスを得てもよい。次に、同じBEAMコンテキストを、上記JTAトランザクションによって実行される演算(たとえばすべての演算)に使用してもよく、最終的には、JTAトランザクションのコミットまたはロールバック時に解放すればよい。こうすれば、BEAMコンテキストにおいて処理を並列に進めることができる。よって、同時性のレベルは、BEAMコンテキストの割当てに釣合ったものになるであろう。その他の列(DATAOBJECT_CID)を、各データオブジェクトに追加することにより、最後のコンテキストのIDを保持して、そのデータオブジェクトのインスタンス(行)を修正することができる。しかしながら、他の例では、その他の列は追加されず、その代わりにトランザクションコンテキストを利用してもよい。コンテキストIDは、トランザクションIDのように、データオブジェクトの変更通知に含まれてもよい。しかしながら、これにより、二重カウントを解消するためにコンテキストIDに対してMAX(DATAOBJECT_TID)を取得することを必要とし得るという点において、クエリ側に対する要求が変化し得る。
【0100】
いくつかの例において、同じレベルの同時性は、トランザクションコンテキストエンティティの概念が導入されるのであれば、データオブジェクトに他の列を追加することなく、得ることができる。次に、新たなJavaクラスおよび関連するJPAエンティティを作成してデータベースにおけるコンテキストIDの状態を維持してもよい。トランザクションコンテキストエンティティは、コンテキストIDと、関連する(最大、最後に使用された)トランザクションIDとを含み得る。コンテキストIDはシーケンスとして生成してもよく、エンティティに対する主キーであってもよい。
【0101】
永続性サービスは、初期化されると、構成された数のトランザクションコンテキストインスタンスを作成してもよい。これらトランザクションコンテキストインスタンスは、この永続性サービスが単独使用するためのものであってもよい。別の永続性サービスが別のサーバ上で初期化される場合、これも、構成された数のトランザクションコンテキストインスタンスを作成してもよい。このやり方で、各永続性サービスがコンテキストの固有のセットを有することを保証してもよい。永続性サービスは、トランザクションコンテキストのインスタンスを作成してもよく、これらをJPAを介して存続させてもよい。これはシーケンス状に並べられたエンティティでありこのシーケンスはコンテキストIDであるので、作成されたトランザクションコンテキストインスタンスは自動的に固有のものである。作成された各トランザクションコンテキストは次の連続番号を得るであろう。永続性サービスは、シャットダウンされるとき、作成したトランザクションコンテキストインスタンスを削除してもよい。場合によっては、これによってインスタンスがデータベースから削除されてもよい。
【0102】
いくつかの例において、データオブジェクト演算(たとえばすべてのまたはいくつかのデータオブジェクト演算)は、最終的にはEJB法(たとえばプロセスデータオブジェクト演算と呼ばれる)によって行なってもよい。この方法は、挿入、更新、アップサート(upsert)、および/または削除に対する派生があるデータオブジェクト演算の集合体を利用してもよい。各データオブジェクト演算は、対象とするデータオブジェクトを、名称、特定の演算、およびこの演算に必要なデータによって、指定してもよい。データオブジェクト演算は、データオブジェクト演算の対象および/または任意の数のデータオブジェクトの組合わせを含み得る。データオブジェクト演算は、演算がデータオブジェクト演算に追加された順序で実行してもよい。プロセスデータオブジェクト演算法は、TransactionAttributeType.REQUIREDとして定義してもよく、これは、JTAトランザクション内でコールされた場合このトランザクションに参加し得ることを意味する。しかしながらJTAトランザクション外でコールされた場合、アプリケーションサーバは、JTAトランザクションを、この方法のコールの期間中に起動してもよい。いくつかの例において、このことは、プロセスデータオブジェクト演算が常にJTAトランザクション内で機能しているであろうことを意味する。加えて、データオブジェクトに対するすべてのまたはいくつかの演算は、JTAトランザクション内で発生し得る。
【0103】
いくつかの例において、変更イベントの二重カウントの解消は、以下の動作によって可能になるであろう(これは希望に応じて任意の適切な順序で実行すればよい)。たとえば、プロセスデータオブジェクト演算がコールされたときに以下の動作を行なう(以下の動作には番号が付けられているが、これらの番号は、説明を助けるためのものに過ぎず、この一組の動作を特定の順序または必要な何らかの動作に限定するものではない)。
【0104】
1.関連するJTAトランザクションからトランザクションコンテキストをフェッチすることを試みてもよい。関連するトランザクションコンテキストがある場合はそれを使用すればよい。しかしながら、関連するトランザクションコンテキストがない場合は次のようにする。
【0105】
a)起動時に永続性サービスによって作成された利用可能なトランザクションコンテキストインスタンスのセット(プール)からのトランザクションコンテキストインスタンスに対する排他ロックを取得してもよい。トランザクションコンテキストが利用可能でなければ、トランザクションコンテキストが利用可能になるまでコールをブロックしてもよい。このロックはJavaおよび/またはデータベースにおいて行なってもよい。
【0106】
b)このトランザクションコンテキストにおけるトランザクションIDを、関連するJTAトランザクションのトランザクションIDとなり得る、一連の数のうちの次の数に増分してもよい。
【0107】
c)トランザクションコンテキストインスタンスを、JTAトランザクションに、アプリケーションリソースとして「添付」してもよい。そうすることによって、この1つのJTAトランザクションの中で複数のコールがなされた場合は、永続性サービスが、トランザクションコンテキストを、その関連するJTAトランザクション(たとえば上記1の動作のもの)を取得することができるであろう。これによって、JTAトランザクションがBEAMサーバの中から開始されようとBEAMサーバなしで開始されようと、同じJTAトランザクションの中で実行される動作に対して同じトランザクションコンテキストを使用できることを保証し得る。
【0108】
d)トランザクションコンテキストインスタンスを、トランザクション同期リスナーとして、関連するJTAトランザクションに追加してもよい。これによって、永続性サービスに、JTAトランザクションがいつ完了したか知らせて、適切な動作を行なえるようにすることができる。
【0109】
e)増分されたトランザクションIDを有するトランザクションコンテキストエンティティをマージしてもよい。いくつかの例において、このデータベース更新は、関連するJTAトランザクション内でも発生し得る。
【0110】
2.指定されたデータオブジェクト動作を実行してもよい。トリガされた変更通知を、トランザクションコンテキストからのコンテキストIDおよびトランザクションIDでタグ付けしてもよい。
【0111】
3.プロセスデータオブジェクト演算法のコールが終了し得る。
4.同じJTAトランザクション内で他のコールがなされた場合、上記動作1は、添付された」トランザクションコンテキストをピックアップして動作2に進めばよい。
【0112】
5.場合によって、JTAトランザクションがコミットするならば、
a)実行されたデータオブジェクト動作をデータベースにコミットしてもよい。
【0113】
b)データオブジェクトの変更通知を送ってもよい(JMS)。
c)トランザクションコンテキストのマージをコミットしてもよい。
【0114】
d)トランザクションが完了しトランザクションコンテキストを次のトランザクションによる使用のために解放してプールに戻し得ることを、永続性に通知してもよい。いくつかの局面において、これはコミット後のある時点で起こり得る。
【0115】
6.場合によって、JTAトランザクションがロールバックするならば、
a)実行されたデータオブジェクト動作をロールバックしてもよい。
【0116】
b)データオブジェクトの変更通知を破棄してもよい(JMS)。
c)BEAMトランザクションコンテキストのマージをロールバックしてもよい。
【0117】
d)トランザクションが完了したのでトランザクションコンテキストを次のトランザクションによる使用のために解放してプールに戻し得ることを、永続性に通知してもよい。いくつかの局面において、これはロールバック後に起こり得る。
【0118】
ある例において、クエリを実行して初期状態をデータオブジェクト補助記憶装置から取得するとき、クエリを不可分的に実行することにより、UNIONもトランザクションコンテキストテーブルに含めてもよい。このようにして、クエリ結果に加えて、クエリ結果におけるすべてのデータに対する各BEAMコンテキストの最大のコミットされたトランザクションIDを受けることができる。トランザクションコンテキスト情報は、データオブジェクトの変更通知を検査し変更通知におけるIDをトランザクションコンテキストテーブルにおけるIDと突合せて検査することによって二重カウントを解消することを、可能にする。これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、CQLエンジンにおいて維持されてもよく、スナップショットID(増大する識別子)はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル(全体)クエリプランに結合し得る場所を表わしてもよい。イベントがCQLエンジンに達すると、このイベントに対し、スナップショットIDを、その中のコンテキストIDおよびトランザクションIDの値を用いて計算してもよい。スナップショットIDは、CQLエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットIDは次に、入力キューのスナップショットIDと比較してもよい。イベントのID>キューのIDであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを回避するために無視してもよい。
【0119】
いくつかの例において、永続性レイヤはコンテキストID(ワーカー(worker)識別子)およびトランザクションID(トランザクション識別子)に各変更イベント通知を与えてもよく、および/または、永続性レイヤはトランザクションコンテキストテーブルを維持してもよい。加えて、クエリ起動時に、CQLエンジンは、トランザクションコンテキストテーブルからの「スナップショット」情報(ワーカー識別子、トランザクション識別子対)にクエリし、増大するスナップショットIDをこれに関連付けてもよい。また、CQLエンジンは、起動時に「コネクタ」演算子の入力キューにスナップショットIDを設定してもよい。加えて、クエリ実行時に、CQLエンジンは、入力イベントにおけるワーカー識別子および/またはトランザクション識別子フィールドと、維持されている「スナップショット」情報を用いて、各入力イベントのスナップショットIDを計算してもよい。クエリ実行時に、CQLエンジンはまた、入力イベントのスナップショットIDを、(クエリ起動時の)入力キューにおいて設定されたものと比較することにより、イベントを処理するべきか無視すべきか判断してもよい。以下は、ワーカーおよびトランザクションID句のDDLの一般的な形態の一例である。
【0121】
いくつかの例において、アーカイバ(Archiver)はCQサービスによって維持されてもよく、エンティティ(Entity)は引用されたストリングとしてのデータオブジェクトの名称であってもよく、イベントID(Event ID)はこのリレーションに対して固有イベントID列として機能し得るロングタイプの列であってもよく、ワーカーID(Worker ID)は永続性の生成された変更通知におけるコンテキストID列にマッピングし得るロングタイプの列であってもよく、トランザクションID(Transaction ID)は、永続性の生成された変更通知におけるトランザクションID列にマッピングし得るロングタイプの列であってもよい。以下は実装例である。
【0123】
同様に、いくつかの例において、これら2つの句を、アーカイブされたストリームのREPLAY句の後に追加してもよい。
【0124】
先に述べたように、各データオブジェクトインスタンスを、これを修正した最新のコンテキストおよびトランザクションIDで実際にタグ付けする必要はないであろう。いくつかの例において、この情報は、代わりにトランザクションコンテキストエンティティから受けることができる。そうするための1つのやり方は、先に述べたように、データオブジェクトからの所望のデータおよびトランザクションコンテキストエンティティの内容双方に対して不可分的にクエリすることである。不可分性実現のために、これを1つのクエリのみを用いて実行してもよい。たとえば、UNION句を用いることにより、2つの異種のクエリからの結果セットを1つのクエリに追加することができる。いくつかの例において、上記データオブジェクトおよび/または永続性サービスは、
図1のデータ記憶装置166によって実現してもよい。
【0125】
サービスプロバイダコンピュータ106および/またはユーザ装置104に存在し得るその他の種類のコンピュータ記録媒体(これも非一時的であってもよい)は、プログラマブルランダムアクセスメモリ(PRAM)、SRAM、DRAM、RAM、ROM、電気的に消去可能なプログラマブル読出専用メモリ(EEPROM)、フラッシュメモリもしくはその他のメモリ技術、コンパクトディスク読出専用メモリ(CD−ROM)、デジタル汎用ディスク(DVD)もしくはその他の記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または、所望の情報を格納するのに使用することができサービスプロバイダコンピュータ106および/またはユーザ装置104からアクセス可能なその他の媒体を含み得るがこれらに限定されない。上記のうちのいずれかを組合わせたものも、コンピュータ読取可能な媒体の範囲に含まれるはずである。
【0126】
これに代えて、コンピュータ読取可能な通信媒体が、コンピュータ読取可能な命令、プログラムモジュール、または、搬送波等のデータ信号内で伝送されるその他のデータ、またはその他の伝送を含む場合がある。しかしながら、本明細書で使用されるコンピュータ読取可能な記録媒体は、コンピュータ読取可能な通信媒体を含まない。
【0127】
図2は簡略ブロック
図200を示し、これを用いて、アーカイブされたリレーションを有する連続クエリの管理の特徴を説明することができる。上記の、いくつかの例における、アーカイブされたリレーション、構成可能なアーカイブされたリレーションのウィンドウ、および/または変更イベントのカウントについて、本明細書で説明することができる。示されるように、
図2は、(たとえば射影203に関連する)アーカイブされたリレーションを管理するための、CQLエンジン156および/またはCQサービス202の、少なくとも1つの実装例を示す。いくつかの例において、アーカイブされリレーションを含むクエリ(たとえば連続クエリ)162が識別されたとき(たとえば、射影203に関連するグループ化(Group By)演算子204および/または売上情報(Sales Info)演算子206が、ストリームまたは履歴データではなくアーカイブされたリレーションを参照する場合)、CQLエンジン156は、このクエリ162をパース(parse)してCQサービス202のアーカイバ208に送ってもよい。加えて、いくつかの例において、CQLエンジン156は、この場合クエリ演算子としてのGroupAggr(またはグループ化204)演算子を識別してもよく、この演算子のためのアーカイバクエリを構成してもよい。このアーカイバクエリは次にアーカイバ208に送ってもよい。場合によっては、この時点で、CQサービス202は外に出てスナップショットを得てもよい(たとえば永続的データ記憶装置166からおよび/またはBIサーバから)。また、永続性レイヤ(BI/DBを含む)210は多数のエントリを有し得るが、(たとえばグループ化演算子204があるので)CQサービス202は積の合計を取出すだけでよい。このため、CQLエンジン156は、変更イベント212と履歴データ166双方を受けることができる。そこで、出力214は、データ記憶装置166からの元の履歴データに加えて取出した変更イベント212を反映し得る。いくつかの例において、−12,75という変更イベントを受けると、+12,125は、出力214における更新された合計値を反映し得る。CQLサービス202を変更イベント212につなぐ、点線で示した矢印は、CQLサービス202が、変更イベントを、永続性レイヤ210から受けた後にCQLエンジン156に送ることができることを示している。クエリ162における上向きの矢印は、クエリ162に関連するクエリプランにおけるイベントの流れを示すことを意図している。
【0128】
図3は、本開示の実施形態を取入れることができるイベント処理システム300の簡略化された高レベルの図を示す。イベント処理システム300は、1つ以上のイベントソース(304,306,308)と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバ(EPS)302と、1つ以上のイベントシンク(310,312)とを含み得る。イベントソースは、EPS302が受けるイベントストリームを生成する。EPS302は、1つ以上のイベントストリームを1つ以上のイベントソースから受けることができる。たとえば、
図3に示されるように、EPS302は、入力イベントストリーム314をイベントソース304から受け、第2の入力イベントストリーム316をイベントソース306から受け、第3のイベントストリーム318をイベントソース308から受ける。1つ以上のイベント処理アプリケーション(320,322,324)をEPS302上で展開しEPS302によって実行することができる。EPS302によって実行されるイベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、顕著なイベントとして入力イベントストリームから1つ以上のイベントを選択する処理ロジックに基づいて1つ以上のイベントストリームを介して受けたイベントを処理するように、構成されてもよい。顕著なイベントは次に、1つ以上の出力イベントストリームの形態の1つ以上のイベントシンク(310,312)に送ってもよい。たとえば、
図3において、EPS302は、出力イベントストリーム326をイベントシンク310に出力し、第2の出力イベントストリーム328をイベントシンク312に出力する。ある実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、他の構成要素の変更を引起すことなくこれら構成要素のうちのいずれかを追加または削除することができるように、相互に切離される。
【0129】
ある実施形態において、EPS302は、共有サービスを有する、Equinox OSGiに基づくもののような、軽量Javaアプリケーションコンテナを含むJavaサーバとして実装してもよい。いくつかの実施形態において、EPS302は、たとえば、イベントの処理における極めて高いスループットおよびマイクロ秒のレイテンシを、JRockkit Real Timeを使用することによってサポートし得る。EPS302はまた、イベント処理アプリケーションを開発するためのツール(たとえばOracle CEP VisualizerおよびOracle CEP IDE)を含む開発プラットフォーム(たとえば完全リアルタイムエンドツーエンドJavaイベント駆動アーキテクチャ(EDA)開発プラットフォーム)を提供し得る。
【0130】
イベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、1つ以上の入力イベントストリームから1つ以上の顕著なイベントを選択するためのロジック(たとえばクエリ)を実行し、選択された顕著なイベントを1つ以上のイベントソースに1つ以上の出力イベントストリームを介して出力するように、構成される。
図3はこのようなイベント処理アプリケーション320に対するドリルダウンを提供する。
図3に示されるように、イベント処理アプリケーション320は、入力イベントストリーム318をリッスンし、入力イベントストリーム318から1つ以上の顕著なイベントを選択するためのロジックを含むクエリ330を実行し、選択された顕著なイベントを出力イベントストリーム328を介してイベントシンク312に出力するように、構成されている。イベントソースの例は、限定されないが、アダプタ(たとえばJMS、HTTP、およびファイル)、チャネル、プロセッサ、テーブル、キャッシュ等を含む。イベントシンクの例は、限定されないが、アダプタ(たとえばJMS、HTTP、およびファイル)、チャネル、プロセッサ、キャッシュ等を含む。
【0131】
図3のイベント処理アプリケーション320は、1つの入力ストリームをリッスンし選択されたイベントを1つの出力ストリームを介して出力するものとして示されているが、これは限定を意図したものではない。これに代わる実施形態において、イベント処理アプリケーションは、1つ以上のイベントソースから受けた複数の入力ストリームをリッスンし、モニタリングされたストリームからイベントを選択し、選択されたイベントを1つ以上の出力イベントストリームを介して1つ以上のイベントシンクに出力するように、構成されてもよい。同一のクエリを2つ以上のイベントシンクにおよび異なる種類のイベントシンクに関連付けることができる。
【0132】
制約がないという性質があるので、イベントストリームを介して受けるデータの量は、一般的に非常に多い。結果として、クエリのためにすべてのデータを格納またはアーカイブすることは、一般的に実用的ではなく望ましくない。イベントストリームの処理では、イベントをEPS302が受けるときに、受けたイベントのデータすべてを格納しなくても、イベントをリアルタイムで処理することが、必要である。したがって、EPS302は、イベントをEPS302が受けるときに受けたイベントすべてを格納しなくても、イベントを処理できるようにする特別なクエリ機構を提供する。
【0133】
イベント駆動型アプリケーションはルール駆動型であり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わすことができる。連続クエリは、受けたイベントに対して実行すべき処理を識別する命令(たとえばビジネスロジック)を含み得る。これは、クエリ処理の結果としてどのようなイベントを顕著なイベントとして選択し出力すべきかを含む。連続クエリは、データ格納装置に存続させ、イベントの入力ストリームを処理しイベントの出力ストリームを生成するために使用することができる。連続クエリは、典型的にはフィルタリングおよび集計関数を実行することにより、入力イベントストリームから顕著なイベントストリームを発見して抽出する。結果として、出力イベントストリームにおける外部へのイベントの数は一般的に、イベントを選択する元になった入力イベントストリームのイベントの数よりも遥かに少ない。
【0134】
有限のデータ集合に対して一度実行されるSQLクエリと異なり、特定のイベントストリームに対する、EPS302にアプリケーションによって登録されている連続クエリは、このイベントストリームにおいてイベントを受ける度に実行し得る。連続クエリの実行の一部として、EPS302は、受けたイベントを、連続クエリによって指定された命令に基づいて評価することにより、連続クエリ実行の結果として、1つ以上のイベントを顕著なイベントとして選択して出力するか否か判断する。
【0135】
連続クエリは、異なる言語を用いてプログラムしてもよい。ある実施形態において、連続クエリは、Oracle社が提供するCQLを用いて構成してもよく、Oracle社のComplex Events Procesing(CEP)という製品によって使用してもよい。Oracle社のCQLは、イベントストリームに対して実行できるクエリ(CQLクエリと呼ぶ)をプログラムするのに使用することができる宣言型言語である。ある実施形態において、CQLは、ストリーミングイベントデータの処理をサポートする構造が追加されたSQLに基づく。
【0136】
一実施形態において、イベント処理アプリケーションは、以下の構成要素タイプからなるものであってもよい。
(1)入力および出力ストリームならびにリレーションソースおよびシンクに対して直接インターフェイスする1つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを理解するように構成され、イベントデータを、アプリケーションプロセッサによってクエリできる正規化された形態に変換する役割を果たす。アダプタは、正規化されたイベントデータを、チャネルまたは出力ストリームおよびリレーションシンクに送ってもよい。イベントアダプタは、さまざまなデータソースおよびシンクに対して定めることができる。
(2)イベント処理の終点として機能する1つ以上のチャネル。特に、チャネルは、イベントデータを、イベント処理エージェントがそれに対して働くことが可能になる時点まで、キューに入れておく役割を果たす。
(3)1つ以上のアプリケーションプロセッサ(またはイベント処理エージェント)が、チャネルからの正規化されたイベントデータを消費し、クエリを用いてこれを処理することで顕著なイベントを選択し、選択された顕著なイベントを出力チャネルに送る(またはコピーする)ように、構成される。
(4)1つ以上のビーン(bean)が、出力チャネルをリッスンするように構成され、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態において、このユーザコードは、plain-old-Java-object(POJO)である。ユーザアプリケーションは、一組の、JMS、ウェブサービス、およびファイルライタ(writer)といった外部サービスを利用することによって、生成されたイベントを外部イベントシンクに送ることができる。
(5)イベントビーンは、出力チャネルをリッスンするために登録されてもよく、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態において、このユーザコードは、Oracle CEPイベントビーンAPIを用い、このビーンをOracle CEPによって管理できるようにしてもよい。
【0137】
一実施形態において、イベントアダプタは、イベントデータを入力チャネルに与える。入力チャネルは、入力チャネルによって与えられたイベントに対して機能する1つ以上のCQLクエリに関連するCQLプロセッサに接続される。CQLプロセッサは、クエリ結果が書込まれる出力チャネルに接続される。
【0138】
いくつかの実施形態において、イベント処理アプリケーションに対して、このイベント処理アプリケーションのさまざまな構成要素、これら構成要素が如何にして相互に接続されるか、およびこのアプリケーションによって処理されるイベントタイプを記載した、アセンブリファイルを、与えてもよい。イベントを選択するための連続クエリまたはビジネスロジックを指定するために、別々のファイルを与えてもよい。
【0139】
図3に示されるシステム300は、
図3に示されている構成要素以外の構成要素を有し得ることが理解されるはずである。さらに、
図3に示される実施形態は、本開示の実施形態を取入れることができるシステムの一例に過ぎない。他のいくつかの実施形態では、システム300の構成要素は
図3に示されるものよりも多くても少なくてもよく、2つ以上の構成要素が組合わされてもよく、または構成要素の構成または配置が異なっていてもよい。システム300は、パーソナルコンピュータ、ポータブルデバイス(たとえば携帯電話または装置)、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはそれ以外のデータ処理システムを含むさまざまな種類のものとすることができる。他のいくつかの実施形態では、システム300を、システム300の1つ以上の構成要素がクラウド内の1つ以上のネットワークに分散している分散システムとして構成してもよい。
【0140】
図3に示される構成要素のうちの1つ以上を、ソフトウェア、ハードウェア、またはその組合わせにおいて実装してもよい。いくつかの実施形態において、ソフトウェアは、メモリ(たとえば非一時的なコンピュータ読取可能な媒体)、メモリデバイス、またはその他の物理メモリに格納されてもよく、1つ以上の処理ユニット(たとえば1つ以上のプロセッサ、1つ以上のプロセッサコア、1つ以上のGPU等)によって実行されてもよい。
【0141】
図4は簡略ブロック
図400を示し、これを用いてアーカイブされたリレーションの管理の特徴を説明することができる。
図4に示されるように、アーカイブされたリレーションは、クエリグラフ402として表わすことができる。いくつかの例において、クエリグラフ402は、クエリの演算子を表わすノードおよびクエリグラフ402の演算子間の経路を表わす頂点を含み得る。限定されない1つの例において、
図4のクエリグラフ402は、射影演算子404と、グループ化演算子406と、リレーショナルソース演算子408とを含む。さらに、いくつかの例において、射影演算子404およびリレーショナルソース408はステートレスでもよく、グループ化演算子406はステートフルでもよい。場合によっては、ステートレス演算子は、状態を、追跡、管理、または要求しないが、ステートフル演算子は、状態を、追跡、管理、または要求する。上記のように、いくつかの例において、クエリグラフ402を、上から下へというやり方で分析または評価し410、ステートフル演算子(いくつかの例では第1のまたは最下位のステートフル演算子)における履歴データをインポートしてもよい。クエリグラフ402を分析する410間に、クエリグラフ402における第1のステートフル演算子を決定するように、サービスおよび/またはエンジン(たとえば
図1〜
図3を参照しながら説明したCQサービス202および/またはCQLエンジン156)を構成してもよい。
図4の例において、第1のステートフル演算子はグループ化406である。このため、412で、サービスが射影演算子404(この例ではステートレス)に達したとき、テーブルデータ(すなわち履歴データ)はインポートしなくてよい。しかしながら、414で、グループ化演算子406に達したとき、履歴、ウェアハウス、および/またはテーブルデータをインポートして、アーカイブされたリレーションを初期化すればよい。
【0142】
これに代えてまたはこれに加えて、いくつかの例において、クエリグラフ402(プランとも呼ばれる)を、ソース(ここではリレーショナルソース演算子408)から初めてトポロジーの順にトラバースしてもよい。このため、この例において、トラバースは下から上へというやり方でもよい。このトラバースにおいて、第1のステートフル演算子に達したとき、これをクエリ演算子としてマークしてもよく、よって、グラフ402をこの分岐においてさらにトラバースする必要はない。なお、aggregate distinctのようないくつかのCQLクエリの場合、クエリプランは2つ以上の分岐を有し得る。この例において、リレーショナルソース408はステートレスでもよく、そうすると、トラバースは上方向でありグループ化406を見ることになるであろう。グループ化406はステートフルなので、これは、クエリ演算子としてマークしてもよい。よって、トラバースは完了することができ、射影演算子404まで上る必要はないであろう。なぜなら、グループ化406はアーカイバにクエリし、その状態を埋め、また、スナップショット出力を射影404に伝搬しさらに下流の演算子があればそこに伝搬する。
【0143】
図5は、(上記)TRANSACTION_CIDおよび/またはTRANSACTION_TID等であるがこれらに限定されない1つ以上のテーブルIDを利用して、アーカイブされたリレーションに関連する変更イベントをカウントするための、限定されない少なくとも1つの例500を示す。
図5に示されるように、最初のトランザクションコンテキストテーブル502および挿入後のトランザクションコンテキストテーブル504が示されている。いくつかの例において、トランザクションIDを管理するように構成されたサーバを、初期化するかそうでなければ起動すればよい。永続性サービスは、このサーバによって起動されると、1組のトランザクションインスタンスを作成し得る。このため、トランザクションコンテキストテーブル502は、自身が使用するために10のコンテキストインスタンスを作成した1つの永続性サービスの起動後の内容を示す。TRANSACTION_CID列はコンテキストIDを含み、TRANSACTION_TID列はこのコンテキストIDによってコミットされる最大トランザクションIDを含む。
【0144】
限定されない1つの例において、この時点で、これも自身が使用するために10のコンテキストインスタンスを作成した第2の永続性サービスが起動した場合、テーブル02は、11〜20というTRANSACTION_CIDの値を有する10の新たなエントリを示し得る。この時点で、永続性サービスは実行しているので、データオブジェクト列データタイプ各々を1つずつ含む「アルファ」という名称のデータオブジェクトが作成されるであろう。いくつかの例において、データオブジェクトが作成される度に、永続性サービスはこのデータオブジェクトに対する永続性記憶装置を表わす、対応するデータベースビューを作成してもよい。ある例において、データオブジェクトが生成されると、挿入コマンドがこれに対して実行されてもよい。コンテキストおよびトランザクションIDの処理を最も適切に示すために、合計24の挿入に対して12のスレッドを用いる1スレッド当たり2つの挿入動作が行なわれてもよい。各スレッドは、JTAトランザクションを開始し、1つの挿入動作を実行し、第2の挿入動作を実行し、次にトランザクションをコミットしてもよい。複数のスレッドを用いる理由は、そうすれば、並列に実行する複数のJTAトランザクションを作成し得るからであり、このことは、如何にしてコンテキストIDが機能するようになるかをより適切に示すであろう。これはまた、複数の(この例では1スレッド当たり2つ)データオブジェクト動作方法コールが同じJTAトランザクションにおいてなされかつこのJTAトランザクションが永続性の外で開始されコミットされたというシナリオを実証する。
【0145】
この例の場合、12のスレッドがコードを同時に実行しているであろう。各スレッドは、サーバの外側でトランザクションを開始し、2つの挿入コールを永続性に対して行ない、その後このトランザクションをコミットし得る。永続性は10のコンテキストIDを割当てているので、これらスレッドのうち、10個はコンテキストを取得するが、2個は最初にブロックされるであろう。2つのJTAトランザクションを、別のJTAトランザクションが完了しコンテキストを解放するまでブロックしてもよい。ブロックされたJTAトランザクションは次に、解放されたコンテキストを捕捉し永続性APIコールを処理すればよい。いくつかの例において、挿入動作の完了後、テーブル504(挿入後)の検査はまさにこの結果を示す。トランザクションコンテキスト1および2は、トランザクションID2を「最後にコミットされた」トランザクションIDとして示し、他のすべてのトランザクションコンテキストはトランザクションID1をこれらの最後にコミットされたトランザクションとして示す。
【0146】
いくつかの例において、データオブジェクト変更通知は、この例において実行された挿入動作の結果としてJMSを介してブロードキャストしてもよい。1つのJTAトランザクション当たり2つの挿入が実行され、合計24の挿入動作に対して12のトランザクションが実行されたことを想起されたい。トランザクションコンテキスト1および2は、2つのトランザクション各々に対して使用されたので、2つの挿入についてのトランザクションID1およびその他2つの挿入についてのトランザクションID2を有するコンテキスト1および2からの4つの変更通知を見ることになるはずである。他のすべてのコンテキストは、トランザクション1つのみに対して使用されたので、いずれもトランザクションID1を有する2つの挿入を生成しているはずである。
【0147】
図6〜
図8は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス600、700、および800をそれぞれ示すフロー図の例を示す。これらプロセス600、700、800は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、1つ以上のプロセッサによって実行されるときに、記載されている動作を実行する1つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび/または並列に組合わせてプロセスを実装することができる。
【0148】
加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された1つ以上のコンピュータシステムの制御下で実行してもよく、1つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード(たとえば実行可能な命令、1つ以上のコンピュータプログラム、または1つ以上のアプリケーション)として実装してもよい。上記のように、コードは、たとえば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。
【0149】
いくつかの例において、少なくとも
図1(およびその他の図面)に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図6のプロセス600を実行し得る。プロセス600は、602で、アーカイブされたストリームまたはアーカイブされたリレーションをデータソースとして識別するクエリを識別するおよび/または受けることを含むことから始まり得る。いくつかの例において、プロセス600は、604で、履歴データを用いてクエリを初期化することを含み得る。プロセス600は、606で、アーカイブされたストリームまたはアーカイブされたリレーションおよび履歴データに少なくとも一部基づいてクエリを評価することを含み得る。プロセス600はまた、608で、クエリの演算子を表わすクエリグラフを形成することを含み得る。プロセス600は、610で、クエリグラフをグラフの上から下にトラバースすることを含み得る。さらに、いくつかの例において、プロセス600は、612で、クエリグラフにおいて識別された第1のステートフル演算子における履歴データを用いてクエリを初期化することを含むことで、終了し得る。
【0150】
図7は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス700を示すフロー図の例を示す。少なくとも
図1に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図7のプロセス700を実行し得る。プロセス700は、702で、連続クエリを受けて、データストリームまたは履歴データのIDを含むデータストリームまたはアーカイブされたリレーションを処理することを含むことから始まり得る。プロセス700は、704で、受けた連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。加えて、いくつかの例において、プロセス700は、履歴データの一部を用いて連続クエリを初期化することを含み得る。さらに、プロセス700は、708で、データストリームまたはアーカイブされたリレーションに関して履歴データに少なくとも一部基づいて連続クエリを評価することを含むことで、終了し得る。
【0151】
図8は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス800を示すフロー図の例を示す。少なくとも
図1に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図8のプロセス800を実行し得る。プロセス800は、802で、連続クエリを受けて、ビジネスイベントデータに関連するストリームまたはアーカイブされたリレーションを処理することを含むことから始まり得る。プロセス800は、804で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。プロセス800は、806で、クエリグラフを、ソースからトポロジーに従ってトラバースして、最下位のステートフル演算子(たとえば最下位のステートフル演算子はトラバース中に識別される最後のステートフル演算子であってもよく、および/または、これは分岐の演算子であってもよい)。いくつかの例において、プロセス800は、808で、クエリの演算子に少なくとも一部基づいて初期化のための履歴データの最適量を決定することを含み得る。プロセス800は、810で、識別された最下位のステートフル演算子における履歴データを用いて連続クエリを初期化することを含み得る。さらに、いくつかの例において、プロセス800は、812で、データストリームまたはアーカイブされたリレーションに関して履歴データに少なくとも一部基づいて連続クエリを評価することを含むことで、終了し得る。
【0152】
図9〜
図11は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス900、1000、および1100をそれぞれ示すフロー図の例を示す。これらプロセス900、1000、1100は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、1つ以上のプロセッサによって実行されるときに、記載されている動作を実行する1つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび/または並列に組合わせてプロセスを実装することができる。
【0153】
加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された1つ以上のコンピュータシステムの制御下で実行してもよく、1つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード(たとえば実行可能な命令、1つ以上のコンピュータプログラム、または1つ以上のアプリケーション)として実装してもよい。上記のように、コードは、たとえば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。
【0154】
いくつかの例において、少なくとも
図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図9のプロセス900を実行し得る。プロセス900は、902で、データストリームまたはアーカイブされたリレーションを識別するクエリを識別するかそうでなければ受けることを含むことから始まり得る。プロセス900は、904で、ユーザにより構成されたウィンドウサイズを識別することを含み得る。プロセス900は、906で、履歴データを用いウィンドウサイズに少なくとも一部基づいてクエリを初期化することを含み得る。さらに、プロセス900は、908で、履歴データおよびアーカイブされたストリームまたはアーカイブされたリレーションに少なくとも一部基づいてクエリを評価することを含むことで、終了し得る。
【0155】
図10は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス1000を示すフロー図の例を示す。少なくとも
図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図10のプロセス1000を実行し得る。プロセス1000は、1002で、データストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリを受けることを含むことから始まり得る。プロセス1000は、1004で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。プロセス1000は、1006で、データストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリからウィンドウサイズを計算することを含み得る。いくつかの例において、プロセス1000は、1008で、ウィンドウサイズに少なくとも一部基づいて初期化のための履歴データの量を決定することを含み得る。プロセス1000は、1010で、決定した履歴データを用いて連続クエリを初期化することを含み得る。さらに、プロセス1000は、1012で、アーカイブされたストリームまたはアーカイブされたリレーション、およびウィンドウサイズに関して連続クエリを評価することを含み得る。
【0156】
図11は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス1100を示すフロー図の例を示す。少なくとも
図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図11のプロセス1100を実行し得る。プロセス1100は、1102で、アーカイブされたストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリを受けることを含むことから始まり得る。1104で、連続クエリからウィンドウサイズを計算して、処理するストリームまたはアーカイブされたリレーションの有界範囲を識別することを含み得る。プロセス1100は、1106で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。加えて、いくつかの局面において、プロセス1100は、ステートフル演算子を識別するためにクエリグラフを下向きに(たとえば上から下へという手法)トラバースすることを含み得る。プロセス1100は、1110で、初期化のための履歴データの最適量を決定することを含み得る。プロセス1100は、1112で、識別されたステートフル演算子における履歴データを用いて連続クエリを初期化することを含み得る。さらに、いくつかの例において、プロセス1100は、ストリームまたはアーカイブされたリレーションに関してウィンドウサイズに少なくとも一部基づいて連続クエリを評価することを含み得る。
【0157】
図12〜
図14は、本明細書に記載のアーカイブされたリレーションに関連するイベントカウントという特徴を実装するためのプロセス1200、1300、および1400をそれぞれ示すフロー図の例を示す。これらプロセス1200、1300、1400は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、1つ以上のプロセッサによって実行されるときに、記載されている動作を実行する1つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび/または並列に組合わせてプロセスを実装することができる。
【0158】
加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された1つ以上のコンピュータシステムの制御下で実行してもよく、1つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード(たとえば実行可能な命令、1つ以上のコンピュータプログラム、または1つ以上のアプリケーション)として実装してもよい。上記のように、コードは、たとえば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。
【0159】
いくつかの例において、少なくとも
図1に示される(たとえば少なくともイベントカウントモジュール152を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図12のプロセス1200を実行し得る。プロセス1200は、1202で、データオブジェクトを識別するクエリを識別することを含むことから始まり得る。プロセス1200は、1204で、データオブジェクトに関連する履歴データに対してクエリを評価することを含み得る。プロセス1200は、1206で、データオブジェクトにリスニングサービスを登録することを含み得る。プロセス1200はまた、1208で、リスニングサービスによって識別された変更のトランザクションIDを受けることを含み得る。いくつかの例において、プロセス1200は、1210で、トランザクションIDを履歴データの最大トランザクションIDと比較することを含み得る。プロセス1200は、1212で、受けたトランザクションIDが最大トランザクションIDよりも大きい場合のみ変更を処理することを含み得る。プロセス1200は、1214で、データオブジェクトおよび履歴データに少なくとも一部基づいてクエリを評価することを含むことで、終了し得る。
【0160】
図13は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス1300を示すフロー図の例を示す。少なくとも
図1に示される(たとえば少なくともイベントカウントモジュール152を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図13のプロセス1300を実行し得る。プロセス1300は、1302で、データオブジェクトを識別するかそうでなければ受ける連続クエリを受けることを含むことから始まり得る。プロセス1300は、1304で、データオブジェクトに関連するリスニングサービスを登録することを含み得る。加えて、いくつかの例において、プロセス1300は、1306で、リスニングサービスの登録後に連続クエリを履歴データに対して評価することを含み得る。プロセス1300は、1308で、履歴データに対する評価後にリスニングサービスによって識別された変更を処理することを含み得る。プロセス1300は、1310で、データオブジェクトに対して連続クエリを評価することを含むことで、終了し得る。
【0161】
図14は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス1400を示すフロー図の例を示す。少なくとも
図1に示される(たとえば少なくともイベントカウントモジュール152を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図14のプロセス1400を実行し得る。プロセス1400は、1402で、データオブジェクトを処理するように構成された連続クエリを受けることを含むことから始まり得る。プロセス1400は、1404で、データオブジェクトにリスニングサービスを登録することを含み得る。プロセス1400は、1406で、データオブジェクトに関連する履歴データに対して連続クエリを評価することを含み得る。いくつかの例において、プロセス1400はまた、1408で、リスニングサービスによって識別された変更のトランザクションIDを受けることを含み得る。加えて、プロセス1400は、1410で、受けたトランザクションIDを現在履歴データに関連する最大トランザクションIDと比較することを含み得る。プロセス1400は、1412で、受けたIDが履歴データに関連する最大IDよりも大きい場合に変更を処理することを含み得る。プロセス1400は、1414で、データオブジェクトに関して連続クエリを評価することを含むことで、終了し得る。
【0162】
連続クエリおよびスケジュールされたクエリの混成の実行を実装するための、例示としての方法およびシステムについては上記の通りである。これらシステムおよび方法のうちのいくつかまたはすべては、少なくとも上記
図1〜
図14に示されるもののようなアーキテクチャおよびプロセスによって少なくとも部分的に実装し得るが、そうすることが必要な訳ではない。
【0163】
図15は、本開示の実施形態に従い使用し得るシステム環境1500の構成要素を示す簡略ブロック図である。図に示されるように、システム環境1500は、1つ以上のクライアントコンピューティング装置1502、1504、1506、1508を含み、これら装置は、ウェブブラウザまたは専用のクライアント(たとえばOracle Forms)等のクライアントアプリケーションを、(
図1および
図3のネットワーク108と同様のネットワーク等であるがこれに限定されない)1つ以上のネットワーク1510を通して操作するように構成されている。さまざまな実施形態において、クライアントコンピューティング装置1502、1504、1506、および1508は、ネットワーク1510を通してサーバ1512と情報をやり取りし得る。
【0164】
クライアントコンピューティング装置1502、1504、1506、1508は、汎用のパーソナルコンピュータ(例として、さまざまなバージョンのMicrosoft Windows(登録商標)および/またはApple Macintoshオペレーティングシステムを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む)、携帯電話もしくはPDA(Microsoft Windows Mobile等のソフトウェアを実行し、インターネット、電子メール、SMS、ブラックベリー(Blackberry)、またはその他の通信プロトコルを使用可能)、および/またはさまざまな市販のUNIX(登録商標)もしくはUNIXのようなオペレーティングシステム(さまざまなGNU/Linux(登録商標)オペレーティングシステムを含むがこれに限定されない)のいずれかを実行するワークステーションコンピュータであってもよい。これに代えて、クライアントコンピューティング装置1502、1504、1506、および1508は、ネットワーク(たとえば以下で説明するネットワーク1510)を通して通信可能なシンクライアントコンピュータ、インターネットを使用可能なゲーム機、および/またはパーソナルメッセージングデバイス等のその他の電子デバイスであってもよい。典型的なシステム環境1500が4つのクライアントコンピューティング装置とともに示されているが、クライアントコンピューティング装置の数はいくつであってもそれらをサポートし得る。センサ等を有する装置等の他の装置がサーバ1512と情報をやり取りしてもよい。
【0165】
システム環境1500はネットワーク1510を含み得る。ネットワーク1510は、TCP/IP、SNA、IPX、AppleTalk等を含むがこれらに限定されないさまざまな市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者によく知られているネットワークであれば、どのような種類のネットワークであってもよい。単なる例として、ネットワーク1510は、イーサネット(登録商標)ネットワーク、トークンリングネットワーク等のローカルエリアネットワーク(LAN)、ワイドエリアネットワーク、バーチャルプライベートネットワーク(VPN)を含むがこれに限定されないバーチャルネットワーク、インターネット、イントラネット、エクストラネット、公衆電話交換回線網(PSTN)、赤外線ネットワーク、ワイヤレスネットワーク(たとえば、IEEE 802.11プロトコル群のいずれかの下で動作するネットワーク、当該技術分野において公知のブルートゥース(登録商標)プロトコル、および/またはその他のワイヤレスプロトコル)、および/または、これらおよび/または他のネットワークの任意の組合わせであってもよい。
【0166】
システム環境1500はまた、1つ以上のサーバコンピュータ1512を含み、このサーバコンピュータは、汎用コンピュータ、専用サーバコンピュータ(例として、PCサーバ、UNIXサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式(rack-mounted)のサーバ等を含む)、サーバファーム、サーバクラスタ、またはその他の適切な配置および/または組合わせであってもよい。さまざまな実施形態において、サーバ1512は、本願のこれまでの開示において説明された1つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。たとえば、サーバ1512は、本開示の一実施形態に従う上記処理を実行するためのサーバに相当するものであってもよい。
【0167】
サーバ1512は、上述したオペレーティングシステムのうちのいずれかおよび任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行してもよい。また、サーバ1512は、HTTPサーバ、FTPサーバ、CGIサーバ、Javaサーバ、データベースサーバ等を含むさまざまなその他のサーバアプリケーションおよび/またはミッドティア(mid-tier)アプリケーションのうちのいずれかを実行してもよい。典型的なデータベースサーバは、Oracle、Microsoft、Sybase、IBM等から市販されているものを含むが、これらに限定されない。
【0168】
また、システム環境1500は1つ以上のデータベース1514、1516を含み得る。データベース1514、1516は、さまざまな場所に存在し得る。例として、データベース1514、1516のうちの1つ以上は、サーバ1512に対してローカルな(および/またはサーバ1512内に常駐している)非一時的な記録媒体に存在していてもよい。これに代えて、データベース1514、1516は、サーバ1512から離れていてネットワークベースまたは専用回線を介してサーバ1512と通信してもよい。一連の実施形態では、データベース1514、1516は、当業者によく知られているストレージエリアネットワーク(SAN)に存在していてもよい。同様に、サーバ1512による機能を実行するために必要なファイルは、必要に応じて、サーバ1512に対してローカルにおよび/または遠隔で格納されてもよい。一組の実施形態において、データベース1514、1516は、SQLフォーマットのコマンドに応答してデータを格納し、更新し、取出すようにされている、Oracleから提供されているデータベース等のリレーショナルデータベースを含み得る。
【0169】
図16は、本開示の実施形態に従い使用し得るコンピュータシステム1600の簡略ブロック図である。たとえば、サービスプロバイダコンピュータ106を、システム1600のようなシステムを用いて実装してもよい。バス1601を介して電気的におよび/または通信可能に結合し得るハードウェア構成要素を含むコンピュータシステム1600が示されている。このハードウェア構成要素は、1つ以上の中央処理装置(CPU)1602と、1つ以上の入力装置1604(たとえばマウス、キーボード等)と、1つ以上の出力装置1606(たとえばディスプレイ装置、プリンタ等)とを含み得る。また、コンピュータシステム1600は、1つ以上の記憶装置1608を含み得る。例として、記憶装置1608は、ディスクドライブ、光学式記憶装置等の装置、ならびに、プログラム可能で、一瞬で更新可能で(flash-updateable)、および/またはそれと同じようなことが可能であるランダムアクセスメモリ(RAM)および/または読出専用メモリ(ROM)等のソリッドステート記憶装置を含み得る。
【0170】
コンピュータシステム1600は、さらに、コンピュータ読取可能記録媒体リーダ1612と、通信サブシステム1614(たとえばモデム、ネットワークカード(無線または有線)、赤外線通信装置等)と、ワーキングメモリ1618とを含み得る。ワーキングメモリ1618は、上記RAMおよびROM装置を含み得る。いくつかの実施形態において、コンピュータシステム1600は、デジタル信号プロセッサ(DSP)、専用プロセッサ、および/またはそれと同様のものを含み得る処理加速部1616を含んでいてもよい。
【0171】
コンピュータ読取可能記録媒体リーダ1612は、さらに、コンピュータ読取可能な記録媒体1610に接続し得る。コンピュータ読取可能記録媒体1610は、(任意に、記憶装置1608と組合わせて)リモート式、ローカル式、固定式および/または着脱交換式の記憶装置、および、一時的および/またはより永続的にコンピュータ読取可能な情報を収容するための記録媒体を総合的に意味している。通信システム1614によって、ネットワーク1612および/またはシステム環境1600に関連する上述のその他のコンピュータと、データをやり取りすることが可能であってもよい。
【0172】
また、コンピュータシステム1600は、ワーキングメモリ1618内に現在位置しているものとして示されているソフトウェア構成要素を含み得る。このソフトウェア構成要素は、オペレーティングシステム1620、および/または、アプリケーションプログラム(クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、RDBMS等であってもよい)等のその他のコード1622を含む。典型的な実施形態において、ワーキングメモリ1618は、実行可能なコードと、上述のように証明書利用者およびオープン認可関連の処理に使用される関連のデータ構造とを含んでいてもよい。コンピュータシステム1600の代替の実施形態には、上述のものの多くの変形例があり得ることが理解されるはずである。たとえば、カスタマイズされたハードウェアが用いられてもよく、および/または特定の構成要素がハードウェア、ソフトウェア(アプレット等のポータブルソフトウェアを含む)またはそれら両方において実装されてもよい。さらに、ネットワーク入出力装置等の他のコンピューティング装置への接続を用いてもよい。
【0173】
図17は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス1700を示すフロー図の別の例を示す。少なくとも
図1に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図17のプロセス1700を実行し得る。プロセス1700は、1702で、アーカイブされたリレーションに少なくとも一部基づいてクエリを識別することを含むことから始まり得る。プロセス1700は、1704で、クエリの演算子を利用してクエリ演算子グラフを生成することを含み得る。加えて、いくつかの例において、プロセス1700は、1706で、演算子グラフを(たとえばトポロジーに従って)ソートすることを含み得る。プロセス1700は、1708で、グラフを分析しアーカイバにクエリし得る演算子を決定して状態(たとえばステートフル演算子)を初期化することを含み得る。プロセス1700は、1710で、アーカイバに与える適切なクエリ(たとえばアーカイバクエリ)を構成することを含み得る。いくつかの例において、プロセス1700は、1712で、オペレータシェアリングについて判断することを含み得る。プロセス1700は、1714で、(たとえば上記のように)アーカイバクエリをCQサービスに対して発行することにより、決定された演算子の状態を初期化することを含み得る。プロセス1700は、1716で、履歴結果を(たとえばCQサービスまたは永続性から)受けてもよい。さらに、プロセス1700は、1718で、まだカウントされていない場合到来したイベントを履歴結果にクエリすることの一部として処理することを含むことで、終了し得る。
【0174】
図18は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス1800を示すフロー図の別の例を示す。少なくとも
図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図18のプロセス1800を実行し得る。プロセス1800は、1802で、アーカイバソースに対するアーカイバクエリを評価し1つ以上のスナップショット出力を取得することを含むことから始まり得る。プロセス1800は、1804で、リレーションに対するウィンドウを、構成可能な2つのパラメータのうちの少なくとも1つを利用して、指定することを含み得る。構成可能なパラメータは、ウィンドウサイズおよび/またはリレーション属性を含む。加えて、いくつかの例において、プロセス1800は、1806で、各スナップショットタプルについて、指定された属性の値を現在のイベント時間と比較することにより、タプルがウィンドウの中にあるか否かテストすることを含み得る。プロセス1800は、1808で、スナップショットタプルがテストにパスしたか否か判断することを含み得る。いくつかの例において、テストにパスした場合、プロセス1800は、1810で、タプルをウィンドウに挿入することを含み得る。しかしながら、いくつかの例において、テストにパスしなかった場合、プロセス1800は、1812で、その代わりにタプルを無視することを含み得る。プロセス1800は次に1802に戻り終了するかまたは、次のアーカイバクエリを評価することを含み得る。
【0175】
図19は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス1900を示すフロー図の別の例を示す。少なくとも
図1に示される(たとえば少なくともイベントカウントモジュール152を利用する)1つ以上のサービスプロバイダコンピュータ106は、
図19のプロセス1900を実行し得る。プロセス1900は、1902で、状態演算子についてデータオブジェクトにクエリすることを含むことから始まり得る。プロセス1900は、1904で、トランザクションコンテキストテーブルからスナップショット情報を得ることを含み得る。プロセス1900は、1906で、スナップショット情報をCQLエンジンにおいて維持し関連するスナップショットIDを増加させることを含み得る。プロセス1900は、1908で、スナップショットIDをクエリプランの「コネクタ」演算子に設定することを含み得る。「コネクタ」演算子は、ローカルプランをグローバルプランに結合し得る。プロセス1900は、1910で、到着するイベントのスナップショットIDを、イベントにおけるコンテキストID(CID)およびトランザクションID(TID)を用いて計算することを含み得る。プロセス1900は、1912で、イベントのスナップショットIDを入力キューのスナップショットIDと比較することを含み得る。プロセス1900は、1914で、イベントのIDが入力キューのIDよりも大きいか否か判断することを含み得る。いくつかの例において、1914でイベントIDがキューIDよりも大きい場合、プロセス1900は、イベントを処理することを含み得る。しかしながら、いくつかの例において、1914でイベントIDがキューIDよりも大きくない場合、プロセスは1918でその代わりにイベントを無視することを含み得る。プロセス1900は次に1902に戻って終了するかまたは再び開始する。
【0176】
これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、CQLエンジンにおいて維持されてもよく、スナップショットID(増大する識別子)はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル(全体)クエリプランに結合し得る場所を表わしてもよい。イベントがCQLエンジンに達すると、このイベントに対し、スナップショットIDを、その中のコンテキストIDおよびトランザクションIDの値を用いて計算してもよい。スナップショットIDは、CQLエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットIDは次に、入力キューのスナップショットIDと比較してもよい。イベントのID>キューのIDであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを避けるために無視してもよい。コードまたはコードの一部を収容するための記録媒体およびコンピュータ読取可能な媒体は、当該技術において公知のまたは使用されているあらゆる適切な媒体を含み得る。上記適切な媒体は記録媒体および通信媒体を含み、これら記録媒体および通信媒体は、RAM、ROM、EEPROM、フラッシュメモリもしくはその他のメモリ技術、CD−ROM、デジタル汎用ディスク(DVD)もしくはその他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、データ信号、データ伝送、または、所望の情報を格納もしくは伝送するために使用することができコンピュータによってアクセス可能なその他の媒体を含む、コンピュータ読取可能な命令、データ構造、プログラムモジュール、またはその他のデータ等の情報の、格納および/または伝送のための何等かの方法または技術において実装される、揮発性および不揮発性(非一時的)の着脱可能および着脱不能な媒体等であるが、これらに限定されない。
【0177】
本開示の特定の実施形態について説明してきたが、さまざまな修正、変更、代替構成、および均等物も、本開示の範囲に包含される。上記さまざまな修正、変更、代替構成、および均等物は、開示されている特徴の妥当な組合わせを含む。本開示の実施形態は、ある特定のデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で機能することが可能である。加えて、本開示の実施形態について、特定の一連のトランザクションおよびステップを用いて説明してきたが、本開示の範囲が、記載されている一連のトランザクションおよびステップに限定されないことは、当業者には明らかなはずである。
【0178】
さらに、本開示の実施形態について、ハードウェアとソフトウェアの特定の組合わせを用いて説明してきたが、ハードウェアとソフトウェアの他の組合わせも本開示の範囲内であることが認識されるはずである。本開示の実施形態は、ハードウェアのみで実装されてもよく、ソフトウェアのみで実装されてもよく、これらの組合わせを用いて実装されてもよい。
【0179】
したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考慮されねばならない。しかしながら、これに対し、追加、控除、削除、およびその他の修正および変更を、より広い精神および範囲から逸脱することなく行ない得ることは明らかであろう。本開示の特徴を示すための例示的な方法およびシステムは上述の通りである。これらのシステムおよび方法のうちのいくつかまたはすべては、上記
図1〜
図12に示されるもののようなアーキテクチャによって、少なくとも部分的に実装し得るが、そうすることが必要な訳ではない。
【0180】
実施形態について、構造的特徴および/または方法論的行為に特有の表現で説明してきたが、本開示は記載されている具体的な特徴または行為に必ずしも限定されないことが理解されるはずである。むしろ、この具体的な特徴および行為は、実施形態を実装する例示的な形態として開示されている。条件表現、特に「できる」または「してもよい」(「can」、「could」、「might」、または「may」)等は、特に明記されない限りまたは使用されている文脈の中で他の解釈がなされない限り、何らかの特徴、要素、および/またはステップを、ある実施形態は含み得るがそれ以外の実施形態は含まないことを示唆することを、概ね意図している。よって、このような条件表現は、特徴、要素、および/またはステップが、1つ以上の実施形態に多少なりとも必要であることを、または、これら特徴、要素、および/またはステップがいずれか特定の実施形態に含まれるのかまたはいずれか特定の実施形態において実施されるのかをユーザの入力または刺激の有無に関わらず判断するための論理を1つ以上の実施形態が必然的に含むことを、示唆することは、概ね意図していない。