(57)【要約】【課題】  センサ情報処理サーバのプログラム自体を修正することなく、複数のデータ管理方法を切り替える。【解決手段】  共通データベースの操作と、DHTなどを利用した分散型データベースの操作の違いを隠蔽したミドルウェアを導入する。このミドルウェアは、予めデータに付与されたデータ属性と、そのシステム共通のデータベースポリシを比較し、各データの保存方法（共通データベース、分散型データベース）を動的に決定する。センサ情報処理サーバのように、共通データベースと分散型データベースの両方を利用する可能性のあるプログラムは、このミドルウェアの提供するAPIを利用してデータベースを操作する。プログラマは、このAPIへの命令（SQL文など）か、またはプログラム外の設定ファイルの中に各データのデータ属性を埋め込む。一方、このシステムを運用する管理者は、各データ属性の扱いについて記述したデータベースポリシを作成する。【選択図】  図５
2008146119.tif 000002
【特許請求の範囲】
【請求項１】
パケットを送受信するインタフェースと、
プログラムが格納されたメモリと、
該メモリから該プログラムを読み出して該パケットを処理するCPUと、
分散データベースと、からなり、ネットワークを介して複数のサーバと共通データベースと接続されるセンサ情報処理サーバであって、
該メモリは、該パケットに含まれるデータのデータ属性を管理するデータ属性テーブルと上記ネットワーク共通のデータベースポリシを管理するデータベースポリシテーブルを備え、
前記データ属性テーブルと前記データベースポリシテーブルに基づいて、該データを格納するデータベースが前記分散データベースか前記共通データベースかを判断し、該判断されたデータベースに該データを格納することを特徴とするセンサ情報処理サーバ。
【請求項２】
前記データベースポリシは、前記分散データベース若しくは前記共通データベースへ格納する、または前記データを前記複数のサーバへミラーリングするかのうちいずれかであることを特徴とする請求項１記載のセンサ情報処理サーバ。
【請求項３】
前記判断において、前記データベースポリシテーブルが管理する前記データベースポリシには優先度が与えられており、該優先度の高いデータベースポリシから順番に、該データベースポリシテーブルの管理するデータ属性と前記データ属性テーブルの管理する該データの前記データ属性とが一致するか否かを判断し、最初に一致した該データベースの該データベースポリシを選び、該データを該データベースポリシに従って格納することを特徴とする請求項１記載のセンサ情報処理サーバ。
【請求項４】
前記判断において、前記データ属性テーブルの管理する該データの前記データ属性が、前記データベースポリシテーブルの管理する前記データ属性のいずれにも一致しない場合は、該データを前記複数のサーバへミラーリングすることを特徴とする請求項２記載のセンサ情報処理サーバ。
【請求項５】
前記判断において、前記データ属性テーブルの管理する該データの前記データ属性が、前記データベースポリシテーブルの管理する前記データ属性のいずれにも一致しない場合は、該データを共通データベースに保存することを特徴とする請求項３記載のセンサ情報処理サーバ。
【請求項６】
前記データ属性は、該データの全体または一部に付与されていることを特徴とする請求項１に記載のセンサ情報処理サーバ。
【請求項７】
前記データの属性は、前記分散データベースを有する複数のサーバから該データのデータ格納先を選ぶためのキーとして使いたい対象に付与されていることを特徴とする請求項１記載のセンサ情報処理サーバ。
【請求項８】
前記データが個人情報を表すデータである場合には、該データ全体に前記データ属性が付与されていることを特徴とする請求項１記載のセンサ情報処理サーバ。
【請求項９】
前記データがサーバ設定を表すデータである場合には、該データ全体に前記データ属性が付与されていることを特徴とする請求項１記載のセンサ情報処理サーバ。
【請求項１０】
ネットワークを介して、センサ情報配布元と接続されたセンサ情報処理サーバであって、
前記センサ情報配布元からセンサ情報を含むパケットを送受信するインタフェースと、
プログラムが格納されたメモリと、
該メモリから該プログラムを読み出して該パケットを処理するCPUと、からなり、
該メモリは、データ属性を管理するデータ属性テーブルと上記ネットワーク共通のデータベースポリシを管理するデータベースポリシテーブルを備え、
前記データ属性テーブルと前記データベースポリシテーブルに基づいて、前記センサ情報を含むパケットの送信先を判断することを特徴とするセンサ情報処理サーバ。
【請求項１１】
ネットワークを介して、センサ情報処理サーバに、センサ情報配布元、共通データベース及びアプリケーションサーバが接続されるセンサ情報処理システムであって、
前記センサ情報処理サーバは、
分散データベースと、上記センサ情報配布元から受信するデータのデータ属性を管理するデータ属性管理テーブルと、上記センサ情報処理システム共通のデータベースポリシを管理するデータベースポリシテーブルを備え、
上記データ属性管理テーブルと上記データベースポリシデーブルに基づいて、上記センサ情報配布元から受信するデータを格納するデータベースが前記分散データベースか前記共通データベースかを判断し、該データを該判断したデータベースに格納するセンサ情報処理システム。
【請求項１２】
前記判断において、前記データベースポリシテーブルの前記データベースポリシには優先度が与えられており、該優先度の高いデータベースポリシから順番に、該データベースポリシテーブルの管理するデータ属性と前記データ属性テーブルの管理する該データの前記データ属性とが一致するか否かを判断し、最初に一致した該データベースの該データベースポリシを選び、該データを該データベースポリシに従って格納することを特徴とする請求項１１記載のセンサ情報処理システム。
【請求項１３】
前記センサ情報処理サーバは、前記センサ情報配布元から過去に受信したセンサ情報の履歴を備え、前記センサ情報配布元からセンサ情報を受信し、該受信したセンサ情報と、前記過去のセンサ情報とを比較し、その結果に応じて前記アプリケーションサーバに制御メッセージを送信することを特徴とする請求項１１記載のセンサ情報処理システム。
【請求項１４】
前記データベースポリシは、前記分散データベース若しくは前記共通データベースへ格納する、または前記データを前記複数のサーバへミラーリングするかのうちいずれかであることを特徴とする請求項１１記載のセンサ情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機を備える計算機システムに関し、特に、頻繁に更新されるデータの分散処理技術に関する。
【背景技術】
【０００２】
近年、ユーザが所有する通信端末はデスクトップPCや各家庭の電話機、ビジネス用途の内線電話などの固定端末から、携帯電話やノートPCなどの移動端末まで多岐に渡りつつある。また、メールやインスタントメッセンジャー、テレビ電話の普及によって、ネットワークを利用した通信手段も多様化しつつある。
【０００３】
従って近未来のネットワークは、ユーザが複数の通信端末、複数の通信手段を使い分けられるように、ユーザを支援する必要がある。そのための方法としては、ユーザの状態を何らかの方法で取得し、それらの情報に基づいて通信アプリケーションを制御することが考えられる。
【０００４】
ユーザの情報を取得および利用するための従来技術としては、プレゼンスサービスがある（参考：非特許文献１）。プレゼンスサービスは、インスタントメッセージングソフトウェアやソフトフォンのユーザ状態表示機能という形で既に普及している。プレゼンスサービスは、一般にユーザの状態をネットワーク側で管理する1台以上のプレゼンスサーバから成る。プレゼンスサービスのユーザは、ユーザエージェント（以下、UA）と呼ばれるクライアントソフトウェアを通してプレゼンスサービスを利用する。ユーザが自分の状態（「オンライン」「退席中」「取り込み中」など）をUAに入力すると、UAはそれをプレゼンスサーバに登録する。そして、プレゼンスサーバはそのユーザの友達のUAに、登録された状態を配布する。
【０００５】
UAに状態を手入力することはユーザにとって面倒であるため、一般的に、プレゼンスサーバに登録される状態の精度はあまり高くない。そのため、プレゼンスサーバ上のユーザ状態は今まであまり活用されていない。また、プレゼンスサーバ上のデータに対する読み書きの回数も少なく、プレゼンスサーバ上のデータベースの負荷は問題にならなかった。
【０００６】
非集中かつアドホック的にプレゼンスサービスを実現する既存の研究としては、非特許文献２がある。
【０００７】
【非特許文献１】M. Day et al., A Model for Presence and Instant Messaging, RFC2778, February 2000.
【非特許文献２】K. Singh and H. Schulzrinne. Peer-to-peer internet telephony using SIP. In Proc. NOSSDOV 2005 (2005).
【発明の開示】
【発明が解決しようとする課題】
【０００８】
複数の通信端末、通信手段の使い分けを支援するためには、ユーザの手入力に頼らず、精度の高いユーザ状態を取得することが必要になる。そこで、ユーザに関する情報を各種センサから自動的に取得し、それらのセンサ情報からユーザの状況を推測して、通信アプリケーションを制御するサーバ（以下、センサ情報処理サーバ）が検討されている。
【０００９】
図１は、センサ情報処理サーバを利用した通信ネットワークの一例である。
センサ情報配布元２は、温度センサや圧力センサなどの各種センサ群から得られるデータを収集し、再配布するサーバ機器である。センサ情報配布元２は、センサから得られたデータをセンサ情報処理サーバ３へ送信する。センサ情報処理サーバ３はサーバ機器であり、センサ情報がどのように変化したらどのようなアプリケーション制御を行うか、という処理内容を記述したシナリオを備えている。センサ情報処理サーバ３は、センサ情報を受信すると、このシナリオに基づいて過去のセンサ情報と現在のセンサ情報を処理し、その結果に応じてアプリケーションを制御する。この例では、SIPサーバ４に対して、ユーザのプレゼンス情報の更新や、ユーザ間の呼制御を要求する制御メッセージを送信する。
【００１０】
このような制御メッセージを受信したSIPサーバ4は、SIP User Agent（以下、SIP UA）５に対してプレゼンス情報や呼制御メッセージを送信する。センサ情報処理サーバ３が制御するアプリケーションサーバは、この例（すなわちSIPサーバ）に限られるものではない。
【００１１】
今後、ユーザが携帯するセンサや、ユーザの周囲に配置されるセンサが増えるに従って、センサ情報処理サーバの処理量は増加する。そのため、将来的にはセンサ情報処理サーバの負荷分散が必要になる。
【００１２】
図２は、一般的な方法でセンサ情報処理サーバの負荷分散を行った通信ネットワークの一例である。センサ情報配布元２は、センサから得たセンサ情報をロードバランサ７へ送信する。ロードバランサ７は、ｎ台のセンサ情報処理サーバ３（ｎは１以上の整数）の負荷を監視しており、負荷の少ないセンサ情報処理サーバ３へセンサ情報を転送する。センサ情報処理サーバ３は、センサ情報を受信すると、過去のセンサ情報を共通データベースサーバ６から読み込み、現在のセンサ情報を共通データベースサーバ６に書き込む。そして、シナリオに基づいて過去のセンサ情報と現在のセンサ情報を処理し、その結果に応じてアプリケーションを制御する。この例では、SIPサーバ４に対して制御メッセージを送信する。SIPサーバ４とSIP UA５の動作は、図１の例と同じである。
【００１３】
一般的な方法でセンサ情報処理サーバの負荷分散を行う場合、センサ情報処理サーバがセンサ情報を受信するたびに、共通データベースへの読み書きが発生する。従って、共通データベースがシステム全体のボトルネックになる。また、ロードバランサと共通データベースがシステムの単一障害点（Single Point of Failure、ダウンするとシステム全体が止まる場所）になるため、これらの冗長化が必要になる。システムを導入する際には、前者は性能上、後者はコスト上の問題になる。
【００１４】
近年、複数のサーバ間で自律的にデータを分散・冗長化する技術として、分散ハッシュテーブル（Distributed Hash Table、DHT）が注目を集めている。
DHTは非集中型分散システムの一種である。DHTの特徴は、(1)そのシステムに参加するノード全体でキー空間を分割すること、および(2)キー空間の分割を工夫することで、特定のキーを管理するノードに向けて効率的にメッセージをルーティングすることである。キーとは一般にハッシュ値のことで、例えばハッシュ関数としてSHA-1（160ビット）を使う場合、キー空間は0〜2^160-1となる。DHTはこのような特徴を持つ分散システムの総称であり、DHTを実現する代表的なアルゴリズムにはChordなどがある。
【００１５】
DHTの主な用途は、ファイル名のハッシュ値をキーとして、各キーを管理するノードにデータを格納する大規模分散ストレージである。しかし、DHTの用途はストレージに限定されない。例えば、DHTをSIPの世界に応用したP2P SIPという研究がある。P2P SIPでは、SIPサーバ（レジストラとSIPプロクシが一体になったサーバ）群がDHTネットワークを構成する。そして、SIPサーバの1つがSIP UAからREGISTER（端末情報の登録要求）を受信すると、そのユーザのSIP URI（Uniform Resource Identifier、SIPにおけるユーザの識別子）のハッシュ値をDHTのキーとして用い、そのキーを管理するサーバへREGISTERを転送またはリダイレクトする。これにより、P2P SIPは単一障害点に成りうる特定のサーバに頼ることなくIP電話サービスを実現できる。
【００１６】
一方、センサ情報処理サーバが扱うセンサ情報も、その大半はユーザ（またはユーザが所有する端末）と関連付けられている。従って、DHTを利用してユーザの識別子とセンサ情報処理サーバの対応付けを行うことで、センサ情報処理もP2P SIPと同様の仕組みで分散化できると考えられる。
上記のように、DHTを利用してユーザの識別子とセンサ情報処理サーバの対応付けを行うことで、センサ情報処理サーバの負荷分散と冗長化を実現できる。
【００１７】
しかし、センサ情報処理サーバは、全ユーザに共通するデータも扱う必要がある。例えば、シナリオの動作を調整するためのパラメータは全ユーザに共通である。このような共通データは、DHTに基づくストレージや、全サーバへのミラーリング（データの更新を全サーバへ配布する方法）によって管理することもできる。しかし、センサ情報処理サーバの数が増えれば増えるほど、データの同期が難しくなる。従って、システムの規模によっては共通データベースが必要になる場合がある。
【００１８】
また、センサ情報の管理や、その履歴の再利用を容易にするために、利用者がデータの分散配置を望まない可能性がある。そのためには、図２の方法によって負荷分散を実現するという選択肢は残しておく必要がある。
従って、センサ情報処理サーバは、システムの規模やシステム管理者の要求に応じて、共通データベース、DHT及びミラーリングなど複数のデータ管理方法を切り替えられることが望ましい。
【００１９】
しかし、データ操作を行う全ての部分に複数のデータ管理方法を実装すると、開発量が多くなり、結果としてバグも多くなりやすいという課題がある。
【００２０】
本発明の目的はセンサ情報処理サーバのプログラム自体を修正することなく、複数のデータ管理方法を切り替えるための手段を提供することである。
【課題を解決するための手段】
【００２１】
本発明では、共通データベースの操作と、DHTなどを利用した分散型データベースの操作の違いを隠蔽したミドルウェア（以下、データベース/DHTミドルウェア）を導入し、データ属性とデータベースポリシに基づいて、データを格納するデータベースが分散データベースか共通データベースかを判断し、データを格納する。
【発明の効果】
【００２２】
データベース/DHTミドルウェアを採用したプログラムは、そのシステムの規模やシステム管理者の要求に応じて、プログラム自体に手を加えることなく、複数のデータ管理方法を切り替えることができるようになる。
特に、センサ情報処理サーバにこのミドルウェアを採用した場合、センサ情報処理のボトルネックであった共通データベースへのアクセスが減少するまたは共通データベースが不要になり、処理速度が向上する。また、センサ情報処理がサーバ間で自律分散されるため、単一障害点となる分散装置が不要である構成も可能となり、必要な設備投資が減少する。
【実施例１】
【００２３】
以下、実施例を図面を用いて説明する。
図３に、本実施例で想定する通信ネットワークの物理的な構成を模式的に示す。通信網１−１、センサ情報配布元２、センサ情報処理サーバ３、SIPサーバ４は、互いに物理的な通信回線９を介して接続されている。また、通信網１−２、SIPサーバ４、SIP UA５は互いに物理的な通信回線９を介して接続されている。図３では、見やすさのために通信網１−１と１−２を分けているが、この両者は同じ通信網であってもよい。
【００２４】
センサ情報配布元２は、温度センサや圧力センサなどの各種センサ群から得られるデータを収集し、再配布するサーバ機器である。センサ情報配布元２は、センサから得られたデータと、そのデータを生成したセンサの識別子（以下、センサID）の組をセンサ情報処理サーバ３へ送信する。以下では、センサIDとデータの組をまとめてセンサ情報と呼ぶ。
【００２５】
本実施例でセンサ情報配布元２が扱うセンサ群は、Zigbee等の短距離無線通信をサポートし、近くにある基地局のID（以下、基地局ID）をセンサ情報配布元２に提供するセンサ群であるとする。この基地局IDは、各センサおよびその所有者の位置を推測する手がかりとして利用できるデータである。また、各センサはその他のセンサ（温度センサや照度センサなど）も同時に備え、それらのセンサから得たデータを基地局IDと共に提供することも可能である。温度センサは所有者の居る場所の温度を、照度センサは所有者の居る場所の明るさを推測する手がかりとして利用できるデータである。
【００２６】
センサ情報配布元２がセンサ群からデータを受け取ると、センサ情報配布元２はそのセンサ情報をセンサ情報処理サーバ３へ送信する。センサ情報の例を図２２に示す。この例ではセンサ情報をXML形式で表現している。node要素はデータを生成したセンサに関する情報を格納する要素である。node要素の中のid要素は、センサIDを格納している。そして、parameters要素はそのセンサが生成した1つ以上のデータを格納する要素である。parameters要素の中のparameter要素は、各データを表す。図２２の例は、base station IDという名前のデータ（すなわち基地局ID）が0001であることを示している。
【００２７】
センサ情報処理サーバ３はサーバ機器であり、センサ情報がどのように変化したらどのようなアプリケーション制御を行うか、という処理内容を記述したシナリオを備えている。センサ情報処理サーバ３は、センサ情報を受信すると、このシナリオに基づいて過去のセンサ情報と現在のセンサ情報を処理し、その結果に応じてアプリケーションを制御する。このとき、過去と現在のセンサ情報を比較することで、センサ情報に変化が無い場合は処理を省略して負荷を軽減できる。
【００２８】
本実施例では、センサ情報処理サーバ３はSIPサーバ４に対して、ユーザのプレゼンス情報の更新や、ユーザ間の呼制御を要求する制御メッセージを送信する。これにより、複数の通信端末、通信手段の使い分けを支援することが可能になる。例えば、あるユーザに連絡を取るために最も隣接した通信端末を、そのユーザの友人に公開することができる。
【００２９】
センサ情報処理サーバ３が制御する対象は、本実施例のSIPサーバに限られるものではなく、Webサーバや会議サーバなどを制御することも可能である。例えば、Webサーバを制御することでユーザの位置や状況に応じたコンテンツの提供、会議サーバを制御することでユーザの状況に応じた会議の開始が可能になる。
【００３０】
SIPサーバ４はサーバ機器であり、ｍ台のSIP UA５（ｍは1以上の整数）を管理し、SIP UA５との間でSIPメッセージを送受信する機能を持つ。SIPサーバ４は、SIPメッセージを通して、音声通話などの通信セッション制御や、プレゼンス情報の更新や通知などを行う。また、SIPサーバ４は、センサ情報処理サーバ３などからの制御メッセージを受信する機能を備える。SIP UA５は、音声通話やプレゼンス情報の表示などの機能を備えた端末である。これらは、PCや電話のような固定端末、または携帯電話やPDA（Personal Digital Assistant）のような移動端末である。
【００３１】
図５は、センサ情報処理サーバ３の内部構造を示す機能ブロック図である。この内部構造は、センサ情報処理サーバ３−１から３−ｎの全てに共通である。センサ情報処理サーバ３はIF３１を通してパケットを送受信する。センサ情報処理サーバ３の各プログラムはメモリ３３に格納されており、動作時にはCPU３２がデータパス３４を通してそれらを読み出して実行する。図中の点線は、データベース操作などを除いた、センサ情報処理の主な流れを示している。
【００３２】
メモリ３３はセンサ情報処理プログラム３３１、データ管理プログラム３３２、データベース/DHTミドルウェア３３３、データベースミドルウェア３３４、DHTミドルウェア３３５、ミラーリングプログラム３３６、データベースプログラム３３７を格納する。
【００３３】
センサ情報処理プログラム３３１は、センサ情報を受信し、センサ情報の変化に応じてアプリケーション制御を行うプログラムである。このプログラムの主な処理部は、センサID解決部３３１１、シナリオ部３３１２、アプリケーション制御部３３１３の3つに分けられる。
【００３４】
センサID解決部３３１１は、センサ情報配布元２からセンサ情報を受信する。そして、センサ情報に含まれるセンサIDを、制御対象のアプリケーションがユーザを識別するために使う識別子（以下、ユーザID）に変換する。本実施例では制御対象のアプリケーションがSIPであるため、ユーザIDとはSIP URIのことである。センサID解決部３３１１は、データベースプログラムまたはDHTミドルウェアに格納されているセンサIDデータを元に、この変換を行う。
【００３５】
センサIDデータは、センサIDとユーザIDの対応関係を表すデータである。センサIDデータの例を図１４に示す。この例ではセンサIDデータをテーブルとして保存しており、列１００１はユーザIDを、列１００２はセンサIDを表す。
シナリオ部３３１２は、センサ情報がどのように変化したらどのようなアプリケーション制御を行うか、という処理内容が記述されたプログラムである。受信したセンサ情報と過去のセンサ情報を比較し、その変化に応じて、アプリケーション制御部３３１３にアプリケーション制御を要求する。
【００３６】
本実施例では、シナリオ部３３１２は、センサ情報に含まれる基地局IDに応じて、そのユーザの位置を表すプレゼンス情報を更新するものとする。まず、シナリオ部３３１２は、センサ情報の履歴を、データベースプログラムまたはDHTミドルウェアから読み込み、そのユーザの基地局IDが変化したか確かめる。そして、基地局IDが変化していた場合は、新しい基地局IDを、データベースプログラムまたはDHTミドルウェアに格納する。そして、シナリオ設定（この例では新しい基地局IDが表す位置）を、データベースプログラムまたはDHTミドルウェアから読み込み、アプリケーション制御部３３１３にプレゼンス情報の更新を要求する。これにより、プレゼンス情報の自動更新を実現する。
センサ情報履歴とは、過去のセンサ情報を表すデータである。センサ情報履歴の例を図１５に示す。この例ではセンサ情報履歴をテーブルとして保存しており、列２００１はユーザID、列２００２はセンサID、列２００３は基地局ID、列２００４はデータの更新時刻を表す。
【００３７】
シナリオ設定とは、シナリオの動作を調整するためのパラメータ（この例では、基地局IDと位置の関係）を表すデータである。シナリオ設定の例を図１６に示す。この例ではシナリオ設定をテーブルとして保存しており、列３００１は基地局ID、列３００２はその位置を表現する文字列を表す。シナリオ設定をテーブルとして保存することで、管理者は、シナリオ部３３１２のプログラムを修正することなく、シナリオの動作を調整できる。
【００３８】
アプリケーション制御部３３１３は、シナリオ部の要求に応じて、各種アプリケーションサーバに対して制御メッセージを送信する。本実施例では、アプリケーションサーバの一種であるSIPサーバ４に対して、ユーザのプレゼンス情報の更新や、ユーザ間の呼制御を要求する制御メッセージを送信する。
【００３９】
データ管理プログラム３３２は、管理者の操作に応じて、センサ情報処理に関するデータを操作する管理用プログラムである。データ管理プログラム３３２は、データベース/DHTミドルウェア３３３を通して、データベースプログラムまたはDHTミドルウェアに格納されているデータを操作する。データの管理に共通データベースを利用しない場合、通常ならば、管理者は各センサ情報処理サーバ３上のデータを1台1台操作する必要がある。しかし、このデータ管理プログラム３３２を利用することで、管理者は１つのセンサ情報処理サーバ３から全センサ情報処理サーバ３上のデータを操作することが可能になる。
【００４０】
データベース/DHTミドルウェア３３３は、複数のデータ管理方法（すなわちデータベースミドルウェア３３４、DHTミドルウェア３３５、ミラーリングプログラム３３６）の違いを隠蔽するプログラムである。センサ情報処理プログラム３３１を修正せずにデータ管理方法を切り替えられるようにするためには、センサ情報処理プログラム３３１に対してデータ管理方法の違いを隠蔽する必要がある。そのため、データベース/DHTミドルウェア３３３は、全てのデータ管理方法に共通のAPI（Application Program Interface）を備えている。センサ情報処理プログラム３３１とデータ管理プログラム３３２は、このAPIを利用することで、データベースプログラムまたはDHTミドルウェアに格納されているデータを操作する。
【００４１】
データベース/DHTミドルウェア３３３は、このミドルウェアを通して操作されるデータのデータ属性を管理している。データ属性とは、このミドルウェアを利用するプログラマが、データの一部または全体に付与する属性のことである。属性とは、そのデータの意味を表す文字列である。1つのデータに複数のデータ属性を付与してもよい。データ属性の例を図１７に示す。この例ではデータ属性をテーブルとして保存しており、列４００１はデータの名前、列４００２は属性が付与されている対象、列４００３は属性が付与されている対象の名前、列４００４は付与されている属性を表す。例えば、行４０１１は、センサ情報履歴２０００のユーザID２００１に、「ユーザID」という名前の属性が付与されていることを示している。また、属性がデータ全体に付与されている場合は、データ名４００１と対象の名前４００３は同じになる。そのため、行４０１３のような例では対象の名前４００３を省略している。
【００４２】
データ全体に付与されるデータ属性は、そのデータが特別な扱いをされる可能性があることを示す。つまり、特別な扱いをされる可能性があるデータに対して、プログラマが予め付与する。例えば、ユーザの個人情報に関するデータは厳重に管理される必要があるため、特別に共通データベースで管理される可能性がある。そのため、ユーザの個人情報に関するデータには予め「個人情報」というデータ属性を付与しておく。また、サーバが頻繁に読み込む設定はできるだけサーバの近くに配置すべきであるため、特別にミラーリングで管理される可能性がある。そのため、サーバが頻繁に読み込む設定には予め「サーバ設定」というデータ属性を付与しておく。このようにデータ属性を付与したデータの扱いは、管理者が後述するデータベースポリシを変更することで、後から変更できるようになる。
【００４３】
一方、データの一部に付与されるデータ属性は、主にそのデータがDHTのような分散データベースで保存される可能性があることを示す。データの保存方法として、後述する「DHT」のような分散データベースを使用する場合、分散データベースを構成するサーバ群からデータ格納先を選ぶためのキーが必要になる。そのため、あるデータを分散データベースに保存する可能性がある場合は、そのデータの一部（キーとして使われる部分）に何らかのデータ属性を付与しておく必要がある。データベース/DHTミドルウェア３３３は、このような情報無しでは、データのどの部分をキーとして使うべきか判断できないためである。本実施例では、全てのセンサ情報処理サーバ３のデータベース/DHTミドルウェア３３３が、図１７に示すデータ属性を持っているものとする。
【００４４】
また、データベース/DHTミドルウェア３３３は、このミドルウェアが使われているシステム全体で共通のデータベースポリシを管理している。データベースポリシとは、データ属性と、そのデータ属性を持つデータの保存方法を記述したルールのことである。データベースポリシの例を図１８に示す。この例ではデータベースポリシをテーブルとして保存しており、列５００１はそのデータベースポリシの優先度、列５００２はデータ属性の対象、列５００３はデータ属性、列５００４はデータの保存方法を表す。優先度５００１は数値が低いほど優先度が高いものとして扱う。また、優先度が「−」になっているデータベースポリシはデフォルトのデータベースポリシ（以下、デフォルトポリシ）であり、それ以外のどのデータベースポリシにも該当しなかったデータに対して適用される。データベースポリシ５０００は、プログラムの外の設定ファイルなどから読み込まれる。データベース/DHTミドルウェア３３３がデータベースポリシをプログラムの外の設定ファイルから読み込むことで、管理者はデータベース/DHTミドルウェア３３３のプログラムを修正することなく、データの保存方法を変更できる。
【００４５】
保存方法５００４は、「データベース」「DHT」「ミラーリング」のいずれかである。「データベース」の場合は、データベースミドルウェア３３４を通してデータの読み書きを行う。「DHT」の場合は、DHTミドルウェア３３５を通してデータの読み書きを行う。「ミラーリング」の場合は、データベースミドルウェア３３４を通してデータの読み込みを行い、ミラーリングプログラム３３６を通してデータの書き込みを行う。例えば、行５０１１は、「データの一部に「ユーザID」という名前の属性が付与されているデータは、そのデータをキーとしてDHTに保存する」、ということを示している（これ以降の文章では、「Aをキーとして」という記述を「Aのハッシュ値をキーとして」という意味で使用する）。センサ情報処理サーバ３が扱うデータの中では、センサ情報履歴２０００がこのデータベースポリシに一致する。従って、センサ情報履歴２０００は、ユーザID２００１をキーとしてDHTに保存される。
【００４６】
本実施例では、全てのセンサ情報処理サーバ３のデータベース/DHTミドルウェア３３３が、図１８に示すデータベースポリシを持っているものとする。
行５０１１は、データ属性が「ユーザID」のデータを含むデータ（すなわちセンサ情報）は、DHTを使って保存するというポリシを示している。データ属性が「ユーザID」のデータを含むデータ（すなわちセンサ情報）は読み書きされる頻度が高い。そのため、センサ情報を各センサ情報処理サーバ３に分散配置することで、データの読み書きが特定のサーバに集中することがなくなり、処理が高速化するという効果がある。
【００４７】
一方、行５０１２は、他のどのポリシにも該当しなかったデータはミラーリングする、というデフォルトポリシを示している。これにより、DHTで使用できるキーがデータ属性として指定されていないデータについても、センサ情報処理サーバ群に分散配置できる。
【００４８】
データベース/DHTミドルウェア３３３が提供するAPIの実装方法は4通りある。これは、データベース/DHTミドルウェア３３３に対してデータの操作を指示する方法が2通りあり、そしてデータにデータ属性を付与する方法が2通りあるためである。
【００４９】
まず、データの操作を指示する方法は、SQLのようなデータベース操作用言語で書いた命令をミドルウェアに渡す方法と、プログラム言語特有のデータ構造をそのままミドルウェアに渡す方法がある。後者の方法はオブジェクト指向プログラム言語でよく用いられるため、一般にオブジェクト／リレーショナルマッピング（以下、O/Rマッピング）と呼ばれている。前者の方法は、従来のデータベース操作用言語に慣れている開発者にとっては使いやすいというメリットがある。一方、後者の方法は、プログラム言語のデータ構造と、各種データベース特有のデータ構造の違いを開発者が意識しなくて済むというメリットがある。
【００５０】
そして、データにデータ属性を付与する方法は、データ操作の中にデータ属性を表すデータを埋め込む方法と、プログラムの外の設定ファイルとしてデータ属性を与える方法がある。前者の方法は、余分な設定ファイル等を用意する必要がないというメリットがある。一方、後者の方法は、データ属性を後から変更しやすいというメリットがある。
【００５１】
データ操作の中にデータ属性を表すデータを埋め込むためには、データベース操作用言語またはオブジェクト指向プログラム言語を拡張する必要がある。SQLの場合は、テーブル（データの全体）やカラム（データの一部）の名前に独自の修飾を付ける必要がある。Javaの場合は、アノテーションという機能を使うことで、クラス（データの全体）や変数（データの一部）にデータ属性を付与することができる。または、テーブルやクラス、カラムや変数の名前それ自体をデータ属性として扱うこともできる。本実施例のデータベース/DHTミドルウェア３３３は、データの操作を指示する方法としてデータベース操作用言語を受け付けるものとする。また、プログラムの外の設定ファイルからデータ属性を読み込むものとする。
【００５２】
また、データベース/DHTミドルウェア３３３は、メッセージ配送機能を持つ。メッセージ配送機能とは、キーとデータ属性を指定してメッセージを送信する機能である。指定されたデータ属性を持つデータの保存方法が「DHT」以外の場合は、そのサーバのメッセージハンドラにメッセージを渡す。保存方法が「DHT」の場合は、DHTミドルウェア３３５のメッセージ配送機能を用いて指定されたキーに対応するサーバまでメッセージを配送し、そのサーバのメッセージハンドラにメッセージを渡す。本実施例では、シナリオ部３３１２が、データベース/DHTミドルウェア３３３に対してメッセージハンドラを登録しているものとする。
【００５３】
センサ情報処理サーバ３は、このメッセージ配送機能を利用して、ある1人のユーザに関するセンサ情報を１つのセンサ情報処理サーバ３に集約する。これにより、ある1人のユーザに関するセンサ情報を処理する際に、他のサーバと通信する必要がなくなり、処理が高速化する。
【００５４】
データベースミドルウェア３３４は、ローカルのデータベースプログラム３３７およびリモートのデータベースプログラムを操作するためのプログラムである。ローカルのデータベースプログラム３３７は、保存方法が「ミラーリング」のデータを保存する際にも使用される。データベースミドルウェア３３４は、データベースプログラムに接続するために必要な情報（一般にはユーザ名、パスワードなど）を管理する。データベースミドルウェア３３４は、既存のODBC（Open DataBase Connectivity）ドライバの機能やO/Rマッピングなどの機能を持つ。DHTミドルウェア３３５は、DHT特有のルーティングテーブルを管理し、このルーティングテーブルに基づいて、メッセージ配送機能とストレージ機能を提供するプログラムである。DHTのルーティングテーブルは、キーと、そのキーに対応するノード（すなわちセンサ情報処理サーバ３）の対応関係を表す。DHTミドルウェア３３５は、特定のキーに対するメッセージ配送要求を受けると、そのキーに対応するノードをルーティングテーブルから調べ、そのノードに対してメッセージを配送する。ストレージに対するデータ操作要求も、メッセージ配送要求と同様に処理される。また、DHTミドルウェア３３５は、定期的に他のノードのDHTミドルウェアと制御メッセージを交換する。これにより、ノードが増減しても、ルーティングテーブルはすぐに更新される。
【００５５】
本実施例では、全てのセンサ情報処理サーバ３のDHTミドルウェア３３５が持つルーティングテーブルにおいて、キー「sip:ando@example.com」に対応するノードはセンサ情報処理サーバ３−２であるとする。
メッセージ配送機能とは、キーを指定してメッセージを送信する機能である。指定されたキーに対応するノードに到着するまで、メッセージは転送され続ける。そして、指定されたキーに対応するノードに到着すると、そのメッセージはメッセージハンドラに渡される。本実施例では、データベース/DHTミドルウェア３３３が、DHTミドルウェア３３５に対してメッセージハンドラを登録しているものとする。
【００５６】
ストレージ機能とは、キーを指定してデータを操作（参照、追加、削除）する機能である。データの操作命令は、メッセージ配送機能によって、指定されたキーに対応するノードまで配送される。そして、指定されたキーに対応するノードに到着すると、そのノードのDHTミドルウェア３３５のデータ領域にあるデータが操作される。センサ情報処理サーバ３は、このストレージ機能を利用して、共通データベースなしでのデータ管理を実現する。
【００５７】
DHTミドルウェア３３５がデータを保存する方法は、リレーショナルデータベース、オンメモリデータベース、ファイル形式など、特に形式を問わない。本実施例では、DHTミドルウェア３３５のメモリ空間に、テーブルとしてデータが保存されるものとする。
【００５８】
ミラーリングプログラム３３６は、データの変更を他のサーバへブロードキャストするためのプログラムである。ミラーリングプログラム３３６は、他のサーバのミラーリングプログラム３３６からのメッセージを受信するためのソケットを持つ。また、ミラーリングプログラム３３６は、他のサーバのミラーリングプログラム３３６へメッセージを送信するためのネットワークアドレスを管理している。このネットワークアドレスは、各サーバのネットワークアドレスのリスト、ブロードキャストアドレス、マルチキャストアドレスなどである。本実施例では、各サーバのネットワークアドレスのリストを管理しているものとする。ミラーリングはDHTと同様に、共通データベースなしでのデータ管理を実現する機能である。しかし、更新頻度の低いデータは、DHTで管理するよりもミラーリングで管理した方がよい。なぜなら、そのデータを読み込む際に他のサーバと通信する必要が無くなるからである。
【００５９】
データベースプログラム３３７は、既存のデータベースサーバプログラムである。
本実施例では、全てのセンサ情報処理サーバ３のデータベースプログラム３３７が、図１４のセンサIDデータテーブル１０００および図１６のシナリオ設定テーブル３０００の値を保持しているものとする。また、センサ情報処理サーバ３−２のDHTミドルウェア３３５が、図１５のセンサ情報履歴２０００の値を保持しているものとする（他のセンサ情報処理サーバが保持している値は省略する）。
【００６０】
図６および図７は、センサ情報配布元２が送信したセンサ情報を、適切なセンサ情報処理サーバ３が処理するまでの動作の一例を示したシーケンス図である。この例でセンサ情報配布元２が送信するセンサ情報は、センサIDが「00006c0000090003」、基地局IDが「0003」であるものとする。
【００６１】
まず、センサ情報配布元２は、センサ情報処理サーバ３−１のセンサID解決部３３１１に対してセンサ情報を送信する（S101）。
【００６２】
センサID解決部３３１１は、データベース/DHTミドルウェア３３３に対して、センサIDが「00006c0000090003」のセンサIDデータ１０００を要求する（S102）。
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシを決定する。
【００６３】
まず、データベース/DHTミドルウェア３３３は、データへのアクセス要求から、対象データのデータ名を取得する（S501）。次に、データ名４００１が、S501で取得したデータ名に一致するデータ属性を、データ属性テーブル４０００から取得する（S502）。この場合、データ名は「センサIDデータ」なので、データベース/DHTミドルウェア３３３は行４０１３のデータ属性を取得する。
【００６４】
データ属性が１つ以上あった場合、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S503、S504）。この例では、データベース/DHTミドルウェア３３３は行５０１１のデータベースポリシを取得する。
【００６５】
データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、そのデータベースポリシと比較する（S505、S506）。データ属性の対象４００２とデータベースポリシの対象５００２が等しく、かつデータ属性の属性４００４とデータベースポリシの属性５００３が等しいとき、そのデータ属性とデータベースポリシは一致しているとする。
【００６６】
この例では、行４０１３のデータ属性と、行５０１１のデータベースポリシは一致していない（S507）。また、次に優先度の高いデータベースポリシが存在しない（S509、S505）。従って、デフォルトポリシ５０１２が適用される（S510）。つまり、データベース/DHTミドルウェア３３３は、センサIDデータの保存方法は「ミラーリング」である、と判断する（S103）。このように、データベース/DHTミドルウェア３３３は優先度に従ってデータベースポリシを決定するため、管理者は複数のデータ属性が付与されたデータの保存方法を適切に設定できる。
【００６７】
保存方法が「ミラーリング」のデータは、各センサ情報処理サーバ３のデータベースプログラム３３７に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３４に対して、センサIDが「00006c0000090003」のセンサIDデータ１０００を要求する（S104）。データベースミドルウェア３３４は、この要求をデータベースプログラム３３７に送信する（S105）。
【００６８】
この要求を受信したデータベースプログラム３３７は、センサIDデータテーブル１０００の行１０１１を結果として返す（S106〜S107）。データベース/DHTミドルウェア３３３は、この結果をセンサID解決部３３１１に返す（S108）。これにより、センサID解決部３３１１は、センサID「00006c0000090003」に対応するユーザIDが「sip:ando@example.com」であると知ることができる。センサID解決部３３１１は、このユーザIDをセンサ情報の中に挿入する（S109）。ユーザIDを挿入したセンサ情報の例を、図２５に示す。図２５では、図２２のセンサ情報にuser要素が挿入されている。user要素はこのセンサ情報が表すセンサに対応するユーザの情報を格納する要素である。user要素の中のid要素は、ユーザIDを格納している。
【００６９】
次に、センサID解決部３３１１は、データベース/DHTミドルウェア３３３に対して、センサ情報を含むメッセージの送信を要求する（S110）。このとき、メッセージの送信に使うキーとしてS108で取得したユーザID（すなわち「sip:ando@example.com」）を指定し、データ属性として「ユーザID」を指定する。
【００７０】
データベース/DHTミドルウェア３３３は、メッセージの送信を要求されると、図２４のフローチャートに従ってそのメッセージの送信先を決定する。まず、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S610）。この例では、データベース/DHTミドルウェア３３３は行５０１１のデータベースポリシを取得する。データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、そのデータベースポリシの保存方法が「DHT」かどうかを調べる（S603）。この例では、行５０１１の保存方法は「DHT」であるため、次に、データベース/DHTミドルウェア３３３はそのデータベースポリシのデータ属性が、与えられたデータ属性（ここでは「ユーザID」と一致するかどうかを調べる（S604）。行５０１１のデータ属性は「ユーザID」であるため、データベース/DHTミドルウェア３３３はメッセージの送信先は「DHTミドルウェア」である、と判断する（S605）。
【００７１】
このように、データベース/DHTミドルウェア３３３は、メッセージの送信先を判断する際にもデータ属性とデータベースポリシを利用する。これにより、データベースポリシを変更してデータの保存方法が「DHT」から「データベース」に変わったとしても、センサ情報処理サーバ３間でメッセージを送受信するプログラムを修正する必要はない。
【００７２】
データベース/DHTミドルウェア３３３は、DHTミドルウェア３３３に対して、センサ情報を含むメッセージの送信を要求する（S112）。このとき、センサ情報の送信に使うキーとして、センサID解決部３３１１が指定したキーを指定する。
【００７３】
DHTミドルウェア３３３は、ルーティングテーブルを参照して、センサ情報を含むメッセージの送信先を決定する（S113）。本実施例では、キー「sip:ando@example.com」に対応するノードはセンサ情報処理サーバ３−２である。従って、DHTミドルウェア３３３は、センサ情報処理サーバ３−２へ、センサ情報を含むメッセージを送信する（S114）。
【００７４】
センサ情報処理サーバ３−２のDHTミドルウェア３３３は、このメッセージを受信すると、ルーティングテーブルを参照して、このメッセージの送信先を決定する（S115）。キーに対応するノードが他のサーバの場合は、そのサーバへ再度メッセージを転送する。しかし、本実施例では、キー「sip:ando@example.com」を担当するサーバはセンサ情報処理サーバ３−２である。そのため、DHTミドルウェア３３５は、データベース/DHTミドルウェア３３３にメッセージの受信を通知する（S116）。データベース/DHTミドルウェア３３３は、このメッセージをメッセージハンドラに渡す。前述の通り、シナリオ部３３１２は事前にメッセージハンドラを登録しているので、シナリオ部３３１２はメッセージハンドラを通して、このセンサ情報を含むメッセージを受信する（S117）。
【００７５】
センサ情報を受信すると、シナリオ部３３１２は、そのセンサ情報に含まれるユーザのセンサ情報履歴をデータベース/DHTミドルウェア３３３に要求する（S118）。つまり、ユーザIDが「sip:ando@example.com」のセンサ情報履歴を要求する。
【００７６】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。
【００７７】
まず、データベース/DHTミドルウェア３３３は、データへのアクセス要求から、対象データのデータ名を取得する（S501）。次に、データ名４００１が、S501で取得したデータ名に一致するデータ属性を、データ属性テーブル４０００から取得する（S502）。この場合、データ名は「センサ情報履歴」なので、データベース/DHTミドルウェア３３３は行４０１１のデータ属性を取得する。
【００７８】
データ属性が1つ以上あった場合、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S503、S504）。この例では、データベース/DHTミドルウェア３３３は行５０１１のデータベースポリシを取得する。
【００７９】
データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、S504で取り出した１つのデータベースポリシと比較する（S505、S506）。
【００８０】
この例では、行４０１１のデータ属性と、行５０１１のデータベースポリシは一致している。従って、その行５０１１のデータベースポリシが適用される（S507、S508）。つまり、データベース/DHTミドルウェア３３３は、センサ情報履歴の保存方法は「DHT」である、と判断する（S119）。また、データベースポリシ５０１１は、DHTのキーとして、データ属性「ユーザID」が付与されたデータを使うよう指示している。
【００８１】
保存方法が「DHT」のデータは、各センサ情報処理サーバ３のDHTミドルウェア３３５に保存されている。そのため、データベース/DHTミドルウェア３３３は、DHTミドルウェア３３５に対して、ユーザIDが「sip:ando@example.com」のセンサ情報履歴２０００を要求する（S120）。また、このときDHTのキーとしてユーザID「sip:ando@example.com」を指定する。
【００８２】
この要求を受信したDHTミドルウェア３３５は、ルーティングテーブルを参照して、どのノード上のデータを検索するか決定する（S121）。本実施例では、キー「sip:ando@example.com」に対応するノードはセンサ情報処理サーバ３−２である。従って、DHTミドルウェア３３５は、そのミドルウェア自身が保存しているセンサ情報履歴２０００の行２０１１を結果として返す（S122）。データベース/DHTミドルウェア３３３は、この結果をシナリオ部３３１２に返す（S123）。これにより、シナリオ部３３１２は、このユーザの基地局IDが「0001」から「0003」に変化したことを知ることができる。
【００８３】
センサ情報が変化すると、シナリオ部３３１２は、その新しいセンサ情報をデータベースプログラムまたはDHTミドルウェアに保存する。そのために、シナリオ部３３１２は、データベース/DHTミドルウェアにセンサ情報履歴の更新を要求する（S124）。
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。S119と同様に、データベース/DHTミドルウェア３３３は、センサ情報履歴の保存方法は「DHT」である、と判断する（S125）。また、データベースポリシ５０１１は、DHTのキーとして、データ属性「ユーザID」が付与されたデータを使うよう指示している。
【００８４】
保存方法が「DHT」のデータは、各センサ情報処理サーバ３のDHTミドルウェア３３５に保存されている。そのため、データベース/DHTミドルウェア３３３は、DHTミドルウェア３３５に対して、ユーザIDが「sip:ando@example.com」のセンサ情報履歴２０００の更新を要求する（S126）。また、このときDHTのキーとしてユーザID「sip:ando@example.com」を指定する。
【００８５】
この要求を受信したDHTミドルウェア３３５は、ルーティングテーブルを参照して、どのノード上のデータを更新するか決定する（S127）。本実施例では、キー「sip:ando@example.com」に対応するノードはセンサ情報処理サーバ３−２である。従って、DHTミドルウェア３３５は、そのミドルウェア自身が保存しているセンサ情報履歴２０００の行２０１１を新しい値（基地局ID２００３は「0003」、更新時刻２００４はその時の日時）で更新する。そして、更新の成功をデータベース/DHTミドルウェア３３３に通知する（S128）。データベース/DHTミドルウェア３３３は、この結果をシナリオ部３３１２に返す（S129）。これにより、シナリオ部３３１２は、センサ情報履歴の更新に成功したことを知ることができる。もしもセンサ情報履歴の更新に失敗した場合は、同様の方法でシナリオ部３３１２にエラーを通知する。
【００８６】
センサ情報が変化すると、シナリオ部３３１２は設定情報を読み込んでアプリケーションを制御する。本実施例では、センサ情報に含まれる基地局IDに応じて、そのユーザの位置を表すプレゼンス情報を更新する。各基地局IDに対応する位置は、データベースプログラムまたはDHTミドルウェアから取得する。
【００８７】
シナリオ部３３１２は、基地局IDが「0003」のシナリオ設定３０００をデータベース/DHTミドルウェアに要求する（S130）。
【００８８】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。
【００８９】
まず、データベース/DHTミドルウェア３３３は、データへのアクセス要求から、対象データのデータ名を取得する（S501）。次に、データ名４００１が、S501で取得したデータ名に一致するデータ属性を、データ属性テーブル４０００から取得する（S502）。この場合、データ名は「シナリオ設定」なので、データベース/DHTミドルウェア３３３は行４０１２のデータ属性を取得する。
【００９０】
データ属性が１つ以上あった場合、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S503、S504）。この例では、データベース/DHTミドルウェア３３３は行５０１１のデータベースポリシを取得する。
【００９１】
データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、そのデータベースポリシと比較する（S505、S506）。
【００９２】
この例では、行４０１２のデータ属性と、行５０１１のデータベースポリシは一致していない（S507）。また、次に優先度の高いデータベースポリシが存在しない。従って、デフォルトポリシ５０１２が適用される（S509、S505、S510）。つまり、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「ミラーリング」である、と判断する（S131）。これにより、サーバが頻繁に読み込む設定はサーバ上に配置され、高速に参照される。
【００９３】
保存方法が「ミラーリング」のデータは、各センサ情報処理サーバ３のデータベースプログラム３３７に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３４に対して、基地局IDが「0003」のシナリオ設定３０００を要求する（S132）。データベースミドルウェア３３４は、この要求をデータベースプログラム３３７に送信する（S133）。
【００９４】
この要求を受信したデータベースプログラム３３７は、シナリオ設定テーブル３０００の行３０１３を結果として返す（S134）。データベースミドルウェア３３４は、この結果をデータベース/DHTミドルウェア３３３に返す（S135）。データベース/DHTミドルウェア３３３は、この結果をシナリオ部３３１２に返す（S136）。これにより、シナリオ部３３１２は、基地局ID「0003」に対応する位置が「会議室２」であると知ることができる。
【００９５】
シナリオ部３３１２は、ユーザID「sip:ando@example.com」のユーザの位置を「会議室２」に更新することを、アプリケーション制御部３３１３に要求する（S137）。アプリケーション制御部３３１３は、SIPサーバ４に対して、プレゼンス情報を更新するための制御メッセージを送信する（S138）。
以上が、センサ情報処理の一連の流れである。
【００９６】
図８は、管理者がセンサ情報処理サーバ３−１のデータ管理プログラム３３２を利用して、シナリオ設定を更新する動作の一例を示したシーケンス図である。
まず、管理者がデータ管理プログラム３３２を利用してシナリオ設定を更新すると、データ管理プログラム３３２は、データベース/DHTミドルウェア３３３に対して、シナリオ設定の更新を要求する（S151）。この例では、シナリオ設定３０００の行３０１３の位置を、「会議室２」から「休憩室」に更新したものとする。
【００９７】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。S131と同様に、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「ミラーリング」である、と判断する（S152）。
【００９８】
保存方法が「ミラーリング」のデータは、各センサ情報処理サーバ３のデータベースプログラム３３７に保存されている。そのため、データベース/DHTミドルウェア３３３は、まずローカルのデータベースプログラム３３７の中のデータを更新するために、データベースミドルウェア３３４に対して、シナリオ設定の更新を要求する（S153）。データベースミドルウェア３３４はデータベースプログラム３３７の管理するシナリオ設定を更新し、更新の成功をデータベース/DHTミドルウェア３３３に通知する（S154〜156）。これにより、ローカルのデータベースプログラム３３７の中のデータの更新は終了する。もしもセンサ情報履歴の更新に失敗した場合は、データ管理プログラム３３２にエラーを通知して処理を終了する。
【００９９】
次に、リモートのサーバ上のデータベースプログラム３３７の中のデータを更新するために、ミラーリングプログラム３３６に対して、シナリオ設定の更新を依頼するための更新メッセージの送信を要求する（S157）。ミラーリングプログラム３３６は、このプログラムが管理する全てのネットワークアドレスに対して、更新メッセージを送信する（S158）。
【０１００】
各センサ情報処理サーバのミラーリングプログラム３３６は、受信した更新メッセージに従い、データベースミドルウェア３３４に対して、シナリオ設定の更新を要求する（S159）。
【０１０１】
データベースミドルウェア３３４はデータベースプログラム３３７の管理するシナリオ設定を更新し、更新の成功をミラーリングプログラム３３６に通知する（S160〜162）。これにより、リモートのデータベースプログラム３３７の中のデータの更新は終了する。各センサ情報処理サーバのミラーリングプログラム３３６は、データの更新に成功すると、センサ情報処理サーバ３−１のミラーリングプログラム３３６に対して、成功通知メッセージを送信する（S163）。もしもデータの更新に失敗した場合は、センサ情報処理サーバ３−１のミラーリングプログラム３３６に対して、エラー通知メッセージを送信する。
【０１０２】
センサ情報処理サーバ３−１のミラーリングプログラム３３６は、全てのセンサ情報処理サーバから成功通知メッセージを受信すると、更新の成功をデータベース/DHTミドルウェア３３３に通知する（S164）。これにより、データベース/DHTミドルウェア３３３はローカルとリモート両方のデータの更新に成功したことを知ることができる。そして最後に、データベース/DHTミドルウェア３３３はシナリオ設定の更新成功をデータ管理プログラム３３２に通知する（S165）。
【０１０３】
データの更新を高速化するために、ローカルの更新（S153〜S156）と、リモートの更新（S157〜S164）を並列に行ってもよい。同様に、複数のデータの更新を並列に行ってもよい。
以上のようにして、ユーザIDをキーとしたDHTを利用してセンサ情報をルーティングすることで、センサ情報処理がサーバ間で自律分散されるようになる。これにより、単一障害点となりうるロードバランサが不要になり、可用性が向上する。
【０１０４】
また、センサ情報処理のボトルネックであった共通データベースが不要になり、処理速度が向上する。特に、シナリオ部によるセンサ情報履歴の参照および更新、そしてミラーリングされたシナリオ設定の参照が高速化する。
【０１０５】
また、データベースポリシの内容を変更すれば、センサ情報処理プログラム３３１を変更することなく、複数のデータ管理方法を切り替えることができる。異なるデータベースポリシの例は、以下の実施例２〜４で説明する。
【実施例２】
【０１０６】
実施例１では、センサ情報をDHTミドルウェアに保存する場合の動作を示した。実施例２では、シナリオ設定もDHTミドルウェアに保存する場合について説明する。
本実施例で想定する通信ネットワークの物理的な構成は、実施例１のもの（図３）と同じである。
【０１０７】
また、センサ情報処理サーバ３の内部構造は、実施例１のもの（図５）と同じである。
ただし、本実施例では、全てのセンサ情報処理サーバ３のデータベース/DHTミドルウェア３３３が、図１９に示すデータベースポリシを持っているものとする。このデータベースポリシの行５０１３は、データ属性が「ユーザID」のデータを含むデータ（すなわちセンサ情報）は、DHTを使って保存するというポリシを示している。行５０１４は、データ属性が「基地局ID」のデータを含むデータ（すなわちシナリオ設定）は、DHTを使って保存するというポリシを示している。また、行５０１５は、他のどのポリシにも該当しなかったデータはミラーリングする、というデフォルトポリシを示している。
【０１０８】
本実施例では、全てのセンサ情報処理サーバ３のDHTミドルウェア３３５が持つルーティングテーブルにおいて、キー「sip:ando@example.com」に対応するノードはセンサ情報処理サーバ３−２であるとする。同様に、キー「0003」に対応するノードはセンサ情報処理サーバ３−３であるとする。
【０１０９】
本実施例では、全てのセンサ情報処理サーバ３のデータベースプログラム３３７が、図１４のセンサIDデータテーブル１０００の値を保持しているものとする。また、センサ情報処理サーバ３−２のDHTミドルウェア３３５が、図１５のセンサ情報履歴２０００の値を保持しているものとする（他のセンサ情報処理サーバが保持している値は省略する）。そして、センサ情報処理サーバ３−３のDHTミドルウェア３３５が、図１６のシナリオ設定テーブル３０００の値を保持しているものとする（他のセンサ情報処理サーバが保持している値は省略する）。
【０１１０】
図９は、センサ情報配布元２が送信したセンサ情報を、適切なセンサ情報処理サーバ３が処理するまでの動作の一例を示したシーケンス図の一部である。この例でセンサ情報配布元２が送信するセンサ情報は、センサIDが「00006c0000090003」、基地局IDが「0003」であるものとする。
【０１１１】
S101からS129までの動作は実施例１と同じであるため、ここでは省略する。
センサ情報が変化すると、シナリオ部３３１２は設定情報を読み込んでアプリケーションを制御する。従って、シナリオ部３３１２は、基地局IDが「0003」のシナリオ設定３０００をデータベース/DHTミドルウェアに要求する（S201）。
【０１１２】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。
【０１１３】
まず、データベース/DHTミドルウェア３３３は、データへのアクセス要求から、対象データのデータ名を取得する（S501）。次に、データ名４００１が、S501で取得したデータ名に一致するデータ属性を、データ属性テーブル４０００から取得する（S502）。この場合、データ名は「シナリオ設定」なので、データベース/DHTミドルウェア３３３は行４０１２のデータ属性を取得する。
【０１１４】
データ属性が１つ以上あった場合、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S503、S504）。この例では、データベース/DHTミドルウェア３３３は行５０１３のデータベースポリシを取得する。
【０１１５】
データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、そのデータベースポリシと比較する（S505、S506）。
【０１１６】
この例では、行４０１２のデータ属性と、行５０１３のデータベースポリシは一致していない。そこで、データベースポリシテーブル５０００から次に優先度の高いデータベースポリシを取り出す（S507、S509）。
【０１１７】
そして、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、S509で取り出した１つのデータベースポリシと比較する（S505、S506）。この例では、行４０１２のデータ属性と、行５０１４のデータベースポリシは一致している。従って、センサ情報履歴に対しては行５０１４のデータベースポリシを適用する（S507、S508）。つまり、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「DHT」である、と判断する（S202）。また、データベースポリシ５０１４は、DHTのキーとして、データ属性「基地局ID」が付与されたデータを使うよう指示している。
【０１１８】
保存方法が「DHT」のデータは、各センサ情報処理サーバ３のDHTミドルウェア３３５に保存されている。そのため、データベース/DHTミドルウェア３３３は、DHTミドルウェア３３５に対して、基地局IDが「0003」のシナリオ設定３０００を要求する（S203）。また、このときDHTのキーとして基地局ID「0003」を指定する。
【０１１９】
この要求を受信したDHTミドルウェア３３５は、ルーティングテーブルを参照して、どのノード上のデータを検索するか決定する（S204）。本実施例では、キー「0003」に対応するノードはセンサ情報処理サーバ３−３である。従って、DHTミドルウェア３３５は、シナリオ設定３０００の検索要求メッセージをセンサ情報処理サーバ３−３へ送信する（S205）。このとき、DHTのキーとして基地局ID「0003」を指定する。
【０１２０】
センサ情報処理サーバ３−３のDHTミドルウェア３３３は、このメッセージを受信すると、ルーティングテーブルを参照して、このメッセージの送信先を決定する（S206）。キーに対応するノードが他のサーバの場合は、そのサーバへ再度メッセージを転送する。しかし、本実施例では、キー「sip:ando@example.com」を担当するサーバはセンサ情報処理サーバ３−３である。そのため、DHTミドルウェア３３５は、そのミドルウェア自身が保存しているシナリオ設定３０００の行３０１３を結果として返す（S207）。センサ情報処理サーバ３−２のDHTミドルウェア３３５は、この結果をデータベース/DHTミドルウェア３３３に返す（S208）。また、データベース/DHTミドルウェアは、この結果をシナリオ部３３１２に返す（S209）。これにより、シナリオ部３３１２は、基地局ID「0003」に対応する位置が「会議室２」であると知ることができる。
【０１２１】
シナリオ部３３１２は、ユーザID「sip:ando@example.com」のユーザの位置を「会議室２」に更新することを、アプリケーション制御部３３１３に要求する（S210）。アプリケーション制御部３３１３は、SIPサーバ４に対して、プレゼンス情報を更新するための制御メッセージを送信する（S211）。
以上が、センサ情報処理の一連の流れである。
【０１２２】
図１０は、管理者がセンサ情報処理サーバ３−１のデータ管理プログラム３３２を利用して、シナリオ設定を更新する動作の一例を示したシーケンス図である。
まず、管理者がデータ管理プログラム３３２を利用してシナリオ設定を更新すると、データ管理プログラム３３２は、データベース/DHTミドルウェア３３３に対して、シナリオ設定の更新を要求する（S251）。この例では、シナリオ設定３０００の行３０１３の位置を、「会議室２」から「休憩室」に更新したものとする。
【０１２３】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。S202と同様に、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「DHT」である、と判断する（S252）。
【０１２４】
保存方法が「DHT」のデータは、ある特定のセンサ情報処理サーバ３のDHTミドルウェア３３５に保存されている。そのため、データベース/DHTミドルウェア３３３は、DHTミドルウェア３３５に対して、シナリオ設定の更新を要求する（S253）。このとき、DHTのキーとして基地局ID「0003」を指定する。
【０１２５】
この要求を受信したDHTミドルウェア３３５は、ルーティングテーブルを参照して、どのノード上のデータを検索するか決定する（S254）。本実施例では、キー「0003」に対応するノードはセンサ情報処理サーバ３−３である。従って、DHTミドルウェア３３５は、シナリオ設定３０００の更新メッセージをセンサ情報処理サーバ３−３へ送信する（S255）。このとき、DHTのキーとして基地局ID「0003」を指定する。
【０１２６】
センサ情報処理サーバ３−３のDHTミドルウェア３３３は、このメッセージを受信すると、ルーティングテーブルを参照して、このメッセージの送信先を決定する（S256）。キーに対応するノードが他のサーバの場合は、そのサーバへ再度メッセージを転送する。しかし、本実施例では、キー「0003」を担当するサーバはセンサ情報処理サーバ３−３である。そのため、DHTミドルウェア３３５は、そのミドルウェア自身が保存しているシナリオ設定３０００の行３０１３を更新する。データの更新に成功すると、センサ情報処理サーバ３−２のDHTミドルウェア３３５に対して、成功通知メッセージを送信する（S257）。
【０１２７】
センサ情報処理サーバ３−２のDHTミドルウェア３３５は、この成功通知メッセージを受信すると、更新の成功をデータベース/DHTミドルウェア３３３に通知する（S258）。そして最後に、データベース/DHTミドルウェア３３３はシナリオ設定の更新成功をデータ管理プログラム３３２に通知する（S259）。
【０１２８】
以上のようにして、管理者がデータベースポリシの内容を変更するだけで、センサ情報処理プログラムを変更することなく、実施例１とは異なるデータ管理方法へと切り替えることができる。
【０１２９】
実施例２では、ユーザIDをキーとしたDHTを利用してセンサ情報をルーティングすることで、センサ情報処理がサーバ間で自律分散されるようになる。これは実施例１と同様である。
【０１３０】
一方、実施例１では、シナリオ設定を更新する際に、全てのサーバに対して更新メッセージを送る必要があった。しかし実施例２ではDHTを使ってシナリオ設定を保存することで、シナリオ設定の更新に必要なメッセージの数が実施例１よりも減った。従って、シナリオ設定を頻繁に更新する必要がある場合や、サーバの数が多い場合は、本実施例のデータベースポリシが有効である。
【実施例３】
【０１３１】
実施例１と２では、全てのデータをセンサ情報処理サーバ群が保存する場合の動作を示した。実施例３では、一部のデータを共通データベースに保存する場合について説明する。
【０１３２】
図４には、本実施例で想定する通信ネットワークの物理的な構成を模式的に示す。
センサ情報配布元２、センサ情報処理サーバ３、SIPサーバ４、SIP UA５は、実施例１のものと同じである。
【０１３３】
共通データベース６は、データベースプログラムが動作するサーバ機器である。センサ情報処理サーバ３は、それぞれのデータベースミドルウェア３３７を通して、共通データベース６のデータベースプログラムが管理するデータにアクセスする。
【０１３４】
通信網１−１、センサ情報配布元２、センサ情報処理サーバ３、SIPサーバ４、共通データベースサーバ６は、互いに物理的な通信回線９を介して接続されている。また、通信網１−２、SIPサーバ４、SIP UA５は互いに物理的な通信回線９を介して接続されている。図４では、見やすさのために通信網１−１と１−２を分けているが、この両者は同じ通信網であってもよい。
また、センサ情報処理サーバ３の内部構造は、実施例１のもの（図５）と同じである。
【０１３５】
ただし、本実施例では、全てのセンサ情報処理サーバ３のデータベース/DHTミドルウェア３３３が、図２０に示すデータベースポリシを持っているものとする。このデータベースポリシの行５０１６は、データ属性が「ユーザID」のデータを含むデータ（すなわちセンサ情報）は、DHTを使って保存するというポリシを示している。行５０１７は、データ属性が「サーバ設定」のデータ（すなわちセンサIDデータ）は、ミラーリングで保存するというポリシを示している。また、行５０１８は、他のどのポリシにも該当しなかったデータは共通データベースに保存する、というデフォルトポリシを示している。
【０１３６】
本実施例では、全てのセンサ情報処理サーバ３のDHTミドルウェア３３５が持つルーティングテーブルにおいて、キー「sip:ando@example.com」に対応するノードはセンサ情報処理サーバ３−２であるとする。
【０１３７】
本実施例では、全てのセンサ情報処理サーバ３のデータベースプログラム３３７が、図１４のセンサIDデータテーブル１０００の値を保持しているものとする。また、センサ情報処理サーバ３−２のDHTミドルウェア３３５が、図１５のセンサ情報履歴２０００の値を保持しているものとする（他のセンサ情報処理サーバが保持している値は省略する）。そして、共通データベースサーバ６が、図１６のシナリオ設定テーブル３０００の値を保持しているものとする。
【０１３８】
図１１は、センサ情報配布元２が送信したセンサ情報を、適切なセンサ情報処理サーバ３が処理するまでの動作の一例を示したシーケンス図の一部である。この例でセンサ情報配布元２が送信するセンサ情報は、センサIDが「00006c0000090003」、基地局IDが「0003」であるものとする。
【０１３９】
S101からS129までの動作は実施例１とほぼ同じである。ただし、S103でセンサIDデータの保存方法が「ミラーリング」であると判断する流れが、実施例１と異なる。この流れを詳しく説明する。
【０１４０】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシを決定する。
まず、データベース/DHTミドルウェア３３３は、データへのアクセス要求から、対象データのデータ名を取得する（S501）。次に、データ名４００１が、S501で取得したデータ名に一致するデータ属性を、データ属性テーブル４０００から取得する（S502）。この場合、データ名は「センサIDデータ」なので、データベース/DHTミドルウェア３３３は行４０１３のデータ属性を取得する。
【０１４１】
データ属性が１つ以上あった場合、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S503、S504）。この例では、データベース/DHTミドルウェア３３３は行５０１６のデータベースポリシを取得する。
【０１４２】
データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、そのデータベースポリシと比較する（S505、S506）。この例では、行４０１３のデータ属性と、行５０１６のデータベースポリシは一致していない。そこで、データベースポリシテーブル５０００から次に優先度の高いデータベースポリシを取り出す（S507、S509）。この例では、行５０１７のデータベースポリシを取得する。
【０１４３】
そして、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、S509で取り出した１つのデータベースポリシと比較する（S505、S506）。この例では、行４０１３のデータ属性と、行５０１７のデータベースポリシは一致している。従って、センサ情報履歴に対しては行５０１７のデータベースポリシを適用する（S507、S508）。つまり、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「DHT」である、と判断する。この結果は、実施例１のS103と同じである。
【０１４４】
S103を除いたS101からS129までの動作は実施例１と同じであるため、ここでは省略する。
【０１４５】
センサ情報が変化すると、シナリオ部３３１２は設定情報を読み込んでアプリケーションを制御する。従って、シナリオ部３３１２は、基地局IDが「0003」のシナリオ設定３０００をデータベース/DHTミドルウェアに要求する（S301）。
【０１４６】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。
まず、データベース/DHTミドルウェア３３３は、データへのアクセス要求から、対象データのデータ名を取得する（S501）。次に、データ名４００１が、S501で取得したデータ名に一致するデータ属性を、データ属性テーブル４０００から取得する（S502）。この場合、データ名は「シナリオ設定」なので、データベース/DHTミドルウェア３３３は行４０１２のデータ属性を取得する。
【０１４７】
データ属性が１つ以上あった場合、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S503、S504）。この例では、データベース/DHTミドルウェア３３３は行５０１６のデータベースポリシを取得する。
【０１４８】
データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、そのデータベースポリシと比較する（S505、S506）。
【０１４９】
この例では、行４０１２のデータ属性と、行５０１６のデータベースポリシは一致していない。そこで、データベースポリシテーブル５０００から次に優先度の高いデータベースポリシを取り出す（S507、S509）。この例では、行５０１７のデータベースポリシを取得する。
【０１５０】
そして、データベース/DHTミドルウェア３３３は、S502で取り出した全てのデータ属性を、S509で取り出した１つのデータベースポリシと比較する（S505、S506）。この例では、行４０１２のデータ属性と、行５０１７のデータベースポリシは一致していない（S507）。この例では次に優先度の高いデータベースポリシが存在しないため、デフォルトポリシ５０１８を適用する（S509、S505、S510）。つまり、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「共通データベース」である、と判断する（S302）。このように、どのデータベースポリシにも該当しないデータは共通データベースに保存されるため、データベースポリシの設定漏れによるデータの欠損は無い。保存方法が「共通データベース」のデータは、共通データベースサーバ６に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３７に対して、共通データベースサーバ６へのアクセスを要求する（S303）。データベースミドルウェア３３７は、共通データベースサーバ６に対して、基地局IDが「0003」のシナリオ設定３０００を要求する（S304）。
【０１５１】
この要求を受信した共通データベースサーバ６は、そのサーバ内のデータベースプログラムが保存しているシナリオ設定３０００の行３０１３を結果として返す（S305）。センサ情報処理サーバ３−２のデータベースミドルウェア３３７は、この結果をデータベース/DHTミドルウェア３３３に返す（S306）。また、データベース/DHTミドルウェア３３３は、この結果をシナリオ部３３１２に返す（S307）。これにより、シナリオ部３３１２は、基地局ID「0003」に対応する位置が「会議室２」であると知ることができる。
【０１５２】
シナリオ部３３１２は、ユーザID「sip:ando@example.com」のユーザの位置を「会議室２」に更新することを、アプリケーション制御部３３１３に要求する（S308）。アプリケーション制御部３３１３は、SIPサーバ４に対して、プレゼンス情報を更新するための制御メッセージを送信する（S309）。
以上が、センサ情報処理の一連の流れである。
【０１５３】
図１２は、管理者がセンサ情報処理サーバ３−１のデータ管理プログラム３３２を利用して、シナリオ設定を更新する動作の一例を示したシーケンス図である。
まず、管理者がデータ管理プログラム３３２を利用してシナリオ設定を更新すると、データ管理プログラム３３２は、データベース/DHTミドルウェア３３３に対して、シナリオ設定の更新を要求する（S351）。この例では、シナリオ設定３０００の行３０１３の位置を、「会議室２」から「休憩室」に更新したものとする。
【０１５４】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。S302と同様に、データベース/DHTミドルウェア３３３は、シナリオ設定の保存方法は「共通データベース」である、と判断する（S352）。
【０１５５】
保存方法が「共通データベース」のデータは、共通データベースサーバ６のデータベースプログラムに保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３７に対して、共通データベースサーバ６へのアクセスを要求する（S353）。データベースミドルウェア３３７は、共通データベースサーバ６に対して、シナリオ設定の更新を要求する（S354）。
【０１５６】
この要求を受信した共通データベースサーバ６は、そのサーバ内のデータベースプログラムが保存しているシナリオ設定３０００の行３０１３を更新する。データの更新に成功すると、センサ情報処理サーバ３−２のデータベースミドルウェア３３７DHTミドルウェア３３５に対して、成功通知メッセージを送信する（S355）。
【０１５７】
センサ情報処理サーバ３−２のデータベースミドルウェア３３７は、この成功通知メッセージを受信すると、更新の成功をデータベース/DHTミドルウェア３３３に通知する（S356）。そして最後に、データベース/DHTミドルウェア３３３はシナリオ設定の更新成功をデータ管理プログラム３３２に通知する（S357）。
【０１５８】
また、上記のようにデータ管理プログラム３３２を用いなくても、従来のデータベース操作ソフトウェアを利用して共通データベースサーバ６に保存されているデータ（すなわちシナリオ設定）を操作することもできる。
【０１５９】
以上のようにして、管理者がデータベースポリシの内容を変更するだけで、センサ情報処理プログラムを変更することなく、実施例１とは異なるデータ管理方法へと切り替えることができる。
【０１６０】
実施例３では、実施例１〜２とは異なり、共通データベースを利用している。しかし、データベースポリシに基づき、センサ情報はDHTを利用してルーティングされる。従って、センサ情報処理は実施例１〜２と同様にサーバ間で自律分散される。また、頻繁に参照されるセンサIDデータは、ミラーリングによって各サーバ上に配置される。これにより、従来の方法と比べて、共通データベースがセンサ情報処理のボトルネックになりにくくなっている。
【０１６１】
また、実施例３ではシナリオ設定の保存先を共通データベースサーバに固定している。そのため、複数のセンサ情報処理サーバの間でデータを管理する実施例１〜２よりも、データの同期を取りやすい。従って、シナリオ設定の更新頻度が実施例２よりも高い、またはサーバの数が多い場合は、本実施例のデータベースポリシが有効である。
このように、DHT、ミラーリングと共通データベースを使い分けるデータベースポリシを設定することで、各データの特徴に合わせてデータベースを使い分けることが可能になる。
【実施例４】
【０１６２】
実施例１〜３では、センサ情報履歴はセンサ情報処理サーバ群に分散配置されていた。実施例４では、全てのデータを共通データベースに保存する場合について説明する。
【０１６３】
図２には、本実施例で想定する通信ネットワークの物理的な構成を模式的に示す。センサ情報配布元2、センサ情報処理サーバ３、SIPサーバ４、SIP UA５、共通データベース６は、実施例３と、センサ情報配布元２が、ロードバランサ７に対してセンサ情報を送信する点以外は同じである。ロードバランサ７は、通信回線９を通して受信したパケットを、ｎ台のセンサ情報処理サーバ３のいずれかに転送するサーバ機器である。ロードバランサ７はｎ台のセンサ情報処理サーバ３の負荷を監視しており、負荷の少ないセンサ情報処理サーバへパケットを転送する。
【０１６４】
通信網１−１、センサ情報配布元２、センサ情報処理サーバ３、SIPサーバ４、共通データベースサーバ６、ロードバランサ７は、互いに物理的な通信回線９を介して接続されている。また、通信網１−２、SIPサーバ４、SIP UA５は互いに物理的な通信回線９を介して接続されている。図２では、見やすさのために通信網１−１と１−２を分けているが、この両者は同じ通信網であってもよい。
また、センサ情報処理サーバ３の内部構造は、実施例１のもの（図５）と同じである。
【０１６５】
ただし、本実施例では、全てのセンサ情報処理サーバ３のデータベース/DHTミドルウェア３３３が、図２１に示すデータベースポリシを持っているものとする。このデータベースポリシには、デフォルトポリシ５０１９しか含まれていない。つまり、全てのデータを共通データベースに保存することを示している。
【０１６６】
本実施例では、共通データベースサーバ６が、図１４のセンサIDデータテーブル１０００の値、図１５のセンサ情報履歴テーブル２０００の値、および図１６のシナリオ設定テーブルの値を保持しているものとする。
【０１６７】
図１３は、センサ情報配布元２が送信したセンサ情報を、センサ情報処理サーバ３が処理するまでの動作の一例を示したシーケンス図である。この例でセンサ情報配布元２が送信するセンサ情報は、センサIDが「00006c0000090003」、基地局IDが「0003」であるものとする。
【０１６８】
まず、センサ情報配布元２は、ロードバランサ７に対してセンサ情報を送信する（S401）。ロードバランサ７はサーバ負荷を考慮して、このセンサ情報をいずれかのセンサ情報処理サーバ３に転送する（S402）。この例では、センサ情報処理サーバ３−１のセンサID解決部３３１１に転送したものとする。
【０１６９】
センサID解決部３３１１は、データベース/DHTミドルウェア３３３に対して、センサIDが「00006c0000090003」のセンサIDデータ１０００を要求する（S403）。
【０１７０】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシを決定する。本実施例ではデフォルトポリシしか存在しないため、センサIDデータの保存方法は「共通データベース」である、と判断する（S404）。
【０１７１】
保存方法が「共通データベース」のデータは、共通データベースサーバ６に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３７に対して、共通データベースサーバ６へのアクセスを要求する。データベースミドルウェア３３７は、共通データベースサーバ６に対して、基地局IDが「0003」のシナリオ設定３０００を要求し、シナリオ設定３０００の行３０１３が返される（S405〜S408）。そして、データベース/DHTミドルウェア３３３は、この結果をセンサID解決部３３１１に返す（S409）。これにより、センサID解決部３３１１は、センサID「00006c0000090003」に対応するユーザIDが「sip:ando@example.com」であると知ることができる。センサID解決部３３１１は、このユーザIDをセンサ情報の中に挿入する（S410）。
【０１７２】
次に、センサID解決部３３１１は、データベース/DHTミドルウェア３３３に対して、センサ情報を含むメッセージの送信を要求する（S411）。このとき、メッセージの送信に使うキーとしてS409で取得したユーザID（すなわち「sip:ando@example.com」）を指定し、データ属性として「ユーザID」を指定する。
【０１７３】
データベース/DHTミドルウェア３３３は、メッセージの送信を要求されると、図２４のフローチャートに従ってそのメッセージの送信先を決定する。まず、データベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、最も優先度の高いデータベースポリシを取り出す（S610）。この例では、データベース/DHTミドルウェア３３３は行５０１９のデータベースポリシを取得する。データベースポリシを取得できた場合、データベース/DHTミドルウェア３３３は、そのデータベースポリシの保存方法が「DHT」かどうかを調べる（S603）。この例では、行５０１９の保存方法は「DHT」でない。従ってデータベース/DHTミドルウェア３３３は、データベースポリシテーブル５０００から、次に優先度の高いデータベースポリシを取り出す（S606）。しかし、データベースポリシは１つしか存在しないため、データベース/DHTミドルウェア３３３はメッセージの送信先は「メッセージハンドラ」である、と判断する（S602、S607）。
【０１７４】
データベース/DHTミドルウェア３３３は、センサ情報を含むメッセージをメッセージハンドラに渡す。前述の通り、シナリオ部３３１２は事前にメッセージハンドラを登録しているので、シナリオ部３３１２はメッセージハンドラを通して、このセンサ情報を含むメッセージを受信する（S413）。
【０１７５】
センサ情報を受信すると、シナリオ部３３１２は、そのセンサ情報に含まれるユーザのセンサ情報履歴をデータベース/DHTミドルウェア３３３に要求する（S414）。つまり、ユーザIDが「sip:ando@example.com」のセンサ情報履歴を要求する。
【０１７６】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。本実施例ではデフォルトポリシしか存在しないため、センサ情報履歴の保存方法は「共通データベース」である、と判断する（S415）。
【０１７７】
保存方法が「共通データベース」のデータは、共通データベースサーバ６に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３７に対して、共通データベースサーバ６へのアクセスを要求する。データベースミドルウェア３３７は、共通データベースサーバ６に対して、ユーザIDが「sip:ando@example.com」のセンサ情報履歴２０００を要求し、センサ情報履歴２０００の行２０１１が返される（S416〜S419）。そして、データベース/DHTミドルウェア３３３は、この結果をシナリオ部３３１２に返す（S420）。これにより、シナリオ部３３１２は、このユーザの基地局IDが「0001」から「0003」に変化したことを知ることができる。
【０１７８】
センサ情報が変化すると、シナリオ部３３１２は、その新しいセンサ情報をデータベースプログラムまたはDHTミドルウェアに保存する。そのために、シナリオ部３３１２は、データベース/DHTミドルウェアにセンサ情報履歴の更新を要求する（S421）。
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。S422と同様に、データベース/DHTミドルウェア３３３は、センサ情報履歴の保存方法は「共通データベース」である、と判断する（S422）。
【０１７９】
保存方法が「共通データベース」のデータは、共通データベースサーバ６に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３７に対して、共通データベースサーバ６へのアクセスを要求する。データベースミドルウェア３３７は、共通データベースサーバ６に対して、ユーザIDが「sip:ando@example.com」のセンサ情報履歴２０００の更新を要求する（S423〜S426）。更新に成功すると、データベース/DHTミドルウェア３３３は、更新の成功をシナリオ部３３１２に通知する（S427）。これにより、シナリオ部３３１２は、センサ情報履歴の更新に成功したことを知ることができる。
【０１８０】
センサ情報が変化すると、シナリオ部３３１２は設定情報を読み込んでアプリケーションを制御する。本実施例では、センサ情報に含まれる基地局IDに応じて、そのユーザの位置を表すプレゼンス情報を更新する。各基地局IDに対応する位置は、データベースプログラムまたはDHTミドルウェアから取得する。
【０１８１】
シナリオ部３３１２は、基地局IDが「0003」のシナリオ設定３０００をデータベース/DHTミドルウェアに要求する（S428）。
【０１８２】
データベース/DHTミドルウェア３３３は、データへのアクセスを要求されると、図２３のフローチャートに従ってそのデータに適用するデータベースポリシ（すなわちデータの保存方法）を決定する。本実施例ではデフォルトポリシしか存在しないため、シナリオ設定の保存方法は「共通データベース」である、と判断する（S429）。
【０１８３】
保存方法が「共通データベース」のデータは、共通データベースサーバ６に保存されている。そのため、データベース/DHTミドルウェア３３３は、データベースミドルウェア３３７に対して、共通データベースサーバ６へのアクセスを要求する。データベースミドルウェア３３７は、共通データベースサーバ６に対して、基地局IDが「0003」のシナリオ設定３０００を要求するを要求し、シナリオ設定３０００の行３０１３が返される（S430〜S433）。そして、データベース/DHTミドルウェア３３３は、この結果をシナリオ部３３１２に返す（S434）。これにより、シナリオ部３３１２は、基地局ID「0003」に対応する位置が「会議室２」であると知ることができる。
【０１８４】
シナリオ部３３１２は、ユーザID「sip:ando@example.com」のユーザの位置を「会議室２」に更新することを、アプリケーション制御部３３１３に要求する（S435）。アプリケーション制御部３３１３は、SIPサーバ４に対して、プレゼンス情報を更新するための制御メッセージを送信する（S436）。
以上が、センサ情報処理の一連の流れである。
【０１８５】
図１２は、管理者がセンサ情報処理サーバ３−１のデータ管理プログラム３３２を利用して、シナリオ設定を更新する動作の一例を示したシーケンス図である。シナリオ設定の更新は、実施例３で示した例と全く同様に行うことができる。
【０１８６】
以上のようにして、管理者がデータベースポリシの内容を変更するだけで、センサ情報処理プログラムを変更することなく、実施例１とは異なるデータ管理方法へと切り替えることができる。特に本実施例は、データベースポリシの内容を変更するだけで、従来の負荷分散方式もサポートできることを示している。
【０１８７】
実施例４の構成は、全てのデータを共通データベースで管理している。そのため、処理速度は実施例１〜３に劣るが、データが一カ所に集中しているため、センサ情報履歴の再利用を行いやすくなっている。
【０１８８】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。
【図面の簡単な説明】
【０１８９】
【図１】センサ情報処理システムの物理的な構成を示す図である。
【図２】実施例４で想定するネットワークの物理的な構成を示す図である。
【図３】実施例１および実施例２で想定するネットワークの物理的な構成を示す図である。
【図４】実施例３で想定するネットワークの物理的な構成を示す図である。
【図５】センサ情報処理サーバの物理的な構成を示す図である。
【図６】実施例１のセンサ情報受信時のシーケンス図である。
【図７】実施例１のセンサ情報受信時のシーケンス図である。
【図８】実施例１のシナリオ設定更新時のシーケンス図である。
【図９】実施例２のセンサ情報受信時のシーケンス図である。
【図１０】実施例２のシナリオ設定更新時のシーケンス図である。
【図１１】実施例３のセンサ情報受信時のシーケンス図である。
【図１２】実施例３のシナリオ設定更新時のシーケンス図である。
【図１３】実施例４のセンサ情報受信時のシーケンス図である。
【図１４】センサIDデータの例を示す図である。
【図１５】センサ情報履歴の例を示す図である。
【図１６】シナリオ設定の例を示す図である。
【図１７】データ属性の例を示す図である。
【図１８】実施例１のデータベースポリシを示す図である。
【図１９】実施例２のデータベースポリシを示す図である。
【図２０】実施例３のデータベースポリシを示す図である。
【図２１】実施例４のデータベースポリシを示す図である。
【図２２】センサ情報の例を示す図である。
【図２３】あるデータに適用するデータベースポリシを決定する処理のフローチャートである。
【図２４】メッセージの送信先を決定する処理のフローチャートである。
【図２５】ユーザIDを含むセンサ情報の例を示す図である。
【符号の説明】
【０１９０】
１  通信網
２  センサ情報配布元
３  センサ情報処理サーバ
４  SIPサーバ
５  SIP UA
６  共通データベースサーバ
７  ロードバランサ
９  通信回線
３１  ＩＦ
３２  ＣＰＵ
３３  メモリ
３４  データパス
３３１  センサ情報処理プログラム
３３１１  センサID解決部
３３１２  シナリオ部
３３１３  アプリケーション制御部
３３２  データ管理プログラム
３３３  データベース/DHTミドルウェア
３３４  データベースミドルウェア
３３５  DHTミドルウェア
３３６  ミラーリングプログラム
３３７  データベースプログラム
１０００  センサIDデータテーブル
２０００  センサ情報履歴テーブル
３０００  シナリオ設定テーブル
４０００  データ属性テーブル
５０００  データベースポリシテーブル。
【図１】
2008146119.tif 000003
【図２】
2008146119.tif 000004
【図３】
2008146119.tif 000005
【図４】
2008146119.tif 000006
【図５】
2008146119.tif 000007
【図６】
2008146119.tif 000008
【図７】
2008146119.tif 000009
【図８】
2008146119.tif 000010
【図９】
2008146119.tif 000011
【図１０】
2008146119.tif 000012
【図１１】
2008146119.tif 000013
【図１２】
2008146119.tif 000014
【図１３】
2008146119.tif 000015
【図１４】
2008146119.tif 000016
【図１５】
2008146119.tif 000017
【図１６】
2008146119.tif 000018
【図１７】
2008146119.tif 000019
【図１８】
2008146119.tif 000020
【図１９】
2008146119.tif 000021
【図２０】
2008146119.tif 000022
【図２１】
2008146119.tif 000023
【図２２】
2008146119.tif 000024
【図２３】
2008146119.tif 000025
【図２４】
2008146119.tif 000026
【図２５】
2008146119.tif 000027