(57)【要約】  コンピューティングコンポーネントを独立にバージョニングし、そのようなコンポーネントを分離し、それらを動的にバインドする管理された自動プログラミングモデルを提供する。例えば、アプリケーションおよびアドインなどのコンポーネントは、互いに独立にバージョニングすることができ、その結果、これらのコンポーネントの異なるバージョンが、それでも通信できるようになり、あるいは、名目上の事例で、同一バージョンが通信できるようになる。さらに、そのようなコンポーネントは、管理された自動プログラミングモデルによって分離され、その結果、そのようなコンポーネントを、シームレスな形で統合解除でき、他のコンポーネントとバインドできるようになる。最後に、独立バージョニングおよびコンポーネント分離は、ランタイムのコンポーネントの動的バインディングを有利に可能にする。
2008544398.tif 000002
【特許請求の範囲】
【請求項１】
第１のコンポーネント、第２のコンポーネント、第１のアダプタ、第２のアダプタ、およびプロトコルを使用するステップであって、前記第１のアダプタは、前記第１のコンポーネントおよび前記プロトコルに結合され、前記第２のアダプタは、前記第２のコンポーネントおよび前記プロトコルに結合され、前記プロトコルは、それぞれ前記第１のアダプタおよび前記第２のアダプタを介して前記第１のコンポーネントと前記第２のコンポーネントとの間の通信レイヤを提供する、使用するステップと、
管理された自動フレームワークを使用するステップであって、管理された自動モデルは、主にプロトコルおよび選択された型を公開することによって、選択された情報を前記第１のコンポーネントから前記第２のコンポーネントにおよびその逆に不可視にすることによって少なくとも前記第１のコンポーネントと前記第２のコンポーネントとの間の分離を提供するために、前記第１のアダプタ、前記第２のアダプタ、および前記プロトコルを組み込む、使用するステップと
を備えた、コンピューティングエンティティ間の自動化された通信および分離を提供するコンピュータ可読命令を実行することを特徴とするコンピュータ可読記憶媒体。
【請求項２】
前記第１のコンポーネントと前記第２のコンポーネントとの間の前記分離は、前記第２のコンポーネントへの前記第１のコンポーネントの動的バインディングを可能にすることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
【請求項３】
前記第１のアダプタおよび前記第２のアダプタは、それぞれ（ａ）プロトコルアダプタおよび（ｂ）ビューアダプタのうちの少なくとも１つであることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
【請求項４】
前記第１のコンポーネントと前記第２のコンポーネントとの間の前記分離は、リモーティング境界によって維持されることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
【請求項５】
前記リモーティング境界は、プロセス内のミニプロセス、別々のプロセス、または別々の物理的マシンの同等物であることを特徴とする請求項４に記載のコンピュータ可読記憶媒体。
【請求項６】
前記管理された自動モデルは、．ＮＥＴ環境内で実装されることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
【請求項７】
前記第１のコンポーネントは、前記管理された自動モデルに関連するアプリケーションであり、前記第２のコンポーネントは、アドインであることを特徴とする請求項１に記載のコンピュータ可読記憶媒体。
【請求項８】
第１のコンポーネント、第２のコンポーネント、第１のアダプタ、第２のアダプタ、およびプロトコルを使用するステップであって、前記第１のアダプタは、前記第１のコンポーネントおよび前記プロトコルに結合され、前記第２のアダプタは、前記第２のコンポーネントおよび前記プロトコルに結合され、前記プロトコルは、それぞれ前記第１のアダプタおよび前記第２のアダプタを介して前記第１のコンポーネントと前記第２のコンポーネントとの間の通信レイヤを提供する、使用するステップと、
管理された自動フレームワークを使用するステップであって、管理された自動モデルは、主にプロトコルおよび選択された型を公開することによって、選択された情報を前記第１のコンポーネントから前記第２のコンポーネントにおよびその逆に不可視にすることによって少なくとも前記第１のコンポーネントと前記第２のコンポーネントとの間の独立バージョニングを提供するために、前記第１のアダプタ、前記第２のアダプタ、および前記プロトコルを組み込む、使用するステップと
を備えた、コンピューティングエンティティ間の自動化された通信およびバージョニング弾力性を提供するコンピュータ可読命令を実行することを特徴とするコンピュータ可読記憶媒体。
【請求項９】
前記第１のコンポーネントと前記第２のコンポーネントとの間の前記バージョニングは、前記第２のコンポーネントへの前記第１のコンポーネントの動的バインディングを可能にすることを特徴とする請求項８に記載のコンピュータ可読記憶媒体。
【請求項１０】
前記第１のアダプタおよび前記第２のアダプタは、それぞれ（ａ）プロトコルアダプタおよび（ｂ）ビューアダプタのうちの少なくとも１つであることを特徴とする請求項８に記載のコンピュータ可読記憶媒体。
【請求項１１】
前記第１のコンポーネントと前記第２のコンポーネントとの間の前記独立バージョニングは、前記第１のコンポーネントが前記第２のコンポーネントに関してバージョンを変更することおよびその逆を可能にすることを特徴とする請求項８に記載のコンピュータ可読記憶媒体。
【請求項１２】
前記管理された自動モデルは、．ＮＥＴ環境内で実装されることを特徴とする請求項８に記載のコンピュータ可読記憶媒体。
【請求項１３】
前記第１のコンポーネントは、前記管理された自動モデルに関連するアプリケーションであり、前記第２のコンポーネントは、アドインであることを特徴とする請求項８に記載のコンピュータ可読記憶媒体。
【請求項１４】
第１のコンポーネント、第２のコンポーネント、第１のアダプタ、第２のアダプタ、およびプロトコルを使用するステップであって、前記第１のアダプタは、前記第１のコンポーネントおよび前記プロトコルに結合され、前記第２のアダプタは、前記第２のコンポーネントおよび前記プロトコルに結合され、前記プロトコルは、それぞれ前記第１のアダプタおよび前記第２のアダプタを介して前記第１のコンポーネントと前記第２のコンポーネントとの間の通信レイヤを提供する、使用するステップと、
管理された自動フレームワークを提供するステップであって、管理された自動モデルは、前記第１のコンポーネントおよび前記第２のコンポーネントのうちの少なくとも１つによって使用されるリフレクション機構を制御することによって、前記第１のコンポーネントと前記第２のコンポーネントとの間のサポートレートバインディングを提供するために、前記第１のアダプタ、前記第２のアダプタ、および前記プロトコルを組み込む、提供するステップと
を備えた、コンピューティングエンティティ間の自動化された通信およびレートバインディング能力を提供するコンピュータ可読命令を実行することを特徴とするコンピュータ可読記憶媒体。
【請求項１５】
前記第１のアダプタおよび前記第２のアダプタは、それぞれ（ａ）プロトコルアダプタおよび（ｂ）ビューアダプタのうちの少なくとも１つであることを特徴とする請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１６】
前記プロトコルは、基底クラスに基づくことを特徴とする請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１７】
前記第１のアダプタおよび前記第２のアダプタは、基底クラスに基づくことを特徴とする請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記レートバインディングは、リモーティング境界にまたがって達成されることを特徴とする請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記リモーティング境界は、プロセス内のミニプロセス、別々のプロセス、または別々の物理的マシンの同等物であることを特徴とする請求項１８に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記管理された自動フレームワークは、リモーティング境界にまたがる型リーケージを防ぐために、前記第１のアダプタ、前記第２のアダプタ、および前記プロトコルを管理することを特徴とする請求項１４に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本特許文書の開示の一部に、著作権保護の対象になる材料が含まれる可能性がある。著作権所有者は、特許商標局の特許ファイルまたは記録に現れる本特許文書または特許開示の何人による写真複製にも異議を唱えないが、それ以外の点ではすべての著作権を留保する。次の表記が、本文書に適用されなければならない。Ｃｏｐｙｒｉｇｈｔ（Ｃ）２００５、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐ．
【０００２】
本発明は、全般的にはフィールドコンピューティングに関する。より具体的には、本発明は、コンポーネントをバインドする管理された自動（ｍａｎａｇｅｄ  ａｕｔｏｍａｔｉｏｎ）に関する。
【背景技術】
【０００３】
それぞれワードプロセッシングプログラムおよびスペルチェッカなどのプログラムに対応するものとすることができるアプリケーションおよびアドインなどのコンポーネントは、静的環境では簡単に統合される。その理由は、そのようなシナリオで、開発者が、どのコンポーネントが一緒に良好に相互作用するかを先験的に知っていることである。例えば、開発者が、あるワードプロセッシングプログラムが特定のスペルチェッカと良好に相互作用することを先験的に知っている場合がある。そのようなコンポーネントは、ビルド時に簡単にバインドすることができる。
【０００４】
しかし、動的バインディングが望まれる場合には、問題はより複雑になる。言い換えると、ランタイムのコンポーネントの動的バインディングは、コンポーネントのバージョニングおよびコンポーネントの相互分離などの問題のゆえに、より困難な問題を提示する。バージョニングに関して、コンポーネントの異なるバージョンは、しばしば、それらのコンポーネントの非互換性につながる。例えば、あるアプリケーションのバージョン１．０が、あるアドインのバージョン１．０と正しく相互作用する場合がある。しかし、バージョニングがオフの場合、例えば、そのアプリケーションがバージョン２．０にアップグレードされたが、そのアドインがバージョン１．０のままである場合に、この２つのコンポーネントが、一緒に良好に働かない場合があり、あるいは、まったく働かない場合もある。
【０００５】
第２の問題は、コンポーネントの分離に関する問題につながる。例えば、前述のアプリケーションが、そのアドインと統合される場合に、いずれかのコンポーネントのアップグレードが、困難または不可能であるとわかる場合がある。したがって、コンピュータユーザが、アプリケーションをバージョン２．０にアップグレードしたいが、アドインのバージョン１．０に満足している場合に、そのようなユーザは、統合されたシステムを分解せずにこの２つのアプリケーションを分離するのに苦労する可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
少なくともこの２つの例示的な問題すなわちバージョニングおよび分離を解決するために、コンポーネントの異なるバージョンを互いと共に使用することができ、そのようなコンポーネントを、それらが統合解除（ｄｉｓｉｎｔｅｇｒａｔｅ）された時に互いに影響しない範囲まで互いから分離できる、動的バインディングシステムが望ましいはずである。さらに、ランタイムにコンポーネントの動的バインディングを可能にし、したがってこれらのコンポーネントがマネージコードプラットフォーム内で通信できるようにすることができる、管理された自動プログラミングモデルを提供することが望ましいはずである。
【課題を解決するための手段】
【０００７】
コンピューティングシステム内のコンポーネントが独立にバージョニングし、互いから分離し、互いに動的にバインドすることを可能にする管理された自動プログラミングモデルを提供する。アプリケーションおよびアドインなどのコンポーネントは、同一バージョンではないにもかかわらず、プロトコルを介して互いと通信することができる。言い換えると、アドインは、アプリケーションより上位または下位のいずれかのバージョンでありながら、そのアプリケーションと共に機能することができ、逆も同様である。
【０００８】
さらに、これらのコンポーネントは、統合および統合解除の問題を引き起こさずに、所与のアドインをアプリケーションにシームレスにバインドでき、アンバインドできるように、管理された自動プログラミングモデルによって分離もされる。例えば、アドインがアプリケーションから相対的に分離されているので、あるアドインの旧バージョンを、アプリケーションからシームレスに除去することができ、なおかつ、その旧バージョンは、そのアプリケーションと通信することができる。この種の分離は、リモーティング境界（ｒｅｍｏｔｉｎｇ  ｂｏｕｎｄａｒｙ）によって提供することができる。
【０００９】
最後に、コンポーネントの独立バージョニングと分離との両方が、あるコンポーネントの別のコンポーネントへの動的バインディングを可能にする。バージョニング機能と、コンポーネントのシームレスな切替を可能にするコンポーネントの提供される分離とのゆえに、コンポーネントの異なるバージョンをいつでも（ビルド時を超えて）互いにバインドすることができる。
【００１０】
本発明の追加の特徴は、添付図面を参照して進行する、例示的諸態様の次の詳細な説明から明白になる。
【００１１】
前述の要約ならびに次の本発明の詳細な説明は、添付図面と共に読まれる時によりよく理解される。本発明を示すために、本発明の様々な態様を示す。しかし、本発明は、開示される特定のシステムおよび方法に限定されない。
【発明を実施するための最良の形態】
【００１２】
概要
管理された自動プログラミングモデル（ＭＡＰＭ）の少なくとも３つの全般的な態様すなわち、（１）バージョニング、（２）分離、および（３）動的バインディングを検討する。下の説明では、どのようにして、コンポーネントを互いから分離できるフレームワークを提供すると同時に、異なるコンポーネントのバージョニングを維持できるかを説明する。このバージョニングおよび分離のプロパティは、本発明の動的バインディング態様につながる。異なるコンポーネントバージョンにもかかわらず互いにバインドできるコンポーネント、および、他のコンポーネントからアンバインドでき、バインドできるようにするために互いから分離できるコンポーネントは、コンポーネントの動的（スタティックではなく）バインディングの自然なサポートにつながる。
【００１３】
最後に、ＭＡＰＭがその上にある．ＮＥＴフレームワークを示し、その後、例示的なネットワーク化されたコンピューティング環境すなわち分散コンピューティング環境の概略図を示す。また、それに関連して本発明を実施できる適切なコンピューティング環境の短い全般的な説明を提供する。
【００１４】
管理された自動プログラミングモデル（ＭＡＰＭ）の諸態様
本発明の一態様では、図１で、ＭＡＰＭ（または同等に、管理された自動フレームワーク）の「プロトコル」が、複数の独立にバージョニングするコンポーネントの間で通信するのに使用される。すなわち、コンポーネント自体がバージョニングすることはできるが、プロトコルが変化してはならない。このプロトコルは、それを介してコンポーネントが通信する仕様または契約とみなすことができる。この安定した契約は、別々にバージョニングするコンポーネントが頼り続けることのできる基礎である。
【００１５】
図１に、コンポーネントの独立バージョニングの一態様を示す。２つのコンポーネントすなわちコンポーネントＡ  １０２およびコンポーネントＢ  １０６が与えられる。これらのコンポーネントは、プロトコル１０４を介して通信する。２つのコンポーネント１０２および１０６は、他の図示のコンポーネントすなわちコンポーネント１０８、１１０、および１１２のどれもが、コンポーネントＡ  １０２の代わりをすることができ、コンポーネント１１４、１１６、および１１８が、コンポーネントＢ  １０６の代わりをすることができることを示すために破線内に示されている。したがって、コンポーネントＡ  １０２およびＢ  １０６は、任意の包括的なコンポーネントにすぎない。
【００１６】
一定のままであり、必ずしも変化しないプロトコル１０４を有することによって、異なるバージョンのコンポーネントが問題のプロトコルを認識する限り、これらの異なるバージョンのコンポーネントが互いに相互作用することが可能になる。したがって、例えば、名目上の事例で、コンポーネントＡのバージョン１．０  １０８が、このプロトコル１０４を介してコンポーネントＢのバージョン１．０  １１４と通信することができる。しかし、より重要なことに、異なるバージョン番号が通信することもできる。したがって、コンポーネントＡのバージョン１．０  １０８は、コンポーネントＢのバージョン５．５  １１６およびコンポーネントＢのバージョン１１．０  １１８と通信することもできる。同様に、コンポーネントＡのバージョン５．０  １１０は、コンポーネントＡのバージョン５．０  １１０より高いまたはこれより低いのいずれかである他のコンポーネントのバージョンと通信することができ、コンポーネントＡのバージョン５．０  １１０は、コンポーネントＢのバージョン１．０  １１４またはコンポーネントＢのバージョン１１．０  １１８と通信することができる。
【００１７】
本発明のこの態様の要点は、任意の２つのコンポーネントが互いに独立にバージョニングできることである。これは、コンポーネントの間のよりよい互換性と、．ＮＥＴなどのコンピューティングフレームワークでそのようなコンポーネントを使用する時の使いやすさとを可能にする。
【００１８】
本発明のもう１つの態様では、図２で、アダプタが図示されており、ここで、アダプタは、そのめいめいのコンポーネントとプロトコルとの中間にある。したがって、アダプタＡ  ２０８が図示されており、このアダプタは、コンポーネントＡ  ２０２とプロトコル２０４との間に配置される。同様に、アダプタＢ  ２１０は、コンポーネントＢ  ２０６とプロトコル２０４との間に配置される。アダプタは、本明細書では、あるオブジェクトのＡＰＩを別のオブジェクト（またはコンポーネント）に適合させるオブジェクトと理解される。ＭＡＰＭでは、アダプタは、プロトコルを実装するかプロトコルを呼び出すかのいずれかであるマネージ型である。言い換えると、アダプタは、具象実装からプロトコルを隠すクラスである。
【００１９】
興味深いことに、様々なアダプタがある。例えば、「プロトコル」アダプタは、プロトコルを実装するクラスと理解される。プロトコルアダプタは、多数の形すなわち、他のクラスによって使用されるシールクラス、アプリケーション全体を通じて使用される抽象基底クラス、または任意選択で拡張できる多形実装クラスの形をとることができる。ＭＡＰＭは、任意のプロトコルアダプタの基本構成要素として使用できる抽象基底クラスを含む多数のプロトコルアダプタを再利用のために提供する。
【００２０】
アダプタのもう１つの例が、「ビュー」アダプタである。「ビュー」は、プロトコルを呼び出すクラスと単純に定義される。ビューは、本質的に、プロトコルおよびプロトコルアダプタの背後に隠蔽された、実装のためのプロキシである。ビューは、フレンドリなプログラミングの正面をユーザに提示する。それを行う際に、ビューは、プロトコル自体の制約および複雑さを隠蔽する。プロトコルが、他のプロトコルおよびプリミティブ型だけを公開することができる場合に、ビューは、シリアライズ不能な型および他のビューを含む事実上すべての型を公開することができる。プロトコルアダプタと異なって、ユーザまたはコンシューマに提示されるビューは、通常、単一の形すなわちシールクラスであるが、これらは、通常、ＭＡＰＭによって提供される多形実装クラスからも導出される。さらに、ＭＡＰＭは、上でプロトコルアダプタに関して同様に述べたように、再利用可能なビューアダプタをも提供する。
【００２１】
さらに、この２つのタイプのアダプタすなわち、プロトコルアダプタおよびビューアダプタを組み合わせることができる。したがって、特定のクラスが、ビューアダプタとプロトコルアダプタとの両方として働くことが、かなり一般的である。図３に、本発明の一態様で使用できる異なるタイプのアダプタのうちのいくつかを示す。汎用アダプタ３０２は、破線内に示されており、このタイプのアダプタは、３つの形すなわち、プロトコルアダプタ３０４、組合せアダプタ３０６、およびビューアダプタ３０８のうちの少なくとも１つとしてインスタンス化することができる。上で述べたように、プロトコルアダプタ３０４およびビューアダプタ３０８を組み合わせて、組合せアダプタ３０６を構成することができる。
【００２２】
図２および３を組み合わせて、図４に、コンポーネント、ビューアダプタ、プロトコルアダプタ、およびプロトコルのすべてが相互作用する、本発明のもう１つの態様を示す。図４によれば、コンポーネントＡ  ４０２は、ビューアダプタＡ  ４１２に結合され、ビューアダプタＡ  ４１２は、プロトコルアダプタＡ  ４０８に結合される。上の図３に関する議論に基づいて、プロトコルアダプタＡ  ４０８は、プロトコル４０４を実装し、ビューアダプタＡ  ４１２は、プロトコル４０４を呼び出す。類似する論理が、プロトコルアダプタＢ  ４１０およびビューアダプタＢ  ４１４にあてはまる。したがって、ビューアダプタＡ  ４１２−プロトコルアダプタＡ  ４０８−プロトコル４０４−プロトコルＢ  ４１０−ビューアダプタＢ  ４１４のパイプライン全体は、２つのコンポーネントすなわちコンポーネントＡ  ４０２およびコンポーネントＢ  ４０６が、この２つのコンポーネントの異なるバージョンが存在できる形で通信することを可能にすると同時に、この２つのコンポーネントを互いから分離することを可能にする。
【００２３】
スプレッドシートおよびデータベースのシナリオは、コンポーネントを伴うこのパイプラインをどのように使用できるかの実世界の例を示す。サードパーティが、データベースからスプレッドシートアプリケーションにスプレッドシートデータを駆動するコードをプラグインすることを望む場合がある。データがデータベースからプルされたならば、スプレッドシートアプリケーションは、ある動作および操作を実行し、データをデータベースに押し戻す。したがって、例えば、Ｅｘｃｅｌなどのスプレッドシートプログラムは、データベースに関して知る必要すらなく、ドライバに関してのみ知る必要がある。したがって、図４によれば、コンポーネントＡ  ４０２をＥｘｃｅｌスプレッドシートアプリケーションに対応するものとすることができ、コンポーネントＢ  ４０６をデータベースに対応するものとすることができる。プロトコルアダプタＡ  ４０８およびＢ  ４１０は、プロトコル４０４を実装し、ビューアダプタＡ  ４１２およびＢ  ４１４は、そのプロトコルを呼び出し、その結果、コンポーネントＢ  ４０６内のデータをコンポーネントＡ  ４０２にプルできるようになり、コンポーネントＡ  ４０２は、そのデータを操作したならば、そのデータをコンポーネントＢ  ４０６に押し戻すことができる。
【００２４】
本発明のもう１つの態様では、図５に、プロトコルを介して通信する２つの通常のコンポーネントの分離が示されている。そのようなコンポーネントは、リモーティング境界にまたがって通信することができる。．ＮＥＴフレームワークにおけるリモーティング境界の１つの例が、ＡｐｐＤｏｍａｉｎである。ＡｐｐＤｏｍａｉｎは、プロセス内のミニプロセスの形で境界を提供し、その結果、そのＡｐｐＤｏｍａｉｎ内のコードを他のコードから分離できるようになる。しかし、リモーティング境界は、異なるプロセッサの間の境界、異なるプロセスの間の境界、さらには異なるマシンの間の境界など、ソフトウェアまたはハードウェアで他の形で現れることができる。
【００２５】
例えば、スペルチェッカを、あるＡｐｐＤｏｍａｉｎ内に含めることができ、ワードプロセッシングアプリケーションを、別のＡｐｐＤｏｍａｉｎに含めることができる。この分離は、スペルチェッカおよびワードプロセッシングアプリケーションがめいめいの完全性を維持することを可能にするだけではなく、この２つのコンポーネントの簡単な分離も可能にする。そうではなく、ワードプロセッシングアプリケーションとスペルチェッカとの両方が同一のＡｐｐＤｏｍａｉｎに含まれる場合には、この２つの分離が、はるかに難しくなるはずである。そのような分離は、例えば、この２つのコンポーネントの異なるバージョンが使用可能であり、望まれる場合に、必要になる可能性がある。
【００２６】
図５に移ると、リモーティング境界５１２が示されている。上で述べたように、ＡｐｐＤｏｍａｉｎの形で境界を構成することができ、ここで、ＡｐｐＤｏｍａｉｎは、所与のプロセス内の分離されたミニプロセスである。この境界は、あるコンポーネントから別のコンポーネントへのコードのリモーティングまたは送出を防ぐことができる。コンポーネントすなわち、コンポーネントＡ  ５０２およびコンポーネントＢ  ５０６は、アプリケーション、アドイン、またはその種の同等の何であれ、これまでに述べたコンポーネントのいずれかとすることができる。図５に、コンポーネントＡ  ５０２がビューアダプタＡ  ５０８を使用して、プロトコルＢ  ５１０によって実装されるプロトコル５０４を呼び出し、したがって、コンポーネントＡ  ５０２がコンポーネントＢ  ５０６と通信することを可能にする実施態様を示す。リモーティング境界５１２は、望まれない通信がコンポーネントＡ  ５０２とＢ  ５０６との間で行われないことと、これらのコンポーネントを他方のコンポーネントに影響せずに交換できることとを保証する。
【００２７】
本発明のもう１つの態様では、図６に、管理された自動プログラミングモデル（ＭＡＰＭ）と、ＭＡＰＭが、上で述べた２つの態様すなわちバージョニング（例えば、図１を参照されたい）および分離（例えば、図５を参照されたい）につながるコンポーネントの動的バインディングをどのように可能にするかを示す図である。ＭＡＰＭは、．ＮＥＴフレームワークに基づくものとすることができるという点でマネージモデルであり、．ＮＥＴフレームワークは、データおよび命令の格納のためのメモリの割振り、アプリケーションに許可を与えることおよび拒否すること、これらのアプリケーションの実行の管理、必要でないリソースのためのメモリの再割振りなど、プログラム実行の様々な態様を管理するのを助ける。
【００２８】
ＭＡＰＭフレームワーク６０４が図示されており、ＭＡＰＭ  ６０４は、事前定義のアダプタ６０６および６０８と事前定義のプロトコル６０２とを有する。ＭＡＰＭ  ６０４は、アプリケーション６１０およびアドイン６１２など、独立にバージョニングするエンティティ（Entity）を作成する能力を提供する。これらのエンティティを分離することもでき、その結果、これらのエンティティをアンロードできるようになり、これらのエンティティは、異なるセキュリティコンテキストを有することができるようになる。重要なことに、アドイン６１２は、任意のリモーティング境界にまたがってアプリケーション６１０にランタイムに（コンパイル時ではなく）レート（late）バインディングすることができる。
【００２９】
したがって、図６Ａに、第１のコンポーネントすなわちアプリケーション６１０が、時刻ｔ＝１にＭＡＰＭ  ６０４を介して、あるアドイン（図示せず）にバインドされることを示す。少し後に、おそらくはランタイム中に、時刻ｔ＝２に、第２のコンポーネントすなわちもう１つのアドイン６１２が、ＭＡＰＭ  ６０４に追加される。アドイン６１２は、動的に追加されるという概念を伝えるために、破線を介して追加されるものとして示されている。対照的に、アプリケーション６１０は、ビルド時に（ある以前のアドインに）バインドすることができ、したがって、実線を介してＭＡＰＭ  ６０４に接続されている。アドイン６１２がｔ＝２にバインドされる必要はなく、実際に、アドイン６１２をｔ＝１にアプリケーション６１０にスタティックにバインドできることに留意されたい。
【００３０】
図１〜６を参照して上で述べた少なくとも３つの目標すなわち、バージョニング、分離、およびレートバインディングを達成する際に、様々な技術的問題が生じる。例えば、バージョン弾力性を維持するために、プロトコルのメソッドのシグネチャが、そのプロトコルを用いて定義される他のプロトコルまたはシリアライズ可能な値型、あるいは．ＮＥＴなどのフレームワークに含まれるプリミティブ型だけを公開する場合がある。したがって、図６Ｂに、プロトコル６０２を示すが、このプロトコルは、あるメソッド６２０を有する。そのようなメソッドは、シグネチャ６２２を有し、メソッド６２０のシグネチャ６２２は、メソッド６２０の名前をパラメータの個数および型（およびその順序）と組み合わせたものである。図示の例では、２つの引数すなわち、「ｏｔｈｅｒ  ｐｒｏｔｏｃｏｌ（他のプロトコル）」および「ｓｅｒｉａｌｉｚａｂｌｅ  ｖａｌｕｅ  ｔｙｐｅ（シリアライズ可能な値型）」が示されている。「ｏｔｈｅｒ  ｐｒｏｔｏｃｏｌ」は、このプロトコルのこのメソッドのこのシグネチャが公開できる、ある他のプロトコル６２４に対応する。「ｓｅｒｉａｌｉｚａｂｌｅ  ｖａｌｕｅ  ｔｙｐｅ」は、単に任意の通常のシリアライズ可能な型である。例えば、これは、次のように、データのかたまりごとにフェリーを構成できる単純な集約型とすることができる。
【００３１】
【表１】
2008544398.tif 000003
【００３２】
シリアライズ可能な属性が、値によってこのマーシャリングを行うのに必要であり、これは、このデータが、リモーティング境界にまたがって新しいインスタンスにコピーされることを意味する。
【００３３】
さらに、次の型リーケージ（ｔｙｐｅ  ｌｅａｋａｇｅ）ルールでは、プロトコルが、そのシグネチャでイベントまたは委任を公開しない場合がある。その理由は、イベントおよび委任が、本質的に、関数ポインタを表す型であるからである。関数ポインタは、委任クラスでカプセル化されるが、呼び出される関数は、必ずサブクラスで記述される。
【００３４】
もう１つの例として、上で述べたコンポーネントが、実際に互いに分離されなければならない場合に、それらのコンポーネントの型は文字通り相互に不可視でなければならない。合意されたプロトコルだけが、両方のコンポーネントに可視でなければならない。言い換えると、各コンポーネントの型は、そのコンポーネントだけの秘密にされなければならず、他のコンポーネントと共有されてはならず、プロトコルだけが、両方のコンポーネントによって見られなければならない。これが、本発明の一態様が実施する型リーケージルールである。
【００３５】
したがって、図６Ｃに、図６Ａに関して述べた２つのコンポーネントすなわち、アプリケーション６１０およびアドイン６１２を示す。アプリケーションは、あるアプリケーション型６３０を有し、このアプリケーション型６３０は、期待される通り、このアプリケーション６１０に可視である。同様に、アドイン６１２は、アドイン６１２に可視のあるアドイン型６３２を有する。しかし、アドイン型６３２は、アプリケーション６１０に可視ではなく、これは、アドイン型６３２を破線内に図示することによって示されている。同様に、アプリケーション型６３０は、アドイン６１２に可視ではない。しかし、プロトコル６０２は、この両方のコンポーネントに可視である。
【００３６】
それでも、本発明の他の態様では、プロトコルの規約が定義される。これらの規約は、．ＮＥＴインターフェース（．ＮＥＴフレームワークの包括的な議論については下を参照されたい）であり、必ずしも抽象クラスではない。インターフェースを選択した理由は、挙動がプロトコルに関連する可能性を除去するため、ならびにプロトコルがリモーティングトランスポートにかかわりなく働くことを保証するためである。これによって、コンストラクタが、リモーティング境界にまたがるプロトコルを用いて呼び出される可能性も除去される。境界にまたがるコンストラクタの呼出しは、コンストラクタパラメータがオブジェクト配列内で様々なインスタンス作成関数の１つを介して渡されなければならないので、型リーケージ（上で述べた）をもたらす可能性がある。
【００３７】
さらに、そのような．ＮＥＴインターフェースは、すべてが、共通の基底インターフェースから導出される。共通基底インターフェースの例が、次のルートプロトコルＳｙｓｔｅｍ．Ｐｒｏｔｏｃｏｌ．ＩＰｒｏｔｏｃｏｌである。
【００３８】
【表２】
2008544398.tif 000004
【００３９】
上記から明らかにわかる通り、ＩＰｒｏｔｏｃｏｌはＩＤｉｓｐｏｓａｂｌｅから派生する。これは、すべてのプロトコル実装がＤｉｓｐｏｓａｂｌｅパターンを実装することを可能にし、それを必要とし、Ｄｉｓｐｏｓａｂｌｅパターンの実装は、プロトコル実装によって使用されるリソースの、ある度合の決定論的完結化を可能にする。上の第１のメソッドＱｕｅｒｙＰｒｏｔｏｃｏｌは、実装が他のプロトコルをサポートするかどうかをコンシューマが実装に尋ねることを可能にする。あるいは、その代わりに、メソッドＱｕｅｒｙＰｒｏｔｏｃｏｌは、より特定でないプロトコル（ＩＰｒｏｔｏｃｏｌ自体など）からより特定のプロトコルを入手することを可能にするかどうかを尋ねることを可能にする。特筆すべきことに、あるプロトコルから同一アイデンティティ上の別のプロトコルを得る唯一の形は、ＱｕｅｒｙＰｒｏｔｏｃｏｌメソッドを介することである。
【００４０】
ＱｕｅｒｙＰｒｏｔｏｃｏｌは、ストリングをとる。このストリングパラメータには、照会されるプロトコルの完全修飾型名を含めることができる。したがって、ＱｕｅｒｙＰｒｏｔｏｃｏｌへの呼出しは、次のような形とすることができる。
【００４１】
【表３】
2008544398.tif 000005
【００４２】
ここでは、「Ｔｙｐｅ」型を直接に使用するのではなく、ストリングが使用されている。これは、セキュリティ問題のゆえである。
【００４３】
さらに、ＩＰｒｏｔｏｃｏｌ．ＱｕｅｒｙＰｒｏｔｏｃｏｌの実装を容易にするために、ＭＡＰＭでは、新しい例外すなわちＰｒｏｔｏｃｏｌＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎが定義され、この例外は、照会されたプロトコルがサポートされない時に必ず送出される（．ＮＥＴの同等物はＥ＿ＮＯＩＮＴＥＲＦＡＣＥである）。例外は、プロトコルアセンブリがクラスまたは実装を含まないというガイドラインに対する１つの例外とすることができる。この場合がそうであるが、いくつかの場合に、あるプロトコルの実装で使用される新しい例外を定義する必要がある場合がある。
【００４４】
ＩＰｒｏｔｏｃｏｌの他方のメソッドは、ＧｅｔＲｅｍｏｔｅＨａｓｈＣｏｄｅである。このメソッドは、プロトコルのアイデンティティを提供するために存在する。ＧｅｔＲｅｍｏｔｅＨａｓｈＣｏｄｅは、所与のプロトコルを実装するオブジェクトのインスタンスごとに一意の値を返す。この値は、プロトコルコンシューマによって、アイデンティティを判定するのに使用することができる。
【００４５】
型リーケージ（上で述べた）の制約に起因して、リフレクションは、プロトコル（またはリモーティング）境界にまたがっては許可されない。リフレクションは、一般に、ランタイムだけにクラス情報を発見する機構と理解される。したがって、本発明のこの態様では、リフレクションの機能性をエミュレートし、プロトコル境界にまたがる具象機能性へのレートバインディングの能力を可能にする実装をサポートする、プロトコルのグループが提供される。リフレクションは、これらのプロトコルが、ある種のシステム型またはリフレクション型を公開しないことを意味するが、これらのプロトコルが公開するものは、透過的な形でリフレクション機能性のサブセットを実装する能力であり、この能力は、クライアントが、設計（またはビルド）時ではなくランタイムにメソッドおよびプロパティを発見し、呼び出すことを可能にする。リフレクションプロトコルのいくつかの例は、次のように定義される（これらのプロトコルのいくつかが、この文書で後で述べるコレクションプロトコルに頼ることに留意されたい）。
【００４６】
【表４】
2008544398.tif 000006
【００４７】
【表５】
2008544398.tif 000007
【００４８】
【表６】
2008544398.tif 000008
【００４９】
【表７】
2008544398.tif 000009
【００５０】
上のコードを調べると、ｓｙｓｔｅｍ．ｐｒｏｔｏｃｏｌアセンブリが、多数の後続プロトコルのルートにあることが明らかになる。例えば、図７Ａに、本発明の一態様でのプロトコル間の階層関係を示す。ｓｙｓｔｅｍ．ｐｒｏｔｏｃｏｌアセンブリ７０２は、ＩＰｒｏｔｏｃｏｌ  ７０４の基礎として働く。あるいは、言い換えると、ＩＰｒｏｔｏｃｏｌ  ７０４は、アセンブリ７０２から派生する。ＩＰｒｏｔｏｃｏｌ  ７０４は、複数の派生メソッド７０６、７０８、７１６、７１８、７２６、および７２０の基礎として働く。これらのプロトコルのそれぞれは、真上で詳細に説明されている。特筆すべきことに、ＩＲｅｍｏｔｅＭｅｍｂｅｒＩｎｆｏＰｒｏｔｏｃｏｌ  ７０８は、他のプロトコル７１０、７１２、７１４、７２２、および７２４のコレクションの基礎として働く。これは、プロトコルの例示的関係にすぎず、限定的ではなく例示的であることを意図されている。
【００５１】
図７Ａに示されたプロトコルは、型リーケージのルールに違反せずに、リモーティング境界にまたがってパブリックメソッドなどをレートバインディングを介して安全に呼び出す能力を提供する。真のリフレクションは、非常に強力であり、呼出し側が完全に信頼されることを必要とし、リフレクションプロトコルは、必ず、この能力を安全な動作だけに制限し、呼出し側からの特別な許可を必要としない。
【００５２】
図７Ｂを参照する際には、型ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２が、上でリストしたリフレクションプロトコル７４４のシグネチャの多くに存在することに留意することが重要である。リフレクションプロトコル７４４の作成において、リモーティング境界７３８にまたがって未知の型の引数を渡す形が必要である。必要なものは、任意の「プロトコルセーフ」型を表すのに使用できる新しい型である。ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２は、この必要を満足する。
【００５３】
ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２がこのタスクを達成する形は、図７Ｂに示されているように、抽象基底クラスとしてそれ自体を実装することによる。ＭＡＰＭは、ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２の２つの具象実装を含み、その一方は、プロトコル７３４を含むのに使用され、他方は、プリミティブ変換型（ｐｒｉｍｉｔｉｖｅ  ｃｏｎｖｅｒｔｉｂｌｅ  ｔｙｐｅ）７３６を含むのに使用される。したがって、ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２は、全般的なプロトコルルール以上に、リフレクトされるレートバインディングされる呼出しで使用される型を制限する。ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２は、プロトコル７３４または標準の変換型７３６だけを含むことができる。したがって、例えば、すべての数値型、ならびにｓｔｒｉｎｇ、ｂｏｏｌ、ＤａｔｅＴｉｍｅ、ＤＢＮｕｌｌ、およびＥｍｐｔｙが有効である。
【００５４】
特筆すべきことに、ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２は、プロトコルと共に含まれるクラスなので、多少変則的である。プロトコルルールを厳守するために、ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２は、完全にシリアライズ可能でマシン全体の値によってマーシャリングされる型でなければならず、マーシャリングは、データオブジェクトをコンテキストにまたがって、例えば２つのコンポーネントの間で送る時にそのデータオブジェクトを型の間で変換するという概念を必然的に伴う。ＳａｆｅＲｅｍｏｔｅＰａｒａｍ  ７３２は、基底プロトコルと共に含まれることによってこれらの判断基準を満足し、この基底プロトコルも、他のオブジェクトから導出されず、シリアライズ可能であることによって、マシン全体のプラットフォームアセンブリ内にあるものとすることができる。一般に、プロトコルアセンブリにクラスを含めることは、極端に希である。
【００５５】
ＳａｆｅＲｅｍｏｔｅＰａｒａｍ自体は、ＩＣｏｎｖｅｒｔｉｂｌｅ（上を参照されたい）を実装して、その基礎になる型を直接に公開することを可能にし、基礎になる型の別の変換型への強制変換を可能にする。さらに、ＳａｆｅＲｅｍｏｔｅＰａｒａｍは、これらの型の明示的変換オーバーロードをサポートする。
【００５６】
ＳａｆｅＲｅｍｏｔｅＰａｒａｍは、注記したように、それ自体が抽象クラスであり、コンストラクタを含まない。それから導出される実装は、本質的にプライベートでもあり、基底型だけを公開する。したがって、ＳａｆｅＲｅｍｏｔｅＰａｒａｍのインスタンスを作成するためには、開発者は、スタティック作成メソッドのうちの１つを呼び出さなければならない。ＳａｆｅＲｅｍｏｔｅＰａｒａｍのパブリックサーフェスは、次の通りである。
【００５７】
【表８】
2008544398.tif 000010
【００５８】
【表９】
2008544398.tif 000011
【００５９】
【表１０】
2008544398.tif 000012
【００６０】
特筆に値するメソッドは、もちろん、スタティック作成メソッドである。最初の２つは、かなり自己説明的である。
【００６１】
【表１１】
2008544398.tif 000013
【００６２】
ＩＣｏｎｖｅｒｔｉｂｌｅは、渡される値を、ＩＣｏｎｖｅｒｉｂｌｅを実装する型に制限し、その実装は、これを、さらに、そのＧｅｔＴｙｐｅＣｏｄｅメソッドがＴｙｐｅＣｏｄｅ．Ｏｂｊｅｃｔ以外のものを返す型だけに制限する。言い換えると、これらの作成メソッドは、その型がＳｙｓｔｅｍ．ＴｙｐｅＣｏｄｅ列挙で明示的に指定されているプリミティブ型だけに使用されなければならない。ｂｏｏｌ  ｂｙＲｅｆパラメータは、呼び出されるメソッドにＳａｆｅＲｅｍｏｔｅＰａｒａｍがどのように渡されることを（マーシャリングではなく、定義により、値型は値によってマーシャリングされる）意図されているかに関係がある。ｂｙＲｅｆがｔｒｕｅである場合に、値は、２回すなわち、呼び出されるメソッドに入る時とそのメソッドから出る時にマーシャリングされる。
【００６３】
上で述べたリフレクションプロトコルに加えて、本発明のもう１つの態様では、強く型付けされた型および包括的コレクション型が処理される。コレクションプロトコルは、集合的に、プロトコル境界にまたがってコレクションへの参照を表すのに使用される。これらは、コレクションが、オブジェクトのコレクション、収集されたプロトコルによって表されるオブジェクトを表す時、またはコレクションが、他のクライアントによって変更される可能性があり、同期状態に保たれなければならない共有データに対するビューである時に、使用するのに適当である。
【００６４】
ＭＡＰＭのプロトコル態様を述べたが、ＭＡＰＭが、様々なプロトコル用のアダプタを提供することに留意されたい。アダプタは、概して、アセンブリ内に常駐する。ほとんどの場合に、プロトコルアダプタとビューアダプタとの両方が、所与のプロトコルについて提供される。いくつかの場合に、複数のアダプタが提供される。
【００６５】
一態様で、すべてのプロトコルアダプタの基底クラスが提供される。これは、すべてのプロトコル実装を所与のリモート境界にまたがってマーシャリング可能にするのに有益である。この基底クラスは、デフォルト実装を提供することができ、したがって、明示的インターフェース実装を使用して、すべてのプロトコルアダプタの実装パターンをセットする。デフォルトシナリオは、プロトコルをクラス実装からきれいに分離する。デフォルトシナリオは、インターフェース実装を基底クラスに封印し、これは、サブクラスが実装をオーバーライドできないことを意味し、オーバーライドが必要であるか望まれる可能性がある場合には、仮想メソッドが明示的に提供される。
【００６６】
上で述べたプロトコルアダプタと同様に、ビューアダプタの基底クラスがある。例えば、リフレクションプロトコルのビューアダプタに関して、これらの基底クラスは、デフォルトリフレクション実装を提供するために、．ＮＥＴなどのフレームワーク内で拡張される。ＭＡＰＭも、これらのクラスを拡張することができ、同様に、拡張は、基底クラス型として公開される内部実装である。ＭＡＰＭ拡張は、リフレクションプロトコルを利用して、オブジェクトをリフレクトし、オブジェクトをリモートに呼び出す。これらのクラスの主な理由は、未知のオブジェクトへのランタイムのレートバインディングを可能にすることである。呼び出されるオブジェクトは、バージョンにおいて変化する可能性があり、まったく異なるオブジェクトになることができる。唯一の要件は、リフレクトされる型が、バージョンの間で同一の動作を維持し、その結果、以前のバージョンのために記述されたコードが働き続けるようにすることである。さらに、リフレクションアダプタは、純マネージセットの形で現れることができ、この場合に、そのようなアダプタは、リフレクションプロトコルを実装し、実際のリフレクションを使用して、リフレクトされたマネージ型を呼び出す。
【００６７】
もう１つの態様では、オブジェクトがリモーティング境界にまたがってマーシャリングされる時に、そのオブジェクトの寿命が、リース期間の対象であることが観察される。言い換えると、オブジェクトの寿命をリースすることができる。リースが満了する時に、オブジェクトは、ガーベジコレクションに使用可能である。デフォルトで、リースを５分とすることができる。リースは、オブジェクトがリモーティング境界を介してアクセスされるたびに更新することができる。５分以内にアクセスされない場合に、リースは満了し、オブジェクトは収集される。一般的に言って、これは望まれる挙動ではないので、ＭＡＰＭは、オブジェクトに無限のリースを与え、したがって、そうでなければオブジェクトが満了しているはずの時にクライアントが例外を受け取らないようにすることができる。しかし、欠点は、長時間動作するアプリケーションが、絶対に収集されず、その代わりにメモリ例外を引き起こす多数のオブジェクトを作り上げる可能性があることである。
【００６８】
ＭＡＰＭは、任意の所与のリースのスポンサになることによってこの問題をうまく解決する。スポンサとは、満了しようとしているリースを更新する機会をシステムによって与えられるオブジェクトである。スポンサは、リースの対象であるオブジェクトと同一のＡｐｐＤｏｍａｉｎ内に常駐する別々のオブジェクトである。このスポンサオブジェクトは、オブジェクトがリモーティング境界にまたがってマーシャリングされた回数のカウントを維持する。
【００６９】
例示的な分散コンピューティングフレームワークまたは分散コンピューティングアーキテクチャ
様々な分散コンピューティングフレームワークが、パーソナルコンピューティングおよびインターネットの集中を考慮に入れて、過去に開発され、また、開発されつつある。個人およびビジネスユーザは、同様に、コンピューティングアクティビティをますますウェブブラウザ指向またはネットワーク指向にする、アプリケーションおよびコンピューティングデバイス用のシームレスにインターオペラブルでウェブ対応のインターフェースを与えられている。
【００７０】
例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）のマネージコードプラットフォームすなわち．ＮＥＴは、サーバと、ウェブベースのデータストレージおよびダウンロード可能デバイスソフトウェアなどのビルディングブロックサービスとを含む。一般的に言って、．ＮＥＴプラットフォームは、（１）すべての範囲のコンピューティングデバイスが一緒に働くようにし、それらのすべてでユーザ情報を自動的に更新させ同期化させる能力と、（２）ＨＴＭＬではなくＸＭＬのより多くの使用によって可能にされる、ウェブページに関する高められた対話型能力と、（３）例えば電子メールなどの様々なアプリケーションまたはＯｆｆｉｃｅ  ．ＮＥＴなどのソフトウェアの管理のための中央開始点からユーザへの製品およびサービスのカスタマイズされたアクセスおよび配送を特徴とするオンラインサービスと、（４）情報へのアクセスの効率およびたやすさならびにユーザおよびデバイスの間の情報の同期化を高める、集中データストレージと、（５）電子メール、ファクシミリ、および電話機など、様々な通信媒体を統合する能力と、（６）開発者のための、再利用可能モジュールを作成し、これによって生産性を高め、プログラミングエラーの個数を減らす能力と、（７）多数の他のクロスプラットフォーム特徴および言語統合特徴とを提供する。
【００７１】
実際に、図８に示されているように、上で前のセクションで述べた管理された自動プログラミングモデル（ＭＡＰＭ）は、このセクションで述べる．ＮＥＴフレームワークの上にある。具体的に言うと、．ＮＥＴフレームワーク８０４が、フレームワーク８０４の上のＭＡＰＭ  ８０２と共に示されている。しかし、複数のＭＡＰＭが、．ＮＥＴフレームワークと相互作用することができる。
【００７２】
本明細書では、いくつかの例示的態様を、コンピューティングデバイスに常駐するアプリケーションプログラミングインターフェース（ＡＰＩ）などのソフトウェアに関して説明したが、本発明による無線トラフィックを調整する方法が、．ＮＥＴコードなどのマネージコードによって使用可能にされる言語およびサービスのすべてに、および他の分散コンピューティングフレームワークも、含まれ、サポートされ、またはそれらを介してアクセスされることが可能になるように、本発明の１つまたは複数の部分を、オペレーティングシステムまたは「ミドルマン」オブジェクト、制御オブジェクト、ハードウェア、ファームウェア、中間言語の命令またはオブジェクトなどを介して実装することもできる。
【００７３】
例示的なネットワーク化された環境および分散環境
当業者は、本発明を、コンピュータネットワークの一部としてまたは分散コンピューティング環境内で展開できる、任意のコンピュータまたは他のクライアントデバイスもしくはサーバデバイスに関して実施できることを了解することができる。これに関して、本発明は、任意の個数のメモリまたはストレージユニットと、任意の個数のストレージユニットまたはボリュームにまたがって発生する任意の個数のアプリケーションおよびプロセスに関係し、これらのアプリケーションおよびプロセスは、本発明に従って無線トラフィックを調整するプロセスと共に使用することができる。本発明は、リモートストレージまたはローカルストレージを有する、ネットワーク環境または分散コンピューティング環境内で展開されたサーバコンピュータおよびクライアントコンピュータを伴う環境に適用することができる。本発明は、リモートまたはローカルのサービスおよびプロセスに関して情報を生成し、受信し、送信する、プログラミング言語機能性、解釈機能、および実行機能を有する独立型コンピューティングデバイスにも適用することができる。アプリケーションデータ、ウェブサービス、ＶｏＩＰアプリケーション、音楽プレイヤなどは、異種デバイスにまたがって潜在的に無線の形であちこちに送信されなければならない大量のデータを生成し、したがって、本発明による無線トラフィックを調整する技法は、これらの環境で高い効率を伴って適用することができる。
【００７４】
分散コンピューティングは、コンピューティングデバイスとシステムとの間の交換によるコンピュータリソースおよびサービスの共有を提供する。これらのリソースおよびサービスには、情報の交換、キャッシュストレージ、ファイルなどのオブジェクトのディスクストレージが含まれる。分散コンピューティングは、ネットワーク接続性を利用し、クライアントが企業全体に利益をもたらすためにその集合的な威力を活用することを可能にする。これに関して、様々なデバイスは、本発明による無線トラフィックを調整するシステムおよび方法を包含することができるアプリケーション、オブジェクト、またはリソースを有することができる。
【００７５】
図９に、例示的なネットワーク化されたコンピューティング環境すなわち分散コンピューティング環境の概略図を示す。この分散コンピューティング環境は、オブジェクト１０ａ、１０ｂなどと、コンピューティングオブジェクトまたはデバイス１１０ａ、１１０ｂ、１１０ｃとを含む。これらのオブジェクトは、プログラム、メソッド、データストア、プログラマブルロジックなどを含むことができる。オブジェクトは、ＰＤＡ、オーディオ／ビデオデバイス、ＭＰ３プレイヤ、パーソナルコンピュータなどの同一のまたは異なるデバイスの諸部分を含むことができる。各オブジェクトは、通信ネットワーク１４によって別のオブジェクトと通信することができる。このネットワーク自体は、図９のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティングデバイスを含むことができ、複数の相互接続されたネットワークを表すことができる。本発明の態様によれば、各オブジェクト１０ａ、１０ｂなどまたは１１０ａ、１１０ｂ、１１０ｃなどは、ＡＰＩを利用することができるアプリケーション、あるいは、本発明による無線トラフィックを調整するシステムおよび方法と共に使用するのに適する他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを含むことができる。
【００７６】
１１０ｃなどのオブジェクトを、別のコンピューティングデバイス１０ａ、１０ｂなどまたは１１０ａ、１１０ｂなどでホスティングできることも了解することができる。したがって、図示の物理的環境は、接続されたデバイスをコンピュータとして示すことができるが、そのような図示は、単に例示であり、物理的環境を、その代わりに、ＰＤＡ、テレビジョン、ＭＰ３プレイヤなどの様々なデジタルデバイス、インターフェース、ＣＯＭオブジェクトなどのソフトウェアオブジェクト、および類似物を含んで図示し、または説明することができる。
【００７７】
分散コンピューティング環境をサポートする様々なシステム、コンポーネント、およびネットワーク構成がある。例えば、コンピューティングシステムを、有線システムまたは無線システムによって、ローカルネットワークまたは広範囲に分散されたネットワークによって一緒に接続することができる。現在、ネットワークの多くは、インターネットに結合され、インターネットは、広範囲に分散されたコンピューティングのインフラストラクチャを提供し、多数の異なるネットワークを含む。インフラストラクチャのどれであっても、本発明による無線トラフィックの調整に付随するようにされる例示的通信に使用することができる。
【００７８】
ホームネットワーキング環境には、電力線、データ（無線と有線との両方）、音声（例えば電話）、およびエンターテイメントメディアなどの独自のプロトコルをそれぞれがサポートすることができる少なくとも４つの異なるネットワークトランスポートメディアがある。照明スイッチおよび照明器具などのホームコントロールデバイスのほとんどは、接続性に電力線を使用することができる。データサービスは、ブロードバンド（例えば、ＤＳＬモデムまたはケーブルモデムのいずれか）として家庭に入ることができ、家庭内で無線接続性（例えば、ＨｏｍｅＲＦまたは８０２．１１Ｂ）または有線接続性（例えば、Ｈｏｍｅ  ＰＮＡ、Ｃａｔ  ５、イーサネット（登録商標）、さらには電力線）のいずれかを使用してアクセス可能である。音声トラフィックは、有線（例えば、Ｃａｔ  ３）または無線（例えば、携帯電話）のいずれかとして家庭に入ることができ、家庭内でＣａｔ  ３配線を使用して配布することができる。エンターテイメントメディアまたは他のグラフィカルデータは、衛星またはケーブルのいずれかを介して家庭に入ることができ、通常は、家庭内で同軸ケーブルを使用して配布される。ＩＥＥＥ  １３９４およびＤＶＩも、メディアデバイスのクラスタのデジタル相互接続である。これらのネットワーク環境およびプロトコル標準規格として現れる可能性があるか既に現れている他の環境のすべてを、インターネットなどの広域ネットワークによって外部の世界に接続することができるイントラネットなどのネットワークを形成するように相互接続することができる。短く言うと、データの格納および伝送のための様々な異なるソースが存在し、その結果、前に進むと、コンピューティングデバイスは、本発明に従ってトラフィックを調整する、プログラムオブジェクトに付随するアクセスされまたは利用されるデータなどのデータを共有する形を必要とする。
【００７９】
インターネットは、一般に、コンピュータネットワーキングの技術で周知の、転送制御プロトコル／インターフェースプログラム（ＴＣＰ／ＩＰ）プロトコルスイートを使用するネットワークおよびゲートウェイの集合を指す。インターネットは、ユーザがネットワークを介して対話でき、情報を共有できるようにする、ネットワーキングプロトコルを実行するコンピュータによって相互接続された、地理的に分散したリモートコンピュータネットワークのシステムとして説明することができる。そのような広範囲に広がった情報共有のゆえに、インターネットなどのリモートネットワークは、これまで、全般的に、開発者が、本質的に制限なしで特殊化された動作またはサービスを実行するソフトウェアアプリケーションを設計することができるオープンシステムに進化してきた。
【００８０】
したがって、ネットワークインフラストラクチャは、クライアント／サーバアーキテクチャ、ピアツーピアアーキテクチャ、またはハイブリッドアーキテクチャなどのネットワークトポロジのホストを可能にする。「クライアント」は、それが関係しない別のクラスまたはグループのサービスを使用する、あるクラスまたはグループのメンバである。したがって、コンピューティングにおいて、クライアントは、別のプログラムによって提供されるサービスを要求するプロセスすなわち、おおまかには命令の組またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体に関する動作の詳細を一切「知る」必要なしに、要求されたサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワーク化されたシステムにおいて、クライアントは、通常は、例えばサーバなどの別のコンピュータによって提供される共有ネットワークリソースにアクセスするコンピュータである。図９の図では、例として、コンピュータ１１０ａ、１１０ｂなどをクライアントと考えることができ、コンピュータ１０ａ、１０ｂなどをサーバと考えることができ、ここで、サーバ１０ａ、１０ｂなどは、データを維持し、このデータは、クライアントコンピュータ１１０ａ、１１０ｂなどに複製されるが、任意のコンピュータを、状況に応じてクライアント、サーバ、またはその両方と考えることができる。これらのコンピューティングデバイスのいずれもが、データを処理しているか、サービスまたはタスクを要求している可能性があり、これに、本発明による無線トラフィックの調整が含まれる可能性がある。
【００８１】
サーバは、通常は、インターネットなどのリモートネットワークまたはローカルネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは、第１のコンピュータシステム内でアクティブとすることができ、サーバプロセスは、第２のコンピュータシステム内でアクティブとすることができ、これらが通信媒体を介して互いに通信し、したがって、分散機能性がもたらされ、複数のクライアントがサーバの情報収集機能を利用できるようになる。本発明による無線トラフィックの調整の技法に従って利用される任意のソフトウェアオブジェクトを、複数のコンピューティングデバイスまたはオブジェクトにまたがって分散させることができる。
【００８２】
クライアントおよびサーバは、プロトコルレイヤによって提供される機能性を使用して互いに通信する。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）または「ウェブ」と共に使用される一般的なプロトコルである。通常、インターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレスまたはＵｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）などの他の参照を、サーバコンピュータまたはクライアントコンピュータがお互いを識別するのに使用することができる。ネットワークアドレスを、ＵＲＬアドレスと呼ぶことができる。通信を、通信媒体を介して提供することができ、例えば、クライアントおよびサーバを、大容量通信のためのＴＣＰ／ＩＰ接続を介して互いに結合することができる。
【００８３】
したがって、図９に、サーバがネットワーク／バスを介してクライアントコンピュータと通信する、本発明を使用することができる、例示的なネットワーク化された環境または分散環境が示されている。より詳細に言うと、本発明に従って、複数のサーバ１０ａ、１０ｂなどが、ＬＡＮ、ＷＡＮ、イントラネット、インターネットなどとすることができる通信ネットワーク／バス１４を介して、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク化された機器などの複数のクライアントコンピューティングデバイスまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなど、またはＶＣＲ、ＴＶ、オーブン、照明、ヒータ、および類似物などの他のデバイスに相互接続される。したがって、本発明を、それに関してＶｏＩＰデータを含む無線トラフィックを効率的に配送することが望ましい、あらゆるコンピューティングデバイスに適用することができることが企図されている。
【００８４】
通信ネットワーク／バス１４がインターネットであるネットワーク環境では、例えば、サーバ１０ａ、１０ｂなどを、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどがＨＴＴＰなどの複数の既知のプロトコルのいずれかを介して通信するウェブサーバとすることができる。サーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどとして働くこともでき、これは、分散コンピューティング環境の特性とすることができる。
【００８５】
上で述べたように、通信は、適当な場合に、有線または無線あるいはその組合せとすることができる。クライアントデバイス１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどは、通信ネットワーク／バス１４を介して通信してもしなくてもよく、独立の通信を関連付けられることができる。例えば、ＴＶまたはＶＣＲの場合に、その制御に対するネットワーク化された態様がある場合もそうでない場合もある。各クライアントコンピュータ１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどおよびサーバコンピュータ１０ａ、１０ｂなどは、様々なアプリケーションプログラムモジュールまたはオブジェクト１３５ａ、１３５ｂ、１３５ｃなどを備えることができ、様々なタイプのストレージ要素またはオブジェクトへの接続またはアクセスを備えることができ、このストレージ要素またはオブジェクトを介して、ファイルまたはデータストリームを格納することができ、あるいは、このストレージ要素またはオブジェクトにファイルまたはデータストレージの一部をダウンロードし、送信し、または移植することができる。コンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂなどのいずれか１つまたは複数を、本発明に従って処理されまたは保存されるデータを格納するデータベースまたはメモリ２０など、データベース２０または他のストレージ要素の維持および更新の責任を負うものとすることができる。したがって、本発明を、コンピュータネットワーク／バス１４にアクセスし、これと相互作用することができるクライアントコンピュータ１１０ａ、１１０ｂなどと、クライアントコンピュータ１１０ａ、１１０ｂなどおよび他の類似するデバイスと相互作用することができるサーバコンピュータ１０ａ、１０ｂなどと、データベース２０とを有するコンピュータネットワーク環境で利用することができる。
【００８６】
例示的なコンピューティングデバイス
図１０および次の議論は、それに関連して本発明を実施できる適切なコンピューティング環境の短い全般的な説明を提供することを意図されたものである。しかし、すべての種類のハンドヘルドデバイス、ポータブルデバイス、および他のコンピューティングデバイスならびにコンピューティングオブジェクトが、本発明に関連する使用についてすなわち、コンピューティング環境内で柔軟にまたはすばやくデータを処理することが望ましいすべての場合について企図されていることを理解されたい。汎用コンピュータを下で説明するが、これは、１つの例にすぎず、本発明は、ネットワーク／バスとのインターオペラビリティおよび相互作用を有するシンクライアントと共に実施することができる。したがって、本発明を、非常に少ないまたは最小限のクライアントリソースを包含するネットワーク化されたホスティングされるサービスの環境で、例えばクライアントデバイスが単に機器内に配置されたオブジェクトなどのネットワーク／バスへのインターフェースとして働くネットワーク化された環境で実施することができる。本質的に、データを格納できるか、そこからデータを取り出せるか別のコンピュータに送信できるすべての場所が、本発明によるアルゴリズム要素をコプロセッサにダウンロードする技法の動作の望ましい環境または適切な環境である。
【００８７】
必要ではないが、本発明を、デバイスまたはオブジェクト用のサービスの開発者によって使用されるオペレーティングシステムを介して実施し、かつ／または本発明による無線トラフィックを調整する方法に関連して動作するアプリケーションソフトウェアに含めることができる。ソフトウェアは、クライアントワークステーション、サーバ、もしくは他のデバイスなどの１つもしくは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、および類似物を含む。通常、プログラムモジュールの機能性は、様々な実施形態で望み通りに組み合わせ、または分散させることができる。さらに、当業者は、他のコンピュータシステム構成およびプロトコルを用いて本発明を実践できることを了解するであろう。本発明と共に使用するのに適切とすることのできる他の周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成は、パーソナルコンピュータ（ＰＣ）、自動預金払戻機、サーバコンピュータ、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル消費者電子製品、ネットワークＰＣ、アプライアンス、照明、環境制御要素、ミニコンピュータ、メインフレームコンピュータ、および類似物を含むが、これに限定はされない。本発明は、通信ネットワーク／バスまたは他のデータ伝送媒体を介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。上で説明したように、分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体との両方に配置することができ、クライアントノードは、サーバノードとして働くことができる。
【００８８】
したがって、図１０に、本発明を実施することができる適切なコンピューティングシステム環境１００の例を示すが、上で明らかにしたように、コンピューティングシステム環境１００は、適切なコンピューティング環境の１つの例にすぎず、本発明の使用または機能性の範囲に関する限定を提案することを意図されたものではない。コンピューティング環境１００を、例示的なオペレーティング環境１００に示されたコンポーネントのいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。
【００８９】
図１０を参照すると、本発明を実施する例示的なシステムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントは、処理ユニット１２０と、システムメモリ１３０と、システムメモリを含む様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含むが、これらに限定はされない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および／または様々なバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。制限ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス（メザニンバスとも称する）が含まれる。
【００９０】
コンピュータ１１０には、通常は、様々なコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体は、コンピュータ１１０によってアクセスすることができるすべての使用可能な媒体とすることができ、コンピュータ可読記憶媒体には、揮発性媒体および不揮発性媒体と、取外し可能媒体および取外し不能媒体の両方が含まれる。制限ではなく例として、コンピュータ可読記憶媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶する任意の方法またはテクノロジで実施される、揮発性および不揮発性の両方の、取外し可能媒体および取外し不能媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を格納するのに使用することができ、コンピュータ１１０によってアクセスすることができるすべての他の媒体が含まれるが、これに限定はされない。通信媒体は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実施し、通信媒体は、すべての情報配信媒体を含む。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含む。上記のいずれかの組合せも、コンピュータ可読記憶媒体の範囲に含まれなければならない。
【００９１】
システムメモリ１３０には、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性のメモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１１０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２には、通常は、即座にアクセス可能であるおよび／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図１０に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が図示されている。
【００９２】
コンピュータ１１０には、他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶媒体を含めることもできる。例としてのみ、図１０に、取外し不能不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１４１、取外し可能不揮発性磁気ディスク１５２から読み取るかこれに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭまたは他の光学媒体などの取外し可能不揮発性光ディスク１５６から読み取るかこれに書き込む光学ディスクドライブ１５５が図示されている。この例示的オペレーティング環境で使用することができる他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定はされない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの取外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光学ディスクドライブ１５５は、通常は、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００９３】
上で述べ、図１０に図示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１１０のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供する。図１０では、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一または異なるもののいずれかとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、最低限でもこれらを異なるコピーとすることができることを示すために、本明細書では異なる符号を与えられている。ユーザは、キーボード１６２および通常はマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、システムバス１２１に結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ（ＵＳＢ）などの、他のインターフェースおよびバス構造によって接続されることが可能である。ノースブリッジなどのグラフィックインターフェース１８２をも、システムバス１２１に接続することができる。ノースブリッジは、ＣＰＵまたはホスト処理ユニット１２０と通信するチップセットであり、ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ（ＡＧＰ）通信の責任を負う。グラフィック処理ユニット（ＧＰＵ）１８４などの１つまたは複数のコプロセッサが、グラフィックインターフェース１８２と通信することができる。これに関して、ＧＰＵ  １８４は、一般に、レジスタストレージなどのオンチップメモリストレージを含み、ＧＰＵ  １８４は、ビデオメモリ１８６と通信し、ここで、本発明のコプロセッサにアルゴリズム要素をダウンロードする方法が、特定の影響を有する。しかし、ＧＰＵ  １８４は、コプロセッサの１つの例にすぎず、したがって、様々なコプロセッシングデバイスを、コンピュータ１１０に含めることができ、これらのコプロセッシングデバイスは、ピクセルシェーダおよび頂点シェーダなどの様々な手続シェーダを含むことができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続され、このビデオインターフェース１９０は、ビデオメモリ１８６と通信することができる。モニタ１９１の他に、コンピュータに、スピーカ１９７およびプリンタ１９６など、出力周辺インタ���フェース１９５を介して接続することができる他の周辺出力デバイスをも含めることができる。
【００９４】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境または分散環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ１１０に関して上で説明した要素の多数またはすべてを含むが、図１０にはメモリストレージデバイス１８１だけが図示されている。図１０に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワーク／バスを含めることもできる。そのようなネットワーキング環境は、家庭、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【００９５】
ＬＡＮネットワーキング環境で使用される場合に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合に、コンピュータ１１０には、通常は、インターネットなどのＷＡＮ１７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデムなどのデータ通信デバイス１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその諸部分を、リモートメモリストレージデバイスに格納することができる。制限ではなく例として、図１０に、メモリデバイス１８１に常駐するものとしてリモートアプリケーションプログラム１８５を示す。図示のネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用することができることを了解されたい。
【００９６】
本発明を、様々な図面に示された好ましい態様に関して説明してきたが、本発明から逸脱せずに、他の類似する態様を使用することができ、あるいは、本発明と同一の機能を実行するために、説明された態様に対して変更および追加を行うことができることを理解されたい。例えば、本発明の一態様で、少なくともバージョニング、分離、およびレートバインディングを可能にする管理された自動プログラミングモデルを述べた。しかし、これらの説明された態様と同等の他のシステムおよび方法も、本明細書の教示によって予期される。したがって、本発明は、どの単一の態様にも限定されてはならず、添付の特許請求の範囲に従う広がりおよび範囲において理解されたい。
【図面の簡単な説明】
【００９７】
【図１】管理された自動プログラミングモデル（ＭＡＰＭ）内のプロトコルと、そのプロトコルが複数の独立にバージョニングするコンポーネントの間の通信にどのように使用されるかを示す図である。
【図２】アダプタがそのめいめいのコンポーネントおよびプロトコルの中間にある場合のアダプタを示す図である。
【図３】本発明の一態様で使用できる異なるタイプのアダプタのうちのいくつかを示す図である。
【図４】コンポーネント、ビューアダプタ、プロトコルアダプタ、およびプロトコルのすべてが相互作用する、本発明のもう１つの態様を示す図である。
【図５】プロトコルを介して通信する２つの通常のコンポーネントの分離を示す図である。
【図６Ａ】ＭＡＰＭと、ＭＡＰＭがコンポーネントの動的バインディングをどのように可能にするかを示す図である。
【図６Ｂ】ＭＡＰＭのプロトコルアーキテクチャの詳細な調査を示す図である。
【図６Ｃ】コンポーネントによる型の可視性および不可視性を示す図である。
【図７Ａ】本発明の一態様でのプロトコル間の階層関係を示す図である。
【図７Ｂ】ＭＡＰＭがリフレクションをどのように管理するかを示す図である。
【図８】ＭＡＰＭがその上にある．ＮＥＴフレームワークを示す図である。
【図９】例示的なネットワーク化されたコンピューティング環境すなわち分散コンピューティング環境を示す概略図である。
【図１０】それに関連して本発明を実施できる適切なコンピューティング環境の短い全般的な説明を示す図である。
【図１】
2008544398.tif 000014
【図２】
2008544398.tif 000015
【図３】
2008544398.tif 000016
【図４】
2008544398.tif 000017
【図５】
2008544398.tif 000018
【図６Ａ】
2008544398.tif 000019
【図６Ｂ】
2008544398.tif 000020
【図６Ｃ】
2008544398.tif 000021
【図７Ａ】
2008544398.tif 000022
【図７Ｂ】
2008544398.tif 000023
【図８】
2008544398.tif 000024
【図９】
2008544398.tif 000025
【図１０】
2008544398.tif 000026
【国際調査報告】
2008544398.tif 000027