JP6418004B2 - イベント通知プログラム、イベント通知方法及びイベント通知装置 - Google Patents

Description

本発明は、イベント通知プログラム、イベント通知方法及びイベント通知装置に関する。

Open Ajax HUBのように、Publish／Subscribe形式の通信モデルのメッセージを非同期で通信するシステムが開発されている（例えば、特許文献１参照）。これによれば、イベント通知の依頼側（Subscribe側：イベントの受信側）とこれに対するイベント通知側（Publish側：イベントの発行側）とを分離させ、各動作主体の動作を、独立してアプリケーションに規定することができる。

他方、昨今Open Socialに代表される共通の仕様に則り開発されたガジェット（ウィジェット）を利用したポータルへの移行が進んできている。このようなポータルでは利用者が自由にガジェットを組み合わせてコンテンツを作成することが可能である。ガジェット間の通信には、例えば、Open Ajax HUBのようなPublish／Subscribeモデルのイベント通知機構が利用される。

特開２００７−２１３３７２号公報

しかしながら、Publish／Subscribeモデルのように、イベントの発行とイベントの受信との２フェーズを有するモデルでは、イベント通知の依頼時（Subscribe）とこれに対するイベント通知の発行時（Publish）とが必ずしも時間的に近接しているとは限らない。このため、イベント通知の優先順位が、イベント通知を依頼する段階と実際に依頼元にイベントを通知する段階とで異なる場合が生じる。よって、イベント通知の依頼時の優先順位に従い、イベント発行後にイベントを依頼元に通知すると、イベント通知の依頼時には適切な優先順位であっても、イベント発行時には不適切な順番でイベントを通知してしまうことがある。

そこで、一側面では、本発明は、適切な順番でイベント通知を行うことを目的とする。

一つの案では、イベント通知条件情報および優先情報を含むイベント通知依頼を受け付け、前記イベント通知条件情報に基づき前記イベント通知依頼に応じたイベントが発生し、かつ、該イベントのメッセージの同期配信を実行するか否かによってイベント通知の条件が成立するかを判定し、前記イベント通知依頼に応じたイベント通知が発生し、かつ、メッセージの同期配信を実行する場合、前記イベント通知の条件が成立したと判定し、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する、処理をコンピュータに実行させるイベント通知プログラムが提供される。

一側面によれば、適切な順番でイベント通知を行うことができる。

ガジェットの画面表示の一例を示す図。 Publish／Subscribe形式の通信モデルの一例を示す図。 ガジェット間のデータ連携を説明するための図。 ガジェット間のPublish／Subscribe形式の通信の課題の一例を示す図。 ガジェット間のPublish／Subscribe形式の通信の課題の他の例を示す図。 一実施形態に係るイベント通知装置の機能構成の一例を示す図。 一実施形態に係るガジェット間のPublish／Subscribe形式の通信の一例を示す図。 一実施形態に係る依頼情報テーブルの一例を示す図。 一実施形態に係るイベント通知依頼処理の一例を示したフローチャート。 一実施形態に係るイベント通知処理の一例を示したフローチャート。 一実施形態に係るイベント通知装置のハードウェア構成の一例を示す図。

以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

［ガジェット］
昨今Open Socialに代表される共通の仕様に則り開発されたガジェット（ウィジェット）を利用したポータルへの移行が進んできている。ガジェットとは、アプリケーション（以下、「アプリ」ともいう。）やデスクトップ上で動作するソフトウェアである。例えば、図１には、ウェブブラウザ上に配置したガジェットの一例が示されている。この例では、イベント通知装置１０の一例であるパーソナルコンピュータの画面１０ａ上に、ニュースや天気等のコンテンツ情報を提供するガジェット１１ａ〜１１ｄが示されている。

このようなポータルでは利用者が自由にガジェットを組み合わせてコンテンツを作成することが可能である。また、ガジェット間の通信には、例えば、Open Ajax HUBのようなPublish／Subscribeモデルのイベント通知機構が利用される。

図２に、Publish／Subscribe形式の通信モデルの一例を示す。イベント通知の依頼元３０（イベントの受信側）のガジェットと、これに対するイベント通知の発行元４０（イベントの発行側）のガジェットとは分離され、各動作主体の動作が、独立してアプリケーション（図２では、アプリＡ、Ｂ）に規定されている。イベント通知の依頼元３０およびイベント通知の発行元４０は、相手を直接意識せず、トピック（後述されるデータ連携部５０）という上位概念で結びつき、トピックを介してデータの連携を行う。このようにして、Publish／Subscribeの通信モデルでは、イベント通知の依頼元３０のガジェットおよびイベント通知の発行元４０のガジェットの変更に対して、独立してアプリケーションが記述できるというのが利点である。

つまり、イベント通知の依頼元３０のガジェット（以下、「Subscribe側」ともいう。）は、どのようなアプリケーションでイベントが発生したのか、他にどのようなSubscribe処理があるかを意識する必要はない。Subscribe側は、単にイベント発生が関心対象にどのように作用するのかだけを、ハンドラに記述し、（１）のイベント通知依頼をトピックに行えばよい。

また、イベント通知の発行元４０のガジェット（以下、「Publish側」ともいう。）は、そのイベントが、どのアプリケーションが読み込むものか？どのように処理されるのか？を意識する必要はない。Publish側は、単にイベントが発生したことを示す（２）のイベントの通知をトピックに行えばよい。

図２に示すPublish／Subscribe形式の通信モデルでは、メッセージは非同期で通信される（（３）メッセージ配信）。

たとえば、図３を参照しながら、Open Ajax HUBのように、Publish／Subscribe形式の通信モデルにおけるガジェット間のデータ連携について具体的に説明する。図３の例では、ガジェット１１ｅ、１１ｆが表示されている。この説明では、ガジェット１１ｅがSubscribe側、ガジェット１１ｆがPublish側として機能する場合を例に挙げるが、ガジェット１１ｅがPublish側、ガジェット１１ｆがSubscribe側として機能することもできる。なお、画面初期化時に、Subscribe側とPublish側とのデータの連携を行うＭａｎａｇｅｄ ＨＵＢ（以下、「データ連携部５０」ともいう。）が生成される。

（１）イベント通知依頼
データを受信するガジェット１１ｅは、ガジェット初期化後の任意のタイミングでデータ連携部５０に対してイベント通知依頼（以下、「Subscribe」ともいう。）を行う（（１）イベント通知依頼）。イベント通知依頼時、「トピック名」、「データ受信時に起動するコールバック関数」を引数としてSubscribeメソッドを呼び出す。ガジェット１１ｅは、データ連携対象のメッセージ送信側のガジェット１１ｆにてイベントの発行（以下、「Publish」ともいう。）が行われる前に、Subscribeを行う必要がある。これにより、登録したトピック（ここでは株価）のイベントに変化があった場合に、そのトピックのデータ連携部５０を介して、変化したイベントの情報がイベントの発行元（ここでは、ガジェット１１ｆ）からイベント通知の依頼元（ここでは、ガジェット１１ｅ）に配信されるようになる。

（２）イベントの発行（通知）
イベントの発行の際のデータを送信するガジェット１１ｆは「トピック名」、「送信するデータ（メッセージ）」を引数としてPublishメソッドを呼び出す（（２）イベント通知）。ガジェット１１ｆにおけるPublishのタイミングとしては、例えば入力項目に記載し終わった後にENTERキーを押下した時などが挙げられる。

（３）メッセージ配信
トピック名で指定されたデータ連携部５０は、Publishされたデータの送信元のガジェット１１ｆの確認を行う（セキュリティチェック）。データ連携部５０は、管理下にあるガジェットであると確認した場合、同じトピック（ここでは、株価のトピック）をSubscribeしているガジェット１１ｅにデータを送信する（（３）メッセージ配信）。データを受信したガジェット１１ｅは、登録されたコールバック関数によって、データを処理する。

なお、セキュアにガジェット間連携を実現するための技術としては、次の技術がある。ＯｐｅｎＡｊａｘ ＨＵＢ ２．０（ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎａｊａｘ．ｏｒｇ／ｍｅｍｂｅｒ／ｗｉｋｉ／ＯｐｅｎＡｊａｘ＿Ｈｕｂ＿２．０＿Ｓｐｅｃｉｆｉｃａｔｉｏｎ）
Publish／Subscribe形式の通信モデルでは、メッセージは非同期で通信されるため、ガジェット間通信ではメッセージの到着順番が不定になるという問題がある。アプリケーションの独立性が高い場合、又は処理順番に依存しないアプリケーションの処理の場合であれば不具合は生じない。しかし、処理順番に依存するアプリケーションの処理の場合、不具合が生じる。

たとえば、メッセージを処理するアプリが複数あり、それぞれの処理順番に意味がある場合には、同期通信を使う事は必須である。しかし、処理順番に意味がない場合にも同期通信を行うと、不要な待機時間が発生し、非効率になる。

（処理順番に依存するアプリケーション例１）
例えば、図４では、複数のガジェットで発生した事象（メソッド呼び出し等）について時系列にログ（トレース）を記録したい場合のPublish／Subscribeモデルの通信の一例を示す。ここでは、複数のガジェットで発生する大量のイベントをログするデバッグログが想定される。

（１）まず、イベント通知の依頼元３０のガジェットが、「トピック：ログ」のデータ連携部５０に対してイベント通知の依頼（Subscribe）を行う。イベント通知の依頼元３０のガジェットでは、ログ取得アプリが動作する。

（２）次に、イベント通知の発行元４０、４１のガジェットが、「トピック：ログ」のデータ連携部５０に対してイベントを通知する。ここでは、先に（２−１）の取得対象イベントアプリ１の動作により発生したログ１がPublishされ、後に（２−２）の取得対象イベントアプリ２の動作により発生したログ２がPublishされる。

（３）次に、「トピック：ログ」のデータ連携部５０は、イベント通知の依頼元３０にメッセージを配信する。ここでは、先に（３−１）のログ２が配信され、後に（３−２）のログ１が配信される。

このように、非同期通信では、配信したメッセージの順番が保障されず、イベント通知（Publish）の順番とイベント通知の依頼元（Subscribe側）へメッセージが配信される順番とは異なる。このようにPublish側からのメッセージ通知順番は不定となる。一方、イベント通知の依頼元３０のガジェットでは、通知された複数のログイベントの発行の前後関係はわからない。つまり、ログ情報の取得の順番によってはログ情報の発生の順番がわからない。そのため、ログ１及びログ２のどちらの事象が先に発生したかがわからず、ログ情報を時系列に記憶することが保障できない。時系列にログ情報を記憶できないと、ログ情報の利用価値は著しく低下する。

これに対して、ログ取得対象のイベント発生時刻のタイムスタンプをログ情報に埋め込む方法が考えられる。しかしながら、この場合、コンピュータの性能による最小解析時間があり、その時間以下の間隔で発生したログ取得対象のイベントについては対応できない。

また、Publishする前にマスターとなるコンポーネントでシーケンシャルなログ番号を取得してログ情報に埋め込む方法が考えられる。しかしながら、この場合、シーケンスの中で、「順序番号取得のための通信」と「Publishのための通信」との２種類の通信が必要となり、通信方法が煩雑になる。

（処理順番に依存するアプリケーション例２）
また、図５に示すように、複数のイベント通知の依頼元３０、３１のガジェットで発生した事象（メソッド呼び出し等）についてイベントを受信する際にも不具合が生じる場合がある。

（１−１）まず、イベント通知の依頼元３０のガジェットが、「トピック：誕生日」に対してイベント通知依頼（Subscribe）を行う。イベント通知の発行元４０は、定められた年齢に応じて、誕生日の特別ポイントを加算する。

（１−２）次に、イベント通知の依頼元３１のガジェットが、「トピック：誕生日」に対してイベント通知依頼（Subscribe）を行う。イベント通知の発行元４０は、誕生日時に一定のポイントがあればプレゼトイベントをpublishする。

（２）次に、イベント通知の発行元４０のガジェットが、「トピック：誕生日」に対してイベント通知を行う。ここでは、誕生日イベントアプリの動作により発生した誕生日イベントのデータがPublishされる。

（３）次に、「トピック：誕生日」のデータ連携部５０は、ログインユーザの属性と当日日付を比較し、比較結果に応じてイベント通知の依頼元３０、３１のガジェットに誕生日イベントのメッセージを配信（Publish）する。ここでは、先に（３−１）の誕生日のメッセージがイベント通知の依頼元３１に配信され、後に（３−２）の誕生日のメッセージがイベント通知の依頼元３０に配信される。

配信されるメッセージに、Subscribeした順番（イベント通知の依頼元３０→イベント通知の依頼元３１）に対する依存性がある場合、上記のようにSubscribeした順番と異なる順番でメッセージが配信されると、誕生日のメッセージの内容が変わり、不具合が生じる場合がある。

例えば、イベント通知の依頼元３０に先に誕生日のイベント通知が配信される場合、イベント通知の依頼元３０への誕生日のイベント通知時には、すでにポイントが加算されている。このため、正しいタイミングでプレゼントイベントが発生する。

一方、上記の例のように、イベント通知の依頼元３１に先に誕生日のイベント通知が配信される場合、その時点では、先にイベント通知の依頼元３０に誕生日のイベント通知が配信されたときには加算されたはずのポイントが加算されていない。この結果、正しいタイミングでプレゼントイベントが発生しない可能性がある。このようにSubscribeした順番に対する依存性がある場合、Subscribeした順番にメッセージが配信されることが保障されないと不具合が生じる。

これに対して、イベント通知後に一定時間待機することで、イベント通知の依頼元３０へのメッセージの配信が完了するまでイベント通知の依頼元３１へのメッセージの配信を待つことが考えられる。しかしながら、その場合、複数のメッセージを並行して配信できないため、通信効率が悪くなって処理が遅延することが懸念される。また、待機時間を一意に決めることができない。

（処理順番に依存するアプリケーション例３）
更に、イベント通知を依頼したガジェットが、publish時には閉じられていた等のアプリケーションの事情により、実際にはpublish時には通知の必要がなくなったイベントが通知されることがある。

たとえば、「トピック：株価」において、株価が変化した場合、Publish側から株価の現在値がイベントで通知される。ところが、イベント通知依頼（Subscribe）時とイベント通知（Publish）時とが必ずしも時間的に近接しているとは限らない。そこで、Subscribe時には必要であったイベント通知であっても、イベント通知時（Publish）には通知が不要となっている場合が生じ得る。例えば、Publish前に株価を知らせるガジェットの非表示が選択された場合やユーザが一時的に株価の表示が必要ないことを通知した場合が挙げられる。それらの場合には、Publishされた株価の現在値がイベントで通知されたとしても、イベント通知の依頼元の画面上で反映するガジェットが閉じられているため、株価の現在値を表示できず、Subscribeへのメッセージの配信が無駄になってしまう。

上記で説明した課題を考慮して、以下では、適切な順番でイベント通知を行うことが可能なイベント通知装置１０について説明する。

［イベント通知装置の機能構成］
一実施形態に係るイベント通知装置１０の構成について、図６〜図８を参照しながら説明する。図６は、一実施形態に係るイベント通知装置１０の機能構成の一例を示す。図７は、一実施形態に係るガジェット間のPublish／Subscribe形式の通信の一例を示す。図８は、一実施形態に係る依頼情報テーブルの一例を示す。

本実施形態に係るイベント通知装置１０は、データ連携部５０を有する。データ連携部５０は、Publish／Subscribe形式の通信におけるガジェット間において、画面初期化時に生成される。

データ連携部５０は、受付部５１、記憶部５２、優先度算出部５３及び通知部５４を有する。受付部５１は、イベント通知条件情報及び優先情報を含むイベント通知依頼を受け付ける。例えば、図７に示すように、データを受信するあるガジェットが、ガジェット初期化後の任意のタイミングでデータ連携部５０に対してイベント通知依頼（Subscribe）を行う。イベント通知の依頼元３０のガジェットは、イベント通知依頼時、「トピック名」、「コールバック関数」、「優先度」を引数としてSubscribeメソッドを呼び出す。これにより、登録したトピックのイベントに変化があった場合に、変化したイベントの情報がイベント通知の依頼元３０のガジェットに配信されるようになる。「トピック名」及び「コールバック関数」のパラメータは、イベント通知条件情報の一例である。また、「優先度」のパラメータは、優先情報の一例である。

記憶部５２は、イベント通知条件情報及び優先情報を依頼情報テーブル５５に記憶する。依頼情報テーブル５５は、図８の（ａ）に示すように、トピック名５５ａ、コールバック関数５５ｂ、優先度（値）５５ｃ及び優先度（メソッド）５５ｄの項目を有する。

記憶部５２は、イベント通知の依頼元３０のガジェットがSubscribe時に指定した「トピック名」、「コールバック関数」、「優先度」を依頼情報テーブル５５に登録する。優先度には値（数値）とメソッドとの何れかが設定されているので、「優先度」のパラメータは、依頼情報テーブル５５の優先度（値）５５ｃ及び優先度（メソッド）５５ｄのいずれかに登録される。

優先度算出部５３は、優先度がメソッドで設定されている場合、イベントの通知を発行する際に優先度で指定されたメソッドを数値化して、その通知の優先順位を算出する。このように、本実施形態では、優先度をメソッドで指定可能とすることで、優先度算出部５３は、イベントの通知を発行する際に評価される優先情報の動的な条件に基づき優先順位を特定することができる。

判定部５５は、イベント通知条件情報に基づきイベント通知依頼に対する同期配信によるイベント通知の条件が成立するか否かを判定する。例えば、判定部５５は、イベント通知依頼に含まれる「トピック名」（すなわち、イベント通知の依頼元３０のガジェットがSubscribe時に指定する「トピック名」）によりメッセージの同期配信又は非同期配信のいずれが実行されるかを判定する。「トピック名_sync」というように「トピック名」に「_sync」というサフィックスが付いている場合、判定部５５は、メッセージの同期配信を実行すると判定する。一方、「トピック名」に「_sync」というサフィックスが付いていない場合、判定部５５は、メッセージの非同期配信を実行すると判定する。

判定部５５は、イベント通知依頼に含まれる「トピック名」に応じたイベント通知が発生し、かつ、メッセージの同期配信を実行すると判定した場合、イベント通知条件情報に基づきイベント通知依頼に対する同期配信によるイベント通知の条件が成立すると判定する。

通知部５４は、優先順位に従いイベントの通知を行う。通知部５４は、イベント通知条件情報に基づき、イベント通知依頼に対するイベント通知の条件が成立した場合、前記成立した際に評価される前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する。その際、通知部５４は、判定部５５の判定結果に応じて、同期配信又は非同期配信のいずれかにより通信を行う。

このようにして、本実施形態では、「トピック名」の命名規則により同期配信及び非同期配信のロジックを切り替えることができる。これにより、本実施形態によれば、実行順番を保障してほしいアプリケーションは同期通信のトピック名を指定することで配信ロジックを同期通信に切り替えることができる。この結果、本実施形態では、ガジェット間通信を同期配信及び非同期配信のいずれにも適用できるようにする。

例えば、Subscribe時のトピック名に、「_sync」というサフィックスが付いた場合、通知部５４は、全て同期通信とし、復帰情報を待ってから次の処理を実行する。その場合、通知部５４は、複数回発行（Publish）されたイベント通知に対する配信キューからのメッセージ配信を、かならずPublishの到着順で行う。

また、図７に示すように、本実施形態では、Subscribe時に「優先度」のパラメータが指定される。これにより、イベント通知の優先順位が定数、またはメソッドで指定可能となる。例えば、「優先度」が数値で指定されている場合、その値がそのままイベント通知の優先順位となる。一方、「優先度」がメソッドで指定されている場合、イベント通知（Publish）の直前に当該メソッドを呼び出し、その復帰値がイベント通知の優先順位となる。

本実施形態によれば、このようにしてイベント通知の依頼元のガジェットで優先度にシーケンシャル番号を付加することで、メッセージの配信順番をイベントの発生順番と一致させることができる。例えば、通知部５４は、Publish時のイベント通知の受信の順番と同じ順番でデータ連携部５０の配信キューからメッセージの配信を実施する。この結果、上記に説明した処理順番に依存するアプリケーションの場合にも不具合なくガジェット間におけるデータの連携が可能になる。

「優先度」にメソッドが指定された場合、優先度算出部５３は、イベントが発生した後であってメッセージが配信される前のいずれかのタイミングに、指定されたメソッドを呼び出し、メッセージを配信する優先順位を算出する。この結果、以下の（１）及び（２）のケースにおいて、メッセージの配信順番をイベント通知依頼の順番又はイベント発生の順番と一致させることができ、メッセージの通知順番が保障される。
（１）同一トピックに対してSubscribe側に複数のアプリケーションがある場合（図５）
（２）同一トピックに対してPublish側から複数のメッセージが発行される場合（図４）
例えば、図５に示す同一トピックに対してSubscribe側に複数のアプリケーションがある場合、トピック名を「トピック：誕生日_sync」に変更する。加えて、イベント通知の依頼元３０、３１のガジェットの（１−２）のイベント通知依頼時に指定する優先度を、（１−１）のイベント通知依頼時に指定する優先度よりも低く設定する。これにより、「トピック：誕生日」のイベントが発生した場合には、イベント通知の依頼元３０→イベント通知の依頼元３１の順番でメッセージが配信されることが保障される。この結果、（１−２）のアプリ２で表示されるメッセージの内容は、（１−１）のアプリ１が加算したポイントを反映したものとなる。

また、「優先度」にメソッドが指定される場合、イベントが発生した後であってメッセージが配信される前のいずれかのタイミングに、優先度算出部５３が、メソッドを呼び出して優先順位を計算することで以下のメリット（３）及び（４）を奏することができる。
（３）Publish時の状況に応じたメッセージの配信順番が選択できる。
（４）不要なメッセージ配信を省略できる。

特に、（４）のメリットについては、前述のとおりイベントが変更されたことの通知が配信されても、画面上のガジェットが閉じられている等の場合にはイベントの変更を反映できず、メッセージの配信が無駄になる。このような通信の無駄を省くために、優先度算出部５３は、Publish時等のイベントが発生した後であってメッセージが配信される前のいずれかのタイミングに、指定された優先度のメソッドを呼び出して、Subscribe時に設定されたイベント通知条件情報に基づきイベント通知依頼に対するイベント通知の条件が成立するかを判定する。優先度算出部５３は、Publish時におけるイベント通知の条件が成立しないと判定した場合、優先度に負の値を設定する。これにより、本実施形態では、通知部５４は、優先度が負の値の場合、更新メソッドは呼ばなくてよいという条件を設定することでメッセージを配信しないようにすることができる。

なお、本実施形態では、優先度に負の値を設定した場合、更新メソッドは呼ばなくてよいという条件を設定したが、これに限らない。つまり、通知部５４は、優先度が一定数以下の値や予め定められた値や範囲に包含されていれば、更新メソッドを呼ぶ処理を行わずにメッセージを配信しないようにしてもよい。

例えば、イベント通知の依頼元３０のガジェットが、図５の（１−１）においてSubscribe（トピック：株価_sync、株価欄を更新するメソッド、株価欄がなければ負の値を返却するメソッド)を設定することで、上記の（３）や（４）の効果を得ることができる。

［イベント通知依頼処理］
次に、本実施形態に係るイベント通知依頼処理について図９を参照して説明する。図９は、本実施形態に係るイベント通知依頼処理の一例を示したフローチャートである。本処理は、イベント通知の依頼元（Subscribe側）のガジェットのアプリケーションから依頼される。

本処理が開始されると、受付部５１は、イベント通知依頼（Subscribe）を受け付ける（ステップＳ１０）。図７に示すように、イベント通知依頼には、「トピック名」、「コールバック関数」及び「優先度」のパラメータが指定されている。記憶部５２は、イベント通知の依頼元のガジェットがSubscribe時に指定した「トピック名」、「コールバック関数」、「優先度」を依頼情報テーブル５５に登録し（ステップＳ１２）、本処理を終了する。

これにより、図８の（ａ）に示すように、イベント通知依頼を受け付ける度に依頼情報テーブル５５にトピック名等が保存される。

［イベント通知処理］
次に、本実施形態に係るイベント通知処理について図１０を参照して説明する。図１０は、本実施形態に係るイベント通知処理の一例を示したフローチャートである。本処理は、イベント通知の発行元（Publish側）のガジェットのアプリケーションから通知される。

本処理が開始されると、受付部５１は、イベントの通知（Publish）を受け付ける（ステップＡ２０）。図７に示すように、イベントの通知には、「トピック名」、「データ」のパラメータが指定されている。

判定部５５は、「トピック名」に「_sync」というサフィックスが付いているかを判定する（ステップＳ２１）。判定部５５が「トピック名」に「_sync」というサフィックスが付いていないと判定した場合、判定部５５はメッセージの非同期配信を実行すると判定する。この場合、通知部５４は、イベント通知のコールバック関数を呼び出し、メッセージを配信し（ステップＳ３６）、本処理を終了する。

一方、ステップＳ２１において、判定部５５が「トピック名」に「_sync」というサフィックスが付いていると判定した場合、判定部５５はメッセージの同期配信を実行すると判定し、ステップＳ２２に進む。

優先度算出部５３は、依頼情報テーブル５５から、前記イベントの通知のパラメータで与えられたトピック名に対応する情報を選択する（ステップＳ２２）。例えば、イベントの通知において、「トピック名」に「Topic A」が指定されていた場合、図８の（ｂ）に示すように、依頼情報テーブル５５から「Topic A」に対応する情報が選択される。

次に、優先度算出部５３は、優先度にメソッドが設定されているかを判定する（ステップＳ２４）。優先度算出部５３は、優先度にメソッドが設定されていると判定した場合、設定されているメソッドを呼び出し、メソッドに基づき優先度の値を算出する（ステップＳ２６）。図８の（ｂ）の２行目には、優先度（メソッド）５５ｄに「メソッド９」が設定されている。この場合、優先度算出部５３は、メソッド９に基づき優先度の値を算出する。この結果、図８の（ｂ）の２行目の優先度（値）５５ｃに「８」が設定される。なお、優先度算出部５３は、優先度にメソッドが設定されていないと判定した場合、ステップＳ２８に進む。

次に、通知部５４は、優先度が高い順にソートする（ステップＳ２８）。図８の（ｂ）の情報が、優先度が高い順にソートされた結果を図８の（ｃ）に示す。

次に、通知部５４は、負の値の優先度があるかを判定する（ステップＳ３０）。通知部５４は、負の値の優先度があると判定した場合、優先度に負の値を持つイベント通知を破棄する（ステップＳ３２）。

通知部５４は、破棄されたイベント通知以外のイベント通知について、優先度が高い順に各イベント通知のコールバック関数を呼び出し、優先度が高い順にメッセージを配信し（ステップＳ３４）、本処理を終了する。これにより、図８の（ｃ）に示すように、優先度（値）５５ｃが高い順に「メソッド４」、「メソッド５」、「メソッド１」のコールバック関数が呼び出され、各メソッドで指定されるイベント通知の依頼元のガジェットへ優先度が高い順番にメッセージが配信される。

以上に説明したように、本実施形態かかるイベント通知装置１０によれば、非同期通信によるアプリケーションと、同期通信によりメッセージ到着順番を保障する必要があるアプリケーションとを両立させたガジェット間の通信を提供することができる。

また、同期通信によるPublish/Subscribeの通信の場合、Subscribe時にイベント通知依頼に「優先度」を設定することで、イベント通知のメッセージ配信の順番を確定することができる。これに加えて、「優先度」に負の値を設定することで、Publish時には必要としない不要なメッセージ配信を抑止することができる。

例えば、あるデータ（トピックＡ）の更新に伴い、図１の画面１０ａのガジェット１１ｂ、１１ｃ、１１ｄの更新を行う際、画面１０ａの左から右、上から下の順番でデータを更新したい場合について説明する。この場合、「キーワードランキング」のガジェット１１ｂ、「乗り換えのご案内」のガジェット１１ｃ、「お天気情報」のガジェット１１ｄの順にデータの更新を契機に再描画されるようにしたい。このとき、本実施形態によれば、
（１）受付部５１は、イベント通信の依頼元からイベント通信の依頼を受け付けるとき、イベント発生時のメソッドともに優先度のメソッドを受け付ける。
（２）このとき、指定されたメソッドによる優先度は、イベント通信の依頼時には一意に決まらないので、自己のガジェットが表示されている位置から計算するメソッドが指定される。
（３）優先度算出部５３は、指定されたトピックのイベント通信の発行時、優先度のメソッドを呼び出し、依頼元のガジェットの表示位置から優先度を計算する。
（４）通知部５４は、優先度が高い順番にイベントを通知する。

これにより、優先度が高い順に、「キーワードランキング」のガジェット１１ｂ、「乗り換えのご案内」のガジェット１１ｃ、「お天気情報」のガジェット１１ｄの順でデータが更新される。

（ハードウェア構成例）
最後に、本実施形態に係るイベント通知装置１０のハードウェア構成例について、図１１を参照して説明する。イベント通知装置１０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ(Random Access Memory)１０４、ＲＯＭ(Read Only Memory)１０５、ＣＰＵ(Central Processing Unit)１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ(Hard Disk Drive)１０８を備える。各部はバスＢで相互に接続されている。

入力装置１０１は、キーボードやマウスなどを含み、イベント通知装置１０に各操作信号を入力するのに用いられる。表示装置１０２は、ディスプレイ１０ａを含み、各種のガジェットの更新データを表示する。

通信Ｉ／Ｆ１０７は、イベント通知装置１０をネットワークに接続するインタフェースである。これにより、イベント通知装置１０は、通信Ｉ／Ｆ１０７を介して、他の機器とデータ通信を行うことができる。

ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、装置全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のＤＢ情報やプログラム等が格納されている。

外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、イベント通知装置１０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ(Compact Disk)、及びＤＶＤ(Digital Versatile Disk)、ならびに、ＳＤメモリカード(SD Memory card)やＵＳＢメモリ(Universal Serial Bus memory)などがある。

ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。

上記ハードウェア構成により、本実施形態に係るイベント通知装置１０は、イベント通知依頼処理及びイベント通知処理を行うことができる。例えば、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたデータ及びプログラムを用いてイベント通知依頼処理及びイベント通知処理を実行する。この結果、本実施形態では、イベント通知のPublish及びSubscribeを行うことができる。なお、依頼情報テーブル５５は、ＲＡＭ１０４、ＨＤＤ１０８、又はネットワークを介してイベント通知装置１０に接続されるクラウド上のサーバー等に格納され得る。

以上、イベント通知プログラム、イベント通知方法及びイベント通知装置を上記実施形態により説明した。しかしながら、本発明にかかるイベント通知プログラム、イベント通知方法及びイベント通知装置は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記複数の実施形態に記載された事項は、矛盾しない範囲で組み合わせることができる。また、イベント通知装置の各機能は、ハードウェアにより構成されてもよく、ソフトウェアにより構成されてもよく、ハードウェアとソフトウェアとを組み合わせて構成されてもよい。

例えば、上記実施形態に係るイベント通知装置の構成は一例であり、本発明の範囲を限定するものではなく、用途や目的に応じて様々なシステム構成例があることは言うまでもない。

以上の説明に関し、更に以下の項を開示する。
（付記１）
イベント通知条件情報及び優先情報を含むイベント通知依頼を受け付け、
前記イベント通知条件情報に基づき前記イベント通知依頼に対する同期配信によるイベント通知の条件が成立するかを判定し、
前記イベント通知依頼に対する同期配信によるイベント通知の条件が成立したと判定された場合、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する、
処理をコンピュータに実行させるイベント通知プログラム。
（付記２）
前記イベント通知の条件が成立した際の前記優先情報に基づき算出される優先順位の値に基づき、前記イベントの通知を破棄する、
付記１に記載のイベント通知プログラム。
（付記３）
イベント通知条件情報および優先情報を含むイベント通知依頼を受け付け、
前記イベント通知条件情報に基づき前記イベント通知依頼に対する同期配信によるイベント通知の条件が成立するかを判定し、
前記イベント通知依頼に対する同期配信によるイベント通知の条件が成立したと判定された場合、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する、
処理をコンピュータが実行するイベント通知方法。
（付記４）
前記イベント通知の条件が成立した際の前記優先情報に基づき算出される優先順位の値に基づき、前記イベントの通知を破棄する、
付記３に記載のイベント通知方法。
（付記５）
イベント通知条件情報および優先情報を含むイベント通知依頼を受け付ける受付部と、
前記イベント通知条件情報に基づき前記イベント通知依頼に対する同期配信によるイベント通知の条件が成立するかを判定する判定部と、
前記イベント通知依頼に対する同期配信によるイベント通知の条件が成立したと判定された場合、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する通知部と、
を有するイベント通知装置。
（付記６）
前記通知部は、
前記イベント通知の条件が成立した際の前記優先情報に基づき算出される優先順位の値に基づき、前記イベントの通知を破棄する、
付記５に記載のイベント通知装置。

１０：イベント通知装置
１１ａ〜１１ｆ：ガジェット
３０、３１：イベント通知の依頼元
４０、４１：イベント通知の発行元
５０：データ連携部
５１：受付部
５２：記憶部
５３：優先度算出部
５４：通知部
５５：依頼情報テーブル
５５ａ：トピック名
５５ｂ：コールバック関数
５５ｃ：優先度（値）
５５ｄ：優先度（メソッド）

Claims (4)

1. イベント通知条件情報および優先情報を含むイベント通知依頼を受け付け、
   前記イベント通知条件情報に基づき前記イベント通知依頼に応じたイベントが発生し、かつ、該イベントのメッセージの同期配信を実行するか否かによってイベント通知の条件が成立するかを判定し、
   前記イベント通知依頼に応じたイベント通知が発生し、かつ、メッセージの同期配信を実行する場合、前記イベント通知の条件が成立したと判定し、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する、
   処理をコンピュータに実行させるイベント通知プログラム。
2. 前記イベント通知の条件が成立した際の前記優先情報に基づき算出される優先順位の値に基づき、前記イベントの通知を破棄する、
   請求項１に記載のイベント通知プログラム。
3. イベント通知条件情報および優先情報を含むイベント通知依頼を受け付け、
   前記イベント通知条件情報に基づき前記イベント通知依頼に応じたイベントが発生し、かつ、該イベントのメッセージの同期配信を実行するか否かによってイベント通知の条件が成立するかを判定し、
   前記イベント通知依頼に応じたイベント通知が発生し、かつ、メッセージの同期配信を実行する場合、前記イベント通知の条件が成立したと判定し、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する、
   処理をコンピュータが実行するイベント通知方法。
4. イベント通知条件情報および優先情報を含むイベント通知依頼を受け付ける受付部と、
   前記イベント通知条件情報に基づき前記イベント通知依頼に応じたイベントが発生し、かつ、該イベントのメッセージの同期配信を実行するか否かによってイベント通知の条件が成立するかを判定する判定部と、
   前記イベント通知依頼に応じたイベント通知が発生し、かつ、メッセージの同期配信を実行する場合、前記イベント通知の条件が成立したと判定し、前記優先情報の動的な条件に基づき特定された優先順位で前記イベントを通知する通知部と、
   を有するイベント通知装置。
   

Images