リモート境界を横切ってコンピュータ読取り可能オブジェクトを転送するためのシステムおよび方法
【課題】リモート境界を横切ってコンピュータ読取り可能オブジェクトをセキュアに転送するためのシステムおよび方法を提供すること。
【解決手段】この方法は、任意の型のオブジェクトを、既知のオブジェクト型リストに基づいてサブコンポーネント階層に分解する。各サブコンポーネントは、既知のオブジェクト型または未知のオブジェクト型のいずれかに対応する。未知のオブジェクト型は、他の階層レベルで既知のオブジェクト型にさらに分解することができる。階層内の既知のオブジェクトはパッケージに直列化され、リモートエンティティに伝送される。リモートエンティティは階層を再構築する。いずれかの既知のオブジェクト型について、リモートエンティティは既知のオブジェクト型のうちの１つのオブジェクトをインスタンス化し、そのオブジェクトにパッケージ中で伝送された情報を読み込む。
【解決手段】この方法は、任意の型のオブジェクトを、既知のオブジェクト型リストに基づいてサブコンポーネント階層に分解する。各サブコンポーネントは、既知のオブジェクト型または未知のオブジェクト型のいずれかに対応する。未知のオブジェクト型は、他の階層レベルで既知のオブジェクト型にさらに分解することができる。階層内の既知のオブジェクトはパッケージに直列化され、リモートエンティティに伝送される。リモートエンティティは階層を再構築する。いずれかの既知のオブジェクト型について、リモートエンティティは既知のオブジェクト型のうちの１つのオブジェクトをインスタンス化し、そのオブジェクトにパッケージ中で伝送された情報を読み込む。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書に開示された主題はリモートコンピューティングシステムに関し、特に、リモート通信中にコンピュータ読取り可能オブジェクトを転送するための方法に関する。
【背景技術】
【０００２】
現在では、開発者がソフトウェアを開発する際にはオブジェクト指向プログラミングと呼ばれるプログラミング概念を利用する。オブジェクト指向プログラミングでは、コンピュータ読取り可能オブジェクト（オブジェクト）が定義される。オブジェクトはプロパティおよびメソッドを有する。プロパティは、オブジェクトに関係するデータを格納する。メソッドは、オブジェクトに関連付けられた機能を実行し、一般的にはオブジェクト内に定義されたプロパティへのインターフェースを提供する。オブジェクトを使用したプログラミングは、卓越した多様性を提供するが、異なるコンピュータ間などのリモート境界を横切ってオブジェクトを使用すると、いくつかの課題を示す。
【０００３】
課題の１つは、２つのコンピュータ間でオブジェクトを転送するための機構を決定することである。ある種の環境では、オブジェクト用の実行可能コード（メソッド）およびそのプロパティが、サーバコンピュータから要求側コンピュータに転送される。しかしながらこの解決方法は、転送された実行可能コードがファイルの削除などの不正な動作を実行した場合、要求側コンピュータにセキュリティリスクを及ぼす可能性がある。したがって、この潜在的なリスクを最小限にするための他の解決方法が開発されてきた。
【０００４】
現在の解決方法の１つが、Ｗｅｂサービス技術と呼ばれる技術である。この技術を使用する場合、オブジェクトはＸＭＬ（拡張マークアップ言語）に変換され、これが要求側コンピュータに送信される。要求側コンピュータはＸＭＬを受信すると、このＸＭＬをオブジェクトに再変換する。その後、要求側コンピュータはオブジェクトのプロパティにアクセスし、オブジェクトのメソッドを呼び出すことができる。この技術を使用する要求側コンピュータは、オブジェクトの受信元であるサーバを知ることおよび信用することが責務である。さらに、要求側コンピュータとの通信を希望するいかなるオブジェクトについても、オブジェクトを開発したソフトウェア開発者は、通信を処理するために特別なインターフェースを実施しなければならない。特別なインターフェースは、オブジェクトを転送するためにオブジェクトを直列化し、および非直列化するための機構を提供する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願第１０／４１３０５４号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
このＷｅｂサービスの解決方法は、リモート境界を横切ってオブジェクトを転送するための堅固な環境を提供するものであるが、この技術は制限が多く煩わしい。システム管理環境などの一部の環境において、ソフトウェア開発者にシステム管理タスクが監視を希望するオブジェクト用の特別なインターフェースを実装させることは、実行可能な解決方法ではない。例えば、開発者にこれらの特別なインターフェースを実装するように要求することは些細な問題ではなく、開発者は、彼ら自身の特定アプリケーション向けのオブジェクトを実施するという自分達の主要な目的から注意をそらさなければならない。したがって、多くの開発者が自分達のオブジェクト向けの特別なインターフェースを実装しないため、これらのオブジェクトにはアクセスできない。
【０００７】
したがって、ソフトウェア開発者にとってセキュアで、制限されず、かつ煩わしくない、リモート境界を横切ってオブジェクトを転送するための方法が求められている。
【課題を解決するための手段】
【０００８】
本発明は、オブジェクトのリモート通信用の機構および技法を対象とするものである。簡潔に言えば、リモート境界を横切ってコンピュータ読取り可能オブジェクトをセキュアに転送するためのシステムおよび方法が提供される。この方法は、任意の型のオブジェクトを、既知のオブジェクト型リストに基づいてサブコンポーネント階層に分解する。各サブコンポーネントは、既知のオブジェクト型または未知のオブジェクト型のいずれかに対応する。未知のオブジェクト型は、他の階層レベルで既知のオブジェクト型にさらに分解することができる。階層内の既知のオブジェクトは、パッケージに直列化され、リモートエンティティに伝送される。リモートエンティティは、階層を再構築する。既知のオブジェクト型のいずれかに関して、リモートエンティティは、既知のオブジェクト型のうちの１つのオブジェクトをインスタンス化し、そのオブジェクトにパッケージ中で伝送された情報を読み込む（ｐｏｐｕｌａｔｅ）。分解は、階層のレベルを指定すること、直列化される既知のオブジェクトを制限する数を指定すること、または直列化するオブジェクト内のプロパティを指定することによって、制限することができる。
【図面の簡単な説明】
【０００９】
【図１】例示的な管理ツールフレームワークが実施可能な例示的なコンピューティング装置を示す図である。
【図２】例示的な管理ツールフレームワークの概要を全体として示すブロック図である。
【図３】図２に示された管理ツールフレームワークのホスト特有のコンポーネント内にあるコンポーネントを示すブロック図である。
【図４】図２に示された管理ツールフレームワークのコアエンジンコンポーネント内にあるコンポーネントを示すブロック図である。
【図５】図２に示された管理ツールフレームワーク内で使用するのに好適な例示的な拡張型マネージャを示す機能ブロック図である。
【図６】図２に示された管理ツールフレームワーク内で使用するのに好適なコマンドレットを指定するための、例示的なデータ構造である。
【図７】コマンドレットのリモート処理を実行するための、図２に示された管理ツールフレームワーク内にあるコンポーネントを示す機能ブロック図である。
【図８】コマンドレットを処理するための例示的な処理を示す論理流れ図である。
【図９】図８で使用するのに好適な直列化処理および非直列化処理の概要を示すブロック図である。
【図１０】図８に示されたコマンドレットの処理で使用するのに好適なオブジェクトを直列化するための例示的処理を示す論理流れ図である。
【図１１】図８に示されたコマンドレットの処理で使用するのに好適なオブジェクトを非直列化するための例示的処理を示す論理流れ図である。
【図１２】図１０に示された直列化処理中に生成されるプロパティバッグ階層を示すグラフ図である。
【図１３】図１０に示されたオブジェクトを直列化するための処理に関して使用するのに好適な、プロトコルを取り決めるための例示的処理を示す論理流れ図である。
【発明を実施するための形態】
【００１０】
簡潔に言えば、リモート境界を横切ってオブジェクトを転送するための本システムおよび方法は、オブジェクトを転送するためのセキュアな方法を提供する。さらに本システムおよび方法は、いかなる人工的な要件をもオブジェクトに設定するものではない。したがってソフトウェア開発者は、自分たちのオブジェクトを使用するリモート操作をサポートする場合に、いかなる負担も負わない。したがって既存のシステムとは異なり、任意のコンピュータ上または同じコンピュータ上の他の処理中の任意のオブジェクトを、リモート境界を横切って要求側処理に転送することができる。さらに、オブジェクトを転送するための本システムおよび方法は、どちらのコンピュータにも同じバーションのソフトウェアを実行させる必要がない。むしろこの方法は、２つの異なるバージョン間での通信をサポートするための機構を提供するだけでなく、リモート境界を介して転送されるデータの量も最小限にする、プロトコルネゴシエーション処理を組み込む。
【００１１】
以下の詳細な説明は、いくつかのセクションに分けられる。一般に、本システムおよび方法については、例示的な管理ツール環境との関連において説明する。しかしながら、当業者が下記の説明を読めば、本方法が添付の特許請求の範囲にも含められる他の例示的な環境でも実施可能であることを理解されよう。
【００１２】
第１のセクションでは、例示的な管理ツール環境が動作可能な例示的なコンピューティング環境について説明する。第２のセクションでは、管理ツール環境用の例示的なフレームワークについて説明する。続くセクションでは、例示的なフレームワークの個々のコンポーネントおよびこれらのコンポーネントの運用について説明する。例えば図７〜１３に関する「コマンドレットの例示的なリモート処理」のセクションでは、リモート境界を横切ってオブジェクトを転送するための例示的なシステムおよび方法について説明する。
【００１３】
（例示的なコンピューティング環境）
図１に、例示的な管理ツール環境で使用可能な例示的なコンピューティング装置を示す。非常に基本的な構成では、通常、コンピューティング装置１００は少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を含む。厳密なコンピューティング装置の構成および型に依存して、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはその２つの何らかの組合せとすることができる。システム１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を含み、プログラムデータ１０７を含むことができる。オペレーティングシステム１０６は、コンポーネント（プロパティおよびイベントを含む）、オブジェクト、継承、多相性（ｐｏｌｙｍｏｒｐｈｉｓｍ）、反映（ｒｅｆｌｅｃｔｉｏｎ）をサポートし、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎが製造する．ＮＥＴ（商標）フレームワークのそれのようなオブジェクト指向コンポーネントに基づくアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する、コンポーネントに基づくフレームワーク１２０を含む。オペレーティングシステム１０５は、コンポーネントに基づくフレームワーク１２０と対話して管理ツール（図示せず）の開発をサポートする管理ツールフレームワーク２００も含む。この基本的な構成が図１に示されており、それらコンポーネントは破線１０８で囲まれている。
【００１４】
コンピューティング装置１００は、追加の特徴または機能を有することができる。例えばコンピューティング装置１００は、例えば磁気ディスク、光ディスク、またはテープなどの（取り外し可能および／または固定の）追加のデータ記憶装置を含むこともできる。こうした追加の記憶は、図１では取り外し可能な記憶１０９および固定の記憶１１０によって示されている。コンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性および不揮発性、取り外し可能および固定の媒体を含むことができる。システムメモリ１０４、取り外し可能なストレージ１０９、および固定のストレージ１１０は、すべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、あるいは、所望の情報を格納するために使用可能であり、コンピューティング装置１００によってアクセス可能な任意の他の媒体が含まれるが、これらに限定されない。任意のこうしたコンピュータ記憶媒体は、装置１００の一部とすることができる。コンピューティング装置１００は、キーボード、マウス、ペン、音声入力装置、タッチ式入力装置、その他などの、入力装置１１２を有することもできる。ディスプレイ、スピーカ、プリンタ、その他などの出力装置１１４も含むことができる。これらの装置は当分野でよく知られているため、これ以上ここで論じる必要はない。
【００１５】
コンピューティング装置１００は、ネットワークを介するなどして、装置が他のコンピューティング装置１１８と通信できるようにする通信接続１１６を含むこともできる。通信接続１１６は、通信媒体の一例である。通信媒体は、通常、搬送波または他の移送機構などの変調データ信号中のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータによって具体化することが可能であり、任意の情報送達媒体を含む。「変調データ信号」という用語は、その特徴の１つまたは複数を、信号内の情報を符号化したような方法で設定または変更した信号を意味する。例を挙げると、通信媒体は、有線ネットワークまたはダイレクトワイヤード接続などの有線媒体と、音波、ＲＦ、赤外線、および他の無線媒体などの無線媒体とを含むが、これらに限定されるものではない。本明細書で使用されるコンピュータ読取り可能な媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００１６】
（例示的な管理ツールフレームワーク）
図２に、例示的な管理ツールフレームワーク２００の概要を一般的に示す。管理ツールフレームワーク２００は、１つまたは複数のホストコンポーネント２０２、ホスト特有のコンポーネント２０４、ホストに依存しないコンポーネント２０６、およびハンドラコンポーネント２０８を含む。ホストに依存しないコンポーネント２０６は、他のそれぞれのコンポーネント（すなわち、ホストコンポーネント２０２、ホスト特有のコンポーネント２０４、およびハンドラコンポーネント２０８）と通信することができる。これらそれぞれのコンポーネントについては以下で簡単に説明し、必要に応じて後続のセクションでさらに詳細に説明する。
【００１７】
（ホストコンポーネント）
ホストコンポーネント２０２は、関連するアプリケーション向けの自動化機能をユーザまたは他のプログラムに公開する、１つまたは複数のホストプログラム（例えばホストプログラム２１０〜２１４）を含む。各ホストプログラム２１０〜２１４は、コマンド行、グラフィカルユーザインターフェース（ＧＵＩ）、音声認識インターフェース、アプリケーションプログラミングインターフェース（ＡＰＩ）、記述言語、Ｗｅｂサービス、およびその他を介するなどの、それ自体の特定のスタイルで、これらの自動化機能を公開することができる。しかしながら、ホストプログラム２１０〜２１４はそれぞれ、管理ツールフレームワークによって提供された機構を介して、この１つまたは複数の自動化機能を公開する。
【００１８】
この例では、機構は、コマンドレット（ｃｍｄｌｅｔ）を使用して、関連するホストプログラム２１０〜２１４のユーザに対して管理ツール機能を表面化させる。さらにこの機構は、ホストが使用可能にしたインターフェース群を用いて、対応するホストプログラム２１０〜２１４に関連付けられたアプリケーションに管理ツール環境を埋め込む。以下の考察全体を通じて、「コマンドレット」という用語は例示的な管理ツール環境内で使用されるコマンドを表す。
【００１９】
コマンドレットは、従来の管理環境におけるコマンドに対応する。しかしながらコマンドレットは、これら従来のコマンドとはまったく異なる。例えばコマンドレットは、解析、データの妥当性検査、エラー報告などの管理ツールフレームワークが提供する共通の機能を利用することができるので、通常、対応するコマンドよりもサイズが小さい。こうした共通の機能は、１回の実施毎にテストすることができる。そのため、管理ツールフレームワーク全体を通じてコマンドレットを使用すると、アプリケーション特有の機能に関連付けられた開発およびテスト費用を、従来の環境に比べて非常に低く抑えることができる。
【００２０】
さらに従来の環境とは対照的に、コマンドレットはスタンドアロン型の実行可能プログラムである必要がない。むしろコマンドレットは、管理ツールフレームワーク内の同じ処理で実行することができる。これによってコマンドレットは、互いの間で「ライブ」オブジェクトを交換することができる。この「ライブ」オブジェクトを交換できる機能によって、コマンドレットはこれらのオブジェクトに関するメソッドを直接呼び出すことができる。
【００２１】
概して各ホストプログラム２１０〜２１４は、管理ツールフレームワーク内でユーザと他方のコンポーネントとの間の対話を管理する。これらの対話は、パラメータ向けのプロンプト、エラー報告、およびその他を含むことができる。通常、各ホストプログラム２１０〜２１３は、特定のホストコマンドレット（例えばホストコマンドレット２１８）のそれ自体の集合を提供することができる。例えばホストプログラムが電子メールプログラムの場合、ホストプログラムは、メールボックスおよびメッセージと対話するホストコマンドレットを提供することができる。図２にホストプログラム２１０〜２１４を示すが、当業者であれば、ホストコンポーネント２０２が既存のまたは新規に作成されたアプリケーションに関連付けられた他のホストプログラムを含むことができることを理解されよう。これらの他のホストプログラムも、管理ツール環境によって提供される機能をそれらの関連するアプリケーションに埋め込むことになる。
【００２２】
図２に示す例では、ホストプログラムは、コンピューティング装置のハードウェア、ソフトウェア、およびネットワークコンポーネントを管理する管理ツールを作成、保存、およびオープンするための単純で一貫した管理ユーザインターフェースをユーザに提供する、管理コンソール（すなわちホストプログラム２１０）とすることができる。これらの機能を実施するために、ホストプログラム２１０は、管理ツールフレームワークの上に管理ＧＵＩを構築するためのサービスの集合を提供する。ＧＵＩの対話は、管理ツール環境によって提供されたスクリプティング機能をユーザに教示するのに役立つ、ユーザ可視（ｕｓｅｒ−ｖｉｓｉｂｌｅ）スクリプトとして公開することもできる。
【００２３】
他の例では、ホストプログラムは、コマンド行対話シェル（すなわちホストプログラム２１２）とすることができる。コマンド行対話シェルは、コマンド行の処理に影響を与えるためにシェルメタデータ２１６をコマンド行に入力できるようにするものである。
【００２４】
他の例では、ホストプログラムは、分散コンピューティング用の業界標準仕様と、プラットフォーム、プログラミング言語、およびアプリケーションを横切る相互運用性とを使用するＷｅｂサービス（すなわちホストプログラム２１４）とすることができる。図７に示す他の例では、ホストプログラムはリモートコンピュータと通信するためのリモートインターフェースを提供することができる。
【００２５】
これらの例に加えて、第三者が、それらのホストプログラムまたは他のホストプログラムと共に使用される「第三者」または「プロバイダ」インターフェースおよびプロバイダコマンドレットを作成することによって、それら自身のホストコンポーネントを追加することができる。プロバイダインターフェースは、管理ツールフレームワークがアプリケーションまたはインフラストラクチャを操作できるように、アプリケーションまたはインフラストラクチャを公開する。プロバイダコマンドレットは、ナビゲーション、診断、構成、ライフサイクル、操作、およびその他に自動化を提供する。プロバイダコマンドレットは、完全な異種集合のデータストア上で多相性（ｐｏｌｙｍｏｒｐｈｉｃ）のコマンドレット挙動を見せる。管理ツール環境は、他のコマンドレットクラスと同じ優先度で、プロバイダコマンドレット上で動作する。プロバイダコマンドレットは、他のコマンドレットと同じ機構を使用して作成される。プロバイダコマンドレットは、アプリケーションまたはインフラストラクチャの特定の機能を管理ツールフレームワークに公開する。したがって、コマンドレットを使用することによって製品開発者は、ホストコンポーネントを１つだけ作成すればよい。その後、このコンポーネントにより、彼らの製品は、多くの管理ツールで動作可能となる。例えば、例示的な管理ツール環境では、システムレベルのグラフィカルユーザインターフェースのヘルプメニューを既存のアプリケーションに統合および移植することができる。
【００２６】
（ホスト特有のコンポーネント）
ホスト特有のコンポーネント２０４は、フレームワークが実行されているプラットフォームの特性から管理ツールフレームワークを隔離するために、コンピューティングシステム（例えば図１のコンピューティング装置１００）が使用するサービスの集合を含む。したがって、各型のプラットフォームに対して、１つのホスト特有のコンポーネント群がある。ユーザは、このホスト特有のコンポーネントを使用して、異なるオペレーティングシステム上で同じ管理ツールを使用することができる。
【００２７】
次に図３を簡単に説明すると、ホスト特有のコンポーネント２０４は、インテリセンス（ｉｎｔｅｌｌｉｓｅｎｓｅ）／メタデータアクセスコンポーネント３０２、ヘルプコマンドレットコンポーネント３０４、構成／登録コンポーネント３０６、コマンドレットセットアップコンポーネント３０８、および出力インターフェースコンポーネント３０９を含むことができる。コンポーネント３０２〜３０８は、データベースストア３１４に関連付けられたデータベースストアマネージャ３１２と通信する。パーサ２２０およびスクリプトエンジン２２２は、インテリセンス／メタデータアクセスコンポーネント３０２と通信する。コアエンジン２２４は、ヘルプコマンドレットコンポーネント３０４、構成／登録コンポーネント３０６、コマンドレットセットアップコンポーネント３０８、および出力インターフェースコンポーネント３０９と通信する。出力インターフェースコンポーネント３０９は、ホストによって提供される出力コマンドレットへのインターフェースを含む。その後、これらの出力コマンドレットがホストの出力オブジェクトを呼び出して、レンダリングを実行する。ホスト特有のコンポーネント２０４は、コアエンジン２２４が、ログおよび監査機能を提供するホスト特有の（すなわちプラットフォーム特有の）サービスと通信するために使用する、ログ／監査コンポーネント３１０も含むことが可能である。
【００２８】
管理ツールフレームワークの一例では、インテリセンス／メタデータアクセスコンポーネント３０２がコマンド、パラメータ、およびパラメータ値の自動完了を提供する。ヘルプコマンドレットコンポーネント３０４は、ホストユーザインターフェースに基づいてカスタマイズされたヘルプシステムを提供する。
【００２９】
（ハンドラコンポーネント）
再度図２を参照すると、ハンドラコンポーネント２０８は、レガシーユーティリティ２３０、管理コマンドレット２３２、非管理コマンドレット２３４、リモーティング（ｒｅｍｏｔｉｎｇ）コマンドレット２３６、およびＷｅｂサービスインターフェース２３８を含む。（プラットフォームコマンドレットとも呼ばれる）管理コマンドレット２３２は、コンピューティング装置に関連付けられた構成情報を照会または操作するコマンドレットを含む。管理コマンドレット２３２は、システム型の情報を操作するものであるため、特定のプラットフォームに依存している。しかしながら各プラットフォームは、通常、他のプラットフォーム上で管理コマンドレット２３２と同様に動作する管理コマンドレット２３２を有する。例えば各プラットフォームは、システム管理属性（例えば取得／処理、設定／ＩＰアドレス）を取得および設定する管理コマンドレット２３２をサポートする。ホストに依存しないコンポーネント２０６は、ホストに依存しないコンポーネント２０６内で生成されたコマンドレットオブジェクトを介して管理コマンドレットと通信する。
【００３０】
（基本コマンドレットと呼ばれることもある）非管理コマンドレット２３４は、管理コマンドレット２３２によって提供されるオブジェクト上で他の処理をグループ化、ソート、フィルタリングを行い、および実行するコマンドレットを含む。非管理コマンドレット２３４は、パイプライン式オブジェクトに関連付けられたデータをフォーマット化し、および出力するためのコマンドレットも含むことができる。非管理コマンドレット２３４は、各プラットフォーム上で同一とすることが可能であり、コマンドレットオブジェクトを介してホストに依存しないコンポーネント２０６と対話するユーティリティ群を提供する。非管理コマンドレット２３４とホストに依存しないコンポーネント２０６との間の対話により、オブジェク上での反映が可能になり、それらの（オブジェクト）型に依存しない反映されたオブジェクト上での処理が可能になる。したがってこれらのユーティリティは、開発者が非管理コマンドレットをいったん作成すると、コンピューティングシステム上でサポートされているすべてのクラスのオブジェクトを横切ってそれらの非管理コマンドレットを適用できるようにする。従来開発者は、第１に、処理されることになるデータのフォーマットを理解した後、そのデータのみを処理するためにアプリケーションを作成しなければならなかった。したがって従来のアプリケーションは、非常に限られた範囲のデータしか処理することができなかった。
【００３１】
レガシーユーティリティ２３０は、ｃｍｄ．ｅｘｅの下で動作するｗｉｎ３２実行可能プログラムなどの、既存の実行可能プログラムを含む。各レガシーユーティリティ２３０は、オブジェクトフレームワーク内のオブジェクトの一種である、テキストストリーム（すなわち標準入力（ｓｔｄｉｎ）および標準出力（ｓｔｄｏｕｔ））を使用する管理ツールフレームワークと通信する。レガシーユーティリティ２３０は、テキストストリームを利用するので、管理ツールフレームワークによって提供される反映に基づく操作は使用不可能である。レガシーユーティリティ２３０は、管理ツールフレームワークとは異なる処理で実行する。図示されてはいないが、他のコマンドレットも処理外で操作可能である。
【００３２】
リモーティングコマンドレット２３６は、Ｗｅｂサービスインターフェース２３８と組み合わせて、インターネットまたはイントラネット（例えば図２に示されたインターネット／イントラネット２４０）などの通信媒体を介して、他のコンピューティング装置上の対話型およびプログラムに従った管理ツール環境にアクセスするためのリモーティング機構を提供する。管理ツールフレームワークの一例では、リモーティング機構は、複数の独立した制御ドメインに及ぶインフラストラクチャに依存する連合サービスをサポートする。リモーティング機構は、スクリプトがリモートコンピューティング装置上で実行できるようにするものである。スクリプトは、単一または複数のリモートシステム上で実行可能である。スクリプトの結果は、個々のスクリプトがそれぞれ完了したときに処理するか、または集約して、様々なコンピューティング装置上のすべてのスクリプトが完了した後でまとめて処理することが可能である。
【００３３】
例えば、ホストコンポーネント２０２の１つとして示されているＷｅｂサービス２１４は、リモートエージェントとすることができる。リモートエージェントは、対象のシステムにおけるパーサおよび管理ツールフレームワークへのリモートコマンド要求の送信を処理する。リモーティングコマンドレットは、リモートエージェントへアクセスするリモートクライアントとして働く。リモートエージェントおよびリモーティングコマンドレットは、解析済みストリームを介して通信する。この解析済みストリームをプロトコル層で保護するか、または解析済みストリームを追加のコマンドレットを使用して暗号化した後復号することができる。リモートコマンドレットを処理し、およびリモート処理間でオブジェクトを転送する例示的なコンポーネントについては図７に示しおり、下記の「コマンドレットの例示的リモート処理」と題するセクションで説明する。
【００３４】
（ホストに依存しないコンポーネント）
ホストに依存しないコンポーネント２０６は、パーサ２２０、スクリプトエンジン２２２、およびコアエンジン２２４を含む。ホストに依存しないコンポーネント２０６は、複数のコマンドレットをグループ化し、コマンドレットのオペレーションを調整し、他のリソース、セッション、およびジョブのコマンドレットとの対話を調整する機構およびサービスを提供する。
【００３５】
（例示的なパーサ）
パーサ２２０は、様々なホストプログラムからの入力要求を受信し、およびその入力要求をコアエンジン２２４内などの管理ツールフレームワーク全体を通じて使用される均一なコマンドレットオブジェクトにマッピングする機構を提供する。さらにパーサ２２０は、受信した入力に基づくデータ処理を実行することもできる。本管理ツールフレームワークのパーサ２２０は、同じ機能に関して異なる言語または構文をユーザに容易に公開する機能を提供する。例えば、パーサ２２０は入力要求を解釈する責務を負うものであるため、予想される入力構文に影響を与えるパーサ２２０内のコードの変更は、本質的に管理ツールフレームワークのそれぞれのユーザに影響を与えることになる。したがってシステム管理者は、異なる構文をサポートする異なるコンピューティング装置上に異なるパーサを提供することができる。しかしながら、同じパーサを使用して作業を行う各ユーザは、各コマンドレットについて一貫した構文を体験することになる。これに対して従来の環境では、各コマンドはそれ自体の構文を実施していた。したがって何千ものコマンドがある場合、いくつかの異なる構文をサポートするそれぞれの環境では、通常、それらの多くが互いに一貫していなかった。
【００３６】
（例示的なスクリプトエンジン）
スクリプトエンジン２２２は、スクリプトを使用して複数のコマンドレットを互いに結合するための機構およびサービスを提供する。スクリプトとは、厳密な継承規則の下でセッション状態を共有するコマンド行の集約である。スクリプト内の複数のコマンド行は、入力要求内に提供された構文に基づいて、同期的または非同期的のいずれかで実行することができる。スクリプトエンジン２２２は、ループまたは条件節などの制御構造を処理し、およびスクリプト内の変数を処理する機能を有する。さらにスクリプトエンジンは、セッション状態を管理し、ポリシー（図示せず）に基づいてセッションデータへのアクセスをコマンドレットに与える。
【００３７】
（例示的なコアエンジン）
コアエンジン２２４は、パーサ２２０によって識別されたコマンドレットを処理する責務を負う。次に図４を簡単に説明すると、管理ツールフレームワーク２００内の例示的なコアエンジン２２４が示されている。例示的なコアエンジン２２４は、パイプラインプロセッサ４０２、ローダ４０４、メタデータプロセッサ４０６、エラーおよびイベントハンドラ４０８、セッションマネージャ４１０、および拡張型マネージャ４１２を含む。
【００３８】
（例示的なメタデータプロセッサ）
メタデータプロセッサ４０６は、メタデータにアクセスし、図３に示されたデータベースストア３１４などのメタデータストア内にメタデータを格納するように構成される。メタデータは、コマンド行を介して、コマンドレットクラス定義内において、およびその他で供給可能である。管理ツールフレームワーク２００内の異なるコンポーネントは、それら自体の処理を実行中にメタデータを要求することができる。例えばパーサ２０２は、メタデータを要求して、コマンド行に供給されたパラメータの妥当性を検査することができる。
【００３９】
（例示的なエラーおよびイベントプロセッサ）
エラーおよびイベントプロセッサ４０８は、コマンド行の処理中に発生した各エラーに関する情報を格納するために、エラーオブジェクトを提供する。本管理ツールフレームワークに特に好適な１つの特定エラーおよびイベントプロセッサに関する追加の情報については、「System and Method for Persisting Error Information in a Command Line Environment」という名称の特許文献１を参照されたい。
【００４０】
（例示的なセッションマネージャ）
セッションマネージャ４１０は、管理ツールフレームワーク２００内の他のコンポーネントにセッションおよび状態情報を供給する。セッションマネージャによって管理される状態情報には、任意のコマンドレット、ホスト、またはコアエンジンがプログラミングインターフェースを介してアクセスすることができる。これらのプログラミングインターフェースは、状態情報の作成、修正、および削除が可能である。
【００４１】
（例示的なパイプラインプロセッサおよびローダ）
ローダ４０４は、パイプラインプロセッサ４０２がコマンドレットを実行するために、メモリ内に各コマンドレットを読み込むように構成される。パイプラインプロセッサ４０２は、コマンドレットプロセッサ４２０およびコマンドレットマネージャ４２２を含む。コマンドレットプロセッサ４２０は、個々のコマンドレットをディスパッチする。コマンドレットがリモートまたはリモートマシン群上での実行を要求する場合、コマンドレットプロセッサ４２０は、図２に示されたリモーティングコマンドレット２３６を使用して実行を調整する。コマンドレットマネージャ４２２は、コマンドレットの集合体の実行を処理する。コマンドレットマネージャ４２２、コマンドレットプロセッサ４２０、およびスクリプトエンジン２２２（図２）は互いに通信して、ホストプログラム２１０〜２１４から受信した入力に関する処理を実行する。通信は、本来反復的なものとすることができる。例えば、ホストプログラムがスクリプトを提供する場合、スクリプトは、それ自体がスクリプトの可能性があるコマンドレットマネージャ４２２を呼び出してコマンドレットを実行する。その後スクリプトは、スクリプトエンジン２２２によって実行することができる。
【００４２】
（例示的な拡張型マネージャ）
前述のように、管理ツールフレームワークは、オブジェクト上での反映を可能にし、それらの（オブジェクト）型に依存しない反映されたオブジェクト上での処理を可能にする、ユーティリティ群を提供する。管理ツールフレームワーク２００は、コンピューティングシステム上のコンポーネントフレームワーク（図１のコンポーネントフレームワーク１２０）と対話して、この反映を実行する。当業者であれば、反映は、オブジェクトを照会し、およびそのオブジェクトの型を取得する機能、ならびにその後、そのオブジェクト型に関連付けられた様々なオブジェクトおよびプロパティを反映して他のオブジェクトおよび／または所望の値を取得する機能を提供することを理解されよう。
【００４３】
反映は、オブジェクトに関する多くの量の情報を管理ツールフレームワーク２００に提供するが、従来の反映は、オブジェクトの型に焦点を合わせる。例えば、データベースのデータテーブルが反映される場合、戻される情報は、データテーブルが列プロパティおよび行プロパティという２つのプロパティを有することである。これら２つのプロパティは、データテーブル内の「オブジェクト」に関する詳細を十分に提供するものではない。拡張可能マークアップ言語（ＸＭＬ）および他のオブジェクトで反映が使用される場合、同様の問題が生じる。
【００４４】
これに対して拡張型マネージャ４１２は、オブジェクトの型以外の型の用法に焦点を合わせる。したがってこれを焦点とする場合、拡張型マネージャは、オブジェクトを使用して必要な情報が取得できるか否かを判定する。引き続き上記のデータテーブルの例を用いると、データテーブルが列プロパティを有し、行プロパティには特に関心が寄せられないことが分かる。しかしながら、用法に焦点を当てることによって、拡張型マネージャは各行を「オブジェクト」に関連付け、各列をその「オブジェクト」の「プロパティ」に関連付ける。したがって拡張型マネージャ４１２は、任意の型の精密に解析可能な入力から「オブジェクト」を作成するための機構を提供する。このように実行する場合、拡張型マネージャ４１２は、コンポーネントベースのフレームワーク１２０によって提供される反映機能を補い、「反映」を任意の型の精密に解析可能な入力まで拡張する。
【００４５】
概して拡張型マネージャは、精密に解析可能な入力（図示せず）にアクセスし、この精密に解析可能な入力を要求されたデータ型と相関させるように構成される。その後、拡張型マネージャ４１２は、要求された情報をパイプラインプロセッサ４０２またはパーサ２２０などの要求側コンポーネントに提供する。以下の考察では、精密に解析可能な入力は、プロパティおよび値を見分けることが可能な入力として定義される。精密に解析可能な入力の例には、Ｗｉｎｄｏｗｓ（登録商標）Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）入力、ＡｃｔｉｖｅＸ Ｄａｔａ Ｏｂｊｅｃｔ（ＡＤＯ）入力、拡張可能マークアップ言語（ＸＭＬ）入力、および．ＮＥＴオブジェクトなどのオブジェクト入力が含まれる。他の精密に解析可能な入力は、第三者データフォーマットを含むことができる。
【００４６】
図５は、管理ツールフレームワーク内で使用するための例示的な拡張型マネージャを示す機能ブロック図である。説明のために、拡張型マネージャによって提供される機能（丸で囲まれた数字「３」で示す）と、従来の密接に連結したシステムによって提供される機能（丸で囲まれた数字「１」で示す）および反映システムによって提供される機能（丸で囲まれた数字「２」で示す）とが対比される。従来の密接に連結したシステムでは、アプリケーション中で発呼者５０２は、オブジェクトＡ内の情報（例えばプロパティＰ１およびＰ２、メソッドＭ１およびＭ２）に直接アクセスする。前述のように発呼者５０２は、コンパイル時にオブジェクトＡによって提供されるプロパティ（例えばプロパティＰ１およびＰ２）およびメソッド（例えばメソッドＭ１およびＭ２）を、予め知っていなければならない。反映システムでは、（いずれのデータ型にも依存しない）汎用コード（ｇｅｎｅｒｉｃ ｃｏｄｅ）５２０がシステム５０８に照会し、このシステムが要求されたオブジェクトに関する反映５１０を実行し、オブジェクト（例えばオブジェクトＡ）に関する情報（例えばプロパティＰ１およびＰ２、メソッドＭ１およびＭ２）を汎用コード５２０に戻す。オブジェクトＡには図示されていないが、戻される情報は、ベンダ、ファイル、日付、およびその他などの追加情報を含むことができる。したがって汎用コード５２０は、反映を介して、密接に連結したシステムが提供する情報と少なくとも同じ情報を取得する。反映システムは、発呼者５０２がシステムに照会して、パラメータに関するいかなる事前の知識もなしに追加情報を取得できるようにするものでもある。
【００４７】
密接に連結したシステムおよび反映システムのどちらでも、新しいデータ型を容易にオペレーティング環境に組み込むことはできない。例えば密接に連結したシステムでは、一度オペレーティング環境が送達されると、そのオペレーティング環境が新しいデータ型を組み込むためには、その新しいデータ型をサポートするように再構築しなければならなくなるため、新しいデータ型を組み込むことはできない。同様に、反映システムでは、各オブジェクトクラス向けのメタデータが固定される。したがって、通常、新しいデータ型は組み込まれない。
【００４８】
しかしながら、本拡張型マネージャの場合、新しいデータ型をオペレーティングシステムに組み込むことができる。汎用コード５２０は、拡張型マネージャ５２２を使用して要求されたオブジェクトを反映し、第三者オブジェクト（例えばオブジェクトＡ’およびＢ）、セマンティック（ｓｅｍａｎｔｉｃ）Ｗｅｂ５３２、オントロジ（ｏｎｔｏｌｏｇｙ）サービス５３４、およびその他などの、様々な外部ソースによって提供される拡張データ型（例えばオブジェクトＡ’）を取得することができる。図に示されるように、第三者オブジェクトは既存のオブジェクト（例えばオブジェクトＡ’）を拡張するか、またはまったく新しいオブジェクト（例えばオブジェクトＢ）を作成することができる。
【００４９】
これら外部ソースは各々、それら固有の構造を型メタデータ５４０内に登録し、コード５４２を提供することができる。オブジェクトが照会されると、拡張型マネージャは型メタデータ５４０を再検討し、オブジェクトが登録されているか否かを判別する。オブジェクトが型メタデータ５４０内に登録されていない場合、反映が実行される。そうでない場合、拡張された反映が実行される。コード５４２は、反映される型に関連付けられた追加のプロパティおよびメソッドを戻す。例えば、入力型がＸＭＬの場合、コード５４２は、ＸＭＬドキュメントからオブジェクトを作成する際にＸＭＬが使用される方法を記述した記述ファイルを含むことができる。したがって、型メタデータ５４０は、拡張型マネージャ４１２が様々な型の精密に解析可能な入力（例えば第三者オブジェクトＡ’およびＢ、セマンティックＷｅｂ５３２）をどのように照会して、その特定の入力型用のオブジェクトを作成するための所望のプロパティを取得するべきかを記述し、コード５４２は、これらの所望のプロパティを取得するための命令を提供する。その結果、拡張型マネージャ４１２は、すべての型のオブジェクトに関する「反映」を可能にする、間接化（ｉｎｄｉｒｅｃｔｉｏｎ）の層を提供する。この間接化の層の実施例について、リモート処理に関して以下でより詳細に説明する。この実施形態では、精密に解析可能な入力（例えば直列化オブジェクト）を使用して、特定の入力型（例えばプロパティバッグ）用のオブジェクトを作成するために所望のプロパティを取得する。その後、さらにプロパティバッグを分解して、１つまたは複数の基本型のオブジェクトを作成する。以下で説明するように、拡張型マネージャは、リモート処理間でオブジェクトを転送するための一実施形態を実行可能にし、処理間で任意の型の任意のオブジェクトを転送可能にする。
【００５０】
拡張型の提供に加えて、拡張型マネージャ４１２は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ（ｇｌｏｂｂｅｒ）機構、プロパティ集合機構、関係機構、およびその他などの、追加の照会機構も提供する。様々な技法を使用して、拡張型マネージャ向けのセマンティックを実施することができる。以下に、３つの技法を説明する。しかしながら当業者であれば、これらの技法の変形形態が使用可能であることを理解されよう。
【００５１】
一技法では、静的メソッド（例えばｇｅｔｐｒｏｐｅｒｔｙ（））を有する一連のクラスを提供することができる。オブジェクトが静的メソッドに入力され（例えばｇｅｔｐｒｏｐｅｒｔｙ（ｏｂｊｅｃｔ））、静的メソッドは結果の集合を戻す。他の技法では、オペレーティング環境が、アダプタを使用してオブジェクトを包む（ｅｎｖｅｌｏｐ）。したがって入力が供給されない。アダプタの各インスタンスは、包まれたオブジェクト上で動作し、および包まれたオブジェクト用のプロパティを戻すｇｅｔｐｒｏｐｅｒｔｙメソッドを有する。この技法を例示する擬似コードを以下に示す。
【００５２】
【表１】
【００５３】
他の技法では、アダプタクラスがオブジェクトを下位分類する。従来では、下位分類はコンパイル前に発生した。しかしながら、あるオペレーティング環境では、下位分類が動的に発生する場合がある。この種の環境でこの技法を例示する擬似コードを下記に示す。
【００５４】
【表２】
【００５５】
したがって、図５に示されるように、拡張型マネージャは開発者が新しいデータ型を作成してそのデータ型を登録できるようにし、他のアプリケーションおよびコマンドレットがこの新しいデータ型を使用できるようにする。これに対して従来の管理環境では、コンパイル時に各データ型を知っておかなければならないため、そのデータ型からインスタンス化されたオブジェクトに関連付けられたプロパティまたはメソッドに直接アクセスすることができた。したがって、過去には、管理環境によってサポートされた新しいデータ型を追加することはめったに実行されなかった。
【００５６】
図２を参照すると、概して、管理ツールフレームワーク２００は、ユーザによって入力されたコマンドの実行を調整するためのシェルに依拠せず、むしろ、機能を処理部分（例えばホストに依存しないコンポーネント２０６）と（例えばホストコマンドレットを介する）ユーザ対話部分とに分割する。さらに、本管理ツール環境は、解析およびデータの妥当性検査に必要なコードがもはや各コマンドに含まれておらず、むしろ管理ツールフレームワーク内のコンポーネント（例えばパーサ２２０）によって提供されるため、管理ツールのプログラミングがかなり簡略化される。管理ツールフレームワーク内で実行される例示的な処理について、以下で説明する。
【００５７】
（例示的オペレーション）
図６は、管理ツール環境で使用される例示的なデータ構造を示す図である。図８〜１１および１３は、管理ツール環境内での例示的な処理流れを示す図である。当業者であれば、特許請求の範囲を逸脱することなく、下記で説明するコンポーネントとは異なるコンポーネントによって、ある種の処理が実行できることを理解されよう。管理ツールフレームワークのコンポーネント内で実行される処理について説明する前に、管理ツールフレームワーク内で使用されるコマンドレット用の例示的なデータ構造について説明する。
【００５８】
（コマンドレットオブジェクト用の例示的なデータ構造）
図６は、図２に示された管理ツールフレームワーク内で使用するのに好適なコマンドレットを指定するための例示的なデータ構造である。完了すると、コマンドレットは管理コマンドレット、非管理コマンドレット、ホストコマンドレット、プロバイダコマンドレット、またはその他とすることができる。以下の考察では、システム管理者の見地に基づいたコマンドレット（すなわちプロバイダコマンドレット）の作成について説明する。しかしながら、各型のコマンドレットが同じ様式で作成され、同様の様式で動作する。コマンドレットは、Ｃ＃などの任意の言語で作成することができる。さらにコマンドレットは、記述言語などを使用して作成することができる。管理ツール環境が．ＮＥＴ Ｆｒａｍｅｗｏｒｋで動作する場合、コマンドレットは．ＮＥＴオブジェクトとすることができる。
【００５９】
プロバイダコマンドレット６００（以下、コマンドレット６００と呼ぶ）は、コマンドレットクラス６０２から導出するパブリッククラスである。コマンドレット６００は、「＜ｃｏｍｍａｎｄ ｎａｍｅ＞」の代わりに指定されるコマンドレットクラス名を含む。ソフトウェア開発者は、「ｇｅｔ／ｐｒｏｃｅｓｓ」、「ｇｅｔ／ｄｂ」、「ｆｏｒｍａｔ／ｔａｂｌｅ」、およびその他などの動詞／名詞ペア６０６をコマンドレット６００に関連付ける、コマンドレットＤｅｃｌａｒａｔｉｏｎ６０４を指定する。動詞／名詞ペア６０６は、管理ツール環境内に登録される。動詞または名詞は暗黙的な場合がある。パーサは、名前（例えばｇｅｔ／ｄｂ）を有するコマンド文字列がコマンド行上またはスクリプト内で入力として供給されたときに、コマンドレットレジストリを見てコマンドレット６００を識別する。
【００６０】
コマンドレット６００は、コマンドレットへの予測される入力パラメータ用の文法を定義する文法機構に関連付けられる。文法機構は、コマンドレットに直接的または間接的に関連付けることができる。例えばコマンドレット６００は、直接的な文法関連付けを示す。コマンドレット６００では、１つまたは複数のパブリックパラメータ（例えば、Ｎａｍｅ６３０およびＳｔａｔｅ６３２）が宣言される。各パブリックパラメータ６３０および６３２を、入力属性６３１および６３３などの１つまたは複数型の属性と関連付けることができる。入力属性６３１および６３３は、それぞれ、パブリックパラメータ６３０および６３２を読み込む方式を指定する。例えばパブリックパラメータは、コマンドのパイプライン中、コマンド行から、およびその他の、他のコマンドレットによって発信されるオブジェクトから読み込むことができる。パブリックパラメータが他のオブジェクトから読み込まれる場合、コマンドレット６００は、第１のメソッド６４０（例えばＳｔａｒｔＰｒｏｃｅｓｓｉｎｇ）および第２のメソッド６４２（例えばｐｒｏｃｅｓｓＲｅｃｏｒｄ）を含む。コアエンジンは、第１および第２のメソッド６４０および６４２を使用してコマンドレット６００の処理を指示する。例えば第１のメソッド６４０は、１回実行され、およびセットアップ機能を実行することができる。第２のメソッド６４２内のコードは、コマンドレット６００によって処理される必要がある各オブジェクト（例えばｒｅｃｏｒｄ）について実行されることができる。コマンドレット６００は、コマンドレット６００の後に終結処理する第３のメソッド（図示せず）を含むこともできる。別の方法として、ＸＭＬドキュメントなどの外部ソース内に定義されたパブリックパラメータの記述を用いて、文法機構とコマンドレットを間接的に関連付けることもできる。この外部ソース内のパラメータの記述は、コマンドレットへのオブジェクト入力の構文解析を駆動することになる。
【００６１】
したがって図６に示されるように、第２のメソッド６４２内のコードは通常極めて簡潔であり、解析コード、データの妥当性検査コードなどの従来の管理ツール環境で必要とされた機能を含まない。したがってシステム管理者は、複雑なプログラミング言語を習得することなしに複雑な管理タスクを開発することができる。
【００６２】
データ構造６００は、入力パラメータとして認識されないプライベートメンバ６５０も含むことができる。プライベートメンバ６５０は、コマンドレット内で生成されたデータを格納するために使用することができる。
【００６３】
次に、管理ツール環境内の例示的な処理の流れについて説明する。
【００６４】
（コマンドレットの例示的なリモート処理）
図７は、本発明に関して説明された機構を利用するリモートコンピューティング環境７００を全体として示す機能ブロック図である。「アドミニストレータ」７１０コンピューティングシステムおよびリモートコンピューティングシステム（以下、リモートサーバ７２０と呼ぶ）が図示されている。リモートサーバ７２０は、物理的にいずれの場所に配置することも可能であり、従業員または加入者などのエンドユーザが使用中の個々のコンピューティングシステムとすることも可能である。図７には単一のリモートサーバ７２０が示されているが、リモートコンピューティング環境７００は任意の数のリモートサーバを含むことができる。各リモートサーバは、リモートサーバ７２０を参照しながら以下で説明するような処理を実行する。
【００６５】
アドミニストレータ１１２およびリモートサーバ７２０は、図１に示されたコンピューティング装置１００などのコンピューティング装置とすることができる。アドミニストレータ１１２は、リモートサーバ７２０を保守するためにシステム管理者などによって使用される。言い換えればアドミニストレータ１１２は、リモートサーバ７２０の状況または状態を照会することおよび／またはリモートサーバ７２０を変更することが可能なコマンドおよびタスクを実行する。アドミニストレータ１１２は、図２に示された管理ツールフレームワーク２００のいくつかのコンポーネントを含むことが可能な、実行環境を含む。具体的には、アドミニストレータ１１２はリモートインターフェース７１４および基本型７１２のリストを含む。一実施形態では、基本型７１２のリストは、オブジェクトの型を列挙するための第１の列と、型に関連付けられた特定のシリアライザを参照するための第２の列との、２つの列を有するテーブルを備える。管理ツールフレームワーク２００内の他のコンポーネントを使用してコマンドレットのリモート処理を実行することもできるが、下記の考察では、「Ｒｃｍｄ ｍａｃｈｉｎｅ：ＲｅｍｏｔｅＳｅｒｖｅｒ Ｇｅｔ／ＤＢ」などのリモートコマンドレットを処理するためのアドミニストレータ１１２とリモートサーバ７２０との間の対話に焦点を合わせ、この文脈で必要に応じて他のコンポーネントの動作について説明する。さらに下記の例では、１つのコマンドレットのリモート処理を示す。しかしながら、リモートの態様はコマンドレットのパイプラインが存在する場合でも同様に等しく動作する。
【００６６】
リモートサーバ７２０はリモートエージェント７２４を含む。リモートエージェント７２４は、１つまたは複数のコマンドレットを実行するためにリモート要求に応答するコンポーネントである。さらにリモートエージェント７２４は、１つまたは複数のコマンドレットの実行の結果を取り、要求側エンティティ（例えばアドミニストレータ１１２）に戻される戻りパッケージ７３０を作成するように構成される。一実施形態では、パッケージは、実行の結果、ならびに、呼出しの日付および時刻などのメタ情報、結果の発信元である特定のリモートシステムに関する識別情報、および要求側エンティティに関する情報を含む、直列化オブジェクトの形を取る。この情報および起こり得る他の情報が戻りパッケージ７３０にまとめられ、要求側エンティティ（例えばアドミニストレータ１１２）に返送される。
【００６７】
要求側エンティティは、コンピューティングシステム上で実行中の１つの処理とすることが可能であり、リモートサーバは、同じコンピューティングシステム上で動作中の他の処理とすることが可能であることに留意されたい。この構成では、通信インターフェース７４０は、２つの処理間で通信するための当業者によく知られたシステムレベルのアプリケーションプログラミングインターフェース（ＡＰＩ）を含む。他の実施形態では、通信インターフェース７４０は、インターネットまたはイントラネットのネットワークを含む。
【００６８】
図８は、コマンドレットを実行するために処理８００によって実行可能なステップを全体として示す論理流れ図である。処理は、意思決定ブロック８０６で始まり、コマンド行などを介するなど、コマンドレットが実行のために入力されている。例えばコマンドレット「Ｒｃｍｄ ｍａｃｈｉｎｅ：ＲｅｍｏｔｅＳｅｒｖｅｒ Ｇｅｔ／ＤＢ」が入力されている場合がある。意思決定ブロック８０６において、実行がリモート境界を横切る場所を決定するために、コマンドレットを実行する予定の場所が決定される。概して、各コンピューティングシステム（例えばアドミニストレータ７２０、リモートサーバ７２０）は、１つまたは複数の処理をサポートする。各処理は少なくとも１つのプログラムまたはアプリケーションをホスティングする。さらに、１つの処理が、１つまたは複数のアプリケーションドメインをホスティングすることもできる。アプリケーションドメインは、複数のアプリケーションが依然として他のアプリケーションとは分離しながらも、同じ処理内で実行できるようにする比較的新しい機構である。アプリケーションドメインは、ランタイム環境によってアプリケーションの周囲に作成される論理的および物理的な境界である。各アプリケーションドメインは、そのそれぞれのアプリケーションの構成、セキュリティ、または安定性が、他のアプリケーションドメイン内の他のアプリケーションに影響を与えないようにする。したがってコマンドレットは、１）要求側エンティティ（例えばアドミニストレータ）のアプリケーションドメイン内、２）要求側エンティティと同じ処理の他のアプリケーションドメイン内、３）要求側エンティティ上の他の処理内、または４）リモートサーバ上、という場所で実行することができる。コマンドレットが他の処理内（＃３）またはリモートサーバ上（＃４）のいずれかで実行する場合、下記の考察ではこれを「リモート境界」を介して実行するように言及し、一般に処理境界外での実行を意味する。
【００６９】
場所を指定するために、一実施形態では、コマンドレットと共に指定されたパラメータがどの場所でコマンドレットを実行するかを識別する。例えば、パラメータ「−ｎｏｄｅ」ならびに関連するノード名は、そのノード名に関連付けられたリモートサーバ上でのコマンドレットの実行を示すことができる。パラメータ「−ｗｏｒｋｅｒｐｒｏｃｅｓｓ」は、要求側エンティティの他の処理でのコマンドレットの実行を示すことができる。パラメータ「−ａｐｐｄｏｍａｉｎ」は、同じ処理の他のアプリケーションドメイン内でのコマンドレットの実行を示すことができる。実行が、同じアプリケーションドメイン内、または同じ処理内の他のアプリケーションドメイン内で発生する場合、処理はブロック８０８で継続される。そうでない場合、処理はブロック８１８で継続される。ブロック８０８〜８１４の処理は、リモート処理を理解する上で不可欠ではないが、この処理を理解することは、コマンドレットのリモート処理をサポートするために克服された問題を理解する際の助けになる。
【００７０】
ブロック８０８では、コマンドレットに関連付けられたファイルが識別される。コマンドレットおよびその関連ファイルを、登録によって識別することができる。図６に関して上記で説明したように、ファイルはコマンドレットを実行するためのコードを含み、コマンドレットクラスに関連付けられたプロパティおよびメソッドも含む。
【００７１】
ブロック８１０において、ファイルは、現在のアプリケーションドメイン用の処理に読み込まれる。前述のように、ファイルが何らかの未知の信頼できないリモートサーバから読み込まれている場合、実行可能ファイルを要求側エンティティ上の処理にブラインドロードすることは、セキュリティリスクをもたらす。ブロック８２０〜８３４に関して説明するように、このセキュリティリスクは、リモート境界間でオブジェクトを転送するために本メソッドを利用することによって克服される。
【００７２】
ブロック８１２においてコマンドレットが実行される。実行には、コマンドレットオブジェクトを作成するためのコマンドレットクラスのインスタンス化が含まれる。コマンドレットクラスで指定された方式で、コマンドレットオブジェクト内に指定されたプロパティを取り込む。コマンドレットクラスのコードに定義されたようにオブジェクトを作成する。（パイプライン化されたコマンドの前のコマンドレットからのオブジェクトなどの）入ってくるオブジェクトが、現在のコマンドレットクラスに指定された型と合致しない場合、拡張型マネージャは、必要に応じて型を強制する（ｃｏｅｒｃｅ）ことができる。処理はブロック８１４へ進む。
【００７３】
ブロック８１４において、処理は、任意のプロパティにアクセスすることおよび任意のメソッドを呼び出すことによって、作成されたオブジェクトを操作することができる。これらの作成されたオブジェクトは、オブジェクトのメソッドが使用可能であり、および呼出し可能であるため、「ライブ」または「生」オブジェクトと呼ばれる。
【００７４】
想像できるように、ブロック８０８〜８１４において説明された処理は、コマンドレットがリモートコンピュータ上に配置された場合、あまり理想的とは言えない。リモートファイルが実行のためにローカル処理に読み込まれた場合、リモートファイルは、悪意あるコードを実行する可能性があり、これによって要求側エンティティのセキュリティを危険にさらす可能性がある。さらに管理ツール環境では、要求側エンティティ（例えばアドミニストレータ）は一般に、リモートコンピュータに関する管理情報の取得に関心がある。したがって、コマンドレットによって読み込まれるオブジェクトは、要求側エンティティ（例えばアドミニストレータ）ではなく、リモートサーバに関係する状況または他の情報を含まなければならない。
【００７５】
上述したように、従来のＷｅｂサービス環境では、クライアントは通信を希望するリモートサーバについて知ることおよびこれを信頼することの責務を負う。しかしながら上記で説明したように、特定のインターフェースをサポートするオブジェクトのみが要求側エンティティと通信できることから、これによってクライアントが通信できる相手がかなり制約される。要求側エンティティ（例えばアドミニストレータ）とリモートサーバとの間でオブジェクトを通信するための本方法は、このような制限を課さない。次にこの方法について説明する。便宜上、リモートエンティティ（例えばリモートサーバまたは別の処理）上で処理を実行するブロックは、「ドット付き」背景で示される。
【００７６】
意思決定ブロック８０６に戻り、コマンドレットが他の処理内またはリモートサーバ上で実行されることになる場合、処理はブロック８１８へ進む。ブロック８１８において、クライアントは、リモートエンティティに関連付けられたリモートエージェントとの通信を確立する。その後、リモートエージェントは、ブロック８２０〜８２４を実行し、これによって、リモートエンティティに関して実行するのではなく、ブロック８１０〜８１２に関して上記で説明した機能が実行される。しかしながらいったんコマンドレットが実行され、その関連するオブジェクトを取得すると、処理はブロック８２６へと進む。
【００７７】
ブロック８２６において、オブジェクトは、要求側エンティティ（例えばアドミニストレータ）のセキュリティが危険にさらされないような方式で直列化される。直列化処理によって、図７に示された戻りパッケージ７３０などの戻りパッケージが作成される。一般にオブジェクトの直列化は、要求側エンティティに対して有害な可能性の無い方式で、情報を直列化する。直列化処理の概要は、図９に示されており、直列化処理については、図１０に関して下記でより詳細に説明する。処理はブロック８２８へと進む。
【００７８】
ブロック８２８において、直列化されたオブジェクトがクライアントコンピュータに送信される。直列化オブジェクトの送信は、ネットワーク通信に関して知られた従来の方法を使用して実行するか、または要求側エンティティおよびリモートサーバが同じコンピュータ上にある場合、既知の処理間通信を使用することができる。処理はブロック８３０へと進む。
【００７９】
ブロック８３０において、直列化されたオブジェクトは、要求側エンティティで受信される。直列化されたオブジェクトの型は、拡張型マネージャで登録された型である。したがって、受信時に、拡張型マネージャは、直列化されたオブジェクトの型を認識する。処理は、ブロック８３２へと進む。
【００８０】
ブロック８３２において、直列化されたオブジェクトは、サブコンポーネントオブジェクトに非直列化される。簡潔に言えば、非直列化処理は、直列化されたオブジェクトを知られた基本型に分解する。非直列化処理の概要は、図９に示されており、非直列化処理については、図１１に関して下記でより詳細に説明する。処理はブロック８３４へと進む。
【００８１】
ブロック８３４において、基本型の１つであった非直列化されたオブジェクトを、オブジェクトに関連付けられたメソッドおよびプロパティが使用可能であることを意味する「生」オブジェクトとして操作することができる。基本型の１つではない非直列化されたオブジェクトは、「生」オブジェクトとして操作できない。これらのオブジェクトは「非直列化」オブジェクトと呼ばれ、オブジェクトはオブジェクトのある種のプロパティに関する情報を含むが、それらのメソッドは含まないことを意味する。
【００８２】
図９は、図８で使用するのに好適な直列化処理および非直列化処理の一般的な概要を示すブロック図である。一般に、直列化処理９００は、リモートエンティティ上で実行中のコマンドレットによって作成されたオブジェクト９０２を、階層ツリー９０４に変換する。一般に階層ツリー９０４は、サブコンポーネントに分割されたオブジェクト９０２を表すオブジェクトである。サブコンポーネントの中には、両方のエンティティ（例えば要求側エンティティおよびリモートエンティティ）によって知られたオブジェクト型のものもある。これらの知られた型は、それぞれ要求側エンティティおよびリモートエンティティの基本型７１２および７２２のリストで識別される（図７を参照のこと）。基本型７１２および７２２が同じ基本型リストを含まない場合、図１３に関して下記で詳細に説明するプロトコル取決め処理を実行して、どちらの基本型リストを使用するかを決定する。したがって、図１０に関して下記でより詳細に説明するように、階層ツリー内の各エントリは直列化され、直列化されたオブジェクト９０６に追加される。一実施形態では、直列化されたオブジェクト９０６は、ＸＭＬドキュメントを備える。この直列化されたオブジェクトは、他の情報と組み合わされて、要求側エンティティに送信される要求パッケージを形成する。
【００８３】
要求パッケージを受信すると、要求側エンティティは、直列化されたオブジェクト９０６を取り出して、非直列化処理９１０を実行する。一般に、非直列化処理９１０は、階層ツリー９０４を再構築する。階層ツリー９０４は、拡張型マネージャによって認識されたオブジェクト型の１つであるため、拡張型マネージャは、階層ツリー９０４を基本オブジェクトおよび／またはプロパティバッグオブジェクト９１２に分解する。基本オブジェクトは、機能（例えばメソッド）を有する「ライブ」（すなわち「生」）オブジェクトである。プロパティバッグオブジェクト９１２（すなわち「非直列化」オブジェクト）は、関連データを提供するが、メソッドは含まない。したがって、この概要が示すように、元来リモートエンティティ上で作成されたオブジェクト９０２は、要求側エンティティのセキュリティの危険を脅かすこと、またはオブジェクト９０２用の任意の特別なインターフェースを必要とすることなしに、複数の「生」基本オブジェクトおよび他の「非直列化された」オブジェクトとして要求側エンティティへ転送された。この非直列化処理９１０については、図１１に関してより詳細に説明する。
【００８４】
図１０は、オブジェクトを直列化するための例示的な処理９００を示す図である。前述のように、一般的な概要として、直列化処理９００は、オブジェクトおよびそのプロパティ（プロパティはオブジェクトでもある）を知られた基本型に、および場合によっては１つまたは複数のプロパティバッグに分解する。処理９００は、本来再帰的であり、（プロパティを含む）オブジェクトが基本型のうちのいずれか１つに分解されるまで、あるいは残りのオブジェクトがそれぞれ知られた基本型のリストに掲載されなくなるまで続行される。直列化処理９００が再帰的であり、管理が困難な階層ツリーを作成することができるため、処理９００は、下記で説明するいくつかの異なる技法を使用して制限することもできる。処理９００をより分かり易く説明するために、下記の考察では、「ｇｅｔ／ＤＢ」コマンドレットによって仮に作成されたオブジェクト例（例えばＳＱＬＩｎｆｏオブジェクト）を使用する。これらの従来の方式の１つを下記に示す。
【００８５】
【表３】
【００８６】
図１２は、処理９００中に作成される階層ツリーの一部を示すグラフ図である。階層ツリーは、上記に示されたＳＱＬＩｎｆｏオブジェクトの分解された部分を表し、直列化処理を説明するために図９に関して用いられる。
【００８７】
処理９００は、ブロック１００２で始まり、リモートコマンドレットによって作成されたオブジェクトが作成されている。ブロック１００２では、要求側エンティティおよびリモートエンティティが通信可能なレベルを識別するために、プロトコル取決め処理が実行される。簡潔に言えば、図１３に関して後で詳細に説明されるように、エンティティが通信するレベルは、オブジェクトを転送するために要求側エンティティに送信される情報の量を決定する。以下で説明するように、プロトコル取決め処理は、要求側エンティティおよびリモートエンティティの両方が依然として異なるバージョンを使用して互いに通信可能である一方で、それらのシステムを互いに独立してアップグレードできるようにするものである。実際のところ、これによって、リモートエンティティ上のバージョンよりも数年新しいバージョンの基本型で動作する要求側エンティティは、依然としてリモートエンティティと通信できるようにする。その逆もまた真である。したがって、数年前に出荷されたシステムを、新しい管理者コンピュータで管理することができる。取決め処理の出力は、それぞれの取り決められた基本型を識別する取決め済みリストである。通信レベルが決定されると、処理はブロック１００４へと進む。
【００８８】
ブロック１００４では、オブジェクトに関する情報を保持するためにプロパティバッグが作成される。一実施形態において、プロパティバッグは、ハッシュテーブルとして実施することができる。プロパティバッグは、管理ツール環境によってサポートされるコアデータ型である。処理はブロック１００６へと進む。
【００８９】
ブロック１００６において、オブジェクトを反映することによってオブジェクトの型が識別される。一旦型が識別されると、処理は意思決定ブロック１００８へと進む。意思決定ブロック１００８では、識別されたオブジェクト型が取り決められた基本型に含まれるか否かが決定される。この決定は、取り決められたリスト内の検索として実施することができる。この実施の場合、取り決められたリストが取り決められた基本型の各々を識別することになる。オブジェクトが取り決められた基本型の１つとして識別されると、処理はブロック１０１０へと進む。
【００９０】
ブロック１０１０では、識別されたオブジェクト用のプロパティバッグ内にエントリが作成される。次に、プロパティバッグの例示的な実施について説明する。
【００９１】
簡単に図１２を見ると、例示的な階層ツリー（例えばプロパティバッグツリー）の一部を示すグラフ図が示されている。この一部分は、プロパティバッグを有する第１のレベル１２２０と、サブプロパティバッグを有する第２のレベル１２４０との、階層ツリー内の２つのレベルを示す。各プロパティバッグ１２２０および１２４０が、名前フィールド１２０２、価値フィールド１２０４、および型フィールド１２０６を含む。さらに、各プロパティバッグ１２２０および１２４０は、ＩｓＴｙｐｅフィールド１２０８、ＷａｓＴｙｐｅフィールド１２１０、およびＴｒｅａｔＡｓフィールド１２１２を含むことができる。プロパティバッグ１２２０は、エントリ１２２２〜１２３０を含み、サブプロパティバッグ１２４０は、エントリ１２４２〜１２４８を含む。
【００９２】
図１０を参照すると、ブロック１０１０について上記で述べたように、プロパティバッグ１２２０にオブジェクト用のエントリ（例えばエントリ１２２２）が作成される。その後、このエントリに関する各フィールドが、オブジェクトに関する情報を使用して更新される。例えば、オブジェクトの名前（例えば「ＥｍｐｌｏｙｅｅＮａｍｅ」）が名前フィールド１２０２に入力される。プロパティの値（例えば２８７３１）が値フィールド１２０４に入力される。オブジェクトの型（例えば「Ｉｎｔ」）が型フィールド１２０６に入力される。一実施形態では、名前フィールドはハッシュテーブル用のキーとすることができる。処理はブロック１０１２へと進む。
【００９３】
ブロック１０１２では、オブジェクトが直列化される。直接の直列化は、基礎となるコンポーネントフレームワークによって、あるいは基本型用に指定されたコード、またはその他によって提供される機構を介して行うことができる。オブジェクトの直列化処理は、その基本型に依存する。各基本型は、それ自体の特別な直列化処理を有する。一実施形態において、取決め済みリスト内で特別な直列化処理は識別される。この実施形態において、取決め済みリストは、リスト内の各々の取決め済み基本型に関する特別な直列化処理への参照を含む。一実施形態において、直接の直列化は、オブジェクトをＸＭＬに変換する。しかしながら直接の直列化は、添付の特許請求の範囲から逸脱することなしに、オブジェクトをＸＭＬ以外のフォーマットに変換することができる。特別な直列化処理の結果は、直列化されたオブジェクト内に格納される。
【００９４】
意思決定ブロック１００８に戻り、オブジェクトが取決め済み基本型の１つとして識別されないことが決定された場合、処理はブロック１０１４へと進む。ブロック１０１４において、プロパティバッグ型は、型フィールド１２０６に入力される。その後このプロパティバッグ型は、ブロック１０１６で作成されたサブプロパティバッグ（例えばサブプロパティバッグ１２４０）を参照する。
【００９５】
ブロック１０１６において、サブプロパティバッグ（例えばサブプロパティバッグ１２４０）は作成される。したがって、サブプロパティバッグの追加レベルを作成することによって、プロパティバッグツリーが形成される。サブプロパティバッグは、プロパティバッグ用に定義されたフィールドと同じフィールドを有する。このサブプロパティバッグは、プロパティバッグの階層ツリーで他のレベルを作成する、１つまたは複数のサブプロパティバッグ用のエントリも有することができる。処理はブロック１０２０へと進む。
【００９６】
ブロック１０２０において、再帰的性質の直列化処理が図示されている。直列化処理は、オブジェクト内で所望の各プロパティを直列化することに焦点を合わせている。一般的に、所望のプロパティは、公開として指定されるプロパティである。しかしながら、場合によっては、隠しプロパティおよび他のプロパティを所望のプロパティとして直列化することもできる。ブロック１０２２〜１０３２は様々な順番で実行可能であり、場合によっては、オプションで１つまたは複数のブロック（例えばブロック１０３２）を実行することができる。次に、ブロック１０２２〜１０３２の各々についてさらに説明する。
【００９７】
ブロック１０２２において、所望のプロパティの型が識別される。これはブロック１００６を参照しながら上記で説明した反映を介して、再度行われる。
【００９８】
ブロック１０２４において、現在のプロパティバッグ（例えばサブプロパティバッグ）へのエントリは、そのプロパティに追加される。
【００９９】
ブロック１０２６において、所望のプロパティに関連付けられたエントリ内のフィールドが設定される。フィールドは、ブロック１０１０に関して上記で説明したように設定されるが、プロパティバッグではなくサブプロパティバッグに設定される。例えば、図１２に示されたサブプロパティバッグ１２４０内のエントリ１２４２のフィールドは、プロパティ（オブジェクト）に関連付けられた情報を使用して更新される。
【０１００】
ブロック１０２８において、所望のプロパティが取決め済み基本型の１つである場合、プロパティは、ブロック１０１２に関して上記で説明されたように直接直列化される。
【０１０１】
ブロック１０３０において、所望のプロパティが取決め済み基本型の１つでない場合、ブロック１０１４および１０２０は、再帰的に実行される。
【０１０２】
この再帰的な処理により、プロパティバッグの階層ツリーは管理が困難になる可能性がある。したがって、直列化処理９００を制限することが望ましい。直列化処理を制限するための実施形態を、ブロック１０３２に示す。これは、オプションで実行することができる。階層ツリーをカリング（ｃｕｌｌｉｎｇ）するためのいくつかの実施形態がある。一実施形態において、階層ツリーの所定の深さを指定するポリシーを設定することができる。例えば、所定の深さが２に設定された場合、直列化処理の再帰的性質は、プロパティバッグから参照された１つまたは複数のサブプロパティバッグを作成した後に停止する。直列化処理９００は、それ以上サブプロパティバッグ内でのオブジェクトの分解を進めることはない。したがって、これらのサブプロパティバッグは、プロパティバッグとして直列化され、直列化されたオブジェクト内に含められる。
【０１０３】
他の実施形態において、リモートエージェントは、直列化に先立ち、指定されなかったプロパティを除去する「ピック」処理を介してオブジェクトを実行する。例示的な構文は、＞Ｒｃｍｄ ｍａｃｈｉｎｅ：ＲｅｍｏｔｅＳｅｒｖｅｒ Ｇｅｔ／ＤＢ｜Ｐｉｃｋ Ｎａｍｅ，Ｂｉｒｔｈｄａｔｅである。その後、直列化の間に、指定されたプロパティ（例えばＮａｍｅおよびＢｉｒｔｈｄａｔｅ）が所望のプロパティとなり、前述のように直列化される。ピック処理は、あらゆるシステムで使用できる他のコマンドレットとすることができる。ピック処理でプロパティを明示的に指定する欠点の１つが、ピックリストを毎回指定しなければならないこと、およびそれらを選び出すために所望のプロパティを知らなければならないことである。
【０１０４】
他の実施形態において、ブロック８３２は、プロパティ設定機構を使用することができる。プロパティ設定機構は、プロパティ集合に関して名前を定義できるようにするものである。その後、管理者は、所望のプロパティ集合を取得するために、コマンドレットと共にプロパティ設定名を指定することができる。プロパティ集合は、様々な方法で定義することができる。１つの方法には、「？」などの所定のパラメータをコマンドレット用の入力パラメータとして入力することができる。予め定義されたパラメータを認識すると、オペレーティング環境は、オブジェクトのすべてのプロパティをリスト表示することができる。リストは、管理者が所望のプロパティにチェックを入れ（例えば「クリックオン」）、プロパティ集合に命名することができるＧＵＩとすることができる。その後、プロパティ集合情報は、拡張メタデータに格納される。例えば、プロパティ集合は「ｐｅｒｆｏｒｍａｎｃｅ」と命名することができる。その後、各オブジェクトは、そのプロパティのいずれをこのｐｅｒｆｏｒｍａｎｃｅプロパティ集合に含めるべきであるかを識別することになる。したがって管理者は、プロパティの名前を知る必要がなく、所望のプロパティ集合の名前のみを知っていればよいことになる。「ｄｅｆａｕｌｔ」と命名されたプロパティ集合は、所望のプロパティがオブジェクトを直列化することを指定する。その後管理者は、直列化が必要な場合にｄｅｆａｕｌｔプロパティを指定することができる。
【０１０５】
プロパティバッグ階層ツリーを制限する他の方法は、ある種の型のみをサポートすること、およびある種の型から導出された型を強制的にその型に合致させることによるものである。一実施形態において、オブジェクト階層は、その親を識別するために各オブジェクトを反映することによって「ウォークダウン（ｗａｌｋ ｄｏｗｎ）」される。ある種のオブジェクトに関して、それが基本型から導出されたものである場合、そのオブジェクトは、強制的にその親型となる。例えば、ハッシュテーブルオブジェクトはＩｄｉｃｔｉｏｎａｒｙオブジェクトであり、これは基本オブジェクトから導出するＩＥｎｕｍｂｅｒａｂｌｅオブジェクトである。直列化処理は、ハッシュテーブルオブジェクトをＩＥｎｕｍｂｅｒａｂｌｅオブジェクトとして取り扱うことができる。この方法では、直列化処理はオブジェクト階層内の所定のレベルのオブジェクトを完全にサポートするが、オブジェクト階層内の他の型のオブジェクトは選択された型に強制的に合致させる。実際のところ、たとえオリジナルのオブジェクト型が転送されない場合であっても、受信側コンピュータで一旦情報が取得されると、受信側コンピュータはそこで処理（キーの作成など）を実行し、必要であればオリジナルオブジェクトを取得することができる。
【０１０６】
直列化処理９００がいったん完了すると、直列化オブジェクトならびに他の情報が組み合わされて、要求側エンティティに送信される要求パッケージを形成する。
【０１０７】
プロパティバッグおよびサブプロパティバッグは、ＩｓＴｙｐｅフィールド１２０８、ＷａｓＴｙｐｅフィールド１２１０、またはＴｒｅａｔＡｓフィールド１２１２などの直列化処理中に設定される追加のフィールドを有することができる。これらの型は、非直列化処理９１０時に使用される。ＩｓＴｙｐｅフィールド１２０８は、オブジェクトの型を識別する。しかしながらオブジェクトが直列化された場合、オブジェクトのＩｓＴｙｐｅフィールド１２０８は「ＮＵＬＬ」となる。ＷａｓＴｙｐｅフィールド１２１０は、プロパティが以前に変更した型を識別する。非直列化フィールド９１０は、この情報からオブジェクトの発生元を識別することができるが、オブジェクトが現在いくつのプロパティを有するかを知ることはできない。例えば、オブジェクトを直列化するときにプロパティ集合またはピック処理が使用された場合、すべてではなく特定のプロパティのみが直列化された。ＴｒｅａｔＡｓフィールド１２１０は、ある型を識別し、その型に関連付けられたプロパティが使用可能であることを保証する。例えば、前述のプロパティ集合の例を使用して、新しいオブジェクト型を「ＳＱＬＩｎｆｏＰｅｒｓｏｎａｌ」として定義することができる。この新しい型は、自宅住所、自宅電話番号、およびその他などの、オブジェクトに関連付けられた指定されたプロパティが使用可能であることを保証する。ＴｒｅａｔＡｓとしての資格を与えるのに必要なすべてのプロパティを含めるのに十分なプロパティが指定されると、直列化処理９００は、ＴｒｅａｔＡｓフィールド１２１０の下に正しい型を入力することになる。
【０１０８】
図１１は、図８に示されたコマンドレットの処理で使用するのに好適なオブジェクトを非直列化するための例示的な処理を示す論理流れ図である。一般に、送信されたオブジェクトの非直列化は、直列化処理の逆オペレーションを実行する。処理はブロック１１０２で始まり、送信されるデータ内でプロパティバッグ標識が識別される。一実施形態において、識別子は、ＸＭＬドキュメント内の一要素とすることができる。処理はブロック１１０４へと進む。
【０１０９】
ブロック１１０４において、送信されるデータ内に含まれる情報が読み込まれるプロパティバッグオブジェクトが作成される。
【０１１０】
ブロック１１０６において、プロパティバッグオブジェクト用の型プロパティが設定される。この型プロパティは、拡張型マネージャが必要に応じてプロパティバッグを処理できるように、拡張型マネージャに通知する。
【０１１１】
ブロック１１０８において、送信されるデータ内で識別されプロパティバッグに関連付けられた各要素が処理される。ブロック１１１０では、プロパティバッグ内のエントリが作成される。ブロック１１１２において、プロパティバッグ内のフィールドが読み込まれる。処理は意思決定ブロック１１１４へと進む。
【０１１２】
意思決定ブロック１１１４において、送信されるデータ内に他のプロパティバッグを定義するか否かが決定される。送信されるデータ内に他のプロパティバッグが定義される場合、処理は、送信されるデータがいかなる他のプロパティバッグも含まなくなるまで、ブロック１１０２〜１１０８を一巡して元に戻る。
【０１１３】
しかしながら、いかなる他のプロパティバッグも含まなくなると、処理はブロック１１２０〜１１４０へと進む。一旦プロパティバッグの階層ツリーが作成されると、その後の処理について各プロパティバッグが再検討される。
【０１１４】
ブロック１１２０において、プロパティバッグの型プロパティが基本型の１つである場合、非直列化処理は、識別された型のオブジェクトをインスタンス化し（ブロック１１２２）、オブジェクトのプロパティを読み込む（ブロック１１２４）。
【０１１５】
ブロック１１３０において、プロパティバッグのＴｒｅａｔＡｓ属性がある型を指定する場合、指定された型のオブジェクトはインスタンス化され（ブロック１１３２）、オブジェクトのプロパティが読み込まれる（１１３４）。ＴｒｅａｔＡｓ属性で指定される型は、基本型の１つである。
【０１１６】
ブロック１１４０において、基本型ではない残りの各々のプロパティバッグに関し、プロパティバッグ内で識別された各オブジェクトは、インスタンス化され（ブロック１１４２）、読み込まれる（ブロック１１４４）。
【０１１７】
したがって、図に示すように、リモートコンピュータで作成されたオリジナルオブジェクトが基本型である場合、送信されるデータには最小限の情報が含まれる。これは、１つのレベルしかない階層ツリーと一致する。送信されるデータには、プロパティの名前／値のペアが含まれるが、いずれの実行可能コードも含まれない。しかしながら、一旦要求側コンピュータが送信されるデータを受信し、その型を認識すると、その型のオブジェクトがインスタンス化され、オリジナルオブジェクトによって提供されたメソッドおよび機能を有することになる。この形式では、悪意あるコードは要求側コンピュータに送信されず、要求側コンピュータによって実行されない。代わりに、オブジェクトに関する無害な情報が要求側コンピュータに送信される。
【０１１８】
図１３は、図９に示されたオブジェクトを直列化するための処理と共に使用するのに好適なプロトコルを取り決めるための例示的な処理を示す論理流れ図である。ある種のオブジェクトに関して、たとえ特定のパラメータの直列化を制限するか、または階層ツリーの深さを指定しても、２つのコンピュータ間で転送される情報はかなりの量である。したがって、伝送に必要な情報量を制限する追加の取決め機構を提供する。前述のように、階層ツリーの複雑さは取り決められる基本型の数に依存する。多数の取り決められた基本型が知られている場合、階層ツリーは複雑でなくなり、最終的には要求側コンピュータに送信される情報が少なくなる。基本型を指定するプロパティバッグ内の任意のエントリについて、要求側コンピュータで「生」オブジェクトを作成するための最低限の情報しか転送されない。したがって、より多くのオブジェクトを収容するために、基本型のリストに指定される基本型の数を増やすことができることが想像される。しかしながら本方法は、この方法を使用するための人為的な制約または要件をソフトウェア開発者に課すものではない。例えば何らかの従来の環境では、適切に動作するためにどちらのコンピュータも同じバージョンで更新しなければならない。この従来の環境では、１台のコンピュータがどのコンピュータと通信するかを指定し、通信を行うための準拠事項を他のコンピュータに強制した。これに対して、オブジェクトを転送する本方法は、コンピュータが依然として互いに通信可能でありながら、互いに独立して更新できるようにする、プロトコル取決め方法を提供する。
【０１１９】
プロトコル取決め処理１３００は、ブロック１３０２で始まる。ブロック１３０２では、クライアントのバージョン番号が受信される。クライアントのバージョン番号は、クライアント（例えば要求側コンピュータ）が使用可能な基本型のリストの最新バージョンを識別する。処理は意思決定ブロック１３０４へと進む。
【０１２０】
意思決定ブロック１３０４では、クライアントのバージョン番号がリモートのバージョン番号と比較され、リモートのバージョン番号の方が新しいか否かが判断される。リモートのバージョン番号は、リモートサーバが使用可能な基本型のリストの最新バージョンを識別する。リモートのバージョン番号の方が新しい場合、処理はブロック１３０６へと進む。
【０１２１】
ブロック１３０６では、クライアントのバージョン番号に関連付けられた基本型のリストが直列化処理に使用される。したがって、クライアントバージョンが、直列化処理時に使用される取り決められたリストとなる。
【０１２２】
他方で、リモートのバージョン番号がクライアントバージョンよりも新しくない場合、処理はブロック１３０８へと進む。ブロック１３０８では、リモートコンピュータで使用可能な基本型の最も新しいリストが直列化処理に使用される。したがって、リモートバージョンが、直列化処理時に使用される取り決められたリストとなる。
【０１２３】
取決め処理の他の実施形態では、要求側コンピュータがサポートしている基本型をリモートコンピュータに送信することができる。その後リモートコンピュータは、テーブルをウォークスルーして、テーブル内の項目を受け入れまたは拒否することによって、どの型がサポートされるかを決定する。その後、受け入れられた型が取り決められたリストを形成する。
【０１２４】
取決め処理の他の実施形態では、要求側コンピュータが参照の集合を送信することができる。参照の集合は、ファイル名を指定することができる。したがって、指定されたファイル名内の任意の型のオブジェクトをサポートし、取り決められた基本型の１つとすることになる。
【０１２５】
以上、特定の実施および実施形態の細部について説明してきたが、こうした細部は、添付の特許請求の範囲を限定するものではなく、法的な開示の義務を果たすことを意図するものである。したがって、前述のシステムおよび方法は特許請求の範囲によって画定されるものであり、前述の特定の機能に限定されるものではない。むしろ、本システムおよび方法は、添付の特許請求の範囲の適切な範囲内にあり、同等の原理に従って適切に解釈された、その形式または修正のいずれかにおいて請求されるものである。
【技術分野】
【０００１】
本明細書に開示された主題はリモートコンピューティングシステムに関し、特に、リモート通信中にコンピュータ読取り可能オブジェクトを転送するための方法に関する。
【背景技術】
【０００２】
現在では、開発者がソフトウェアを開発する際にはオブジェクト指向プログラミングと呼ばれるプログラミング概念を利用する。オブジェクト指向プログラミングでは、コンピュータ読取り可能オブジェクト（オブジェクト）が定義される。オブジェクトはプロパティおよびメソッドを有する。プロパティは、オブジェクトに関係するデータを格納する。メソッドは、オブジェクトに関連付けられた機能を実行し、一般的にはオブジェクト内に定義されたプロパティへのインターフェースを提供する。オブジェクトを使用したプログラミングは、卓越した多様性を提供するが、異なるコンピュータ間などのリモート境界を横切ってオブジェクトを使用すると、いくつかの課題を示す。
【０００３】
課題の１つは、２つのコンピュータ間でオブジェクトを転送するための機構を決定することである。ある種の環境では、オブジェクト用の実行可能コード（メソッド）およびそのプロパティが、サーバコンピュータから要求側コンピュータに転送される。しかしながらこの解決方法は、転送された実行可能コードがファイルの削除などの不正な動作を実行した場合、要求側コンピュータにセキュリティリスクを及ぼす可能性がある。したがって、この潜在的なリスクを最小限にするための他の解決方法が開発されてきた。
【０００４】
現在の解決方法の１つが、Ｗｅｂサービス技術と呼ばれる技術である。この技術を使用する場合、オブジェクトはＸＭＬ（拡張マークアップ言語）に変換され、これが要求側コンピュータに送信される。要求側コンピュータはＸＭＬを受信すると、このＸＭＬをオブジェクトに再変換する。その後、要求側コンピュータはオブジェクトのプロパティにアクセスし、オブジェクトのメソッドを呼び出すことができる。この技術を使用する要求側コンピュータは、オブジェクトの受信元であるサーバを知ることおよび信用することが責務である。さらに、要求側コンピュータとの通信を希望するいかなるオブジェクトについても、オブジェクトを開発したソフトウェア開発者は、通信を処理するために特別なインターフェースを実施しなければならない。特別なインターフェースは、オブジェクトを転送するためにオブジェクトを直列化し、および非直列化するための機構を提供する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願第１０／４１３０５４号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
このＷｅｂサービスの解決方法は、リモート境界を横切ってオブジェクトを転送するための堅固な環境を提供するものであるが、この技術は制限が多く煩わしい。システム管理環境などの一部の環境において、ソフトウェア開発者にシステム管理タスクが監視を希望するオブジェクト用の特別なインターフェースを実装させることは、実行可能な解決方法ではない。例えば、開発者にこれらの特別なインターフェースを実装するように要求することは些細な問題ではなく、開発者は、彼ら自身の特定アプリケーション向けのオブジェクトを実施するという自分達の主要な目的から注意をそらさなければならない。したがって、多くの開発者が自分達のオブジェクト向けの特別なインターフェースを実装しないため、これらのオブジェクトにはアクセスできない。
【０００７】
したがって、ソフトウェア開発者にとってセキュアで、制限されず、かつ煩わしくない、リモート境界を横切ってオブジェクトを転送するための方法が求められている。
【課題を解決するための手段】
【０００８】
本発明は、オブジェクトのリモート通信用の機構および技法を対象とするものである。簡潔に言えば、リモート境界を横切ってコンピュータ読取り可能オブジェクトをセキュアに転送するためのシステムおよび方法が提供される。この方法は、任意の型のオブジェクトを、既知のオブジェクト型リストに基づいてサブコンポーネント階層に分解する。各サブコンポーネントは、既知のオブジェクト型または未知のオブジェクト型のいずれかに対応する。未知のオブジェクト型は、他の階層レベルで既知のオブジェクト型にさらに分解することができる。階層内の既知のオブジェクトは、パッケージに直列化され、リモートエンティティに伝送される。リモートエンティティは、階層を再構築する。既知のオブジェクト型のいずれかに関して、リモートエンティティは、既知のオブジェクト型のうちの１つのオブジェクトをインスタンス化し、そのオブジェクトにパッケージ中で伝送された情報を読み込む（ｐｏｐｕｌａｔｅ）。分解は、階層のレベルを指定すること、直列化される既知のオブジェクトを制限する数を指定すること、または直列化するオブジェクト内のプロパティを指定することによって、制限することができる。
【図面の簡単な説明】
【０００９】
【図１】例示的な管理ツールフレームワークが実施可能な例示的なコンピューティング装置を示す図である。
【図２】例示的な管理ツールフレームワークの概要を全体として示すブロック図である。
【図３】図２に示された管理ツールフレームワークのホスト特有のコンポーネント内にあるコンポーネントを示すブロック図である。
【図４】図２に示された管理ツールフレームワークのコアエンジンコンポーネント内にあるコンポーネントを示すブロック図である。
【図５】図２に示された管理ツールフレームワーク内で使用するのに好適な例示的な拡張型マネージャを示す機能ブロック図である。
【図６】図２に示された管理ツールフレームワーク内で使用するのに好適なコマンドレットを指定するための、例示的なデータ構造である。
【図７】コマンドレットのリモート処理を実行するための、図２に示された管理ツールフレームワーク内にあるコンポーネントを示す機能ブロック図である。
【図８】コマンドレットを処理するための例示的な処理を示す論理流れ図である。
【図９】図８で使用するのに好適な直列化処理および非直列化処理の概要を示すブロック図である。
【図１０】図８に示されたコマンドレットの処理で使用するのに好適なオブジェクトを直列化するための例示的処理を示す論理流れ図である。
【図１１】図８に示されたコマンドレットの処理で使用するのに好適なオブジェクトを非直列化するための例示的処理を示す論理流れ図である。
【図１２】図１０に示された直列化処理中に生成されるプロパティバッグ階層を示すグラフ図である。
【図１３】図１０に示されたオブジェクトを直列化するための処理に関して使用するのに好適な、プロトコルを取り決めるための例示的処理を示す論理流れ図である。
【発明を実施するための形態】
【００１０】
簡潔に言えば、リモート境界を横切ってオブジェクトを転送するための本システムおよび方法は、オブジェクトを転送するためのセキュアな方法を提供する。さらに本システムおよび方法は、いかなる人工的な要件をもオブジェクトに設定するものではない。したがってソフトウェア開発者は、自分たちのオブジェクトを使用するリモート操作をサポートする場合に、いかなる負担も負わない。したがって既存のシステムとは異なり、任意のコンピュータ上または同じコンピュータ上の他の処理中の任意のオブジェクトを、リモート境界を横切って要求側処理に転送することができる。さらに、オブジェクトを転送するための本システムおよび方法は、どちらのコンピュータにも同じバーションのソフトウェアを実行させる必要がない。むしろこの方法は、２つの異なるバージョン間での通信をサポートするための機構を提供するだけでなく、リモート境界を介して転送されるデータの量も最小限にする、プロトコルネゴシエーション処理を組み込む。
【００１１】
以下の詳細な説明は、いくつかのセクションに分けられる。一般に、本システムおよび方法については、例示的な管理ツール環境との関連において説明する。しかしながら、当業者が下記の説明を読めば、本方法が添付の特許請求の範囲にも含められる他の例示的な環境でも実施可能であることを理解されよう。
【００１２】
第１のセクションでは、例示的な管理ツール環境が動作可能な例示的なコンピューティング環境について説明する。第２のセクションでは、管理ツール環境用の例示的なフレームワークについて説明する。続くセクションでは、例示的なフレームワークの個々のコンポーネントおよびこれらのコンポーネントの運用について説明する。例えば図７〜１３に関する「コマンドレットの例示的なリモート処理」のセクションでは、リモート境界を横切ってオブジェクトを転送するための例示的なシステムおよび方法について説明する。
【００１３】
（例示的なコンピューティング環境）
図１に、例示的な管理ツール環境で使用可能な例示的なコンピューティング装置を示す。非常に基本的な構成では、通常、コンピューティング装置１００は少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を含む。厳密なコンピューティング装置の構成および型に依存して、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはその２つの何らかの組合せとすることができる。システム１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を含み、プログラムデータ１０７を含むことができる。オペレーティングシステム１０６は、コンポーネント（プロパティおよびイベントを含む）、オブジェクト、継承、多相性（ｐｏｌｙｍｏｒｐｈｉｓｍ）、反映（ｒｅｆｌｅｃｔｉｏｎ）をサポートし、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎが製造する．ＮＥＴ（商標）フレームワークのそれのようなオブジェクト指向コンポーネントに基づくアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する、コンポーネントに基づくフレームワーク１２０を含む。オペレーティングシステム１０５は、コンポーネントに基づくフレームワーク１２０と対話して管理ツール（図示せず）の開発をサポートする管理ツールフレームワーク２００も含む。この基本的な構成が図１に示されており、それらコンポーネントは破線１０８で囲まれている。
【００１４】
コンピューティング装置１００は、追加の特徴または機能を有することができる。例えばコンピューティング装置１００は、例えば磁気ディスク、光ディスク、またはテープなどの（取り外し可能および／または固定の）追加のデータ記憶装置を含むこともできる。こうした追加の記憶は、図１では取り外し可能な記憶１０９および固定の記憶１１０によって示されている。コンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性および不揮発性、取り外し可能および固定の媒体を含むことができる。システムメモリ１０４、取り外し可能なストレージ１０９、および固定のストレージ１１０は、すべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、あるいは、所望の情報を格納するために使用可能であり、コンピューティング装置１００によってアクセス可能な任意の他の媒体が含まれるが、これらに限定されない。任意のこうしたコンピュータ記憶媒体は、装置１００の一部とすることができる。コンピューティング装置１００は、キーボード、マウス、ペン、音声入力装置、タッチ式入力装置、その他などの、入力装置１１２を有することもできる。ディスプレイ、スピーカ、プリンタ、その他などの出力装置１１４も含むことができる。これらの装置は当分野でよく知られているため、これ以上ここで論じる必要はない。
【００１５】
コンピューティング装置１００は、ネットワークを介するなどして、装置が他のコンピューティング装置１１８と通信できるようにする通信接続１１６を含むこともできる。通信接続１１６は、通信媒体の一例である。通信媒体は、通常、搬送波または他の移送機構などの変調データ信号中のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータによって具体化することが可能であり、任意の情報送達媒体を含む。「変調データ信号」という用語は、その特徴の１つまたは複数を、信号内の情報を符号化したような方法で設定または変更した信号を意味する。例を挙げると、通信媒体は、有線ネットワークまたはダイレクトワイヤード接続などの有線媒体と、音波、ＲＦ、赤外線、および他の無線媒体などの無線媒体とを含むが、これらに限定されるものではない。本明細書で使用されるコンピュータ読取り可能な媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００１６】
（例示的な管理ツールフレームワーク）
図２に、例示的な管理ツールフレームワーク２００の概要を一般的に示す。管理ツールフレームワーク２００は、１つまたは複数のホストコンポーネント２０２、ホスト特有のコンポーネント２０４、ホストに依存しないコンポーネント２０６、およびハンドラコンポーネント２０８を含む。ホストに依存しないコンポーネント２０６は、他のそれぞれのコンポーネント（すなわち、ホストコンポーネント２０２、ホスト特有のコンポーネント２０４、およびハンドラコンポーネント２０８）と通信することができる。これらそれぞれのコンポーネントについては以下で簡単に説明し、必要に応じて後続のセクションでさらに詳細に説明する。
【００１７】
（ホストコンポーネント）
ホストコンポーネント２０２は、関連するアプリケーション向けの自動化機能をユーザまたは他のプログラムに公開する、１つまたは複数のホストプログラム（例えばホストプログラム２１０〜２１４）を含む。各ホストプログラム２１０〜２１４は、コマンド行、グラフィカルユーザインターフェース（ＧＵＩ）、音声認識インターフェース、アプリケーションプログラミングインターフェース（ＡＰＩ）、記述言語、Ｗｅｂサービス、およびその他を介するなどの、それ自体の特定のスタイルで、これらの自動化機能を公開することができる。しかしながら、ホストプログラム２１０〜２１４はそれぞれ、管理ツールフレームワークによって提供された機構を介して、この１つまたは複数の自動化機能を公開する。
【００１８】
この例では、機構は、コマンドレット（ｃｍｄｌｅｔ）を使用して、関連するホストプログラム２１０〜２１４のユーザに対して管理ツール機能を表面化させる。さらにこの機構は、ホストが使用可能にしたインターフェース群を用いて、対応するホストプログラム２１０〜２１４に関連付けられたアプリケーションに管理ツール環境を埋め込む。以下の考察全体を通じて、「コマンドレット」という用語は例示的な管理ツール環境内で使用されるコマンドを表す。
【００１９】
コマンドレットは、従来の管理環境におけるコマンドに対応する。しかしながらコマンドレットは、これら従来のコマンドとはまったく異なる。例えばコマンドレットは、解析、データの妥当性検査、エラー報告などの管理ツールフレームワークが提供する共通の機能を利用することができるので、通常、対応するコマンドよりもサイズが小さい。こうした共通の機能は、１回の実施毎にテストすることができる。そのため、管理ツールフレームワーク全体を通じてコマンドレットを使用すると、アプリケーション特有の機能に関連付けられた開発およびテスト費用を、従来の環境に比べて非常に低く抑えることができる。
【００２０】
さらに従来の環境とは対照的に、コマンドレットはスタンドアロン型の実行可能プログラムである必要がない。むしろコマンドレットは、管理ツールフレームワーク内の同じ処理で実行することができる。これによってコマンドレットは、互いの間で「ライブ」オブジェクトを交換することができる。この「ライブ」オブジェクトを交換できる機能によって、コマンドレットはこれらのオブジェクトに関するメソッドを直接呼び出すことができる。
【００２１】
概して各ホストプログラム２１０〜２１４は、管理ツールフレームワーク内でユーザと他方のコンポーネントとの間の対話を管理する。これらの対話は、パラメータ向けのプロンプト、エラー報告、およびその他を含むことができる。通常、各ホストプログラム２１０〜２１３は、特定のホストコマンドレット（例えばホストコマンドレット２１８）のそれ自体の集合を提供することができる。例えばホストプログラムが電子メールプログラムの場合、ホストプログラムは、メールボックスおよびメッセージと対話するホストコマンドレットを提供することができる。図２にホストプログラム２１０〜２１４を示すが、当業者であれば、ホストコンポーネント２０２が既存のまたは新規に作成されたアプリケーションに関連付けられた他のホストプログラムを含むことができることを理解されよう。これらの他のホストプログラムも、管理ツール環境によって提供される機能をそれらの関連するアプリケーションに埋め込むことになる。
【００２２】
図２に示す例では、ホストプログラムは、コンピューティング装置のハードウェア、ソフトウェア、およびネットワークコンポーネントを管理する管理ツールを作成、保存、およびオープンするための単純で一貫した管理ユーザインターフェースをユーザに提供する、管理コンソール（すなわちホストプログラム２１０）とすることができる。これらの機能を実施するために、ホストプログラム２１０は、管理ツールフレームワークの上に管理ＧＵＩを構築するためのサービスの集合を提供する。ＧＵＩの対話は、管理ツール環境によって提供されたスクリプティング機能をユーザに教示するのに役立つ、ユーザ可視（ｕｓｅｒ−ｖｉｓｉｂｌｅ）スクリプトとして公開することもできる。
【００２３】
他の例では、ホストプログラムは、コマンド行対話シェル（すなわちホストプログラム２１２）とすることができる。コマンド行対話シェルは、コマンド行の処理に影響を与えるためにシェルメタデータ２１６をコマンド行に入力できるようにするものである。
【００２４】
他の例では、ホストプログラムは、分散コンピューティング用の業界標準仕様と、プラットフォーム、プログラミング言語、およびアプリケーションを横切る相互運用性とを使用するＷｅｂサービス（すなわちホストプログラム２１４）とすることができる。図７に示す他の例では、ホストプログラムはリモートコンピュータと通信するためのリモートインターフェースを提供することができる。
【００２５】
これらの例に加えて、第三者が、それらのホストプログラムまたは他のホストプログラムと共に使用される「第三者」または「プロバイダ」インターフェースおよびプロバイダコマンドレットを作成することによって、それら自身のホストコンポーネントを追加することができる。プロバイダインターフェースは、管理ツールフレームワークがアプリケーションまたはインフラストラクチャを操作できるように、アプリケーションまたはインフラストラクチャを公開する。プロバイダコマンドレットは、ナビゲーション、診断、構成、ライフサイクル、操作、およびその他に自動化を提供する。プロバイダコマンドレットは、完全な異種集合のデータストア上で多相性（ｐｏｌｙｍｏｒｐｈｉｃ）のコマンドレット挙動を見せる。管理ツール環境は、他のコマンドレットクラスと同じ優先度で、プロバイダコマンドレット上で動作する。プロバイダコマンドレットは、他のコマンドレットと同じ機構を使用して作成される。プロバイダコマンドレットは、アプリケーションまたはインフラストラクチャの特定の機能を管理ツールフレームワークに公開する。したがって、コマンドレットを使用することによって製品開発者は、ホストコンポーネントを１つだけ作成すればよい。その後、このコンポーネントにより、彼らの製品は、多くの管理ツールで動作可能となる。例えば、例示的な管理ツール環境では、システムレベルのグラフィカルユーザインターフェースのヘルプメニューを既存のアプリケーションに統合および移植することができる。
【００２６】
（ホスト特有のコンポーネント）
ホスト特有のコンポーネント２０４は、フレームワークが実行されているプラットフォームの特性から管理ツールフレームワークを隔離するために、コンピューティングシステム（例えば図１のコンピューティング装置１００）が使用するサービスの集合を含む。したがって、各型のプラットフォームに対して、１つのホスト特有のコンポーネント群がある。ユーザは、このホスト特有のコンポーネントを使用して、異なるオペレーティングシステム上で同じ管理ツールを使用することができる。
【００２７】
次に図３を簡単に説明すると、ホスト特有のコンポーネント２０４は、インテリセンス（ｉｎｔｅｌｌｉｓｅｎｓｅ）／メタデータアクセスコンポーネント３０２、ヘルプコマンドレットコンポーネント３０４、構成／登録コンポーネント３０６、コマンドレットセットアップコンポーネント３０８、および出力インターフェースコンポーネント３０９を含むことができる。コンポーネント３０２〜３０８は、データベースストア３１４に関連付けられたデータベースストアマネージャ３１２と通信する。パーサ２２０およびスクリプトエンジン２２２は、インテリセンス／メタデータアクセスコンポーネント３０２と通信する。コアエンジン２２４は、ヘルプコマンドレットコンポーネント３０４、構成／登録コンポーネント３０６、コマンドレットセットアップコンポーネント３０８、および出力インターフェースコンポーネント３０９と通信する。出力インターフェースコンポーネント３０９は、ホストによって提供される出力コマンドレットへのインターフェースを含む。その後、これらの出力コマンドレットがホストの出力オブジェクトを呼び出して、レンダリングを実行する。ホスト特有のコンポーネント２０４は、コアエンジン２２４が、ログおよび監査機能を提供するホスト特有の（すなわちプラットフォーム特有の）サービスと通信するために使用する、ログ／監査コンポーネント３１０も含むことが可能である。
【００２８】
管理ツールフレームワークの一例では、インテリセンス／メタデータアクセスコンポーネント３０２がコマンド、パラメータ、およびパラメータ値の自動完了を提供する。ヘルプコマンドレットコンポーネント３０４は、ホストユーザインターフェースに基づいてカスタマイズされたヘルプシステムを提供する。
【００２９】
（ハンドラコンポーネント）
再度図２を参照すると、ハンドラコンポーネント２０８は、レガシーユーティリティ２３０、管理コマンドレット２３２、非管理コマンドレット２３４、リモーティング（ｒｅｍｏｔｉｎｇ）コマンドレット２３６、およびＷｅｂサービスインターフェース２３８を含む。（プラットフォームコマンドレットとも呼ばれる）管理コマンドレット２３２は、コンピューティング装置に関連付けられた構成情報を照会または操作するコマンドレットを含む。管理コマンドレット２３２は、システム型の情報を操作するものであるため、特定のプラットフォームに依存している。しかしながら各プラットフォームは、通常、他のプラットフォーム上で管理コマンドレット２３２と同様に動作する管理コマンドレット２３２を有する。例えば各プラットフォームは、システム管理属性（例えば取得／処理、設定／ＩＰアドレス）を取得および設定する管理コマンドレット２３２をサポートする。ホストに依存しないコンポーネント２０６は、ホストに依存しないコンポーネント２０６内で生成されたコマンドレットオブジェクトを介して管理コマンドレットと通信する。
【００３０】
（基本コマンドレットと呼ばれることもある）非管理コマンドレット２３４は、管理コマンドレット２３２によって提供されるオブジェクト上で他の処理をグループ化、ソート、フィルタリングを行い、および実行するコマンドレットを含む。非管理コマンドレット２３４は、パイプライン式オブジェクトに関連付けられたデータをフォーマット化し、および出力するためのコマンドレットも含むことができる。非管理コマンドレット２３４は、各プラットフォーム上で同一とすることが可能であり、コマンドレットオブジェクトを介してホストに依存しないコンポーネント２０６と対話するユーティリティ群を提供する。非管理コマンドレット２３４とホストに依存しないコンポーネント２０６との間の対話により、オブジェク上での反映が可能になり、それらの（オブジェクト）型に依存しない反映されたオブジェクト上での処理が可能になる。したがってこれらのユーティリティは、開発者が非管理コマンドレットをいったん作成すると、コンピューティングシステム上でサポートされているすべてのクラスのオブジェクトを横切ってそれらの非管理コマンドレットを適用できるようにする。従来開発者は、第１に、処理されることになるデータのフォーマットを理解した後、そのデータのみを処理するためにアプリケーションを作成しなければならなかった。したがって従来のアプリケーションは、非常に限られた範囲のデータしか処理することができなかった。
【００３１】
レガシーユーティリティ２３０は、ｃｍｄ．ｅｘｅの下で動作するｗｉｎ３２実行可能プログラムなどの、既存の実行可能プログラムを含む。各レガシーユーティリティ２３０は、オブジェクトフレームワーク内のオブジェクトの一種である、テキストストリーム（すなわち標準入力（ｓｔｄｉｎ）および標準出力（ｓｔｄｏｕｔ））を使用する管理ツールフレームワークと通信する。レガシーユーティリティ２３０は、テキストストリームを利用するので、管理ツールフレームワークによって提供される反映に基づく操作は使用不可能である。レガシーユーティリティ２３０は、管理ツールフレームワークとは異なる処理で実行する。図示されてはいないが、他のコマンドレットも処理外で操作可能である。
【００３２】
リモーティングコマンドレット２３６は、Ｗｅｂサービスインターフェース２３８と組み合わせて、インターネットまたはイントラネット（例えば図２に示されたインターネット／イントラネット２４０）などの通信媒体を介して、他のコンピューティング装置上の対話型およびプログラムに従った管理ツール環境にアクセスするためのリモーティング機構を提供する。管理ツールフレームワークの一例では、リモーティング機構は、複数の独立した制御ドメインに及ぶインフラストラクチャに依存する連合サービスをサポートする。リモーティング機構は、スクリプトがリモートコンピューティング装置上で実行できるようにするものである。スクリプトは、単一または複数のリモートシステム上で実行可能である。スクリプトの結果は、個々のスクリプトがそれぞれ完了したときに処理するか、または集約して、様々なコンピューティング装置上のすべてのスクリプトが完了した後でまとめて処理することが可能である。
【００３３】
例えば、ホストコンポーネント２０２の１つとして示されているＷｅｂサービス２１４は、リモートエージェントとすることができる。リモートエージェントは、対象のシステムにおけるパーサおよび管理ツールフレームワークへのリモートコマンド要求の送信を処理する。リモーティングコマンドレットは、リモートエージェントへアクセスするリモートクライアントとして働く。リモートエージェントおよびリモーティングコマンドレットは、解析済みストリームを介して通信する。この解析済みストリームをプロトコル層で保護するか、または解析済みストリームを追加のコマンドレットを使用して暗号化した後復号することができる。リモートコマンドレットを処理し、およびリモート処理間でオブジェクトを転送する例示的なコンポーネントについては図７に示しおり、下記の「コマンドレットの例示的リモート処理」と題するセクションで説明する。
【００３４】
（ホストに依存しないコンポーネント）
ホストに依存しないコンポーネント２０６は、パーサ２２０、スクリプトエンジン２２２、およびコアエンジン２２４を含む。ホストに依存しないコンポーネント２０６は、複数のコマンドレットをグループ化し、コマンドレットのオペレーションを調整し、他のリソース、セッション、およびジョブのコマンドレットとの対話を調整する機構およびサービスを提供する。
【００３５】
（例示的なパーサ）
パーサ２２０は、様々なホストプログラムからの入力要求を受信し、およびその入力要求をコアエンジン２２４内などの管理ツールフレームワーク全体を通じて使用される均一なコマンドレットオブジェクトにマッピングする機構を提供する。さらにパーサ２２０は、受信した入力に基づくデータ処理を実行することもできる。本管理ツールフレームワークのパーサ２２０は、同じ機能に関して異なる言語または構文をユーザに容易に公開する機能を提供する。例えば、パーサ２２０は入力要求を解釈する責務を負うものであるため、予想される入力構文に影響を与えるパーサ２２０内のコードの変更は、本質的に管理ツールフレームワークのそれぞれのユーザに影響を与えることになる。したがってシステム管理者は、異なる構文をサポートする異なるコンピューティング装置上に異なるパーサを提供することができる。しかしながら、同じパーサを使用して作業を行う各ユーザは、各コマンドレットについて一貫した構文を体験することになる。これに対して従来の環境では、各コマンドはそれ自体の構文を実施していた。したがって何千ものコマンドがある場合、いくつかの異なる構文をサポートするそれぞれの環境では、通常、それらの多くが互いに一貫していなかった。
【００３６】
（例示的なスクリプトエンジン）
スクリプトエンジン２２２は、スクリプトを使用して複数のコマンドレットを互いに結合するための機構およびサービスを提供する。スクリプトとは、厳密な継承規則の下でセッション状態を共有するコマンド行の集約である。スクリプト内の複数のコマンド行は、入力要求内に提供された構文に基づいて、同期的または非同期的のいずれかで実行することができる。スクリプトエンジン２２２は、ループまたは条件節などの制御構造を処理し、およびスクリプト内の変数を処理する機能を有する。さらにスクリプトエンジンは、セッション状態を管理し、ポリシー（図示せず）に基づいてセッションデータへのアクセスをコマンドレットに与える。
【００３７】
（例示的なコアエンジン）
コアエンジン２２４は、パーサ２２０によって識別されたコマンドレットを処理する責務を負う。次に図４を簡単に説明すると、管理ツールフレームワーク２００内の例示的なコアエンジン２２４が示されている。例示的なコアエンジン２２４は、パイプラインプロセッサ４０２、ローダ４０４、メタデータプロセッサ４０６、エラーおよびイベントハンドラ４０８、セッションマネージャ４１０、および拡張型マネージャ４１２を含む。
【００３８】
（例示的なメタデータプロセッサ）
メタデータプロセッサ４０６は、メタデータにアクセスし、図３に示されたデータベースストア３１４などのメタデータストア内にメタデータを格納するように構成される。メタデータは、コマンド行を介して、コマンドレットクラス定義内において、およびその他で供給可能である。管理ツールフレームワーク２００内の異なるコンポーネントは、それら自体の処理を実行中にメタデータを要求することができる。例えばパーサ２０２は、メタデータを要求して、コマンド行に供給されたパラメータの妥当性を検査することができる。
【００３９】
（例示的なエラーおよびイベントプロセッサ）
エラーおよびイベントプロセッサ４０８は、コマンド行の処理中に発生した各エラーに関する情報を格納するために、エラーオブジェクトを提供する。本管理ツールフレームワークに特に好適な１つの特定エラーおよびイベントプロセッサに関する追加の情報については、「System and Method for Persisting Error Information in a Command Line Environment」という名称の特許文献１を参照されたい。
【００４０】
（例示的なセッションマネージャ）
セッションマネージャ４１０は、管理ツールフレームワーク２００内の他のコンポーネントにセッションおよび状態情報を供給する。セッションマネージャによって管理される状態情報には、任意のコマンドレット、ホスト、またはコアエンジンがプログラミングインターフェースを介してアクセスすることができる。これらのプログラミングインターフェースは、状態情報の作成、修正、および削除が可能である。
【００４１】
（例示的なパイプラインプロセッサおよびローダ）
ローダ４０４は、パイプラインプロセッサ４０２がコマンドレットを実行するために、メモリ内に各コマンドレットを読み込むように構成される。パイプラインプロセッサ４０２は、コマンドレットプロセッサ４２０およびコマンドレットマネージャ４２２を含む。コマンドレットプロセッサ４２０は、個々のコマンドレットをディスパッチする。コマンドレットがリモートまたはリモートマシン群上での実行を要求する場合、コマンドレットプロセッサ４２０は、図２に示されたリモーティングコマンドレット２３６を使用して実行を調整する。コマンドレットマネージャ４２２は、コマンドレットの集合体の実行を処理する。コマンドレットマネージャ４２２、コマンドレットプロセッサ４２０、およびスクリプトエンジン２２２（図２）は互いに通信して、ホストプログラム２１０〜２１４から受信した入力に関する処理を実行する。通信は、本来反復的なものとすることができる。例えば、ホストプログラムがスクリプトを提供する場合、スクリプトは、それ自体がスクリプトの可能性があるコマンドレットマネージャ４２２を呼び出してコマンドレットを実行する。その後スクリプトは、スクリプトエンジン２２２によって実行することができる。
【００４２】
（例示的な拡張型マネージャ）
前述のように、管理ツールフレームワークは、オブジェクト上での反映を可能にし、それらの（オブジェクト）型に依存しない反映されたオブジェクト上での処理を可能にする、ユーティリティ群を提供する。管理ツールフレームワーク２００は、コンピューティングシステム上のコンポーネントフレームワーク（図１のコンポーネントフレームワーク１２０）と対話して、この反映を実行する。当業者であれば、反映は、オブジェクトを照会し、およびそのオブジェクトの型を取得する機能、ならびにその後、そのオブジェクト型に関連付けられた様々なオブジェクトおよびプロパティを反映して他のオブジェクトおよび／または所望の値を取得する機能を提供することを理解されよう。
【００４３】
反映は、オブジェクトに関する多くの量の情報を管理ツールフレームワーク２００に提供するが、従来の反映は、オブジェクトの型に焦点を合わせる。例えば、データベースのデータテーブルが反映される場合、戻される情報は、データテーブルが列プロパティおよび行プロパティという２つのプロパティを有することである。これら２つのプロパティは、データテーブル内の「オブジェクト」に関する詳細を十分に提供するものではない。拡張可能マークアップ言語（ＸＭＬ）および他のオブジェクトで反映が使用される場合、同様の問題が生じる。
【００４４】
これに対して拡張型マネージャ４１２は、オブジェクトの型以外の型の用法に焦点を合わせる。したがってこれを焦点とする場合、拡張型マネージャは、オブジェクトを使用して必要な情報が取得できるか否かを判定する。引き続き上記のデータテーブルの例を用いると、データテーブルが列プロパティを有し、行プロパティには特に関心が寄せられないことが分かる。しかしながら、用法に焦点を当てることによって、拡張型マネージャは各行を「オブジェクト」に関連付け、各列をその「オブジェクト」の「プロパティ」に関連付ける。したがって拡張型マネージャ４１２は、任意の型の精密に解析可能な入力から「オブジェクト」を作成するための機構を提供する。このように実行する場合、拡張型マネージャ４１２は、コンポーネントベースのフレームワーク１２０によって提供される反映機能を補い、「反映」を任意の型の精密に解析可能な入力まで拡張する。
【００４５】
概して拡張型マネージャは、精密に解析可能な入力（図示せず）にアクセスし、この精密に解析可能な入力を要求されたデータ型と相関させるように構成される。その後、拡張型マネージャ４１２は、要求された情報をパイプラインプロセッサ４０２またはパーサ２２０などの要求側コンポーネントに提供する。以下の考察では、精密に解析可能な入力は、プロパティおよび値を見分けることが可能な入力として定義される。精密に解析可能な入力の例には、Ｗｉｎｄｏｗｓ（登録商標）Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）入力、ＡｃｔｉｖｅＸ Ｄａｔａ Ｏｂｊｅｃｔ（ＡＤＯ）入力、拡張可能マークアップ言語（ＸＭＬ）入力、および．ＮＥＴオブジェクトなどのオブジェクト入力が含まれる。他の精密に解析可能な入力は、第三者データフォーマットを含むことができる。
【００４６】
図５は、管理ツールフレームワーク内で使用するための例示的な拡張型マネージャを示す機能ブロック図である。説明のために、拡張型マネージャによって提供される機能（丸で囲まれた数字「３」で示す）と、従来の密接に連結したシステムによって提供される機能（丸で囲まれた数字「１」で示す）および反映システムによって提供される機能（丸で囲まれた数字「２」で示す）とが対比される。従来の密接に連結したシステムでは、アプリケーション中で発呼者５０２は、オブジェクトＡ内の情報（例えばプロパティＰ１およびＰ２、メソッドＭ１およびＭ２）に直接アクセスする。前述のように発呼者５０２は、コンパイル時にオブジェクトＡによって提供されるプロパティ（例えばプロパティＰ１およびＰ２）およびメソッド（例えばメソッドＭ１およびＭ２）を、予め知っていなければならない。反映システムでは、（いずれのデータ型にも依存しない）汎用コード（ｇｅｎｅｒｉｃ ｃｏｄｅ）５２０がシステム５０８に照会し、このシステムが要求されたオブジェクトに関する反映５１０を実行し、オブジェクト（例えばオブジェクトＡ）に関する情報（例えばプロパティＰ１およびＰ２、メソッドＭ１およびＭ２）を汎用コード５２０に戻す。オブジェクトＡには図示されていないが、戻される情報は、ベンダ、ファイル、日付、およびその他などの追加情報を含むことができる。したがって汎用コード５２０は、反映を介して、密接に連結したシステムが提供する情報と少なくとも同じ情報を取得する。反映システムは、発呼者５０２がシステムに照会して、パラメータに関するいかなる事前の知識もなしに追加情報を取得できるようにするものでもある。
【００４７】
密接に連結したシステムおよび反映システムのどちらでも、新しいデータ型を容易にオペレーティング環境に組み込むことはできない。例えば密接に連結したシステムでは、一度オペレーティング環境が送達されると、そのオペレーティング環境が新しいデータ型を組み込むためには、その新しいデータ型をサポートするように再構築しなければならなくなるため、新しいデータ型を組み込むことはできない。同様に、反映システムでは、各オブジェクトクラス向けのメタデータが固定される。したがって、通常、新しいデータ型は組み込まれない。
【００４８】
しかしながら、本拡張型マネージャの場合、新しいデータ型をオペレーティングシステムに組み込むことができる。汎用コード５２０は、拡張型マネージャ５２２を使用して要求されたオブジェクトを反映し、第三者オブジェクト（例えばオブジェクトＡ’およびＢ）、セマンティック（ｓｅｍａｎｔｉｃ）Ｗｅｂ５３２、オントロジ（ｏｎｔｏｌｏｇｙ）サービス５３４、およびその他などの、様々な外部ソースによって提供される拡張データ型（例えばオブジェクトＡ’）を取得することができる。図に示されるように、第三者オブジェクトは既存のオブジェクト（例えばオブジェクトＡ’）を拡張するか、またはまったく新しいオブジェクト（例えばオブジェクトＢ）を作成することができる。
【００４９】
これら外部ソースは各々、それら固有の構造を型メタデータ５４０内に登録し、コード５４２を提供することができる。オブジェクトが照会されると、拡張型マネージャは型メタデータ５４０を再検討し、オブジェクトが登録されているか否かを判別する。オブジェクトが型メタデータ５４０内に登録されていない場合、反映が実行される。そうでない場合、拡張された反映が実行される。コード５４２は、反映される型に関連付けられた追加のプロパティおよびメソッドを戻す。例えば、入力型がＸＭＬの場合、コード５４２は、ＸＭＬドキュメントからオブジェクトを作成する際にＸＭＬが使用される方法を記述した記述ファイルを含むことができる。したがって、型メタデータ５４０は、拡張型マネージャ４１２が様々な型の精密に解析可能な入力（例えば第三者オブジェクトＡ’およびＢ、セマンティックＷｅｂ５３２）をどのように照会して、その特定の入力型用のオブジェクトを作成するための所望のプロパティを取得するべきかを記述し、コード５４２は、これらの所望のプロパティを取得するための命令を提供する。その結果、拡張型マネージャ４１２は、すべての型のオブジェクトに関する「反映」を可能にする、間接化（ｉｎｄｉｒｅｃｔｉｏｎ）の層を提供する。この間接化の層の実施例について、リモート処理に関して以下でより詳細に説明する。この実施形態では、精密に解析可能な入力（例えば直列化オブジェクト）を使用して、特定の入力型（例えばプロパティバッグ）用のオブジェクトを作成するために所望のプロパティを取得する。その後、さらにプロパティバッグを分解して、１つまたは複数の基本型のオブジェクトを作成する。以下で説明するように、拡張型マネージャは、リモート処理間でオブジェクトを転送するための一実施形態を実行可能にし、処理間で任意の型の任意のオブジェクトを転送可能にする。
【００５０】
拡張型の提供に加えて、拡張型マネージャ４１２は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ（ｇｌｏｂｂｅｒ）機構、プロパティ集合機構、関係機構、およびその他などの、追加の照会機構も提供する。様々な技法を使用して、拡張型マネージャ向けのセマンティックを実施することができる。以下に、３つの技法を説明する。しかしながら当業者であれば、これらの技法の変形形態が使用可能であることを理解されよう。
【００５１】
一技法では、静的メソッド（例えばｇｅｔｐｒｏｐｅｒｔｙ（））を有する一連のクラスを提供することができる。オブジェクトが静的メソッドに入力され（例えばｇｅｔｐｒｏｐｅｒｔｙ（ｏｂｊｅｃｔ））、静的メソッドは結果の集合を戻す。他の技法では、オペレーティング環境が、アダプタを使用してオブジェクトを包む（ｅｎｖｅｌｏｐ）。したがって入力が供給されない。アダプタの各インスタンスは、包まれたオブジェクト上で動作し、および包まれたオブジェクト用のプロパティを戻すｇｅｔｐｒｏｐｅｒｔｙメソッドを有する。この技法を例示する擬似コードを以下に示す。
【００５２】
【表１】
【００５３】
他の技法では、アダプタクラスがオブジェクトを下位分類する。従来では、下位分類はコンパイル前に発生した。しかしながら、あるオペレーティング環境では、下位分類が動的に発生する場合がある。この種の環境でこの技法を例示する擬似コードを下記に示す。
【００５４】
【表２】
【００５５】
したがって、図５に示されるように、拡張型マネージャは開発者が新しいデータ型を作成してそのデータ型を登録できるようにし、他のアプリケーションおよびコマンドレットがこの新しいデータ型を使用できるようにする。これに対して従来の管理環境では、コンパイル時に各データ型を知っておかなければならないため、そのデータ型からインスタンス化されたオブジェクトに関連付けられたプロパティまたはメソッドに直接アクセスすることができた。したがって、過去には、管理環境によってサポートされた新しいデータ型を追加することはめったに実行されなかった。
【００５６】
図２を参照すると、概して、管理ツールフレームワーク２００は、ユーザによって入力されたコマンドの実行を調整するためのシェルに依拠せず、むしろ、機能を処理部分（例えばホストに依存しないコンポーネント２０６）と（例えばホストコマンドレットを介する）ユーザ対話部分とに分割する。さらに、本管理ツール環境は、解析およびデータの妥当性検査に必要なコードがもはや各コマンドに含まれておらず、むしろ管理ツールフレームワーク内のコンポーネント（例えばパーサ２２０）によって提供されるため、管理ツールのプログラミングがかなり簡略化される。管理ツールフレームワーク内で実行される例示的な処理について、以下で説明する。
【００５７】
（例示的オペレーション）
図６は、管理ツール環境で使用される例示的なデータ構造を示す図である。図８〜１１および１３は、管理ツール環境内での例示的な処理流れを示す図である。当業者であれば、特許請求の範囲を逸脱することなく、下記で説明するコンポーネントとは異なるコンポーネントによって、ある種の処理が実行できることを理解されよう。管理ツールフレームワークのコンポーネント内で実行される処理について説明する前に、管理ツールフレームワーク内で使用されるコマンドレット用の例示的なデータ構造について説明する。
【００５８】
（コマンドレットオブジェクト用の例示的なデータ構造）
図６は、図２に示された管理ツールフレームワーク内で使用するのに好適なコマンドレットを指定するための例示的なデータ構造である。完了すると、コマンドレットは管理コマンドレット、非管理コマンドレット、ホストコマンドレット、プロバイダコマンドレット、またはその他とすることができる。以下の考察では、システム管理者の見地に基づいたコマンドレット（すなわちプロバイダコマンドレット）の作成について説明する。しかしながら、各型のコマンドレットが同じ様式で作成され、同様の様式で動作する。コマンドレットは、Ｃ＃などの任意の言語で作成することができる。さらにコマンドレットは、記述言語などを使用して作成することができる。管理ツール環境が．ＮＥＴ Ｆｒａｍｅｗｏｒｋで動作する場合、コマンドレットは．ＮＥＴオブジェクトとすることができる。
【００５９】
プロバイダコマンドレット６００（以下、コマンドレット６００と呼ぶ）は、コマンドレットクラス６０２から導出するパブリッククラスである。コマンドレット６００は、「＜ｃｏｍｍａｎｄ ｎａｍｅ＞」の代わりに指定されるコマンドレットクラス名を含む。ソフトウェア開発者は、「ｇｅｔ／ｐｒｏｃｅｓｓ」、「ｇｅｔ／ｄｂ」、「ｆｏｒｍａｔ／ｔａｂｌｅ」、およびその他などの動詞／名詞ペア６０６をコマンドレット６００に関連付ける、コマンドレットＤｅｃｌａｒａｔｉｏｎ６０４を指定する。動詞／名詞ペア６０６は、管理ツール環境内に登録される。動詞または名詞は暗黙的な場合がある。パーサは、名前（例えばｇｅｔ／ｄｂ）を有するコマンド文字列がコマンド行上またはスクリプト内で入力として供給されたときに、コマンドレットレジストリを見てコマンドレット６００を識別する。
【００６０】
コマンドレット６００は、コマンドレットへの予測される入力パラメータ用の文法を定義する文法機構に関連付けられる。文法機構は、コマンドレットに直接的または間接的に関連付けることができる。例えばコマンドレット６００は、直接的な文法関連付けを示す。コマンドレット６００では、１つまたは複数のパブリックパラメータ（例えば、Ｎａｍｅ６３０およびＳｔａｔｅ６３２）が宣言される。各パブリックパラメータ６３０および６３２を、入力属性６３１および６３３などの１つまたは複数型の属性と関連付けることができる。入力属性６３１および６３３は、それぞれ、パブリックパラメータ６３０および６３２を読み込む方式を指定する。例えばパブリックパラメータは、コマンドのパイプライン中、コマンド行から、およびその他の、他のコマンドレットによって発信されるオブジェクトから読み込むことができる。パブリックパラメータが他のオブジェクトから読み込まれる場合、コマンドレット６００は、第１のメソッド６４０（例えばＳｔａｒｔＰｒｏｃｅｓｓｉｎｇ）および第２のメソッド６４２（例えばｐｒｏｃｅｓｓＲｅｃｏｒｄ）を含む。コアエンジンは、第１および第２のメソッド６４０および６４２を使用してコマンドレット６００の処理を指示する。例えば第１のメソッド６４０は、１回実行され、およびセットアップ機能を実行することができる。第２のメソッド６４２内のコードは、コマンドレット６００によって処理される必要がある各オブジェクト（例えばｒｅｃｏｒｄ）について実行されることができる。コマンドレット６００は、コマンドレット６００の後に終結処理する第３のメソッド（図示せず）を含むこともできる。別の方法として、ＸＭＬドキュメントなどの外部ソース内に定義されたパブリックパラメータの記述を用いて、文法機構とコマンドレットを間接的に関連付けることもできる。この外部ソース内のパラメータの記述は、コマンドレットへのオブジェクト入力の構文解析を駆動することになる。
【００６１】
したがって図６に示されるように、第２のメソッド６４２内のコードは通常極めて簡潔であり、解析コード、データの妥当性検査コードなどの従来の管理ツール環境で必要とされた機能を含まない。したがってシステム管理者は、複雑なプログラミング言語を習得することなしに複雑な管理タスクを開発することができる。
【００６２】
データ構造６００は、入力パラメータとして認識されないプライベートメンバ６５０も含むことができる。プライベートメンバ６５０は、コマンドレット内で生成されたデータを格納するために使用することができる。
【００６３】
次に、管理ツール環境内の例示的な処理の流れについて説明する。
【００６４】
（コマンドレットの例示的なリモート処理）
図７は、本発明に関して説明された機構を利用するリモートコンピューティング環境７００を全体として示す機能ブロック図である。「アドミニストレータ」７１０コンピューティングシステムおよびリモートコンピューティングシステム（以下、リモートサーバ７２０と呼ぶ）が図示されている。リモートサーバ７２０は、物理的にいずれの場所に配置することも可能であり、従業員または加入者などのエンドユーザが使用中の個々のコンピューティングシステムとすることも可能である。図７には単一のリモートサーバ７２０が示されているが、リモートコンピューティング環境７００は任意の数のリモートサーバを含むことができる。各リモートサーバは、リモートサーバ７２０を参照しながら以下で説明するような処理を実行する。
【００６５】
アドミニストレータ１１２およびリモートサーバ７２０は、図１に示されたコンピューティング装置１００などのコンピューティング装置とすることができる。アドミニストレータ１１２は、リモートサーバ７２０を保守するためにシステム管理者などによって使用される。言い換えればアドミニストレータ１１２は、リモートサーバ７２０の状況または状態を照会することおよび／またはリモートサーバ７２０を変更することが可能なコマンドおよびタスクを実行する。アドミニストレータ１１２は、図２に示された管理ツールフレームワーク２００のいくつかのコンポーネントを含むことが可能な、実行環境を含む。具体的には、アドミニストレータ１１２はリモートインターフェース７１４および基本型７１２のリストを含む。一実施形態では、基本型７１２のリストは、オブジェクトの型を列挙するための第１の列と、型に関連付けられた特定のシリアライザを参照するための第２の列との、２つの列を有するテーブルを備える。管理ツールフレームワーク２００内の他のコンポーネントを使用してコマンドレットのリモート処理を実行することもできるが、下記の考察では、「Ｒｃｍｄ ｍａｃｈｉｎｅ：ＲｅｍｏｔｅＳｅｒｖｅｒ Ｇｅｔ／ＤＢ」などのリモートコマンドレットを処理するためのアドミニストレータ１１２とリモートサーバ７２０との間の対話に焦点を合わせ、この文脈で必要に応じて他のコンポーネントの動作について説明する。さらに下記の例では、１つのコマンドレットのリモート処理を示す。しかしながら、リモートの態様はコマンドレットのパイプラインが存在する場合でも同様に等しく動作する。
【００６６】
リモートサーバ７２０はリモートエージェント７２４を含む。リモートエージェント７２４は、１つまたは複数のコマンドレットを実行するためにリモート要求に応答するコンポーネントである。さらにリモートエージェント７２４は、１つまたは複数のコマンドレットの実行の結果を取り、要求側エンティティ（例えばアドミニストレータ１１２）に戻される戻りパッケージ７３０を作成するように構成される。一実施形態では、パッケージは、実行の結果、ならびに、呼出しの日付および時刻などのメタ情報、結果の発信元である特定のリモートシステムに関する識別情報、および要求側エンティティに関する情報を含む、直列化オブジェクトの形を取る。この情報および起こり得る他の情報が戻りパッケージ７３０にまとめられ、要求側エンティティ（例えばアドミニストレータ１１２）に返送される。
【００６７】
要求側エンティティは、コンピューティングシステム上で実行中の１つの処理とすることが可能であり、リモートサーバは、同じコンピューティングシステム上で動作中の他の処理とすることが可能であることに留意されたい。この構成では、通信インターフェース７４０は、２つの処理間で通信するための当業者によく知られたシステムレベルのアプリケーションプログラミングインターフェース（ＡＰＩ）を含む。他の実施形態では、通信インターフェース７４０は、インターネットまたはイントラネットのネットワークを含む。
【００６８】
図８は、コマンドレットを実行するために処理８００によって実行可能なステップを全体として示す論理流れ図である。処理は、意思決定ブロック８０６で始まり、コマンド行などを介するなど、コマンドレットが実行のために入力されている。例えばコマンドレット「Ｒｃｍｄ ｍａｃｈｉｎｅ：ＲｅｍｏｔｅＳｅｒｖｅｒ Ｇｅｔ／ＤＢ」が入力されている場合がある。意思決定ブロック８０６において、実行がリモート境界を横切る場所を決定するために、コマンドレットを実行する予定の場所が決定される。概して、各コンピューティングシステム（例えばアドミニストレータ７２０、リモートサーバ７２０）は、１つまたは複数の処理をサポートする。各処理は少なくとも１つのプログラムまたはアプリケーションをホスティングする。さらに、１つの処理が、１つまたは複数のアプリケーションドメインをホスティングすることもできる。アプリケーションドメインは、複数のアプリケーションが依然として他のアプリケーションとは分離しながらも、同じ処理内で実行できるようにする比較的新しい機構である。アプリケーションドメインは、ランタイム環境によってアプリケーションの周囲に作成される論理的および物理的な境界である。各アプリケーションドメインは、そのそれぞれのアプリケーションの構成、セキュリティ、または安定性が、他のアプリケーションドメイン内の他のアプリケーションに影響を与えないようにする。したがってコマンドレットは、１）要求側エンティティ（例えばアドミニストレータ）のアプリケーションドメイン内、２）要求側エンティティと同じ処理の他のアプリケーションドメイン内、３）要求側エンティティ上の他の処理内、または４）リモートサーバ上、という場所で実行することができる。コマンドレットが他の処理内（＃３）またはリモートサーバ上（＃４）のいずれかで実行する場合、下記の考察ではこれを「リモート境界」を介して実行するように言及し、一般に処理境界外での実行を意味する。
【００６９】
場所を指定するために、一実施形態では、コマンドレットと共に指定されたパラメータがどの場所でコマンドレットを実行するかを識別する。例えば、パラメータ「−ｎｏｄｅ」ならびに関連するノード名は、そのノード名に関連付けられたリモートサーバ上でのコマンドレットの実行を示すことができる。パラメータ「−ｗｏｒｋｅｒｐｒｏｃｅｓｓ」は、要求側エンティティの他の処理でのコマンドレットの実行を示すことができる。パラメータ「−ａｐｐｄｏｍａｉｎ」は、同じ処理の他のアプリケーションドメイン内でのコマンドレットの実行を示すことができる。実行が、同じアプリケーションドメイン内、または同じ処理内の他のアプリケーションドメイン内で発生する場合、処理はブロック８０８で継続される。そうでない場合、処理はブロック８１８で継続される。ブロック８０８〜８１４の処理は、リモート処理を理解する上で不可欠ではないが、この処理を理解することは、コマンドレットのリモート処理をサポートするために克服された問題を理解する際の助けになる。
【００７０】
ブロック８０８では、コマンドレットに関連付けられたファイルが識別される。コマンドレットおよびその関連ファイルを、登録によって識別することができる。図６に関して上記で説明したように、ファイルはコマンドレットを実行するためのコードを含み、コマンドレットクラスに関連付けられたプロパティおよびメソッドも含む。
【００７１】
ブロック８１０において、ファイルは、現在のアプリケーションドメイン用の処理に読み込まれる。前述のように、ファイルが何らかの未知の信頼できないリモートサーバから読み込まれている場合、実行可能ファイルを要求側エンティティ上の処理にブラインドロードすることは、セキュリティリスクをもたらす。ブロック８２０〜８３４に関して説明するように、このセキュリティリスクは、リモート境界間でオブジェクトを転送するために本メソッドを利用することによって克服される。
【００７２】
ブロック８１２においてコマンドレットが実行される。実行には、コマンドレットオブジェクトを作成するためのコマンドレットクラスのインスタンス化が含まれる。コマンドレットクラスで指定された方式で、コマンドレットオブジェクト内に指定されたプロパティを取り込む。コマンドレットクラスのコードに定義されたようにオブジェクトを作成する。（パイプライン化されたコマンドの前のコマンドレットからのオブジェクトなどの）入ってくるオブジェクトが、現在のコマンドレットクラスに指定された型と合致しない場合、拡張型マネージャは、必要に応じて型を強制する（ｃｏｅｒｃｅ）ことができる。処理はブロック８１４へ進む。
【００７３】
ブロック８１４において、処理は、任意のプロパティにアクセスすることおよび任意のメソッドを呼び出すことによって、作成されたオブジェクトを操作することができる。これらの作成されたオブジェクトは、オブジェクトのメソッドが使用可能であり、および呼出し可能であるため、「ライブ」または「生」オブジェクトと呼ばれる。
【００７４】
想像できるように、ブロック８０８〜８１４において説明された処理は、コマンドレットがリモートコンピュータ上に配置された場合、あまり理想的とは言えない。リモートファイルが実行のためにローカル処理に読み込まれた場合、リモートファイルは、悪意あるコードを実行する可能性があり、これによって要求側エンティティのセキュリティを危険にさらす可能性がある。さらに管理ツール環境では、要求側エンティティ（例えばアドミニストレータ）は一般に、リモートコンピュータに関する管理情報の取得に関心がある。したがって、コマンドレットによって読み込まれるオブジェクトは、要求側エンティティ（例えばアドミニストレータ）ではなく、リモートサーバに関係する状況または他の情報を含まなければならない。
【００７５】
上述したように、従来のＷｅｂサービス環境では、クライアントは通信を希望するリモートサーバについて知ることおよびこれを信頼することの責務を負う。しかしながら上記で説明したように、特定のインターフェースをサポートするオブジェクトのみが要求側エンティティと通信できることから、これによってクライアントが通信できる相手がかなり制約される。要求側エンティティ（例えばアドミニストレータ）とリモートサーバとの間でオブジェクトを通信するための本方法は、このような制限を課さない。次にこの方法について説明する。便宜上、リモートエンティティ（例えばリモートサーバまたは別の処理）上で処理を実行するブロックは、「ドット付き」背景で示される。
【００７６】
意思決定ブロック８０６に戻り、コマンドレットが他の処理内またはリモートサーバ上で実行されることになる場合、処理はブロック８１８へ進む。ブロック８１８において、クライアントは、リモートエンティティに関連付けられたリモートエージェントとの通信を確立する。その後、リモートエージェントは、ブロック８２０〜８２４を実行し、これによって、リモートエンティティに関して実行するのではなく、ブロック８１０〜８１２に関して上記で説明した機能が実行される。しかしながらいったんコマンドレットが実行され、その関連するオブジェクトを取得すると、処理はブロック８２６へと進む。
【００７７】
ブロック８２６において、オブジェクトは、要求側エンティティ（例えばアドミニストレータ）のセキュリティが危険にさらされないような方式で直列化される。直列化処理によって、図７に示された戻りパッケージ７３０などの戻りパッケージが作成される。一般にオブジェクトの直列化は、要求側エンティティに対して有害な可能性の無い方式で、情報を直列化する。直列化処理の概要は、図９に示されており、直列化処理については、図１０に関して下記でより詳細に説明する。処理はブロック８２８へと進む。
【００７８】
ブロック８２８において、直列化されたオブジェクトがクライアントコンピュータに送信される。直列化オブジェクトの送信は、ネットワーク通信に関して知られた従来の方法を使用して実行するか、または要求側エンティティおよびリモートサーバが同じコンピュータ上にある場合、既知の処理間通信を使用することができる。処理はブロック８３０へと進む。
【００７９】
ブロック８３０において、直列化されたオブジェクトは、要求側エンティティで受信される。直列化されたオブジェクトの型は、拡張型マネージャで登録された型である。したがって、受信時に、拡張型マネージャは、直列化されたオブジェクトの型を認識する。処理は、ブロック８３２へと進む。
【００８０】
ブロック８３２において、直列化されたオブジェクトは、サブコンポーネントオブジェクトに非直列化される。簡潔に言えば、非直列化処理は、直列化されたオブジェクトを知られた基本型に分解する。非直列化処理の概要は、図９に示されており、非直列化処理については、図１１に関して下記でより詳細に説明する。処理はブロック８３４へと進む。
【００８１】
ブロック８３４において、基本型の１つであった非直列化されたオブジェクトを、オブジェクトに関連付けられたメソッドおよびプロパティが使用可能であることを意味する「生」オブジェクトとして操作することができる。基本型の１つではない非直列化されたオブジェクトは、「生」オブジェクトとして操作できない。これらのオブジェクトは「非直列化」オブジェクトと呼ばれ、オブジェクトはオブジェクトのある種のプロパティに関する情報を含むが、それらのメソッドは含まないことを意味する。
【００８２】
図９は、図８で使用するのに好適な直列化処理および非直列化処理の一般的な概要を示すブロック図である。一般に、直列化処理９００は、リモートエンティティ上で実行中のコマンドレットによって作成されたオブジェクト９０２を、階層ツリー９０４に変換する。一般に階層ツリー９０４は、サブコンポーネントに分割されたオブジェクト９０２を表すオブジェクトである。サブコンポーネントの中には、両方のエンティティ（例えば要求側エンティティおよびリモートエンティティ）によって知られたオブジェクト型のものもある。これらの知られた型は、それぞれ要求側エンティティおよびリモートエンティティの基本型７１２および７２２のリストで識別される（図７を参照のこと）。基本型７１２および７２２が同じ基本型リストを含まない場合、図１３に関して下記で詳細に説明するプロトコル取決め処理を実行して、どちらの基本型リストを使用するかを決定する。したがって、図１０に関して下記でより詳細に説明するように、階層ツリー内の各エントリは直列化され、直列化されたオブジェクト９０６に追加される。一実施形態では、直列化されたオブジェクト９０６は、ＸＭＬドキュメントを備える。この直列化されたオブジェクトは、他の情報と組み合わされて、要求側エンティティに送信される要求パッケージを形成する。
【００８３】
要求パッケージを受信すると、要求側エンティティは、直列化されたオブジェクト９０６を取り出して、非直列化処理９１０を実行する。一般に、非直列化処理９１０は、階層ツリー９０４を再構築する。階層ツリー９０４は、拡張型マネージャによって認識されたオブジェクト型の１つであるため、拡張型マネージャは、階層ツリー９０４を基本オブジェクトおよび／またはプロパティバッグオブジェクト９１２に分解する。基本オブジェクトは、機能（例えばメソッド）を有する「ライブ」（すなわち「生」）オブジェクトである。プロパティバッグオブジェクト９１２（すなわち「非直列化」オブジェクト）は、関連データを提供するが、メソッドは含まない。したがって、この概要が示すように、元来リモートエンティティ上で作成されたオブジェクト９０２は、要求側エンティティのセキュリティの危険を脅かすこと、またはオブジェクト９０２用の任意の特別なインターフェースを必要とすることなしに、複数の「生」基本オブジェクトおよび他の「非直列化された」オブジェクトとして要求側エンティティへ転送された。この非直列化処理９１０については、図１１に関してより詳細に説明する。
【００８４】
図１０は、オブジェクトを直列化するための例示的な処理９００を示す図である。前述のように、一般的な概要として、直列化処理９００は、オブジェクトおよびそのプロパティ（プロパティはオブジェクトでもある）を知られた基本型に、および場合によっては１つまたは複数のプロパティバッグに分解する。処理９００は、本来再帰的であり、（プロパティを含む）オブジェクトが基本型のうちのいずれか１つに分解されるまで、あるいは残りのオブジェクトがそれぞれ知られた基本型のリストに掲載されなくなるまで続行される。直列化処理９００が再帰的であり、管理が困難な階層ツリーを作成することができるため、処理９００は、下記で説明するいくつかの異なる技法を使用して制限することもできる。処理９００をより分かり易く説明するために、下記の考察では、「ｇｅｔ／ＤＢ」コマンドレットによって仮に作成されたオブジェクト例（例えばＳＱＬＩｎｆｏオブジェクト）を使用する。これらの従来の方式の１つを下記に示す。
【００８５】
【表３】
【００８６】
図１２は、処理９００中に作成される階層ツリーの一部を示すグラフ図である。階層ツリーは、上記に示されたＳＱＬＩｎｆｏオブジェクトの分解された部分を表し、直列化処理を説明するために図９に関して用いられる。
【００８７】
処理９００は、ブロック１００２で始まり、リモートコマンドレットによって作成されたオブジェクトが作成されている。ブロック１００２では、要求側エンティティおよびリモートエンティティが通信可能なレベルを識別するために、プロトコル取決め処理が実行される。簡潔に言えば、図１３に関して後で詳細に説明されるように、エンティティが通信するレベルは、オブジェクトを転送するために要求側エンティティに送信される情報の量を決定する。以下で説明するように、プロトコル取決め処理は、要求側エンティティおよびリモートエンティティの両方が依然として異なるバージョンを使用して互いに通信可能である一方で、それらのシステムを互いに独立してアップグレードできるようにするものである。実際のところ、これによって、リモートエンティティ上のバージョンよりも数年新しいバージョンの基本型で動作する要求側エンティティは、依然としてリモートエンティティと通信できるようにする。その逆もまた真である。したがって、数年前に出荷されたシステムを、新しい管理者コンピュータで管理することができる。取決め処理の出力は、それぞれの取り決められた基本型を識別する取決め済みリストである。通信レベルが決定されると、処理はブロック１００４へと進む。
【００８８】
ブロック１００４では、オブジェクトに関する情報を保持するためにプロパティバッグが作成される。一実施形態において、プロパティバッグは、ハッシュテーブルとして実施することができる。プロパティバッグは、管理ツール環境によってサポートされるコアデータ型である。処理はブロック１００６へと進む。
【００８９】
ブロック１００６において、オブジェクトを反映することによってオブジェクトの型が識別される。一旦型が識別されると、処理は意思決定ブロック１００８へと進む。意思決定ブロック１００８では、識別されたオブジェクト型が取り決められた基本型に含まれるか否かが決定される。この決定は、取り決められたリスト内の検索として実施することができる。この実施の場合、取り決められたリストが取り決められた基本型の各々を識別することになる。オブジェクトが取り決められた基本型の１つとして識別されると、処理はブロック１０１０へと進む。
【００９０】
ブロック１０１０では、識別されたオブジェクト用のプロパティバッグ内にエントリが作成される。次に、プロパティバッグの例示的な実施について説明する。
【００９１】
簡単に図１２を見ると、例示的な階層ツリー（例えばプロパティバッグツリー）の一部を示すグラフ図が示されている。この一部分は、プロパティバッグを有する第１のレベル１２２０と、サブプロパティバッグを有する第２のレベル１２４０との、階層ツリー内の２つのレベルを示す。各プロパティバッグ１２２０および１２４０が、名前フィールド１２０２、価値フィールド１２０４、および型フィールド１２０６を含む。さらに、各プロパティバッグ１２２０および１２４０は、ＩｓＴｙｐｅフィールド１２０８、ＷａｓＴｙｐｅフィールド１２１０、およびＴｒｅａｔＡｓフィールド１２１２を含むことができる。プロパティバッグ１２２０は、エントリ１２２２〜１２３０を含み、サブプロパティバッグ１２４０は、エントリ１２４２〜１２４８を含む。
【００９２】
図１０を参照すると、ブロック１０１０について上記で述べたように、プロパティバッグ１２２０にオブジェクト用のエントリ（例えばエントリ１２２２）が作成される。その後、このエントリに関する各フィールドが、オブジェクトに関する情報を使用して更新される。例えば、オブジェクトの名前（例えば「ＥｍｐｌｏｙｅｅＮａｍｅ」）が名前フィールド１２０２に入力される。プロパティの値（例えば２８７３１）が値フィールド１２０４に入力される。オブジェクトの型（例えば「Ｉｎｔ」）が型フィールド１２０６に入力される。一実施形態では、名前フィールドはハッシュテーブル用のキーとすることができる。処理はブロック１０１２へと進む。
【００９３】
ブロック１０１２では、オブジェクトが直列化される。直接の直列化は、基礎となるコンポーネントフレームワークによって、あるいは基本型用に指定されたコード、またはその他によって提供される機構を介して行うことができる。オブジェクトの直列化処理は、その基本型に依存する。各基本型は、それ自体の特別な直列化処理を有する。一実施形態において、取決め済みリスト内で特別な直列化処理は識別される。この実施形態において、取決め済みリストは、リスト内の各々の取決め済み基本型に関する特別な直列化処理への参照を含む。一実施形態において、直接の直列化は、オブジェクトをＸＭＬに変換する。しかしながら直接の直列化は、添付の特許請求の範囲から逸脱することなしに、オブジェクトをＸＭＬ以外のフォーマットに変換することができる。特別な直列化処理の結果は、直列化されたオブジェクト内に格納される。
【００９４】
意思決定ブロック１００８に戻り、オブジェクトが取決め済み基本型の１つとして識別されないことが決定された場合、処理はブロック１０１４へと進む。ブロック１０１４において、プロパティバッグ型は、型フィールド１２０６に入力される。その後このプロパティバッグ型は、ブロック１０１６で作成されたサブプロパティバッグ（例えばサブプロパティバッグ１２４０）を参照する。
【００９５】
ブロック１０１６において、サブプロパティバッグ（例えばサブプロパティバッグ１２４０）は作成される。したがって、サブプロパティバッグの追加レベルを作成することによって、プロパティバッグツリーが形成される。サブプロパティバッグは、プロパティバッグ用に定義されたフィールドと同じフィールドを有する。このサブプロパティバッグは、プロパティバッグの階層ツリーで他のレベルを作成する、１つまたは複数のサブプロパティバッグ用のエントリも有することができる。処理はブロック１０２０へと進む。
【００９６】
ブロック１０２０において、再帰的性質の直列化処理が図示されている。直列化処理は、オブジェクト内で所望の各プロパティを直列化することに焦点を合わせている。一般的に、所望のプロパティは、公開として指定されるプロパティである。しかしながら、場合によっては、隠しプロパティおよび他のプロパティを所望のプロパティとして直列化することもできる。ブロック１０２２〜１０３２は様々な順番で実行可能であり、場合によっては、オプションで１つまたは複数のブロック（例えばブロック１０３２）を実行することができる。次に、ブロック１０２２〜１０３２の各々についてさらに説明する。
【００９７】
ブロック１０２２において、所望のプロパティの型が識別される。これはブロック１００６を参照しながら上記で説明した反映を介して、再度行われる。
【００９８】
ブロック１０２４において、現在のプロパティバッグ（例えばサブプロパティバッグ）へのエントリは、そのプロパティに追加される。
【００９９】
ブロック１０２６において、所望のプロパティに関連付けられたエントリ内のフィールドが設定される。フィールドは、ブロック１０１０に関して上記で説明したように設定されるが、プロパティバッグではなくサブプロパティバッグに設定される。例えば、図１２に示されたサブプロパティバッグ１２４０内のエントリ１２４２のフィールドは、プロパティ（オブジェクト）に関連付けられた情報を使用して更新される。
【０１００】
ブロック１０２８において、所望のプロパティが取決め済み基本型の１つである場合、プロパティは、ブロック１０１２に関して上記で説明されたように直接直列化される。
【０１０１】
ブロック１０３０において、所望のプロパティが取決め済み基本型の１つでない場合、ブロック１０１４および１０２０は、再帰的に実行される。
【０１０２】
この再帰的な処理により、プロパティバッグの階層ツリーは管理が困難になる可能性がある。したがって、直列化処理９００を制限することが望ましい。直列化処理を制限するための実施形態を、ブロック１０３２に示す。これは、オプションで実行することができる。階層ツリーをカリング（ｃｕｌｌｉｎｇ）するためのいくつかの実施形態がある。一実施形態において、階層ツリーの所定の深さを指定するポリシーを設定することができる。例えば、所定の深さが２に設定された場合、直列化処理の再帰的性質は、プロパティバッグから参照された１つまたは複数のサブプロパティバッグを作成した後に停止する。直列化処理９００は、それ以上サブプロパティバッグ内でのオブジェクトの分解を進めることはない。したがって、これらのサブプロパティバッグは、プロパティバッグとして直列化され、直列化されたオブジェクト内に含められる。
【０１０３】
他の実施形態において、リモートエージェントは、直列化に先立ち、指定されなかったプロパティを除去する「ピック」処理を介してオブジェクトを実行する。例示的な構文は、＞Ｒｃｍｄ ｍａｃｈｉｎｅ：ＲｅｍｏｔｅＳｅｒｖｅｒ Ｇｅｔ／ＤＢ｜Ｐｉｃｋ Ｎａｍｅ，Ｂｉｒｔｈｄａｔｅである。その後、直列化の間に、指定されたプロパティ（例えばＮａｍｅおよびＢｉｒｔｈｄａｔｅ）が所望のプロパティとなり、前述のように直列化される。ピック処理は、あらゆるシステムで使用できる他のコマンドレットとすることができる。ピック処理でプロパティを明示的に指定する欠点の１つが、ピックリストを毎回指定しなければならないこと、およびそれらを選び出すために所望のプロパティを知らなければならないことである。
【０１０４】
他の実施形態において、ブロック８３２は、プロパティ設定機構を使用することができる。プロパティ設定機構は、プロパティ集合に関して名前を定義できるようにするものである。その後、管理者は、所望のプロパティ集合を取得するために、コマンドレットと共にプロパティ設定名を指定することができる。プロパティ集合は、様々な方法で定義することができる。１つの方法には、「？」などの所定のパラメータをコマンドレット用の入力パラメータとして入力することができる。予め定義されたパラメータを認識すると、オペレーティング環境は、オブジェクトのすべてのプロパティをリスト表示することができる。リストは、管理者が所望のプロパティにチェックを入れ（例えば「クリックオン」）、プロパティ集合に命名することができるＧＵＩとすることができる。その後、プロパティ集合情報は、拡張メタデータに格納される。例えば、プロパティ集合は「ｐｅｒｆｏｒｍａｎｃｅ」と命名することができる。その後、各オブジェクトは、そのプロパティのいずれをこのｐｅｒｆｏｒｍａｎｃｅプロパティ集合に含めるべきであるかを識別することになる。したがって管理者は、プロパティの名前を知る必要がなく、所望のプロパティ集合の名前のみを知っていればよいことになる。「ｄｅｆａｕｌｔ」と命名されたプロパティ集合は、所望のプロパティがオブジェクトを直列化することを指定する。その後管理者は、直列化が必要な場合にｄｅｆａｕｌｔプロパティを指定することができる。
【０１０５】
プロパティバッグ階層ツリーを制限する他の方法は、ある種の型のみをサポートすること、およびある種の型から導出された型を強制的にその型に合致させることによるものである。一実施形態において、オブジェクト階層は、その親を識別するために各オブジェクトを反映することによって「ウォークダウン（ｗａｌｋ ｄｏｗｎ）」される。ある種のオブジェクトに関して、それが基本型から導出されたものである場合、そのオブジェクトは、強制的にその親型となる。例えば、ハッシュテーブルオブジェクトはＩｄｉｃｔｉｏｎａｒｙオブジェクトであり、これは基本オブジェクトから導出するＩＥｎｕｍｂｅｒａｂｌｅオブジェクトである。直列化処理は、ハッシュテーブルオブジェクトをＩＥｎｕｍｂｅｒａｂｌｅオブジェクトとして取り扱うことができる。この方法では、直列化処理はオブジェクト階層内の所定のレベルのオブジェクトを完全にサポートするが、オブジェクト階層内の他の型のオブジェクトは選択された型に強制的に合致させる。実際のところ、たとえオリジナルのオブジェクト型が転送されない場合であっても、受信側コンピュータで一旦情報が取得されると、受信側コンピュータはそこで処理（キーの作成など）を実行し、必要であればオリジナルオブジェクトを取得することができる。
【０１０６】
直列化処理９００がいったん完了すると、直列化オブジェクトならびに他の情報が組み合わされて、要求側エンティティに送信される要求パッケージを形成する。
【０１０７】
プロパティバッグおよびサブプロパティバッグは、ＩｓＴｙｐｅフィールド１２０８、ＷａｓＴｙｐｅフィールド１２１０、またはＴｒｅａｔＡｓフィールド１２１２などの直列化処理中に設定される追加のフィールドを有することができる。これらの型は、非直列化処理９１０時に使用される。ＩｓＴｙｐｅフィールド１２０８は、オブジェクトの型を識別する。しかしながらオブジェクトが直列化された場合、オブジェクトのＩｓＴｙｐｅフィールド１２０８は「ＮＵＬＬ」となる。ＷａｓＴｙｐｅフィールド１２１０は、プロパティが以前に変更した型を識別する。非直列化フィールド９１０は、この情報からオブジェクトの発生元を識別することができるが、オブジェクトが現在いくつのプロパティを有するかを知ることはできない。例えば、オブジェクトを直列化するときにプロパティ集合またはピック処理が使用された場合、すべてではなく特定のプロパティのみが直列化された。ＴｒｅａｔＡｓフィールド１２１０は、ある型を識別し、その型に関連付けられたプロパティが使用可能であることを保証する。例えば、前述のプロパティ集合の例を使用して、新しいオブジェクト型を「ＳＱＬＩｎｆｏＰｅｒｓｏｎａｌ」として定義することができる。この新しい型は、自宅住所、自宅電話番号、およびその他などの、オブジェクトに関連付けられた指定されたプロパティが使用可能であることを保証する。ＴｒｅａｔＡｓとしての資格を与えるのに必要なすべてのプロパティを含めるのに十分なプロパティが指定されると、直列化処理９００は、ＴｒｅａｔＡｓフィールド１２１０の下に正しい型を入力することになる。
【０１０８】
図１１は、図８に示されたコマンドレットの処理で使用するのに好適なオブジェクトを非直列化するための例示的な処理を示す論理流れ図である。一般に、送信されたオブジェクトの非直列化は、直列化処理の逆オペレーションを実行する。処理はブロック１１０２で始まり、送信されるデータ内でプロパティバッグ標識が識別される。一実施形態において、識別子は、ＸＭＬドキュメント内の一要素とすることができる。処理はブロック１１０４へと進む。
【０１０９】
ブロック１１０４において、送信されるデータ内に含まれる情報が読み込まれるプロパティバッグオブジェクトが作成される。
【０１１０】
ブロック１１０６において、プロパティバッグオブジェクト用の型プロパティが設定される。この型プロパティは、拡張型マネージャが必要に応じてプロパティバッグを処理できるように、拡張型マネージャに通知する。
【０１１１】
ブロック１１０８において、送信されるデータ内で識別されプロパティバッグに関連付けられた各要素が処理される。ブロック１１１０では、プロパティバッグ内のエントリが作成される。ブロック１１１２において、プロパティバッグ内のフィールドが読み込まれる。処理は意思決定ブロック１１１４へと進む。
【０１１２】
意思決定ブロック１１１４において、送信されるデータ内に他のプロパティバッグを定義するか否かが決定される。送信されるデータ内に他のプロパティバッグが定義される場合、処理は、送信されるデータがいかなる他のプロパティバッグも含まなくなるまで、ブロック１１０２〜１１０８を一巡して元に戻る。
【０１１３】
しかしながら、いかなる他のプロパティバッグも含まなくなると、処理はブロック１１２０〜１１４０へと進む。一旦プロパティバッグの階層ツリーが作成されると、その後の処理について各プロパティバッグが再検討される。
【０１１４】
ブロック１１２０において、プロパティバッグの型プロパティが基本型の１つである場合、非直列化処理は、識別された型のオブジェクトをインスタンス化し（ブロック１１２２）、オブジェクトのプロパティを読み込む（ブロック１１２４）。
【０１１５】
ブロック１１３０において、プロパティバッグのＴｒｅａｔＡｓ属性がある型を指定する場合、指定された型のオブジェクトはインスタンス化され（ブロック１１３２）、オブジェクトのプロパティが読み込まれる（１１３４）。ＴｒｅａｔＡｓ属性で指定される型は、基本型の１つである。
【０１１６】
ブロック１１４０において、基本型ではない残りの各々のプロパティバッグに関し、プロパティバッグ内で識別された各オブジェクトは、インスタンス化され（ブロック１１４２）、読み込まれる（ブロック１１４４）。
【０１１７】
したがって、図に示すように、リモートコンピュータで作成されたオリジナルオブジェクトが基本型である場合、送信されるデータには最小限の情報が含まれる。これは、１つのレベルしかない階層ツリーと一致する。送信されるデータには、プロパティの名前／値のペアが含まれるが、いずれの実行可能コードも含まれない。しかしながら、一旦要求側コンピュータが送信されるデータを受信し、その型を認識すると、その型のオブジェクトがインスタンス化され、オリジナルオブジェクトによって提供されたメソッドおよび機能を有することになる。この形式では、悪意あるコードは要求側コンピュータに送信されず、要求側コンピュータによって実行されない。代わりに、オブジェクトに関する無害な情報が要求側コンピュータに送信される。
【０１１８】
図１３は、図９に示されたオブジェクトを直列化するための処理と共に使用するのに好適なプロトコルを取り決めるための例示的な処理を示す論理流れ図である。ある種のオブジェクトに関して、たとえ特定のパラメータの直列化を制限するか、または階層ツリーの深さを指定しても、２つのコンピュータ間で転送される情報はかなりの量である。したがって、伝送に必要な情報量を制限する追加の取決め機構を提供する。前述のように、階層ツリーの複雑さは取り決められる基本型の数に依存する。多数の取り決められた基本型が知られている場合、階層ツリーは複雑でなくなり、最終的には要求側コンピュータに送信される情報が少なくなる。基本型を指定するプロパティバッグ内の任意のエントリについて、要求側コンピュータで「生」オブジェクトを作成するための最低限の情報しか転送されない。したがって、より多くのオブジェクトを収容するために、基本型のリストに指定される基本型の数を増やすことができることが想像される。しかしながら本方法は、この方法を使用するための人為的な制約または要件をソフトウェア開発者に課すものではない。例えば何らかの従来の環境では、適切に動作するためにどちらのコンピュータも同じバージョンで更新しなければならない。この従来の環境では、１台のコンピュータがどのコンピュータと通信するかを指定し、通信を行うための準拠事項を他のコンピュータに強制した。これに対して、オブジェクトを転送する本方法は、コンピュータが依然として互いに通信可能でありながら、互いに独立して更新できるようにする、プロトコル取決め方法を提供する。
【０１１９】
プロトコル取決め処理１３００は、ブロック１３０２で始まる。ブロック１３０２では、クライアントのバージョン番号が受信される。クライアントのバージョン番号は、クライアント（例えば要求側コンピュータ）が使用可能な基本型のリストの最新バージョンを識別する。処理は意思決定ブロック１３０４へと進む。
【０１２０】
意思決定ブロック１３０４では、クライアントのバージョン番号がリモートのバージョン番号と比較され、リモートのバージョン番号の方が新しいか否かが判断される。リモートのバージョン番号は、リモートサーバが使用可能な基本型のリストの最新バージョンを識別する。リモートのバージョン番号の方が新しい場合、処理はブロック１３０６へと進む。
【０１２１】
ブロック１３０６では、クライアントのバージョン番号に関連付けられた基本型のリストが直列化処理に使用される。したがって、クライアントバージョンが、直列化処理時に使用される取り決められたリストとなる。
【０１２２】
他方で、リモートのバージョン番号がクライアントバージョンよりも新しくない場合、処理はブロック１３０８へと進む。ブロック１３０８では、リモートコンピュータで使用可能な基本型の最も新しいリストが直列化処理に使用される。したがって、リモートバージョンが、直列化処理時に使用される取り決められたリストとなる。
【０１２３】
取決め処理の他の実施形態では、要求側コンピュータがサポートしている基本型をリモートコンピュータに送信することができる。その後リモートコンピュータは、テーブルをウォークスルーして、テーブル内の項目を受け入れまたは拒否することによって、どの型がサポートされるかを決定する。その後、受け入れられた型が取り決められたリストを形成する。
【０１２４】
取決め処理の他の実施形態では、要求側コンピュータが参照の集合を送信することができる。参照の集合は、ファイル名を指定することができる。したがって、指定されたファイル名内の任意の型のオブジェクトをサポートし、取り決められた基本型の１つとすることになる。
【０１２５】
以上、特定の実施および実施形態の細部について説明してきたが、こうした細部は、添付の特許請求の範囲を限定するものではなく、法的な開示の義務を果たすことを意図するものである。したがって、前述のシステムおよび方法は特許請求の範囲によって画定されるものであり、前述の特定の機能に限定されるものではない。むしろ、本システムおよび方法は、添付の特許請求の範囲の適切な範囲内にあり、同等の原理に従って適切に解釈された、その形式または修正のいずれかにおいて請求されるものである。
【特許請求の範囲】
【請求項１】
エンティティがリモート境界を横切ってオブジェクトを転送するための方法であって、前記エンティティが、
既知のオブジェクトの取り決めリストを決定するようにリモートエンティティと取り決めるステップであって、
前記リモートエンティティで使用可能なオブジェクト型の第１のリストのバージョンを、オブジェクトを前記リモートエンティティに転送しようとするローカルエンティティで使用可能なオブジェクト型の第２のリストと比較するステップ、
前記第２のリストのバージョンが前記第１のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第１のリストを選択するステップ、および
前記第１のリストのバージョンが前記第２のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第２のリストを選択するステップを含む、ステップと、
前記オブジェクトを複数のサブオブジェクトに分解し、前記複数のサブオブジェクトを階層に分割するステップと、
前記複数のサブオブジェクトの第１のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれる場合、前記第１のサブコンポーネントのいかなる実行コードも含むこと無く前記第１のサブコンポーネントを直列化するステップと、
前記複数のサブオブジェクトの第２のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれない場合、前記第２のサブコンポーネントのプロパティバッグ内にサブプロパティバッグを作成してプロパティバッグの階層ツリーを作成し、前記第２のサブコンポーネントのプロパティを再帰的に直列化するステップであって、前記プロパティバッグの階層ツリーが、前記階層ツリーの最大の深さを指定すること、特定のオブジェクト型のみサポートし、前記特定のオブジェクト型から得られるオブジェクト型を課して型を一致させること、前記複数のサブコンポーネントおよび前記プロパティバッグを直列化されたパッケージに直列化すること、前記直列化されたパッケージを前記リモートエンティティに転送することの内の少なくとも１つによって制限される、ステップと
を実行することを特徴とする方法。
【請求項２】
前記取り決めリストは、前記コンポーネント読取り可能なオブジェクトまたは前記複数のサブコンポーネントの少なくとも１つのサブコンポーネントのデータ型を前記既知のオブジェクト型の１つとして識別することを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも１つのサブコンポーネントは前記取り決めリストにおいて識別されていない型を有する未知のオブジェクトを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記オブジェクトを分解するステップは、前記取り決めリストに基づき前記未知のオブジェクトを他のレベルのサブコンポーネントに分解することを特徴とする請求項３に記載の方法。
【請求項５】
システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記システム上に他の処理を含むことを特徴とする請求項１に記載の方法。
【請求項６】
システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、他のシステム上に他の処理を含むことを特徴とする請求項１に記載の方法。
【請求項７】
処理内で実行中の第１のアプリケーションドメインは、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記処理内に他のアプリケーションドメインを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記プロパティバッグは、ハッシュテーブルを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ハッシュテーブル内の各エントリ用のキーは、前記エントリに関連付けられた前記サブコンポーネントの名前を備えることを特徴とする請求項８に記載の方法。
【請求項１０】
前記プロパティバッグは、複数のエントリを含み、各エントリは、前記サブコンポーネントのうちの１つに関連付けられ、および前記サブコンポーネントに関連付けられた名前を格納するための第１のフィールドと、前記サブコンポーネントに関連付けられた値を格納するための第２のフィールドと、前記サブコンポーネントに関連付けられた型を格納するための第３のフィールドとを有することを特徴とする請求項１に記載の方法。
【請求項１１】
前記取り決めるステップは、前記ローカルエンティティから複数のオブジェクト型を受け入れることを含み、前記受け入れられたオブジェクト型が前記取り決めリストにおいて識別される既知のオブジェクト型となることを特徴とする請求項１に記載の方法。
【請求項１２】
前記取り決めるステップは、前記取り決めリストを有するファイルの識別子を受信するステップ、および前記ファイルにおいて識別されたオブジェクト型を含むステップを含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記階層について所定の深さを指定することによって前記サブコンポーネントの階層を制限するステップをさらに備え、前記オブジェクトを分解するステップが、前記所定の深さまで前記オブジェクトを分解するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記オブジェクトの個々のプロパティを識別するプロパティ集合を定義することによって前記サブコンポーネントの階層を制限するステップをさらに備え、前記オブジェクトを分解するステップが、前記オブジェクトの識別された個々のプロパティを分解するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記オブジェクト内で指定されたプロパティを識別することによって前記サブコンポーネントの階層を制限するステップをさらに備え、前記オブジェクトを分解するステップが、前記指定されたプロパティを分解するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
所定の数によって前記直列化されたパッケージに直列化される、前記既知のオブジェクトを制限する前記所定の数を指定することによって、前記サブコンポーネントの階層を制限するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１７】
前記既知のオブジェクトは前記直列化するステップにおいて直列化されることを特徴とする請求項１に記載の方法。
【請求項１８】
リモート境界を横切って通信するシステムであって、
前記リモート境界を横切ってオブジェクトを通信する第１のエンティティとが、
既知のオブジェクトの取り決めリストを決定するようにリモートエンティティと取り決めるステップであって、
前記リモートエンティティで使用可能なオブジェクト型の第１のリストのバージョンを、オブジェクトを前記リモートエンティティに転送しようとするローカルエンティティで使用可能なオブジェクト型の第２のリストと比較するステップ、
前記第２のリストのバージョンが前記第１のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第１のリストを選択するステップ、および
前記第１のリストのバージョンが前記第２のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第２のリストを選択するステップを含む、ステップと、
前記オブジェクトを複数のサブオブジェクトに分解し、前記複数のサブオブジェクトを階層に分割するステップと、
前記複数のサブオブジェクトの第１のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれる場合、前記第１のサブコンポーネントのいかなる実行コードも含むこと無く前記第１のサブコンポーネントを直列化するステップと、
前記複数のサブオブジェクトの第２のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれない場合、前記第２のサブコンポーネントのプロパティバッグ内にサブプロパティバッグを作成してプロパティバッグの階層ツリーを作成し、前記第２のサブコンポーネントのプロパティを再帰的に直列化するステップであって、前記プロパティバッグの階層ツリーが、前記階層ツリーの最大の深さを指定すること、特定のオブジェクト型のみサポートし、前記特定のオブジェクト型から得られるオブジェクト型を課して型を一致させること、前記複数のサブコンポーネントおよび前記プロパティバッグを直列化されたパッケージに直列化すること、前記直列化されたパッケージを前記リモートエンティティに転送することの内の少なくとも１つによって制限される、ステップと
を備えた方法を実行することを特徴とするシステム。
【請求項１９】
前記システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記システム上に他の処理を含むことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、他のシステム上に他の処理を含むことを特徴とする請求項１８に記載のシステム。
【請求項２１】
処理内で実行中の第１のアプリケーションドメインは、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記処理内に他のアプリケーションドメインを含むことを特徴とする請求項１８に記載のシステム。
【請求項１】
エンティティがリモート境界を横切ってオブジェクトを転送するための方法であって、前記エンティティが、
既知のオブジェクトの取り決めリストを決定するようにリモートエンティティと取り決めるステップであって、
前記リモートエンティティで使用可能なオブジェクト型の第１のリストのバージョンを、オブジェクトを前記リモートエンティティに転送しようとするローカルエンティティで使用可能なオブジェクト型の第２のリストと比較するステップ、
前記第２のリストのバージョンが前記第１のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第１のリストを選択するステップ、および
前記第１のリストのバージョンが前記第２のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第２のリストを選択するステップを含む、ステップと、
前記オブジェクトを複数のサブオブジェクトに分解し、前記複数のサブオブジェクトを階層に分割するステップと、
前記複数のサブオブジェクトの第１のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれる場合、前記第１のサブコンポーネントのいかなる実行コードも含むこと無く前記第１のサブコンポーネントを直列化するステップと、
前記複数のサブオブジェクトの第２のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれない場合、前記第２のサブコンポーネントのプロパティバッグ内にサブプロパティバッグを作成してプロパティバッグの階層ツリーを作成し、前記第２のサブコンポーネントのプロパティを再帰的に直列化するステップであって、前記プロパティバッグの階層ツリーが、前記階層ツリーの最大の深さを指定すること、特定のオブジェクト型のみサポートし、前記特定のオブジェクト型から得られるオブジェクト型を課して型を一致させること、前記複数のサブコンポーネントおよび前記プロパティバッグを直列化されたパッケージに直列化すること、前記直列化されたパッケージを前記リモートエンティティに転送することの内の少なくとも１つによって制限される、ステップと
を実行することを特徴とする方法。
【請求項２】
前記取り決めリストは、前記コンポーネント読取り可能なオブジェクトまたは前記複数のサブコンポーネントの少なくとも１つのサブコンポーネントのデータ型を前記既知のオブジェクト型の１つとして識別することを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも１つのサブコンポーネントは前記取り決めリストにおいて識別されていない型を有する未知のオブジェクトを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記オブジェクトを分解するステップは、前記取り決めリストに基づき前記未知のオブジェクトを他のレベルのサブコンポーネントに分解することを特徴とする請求項３に記載の方法。
【請求項５】
システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記システム上に他の処理を含むことを特徴とする請求項１に記載の方法。
【請求項６】
システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、他のシステム上に他の処理を含むことを特徴とする請求項１に記載の方法。
【請求項７】
処理内で実行中の第１のアプリケーションドメインは、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記処理内に他のアプリケーションドメインを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記プロパティバッグは、ハッシュテーブルを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ハッシュテーブル内の各エントリ用のキーは、前記エントリに関連付けられた前記サブコンポーネントの名前を備えることを特徴とする請求項８に記載の方法。
【請求項１０】
前記プロパティバッグは、複数のエントリを含み、各エントリは、前記サブコンポーネントのうちの１つに関連付けられ、および前記サブコンポーネントに関連付けられた名前を格納するための第１のフィールドと、前記サブコンポーネントに関連付けられた値を格納するための第２のフィールドと、前記サブコンポーネントに関連付けられた型を格納するための第３のフィールドとを有することを特徴とする請求項１に記載の方法。
【請求項１１】
前記取り決めるステップは、前記ローカルエンティティから複数のオブジェクト型を受け入れることを含み、前記受け入れられたオブジェクト型が前記取り決めリストにおいて識別される既知のオブジェクト型となることを特徴とする請求項１に記載の方法。
【請求項１２】
前記取り決めるステップは、前記取り決めリストを有するファイルの識別子を受信するステップ、および前記ファイルにおいて識別されたオブジェクト型を含むステップを含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記階層について所定の深さを指定することによって前記サブコンポーネントの階層を制限するステップをさらに備え、前記オブジェクトを分解するステップが、前記所定の深さまで前記オブジェクトを分解するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記オブジェクトの個々のプロパティを識別するプロパティ集合を定義することによって前記サブコンポーネントの階層を制限するステップをさらに備え、前記オブジェクトを分解するステップが、前記オブジェクトの識別された個々のプロパティを分解するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記オブジェクト内で指定されたプロパティを識別することによって前記サブコンポーネントの階層を制限するステップをさらに備え、前記オブジェクトを分解するステップが、前記指定されたプロパティを分解するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
所定の数によって前記直列化されたパッケージに直列化される、前記既知のオブジェクトを制限する前記所定の数を指定することによって、前記サブコンポーネントの階層を制限するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１７】
前記既知のオブジェクトは前記直列化するステップにおいて直列化されることを特徴とする請求項１に記載の方法。
【請求項１８】
リモート境界を横切って通信するシステムであって、
前記リモート境界を横切ってオブジェクトを通信する第１のエンティティとが、
既知のオブジェクトの取り決めリストを決定するようにリモートエンティティと取り決めるステップであって、
前記リモートエンティティで使用可能なオブジェクト型の第１のリストのバージョンを、オブジェクトを前記リモートエンティティに転送しようとするローカルエンティティで使用可能なオブジェクト型の第２のリストと比較するステップ、
前記第２のリストのバージョンが前記第１のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第１のリストを選択するステップ、および
前記第１のリストのバージョンが前記第２のリストのバージョンよりも新しい場合、前記既知のオブジェクトの取り決めリストとして前記第２のリストを選択するステップを含む、ステップと、
前記オブジェクトを複数のサブオブジェクトに分解し、前記複数のサブオブジェクトを階層に分割するステップと、
前記複数のサブオブジェクトの第１のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれる場合、前記第１のサブコンポーネントのいかなる実行コードも含むこと無く前記第１のサブコンポーネントを直列化するステップと、
前記複数のサブオブジェクトの第２のサブコンポーネントが前記既知のオブジェクトの取り決めリストに含まれない場合、前記第２のサブコンポーネントのプロパティバッグ内にサブプロパティバッグを作成してプロパティバッグの階層ツリーを作成し、前記第２のサブコンポーネントのプロパティを再帰的に直列化するステップであって、前記プロパティバッグの階層ツリーが、前記階層ツリーの最大の深さを指定すること、特定のオブジェクト型のみサポートし、前記特定のオブジェクト型から得られるオブジェクト型を課して型を一致させること、前記複数のサブコンポーネントおよび前記プロパティバッグを直列化されたパッケージに直列化すること、前記直列化されたパッケージを前記リモートエンティティに転送することの内の少なくとも１つによって制限される、ステップと
を備えた方法を実行することを特徴とするシステム。
【請求項１９】
前記システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記システム上に他の処理を含むことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記システム上の第１の処理は、前記直列化されたパッケージを送信し、および前記リモートエンティティは、他のシステム上に他の処理を含むことを特徴とする請求項１８に記載のシステム。
【請求項２１】
処理内で実行中の第１のアプリケーションドメインは、前記直列化されたパッケージを送信し、および前記リモートエンティティは、前記処理内に他のアプリケーションドメインを含むことを特徴とする請求項１８に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−１２８８８８（Ｐ２０１２−１２８８８８Ａ）
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願番号】特願２０１２−８４２９６（Ｐ２０１２−８４２９６）
【出願日】平成２４年４月２日（２０１２．４．２）
【分割の表示】特願２００６−５４９２２９（Ｐ２００６−５４９２２９）の分割
【原出願日】平成１６年７月２３日（２００４．７．２３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願日】平成２４年４月２日（２０１２．４．２）
【分割の表示】特願２００６−５４９２２９（Ｐ２００６−５４９２２９）の分割
【原出願日】平成１６年７月２３日（２００４．７．２３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
[ Back to top ]