JP2016095824A - イベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法 - Google Patents

Abstract

【課題】メッセージ転送の効率を向上することを可能とする。
【解決手段】実施形態のイベントドリブンシステムは、第１のキューと、第２のキューと、制御部とを有する。第１のキューは、転送元からイベントドリブンで転送されたイベントメッセージを保持する。第２のキューは、第１のキューで保持するイベントメッセージの種別毎に設けられ、イベントメッセージを種別毎に保持する。制御部は、第２のキューごとのフィルタ定義をもとに、第２のキューごとにフィルタを適用して、第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定する。そして、制御部は、決定結果に基づいて、第１のキューに保持されるイベントメッセージの保持状態を更新する。
【選択図】図２

Description

本発明の実施形態は、イベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法に関する。

会話や仕草などにより、人との間で親和的な対話（インタラクション）を行うロボットが開発されている。このインタラクションロボットの一態様としては、セラピーロボット、エンターテイメントロボットなどが挙げられる。

このインタラクションロボットは、人との対話等のイベントに対してイベントドリブン型の処理で反応を示す、即応性の高いシステムであることが重要である。このイベントドリブン型の処理を行うシステムとしては、ネットワーク分散型のイベントドリブンシステムがある。例えば、インタラクションロボットの場合、イベントを検知するセンサ側のシステムと、検知されたイベントに応じた動作を制御する制御側のシステムとが分散したイベントドリブンシステムがある。このようなネットワーク分散型のイベントドリブンシステムでは、必要な時に必要な機器（システム）と接続して動作できるとともに、処理のリソースを分散できる。

ネットワーク分散型のインベントドリブンシステムでは、互いのシステムがネットワークで接続された際に互いにイベントのメッセージ（以下、「イベントメッセージ」または単に「メッセージ」と呼ぶ）を転送しあう転送モジュールを有することで、システム同士の動作を連携している。このメッセージの送受信には、「メッセージキューイング」と呼ばれる方式が用いられている。

図２３は、従来の転送モジュール３００を示すブロック図である。図２３に示すように、転送モジュール３００は、メッセージ受信部３０１、静的フィルタ部３０２、キュー格納部３０４、キュー３０５、キュー取出部３０６およびメッセージ送信部３０７を有する。

メッセージ受信部３０１は、転送元メッセージを受信し、受信した転送元メッセージを静的フィルタ部３０２へ出力する。静的フィルタ部３０２は、静的フィルタ定義３０３に従って転送元メッセージのフィルタ処理を行い、フィルタ後の転送元メッセージをキュー格納部３０４に出力する。キュー格納部３０４は、静的フィルタ部３０２より出力されたメッセージをキュー３０５へ格納する。この転送元メッセージをキュー３０５に格納する処理は、転送元メッセージの受信ごとに順次行われる。

キュー取出部３０６は、キュー３０５に格納されたメッセージを取り出し、メッセージ送信部３０７に出力する。メッセージ送信部３０７は、キュー取出部３０６によってキュー３０５より取り出されたメッセージを所定の転送先に転送先メッセージとして送信する。この転送先メッセージを送信する処理は、システム同士が接続された際に行われる。このように、メッセージキューイングでは、システム間でやり取りされるメッセージをキュー３０５と呼ばれる記憶領域を介して交換する。

特表２００３−５３２２２０号公報 特表２００７−５０４５２９号公報

しかしながら、上記の従来技術では、キューから一律にメッセージが転送されるため、メッセージ転送の効率が悪く、イベントドリブンシステムにおける即時性の要求を十分に満足できないという問題がある。

例えば、インタラクションロボットでは、古くなったイベントに対する反応はイベントの種別によっては不要である場合があり、システム同士が接続した際に古いメッセージが送られると、不自然な応答になる可能性がある。また、古くなったイベントメッセージが数多くキューに格納されると、それらのイベントメッセージを転送する処理に時間がかかり、応答を行うのに時間を要する場合がある。

１つの側面では、メッセージ転送の効率を向上できるイベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法を提供することを目的とする。

第１の案では、イベントドリブンシステムは、第１のキューと、第２のキューと、制御部とを有する。第１のキューは、転送元からイベントドリブンで転送されたイベントメッセージを保持する。第２のキューは、第１のキューで保持するイベントメッセージの種別毎に設けられ、イベントメッセージを種別毎に保持する。制御部は、第２のキューごとのフィルタ定義をもとに、第２のキューごとにフィルタを適用して、第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定する。そして、制御部は、決定結果に基づいて、第１のキューに保持されるイベントメッセージの保持状態を更新する。

本発明の１実施態様によれば、メッセージ転送の効率を向上することができる。

図１は、第１の実施形態にかかるシステム構成例を説明する説明図である。 図２は、第１の実施形態にかかる転送モジュールの構成例を示すブロック図である。 図３は、第１の実施形態にかかるキューの構成例を説明する説明図である。 図４は、メインキューのみと、種別キューがある場合との比較を説明する説明図である。 図５は、動的フィルタ定義を説明する説明図である。 図６は、メッセージ受信の一例を示すフローチャートである。 図７は、メインキューに対する動的フィルタを適用する処理の一例を示すフローチャートである。 図８は、種別キューに対する動的フィルタを適用する処理の一例を示すフローチャートである。 図９は、動的フィルタの適用の一例を示すフローチャートである。 図１０は、メッセージ送信の一例を示すフローチャートである。 図１１は、第２の実施形態にかかるシステム構成例を説明する説明図である。 図１２は、第３の実施形態にかかるシステム構成例を説明する説明図である。 図１３は、第３の実施形態にかかる転送モジュールの構成例を示すブロック図である。 図１４は、第３の実施形態にかかるキューの構成例を説明する説明図である。 図１５は、メインキューに対する動的フィルタの一例を示すフローチャートである。 図１６は、種別キューに対する動的フィルタの一例を示すフローチャートである。 図１７は、メッセージ送信の一例を示すフローチャートである。 図１８は、第４の実施形態にかかる静的フィルタを適用する処理の一例を示すフローチャートである。 図１９は、第５の実施形態にかかるシステム構成例を説明する説明図である。 図２０は、第５の実施形態にかかる転送モジュールの構成例を示すブロック図である。 図２１は、第６の実施形態にかかる動的フィルタの適用の一例を示すフローチャートである。 図２２は、イベントドリブンプログラムを実行するコンピュータの一例について説明するための図である。 図２３は、従来の転送モジュールを示すブロック図である。

以下、図面を参照して、実施形態にかかるイベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法を説明する。実施形態において同一の機能を有する構成には同一の符号を付し、重複する説明は省略する。なお、以下の実施形態で説明するイベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法は、一例を示すに過ぎず、実施形態を限定するものではない。また、以下の各実施形態は、矛盾しない範囲内で適宜組みあわせてもよい。

（第１の実施形態）
図１は、第１の実施形態にかかるシステム構成例を説明する説明図である。図１に示すように、ネットワーク分散型のイベントドリブンシステムでは、システム１Ａとシステム１Ｂとが分散している。例えば、インタラクションロボットにネットワーク分散型のイベントドリブンシステムを用いる場合は、イベントを検知するセンサ側をシステム１Ａとし、検知されたイベントに応じた動作を制御する制御側をシステム１Ｂとしてもよい。

システム１Ａ、１Ｂは、クライアント２、メッセージプロバイダ３および転送モジュール４を有し、ＪＭＳ（Java（登録商標）メッセージサービス）等を用いてクライアント２間およびシステム１Ａ、１Ｂ間のメッセージの送受信を行う。クライアント２は、アプリケーションプログラム等であり、例えば、インタラクションロボットにおけるセンサ検知にかかるプログラム、制御にかかるプログラムなどである。メッセージプロバイダ３は、システム１Ａ、１Ｂ内のクライアント２からのメッセージを管理し、他のクライアント２または転送モジュール４へ受け取ったメッセージを出力する。

転送モジュール４は、転送元のメッセージをキューイングし、転送先との接続状態を監視しながら、キューイングしたメッセージを転送するモジュールである。この転送モジュール４におけるメッセージ転送は、ＪＭＳなどのｐｕｂ／ｓｕｂ（出版-購読型）のメッセージ基盤を使用し、非同期で動作してもよい。

例えば、システム１Ａの転送モジュール４は、内部のメッセージプロバイダ３が管理するメッセージをキューイングする。そして、転送先であるシステム１Ｂとの通信接続が開始されたところで、キューイングしたメッセージをシステム１Ｂのメッセージプロバイダ３へ転送する。逆に、システム１Ｂの転送モジュール４は、転送先であるシステム１Ａとの通信接続が開始されたところで、キューイングしたメッセージをシステム１Ａのメッセージプロバイダ３へ転送する。これにより、システム１Ａ、１Ｂ間におけるメッセージ転送が実現される。また、ＪＭＳのコネクションを長時間ロックしないように、メッセージは一旦テンポラリのキューに格納し、メッセージの受信はテンポラリのキューをポーリングするような実装にしてもよい。

図２は、第１の実施形態にかかる転送モジュール４の構成例を示すブロック図である。図２に示すように、転送モジュール４は、メッセージ受信部１０、静的フィルタ部１１、キュー格納部１２、キュー１３、動的フィルタ部１４、キュー取出部１５およびメッセージ送信部１６を有する。

メッセージ受信部１０は、メッセージプロバイダ３より転送元のメッセージ（転送元メッセージ）を受信し、受信した転送元メッセージを静的フィルタ部１１へ出力する。静的フィルタ部１１は、メモリなどに予め設定された静的フィルタ定義１１１に従い、転送元メッセージのフィルタリングを行って、フィルタリング後の転送元メッセージをキュー格納部１２へ出力する。

静的フィルタ部１１におけるフィルタリングは、転送元メッセージを選別してキュー１３に格納するために行われるものであり、転送元メッセージに対してキュー１３への格納時などに一度行われる。また、静的フィルタ定義１１１における選別の条件は、時間が経過しても変動することのない、静的なものである。

例えば、インタラクションロボットの例では、センサ側で検知されたイベントの中で制御側に通知するイベントは限られている。具体的には、人物の有無などのセンサの検知結果は制御側に通知するイベントである。これに対し、センサの異常を示すステータス情報などは制御側に通知しなくてもよく、センサ側で対処すべきイベントである。静的フィルタ部１１では、このような通知の有無にかかる選別を行う。

キュー格納部１２は、静的フィルタ部１１より出力された転送元メッセージをキュー１３へ格納する。キュー１３は、転送元メッセージを順次格納するメインキュー１３１と、転送元メッセージを種別ごとに分けて格納する種別キュー１３２ａ、１３２ｂ、１３２ｃとを有する。

キュー格納部１２は、転送元メッセージをメインキュー１３１の最後へ格納するとともに、転送元メッセージのプロパティなどに記述された情報をもとに、メッセージにおけるイベントの種別を判定し、判定した種別ごとに種別キュー１３２ａ、１３２ｂ、１３２ｃの最後へ格納する。

イベントの種別には、センサ検出による検出イベント、状態の変化などを示す状態イベント、アクチュエータなどへの指示を示す指示イベント、動作モードの変更などを示すモード変更イベントなど、様々なものがある。

例えば、インタラクションロボットの例では、検出イベントとして、ユーザがタッチセンサに触れた場合、笑顔を検出した場合、ユーザの手振りを検出した場合などがある。また、状態イベントとしては、人がいなくなったことを検出した場合、日中、夜間などの現在の時間帯の変化を検出した場合などがある。また、指示イベントとしては、タッチされて喜ぶ反応を行う反応動作、手振りに対して振り返す反応動作などがある。また、モード変更イベントとしては、人がいなくなったので省エネモードへ移行する場合、現在の時間帯が夜間なのでスリープモードへ移行する場合などがある。

これらのイベントの種別は、メッセージのプロパティなどに種別を示す情報として記述されている。キュー格納部１２は、このプロパティなどを参照して、転送元メッセージにおけるイベントの種別に対応した種別キュー１３２ａ、１３２ｂ、１３２ｃへメッセージの内容を格納する。

メインキュー１３１と、種別キュー１３２ａ、１３２ｂ、１３２ｃとは、互いに参照可能な双方向のリスト構造を有し、格納されるメッセージ（要素）の参照から削除が容易となっている。

図３は、第１の実施形態にかかるキューの構成例を説明する説明図である。具体的には、図３では、メインキュー１３１と、種別キュー１３２ａとを例示している。図３に示すように、メインキュー１３１と、種別キュー１３２ａとには、転送元メッセージが要素ＭＤ_ｋ、要素ＳＤ_ｋとして格納される。

ここで、要素ＭＤ_ｋ−１は要素ＭＤ_ｋより一つ前の要素であり、要素ＭＤ_ｋ＋１は要素ＭＤ_ｋより次の要素である。同様に、要素ＳＤ_ｋ−１は要素ＳＤ_ｋより一つ前の要素であり、要素ＳＤ_ｋ＋１は要素ＳＤ_ｋより次の要素である。

メインキュー１３１における各要素（ＭＤ_ｋ−１、ＭＤ_ｋ、ＭＤ_ｋ＋１…）は、種々の情報を格納するための領域Ｒ１、Ｒ２、Ｒ３、Ｒ４を有する。領域Ｒ１は、転送元メッセージの内容を格納する。領域Ｒ２、Ｒ３は前の要素または次の要素への参照ための情報（例えばポインタ）を格納する。領域Ｒ４は、対応する種別キュー１３２ａの要素への参照のための情報（例えばポインタ）を格納する。

種別キュー１３２ａにおける各要素（ＳＤ_ｋ−１、ＳＤ_ｋ、ＳＤ_ｋ＋１…）は、種々の情報を格納するための領域Ｒ１１、Ｒ１２、Ｒ１３、Ｒ１４を有する。領域Ｒ１１は、対応するメインキュー１３１の要素への参照のための情報（例えばポインタ）を格納する。領域Ｒ１２、Ｒ１３は前の要素または次の要素への参照ための情報（例えばポインタ）を格納する。領域Ｒ４は、メッセージにおけるイベントの種別ごとの情報、すなわち、動的フィルタの実行に必要となる動的フィルタ判断情報を格納する。具体的には、検出イベントにおける検出内容、状態イベントにおける状態の内容、指示イベントにおける指示内容、モード変更イベントにおける変更後の動作モードなどが動的フィルタ判断情報として領域Ｒ４に格納される。

メインキュー１３１と、種別キュー１３２ａとは、図３に示すような互いに参照可能な双方向のリスト構造であることから、メインキュー１３１に格納されたメッセージのイベントの種別ごとの操作（例えば、参照や削除）を容易に行うことができる。

図４は、メインキュー１３１のみと、種別キュー１３２ａ、１３２ｂ、１３２ｃがある場合との比較を説明する説明図である。ここで、上段のケースＣ１はメインキュー１３１のみの場合を、下段のケースＣ２はメインキュー１３１の他に種別キュー１３２ａ、１３２ｂ、１３２ｃがある場合を例示している。また、メインキュー１３１に格納されるメッセージは、イベントＥ１、Ｅ２、Ｅ３の３種類のイベントであるものとし、それぞれの寿命は期間Ｔ１１、Ｔ１２、Ｔ１３であるものとする。また、イベントＥ１のメッセージは種別キュー１３２ａに、イベントＥ２のメッセージは種別キュー１３２ｂに、イベントＥ３のメッセージは種別キュー１３２ｃに、それぞれメインキュー１３１と互いに参照可能に格納される。

図４に示すように、ケースＣ１では、イベントＥ１、Ｅ２、Ｅ３のメッセージを操作しようとする場合は、メインキュー１３１の要素を全検索しなければならない。例えば、イベントＥ１、Ｅ２、Ｅ３のそれぞれの寿命に応じてメッセージを削除する場合には、メインキュー１３１の要素を全検索して寿命が尽きたメッセージを削除していくこととなる。これに対し、ケースＣ２では、種別キュー１３２ａ、１３２ｂ、１３２ｃのそれぞれに操作を行えばよく、メインキュー１３１の要素を全検索する必要がない。例えば、イベントＥ１、Ｅ２、Ｅ３のそれぞれの寿命に応じてメッセージを削除する場合には、種別キュー１３２ａ、１３２ｂ、１３２ｃごとのメッセージの削除と、参照によるメインキュー１３１のメッセージの削除とを行えばよい。

動的フィルタ部１４は、キュー１３に格納されたメッセージに対して、メモリなどに予め設定された動的フィルタ定義１４１を適用したフィルタリングを行う。動的フィルタ定義１４１における選別の条件は、メッセージの要／不要の判断が時間の経過によって変動するものであり、動的なものである。したがって、動的フィルタ部１４におけるフィルタリングは、転送元メッセージをキュー１３に格納するタイミング、キュー１３に格納された転送元メッセージを送信するタイミング、所定の時間間隔などでキュー１３に対して実施される。

具体的には、メインキュー１３１に対する動的フィルタの場合、動的フィルタ部１４は、メインキュー１３１の最初（古い）のメッセージから順に動的フィルタ定義１４１を適用し、メッセージを削除するか残すかの選別を行う。フィルタされる場合、動的フィルタ部１４は、メインキュー１３１と、参照される種別キュー１３２ａ、１３２ｂ、１３２ｃとから該当のメッセージを削除する。

また、種別キュー１３２ａ、１３２ｂ、１３２ｃに対する動的フィルタの場合、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃの最初（古い）のメッセージから順に動的フィルタ定義１４１を適用し、メッセージを削除するか残すかの選別を行う。フィルタされる場合、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃと、参照されるメインキュー１３１から該当のメッセージを削除する。

また、メッセージの要／不要の判断が時間の経過によって変動する選別の条件は、イベントの種別によって異なる。具体的には、インタラクションロボットの例では、検出イベント、状態イベント、指示イベントまたはモード変更イベントによって異なる。ユーザがタッチセンサに触れたなどの検出イベントや反応動作などの指示イベントは、即座に応答や指示が必要であるが、時間の経過によって必要としなくなる場合がある。また、状態イベントやモード変更イベントなどは、多少の遅れは許容できるが、確実に転送することが望まれる。したがって、動的フィルタ定義１４１では、例えば、イベントの種別ごとにフィルタが定義されている。

図５は、動的フィルタ定義１４１を説明する説明図である。図５に示すように、動的フィルタ定義１４１には、タッチセンサのイベント、人の入退場のイベント、発話指示のイベントなどのイベントごとの定義Ｄ１〜Ｄ３が記述されている。具体的には、イベントごとの種別キュー１３２ａ、１３２ｂ、１３２ｃにおけるキューサイズ、適用するフィルタの種類と、フィルタの条件などが記述されている。このフィルタの種類については、イベントの有効時間（寿命）でフィルタする「有効時間フィルタ」、所定の条件を満たした状態イベントのメッセージを削除する「イベントフィルタ」および所定の転送レートでメッセージを転送するための間引きを行う「転送レートフィルタ」などがある。

例えば、定義Ｄ１におけるタッチセンサのイベントについては、キューサイズ「２０」とし、有効時間（ｓ）を「３」とする「有効時間フィルタ」と、「転送レートフィルタ」とが定義されている。転送レートフィルタでは、キュー１３からメッセージの間引きを開始するタイミングを「５」、間引きで無効にするメッセージの属性を「タッチ」およびキューの最大保持数を「１０」とする間引きの条件が定義されている。このため、タッチセンサのイベントについては、３秒だけキュー１３に保持され、３秒経過後には動的フィルタ部１４によって削除される。また、タッチセンサのイベントについては、転送レートフィルタで定義された条件で動的フィルタ部１４によりキュー１３からメッセージが間引きされる。

また、定義Ｄ２における入退場イベントについては、有効時間を「６００」とする「有効時間フィルタ」が定義されている。このため、入退出イベントについては、１０分間保持される。

また、定義Ｄ３における発話指示イベントについては、キューサイズ「１」とし、人（Ａ）の退出イベントを削除の条件とする「イベントフィルタ」と、有効時間（ｓ）を「６０」とする「有効時間フィルタ」とが定義されている。このため、発話指示イベントについては、６０秒（１分）間だけキュー１３に保持され、１分経過後には動的フィルタ部１４によって削除される。また、人（Ａ）が退出した条件を満たす場合も動的フィルタ部１４によって削除される。

キュー取出部１５は、キュー１３に格納されたメッセージを取り出しメッセージ送信部１６へ出力する。具体的には、キュー取出部１５は、メインキュー１３１の最初（古い）のメッセージから順に取り出し、メッセージ送信部１６へ出力する。メッセージ送信部１６は、キュー取出部１５より出力されたメッセージをネットワークなどを介して接続された転送先（例えば、システム１Ａにおけるシステム１Ｂ）へ転送する。キュー取出部１５は、転送先へのメッセージの転送に成功したところで、取り出したメインキュー１３１の要素と、対応する種別キュー１３２ａ、１３２ｂ、１３２ｃの要素とを削除する。なお、キュー格納部１２によりキュー１３へメッセージを格納する処理と、キュー取出部１５によりキュー１３からメッセージを取り出す処理とは、データの整合性を取るために排他処理で行われる。

次に、転送元メッセージの受信時に行われる処理を説明する。図６は、メッセージ受信の一例を示すフローチャートである。

図６に示すように、処理が開始されると、メッセージ受信部１０は、メッセージプロバイダ３からの転送元メッセージの受信を待ち（Ｓ１）、メッセージの有無を判定する（Ｓ２）。メッセージがない場合（Ｓ２：ＮＯ）、メッセージ受信部１０は、Ｓ１へ処理を戻して待機する。

メッセージが有る場合（Ｓ２：ＹＥＳ）、メッセージ受信部１０はメッセージプロバイダ３から転送元メッセージを受信し（Ｓ３）、メッセージを受信した時刻を取得する（Ｓ４）。次いで、静的フィルタ部１１は、静的フィルタ定義１１１をもとに、メッセージ受信部１０が受信した転送元メッセージの静的フィルタ処理を行って（Ｓ５）、選別によりメッセージが有効であるか否かを判定する（Ｓ６）。メッセージが有効でない場合（Ｓ６：ＮＯ）、静的フィルタ部１１はＳ１へ処理を戻す。したがって、転送元メッセージはキュー１３に格納されない。

メッセージが有効である場合（Ｓ６：ＹＥＳ）、動的フィルタ部１４は、有効であると判定されたメッセージのイベント種別をプロパティ等を参照して判断する（Ｓ７）。次いで、動的フィルタ部１４は、動的フィルタ定義１４１をもとに、判断されたイベント種別の種別キューに格納されたメッセージに対して動的フィルタを適用する（Ｓ８）。次いで、キュー格納部１２は、有効であると判定されたメッセージにかかる要素をメインキュー１３１に追加する（Ｓ９）。

次いで、キュー格納部１２は、判断されたイベント種別をもとに、メッセージから動的フィルタ判断情報を生成する（Ｓ１０）。具体的には、検出イベントにおける検出内容、状態イベントにおける状態の内容、指示イベントにおける指示内容、モード変更イベントにおける変更後の動作モードなどが生成される。例えば、検出イベントにおけるタッチセンサイベントでは、タッチセンサの検出結果とともに、有効時間を判定するために、Ｓ４で取得した時刻などを含む情報が動的フィルタ判断情報として生成される。

次いで、キュー格納部１２は、生成した動的フィルタ判断情報を含む要素をＳ９で判断された種別に対応する種別キューへ追加する（Ｓ１１）。次いで、キュー格納部１２は、メインキュー１３１へ追加した要素と種別キューへ追加した要素とが互いに参照できるように、メインキュー１３１および種別キューの互いの要素にリファレンスを保持させる（Ｓ１２）。

次いで、動的フィルタ部１４は、動的フィルタ定義１４１を参照し、種別キュー１３２ａ、１３２ｂ、１３２ｃにおけるキューサイズ（最大キュー数（ｍａｘＡ））を取得し（Ｓ１３）、現在の種別キュー１３２ａ、１３２ｂ、１３２ｃのキュー数（ｃｎｔＡ）を取得する（Ｓ１４）。次いで、キュー格納部１２は、ｃｎｔＡ＞ｍａｘＡであるか否かを判定する（Ｓ１５）。

ここで、現在のキュー数が最大キュー数を超えない場合（Ｓ１５：ＮＯ）、動的フィルタ部１４はそのままＳ１へ処理を戻す。また、現在のキュー数が最大キュー数を超える場合（Ｓ１５：ＹＥＳ）、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃにおける最初（古い）の要素を削除し（Ｓ１６）、この削除した要素と対応するメインキュー１３１の要素を削除して（Ｓ１７）、Ｓ１へ処理を戻す。これにより、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃにおけるキューサイズが動的フィルタ定義１４１に定義されたキューサイズを超えないようにすることができる。

次に、動的フィルタの適用について説明する。図７は、メインキュー１３１に対する動的フィルタを適用する処理の一例を示すフローチャートであり、例えば、送信時のフローから呼ばれる処理の一例である。

図７に示すように、処理が開始されると、動的フィルタ部１４は、メインキュー１３１の要素を最初（古い）の要素から順に取得し（Ｓ２０）、要素を取得できたか否かを判定する（Ｓ２１）。取得できなかった場合（Ｓ２１：ＮＯ）、メインキュー１３１のすべての要素に対して動的フィルタを適用したことから、動的フィルタ部１４は処理を終了する。

取得できた場合（Ｓ２１：ＹＥＳ）、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃにおいて対応する要素を参照し、メッセージのイベント種別を判断する（Ｓ２２）。次いで、動的フィルタ部１４は、動的フィルタ定義１４１を取得し（Ｓ２３）、対応する種別キュー１３２ａ、１３２ｂ、１３２ｃの要素を取得する（Ｓ２４）。次いで、動的フィルタ部１４は、取得した動的フィルタ定義１４１と、種別キュー１３２ａ、１３２ｂ、１３２ｃの要素に含まれる動的フィルタ判断情報とを使って動的フィルタを適用し（Ｓ２５）、転送が不要な要素であるか否かを選別する（Ｓ２６）。なお、動的フィルタ定義１４１と動的フィルタ判断情報とを使った動的フィルタの詳細は後述する。

動的フィルタの適用の結果、転送が不要であると判定された場合（Ｓ２６：ＹＥＳ）、動的フィルタ部１４は、対象の要素について、メインキュー１３１からの削除と（Ｓ２７）、種別キュー１３２ａ、１３２ｂ、１３２ｃからの削除（Ｓ２８）とを行い、Ｓ２０へ処理を戻す。なお、Ｓ２６において否定の判定である場合（Ｓ２６：ＮＯ）、動的フィルタ部１４は、対象の要素について削除することなくそのまま残し、処理を終了する。これにより、転送が必要なもの（例えば、削除されることなく残された要素）が、送信処理によって転送されることとなる。

図８は、種別キュー１３２ａ、１３２ｂ、１３２ｃに対する動的フィルタを適用する処理の一例を示すフローチャートである。

図８に示すように、処理が開始されると、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃの要素を最初（古い）の要素から順に取得し（Ｓ３０）、要素を取得できたか否かを判定する（Ｓ３１）。取得できなかった場合（Ｓ３１：ＮＯ）、種別キュー１３２ａ、１３２ｂ、１３２ｃのすべての要素に対して動的フィルタを適用したことから、動的フィルタ部１４は処理を終了する。

取得できた場合（Ｓ３１：ＹＥＳ）、動的フィルタ部１４は、動的フィルタ定義１４１を取得し（Ｓ３２）、取得した動的フィルタ定義１４１と、種別キュー１３２ａ、１３２ｂ、１３２ｃの要素に含まれる動的フィルタ判断情報とを使って動的フィルタを適用する（Ｓ３３）。この動的フィルタの適用により、動的フィルタ部１４は、転送が不要な要素であるか否かを選別する（Ｓ３４）。

動的フィルタの適用の結果、転送が不要であると判定された場合（Ｓ３４：ＹＥＳ）、動的フィルタ部１４は、対象の要素について、メインキュー１３１の要素を取得し（Ｓ３５）、メインキュー１３１からその要素を削除する（Ｓ３６）。次いで、動的フィルタ部１４は、対象の要素について、種別キュー１３２ａ、１３２ｂ、１３２ｃからの削除を行い（Ｓ３７）、Ｓ３０へ処理を戻す。なお、なお、Ｓ３４において否定の判定である場合（Ｓ３４：ＮＯ）、動的フィルタ部１４は、対処の要素について削除することなくそのまま残し、Ｓ３０へ処理を戻す。

次に、動的フィルタ定義１４１と動的フィルタ判断情報とを使った動的フィルタの適用について説明する。図９は、動的フィルタの適用の一例を示すフローチャートである。

図９に示すように、Ｓ２５、Ｓ３３などで処理が開始されると、動的フィルタ部１４は、動的フィルタ定義１４１をもとに、動的フィルタの対象となる要素のイベント種別について定義されているフィルタの内容を判定する（Ｓ４０）。イベント種別については、上述した「有効時間フィルタ」、「イベントフィルタ」および「転送レートフィルタ」等がある。図９のフローでは、例えば、図５の動的フィルタ定義１４１を、全ての定義が終了するまで（Ｓ５６：ＹＥＳ）全て順に処理する。

フィルタの内容が「有効時間フィルタ」である場合、動的フィルタ部１４は、要素に含まれる動的フィルタ判断情報を参照し、要素のイベントが動的フィルタ定義１４１に定義された有効時間を満たすか否かを判定して、メッセージの選別を行う。

具体的には、動的フィルタ部１４は、現在時刻（ｃ）を取得し（Ｓ４１）、動的フィルタ判断情報であるイベントの時刻（ｔ）に、動的フィルタ定義１４１に定義された有効時間（Ｔ）を加えたｔ＋Ｔについて、ｃ＞ｔ＋Ｔであるか否かを判定する（Ｓ４２）。ｃ＞ｔ＋Ｔでない場合（Ｓ４２：ＮＯ）、現在時刻はイベントの有効時間内であることから、動的フィルタ部１４は、メッセージを有効と判断（選別）する（Ｓ４３）。

また、ｃ＞ｔ＋Ｔである場合（Ｓ４２：ＹＥＳ）、現在時刻はイベントの有効時間を過ぎていることから、動的フィルタ部１４は、メッセージを無効と判断（選別）する（Ｓ４４）。メッセージを無効とした場合（Ｓ４４）は、そのメッセージは転送不要となったことから、他の動的フィルタ定義１４１の処理を行わずに処理を抜ける（終了する）こととなる。

フィルタの内容が「イベントフィルタ」である場合、動的フィルタ部１４は、要素に含まれる動的フィルタ判断情報を参照し、要素のイベントが動的フィルタ定義１４１に定義された状態イベントであるか否かを判定して、メッセージの選別を行う。

具体的には、動的フィルタ部１４は、動的フィルタ定義１４１に定義された状態イベントの条件を取得し（Ｓ４５）、要素に含まれる動的フィルタ判断情報が示すイベントの状態が定義された条件を満たすか否かを判定する（Ｓ４６）。例えば、図５に例示した定義Ｄ３であり、要素に含まれるイベントの状態が人の退室である場合は、条件を満たすものと判定される。

条件を満たさない場合（Ｓ４６：ＮＯ）、「イベントフィルタ」でフィルタリングされるメッセージでないことから、動的フィルタ部１４は、メッセージを有効と判断（選別）する（Ｓ４７）。また、条件を満たす場合（Ｓ４６：ＹＥＳ）、「イベントフィルタ」でフィルタリングされるメッセージであることから、動的フィルタ部１４は、メッセージを無効と判断（選別）する（Ｓ４８）。メッセージを無効とした場合（Ｓ４８）は、そのメッセージは転送不要となったことから、他の動的フィルタ定義１４１の処理を行わずに処理を抜ける（終了する）こととなる。

フィルタの内容が「転送レートフィルタ」である場合、動的フィルタ部１４は、単位時間あたりにおけるキューの格納速度（Ｒｉｎ）と、キューの取り出し速度（Ｒｏｕｔ）とを取得する（Ｓ４９、Ｓ５０）。このキューの格納速度および取り出し速度は、単位時間あたりにキュー１３へ格納されたメッセージの数や、取り出されたメッセージの数を計数することで算出できる。

次いで、動的フィルタ部１４は、取得したＲｉｎ、Ｒｏｕｔをもとに、動的フィルタ定義１４１に定義されたメッセージの間引きを発動するための条件を満たすか否かを判定する（Ｓ５１）。具体的には、図５に例示した定義Ｄ４の間引きを開始するタイミング（Ｔｈ）と、キューの最大保持数（ＭＡＸＱ）とをもとに、ＭＡＸＱ／（Ｒｉｎ−Ｒｏｕｔ）＞Ｔｈ等の発動の条件を満たすか否かを判定する。

発動の条件を満たさない場合（Ｓ５１：ＹＥＳ）、動的フィルタ部１４は、メッセージの間引きをおこなうことなく、メッセージを有効と判断（選別）する（Ｓ５２）。

発動の条件を満たす場合（Ｓ５１：ＮＯ）、動的フィルタ部１４は、動的フィルタ定義１４１に定義された間引きで無効にするメッセージ属性（ＹＹ）に相当するメッセージを、所定の間隔（例えば、１／（Ｒｉｎ−Ｒｏｕｔ）に１件）で間引きする。具体的には、動的フィルタ部１４は、メッセージの属性（ｙ）がＹＹであり、かつ、Ｔ−ｔ＞１／（Ｒｉｎ−Ｒｏｕｔ）であるか否かを判定する（Ｓ５３）。動的フィルタ部１４は、Ｓ５３において肯定である場合にメッセージを無効と判断（選別）し（Ｓ５４）、否定である場合にメッセージを有効と判断（選別）する（Ｓ５５）。メッセージを無効とした場合（Ｓ５４）は、そのメッセージは転送不要となったことから、他の動的フィルタ定義１４１の処理を行わずに処理を抜ける（終了する）こととなる。

メッセージを有効とした場合（Ｓ４３、Ｓ４７、Ｓ５２、Ｓ５５）、動的フィルタ部１４は、動的フィルタ定義１４１の全ての定義についてＳ４０〜Ｓ５５の処理が終了したか否かを判定する（Ｓ５６）。全ての定義について終了している場合（Ｓ５６：ＹＥＳ）、動的フィルタ部１４は処理を終了する。Ｓ５６において未終了である場合（Ｓ５６：ＮＯ）、動的フィルタ部１４は、Ｓ４０へ処理を戻し、未終了である定義についての処理を継続する。

次に、転送元メッセージの送信時に行われる処理を説明する。図１０は、メッセージ送信の一例を示すフローチャートである。

図１０に示すように、処理が開始されると、転送モジュール４は、一定時間処理を待機する（Ｓ６０）。次いで、動的フィルタ部１４は、動的フィルタ定義１４１に対して動的フィルタを適用する（Ｓ６１）。この動的フィルタの適用は、一定時間ごとであってもよいし、転送先にメッセージを送信する際（Ｓ６６）に行ってもよい。

次いで、キュー取出部１５は、メインキュー１３１の要素を最初（古い）の要素から順に取得し（Ｓ６２）、取得できたか否かを判定する（Ｓ６３）。取得できなかった場合（Ｓ６３：ＮＯ）は、転送するメッセージがないことから、キュー取出部１５はＳ６０へ処理を戻す。

取得できた場合（Ｓ６３：ＹＥＳ）、メッセージ送信部１６は、転送先との接続確認を行い（Ｓ６４）、接続中であるか否かを判定する（Ｓ６５）。接続中でない場合（Ｓ６５：ＮＯ）、転送先との接続がないことから、メッセージ送信部１６はＳ６０へ処理を戻す。

接続中である場合（Ｓ６５：ＹＥＳ）、メッセージ送信部１６は、キュー取出部１５がメインキュー１３１より取得したメッセージを送信し（Ｓ６６）、受領通知などを確認することで送信が成功したか否かを判定する（Ｓ６７）。送信が失敗した場合（Ｓ６７：ＮＯ）、メッセージが転送先に送れなかったことから、メッセージ送信部１６はＳ６０へ処理を戻す。

送信が成功した場合（Ｓ６７：ＹＥＳ）、メッセージが転送先に送れたことから、キュー取出部１５は、送信したメッセージに対応する種別キュー１３２ａ、１３２ｂ、１３２ｃの要素を取得する（Ｓ６８）。次いで、キュー取出部１５は、送信したメッセージの要素を、メインキュー１３１および種別キュー１３２ａ、１３２ｂ、１３２ｃから削除し（Ｓ６９、Ｓ７０）、Ｓ６１へ処理を戻す。

このように、動的フィルタ部１４は、動的フィルタ定義１４１による種別キュー１３２ａ、１３２ｂ、１３２ｃごとのフィルタ定義をもとに、種別キュー１３２ａ、１３２ｂ、１３２ｃごとにフィルタを適用して、種別キュー１３２ａ、１３２ｂ、１３２ｃに保持されるメッセージを削除するか、残して転送先へ転送するかを決定する。そして、動的フィルタ部１４は、動的フィルタ定義１４１による決定結果に基づいて、メインキュー１３１に保持されるメッセージの保持状態を更新する。このため、キュー１３には、時間の経過とともに、転送に必要なメッセージが残されることとなる。したがって、システム１Ａ、１Ｂにおけるイベントドリブンシステムでは、キュー１３によるメッセージ転送の効率をよくすることができる。

（第２の実施形態）
図１１は、第２の実施形態にかかるシステム構成例を説明する説明図である。図１１に示すように、システム１Ｃが転送する転送先がシステム１Ａ、１Ｂであり、それぞれの転送ルール（例えば、通信プロトコル）が異なる場合は、それぞれの転送ルールに対応した転送モジュール４Ａ、４Ｂを有するように構成してもよい。

この第２の実施形態では、転送モジュール４Ａ、４Ｂについては、メッセージ送信部１６が転送先にメッセージを送る際の転送ルールを変更するだけでよく、他の構成は第１の実施形態と同様の構成とすることができる。ただし、転送モジュール４Ａ、４Ｂにおいて処理が重複する場合には、その分のリソースを用意する必要がある。

（第３の実施形態）
図１２は、第３の実施形態にかかるシステム構成例を説明する説明図である。図１２に示すように、第３の実施形態にかかるシステム１Ｄは、共通の転送モジュール４Ｄによりシステム１Ａ、１Ｂ、１Ｃへの転送を行う点が第２の実施形態とは異なる。

図１３は、第３の実施形態にかかる転送モジュール４Ｄの構成例を示すブロック図である。図１３に示すように、転送モジュール４Ｄは、転送先ごとの転送スレッド１７Ａ、１７Ｂを用意している。これにより、転送ルールの異なる複数のシステムへ転送する場合であっても、メッセージ受信部１０、静的フィルタ部１１、キュー格納部１２、キュー１３および動的フィルタ部１４を共通化できる。

図１４は、第３の実施形態にかかるキュー１３の構成例を説明する説明図である。図１４に示すように、メインキュー１３１の要素は、転送先毎の転送済みフラグを格納する領域Ｒ５を有する。この転送済みフラグは、転送先ごとの転送の有無を示すフラグである。転送スレッド１７Ａ、１７Ｂは、領域Ｒ５を参照することで、全てのスレッドで転送が完了したか否かを判定することができる。

ここで、第３の実施形態における動的フィルタの適用について説明する。図１５は、メインキュー１３１に対する動的フィルタの一例を示すフローチャートである。

図１５に示すように、処理が開始されると、動的フィルタ部１４は、メインキュー１３１のチェック済みの位置の次の要素を順次取得し（Ｓ１０１）、要素を取得できたか否かを判定する（Ｓ１０２）。取得できなかった場合（Ｓ１０２：ＮＯ）、メインキュー１３１のすべての要素に対して動的フィルタを適用したことから、動的フィルタ部１４は処理を終了する。なお、メインキュー１３１のチェック済み位置は、メインキュー１４１のフィルタと共通の値であり、転送スレッド単位で管理する変数等である。このように、メインキュー１３１のチェック済み位置は、転送スレッドごとに管理されており、Ｓ１０１、Ｓ１０２でチェックした場合に更新される。これにより、次にメインキュー１３１へ動的フィルタを適用する場合は、更新後のチェック済み位置から開始される。

取得できた場合（Ｓ１０２：ＹＥＳ）、動的フィルタ部１４は、取得した要素の転送済みフラグが「ｔｒｕｅ」であるか否かを判定する（Ｓ１０３）。「ｔｒｕｅ」である場合（Ｓ１０３：ＹＥＳ）は、取得した要素については既に処理済み（転送済みまたはフィルタ済み）である。したがって、この場合は動的フィルタを適用することなく、動的フィルタ部１４はＳ１１０へ処理を進める。

「ｔｒｕｅ」でない場合（Ｓ１０３：ＮＯ）、動的フィルタ部１４は、前述したＳ２２〜Ｓ２６と同様に動的フィルタを適用する処理を行う（Ｓ１０４〜Ｓ１０８）。

次いで、動的フィルタの適用の結果、転送が不要であると判定された場合（Ｓ１０８：ＹＥＳ）、動的フィルタ部１４は、自身の転送済みフラグを「ｔｒｕｅ」に設定し（Ｓ１０９）、転送済みフラグを参照して全てのスレッドが要素を転送済みであるか否かを判定する（Ｓ１１０）。

全てのスレッドが要素を転送済みである場合（Ｓ１１０：ＹＥＳ）、動的フィルタ部１４は、対象の要素について、種別キュー１３２ａ、１３２ｂ、１３２ｃの要素を削除し（Ｓ１１１）、メインキュー１３１からの削除を行って（Ｓ１１２）、Ｓ１０１へ処理を戻す。なお、Ｓ１０８において否定の判定であり（Ｓ１０８：ＮＯ）、転送すべきメッセージを見つけた時点で、動的フィルタ部１４は処理を終了する。

図１６は、種別キュー１３２ａ、１３２ｂ、１３２ｃに対する動的フィルタの一例を示すフローチャートである。

図１６に示すように、処理が開始されると、動的フィルタ部１４は、種別キュー１３２ａ、１３２ｂ、１３２ｃの要素を最初（古い）の要素から順に取得し（Ｓ１２０）、要素を取得できたか否かを判定する（Ｓ１２１）。取得できなかった場合（Ｓ１２１：ＮＯ）、種別キュー１３２ａ、１３２ｂ、１３２ｃのすべての要素に対して動的フィルタを適用したことから、動的フィルタ部１４は処理を終了する。

取得できた場合（Ｓ１２１：ＹＥＳ）、動的フィルタ部１４は、対応するメインキュー１３１の要素を取得し（Ｓ１２２）、取得した要素の転送済みフラグが「ｔｒｕｅ」であるか否かを判定する（Ｓ１２３）。「ｔｒｕｅ」である場合（Ｓ１２３：ＹＥＳ）は、いずれかの転送先へ転送済みであり、フィルタすることで転送先ごとのメッセージに整合性が取れなくなる。したがって、この場合は動的フィルタを適用することなく、動的フィルタ部１４はＳ１２８へ処理を進める。

「ｔｒｕｅ」でない場合（Ｓ１２３：ＮＯ）、動的フィルタ部１４は、前述したＳ３２〜Ｓ３４と同様に動的フィルタを適用する処理を行う（Ｓ１２４〜Ｓ１２６）。

次いで、動的フィルタの適用の結果、転送が不要であると判定された場合（Ｓ１２６：ＹＥＳ）、動的フィルタ部１４は、自身の転送済みフラグを「ｔｒｕｅ」に設定し（Ｓ１２７）、転送済みフラグを参照して全てのスレッドが要素を転送済みであるか否かを判定する（Ｓ１２８）。

全てのスレッドが要素を転送済みである場合（Ｓ１２８：ＹＥＳ）、動的フィルタ部１４は、対象の要素について、種別キュー１３２ａ、１３２ｂ、１３２ｃの要素を削除する（Ｓ１２９）。次いで、動的フィルタ部１４は、メインキュー１３１からの削除を行って（Ｓ１３０）、処理対象を次の要素とするようにＳ１２０へ処理を戻す。

次に、第３の実施形態において、転送元メッセージの送信時に行われる処理を説明する。図１７は、メッセージ送信の一例を示すフローチャートである。

図１７に示すように、処理が開始されると、転送モジュール４は、一定時間処理を待機する（Ｓ１４０）。次いで、動的フィルタ部１４は、動的フィルタ定義１４１に対して動的フィルタを適用する（Ｓ１４１）。この動的フィルタの適用は、一定時間ごとであってもよいし、転送先にメッセージを送信する際（Ｓ１４６）に行ってもよい。

次いで、キュー取出部１５は、メインキュー１３１のチェック済み位置の次の要素を取得し（Ｓ１４２）、取得できたか否かを判定する（Ｓ１４３）。取得できなかった場合（Ｓ１４３：ＮＯ）は、転送するメッセージがないことから、キュー取出部１５はＳ１４０へ処理を戻す。なお、メインキュー１３１のチェック済み位置は、メインキュー１４１のフィルタと共通の値であり、転送スレッド単位で管理する変数等である。このように、メインキュー１３１のチェック済み位置が転送スレッドごとに管理されていることから、転送ルールの異なる複数のシステムへ転送する場合の処理を効率的の行うことができる。

取得できた場合（Ｓ１４３：ＹＥＳ）、メッセージ送信部１６は、転送先との接続確認を行い（Ｓ１４４）、接続中であるか否かを判定する（Ｓ１４５）。接続中でない場合（Ｓ１４５：ＮＯ）、転送先との接続がないことから、メッセージ送信部１６はＳ１４０へ処理を戻す。

接続中である場合（Ｓ１４５：ＹＥＳ）、メッセージ送信部１６は、キュー取出部１５がメインキュー１３１より取得したメッセージを送信し（Ｓ１４６）、受領通知などを確認することで送信が成功したか否かを判定する（Ｓ１４７）。送信が失敗した場合（Ｓ１４７：ＮＯ）、メッセージが転送先に送れなかったことから、メッセージ送信部１６はＳ１４０へ処理を戻す。

送信が成功した場合（Ｓ１４７：ＹＥＳ）、メッセージが転送先に送れたことから、キュー取出部１５は、送信したメッセージに対応するメインキュー１３１の要素の転送済みフラグを「ｔｒｕｅ」に設定し（Ｓ１４８）、Ｓ１４１へ処理を戻す。

以上のように、第３の実施形態では、スレッドが別となることから、自身のスレッドで転送したとしても、全てのスレッドで転送が完了するまでは、キュー１３に格納されたメッセージを削除できない。したがって、転送スレッド１７Ａ、１７Ｂにおいて転送が完了した後の、動的フィルタ部１４の適用により、キュー１３に格納されたメッセージを削除してもよい。

（第４の実施形態）
第４の実施形態では、第３の実施形態と同様に、共通の転送モジュール４Ｄによりシステム１Ａ、１Ｂ、１Ｃへメッセージを転送するが（図１２参照）、その転送先（宛先）がメッセージによって異なる。

転送モジュール４Ｄが転送するメッセージは、転送先が不定であり、転送するメッセージもメッセージによって転送先が異なるようなユースケースがある。この場合、メッセージの内容に転送先が示されている。例えば、メッセージのヘッダ等にメッセージのメタ情報に転送先を判断する情報が書かれている。一例として、送信先のユーザ名、トピック名、グループ名がメタ情報に含まれており、これらの情報をもとに、実際の転送先を決定することができる。

この転送先の決定は、静的フィルタ部１１（図１３参照）で行う。そして、キュー格納部１２は、メインキュー１３１および種別キュー１３２ａ、１３２ｂ、１３２ｃへメッセージを格納する際に、決定された転送先を示す宛先情報を付与する。この宛先情報の付与は、例えば、転送先毎の転送済みフラグを格納する領域Ｒ５（図１４参照）において、フラグとともに宛先情報を格納してもよい。

図１８は、第４の実施形態にかかる静的フィルタを適用する処理の一例を示すフローチャートである。図１８に示すように、静的フィルタ部１１は、静的フィルタの定義情報に記述されたフィルタリングの定義に従って、静的フィルタの適用を開始する。この時、所定のタイミング、例えば、各メッセージにおける前の静的フィルタ（Ｓ１５０）および次の静的フィルタ（Ｓ１５４）の合間において、メッセージの転送先を決定して宛先情報を書き込む処理（Ｓ１５１〜Ｓ１５３）を行う。なお、Ｓ１５１〜Ｓ１５３が行われるタイミングは、全ての静的フィルタを行う前または行った後などであってもよく、図示例に限定しない。

具体的には、静的フィルタ部１１は、メッセージのメタ情報を解釈する（Ｓ１５１）。これにより、メタ情報に含まれるユーザ名、トピック名、グループ名などの、メッセージの宛先となる情報が取得される。

次いで、静的フィルタ部１１は、メタ情報の解釈をもとに宛先（ユーザ名、トピック名、グループ名に対応する宛先）一覧を決定する（Ｓ１５２）。この宛先一覧は、単数または複数の宛先でよい。例えば、特定のユーザ名に対応する１人のユーザを宛先とする宛先一覧としてもよい。また、グループ名に対応するグループにおいて所属する複数のユーザを宛先とする宛先一覧としてもよい。

次いで、キュー格納部１２は、メインキュー１３１および種別キュー１３２ａ、１３２ｂ、１３２ｃに格納するメッセージを包含するデータ構造（例えば、領域Ｒ５）に決定された宛先一覧（宛先リスト）を書き込む（Ｓ１５３）。

キュー取出部１５は、メッセージとともに領域Ｒ５に格納された宛先情報を取り出してメッセージ送信部１６へ出力する。メッセージ送信部１６は、全ての転送先のリストに対する転送済みフラグを管理する代わりに、該当する宛先に対してのみ送信済みフラグを管理するようする事により、メッセージ毎に異なる転送先への転送を実現する。

（第５の実施形態）
図１９は、第５の実施形態にかかるシステム構成例を説明する説明図である。図１９に示すように、システム１Ｅ間においては、例えば、転送先または転送元のクライアント２の要求（新たに通知したいイベントの種別が発生した場合等）によって、メッセージの転送ポリシーを動的に変更する場合がある。

例えば、転送ポリシーを変更する場合としては、転送先のクライアント２やシステム１Ｅの都合で転送元の特定の情報が必要となる場合がある。また、転送元のクライアント２やシステム１Ｅの都合で、転送先のシステム１Ｅに所定の情報を伝える場合がある。この転送ポリシーは、静的フィルタまたは動的フィルタの定義として示される。

システム１Ｅの転送モジュール４Ｅは、動的に転送ポリシー（静的フィルタまたは動的フィルタの定義）を変更する。具体的には、転送モジュール４Ｅは、静的フィルタまたは動的フィルタの定義を、別のシステムやシステム１Ｅ内のクライアント２の要求に応じて、追加／削除を可能としている。

図２０は、第５の実施形態にかかる転送モジュール４Ｅの構成例を示すブロック図である。図２０に示すように、転送モジュール４Ｅは、転送ポリシー管理部１８と、記憶部１９とを有している。

記憶部１９は、静的フィルタ定義１１１および動的フィルタ定義１４１を記憶する。転送ポリシー管理部１８は、別のシステムやシステム１Ｅ内のクライアント２からの、静的・動的フィルタの追加／削除等の要求を元に、記憶部１９に記憶された静的フィルタ定義１１１および動的フィルタ定義１４１を更新する。具体的には、別のシステムやシステム１Ｅ内のクライアント２から通知された新たな定義を、静的フィルタ定義１１１および動的フィルタ定義１４１に反映する。

静的フィルタ部１１および動的フィルタ部１４は、更新された静的フィルタ定義１１１および動的フィルタ定義１４１に従ったフィルタ処理を行う。このため、システム１Ｅでは、動的に変更される転送ポリシーに応じたメッセージの転送を実現できる。

（第６の実施形態）
第６の実施形態では、イベントメッセージにおける一部のデータ領域にフィルタリングを行うことで、転送先の接続が不安定な場合等、送信が滞る場合にデータの転送量を適正化する。

例えば、転送モジュール４Ｄによりシステム１Ａ、１Ｂ、１Ｃへメッセージを転送する場合など（図１２参照）、転送先が不定の場合は、転送先ごとに通信速度や接続の安定度が異なることがある。この時、転送先によってはイベントメッセージの転送が滞ってしまう場合がある。一例として、画像を転送する場合等、イベントメッセージが大きなデータを含む場合は、転送が滞る可能性が高くなる。

しかしながら、画像を含むイベントメッセージの種別として一律にフィルタリングを行うと、イベントメッセージに含まれる画像以外の情報もフィルタリングされてしまう。例えば、画像と、画像処理の結果などの負荷情報とがイベントメッセージとして転送される場合には、転送が滞らないように画像をフィルタし、負荷情報を転送したいケースがある。

第６の実施形態では、動的フィルタ定義１４１において、イベントメッセージで画像等が格納される所定のデータ領域の有効時間（Ｔ２）を定義する。そして、動的フィルタ部１４は、有効時間（Ｔ２）をもとに、キュー１３に保持されるイベントメッセージの所定のデータ領域を削除するか否かを決定して、データのフィルタリングを行う。

図２１は、第６の実施形態にかかる動的フィルタの適用の一例を示すフローチャートである。図２１に示すように、動的フィルタ部１４は、現在時刻（ｃ）を取得し（Ｓ４１）、動的フィルタ判断情報であるイベントの時刻（ｔ）に、動的フィルタ定義１４１に定義された有効時間（Ｔ１）を加えたｔ＋Ｔ１について、ｃ＞ｔ＋Ｔであるか否かを判定する（Ｓ４２）。ｃ＞ｔ＋Ｔ１でない場合（Ｓ４２：ＮＯ）、現在時刻はイベントの有効時間内であることから、動的フィルタ部１４は、イベントの時刻（ｔ）に所定のデータ領域の有効時間（Ｔ２）を加えたｔ＋Ｔ２について、ｃ＞ｔ＋Ｔ２であるか否かを判定する（Ｓ４３ａ）。

ｃ＞ｔ＋Ｔ２である場合（Ｓ４３ａ：ＹＥＳ）、現在時刻は所定のデータ領域の有効時間を過ぎていることから、動的フィルタ部１４は、該当するデータ領域の削除、すなわちイベントメッセージにおけるデータの部分削除を行う（Ｓ４３ｂ）。また、ｃ＞ｔ＋Ｔ２でない場合（Ｓ４３ａ：ＮＯ）、動的フィルタ部１４は、メッセージは有効と判断（選別）する（Ｓ４３ｃ）。

また、ｃ＞ｔ＋Ｔ１である場合（Ｓ４２：ＹＥＳ）、現在時刻はイベントの有効時間を過ぎていることから、動的フィルタ部１４は、メッセージを無効と判断（選別）する（Ｓ４４）。メッセージを無効とした場合（Ｓ４４）は、そのメッセージは転送不要となったことから、他の動的フィルタ定義１４１の処理を行わずに処理を抜ける（終了する）こととなる。

第６の実施形態では、上述した動的フィルタの適用により、例えば、通信が遅い転送先に対して大きなデータを送ろうとし続けて転送が滞るような現象を、大きなデータが格納されるデータ領域を削除することで回避できる。また、イベントメッセージに含まれる必要な情報を、適切な時間で転送することが可能となる。

また、上記の実施形態では、キュー１３は、メインキュー１３１と、種別キュー１３２ａ、１３２ｂ、１３２ｃとを有する構成としたが、メインキュー１３１がなく、種別キュー１３２ａ、１３２ｂ、１３２ｃとする構成であってもよい。この構成では、転送スレッド１７Ａ、１７Ｂが種別キュー１３２ａ、１３２ｂ、１３２ｃごとの最後のイベントメッセージの時刻を見て、どのイベントメッセージを送るかを決定すればよい。この場合、キュー１３にメインキュー１３１を用意することなく、キュー１３に格納されたイベントメッセージを順番どおりに転送できるが、メインキュー１３１を参照して順番どおりに転送する場合と比較すると、処理効率が落ちることとなる。

また、上記の実施形態では、１つの転送先に１つの転送スレッドの場合を例示しているが、転送先が不定の場合には、転送先が多数になることがある。このように、転送先が不定である場合は、転送先ごとに転送スレッドを用意するのは効率的ではない。したがって、転送モジュール４Ｄ、４Ｅは、予め一定数の転送スレッドを動作させ（スレッドプール）、スレッドプール内の転送スレッドの中から転送先を選択して処理するようにしてもよい。

また、上記の実施形態では、センサ側のシステムと制御側のシステムとが分散したインタラクションロボットを例示して説明したが、これに限定されない。例えば、パーソナルコンピュータ（ＰＣ：Personal Computer）を始めとする固定端末や、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末による情報処理装置において実現してもよい。

また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、システム１Ａ、１Ｂ、１Ｃ、１Ｄ、１Ｅの各処理部が適宜統合されてもよい。また、各処理部の処理が適宜複数の処理部の処理に分離されてもよい。さらに、各処理部にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、上記の実施形態で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図２２を用いて、上記の実施形態と同様の機能を有するイベントドリブンプログラムを実行するコンピュータの一例について説明する。

図２２は、イベントドリブンプログラム２７０ａを実行するコンピュータ２００の一例について説明するための図である。図２２に示すように、コンピュータ２００は、操作部２１０ａと、スピーカ２１０ｂと、カメラ２１０ｃと、マイク２１０ｄ、ディスプレイ２２０と、通信部２３０とを有する。さらに、このコンピュータ２００は、ＣＰＵ２５０と、ＲＯＭ２６０と、ＨＤＤ２７０と、ＲＡＭ２８０と有する。これら２１０〜２８０の各部はバス２４０を介して接続される。

ＨＤＤ２７０には、システム１Ａ、１Ｂ、１Ｃ、１Ｄ、１Ｅの各処理部と同様の機能を発揮するイベントドリブンプログラム２７０ａが予め記憶される。このイベントドリブンプログラム２７０ａについては、上述した実施形態で示した各構成要素と同様、適宜統合又は分離してもよい。すなわち、ＨＤＤ２７０に格納される各データは、常に全てのデータがＨＤＤ２７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ２７０に格納されればよい。

そして、ＣＰＵ２５０が、イベントドリブンプログラム２７０ａをＨＤＤ２７０から読み出してＲＡＭ２８０に展開する。これによって、イベントドリブンプログラム２７０ａは、イベントドリブンプロセス２８０ａとして機能する。このイベントドリブンプロセス２８０ａは、ＨＤＤ２７０から読み出した各種データを適宜ＲＡＭ２８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、イベントドリブンプロセス２８０ａは、システム１Ａ、１Ｂ、１Ｃ、１Ｄの各処理部にて実行される処理を含む。また、ＣＰＵ２５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ２５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されればよい。

なお、上記のイベントドリブンプログラム２７０ａについては、必ずしも最初からＨＤＤ２７０やＲＯＭ２６０に記憶させておく必要はない。例えば、コンピュータ２００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ２００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ２００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ２００がこれらから各プログラムを取得して実行するようにしてもよい。

１Ａ、１Ｂ、１Ｃ、１Ｄ、１Ｅ…システム
２…クライアント
３…メッセージプロバイダ
４、４Ａ、４Ｂ、４Ｄ、４Ｅ…転送モジュール
１０…メッセージ受信部
１１…静的フィルタ部
１２…キュー格納部
１３…キュー
１４…動的フィルタ部
１５…キュー取出部
１６…メッセージ送信部
１７Ａ、１７Ｂ…転送スレッド
１８…転送ポリシー管理部
１９…記憶部
１１１…静的フィルタ定義
１３１…メインキュー
１３２ａ、１３２ｂ、１３２ｃ…種別キュー
１４１…動的フィルタ定義
２００…コンピュータ
Ｄ１〜Ｄ４…定義
Ｅ１〜Ｅ３…イベント
Ｒ１〜Ｒ５、Ｒ１１〜Ｒ１４…領域
Ｔ１１、Ｔ１２、Ｔ１３…期間

Claims (11)

1. 転送元からイベントドリブンで転送されたイベントメッセージを保持する第１のキューと、
   前記第１のキューで保持するイベントメッセージの種別毎に設けられ、前記イベントメッセージを種別毎に保持する第２のキューと、
   前記第２のキューごとのフィルタ定義をもとに、前記第２のキューごとにフィルタを適用して、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定し、当該決定結果に基づいて、前記第１のキューに保持されるイベントメッセージの保持状態を更新する制御部と
   を有することを特徴とするイベントドリブンシステム。
2. 前記制御部は、前記転送元からイベントメッセージが転送された場合および前記転送先へイベントメッセージを転送する場合の少なくとも一方で、前記第１のキューに保持されるイベントメッセージの保持状態を更新する
   ことを特徴とする請求項１に記載のイベントドリブンシステム。
3. 前記フィルタ定義は、前記第２のキューごとのイベントメッセージの有効時間を定義し、
   前記制御部は、前記第２のキューごとに定義された有効時間をもとに、前記第２のキューに保持されるイベントメッセージが前記定義された有効時間を満たすように、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定する
   ことを特徴とする請求項１又は２に記載のイベントドリブンシステム。
4. 前記フィルタ定義は、前記第２のキューごとのキューサイズを定義し、
   前記制御部は、前記第２のキューごとに定義されたキューサイズをもとに、前記第２のキューに保持されるイベントメッセージの数が前記定義されたキューサイズを満たすように、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定する
   ことを特徴とする請求項１乃至３のいずれか一項に記載のイベントドリブンシステム。
5. 前記フィルタ定義は、所定の状態を示す状態イベントの削除を定義し、
   前記制御部は、前記第２のキューに保持されるイベントメッセージについて、前記状態イベントを満たすイベントを削除するように、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定する
   ことを特徴とする請求項１乃至４のいずれか一項に記載のイベントドリブンシステム。
6. 前記イベントメッセージを前記第１のキューおよび前記第２のキューへ格納する際に、当該イベントメッセージのフィルタリングを行う静的フィルタ部を有し、
   前記静的フィルタ部は、前記イベントメッセージの内容をもとに当該イベントメッセージの転送先を決定し、決定した転送先を示す宛先情報を前記第１のキューおよび前記第２のキューへ格納し、
   前記制御部は、前記宛先情報に基づいた転送先に前記イベントメッセージを転送する
   ことを特徴とする請求項１乃至５のいずれか一項に記載のイベントドリブンシステム。
7. 前記フィルタ定義および前記静的フィルタ部のフィルタリングにかかる定義を記憶する記憶部と、
   外部からの要求に応じて前記記憶部が記憶する定義の内容を更新する管理部とを有する
   ことを特徴とする請求項６に記載のイベントドリブンシステム。
8. 前記フィルタ定義は、前記第２のキューごとのイベントメッセージに含まれる所定のデータ領域の有効時間を定義し、
   前記制御部は、前記所定のデータ領域の有効時間をもとに、前記第２のキューに保持されるイベントメッセージに含まれる所定のデータ領域を削除するか否かを決定する
   ことを特徴とする請求項１乃至７のいずれか一項に記載のイベントドリブンシステム。
9. 転送元からイベントドリブンで転送されたイベントメッセージを保持する第１のキューと、
   前記第１のキューで保持するイベントメッセージの種別毎に設けられ、前記イベントメッセージを種別毎に保持する第２のキューと、
   前記第２のキューごとのフィルタ定義をもとに、前記第２のキューごとにフィルタを適用して、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定し、当該決定結果に基づいて、前記第１のキューに保持されるイベントメッセージの保持状態を更新する制御部と
   を有することを特徴とする情報処理装置。
10. コンピュータに、
    転送元からイベントドリブンで転送されたイベントメッセージを第１のキューに保持し、
    前記第１のキューで保持するイベントメッセージの種別毎に設けられた第２のキューに、前記イベントメッセージを種別毎に保持し、
    前記第２のキューごとのフィルタ定義をもとに、前記第２のキューごとにフィルタを適用して、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定し、当該決定結果に基づいて、前記第１のキューに保持されるイベントメッセージの保持状態を更新する
    処理を実行させることを特徴とするイベントドリブンプログラム。
11. コンピュータが、
    転送元からイベントドリブンで転送されたイベントメッセージを第１のキューに保持し、
    前記第１のキューで保持するイベントメッセージの種別毎に設けられた第２のキューに、前記イベントメッセージを種別毎に保持し、
    前記第２のキューごとのフィルタ定義をもとに、前記第２のキューごとにフィルタを適用して、前記第２のキューに保持されるイベントメッセージを転送先へ転送するか、削除するかを決定し、当該決定結果に基づいて、前記第１のキューに保持されるイベントメッセージの保持状態を更新する
    処理を実行することを特徴とするイベントドリブン方法。

Images