(57)【要約】【課題】  スマートデバイス上に分散されるサービスまたはコンポーネントベースのアプリケーションのための組み立てモデルと組み立ての検証アルゴリズム。【解決手段】  コンポーネントベースアプリケーションをモデル化することは、アプリケーションのコンポーネント（７０４、７０６等）の通信能力（３１０、３２１等）をモデル化すること、アプリケーションのコンポーネント（７０４、７０６等）を連結するための計画をモデル化すること、複数の構成コンポーネントから組み立てられた複合コンポーネント（８５０、９２０）の通信能力をモデル化すること、および連結されたコンポーネントがアプリケーションにおいて有効に通信を行うのに互換性があるかどうかを決定することを含む。【選択図】図１０
2007157149.tif 000002
【特許請求の範囲】
【請求項１】
コンポーネントベースアプリケーションをモデル化する方法であって、
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化することと、
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）を連結する計画をモデル化することと、
複数の構成コンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）から組み立てられた複合コンポーネント（８５０、９２０）の通信能力をモデル化することと、
前記アプリケーションにおいて有効に通信するために、連結されたコンポーネント（９００、９１０、８０２、８０６、８１２）に互換性があるかどうか決定することと
を備えたことを特徴とする方法。
【請求項２】
前記コンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）は、ソフトウェアモジュールを備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記コンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）は、異種のコンピュータデバイスを備えたことを特徴とする請求項１に記載の方法。
【請求項４】
前記異種のコンピュータデバイスは、ＲＦＩＤデバイス（１１２）を備えたことを特徴とする請求項３に記載の方法。
【請求項５】
前記複合コンポーネント（９２０）は適格であるかどうかを決定することを更に備えたことを特徴とする請求項１に記載の方法。
【請求項６】
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）の通信能力をモデル化することは、通信概念（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）を前記コンポーネントに関連付けられた特性へマッピングすることを備えたことを特徴とする請求項１に記載の方法。
【請求項７】
連結されたコンポーネント（９００、９１０、８０２、８０６、８１２）を通る通信経路の終端におけるコンポーネント（７０４、７０６、７１２、８０２、８１０、８１２、９００、９１０）のエンドツーエンド通信概念（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化することと、
前記経路の前記終端における前記コンポーネントの前記エンドツーエンド通信概念が互換性があるかどうかを決定することと
を更に備えたことを特徴とする請求項１に記載の方法。
【請求項８】
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８１０、８１２、９００、９１０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化することは、前記コンポーネントのインタフェースポート（７０８、７１０、７２０、７５６、７５８、８０４、８０８、８１０、８１４、８２２、８２６、９０２、９０４、９０６、９１２、９１２’、９１４、９１６）のモデルを作成することを備えたことを特徴とする請求項１に記載の方法。
【請求項９】
複数の構成コンポーネントから組み立てられた複合コンポーネント（９２０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化することは、前記構成コンポーネントのインタフェースポートのモデル（７０８、７１０、７２０、７５６、７５８、８０４、８０８、８１０、８１４、８２２、８２６、９０２、９０４、９０６、９１２、９１２’、９１４、９１６）をマージすることを備えたことを特徴とする請求項８に記載の方法。
【請求項１０】
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８１０、８１２、９００、９１０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化することは、コンポーネントのタイプの通信能力をモデル化することを備え、
連結されたコンポーネント（９００、９１０、８０２、８０６、８１２）が、前記アプリケーションにおいて有効に通信するために、互換性があるかどうかを決定することは、コンポーネントの前記タイプによってモデル化された通信技術が、互換性があるかどうかを決定することを備えたこと
を特徴とする請求項１に記載の方法。
【請求項１１】
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８１０、８１２、９００、９１０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化することは、コンポーネントのインスタンスの通信能力をモデル化することを備え、
連結されたコンポーネントが、前記アプリケーションにおいて有効に通信するために、互換性があるかどうかを決定することは、コンポーネントの前記インスタンスに互換性があるかどうかを決定することを備えたこと
を特徴とする請求項１に記載の方法。
【請求項１２】
通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をＯＳＩ層に関連付けることをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１３】
コンポーネントベースアプリケーションをモデル化するシステムであって、
前記アプリケーションのコンポーネント（７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）のモデルと、
前記アプリケーションのコンポーネントを連結するための計画のモデルと
を備えた記憶装置と、
複数の構成コンポーネント（８０２、８０６、８１２、９００、９１０）で組み立てられた複合コンポーネント（８５０、９２０、８２０、８２４）の通信能力をモデル化し、
連結されたコンポーネントが、前記アプリケーションにおいて有効に通信するために、互換性があるかどうかを決定する
ように構成されたプロセッサと
を備えたことを特徴とするシステム。
【請求項１４】
前記コンポーネントは、異種のコンピュータデバイスを備えたことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記異種のコンピュータデバイスは、ＲＦＩＤデバイス（１１２）を備えたことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記プロセッサは、さらに、前記複合コンポーネント（８５０、９２０、８２０、８２４）が適格であるかどうかを決定するように構成されることを特徴とする請求項１３に記載のシステム。
【請求項１７】
前記記憶装置は、連結されたコンポーネントを通る通信経路の終端におけるコンポーネント（７０４、７０６、７１２、８０２、８１０，８１２、９００、９１０）のエンドツーエンド通信概念（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）のモデルをさらに備え、
前記プロセッサは、前記経路の前記終端における前記コンポーネントの前記エンドツーエンド通信概念に互換性があるかどうかを決定するようにさらに構成されること
を特徴とする請求項１３に記載のシステム。
【請求項１８】
前記プロセッサは、前記コンポーネントのインタフェースポート（７０８、７１０、７２０、７５６、７５８、８０４、８０８、８１０、８１４、８２２、８２６、９０２、９０４、９０６、９１２、９１２’、９１４、９１６）のモデルを生成するようにさらに構成され、
前記複合コンポーネントの通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化するために、前記プロセッサは、前記構成コンポーネントのインタフェースポートのモデルをマージするようにさらに構成されること
を特徴とする請求項１３に記載のシステム。
【請求項１９】
前記プロセッサは、前記アプリケーションの前記コンポーネントの通信能力をモデル化するために、コンポーネントのタイプ（７０４、７０６、７１２、８０２、８１０、８１２、９００、９１０）の通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化するように構成され、
前記連結されたコンポーネントが、前記アプリケーションにおいて有効に通信するのに互換性があるかどうかを決定するために、前記プロセッサは、コンポーネントの前記タイプに互換性があるかどうかを決定するよう構成されること
を特徴とする請求項１３に記載のシステム。
【請求項２０】
前記アプリケーションのコンポーネントの通信能力をモデル化するために、前記プロセッサは、コンポーネント（７０４、７０６、７１２、８０２、８１０、８１２、９００、９１０）のインスタンスの通信能力（３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６）をモデル化するように構成され、
前記コンポーネントのインスタンスが互換性があるかどうかを決定ために、前記プロセッサは、連結されたコンポーネントは、有効に通信するのに互換性があるかどうかを決定するよう構成されること
を特徴とする請求項１３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、ユビキタスコンピューティング技術に関する。
【背景技術】
【０００２】
ユビキタスコンピューティング環境においては、多数の異なるコンピューティング技術は、人間環境に統合されており、職場または自宅での日々の生活の中で、役立つサービスを人に提供する。このような環境は、「スマートアイテム技術」、「知能空間」または「ウェアラブルコンピューティング」として知られているシステムおよびインフラストラクチャに関する。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
さまざまな協働する異種のデバイス（例えば、ＰＤＡ、スマートフォン、センサデバイス、ＲＦＩＤタグ、埋込みデバイス、ＰＣ類、サーバ、ＧＰＳ衛星、コンピューティングネットワーク、電話、テレビなど）、またはサービス（例えば、様々なソフトウェアプログラム、ルーチン、プラットフォーム、および実行可能コード）の形態で実行される高度に分散化されたアプリケーションによるユビキタスコンピューティングアプリケーション環境においては、様々な異なる通信技術およびプロトコルを使用して、それらのコンピューティング能力を生かす。個々のデバイスは、より複雑なサービスまたはアプリケーションへと組み合せることができる、すなわち、「組み立て」可能なコンポーネントまたはサービスを実行する。このようなコンポーネントベースまたはサービスベースのユビキタスアプリケーション開発方法は、利用可能なデバイスの集合への機能の分散をサポートし、異なった／新規のアプリケーションにおけるコンポーネントのより良い再利用を可能にし、別々に開発およびテストできる明確に定義されたインタフェースで、機能全体を複数のコンポーネントに分割することによって、ユビキタスアプリケーションの開発をサポートする。
【０００４】
ユビキタスコンピューティング環境の一例は、スマートアイテムインフラストラクチャ（ＳＩＩ）である。スマートアイテム技術は、例えば、無線周波数識別（ＲＦＩＤ）システム、埋込みシステム、またはセンサネットワークを含むことができ、スマートアイテム技術を使用して、例えば、ビジネスソフトウェアアプリケーションに実世界データへ高速アクセスを提供できる。例えば、スマートアイテム技術を使用して、ＲＦＩＤタグの検出、読取り、または書込みをサポートすることができ、無線センサネットワークおよび埋め込みシステムとの通信およびそれらの制御をサポートすることもできる。多くの場合、スマートアイテムは、ローカル処理能力、メモリ、および／または通信能力を有するデバイスを含むことができ、これは、デバイスとその特性についてのデータ、またはスマートアイテムデバイスの現在の状態もしくは環境についての情報を提供することができる。従って、いくつかのそのようなデバイスは、バックエンドまたは基本ビジネスアプリケーションのサービスコンポーネントの実行で使用することができ、特に、協働的な方法で、例えば、ビジネスデータを収集、処理、または送信するために、モバイルアドホックネットワークを形成することによって、使用することができる。
【０００５】
スマートアイテムデバイスの例はＲＦＩＤタグを含み、これは、受動的であってもアクティブであってもよく、オブジェクトに取り付けて、オブジェクトに関する製品または取り扱い情報を提供するために使用できる。スマートアイテムデバイスの他の例は、様々なセンサ、例えば環境センサ（例えば、温度、湿度、または振動のセンサ）を含み、これらは、１つまたは複数のセンサネットワークにおいて互いに通信可能とすることができる。これらおよび他の種類のスマートアイテムデバイスは、埋め込みシステムを含むこともでき、これは、一般に、専用プロセッサおよび／またはプログラムが含まれ、および／またはシステムが制御されているデバイスにカプセル化された任意のシステムを指すことができる。
【０００６】
自動実時間オブジェクト追跡によって、スマートアイテム技術は、企業活動についての正確でタイムリーなデータを企業に提供することができ、また、企業活動の合理化および自動化を助けることもできる。その結果、コスト削減と追加営業利益（例えば、資産の可視化の向上、応答性の向上、およびビジネス機会の拡大）を得ることができる。
【課題を解決するための手段】
【０００７】
第１の一般的な態様において、コンポーネントベースのアプリケーションをモデル化する方法は、アプリケーションのコンポーネントの通信能力をモデル化すること、アプリケーションのコンポーネントを連結する計画をモデル化すること、複数の構成コンポーネントから組み立てられた複合コンポーネントの通信能力をモデル化すること、およびアプリケーション内で有効に通信するために連結されたコンポーネントに互換性があるかどうかを決定することを含む。
【０００８】
実装例は、次の特徴の１つまたは複数を含むことができる。例えば、コンポーネントは、ソフトウェアモジュールまたは異種のコンピュータによるデバイス（例えばＲＦＩＤデバイス）を含むことができる。その方法は、複合コンポーネントが適格であるかどうかを決定することをさらに含むことができる。アプリケーションのコンポーネントの通信能力をモデル化することは、通信概念をコンポーネントに関連付けられた特性にマッピングすることを含むことができる。
【０００９】
方法は、連結されたコンポーネントを通る通信経路の終端におけるコンポーネントのエンドツーエンド通信概念をモデル化することと、通信経路の終端におけるコンポーネントのエンドツーエンド通信概念に互換性があるかどうかを決定することとをさらに含むことができる。アプリケーションのコンポーネントの通信能力をモデル化することは、コンポーネントのインタフェースポートのモデルを生成することを含むことができる。複数の構成コンポーネントから組み立てられた複合コンポーネントの通信能力をモデル化することは、構成コンポーネントのインタフェースポートのモデルをマージすることを含むことができる。アプリケーションのコンポーネントの通信能力をモデル化することは、コンポーネントの複数の種類の通信能力をモデル化することを含むことができ、連結されたコンポーネントがアプリケーションにおいて有効に通信を行うのに互換性があるかどうかを決定することは、コンポーネントのタイプによってモデル化された通信技術が互換性があるかどうかを決定することを含むことができる。アプリケーションのコンポーネントでの通信能力をモデル化することは、コンポーネントのインスタンスの通信能力をモデル化することを含むことができ、連結されたコンポーネントがアプリケーションにおいて有効に通信する互換性があるかどうかを決定することは、コンポーネントのインスタンスが互換性があるかどうかを決定することを含むことができる。この方法は、通信能力をＯＳＩ層に関連づけることを含むことができる。
【００１０】
別の一般的な態様において、コンポーネントベースのアプリケーションをモデル化するシステムは、記憶装置とプロセッサとを含む。記憶装置は、アプリケーションのコンポーネントの通信能力のモデルと、アプリケーションのコンポーネントを連結する計画のモデルを含む。プロセッサは、複数の構成コンポーネントから組み立てられた複合コンポーネントの通信能力をモデル化し、連結されたコンポーネントがアプリケーションにおいて有効に通信を行うために互換性があるかどうかを決定するように構成される。
【００１１】
実装例は、次の特徴のうちの１つまたは複数を含むことができる。例えば、コンポーネントは、異種のコンピュータデバイス（例えばＲＦＩＤデバイス）を含むことができる。プロセッサは、複合コンポーネントが適格であるかどうかを決定するように、さらに構成できる。記憶装置は、連結されたコンポーネントを通る通信経路の終端におけるコンポーネントのエンドツーエンド通信概念のモデルをさらに備えることができ、プロセッサは、経路の終端におけるコンポーネントのエンドツーエンド通信概念が互換性があるかどうか決定するようにさらに構成することができる。プロセッサは、コンポーネントのインタフェースポートのモデルを生成するようにさらに構成することができ、複合コンポーネントの通信能力をモデル化するために、構成コンポーネントのインタフェースポートのモデルをマージするようにさらに構成することができる。
【００１２】
プロセッサは、アプリケーションのコンポーネントの通信能力をモデル化するために、コンポーネントの数タイプの通信能力をモデル化するように構成することができ、連結されたコンポーネントがアプリケーションにおいて有効に通信するために互換性があるかどうかを決定するために、コンポーネントの数タイプが互換性があるかどうかを決定するよう構成できる。
【００１３】
プロセッサは、アプリケーションのコンポーネントの通信能力をモデル化するために、コンポーネントのインスタンスの通信能力をモデル化するように構成でき、プロセッサは、コンポーネントのインスタンスが互換性があるかどうかを決定するために、連結されたコンポーネントが有効に通信するよう互換性があるかどうかを決定するようにさらに構成することができる。
【００１４】
１つまたは複数の実装例の詳細は、添付の図面と次の記述において説明する。他の特徴については、次の記述と図面および特許請求の範囲から明らかになるであろう。
【発明を実施するための最良の形態】
【００１５】
ここで説明されるように、スマートデバイス上に分散されるサービスまたはコンポーネントベースのアプリケーションのために、組み立てモデルを説明する。また、提案された組み立て計画を検証するための検証スキームについて説明する。異種のコンポーネントが、ユビキタスコンピューティングシステムに一緒に連結されるか、またはどうやって異種のコンポーネントが、ユビキタスコンピューティングシステムに一緒に連結されうるかを理解するためにこのモデルが使用される。
【００１６】
複合アプリケーションに結集するために使用されるモデルの基本構築ブロックは、ソフトウェアサービスならびにモジュール、コンピュータデバイス、および通信ミドルウェアを表すコンポーネントである。モデルにおいて、各コンポーネントは、そのポートによって定義されるインタフェースを有し、このポートは、コンポーネントによって使用される通信技術に関する豊富な記述を保持する。ポートは、コンポーネントの機能性へのインタフェースの一部でもあってもよく、または接続を別のポートに託してもよい。このコンポーネントは、モデルフレームワークの一部であるインタフェースオントロジーでモデル化される通信面のクラスを参照して記述する。
【００１７】
モデルで使用されるオントロジーにおいて、サブクラスおよびスーパークラスで編成されるクラスと、オントロジーによって与えられる制約とによって、異なるレベルの細かさでネットワークを記述することが可能になる。更に、異なる層における通信面間の意味構造関係がモデル化される。この情報で、通信戦略に関するアプリケーションの制約は、検証処理において、特定および考察でき、領域特化型オントロジーを定義するために使用されるメタモデルに基づいて、将来の通信技術領域をカバーするようにオントロジーを拡張することもできる。
【００１８】
複合アプリケーションを記述する組み立て計画において、コンポーネントは、それらのポートを介して連結され、複合アプリケーションのモデルは、連結された構築ブロックのモデルに組み立て操作を連続的に適用することによって、計画から導き出される。各ステップにおいて、組み立て操作は、入力として２つの連結されたコンポーネントを用い、結果の複合コンポーネントのモデルを生成する。連結されたコンポーネントによって提供および要求される通信技術を使用して、結果の複合コンポーネントの能力と制約を導き出す。
【００１９】
複合コンポーネントの適格性をチェックするために、組み立て操作は、連結されたポートの両方が、対話を行うのにそれらが必要とするすべての通信概念を定義しているかどうかをチェックする。このような通信概念の例は、プロトコル、無線周波数、またはエラー訂正手段である。連結されるコンポーネントのタイプに関与するコンポーネントの特性に依存して採用するのに必要な概念を導出することができる。このように、ポートツーポートの対話は、必要とされる通信態様の存在と互換性とを評価することによって検証することができる。
【００２０】
ポイントツーポイント接続を実現する対話技術に加えて、エンドツーエンド通信の態様も、通信のエンドポイントにおけるポートの態様を記述することによってチェックすることができる。組み立て操作は、通信ネットワークにおける通信抽象化の任意のレベルで同等な制約を生成する役割となることができ、この制約は、エンドツーエンド接続に関与する結果のコンポーネントのポートに追加される。
【００２１】
組み立て操作の１次出力は、結果の複合コンポーネントのモデルである。更に、組み立てが十分に定義されている場合、または追加コンポーネントがコンポーネントの動作の編成を築き上げるのに必要な場合、情報は含有される。さらに、組み立てが無効な場合、組み立てコンポーネントは、失敗の原因についての情報を返すことができる。
【００２２】
図１は、組み立てモデルと検証スキームとが利用できるスマートアイテムインフラストラクチャ１００のブロック図である。スマートアイテムインフラストラクチャ１００は、デバイス層１０２、デバイスレベルサービス層１０４、ビジネスプロセスブリッジ層１０６、システム接続層１０８および企業アプリケーション層１１０を含む。デバイス層１０２は、様々な異なるハードウェアとソフトウェアと通信プロトコルとを使用して、多数のグループ、ローカルネットワーク、および／または物理的位置にわたって通信する様々なデバイスを含むとみなすことができる。一方、１０６、１０８、１１０層は、ビジネスデータ処理システムもしくはサービスの一部か、またはそれらに関連付けられているとみなすことができる。
【００２３】
デバイス層１０２はこのように、実際のスマートアイテムデバイス、並びにそれらの間の任意の通信を備える。デバイス層１０２は、次に高い層すなわちデバイスレベルサービス層１０４に、あらゆる提供されたハードウェアサービスの提示に関与もする。デバイスは、例えば、ＲＦＩＤデバイス１１２、埋め込みシステム１１４、センサネットワーク１１６、および他の任意の新規または将来技術１１８を、適切であるように、含んでよい。
【００２４】
例えば、ＲＦＩＤデバイス１１２に関して、モバイルタグは、実世界オブジェクトに添付され、ＲＦＩＤリーダによって読取ることができる（任意で書込みも）。アクティブタグを使用する一実装において、アクティブタグは、追加センサデータ（例えば、現在値または過去値）を提供することもできる。ＲＦＩＤにおいて、通信は、一般的にリーダによって開始され、タグは、互いに直接に通信しても、しなくてもよい。このようなＲＦＩＤリーダは、タグデータを処理するという点で構成可能であってもよい。例えば、書込みデータの検証を行うように構成することができるか、または表面上は紛失されたタグが、実際に所与の時間窓内に再度現れる場合、タグの消失を報告することを回避するように構成することもできる。
【００２５】
埋め込みシステム１１４と通信する技術は、埋め込みシステムのデバイスの種類によって変わるかもしれない。例えば、埋め込みシステムは、小規模ワンチップマイクロコンピュータから本格的なＰＣハードウェアまでのすべてを表せる。従って、例えば、携帯電話以上の能力を有する（例えばＪａｖａ仮想マシン（登録商標）を実行できる）デバイスに関して、実装は、Ｊａｖａ（登録商標）、またはＯＳＧｉに基づいて行うことができる。本明細書で述べるように、センサネットワーク１１６は、任意数の種類のセンサを含むことができ、これらは、統合された処理電力を含むことができ、ピアツーピア通信を実行できることもある。
【００２６】
別の例において、デバイス層１０２が無線センサネットワーク１１６を備えるとき、管理を必要とする特徴を含むことができる。例えば、ネットワーク内のセンサノード１１７は、ピアツーピア通信を可能にする統合された処理電力を含むことができ、そのような単純なビジネスロジックは、センサノード１１７によって実行可能である。ノード１１７の振る舞いを制御するために、インフラストラクチャ１００の高位のレベルからそれらへ、プログラムロジックを押し下げることができる。異なるデバイスの種類に固有で実装できる軽量サービスを使用して、このプログラムロジックをカプセル化し、センサノード１１７上に配置することができる。各ハードウェアプラットフォームが提供する基本機能は、いわゆる「可能にするサービス」にカプセル化され、サービスインタフェースを使用して、センサノードへのアクセスを統一し単純化することが可能となる。別のサービス（例えば、管理およびビジネスサービス）をセンサノード１１７上にインストールして実行することができる。通常、管理およびビジネスサービスは、インフラストラクチャ１００の高位のレベルからノード１１７に受信された後に、実行時にインスタンス化される。管理およびビジネスサービスの受信およびインスタンス化を制御するサービスは、可能にするサービスであり、一般的に、ノード１１７にプリインストールされている。
【００２７】
デバイスレベルサービス層１０４は、デバイス層１０２によって使用される配置可能なサービスを管理する。従って、デバイスレベルサービス層１０４は、サービスマッパー１４０、システムモニタ１４２、サービスレポジトリ１４４ａおよびデバイスレポジトリ１１４ｂを含む。
【００２８】
サービスレポジトリ１４４ａとデバイスレポジトリ１１４ｂは、少なくとも２種類のサービスとデバイス、すなわち複合およびアトミックサービスと、複合およびアトミックデバイスを格納することができる。複合サービスは、通常、それらのタスクを満たすために別のサービスに依存し、それ自身の直接実行可能なコードを持たなくてもよい。むしろ、複合サービスは、対応するサービスの記述に格納される実行可能なサービスの組み立て記述を含むことができる。従って、複合サービスは、１つのサービス実行可能性すなわちサービス組み立て記述を有することができる。逆に、アトミックサービスは、通常、別のサービスを使用せず、それ自身で直接実行可能なコードを有する。また、アトミックサービスは異なるプラットフォームに配置可能であってよいので、アトミックサービスは、複数のサービス実行可能性を有することができ、たとえば、異なるプラットフォームの各々に関連付けられたサービスを有することができる。同様に、アトミックデバイスは、通常、スタンドアロンのデバイスであり、一方で、複合デバイスは、複数の構成アトミックデバイスから組み立てられる。
【００２９】
サービスレポジトリとデバイスレポジトリ１４４は、サービスおよびデバイスメタデータとを記憶することもでき、このようなサービスメタデータは、詳細に記述され、サービスあるいはデバイス名、識別子、バージョン、あるいはベンダを含むことができ、またはサービスあるいはデバイスの実行時の要件を記述することもでき、実行時要件には、例えば、技術的な配置要件（例えば、高帯域または必要な最低処理電力）、意味構造的な要件（例えば、受信デバイスが、直列接続を有し、通常の送電線電力および／または近くの多数のデバイスに対するバッテリーバックアップを有すること）、および空間的要件（例えば、受信デバイスは地階または特定の建物の南側にあること）が含まれる。
【００３０】
実行時、システムモニタ１４２は、現在のシステム状態を監視する。サービス状態の任意の部分がシステムモニタに向けられるかどうか、またどのように向けられるかは、設計時にサービスの開発者によって設定することができる。この状態利用可能性情報は、その後、システムアドミニストレーターとサービスマッパー１４０コンポーネントの両方に利用可能である。また、上述のように、サービスマッパー１４０は、配置要件を受信し、その後、例えば、サービスメタデータをデバイスメタデータに一致させることによって、対応するサービスをどのデバイス上に配置すべきかを決定し、デバイスメタデータは、スマートアイテムデバイスおよび関連するローカルネットワークの現在の状態を含むことができる。また、本書に説明するように、サービスマッパー１４０は、（システムモニタ１４２によって認識されるように）ネットワーク状態の変化を含むあるイベントまたは条件に反応することができ、その後、所与の配置要求／要件をより満たすために、サービスを再マッピングするか、サービスのインスタンスを追加または除去するかを決定することができる。
【００３１】
ビジネスプロセスブリッジ層１０６は、デバイスレベルサービス層１０４を介して提供されるデバイス層１０２におけるデバイスからのデータを集約し、そのデータをデバイス層１０２からビジネス関連情報に変換するように設計されたサービスを含む。そうすることで、バックエンドの企業アプリケーションシステムに送られるデータの量を削減することができ、企業アプリケーションシステムの異なるものに対してビジネスロジックを実行することができる。
【００３２】
例えば、１つまたは複数のルールプロセッサ１２０を使用して、着信メッセージを解析し、基本操作サービス（例えば、アイテム移動、関連付け、関連付けの解除、またはデバイスの読取り／書込み）をサポートし、情報のクエリをサポートすることができる。ルールプロセッサ１２０は、実行または参考にされるべき、他の任意の基本操作サービスを定義または参照するユーザ定義のビジネスルールを処理する。このようなルールと基本操作サービスとを使用することは、異なるビジネスシナリオにシステム１００を適応させる柔軟性のある枠組を提供する。
【００３３】
ルールプロセッサ１２０は、データレポジトリ１２２を使用して、関心のある全ての物理的オブジェクトを追跡することができる。例えば、所与の追跡してきたオブジェクトの現在の状態、位置、タイムスタンプ、または関連するビジネス取引の追跡を続け、ならびに予測される将来の行動を追跡することができる。データレポジトリ１２２から集積された情報は、定期的に、例えば日毎または月毎に、報告することができる。
【００３４】
１０２、１０４、１０６層の操作の一例は、「物品受取り」シナリオを含む。例えば、オブジェクトを受信者に配送する供給元は、電子製品コード（ＥＰＣ）等のオブジェクト識別子と共に、出荷する全てのオブジェクトのリストを含む事前出荷通知（ＡＳＮ）を送信することができる。ＡＳＮはデータレポジトリ１２２に記憶することができる。例えば受取りドックのドアにて、出荷したものがデバイス層１０２に到着し、ＲＦＩＤリーダを通過すると、ＥＰＣは、ＲＦＩＤリーダによって読取られ、ルールプロセッサ１２０へ送信される。ルールプロセッサは、メッセージが来たリーダのＩＤを調べ、リーダの位置と役割を決定し、その後、受取った積荷の処理を担当する適切な基本操作サービスを呼出す。この操作サービスは、取得したＥＰＣを前のＡＳＮから予測されるＥＰＣと比較し、一致する場合、配送されたものが到着し完了したことを企業アプリケーション１３２へ報告する。実行された操作サービスは、次に、データレポジトリ１２２内のデータを更新することもできる。上述のサービスならびに関連メッセージを送受信するサービスは、サービスマネージャ１２６によって管理することができる。
【００３５】
システム接続層１０８内のコンポーネントを使用して、異なるアプリケーションシステムを接続し、システムとデータとの統合をサポートすることができる。例えば、メッセージとデータは、情報交換および変換モジュール１２８によって正しいバックエンドシステムにルーティングでき、また、これによって意味構造的に正しい統合が可能になる。メッセージルーティングおよび変換サービスに加えて、システム接続層１０８は、外部サービスレポジトリ１３０を含むこともできる。所与のＳＩＩサービスが、開発環境からデバイスレベルサービス層１０４のサービスレポジトリ１４４ａまたはデバイスレポジトリ１４４ｂに配置されるときに、外部サービスの記述は、外部サービスレポジトリ１３０に登録することができる。レポジトリ１３０は、インフラストラクチャ１００の外部からアクセス可能なインフラストラクチャ１００によって提供される全てのサービスのレジストリを含む。
【００３６】
企業アプリケーション層１３２は、例えば、企業ビジネスアプリケーションの制御と管理を担う従来の企業ＩＴシステムを含む。特定のビジネスプロセスを対象とする企業アプリケーションは、単一のプログラムでなくてよく、所望の機能を果たすために協働する異なるサービスで組み立てられてよい。このようなサービスは、同一の企業システム、企業アプリケーション層１１０内の（おそらく取引相手のサイトにある）別の企業システム、または下位層からのシステム（例えば、デバイス層１０２のスマートアイテムデバイス）によって提供することができる。
【００３７】
図１において最後に、開発ツール１３４は、企業アプリケーション１３２と他のアプリケーション／サービスとを生成するツールを指す。インフラストラクチャ１００に統合された開発環境を使用することによって、企業アプリケーション空間における周知の開発ツールと同様の方式で、基本サービスの実装をサポートすることができる。更に、開発ツール１３４は、必要なサービスメタデータの作成、ならびに既存サービスの新規アプリケーションへの含有を可能にすることができる。実施形態の１つにおいて、検証手順は、このような開発ツール１３４等の利用可能な設計時ツールとして実装することができる。更に、開発ツール１３４は、開発者が、あるサービスをどこで実行すべきかを指定し、個々のサービスインスタンスを構成し、所望の方式でサービスを配置することを可能にする。すなわち、開発者は、開発ツール１３４を使用してサービスメタデータ／実行ファイル１３６を開発し、その後、サービスおよびデバイスメタデータ／実行ファイル１３６のうち所望のものを、サービスレポジトリ１４４ａおよびデバイスレポジトリ１４４ｂに格納するために提供し、および／または、記憶と同時にもしくはその後に、サービスマッパー１４０によってマッピング／再マッピングすることができる。
【００３８】
図１に示されるインフラストラクチャ１００内で、（ここでは、通常、「コンポーネント」で表す）多数の異なる個々のデバイスとサービスが、互いに連結することができる。図１は、ユビキタスコンピューティングインフラストラクチャの一例を示すが、他のインフラストラクチャも、多くの異種のコンポーネントから組み立てることができる。異なるコンポーネントは、異なる技術およびプロトコルを使用して通信することができ、これは図２との関連で記述する。
【００３９】
図２は、デバイス通信の開放型システム間相互接続(「ＯＳＩ」) モデル２００の概略図で、通信の７つの層が定義されている。インフラストラクチャ内でデータを交換するためのインフラストラクチャのコンポーネントにとって、図２に示す抽象概念の７つのすべての層上で通信することが可能でなければならない。
【００４０】
物理層２０２は、ＯＳＩモデル２００の最下層である。物理層２０２のレベルにおいて、電気的規格やタイミングの問題等の通信インタフェースが定義される。図３に示すように、物理層２０２において、コンポーネントのおおまかな特性を、「方向」３０２、「信号符号化」３０４および「通信媒体」３０６等のオントロジークラスの観点から定義することができ、コンポーネントの物理層のモデルに統合することができる。コンポーネントの物理層のモデルは、そのコンポーネントに関連付けられたメタデータの形で格納することができる。コンポーネントの物理層の特性についての情報は、さらにクラスとサブクラスとの観点から定義することができる。コンポーネントのクラスとサブクラスは、より高いレベルのツリーが、サブクラスで定義された情報を継承するように、ツリー構造に配置することができる。このように、一例において、コンポーネントについての物理ファイル層にある情報は、そのコンポーネントが無線通信媒体を使用すること、および、信号を搬送するのに電磁波（ＥＭ Ｗａｖｅｓ）を使用することを示すことができる。
【００４１】
「方向」クラス３０２は、コンポーネントの物理的レベル上で情報フローの方向付けをおこなう高レベルクラスである。コンポーネントの通信の方向は、「一方向」３１０および「双方向」３１２等のオントロジーサブクラスの観点から定義することができ、通信の方向が一方向である場合、通信の方向は、更に、「出る方向」３２０および「入る方向」３２２等のオントロジーサブクラスの観点から定義することができる。コンポーネントの方向クラスのインスタンス化は、別のコンポーネントとの互換性に関して再帰的でなくてもよい。例えば、一方向性の発信通信ポートは、別の同種のポートにプラグされることはできない。なぜなら、第１ポートと第２ポートは両方とも送信のみ可能で受信はできないので、第２ポートは、第１ポートから情報を受信できないからである。
【００４２】
「信号符号化」クラス３０４は、送信において信号をどのように符号化するか（例えば、２進数の０）を定義することができる。例えば、信号のバイナリ値は、信号の電気的な値が、ある閾値を上回るか下回るかに基づいて決定することができ、これは、「信号符号化」のサブクラスでモデル化することができる。
【００４３】
２つのコンポーネントの互換性は、「通信媒体」クラス３０６について定義された値に依存することができる。例えば、コンポーネントのモバイル性要件に依存して、固定のケーブルリンクを有するデバイスは、許容可能であることも、ないこともある。このように、「通信媒体」クラスは、サブクラス「無線」３１４と「固定」３１６の観点から定義することができ、さらにそれぞれ、サブクラス「電磁波」３２４と「音」３２６と「光」３２８の観点、およびサブクラス「電気ケーブル」３３０と「光ケーブル」３３２の観点から定義することができる。さらに、無線通信用にある周波数が必要とされる場合、「周波数」は、「無線」サブクラス３１４と「固定」サブクラス３１６のどちらか一方、または両方のサブクラスとして定義することができる。
【００４４】
図４に示すように、データリンク層２０４のサービスは、物理層２０２の上部で、データ交換を扱う。データリンク層で扱われる問題は、例えば、「フロー制御」４０２、「エラー処理」４０４、「データ交換」４０６および「媒体アクセス制御」４０８であるオントロジークラスを通じて定義することができる。
【００４５】
任意の高レベルオントロジークラスは、「フロー制御」４０２である。コンポーネントのフロー制御機構は、サブクラスである「速度ベース」４１２と「信頼度ベース」４１０に分類することができる。信頼度ベース制御システムは、受信側が取得する用意がないさらなるデータは送信されないことを保証する。受信側のバッファが非常に限られている場合、この戦略は好まれ、アプリケーション制約の要件を形成するかもしれない。結果として、サブクラス「信頼度ベース」４１０と「速度ベース」４１２は、クラス「フロー制御」４０２のために、サブクラスとして含まれることができる。しかしながら、２つのコンポーネント間の通信がそれなしで行えるので、「フロー制御」クラスは必須ではない。
【００４６】
別の任意のサービスクラスは、「エラー処理」４０４である。例えば、エラーは、いくつかの一般的な方法でデータリンク層において取扱うことができる。例えば、冗長符号化が採用されることによって、データリカバリ機構４１４を可能にし、または異なるサービスが、エラーを検出し、メッセージを破棄して破壊されたデータを避けることができ（４１６）、あるいは、データ破壊が検出された場合、データを明確に再要求することができる（４１８）。これらの異なる戦略はサービスの質に影響を与えるので、非機能的なアプリケーションの制約を受けやすく、そのためモデルに含まれる。
【００４７】
「データ交換」４０６クラスは、データリンク層２０４の必須のクラスであることができる。なぜならそのサブクラスが、異なるコンポーネント間の通信戦略を詳細に定義しているからである。「データ交換」クラスの主なサブクラスは、「コネクション指向」４２０と「コネクションレス指向」４２２通信であり、この選択は、待ち時間、同一順序配信および完了の問題に影響を与えることがある。「コネクションレス指向」サブクラス４２０は、データ交換が「確認応答される」４２４または「確認応答されない」４２６かの観点で更に定義することができ、後者の場合、交換が「ブロードキャスト」４２８かどうかの観点から定義することができる。
【００４８】
クラス「媒体アクセス制御」４０８は、衝突検出４３０と衝突処理４３２の問題を取り扱う。さらに、データ評価スキーム４３４またはキャリア検知４３６を介して、衝突検出４３０を実行することができる場合、衝突処理４３２は、確率論的方法４３８または決定論的方法４４０を伴うことができる。
【００４９】
図５に示すように、ネットワーク層２０６は、通信ネットワークを介した情報の転送に関する。ＯＳＩモデル２００のより下位層２０２および２０４とは対照的に、ネットワーク層において、接続は、複数のホップを補うことによって実現できる。すなわち、通信者は、互いの間に直接の物理リンクを有さなくてもよく、連結されたコンポーネントの連鎖を介して接続することができる。ネットワーク層２０６におけるサービスによって、データパッケージが、発信元から所望の宛先へこの鎖を介して移動することが可能になる。インタフェースモデルに関して、オントロジークラスである「ルーティング」５０２、「エラー処理」５０４、「エンドポイント」５０６を定義することができる。
【００５０】
ネットワーク層の主要タスクは、「ルーティング」クラス５０２によって特徴づけられるように、パッケージルーティングを定義することになる。「ルーティング」の追加のサブクラスは、ルーティングスキームは固定であることを示す「静的ルーティング」５１２と、ルーティングスキームは変化し得ることを示す「適応ルーティング」５１４を含むことができる。第１サブクラスの機構は、静的ネットワークにのみ採用されうるが、「適応ルーティング」クラス５１４は、ネットワークの変化に適応する方法を表す。「適応ルーティング」クラス５１４は、さらにクラス「接続変更」５１６、「デバイス移行」５１８および「ルータ移行」５２０によって記述することができる。サブクラス「接続変更」５１６は、ピア間の接続の変更に対処する方法を表し、これは、ネットワークがあるリンク上で輻輳した場合、または、接続が切れた場合に、新たなルートを見つけることを可能にする。サブクラス「デバイス移行」５１８の技術は、デバイスが１つのネットワークゲートウェイから別のネットワークゲートウェイへ移動できる場合、例えば、携帯電話が１つのゲートウェイから別のゲートウェイへと移動する場合に、使用される。クラス「ルータ移行」５２０は、ネットワーク内でルータの移行を可能にする技術を対象とし、これは、ルータが動的コンポーネントであるアドホックメッシュネットワークで特に有用である。
【００５１】
ネットワーク層のエラー処理５０４は、普通、データ転送の完了を確実にするため、またはネットワークを介して異なるルートを移動するパッケージの順序を維持するために採用される。これらの態様は、サブクラス「完全性保証」５２２と「順序付けられた配信」５２４とによって表される。ネットワーク層のプロトコルは、配信されたデータの破壊のチェックもおこない、従って、サブクラス「破壊検出」５２６が、概念モデルに含まれる。
【００５２】
ネットワーク層におけるデータ伝送の問題は、クラス「データ交換」５２８によって記述される。データリンク層２０４におけるのと同様に、このクラスは、同じ名称の通信戦略を表す２つのサブクラス「コネクション指向」５３０と「コネクションレス指向」５３２を有する。この抽象化レベル上で、アドレス指定機構は、ネットワークにおける通信の可能性に重大な影響を与え。従って、アドレス指定サブクラス「ユニキャスト」５３４、「マルチキャスト」５３６、および「ブロードキャスト」５３８は、「コネクションレス指向」５３２のサブクラスとして含まれる。
【００５３】
サブクラス「ユニキャスト」５３４のプロトコルを使用する処理は、一度に１つの特定のリソースへ情報を転送できる。逆に、サブクラス「ブロードキャスト」５３８のプロトコルは、ネットワークのすべての参加者へ情報を送信するのに使用できる。「マルチキャスト」サブクラス５３６は、ブロードキャストのプロトコルと類似のプロトコルを表すが、マルチキャストプロトコルは、ネットワークの会員全員の専用サブセットに情報を送信できる。
【００５４】
クラス「エンドポイント」５０６は、全ての可能性のある通信のエンドポイントを保持する。これは、ネットワークで使用されるアドレス指定スキームを指す。例えば、ＩＰプロトコルに関して、「エンドポイント」は、全てのＩＰアドレスのクラスである。
【００５５】
トランスポート層２０８は、ネットワーク層２０６の上部に構築され、ネットワークにおけるエンドツーエンド接続を提供する。トランスポート層で提供されるサービスは、ネットワーク層でも同様に提供されるが、２つの層の抽象化レベルは異なる。ネットワーク層２０６の機能性を使用すると、トランスポート層２０８のサービスは、接続エンドポイントにおけるマシン上でのみ実行する必要があり、ルータに影響を与えない。図６に示すように、トランスポート層２０８は、クラス「エンドポイント」６０２、「フロー制御」６０４、および「データ伝送」６０６を含む。
【００５６】
クラス「エンドポイント」６０２は、通信の可能性のある全てのエンドポイントを保持し、ネットワーク層２０６における同じ名称のクラスと類似している。このクラスは、アプリケーション用の仮想接続のエンドポイントに使用されるアドレス指定スキームを指し、例えば、ＴＣＰプロトコルに関して、「エンドポイント」は、全てのＴＣＰポートのクラスである。ネットワーク層２０６上のように、トランスポート層２０８上のエラー処理は、同一順序配信とデータ転送完了を確実にすることができ、またはデータ破壊を検出することができる。
【００５７】
機能の観点において、クラス「フロー制御」６０４の概念は、データリンク層２０４で見られるフロー制御機構の概念と類似していて、両方の層がポイントツーポイント接続を取扱うので、これは当然である。すなわち、データリンク層２０４は、物理レベルでポイントツーポイント接続を扱う一方で、トランスポート層２０６は、論理レベルでポイントツーポイント接続を扱う。このように、データリンク層２０４上の「フロー制御」クラス４０２と同様に、トランスポート層２０８における「フロー制御」クラス６０４は、サブクラス「信頼度ベース」と「速度ベース」を含む。
【００５８】
クラス「データ伝送」６０６は、トランスポート層で採用されることが可能な通信戦略を指す。２つのサブクラス「コネクション指向」と「コネクションレス指向」とは、下位層における同じ名称のサブクラスに対応する（例えば、データリンク層２０４のサブクラス４２０と４２２、およびネットワーク層２０６のサブクラス５４０と５４２）。
【００５９】
いくつかのオントロジークラスとサブクラスについて記述したが、他の多くのクラスとサブクラスとが可能であり、組み立ておよび検証モデルで定義し、使用することができる。
【００６０】
再び、図２を参照すると、通信問題が、モデル２００の下位の４つのＯＳＩ層２０２から２０８において向けられることは明らかである。セッション層２１０、プレゼンテーション層２１２、およびアプリケーション層２１４は、抽象化の高位レベルを指し、通常、アプリケーションの意味構造の事柄を扱う。結果的に、本明細書で説明される組み立てモデルでは、下位レベルの通信問題に焦点を合わせ、高位レベルでの拡張については確定していない。
【００６１】
本明細書で説明されるコンポーネント（例えば図１を参照）、および異なる抽象化層における通信の概念（例えば図２から６を参照）を、インタフェース記述を生成するために使用される最高レベルのオントロジーの概念と共に使用することによって、ユビキタスコンピューティングシステム（例えば、スマートアイテムアプリケーション）用に仕立てられる組み立てモデルを、以下により詳細に記述する。
【００６２】
コンポーネント指向アーキテクチャにおいて、システムは、コンポーネントの組み立てとしてモデル化される。コンポーネントは、機能をカプセル化し、コンポーネント間でポートと呼ばれる適切に定義されたインタフェースを提供する。コンポーネントからのシステムの組み立ては、各コンポーネントのポートを連結する対話コンポーネント（コネクタ）で達成することができる。コンポーネントは、デバイス境界をわたって対話することができるので、組み立ては、ソフトウェアの能力が原因の通信問題ならびに利用されるハードウェアに影響される。従って、個々のコンポーネントの通信能力およびコンポーネントのグループの通信能力は、このような問題を扱うコンポーネントモデルに反映される。モデルにおいて、マルチコンポーネントシステムの相互操作性を考慮することによって、物理層を含む全てのプロトコル層に占める通信問題を扱う。このように、ポート、コネクタ、およびコンポーネントは、（例えば、態様、特性、能力、およびインスタンスを記述したメタデータで）詳細にモデル化され、スマートアイテム領域の問題にあたる。ポート、コネクタ、およびコンポーネントを強調して表現することは、モデルに基づいてアプリケーションをどのように組み立てるか（すなわち、モデルの構築ブロックの意味構造面を、組み立て処理において、どのようにインスタンス化し、エンベロップし、結合するか）に影響を与えることができる。
【００６３】
スマートアイテムインフラストラクチャは、多数の異なるコンポーネントおよび対話機構（例えば、目的構築プロトコルおよび専用周波数を使用するＲＦＩＤチップと、無線ネットワーク用のＩＥＥＥ８０２．１１規格を実装するＰＤＡ）を使用し、コンポーネント間の互換性は保証されないので、ポート、コネクタ、およびコンポーネント（すなわち、組み立てモデルの構築ブロック）は、コンポーネントおよび複数のコンポーネントの組み立てに関連するハードウェア、ソフトウェアおよび通信プロトコルを説明する「情報豊富な」コンポーネントとしてモデル化される。
【００６４】
図７を参照すると、第１デバイス７０２と第２デバイス７５２とを接続するとき、デバイスインタフェースは、図７に示すようにコンポーネントのポートを包含する。従って、デバイス７０２とデバイス７５２間の接続は、ホストデバイス上で実装される通信能力上に成り立ち、この能力は、デバイスハードウェアならびにデバイス上で実行されるソフトウェアによって決定される。このような対話面を説明するために、組み立てモデルにおいて、コンポーネント、ポート、およびコネクタは、スマートアイテムインフラストラクチャに関連するように、コンポーネント、ポート、およびコネクタの機能と能力を詳細に記述する豊富な特徴を有するようにモデル化される。
【００６５】
例えば、コンポーネント７０４は、ソフトウェアコンポーネント７１２（例えばサービス）、位置づけられたかもしれないプラットフォーム７０６（例えばオペレーティングシステム）、デバイス７０２、ソフトウェアポート７０８、デバイスポート７１０、またはこれらの実体の入れ子の組合せを表すことができる。ポート７２０は、コンポーネント部品全ての結合された通信能力を有することができ、それは結合され、すなわち、デバイス７５２のポートは、デバイスによって使用されるソフトウェアポート７５６およびデバイスポート７５８についての情報を含むことができる。コネクタ７３０は、「ポート」間の接続を記述し、目標設定における通信チャネルの具体的なインスタンス化と解釈することができる。これについて次に詳細に記述する。
【００６６】
ポート７０８、７１０、７５６および７５８は、コンポーネントへのインタフェースを表し、多数の特性がポートをモデル化するために定義される。例えば、ポート７５６はソフトウェアポートであることができ、ポート７５８はデバイスポートであることができ、このオントロジー的概念のポートの特性へのマッピングは、関数has_typeによって形式的に記述され、has_type:PRT→｛“ソフトウェア,” “デバイス”｝と定義される。別の例において、ポート７０８、７１０、７５６、および７５８は、それらが許可するデータフロー方向を有することができ（例えば、“入る方向”、“出る方向”、または“双方向”）、この概念のポート特性へのマッピングは、関数has_dataflowで形式的に記述され、has_dataflow:PRT→｛“入る方向、”“出る方向、”“双方向”｝と定義される。多数の他の追加特性がポートに関して定義することができ、意味構造の拡張をポート記述へ結びつけるのに、その特性が使用され、これは、通信概念の実現を記述する（例えば、ポートに関してメタデータに格納されるような）特性によって示すことができる。例えば、ポートは携帯電話のゲートウェイとして動作するという概念は、オントロジークラス「通信媒体」、「無線」、および「電磁波」を通して表現することができ、携帯電話ゲートウェイポートのモデルは、メタデータ特性を教え込み、ポートが概念を正確に表していることを示すことができる。組み立てモデルの正確さを保証するために、ポートに必要な各概念を（例えば、概念に対応するメタデータ値を定義することによって）実現することが必要である。実現は、そのポートメタデータを、別のポート、コンポーネント、または結合のメタデータへ直接結合する際に要求されるか、または結合は、高位のプロトコルレベルで生じことができる。
【００６７】
通信概念からポートメタデータへのこのようなマッピングを使用して、どのように個々のポートを接続において使用することができるかを、すなわち、どの技術を使ってポートを別のコンポーネントに結合できるかを指定することができる。例えば、多数の埋め込みデバイスから組み立てられたシステムをモデル化するとき、システムの１つのコンポーネントは、低電力で送信のみのモードで動作するセンサであるかもしれず、他のコンポーネントは、第１の配線接続で低電力コントローラであり、第２のセンサに符号を配信することができる構成可能なコントローラであるかもしれない。センサのポートと第１コントローラのポートのメタデータは、コントローラがセンサからデータを受信するために連結できるように、低電力モードで動作したときに、センサポートの通信プロトコルが第１コントローラのポートの通信プロトコルと一致することを示すことができる。逆に、第２コントローラのポートのメタデータは、センサとの通信は全く不可能か、コントローラが低電力状態で使用されるとき不可能であることを示すことができる。このように、コンポーネントとそのポートのメタデータを使用することによって、タイプレベルではなく（またはタイプレベルに追加して）通信とインスタンスのレベルで、センサとコントローラの互換性を決定する。別の例において、無線通信において、結合技術は、通信周波数、変調技術、ハンドシェークプロトコル等の概念によって決定できる。従って、ポートの特性を指すメタデータは、組み立ての有効な結合を保障する概念に結び付けられる。
【００６８】
コンポーネント７０４は、ソフトウェアコンポーネント、ミドルウェア（例えばオペレーティングシステム）、デバイス、またはこれらの要素の組合せのいずれかであってよい。複数のコンポーネントを共にマージして１つの組合せを形成することができ、その組合せからの結果のコンポーネントにアクセスするために、新規のインタフェースが提供される。例えば、ソフトウェアアプリケーションコンポーネント７０６とプラットフォームコンポーネント７１２をマージでき、結果の組合せコンポーネントのインタフェースはポート７０８であることができる。
【００６９】
複数のコンポーネントから組み立てられたシステムまたはアプリケーションをモデル化するとき、組み立て計画の検証するために使用されるコンポーネントモデルは、モデル化されたシステムまたはアプリケーションの一部であるコンポーネントのすべてのタイプ、すなわち、すべてのソフトウェア（ミドルウェアも含む）コンポーネントタイプとすべてのデバイスコンポーネントタイプを保持する。タイプ自身は、同一の特性を有する全てのコンポーネントの集合として定義される。例えば、同一クラスの２つのＲＦＩＤタグまたは同一のハードウェアを有する２つのＰＤＡは、同一のデバイスコンポーネントタイプである。しかし、コンポーネントのインスタンス化は、具体的なデバイスまたはソフトウェアの配置されたコピーに関連しているので、同一のタイプの２つのコンポーネントは、モデル化されたシステムまたはアプリケーションにおけるインスタンスレベルで異なることがある。
【００７０】
コンポーネント７０４は、他のコンポーネントとのインタフェースをとることができるためのポートの集合を提供する。形式上、これは、ポートの集合へコンポーネントをマッピングするとして表現することができる。このように、モデル化されたシステムのコンポーネントの相互操作性を考慮するとき、コンポーネントタイプは、コンポーネントをマッピングするポート群の観点から分析することができる。
【００７１】
コネクタ７３０をモデルにおいて使用してコンポーネントを連結することができる。このように、コネクタは、複合アプリケーションにおいてこのチャネルを実際に使用させることによってインスタンス化される通信チャネルの抽象的な概念を表す。コネクタのインスタンスは、ソースと各接続の宛先を指し、この情報は、コネクタに関連付けられたメタデータとして格納することができる。コネクタ７３０の追加メタデータは、コネクタに連結されたポートの特性から得ることができる。例えば、無線コネクタは、それが連結されるポートが無線通信する能力を有することを要求する。
【００７２】
コンポーネント７０４、ポート７２０、およびコネクタ７３０は、通信概念と副概念との深い階層を含み、これによって、ユビキタスコンピューティングアプリケーションの組み立てモデルの基本的構築ブロックとして使用することができ、これは、提案されたアプリケーションの実行可能性を検証するために使用することができる。各コンポーネント、各ポート、および各コネクタの基本的な通信の詳細に関する定義を使用することに加えて、高位のレベルの概念を定義してアプリケーションの各部分を表現することもできる。このような高位レベル概念は、「仕様」の観点から定義することができる、これは、予め定義された概念の集合とそれらの概念を記述する特性の値を表す。このように、「仕様」をアプリケーションのモデルで使用することによって、インタフェースの記述においてあるレベルの抽象化を達成することができ、通信概念をより詳細な副概念へ分割する代わりに、概念と副概念との特徴を記述するために仕様を使用することができる。例えば、仕様「ＥＰＣグローバル」を定義して、スマートアイテムインフラストラクチャで使用されるＲＦＩＤタグの通信周波数や信号符号化等のＲＦＩＤタグの通信面を表すことができる。
【００７３】
図８Ａと８Ｂとを参照すると、複合アプリケーションのモデルは、アプリケーションの構成要素である個々のコンポーネントモデル（すなわち、コンポーネント７０４、ポート７２０、およびコネクタ７３０構築ブロック）から構築することができる。個々のコンポーネントモデルを組み合わせるための組み立て計画は構築され、次に、複合アプリケーションのモデルは、組み立て計画において連結されているコンポーネントを順次組み立てることによって生成される。従って、図８Ａに示すように、第１コンポーネント８０２はポート８０４を有することができる。第２コンポーネント８０６は、ポート８０４に接続される第１ポート８０８と第２ポート８１０を有することができる。第３コンポーネント８１２は、ポート８１０に接続されるポート８１４を有することができる。組み立て計画は、組み立てモデル８５０を生成するための２ステップ処理を指定することができる。すなわち、第１に、ポート８２２を有するコンポーネントモデル８２０をコンポーネント８０２と８０６から組み立て、第２に、組み立てモデル８５０をコンポーネントモデル８２０とコンポーネント８１２から組み立てる。または、図８Ｂに示すように、組み立て計画は、コンポーネント８０６と８１０からポート８２６を有するコンポーネントモデル８２４を組み立て、次にコンポーネントモデル８２４とコンポーネント８０２から組み立てモデル８５０を組み立てることによって生成される組み立てモデル８５０を指定することができる。インスタンスレベルに存在するように図８Ａと８Ｂに示されているが、組み立て計画は、タイプレベルならびにインスタンスレベルに存在することができる。
【００７４】
図８Ａと８Ｂを参照して記述したように、組み立て計画を使用することによって、構成コンポーネントから複合コンポーネントを順次組み立てることによって、複雑な組み立てが生成できる。複合コンポーネントは、複数の個別コンポーネントから組み立てられ、結果のコンポーネントモデルは、個別コンポーネントの接続されたポートをマージして、その個別コンポーネントのポートの特性を含むインタフェース記述を獲得する。結果として、通信概念のコンポーネント特性へマッピングは、通常、結果のコンポーネントにおいては、個別コンポーネントにおいてと異なる。例えば、マージされた個別コンポーネント間の接続に関する特性は、個別コンポーネントの組み立てに組み立て計画の一部として含まれない。
【００７５】
個別コンポーネントから組み立てられたコンポーネントの通信概念をモデル化するのに必要な特性を決定するために、２つの事例が考察されなければならない。第１の事例において、図９Ａを参照すると、ポート９０２、９０４、および９０６を有するコンポーネント９００は、ポート９１２、９１４、および９１６を有するコンポーネント９１０と結合されることができる。個別コンポーネントの連結されたポート９０２と９１２が、１つの接続のみを結合できるとき、結果の複合コンポーネント９２０のインタフェースポートの集合は、結び付けるポートを除く構成コンポーネント９００と９１０のインタフェースをプールすることによって定義される。従って、図９Ａに示すように、結果のコンポーネントは、ポート９０４、９０６、９１４、および９１６の特性によって定義される。第２の事例において、図９Ｂに示すように、接続されたポート９０２と９１２は、複数の接続を処理できる。このような場合、ポート９１２は、組み立ての結果のコンポーネント９２０のインタフェースの一部のままであり、その組み立てによって変化しない。代わりに、複製ポート９１２’が生成され、組み立て物９２０において使用される。ポート９１２’は、アイデンティティにおいてのみポート９１２とは異なるが、さもなければ、ポート９１２と９１２’は、同一の特性で定義される。
【００７６】
複合コンポーネントを組み立てるとき、有効な組み立てのみが、組み立て処理中に組み立て互換性ルールをチェックすることによって決定され、作成される。組み立て処理の追加検証は、追加の適格性ルールとアプリケーションへの制約を取り扱う。これらのルールは全て、２つのコンポーネントが共に連結されるときにチェックされる。結果として、検証は、組み立て処理中に行われる操作の一部である。
【００７７】
互換性ルールは、２つのポートが共に連結できるかどうかを決定する。このように、デバイス間に直接リンクを確立するためには、組み立て計画で連結されたコンポーネント間の通信に必要な特性は、組み立て計画に従って連結されるべきポートに存在しなければならない。デバイスのポートに関しては、これらの特性は、３つの下位ＯＳＩ層の特性である。従って、１つのポートがある特性の具体的な実現を必要とする場合、この実現は、他方のポートでも利用可能でなければならない。
【００７８】
組み立てモデルにおいて、実現の利用可能性は、２通りに表現することができる。１つの方法において、実現は、その関係によって明示的にコンポーネントに関連させることができる。例えば、ポートのメタデータで定義された特性は、ポートが２．４ＧＨｚの搬送波周波数で通信することを示すことができる。別の方法において、各実現は、そのコンポーネントが準拠する仕様によって定義することができる。例えば、ポートのメタデータにおいて定義された特性は、８０２．１１（ｇ）規格を使用してポートが通信することを示すことができる。
【００７９】
組み立て計画で連結された２つの再帰的なポートをチェックすることは、これらの互換性ルールを満たし、それゆえに組み立てモデルにおいて連結でき、各通信面、およびポートによって必要と示された通信面の定義された各実現は、対応する連結されたポートによって提供されねばならない。非再帰的な互換性のある態様の場合、ポートの互換性は、連結されたポートが互いに有効な相手であるかどうかを考慮することによって検証することができる。例えば、「一方向」で「入る方向」の通信を提供するポートは、「一方向」で「出る方向」の通信を提供するポートの有効な相手であることができる。このように、一実装において、一方向にブロードキャストする無線局のポートは、一方向通信を受信する無線受信器のポートの有効な相手となることができる。
【００８０】
組み立てモデルは、組み立て内の２つの論理的なエンドポイント（すなわち、一連の連結されたポート群の最も離れた２つのポート）間の接続で満たされることになる制約を要求することもできる。例えば、エンドツーエンド接続に関する制約は、配信されるデータパッケージは正しい順序であってもよく、または破壊のチェックが実施されることであってもよい。このような制約は、組み立て計画における論理的エンドポイントに対応するコンポーネントポートに対して設定することができ、要求された意味構造を伴う態様は、存在に関してチェックすることができる。組み立て計画における各リンクでの一連の接続に続いて、要求された概念の実現（例えば、接続をデータ破壊に関してチェックすること）を見つけることができる。
【００８１】
適格性ルールを構成モデルで使用して、複合アプリケーションにおいて通信が十分に記述されていることを検証する。従って、通信概念ｃが、組み立て計画におけるコンポーネントに関連付けられた特性によって定義される場合、通信概念ｃが依存する概念クラスの他の特性もまた、定義されなければならない。例えば、ポートがＴＣＰ接続を指定する場合、複合アプリケーションが適格であるために、ネットワークプロトコル（ＩＰなど）は、通信するためにコンポーネントが用意されていなければならない。
【００８２】
異なる通信概念を表すクラス間の関係は、ＯＳＩ層２０２から２１４に続くクラス間の階層構造を使用して定義することができる。例えば、ＯＳＩ層２０４におけるデータリンクのタイプとして定義されるポートの特性（例えば、ＴＣＰ接続）は、高位ネットワークＯＳＩ層２０６の一部である特性（例えば、ネットワーク上のデータ交換用ＩＰプロトコル）から依存するように定義することができる。その後、組み立て計画の適格性をチェックしているとき、ポートのＴＰ接続特性の依存性が、依存する特性（例えば、ネットワークのＩＰプロトコル特性）に対してチェックできる。
【００８３】
タイプレベルで組み立てモデルを検証することに加えて、モデル化されたコンポーネントのインスタンスへの具体的なマッピングが分かっている場合、モデルもまた、インスタンスレベルで検証することができる。インスタンスレベルにおいてこのようなチェックを可能にするために、モデルは、アプリケーションの実行がサポートされる物理的条件と環境について詳細に記述するべきである。例えば、デバイスの位置（Ｐｏｓｉｔｉｏｎ）と場所（Ｌｏｃａｔｉｏｎ）は、デバイス間の接続に影響を与えることができる。ある具体例において、無線周波数通信を使用する２つのデバイスが、金属性の物によって分断されることが分かっている場合、インスタンスレベルでの検証は、その２つのデバイスが、それ以外は互いに完全に互換性があるにもかかわらず、障壁のために通信できないことを示す。別の特定の例において、２つの無線周波数通信のデバイスは、通信が行えないほど大きな物理的距離によって分断されることもある。
【００８４】
インスタンスレベルで複合アプリケーションをモデル化するとき、アプリケーションのインスタンス化されたモデルは、そのモデルのタイプレベルの改良である。結果として、個々のタイプレベルのモデルによって提供される情報と少なくとも同じ情報を表す。従って、インスタンス化されたモデルにおいて、ポート特性と通信概念との間の各マッピングｍ毎に、インスタンスレベルで同じ関係を示すマッピングｍｉが存在する。インスタンス化されたモデルにおいて、個々のタイプレベルの組み立てモデルにおける各コンポーネントのタイプとポート毎に１つのインスタンスが存在し、このインスタンスは、タイプの情報すべてに加えて、追加のインスタンス固有情報を含む。インスタンス化されたコネクタは、２つの選択されたデバイス間の具体的なリンクをマークする。
【００８５】
このように、組み立てモデル上の制約は、アプリケーションの目標設定における制限に起因することができる。例えば、ある通信チャネルは、法的手段またはセキュリティポリシーによって規制されることがあり（例えば、ある無線ＲＦＩＤリーダは、異なる管轄における質問信号（Ｉｎｔｅｒｒｏｇａｔｉｏｎ  Ｓｉｇｎａｌ）の許容信号強度に関する異なる規制のために、欧州では使用できるが米国では使用できないかもしれない。）、この種の制約は、検証することができるコネクタに影響を与え得る。これは、１つの目標設定においては有効な組み立て計画が、別の設定では無効となる場合があることを示唆する。
【００８６】
インスタンスレベル上で組み立てモデルの検証するとき、多数の異なるルールを使用してモデルの検証することができる。ルールを使用して、接続において使用される通信概念全てが目標設定において実現可能として明示的に定義されているかどうかをチェックすることができる。例えば、目標設定は、デバイスが８０２．１１（ｇ）規格を使用して通信を行うことを必要とし、このルールは、モデルのコンポーネントが明示の定義を遵守していることを検証することができる。別のルールを使用して、接続で使用される通信概念用に指定された値が、目標設定において実現可能として定義されているかどうかをチェックすることができる。例えば、目標設定は、デバイスが特定の無線周波数を使用して通信することが要求され、このルールは、モデルのコンポーネントがこの周波数で動作可能なことを検証することができる。
【００８７】
インスタンスレベル上で、別のルールを使用して、コネクタの具体的なインスタンスによって使用される通信概念は、このコネクタに対して実現可能であるとして明示的に指定されるかどうかを検証することができる。例えば、目標設定は、コネクタはＵＬ（登録商標）承認済みであることを要求し、このルールは、コネクタがこの要件を満たすことを検証することができる。インスタンスレベル上で、別のルールを使用して、コネクタの具体的なインスタンスによって使用される通信概念に関して定義された値は、このコネクタに対して実現可能であるとして明示的に指定されるかどうかを検証することができる。例えば、目標設定は、あるゲージワイヤを使用して２つのデバイス間で信号を搬送することを要求し、このルールは、モデルのコンポーネントがこのようなゲージワイヤによって接続されていることを検証することができる。
【００８８】
さらに、ルールを使用して、接続で使用される通信概念の全てが、目標設定で実行可能でないとして明示的に定義されているかどうかをチェックすることができる。例えば、目標設定は、デバイスが８０２．１１（ｇ）規格を用いて通信しないことを要求し、このルールは、モデルのコンポーネントがこの明示的な定義を遵守していることを検証することができる。ルールを使用して、接続に使用される通信概念用に指定された値が、目標設定において実現可能でないとして定義されているかどうかをチェックすることができる。例えば、目標設定は、デバイスが、特定の無線周波数を使用せずに通信することを要求し、このルールは、モデルのコンポーネントがこの明示的な定義を遵守していることを検証することができる。
【００８９】
インスタンスレベル上で、別のルールを使用して、コネクタの具体的なインスタンスによって使用される通信概念が、このコネクタに対して実現可能でないとして明示的に指定されているかどうかを、検証することができる。例えば、目標設定は、コネクタは地下には設置されないことを要求でき、このルールは、このコネクタがこの要件を満たすことを検証することができる。インスタンスレベル上で、別のルールを使用して、コネクタの具体的なインスタンスによって使用される通信概念用に定義された値が、このコネクタに対して実現可能でないとして明示的に指定されているかどうかを、検証することができる。例えば、目標設定は、あるゲージより小さくないワイヤを使って２つのデバイス間で信号を搬送することを要求し、このルールを使用して、モデルのコンポーネントが、そのようなゲージワイヤによって接続されることを検証することができる。
【００９０】
図１０に示すように、個別コンポーネント、ポート、およびコネクタで組み立てられたアプリケーションをモデル化し、そのモデルを検証する処理１０００をステップ１００２で開始する。検証および組み立てアルゴリズムが動作することができるコンポーネントとポートとコネクタとのデータモデルを生成する（ステップ１００４）。データモデルは、アプリケーションで必要な通信技術についての詳細を記述する通信オントロジーを表すコンポーネントとポートとコネクタの特性を記述する。データモデルは、コンポーネントとポートとコネクタのメタデータで系統化され、任意の一般的なオントロジー表現言語（例えば、ＲＤＦまたはＯＷＬ）を使用してメタデータを作成することができる。
【００９１】
データモデルが生成された後に、組み立て計画を作成し（ステップ１００６）、組み立て計画の個々のステップを作成する（ステップ１００８）。組み立て計画を定義したあと、２つの個別コンポーネントとそのポートとから成るモデルから複合コンポーネントを組み立てる（ステップ１０１０）。組み立てステップ毎に、複合コンポーネントの適格性をチェックして（ステップ１０１２）、通信面の全てが十分に指定されたことを検証する。
【００９２】
連結されたポートの互換性をチェックし（ステップ１０１４）、結果の複合コンポーネントのポート記述を導出する（ステップ１０１４）。次に、所望の目標設定用に定義された制約を、特定のアプリケーションが使用する可能性のある通信チャネル用に定義された制約を含めて、チェックする（ステップ１０１６）。また、このステップでのチェックの間、デバイスエコシステムのグローバルポリシーまたは制限を考慮に入れる。複合コンポーネントが適切に築かれ、かつ目標設定の制約が満たされている場合（クエリ１０１８）、個別コンポーネントから複合コンポーネントを作成する（ステップ１０２０）。クエリ１０１８が満たされない場合、エラーおよび／または警告を出力し（ステップ１０２６）、処理は終了する（終点１０２８）。しかし、クエリ１０１８が満たされていて、組み立て計画の組み立てステップのすべてが処理されていなければ（クエリ１０２２）、組み立て計画の次のステップの組み立てを実行する（ステップ１０１０）。組み立て計画の全てのステップが処理された場合（クエリ１０２２）、結果の組み立てモデルを出力し（ステップ１０２４）、処理を終了する。
【００９３】
図１１に示すように、複合アプリケーションをモデル化し検証するシステム１１００のコンポーネントは、コンポーネントを記述するメタデータと、アプリケーションの目標設定についての情報と、アプリケーションの制約と、組み立て計画とを含むアプリケーションモデル１１０２を含む。このシステムは、アプリケーションモデル１１０２に使用される通信概念およびポート間の関係を記述するオントロジーの意味構造モデル１１０４も含む。通信技術の仕様についての知識は、アプリケーションモデル１１０２、ならびに意味構造モデル１１０４の両方に格納することができる。
【００９４】
アプリケーションモデル１１０２と意味構造モデル１１０４は、パーサ１１０６に入力することができ、これは、入力データのメモリ内表現を生成する。メモリ内表現内で、異なる種類のメモリ内データが、知識ベース１１０８、１つまたは複数のコンポーネントモデル１１１０、および１つまたは複数の組み立て計画１１１２に格納される。知識ベース１１０８は、検証を必要とされる知識識の交換可能な部分、すなわち、対話オントロジーと、各制約および仕様を含む目標設定のモデルを保持する。
【００９５】
スケジューラ１１１４は、組み立て計画１１１２から入力を受信し、複合コンポーネントが生成されチェックされる順序を決定する。ルールチェッカエンジン１１１６は、知識ベース１１０８、コンポーネントモデル１１１０、およびスケジューラ１１１４から入力を受信し、そのコンポーネントモデルが、一定の一貫性および適格性ルールと目標に固有の制約を満たしているかどうかをチェックする。
【００９６】
ルールチェッカ１１１６によって生成された結果は、モデルクリエイタ１１１８によって所望の出力フォーマットに変換され、これは、選択した組み立て言語、たとえばモデルへの入力として使用されるコンポーネントの記述に一致する言語の選択へ適合させることができる。更に、検査結果１１２０は、所望の目的に最適のフォーマットで出力することができる。例えば、開発環境で使用されているとき、検査結果１１２０は、人間が可読なエラーメッセージで出力することができ、自動組み立てツールで使用されているとき、検査結果１１２０は、機械可読フォーマットで出力しなければならない。
【００９７】
本明細書で記述する様々な技術の実装例は、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せにおいて実装してもよい。たとえばプログラム可能プロセッサ、単一のコンピュータ、複数のコンピュータのデータ処理装置によって実行、またはその動作を制御するために、実装例は、コンピュータプログラム製品として実装することもできる。すなわち、たとえば、機械可読記憶装置または伝播信号等の情報担体において、コンピュータプログラムは明白に組み込まれる。上記のコンピュータプログラム等のコンピュータプログラムは、コンパイラ型またはインタープリタ型言語を含むプログラミング言語の任意の形式で書くことができ、スタンドアローンプログラムとして、または、モジュール、コンポーネント、サブルーチン、もしくはコンピューティング環境での使用に適する他のユニットとして含む、任意の形式で配置することができる。コンピュータプログラムは、１台または複数のコンピュータ上で実行することができるように１つのサイトに配置、あるいは複数のサイトに分散させて通信ネットワークで相互接続することもできる。
【００９８】
方法のステップは、１つまたは複数のプログラム可能プロセッサによって実行することができ、プログラム可能プロセッサは、入力データを操作し、出力を作成することによって機能を実行するためのコンピュータプログラムを実行する。例えばＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）、またはＡＳＩＣ（特定用途アプリケーション集積回路）等の専用論理回路によって、方法のステップは実行され、装置は実装されることができる。
【００９９】
コンピュータプログラムの実行に適したプロセッサは、例えば、汎用および専用マイクロプロセッサと、任意の種類のデジタルコンピュータの任意の１つまたは複数のプロセッサの両方を例として含む。通常、プロセッサは、読み出し専用メモリ、ランダムアクセスメモリ、またはその両方から命令とデータとを受信する。コンピュータの要素は、命令を実行する少なくとも１つのプロセッサと、命令およびデータを記憶する１つまたは複数のメモリデバイスを含む。通常、コンピュータは、たとえば磁気ディスク、光磁気ディスク、または光ディスク等の、データを格納するための大容量記憶装置を１つまたは複数含むか、またはデータを受信、データを転送、もしくはその両方を行うように動作可能に結合することができる。コンピュータプログラムの命令とデータを組み込むのに適した情報担体は、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、あるいはフラッシュメモリデバイスの半導体メモリデバイス、内部ハードディスク、あるいはリムーバブルディスクの磁気ディスク、
光磁気ディスク、またはＣＤ−ＲＯＭディスクおよびＤＶＤ−ＲＯＭディスクを例として含む、任意の形式の不揮発性メモリを含む。プロセッサおよびメモリは、専用論理回路によって補うか、組み込まれてもよい。
【０１００】
ユーザとの対話を提供するために、実装例は、ユーザに情報を表示するための、たとえば陰極線管（ＣＲＴ)や液晶表示（ＬＣＤ)モニタの表示装置、およびユーザがコンピュータへ入力を提供するためのキーボードと、たとえばマウスまたはトラックボールのポインティングデバイスを有するコンピュータで実装することができる。他の種類のデバイスを使用してユーザに対話を提供することもできる。例えば、ユーザに提供されるフィードバックは、視覚フィードバック、聴覚フィードバック、または触覚フィードバックの感覚フィードバックの任意の形式であってよい。そしてユーザからの入力は、音響入力、音声入力、または触覚入力の任意の形式で受け取ることができる。
【０１０１】
データサーバ等のバックエンドコンポーネントを含むか、アプリケーションサーバ等のミドルウェアコンポーネントを含むか、ユーザがこれらを通して実装と対話できるグラフィカルユーザインタフェースもしくはウェブブラウザを有する備えたクライアントコンピュータ等のフロントエンドコンポーネント、またはこれらのバックエンドコンポーネント、ミドルウェアもしくはフロントエンドコンポーネントの任意の組合せを含むコンピュータシステムにおいて、実装例が実装することができる。コンポーネントは、通信ネットワーク等のデジタルデータ通信の任意の形式または媒体によって相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク（ＬＡＮ）、および例えばインターネットの広域ネットワーク（ＷＡＮ）を含む。
【０１０２】
前述の実装例のある特徴が本明細書で示されてきたが、当業者は、多数の修正、代替、変更、同等物に気づくだろう。従って、添付の請求の範囲は、このような修正および変更のすべてを、本発明の実施形態の精神内としてカバーすることを意図すると理解されたい。
【図面の簡単な説明】
【０１０３】
【図１】組み立てモデルと検証スキームを利用できるスマートアイテムインフラストラクチャのブロック図である。
【図２】デバイス通信の開放型システム間相互接続(ＯＳＩ)モデルのブロック図である。
【図３】オントロジークラスの観点からアプリケーションの物理層を記述するために使用される選択された通信概念のブロック図である。
【図４】オントロジークラスの観点からアプリケーションのデータリンク層を記述するために使用される選択された通信概念のブロック図である。
【図５】オントロジークラスの観点からアプリケーションのネットワーク層を記述するために使用される選択された通信概念のブロック図である。
【図６】オントロジークラスの観点からアプリケーションのトランスポート層を記述するために使用される選択された通信概念のブロック図である。
【図７】組み立てモデルで使用されるコンポーネント、ポート、およびコネクタを示すブロック図である。
【図８Ａ】構成コンポーネントから複合アプリケーションを組み立てる処理の流れ図である。
【図８Ｂ】構成コンポーネントから複合アプリケーションを組み立てる処理の流れ図である。
【図９Ａ】構成コンポーネントから複合アプリケーションを組み立てる処理の流れ図である。
【図９Ｂ】構成コンポーネントから複合アプリケーションを組み立てる処理の流れ図である。
【図１０】構成コンポーネントから複合モデルを組み立ておよび検証する処理の流れ図である。
【図１１】構成コンポーネントから複合モデルを組み立ておよび検証するシステムのブロック図である。
【符号の説明】
【０１０４】
７０４、７０６、７１２、８０２、８０６、８１０、８１２、９００、９１０  アプリケーションのコンポーネント
３１０、３２１、３１４、３１６、３２０、３２２、３２４、３２６、３２８、３３０、３３２、４１０、４１２、４１４、４１６、４１８、４２０、４２２、４２４、４２６、４２８、４３０、４３２、４３４、４３６、４３８、４４０、５３０、５３２、５２４、５２６、５２２、５１２、５１４、５１６、５１８、５２０、５３６、５３４、５３８、６０２、６０４、６０６  通信能力
８５０、９２０  複合コンポーネント
９００、９１０、８０２、８０６、８１２  連結されたコンポーネント
７０８、７１０、７２０、７５６、７５８、８０４、８０８、８１０、８１４、８２２、８２６、９０２、９０４、９０６、９１２、９１２’、９１４、９１６  インタフェースポートのモデル
【図１】
2007157149.tif 000003
【図２】
2007157149.tif 000004
【図３】
2007157149.tif 000005
【図４】
2007157149.tif 000006
【図５】
2007157149.tif 000007
【図６】
2007157149.tif 000008
【図７】
2007157149.tif 000009
【図８Ａ】
2007157149.tif 000010
【図８Ｂ】
2007157149.tif 000011
【図９Ａ】
2007157149.tif 000012
【図９Ｂ】
2007157149.tif 000013
【図１０】
2007157149.tif 000014
【図１１】
2007157149.tif 000015