詳細な説明
以下の説明において、様々な実施形態を説明する。説明の便宜上、実施形態の十分な理解のために具体的な構成および詳細を説明する。しかしながら、実施形態が具体的な詳細なしに実施され得ることは、当業者に明らかになるだろう。さらに、記載の実施形態を曖昧にしてしまわないように、周知の特徴は省略または簡略化される場合がある。
複合イベント処理(CEP:Complex Event Processin)の概要
複合イベント処理(CEP)は、イベント駆動型アーキテクチャに基づいてアプリケーションを構築するためのモジュラープラットフォームを提供する。CEPプラットフォームの中心にあるのは、連続問い合わせ(クエリ)言語(CQL:Continuous Query Language)である。CQLによって、アプリケーションは、SQLのような宣言型言語を用いてデータのストリームに対してフィルタ処理、問い合わせ、およびパターンマッチング動作を実行できるようになる。開発者は、軽量Java(登録商標)プログラミングモデルと合わせてCQLを使用してアプリケーションを書いてもよい。他のプラットフォームモジュールとして、一例を挙げると、機能が豊富なIDE、管理コンソール、クラスタリング、分散キャッシング、イベントリポジトリ、モニタリングなどがある。
イベント駆動型アーキテクチャおよび複合イベント処理がエンタープライズコンピューティング分野の目立った特徴になるにつれて、より多くの企業がCEP技術を用いてミッションクリティカルなアプリケーションを構築し始めた。今日、ミッションクリティカルなCEPアプリケーションは、多くの異なる産業で見つけることができる。たとえば、CEP技術は、電力事業において、電気需要の変化に対して瞬時に公共事業を対応させることにより公共事業をより効率的なものにするために利用されている。CEP技術は、クレジットカード業界において、詐欺の可能性があるトランザクションが発生したときにリアルタイムで検出するために利用されている。ミッションクリティカルなCEPアプリケーションの数は、増え続けている。ミッションクリティカルなアプリケーションを構築するためにCEP技術が利用されることにより、CEPアプリケーションが高い可用性を有し、かつ、フォールトトレラントである必要があるようになった。
今日の情報技術(IT:Information Technology)環境は、金融市場およびネットワーク性能の監視から、ビジネスプロセスの実行およびRFIDがタグ付けされたアセットの追跡まで、あらゆることについてのデータの連続ストリームを生成する。CEPは、イベント処理アプリケーションを開発するための豊富な宣言型環境を提供して、業務運営の有効性を改善する。CEPは、複数のイベントストリームを処理して、パターンおよび傾向をリアルタイムで検出し、かつ、新たに出現した商機に出資するまたはリスクが大きくなるのを軽減するために必要な可視性を企業に提供できる。
データの連続ストリーム(イベントストリームとも称する)は、本質的にはっきりとした終端がない、連続または無限のデータストリームまたはイベントストリームを含んでもよい。論理的には、イベントストリームまたはデータストリームは、データ要素(イベントとも称する)のシーケンスであってもよく、各データ要素は、関連するタイムスタンプを有する。連続イベントストリームは、要素(s,T)のバッグまたはセットとして論理的に表されてもよく、「s」は、データ部分を表し、「T」は、時間ドメインに含まれる。この「s」部分は、一般に、タプルまたはイベントと呼ばれる。よって、イベントストリームは、タイムスタンプが記録されたタプルまたはイベントのシーケンスであってもよい。
いくつかの態様では、ストリームに含まれるイベントに関連付けられたタイムスタンプは、クロックタイムと一致してもよい。しかしながら、他の例では、イベントストリームに含まれるイベントに関連付けられた時間は、アプリケーションドメインによって定義されてもよく、クロックタイムに対応しなくてもよいが、代わりに、たとえばシーケンス番号によって表されてもよい。したがって、イベントストリームに含まれるイベントに関連付けられた時間情報は、番号、タイムスタンプ、または時間の観念を表すその他の情報によって表されてもよい。入力イベントストリームを受信するシステムについては、このイベントは、タイムスタンプの昇順に当該システムに到着する。同じタイムスタンプを有するイベントが2つ以上あるかもしれない。
いくつかの例では、イベントストリームに含まれるイベントは、なんらかの世俗的イベントの発生(たとえば、温度センサの値が新しい値に変わったとき、銘柄記号の価格が変更したとき)を表してもよく、当該イベントに関連付けられた時間情報は、データストリームイベントによって表される世俗的イベントがいつ発生したかを示してもよい。
イベントストリームを介して受信されたイベントについては、イベントに関連付けられた時間情報を用いて、イベントストリームに含まれる当該イベントが必ずタイムスタンプ値の昇順に到着するようにしてもよい。これによって、イベントストリームで受信されたイベントがそれらの関連する時間情報に基づいて順序付けされることを可能にしてもよい。この順序付けを可能にするために、後に生成されるイベントが、前に生成されたイベントよりも後のタイムスタンプを有するよう、イベントストリームに含まれるイベントにタイムスタンプが非降順で関連付けられてもよい。別の例として、時間情報としてシーケンス番号が利用されている場合、後に生成されるイベントに関連付けられるシーケンス番号は、それよりも前に生成されたイベントに関連付けられるシーケンス番号よりも大きくてもよい。いくつかの例では、たとえば、データストリームイベントが表す世俗的イベントが同じ時間に発生した場合、複数のイベントが同じタイムスタンプまたはシーケンス番号に関連付けられてもよい。同じイベントストリームに属するイベントは、一般に、関連する時間情報がイベントに設定した順序で処理されてもよく、前のイベントが後のイベントよりも前に処理される。
イベントストリームに含まれるイベントに関連付けられた時間情報(たとえば、タイムスタンプ)は、ストリームの送信元によって設定されてもよく、または、これに代えて、システムが当該ストリームを受信することによって設定されてもよい。たとえば、特定の実施形態では、ハートビートは、イベントストリームを受信するシステム上で維持されてもよく、イベントに関連付けられた時間は、ハートビートが計測するイベントのシステムへの到着時間に基づいてもよい。イベントストリームに含まれる2つのイベントが同じ時間情報を有している可能性がある。なお、タイムスタンプ順序要件は1つのイベントストリームに特有であるが、異なるストリームのイベントが任意にインターリーブされるかもしれない。
イベントストリームは、関連するスキーマ「S」を有し、このスキーマは、時間情報および1つ以上の名前付き属性のセットを含む。特定のイベントストリームに属するすべてのイベントは、その特定のイベントストリームに関連付けられたスキーマに準拠している。したがって、イベントストリーム(s,T)について、このイベントストリームは、(<time_stamp>、<attribute(s)>)というスキーマ「S」を有してもよい。<attributes>は、スキーマのデータ部分を表し、1つ以上の属性を含み得る。たとえば、チッカーイベントストリームのスキーマは、属性<stock symbol>(銘柄記号)と<stock price>(株価)とを含んでもよい。このようなストリームを介して受信された各イベントは、1つのタイムスタンプと2つの属性とを有することになる。たとえば、チッカーイベントストリームは、以下のイベントおよび関連するタイムスタンプを受信してもよい。
…
(<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>)について、イベントは、<ORCL,62>であり、属性「stock_symbol」および「stock_value」を有する。ストリーム要素に関連付けられたタイムスタンプは、「timestamp_N+1」である。よって、連続イベントストリームは、イベントのフローであり、各イベントは同じ一連の属性を有する。
上述したように、ストリームは、CQL問い合わせが作用し得るデータの主要なソースであってもよい。ストリームSは、要素(s,T)のバッグ(「マルチセット」とも称す)であってもよく、「s」は、Sのスキーマに含まれ、「T」は、時間ドメインに含まれる。これに加えて、ストリーム要素は、タプルとタイムスタンプとのペアであってもよく、タイムスタンプが記録されたタプル挿入のシーケンスとして表され得る。つまり、ストリームは、タイムスタンプが記録されたタプルのシーケンスであってもよい。場合によっては、同じタイムスタンプを有する2つ以上のタプルがあってもよい。そして、入力ストリームのタプルは、タイムスタンプの昇順でシステムに到着する必要があってもよい。これに代えて、リレーション(「時間変化リレーション」とも称す。リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同しないこと。)は、時間ドメインからスキーマRの無限のタプルバッグへのマッピングであり得る。いくつかの例では、リレーションは、順序付けされていない、時間で変化するタプルバッグ(すなわち、瞬間のリレーション)であってもよい。場合によっては、各時間において、リレーションは、有界集合であってもよい。リレーションは、リレーションが変化する状態を捉えるために挿入、削除、および/または更新を含み得る、タイムスタンプが記録されたタプルのシーケンスとして表すこともできる。ストリームと同様に、リレーションは、リレーションの各タプルが準拠し得る固定スキーマを有してもよい。さらに、本明細書で使用するとき、連続クエリは、一般に、ストリームおよび/またはリレーションのデータを処理することが可能であってもよい(すなわち、問い合わせされる)。これに加えて、リレーションは、ストリームのデータを参照してもよい。
いくつかの態様では、CQLエンジンは、本格的な問い合わせ言語を含んでもよい。このように、ユーザは、問い合わせによって計算内容を指定してもよい。これに加えて、CQLエンジンは、メモリの最適化、問い合わせ言語特性の利用、演算子の共有、リッチパターンマッチング、リッチ言語構成などのために設計されてもよい。これに加えて、いくつかの例では、CQLエンジンは、過去データおよびストリーミングデータの両方を処理してもよい。たとえば、ユーザは、カリフォルニア州での売上が特定の目標を上回った場合にアラートを送るためのクエリを設定できる。よって、いくつかの例では、アラートは、過去の売上データおよび受信中のライブの(すなわち、リアルタイムの)売上データ、の少なくとも一部に基づいてもよい。
いくつかの例では、CQLエンジンまたは後述する概念の他の特徴は、リアルタイムで過去のコンテキスト(すなわち、ウェアハウスデータ)を受信データと結合するように構成されてもよい。よって、場合によっては、本開示は、データベースに格納された情報とインフライト情報との境界を記述してもよい。データベースに格納された情報およびインフライト情報は、BIデータを含んでもよい。このように、データベースは、いくつかの例では、BIサーバであってもよく、または、任意の種類のデータベースであってもよい。さらに、いくつかの例では、本開示の特徴は、プラグラミングの仕方またはコードの書き方をユーザが知らなくても上記の特徴が実施されることを可能にしてもよい。つまり、この特徴は、多機能ユーザインタフェース(UI)で提供されてもよく、または、開発者でない者が過去データとリアルタイムデータとの結合を実現できるようなその他の方法で提供されてもよい。
いくつかの例では、上記の概念を利用して、複合イベント処理に関連付けられた豊富なリアルタイムの連続イベント処理能力を活用してもよい。これに限定されないが、アーカイブされたリレーションなどのいくつかの特徴がサポートされてもよい。このように、このような特徴(たとえば、豊富なリアルタイムの連続イベント処理)活用するために、システムは、リレーショナルデータのスタートアップ状態および実行時状態を透過的に取り扱うように構成されてもよい。つまり、システムは、空でないクエリを作成された時点から管理するように構成されてもよい(すなわち、アーカイブされたリレーション)。
いくつかの例では、アーカイブされたリレーションを利用してもよい。このように、クエリがアーカイブされたリレーションに基づいていることを示す当該クエリをCQLエンジンが確認した場合、そのアーカイブされたリレーションは、たとえば、過去のコンテキストを問い合わせするためにリレーションが呼び出すことができる特定のエンティティがあることも示してもよい。いくつかの例では、データ定義言語(DDL:Data Definition Language)は、これらに限定されないが、問い合わせをどのように行うか、テーブルにおいて重要なカラムはどれであるか、および/または残りのデータの送リ先など、アーカイブされたリレーションについての注釈を示してもよい。いくつかの例では、CQLエンジンにおいてクエリが組み立てられると(たとえば、グラフとして)、システムは、質問グラフを分析してもよい。これに加えて、いくつかの態様では、「distinct」、「group aggr」、「pattern」、および/または「group by」のような、ステートフルな特定の演算子がある。しかしながら、ステートレスな演算子は、入力を取ってそれを親、たとえば、下流の演算子に送るだけであろう。ついては、1つの手法は、このテーブル全体をここに記憶することである。しかしながら、アーカイブされたリレーションを利用して、システムは、質問グラフを分析して、アーカイブを問い合わせするのに使用できる最下位のステートフル演算子がどれであるかを決めてもよい。いくつかの例では、システム(または、1つ以上のコンピュータにより実現される方法)は、グラフを横断しながら到達した最下位のステートフル演算子での状態を検索してもよい。たとえば、質問グラフは、ソースからトポロジー順に分析されてもよい。この最初のステートフル演算子の少なくとも一部に基づいて、CQLエンジンは、アーカイブされたリレーションに対して定義されたクエリの演算子の状態を初期化するために、フェッチするデータの最適な量を決定してもよい。
少なくとも1つの非限定例では、リレーションおよび/またはソースのようなソース演算子は、トポロジー横断において最初に出現してもよく、クエリが出力されるおよび/またはルートが最後に来る。たとえば、CQLクエリがselect sum(c1)from R1 where c2>c25、のような場合、このクエリのプランは、RelationSource→SELECT→GroupAggr、のようになるだろう。よって、トポロジー順に従って、RelationSourceおよびSELECTは両方ステートレスであるので、最下位のステートフル演算子は、GroupAggrであろう。このように、クエリのステートフル演算子(この例において、GroupAggr)は、クエリエンジンがストリーミングデータを受信する前にデータストアからの過去データで当該クエリエンジンを満たすことを可能にしてもよい。これは、アーカイブされたリレーションをクエリが分析しており、アーカイブされたリレーションがそのように示されている、ということの少なくとも一部に基づいて可能になってもよい。
いくつかの例では、所与のアーカイブされたリレーションのウィンドウサイズは、ユーザによって指定されてもよい。いくつかの態様においてアーカイブされたリレーションと関連しているウィンドウは、ストリーム配信された受信コンテンツを分析または評価する質問グラフにおけるノードを含んでもよい。つまり、ウィンドウは、クエリエンジンによって分析および/もしくは処理されるストリーム配信されたコンテンツの量ならびに/またはアーカイブされたリレーションに含まれることになる過去データの量を規定してもよい。
ハイレベルでは、ウィンドウがStreamに適用されると、それはRelationになり、その後、リレーショナルデータベースと同様に通常の関係論理が適用されてもよい。タプルがウィンドウに到着してウィンドウを離れると、当該Relationは、それに対してクエリがコンパイルされると変化し、それと同時に結果を出力する。CQLは、RANGE(最大でナノ秒の粒度)、ROWS、PARTITION BY、および拡張可能なウィンドウをサポートしてもよい。これらのウィンドウは、ストリームからリレーションへの演算子の例である。一方では、ISTREAM(すなわち、挿入ストリーム)、DSTREAM(すなわち、削除ストリーム)、およびRSTREAM(すなわち、リレーションストリーム)が、リレーションからストリームへの演算子である。いくつかの例では、ユーザ、開発者、および/または管理者は、クエリエンジンまたはクエリエンジンを操作もしくはホストしている1つ以上のコンピューティングシステムが提供するウィンドウサイズを(たとえば、UIを介して)設定してもよい。いくつかの例では、ストリーム上のウィンドウは、時間ベースの範囲ウィンドウであってもよい。たとえば、アーカイブされたリレーション上の構成可能な値ウィンドウは、ウィンドウサイズ、およびウィンドウが算出される属性を用いて指定されてもよい。アーカイブされたリレーション上で指定された構成可能な値ウィンドウがある場合、スナップショットクエリが計算されてもよく、ウィンドウ制限内のスナップショットタプルが出力されてもよい。これに加えて、状態の初期化後、値ウィンドウは、受信アクティブデータに適用されてもよい。いくつかの例では、ウィンドウ属性の値がウィンドウサイズよりも小さい、現在のイベント時刻とは異なるウィンドウに、受信アクティブデータだけが挿入されることになる。
これに加えて、いくつかの例では、本開示の特徴は、CQLエンジンおよび/またはCEPエンジンの連続クエリ処理機能を活用してデータのリアルタイム分析をサポートしてもよい。いくつかの態様では、CQLエンジンおよび/またはCEPエンジンは、従来、ストリーム指向分析エンジンであったと思われる。しかしながら、堅牢なストア(たとえば、上述したアーカイブされたリレーション)が支援するストリーム指向データをサポートするよう強化されてもよい。たとえば、本開示は、堅牢なストア(データベースおよび/またはテーブル)であるデータオブジェクト(DO:Data Object)の概念をサポートし得る特徴を記載する。DOに対して行われた修正によって、データストリームを事実上作成している関心のあるリスナーに変更通知がブロードキャストされてもよい。このデータストリームは、実行中のクエリをサポートしているCQLエンジンおよび/またはCEPエンジンによって消費されてもよい。しかしながら、CQLエンジンおよび/またはCEPエンジンは、DO支援ストアに含まれる既存データを考慮するように設計されていないかもしれない。たとえば、CQLエンジンおよび/またはCEPエンジンは、CQLエンジンおよび/またはCEPエンジンで実行中のクエリの初期状態がDO支援ストアに現在あるすべてのデータを含むDOの現在の状態を反映するよう、要求してもよい。このクエリがこのように初期化されると、CQLエンジンおよび/またはCEPエンジンは、従来のストリーム指向スタイルで、その時点以降のDO変更通知のストリームと関わるだけでよい。
いくつかの態様では、CQLエンジンおよび/またはCEPエンジンは、ストリームまたはアーカイブされていないリレーションを従来的に処理している可能性があり、それ故、初期状態が存在しない可能性がある。たとえば、クエリがロードされてもよく、実行および変更などについての待ち受けを開始してもよい。場合によっては、ユーザが州別の売上を棒グラフで求め、その後、誰かが新しい売上を出した場合、テーブルは更新されてもよく、ユーザは、売上の変更がグラフに反映されていることを期待するだろう。しかしながら、ダッシュボードを閉じて1週間後に再び売上を表示した場合、ユーザは、積算売上データのテーブルに従って売上の合計を得ると期待するだろう。つまり、クエリは、クエリをアーカイブ状態にしてからアクティブな変更を待ち受ける必要があってもよい。
いくつかの態様では、たとえば、CQLエンジンは、アーカイブされたデータを用いて予め初期化されてもよい。初期化されると、CQLエンジンは、JMS(Java Messaging Service)または変更通知用の他のメッセンジャーを(たとえば、アーカイブからのデータの挿入、削除などのためのAPI呼び出しの少なくとも一部に基づいて)待ち受けてもよい。よって、サービスは、待ち受けることができ、待ち受けサービスが待ち受けている同じトピックをJMSが発信した場合、サービスは、データを受信してもよい。サービスは、誰が発信しているか、または発信しているかどうかを把握していなくてもよい。待ち受けサービスは、待ち受けることができるだけであり、何かが起こると、待ち受けサービスはそれが聞こえてもよい。いくつかの例では、これが、たとえば顧客から持続性が切り離される方法である。これに加えて、いくつかの例では、アラートエンジンは、アラートエンジンが聞いた内容、場合によっては、そしてさらにはリスナーに関連性のあるプロセスクエリを待ち受けている可能性のあるSQLエンジンに基づいてアラートを挙げてもよい。
いくつかの例では、クエリは、CQL、SQL、および/またはCEPエンジンで開始されてもよく、命令は、アーカイブデータを取得して(たとえば、エンジンを準備し)、その後、これらのJMSメッセージの待ち受けを開始するように構成されてもよい。しかしながら、挿入、削除などが膨大であると、大量の情報を含んでいる可能性がある。これに加えて、メッセージがリスナーに聞かれる前にタイムラグがある可能性があり、待ち受けは、いくつかの例では、急いでクエリのアーカイブを問い合わせして戻ってきて待ち受けを開始する可能性がある。よって、イベントを喪失してしまう、および/または二重にカウントしてしまう可能性がある。
これに加えて、エンジンが単にクエリを実行するだけである場合、クエリを実行中に様々なものがJMSに入ってしまってエンジンが待ち受けをしていないところでそれらが発信されてしまう可能性がある。そのため、エンジンは、リスナーを最初にセットアップしてからアーカイブクエリを実行し、その後、戻ってきて実際に待ち行列から取り出し始めるように構成されてもよく、これにより、何も見逃さなくなる。よって、JMSは、待ち行列に様々なものを入れてもよく、たとえ停滞したとしても、エンジンが問い合わせをしている間は大丈夫である。なぜならば、エンジンはその後キャッチアップでき、同期しているかどうかについて気にしなくてよいからである。エンジンがここで待ち受けをしていなくても、エンジンがリスナーを設定している限り、見逃すことはなく、エンジンが戻ってくるまでただ待ち行列に入れられる。
これに加えて、いくつかの例では、システムカラムがユーザのデータに追加されてもよい。このシステムカラムは、二重カウントおよび/または喪失操作問題の処理を図るためにトランザクションIDを示すためのものであってもよい。しかしながら、他の例では、システムは、トランザクションコンテキストテーブルを提供または生成してもよい。これに加えて、2つのさらなるカラムであるTRANSACTION_CIDとTRANSACTION_TIDとがあってもよい。コンテキストテーブルは、スレッド(コンテキスト)的に最後にコミットされたトランザクションIDが分かるよう、永続サービスによって常に維持されてもよい。トランザクションIDがスレッド(コンテキスト)の昇順でコミットされることを保証してもよい。たとえば、サーバは、立ち上がると、永続サービスを実行してもよい。各々は、予め初期化された情報のデータがJMSを通したデータのすべてを含んでいるかどうかを判断するための、コンテキストIDとトランザクションIDとのセットを割り当ててもよい。これに加えて、場合によっては、(JTAに準拠して、および/または高可用性(HA)を実現するために)複数の出力サーバが利用されてもよく、各サーバは、その他のサーバが管理するその他のテーブルとは完全に異なる1つコンテキスト/トランザクションテーブルのセットを管理してもよい。
いくつかの実施形態では、連続(たとえば、CQL)クエリが作成または登録された場合、このクエリは、構文解析および意味分析にかけられてもよく、最後に論理クエリプランが作成される。たとえば、「alter query <queryname> start」DDLを発行することによってCQLクエリが開始されると、論理クエリプランは、物理クエリプランに変換されてもよい。一例において、物理クエリプランは、物理演算子のDAG(Directed Acyclic Graph)などと表されてもよい。次に、物理演算子は実行演算子に変換され、そのCQLクエリの最終クエリプランに到着してもよい。CQLエンジンに入ってくるイベントはソース演算子(複数可)に到達し、最終的に、これらのイベントに処理を実行して適切な出力イベントを生成する方法で、演算子とともに下流に移動する。
イベント処理アプリケーション
RAWインフラストラクチャおよびビジネスイベントの量および速度は、IT環境において急激に増加している。それが金融サービスの株式データをストリーミング配信していようと、軍用衛星データまたは運送/ロジスティクス業のリアルタイム車両位置データをストリーミング配信していようと、複数の業界の企業は、大容量の複合データをリアルタイムで処理しなければならない。これに加えて、モバイル機器の急激な増加および高速接続性の偏在性がモバイルデータの急激な増加を増大させる。同時に、ビジネスプロセスの俊敏性および実行の需要も増えている。これらの2つの傾向が、実装のイベント駆動型アーキテクチャパターンをサポートする能力を上げるよう、組織に圧力をかけている。リアルタイムイベント処理は、イベント処理要件を実行するためのインフラストラクチャおよびアプリケーション開発環境の両方を必要とする。これらの要件は、日々のユースケースから、潜在的に、数秒の応答時間ではなく、マイクロ秒で計測されるレイテンシを有する非常に高速のデータおよびイベントスループットまで拡大する必要性を含んでいる場合が多い。これに加えて、イベント処理アプリケーションは、これらのイベントのフローに含まれる複雑なパターンを検出しなければならないことが多い。
Oracle Stream Analyticsプラットフォームは、多くの業界および機能分野を対象としている。以下に、いくつかのユースケースを示す。
テレコミュニケーション:リアルタイムで呼詳細レコード(CDR:Call Detail Record)の監視およびDoS(Denial Of Service)攻撃の検出を行う能力。
金融サービス:ミリ秒またはマイクロ秒の期間に存在する裁定取引する商機に出資する能力。金融証券取引のリスク分析、監視および報告をリアルタイムで行い、外国為替価格を算出する能力。
運輸:地域または目的地の天候、地上整備員の作業、空港セキュリティなどによるフライトの不具合の場合に乗客向けアラートを作成し、手荷物の場所を検出する能力。
公共部門/軍事:地理的な分散した敵の情報を検出、抽出して、高確率の敵の攻撃を読み解く能力。最適なリソースをアラートして非常事態に対応する能力。
保険:詐欺の可能性がある請求を学習および検出する能力。
ITシステム:障害が発生しているアプリケーションまたはサーバをリアルタイムで検出し、修正措置を作動させる能力。
サプライチェーンおよびロジスティクス:出荷をリアルタイムで追跡し、到着が遅れる可能性を検出および報告する能力。
リアルタイムストリーム配信およびイベント処理アナリティクス
互いに接続されるデバイスの数が増えるにつれてデータが急激に増加することにより、組織内を移動するデータだけでなく、ファイアウォール外を移動するデータについても動的に変化するデータが大量に増えている。高速データは、特に変動が激しいビジネスプロセスにとって大きな価値がある。しかしながら、このデータのうちのいくつかは、短時間でその運用価値が失われてしまう。ビッグデータを利用すれば、実用的な洞察を行うための処理を時間をかけて行うことができる。一方では、ファストデータ(Fast Data)の場合、非常に動的かつ戦略的なデータから最大限の価値を引き出す必要がある。ファストデータは、さらに高速な処理が必要とされ、生成されたデータにできるだけ近いタイムリーなアクションを取ることができるようになる。Oracle Stream Analyticsプラットフォームは、応答性が向上したファストデータを実現することができる。Oracle Edge Analyticsでは、ネットワークエッジに処理がプッシュされ、データを相関分析、フィルタ処理、および分析して、実用的な洞察をリアルタイムで行うことができる。
Oracle Stream Analyticsプラットフォームは、永続データを有する受信ストリーミングイベントをつなぎ合わせる能力を提供することにより、前後関係を意識したフィルタ処理、相関分析、アグリゲーション、およびパターンマッチングを提供する。共通のイベントソース(Event Source)用に軽量かつそのまますぐに使える(out of the box)アダプタを提供する。また、カスタムアダプタの開発のための使いやすいアダプタフレームワークを提供する。このプラットフォームによって、組織は、商機、および無関係に思われるイベントが表す脅威を特定して予期することができるようになる。そのインクリメンタル処理規範は、最低限の量のリソースを用いてイベントを処理することができ、待機時間が極端に少ない。また、非常にタイムリーなアラートを作成し、次のような喪失または遅延したイベントをすぐに検出できるようにもなる。
関連するイベント:イベントAが発生すると、イベントBは、ほとんどの場合、その2秒以内に発生する。
喪失したイベントやシーケンス外のイベント:イベントA、B、Cは、この順で発生するはずであるが、CがAの直後に発生し、Bが発生しない。
原因となるイベント:製品の重さが徐々に減少したり、読み取り値が許容基準の範囲外になったりする。潜在的な問題や今後のメンテナンスの必要性について、信号を出す。
Oracle Stream Analyticsプラットフォーム設計環境およびランタイム実行では、リアルタイムイベントソーシングに加えて、イベントストリームならびに、データベースおよび高性能のデータグリッドのような永続データストアの両方に対して、標準ベースの連続クエリ実行がサポートされる。これによって、プラットフォームは、マイクロ秒のまたは数秒で、(そうでなければ見過ごされる可能性のある)パターンおよび傾向を認識するために回答を得る必要のあるシステムのインテリジェンスの中核として機能することができる。イベント処理のユースケースでは、数学的な正確性と標準データベースSQLの信頼性とを備えた、高速のメモリ内処理が必要とされる。このプラットフォームのクエリは、受信イベントストリームを待ち受けて、クエリを最適化する高度な自動アルゴリズムを利用して、メモリ内で各イベントに対して登録済みクエリを連続して実行する。しかしながら、メモリ内実行モデルに基づいているものの、このプラットフォームは、クエリ開発に標準ANSI SQL構文を活用するので、クエリ構成の正確性および拡張性が確保される。このプラットフォームは、ANSI SQL'99規格と完全に互換性があり、ANSI SQLの審査を受けたリアルタイムの連続クエリパターンマッチングのための標準SQLの拡張機能をサポートした業界初の製品であった。CQLエンジンによって、プロセッサ内のクエリの実行が最適化されるので、開発者は、最適化よりもビジネスロジックに集中することができる。
Oracle Stream Analyticsプラットフォームでは、SQLとJavaコードとを組み合わせて堅牢なイベント処理アプリケーションを提供することができる。標準の業界用語を利用してイベントソース、プロセッサ、およびイベント出力またはイベントシンクを記述することにより、このプラットフォームは、アプリケーション内のイベントを定義および操作するためのメタデータ駆動型の手法を提供する。その開発者は、アプリケーション設計のための視覚的な、方向付きのグラフ・キャンバスおよびパレットを使用して、イベント間およびデータソース間のイベントおよび処理のフローの概略を素早く作成することができる。開発者は、ドラッグ・アンド・ドロップモデルと構成ウィザードとによってこのフローを作成し、適切なメタデータ定義を入力して、設計を実装に結びつけることができる。開発者は、必要性や好みに応じて、ワンクリックで、カスタムJavaコード開発に変更したり、Spring(登録商標)フレームワークを用いて最新の概念をアプリケーションに直接コーディングしたりすることができる。
イベント駆動型アプリケーションは、多くの場合、非常に高速なストリーミング入力データを処理するにもかかわらず、レイテンシが低くかつ決定的(deterministic)でなければならない、という特徴がある。Oracle Stream Analyticsプラットフォームの土台は、OSGi(登録商標)バックプレーンに基づく軽量Javaコンテナである。軽量Javaコンテナは、セキュリティ、ロギング、および作業管理アルゴリズムなど、WebLogic JEE アプリケーションサーバの成熟したコンポーネントを含んでいるが、これらのサービスをリアルタイムのイベント処理環境で活用している。統合されたリアルタイムカーネルにより、一意のサービスが提供され、JMXフレームワークがサポートするスレッドおよびメモリ管理が最適化され、パフォーマンスおよび構成に関してコンテナとやり取りができるようになる。Web2.0リッチインターネットアプリケーションは、HTTPパブリッシュ/サブスクライブサービスを用いてプラットフォームと通信できる。HTTPパブリッシュ/サブスクライブサービスは、Web2.0リッチインターネットアプリケーションがアプリケーションチャネルを利用してイベントをクライアントにプッシュさせることを可能にする。小さいフットプリントでは、このプラットフォームは、軽量のJavaベースのコンテナであり、本番への導入時間を短縮し、所有権の総コストを低減することができる。
Oracle Stream Analyticsプラットフォームは、最適にはOracle Exalogicおよび他のEngineered Systemのポートフォリオを用いて、標準的な汎用ハードウェアに対してマイクロ秒の処理レイテンシで1秒あたり何百万というイベントを処理する能力がある。これは、完全な「トップダウン」の階層的ソリューションによって実現され、高パフォーマンスのイベント処理のユースケースだけでなく、エンタープライズクラスのリアルタイム処理インフラストラクチャコンポーネントとの緊密な統合にも設計の重点を置いている。パフォーマンス優先のサーバクラスタのプラットフォームアーキテクチャは、Oracle Coherence技術への緊密な統合による信頼性、フォールトトレランス、および非常に高い柔軟性に重点を置いているため、ミッションクリティカルなアプリケーションをデータグリッドの端から端まで企業が予想どおりにスケーリングし、連続データの可用性およびトランザクション上の完全性を確実にすることができる。
これに加えて、このプラットフォームにより、決定的処理が可能になり、これは、同じイベントを複数のサーバに、または同じサーバに異なる速度で送り込むことができ、毎回同じ結果を達成することを意味する。これにより、動作中のサーバのシステムクロックにしか頼っていないシステムと比べて素晴らしい利点を得ることができる。
上述および後述の技術は、いくつかの方法およびいくつかのコンテキストで実現されてもよい。いくつかの例示的な実装形態およびコンテキストを以下の図面を参照しながら提供するが、さらに詳細は後述する。しかしながら、以下の実装形態およびコンテキストは、たくさんあるうちの一部である。
ジオフェンス・ベースのアプリケーションのための自動並列処理
自動車交通量監視などのアプリケーションでは、データは、連続データストリームの形である。連続データストリームは、はっきりとした終端範囲なしでストリーム処理サーバに到着するデータのストリームである。連続データストリームを処理することによって、アプリケーションは、複雑なパターン、イベント間の相関関係、およびイベント間の関係を検出できる。たとえば、連続データストリームは、高速道路の特定の区画を通過する車についての情報を有していてもよい。自動車は、位置座標を継続的に送ることができる。このデータストリームに基づいて、車両台数と他の車両を利用している人の数との「m」対「n」関係をソリューションが処理する必要がある状況において自動車の位置の近くにいる人を検出するなどの問題、または、車両台数が百万台にわたるときの問題を解決してもよい。
従来のデータベースシステムおよびデータ処理アルゴリズムにおいてサポートされる空間データは、通常、有限の格納データセットとして格納された空間データを処理するように設計されている。従来のデータベースシステムは、SQLなどのデータ管理言語を用いてデータが問い合わせおよび操作されるデータベーステーブルにデータを格納する。しかしながら、データベース管理システムおよびアルゴリズムは、ジオメトリの連続データストリームを処理できない。なぜならば、データベース管理システムおよびアルゴリズムは、大量であるが有限のデータの集まりをシステムが格納するという想定に基づいて設計されているからである。
メモリ資源が制限されているため、限られた数の移動オブジェクトしか1つのアプリケーションによってサポートすることができない。スケーラビリティの問題を解決するために、クラスタリングが利用され得る。しかしながら、単純なクラスタリングでは、上述した人検出問題など、特定のユースケースの問題を解決することができない。なぜならば、通常、処理ノード間でサポートする領域がいくつか重複している必要があるからである。
以前の手法では、ジオ・パーティショナを用いて上記の問題を解決していた。ジオ・パーティショナは、通常、領域が予め定義された距離を有して分割されるグリッドベースの手法、または、ジオメトリが入力ジオメトリをパーティション分割する領域を指定する領域ベースの手法に基づいている。この手法は、パーティションが固定であり、パーティションでの移動オブジェクトの変更を反映することができない静的手法である。たとえば、この手法は、グリッドに含まれる移動オブジェクトの数が突然増える、たとえば、スタジアムでの野球の試合が終了したときにタクシーの台数が増加するシナリオに対応できないと思われる。
特定の実施形態では、動的グリッドは、K-MeansまたはDBSPANなどの空間クラスタリングアルゴリズムに基づいて生成される。図1は、空間クラスタリングアルゴリズムを用いてパーティションのサイズを動的に決定するための技術が実装される例示的な動的グリッドシステムまたはアーキテクチャ100を示す図である。様々な実施形態では、動的グリッドシステムまたはアーキテクチャ100は、次のコンポーネントを含む。空間クラスタジェネレータ(SCG:Spatial Cluster Generator)105、クラスタベース・パーティショナ(CBP:Cluster Based Partitioner)110、および空間クエリプロセッサ(SQP:Spatial Query Processor)115。空間クラスタジェネレータ105コンポーネントは、継続的にK-MeansまたはDBSCANなどの空間クラスタアルゴリズムを漸進的に実行して、入力ジオメトリからジオメトリクラスタを作成するように構成されてもよい。出力(クラスタジオメトリおよびクラスタに含まれるジオメトリの数)は、クラスタベース・パーティショナ110に送られてもよい。クラスタベース・パーティショナ110コンポーネントは、入力ジオメトリをパーティション分割して、どのジオメトリがどのパーティションに行くかを決定するように構成されてもよい。いくつかの実施形態では、クラスタベース・パーティショナ110は、パーティションサイズを動的に変更する役割がある。空間クエリプロセッサ115コンポーネントは、空間クエリを処理する。一例として、空間カートリッジ(Spatial Cartridge)を有するCQLEngineがある。各空間クエリプロセッサ115コンポーネントは、1つ以上のパーティションを処理するように構成されてもよい。図1に示すコンポーネントのうちの1つ以上は、ソフトウェアで、ハードウェアで、またはそれらの組合せで実現されてもよい。いくつかの実施形態では、ソフトウェアは、メモリ(たとえば、非一時的なコンピュータ読み取り可能な媒体)に、メモリ素子または他の物理メモリ上に格納されてもよく、1つ以上の処理装置(たとえば、1つ以上のプロセッサ、1つ以上のプロセッサコア、1つ以上のGPUなど)によって実行されてもよい。
図2~図4は、いくつかの実施形態に係る空間クラスタリングアルゴリズムを用いてパーティションのサイズを動的に決定するための技術を説明する図である。個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明される場合もある。フローチャートは、逐次プロセスとして動作を示し得るが、これらの動作の多くのは、平行してまたは同時に実行してもよい。これに加えて、動作の順序は、並び替えられてもよい。プロセスは、その動作が完了したときに終了するが、図に含まれない追加ステップを有し得る。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに相当してもよい。プロセスが関数に相当する場合、その終了は、呼び出し関数またはメイン関数へのこの関数の戻りに相当してもよい。
図2~図4に示す処理および/または動作は、1つ以上の処理装置(たとえば、プロセッサコア)によって実行されるソフトウェア(たとえば、コード、命令、プログラム)、ハードウェア、またはそれらの組合せで実現されてもよい。ソフトウェアは、(たとえば、メモリ素子上、非一時的なコンピュータ読み取り可能な記憶媒体上の)メモリに格納されてもよい。図2~図4の特定の一連の処理は、限定を意図したものではない。また、他のステップのシーケンスが別の実施形態に従って実行されてもよい。たとえば、別の実施形態では、概要を上述したステップを異なる順序で実行してもよい。また、図2~図4に示す個々のステップは、個々のステップに応じて様々なシーケンスで行なわれ得る複数のサブステップを含んでもよい。さらに、特定のアプリケーションに応じてさらなるステップが追加または削除されてもよい。当業者は、多くの変形例、変更例、および代替例が分かるだろう。
図2は、本開示の実施形態が実施する全体的なワークフローを説明するフローチャート200を示す。いくつかの実施形態では、フローチャート200に示す処理は、動的グリッドシステムまたは図1のアーキテクチャ100によって実施されてもよい。ステップ205において、アプリケーションに関する連続データストリームを受信してもよい。ステップ210において、連続データストリームに関連付けられた入力ジオメトリを特定してもよい。入力ジオメトリは、連続データストリームにおけるパーティション分割される領域を指定してもよい。ステップ215において、入力ジオメトリをSCGに送信してもよい。ステップ220において、SCGは、入力ジオメトリにインクリメンタル空間クラスタアルゴリズムを実行し、入力ジオメトリの少なくとも一部に基づいてジオメトリクラスタを生成してもよい。ステップ225において、ジオメトリクラスタおよびジオメトリクラスタに含まれる各クラスタにおけるジオメトリの数に、少なくとも部分的に基づいて、SCGによって出力ジオメトリを生成してもよい。ステップ230において、SCGは、出力ジオメトリをCBPに送信してもよい。ステップ235において、CBPは、SCGからのジオメトリクラスタおよびジオメトリの数を用いて出力ジオメトリの1つ以上のパーティションを決定してもよい。いくつかの実施形態では、CBPのパーティションアルゴリズムは、次の処理を含んでもよい。(i)クラスタ変更検出、(ii)クラスタ削除、(iii)パーティションの変更、および(iv)入力ジオメトリへのパーティション識別子の割り当て。これらの処理はさらに詳細に後述する。ステップ240において、出力ジオメトリの1つ以上のパーティションのサイズを動的に変更してもよい。ステップ245において、連続データストリームに関連付けられた出力ジオメトリを、1つ以上のパーティションのサイズが動的に変更された状態で送信してもよい。
図3は、本開示の実施形態が実施するCBPのクラスタ変更検出処理を説明するフローチャート300を示す。いくつかの実施形態では、フローチャート300に示す処理は、動的グリッドシステムまたは図1のアーキテクチャ100によって実施されてもよい。特定の実施形態では、RTreeインデックスなどのインデックスを用いてクラスタに変更があるかどうかの判断を行い、クラスタの変更を検出してもよい。RTreeインデックスまたはR-treeは、空間アクセス方法の、すなわち、地理的位置、四角形、または多角形などの多次元情報をインデックス付けするために使用されるツリーデータ構造である。ステップ305において、クラスタのバウンディングボックスをRTreeにロードしてもよい。ステップ310において、RTreeインデックスに含まれる出力クラスタのルックアップを行い、それらのサイズを比較してもよい。たとえば、ジオメトリクラスタのバウンディングボックスをインデックスにロードしてもよく、ジオメトリクラスタを、RTreeインデックス内の他のジオメトリクラスタと比較してもよい。クラスタのサイズを含む1つ以上のパラメータに基づいて比較が行われてもよい。ステップ315において、クラスタがインデックスから見つからなかった場合、クラスタが新しいクラスタであると判断がされてもよい。ステップ320において、クラスタが新しいクラスタである場合、古いクラスタサイズなしでパーティション変更処理を実行してもよい。ステップ325において、クラスタがインデックスから見つかった場合、クラスタが新しいクラスタではない(たとえば、既存クラスタ)との判断がされてもよい。ステップ330において、クラスタが新しいクラスタではない場合、サイズ閾値を特定してパーティションの変更を決定してもよい。たとえば、このサイズ変更がXパーセントである場合、Xパーセントを用いてパーティション変更処理を実行してもよい。
図4は、本開示の実施形態が実施する、クラスタ削除処理、パーティションの変更処理、およびパーティション識別子の割り当て処理を説明するフローチャート400を示す。いくつかの実施形態では、フローチャート400に示す処理は、動的グリッドシステムまたは図1のアーキテクチャ100によって実施されてもよい。ステップ405において、タイマを用いて所定時間SCGからクラスタが見つからなかった場合、RTreeに含まれるクラスタを削除してもよい。ステップ410において、パーティションを変更してもよい。これには、グリッド範囲の決定、インデックステーブルをパーティション分割するためのグリッドインデックスの作成、および、パーティション識別子を割り当てる際にRTreeに格納されたクラスタオブジェクトが利用できるよう、インデックステーブルをパーティション分割するためのグリッドインデックスをクラスタオブジェクトに設定することが含まれてもよい。グリッド範囲の決定は、構成パラメータ、GridSize、SizeEffectFactor、およびSCGから与えられたジオメトリの数によって実施されてもよい。例では、GridSizeは、式(GridSize/(ジオメトリ数×SizeEffectFactor)を適用することによって、ジオメトリの数を用いて調整されてもよい。クラスタのバウンディングボックスは、調整済みのGridSizeによって分割されてもよく、これにより、新しいパーティションが作成されるまたはさらなるパーティションが追加される。例では、コンシステントハッシュ技術を用いてパーティション識別子を作成し、システムを負荷を分散させた状態に維持してもよい。グリッドインデックスは、パーティションIDに直接対応付けられないので、いくつかの実施形態では、ルックアップテーブルを用いてグリッドインデックスをパーティションIDに対応付けてもよい。特定の実施形態では、クラスタ削除アルゴリズムは、パーティションIDの入力ジオメトリへの割り当てをさらに含んでもよい。パーティション識別子の割り当ては、RTreeでクラスタを探索し、範囲比較によってグリッドを見つけ、インデックステーブルをパーティション分割するためのグリッドインデックスをルックアップすることによって行われてもよい。よって、本開示の実施形態は、空間クラスタリングとグリッドパーティション分割とを組合せた空間クラスタリングアルゴリズムを用いてパーティションのサイズを動的に決定するための技術を提供する。さらに、ジオメトリのストリームからパーティションおよびグリッドサイズを動的に変更するための技術を開示する。
図5は、本開示の実施形態に係る、入力ジオメトリ505、入力ジオメトリ505がロードされ得るRTreeなどのインデックス510、および、グリッド範囲とインデックステーブルをパーティション分割するためのグリッドインデックスとを含むグリッド515、のうちの少なくとも一部に基づいて生成されるジオメトリクラスタの例の説明図である。グリッドインデックスは、インデックス510に格納されたクラスタオブジェクトに設定される。
Sparkストリーミングにおける空間変化検出器およびチェック・セット操作
本開示の実施形態は、ストリームに含まれる移動オブジェクトの近接検出およびチェックを実行する技術を提供する。様々な実施形態では、移動オブジェクトを追跡でき、2つの以上の移動オブジェクトが互いに近接している場合にアラートを作成できる空間変化検出器が開示されている。たとえば、空間変化検出器は、空港にある移動オブジェクトを追跡し、それらが所与の範囲内に接近しないようにすることができる。
いくつかの実施形態では、移動オブジェクトの追跡は、空間「withindistance」演算を利用して実施されてもよい。しかしながら、移動オブジェクトがストリームの一部である場合、移動オブジェクトストリームの自己結合からのn!個の組合せの間の距離を算出しなければならない。GPSから2つの位置の間の距離を算出することは、比較的重い点演算であり得る。本開示の実施形態が実施する1つの解決法は、図6に示す空間変化検出器600を利用することである。空間変化検出器600は、ストリーム605のジオメトリ(たとえば、車両の位置についてのデータ)をリレーション610に変換し、ストリーム605とリレーション610との結合演算615を行う。FROM句におけるTableExpressionに含まれ得る結合演算は、2つのデータセットまたはテーブルセット間の結合を行う。これにより、リレーションからの空間インデックスを利用することができ、n!個の組合せの距離の算出を回避する。空間インデックスは、空間カラムをインデックス付けさせる種類の拡張インデックスである。空間カラムは、geometry型またはgeography型など、空間データ型のデータを含んでいるテーブルカラムである。空間インデックスが活用される場合、範囲を用いてフィルタが適用され得、フィルタ処理された結果から距離が算出され得る。これにより、n乗演算が得られる。ストリーム605をリレーション610に変換するために、同じキーのコンテンツの変更が検出されてもよい。実施形態では、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ620を使用して、コンテンツの変更があるかどうかを検出し、「更新」イベントを発行し、ストリーム605をリレーション610に変換してもよい。HashMapなどのメモリ内キャッシュ620は、よく要求されるデータをメモリに保持することによってアプリケーションのパフォーマンスを向上させるように設計されてもよく、そのデータを取得するためのデータベースクエリの必要性を小さくする。その後、ストリーム605およびリレーション610を空間「withindistance」演算625に用いて移動オブジェクト同士のリレーションを追跡し、近接検出を行うことができる。「withindistance」などの空間演算は、ジオメトリ関数を用いて空間データを入力として取り、データを分析し、その後、入力データに対して行われた分析の派生物である出力データを生成する。
いくつかの実施形態では、チェック・セット操作(check and set operation)を実施してもよい。たとえば、(たとえば、乗客からの要求でタクシーを派遣している間に)オブジェクトのストリームに対する要求・照会操作がある場合、当該照会からのアービトレーションが必要である。上記の例について、乗客要求ストリームから、特定の範囲内のタクシーを決定することができる。候補のタクシーが見つかると、それらのタクシーの中から1台が選ばれて、ほかの乗客が同じタクシーのダブルブッキングを回避できるように、「予約済み」とマークされる。CQLはクエリ言語であり、手続き型言語ではないので、チェック操作およびセット操作は、同じ時間に行うことができない。
このようなチェック・セット操作をサポートする1つの方法に、メモリ内キャッシュ(または、HashMap)を使用する方法がある。並列処理のためのアトミック操作として用いられるテスト・アンド・セットまたはコンペア・アンド・スワップと同様に、メモリ内キャッシュ705がサポートする図7に示すセット(CheckAndSet)検出器700は、第1ストリーム710のジオメトリ(たとえば、車両の位置についてのデータ)をリレーション715に変換し、リレーション715と第2ストリーム725(たとえば、要求の位置についてのデータ)との間でチェック・セット操作720を行うように構成されてもよい。これにより、リレーションからの空間インデックスを利用することができ、n!個の組合せ間の距離の算出を回避する。空間インデックスを活用する場合、範囲を用いてフィルタが適用され得、フィルタ処理された結果から距離が算出され得る。これにより、n乗演算が得られる。第1ストリーム710をリレーション715に変換するために、同じキーのコンテンツの変更が検出されてもよい。実施形態では、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ705を用いて、コンテンツの変更があるかどうかを検出し、「更新」イベントを発行し、第1ストリーム710をリレーション715に変換してもよい。その後、チェック・セット操作720においてリレーション715および第2ストリーム725を、第1ストリーム710からのデータを第2ストリーム725からのデータと照合して(たとえば、乗客が要求した場所に近いタクシーが選ばれてもよい)エントリ・オブジェクトのプロパティを設定する(たとえば、ほかの乗客がダブルブッキングを回避できるようにタクシーを「booked(予約済み)」と印を付ける)よう、用いることができる。特定の実施形態では、「select passengerId, taxiId from taxiRelation, requestStream where taxiCache.checkAndSet(‘booked',true)」などのselectステートメントを用いて、エントリ・オブジェクトの「booked」プロパティがtaxiCacheにおいて「false」であるかどうかをチェックし、「booked」プロパティをtrueに設定し、trueを返し、エントリを変更することの副作用を作成しつつ、フィルタを結果に適用することができる。
様々な実施形態では、チェック・セット操作は、メモリ内キャッシュ(または、HashMap)を使用する必要があり、以下のように実施されてもよい。
CacheDStreamおよびCacheRDDを追加する
CQLEngineがシングルトンのCacheを作成する。
CQLEngineがデリゲートによってCacheメソッドのRPC操作を追加する。
CacheRDDをCQLEngineと共通にパーティション分割(co-partitioned)すべきである。
CacheRDDは、キャッシュRPC操作によってキャッシュ操作をCQLEngineにデリゲートする
Cache-変更を検知するための通常操作
if (get(key) == null) {
put
add(new TupleValue(PLUS, ...))
} else {
put
add(new TupleValue(UPDATE, ...)
}
if (expiredTupleQueue.size > 0) {
待ち行列からすべてのタプルを削除して削除
add(new TupleValue(MINUS, ...)
}
キャッシュは、タイマを開始してタプルを自己満了させ、満了したタプルを待ち行列expiredTupleQueueに追加する
キャッシュは、CheckAndSet操作も有する
value = get(key)
if (value.getProperty(property) != newValue)
value.setProperty(property, newValue)
return true
else return false
このように、上記技術を用いて、開示の空間変化検出器は、ジオメトリデータストリームに対する空間「withindistance」演算がより高速で実行されることを可能にし、開示のチェック・セット操作は、アービトレーションにCQLを提供することを可能にする。上記技術を用いて、移動オブジェクトの近接チェックおよび要求・派遣システムなどのジオ・ストリーミングのユースケースを実施することができる。
図8は、ストリームに含まれる移動オブジェクトの近接検出およびチェックを行うための技術およびチェック・セット操作が実施され得る例示的なシステムまたはアーキテクチャを示す図である。いくつかの実施形態では、イベント処理サービス、または、イベントストリームを処理するための環境を提供するように構成されたシステム800は、CQLプロセッサ805と、JAVAカートリッジ810と、タイマ815と、メモリ内キャッシュ820と、CacheRDD825とを備える。CQLプロセッサ805は、入力チャネルが提供するイベントに対して動作する1つ以上のCQLクエリに関連付けられてもよい。CQLプロセッサは、クエリ結果が書き込まれる出力チャネルに接続される。タイマ815は、有効期限を過ぎたデータを編成またはメモリ内キャッシュ820から削除するために使用されてもよい。少なくとも図6および図7に関して本明細書において説明するように、CacheRDD825は、データストリーム830を受信し、メモリ内キャッシュ820を利用してデータストリームをリレーション835に変換してもよい。
図9は、本開示の実施形態を組み込み得るイベント処理システム200の簡略化されたハイレベル図を示す。いくつかの実施形態では、イベント処理システム900は、1つ以上のイベントソース(904、906、908)と、イベントストリームを処理するための環境を提供するように構成されるイベント処理サービス(EPS)902(CQサービス902とも称する)と、1つ以上のイベントシンク(イベントシンク)(910、912)を含んでもよい。イベントソースは、EPS902によって受信されるイベントストリームを生成する。EPS902は、1つ以上のイベントソースから1つ以上のイベントストリームを受信してもよい。たとえば、図9に示すように、EPS902は、イベントソース904から第1の入力イベントストリーム914を受信し、イベントソース906から第2の入力イベントストリーム916を受信し、イベントソース908から第3のイベントストリーム918を受信する。1つ以上のイベント処理アプリケーション(920、922、および924)がEPS902上でデプロイされてEPS902によって実行されてもよい。EPS902が実行するイベント処理アプリケーションは、1つ以上の入力イベントストリームを待ち受けて、入力イベントストリームから1つ以上のイベントを注目イベントとして選択する処理ロジックに基づいて1つ以上のイベントストリームを介して受信したイベントを処理するように構成されてもよい。次に、注目イベントが1つ以上の出力イベントストリームの形で1つ以上のイベントシンク(910、912)に送られてもよい。たとえば、図9において、EPS902は、第1の出力イベントストリーム926をイベントシンク910に出力し、第2の出力イベントストリーム928をイベントシンク912に出力する。特定の実施形態では、イベントソース、イベント処理アプリケーション、およびイベントシンクは、1つのコンポーネントがその他のコンポーネントに変更を生じさせずにこれらのコンポーネントのうちのいずれかを追加または削除できるよう、互いから切り離される。
一実施形態では、EPS902は、共用サービスを有する、Equinox OSGiに基づいたものなどの軽量Javaアプリケーションコンテナを含んだJavaサーバとして実装されてもよい。いくつかの実施形態では、EPS902は、たとえば、JRockit Real Timeを用いることによって、イベントを処理するための超高スループットおよびマイクロ秒のレイテンシをサポートしてもよい。また、EPS902は、イベント処理アプリケーションを開発するためのツール(たとえば、Oracle CEP VisualizerおよびOracle CEP IDE)を含んだ開発プラットフォーム(たとえば、完全リアルタイムのエンドツーエンドJavaイベント駆動型アーキテクチャ(EDA:Java Event-Driven Architecture)開発プラットフォーム)を提供してもよい。
イベント処理アプリケーションは、1つ以上の入力イベントストリームを待ち受けて、1つ以上の入力イベントストリームから1つ以上の注目イベントを選択するためのロジック(たとえば、クエリ)を実行し、選択された注目イベントを1つ以上の出力イベントストリームを介して1つ以上のイベントソースに出力するように構成される。図9は、1つのこのようなイベント処理アプリケーション920のドリルダウンを示す図である。図9に示すように、イベント処理アプリケーション920は、入力イベントストリーム918を待ち受けて、入力イベントストリーム918から1つ以上の注目イベントを選択するためのロジックを含んだ連続クエリ930を実行し、選択された注目イベントを出力イベントストリーム928を介してイベントシンク912に出力するように構成される。イベントソースとして、アダプタ(たとえば、JMS、HTTP、およびファイル)、チャネル、プロセッサ、テーブル、キャッシュなどが挙げられるが、これらに限定されない。イベントシンクとして、アダプタ(たとえば、JMS、HTTP、およびファイル)、チャネル、プロセッサ、キャッシュなどが挙げられるが、これらに限定されない。
図9のイベント処理アプリケーション020は、1つの入力ストリームを待ち受けて、選択されたイベントを1つの出力ストリームを介して出力する、として示されているが、これは、限定を意図したものではない。別の実施形態では、イベント処理アプリケーションは、1つ以上のイベントソースから受信した複数の入力ストリームを待ち受けて、監視されているストリームからイベントを選択し、選択されたイベントを1つ以上の出力イベントストリームを介して1つ以上のイベントシンクに出力するように構成されてもよい。同じクエリが2つ以上のイベントシンクに関連付けられ得、互いに異なる種類のイベントシンクと関連付けられ得る。
イベントストリームが本質的に無限であるため、イベントストリームを介して受信したデータの量は、一般に、大量である。したがって、一般に、クエリ目的のためにすべてのデータを格納またはアーカイブすることは実用的でなく、望ましくない。イベントストリームの処理は、EPS902によってイベントが受信されると、すべての受信イベントデータを格納せずに当該イベントをリアルタイムで処理することが必要である。したがって、EPS902は、イベントがEPS902によって受信されると受信したイベントのすべてを格納しなくても当該イベントの処理が実行されることを可能にする特殊な問い合わせメカニズムを提供する。
イベント駆動型アプリケーションは、ルール駆動型であり、ルールは、入力ストリームを処理するために使用される連続クエリの形で表現されてもよい。連続クエリは、受信したイベントについて実行する、どのイベントを注目イベントとして選択するか、およびどのイベントをクエリ処理の結果として出力するのかを含む処理を特定する命令(たとえば、ビジネスロジック)を含んでもよい。連続クエリは、データストアに永続化され、イベントの入力ストリームを処理およびイベントの出力ストリームを生成するために使用されてもよい。連続クエリは、通常、入力イベントストリームから注目イベントを発見および取り出すためのフィルタ処理機能およびアグリゲーション機能を実行する。その結果、出力イベントストリームに含まれるアウトバウンド・イベントの数は、一般に、イベントの選択元の入力イベントストリームに含まれるイベントの数よりも遙かに少ない。
有限なデータセットに対して1回実行されるSQLクエリとは異なり、特定のイベントストリームのためにアプリケーションがEPS902に登録している連続クエリは、イベントがそのイベントストリームにおいて受信されるたびに実行されてもよい。連続クエリ実行の一部として、EPS902は、受信したイベントを、連続クエリが指定した命令に基づいて評価し、1つ以上のイベントが注目イベントとして選択されるかどうかを判断し、連続クエリ実行の結果として出力する。
連続クエリは、互いに異なる言語を用いてプログラミングされてもよい。特定の実施形態では、連続クエリは、Oracle Corporationが提供し、Oracleの複合イベント処理(CEP:Complex Events Processing)製品の提供によって利用されるCQLを利用して構成されてもよい。OracleのCQLは、イベントストリームに対して実行され得るクエリ(CQLクエリと称する)をプログラミングするために使用され得る宣言型言語である。特定の実施形態では、CQLは、イベントデータをストリーム配信する処理をサポートする構成が追加されたSQLに基づいている。
一実施形態では、イベント処理アプリケーションは、次のコンポーネント型によって構成されてもよい。
(1)入出力ストリーム、ならびに、リレーションソースおよびリレーションシンクに直接インタフェース接続される1つ以上のアダプタ。アダプタは、入出力ストリームプロトコルを理解するように構成され、かつ、アプリケーションプロセッサが問い合わせし得る正規化された形式にイベントデータを変換する責任がある。アダプタは、正規化されたイベントデータをチャネルまたは出力ストリームおよびリレーションシンクに転送してもよい。イベントアダプタは、様々なデータソースおよびデータシンク用に規定されてもよい。
(2)イベント処理エンドポイントとして機能する1つ以上のチャネル。特に、チャネルは、イベント処理エージェントがイベントデータに対して作用できるようになるまで当該イベントデータを待ち行列に入れる責任がある。
(2)1つ以上のアプリケーションプロセッサ(または、イベント処理エージェント)は、チャネルからの正規化されたイベントデータを消費し、それをクエリを用いて処理して注目イベントを選択し、選択された注目イベントを出力チャネルに転送する(または、コピーする)ように構成される。
(4)1つ以上のBeanは、出力チャネルを待ち受けるように構成され、新しいイベントが出力チャネルに挿入されることによりトリガされる。いくつかの実施形態では、このユーザコードは、POJO(Plain-Old-Java-Object)である。ユーザアプリケーションは、JMS、Webサービス、およびファイルライターなど、外部サービスのセットを利用して、生成されたイベントを外部のイベントシンクに転送することができる。
(5)イベントBeanは、出力チャネルを待ち受けるために登録されてもよく、新しいイベントが出力チャネルに挿入されることによりトリガされる。いくつかの実施形態では、このユーザコードは、BeanをOracle CEPで管理できるように、Oracle CEPイベントBean APIを利用してもよい。
一実施形態では、イベントアダプタがイベントデータを入力チャネルに提供する。入力チャネルは、入力チャネルが提供するイベントに対して動作する1つ以上のCQLクエリに関連付けられたCQLプロセッサに接続される。CQLプロセッサは、クエリ結果が書き込まれる出力チャネルに接続される。
いくつかの実施形態では、イベント処理アプリケーションのためにアセンブリファイルが提供されてもよい。イベント処理アプリケーションには、イベント処理アプリケーションの様々なコンポーネント、コンポーネントがどのように互いに関連するか、アプリケーションが処理するイベント型が記述されている。イベントを選択するために連続クエリまたはビジネスロジックを指定するための別々のファイルが提供されてもよい。
図9に示すシステム900が、図9に示すコンポーネント以外のコンポーネントを有し得ることを理解されたい。さらに、図9に示す実施形態は、本開示の実施形態を組み込み得るシステムの一例に過ぎない。他のいくつかの実施形態では、システム900は、図9に示すコンポーネントよりも多いまたは少ないコンポーネントを有してもよく、2つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの構成または配置が異なっていてもよい。システム900は、サービスプロバイダコンピュータ、パーソナルコンピュータ、ポータブルデバイス(たとえば、携帯電話またはモバイルデバイス)、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他のデータ処理システムを含む、様々な種類のうちの1つであり得る。他のいくつかの実施形態では、システム900は、システム900の1つ以上のコンポーネントがクラウドにおける1つ以上のネットワーク間で分散している分散システムとして構成されてもよい。
図9に示すコンポーネントのうちの1つ以上は、ソフトウェアで、ハードウェアで、またはそれらの組合せで実現されてもよい。いくつかの実施形態では、ソフトウェアは、メモリ(たとえば、非一時的なコンピュータ読み取り可能な媒体)に、メモリ素子または他の物理メモリ上に格納されてもよく、1つ以上の処理装置(たとえば、1つ以上のプロセッサ、1つ以上のプロセッサコア、1つ以上のGPUなど)によって実行されてもよい。
図10は、いくつかの実施形態に係る、空間変化検出およびチェック・セット操作のための技術を説明する図である。個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明される場合もある。フローチャートは、逐次プロセスとして動作を示し得るが、動作の多くのは、平行して、または同時に実行してもよい。これに加えて、動作の順序は、並び替えられてもよい。プロセスは、その動作が完了したときに終了するが、図に含まれないステップをさらに有し得る。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに相当してもよい。プロセスが関数に相当する場合、その終了は、呼び出し関数またはメイン関数へのこの関数の戻りに相当してもよい。
図10に示す処理および/または動作は、1つ以上の処理装置(たとえば、プロセッサコア)によって実行されるソフトウェア(たとえば、コード、命令、プログラム)、ハードウェア、またはそれらの組合せで実現されてもよい。ソフトウェアは、(たとえば、メモリ素子上、非一時的なコンピュータ読み取り可能な記憶媒体上の)メモリに格納されてもよい。図10の特定の一連の処理は、限定を意図したものではない。また、他のステップシーケンスが別の実施形態に従って実行されてもよい。たとえば、別の実施形態では、概要を上述したステップを異なる順序で実行してもよい。また、図10に示す個々のステップは、個々のステップに応じて様々なシーケンスで行なわれ得る複数のサブステップを含んでもよい。さらに、特定のアプリケーションに応じてさらなるステップが追加または削除されてもよい。当業者は、多くの変形例、変更例、および代替例が分かるだろう。
図10は、本開示の実施形態が実施する空間変化検出および/またはチェック・セット操作を説明するフローチャート1000を示す図である。いくつかの実施形態では、フローチャート1000に示す処理は、図8および図9のイベント処理システムによって実施されてもよい。ステップ1005において、アプリケーションに関する第1の連続データストリームを受信する。ステップ1010において、第1の連続データストリームのジオメトリをリレーションに変換する。リレーションは、第1の連続データストリームのジオメトリの空間インデックスを含んでもよい。特定の実施形態では、範囲を有するフィルタが空間インデックスに適用され、第1の連続データストリームのジオメトリについてのフィルタ処理された結果が得られる。いくつかの実施形態では、この変換は、第1の連続データストリームのジオメトリに変更があるかどうかを判断し、第1の連続データストリームのジオメトリに変更があった場合、更新イベントを発行することを含む。更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される。
ステップ1015において、第1の連続データストリームにおいて、複数の移動オブジェクトを追跡する。この追跡は、少なくとも第1の移動オブジェクトの第2の移動オブジェクトとの関係を追跡するために空間演算を用いて実行されてもよい。ステップ1020において、複数の移動オブジェクトにおける少なくとも第1の移動オブジェクトと第2の移動オブジェクトとの関係を、第1の連続データストリームのジオメトリおよびリレーションのうちの少なくとも1つに基づいて判断またはチェックする。特定の実施形態では、第1の連続データストリームのジオメトリおよびリレーションは、追跡の前に結合演算を用いて結合されている。
必要に応じて、アプリケーションに関する第2の連続データストリームを受信し、複数の移動オブジェクトのうちの少なくとも1つの移動オブジェクトと第2の連続データストリームに含まれるオブジェクトとの関係を、少なくとも、リレーションおよび第2の連続データストリームのジオメトリに基づいて判断またはチェックする。いくつかの実施形態では、当該関係の判断は、少なくとも、第1の連続データストリームのジオメトリおよびリレーションに基づいて、少なくとも、複数の移動オブジェクトにおける第1の移動オブジェクトと第2の移動オブジェクトとの近接を判断することを含む。他の実施形態では、当該関係の判断は、少なくとも、リレーションおよび第2の連続データストリームのジオメトリに基づいて、少なくとも、複数の移動オブジェクトのうちの当該移動オブジェクトと第2の連続データストリームに含まれるオブジェクトとの近接を判断することを含む。当該近接の判断は、フィルタ処理された結果を用いて第1の移動オブジェクトと第2の移動オブジェクトとの距離を算出すること、または、複数の移動オブジェクトのうちの当該移動オブジェクトと第2の連続データストリームに含まれるオブジェクトとの距離を算出することを含んでもよい。
ステップ1025において、判断された関係に基づいてアクションを取る。様々な実施形態では、このアクションは、リレーション、第1の連続データストリームのジオメトリ、および第2の連続データストリームのジオメトリ、のうちの1つ以上に適用される操作を介して実行される。いくつかの実施形態では、このアクションは、少なくとも第1の移動オブジェクトと第2の移動オブジェクトとの近接が予め定められた閾値を超える場合にアラートを生成することを含む。他の実施形態では、このアクションは、関係が予め定められた基準を満たす場合、たとえば、予め定められた閾値を超える場合、移動オブジェクトのプロパティを設定することを含む。
例示的なシステム
図11~図13は、様々な実施形態に係る本開示の態様を実現するための例示的な環境の態様を説明する図である。図11は、本開示の実施形態を実現するための分散システム1100の簡略図である。図示した実施形態では、分散システム1100は、1つ以上のクライアントコンピューティングデバイス1102、1104、1106、および1108を備える。1つ以上のクライアントコンピューティングデバイス1102、1104、1106、および1108は、1つ以上のネットワーク(複数可)1110でウェブブラウザ、プロプライエタリ・クライアント(たとえば、Oracle Forms)などのクライアントアプリケーションを実行および操作するように構成される。サーバ1112は、ネットワーク1110を介して、リモートクライアントコンピューティングデバイス1102、1104、1106、および1108と通信可能に接続されてもよい。
様々な実施形態では、サーバ1112は、素性管理サービスを提供するサービスおよびアプリケーションなど、1つ以上のサービスまたはソフトウェア・アプリケーションを実行するようになされてもよい。また、特定の実施形態では、サーバ1112は、非仮想環境および仮想環境を含み得る他のサービスまたはソフトウェア・アプリケーションを提供してもよい。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス1102、1104、1106、および/または1108のユーザに対して、ウェブベースのサービスもしくはクラウドサービスとして提供されてもよく、または、SaaS(Software as a Service)モデル下で提供されてもよい。そして、クライアントコンピューティングデバイス1102、1104、1106、および/または1108を操作するユーザは、1つ以上のクライアントアプリケーションを利用して、サーバ1112とやり取りして、これらのコンポーネントが提供するサービスを利用できる。
図11に示す構成において、システム1100のソフトウェアコンポーネント1118、1120、および1122が、サーバ1112上に実装されたものとして示される。また、他の実施形態では、システム1100のコンポーネントのうちの1つ以上および/またはこれらのコンポーネントが提供するサービスのうちの1つ以上は、クライアントコンピューティングデバイス1102、1104、1106、および/または1108のうちの1つ以上によって実現されてもよい。次に、クライアントコンピューティングデバイスを操作しているユーザは、1つ以上のクライアントアプリケーションを利用して、これらのコンポーネントが提供するサービスを使用してもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。様々な異なるシステム構成が可能であり、これらは、分散型システム1100とは異なってもよいことを理解されたい。よって、図11に示す実施形態は、実施形態のシステムを実現するための分散システムの一例であり、限定を意図したものではない。
クライアントコンピューティングデバイス1102、1104、1106、および/または1108は、様々な種類のコンピュータシステムを含んでもよい。たとえば、クライアントデバイスは、Microsoft Windows Mobile(登録商標)などのソフトウェアおよび/またはiOS、Windows(登録商標)Phone、Android、BlackBerry 10、Palm OSなどのいろいろなモバイルオペレーティングシステムを実行する手のひらサイズのポータブルデバイス(たとえば、iPhone(登録商標)、携帯電話、iPad(登録商標)、コンピューティングタブレット、携帯情報端末(PDA))またはウェアラブルデバイス(たとえば、Google Glass(登録商標)ヘッドマウントディスプレイ)を含んでもよい。デバイスは、様々なインターネット関連アプリ、電子メール、ショートメッセージサービス(SMS)アプリケーションなど、様々なアプリケーションをサポートしてもよく、様々な他の通信プロトコルを使用してもよい。また、クライアントコンピューティングデバイスは、一例として、様々なバージョンのMicrosoft Windows(登録商標)、Apple Macintosh(登録商標)、および/またはLinux(登録商標)オペレーティングシステムを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む、汎用パーソナルコンピュータを含んでもよい。クライアントコンピューティングデバイスは、これらに限定されないが、たとえば、Google Chrome OSなど、いろいろなGNU/Linux(登録商標)オペレーティングシステムを含む、流通している各種のUNIX(登録商標)またはUNIX(登録商標)に似たオペレーティングシステムを実行するワークステーションコンピュータであり得る。また、クライアントコンピューティングデバイスは、シンクライアントコンピュータ、インターネット対応のゲーミングシステム(たとえば、Kinect(登録商標)ジェスチャ入力装置付きまたは無しのMicrosoft Xboxのゲーミングコンソール)、および/またはパーソナルメッセージングデバイスなど、ネットワーク(複数可)1110で通信可能な電子機器を含んでもよい。
図11の分散システム1100は、4つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサ付きデバイスなど、他のデバイスがサーバ1112とやり取りを行ってもよい。
分散システム1100におけるネットワーク(複数可)1110は、これらに限定されないが、TCP/IP(Transmission Control Protocol/Internet Protocol)、SNA(Systems Network Architecture)、IPX(Internet packet exchange)、AppleTalkなどを含む、各種の利用可能なプロトコルを使用したデータ通信をサポートできる、当業者にとってなじみの任意の種類のネットワークであってもよい。単に一例として、ネットワーク(複数可)1110は、LAN(Local Area Network)、Ethernet(登録商標)ベースのネットワーク、トークンリング、ワイドエリアネットワーク、インターネット、仮想ネットワーク、VPN(Virtual Private Network)、イントラネット、エクストラネット、PSTN(Public Switched Telephone Network)、赤外線ネットワーク、ワイヤレスネットワーク(たとえば、IEEE(Institute Of Electrical And Electronics)1002.11スイートのプロトコル、Bluetooth(登録商標)、および/またはその他のワイヤレスプロトコルのうちのいずれかの下で動作するネットワーク)、および/またはこれらの任意の組合せならびに/もしくは他のネットワークで有り得る。
サーバ1112は、1つ以上の汎用コンピュータ、専用サーバコンピュータ(一例として、PC(Personal Computer)サーバ、UNIX(登録商標)サーバ、ミッドレンジ・サーバ、メインフレーム・コンピュータ、ラックマウント式のサーバなどを含む)、サーバファーム、サーバクラスタ、またはその他の適切な配置および/または組合せから構成されてもよい。サーバ1112は、仮想オペレーティングシステムを実行している1つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理記憶装置の1つ以上のフレキシブルプールを仮想化して、サーバ用の仮想記憶装置を維持することができる。仮想ネットワークは、ソフトウェア定義ネットワーキングを使用して、サーバ1112によって制御することができる。様々な実施形態において、サーバ1112は、上記の開示において説明した1つ以上のサービスまたはソフトウェア・アプリケーションを実行するようになされてもよい。たとえば、サーバ1112は、本開示の実施形態に係る上述した処理を実行するためのサーバに相当してもよい。
サーバ1112は、上述のオペレーティングシステムのいずれかおよび市販されているサーバオペレーティングシステムのうちのいずれかを含むオペレーティングシステムを実行してもよい。また、サーバ1112は、HTTP(Hypertext Transport Protocol)サーバ、FTP(File Transfer Protocol)サーバ、CGI(Common Gateway Interface)サーバ、JAVA(登録商標)サーバ、データベースサーバなどを含む、各種の追加のサーバアプリケーションおよび/またはミッドティア・アプリケーションを実行してもよい。例示的なデータベースサーバとして、Oracle、Microsoft、Sybase、IBM(International Business Machines)などから市販されているデータベースサーバが挙げられるが、これらに限定されない。
いくつかの実装形態では、サーバ1112は、クライアントコンピューティングデバイス1102、1104、1106、および1108のユーザから受信したデータフィードおよび/またはイベント更新を分析および1つにまとめるための1つ以上のアプリケーションを含んでもよい。例として、データフィードおよび/またはイベント更新は、これらに限定されないが、1つ以上のサードパーティ情報ソースおよび連続したデータストリームから受信するTwitter(登録商標)フィード、Facebook(登録商標)更新またはリアルタイム更新を含んでもよく、当該1つ以上のサードパーティ情報ソースおよび連続したデータストリームは、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール(たとえば、ネットワーク監視およびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通量監視などに関するリアルタイムイベントを含み得る。また、サーバ1112は、クライアントコンピューティングデバイス1102、1104、1106、および1108の1つ以上の表示装置を介してデータフィードおよび/またはリアルタイムイベントを表示するための1つ以上のアプリケーションを含んでもよい。
また、分散システム1100は、1つ以上のデータベース1114および1116を含んでもよい。これらのデータベースは、ユーザ識別情報、および本開示の実施形態が用いるその他の情報などの情報を格納するためのメカニズムを提供してもよい。データベース1114および1116は、いろいろな場所に存在してもよい。一例として、データベース1114および1116のうちの1つ以上は、サーバ1112にローカルな(および/または存在する)非一時的な記憶媒体上に存在してもよい。これに代えて、データベース1114および1116は、サーバ1112から遠隔の場所に存在し、ネットワークベースまたは専用の接続を通してサーバ1112と通信していてもよい。一組の実施形態では、データベース1114および1116は、SAN(Storage-Area Network)に存在してもよい。同様に、サーバ1112に起因する機能を実行するための必要なファイルは、いずれも、サーバ1112上のローカルな場所および/またはサーバ1112から遠隔の場所に、適宜、格納されてもよい。一組の実施形態では、データベース1114および1116は、SQLフォーマットのコマンドに応答してデータ格納、更新、および取り出すようになされたOracleが提供するデータベースなど、リレーショナルデータベースを含んでもよい。
図12は、本開示の実施形態を実現するために使用され得る例示的なコンピュータシステム1200を示す図である。いくつかの実施形態では、コンピュータシステム1200を使用して、上述の様々なサーバおよびコンピュータシステムのうちのいずれかを実現してもよい。図12に示すように、コンピュータシステム1200は、バス・サブシステム1202を介していくつかの周辺サブシステムと通信する処理サブシステム1204を含む、様々なサブシステムを備える。これらの周辺サブシステムは、処理高速化装置1206と、I/Oサブシステム1208と、ストレージサブシステム1218と、通信サブシステム1224とを備えてもよい。ストレージサブシステム1218は、有形のコンピュータ読み取り可能な記憶媒体1222と、システムメモリ1210とを備えてもよい。
バス・サブシステム1202は、コンピュータシステム1200の様々なコンポーネントおよびサブシステムを互いに意図した通りに通信させるための機構を提供する。バス・サブシステム1202は、1つのバスとして図示されているが、バス・サブシステムの別の実施形態は、複数のバスを利用してもよい。バス・サブシステム1202は、メモリコントローラのメモリバス、周辺バス、および各種のバスアーキテクチャを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、ISA(Industry Standard Architecture)バス、MCA(Micro Channel Architecture)バス、EISA(Enhanced ISA)バス、VESA(Video Electronics Standards Association)ローカルバス、およびPCI(Peripheral Component Interconnect)バスを含んでもよく、これらは、IEEE P1386.1標準規格に準拠して製造されるMezzanineバスなどとして実現され得る。
処理サブシステム1204は、コンピュータシステム1200の動作を制御し、1つ以上の処理装置1232、1234などを備えてもよい。処理装置は、シングルコア・プロセッサまたはマルチコア・プロセッサを含む1つ以上のプロセッサ、プロセッサの1つ以上のコア、またはそれらの組合せを含んでもよい。いくつかの実施形態では、処理サブシステム1204は、グラフィックスプロセッサ、デジタル・シグナル・プロセッサ(DSP)など、1つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム1204の処理装置の一部またはすべては、特定用途向け集積回路(ASIC)、またはフィールド・プログラマブル・ゲート・アレイ(FPGA)など、カスタム回路を使用して実現され得る。
いくつかの実施形態では、処理サブシステム1204に含まれる処理装置は、システムメモリ1210に、または、コンピュータ読み取り可能な記憶媒体1222上に格納された命令を実行できる。様々な実施形態では、処理装置は、いろいろなプログラムまたはコード命令を実行し、複数の同時に実行しているプログラムまたはプロセスを維持できる。いつでも、実行されるプログラムコードの一部またはすべては、システムメモリ1210に、および/または、1つ以上の記憶装置上を潜在的に含む、コンピュータ読み取り可能な記憶媒体1210上に存在し得る。適したプログラミングを通して処理サブシステム1204は、使用パターンに応じてドキュメント(たとえば、ウェブページ)を動的に変更するための上述の様々な機能を提供できる。
特定の実施形態では、カスタマイズされた処理を実行するための、または、コンピュータシステム1200によって実行される全体的な処理が高速化するように、処理サブシステム1204によって実行される処理のうちのいくつかの負荷を軽減させるための処理高速化装置1206が提供されてもよい。
I/Oサブシステム1208は、コンピュータシステム1200に情報を入力するためのデバイスおよびメカニズム、ならびに/またはコンピュータシステム1200から、もしくはコンピュータシステム1200を介して情報を出力するためのデバイスおよびメカニズムを含んでもよい。一般に、用語「入力装置」の使用は、コンピュータシステム1200に情報を入力するためのあらゆる種類のデバイスおよび機構を含む意図がある。ユーザインタフェース入力装置は、たとえば、キーボード、マウスもしくはトラックボールなどのポインティングデバイス、タッチパッドもしくはディスプレイに組み込まれたタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、ボイスコマンド認識システムを有する音声入力装置、マイクロホン、および他の種類の入力装置を含んでもよい。また、ユーザインタフェース入力装置は、ユーザが入力装置を制御するおよび入力装置とやり取りすることを可能にするMicrosoft Kinect(登録商標)モーションセンサなどの動き検知デバイスおよび/またはジェスチャ認識デバイス、Microsoft Xbox(登録商標)360ゲームコントローラ、ジェスチャコマンドおよび音声コマンドを使用した入力を受信するためのインタフェースを提供するデバイスを含んでもよい。ユーザインタフェース入力装置は、ユーザからの目のアクティビティ(たとえば、写真を撮影しながらおよび/またはメニュー選択を行いながら「まばたきすること」)を検出し、アイ・ジェスチャを入力装置(たとえば、Google Glass(登録商標))への入力として変形させるGoogle Glass(登録商標)まばたき検出装置などのアイ・ジェスチャ認識デバイスを含んでもよい。これに加えて、ユーザインタフェース入力装置は、ユーザが、ボイスコマンドを通して、音声認識システム(たとえば、Siri(登録商標)ナビゲータ)とやり取りすることを可能にする音声認識検知デバイスを含んでもよい。
ユーザインタフェース入力装置の他の例に、3次元(3D)マウス、ジョイスティックもしくはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレーヤ、ウェブカム、イメージスキャナ、指紋スキャナ、バーコードリーダ3Dスキャナ、3Dプリンタ、レーザー測距器、および視線追跡装置などのオーディオ/ビジュアル装置などが挙げられるが、これらに限定されない。これに加えて、ユーザインタフェース入力装置は、たとえば、コンピュータ断層撮影法、磁気共鳴画像、ポジトロン・エミッション・トモグラフィー、超音波検査デバイスなど、医用画像入力装置を含んでもよい。また、ユーザインタフェース入力装置は、たとえば、MIDIキーボード、デジタル楽器などの音声入力装置を含んでもよい。
ユーザインタフェース出力装置は、表示サブシステム、インジケーターライト、または音声出力装置などの非ビジュアル装置を含んでもよい。表示サブシステムは、ブラウン管(CRT)、液晶ディスプレイ(LCD)またはプラズマディスプレイを使用するものなどのフラットパネル表示装置、投影装置、タッチスクリーンなどであってもよい。一般に、用語「出力装置」の使用は、コンピュータシステム1200からユーザまたは他のコンピュータに情報を出力するためのあらゆる種類のデバイスおよび機構を含むよう意図される。たとえば、ユーザインタフェース出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、作図装置、音声出力装置、およびモデムなど、視覚的に文字、図形、および音声/映像情報を伝えるいろいろな表示装置を含み得るが、これらに限定されない。
ストレージサブシステム1218は、コンピュータシステム1200が使用する情報を格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム1218は、いくつかの実施形態の機能を提供する基本プログラミング構造およびデータ構造を格納するための有形の非一時的なコンピュータ読み取り可能な記憶媒体を提供する。処理サブシステム1204によって実行されると上述の機能を提供するソフトウェア(プログラム、コードモジュール、命令)がストレージサブシステム1218に格納されてもよい。ソフトウェアは、処理サブシステム1204の1つ以上の処理装置によって実行されてもよい。また、ストレージサブシステム1218は、本開示に応じて使用されるデータを格納するためのリポジトリを提供してもよい。
ストレージサブシステム1218は、揮発性および不揮発性メモリ素子を含む、1つ以上の非一時的なメモリ素子を含んでもよい。図12に示すように、ストレージサブシステム1218は、システムメモリ1210と、コンピュータ読み取り可能な記憶媒体1222とを備える。システムメモリ1210は、プログラムを実行中に命令およびデータを格納するための揮発性のメインRAM(Random Access Memory)、および、固定の命令が格納される不揮発性ROM(Read Only Memory)またはフラッシュメモリを含む、いくつかのメモリを含んでもよい。いくつかの実装形態では、起動中などで、コンピュータシステム1200内の要素間で情報を転送することを助ける基本ルーチンを含むBIOS(Basic Input/Output System)は、通常、ROMに格納されてもよい。RAMは、通常、処理サブシステム1204が現在操作および実行していているデータおよび/またはプログラムモジュールを含む。いくつかの実装形態では、システムメモリ1210は、SRAM(Static Random Access Memory)またはDRAM(Dynamic Random Access Memory)など、複数の異なる種類のメモリを含んでもよい。
一例として、限定ではないが、図12に示すように、システムメモリ1210は、クライアントアプリケーション、ウェブブラウザ、ミッドティア・アプリケーション、リレーショナルデータベース管理システム(RDBMS)などのアプリケーションプログラム1212と、プログラムデータ1214と、オペレーティングシステム1216とを含んでもよい。一例として、オペレーティングシステム1216は、様々なバージョンのMicrosoft Windows(登録商標)、Apple Macintosh(登録商標)、および/もしくはLinuxオペレーティングシステム、いろいろな流通しているUNIX(登録商標)もしくはUNIXに似たオペレーティングシステム(いろいろなGNU/Linuxオペレーティングシステム、Google Chrome(登録商標)OSなどを含むが、これらに限定されない)、ならびに/またはiOS、Windows(登録商標)Phone、Android(登録商標)OS、BlackBerry(登録商標)10OS、およびPalm(登録商標)OSオペレーティングシステムなど、モバイルオペレーティングシステムを含んでもよい。
コンピュータ読み取り可能な記憶媒体1222は、いくつかの実施形態の機能を提供するプログラミング構造およびデータ構造を格納してもよい。処理サブシステム1204によって実行されると、プロセッサに上述の機能を提供するソフトウェア(プログラム、コードモジュール、命令)がストレージサブシステム1218に格納されてもよい。一例として、コンピュータ読み取り可能な記憶媒体1222は、ハードディスクドライブなどの不揮発性メモリ、磁気ディスクドライブ、CD ROM、DVD、Blu-Ray(登録商標)ディスクなどの光ディスクドライブまたは他の光学媒体を含んでもよい。コンピュータ読み取り可能な記憶媒体1222は、Zip(登録商標)ドライブ、フラッシュメモリーカード、USB(Universal Serial Bus)フラッシュドライブ、SD(Secure Digital)カード、DVDディスク、デジタルビデオテープなどを含んでもよいが、これらに限定されない。コンピュータ読み取り可能な記憶媒体1222は、フラッシュメモリベースのSSD、エンタープライズフラッシュドライブ、ソリッドステートROMなど、不揮発性メモリに基づくSSD(Solid-State Drives)、ソリッドステートRAM、動的RAM、静的RAMなど、揮発性メモリに基づくSSD、DRAMベースのSSD、磁気抵抗RAM(MRAM)SSD、およびDRAMのSSDとフラッシュメモリベースのSSDとの組合せを使用するハイブリッドSSDを含んでもよい。コンピュータ読み取り可能な媒体1222は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびコンピュータシステム1200用の他のデータのストレージを提供してもよい。
特定の実施形態では、ストレージサブシステム1200は、コンピュータ読み取り可能な記憶媒体1222にさらに接続され得るコンピュータ読み取り可能な記憶媒体リーダ1220を含んでもよい。システムメモリ1210と合わせて、必要に応じてシステムメモリ1210と組み合わせて、コンピュータ読み取り可能な記憶媒体1222は、遠隔の記憶装置、ローカル記憶装置、固定記憶装置、および/またはリム―バブル記憶装置、ならびにコンピュータ読み取り可能な情報を格納するための記憶媒体を包括的に表してもよい。
特定の実施形態では、コンピュータシステム1200は、1つ以上の仮想マシンを実行するためのサポートを提供してもよい。コンピュータシステム1200は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行してもよい。各仮想マシンには、メモリ、コンピュータ(たとえば、プロセッサ、コア)、I/O、およびネットワーキング・リソースが割り当てられてもよい。各仮想マシンは、通常、それ自体のオペレーティングシステムを実行する。このオペレーティングシステムは、コンピュータシステム1200が実行する他の仮想マシンによって実行されるオペレーティングシステムと同じまたは異なってもよい。したがって、複数のオペレーティングシステムは、コンピュータシステム1200によって同時に実行される可能性があってもよい。各仮想マシンは、一般に、その他の仮想マシンとは別に実行される。
通信サブシステム1224は、他のコンピュータシステムおよびネットワークへのインタフェースを提供する。通信サブシステム1224は、コンピュータシステム1200からデータを受信し、コンピュータシステム1200から他のシステムにデータを送信するためのインタフェースとして機能する。たとえば、通信サブシステム1224は、1つ以上のクライアントコンピューティングデバイスと情報を送受信するためのクライアントコンピューティングデバイスへの通信チャネルを、インターネットを介してコンピュータシステム1200が確立することを可能にしてもよい。これに加えて、通信サブシステム1224を用いて、ログインに成功したという通知、または特権アカウントの管理者から要求側ユーザに対してパスワードを再入力するよう求める通知を伝達してもよい。
通信サブシステム1224は、有線通信プロトコルおよび/またはワイヤレス通信プロトコルの両方をサポートしてもよい。たとえば、特定の実施形態では、通信サブシステム1224、ワイヤレス音声ネットワークもしくは/またはデータネットワークにアクセスするためのRF(Radio Frequency)送信コンポーネント(たとえば、携帯電話技術、3G、4G、もしくはEDGE(Enhanced Data Rates For Global Evolution)などの次世代データネットワークテクノロジー、WiFi(IEEE 802.11ファミリー標準規格)、他の移動オブジェクト通信技術、またはそれらの任意の組合せを使用する)、GPS(Global Positioning System)受信コンポーネント、および/または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム1224は、ワイヤレスインタフェースに加えて、またはワイヤレスインタフェースの代わりに、有線ネットワーク接続性(たとえば、Ethernet)を提供できる。
通信サブシステム1224は、様々な形でデータを受送信できる。たとえば、いくつかの実施形態では、通信サブシステム1224は、入力通信文を、構造化および/または非構造化データフィード1226、イベントストリーム1228、イベント更新1230などの形で受信してもよい。たとえば、通信サブシステム1224は、Twitter(登録商標)フィード、Facebook(登録商標)の更新、RSS(Rich Site Summary)フィードなどのwebフィード、および/または1つ以上のサードパーティ情報ソースからのリアルタイム更新など、ソーシャルメディアネットワークおよび/または他のコミュニケーションサービスのユーザから、データフィード1226をリアルタイムで受信する(または送る)ように構成されてもよい。
特定の実施形態では、通信サブシステム1224は、連続したデータストリームの形でデータを受信するように構成されてもよく、連続したデータストリームは、本質的にはっきりとした終端がない、連続または無限の、リアルタイムイベントおよび/またはイベント更新1230のイベントストリーム1228を含んでもよい。連続データを生成するアプリケーションとして、たとえば、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール(たとえば、ネットワーク監視およびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通量監視などが挙げられてもよい。
また、通信サブシステム1224コンピュータシステム1200に接続された1つ以上のストリーミングデータソースコンピュータと通信中であり得る1つ以上のデータベースに、構造化および/または非構造化データフィード1226、イベントストリーム1228、イベント更新1230などを出力するように構成されてもよい。
コンピュータシステム1200は、手のひらサイズのポータブルデバイス(たとえば、iPhone(登録商標)携帯電話、iPad(登録商標)コンピューティングタブレット、PDA)、ウェアラブルデバイス(たとえば、Google Glass(登録商標)ヘッドマウントディスプレイ)、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、様々な種類のうちの1つであり得る。
変わり続けるというコンピュータおよびネットワークの性質により、図12に示すコンピュータシステム1200の説明は、具体例にすぎない。図12に示すシステムよりも多いまたは少ないコンポーネントを有する多くの他の構成が可能である。本明細書に記載の開示および教示に基づいて、当業者は、様々な実施形態を実現するための他のやり方および/または方法が分かるだろう。
図面のいくつかに示すシステムは、様々な構成で提供されてもよい。いくつかの実施形態では、これらのシステムは、システムの1つ以上の構成要素が1つ以上のクラウドインフラストラクチャシステムにおける1つ以上のネットワーク間で分散される分散システムとして構成されてもよい。
クラウドインフラストラクチャシステムは、1つ以上のサーバコンピューティングデバイス、ネットワーク機器、および/または記憶装置の集まりである。これらのリソースは、クラウドサービスプロバイダによって分けられて、その顧客に何らかの方法で割り当てられてもよい。たとえば、カリフォルニア州レッドウッドショアーズのオラクル社などのクラウドサービスプロバイダは、SaaS(Software as a Service)カテゴリ下で提供される1つ以上のサービス、PaaS(Platform as a Service)カテゴリ下で提供されるサービス、IaaS(Infrastructure as a Service)カテゴリ下で提供されるサービス、または、混合サービスを含む他のカテゴリのサービスを様々な種類のクラウドサービスを提供してもよいが、これらに限定されない。SaaSサービスとして、Oracle Fusionアプリケーションなどのオンデマンドアプリケーション一式を構築および届ける機能が挙げられるが、これらに限定されない。SaaSサービスは、クラウドインフラストラクチャシステム上で実行中のアプリケーションを、顧客がアプリケーション用のソフトウェアを購入する必要なしに利用することを可能にする。PaaSサービスとして、JCS(Oracle Java Cloud Service)、DBCS(Oracle Database Cloud Service)など、組織(Oracleなど)が既存のアプリケーションを共有の共通アーキテクチャ上に1つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る能力などが挙げられるが、これらに限定されない。IaaSサービスは、通常、SaaSプラットフォームおよびPaaSプラットフォームが提供するサービスを利用している顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースなど、礎となるコンピューティングリソースの管理および制御を容易にする。
図13は、本開示の実施形態に係る、実施形態のシステムの1つ以上の構成要素が提供するサービスがクラウドサービスとして提供され得るシステム環境1300の1つ以上の構成要素の簡略ブロック図である。 図示した実施形態では、システム環境1300は、1つ以上のクライアントコンピューティングデバイス1304、1306、および1308を含む。1つ以上のクライアントコンピューティングデバイス1304、1306、および1308は、ユーザによって、クラウドサービスを提供するクラウドインフラストラクチャシステム1302と対話するために使用されもよい。クライアントコンピューティングデバイスは、ウェブブラウザ、プロプライエタリ・クライアントアプリケーション(たとえば、Oracle Forms)、または他のアプリケーションなど、クライアントアプリケーションを操作するように構成されてもよい。クライアントアプリケーションは、クライアントコンピューティングデバイスのユーザによって、クラウドインフラストラクチャシステム1302と対話を行ってクラウドインフラストラクチャシステム1302が提供するサービスを利用するために使用され得る。
図に示したクラウドインフラストラクチャシステム1302が、図示された構成要素以外の構成要素を有し得ることを理解されたい。さらに、図に示す実施形態は、本開示の実施形態を組み込み得るクラウドインフラストラクチャシステムの一例に過ぎない。他のいくつかの実施形態では、クラウドインフラストラクチャシステム1302は、図に示す構成要素よりも多いまたは少ない数の構成要素を有してもよく、2つ以上の構成要素を組み合わせてもよく、または構成要素の構成もしくは配置が異なっていてもよい。
クライアントコンピューティングデバイス1304、1306、および1308は、1102、1104、1106、および1108に関して上述したクライアントコンピューティングデバイスと同様のデバイスであってもよい。
例示的なシステム環境1300は、3つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサ付きデバイスなど、他のデバイスがクラウドインフラストラクチャシステム1302と対話を行ってもよい。
ネットワーク(複数可)1310は、クライアント1304、1306、および1308とクラウドインフラストラクチャシステム1302との間のデータの通信およびやり取りを容易にしてもよい。各ネットワークは、ネットワーク(複数可)1610に関して上述したプロトコルを含む各種市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者にとってなじみのある任意の種類のネットワークであってもよい。
クラウドインフラストラクチャシステム1302は、サーバ1112に関して上述したコンピュータおよびサーバを含み得る1台以上のコンピュータおよび/またはサーバから構成されてもよい。
特定の実施形態では、クラウドインフラストラクチャシステムが提供するサービスは、オンラインのデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートドキュメント連携サービス、データベース処理、管理されたテクニカルサポートサービスなど、クラウドインフラストラクチャシステムのユーザが要求すれば利用可能になるサービスのホストを含んでもよい。クラウドインフラストラクチャシステムが提供するサービスは、動的にスケール変更してそのユーザのニーズを満たすことができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものは、本明細書において、「サービスインスタンス」と称される。一般に、インターネットなどの通信ネットワークを介してユーザが利用できるようになる、クラウドサービスプロバイダのシステムからのいずれのサービスも、「クラウドサービス」と称される。通常、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客所有のオンプレミス・サーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介して、要求に基づいてアプリケーションを注文および使用すればよい。
いくつかの例において、コンピュータネットワークのクラウドインフラストラクチャにおけるサービスは、ストレージ、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェア・アプリケーションへの保護されたコンピュータネットワークアクセス、もしくはクラウドベンダーがユーザに提供するその他のサービス、または、当技術分野で周知の上記以外のその他のサービスを含んでもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへのパスワード保護されたアクセスを含み得る。別の例として、サービスは、ネットワークで結ばれた開発者が私的使用するための、ウェブサービスベースのホストされたリレーショナルデータベースおよびスクリプト言語のミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上にホストされた電子メールソフトウェア・アプリケーションへのアクセスを含み得る。
特定の実施形態では、クラウドインフラストラクチャシステム1302は、顧客にセルフサービスでサブスクリプション方式で伸縮自在にスケーラブルで信頼性があり、かつ高い可用性を有するセキュアな方法で届けられるアプリケーション一式、ミドルウェア、およびデータベースサービス提供物を含んでもよい。このようなクラウドインフラストラクチャシステムの例が、本願の譲受人が提供するオラクルパブリッククラウド(Oracle Public Cloud)である。
様々な実施形態では、クラウドインフラストラクチャシステム1302は、クラウドインフラストラクチャシステム1302が提供するサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理、および追跡するようになされてもよい。クラウドインフラストラクチャシステム1302は、それぞれ異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、パブリッククラウドモデル下で提供されてもよい。パブリッククラウドモデルでは、クラウドインフラストラクチャシステム1302は、(たとえば、オラクル所有の)クラウドサービスを提供する組織が所有しており、一般大衆またはそれぞれ異なる産業企業でサービスが使用できるようになる。別の例として、サービスは、クラウドインフラストラクチャシステム1302が1つの組織のためだけに動かされるプライベートクラウドモデル下で提供されてもよく、組織内の1つ以上のエンティティのためのサービスを提供してもよい。また、クラウドサービスは、コミュニティクラウドモデル下で提供されてもよい。コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム1302およびクラウドインフラストラクチャシステム1302が提供するサービスが、関連コミュニティ内のいくつかの組織によって共有される。クラウドサービスは、ハイブリッドクラウドモデル下で提供されてもよい。ハイブリッドクラウドモデルとは、2つ以上の異なるモデルの組合せである。
いくつかの実施形態では、クラウドインフラストラクチャシステム1302が提供するサービスは、SaaS(Software as a Service)カテゴリ、PaaS(Platform as a Service)カテゴリ、IaaS(Infrastructure as a Service)カテゴリ、または混合サービスを含む、他のカテゴリ下で提供される1つ以上のサービスを含んでもよい。顧客は、サブスクリプションのオーダーによって、クラウドインフラストラクチャシステム1302が提供する1つ以上のサービスをオーダーしてもよい。次に、クラウドインフラストラクチャシステム1302は、処理を実行して、顧客のサブスクリプションのオーダーにあるサービスを提供する。
いくつかの実施形態ではクラウドインフラストラクチャシステム1302が提供するサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含んでもよいが、これらに限定されない。いくつかの例において、アプリケーションサービスは、SaaSサービスを介してクラウドインフラストラクチャシステムによって提供されてもよい。SaaSプラットフォームは、SaaSカテゴリに該当するクラウドサービスを提供するように構成されてもよい。たとえば、SaaSプラットフォームは、オンデマンドアプリケーション一式を構築し、統合開発/デプロイメントプラットフォームに届けるための機能を提供してもよい。SaaSプラットフォームは、SaaSサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御してもよい。SaaSプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、アプリケーションサービスを、別のライセンスおよびサポートを購入する必要なしに、入手できる。様々な異なるSaaSサービスが提供されてもよい。例として、大きな組織のための販売実績管理、エンタープライズ統合、およびビジネス上の柔軟性に対するソリューションを提供するサービスなどが挙げられるが、これに限定されない。
いくつかの実施形態では、プラットフォームサービスは、PaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。PaaSプラットフォームは、PaaSカテゴリに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスとして、組織(Oracleなど)が既存のアプリケーションを共有の共通アーキテクチャ上に1つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る能力などが挙げられるが、これらに限定されない。PaaSプラットフォームは、PaaSサービスを提供するための、基礎となるソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、PaaS クラウドインフラストラクチャシステムが提供するサービスを、ライセンスおよびサポートを別に購入する必要なしに、取得できる。プラットフォームサービスとして、JCS(Oracle Java Cloud Service)、DBCS(Oracle Database Cloud Service)など、およびその他が挙げられるが、これらに限定されない。
PaaSプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、また、デブロイされたサービスを管理することができる。いくつかの実施形態において、クラウドインフラストラクチャシステムが提供するプラットフォームサービスは、データベース・クラウドサービス、ミドルウェアクラウドサービス(たとえば、Oracle Fusion Middlewareサービス)、およびJavaクラウドサービスを含んでもよい。一実施形態では、データベース・クラウドサービスは、共有サービスデプロイメントモデルをサポートしてもよい。共有サービスデプロイメントモデルは、組織が、データベースリソースをプールし、データベース・クラウドの形のサービスとしてデータベースを顧客に提供することを可能にする。ミドルウェアクラウドサービスは、顧客が様々な業務アプリケーションを開発およびデプロイするためのプラットフォームを提供してもよく、Javaクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてJavaアプリケーションをデプロイするためのプラットフォームを提供してもよい。
クラウドインフラストラクチャシステムにおいて、IaaSプラットフォームによって、様々な異なるインフラストラクチャサービスが提供されてもよい。インフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームが提供するサービスを利用している顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースなど、基礎となるコンピューティングリソースの管理および制御を容易にする。
特定の実施形態では、クラウドインフラストラクチャシステム1302は、クラウドインフラストラクチャシステムの顧客に様々なサービスを提供するために使用されるリソースを提供するためのインフラストラクチャ・リソース1330を含んでもよい。一実施形態では、インフラストラクチャ・リソース1330は、PaaSプラットフォームおよびSaaSプラットフォームが提供するサービスを実行するための、サーバなどのハードウェアと、ストレージと、ネットワーキング・リソースとの予め統合された最適な組合せ、および他のリソースを含んでもよい。
いくつかの実施形態では、クラウドインフラストラクチャシステム1302におけるリソースは、複数のユーザによって共有され、要求に応じて動的に再割り当てされてもよい。これに加えて、リソースは、それぞれ異なるタイムゾーンのユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム1330は、第1のタイムゾーンにいる第1セットのユーザが、指定された時間数、クラウドインフラストラクチャシステムのリソースを利用することを可能にした後、同じリソースを、異なるタイムゾーンに位置する別のセットのユーザへ再割り当てすることを可能にし、リソースの利用を最大限に活用することができる。
特定の実施形態では、クラウドインフラストラクチャシステム1302のそれぞれ異なるコンポーネントまたはモジュールによって、かつ、クラウドインフラストラクチャシステム1302が提供するサービスによって共有される、いくつかの内部共有サービス1332が提供されてもよい。これらの内部共有サービスは、セキュリティ/素性サービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャン/ホワイトリストサービス、可用性の高いバックアップ・リカバリサービス、クラウドサポート、Eメールサービス、通知サービス、ファイル転送サービスなどを可能にするためのサービスを含み得るが、これらに限定されない。
特定の実施形態では、クラウドインフラストラクチャシステム1302は、クラウドインフラストラクチャシステムにおけるクラウドサービス(たとえば、SaaSサービス、Paaサービス、およびIaaSサービス)の包括的な管理を提供してもよい。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム1302などが受信した顧客のサブスクリプションをプロビジョニング、管理、および追跡するための機能を含んでもよい。
一実施形態では、図に示すように、クラウド管理機能は、オーダー管理モジュール1320、オーダーオーケストレーションモジュール1322、オーダープロビジョニングモジュール1324、オーダー管理/監視モジュール1326、および素性管理モジュール1328など、1つ以上のモジュールによって提供されてもよい。これらのモジュールは、1つ以上のコンピュータおよび/またはサーバを含んでもよく、または、これらを使用して提供されてもよい。1つ以上のコンピュータおよび/またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および/または組合せであり得る。
例示的な動作1334において、クライアントデバイス1304、1306 または1308などのクライアントデバイスを使用している顧客は、クラウドインフラストラクチャシステム1302が提供する1つ以上のサービスを要求し、クラウドインフラストラクチャシステム1302が提供する1つ以上のサービスのサブスクリプションのオーダーをすることによってクラウドインフラストラクチャシステム1302とやり取りしてもよい。特定の実施形態では、顧客は、クラウドUI1312、クラウドUI1314 および/またはクラウドUI1316などのクラウドユーザインタフェース(UI:User Interface)にアクセスし、これらのUIを介してサブスクリプションのオーダーを行ってもよい。顧客がオーダーをすることに応答してクラウドインフラストラクチャシステム1302が受信したオーダー情報は、この顧客を特定する情報、および、顧客がサブスクリプションをする予定である、クラウドインフラストラクチャシステム1302が提供する1つ以上のサービスを含んでもよい。
顧客によって注文がされた後、クラウドUI1312、1314、および/または1316を介してオーダー情報が受け付けられる。
動作1336において、この注文は、オーダーデータベース1318に格納される。オーダーデータベース1318は、クラウドインフラストラクチャシステム1318によって操作され、かつ、他のシステム要素と共に操作されるいくつかのデータベースのうちの1つであり得る。
動作1338において、オーダー情報がオーダー管理モジュール1320に転送される。場合によっては、オーダー管理モジュール1320は、注文の確認、確認後の注文の登録など、注文に関する課金機能および会計機能を実行するように構成されてもよい。
動作1340において、注文に関する情報がオーダーオーケストレーションモジュール1322に伝送される。オーダーオーケストレーションモジュール1322は、このオーダー情報を利用して、顧客が行った注文に関するサービスおよびリソースのプロビジョニングをオーケストレーションしてもよい。場合によっては、オーダーオーケストレーションモジュール1322は、リソースのプロビジョニングをオーケストレーションして、オーダープロビジョニングモジュール1324のサービスを使用してサブスクリプションされているサービスをサポートしてもよい。
特定の実施形態では、オーダーオーケストレーションモジュール1322は、各注文に関連する業務の流れの管理を可能にし、ビジネスロジックを適用して、注文がプロビジョニングに進むべきかどうかを判断する。動作1342において、新しいサブスクリプションの注文を受けると、オーダーオーケストレーションモジュール1322は、サブスクリプションの注文を満たすために必要なリソースを割り当ててこれらのリソースを構成する要求をオーダープロビジョニングモジュール1324に送信する。オーダープロビジョニングモジュール1324は、顧客が申し込んだサービスのためのリソースの割り当てを有効にする。オーダープロビジョニングモジュール1324は、クラウドインフラストラクチャシステム1300が提供するクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理実施層との間に抽象度を設ける。よって、サービスおよびリソースがオンザフライで実際にプロビジョニングされたかどうか、または予めプロビジョニングされて要求された場合にのみ割り当てられたかどうかなどの実装の詳細からオーダーオーケストレーションモジュール1322を切り離すことができる。
動作1344において、サービスおよびリソースがプロビジョニングされると、クラウドインフラストラクチャシステム1302のオーダープロビジョニングモジュール1324によって、クライアントデバイス1304、1306、および/または1308上の顧客に、提供されたサービスについての通知が送信されてもよい。動作1346において、オーダー管理/監視モジュール1326によって顧客のサブスクリプションの注文が管理および追跡されてもよい。場合によっては、オーダー管理/監視モジュール1326は、サブスクリプションの注文におけるサービスに関する使用統計データ、たとえば、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムの稼働時間およびシステムの休止時間などを収集するように構成されてもよい。
特定の実施形態では、クラウドインフラストラクチャシステム1300は、素性管理モジュール1328を含んでもよい。素性管理モジュール1328は、クラウドインフラストラクチャシステム1300におけるアクセス管理および承認サービスなどの素性サービスを提供するように構成されてもよい。いくつかの実施形態では、素性管理モジュール1328は、クラウドインフラストラクチャシステム1302が提供するサービスを利用したい顧客についての情報を管理してもよい。このような情報は、このような顧客の素性を認証する情報、および、様々なシステムリソース(たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対してそれらの顧客がどのような操作を行うことが承認されているのかを記述する情報を含み得る。また、素性管理モジュール1328は、各顧客についての記述情報、およびその記述情報が誰によってどのようにアクセスおよび変更され得るかについての記述情報の管理を含んでもよい。
具体的な本開示の実施形態を説明したが、様々な変更例、代替例、代替的な構成、および均等物も本開示の範囲内に包含される。本開示の実施形態は、ある特定のデータ処理環境内の動作に制限されず、複数のデータ処理環境内で自由に動作することができる。これに加えて、特定の一続きのトランザクションおよびステップを使用して本開示の実施形態を説明したが、本開示の範囲は、記載の一続きのトランザクションおよびステップに限られないことは、当業者に明らかであるはずである。上述の実施形態の様々な特徴および態様は、個々に、または共同で使用されてもよい。
さらに、ハードウェアとソフトウェアとの特定の組合せを使用して本開示の実施形態を説明したが、ハードウェアとソフトウェアとの他の組合せも、本開示の範囲内であることを認識されたい。本開示の実施形態は、ハードウェアのみ、もしくは、ソフトウェアのみで実現されてもよく、またはそれらの組合せを使用して実現されてもよい。本明細書に記載の様々なプロセスは、同じプロセッサまたは任意の組合せのそれぞれ異なるプロセッサ上で実現できる。よって、コンポーネントまたはモジュールが特定の動作を実行するように構成されると説明されている箇所では、このような構成は、たとえば、この動作を実行するように電子回路を設計することによって、この動作を実行するようにプログラム可能な電子回路(マイクロプロセッサなど)をプログラムすることによって、またはそれらの任意の組合せによって達成できる。プロセスは、プロセス間通信のための従来技術を含む、いろいろな技術を使用して通信できるが、これに限定されず、それぞれ異なるペアプロセスは、異なる技術を使用してもよく、プロセスの同じペアは、異なる技術を別々のタイミングで使用してもよい。
明細書および図面は、厳密ではなく一例にすぎないと適宜みなされるべきである。しかしながら、添付の特許請求の範囲に記載のより広義の趣旨および範囲から逸脱することなく、追加、減算、削除、および他の変更ならびに変形がそれらに対してなされてもよいということは明白であろう。したがって、具体的な本開示の実施形態を説明したが、これらは、限定を意図しない。様々な変更例および均等物は、添付の特許請求の範囲内である。