JP6788690B2 - 優先度の制御方法及びデータ処理システム - Google Patents

Description

本発明は、出版購読型システムの改良に関する。

従来から出版購読（Publish-Subscribe）型モデルを採用したメッセージハブ（以下、出版購読型メッセージハブ）では出版者（出版社）がデータを出版（発行）することができ、ある出版者のデータを不特定多数の購読者が受信することが可能になっている（例えば、特許文献１）。

近年、ＩＴやＩｏＴの分野では出版購読型のメッセージハブを大規模データ処理システムに適用することで、様々なデータソースを収容し、各データソースから収集したデータを様々な手法で分析処理を行うことが期待されている。これにより、拡張性の高いデータ処理システムの構築が可能になる。

米国特許出願公開第２００５／２６１９２３号明細書

優先度制御において、データの送信者が優先度を設定する技術が知られている。しかしながら、出版購読型メッセージハブでは、同じデータであっても購読者によってデータに対する重要性が変わる場合があるが、上記従来の技術では購読者側からの的確な優先度の設定を行うことができない、という問題があった。したがって、上記従来技術では、的確でない優先度に基づくスケジューリングにより、本来重要な業務が他の業務の処理によって阻害される場合があった。

そこで本発明は、上記問題点に鑑みてなされたもので、購読者側の優先度を反映可能な出版購読型システムを提供することを目的とする。

本願発明は、プロセッサとメモリを有して、データソースが発行したデータに所定の処理を実行した処理結果を端末に配信する業務を実行するサーバが、前記業務の優先度を制御する優先度の制御方法であって、前記端末が、前記サーバに前記業務の既定優先度と前記端末の情報とを送信する第１のステップと、前記サーバが、前記既定優先度を受信し、前記業務と前記既定優先度を対応付けて優先度管理情報に設定する第２のステップと、前記サーバが、前記データソースが発行するデータと、前記業務とを対応付けて購読者管理情報に設定する第３のステップと、前記データソースが、前記データの重要度を送信する第４のステップと、前記サーバが、前記データソースから受信した前記データの重要度を、前記業務と対応付けて前記優先度管理情報に設定する第５のステップと、前記サーバが、前記データと、前記端末の情報に基づいて興味度を設定する第６のステップと、前記サーバが、前記興味度を前記業務と対応付けて前記優先度管理情報に設定する第７のステップと、前記サーバが、前記優先度管理情報を参照して前記業務の前記既定優先度と前記重要度と前記興味度から前記業務の最終優先度を算出する第８のステップと、を含む。

本発明によれば、データの出版者が発行するデータの重要度に加えて、購読者側の端末の既定優先度を最終優先度に反映させる。これにより、データの出版者側の優先度と、購読者側の優先度とを加味した最終優先度の値で、データの配信を制御することが可能となる。

本発明の第１の実施例を示し、データ処理システムの構成の一例を示すブロック図である。 本発明の第１の実施例を示し、出版購読型メッセージハブサーバの構成の一例を示すブロック図である。 本発明の第１の実施例を示し、データ処理サーバの構成の一例を示すブロック図である。 本発明の第１の実施例を示し、データソースサーバの構成の一例を示すブロック図である。 本発明の第１の実施例を示し、データストアサーバの構成の一例を示すブロック図である。 本発明の第１の実施例を示し、携帯端末の構成の一例を示すブロック図である。 本発明の第１の実施例を示し、購読者管理情報の一例を示す図である。 本発明の第１の実施例を示し、業務優先度管理情報の一例を示す図である。 本発明の第１の実施例を示し、配信先管理情報の一例を示す図である。 本発明の第１の実施例を示し、業務の一例を示すブロック図である。 本発明の第１の実施例を示し、データ処理システムで行われる処理の一例を示すシーケンス図である。 本発明の第１の実施例を示し、データ処理サーバで行われるリソース割り当て処理の一例を示すフローチャートである。 本発明の第２の実施例を示し、データ処理サーバで行われる業務処理の一例を示すフローチャートである。 本発明の第３の実施例を示し、データ処理サーバで行われる業務処理の一例を示すフローチャートである。

以下、本発明の一実施形態について添付図面を用いて説明する。

図１は、本発明の実施例１のデータ処理システムの構成の一例を示すブロック図である。図１は、複数のデータソースサーバ５−１〜５−３と出版購読型メッセージハブサーバ２を含むデータセンタ１が公衆網６を介して接続され、データセンタ１と複数の携帯端末８−１〜８−２が公衆網７を介して接続される。

データセンタ１は、公衆網６を介してデータソースサーバ５−１〜５−３と通信を行う出版購読型メッセージハブサーバ２と、公衆網７を介して複数の携帯端末８−１〜８−２がとデータ処理サーバ３と、データ処理サーバ３から受信したデータを格納するデータストアサーバ４と、これらの出版購読型メッセージハブサーバ２とデータ処理サーバ３とデータストアサーバ４を接続する閉域網９を含む。

なお、以下の説明では、データソースサーバ５−１〜５−３の全体を指すときには「−」以降を省略した符号「５」で示す。他の構成要素の符号についても同様である。

データソースサーバ５は、出版購読型メッセージハブサーバ２にデータを送信可能で、出版購読型メッセージハブサーバ２は、データソースサーバ５からのデータを受信すると受信したデータをデータ処理サーバ３に配信する。

本実施例のデータは、電子書籍などの出版物に限定されるものではなく、センサから収集したデータや、他の装置から受信したデータを含み、データソースサーバ５−１〜５−３の各出版部５１０−１〜５１０−３が発行（出版）したデータである。

データ処理サーバ３は、出版購読型メッセージハブサーバ２からデータを受信すると受信したデータの形式変換や数値演算や論理演算等の所定の処理を実施し、処理した結果をデータストアサーバ４と購読者が利用する携帯端末８−１〜８−２に送信する。

データ処理サーバ３が行う所定の処理は、上述のように、データソースサーバ５が発行するデータはセンサの情報などのバイナリの情報を含むため、バイナリ等の情報を購読者が識別可能な情報に変換または加工するものである。

データストアサーバ４は、データ処理サーバ３から受信したデータを格納する。携帯端末８−１〜８−２は、データ処理サーバ３からデータを受信すると画面表示等の処理を行う。また、前記携帯端末８−１〜８−２は、センサなどから収集したデータをデータ処理サーバ３へ送信することが可能である。

なお、本実施例１では、ひとつのデータセンタ１にひとつの出版購読型メッセージハブサーバ２とデータ処理サーバ３を含む例を示したが、出版購読型メッセージハブサーバ２とデータ処理サーバ３が複数配置されていてもよい。また、データセンタ１は複数存在しても良い。

＜出版購読型メッセージハブ＞
図２は、出版購読型メッセージハブサーバ２の構成の一例を示すブロック図である。出版購読型メッセージハブサーバ２は、プログラムを実行するプロセッサ２１と、プログラムやデータを格納する不揮発性の記憶部２５と、他の装置と通信を行う通信部２４と、管理者からの入力や画面表示などを行う入出力部２３と、データやプログラムを一時的に保持するメモリ２２と、を含む。

メモリ２２には、ＯＳ２００と、重要度代理要求部２１０と、出版購読型メッセージハブ部２２０がロードされてプロセッサ２１によって実行される。重要度代理要求部２１０と、出版購読型メッセージハブ部２２０はＯＳ２００上で稼働する。

プロセッサ２１は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ２１は、重要度代理要求プログラムに従って処理することで重要度代理要求部２１０として機能する。他のプログラムについても同様である。さらに、プロセッサ２１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

重要度代理要求部２１０と、出版購読型メッセージハブ部２２０の各機能を実現するプログラムや、テーブル等の情報は、記憶部２５や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

出版購読型メッセージハブ部２２０は、購読者管理情報２３０と、話題設定変更部２４０と、購読者特定部２６０と、購読者設定変更部２５０と、データ配信部２７０と、を含む。

図７は、購読者管理情報２３０の一例を示す図である。購読者管理情報２３０は、データソースサーバ５が発行するデータの識別子を格納する話題２３１と、話題を購読する携帯端末８へデータ（処理結果）を送信する業務の識別子を格納する購読者２３２と、をエントリに含む。

購読者管理情報２３０は、出版購読型メッセージハブサーバ２の管理者などによって予め設定された情報である。購読者管理情報２３０を参照することで、出版購読型メッセージハブ部２２０は、データソースサーバ５が発行したデータを、データ処理サーバ３のいずれの業務（携帯端末８のユーザアプリ８１０の業務）で処理させるかを決定することができる。なお、本実施例１では、購読者２３２として携帯端末８のユーザアプリ８１０に情報を提供する業務３３０（図３参照）の識別子を格納しているが、後述するように、業務と配信先の携帯端末８の関係はデータ処理サーバ３が保持している。

重要度代理要求部２１０は、データソースサーバ５の出版部５１０から話題（データ）に関する重要度の更新要求を受け付けると、出版購読型メッセージハブ部２２０に対して当該話題２３１毎の購読者２３２を問合せし、問合せして得られた全ての購読者２３２の重要度の設定を更新するためにデータ処理サーバ３の業務スケジューラ部３１０に対して購読者２３２の重要度の更新要求を送信する。

次に、出版購読型メッセージハブ部２２０の話題設定変更部２４０は、データソースサーバ５の出版部５１０から、出版購読型メッセージハブサーバ２に話題の追加や削除などの更新要求を受け付けると、図７に示した購読者管理情報２３０の設定を更新する。

購読者設定変更部２５０は、データ処理サーバ３の業務から話題２３１の購読要求または購読解除の要求を受け付けると、購読者２３２の情報を更新する。

購読者特定部２６０は、重要度代理要求部２１０またはデータ配信部２７０から話題２３１に対する購読者２３２の問合せ要求を受信すると、購読者管理情報２３０を参照して問合せ要求で指定された話題２３１の購読者２３２を特定し、該当する購読者２３２を応答する。購読者特定部２６０は、例えば、「話題１」の購読者の問合せ要求を受け付けると、図７の購読者管理情報２３０から購読者２３２を特定して「業務１」と「業務４」を応答する。

データ配信部２７０は、データソースサーバ５の出版部５１０から購読者管理情報２３０に設定された話題２３１に対して送信されたデータをメモリ２２または記憶部２５に一時的に蓄積し、購読者特定部２６０に当該話題２３１の購読者２３２を問合せ、一時的に蓄積されたデータを該当購読者２３２へ配信する。

以上のように、出版購読型メッセージハブサーバ２は、重要度代理要求部２１０が、データソースサーバ５からの重要度の更新要求をデータ処理サーバ３へ送信して、データ処理サーバ３に重要度の更新を実行させる。また、出版購読型メッセージハブ部２２０は、購読者管理情報２３０の管理とデータソースサーバ５から受信したデータの配信を実施する。

＜データ処理サーバ＞
図３は、データ処理サーバ３の構成の一例を示すブロック図である。データ処理サーバ３は、プログラムを実行するプロセッサ３１と、プログラムやデータを格納する不揮発性の記憶部３５と、他の装置と通信を行う通信部３４と、管理者からの入力や画面表示などを行う入出力部３３と、データやプログラムを一時的に保持するメモリ３２と、を含む。

メモリ３２には、ＯＳ３００と、業務スケジューラ部３１０と、業務優先度管理部３６０と、業務３３０−１〜３３０−ｎと、配信先管理情報３４０と、計算機リソースモニタ部３７０がロードされてプロセッサ３１によって実行される。業務スケジューラ部３１０と、業務優先度管理部３６０と、業務３３０−１〜３３０−ｎと、計算機リソースモニタ部３７０はＯＳ３００上で稼働する。

プロセッサ３１は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ３１は、業務優先度管理プログラムに従って処理することで業務優先度管理部３６０として機能する。他のプログラムについても同様である。さらに、プロセッサ３１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

業務スケジューラ部３１０と、業務優先度管理部３６０と、業務３３０−１〜３３０−ｎと、計算機リソースモニタ部３７０の各機能を実現するプログラムや、テーブル等の情報は、記憶部３５や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

業務スケジューラ部３１０は、業務優先度管理情報３２０と、業務スケジューリング部３５０と、を含む。

業務３３０−１〜３３０−ｎは、出版購読型のメッセージ配信により出版購読型メッセージハブサーバ２から受信した話題（データ）を購読し、話題毎に様々な業務（分析業務）が割り当てられ、所定の処理を実行して携帯端末８のユーザアプリ８１０に配信する。なお、業務３３０と配信先の携帯端末８の関係は、配信先管理情報３４０で管理される。

業務３３０は、携帯端末８のユーザアプリ８１０に情報を提供する処理を含み、ユーザアプリ８１０または携帯端末８が指定した話題（データ）を業務３３０で購読して、当該データに指定された処理を行った処理結果を携帯端末８に配信する。

業務３３０は、データ処理サーバ３上では、出版購読型メッセージハブサーバ２の購読者の代理として機能し、業務３３０の処理結果は実質的な購読者である携帯端末８のユーザアプリ８１０で利用される。

配信先管理情報３４０は、図９で示すように、業務３３０の識別子を格納する業務３４１と、配信先の宛先を格納する配信先３４２とを一つのエントリに含む。配信先管理情報３４０は、業務３３０が起動するときに、予め設定された配信先を配信先管理情報３４０に登録する。なお、図示の例では、ひとつの業務３４１に、ひとつの配信先を割り当てた例を示すが、これに限定されるものではなく、ひとつの業務３４１に、複数の配信先を割り当てることができる。

各業務３３０は、出版購読型メッセージハブサーバ２に設定された話題２３１を購読して、出版購読型メッセージハブサーバ２から配信されたデータに対して所定の処理を実施する購読者として機能する。

購読者である業務３３０は、例えば、イベントドリブンで所定の処理を開始する。業務３３０は、出版購読型メッセージハブサーバ２からデータを受信すると、所定の自身の処理を実施し、処理の結果に応じて当該話題に対する興味度を判定して、興味度に変更があれば興味度の更新要求を業務スケジューラ部３１０に通知する。なお、興味度は、業務３３０が設定する購読対象の話題２３１に対する現在の優先度を示す。

業務スケジューラ部３１０は、業務優先度管理情報３２０に基づいて業務３３０に優先度を設定し、重要な業務３３０の実行を他の業務から保護する。業務優先度管理部３６０は、データソースサーバ５からの要求と、業務３３０からの要求に応じて業務優先度管理情報３２０を管理する。

計算機リソースモニタ部３７０は、ＯＳ３００からデータ処理サーバ３の計算機リソースの使用状態を取得して監視する。計算機リソースモニタ部３７０は、計算機リソースが不足していると判定した場合、業務スケジューラ部３１０の業務スケジューリング部３５０に対して後述する優先度スケジューリングを実施するよう指令する。なお、計算機リソースが不足していない場合、計算機リソースモニタ部３７０は、業務スケジューリング部３５０に対して後述する通常スケジューリングを実施するよう指令する。

なお、計算機リソースの監視の手法やリソース不足の判定に手法については、公知または周知の技術を用いることができる。例えば、監視対象の計算機リソースおよび指標はプロセッサ３１の負荷や、メモリ３２の使用率や、プロセスのプロセッサ占有率などがあり、計算機リソース不足の判定手法としては、それぞれの指標に対し予め設定した閾値と稼動状態との比較を用いることができる。

図８は、業務優先度管理情報３２０の一例を示す図である。業務優先度管理情報３２０は、データ処理サーバ３の業務３３０の識別子を格納する業務３２１と、携帯端末８を利用する購読者側の優先度を格納する既定優先度３２２と、データソースサーバ５側が設定する優先度を格納する重要度３２３と、携帯端末８を利用する購読者側の現在の優先度を格納する興味度３２４と、各優先度の総計を格納する最終優先度３２５と、をひとつのエントリに含む。

既定優先度３２２は、可変要素である重要度３２３と興味度３２４とを加味して業務３３０の最終優先度３２５を決定する際の基準値である。また、既定優先度３２２は、データ処理サーバ３で予め設定される購読者側の優先度の初期値である。

重要度３２３は、データソースサーバ５によって設定される優先度であって、配信内容に関する環境変化等に基づいて変更される。なお、重要度３２３は、購読者側（業務３３０または携帯端末８）で話題を利用または処理する際の優先度を示す。

興味度３２４は、業務３３０が動的に当該業務３３０の最終優先度３２５の変更を可能にすることを目的とした可変値である。例えば、業務３３０は、携帯端末８の状態を受信して、話題２３１に対する興味度を携帯端末８の状態に応じて変更することができる。例えば、話題２３１と携帯端末８の位置情報に相関関係がある場合、業務３３０は、携帯端末８の位置情報が所定の条件を満たせば興味度を増大させ、そうでない場合には興味度を低減させることで、最終優先度３２５を制御することができる。

このように、業務優先度管理情報３２０は、出版側のデータソースサーバ５から設定される重要度３２３と、購読側の携帯端末８（または業務３３０）から予め設定される既定優先度３２２と、に基づく最終優先度３２５を業務３３０毎に管理する。これにより、出版側の優先度に対する要求と、購読側の優先度に対する要求に応じて、業務３３０の実行環境を制御することができる。

そして、業務優先度管理情報３２０には、データを使用する購読者（業務３３０）が自身の環境変化等から判断して可変設定する興味度３２４を加えることで、業務３３０の状態に応じて最終優先度３２５を動的に更新することが可能となる。

業務優先度管理部３６０は、出版購読型メッセージハブサーバ２の重要度代理要求部２１０から重要度更新の要求を受け付けると、指定された業務３３０の重要度３２３を指定された値に設定して業務優先度管理情報３２０を更新する。

また、業務優先度管理部３６０は、業務３３０から興味度更新の要求を受け付けると、当該業務３３０の興味度３２４を指定された値に設定して業務優先度管理情報３２０を更新する。

業務優先度管理部３６０は、業務優先度管理情報３２０を更新すると最終優先度３２５の更新を実行する。

最終優先度３２５は、例えば、業務優先度管理部３６０が、既定優先度３２２と重要度３２３と興味度３２４を加算した値を用いる。なお、最終優先度３２５の算出については、これに限定されるものではなく、既定優先度３２２と重要度３２３と興味度３２４のそれぞれに重み係数を掛けてから加算する方法など、公知または周知の手法を適宜採用することができる。

業務スケジューリング部３５０は、計算機リソースモニタ部３７０からの要求に応じて、各業務３３０に対する計算機リソースの割り当てを制御する。計算機リソースモニタ部３７０が優先度スケジューリングを要求した場合、業務スケジューリング部３５０は、業務３３０毎の最終優先度３２５を参照して、プロセッサ３１の割り付け時間や単位時間当たりのリクエスト受付数などを、より最終優先度３２５の高い業務３３０により多くの計算機リソースが割り当てられるようにスケジュールする。

一方、計算機リソースモニタ部３７０が通常スケジューリングを要求した場合、業務スケジューリング部３５０は、最終優先度３２５を加味しない計算機リソースの割り当てを行う。業務スケジューリング部３５０は、例えば、ラウンドロビン等による計算機リソースの割り当てのスケジューリングを行う。なお、最終優先度３２５に応じた計算機リソースの配分は、公知または周知の手法を用いれば良いので、説明は省略する。

なお、上記では、業務スケジューラ部３１０が、計算機リソースモニタ部３７０からの指令によってスケジューリングの種類を切り替える例を示したが、業務スケジューラ部３１０は優先度スケジューリングを常時適用してもよい。

また、本実施例１では、業務スケジューリング部３５０は、各業務３３０に割り当てる計算機リソースが決定されると、当該割り当てを実行する。

図１０は、業務３３０−１の構成の一例を示す図である。本実施例１では、業務３３０−１が処理の状態に応じて興味度を更新する例を示す。図示の例では、購読するデータと、配信先の携帯端末８の位置情報の関係から業務３３０−１が興味度を更新する。

業務３３０−１は、携帯端末８の位置情報を格納する位置情報３３１と、購読しているデータ（降雨量データ）を処理する降雨量データ処理部３３２と、位置情報３３１から携帯端末８の位置情報を参照する位置情報参照部３３３とを含む。

降雨量データ処理部３３２は、出版購読型メッセージハブサーバ２から受信した降雨量データの所定の処理を実行して処理結果を生成する。降雨量データ処理部３３２は、配信先管理情報３４０を参照して配信先の携帯端末８−１とデータストアサーバ４に処理結果を送信する。業務３３０−１は、携帯端末８−１から位置情報を受信すると位置情報３３１に格納する。

業務３３０−１は、位置情報３３１を参照し、携帯端末８−１が河川の下流域付近にあると判定した場合、降雨量データは携帯端末８−１にとって重要であると判定する。そして、業務３３０−１は、興味度に所定値である「１」を加算して業務優先度管理部３６０へ興味度の更新を要求する。業務優先度管理部３６０は、興味度の更新要求を受信すると、指定された業務の興味度３２４を更新して最終優先度３２５を増大させる。

逆に、業務３３０−１は、携帯端末８−１が河川の下流域付近にないと判定した場合、降雨量データは携帯端末８−１にとって重要ではないと判定する。そして、業務３３０−１は、興味度から所定値である「１」を減算して業務優先度管理部３６０へ興味度の更新を要求する。業務優先度管理部３６０は、興味度の変更要求を受信すると、指定された業務の興味度３２４を更新し、最終優先度３２５を低下させる。

このように、各業務３３０は処理の状態に応じて、当該業務３３０に計算機リソースを割り当てる優先度を、興味度３２４によって動的に変更することができるのである。

以上のように、データ処理サーバ３は、出版購読型メッセージハブサーバ２から配信されたデータを購読者としての業務３３０で処理して携帯端末８に送信する。業務スケジューリング部３５０は、計算機リソースが不足する場合には、既定優先度３２２と重要度３２３を加味した最終優先度３２５の値に応じた計算機リソースを各業務３３０へ割り当てることが可能となる。

さらに、業務スケジューリング部３５０は、購読している話題２３１の内容や、業務３３０の処理結果を利用する携帯端末８の状態などに応じて興味度３２４を変更して、業務３３０毎の最終優先度３２５を動的に変更することができる。

＜データソースサーバ＞
図４は、データソースサーバ５−１の構成の一例を示すブロック図である。なお、データソースサーバ５−２及び５−３も、同様の構成であるので重複する説明は省略する。

データソースサーバ５は、プログラムを実行するプロセッサ５１と、プログラムやデータを格納する不揮発性の記憶部５５と、他の装置と通信を行う通信部５４と、管理者からの入力や画面表示などを行う入出力部５３と、データやプログラムを一時的に保持するメモリ５２と、位置や降雨量などの環境情報を検出するセンサ５６と、を含む。

メモリ５２には、ＯＳ５００と、出版部５１０−１がロードされてプロセッサ３１によって実行される。出版部５１０−１はＯＳ５００上で稼働する。

プロセッサ５１は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ５１は、出版プログラムに従って処理することで出版部５１０−１として機能する。他のプログラムについても同様である。さらに、プロセッサ５１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

センサ５６は、例えば、降雨量センサで構成され、出版部５１０−１のデータを購読する業務３３０としては、降雨量を検出して河川の上流域の降雨量を測定して、降雨量を監視する例を示す。

河川などの降雨量量監ステムの場合、河川の上流域の降雨量が所定の閾値を超えた場合に重要度が増大したと判定する。そして、出版部５１０は、話題を購読している購読者の重要度を上げるために出版購読型メッセージハブサーバ２の重要度代理要求部２１０へ重要度３２３の設定変更要求を行う。

逆に、河川の上流域の降雨量が所定の閾値以下になった場合、出版部５１０は、重要度が低下したと判定する。そして、出版部５１０は、話題を購読している購読者の重要度を上げるために出版購読型メッセージハブサーバ２の重要度代理要求部２１０へ重要度３２３の設定変更要求を行う。

以上のように、データソースサーバ５は、出版部５１０の判定に応じて動的に重要度３２３を動的に変更することができる。

＜データストアサーバ＞
図５は、データストアサーバ４の構成の一例を示すブロック図である。データストアサーバ４は、プログラムを実行するプロセッサ４１と、プログラムやデータを格納する不揮発性の記憶部４５と、他の装置と通信を行う通信部４４と、管理者からの入力や画面表示などを行う入出力部４３と、データやプログラムを一時的に保持するメモリ４２と、を含む。記憶部４５は、受信したデータを蓄積する蓄積データ４２０を有する。メモリ４２には、ＯＳ４００と、クエリ処理部４１０がロードされてプロセッサ４１によって実行される。クエリ処理部４１０はＯＳ４００上で稼働する。

データストアサーバ４は、データ処理サーバ３から送信された処理済みのデータを受信して蓄積データ４２０に格納する。

＜携帯端末＞
図８は、携帯端末８の構成の一例を示すブロック図である。携帯端末８は、プログラムを実行するプロセッサ８１と、プログラムやデータを格納する不揮発性の記憶部８５と、他の装置と通信を行う通信部８４と、管理者からの入力や画面表示などを行う入出力部８３と、データやプログラムを一時的に保持するメモリ８２と、位置情報を検出するセンサ８６を含む。

メモリ８２には、ＯＳ８００と、ユーザアプリ８１０がロードされてプロセッサ８１によって実行される。ユーザアプリ８１０はＯＳ４００上で稼働する。携帯端末８のユーザアプリ８１０は、データ処理サーバ３から送信された処理済みのデータを受信して入出力部８３のディスプレイなどに表示する。また、ユーザアプリ８１０は、携帯端末８の位置情報をデータ処理サーバ３へ送信する。

＜処理＞
図１１は、データ処理システムで行われる処理の一例を示すシーケンス図である。まず、携帯端末８のユーザアプリ８１０が、データソースサーバ５のデータを利用するために、データ処理サーバ３に対して業務開始要求を送信する（Ｓ１）。なお、業務開始要求には、購読対象の話題（データ）や業務３３０の種類や既定優先度３２２の値を含めることができる。

データ処理サーバ３は、業務開始要求に基づいて、業務３３０を起動して購読する話題を決定し（Ｓ２）、当該業務３３０の優先度の初期値である既定優先度を設定し、業務優先度管理情報３２０にエントリを追加する（Ｓ３）。データ処理サーバ３は、業務優先度管理情報３２０に業務３２１と既定優先度３２２を設定する。

業務３３０が購読する話題や既定優先度３２２は、上述のように携帯端末８が指定しても良いが、これに限定されるものではなく、携帯端末８が選択した業務３３０に応じて予め購読する話題と既定優先度３２２を設定しておいても良い。

データ処理サーバ３は、新たに起動した業務３３０が購読する話題の購読要求を出版購読型メッセージハブサーバ２に通知する（Ｓ４）。出版購読型メッセージハブサーバ２は、データ処理サーバ３から購読要求を受信すると、購読者管理情報２３０に話題２３１と購読者２３２を登録する（Ｓ５）。

そして、出版購読型メッセージハブサーバ２は、話題２３１の設定完了の通知をデータ処理サーバ３に送信する（Ｓ６）。データ処理サーバ３は、出版購読型メッセージハブサーバ２からの設定完了の通知を受け付けると、携帯端末８に業務３３０の開始を通知する（Ｓ７）。

業務３３０の開始以降は、次のステップＳ８〜ステップＳ１２の処理が繰り返して実行される。

まず、データソースサーバ５が話題（データ）を発行する（Ｓ８）。出版購読型メッセージハブサーバ２は、データソースサーバ５から話題を受信すると、購読者管理情報２３０を参照して購読者（配信先）を決定し（Ｓ９）、当該データの購読者となる業務３３０へデータを配信する（Ｓ１０）。出版購読型メッセージハブサーバ２は、データを配信する際に、購読者の情報をデータ処理サーバ３へ通知することができる。なお、これに限定されるものではなく、出版購読型メッセージハブサーバ２は、購読者管理情報２３０を更新する度に、購読者管理情報２３０の内容をデータ処理サーバ３へ通知しても良い。

出版購読型メッセージハブサーバ２からデータを受信したデータ処理サーバ３は、出版購読型メッセージハブサーバ２から通知された購読者の情報に基づいて、受信したデータを業務３３０に配信し、各業務３３０で所定の処理を実行させる（Ｓ１１）。各業務３３０は配信されたデータの処理結果を、配信先管理情報３４０の配信先３４２に設定された携帯端末８に送信する（Ｓ１２）。

次に出版側のデータソースサーバ５が重要度の変更を要求する例を、次のステップＳ１３〜ステップＳ１９に示す。

まず、データソースサーバ５は、発行するデータの値が所定の閾値を超えたか否かを判定し（Ｓ１３）、閾値を超えていれば出版購読型メッセージハブサーバ２に対して重要度を増大する更新要求を送信する（Ｓ１４）。

出版購読型メッセージハブサーバ２は、データソースサーバ５から重要度の更新要求を受け付けると、重要度代理要求部２１０が、データソースサーバ５が発行する話題２３１を購読する購読者２３２を特定する。そして、重要度代理要求部２１０は、特定した購読者２３２の重要度を増大する更新要求をデータ処理サーバ３に送信する（Ｓ１５）。

データ処理サーバ３は、出版購読型メッセージハブサーバ２から重要度の更新要求と購読者の業務を受け付けると、業務優先度管理部３６０が、業務優先度管理情報３２０の指定された業務について重要度３２３を更新する（Ｓ１６）。なお、業務優先度管理部３６０は、重要度を増大する更新要求の場合、所定値である「１」を重要度に加算する。そして、業務優先度管理部３６０は、当該業務３２１のエントリで最終優先度３２５を再計算して更新する（Ｓ１６）。

なお、データソースサーバ５は、データの値が所定の閾値を超えた後に、閾値以下になった場合、重要度を減少させる更新要求を送信し、上記と同様に処理することができる。

データ処理サーバ３は、重要度３２３の更新が完了した後に、更新完了の通知を出版購読型メッセージハブサーバ２へ送信する。出版購読型メッセージハブサーバ２は、受信した更新完了の通知をデータソースサーバ５に送信して重要度の更新処理を終了する（Ｓ１８、Ｓ１９）。

次に購読者側の業務３３０が興味度の更新を要求する例を、次のステップＳ２０〜ステップＳ２３に示す。

業務３３０は、携帯端末８から位置情報を受信する（Ｓ２０）。なお、携帯端末８からの位置情報の受信は、処理結果の配信の際に行うようにしても良い。業務３３０は、図１０で示したように、受信した位置情報を位置情報３３１に格納し、位置情報が予め設定された領域（河川の下流域付近）内にあるか否かを判定する（Ｓ２１）。位置情報が予め設定された領域内であれば、業務３３０は、業務優先度管理部３６０に対して、興味度３２４を増大する更新要求を出力する。

業務優先度管理部３６０は、業務３３０から興味度３２４の更新要求を受け付けると、当該業務について興味度３２４を更新する（Ｓ２２）。なお、業務優先度管理部３６０は、興味度３２４を増大する更新要求の場合、所定値である「１」を興味度３２４に加算する。そして、業務優先度管理部３６０は、当該業務３２１のエントリで最終優先度３２５を再計算して更新し（Ｓ２３）、更新処理を終了する。

なお、業務３３０は、位置情報が所定の領域外に移動した場合、興味度３２４を減少させる更新要求を送信し、上記と同様に処理することができる。

なお、上記では業務優先度管理部３６０が、重要度３２３を増減する値を設定する例を示したが、これに限定されるものではなく、重要度３２３の増減を判定するデータソースサーバ５が、重要度３２３の増分値（または減少値）を決定しても良い。

また、上記では業務優先度管理部３６０が、興味度３２４を増減する値を設定する例を示したが、これに限定されるものではなく、興味度３２４の増減を判定する業務３３０が、興味度３２４の増分値（または減少値）を決定しても良い。

図１２は、データ処理サーバ３できるだけ行われる業務３３０へのリソース割り当て処理の一例を示すシーケンス図である。この処理は、所定の周期（例えば、１分毎）で実行される。

計算機リソースモニタ部３７０は、データ処理サーバ３のＯＳ３００から計算機リソースの使用状態を取得する（Ｓ３１）。計算機リソースの使用状態は、上述のようにプロセッサ３１の使用率や、メモリ３２の使用率や、通信部３４の使用率等の予め設定された値を取得する。

計算機リソースモニタ部３７０は、取得した計算機リソースの使用状態の各値と、予め設定された閾値とを比較し（Ｓ３２）、閾値を超えている値があれば計算機リソースの不足が発生したと判定する（Ｓ３３）。計算機リソースモニタ部３７０は、計算機リソースの不足が発生している場合には、業務スケジューラ部３１０に計算機リソースの不足を通知してステップＳ３４へ進む。一方、計算機リソースの不足が発生していない場合、計算機リソースモニタ部３７０は、業務スケジューラ部３１０に計算機リソースの通常スケジューリングを通知してステップＳ３６へ進む。

ステップＳ３４では、計算機リソースの不足を受け付けた業務スケジューラ部３１０が、業務優先度管理情報３２０の最終優先度３２５を参照する。そして、業務スケジューラ部３１０は、最終優先度３２５の値の大きさに応じて、業務３３０毎に割り当てる計算機リソースを決定する優先度スケジューリングを実行する（Ｓ３５）。

ステップＳ３６では、計算機リソースの通常スケジューリングを受け付けた業務スケジューラ部３１０が、各業務３３０に計算機リソースの均等割り当てなど、所定の手法で配分する。

上記処理によって、業務スケジューラ部３１０はリソース不足が発生すると、最終優先度３２５に基づいて業務３３０に割り当てる計算機リソースをスケジューリングすることで、計算機リソースが不足している場合でも重要な業務３３０を他の業務３３０の影響から保護することができる。

以上、本実施例１によれば、データの出版者であるデータソースサーバ５が発行するデータの重要度に加えて、購読者側の携帯端末８の既定優先度を最終優先度に反映させることができる。これにより、データ処理サーバ３は、データの出版者側の優先度と、購読者側の優先度とを加味した最終優先度の値で、データの配信を制御することが可能となる。

そして、購読者側の業務スケジューラ部３１０内に予め設定する既定優先度３２２と、データの出版者が発行する話題（データ）に関して環境変化等から動的に設定する当該話題の重要度３２３を、最終優先度３２５に反映させる。これにより、データの出版者側の優先度と、購読者側の優先度とを加味した最終優先度３２５の値で、各業務３３０へ計算機リソースの割り当てを行うことが可能となって、データの出版者側および購読者側の双方から臨機応変にリソースの配分を制御することが可能となる。

さらに、データを使用する購読者（業務３３０）が、自身の環境変化等から動的に設定する興味度３２４を加えて、最終優先度３２５に反映させることにより、データの出版者側の動的な優先度と、購読者側の動的な優先度の双方を業務３３０への計算機リソースの割り当てに反映させることができる。

なお、上記実施例１では、出版購読型メッセージハブサーバ２とデータ処理サーバ３を異なる計算機で稼働させる例を示したが、同一の計算機（サーバ）で稼働させてもよい。この場合、出版側のデータソースサーバ５から発行されたデータを、購読側の携帯端末８に配信するサーバ（出版購読型メッセージハブサーバ２＋データ処理サーバ３）は、出版側からデータの優先度として重要度を受け付けて、購読側の携帯端末８から既定優先度３２２を受け付けて、重要度と既定優先度から最終優先度を算出し、最終優先度に応じて業務３３０のリソースを制御することになる。

前記実施例１では、出版購読型メッセージハブ部２２０は購読者にデータを送信するプッシュ型のデータ配信の一例を示したが、本実施例２では購読者としての業務３３０から出版購読型メッセージハブ部２２０にデータの取得要求を行うプル型のデータ配信を適用して例を示す。

本実施例２では、データソースサーバ５がデータを発行すると、出版購読型メッセージハブサーバ２は受信したデータを、全ての購読者の購読が完了するまで保持する。

図１３は、第２の実施例を示し、業務３３０で行われる処理の一例を示すフローチャートである。この処理は、所定の周期（例えば、１分毎）で実行される。

業務３３０は、出版購読型メッセージハブサーバ２に対してデータの購読要求を送信する（Ｓ４１）。出版購読型メッセージハブサーバ２は、当該業務３３０が購読しているデータが発行されていればデータをデータ処理サーバ３の業務３３０に配信する。

データ処理サーバ３の業務３３０は、購読中のデータを取得したか否かを判定する（Ｓ４２）。データを取得していればステップＳ４３へ進み、そうでない場合には処理を終了する。

ステップＳ４３では、取得したデータに所定の処理を実行し、処理の結果を配信先の携帯端末８及びデータストアサーバ４へ送信する。ステップＳ４４では、業務３３０が携帯端末８から位置情報を取得して、図１１のステップＳ２１と同様にして興味度３２４を更新するか否かを判定する。

次に、ステップＳ４５では、業務３３０が更新の有無を判定し、更新する場合にはステップＳ４６へ進み、そうでない場合には処理を終了する。ステップＳ４６では、業務３３０が興味度３２４の更新要求を業務優先度管理部３６０へ送信して処理を終了する。

以上のように、出版購読型メッセージハブサーバ２がプル型の場合でも、前記実施例１と同様に、データ処理サーバ３はデータソースサーバ５が発行した話題（データ）を処理して携帯端末８に配信することができるのである。

実施例１または実施例２では出版部５１０側から購読者である業務３３０の重要度を更新する場合、重要度代理要求部２１０を介して行っていたが、本実施例３では重要度代理要求部２１０の代わりに送信するデータに重要度を付与することで重要度３２３の更新を行う例を示す。

本実施例３では、前記実施例１の出版購読型メッセージハブサーバ２の重要度代理要求部２１０を使用しない。また、データソースサーバ５の出版部５１０は、データを発行する際に、重要度の更新が必要であれば、データに重要度を付加して配信する。

図１４は、第３の実施例を示し、業務３３０で行われる処理の一例を示すフローチャートである。この処理は、所定の周期（例えば、１分毎）で実行される。

業務３３０は、出版購読型メッセージハブサーバ２からデータを受信する（Ｓ５１）。業務３３０は、前記実施例１と同様にして、受信したデータに所定の処理を実行して、処理の結果を配信先の携帯端末８及びデータストアサーバ４へ送信する（Ｓ５２）。

次に、業務３３０は、受信したデータに重要度が付加されているか否かを判定する。データに重要度が付加されている場合にはステップＳ５４へ進み、付加されていなければステップＳ５５へ進む。

ステップＳ５４では、業務３３０は、データに付加されている重要度の値を取得して、業務優先度管理部３６０へ重要度３２３を指定された値で更新するように指令する。

ステップＳ５５では、業務３３０が携帯端末８から位置情報を取得して、図１１のステップＳ２１と同様にして興味度３２４を更新するか否かを判定する。更新する場合にはステップＳ５６へ進み、そうでない場合には処理を終了する。ステップＳ５６では、業務３３０が興味度３２４の更新要求を業務優先度管理部３６０へ送信して処理を終了する。

以上のように、データソースサーバ５が重要度を更新する際に、データに重要度を付加する場合は、実施例１に示した出版購読型メッセージハブサーバ２の重要度代理要求部２１０を使用せずに、データ処理サーバ３の業務３３０でデータに付加された重要度を受信して業務優先度管理情報３２０を更新させることができる。

本実施例３では、重要度代理要求部２１０を使用しないので、出版購読型メッセージハブサーバ２として前記従来例と同様の装置を利用することが可能となる。

＜まとめ＞
なお、前記実施例１では、業務３３０が処理するデータの一例として、データソースサーバ５から降雨量のデータを購読する例を示したが、これに限定されるものではなく、物量や価格あるいは文字列などのデータを含むことができる。

また、前記実施例１では、データソースサーバ５がデータを発行する例を示したが、これに限定されるものではなく、データを発行する主体は生産装置や輸送機械などがデータを発行してもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

Claims (8)

1. プロセッサとメモリを有して、データソースが発行したデータに所定の処理を実行した処理結果を端末に配信する業務を実行するサーバが、前記業務の優先度を制御する優先度の制御方法であって、
   前記端末が、前記サーバに前記業務の既定優先度と前記端末の情報とを送信する第１のステップと、
   前記サーバが、前記既定優先度を受信し、前記業務と前記既定優先度を対応付けて優先度管理情報に設定する第２のステップと、
   前記サーバが、前記データソースが発行するデータと、前記業務とを対応付けて購読者管理情報に設定する第３のステップと、
   前記データソースが、前記データの重要度を送信する第４のステップと、
   前記サーバが、前記データソースから受信した前記データの重要度を、前記業務と対応付けて前記優先度管理情報に設定する第５のステップと、
   前記サーバが、前記データと、前記端末の情報に基づいて興味度を設定する第６のステップと、
   前記サーバが、前記興味度を前記業務と対応付けて前記優先度管理情報に設定する第７のステップと、
   前記サーバが、前記優先度管理情報を参照して前記業務の前記既定優先度と前記重要度と前記興味度から前記業務の最終優先度を算出する第８のステップと、
   を含むことを特徴とする優先度の制御方法。
2. 請求項１に記載の優先度の制御方法であって、
   前記データソースが、前記データを発行する第９のステップと、
   前記サーバが、前記発行されたデータを受信して、前記業務の最終優先度に基づいて当該データの配信を制御する第１０のステップと、
   を含むことを特徴とする優先度の制御方法。
3. 請求項２に記載の優先度の制御方法であって、
   前記第１０のステップは、
   前記データソースから発行されたデータを受信して、当該データを購読する前記業務の最終優先度に基づいて、当該業務に割り当てる計算機リソースを制御することを特徴とする優先度の制御方法。
4. 請求項１に記載の優先度の制御方法であって、
   前記サーバは、
   前記データソースから発行されたデータを受信して、端末に前記データを配信する出版購読型メッセージハブと、前記出版購読型メッセージハブから配信されたデータを前記業務で処理した処理結果を前記端末に送信するデータ処理サーバと、を含むことを特徴とする優先度の制御方法。
5. プロセッサとメモリを有して、出版側のデータソースが発行したデータに所定の処理を実行した処理結果を端末に配信する業務を実行するサーバが、前記業務の優先度を制御するデータ処理システムであって、
   前記端末は、
   前記サーバに前記サーバに前記業務の既定優先度と前記端末の情報とを送信し、
   前記サーバは、
   前記既定優先度を受信し、前記業務と、前記既定優先度とを対応付けて優先度管理情報に設定し、前記データソースから受信した前記データの重要度を、前記業務と対応付けて前記優先度管理情報に設定する優先度管理部と、
   前記データソースが発行するデータと、前記業務とを対応付けて購読者管理情報に設定するメッセージハブ部と、を有し、
   前記優先度管理部は、
   前記データと、前記端末の情報に基づいて興味度を設定し、前記興味度を前記業務と対応付けて前記優先度管理情報に設定し、前記優先度管理情報を参照して前記業務の前記既定優先度と前記重要度と前記興味度から前記業務の最終優先度を算出することを特徴とするデータ処理システム。
6. 請求項５に記載のデータ処理システムであって、
   前記データソースが、前記データを発行し、
   前記サーバは、
   前記データソースが発行したデータを受信して、前記業務の最終優先度に基づいて当該データの配信を制御する業務スケジューラ部を有することを特徴とするデータ処理システム。
7. 請求項６に記載のデータ処理システムであって、
   前記業務スケジューラ部は、
   前記データを購読する前記業務の最終優先度に基づいて、当該業務に割り当てる計算機リソースを制御することを特徴とするデータ処理システム。
8. 請求項５に記載のデータ処理システムであって、
   前記サーバは、
   前記データソースから発行されたデータを受信して、配信先に前記データを配信する出版購読型メッセージハブと、前記出版購読型メッセージハブから配信されたデータを前記業務で処理した処理結果を前記端末に送信するデータ処理サーバと、を含み、
   前記出版購読型メッセージハブは、
   前記メッセージハブ部を含み、
   前記データ処理サーバは、
   前記優先度管理部を含むことを特徴とするデータ処理システム。

Images