(57)【要約】  大規模な拡張可能アプリケーションに関する合成モデルにおいて、アプリケーションは、モジュール化されて構築される。モジュール群は、共通の定義に準拠する機能を生成し使用することによって、互いに統合される。プロデューサモジュールとコンシューマモジュールとは、互いに独立に保たれ、定義モジュールを介して間接的に一緒にリンクされる。．ＮＥＴ属性を使用して、様々なコードアーティファクト（クラス、メソッド、プロパティなど）が、機能定義、機能生成、および／または機能使用であるものとして識別される。これらの属性は、モジュールローダによって調べられ、インストールされた個々のプロデューサモジュールとコンシューマモジュールとの関係を作成するのに使用される。コンシューマは、．ＮＥＴ属性を使用して、機能に対する依存関係を宣言し、それらの属性によって指定される条件を満たさない実装をフィルタリングして取り除く。
2009508252.tif 000002
【特許請求の範囲】
【請求項１】
属性を使用して、プラグ可能な機能を識別しフィルタリングするための方法であって、
統合ポイントと、ソフトウェアアプリケーション構成においてインストールされた前記統合ポイントに準拠するコードの本体部分とを公示するために、前記属性を使用するステップ
を備えることを特徴とする方法。
【請求項２】
静的かつシリアライザブルに、メタデータを前記ソフトウェアアプリケーションの実行可能なアーティファクトに直接関連付けるステップ
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記使用するステップは、
ソフトウェアコンシューマモジュールによる属性を使用して、ソフトウェアプロデューサモジュールの機能に対する依存関係を宣言するステップと、
前記属性によって指定された条件を満たさないソフトウェア実装をフィルタリングして取り除くステップと
を含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記モジュール群は、前記プロデューサモジュールが機能を生成し、前記コンシューマモジュールが共通の定義に準拠する機能を使用することによって互いに統合されることを特徴とする請求項３に記載の方法。
【請求項５】
前記プロデューサモジュールと前記コンシューマモジュールとは、互いに独立に保たれ、定義モジュールを介して間接的に一緒にリンクされることを特徴とする請求項４に記載の方法。
【請求項６】
前記属性は、．ＮＥＴ属性であることを特徴とする請求項５に記載の方法。
【請求項７】
請求項１に記載のステップを実行するための命令を有することを特徴とするコンピュータ読み取り可能な媒体。
【請求項８】
請求項２に記載のステップを実行するための命令を有することを特徴とするコンピュータ読み取り可能な媒体。
【請求項９】
請求項３に記載のステップを実行するための命令を有することを特徴とするコンピュータ読み取り可能な媒体。
【請求項１０】
請求項４に記載のステップを実行するための命令を有することを特徴とするコンピュータ読み取り可能な媒体。
【請求項１１】
請求項５に記載のステップを実行するための命令を有することを特徴とするコンピュータ読み取り可能な媒体。
【請求項１２】
請求項６に記載のステップを実行するための命令を有することを特徴とするコンピュータ読み取り可能な媒体。
【請求項１３】
属性を使用して、プラグ可能な機能を識別しフィルタリングするためのシステムであって、
統合ポイントと、ソフトウェアアプリケーション構成においてインストールされた前記統合ポイントに準拠するコードの本体部分とを公示するために、前記属性を使用する手段
を備えたことを特徴とするシステム。
【請求項１４】
静的かつシリアライザブルに、メタデータを前記ソフトウェアアプリケーションの実行可能なアーティファクトに直接関連付ける手段
をさらに備えたことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記使用する手段は、
ソフトウェアコンシューマモジュールによる属性を使用して、ソフトウェアプロデューサモジュールの機能に対する依存関係を宣言する手段と、
前記属性によって指定された条件を満たさないソフトウェア実装をフィルタリングして取り除く手段と
を含むことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記モジュール群は、前記プロデューサモジュールが機能を生成し、前記コンシューマモジュールが共通の定義に準拠する機能を使用することによって互いに統合されることを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記プロデューサモジュールと前記コンシューマモジュールとは、互いに独立に保たれ、定義モジュールを介して間接的に一緒にリンクされることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記属性は、．ＮＥＴ属性であることを特徴とする請求項１７に記載のシステム。
【請求項１９】
属性を使用して、プラグ可能な機能を識別しフィルタリングするためのシステムであって、
ソフトウェアコンシューマモジュールと、
ソフトウェアプロデューサモジュールと、
定義モジュールと
を備え、
前記プロデューサモジュールと前記プロデューサモジュールとは、前記定義モジュールを介して互いに間接的にリンクされることを特徴とするシステム。
【請求項２０】
ローダモジュール
をさらに備え、
前記ローダモジュールは、前記プロデューサモジュールと前記コンシューマモジュールとの間に前記リンクを確立し、機能定義を含むモジュールを発見し、前記機能定義に準拠する機能を生成するモジュールを発見し、前記機能を使用するモジュールを発見し、前記発見したモジュールをロードするように構成されることを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
（著作権表示および許可）
本特許文書の開示の一部分には、著作権保護の対象となる題材が含まれ得る。本著作権所有者は、米国特許商標庁のファイルまたは記録に現れるとおりの、何人による本特許文書または本特許開示の原物どおりの複写には異存はないが、それ以外では、すべての著作権を留保する。以下の表示、すなわち、著作権（Ｃ）、マイクロソフトコーポレーションの表示が、本文書に適用される。
【０００２】
情報、人々、システム、およびデバイスを結び付けるためのＭｉｃｒｏｓｏｆｔ（登録商標；以降省略）  ．ＮＥＴ（．ＮＥＴ）などのソフトウェアが、ＸＭＬ（拡張マークアップ言語）ベースの相互運用性を提供し、現在、クライアント、サーバ、サービス、およびツールにわたって組み込まれている。例えば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標；以降省略）やＭｉｃｒｏｓｏｆｔ  Ｏｆｆｉｃｅ（登録商標；以降省略）のような製品が、．ＮＥＴを使用して、他のシステムやアプリケーションに接続する。ソフトウェア開発者には、．ＮＥＴは、Ｍｉｃｒｏｓｏｆｔ  ．ＮＥＴ  Ｆｒａｍｅｗｏｒｋにおいて提供されるプログラミングモデルに現れる。このフレームワークは、次世代のソフトウェアアプリケーションおよびＷｅｂ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）サービスを構築すること、および実行することを可能にする統合型のＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓコンポーネントである。このフレームワークには、ＷｅｂサービスおよびＷｅｂアプリケーション、データアクセス、スマートクライアントアプリケーション、およびその他多くに関する技術が含まれる。
【０００３】
Ｗｅｂサービスは、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）、ＸＭＬ、およびＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）を含む業界標準のプロトコルを使用して、インターネットを介して呼び出される。これらのプロトコルは、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）などの公的な標準機構により規定されている。ＳＯＡＰは、Ｗｅｂサービスを探し出すため、Ｗｅｂサービスをアプリケーションに組み込むため、およびＷｅｂサービス間で通信するための、すべての必要なルールを指定する、Ｗ３Ｃによって標準化されたＸＭＬベースのメッセージング技術である。ＵＤＤＩは、Ｗｅｂサービスを公開すること、およびＷｅｂサービスについて問い合わせることができる、無料で提供されるパブリックレジストリである。．ＮＥＴは、ＸＭＬやＳＯＡＰのような標準のインターネット通信プロトコルにラップされ、そのようなプロトコルを介してアクセス可能な、個別の機能をセマンティックにカプセル化する、自己記述型ソフトウェアモジュール（ｓｅｌｆ−ｄｅｓｃｒｉｂｉｎｇ  ｓｏｆｔｗａｒｅ  ｍｏｄｕｌｅ）の使用を含む。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
拡張可能なクライアントアプリケーションを構築することは、同様のモジュール性と、構築時の出所を知ることなしに、機能を検出して利用する能力とを、それらモジュールが、同一のアプリケーションプロセスにロードされ、強く型付けされた方法で対話するとしても、必要とする。例えば、開発環境は、ソースコードを操作するツール（コンパイラ、ブラウザ、フォーマッタ/ビューティファイア（ｂｅａｕｔｉｆｉｅｒ）など）をその環境に統合することが可能な統合ポイント（ｉｎｔｅｇｒａｔｉｏｎ  ｐｏｉｎｔ）を有することが可能である。これらのツールは、サードパーティによって作成される可能性があり、したがって、環境自体は、これらのツールが、いずれのモジュールに由来するかということを認識して構築されることはない。このため、環境は、当該環境がそのようなツールと対話する規約（そのようなツールが要求する入力やそのようなツールが生成する出力のフォーマットなどを含む）を開示し、次いで、その規約に準拠するインストール済みのモジュールを発見して、ロードしなければならない。
【０００５】
．ＮＥＴプラットフォームは、現在のプロセスにモジュールを動的にロードし、それらモジュール内の機能を利用する能力を確かに有するが、統合ポイントを開示するためのフレームワーク、またはアプリケーションにおける、そうした統合ポイントへの有効なコントリビューション（ｃｏｎｔｒｉｂｕｔｉｏｎ）を認識するためのフレームワークを、現在全く提供していない。
【０００６】
したがって、従来技術の欠点に対処するプロセスおよびシステムが必要とされている。
【課題を解決するための手段】
【０００７】
この要約は、詳細な説明において以下でさらに説明する選択された概念を、簡略化した形式で導入するように提供するものである。この要約は、特許請求する主題の重要な特徴または不可欠な特徴を特定することを意図するものでも、特許請求する主題の範囲を決定する助けとして使用することを意図するものでもない。
【０００８】
当技術分野の上述した欠点を考慮し、属性を使用して、プラグ可能な機能を識別しフィルタリングすることが提供される。いくつかの実施形態では、属性を使用して、プラグ可能な機能を識別しフィルタリングするためのシステムは、ソフトウェアコンシューマモジュールと、ソフトウェアプロデューサモジュールと、定義モジュールとを備え、このプロデューサモジュールとコンシューマモジュールとは、この定義モジュールを介して、互いに間接的にリンクされる。統合ポイントと、ソフトウェアアプリケーション構成においてインストールされたこの統合ポイントに準拠するコードの本体部分（ｂｏｄｙ）またはモジュールとを公示するために、属性が使用される。特に、プロデューサモジュールとコンシューマモジュールとの間にリンクを確立し、機能定義を含むモジュールを発見し、この機能定義に準拠する機能を生成するモジュールを発見し、この機能を使用する（ｃｏｎｓｕｍｅ）モジュールを発見し、この発見したモジュールをロードするように構成されたローダモジュールが、提供される。
【０００９】
本発明のその他の利点および特徴については、以下で説明する。
【発明を実施するための最良の形態】
【００１０】
属性を使用して、プラグ可能な機能を識別しフィルタリングすることについて、添付の図面を参照しながら、さらに説明する。
【００１１】
以下の説明および図において、本発明の様々な実施形態を完全に理解してもらうように、いくつかの特定の詳細が示される。コンピューティング技術およびソフトウェア技術にしばしば関連する、いくつかの周知の詳細は、本発明の様々な実施形態を不必要に分かりにくくすることを避けるため、以下の開示では示されない。さらに、当業者であれば、以下で説明する詳細の１つまたは複数を用いることなく、本発明の他の実施形態を実施することができることが理解されよう。最後に、以下の開示において、様々な方法について、ステップおよびシーケンスに関連して説明するが、そのような説明は、本発明の実施形態の明確な実装を提供するためであり、そうしたステップ、およびステップのシーケンスは、本発明を実施するのに必須なものと解釈すべきではない。
【００１２】
図１を参照すると、前述したプロセスを実施することに関連して使用するのに適した例示的なコンピューティングデバイスを表すブロック図が示されている。例えば、属性を使用して、プラグ可能な機能を識別しフィルタリングするためのプロセスおよび方法を実行するコンピュータ実行可能命令が、図１に示されるようなコンピューティング環境に存在し、かつ／または、そのような環境において実行され得る。コンピューティングシステム環境２２０は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲について、何らの限定も示唆することを意図していない。また、コンピューティング環境２２０は、この例示的な動作環境２２０に示されたいずれか１つのコンポーネントもしくはコンポーネントの組合せに関して、依存関係または要件を有しているものと解釈すべきではない。また、例えば、コンピュータゲームコンソールには、前述したプロセスを実施することに関連して使用するための、以下で説明するような項目を含めることもできる。
【００１３】
本発明の諸側面は、他の多数の汎用もしくは専用コンピューティングシステム環境、またはコンピューティングシステム構成とともに機能する。本発明において使用するのに適した周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスもしくはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、前述のシステムもしくはデバイスのいずれかを含む分散コンピューティング環境などが含まれるが、これらに限定されるものではない。
【００１４】
本発明の諸側面は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストにおいて実施することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。また、本発明の諸側面は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含むローカルコンピュータ記憶媒体およびリモートコンピュータ記憶媒体の両方に配置させることができる。
【００１５】
本発明の諸側面を実施するための例示的なシステムは、コンピュータ２４１の形態をとる汎用コンピューティングデバイスを含む。コンピュータ２４１のコンポーネントには、処理ユニット２５９と、システムメモリ２２２と、システムメモリ２２２を含む様々なシステムコンポーネントを処理ユニット２５９に結合するシステムバス２２１とを含めることができるが、これらに限定されるものではない。システムバス２２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスもしくはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれであってもよい。例えば、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれるが、これらに限定されるものではない。
【００１６】
コンピュータ２４１は通常、様々なコンピュータ読み取り可能な媒体を含む。コンピュータ読み取り可能な媒体は、コンピュータ２４１がアクセスすることができる任意の利用可能な媒体とすることができ、コンピュータ読み取り可能な媒体には、揮発性媒体および不揮発性媒体、ならびに、取り外し可能な媒体および取り外し不可能な媒体のいずれもが含まれる。例えば、コンピュータ読み取り可能な媒体には、コンピュータ記憶媒体および通信媒体を含めることができるが、これらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータなどの情報の記憶のために任意の方法または技術を用いて実装された、揮発性媒体および不揮発性媒体、ならびに、取り外し可能な媒体および取り外し不可能な媒体のいずれもが含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶デバイス、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または所望の情報を記憶するのに使用することができ、かつコンピュータ２４１がアクセスすることができる他の任意の媒体が含まれるが、これらに限定されるものではない。通信媒体は通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータを、搬送波や他の搬送機構などの変調されたデータ信号として具現化したものであり、通信媒体には、任意の情報配信媒体が含まれる。「変調されたデータ信号」という用語は、信号内に情報を符号化するような方法で特性の１つまたは複数が設定または変更されている信号を意味する。例えば、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体と、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体とが含まれるが、これらに限定されるものではない。また、これらの媒体の任意の組合せも、コンピュータ読み取り可能な媒体の範囲内に含められるべきである。
【００１７】
システムメモリ２２２は、ＲＯＭ（読み取り専用メモリ）２２３やＲＡＭ（ランダムアクセスメモリ）２６０などの揮発性メモリおよび／または不揮発性メモリの形態をとるコンピュータ記憶媒体を含む。起動中などに、コンピュータ２４１内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（基本入出力システム）２２４は通常、ＲＯＭ２２３に記憶される。ＲＡＭ２６０は通常、処理ユニット２５９がただちにアクセスでき、かつ／または、現在処理しているデータおよび／またはプログラムモジュールを含む。例えば、図１には、オペレーティングシステム２２５、アプリケーションプログラム２２６、他のプログラムモジュール２２７、およびプログラムデータ２２８が示されているが、これらに限定されるものではない。
【００１８】
また、コンピュータ２４１は、他の取り外し可能な／取り外し不可能な揮発性／不揮発性のコンピュータ記憶媒体も含むことが可能である。一例として、図１には、取り外し不可能な不揮発性の磁気媒体に対して読み書きを行うハードディスクドライブ２３８と、取り外し可能な不揮発性の磁気ディスク２５４に対して読み書きを行う磁気ディスクドライブ２３９と、ＣＤ  ＲＯＭまたは他の光媒体などの取り外し可能な不揮発性の光ディスク２５３に対して読み書きを行う光ディスクドライブ２４０とが示されている。例示的な動作環境において使用することができる他の取り外し可能な／取り外し不可能な揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これらに限定されるものではない。ハードディスクドライブ２３８は通常、インタフェース２３４のような取り外し不可能なメモリインタフェースを介してシステムバス２２１に接続され、磁気ディスクドライブ２３９および光ディスクドライブ２４０は通常、インタフェース２３５のような取り外し可能なメモリインタフェースを介してシステムバス２２１に接続される。
【００１９】
図１に示して前述したドライブ群、および、それらドライブに関連するコンピュータ記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、および他のデータの記憶領域をコンピュータ２４１に提供する。図１では、例えば、ハードディスクドライブ２３８が、オペレーティングシステム２５８、アプリケーションプログラム２５７、他のプログラムモジュール２５６、およびプログラムデータ２５５を記憶しているものとして示されている。これらのコンポーネントは、オペレーティングシステム２２５、アプリケーションプログラム２２６、他のプログラムモジュール２２７、およびプログラムデータ２２８と同一とすることもできるし、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム２５８、アプリケーションプログラム２５７、他のプログラムモジュール２５６、およびプログラムデータ２５５が、少なくとも異なるコピーであることを示すために、それらに異なる符号が付されている。ユーザは、キーボード２５１や、マウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス２５２などの入力デバイスを介して、コマンドおよび情報をコンピュータ２４１に入力することができる。他の入力デバイス（図示せず）には、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含めることができる。これら、およびその他の入力デバイスは、システムバスに結合されたユーザ入力インタフェース２３６を介して処理ユニット２５９に接続されることが多いが、パラレルポート、ゲームポート、またはＵＳＢ（ユニバーサルシリアルバス）などの、他のインタフェースおよびバス構造を介して接続されてもよい。また、モニタ２４２、または他のタイプのディスプレイデバイスも、ビデオインタフェース２３２のようなインタフェースを介してシステムバス２２１に接続される。コンピュータは、モニタに加え、出力周辺インタフェース２３３を介して接続することができる、スピーカ２４４やプリンタ２４３などの、他の出力周辺デバイスも備えることができる。
【００２０】
コンピュータ２４１は、リモートコンピュータ２４６のような１つまたは複数のリモートコンピュータに対する論理接続を使用して、ネットワーク環境において動作することができる。リモートコンピュータ２４６は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ２４１に関連して前述した要素の多くまたはすべてを備えるが、図１には、メモリ記憶デバイス２４７だけが示されている。図１に示した論理接続には、ＬＡＮ（ローカルエリアネットワーク）２４５およびＷＡＮ（ワイドエリアネットワーク）２４９が含まれるが、他のネットワークを含めることもできる。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。
【００２１】
ＬＡＮネットワーキング環境において使用される場合、コンピュータ２４１は、ネットワークインタフェースまたはネットワークアダプタ２３７を介してＬＡＮ２４５に接続される。ＷＡＮネットワーキング環境において使用される場合、コンピュータ２４１は通常、インターネットなどのＷＡＮ２４９を介して通信を確立するためのモデム２５０、または他の手段を備える。モデム２５０は、内蔵型でも外付け型でもよく、ユーザ入力インタフェース２３６、または他の適切な機構を介してシステムバス２２１に接続することができる。ネットワーク環境では、コンピュータ２４１に関連して示したプログラムモジュール、またはプログラムモジュールの諸部分を、リモートメモリ記憶デバイスに記憶することができる。例えば、図１には、リモートアプリケーションプログラム２４８が、メモリデバイス２４７に存在するものとして示されているが、これに限定されるものではない。図示したネットワーク接続は、例示的なものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることを理解されたい。
【００２２】
本明細書で説明する様々な技術は、ハードウェアまたはソフトウェアを用いて実装することもできるし、あるいは、適宜、その両方の組合せを用いて実装することもできることを理解されたい。このため、本発明の方法および装置、あるいは本発明のいくつかの側面または部分は、フロッピー（登録商標；以降省略）ディスク、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン読み取り可能な記憶媒体などの、有体の媒体において具現化されたプログラムコード（すなわち、命令）の形態をとることができる。そのプログラムコードが、コンピュータなどのマシンにロードされ、そのマシンによって実行されると、そのマシンが、本発明を実施するための装置となる。プログラマブルコンピュータ上でのプログラムコード実行の場合、コンピューティングデバイスは一般に、プロセッサと、そのプロセッサによって読み取り可能な記憶媒体（揮発性および不揮発性のメモリおよび／または記憶要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを備える。本発明に関して説明するプロセスを実施するか、または利用することができる１つまたは複数のプログラムは、例えば、ＡＰＩ、再利用可能なコントロールなどの使用を介するものである。そのようなプログラムは、コンピュータシステムと通信するために、高水準手続き型プログラミング言語またはオブジェクト指向プログラミング言語を用いて実装されることが好ましい。しかし、プログラムは、必要に応じて、アセンブリ言語またはマシン語を用いて実装することもできる。いずれにしても、言語は、コンパイルされる言語か、またはインタプリタ言語とすることができ、ハードウェアの実装と組み合わせることが可能である。
【００２３】
例示的な実施形態は、１つまたは複数のスタンドアロン型コンピュータシステムの状況において本発明の諸側面を利用することについて説明され得るが、本発明は、そのようなコンピュータシステムに限定されるものではなく、ネットワークコンピューティング環境または分散コンピューティング環境などの、任意のコンピューティング環境に関連して実施することができる。さらに、本発明の諸側面は、複数の処理チップもしくは処理デバイスにおいて、または、それらのチップもしくはデバイスにわたって実施されてもよく、記憶も同様に、複数のデバイスにわたって実施されてもよい。そのようなデバイスには、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルドデバイス、スーパコンピュータ、または自動車や飛行機などの他のシステムに組み込まれたコンピュータを含めることができる。
【００２４】
図１において提供された一般的なフレームワークに従って構築することができる多種多様なコンピューティング環境に鑑みて、本明細書で提供するシステムおよび方法は、特定のコンピューティングアーキテクチャに限定されるものと解釈すべきではない。そうではなく、本発明は、いずれの単一の実施形態にも限定されるべきではなく、むしろ、添付の特許請求の範囲に従う広がりおよび範囲を有するものと解釈されるべきである。
【００２５】
Ｍｉｃｒｏｓｏｆｔ  ．ＮＥＴ（．ＮＥＴ）属性を使用して、統合ポイントと、その統合ポイントに準拠するソフトウェアコードの本体部分とを公示するという着想に基づくフレームワーク、システム、およびプロセスが、本明細書で提供され、説明される。しかし、Ｍｉｃｒｏｓｏｆｔ  ．ＮＥＴ属性を使用することは、本明細書では、例示的な実施形態の一部として提供され、このため、Ｍｉｃｒｏｓｏｆｔ  ．ＮＥＴソフトウェアと同様の方法で属性を提供する他のシステム、フレームワーク、および／またはプラットフォームが、同様に利用されてもよい。
【００２６】
．ＮＥＴ属性を使用して、統合ポイントの存在、およびその統合ポイントの規約の存在、ならびにその規約に準拠する機能の存在を示すことは、以下の利点を有する。すなわち、属性により、静的かつシリアライザブルに、メタデータを実行可能なアーティファクト（クラス、メソッドなど）に直接関連付けることが可能となる。そうすることにより、メタデータを読み取ってキャッシュすることが可能になり、システムが、モジュールをロードすることなく、後でメタデータを利用できるようになる。この場合の利点は、属性付き機能の開発者が、メタデータをコードアーティファクトに直接関連付けるという利便性を享受することにあり、コードからメタデータを分離し、メタデータを別個にロードするシステムの能力によって、ランタイムパフォーマンスが向上されることにある。それ自体、．ＮＥＴ型であるため、属性は、．ＮＥＴプログラマには馴染みやすい概念である。統合ポイントおよび規約を開示するための別の方法を使用することには、新たな機構や新たなデータフォーマットなどを導入することが伴い、そのような方法では、不必要かつ無用な複雑さをシステムに与えてしまうことになる。
【００２７】
重要なことは、機能に対する依存関係を宣言するのに、コンシューマによって同一の．ＮＥＴ属性が使用され、そうした属性によって指定される条件を満たさない実装がフィルタリングされ取り除かれることである。このシステムによって示される任意のプラグ可能な機能に関する規約は、その機能に対するプログラマティックインタフェース（ｐｒｏｇｒａｍｍａｔｉｃ  ｉｎｔｅｒｆａｃｅ）と、その機能を実現する静的メタデータの記述との両方から構成される。その静的メタデータは、．ＮＥＴ属性の点で表現される。コンシューマは、コンシューマ自身のコード内でそれらの属性を使用して、同一の属性を備えた規約の実施形態に対する依存関係を宣言し、その実施形態のみとマッチさせることができる。
【００２８】
次に図２を参照すると、属性を使用して、プラグ可能な機能を識別しフィルタリングする際に、ソフトウェアモジュールが、共通の定義に準拠する機能を生成し使用することにより、どのように互いに統合されるかを示す図が示されている。この概念は、大規模な拡張可能アプリケーションに関する合成モデル（ｃｏｍｐｏｓｉｔｉｏｎ  ｍｏｄｅｌ）の一部である。このモデルでは、アプリケーションは、モジュール化されて構築される。モジュール２６２、２６４、２６８が、定義モジュール２６２に対する直接的な依存関係２７２を介して、共通の定義に準拠する機能を生成し使用することにより、互いに統合される。プロデューサモジュール２６８およびコンシューマモジュール２６４は、互いに独立に保たれ、図２に示されるように、定義モジュール２６２を介して間接的に（２７０）一緒にリンクされる。
【００２９】
プロデューサモジュールとコンシューマモジュールとの間で実際のリンクを確立する動作は、モジュールローダによって行われる。ローダは、次の役割を担う。すなわち、機能定義を含むモジュールを発見すること、それら定義に準拠する機能を生成するモジュールを発見すること、そのような機能を使用するモジュールを発見すること、および、それらのモジュールをロードして、コンシューマ２６４と、対応するプロデューサ２６８との間に接続を確立することである。
【００３０】
ローダがいかにして上記のタスクを実行するかに関する機構について、以下で説明する。．ＮＥＴ属性を使用して、様々なコードアーティファクト（クラス、メソッド、プロパティなど）が、機能定義、機能生成、および／または機能使用であるものとして識別される。これらの属性は、モジュールローダによって調べられ、インストールされた個々のプロデューサモジュール２６８とコンシューマモジュール２６４との関係を作成するのに使用される。２つの例示的な実装について以下で説明する。
【００３１】
次に図３を参照すると、共通の定義に準拠する機能を生成し使用することによって互いに統合されるソフトウェアモジュールに従う生成／使用の第１の実装例における実行フローを示す図が示されている。第１の実装例では、生成されるべき／使用されるべき機能の定義は、．ＮＥＴ属性宣言（「サービス属性」）３０２を含む。この．ＮＥＴ属性宣言（「サービス属性」）３０２は、システムによって提供されるベースクラスから派生し、システムによって提供される属性を介してクラス型またはインタフェース型（「サービスオブジェクト型」）を識別し、かつそのサービスオブジェクト型のインスタンスのプロデューサについての静的メタデータを記述するプロパティを有する。
【００３２】
サービス定義は、定義モジュール２６２内に存在し、リフレクション（ｒｅｆｌｅｃｔｉｏｎ）を介して（サービスオブジェクト型を識別する属性の存在によって特別に合わせられた）前述の条件を満たす属性クラス定義を検出するモジュールローダ３０４によって識別される。次いで、プロデューサモジュール２６８は、クラスを「サービスプロデューサ」クラス３０８として識別する、システムによって提供される属性を備えた当該クラスから、静的に開示されたプロパティを介して、サービスオブジェクト型（「サービスオブジェクト」）の実装を提供し、サービスオブジェクト型のインスタンスを戻し、サービス属性を保持して、この生成を記述する属性のプロパティに関する適切なデータを提供する。
【００３３】
モジュールローダ３０４は、リフレクションを介して、そのようなプロパティを発見し、サービスプロデューサクラスのプロパティに対するサービス属性の存在を検出する。そのような各プロパティに付随するサービス属性インスタンスが、これらのサービスオブジェクトのコンシューマによって利用可能となり、コンシューマによって宣言された依存関係を満たす場合、モジュールローダ３０４によっても、比較の目的のために使用される。コンシューマモジュール２６４は、サービスオブジェクトへのアクセスを提供するクラス（「サービスファクトリ」）３０６を定義することによって、そのサービスオブジェクトを使用する要望を示す。サービスオブジェクトへのアクセスを提供するクラス３０６は、システムによって提供されるベースクラスから派生し、オプションとして、サービス属性により修飾される。このシステムによって提供されるベースクラスは、サービス属性型およびサービスオブジェクト型によってパラメータ化される。サービス属性は、プロデューサのサービス属性インスタンスが、サービスファクトリ３０６により提供されたインスタンスと合致する当該プロデューサに対する依存関係を宣言する。
【００３４】
コンシューマ２６４は、プロデューサ２６８を記述するサービス属性インスタンスを戻すプロパティと、プロデューサのサービス生成プロパティを呼び出すメソッドとを公開するサービスファクトリ３０６をインスタンス化する。このメソッドの実装は、システムによって提供されるベースファクトリクラスに組み込まれており、このクラスは、インストール済みのモジュールのモジュールローダ３０４による理解を使用して、どのプロデューサモジュール２６８をロードし呼び出して、サービスオブジェクトを作成すべきかを認識する。プロデューサモジュール２６８の選択は、ファクトリによって提供されるサービス属性インスタンスの値に基づいて決定される。同様に、コンシューマは、同一サービスオブジェクト型の複数の生成を表すことを除いてサービスファクトリ３０６と全く同じように振る舞うマルチプロデューサファクトリ（「サービスブローカ（ｓｅｒｖｉｃｅ  ｂｒｏｋｅｒ）」）を作成することができる。
【００３５】
次に図４を参照すると、共通の定義に準拠する機能を生成し使用することによって互いに統合されるソフトウェアモジュールに従う生成／使用の第２の実装例における実行フローを示す図が示されている。第２の実装例では、生成されるべき／使用されるべき機能の定義は、「ポート」４０３と呼ばれるクラスによって定義される。ポート定義に準拠する機能の単位（ｕｎｉｔ）は、「コントリビューション」４０７と呼ばれる。コントリビューション４０７には、メタデータ４１２が付随する静的メソッドが含まれる。そのメタデータは、コントリビューション４０９を定義するポート型のＩＤを少なくとも含む。ポート４０３はクラス定義である。このクラス定義は、システムによって提供されるベースクラス４０４から派生し、メタデータを対応するコントリビューションに関連付けるのに使用することが可能な０個以上の、システムによって提供される属性４０８とともに、その定義をポート定義４１１として識別する、システムによって提供される属性により修飾され、そして、このクラス定義はメソッド（「シグネチャメソッド」）４１３を含む。シグネチャメソッドは、ベースクラスからの機能を介して、コントリビューションメソッドを呼び出し、このポートによって定義されるコントリビューションに関するメソッドシグネチャを定義する。コントリビューション４０７には、ポートクラス４０３のシグネチャメソッド４１３と合致するメソッドと、ポートクラス４０３によって識別された属性４０８を使用して宣言された、そのメソッドに関連付けられたメタデータ４１２とが含まれる。
【００３６】
ポートクラス４０３のインスタンスは、そのポート４０３の定義に準拠する１つのコントリビューション４０７を正確に表す。コンシューマは、特に属性付きのフィールド内に記憶された、システムによって提供されるディスペンサオブジェクト（ｄｉｓｐｅｎｓｅｒ  ｏｂｊｅｃｔ）を使用して、モジュールローダ３０４からポートクラス４０３のインスタンスを取得する。モジュールローダ３０４は、ロード時に、それらフィールドに配置された属性を用いて宣言された依存関係情報と合致するポートインスタンスにより、これらのディスペンサオブジェクトをポピュレートする（ｐｏｐｕｌａｔｅ）。コンシューマは、ディスペンサからのポートインスタンス全体にわたって繰り返し、各コントリビューションからのメタデータを調べ、コントリビューションメソッドを呼び出すことができる。
【００３７】
図４は、この第２の実装例を使用する、通常の生成／使用にかかわる実行フローを示している。図４は、合致する考えられ得るコントリビューションの数が、ディスペンサ４１０において提供されるメタデータに基づいて１つに限られる、「単一のディスペンサ」４１０を示している。具体的には、このディスペンサ４１０は、例えば、ブランド名が、「Ｘ」４１２、４１５と指定されている「ＧｉｚｍｏＣｒｅａｔｏｒ」４０２コントリビューションを求めている。他のブランド名を有するコントリビューションは表されず、「Ｘ」と等しいブランド名を有する複数のコントリビューションが存在する場合には、構成の誤りである。
【００３８】
前述したように、機能に対する依存関係を宣言するのにコンシューマによって同一の．ＮＥＴ属性が使用され、それらの属性によって指定される条件を満たさない実装がフィルタリングされて取り除かれることは、大規模な拡張可能アプリケーションに関する合成モデルの一部である。モジュール化して拡張可能な方法でシステムを構築するアーキテクチャ全体にわたって使用される静的合成の方法を含む、１つのそのような合成モデルの実装例について、以下で説明する。したがって、大規模な拡張可能アプリケーションに関する合成モデルの状況における、前述したコンシューマモジュール、プロデューサモジュール、および定義モジュールの概念について、以下で説明する。
【００３９】
（大規模な拡張可能アプリケーションに関する合成モデルの状況における実装例）  
モジュール性は、大規模システム開発の重要な側面として十分に認識されている。拡張可能アプリケーションの適切な設計は、機能をモジュールに分割することを伴うだけでなく、広範にわたる拡張性を促進するように適合された、単純で一貫性があり、かつオープンな対話パターンも必要とする。この合成モデルは、そのようなモジュール性および対話パターンを規定して、実施する。本明細書で説明するモジュール性は、型分離のための境界を作成すること、またはバージョン管理問題に対処することに関するものではない。そうではなく、このモジュール性は、モノリシックコード（ｍｏｎｏｌｉｔｈｉｃ  ｃｏｄｅ）を構築する可能性がある場合に、モジュール化された拡張可能なコードを作成するための方法である。このモデルは、単一のアプリケーションドメイン内のメソッドおよびプロパティを介して対話するＣＬＲ型のレベルにある。このモデルは、型のレベルより高いレベルの抽象化を提供し、オープンなものであるので、外部で開発されたモジュールは、コアシステムモジュールが使用するのと同一の機構を使用して、システムを拡張することができる。
【００４０】
本明細書で説明することは、機能がどのようにモジュールに分割されるかと、モジュールを互いに統合できるようにする、どのような対話機構が存在するか、についての詳細である。合成モデルの目的は、拡張性を促進するアプリケーション開発のためのパターンおよび機構を定義すること、再利用および保守性をサポートすること、ならびに優れたランタイムパフォーマンスを示すことである。
【００４１】
合成モデルの核となる原則は、広範にわたる拡張性である。拡張性の概念を土台から促進させるために、対話機構は、オープンであり、かつプラグ可能でなければならない。すべてのモジュールは、それらモジュールが、アプリケーションの中核部分であるか、またはサードパーティ開発者によって展開後に構築されたかにかかわらず、同一の対話機構を使用して、システムを拡張する同一の能力を有する。
【００４２】
合成モデルモジュールは、複数のアプリケーションにおいて変更することなく再利用可能である。このことは、他のモジュールによって提供される機能に対する依存関係の間接化（ｉｎｄｉｒｅｃｔｉｏｎ）を必要とするので、機能の定義は一定のままであるが、実装はアプリケーションに応じて変わり得る。
【００４３】
保守性の高いシステムは、システムのモジュール間で、理解可能な依存関係の要件を有する。これに関連して、そのようなシステムは、パブリックに使用可能な部分と、プライベートな実装詳細との間の明確な輪郭（ｄｅｌｉｎｅａｔｉｏｎ）も有する。これら２つの側面が一緒になると、開発者は、ある変更がシステム全体にわたって及ぼし得る影響を理解できるようになる。
【００４４】
このモデルにおけるパフォーマンスの影響は、特に起動時において、極めて小さい。対話機構の設計は、コストのかからない統合を可能にし、モジュールのロード、または他の初期化コードなどの、よりコストのかかるアクティビティを、その機能が実際に呼び出されるまで先へ延ばす。
【００４５】
どのようにソフトウェアシステムが動作するかを知るために、システムのロジック部分を認識し、それらロジック部分間の依存関係および対話性を理解する必要がある。オブジェクト指向システムにおいて、それらロジック部分は通常、オブジェクト（またはオブジェクト型）である。これはうまく機能するが、無制限にスケールアップされるわけではない。開発者が型レベルでシステムを理解する能力は、そのシステムにおける型の数が今日のＶｉｓｕａｌ  Ｓｔｕｄｉｏのサイズのように相当な数になると、急速に崩壊し始める。次世代のシステムは、さらにいっそう複雑である。
【００４６】
．ＮＥＴの世界において、次のレベルの抽象化はアセンブリである。アセンブリは、型を含むが、型間の関係の一貫性のある宣言、または、それらの型をどのように使用すべきかを提供しない。さもなければ、しばしば、無関係の型が、より良好なロードパフォーマンス、または配布の利便性を単に実現するために、組み合わされてアセンブリにされる。システムにおけるアセンブリ間の相互依存関係を理解することは、確かに興味深いことではあるが、それだけでは通常十分でない。
【００４７】
合成モデルにおけるモジュール性パターンは、アセンブリと型との間に属する新たなレベルの抽象化をもたらす。機能は、潜在的に多くの型を伴う単位で生成されて使用され、モジュール間の依存関係は、それらの単位の点で明確である。このことは、型レベルに至るまでの低いレベルに進むことなく、アセンブリ間の依存関係の存在のみならず、それら依存関係の理由も理解することを可能にする。
【００４８】
拡張性は、合成モデルの設計において広く普及している。このことは、アプリケーションが「拡張性モデル」をエンドユーザに提供できるようにすることをはるかに超えている。アプリケーション自体が、展開後に公開される同一の拡張性機構上に構築される。動機付けは、大規模なチームの生産性を高めて、チームが、モジュール化されて統合される機能を生成し使用することによって、複雑なシステムに対して、より効率的にともに作業することを可能にすることである。
【００４９】
システムは、モジュール化されていることに加え、真に拡張可能であるように、土台からオープンであり、かつプラグ可能である。合成モデルにおける対話機構および対話パターンは、特にこの目的で設計される。モジュール間で共有される機能の単位は、オープンであるように設計されて、アプリケーションにおいて任意の数の実装が存在することを可能にする。このことは、アプリケーションが柔軟性を欠いている可能性がある場合でも、任意のモジュールがそのアプリケーションに機能をプラグする機会を提供する。
【００５０】
．ＮＥＴにおいて、モジュール性を実現し、かつモジュール間の対話性を記述する多くの可能な方法が存在する。本明細書で説明するモデルは、アーキテクチャ全体にわたって一貫して使用される。そのような共通の機構は、実装が共有される点、およびシステムのすべての開発者間で理解が共有される点で利点を有する。
【００５１】
他のモジュールに直接関連付けることは、再利用可能性を制限することになる。実際の実装が、未知であるモジュールによって提供される、何らかの機能のパブリックな定義だけを含むモジュールに関連付けられている方がよりよい。このようにすると、そのモジュールは、その機能の同一のパブリックな定義を含むが、その特定のアプリケーションにより適した完全に異なる実装を含む別のアプリケーション構成において使用することができる。そのような間接化は、このモデルの設計において元々備わっているものである。そのような間接化は、再利用可能性を実現するだけでなく、任意のモジュール開発者がパブリックな定義に準拠する機能を生成してシステムを拡張することができるように、オープンであり、かつプラグ可能であるという重要な側面である。また、そのような間接化は、システムに存在する、パブリックに使用可能なＡＰＩと、プライベートな実装詳細との間の明確な輪郭を確立する優れた手段も提供する。
【００５２】
システムにおいて共有される機能の各単位は、記述的メタデータによって実現することができる。コンシューマは、フォーマットが、機能のパブリックな定義の一部であるこのメタデータを使用して、アプリケーション内にインストールされた様々な実装を区別することができる。システムはこのメタデータへのアクセスを最適化して、その結果、生成モジュールをロードすることなく、このメタデータを取得できるようになり、非常にわずかなランタイムコストでリッチな統合をもたらす。
【００５３】
．ＮＥＴにおいて、異なるアセンブリからの型は、アセンブリ参照を介して一緒にバインドされる。ランタイムに、別のアセンブリからの型が使用されると、そのアセンブリが、探し出されてロードされる。それに失敗すると、例外が投げられることになり、使用コードが、その型を利用できない可能性に対処しなければならないことが回避される。
【００５４】
依存関係特性も同様に、相互依存関係の間接的性質にもかかわらず、このモデルにおけるモジュール用に利用可能である。モジュール作成者は、提供された条件に合致する、パブリックに定義された機能の実装に対する依存関係を宣言することができる。その依存関係が満たされない場合、モジュールはアクティブ化されない。このことにより、その状況を検出して順に対処する必要性が回避される。
【００５５】
合成モデルは、大規模な拡張可能アプリケーションの静的なモジュール合成を提供する。機能は、複数のアプリケーション構成において再利用可能であり、他の機能に対して間接的な依存関係だけを有することが可能である。
【００５６】
このモデルの重要な側面は、共有される機能の定義と実装との明確な分離である。このことは、ある実装コードが、他の特定の実装コードに対する不要な依存関係を有さないよう保つとともに、機能が進化する際に最も注意を必要とするパブリックな定義を明確に識別する。
【００５７】
合成モデルプラットフォーム上に構築されたアプリケーションは、モジュール化された設計である。モジュールは、例えば、別のモジュールにおける静的メソッドを呼び出すという単純な動作に究極的には基づく明確に定義された機構を介して、機能を生成して使用することにより対話する．ＮＥＴアセンブリである。その単純な動作に追加される主要な概念が間接化であり、この間接化により、所望される機能を、ある特定のアセンブリによってではなく、任意のアセンブリによって提供できるようにする。この間接化の結果、所望される機能の複数の実装が可能となり、コンシューマは、それらの実装のすべてを呼び出すこと、またはそれらの実装の各々に付随するメタデータに基づくサブセットを選択することができる。
【００５８】
このモデルが、アプリケーションの合成においてある役割を果たす、以下の３つの領域が存在する。すなわち、ビルド、リンク、およびランタイムである。このモデルにおいて使用される、いくつかのプログラミングパターンおよびプログラミング慣行が存在し、ビルド時に、これらのルールの順守を確認し実施する検証ツールが提供される。モジュール間の依存関係は間接的であるが、アプリケーションの合成は、このモデルにおいて静的なままである。このため、プロデューサとコンシューマとを接続するリンク段階が存在する。この段階は、概念上、ランタイムの直前に行われる。アセンブリのロードおよびアクティブ化を扱い、コンシューマからの呼び出しを適切な機能プロデューサに転送し、関連付けられたメタデータへのアクセスを提供する、「カーネル」と呼ばれるシステムのランタイム部分が存在する。しかし、ビルドされて一緒にリンクされると、アプリケーションは一般に、ほとんどカーネルからの関与なしに実行される。アセンブリ間の対話ポイントは、このモデルにおいては静的に記述される。この例では、カードシャッフリング機能が、別のアセンブリに入れられている（あるいは、おそらく、別のアセンブリの形態で、Ｐｏｋｅｒ．ｄｌｌの作成者に提供されていた）。ポーカアセンブリは、単に、ＣａｒｄＧａｍｅＵｔｉｌｉｔｉｅｓ．ｄｌｌへの参照を追加し、その静的メソッドを直接呼び出すことによって、シャッフリングコードを使用することができる。合成モデルにおけるアセンブリ間の対話は、静的メソッドを呼び出すことに非常に類似している。重要な違いは、所望される機能のプロデューサとコンシューマとの間に間接化のレベルが存在することである。クラスがインタフェースを実装するのと同じように、この間接化を、静的メソッド「によって実装される」「インタフェース」と考えることができる。そのメソッドの呼び出し元は、そのメソッドの形状（ｓｈａｐｅ）だけを知っているが、そのメソッドが、どのアセンブリに由来するかを知らないか、またはそのことに無関心である。
【００５９】
次に図５を参照すると、共通の定義に準拠する機能を生成し消費することによって互いに統合されるソフトウェアモジュールに従う、所望される機能のプロデューサとコンシューマとの間の間接化のレベルを示す図が示されている。この間接化は、図５において作成されたＣ＃構文により例示されている。図５に示されるように、実際のシャッフリングコードは、Ｐｏｋｅｒ．ｄｌｌ５０２に知られていないアセンブリ内に存在する。このコードは、呼び出し元が知らないクラスＳｈｕｆｆｌｅｒ５０４において定義されるメソッド「インタフェース」を「実装する」。Ｐｏｋｅｒクラス５０６からの呼び出しが、ＭｙＣａｒｄＳｈｕｆｆｌｅｒクラス５０８における実装に向けられる。アプリケーション構成に応じて、呼び出しは、呼び出し元アセンブリを変更することなく、完全に異なるシャフリング実装に向けることもできる。
【００６０】
図５に示される作成された構文は、言語拡張に対する提案として文字どおりに解釈すべきではないことに留意されたい。これを達成するための実際の機構については、本明細書において以下で詳細に説明する。これらの概念を推進するための言語拡張を考慮することは、興味深いものではあるが、図５に示される「構文」は、そのような拡張のための提案ではない。
【００６１】
図５に示される３つのアセンブリのセット５０２、５０４、５０８は、例えば、図２から図４までを参照して前述したアセンブリなどの、定義アセンブリ、プロデューサアセンブリ、およびコンシューマアセンブリと呼ばれる一般的な三連構造（ｔｒｉａｄ）を表している。プロデューサアセンブリおよびコンシューマアセンブリという用語は一般に、図５に示されるＳｈｕｆｆｌｅＤｅｃｋメソッド５１０などの、単一の定義の状況においてのみ使用される。通常、１つの対話定義に関するプロデューサアセンブリは、別の対話定義に関するコンシューマアセンブリでもある。したがって、実装アセンブリという用語は、定義アセンブリから、そのようなアセンブリを区別するよう、そのようなアセンブリを指すために使用される。
【００６２】
プロデューサとコンシューマとの間の間接化は、システムの別の重要な側面を生じさせることを可能にする。その側面は、所望される機能の複数の実装が、コンシューマにとって利用可能である能力である。このことは、明らかに、ここでは示されていない異なる呼び出しパターンを必要とする。基本的に、コンシューマは、メソッドのセット全体にわたって繰り返し、それらのメソッドをすべて呼び出すか、またはそれらのメソッドとともに提供されるメタデータに基づいて、それらのメソッドの１つ（または複数）を選択することを必要とする。メタデータに基づいて選択することは、システムにおけるリッチで、オープンエンドの拡張性能力を提供するとともに、ロードを遅らせることにより高いパフォーマンスを実現するための機構も提供する。
【００６３】
合成モデルにおけるアセンブリ対話に関与する基本的なパターンは、馴染みのあるプロデューサ／コンシューマパターンである。すべてのケースで、プロデューサとコンシューマとの間に間接化のレベルが存在するので、プロデューサとコンシューマとの間に、直接的な依存関係の結び付きは存在しない。定義に準拠する機能の複数のコンシューマおよび複数のプロデューサが、システムに存在することを許容される。このモデルにおいて生成され使用される機能は、概念上、静的メソッドと均等である。このシステムは、メソッドが任意の型のオブジェクトを戻すことが可能であるということを超えて、いずれの特定の形態のオブジェクト交換も規定しない。
【００６４】
プロデューサアセンブリは、付随するいくつかのメタデータを有する静的メソッドであるコントリビューションの形態で、システムに価値を加える。メソッドおよびメタデータの形状は、コントリビューションポート（またはポート）によって定義される。ポートは、機能のプロデューサとコンシューマとの間のコンタクトポイントを一意に識別するクラスである。ポートクラスのインスタンスは、そのポートによって定義される単一のコントリビューションを表し、メタデータへのアクセスを提供するとともに、そのコントリビューションのメソッドを呼び出す方法も提供する。コンシューマは、合致するコントリビューションに関するコンシューマの依存関係宣言も保持するプライベートなフィールド内に記憶される、ディスペンサと呼ばれる特別なオブジェクトからポートインスタンスを取得する。これらのフィールド、およびコントリビューションメソッドは、ブローカと呼ばれる静的クラスのメンバである。ブローカは、単独の棄却（ｒｅｊｅｃｔｉｏｎ）単位を形成するように、互いに関係するコントリビューションの「売買を行う」（使用および生成を行う）。ブローカは、他のコントリビューションに矛盾するコントリビューションを生成する場合、または利用できないコントリビューションに依存するコントリビューションを生成する場合、棄却される。
【００６５】
コントリビューションは、いくつかの対応するメタデータを有する静的メソッドである。コントリビューションは、アセンブリによって「生成」され「使用」される。コントリビューションを「使用する」とは、そのコントリビューションのメタデータを検査し、かつ／またはそのコントリビューションのメソッドを呼び出すことであるのに対して、そのコントリビューションを含むアセンブリは、そのコントリビューションを「生成する」という言い方がされる。コントリビューションの生成および使用は、静的に記述可能ではあるが、それでも、間接的な方法で行われる。このことは、アセンブリが、当該アセンブリを検査することによって一意に識別できる決まった数のコントリビューションを生成することを意味し、アセンブリによって使用されるコントリビューションも、宣言された依存関係情報に基づいて発見することができる。しかし、コントリビューションを生成するアセンブリと、そのコントリビューションを使用するアセンブリとの間に、直接的な参照は存在しない。これらの結び付きは、ローダによって確立される。
【００６６】
コントリビューションメソッドは、ブローカクラスにおいて宣言されるプライベートな静的メソッドである。メタデータは、コントリビューションメソッドに配置された属性の形態をとる。このメソッドは、ポートクラスにおける特別に指定されたメソッドのシグネチャと合致することが要求される。また、コントリビューションメソッドを修飾するのに使用することが可能な属性の型も、ポート定義の一環として識別される。
【００６７】
コントリビューションポートは、コントリビューションの形状を定義するクラスである。ポートを、コントリビューションが実装するインタフェース定義として考えることができる。このモデルにおいて、プロデューサとコンシューマとの間に、直接的なアセンブリ参照は決して存在しないことを想起されたい。ポートは間接化ポイントである。すなわち、コントリビューションのプロデューサおよびコンシューマがともに、ポート定義を含むアセンブリへの直接的な参照を有する。ポート定義の一部は、コントリビューションのメタデータを構成する属性型セットの宣言である。これらの型は、ポートクラス定義自体に配置された属性を介して識別される。ポート定義の一部はまた、コンシューマがコントリビューションメソッドを呼び出すエントリポイントの役割を果たすパブリックなメソッドである。このメソッドは、「シグネチャメソッド」と呼ばれる。というのは、再びインタフェースになぞらえると、コントリビューションメソッドに関するシグネチャを定義するからである。
【００６８】
ポートクラスは、対応するコントリビューションが、どのような外観でなければならないかを定義するのに対して、ポートクラスのインスタンスは、単一のそのようなコントリビューションを表す。コンシューマは、ポートインスタンスを用いて、（ベースＣｏｎｔｒｉｂｕｔｉｏｎＰｏｒｔクラスから公開された機能を介して）コントリビューションのメタデータ部分を検査する手段を得るとともに、（ポートのシグネチャメソッドを介して）コントリビューションメソッドを呼び出す手段を得る。
【００６９】
ポートインスタンスは、時として、「コントリビューションインスタンス」と呼ばれ、あるいは、単に、「コントリビューション」とも呼ばれることに留意されたい。そのような呼び方のコンテキストは、通常、ポートクラスのインスタンスと、コントリビューションの生成（実際にはオブジェクトではない）とを区別するのに十分である。
【００７０】
実装アセンブリは通常、プロデューサおよびコンシューマの両方である。実装アセンブリに「入ってくる」コントリビューションと、実装アセンブリから「出ていく」コントリビューションとの両方のフローが、ブローカと呼ばれる静的クラスに集中する。コントリビューションメソッドは、実際は、ブローカクラスのメンバである。また、「入ってくる」コントリビューション、すなわち、ブローカクラスを含むアセンブリによって使用されるコントリビューションを表すブローカクラスの静的フィールド内に記憶されたオブジェクト（ディスペンサと呼ばれる）も存在する。
【００７１】
ブローカは、コントリビューションの関係する使用と生成とを関連付ける。例えば、実装アセンブリによって生成されるコントリビューションは、他の場所から別のコントリビューションを使用するコードによってバックアップすることが可能である。使用されるコントリビューションが利用可能でない場合、生成されるコントリビューションは棄却されなければならない。
【００７２】
いくらか稀ではあるが、実装アセンブリには、複数のブローカクラスを含めることもできる。その場合、１つのブローカと関連するアセンブリにおけるコードは、他のいずれのブローカと関連するコードからも完全に独立でなければならない。基本的に、アセンブリを分割して１つのアセンブリにつき１つのブローカが存在するようにし、それらの間にアセンブリ参照が全く存在しないようにしなければならない。この要件を満たさないと、ブローカは、独立して棄却を回避することができない。
【００７３】
一般に、実装アセンブリの開発は、１つのアセンブリにつき１つのブローカクラスをもたらすことに留意されたい。アセンブリではなく、ブローカを棄却単位として可能にすることにより、配布の利便性またはロードパフォーマンスのシナリオが要求する場合、実装アセンブリの、ビルド後の組み合わせが可能になる。
【００７４】
ポートインスタンスは、単に新たな表現を使用してコンシューマによって作成することはできない。そうではなく、ポートインスタンスは、ローダだけに知られているアセンブリを出所とするコントリビューションを表すので、ポートインスタンスは、ローダによってコンシューマに提供される。コンシューマは、ディスペンサと呼ばれるオブジェクトを使用して、ポートインスタンスを取得する。
【００７５】
ディスペンサは、新たな表現を使用してコンシューマによって作成されるオブジェクトである。ディスペンサは、ブローカクラスのフィールド内に静的に記憶され、それらのフィールドは、識別されたポートに基づいて、コントリビューションに対するコンシューマの依存関係の性質を宣言する属性により修飾される。それらの属性を使用して、利用可能なコントリビューションの中で、コンシューマの依存関係と合致するコントリビューションが存在すれば、その合致するコントリビューションを特定する。ローダは、ロード時に、合致するコントリビューションを表すポートインスタンスを用いて、ディスペンサをポピュレートする。
【００７６】
また、コンシューマは、少なくとも１つのコントリビューションが利用可能でなければならないという要件も示すことができる。そのようなコントリビューションが全く見出されない場合、ブローカは棄却される。
【００７７】
単一のポートインスタンスを含むディスペンサと、ポートインスタンスの集合体を含むディスペンサという、２つの形態のディスペンサが存在する。コンシューマが、単一のコントリビューションを識別する場合（または、単一のコントリビューションだけしか利用できる可能性がない状況において）、シングルディスペンサが使用される。複数のコントリビューションが利用できる可能性がある場合、マルチディスペンサが使用され、コンシューマは、それらコントリビューションの中から選択するために、またはそれらコントリビューションをすべて利用するために準備される。
【００７８】
棄却は、欠如しているコントリビューションに依存するコード、またはシステム制約に違反する（矛盾するコントリビューションを生成することなど）コードが、ロードされる、または実行されるのを防止する。このことは、コンシューマが、欠如している依存関係の可能性に備えて守勢でコーディングすることなく、自信を持ってコントリビューションを使用することを可能にする。また、このことは、システムが、互いに矛盾していない有効なコントリビューションのセットによって構成されていることも保証する。
【００７９】
棄却は、アプリケーション開発のライフサイクルにおける「リンク段階」中に行われる。この段階は、概念上、アプリケーションが実行され始める前であって、候補アセンブリのセットがシステム内に展開された後に、生じる。棄却の単位は、コントリビューションの関係する消費と生成とのペアである、ブローカクラスである。通常、１つの実装アセンブリにつき１つのブローカクラスが存在するが、棄却の粒度は、実装アセンブリが適宜一緒にマージされることを可能にするブローカクラスである。
【００８０】
ブローカクラスが棄却された場合、そのクラスは、あたかも存在していなかったかのようになる。このことは、そのクラスが生成するコントリビューションが、ローダによって無視され、いずれのコンシューマも、それらコントリビューションを呼び出すことができないことが保証される。また、このことは、そのブローカクラスによって提供されるコントリビューションを使用するコードは、決して実行されないことも意味する。さらに、棄却は、カスケードイベントである。ブローカが棄却された場合、そのブローカの生成も、事実上存在しない。別のブローカが、それらの生成のいずれかに対する依存関係を宣言している場合、そのブローカもまた、棄却されるといった具合である。このサイクルは、残りのすべてのブローカの要件が満たされるまで、継続する。
【００８１】
ポート定義は、コントリビューションとは独立したアセンブリ内で表されて、プロデューサとコンシューマとの間の間接化を提供しなければならない。この間接化は、開発者にコンポーネントのパブリック面について考えることを強制すること、および実装詳細をプライベートに保つことにより、より良好なバージョン弾力性と、より適切なモジュール設計とをもたらす。
【００８２】
定義アセンブリと実装アセンブリとは、次の違いを有する。他のいずれのアセンブリも、実装アセンブリに対する依存関係をとらず、実装アセンブリが、パブリックな型を含むことを無意味にする可能性がある。他方、定義アセンブリには、他のアセンブリが必然的に依存する。定義アセンブリは、主に、パブリックな抽象型の定義を含むのに対して、実装アセンブリは、より複雑な実装コードを含む。実装アセンブリだけが、コントリビューションを含むことができる。定義アセンブリ内のブローカクラスは、ディスペンサしか含むことができない。
【００８３】
（プログラミングモデル）  
このセクションでは、合成モデルにおいて、プロデューサとコンシューマとの間に接続を確立することに伴うプログラミングモデルについて説明する。完全な機能上の指定をするわけではないが、これらのセクションは、モデルに関するプログラミングに伴う、様々なクラスおよび属性、ならびにパターンおよび慣行の十分な理解を提供するものである。
【００８４】
これらの概念は、単純な例示的なシナリオにおいて、機能を定義し、生成し、使用するのに必要なステップを例示することによって提示される。次に、その例を少しずつ拡張して、このプログラミングモデルのさらなる能力を例示する。
【００８５】
（例示的なシナリオ）  
プログラミングモデルを例示するために、以下の対話シナリオを使用する。コンシューマアセンブリに関連するインタフェース定義が存在するものと想定されたい。そのインタフェースが何を行うかの詳細は、重要ではない。このインタフェースは、例えば、ＩＧｉｚｍｏと呼ばれる。コンシューマアセンブリは、これらのギズモ（ｇｉｚｍｏ）のインスタンスを、オープンエンドに（コンシューマは、インスタンスが、場合により、アプリケーションへの展開後の追加としてインストールされる、任意のアセンブリに由来することを可能にすることを望むことを意味する）作成することに関連する。
【００８６】
このシナリオが与えられると、このコンシューマとプロデューサとの間の対話ポイントを「ギズモファクトリ」と定義することは理にかなうことである。この「ギズモファクトリ」型の任意の数のコントリビューションが存在し得るが、各コントリビューションは、ＩＧｉｚｍｏのインスタンスを作成して戻すことである、同一の基本的な挙動を有する。
【００８７】
本明細書の以下において、このシナリオを拡張するが、差し当たって、コンシューマは、各コントリビューションから１つのギズモを作成する必要があるものと想定されたい。
【００８８】
（ポートの定義）  
ポートは、パブリックなクラス定義であり、定義アセンブリ内に入れられなければならない。ＣｏｎｔｒｉｂｕｔｏｎＰｏｒｔと呼ばれる、システムによって提供されるすべてのポート定義に関するベースクラスが存在する。このクラスは、コントリビューションメソッドの戻り型によってパラメータ化される一般的な型である。
【００８９】
ポート定義は、ＣｏｎｔｒｉｂｕｔｏｎＰｏｒｔベースクラスから派生することに加え、メタデータを保持していなければならない。最低限、ポート定義は、ＰｏｒｔＤｅｆｉｎｉｔｉｏｎ属性により修飾されなければならない。
【００９０】
ポート定義の最終的な要件は、この定義が、シグネチャメソッドを宣言しなければならないことである。シグネチャメソッドは、対応するコントリビューションメソッドに関するシグネチャを定義するだけでなく、コンシューマが、それらのメソッドを実際に呼び出す手段でもある。ポートクラスにおけるシグネチャメソッドは、ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ属性を保持することによって識別される。
【００９１】
これら要件が与えられると、この例示的なシナリオに関するポート定義は、以下のような外観となる。
【００９２】
【表１】
2009508252.tif 000003
【００９３】
シグネチャメソッドの形状は、このシナリオに関して、何が理にかなうかに基づく。この場合、例示のため、ギズモは、ギズモの構成に影響を与えるサイズパラメータを有するものと想定されたい。シグネチャメソッドの戻り型は、ＣｏｎｔｒｉｂｕｔｉｏｎＰｏｒｔベースクラスに提供される型と合致しなければならない。このルールには、例外が存在し、このことは、シグネチャメソッドが、ｖｏｉｄを戻す場合に当てはまることに留意されたい。その場合、Ｐｏｒｔベースクラスに提供される型は、オブジェクトでなければならない。また、シグネチャメソッドの本体部分にも留意されたい。これは、すべてのシグネチャメソッド実装が有する基本的な形態である。ＩｎｖｏｋｅＣｏｎｔｒｉｂｕｔｉｏｎメソッド（ＣｏｎｔｒｉｂｕｔｉｏｎＰｏｒｔベースクラスにおける保護されたメソッド）への呼び出しは、このポートインスタンスによって表されるコントリビューションメソッドを、カーネルに呼び出させる。
【００９４】
（コントリビューションの生成）  
ポートが定義されたので、プロデューサアセンブリが、どのようにギズモファクトリコントリビューションを提供するかについて検討する。コントリビューションは、メタデータを有する静的メソッドであり、これらのメソッドは、ブローカクラスのメンバである。ブローカクラスは、実装アセンブリに属し、したがって、パブリックでない。ブローカクラスは、決してインスタンス化されず、静的メンバだけしか含まないので、通常、静的クラスとして定義される（Ｃ＃により記述される場合）。また、ブローカクラスは、自身をブローカクラスとして識別するＢｒｏｋｅｒ属性を用いて宣言されなければならない。
【００９５】
以下のコードは、ギズモファクトリコントリビューションを生成するブローカクラスを例示するものである。
【００９６】
【表２】
2009508252.tif 000004
【００９７】
インスタンス化された実際のギズモオブジェクトについての詳細は省略されている。この例示的なコードの重要な側面は、生成属性が、ＣｒｅａｔｅＴｕｒｂｏＧｉｚｍｏを、ＧｉｚｍｏＦａｃｔｏｒｙポートに関するコントリビューションメソッドとして識別すること、および、このメソッドが、プライベートかつ静的であって、ポートのシグネチャメソッドと異なる名前を有するが、それ以外は、ポートのシグネチャメソッドと合致することである。このことは、コントリビューションメソッドに関する合致ルールに則っている。
【００９８】
（コントリビューションの使用）  
コンシューマは、コントリビューションを定義するポートのインスタンスを取得することにより、コントリビューションを使用する。カーネルしかコントリビューションのソースについての詳細を知らないので、カーネルは、ポートインスタンスが由来することが可能な唯一の場所である。ポートインスタンスは、コンシューマが作成して、コンシューマのブローカクラスのプライベートなフィールド内に静的に記憶するディスペンサと呼ばれるオブジェクトを介して、コンシューマに提供される。これらのフィールドは、これらのフィールドを使用として識別する属性（Ｃｏｎｓｕｍｐｔｉｏｎと呼ばれる）を保持していなければならない。
【００９９】
１つは、ＳｉｎｇｌｅＤｉｓｐｅｎｓｅｒと呼ばれ、もう１つは、ＭｕｌｔｉＤｉｓｐｅｎｓｅｒと呼ばれる、２つの形態のディスペンサが存在する。名前が示すとおり、これらのディスペンサは、単一のポートインスタンス、またはポートインスタンスのセットを提供する。ポートの型は、型パラメータとして提供される。
【０１００】
本発明のシナリオの場合において、ＭｕｌｔｉＤｉｓｐｅｎｓｅｒが必要とされるのは、任意の数が存在し得る、利用可能な各コントリビューションから１つのギズモを作成することが望ましいからである。以下のブローカクラスが、ギズモファクトリに関するディスペンサを含む。
【０１０１】
【表３】
2009508252.tif 000005
【０１０２】
ここで重要なのは、型ＭｕｌｔｉＤｉｓｐｅｎｓｅｒ＜ＧｉｚｍｏＦａｃｔｏｒｙ＞のフィールドである。このフィールドは、このブローカがロードされると、カーネルによって、（Ｃｏｎｓｕｍｐｔｉｏｎ属性を介して）自動的に認識されて、ポピュレートされる。型ＧｉｚｍｏＦａｃｔｏｒｙのすべてのコントリビューションは、各々が、ＧｉｚｍｏＦａｃｔｏｒｙのインスタンスによって、ディスペンサ内で表される。慣習として、このフィールドは、プライベートとしてマークが付けられ、アセンブリ内の残りのコードのポートインスタンスの集合体を公開する、対応するパブリックなアクセスプロパティが存在する。このプロパティの型は、ＭｕｌｔｉＤｉｓｐｅｎｓｅｒ＜＞ではなく、ＩＬｉｓｔ＜＞である。というのは、単に、このプロパティのコンシューマが、扱っているのがディスペンサであることを知る必要がない、または知ることを望まないために、すなわち、このプロパティのコンシューマが、ポートインスタンスのリストを有することを知っているだけで十分であるからである。実際、ＭｕｌｔｉＤｉｓｐｅｎｓｅｒ＜＞は、ＩＬｉｓｔ＜＞インタフェースを満たすのに必要とされるメンバ以外は、メンバを公開しない。
【０１０３】
このブローカクラスが記述されると、例示的なシナリオを完成させるために、コンシューマアセンブリには、以下のコードが記述されるだけでよい。
【０１０４】
【表４】
2009508252.tif 000006
【０１０５】
（実行フロー）  
次に図６を参照すると、コンシューマから単一のプロデューサに至る、このシナリオを通る実行フローを示す図が示されている。コンシューマアセンブリ６０２と、定義アセンブリ６０４と、カーネル６０６と、プロデューサアセンブリ６０８との間のフローが図示されている。
【０１０６】
（メタデータの追加）  
これまでのところ、例示的なシナリオでは、コントリビューションメソッドが、コンシューマによってどのように呼び出されるかを示してきた。しかし、それらのコントリビューションに付随し得るメタデータを呼び出すアプリケーションについては、以下で提供される。そのことを例示するために、この例は、わずかに変更されている。ギズモファクトリに、ブランド名が与えられ、したがって、すべてのギズモファクトリを、互いに区別することができる。コンシューマの機能は、コンシューマが作成する各ギズモを、ファクトリのブランド名によってキーが付けられたテーブルに入れるように変更される。
【０１０７】
コントリビューションメソッドにメタデータを追加するために使用することが可能な属性の型は、ポート定義の一部として識別されなければならない。これは、ポートクラス定義に直接的に配置されるＣｏｎｔｒｉｂｕｔｉｏｎＭｅｔａｄａｔａＴｙｐｅ属性を使用して行われる。
【０１０８】
この新たな例示的なシナリオにおいて、ギズモファクトリコントリビューションに関連付けられたあるメタデータ、すなわち、ブランド名が、識別される。最初のステップは、そのブランド名を表す属性を定義することである。これは単純なことなので、ここでは省略する。この属性の名前は、Ｂｒａｎｄであり、この名前は、ＡｌｌｏｗＭｕｌｔｉｐｌｅ＝ｆａｌｓｅと宣言されており、この名前は、Ｎａｍｅと呼ばれる単一のストリングプロパティを有するものと想定されたい。属性をポートに関連付けるために、以下のようなＣｏｎｔｒｉｂｕｔｉｏｎＭｅｔａｄａｔａＴｙｐｅを使用されたい。
【０１０９】
【表５】
2009508252.tif 000007
【０１１０】
この属性は、型ＧｉｚｍｏＦａｃｔｏｒｙのコントリビューションに、Ｂｒａｎｄ属性を用いて属性付けすることを可能にする。実際、この属性は、コントリビューションが、Ｂｒａｎｄ属性により修飾されること、およびその属性の値が、すべてのＧｉｚｍｏＦａｃｔｏｒｙコントリビューションにわたって一意でなければならないことを必要とする。
【０１１１】
各属性型は、１回だけ指定することが可能であるものの、このようにして、任意の数の属性をポート定義に関連付けることが可能であることに留意されたい。
【０１１２】
（コントリビューションに対するメタデータの提供）  
ポートの定義が変更されたので、コントリビューションは、以下に示されるように変更される必要がある。
【０１１３】
【表６】
2009508252.tif 000008
【０１１４】
この例を累進的な開示スタイルで記述した結果、ポート定義に対する最新の後方互換性のない変更が行われたことに留意されたい。実際、ポート定義にメタデータ型を追加することは、ＩｓＲｅｑｕｉｒｅｄがｆａｌｓｅに設定される場合に限って、後方互換性があると考えられる。
【０１１５】
（メタデータの使用）  
コントリビューションに備えられたメタデータへのアクセスは、型ＣｏｎｔｒｉｂｕｔｉｏｎＭｅｔａｄａｔａのＭｅｔａｄａｔａと呼ばれるプロパティを介して、一般的に、ＣｏｎｔｒｉｂｕｔｉｏｎＰｏｒｔベースクラスによって提供される。これは、基本的に属性の集合体であって、指定された属性型のインスタンスを探し出して戻す、ＦｉｎｄＡｔｔｒｉｂｕｔｅ＜＞およびＦｉｎｄＡｔｔｒｉｂｕｔｅｓ＜＞と呼ばれる汎用の便利なメソッドを伴う。
【０１１６】
以下は、どのように、前段の例のコンシューマコードが変更されて、ファクトリのブランド名によってキーが付けられた辞書に、作成されたギズモを入れることが可能であるかを示している。
【０１１７】
【表７】
2009508252.tif 000009
【０１１８】
ポート定義により、Ｂｒａｎｄ属性が、すべてのコントリビューションに付随しなければならないと宣言されているので、ＦｉｎｄＡｔｔｒｉｂｕｔｅの呼び出しは成功するものとみなして「間違いない」と考えられることに留意されたい。
【０１１９】
（依存関係の宣言）  
コントリビューションに対する依存関係を宣言するという概念を例示するために、例示的なシナリオが、再びわずかに変更される。今度は、コンシューマに、型ＧｉｚｍｏＦａｃｔｏｒｙの少なくとも１つのコントリビューションが与えられるという要件が、追加される。次いで、この要件がさらに改良されて、コンシューマが、提供された３つのコントリビューションのセットの中の１つと合致するブランド名を有する少なくとも１つのコントリビューションを探し出さなければならないことについて説明する。最終的に、この要件は、コンシューマに、ある特定のブランド名を有する１つのコントリビューションが与えられなければならないという要件にまで限定される。
【０１２０】
（少なくとも１つのコントリビューションの必要性）  
上記のようにコーディングされたとおり、コンシューマコードは、型ＧｉｚｍｏＦａｃｔｏｒｙのコントリビューションに対する依存関係を全く宣言しない。最も単純な形態の依存関係宣言は、少なくとも１つのコントリビューションの必要性を記述することである。これは、以下のように、Ｃｏｎｓｕｍｐｔｉｏｎ属性において、Ｒｅｑｕｉｒｅｄパラメータをｔｒｕｅに設定することによって行われる。
【０１２１】
【表８】
2009508252.tif 000010
【０１２２】
これは、このブローカ（および、関連するコード）がロードされるか、または実行される前提条件として、ディスペンサに入れられるべき、少なくとも１つのコントリビューションが存在しなければならないことを記述している。インストールがそのようなコントリビューションを含まない場合、そのブローカは棄却される。
【０１２３】
本明細書で説明した様々な技術は、ハードウェアまたはソフトウェアを用いて実装することもできるし、あるいは、適宜、その両方の組合せを用いて実装することもできる。このため、本発明の方法および装置、あるいは本発明のいくつかの側面または部分は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン読み取り可能な記憶媒体などの、有体の媒体において具現化されたプログラムコード（すなわち、命令）の形態をとることができる。そのプログラムコードが、コンピュータなどのマシンにロードされ、そのマシンによって実行されると、そのマシンが、本発明を実施するための装置となる。プログラマブルコンピュータ上でのプログラムコード実行の場合、コンピュータは一般に、プロセッサと、そのプロセッサによって読み取り可能な記憶媒体（揮発性および不揮発性のメモリおよび／または記憶要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを備える。１つまたは複数のプログラムは、コンピュータシステムと通信するために、高水準手続き型プログラミング言語またはオブジェクト指向プログラミング言語を用いて実装されることが好ましい。しかし、プログラムは、必要に応じて、アセンブリ言語またはマシン語を用いて実装することもできる。いずれにしても、言語は、コンパイルされる言語か、またはインタプリタ言語とすることができ、ハードウェアの実装と組み合わせることが可能である。
【０１２４】
また、本発明の方法および装置は、何らかの伝送媒体を介して伝送されるプログラムコードの形態で具現化されてもよく、そのプログラムコードが、ＥＰＲＯＭ、ゲートアレイ、ＰＬＤ（プログラマブル論理デバイス）、添付の図に示されるようなクライアントコンピュータ、ビデオレコーダなどのマシンによって受信され、そのマシンにロードされ、そのマシンによって実行されると、そのマシンが、本発明を実施するための装置となる。上記の伝送媒体は、電気配線もしくはケーブル配線、光ファイバ、または他の任意の伝送形態とすることができる。汎用プロセッサ上で実装されると、プログラムコードは、そのプロセッサと組み合わさって、本発明のインデックス機能を実行するように動作する独特な装置が提供される。
【０１２５】
様々な図の好ましい実施形態を参照しながら本発明について説明してきたが、本発明から逸脱することなく、他の類似する実施形態が使用されてもよく、あるいは、本発明と同一の機能を実行するために、説明した実施形態に変形および追加が行われてもよいことを理解されたい。さらに、特に、無線ネットワークデバイスの数が増えつづけるなか、ハンドヘルドデバイスオペレーティングシステム、および他の特定用途向けハードウェア／ソフトウェアインタフェースシステムを含む様々なコンピュータプラットフォームも、本明細書においては企図されていることを強調しておきたい。したがって、本発明は、いずれの単一の実施形態にも限定されるべきではなく、むしろ、特許請求の範囲に従う広がりおよび範囲を有するものとして解釈されるべきである。
【０１２６】
最後に、本明細書で説明し開示した実施形態は、他のプロセッサアーキテクチャ、コンピュータベースのシステム、またはシステム仮想化において使用されるように適合することが可能であり、そのような実施形態は、本明細書の開示によって明確に予想されるものである。したがって、本発明は、本明細書で開示した特定の実施形態に限定されるべきではなく、最も広く解釈されるべきである。
【図面の簡単な説明】
【０１２７】
【図１】属性を使用して、プラグ可能な機能を識別しフィルタリングすることに関連して使用するのに適した例示的なコンピューティングデバイスを示すブロック図である。
【図２】属性を使用して、プラグ可能な機能を識別しフィルタリングする際に、ソフトウェアモジュールが、共通の定義に準拠する機能を生成し使用することにより、どのように互いに統合されるかを示す図である。
【図３】共通の定義に準拠する機能を生成し使用することによって互いに統合されるソフトウェアモジュールに従う生成／使用の第１の実装例における実行フローを示す図である。
【図４】共通の定義に準拠する機能を生成し使用することによって互いに統合されるソフトウェアモジュールに従う生成／使用の第２の実装例における実行フローを示す図である。
【図５】共通の定義に準拠する機能を生成し消費することによって互いに統合されるソフトウェアモジュールに従う、所望される機能のプロデューサとコンシューマとの間の間接化のレベルを示す図である。
【図６】共通の定義に準拠する機能を生成し消費することによって互いに統合されるソフトウェアモジュールに従う、コンシューマから単一のプロデューサに至る、例示的なシナリオを通る実行フローを示す図である。
【図１】
2009508252.tif 000011
【図２】
2009508252.tif 000012
【図３】
2009508252.tif 000013
【図４】
2009508252.tif 000014
【図５】
2009508252.tif 000015
【図６】
2009508252.tif 000016
【国際調査報告】
2009508252.tif 000017
2009508252.tif 000018