実施形態1.
以下、本発明の第1の実施形態を図面を参照して説明する。
図1は、本発明によるルール分配装置を含むイベント処理システムの構成の一例を示すブロック図である。
本発明によるイベント処理システムは、ルール分配装置100と、処理サーバ200とを含む。また、図1に示すように、イベント処理システムは、端末300-1~300-nと通信可能に接続される。また、イベント処理システムは、アプリケーション400と通信可能に接続される。なお、図1には、処理サーバが1つ例示されているが、処理サーバはいくつあってもよい。また、図1には、アプリケーションが1つ例示されているが、アプリケーションはいくつあってもよい。
ルール分配装置100は、処理サーバ200、端末300-1~300-nから事前情報を取得する。具体的には、ルール分配装置100は、処理サーバ200から処理サーバ200の処理能力を示す情報を取得する。また、ルール分配装置100は、端末300-1~300-nから、各端末の処理能力、各端末が送信するイベントタイプおよび各端末の設置場所を示す情報を取得する。
ルール分配装置100は、アプリケーション400からCEPルールを受信すると、受信したCEPルールと取得した事前情報とをもとに、配置ルールおよびサブルールを生成する。配置ルールは、サブルールを、どの端末にどのタイミングで配置するかを規定するルールである。ルール分配装置100は、配置ルールを処理サーバ200に送信する。サブルールは、端末におけるイベント処理を規定するルールである。
処理サーバ200は、制御部(図示せず)を備える。なお、制御部は、処理サーバ200が備えるCPU等によって実現される。以降、処理サーバ200の制御部が処理することを、単に処理サーバ200が処理すると表現する。処理サーバ200は、受信した配置ルールを自装置に登録する。処理サーバ200は、配置ルールに対応するサブルールをルール分配装置100から取得し、保持する。
処理サーバ200は、配置ルールにもとづいて、サブルールを端末300-1~300-nに登録する。具体的には、処理サーバ200は、各端末から受信したイベントをもとに、配置ルールのイベント条件の判定を行う。そして、処理サーバ200は、受信したイベントが配置ルールのイベント条件に合致した場合には、配置ルールのアクションを実行する。つまり、処理サーバ200は、サブルールを端末に送信する。
端末300-1~300-nは、受信したサブルールを自端末に登録する。端末300-1~300-nは、サブルールに従って処理サーバ200に対してイベント通知を行う。また、端末300-1~300-nは、サブルールに従ってイベント処理を実行する。
図2は、ルール分配装置100の第1の実施形態の構成を示すブロック図である。
図2に示すように、ルール分配装置100は、ルール受信部110と、事前情報取得部120と、配置ルール生成部130と、サブルール生成部140と、事前情報記憶部150とを含む。
ルール受信部110は、アプリケーション400からCEPルールを受信する。
事前情報取得部120は、処理サーバ200、端末300-1~300-nから事前情報を取得する。事前情報取得部120は、取得した事前情報を事前情報記憶部150に格納する。
配置ルール生成部130は、ルール受信部110が受信したCEPルールと、事前情報記憶部150に格納された事前情報とをもとに、配置ルールを生成する。配置ルール生成部130は、処理サーバ200に配置ルールを送信する。
サブルール生成部140は、ルール受信部110が受信したCEPルールと、事前情報記憶部150に格納された事前情報とをもとに、サブルールを生成する。サブルール生成部140は、処理サーバ200にサブルールを送信する。
事前情報記憶部150は、事前情報取得部120から受け取った事前情報を保持する。なお、ユーザなどが予め事前情報記憶部150に事前情報を格納させてもよい。
なお、ルール受信部110、事前情報取得部120、配置ルール生成部130およびサブルール生成部140は、ルール分配装置100が備えるCPU等によって実現される。例えば、コンピュータ読み取り可能な記録媒体に記憶されたルール分配プログラムを、CPUが読み込み、CPUが、そのルール分配プログラムに従って、ルール受信部110、事前情報取得部120、配置ルール生成部130およびサブルール生成部140として動作してもよい。また、事前情報記憶部150は、ルール分配装置100が備えるメモリ等の記憶装置によって実現される。
図3は、端末の構成の一例を示すブロック図である。
図3に示すように、端末300(300-1~300-n)は、イベント制御部301と、加速度イベント生成部302と、GPS(Global Positioning System)イベント生成部303と、表示装置304とを備える。
イベント制御部301は、自端末に登録されたサブルールをもとに、加速度イベント生成部302およびGPSイベント生成部303から通知されるイベントのマッチング処理を行う。
イベント制御部301は、マッチング処理の結果に応じて、例えば、アラート画面を表示するための画像情報を表示装置304に送信する。
加速度イベント生成部302は、加速度センサ(図示せず)を含み、加速度センサから取得した加速度データをもとに、急ブレーキ等の危険を検出する。加速度イベント生成部302は、危険を検出すると、危険情報を含むイベント(以下、危険イベントという。)をイベント制御部301に通知する。危険情報は、例えば、危険の種類や危険の発生位置を示す情報である。
GPSイベント生成部303は、GPSを利用して自端末の位置情報を取得する。GPSイベント生成部303は、定期的または間欠的に、位置情報を含むイベント(以下、位置イベントという。)をイベント制御部301に通知する。位置イベントは、位置情報とともに自端末を識別可能なID情報を含む。
表示装置304は、例えば、ディスプレイ装置である。
なお、イベント制御部301、加速度イベント生成部302およびGPSイベント生成部303は、端末300が備えるCPU等によって実現される。
また、端末300は、表示装置以外の出力装置を備えていてもよい。また、本実施形態では、端末300は、イベント生成部として加速度イベント生成部およびGPSイベント生成部を備えるが、端末300はどちらか一方のイベント生成部のみを備えていてもよいし、それ以外のイベント生成部を備えていてもよい。
次に、本実施形態の動作を説明する。
本実施形態では、イベント処理システムがクーポン配信サービスに適用される場合を例にする。
図4は、クーポン配信サービスに適用したイベント処理システムの概要を示す説明図である。クーポン配信サービスは、端末を携帯するユーザが店舗に近づいたら、その店舗の広告情報としてクーポンをそのユーザの端末に配信するサービスである。
図4に示すように、クーポンの配信元である広告事業者等が、クラウド(クラウドコンピューティングシステム)上に設置されたルール分配装置に、店舗ごとのCEPルールを登録する。
クラウド上に設置された処理サーバは、ルール分配装置から受信した配置ルールに従って、次のように、端末に位置情報を通知させるためのサブルールの登録および削除を実行する。ユーザが店舗に近づいている場合は、処理サーバはその店舗に対応するサブルールをそのユーザの端末に登録する。そして、ユーザが店舗から離れて行く場合は、処理サーバはその店舗に対応するサブルールをそのユーザの端末から削除する。
図4では、ユーザXが店舗Aに近づいている。従って、処理サーバは、店舗Aに対応するサブルールをユーザXの端末に登録する。また、ユーザYが店舗Aから離れ、店舗Bに近づいている。従って、処理サーバは、店舗Aに対応するサブルールをユーザYの端末から削除し、店舗Bに対応するサブルールをユーザYの端末に登録する。
図5は、第1の実施形態におけるイベント処理システムの動作を示すシーケンス図である。なお、図5には端末300が1つ例示されているが、端末はいくつあってもよい。
ルール分配装置100は、アプリケーションからCEPルールが登録されると(ステップS101)、配置ルール、サブルールおよび削除ルールを生成する(ステップS102)。本実施形態では、ルール分配装置100は、サブルールとして通知用サブルールを生成する。通知用サブルールは、端末に、配置ルールのイベント条件の判定に必要なイベントを処理サーバ200に通知させるためのルールである。
ステップS101において登録されたCEPルールと、CEPルールから生成される配置ルール、削除ルール、通知用サブルールの一例を以下に示す。
(a)CEPルール
[イベント条件]位置イベント.位置が店舗Aから300m以内
[アクション]位置イベント.idにクーポン配信
(b)配置ルール
[イベント条件]位置イベント.位置が店舗Aから1300m以内
[アクション]通知用サブルールを位置イベント.idに設定、削除ルールを処理サーバに設定
(c)通知用サブルール
[イベント条件]位置イベント.位置が店舗Aから300m以内
[アクション]処理サーバに配信
(d)削除ルール
[イベント条件]位置イベント.位置が店舗Aから1300mより離れる
[アクション]位置イベント.idから削除対象の通知用サブルールを削除
(a)は、本実施形態において、アプリケーションから登録されるCEPルールの一例である。「位置イベント.位置が店舗Aから300m以内」は、位置イベントの属性「位置」の属性値が示す位置が店舗Aから300m(メートル)以内であるかを判定させるための条件である。このように、範囲指定を含む属性条件を範囲指定属性条件という。なお、店舗Aの位置を示す情報は、予め処理サーバ200が備える記憶部(図示せず)に格納される。
(b)は、(a)に示すCEPルールから生成される配置ルールの一例である。ルール分配装置100は、イベント条件に含まれる範囲指定属性条件の指定範囲がCEPルールよりも広くなるように、配置ルールのイベント条件を設定する。ここでは、配置ルールのイベント条件における範囲指定属性条件の指定範囲を“300m以内”よりも広い“1300m以内”に設定する。
(c)は、(b)に示す配置ルールに対応する通知用サブルールの一例である。
(d)は、削除ルールの一例である。
なお、配置ルール、通知用サブルールおよび削除ルールの構成は、CEPルールと同様の構成である。アクション「位置イベント.idから通知用サブルールを削除」は、位置イベントの属性「id」の属性値に対応する端末、つまり、位置イベントの送信元の端末に登録された通知用サブルールを削除する処理を示す。削除対象の通知用サブルールは、通知用サブルールを識別可能なIDなどで指定すればよい。本実施形態では、削除対象として通知用サブルール(c)が指定される。
ルール分配装置100は、CEPルールと、配置ルールと、配置ルールに対応する通知用サブルールおよび削除ルールとを処理サーバ200に送信する(ステップS103)。このとき、処理サーバ200は、CEPルールと配置ルールとを自装置に登録する。これにより、処理サーバ200は、当該CEPルールと当該配置ルールとを実行可能な状態となる。また、処理サーバ200は、通知用サブルールと削除ルールとを保持する。
端末300のイベント制御部301は、GPSイベント生成部303から位置イベントが送信されるたびに、位置イベントと初期動作用サブルールのイベント条件とのマッチング処理を行う(ステップS104、S105)。初期動作用サブルールは、第2のサブルールとして、アプリケーション起動時にアプリケーションによって予め各端末に登録される。なお、ルール分配装置100が、CEPルールから初期動作用サブルールを生成し、生成した初期動作用サブルールを各端末に配置するようにしてもよい。ルール分配装置100は、初期動作用サブルールを登録する端末を、例えば、事前情報記憶部150に格納された事前情報をもとに決定する。初期動作用サブルールの一例を以下に示す。初期動作用サブルールの構成は、CEPルールと同様の構成である。
(e)初期動作用サブルール
[イベント条件]位置イベント
[アクション]5分間隔で処理サーバに配信
位置イベントが初期動作用サブルールのイベント条件にマッチした場合には、つまり、前回の位置イベント送信時から5分経過している場合には、イベント制御部301は、その位置イベントを処理サーバ200へ送信する(ステップS106)。
処理サーバ200は、受信した位置イベントに対して、配置ルールのイベント条件とのマッチング処理を行う(ステップS107)。
位置イベントが配置ルールのイベント条件にマッチした場合には、つまり、端末300の位置が店舗Aから1300m以内である場合には、処理サーバ200は、位置イベントの送信元である端末300に通知用サブルールを登録する(ステップS108)。このとき、処理サーバ200は、配置ルールに従って削除ルールを自装置に登録する。
ステップS108の後、端末300のイベント制御部301は、GPSイベント生成部303から位置イベントが送信されるたびに、位置イベントと通知用サブルールのイベント条件とのマッチング処理を行う(ステップS109、S110)。
位置イベントが通知用サブルールのイベント条件にマッチした場合には、つまり、端末300の位置が店舗Aから300m以内である場合には、イベント制御部301は、位置イベントを処理サーバ200へ送信する(ステップS111)。
処理サーバ200は、受信した位置イベントに対して、CEPルールのイベント条件とのマッチング処理を行う(ステップS112)。このとき、端末300の位置は店舗Aから300m以内であるので、処理サーバ200は、CEPルールのアクションを実行する。これにより、位置イベントの送信元である端末300に、処理サーバ200から店舗Aのクーポンが配信される(ステップS113)。
処理サーバ200は、ステップS113の後、端末300から受信する位置イベントに対して、削除ルールのイベント条件とのマッチング処理を行う。位置イベントが削除ルールのイベント条件とマッチした場合には、つまり、端末300の位置が店舗Aから1300mより離れた場合には、処理サーバ200は、削除ルールのアクションを実行する。つまり、位置イベントの送信元である端末300に登録された通知用サブルールを削除する。
ここで、ユーザからルール分配装置100に対して、CEPルールの削除要求があった場合の動作を説明する。
ルール分配装置100は、ユーザからCEPルールの削除要求を受け付けると、具体的には、ルール分配装置100が備えるルール削除部(図示せず)がCEPルールの削除要求を受信すると、自装置に登録されたCEPルールを削除する。また、ルール分配装置100のルール削除部は、処理サーバ200にCEPルールおよび当該CEPルールに対応する配置ルールの削除要求を送信する。
処理サーバ200は、ルール分配装置100の要求に応じて、自装置に登録されたCEPルールおよび配置ルールを削除する。処理サーバ200は、各ルールを削除した後、各端末に通知用サブルールの削除要求を送信する。なお、ルール分配装置100のルール削除部が各端末に通知用サブルールの削除要求を送信してもよい。
各端末は、処理サーバ200の要求に応じて通知用サブルールを削除する。
このように、ルール分配装置100からCEPルールが削除されると、処理サーバ200および各端末に登録されている当該CEPルールに対応する各ルールが削除される。
以上に説明したように、本実施形態では、ルール分配装置は、アプリケーションが登録したCEPルールをもとに生成した、配置ルールおよび通知用サブルールを用いて、イベント処理システムにおける処理サーバおよび端末の処理を制御する。また、ルール分配装置は、CEPルールが登録されるたびにCEPルールの内容に応じた配置ルール、通知用サブルールを生成し、各ルールを処理サーバおよび端末に登録する。従って、CEPにおいて動的な分散並列処理を実現することができる。
また、処理サーバは、配置ルールに従って、CEPルールのイベント条件にマッチしそうな状況にあるユーザの端末にのみ、通知用サブルールを配置する。従って、本実施形態によれば、イベント条件にマッチしそうにない端末における不要なイベントの送信を抑えることができるので、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。
また、本実施形態によれば、処理サーバは、全端末に通知用サブルールを配置する必要がないので、処理サーバの負荷を低減することができる。また、端末の状況、例えば端末と店舗との位置関係に応じて、端末がその状況で最小限必要なサブルールのみが当該端末に登録される。それにより、端末のメモリ消費量を低減することができる。また、端末は最低限のサブルールのみを実行すればよいので、端末のCPUリソース消費量を低減することができる。従って、ネットワークにおけるリソースがボトルネックとなることを回避することができ、高いサービス品質を維持することができる。
また、本実施形態では、端末と店舗との距離が一定以上になった場合には、端末からCEPルールに対応する通知用サブルールを削除する。このように、端末における通知用サブルールによるマッチング処理が必要なくなったときに、端末から通知用サブルールを削除することにより、端末のメモリ消費量およびCPUリソース消費量をより低減することができる。なお、本実施形態では、端末と店舗との距離にもとづいて通知用サブルールを削除する場合を例にしたが、例えば、端末にクーポンが配信されてからの経過時間にもとづいて通知用サブルールを削除するようにしてもよい。
また、本実施形態では、ルール分配装置からCEPルールが削除されたときに、処理サーバ200および各端末に登録されている当該CEPルールに対応する各ルールを削除する。従って、処理サーバおよび端末のメモリ消費量およびCPUリソース消費量をより低減することができる。
また、本実施形態では、監視対象となる一方が店舗である場合を例にしたが、店舗に限定されず、店舗以外の固定エリアを監視対象としてもよい。
実施形態2.
以下、本発明の第2の実施形態を図面を参照して説明する。
イベント処理システムの第2の実施形態の構成は、第1の実施形態の構成と同様であるため、説明を省略する。
ここでは、イベント処理システムがお近づき通知サービスに適用される場合を例にする。
図6は、お近づき通知サービスに適用したイベント処理システムの概要を示す説明図である。お近づき通知サービスは、端末を携帯するユーザ同士がある一定距離以下まで近づいたら、互いの端末が近づいていることを示すお近づき通知を各ユーザの端末に送信するサービスである。図6は、ユーザXとユーザYとの距離が300m以内になったときに、お近づき通知が送信される様子を示す。
図6に示すように、ユーザX、Yが携帯する各端末(以下、単にユーザX、ユーザYという。)は、まず、予め定められたタイミングで位置イベントを処理サーバに送信する。ここでは、ユーザX、Yは、5分間隔で位置イベントを送信する。
処理サーバは、各ユーザから受信した位置イベントをもとに、ユーザXとユーザYとの距離が一定以内、例えば、1300m以内になったか否かを判定する。処理サーバは、ユーザXとユーザYとの距離が一定以内になると、各ユーザの位置イベントの送信間隔を5分よりも短い30秒に変更する。
処理サーバは、30秒間隔で各ユーザから送信される位置イベントをもとに、ユーザXとユーザYとの距離が300m以内になったか否かを判定する。処理サーバは、ユーザXとユーザYとの距離が300m以内である場合には、他のユーザが近づいていることを各ユーザに通知する。これにより、ユーザX、Yは、他方が自身に近づいているか否かを認識することができる。
図7は、第2の実施形態におけるイベント処理システムの動作を示すシーケンス図である。
ここでは、端末300-1および端末300-2に対して、お近づき通知を送信する場合を例にする。なお、図7には2つの端末300-1、300-2が例示されているが、端末はいくつあってもよい。
ルール分配装置100は、アプリケーションからCEPルールが登録されると(ステップS201)、配置ルール、サブルールおよび削除ルールを生成する(ステップS202)。本実施形態では、ルール分配装置100は、第1の実施形態と同様に、サブルールとして通知用サブルールを生成する。
ステップS201において登録されたCEPルールと、CEPルールから生成される配置ルール、通知用サブルール、削除ルールの一例を以下に示す。
(f)CEPルール
[イベント条件]位置イベント1.位置と位置イベント2.位置の距離が300m以内
[アクション]位置イベント1.idと位置イベント2.idに近づいたことを通知
(g)配置ルール
[イベント条件]位置イベント1.位置と位置イベント2.位置の距離が1300m以内
[アクション]通知用サブルールを位置イベント.idに設定、削除ルールを処理サーバに設定
(h)通知用サブルール
[イベント条件]位置イベント
[アクション]30秒間隔で処理サーバに配信
(i)削除ルール
[イベント条件]位置イベント1.位置と位置イベント2.位置の距離が1300mより離れる
[アクション]位置イベント.idから削除対象の通知用サブルールを削除
ここで、各ルールにおける“位置イベント1”は、端末300-1が送信する位置イベントを示す。“位置イベント2”は、端末300-2が送信する位置イベントを示す。
(f)は、本実施形態において、アプリケーションから登録されるCEPルールの一例である。「位置イベント1.位置と位置イベント2.位置の距離が300m以内」は、端末300-1が送信する位置イベントの属性「位置」の属性値と、端末300-2が送信する位置イベントの属性「位置」の属性値との差が300m以内であるかを判定させるための条件である。
(g)は、(f)に示すCEPルールから生成される配置ルールの一例である。(h)は、(g)に示す配置ルールに対応する通知用サブルールの一例である。
(i)は、削除ルールの一例である。本実施形態では、削除対象として通知用サブルール(h)が指定される。
ルール分配装置100は、CEPルールと、配置ルールと、配置ルールに対応する通知用サブルールおよび削除ルールとを処理サーバ200に送信する(ステップS203)。このとき、処理サーバ200は、CEPルールと配置ルールとを自装置に登録する。また、処理サーバ200は、通知用サブルールと削除ルールとを保持する。
端末300-1、300-2のイベント制御部は、GPSイベント生成部から位置イベントが送信されるたびに、位置イベントと初期動作用サブルールのイベント条件とのマッチング処理を行う(ステップS204、S205)。初期動作用サブルールは、アプリケーション起動時にアプリケーションによって予め各端末に登録される。ここでは、各端末に上記(e)に示す初期動作用サブルールが登録されているとする。なお、ルール分配装置100が、CEPルールから初期動作用サブルールを生成し、生成した初期動作用サブルールを各端末に配置するようにしてもよい。
位置イベントが初期動作用サブルールのイベント条件にマッチした場合には、つまり、前回の位置イベント送信時から5分経過している場合には、各端末のイベント制御部は、その位置イベントを処理サーバ200へ送信する(ステップS206)。
処理サーバ200は、各端末から受信した位置イベントに対して、配置ルールのイベント条件とのマッチング処理を行う(ステップS207)。
各端末から受信した位置イベントが配置ルールのイベント条件にマッチした場合には、つまり、位置イベントの送信元である端末300-1と端末300-2との距離が1300m以内である場合には、各位置イベントの送信元である端末300-1、300-2に通知用サブルールを登録する(ステップS208)。このとき、処理サーバ200は、削除ルールを自装置に登録する。
ステップS208の後、端末300-1、300-2のイベント制御部は、GPSイベント生成部から位置イベントが送信されるたびに、位置イベントと通知用サブルールのイベント条件とのマッチング処理を行う(ステップS209、S210)。
GPSイベント生成部から通知される位置イベントが通知用サブルールのイベント条件にマッチした場合には、つまり、前回の位置イベント送信時から30秒経過している場合には、各端末のイベント制御部は、位置イベントを処理サーバ200へ送信する(ステップS211)。
処理サーバ200は、各端末から受信した位置イベントに対して、CEPルールのイベント条件とのマッチング処理を行う(ステップS212)。
各端末から受信した位置イベントがCEPルールのイベント条件にマッチした場合、つまり、位置イベントの送信元である端末300-1と端末300-2との距離が300m以内である場合には、処理サーバ200は、CEPルールのアクションを実行する(ステップS213)。これにより、端末300-1、300-2にお近づき通知が送信される。
処理サーバ200は、ステップS213の後、各端末から受信する位置イベントに対して、削除ルールのイベント条件とのマッチング処理を行う。各端末から受信した位置イベントが削除ルールのイベント条件とマッチした場合には、つまり、端末300-1と端末300-2とが1300mより離れた場合には、処理サーバ200は、削除ルールのアクションを実行する。つまり、位置イベントの送信元である端末300-1、300-2に登録された通知用サブルールを削除する。
なお、ユーザからルール分配装置100に対して、CEPルールの削除要求があった場合のルール分配装置100、処理サーバ200および各端末の動作は、第1の実施形態と同様であるため、説明を省略する。
以上に説明したように、本実施形態では、処理サーバは、端末同士が一定の距離以下に近づいたときに、各端末にお近づき通知を送信する。これにより、端末を携帯するユーザは、他のユーザが自身に近づいているか否かを認識することができる。第1の実施形態におけるクーポン配信サービスでは、監視対象となる一方(店舗)の位置が固定されている。本実施形態では、監視対象となる一方の位置が固定されていないサービス、つまり、監視対象となる双方の位置が固定されていないサービスにおいても、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。
実施形態3.
以下、本発明の第3の実施形態を図面を参照して説明する。
イベント処理システムの第3の実施形態の構成は、第1の実施形態の構成と同様であるため、説明を省略する。
ここでは、イベント処理システムが危険箇所事前通知サービスに適用される場合を例にする。
図8は、危険箇所事前通知サービスの概要を示す説明図である。
まず、図8を参照して、危険箇所事前通知サービスの概要を説明する。
図8に示す各車両は、それぞれ、図3に示す端末を搭載する。車両に搭載された端末(以下、単に車両という。)は、位置イベントを危険通知サーバに送信する。
各車両は、自車両が危険な状態にあるか否かを判定し、危険イベントを危険通知サーバに送信する。各車両は、例えば、運転者が急ブレーキを踏んだ場合や、車両が道路の陥没を検出した場合に、危険であると判断する。
危険通知サーバは、危険を検出した車両(以下、危険検出車両という。)から危険イベントを受信すると、危険情報の通知対象候補となる車両(以下、通知対象候補車両という。)を特定する。危険通知サーバは、例えば、危険検出車両と他の車両との距離が一定距離(以下、危険判定距離という。)以下にある車両を通知対象候補とする。処理サーバ200は、特定した通知対象候補車両に危険通知を送信する。これにより、危険検出車両は、周辺エリアにいる他の車両に危険を知らせることができる。
危険通知を受信した通知対象候補車両は、自車両と危険検出車両との距離をもとに、自車両に危険の影響があるか否かを判断する。また、危険の影響があると判断した場合には、運転者に対して危険を通知する。例えば、通知対象候補車両は、車両に搭載されたディスプレイ等の表示装置に、危険を通知するための情報としてアラート画面を表示する。
次に、図9を参照して、危険箇所事前通知サービスに適用したイベント処理システムのCEPルール登録時の動作を説明する。
図9は、第3の実施形態におけるイベント処理システムのCEPルール登録時の動作を示すシーケンス図である。なお、図9には2つの端末300-1、300-2が例示されているが、端末はいくつあってもよい。
本実施形態では、イベント処理システムは、配置ルール、実行用サブルールおよび通知用サブルールを用いて、車両から危険通知サーバ(処理サーバ200)へ送信される位置イベントの送信間隔を調整する。
ルール分配装置100は、アプリケーション400からCEPルールが登録されると(ステップS501)、配置ルールおよびサブルールを生成する(ステップS502)。本実施形態では、ルール分配装置100は、サブルールとして、実行用サブルールおよび通知用サブルールを生成する。実行用サブルールは、端末にCEPルールに規定されたイベント処理を実行させるためのルールである。
ステップS501において登録されたCEPルールと、CEPルールから生成される配置ルール、実行用サブルールおよび通知用サブルールの一例を以下に示す
(j)CEPルール
[イベント条件]危険イベント.危険=急ブレーキ&&危険イベント.位置と位置イベント.位置が300m以内
[アクション]位置イベント.idにアラーム通知
(k)配置ルール
[イベント条件]危険イベント.危険=急ブレーキ&&危険イベント.位置と位置イベント.位置が1300m以内
[アクション]実行用サブルールに危険イベント.位置の絶対値を入力し、実行用サブルールを位置イベント.idに設定
(l)実行用サブルール
[イベント条件]危険イベント.位置と位置イベント.位置が300m以内
[アクション]位置イベント.idにアラーム通知
(m)通知用サブルール
[イベント条件]位置イベント.位置が前回処理サーバに位置イベントを送信してから1000m移動
[アクション]処理サーバに配信
(n)通知用サブルール
[イベント条件]危険イベント.危険=急ブレーキ
[アクション]処理サーバに配信
(j)は、本実施形態において、アプリケーションから登録されるCEPルールの一例である。(j)に示すイベント条件は、2つの属性条件「危険イベント.危険=急ブレーキ」と「危険イベント.位置と位置イベント.位置が300m以内」とのAND(論理積)である。
「危険イベント.危険=急ブレーキ」は、危険イベントの属性「危険」の属性値が“急ブレーキ”であるかを判定させるための条件である。「危険イベント.位置と位置イベント.位置が300m以内」は、危険イベントの属性「位置」の属性値と位置イベントの属性「位置」の属性値との差が300m以内であるかを判定させるための条件である。
(k)は、(j)に示すCEPルールから生成される配置ルールの一例である。(l)は、(k)に示す配置ルールに対応する実行用サブルールの一例である。(m)、(n)は、(k)に示す配置ルールに対応する通知用サブルールの一例である。なお、実行用サブルールの構成は、CEPルールと同様の構成である。
ルール分配装置100は、配置ルールと実行用サブルールとを処理サーバ200に送信する(ステップS503)。このとき、処理サーバ200は、配置ルールと実行用サブルールとを自装置に登録する。
また、ルール分配装置100は、通知用サブルール(m)、(n)を各端末に登録する(ステップS504)。
ステップS504の後、通知用サブルールが登録された各端末は、(m)に示す通知用サブルールに従って、位置イベントの通知処理を開始する。つまり、各端末は、1000m移動するごとに、処理サーバ200に位置イベントを通知する。また、各端末は、急ブレーキ等を検出したときには、(n)に示す通知用サブルールに従って、処理サーバ200に危険イベントを通知する。
なお、ステップS504の処理は、ユーザ等が予め実行するようにしてもよい。例えば、ユーザ等が予め通知用サブルール(m)、(n)を生成し、第1および第2の実施形態と同様に、初期動作用サブルールとして各端末に登録するようにしてもよい。
ここで、ステップS502における配置ルールおよびサブルールの生成処理を説明する。
まず、ルール分配装置100は、配置ルールおよびサブルールを生成する。図10は、ステップS502における配置ルールおよび実行用サブルールの生成処理を示すフローチャートである。
ルール分配装置100のルール受信部110は、アプリケーション400からCEPルールを受信すると(ステップS701)、CEPルールを配置ルール生成部130とサブルール生成部140とに渡す。
配置ルール生成部130は、CEPルールをもとに、配置ルールを生成する。このとき、配置ルール生成部130は、CEPルールのイベント条件を配置ルールのイベント条件に設定する(ステップS702)。
配置ルール生成部130は、配置ルールのイベント条件の各属性条件に対して、更新処理(ステップS704、S705の処理)を実行する(ステップS703)。
ステップS704で、配置ルール生成部130は、属性条件が範囲指定であるか否かを判定する。
属性条件が範囲指定であった場合には(ステップS704のyes)、ステップS705で、配置ルール生成部130は当該属性条件に含まれる属性値を更新する。
ステップS705の後、サブルール生成部140は、CEPルールをもとに、実行用サブルールを生成する(ステップS706、S707)。このとき、サブルール生成部140は、CEPルールのイベント条件のうち、範囲指定属性条件を、実行用サブルールのイベント条件に設定する。また、サブルール生成部140は、CEPルールのアクションを実行用サブルールのアクションに設定する。
ステップS707の後、配置ルール生成部130は、配置ルールのアクションを設定する(ステップS708)。このとき、配置ルールのアクションには、配置ルールのイベント条件が成立したときに、サブルール生成部140が生成した実行用サブルールをどの車両に登録するかを示す処理内容が設定される。上記(k)に示す例の場合、登録対象となる車両、つまり、通知対象候補車両は、配置ルールのイベント条件にマッチした位置イベントの属性「id」の属性値に対応する車両である。処理サーバ200は、イベント端末対応テーブルを参照して、属性「id」の属性値に対応する車両を特定する。イベント端末対応テーブルは、属性「id」の属性値とそれに対応する車両とを対応づけた情報である。イベント端末対応テーブルは、処理サーバ200の記憶部(図示せず)等に格納される。
ここで、ステップS705の属性条件の更新処理を説明する。
当該更新処理実行前における配置ルールのイベント条件のうち範囲指定属性条件は、「危険イベント.位置と位置イベント.位置が300m以内」である。従って、配置ルール生成部130は、ステップS705において、当該属性条件に含まれる属性値「300m」を次のように更新する。
まず、配置ルール生成部130は、アプリケーションが登録したCEPルールと、事前情報記憶部150に格納された事前情報とをもとに、車両の位置イベント送信間隔xを決定する。ここでは、位置イベント送信間隔xが1000mに決定されたとする。
次に、配置ルール生成部130は、属性値「300m」に、位置イベント送信間隔x(1000m)を加算する。つまり、属性値は「1300(=300+1000)m」に更新される。これにより、配置ルールのイベント条件は、上記(k)に示すような条件になる。
ここで、位置イベント送信間隔xの算出方法を説明する。位置イベント送信間隔xは、イベント処理システムの総通信量uが最小になるように算出する。
式1は、イベント処理システムの総通信量uを算出するための式である。
αは、端末から処理サーバに送信される危険イベントの1秒当たりの発生率を示す。
βは、端末から処理サーバに送信される位置イベントの1秒当たりの発生率を示す。βは、式2によって算出される。
pは、端末の移動速度(m/s)を示す。
γは、実行用サブルールの発生率、つまり、処理サーバから端末に1秒あたりに登録される実行用サブルールの個数を示す。γは、式3によって算出される。
eは、危険通知の範囲(円)の半径を示す。つまり、危険検出車両から半径何メートル以内にいる車両にアラートを通知するかを示す値である。mは、端末密度、つまり、1平方メートル当たりの通知対象候補となる端末の数を示す。nは、全端末数を示す。
なお、α、p、e、n、mは、事前情報であって、事前情報記憶部150に格納されている。
配置ルール生成部130は、式1に示す総通信量uを最小とする位置イベント送信間隔xを算出する。例えば、uとxとの対応を示すグラフの凸部分のx、つまり、uの微分値が0になるときのxと、xの限界値(0または∞)とのうち、uが最小になるxを求めるようにしてもよい。なお、位置イベント送信間隔xの算出方法はその他の方法であってもよい。
ルール分配装置100は、ステップS502において配置ルールおよび実行用サブルールを生成した後、配置ルールのイベント条件に含まれるイベントのタイプごとに、通知用サブルールを生成する。具体的には、ルール分配装置100のサブルール生成部140は、ステップS502において位置イベントを通知させるための通知用サブルール(m)および危険イベントを通知させるための通知用サブルール(n)を生成する。
サブルール生成部140は、位置イベントを通知させるための通知用サブルールに、上記(m)に示すように、位置イベント送信間隔xが1000mになるようなイベント条件を設定する。
次に、図11を参照して、危険箇所事前通知サービスに適用したイベント処理システムの危険イベント受信時の動作を説明する。
図11は、第3の実施形態におけるイベント処理システムの危険イベント受信時の動作を示すシーケンス図である。
図11に示すように、端末300-1の加速度イベント生成部302-1は、急ブレーキなどを検出すると、イベント制御部301-1に危険イベントを送信する(ステップS801)。
イベント制御部301-1は、受信した危険イベントと、通知用サブルール(n)のイベント条件とのマッチング処理を行う(ステップS802)。危険イベントが通知用サブルール(n)のイベント条件にマッチした場合には、イベント制御部301-1は、その危険イベントを処理サーバ200へ送信する(ステップS803)。
端末300-2のイベント制御部301-2は、GPSイベント生成部303-2から位置イベントが送信されるたびに、位置イベントと通知用サブルール(m)のイベント条件とのマッチング処理を行う(ステップS804、S805)。位置イベントが通知用サブルール(m)のイベント条件にマッチした場合には、イベント制御部301-2は、その位置イベントを処理サーバ200へ送信する(ステップS806)。
処理サーバ200は、ステップS803において受信した危険イベントおよびステップS806において受信した位置イベントに対して、配置ルールのイベント条件とのマッチング処理を行う(ステップS807)。
ステップS807において危険イベントおよび位置イベントが、配置ルールのイベント条件とマッチした場合には、処理サーバ200は、配置ルールのアクションを実行する。すなわち、処理サーバ200は、位置イベントの属性「id」の属性値に対応する端末に実行用サブルールを登録する(ステップS808)。つまり、位置イベントの送信元である端末300-2に実行用サブルールを登録する。このとき、処理サーバ200は、受信した危険イベントの属性「位置」の属性値の絶対値を、実行用サブルールのイベント条件に含まれる危険イベントの属性「位置」の属性値に設定する。
ステップS808の後、端末300-2のイベント制御部301-2は、GPSイベント生成部303-2から位置イベントが送信されるたびに、位置イベントと実行用サブルールのイベント条件とのマッチング処理を行う(ステップS809、S810)。
位置イベントが実行用サブルールのイベント条件にマッチした場合、つまり、位置イベントの属性「位置」の属性値と危険イベントの属性「位置」の属性値との差が300m以内になった場合には、イベント制御部301-2は、実行用サブルールのアクションを実行する(ステップS811)。つまり、イベント制御部301-2は、表示装置304-2に危険を通知するための情報を送信する。
このように、処理サーバ200は、各車両が1000m移動するごとに通知する位置イベントと、危険検出車両が通知する危険イベントとをもとに、危険検出車両と各車両との距離が1300m以下であるかを判定する。そして、処理サーバ200は、車両と危険検出車両との距離が1300m以下であると判断した場合には、実行用サブルールを当該車両に登録する。これにより、実行用サブルールが登録された車両(通知対象候補車両)は、危険検出車両との距離が300m以下になったときに、自車両のディスプレイ等に危険を通知するための情報を表示する。
以上に説明したように、本実施形態では、ルール分配装置が、端末と処理サーバ間の通信回数を最小化する位置イベント送信間隔を決定する。そして、ルール分配装置は、決定した位置イベント送信間隔とアプリケーションが登録したCEPルールとをもとに生成した、配置ルール、実行用サブルールおよび通知用サブルールを用いて、イベント処理システムにおける処理サーバおよび端末の処理を制御する。また、本実施形態では、端末が、実行用サブルールに従って、CEPルールのイベント処理を処理サーバに代わって実行する。従って、本実施形態によれば、CEPにおいてより動的な分散並列処理を実現することができる。
また、本実施形態では、第1および第2の実施形態と同様に、配置ルールに従って、CEPルールのイベント条件にマッチしそうな状況にあるユーザの端末にのみ、実行用サブルールを配置する。従って、本実施形態によれば、危険箇所事前通知サービスにおいてCEPルールを実行する際に、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなく危険箇所事前通知サービスを提供することができる。
また、本実施形態によれば、実行用サブルールを全端末に登録する必要がない。よって、実行用サブルールを端末に配置する処理を軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることを回避することができる。
なお、本実施形態においても、第1および第2の実施形態と同様に、削除ルールを使用して実行用サブルールを削除するようにしてもよい。そのような形態によれば、端末のメモリ消費量およびCPUリソース消費量をより低減することができる。
また、本実施形態では、端末が危険を検出したときに危険イベントを送信する場合を例にしたが、端末は危険イベント以外のイベントを送信してもよい。例えば、端末が危険以外の状態変化を検出するセンサを備え、当該センサが検出した情報を含むイベントを送信するようにしてもよい。
実施形態4.
以下、本発明の第4の実施形態を図面を参照して説明する。
図12は、本発明によるルール分配装置を含むイベント処理システムの第4の実施形態の構成を示すブロック図である。なお、イベント処理システムの第4の実施形態の構成は、第1の実施形態の構成と同様であるため、説明を省略する。
ただし、図12に示すように、本実施形態では、処理サーバ200と端末300-1~300-nとが、基地局500-1~500-mを介して接続されている。なお、各基地局には端末がいくつ接続されていてもよい。図12に示す基地局500-1には、2台の端末300-1、300-2が接続されている。
また、処理サーバ200は、各基地局の対象エリアの情報(以下、エリア情報という。)を保持する。処理サーバ200は、危険イベントを受信した場合、エリア情報をもとに、危険イベントの発生位置を対象エリアとする基地局を特定する。そして、処理サーバ200は、特定した基地局に対して配置ルールのアクションを実行する。なお、エリア情報は、処理サーバ200が備える記憶部(図示せず)に予め格納される。
次に、本実施形態の動作を説明する。
図13は、基地局を介して危険通知を行う危険箇所事前通知サービスの概要を示す説明図である。第3の実施形態では、イベント処理システムが図8に示す危険箇所事前通知サービスに適用される場合を例にした。ここでは、イベント処理システムが図13に示す危険箇所事前通知サービスに適用される場合を例にする。図13に示す危険通知サーバは、基地局を介して端末に危険通知を行う。
第4の実施形態におけるイベント処理システムのCEPルール登録時の動作は、図9に示す第3の実施形態の動作と同様であるため、説明を省略する。
ただし、本実施形態では、ルール分配装置100は、ステップS502において、CEPルールのイベント条件を配置ルールのイベント条件に設定するときに、範囲指定属性条件を配置ルールのイベント条件に含ませない。
また、ルール分配装置100は、通知用サブルールとして、端末に危険イベントを通知させるためのサブルールのみを生成し、位置イベントを通知させるためのサブルールは生成しない。
また、ルール分配装置100は、危険イベントの発生位置を対象エリアとする基地局に対して実行用サブルールのブロードキャストを依頼する処理を、配置ルールのアクションとして登録する。
従って、本実施形態において、アプリケーション400からルール分配装置100に対して上記(j)に示すCEPルールが登録された場合、ルール分配装置100は、以下の(o)~(q)に示すルールを生成する。
(o)配置ルール
[イベント条件]危険イベント.危険=急ブレーキ
[アクション]実行用サブルールに危険イベント.位置の絶対値を入力し、危険イベント.位置をカバーする基地局に対して、5秒ごとに2回実行用サブルールのブロードキャストを依頼
(p)実行用サブルール
[イベント条件]危険イベント.位置と位置イベント.位置が300m以内
[アクション]位置イベント.idにアラーム通知
(q)通知用サブルール
[イベント条件]危険イベント.危険=急ブレーキ
[アクション]処理サーバに配信
図14は、第4の実施形態におけるイベント処理システムの危険イベント受信時の動作を示すシーケンス図である。
ステップS1201~S1203の処理は、第3の実施形態のステップS801~S803の処理と同様であるため説明を省略する。
処理サーバ200は、ステップS1203において受信した危険イベントに対して、配置ルールのイベント条件とのマッチング処理を行う(ステップS1204)。
ステップS1204において危険イベントが配置ルールのイベント条件とマッチした場合には、処理サーバ200は、配置ルールのアクションを実行する(ステップS1205)。
ステップS1205において、処理サーバ200は、エリア情報をもとに、受信した危険イベントの発生位置を対象エリアとする基地局を特定する。ここでは、基地局500-1が特定されたとする。処理サーバ200は、基地局500-1に実行用サブルールを送信するとともに、実行用サブルールのブロードキャストを依頼する。本実施形態では、処理サーバ200は、上記(o)に示す配置ルールに従って、実行用サブルールを5秒ごとに2回ブロードキャストするように依頼する。
基地局500は、処理サーバ200から受信した実行用サブルールを、自局の配下の端末300-1、300-2にブロードキャストする(ステップS1206)。
各端末のイベント制御部は、実行用サブルールが自端末に既に登録されているかどうかの重複チェックを行う(ステップS1207)。各端末は、重複チェックの結果、実行用サブルールが未登録の場合には、実行用サブルールを登録する(ステップS1208)。
ステップS1208の後、各端末のイベント制御部は、GPSイベント生成部から位置イベントが送信されるたびに、位置イベントと実行用サブルールとのマッチング処理を行う(ステップS1209、S1210)。
各端末のイベント制御部は、位置イベントが実行用サブルールにマッチした場合には、実行用サブルールのアクションを実行する(ステップS1211)。つまり、イベント制御部は、自端末の表示装置に危険を通知するための情報、例えば、アラート画面を表示するための画像情報を送信する。
ここで、端末300-1、300-2に実行用サブルールが登録された後に、基地局500の配下に新たに端末が加わった場合のイベント処理システムの動作を説明する。
図15は、第4の実施形態におけるイベント処理システムの新規端末加入時の動作を示すシーケンス図である。図15は、基地局500-1の配下に新たに端末300-3が加わったときのイベント処理システムの動作を示す。
基地局500は、端末300-3が新規加入した後に実行用サブルールのブロードキャストを依頼された場合(ステップS1301)、端末300-1、300-2および300-3に対して実行用サブルールをブロードキャストする(ステップS1302)。
各端末は、実行用サブルールが自端末に既に登録されているかどうかの重複チェックを行う(ステップS1303)。
端末300-1、300-2は、すでに実行用サブルールが登録されているので、実行用サブルールの登録処理は行わない。
新規加入した端末300-3は、実行用サブルールが未登録であるため、実行用サブルールを登録する(ステップS1304)。
ステップS1304の後、端末300-3は、図14に示すステップS1209~S1211の処理を実行する。
以上に説明したように、本実施形態では、処理サーバが危険イベントを受信した場合に、危険イベントを送信した端末を配下に接続する基地局に実行用サブルールのブロードキャストを依頼する。従って、処理サーバは、危険通知対象となる端末を特定するときに、各基地局のエリア情報を参照するだけでよい。よって、処理サーバ200は、各端末から位置イベントを受信する必要がないので、端末、処理サーバおよびネットワークの負荷をさらに低減させることができる。
また、端末に位置イベントを通知させるための通知用サブルールを登録する必要がないので、通知用サブルールを端末に配置する処理をさらに軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることをより回避しやすい。
図16は、本発明によるルール分配装置の最小構成を示すブロック図である。図17は、本発明によるルール分配装置の他の最小構成を示すブロック図である。図18は、本発明によるイベント処理システムの最小構成を示すブロック図である。
図16に示すように、ルール分配装置10(図2に示すルール分配装置100に相当。)は、アプリケーション(図1に示すアプリケーション400に相当。)が要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部11(図2に示すルール分配装置100におけるルール受信部110に相当。)と、処理ルールのイベント条件が含む1つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末(図1に示す端末300-1~300-nに相当。)に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、端末と通信可能でありイベント処理を実行可能な処理装置(図1に示す処理サーバ200に相当。)に、配置ルールとサブルールとを送信するルール生成部12(図2に示すルール分配装置100における配置ルール生成部130およびサブルール生成部140に相当。)とを含む。
そのような構成によれば、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。また、CEPにおいて動的な分散並列処理を実現することができる。また、サブルールを全端末に登録する必要がないので、サブルールを端末に配置する処理を軽減させることができる。また、端末のメモリ消費量を低減させることができる。従って、ネットワークにおけるリソースがボトルネックとなることを回避することができ、高いサービス品質を維持することができる。
上記の実施形態には、以下のようなルール分配装置も開示されている。
(1)イベント条件は、端末から受信したイベントの属性値が所定の範囲内に含まれるか否かを判定する範囲指定属性条件を含み、ルール生成部12は、処理ルールの範囲指定属性条件の指定範囲をもとに当該指定範囲を含む新たな指定範囲を算出し、新たな指定範囲を配置ルールの範囲指定属性条件の指定範囲とするルール分配装置。
そのような構成によれば、範囲指定属性条件を含むイベント条件から構成されるCEPルールを、端末、処理サーバおよびネットワークの負荷を増大させることなく実行することができる。
(2)ルール生成部12は、ルール受信部11が処理ルールを受信したときに、当該処理ルールをもとに、端末に初期動作をさせるための第2のサブルールを生成し、第2のサブルールを端末に送信するルール分配装置。
そのような構成によれば、ルール受信部が処理ルールを受信するまで、つまり、アプリケーションから処理ルールが登録されるまで、第2のサブルールを端末に登録しておく必要がない。従って、端末のメモリ消費量をより低減させることができる。また、第2のサブルールによる端末からのイベント送信を抑えることができるので、端末、処理サーバおよびネットワークの負荷を低減することができる。また、例えば、端末に配置ルールのイベント条件に必要なイベントの送信を初期動作として実行させることができる。
(3)ルール受信部11は、固定エリアと端末とが指定範囲内に存在するか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部12は、範囲指定属性条件をイベント条件とし、処理装置へ位置イベントを送信する処理をアクションとするサブルールを生成するルール分配装置。
そのような構成によれば、CEPルールのイベント条件にマッチしそうにない端末における不要なイベントの送信を抑えることができるので、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。
(4)ルール受信部11は、端末同士が指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部12は、位置イベントの送信をアクションとし、イベント条件に位置イベントを送信する周期を指定したサブルールを生成するルール分配装置。
そのような構成によれば、監視対象となる一方の位置が固定されていない状態、つまり、監視対象となる双方の位置が固定されていないサービスにおいても、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。
(5)ルール受信部11は、位置イベントの送信元の端末と位置イベント以外のイベントの送信元の端末とが指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部12は、範囲指定属性条件をイベント条件とするサブルールを生成し、サブルールのアクションに処理ルールのアクションを設定するルール分配装置。
そのような構成によれば、CEPルールのイベント条件に位置イベント以外のイベントが含まれる場合であっても、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。例えば、危険箇所事前通知サービスにおいてCEPルールを実行する際に、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなく危険箇所事前通知サービスを提供することができる。
(6)ルール生成部12は、処理装置と端末とが基地局(図12に示す基地局500-1~500-mに相当。)を介して接続されている場合には、基地局に対して、基地局に接続している端末にサブルールのブロードキャストを依頼するアクションを規定した配置ルールを処理装置に送信するルール分配装置。
そのような構成によれば、実行用サブルールの通知対象となる端末を特定するときに、各基地局のエリア情報を参照するだけでよい。従って、処理サーバは、各端末から位置イベントを受信する必要がないので、端末、処理サーバおよびネットワークの負荷をさらに低減させることができる。また、端末に位置イベントを通知させるための通知用サブルールを登録する必要がないので、通知用サブルールを端末に配置する処理をさらに軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることをより回避しやすい。
(7)ルール生成部12は、サブルールが登録された端末から当該サブルールを削除するための削除ルールを生成し、当該サブルールを削除するタイミングを指定したイベント条件を削除ルールに設定し、削除ルールを処理装置に送信するルール分配装置。
そのような構成によれば、端末におけるサブルールによるマッチング処理が必要なくなったときに、端末からサブルールを削除することができる。それにより、端末のメモリ消費量およびCPUリソース消費量をより低減することができる。
(8)図17に示すように、処理装置および端末から処理能力を示す情報を受信する事前情報取得部13(図2に示すルール分配装置100における事前情報取得部120に相当。)と、事前情報取得部13が取得した処理能力を示す情報を記憶する事前情報記憶部14(図2に示すルール分配装置100における事前情報記憶部150に相当。)とを含み、ルール生成部12は、事前情報記憶部14が記憶する情報をもとに、第2のサブルールを送信する端末を決定するルール分配装置。
そのような構成によれば、処理装置および端末の処理能力に応じて、配置ルールのイベント条件に必要なイベントを送信させる端末を決定することができる。
(9)図17に示すように、処理ルールの削除要求を受信した場合に、当該処理ルールから生成した配置ルールの削除要求を当該配置ルールを登録した処理装置に送信し、当該処理ルールから生成したサブルールの削除要求を当該サブルールを登録した端末に送信するルール削除部15(図2に示すルール分配装置100におけるルール削除部(図示せず)に相当)を備えるルール分配装置。
そのような構成によれば、ルール分配装置、処理サーバおよび端末のメモリ消費量およびCPUリソース消費量をより低減することができる。
なお、図17に示すルール分配装置は、事前情報取得部13、事前情報記憶部14およびルール削除部15を含むが、事前情報取得部13および事前情報記憶部14と、ルール削除部15とのいずれかを含んでいてもよい。
また、上記の実施形態には、図18に示すようなイベント処理システムも開示されている。
(10)ルール分配装置10と、端末30-1~30-n(図1に示す端末300-1~300-nに相当。)と通信可能でありイベント処理を実行可能な処理装置20(図1に示す処理サーバ200に相当。)とを含み、ルール分配装置10は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部11と、処理ルールのイベント条件が含む1つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末30-1~30-nに登録するタイミングを指定したイベント条件を含む配置ルールを生成し、配置ルールとサブルールとを処理装置20に送信するルール生成部12とを含み、処理装置20は、配置ルールのイベント条件に従って端末が通知するイベントとのマッチング処理を実行し、イベントがイベント条件にマッチした場合には、当該端末にサブルールを送信する制御部21(図1に示す処理サーバ200における制御部(図示せず)に相当。)を備えるイベント処理システム。
そのような構成によれば、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。また、CEPにおいて動的な分散並列処理を実現することができる。また、サブルールを全端末に登録する必要がないので、サブルールを端末に配置する処理を軽減させることができる。また、端末のメモリ消費量を低減させることができる。従って、ネットワークにおけるリソースがボトルネックとなることを回避することができ、高いサービス品質を維持することができる。
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下
に限られない。
(付記1)ルール分配装置10と、端末30-1~30-nと通信可能でありイベント処理を実行可能な処理装置20とを含み、ルール分配装置10は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部11と、処理ルールのイベント条件が含む1つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末30-1~30-nに登録するタイミングを指定したイベント条件を含む配置ルールを生成し、配置ルールとサブルールとを処理装置20に送信するルール生成部12とを含み、処理装置20は、配置ルールのイベント条件に従って端末が通知するイベントとのマッチング処理を実行し、イベントがイベント条件にマッチした場合には、当該端末にサブルールを送信する制御部21を備えるイベント処理システム。
(付記2)イベント条件は、端末30-1~30-nから受信したイベントの属性値が所定の範囲内に含まれるか否かを判定する範囲指定属性条件を含み、ルール生成部12は、処理ルールの範囲指定属性条件の指定範囲をもとに当該指定範囲を含む新たな指定範囲を算出し、新たな指定範囲を配置ルールの範囲指定属性条件の指定範囲とする付記1に記載のイベント処理システム。
そのような構成によれば、範囲指定属性条件を含むイベント条件から構成されるCEPルールを、端末、処理サーバおよびネットワークの負荷を増大させることなく実行することができる。
(付記3)ルール生成部12は、ルール受信部11が処理ルールを受信したときに、当該処理ルールをもとに、端末に初期動作をさせるための第2のサブルールを生成し、第2のサブルールを端末に送信する付記1または付記2に記載のイベント処理システム。
そのような構成によれば、ルール受信部が処理ルールを受信するまで、つまり、アプリケーションから処理ルールが登録されるまで、第2のサブルールを端末に登録しておく必要がない。従って、端末のメモリ消費量をより低減させることができる。また、第2のサブルールによる端末からのイベント送信を抑えることができるので、端末、処理サーバおよびネットワークの負荷を低減することができる。また、例えば、端末に配置ルールのイベント条件に必要なイベントの送信を初期動作として実行させることができる。
(付記4)ルール受信部11は、固定エリアと端末とが指定範囲内に存在するか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部12は、範囲指定属性条件をイベント条件とし、処理装置20へ位置イベントを送信する処理をアクションとするサブルールを生成する付記1から付記3のうちのいずれか1つに記載のイベント処理システム。
そのような構成によれば、CEPルールのイベント条件にマッチしそうにない端末における不要なイベントの送信を抑えることができるので、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。
(付記5)ルール受信部11は、端末同士が指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部12は、位置イベントの送信をアクションとし、イベント条件に位置イベントを送信する周期を指定したサブルールを生成する付記1から付記3のうちのいずれか1つに記載のイベント処理システム。
そのような構成によれば、監視対象となる一方の位置が固定されていない状態、つまり、監視対象となる双方の位置が固定されていないサービスにおいても、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。
(付記6)ルール受信部11は、位置イベントの送信元の端末と位置イベント以外のイベントの送信元の端末とが指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部12は、範囲指定属性条件をイベント条件とするサブルールを生成し、サブルールのアクションに処理ルールのアクションを設定する付記1から付記3のうちのいずれか1つに記載のイベント処理システム。
そのような構成によれば、CEPルールのイベント条件に位置イベント以外のイベントが含まれる場合であっても、端末、処理サーバおよびネットワークの負荷を増大させることなくCEPルールを実行することができる。例えば、危険箇所事前通知サービスにおいてCEPルールを実行する際に、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなく危険箇所事前通知サービスを提供することができる。
(付記7)ルール生成部12は、処理装置20と端末30-1~30-nとが基地局を介して接続されている場合には、基地局に対して、基地局に接続している端末にサブルールのブロードキャストを依頼するアクションを規定した配置ルールを処理装置20に送信する付記6に記載のイベント処理システム。
そのような構成によれば、実行用サブルールの通知対象となる端末を特定するときに、各基地局のエリア情報を参照するだけでよい。従って、処理サーバは、各端末から位置イベントを受信する必要がないので、端末、処理サーバおよびネットワークの負荷をさらに低減させることができる。また、端末に位置イベントを通知させるための通知用サブルールを登録する必要がないので、通知用サブルールを端末に配置する処理をさらに軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることをより回避しやすい。
(付記8)ルール生成部12は、サブルールが登録された端末30-1~30-nから当該サブルールを削除するための削除ルールを生成し、当該サブルールを削除するタイミングを指定したイベント条件を削除ルールに設定し、削除ルールを処理装置20に送信する付記1から付記7のうちのいずれか1つに記載のイベント処理システム。
そのような構成によれば、端末におけるサブルールによるマッチング処理が必要なくなったときに、端末からサブルールを削除することができる。それにより、端末のメモリ消費量およびCPUリソース消費量をより低減することができる。
(付記9)ルール分配装置10は、処理装置20および端末30-1~30-nから処理能力を示す情報を受信する事前情報取得部13と、事前情報取得部13が取得した処理能力を示す情報を記憶する事前情報記憶部14とを含み、ルール生成部12は、事前情報記憶部14が記憶する情報をもとに、第2のサブルールを送信する端末を決定する付記3から付記8のうちのいずれか1つに記載のイベント処理システム。
そのような構成によれば、処理装置および端末の処理能力に応じて、配置ルールのイベント条件に必要なイベントを送信させる端末を決定することができる。
(付記10)ルール分配装置10は、処理ルールの削除要求を受信した場合に、当該処理ルールから生成した配置ルールの削除要求を当該配置ルールを登録した処理装置20に送信し、当該処理ルールから生成したサブルールの削除要求を当該サブルールを登録した端末に送信するルール削除部15を備える付記1から付記9のうちのいずれか1つに記載のイベント処理システム。
そのような構成によれば、ルール分配装置、処理サーバおよび端末のメモリ消費量およびCPUリソース消費量をより低減することができる。
この出願は、2012年8月31日に出願された日本特許出願2012-191260を基礎とする優先権を主張し、その開示の全てをここに取り込む。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。