(57)【要約】【課題】サービス検出およびサービス公開のためのシステムおよびメソッドを提供すること。【解決手段】アプリケーションプログラム群が、サービス検出アプリケーションプログラミングインタフェースに対して、サービス検出、サービス公開、およびサブスクリプションを求める要求を書き込む。サービス検出アプリケーションプログラミングインタフェースは、１つまたは複数のより低レベルプロトコルを呼び出して、検出要求、公開要求、および／またはサブスクリプション要求を満たす。より低いレイヤのプロトコルから取り出されたサービス情報が、整合性のあるデータモデルにフォーマットされて、クライアントアプリケーションに戻される。さらに、サービス情報は、サービス検出ＡＰＩと通信するように接続された検出保持サービスによって管理される永続データストアの中に格納されることが可能である。【選択図】図２
2011103131.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング環境においてサービスイベントにサブスクライブする方法であって、
コンピュータ上で実行されるアプリケーションプログラムにおいて、
検索可能なクエリドメインを明らかにする範囲を定義するステップと、
シンプルフィルタ及びリッチフィルタを含むフィルタを定義するステップであって、前記シンプルフィルタは、サービスタイプ、サービスインターフェース、および／またはサービス特性による探索可能なクエリドメインの表現を提供し、前記リッチフィルタは、クエリセマンティクスを用いて探索可能なクエリドメインの表現を提供するものであるステップと、
コールバック機能を定義するステップと、
第１のアプリケーションプログラミングインタフェースに対するサブスクリプション要求を開始するステップとを備え、
前記第１のアプリケーションプログラミングインタフェースにおいて、前記探索要求を解析するステップと、
少なくとも１つの低レベルＡＰＩコールを実行してサービスイベントにサブスクライブするステップと、
サービスイベントからの情報を前記アプリケーションプログラムに戻すステップとを備えることを特徴とする方法。
【請求項２】
取り出されたサービス情報をサービスエントリオブジェクトデータ形式にフォーマットするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記少なくとも１つの低レベルＡＰＩから取り出された情報を永続データストアの中に保存するステップをさらに備えることを特徴とする請求項２に記載の方法。
【請求項４】
コンピューティング環境において利用可能なサービスに関する情報を管理するためのシステムにおいて、
アプリケーションからのサービスクエリを受け入れるように構成された第１のアプリケーションプログラミングインタフェースであって、第１のサービスクエリプロトコルでサービスクエリを受け取り、前記サービスクエリを処理し、第２のプロトコルに対して少なくとも１つの対応するサービスクエリを開始する第１のアプリケーションプログラミングインタフェースと、
前記第１のアプリケーションプログラミングインタフェースと通信するように接続された、シンプルフィルタ及びリッチフィルタを有する検出保持サービスであって、前記第１のアプリケーションプログラミングインタフェースからサービス情報を受け取り、前記サービス情報をデータストアの中に格納する検出保持サービスと
を備えることを特徴とするシステム。
【請求項５】
前記第１のアプリケーションプログラミングインタフェースは、少なくとも１つのディレクトリベースのプロトコル、および、少なくとも１つのアドホックプロトコルを提供することを特徴とする請求項４に記載のシステム。
【請求項６】
前記シンプルフィルタは、サービスタイプ、サービスインターフェース、および／またはサービス特性による前記サービスクエリの表現を提供することを特徴とする請求項４に記載のシステム。
【請求項７】
前記リッチフィルタは、クエリセマンティクスを用いて前記サービスクエリの表現を提供することを特徴とする請求項４に記載のシステム。
【請求項８】
前記第１のアプリケーションプログラミングインタフェースは、範囲マップを実装し、前記範囲マップは、システム管理者が構成することができることを特徴とする請求項４に記載のシステム。
【請求項９】
コンピューティング環境において利用可能なサービスを公開するための方法であって、
アプリケーションプログラムにおいて、
サービスエントリオブジェクトを定義するステップと、
公開範囲を定義するステップと、
前記サービスに固有キーを割り当てるステップと、
前記サービスにサービスタイプを割り当てるステップと、
前記サービスのプロパティを定義するステップと、
前記サービスのエンドポイントを定義するステップと、
第１のアプリケーションプログラミングインタフェースに対して公開要求を開始するステップとを備え、
前記第１のアプリケーションプログラミングインタフェースにおいて、
複数の探索要求を解析するステップと、
少なくとも１つの低レベルＡＰＩコールを実行して前記サービスを公開するステップとを含むことを特徴とする方法。
【請求項１０】
前記サービスエントリオブジェクトは、公開されるサービスに対する記述プロパティ及び識別プロパティを提供することを特徴とする請求項９に記載の方法。
【請求項１１】
コンピューティング環境において公開済みサービスを削除するための方法であって、
アプリケーションプログラムにおいて、
サービスエントリオブジェクトを定義するステップと、
前記公開済みサービスに対応するキーを指定するステップと、
前記公開済みサービスの削除範囲を定義するステップと、
第１のアプリケーションプログラミングインタフェースに対して削除要求を開始するステップとを備え、
前記第１のアプリケーションプログラミングインタフェースにおいて、
探索要求を解析するステップと、
少なくとも１つの低レベルＡＰＩコールを実行して前記公開済みサービスを削除するステップとを含むことを特徴とする方法。
【請求項１２】
取り出されたサービス情報をサービスエントリオブジェクトデータ形式にフォーマットするステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記削除範囲は、モニタする特定の低レベルプロトコルを指定することを特徴とする請求項１１記載の方法。
【請求項１４】
コールバック機能を定義するステップをさらに含み、
前記コールバック機能は、合致するイベントが生ずるとサービスエントリオブジェクトを受け取ることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記記述プロパティ及び識別プロパティは、
サービス名、サービス記述、特定のサービスのための複数のネットワークアドレスを含む複数のエンドポイント、前記特定のサービスを識別するキー、サービス及びデバイス特性に対する名前−値ペアの拡張可能なリストを含む複数のプロパティ、および、複数のサービスを提供するエンティティに対する識別子を含むプロバイダを含むことを特徴とする請求項１１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
説明する本件は、デジタルコンピューティングに関し、より詳細には、コンピューティングデバイスおよびコンピューティングネットワークにおけるサービス検出（ｄｉｓｃｏｖｅｒｙ）に関する。
【背景技術】
【０００２】
コンピューティングデバイス上およびコンピュータネットワーク上で実行されるアプリケーションプログラム群は、そのコンピューティングデバイスまたはコンピューティングネットワークに接続された他の物理デバイス群または論理デバイス群によって提供されるサービスの使用を要する可能性がある。現在、アプリケーションプログラム群は、ローカルコンピューティングデバイス上で、またはコンピュータネットワーク内の複数のデバイスにわたってサービスおよびデバイスを検出し、列挙し、記述するのに、多種多様なアプリケーションプログラミングインタフェース（ＡＰＩ）、プロトコル、およびオブジェクトモデルを使用する。サービスおよびデバイスを検出し、列挙し、記述するのに利用可能な機構は、関与するサービスおよびデバイスが概念上、類似している場合でも、大きく異なる。
【０００３】
例えば、アプリケーションが、利用可能なプリンタを列挙することを求める状況を考えてみる。管理された企業環境内で実行されている場合、アプリケーションは、登録済みの企業プリンタ群を検出するのに、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）を使用してＭｉｃｒｏｓｏｆｔ  Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙ（登録商標）ディレクトリサービスストアと通信し、印刷キューサーバ群を検出するのにＮｅｔＢＴを使用し、パーソナルエリアネットワークプリンタ群を検出するのにＢｌｕｅｔｏｏｔｈ（商標）を使用することを必要とする可能性がある。さらに、アプリケーションは、直接接続プリンタ群を検出するのにデバイス管理ＡＰＩ群を呼び出し、ＵＰｎＰ（商標）プリンタ群を検出するのにＵＰｎＰ（商標）ＡＰＩ群を呼び出すことを必要とする可能性がある。以上の機構のそれぞれは、特定のＡＰＩ、プロトコル、およびクエリセマンティクス（ｓｅｍａｎｔｉｃｓ）の理解を要する。
【０００４】
アプリケーションがサービスを検出し、列挙し、記述するのに要求されるＡＰＩおよびプロトコルの数により、ソフトウェア開発の作業が複雑になる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【０００６】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、コンピューティングデバイスおよびコンピューティングネットワークにおけるサービス検出およびサービス公開を提供することにある。
【課題を解決するための手段】
【０００７】
本明細書で説明し、特許請求の範囲に記載するインプリメンテーションは、検出作業および公開作業を単純化する一様なインタフェースを提供することにより、以上の問題、およびその他の問題に対処する。一様なインタフェースは、基礎にあるプロトコルが活用されることを可能にし、アプリケーション開発者が低レベルプロトコルを理解する必要性をなくす。一様なインタフェースは、サービスの整合性のある高レベルの抽象化、ならびに多種多様なより低いレベルのＡＰＩ、プロトコル、ストア、およびネットワーク環境にわたるサービスの詳細の検出および公開を目標とする、関連する動作を提供する。
【０００８】
１つの典型的なインプリメンテーションでは、コンピューティング環境において利用可能なサービスを検出するためのメソッドが提供される。メソッドは、アプリケーションプログラムにおいて、検出範囲を定義すること、検出フィルタを定義すること、および第１のアプリケーションプログラミングインタフェースに対する探索要求を開始することを含み、第１のアプリケーションプログラミングインタフェースにおいて、探索要求を解析すること、要求された探索範囲および探索フィルタに合致するサービス情報を取り出すこと、およびそのサービス情報をアプリケーションプログラムに戻すことを含む。
【０００９】
別の典型的なインプリメンテーションでは、コンピューティング環境において利用可能なサービスを公開するためのメソッドが提供される。メソッドは、アプリケーションプログラムにおいて、サービスエントリオブジェクトを定義すること、公開範囲を定義すること、固有キーをサービスに割り当てること、サービスタイプを割り当てること、サービスのプロパティを定義すること、サービスのエンドポイントを定義すること、および第１のアプリケーションプログラミングインタフェースに対する公開要求を開始することを含み、第１のアプリケーションプログラミングインタフェースにおいて、公開要求を解析すること、および少なくとも１つの低レベルＡＰＩコールを実行してサービスを公開することを含む。
【００１０】
別の典型的なインプリメンテーションでは、コンピューティング環境において公開済みのサービスを削除するためのメソッドが提供される。メソッドは、アプリケーションプログラムにおいて、サービスエントリオブジェクトを定義すること、公開済みのサービスに対応するキーを指定すること、削除範囲を定義すること、および第１のアプリケーションプログラミングインタフェースに対する削除要求を開始することを含み、第１のアプリケーションプログラミングインタフェースにおいて、削除要求を解析すること、および少なくとも１つの低レベルＡＰＩコールを実行してサービスを削除することを含む。
【００１１】
別の典型的なインプリメンテーションでは、コンピューティング環境におけるサービスイベントにサブスクライブするメソッドが提供される。メソッドは、アプリケーションプログラムにおいて、範囲を定義すること、フィルタを定義すること、コールバック機能を定義すること、および第１のアプリケーションプログラミングインタフェースに対するサブスクライブ要求を開始することを含み、第１のアプリケーションプログラミングインタフェースにおいて、サブスクライブ要求を解析すること、少なくとも１つの低レベルＡＰＩコールを実行してサービスイベントにサブスクライブすること、およびサービスイベントからの情報をアプリケーションプログラムに戻すことを含む。
【００１２】
別の典型的な実施形態では、コンピューティング環境において利用可能なサービスに関する情報を管理するためのシステムが提供される。システムは、アプリケーションからのサービスクエリを受け入れるように構成され、第１のサービスクエリプロトコルでサービスクエリを受け取り、そのサービスクエリを処理し、第２のプロトコルに対して少なくとも１つの対応するサービスクエリを開始する第１のアプリケーションプログラミングインタフェースと、第１のアプリケーションプログラミングインタフェースと通信するように接続され、第１のアプリケーションプログラミングインタフェースからサービス情報を受け取り、そのサービス情報をデータストアの中に格納する検出保持サービスとを含む。
【図面の簡単な説明】
【００１３】
【図１】典型的なコンピューティングデバイスを示す概略図である。
【図２】典型的なソフトウェアアーキテクチャを示すブロック図である。
【図３】サービス検出の諸動作を示す流れ図である。
【図４】サービス公開の諸動作を示す流れ図である。
【図５】サービス削除の諸動作を示す流れ図である。
【図６】サービスイベントにサブスクライブするための諸動作を示す流れ図である。
【図７】具象範囲と抽象範囲の間の関係を示すブロック図である。
【図８】Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙプロトコルに対してＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトを使用して毎分５０ページを印刷するカラープリンタ群を探し出すのに、どのようにＣ＃プログラミング言語を使用するかを例示する擬似コードである。
【図９】Ｗｅｂサービスを探し出すのに、どのようにＣ＃プログラミング言語を使用するかを例示する擬似コードである。
【図１０】ＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトおよびＵＤＤＩプロトコルを使用して特定のｔＭｏｄｅｌインタフェースをサポートするサービスを探し出す、Ｃ＃プログラミング言語の用法を例示する擬似コードである。
【図１１】ＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトおよびＵＤＤＩプロトコルを使用して特定のｔＭｏｄｅｌインタフェースをサポートするサービスを探し出す、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【図１２】Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙに対してＲｉｃｈＦｉｌｔｅｒを使用して、Ｏｆｆｉｃｅ  Ｐｒｉｎｔｅｒのような名前でプリンタを探し出す、Ｃ＃プログラミング言語の用法を例示する擬似コードである。
【図１３】Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙに対してＲｉｃｈＦｉｌｔｅｒを使用して、Ｏｆｆｉｃｅ  Ｐｒｉｎｔｅｒのような名前でプリンタを探し出す、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【図１４】ＳＳＤＰプロトコルを使用して、特定の固有識別子で識別される特定のタイプのサービスを公開する、Ｃ＃プログラミング言語の用法を例示する擬似コードである。
【図１５】ＳＳＤＰプロトコルを使用して、特定の固有識別子で識別される特定のタイプのサービスを公開する、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【図１６】ＳＳＤＰプロトコルからサービスを削除するＣ＃プログラミング言語の用法を例示する擬似コードである。
【図１７】ＳＳＤＰプロトコルからサービスを削除するＶｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【図１８】ＳｉｍｐｌｅＦｉｌｔｅｒを使用して、ＳＳＤＰプロトコルを使用する特定のタイプのイベントに関して登録する、Ｃ＃プログラミング言語の用法を例示する擬似コードである。登録されたコールバック機能は、フィルタに合致するイベントごとに呼び出され、対応するＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトがそのハンドラに提供される。
【図１９】ＳｉｍｐｌｅＦｉｌｔｅｒを使用して、ＳＳＤＰプロトコルを使用する特定のタイプのイベントに関して登録する、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【発明を実施するための形態】
【００１４】
本明細書で説明するのは、サービス検出およびサービス公開のための典型的なメソッドおよびソフトウェアアーキテクチャである。本明細書で説明するメソッドは、コンピュータ可読媒体上の論理命令として実現することができる。プロセッサ上で実行されると、その論理命令により、汎用コンピューティングデバイスが、説明するメソッドを実施する専用マシンとしてプログラミングされるようになる。プロセッサは、論理命令によって本明細書に記載するメソッドを実行するように構成された場合、説明するメソッドを実行するための構造を構成する。
【００１５】
典型的な動作環境 
図１は、説明する実施形態による、１つまたは複数のコンピューティングデバイスを実装するのに利用することができる典型的なコンピューティングデバイス１３０の概略図である。コンピューティングデバイス１３０を利用して、説明する実施形態による様々なインプリメンテーションを実施することができる。
【００１６】
コンピューティングデバイス１３０は、１つまたは複数のプロセッサまたは処理装置１３２、システムメモリ１３４、ならびにシステムメモリ１３４からプロセッサ１３２までを含む様々なシステムコンポーネントを結合するバス１３６を含む。バス１３６は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含め、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。始動中などに、コンピューティングデバイス１３０内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１４２が、ＲＯＭ１３８の中に格納される。
【００１７】
コンピューティングデバイス１３０は、ハードディスク（図示せず）に対して読み取りおよび書き込みを行うためのハードディスクドライブ１４４、リムーバブルな磁気ディスク１４８に対して読み取りおよび書き込みを行うための磁気ディスクドライブ１４６、およびＣＤ−ＲＯＭまたは他の光媒体などのリムーバブルな光ディスク１５２に対して読み取りまたは書き込みを行うための光ディスクドライブ１５０をさらに含む。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０は、ＳＣＳＩインタフェース１５４、または他の何らかの適切なインタフェースでバス１３６に接続される。以上のドライブ群、および関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストレージがコンピューティングデバイス１３０に提供される。本明細書で説明する典型的な環境は、ハードディスク、リムーバブルな磁気ディスク１４８、およびリムーバブルな光ディスク１５２を使用するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などの、データを格納することができ、コンピュータがアクセスすることができる他のタイプのコンピュータ可読媒体も、典型的な動作環境において使用することが可能であることを当業者なら理解すべきである。
【００１８】
オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール群１６２、およびプログラムデータ１６４を含め、いくつかのプログラムモジュールが、ハードディスク１４４、磁気ディスク１４８、光ディスク１５２、ＲＯＭ１３８、またはＲＡＭ１４０に格納されることが可能である。ユーザは、キーボード１６６やポインティングデバイス１６８などの入力デバイス群を介して、コマンドおよび情報をコンピューティングデバイス１３０に入力することができる。他の入力デバイス群（図示せず）には、マイク、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどが含まれることが可能である。以上の入力デバイス群、およびその他の入力デバイス群は、バス１３６に結合されたインタフェース１７０を介してプロセッサ１３２に接続される。モニタ１７２、またはその他のタイプのディスプレイデバイスも、ビデオアダプタ１７４のようなインタフェースを介して、バス１３６に接続される。モニタに加えて、パーソナルコンピュータは、通常、スピーカやプリンタなどの他の周辺出力デバイス群（図示せず）も含む。
【００１９】
コンピューティングデバイス１３０は、一般に、リモートコンピュータ１７６などの１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作する。リモートコンピュータ１７６は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることが可能であり、通常、コンピューティングデバイス１３０に関連して前述した要素の多く、またはすべてを含むが、メモリ記憶装置１７８だけを図１に示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１８０およびワイドエリアネットワーク（ＷＡＮ）１８２を含む。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。
【００２０】
ＬＡＮネットワーキング環境で使用される場合、コンピューティングデバイス１３０は、ネットワークインタフェースまたはネットワークアダプタ１８４を介してローカルネットワーク１８０に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピューティングデバイス１３０は、通常、インターネットなどのワイドエリアネットワーク１８２を介して通信を確立するためのモデム１８６、またはその他の手段を含む。内部にあることも、外部にあることも可能なモデム１８６は、シリアルポートインタフェース１５６を介してバス１３６に接続される。ネットワーク化された環境では、コンピューティングデバイス１３０に関連して示したプログラムモジュール群、またはプログラムモジュール群の諸部分は、リモートメモリ記憶装置の中に格納されることが可能である。図示したネットワーク接続は、典型的であり、コンピュータ間で通信リンクを確立するその他の手段も使用することができることが理解されよう。
【００２１】
一般に、コンピューティングデバイス１３０のデータプロセッサ群は、異なる時点でコンピュータの様々なコンピュータ可読記憶媒体の中に格納される命令によってプログラミングされる。プログラム群およびオペレーティングシステム群は、通常、例えば、フロッピー（登録商標）ディスク上またはＣＤ−ＲＯＭ上で配布される。そこから、プログラム群およびオペレーティングシステム群は、コンピュータの２次メモリにインストールされるか、または読み込まれる。実行時に、プログラム群およびオペレーティングシステム群は、コンピュータの主電子メモリに少なくとも部分的に読み込まれる。本明細書で説明する本発明は、以上のタイプ、およびその他の様々なタイプのコンピュータ可読記憶媒体を、そのような媒体が、マイクロプロセッサ、またはその他のデータプロセッサと連携して以下に説明するステップを実施するための命令群またはプログラム群を含む場合に含む。また、本発明は、コンピュータが以下に説明するメソッドおよび技術に従ってプログラミングされている場合、そのコンピュータ自体も含む。
【００２２】
典型的なソフトウェアアーキテクチャの概要 
図２は、図１のシステムメモリ１３４の中に存在することが可能なサービス検出のための典型的なソフトウェアアーキテクチャ２００のブロック図である。このインプリメンテーションでは、システムメモリ１３４は、複数のアプリケーションプログラム２１０を含むことが可能である。ネットワーク化された環境では、アプリケーションプログラム群は、クライアントプログラム群として機能することが可能であるが、ＰＣ環境では、スタンドアロンプログラム群として実行されることが可能である。アプリケーションプログラム群の特定の性質は、重要ではない。
【００２３】
アプリケーションプログラム群２１０は、サービス検出ＡＰＩ２１４を呼び出して、コンピューティング環境において利用可能なサービスを検出する。サービス検出ＡＰＩ２１４は、検出クエリを表現するための高レベルの文法を提供する。文法は、検出クエリを表現するために使用される自然クエリ言語である、ＯＰａｔｈで実装されることが可能である。この高レベルの文法は、基礎にあるプロトコル群２２０〜２３４によって要求される可能性があるより細分性の高い（ｍｏｒｅ  ｇｒａｎｕｌａｒ）、プロトコル固有の表現を要求するのではなく、開発者が探しているサービスを表現するより概念的な機構をソフトウェア開発者に提供する。開発者は、高レベルの文法を使用してクエリを構築することができ、そのクエリが、次に、いくつかの「具象範囲」と呼ばれる特定のプロトコルセットに転送されるか、あるいは、事前定義された、または更新された具象範囲セットである「抽象範囲」を使用することが可能である。サービス検出をサポートすることに加え、システムは、サービス公開／削除、およびイベントの監視をサポートする。
【００２４】
サービス検出ＡＰＩ２１４は、図にプロトコル１  ２２０ないしプロトコル８  ２３４で表す、１つまたは複数の基礎にあるプロトコルを呼び出す。基礎にあるプロトコルの特定の数は、重要ではない。プロトコル２２０〜２３４の一部は、例えば、ＬＤＡＰ、ＵＤＤＩ（Universal Description, Discovery and Integration）、およびドメイン名システム（ＤＮＳ）サーバなどのディレクトリに支えられた（ｄｉｒｅｃｔｏｒｙ−ｂａｃｋｅｄ）プロトコルであることが可能である。その他のプロトコルは、例えば、Ｂｌｕｅｔｏｏｔｈ（商標）、ＵＰｎＰ（商標）、およびＮｅｔＢＴなどの特別な（ａｄ−ｈｏｃ）プロトコルであることが可能である。基礎にあるプロトコル２２０〜２３４の１つまたは複数は、通信接続２３６を使用して、コンピューティング環境において利用可能な他のコンポーネントまたはサービスと通信する。
【００２５】
検出要求に応答して、サービス検出ＡＰＩは、ローカルマシン上、またはネットワーク上で検出された合致するサービスを表すＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトの集合を戻す。ＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトは、システムがサポートする基礎にあるプロトコル群によって戻される妥当な詳細の多くを表すことが可能な、一般化されたデータ構造である。各ＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトは、サービスの単一のインスタンスに相当する。１つのインプリメンテーションでは、ＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトは、（１）サービス名、（２）サービス記述、（３）通常、サービスの１つまたは複数のネットワークアドレスを含むエンドポイント、（４）サービスインスタンスを識別するキー、（５）プロパティ、例えば、サービス特性またはデバイス問合せに関する名前−値ペアの拡張可能なリスト、および（６）プロバイダ、例えば、サービスを提供するエンティティを識別する識別子を含む、記述プロパティおよび識別プロパティを提供する。
【００２６】
検出保持サービス２１２が、サービス検出ＡＰＩ２１４と通信する。とりわけ、検出保持サービス２１２は、特別なプロトコルを介する告知イベントに関して登録する。検出保持サービスは、告知イベントが検出されると通知を受け、サービス告知に関する情報をデータストア２４０内のメモリロケーションの中にコピーする。メモリロケーションの中にサービスの詳細を格納することにより、現在、利用できない可能性があるサービスの検出が可能になる。例えば、プリンタの電源が現在、オフにされている場合でも、そのプリンタに関する詳細が、メモリロケーションの中に登録されていることが可能であり、検出されることが可能である。さらに、サービスクエリは、サービスと通信するプロトコルに限定されない。さらに、メモリロケーションにクエリを行うことのパフォーマンスは、広範なネットワーク検出クエリを発行することより、はるかに良好である可能性がある。
【００２７】
典型的な動作 
典型的なインプリメンテーションでは、サービス検出ＡＰＩ２１４は、サービス検出のためのメソッド、サービス公開のためのメソッド、およびサービスイベント通知にサブスクライブするためのメソッドを提供する。図３は、サービス検出のための諸動作３００を示す流れ図である。動作３１０で、アプリケーションが、範囲を定義し、動作３１５で、アプリケーションは、フィルタを定義し、動作３２０で、アプリケーションは、探索要求を発行する。サービス検出ＡＰＩ２１４が、その探索要求を受け取り、動作３２５で、その探索要求を解析する。オプションの動作３３０で、サービス検出ＡＰＩ２１４は、探索要求が、検出保持サービス２１２の中に格納されている情報を使用して解決可能であるかどうかを判定する。１つのインプリメンテーションでは、検出保持サービス２１２によって管理される情報には、検出保持サービス２１２内の情報の寿命を指定する存続期間（ｔｉｍｅ−ｏｆ−ｌｉｆｅ）インジケータが含まれる。制御および構成に依存して、サービス検出ＡＰＩ２１４は、検出保持サービス２１２にクエリを行って、検出保持サービス２１２がデータストア２４０上で管理する情報を使用して、検出要求を満たすことができるかどうかを判定することができる。検出要求が検出保持サービス２１２を使用して解決可能である場合、制御は、動作３５０に移り、検出保持サービス２１２から取り出されたサービスエントリオブジェクトが、アプリケーションに戻される。
【００２８】
反対に、検出要求が、検出保持サービス２１２によって管理される情報を使用して解決されなかった、または解決可能でない場合、制御は、動作３３５に移り、サービス検出ＡＰＩ２１４が、検出要求を満たすのに要求される低レベルＡＰＩコールを実行する。動作３４０で、低レベルＡＰＩコールから戻されたサービス情報が、サービスエントリオブジェクトにフォーマットされて、オプションの動作３４５で、サービスエントリオブジェクトが、検出保持サービスに転送され、検出保持サービスは、そのサービスエントリオブジェクトをデータストア２４０上に格納することができる。重複検出および削除（ｒｅｍｏｖａｌ）などのサービスエントリ結果をさらに処理し、フィルタ処理するオプションの動作３４７が、実行されることも可能である。動作３５０で、サービスエントリオブジェクトは、動作３５５におけるさらなる処理のためにアプリケーションに戻される。アプリケーションによって実行されるさらなる処理の特定の詳細は、重要ではない。
【００２９】
図４は、サービス公開のための諸動作を示す流れ図である。動作４１０で、アプリケーションが、サービス公開のためのサービスエントリオブジェクトを定義する。動作４１５で、アプリケーションは、サービス公開のための範囲を定義する。動作４２０で、アプリケーションは、固有キーをサービス公開に割り当て、動作４２５で、アプリケーションは、サービスタイプをサービス公開に割り当てる。動作４３０で、アプリケーションは、サービス公開のエンドポイントを定義し、動作４３２で、アプリケーションは、サービス公開のプロパティを定義し、動作４３５で、アプリケーションは、公開要求を生成する。実行されるステップは、公開される情報の詳細、および使用される低レベルＡＰＩに応じて異なることが可能である。
【００３０】
サービス検出ＡＰＩ２１４が、公開要求を受け取り、動作４４０で、その公開要求を解析する。動作４５０で、サービス検出ＡＰＩ２１４は、低レベルＡＰＩコールを実行してサービス公開要求を実行する。オプションの動作４５５で、サービス公開が、検出保持サービス２１２の中に格納される。
【００３１】
サービス検出ＡＰＩ２１４のサービス公開機能は、公開済みのサービスを削除するのにも使用することができる。図５は、サービス削除の諸動作を示す流れ図である。動作５１０で、アプリケーションが、サービス公開のためのサービスエントリオブジェクトを定義する。動作５１５で、アプリケーションは、サービスに対する固有キーを指定する。動作５２０で、アプリケーションは、サービス削除の範囲を定義する。動作５３０で、アプリケーションは、サービス削除要求を生成する。
【００３２】
サービス検出ＡＰＩ２１４が、その削除要求を受け取り、動作５４０で、その削除要求を解析する。動作５５０で、サービス検出ＡＰＩ２１４は、低レベルＡＰＩコールを実行してサービス削除要求を実行する。オプションの動作５５５で、サービス公開が、検出保持サービス２１２から削除される。
【００３３】
サービス検出ＡＰＩ２１４を使用して、アプリケーション群が、新たなサービスまたは特定のタイプのデバイスの出現（ａｒｒｉｖａｌ）または離脱（ｄｅｐａｒｔｕｒｅ）などの、サービスイベントの通知を受けることができるようにすることもできる。図６は、サービスイベントにサブスクライブするための諸動作６００を示す流れ図である。動作６１０で、アプリケーションが、監視されるべき特定の低レベルプロトコルを指定する範囲を定義する。動作６１５で、アプリケーションは、イベントのタイプを指定するフィルタを定義する。動作６２０で、アプリケーションは、合致するイベントが生じた際にＳｅｒｖｉｃｅＥｎｔｒｙの詳細を受け取るコールバック機能を定義する。動作６２５で、アプリケーションは、サービス検出ＡＰＩ２１４に転送されるサブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）要求を生成する。
【００３４】
サービス検出要求ＡＰＩ２１４が、そのサブスクリプション要求を受け取り、動作６３０で、そのサブスクリプション要求を解析する。動作６３５で、サービス検出要求は、サブスクリプションサービスを実施するのに要求される低レベルプロトコルコールを実行する。サービスイベントが生じると、低レベルプロトコルは、そのイベントの通知をサービス検出ＡＰＩに提供する。動作６４０で、イベント通知は、サービスエントリオブジェクトにフォーマットされる。オプションの動作６４５で、サービスエントリオブジェクトは、検出保持サービス２１２の中に格納されることが可能であり、動作６５０で、サービスエントリオブジェクトは、前もって指定されているコールバック機能を使用してアプリケーションに戻される。動作６５５で、アプリケーションが、サービスエントリオブジェクトに対してさらなる処理を実行する。アプリケーションによって実行されるさらなる処理の特定の詳細は、重要ではない。
【００３５】
以下に、システムのコンポーネントおよび動作をさらに詳細に説明する。  
ＡＰＩクラス 
フィルタ群 
フィルタは、規則セットであり、この規則セットによってサービス記述を評価することができ、真（すなわち、サービス記述がフィルタに合致する）または偽（すなわち、サービス説明がフィルタに合致しない）の結果がもたらされる。フィルタは、特定のプロパティを指定するシンプルフィルタとして、またはより表現豊かな文法を使用するリッチ（ｒｉｃｈ）フィルタとして表現されることが可能である。シンプルフィルタとして表現されるか、リッチフィルタとして表現されるかにかかわらず、クエリは、基礎にあるプロトコル群の能力に従った（ｓｕｂｊｅｃｔ  ｔｏ）変更なしに、１つまたは複数のプロトコルにわたって指定され、実行されることが可能である。サービス検出要求ＡＰＩ２１４が、より高いレベルのクエリの表現変更（ｒｅ−ｅｘｐｒｅｓｓｉｏｎ）を管理して、基礎にある低レベルプロトコルに対して正しいフォーマットにする。例えば、サービス検出要求ＡＰＩ２１４は、特定のサービスタイプに関するクエリを受け取り、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙに関してＬＤＡＰを使用し、ＵＤＤＩ  Ｗｅｂサービスレジストリに関してＵＤＤＩプロトコルを使用して、そのクエリを表現し、評価することができる。アプリケーション開発者は、個々のプロトコルを直接に扱うことを要求されない。
【００３６】
典型的なインプリメンテーションでは、サービス検出要求ＡＰＩ２１４は、与えられた条件（ｃｒｉｔｅｒｉａ）に対する完全合致セマンティクス（ｅｘａｃｔ  ｍａｔｃｈ  ｓｅｍａｎｔｉｃｓ）を提供するシンプルフィルタ、およびＯＰａｔｈ文法で表現されたクエリを含むリッチフィルタをサポートする検出モジュール群を要する。各モジュールは、追加の「ネイティブ」フィルタタイプをサポートすることも可能であることが認識されよう。異なる検出モジュールは、プロトコル固有のネイティブフィルタタイプを有することが可能であり、例えば、ＵＰｎＰ（商標）は、ＸＰａｔｈフィルタ群を使用することが可能であり、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙは、ＬＤＡＰフィルタ群をネイティブで使用することが可能であり、ＵＤＤＩは、ＵＤＤＩフィルタをネイティブで使用することが可能である。
【００３７】
モジュール群全体にわたるＯｐａｔｈフィルタ機能のベースレベルにより、アプリケーション群が、基礎にある検出プロトコル群からさらに隔離される。フィルタクラスは、モジュール群全体にわたって共有される形でフィルタを解析し、解釈する追加のメソッドも公開する。
【００３８】
シンプルフィルタは、サービスタイプ、サービスインタフェース、および／またはプロパティを指定することにより、クエリの表現を提供する。これらの設定の任意の組合せも、探索クエリの中で与えられることが可能であり、サービスは、条件のすべてが完全に合致した場合にだけ、結果のサービスエントリ集合の中に含められる。
【００３９】
サービスタイプは、サービスインスタンスに合致しなければならないタイプを指定する文字列としてインプリメント（ｉｍｐｌｅｍｅｎｔ）することができる。一般的なサービスタイプセットが、サービス検出要求ＡＰＩ２１４の中で事前定義される。このセットは、プロトコル群およびストア群の範囲内の重要なエンティティが明らかにされるにつれ、拡張することができる。例えば、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙ内のプリンタに関して、このセットは、filter.ServiceType = CommonServiceTypes.Printerを指定する。
【００４０】
サービスインタフェース群は、サービスが合致しなければならないインタフェース群の識別子を指定する文字列集合として実施することができる。例として、ＵＤＤＩにおけるＷｅｂサービスの場合、次のｔＭｏｄｅｌ識別子が指定されることが可能である。すなわち、filter.ServiceInterfaces.Add ("uuid:ac104dcc-d623-452f-88a7-f8acd94d9b2b")、filter.ServiceInterfaces.Add ("uuid:4d2ac1ca-e234-142f-e217-4d9b2f8acd9b")である。
【００４１】
プロパティは、サービスが合致しなければならないサービス特性を指定するプロパティディクショナリの中でインプリメントすることができる。例として、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙの中のプリンタ群の場合、次のプロパティを指定することができる。すなわち、filter.Properties.Add ("printcolor", "TRUE")、filter.Properties.Add ("pagesperminute", "50")である。
【００４２】
リッチフィルタは、Ｑｕｅｒｙ文字列プロパティを設定することにより、例えば、ＯＰａｔｈ文法を使用して、相当により豊かなクエリセマンティクスを表現するための機構を提供する。例として、ＵＤＤＩにおけるＷｅｂサービスの場合、Ｑｕｅｒｙ文字列は、次のとおり、要求される名前、および要求されるサポートされたインタフェースを指定する。すなわち、filter.Query = "WebService[name = 'Fabrikam' and ServiceInterface = 'uuid:ac104dcc-d623-452f-88a7-f8acd94d9b2b']"
Ａ４用紙が選択可能でない場合に毎分２５ページを超えて印刷することができるＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙの中のプリンタ群を見つけるより表現豊かな例としては、次のとおりである。すなわち、filter.Query = "Printer[printPagesPerMinute > 20 + 5 and not (printmediaReady = 'A4')]"
基礎にあるプロトコルおよびストアの能力は、基本的なＮｅｔＢＴセマンティクスから豊かなＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙクエリセマンティクスまでに及び、とうてい同一ではないため、ＯＰａｔｈのより表現豊かなコンストラクト（ｃｏｎｓｔｒｕｃｔｓ）を使用できることは、選択される範囲（プロトコル）に依存する。
【００４３】
範囲 
範囲は、通常、粗く、ネットワークロケーション別、または管理境界別の、探索されることが可能なクエリドメインを明らかにする。検出クエリは、１つまたは複数の範囲に向けられ、クエリ結果は、それらの範囲内のサービスのサブセットを含む。すなわち、クエリ結果は、所与のフィルタに合致する範囲内のすべてのサービスのサブセットである。典型的な範囲には、ワークグループ、ｌｏｃａｌｍａｃｈｉｎｅ、およびドメインが含まれる。
【００４４】
サービス検出ＡＰＩ２１４は、具象範囲および抽象範囲に対応する（ａｃｃｏｍｍｏｄａｔｅ）。具象範囲は、３つの部分で（ｉｎ  ｔｈｒｅｅ  ｐｉｅｃｅｓ）クエリドメインを指定する。特定のプロトコルを識別する、例えば、ＣｏｎｃｒｅｔｅＳｃｏｐｅ．ＮｅｔＢｔＰｒｏｔｏｃｏｌまたはＣｏｎｃｒｅｔｅＳｃｏｐｅ．ＡＤＰｒｏｔｏｃｏｌなどの単一の検出モジュールにマップされたＰｒｏｔｏｃｏｌ識別子、イントラネットＵＤＤＩサーバに対する「http://intra-uddi/uddi/inquire.asmx」のような、その範囲に対する諸動作が向けられるべきサーバを指定するＡｄｄｒｅｓｓ識別子（オプション）、および「CN-Joe-dev,CN=Computers,DC=corp,DC=fabrikam,DC=com」またはＵＰｎＰ（商標）ｖ２範囲名に設定されることが可能なＬＤＡＰ探索ベースなどの、モジュールの名前空間のパーティションを識別するパス識別子（オプション）である。
【００４５】
サービス検出要求ＡＰＩ２１４は、具象範囲をモジュール群に送る。サービス検出要求ＡＰＩ２１４は、例えば、第２のマシンに配線を介して具象範囲を伝送すること、および第２のマシン上の対応するＡＰＩに具象範囲を送ることなどの、具象範囲に対するさらなる間接化（ｉｎｄｉｒｅｃｔｉｏｎ）をモジュール群が実行することを排除しない。
【００４６】
抽象範囲は、１つまたは複数の具象範囲、ならびに、場合により、さらなる抽象範囲に対するモニカ（ｍｏｎｉｋｅｒ）である。抽象範囲は、論理的な事前定義された、または構成された具象範囲集合全体をクエリの対象とするための機構を提供する。これにより、開発者が、特定のディレクトリサーバ群に関する明示的なプロトコル、アドレス、および接続の詳細を要することなしに、例えば、「企業」範囲を目標とすることができるようにする、さらなる抽象化が提供される。
【００４７】
具象範囲に対する抽象範囲のマッピングは、マシン全体にわたり、構成可能である。例えば、抽象範囲、ＡｂｓｔｒａｃｔＳｃｏｐｅ．Ｅｎｔｅｒｐｒｉｓｅが、表１内の具象範囲の両方を含むようにマップされることが可能である。
【００４８】
【表１】
2011103131.tif 000003
【００４９】
図７は、具象範囲と抽象範囲の間の典型的な関係を示すブロック図である。具象範囲７３０〜７５０は、クエリが評価される範囲のドメインの指定を提供する。具象範囲７３０〜７５０は、プロトコルＩＤの詳細、ならびに、必要に応じて、使用されるストアまたはサーバの詳細を含み、そのストア内部またはサーバ内部でさらに範囲を定める（ｓｃｏｐｅ）可能性を有する。サービス検出ＡＰＩ２１４内で、以上が、それぞれ、Ｐｒｏｔｏｃｏｌプロパティ、Ａｄｄｒｅｓｓプロパティ、およびＰａｔｈプロパティにおいて指定される。
【００５０】
抽象範囲７１０〜７２５は、具象範囲を超えるより高いレベルの階層式抽象化を提供する。抽象範囲は、その抽象範囲を構成する具象範囲または抽象範囲を含むように構成される。その範囲マッピングが、システム管理者には利用可能であり、システム管理者は、例えば、ＡｂｓｔｒａｃｔＳｃｏｐｅ．ＥｎｔｅｒｐｒｉｓｅＳｃｏｐｅが、具体的にどのように解決されるべきかを構成できることが可能である。
【００５１】
具象範囲と抽象範囲はともに、サービス検出ＡＰＩ２１４のユーザによって使用されることが可能である。抽象範囲が提供されるケースでは、サービス検出ＡＰＩ２１４は、階層を下って、いくつかの具象範囲までその抽象範囲を解決する。
【００５２】
抽象範囲は、アプリケーションプログラム群２１０の開発者が、比較的高いレベルで作業し、コードの中に「ＡｂｓｔｒａｃｔＳｃｏｐｅ．Ｅｎｔｅｒｐｒｉｓｅ」のような範囲を明らかにする用語を含めることができるようにする。このようにして、例えば、開発者は、特定のＵＤＤＩサーバの詳細を自分のコードにハードコードする（ｈａｒｄｃｏｄｅ）ことを要さない。この抽象化により、コードのより大幅な再使用、およびより高い移植性が可能になる。同一のコードを、変更または再コンパイルなしに、様々な企業環境において使用することができる。抽象範囲構成だけが、環境間で変化する。
【００５３】
抽象範囲−具象範囲マッピングの複数の階層が存在することが可能である。図７で、ＡｂｓｔｒａｃｔＳｃｏｐｅ．ＬｏｃａｌＭａｃｈｉｎｅは、その構成要素のすべてがＡｂｓｔｒａｃｔＳｃｏｐｅ．Ａｌｌに含まれるものの、ＡｂｓｔｒａｃｔＳｃｏｐｅ．Ａｌｌまで上るようにマップされない。
【００５４】
典型的なインプリメンテーションでは、範囲マップ構成は、企業におけるサービス検出ＡＰＩ２１４の使用を制限するように、システム管理者によってグループポリシーを介して操作されることが可能である。例として、管理者は、企業コンピューティング環境、または企業コンピューティング環境の一部分において利用可能な１つまたは複数の抽象範囲を定義することができる。これにより、システム管理者が、アプリケーション群によるリソースの検出および使用を規制することが可能になる。
【００５５】
ＳｅｒｖｉｃｅＥｎｔｒｙ結果 
アプリケーション開発者は、適切なＳｃｏｐｅ表現およびＦｉｌｔｅｒ表現を選択することができ、その表現が、次に、サービスファインダ（ｓｅｒｖｉｃｅ  ｆｉｎｄｅｒ）オブジェクト上のプロパティとして設定されることが可能である。次に、アプリケーションは、ＦｉｎｅＯｎｅメソッドまたはＦｉｎｄＡｌｌメソッドを使用して検出要求を実行することができる。ＦｉｎｄＡｌｌメソッドは、与えられた条件に合致するすべてのサービスを戻し、他方、ＦｉｎｅＯｎｅメソッドは、単一の合致するサービスを戻す。メソッドは、同期呼び出しパターン、または非同期呼び出しパターンを使用して実行されることが可能である。
【００５６】
指定された範囲内に提供されたフィルタに合致するサービスが存在するものと想定すると、ＦｉｎｄＯｎｅメソッドまたはＦｉｎｄＡｌｌメソッドは、１つのサービスエントリオブジェクト、またはサービスエントリオブジェクトの集合を戻す。サービスエントリオブジェクトは、基礎にあるプロトコル群が提供することができるサービスの様々な表現にわたる抽象化である。各サービスエントリオブジェクトは、サービスの単一のインスタンスに相当し、このため、表２に記載したプロパティを含む、記述プロパティおよび識別プロパティを提供する。
【００５７】
【表２】
2011103131.tif 000004
【００５８】
範囲集合の中で指定された範囲内のサービスエントリ表現を作成する、または更新するｐｕｂｌｉｃ  ｖｏｉｄ  Ｓａｖｅ（）関数が提供される。
【００５９】
ｐｕｂｉｃ  ｖｏｉｄ  Ｄｅｌｅｔｅ（）メソッドが、Ｓｃｏｐｅプロパティにおいて指定された範囲から、そのＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトを削除する。サービスが既に公開済みではない場合、例外がスロー（ｔｈｒｏｗ）される。
【００６０】
擬似コード 
図８〜１９は、様々なサービス検出機能、サービス公開機能、およびサブスクリプション機能を実行するための擬似コードを示す。
【００６１】
図８は、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙプロトコルに対してＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトを使用して毎分５０ページを印刷するカラープリンタ群を探し出すのに、どのようにＣ＃プログラミング言語を使用するかを例示する擬似コードである。
【００６２】
図９は、ＵＤＤＩプロトコルに対してＲｉｃｈＦｉｌｔｅｒオブジェクトを使用して、ｕｄｄｉ−ｏｒｇ：ｉｎｑｕｉｒｙ＿ｖ２インタフェースを実装し、Ｆａｂｒｉｋａｍと名付けられたＷｅｂサービスを探し出すのに、どのようにＣ＃プログラミング言語を使用するかを例示する擬似コードである。
【００６３】
図１０は、ＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトおよびＵＤＤＩプロトコルを使用して特定のｔＭｏｄｅｌインタフェースをサポートするサービスを探し出す、Ｃ＃プログラミング言語の用法を例示する擬似コードである。
【００６４】
図１１は、ＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトおよびＵＤＤＩプロトコルを使用して特定のｔＭｏｄｅｌインタフェースをサポートするサービスを探し出す、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【００６５】
図１２は、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙに対してＲｉｃｈＦｉｌｔｅｒを使用して、Ｏｆｆｉｃｅ  Ｐｒｉｎｔｅｒのような名前でプリンタを探し出す、Ｃ＃プログラミング言語の用法を例示する擬似コードである。
【００６６】
図１３は、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙに対してＲｉｃｈＦｉｌｔｅｒを使用して、Ｏｆｆｉｃｅ  Ｐｒｉｎｔｅｒのような名前でプリンタを探し出す、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【００６７】
図１４は、ＳＳＤＰプロトコルを使用して、特定の固有識別子で識別される特定のタイプのサービスを公開する、Ｃ＃プログラミング言語の用法を例示する擬似コードである。
【００６８】
図１５は、ＳＳＤＰプロトコルを使用して、特定の固有識別子で識別される特定のタイプのサービスを公開する、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【００６９】
図１６は、ＳＳＤＰプロトコルからサービスを削除するＣ＃プログラミング言語の用法を例示する擬似コードである。
【００７０】
図１７は、ＳＳＤＰプロトコルからサービスを削除するＶｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【００７１】
図１８は、ＳｉｍｐｌｅＦｉｌｔｅｒを使用して、ＳＳＤＰプロトコルを使用する特定のタイプのイベントに関して登録する、Ｃ＃プログラミング言語の用法を例示する擬似コードである。登録されたコールバック機能は、フィルタに合致するイベントごとに呼び出され、対応するＳｅｒｖｉｃｅＥｎｔｒｙオブジェクトがそのハンドラに提供される。
【００７２】
図１９は、ＳｉｍｐｌｅＦｉｌｔｅｒを使用して、ＳＳＤＰプロトコルを使用する特定のタイプのイベントに関して登録する、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴの用法を例示する擬似コードである。
【００７３】
典型的なＯＰａｔｈ構文 
表３は、様々な検出機能に関する適切なＯＰａｔｈ構文を提供する。
【００７４】
【表３】
2011103131.tif 000005
【００７５】
表４は、ＵＤＤＩプロトコルに対して使用することができるＯＰａｔｈ構文の例を含む。
【００７６】
【表４】
2011103131.tif 000006
【００７７】
表５は、ＮｅｔＢＴプロトコルに対して使用することができるＯＰａｔｈ構文の例を含む。
【００７８】
【表５】
2011103131.tif 000007
【００７９】
検出保持サービス 
上記に簡単に説明したとおり、検出保持サービス２１２は、サービス情報のための永続データストアを管理する。定期的に、または始動などの所定のイベント時に、検出保持サービスは、特別な（ａｄ−ｈｏｃ）デバイス／サービス告知を受け取るように登録する。例として、新たなＵＰｎＰ（商標）デバイスが導入されると、そのデバイスは、ＵＰｎＰ（商標）プロトコルモジュールによって扱われるデバイス告知を生成する。このモジュールは、サービス検出ＡＰＩ２１４を介して、そのイベント（デバイス、およびデバイスのサービス）の詳細を検出保持サービスに公表する（ｓｕｒｆａｃｅ）。
【００８０】
すると、検出保持サービスは、自らの永続データストアを使用して、そのイベントが、新たなデバイス／サービスであるか、または復帰した（ｒｅｔｕｒｎｉｎｇ）デバイス／サービスであるかを判定する。イベントが新たなデバイス／サービスである場合、そのデバイス、およびそのデバイスのサービスの詳細が、永続データストアの中に登録される。サービス検出ＡＰＩ２１４の別のコンシューマ（ｃｏｎｓｕｍｅｒ）がサービスを探し出そうと試みた場合、サービス検出ＡＰＩ２１４は、特別のデバイス／サービスに関するサービスを、そのデバイスが現在、利用可能でない場合でも戻すことができる。上記の例に関して、デバイス／サービスが現在、利用可能であるケースでは、指定された範囲に依存して、ＵＰｎＰ（商標）プロトコルモジュールと永続データストアモジュールがともに、デバイスに関する結果を戻すことができる。ＵＰｎＰ（商標）に加えて、上記の機能は、他の特別な検出機構群にも適用される。
【００８１】
このため、検出保持サービス２１２、サービス検出ＡＰＩ２１４、およびローカルデータベースストア２４０は、デバイス検出およびサービス検出のために使用される様々な低レベルプロトコルにわたる抽象化レイヤを提供する。この追加の抽象化レイヤにより、アプリケーション開発者がアプリケーションを開発する際に使用することができる、共通の改良された探索セマンティクスが確立される。
【００８２】
さらに、検出保持サービス２１２、サービス検出ＡＰＩ２１４、およびローカルデータベースストア２４０は、ローカルマシン上、ホームネットワーク上、企業ネットワーク上、およびインターネット上のサービスおよびデバイスに関する統合された検出モデルを提供する。このため、アプリケーション開発者は、単一の整合性のあるＡＰＩを書くことにより、多種多様な場所におけるサービスを検出することができる。
【００８３】
結論 
説明した構成は、構造上の特徴および／または方法上の動作に特有の言い回しで説明してきたが、添付の特許請求の範囲で定義する本件は、説明した特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、特定の特徴および動作は、請求する本件を実施する好ましい形態として開示している。
【図１】
2011103131.tif 000008
【図２】
2011103131.tif 000009
【図３】
2011103131.tif 000010
【図４】
2011103131.tif 000011
【図５】
2011103131.tif 000012
【図６】
2011103131.tif 000013
【図７】
2011103131.tif 000014
【図８】
2011103131.tif 000015
【図９】
2011103131.tif 000016
【図１０】
2011103131.tif 000017
【図１１】
2011103131.tif 000018
【図１２】
2011103131.tif 000019
【図１３】
2011103131.tif 000020
【図１４】
2011103131.tif 000021
【図１５】
2011103131.tif 000022
【図１６】
2011103131.tif 000023
【図１７】
2011103131.tif 000024
【図１８】
2011103131.tif 000025
【図１９】
2011103131.tif 000026