JP2009501385A - ノード間通信パイプライン - Google Patents

Abstract

ノード間通信パイプラインは、動的に入力されるモジュール特有のパラメータに従ってプロトコルにわたって構成され組み立てられるコードモジュールを含むことができる。モジュールが登録されているサービスへパラメータを入力することができ、１つまたは複数の適切なパイプラインを動的に組み立てることができる。

Description

本発明は、ノード間通信パイプラインに関する。

アプリケーション、プログラム、機能、およびプログラム可能で実行可能なコードのその他の集合は、モジュール化することができる。すなわち、上述の集合に関連付けられているコードは、コードモジュールへと分けることができ、これらのコードモジュールは、別々のメンバーが別々の時点で独立して作成したり、作成し直したり（すなわち、新たなバージョンを生成したり）することができる。そのようなコードモジュールの例としては、「アドイン」が含まれ、このアドインは、ランタイムにエンドユーザによってアプリケーションに追加することができる。

ランタイムに、そのようなコードモジュール同士は、相互関係を有するようになることができ、あるいはそのような相互関係は、その他の形で明らかになることもできる。しかしランタイムは、コードモジュール同士の間にバージョニング（ｖｅｒｓｉｏｎｉｎｇ）および／または互換性の問題が存在するということも明らかにするかもしれない。「バージョニング」の問題とは、上述の生成され追加されるアプリケーション、プログラム、機能、およびプログラム可能で実行可能なコードのその他の集合の１つまたは複数の部分に対して行われる変更を指すことができる。そして、互換性の問題は、それらのいかなる部分における微妙な変更にさえ起因して生じるおそれがある。

動的なノード間通信パイプラインについて、本明細書において説明する。

より詳細には、本明細書に記載されている例示的な実施形態は、動的に入力されるモジュール特有のパラメータに従って構成して組み立てることができるコードモジュールを含むノード間通信パイプラインに関する。モジュールが登録されているサービスへパラメータを入力することができ、１つまたは複数の適切なパイプラインを動的に組み立てることができる。

次いで、動的なノード間通信パイプラインについて、添付の図に従って説明する。

動的なピアツーピア通信パイプラインについて、本明細書において説明する。

より詳細には、動的なノード間通信パイプラインは、本明細書において説明される際には、指定された順序で変更可能に組み立てることができる固定ステージ（ｆｉｘｅｄ ｓｔａｇｅ）のノード間パイプラインに関連することができる。さらに、動的なノード間通信パイプラインは、ネットワーク環境内の１つまたは複数のデバイスまたはノード内に実装することができ、ノードの構成は、ピアツーピアの構成やホスト対クライアントの構成を含むことができる。

「パイプライン」は、本明細書において説明される際には、少なくとも１つまたは複数のノード・アプリケーション・プログラミング・インターフェース（以降では「ＡＰＩ」と呼ぶ）と、１つまたは複数のアダプタと、少なくとも１つのプロトコルとを含むことができる。このようなパイプラインは、上述のＡＰＩと、アダプタと、プロトコルとを様々な数量および組合せで含むことができ、また、必ずしも上述のパイプライン要素のすべてを含む必要はない。

「ＡＰＩ」は、本明細書において説明される際には、プロシージャーの実行を指示するために、アプリケーション、プログラム、機能、およびプログラム可能で実行可能なコードのその他の集合によって使用され、したがってオペレーティングシステムやランタイム実行環境などの対応する実行環境によって使用されるルーチンのセットを指すことができる。「アダプタ」は、本明細書において説明される際には、１つのＡＰＩを別のＡＰＩへ通信可能に適合させることができるモジュールまたはオブジェクトを指すことができ、シリアルに、またはプロトコルを介してリンクすることができる。「プロトコル」は、本明細書において説明される際には、オブジェクトが、それを介して通信できる規格や規約を指すことができる（ＡＰＩが、それらのオブジェクトの唯一の例ではない）。

したがって「パイプライン」は、本明細書において説明される際には、ホストＡＰＩアダプタからプロトコルを介してアドインＡＰＩアダプタへ流れて、それによって第１のノードアプリケーション（例えば、ホストアプリケーション）を第２のノードアプリケーション（例えば、アドインアプリケーション）に接続するコードモジュールやオブジェクトの連鎖をさらに指すことができる。

図１は、動的なノード間通信パイプラインの例示的なテクノロジーを実装することができる例示的なネットワーク環境１００を示しているが、動的なノード間通信パイプラインは、ネットワーク環境に限定されない。図１においては、クライアントデバイス１０５、サーバデバイス１１０、および「その他の」デバイス１１５が、ネットワーク１２５を介してお互いへ通信可能に結合することができ、またさらに、クライアントデバイス１０５、サーバデバイス１１０、および「その他の」デバイス１１５のうちの少なくとも１つは、本明細書に記載されているように、動的なピアツーピア通信パイプライン１２０を実装することができる。

クライアントデバイス１０５は、デスクトップＰＣ（personal computer）、ワークステーション、メインフレームコンピュータ、インターネット機器、セットトップボックス、およびゲーム機など、様々な従来のコンピューティングデバイスのうちの少なくとも１つに相当することができる。クライアントデバイス１０５は、モバイル（すなわち携帯）電話、ＰＤＡ（personal digital assistant）、ラップトップコンピュータなどを含む、有線および／または無線のリンクによってネットワーク１２５に関連付けることができる任意のデバイスのうちの少なくとも１つにさらに相当することができる。さらにまた、クライアントデバイス１０５は、様々な数量および／または組合せの上述のクライアントデバイスに相当することができる。「その他の」デバイス１１５は、クライアントデバイス１０５の上述の例のうちのいずれかによって具体化することもできる。

サーバデバイス１１０は、動的なノード間通信パイプライン１２０の少なくとも１つの実装に従って、様々なデータおよび／または機能のうちの任意のものをクライアントデバイス１０５や「その他の」デバイス１１５に提供することができる任意のデバイスに相当することができる。それらのデータは、公に利用可能とすることもでき、または別の方法としては、制限すること、例えば特定のユーザのみに、あるいは適切な会費やライセンス料金が支払われている場合のみに制限することもできる。サーバデバイス１１０は、ネットワークサーバ、アプリケーションサーバ、ブレードサーバ、またはそれらの任意の組合せのうちの少なくとも１つとすることができる。通常、サーバデバイス１１０は、コンテンツの提供元になることができる任意のデバイスに相当することができ、クライアントデバイス１０５は、ネットワーク１２５を介して、またはオフライン方式で、そのようなコンテンツを受信することができる任意のデバイスに相当することができる。しかし、本明細書に記載される例示的な実施形態によれば、クライアントデバイス１０５およびサーバデバイス１１０は、ネットワーク環境１００内において送信側ノードまたは受信側ノードに交換可能になることができる。「その他の」デバイス１１５は、サーバデバイス１１０の上述の例のうちのいずれかによって具体化することもできる。

「その他の」デバイス１１５は、本明細書に記載される例のうちの１つまたは複数に従って動的なノード間通信パイプライン１２０を実装することができる任意のさらなるデバイスに相当することができる。すなわち、「その他の」デバイス１１５は、少なくともマネージド実行環境内におけるアプリケーション、プログラム、機能、あるいはプログラム可能で実行可能なコードのその他の集合に関するモジュール初期化を実装することができる任意のソフトウェア対応型のコンピューティングデバイスや処理デバイスに相当することができる。したがって、「その他の」デバイス１１５は、オペレーティングシステム、インタープリタ、コンバータ、コンパイラ、またはそれらに実装されたランタイム実行環境のうちの少なくとも１つを有するコンピューティングデバイスや処理デバイスとすることができる。これらの例は、いかなる形であれ限定することを意図するものではなく、したがって、そのように解釈されるべきではない。

ネットワーク１２５は、有線ネットワークおよび／または無線ネットワークを含むことができる様々な従来のネットワークトポロジーおよびタイプのうちのいずれかに相当することができる。ネットワーク１２５は、公開されているプロトコルおよび／または独自のプロトコルを含む様々な従来のネットワークプロトコルのうちのいずれかをさらに利用することができる。ネットワーク１２５は、例えばインターネット、ならびに８０２．１１システムなどの１つまたは複数のローカルエリアネットワーク（個々には「ＬＡＮ」とも呼ばれる）の少なくとも一部、またはより大きな規模ではワイドエリアネットワーク（すなわち「ＷＡＮ」）、あるいはＢｌｕｅｔｏｏｔｈなどのパーソナルエリアネットワーク（すなわちＰＡＮ）を含むことができる。

デバイス１０５、１１０、および１１５のうちの少なくとも１つにおけるコンピュータアーキテクチャは通常、ハードウェアおよびソフトウェアの点で確定したコンピューティングプラットフォームになっている。コンピューティングデバイス用のソフトウェアは、機能に基づいてグループに分類されており、それらのグループとしては、ハードウェア抽象層（ｈａｒｄｗａｒｅ ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ）（「ＨＡＬ」と別称されている）、オペレーティングシステム（「ＯＳ」と別称されている）、およびアプリケーションを含むことができる。

ランタイム実行環境は、ＯＳとアプリケーションとの間における隔離されたスペースを指すことができ、このスペース内において、アプリケーションは、処理デバイス１０５、１１０、または１１５のうちの少なくとも１つの上で特定のタスクを実行することができる。より詳細には、ランタイム実行環境は、サーバ、デスクトップコンピュータ、ラップトップコンピュータ、およびモバイル処理デバイスなど、ますます広範囲になっている処理デバイス１０５、１１０、および１０５上でアプリケーションを実行する際の信頼性を、そのような処理デバイス上で実行されるアプリケーションのための抽象層およびサービス層を提供することによって、ならびにメモリの管理およびその構成を含む機能をそのアプリケーションにさらに提供することによって、高めることができる。

ランタイム実行環境は、アプリケーション・プログラミング・プラットフォームおよびアプリケーション実行プラットフォームのうちの少なくとも１つとして機能することができる。アプリケーション・プログラミング・プラットフォームとしては、ランタイム実行環境は、複数のコンピューティング言語のうちの１つで書かれている可能性のある対象のアプリケーションを、中間言語（以降では「ＩＬ」と呼ぶ）へとコンパイルすることができる。ＩＬは通常、プラットフォームから独立しており、中央処理装置（以降では「ＣＰＵ」と呼ぶ）が、ＩＬを実行する。実際に、ＩＬは、多くのＣＰＵマシン語よりも高水準の言語である。アプリケーション実行プラットフォームとしては、ランタイム実行環境は、コンパイルされたＩＬをネイティブな機械命令へと解釈することができる。ランタイム実行環境は、インタープリタまたはコンパイラ（例えば「ジャストインタイム」（別称「ＪＩＴ」）のコンパイラ）のいずれかを利用して、そのような命令を実行することができる。いずれにしろ、ネイティブな機械命令は、次いでＣＰＵによって直接実行されることができる。ＩＬは、ＣＰＵから独立しているため、ＣＰＵプラットフォーム上で実行されているＯＳが適切なランタイム実行環境をホストしている限り、いかなるＣＰＵプラットフォーム上でも実行することができる。動的なノード間通信パイプライン１２０の実装が関連することができるランタイム環境の例としては、Ｖｉｓｕａｌ Ｂａｓｉｃランタイム環境、例えばＪａｖａ（登録商標）ルーチンを実行するために使用されるＪａｖａ（登録商標）Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅランタイム環境、または呼び出しルーチンを実行する前に例えばＭｉｃｒｏｓｏｆｔ．ＮＥＴ（商標）アプリケーションをマシン語へとコンパイルするためのＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）が含まれる。しかし、ランタイム環境をこうして列挙したのは、例を提供しているにすぎない。例示的な実施形態は、これらのマネージドの実行環境だけに限らない。より詳細には、例示的な実施形態がマネージドの実行環境だけに限らないのは、１つまたは複数の例をテスト環境および／またはアンマネージドの実行環境内に実装することができるためである。

ＩＬへとコンパイルされたアプリケーションを「マネージドのコード」と呼ぶことができ、これが、ランタイム実行環境を「マネージドの実行環境」と別称することができるゆえんである。ランタイム実行環境を利用しないで実行されるコードをネイティブなコードアプリケーションと呼ぶことができるという点に留意されたい。

少なくとも１つのマネージドの実行環境内においては、プロセスのための隔離の単位すなわち「隔離構造（ｉｓｏｌａｔｉｏｎ ｃｏｎｓｔｒｕｃｔ）」をアプリケーションドメインと呼ぶことができる。このような用語は、一例として提供されているにすぎない。すなわち、本明細書に記載されている例示的な実施形態は、アプリケーションドメインに、あるいは上述のようなマネージドの実行環境にさえ限定されるものではなく、様々な実行環境内における様々なその他の隔離構造の実施形態に適用することができる。

隔離構造（例えば、アプリケーションドメイン）は、内部で実行されるコードを指定のソースからロードできるようにすることができ、隔離構造は、その他のそのような隔離構造から独立して途中停止することができ、また隔離構造内での処理は、内部で生じる障害がプロセス内のその他の隔離構造に影響を及ぼさないように隔離することができる。すなわち、隔離構造内での処理の影響は、プロセス全体が永続的なものにされるまで、同時に実行されている構造からは見えない。整合性のために、以降の論考は、「アプリケーション」および「プロセス」に言及する可能性があるが、これらは双方とも、少なくともソフトウェアプログラムおよびアプリケーションのうちのいずれか１つを単独でまたは組み合わせて含むことができる。

図２は、動的なノード間通信パイプライン１２０の例（図１を参照されたい）、とりわけプロトコル間での動的なノード間通信パイプラインを実装することができるランタイム実行環境２００の一例を示している。

少なくとも１つの例示的な実施形態によれば、ランタイム実行環境２００は、コンピューティング・デバイス・プラットフォームのためのマネージドのコードの実行を容易にすることができる。マネージドのコードは、アプリケーション開発テクノロジーの中核をなすセットの一部であるとみなすことができ、またさらに、対応するサービスをコンピューティング・デバイス・プラットフォームに提供するためにランタイム実行環境２００での実行用にコンパイルされたアプリケーション、プログラム、機能、あるいはプログラム可能で実行可能なコードのその他の集合とみなすことができる。さらにランタイム実行環境２００は、マネージドのコードを解釈的なレベルで命令へと翻訳することができ、それらの命令は、代理する（ｐｒｏｘｙ）ことができ、そしてプロセッサによって実行することができる。ランタイム実行環境２００のためのフレームワークはまた、クラスライブラリを提供し、このクラスライブラリは、マネージドのアプリケーションに関するソフトウェアの基礎的要素とみなすことができる。

ランタイム実行環境２００は、少なくとも部分的な機能を提供することができ、この部分的な機能は、別なやり方でカーネルから求められることができ、カーネルは、デバイス１０５、１１０、および１１５（図１を参照されたい）のうちの特定の１つに関するリソースの制約に依存してコンピューティング・デバイス・プラットフォームから欠けているかもしれないし、あるいは欠けていないかもしれない。したがって、ランタイム実行環境２００の少なくとも１つの例は、入力／出力（以降では「Ｉ／Ｏ」と呼ぶ）ルーチン管理、メモリ管理、コンパイリング、およびサービスルーチン管理を実装することができる。したがってランタイム実行環境２００は、Ｉ／Ｏコンポーネント２０５と、コンパイラ２１０と、少なくとも１つのメモリ管理コンポーネント２１５と、サービス・ルーチン・マネージャ２２５と、実行コンポーネント２２５とを含むことができる。これらのコンポーネントについては、以降でさらに詳しく説明するが、例として提供されており、ランタイム実行環境２００のいかなる特定の実施形態にも限定することを意図するものではなく、そのような推論は、行うべきではない。したがって、これらのコンポーネントは、ランタイム実行環境２００の例の中に様々な組合せおよび構成で実装することができる。

ランタイム実行環境２００のＩ／Ｏコンポーネント２０５は、コンピューティング・デバイス・プラットフォームに関連付けられているデータソース（すなわち、プロセッサおよび周辺機器）への非同期アクセスを提供することができる。より詳細には、Ｉ／Ｏコンポーネント２０５は、ランタイム実行環境２００に、堅牢なシステムスループットを提供し、Ｉ／Ｏ要求が生じる元となるコードの実行をさらに合理化することができる。

コンパイラ２１０は、コンパイルされたＩＬを、ランタイム実行環境２００内で実行するためのネイティブな機械命令へと解釈することができるランタイム実行環境２００内のモジュールを指すことができる。さらに、モジュールの初期化１２０の少なくとも１つの例示的な実施形態によれば、コンパイラ２１０は、ランタイム実行環境２００内へロードすることができるアプリケーション、プログラム、機能、あるいはプログラム可能で実行可能なコードのその他の集合に関連付けられているコードモジュールの動作を様々な目的から動的に分析することができる。そのような分析は、コンパイルされたコードモジュールのバージョンおよびプロトコルの互換性について判断することを含むことができる。さらにまた、この分析は、コードモジュールの実行可能な部分に触れたり影響を及ぼしたりすることなく実行することができる。この分析は、コンパイル時に、または最初のランタイムに、あるいはその後にコードモジュールの実行可能な部分を実行している最中の任意の時点で、実行することができる。

メモリ管理コンポーネント２１５は、「ごみ収集担当」とみなすことができる。ごみの収集は、マネージドのコードの実行環境の堅牢な機能とみなすことができ、この機能は、メモリヒープ（ｍｅｍｏｒｙ ｈｅａｐ）を掃除したりスキャンしたりした際に、オブジェクトがもはやどのアプリケーションによっても使用されていないならば、オブジェクトを自動的に解放する（すなわち、割り当てを解除する）。メモリ管理コンポーネント２１５によって実施されるさらなる機能には、コンピューティング・デバイス・プラットフォーム上で実行されているタスクの間で、有限な揮発性ＲＡＭ（すなわち、メモリヒープ）ストレージの１つまたは複数の連続したブロック、あるいはメモリの連続したブロックのセットを管理すること、コンピューティング・デバイス・プラットフォーム上で実行されている少なくとも１つのアプリケーションにメモリを割り当てること、アプリケーションのうちの少なくとも１つによる要求に応じてメモリの少なくとも一部を解放すること、およびアプリケーションのうちのいずれかが、その他のアプリケーションのうちのいずれかに割り当てられているメモリスペースに煩わしくアクセスするのを防止することを含むことができる。

プロセッサおよび周辺機器のためのサービス機能を提供するために、アプリケーションサポート層（ａｐｐｌｉｃａｔｉｏｎ ｓｕｐｐｏｒｔ ｌａｙｅｒ）の少なくとも一部として、サービス・ルーチン・マネージャ２２０を含むことができる。動的なノード間通信パイプラインに関連付けられているサービスの例示的な実施形態は、サービス・ルーチン・マネージャ２２０によって管理することができる（ただし、この管理を行えるのは、サービス・ルーチン・マネージャ２２０だけではない）。例えばサービス・ルーチン・マネージャ２２０は、アプリケーションが、サービス、ＡＰＩアダプタなどのモジュール、およびプロトコルに登録できるようにすることができる。このような例示的な実施形態に加えて、サービス・ルーチン・マネージャ２２０は、サービスに入力されたパラメータおよび制約に基づいて、サービスに登録されているアダプタおよびプロトコルの様々な組合せを含むノード間通信パイプラインを構成して組み立てることを可能にすることができる。

実行コンポーネント２２５は、コンピューティング・デバイス・プラットフォームのためのマネージドのコードを実行できるようにすることができる。より詳細には、動的なピアツーピア通信パイプライン１２０の実施形態に関して、実行コンポーネント２２５は、例えば、動的なノード間通信パイプラインによって満たされるべきプロトコルの制約を含む１つまたは複数のパラメータを決定することができるランタイム実行環境２００内の例示的なコンポーネントとして機能することができる。そのようなパラメータは、サービス・ルーチン・マネージャ２２０に関して上述したように、モジュールおよびプロトコルが登録されているサービスへ入力することができる。さらに実行コンポーネント２２５は、そのようなパラメータを実施形態１２０のためのサービスへ提示することができる。

図３は、本明細書に記載されているノード間通信パイプラインの例示的な実施形態のうちの少なくとも１つによって構成され組み立てられている例示的なノード間通信パイプライン３００を示している。

より詳細には、ノード間通信パイプライン３００の例示的な実施形態は、２つのオブジェクトを通信可能に接続するモジュールの動的に組み立てられた連続を含むことができる。パイプライン３００の少なくとも１つの実施形態によるそのようなオブジェクトの例としては、ホストアプリケーションおよびアドインアプリケーションが含まれるが、これらには限定されない。さらにより詳細には、ノード間通信パイプライン３００は、１つのアダプタから別のアダプタへのプロトコル間の通信を可能にすることができる。

モジュール３０５は、ホストアプリケーションのためのＡＰＩの抽象インターフェースまたはクラスとみなすことができるホスト・ビュー・オブジェクト（ｈｏｓｔ ｖｉｅｗ ｏｂｊｅｃｔ）に相当することができる。

モジュール３１０は、モジュール３０５とインターフェースをとることができる少なくとも１つのアダプタに相当することができる。すなわちモジュール３１０は、１つのノードオブジェクトのＡＰＩ（すなわちモジュール３０５）を、別のノードオブジェクトのＡＰＩと互換性を持って通信するように適合させることができる。

モジュール３１５は、モジュール同士が通信できるようにする上で介さなければならない規格や規約を指すプロトコルに相当することができる（ＡＰＩは、それらのモジュールの一例だが、そうした例は、ＡＰＩだけではない）。プロトコル３１５は、厳格に規定することができ、したがって不変であることができ、それによってプロトコル内のモジュールは、お互いに通信することができる。パイプライン３００の少なくとも１つの例示的な実施形態によれば、プロトコル３１５は、少なくとも、実行環境間のプロトコル、隔離構造間の（すなわち、特定の実行環境内で１つの隔離構造から別の隔離構造にわたる）プロトコル、プロセス間のプロトコル、およびマシン間のプロトコルのうちのいずれか１つに相当することができる。したがってプロトコル３１５は、モジュール（すなわちＡＰＩ）のための通信ブリッジ（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｂｒｉｄｇｅ）（例えば隔離構造、プロセス、およびマシン、規格）に相当することができる。モジュール３２０は、モジュール３０５とインターフェースをとることができる少なくとも１つのアダプタに相当することができる。モジュール３２０は、１つのノードオブジェクトのＡＰＩ（すなわちモジュール３２５）を、別のノードオブジェクトのＡＰＩ（すなわちモジュール３０５）と互換性を持って通信するように適合させることができる。

モジュール３２５は、アドイン・ビュー・オブジェクト（ａｄｄ−ｉｎ ｖｉｅｗ ｏｂｊｅｃｔ）に相当することができる。この例によれば、モジュール３２５は、アドインアプリケーションのためのＡＰＩの抽象インターフェースまたはクラスとみなすことができる。

図４は、動的なノード間通信パイプライン１２０（図１を参照されたい）の例示的な実施形態による例示的な処理フロー４００を示している。処理フロー４００については、図２のランタイム実行環境２００および図３の例示的なパイプライン３００に関して上述した機能および特徴を参照して説明することができる。

より詳細には、限定されない例として、処理フロー４００の説明は、複数バージョンのモジュール（例えば、ホスト・ビュー・オブジェクト）３０５と、複数バージョンのモジュール（例えば、アドイン・ビュー・オブジェクト）３２５との間で互換性のある通信を可能にすることに言及することができる。

ブロック４０５は、複数バージョンのモジュール３１０および３２０をサービス４１５へ登録するサービス・ルーチン・マネージャ２２０（図２を参照されたい）、ホストアプリケーション、およびアドインアプリケーションのうちの少なくとも１つを指すことができる。すなわちサービス４１５は、モジュール３１０か、モジュール３２０か、またはモジュール３１０かモジュール３２０のどちらかとインターフェースをとるための少なくとも１つのその他のアダプタモジュールのうちの１つと、インターフェースをとることができる複数のアダプタを内部に登録しておくことができる。一例として、サービス４１５は、複数バージョンのホスト・ツー・プロトコルアダプタモジュール（ｈｏｓｔ−ｔｏ−ｐｒｏｔｏｃｏｌ ａｄａｐｔｅｒ ｍｏｄｕｌｅ）３１０を内部に登録しておくことができ、ホスト・ツー・プロトコルアダプタモジュール３１０のそれぞれは、別のバージョンのモジュール３０５と別のプロトコル３１５との間で通信可能にインターフェースをとることができる。同様にサービス４１５は、複数バージョンのプロトコル・ツー・アドインアダプタモジュール（ｐｒｏｔｏｃｏｌ−ｔｏ−ａｄｄ−ｉｎ ａｄａｐｔｅｒ ｍｏｄｕｌｅ）３２０を内部に登録しておくこともでき、プロトコル・ツー・アドインアダプタモジュール３２０のそれぞれは、別のプロトコル３１５と別のバージョンのモジュール３２５との間で通信可能にインターフェースをとることができる。

したがってブロック４０５は、複数のプロトコル３１５をサービス４１５へ登録するサービス・ルーチン・マネージャ２２０、ホストアプリケーション、およびアドインアプリケーションのうちの少なくとも１つをさらに指すことができる。サービス４１５へ登録される複数のプロトコル３１５は、モジュール同士の間における通信上の制約として指定することができ、それらの制約としては、例えば、実行環境間の（例えば、マネージドの実行環境と、アンマネージドの実行環境との間における）プロトコル、隔離構造間のプロトコル、プロセス間のプロトコル、およびマシン間のプロトコルが含まれる。

ブロック４１０は、１つまたは複数のノード間通信パイプラインを構成して組み立てる際のパラメータを指定したりその他の形で定義したりするホストアプリケーションおよびアドインアプリケーションのうちの少なくとも１つを指すことができる。例えばホストアプリケーションは、ノード間通信パイプライン３００の１つまたは複数の実施形態を構成して組み立てる際の少なくとも１つのホストビューモジュール３０５、１つまたは複数の制約、および少なくとも１つのアドインビューモジュール３２５を指定することができる。１つまたは複数の制約を、ホストビューモジュール３０５およびアドインビューモジュール３２５と併用すれば、プロトコル３１５のうちの適切な１つを識別するには十分かもしれない。しかし上述のように、ホストアプリケーションが、モジュール３０５、３１５、および３２５のうちの１つまたは複数の部分的な組合せを指定できる可能性の方が高い。したがって一例として、ブロック４１０は、より詳細には、１つまたは複数のノード間通信パイプラインを構成して組み立てる際の１つまたは複数のホストビューモジュール３０５およびプロトコル３１５を指定したりその他の形で定義したりするホストアプリケーションを指すことができる。

ブロック４１０においてサービス４１５のために指定されたり定義されたりするパラメータに加えて、１つまたは複数の制約を、ノード間通信パイプライン３００の１つまたは複数の実施形態を構成して組み立てる際のホストビューモジュール３０５、プロトコル３１５、およびアドインビューモジュール３２５のうちのいずれかに関して指定することができる。これらの制約は、ノード間通信パイプライン上のノード同士の間におけるプロトコルによって満たされる任意のユーザ定義のプロパティを含むことができるパラメータである。例えば、これらの制約は、実行するのに必要とされる許可と、ノード間通信パイプライン３００の構成され組み立てられた実施形態上で指定されたり定義されたりしているプロトコル３１５によってサポートされる隔離境界（ｉｓｏｌａｔｉｏｎ ｂｏｕｎｄａｒｙ）とを指定したりその他の形で定義したりすることができる。そのような隔離境界の例は、局所的な境界（ｌｏｃａｌ ｂｏｕｎｄａｒｙ）、共有されている隔離構造、私的な隔離構造（ｐｒｉｖａｔｅ ｉｓｏｌａｔｉｏｎ ｃｏｎｓｔｒｕｃｔ）、あるいはその他のプロセスを指すことができる。

サービス４１５は、ホストアプリケーションまたはアドインアプリケーションのいずれかに対応する実行環境内に配置されているデータベース、レジストリ、およびファイルシステムのうちのいずれか１つを含むことができる。あるいはサービス４１５は、パイプライン３００を構成して組み立てることにアクセスできる限り、デバイスに基づく任意の場所や、ネットワークに基づく任意の場所に配置することができる。上述のように、サービス４１５は、ノード間通信パイプライン３００の多くの実施形態を構成して組み立てるための登録されたモジュール、パラメータ、および制約のためのリポジトリとして機能することができる。

ブロック４２０は、ノード間通信パイプライン３００の１つまたは複数の実施形態を構成して組み立てる単独または様々な組合せのコンパイラ２１０、サービス・ルーチン・マネージャ２２０、または実行モジュール２２５のうちのいずれか１つを指すことができる。より詳細には、パイプライン３００は、ブロック４１０においてサービス４１５へ入力されたパラメータおよび任意の制約によって指定されたりその他の形で定義されたりしているとおりに、１つまたは複数のホスト・ツー・プロトコルアダプタ３１０、プロトコル３１５、およびプロトコル・ツー・アドインアダプタ３２０の組合せをつなぎ合わせることによって構成することができる。

ここまで処理フロー４００の例に関して説明したように、３つのステージのパイプライン３００をブロック４２０において構成して組み立てることができる。しかし、とりわけホスト・ビュー・オブジェクト３０５およびアドイン・ビュー・オブジェクト３２５の多くの可能なバージョンを考慮すると、ノード間通信パイプライン３００の代替実施形態は、１つまたは複数のホスト・ツー・プロトコルアダプタ３１０、あるいは１つまたは複数のプロトコル・ツー・アドインアダプタ３２０を考えることができる。したがって、３つのステージや４つのステージのパイプライン３００の数百に及ぶ順列を考えることができる。この実施形態は、５つ以上のステージのパイプライン３００をサポートすることができるが、登録されたモジュールと、指定されたパラメータおよび制約とに基づく可能な順列の数は、指数関数的に増加する可能性がある。したがって、可能ではあるものの、そのようなパイプラインによって必要とされるリソース消費は、そのような実施形態に対して重荷になるおそれがある。

ブロック４２５は、ブロック４２０において構成されて組み立てられたパイプライン３００のうちの１つまたは複数を起動する、単独または様々な組合せのサービス・ルーチン・マネージャ２２０または実行モジュール２２５を指すことができる。より詳細には、ノード間通信パイプライン３００の少なくとも１つの実施形態が、サービス４１５のために指定されたりその他の形で定義されたりしたパラメータおよび任意の制約を満たしていることをホスト・ビュー・オブジェクト３０５が判断した場合には、パイプライン３００を介した通信処理のために隔離境界を作成することができる。そのような隔離境界は、別個の隔離構造（すなわち、アプリケーションドメイン）またはプロセスを含むことができる。

起動したら、パイプライン３００のモジュールをロードすることができる。すなわち、サービス４１５から検索されたモジュールを表すメタデータをロードすることができる。このようなロードの繰り延べは、セキュリティ対策とみなすことができる。というのも、アドインはサードパーティによって提供される可能性があり、したがって、信頼の層が欠落しているおそれがあるためである。

図１〜図４に関連する上述の説明によれば、ランタイム実行環境のモジュールの初期化は、内部にロードされる実行コードに関連付けられているデータに従って構成することができる。しかし、本明細書に記載されている例示的な実施形態は、図１の環境、図２および図３のコンポーネント、あるいは図４のプロセスだけに限定されない。モジュールの初期化１２０（図１を参照されたい）は、図２および図３を参照して説明したコンポーネントの様々な組合せによって、ならびに図４を参照して説明したブロックの様々な順序で実施することができる。

さらに、上述の例および実施形態のうちのいずれかのためのコンピュータ環境は、例えば１つまたは複数のプロセッサまたは処理装置と、システムメモリと、様々なシステムコンポーネント同士を結合するためのシステムバスとを有するコンピューティングデバイスを含むことができる。

コンピューティングデバイスは、揮発性メディアおよび不揮発性メディア、取り外し可能なメディアおよび取り外し不能なメディアの双方を含む様々なコンピュータ可読媒体を含むことができる。システムメモリは、コンピュータ可読媒体を、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）などの揮発性メモリ、および／またはＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）やフラッシュＲＡＭなどの不揮発性メモリの形態で含むことができる。磁気カセットやその他の磁気ストレージデバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、あるいはその他の光ストレージ、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）など、コンピュータによってアクセスできるデータを保存することができるその他のタイプのコンピュータ可読媒体を利用して、例示的なコンピューティングシステムおよび環境を実装することもできるということを理解されたい。

本明細書の全体を通じて、「一例」、「別の例」、「少なくとも１つの例」、「実施形態」、あるいは「例示的な実施形態」に言及しているが、これらは、記載されている特定の機能、構造、あるいは特徴が、本発明の少なくとも１つの実施形態内に含まれているということを意味している。したがって、そのような語句を使用して、１つの実施形態だけでなく、それよりも多くの実施形態を指すことができる。さらに、記載されている機能、構造、あるいは特徴は、１つまたは複数の実施形態内で任意の適切な方法で組み合わせることができる。

しかし、コードモジュールの初期化は、特定の詳細のうちの１つまたは複数を伴わずに、あるいはその他の方法、リソース、素材などを用いて実施することができるということを当業者なら認識することができる。その他の場合においては、よく知られている構造、リソース、あるいはオペレーションについて詳細には図示したり説明したりしていないが、これは、本発明の態様が分かりにくくなることを避けるためにすぎない。

コードモジュールの初期化の例示的な実施形態および応用例について例示して説明したが、本発明は上述の厳密な構成およびリソースには限定されないということを理解されたい。上述の説明および添付の特許請求の範囲の双方におけるような本発明の範囲から逸脱することなく、本明細書において開示されている本発明の方法およびシステムの構成、オペレーション、および細部において、当業者にとって明らかな様々な修正形態、変更形態、および変形形態を作成することができる。

ネットワークを介して通信するデバイスであり、モジュールを初期化するための例示的なテクノロジーを実装しているデバイスを示す図である。 動的なノード間通信パイプラインを実装するための例示的なテクノロジーを実装するための実行環境の一例を示す図である。 動的なノード間通信パイプラインの例示的な実施形態を示す図である。 例示的な動的なノード間通信パイプラインの実施形態による例示的な処理フローを示す図である。

Claims (20)

1. ノード間パイプライン実装のための少なくとも１つのパラメータを指定するステップ（４１０）と、
   サービス（４１５）にアクセスして前記指定されたパラメータを所定の順序で満たすモジュールを有するノード間パイプラインを構成するステップ（４２０）と
   を備えることを特徴とする方法。
2. 前記少なくとも１つのパラメータは、ノードアプリケーションのＡＰＩを含むことを特徴とする請求項１に記載の方法。
3. 前記少なくとも１つのパラメータは、ノードアプリケーションのＡＰＩ、ピアアプリケーションのＡＰＩ、またはプロトコルの制約のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
4. 前記少なくとも１つのパラメータは、隔離構造間の互換性、プロセス間の互換性、またはマシン間の互換性のうちの１つを含む制約を指定することを特徴とする請求項１に記載の方法。
5. 前記パイプラインは、第１のノードのＡＰＩ実装されたアダプタモジュールと、第２のノードのＡＰＩ実装されたアダプタモジュールと、プロトコル制約モジュールとを含むことを特徴とする請求項１に記載の方法。
6. １つのノードはホストアプリケーションであり、別のノードはアドインアプリケーションであることを特徴とする請求項１に記載の方法。
7. ノード間通信パイプラインを組み立てる際に使用することができるモジュールを登録するステップ（４０５）と、
   特定のノード間通信パイプラインを定義するために少なくとも１つのパラメータを受信するステップ（４１０）と、
   前記パラメータに準拠するモジュールを使用して前記特定のノード間通信パイプラインの少なくとも１つのバージョンを組み立てるステップ（４２０）と
   を、読み取られるときに１つまたは複数のプロセッサに実行させる１つまたは複数のコンピュータ実行可能命令を有することを特徴とする少なくとも１つのコンピュータ可読媒体。
8. 前記１つまたは複数の命令は、少なくとも部分的に、サービスにおいて実行されることを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
9. 前記モジュールは、第１のノード・ツー・プロトコルアダプタモジュール、プロトコルモジュール、および少なくとも１つのプロトコル・ツー・第２のノードプロトコルアダプタモジュールのうちの少なくとも１つを含むことを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
10. 前記ノード間パイプラインは、プロトコル間の通信パイプラインであることを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
11. 前記ノード間パイプラインは、ホストアプリケーションＡＰＩからアドインアプリケーションＡＰＩへ実装されるプロトコル間の通信パイプラインであることを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
12. 前記少なくとも１つのパラメータは、第１のノードアプリケーションのＡＰＩ、第２のノードアプリケーションのＡＰＩ、またはプロトコル間の制約のうちの少なくとも１つを含むことを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
13. 前記少なくとも１つのパラメータは、隔離構造間の互換性、プロセス間の互換性、またはマシン間の互換性のうちの１つを有するプロトコル間の制約を含むことを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
14. 前記少なくとも１つのパラメータは、アンマネージドの実行環境内の第２のノードと通信するマネージドの実行環境内の第１のノードを指定するプロトコル間の制約を含むことを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
15. 組み立てを行うための前記１つまたは複数の命令は、前記１つまたは複数のプロセッサに、前記パラメータに準拠する前記モジュールを特定の順序で組み立てさせることを特徴とする請求項７に記載の少なくとも１つのコンピュータ可読媒体。
16. 指定されたプロトコル内のパイプラインに関する１つまたは複数のパラメータを指定するためのホスト（２２０）と、
    サービス（４１５）であって、
    プロトコル内のパイプラインを組み立てる際に使用することができるモジュールを登録し（４０５）、
    前記１つまたは複数のパラメータを満たす前記登録されたモジュールのうちの様々なモジュールを、前記指定されたプロトコル内のパイプラインの１つまたは複数のバージョンへと組み立てる（４２０）、サービス（４１５）と、
    前記指定されたプロトコル内のパイプラインの前記組み立てられたバージョンのうちの１つまたは複数を起動する（４２５）ためのアクティベータと
    を備えることを特徴とするシステム。
17. 前記少なくとも１つのパラメータは、ホストアプリケーションのＡＰＩ、アドインアプリケーションのＡＰＩ、またはプロトコル間の制約のうちの少なくとも１つを含むことを特徴とする請求項１６に記載のシステム。
18. 前記１つまたは複数のパラメータは、隔離構造間の互換性、プロセス間の互換性、またはマシン間の互換性のうちの１つを有するプロトコル間の制約のうちの少なくとも１つを含むことを特徴とする請求項１６に記載のシステム。
19. 前記指定されたプロトコル内のパイプラインは、少なくとも、ホストＡＰＩ・ツー・プロトコルアダプタ、プロトコル、およびプロトコル・ツー・アドインアダプタのうちの１つを含むことを特徴とする請求項１６に記載のシステム。
20. 前記指定されたプロトコル内のパイプラインは、マネージドの実行環境内のホストＡＰＩからアンマネージドの実行環境内のアドインＡＰＩへと拡張していることを特徴とする請求項１６に記載のシステム。

Images