JP3915797B2 - プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 - Google Patents

プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 Download PDF

Info

Publication number
JP3915797B2
JP3915797B2 JP2004152883A JP2004152883A JP3915797B2 JP 3915797 B2 JP3915797 B2 JP 3915797B2 JP 2004152883 A JP2004152883 A JP 2004152883A JP 2004152883 A JP2004152883 A JP 2004152883A JP 3915797 B2 JP3915797 B2 JP 3915797B2
Authority
JP
Japan
Prior art keywords
service
agent
user
framework
pnp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004152883A
Other languages
English (en)
Other versions
JP2004334896A (ja
Inventor
ビシャル・シャー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JP2004334896A publication Critical patent/JP2004334896A/ja
Application granted granted Critical
Publication of JP3915797B2 publication Critical patent/JP3915797B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Information Transfer Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、相異なる通信プロトコルを有する複数のネットワークを単一の統一フレームワークへと統合して、ユーザアプリケーションがさまざまなネットワークデバイスを発見し利用することを可能にする方法および装置に関する。また、本発明は、利用可能な機能の変更およびユーザ相互作用に応答してネットワークノードの動的な適応および再構成を達成する方法に関する。また、本発明は、アプリケーション、サービス、およびデバイスが、自己の能力を記述し、それを他のアプリケーション、サービス、およびデバイスに公表する方法に関する。さらに、本発明は、物理的に相異なるデバイスが、接続し、情報交換し、データタイプを交渉し、それぞれの動作についてのステータスを提供して、ネットワークプラグアンドプレイを達成することを可能にする、プラットフォーム独立でトランスポート独立なプロトコルを提供する方法に関する。
世界的なネットワーキング基盤の出現により、分散サービスおよび分散アプリケーションの大規模な配備が一般的になっている。現在および将来のネットワークでは、時間に敏感な情報を全世界に発信し、世界的な取引を電子的に仲介するサービスがさらに配備されることが期待される。このような分散サービスが普遍的になる前に、このようなサービスの開発、デバッグ、配備および発展を簡単にする新たな機構が必要とされる。このような機構は、基礎になるプロトコルやインタフェースにかかわらずに、必要なサービスを発見し、そのサービスの能力を使用することが必要となる。
家庭で使用可能なもののような典型的な分散ネットワークシステムは、相異なるさまざまな機器を相互接続する。さまざまな家庭用機器（ホームデバイス）は本質的にさまざまなインタフェースおよびプロトコルを利用することがあるため、単一の共通の通信プロトコルを用いてこれらのすべてのデバイスを相互接続することはほとんど不可能である。場合によっては、ほとんどの家庭に既に設置されている配線を使用する（例えば、既存の電源線をＸ−１０デバイスとの通信に使用する）ことは便利であるが、このような既存の配線を使用するネットワークの伝送速度が制限される。例えば、白熱電球やホームセキュリティシステムのようなＸ−１０デバイスは、毎秒数ビットのデータレートで動作する。他方、ディジタルＴＶ、カメラ、あるいはＶＣＲのようなデバイスは、ずっと高い伝送データレートを必要とする。このようなデバイスは通常、ＩＥＥＥ１３９４アーキテクチャプロトコルを用いて相互接続され、データ転送レートは４００Ｍｂ／ｓに達する。
これに対して、現在開発されているさまざまな家庭用自動化アプリケーションは、さまざまな家庭用機器の有効な相互作用を必要とする。したがって、家庭に設置されたすべての相異なるデバイスおよびサービスの有効な相互作用を可能にするには、相異なるさまざまなネットワークを、統一するフレームワークに統合して、相異なるネットワーク内に位置するさまざまなネットワークエンティティが互いを発見し相互作用する機構を提供しなければならない。
また、さまざまなデバイスインタフェースおよびネットワークプロトコルについて、低レベルのプロトコル固有の詳細をアプリケーションが扱うことを必要とせずに、リモートサービスを利用する手段をユーザアプリケーションに提供することが望ましい。
真のプラグアンドプレイ能力を達成するには、フレームワークは、新たに追加されたデバイスによって提供されるサービスを自動的に発見する機構を提供しなければならない。このようなフレームワーク内では、利用可能なネットワークサービスおよびそのネットワーク位置に関する記述は、すべてのユーザアプリケーションにとって容易に利用可能であるようにしなければならない。さらに、ユーザアプリケーションは、遭遇する可能性のある特定のデバイスあるいはサービスとの通信のために、自己の通信インタフェースを自動的に再構成することができなければならない。さらに、フレームワークは、ネットワークサービスへのアクセスを制御するために、ユーザの認可および認証を実行するセキュリティモデルを含まなければならない。
ＪｉｎｉTMは、ネットワークプラグアンドプレイを達成する既存の候補のうちの１つである（Ｊｉｎｉは、サンマイクロシステムズ社(Sun Microsystems, Inc.)の商標である）。Ｊｉｎｉは、分散システムの構築および配備を容易にするアプリケーションプログラミングインタフェース（ＡＰＩ）およびランタイム規約のセットである。Ｊｉｎｉは、分散システムの、共通しているが相異なる部分を処理する「配管」(plumbing)を提供する。Ｊｉｎｉは、プログラミングモデルおよびランタイムインフラストラクチャからなる。リース、分散イベント、および分散トランザクションをサポートするＡＰＩおよび規約を定義することによって、プログラミングモデルは、基礎となるネットワークの信頼性が低くても、信頼性の高い分散システムを開発者が構築するのを助ける。ランタイムインフラストラクチャは、ネットワークプロトコルとそれを実装するＡＰＩとからなり、ネットワーク上のデバイスおよびサービスの追加、探索、アクセス、および削除を容易にする。
Ｊｉｎｉの使用は、基礎となるネットワーク技術について知らなくてもサービスを発見する容易な方法を提供する。他の既知のインフラストラクチャに比べてＪｉｎｉが改良されている点は、ユーザアプリケーションが実際にサービスを探索し、そのサービスをサポートするホストを他者に発見させることができることである。しかし、主な未解決の問題点は、「ユーザアプリケーションはどのようにして自動的にクライアントマシン上のサービスを使用するか」である。クライアントユーザアプリケーションにサービスインタフェースしか設けられていない場合、クライアントが、このサービスを理解することが可能なコードを有していなければならない。
例えば、ユーザが、自己のアプリケーションに、カメラサービスのためのネットワークをブラウズさせたい状況を考える。アプリケーションがこのようなサービスをネットワーク上に見つけた場合、ユーザは、それをクリックして、ユーザ自身のアプリケーションでそれを使用することができる。ユーザが、このようなサービスを実行するためのコードを必要とする場合、このようなコードは、ユーザのマシン上に自動的にダウンロードされなければならない。しかし、このアプローチに関連する主な問題点は、ユーザアプリケーションがこのようなサービスをどのようにして利用するかである。ユーザアプリケーションは、拡張可能なインタフェースを有する場合、リモートサービスインタフェースに問い合わせてその固有の特性を取得し、その利用を可能にすることができる。しかし、このような拡張可能インタフェースの定義は、ＪｉｎｉTM仕様の範囲内にはなく、ＪｉｎｉTMサービスを使用するユーザアプリケーションに委ねられている。
もう１つの問題点は、カメラサービスのセマンティクス（意味論）を定義するエンティティの識別である。例えば、キャノン、ミノルタ、およびニコンを含む主要なカメラメーカがそれぞれ固有のインタフェースを提供する場合、カメラサービスには相互運用性がなくなり、ユーザは、３つの異なるすべてのカメラサービスをコードの形で適切に提供しなければならないことになる。また、もしコダックがＪｉｎｉTMカメラを市販することに決めた場合、ユーザは、コダックのインタフェースの解析を含むようにそのコードを手動（マニュアル）で変更しなければならない。このような拡張可能インタフェースは、ネットワークトラフィックと、クライアントコードのサイズを非常に増大させてしまう。すべての種類の市場固有のグループがまとまってインタフェースを指定することが好ましく、多くの場合にはこれが必要となるであろうが、これはすぐには、また効率的には実現しそうになく、特に、家庭で使用されるすべての種類のデバイスに対しては、きわめて非現実的である。
既知のネットワークで依然として解決されていないもう１つの制限は、ＪｉｎｉTMベースのアプリケーションがどのようにして非ＪｉｎｉTMベースのオペレーティングシステム上にあるデータにアクセスすることができるかに関するものである。すなわち、ユーザは、例えば、ＪｉｎｉTMに対するマイクロソフトのサポートなしで、どのようにしてＭＳ−ＷｏｒｄTMからＪｉｎｉTMプリンタにアクセスすることができるだろうか。Ｊｉｎｉプリンタを使用したいＪａｖａTMアプリケーションですら、アクセスのためのオペレーティングシステムに依拠しなければならない。
例えば、ユーザプログラムが印刷メソッドへのアクセスを要求するとき、以下のようなコードフラグメントが使用される。
object o=Lookup(GeneralPrintService);
GeneralPrintService pservice=(GeneralPrintService)o;
pservice.print();
しかし、このコードが書かれるときに、プログラマは、GeneralPrintServiceという名前のインタフェースがコード実行時に本当に存在するかどうかを知らない。さらに、プログラマが複数のデバイスでイメージを印刷したい場合、複数のインタフェースを予想し、それに応じて印刷を行う必要がある。
Ｊｉｎｉは、ユーザインタフェース（ＵＩ）コンポーネントがサービスの属性リストにエントリとして付加されるように使用することができるため、サービスについて要求されるクライアントの知識は最小限である。クライアントは、単に、ＵＩがアプレットと同様の属性によって表現されることを知っているだけでよい。ＵＩは、ＪａｖａＢｅａｎｓとして提供可能であるため、内省(introspection)・反省(reflection)により、サービスは、クライアントに対して、クライアントがそのサービスを使用することができる手段を提供することが可能である。これは、本質的に、クライアントとサーバの間のメッセージ交換であり、手動の設定を必要とする。しかし、ＵＩコンポーネントを付加することは、人間でないクライアント（生成・使用されるマシン）がデバイスを使用するのを妨げる可能性がある。また、デバイスの個数が増大して、クライアントプログラムが複雑になると、もう１つの問題点が生じる。その場合、クライアントは、返されたリストのどのオブジェクトが真のターゲットであるかを決定しなければならない。さらに、あらゆるＪｉｎｉTMのデバイスあるいはアプリケーションは、製造時において通信するために必要としたすべてのデバイスの（あるいは少なくとも、「デバイスのすべてのタイプの」）すべてのインタフェースを必要とする。その結果、ＪｉｎｉTMは、相互運用性の問題点を実際には解決していない。
もう１つの既存のネットワーキングシステムであるＨｏｍｅＡＰＩは、アプリケーションがさまざまなホームデバイスを発見し利用することを可能にする、オブジェクト指向のソフトウェアサービスおよびアプリケーションプログラミングインタフェース（ＡＰＩ）のセットである。このシステムは、アプリケーションが使用するデバイスおよびネットワークのプロトコル固有の詳細に、ユーザアプリケーションが関与しないように設計された。ＨｏｍｅＡＰＩは、ＨｏｍｅＡＰＩインタフェースの使用を通じてサービスを利用するユーザアプリケーションを開発するのを容易にする分散サービスを表現するソフトウェアオブジェクトのセットを提供する。
しかし、ＨｏｍｅＡＰＩは、新たなデバイスの発見の問題点を解決していないため、所望のプラグアンドプレイネットワーキング能力を提供しない。ＨｏｍｅＡＰＩのもう１つの欠点は、すべてのネットワークデバイスが標準の通信インタフェースを提供することを要求することであり、これは今日の市場では実現不可能である。
ＨｏｍｅＰＮＡ、ＨｏｍｅＲＦ、Ｂｌｕｅｔｏｏｔｈ、ＰＩＡＮＯ、Ｘ−１０、ＣＥＢｕｓ、ＩＥＥＥ１３９４、ＵＳＢ、ＨＡＶｉなどのようなその他の発展段階のネットワーク構想は、単に、ネットワーク接続に関するさまざまなプロトコルを提供しているだけである。これらの通信プロトコルは当業者に周知である。しかし、現在のところ、競合するさまざまなネットワーク技術およびプロトコルの相互運用性の問題点を解決し、ネットワークプラグアンドプレイを達成する統一フレームワークシステムは存在しない。
したがって、さまざまなタイプのネットワークデバイスを相互接続し、デバイスの発見および利用のための一様な機構を提供する統一フレームワークに対して、強く幅広い受容が認識されており、このようなものがあることは非常に有利である。このような統一フレームワークは、ユーザアプリケーションが、アプリケーション−サービス間通信プロトコル、所望のサービスを提供するデバイスに接続されたホストのＩＰアドレスの発見、およびさらには、ネットワークサービスのユーザインタフェースの詳細のような低レベルの詳細を組み込むことを不要にするとともに、上記のその他の要求を満たす。
したがって、本発明の１つの目的は、既知のネットワーキングシステムの上記の制限を克服し、さまざまな機器を相互接続する相異なる通信プロトコルを有する複数のネットワークを単一の統一フレームワークへと統合して、ユーザアプリケーションがさまざまなネットワークデバイスを発見し利用することを可能にする方法および装置を提供することである。
具体的には、本発明の目的は、利用可能な機能の変更およびユーザ相互作用に応答してネットワークノードの動的な適応および再構成を達成する方法および装置を提供することである。
本発明のもう１つの目的は、アプリケーション、サービス、およびデバイスが、自己の能力および通信インタフェースを記述し、それを他のアプリケーション、サービス、およびデバイスに公表する方法を提供する。
本発明のさらにもう１つの目的は、物理的に相異なるデバイスが、接続し、情報交換し、データタイプを交渉し、それぞれの動作についてのステータスを提供して、ネットワークプラグアンドプレイを達成することを可能にする、プラットフォーム独立でトランスポート独立なプロトコルを提供する方法および装置を提供することである。
上記の目的を実現し、本発明の効果を達成するため、アクティブコンフィグレーションフレームワークシステムが提供される。本発明のフレームワークは、サービスとサービスユーザを相互接続する。また、このフレームワークは、プラグアンドプレイブローカを有する。本発明のフレームワークでは、サービスユーザは、プラグアンドプレイブローカを用いて、ネットワーキングサービスを発見し、利用し、ネットワーキングサービスと通信する。
本発明のフレームワークでは、サービスユーザは、サービスを提供するデバイスによって使用される通信プロトコルとは独立に、プラグアンドプレイブローカのインタフェースを通じてサービスと通信する。
また、本発明によれば、サービスをプラグアンドプレイブローカに登録するゲートウェイが提供される。
また、本発明によれば、サービスエージェント、ユーザエージェント、およびディレクトリエージェントを有するアクティブコンフィグレーションフレームワークが提供される。本発明のフレームワークでは、サービスエージェントはサービスをディレクトリエージェントに登録する。その後、ユーザエージェントは、要求するサービスの記述をディレクトリエージェントに通信し、ディレクトリエージェントは、適合するサービスのロケーションを帰す。
本発明のフレームワークでは、サービスは、デバイスクラスタおよびゲートウェイからなることが可能である。サービスエージェントは、このゲートウェイを通じてデバイスクラスタと通信する。
また、本発明によれば、新たなネットワークデバイスの追加に応答して、フレームワークの自動的再構成を行う方法が提供される。本発明の方法によれば、サービスエージェントは、サービスをディレクトリエージェントに登録する。その後、ユーザエージェントは、要求するサービスの記述をディレクトリエージェントに通信する。最後に、ディレクトリエージェントは、要求されたサービスの記述を、提供するサービスの記述と照合し、適合したサービスのアドレスをユーザエージェントに返す。
また、本発明によれば、フレームワークに追加される新たなネットワークデバイスによって実行されるサービスに対する通信インタフェースを生成する方法が提供される。本発明の方法によれば、デバイスは、その通信インタフェースを記述するスキーマを生成する。このスキーマは、ＸＭＬ(eXtensible Markup Language)文書の形式とすることが可能である。その場合、ユーザアプリケーションは、ＸＭＬ言語パーサを用いて、通信インタフェースを生成する。
また、本発明によれば、ネットワークデバイスを制御する方法が提供される。本発明の方法によれば、ユーザアプリケーションは、デバイス記述スキーマを編集し、編集されたデバイス記述スキーマをデバイスに返す。これに応答して、デバイスは、編集されたデバイス記述スキーマに従って状態を変更する。
本発明のフレームワークを使用することにより、ネットワーク内の相異なる物理デバイスの個数にかかわらず、ネットワーキングエンティティの相互作用のための複雑な機構は一度だけ実装すればよい。さらに、これらの機構は、デバイス固有のゲートウェイを通じて管理ブローカと相互作用するユーザアプリケーションから隠蔽される。本発明のフレームワークは、ＳＬＰ、ＨＴＴＰ、ＸＭＬ、ＪａｖａＲＭＩ、およびＩＩＯＰのような周知のインターネット関連プロトコルに基づいており、ウェブサーバへのアドオンとして実装可能であるため、配備および利用が容易である。さらに、本発明のフレームワークでは、サービス発見の全プロセスは、ユーザアプリケーションにとって透過的（トランスペアレント）であり、物理接続（コネクション）に対する区別がない。例えば、ネットワークに接続されるプラグアンドプレイデバイスはＴＣＰ／ＩＰベースである必要はない。サービス利用プロセスもまたトランスペアレントであり、対象となるさまざまなデバイスの能力と、ユーザの認証および認可に基づく。互換性のないデバイスを接続するときには、トンネリングや完全なデータ変換が必要となることもある。
本発明は、デバイス独立な情報交換を容易にするためのアクティブコンフィグレーションフレームワークを提供する。複数のデバイスが接続し、情報交換し、データタイプを交渉し、それぞれの動作についてのステータスを提供するには、相異なるプロトコルが要求される。これらのプロトコルは、プラットフォーム独立であり、その形式や機能にかかわらず、他のデバイスに接続する必要のある任意のデバイスに組み込むことができる。これらのプロトコルはトランスポート独立でもあるため、任意のデバイスが、他の任意のデバイスに接続し、情報交換することが可能となる。
本発明のフレームワークでは、アクティブネットワークの場合のように、ユーザ定義計算がネットワーク内に配置される。しかし、アクティブネットワークとは異なり、現在のインターネットアーキテクチャのすべてのルーティングおよびフォワーディングのセマンティクスは、計算環境をアプリケーション層に制限することにより保持される。このフレームワークを利用するネットワークデバイスおよびサービスは、ネットワークインフラストラクチャに深く組み込まれる場合でも、実際には、エンドシステム上のユーザアプリケーションによって作成され、設定され、動的に制御される。このようなアプリケーション定義エンティティは、ネットワーク内の任意のノードで実行され、個々のパケットは、ネットワークを通じて伝搬するとともに任意のアクションを実行するようにプログラムされることが可能である。
すべてのタイプの分散デバイスおよび分散サービスにわたりネットワークプラグアンドプレイを達成するためには、統一フレームワークが必要である。ここで使用される「フレームワーク」あるいは「サブストレート」という用語は、１つ以上のネットワークを統合するシステムを意味する。しかし、多くの場合、「フレームワーク」、「サブストレート」、および「ネットワーク」という用語は区別なく用いられる。
［アクティブコンフィグレーションフレームワークのコンポーネント］
完全なアクティブコンフィグレーションアーキテクチャは、ダミーデバイス、ゲートウェイデバイス、および、ネットワークに直接的または間接的に接続されたＰｎＰブローカからなる。アクティブコンフィグレーションフレームワークのアーキテクチャを図１に示す。図１に示すように、ネットワークには１個以上の実行環境１０２がある。実行環境１０２は、例えば、インターネットのようなネットワーク１０１を用いて相互接続される。実行環境１０２は、ある意味で、ネットワークノードとして作用する。実行環境１０２は、当業者に周知のＪａｖａ仮想マシンやＷｉｎｄｏｗｓTMベースのマシン内にあることが可能である。実行環境１０２は、ゲートウェイ（図示せず）を通じて非インテリジェント（すなわち、ダミー）デバイスに接続された１個以上のＰｎＰブローカ１０４を有する。ユーザアプリケーション１０３は、ＰｎＰブローカ１０４を通じて、デバイスを発見し、利用し、デバイスと通信する。以下で、本発明のアクティブコンフィグレーションフレームワークシステムのさまざまなコンポーネントについて詳細に説明する。
［ダミーデバイス］
ダミーデバイスは、ＴＣＰ／ＩＰプロトコルスタック、もしくはＪａｖａ仮想マシン、またはその両方のないデバイスである。このようなデバイスは、ネットワークから直接にアクセス可能ではなく、媒介物としてゲートウェイを必要とする。このようなデバイスは、ネットワークにインストールされる前に、特定のコンフィグレーション選択を行う必要がある。例えば、それぞれのＸ−１０デバイス（白熱電球など）には、電源線ネットワークに接続する前に手動でハウスコードおよびデバイスコードを割り当てなければならない。さらに、このようなデバイスは、提示するサービスのためのセキュリティやアクセス制御を実施することはない。このようなデバイスのほとんどは、メモリや処理能力を有しておらず、ネットワークの残りの部分に依然として接続する必要のあるレガシーデバイスとして特徴づけることができる。
［ゲートウェイデバイス］
通常のネットワークデバイスは、単一のネットワークタイプ（例えば、ＩＰまたはＩＰＸ）により、ピアツーピア方式で相互作用することができる。これは、あるネットワークタイプのデバイスは、同じネットワークに物理的に接続された、同じネットワークタイプのデバイスとのみ通信することができることを意味する。第１のデバイスが、その第１のデバイスによってサポートされていないネットワーク上にある第２のデバイス、あるいは、第１のデバイスによってサポートされていないプロトコルを実行している第２のデバイスに接続することを必要とする場合に問題が生じる。この問題を解決するには２つのアプローチがある。
第１のアプローチは、複数の通信スタックを単一のネットワークデバイスにロードすることである。これにより、デバイスは、適当な通信スタックを有する限り、任意のタイプのネットワークデバイスと相互作用することが可能となる。基礎となるトランスポートは異なるが、デバイスがプロトコルスタック全体を理解する場合には、このアプローチはうまくいく。
複数の相異なるデバイスを接続する問題を解決するため、本発明のフレームワークシステムはゲートウェイを使用する。ゲートウェイは、ネットワーク内に不可視的に存在し、あるネットワークタイプを別のネットワークタイプに変換するデバイスである。このアプローチは、デスティネーションデバイスがレガシーであり、各ソースデバイスがデスティネーションと通信するためにデスティネーションをモデル化しなければならない、という本発明の実施例で用いられる。これは、例えば、ファックスデバイスや電子メールデバイスの場合である。デバイスにレガシーネットワークと対話する能力を追加するのではなく、この機能はゲートウェイに置かれる。ゲートウェイは、通常、プログラム可能なプラットフォーム上にホスティングされる。
本発明のフレームワークでは、ＰｎＰブローカが、アクセスのためにゲートウェイを要求するレガシー（ダミー）デバイスとのセッションを確立したい場合、ゲートウェイは、ＰｎＰブローカから、そのデバイスの存在を隠蔽する。ＰｎＰブローカは、その代わりに、ゲートウェイとのセッションを作成し、ダミーデバイスのアドレスをゲートウェイに渡す。この時点以降、ゲートウェイは、セッションにおけるいずれかのチャネルを通じてデータを受け取ると、そのデータを、ゲートウェイ−ダミーリンクを通じてリモートデバイスへと中継する。本発明は、次の２つのタイプのゲートウェイを使用する。一般化ゲートウェイは、ＩＰデバイスとの通信を行い、特殊化ゲートウェイは、ダミーを通じて非ＩＰデバイスとの通信を行う。特殊化ゲートウェイは、ダミーデバイスをネットワークに公開するものであり、そのデバイスを制御・管理するためのプログラミングロジックを含む。さらに、特殊化ゲートウェイは、ダミーデバイスのセキュリティポリシーを実現する。１つのゲートウェイデバイスが複数のダミーデバイスを管理することが可能である。
［ＰｎＰブローカ］
ＰｎＰブローカは、アプリケーション、サービス、およびデバイスのサービスブローカとして作用する。ＰｎＰブローカは、分散システムのためのＩｎｆｏｂｕｓの概念を拡張し、ネットワーク全体をSoftware Busとして扱う。Ｉｎｆｏｂｕｓシステムは当業者に周知である。詳細な説明は、Reaz Hoque, "Connecting JavaBeans with InfoBus", Wiley Computer Publishing, Nov. 98、にある。Software Busもまた当業者に周知であり、Brian Oki, Manfred Pfluegl, Alex Siegel, and Dale Skeen, "The Information Bus - an architecture for extensible distributed systems", Proceedings of the 14th Symposium on Operating Systems Principles, p.58-68, Asheville, North Carolina, December 1993、に記載されている。
ＰｎＰブローカにより、ネットワーク接続されたエンティティは、他のネットワーク接続エンティティ（ゲートウェイあるいはダミー）の能力を発見し利用することが可能となる。ゲートウェイは、その能力を、対応するＰｎＰブローカに登録し、ダミーデバイスは、ゲートウェイを発見し、このゲートウェイを通じてＰｎＰブローカと通信する。ネットワーク内のデバイスの各タイプ（例えば、Ｘ−１０Ｘ、１３９４Ｘ、ＵＳＢ）ごとに特定のゲートウェイがあり、その一端でこのデバイスクラスタに接続され、他端でＰｎＰブローカに接続される。Ｘ−１０、ＨＡＶｉ、ＩＥＥＥ−１３９４、およびＵＳＢは周知の通信プロトコルである。２つの相異なるゲートウェイが互いに対話したい場合、通信のためにＰｎＰブローカを使用することができる。例えば、あるゲートウェイがＪｉｎｉクラスタを代表する一方で、別のゲートウェイが、ＨＡＶｉを用いたＩＥＥＥ１３９４クラスタのゲートウェイとなることが可能である。本発明のフレームワークでは、ゲートウェイは、そのアーキテクチャ用に設計されたダミーを使用することにより、受動（非ＴＣＰ／ＩＰ）デバイスと通信する。
図２に、アクティブコンフィグレーションフレームワークの全体設計を示す。実行環境１０２内で動作するＰｎＰブローカ１０４は、ゲートウェイ２０１を通じて、ダミーデバイス２０３およびユーザアプリケーション２０２と通信する。ゲートウェイデバイス２０１は、ネットワークノード２０５上で、そのオペレーティングシステム環境内で動作する。ノード２０５は、ゲートウェイおよびサービスへのアクセスを制御するためにセキュリティ実施機構２０４を提供する。
ネットワーク接続されたエンティティは、サービスユニットと呼ばれる有意味な機能に再分割される。原理的には、アーキテクチャは、ユーザアプリケーションの観点から、１つの有意味な機能を１つのサービスユニットとして定義する。サービスユニットは、ユーザアプリケーション／サービス全体であることも可能であり、ユーザアプリケーション／サービスの一部であることも可能である。コマンド、応答、およびデータは、ユーザアプリケーションとサービスユニットの間、サービスユニットとサービスの間、あるいはサービスユニットと別のサービスユニットの間で交換することが可能である。サービスユニットは、その機能をＰｎＰブローカに登録する。
ＰｎＰブローカにより、ネットワーク接続されたエンティティは、他のネットワーク接続エンティティの能力を発見し利用することが可能となる。ネットワーク接続エンティティは、サービスユーザ（ユーザアプリケーション）であることが可能である。ユーザアプリケーションは、ＰｎＰブローカを通じて、サービスを発見し、それを使用することを要求する。ＰｎＰブローカは、サービスユニットとユーザアプリケーションを接続するためのトランスポート独立なインタフェース（ＰｎＰブローカインタフェースという）を提供する。このインタフェースは、ＴＣＰ／ＩＰプロトコルスタック上で動作するように設計される。ＰｎＰブローカは、サービスブローカまたはマネージャとしてその役割を果たすために、異なるクラスタ内の他のＰｎＰブローカと通信する。ＰｎＰブローカ間のプロトコルはＰｎＰブローカ間プロトコルと呼ばれる。
各デバイスクラスタは、高々、１つのＰｎＰブローカを有する。ローカルなＰｎＰブローカがないとき、ユーザアプリケーション／サービスユニットは、ＪａｖａＲＭＩやＨＴＴＰのようなインターネット通信プロトコルを通じてリモートＰｎＰブローカ（別のゲートウェイに接続されたＰｎＰブローカ）を使用することが可能である。ＪａｖａＲＭＩプロトコルは当業者に周知である。その詳細な説明は、Downing, Troy Bryan, "Java RMI: Remote Method Invocation", IDG Books Worldwide, 1998、にある。ＨＴＴＰプロトコルも当業者に周知である。その説明は、"Paul S. Hethmon, "Illustrated Guide to HTTP", Manning Publications, 1997、にある。サービスユニットは、それに直接に接続されたＰｎＰブローカを使用することも可能であるし、ＰｎＰブローカ間プロトコルを使用することによりリモートＰｎＰブローカを使用することも可能である。図３に示すネットワークシステムでは、サービスユニット４０６は、ＰｎＰブローカ間プロトコル４０４を通じて、リモートＰｎＰブローカ１１０４に接続されたサービス１４０６および１４０２を利用する。こうして、あるサービスユニットが、異なるデバイスクラスタに位置するサービスユニットで利用可能なサービスに問い合わせ、これを使用することができる。
［ＰｎＰブローカ機能コンポーネント］
ＰｎＰブローカの内部コンポーネントを図４に示す。通常、ＰｎＰブローカは、サービスレジストリ３０５、サービスディスカバリ／アベイラビリティエージェント３０４、サービスセッション管理エージェント３０６、サービスロケーションプロトコル（ＳＬＰ：service location protocol）ユーザエージェント３０８およびＳＬＰサービスエージェント３０７からなる。ＰｎＰブローカ間プロトコル３０３は、他のＰｎＰブローカ３０１との通信に使用される。ＰｎＰブローカインタフェース３０２は、ユーザアプリケーション１０３に対するインタフェースを提供する。サービスロケーションプロトコル（ＳＬＰ）は、当業者に周知であり、James Kempf and Pete St. Pierre, "Service Location Protocol for Enterprise Networks: Implementing and Deploying a Dynamic Service Resource Finder", John Wiley and Sons, 1999、に記載されている。サービスレジストリは、１個以上のサービスレコードを含む。サービスレジストリ内のすべての情報は、検索、索引づけおよび交換を容易にするために、ＸＭＬ(eXtensible Markup Language)として記述される。ＸＭＬもまた当業者に周知であり、Natanya Pitts-Moultis and Cheryl Kirk, "XML black book", Coriolis Group Books, 1999、に記載されている。
［サービスレジストリ］
ＰｎＰブローカは、サービスについての情報を保持するためにサービスレジストリを含む。最小限、レジストリは、そのＰｎＰブローカに直接に接続されたゲートウェイおよびサービスについての情報を格納する。図３に示すように、これらのサービスは、ローカルＰｎＰブローカ１０４またはリモートＰｎＰブローカ１１０４にある。さらに、ＰｎＰブローカレジストリは、他のＰｎＰブローカに登録されているサービスについての情報を格納することも可能である。この拡張されたレジストリ機能により、ローカルＰｎＰブローカは、サービスのローカルなディレクトリを保持することが可能となる。これは、ローカルな環境にとって重要であり、ネットワーク内に別個の「集中化した」ＳＬＰディレクトリエージェントは不要となる。例えば、ローカルＰｎＰブローカがプリントサーバをサポートする場合、レジストリは、すべての準拠プリントサーバについての情報を有することが可能である。最終的に、この情報は、負荷均衡、フォールトトレランス、あるいはキャッシュのために使用可能である。また、ＰｎＰブローカサービスレジストリは、デバイスタイプにかかわらず、ローカルＰｎＰブローカの範囲内にあるすべての準拠デバイスについての情報を提供する、ネットワークディレクトリとして作用することも可能である。この場合、ネットワーク内のＰｎＰブローカのうちの１つが、すべてのＰｎＰブローカを見つけて登録する責任を負う中心ディレクトリとして指定されることになる。ネットワークリソースに対する他のデバイスからのすべての要求は、このＰｎＰブローカへ向けて送られ、このＰｎＰブローカはそれぞれに応答することになる。
［サービスレコード］
サービスレコードは、ネットワーク接続されたクラスタ内の利用可能なサービスユニットのセットであり、利用可能なサービスと、他のＰｎＰブローカから要求されたサービスとを記述する。サービスレコードは、そのローカルクラスタ内の０個以上のサービスユニットレコードからなる。サービスユニットレコードは、サービスユニットＩＤフィールドと、それに続く０個以上の属性レコードからなる。サービスユニットＩＤフィールドは、サービスユニットのタイプと、そのサービスユニットによって提供されるサービスとを識別する。デバイスは、ただ１つのサービスユニットを有するが、複数の属性を有することも可能である。属性レコードは、属性ＩＤフィールド、その値、および、アクセス制御情報からなる。属性レコードは、主に、それぞれのサービスまたはデバイスに対する細かいアクセス制御を実施するために使用される。さらに、属性レコードは、デバイスの現在の状態、および、それを変更するために使用可能なインタフェースの記述を格納する。
［サービスディスカバリ／アベイラビリティエージェント］
ＰｎＰブローカは、リモートＰｎＰブローカを発見し利用可能なサービスを識別するために、サービスディスカバリ／アベイラビリティエージェントを必要とする。サービスディスカバリ（発見）は、ローカルＰｎＰブローカによって指定される、要求されるサービスタイプを、リモートＰｎＰブローカ上で利用可能なサービスタイプと比較することによって実行される。ローカルＰｎＰブローカからリモートＰｎＰブローカへ要求サービスタイプを送信し、リモートＰｎＰブローカからローカルＰｎＰブローカへその応答を送信するために、上記のＪａｖａＲＭＩやＨＴＴＰを使用することができる。要求サービスタイプの指定の検査により、ＰｎＰブローカは、リモートＰｎＰブローカに登録されているすべてのあるいは特定のサービスの特性を決定することができる。サービスディスカバリ／アベイラビリティエージェントは、ＳＬＰユーザエージェントおよびＳＬＰサービスエージェントの上に位置する。
さらに、ＰｎＰブローカは、サービスディスカバリ／アベイラビリティエージェントを用いて、サービスのアベイラビリティ（利用可能性）を周期的にチェックすることができる。ローカルＰｎＰブローカは、適当なＰｎＰブローカに対して、アベイラビリティチェックを実行するよう要求する。本発明の実施例では、ユーザは、アベイラビリティチェックの周期を指定し、また、このチェックを取り消すことができる。
［サービスセッション管理エージェント］
ユーザアプリケーションがサービスまたはデバイスを発見し、それを使用したいとき、ＰｎＰブローカは、ユーザアプリケーションとそのサービスの間に仮想パイプ（トンネル）を確立する。これをサービスセッションという。このようなトンネルを用いて、ユーザアプリケーションとサービスの間で、コマンド、応答およびデータを交換することができる。デバイスのインタフェースの編成に従って、これらのコマンド、応答、およびデータは特定のフォーマットを有し、定義されたプロトコルのもとで交換される。ＰｎＰブローカは、この仮想パイプを管理しながら、以下の３つのプロトコルのうちの１つで動作するよう指令されることが可能である。
［ネイティブパケットでのネイティブデータ転送］
ＰｎＰブローカは、データパイプを設定した後、バックグラウンドに入ることにより、ユーザアプリケーションとサービスが、メッセージストリームおよびデータフォーマットを管理することを可能にする。このアプローチは、ＰｎＰブローカが他のネットワークエンティティの能力を発見するために単独で使用され、アプリケーション、サービス、およびデバイスがユーザアプリケーションと発見されたサービスとの間の相互作用を管理するときに有用である。メッセージは、ＰｎＰブローカの関与なしに、ユーザアプリケーションとサービスの間で直接に交換される。メッセージ交換は、厳密に、ネイティブパケットにおけるネイティブデータの形式である。サービスを要求する前にサービスを発見するためあるいはサービスの問合せ（クエリ）を行うために、ユーザアプリケーションは、ＰｎＰブローカ間プロトコルを使用可能である。例えば、ＩＥＥＥ１３９４対応のカメラは、このデータ交換フォーマットを用いて、データストリームをディジタルＶＣＲに送ることができる。
［ＰｎＰブローカのパケットにおけるネイティブデータ転送（トンネリング）］
データフォーマットはユーザアプリケーションおよびサービスによって選択され制御される一方で、ＰｎＰブローカが、データパイプを設定し、メッセージストリームを管理することも可能である。このアプローチは、ユーザアプリケーションと発見されたサービスとの間で共通のメッセージングプロトコルが存在しないときに有用である。すべてのメッセージは、ＰｎＰブローカ間プロトコルによって運ばれる。例えば、ＩＥＥＥ１３９４対応カメラは、ＰｎＰブローカを通じて、異なるクラスタ内のディジタルＶＣＲにデータストリームを送る。
［ＰｎＰブローカのパケットにおけるＰｎＰブローカのデータ（完全機能ゲートウェイ）］
ＰｎＰブローカが、データパイプを設定し、メッセージストリームを管理し、ユーザアプリケーションとサービスとの相互作用のためのデータフォーマット定義を提供する。また、ブローカは、ユーザアプリケーションと発見されたサービスとの間の共通のメッセージングプロトコルおよび共通のデータフォーマットを提供する。メッセージ交換情報は、ＰｎＰブローカデータに含まれ、これはパケットにフォーマットされる。ユーザアプリケーションメッセージは、ＰｎＰブローカを通るが、ＰｎＰブローカは、メッセージの内容あるいはセマンティクスを検査することはない。このタイプの相互作用の例は、ＵＳＢデバイスと対話するＩＥＥＥ１３９４対応デバイスである。
［ＳＬＰユーザエージェント］
ユーザエージェントは、あるサービスとの接続を確立するためにユーザに代わって動作するプロセスである。ユーザエージェントは、サービスエージェントまたはディレクトリエージェントからサービス情報を取得する。
［ＳＬＰサービスエージェント］
サービスエージェントは、サービスを公表するために、１個以上のサービスに代わって動作するプロセスである。
［プロトコルと相互作用］
ＰｎＰブローカは、ユーザアプリケーションがネットワークのプラグアンドプレイ機能を利用することができるようにする標準化されたインタフェースを公開する。このＰｎＰブローカインタフェースを用いて、アプリケーションは、トランスポート層とは独立にＰｎＰブローカ間プロトコルを用いて相互に通信するように書くことができる。この設計は、ポータビリティ（可搬性）を促進し、ネットワークサービスの発見および選択のためのスケーラブルなフレームワークを提供する。ＰｎＰブローカ間プロトコルは、IETF Service Location Protocol v.2に基づいており、サービスをサポートするネットワークホストの名前をユーザアプリケーションが知ることは不要である。むしろ、ユーザは、ＰｎＰブローカインタフェースを通じて、所望のサービスタイプと、対応する属性のセットとをＰｎＰブローカに与える。これらは、ＰｎＰブローカに対して、所望のサービスを記述する。この記述に基づいて、ＰｎＰブローカは、ＰｎＰブローカ間プロトコルを用いてサービスのネットワークアドレスを解決し、ＰｎＰブローカ間プロトコルは、サービスロケーションプロトコルを使用する。また、ＰｎＰブローカインタフェースは、デバイスあるいはサービスのためのユーザの識別および認証機構を扱う。いったんサービスが識別されると、ＰｎＰブローカ間プロトコルは、ＪａｖａＲＭＩあるいはＨＴＴＰを用いて、ユーザアプリケーションが、発見されたサービスを使用することを可能にする。このフレームワークのもう１つの重要な特徴はゲートウェイによって提供される。ゲートウェイは、デバイスの能力をＰｎＰブローカに登録し、ＰｎＰブローカが、ＰｎＰブローカにおいてサービスエージェントを通じてサービスを使用することを可能にする。
要約すれば、本発明のプロトコルスイートは、以下のプロトコルおよびインタフェースからなる。
・ＰｎＰブローカとユーザアプリケーションの間のインタフェース。
・あるＰｎＰブローカと別のＰｎＰブローカの間のプロトコル。
・ＰｎＰブローカとゲートウェイの間のプロトコル。
・ゲートウェイとダミーの間のプロトコル。
［ユーザアプリケーションへのＰｎＰブローカのインタフェース（ＰｎＰブローカインタフェース）］
ＰｎＰブローカは、サービス登録、サービス発見、サービス要求、およびアベイラビリティチェックのために、ユーザアプリケーションに対して、標準化されたＡＰＩおよびインタフェースを公開する。さらに、ＰｎＰブローカは、適当なサービスあるいはデバイスのためのユーザの識別および認証を扱う。
［サービス登録］
必要なとき、サービスユニットまたははユーザアプリケーションは、それぞれ、サービスユニットまたはユーザアプリケーションとしてローカルＰｎＰブローカに自分を登録または登録解除するために、RegisterService()またはUnregisterService()を呼び出す。ユーザアプリケーションまたはサービスユニットがＰｎＰブローカに登録された後、その機能は、別のユーザアプリケーションまたはサービスユニットからのQueryService()またはSearchService()要求に対する応答に含まれる。
［サービス発見］
ユーザアプリケーションは、SearchService()を呼び出して、ローカルＰｎＰブローカに対し、特定のサービスを有する登録されたサービスユニットを含むＰｎＰブローカを探索するよう要求する。ユーザアプリケーションは、QueryService()を呼び出して、どのようなサービスユニットが登録されているか、および、ユーザアプリケーションによって指定されたＰｎＰブローカに登録されているサービスユニットの機能を発見する。
［サービス要求］
ユーザアプリケーションまたはサービスユニットは、OpenService()を呼び出して、ローカルＰｎＰブローカに対し、ローカルＰｎＰブローカまたはリモートＰｎＰブローカのいずれかに登録されている特定のサービスユニットとのサービスセッションを開始するよう要求する。TransferData()、ReceiveData()、およびCloseService()コールにより、追加機能が提供される。
［アベイラビリティチェック］
ユーザアプリケーションまたはサービスユニットは、StartAvailabilityCheck()を呼び出して、ローカルＰｎＰブローカに対し、ローカルＰｎＰブローカまたはリモートＰｎＰブローカのいずれかに登録されている特定のサービスユニットが動作しているかどうかを周期的にチェックするよう要求する。
［ユーザの識別および認証］
好ましい実施例では、本発明は、Ｊａｖａアプリケーション環境を利用する。これは、分散コンピューティングのための適切な、現在利用可能なコンピューティングプラットフォームを提供するからである。この環境では、コードおよびデータの両方が、マシン間で移動可能である。この環境は、別のマシンからダウンロードされたコードが、妥当なレベルの信頼性で動作することを可能にする組込みセキュリティを有する。Ｊａｖａアプリケーション環境における強い型付けにより、仮想マシン上で、オブジェクトのクラスの識別は、そのオブジェクトがそのマシン上で発生したものでないときでも実行可能である。その結果、ネットワークは、必要に応じて移動可能なオブジェクトの流動的なコンフィグレーションをサポートし、オペレーションを実行するためにネットワークの任意の部分を呼び出すことができる。
ホームデバイスへの認証なしのアクセスは、フレームワーク全体のセキュリティにとって重大な結果を生じる可能性がある。リソースへの制御されたアクセスは、安全性とセキュリティの基礎である。従って、本発明の一実施例は、Ｊａｖａ仮想マシンおよびＪａｖａプログラミング環境を使用して、１つのデバイスのセキュリティを保証する。システムは、障害のあるデバイスに対処するように設計することが可能であるが、ネットワークセキュリティは、デバイスセキュリティよりも複雑な問題となる。
本発明のもう１つの実施例は、コードを参照する手段として、および、基本的なアクセス制御機構として、コードのＭＤ５チェックサムを使用する。ＭＤ５は、コードのチェックサムを生成する暗号化手続きであり、アクセス制御のために使用される。しかし、ネットワークが大規模になると、セキュリティポリシーを指定しコードに名前付けするためのより柔軟な分散機構が必要である。
本発明のセキュリティモデルは、プリンシパルとアクセス制御リストという２つの概念の上に構築される。サービスは、あるエンティティ（プリンシパル）に代わってアクセスされる。プリンシパルは、一般に、システムの特定のユーザに由来する。サービス自体が、そのサービスを実装するオブジェクトの識別に基づいて、他のサービスへのアクセスを要求することが可能である。サービスへのアクセスが許可されるか否かは、そのオブジェクトに対応するアクセス制御リストに依存する。
［ＰｎＰブローカ間通信プロトコル］
ＰｎＰブローカ間通信プロトコルは、２つの部分に分かれる。第１に、ネットワーク内で新たなデバイスおよびサービスを発見するための、プロトコルおよび機構のセットが使用される。発見（ディスカバリ）手続きは、ユーザアプリケーションがどのようにしてネットワークインフラストラクチャを探索するか、および、ユーザアプリケーションがどのようにして自分自身およびそのサービスを登録することができるかを指定するサービスディスカバリプロトコルの部分に基づく。他方、ルックアップ手続きは、ユーザアプリケーションが、集中化されたレジストリがある場合あるいはない場合に、必要とするサービスを探索するためにどのようにしてレジストリに問合せを行うかを指定するプロトコルに基づく。
いったんサービスが探索された後、そのサービスを利用するために他のステップが必要になることがある。本発明の実施例では、ユーザアプリケーションは、サービスの品質およびセキュリティ条件を含めて、サービスへのアクセスの交渉を行う。さらに、サービスへのアクセスの交渉が成功した後、ユーザアプリケーションは、ＪａｖａＲＭＩ、ＨＯＰ、あるいはＨＴＴＰプロトコルを使用して、実際にサービスを利用する。
［サービスディスカバリ／登録プロセス］
ルックアップおよびディスカバリの両方のために、サービスロケーションプロトコル（ＳＬＰ）が使用される。図５に、サービスディスカバリ手続きを示す。ＳＬＰは、自動的に、しかも事前の設定なしで、ユーザエージェント（ＵＡ：user agent）５０２の要求を、サービスエージェント（ＳＡ：Service Agent）５０４によって提供されるサービス５１２と照合する。ＳＬＰは、ＳＡによるサービスの公表と、ディレクトリエージェント（ＤＡ：Directory Agent）５１１により管理されるＳＬＰディレクトリ５０８へのサービスの編成とを処理する。また、ＳＬＰは、サービスがユーザアプリケーションにサービスの能力および設定条件を通知する手段を提供する。
ＰｎＰブローカ５０１内のＵＡ５０２は、ユーザアプリケーション１０３によるサービスおよびリソースの要求を理解する。同じくＰｎＰブローカ５０３（同じＰｎＰブローカでも異なるＰｎＰブローカでもよい）にあるＳＡ５０４は、各ネットワークサービスを代表し、ＵＡ５０２にとって利用可能なサービスを行う。ＳＬＰは、動的にサービス属性を保持するため、ＵＡ５０２は、現在の情報を取得することが可能である。サービスは、アプリケーションによって自動的に探索されることも可能であり、あるいは、サービスブラウザでユーザに提示されることも可能である。ＳＬＰは、既存のアプリケーションをサポートするとともに、新たなサービスの公表および発見を容易に可能にする。
本発明によれば、サービスは、ゲートウェイによって記述される。ゲートウェイは、ＳＡ内の属性（そのサービスに対応する）の値を設定する。例えば、プリンタは、ポストスクリプトプリンタとして、青色の紙が利用可能なプリンタとして、あるいは、ユーザのオフィスの同じフロアにあるプリンタとして、記述することができる。ＵＡ５０２は、ＤＡ５１１への要求メッセージＳｒｖＲｅｑ５０５において必要なキーワードおよび属性値を指定することによって適当なプリンタを選択し、応答を待つ。ＤＡ５１１は、適当するサービスのネットワークロケーションを含む応答ＳｒｖＲｐｌｙ５０５により応答する。小規模な施設では、ＤＡがないことも可能であり、その場合、要求メッセージは直接にＳＡに送られることになる。これを、ブロードキャストによるディスカバリ（５０７）という。
サービスは、ＤＡ５１１に登録することによって自分自身を公表する。サービスの登録は、サービスを記述するすべてのキーワードと属性値対（属性と値からなる対）とからなるリストを含む。また、登録は、リソースへのリースを含む。これにより、リースの満期後、サービス情報はＤＡ５１１によって削除される。リース機構は、サービスが永久に公表され続けているのにサービスハードウェアがもはや利用可能でない状況を避けるために実装される。また、明示的な登録解除も、ＳＡの規則正しいシャットダウン手続きの一部として、ＤＡからサービスの情報を削除することが可能である。また、ＳＡが、現在の属性情報を周期的に登録することにより、ＵＡが、サービスに関連するステータス、負荷、温度、あるいはその他の動的特性を確認することも可能である。
本発明のフレームワークでは、サービスは、そのサービスタイプに従って分類される。各サービスタイプは、ＳＡ５０４がサービスを記述するために利用可能にする、利用可能なキーワードおよび属性のセットを定義する。サービスブラウザは、まず、ＵＡ５０２にとって利用可能なサービスタイプを発見した後、そのサービスタイプについてＳＡによって公表されているすべての情報を問い合わせることによって、ＵＡ５０２にとって利用可能なすべてのサービスのすべての特性を決定することができる。
［ユーザエージェントとサービスエージェントの相互作用］
サービス／デバイス登録プロセスの一部として、まず、サービスユニット５１２のゲートウェイは、サービスあるいはデバイスをＳＡ５０４に登録し、その後、ＳＡ５０４は、ＳｒｖＲｅｇメッセージ５０６をＤＡ５１１に送る。この登録は、サービスの特定のインスタンスに対するサービスＵＲＩと、そのサービスを記述する属性値対とを含む。ＤＡ５１１は、さまざまな目的で、このような登録をキャッシュすることが可能である。登録がキャッシュされた後、ＤＡ５１１は、ＳｒｖＡｃｋメッセージにより応答する。また、サービス登録は、寿命(lifetime)を含む。サービスが利用不能になったがそれ自身を登録解除することができなかった場合、寿命値により、ＤＡ５１１は、キャッシュされた登録を満期にすることができる。この状況は、ＳＡ５０４がＳｒｖＤｅｒｅｇメッセージ５０６を発行することができない場合にしか生じないはずである。正常動作中、ＳＡ５０４は、後続のＳｒｖＲｅｇメッセージで周期的にサービスの登録をリフレッシュする。このような「リフレッシュ」メッセージは、いずれかの値が変化した場合には更新された情報を含むことが可能であるが、完全な属性のセットを含む必要はない。
ＰｎＰブローカ５０１のＵＡ５０２は、サービスが要求されるときに、ＤＡ５１１に対して要求を行う。ＵＡ５０２がＤＡ５１１を発見することが可能ないくつかの方法がある。起動時にＤＡ５１１のアドレスをＵＡ５０２に静的に設定することに加えて、ＵＡ５０２は、当業者に周知のＤＨＣＰ(Dynamic Host Configuration Protocol)を用いてＤＡ５１１のアドレスを要求することも可能である。第３のオプションとして、リンク上にマルチキャストを行い、ＤＡの公表を受け取るということがある。これらの３つのオプションは共存するが、ＳＬＰが、手動設定なしで動作可能であることが重要である。この理由で、ＵＡ５０２は、ＤＡ５１１を見つけるためにＳｒｖＲｅｑを使用することが可能である。ＳｒｖＲｅｑは、ＳＬＰに対するＩＡＮＡ割当てマルチキャストアドレスにマルチキャストされる。ＩＡＮＡは、当業者に周知のInternet Assigned Numbering Authority標準である。これはマルチキャスト要求であるため、複数のユニキャスト応答を受け取る可能性がある。その結果として得られるＤＡのりすとは、他のサービス要求のために使用可能である。
いったんＵＡ５０２がＤＡ５１１のアドレスを得ると、後続のサービス要求は直接にそのエンティティに対して行うことが可能である。プリンタを例とすると、ＵＡ５０２がプリンタサービスを探索しようとする場合、ＳｒｖＲｅｑが作成される。このメッセージは、サービスタイプ"printer"と、オプションの属性および値のリストとを含む。属性値対は、要求されるプリンタのタイプを記述する。このメッセージは、事前に設定された、または、マルチキャストを通じて発見された、ＤＡ５１１へユニキャストされる。ＤＡ５１１は、ＳｒｖＲｅｑを受信し、キャッシュされた登録に対するルックアップを実行して、要求された属性および値と一致するものを見つけようと試みる。その後、ＳｒｖＲｐｌｙが、要求側のＵＡ５０２へユニキャストされる。この応答は、一致結果に依存して、０個以上のサービスＵＲＩを含む。その後、ユーザアプリケーションは、そのサービスＵＲＩを用いてプリンタを見つける。
施設内にＤＡ５１１がない場合、ＰｎＰブローカは、同じくラスタ内のＳＡ５０４を見つけることに制限される。これは、多くの小規模な施設では許容できるかもしれないが、ＰｎＰブローカのスケーラブルなアプリケーションの場合、および、複数のクラスタを有する大規模な施設では、ＤＡ５１１を使用しなければならない。さらに、ＳＬＰ ＤＡ５１１は、ＬＤＡＰベースのディレクトリ５０９へのゲートウェイであることが可能であるため、ＰｎＰブローカインタフェースは、変換スキーマ５１０を用いて、すべてのプロトコルに対する単一のＡＰＩを提供する。
ＵＡ５０２は、サービスハンドルを取得したいとき、サービスタイプと、要求する属性の文字列ベースの問合せとをサービス要求として送信する。サービス応答が返されるとき、これは、サービスを指すＵＲＩを含む。ＵＲＩは、ＳＡ５０４のＩＰアドレスを含むか、さもなければ、ＤＮＳがＩＰアドレスへと解決することができる名前を含む。また、ＵＲＩは、ＵＡ５０２がサービスを使用するために必要とするその他の情報を含む。例えばプリンタの場合、キュー名と、プリントサービスをホスティングしているコンピュータのアドレスとが返される。ＵＲＩは、リソースロケーションを表すための従来の標準と同様の自然な方法で、サービスを見つけるために使用される。さらに、文字セット問題は、標準的な方法で対処することができる。
［ＰｎＰブローカとユーザエージェントおよびサービスエージェントとの相互作用］
ＳＬＰを使用することにより、ＰｎＰブローカは、同じタイプの多くの他の公表されたデバイスから適当なサービスの正確な選択をすることができる。これは、ＵＡ５０２によって要求されたキーワードおよび要求された属性値に一致するサービスのみを要求することによって行われる。このようなキーワードおよび属性値は、ＡＮＤ、ＯＲ演算子、一般的な比較演算子により、また、部分文字列マッチングを使用することにより、ブール式へと結合することができる。
ＰｎＰブローカは、ユーザへのコンフィグレーション情報の提供を透過的にし、新たなサービスの設定の作業を容易にする。これらはいずれも、システムアドミニストレータを必要とする。ＳＡ５０４が近隣のＤＡ５１１にサービスを公表するように設定された後、ＵＡ５０２は、さまざまなサービスがオペレーションを開始および停止するとともにネットワーク上で変化する条件に、動的に適応することができる。例えば、ウェブアプリケーションは、現時点でたまたま動作中であるシステムとは独立に、適当なプリンタが利用可能である限りそれを見つけることができる。
ゲートウェイは、ＳＡ５０４に新たなデバイスあるいはサービスを追加したいとき、そのサービスの利用可能な属性およびキーワードを供給する。ＳＡ５０４は、プログラム的にＳＬＰに登録を行い、サービスの固有のコンフィグレーション情報に基づいて属性に対する値を割り当てることができる。その後、ＳＬＰは、登録（公表）を処理し、ユーザアプリケーションとサービスの間のコネクションの確立を可能にする。
新たなサービスタイプを必要に応じて定義することができる。実験的なサービスタイプを限定された用途で配備し、その後に一般用に公開することも可能である。これは、ＳＬＰのネーミング権限機能を用いて実行される。ほとんどの一般的なサービスタイプは、デフォルトで、ＩＡＮＡ(Internet Assigned Numbering Authority)により標準化されたサービステンプレート（スキーム）定義を使用する。代替サービスタイプを定義することは、任意の代替ネーミング権限に知られているスキーム定義（通常は、ローカル管理者に知られている名前）を使用するようにディレクトリエージェントを設定するのと同様に容易である。例えば、家庭でセキュリティサービスを提供するためには、"service:secure:Door"というサービスタイプを定義することができる。もちろん、このタイプのサービスハンドルを利用するユーザアプリケーションは、"secure"サービスと通信するために、そのサービスのネットワークプロトコルを使用しなければならず、さらに、この特別のサービスタイプのＵＲＩに含まれる情報を解析することができなければならない。これは、任意のユーザアプリケーション／サーバプロトコルの自然な動作に本来的なことである。
［ＳＬＰをＬＤＡＰとともに使用すること］
ＬＤＡＰｖ３(Lightweight Directory Access Protocol)は、当業者に周知であり、汎用のディレクトリアクセスプロトコルとして普及しつつある。ＬＤＡＰはその名前にLightweight（軽量）とあるが、ＳＬＰはＬＤＡＰよりもさらに「軽量」である。また、ＳＬＰは、自動ディレクトリ管理を提供するため、および、階層的で自由度の少ない名前空間における不適切なリソース配置を必要としないために、リソース管理においてＬＤＡＰよりすぐれている。ＳＬＰにおいて新たなサービスタイプを追加することはＬＤＡＰの場合よりもずっと容易である。タイプによる問合せは、ＳＬＰの場合のほうがＬＤＡＰの場合よりも効率的である。既存のリソースに対する属性記述は、ＳＬＰでは利用可能であるが、ＬＤＡＰでは不可能である。
ＳＬＰでは、事前コンフィグレーションなしでのディスカバリが可能である。これに対して、ＬＤＡＰは、はじめに、ディレクトリのアドレスと、ＬＤＡＰが使用するディレクトリスキームの知識を必要とする。ＳＬＰでは、非標準的な属性と、標準化されたサービスタイプテンプレートの新しいバージョンが可能であるため、進化することができる。
本発明の実施例は、ＳＬＰを使用して、ＬＤＡＰディレクトリの管理を簡単化し、ＳＬＰが、必要に応じてＬＤＡＰディレクトリから取得される情報を返すことを可能にする。別の実施例では、ＳＬＰは、ＬＤＡＰにサービスエントリを入力するために動的に使用され、ＳＬＰ問合せはＬＤＡＰ問合せにマッピングされて、ＬＤＡＰがＳＬＰのバックエンドとなる。このようなコンフィグレーションの１つの利点は、ユーザアプリケーションが、ＬＤＡＰディレクトリから直接にユーザ認証情報を得ることである。
［サービス利用プロセス］
サービスディスカバリ／登録プロセスは、サービスロケーションプロトコルによって提供されるＵＲＩによって検索可能なサービスレコードを提供する。ＰｎＰブローカ間の交換能力は、サービスレコードを含むQueryService()メッセージを交換することにより提供される。この問合せ(query)は、ユーザアプリケーションが利用したいサービスの要件を記述し、リモートＰｎＰブローカに対してサービスの詳細を要求する。
受信側ＰｎＰブローカは、QueryService()メッセージを受信すると、受信したサービスレコードを自己のサービスレコードと比較する。その後、受信側ＰｎＰブローカは、一致したサービスレコードを含むサービスレコードを要求側ＰｎＰブローカに返す。このアプローチは、すべてのサービスユニット、特定のタイプのサービスユニット、あるいは、特定の能力のセットを有するサービスユニットのうちで、ユーザアプリケーションが探索を行う技術を提供する。ユーザアプリケーションは、サービスレコードを受け取った後、サービスあるいはデバイスを使用するためにＰｎＰブローカとの通信を開始することができる。
ローカルＰｎＰブローカは、リモートＰｎＰブローカへメッセージを送ることによって、ユーザアプリケーションとサービスの間のサービスセッションの確立を要求する。このメッセージは、ユーザアプリケーションサービスハンドル、リモートサービスユニットハンドル、プロトコルＩＤ（ネイティブ／トンネル／ゲートウェイ経由）、要求側（リクエスタ）ＩＤ、および要求側資格証明(credential)からなる。
リモートＰｎＰブローカは、要求されたサービスが受容されるかそれとも拒否されるかを指定するリザルトコードで応答する。リモートＰｎＰブローカは、ある時間後のリダイレクトまたはリトライを含むことも可能である。サービスが受容される場合、リモートＰｎＰブローカは、サービスセッションの開始を識別するサービスハンドルを送信する。サービスセッションは、ユーザアプリケーションとサービスユニットの間、または、２つのサービスユニットの間でのデータ転送を扱う。ユーザアプリケーションは、サービスの使用を完了すると、ローカルＰｎＰブローカに対して、"close service"（サービス終了）メッセージをリモートＰｎＰブローカへ送るよう要求する。さらに、ユーザアプリケーションは、サービスが利用可能であるかどうかを周期的に判定する必要があるとき、それぞれのＰｎＰブローカに対して、フレームワーク内のＰｎＰブローカ間でアベイラビリティチェックを実行するよう要求することができる。アベイラビリティチェックは、１つのデバイス全体に対しても、あるいは、デバイス内で提供される特定のサービスに対しても、実行可能である。
［ＰｎＰブローカ／ゲートウェイプロトコル］
ＰｎＰブローカ／ゲートウェイプロトコルは、簡単なメッセージ交換機構に基づいている。ゲートウェイは、既に説明したように、ゲートウェイに直接に接続されたサービスユニットを代表し、提供されるサービスを登録する。また、ゲートウェイは、ＰｎＰブローカにあるサービスエージェントに対する、任意のサービスのコンフィグレーションにおいてなされる変更を反映する。この登録は、リースに基づいており、ゲートウェイまたはサービスエージェントのいずれかにより更新可能である。登録は、サービスエージェントに現在の情報を提供する。ＰｎＰブローカは、特定のサービスに対する要求を受け取ると、まず、サービスエージェントをチェックして、必要なデバイスあるいはサービスをいずれかの直接接続されたゲートウェイが提供するかどうかを判定する。また、ゲートウェイにより、サービスエージェントは、ゲートウェイ内の特定のイベントに関心があることを登録し、そのイベントの発生の通知を受け取ることが可能である。このようなイベントは、ネットワークにおけるデバイス／サービスの追加／削除であることが可能である。サービスのサービスレコードがアプリケーションの要件に一致した場合、ユーザアプリケーションは、ゲートウェイ内のサービスユニットと、ユーザアプリケーションとの間のサービスセッションを設定することができる。
［イベント通知機構］
本発明のフレームワークでは、ユーザアプリケーションは、イベント通知要求をサーバに登録することができるため、サーバは、新たなデバイスがオンラインになったとき、あるいは、デバイスの属性が変化したときに、ユーザアプリケーションに通知することになる。これを達成するため、本発明は、登録ユーザにイベント通知を配信するための機構を提供する。
ネットワークイベント通知プロトコルには、ＣＯＲＢＡ(Common Request Broker Architecture)イベントサービス、Ｘ−Ｗｉｎｄｏｗシステムイベント、ＳＧＡＰ、ＢＳＣＷなどのいくつかの周知のものがある。例えば、ＣＯＲＢＡイベントサービスは、Robert Orfali and Dan Harkey, "Client/Server Programming with Java and CORBA", Wiley, 1996、に詳細に記載されている。
しかし、上記のイベント通知サービスは、特定のアーキテクチャで動作するように設計され、大規模なコードベースを課するため、軽量通知サービスにおいて実際に使用するのは困難である。
いくつかのタイプのイベントの通知のための登録に関して提供される能力に加えて、ユーザは、属性を通知要求に関連づけることができる。好ましくは、このような通知は、高い信頼性で配信され、完全に規則正しいエンドツーエンド配信を保証するべきである。しかし、通知が、信頼できないトランスポートを通じて配信されるとき、確認応答やリトライは不要である。ユーザアプリケーションは、イベントの需要側が、受信の明示的な確認を供給側に提供することを要求することも可能である。認証のために、ユーザは、通知にディジタル証明して、通知の正当性および完全性を保証することができる。
本発明のフレームワークは、ＳＬＰの使用により、２つの方法でイベント通知を達成する。第１実施例によれば、サービスエージェントは、サービスが更新された後、マルチキャストアナウンス（ＳｒｖＲｅｇ）を送信する。更新を受信した後、ユーザエージェントは、ブラウザ更新を行うことが可能であり、ＤＡは登録を更新することができる。このような使用法は、ＳＬＰ使用では明示的に禁じられていないが、フラッディング(flooding)を引き起こす可能性がある。さらに、このアプローチは、多数のサービス、異なる言語、およびディジタル署名に関して効率的に動作しない。また、ＳｒｖＲｅｇは、ネットワークにおいて追加／削除／変更された各サービスのＵＲＩおよび属性を含む。
本発明のもう１つの実施例では、サービスエージェントは、ネットワーク内のすべてのユーザエージェントへのブロードキャストにより、ＳＡＡｄｖｅｒｔｓメッセージをアナウンスする。ＳＡＡｄｖｅｒｔｓメッセージは、提供されるすべてのサービスタイプのリストを含む。ＳＡＡｄｖｅｒｔｓを得た後、ユーザエージェントは、送信側サービスエージェントへ適当なサービス要求をユニキャストする。サービスエージェントからのアナウンスは、指数バックオフ方式で行われる。
［ゲートウェイ／ダミープロトコル］
ゲートウェイ／ダミープロトコルは、特殊なプロトコルであり、ネットワークにより統合されるデバイスのタイプを反映する。ネットワークは、Ｘ−１０、ＵＳＢおよびＩＥＥＥ１３９４のデバイス／サービスをそれぞれネットワークの残りの部分に接続するＸ−１０ゲートウェイ、ＵＳＢゲートウェイ、およびＩＥＥＥ１３９４ゲートウェイからなることが可能である。ダミーデバイスは、サービスレコードに対応するタイプのレコードを独自(proprietary)フォーマットで格納する。ゲートウェイ／ダミープロトコルは独自のものであるが、ＰｎＰブローカに対しては、標準化されたインタフェースを公開する。
［実施例］
本発明の一実施例によれば、ネットワークは、１個以上のＰｎＰブローカを有する。ＰｎＰブローカは、ユーザといくつかのサービスとの間のインタフェースとして作用する。一実施例では、Ｘ−１０デバイスに対するＰｎＰブローカは、ＵＳＢデバイスによって提供されるサービスにリンクされたいくつかのボタンあるいはその他のユーザインタフェースウィジェットを提供する。ここで用いた「ユーザインタフェースウィジェット」という用語の意味には、ユーザアプリケーションのグラフィカルユーザインタフェースを作成するために使用されるボタン、ダイアログ、テキストウィンドウ、スケールおよびその他のグラフィカルコンポーネントを含む。あるボタンがクリックされると、ＰｎＰブローカは、単に、Ｘ−１０ゲートウェイを通じて、特定のサービスを呼び出す。以下のステップは、この実施例により、ユーザアプリケーションが、ネットワーク内の新たに登録されたサービスを利用するために必要とされる。
１．白熱電球が、家庭の電源アウトレットに挿入される。
２．白熱電球は、ダミーデバイスであるため、Ｘ−１０デバイスを通じて電源線ネットワークに接続される。
３．ホームネットワークでは、ＰｎＰブローカおよびＸ−１０ゲートウェイは、新たなデバイスの導入前に既に動作中である。
４．Ｘ−１０ゲートウェイは、利用可能なアドレスを周期的にポーリングし、いずれかのデバイスがアクティブになったかどうかをチェックする。
５．ゲートウェイは、新たなデバイスがネットワークに入ったことを認識し、そのデバイスと、そのデバイスにより提供されるサービスとの両方を、ＰｎＰブローカのサービスエージェントに登録する。
６．サービスエージェントは、デバイスを使用するために、あるリースを取得する。このリースは、各リース期間後に更新して、これにより、ゲートウェイに対して、サービスが依然として利用可能であるかどうかをチェックするよう要求しなければならない。
７．サービスエージェントは、デバイスにより提供されるサービスを、サービスロケーションプロトコルを用いて、ディレクトリエージェントに登録する。
８．ユーザは、デバイスを使用したい場合、ＰｎＰブローカインタフェースを用いて、要求するサービスに対する問合せおよび検索を行う。すると、ＰｎＰブローカにあるユーザエージェントは、ディレクトリエージェントと連絡をとるか、あるいは、（サービスエージェントおよびユーザエージェントがいずれも１つのＰｎＰブローカ内にある場合には）直接にサービスエージェントへ行く。
９．新たに発見されたデバイスが、ユーザのデバイス記述と一致する場合、サービスエージェントあるいはディレクトリエージェントは、サービスパラメータとともに、固有のＵＲＩをユーザエージェントに返す。
１０．ユーザアプリケーションは、これが非ＴＣＰ／ＩＰデバイスであると判定し、これに従い、ＰｎＰブローカ内のサービスセッション管理エージェントは、ユーザアプリケーションとデバイスの間のセッションを確立する。しかし、このセッションでは、コマンド／データ転送は、ＰｎＰブローカをゲートウェイとして使用して、ＰｎＰブローカ間プロトコルにより行われる。
１１．また、ユーザアプリケーションにより提供されるインタフェースは、デバイス内の機能の実行に関する情報も含む。
１２．ゲートウェイは、サービスにおける状態の変化をサービスエージェントに知らせて更新する。
図６において、本発明の一実施例による例示的なホームネットワークは、電源線（Ｘ−１０）クラスタ６１３、電話線（ＨｏｍｅＰＮＡ／ｘＤＳＬ）クラスタ６０２および６０６、ＣＡＴ５（イーサネット（登録商標、以下同じ。））クラスタ６１６、ＵＳＢクラスタ６１０、ならびにＪｉｎｉデバイスクラスタ６０９などの、周知のネットワークコンポーネントにより構成される。レジデンシャル（住宅）ゲートウェイ６０５は、イーサネット、ＨｏｍｅＰＮＡ、ｘＤＳＬ、およびＪｉｎｉを含むさまざまなネットワークを相互接続するために使用される。イーサネットクラスタは、ユーザのホームＰＣ６２０を含む。ホームＰＣ６２０は、イーサネットプロトコルにより、ディジタルカメラ６１７およびウェブパネル６１８のようなさまざまなデバイスに接続される。ウェブパネル６１８は、ＮＥＣ社の製品であり、タッチパッドを有し、ユーザに、インターネットに容易にアクセスする手段を提供するデバイスである。イーサネットクラスタ６１６は、イーサネットハブ６１９を通じてレジデンシャルゲートウェイ６０５と通信する。イーサネットハブ６１９もまた、インターネットへのホームネットワークのブリッジを提供する。また、ホームＰＣ６２０は、ＵＳＢ配線を用いてスピーカ６１１およびネットワークカメラ６１２に、および、Ｘ−１０配線を用いて白熱電球６１４およびセキュリティマネージャ６１５に接続される。さらに、ホームネットワークは、別のホームＰＣ６０３および６０７、テレビジョン６０１、ならびに電話機６０４を有する。ホームＰＣ６０７を含むｘＤＳＬクラスタ６０６は、ブリッジ６０８を通じてレジデンシャルゲートウェイ６０５に接続される。ＰＣ６２０上で動作するＰｎＰブローカは、ユーザが、ウェブブラウザに基づくインタフェース内で、新たなデバイス／サービスを検索することを可能にする。本実施例は、ユーザインタフェースとして、Microsoft Internet ExplorerTM v5.0ウェブブラウザを使用するが、他の適当なブラウザも使用可能である。
デバイス／サービスは、対応するネットワークに挿入されると、設定可能なプロパティとともにブラウザに現れる。デバイス固有のゲートウェイは、デバイス／サービス記述を格納する。ディレクトリエージェントがネットワーク内にある場合、ディレクトリエージェントが、デバイス／サービスの機能の登録を扱う。正当な権限が与えられた後、ユーザは、デバイスのプロパティの変更や、デバイスの相互接続が可能である。ＰｎＰブローカは、デバイスに対するユーザの認証と、非互換の場合のデータ／メッセージの変換を扱う。例えば、Ｘ−１０デバイス６１４および６１５は、ＰＣ６２０上にあるゲートウェイデバイスを使用することによって、フレームワーク内の残りのデバイスと対話することができるダミーデバイスである。ＰｎＰブローカは、ＨＴＴＰサーバへのアドオンとして実装されることも可能である。ユーザは、電源線デバイス６１４および６１５の状態（電灯のオン／オフ）を変更することができる。デバイス（例えば、カメラ６１７）がＴＣＰ／ＩＰベースである場合、ユーザは、カメラにより提供されるインタフェースに基づいて手動設定を実行し、カメラにより撮られる画像を見ることができる。ユーザは、ビデオオンデマンドサーバに対して、利用可能な映画のリストを問い合わせることができる。通常、（ＰＣ６０３上のＭＰＥＧ−２デコーダを用いて）ネットワークに接続されたアナログＴＶ６０１は、同じタイプのインタフェースを使用している場合には、ビデオオンデマンドサーバにも接続可能である。しかし、ＴＶ６０１およびネットワークカメラ６１２はインタフェースを共有していないため、ユーザは、カメラの画像を直接にＴＶで見ることはできない。Ｊｉｎｉデバイス（例えば、プリンタ）がネットワークに接続されている場合、このデバイスは、非ＪｉｎｉデバイスがあたかもＪｉｎｉデバイスであるかのようにして、非Ｊｉｎｉデバイスとともに動作する。
［Ｊｉｎｉインタフェースの問題点に対する解決法］
ネットワークプラグアンドプレイを達成する候補のうちの１つとしてのＪｉｎｉインタフェースモデルの欠点については既に説明した。本発明は、Ｊｉｎｉセキュリティモデルを借りながら、上記のＪｉｎｉインタフェースの欠点を克服する。Ｊｉｎｉのインタフェースの問題点を解決するには、以下の４つのアプローチを使用可能である。第１に、標準に基づく相互運用性が提供可能である。このアプローチによれば、すべてのサービスは標準ＡＰＩを有し、サービスは、それらの標準ＡＰＩを実装することになる。第２のオプションは、サンドボックスに基づく相互運用性である。この場合、適当なセキュリティモデルを有するＪａｖａ仮想マシンが与えられれば、サービスは独立して動作することができる。第３のオプションは、リフレクションに基づく相互運用性である。この場合、アプリケーションは、サービスに対して、そのインタフェースについて質問し、リフレクション機構を通じて、このインタフェースの状態に影響を及ぼす。最後に、第４の方法は、実装に基づく相互運用性である。この場合、同じ人あるいは会社が、プロキシおよびサービスの両方を製造することになる。
Ｊｉｎｉとは異なり、コードをクライアントに移動しそれをＪａｖａ仮想環境内で実行する代わりに、本発明は、サービスのアドレスおよびそのサービスのインタフェースを記述するその他のパラメータを処理し、このインタフェース情報をクライアントに提供する。
本発明のフレームワークが提供する主な利点の１つは、利用可能な機能およびユーザ相互作用モードにおける変更に応じたエンドユーザアプリケーションの動的な適応および再構成である。一部のインタフェースモデルは、ユーザが「従来型」ソフトウェアとのみ相互作用することができることに基づいている。このようなシステムでは、ユーザは、アプリケーションをカスタマイズする能力において制約があるため、アプリケーションは、デバイスの能力を最大限に、すなわち、サービス設計者が予測したユーザの需要あるいは提供したプログラムインタフェースの限界まで、利用することができない。
多くの場合、自由度はユーザインタフェースによって制限される。アプリケーションの状態およびアプリケーションの初期設定は、ユーザインタフェースを通じてのみ操作可能であるが、ユーザインタフェース自体はあまり設定の自由度はない。これは、モノリシックなプログラムにおいて顕著であり、アプリケーションの状態にフックを設けたり、適切に定義された外部プロトコルを通じてアプリケーションの状態にアクセス可能にしたりするのがきわめて不便である。これに対して、クライアント／サーバプログラムは、公開された相互作用プロトコルを提供するが、２つの大きな問題点を有する。インタフェースの仕様がしばしば臨時的(ad hoc)であること、および、ネットワーク機能についてのアプリケーションのビューを（クライアントコードを修正することによって）変更することができるのはプログラマのみであることである。
上記のインタフェースの問題点を解決する１つのアプローチは、アプリケーションプログラムが、オンザフライでクライアントデバイスあるいはコンピュータに、例えばＪａｖａアプレットとして、ダウンロードされるようにすることである。しかし、このアプローチの問題点として、エンドユーザが、関連するエンティティとして異種のサービスのセットとの相互作用のためにアプリケーションをカスタマイズすることができないことがある。すなわち、このアプローチでは、アプリケーションが透過的でないために、機能的に同一のサービスの場合でも、プロトコルにおける小さい相違を克服することができない。例えば、上記のインタフェースモデルに基づく電灯スイッチ制御プログラムは、新たな電灯スイッチに遭遇するたびに、それを使用するためには異なるアプリケーションをダウンロードする必要がある。したがって、このアプローチは機能を公開するが、操作しやすい形式ではない。
もう１つのアプローチは、さまざまなサービスの機能インタフェースを標準化し、アプリケーションがこれらのインタフェース標準をサポートすることを要求することにより、上記の問題点を回避することである。このアプローチの問題点は、多数のアプリケーション固有の標準を強制することが非実際的である点である。
明らかに、上記のいずれとも異なるモデル、すなわち、インタフェースを公開する要求と、プロトコル標準について合意する要求とのバランスのとれたモデルが好ましい。この問題点を解決するための第１の困難は、サービスの利用可能な機能（インタフェース）を記述する単一ドキュメントスキーマを定義し、関連するプログラムおよびユーザインタフェースをサービスの集合に（およびその逆）関連づけることである。第２の困難は、カスタムユーザインタフェースが利用可能でないときに、上記のスキーマで書かれたドキュメントを用いてユーザインタフェースを生成し、ランタイム環境を実装することができるソフトウェアを提供することである。
本発明の一実施例は、コンポーネントベースのアプリケーションフレームワークを、コンポーネント記述のためのアーキテクチャ独立なドキュメントモデルとともに利用する。このようなコンポーネントベースのアプリケーションフレームワークの詳細な説明は、David Krieger and Richard Adler, "The emergence of distributed component platforms", IEEE Computer Magazine, p.43-53, March 1998、にある。このフレームワークは、上記の２つの基本的なアプローチの特徴を組み合わせることにより、コードフラグメントのアップロード／ダウンロードを可能にし、アプリケーション固有でないインタフェースの記述および操作のために標準を課する。
［本発明のアクティブコンフィグレーションモデル］
本発明のアクティブコンフィグレーションモデルでは、ＸＭＬ(eXtensible Markup Language)記述が、すべてのネットワークデバイスに関連づけられる。ＸＭＬが使用されるのは、ＸＭＬ記述が、（サーバ側での）デバイスの機能の公表として、静的で不変のインタフェース記述を提供するからである。さらに、このようなＸＭＬサービスインタフェース記述を操作することによって、クライアントは、フレームワーク内のサービスを利用することができる。フレームワークは、操作のための標準的なロケーションを提供するために、それぞれのサービスオブジェクトにプログラムおよびユーザインタフェースを公開する。
図７に、本発明のアクティブコンフィグレーションモデルを示す。本発明によれば、ネットワーク内のあらゆるデバイスあるいはサービス７０１は、その機能インタフェースの定義７０２を指定する。これらのインタフェース定義は、アナウンス７０５によってクライアントに伝えられる。これらのインタフェース定義は、サーバ側で静的（スタティック）である（ＣＯＲＢＡにおけるＩＤＬと同様）。これらのインタフェースは、ネットワーク内のすべてのエンティティ間で共有されるが、いずれのユーザアプリケーションによって操作されることも可能である。ユーザアプリケーションは、サービスインタフェースの使用、および、このようなインタフェースによって提示されるメタデータに対する完全なコントロールを有する。ユーザアプリケーション７０３によってインタフェースまたはその使用の状態に変更７０４があれば、リファレンス（参照）７０６によりデバイスあるいはサービスに反映される。
したがって、本発明は、任意のネットワークサービスを構築するためのプログラム可能な基盤を提供する。本発明の一実施例では、エンドユーザアプリケーションは、利用可能な機能および相互作用モードにおける変更に応答して動的に適応され再構成される。この実施例は、コードをダウンロードするＪａｖａアプレットの考え方と、標準化されたインタフェースの記述および操作との利点を組み合わせている。本発明のフレームワークでは、ユーザ（あるいはマシンにより生成されたユーザアプリケーション）は、単に、サービスによって提供されるインタフェース記述を編集し、その編集をデバイスに反映させることによって、ネットワークあるいはデバイスの状態を変えることができる。さらに、デバイスあるいはサービスは、標準化されたＡＰＩを通じてアクセス可能である。すべてのＡＰＩを標準化しようとすることによって特徴づけられる従来のシステムとは異なり、本発明のフレームワークによれば、さまざまなネットワーキングデバイスのベンダは、自己の製品の記述をフレームワークにマッピングすることが可能である。こうして、ベンダは、構文的定義およびデバイスの能力に集中することができる。
本発明によれば、デバイス記述は、宣言的スタイルのＸＭＬを用いて格納され、アプリケーションコードに追加して使用される。ＸＭＬデバイス記述の主な機能は、データおよび制御フロー情報を提供することである。この制御／データの分離を公開することにより、本発明は、メタデータを設計に明瞭に組み込むので、格納および操作がアプリケーションとは独立となるため、アプリケーションは、将来の変更が可能なように設計することができる。
本発明のフレームワークで用いられているような、プログラム／ユーザインタフェースを、それらが参照するオブジェクトから分離することは、当業者に周知のＳｍａｌｌｔａｌｋTMのモデル／ビュー／コントローラ（Ｍ／Ｖ／Ｃ）アーキテクチャに類似している。モデル／ビュー／コントローラアーキテクチャについてさらに詳細には、G. Krasner and S. T. Pope, "A Cookbook for Using the Model View Controller User Interface Paradigm in Smalltalk-80", Journal of Object Oriented Programming, August/September 1988、に記載されている。
Ｍ／Ｖ／Ｃアーキテクチャでは、データ（モデル）は、データの表示（ビュー）およびデータを操作するイベント（コントローラ）から分離される。同様に、本発明のシステムにおける文書は、データを操作し見るためのユーザインタフェース／プログラムにそのデータを関連づける糊（グルー）として作用する。
本発明は、ＸＭＬ構文を利用して、デバイス記述スキーマを、ＸＭＬ文書型定義（ＤＴＤ）として作成する。ＸＭＬは、構造化された情報を含む文書のためのマークアップ言語である。これは、ＳＧＭＬのサブセットであり、階層的な名前付けされた値と、他の文書を参照するための高度な手段の形で、自己記述型のカスタムマークアップを提供する。ＸＳＬ(Extensible Style Sheets)やＸＬｉｎｋ(Extensible Linking Language)のような同類のプロトコルとともに、ＸＭＬは、付随する文書スキーマ（文書型定義：ＤＴＤ）のグループを指定し、発見し、結合する能力を提供する。しかし、ＨＴＭＬとは異なり、ＸＭＬにおけるタグのセットはフレキシブルであり、タグのセマンティクスは、その文書に付随するＤＴＤによって定義される。Resource Description Format、Dublin CoreおよびＸＭＬ−Ｄａｔａのような他のメタデータマークアップ言語も提案されている。
本発明のフレームワーク内では、デバイスあるいはサービスは、自己の記述スキーマを、ＸＭＬ文書と、それに伴うＤＴＤおよびスタイルシートとして作成する。このスキーマは、言語独立なサービス記述のため、ならびに、ユーザインタフェース（プログラム）をサービスオブジェクトに、およびその逆にマッピングするための、マークアップタグを提供する。また、スキーマは、サービスのインタフェースをＸＭＬ／ＸＳＬ定義内に組み込むので、パーサは、ユーザアプリケーションにコードをダウンロードすることを必要とせずに、これらのインタフェースを読み出すことができる。例えば、電灯スイッチのための＜ＯＮ＞タグは、デバイスがメソッド呼出しおよびその他のイベントをリスンするアドレスおよびポート番号を示すことが可能である。
ユーザインタフェースをこれらのサービス記述から生成するために、ＸＭＬパーサが、クライアントユーザアプリケーションによって使用される。クライアントは、語彙的な型をユーザインタフェースウィジェットにマッピングし、ＸＭＬ／ＸＳＬを解析した後、ネットワークの現在のコンフィグレーションに対するユーザインタフェースを生成する。ユーザ（あるいはユーザアプリケーション）は、そのデバイスに対応する動的に生成されるＵＩウィジェットを単にクリックすることによって、任意のネットワークデバイスの状態を変更することができる。このアクションは、ユーザのマシン上で現在のＵＩ状態を変更するとともに、適当なコマンド（デバイスベンダにより定義されＸＭＬ文書に埋め込まれる）を実行のためにデバイスに送る。本発明の実施例では、この目的のために、ＪａｖａTMで書かれたパブリックドメインのＸＭＬパーサと、Internet ExplorerTM 5.0のようなＸＭＬ対応ウェブブラウザが使用される。
以上、本発明について、その好ましい実施例を用いて説明したが、当業者には容易に認識されるように、本発明の技術的範囲および技術思想から離れることなく、形式および細部におけるさまざまな変更が可能である。
アクティブコンフィグレーションフレームワークのインフラストラクチャの図である。 アクティブコンフィグレーションフレームワークの全体設計図である。 ２つのプラグアンドプレイブローカ間の通信を示す図である。 プラグアンドプレイブローカの内部表現を示す図である。 サービス発見（ディスカバリ）手続きを示す図である。 アクティブコンフィグレーションフレームワークの実装例の図である。 アクティブコンフィグレーションインタフェースモデルの図である。
符号の説明
１０１ ネットワーク
１０２ 実行環境
１０３ ユーザアプリケーション
１０４ ＰｎＰブローカ
２０１ ゲートウェイデバイス
２０２ ユーザアプリケーション
２０３ ダミーデバイス
２０４ セキュリティ実施機構
２０５ ネットワークノード
３０１ ＰｎＰブローカ
３０２ ＰｎＰブローカインタフェース
３０３ ＰｎＰブローカ間プロトコル
３０４ サービスディスカバリ／アベイラビリティエージェント
３０５ サービスレジストリ
３０６ サービスセッション管理エージェント
３０７ サービスロケーションプロトコル（ＳＬＰ）サービスエージェント
３０８ ＳＬＰユーザエージェント
４０４ ＰｎＰブローカ間プロトコル
４０６ サービスユニット
５０１ ＰｎＰブローカ
５０２ ユーザエージェント（ＵＡ）
５０３ ＰｎＰブローカ
５０４ サービスエージェント（ＳＡ）
５０７ ブロードキャストによるディスカバリ
５０８ ＳＬＰディレクトリ
５０９ ＬＤＡＰディレクトリ
５１０ 変換スキーマ
５１１ ディレクトリエージェント（ＤＡ）
５１２ サービス
６０１ テレビジョン
６０２ ＨｏｍｅＰＮＡクラスタ
６０３ ホームＰＣ
６０４ 電話機
６０５ レジデンシャルゲートウェイ
６０６ ｘＤＳＬクラスタ
６０７ ホームＰＣ
６０８ ブリッジ
６０９ Ｊｉｎｉクラスタ
６１０ ＵＳＢクラスタ
６１１ スピーカ
６１２ ネットワークカメラ
６１３ Ｘ−１０クラスタ
６１４ 白熱電球
６１５ セキュリティマネージャ
６１６ イーサネットクラスタ
６１７ ディジタルカメラ
６１８ ウェブパネル
６１９ イーサネットハブ
６２０ ホームＰＣ
７０１ デバイス／サービス
７０２ インタフェース定義
７０３ ユーザアプリケーション
７０４ 変更
７０５ アナウンス
７０６ 参照
１１０４ リモートＰｎＰブローカ

Claims (15)

  1. （ａ）少なくとも１つのサービスと、
    （ｂ）サービスエージェントと、
    （ｃ）ディレクトリエージェントと、
    （ｄ）ユーザエージェントと、を有し、
    前記サービスエージェントは、前記少なくとも１つのサービスのタイプおよび属性を前記ディレクトリエージェントに登録し、
    前記ユーザエージェントは、ユーザアプリケーションによって要求されるサービスのタイプおよび属性を前記ディレクトリエージェントに送信し、
    前記ディレクトリエージェントは、前記要求されるサービスのタイプおよび属性を、前記少なくとも１つのサービスのタイプおよび属性と照合して、前記少なくとも１つのサービスのアドレスを前記ユーザエージェントに返すことを特徴とするアクティブコンフィグレーションフレームワーク。
  2. （ａ）少なくとも１つのサービスと、
    （ｂ）サービスエージェントと、
    （ｃ）ディレクトリエージェントとを有するアクティブコンフィグレーションフレームワークにおいて、
    前記サービスエージェントは、前記少なくとも１つのサービスのタイプおよび属性を前記ディレクトリエージェントに登録し、
    前記ディレクトリエージェントは、ユーザアプリケーションによって要求されるサービスのタイプおよび属性を、前記少なくとも１つのサービスのタイプおよび属性と照合して、前記少なくとも１つのサービスのアドレスを返し、
    前記少なくとも１つのサービスは、ゲートウェイおよびデバイスクラスタを有し、
    前記ゲートウェイは、前記デバイスクラスタを前記サービスエージェントに接続し、
    前記サービスエージェントは、前記ゲートウェイを通じて、前記デバイスクラスタと通信することを特徴とするアクティブコンフィグレーションフレームワーク。
  3. 前記アクティブコンフィグレーションフレームワークは、実行環境をさらに有し、
    前記アプリケーションは、前記実行環境で動作することを特徴とする請求項１または２に記載のアクティブコンフィグレーションフレームワーク。
  4. 前記実行環境はＪａｖａ（登録商標）仮想マシンであることを特徴とする請求項３に記載のアクティブコンフィグレーションフレームワーク。
  5. 前記実行環境はＷｉｎｄｏｗｓTMベースのマシンであることを特徴とする請求項３に記載のアクティブコンフィグレーションフレームワーク。
  6. ネットワークデバイスの追加に応答してフレームワークの自動再構成を行う方法において、
    前記ネットワークデバイスは、少なくとも１つのサービスを提供し、
    前記フレームワークは、サービスエージェント、ユーザエージェントおよびディレクトリエージェントを有し、
    前記方法は、
    （ａ）前記サービスエージェントが、提供されるサービスのタイプおよび属性を前記ディレクトリエージェントに登録するステップと、
    （ｂ）前記ユーザエージェントは、ユーザアプリケーションによって要求されるサービスのタイプおよび属性を前記ディレクトリエージェントに送信するステップと、
    （ｃ）前記ディレクトリエージェントが、前記要求されるタイプおよび属性を、前記提供されるサービスのタイプおよび属性と照合して、前記提供されるサービスのアドレスを前記ユーザエージェントに返すステップと、
    を有することを特徴とする、ネットワークデバイスの追加に応答してフレームワークの自動再構成を行う方法。
  7. ネットワークデバイスの追加に応答してフレームワークの自動再構成を行う方法において、
    前記ネットワークデバイスは、少なくとも１つのサービスを提供し、
    前記フレームワークは、サービスエージェントおよびディレクトリエージェントを有し、
    前記方法は、
    （ａ）前記サービスエージェントが、提供されるサービスのタイプおよび属性を前記ディレクトリエージェントに登録するステップと、
    （ｂ）前記ディレクトリエージェントが、ユーザアプリケーションによって要求されるタイプおよび属性を、前記提供されるサービスのタイプおよび属性と照合して、前記提供されるサービスのアドレスを返すステップと、
    を有し、
    前記ステップ（ａ）は、
    （１）ゲートウェイが、前記ネットワークデバイスのアベイラビリティをチェックするステップと、
    （２）前記ゲートウェイが、前記提供されるサービスのタイプおよび属性を前記サービスエージェントに登録するステップと、
    （３）前記サービスエージェントが、前記提供されるサービスのタイプおよび属性を前記ディレクトリエージェントに登録するステップと、
    を有することを特徴とする方法。
  8. セッション管理エージェントが、前記アドレスを用いて、前記ユーザアプリケーションと前記ネットワークデバイスの間の通信セッションを確立するステップをさらに有することを特徴とする請求項６または７に記載の方法。
  9. フレームワークに挿入されたデバイスによって実行されるサービスのための通信インタフェースを生成する方法において、
    前記インタフェースは、ユーザアプリケーションによって、前記サービスを利用するために使用され、
    前記方法は、
    （ａ）ＸＭＬ文書、文書型定義、またはスタイルシートのうちの少なくとも１つを含む、前記デバイスによって提供されるサービスのサービス記述スキーマを生成するステップと、
    （ｂ）ＸＭＬパーサを用いて、前記サービス記述スキーマから、前記サービスのための通信インタフェースを生成するステップと、
    を有し、
    前記ステップ（ｂ）において、前記デバイスによって生成されるサービス記述スキーマは、ユーザインタフェースウィジェットのセットにマッピングされ、
    ユーザは、実行のために前記デバイスにコマンドを送るユーザインタフェースウィジェットをクリックすることによって、前記デバイスの状態を変えることができることを特徴とする、フレームワークに挿入されたデバイスによって実行されるサービスのための通信インタフェースを生成する方法。
  10. 前記サービス記述スキーマは、前記サービスのためのデータおよび制御フロー仕様を含むことを特徴とする請求項９に記載の方法。
  11. フレームワークに挿入されたデバイスによって実行されるサービスのための通信インタフェースを生成する方法において、
    前記インタフェースは、ユーザアプリケーションによって、前記サービスを利用するために使用され、
    前記方法は、
    （ａ）ＸＭＬ文書、文書型定義、またはスタイルシートのうちの少なくとも１つを含む、前記デバイスによって提供されるサービスのサービス記述スキーマを生成するステップと、
    （ｂ）ＸＭＬパーサを用いて、前記サービス記述スキーマから、前記サービスのための通信インタフェースを生成するステップと、
    を有し、
    前記ステップ（ｂ）において、前記デバイスによって生成されるサービス記述スキーマは、前記サービスのための通信インタフェースを表すオブジェクトの階層にマッピングされ、
    前記サービスは、前記オブジェクトの階層を用いて、前記ユーザアプリケーションによって利用されることを特徴とする方法。
  12. 前記オブジェクトの階層の構造は、前記ユーザアプリケーションが前記デバイスを利用する時点での前記デバイスの機能に基づいて決定されることを特徴とする請求項１１に記載の方法。
  13. 前記ＸＭＬパーサは、ＸＭＬ対応ウェブブラウザであることを特徴とする請求項１２に記載の方法。
  14. フレームワークに挿入されたデバイスを制御する方法において、該方法は、
    （ａ）前記デバイスが、ＸＭＬ文書、文書型定義、またはスタイルシートのうちの少なくとも１つを含む、前記デバイスのデバイス記述スキーマを生成するステップと、
    （ｂ）ユーザアプリケーションが、前記デバイス記述スキーマを編集し、編集されたデバイス記述スキーマを前記デバイスに反映するステップとを有し、
    前記デバイスは、前記編集されたデバイス記述スキーマに従って状態を変更することを特徴とする、フレームワークに挿入されたデバイスを制御する方法。
  15. （ａ）少なくとも１つのサービスと、
    （ｂ）サービスエージェントと、
    （ｃ）ユーザエージェントと、を有し、
    前記ユーザエージェントは、ユーザアプリケーションによって要求されるサービスのタイプおよび属性を前記サービスエージェントに送信し、
    前記サービスエージェントは、前記要求されるサービスのタイプおよび属性を、前記少なくとも１つのサービスのタイプおよび属性と照合して、前記少なくとも１つのサービスのアドレスを前記ユーザエージェントに返すことを特徴とするアクティブコンフィグレーションフレームワーク。
JP2004152883A 2000-04-10 2004-05-24 プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 Expired - Fee Related JP3915797B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US54639700A 2000-04-10 2000-04-10

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2000371402A Division JP3711866B2 (ja) 2000-04-10 2000-12-06 プラグアンドプレイ機能を有するフレームワークおよびその再構成方法

Publications (2)

Publication Number Publication Date
JP2004334896A JP2004334896A (ja) 2004-11-25
JP3915797B2 true JP3915797B2 (ja) 2007-05-16

Family

ID=24180256

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2000371402A Expired - Fee Related JP3711866B2 (ja) 2000-04-10 2000-12-06 プラグアンドプレイ機能を有するフレームワークおよびその再構成方法
JP2004152883A Expired - Fee Related JP3915797B2 (ja) 2000-04-10 2004-05-24 プラグアンドプレイ機能を有するフレームワークおよびその再構成方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2000371402A Expired - Fee Related JP3711866B2 (ja) 2000-04-10 2000-12-06 プラグアンドプレイ機能を有するフレームワークおよびその再構成方法

Country Status (1)

Country Link
JP (2) JP3711866B2 (ja)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7343428B2 (en) 2001-09-19 2008-03-11 International Business Machines Corporation Dynamic, real-time integration of software resources through services of a content framework
US7035944B2 (en) 2001-09-19 2006-04-25 International Business Machines Corporation Programmatic management of software resources in a content framework environment
JP4518719B2 (ja) 2001-12-10 2010-08-04 ソニー株式会社 データ処理システム、情報処理装置、および方法、並びにコンピュータ・プログラム
AU2002353303A1 (en) 2002-01-08 2003-07-24 Koninklijke Philips Electronics N.V. Controlling application devices simultaneously
US7603469B2 (en) 2002-01-15 2009-10-13 International Business Machines Corporation Provisioning aggregated services in a distributed computing environment
JP3756457B2 (ja) * 2002-03-19 2006-03-15 株式会社エヌ・ティ・ティ・データ アクセス制御付ディレクトリ機能装置及びプログラム
US7987489B2 (en) 2003-01-07 2011-07-26 Openpeak Inc. Legacy device bridge for residential or non-residential networks
JP4284499B2 (ja) * 2003-03-07 2009-06-24 ソニー株式会社 デバイス管理方法およびデバイス管理システム
JP2004289561A (ja) * 2003-03-24 2004-10-14 Sony Corp ネットワーク接続の管理方法および電子機器
JP2010055620A (ja) * 2003-05-28 2010-03-11 Sharp Corp アプリケーション処理装置
JP4818590B2 (ja) * 2003-05-28 2011-11-16 シャープ株式会社 サービス利用端末、携帯電話端末、テレビジョン受像端末、コネクタ提供サーバ、およびコネクタデータのデータ構造
EA015549B1 (ru) 2003-06-05 2011-08-30 Интертраст Текнолоджис Корпорейшн Переносимая система и способ для приложений одноранговой компоновки услуг
US7418486B2 (en) * 2003-06-06 2008-08-26 Microsoft Corporation Automatic discovery and configuration of external network devices
US7467399B2 (en) 2004-03-31 2008-12-16 International Business Machines Corporation Context-sensitive confidentiality within federated environments
JP4645164B2 (ja) 2004-11-12 2011-03-09 セイコーエプソン株式会社 ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御
US8275793B2 (en) 2005-04-29 2012-09-25 Microsoft Corporation Transaction transforms
US8418132B2 (en) 2005-04-29 2013-04-09 Microsoft Corporation Application description language
US8132148B2 (en) 2005-04-29 2012-03-06 Microsoft Corporation XML application framework
US7882256B2 (en) 2005-05-24 2011-02-01 Panasonic Corporation Gateway device and control device
WO2006126355A1 (ja) * 2005-05-24 2006-11-30 Matsushita Electric Industrial Co., Ltd. ゲートウェイ装置及び制御装置
EP1763198A3 (en) 2005-09-07 2007-04-04 Seiko Epson Corporation Control of network plug-and-play compliant device
JP4768369B2 (ja) * 2005-09-14 2011-09-07 日立オムロンターミナルソリューションズ株式会社 デバイス制御システム
KR100717032B1 (ko) 2005-09-30 2007-05-10 삼성전자주식회사 ＵＰｎＰ를 따르지 않는 개체를 ＵＰｎＰ 디바이스 또는컨텐트로 표현하는 방법 및 장치
US9626667B2 (en) 2005-10-18 2017-04-18 Intertrust Technologies Corporation Digital rights management engine systems and methods
CN102073819B (zh) 2005-10-18 2013-05-29 英特托拉斯技术公司 数字权利管理的方法
EP1793565A1 (en) 2005-12-02 2007-06-06 Seiko Epson Corporation Network plug-and-play compliant network relay control
JP2007179119A (ja) * 2005-12-27 2007-07-12 Hitachi Ltd 計算機システム
JP4349391B2 (ja) 2006-08-07 2009-10-21 セイコーエプソン株式会社 画像表示システム
US20090083765A1 (en) * 2007-09-20 2009-03-26 Microsoft Corporation Accessing device-hosted services from scripting and other programming environments
JP2009205612A (ja) * 2008-02-29 2009-09-10 Kddi R & D Laboratories Inc サービス状態提示システム及びサービス状態提示方法
US8606967B2 (en) * 2008-06-17 2013-12-10 Qualcomm Incorporated Methods and apparatus for proxying of devices and services using overlay networks
JP5611576B2 (ja) * 2009-12-03 2014-10-22 ソニー株式会社 情報処理装置、および情報処理方法、並びにプログラム
EP2697929A4 (en) 2011-04-11 2014-09-24 Intertrust Tech Corp INFORMATION SECURITY SYSTEMS AND METHODS
JP2012022715A (ja) * 2011-10-21 2012-02-02 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
EP2995100B1 (en) 2013-05-06 2021-07-28 Convida Wireless, LLC Semantics support and management in m2m systems
CA2916261C (en) * 2013-06-26 2018-04-10 Amazon Technologies, Inc. Managing client access to a plurality of computing systems
JP2014002781A (ja) * 2013-09-02 2014-01-09 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
CN107431726B (zh) * 2015-02-20 2020-07-28 康维达无线有限责任公司 消息总线服务目录
WO2023039756A1 (en) * 2021-09-15 2023-03-23 Siemens Aktiengesellschaft Industrial data integration device, method and computer readable storage medium

Also Published As

Publication number Publication date
JP2004334896A (ja) 2004-11-25
JP2001290724A (ja) 2001-10-19
JP3711866B2 (ja) 2005-11-02

Similar Documents

Publication Publication Date Title
JP3915797B2 (ja) プラグアンドプレイ機能を有するフレームワークおよびその再構成方法
US8423671B2 (en) Middleware device and method of supporting compatibility of devices in home network
US7668908B2 (en) System and method for generalized and distributed scalable eventing system
US7640329B2 (en) Scaling and extending UPnP v1.0 device discovery using peer groups
US7647394B2 (en) Scaling UPnP v1.0 device eventing using peer groups
US6842903B1 (en) System and method for providing dynamic references between services in a computer system
US7272636B2 (en) Peer group name server
JP5048064B2 (ja) ユニバーサル・プラグ・アンド・プレー発見項目のｓｍｂ位置に対するマッピング
US7526482B2 (en) System and method for enabling components on arbitrary networks to communicate
US20030191802A1 (en) Reshaped UDDI for intranet use
US20020112058A1 (en) Peer networking host framework and hosting API
US9323587B2 (en) Method and system for automatic detecting and resolving APIs
US20040133896A1 (en) Network device application interface
EP1198102B1 (en) Extendable provisioning mechanism for a service gateway
US7181490B1 (en) Method and apparatus for mapping network events to names of network devices
US7590618B2 (en) System and method for providing location profile data for network nodes
JP4799005B2 (ja) 情報処理装置
KR100888478B1 (ko) 액션 처리 방법, 피제어 장치의 제어 방법, 피제어 장치 및제어 포인트
US7685303B2 (en) Object-oriented discovery framework
KR20080000310A (ko) 홈네트워크 간의 정보 공유 시스템 및 정보 공유 방법,그리고 정보 공유 생성 방법
US7133872B2 (en) Method and system for unifying component metadata
KR100665436B1 (ko) 홈네트워크를 통한 파일 서버 관리 방법
Moller et al. Enhancing Jini's lookup service using XML-based service templates
Hsu et al. Widget-based framework for web service discovery on multiple home social network
Hajamohideen A model for web service discovery and invocation in jxta

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061010

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061211

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070116

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070129

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100216

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110216

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110216

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120216

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120216

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130216

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130216

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140216

Year of fee payment: 7

LAPS Cancellation because of no payment of annual fees