JP2005085244A - 情報処理装置ならびにその名前空間構成装置および方法 - Google Patents

Abstract

【課題】 センサ情報の管理とアプリケーションとを独立に構成しつつ、必要時に相互の計算機リソースにアクセスできるようにする。
【解決手段】 アプリケーションサービス１１０は、実行時に名前空間自動構成サービス１０に対して、センサ割当要求を発行する。センサ割当要求には「アプリケーション側の名前サービスＩＤ」と「センサ側の名前サービスＩＤの集合」と左記センサ側の名前サービスＩＤのそれぞれに対応する「センサ群の名前の集合」とを含む。名前空間自動構成サービス１０はアプリケーションサービスの要求にしたがって関連する名前管理サービス１００，３００対して自動的に設定を行う。アプリケーションの名前管理サービス１００はセンサ群を名前空間に配置し、センサグループの名前管理サービス３００はアプリケーションの状態を名前空間に配置する。
【選択図】 図３

Description

本発明は、センサ情報に基づいたアプリケーションを構築するための分散処理技術に関する。

センサから得られる情報を利用するアプリケーションを構築する際に、センサとアプリケーションの詳細が予め分かっている場合には、センサとアプリケーションを密結合し、センサの仕様やアプリケーションの要件に最適化されたシステム設計を行うことができる。

しかしながら、パイロット・プロジェクトやプロトタイピングの局面でしばしば見られる、上記のような安定した条件が無い場合や、システム要件そのものとして新規センサや新規アプリケーションの導入を容易に行える（センサ・デバイスやアプリケーション・ソフトウェアの“プラグ・アンド・プレイ”が可能な）柔軟性を備えねばならない場合には、センサの仕様やアプリケーションの要件を予め想定しずらい。このような条件下では、センサとアプリケーションの両者を互いに独立にしつつ、実行時に両者が互いに調整できる程度の疎結合を達成する戦略が有効なシステム構築方法である。

センサ情報を提供するサービスは、ビデオストリーミングや音声通話のように連続的に使用されるものではない。センサ情報を提供するサービスの機能として、アプリケーションが問い合わせを行った時点でのセンサ情報を返したり、センサ情報が特定の条件を満たしたときにアプリケーション側に通知を上げる程度の間欠的な相互作用で十分であり、アプリケーション側とセンサ側が疎結合状態でもシステムとして十分に機能することができる。

センサ情報を利用するアプリケーションを構築する上で、センサ情報の管理とアプリケーションとを独立に構成しつつ、必要時に相互の計算機リソースにアクセスできるようにすることが望まれる。

なお、本発明と関連する先行技術としては下記の特許文献１〜４がある。

特許文献１（「ワイヤレスネットワーク内の移動コンピュータに対する処理継続性を維持する方法と装置」）に係る発明では、移動装置が物理的境界を超えても、当該移動装置と通信を行っている固定計算機上の計算処理を継続させるための基本的な機構を提供しており、ユーザの物理的な行動を電子的な領域で持続的に捕捉しつづけることができる。本発明では、移動装置と固定計算機上の計算処理を予め１対１対応させており、センサ側とアプリケーション側を疎結合するものではない。

特許文献２（「インフラストラクチュア」）に係る発明では、特許文献１に係る発明におけるユーザ情報を機密保護モデルをもとに制御することができる。この発明では、左記制御を実現するための機構として、機密保護ポリシーを実行するユーザエージェントを位置質問サービスに実行時に組合せを行っている。しかしながら、その組合せ状況はユーザエージェントや位置質問サービス自身が管理しており、センサ側とアプリケーション側が疎結合にならない。

特許文献３（「ネットワークシステム、デバイス、デバイス情報登録方法および記録媒体」）に係る発明では、デバイス情報をディレクトリサーバに登録することでアプリケーションからデバイス情報を利用可能にするが、登録の際にデバイス情報の更新頻度も合わせてディレクトリサーバに登録し、その更新頻度に応じて登録処理を分散的に行う機構を提供する。この発明においては、変化するデバイス情報を効率良くディレクトリサーバに集中させることを目的としており、アプリケーション側とデバイス側を疎結合にして相互に利用可能にするものではない。

特許文献４（「ネットワーク端末装置及びネットワークシステム」）に係る発明では、マルチメディアサービスを提供するコンポーネントをディレクトリサーバに登録しておき、アプリケーション実行時に登録されたコンポーネント間をＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）交渉を行って結合する機構を提供している。本発明では、映像のストリーミングなどのように長時間連続的に利用されるコンポーネントを対象にしているため、コンポーネントの構成変更時には、それを利用している端末に通知を行う機構を備えており、実行時のコンポーネントは密結合になっている。

特開平７−１２１４５８号公報 特開平７−２００４４７号公報 特開２００１−９２７５８公報 特開２００２−９９４７１公報

この発明は、以上の事情を考慮してなされたものであり、センサ情報を利用するアプリケーションを構築する上で、センサ情報の管理とアプリケーションとを独立に構成しつつ、必要時に相互の計算機リソースにアクセスできるようにするために、センサ情報の情報管理サービスとこれを利用するアプリケーションとの間を疎結合させることを目的としている。

この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。

この発明の原理的な構成例によれば、センサから得られる情報を利用するアプリケーションを構築する際には、アプリケーション側とセンサ側を積極的に疎結合で結合する。それを達成する手段として、アプリケーション側とセンサ側の提供する状態群を、それぞれに対応する名前管理サービスで管理しておき、実行時に左記複数の名前管理サービス間で後に実施例を参照して述べるような相互の参照関係を確立する設定代行手段を設ける。

本発明によって、アプリケーションとセンサ間で相互に情報を共有可能にしつつアプリケーション間を相互に隔離可能な、複数アプリケーションと複数センサ間の多対多の疎結合をもたらす名前空間を自動構成できる。

また、このような構成を行うことで、アプリケーション側とセンサ側のそれぞれの変更から、互いを独立にすることができるようになる。これにより、センサデバイスの同質性を生かして、実行中にセンサデバイスを増やしたり減らしたりしてセンサの物理的な特性を調整してもシステム全体の動作には影響しない。

さらに、センサ側からアプリケーション側の状態情報に到達可能になることから、アプリケーション側の状態に応じたセンサ群の適応制御が可能になる。

さらにこの発明を説明する。

すなわち、この発明の一側面によれば、上述の目的を達成するために、情報処理装置に：センサと；上記センサの管理サービスを実行するセンサ管理手段と；上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と；アプリケーションサービスを実行するアプリケーション実行手段と；上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段とを設け；上記アプリケーションサービスからの要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースを上記第２の名前空間管理手段の名前空間に位置づけるようにしている。

さらに、上記アプリケーションサービスからの要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づけるようにしてもよい。

センサは、物理的な状態や事象を検出する装置であり、例えば、温度等の物理量や、人、物等の存在・移動等の事象の判別、事象の回数の判別等を行なうものであるが、これに限定されない。

この構成においては、要求に基づいてセンサ（センサ情報）やアプリケーションサービスの機器（機器情報）を名前空間上に位置づけるので、柔軟にセンサ利用アプリケーション環境を構築できる。

なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品もこの発明の技術的な範囲に含まれることも当然である。

この発明の上述の側面および他の側面は特許請求の範囲に記載され以下実施例を用いて詳述される。

この発明によれば、センサや機器を適合的に名前空間に位置づけることにより柔軟にセンサ利用アプリケーション環境を構築できる。

以下、この発明の実施例について説明する。

［装置構成］

図１は本発明の実施における論理的な装置構成図である。図１において、システムは大別して４つのサブシステムに分かれている。各サブシステムは、アプリケーションサービス（サーバ装置で実行されるサービス。ここではサーバ装置とサービスとは同じ意味である）とそのクライアント（クライアント装置）の対が２系統（アプリケーションサービス１１０，クライアント１２０の系統およびアプリケーションサービス２１０，クライアント２２０の系統）と、センサ群が２系統（センサ管理サービス３１０，３２０，．．．の系統およびセンサ管理サービス４１０，４２０，．．．の系統）である。さらに、それら各サブシステムにはそれぞれ１つの名前管理サービス（１００，２００，３００，４００）が対応している。上記４つのサブシステムは互いに独立している。上記４つのサブシステムはネットワーク１０００を介して分散配置されている。

なお、クライアントは、典型的にはパーソナルコンピュータであるが、これに限定されず、種々の情報機器とすることができる。

本実施例では、汎システム的に一意な識別子、例えば、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）やＧＵＩＤ（Ｇｌｏｂａｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）を用いて、各サービスやオブジェクトはＩＤにより指定することができ、サービスＩＤやオブジェクトＩＤを指定することにより通信インフラストラクチャーが対象サービスや対象オブジェクトとの適切な通信路を割り当ててくれるものとする。

通信インフラストラクチャは例えばサービス・レジストリを用意し、これにサービスの所在を登録し照会することで相手サービスへの参照を取得する方法や、ネットワークに同報通信を行うことで相手サービスへの通知を行う方法を利用することができる。

アプリケーションサービスは、クライアント１２０，２２０に埋め込まれた「タグ」１２２，２２２を「センサ」３１１，３１２，３２１，３２２，４１１，４１２，４２１，４２２に検出させて、その情報をもとにクライアント１２０，２２０に対してサービスを提供する。そうしたサービスの典型的な例として、建物の中の各部屋にセンサを配置し、その部屋に入ったユーザが持っているクライアントに埋め込まれたタグを識別することで、ユーザの動態を把握し、ユーザの居る場所に応じた適切な情報提供を行うといったサービスを挙げることができる。

なお、アプリケーションサービス１１０，２１０、クライアント１２０，２２０はそれぞれ状態１１１，２１１，１２１，２２１を保持している。

各サブシステムは上述のとおり独立しているが、名前空間自動構成サービス１０により名前空間に関連して疎結合される。これについては以下詳述する。

［名前空間の部分結合によるサブシステム間疎結合］

本発明は上記のような互いに独立したアプリケーション群とセンサ群の間の実行時疎結合を達成することが目的である。この実施例においては、その具体的な方法として、各名前管理サービス上の名前空間に対してアプリケーション側とセンサ側のそれぞれのオブジェクトへの到達性を実行時に自動設定する機構（名前空間自動構成サービス）を導入することで、互いに実行時に必要なオブジェクトへの到達性を確保する。そのようにして実行時に到達可能になるオブジェクト間のパラメータ調整は、アプリケーション側とセンサ側の両者の責任において行う。

図２は上記の機構が設定する名前空間の概要である。各サブシステム毎に名前空間が存在する。名前空間はネーミングコンテキスト（Ｃ１０，Ｃ１１，．．．）をノードとし名前を辺とする、ルートネーミングコンテキスト（Ｃ１０，Ｃ２０，Ｃ３０，．．．）を始点とする有向グラフを構成し、グラフの端点にさまざまなオブジェクトへの参照を持つ。

図２においては、センサグループＡの管理するセンサのうち「２Ｆ」「５Ｆ」の名前で表されるセンサ群を統括するネーミングコンテキスト（Ｃ３２，Ｃ３３）がアプリケーション１が参照したいセンサ群を統括するネーミングコンテキスト（Ｃ１４，Ｃ１５）に対応付けられる。アプリケーション１に関わる各機器の持つ内部状態を統括するネーミングコンテキスト（Ｃ１３）は、センサグループＡが参照したい内部状態を統括するネーミングコンテキスト（Ｃ３１）に対応付けられる。同様にして、アプリケーション２とも対応付けられる。この図には図示していないが、もちろん、両アプリケーションとも、もう一系統のセンサ群であるセンサグループＢと同様の対応関係をとることができる。

本実施例で重要なポイントは、アプリケーションとセンサ群を多対多の関係で対応付けても、なおもアプリケーション同士は互いに独立にできる構成を行うことである。センサグループはアプリケーション側の状態情報に到達できるが（Ｃ３１からＣ１３，Ｃ２３は解決できる）、アプリケーション側では同一センサグループを共有している他のアプリケーションの状態情報に到達できない（Ｃ１３とＣ２３は互いに解決できない）。アプリケーションはユーザの動態を把握しているため、その状態を開示することはユーザのプライバシーの侵害につながる恐れがあるが、本実施例では、その開示範囲をセンサ側に対してのみに限定することが可能である。

ここで、若干、名前空間について説明を補充する。

名前空間は大別してネーミングコンテキストおよびリソースという２種類のオブジェクトから構成される。

ネーミングコンテキストは、複数のオブジェクトをとりまとめ、各々のオブジェクトに名前を付ける。ネーミングコンテキストは、「ファイルフォルダ」や「ファイルディレクトリ」の一般的化であり、関連するリソースをひとまとめにする上で有効な情報整理の単位を提供する。ネーミングコンテキストは再帰的に組合せ可能であり、ネーミングコンテキストに沿って、階層的な名前を構成することができる。

リソースは電子文書やアプリケーションプログラムの実行状態といった、計算機上の具体的なリソースを表現する。

以下では、ネーミングコンテキストとリソースから構成されるグラフを名前空間と言う。

なお、計算機リソースは、例えば、外部記憶装置（ハードディスク、ＣＤ−ＲＯＭ、．．．）に格納された電子ファイルや実行中の計算プロセスおよびオペレーティングシステムである。実行中のプロセスは、例えばアプリケーションプログラム、各種センサ情報を取得するプログラム／オペレーティングシステム、各種外部機器を制御するプログラム／オペレーティングシステムである。

計算機リソースは、大別して外部記憶装置上に格納されている不揮発性のオブジェクトと、主記憶上にあり計算に沿って変化する揮発性のオブジェクトの２種類である。前者の代表例が通常の電子ファイルである。後者は様々なものが考えられるが、オペレーティングシステムのもとで実行される特定の計算プロセスか、オペレーティングシステム自身かに分類することができる。アプリケーションプログラムは特定の計算プロセスであるが、計算機につながっているセンサ情報や外部機器については計算プロセスが責任を持つ場合か、オペレーティングシステムが責任を持つ場合か、あるいはその両方がある。例えば、オペレーティングシステムが責任を持つ場合には、オペレーティングシステムに対して特定のシステムコールを発行すると、センサの情報が返ってきたり、周辺機器の状態を変えることになる。計算プロセスが責任を持つ場合には、特定のサービスプログラム、ドライバプログラムなどが同様の機能をオペレーティングシステムを代行して提供することになる。

［名前空間自動構成サービス］

図３は名前空間自動構成サービスと他のサブシステムとの相互作用を表す。アプリケーションサービスは、実行時に名前空間自動構成サービスに対して、センサ割当要求を発行すると、名前空間自動構成サービスはアプリケーションの要求にしたがって関連する名前管理サービス対して自動的に設定を行う。センサ割当要求には「アプリケーション側の名前サービスＩＤ」と「センサ側の名前サービスＩＤの集合」と左記センサ側の名前サービスＩＤのそれぞれに対応する「センサ群の名前の集合」とを含む。

図４は名前空間自動構成サービスが実行する処理である。この処理におけるポイントはステップＳ１４、ステップＳ１５およびステップＳ１８である。ステップＳ１４，Ｓ１５において、図２に示した名前空間の構成が各名前管理サービス毎に達成され、ステップＳ１８においてシステム全体として確定する。ただし、本実施例では名前空間をユニフォームな構成にしているため、ステップＳ１４，Ｓ１５における、ネーミングコンテキストの相互設定参照可能化設定は、固定された名前を対象としている。もちろん、センサ割当要求を拡張し、任意の名前を対象にしても構わない。

図４の名前空間自動構成サービスの処理は以下のとおりである。

［ステップＳ１０］：センサ割当要求ｒを取得する。
［ステップＳ１１］：センサ割当要求ｒからアプリケーション側の名前サービスＩＤ＝ａｉｄを取得する。
［ステップＳ１２］：センサ割当要求ｒに未処理のセンサ側名前サービスＩＤがあるかどうか判別する。あればステップＳ１３へ進み、なければ、ステップＳ１６へ進む。
［ステップＳ１３］：センサ割当要求ｒから未処理のセンサ側の名前サービスＩＤ＝ｓｉｄと対応するセンサ群の名前の集合＝ｓｎａｍｅｓを取得する。
［ステップＳ１４］：サービスＩＤ＝ａｉｄに対応する名前サービスの所定の名前（ｓｅｎｓｏｒ）に対して、サービスＩＤ＝ｓｉｄに対応する名前サービスにおけるｓｎａｍｅｓの各名前が指すネーミングコンテキストを照会可能に設定する名前空間設定要求を発行する。
［ステップＳ１５］：サービスＩＤ＝ｓｉｄに対応する名前サービスの所定の名前（ｓｔａｔｕｓ）に対して、サービスＩＤ＝ａｉｄに対応する名前サービスにおける所定の名前（ｓｅｎｓｏｒ／ｓｔａｔｕｓ）が指すネーミングコンテキストを照会可能に設定する名前空間設定要求を発行する。
［ステップＳ１６］：全ての名前空間設定確認応答が一定時間の間に揃い、それらがすべて設定準備完了を示したかどうかを判別する。すべて設定準備完了を示した場合にはステップＳ１７へ進み、そうでなければステップＳ１９へ進む。
［ステップＳ１７］：センサ割当応答を返す。
［ステップＳ１８］：名前空間設定確認応答を返した全ての名前サービスに対して、名前空間設定完了通知を発行する。リターンする。
［ステップＳ１９］：センサ割当失敗応答を返す。リターンする。

なお、本実施例では、名前空間自動構成サービス１０を用いてアプリケーションのサブシステムとセンサグループのサブシステムとの間を疎結合したが、各名前サービスがそのリソースを共有リソースとして持ち寄り、管理するようにしても良い。すなわち、名前管理サービス間でネーミングコンテキストを相互に接続し、接続されたネーミングコンテキストを経由して互いの部分名前空間を相互に解決可能に設定するための特別な設定プロトコルを定義してもよい。これについては本実施例の変形例としてのちに説明する。名前管理サービスとして、左記プロトコルを実装した名前管理サービスを利用する場合には、ステップＳ１８は不要である。

［アプリケーションとセンサの相互作用］

図５および図６は本発明によって可能となるアプリケーションとセンサの相互作用を表す。

図５はアプリケーション側からセンサ側の状態を照会する（センサに検出されているタグＩＤを問い合わせるなど）ときの手順である。センサ情報を管理しているセンサ管理サービスの実体は、実行時に名前管理サービスを経由して名前で取得することが可能となる。これによって、センサの追加・削除などのサブシステムの変更があった際も、センサ側の運用管理者ないしはセンサ管理サービス自身が、センサ側の名前管理サービスにその変更を反映させるだけでシステム全体が構成変更に対応できるようになる。

図６は、図５と逆に、センサ側からアプリケーション側の状態を照会するときの手順である。上記の議論と同様に、アプリケーションに関連する状態は、実行時に名前管理サービスを経由して名前で取得することが可能となる。これによって、新しいクライアントがオンラインになったり既存クライアントがオフラインになった際も、アプリケーションサービスがアプリケーション側の名前管理サービスにその変更を反映させるだけでシステム全体が構成変更に対応できるようになる。

以上のように、本実施例の構成によって、アプリケーション側とセンサ側のそれぞれの変更から、互いを独立にすることができる。

［センサ群の適応制御］

本実施例においては、センサ側からアプリケーション側の状態情報に到達可能になることから、アプリケーション側の状態に応じたセンサ群の適応制御が可能になる。図７および図８は本実施例におけるアプリケーション側の状態情報の一部である。各センサ管理サービスは、それぞれの都合に応じたタイミング・範囲でアプリケーション側の状態情報を参照して良く、アプリケーション側はその詳細を意識しなくて良い。アプリケーション側からセンサ側に明示的に要求値を示しても良いが、センサ側がそれを充足するかどうかは、アプリケーション側とセンサ側との間の契約条件に依存する個別問題であり、本発明の実施の形態では説明しない。したがって、ここでは、アプリケーション側の状態情報は、センサ群に対する「ヒント情報」として機能する。

本実施例おいて、センサ管理サービスは以下のような適応制御を行う。

（１） 非稼働アプリケーションに対するサービスの自動停止

センサ管理サービスは一定間隔でアプリケーションサービスの「ディスプレイ動作」をポーリングする。この値が連続して規定回数以上「ＯＦＦ」であった場合に、アプリケーションサービスがサービス停止状態であると見なす。

センサ管理サービスを利用している全てのアプリケーションサービスが停止状態になったら、センサ管理サービスはセンサ情報の収集を停止し、装置の駆動電力を削減する。

（２） 検出遅延の自動調整

センサ管理サービスは一定間隔でアプリケーションサービスの「検出遅延要求値」をポーリングする。センサ管理サービスは、センサ管理サービスを利用している全てのアプリケーションサービスのうち最も小さい要求値に適合した間隔でセンサ情報の収集を行うように自動設定する。

（３） センサ情報収集感度の自動調整

センサ管理サービスは一定間隔で全クライアントの「タグ駆動レベル」をポーリングする。センサ管理サービスは、それら駆動レベルの平均値を求め、タグ検出のためのスキャン出力レベルをそれに応じて自動設定する（平均が低レベルの範囲ならば高レベルでスキャンし、平均が中レベルならば中レベルでスキャンし、平均が高レベルならば低レベルでスキャンする）。

（４） センサ収容容量の自動調整

センサ管理サービスは一定間隔で全クライアントの「最新応答センサＩＤ」「最新応答時刻」をポーリングする。センサ管理サービスは、特定センサに対して一定の閾値以内の時間に一定の閾値以上の数のクライアントが集中しているのを発見した場合に、当該センサが検出可能なタグの上限値を引き上げ、時間とクライアント数の閾値を変更する。クライアントが減ったセンサについては、逆の処理を行う。

なお、この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。例えば、上述の例では、名前空間自動構成サービス１０が名前空間を自動構成するようにしたが、サブシステムの名前管理サービスが名前空間自動構成サービス１０と同等の機能を実行しても良い。

例えば、図９に示すように各名前管理サービスがネーミングコンテクスト・テーブルを用いて計算機リソースを管理し、その上で図１０に示すようなネーミングコンテキスト共有化テーブルを用いて自らが管理する計算機リソースを持ち寄ってサブシステムの名前空間の疎結合を行なっても良い。

すなわち、名前管理サービスは、ネーミングコンテキスト・オブジェクトを管理し、さらに、ネーミングコンテキストのグラフ情報を管理することで名前空間を管理する。名前管理サービスは、図９のデータ構造体（ネーミングコンテキスト・テーブル）等を管理する。

図９はネーミングコンテキストのグラフを管理するために用いられる。個々のネーミングコンテキストはオブジェクトＩＤにより識別される。オブジェクトＩＤは汎システム的に一意な識別子であり、本実施の形態ではサービスがオブジェクトを生成する際に割り付けるオブジェクトの通し番号と、そのサービスのサービスＩＤとを組み合わせて構成する。

ネーミングコンテキストは、名前リストとアクセス制御リストを要素として持つ。名前リストは、そのネーミングコンテキストがまとめているネーミングコンテキストやリソースと名前とを関連付ける。

名前リストにおいて、ネーミングコンテキストやリソースは、各々のオブジェクトを管理しているサービスのサービスＩＤとオブジェクト自身のオブジェクトＩＤの組みにより表される。アクセス制御リストは、そのネーミングコンテキストに対して行える操作を操作主体毎に指定する。本実施の形態では、説明の簡便さのため以下では、アクセス制御リストに現われない操作主体も含めた任意の操作主体に対してネーミングコンテキストの照会操作のみが許可され、アクセス制御リストに現われる操作主体には、あらゆる操作が可能であるという、暗黙の設定が成されているものとする。

名前管理サービスは、ネーミングコンテキスト・テーブルを参照して名前が指し示すオブジェクトを照会することができる。すなわち、階層的に構成された名前について、名前の階層の最上部から順に、照会開始点を基点にして対応するオブジェクトを取得しつつ階層を下がってゆく。階層の末端部であることを表す名前（原始名）に到達した時点でオブジェクトへの対応関係が存在すれば、そのオブジェクトへの参照を返す。

名前管理サービスの名前空間合成処理は、複数の名前管理サービス間で名前合成を行う。名前空間合成サービスは、図１０のデータ構造体（ネーミングコンテキスト共有化テーブル）を管理する。図１０はオブジェクトＩＤで表されるネーミングコンテキストについて、それと互いに共有状態にある他のネーミングコンテキストを共有リストとして表す。共有リストにおいて、共有状態にある他のネーミングコンテキストは、それを管理している外部の名前管理サービスのサービスＩＤとそれ自身のオブジェクトＩＤの組によって表される。

共有状態にあるネーミングコンテキスト群は、個々のネーミングコンテキストに関連付けられている名前のみならず、他のネーミングコンテキストに関連付けられている名前も同等に取り扱う。

名前空間合成処理は、図１０のネーミングコンテキスト共有化テーブルを用いて名前が指し示すオブジェクトを共有状態にある他の名前管理サービスを横断して照会することができる。

また、上述の図１０のネーミングコンテキスト共有化テーブルに代えて横断ドメイン管理テーブルを設け、共有単位を横断ドメインとして一括して管理するようにしても良い。

すなわち、名前空間合成処理は、複数の名前管理サービス間で名前合成を行う。名前空間合成処理は、図１１（横断ドメイン管理テーブル）のデータ構造体を管理する。複数の名前管理サービス間で名前空間合成を行う取り決めがなされた場合、その取り決めに係る範囲を横断ドメインという。図１１（横断ドメイン管理テーブル）では、自名前管理サービスが識別する横断ドメインＩＤと、その横断ドメインのルートとなるネーミングコンテキストのＩＤと、横断ドメインに参加している他の名前管理サービスに関する情報を集約した外部ドメイン結合リストからなる組みのリストを表す。さらに、外部ドメイン結合リストは、その横断ドメインに参加している他の名前管理サービスのＩＤと、左記サービスが識別する横断ドメインＩＤと、左記サービスが設定した横断ドメインのルートとなるネーミングコンテキストのＩＤと、認証情報からなる組みのリストを表す。さらに、左記認証情報は自ドメインのユーザＩＤとそのユーザが他のドメインでも認証されるための外部認証キーの対応関係のリストと、逆に、他ドメインのうち自ドメインで認証できるユーザのＩＤのリストとを表す。前者は自ドメインのユーザが他ドメインの計算機リソースを操作するときに、名前管理サービスがユーザに代わって他ドメインに対してそのユーザの認証操作を行うために用いられる。後者は逆に、他ドメインのユーザが自ドメインの計算機リソースを操作するときに、用いられる。

名前空間合成処理は、横断ドメイン管理テーブルを用いて、横断ドメイン上のオブジェクトの照会を行う。この処理では、ネーミングコンテキストのグラフを下降しつつ、横断ドメインのルートに設定されているネーミングコンテキストに達したときには対応する他のドメインまで拡張してオブジェクト照会を行う。

このように図１０のネーミングコンテキスト共有化テーブルや図１１の横断ドメイン管理テーブル等を用いることによりサブシステムの名前空間を疎結合することができる。
なお、アプリケーションのサブシステムとセンサグループのサブシステムとの疎結合のみが行なわれるようにするために、サブシステムの種別に基づいて疎結合を制御するようにしても良い。

この発明の実施例の分散処理システムを構成を全体として示す図である。 この実施例の名前空間の自動構成の例を説明する図である。 上述実施例におけるアプリケーションサービスへのセンサ割り当て手順を説明する図である。 上述実施例におけるアプリケーションサービスへのセンサ割り当て処理を説明するフローチャートである。 上述実施例におけるアプリケーション側からのセンサ側の状態問い合わせ手順を説明する図である。 上述実施例におけるセンサ側からのアプリケーション側の状態問い合わせ手順を説明する図である。 上述実施例におけるクライアントの状態テーブルを説明する図である。 上述実施例におけるアプリケーションサービスの状態テーブルを説明する図である。 上述実施例の変形例を説明するための図である。 上述実施例の変形例を説明するための図である。 上述実施例の他の変形例を説明するための図である。

符号の説明

１０ 名前空間自動構成サービス
１００，２００，３００，４００ 名前管理サービス
１１０，２１０ アプリケーションサービス
１１１，２１１ アプリケーションサービスの状態
１２０，２２０ クライアント
１２１，２２１ クライアントの状態
１２２，２２２ タグ
３１０，３２０，４１０，４２０ センサ管理サービス
３１１，３１２，３２１，３２２，４１１，４１２，４２１，４２２ センサ
１０００ ネットワーク

Claims (9)

1. センサと、
   上記センサの管理サービスを実行するセンサ管理手段と、
   上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と、
   アプリケーションサービスを実行するアプリケーション実行手段と、
   上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段とを有し、
   上記アプリケーションサービスからの要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースを上記第２の名前空間管理手段の名前空間に位置づけることを特徴とする情報処理装置。
2. さらに、上記アプリケーションサービスからの要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づける請求項１記載の情報処理装置。
3. センサと、
   上記センサの管理サービスを実行するセンサ管理手段と、
   上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と、
   アプリケーションサービスを実行するアプリケーション実行手段と、
   上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段と、
   上記アプリケーションサービスからの要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースを上記第２の名前空間管理手段の名前空間に位置づける名前空間構成手段とを有することを特徴とする情報処理装置。
4. 上記名前空間構成手段は、さらに、上記アプリケーションサービスからの要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づける請求項３記載の情報処理装置。
5. センサと、
   上記センサの管理サービスを実行するセンサ管理手段と、
   上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と、
   アプリケーションサービスを実行するアプリケーション実行手段と、
   上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段とを有し、
   上記第２の名前管理手段は、上記アプリケーションサービスからの要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースを上記第２の名前空間管理手段の名前空間に位置づけることを特徴とする情報処理装置。
6. 上記第１の名前管理手段は、上記アプリケーションサービスからの要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づける請求項５記載の情報処理装置。
7. センサと、上記センサの管理サービスを実行するセンサ管理手段と、上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と、アプリケーションサービスを実行するアプリケーション実行手段と、上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段とを具備する情報処理システムにおいて名前空間を構成する名前空間構成装置であって、
   上記アプリケーションサービスからの要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースを上記第２の名前空間管理手段の名前空間に位置づけるとともに、
   上記アプリケーションサービスからの要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づけることを特徴とする名前空間構成装置。
8. センサと、上記センサの管理サービスを実行するセンサ管理手段と、上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と、アプリケーションサービスを実行するアプリケーション実行手段と、上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段とを具備する情報処理システムにおいて名前空間を構成する名前空間構成方法であって、
   センサ割り当て要求受信部が、上記アプリケーションサービスからセンサ割り当て要求を受け取るステップと、
   第１名前空間設定部が、受け取った上記センサ割り当て要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースの名前を上記第２の名前管理手段の名前空間に位置づけるステップと、
   第２名前空間設定部が、受け取った上記センサ割り当て要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づけるステップとを有することを特徴とする名前空間構成方法。
9. センサと、上記センサの管理サービスを実行するセンサ管理手段と、上記センサおよびセンサ管理手段に対して名前管理サービスを提供する第１の名前管理手段と、アプリケーションサービスを実行するアプリケーション実行手段と、上記アプリケーション実行手段に対して名前管理サービスを提供する第２の名前管理手段とを具備する情報処理システムにおいて名前空間を構成するために用いられる名前空間構成用コンピュータプログラムであって、
   上記アプリケーションサービスからセンサ割り当て要求を受け取るセンサ割り当て要求受信ステップと、
   受け取った上記センサ割り当て要求に基づいて、上記第１の名前管理手段で管理される第１の計算機リソースの名前を上記第２の名前管理手段の名前空間に位置づける第１名前空間設定ステップと、
   受け取った上記センサ割り当て要求に基づいて、上記アプリケーションサービスに関連して上記第２の名前管理手段で管理される第２の計算機リソースを上記第１の名前空間管理手段の名前空間に位置づける第２名前空間設定ステップとをコンピュータに実行させるために用いられることを特徴とする名前空間構成用コンピュータプログラム。

Images