(57)【要約】  タイマーを利用する処理を容易に並列化できるようにする。  情報処理装置（１０）でプロセス（１１）が実行され、情報処理装置（２０）でプロセス（２１）が実行される。情報処理装置（１０）は、プロセス（１１）によって生成される第１の発行要求を取得する。情報処理装置（１０）は、プロセス（２１）によって生成された第２の発行要求に応じて情報処理装置（２０）で発行される発行タイミング情報を受信する。情報処理装置（１０）は、発行タイミング情報に基づいて、第１の発行要求に応じたプロセス（１１）へのタイマーイベントの発行タイミングを制御する。
2015071978.tif 000002
【特許請求の範囲】
【請求項１】
複数のプロセスによって分散処理を行う分散システムの制御に用いられるプログラムであって、
コンピュータに、
前記複数のプロセスのうち前記コンピュータで実行される第１のプロセスによって生成される、タイマーイベントの第１の発行要求を取得し、
前記複数のプロセスのうち第２のプロセスを実行する他のコンピュータから、前記第２のプロセスによって生成されたタイマーイベントの第２の発行要求に応じて前記他のコンピュータで発行されるタイマーイベントの発行タイミング情報を受信し、
受信した前記タイマーイベントの発行タイミング情報に基づいて、前記タイマーイベントの第１の発行要求に応じた、前記第１のプロセスへのタイマーイベントの発行タイミングを制御する、
処理を実行させるイベント管理プログラム。
【請求項２】
前記タイマーイベントの第１の発行要求に基づいて、タイマーイベントの発行タイミングの特定に利用される第１の基準時刻が特定され、
前記タイマーイベントの発行タイミング情報は、タイマーイベントの発行タイミングの特定に利用される第２の基準時刻を示す情報を含み、
前記第１および第２の基準時刻から前記コンピュータと前記他のコンピュータとの間の共通の基準時刻を決定し、前記共通の基準時刻に基づいて前記第１のプロセスへのタイマーイベントの発行タイミングを制御する、
請求項１記載のイベント管理プログラム。
【請求項３】
前記共通の基準時刻は、前記タイマーイベントの第１の発行要求の取得状況および前記タイマーイベントの発行タイミング情報の受信状況に応じて仮決定し、前記他のコンピュータとの間の確定手続を通じて確定させ、
前記仮決定した共通の基準時刻によって特定される仮決定の発行タイミングまで、または、前記仮決定の発行タイミングから所定時間前までに前記確定手続が完了しない場合、前記仮決定の発行タイミングで前記第１のプロセスへタイマーイベントを発行する、
請求項２記載のイベント管理プログラム。
【請求項４】
前記所定時間は、前記コンピュータと前記他のコンピュータとの間の通信品質を示す指標値に基づいて算出する、
請求項３記載のイベント管理プログラム。
【請求項５】
前記コンピュータおよび前記他のコンピュータと異なる一のコンピュータで第３のプロセスが起動した場合、前記一のコンピュータに前記共通の基準時刻を通知する、
請求項２乃至４の何れか一項に記載のイベント管理プログラム。
【請求項６】
前記第１の基準時刻は、前記第１のプロセスが所定の条件を満たすデータを受け付けた時刻であり、前記第２の基準時刻は、前記第２のプロセスが前記所定の条件を満たすデータを受け付けた時刻である、
請求項２乃至５の何れか一項に記載のイベント管理プログラム。
【請求項７】
前記タイマーイベントの第１の発行要求に応じて発行されるタイマーイベントの他の発行タイミング情報を、前記他のコンピュータに送信し、
前記他のコンピュータでは、前記タイマーイベントの他の発行タイミング情報に基づいて、前記タイマーイベントの第２の発行要求に応じた、前記第２のプロセスへのタイマーイベントの発行タイミングが制御される、
請求項１乃至６の何れか一項に記載のイベント管理プログラム。
【請求項８】
複数のコンピュータを備えており、複数のプロセスによって分散処理を行う分散システムが行うイベント管理方法であって、
前記複数のプロセスのうち第１のプロセスを実行する第１のコンピュータにおいて、前記第１のプロセスによって生成される、タイマーイベントの発行要求を取得し、
前記タイマーイベントの発行要求に応じて発行するタイマーイベントの発行タイミング情報を、前記第１のコンピュータから、前記複数のプロセスのうち第２のプロセスを実行する第２のコンピュータに送信し、
前記第２のコンピュータにおいて、前記第１のコンピュータから受信した前記タイマーイベントの発行タイミング情報に基づいて、前記第２のプロセスへのタイマーイベントの発行タイミングを制御する、
イベント管理方法。
【請求項９】
複数のプロセスによって分散処理を行う分散システムであって、
第１の情報処理装置と第２の情報処理装置とを有し、
前記第１の情報処理装置は、
前記複数のプロセスのうち前記第１の情報処理装置で実行される第１のプロセスによって生成される、タイマーイベントの発行要求を取得する第１の制御部と、
前記タイマーイベントの発行要求に応じて発行するタイマーイベントの発行タイミング情報を、前記第２の情報処理装置に送信する通信部とを有し、
前記第２の情報処理装置は、
前記第１の情報処理装置から受信した前記タイマーイベントの発行タイミング情報に基づいて、前記複数のプロセスのうち前記第２の情報処理装置で実行される第２のプロセスへのタイマーイベントの発行タイミングを制御する第２の制御部を有する、
分散システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はイベント管理プログラム、イベント管理方法および分散システムに関する。
【背景技術】
【０００２】
近年、大量のデータを収集して分析し、収集したデータから有用な知見を引き出す大規模データ処理システムが利用されるようになっている。大規模データ処理システムの中には、継続的に到着するデータを順次処理していくストリーム型のものがある。ストリーム型の大規模データ処理システムは、分析のリアルタイム性を重視する場合に用いられることが多い。例えば、クレジットカードの使用履歴をリアルタイムに収集し、短時間に異なる店で複数回使用されたもの等、不正使用された可能性があるクレジットカードを検出するシステムが考えられる。また、例えば、道路上に設けたセンサから車両速度のデータをリアルタイムに収集し、渋滞が発生する場所を予測するシステムが考えられる。【０００３】
ストリーム型の大規模データ処理は、複合イベント処理（ＣＥＰ：Complex Event Processing）と呼ばれることもある。ＣＥＰでは、例えば、検出するデータのパターンやパターンに合致したデータの処理方法等を記述したプログラムモジュールをユーザが作成しておき、当該プログラムモジュールを実行状態にしておく。すると、実行状態のプログラムモジュールに従い、継続的に到着するデータの中からパターンに合致するものが検索されて処理される。ＣＥＰでは、上記のようなプログラムモジュールまたはそのプログラムモジュールの実行時のインスタンスを「クエリ」と呼ぶことがある。【０００４】
単位時間当たりに到着するデータが多い場合、ストリーム型の大規模データ処理システムは、複数のコンピュータ（物理マシン）を備える分散システムとして実装されることがある。分散システムでは、同様の処理を記述したプログラムモジュール（例えば、コピーした同じプログラムモジュール）を異なるコンピュータで並列に実行することができる。到着したデータを、上記プログラムモジュールに従って異なるコンピュータで動作する複数のプロセス（インスタンス）に対して振り分けることで、プログラムモジュールに記述されたデータ処理を並列化し、システムの処理能力を向上させることができる。【０００５】
なお、複数のノードの間で時刻（ＴＯＤ：Time of Day）を同期する分散システムが提案されている。この分散システムでは、複数のノードの中から選択されたマスタノードが、現在のＴＯＤ値を含むＴＯＤパケットを他のノードにブロードキャストする。他のノードは、受信したＴＯＤパケットに基づいてローカルのＴＯＤ値を更新する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２９７０７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、ユーザが作成するプログラムモジュールの中には、タイマーを利用して、所定の条件が満たされた時点からの相対時間に応じてデータ処理を行うものもある。例えば、ある種類のデータが最初に到着してからＮ秒（Ｎは正の整数）の間、後続のデータを溜めて分析対象として選択するようなプログラムモジュールが考えられる。【０００８】
しかし、タイマーを利用するプログラムモジュールをそのまま複数のコンピュータで実行してデータ処理を並列化しようとすると、次のような問題が生じる。データは異なるコンピュータで動作する複数のプロセスによって分散処理されるため、各プロセスが認識する「所定の条件」が満たされた時点（例えば、最初のデータが到着した時点）は、プロセスによって異なる可能性がある。また、タイマーは、コンピュータ毎に他のコンピュータとは独立に管理されることが多い。そのため、タイマーを利用するプログラムモジュールをそのまま複数のコンピュータで実行させると、プロセス間で処理タイミングがずれてしまい、データ処理の結果が並列化しない場合と変わってしまうおそれがある。【０００９】
一方、ユーザがプログラムモジュールを作成するときに、並列化を考慮する方法も考えられる。しかしながら、並列化に対応したプログラムモジュールを明示的に作成することはユーザの負担が大きく、また、システムによる並列性の管理も難しくなる。【００１０】
１つの側面では、本発明は、タイマーを利用する処理を容易に並列化できるようにするイベント管理プログラム、イベント管理方法および分散システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
１つの態様では、複数のプロセスによって分散処理を行う分散システムの制御に用いられるプログラムが提供される。このプログラムは、コンピュータに以下の処理を実行させる。複数のプロセスのうちコンピュータで実行される第１のプロセスによって生成される、タイマーイベントの第１の発行要求を取得する。複数のプロセスのうち第２のプロセスを実行する他のコンピュータから、第２のプロセスによって生成されたタイマーイベントの第２の発行要求に応じて他のコンピュータで発行されるタイマーイベントの発行タイミング情報を受信する。受信したタイマーイベントの発行タイミング情報に基づいて、タイマーイベントの第１の発行要求に応じた、第１のプロセスへのタイマーイベントの発行タイミングを制御する。【００１２】
また、１つの態様では、複数のコンピュータを備えており、複数のプロセスによって分散処理を行う分散システムが行うイベント管理方法が提供される。複数のプロセスのうち第１のプロセスを実行する第１のコンピュータにおいて、第１のプロセスによって生成される、タイマーイベントの発行要求を取得する。タイマーイベントの発行要求に応じて発行するタイマーイベントの発行タイミング情報を、第１のコンピュータから、複数のプロセスのうち第２のプロセスを実行する第２のコンピュータに送信する。第２のコンピュータにおいて、第１のコンピュータから受信したタイマーイベントの発行タイミング情報に基づいて、第２のプロセスへのタイマーイベントの発行タイミングを制御する。【００１３】
また、１つの態様では、複数のプロセスによって分散処理を行う、第１の情報処理装置と第２の情報処理装置とを有する分散システムが提供される。第１の情報処理装置は、複数のプロセスのうち第１の情報処理装置で実行される第１のプロセスによって生成される、タイマーイベントの発行要求を取得する第１の制御部と、タイマーイベントの発行要求に応じて発行するタイマーイベントの発行タイミング情報を、第２の情報処理装置に送信する通信部とを有する。第２の情報処理装置は、第１の情報処理装置から受信したタイマーイベントの発行タイミング情報に基づいて、複数のプロセスのうち第２の情報処理装置で実行される第２のプロセスへのタイマーイベントの発行タイミングを制御する第２の制御部を有する。
【発明の効果】
【００１４】
１つの側面では、タイマーを利用する処理を容易に並列化できる。
本発明の上記および他の目的、特徴および利点は、本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
【図面の簡単な説明】
【００１５】
【図１】第１の実施の形態の分散システムを示す図である。
【図２】第２の実施の形態の分散システムを示す図である。
【図３】エンジンノードのハードウェア例を示すブロック図である。
【図４】クエリの実行順序の例を示す図である。
【図５】エンジンノードの拡大または縮小の例を示す図である。
【図６】時間ベースオペレータの例を示す図である。
【図７】時間ベースオペレータの実装例を示す図である。
【図８】並列化されたクエリ毎のタイマー通知時刻の例を示す図である。
【図９】到着時刻を共通化する例を示す図である。
【図１０】最初の到着時刻の確定手続の例を示す図である。
【図１１】特定時刻経過時の暫定タイマー通知の例を示す図である。
【図１２】エンジンノードの機能例を示すブロック図である。
【図１３】共有管理テーブルの例を示す図である。
【図１４】イベント管理テーブルの例を示す図である。
【図１５】ルーティングテーブルの例を示す図である。
【図１６】タイマー依頼の例を示す図である。
【図１７】イベント制御通知の例を示す図である。
【図１８】到着時刻共通化の送信側処理の例を示すフローチャートである。
【図１９】到着時刻共通化の受信側処理の例を示すフローチャートである。
【図２０】確定通知受信時の処理の例を示すフローチャートである。
【図２１】特定時刻経過時の処理の例を示すフローチャートである。
【図２２】確認通知が許可される場合のシーケンス例を示す図である。
【図２３】確認通知が拒否される場合のシーケンス例を示す図である。
【図２４】エンジンノード追加時の管理の例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の分散システムを示す図である。
【００１７】
第１の実施の形態の分散システムは、複数のプロセスによってデータを分散処理する。この分散システムは、情報処理装置１０，２０を有する。情報処理装置１０，２０は、物理マシン、コンピュータ、サーバ装置等と呼ばれるものであってもよい。
【００１８】
情報処理装置１０ではプロセス１１が実行され、情報処理装置２０ではプロセス２１が実行されている。プロセス１１，２１は、同様の処理手順を記述したプログラムモジュールに基づいて起動された実行単位であり、例えば、コピーした同じプログラムモジュールから起動されたものである。プロセス１１，２１は、スレッド、タスク、ジョブ等と呼ばれるものであってもよく、ＣＥＰにおける「クエリ」であってもよい。プロセス１１，２１に対して、分散システムに到着したデータが振り分けられる。プロセス１１とプロセス２１は、異なるデータを同様の処理手順に従って並列処理することになる。
【００１９】
情報処理装置１０は、制御部１２および通信部１３を有する。情報処理装置２０は、制御部２２および通信部２３を有する。制御部１２，２２は、例えば、プロセッサである。プロセッサは、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）であってもよく、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路を含んでもよい。プロセッサは、例えば、ＲＡＭ（Random Access Memory）等の半導体メモリに記憶されたプログラムを実行する。また、「プロセッサ」は２以上のプロセッサの集合（マルチプロセッサ）であってもよい。通信部１３，２３は、複数の情報処理装置が通信するための通信インタフェースであり、有線通信インタフェースでも無線通信インタフェースでもよい。
【００２０】
制御部１２は、タイマーイベントの発行を要求するプロセス１１によって生成される、タイマーイベントの発行要求（第１の発行要求）を取得する。第１の発行要求は、所定の条件が満たされた時点（例えば、ある種類のデータが最初に受信された時点）からの相対時間に応じて、プロセス１１がデータ処理を行おうとする場合に生成され得る。制御部１２は、プロセス１１から第１の発行要求を取得した場合、タイマーを管理し、適切なタイミングでプロセス１１に対してタイマーイベントを発行する。プロセス１１は、タイマーイベントを受け取ることで、データ処理を行うべきタイミングを認識できる。同様に、制御部２２は、タイマーイベントの発行を要求するプロセス２１によって生成される、タイマーイベントの発行要求（第２の発行要求）を取得する。制御部２２は、プロセス２１から第２の発行要求を取得した場合、タイマーを管理し、適切なタイミングでプロセス２１に対してタイマーイベントを発行する。情報処理装置１０と情報処理装置２０とでは、互いに独立にタイマーが管理される。
【００２１】
ここで、プロセス１１，２１は異なるデータを並列処理することから、所定の条件が満たされた時点の認識が、プロセス１１とプロセス２１とで異なる可能性がある。例えば、プロセス１１は、分散システムに到着したデータのうちプロセス１１が担当するデータの中で、「最初に受信された時点」を認識する。プロセス２１は、プロセス２１が担当するデータの中で、「最初に受信された時点」を認識する。一方、プロセス１１，２１の処理手順を記述したプログラムモジュールは、分散システムに到着したデータ全体の中で、「最初に受信された時点」を認識するよう意図していることがある。そこで、制御部１２，２２は、タイマーイベントの発行タイミングを特定するための発行タイミング情報を情報処理装置１０，２０の間で共有し、タイマーイベントの発行タイミングが揃うようにする。
【００２２】
具体的には、制御部１２は、プロセス１１から第１の発行要求を取得した場合、タイマーイベントの発行タイミング情報を、通信部１３を介して情報処理装置２０に送信する。このタイマーイベントの発行タイミング情報には、例えば、プロセス１１が認識する基準時刻（第１の基準時刻）を示す情報が含まれる。第１の基準時刻は、プロセス１１が所定の条件を満たすデータを検出した時刻でもよいし、制御部１２が第１の発行要求を取得した時刻でもよい。前者の場合、プロセス１１が生成する第１の発行要求に、第１の基準時刻を示す情報が含まれていてもよい。制御部２２は、情報処理装置１０から通信部２３を介して受信される発行タイミング情報を監視する。制御部２２は、発行タイミング情報を受信した場合、受信した発行タイミング情報を考慮して（例えば、発行タイミング情報が示す第１の基準時刻を考慮して）、プロセス２１へのタイマーイベントの発行タイミングを制御する。ここでプロセス２１へ発行されるタイマーイベントは、例えば、プロセス２１が生成した第２の発行要求への応答としてのタイマーイベントである。
【００２３】
同様に、制御部２２は、プロセス２１から第２の発行要求を取得した場合、タイマーイベントの発行タイミング情報を、通信部２３を介して情報処理装置１０に送信する。このタイマーイベントの発行タイミング情報には、例えば、プロセス２１が認識する基準時刻（第２の基準時刻）が含まれる。制御部１２は、情報処理装置２０から通信部１３を介して受信される発行タイミング情報を監視する。制御部１２は、発行タイミング情報を受信した場合、受信した発行タイミング情報を考慮して（例えば、発行タイミング情報が示す第２の基準時刻を考慮して）、プロセス１１へのタイマーイベントの発行タイミングを制御する。ここでプロセス１１へ発行されるタイマーイベントは、例えば、プロセス１１が生成した第１の発行要求への応答としてのタイマーイベントである。
【００２４】
プロセス１１，２１の両方が発行要求を生成した場合、例えば、制御部１２，２２は、第１の基準時刻と第２の基準時刻とを比較し、情報処理装置１０，２０に共通の基準時刻を決定する。共通の基準時刻として、例えば、第１の基準時刻と第２の基準時刻のうち小さい方を採用することができる。共通の基準時刻を確定させるため、情報処理装置１０と情報処理装置２０との間で確定手続を実施してもよい。そして、制御部１２，２２はそれぞれ、共通の基準時刻に基づいて独立にタイマーを管理する。例えば、制御部１２，２２は、共通の基準時刻に待ち時間を加えた時刻を、タイマーイベントの発行タイミングとする。待ち時間は、プロセス１１，２１から指定された値を用いることができる。
【００２５】
例えば、プログラムモジュールが、ある種類のデータが分散システムに最初に到着してからＮ秒間、後続のデータを分析対象として蓄積することを意図しているとする。このプログラムモジュールに基づいてプロセス１１，２１が起動された場合、ある種類のデータが最初に到着したことを認識し発行要求が生成される時点は、プロセス１１，２１の間で異なる可能性がある。一方、制御部１２，２２により、タイマーの基準時刻が共通化される。これは、客観的な最初の到着時刻を、制御部１２，２２の間で共有していると言うこともできる。よって、制御部１２，２２は、プログラムモジュールの意図通りに、客観的な最初の到着時刻からＮ秒後にタイマーイベントを発行することができ、プロセス１１，２１が分析対象のデータを蓄積するＮ秒間の時間帯を揃えることができる。
【００２６】
第１の実施の形態の分散システムによれば、情報処理装置１０で実行されるプロセス１１によって発行要求が生成された場合、その発行要求に応じた発行タイミング情報が情報処理装置２０に送信され、情報処理装置２０のタイマー管理に利用される。また、情報処理装置２０で実行されるプロセス２１によって発行要求が生成された場合、その発行要求に応じた発行タイミング情報が情報処理装置１０に送信され、情報処理装置１０のタイマー管理に利用される。これにより、情報処理装置１０，２０が独立にタイマー管理を行っても、プロセス１１，２１へのタイマーイベントの発行タイミングを効率的に揃えることができる。例えば、情報処理装置１０，２０の間でタイマーの基準時刻を共通化し、共通の基準時刻に基づいてタイマー管理を行うことができる。
【００２７】
また、並列化を考慮していないプログラムモジュールに基づいて複数のプロセス（プロセス１１，２１等）を起動してデータ処理を並列化しても、並列化しない場合と結果が整合し、プログラムモジュールが意図したデータ処理を実現することができる。よって、データ処理を円滑に並列化でき、分散システムの性能を向上できる。また、プログラムモジュールにおいて並列処理の手順を明記しなくてもよいため、プログラムモジュールを作成するユーザの負担が軽減される。また、分散システムが動的に並列度を変更する（プロセス数を変える）ことが容易になる等、並列性の管理も容易となる。
【００２８】
［第２の実施の形態］
図２は、第２の実施の形態の分散システムを示す図である。第２の実施の形態の分散システムは、センサデバイスから受信した大量のセンサデータをリアルタイムに分析し、分析結果をクライアント装置に提供する情報処理システムである。センサデータとしては、例えば、道路上に設けた速度計からリアルタイムに収集する車両速度のデータや、店舗に設けたカードリーダからリアルタイムに収集するクレジットカードの使用履歴等が挙げられる。センサデータの分析としては、例えば、収集した車両速度のデータに基づいて渋滞の発生場所を予測する処理や、収集したクレジットカードの使用履歴に基づいてクレジットカードの不正使用を検出する処理等が挙げられる。
【００２９】
第２の実施の形態の分散システムは、ネットワーク３１，３２、ゲートウェイ３３、センサデバイス１００、入力アダプタノード２００、エンジンノード３００，３００ａ，３００ｂ，３００ｃ、出力アダプタノード４００、クライアント装置５００およびマネージャノード６００を有する。なお、エンジンノード３００，３００ａ，３００ｂ，３００ｃは、第１の実施の形態のシステムの情報処理装置１０，２０の一例である。
【００３０】
入力アダプタノード２００、エンジンノード３００，３００ａ，３００ｂ，３００ｃ、出力アダプタノード４００およびマネージャノード６００は、ネットワーク３１に接続されている。センサデバイス１００およびクライアント装置５００は、ネットワーク３２に接続されている。ネットワーク３１とネットワーク３２とは、ゲートウェイ３３を介して相互に接続されている。
【００３１】
ネットワーク３１とネットワーク３２とでは、異なるプロトコルが用いられ得る。例えば、ネットワーク３１はＬＡＮ（Local Area Network）でもよく、ネットワーク３２はインターネットなどの広域ネットワークでもよい。ゲートウェイ３３は、プロトコルの異なるネットワークを接続するネットワークノードである。ゲートウェイ３３は、プロトコルを変換することで、ネットワーク３１，３２を相互接続する。
【００３２】
センサデバイス１００は、入力アダプタノード２００にセンサデータを送信する。入力アダプタノード２００は、センサデバイス１００からセンサデータを受信するコンピュータである。入力アダプタノード２００は、受信したセンサデータを、クエリによって処理されるイベントと呼ばれる形式のデータに変換する。
【００３３】
「クエリ」は、イベントの到着に応じて情報処理を行うイベント駆動型の処理主体である。第２の実施の形態において、クエリは、ユーザが記述したクエリプログラムに基づいて起動されるインスタンスであり、プロセス・スレッド・タスク・ジョブ・オブジェクト等と呼ばれるものであってもよい。並列化のために、同じクエリプログラムからインスタンスとしてのクエリを複数起動させることも可能である。クエリは、エンジンノード３００，３００ａ，３００ｂ，３００ｃに配置される。各エンジンノードには、１または２以上のクエリが配置される。入力アダプタノード２００は、定義されたフローに従って、イベントをあるエンジンノード（例えば、エンジンノード３００）へ送信する。
【００３４】
エンジンノード３００，３００ａ，３００ｂ，３００ｃは、クエリを実行するコンピュータである。後述するように、定義されたフローに従って、複数のクエリが連携して情報処理を行う。クエリは、入力アダプタノード２００または前段のクエリからイベントを受信する。クエリは、受信したイベントに応じた処理を実行し、実行結果としてイベントを出力する。出力されるイベントとしては、受信したイベントを一定時間蓄積したものや、受信したイベントに基づいて新たに生成されたもの等が挙げられる。クエリが出力したイベントは、出力アダプタノード４００または後段のクエリへ送信される。後段のクエリが並列化されている場合、複数のイベントが複数の後段のクエリへ振り分けられる。なお、イベントは、同一エンジンノード内の異なるクエリ間で受け渡されることもあるし、異なるエンジンノードに配置されたクエリ間で受け渡されることもある。
【００３５】
第２の実施の形態では、最初は、エンジンノード３００，３００ａ，３００ｂが稼働しておりエンジンノード３００ｃが稼働していないものとする。エンジンノード３００ｃは、エンジンノード３００，３００ａ，３００ｂが高負荷の場合に使用される予備のエンジンノードとして位置付けることができる。なお、第２の実施の形態では、クエリが配置されるエンジンノード３００，３００ａ，３００ｂ，３００ｃを物理的なコンピュータ（物理マシン）としたが、仮想的なコンピュータ（仮想マシン）としてもよい。
【００３６】
出力アダプタノード４００は、定義されたフローに従って、最終的な結果としてのイベントをあるエンジンノード（例えば、エンジンノード３００ｂ）から受信するコンピュータである。受信したイベントには、センサデータの解析結果を示す情報が含まれる。出力アダプタノード４００は、受信したイベントをクライアント装置５００が参照可能な形式の結果データに変換し、結果データをクライアント装置５００へ送信する。
【００３７】
クライアント装置５００は、センサデータの解析結果を示す結果データを出力アダプタノード４００から受信し、受信した結果データをユーザに提供するコンピュータである。例えば、クライアント装置５００は、結果データをディスプレイに表示する。
【００３８】
マネージャノード６００は、エンジンノード３００，３００ａ，３００ｂの負荷を監視し、各エンジンノードの稼働状況およびクエリの配置を制御するコンピュータである。マネージャノード６００は、エンジンノード３００，３００ａ，３００ｂの負荷に応じて、稼働させるエンジンノードの追加や削除を行うことがある。また、マネージャノード６００は、負荷分散のためにエンジンノード間でクエリを移動させることがある。また、マネージャノード６００は、負荷分散のために、同一のクエリプログラムから起動するクエリの数（並列度）を増加または減少させることがある。
【００３９】
ここで、以下のようなフローでセンサデータを分析することを考える。入力アダプタノード２００は、センサデバイス１００からセンサデータを受信し、受信したセンサデータをイベントに変換してエンジンノード３００に送信する。エンジンノード３００では、第１段階の処理を行うクエリが実行されている。エンジンノード３００は、受信したイベントに応じた処理を行い、処理結果としてのイベントをエンジンノード３００，３００ａ，３００ｂへ振り分ける。エンジンノード３００，３００ａ，３００ｂでは、同一のクエリプログラムから起動された第２段階の処理を行うクエリが並列に実行されている。
【００４０】
エンジンノード３００，３００ａ，３００ｂは、エンジンノード３００から受信した異なるイベントを並列に処理し、それぞれ処理結果としてのイベントをエンジンノード３００ｂへ送信する。エンジンノード３００ｂでは、第３段階の処理を行うクエリが実行されている。エンジンノード３００ｂは、受信したイベントに応じた処理を行い、処理結果としてのイベントを出力アダプタノード４００に送信する。出力アダプタノード４００は、受信したイベントを結果データに変換してクライアント装置５００へ送信する。
【００４１】
図３は、エンジンノードのハードウェア例を示すブロック図である。エンジンノード３００は、プロセッサ３０１、ＲＡＭ３０２、ＨＤＤ（Hard Disk Drive）３０３、画像信号処理部３０４、入力信号処理部３０５、ディスクドライブ３０６および通信インタフェース３０７を有する。これらユニットは、エンジンノード３００内でバス３０８に接続されている。なお、プロセッサ３０１は、第１の実施の形態の制御部１２，２２の一例である。通信インタフェース３０７は、第１の実施の形態の通信部１３，２３の一例である。
【００４２】
プロセッサ３０１は、プログラムの命令を実行する演算器を含むプロセッサであり、例えばＣＰＵである。プロセッサ３０１は、ＨＤＤ３０３に記憶されているプログラムやデータの少なくとも一部をＲＡＭ３０２にロードし、プログラムを実行する。なお、プロセッサ３０１は複数のプロセッサコアを備えてもよく、エンジンノード３００は複数のプロセッサを備えてもよい。エンジンノード３００は、複数のプロセッサまたは複数のプロセッサコアを用いてプログラムの命令を並列に実行してもよい。また、２以上のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼んでもよく、プロセッサ３０１はＦＰＧＡやＡＳＩＣ等の専用回路を含んでいてもよい。
【００４３】
ＲＡＭ３０２は、プロセッサ３０１が実行するプログラムやプログラムから参照されるデータを一時的に記憶する揮発性メモリである。なお、エンジンノード３００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個の揮発性メモリを備えてもよい。
【００４４】
ＨＤＤ３０３は、ＯＳ（Operating System）やファームウェアやアプリケーションソフトウェア等のソフトウェアのプログラムおよびデータを記憶する不揮発性の記憶装置である。なお、エンジンノード３００は、フラッシュメモリ等の他の種類の記憶装置を備えてもよく、複数個の不揮発性の記憶装置を備えてもよい。
【００４５】
画像信号処理部３０４は、プロセッサ３０１からの命令に従って、エンジンノード３００に接続されたディスプレイ４１に画像を出力する。ディスプレイ４１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイ等を用いることができる。
【００４６】
入力信号処理部３０５は、エンジンノード３００に接続された入力デバイス４２から入力信号を取得し、プロセッサ３０１に通知する。入力デバイス４２としては、マウスやタッチパネル等のポインティングデバイス、キーボード等を用いることができる。
【００４７】
ディスクドライブ３０６は、記録媒体４３に記録されたプログラムやデータを読み取る駆動装置である。記録媒体４３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤ等の磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）等の光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。ディスクドライブ３０６は、プロセッサ３０１からの命令に従って、記録媒体４３から読み取ったプログラムやデータをＲＡＭ３０２またはＨＤＤ３０３に格納する。
【００４８】
通信インタフェース３０７は、ネットワーク３１等のネットワークを介して他の情報処理装置（例えば、エンジンノード３００ａ）と通信を行う。
なお、エンジンノード３００はディスクドライブ３０６を備えていなくてもよく、ユーザが操作する端末装置から制御される場合には、画像信号処理部３０４や入力信号処理部３０５を備えていなくてもよい。また、ディスプレイ４１や入力デバイス４２は、エンジンノード３００の筐体と一体に形成されていてもよい。入力アダプタノード２００、エンジンノード３００ａ，３００ｂ，３００ｃ、出力アダプタノード４００およびクライアント装置５００も、エンジンノード３００と同様のハードウェアを用いて実現できる。
【００４９】
図４は、クエリの実行順序の例を示す図である。クエリ３１０，３１１は、エンジンノード３００に配置されている。クエリ３１２は、エンジンノード３００ａに配置されている。クエリ３１３，３１４は、エンジンノード３００ｂに配置されている。
【００５０】
クエリ３１１，３１２，３１３は、同じクエリプログラムから起動されたクエリであり、複数の異なるイベントに対して同様の処理を並列に実行する。第２の実施の形態において、同じクエリプログラムから起動されたクエリを「同じ種類のクエリ」と言うことがある。一方、クエリ３１０とクエリ３１１，３１２，３１３とクエリ３１４とは、異なるクエリプログラムから起動されたクエリである。第２の実施の形態において、異なるクエリプログラムから起動されたクエリを「異なる種類のクエリ」と言うことがある。
【００５１】
この分散システムでは、クエリ３１０は、入力アダプタノード２００から受信したイベントに応じた処理を行い、処理結果としてのイベントをクエリ３１１，３１２，３１３の何れかに送信する。このとき、クエリ３１０は、クエリ３１１，３１２，３１３の負荷を均等化するため、生成した複数のイベントをクエリ３１１，３１２，３１３に振り分ける。クエリ３１１，３１２，３１３は、異なるイベントを並列に処理することになる。
【００５２】
次に、クエリ３１１，３１２，３１３はそれぞれ、クエリ３１０から受信したイベントに応じた処理を行う。クエリ３１１，３１２，３１３は、同じクエリプログラムから起動されたものであるため、異なるイベントに対して同様の処理手順を実行することになる。クエリ３１１，３１２，３１３は、処理結果のイベントをクエリ３１４へ送信する。クエリ３１４は、クエリ３１１，３１２，３１３から受信したイベントに応じた処理を行い、処理結果としてのイベントを出力アダプタノード４００へ送信する。
【００５３】
このように、第２の実施の形態の分散システムでは、各クエリがイベントの到着を契機としてクエリプログラムに定義された処理を実行し、他のイベントを生成する。複数のクエリは直列に結合することができる。これにより、継続的に到着する大量のセンサデータをリアルタイムに分析することができる。また、クエリ３１１，３１２，３１３のように、同じ種類のクエリを異なるエンジンノードで実行させることで、クエリプログラムに定義された処理を分散並列化でき、スループットを向上させることができる。なお、クエリ３１１，３１２，３１３は、第１の実施の形態のプロセス１１，２１の一例である。
【００５４】
図５は、エンジンノードの拡大または縮小の例を示す図である。エンジンノード３００に配置されているクエリが、互いに異なるデータ範囲に属する（例えば、キーが互いに異なる範囲に属する）イベント＃１，＃２，＃３を処理しているとする。このとき、エンジンノード３００の負荷が閾値以上となったため、エンジンノード３００ａ，３００ｂを利用してイベント＃１，＃２，＃３の処理を並列化することになったとする。
【００５５】
すると、エンジンノード３００に配置されているクエリをエンジンノード３００ａ，３００ｂにコピーする。クエリの「コピー」は、同じ種類のクエリを増やす（並列度を上げる）ことを意味し、そのクエリを起動するためのクエリプログラムをコピーして他のエンジンノードで実行させることにより実現できる。クエリのコピーにより、クエリプログラムに定義された処理をエンジンノード３００，３００ａ，３００ｂで並列実行できる。
【００５６】
例えば、イベント＃１をエンジンノード３００が処理し、イベント＃２をエンジンノード３００ａが処理し、イベント＃３をエンジンノード３００ｂが処理するようにする。エンジンノード３００，３００ａ，３００ｂに異なるデータ範囲を割り当てることで、エンジンノード３００，３００ａ，３００ｂが異なるイベントを並列に処理できる。イベントの振り分けは、例えば、イベントに含まれるキーなどの識別子に基づいて行われる。
【００５７】
一方、エンジンノード３００がイベント＃１を処理し、エンジンノード３００ａがイベント＃２を処理し、エンジンノード３００ｂがイベント＃３を処理しているときに、各エンジンノードの負荷が下がったとする。このとき、クエリの並列度を３から１に減らすことができる。すると、例えば、エンジンノード３００ａ，３００ｂにコピーしたクエリが削除される。以降は、エンジンノード３００ａ，３００ｂに割り当てられていたデータ範囲に属するイベントも、エンジンノード３００が処理することになる。
【００５８】
このように、第２の実施の形態の分散システムは、エンジンノード３００，３００ａ，３００ｂの負荷に応じてクエリの並列度を動的に変更することができる。なお、クエリの並列度を上げることをシステムの拡大と言うことができ、クエリの並列度を下げることをシステムの縮小と言うことができる。システムの拡大または縮小が発生すると、同じ種類の１または２以上のクエリそれぞれに割り当てられるデータ範囲が変更される。データ範囲の割り当ては、例えば、マネージャノード６００によって決定されてエンジンノード３００，３００ａ，３００ｂに通知される。これにより、並列実行される同じ種類の複数のクエリに、前段のクエリから出力されたイベントを振り分けることができる。
【００５９】
次に、図６〜７を用いて、時間ベースオペレータについて説明する。
図６は、時間ベースオペレータの例を示す図である。クエリ３１１は、オペレータ３１１ａを有する。オペレータは、クエリプログラムに記述された演算子のインスタンスであり、クエリの中で実行される。演算子には、イベントの収集・検索・選択などに相当する演算子、算術演算・論理演算・関係演算の演算子、関数などが含まれる。１つのクエリに複数のオペレータが含まれることがある。その場合、例えば、複数のオペレータの間の関係が木構造で定義され、木構造に応じた順序で複数のオペレータが呼び出される。
【００６０】
オペレータの中には、時間ベースオペレータが存在する。時間ベースオペレータは、所定の時間条件が満たされたタイミングで実行されるものであり、例えば、基準時刻からの相対時間に応じたタイミングで実行される。時間ベースオペレータの例として、あるイベントが到着してから一定時間後（例えば、４秒後）に処理を行うものが考えられる。この処理は一定周期で繰り返されることもある。なお、時間条件が満たされて時間ベースオペレータが実行されることを、時間ベースオペレータが「発火する」と言うこともできる。
【００６１】
クエリ３１１に含まれるオペレータ３１１ａは、時間ベースオペレータである。オペレータ３１１ａは、クエリ３１１が起動してから最初にイベントが到着した時刻を基準時刻とし、基準時刻からＮ秒間（例えば、４秒間）の間に到着したイベントを蓄積し、蓄積されたイベントを基準時刻からＮ秒後に出力する。以降、オペレータ３１１ａは、前回イベントを出力してからＭ秒間（Ｎ＝Ｍでもよい）の間に到着したイベントを蓄積し、直近のＭ秒間で蓄積されたイベントを出力することを繰り返す。
【００６２】
クエリプログラムは、イベント処理言語（ＥＰＬ：Event Processing Language）を用いて記述することができる。例えば、クエリ３１１のクエリプログラムは、“ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  ＩｎｐｕｔＳｔｒｅａｍ．ｗｉｎ：ｔｉｍｅ＿ｂａｔｃｈ（４ｓｅｃ）”のように記述される。このクエリプログラムは、演算子“ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  ＩｎｐｕｔＳｔｒｅａｍ”と、演算子“ｗｉｎ：ｔｉｍｅ＿ｂａｔｃｈ（４ｓｅｃ）”とを含んでいる。演算子“ｗｉｎ：ｔｉｍｅ＿ｂａｔｃｈ（４ｓｅｃ）”は、最初にイベントが到着してから４秒毎にオペレータが発火することを示す。演算子“ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  ＩｎｐｕｔＳｔｒｅａｍ”は、このクエリプログラムのインスタンスに対して到着したイベントを選択して出力することを示す。
【００６３】
このような時間ベースオペレータに関して、クエリプログラムに基づいて１つのクエリが起動してから当該クエリに１つ目のイベントが到着した時刻を、当該クエリにとっての「到着時刻」と言うことができる。また、蓄積したイベントを出力する時刻を「発火時刻」、到着時刻から１回目の発火までの時間を「待機時間」、前回の発火から次の発火までの間隔（２回目以降の発火の繰り返し周期）を「発火間隔」と言うことができる。
【００６４】
クエリ３１１が配置されるエンジンノード３００には、クエリ３１１に対応する状態記憶部３１１ｂが設けられる。状態記憶部３１１ｂは、クエリ３１１の内部状態を示す情報を記憶する。内部状態を示す情報には、オペレータ３１１ａに基づいて一時的に蓄積されたイベントが含まれる。また、内部状態を示す情報には、クエリ３１１，３１２，３１３のうちクエリ３１１に割り当てられたデータ範囲を示す情報が含まれる。
【００６５】
例えば、クエリ３１１は、起動後の１番目のイベントとして、識別子がＥｖ＃１であるイベント（イベントＥｖ＃１）を受信する。その後、クエリ３１１は、イベントＥｖ＃１が受信されてからＮ秒以内に、続けてイベントＥｖ＃２，Ｅｖ＃３を受信する。イベントＥｖ＃１，Ｅｖ＃２，Ｅｖ＃３は、前段のクエリ３１０が出力するイベントのうち、クエリ３１１が担当するデータ範囲に属するイベントである。その間、クエリ３１１は、状態記憶部３１１ｂにイベントＥｖ＃１，Ｅｖ＃２，Ｅｖ＃３を蓄積しておく。そして、イベントＥｖ＃１が到着してからＮ秒経過すると、オペレータ３１１ａが発火する。オペレータ３１１ａの発火に伴い、クエリ３１１は、状態記憶部３１１ｂに蓄積されたイベントＥｖ＃１，Ｅｖ＃２，Ｅｖ＃３を後段のクエリ３１４へ送信する。
【００６６】
次に、時間ベースオペレータの実装方法について説明する。
図７は、時間ベースオペレータの実装例を示す図である。エンジンノード３００は、エンジン３２０を有する。エンジン３２０は、エンジンノード３００で実行される１または２以上のクエリを制御する。物理マシンまたは仮想マシンとしての１つのエンジンノード毎に、１つのエンジンが実行される。以下に説明するように、エンジン３２０は、オペレータ３１１ａの発火タイミングを制御することができるタイマー機能を有する。
【００６７】
（Ｓ１）クエリ３１１にとって１つ目のイベントＥｖ＃１がクエリ３１１に到着する。
（Ｓ２）オペレータ３１１ａは、イベントＥｖ＃１が到着したことを契機として、タイマー依頼をエンジン３２０へ送信する。タイマー依頼は、発火タイミングを示すタイマー通知をオペレータ３１１ａに対して発行するよう要求するものである。タイマー依頼には、イベントＥｖ＃１の到着時刻や待機時間の情報が含まれ得る。タイマー依頼がタイマー通知を繰り返し発行するよう要求するものである場合、タイマー依頼に発火間隔が含まれ得る。クエリ３１１は、オペレータ３１１ａがエンジン３２０からタイマー通知を受け取るまで、前段のクエリ３１０から振り分けられたイベントを蓄積する。
【００６８】
（Ｓ３）エンジン３２０は、タイマー依頼で指定された到着時刻と待機時間から、１回目の発火時刻を算出する。通常、１回目の発火時刻は、到着時刻に待機時間を加えたものである。エンジン３２０は、算出した発火時刻になるとタイマー通知をオペレータ３１１ａに対して発行する。オペレータ３１１ａはイベント駆動型の処理主体であるため、タイマー通知はイベントの一種として実装することが可能である。また、エンジン３２０は、タイマー依頼で発火間隔が指定されている場合、前回の発火時刻から発火間隔が経過する毎に、タイマー通知をオペレータ３１１ａに対して発行する。
【００６９】
（Ｓ４）オペレータ３１１ａは、エンジン３２０からタイマー通知を受け取ると、発火タイミングが到来したことを検知する。１回目のタイマー通知が発行されたとき、クエリ３１１は、イベントＥＶ＃１が到着してから蓄積したイベントを、後段のクエリ３１４に対して出力する。また、２回目のタイマー通知が発行されたとき、クエリ３１１は、前回タイマー通知が発行されてから蓄積したイベントを、後段のクエリ３１４に対して出力する。
【００７０】
なお、オペレータ３１１ａが生成するタイマー依頼には、発火上限回数の情報が含まれていることがある。その場合、最大で発火上限回数だけエンジン３２０からオペレータ３１１ａに対してタイマー通知が発行される。ユーザからの指示でクエリ３１１がシャットダウンされた場合、オペレータ３１１ａへのタイマー通知の発行は停止される。
【００７１】
次に、図８〜１１を用いて、到着時刻の共通化について説明する。
図８は、並列化されたクエリ毎のタイマー通知時刻の例を示す図である。入力ストリーム５１は、前段のクエリ３１０が出力したイベントをクエリ３１１，３１２，３１３に渡す仮想的な入力チャネルである。出力ストリーム５２は、クエリ３１１，３１２，３１３から出力されたイベントを後段のクエリ３１４に渡す仮想的な出力チャネルである。入力ストリーム５１や出力ストリーム５２は、エンジンノード３００，３００ａ，３００ｂのエンジンによって形成される。クエリ３１１，３１２は、入力ストリーム５１および出力ストリーム５２を認識すればよく、前段や後段のクエリを直接意識しなくてよい。
【００７２】
前述のように、エンジンノード３００のクエリ３１１と対応するように、エンジンノード３００ａはクエリ３１２および状態記憶部３１２ｂを有し、クエリ３１２はオペレータ３１２ａを有する。クエリ３１１，３１２は、同じクエリプログラムから起動されたものであり、入力ストリーム５１から受け取る異なるイベントを並列に処理する。
【００７３】
このとき、オペレータ３１１ａ，３１２ａが認識する「到着時刻」が異なることにより、オペレータ３１１ａ，３１２ａの発火時刻が異なるという問題が生じ得る。例えば、イベントＥｖ＃１がクエリ３１１に配信され、イベントＥｖ＃２がクエリ３１２に配信されたとする。イベントＥｖ＃１がクエリ３１１に到着した時刻が００：００：０１であり、イベントＥｖ＃２がクエリ３１２に到着した時刻が００：００：０２であるとする。
【００７４】
この場合、オペレータ３１１ａが認識する「到着時刻」は００：００：０１であり、待機時間が４秒であるとすると、オペレータ３１１ａの１回目の発火時刻は００：００：０５になる。よって、クエリ３１１は、００：００：０１〜００：００：０５の間にクエリ３１１に到着したイベントを、００：００：０５になったときに出力ストリーム５２に出力する。一方、オペレータ３１２ａが認識する「到着時刻」は００：００：０２であり、オペレータ３１２ａの１回目の発火時刻は００：００：０６になる。よって、クエリ３１２は、００：００：０２〜００：００：０６の間にクエリ３１２に到着したイベントを、００：００：０６になったときに出力ストリーム５２に出力する。
【００７５】
上記のクエリ３１１，３１２の動作は、並列化を行わなかった場合と異なっており、クエリプログラムの本来の意図とは異なるものになっている。並列化しなかった場合、単一のクエリが認識する「到着時刻」はイベントＥｖ＃１が到着した００：００：０１であるため、００：００：０１〜００：００：０５の間に当該単一のクエリに到着したイベントのみが出力ストリーム５２に出力される。このように、時間ベースオペレータに相当する演算子を含むクエリプログラムを、異なるエンジンノード上で単純に並列実行してしまうと、処理結果が並列実行しなかった場合と異なってしまう可能性がある。
【００７６】
そこで、第２の実施の形態の分散システムは、発火時刻を算出するための基準時刻である「到着時刻」を、エンジンノード３００，３００ａ，３００ｂの間で共通化する手続を行う。クエリ３１１，３１２，３１３全体にとって１つ目のイベント（上記の例におけるイベントＥｖ＃１）が到着した時刻は、「最初の到着時刻」と言うことができる。
【００７７】
図９は、到着時刻を共通化する例を示す図である。エンジン３２０と対応するように、エンジンノード３００ａはエンジン３２０ａを有し、エンジンノード３００ｂはエンジン３２０ｂを有する。クエリ３１３は、オペレータ３１１ａ，３１２ａと対応するように、オペレータ３１３ａを有する。エンジンノード３００，３００ａ，３００ｂが時刻デバイスを用いて管理する現在時刻（リアルタイムクロック）は、同期がとられている。
【００７８】
クエリ３１１にイベントＥｖ＃１が到着すると（Ｓ１）、オペレータ３１１ａはエンジン３２０にタイマー依頼を送信する（Ｓ２）。このタイマー依頼で指定される到着時刻が、００：００：０１であるとする。すると、エンジン３２０は、クエリ３１１にとっての到着時刻を示す情報をエンジンノード３００ａ，３００ｂに送信する。エンジンノード３００ａ，３００ｂは、受信した到着時刻の情報に基づき、発火時刻を算出するための基準時刻としての「最初の到着時刻」を決定する（Ｓ１１，Ｓ１２）。クエリ３１２，３１３がイベントを受信していない場合、００：００：０１が最初の到着時刻として決定される。
【００７９】
この結果、エンジン３２０，３２０ａ，３２０ｂによって、同じ種類のクエリ３１１，３１２，３１３についての最初の到着時刻が００：００：０１に共通化される。エンジン３２０，３２０ａ，３２０ｂは、共通化した最初の到着時刻に基づいて、それぞれ独立に発火時刻を管理できる。エンジン３２０は、最初の到着時刻００：００：０１から１回目の発火時刻００：００：０５を算出し、その発火時刻にオペレータ３１１ａに対してタイマー通知を発行する（Ｓ３）。同様に、エンジン３２０ａは、最初の到着時刻から１回目の発火時刻を算出し、その発火時刻にオペレータ３１２ａに対してタイマー通知を発行する（Ｓ３ａ）。エンジン３２０ｂは、最初の到着時刻から１回目の発火時刻を算出し、その発火時刻にオペレータ３１３ａに対してタイマー通知を発行する（Ｓ３ｂ）。
【００８０】
このように、エンジン３２０，３２０ａ，３２０ｂは、時間ベースオペレータからタイマー依頼を受け付けると、同じ種類の複数のクエリについて単一の最初の到着時刻を決定する。これにより、エンジン３２０，３２０ａ，３２０ｂ上の時間ベースオペレータに対するタイマー通知の発行タイミングを揃えることができる。
【００８１】
クエリ３１１，３１２，３１３のうちの２つ以上が同時期にイベントを受信した場合には、エンジン３２０，３２０ａ，３２０ｂの間で、各クエリにとっての到着時刻の情報が相互に送信されることになる。この場合、エンジン３２０，３２０ａ，３２０ｂの間で最初の到着時刻を確定するための手続が行われる。以下、図１０〜１１を用いて、最初の到着時刻の確定手続について、具体的に説明する。
【００８２】
図１０は、最初の到着時刻の確定手続の例を示す図である。
（Ｓ３１）エンジン３２０ａは、クエリ３１２のオペレータ３１２ａからタイマー依頼を受信する。このタイマー依頼には、到着時刻００：００：０１が指定されている。エンジン３２０ａは、００：００：０１をクエリ３１１，３１２，３１３についての最初の到着時刻の候補として仮登録しておく。仮登録された到着時刻は、後に更新され得る。
【００８３】
（Ｓ３２，Ｓ３２ａ）エンジン３２０ａは、仮登録した到着時刻００：００：０１が最も早い到着時刻であるか確認するための確認通知を、エンジン３２０，３２０ｂに送信する。この確認通知には、到着時刻００：００：０１の情報が含まれる。
【００８４】
（Ｓ３３）エンジン３２０は、クエリ３１１のオペレータ３１１ａからタイマー依頼を受信する。このタイマー依頼には、到着時刻００：００：０２が指定されている。エンジン３２０は、００：００：０２をクエリ３１１，３１２，３１３についての最初の到着時刻の候補として仮登録しておく。仮登録された到着時刻は、後に更新され得る。
【００８５】
（Ｓ３４，Ｓ３４ａ）エンジン３２０は、仮登録した到着時刻００：００：０２が最も早い到着時刻であるか確認するための確認通知を、エンジン３２０ａ，３２０ｂに送信する。この確認通知には、到着時刻００：００：０２の情報が含まれる。
【００８６】
（Ｓ３５）エンジン３２０ａは、エンジン３２０から確認通知を受信する。すると、エンジン３２０ａは、受信した確認通知で指定された到着時刻が、エンジン３２０ａに仮登録されている到着時刻より早い（小さい）か判定する。確認通知の到着時刻が仮登録された到着時刻より早いかまたは仮登録された到着時刻が存在しない場合、エンジン３２０ａは、許可通知を返信し、確認通知で指定された到着時刻をエンジン３２０ａに仮登録する。それ以外の場合、すなわち、確認通知の到着時刻が仮登録された到着時刻より遅い（大きい）かまたは同じである場合、エンジン３２０ａは、拒否通知を返信する。ここでは、確認通知で指定された到着時刻００：００：０２がエンジン３２０ａに仮登録された到着時刻００：００：０１より遅いため、エンジン３２０に拒否通知を送信する。
【００８７】
（Ｓ３５ａ）エンジン３２０ｂは、エンジン３２０から確認通知を受信する。すると、エンジン３２０ａと同様に、受信した確認通知で指定された到着時刻と仮登録された到着時刻とを比較する。ここでは、エンジン３２０ｂに仮登録された到着時刻がないため、エンジン３２０ｂは、確認通知で指定された到着時刻００：００：０２をエンジン３２０ｂに仮登録し、許可通知をエンジン３２０に送信する。
【００８８】
エンジン３２０は、エンジン３２０ａ，３２０ｂから、確認通知に対する応答として許可通知または拒否通知を受信する。全ての応答が受信されると、エンジン３２０は、応答の中に拒否通知が含まれているか判定する。１つでも拒否通知を受信した場合、エンジン３２０は、クエリ３１１よりも早くイベントを受信した他の同種のクエリが存在するため、クエリ３１１の到着時刻を最初の到着時刻としない。一方、１つも拒否通知を受信しなかった（許可通知のみ受信した）場合、エンジン３２０は、仮登録した到着時刻を最初の到着時刻として決定する。ここでは、エンジン３２０は、エンジン３２０ａから拒否通知を受信しているため、クエリ３１１の到着時刻を最初の到着時刻としない。
【００８９】
（Ｓ３６）エンジン３２０は、エンジン３２０ａから確認通知を受信する。ここでは、確認通知で指定された到着時刻００：００：０１がエンジン３２０に仮登録された到着時刻００：００：０２より早いため、エンジン３２０は、エンジン３２０に仮登録した到着時刻を００：００：０１に更新し、許可通知をエンジン３２０ａに送信する。
【００９０】
（Ｓ３６ａ）エンジン３２０ｂは、エンジン３２０ａから確認通知を受信する。ここでは、確認通知で指定された到着時刻００：００：０１がエンジン３２０ｂに仮登録された到着時刻００：００：０２より早いため、エンジン３２０ｂは、エンジン３２０ｂに仮登録し到着時刻を００：００：０１に更新し、許可通知をエンジン３２０ａに送信する。
【００９１】
（Ｓ３７，Ｓ３７ａ）エンジン３２０ａは、エンジン３２０，３２０ｂから許可通知を受信する。すると、エンジン３２０ａは、エンジン３２０ａに仮登録されている到着時刻００：００：０１を最初の到着時刻と決定し（仮登録を本登録に切り替え）、エンジン３２０，３２０ｂに確定通知を送信する。確定通知を受信したエンジン３２０，３２０ｂは、仮登録されている到着時刻００：００：０１を最初の到着時刻とする（本登録する）。
【００９２】
このようにして、同じ種類の２以上のクエリが同時期にイベントを受信した場合、上記のような確定手続を通じて、客観的な最初の到着時刻が確定される。
しかし、上記の確定手続は通信のオーバヘッドを伴う。そのため、時間ベースオペレータから指定される待機時間（到着時刻から１回目の発火時刻までの時間）が短い場合、１回目のタイマー通知までにエンジン３２０，３２０ａ，３２０ｂの間で確定手続を完了できないことも有り得る。そこで、エンジン３２０，３２０ａ，３２０ｂそれぞれは、「特定時刻」までに確定手続を完了できない場合には、現在の仮登録の到着時刻を最初の到着時刻であると仮定して、暫定的に１回目のタイマー通知を発行する。
【００９３】
「特定時刻」は、１回目のタイマー通知を発行するために仮登録の到着時刻を基準時刻として使用するか否か決定する期限である。特定時刻は、現在の仮登録の到着時刻に基づいて算出される仮の発火時刻（仮登録の到着時刻に待機時間を加えた時刻）であってもよい。また、特定時刻は、仮の発火時刻から「最低特定時間」だけ早い時刻であってもよい。
【００９４】
「最低特定時間」を設けることで、エンジン３２０，３２０ａ，３２０ｂは余裕をもって１回目のタイマー通知の発行を準備することができ、発行タイミングの精度を確保することができる。最低特定時間は、所定の固定値でもよい。また、最低特定時間は、エンジン３２０，３２０ａ，３２０ｂの間の通信のオーバヘッドに基づいて算出される時間であってもよい。一のエンジンが他の一のエンジンから確認通知を受け取った後、その確認通知で指定された到着時刻を最初の到着時刻として確定させるには、その２つのエンジン間で許可通知と確定通知を送信することになる。現在時刻と仮の発火時刻との間隔が、予想される通信の往復時間より短い場合、仮の発火時刻までに最初の到着時刻を確定させることができないと判断することができる。そこで、最低特定時間を、確認通知の送信元エンジンとの間の予想される通信の往復時間とすることが考えられる。
【００９５】
図１１は、特定時刻経過時の暫定タイマー通知の例を示す図である。図１１では、待機時間を４秒とし、最低特定時間を２秒としている。仮登録の到着時刻から４秒後が仮の発火時刻になり、仮の発火時刻の２秒前（仮登録の到着時刻から２秒後）が特定時刻になる。
【００９６】
エンジン３２０は、クエリ３１１のオペレータ３１１ａから到着時刻００：００：０２を指定したタイマー依頼を受け付けると、到着時刻００：００：０２を仮登録してエンジン３２０ａ，３２０ｂに確認通知を送信する。エンジン３２０ａは、クエリ３１２のオペレータ３１２ａから到着時刻００：００：０１を指定したタイマー依頼を受け付けると、到着時刻００：００：０１を仮登録してエンジン３２０，３２０ｂに確認通知を送信する。
【００９７】
エンジン３２０から送信された確認通知は、００：００：０３より前にエンジン３２０ａ，３２０ｂに到着している。一方、エンジン３２０ａから送信された確認通知は、００：００：０４より後にエンジン３２０，３２０ｂに到着している。この場合において、エンジン３２０，３２０ｂに最初に仮登録されるのは到着時刻００：００：０２であり、特定時刻は００：００：０４になる。一方、エンジン３２０ａに最初に仮登録されるのは到着時刻００：００：０１であり、特定時刻は００：００：０３になる。
【００９８】
エンジン３２０，３２０ａ，３２０ｂの何れにおいても、特定時刻までに最初の到着時刻が確定しない。そこで、エンジン３２０，３２０ｂは、特定時刻００：００：０４の時点で、仮登録された到着時刻に基づいて決まる仮の発火時刻００：００：０６に１回目のタイマー通知を発行すると決定する。また、エンジン３２０ａは、特定時刻００：００：０３の時点で、仮登録された到着時刻に基づいて決まる仮の発火時刻００：００：０５に１回目のタイマー通知を発行すると決定する。１回目のタイマー通知は、最初の到着時刻の確定が間に合わないため、エンジン３２０，３２０ａ，３２０ｂの間で統一されていない。
【００９９】
ただし、１回目のタイマー通知の発行と並行して、図１０に示したような確定手続が進められる。よって、エンジン３２０，３２０ａ，３２０ｂが１回目のタイマー通知を発行した後、最初の到着時刻００：００：０１が確定する。すると、エンジン３２０，３２０ａ，３２０ｂは、２回目以降のタイマー通知を、確定した最初の到着時刻に基づいて発行する。発火間隔（２回目以降のタイマー通知の発行間隔）を４秒とすると、エンジン３２０，３２０ａ，３２０ｂは、００：００：０９に２回目のタイマー通知を発行する。
【０１００】
このように、エンジン３２０，３２０ａ，３２０ｂは、特定時刻までに最初の到着時刻を確定できない場合、仮登録されている到着時刻を基準時刻として用いて１回目のタイマー通知を暫定的に発行する。よって、１回目のタイマー通知を発行し損ねることを回避できる。また、最初の到着時刻の確定手続が完了することで、エンジン３２０，３２０ａ，３２０ｂは、２回目以降のタイマー通知を同じタイミングで発行することができる。
【０１０１】
なお、特定時刻までに確定手続が完了できないことは、タイマー依頼で指定された待機時間が非常に短いときに発生する。そのため、エンジン３２０，３２０ａ，３２０ｂの間で１回目のタイマー通知の発行タイミングがずれる量は、十分に小さいと期待できる。
【０１０２】
次に、エンジンノード３００，３００ａ，３００ｂの機能について説明する。
図１２は、エンジンノードの機能例を示すブロック図である。エンジンノード３００は、クエリ３１０，３１１、状態記憶部３１０ｂ，３１１ｂ、エンジン３２０および管理情報記憶部３３０を有する。エンジン３２０は、タイマー管理部３４０、イベント管理部３５０および通信部３６０を有する。エンジン３２０は、プロセッサ３０１が実行するプログラムのモジュールとして実装できる。状態記憶部３１０ｂ，３１１ｂおよび管理情報記憶部３３０は、ＲＡＭ３０２またはＨＤＤ３０３に確保した記憶領域として実装できる。エンジンノード３００ａ，３００ｂも、エンジンノード３００と同様の機能を有する。
【０１０３】
クエリ３１０は、オペレータ３１０ａを有する。オペレータ３１０ａは、時間ベースオペレータでもよいし時間ベースオペレータ以外のオペレータでもよい。クエリ３１１は、時間ベースオペレータであるオペレータ３１１ａを有する（図１２では省略）。
【０１０４】
状態記憶部３１０ｂは、クエリ３１０に対応して設けられ、クエリ３１０の内部状態を示す情報を記憶する。内部状態の情報には、一時的に蓄積したイベントや、クエリ３１０が担当するデータ範囲（例えば、クエリ３１０に振り分けられるイベントに含まれる識別子の範囲）を示す情報が含まれる。状態記憶部３１１ｂは、クエリ３１１に対応して設けられ、クエリ３１１の内部状態を示す情報を記憶する。
【０１０５】
このように、各エンジンノードには複数のクエリを配置することができ、配置されたクエリ毎に内部状態の情報を記憶する状態記憶部が設けられる。エンジンノード毎に１つのエンジンが、当該エンジンノード上の複数のクエリおよび状態記憶部を管理する。
【０１０６】
管理情報記憶部３３０は、タイマー依頼に関する情報を格納する共有管理テーブル、タイマー通知に関する情報を格納するイベント管理テーブル、および、イベントの配信先に関する情報を格納するルーティングテーブルを含む管理情報を記憶する。
【０１０７】
タイマー管理部３４０は、タイマー通知の発行を管理する。タイマー管理部３４０は、依頼受信部３４１、共有部３４２および生成部３４３を有する。
依頼受信部３４１は、エンジンノード３００に配置されたクエリの時間ベースオペレータ（例えば、クエリ３１１のオペレータ３１１ａ）からタイマー依頼を受け付ける。タイマー依頼には、到着時刻・待機時間・発火間隔・発火上限回数等の情報が含まれる。
【０１０８】
共有部３４２は、依頼受信部３４１がタイマー依頼を受け付けると、タイマー依頼に含まれる情報を、管理情報記憶部３３０に記憶された共有管理テーブルに登録する。このとき、共有部３４２は、タイマー依頼で指定された到着時刻を仮登録の到着時刻として扱う。そして、共有部３４２は、仮登録した到着時刻について確認通知を生成し、イベント管理部３５０および通信部３６０を介してエンジンノード３００ａ，３００ｂに送信する。確認通知の送信先は、タイマー依頼の送信元と同種のクエリが配置されたエンジンノードであり、管理情報記憶部３３０に記憶されたルーティングテーブルを参照して検索することができる。ただし、確認通知は、ネットワーク３１にブロードキャストされてもよいし、全ての他のエンジンノードに対して送信されるようにしてもよい。
【０１０９】
また、共有部３４２は、確認通知に対する応答として許可通知または拒否通知を、通信部３６０およびイベント管理部３５０を介してエンジンノード３００ａ，３００ｂから受信する。すると、共有部３４２は、受信した応答に基づいて、仮登録した到着時刻を最初の到着時刻として確定するか判定する。最初の到着時刻を確定する場合、共有部３４２は、仮登録の到着時刻を本登録として扱い、管理情報記憶部３３０に記憶されたイベント管理テーブルに、１回目の発火時刻・発火間隔・発火上限回数等を登録する。そして、共有部３４２は、エンジンノード３００ａ，３００ｂに確定通知を送信する。
【０１１０】
また、共有部３４２は、通信部３６０およびイベント管理部３５０を介して確認通知を受信すると、確認通知で指定された到着時刻とエンジンノード３００における仮登録の到着時刻とを比較する。前者が後者より早い（小さい）場合、共有部３４２は、仮登録の到着時刻を確認通知で指定されたものに更新し、許可通知を返信する。それ以外の場合、共有部３４２は、拒否通知を返信する。また、共有部３４２は、通信部３６０およびイベント管理部３５０を介して確定通知を受信すると、仮登録の到着時刻を本登録として扱い、イベント管理テーブルに１回目の発火時刻・発火間隔・発火上限回数等を登録する。
【０１１１】
また、共有部３４２は、到着時刻を仮登録してから本登録するまでの間に特定時刻が到来すると、１回目のタイマー通知の発行のために、１回目の発火時刻・発火間隔・発火上限回数等をイベント管理テーブルに仮登録する。なお、共有部３４２は、時間ベースオペレータからタイマー依頼の変更や取消を受け付けてもよい。その場合、共有部３４２は、その変更や取消を共有管理テーブルやイベント管理テーブル等に反映してもよい。
【０１１２】
生成部３４３は、管理情報記憶部３３０に記憶されたイベント管理テーブルを参照して、適切なタイミングでタイマー通知を生成し、イベント管理部３５０に出力する。
イベント管理部３５０は、エンジン３２０とエンジンノード３００上のクエリ間でのイベントの配信、および、エンジンノード間でのイベントの配信を管理する。イベント管理部３５０は、振分部３５１および配信部３５２を有する。
【０１１３】
振分部３５１は、タイマー管理部３４０から、イベントの一種としてタイマー通知を取得する。すると、振分部３５１は、管理情報記憶部３３０に記憶されたルーティングテーブルを参照して、タイマー通知の配信先の時間ベースオペレータを判定する。また、振分部３５１は、タイマー管理部３４０から、イベントの一種として確認通知・許可通知・拒否通知・確定通知等のイベント制御通知を取得すると、ルーティングテーブルを参照して送信先のエンジンノードを判定し、通信部３６０にイベント制御通知を渡す。また、振分部３５１は、通信部３６０から取得したイベント制御通知をタイマー管理部３４０に渡す。
【０１１４】
また、振分部３５１は、クエリ３１０〜３１４の間で受け渡されるデータとしてのイベントの配信を制御する。振分部３５１は、通信部３６０からデータとしてのイベントを取得すると、ルーティングテーブルおよび状態記憶部３１０ｂ，３１１ｂに記憶された担当データ範囲の情報を参照して、当該イベントの配信先のクエリを判定する。また、振分部３５１は、クエリ３１０，３１１からデータとしてのイベントを取得すると、ルーティングテーブルを参照して送信先のエンジンノードを判定し、通信部３６０にイベントを渡す。
【０１１５】
配信部３５２は、振分部３５１により判定された配信先がエンジンノード３００に存在する場合、イベントを配信先のクエリまたは時間ベースオペレータに渡す。
通信部３６０は、ネットワーク３１を介してエンジンノード３００ａ，３００ｂと通信する。通信部３６０は、イベント管理部３５０からイベント制御通知やデータとしてのイベントを取得すると、イベント管理部３５０から指定されたエンジンノードに送信する。また、通信部３６０は、エンジンノード３００ａ，３００ｂからイベント制御通知やデータとしてのイベントを受信すると、イベント管理部３５０に渡す。
【０１１６】
図１３は、共有管理テーブルの例を示す図である。共有管理テーブル３３１は、タイマー依頼に関する情報を格納する。共有管理テーブル３３１は、管理情報記憶部３３０に記憶されている。共有管理テーブル３３１は、クエリ名、オペレータ名、到着時刻、待機時間、発火間隔、発火上限回数、最低特定時間および登録種別の項目を有する。
【０１１７】
クエリ名の項目には、タイマー依頼を送信したクエリの種類を示す識別子が設定される。クエリ名は、クエリプログラムの識別子と言うこともできる。同じクエリプログラムから起動された同じ種類のクエリには、同じクエリ名が付与されている。オペレータ名の項目には、タイマー依頼を送信したオペレータの種類を示す識別子が設定される。オペレータ名は、クエリプログラムに含まれる演算子の識別子と言うこともできる。同じ種類のクエリに含まれる同じ種類のオペレータには、同じオペレータ名が付与されている。
【０１１８】
到着時刻の項目には、タイマー依頼で指定された到着時刻が設定される。この到着時刻は、タイマー依頼を送信したクエリに１つ目のイベントが到着した時刻を示す。待機時間の項目には、タイマー依頼で指定された待機時間が設定される。発火間隔の項目には、タイマー依頼で指定された発火間隔（２回目以降のタイマー通知の発行間隔）が設定される。発火上限回数の項目には、タイマー依頼で指定された発火上限回数（タイマー通知の最大の発行回数）が設定される。待機時間・発火間隔・発火上限回数はクエリプログラムに記述されているため、同じ種類のオペレータは同じ待機時間・発火間隔・発火上限回数を指定する。なお、時間ベースオペレータがタイマー通知を１回だけ要求する場合には、タイマー依頼に発火間隔や発火上限回数の情報が含まれていないこともある。
【０１１９】
最低特定時間の項目には、特定時刻を算出するための最低特定時間が設定される。特定時刻を１回目の発火時刻とする場合、最低特定時間を０とすればよい。最低特定時間を正の固定値にする場合、その固定値を最低特定時間の項目に設定すればよい。最低特定時間を通信状況等に応じた可変値にする場合、算出した可変値を最低特定時間の項目に設定する。例えば、共有部３４２は、他のエンジンノードから確認通知を受信した時刻と確認通知で指定された到着時刻との差を通知遅延時間として算出し、通知遅延時間の２倍を最低特定時間とする。なお、最低特定時間は待機時間以下とする。
【０１２０】
登録種別の項目には、到着時刻の確定状態が設定される。最初の到着時刻が未確定であれば「仮登録」が設定され、確定済であれば「本登録」が設定される。
図１４は、イベント管理テーブルの例を示す図である。イベント管理テーブル３３２は、タイマー通知に関する情報を格納する。イベント管理テーブル３３２は、管理情報記憶部３３０に記憶されている。イベント管理テーブル３３２は、クエリ名、オペレータ名、初回発火時刻、発火間隔、発火上限回数、発火済回数および登録種別の項目を有する。
【０１２１】
クエリ名、オペレータ名、発火間隔および発火上限回数の項目には、共有管理テーブル３３１に登録されているものがコピーされる。初回発火時刻の項目には、最初の到着時刻と待機時間から算出される１回目の発火時刻が設定される。発火済回数の項目には、生成部３４３がタイマー通知を生成した回数が設定される。生成部３４３は、発火済回数が発火上限回数に達するまで、発火間隔に従って繰り返しタイマー通知を生成する。
【０１２２】
登録種別の項目には、初回発火時刻の確定状況が設定される。特定時刻を経過しても最初の到着時刻を確定できないために暫定的に１回目のタイマー通知が発行される場合、登録種別の項目に「仮登録」が設定される。それ以外の場合、すなわち、最初の到着時刻が確定された場合には、登録種別の項目に「本登録」が設定される。
【０１２３】
図１５は、ルーティングテーブルの例を示す図である。ルーティングテーブル３３３は、イベントの配信先に関する情報を格納する。ルーティングテーブル３３３は、管理情報記憶部３３０に記憶されている。ルーティングテーブル３３３は、イベント名、クエリ名、オペレータ名およびノード名の項目を有する。
【０１２４】
イベント名の項目には、イベントの種類を示す識別子が設定される。クエリ３１０〜３１４の間で受け渡されるデータ、タイマー通知およびイベント制御通知は、イベントの一種である。図１５において、Ｅｖｅｎｔ１，Ｅｖｅｎｔ２はデータに相当するイベントを示し、ＴｉｍｅＥｖｅｎｔ１，ＴｉｍｅＥｖｅｎｔ２はタイマー通知を示し、ＴｉｍｅＥｖｅｎｔ＿Ｃｔｌ１，ＴｉｍｅＥｖｅｎｔ＿Ｃｔｌ２はイベント制御通知を示す。
【０１２５】
クエリ名の項目には、イベント配信先のクエリの種類を示す識別子が設定される。オペレータ名の項目には、イベントを受け取るオペレータの種類を示す識別子が設定される。ノード名の項目には、クエリが配置されているエンジンノードの識別子が設定される。並列化のため同じ種類のクエリが複数のエンジンノードに配置されている場合、１つのクエリ名に対して複数のノード名が登録される。なお、エンジン３２０はタイマー通知を他のエンジンノードに直接配信することがないため、図１５のルーティングテーブル３３３では、タイマー通知に対応するノード名がＬｏｃａｌに設定されている。
【０１２６】
図１６は、タイマー依頼の例を示す図である。オペレータ３１１ａ等の時間ベースオペレータは、タイマー管理部３４０にタイマー依頼６１を送信する。タイマー依頼６１は、クエリ名、オペレータ名、到着時刻、待機時間、発火間隔および発火上限回数の項目を有する。
【０１２７】
クエリ名、オペレータ名、到着時刻、待機時間、発火間隔および発火上限回数は、前述の共有管理テーブル３３１に登録されるものである。タイマー依頼６１に含まれるクエリ名およびオペレータ名は、タイマー依頼６１の送信元を示す。タイマー依頼６１で指定される到着時刻は、タイマー依頼６１の送信元に１つ目のイベントが到着した時刻である。
【０１２８】
図１７は、イベント制御通知の例を示す図である。イベント制御通知６２は、最初の到着時刻を確定するためにエンジンノード３００，３００ａ，３００ｂの間で送信される。イベント制御通知６２は、クエリ名、オペレータ名、送信元、制御種別、到着時刻、待機時間、発火間隔および発火上限回数の項目を有する。
【０１２９】
クエリ名、オペレータ名、到着時刻、待機時間、発火間隔および発火上限回数は、共有管理テーブル３３１に仮登録されたものである。送信元の項目には、イベント制御通知６２を送信したエンジンノードの識別子が設定される。制御種別の項目には、イベント制御通知６２の種類として、確認・許可・拒否・確定の何れかが設定される。
【０１３０】
次に、図１８〜２１を用いて、到着時刻を共通化する処理についてフローチャートを用いて説明する。以下では、エンジンノード３００が図１８〜２１の処理を実行するものとして説明する。エンジンノード３００ａ，３００ｂも、エンジンノード３００と同様の処理を実行する。なお、図１８〜２１の処理は互いに独立に実行される。
【０１３１】
図１８は、到着時刻共通化の送信側処理の例を示すフローチャートである。
（Ｓ１０１）依頼受信部３４１は、タイマー依頼６１を受信する。
（Ｓ１０２）共有部３４２は、管理情報記憶部３３０に記憶されたルーティングテーブル３３３を参照して、タイマー依頼６１の送信元と同じ種類のクエリが配置されている他のエンジンノードを検索する。例えば、共有部３４２は、イベント制御通知を示すイベント名（図１５の「＿Ｃｔｌ」が付されたもの）およびタイマー依頼６１で指定されたクエリ名・オペレータ名に対応するノード名をルーティングテーブル３３３から抽出する。
【０１３２】
（Ｓ１０３）共有部３４２は、ステップＳ１０２で１つ以上の他のエンジンノードが検索されたか、すなわち、タイマー依頼６１の送信元のクエリが並列化されているか判断する。送信元のクエリが並列化されている場合はステップＳ１０５に処理を進め、送信元のクエリが並列化されていない場合はステップＳ１０４に処理を進める。
【０１３３】
（Ｓ１０４）共有部３４２は、タイマー依頼６１で指定された到着時刻と待機時間から初回発火時刻を算出する（到着時刻に待機時間を加えた時刻を初回発火時刻とする）。そして、共有部３４２は、管理情報記憶部３３０に記憶されたイベント管理テーブル３３２に、タイマー依頼６１で指定されたクエリ名・オペレータ名・発火間隔・発火上限回数と算出した初回発火時刻とを「本登録」として登録する。そして、処理が終了する。
【０１３４】
（Ｓ１０５）共有部３４２は、タイマー依頼６１で指定されたクエリ名およびオペレータ名を含むレコードが、管理情報記憶部３３０に記憶された共有管理テーブル３３１に、本登録または仮登録として登録済であるか判断する。登録済である場合はタイマー依頼６１が破棄されて処理が終了し、未登録である場合はステップＳ１０６に処理が進む。
【０１３５】
（Ｓ１０６）共有部３４２は、最低特定時間を算出する。ここで用いる最低特定時間は、予め決めた固定値でもよいし、ステップＳ１０２で検索された他のエンジンノードとの間の過去の通信時間に基づいて算出するようにしてもよい。
【０１３６】
（Ｓ１０７）共有部３４２は、共有管理テーブル３３１に、タイマー依頼６１で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とステップＳ１０６で算出した最低特定時刻とを「仮登録」として登録する。
【０１３７】
（Ｓ１０８）共有部３４２は、制御種別が「確認」であるイベント制御通知（確認通知）を生成する。確認通知には、タイマー依頼６１で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とエンジンノード３００のノード名が記載される。共有部３４２は、イベント管理部３５０および通信部３６０を介して、ステップＳ１０２で検索した他のエンジンノードに確認通知を送信する。ただし、確認通知は、全てのエンジンノードにブロードキャストするようにしてもよい。
【０１３８】
（Ｓ１０９）共有部３４２は、通信部３６０およびイベント管理部３５０を介して、確認通知の送信先の他のエンジンノードからイベント制御通知を受信する。このとき、イベント管理部３５０の振分部３５１は、例えば、通信部３６０から取得したイベントの識別子に基づいて当該イベントがイベント制御通知であるか判定し、イベント制御通知を共有部３４２に渡すようにする。共有部３４２は、受信したイベント制御通知の全てが許可通知であるか判断する。全てのイベント制御通知が許可通知である場合、ステップＳ１１０に処理が進む。１以上のイベント制御通知が拒否通知である場合、処理を終了する。
【０１３９】
（Ｓ１１０）共有部３４２は、共有管理テーブル３３１から、許可通知で指定されたクエリ名およびオペレータ名を含むレコード（ステップＳ１０７で仮登録したレコード）を検索し、検索したレコードを「仮登録」から「本登録」に書き換える。
【０１４０】
（Ｓ１１１）共有部３４２は、ステップＳ１１０で「本登録」にした共有管理テーブル３３１のレコードに記載された到着時刻と待機時間から、初回発火時刻を算出する。そして、共有部３４２は、イベント管理テーブル３３２に、当該レコードに記載されたクエリ名・オペレータ名・発火間隔・発火上限回数と算出した初回発火時刻とを「本登録」として登録する。ただし、後述するように、本登録しようとするクエリ名・オペレータ名等がイベント管理テーブル３３２に仮登録されていることがある。その場合、共有部３４２は、仮登録されているイベント管理テーブル３３２のレコードを「本登録」にすればよい。
【０１４１】
（Ｓ１１２）共有部３４２は、制御種別が「確定」であるイベント制御通知（確定通知）を生成する。確定通知には、ステップＳ１１０で共有管理テーブル３３１に本登録されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数が含まれる。共有部３４２は、イベント管理部３５０および通信部３６０を介して、全てのエンジンノードに確定通知を送信する。ただし、各通知は、全てのエンジンノードにブロードキャストするようにしてもよい。
【０１４２】
図１９は、到着時刻共通化の受信側処理の例を示すフローチャートである。
（Ｓ１２１）共有部３４２は、通信部３６０およびイベント管理部３５０を介して、他のエンジンノードから、制御種別が「確認」であるイベント制御通知（確認通知）を受信する。このとき、イベント管理部３５０の振分部３５１は、例えば、通信部３６０から取得したイベントの識別子に基づいて当該イベントがイベント制御通知であるか判定し、イベント制御通知を共有部３４２に渡すようにする。
【０１４３】
（Ｓ１２２）共有部３４２は、確認通知で指定されたクエリ名およびオペレータ名を含むレコードが、管理情報記憶部３３０に記憶された共有管理テーブル３３１に本登録されているか判断する。本登録されている場合はステップＳ１２３に処理が進み、本登録されていない（仮登録されているか登録がない）場合はステップＳ１２４に処理が進む。
【０１４４】
（Ｓ１２３）共有部３４２は、制御種別が「拒否」であるイベント制御通知（拒否通知）を生成する。拒否通知には、確認通知で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とエンジンノード３００のノード名が記載される。共有部３４２は、イベント管理部３５０および通信部３６０を介して、確認通知の送信元の他のエンジンノードに対して拒否通知を返信する。そして、処理が終了する。
【０１４５】
（Ｓ１２４）共有部３４２は、確認通知で指定されたクエリ名およびオペレータ名を含むレコードが、共有管理テーブル３３１に仮登録されているか判断する。仮登録されている場合はステップＳ１２５に処理が進み、仮登録されていない（該当するレコードが存在しない）場合はステップＳ１２７に処理が進む。
【０１４６】
（Ｓ１２５）共有部３４２は、確認通知で指定された到着時刻と共有管理テーブル３３１に仮登録されている到着時刻とを比較する。
（Ｓ１２６）共有部３４２は、ステップＳ１２５の比較の結果、確認通知で指定された到着時刻が共有管理テーブル３３１に仮登録された到着時刻より早い（小さい）か判断する。前者が後者より早い場合はステップＳ１２７に処理が進み、それ以外の場合（前者が後者より遅い（大きい）か同じ場合）はステップＳ１２３に処理が進む。
【０１４７】
（Ｓ１２７）共有部３４２は、最低特定時間を算出する。最低特定時間は、固定値でもよいし可変値でもよい。後者の場合、例えば、共有部３４２は、確認通知で指定された到着時刻と確認通知の受信時刻とから最低特定時間を算出する。最低特定時間＝（確認通知の受信時刻−確認通知で指定された到着時刻）×２とすることが考えられる。これは、エンジンノード３００と確認通知の送信元との間の通信の往復時間を意味し、確認通知の後に許可通知と確定通知とを送信するのに要する時間に相当する。最低特定時間より短い時間では、最初の到着時刻の確定手続を完了できないことが予想される。
【０１４８】
（Ｓ１２８）共有部３４２は、受信した確認通知に関する情報を共有管理テーブル３３１に仮登録する。ステップＳ１２４で仮登録のレコードが検索されなかった場合、共有部３４２は、共有管理テーブル３３１に、確認通知で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とステップＳ１２７で算出した最低特定時刻とを「仮登録」として登録する。ステップＳ１２４で仮登録のレコードが検索された場合、共有部３４２は、仮登録の到着時刻を確認通知で指定されたものに更新し、最低特定時間をステップＳ１２７で算出されたものに更新する。
【０１４９】
（Ｓ１２９）共有部３４２は、制御種別が「許可」であるイベント制御通知（許可通知）を生成する。許可通知には、確認通知で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とエンジンノード３００のノード名が記載される。共有部３４２は、イベント管理部３５０および通信部３６０を介して、確認通知の送信元の他のエンジンノードに対して許可通知を返信する。
【０１５０】
図２０は、確定通知受信時の処理の例を示すフローチャートである。
（Ｓ１３１）共有部３４２は、通信部３６０およびイベント管理部３５０を介して、他のエンジンノードから、制御種別が「確定」であるイベント制御通知（確定通知）を受信する。このとき、イベント管理部３５０の振分部３５１は、例えば、通信部３６０から取得したイベントの識別子に基づいて当該イベントがイベント制御通知であるか判定し、イベント制御通知を共有部３４２に渡すようにする。
【０１５１】
（Ｓ１３２）共有部３４２は、確定通知で指定されたクエリ名およびオペレータ名を含む仮登録のレコードを、管理情報記憶部３３０に記憶された共有管理テーブル３３１から検索する。共有部３４２は、検索されたレコードを仮登録から本登録に変更する。
【０１５２】
（Ｓ１３３）共有部３４２は、ステップＳ１３２で共有管理テーブル３３１に本登録した到着時刻と待機時間から、初回発火時刻を算出する。そして、共有部３４２は、イベント管理テーブル３３２に、共有管理テーブル３３１に本登録したクエリ名・オペレータ名・発火間隔・発火上限回数と算出した初回発火時刻とを「本登録」として登録する。ただし、後述するように、本登録しようとするクエリ名・オペレータ名等がイベント管理テーブル３３２に仮登録されていることがある。その場合、共有部３４２は、仮登録されているイベント管理テーブル３３２のレコードを「本登録」にすればよい。
【０１５３】
図２１は、特定時刻経過時の処理の例を示すフローチャートである。
（Ｓ１４１）共有部３４２は、共有管理テーブル３３１から、現在時刻が特定時刻を経過した仮登録のレコードを検索する。特定時刻は、仮登録の到着時刻を基準時刻として用いた場合の１回目の発火時刻から最低特定時間だけ遡った時刻である。具体的には、特定時刻＝到着時刻＋待機時間−最低特定時間と算出することができる。
【０１５４】
（Ｓ１４２）共有部３４２は、ステップＳ１４１において、現在時刻が特定時刻を経過した仮登録のレコードが検索されたか判断する。検索された場合にはステップＳ１４３に処理が進み、検索されなかった場合はステップＳ１４１に処理が進む。
【０１５５】
（Ｓ１４３）共有部３４２は、ステップＳ１４１で検索された共有管理テーブル３３１の仮登録のレコードに記載された到着時刻と待機時間から、暫定の初回発火時刻を算出する。そして、共有部３４２は、イベント管理テーブル３３２に、共有管理テーブル３３１に仮登録されているクエリ名・オペレータ名・発火間隔・発火上限回数と算出した暫定の初回発火時刻とを「仮登録」として登録する。これにより、仮の到着時刻に基づいて、生成部３４３により１回目のタイマー通知が暫定的に発行される。
【０１５６】
次に、図２２〜２３を用いて、最初の到着時刻の確定手続のシーケンス例について説明する。以下の図２２〜２３の説明では、エンジンノード３００が確認通知を送信し、エンジンノード３００ａが確認通知を受信する場合を考える。
【０１５７】
図２２は、確認通知が許可される場合のシーケンス例を示す図である。
（Ｓ２０１）エンジン３２０は、時間ベースオペレータであるクエリ３１１のオペレータ３１１ａから、タイマー依頼６１を受信する。
【０１５８】
（Ｓ２０２）エンジン３２０は、タイマー依頼６１で指定された到着時刻等を、エンジンノード３００に記憶された共有管理テーブル３３１へ仮登録する。
（Ｓ２０３）エンジン３２０は、ステップＳ２０２で共有管理テーブル３３１へ仮登録した到着時刻等を記載した確認通知を、エンジンノード３００ａに送信する。
【０１５９】
（Ｓ２０４）エンジン３２０ａは、受信した確認通知で指定された到着時刻とエンジンノード３００ａに記憶された共有管理テーブルに登録されている到着時刻とを比較する。ここでは、エンジンノード３００ａの共有管理テーブルにオペレータ３１１ａに関する到着時刻等が登録されていないか、または、確認通知で指定された到着時刻がエンジンノード３００ａの共有管理テーブルに仮登録されたものより早いとする。すると、エンジン３２０ａは、エンジンノード３００ａの共有管理テーブルに到着時刻等を仮登録する。
【０１６０】
（Ｓ２０５）エンジン３２０ａは、許可通知をエンジンノード３００に送信する。
（Ｓ２０６）エンジン３２０は、ステップＳ２０２でエンジンノード３００の共有管理テーブル３３１へ仮登録した到着時刻等を本登録する。
【０１６１】
（Ｓ２０７）エンジン３２０は、確定通知をエンジンノード３００ａに送信する。
（Ｓ２０８）エンジン３２０ａは、ステップＳ２０４でエンジンノード３００ａの共有管理テーブルへ仮登録した到着時刻等を本登録する。これにより、エンジンノード３００，３００ａの間で共通の「最初の到着時刻」が確定する。
【０１６２】
図２３は、確認通知が拒否される場合のシーケンス例を示す図である。
（Ｓ２１１）エンジン３２０は、時間ベースオペレータであるクエリ３１１のオペレータ３１１ａから、タイマー依頼６１を受信する。
【０１６３】
（Ｓ２１２）エンジン３２０は、タイマー依頼６１で指定された到着時刻等を、エンジンノード３００に記憶された共有管理テーブル３３１へ仮登録する。
（Ｓ２１３）エンジン３２０は、ステップＳ２１２で共有管理テーブル３３１へ仮登録した到着時刻等を記載した確認通知を、エンジンノード３００ａに送信する。
【０１６４】
（Ｓ２１４）エンジン３２０ａは、受信した確認通知で指定された到着時刻とエンジンノード３００ａに記憶された共有管理テーブルに登録されている到着時刻とを比較する。ここでは、確認通知で指定された到着時刻がエンジンノード３００ａの共有管理テーブルに仮登録されたものより遅いか同じであるとする。すると、エンジン３２０ａは、エンジンノード３００の共有管理テーブルに到着時刻等を仮登録せず、拒否通知をエンジンノード３００に送信する。これにより、共通の「最初の到着時刻」として、オペレータ３１１ａが指定した到着時刻は採用されず他のオペレータが指定した到着時刻が採用される。
【０１６５】
次に、負荷分散のために、エンジンノード３００からエンジンノード３００ｃにクエリ３１１をコピーするかまたは移動する場合について説明する。
図２４は、エンジンノード追加時の管理の例を示す図である。
【０１６６】
マネージャノード６００は、エンジンノード３００，３００ａ，３００ｂの負荷が高いと判断すると、予備のエンジンノードとしてのエンジンノード３００ｃを、クエリを配置可能な状態にする。例えば、マネージャノード６００は、エンジンノード３００ｃに、１または２以上のクエリを管理するためのエンジンを起動させる。
【０１６７】
マネージャノード６００は、エンジンノード３００に配置されたクエリ３１１をエンジンノード３００ｃにコピーするか、または、エンジンノード３００ｃに移動させることができる。クエリ３１１をコピーしてクエリ３１１と同じ種類のクエリを増やす（並列度を上げる）ことで、クエリ３１１の負荷を下げることができる。また、クエリ３１１を移動することで、エンジンノード３００の負荷を下げることができる。
【０１６８】
クエリ３１１のコピーは、例えば、エンジンノード３００からエンジンノード３００ｃにクエリプログラムをコピーし、コピーしたクエリプログラムに基づいてエンジンノード３００ｃでクエリ３１５を起動することによって実現できる。この場合、エンジンノード３００上のクエリ３１１とエンジンノード３００ｃ上のクエリ３１５とは、並列に実行される。クエリ３１１の移動は、例えば、クエリ３１１を停止させてクエリプログラムをエンジンノード３００からエンジンノード３００ｃに移動し、移動したクエリプログラムに基づいてエンジンノード３００ｃでクエリ３１１を起動することによって実現できる。
【０１６９】
以下では、エンジンノード３００のクエリ３１１をコピーすることで、クエリ３１１と同じ種類のクエリ３１５をエンジンノード３００ｃに配置する場合を考える。マネージャノード６００は、コピー元であるエンジンノード３００のエンジン３２０とコピー先であるエンジンノード３００ｃのエンジンとに、コピーを指示する（Ｓ３０１）。
【０１７０】
エンジンノード３００は、マネージャノード６００からの指示に応じて、クエリ３１１の処理を記述したクエリプログラムをエンジンノード３００ｃに送信する。エンジンノード３００ｃは、エンジンノード３００から受信したクエリプログラムに基づいて、オペレータ３１５ａを含むクエリ３１５を起動する。また、エンジンノード３００ｃは、クエリ３１５の内部状態の情報を記憶する状態記憶部３１５ｂを確保する（Ｓ３０２）。
【０１７１】
また、エンジンノード３００は、管理情報記憶部３３０に記憶された共有管理テーブル３３１およびイベント管理テーブル３３２からクエリ３１１についての情報を抽出し、エンジンノード３００ｃに送信する。エンジンノード３００からエンジンノード３００ｃには、確定された最初の到着時刻・待機時間・発火間隔・発火上限回数等が通知されることになる。エンジンノード３００ｃは、共有管理テーブルやイベント管理テーブルを記憶する管理情報記憶部３３０ｃを確保し、エンジンノード３００から受信した情報を共有管理テーブルおよびイベント管理テーブルに登録する。これにより、エンジンノード３００ｃは、エンジンノード３００，３００ａ，３００ｂによって確定された最初の到着時刻を事後的に共有することができる。よって、クエリ３１１のオペレータ３１１ａと同じ時刻に、クエリ３１５のオペレータ３１５ａへタイマー通知が発行される（Ｓ３０３）。
【０１７２】
クエリ３１５が起動すると、マネージャノード６００は、クエリ３１０から出力されたイベントがクエリ３１５にも振り分けられるように、各ノードのルーティングテーブルおよびクエリ３１０〜３１５の内部状態の情報を更新する。具体的には、マネージャノード６００は、入力アダプタノード２００やエンジンノード３００，３００ａ，３００ｂ，３００ｃがもつルーティングテーブルに、クエリ３１１，３１２，３１３と同じ種類のクエリがエンジンノード３００ｃに存在することを登録する。また、マネージャノード６００は、負荷が分散されるようにクエリ３１１，３１２，３１３が担当するデータ範囲を見直し、クエリ３１１，３１２，３１３の内部状態の情報を更新する。
【０１７３】
上記ではクエリ３１１をコピーする場合について説明したが、クエリ３１１を移動する場合も、最初の到着時刻等をエンジンノード３００からエンジンノード３００ｃに通知することができる。このように、エンジンノード３００ｃにクエリ３１５を配置するにあたり、エンジンノード３００ｃが他のエンジンノードから最初の到着時刻等の通知を受け取ることで、オペレータ３１５ａに対して適切なタイミングでタイマー通知を発行できる。なお、上記ではエンジンノード３００が最初の到着時刻等を通知することとしたが、エンジンノード３００ａ，３００ｂ等、クエリ３１５と同じ種類のクエリが配置されているエンジンノードの少なくとも１つが通知すればよい。最初の到着時刻等を通知するエンジンノードは、マネージャノード６００が指定するようにしてもよい。
【０１７４】
第２の実施の形態の分散システムによれば、クエリ３１１からタイマー依頼６１が出力されると、クエリ３１１が配置されたエンジンノード３００から他のエンジンノードに、タイマー依頼６１で指定された到着時刻が通知される。同時期に同じ種類のクエリ３１１，３１２，３１３からタイマー依頼６１が出力された場合、エンジンノード３００，３００ａ，３００ｂの間で共通の「最初の到着時刻」が決定される。そして、共通化された「最初の到着時刻」を基準時刻として用いて、エンジンノード３００，３００ａ，３００ｂそれぞれにおいてタイマー通知を発行するタイミングが管理される。
【０１７５】
これにより、エンジンノード３００，３００ａ，３００ｂが独立にタイマー管理を行っても、クエリ３１１，３１２，３１３へのタイマー通知の発行タイミングを揃えることができる。その結果、並列化を考慮していないクエリプログラムに基づいてクエリ３１１，３１２，３１３を起動してイベント処理を並列化しても、並列化しない場合と処理結果が整合し、クエリプログラムが意図したイベント処理を実現することができる。よって、イベント処理を円滑に並列化することができ、分散システムの性能を向上できる。
【０１７６】
また、クエリプログラムで並列処理の手順を明記しなくてもよいため、クエリプログラムを作成するユーザの負担が軽減される。また、各エンジンノードで実行される制御ソフトウェアとしてのエンジンやマネージャノード６００が、クエリの並列度を動的に変更することが容易となり、分散システムにおける並列性の管理も容易となる。
【０１７７】
また、最初の到着時刻の確定手続において、特定時刻が設定され、特定時刻を経過すると各エンジンノードの判断で仮登録の到着時刻に基づいて１回目のタイマー通知が暫定的に発行される。よって、エンジンノード３００，３００ａ，３００ｂの間の通信遅延が大きく確定手続に時間を要する場合であっても、１回目のタイマー通知を発行し損ねることを回避できる。また、追加されたエンジンノード３００ｃにクエリ３１１がコピーまたは移動されると、確定された最初の到着時刻がエンジンノード３００ｃに通知される。よって、追加されたエンジンノード３００ｃは、エンジンノード３００，３００ａ，３００ｂと同じタイミングでタイマー通知を発行することが可能となる。
【０１７８】
なお、前述のように、第１の実施の形態のシステムは、情報処理装置１０，２０にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、入力アダプタノード２００、エンジンノード３００，３００ａ，３００ｂ，３００ｃ、出力アダプタノード４００、クライアント装置５００およびマネージャノード６００にプログラムを実行させることで実現できる。このようなプログラムは、コンピュータ読み取り可能な記録媒体（例えば、記録媒体４３）に記録しておくことができる。記録媒体としては、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリ等を使用できる。磁気ディスクには、ＦＤおよびＨＤＤが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷが含まれる。
【０１７９】
プログラムを流通させる場合、例えば、当該プログラムを記録した可搬記録媒体が提供される。コンピュータは、例えば、可搬記録媒体に記録されたプログラムを、記憶装置（例えば、ＨＤＤ３０３）に格納し、当該記憶装置からプログラムを読み込んで実行する。ただし、可搬記録媒体から読み込んだプログラムを直接実行してもよい。また、上記の情報処理の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤ（Programmable Logic Device）等の電子回路で実現することも可能である。
【０１８０】
上記については単に本発明の原理を示すものである。さらに、多数の変形や変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応する全ての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
【符号の説明】
【０１８１】
１０，２０  情報処理装置
１１，２１  プロセス
１２，２２  制御部
１３，２３  通信部
【図１】
2015071978.tif 000003
【図２】
2015071978.tif 000004
【図３】
2015071978.tif 000005
【図４】
2015071978.tif 000006
【図５】
2015071978.tif 000007
【図６】
2015071978.tif 000008
【図７】
2015071978.tif 000009
【図８】
2015071978.tif 000010
【図９】
2015071978.tif 000011
【図１０】
2015071978.tif 000012
【図１１】
2015071978.tif 000013
【図１２】
2015071978.tif 000014
【図１３】
2015071978.tif 000015
【図１４】
2015071978.tif 000016
【図１５】
2015071978.tif 000017
【図１６】
2015071978.tif 000018
【図１７】
2015071978.tif 000019
【図１８】
2015071978.tif 000020
【図１９】
2015071978.tif 000021
【図２０】
2015071978.tif 000022
【図２１】
2015071978.tif 000023
【図２２】
2015071978.tif 000024
【図２３】
2015071978.tif 000025
【図２４】
2015071978.tif 000026
【手続補正書】
【提出日】平成28年5月23日(2016.5.23)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０１３６
【補正方法】変更
【補正の内容】
【０１３６】
（Ｓ１０７）共有部３４２は、共有管理テーブル３３１に、タイマー依頼６１で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とステップＳ１０６で算出した最低特定時間とを「仮登録」として登録する。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１４８
【補正方法】変更
【補正の内容】
【０１４８】
（Ｓ１２８）共有部３４２は、受信した確認通知に関する情報を共有管理テーブル３３１に仮登録する。ステップＳ１２４で仮登録のレコードが検索されなかった場合、共有部３４２は、共有管理テーブル３３１に、確認通知で指定されたクエリ名・オペレータ名・到着時刻・待機時間・発火間隔・発火上限回数とステップＳ１２７で算出した最低特定時間とを「仮登録」として登録する。ステップＳ１２４で仮登録のレコードが検索された場合、共有部３４２は、仮登録の到着時刻を確認通知で指定されたものに更新し、最低特定時間をステップＳ１２７で算出されたものに更新する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０１６４
【補正方法】変更
【補正の内容】
【０１６４】
（Ｓ２１４）エンジン３２０ａは、受信した確認通知で指定された到着時刻とエンジンノード３００ａに記憶された共有管理テーブルに登録されている到着時刻とを比較する。ここでは、確認通知で指定された到着時刻がエンジンノード３００ａの共有管理テーブルに仮登録されたものより遅いか同じであるとする。すると、エンジン３２０ａは、エンジンノード３００ａの共有管理テーブルに到着時刻等を仮登録せず、拒否通知をエンジンノード３００に送信する。これにより、共通の「最初の到着時刻」として、オペレータ３１１ａが指定した到着時刻は採用されず他のオペレータが指定した到着時刻が採用される。
【国際調査報告】
2015071978.tif 000027
2015071978.tif 000028