第1節:コンピューティング環境の実施例
図1に、本発明の比較手法を実装する際に使用できるコンピューティング装置例を示す。最も基本的な構成では、コンピューティング装置100は、通常、少なくとも1つの処理装置102およびシステムメモリ104を備える。コンピューティング装置の正確な構成と種類に応じて、システムメモリ104は、揮発性(RAMなど)、不揮発性(ROM、フラッシュメモリなど)、またはこれら2つの何らかの組み合わせとすることができる。システムメモリ104は、通常、オペレーティングシステム105、1つまたは複数のプログラムモジュール106を格納し、1つまたは複数のプログラムデータ107を含むこともできる。システムメモリ104は、さらに、(プロパティおよびイベントを含む)コンポーネント、オブジェクト、継承、多態性、リフレクションをサポートするコンポーネントベースのフレームワーク120を格納し、ワシントン州レッドモンドのMicrosoft Corporation社製の.NET(商標)フレームワークなどのオブジェクト指向コンポーネントベースのアプリケーションプログラミングインターフェイス(API)を提供する。システムメモリ104は、さらに、管理ツール(図に示されていない)の開発をサポートするコンポーネントベースのフレームワーク120とやり取りする管理ツールフレームワーク200も格納する。コンポーネントベースのフレームワーク120および管理ツールフレームワーク200は、オペレーティングシステム105の一部として常駐するか(図に示されているように)、またはプログラムモジュール106の一部として常駐することができる。基本構成は、図1において点線108内のコンポーネントにより示されている。
コンピューティング装置100は、さらに特徴または機能を追加することもできる。例えば、コンピューティング装置100は、磁気ディスク、光ディスク、またはテープなどの(取り外し可能および/または固定の)追加のデータ記憶装置を備えることもできる。このような追加記憶装置は、図1では、取り外し可能記憶装置109および固定の記憶装置110により例示されている。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および固定の媒体を含むことができる。システムメモリ104、取り外し可能記憶装置109、および固定の記憶装置110は、すべてコンピュータ記憶媒体の実施例である。コンピュータ記憶媒体としては、限定ではないが、RAM、ROM、EEPROM、フラッシュメモリまたはその他のメモリ技術、CD−ROM、デジタル多目的ディスク(DVD)またはその他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができコンピューティング装置100によりアクセスできるその他の媒体がある。このような任意のコンピュータ記憶媒体を装置100の一部とすることができる。さらにコンピューティング装置100は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの(複数の)入力装置112を備えることもできる。ディスプレイ、スピーカ、プリンタなどの(複数の)出力装置114を備えることもできる。これらの装置は、当業ではよく知られているため、本明細書でさらに詳しい説明をする必要はない。
また、コンピューティング装置100は、装置がネットワークなどを経由して他のコンピューティング装置118と通信するために使用する通信接続116も含むことができる。通信接続116は、通信媒体の一実施例である。通信媒体は、通常、搬送波またはその他のトランスポート機構などの変調データ信号を介して、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータによって実現されることができ、情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち1つまたは複数が設定または変更された信号を意味する。例えば、限定ではないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、RF、赤外線、およびその他の無線媒体などの無線媒体がある。本明細書で使用されているコンピュータ読み取り可能媒体という用語は、記憶媒体と通信媒体の両方を含む。
第2節:管理ツールフレームワーク
図2は、管理ツールフレームワーク200の例の概要を一般的に示すブロック図である。管理ツールフレームワーク200は、1つまたは複数のホストコンポーネント202、プラットフォーム固有コンポーネント204、ホスト独立コンポーネント206、およびハンドラコンポーネント208を備える。ホスト独立コンポーネント206は、他のコンポーネントのそれぞれ(つまり、ホストコンポーネント202、プラットフォーム固有コンポーネント204、およびハンドラコンポーネント208)と通信することができる。これらのコンポーネントのそれぞれについて、以下で簡単に説明し、必要に応じて、後の節でさらに詳しく説明する。
(ホストコンポーネント)
ホストコンポーネント202は、関連付けられたアプリケーションの自動化機能をユーザまたはその他のプログラムに公開する1つまたは複数のホストプログラム(例えば、ホストプログラム210〜214)を備える。自動化機能は、ナビゲーション、診断、構成、ライフサイクル、オペレーションなどを自動化することができる。それぞれのホストプログラム210〜214は、コマンドライン、グラフィカルユーザインターフェイス(GUI)、音声認識インターフェイス、アプリケーションプログラミングインターフェイス(API)、スクリプト言語、Webサービスなどを介して、特定のスタイルでこれらの自動化機能を公開することができる。しかし、ホストプログラム210〜214はそれぞれ、管理ツールフレームワークが備える機構を通じて1つまたは複数の自動化機能を公開する。
この実施例では、この機構はcmdletsを使用して、関連付けられたホストプログラム210〜214のユーザに対し管理ツール機能を表面化する。さらに、この機構は、ホストにより利用可能にされた一組のインターフェイスを使用して、管理ツール環境を、対応するホストプログラム210〜214に関連付けられたアプリケーション内に埋め込む。
以下の説明全体を通して、「cmdlet」という用語を使用して、図2〜13を参照しつつ説明されている管理ツール環境例の中で使用されるコマンドに言及する。そのため、cmdletsは、従来の管理環境内のコマンドに対応するが、それらの従来のコマンドとは大きく異なる。例えば、cmdletsは、通常、それに対応するコマンドと比べてサイズが小さいが、それは、cmdletsでは、構文解析、データ妥当性検証、エラー報告などの管理ツールフレームワークが備える共通機能を使用できるからである。このような共通機能は一度で実施し、一度でテストできるため、管理ツールフレームワーク全体でcmdletsを使用することにより、従来の環境に比べて、アプリケーション固有の機能に関連する漸進的開発およびテストコストをかなり低くすることができる。
さらに、従来の環境とは対照的に、cmdletsは、スタンドアロンの実行可能プログラムである必要はない。むしろ、cmdletsは、管理ツールフレームワーク内の同じプロセスで実行できる。これにより、cmdlets同士で「ライブ」オブジェクトをやり取りすることができる。「ライブ」オブジェクトをやり取りするこのような機能があるため、cmdletsはそれらのオブジェクトに対するメソッドを直接呼び出すことができる。そのため、用語「ライブ」オブジェクトは、直接呼び出し可能なメソッドを持つオブジェクトを意味する。それとは対照的に、用語「デッド」オブジェクトは、直接呼び出し可能なメソッドを持たないオブジェクトを意味する。cmdletsの作成および使用の詳細については、以下でさらに詳しく説明する。
概要を述べると、それぞれのホストプログラム210〜214は、ユーザが対話形式で管理ツールフレームワーク内の他のコンポーネントを操作するのを管理する。これらの対話操作は、パラメータ、エラー報告などのプトンプトを含むことができる。通常、各ホストプログラム210〜214は、独自の一組の特定のホストcmdlets(例えば、ホストcmdlets218)を備えることができる。例えば、ホストプログラムが電子メールプログラムの場合、ホストプログラムは、メールボックスおよびメッセージを対話形式で操作するホストcmdletsを提供することができる。図2がホストプログラム210〜214を例示しているとしても、当業者であれば、ホストコンポーネント202が既存の、または新規に作成されたアプリケーションに関連付けられた他のホストプログラムを含むことができることを理解するであろう。このような他のホストプログラムは、管理ツール環境が備える機能を関連付けられたアプリケーション内にさらに埋め込む。ホストプログラムにより実行される処理は、図7を参照しつつ以下で詳述する。
図2に示されているいくつかの実施例では、ホストプログラムは、コンピューティング装置のハードウェア、ソフトウェア、およびネットワークコンポーネントを管理する管理ツールをユーザが作成し、保存し、開くための単純で、一貫性のある、管理ユーザインターフェイスを備える管理コンソール(つまり、ホストプログラム210)とすることができる。これらの機能を実現するために、ホストプログラム210は、管理ツールフレームワークの上に管理GUIを構築するための一組のサービスを提供する。GUI対話操作は、さらに、管理ツール環境が備えるスクリプティング機能をユーザに教示するのを手助けするユーザの管理下にあるスクリプトとして公開されることもできる。
他の実施例では、ホストプログラムは、コマンドライン対話型シェル(つまり、ホストプログラム212)とすることができる。コマンドライン対話型シェルでは、シェルのメタデータ216をコマンドライン上で入力し、コマンドラインの処理に影響を及ぼすようにできる。
さらに他の実施例では、ホストプログラムは、プラットフォーム、プログラミング言語、およびアプリケーション間の分散コンピューティングおよび相互運用性に業界標準仕様を使用するWebサービス(つまり、ホストプログラム214)とすることができる。
これらの実施例に加えて、サードパーティは、そのホストプログラムまたは他のホストプログラムとともに使用される「プロバイダ」インターフェイスおよびプロバイダcmdletsを作成することにより独自のホストコンポーネントを追加することができる。プロバイダインターフェイスは、管理ツールフレームワークによりアプリケーションまたはインフラストラクチャを操作できるようにアプリケーションまたはインフラストラクチャを公開する。プロバイダcmdletsは、ナビゲーション、診断、構成、ライフサイクル、オペレーションなどを自動化する。プロバイダcmdletsは、完全に異種の一組のデータストア上で多形的cmdlet挙動を示す。管理ツール環境は、他のcmdletsクラスと同じ優先度を持つプロバイダcmdletsに作用する。プロバイダcmdletは、他のcmdletsと同じ機構を使用して作成される。プロバイダcmdletsは、アプリケーションまたはインフラストラクチャの特定の機能を管理ツールフレームワークに公開する。そのため、cmdletsを使用すると、製品開発者はその製品が多くの管理ツールで動作できる1つのホストコンポーネントを作成するだけでよい。例えば、管理ツール環境例では、システムレベルのグラフィカルユーザインターフェイスのヘルプメニューを既存のアプリケーションに統合し、移植することができる。
(プラットフォーム固有コンポーネント)
プラットフォーム固有コンポーネント204は、コンピューティングシステム(例えば、図1のコンピューティング装置100)が使用するサービスの集合体を含み、フレームワークが稼働しているプラットフォームの詳細から管理ツールフレームワークを分離する。そのため、プラットフォームの種類毎に一組のプラットフォーム固有コンポーネントがある。プラットフォーム固有コンポーネントを使用すると、ユーザは、異なるオペレーティングシステム上で同じ管理ツールを使用することができる。
図3を簡単に参照すると、プラットフォーム固有コンポーネント204は、メタデータ/状況依存入力コンポーネント302、ヘルプコンポーネント304、構成/登録コンポーネント306、cmdletセットアップコンポーネント308、および出力インターフェイスコンポーネント309を含むことができる。コンポーネント302〜308は、データベースストア314に関連付けられたデータベースストアマネージャ312と通信する。パーザ220およびスクリプトエンジン222は、メタデータ/状況依存入力コンポーネント302と通信する。コアエンジン224は、ヘルプcmdletコンポーネント304、構成/登録コンポーネント306、cmdletセットアップコンポーネント308、および出力インターフェイスコンポーネント309と通信する。出力インターフェイスコンポーネント309は、ホストによって出力cmdletsに提供されるインターフェイスを含む。出力されるcmdletsは、その後、ホストの出力オブジェクトを呼び出してレンダリングを実行することができる。プラットフォーム固有コンポーネント204は、さらに、ログ記録/監査コンポーネント310も備えることができ、コアエンジン224は、これらを使用して、ログ記録および監査機能を備えるホスト固有(つまり、プラットフォーム固有)サービスと通信する。
一管理ツールフレームワーク例では、メタデータ/状況依存入力コンポーネント302が、コマンド、パラメータ、およびパラメータ値の自動補完を行う。ヘルプcmdletコンポーネント304は、ホストユーザインターフェイスに基づくカスタマイズされたヘルプシステムを備える。
(ハンドラコンポーネント)
再び図2を参照すると、ハンドラコンポーネント208は、レガシーユーティリティ230、管理cmdlets232、非管理cmdlets234、リモーティングcmdlets(remoting cmdlets)236、およびWebサービスインターフェイス238を備える。それぞれについて、以下で詳述する。管理cmdlets232(プラットフォームcmdletsともいう)は、コンピューティング装置に関連付けられた構成情報を問い合わせ、または操作するcmdletsを含む。管理cmdlets232は、システム型情報を操作するので、これらは、特定のプラットフォームに依存する。しかし、それぞれのプラットフォームは、通常、他のプラットフォーム上で管理cmdlets232と似たアクションを実行する管理cmdlets232を備える。例えば、それぞれのプラットフォームは、システム管理属性の取得および設定を行う管理cmdlets232をサポートする(例えば、get/process、set/IPAddress)。ホスト独立コンポーネント206は、公開APIを介して管理cmdletsと通信する。
非管理cmdlets234(ベースcmdletsと呼ばれることもある)は、管理cmdlets232およびその他のcmdletsにより提供されるオブジェクトに対する処理のグループ分け、並べ替え、フィルタ処理、および実行の他の操作を行うcmdletsを含む。本発明の比較手法によれば、非管理cmdlets234は、「compare−object」cmdletを含むが、これについては、図14〜23を参照しつつ詳しく説明する。非管理cmdlets234は、各プラットフォーム上で同じでよく、公開APIを介してホスト独立コンポーネント206とやり取りする一組のユーティリティを備える。非管理cmdlets234とホスト独立コンポーネント206との間のやり取りにより、オブジェクトへのリフレクションが可能になり、またその(オブジェクト)の型と無関係にリフレクションされたオブジェクトでの処理が可能になる。そのため、これらのユーティリティを使用することにより、開発者は、非管理cmdletsを1回書いて、その後、コンピューティングシステム上でサポートされているオブジェクトのすべてのクラスにわたってそれらの非管理cmdletsを適用することができる。以前には、開発者は、処理されなければならないデータの形式をまず把握してから、そのデータのみを処理するアプリケーションを書く必要があった。その結果、従来のアプリケーションでは、非常に限られた範囲のデータしか処理できなかった。以下では、図13を参照しつつ、そのオブジェクトの型とは独立にオブジェクトを処理する機構の一例を説明する。
レガシーユーティリティ230は、win32コマンドライン実行ファイルなどの既存の実行ファイルを含む。それぞれのレガシーユーティリティ230は、オブジェクトフレームワーク内のある種のオブジェクトである、テキストストリーム(例えば、stdin、stdout、およびstderr)を使用して管理ツールフレームワークと通信する。レガシーユーティリティ230ではテキストストリームを使用するので、管理ツールフレームワークが備えるリフレクションベースのオペレーションは利用できない。レガシーユーティリティ230は、管理ツールフレームワークと異なるプロセスで実行される。図に示されていないが、他のcmdletsもプロセスから離れて動作可能である。
リモーティングcmdlets236は、Webサービスインターフェイス238と組み合わせて、インターネットまたはイントラネット(例えば、図2に示されているインターネット/イントラネット240)などの通信媒体を介して他のコンピューティング装置上で対話型およびプログラム管理ツール環境にアクセスするためのリモーティング機構を実現する。管理ツールフレームワークの一例では、リモーティング機構は、複数の独立の制御領域にまたがるインフラストラクチャに依存する連合サービスをサポートする。リモーティング機構により、リモートコンピューティング装置上でスクリプトを実行できる。スクリプトは、単一の、または複数のリモートシステム上で実行することができる。スクリプトの実行結果は、個々のスクリプトが完了する毎に処理するか、またはさまざまなコンピューティング装置上のスクリプトすべてが完了してからそれらの結果を集計し、一括して処理することができる。
例えば、ホストコンポーネント202の1つとして示されているWebサービス214は、リモートエージェントであってよい。他の実施形態では、Webサービス214は、通信媒体240を通じてエンジンと通信する別のコンポーネント(図に示されていない)とすることもできる。いずれの構成であっても、Webサービス214は、その後、cmdletsを制御するため他のホストコンポーネントと通信するように構成されたエンジンと通信する。リモートエージェントは、リモートコマンド要求をターゲットシステム上のパーザおよび管理ツールフレームワークにサブミットする動作を処理する。リモーティングcmdletsは、リモートエージェントにアクセスできるようにするリモートクライアントとして使用される。リモートエージェントおよびリモーティングcmdletsは、解析されたストリームを介して通信する。この解析されたストリームは、プロトコル層で保護されるか、または追加cmdletsを使用して解析されたストリームの暗号化および解読を行うようにできる。
(ホスト独立コンポーネント)
ホスト独立コンポーネント206は、パーザ220、スクリプトエンジン222、およびコアエンジン224を備える。ホスト独立コンポーネント206は、複数のcmdletsをグループ分けする機構およびサービスを提供し、cmdletsのオペレーションを調整し、他の資源、セッション、およびジョブとcmdletsとのやり取りを調整する。
(パーザの例)
パーザ220は、さまざまなホストプログラムから入力要求を受け取り、それらの入力要求をコアエンジン224などの中の管理ツールフレームワーク全体を通して使用される一様なcmdletsオブジェクトにマッピングする機構を備える。さらに、パーザ220は、受け取った入力に基づいてデータ処理を実行できる。パーザ220は、同じ機能に関して異なる言語または構文をユーザに簡単に公開する機能を備える。例えば、パーザ220は、入力要求を解釈する役割を担っているので、予想される入力構文に影響を及ぼすパーザ220内のコードに変更を加えると、管理ツールフレームワークの各ユーザに本質的な影響が及ぶ。したがって、システム管理者は、異なる構文をサポートする異なるコンピューティング装置上の異なるパーザを用意することができる。しかし、同じパーザを操作する各ユーザは、cmdlet毎に首尾一貫した構文を使用することになる。それとは対照的に、従来の環境では、それぞれのコマンドでその環境独自の構文を実装していた。そのため、数千ものコマンドがある場合には、それぞれの環境で数種類の構文をサポートし、それらの多くは互いに整合していなかった。
(スクリプトエンジンの例)
スクリプトエンジン222は、スクリプトを使用して複数のcmdletsを1つに結び合わせる機構およびサービスを提供する。スクリプトは、継承の厳密な規則に従ってセッション状態を共有するコマンドラインの集合体である。スクリプト内の複数のコマンドラインは、入力要求において与えられた構文に応じて、同期または非同期で実行できる。スクリプトエンジン222は、ループおよび条件節などの制御構造を処理し、スクリプト内の変数を処理する機能を有する。スクリプトエンジンは、さらに、セッション状態を管理し、ポリシー(図に示されていない)に基づきセッションデータへのアクセス権をcmdletsに与える。
(コアエンジンの例)
コアエンジン224は、パーザ220により識別されたcmdletsを処理する役割を担う。図4を簡単に参照すると、管理ツールフレームワーク200内のコアエンジン224の例が示されている。コアエンジン224の例は、パイプラインプロセッサ402、ローダ404、メタデータプロセッサ406、エラー&イベントハンドラ408、セッションマネージャ410、および拡張型マネージャ412を備える。
(メタデータプロセッサの例)
メタデータプロセッサ406は、図3に示されているデータベースストア314などのメタデータストア内のメタデータにアクセスおよび格納を行うように構成されている。メタデータは、cmdletクラス定義の範囲で、コマンドラインを介して、および類似の方法で供給することができる。管理ツールフレームワーク200内の異なるコンポーネントは、処理を実行するときにメタデータを要求することができる。例えば、パーザ202は、コマンドラインにおいて供給されるパラメータの妥当性を検証するためメタデータを要求することができる。
(エラー&イベントプロセッサの例)
エラー&イベントプロセッサ408は、コマンドラインの処理中にエラーが発生する毎に、エラーに関する情報を格納するエラーオブジェクトを提供する。
(セッションマネージャの例)
セッションマネージャ410は、セッションおよび状態情報を管理ツールフレームワーク200内の他のコンポーネントに供給する。セッションマネージャにより管理される状態情報は、cmdlet、ホスト、またはコアエンジンにより、プログラミングインターフェイスを介してアクセスすることができる。これらのプログラミングインターフェイスでは、セキュリティポリシー制約条件が適用される状態情報の作成、修正、および削除を考慮している。
(パイプラインプロセッサおよびローダの例)
ローダ404は、メモリ内に各cmdletをロードし、パイプラインプロセッサ402がcmdletを実行できるように構成される。パイプラインプロセッサ402は、cmdletプロセッサ420およびcmdletマネージャ422を備える。cmdletプロセッサ420は、個々のcmdletsをディスパッチする。cmdletが1つのリモートマシンまたはリモートマシン群上での実行を必要とする場合、cmdletプロセッサ420は、図2に示されているリモーティングcmdlet236と実行の調整を行う。cmdletマネージャ422は、cmdletsの集合体の実行を処理する。cmdletマネージャ422、cmdletプロセッサ420、およびスクリプトエンジン222(図2)は互いに通信し合い、ホストプログラム210〜214から受け取った入力について処理を実行する。通信は、その性質上、再帰的であってよい。例えば、ホストプログラムがスクリプトを備えている場合、スクリプトは、cmdletマネージャ422を呼び出して、それ自体がスクリプトであってもよいcmdletを実行することができる。その後、スクリプトは、スクリプトエンジン222により実行することができる。コアエンジンに対する1つのプロセスの流れの例について、図14を参照しつつ以下で詳述する。
(拡張型マネージャの例)
上述のように、管理ツールフレームワークは、複数のオブジェクトに対してリフレクションを実行でき、またその(オブジェクト)の型とは無関係にリフレクションされたオブジェクトに対し処理を実行できる一組のユーティリティを備えている。管理ツールフレームワーク200は、コンピューティングシステム上のコンポーネントフレームワーク(図1のコンポーネントフレームワーク120)と対話し、このリフレクションを実行する。当業者であれば、リフレクションはオブジェクトにクエリを行ってそのオブジェクトの型を取得し、その後、オブジェクトのその型に関連付けられているさまざまなオブジェクトおよびプロパティに対しリフレクションを実行して他のオブジェクトをおよび/または所望の値を取得する機能を備えていることが理解されよう。
リフレクションにより管理ツールフレームワーク200がオブジェクトに関するかなりの量の情報を得られるとしても、リフレクションはオブジェクトの型に注目する。例えば、データベースのデータテーブルがリフレクションされる場合、返される情報は、そのデータテーブルが列プロパティと行プロパティとの2つのプロパティを持つということである。これら2つのプロパティでは、そのデータテーブル内の「オブジェクト」に関する十分な詳細が得られない。拡張マークアップ言語(XML)および他のオブジェクト上でリフレクションが使用される場合にも同様の問題が生じる。
そのため、オブジェクトの型に注目する代わりに、拡張型マネージャ412では、型の使用に注目し、そのオブジェクトを必要な情報の取得に使用できるか否かを判別する。上記のデータテーブル例を続けると、データテーブルが列プロパティと行プロパティとを持つという事実は、特に関心を引くものではない。むしろ、関心を引くのは、1つの列が注目している情報を含むという点である。したがって、使用法に注目すると、拡張型マネージャ412は、各行を「オブジェクト」に関連付け、各列をその「オブジェクト」の「プロパティ」に関連付ける。そのため、拡張型マネージャ412は、任意の型の正確に解析可能な入力から「オブジェクト」を作成する機構を備える。そうする際に、拡張型マネージャ412は、コンポーネントベースのフレームワーク120が備えるリフレクション機能を補完し、「リフレクション」を任意の型の正確に解析可能な入力に拡張する。
大まかに言うと、拡張型マネージャは、正確に解析可能な入力(図に示されていない)にアクセスし、正確に解析可能な入力を要求されたデータ型と関連付けるように構成される。その後、拡張型マネージャ412は、要求された情報をパイプラインプロセッサ402またはパーザ220などの要求側コンポーネントに提供する。以下の説明では、正確に解析可能な入力は、プロパティおよび値を識別できる入力として定義される。いくつかの正確に解析可能な入力の例としては、Windows(登録商標)Management Instrumentation(WMI)入力、ActiveX Data Objects(ADO)入力、拡張マークアップ言語(XML)入力、および.NETオブジェクトなどのオブジェクト入力がある。他の正確に解析可能な入力としては、サードパーティのデータ形式が考えられる。
図13を簡単に参照すると、管理ツールフレームワーク内で使用するための拡張型マネージャ例のブロック図が示されている。説明のため、拡張型マネージャにより提供される機能(3)は、従来の密結合システム(1)により提供される機能およびリフレクションシステム(2)により提供される機能と対比されている。従来の密結合システムでは、アプリケーション内の呼び出し側1302は、直接、オブジェクトA内の情報(例えば、プロパティAおよびB、メソッドM1およびM2)に直接アクセスする。上述のように、呼び出し側1302は、先験的に、コンパイル時にオブジェクトAにより提供されるプロパティ(例えば、プロパティAおよびB)およびメソッド(例えば、メソッドM1およびM2)を知っていなければならない。リフレクションシステムでは、ジェネリックコード1320(データ型に依存しない)は、要求されたオブジェクトに対しリフレクション1310を実行し、オブジェクト(例えば、オブジェクトA)に関する情報(例えば、プロパティAおよびB、メソッドM1およびM2)をジェネリックコード1320に返すシステム1308に対しクエリを行う。オブジェクトAでは示されていないが、返される情報は、ベンダ、ファイル、日付などの補足情報を含むことができる。そのため、ジェネリックコード1320は、リフレクションを通じて、密結合システムが提供するのと少なくとも同じ情報を取得する。リフレクションシステムでは、さらに、呼び出し側1302は、システムにクエリを行い、パラメータを先験的に知ることなく補足情報を取得することができる。
密結合システムもリフレクションシステムも、新しいデータ型を動作環境内に簡単に組み込むことはできない。例えば、密結合システムでは、動作環境は、実現された後、新しいデータ型をサポートするため構築し直さなければならないため、新しいデータ型を組み込むことができない。同様に、リフレクションシステムでは、それぞれのオブジェクトクラスのメタデータは固定されている。そのため、新しいデータ型を組み込むことは、通常は行われない。
しかし、本発明の拡張型マネージャを使用すると、新しいデータ型をオペレーティングシステムに組み込むことができる。拡張型マネージャ1322を使用すると、ジェネリックコード1320は、要求されたオブジェクトに対するリフレクションを実行し、サードパーティオブジェクト(例えば、オブジェクトA’およびB)、意味論的Web(semantic web)1332、オントロジーサービス(ontology service)1334などのさまざまな外部ソースにより提供される拡張データ型(例えば、オブジェクトA’)を取得することができる。図に示されているように、サードパーティオブジェクトは、既存のオブジェクト(例えば、オブジェクトA’)を拡張するか、またはまったく新しいオブジェクト(例えば、オブジェクトB)を作成できる。
これらの外部ソースは、それぞれ型メタデータ1340内に一意的構造を登録し、コード1342を供給することができる。オブジェクトが照会されると、拡張型マネージャは、型メタデータ1340を再検討し、オブジェクトが登録されているか否かを判別する。オブジェクトが型メタデータ1340内に登録されていない場合、リフレクションが実行される。そうでない場合、拡張リフレクションが実行される。コード1342は、リフレクションを実行される型に関連付けられた追加プロパティおよびメソッドを返す。例えば、入力型がXMLの場合、コード1342は、XMLドキュメントからオブジェクトを作成するためにXMLを用いる方法を記述する記述ファイルを含むことができる。そのため、型メタデータ1340は、拡張型マネージャ412がさまざまな型の正確に解析可能な入力(例えば、サードパーティオブジェクトA’およびB、意味論的Web1332)に対しクエリを行って、その特定の入力型に対するオブジェクトを作成する所望のプロパティを取得する方法を記述し、コード1342は、それらの所望のプロパティを取得する命令を与える。その結果、拡張型マネージャ412は、あらゆる型のオブジェクトに対し「リフレクション」を実行できる間接層(layer of indirection)を提供する。
拡張型マネージャ412は、拡張型を備えるほかに、プロパティパス機構、キー機構、比較機構、変換機構、グロバー機構(globber mechanism)、プロパティセット機構、関係機構などの追加クエリ機構も備える。下記の「拡張型マネージャ処理例」の節で説明されているこれらのクエリ機構を使用することで、システム管理者は、コマンド文字列を入力するときに自由に作業できる。さまざまな手法を使用して、拡張型マネージャの意味論を実装することができる。以下では3つの手法について説明する。当業者であれば、請求されている発明の範囲から逸脱せずにこれらの手法の変更形態を使用できることを理解するであろう。
一手法では、静的メソッド(例えば、getproperty())を持つ一連のクラスを提供することができる。オブジェクトが静的メソッドに入力され(例えば、getproperty(object))、静的メソッドは一組の結果を返す。他の手法では、この動作環境はオブジェクトをアダプタで包む。そのため、入力は供給されない。アダプタのそれぞれのインスタンスは、包まれているオブジェクトに作用するgetpropertyメソッドを持ち、包まれているオブジェクトに対するプロパティを返す。この手法を例示する擬似コードを以下に示す。
さらに他の手法では、アダプタクラスがオブジェクトをサブクラス化する。従来、サブクラス化は、コンパイル前に実行されていた。しかし、いくつかの動作環境では、サブクラス化は動的に実行することができる。これらの型の環境について、この手法を例示する擬似コードを以下に示す。
そのため、図13に例示されているように、拡張型マネージャは、開発者が新しいデータ型を作成し、データ型を登録し、他のアプリケーションおよびcmdletがその新しいデータ型を使用できるようにする。それとは対照的に、以前の管理環境では、それぞれのデータ型からインスタンス化されるオブジェクトに関連付けられたプロパティまたはメソッドに直接アクセスできるように、コンパイル時にそれぞれのデータ型が知られていなければならなかった。したがって、管理環境によりサポートされる新しいデータ型の追加は、以前には滅多に実行されることはなかった。
図2を再び参照すると、概略として、管理ツールフレームワーク200は、ユーザによって入力されたコマンドの実行を調整するためシェルに依存せず、むしろ、機能を処理部分(例えば、ホスト独立コンポーネント206)とユーザ対話操作部分(例えば、ホストcmdletsを介して)とに分割する。さらに、管理ツール環境では、構文解析およびデータ妥当性検証に必要なコードはもはやそれぞれのコマンドに含まれず、むしろ、管理ツールフレームワーク内のコンポーネント(例えば、パーザ220)により提供されるため、管理ツールのプログラミングが大幅に簡素化される。管理ツールフレームワーク内で実行される処理の例について以下で説明する。
(オペレーションの例)
図5〜6は、管理ツール環境内で使用されるデータ構造例を示す。図7〜12は、管理ツール環境内の処理の流れの例を示す。当業者であれば、本発明の範囲を逸脱することなく特定の処理を後述のコンポーネントと異なるコンポーネントにより実行できることを理解するであろう。管理ツールフレームワークのコンポーネント内で実行される処理について説明する前に、管理ツールフレームワーク内で使用されるデータ構造例について説明する。
(cmdletオブジェクトのデータ構造例)
図5に、図2に示されている管理ツールフレームワーク内で使用するのに好適なcmdletを指定するための一データ構造例を示す。完了している場合、cmdletは、管理cmdlet、非管理cmdlet、ホストcmdlet、プロバイダcmdletなどであってよい。以下では、ソフトウェア開発者の視点からcmdletを作成することについて説明する(つまり、プロバイダcmdlet)。しかし、それぞれの型のcmdletは、同じ方法で作成され、似た動作をする。cmdletは、C#などどのような言語でも書くことができる。さらに、cmdletは、スクリプト言語などを使用して書くこともできる。管理ツール環境が.NET Frameworkで動作する場合、cmdletは.NETオブジェクトとすることができる。
プロバイダcmdlet500(これ以降、cmdlet500と呼ぶ)は、cmdletクラス名(例えば、StopProcess504)を持つパブリッククラスである。cmdlet500は、cmdletクラス506から派生する。cmdletクラス504のデータ構造例は、図6を参照しつつ以下で説明する。それぞれのcmdlet500は、名前(例えば、Stop/Process)をcmdlet500に関連付けるコマンド属性502に関連付けられる。この名前は、管理ツール環境内に登録される。後述のように、その名前(例えば、Stop/Process)を持つコマンド文字列がコマンドライン上の入力として、またはスクリプトで与えられる場合、パーザは、cmdletレジストリ内を探しcmdlet500を識別する。
cmdlet500は、cmdletへの予想される入力パラメータの文法を定義する文法機構に関連付けられる。文法機構は、cmdletに直接的にまたは間接的に関連付けられるようにできる。例えば、cmdlet500は、直接的文法関連付けを例示している。このcmdlet500では、1つまたは複数のパブリックパラメータ(例えば、ProcessName510およびPID512)が宣言される。パブリックパラメータの宣言は、cmdlet500への入力オブジェクトの構文解析を駆動する。それとは別に、パラメータの記述は、XMLドキュメントなどの外部ソース内にあってもよい。その後、この外部ソース内のパラメータの記述は、cmdletへの入力オブジェクトの構文解析を駆動する。
それぞれのパブリックパラメータ510、512は、それに関連付けられた1つまたは複数の属性(つまり、ディレクティブ)を持つことができる。それらのディレクティブは、構文解析ディレクティブ520、データ妥当性検証ディレクティブ521、データ生成ディレクティブ522、処理ディレクティブ523、符号化ディレクティブ524、およびドキュメンテーションディレクティブ525のカテゴリのうちのいずれかとすることができる。これらのディレクティブは、角括弧で囲むことができる。それぞれのディレクティブは、以下の予想される入力パラメータ上で実行されオペレーションを記述する。これらのディレクティブには、ユーザ対話操作型ディレクティブなどのクラスレベルで適用できるものもある。これらのディレクティブは、cmdletに関連付けられたメタデータ内に格納される。
これらの属性は、さらに、cmdlet内で宣言されたパラメータの母集団に影響を及ぼすことがある。これらのパラメータの母集団に対する一プロセスについて、図11を参照しつつ以下で説明する。コアエンジンは、適合性を保証するためにこれらのディレクティブを適用することができる。cmdlet500は、第1のメソッド530(これ以降、代わりにBeginProcessingメソッド530と呼ぶ)および第2のメソッド540(これ以降、ProcessRecordメソッド540と呼ぶ)を含む。コアエンジンは、第1および第2のメソッド530、540を使用して、cmdlet500の処理を指令する。例えば、第1のメソッド530は、1回実行され、セットアップ機能を実行する。第2のメソッド540内のコード542は、cmdlet500によって処理される必要のあるオブジェクト(例えば、レコード)毎に実行される。cmdlet500は、さらに、cmdlet500の後にクリーンアップする第3のメソッド(図に示されていない)を含むこともできる。
そのため、図5に示すように、第2のメソッド540内のコード542は、通常は、かなり簡潔であり、構文解析コード、データ妥当性検証コードなどの従来の管理ツール環境で必要とされる機能を含まない。そのため、システム管理者は、複雑なプログラミング言語学習せずとも複雑な管理タスクを開発することができる。
図6は、cmdletを指定するための例示的なデータ構造600である。概略として、データ構造600は、管理ツールフレームワークとcmdletとの間のコントラクトを明確に表すための手段を提供する。データ構造600は、cmdletクラス604から派生するパブリッククラスである。ソフトウェア開発者側では、「get/process」および「format/table」などの名詞/動詞ペアをcmdlet600に関連付けるcmdletDeclaration602を指定する。この名詞/動詞ペアは、管理ツール環境内に登録される。動詞または名詞は、cmdlet内で暗黙的であってよい。また、データ構造500と同様に、データ構造600は、1つまたは複数のパブリックメンバ(例えば、Name630、Recurse632)を含み、これは、データ構造500に関して説明されている1つまたは複数のディレクティブ520〜525に関連付けることができる。
しかし、このデータ構造600の例では、予想される入力パラメータ630および632はそれぞれ、入力属性631および633に関連付けられる。入力属性631および633では、それぞれのパラメータ630および632に対するデータをコマンドラインから取得するように指定する。そのため、このデータ構造600の例では、他のcmdletによって吐き出されたパイプライン化されたオブジェクトから設定(populate)される予想される入力パラメータはない。そこで、データ構造600は、cmdlet基本クラスによって与えられる第1のメソッド(例えば、BeginProcessing)または第2のメソッド(例えば、ProcessRecord)をオーバーライドしない。
データ構造600は、入力パラメータとして認識されない他のメンバ640も含むことができる。他のメンバ640は、ディレクティブの1つに基づいて生成されるデータを格納するために使用することができ、またプライベートでもパブリックでもよい。
したがって、データ構造600に例示されているように、特定のcmdletクラス内でパブリックのプロパティおよびディレクティブを宣言することを利用して、cmdlet開発者は、cmdletsへの予想される入力パラメータの文法を容易に指定することができ、かつcmdlet開発者側で基本ロジックを生成しなくても予想される入力パラメータに対し実行しなければならない処理を指定することができる。データ構造600は、cmdletと文法機構との間の直接的関連付けを例示している。上述のように、この関連付けは、XMLドキュメントなどの外部ソース内の予想されるパラメータ定義を指定するなどして、間接的であってもよい。
次に、管理ツール環境のプロセスの流れの例について説明する。
(ホスト処理の流れの例)
図7は、図2に示されている管理ツールフレームワーク内で実行されるホスト処理のプロセス例を示す論理流れ図である。プロセス700は、ブロック701から始まり、そこでは特定のアプリケーションについて管理ツール環境を起動する要求が届いている。要求は、アプリケーションアイコンを選択するなどのキーボード入力を通じてローカルで、または異なるコンピューティング装置のWebサービスインターフェイスを通じてリモートで、送信されている可能性がある。いずれのシナリオでも、処理はブロック702に続く。
ブロック702で、「ターゲット」コンピューティング装置上の特定のアプリケーション(例えば、ホストプログラム)は、その環境をセットアップする。これは、cmdlet(例えば、管理cmdlets232、非管理cmdelets234、およびホストcmdlets218)のどのサブセットをユーザが利用可能なようにするのかを決定すること含む。通常、ホストプログラムは、すべての非管理cmdlets234を利用可能にし、そのホストcmdlets218を利用可能にする。さらに、ホストプログラムは、プロセス、ディスクなどを処理するcmdletsなどの管理cmdlets234のサブセットを利用可能にする。そのため、ホストプログラムがcmdletsのサブセットを利用可能にすると、管理ツールフレームワークは、対応するアプリケーション内に効果的に埋め込まれる。処理は、ブロック704に続く。
ブロック704で、特定のアプリケーションを通じて入力が取得される。上述のように、入力は、コマンドライン、スクリプト、音声、GUIなどいくつかの形態を取りうる。例えば、入力がコマンドラインから得られる場合、入力は、キーボード上で入力されたキーストロークから取り出される。GUIホストについては、そのGUIに関連付けられた入力機構に基づいて文字列が構成される。処理は、ブロック706に続く。
ブロック706で、その入力は、管理ツールフレームワーク内の他のコンポーネントに送られ、そこで処理される。ホストプログラムは、その入力を直接パーザなどの他のコンポーネントに転送することができる。それとは別に、ホストプログラムは、そのホストcmdletsのうちの1つを介して入力を転送することもできる。ホストcmdletは、特定の型の入力(例えば、音声)を管理ツールフレームワークにより認識されるある型の入力(例えば、テキスト文字列、スクリプト)に変換することができる。例えば、音声入力を、その音声入力の内容に応じてスクリプトまたはコマンドライン文字列に変換することができる。それぞれのポストプログラムは、その型の入力を管理ツールフレームワークにより認識される入力に変換する役割を持つので、管理ツールフレームワークは、多数のさまざまなホストコンポーネントから入力を受け付けることができる。さらに、管理ツールフレームワークは、cmdletsの1つを介して入力が転送されるときにデータ型の間の変換を実行する豊富なユーティリティ群を備える。以下では、他のいくつかの図を参照しつつ、他のコンポーネントにより入力に対して実行される処理について説明する。ホスト処理は、決定ブロック708に続く。
決定ブロック708で、追加入力の要求が受け取られたか否かの判別が行われる。これは、入力を処理する役割を持つ他のコンポーネントのうちの1つが、その処理を完了するためにユーザからの追加情報を必要とする場合に実行されることがある。例えば、特定のデータにアクセスするためにパスワードが必要であったり、特定のアクションの確認が必要であったりする。いくつかの種類のホストプログラム(例えば、音声メール)では、このような要求は適切でない場合がある。そこで、ユーザが追加情報についてクエリを行う代わりに、ホストプログラムが状態をシリアライズし、状態を一時的に停止し、通知を送信して、後でその状態を再開し、入力の実行を継続できるようにする。他の変更形態では、ホストプログラムは、所定の期間の経過後に既定値を与えることができる。追加入力の要求が届いた場合、処理はブロック704にループバックし、そこで、追加入力が得られる。その後、処理は、上述のようにブロック706および708に続く。追加入力の要求を受け取らず、入力が処理済みの場合、処理はブロック710に続く。
ブロック710で、管理ツールフレームワーク内の他のコンポーネントから結果を受け取る。それらの結果は、エラーメッセージ、ステータス、進捗状況などを含むことができる。結果は、オブジェクト形態であり、管理ツールフレームワーク内のホストcmdletにより認識され、かつ処理される。後述のように、それぞれのホストcmdlet用に書かれたコードはまさに最小のコードである。そのため、開発コストに多大な投資を行うことなくさまざまな出力を表示することができる。処理は、ブロック712に続く。
ブロック712で、結果を表示することができる。ホストcmdletは、それらの結果をホストプログラムによってサポートされている表示スタイルに変換する。例えば、返されるオブジェクトは、アイコン、吠える犬などのグラフィック表現を使用してGUIホストプログラムにより表示することができる。ホストcmdletは、データの既定の形式および出力を与える。オプションにより結果が表示された後、ホスト処理は完了である。
(入力を処理するためのプロセスの流れの例)
次にコマンド文字列を処理するプロセスの一例について説明する。図8は、図2に示されている管理ツールフレームワーク内のパーザ220およびコアエンジン224によるコマンド文字列850の処理をグラフィックで例示する機能流れ図である。コマンド文字列850の例では、複数のコマンド(つまり、processコマンド860、whereコマンド862、sortコマンド864、およびtableコマンド866)をパイプラインで送る。コマンドライン850では、入力パラメータをコマンドのどれかに受け渡すことができる(例えば、「handlecount>400」はwhereコマンド862に渡される。)processコマンド860は、関連付けられた入力パラメータを持たないことに注意されたい。
パーザ220は、解析可能なストリーム(例えば、コマンド文字列850)を解析して、構成要素820〜826(例えば、where部分822)に分ける。それぞれの部分820〜826は、cmdlets830〜836の1つに関連付けられる。パーザ220およびエンジン224は、構文解析、パラメータ妥当性検証、データ生成、パラメータ処理、パラメータ符号化、およびパラメータドキュメンテーションなどのさまざまな処理を実行する。パーザ220およびエンジン224は、コマンドライン上で入力パラメータに対し共通機能を実行するので、管理ツールフレームワーク200は、一貫したエラーメッセージをユーザに発行することができる。
理解できるであろうが、実行可能なcmdlets830〜836では、従来の管理環境のコマンドと比べて必要とするコードは小さい。それぞれの実行可能なcmdlet830〜836は、それぞれの構成要素820〜826を使用して識別される。さらに、それぞれの実行可能なcmdlet830〜836は、次のパイプライン化されたcmdletに入力オブジェクト(矢印841、843、および845により表される)として入力されるオブジェクト(矢印840、842、844、および846により表される)を出力する。これらのオブジェクトは、オブジェクトに参照(例えば、ハンドル)を受け渡すことにより入力することができる。その後、実行可能なcmdlets830〜836は、中に渡されたオブジェクト上で追加処理を実行することができる。
図9は、コマンド文字列の処理をさらに詳しく例示する論理流れ図である。コマンド文字列処理は、ブロック901から始まるが、そこではパーザまたはスクリプトエンジンが入力内のコマンド文字列を識別している。一般に、コアエンジンは、cmdletsのデータの流れのセットアップおよび順序付けを実行する。1つのcmdletのセットアップおよび順序付けについて以下で説明するが、これは、パイプライン内のそれぞれのcmdletに適用可能である。処理は、ブロック904に続く。
ブロック904で、cmdletが識別される。cmdletの識別は、登録を使用することもできる。コアエンジンでは、cmdletがローカルであるか、リモートであるかを判別する。cmdletは、1)管理ツールフレームワークのアプリケーション領域内で、2)管理ツールフレームワークと同じプロセスの他のアプリケーション領域内で、3)同じコンピューティング装置上の他のプロセス内で、または4)リモートコンピューティング装置内で実行する。同じプロセス内で動作するcmdelets同士の間の通信は、オブジェクト経由で行われる。異なるプロセス内で動作するcmdlets間の通信は、シリアライズされた構造化データ形式を経由する。シリアライズされた構造化データ形式の一例は、拡張マークアップ言語(XML)に基づく。処理は、ブロック906に続く。
ブロック906で、cmdletオブジェクトのインスタンスが作成される。cmdletのインスタンスを作成するプロセス例は、図10を参照しつつ以下で説明する。cmdletオブジェクトが作成されると、処理はブロック908に続く。
ブロック908で、cmdletオブジェクトに関連付けられているプロパティが設定(populate)される。上述のように、開発者は、cmdletクラス内、または外部ソース内でプロパティを宣言する。簡単に言うと、管理ツールフレームワークは、そのプロパティについて宣言されている名前および型に基づきcmdletクラスからインスタンス化されたcmdletに対する(複数の)送られて来るオブジェクトを解読するということである。それらの型が異なる場合、その型が拡張データ型マネージャを介して課せられるようにできる。前述のように、パイプライン化されたコマンド文字列内のそれぞれのcmdletの出力は、オブジェクトへのハンドルのリストであってよい。次のcmdletは、このオブジェクトハンドルのリストを入力し、処理を実行し、他のオブジェクトハンドルのリストを次のcmdletに受け渡すことができる。さらに、図6に例示されているように、入力パラメータをコマンドラインから送られて来るものとして指定することもできる。cmdletに関連付けられているプロパティの設定の方法の一例について、図11を参照しつつ以下で説明する。cmdletの設定が行われた後、処理はブロック910に続く。
ブロック910で、cmdletが実行される。概略として、cmdletにより行われる処理は、少なくとも1回実行され、これは、cmdletへの各入力オブジェクトの処理を含む。そこで、cmdletがパイプライン化されたコマンド文字列内の第1のcmdletである場合、処理は1回実行される。後続のcmdletsについては、処理は、cmdletに渡されるオブジェクト毎に実行される。cmdletsを実行する一方法について、図5を参照しつつ以下で説明する。入力パラメータがコマンドラインからしか来ない場合、cmdletの実行では基本のcmdletの場合に用意される既定の方法を使用する。cmdletの実行が終了すると、処理はブロック912に続く。
ブロック912で、cmdletがクリーンアップされる。これは、割り当てられたメモリの解放などを受け持つ、関連付けられているcmdletオブジェクトのデストラクタを呼び出すことを含む。そこでコマンド文字列の処理は完了する。
(cmdletオブジェクトを作成するプロセスの例)
図10は、図9に示されているコマンド文字列の処理内で使用するのに好適なcmdletオブジェクトを作成するプロセス例を示す論理流れ図である。この時点で、cmdletデータ構造は、作成済みであり、属性および予想される入力パラメータはすでに指定されている。cmdletは、コンパイルされ、登録されている。登録時に、クラス名(つまり、cmdlet名)が登録ストア内に書き込まれ、cmdletに関連付けられたメタデータは、格納済みである。プロセス1000は、ブロック1001から始まり、そこで、パーザはcmdletを示す入力(例えば、キーストローク)を受け取っている。パーザは、レジストリ内から入力を検索し、その入力を登録済みのcmdletsの1つに関連付けることにより、入力をcmdletとして認識することができる。処理は、ブロック1006に進む。
ブロック1006に進む前に、cmdletオブジェクトクラスに関連付けられているメタデータが読み込まれる。メタデータは、cmdletに関連付けられたディレクティブのいずれかを含む。それらのディレクティブを、cmdlet自体またはパラメータのうちの1つまたは複数に適用することができる。cmdletの登録時に、登録コードは、メタデータを永続的ストアに登録する。メタデータは、シリアライズ形式でXMLファイル、および外部データベースなどに格納されることができる。各カテゴリのディレクティブは、異なる段階で処理される。それぞれのメタデータディレクティブは、それ独自のエラー処理を行う。
ブロック1006で、cmdletオブジェクトは、識別されたcmdletクラスに基づいてインスタンス化される。処理は、ブロック1008に続く。
ブロック1008で、cmdletに関する情報が取得される。これは、リフレクションまたはその他の手段を通じて実行することができる。この情報は、予想される入力パラメータに関する情報である。上述のように、パブリックと宣言されたパラメータ(例えば、パブリック文字列Name 630)は、コマンドライン上のコマンド文字列で指定でき、または入力ストリーム内で与えることができる予想される入力パラメータに対応する。図13で説明されている、拡張型マネージャを経由した管理ツールフレームワークは、情報を(必要に応じて)呼び出し側に返すための共通インターフェイスを備える。処理は、ブロック1010に続く。
ブロック1010で、適用性ディレクティブ(applicability directives)が適用される。適用性ディレクティブは、そのクラスが特定のマシン役割および/またはユーザ役割で使用されることを保証する。例えば、いくつかのcmdletsは、ドメイン管理者のみが使用できる。適用性ディレクティブの1つで指定された制約条件が満たされない場合、エラーが発生する。処理は、ブロック1012に続く。
ブロック1012で、メタデータが使用される。処理中のこの時点では、コマンド文字列全体はまだ入力されていない。しかし、管理ツールフレームワークは、使用可能なcmdletsを知っている。cmdletが決定されると、管理ツールフレームワークは、cmdletオブジェクトに対してリフレクションを実行することにより使用できるようになる入力パラメータを認識する。そこで、管理ツールフレームワークは、cmdlet名の曖昧でない部分が与えられると、cmdletをオートコンプリートし、その後、入力パラメータの曖昧でない部分がコマンドライン上で入力されると、入力パラメータをオートコンプリートすることができる。オートコンプリートは、入力パラメータの一部が入力パラメータの1つをはっきりと識別できると、すぐに実行することができる。さらに、オートコンプリートは、cmdlet名およびオペランドでも実行できる。処理は、ブロック1014に続く。
ブロック1014で、プロセスは、cmdletに対する入力パラメータが入力されるまで待つ。これは、ユーザがリターンキーを押すなどによりコマンド文字列の終わりを指示すると実行される。スクリプトでは、改行がコマンド文字列の終わりを示す。この待機は、ユーザからパラメータに関する追加情報を取得し、他のディレクティブを適用することを含むことができる。cmdletがパイプライン化されたパラメータの1つであれば、処理は即座に開始することができる。必要なコマンド文字列および入力パラメータが与えられると、処理は完了である。
(cmdletの初期値設定のプロセスの例)
cmdletの設定のプロセスの例は図11に示されており、次に、図5を参照しつつ説明する。管理ツールフレームワークでは、コアエンジンは、cmdletのパラメータの設定をする処理を実行する。処理は、cmdletのインスタンスが作成された後、ブロック1101から始まる。処理は、ブロック1102に続く。
ブロック1102で、cmdlet内で宣言されたかパラメータ(例えば、ProcessName)が取り出される。cmdletでの宣言に基づき、コアエンジンは、送られて来る入力オブジェクトが「ProcessName」という名前のプロパティを与えることを認識する。送られて来るプロパティの型がパラメータ宣言で指定された型と異なる場合、その型は、拡張型マネージャを介して課される。データ型を課すプロセスについては、以下の「拡張型マネージャの処理の例」という表題の小節で説明する。処理は、ブロック1103に続く。
ブロック1103で、このパラメータに関連付けられている属性が取得される。この属性で、パラメータに対する入力ソースがコマンドラインであるか、それともパイプラインからであるかを識別する。処理は、決定ブロック1104に続く。
決定ブロック1104で、その属性が入力ソースをコマンドラインとして指定するか否かの決定が行われる。入力ソースがコマンドラインの場合、処理はブロック1109に続く。そうでない場合、処理は、決定ブロック1105に続く。
決定ブロック1105で、宣言の中で指定されたプロパティ名が使用されるか、またはプロパティ名に対するマッピングが使用されるのかの決定が行われる。この決定は、コマンド入力でパラメータに対するマッピングを指定したか否かに基づく。以下の行は、パラメータ「ProcessName」を送られて来るオブジェクトの「foo」メンバにマッピングする例を示している。
$get−process|where{$_.hcount−gt 500}|stop−process−ProcessName<−foo.
処理は、ブロック1106に続く。
ブロック1106で、マッピングが適用される。このマッピングで、予想されるパラメータの名前が「ProcessName」から「foo」に置き換えられ、その後、コアエンジンはこれを使用して、送られて来るオブジェクトを解析し、正しい予想されるパラメータを識別する。処理は、ブロック1108に続く。
ブロック1108で、拡張型マネージャに対しクエリが実行され、送られて来るオブジェクト内のパラメータの値が特定される。拡張型マネージャに関して説明するように、拡張型マネージャは、パラメータ名を受け取り、リフレクションを使用して、パラメータ名を持って送られて来るオブジェクト内のパラメータを識別する。拡張型マネージャは、さらに、必要ならば、パラメータの他の処理を実行することもできる。例えば、拡張型マネージャは、上述の変換機構を通じて、データの型をデータの予想される型に強制することができる。処理は、決定ブロック1110に続く。
ブロック1109に再び戻ると、この属性で、入力ソースがコマンドラインであると指定された場合、コマンドラインからのデータが取得される。コマンドラインからデータを取得する作業は、拡張型マネージャを介して実行することができる。その後、処理は、決定ブロック1110に続く。
決定ブロック1110で、他の予想されるパラメータがあるか否かの判別が行われる。他の予想されるパラメータがある場合、処理は、ブロック1102にループバックし、上述のように進行する。そうでない場合、処理は完了し戻る。
そこで、図に示されているように、cmdletsは、送られて来るデータをシュレッディングするためのテンプレートとして動作して予想されるパラメータを取得する。さらに、予想されるパラメータは、予想されるパラメータの値を与える、送られて来るオブジェクトの型を知らなくても得られる。これは、従来の管理環境とはかなり異なる。従来の管理環境は、密結合であり、オブジェクトの型がコンパイル時に判明している必要がある。さらに、従来の環境であれば、予想されるパラメータは、値渡しまたは参照渡しにより関数に受け渡されているところである。そのため、本発明の解析(例えば、「シュレッディング」)機構では、プログラマは、それらのパラメータの値の取得方法を具体的に知らなくてもパラメータの型を指定することができる
例えば、cmdlet Fooに対する以下の宣言が与えられると、
コマンドライン構文は以下のいずれかとすることができる。
所望の構文を得るために、システム管理者側で規則の集まりを修正することができる。さらに、パーザは、ユーザが複数の構文を使用できるように複数の規則の集まりをサポートできる。本質的に、cmdlet構造(例えば、文字列NameおよびBool Recurse)に関連付けられた文法によりパーザが駆動される。
一般に、解析ディレクティブは、コマンド文字列として入力されたパラメータをcmdletオブジェクト内で識別された予想されるパラメータにマッピングする方法を記述する。入力パラメータ型のチェックが行われて、正しいか否かの判定が行われる。入力パラメータ型が正しくない場合、入力パラメータは、正しいパラメータになることを課すことができる。入力パラメータ型が正しくなく、修正することができない場合、使用法エラーが表示される。使用法エラーでは、ユーザは予想される正しい構文を認識することができる。使用法エラーは、ドキュメンテーションディレクティブから構文を記述する情報を取得することができる。入力パラメータ型がマッピングされるか、または検証されている場合、cmdletオブジェクトインスタンス内の対応するメンバは設定が行われる。メンバの設定が行われると共に、拡張型マネージャは、入力パラメータ型の処理を行う。簡単に言うと、処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバー機構、関係機構、およびプロパティセット機構を含むことができる。これらの機構は、それぞれ、以下の「拡張型マネージャの処理」という表題の節で説明するが、さらに図例も含む。
(cmdletを実行するプロセスの例)
cmdletを実行するプロセスの例を図12に示すが、次に説明する。管理ツール環境の一実施例では、コアエンジンがcmdletを実行する。上述のように、第2のメソッド540内のコード542は、入力オブジェクト毎に実行される。処理は、ブロック1201から始まるが、cmdletはすでに設定済みである。処理は、ブロック1202に続く。
ブロック1202で、コード542からのステートメントが実行のため取り出される。処理は、ブロック1206に続く。
ブロック1206で、そのステートメントが処理される。その後、処理は、決定ブロック1208に進む。ブロック1208で、コードに他のステートメントが含まれているか否かの判別が行われる。他のステートメントがある場合、処理はブロック1202にループバックし、次のステートメントを取得し、上述のように進行する。そうでない場合、処理は、決定ブロック1214に続く。
決定ブロック1214で、処理すべき他の入力オブジェクトがあるか否かの判別が行われる。他の入力オブジェクトがある場合、処理はブロック1216に進み、cmdletに次のオブジェクトからのデータが設定される。図10で説明されている設定プロセスは、次のオブジェクトで実行される。その後、処理は、ブロック1202にループバックし、上述のように進行する。すべてのオブジェクトが処理された後、cmdletを実行するプロセスが完了し、戻る。
(拡張型マネージャの処理例)
図13を参照しつつ上で簡単に述べたように、拡張型マネージャは、供給されるオブジェクト上で追加処理を実行することができる。追加処理は、パーザ220、スクリプトエンジン222、またはパイプラインプロセッサ402の要求時に実行することができる。追加処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバー機構、関係機構、およびプロパティセット機構を含む。当業者であれば、請求されている発明の範囲から逸脱せずに、拡張型マネージャはさらに他の処理とともに拡張できることを理解するであろう。次に、追加処理機構のそれぞれについて説明する。
最初に、プロパティパス機構は、文字列でオブジェクトのプロパティをナビゲートすることができる。従来のリフレクションシステムでは、複数のクエリによりオブジェクトのプロパティにクエリを行うことができる。しかし、本発明の拡張型マネージャでは、オブジェクトの次々に続く複数のプロパティへのナビゲーションパスを与える文字列を指定できる。以下は、プロパティパスA.B.C.Dの構文例を説明している。
それぞれのコンポーネント(例えば、A、B、C、およびD)は、プロパティ、パラメータ付きメソッド、パラメータなしメソッド、フィールド、XPATHなどを表すことができる文字列を含む。XPATHは、要素を検索するクエリ文字列を指定する(例えば、「/FOO@=13」)。この文字列内には、特にコンポーネントの型を示すために特殊文字を含めることができる。文字列が特殊文字を含まない場合、拡張型マネージャは、検索を実行し、コンポーネントの型を判別することができる。例えば、コンポーネントAがオブジェクトの場合、拡張型マネージャは、Bがオブジェクトのプロパティなのか、オブジェクトに対するメソッドなのか、オブジェクトのフィールドなのか、プロパティセットなのかについてクエリを行うことができる。拡張型マネージャがBの型を識別した後、その型に応じた処理が実行される。コンポーネントが上記の型の1つでない場合、拡張型マネージャは、さらに、拡張ソースにクエリを行って、Aの型をBの型に変換する変換関数があるか否かを判別することができる。これらおよび他の検索について、コマンド文字列の例を使用し、それぞれの出力を示して説明することにする。
プロパティパスを含む文字列例を以下に示す。
$ get−process|where{$_.handlecount−gt 500}|format−table name.toupper,ws.kb,exe*.ver*.description.tolower.trunc(30).
上記の文字列の中には、3つのプロパティパス、(1)「name.toupper」、(2)「ws.kb」、および(3)「exe*.ver*.description.tolower.trunc(30)」がある。これらのプロパティパスについて説明する前に、「name」、「ws」、および「exe」はテーブルのプロパティを指定することに留意されたい。さらに、これらのプロパティはそれぞれ、「get/process」により元々生成され、その後、さまざまなcmdletsを通じてパイプラインで送られる、送られて来るオブジェクトの直接プロパティであることに留意されたい。次に3つのプロパティパスのそれぞれについてかかわる処理について説明する。
第1のプロパティパス(つまり、「name.toupper」)で、nameは、送られて来るオブジェクトの直接プロパティであり、オブジェクトそれ自体でもある。拡張型マネージャは、上述の優先度検索を使用してシステムにクエリを行い、toupperに対する型を判別する。拡張型マネージャは、toupperがプロパティでないことを発見する。しかし、toupperは、文字列型により継承され、文字列内の小文字を大文字に変換するメソッドであるかもしれない。それとは別に、拡張型マネージャは、拡張メタデータへのクエリを行って、名前オブジェクトを大文字に変換できるサードパーティコードがあるか否かを判別する場合もある。コンポーネント型を見つけた後、そのコンポーネント型に応じて処理が実行される。
第2のプロパティパス(つまり、「ws.kb」)で、「ws」は、送られて来るオブジェクトの直接プロパティであり、オブジェクトそれ自体でもある。拡張型マネージャは、「ws」が整数であると判別する。次に、拡張型マネージャは、kbは整数のプロパティか、kbが整数のメソッドであるかについてクエリを行い、そして最後に、コードが整数を受け取って、kb型に変換する方法を認識しているか否かについてクエリを行う。サードパーティコードは、この変換を実行するために登録され、変換が実行される。
第3のプロパティパス(つまり、「exe*.ver*.description.tolower.trunc(30)」)に、複数のコンポーネントがある。第1のコンポーネント(「exe」)は、送られて来るオブジェクトの直接プロパティであり、またオブジェクトでもある。ここでもまた、拡張型マネージャは、検索クエリを続けて、第2のコンポーネント(「ver*」)を処理する。「exe*」オブジェクトは、「ver*」プロパティまたはメソッドを持たないため、拡張型マネージャは、拡張メタデータについてクエリを行い、実行可能ファイル名をバージョンに変換するために登録されているコードがあるか否かを判別する。この例については、そのようなコードが存在する。このコードは、実行可能ファイル名文字列を受け取り、それを使用してファイルを開き、その後、バージョンブロックオブジェクトにアクセスし、バージョンブロックオブジェクトの記述プロパティ(第3のコンポーネント「description」)を返すことができる。次に、拡張型マネージャは、この同じ検索機構を第4のコンポーネント(「tolower」および第5のコンポーネント(「trunc(40)」)に対して実行する。そこで、例示されているように、拡張型マネージャは、きわめて手の込んだ処理をコマンド文字列に対して実行することができ、しかも管理者が特定のコードを書く必要がない。表1は、例示されている文字列について生成される出力を示している。
他のクエリ機構1324は、キーを含む。キーは、データ型のインスタンスを一意的にする1つまたは複数のプロパティを識別する。例えば、データベース中の1つの列は、各行(例えば、社会保障番号)を一意に識別できるキーとして識別することができる。キーは、そのデータ型に関連付けられている型メタデータ1340内に格納される。その後、このキーは、そのデータ型のオブジェクトを処理するときに拡張型マネージャにより使用されうる。データ型は、拡張データ型でも既存のデータ型でもよい。
他のクエリ機構1324は、比較機構を含む。簡単に言うと、図14〜23を参照しつつ以下で詳しく説明するが、比較機構は2つのオブジェクトを比較する。2つのオブジェクトが比較関数を直接サポートしている場合、直接サポートされている比較関数が実行される。しかし、いずれのオブジェクトも比較関数をサポートしていない場合、拡張型マネージャは、型メタデータ内で、2つのオブジェクトの間の比較をサポートするために登録されているコードを探すことができる。比較機構を呼び出す一連のコマンドライン文字列の例を、表2の対応する出力とともに、以下に示す。
compare−time cmdletは、2つの日時オブジェクトを比較するために書かれている。この場合、DateTimeオブジェクトはIComparableインターフェイスをサポートする。
他のクエリ機構1324は、変換機構を含む。拡張型マネージャを使用することにより、特定の変換を実行する機能を記述しているコードを登録することができる。その後、型Aのオブジェクトが入力され、cmdletで型Bのオブジェクトを指定した場合、拡張型マネージャは、登録済みの変換のうちの1つを使用して変換を実行することができる。拡張型マネージャは、一連の変換を実行することで、型Aを型Bに課すことができる。上述のプロパティパス(「ws.kb」)は、変換機構を例示している。
他のクエリ機構1324は、グロバー機構を含む。グロバーは、文字列内のワイルドカード文字を指す。グロバー機構は、ワイルドカード文字を含む文字列を入力し、オブジェクトの集合を出力する。拡張型マネージャでは、ワイルドカード処理を指定するコードを登録することができる。上述のプロパティパス(「exe*.ver*.description.tolower.trunc(30)」)は、グロバー機構を例示している。登録されているプロセスは、ファイル名、ファイルオブジェクト、送られて来るプロパティなどのグロビング(globbing)機能を備えることができる。
他のクエリ機構1324は、プロパティセット機構を含む。プロパティセット機構では、プロパティの集合に対し名前を定義することができる。その後、管理者は、コマンド文字列内で名前を指定してプロパティの集合を取得することができる。プロパティセットは、さまざまな方法で定義できる。一方法では、「?」などの定義済みパラメータは、cmdletの入力パラメータとして入力できる。定義済みパラメータを認識した後の動作環境では、送られて来るオブジェクトのプロパティをすべてリストに列挙する。このリストは、管理者が所望のプロパティを容易にチェック(例えば、「クリックオン」)し、プロパティセットに名前を付けるために使用されるGUIであってよい。その後、プロパティセット情報は、拡張メタデータ内に格納される。プロパティセット機構を呼び出す文字列の例を、表3の対応する出力とともに、以下に示す。
$ get−process|where{$_.handlecount−gt 500}|format−table config.
この文字列の例では、「config」という名前のプロパティセットは、名前プロパティ、プロセスidプロパティ(Pid)、および優先度プロパティを含むものとして定義されている。このテーブルの出力を以下に示す。
他のクエリ機構1324は、関係機構を含む。1つの関係(つまり、継承)をサポートする従来の型システムとは対照的に、関係機構では、型間の複数の関係を表すことをサポートする。ここでもまた、これらの関係は登録される。関係は、オブジェクトが消費するアイテムを見つけること、またはオブジェクトを消費するアイテムを見つけることを含むことができる。拡張型マネージャは、さまざまな関係を記述するオントロジーにアクセスすることができる。拡張メタデータおよびコードを使用することにより、OWL、DAWLなどのオントロジーサービスにアクセスするための仕様を記述することができる。.OWL:“string”は、関係機構を使用する例示文字列の一部である。
「OWL」識別子で、オントロジーサービスを識別し、「string」で、オントロジーサービス内の特定の文字列を指定する。そのため、拡張型マネージャは、オントロジーサービスにより与えられる型にアクセスすることができる。
第3節:比較手法の例
図14〜23は、上記の第2節で説明されているオブジェクトベースの管理ツールフレームワーク内で稼働する本発明の比較手法の複数の実施例を示す。本発明の比較手法は、従来の比較手法に勝るいくつかの利点を有する。例えば、本発明の比較手法を使用すると、異なるデータ型のオブジェクト同士を比較することができる。さらに、比較手法からの結果を、最終的に問題を解決することができる他のオペレーションへの入力として自動的に使用できる。これらおよびその他の利点は、以下の詳細な説明を読むと明らかになるであろう。
図14は、図2に示されているオブジェクトベースの管理フレームワーク内に実装されているcompare cmdletの構文例のいくつかの実施形態を示している。第1の構文1400は、図16に示される流れ図を参照しつつ説明されるキーベースの比較に対応している。第2の構文1401は、図17に示されている流れ図を参照しつつ説明される順序ベースの比較に対応する。2つの比較手法を区別するために、compare−object cmdletが呼び出されるときにKeyBasedパラメータ1406またはOrderBasedパラメータ1408がコマンド文字列内に含まれる。KeyBasedパラメータ1406は、スイッチ(例えば、「−KeyBased」)およびキー名を伴う。キー名は、比較されるオブジェクトを識別する。その後、そのキー名に関連付けられているプロパティを持つオブジェクトのみが比較に含まれる。キー名は、単一のプロパティでも、プロパティの集合でもよい。
第1の構文1400と第2の構文1401は両方とも、他のパラメータを含む。一般に、パラメータのほとんどはスイッチおよびデータを含む。スイッチは、compare−object cmdletを呼び出すときにコマンド文字列内に現れる所定のテキストを表す。データは、このスイッチに依存する。例えば、いくつかのスイッチは、論理データに関連付けることができる。他のスイッチは、プロパティに関連付けることができる。これらのスイッチの一部は、関連付けられたデータを持つコマンド文字列内に含まれない場合がある。このような場合、コマンド文字列内に入力されているデータは、順序に依存することになるか、または少なくとも、compare cmdletの定義内の入力パラメータについて指定された属性に依存しうる。次に、これら他のパラメータのそれぞれについて、個別に説明する。
ReferenceObjectパラメータ1402は、「−ReferenceObject」スイッチおよび参照オブジェクトを含む。参照オブジェクトは、他のオブジェクトと比較される1つまたは複数のオブジェクトを識別する。
ComparisonObjectパラメータ1404は、「−ComparisonObject」スイッチおよび比較オブジェクトを含む。比較オブジェクトは、参照オブジェクトと比較される1つまたは複数のオブジェクトを識別する。図に示されるように、比較オブジェクトは、オブジェクトベースのパイプラインから供給されうる。
そのため、参照オブジェクトは、スタンダードとして使用され、任意の個数の比較オブジェクトと比較されることができる。例えば、参照オブジェクトは、コンピューティング装置の標準構成とすることができ、それぞれの比較オブジェクトは、システム管理者が標準構成に類似の構成をとりたい異なるコンピューティング装置に対応することができる。
Propertyパラメータ1410は、「−Property」スイッチおよびプロパティ名を含む。プロパティ名は、1つまたは複数のプロパティをリストにしたもの、またはプロパティの集合をリストにしたものとすることができる。Propertyパラメータ1410を使用すると、複数のオブジェクト内のすべてのプロパティを比較する代わりに、特定のプロパティを比較することができる。このように特定のプロパティを指定できると、報告される重要でない相違点の数が最小限に抑えられる。例えば、Process Aが現在は動作していない(これ以降、Today Process Aと呼ぶ)が、昨日は動作していた(これ以降、Yesterday Process Aと呼ぶ)場合、Propertyパラメータ1410は、比較の中に含まれることによってToday Process AとYesterday Process Aとの間の違いが分かるプロパティ(例えば、CPU時間、ワーキングセット)にすることができる。そのため、本発明の比較手法の出力は、より参考になる情報を提供し、失敗の理由を突き止めるのに役立つ。
CaseSensitiveパラメータ1412は、「−CaseSensitive」スイッチおよび「False」または「True」を示すオプションの論理値を含む。「−CaseSensitive」スイッチが「False」値とともに含まれる場合、参照オブジェクトおよび比較オブジェクトの中の文字列の大文字小文字の区別は考慮されない。逆に、「True」値が指定されている場合、文字列の大文字小文字の区別は、相違点を判別する際に考慮される。CaseSensitiveパラメータ1412は、参照オブジェクトおよび比較オブジェクトが文字列型である場合に使用できる。他のデータ型については、CaseSenstiveパラメータ1412は無視される。
Cultureパラメータ1414は、「−Culture」スイッチおよびカルチャ設定値を含む。指定されたカルチャ設定値は、現在のカルチャ設定をオーバーライドする。参照オブジェクトおよび比較オブジェクトは、両方とも、同じカルチャを持つものとして処理される。Cultureパラメータ1414は、参照オブジェクトおよび比較オブジェクトが文字列型であり、同じ言語を使用してテキストの比較が実行されることを保証する場合に使用することができる。他のデータ型については、Cultureパラメータ1414を無視できる。
IgnoreWhiteSpaceパラメータ1416は、「−IgnoreWhiteSpace」スイッチおよびオプションの論理値を含む。論理値が「False」の場合、比較の際に空白類はテキストの一部であるとみなされる。逆に、論理値が「True」の場合、比較時にテキスト内の空白類は無視される。IgnoreWhiteSpace 1416は、参照オブジェクトおよび比較オブジェクトが文字列型である場合に使用できる。他のデータ型については、IgnoreWhiteSpaceパラメータ1416は無視される。
RecordDifferenceパラメータ1418は、「−RecordDifference」スイッチおよびオプションの論理値を含む。論理値が「False」の場合、参照オブジェクトと比較オブジェクトとの間の相違点は出力に送られない。逆に、論理値が「True」の場合、相違点は出力に送られる。
RecordEqualパラメータ1420は、「−RecordEqual」スイッチおよびオプションの論理値を含む。論理値が「False」の場合、同じ値を持つ参照オブジェクトと比較オブジェクトのプロパティは出力に送られない。論理値が「True」の場合、同じ値を持つ参照オブジェクトと比較オブジェクトのプロパティは出力に送られる。
PassThruパラメータ1422は、「−PassThru」スイッチおよびオプションの論理値を含む。論理値が「False」の場合、比較の結果、キー名、プロパティ値、イコールインジケータ、およびsideIndicatorが出力される。sideIndicatorは、出力が参照オブジェクトに関連付けられているか否か、または出力が比較オブジェクトに関連付けられているか否かをグラフィックで示す。例えば、左sideIndicator「<=」は、後に続く情報が参照オブジェクトからであることを示す。右sideIndicator「=>」は、後に続く情報が比較オブジェクトからであることを示す。イコールインジケータ「==」は、比較オブジェクトと参照オブジェクトとが同じ値を持つことを示す。論理値が「True」の場合、参照オブジェクトと比較オブジェクトの両方が注釈され、出力される。本発明の比較手法の範囲から逸脱することなく、さまざまな文字および/またはグラフィックスをsideIndicatorに使用できることに留意されたい。
図15は、compare cmdletを呼び出すコマンド文字列を例示し、また生成された出力を例示するいくつかの実施例を示している。これらの実施例1510および1520は両方とも、テーブル1502およびテーブル1504に示されている実施例に基づく。テーブル1502および1504は、両方とも、2行、2列、Process NameおよびHandlecountを持つ。第1の行は、Process Nameとして「MSH」を持つプロセスに対応し、第2の行は、Process Nameとして「Calc」を持つプロセスに対応する。テーブル1502では、MSHに対するhandlecountは100であり、Calcに対するhandlecountは100である。テーブル1504では、MSHに対するhandlecountはそのまま100であり、Calcに対するhandlecountは500である。例示するために、テーブル1504内の情報は、テーブル1502内の情報の10秒後に生成されていると仮定されている。
第1の実施例1510では、コマンドラインにコマンド「$a=get−process」が入力される。上記で説明されているように、オブジェクトベースの管理フレームワークでこのコマンドが実行される場合、get−process cmdletから生成された情報(例えば、テーブル1502)は、オブジェクトaに割り当てられる。10秒後に、以下のコマンドが入力される。
オブジェクトベースの管理フレームワークで上記コマンドが実行される場合、参照オブジェクトは、テーブル1502内の情報に関連付けられたオブジェクト「a」である。比較オブジェクトは、テーブル1504内の情報を生成したget−process cmdletから生成されたオブジェクトである。KeyBasedパラメータ1406は、「ProcessName」という名前のプロパティを持つオブジェクトに対しKeyBased比較を実行するコマンド文字列および信号に含まれる。このコマンド文字列は、さらに、「Handlecount」を比較対象のプロパティとして識別するPropertyパラメータ1410も含む。そのため、ProcessNameプロパティを持つ比較オブジェクト毎に、handlecountプロパティが参照オブジェクト内のhandlecountプロパティと比較される。その後、出力1512は、MSHプロセス名が参照オブジェクト内で同一の情報を持つことを示す。出力1512は、さらに、Calcプロセス名が参照オブジェクトと比較オブジェクトとで異なる情報を持つことも示す。
実施例1520では、第1のコマンドは、実施例1510と同じであるが、第2のコマンドは、以下のとおりである。
そのため、実施例1520は、RecordDifferenceスイッチおよびRecordEqualスイッチを含む。RecordDifferenceスイッチは、falseで設定することができ、RecordEqualスイッチは、trueで設定することができる。上記で説明されているように、これらのスイッチを使用すると、RecordEqualパラメータでは等しいプロパティのみを出力することを指定するので、出力1522は、参照オブジェクトまたは比較オブジェクトのいずれかに関連付けられているCalcプロセスのhandlecountをリストしない。
実施例1510および1520はcompare−object cmdletのオペレーションを例示しているが、当業者であれば、さまざまなスイッチおよびその他のcmdletsを使用して多数のコマンド文字列を定式化し、有用な情報を取得することができることを理解するであろう。さらに、上記の第2節で説明したように、cmdletの結果はパイプラインで他のcmdletsに送ることができる。そのため、compare−object cmdletは、それぞれのオブジェクトおよびその相違点を識別する差分レコードを作成するので、この差分レコードは、さらに、他のcmdletsにより操作することができる。これら他のcmdletsは、データベースのフィルタ処理、レポート作成、フィリングなどの処理、または差分レコードにリストされている相違点を解決する制御ループを提供することができる。差分レコードを制御ループにパイプラインで送ることができるため、本発明の比較手法の有用性が大幅に高められる。
さらに、この比較手法は、これらのオブジェクトの完全な意味論が出力オブジェクト内で利用できるように、オリジナルの参照オブジェクトおよびオリジナルの比較オブジェクトをカプセル化する1つまたは複数の出力オブジェクトを生成することができる。この実施形態では、差分レコードに書き込まれる情報は、注釈として、オリジナルの参照オブジェクトに追加することができる。拡張型マネージャは、この注釈を実行することができる。出力オブジェクトは、参照オブジェクトおよび比較オブジェクト、相違点のあるオブジェクト、一致するオブジェクトなどのそれぞれを含むように構成することができる。本発明の比較手法では、オリジナルのオブジェクトの一部をカプセル化する出力オブジェクトを生成できるため、これらのオリジナルのオブジェクトは、最初に、プロパティの一方の集合に基づいて比較され、そして後から、プロパティの第1の集合に含まれるプロパティのどれも含みえないか、またはそれらの一部を含みえるプロパティの他方の集合に基づいて処理されることが可能である。さらに、差分インジケータ注釈を使用し、その後の処理においてそれ独自の必要条件に基づいてプロパティのそれ独自の集合を選択することができる。オリジナルのオブジェクトをカプセル化するオブジェクトを出力することにより得られる他の利点は、オリジナルのオブジェクトにより公開されるクエリおよび制御メソッドを出力オブジェクト上で呼び出せるという点である。次に、図16〜23の流れ図を参照しつつ、比較手法のオペレーションについて説明する。
図16は、キーベースの比較プロセスを実行するプロセス例を示す論理流れ図である。このプロセスは、ブロック1601から始まり、ブロック1602に続く。
ブロック1602で、参照オブジェクトが取り出される。参照オブジェクトは、比較プロセスのときに他のオブジェクトと比較されるオブジェクトである。処理は、決定ブロック1604に続く。
決定ブロック1604では、参照オブジェクトがKeyBasedパラメータで指定されたキー名に関連付けられたプロパティを含むか否かの判別が行われる。複数のキーがある場合、参照オブジェクトは、それらの複数のキーのそれぞれに関連付けられたプロパティを含む。参照オブジェクトが指定されたプロパティを含まない場合、処理はブロック1610に続く。他の改良では、ブロック1610に進む前に、参照オブジェクトは、コマンドで指定されたパラメータに基づいて出力されるリストに追加することができる。そうでない場合、処理は、決定ブロック1606に続く。
決定ブロック1606で、参照セットが見直され、参照オブジェクトがすでにキーに対する同じ値を持つ参照セット内に存在するか否かを判別する。そのような参照オブジェクトが存在する場合、処理は決定ブロック1610に続く。そうでない場合、処理は、ブロック1608に続く。
ブロック1608で、参照オブジェクトが参照セットに追加される。その後、処理は、決定ブロック1610に続く。
決定ブロック1610で、比較プロセスで使用する他の参照オブジェクトがあるか否かの判別が行われる。他の参照オブジェクトがある場合、処理はブロック1602にループバックし、上述のように続く。そうでない場合、指定された1つまたは複数のキーを含むすべての参照オブジェクトが参照セットにすでに追加されている。処理は、ブロック1612に続く。
ブロック1612で、参照セット内の各参照オブジェクトおよびそれぞれの使用可能な比較オブジェクトを使用して比較が実行される。図21を参照しつつ以下で簡単に説明するが、Propertyパラメータで指定されるそれぞれのプロパティは、参照オブジェクトとそれぞれの比較オブジェクトとの間で比較される。この比較が実行された後、処理は完了する。
図21は、それぞれの比較オブジェクトを図16のブロック1612で使用するのに好適な参照オブジェクトと比較するプロセスの例を示す流れ図である。プロセス2100は、ブロック2101から始まり、ブロック2102に進む。
ブロック2102で、比較オブジェクトが取得される。上述のように、複数の比較オブジェクトがありうる。そのため、それぞれの比較オブジェクトをチェックし、参照オブジェクトと比較すべきか否かを調べる。処理は、決定ブロック2104に続く。
決定ブロック2104で、比較オブジェクトがキー名と関連付けられたプロパティを持つか否かの判別が行われる。複数のキーを使用できることに留意されたい。複数のキーがある場合、参照オブジェクトと比較オブジェクトとは、両方とも、複数のキーに関連付けられたプロパティを持っていなければならない。比較オブジェクトがキー名に関連付けられたプロパティを持っていない場合、処理は決定ブロック2116に続き、そこで、比較オブジェクトが欠損リストに追加され、処理は後述の決定ブロック2118に続く。ブロック2104での判別により、比較オブジェクトがキー名に関連付けられたプロパティを持つと結論された場合、処理は、決定ブロック2106に続く。
決定ブロック2106で、比較オブジェクトがキー値と関連付けられた第1の比較オブジェクトであるか否かの判別が行われる。第1の比較オブジェクトでない場合、処理はさらに決定ブロック2118に進む。そうでない場合、処理は、決定ブロック2108に続く。
決定ブロック2108で、同じキー値を持つ参照セット内に参照オブジェクトが存在するか否かの判別が行われる。このような参照オブジェクトが存在しない場合、処理はブロック2114に続き、そこで、比較専用レコードが出力される。比較専用レコードは、特定のキーを持つ比較オブジェクトが存在していたが、類似の参照オブジェクトは存在していなかったことを示す。上述のように、コンピューティング装置を標準構成と比較した場合、この情報は、潜在的構成問題を知らせるために有用である。比較専用レコードが出力された後、処理は、再び、決定ブロック2118に続く。しかし、決定ブロック2108の結果から、参照オブジェクトが存在すると結論される場合、処理はブロック2110に続く。
ブロック2110で、参照オブジェクトおよび比較オブジェクトのプロパティ値が比較される。手短に言うと、以下で図22を参照しつつ詳しく説明するが、この比較は、指定されたそれぞれのプロパティを比較するということである。そのため、上で説明したように、注目するプロパティのみが比較され、それぞれのプロパティを比較する必要がない。プロパティ値が比較された後、処理はブロック2112に続く。
ブロック2112で、参照オブジェクトが参照セットから削除される。ブロック2106では、比較オブジェクトがすでに処理されている他の比較オブジェクトを複製するか否かをチェックするので、参照オブジェクトはこの時点で削除できる。参照オブジェクトを削除すると、後から結果を出力する際に列挙が簡単に行える。そこで、すべての比較オブジェクトが取り出され、および比較された後、参照オブジェクトが参照セット内にまだ存在している場合、これは相違のあることを示す。処理は、決定ブロック2118に続く。
決定ブロック2118で、他の比較が処理のため利用可能か否かが判別される。他の比較オブジェクトがある場合、処理はブロック2102にループバックし、上述のように続く。ただし、すべての比較オブジェクトが処理された後、処理はブロック2120に続く。
ブロック2120で、比較の残りの結果が出力される。手短に言うと、図23を参照しつつ以下で詳しく説明するが、出力される結果は、compareコマンドとともに指定されたスイッチに基づくということである。その後処理は完了する。
図22は、図21で使用するのに好適な参照オブジェクトと比較オブジェクトとの間のプロパティ値を比較するプロセス例を示す流れ図である。プロセスは、ブロック2201から始まり、ブロック2202に進行する。
ブロック2202で、比較オブジェクト内の指定されたプロパティの1つが、参照オブジェクト内の対応するプロパティと比較される。参照オブジェクトおよび比較オブジェクトのデータ型は、必ずしも、同じである必要はないことに留意されたい。データ型が異なる場合、オブジェクトベースの管理フレームワークの拡張型マネージャは、異なるデータ型を認識し、それらを類似のデータ型が比較される形式に変換する。そのため、比較オブジェクトは、参照オブジェクトのデータ型に変換することができる。逆に、比較オブジェクトは、比較オブジェクトのデータ型に変換することができる。さらに、それぞれの指定されたプロパティは、比較の実行のため、個別に変換することができる。したがって、本発明の比較手法では、異なる型のオブジェクトを比較することができる。この比較手法では、参照オブジェクトを、仮想オブジェクトとしても取り扱われる比較オブジェクトと比較できる仮想オブジェクトとして取り扱う。
さらに、compareは、ファジー比較を含むことができ、参照オブジェクトおよび比較オブジェクトのプロパティに対する「値」は、エラーを報告する前にエラーの許容範囲内にありうることにも留意されたい。例えば、エラーの許容範囲が1Mbyteに設定されている場合、値10MBと12MBとでは違いが生じる。しかし、値10.5MBと11MBとでは、違いは生じない。このファジー比較により、信号対雑音比が改善される。そのため、ファジー比較を実装する比較手法では、相違点の検出が改善され、著しく関連性が高まる。
ファジー比較は、「−compare−object colorCompare−ReferenceObject $a −ComparisonObject $b」などのコマンド文字列の一部として与えられるカスタム比較器を使用して実装することができる。この特定の実施例について、colorCompareは、「moss green」および「sage」が同じであると報告されるように異なる色を格納するテキスト文字列同士を比較することができる。したがって、カスタム比較器があるため、異なるオブジェクト同士の比較を実行する自由度が大幅に高まる。指定されたプロパティが比較された後、処理は決定ブロック2204に続く。決定ブロック2204で、比較オブジェクトのプロパティの値が参照オブジェクトのプロパティの値に等しいか否かの判別が行われる。値が等しくない場合、処理はブロック2210に続き、そこで、指定されたプロパティに関して比較オブジェクトと参照オブジェクトとの間の相違を示す差分レコードを出力することができる。この差分レコードは、compareコマンドで指定されたパラメータに依存する。処理は、決定ブロック2212に続く。しかし、比較オブジェクトおよび参照オブジェクトのプロパティの値が等しい場合、処理は決定ブロック2206に続く。
決定ブロック2206で、compareコマンドの呼び出しで、等しいオブジェクトが出力されることを指定したか否かの判別が行われる。上述のように、これを達成する方法として、図14に示されているRecordEqual 1420を使用する方法がある。等しいオブジェクトが出力の中に含まれるべきでない場合、処理は決定ブロック2212に続く。そうでない場合、処理は、ブロック2208に続く。
ブロック2208で、比較オブジェクトの同等性レコードが出力される。同等性レコードは、比較オブジェクトの値およびプロパティを示す。処理は、決定ブロック2212に続く。
決定ブロック2212で、比較する必要のある他の指定されているオブジェクトが存在するか否かの判別が行われる。他のプロパティがある場合、処理はブロック2202にループバックし、上述のように続く。そうでない場合、処理は完了し、終了する。
図23は、図21で使用するのに好適な結果を出力するプロセス例を示す流れ図である。プロセス2300は、ブロック2301から始まり、ブロック2302に進む。
ブロック2302で、参照セット内のオブジェクトが列挙され、「参照専用」レコードが出力される。そのため、これは、対応する比較オブジェクトを持たなかった参照オブジェクトを出力する。処理は、決定ブロック2304に続く。
決定ブロック2304で、欠損リスト内で識別されたオブジェクトが出力されるべきか否かの決定が行われる。欠損キーオブジェクトを出力しない場合、処理は完了である。そうでない場合、処理は、ブロック2306に続く。
ブロック2306で、欠損リスト内で識別される参照オブジェクトが出力される。その後、処理は完了し、戻る。
図17は、順序ベースの比較プロセスを実行するプロセス例を示す論理流れ図である。いくつかの管理タスクでは、順序ベースの比較が、キーベースの比較よりも好ましい。例えば、順序ベースの比較は、アクセス制御リスト(ACL)を比較する場合に好ましい。ACLはユーザの許可およびアクセス権を示すので、これらの権利を分析する順序が重要である。処理はブロック1701から始まり、ブロック1702に続く。
ブロック1702で、参照オブジェクトが取得される。処理はブロック1704に続き、そこで、比較オブジェクトが取得される。上述のように、参照オブジェクトおよび比較オブジェクトのデータ型は同じである必要はない。拡張型マネージャは、比較が実行される前に、実行される必要がある変換を処理する。処理は、決定ブロック1706として続く。
決定ブロック1706で、参照オブジェクトおよび比較オブジェクトのデータ型がテキストであるか否かの判別が行われる。データ型がテキストでない場合(例えば、文字列、ファイル)、処理はブロック1712に続く。
ブロック1712で、参照オブジェクトおよび比較オブジェクトのプロパティの比較が実行される。手短に言うと、図18を参照しつつ以下で詳しく説明するが、参照オブジェクトおよび比較オブジェクトのプロパティが値および/または順序について異なる場合に相違点を報告する。処理は、決定ブロック1710に続く。
決定ブロック1710で、他の比較オブジェクトがあるか否かの判別が行われる。もしあれば、処理はブロック1704にループバックし、上述のように進行する。そうでない場合、処理は完了する。
決定ブロック1706に戻り、参照オブジェクトおよび比較オブジェクトのデータ型がテキストの場合、処理はブロック1708に続く。
ブロック1708で、参照オブジェクトと比較オブジェクトとの間のテキスト比較が実行される。手短に言うと、図19を参照しつつ以下で詳しく説明するが、テキスト比較は、現在利用可能な標準のテキストベースの比較手法と同様の動作をする。処理は、さらに、決定ブロック1710に続き、上述のように進行する。図17は複数の参照オブジェクトを例示していないが、当業者であれば、複数の参照オブジェクトを受け入れるように他の決定ブロックを実装することができることを理解するであろう。
図18は、図17に示されている順序ベースのプロセス内で使用するのに好適な順序ベースのオブジェクト比較プロセスを例示する論理流れ図である。処理はブロック1801から始まり、ブロック1802に進む。
ブロック1802で、参照オブジェクトからのプロパティが取得される。この比較は順序依存でないため、通常、プロパティは、逐次的に取得される。処理は、ブロック1804に続く。
ブロック1804で、比較オブジェクトからのプロパティが取得される。比較オブジェクト内のプロパティが取得される順序は、参照オブジェクト内のプロパティを取得する順序と同じである。処理は、決定ブロック1806に続く。
決定ブロック1806で、参照プロパティおよび差分プロパティが比較可能か否かの判別が行われる。まず、このプロセスで、参照プロパティの名前が差分プロパティの名前と同じであることを検証する。これは、リフレクションを使用して実行することができる。リフレクションに加えて、本発明の比較手法では、さらに、図13に例示されている拡張型システムとともに上で説明されているようなプロパティエイリアス機能も備える。そこで、プロパティエイリアス機能を使用することにより、参照オブジェクトおよび比較オブジェクトで異なるプロパティ名は、比較時に同等であるものとして処理することができる。
例えば、いくつかのオブジェクトでは、プロパティ名「ProcessName」を使用して、プロセスの名前に関連付けられているプロパティを識別することができる。他のオブジェクトでは、プロパティ名「Name」を使用して、プロセスの名前に関連付けられているプロパティを識別することができる。「Name」を「ProcessName」でエイリアスすることにより、これら2つの異なるオブジェクトのプロパティは、比較時に同じものとして処理される。
拡張型システムは、プロパティの1つに対するデータ型を他のプロパティのデータ型と同じものであることを課すことができることに留意されたい。例えば、参照プロパティが整数データ型であり、比較プロパティが文字列データ型の場合、拡張型マネージャは、図13とともに上で説明されているように文字列を整数値にすることを課すことができる。これは、異なるデータ型であるため相違点によりエラーが発生する厳密なオブジェクト比較とは対照的である。プロパティが直に互いに比較可能でない場合には、処理はブロック1808に続く。
ブロック1808で、必要な変換が実行され、2つのプロパティの比較を行うことができる。上述のように、これは、データ型の強制などを伴う場合がある。これらのプロパティが比較可能であったら、処理はブロック1810に続く。
ブロック1810で、2つのプロパティが比較される。上述のように、比較では、カスタム比較機構を使用する、ファジー比較の実行などを行うことができる。これら2つのプロパティが比較された後、処理はブロック1812に続く。
ブロック1812で、コマンド文字列とともに与えられるスイッチに基づいて相違が報告される。相違は、値および/またはプロパティの順序の違いを含むことができる。処理は、決定ブロック1814に続く。
決定ブロック1814で、比較する他のプロパティがあるか否かの判別が行われる。オブジェクトの順序ベースの比較では、プロパティの値および/またはプロパティの順序の間の違いを識別することが重要である。他のプロパティがある場合、処理はブロック1802にループバックし、上述のように進む。そうでない場合、処理は完了する。
図19は、図17に示されている順序ベースのプロセス内で使用するのに好適なテキスト比較プロセスを例示する論理流れ図である。処理はブロック1901から始まり、ブロック1908に進む。
ブロック1908で、テキストを比較し、違いが識別されるまで、またはテキストの終わりになるまで比較を続ける。テキスト比較では、ブロック1908でよく知られているテキスト比較手法を使用することができる。相違が検出されるか、または終わりが検出されると、処理は決定ブロック1910に続く。
決定ブロック1910で、テキストの終わりに達したか否かの判別が行われる。終わりに達した場合、処理はブロック1918に続く。そうでない場合、処理は、ブロック1912に続く。
ブロック1912で、相違の原因となっているテキストに対して検索が実行される。この検索は、参照オブジェクトまたは比較オブジェクトに関連付けられたテキストで実行することができる。検索は、テキストが見つかるか、または指定された同期ウィンドウが完了するまで実行される。同期ウィンドウの使用は、当業者にはよく知られているため、それ以上説明する必要はない。処理は、決定ブロック1914に続く。
決定ブロック1914で、検索中にテキストが見つかったか否かの判別が行われる。テキストが見つかった場合、処理はブロック1916に続き、そこで、参照オブジェクトまたは比較オブジェクトのいずれかの追加テキストに注目するなどで差分レコードが更新される。その後、処理は、ブロック1908にループバックし、上述のように進行する。
決定ブロック1914でテキストが見つからなかった場合、処理はブロック1918に続き、そこで、差分レコードが比較の情報とともに更新される。その後処理は完了する。
図20では、compareメソッドに対するシステム例を示している。構文2000は、λ式をサポートする。概要としては、λ式を使用すると、本発明の比較手法により、参照オブジェクトおよび/または比較オブジェクトのプロパティから派生されたキーおよび値に基づいてオブジェクトの2つのセットを比較できるが、これらはオブジェクト自体には存在しない。そのため、拡張型システムでは、値を単に返すだけであるが、むしろ、処理を実行して必要な値を取得することができる。
構文2000は、図14とともに上述のパラメータの多くを含む。さらに、構文2000は、ReferenceKeyパラメータ2002、ComparisonKeyパラメータ2004、ReferenceValueパラメータ2006、およびComparisonValueパラメータ2008のうちの1つまたは複数を含むことができる。ここでもまた、それらのパラメータはスイッチを含み、そのスイッチに関連付けられたデータを含むことができる。
ReferenceKeyパラメータ2002は、「−ReferenceKey」スイッチおよび参照キーオブジェクトを含む。参照キーオブジェクトは、各参照オブジェクトのキーを計算する任意の関数、スクリプト、λ式など(以下、λ式と総称する)とすることができる。同様に、ComparisonKeyパラメータ2004は、「−ComparisonKey」スイッチおよび比較キーオブジェクトを含み、比較キーオブジェクトは各比較オブジェクトのキーを計算するλ式とすることができる。
ReferenceValueパラメータ2006は、「−ReferenceValue」スイッチおよび参照値オブジェクトを含む。参照値オブジェクトは、各参照オブジェクトの値を計算するλ式とすることができる。同様に、ComparisonValueパラメータ2008は、「ComparisonValue」スイッチおよび比較値オブジェクトを含む。比較値オブジェクトは、各参照オブジェクトの値を計算するλ式とすることができる。
λ式の使用は、例を見ると最もよく理解できる。そこで、コマンド文字列が上記のプロパティ2002〜2008の各々についてλ式を含むと仮定する。さらに、λ式のそれぞれが、対応するオブジェクトのプロパティに基づきデータベース検索を実行すると仮定する。例えば、ReferenceKeyパラメータ2002に関連付けられた参照キーλ式は、プロパティAに対するデータベース検索の結果を返すことができる。例えば、ComparisonKeyパラメータ2004に関連付けられた比較キーλ式は、プロパティBに対するデータベース検索の結果を返すことができる。疑似コードでは、参照キーλ式は、「{$db.fetch($_.A)}」として表示することができ、$dbはデータベースオブジェクトを指し、.fetch($_.A)は拡張型マネージャを使用し入力セット内の単一参照オブジェクトからfetchメソッドを介してプロパティAを取り出すことを意味する。同様に、比較キーλ式に対する擬似コードは、「{$db.fetch($_.B)}」として表示されうる。
そこで、図16〜19および図23を参照しつつ上記で説明されている処理の実行時に、キーが取得され、評価されたときに、対応するキーλ式が必ず適用される。キーが等しいか否かのテストでは、上記で説明したのと同じ規則を使用する。しかし、キーの間の実際の比較を実行する他のλ式を指定することもできる。
次に、compare cmdletは、一致するキーを持つ参照オブジェクトおよび比較オブジェクト毎に、対応する値λ式を適用する。例えば、参照値λ式が「{$db.fetch($_.C)}“」で、比較値λ式が「{$db.fetch($_.D)}」である場合、compare−cmdletは、$db.fetch($R.C)の結果を$db.fetch($C.D)の結果と比較する。ただし、$Rは参照オブジェクト、$Cは比較オブジェクトである。ここでもまた、比較では、オプションの値比較λ式を実行することを含む上述の比較プロセスを使用することができる。
λ式をサポートする他の実施形態では、参照オブジェクトおよび比較オブジェクトのフィルタ処理を行って、λ式から計算されたキーおよび値を入力オブジェクト上にメモとして追加する。本発明の比較手法をサポートするλ式を指定するこれらおよびその他の変更形態は、エラーを識別する際に非常に柔軟に対応できる。
そこで、λ式を使用することにより、異なるオブジェクト型を持ち、共通プロパティを持たない参照オブジェクトは、各参照オブジェクトのキー関数が互換性のある結果を出力し、各参照オブジェクトの値関数が比較可能な結果を出力する限り、比較できる。さらに、各オブジェクトに使用されるキーまたは値関数は、外部システム機能(例えば、データベース検索)を呼び出し、ネットワークオペレーションを実行して、リモートシステムからデータを取り出すことができるいくらでも複雑な計算であってよい。他の改良では、キーまたは値関数は、異なる名前を使用する意味論的に同一のプロパティの比較を行うことができるエイリアス機能を備えることができる。
λ式が指定された場合に生成される出力オブジェクトは、計算されたキーおよび計算された値を生成されたオブジェクトの一部として、またはパススルーモードにおけるオリジナルのオブジェクトへの注釈として含めることができる。これにより、計算された値を使用して、生成された出力をさらに処理できる。他の改良では、キー関数は、入力データから除外すべきデータに対してヌルを返す動作をすることができる。
λ式を適用すると、パススルーモードで実行された1回の比較の出力を別の比較への入力として使用することにより、比較を複数の入力セット(例えば、参照オブジェクト)にまたがって適用することができる。これが実行される場合、オブジェクトのソースを示すプロパティの名前または値が異なることがある。これにより、入力セットの任意のグループ間の相違を追跡することができる。他の変更形態では、複数の入力セットを組み合わせて単一のストリームにすることにより比較を複数の入力集合にまたがって適用することができる。
特定の実装および実施形態の詳細が上で説明されているが、このような詳細は、請求項の範囲を限定するのではなく、法で定められた開示義務を満たすことが意図されている。したがって、請求項により定められている本発明は、上述の特定の機能に限定されない。むしろ、本発明は、付属の請求項の適切な範囲内に収まる形態または修正形態のいずれかで請求され、均一者の原則に従って適宜解釈される。