JP4283328B2 - 部分的に順序付けられたトランザクションをスケジューリングしてイベントを関連付けるための方法 - Google Patents

Description

本発明は、イベント駆動システムに関し、特に、分散環境において部分的に時間に依存するイベントの並列処理を確実にするための方法に関する。

応答形アプリケーションは、イベントの検出によって動作するように構成されるイベント駆動のアプリケーションという種類に関連する。そのようなイベントの正確なタイミングおよび内容は、予めわからないのが通常である。イベントを検出し、その検出を適切な動作に結びつけるために、互いに異なる分野において数多くのツールが構築されている。このようなツールは、能動的なデータベース、イベント管理システム、「発行／購読（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）型」機構、リアル・タイム・システム、および同様の製品において存在する。

「Ｓｉｔｕａｔｉｏｎ ａｗａｒｅｎｅｓｓ ｓｙｓｔｅｍ」という題の２００３年８月５日に発行された米国特許第６６０４０９３号（エツォン（Ｅｔｚｉｏｎ）他）は、参照によって本願に引用されたものとする。本米国特許は、イベントを順次的な順序で処理するための構成可能なイベント駆動規則ベース・システムを開示している。以降、本明細書を通じて、このシステムを「動的ミドルウェア技術（Ａｃｉｔｉｖｅ Ｍｉｄｄｌｅｗａｒｅ Ｔｅｃｈｎｏｌｏｇｙ）」を意味する省略形である「ＡＭＩＴ」と称するものとする。ＡＭＩＴは、米国ニューヨーク州アーモンクのインターナショナル・ビジネス・マシン社の商標である。すなわち、互いに異なるイベントのインスタンス間のすべての関係（時間的および量的共に）がメモリ内に保存されていると同時に、入力イベントが１つずつ処理される。このアプローチは、イベントの多くが時間的な関係を有する場合（例えば、特定のイベントのシーケンスが特定の時間内に生じる場合）には必須であるものの、時間的に独立した膨大な数のイベントを分散環境において処理しなければならないような他の場合（例えば、個々のイベント・インスタンスの順序が計算された統計メトリクスよりも重要でない、集合イベント規則）には、拡張可能ではないだろう。また、ＡＭＩＴイベント規則（イベント結合）にデータベース・クエリが含まれる場合には、ＡＣＩＤトランザクション・サポートを追加しなければならない。

２００１年８月７日に発行された「Ｍｅｔｈｏｄ ｏｆ Ｓｃｈｅｄｕｌｉｎｇ ｄｉｓｔｒｉｂｕｔｅｄ ｔｒａｎｓａｃｔｉｏｎｓ」という題の米国特許６２７２５１５号（フォーケット（Ｆｏｕｑｕｅｔ））は、参照によって本願に引用されたものとする。本米国特許は、トランザクションの動作の起動をトランザクションが開始された時系列順序に従ってシリアル化するために、トランザクションの並列起動の可能性を有するトランザクショナル・モニタのための分散トランザクションをスケジューリングして、互いに異なるトランザクションまたは同一のトランザクションの動作間の実行が衝突することを許容する方法を開示する。よって、そのような方法は、基本的な動作に分割可能な従来のトランザクションには適用可能で、イベントはトランザクションの開始または動作の中止のみを信号で知らせるだけであったが、そのようなアプローチは、予め定義されたイベント結合（イベント駆動規則）を検出して、分散トランザクション環境における後続の処理を行う規則エンジンには適さない。

そのような場合には、イベント駆動規則エンジンは、各イベント・インスタンスを、これ以上複合動作に分割できないアトミックなトランザクションとして扱う。そのようなトランザクションは、処理されたイベント・インスタンスに特有なリソースを固定しなければならない。リソースとは、期間である計算ウィンドウを表すデータ構造であって、そこにおいては、イベント・インスタンスの根拠となることができ、予め定義されたイベントの結合（規則）が生じる。入力イベント間の時間的および他の意味的な依存性がある場合には、互いに異なる分散トランザクション間における、解消されなければならない衝突が生じうる。

したがって、本発明の目的は、意味的に関連しているイベントであって、構成イベントの順序が重要でありうるようなイベントを定義するイベント駆動規則を有するイベント・トランザクションの分散型トランザクション志向環境における並列処理のための改良された方法およびシステムを提供することである。

本発明の概略的な局面によれば、それぞれが各タイムスタンプを有するイベント・トランザクションをスケジューリングするための、所定のイベント規則を有するイベント駆動アプリケーションにおいて使用される方法（スケジューラ）が提供され、本方法は、前記所定のイベント規則に従ってイベント間の予想時間依存性を解消するステップと、イベント・トランザクションが処理されるであろう時を判断するステップとを含み、それによって、イベント・トランザクションを並列処理のために分散型プロセッサへディスパッチすることができる。

本発明を他の局面から見ると、そのような方法を実施するためのシステムが提供される。好ましくは、そのようなシステムは、予め定義されたイベント結合を検出するイベント受信器および搬送器を備え、１つ以上のイベントを受信するためのイベント・トランザクションと、イベント・トランザクションに結合され、前記イベントに関連した各タイムスタンプに応答可能で、関連イベント規則に従ってイベント間の予想時間依存性を解消するためのイベント並列制御部と、各分散型プロセッサに結合されるように適合されて、前記イベント規則定義からわかる依存性に従って前記イベントを並列的に実行するためのイベント並列制御部の少なくとも２つの出力ポートとを備える。

よって、本発明の好ましい実施形態は、イベント駆動規則エンジンにおいて状況を生じさせるイベント規則に適したトランザクションを定義し、そのようなトランザクションのための並列制御機構を定義する。

トランザクションを順次的ではなく並列的に処理するには、いくつかのイベント処理部間にトランザクションを分散させる必要がある。

イベント並列制御部は、単一のマシンを使用して並列制御アルゴリズムを中心的に実行し、実行準備のできたトランザクション、すなわち、現在のトランザクションの実行が完了する前に実行するはずだったすべてのトランザクションを互いに異なる処理部へディスパッチする。処理部は、互いに異なるマシン上の互いに異なる処理であってもよいし、遠隔手続呼び出し（ＲＰＣ）を使用して単一のマシン上の互いに異なる処理（スレッド）であってもよい。本発明は、ＡＭＩＴ用に開発されたが、分散環境において動作するイベント駆動規則エンジンの種類全体に対して容易に適用できる。

本発明を理解し、実際にどのように実行されるかを見るために、非限定的な例としてのみ、添付の図面を参照して、本発明の好ましい実施形態を説明する。

図１は、予め定義されたイベント結合（規則）に従ってイベントを検出および処理するための本発明の第１の実施形態に係るシステム１０を模式的に示すブロック図である。イベント・ディスパッチャ１１は、各イベントに関連したタイムスタンプに従ってイベントをイベント並列制御部１２へ順次搬送し、イベント処理部１３は、各イベントについてイベント処理を開始する。イベント処理部１３は、先に参照した米国特許第６６０４０９３号に記載されたＡＭＩＴのような任意の従来のイベント・トランザクション・プロセッサでありうる。イベント並列制御部１２は、同時に入力するイベントを処理するために、イベント規則の意味論的知識を使用する、タイムスタンプに基づく並列アルゴリズム（後述）を使用する。イベント・トランザクションが現在のイベント規則に従って開始できるかをチェックして、必要があればトランザクションの実行を中断する。また、対応イベントが、他のイベント結合および基本のイベントから派生された複雑な（入れ子となっている）イベント結合に対して定義された場合に、既に実行しているイベント・トランザクションをコミットまたは中止させる。

イベント規則は、イベントおよびルールが従来ＡＭＩＴへ供給されるのと同様のやり方で、外部データベース１４内またはイベント・ディスパッチャ１１によってアクセスされるデータ・ファイル内に記憶されてもよい。しかしながら、イベントは従来ＡＭＩＴへ直接供給されるのに対して、本発明においては、直接ではなく、イベント・ディスパッチャ１１を介して供給される。規則はＡＭＩＴおよびイベント・ディスパッチャによって同時に読み出されてもよい。イベント・ディスパッチャ１１は、まず、イベントをイベント並列制御部１２へ供給し、その後にのみ、イベント並列制御部１２からの開始制御情報に応じて、イベントをイベント処理部１３に供給する。各イベントに関連したタイムスタンプ情報が内部クロック（図示せず）または各イベントに関連した予め定義された実行順序によって導出されてもよい。イベント・ディスパッチャ１１は、イベント並列制御部１２と共に、既知の依存性に従って処理が開始されるであろう時を判断するように入力イベントを処理するイベント受信器および搬送器１５として動作して、その後、イベントをイベント処理部１３へディスパッチする。

図１は、イベント並列制御部１２の構成およびそれがイベント処理部１３に結合される方法を示す。実際には、本発明の好ましい一実施形態は、数個のイベント処理部を同時に実行できるので、実際には、イベント並列制御部１２は、複数のプロセッサ出力ポートを有し、それぞれの出力ポートは、各イベント処理部に結合するように適合されている。

図２は、分散環境で使用される本発明のそのような実施形態に係るシステム２０を模式的に示すブロック図である。図１を参照してすでに説明した構成要素は、同一の参照符号によって識別されることになる。よって、システム２０において、イベント受信器および搬送器１５は、複数のイベント処理部に結合され、そのそれぞれに１３が付されており、ＡＭＩＴエンジンによって実現されてもよい。入力イベントは、開始されるであろう時を判断するように、図１を参照して上述したように、イベント受信器および搬送器１５によって処理される。その後、互いに異なるイベント処理部１３へディスパッチされて並列処理されてもよいが、これが行われる方法および互いに異なるプロセッサが選択される方法自体は、本発明の特徴ではない。

本発明に係るシステムの予想される実施について述べたが、今度は、タイムスタンプに基づく並列制御アルゴリズムの動作の仕方を説明する。

本システムにおけるすべてのイベントと状況と間の依存グラフが作成される。依存グラフは、メタデータ（規則定義）の分析に基づいて構築されてもよい。メタデータは、通常は、イベント処理部１３への直接入力として供給されるが、本発明においては、イベント受信器および搬送器１５を介して間接的にそこへ供給される。本発明の一実施形態を実施する目的で、規則定義の一部として、各イベントについて以下のデータ構造が保持されるものとする。

本イベントを追加すべき状況のリスト、
本イベントがその計算ウィンドウを開始できる状況のリスト、
本イベントがその計算ウィンドウを閉じることができる状況のリスト、
本イベントによってトリガできる状況のリスト。

本発明を実施するアルゴリズムは、構成イベントに関連したタイムスタンプを示すデータを含むイベント／状況階層をあらわすデータを構築するために、これらの規則を処理して、イベントと状況との間の依存性と、状況と他の状況との間の依存性とを判断する。この情報は、その後、あるイベントが正当に開始したといえるかどうか、またはあるイベントは開始可能以前の関連イベントの完了に依存するかどうか判断するために使用される。このような事情において、状況は、あるイベントまたはイベントの組み合わせによって生じるイベントの一種に過ぎないことが理解されるだろう。したがって、アルゴリズムに関して言えば「イベント」という用語および「状況」という用語は区別がなされていない。

アルゴリズムは楽観的処理を許容するので、イベントは、分散プロセッサによって、従来行われるような順次的ではなく並列的に処理される。よって、前のイベントに時間的に依存しない後のイベントの処理が遅延しないように、前のイベントがコミットするのを待つ必要なく後のイベントの処理を開始できる可能性を考慮している。一方、後のイベントが前のイベントの完了までは後のイベントは解決できないことがイベント階層から判断される場合には、後のイベントが完了に時間依存する前のイベントが終了するまで、後のイベントは中止される。

アルゴリズムは、以下に説明するように、イベント間の時間依存性を抽出するようにイベント・データを処理する。これがどのように行われるかをより直感的な方法で説明するために、イベント階層が図示されている。しかしながら、実際には、重要なのは図示表現における暗黙の情報であって、当該情報はどのみちイベント・データ内に固有なものであるから、アルゴリズムは、イベント階層の図示表現を実際に生じさせる必要はないものと理解されるべきである。よって、以下の規則は、イベント階層を図によって構築するために適用される。

イベントまたは状況がオペランドとして状況に関係する場合には、イベント／状況ノードから状況ノードへエッジが追加される。
イベントまたは状況が計算ウィンドウの開始または終了として機能する場合には、対応する開始／終了エッジがイベント／状況ノードから状況ノードへ追加される。
並列制御テーブルが作成されて、各状況定義用に別個の欄が定義される。依存グラフにおいて、あるイベントから当該欄に関連した状況へのエッジがある場合、イベントが欄に追加される。各欄は、イベントの到着タイムスタンプによってソートされる。イベントは、その到着タイムスタンプと共に、並列制御テーブル内の適切な欄に追加される。特定のイベントによってトリガされうるすべての状況は、これらの状況がまだ保留中である旨を示すマークと共に並列制御テーブル内の適切な欄に追加される。以下に説明する例において、マークは、アスタリスク（＊）によって示されている。計算ウィンドウの終了として機能するイベントについては、延期／遅延状況を配慮するために、特別なマークが追加される。以下に説明する例において、そのようなイベントから依存状況へのパスは、「終了エッジ」としてマーク付けされている。同様な方法で、計算ウィンドウの開始として機能するイベントから依存状況へのパスは、「開始エッジ」としてマーク付けされている。これにより、アルゴリズムは、依存状況に関する計算ウィンドウの開始および終了依存を識別することができる。
イベント・トランザクションは、並列制御テーブルのすべての欄における「実」イベント（マーク付けされていない状況）のうちで最初に配置されている場合に開始されるはずである。イベント・トランザクションは、並列制御テーブルの全ての欄において最初に配置されている場合にのみコミットされることになる。通常のイベントと、計算ウィンドウの終了として機能するイベントとがあって、タイムスタンプが同一の場合（延期／遅延状況の場合）には、イベントは、新たなトランザクションを開始することになる。タイムスタンプｔ２のイベント・トランザクションがコミットしようとすると、アルゴリズムは、タイムスタンプｔ１（ｔ１＜ｔ２）を有するマーク付けされた状況が実状況になったか（マークが除去された）どうかをチェックする。このような場合に、後のイベント・トランザクションは中止されて再開される。
まだマーク付けされているタイムスタンプを有する状況がある場合には、マーク付けされた状況が解消するまで（除去されるか、または実状況となるまで）トランザクション処理はブロックされることになる。

図３から図５を参照して、互いに異なる例を説明する。図３は、依存性の単純な場合を示し、第１のイベントが状況の検出を導き、検出された状況が第２のイベントと共に他の状況検出に関わる。図４は、入力イベントが状況を検出するための計算ウィンドウを閉じることができる場合を示し、図５は、計算ウィンドウ期間の終了時にのみ報告される検出された状況は、他の状況検出については考慮しなければならない場合を示す。

第１の例

図３は、合成関数がｅ１である状況Ｓ１と、Ｓ１およびｅ２の合成である状況Ｓ２とを図示している。イベント・トランザクションが部分的に順序立っており、イベントがコミットされている順序またはシーケンスが重要であることを暗示しているものとする。両状況についての計算ウィンドウは、スタートアップで開始され、終了しない。

シナリオ

イベントｅ１はｔ１に到着し、イベントｅ２はｔ２に到着する（ｔ２＞ｔ１）。Ｓ１およびＳ２についての並列制御テーブルは、表１に示すとおりである。

状況Ｓ２に関して言えば、Ｓ１は、状況Ｓ２が生じうる前に完了（すなわち、コミット）しなければならない構成イベントである。しかしながら、Ｓ１は、イベントｅ１のコミットにも依存している。これは、状況Ｓ２に関して言えば、イベントＳ１は時間ｔ１において解消しておらず、そのようにマーク付けされている。ｅ１およびｅ２は共に、トランザクションを並列して開始することになる。Ｓ１がトリガされると、ｅ２はそのトランザクションを中止して、その作業をやり直すことになる。これにより、Ｓ２が（Ｓ１，ｅ２）のシーケンスであって、ｅ２がコミットする前にＳ１がコミットしなければならず、その後にのみＳ２が解消可能であることを示す場合に、トランザクションの順序付けは維持されることが確実となる。一方、Ｓ１が生じず、並列制御テーブルから削除されるという場合もある。例えば、Ｓ１は「銀行口座は引き出し超過である」という状況であり、この状況を生じさせるイベントであるｅ１は、単に顧客の現在の残高である場合がある。よって、ｅ２がコミットする時までにｅ１が到着し、かつ健全な残高である場合には、Ｓ１はトリガされず、並列制御テーブルから削除可能である。このことは、状況をトリガするために１つのイベントのみを必要とする定義の場合に発生しうる。例えば、Ｓ２は２つのイベント（Ｓ１またはｅ２）のうちの１つが到着するとトリガされるように定義されてもよい。例えば、Ｓ２は「口座上の問題」という状況を示し、ｅ２は「クレジット・カード
は取り消される」ことを示す場合を考える。この場合、Ｓ１がトリガされなければ、ｅ２は戻されず、Ｓ２が検出されることになる。これにより、イベント・ディスパッチャ１１は、イベント・トランザクションｅ１およびｅ２を別のプロセッサへディスパッチすることができ、並列処理が可能となることによって時間の節約となる。

第２の例

図４は、ｅ１の合成関数である状況Ｓ１を図示する。状況Ｓ２は、Ｓ１とｅ２との合成関数である。ここまでは、図３を参照して上述したのと同一のイベント階層である。しかしながら、すべての状況が特定の計算ウィンドウにおいて生じる一方で、以前の場合、計算ウィンドウは無制限であり、スタートアップから解除されることなく拡張されていたが、図４に示す状況が、スタートアップ後に開始して所定のターミネータを有する計算ウィンドウ内において強制的に生じる。これらは、イベントに関連した開始エッジまたは終了エッジとして図示されており、開始エッジまたは終了エッジは、当該イベントによって生じた状況が、エッジが開始エッジか終了エッジかによって、当該イベントと同時に開始または終了する計算ウィンドウと共に強制的に生じることを示す。よって、イベントｅ３は、Ｓ１およびＳ２についての計算ウィンドウを終了させる。これは、ｅ３が生じる場合には、Ｓ１およびＳ２の両方の計算が終了するという意味である。一方、Ｓ１およびＳ２の計算ウィンドウは、共にｅ４の到着で開始される。よって、Ｓ１およびＳ２両方の計算ウィンドウは、ｅ４に関連した時間からｅ３に関連した時間へと拡張する。これは、ｅ３がｅ４より前に到着する場合には、Ｓ１に対する影響はないという意味である。なぜならば、その計算ウィンドウは、Ｓ１がその計算の開始以前に計算される必要がある場合があるので、まだ開始されていないからである。イベントｅ４は、Ｓ１の計算は開始可能でｅ３によって計算ウィンドウが閉じられる時に計算が完了すると判断している。イベントｅ４は、計算ウィンドウを開始するが、Ｓ１は、（もしあれば、閾値条件に対応した）イベントｅ１の到着後に適切になるとすぐ検出されることになる。よって、ｅ４が到着すると、Ｓ１の計算ウィンドウを開始して、次に到着する（但しｅ３より前の）イベントｅ１が計算されることになる。一例として、ｅ４は「営業開始（ｄａｙ ｓｔａｒｔ）」イベント、ｅ３は「営業終了（ｄａｙ ｅｎｄ）」であってもよい。Ｓ１は「銀行口座が引き出し超過である」というイベント、ｅ１は「口座残高」であってもよい。イベントｅ２は「支払い要求」、Ｓ２は「支払い不履行」であってもよい。「支払い不履行」は、同一の営業日に「支払い要求」と「口座引き出し超過」とが受信される場合に検出されてもよい。

シナリオ

イベントｅ４はｔ１に到着し、イベントｅ１はｔ２に到着し、イベントｅ３はｔ３に到着し、イベントｅ２はｔ４に到着し、ｔ１＜ｔ２＜ｔ３＜ｔ４となる。

この場合、並列制御テーブルは、以下を含むことになる。

この場合、処理は順次的となる。なぜならば、ｅ３はｅ１（Ｓ１）前に開始できず、ｅ２はｅ３（Ｓ２）前に開始できないからである。イベントが計算ウィンドウを閉じる場合に計算ウィンドウを閉じると、トランザクションは、すべてのイベント（実状況、および楽観的に処理されるが後に中止されて再実行されてもよい「マーク付けされた状況」）のうち最初に配置されている場合にのみ開始することになり、各状況について別個にコミットされることになる（部分コミット）。部分コミットメントの後、他のトランザクションがコミットされた状況について開始してもよい。また、ある状況について計算ウィンドウが閉じられた後に、方法は、（同一のタイムスタンプの）ウィンドウを閉じるイベントの前に、遅延／延期状況がトリガされて書き込まれたかをチェックする。これは、同一のイベントによって計算ウィンドウが閉じられた他の状況において必要とされる延期／遅延状況の場合に生じることとなる。

第３の例

図５は、ｅ１の合成関数である延期された状況Ｓ１を図示する。状況Ｓ２は、Ｓ１の合成関数である。よってここでも、イベント階層は、図３を参照して上述したのと同一である。しかしながら、両方の状況についての計算ウィンドウは、スタートアップにおいて開始し、イベントｅ２の到着で終了する。

シナリオ

イベントｅ１はｔ１に到着し、ｅ２はｔ２に到着する（ｔ１＜ｔ２）．

この場合、並列制御テーブルは、以下を含むことになる。

状況Ｓ１は、タイムスタンプｔ１で書き込まれない。なぜなら、ｅ２のみがＳ１をトリガできるからである（延期状況）。Ｓ１は、ｅ２の到着で終了する計算ウィンドウ内でコミットされなければならない。よって、ｅ２が到着すると、Ｓ１の計算は停止し、すなわち、計算ウィンドウが閉じる。Ｓ１の計算は、ｅ２が到着すると実行される。すなわち、Ｓ１は延期状況なので、その計算はｅ２が到着するまで延期される。実際の計算は、ｅ２の前に到着したｅ１イベントに対して行われる。

ｅ２が到着してその処理を開始すると、Ｓ１の計算が終了する。Ｓ１が検出されて状況が生じたことが暗示されると、Ｓ１：ｔ１が並列制御テーブルに書き込まれ、ｅ２がその処理を中断し、その処理はＳ１の処理が完了した後にのみ再開される。これにより、例えばＡＭＩＴ言語の一部である延期状況の計算が可能となる。

延期状況の一例は、ＮＯＴ状況である。例えば、状況Ｓ１がＮＯＴ（ｅ１）として定義されるとする。この場合、Ｓ１は、ｅ１がｅ２以前に到着しない場合に検出されることになる。イベントｅ１はそのままであり、「口座残高」である状況Ｓ１は「平均残高」となり、Ｒｅｐｏｒｔ（ｅ１）として定義されることになる。この状況は、イベントｅ２が受信されるまで最大バランスを計算し、ｅ２の到着でトリガされることになる。状況Ｓ２は、「よい一日を（Ｇｏｏｄ Ｄａｙ）」となり、Ｓ１によって計算された平均残高が所定量より大きい場合にトリガされる。

図６は、図１および図２に示すイベント受信器および搬送器１５によって実行される主要動作の概要を示すフローである。よって、イベントを受信すると、イベント受信器および搬送器１５は、タイムスタンプをイベントに割り当て、受信されたイベントと、それによってトリガされうるすべての状況をイベント並列テーブル内の適切な欄に追加する。その後、所定の規則に従って、当該イベントについてトランザクションが開始できるかが判断される。開始できなければ、イベント受信器および搬送器１５は、イベント・トランザクションが開始できるまで待機する。イベント・トランザクションが開始できる場合には、イベント受信器および搬送器１５は、イベントをイベント処理部１３へディスパッチし、その後、イベント処理部１３から、トランザクション処理結果を受信する。その後、所定の規則に従って、トランザクションが本イベントに対してコミット可能かが判断される。コミット可能でない場合には、結果を廃棄して、トランザクションを再開する。コミット可能である場合には、イベント並列テーブルを更新して、結果をコミットする。どのプロセッサを選択するかは、本発明の一部ではないことに注意すべきである。任意の適切な既存のクラスタ化機構を使用できる。例えば、ＷｅｂＳｐｈｅｒｅ（ＩＢＭ社の登録商標）アプリケーション・サーバ・ベースのソリューションの場合には、ＷｅｂＳｐｈｅｒｅクラスタが使用されてもよく、そのロード・バランシング機構によってプロセッサが選択されることになる。

図７は、１つ以上のイベントを受信するためのイベント・ディスパッチャ１１を備えるイベント受信器および搬送器１５を機能的により詳細に示すブロック図である。イベント並列制御部１２は、イベント・ディスパッチャ１１に結合されて、イベントに関連したタイムスタンプに応答して、関連イベント規則に従ってイベント間の予想時間依存性を解消するためのものである。タイムスタンプは、到着前の各イベントに予め関連付けられていてもよいし、代わりに、タイムスタンプは、到着時にイベント受信器および搬送器１５によってイベントに割り当てられてもよい。イベント・ディスパッチャ１１は、登録部２０を含む。登録部２０は、登録されたリストを維持するように各入力イベントを登録するためのものであって、すべての依存性が解消される各イベント・トランザクションをイベント処理部１３へディスパッチするように適合されており、よって、イベントに関連したイベント規則定義からわかった依存性に従ってイベントの並列実行が可能となる。イベント並列制御部は、所定のイベント規則に従って、各登録されたイベントの予想時間依存性を、登録されたイベントとまだ検出されていないマーク付けされた状況と共に解消するように構成される。

イベント受信器および搬送器１５は、イベント・トランザクションの処理結果を受信するための受信部２１と、受信部２１に結合されて、イベント・トランザクションをコミットすべきかまたは中止すべきかを判定するためのステータス判定部２２とをさらに含む。ステータス判定部に結合された割り込み部２３は、イベント・トランザクションは中止すべきである旨を示すステータスに応答して、イベント・トランザクションを中止するためのものである。イベント・ディスパッチャ１１は、割り込み部に結合されて、イベント・トランザクションを再び処理部へディスパッチする。処理部は、上述の処理部と同一であっても、異なる処理部であってもよい。

また、本発明のシステムは、適切にプログラムされたコンピュータであってもよいことが理解されるだろう。同様に、本発明においては、本発明の方法を実行するためにコンピュータによって読み出し可能なコンピュータ・プログラムが意図されている。さらに、本発明においては、本発明の方法を実行するために機械によって実行可能な命令のプログラムを具体的に実施する機械読み取り可能なメモリが意図されている。

予め定義されたイベント結合（規則）に従ってイベントを検出および処理するための本発明の第１の実施形態に係るシステムを模式的に示すブロック図である。 分散環境において使用される本発明の第２の実施形態に係るシステムを模式的に示すブロック図である。 本発明の別の例に係るイベントと状況との間の依存性を説明する依存グラフを示す。 本発明の別の例に係るイベントと状況との間の依存性を説明する依存グラフを示す。 本発明の別の例に係るイベントと状況との間の依存性を説明する依存グラフを示す。 本発明に係るイベント受信器／搬送器によって実行される主要動作を示すフローである。 図１に示すイベント受信器／搬送器を機能的により詳細に示すブロック図である。

Claims (1)

1. それぞれが各タイムスタンプを有するイベント・トランザクションをスケジューリングするための、所定のイベント規則を有するイベント駆動アプリケーションにおいて使用される方法であって、
   前記所定のイベント規則に従ってイベント間の予想時間依存性を解消するステップと、
   前記イベント・トランザクションが処理されるであろう時を判断するステップとを含み、それによって、前記イベント・トランザクションを並列処理のために分散型プロセッサへディスパッチすることができ、
   前記イベント・トランザクションが処理されるであろう時を判断するステップが、
   登録されたイベントのリストを維持するように各入力イベントを登録するステップと、
   各登録されたイベントについて、前記所定のイベント規則に従って、登録されたイベント間の予想時間依存性を、まだ検出されていないマーク付けされた状況と共に解消するステップと、
   すべての依存性が解消された各イベント・トランザクションをイベント処理部へディスパッチするステップと、
   前記イベント・トランザクションの処理結果を受信するステップと、
   前記イベント・トランザクションをコミットすべきかまたは中止すべきかを判断するステップと、
   前記イベント・トランザクションを中止すべきである場合には、前記イベント・トランザクションを中止して、再びイベント処理部へディスパッチするステップとを含み、
   各入力イベントを登録するステップが、
   イベントを受信するステップと、
   タイムスタンプを前記イベントに割り当てるステップと、
   前記受信されたイベントによってトリガ可能なすべての状況を所定の規則を使用して判断するステップと、
   前記受信されたイベントと、それによってトリガ可能なすべての状況とをイベント並列テーブル内の適切な欄に追加するステップと、
   前記受信されたイベントによって生じたトランザクションを前記受信されたイベントのために開始できるかを前記所定の規則に従って判断するステップと、
   前記トランザクションを前記受信されたイベントのために開始できない場合には、前記トランザクションが開始できるまで待機するステップと、
   前記トランザクションを開始できる場合には、前記イベントをイベント処理部へディスパッチするステップと、
   トランザクション処理結果を前記イベント処理部から受信するステップと、
   前記トランザクションを前記受信されたイベントに対してコミットできるかを前記所定の規則に従って判断するステップと、
   前記トランザクションを前記受信されたイベントに対してコミットできない場合には、前記処理結果を廃棄して前記トランザクションを再開するステップと、 前記トランザクションを前記受信されたイベントに対してコミットできる場合には、前記イベント並列テーブルを更新して、前記トランザクションをコミットするステップとを含む、方法。

Images