JP2007519073A - 管理用ツール環境 - Google Patents

Abstract

管理用ツール環境において、ユーザ入力が、処理のために管理用ツールフレームワークに供給される。管理用ツールフレームワークは、ユーザ入力をｃｍｄｌｅｔオブジェクトにマップする。ｃｍｄｌｅｔオブジェクトは、ユーザ入力を解析する文法と、予想される入力パラメータを入手するための入力オブジェクトとを記述する。入力オブジェクトは、１つのｃｍｄｌｅｔによって発せられ、別のｃｍｄｌｅｔへの入力として使用可能である。入力オブジェクトは、たとえば．ＮＥＴオブジェクト、プレーン文字列、ＸＭＬドキュメントなど、精密解析可能などの入力でもよい。ｃｍｄｌｅｔは、同じプロセス中で動作し得る。あるいは、１つのｃｍｄｌｅｔが、別のｃｍｄｌｅｔがリモートに動作する間、ローカルに動作することもできる。ｃｍｄｌｅｔは、管理用ツールフレームワークによって提供されることもでき、サードパーティ開発者によって提供されることもできる。ユーザ入力は、ホストｃｍｄｌｅｔを介して、フレームワークに与えられ得る。

Description

本明細書において開示される主題は、ランタイム環境に関し、より詳細には、管理タスクを自動化する管理用ツール環境に関する。

管理タスクは、たとえばラップトップ、デスクトップなどのコンピューティングデバイスの日常的な作業をサポートする。たとえば、管理タスクは一般に、ユーザが、新規フォルダを作成し、アプリケーションをインストールまたはアップグレードし、他の様々なシステムタスクを実施することを可能にする。ネットワーク化されたコンピュータの保守を行うシステム管理者は、たとえば新規ユーザの作成、ソフトウェアおよびソフトウェアパッチの展開、ネットワークの監視、ネットワークのトラブルシューティングなど、よりいっそう複雑な管理タスクを実施する。しばしば、コマンドラインインターフェイスまたはグラフィカルユーザインターフェイス（ＧＵＩ）は、管理タスクの実行を容易にする。

ほとんどのグラフィカルユーザインターフェイスは、ユーザに、一連のメニューまたはページをナビゲートし、次いで、所望のオプションをクリックすることを要求する。このようなインターフェイスによると、ユーザは、そうした一連のメニューまたはページに従うよう要求され、そうした一連のページを最初から見直し、または上下に巡回せずにあるページから別のページにジャンプすることを許可されない。このようなインターフェイスは、制限つきナビゲーションインターフェイスと呼ばれる場合があり、ユーザは、管理目標を達成するために、統制された所定の手順に従わなければならない。初心者ユーザは、このようなＧＵＩを使うことによって利益を受ける可能性がある。というのは、このようなＧＵＩは、初心者ユーザを所望の管理タスクに向かわせる有用な情報を各メニューまたはページで提供するからである。しかし、システム管理者などの多くの上級ユーザにとって、変更できないナビゲーション制約を有するＧＵＩを使うことは、非常にわずらわしい。こうした上級ユーザは、実施したいと思っている管理タスクを既に知っている。さらに、上級ユーザは、少なくともタスクのある程度の自動化を望む。しかし、ＧＵＩを介してアクセスされる管理タスクの自動化は非常に難しい。また、ＧＵＩが変わった場合、対応する自動化は、もはや正しく動作することができない。したがって、多くの上級ユーザは、より堅固なコマンドラインインターフェイスを使うことを好む。

コマンドラインインターフェイスは、コマンドをタイプ入力することによって、ユーザにタスクを直接実施させる。コマンドラインインターフェイスに伴う１つの欠点は、有用な情報がディスプレイ上で与えられないので、ユーザが、タイプ入力する正確なコマンドを知らなければならないことである。しかし、コマンドがわかると、一連のメニューをナビゲートするよりも、コマンドをタイプする方がはるかに効率的になる。さらに、コマンドラインインターフェイスから実行されるタスクは、自動化され得る。たとえば、ユーザは、同じコマンド（たとえば、一連のコマンドなど）を頻繁にタイプしていることに気づくと、そうした反復コマンドを含むスクリプト（たとえば．ｂａｔファイル）を作成することができる。このスクリプトが実行されると、スクリプト中に列挙されているコマンドすべてが実行される。ユーザは、異なるスクリプトが同じような項目を含むことにもすぐに気づき得る。このことに気がつくと、ユーザは、タスクをさらに自動化するために、パラメータ化されたサブルーチンをスクリプト中に作成することを望み得る。

しかし、高度な自動化特徴（たとえば、パラメータ化されたサブルーチン）をもたらす多くのスクリプト作成ソリューションは、完全なアプリケーションと同じやり方で開発され、システムプログラミング知識を要求する。したがって、こうしたソリューションは、概して高度なプログラミング知識をもたないシステム管理者にとって理想的でない。

したがって、現在、システム管理者は、自動化なしですませるか、またはシステムプログラミングスキルを利用して自動化を行わなければならない。どちらの選択肢もあまり望ましいものではない。管理者が、自動化なしですませることを選択した場合、タスクを手動で実行するのを補助する他の数人の管理者をサポートするのに、追加コストが発生する。しかし、管理者が、タスクを自動化することを選択した場合、プログラミング環境をサポートし、必要なプログラミングスキルを得るのにコストが発生する。さらに、変更が起こる度に、自動化されたツールが再構築されなければならないので、保守コストが高くなる。

したがって、管理者が、管理タスクを効果的かつ効率的に自動化することを可能にする管理用ツールフレームワークが必要である。

管理用ツールフレームワークが提供される。処理のために、ユーザ入力が管理用ツールフレームワークに供給される。管理用ツールフレームワークは、ユーザ入力をｃｍｄｌｅｔオブジェクトにマップする。ｃｍｄｌｅｔオブジェクトは、ユーザ入力を解析する文法と、ｃｍｄｌｅｔ中で識別される、予想される入力パラメータを入手するための入力オブジェクトとに関連づけられる。文法は、パラメータ宣言を用いるなどして、ｃｍｄｌｅｔ中で直接関連づけられ得る。あるいは、文法は、ＸＭＬドキュメントを介するなどして、ｃｍｄｌｅｔに間接的に関連づけられることもできる。入力オブジェクトは、１つのｃｍｄｌｅｔによって発せられ、別のｃｍｄｌｅｔへの入力として使用可能である。入力オブジェクトは、たとえば．ＮＥＴオブジェクト、プレーン文字列、ＸＭＬドキュメントなど、精密解析可能などの入力でもよい。ｃｍｄｌｅｔは、同じプロセス中で動作し得る。あるいは、１つのｃｍｄｌｅｔが、別のプロセス中でまたはリモートに別のｃｍｄｌｅｔが動作する間、ローカルに動作することもできる。ｃｍｄｌｅｔは、管理用ツールフレームワークによって提供されることもでき、サードパーティ開発者によって提供されることもできる。ユーザ入力は、ホストｃｍｄｌｅｔを介して、フレームワークに与えられ得る。

簡潔に述べると、本発明による管理用ツール環境は、コンピュータおよびコンピュータネットワークの保守およびサポートに関わる管理コストを削減するコンピューティングフレームワークを提供する。さらに、このフレームワークは、プログラマおよび非プログラマ両方による管理用ツールの迅速なアドホック開発をサポートする。

以下の説明は、具体的、例示的な管理用ツール環境を述べる。他の例示的な環境は、管理タスクを容易にすることを目指す、この具体的な実施形態の特徴および／または他の特徴を含み得る。

以下の詳細な説明は、いくつかのセクションに分けられる。第１のセクションは、管理用ツール環境が動作し得る例示的な計算機環境について述べる。第２のセクションは、管理用ツール環境のための例示的なフレームワークについて述べる。それ以降のセクションは、例示的なフレームワークの個々のコンポーネントおよびこうしたコンポーネントの動作について述べる。

（例示的な計算機環境）
図１は、例示的な管理用ツール環境において使用され得る、例示的なコンピューティングデバイスを示す。ごく基本的な構成において、コンピューティングデバイス１００は通常、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を含む。コンピューティングデバイスの正確な構成およびタイプによると、システムメモリ１０４は、揮発性（たとえばＲＡＭ）でも、不揮発性（たとえばＲＯＭ、フラッシュメモリなど）でも、この２つの何らかの組合せでもよい。システムメモリ１０４は通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を含み、プログラムデータ１０７を含み得る。オペレーティングシステム１０５は、コンポーネント（プロパティおよびイベントを含む）、オブジェクト、継承、多相性、リフレクションをサポートする、コンポーネントベースのフレームワーク１２０を含み、ワシントン州レドモンドのマイクロソフトコーポレーションによって作成された．ＮＥＴ（商標）フレームワークのＡＰＩなど、オブジェクト指向コンポーネントに基づくアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。オペレーティングシステム１０５は、管理用ツール（図示せず）の開発をサポートするためにコンポーネントベースのフレームワーク１２０と対話する管理用ツールフレームワーク２００も含む。この基本構成が、破線１０８内の構成要素によって図１に示される。

コンピューティングデバイス１００は、追加の特徴も機能も有することができる。たとえば、コンピューティングデバイス１００は、たとえば磁気ディスク、光ディスク、またはテープなど、追加のデータ記憶装置（着脱式および／または固定式）を含み得る。このような追加記憶装置が、図１に着脱式記憶装置１０９および固定式記憶装置１１０で示される。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するためのどの方法でも技術でも実装される揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体を含み得る。システムメモリ１０４、着脱式記憶装置１０９および固定式記憶装置１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタル多用途ディスク）または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは、所望の情報を記憶するのに使われ得るとともにコンピューティングデバイス１００によってアクセスされ得る他のどの媒体も含むが、それに限定されない。このようなどのコンピュータ記憶媒体も、装置１００の一部となり得る。コンピューティングデバイス１００は、たとえばキーボード、マウス、ペン、音声入力デバイス、タッチ式入力デバイスなどの入力デバイス（群）１１２も有することができる。たとえばディスプレイ、スピーカ、プリンタなどの出力デバイス（群）１１４も含められ得る。こうしたデバイスは、当該分野において公知であり、ここで詳細に説明される必要はない。

コンピューティングデバイス１００は、たとえばネットワークを介して装置を他のコンピューティングデバイス１１８と接続させる通信接続１１６も含み得る。通信接続１１６は、通信媒体の一例である。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータによって、変調データ信号、たとえば搬送波や他の移送機構として具体化されることができ、どの情報配信媒体も含む。「変調データ信号」という用語は、信号中の情報を符号化するようなやり方で設定されまたは変更される信号特性の１つまたは複数を有する信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含む。本明細書で使用されるコンピュータ可読媒体という用語は、記憶媒体および通信媒体両方を含む。

（例示的な管理用ツールフレームワーク）
図２は、例示的な管理用ツールフレームワーク２００の概観を全体的に示すブロック図である。管理用ツールフレームワーク２００は、１つまたは複数のホストコンポーネント２０２、ホスト固有コンポーネント２０４、ホスト非依存コンポーネント２０６、およびハンドラコンポーネント２０８を含む。ホスト非依存コンポーネント２０６は、他のコンポーネントそれぞれ（すなわち、ホストコンポーネント２０２、ホスト固有コンポーネント２０４、およびハンドラコンポーネント２０８）と通信することができる。こうしたコンポーネントはそれぞれ、後で簡潔に説明され、必要に応じて、以降のセクションでさらに詳しく説明される。

（ホストコンポーネント）
ホストコンポーネント２０２は、ユーザまたは他のプログラムに、関連するアプリケーション用の自動化特徴を公開する１つまたは複数のホストプログラム（たとえば、ホストプログラム２１０〜２１４）を含む。各ホストプログラム２１０〜２１４は、その独自のスタイルで、たとえば、コマンドライン、グラフィカルユーザインターフェイス（ＧＵＩ）、音声認識インターフェイス、アプリケーションプログラミングインターフェイス（ＡＰＩ）、スクリプト言語、ウェブサービスなどを介して、こうした自動化特徴を公開することができる。ただし、ホストプログラム２１０〜２１４はそれぞれ、管理用ツールフレームワークによって提供される機構を介して、１つまたは複数の自動化特徴を公開する。

この例では、機構は、関連するホストプログラム２１０〜２１４のユーザに対して管理用ツールの機能を明らかにするのに、ｃｍｄｌｅｔを用いる。さらに、機構は、ホストによって利用可能にされる１組のインターフェイスを用いて、対応するホストプログラム２１０〜２１４に関連するアプリケーションに、管理用ツール環境を組み込む。以下の説明を通して、「ｃｍｄｌｅｔ」という用語は、図２〜２３を参照して説明される例示的な管理用ツール環境において使われるコマンドを指すのに用いられる。

ｃｍｄｌｅｔは、従来の管理環境におけるコマンドに対応する。しかし、ｃｍｄｌｅｔは、こうした従来のコマンドとは大きく異なる。たとえば、ｃｍｄｌｅｔは通常、それに相対するコマンドよりもサイズが小さい。というのは、ｃｍｄｌｅｔは、たとえば解析、データ認証、エラー報告など、管理用ツールフレームワークによって提供される共通機能を利用し得るからである。このような共通機能は、一度だけ実装され、一度だけテストされればよいので、管理用ツールフレームワーク全体に及ぶｃｍｄｌｅｔの使用は、アプリケーション固有機能に関連するインクリメンタル開発およびテストのコストを、従来の環境に比べてかなり低くさせる。

さらに、従来の環境とは対照的に、ｃｍｄｌｅｔは、スタンドアロン型の実行可能プログラムでなくてよい。そうではなく、ｃｍｄｌｅｔは、管理用ツールフレームワーク内部の同じプロセス中で実行され得る。このことは、ｃｍｄｌｅｔが、互いの間で「ライブ」オブジェクトを交換することを可能にする。「ライブ」オブジェクトを交換するこの機能は、ｃｍｄｌｅｔが、こうしたオブジェクトにおいてメソッドを直接呼び出すことを可能にする。ｃｍｄｌｅｔの作成および使用の詳細は、後でさらに詳しく説明される。

概して、各ホストプログラム２１０〜２１４は、管理用ツールフレームワーク内部で、ユーザと他のコンポーネントの間の対話を管理する。こうした対話は、パラメータを求めるプロンプト、エラーの報告などを含み得る。通常、各ホストプログラム２１０〜２１４は、独自の具体的なホストｃｍｄｌｅｔ（たとえば、ホストｃｍｄｌｅｔ２１８）の組を提供することができる。たとえば、ホストプログラムがｅメールプログラムの場合、ホストプログラムは、メールボックスおよびメッセージと対話するホストｃｍｄｌｅｔを提供することができる。図２は、ホストプログラム２１０〜２１４を示すが、ホストコンポーネント２０２は、既存または新規作成アプリケーションに関連する他のホストプログラムを含み得ることを当業者は理解するであろう。こうした他のホストプログラムは、それと関連するアプリケーションに、管理用ツール環境によって提供される機能も組み込む。ホストプログラムによって提供される処理は、後で図８とともに詳しく説明される。

図２に示される例において、ホストプログラムは、コンピューティングデバイスのハードウェア、ソフトウェア、およびネットワークコンポーネントを管理する管理用ツールをユーザが作成し、保存し、開くための、シンプルで一貫性がある管理ユーザインターフェイスを提供する管理コンソール（すなわち、ホストプログラム２１０）でよい。こうした機能を遂行するために、ホストプログラム２１０は、管理用ツールフレームワークの上に管理ＧＵＩを構築する１組のサービスを提供する。ＧＵＩとの対話は、管理用ツール環境によって提供されるスクリプト作成能力をユーザに教えるのを補助する、ユーザが見ることのできるスクリプトとして公開されることもできる。

別の例では、ホストプログラムは、コマンドライン対話シェル（すなわち、ホストプログラム２１２）でよい。コマンドライン対話シェルは、コマンドライン上でシェルメタデータ２１６を入力させて、コマンドラインの処理に影響を与え得る。

さらに別の例では、ホストプログラムは、複数のプラットフォーム、プログラミング言語、およびアプリケーションに及ぶ、分散コンピューティングおよび相互運用性のための業界標準仕様を用いるウェブサービス（すなわち、ホストプログラム２１４）でよい。

こうした例に加えて、サードパーティは、そのホストプログラムまたは他のホストプログラムとともに用いられる「サードパーティ」すなわち「プロバイダ」インターフェイスおよびプロバイダｃｍｄｌｅｔを作成することによって、独自のホストコンポーネントを追加することができる。プロバイダインターフェイスは、アプリケーションまたはインフラストラクチャが管理用ツールフレームワークによって操作され得るように、アプリケーションまたはインフラストラクチャを公開する。プロバイダｃｍｄｌｅｔは、ナビゲーション、診断、構成、ライフサイクル、動作などの自動化をもたらす。プロバイダｃｍｄｌｅｔは、全く異質な１組のデータストアに対して、多様型(polymorphic)ｃｍｄｌｅｔ行動を示す。管理用ツール環境は、他のｃｍｄｌｅｔクラスと同じ優先度で、プロバイダｃｍｄｌｅｔに作用する。プロバイダｃｍｄｌｅｔは、他のｃｍｄｌｅｔと同じ機構を用いて作成される。プロバイダｃｍｄｌｅｔは、管理用ツールフレームワークに、アプリケーションまたはインフラストラクチャの詳細な機能を公開する。したがって、ｃｍｄｌｅｔを使うことにより、製品開発者は、１つのホストコンポーネントを作成するだけでよく、このホストコンポーネントは次いで、製品開発者の製品を多くの管理用ツールを用いて動作させる。たとえば、例示的な管理用ツール環境を用いると、システムレベルのグラフィカルユーザインターフェイスのヘルプメニューが、既存のアプリケーションに統合され移植され得る。

（ホスト固有コンポーネント）
ホスト固有コンポーネント２０４は、計算機システム（たとえば、図１のコンピューティングデバイス１００）が、フレームワークが実行されているプラットフォームの各部から管理用ツールフレームワークを切り離すのに用いるサービスの集合体を含む。したがって、プラットフォームの各タイプごとに、１組のホスト固有コンポーネントが存在する。ホスト固有コンポーネントは、異なるオペレーティングシステム上で同じ管理用ツールをユーザが使うことを可能にする。

一時的に図３に移ると、ホスト固有コンポーネント２０４は、インテリセンス(IntelliSense)／メタデータアクセスコンポーネント３０２、ヘルプｃｍｄｌｅｔコンポーネント３０４、構成／登録コンポーネント３０６、ｃｍｄｌｅｔセットアップコンポーネント３０８、および出力インターフェイスコンポーネント３０９を含み得る。コンポーネント３０２〜３０８は、データベースストア３１４に関連づけられたデータベースストアマネージャ３１２と通信する。パーサ２２０およびスクリプトエンジン２２２は、インテリセンス／メタデータアクセスコンポーネント３０２と通信する。コアエンジン２２４は、ヘルプｃｍｄｌｅｔコンポーネント３０４、構成／登録コンポーネント３０６、ｃｍｄｌｅｔセットアップコンポーネント３０８、および出力インターフェイスコンポーネント３０９と通信する。出力インターフェイスコンポーネント３０９は、ホストによってアウトｃｍｄｌｅｔに提供されるインターフェイスを含む。こうしたアウトｃｍｄｌｅｔは次いで、ホストの出力オブジェクトをコールして、レンダリングを実施することができる。ホスト固有コンポーネント２０４は、コアエンジン２２４がロギングおよび監査能力をもたらすホスト固有（すなわち、プラットフォーム固有）サービスと通信するのに用いるロギング／監査コンポーネント３１０も含み得る。

例示的な一管理用ツールフレームワークにおいて、インテリセンス／メタデータアクセスコンポーネント３０２は、コマンド、パラメータ、およびパラメータ値の自動補完をもたらす。ヘルプｃｍｄｌｅｔコンポーネント３０４は、ホストユーザインターフェイスに基づいて、カスタマイズされたヘルプシステムを提供する。

（ハンドラコンポーネント）
図２に戻ると、ハンドラコンポーネント２０８は、レガシーユーティリティ２３０、管理ｃｍｄｌｅｔ２３２、非管理ｃｍｄｌｅｔ２３４、リモーティングｃｍｄｌｅｔ２３６、およびウェブサービスインターフェイス２３８を含む。管理ｃｍｄｌｅｔ２３２（プラットフォームｃｍｄｌｅｔとも呼ばれる）は、コンピューティングデバイスに関連する構成情報を照会し、または操作するｃｍｄｌｅｔを含む。管理ｃｍｄｌｅｔ２３２は、システムタイプ情報を操作するので、ある特定のプラットフォームに依存する。しかし、各プラットフォームは通常、他のプラットフォーム上で管理ｃｍｄｌｅｔ２３２と同様のアクションを提供する管理ｃｍｄｌｅｔ２３２を有する。たとえば、各プラットフォームは、システム管理属性（たとえば、ｇｅｔ／ｐｒｏｃｅｓｓ、ｓｅｔ／ＩＰＡｄｄｒｅｓｓ）を入手し設定する管理ｃｍｄｌｅｔ２３２をサポートする。ホスト非依存コンポーネント２０６は、ホスト非依存コンポーネント２０６内で生成されたｃｍｄｌｅｔオブジェクトを介して管理ｃｍｄｌｅｔと通信する。ｃｍｄｌｅｔオブジェクトの例示的なデータ構造は、後で図５〜７とともに詳しく説明される。

非管理ｃｍｄｌｅｔ２３４（基本ｃｍｄｌｅｔと呼ばれる場合もある）は、管理ｃｍｄｌｅｔ２３２によって提供されるオブジェクトに対して他の処理をグループ化し、ソートし、フィルタリングし、実施するｃｍｄｌｅｔを含む。非管理ｃｍｄｌｅｔ２３４は、パイプラインオブジェクトに関連づけられたデータをフォーマットし出力するｃｍｄｌｅｔも含み得る。データ駆動コマンドライン出力をもたらす例示的な機構が、後で図１９〜２３とともに説明される。非管理ｃｍｄｌｅｔ２３４は、各プラットフォームにおいて同じでよく、ｃｍｄｌｅｔオブジェクトを介してホスト非依存コンポーネント２０６と対話する１組のユーティリティを提供し得る。非管理ｃｍｄｌｅｔ２３４とホスト非依存コンポーネント２０６の間の対話は、オブジェクトのリフレクションを可能にし、その（オブジェクト）タイプに依存しない、リフレクトされたオブジェクトに対する処理を可能にする。したがって、こうしたユーティリティは、開発者が、非管理ｃｍｄｌｅｔを書くと、こうした非管理ｃｍｄｌｅｔを計算機システム上でサポートされる全クラスのオブジェクトに渡って適用することを可能にする。従来、開発者は、処理されるデータ形式を最初に把握し、次いで、そのデータのみを処理するようなアプリケーションを書かなければならなかった。その結果、従来のアプリケーションは、非常に限られた範囲のデータを処理することしかできなかった。オブジェクトタイプに依存しない、オブジェクトを処理する例示的な一機構が、後で図１８とともに説明される。

レガシーユーティリティ２３０は、ｃｍｄ．ｅｘｅの下で実行されるｗｉｎ３２実行可能プログラムなど、既存の実行可能プログラムを含む。各レガシーユーティリティ２３０は、オブジェクトフレームワークにおいてあるタイプのオブジェクトであるテキストストリーム（すなわち、ｓｔｄｉｎおよびｓｔｄｏｕｔ）を使って管理用ツールフレームワークと通信する。レガシーユーティリティ２３０は、テキストストリームを使用するので、管理用ツールフレームワークによって提供されるリフレクションベースの動作は利用可能でない。レガシーユーティリティ２３０は、管理用ツールフレームワークとは異なるプロセスで実行される。図示されていないが、他のｃｍｄｌｅｔも、プロセス外部で動作することができる。

リモーティングｃｍｄｌｅｔ２３６は、ウェブサービスインターフェイス２３８と組み合わされて、インターネットやイントラネット（たとえば、図２に示されるインターネット／イントラネット２４０）などの通信媒体を介して、他のコンピューティングデバイス上の、対話型でありプログラマティック(programmatic)管理用ツール環境にアクセスするためのリモーティング機構を提供する。例示的な一管理用ツールフレームワークにおいて、リモーティング機構は、複数の独立コントロールドメインに及ぶインフラストラクチャに依存する統合サービスをサポートする。リモーティング機構は、リモートコンピューティングデバイス上でスクリプトを実行させる。スクリプトは、１つまたは複数のリモートシステム上で実行され得る。スクリプトの結果は、個々の各スクリプトが完了したときに処理されることもでき、様々なコンピューティングデバイスの上のスクリプトすべてが完了した後で集約され、まとめて処理されることもできる。

たとえば、ホストコンポーネント２０２の１つとして示されるウェブサービス２１４は、リモートエージェントでよい。リモートエージェントは、ターゲットシステム上のパーサおよび管理用ツールフレームワークへのリモートコマンド要求の提出を操作する。リモーティングｃｍｄｌｅｔは、リモートエージェントへのアクセスを提供するためのリモートクライアントとして働く。リモートエージェントおよびリモーティングｃｍｄｌｅｔは、解析されたストリームを介して通信を行う。解析されたこのストリームが、プロトコル層で保護されることもでき、解析されたストリームを暗号化し、次いで解読するために追加ｃｍｄｌｅｔが使われることもできる。

（ホスト非依存コンポーネント）
ホスト非依存コンポーネント２０６は、パーサ２２０、スクリプトエンジン２２２、およびコアエンジン２２４を含む。ホスト非依存コンポーネント２０６は、複数のｃｍｄｌｅｔをグループ化し、ｃｍｄｌｅｔの動作を調整し、ｃｍｄｌｅｔとの他のリソース、セッション、およびジョブの対話を調整するための機構およびサービスを提供する。

（例示的なパーサ）
パーサ２２０は、様々なホストプログラムから入力要求を受け取り、コアエンジン２２４内部など、管理用ツールフレームワーク内で用いられる一様なｃｍｄｌｅｔオブジェクトに入力要求をマップする機構を提供する。さらに、パーサ２２０は、受け取られた入力に基づいてデータ処理を実施することができる。入力に基づいてデータ処理を実施する例示的な一方法が、後で図１２とともに説明される。本発明による管理用ツールフレームワークのパーサ２２０は、異なる言語またはシンタクスを容易に公開する能力を提供し、ユーザに同じ能力をもたらす。たとえば、パーサ２２０は、入力要求の解釈を担当するので、予想される入力シンタクスに影響を与える、パーサ２２０内部でのコードへの変更は、管理用ツールフレームワークの各ユーザに本質的に影響を与える。したがって、システム管理者は、異なるコンピューティングデバイス上で、異なるシンタクスをサポートする異なるパーサを提供することができる。ただし、同じパーサを使って操作している各ユーザは、各ｃｍｄｌｅｔに対して一貫性があるシンタクスを経験する。対照的に、従来の環境では、各コマンドは、独自のシンタクスを実装していた。したがって、各環境は、数千のコマンドを使って、通常その多くは互いと一貫性がなかった異なるいくつかのシンタクスをサポートした。

（例示的なスクリプトエンジン）
スクリプトエンジン２２２は、スクリプトを用いて複数のｃｍｄｌｅｔを結合するための機構およびサービスを提供する。スクリプトとは、厳格な継承規則の下でセッション状態を共有するコマンドラインの集約である。スクリプト中の複数のコマンドラインは、入力要求中で提供されるシンタクスに基づいて、同期または非同期で実行され得る。スクリプトエンジン２２２は、ループおよび条件節などの制御構造を処理し、スクリプト中の変数を処理することができる。スクリプトエンジンはまた、セッション状態を管理し、ポリシー（図示せず）に基づいて、セッションデータへのアクセスをｃｍｄｌｅｔに与える。

（例示的なコアエンジン）
コアエンジン２２４は、パーサ２２０によって識別されるｃｍｄｌｅｔの処理を担当する。一時的に図４に移ると、管理用ツールフレームワーク２００における例示的なコアエンジン２２４が示されている。例示的なコアエンジン２２４は、パイプラインプロセッサ４０２、ローダ４０４、メタデータプロセッサ４０６、エラー＆イベントハンドラ４０８、セッションマネージャ４１０、および拡張タイプマネージャ４１２を含む。

（例示的なメタデータプロセッサ）
メタデータプロセッサ４０６は、メタデータにアクセスし、図３に示されるデータベースストア３１４などのメタデータストアにメタデータを格納するように構成される。メタデータは、ｃｍｄｌｅｔクラス定義などにおいて、コマンドラインを介して与えられ得る。管理用ツールフレームワーク２００内部の様々なコンポーネントは、その処理を実施するとき、メタデータを要求し得る。たとえば、パーサ２２０は、コマンドライン上で供給されたパラメータを検証するためにメタデータを要求し得る。

（例示的なエラー＆イベントプロセッサ）
エラー＆イベントプロセッサ４０８は、コマンドラインの処理中にエラーのそれぞれの出現についての情報を格納するためのエラーオブジェクトを提供する。本発明による管理用ツールフレームワークに特に適している特定の一エラーおよびイベントプロセッサについての追加情報については、たとえば、米国特許出願第１０/４１３、０５４号明細書「System and Method for Persisting Error Information in a Command Line Environment」を参照されたい。

（例示的なセッションマネージャ）
セッションマネージャ４１０は、管理用ツールフレームワーク２００内部の他のコンポーネントに、セッションおよび状態情報を供給する。セッションマネージャによって管理される状態情報は、プログラミングインターフェイスを介して、どのｃｍｄｌｅｔ、ホスト、またはコアエンジンによってもアクセスされ得る。こうしたプログラミングインターフェイスは、状態情報の作成、修正、および削除を可能にする。

（例示的なパイプラインプロセッサおよびローダ）
ローダ４０４は、パイプラインプロセッサ４０２がｃｍｄｌｅｔを実行するために、各ｃｍｄｌｅｔをメモリにロードするように構成される。パイプラインプロセッサ４０２は、ｃｍｄｌｅｔプロセッサ４２０およびｃｍｄｌｅｔマネージャ４２２を含む。ｃｍｄｌｅｔプロセッサ４２０は、個々のｃｍｄｌｅｔをディスパッチする。ｃｍｄｌｅｔが、リモートでの、または１組のリモートマシンでの実行を要求した場合、ｃｍｄｌｅｔプロセッサ４２０は、図２に示されるリモーティングｃｍｄｌｅｔ２３６を用いて実行を調整する。ｃｍｄｌｅｔマネージャ４２２は、ｃｍｄｌｅｔの集約の実行を操作する。ｃｍｄｌｅｔマネージャ４２２、ｃｍｄｌｅｔプロセッサ４２０、およびスクリプトエンジン２２２（図２）は、ホストプログラム２１０〜２１４から受け取られた入力に対する処理を実施するために、相互に通信する。通信は、本質的に再帰的であり得る。たとえば、ホストプログラムがスクリプトを与えた場合、スクリプトは、それ自体がスクリプトであり得るｃｍｄｌｅｔを実行するために、ｃｍｄｌｅｔマネージャ４２２を呼び出し得る。スクリプトは次いで、スクリプトエンジン２２２によって実行され得る。コアエンジン用の例示的な一プロセスフローが、後で図１４とともに詳しく説明される。

（例示的な拡張タイプマネージャ）
上述したように、管理用ツールフレームワークは、オブジェクトのリフレクションを可能にし、その（オブジェクト）タイプに依存しない、リフレクトされたオブジェクトに対する処理を可能にする１組のユーティリティを提供する。管理用ツールフレームワーク２００は、このリフレクションを実施するために、計算機システム上のコンポーネントフレームワーク（図１のコンポーネントフレームワーク１２０）と対話する。当業者は理解するであろうが、リフレクションは、オブジェクトを照会し、そのオブジェクトのタイプを入手し、次いで、様々なオブジェクトと、そのタイプのオブジェクトに関連するプロパティとをリフレクトして、他のオブジェクトおよび／または所望の値を入手する能力をもたらす。

リフレクションは、管理用ツールフレームワーク２００に、オブジェクトについての相当量の情報を提供するが、本発明者は、リフレクションが、オブジェクトのタイプに焦点を当てていることを認識した。たとえば、データベースのデータテーブルがリフレクトされると、返される情報は、データテーブルが２つのプロパティ、すなわち列プロパティおよび行プロパティを有するというものである。こうした２つのプロパティは、データテーブル中の「オブジェクト」に関する十分な詳細を提供しない。リフレクションが拡張マークアップ言語（ＸＭＬ）および他のオブジェクトにおいて用いられると、同様の問題が起こる。

したがって、本発明者は、タイプの使用法に焦点を当てる拡張タイプマネージャ４１２を考案した。この拡張タイプマネージャにとって、オブジェクトのタイプは重要でない。そうではなく、拡張タイプマネージャは、必要な情報を入手するためにオブジェクトが使用され得るかどうかに関心を示す。上記データテーブルの例を用いて続けると、本発明者は、データテーブルが列プロパティおよび行プロパティを有することがわかってもあまり興味深くないと認識したが、ある１列が興味深い情報を含むことを認識した。使用法に注目すると、各行を「オブジェクト」に関連づけ、各列をその「オブジェクト」の「プロパティ」に関連づけることができよう。したがって、拡張タイプマネージャ４１２は、精密解析可能などのタイプの入力からも「オブジェクト」を作成するための機構を提供する。この機構の提供において、拡張タイプマネージャ４１２は、コンポーネントベースのフレームワーク１２０によって提供されるリフレクション機能を補い、「リフレクション」を、精密解析可能などのタイプの入力にも拡張する。

概して、拡張タイプマネージャは、精密解析可能な入力（図示せず）にアクセスし、精密解析可能な入力を、要求されたデータ型に相関させるように構成される。拡張タイプマネージャ４１２は次いで、パイプラインプロセッサ４０２やパーサ２２０などの要求コンポーネントに、要求された情報を提供する。以下の説明において、精密解析可能な入力は、プロパティおよび値が見分けられ得る入力として定義される。精密解析可能な一部の例示的入力は、ＷＭＩ（Windows（登録商標） Management Instrumentation）入力、ＡｃｔｉｖｅＸデータオブジェクト（ＡＤＯ）入力、拡張マークアップ言語（ＸＭＬ）入力、および．ＮＥＴオブジェクトなどのオブジェクト入力を含む。他の精密解析可能な入力は、サードパーティのデータ形式を含み得る。

一時的に図１８に移ると、管理用ツールフレームワークでの使用に適した例示的な拡張タイプマネージャを示す機能ブロック図が示されている。説明のために、拡張タイプマネージャによって提供される機能（丸で囲まれた番号「３」で示される）は、従来の密束縛システム(tightly bound system)によって提供される機能（丸で囲まれた番号「１」で示される）、およびリフレクションシステムによって提供される機能（丸で囲まれた番号「２」で示される）と対比される。従来の密束縛システムでは、アプリケーションにおけるコール側１８０２は、オブジェクトＡの中の情報（たとえば、プロパティＰ１およびＰ２、メソッドＭ１およびＭ２）に直接アクセスする。上述したように、コール側１８０２は、コンパイル時にオブジェクトＡによって与えられるプロパティ（たとえば、プロパティＰ１およびＰ２）ならびにメソッド（たとえば、メソッドＭ１およびＭ２）を先験的に知っていなければならない。リフレクションシステムにおいて、ジェネリックコード１８２０（どのデータ型にも依存しない）は、要求されたオブジェクトに対してリフレクション１８１０を実施するとともにオブジェクト（たとえば、オブジェクトＡ）についての情報（たとえば、プロパティＰ１およびＰ２、メソッドＭ１およびＭ２）をジェネリックコード１８２０に返すシステム１８０８に問合せを行う。オブジェクトＡには示されていないが、返される情報は、たとえばベンダ、ファイル、日付などの付加情報を含み得る。したがって、リフレクションにより、ジェネリックコード１８２０は少なくとも、密束縛システムが提供する同じ情報を入手する。リフレクションシステムは、コール側１８０２がシステムに問合せを行うこと、およびパラメータについて先験的に何も知らなくても付加情報を入手することも可能にする。

密束縛システムおよびリフレクションシステム両方において、新規データ型は、動作環境に容易に組み込まれることができない。たとえば、密束縛システムにおいて、動作環境が引き渡されると、動作環境は、新規データ型をサポートするために再構築されなければならないので、新規データ型を組み込むことができない。同様に、リフレクションシステムでは、各オブジェクトクラスについてのメタデータが固定される。したがって、新規データ型の組込みは通常、行われない。

しかし、本発明による拡張タイプマネージャを用いると、新規データ型が、オペレーティングシステムに組み込まれ得る。拡張タイプマネージャ１８２２を用いると、ジェネリックコード１８２０は、要求されたオブジェクトをリフレクトして、様々な外部ソース、たとえばサードパーティオブジェクト（たとえば、オブジェクトＡおよびＢ）、セマンティックウェブ１８３２、オントロジー（ontology）サービス１８３４などによって与えられる拡張データ型（たとえば、オブジェクトＡ’）を入手することができる。説明されたように、サードパーティオブジェクトは、既存のオブジェクト（たとえばオブジェクトＡ’）を拡張することもでき、全く新しいオブジェクト（たとえばオブジェクトＢ）を作成することもできる。

こうした外部ソースはそれぞれ、タイプメタデータ１８４０に一義的な構造を登録し、コード１８４２を提供することができる。オブジェクトが照会されると、拡張タイプマネージャは、タイプメタデータ１８４０を見直して、オブジェクトが登録されているかどうか判定する。オブジェクトがタイプメタデータ１８４０に登録されていない場合、リフレクションが実施される。登録されている場合、拡張リフレクションが実施される。コード１８４２は、リフレクトされるタイプに関連づけられた追加プロパティおよびメソッドを返す。たとえば、入力タイプがＸＭＬの場合、コード１８４２は、ＸＭＬドキュメントからオブジェクトを作成するためのＸＭＬの使われ方を記述する記述ファイルを含み得る。したがって、タイプメタデータ１８４０は、その具体的な入力タイプ向けのオブジェクトを作成する所望のプロパティを入手するために、拡張タイプマネージャ４１２が様々なタイプの精密解析可能入力（たとえば、サードパーティオブジェクトＡおよびＢ、セマンティックウェブ１８３２）をどのようにして照会するべきかを記述し、コード１８４２は、こうした所望のプロパティを入手するための命令を提供する。その結果、拡張タイプマネージャ４１２は、全タイプのオブジェクトの「リフレクション」を可能にする間接指定層を提供する。

拡張タイプの提供に加えて、拡張タイプマネージャ４１２は、たとえばプロパティパス機構、キー機構、比較機構、変換機構、グロバ（globber）機構、プロパティセット機構、関係機構など、追加クエリ機構を提供する。こうしたクエリ機構はそれぞれ、後で「例示的な拡張タイプマネージャ処理」というセクションで説明されるが、コマンド文字列を入力するとき、システム管理者に柔軟性をもたらす。拡張タイプマネージャ用のセマンティクスを実装するのに、様々な技術が用いられ得る。３つの技術が後で説明される。ただし、こうした技術の変形形態は、特許請求の範囲に記載されている本発明の範囲から逸脱することなく利用され得ることを当業者は理解するであろう。

ある技術では、静的メソッド（たとえば、ｇｅｔｐｒｏｐｅｒｔｙ（））を有する一連のクラスが提供される。オブジェクトは、静的メソッドに入力され（たとえば、ｇｅｔｐｒｏｐｅｒｔｙ（ｏｂｊｅｃｔ））、静的メソッドは、１組の結果を返す。別の技術では、動作環境は、オブジェクトをアダプタで包む。このようにして、入力は与えられない。アダプタの各インスタンスは、包まれたオブジェクトに作用するとともに包まれたオブジェクト用のプロパティを返すｇｅｔｐｒｏｐｅｒｔｙメソッドを有する。以下は、この技術を示す擬似コードである。

さらに別の技術では、アダプタクラスが、オブジェクトを下位分類する。従来、下位分類は、コンパイルの前に起きた。しかし、特定の動作環境を用いると、下位分類は、動的に起こり得る。こうしたタイプの環境に対して、以下が、この技術を示す擬似コードである。

したがって、図１８に示されるように、拡張タイプマネージャは、開発者が新規データ型を作成し、データ型を登録することを可能にし、他のアプリケーションおよびｃｍｄｌｅｔに、新規データ型を使用させる。対照的に、従来の管理環境では、各データ型は、そのデータ型からインスタンス化されたオブジェクトに関連づけられたプロパティまたはメソッドが直接アクセスされ得るように、コンパイル時に知られていなければならなかった。したがって、管理環境によってサポートされる新規データ型の追加は、従来、ほとんど行われなかった。

図２に戻ると、概して、管理用ツールフレームワーク２００は、ユーザによって入力されるコマンドの実行を調整するシェルに依拠するのではなく、（たとえば、ホストｃｍｄｌｅｔにより）機能を処理部分（たとえば、ホスト非依存コンポーネント２０６）およびユーザ対話部分に分割する。さらに、本発明による管理用ツール環境は、解析およびデータ認証に要求されるコードが、各コマンドに含まれなくなり、管理用ツールフレームワーク内部のコンポーネント（たとえば、パーサ２２０）によって提供されるので、管理用ツールのプログラミングを大幅に簡略化する。管理用ツールフレームワークにおいて実施される例示的な処理は、後で説明される。

（例示的な動作）
図５〜７は、管理用ツール環境において使われる例示的なデータ構造を、図表により示す。図８〜１７は、管理用ツール環境における例示的な処理フローを、図表により示す。特定の処理は、後で説明されるコンポーネントとは異なるコンポーネントによって、本発明の範囲から逸脱することなく実施され得ることを当業者は理解するであろう。管理用ツールフレームワークのコンポーネント内で実施される処理を説明する前に、管理用ツールフレームワークにおいて用いられる例示的なデータ構造が説明される。

（ｃｍｄｌｅｔオブジェクトの例示的なデータ構造）
図５は、図２に示される管理用ツールフレームワークでの使用に適したｃｍｄｌｅｔを指定する例示的なデータ構造である。ｃｍｄｌｅｔは、完了されると、管理ｃｍｄｌｅｔ、非管理ｃｍｄｌｅｔ、ホストｃｍｄｌｅｔ、プロバイダｃｍｄｌｅｔなどになり得る。以下の説明は、システム管理者の視点（すなわち、プロバイダｃｍｄｌｅｔ）を参照して、ｃｍｄｌｅｔの作成について述べる。ただし、各タイプのｃｍｄｌｅｔは、同じやり方で作成され、同じように動作する。ｃｍｄｌｅｔは、Ｃ＃など、どの言語でも書かれ得る。さらに、ｃｍｄｌｅｔは、スクリプト言語などを使って書かれ得る。管理用ツール環境が．ＮＥＴフレームワークとともに動作する場合、ｃｍｄｌｅｔは、．ＮＥＴオブジェクトでよい。

プロバイダｃｍｄｌｅｔ５００（これ以降、ｃｍｄｌｅｔ５００と呼ばれる）は、ｃｍｄｌｅｔクラス名（たとえば、ＳｔｏｐＰｒｏｃｅｓｓ５０４）を有するパブリッククラスである。ｃｍｄｌｅｔ５００は、ｃｍｄｌｅｔクラス５０６から派生する。ｃｍｄｌｅｔクラス５０６用の例示的なデータ構造が、後で図６とともに説明される。各ｃｍｄｌｅｔ５００は、名前（たとえば、Ｓｔｏｐ／Ｐｒｏｃｅｓｓ）をｃｍｄｌｅｔ５００に関連づけるコマンド属性５０２に関連づけられる。名前は、管理用ツール環境内部で登録される。後で説明されるように、名前（たとえば、Ｓｔｏｐ／Ｐｒｏｃｅｓｓ）をもつコマンド文字列が、コマンドラインで、またはスクリプト中で入力として与えられると、パーサは、ｃｍｄｌｅｔレジストリ内部を調べて、ｃｍｄｌｅｔ５００を識別する。

ｃｍｄｌｅｔ５００は、ｃｍｄｌｅｔに対して予想される入力パラメータ用の文法を定義する文法機構に関連づけられる。文法機構は、直接または間接的にｃｍｄｌｅｔに関連づけられ得る。たとえば、ｃｍｄｌｅｔ５００は、直接的な文法の関連づけを示す。このｃｍｄｌｅｔ５００において、１つまたは複数のパブリックパラメータ（たとえば、ＰｒｏｃｅｓｓＮａｍｅ５１０およびＰＩＤ５１２）が宣言される。パブリックパラメータの宣言は、ｃｍｄｌｅｔ５００への入力オブジェクトの解析を駆動する。あるいは、パラメータの記述は、ＸＭＬドキュメントなど、外部ソースに現れ得る。この外部ソースにおけるパラメータの記述は次いで、ｃｍｄｌｅｔへの入力オブジェクトの解析を駆動する。

各パブリックパラメータ５１０、５１２は、それに関連づけられた１つまたは複数の属性（すなわち、ディレクティブ）をもち得る。ディレクティブは、解析ディレクティブ５２０、データ認証ディレクティブ５２１、データ生成ディレクティブ５２２、処理ディレクティブ５２３、エンコードディレクティブ５２４、およびドキュメンテーションディレクティブ５２５というカテゴリーのいずれでもよい。ディレクティブは、角括弧で囲まれ得る。各ディレクティブは、予想される次の入力パラメータに対して実施される動作を記述する。ユーザ対話タイプのディレクティブなど、ディレクティブのいくつかは、クラスレベルでも適用され得る。ディレクティブは、ｃｍｄｌｅｔに関連づけられたメタデータに格納される。こうした属性の適用が、後で図１２とともに説明される。

こうした属性は、ｃｍｄｌｅｔ内で宣言されるパラメータの投入にも影響を与え得る。こうしたパラメータを投入する例示的な一プロセスが、後で図１６とともに説明される。コアエンジンは、準拠性を保証するためにこうしたディレクティブを適用し得る。ｃｍｄｌｅｔ５００は、第１のメソッド５３０（これ以降、同義的にＳｔａｒｔＰｒｅｃｅｓｓｉｎｇメソッド５３０と呼ばれる）および第２のメソッド５４０（これ以降、同義的にｐｒｏｃｅｓｓＲｅｃｏｒｄメソッド５４０と呼ばれる）を含む。コアエンジンは、第１および第２のメソッド５３０、５４０を用いて、ｃｍｄｌｅｔ５００の処理を指示する。たとえば、第１のメソッド５３０が一度実行され、セットアップ機能を実施する。第２のメソッド５４０中のコード５４２は、ｃｍｄｌｅｔ５００によって処理される必要がある各オブジェクト（たとえばｒｅｃｏｒｄ）に対して実行される。ｃｍｄｌｅｔ５００は、ｃｍｄｌｅｔ５００の後でクリーンアップを行う第３のメソッド（図示せず）も含み得る。

したがって、図５に示されるように、第２のメソッド５４０中のコード５４２は通常、非常に短く、たとえば解析コード、データ認証コードなど、従来の管理用ツール環境において要求される機能を含まない。したがって、システム管理者は、複雑なプログラミング言語を学習することなく、複雑な管理タスクを開発することができる。

図６は、図５に示されるｃｍｄｌｅｔが派生されるｃｍｄｌｅｔ基本クラス６０２を詳述する例示的なデータ構造６００である。ｃｍｄｌｅｔ基本クラス６０２は、ｃｍｄｌｅｔがフックステートメントを含み、対応するスイッチがコマンドラインでまたはスクリプト中で入力される（併せてコマンド入力と呼ばれる）ときはいつでも、付加機能を提供する命令を含む。

例示的なデータ構造６００は、ブーリアンパラメータｖｅｒｂｏｓｅ６１０、ｗｈａｔｉｆ６２０、およびｃｏｎｆｉｒｍ６３０などのパラメータを含む。後で説明されるように、こうしたパラメータは、コマンド入力で入力され得る文字列に対応する。例示的なデータ構造６００は、実行を要求されているタスクが許可されるかどうかを判定するセキュリティメソッド６４０も含み得る。

図７は、ｃｍｄｌｅｔを詳述する、別の例示的なデータ構造７００である。概して、データ構造７００は、管理用ツールフレームワークとｃｍｄｌｅｔの間のコントラクトを明白に表現する手段を提供する。データ構造５００と同様、データ構造７００は、ｃｍｄｌｅｔクラス７０４から派生するパブリッククラスである。ソフトウェア開発者は、「ｇｅｔ／ｐｒｏｃｅｓｓ」および「ｆｏｒｍａｔ／ｔａｂｌｅ」などの名詞／動詞ペアをｃｍｄｌｅｔ７００に関連づけるｃｍｄｌｅｔＤｅｃｌａｒａｔｉｏｎ７０２を指定する。名詞／動詞ペアは、管理用ツール環境内で登録される。動詞も名詞も、ｃｍｄｌｅｔ名において暗黙的でよい。また、データ構造５００と同様、データ構造７００は、データ構造５００とともに説明される１つまたは複数のディレクティブ５１０〜５２０に関連づけられ得る１つまたは複数のパブリックメンバ（たとえば、Ｎａｍｅ７３０、Ｒｅｃｕｒｓｅ７３２）を含み得る。

ただし、この例示的なデータ構造７００において、予想される入力パラメータ７３０および７３２はそれぞれ、入力属性７３１および７３３それぞれに関連づけられる。入力属性７３１および７３３は、それぞれのパラメータ７３０および７３２用のデータがコマンドラインから取得されるべきであると指定する。したがって、この例示的なデータ構造７００において、別のｃｍｄｌｅｔによって発せられたパイプラインオブジェクトから投入される、予想される入力パラメータが存在しない。したがって、データ構造７００は、ｃｍｄｌｅｔ基本クラスによって提供される第１のメソッド（たとえば、ＳｔａｒｔＰｒｏｃｅｓｓｉｎｇ）も第２のメソッド（たとえば、ＰｒｏｃｅｓｓＲｅｃｏｒｄ）もオーバーライドしない。

データ構造７００は、入力パラメータとして認識されないプライベートメンバ７４０も含み得る。プライベートメンバ７４０は、ディレクティブの１つに基づいて生成されるデータの格納に使われ得る。

したがって、データ構造７００に示されるように、具体的なｃｍｄｌｅｔクラスにおいてパブリックプロパティおよびディレクティブの宣言を使用することにより、ｃｍｄｌｅｔ開発者は、そのｃｍｄｌｅｔに対して予想される入力パラメータ用の文法を容易に指定し、ｃｍｄｌｅｔ開発者が基底論理のいずれかをも生成する必要なく、予想される入力パラメータに対して実施されるべき処理を指定することができる。データ構造７００は、ｃｍｄｌｅｔと文法機構の間の直接的な関連づけを示す。上述したように、この関連づけは、ＸＭＬドキュメントなどの外部ソースにおいて、予想されるパラメータ定義を明記するなどして、間接的でもよい。

管理用ツール環境における例示的なプロセスフローが次に説明される。

（例示的なホスト処理フロー）
図８は、図２に示される管理用ツールフレームワーク内部で実施されるホスト処理のための例示的なプロセスを示す論理フロー図である。プロセス８００は、ブロック８０１で始まり、ここで、具体的なアプリケーション向けの管理用ツール環境を開始するための要求が受け取られている。要求は、アプリケーションアイコンの選択などのキーボード入力を介してローカルに、または異なるコンピューティングデバイスのウェブサービスインターフェイスを介してリモートに送られている可能性がある。いずれのシナリオでも、処理は、ブロック８０２へ続く。

ブロック８０２で、「ターゲット」コンピューティングデバイス上の具体的なアプリケーション（たとえばホストプログラム）が、その環境をセットアップする。このセットアップは、ｃｍｄｌｅｔのどのサブセット（たとえば、管理ｃｍｄｌｅｔ２３２、非管理ｃｍｄｌｅｔ２３４、およびホストｃｍｄｌｅｔ２１８）がユーザに対して使用可能にされるかという判定を含む。通常、ホストプログラムは、非管理ｃｍｄｌｅｔ２３４すべてを使用可能にし、独自のホストｃｍｄｌｅｔ２１８を使用可能にする。さらに、ホストプログラムは、プロセス、ディスクなどを扱うｃｍｄｌｅｔなど、管理ｃｍｄｌｅｔ２３２の一部を使用可能にする。したがって、ホストプログラムがｃｍｄｌｅｔの一部を使用可能にすると、管理用ツールフレームワークは、対応するアプリケーションに有効に組み込まれる。処理は、ブロック８０４へ続く。

ブロック８０４で、特定のアプリケーションを介して入力が入手される。上述したように、入力は、たとえばコマンドライン、スクリプト、音声、ＧＵＩなど、いくつかの形をとり得る。たとえば、コマンドラインを介して入力が入手されると、入力は、キーボードで入れられるキーストロークから取得される。ＧＵＩホストに対しては、ＧＵＩに基づいて文字列が組み立てられる。処理は、ブロック８０６で継続する。

ブロック８０６で、入力は、処理のために管理用ツールフレームワーク内部の他のコンポーネントに与えられる。ホストプログラムは、パーサなど、他のコンポーネントに入力を直接転送することができる。あるいは、ホストプログラムは、そのホストｃｍｄｌｅｔの１つを介して入力を転送することもできる。ホストｃｍｄｌｅｔは、その具体的なタイプの入力（たとえば音声）を、管理用ツールフレームワークによって認識されるタイプの入力（たとえば、テキスト列、スクリプト）に変換することができる。たとえば、音声入力は、音声入力の内容に応じて、スクリプトまたはコマンドライン文字列に変換され得る。各ホストプログラムは、そうしたタイプの入力を、管理用ツールフレームワークによって認識される入力に変換する責任があるので、管理用ツールフレームワークは、任意の数の様々なホストコンポーネントからの入力を受諾することができる。さらに、管理用ツールフレームワークは、入力がそのｃｍｄｌｅｔの１つを介して転送されるときにデータ型の間の変換を実施する、豊富な１組のユーティリティを提供する。他のコンポーネントによって入力に対して実施される処理が、後で他のいくつかの図とともに説明される。ホスト処理は、判断ブロック８０８で継続する。

判断ブロック８０８で、追加入力の要求が受け取られたかどうか、判定が行われる。この判定は、入力の処理を担当する他のコンポーネントの１つが、その処理を完了するためにユーザからの付加情報を必要とする場合に起こり得る。たとえば、特定のデータにアクセスするのにパスワードが要求され、具体的なアクションの確認が必要とされる場合などがある。特定のタイプのホストプログラム（たとえば音声メール）に対して、このような要求は適切でない場合がある。したがって、ユーザに付加情報を問い合わせるのではなく、後で状態が再開され、入力の実行が継続され得るようにホストプログラムが状態をシリアル化し、状態を一時停止し、通知を送ることができる。別の変形形態では、ホストプログラムは、所定の期間の後でデフォルト値を提供することができる。追加入力の要求が受け取られた場合、処理は、ブロック８０４にループバックし、ここで、追加入力が入手される。処理は次いで、上述されたようにブロック８０６および８０８を経由して継続する。追加入力要求が受け取られず、入力が処理されている場合、処理は、ブロック８１０へ続く。

ブロック８１０で、管理用ツールフレームワーク内部の他のコンポーネントから結果が受け取られる。結果は、エラーメッセージ、状況などを含み得る。結果は、管理用ツールフレームワーク内部のホストｃｍｄｌｅｔによって認識され処理されるオブジェクトの形である。後で説明されるように、各ホストｃｍｄｌｅｔ用に書かれるコードは、非常に小さい。したがって、開発コストへの莫大な投資を要せずに豊富な１組の出力が表示され得る。処理は、ブロック８１２で継続する。

ブロック８１２で、結果が閲覧され得る。ホストｃｍｄｌｅｔは、ホストプログラムによってサポートされる表示スタイルに結果を変換する。たとえば、返されたオブジェクトは、アイコン、ほえる犬（barking dog）など、図形表示を用いて、ＧＵＩホストプログラムによって表示され得る。ホストｃｍｄｌｅｔは、データのデフォルト形式および出力を提供する。デフォルト形式および出力は、後で図１９〜２３とともに説明される例示的な出力処理ｃｍｄｌｅｔを使用し得る。結果が任意選択で表示された後、ホスト処理が完了する。

（入力を操作する例示的なプロセスフロー）
図９は、図２に示される管理用ツールフレームワーク内部で実施される入力操作のための例示的なプロセスを示す論理フロー図である。処理は、ブロック９０１で始まり、ここで、入力が、ホストプログラムを介して入れられ、管理用ツールフレームワーク内部の他のコンポーネントに転送されている。処理は、ブロック９０２で継続する。

ブロック９０２で、入力は、ホストプログラムから受け取られる。例示的な一管理用ツールフレームワークにおいて、入力は、パーサによって受け取られ、このパーサは、入力を解読し、入力をさらに処理するように向ける。処理は、判断ブロック９０４で継続する。

判断ブロック９０４で、入力がスクリプトであるかどうか判定が行われる。入力は、スクリプト、またはコマンドラインを表す文字列（これ以降、「コマンド文字列」と呼ばれる）の形をとり得る。コマンド文字列は、まとめてパイプライン処理される１つまたは複数のｃｍｄｌｅｔを表し得る。管理用ツールフレームワークは、異なるいくつかのホストをサポートするが、各ホストは、処理用のスクリプトまたはコマンド文字列として入力を提供する。後で示されるように、スクリプトとコマンド文字列の間の対話は、本質的に再帰的である。たとえば、スクリプトは、ｃｍｄｌｅｔを呼び出す行を有し得る。ｃｍｄｌｅｔ自体は、スクリプトでよい。

したがって、判断ブロック９０４で、入力がスクリプトの形の場合、処理は、ブロック９０６で継続し、ここで、スクリプトの処理が実施される。スクリプトの形でない場合、処理は、ブロック９０８で継続し、ここで、コマンド文字列の処理が実施される。ブロック９０６または９０８で実施される処理が完了されると、入力の処理が完了する。

（スクリプトの例示的な処理）
図１０は、図９に示される入力操作プロセスでの使用に適したスクリプトを処理するプロセスを示す論理フロー図である。プロセスは、ブロック１００１で始まり、ここで、入力は、スクリプトとして識別されている。スクリプトエンジンおよびパーサは、相互に通信して、後続の機能を実施する。処理は、ブロック１００２で継続する。

ブロック１００２で、スクリプトに対して前処理が実施される。一時的に図１１に移ると、スクリプト処理プロセス１０００での使用に適したスクリプト前処理プロセス１１００を示す論理フロー図が示されている。スクリプトの前処理は、ブロックで１１０１始まり、判断ブロック１１０２へ続く。

判断ブロック１１０２で、スクリプトが初めて実行されているのかどうか、判定が行われる。この判定は、レジストリまたは他の記憶機構から入手される情報に基づき得る。スクリプトは、記憶機構内部から識別され、関連するデータが検討される。スクリプトが前に実行されたことがない場合、処理は、ブロック１１０４で継続する。

ブロック１１０４で、スクリプトがレジストリに登録される。この登録は、管理用ツールフレームワーク内部のコンポーネントによるその後のアクセスのために、スクリプトについての情報を格納させる。処理は、ブロック１１０６で継続する。

ブロック１１０６で、ヘルプおよびドキュメンテーションがスクリプトから抽出され、レジストリに格納される。やはり、この情報も、管理用ツールフレームワーク内部のコンポーネントによって後でアクセスされ得る。スクリプトはこの時点で、処理の準備が整い、図１０のブロック１００４に戻る。

判断ブロック１１０２に戻ると、スクリプトが前に実行されたことがあるとプロセスが結論づけた場合、処理は判断ブロック１１０８へ続く。判断ブロック１１０８で、スクリプトが処理中に障害を起こしたかどうか、判定が行われる。この情報は、レジストリから入手され得る。スクリプトが障害を起こしていない場合、スクリプトは、処理の準備が整い、図１０のブロック１００４に戻る。

しかし、スクリプトが障害を起こした場合、処理は、ブロック１１１０で継続する。ブロック１１１０で、スクリプトエンジンは、スクリプトが障害を起こしたことを、ホストプログラムを介してユーザに通知し得る。この通知は、スクリプトを進めるか、それともスクリプトを終了させるか、ユーザに判断させる。図８とともに上述されたように、ホストプログラムは、この要求を、入力スタイル（たとえば、音声、コマンドライン）に応じて様々なやり方で扱うことができる。ユーザから追加入力が受け取られると、スクリプトは、処理のために図１０のブロック１００４に戻るか、またはスクリプトが破棄される。

図１０のブロック１００４に戻ると、スクリプト中の行が取得される。処理は、判断ブロック１００６で継続する。判断ブロック１００６で、行が何らかの制約を含むかどうか、判定が行われる。制約は、予め定義された開始キャラクタ（たとえば、括弧「［」）および対応する終了キャラクタ（たとえば、閉じ括弧「］」）で検出される。行が制約を含む場合、処理は、ブロック１００８へ続く。

ブロック１００８で、行に含まれる制約が適用される。概して、制約は、スクリプトに入れられたパラメータ用のタイプを指定するとともにパラメータに対して実施されるべき認証論理を指定するための機構を、管理用ツールフレームワーク内部で提供する。制約は、パラメータに対して適用可能なだけでなく、変数など、スクリプトに入れられたどのタイプの構文(construct)にも適用可能である。したがって、制約は、データ型を指定し、パラメータを検証するための機構を、解釈環境内部で提供する。従来の環境では、システム管理者は、スクリプトに入れられたパラメータを正式にテストすることができない。制約を課す例示的なプロセスは、図１２に示される。

判断ブロック１０１０で、スクリプトの行が組込み機能を含むかどうか、判定が行われる。組込み機能は、コアエンジンによって実施されない機能である。組込み機能は、ｃｍｄｌｅｔを用いて処理されることも、インライン関数など、他の機構を用いて処理されることもできる。行が組込み機能をもたない場合、処理は、判断ブロック１０１４で継続する。組込み機能をもつ場合、処理は、１０１２ブロックで継続する。

ブロック１０１２で、スクリプトの行で与えられた組込み機能が処理される。組込み機能の例は、たとえば「ｉｆ」ステートメント、「ｆｏｒ」ループ、スイッチなど、コントロール構造の実行を含み得る。組込み機能は、割当てタイプのステートメント（たとえば、ａ＝３）も含み得る。組込み機能が処理されると、処理は、判断ブロック１０１４へ続く。

判断ブロック１０１４で、スクリプトの行がコマンド文字列を含むかどうか、判定が行われる。判定は、登録されているコマンド文字列と、起こり得るｃｍｄｌｅｔ呼出しのシンタクスとに行中のデータが関連づけられているかどうかに基づく。上述したように、コマンド文字列およびスクリプトの処理は、本質的に再帰的であり得る。というのは、スクリプトは、コマンド文字列を含むことができ、コマンド文字列は、それ自体がスクリプトであるｃｍｄｌｅｔを実行することができるからである。行がコマンド文字列を含まない場合、処理は、判断ブロック１０１８で継続する。コマンド文字列を含む場合、処理は、ブロック１０１６で継続する。

ブロック１０１６で、コマンド文字列が処理される。概して、コマンド文字列の処理は、パーサによってｃｍｄｌｅｔクラスを識別すること、および対応するｃｍｄｌｅｔオブジェクトを実行のためにコアエンジンに渡すことを含む。コマンド文字列は、いくつかの別個のｃｍｄｌｅｔオブジェクトに解析されるとともにコアエンジンによって個別に処理されるパイプライン型コマンド文字列も含み得る。コマンド文字列を処理する例示的な一プロセスが、後で図１４とともに説明される。コマンド文字列が処理されると、処理は、判断ブロック１０１８で継続する。

判断ブロック１０１８で、スクリプトにさらに行があるかどうか、判定が行われる。スクリプトにさらに行がある場合、処理は、ブロック１００４にループバックし、ブロック１００４〜１０１６で上述されたように進行する。行がない場合、処理は完了する。

ブロック１００８で制約を課す例示的なプロセスが、図１２に示されている。プロセスは、ブロック１２０１で始まり、ここで、スクリプト中の、またはコマンドライン上のコマンド文字列中の制約が検出される。制約がスクリプト中にある場合、制約および関連する構文は、同じ行にも別個の行にも現れ得る。制約がコマンド文字列中にある場合、制約および関連する構文は、行末インジケータ（たとえば、エンターキー）の前に現れる。処理は、ブロック１２０２へ続く。

ブロック１２０２で、解釈環境から制約が入手される。例示的な一管理用ツール環境において、パーサは、入力を解読し、制約の出現を判定する。制約は、述語ディレクティブ(predicate directive)、解析ディレクティブ、データ認証ディレクティブ、データ生成ディレクティブ、処理ディレクティブ、エンコードディレクティブ、およびドキュメンテーションディレクティブのカテゴリーの１つでよい。例示的な一解析シンタクスの場合、ディレクティブは、角括弧で囲まれ、その後に続く構文を記述する。構文は、関数、変数、スクリプトなどでよい。

後で説明されるように、ディレクティブを使用することにより、スクリプト作成者は、スクリプト作成者が基底論理のいずれを生成することも要せずに、スクリプトまたはコマンドライン（すなわち、解釈環境）におけるパラメータに対する処理を容易にタイプし実施することを可能にされる。処理は、ブロック１２０４へ続く。

ブロック１２０４で、入手された制約が、関連する構文用のメタデータに格納される。関連する構文は、１つまたは複数の属性（attribution）トークン（制約を示すトークン）が遭遇された後、第１の非属性表示トークンであると識別される。処理は、ブロック１２０６へ続く。

ブロック１２０６で、スクリプト中またはコマンド文字列中で構文が遭遇されると常に、メタデータ内部で定義された制約が、構文に適用される。制約は、データ型、述語ディレクティブ１２１０、ドキュメンテーションディレクティブ１２１２、解析ディレクティブ１２１４、データ生成ディレクティブ１２１６、データ認証ディレクティブ１２１８、ならびにオブジェクト処理およびエンコードディレクティブ１２２０を含み得る。データ型を指定する制約は、管理用ツールフレームワークが実行されているシステム上でサポートされるどのデータ型も指定し得る。述語ディレクティブ１２１０は、処理が起こるべきかどうかを示すディレクティブである。したがって、述語ディレクティブ１２１０は、実行に対して環境が適正であることを保証する。たとえば、スクリプトは、次の述語ディレクティブを含み得る。

[PredicateScript("isInstalled","ApplicationZ")]
この述語ディレクティブは、スクリプトを実行する前に正しいアプリケーションがコンピューティングデバイスにインストールされることを保証する。通常、システム環境変数は、述語ディレクティブとして指定され得る。ディレクティブタイプ１２１２〜１２２０にある例示的なディレクティブが、テーブル１〜５に示される。スクリプトの処理は次いで、完了する。

したがって、解釈環境においてタイプおよび制約を適用する本プロセスは、システム管理者が、この処理を実施する基底論理を書くことなく、タイプを容易に指定し、認証要件を指定することなどを可能にする。以下は、次のように指定されたコマンド文字列に対して実施される制約処理の例である。

「[]」で示される属性表示トークンにより指定される２つの制約がある。第１の属性表示トークンは、変数が整数型であることを示し、第２の属性表示トークンは、変数$aの値が３と５を含むその間でなければならないことを示す。このコマンド文字列の例は、後続コマンド文字列または行の中で変数＄ａが割り当てられている場合、変数＄ａは、２つの制約と突き合わせて調べられることを保証する。したがって、次のコマンド文字列が、エラー中でそれぞれ現れる。

制約は、管理用ツールフレームワークにおいて様々な段階で適用される。たとえば、使用可能性ディレクティブ、ドキュメンテーションディレクティブ、および解析ガイドラインディレクティブは、非常に早い段階にパーサ内で処理される。データ生成ディレクティブおよび認証ディレクティブは、パーサが入力パラメータすべての解析を終えるとエンジン内で処理される。

以下のテーブルは、ディレクティブに応答して管理用ツール環境によって実施されるプロセスの説明とともに、様々なカテゴリー用の代表的なディレクティブを示す。

．ＮＥＴ（商標）フレームワーク内部で例示的な管理用ツールフレームワークが動作しているとき、各カテゴリーは、基本カテゴリークラス（たとえば、ＣｍｄＡｔｔｒｉｂｕｔｅ）から派生される基本クラスを有する。基本カテゴリークラスは、Ｓｙｓｔｅｍ．Ａｔｔｒｉｂｕｔｅクラスから派生する。各カテゴリーは、カテゴリー処理中にパーサによってコールされる、予め定義された関数（たとえば、ａｔｔｒｉｂ．ｆｕｎｃ（））を有する。スクリプト作成者は、カスタムカテゴリークラス（たとえば、ＣｍｄＣｕｓｔｏｍＡｔｔｒｉｂｕｔｅ）から派生されるカスタムカテゴリーを作成することができる。スクリプト作成者は、そのカテゴリー用の基本カテゴリークラスからディレクティブクラスを派生することによって既存のカテゴリークラスを拡張し、予め定義された関数を実装でオーバーライドすることもできる。スクリプト作成者は、ディレクティブをオーバーライドし、予め定義されたディレクティブの組に新規ディレクティブを追加することもできる。

こうしたディレクティブの処理順序は、パーサによってアクセス可能な外部データストアに格納され得る。管理用ツールフレームワークは、登録されたカテゴリーを探し、そのカテゴリー中のディレクティブそれぞれに対して関数（たとえば、ＰｒｏｃｅｓｓＣｕｓｔｏｍＤｉｒｅｃｔｉｖｅ）をコールする。したがって、カテゴリー処理の順序は、カテゴリー実行情報を永続ストアに格納することによって、動的になり得る。様々なプロセス段階で、パーサは、永続ストアの中を調べて、いずれかのメタデータカテゴリーが、その時点で実行される必要があるかどうか判定する。この判定は、永続ストアからカテゴリーエントリを削除することによって、カテゴリーを容易に廃止させる。

（コマンド文字列の例示的な処理）
コマンド文字列を処理する例示的な一プロセスが次に説明される。図１３は、図２に示される管理用ツールフレームワークにおける、パーサ２２０およびコアエンジン２２４を介したコマンド文字列１３５０の処理を図表により示す機能フロー図である。例示的なコマンド文字列１３５０は、いくつかのコマンド（すなわち、ｐｒｏｃｅｓｓコマンド１３６０、ｗｈｅｒｅコマンド１３６２、ｓｏｒｔコマンド１３６４、およびｔａｂｌｅコマンド１３６６）をパイプライン処理する。コマンドライン１３５０は、こうしたコマンドのいずれにも入力パラメータを渡し得る（たとえば、「ｈａｎｄｌｅｃｏｕｎｔ＞４００」が、ｗｈｅｒｅコマンド１３６２に渡される）。ｐｒｏｃｅｓｓコマンド１３６０は、関連する入力パラメータを何ももたないことに留意されたい。

従来、各コマンドは、コマンドに関連づけられた入力パラメータの解析、入力パラメータが有効であるかどうかの判定、および入力パラメータが有効でない場合のエラーメッセージの発行を担当した。コマンドは通常、様々なプログラマによって書かれたので、コマンドライン上の入力パラメータ用のシンタクスは、あまり一貫していなかった。さらに、エラーが起きた場合、エラーメッセージは、同じエラーに対してさえも、コマンドの間であまり一貫していなかった。

たとえば、ＵＮＩＸ（登録商標）環境では、「ｌｓ」コマンドおよび「ｐｓ」コマンドの間には多くの不一致がある。両方ともオプション「−ｗ」を受諾するが、「−ｗ」オプションは、「ｌｓ」コマンドではページ幅を示すのに使われ、「−ｗ」オプションは、「ｐｓ」コマンドでは幅のある出力の印刷を示すのに使われる（本質的に、ページ幅を無視する）。「ｌｓ」および「ｐｓ」コマンドに関連するヘルプページにもいくつかの不一致があり、たとえば、あるページではオプションをボールド体にしてあるが他のページではそうでなく、あるページではオプションをアルファベット順にソートしてあるが他のページではそうでなく、一部のオプションにはダッシュをつけさせるが一部のオプションにはつけない。

本管理用ツールフレームワークは、より一貫性がある手法を提供し、各開発者が書かなければならない重複コードの量を最小限にする。管理用ツールフレームワーク２００は、開発者が管理用ツールフレームワーク２００によって提供される共通機能を容易に利用することを可能にするためのシンタクス（たとえば文法）、対応するセマンティクス（たとえば辞書）、および参照モデルを提供する。

本発明をさらに説明する前に、本明細書を通して現れる追加用語の定義が与えられる。入力パラメータは、ｃｍｄｌｅｔ用の入力フィールドを指す。引数は、ａｒｇｖアレイ中のただ１つの文字列の等価物であるｃｍｄｌｅｔに渡され、またはｃｍｄｌｅｔオブジェクト中のただ１つの要素として渡される入力パラメータを指す。後で説明されるように、ｃｍｄｌｅｔは、文法を指定する機構を提供する。機構は、直接的にも間接的にも提供され得る。引数は、オプション、オプション引数、またはコマンド名に続くオペランドの１つである。引数の例が、次のコマンドラインに基づいて与えられる。

上記のコマンドラインにおいて、「ｆｉｎｄｓｔｒ」は引数０であり、「／ｉ」は引数１であり、「／ｄ：￥ｗｉｎｎｔ；￥ｗｉｎｎｔ￥ｓｙｓｔｅｍ３２」は引数２であり、「ａａ＊ｂ」は引数３であり、「＊．ｉｎｉ」は引数４である。「オプション」は、概してプログラムのデフォルト動作に対する変更を指定するのに使われる、ｃｍｄｌｅｔへの引数である。上のコマンドラインの例で続けると、「／ｉ」および「／ｄ」がオプションである。オプション引数は、特定のオプションに続く入力パラメータである。一部の場合では、オプション引数は、オプションと同じ引数文字列に含まれる。それ以外の場合では、オプション引数は、次の引数として含まれる。再度上記のコマンドラインを参照すると、「ｗｉｎｎｔ；￥ｗｉｎｎｔ￥ｓｙｓｔｅｍ３２」がオプション引数である。「オペランド」は、概して、プログラム処理を完了するのに必要な情報をプログラムに供給するオブジェクトとして使われるｃｍｄｌｅｔへの引数である。オペランドは概して、コマンドライン中でオプションの後に続く。再度上のコマンドラインの例を参照すると、「ａａ＊ｂ」および「＊．ｉｎｉ」がオペランドである。「解析可能ストリーム」は、引数を含む。

図１３を参照すると、パーサ２２０は、解析可能ストリーム（たとえば、コマンド文字列１３５０）を構成要素１３２０〜１３２６（たとえば、ｗｈｅｒｅ部分１３２２）に解析する。各部分１３２０〜１３２６は、ｃｍｄｌｅｔ１３３０〜１３３６の１つに関連づけられる。パーサ２２０およびエンジン２２４は、解析、パラメータ認証、データ生成、パラメータ処理、パラメータエンコーディング、およびパラメータドキュメンテーションなど、様々な処理を実施する。パーサ２２０およびエンジン２２４は、コマンドライン上の入力パラメータに対して共通機能を実施するので、管理用ツールフレームワーク２００は、一貫したエラーメッセージをユーザに発行することができる。

本発明による管理用ツールフレームワークに従って書かれた実行可能ｃｍｄｌｅｔ１３３０〜１３３６は、従来の管理環境におけるコマンドより少ないコードを必要とすることが認識されよう。各実行可能ｃｍｄｌｅｔ１３３０〜１３３６は、それぞれの構成要素１３２０〜１３２６を使って識別される。さらに、（矢印１３４０、１３４２、１３４４、および１３４６で表される）各実行可能ｃｍｄｌｅｔ１３３０〜１３３６は、オブジェクトを出力し、こうした出力オブジェクトは、（矢印１３４１、１３４３、および１３４５で表される）入力オブジェクトとして次のパイプライン型ｃｍｄｌｅｔに入力される。こうしたオブジェクトは、オブジェクトに参照（たとえばハンドル）を渡すことによって入力され得る。実行可能ｃｍｄｌｅｔ１３３０〜１３３６は次いで、ハンドルを渡されたオブジェクトに対して追加処理を実施することができる。

図１４は、図９に示される入力を操作するプロセスでの使用に適したコマンド文字列の処理をより詳しく示す論理フロー図である。コマンド文字列処理は、ブロック１４０１で始まり、ここで、パーサまたはスクリプトエンジンが、入力中のコマンド文字列を識別している。概して、コアエンジンは、ｃｍｄｌｅｔのデータフローに対してセットアップおよび順序付けを実施する。１つのｃｍｄｌｅｔ用のセットアップおよび順序付けは、後で説明されるが、パイプライン中の各ｃｍｄｌｅｔに適用可能である。処理は、ブロック１４０４で継続する。

ブロック１４０４で、ｃｍｄｌｅｔが識別される。ｃｍｄｌｅｔの識別は、登録を介し得る。コアエンジンは、ｃｍｄｌｅｔがローカルであるか、それともリモートであるか判定する。ｃｍｄｌｅｔは、１）管理用ツールフレームワークのアプリケーションドメイン内部、２）管理用ツールフレームワークと同じプロセスの別のアプリケーションドメイン内部、３）同じコンピューティングデバイス上の別のプロセス中、または４）リモートコンピューティングデバイス内部で実行され得る。同じプロセス中で動作しているｃｍｄｌｅｔの間の通信は、オブジェクトを介する。異なるプロセス中で動作しているｃｍｄｌｅｔの間の通信は、直列構造データ形式による。例示的な一直列構造データ形式は、拡張マークアップ言語（ＸＭＬ）に基づく。処理は、ブロック１４０６で継続する。

ブロック１４０６で、ｃｍｄｌｅｔオブジェクトのインスタンスが作成される。ｃｍｄｌｅｔのインスタンスを作成する例示的なプロセスが、後で図１５とともに説明される。ｃｍｄｌｅｔオブジェクトが作成されると、処理は、ブロック１４０８で継続する。

ブロック１４０８で、ｃｍｄｌｅｔオブジェクトに関連づけられたプロパティが投入される。上述したように、開発者は、ｃｍｄｌｅｔクラスの中、または外部ソースの中でプロパティを宣言する。簡潔には、管理用ツールフレームワークは、プロパティに対して宣言される名称およびタイプに基づいて、受信オブジェクト（群）を解読し、ｃｍｄｌｅｔクラスからインスタンス化されたｃｍｄｌｅｔにする。タイプが異なる場合、タイプは、拡張データ型マネージャを介して強制的に変換され得る。前述されたように、パイプライン型コマンド文字列において、各ｃｍｄｌｅｔの出力は、オブジェクトへのハンドルのリストとなり得る。次のｃｍｄｌｅｔは、このオブジェクトハンドルリストを入力し、処理を実施し、オブジェクトハンドルの別のリストを次のｃｍｄｌｅｔに渡す。さらに、図７に示されるように、入力パラメータは、コマンドラインから届くものとして指定され得る。ｃｍｄｌｅｔに関連するプロパティを投入する例示的な一方法が、後で図１６とともに説明される。ｃｍｄｌｅｔが投入を行われると、処理は、ブロック１４１０で継続する。

ブロック１４１０で、ｃｍｄｌｅｔが実行される。概して、ｃｍｄｌｅｔによって提供される処理は、少なくとも一度実施され、これは、ｃｍｄｌｅｔへの各入力オブジェクトの処理を含む。したがって、ｃｍｄｌｅｔがパイプライン型コマンド文字列中の第１のｃｍｄｌｅｔである場合、処理は一度実行される。後続ｃｍｄｌｅｔについては、処理は、ｃｍｄｌｅｔに渡される各オブジェクトごとに実行される。ｃｍｄｌｅｔを実行する例示的な一方法が、後で図５とともに説明される。入力パラメータが、コマンドラインからのみ届いている場合、ｃｍｄｌｅｔの実行は、基本ｃｍｄｌｅｔケースによって提供されるデフォルトメソッドを用いる。ｃｍｄｌｅｔが実行を終了されると、処理はブロック１４１２へ進む。

ブロック１４１２で、ｃｍｄｌｅｔがクリーンアップされる。クリーンアップは、メモリの割振り解除などを担当する、関連するｃｍｄｌｅｔオブジェクト用デストラクタ(destructor)のコールを含む。コマンド文字列の処理は次いで、完了する。

（ｃｍｄｌｅｔオブジェクトを作成する例示的なプロセス）
図１５は、図１４に示されるコマンド文字列処理での使用に適した、ｃｍｄｌｅｔを作成する例示的なプロセスを示す論理フロー図である。この時点で、ｃｍｄｌｅｔデータ構造が開発されており、属性および予想される入力パラメータが指定されている。ｃｍｄｌｅｔは、コンパイルされ登録されている。登録の間、クラス名（すなわち、ｃｍｄｌｅｔ名）が登録ストアに書き込まれ、ｃｍｄｌｅｔに関連づけられたメタデータが格納されている。プロセス１５００は、ブロック１５０１で始まり、ここで、パーサは、ｃｍｄｌｅｔを示す入力（たとえばキーストローク）を受け取っている。パーサは、レジストリ中から入力をルックアップし、登録されたｃｍｄｌｅｔの１つに入力を関連づけることによって、入力をｃｍｄｌｅｔとして認識し得る。処理はブロック１５０４へ進む。

ブロック１５０４で、ｃｍｄｌｅｔオブジェクトクラスに関連づけられたメタデータが読み取られる。メタデータは、ｃｍｄｌｅｔに関連づけられたディレクティブのいずれをも含む。ディレクティブは、ｃｍｄｌｅｔ自体にも、パラメータの１つまたは複数にも適用し得る。ｃｍｄｌｅｔの登録中、登録コードは、メタデータを永続ストアに登録する。メタデータは、シリアル化形式のＸＭＬファイル、外部データベースなどに格納され得る。スクリプト処理中のディレクティブの処理と同様に、ディレクティブの各カテゴリーは、様々な段階で処理される。各メタデータディレクティブは、独自のエラー操作を扱う。処理は、ブロック１５０６で継続する。

ブロック１５０６で、識別されたｃｍｄｌｅｔクラスに基づいてｃｍｄｌｅｔオブジェクトがインスタンス化される。処理は、ブロック１５０８で継続する。

ブロック１５０８で、ｃｍｄｌｅｔについての情報が入手される。情報入手は、リフレクションまたは他の手段を介して起こり得る。情報は、予想される入力パラメータに関するものである。上述したように、パブリック宣言されるパラメータ（たとえば、ｐｕｂｌｉｃ ｓｔｒｉｎｇ Ｎａｍｅ７３０）は、コマンドライン上のコマンド文字列中で指定されることも入力ストリーム中で与えられることもできる、予想される入力パラメータに対応する。図１８で説明される、拡張タイプマネージャによる管理用ツールフレームワークは、（必要に応じて）コール側に情報を返す共通インターフェイスを提供する。処理は、ブロック１５１０で継続する。

ブロック１５１０で、使用可能性ディレクティブ（たとえば、テーブル１）が適用される。使用可能性ディレクティブは、クラスが特定のマシン役割および／またはユーザ役割において使われることを保証する。たとえば、特定のｃｍｄｌｅｔは、ドメイン管理者によってのみ使われ得る。使用可能性ディレクティブの１つにおいて指定された制約が満たされない場合、エラーが起こる。処理は、ブロック１５１２で継続する。

ブロック１５１２で、メタデータが、インテリセンスを提供するのに使われる。処理のこの時点で、コマンド文字列全体は、まだ入力されていない。しかし、管理用ツールフレームワークは、使用可能なｃｍｄｌｅｔを知っている。ｃｍｄｌｅｔが判別されると、管理用ツールフレームワークは、ｃｍｄｌｅｔオブジェクトをリフレクトすることによって、許可される入力パラメータを知る。したがって、管理用ツールフレームワークは、ｃｍｄｌｅｔ名のあいまい性排除部分が与えられるとｃｍｄｌｅｔを自動補完し、次いで、入力パラメータのあいまい性排除部分がコマンドライン上でタイプされると入力パラメータを自動補完することができる。自動補完は、入力パラメータの部分が入力パラメータの１つを明確に識別できるとすぐに起こり得る。さらに、自動補完は、ｃｍｄｌｅｔ名およびオペランドに対しても起こり得る。処理は、ブロック１５１４で継続する。

ブロック１５１４で、プロセスは、ｃｍｄｌｅｔ用の入力パラメータが入力されるまで待機する。この待機は、リターンキーを打つことなどによって、ユーザがコマンド文字列の終わりを示すと起こり得る。スクリプト中では、新規行が、コマンド文字列の終わりを示す。この待機は、パラメータに関する付加情報のユーザからの入手、および他のディレクティブの適用を含み得る。ｃｍｄｌｅｔがパイプライン型パラメータの１つである場合、処理は直ちに始まり得る。必要なコマンド文字列および入力パラメータが与えられると、処理は完了する。

（ｃｍｄｌｅｔに投入を行う例示的なプロセス）
ｃｍｄｌｅｔに投入を行う例示的なプロセスが、図１６に示され、図５とともに次に説明される。例示的な一管理用ツールフレームワークにおいて、コアエンジンは、ｃｍｄｌｅｔ用パラメータを投入するための処理を実施する。処理は、ｃｍｄｌｅｔのインスタンスが作成された後、ブロック１６０１で始まる。処理は、ブロック１６０２へ続く。

ブロック１６０２で、ｃｍｄｌｅｔ内部で宣言されたパラメータ（たとえば、ＰｒｏｃｅｓｓＮａｍｅ）が取得される。ｃｍｄｌｅｔを用いた宣言に基づいて、コアエンジンは、受信入力オブジェクトが、「ＰｒｏｃｅｓｓＮａｍｅ」という名前のプロパティを提供すると認識する。受信プロパティのタイプが、パラメータ宣言で指定されたタイプと異なる場合、タイプは、拡張タイプマネージャにより強制的に変換される。データ型を強制的に変換するプロセスは、後で「例示的な拡張タイプマネージャ処理」というサブセクションで説明される。処理は、ブロック１６０３へ続く。

ブロック１６０３で、パラメータに関連づけられた属性が取得される。属性は、パラメータ用の入力ソースがコマンドラインであるかどうか、または入力がパイプラインからであるかどうかを識別する。処理は、判断ブロック１６０４へ続く。

判断ブロック１６０４で、属性が入力ソースをコマンドラインとして指定しているかどうか、判定が行われる。入力ソースがコマンドラインの場合、処理は、ブロック１６０９で継続する。コマンドラインでない場合、処理は、判断ブロック１６０５で継続する。

判断ブロック１６０５で、宣言において指定されたプロパティ名が使われるべきかどうか、またはプロパティ名に対するマッピングが使われるべきかどうか判定が行われる。この判定は、コマンド入力が、パラメータに対してマッピングを指定したかどうかに基づく。次の行は、受信オブジェクトの「ｆｏｏ」メンバへの、パラメータ「ＰｒｏｃｅｓｓＮａｍｅ」の例示的なマッピングを示す。

$ get/process | where han* -gt 500 | stop/process -ProcessName<-foo
処理は、ブロック１６０６で継続する。

ブロック１６０６で、マッピングが適用される。マッピングは、予想されるパラメータの名称を、「ＰｒｏｃｅｓｓＮａｍｅ」から「ｆｏｏ」に置き換え、置き換えられた後の名称は次いで、コアエンジンによって、受信オブジェクトを解析し、予想される正しいパラメータを識別するのに使われる。処理は、ブロック１６０８で継続する。

ブロック１６０８で、拡張タイプマネージャは、パラメータ用の値を受信オブジェクト中に配置するために問合せを受ける。拡張タイプマネージャとともに説明したように、拡張タイプマネージャは、パラメータ名を受け取り、リフレクションを用いて、パラメータ名を有する受信オブジェクト中でパラメータを識別する。拡張タイプマネージャは、必要な場合、パラメータに対して他の処理も実施することができる。たとえば、拡張タイプマネージャは、上述された変換機構により、データのタイプを、予想されるデータ型に強制的に変換することができる。処理は、判断ブロック１６１０へ続く。

ブロック１６０９に戻ると、属性が、入力ソースがコマンドラインであると指定している場合、コマンドラインからのデータが入手される。コマンドラインからのデータの入手は、拡張タイプマネージャを介して実施され得る。処理は次いで、判断ブロック１６１０へ続く。

判断ブロック１６１０で、予想される別のパラメータがあるかどうか、判定が行われる。予想される別のパラメータがある場合、処理は、ブロック１６０２にループバックし、上述されたように進行する。別のパラメータがない場合、処理は完了し、戻る。

したがって、説明されたように、ｃｍｄｌｅｔは、受信データを分解して、予想されるパラメータを入手するテンプレートとして作用する。さらに、予想されるパラメータは、予想されるパラメータの値を提供する受信オブジェクトのタイプを知らなくても入手される。これは、従来の管理環境と大きく異なる。従来の管理環境は、密束縛され、オブジェクトのタイプがコンパイル時に知られていることを要求する。さらに、従来の環境では、予想されるパラメータは、値または参照によって関数に渡されている。したがって、本発明による解析（たとえば「分解」）機構は、プログラマが、こうしたパラメータの値がどのようにして取得されるかを具体的に知ることを要せずに、パラメータのタイプを指定することを可能にする。

たとえば、ｃｍｄｌｅｔ Ｆｏｏに対して次の宣言が与えられる。

コマンドラインシンタクスは、次のいずれでもよい。

規則の組は、所望のシンタクスを提供するために、システム管理者によって修正され得る。さらに、パーサは、複数のシンタクスがユーザによって使われ得るように、複数の規則の組をサポートすることができる。本質的に、ｃｍｄｌｅｔ構造（たとえば、ｓｔｒｉｎｇ ＮａｍｅおよびＢｏｏｌ Ｒｅｃｕｒｓｅ）に関連づけられた文法が、パーサを駆動する。

概して、解析ディレクティブは、コマンド文字列として入力されたパラメータが、ｃｍｄｌｅｔオブジェクト中で識別される、予想されるパラメータにどのようにしてマップするべきかを記述する。入力パラメータタイプは、正しいかどうか判定するために調べられる。入力パラメータタイプが正しくない場合、入力パラメータは、正しくなるように強制的に変換され得る。入力パラメータタイプが正しくなく、強制的に変換されることもできない場合、使用上のエラーが印字される。使用上のエラーは、期待される正しいシンタクスをユーザに気づかせる。使用上のエラーは、ドキュメンテーションディレクティブから、シンタクスを記述する情報を入手することができる。入力パラメータタイプがマッピングされるか、または認証されると、ｃｍｄｌｅｔオブジェクトインスタンス中の対応するメンバが投入される。メンバが投入されるとき、拡張タイプマネージャは、入力パラメータタイプの処理をもたらす。簡潔には、処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ機構、関係機構、およびプロパティセット機構を含み得る。こうした機構はそれぞれ、後で、説明のための例も含む「拡張タイプマネージャ処理」というセクションで詳しく説明される。

（ｃｍｄｌｅｔを実行する例示的なプロセス）
ｃｍｄｌｅｔを実行する例示的なプロセスが図１７に示され、次に説明される。例示的な一管理用ツール環境において、コアエンジンは、ｃｍｄｌｅｔを実行する。上述したように、第２のメソッド５４０内部のコード５４２が、各入力オブジェクトに対して実行される。処理は、ブロック１７０１で始まり、ここで、ｃｍｄｌｅｔは既に投入を受けている。処理は、ブロック１７０２で継続する。

ブロック１７０２で、コード５４２にあるステートメントが、実行のために取得される。処理は、判断ブロック１７０４で継続する。

判断ブロック１７０４で、ステートメント中にフックが含まれるかどうか、判定が行われる。一時的に図５に移ると、フックは、コアエンジンによって提供されるＡＰＩのコールを含み得る。たとえば、図５のｃｍｄｌｅｔ５００のコード５４２中のステートメント５５０は、必要なパラメータ、第１の文字列（たとえば、「ＰＩＤ＝」）、およびパラメータ（たとえば、ＰＩＤ）を指定するｃｏｎｆｉｒｍｐｒｏｃｅｓｓｉｎｇ ＡＰＩをコールする。図１７に戻ると、ステートメントがフックを含む場合、処理は、ブロック１７１２へ続く。したがって、ｃｏｎｆｉｒｍｐｒｏｃｅｓｓｉｎｇ ＡＰＩをコールする命令が指定された場合、ｃｍｄｌｅｔは、動作環境によって提供される代替実行モードで動作する。それ以外の場合、処理は、ブロック１７０６で継続し、実行は、「ノーマル」モードで継続する。

ブロック１７０６で、ステートメントが処理される。処理は次いで、判断ブロック１７０８へ進む。ブロック１７０８で、コードが別のステートメントを含むかどうか、判定が行われる。別のステートメントがある場合、処理は、ブロック１７０２にループバックして、次のステートメントを入手し、上述されたように進行する。別のステートメントがない場合、処理は判断ブロック１７１４へ続く。

判断ブロック１７１４で、処理すべき別の入力オブジェクトがあるかどうか、判定が行われる。別の入力オブジェクトがある場合、処理は、ブロック１７１６へ続き、ここで、ｃｍｄｌｅｔは、次のオブジェクトからのデータを投入される。図１６で説明される投入プロセスが、次のオブジェクトで実施される。処理は次いで、ブロック１７０２にループバックし、上述されたように進行する。オブジェクトすべてが処理されると、ｃｍｄｌｅｔ実行プロセスは完了し、戻る。

判断ブロック１７０４に戻ると、ステートメントがフックを含む場合、処理は、ブロック１７１２へ続く。ブロック１７１２で、管理用ツール環境によってもたらされる追加特徴が処理される。処理は、判断ブロック１７０８で継続し、上述されたように継続する。

ブロック１７１２において実施される追加処理が、次に、図６に示される例示的なデータ構造６００とともに説明される。上で説明されたように、コマンド基本クラス６００中には、予想される追加入力パラメータ（たとえばスイッチ）に対応すると宣言したパラメータが存在し得る。

スイッチは、所定の文字列を含み、認識されると、ｃｍｄｌｅｔに付加機能を提供するよう、コアエンジンに指図する。パラメータｖｅｒｂｏｓｅ６１０が、コマンド入力中で指定された場合、ｖｅｒｂｏｓｅステートメント６１４が実行される。以下は、ｖｅｒｂｏｓｅスイッチを含むコマンドラインの例である。

概して、「−ｖｅｒｂｏｓｅ」が、コマンド入力中で指定された場合、コアエンジンは、各入力オブジェクトに対してコマンドを実行し、表示のために各入力オブジェクトごとにホストプログラムに対して実行された実際のコマンドを転送する。以下は、上記のコマンドラインが例示的な管理用ツール環境において実行されたときに生成される出力の例である。

パラメータｗｈａｔｉｆ６２０がコマンド入力中で指定された場合、ｗｈａｔｉｆステートメント６２４が実行される。以下は、ｗｈａｔｉｆスイッチを含むコマンドラインの例である。

概して、「−ｗｈａｔｉｆ」が指定されると、コアエンジンは、実際にはコード５４２を実行するのではなく、表示のためにホストプログラムに対して実行されているはずのコマンドを送る。以下は、本発明の例示的な管理用ツール環境において上記のコマンドラインが実行されたときに生成される出力の例である。

パラメータｃｏｎｆｉｒｍ６３０がコマンド入力中で指定された場合、ｃｏｎｆｉｒｍステートメント６３４が実行される。以下は、ｃｏｎｆｉｒｍスイッチを含むコマンドラインの例である。

概して、「−ｃｏｎｆｉｒｍ」が指定されると、コアエンジンは、コマンドを進めるかどうかに関して、追加ユーザ入力を要求する。以下は、本発明の例示的な管理用ツール環境において上記のコマンドラインが実行されたときに生成される出力の例である。

上述したように、例示的なデータ構造６００は、実行に対して要求されているタスクが許可されるべきかどうか判定するセキュリティメソッド６４０も含み得る。従来の管理環境では、各コマンドは、コマンドを実行している人がコマンドを実施するのに十分な特権を有しているかどうかのチェックを担当する。このチェックを実施するために、いくつかのソースからの情報にアクセスするのに、拡張コードが必要とされる。こうした複雑さのせいで、多くのコマンドは、セキュリティチェックを実施しなかった。本管理用ツール環境の発明者は、タスクがコマンド入力中で指定されると、セキュリティチェックの実施に必要な情報が管理用ツール環境において利用可能であると認識した。したがって、管理用ツールフレームワークは、ツール開発者に対して複雑なコードを要求せずにセキュリティチェックを実施する。セキュリティチェックは、ｃｍｄｌｅｔ中でフックを定義するどのｃｍｄｌｅｔに対しても実施され得る。あるいは、フックは、上述されたｖｅｒｂｏｓｅパラメータと同様に、コマンド入力中で指定され得る任意選択の入力パラメータでもよい。

セキュリティチェックは、概してユーザの役割に基づいて、どのユーザがリソースへのアクセス権をもつかをコントロールするシステムとして定義される、役割ベースの認証をサポートするように実装される。したがって、各役割は、異なるリソースへの特定のアクセス権を割り当てられる。ユーザは次いで、１つまたは複数の役割に割り当てられる。概して、役割ベースの認証は、３つの項目、すなわち原理、リソース、およびアクションに注目する。リソースに対してアクションが実施されるよう要求したのは誰かを、原理が識別する。

本発明の発明者は、要求されているｃｍｄｌｅｔが、実施されるべきアクションに対応することを認識した。さらに、本発明者は、管理用ツールフレームワークが実行されているプロセスの所有者が、原理に対応することを認識した。さらに、本発明者は、リソースがｃｍｄｌｅｔ中で指定されることを認識した。したがって、管理用ツールフレームワークは、こうした項目へのアクセス権をもっているので、本発明者は、セキュリティチェックは、ツール開発者がセキュリティチェックを実装することを要せずに管理用ツールフレームワーク内部から実施され得ることを認識した。

セキュリティチェックの動作は、ｃｏｎｆｉｒｍｐｒｏｃｅｓｓｉｎｇ ＡＰＩなどのフックを用いることによって、ｃｍｄｌｅｔ内部で付加機能が要求されるといつでも実施され得る。あるいは、セキュリティチェックは、ｖｅｒｂｏｓｅ、ｗｈａｔｉｆ、およびｃｏｎｆｉｒｍと同様にコマンドライン上でセキュリティスイッチが入れられたかどうか調べることによっても、実施され得る。いずれの実装の場合でも、ｃｈｅｃｋＳｅｃｕｒｉｔｙメソッドは、誰が許可されるかを判定する１組のＡＰＩを提供するセキュリティプロセス（図示せず）によって提供されるＡＰＩをコールする。セキュリティプロセスは、管理用ツールフレームワークによって提供される情報を受け取り、タスクが完了され得るかどうかを示す結果をもたらす。管理用ツールフレームワークは次いで、エラーをもたらしても、単にタスクの実行を停止してもよい。

したがって、ｃｍｄｌｅｔ中でフックを提供することによって、開発者は、管理用ツールフレームワークによって提供される追加処理を使うことができる。

（例示的な拡張タイプマネージャ処理）
図１８とともに上で簡潔に述べられたように、拡張タイプマネージャは、供給されるオブジェクトに対して追加処理を実施することができる。追加処理は、パーサ２２０、スクリプトエンジン２２２、またはパイプラインプロセッサ４０２からの要求時に実施され得る。追加処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ機構、関係機構、およびプロパティセット機構を含む。拡張タイプマネージャは、特許請求の範囲に記載されている本発明の範囲から逸脱することなく、他の処理を用いても拡張され得ることを当業者は理解するであろう。追加処理機構がそれぞれ、次に説明される。

最初に、プロパティパス機構が、文字列に、オブジェクトのプロパティをナビゲートさせる。現在のリフレクションシステムでは、クエリは、オブジェクトのプロパティを照会することができる。しかし、本発明による拡張タイプマネージャでは、オブジェクトの一連のプロパティへのナビゲーションパスを提供する文字列が指定され得る。プロパティパスの例示的なシンタクスは、Ｐ１．Ｐ２．Ｐ３．Ｐ４である。

各コンポーネント（たとえば、Ｐ１、Ｐ２、Ｐ３、およびＰ４）は、プロパティ、パラメータを有するメソッド、パラメータをもたないメソッド、フィールド、ＸＰＡＴＨなどを表し得る文字列を含む。ＸＰＡＴＨは、要素（たとえば、「／ＦＯＯ＠＝１３」）を検索するためのクエリ文字列を指定する。文字列には、コンポーネントのタイプを具体的に示すための特殊文字が含まれ得る。文字列が特殊文字を含まない場合、拡張タイプマネージャは、コンポーネントのタイプを判定するためのルックアップを実施し得る。たとえば、コンポーネントＰ１がオブジェクトの場合、拡張タイプマネージャは、Ｐ２が、オブジェクトのプロパティ、オブジェクトのメソッド、オブジェクトのフィールド、またはプロパティセットであるか照会し得る。拡張タイプマネージャが、Ｐ２のタイプを識別すると、そのタイプに従った処理が実施される。コンポーネントが、上記のタイプの１つでない場合、拡張タイプマネージャは、拡張ソースをさらに照会して、Ｐ１タイプをＰ２タイプに変換するための変換関数が存在するかどうか判定することができる。こうしたおよび他のルックアップが、例示的なコマンド文字列を使い、それぞれの出力を示して次に説明される。

以下は、プロパティパスを含む例示的な文字列である。
$ get/process | /where hand* -gt> 500 | format/table name.toupper, ws.kb, exe*.ver*.description.tolower.trunc(30)

上記の例示的な文字列中には、３つのプロパティパス、すなわち（１）「ｎａｍｅ．ｔｏｕｐｐｅｒ」、（２）「ｗｓ．ｋｂ」、および（３）「ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０）がある。こうしたプロパティパスについて述べる前に、「ｎａｍｅ」、「ｗｓ」、および「ｅｘｅ」は、テーブルのプロパティを指定することに留意すべきである。さらに、こうしたプロパティはそれぞれ、最初に「ｇｅｔ／ｐｒｏｃｅｓｓ」によって生成され、次いで、様々なｃｍｄｌｅｔを介してパイプライン処理される受信オブジェクトの直接プロパティであることに留意すべきである。３つのプロパティパスそれぞれに関わる処理が次に説明される。

第１のプロパティパス（すなわち、「ｎａｍｅ．ｔｏｕｐｐｅｒ」）において、ｎａｍｅは、受信オブジェクトの直接プロパティであり、オブジェクト自体でもある。拡張タイプマネージャは、上述された優先度ルックアップを用いてシステムを照会して、ｔｏｕｐｐｅｒのタイプを判定する。拡張タイプマネージャは、ｔｏｕｐｐｅｒがプロパティでないことを発見する。ただし、ｔｏｕｐｐｅｒは、文字列タイプによって継承される、文字列中で小文字を大文字に変換するためのメソッドであり得る。あるいは、拡張タイプマネージャは、名前オブジェクトを大文字に変換し得るサードパーティコードが存在するかどうか判定するために、拡張メタデータを照会している可能性もある。コンポーネントタイプがわかると、そのコンポーネントタイプに従って処理が実施される。

第２のプロパティパス（すなわち、「ｗｓ．ｋｂ」）において、「ｗｓ」は、受信オブジェクトの直接プロパティであり、オブジェクト自体でもある。拡張タイプマネージャは、「ｗｓ」が整数であると判定する。次いで、拡張タイプマネージャは、ｋｂが整数プロパティであるかどうか、ｋｂが整数のメソッドであるかどうかを照会し、最後に、どのようにして整数を受け取り、整数をkbタイプに変換するかをいずれかのコードが知っているかを照会する。サードパーティのコードが、この変換を実施するために登録され、変換が実施される。

第３のプロパティパス（すなわち、「ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０）」）には、いくつかのコンポーネントがある。第１のコンポーネント（「ｅｘｅ＊」）は、受信オブジェクトの直接プロパティであり、オブジェクトでもある。やはり、拡張タイプマネージャは、第２のコンポーネント（「ｖｅｒ＊」）を処理するためにルックアップクエリを進む。「ｅｘｅ＊」オブジェクトは、「ｖｅｒ＊」プロパティもメソッももたないので、拡張タイプマネージャは、拡張メタデータを照会して、実行ファイル名をバージョンに変換するために登録されているコードがあるかどうか、判定する。この例では、このようなコードが存在する。このコードは、実行ファイル名文字列を受け取り、ファイルを開くのに使うことができ、次いで、バージョンブロックオブジェクトにアクセスし、バージョンブロックオブジェクトの記述プロパティ（第３のコンポーネント（「ｄｅｓｃｒｉｐｔｉｏｎ」）を返す。拡張タイプマネージャは次いで、第４のコンポーネント（「ｔｏｌｏｗｅｒ」）および第５のコンポーネント（「ｔｒｕｎｃ（３０）」）に対して、この同じルックアップ機構を実施する。したがって、説明されたように、拡張タイプマネージャは、管理者が具体的なコードを何も書く必要なく、コマンド文字列に対して極めて入念な処理を実施することができる。テーブル１は、例示的な文字列に対して生成される出力を示す。

別のクエリ機構１８２４は、キーを含む。キーは、データ型のインスタンスを一義的にする１つまたは複数のプロパティを識別する。たとえば、データベース中で、ある列が、各行を一義的に識別し得るキー（たとえば、社会保障番号）として識別され得る。キーは、データ型に関連づけられたタイプメタデータ１８４０に格納される。このキーは次いで、そのデータ型のオブジェクトを処理するときに拡張タイプマネージャによって使われ得る。データ型は、拡張データ型でも、既存のデータ型でもよい。

別のクエリ機構１８２４は、比較機構を含む。比較機構は、２つのオブジェクトを比較する。２つのオブジェクトが、比較関数を直接サポートする場合、直接サポートされる比較関数が実行される。しかし、どちらのオブジェクトも比較関数をサポートしない場合、拡張タイプマネージャは、タイプメタデータの中で、２つのオブジェクトの比較をサポートするために登録されているコードを探し得る。比較機構を伴う例示的な一連のコマンドライン文字列が、テーブル２の中の対応する出力とともに下に示されている。

ｃｏｍｐａｒｅ／ｔｉｍｅ ｃｍｄｌｅｔは、２つのｄａｔｅｔｉｍｅオブジェクトを比較するために書かれる。この場合、ＤａｔｅＴｉｍｅオブジェクトは、ＩＣｏｍｐａｒａｂｌｅインターフェイスをサポートする。

別のクエリ機構１８２４は、変換機構を含む。拡張タイプマネージャは、具体的な変換を実施する機能を言明するコードを登録させる。次いで、タイプＡのオブジェクトが入力されるとともにｃｍｄｌｅｔがタイプＢのオブジェクトを指定すると、拡張タイプマネージャは、登録された変換の１つを用いて変換を実施し得る。拡張タイプマネージャは、タイプＡをタイプＢに強制的に変換するために、一連の変換を実施し得る。上述されたプロパティパス（「ｗｓ．ｋｂ」）は、変換機構を示す。

別のクエリ機構１８２４は、グロバ機構を含む。グロバは、文字列中のワイルドカード文字を指す。グロバ機構は、ワイルドカード文字を有する文字列を入力し、１組のオブジェクトを生じる。拡張タイプマネージャは、ワイルドカード処理を指定するコードを登録させる。上述されたプロパティパス（「ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０））は、グロバ機構を示す。登録されたプロセスは、ファイル名、ファイルオブジェクト、受信プロパティなどに対してグロビングを提供し得る。

別のクエリ機構１８２４は、プロパティセット機構を含む。プロパティセット機構は、１組のプロパティ用の名称を定義させる。管理者は次いで、コマンド文字列中で名称を指定して、プロパティの組を入手することができる。プロパティセットは、様々な方式で定義され得る。一方式では、「？」など、予め定義されたパラメータが、ｃｍｄｌｅｔ用の入力パラメータとして入力され得る。動作環境は、予め定義されたパラメータを認識すると、受信オブジェクトのプロパティすべてを列挙する。リストは、管理者が、望まれるプロパティを容易にチェックする（たとえば、「クリックする」）とともにプロパティセットに名前をつけることを可能にするＧＵＩでよい。プロパティセット情報は次いで、拡張メタデータに格納される。プロパティセット機構を呼び出す例示的な文字列が、テーブル３の対応する出力とともに下に示されている。

この例示的な文字列では、「ｃｏｎｆｉｇ」というプロパティセットが、名称プロパティ、プロセスｉｄプロパティ（Ｐｉｄ）、および優先度プロパティを含むように定義されている。このテーブル用の出力が次に示される。

別のクエリ機構１８２４は、関係機構を含む。１つの関係（すなわち、継承）をサポートする従来型システムとは対照的に、関係機構は、タイプの間の複数の関係の表現をサポートする。やはり、こうした関係も登録される。関係は、オブジェクトが使用する項目を見つけることも、オブジェクトを使用する項目を見つけることも含み得る。拡張タイプマネージャは、様々な関係を記述する存在論（オントロジー）にアクセスし得る。拡張メタデータおよびコードを用いて、どのオントロジーサービスにも、たとえばＯＷＬ、ＤＡＷＬなどにアクセスする仕様が記述され得る。．ＯＷＬ：”ｓｔｒｉｎｇ”が、関係機構を使用する例示的な文字列の一部分である。

「ＯＷＬ」識別子は、オントロジーサービスを識別し、「ｓｔｒｉｎｇ」は、オントロジーサービスにおける具体的な文字列を指定する。したがって、拡張タイプマネージャは、オントロジーサービスによって供給されるタイプにアクセスし得る。

（コマンドラインデータを表示する例示的なプロセス）
本機構は、データ駆動コマンドライン出力を提供する。データのフォーマット化および出力は、ｃｍｄｌｅｔからなるパイプライン中の１つまたは複数のｃｍｄｌｅｔによって実現される。通常、こうしたｃｍｄｌｅｔは、上で図２とともに説明された非管理ｃｍｄｌｅｔに含まれる。ｃｍｄｌｅｔは、フォーマットｃｍｄｌｅｔ、マークアップｃｍｄｌｅｔ、変換ｃｍｄｌｅｔ、変形ｃｍｄｌｅｔ、およびアウトｃｍｄｌｅｔを含み得る。

図１９は、パイプライン中のこうしたｃｍｄｌｅｔの例示的なシーケンス１９０１〜１９０７を図表により示す。第１のシーケンス１９０１は、パイプライン中の最後のｃｍｄｌｅｔとしてアウトｃｍｄｌｅｔ１９１０を示す。他のｃｍｄｌｅｔに対して上述されたのと同じやり方で、アウトｃｍｄｌｅｔ１９１０は、パイプライン中の他のｃｍｄｌｅｔによって生成され処理されたパイプラインオブジェクトのストリームを受諾する。ただし、ほとんどのｃｍｄｌｅｔとは対照的に、アウトｃｍｄｌｅｔ１９１０は、他のｃｍｄｌｅｔ用にパイプラインオブジェクトを送出しない。そうではなく、アウトｃｍｄｌｅｔ１９１０は、パイプラインによって生成された結果のレンダリング／表示を担当する。各アウトｃｍｄｌｅｔ１９１０は、デバイス、プログラムなど、出力の宛先に関連づけられる。たとえば、コンソールデバイスに対して、アウトｃｍｄｌｅｔ１９１０は、ｏｕｔ／ｃｏｎｓｏｌｅとして指定されることができ、インターネットブラウザに対して、アウトｃｍｄｌｅｔ１９１０は、ｏｕｔ／ｂｒｏｗｓｅｒとして指定されることができ、ウィンドウに対して、アウトｃｍｄｌｅｔ１９１０は、ｏｕｔ／ｗｉｎｄｏｗとして指定されることができる。具体的な各アウトｃｍｄｌｅｔは、それに関連づけられた宛先の機能を熟知しいている。変換ｃｍｄｌｅｔがパイプライン中でアウトｃｍｄｌｅｔに先行しない限り、ロケール情報（たとえば、日付および通貨フォーマット）がアウトｃｍｄｌｅｔ１９１０によって処理される。この状況において、変換ｃｍｄｌｅｔは、ロケール情報を処理した。

各ホストは、ｏｕｔ／ｃｏｎｓｏｌｅなど、特定のアウトｃｍｄｌｅｔのサポートを担当する。ホストは、どの宛先固有ホストｃｍｄｌｅｔ（たとえば、表計算アプリケーションによって提供されるチャートに出力を向けるｏｕｔ／ｃｈａｒｔ）もサポートする。さらに、ホストは、結果のデフォルト操作の提供を担当する。このシーケンス中のアウトｃｍｄｌｅｔは、他の出力処理ｃｍｄｌｅｔ（形式／マークアップ／変換／変形など）をコールすることによって、その行動の実装を決定し得る。したがって、アウトｃｍｄｌｅｔは、シーケンス１９０１を他のシーケンスのいずれにも暗黙的に変更することもでき、それ自体の追加形式／出力ｃｍｄｌｅｔを追加することもできる。

第２のシーケンス１９０２は、アウトｃｍｄｌｅｔ１９１０の前にフォーマットｃｍｄｌｅｔ１９２０を示す。このシーケンスに対して、フォーマットｃｍｄｌｅｔ１９２０は、パイプライン中の他のｃｍｄｌｅｔによって生成され処理されたパイプラインオブジェクトのストリームを受諾する。概して、フォーマットｃｍｄｌｅｔ１９２０は、表示プロパティを選択するための方式と、ページレイアウト、たとえば形状、列の幅、ヘッダー、フッターなどを指定するための方式とを提供する。形状は、テーブル、ワイドリスト、縦書きリストなどを含み得る。さらに、フォーマットｃｍｄｌｅｔ１９２０は、総計または合計の計算を含み得る。フォーマットｃｍｄｌｅｔ１９２０によって実施される例示的な処理が、後で図２０とともに説明される。簡潔には、フォーマットｃｍｄｌｅｔは、パイプラインオブジェクトの送出に加えて、フォーマットオブジェクトを送出する。フォーマットオブジェクトは、拡張タイプマネージャまたは他の機構を介してアウトｃｍｄｌｅｔ（たとえば、シーケンス１９０２中のアウトｃｍｄｌｅｔ１９２０）によって、ダウンストリームと認識され得る。アウトｃｍｄｌｅｔ１９２０は、発せられるフォーマットオブジェクトの使用を選ぶこともでき、こうしたオブジェクトの無視を選ぶこともできる。アウトｃｍｄｌｅｔは、表示情報において指定されたページレイアウトデータに基づいて、ページレイアウトを決定する。特定の例において、ページレイアウトに対する修正は、アウトｃｍｄｌｅｔによって指定され得る。例示的な一プロセスにおいて、アウトｃｍｄｌｅｔは、所定のいくつかのオブジェクトの各プロパティに対する最大長（たとえば５０）を見つけることによって未指定の列幅を判定し、列幅を最大長に設定することができる。フォーマットオブジェクトは、フォーマット情報、ヘッダー／フッター情報などを含む。

第３のシーケンス１９０３は、アウトｃｍｄｌｅｔ１９１０の前にフォーマットｃｍｄｌｅｔ１９２０を示す。ただし、第３のシーケンス１９０３において、マークアップｃｍｄｌｅｔ１９３０が、フォーマットｃｍｄｌｅｔ１９２０とアウトｃｍｄｌｅｔ１９１０の間にパイプライン処理される。マークアップｃｍｄｌｅｔ１９３０は、選択されたパラメータにプロパティ注釈（たとえば、フォント、色）を追加する機構を提供する。したがって、マークアップｃｍｄｌｅｔ１９３０は、出力ｃｍｄｌｅｔ１９１０の前に現れる。プロパティ注釈は、「プロパティバッグに影をつける」を用いて、またはプロパティバッグ中のカスタム名前空間中のプロパティ注釈を追加することによって実装され得る。マークアップｃｍｄｌｅｔ１９３０は、フォーマットｃｍｄｌｅｔ１９２０の処理の間、マークアップ注釈が維持され得る限り、フォーマットｃｍｄｌｅｔ１９２０の前に現れ得る。

第４のシーケンス１９０４もやはり、アウトｃｍｄｌｅｔ１９１０の前にフォーマットｃｍｄｌｅｔ１９２０を示す。ただし、第４のシーケンス１９０４において、変換ｃｍｄｌｅｔ１９４０が、フォーマットｃｍｄｌｅｔ１９２０とアウトｃｍｄｌｅｔ１９１０の間にパイプライン処理される。変換ｃｍｄｌｅｔ１９４０も、フォーマットｃｍｄｌｅｔ１９２０によって発せられるフォーマットオブジェクトを処理するように構成される。変換ｃｍｄｌｅｔ１９４０は、フォーマットオブジェクトに基づいて、パイプラインオブジェクトを固有エンコーディングに変換する。変換ｃｍｄｌｅｔ１９４０は、固有エンコーディングに関連づけられる。たとえば、パイプラインオブジェクトをアクティブディレクトリオブジェクト（ＡＤＯ）に変換する変換ｃｍｄｌｅｔ１９４０は、コマンドライン上で「ｃｏｎｖｅｒｔ／ＡＤＯ」として宣言され得る。同様に、パイプラインオブジェクトを、コンマで区切られた値（ｃｏｍｍａ ｓｅｐａｒａｔｅ ｖａｌｕｅ、ｃｓｖ）に変換する変換ｃｍｄｌｅｔ１９４０は、コマンドライン上で「ｃｏｎｖｅｒｔ／ｃｓｖ」として宣言され得る。変換ｃｍｄｌｅｔ１９４０のいくつか（たとえば、ｃｏｎｖｅｒｔ／ＸＭＬおよびｃｏｎｖｅｒｔ／ｈｔｍｌ）はブロッキングコマンドでよく、すなわち、変換を実行する前にパイプラインオブジェクトすべてが受け取られる。通常、アウトｃｍｄｌｅｔ１９２０は、フォーマットオブジェクトによって提供されるフォーマット情報を使うかどうか、判定することができる。ただし、変換ｃｍｄｌｅｔ１９２０がアウトｃｍｄｌｅｔ１９２０の前に現れる場合、アウトｃｍｄｌｅｔがオブジェクトを受け取る前に実際のデータ変換が既に起こっている。したがって、この状況において、アウトｃｍｄｌｅｔは、変換を無視することができない。

第５のシーケンス１９０５は、フォーマットｃｍｄｌｅｔ１９２０、マークアップｃｍｄｌｅｔ１９３０、変換ｃｍｄｌｅｔ１９４０、およびアウトｃｍｄｌｅｔ１９１０をこの順序で示す。したがって、この順序は、マークアップｃｍｄｌｅｔ１９３０が変換ｃｍｄｌｅｔ１９４０の前に現れ得ることを示す。

第６のシーケンス１９０６は、フォーマットｃｍｄｌｅｔ１９２０、固有の変換ｃｍｄｌｅｔ（たとえば、ｃｏｎｖｅｒｔ／ｘｍｌ ｃｍｄｌｅｔ１９４０’）、固有の変形ｃｍｄｌｅｔ（たとえば、ｔｒａｎｓｆｏｒｍ／ｘｓｌｔ ｃｍｄｌｅｔ１９５０）、およびアウトｃｍｄｌｅｔ１９１０を示す。ｃｏｎｖｅｒｔ／ＸＭＬ ｃｍｄｌｅｔ１９４０’は、パイプラインオブジェクトを、拡張マークアップ言語（ＸＭＬ）に変換する。ｔｒａｎｓｆｏｒｍ／ｘｓｌｔ ｃｍｄｌｅｔ１９５０は、拡張スタイル言語（ＸＳＬ）スタイルシートを使って、ＸＭＬドキュメントを別のＸＭＬドキュメントに変形する。変形プロセスは一般に、拡張スタイル言語変換（ＸＳＬＴ）と呼ばれ、ＸＳＬＴにおいて、ＸＳＬプロセッサは、ＸＭＬドキュメントを読み、ＸＳＬスタイルシート中の命令に従って、新規ＸＭＬドキュメントを作成する。

第７のシーケンス１９０７は、フォーマットｃｍｄｌｅｔ１９２０、マークアップｃｍｄｌｅｔ１９３０、固有の変換ｃｍｄｌｅｔ（たとえば、ｃｏｎｖｅｒｔ／ｘｍｌ ｃｍｄｌｅｔ１９４０’）、固有の変形ｃｍｄｌｅｔ（たとえば、ｔｒａｎｓｆｏｒｍ／ｘｓｌｔ ｃｍｄｌｅｔ１９５０）、およびアウトｃｍｄｌｅｔ１９１０を示す。したがって、第７のシーケンス１９０７は、変換ｃｍｄｌｅｔおよび変形ｃｍｄｌｅｔの上流にあるマークアップｃｍｄｌｅｔ１９３０を有することを示す。

図２０は、フォーマットｃｍｄｌｅｔによって実施される例示的な処理２０００を示す。フォーマットプロセスは、フォーマットｃｍｄｌｅｔが、上述されたやり方でパーサおよびパイプラインプロセッサによって解析され呼び出された後、ブロック２００１で始まる。処理は、ブロック２００２で継続する。

ブロック２００２で、パイプラインオブジェクトが、フォーマットｃｍｄｌｅｔへの入力として受け取られる。処理は、ブロック２００４で継続する。

ブロック２００４で、パイプラインオブジェクトのタイプを識別するためのクエリが開始される。このクエリは、図１８とともに上述されたように、拡張タイプマネージャによって実施される。拡張タイプマネージャがオブジェクトのタイプを識別すると、処理は、ブロック２００６で継続する。

ブロック２００６で、識別されたタイプが表示情報中でルックアップされる。表示情報の例示的な形式は、図２１に示され、後で説明される。処理は、判断ブロック２００８で継続する。

判断ブロック２００８で、識別されたタイプが、表示情報中で指定されているかどうか、判定が行われる。表示情報中に識別されたタイプのエントリがない場合、処理は完了する。エントリがある場合、処理は、ブロック２０１０で継続する。

ブロック２０１０で、識別されたタイプに関連づけられたフォーマット情報が、表示情報から入手される。処理は、ブロック２０１２で継続する。

ブロック２０１２で、パイプライン上で情報が発せられる。情報が発せられると、処理は完了する。

発せられ得る例示的な情報が、次にさらに詳しく説明される。情報は、フォーマット情報、ヘッダー／フッター情報、およびグループ終了／開始信号オブジェクトを含み得る。フォーマット情報は、形状、ラベル、番号づけ／点打ち、列の幅、キャラクタエンコードタイプ、内容フォントプロパティ、ページの長さ、プロパティ名によるグループ化などを含み得る。こうした情報はそれぞれ、関連づけられた追加仕様を有し得る。たとえば、形状は、形状が、テーブル、リストなどであるかを指定し得る。ラベルは、列ヘッダー、リストラベルなどを使うかどうかを指定し得る。キャラクタエンコードは、アスキー、ＵＴＦ−８、Ｕｎｉｃｏｄｅなどを指定し得る。内容フォントプロパティは、表示されるプロパティ値に適用されるフォントを指定し得る。デフォルトフォントプロパティ（たとえば、Ｃｏｕｒｉｅｒ Ｎｅｗ、１０ポイント）は、内容フォントプロパティが指定されていない場合に使われ得る。

ヘッダー／フッター情報は、ヘッダー／フッタースコープ、フォントプロパティ、タイトル、サブタイトル、日付、時刻、ページ番号、分離記号などを含み得る。たとえば、スコープは、ドキュメント、ページ、グループなどを指定し得る。追加プロパティは、ヘッダーまたはフッターのどちらかに対して指定され得る。たとえば、グループおよびドキュメントのフッター用に、追加プロパティは、合計／総計を計算するためのプロパティまたは列、オブジェクトカウント、総計およびカウント用ラベル文字列などを含み得る。

グループ終了／開始信号オブジェクトは、フォーマットｃｍｄｌｅｔが、グループ化プロパティ(group-by property)が変わったことを検出したときに発せられる。これが起こると、フォーマットｃｍｄｌｅｔは、パイプラインオブジェクトのストリームを、予めソートされたものとして扱い、ソートし直さない。グループ終了／開始信号オブジェクトは、パイプラインオブジェクトとともに点在され得る。ネスト式ソート用に複数のグループ化プロパティが指定され得る。フォーマットｃｍｄｌｅｔは、最終合計および総計を含む形式終了オブジェクトを送出することもできる。

手短に図２１に移ると、例示的な表示情報２１００は、構造化形式であり、定義されている各オブジェクトに関連づけられた情報（たとえば、フォーマット情報、ヘッダー／フッター情報、グループ化プロパティまたはメソッド）を含む。たとえば、表示情報２１００は、ＸＭＬベースでよい。上述されたプロパティはそれぞれ、次いで、表示情報中で指定され得る。表示情報２１００中の情報は、入力されているオブジェクトタイプの所有者によって投入され得る。動作環境は、所有者が、エントリを作成し、消去し、修正することによって表示情報をアップデートすることを可能にする特定のＡＰＩおよびｃｍｄｌｅｔを提供する。

図２２は、特定のフォーマットｃｍｄｌｅｔ（たとえば、ｆｏｒｍａｔ／ｔａｂｌｅ、ｆｏｒｍａｔ／ｌｉｓｔ、およびｆｏｒｍａｔ／ｗｉｄｅ）、マークアップｃｍｄｌｅｔ（たとえば、ａｄｄ／ｍａｒｋｕｐ）、変換ｃｍｄｌｅｔ（たとえば、ｃｏｎｖｅｒｔ／ｔｅｘｔ、ｃｏｎｖｅｒｔ／ｓｖ、ｃｏｎｖｅｒｔ／ｃｓｖ、ｃｏｎｖｅｒｔ／ＡＤＯ、ｃｏｎｖｅｒｔ／ＸＭＬ、ｃｏｎｖｅｒｔ／ｈｔｍｌ）、変形ｃｍｄｌｅｔ（たとえば、ｔｒａｎｓｆｏｒｍ／ＸＳＬＴ）、ならびにアウトｃｍｄｌｅｔ（たとえば、ｏｕｔ／ｃｏｎｓｏｌｅ、ｏｕｔ／ｆｉｌｅ）用の例示的なシンタクス２２０１〜２２１３を列挙するテーブルである。図２３は、出力処理ｃｍｄｌｅｔ（たとえば、フォーマットｃｍｄｌｅｔ、変換ｃｍｄｌｅｔ、およびマークアップｃｍｄｌｅｔ）の様々なパイプラインシーケンスを用いて、ｏｕｔ／ｃｏｎｓｏｌｅ ｃｍｄｌｅｔによってレンダリングされる結果を示す。

本管理用ツールフレームワークは、どのホストからもタスクを開始させる（たとえば、ユーザインターフェイス、コマンドライン、プログラムに従って）ので、システム管理者および製品開発者は、コードおよび経験を共有することができ、このことは、両方のタイプのユーザの効果および効率を向上させる。さらに、システム管理者は、１組のコンセプト、コマンド、トラブルシューティング技術を学習する必要があるだけである。同様に、製品開発者は、管理ツールすべてを利用するのに１つのプロバイダｃｍｄｌｅｔを作成する必要があるだけである。

したがって、説明されたように、本管理用ツールフレームワークは、管理オブジェクトへのアクセスおよびその制御を簡素化し、透過性のあるリモーティングを提供するので、本管理用ツールフレームワークは、管理用ツールを開発するのに要求される能力レベルを低下させる。さらに、本フレームワークは、開発者が、開発者がフレームワークを学習するのを助けるＧＵＩ対話によって実行されるスクリプトを見ること、および独自の自動化されたスクリプトを作成することを可能にする。さらに、フレームワークによって提供される機能においてテストが既に実施されているので、製品レベルのテストは、フレームワークによって提供される関数を呼び出すためのＧＵＩパスのテストのみに削減される。別の利益は、管理ＧＵＩが、その内部動作を、ｃｍｄｌｅｔを介して公開し得ることであり、この公開は、開発者およびテスト実施者に、内部状態への容易なアクセス、およびデバッグ／診断／テスト自動化のためのＧＵＩの制御を提供する。

具体的な実装形態および実施形態の詳細が上述されたが、このような詳細は、添付の特許請求の範囲を限定することではなく、法定の開示義務を満たすことを意図する。したがって、特許請求の範囲によって定義される本発明は、上述された具体的な特徴に限定されない。そうではなく、本発明は、適正な添付の特許請求の範囲内である形または修正形態のいずれにおいても権利請求され、均等論に従って適切に解釈される。

例示的な管理用ツール環境を使用し得る、例示的なコンピューティングデバイスを示す図である。 本管理用ツール環境のための例示的な管理用ツールフレームワークの概観を全体的に示すブロック図である。 図２に示される管理用ツールフレームワークのホスト固有コンポーネント内部のコンポーネントを示すブロック図である。 図２に示される管理用ツールフレームワークのコアエンジンコンポーネント内部のコンポーネントを示すブロック図である。 図２に示される管理用ツールフレームワークでの使用に適したｃｍｄｌｅｔを指定する例示的な一データ構造を示す図である。 図５に示されるｃｍｄｌｅｔが派生されるコマンド基本タイプを指定する例示的なデータ構造を示す図である。 図２に示される管理用ツールフレームワークでの使用に適したｃｍｄｌｅｔを指定する別の例示的なデータ構造を示す図である。 図２に示される管理用ツールフレームワーク内部で実施されるホスト処理のための例示的なプロセスを示す論理フロー図である。 図２に示される管理用ツールフレームワーク内部で実施される入力操作のための例示的なプロセスを示す論理フロー図である。 図９に示される入力操作プロセスでの使用に適したスクリプトを処理するプロセスを示す論理フロー図である。 図１０に示されるスクリプト処理プロセスでの使用に適したスクリプト前処理プロセスを示す論理フロー図である。 図１０に示されるスクリプト処理プロセスでの使用に適した、制約を課すプロセスを示す論理フロー図である。 図２に示される管理用ツールフレームワークにおけるコマンド文字列の処理を示す機能フロー図である。 図９に示される入力を操作するプロセスでの使用に適した、コマンド文字列を処理するプロセスを示す論理フロー図である。 図１４に示されるコマンド文字列処理での使用に適した、ｃｍｄｌｅｔのインスタンスを作成する例示的なプロセスを示す論理フロー図である。 図１４に示されるコマンド処理での使用に適した、ｃｍｄｌｅｔのプロパティに投入を行う例示的なプロセスを示す論理フロー図である。 図１４に示されるコマンド処理での使用に適した、ｃｍｄｌｅｔを実行する例示的なプロセスを示す論理フロー図である。 図２に示される管理用ツールフレームワークでの使用に適した例示的な拡張タイプマネージャを示す機能ブロック図である。 パイプライン中の出力処理ｃｍｄｌｅｔの例示的なシーケンスを示す図である。 図１９に示される出力処理ｃｍｄｌｅｔの１つによって実施される例示的な処理を示す図である。 図２０の処理中にアクセスされる表示情報の例示的な構造を示す図である。 例示的な出力処理ｃｍｄｌｅｔ用の例示的なシンタクスを列挙するテーブルを示す図である。 出力処理ｃｍｄｌｅｔの様々なパイプラインシーケンスを用いて、ｏｕｔ／ｃｏｎｓｏｌｅ ｃｍｄｌｅｔによってレンダリングされる結果を示す図である。

Claims (30)

1. 管理タスクを自動化するフレームワークを提供するコンピュータ実行可能命令を有する少なくとも１つのコンピュータ可読媒体であって、前記フレームワークは、
   入力を解析し、前記入力に基づいて少なくとも１つのｃｍｄｌｅｔを識別するように構成されたパーサコンポーネントと、
   入力ソースからの情報を用いて前記ｃｍｄｌｅｔに関連するパラメータを投入し、前記ｃｍｄｌｅｔを実行して、精密解析可能なストリームを生成するように構成されたエンジンコンポーネントであって、前記入力ソースは、別のｃｍｄｌｅｔから発せられた、精密解析可能なストリームを含むエンジンコンポーネントと
   を備えることを特徴とするコンピュータ可読媒体。
2. 少なくとも１つのコマンドについての前記入力を供給するように構成されたホストコンポーネントをさらに備えることを特徴とする請求項１に記載のコンピュータ可読媒体。
3. 前記ホストコンポーネントは、前記パーサコンポーネントに前記入力直接供給することを特徴とする請求項２に記載のコンピュータ可読媒体。
4. 前記ホストコンポーネントは、前記エンジンコンポーネント内部で前記ｃｍｄｌｅｔの１つとして処理されるホストｃｍｄｌｅｔを使って、前記入力を供給することを特徴とする請求項２に記載のコンピュータ可読媒体。
5. 前記ｃｍｄｌｅｔは、複数のデータ型に対して作用する共通ユーティリティを提供する基本ｃｍｄｌｅｔを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
6. 前記ｃｍｄｌｅｔは、システムユーティリティを提供するホストｃｍｄｌｅｔを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
7. 前記ｃｍｄｌｅｔに関連づけられた前記パラメータは、前記ｃｍｄｌｅｔ中の前記パラメータ用のパラメータ宣言を含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
8. 前記ｃｍｄｌｅｔに関連づけられた前記パラメータは、前記パラメータを定義する外部ソースへの参照を含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
9. 前記ｃｍｄｌｅｔは、アプリケーションに関連づけられた機能を提供するプロバイダｃｍｄｌｅｔを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
10. 命令を含む少なくとも１つのコンピュータ可読媒体であって、前記命令は、１つまたは複数のコンピュータによって実行されると、
    入力を受け取ること、
    予想される少なくとも１つの入力パラメータを識別するｃｍｄｌｅｔを前記入力に関連づけること、
    前記入力からのデータの入手を指定する、予想される各入力パラメータごとに、前記入力からのデータを前記予想される入力パラメータに投入すること、ならびに
    入力ストリームからの情報の入手を指定する、予想される各入力パラメータごとに、前記情報を前記予想される入力パラメータに投入し、前記ｃｍｄｌｅｔを実行して、前記情報および前記データに基づいてオブジェクトストリームを生成し、前記オブジェクトストリームを送出することであって、前記入力ストリームは、別のｃｍｄｌｅｔによって発せられる前記オブジェクトストリームを含むことを実施することを特徴とするコンピュータ可読媒体。
11. 前記入力オブジェクトは、．ＮＥＴオブジェクト、ＸＭＬドキュメント、またはアクティブディレクトリオブジェクトを含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
12. 前記ｃｍｄｌｅｔおよび前記別のｃｍｄｌｅｔは、同じプロセス中で動作することを特徴とする請求項１０に記載のコンピュータ可読媒体。
13. 前記ｃｍｄｌｅｔは、ローカルプロセス中で動作し、前記別のｃｍｄｌｅｔは、リモートプロセス中で動作することを特徴とする請求項１０に記載のコンピュータ可読媒体。
14. 前記入力は、文字列を含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
15. 前記入力は、スクリプトを含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
16. 管理タスクを自動化する管理用ツールフレームワークを提供するシステムであって、
    プロセッサと、
    メモリとを備え、前記メモリは、前記プロセッサによる実行のために前記メモリにロードされる複数のコンピュータ実行可能命令用に割り振られ、前記コンピュータ実行可能命令は、管理タスクを自動化する方法を提供し、前記方法は、
    少なくとも１つのコマンドについての入力を受け取ること、
    前記入力を解析して１つのｃｍｄｌｅｔを解析すること、
    前記ｃｍｄｌｅｔ中で定義されたパラメータに入力ソースからの情報を投入すること、
    前記ｃｍｄｌｅｔを実行して、オブジェクトストリームを生成すること、および
    前記オブジェクトストリームを出力することを含むことを特徴とするシステム。
17. 前記入力ソースは、別のｃｍｄｌｅｔによって生成された前記オブジェクトストリームを含むことを特徴とする請求項１６に記載のシステム。
18. コンピューティングデバイス上で動作するように構成された管理用フレームワークであって、
    入力を受け取る手段と、
    前記入力を少なくとも１つのｃｍｄｌｅｔに解析する手段であって、前記ｃｍｄｌｅｔは、入力ソースに関連づけられた、予想される少なくとも１つの入力パラメータを記述する手段を提供する手段と、
    予想される各入力パラメータを投入する手段と、
    前記入力ソースが、別のｃｍｄｌｅｔによって生成された出力ストリームを含むようなやり方で前記ｃｍｄｌｅｔを処理する手段と
    を備えることを特徴とする管理用フレームワーク。
19. 前記１つのｃｍｄｌｅｔおよび前記別のｃｍｄｌｅｔは、同じプロセス中で実行されることを特徴とする請求項１８に記載の管理用フレームワーク。
20. 前記オブジェクトストリームは、．ＮＥＴオブジェクトを含むことを特徴とする請求項１８に記載の管理用フレームワーク。
21. 前記ｃｍｄｌｅｔを処理することは、予想される少なくとも１つの入力プロパティに、前記オブジェクトストリームから取得された情報を投入することを含むことを特徴とする請求項１８に記載の管理用フレームワーク。
22. 前記少なくとも１つのｃｍｄｌｅｔは、前記管理用フレームワークによって提供される基本ｃｍｄｌｅｔを含むことを特徴とする請求項１８に記載の管理用フレームワーク。
23. 前記少なくとも１つのｃｍｄｌｅｔは、サードパーティ開発者によって提供されるサードパーティｃｍｄｌｅｔを含むことを特徴とする請求項１８に記載の管理用フレームワーク。
24. リモートコンピューティングデバイス上の前記ｃｍｄｌｅｔにアクセスする手段をさらに提供することを特徴とする請求項１８に記載の管理用フレームワーク。
25. 命令を含むコンピュータ可読媒体であって、前記命令は、コンピュータによって実行されると、
    ユーザ入力の受諾、
    管理用ツールフレームワークによって認識される入力形式へのユーザ入力の変換、および
    前記管理用ツールフレームワークへの前記入力形式の転送を実施し、前記管理用ツールフレームワークは、
    前記入力形式を解析し、
    予想される入力パラメータを指定するｃｍｄｌｅｔを、前記入力に基づいてインスタンス化し、
    入力ソースから前記予想される入力パラメータに投入するように構成されることを特徴とするコンピュータ可読媒体。
26. 前記入力ソースは、前記入力形式を含むことを特徴とする請求項２５に記載のコンピュータ可読媒体。
27. 前記入力ソースは、別のｃｍｄｌｅｔから発せられた入力ストリームを含むことを特徴とする請求項２５に記載のコンピュータ可読媒体。
28. ホストアプリケーションと前記管理用ツールフレームワークの間のインターフェイスを提供するホストｃｍｄｌｅｔの提供をさらに含むことを特徴とする請求項２５に記載のコンピュータ可読媒体。
29. 前記ユーザ入力は、音声入力を含むことを特徴とする請求項２５に記載のコンピュータ可読媒体。
30. 前記ユーザ入力は、コマンドライン上で入力されるコマンド文字列を含むことを特徴とする請求項２５に記載のコンピュータ可読媒体。
    

Images