JP2007509407A - コマンドライン命令への拡張機能を提供する機構 - Google Patents
コマンドライン命令への拡張機能を提供する機構 Download PDFInfo
- Publication number
- JP2007509407A JP2007509407A JP2006536563A JP2006536563A JP2007509407A JP 2007509407 A JP2007509407 A JP 2007509407A JP 2006536563 A JP2006536563 A JP 2006536563A JP 2006536563 A JP2006536563 A JP 2006536563A JP 2007509407 A JP2007509407 A JP 2007509407A
- Authority
- JP
- Japan
- Prior art keywords
- command
- cmdlet
- computer
- input
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2105—Dual mode as a secondary aspect
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2149—Restricted operating environment
Abstract
本機構は、コマンドライン動作環境においてコマンドラインで入力されるコマンドに、第1の実行モードまたは代替実行モードで実行する能力を与える。コマンドは、代替実行モードで実行する命令を含む場合、代替実行モードで実行される。代替実行モードは、動作環境によって提供され、コマンドに拡張機能を提供する。代替実行モードは、コマンドの実行結果を視覚表示し、コマンドの実行をシミュレートした結果を視覚表示し、コマンドの実行前に検証を促し、実行を要求しているユーザが、コマンドを実行するのに十分な特権をもっているかどうか判定するためにセキュリティチェックを実施することなどができる。
Description
本明細書において開示される主題は、コマンドライン環境に関し、より詳細には、コマンドライン環境におけるコマンドの処理に関する。
コマンドライン環境において、コマンドラインインターフェイスは、コマンドを入れることによって、ユーザにタスクを直接実施させる。たとえば、プロンプト(たとえば、「C:¥>」)を表示するウィンドウを提供するコマンドラインインターフェイスが呼び出され得る。ユーザは、コマンドを実施するために、プロンプトで「dir」などのコマンドをタイプ入力することができる。いくつかのコマンドが、より複雑なタスクを実施するために一緒にパイプライン処理され得る。こうしたパイプライン化されるコマンドが非常に複雑なコマンドライン命令をもつことは一般的である。
コマンドラインインターフェイスに伴う1つの欠点は、有用な情報がコマンドラインインターフェイスによって示されないので、ユーザが、入力する正確なコマンドライン命令を知らなければならないことである。コマンドライン命令の1つに対して、タイプミスなどの不注意によるエラーが入力された場合、タスクは、ユーザの期待に沿わない方法で実施され得る。
したがって、コマンドライン命令を入力するユーザを補助する機構が必要である。
本機構は、コマンドライン動作環境においてコマンドラインで入力されるコマンドに、第1の実行モードまたは代替実行モードで実行する能力を与える。コマンドは、代替実行モードで実行する命令を含む場合、代替実行モードで実行される。代替実行モードは、動作環境によって提供され、コマンドに拡張機能を提供する。代替実行モードは、コマンドの実行結果を視覚表示し、コマンドの実行をシミュレートした結果を視覚表示し、コマンドの実行前に検証を促し、実行を要求しているユーザが、コマンドを実行するのに十分な特権をもっているかどうか判定するためにセキュリティチェックを実施することなどができる。したがって、動作環境によって提供される拡張機能は、コマンドライン命令を入力するユーザを補助するが、開発者がコマンド中に拡張コードを書くことを要求しない。
簡潔に述べると、本機構は、コマンドライン命令への拡張機能を提供し、コマンドライン命令を入力するユーザを補助する。本機構は、望まれる拡張機能を指定するコマンドライン文法を提供する。拡張機能は、実行前の命令の確認を可能にし、実行される命令の視覚表現をもたらし、シミュレートされた命令の視覚表現をもたらし、または命令を実行する前に特権を検証することができる。コマンドライン文法は、他の機能を提供するように拡張され得る。
以下の説明は、本機構が作用する、具体的、例示的な管理用ツール環境を述べる。他の例示的な環境は、コマンドライン命令を入力するユーザを補助することを目指す、この具体的な実施形態の特徴および/または他の特徴を含み得る。
以下の詳細な説明は、いくつかのセクションに分けられる。第1のセクションは、管理用ツール環境が動作し得る例示的な計算機環境について述べる。第2のセクションは、管理用ツール環境のための例示的なフレームワークについて述べる。それ以降のセクションは、例示的なフレームワークの個々のコンポーネントおよびこうしたコンポーネントの動作について述べる。たとえば、「cmdletを実行する例示的なプロセス」に関するセクションは、図6とともに、コマンドライン命令に拡張機能を提供する例示的な機構を説明する。
(例示的な計算機環境)
図1は、例示的な管理用ツール環境において使用され得る、例示的なコンピューティングデバイスを示す。ごく基本的な構成において、コンピューティングデバイス100は通常、少なくとも1つの処理ユニット102およびシステムメモリ104を含む。コンピューティングデバイスの正確な構成およびタイプによると、システムメモリ104は、揮発性(たとえばRAM)でも、不揮発性(たとえばROM、フラッシュメモリなど)でも、この2つの何らかの組合せでもよい。システムメモリ104は通常、オペレーティングシステム105、1つまたは複数のプログラムモジュール106を含み、プログラムデータ107を含み得る。オペレーティングシステム105は、コンポーネント(プロパティおよびイベントを含む)、オブジェクト、継承、多相性、リフレクションをサポートする、コンポーネントベースのフレームワーク120を含み、ワシントン州レドモンドのマイクロソフトコーポレーションによって作成された.NET(商標)フレームワークのAPIなど、オブジェクト指向コンポーネントに基づくアプリケーションプログラミングインターフェイス(API)を提供する。オペレーティングシステム105は、管理用ツール(図示せず)の開発をサポートするためにコンポーネントベースのフレームワーク120と対話する管理用ツールフレームワーク200も含む。この基本構成が、破線108内の構成要素によって図1に示される。
図1は、例示的な管理用ツール環境において使用され得る、例示的なコンピューティングデバイスを示す。ごく基本的な構成において、コンピューティングデバイス100は通常、少なくとも1つの処理ユニット102およびシステムメモリ104を含む。コンピューティングデバイスの正確な構成およびタイプによると、システムメモリ104は、揮発性(たとえばRAM)でも、不揮発性(たとえばROM、フラッシュメモリなど)でも、この2つの何らかの組合せでもよい。システムメモリ104は通常、オペレーティングシステム105、1つまたは複数のプログラムモジュール106を含み、プログラムデータ107を含み得る。オペレーティングシステム105は、コンポーネント(プロパティおよびイベントを含む)、オブジェクト、継承、多相性、リフレクションをサポートする、コンポーネントベースのフレームワーク120を含み、ワシントン州レドモンドのマイクロソフトコーポレーションによって作成された.NET(商標)フレームワークのAPIなど、オブジェクト指向コンポーネントに基づくアプリケーションプログラミングインターフェイス(API)を提供する。オペレーティングシステム105は、管理用ツール(図示せず)の開発をサポートするためにコンポーネントベースのフレームワーク120と対話する管理用ツールフレームワーク200も含む。この基本構成が、破線108内の構成要素によって図1に示される。
コンピューティングデバイス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は、例示的な管理用ツールフレームワーク200の概観を全体的に示すブロック図である。管理用ツールフレームワーク200は、1つまたは複数のホストコンポーネント202、ホスト固有コンポーネント204、ホスト非依存コンポーネント206、およびハンドラコンポーネント208を含む。ホスト非依存コンポーネント206は、他のコンポーネントそれぞれ(すなわち、ホストコンポーネント202、ホスト固有コンポーネント204、およびハンドラコンポーネント208)と通信することができる。こうしたコンポーネントはそれぞれ、後で簡潔に説明され、必要に応じて、以降のセクションでさらに詳しく説明される。
図2は、例示的な管理用ツールフレームワーク200の概観を全体的に示すブロック図である。管理用ツールフレームワーク200は、1つまたは複数のホストコンポーネント202、ホスト固有コンポーネント204、ホスト非依存コンポーネント206、およびハンドラコンポーネント208を含む。ホスト非依存コンポーネント206は、他のコンポーネントそれぞれ(すなわち、ホストコンポーネント202、ホスト固有コンポーネント204、およびハンドラコンポーネント208)と通信することができる。こうしたコンポーネントはそれぞれ、後で簡潔に説明され、必要に応じて、以降のセクションでさらに詳しく説明される。
(ホストコンポーネント)
ホストコンポーネント202は、ユーザまたは他のプログラムに、関連するアプリケーション用の自動化特徴を公開する1つまたは複数のホストプログラム(たとえば、ホストプログラム210〜214)を含む。各ホストプログラム210〜214は、その独自のスタイルで、たとえば、コマンドライン、グラフィカルユーザインターフェイス(GUI)、音声認識インターフェイス、アプリケーションプログラミングインターフェイス(API)、スクリプト言語、ウェブサービスなどを介して、こうした自動化特徴を公開することができる。ただし、ホストプログラム210〜214はそれぞれ、管理用ツールフレームワークによって提供される機構を介して、1つまたは複数の自動化特徴を公開する。
ホストコンポーネント202は、ユーザまたは他のプログラムに、関連するアプリケーション用の自動化特徴を公開する1つまたは複数のホストプログラム(たとえば、ホストプログラム210〜214)を含む。各ホストプログラム210〜214は、その独自のスタイルで、たとえば、コマンドライン、グラフィカルユーザインターフェイス(GUI)、音声認識インターフェイス、アプリケーションプログラミングインターフェイス(API)、スクリプト言語、ウェブサービスなどを介して、こうした自動化特徴を公開することができる。ただし、ホストプログラム210〜214はそれぞれ、管理用ツールフレームワークによって提供される機構を介して、1つまたは複数の自動化特徴を公開する。
この例では、機構は、関連するホストプログラム210〜214のユーザに対して管理用ツールの機能を明らかにするのに、cmdletを用いる。さらに、機構は、ホストによって利用可能にされる1組のインターフェイスを用いて、対応するホストプログラム210〜214に関連するアプリケーションに、管理用ツール環境を組み込む。以下の説明を通して、「cmdlet」という用語は、図2〜23を参照して説明される例示的な管理用ツール環境において使われるコマンドを指すのに用いられる。
cmdletは、従来の管理環境におけるコマンドに対応する。しかし、cmdletは、こうした従来のコマンドとは大きく異なる。たとえば、cmdletは通常、それに相対するコマンドよりもサイズが小さい。というのは、cmdletは、たとえば解析、データ認証、エラー報告など、管理用ツールフレームワークによって提供される共通機能を利用し得るからである。このような共通機能は、一度だけ実装され、一度だけテストされればよいので、管理用ツールフレームワーク全体に及ぶcmdletの使用は、アプリケーション固有機能に関連するインクリメンタル開発およびテストのコストを、従来の環境に比べてかなり低くさせる。
さらに、従来の環境とは対照的に、cmdletは、スタンドアロン型の実行可能プログラムでなくてよい。そうではなく、cmdletは、管理用ツールフレームワーク内部の同じプロセス中で実行され得る。このことは、cmdletが、互いの間で「ライブ」オブジェクトを交換することを可能にする。「ライブ」オブジェクトを交換するこの機能は、cmdletが、こうしたオブジェクトにおいてメソッドを直接呼び出すことを可能にする。cmdletの作成および使用の詳細は、後でさらに詳しく説明される。
概して、各ホストプログラム210〜214は、管理用ツールフレームワーク内部で、ユーザと他のコンポーネントの間の対話を管理する。こうした対話は、パラメータを求めるプロンプト、エラーの報告などを含み得る。通常、各ホストプログラム210〜214は、独自の具体的なホストcmdlet(たとえば、ホストcmdlet218)の組を提供することができる。たとえば、ホストプログラムがeメールプログラムの場合、ホストプログラムは、メールボックスおよびメッセージと対話するホストcmdletを提供することができる。図2は、ホストプログラム210〜214を示すが、ホストコンポーネント202は、既存または新規作成アプリケーションに関連する他のホストプログラムを含み得ることを当業者は理解するであろう。こうした他のホストプログラムは、それと関連するアプリケーションに、管理用ツール環境によって提供される機能も組み込む。ホストプログラムによって提供される処理は、後で図8とともに詳しく説明される。
図2に示される例において、ホストプログラムは、コンピューティングデバイスのハードウェア、ソフトウェア、およびネットワークコンポーネントを管理する管理用ツールをユーザが作成し、保存し、開くための、シンプルで一貫性がある管理ユーザインターフェイスを提供する管理コンソール(すなわち、ホストプログラム210)でよい。こうした機能を遂行するために、ホストプログラム210は、管理用ツールフレームワークの上に管理GUIを構築する1組のサービスを提供する。GUIとの対話は、管理用ツール環境によって提供されるスクリプト作成能力をユーザに教えるのを補助する、ユーザが見ることのできるスクリプトとして公開されることもできる。
別の例では、ホストプログラムは、コマンドライン対話シェル(すなわち、ホストプログラム212)でよい。コマンドライン対話シェルは、コマンドライン上でシェルメタデータ216を入力させて、コマンドラインの処理に影響を与え得る。
さらに別の例では、ホストプログラムは、複数のプラットフォーム、プログラミング言語、およびアプリケーションに及ぶ、分散コンピューティングおよび相互運用性のための業界標準仕様を用いるウェブサービス(すなわち、ホストプログラム214)でよい。
こうした例に加えて、サードパーティは、そのホストプログラムまたは他のホストプログラムとともに用いられる「サードパーティ」すなわち「プロバイダ」インターフェイスおよびプロバイダcmdletを作成することによって、独自のホストコンポーネントを追加することができる。プロバイダインターフェイスは、アプリケーションまたはインフラストラクチャが管理用ツールフレームワークによって操作され得るように、アプリケーションまたはインフラストラクチャを公開する。プロバイダcmdletは、ナビゲーション、診断、構成、ライフサイクル、動作などの自動化をもたらす。プロバイダcmdletは、全く異質な1組のデータストアに対して、多様型(polymorphic)cmdlet行動を示す。管理用ツール環境は、他のcmdletクラスと同じ優先度で、プロバイダcmdletに作用する。プロバイダcmdletは、他のcmdletと同じ機構を用いて作成される。プロバイダcmdletは、管理用ツールフレームワークに、アプリケーションまたはインフラストラクチャの詳細な機能を公開する。したがって、cmdletを使うことにより、製品開発者は、1つのホストコンポーネントを作成するだけでよく、このホストコンポーネントは次いで、製品開発者の製品を多くの管理用ツールを用いて動作させる。たとえば、例示的な管理用ツール環境を用いると、システムレベルのグラフィカルユーザインターフェイスのヘルプメニューが、既存のアプリケーションに統合され移植され得る。
(ホスト固有コンポーネント)
ホスト固有コンポーネント204は、計算機システム(たとえば、図1のコンピューティングデバイス100)が、フレームワークが実行されているプラットフォームの各部から管理用ツールフレームワークを切り離すのに用いるサービスの集合体を含む。したがって、プラットフォームの各タイプごとに、1組のホスト固有コンポーネントが存在する。ホスト固有コンポーネントは、異なるオペレーティングシステム上で同じ管理用ツールをユーザが使うことを可能にする。
ホスト固有コンポーネント204は、計算機システム(たとえば、図1のコンピューティングデバイス100)が、フレームワークが実行されているプラットフォームの各部から管理用ツールフレームワークを切り離すのに用いるサービスの集合体を含む。したがって、プラットフォームの各タイプごとに、1組のホスト固有コンポーネントが存在する。ホスト固有コンポーネントは、異なるオペレーティングシステム上で同じ管理用ツールをユーザが使うことを可能にする。
一時的に図3に移ると、ホスト固有コンポーネント204は、インテリセンス(IntelliSense)/メタデータアクセスコンポーネント302、ヘルプcmdletコンポーネント304、構成/登録コンポーネント306、cmdletセットアップコンポーネント308、および出力インターフェイスコンポーネント309を含み得る。コンポーネント302〜308は、データベースストア314に関連づけられたデータベースストアマネージャ312と通信する。パーサ220およびスクリプトエンジン222は、インテリセンス/メタデータアクセスコンポーネント302と通信する。コアエンジン224は、ヘルプcmdletコンポーネント304、構成/登録コンポーネント306、cmdletセットアップコンポーネント308、および出力インターフェイスコンポーネント309と通信する。出力インターフェイスコンポーネント309は、ホストによってアウトcmdletに提供されるインターフェイスを含む。こうしたアウトcmdletは次いで、ホストの出力オブジェクトをコールして、レンダリングを実施することができる。ホスト固有コンポーネント204は、コアエンジン224がロギングおよび監査能力をもたらすホスト固有(すなわち、プラットフォーム固有)サービスと通信するのに用いるロギング/監査コンポーネント310も含み得る。
例示的な一管理用ツールフレームワークにおいて、インテリセンス/メタデータアクセスコンポーネント302は、コマンド、パラメータ、およびパラメータ値の自動補完をもたらす。ヘルプcmdletコンポーネント304は、ホストユーザインターフェイスに基づいて、カスタマイズされたヘルプシステムを提供する。
(ハンドラコンポーネント)
図2に戻ると、ハンドラコンポーネント208は、レガシーユーティリティ230、管理cmdlet232、非管理cmdlet234、リモーティングcmdlet236、およびウェブサービスインターフェイス238を含む。管理cmdlet232(プラットフォームcmdletとも呼ばれる)は、コンピューティングデバイスに関連する構成情報を照会し、または操作するcmdletを含む。管理cmdlet232は、システムタイプ情報を操作するので、ある特定のプラットフォームに依存する。しかし、各プラットフォームは通常、他のプラットフォーム上で管理cmdlet232と同様のアクションを提供する管理cmdlet232を有する。たとえば、各プラットフォームは、システム管理属性(たとえば、get/process、set/IPAddress)を入手し設定する管理cmdlet232をサポートする。ホスト非依存コンポーネント206は、ホスト非依存コンポーネント206内で生成されたcmdletオブジェクトを介して管理cmdletと通信する。cmdletオブジェクトの例示的なデータ構造は、後で図5〜7とともに詳しく説明される。
図2に戻ると、ハンドラコンポーネント208は、レガシーユーティリティ230、管理cmdlet232、非管理cmdlet234、リモーティングcmdlet236、およびウェブサービスインターフェイス238を含む。管理cmdlet232(プラットフォームcmdletとも呼ばれる)は、コンピューティングデバイスに関連する構成情報を照会し、または操作するcmdletを含む。管理cmdlet232は、システムタイプ情報を操作するので、ある特定のプラットフォームに依存する。しかし、各プラットフォームは通常、他のプラットフォーム上で管理cmdlet232と同様のアクションを提供する管理cmdlet232を有する。たとえば、各プラットフォームは、システム管理属性(たとえば、get/process、set/IPAddress)を入手し設定する管理cmdlet232をサポートする。ホスト非依存コンポーネント206は、ホスト非依存コンポーネント206内で生成されたcmdletオブジェクトを介して管理cmdletと通信する。cmdletオブジェクトの例示的なデータ構造は、後で図5〜7とともに詳しく説明される。
非管理cmdlet234(基本cmdletと呼ばれる場合もある)は、管理cmdlet232によって提供されるオブジェクトに対して他の処理をグループ化し、ソートし、フィルタリングし、実施するcmdletを含む。非管理cmdlet234は、パイプラインオブジェクトに関連づけられたデータをフォーマットし出力するcmdletも含み得る。データ駆動コマンドライン出力をもたらす例示的な機構が、後で図19〜23とともに説明される。非管理cmdlet234は、各プラットフォームにおいて同じでよく、cmdletオブジェクトを介してホスト非依存コンポーネント206と対話する1組のユーティリティを提供し得る。非管理cmdlet234とホスト非依存コンポーネント206の間の対話は、オブジェクトのリフレクションを可能にし、その(オブジェクト)タイプに依存しない、リフレクトされたオブジェクトに対する処理を可能にする。したがって、こうしたユーティリティは、開発者が、非管理cmdletを書くと、こうした非管理cmdletを計算機システム上でサポートされる全クラスのオブジェクトに渡って適用することを可能にする。従来、開発者は、処理されるデータ形式を最初に把握し、次いで、そのデータのみを処理するようなアプリケーションを書かなければならなかった。その結果、従来のアプリケーションは、非常に限られた範囲のデータを処理することしかできなかった。オブジェクトタイプに依存しない、オブジェクトを処理する例示的な一機構が、後で図18とともに説明される。
レガシーユーティリティ230は、cmd.exeの下で実行されるwin32実行可能プログラムなど、既存の実行可能プログラムを含む。各レガシーユーティリティ230は、オブジェクトフレームワークにおいてあるタイプのオブジェクトであるテキストストリーム(すなわち、stdinおよびstdout)を使って管理用ツールフレームワークと通信する。レガシーユーティリティ230は、テキストストリームを使用するので、管理用ツールフレームワークによって提供されるリフレクションベースの動作は利用可能でない。レガシーユーティリティ230は、管理用ツールフレームワークとは異なるプロセスで実行される。図示されていないが、他のcmdletも、プロセス外部で動作することができる。
リモーティングcmdlet236は、ウェブサービスインターフェイス238と組み合わされて、インターネットやイントラネット(たとえば、図2に示されるインターネット/イントラネット240)などの通信媒体を介して、他のコンピューティングデバイス上の、対話型でありプログラマティック(programmatic)管理用ツール環境にアクセスするためのリモーティング機構を提供する。例示的な一管理用ツールフレームワークにおいて、リモーティング機構は、複数の独立コントロールドメインに及ぶインフラストラクチャに依存する統合サービスをサポートする。リモーティング機構は、リモートコンピューティングデバイス上でスクリプトを実行させる。スクリプトは、1つまたは複数のリモートシステム上で実行され得る。スクリプトの結果は、個々の各スクリプトが完了したときに処理されることもでき、様々なコンピューティングデバイスの上のスクリプトすべてが完了した後で集約され、まとめて処理されることもできる。
たとえば、ホストコンポーネント202の1つとして示されるウェブサービス214は、リモートエージェントでよい。リモートエージェントは、ターゲットシステム上のパーサおよび管理用ツールフレームワークへのリモートコマンド要求の提出を操作する。リモーティングcmdletは、リモートエージェントへのアクセスを提供するためのリモートクライアントとして働く。リモートエージェントおよびリモーティングcmdletは、解析されたストリームを介して通信を行う。解析されたこのストリームが、プロトコル層で保護されることもでき、解析されたストリームを暗号化し、次いで解読するために追加cmdletが使われることもできる。
(ホスト非依存コンポーネント)
ホスト非依存コンポーネント206は、パーサ220、スクリプトエンジン222、およびコアエンジン224を含む。ホスト非依存コンポーネント206は、複数のcmdletをグループ化し、cmdletの動作を調整し、cmdletとの他のリソース、セッション、およびジョブの対話を調整するための機構およびサービスを提供する。
ホスト非依存コンポーネント206は、パーサ220、スクリプトエンジン222、およびコアエンジン224を含む。ホスト非依存コンポーネント206は、複数のcmdletをグループ化し、cmdletの動作を調整し、cmdletとの他のリソース、セッション、およびジョブの対話を調整するための機構およびサービスを提供する。
(例示的なパーサ)
パーサ220は、様々なホストプログラムから入力要求を受け取り、コアエンジン224内部など、管理用ツールフレームワーク内で用いられる一様なcmdletオブジェクトに入力要求をマップする機構を提供する。さらに、パーサ220は、受け取られた入力に基づいてデータ処理を実施することができる。入力に基づいてデータ処理を実施する例示的な一方法が、後で図12とともに説明される。本発明による管理用ツールフレームワークのパーサ220は、異なる言語またはシンタクスを容易に公開する能力を提供し、ユーザに同じ能力をもたらす。たとえば、パーサ220は、入力要求の解釈を担当するので、予想される入力シンタクスに影響を与える、パーサ220内部でのコードへの変更は、管理用ツールフレームワークの各ユーザに本質的に影響を与える。したがって、システム管理者は、異なるコンピューティングデバイス上で、異なるシンタクスをサポートする異なるパーサを提供することができる。ただし、同じパーサを使って操作している各ユーザは、各cmdletに対して一貫性があるシンタクスを経験する。対照的に、従来の環境では、各コマンドは、独自のシンタクスを実装していた。したがって、各環境は、数千のコマンドを使って、通常その多くは互いと一貫性がなかった異なるいくつかのシンタクスをサポートした。
パーサ220は、様々なホストプログラムから入力要求を受け取り、コアエンジン224内部など、管理用ツールフレームワーク内で用いられる一様なcmdletオブジェクトに入力要求をマップする機構を提供する。さらに、パーサ220は、受け取られた入力に基づいてデータ処理を実施することができる。入力に基づいてデータ処理を実施する例示的な一方法が、後で図12とともに説明される。本発明による管理用ツールフレームワークのパーサ220は、異なる言語またはシンタクスを容易に公開する能力を提供し、ユーザに同じ能力をもたらす。たとえば、パーサ220は、入力要求の解釈を担当するので、予想される入力シンタクスに影響を与える、パーサ220内部でのコードへの変更は、管理用ツールフレームワークの各ユーザに本質的に影響を与える。したがって、システム管理者は、異なるコンピューティングデバイス上で、異なるシンタクスをサポートする異なるパーサを提供することができる。ただし、同じパーサを使って操作している各ユーザは、各cmdletに対して一貫性があるシンタクスを経験する。対照的に、従来の環境では、各コマンドは、独自のシンタクスを実装していた。したがって、各環境は、数千のコマンドを使って、通常その多くは互いと一貫性がなかった異なるいくつかのシンタクスをサポートした。
(例示的なスクリプトエンジン)
スクリプトエンジン222は、スクリプトを用いて複数のcmdletを結合するための機構およびサービスを提供する。スクリプトとは、厳格な継承規則の下でセッション状態を共有するコマンドラインの集約である。スクリプト中の複数のコマンドラインは、入力要求中で提供されるシンタクスに基づいて、同期または非同期で実行され得る。スクリプトエンジン222は、ループおよび条件節などの制御構造を処理し、スクリプト中の変数を処理することができる。スクリプトエンジンはまた、セッション状態を管理し、ポリシー(図示せず)に基づいて、セッションデータへのアクセスをcmdletに与える。
スクリプトエンジン222は、スクリプトを用いて複数のcmdletを結合するための機構およびサービスを提供する。スクリプトとは、厳格な継承規則の下でセッション状態を共有するコマンドラインの集約である。スクリプト中の複数のコマンドラインは、入力要求中で提供されるシンタクスに基づいて、同期または非同期で実行され得る。スクリプトエンジン222は、ループおよび条件節などの制御構造を処理し、スクリプト中の変数を処理することができる。スクリプトエンジンはまた、セッション状態を管理し、ポリシー(図示せず)に基づいて、セッションデータへのアクセスをcmdletに与える。
(例示的なコアエンジン)
コアエンジン224は、パーサ220によって識別されるcmdletの処理を担当する。一時的に図4に移ると、管理用ツールフレームワーク200における例示的なコアエンジン224が示されている。例示的なコアエンジン224は、パイプラインプロセッサ402、ローダ404、メタデータプロセッサ406、エラー&イベントハンドラ408、セッションマネージャ410、および拡張タイプマネージャ412を含む。
コアエンジン224は、パーサ220によって識別されるcmdletの処理を担当する。一時的に図4に移ると、管理用ツールフレームワーク200における例示的なコアエンジン224が示されている。例示的なコアエンジン224は、パイプラインプロセッサ402、ローダ404、メタデータプロセッサ406、エラー&イベントハンドラ408、セッションマネージャ410、および拡張タイプマネージャ412を含む。
(例示的なメタデータプロセッサ)
メタデータプロセッサ406は、メタデータにアクセスし、図3に示されるデータベースストア314などのメタデータストアにメタデータを格納するように構成される。メタデータは、cmdletクラス定義などにおいて、コマンドラインを介して与えられ得る。管理用ツールフレームワーク200内部の様々なコンポーネントは、その処理を実施するとき、メタデータを要求し得る。たとえば、パーサ220は、コマンドライン上で供給されたパラメータを検証するためにメタデータを要求し得る。
メタデータプロセッサ406は、メタデータにアクセスし、図3に示されるデータベースストア314などのメタデータストアにメタデータを格納するように構成される。メタデータは、cmdletクラス定義などにおいて、コマンドラインを介して与えられ得る。管理用ツールフレームワーク200内部の様々なコンポーネントは、その処理を実施するとき、メタデータを要求し得る。たとえば、パーサ220は、コマンドライン上で供給されたパラメータを検証するためにメタデータを要求し得る。
(例示的なエラー&イベントプロセッサ)
エラー&イベントプロセッサ408は、コマンドラインの処理中にエラーのそれぞれの出現についての情報を格納するためのエラーオブジェクトを提供する。本発明による管理用ツールフレームワークに特に適している特定の一エラーおよびイベントプロセッサについての追加情報については、たとえば、米国特許出願第10/413,054号明細書「System and Method for Persisting Error Information in a Command Line Environment」を参照されたい。
エラー&イベントプロセッサ408は、コマンドラインの処理中にエラーのそれぞれの出現についての情報を格納するためのエラーオブジェクトを提供する。本発明による管理用ツールフレームワークに特に適している特定の一エラーおよびイベントプロセッサについての追加情報については、たとえば、米国特許出願第10/413,054号明細書「System and Method for Persisting Error Information in a Command Line Environment」を参照されたい。
(例示的なセッションマネージャ)
セッションマネージャ410は、管理用ツールフレームワーク200内部の他のコンポーネントに、セッションおよび状態情報を供給する。セッションマネージャによって管理される状態情報は、プログラミングインターフェイスを介して、どのcmdlet、ホスト、またはコアエンジンによってもアクセスされ得る。こうしたプログラミングインターフェイスは、状態情報の作成、修正、および削除を可能にする。
セッションマネージャ410は、管理用ツールフレームワーク200内部の他のコンポーネントに、セッションおよび状態情報を供給する。セッションマネージャによって管理される状態情報は、プログラミングインターフェイスを介して、どのcmdlet、ホスト、またはコアエンジンによってもアクセスされ得る。こうしたプログラミングインターフェイスは、状態情報の作成、修正、および削除を可能にする。
(例示的なパイプラインプロセッサおよびローダ)
ローダ404は、パイプラインプロセッサ402がcmdletを実行するために、各cmdletをメモリにロードするように構成される。パイプラインプロセッサ402は、cmdletプロセッサ420およびcmdletマネージャ422を含む。cmdletプロセッサ420は、個々のcmdletをディスパッチする。cmdletが、リモートでの、または1組のリモートマシンでの実行を要求した場合、cmdletプロセッサ420は、図2に示されるリモーティングcmdlet236を用いて実行を調整する。cmdletマネージャ422は、cmdletの集約の実行を操作する。cmdletマネージャ422、cmdletプロセッサ420、およびスクリプトエンジン222(図2)は、ホストプログラム210〜214から受け取られた入力に対する処理を実施するために、相互に通信する。通信は、本質的に再帰的であり得る。たとえば、ホストプログラムがスクリプトを与えた場合、スクリプトは、それ自体がスクリプトであり得るcmdletを実行するために、cmdletマネージャ422を呼び出し得る。スクリプトは次いで、スクリプトエンジン222によって実行され得る。コアエンジン用の例示的な一プロセスフローが、後で図14とともに詳しく説明される。
ローダ404は、パイプラインプロセッサ402がcmdletを実行するために、各cmdletをメモリにロードするように構成される。パイプラインプロセッサ402は、cmdletプロセッサ420およびcmdletマネージャ422を含む。cmdletプロセッサ420は、個々のcmdletをディスパッチする。cmdletが、リモートでの、または1組のリモートマシンでの実行を要求した場合、cmdletプロセッサ420は、図2に示されるリモーティングcmdlet236を用いて実行を調整する。cmdletマネージャ422は、cmdletの集約の実行を操作する。cmdletマネージャ422、cmdletプロセッサ420、およびスクリプトエンジン222(図2)は、ホストプログラム210〜214から受け取られた入力に対する処理を実施するために、相互に通信する。通信は、本質的に再帰的であり得る。たとえば、ホストプログラムがスクリプトを与えた場合、スクリプトは、それ自体がスクリプトであり得るcmdletを実行するために、cmdletマネージャ422を呼び出し得る。スクリプトは次いで、スクリプトエンジン222によって実行され得る。コアエンジン用の例示的な一プロセスフローが、後で図14とともに詳しく説明される。
(例示的な拡張タイプマネージャ)
上述したように、管理用ツールフレームワークは、オブジェクトのリフレクションを可能にし、その(オブジェクト)タイプに依存しない、リフレクトされたオブジェクトに対する処理を可能にする1組のユーティリティを提供する。管理用ツールフレームワーク200は、このリフレクションを実施するために、計算機システム上のコンポーネントフレームワーク(図1のコンポーネントフレームワーク120)と対話する。当業者は理解するであろうが、リフレクションは、オブジェクトを照会し、そのオブジェクトのタイプを入手し、次いで、様々なオブジェクトと、そのタイプのオブジェクトに関連するプロパティとをリフレクトして、他のオブジェクトおよび/または所望の値を入手する能力をもたらす。
上述したように、管理用ツールフレームワークは、オブジェクトのリフレクションを可能にし、その(オブジェクト)タイプに依存しない、リフレクトされたオブジェクトに対する処理を可能にする1組のユーティリティを提供する。管理用ツールフレームワーク200は、このリフレクションを実施するために、計算機システム上のコンポーネントフレームワーク(図1のコンポーネントフレームワーク120)と対話する。当業者は理解するであろうが、リフレクションは、オブジェクトを照会し、そのオブジェクトのタイプを入手し、次いで、様々なオブジェクトと、そのタイプのオブジェクトに関連するプロパティとをリフレクトして、他のオブジェクトおよび/または所望の値を入手する能力をもたらす。
リフレクションは、管理用ツールフレームワーク200に、オブジェクトについての相当量の情報を提供するが、本発明者は、リフレクションが、オブジェクトのタイプに焦点を当てていることを認識した。たとえば、データベースのデータテーブルがリフレクトされると、返される情報は、データテーブルが2つのプロパティ、すなわち列プロパティおよび行プロパティを有するというものである。こうした2つのプロパティは、データテーブル中の「オブジェクト」に関する十分な詳細を提供しない。リフレクションが拡張マークアップ言語(XML)および他のオブジェクトにおいて用いられると、同様の問題が起こる。
したがって、本発明者は、タイプの使用法に焦点を当てる拡張タイプマネージャ412を考案した。この拡張タイプマネージャにとって、オブジェクトのタイプは重要でない。そうではなく、拡張タイプマネージャは、必要な情報を入手するためにオブジェクトが使用され得るかどうかに関心を示す。上記データテーブルの例を用いて続けると、本発明者は、データテーブルが列プロパティおよび行プロパティを有することがわかってもあまり興味深くないと認識したが、ある1列が興味深い情報を含むことを認識した。使用法に注目すると、各行を「オブジェクト」に関連づけ、各列をその「オブジェクト」の「プロパティ」に関連づけることができよう。したがって、拡張タイプマネージャ412は、精密解析可能などのタイプの入力からも「オブジェクト」を作成するための機構を提供する。この機構の提供において、拡張タイプマネージャ412は、コンポーネントベースのフレームワーク120によって提供されるリフレクション機能を補い、「リフレクション」を、精密解析可能などのタイプの入力にも拡張する。
概して、拡張タイプマネージャは、精密解析可能な入力(図示せず)にアクセスし、精密解析可能な入力を、要求されたデータ型に相関させるように構成される。拡張タイプマネージャ412は次いで、パイプラインプロセッサ402やパーサ220などの要求コンポーネントに、要求された情報を提供する。以下の説明において、精密解析可能な入力は、プロパティおよび値が見分けられ得る入力として定義される。精密解析可能な一部の例示的入力は、WMI(Windows(登録商標) Management Instrumentation)入力、ActiveXデータオブジェクト(ADO)入力、拡張マークアップ言語(XML)入力、および.NETオブジェクトなどのオブジェクト入力を含む。他の精密解析可能な入力は、サードパーティのデータ形式を含み得る。
一時的に図18に移ると、管理用ツールフレームワークでの使用に適した例示的な拡張タイプマネージャを示す機能ブロック図が示されている。説明のために、拡張タイプマネージャによって提供される機能(丸で囲まれた番号「3」で示される)は、従来の密束縛システム(tightly bound system)によって提供される機能(丸で囲まれた番号「1」で示される)、およびリフレクションシステムによって提供される機能(丸で囲まれた番号「2」で示される)と対比される。従来の密束縛システムでは、アプリケーションにおけるコール側1802は、オブジェクトAの中の情報(たとえば、プロパティP1およびP2、メソッドM1およびM2)に直接アクセスする。上述したように、コール側1802は、コンパイル時にオブジェクトAによって与えられるプロパティ(たとえば、プロパティP1およびP2)ならびにメソッド(たとえば、メソッドM1およびM2)を先験的に知っていなければならない。リフレクションシステムにおいて、ジェネリックコード1820(どのデータ型にも依存しない)は、要求されたオブジェクトに対してリフレクション1810を実施するとともにオブジェクト(たとえば、オブジェクトA)についての情報(たとえば、プロパティP1およびP2、メソッドM1およびM2)をジェネリックコード1820に返すシステム1808に問合せを行う。オブジェクトAには示されていないが、返される情報は、たとえばベンダ、ファイル、日付などの付加情報を含み得る。したがって、リフレクションにより、ジェネリックコード1820は少なくとも、密束縛システムが提供する同じ情報を入手する。リフレクションシステムは、コール側1802がシステムに問合せを行うこと、およびパラメータについて先験的に何も知らなくても付加情報を入手することも可能にする。
密束縛システムおよびリフレクションシステム両方において、新規データ型は、動作環境に容易に組み込まれることができない。たとえば、密束縛システムにおいて、動作環境が引き渡されると、動作環境は、新規データ型をサポートするために再構築されなければならないので、新規データ型を組み込むことができない。同様に、リフレクションシステムでは、各オブジェクトクラスについてのメタデータが固定される。したがって、新規データ型の組込みは通常、行われない。
しかし、本発明による拡張タイプマネージャを用いると、新規データ型が、オペレーティングシステムに組み込まれ得る。拡張タイプマネージャ1822を用いると、ジェネリックコード1820は、要求されたオブジェクトをリフレクトして、様々な外部ソース、たとえばサードパーティオブジェクト(たとえば、オブジェクトAおよびB)、セマンティックウェブ1832、オントロジー(ontology)サービス1834などによって与えられる拡張データ型(たとえば、オブジェクトA’)を入手することができる。説明されたように、サードパーティオブジェクトは、既存のオブジェクト(たとえばオブジェクトA’)を拡張することもでき、全く新しいオブジェクト(たとえばオブジェクトB)を作成することもできる。
こうした外部ソースはそれぞれ、タイプメタデータ1840に一義的な構造を登録し、コード1842を提供することができる。オブジェクトが照会されると、拡張タイプマネージャは、タイプメタデータ1840を見直して、オブジェクトが登録されているかどうか判定する。オブジェクトがタイプメタデータ1840に登録されていない場合、リフレクションが実施される。登録されている場合、拡張リフレクションが実施される。コード1842は、リフレクトされるタイプに関連づけられた追加プロパティおよびメソッドを返す。たとえば、入力タイプがXMLの場合、コード1842は、XMLドキュメントからオブジェクトを作成するためのXMLの使われ方を記述する記述ファイルを含み得る。したがって、タイプメタデータ1840は、その具体的な入力タイプ向けのオブジェクトを作成する所望のプロパティを入手するために、拡張タイプマネージャ412が様々なタイプの精密解析可能入力(たとえば、サードパーティオブジェクトAおよびB、セマンティックウェブ1832)をどのようにして照会するべきかを記述し、コード1842は、こうした所望のプロパティを入手するための命令を提供する。その結果、拡張タイプマネージャ412は、全タイプのオブジェクトの「リフレクション」を可能にする間接指定層を提供する。
拡張タイプの提供に加えて、拡張タイプマネージャ412は、たとえばプロパティパス機構、キー機構、比較機構、変換機構、グロバ(globber)機構、プロパティセット機構、関係機構など、追加クエリ機構を提供する。こうしたクエリ機構はそれぞれ、後で「例示的な拡張タイプマネージャ処理」というセクションで説明されるが、コマンド文字列を入力するとき、システム管理者に柔軟性をもたらす。拡張タイプマネージャ用のセマンティクスを実装するのに、様々な技術が用いられ得る。3つの技術が後で説明される。ただし、こうした技術の変形形態は、特許請求の範囲に記載されている本発明の範囲から逸脱することなく利用され得ることを当業者は理解するであろう。
ある技術では、静的メソッド(たとえば、getproperty())を有する一連のクラスが提供される。オブジェクトは、静的メソッドに入力され(たとえば、getproperty(object))、静的メソッドは、1組の結果を返す。別の技術では、動作環境は、オブジェクトをアダプタで包む。このようにして、入力は与えられない。アダプタの各インスタンスは、包まれたオブジェクトに作用するとともに包まれたオブジェクト用のプロパティを返すgetpropertyメソッドを有する。以下は、この技術を示す擬似コードである。
さらに別の技術では、アダプタクラスが、オブジェクトを下位分類する。従来、下位分類は、コンパイルの前に起きた。しかし、特定の動作環境を用いると、下位分類は、動的に起こり得る。こうしたタイプの環境に対して、以下が、この技術を示す擬似コードである。
したがって、図18に示されるように、拡張タイプマネージャは、開発者が新規データ型を作成し、データ型を登録することを可能にし、他のアプリケーションおよびcmdletに、新規データ型を使用させる。対照的に、従来の管理環境では、各データ型は、そのデータ型からインスタンス化されたオブジェクトに関連づけられたプロパティまたはメソッドが直接アクセスされ得るように、コンパイル時に知られていなければならなかった。したがって、管理環境によってサポートされる新規データ型の追加は、従来、ほとんど行われなかった。
図2に戻ると、概して、管理用ツールフレームワーク200は、ユーザによって入力されるコマンドの実行を調整するシェルに依拠するのではなく、(たとえば、ホストcmdletにより)機能を処理部分(たとえば、ホスト非依存コンポーネント206)およびユーザ対話部分に分割する。さらに、本発明による管理用ツール環境は、解析およびデータ認証に要求されるコードが、各コマンドに含まれなくなり、管理用ツールフレームワーク内部のコンポーネント(たとえば、パーサ220)によって提供されるので、管理用ツールのプログラミングを大幅に簡略化する。管理用ツールフレームワークにおいて実施される例示的な処理は、後で説明される。
(例示的な動作)
図5〜7は、管理用ツール環境において使われる例示的なデータ構造を、図表により示す。図8〜17は、管理用ツール環境における例示的な処理フローを、図表により示す。特定の処理は、後で説明されるコンポーネントとは異なるコンポーネントによって、本発明の範囲から逸脱することなく実施され得ることを当業者は理解するであろう。管理用ツールフレームワークのコンポーネント内で実施される処理を説明する前に、管理用ツールフレームワークにおいて用いられる例示的なデータ構造が説明される。
図5〜7は、管理用ツール環境において使われる例示的なデータ構造を、図表により示す。図8〜17は、管理用ツール環境における例示的な処理フローを、図表により示す。特定の処理は、後で説明されるコンポーネントとは異なるコンポーネントによって、本発明の範囲から逸脱することなく実施され得ることを当業者は理解するであろう。管理用ツールフレームワークのコンポーネント内で実施される処理を説明する前に、管理用ツールフレームワークにおいて用いられる例示的なデータ構造が説明される。
(cmdletオブジェクトの例示的なデータ構造)
図5は、図2に示される管理用ツールフレームワークでの使用に適したcmdletを指定する例示的なデータ構造である。cmdletは、完了されると、管理cmdlet、非管理cmdlet、ホストcmdlet、プロバイダcmdletなどになり得る。以下の説明は、システム管理者の視点(すなわち、プロバイダcmdlet)を参照して、cmdletの作成について述べる。ただし、各タイプのcmdletは、同じやり方で作成され、同じように動作する。cmdletは、C#など、どの言語でも書かれ得る。さらに、cmdletは、スクリプト言語などを使って書かれ得る。管理用ツール環境が.NETフレームワークとともに動作する場合、cmdletは、.NETオブジェクトでよい。
図5は、図2に示される管理用ツールフレームワークでの使用に適したcmdletを指定する例示的なデータ構造である。cmdletは、完了されると、管理cmdlet、非管理cmdlet、ホストcmdlet、プロバイダcmdletなどになり得る。以下の説明は、システム管理者の視点(すなわち、プロバイダcmdlet)を参照して、cmdletの作成について述べる。ただし、各タイプのcmdletは、同じやり方で作成され、同じように動作する。cmdletは、C#など、どの言語でも書かれ得る。さらに、cmdletは、スクリプト言語などを使って書かれ得る。管理用ツール環境が.NETフレームワークとともに動作する場合、cmdletは、.NETオブジェクトでよい。
プロバイダcmdlet500(これ以降、cmdlet500と呼ばれる)は、cmdletクラス名(たとえば、StopProcess504)を有するパブリッククラスである。cmdlet500は、cmdletクラス506から派生する。cmdletクラス506用の例示的なデータ構造が、後で図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に関連づけられたメタデータに格納される。こうした属性の適用が、後で図12とともに説明される。
こうした属性は、cmdlet内で宣言されるパラメータの投入にも影響を与え得る。こうしたパラメータを投入する例示的な一プロセスが、後で図16とともに説明される。コアエンジンは、準拠性を保証するためにこうしたディレクティブを適用し得る。cmdlet500は、第1のメソッド530(これ以降、同義的にStartPrecessingメソッド530と呼ばれる)および第2のメソッド540(これ以降、同義的にprocessRecordメソッド540と呼ばれる)を含む。コアエンジンは、第1および第2のメソッド530、540を用いて、cmdlet500の処理を指示する。たとえば、第1のメソッド530が一度実行され、セットアップ機能を実施する。第2のメソッド540中のコード542は、cmdlet500によって処理される必要がある各オブジェクト(たとえばrecord)に対して実行される。cmdlet500は、cmdlet500の後でクリーンアップを行う第3のメソッド(図示せず)も含み得る。
したがって、図5に示されるように、第2のメソッド540中のコード542は通常、非常に短く、たとえば解析コード、データ認証コードなど、従来の管理用ツール環境において要求される機能を含まない。したがって、システム管理者は、複雑なプログラミング言語を学習することなく、複雑な管理タスクを開発することができる。
図6は、図5に示されるcmdletが派生されるcmdlet基本クラス602を詳述する例示的なデータ構造600である。cmdlet基本クラス602は、cmdletがフックステートメントを含み、対応するスイッチがコマンドラインでまたはスクリプト中で入力される(併せてコマンド入力と呼ばれる)ときはいつでも、付加機能を提供する命令を含む。
例示的なデータ構造600は、ブーリアンパラメータverbose610、whatif620、およびconfirm630などのパラメータを含む。後で説明されるように、こうしたパラメータは、コマンド入力で入力され得る文字列に対応する。例示的なデータ構造600は、実行を要求されているタスクが許可されるかどうかを判定するセキュリティメソッド640も含み得る。
図7は、cmdletを詳述する、別の例示的なデータ構造700である。概して、データ構造700は、管理用ツールフレームワークとcmdletの間のコントラクトを明白に表現する手段を提供する。データ構造500と同様、データ構造700は、cmdletクラス704から派生するパブリッククラスである。ソフトウェア開発者は、「get/process」および「format/table」などの名詞/動詞ペアをcmdlet700に関連づけるcmdletDeclaration702を指定する。名詞/動詞ペアは、管理用ツール環境内で登録される。動詞も名詞も、cmdlet名において暗黙的でよい。また、データ構造500と同様、データ構造700は、データ構造500とともに説明される1つまたは複数のディレクティブ510〜520に関連づけられ得る1つまたは複数のパブリックメンバ(たとえば、Name730、Recurse732)を含み得る。
ただし、この例示的なデータ構造700において、予想される入力パラメータ730および732はそれぞれ、入力属性731および733それぞれに関連づけられる。入力属性731および733は、それぞれのパラメータ730および732用のデータがコマンドラインから取得されるべきであると指定する。したがって、この例示的なデータ構造700において、別のcmdletによって発せられたパイプラインオブジェクトから投入される、予想される入力パラメータが存在しない。したがって、データ構造700は、cmdlet基本クラスによって提供される第1のメソッド(たとえば、StartProcessing)も第2のメソッド(たとえば、ProcessRecord)もオーバーライドしない。
データ構造700は、入力パラメータとして認識されないプライベートメンバ740も含み得る。プライベートメンバ740は、ディレクティブの1つに基づいて生成されるデータの格納に使われ得る。
したがって、データ構造700に示されるように、具体的なcmdletクラスにおいてパブリックプロパティおよびディレクティブの宣言を使用することにより、cmdlet開発者は、そのcmdletに対して予想される入力パラメータ用の文法を容易に指定し、cmdlet開発者が基底論理のいずれかをも生成する必要なく、予想される入力パラメータに対して実施されるべき処理を指定することができる。データ構造700は、cmdletと文法機構の間の直接的な関連づけを示す。上述したように、この関連づけは、XMLドキュメントなどの外部ソースにおいて、予想されるパラメータ定義を明記するなどして、間接的でもよい。
管理用ツール環境における例示的なプロセスフローが次に説明される。
(例示的なホスト処理フロー)
図8は、図2に示される管理用ツールフレームワーク内部で実施されるホスト処理のための例示的なプロセスを示す論理フロー図である。プロセス800は、ブロック801で始まり、ここで、具体的なアプリケーション向けの管理用ツール環境を開始するための要求が受け取られている。要求は、アプリケーションアイコンの選択などのキーボード入力を介してローカルに、または異なるコンピューティングデバイスのウェブサービスインターフェイスを介してリモートに送られている可能性がある。いずれのシナリオでも、処理は、ブロック802へ続く。
図8は、図2に示される管理用ツールフレームワーク内部で実施されるホスト処理のための例示的なプロセスを示す論理フロー図である。プロセス800は、ブロック801で始まり、ここで、具体的なアプリケーション向けの管理用ツール環境を開始するための要求が受け取られている。要求は、アプリケーションアイコンの選択などのキーボード入力を介してローカルに、または異なるコンピューティングデバイスのウェブサービスインターフェイスを介してリモートに送られている可能性がある。いずれのシナリオでも、処理は、ブロック802へ続く。
ブロック802で、「ターゲット」コンピューティングデバイス上の具体的なアプリケーション(たとえばホストプログラム)が、その環境をセットアップする。このセットアップは、cmdletのどのサブセット(たとえば、管理cmdlet232、非管理cmdlet234、およびホストcmdlet218)がユーザに対して使用可能にされるかという判定を含む。通常、ホストプログラムは、非管理cmdlet234すべてを使用可能にし、独自のホストcmdlet218を使用可能にする。さらに、ホストプログラムは、プロセス、ディスクなどを扱うcmdletなど、管理cmdlet232の一部を使用可能にする。したがって、ホストプログラムがcmdletの一部を使用可能にすると、管理用ツールフレームワークは、対応するアプリケーションに有効に組み込まれる。処理は、ブロック804へ続く。
ブロック804で、特定のアプリケーションを介して入力が入手される。上述したように、入力は、たとえばコマンドライン、スクリプト、音声、GUIなど、いくつかの形をとり得る。たとえば、コマンドラインを介して入力が入手されると、入力は、キーボードで入れられるキーストロークから取得される。GUIホストに対しては、GUIに基づいて文字列が組み立てられる。処理は、ブロック806で継続する。
ブロック806で、入力は、処理のために管理用ツールフレームワーク内部の他のコンポーネントに与えられる。ホストプログラムは、パーサなど、他のコンポーネントに入力を直接転送することができる。あるいは、ホストプログラムは、そのホストcmdletの1つを介して入力を転送することもできる。ホストcmdletは、その具体的なタイプの入力(たとえば音声)を、管理用ツールフレームワークによって認識されるタイプの入力(たとえば、テキスト列、スクリプト)に変換することができる。たとえば、音声入力は、音声入力の内容に応じて、スクリプトまたはコマンドライン文字列に変換され得る。各ホストプログラムは、そうしたタイプの入力を、管理用ツールフレームワークによって認識される入力に変換する責任があるので、管理用ツールフレームワークは、任意の数の様々なホストコンポーネントからの入力を受諾することができる。さらに、管理用ツールフレームワークは、入力がそのcmdletの1つを介して転送されるときにデータ型の間の変換を実施する、豊富な1組のユーティリティを提供する。他のコンポーネントによって入力に対して実施される処理が、後で他のいくつかの図とともに説明される。ホスト処理は、判断ブロック808で継続する。
判断ブロック808で、追加入力の要求が受け取られたかどうか、判定が行われる。この判定は、入力の処理を担当する他のコンポーネントの1つが、その処理を完了するためにユーザからの付加情報を必要とする場合に起こり得る。たとえば、特定のデータにアクセスするのにパスワードが要求され、具体的なアクションの確認が必要とされる場合などがある。特定のタイプのホストプログラム(たとえば音声メール)に対して、このような要求は適切でない場合がある。したがって、ユーザに付加情報を問い合わせるのではなく、後で状態が再開され、入力の実行が継続され得るようにホストプログラムが状態をシリアル化し、状態を一時停止し、通知を送ることができる。別の変形形態では、ホストプログラムは、所定の期間の後でデフォルト値を提供することができる。追加入力の要求が受け取られた場合、処理は、ブロック804にループバックし、ここで、追加入力が入手される。処理は次いで、上述されたようにブロック806および808を経由して継続する。追加入力要求が受け取られず、入力が処理されている場合、処理は、ブロック810へ続く。
ブロック810で、管理用ツールフレームワーク内部の他のコンポーネントから結果が受け取られる。結果は、エラーメッセージ、状況などを含み得る。結果は、管理用ツールフレームワーク内部のホストcmdletによって認識され処理されるオブジェクトの形である。後で説明されるように、各ホストcmdlet用に書かれるコードは、非常に小さい。したがって、開発コストへの莫大な投資を要せずに豊富な1組の出力が表示され得る。処理は、ブロック812で継続する。
ブロック812で、結果が閲覧され得る。ホストcmdletは、ホストプログラムによってサポートされる表示スタイルに結果を変換する。たとえば、返されたオブジェクトは、アイコン、ほえる犬(barking dog)など、図形表示を用いて、GUIホストプログラムによって表示され得る。ホストcmdletは、データのデフォルト形式および出力を提供する。デフォルト形式および出力は、後で図19〜23とともに説明される例示的な出力処理cmdletを使用し得る。結果が任意選択で表示された後、ホスト処理が完了する。
(入力を操作する例示的なプロセスフロー)
図9は、図2に示される管理用ツールフレームワーク内部で実施される入力操作のための例示的なプロセスを示す論理フロー図である。処理は、ブロック901で始まり、ここで、入力が、ホストプログラムを介して入れられ、管理用ツールフレームワーク内部の他のコンポーネントに転送されている。処理は、ブロック902で継続する。
図9は、図2に示される管理用ツールフレームワーク内部で実施される入力操作のための例示的なプロセスを示す論理フロー図である。処理は、ブロック901で始まり、ここで、入力が、ホストプログラムを介して入れられ、管理用ツールフレームワーク内部の他のコンポーネントに転送されている。処理は、ブロック902で継続する。
ブロック902で、入力は、ホストプログラムから受け取られる。例示的な一管理用ツールフレームワークにおいて、入力は、パーサによって受け取られ、このパーサは、入力を解読し、入力をさらに処理するように向ける。処理は、判断ブロック904で継続する。
判断ブロック904で、入力がスクリプトであるかどうか判定が行われる。入力は、スクリプト、またはコマンドラインを表す文字列(これ以降、「コマンド文字列」と呼ばれる)の形をとり得る。コマンド文字列は、まとめてパイプライン処理される1つまたは複数のcmdletを表し得る。管理用ツールフレームワークは、異なるいくつかのホストをサポートするが、各ホストは、処理用のスクリプトまたはコマンド文字列として入力を提供する。後で示されるように、スクリプトとコマンド文字列の間の対話は、本質的に再帰的である。たとえば、スクリプトは、cmdletを呼び出す行を有し得る。cmdlet自体は、スクリプトでよい。
したがって、判断ブロック904で、入力がスクリプトの形の場合、処理は、ブロック906で継続し、ここで、スクリプトの処理が実施される。スクリプトの形でない場合、処理は、ブロック908で継続し、ここで、コマンド文字列の処理が実施される。ブロック906または908で実施される処理が完了されると、入力の処理が完了する。
(スクリプトの例示的な処理)
図10は、図9に示される入力操作プロセスでの使用に適したスクリプトを処理するプロセスを示す論理フロー図である。プロセスは、ブロック1001で始まり、ここで、入力は、スクリプトとして識別されている。スクリプトエンジンおよびパーサは、相互に通信して、後続の機能を実施する。処理は、ブロック1002で継続する。
図10は、図9に示される入力操作プロセスでの使用に適したスクリプトを処理するプロセスを示す論理フロー図である。プロセスは、ブロック1001で始まり、ここで、入力は、スクリプトとして識別されている。スクリプトエンジンおよびパーサは、相互に通信して、後続の機能を実施する。処理は、ブロック1002で継続する。
ブロック1002で、スクリプトに対して前処理が実施される。一時的に図11に移ると、スクリプト処理プロセス1000での使用に適したスクリプト前処理プロセス1100を示す論理フロー図が示されている。スクリプトの前処理は、ブロックで1101始まり、判断ブロック1102へ続く。
判断ブロック1102で、スクリプトが初めて実行されているのかどうか、判定が行われる。この判定は、レジストリまたは他の記憶機構から入手される情報に基づき得る。スクリプトは、記憶機構内部から識別され、関連するデータが検討される。スクリプトが実行されたことがない場合、処理は、ブロック1104で継続する。
ブロック1104で、スクリプトがレジストリに登録される。この登録は、管理用ツールフレームワーク内部のコンポーネントによるその後のアクセスのために、スクリプトについての情報を格納させる。処理は、ブロック1106で継続する。
ブロック1106で、ヘルプおよびドキュメンテーションがスクリプトから抽出され、レジストリに格納される。やはり、この情報も、管理用ツールフレームワーク内部のコンポーネントによって後でアクセスされ得る。スクリプトはこの時点で、処理の準備が整い、図10のブロック1004に戻る。
判断ブロック1102に戻ると、スクリプトが前に実行されたことがあるとプロセスが結論づけた場合、処理は判断ブロック1108へ続く。判断ブロック1108で、スクリプトが処理中に障害を起こしたかどうか、判定が行われる。この情報は、レジストリから入手され得る。スクリプトが障害を起こしていない場合、スクリプトは、処理の準備が整い、図10のブロック1004に戻る。
しかし、スクリプトが障害を起こした場合、処理は、ブロック1110で継続する。ブロック1110で、スクリプトエンジンは、スクリプトが障害を起こしたことを、ホストプログラムを介してユーザに通知し得る。この通知は、スクリプトを進めるか、それともスクリプトを終了させるか、ユーザに判断させる。図8とともに上述されたように、ホストプログラムは、この要求を、入力スタイル(たとえば、音声、コマンドライン)に応じて様々なやり方で扱うことができる。ユーザから追加入力が受け取られると、スクリプトは、処理のために図10のブロック1004に戻るか、またはスクリプトが破棄される。
図10のブロック1004に戻ると、スクリプト中の行が取得される。処理は、判断ブロック1006で継続する。判断ブロック1006で、行が何らかの制約を含むかどうか、判定が行われる。制約は、予め定義された開始キャラクタ(たとえば、括弧「[」)および対応する終了キャラクタ(たとえば、閉じ括弧「]」)で検出される。行が制約を含む場合、処理は、ブロック1008へ続く。
ブロック1008で、行に含まれる制約が適用される。概して、制約は、スクリプトに入れられたパラメータ用のタイプを指定するとともにパラメータに対して実施されるべき認証論理を指定するための機構を、管理用ツールフレームワーク内部で提供する。制約は、パラメータに対して適用可能なだけでなく、変数など、スクリプトに入れられたどのタイプの構文(construct)にも適用可能である。したがって、制約は、データ型を指定し、パラメータを検証するための機構を、解釈環境内部で提供する。従来の環境では、システム管理者は、スクリプトに入れられたパラメータを正式にテストすることができない。制約を課す例示的なプロセスは、図12に示される。
判断ブロック1010で、スクリプトの行が組込み機能を含むかどうか、判定が行われる。組込み機能は、コアエンジンによって実施されない機能である。組込み機能は、cmdletを用いて処理されることも、インライン関数など、他の機構を用いて処理されることもできる。行が組込み機能をもたない場合、処理は、判断ブロック1014で継続する。組込み機能をもつ場合、処理は、1012ブロックで継続する。
ブロック1012で、スクリプトの行で与えられた組込み機能が処理される。組込み機能の例は、たとえば「if」ステートメント、「for」ループ、スイッチなど、コントロール構造の実行を含み得る。組込み機能は、割当てタイプのステートメント(たとえば、a=3)も含み得る。組込み機能が処理されると、処理は、判断ブロック1014へ続く。
判断ブロック1014で、スクリプトの行がコマンド文字列を含むかどうか、判定が行われる。判定は、登録されているコマンド文字列と、起こり得るcmdlet呼出しのシンタクスとに行中のデータが関連づけられているかどうかに基づく。上述したように、コマンド文字列およびスクリプトの処理は、本質的に再帰的であり得る。というのは、スクリプトは、コマンド文字列を含むことができ、コマンド文字列は、それ自体がスクリプトであるcmdletを実行することができるからである。行がコマンド文字列を含まない場合、処理は、判断ブロック1018で継続する。コマンド文字列を含む場合、処理は、ブロック1016で継続する。
ブロック1016で、コマンド文字列が処理される。概して、コマンド文字列の処理は、パーサによってcmdletクラスを識別すること、および対応するcmdletオブジェクトを実行のためにコアエンジンに渡すことを含む。コマンド文字列は、いくつかの別個のcmdletオブジェクトに解析されるとともにコアエンジンによって個別に処理されるパイプライン型コマンド文字列も含み得る。コマンド文字列を処理する例示的な一プロセスが、後で図14とともに説明される。コマンド文字列が処理されると、処理は、判断ブロック1018で継続する。
判断ブロック1018で、スクリプトにさらに行があるかどうか、判定が行われる。スクリプトにさらに行がある場合、処理は、ブロック1004にループバックし、ブロック1004〜1016で上述されたように進行する。行がない場合、処理は完了する。
ブロック1008で制約を課す例示的なプロセスが、図12に示されている。プロセスは、ブロック1201で始まり、ここで、スクリプト中の、またはコマンドライン上のコマンド文字列中の制約が検出される。制約がスクリプト中にある場合、制約および関連する構文は、同じ行にも別個の行にも現れ得る。制約がコマンド文字列中にある場合、制約および関連する構文は、行末インジケータ(たとえば、エンターキー)の前に現れる。処理は、ブロック1202へ続く。
ブロック1202で、解釈環境から制約が入手される。例示的な一管理用ツール環境において、パーサは、入力を復号し、制約の出現を判定する。制約は、述語ディレクティブ(predicate directive)、解析ディレクティブ、データ認証ディレクティブ、データ生成ディレクティブ、処理ディレクティブ、エンコードディレクティブ、およびドキュメンテーションディレクティブのカテゴリーの1つでよい。例示的な一解析シンタクスの場合、ディレクティブは、角括弧で囲まれ、その後に続く構文を記述する。構文は、関数、変数、スクリプトなどでよい。
後で説明されるように、ディレクティブを使用することにより、スクリプト作成者は、スクリプト作成者が基底論理のいずれを生成することも要せずに、スクリプトまたはコマンドライン(すなわち、解釈環境)におけるパラメータに対する処理を容易にタイプし実施することを可能にされる。処理は、ブロック1204へ続く。
ブロック1204で、入手された制約が、関連する構文用のメタデータに格納される。関連する構文は、1つまたは複数の属性表示(attribution)トークン(制約を示すトークン)が遭遇された後、第1の非属性表示トークンであると識別される。処理は、ブロック1206へ続く。
ブロック1206で、スクリプト中またはコマンド文字列中で構文が遭遇されると常に、メタデータ内部で定義された制約が、構文に適用される。制約は、データ型、述語ディレクティブ1210、ドキュメンテーションディレクティブ1212、解析ディレクティブ1214、データ生成ディレクティブ1216、データ認証ディレクティブ1218、ならびにオブジェクト処理およびエンコードディレクティブ1220を含み得る。データ型を指定する制約は、管理用ツールフレームワークが実行されているシステム上でサポートされるどのデータ型も指定し得る。述語ディレクティブ1210は、処理が起こるべきかどうかを示すディレクティブである。したがって、述語ディレクティブ1210は、実行に対して環境が適正であることを保証する。たとえば、スクリプトは、次の述語ディレクティブを含み得る。
[PredicateScript("isInstalled","ApplicationZ")]
この述語ディレクティブは、スクリプトを実行する前に正しいアプリケーションがコンピューティングデバイスにインストールされることを保証する。通常、システム環境変数は、述語ディレクティブとして指定され得る。ディレクティブタイプ1212〜1220にある例示的なディレクティブが、テーブル1〜5に示される。スクリプトの処理は次いで、完了する。
この述語ディレクティブは、スクリプトを実行する前に正しいアプリケーションがコンピューティングデバイスにインストールされることを保証する。通常、システム環境変数は、述語ディレクティブとして指定され得る。ディレクティブタイプ1212〜1220にある例示的なディレクティブが、テーブル1〜5に示される。スクリプトの処理は次いで、完了する。
したがって、解釈環境においてタイプおよび制約を適用する本プロセスは、システム管理者が、この処理を実施する基底論理を書くことなく、タイプを容易に指定し、認証要件を指定することなどを可能にする。以下は、次のように指定されたコマンド文字列に対して実施される制約処理の例である。
「[]」で示される属性表示トークンにより指定される2つの制約がある。第1の属性表示トークンは、変数が整数型であることを示し、第2の属性表示トークンは、変数$aの値が3と5を含むその間でなければならないことを示す。このコマンド文字列の例は、後続コマンド文字列または行の中で変数$aが割り当てられている場合、変数$aは、2つの制約と突き合わせて調べられることを保証する。したがって、次のコマンド文字列が、エラー中でそれぞれ現れるはずである。
制約は、管理用ツールフレームワークにおいて様々な段階で適用される。たとえば、使用可能性ディレクティブ、ドキュメンテーションディレクティブ、および解析ガイドラインディレクティブは、非常に早い段階にパーサ内で処理される。データ生成ディレクティブおよび認証ディレクティブは、パーサが入力パラメータすべての解析を終えるとエンジン内で処理される。
以下のテーブルは、ディレクティブに応答して管理用ツール環境によって実施されるプロセスの説明とともに、様々なカテゴリー用の代表的なディレクティブを示す。
.NET(商標)フレームワーク内部で例示的な管理用ツールフレームワークが動作しているとき、各カテゴリーは、基本カテゴリークラス(たとえば、CmdAttribute)から派生される基本クラスを有する。基本カテゴリークラスは、System.Attributeクラスから派生する。各カテゴリーは、カテゴリー処理中にパーサによってコールされる、予め定義された関数(たとえば、attrib.func())を有する。スクリプト作成者は、カスタムカテゴリークラス(たとえば、CmdCustomAttribute)から派生されるカスタムカテゴリーを作成することができる。スクリプト作成者は、そのカテゴリー用の基本カテゴリークラスからディレクティブクラスを派生することによって既存のカテゴリークラスを拡張し、予め定義された関数を実装でオーバーライドすることもできる。スクリプト作成者は、ディレクティブをオーバーライドし、予め定義されたディレクティブの組に新規ディレクティブを追加することもできる。
こうしたディレクティブの処理順序は、パーサによってアクセス可能な外部データストアに格納され得る。管理用ツールフレームワークは、登録されたカテゴリーを探し、そのカテゴリー中のディレクティブそれぞれに対して関数(たとえば、ProcessCustomDirective)をコールする。したがって、カテゴリー処理の順序は、カテゴリー実行情報を永続ストアに格納することによって、動的になり得る。様々なプロセス段階で、パーサは、永続ストアの中を調べて、いずれかのメタデータカテゴリーが、その時点で実行される必要があるかどうか判定する。この判定は、永続ストアからカテゴリーエントリを削除することによって、カテゴリーを容易に廃止させる。
(コマンド文字列の例示的な処理)
コマンド文字列を処理する例示的な一プロセスが次に説明される。図13は、図2に示される管理用ツールフレームワークにおける、パーサ220およびコアエンジン224を介したコマンド文字列1350の処理を図表により示す機能フロー図である。例示的なコマンド文字列1350は、いくつかのコマンド(すなわち、processコマンド1360、whereコマンド1362、sortコマンド1364、およびtableコマンド1366)をパイプライン処理する。コマンドライン1350は、こうしたコマンドのいずれにも入力パラメータを渡し得る(たとえば、「handlecount>400」が、whereコマンド1362に渡される)。processコマンド1360は、関連する入力パラメータを何ももたないことに留意されたい。
コマンド文字列を処理する例示的な一プロセスが次に説明される。図13は、図2に示される管理用ツールフレームワークにおける、パーサ220およびコアエンジン224を介したコマンド文字列1350の処理を図表により示す機能フロー図である。例示的なコマンド文字列1350は、いくつかのコマンド(すなわち、processコマンド1360、whereコマンド1362、sortコマンド1364、およびtableコマンド1366)をパイプライン処理する。コマンドライン1350は、こうしたコマンドのいずれにも入力パラメータを渡し得る(たとえば、「handlecount>400」が、whereコマンド1362に渡される)。processコマンド1360は、関連する入力パラメータを何ももたないことに留意されたい。
従来、各コマンドは、コマンドに関連づけられた入力パラメータの解析、入力パラメータが有効であるかどうかの判定、および入力パラメータが有効でない場合のエラーメッセージの発行を担当した。コマンドは通常、様々なプログラマによって書かれたので、コマンドライン上の入力パラメータ用のシンタクスは、あまり一貫していなかった。さらに、エラーが起きた場合、エラーメッセージは、同じエラーに対してさえも、コマンドの間であまり一貫していなかった。
たとえば、UNIX(登録商標)環境では、「ls」コマンドおよび「ps」コマンドの間には多くの不一致がある。両方ともオプション「−w」を受諾するが、「−w」オプションは、「ls」コマンドではページ幅を示すのに使われ、「−w」オプションは、「ps」コマンドでは幅のある出力の印刷を示すのに使われる(本質的に、ページ幅を無視する)。「ls」および「ps」コマンドに関連するヘルプページにもいくつかの不一致があり、たとえば、あるページではオプションをボールド体にしてあるが他のページではそうでなく、あるページではオプションをアルファベット順にソートしてあるが他のページではそうでなく、一部のオプションにはダッシュをつけさせるが一部のオプションにはつけない。
本管理用ツールフレームワークは、より一貫性がある手法を提供し、各開発者が書かなければならない重複コードの量を最小限にする。管理用ツールフレームワーク200は、開発者が管理用ツールフレームワーク200によって提供される共通機能を容易に利用することを可能にするためのシンタクス(たとえば文法)、対応するセマンティクス(たとえば辞書)、および参照モデルを提供する。
本発明をさらに説明する前に、本明細書を通して現れる追加用語の定義が与えられる。入力パラメータは、cmdlet用の入力フィールドを指す。引数は、argvアレイ中のただ1つの文字列の等価物であるcmdletに渡され、またはcmdletオブジェクト中のただ1つの要素として渡される入力パラメータを指す。後で説明されるように、cmdletは、文法を指定する機構を提供する。機構は、直接的にも間接的にも提供され得る。引数は、オプション、オプション引数、またはコマンド名に続くオペランドの1つである。引数の例が、次のコマンドラインに基づいて与えられる。
上記のコマンドラインにおいて、「findstr」は引数0であり、「/i」は引数1であり、「/d:¥winnt;¥winnt¥system32」は引数2であり、「aa*b」は引数3であり、「*.ini」は引数4である。「オプション」は、概してプログラムのデフォルト動作に対する変更を指定するのに使われる、cmdletへの引数である。上のコマンドラインの例で続けると、「/i」および「/d」がオプションである。オプション引数は、特定のオプションに続く入力パラメータである。一部の場合では、オプション引数は、オプションと同じ引数文字列に含まれる。それ以外の場合では、オプション引数は、次の引数として含まれる。再度上記のコマンドラインを参照すると、「winnt;¥winnt¥system32」がオプション引数である。「オペランド」は、概して、プログラム処理を完了するのに必要な情報をプログラムに供給するオブジェクトとして使われるcmdletへの引数である。オペランドは概して、コマンドライン中でオプションの後に続く。再度上のコマンドラインの例を参照すると、「aa*b」および「*.ini」がオペランドである。「解析可能ストリーム」は、引数を含む。
図13を参照すると、パーサ220は、解析可能ストリーム(たとえば、コマンド文字列1350)を構成要素1320〜1326(たとえば、where部分1322)に解析する。各部分1320〜1326は、cmdlet1330〜1336の1つに関連づけられる。パーサ220およびエンジン224は、解析、パラメータ認証、データ生成、パラメータ処理、パラメータエンコーディング、およびパラメータドキュメンテーションなど、様々な処理を実施する。パーサ220およびエンジン224は、コマンドライン上の入力パラメータに対して共通機能を実施するので、管理用ツールフレームワーク200は、一貫したエラーメッセージをユーザに発行することができる。
本発明による管理用ツールフレームワークに従って書かれた実行可能cmdlet1330〜1336は、従来の管理環境におけるコマンドより少ないコードを必要とすることが認識されよう。各実行可能cmdlet1330〜1336は、それぞれの構成要素1320〜1326を使って識別される。さらに、(矢印1340、1342、1344、および1346で表される)各実行可能cmdlet1330〜1336は、オブジェクトを出力し、こうした出力オブジェクトは、(矢印1341、1343、および1345で表される)入力オブジェクトとして次のパイプライン型cmdletに入力される。こうしたオブジェクトは、オブジェクトに参照(たとえばハンドル)を渡すことによって入力され得る。実行可能cmdlet1330〜1336は次いで、ハンドルを渡されたオブジェクトに対して追加処理を実施することができる。
図14は、図9に示される入力を操作するプロセスでの使用に適したコマンド文字列の処理をより詳しく示す論理フロー図である。コマンド文字列処理は、ブロック1401で始まり、ここで、パーサまたはスクリプトエンジンが、入力中のコマンド文字列を識別している。概して、コアエンジンは、cmdletのデータフローに対してセットアップおよび順序付けを実施する。1つのcmdlet用のセットアップおよび順序付けは、後で説明されるが、パイプライン中の各cmdletに適用可能である。処理は、ブロック1404で継続する。
ブロック1404で、cmdletが識別される。cmdletの識別は、登録を介し得る。コアエンジンは、cmdletがローカルであるか、それともリモートであるか判定する。cmdletは、1)管理用ツールフレームワークのアプリケーションドメイン内部、2)管理用ツールフレームワークと同じプロセスの別のアプリケーションドメイン内部、3)同じコンピューティングデバイス上の別のプロセス中、または4)リモートコンピューティングデバイス内部で実行され得る。同じプロセス中で動作しているcmdletの間の通信は、オブジェクトを介する。異なるプロセス中で動作しているcmdletの間の通信は、直列構造データ形式による。例示的な一直列構造データ形式は、拡張マークアップ言語(XML)に基づく。処理は、ブロック1406で継続する。
ブロック1406で、cmdletオブジェクトのインスタンスが作成される。cmdletのインスタンスを作成する例示的なプロセスが、後で図15とともに説明される。cmdletオブジェクトが作成されると、処理は、ブロック1408で継続する。
ブロック1408で、cmdletオブジェクトに関連づけられたプロパティが投入される。上述したように、開発者は、cmdletクラスの中、または外部ソースの中でプロパティを宣言する。簡潔には、管理用ツールフレームワークは、プロパティに対して宣言される名称およびタイプに基づいて、受信オブジェクト(群)を解読し、cmdletクラスからインスタンス化されたcmdletにする。タイプが異なる場合、タイプは、拡張データ型マネージャを介して強制的に変換され得る。前述されたように、パイプライン型コマンド文字列において、各cmdletの出力は、オブジェクトへのハンドルのリストとなり得る。次のcmdletは、このオブジェクトハンドルリストを入力し、処理を実施し、オブジェクトハンドルの別のリストを次のcmdletに渡す。さらに、図7に示されるように、入力パラメータは、コマンドラインから届くものとして指定され得る。cmdletに関連するプロパティを投入する例示的な一方法が、後で図16とともに説明される。cmdletが投入を行われると、処理は、ブロック1410で継続する。
ブロック1410で、cmdletが実行される。概して、cmdletによって提供される処理は、少なくとも一度実施され、これは、cmdletへの各入力オブジェクトの処理を含む。したがって、cmdletがパイプライン型コマンド文字列中の第1のcmdletである場合、処理は一度実行される。後続cmdletについては、処理は、cmdletに渡される各オブジェクトごとに実行される。cmdletを実行する例示的な一方法が、後で図5とともに説明される。入力パラメータが、コマンドラインからのみ届いている場合、cmdletの実行は、基本cmdletケースによって提供されるデフォルトメソッドを用いる。cmdletが実行を終了されると、処理はブロック1412へ進む。
ブロック1412で、cmdletがクリーンアップされる。クリーンアップは、メモリの割振り解除などを担当する、関連するcmdletオブジェクト用デストラクタ(destructor)のコールを含む。コマンド文字列の処理は次いで、完了する。
(cmdletオブジェクトを作成する例示的なプロセス)
図15は、図14に示されるコマンド文字列処理での使用に適した、cmdletを作成する例示的なプロセスを示す論理フロー図である。この時点で、cmdletデータ構造が開発されており、属性および予想される入力パラメータが指定されている。cmdletは、コンパイルされ登録されている。登録の間、クラス名(すなわち、cmdlet名)が登録ストアに書き込まれ、cmdletに関連づけられたメタデータが格納されている。プロセス1500は、ブロック1501で始まり、ここで、パーサは、cmdletを示す入力(たとえばキーストローク)を受け取っている。パーサは、レジストリ中から入力をルックアップし、登録されたcmdletの1つに入力を関連づけることによって、入力をcmdletとして認識し得る。処理はブロック1504へ進む。
図15は、図14に示されるコマンド文字列処理での使用に適した、cmdletを作成する例示的なプロセスを示す論理フロー図である。この時点で、cmdletデータ構造が開発されており、属性および予想される入力パラメータが指定されている。cmdletは、コンパイルされ登録されている。登録の間、クラス名(すなわち、cmdlet名)が登録ストアに書き込まれ、cmdletに関連づけられたメタデータが格納されている。プロセス1500は、ブロック1501で始まり、ここで、パーサは、cmdletを示す入力(たとえばキーストローク)を受け取っている。パーサは、レジストリ中から入力をルックアップし、登録されたcmdletの1つに入力を関連づけることによって、入力をcmdletとして認識し得る。処理はブロック1504へ進む。
ブロック1504で、cmdletオブジェクトクラスに関連づけられたメタデータが読み取られる。メタデータは、cmdletに関連づけられたディレクティブのいずれをも含む。ディレクティブは、cmdlet自体にも、パラメータの1つまたは複数にも適用し得る。cmdletの登録中、登録コードは、メタデータを永続ストアに登録する。メタデータは、シリアル化形式のXMLファイル、外部データベースなどに格納され得る。スクリプト処理中のディレクティブの処理と同様に、ディレクティブの各カテゴリーは、様々な段階で処理される。各メタデータディレクティブは、独自のエラー操作を扱う。処理は、ブロック1506で継続する。
ブロック1506で、識別されたcmdletクラスに基づいてcmdletオブジェクトがインスタンス化される。処理は、ブロック1508で継続する。
ブロック1508で、cmdletについての情報が入手される。情報入手は、リフレクションまたは他の手段を介して起こり得る。情報は、予想される入力パラメータに関するものである。上述したように、パブリック宣言されるパラメータ(たとえば、public string Name730)は、コマンドライン上のコマンド文字列中で指定されることも入力ストリーム中で与えられることもできる、予想される入力パラメータに対応する。図18で説明される、拡張タイプマネージャによる管理用ツールフレームワークは、(必要に応じて)コール側に情報を返す共通インターフェイスを提供する。処理は、ブロック1510で継続する。
ブロック1510で、使用可能性ディレクティブ(たとえば、テーブル1)が適用される。使用可能性ディレクティブは、クラスが特定のマシン役割および/またはユーザ役割において使われることを保証する。たとえば、特定のcmdletは、ドメイン管理者によってのみ使われ得る。使用可能性ディレクティブの1つにおいて指定された制約が満たされない場合、エラーが起こる。処理は、ブロック1512で継続する。
ブロック1512で、メタデータが、インテリセンスを提供するのに使われる。処理のこの時点で、コマンド文字列全体は、まだ入力されていない。しかし、管理用ツールフレームワークは、使用可能なcmdletを知っている。cmdletが判別されると、管理用ツールフレームワークは、cmdletオブジェクトをリフレクトすることによって、許可される入力パラメータを知る。したがって、管理用ツールフレームワークは、cmdlet名のあいまい性排除部分が与えられるとcmdletを自動補完し、次いで、入力パラメータのあいまい性排除部分がコマンドライン上でタイプされると入力パラメータを自動補完することができる。自動補完は、入力パラメータの部分が入力パラメータの1つを明確に識別できるとすぐに起こり得る。さらに、自動補完は、cmdlet名およびオペランドに対しても起こり得る。処理は、ブロック1514で継続する。
ブロック1514で、プロセスは、cmdlet用の入力パラメータが入力されるまで待機する。この待機は、リターンキーを打つことなどによって、ユーザがコマンド文字列の終わりを示すと起こり得る。スクリプト中では、新規行が、コマンド文字列の終わりを示す。この待機は、パラメータに関する付加情報のユーザからの入手、および他のディレクティブの適用を含み得る。cmdletがパイプライン型パラメータの1つである場合、処理は直ちに始まり得る。必要なコマンド文字列および入力パラメータが与えられると、処理は完了する。
(cmdletに投入を行う例示的なプロセス)
cmdletに投入を行う例示的なプロセスが、図16に示され、図5とともに次に説明される。例示的な一管理用ツールフレームワークにおいて、コアエンジンは、cmdlet用パラメータを投入するための処理を実施する。処理は、cmdletのインスタンスが作成された後、ブロック1601で始まる。処理は、ブロック1602へ続く。
cmdletに投入を行う例示的なプロセスが、図16に示され、図5とともに次に説明される。例示的な一管理用ツールフレームワークにおいて、コアエンジンは、cmdlet用パラメータを投入するための処理を実施する。処理は、cmdletのインスタンスが作成された後、ブロック1601で始まる。処理は、ブロック1602へ続く。
ブロック1602で、cmdlet内部で宣言されたパラメータ(たとえば、ProcessName)が取得される。cmdletを用いた宣言に基づいて、コアエンジンは、受信入力オブジェクトが、「ProcessName」という名前のプロパティを提供すると認識する。受信プロパティのタイプが、パラメータ宣言で指定されたタイプと異なる場合、タイプは、拡張タイプマネージャにより強制的に変換される。データ型を強制的に変換するプロセスは、後で「例示的な拡張タイプマネージャ処理」というサブセクションで説明される。処理は、ブロック1603へ続く。
ブロック1603で、パラメータに関連づけられた属性が取得される。属性は、パラメータ用の入力ソースがコマンドラインであるかどうか、または入力がパイプラインからであるかどうかを識別する。処理は、判断ブロック1604へ続く。
判断ブロック1604で、属性が入力ソースをコマンドラインとして指定しているかどうか、判定が行われる。入力ソースがコマンドラインの場合、処理は、ブロック1609で継続する。コマンドラインでない場合、処理は、判断ブロック1605で継続する。
判断ブロック1605で、宣言において指定されたプロパティ名が使われるべきかどうか、またはプロパティ名に対するマッピングが使われるべきかどうか判定が行われる。この判定は、コマンド入力が、パラメータに対してマッピングを指定したかどうかに基づく。次の行は、受信オブジェクトの「foo」メンバへの、パラメータ「ProcessName」の例示的なマッピングを示す。
$ get/process | where han* -gt 500 | stop/process -ProcessName<-foo
$ get/process | where han* -gt 500 | stop/process -ProcessName<-foo
処理は、ブロック1606で継続する。
ブロック1606で、マッピングが適用される。マッピングは、予想されるパラメータの名称を、「ProcessName」から「foo」に置き換え、置き換えられた後の名称は次いで、コアエンジンによって、受信オブジェクトを解析し、予想される正しいパラメータを識別するのに使われる。処理は、ブロック1608で継続する。
ブロック1606で、マッピングが適用される。マッピングは、予想されるパラメータの名称を、「ProcessName」から「foo」に置き換え、置き換えられた後の名称は次いで、コアエンジンによって、受信オブジェクトを解析し、予想される正しいパラメータを識別するのに使われる。処理は、ブロック1608で継続する。
ブロック1608で、拡張タイプマネージャは、パラメータ用の値を受信オブジェクト中に配置するために問合せを受ける。拡張タイプマネージャとともに説明したように、拡張タイプマネージャは、パラメータ名を受け取り、リフレクションを用いて、パラメータ名を有する受信オブジェクト中でパラメータを識別する。拡張タイプマネージャは、必要な場合、パラメータに対して他の処理も実施することができる。たとえば、拡張タイプマネージャは、上述された変換機構により、データのタイプを、予想されるデータ型に強制的に変換することができる。処理は、判断ブロック1610へ続く。
ブロック1609に戻ると、属性が、入力ソースがコマンドラインであると指定している場合、コマンドラインからのデータが入手される。コマンドラインからのデータの入手は、拡張タイプマネージャを介して実施され得る。処理は次いで、判断ブロック1610へ続く。
判断ブロック1610で、予想される別のパラメータがあるかどうか、判定が行われる。予想される別のパラメータがある場合、処理は、ブロック1602にループバックし、上述されたように進行する。別のパラメータがない場合、処理は完了し、戻る。
したがって、説明されたように、cmdletは、受信データを分解して、予想されるパラメータを入手するテンプレートとして作用する。さらに、予想されるパラメータは、予想されるパラメータの値を提供する受信オブジェクトのタイプを知らなくても入手される。これは、従来の管理環境と大きく異なる。従来の管理環境は、密束縛され、オブジェクトのタイプがコンパイル時に知られていることを要求する。さらに、従来の環境では、予想されるパラメータは、値または参照によって関数に渡されている。したがって、本発明による解析(たとえば「分解」)機構は、プログラマが、こうしたパラメータの値がどのようにして取得されるかを具体的に知ることを要せずに、パラメータのタイプを指定することを可能にする。
たとえば、cmdlet Fooに対して次の宣言が与えられる。
コマンドラインシンタクスは、次のいずれでもよい。
規則の組は、所望のシンタクスを提供するために、システム管理者によって修正され得る。さらに、パーサは、複数のシンタクスがユーザによって使われ得るように、複数の規則の組をサポートすることができる。本質的に、cmdlet構造(たとえば、string NameおよびBool Recurse)に関連づけられた文法が、パーサを駆動する。
概して、解析ディレクティブは、コマンド文字列として入力されたパラメータが、cmdletオブジェクト中で識別される、予想されるパラメータにどのようにしてマップするべきかを記述する。入力パラメータタイプは、正しいかどうか判定するために調べられる。入力パラメータタイプが正しくない場合、入力パラメータは、正しくなるように強制的に変換され得る。入力パラメータタイプが正しくなく、強制的に変換されることもできない場合、使用上のエラーが印字される。使用上のエラーは、期待される正しいシンタクスをユーザに気づかせる。使用上のエラーは、ドキュメンテーションディレクティブから、シンタクスを記述する情報を入手することができる。入力パラメータタイプがマッピングされるか、または認証されると、cmdletオブジェクトインスタンス中の対応するメンバが投入される。メンバが投入されるとき、拡張タイプマネージャは、入力パラメータタイプの処理をもたらす。簡潔には、処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ機構、関係機構、およびプロパティセット機構を含み得る。こうした機構はそれぞれ、後で、説明のための例も含む「拡張タイプマネージャ処理」というセクションで詳しく説明される。
(cmdletを実行する例示的なプロセス)
cmdletを実行する例示的なプロセスが図17に示され、次に説明される。例示的な一管理用ツール環境において、コアエンジンは、cmdletを実行する。上述したように、第2のメソッド540内部のコード542が、各入力オブジェクトに対して実行される。処理は、ブロック1701で始まり、ここで、cmdletは既に投入を受けている。処理は、ブロック1702で継続する。
cmdletを実行する例示的なプロセスが図17に示され、次に説明される。例示的な一管理用ツール環境において、コアエンジンは、cmdletを実行する。上述したように、第2のメソッド540内部のコード542が、各入力オブジェクトに対して実行される。処理は、ブロック1701で始まり、ここで、cmdletは既に投入を受けている。処理は、ブロック1702で継続する。
ブロック1702で、コード542にあるステートメントが、実行のために取得される。処理は、判断ブロック1704で継続する。
判断ブロック1704で、ステートメント中にフックが含まれるかどうか、判定が行われる。一時的に図5に移ると、フックは、コアエンジンによって提供されるAPIのコールを含み得る。たとえば、図5のcmdlet500のコード542中のステートメント550は、必要なパラメータ、第1の文字列(たとえば、「PID=」)、およびパラメータ(たとえば、PID)を指定するconfirmprocessing APIをコールする。図17に戻ると、ステートメントがフックを含む場合、処理は、ブロック1712へ続く。したがって、confirmprocessing APIをコールする命令が指定された場合、cmdletは、動作環境によって提供される代替実行モードで動作する。それ以外の場合、処理は、ブロック1706で継続し、実行は、「ノーマル」モードで継続する。
ブロック1706で、ステートメントが処理される。処理は次いで、判断ブロック1708へ進む。ブロック1708で、コードが別のステートメントを含むかどうか、判定が行われる。別のステートメントがある場合、処理は、ブロック1702にループバックして、次のステートメントを入手し、上述されたように進行する。別のステートメントがない場合、処理は判断ブロック1714へ続く。
判断ブロック1714で、処理すべき別の入力オブジェクトがあるかどうか、判定が行われる。別の入力オブジェクトがある場合、処理は、ブロック1716へ続き、ここで、cmdletは、次のオブジェクトからのデータを投入される。図16で説明される投入プロセスが、次のオブジェクトで実施される。処理は次いで、ブロック1702にループバックし、上述されたように進行する。オブジェクトすべてが処理されると、cmdlet実行プロセスは完了し、戻る。
判断ブロック1704に戻ると、ステートメントがフックを含む場合、処理は、ブロック1712へ続く。ブロック1712で、管理用ツール環境によってもたらされる追加特徴が処理される。処理は、判断ブロック1708で継続し、上述されたように継続する。
ブロック1712において実施される追加処理が、次に、図6に示される例示的なデータ構造600とともに説明される。上で説明されたように、コマンド基本クラス600中には、予想される追加入力パラメータ(たとえばスイッチ)に対応すると宣言したパラメータが存在し得る。
スイッチは、所定の文字列を含み、認識されると、cmdletに付加機能を提供するよう、コアエンジンに指図する。パラメータverbose610が、コマンド入力中で指定された場合、verboseステートメント614が実行される。以下は、verboseスイッチを含むコマンドラインの例である。
概して、「-verbose」が、コマンド入力中で指定された場合、コアエンジンは、各入力オブジェクトに対してコマンドを実行し、表示のために各入力オブジェクトごとにホストプログラムに対して実行された実際のコマンドを転送する。以下は、上記のコマンドラインが例示的な管理用ツール環境において実行されたときに生成される出力の例である。
パラメータwhatif620がコマンド入力中で指定された場合、whatifステートメント624が実行される。以下は、whatifスイッチを含むコマンドラインの例である。
概して、「−whatif」が指定されると、コアエンジンは、実際にはコード542を実行するのではなく、表示のためにホストプログラムに対して実行されているはずのコマンドを送る。以下は、本発明の例示的な管理用ツール環境において上記のコマンドラインが実行されたときに生成される出力の例である。
パラメータconfirm630がコマンド入力中で指定された場合、confirmステートメント634が実行される。以下は、confirmスイッチを含むコマンドラインの例である。
概して、「−confirm」が指定されると、コアエンジンは、コマンドを進めるかどうかに関して、追加ユーザ入力を要求する。以下は、本発明の例示的な管理用ツール環境において上記のコマンドラインが実行されたときに生成される出力の例である。
上述したように、例示的なデータ構造600は、実行に対して要求されているタスクが許可されるべきかどうか判定するセキュリティメソッド640も含み得る。従来の管理環境では、各コマンドは、コマンドを実行している人がコマンドを実施するのに十分な特権を有しているかどうかのチェックを担当する。このチェックを実施するために、いくつかのソースからの情報にアクセスするのに、拡張コードが必要とされる。こうした複雑さのせいで、多くのコマンドは、セキュリティチェックを実施しなかった。本管理用ツール環境の発明者は、タスクがコマンド入力中で指定されると、セキュリティチェックの実施に必要な情報が管理用ツール環境において利用可能であると認識した。したがって、管理用ツールフレームワークは、ツール開発者に対して複雑なコードを要求せずにセキュリティチェックを実施する。セキュリティチェックは、cmdlet中でフックを定義するどのcmdletに対しても実施され得る。あるいは、フックは、上述されたverboseパラメータと同様に、コマンド入力中で指定され得る任意選択の入力パラメータでもよい。
セキュリティチェックは、概してユーザの役割に基づいて、どのユーザがリソースへのアクセス権をもつかをコントロールするシステムとして定義される、役割ベースの認証をサポートするように実装される。したがって、各役割は、異なるリソースへの特定のアクセス権を割り当てられる。ユーザは次いで、1つまたは複数の役割に割り当てられる。概して、役割ベースの認証は、3つの項目、すなわち原理、リソース、およびアクションに注目する。リソースに対してアクションが実施されるよう要求したのは誰かを、原理が識別する。
本発明の発明者は、要求されているcmdletが、実施されるべきアクションに対応することを認識した。さらに、本発明者は、管理用ツールフレームワークが実行されているプロセスの所有者が、原理に対応することを認識した。さらに、本発明者は、リソースがcmdlet中で指定されることを認識した。したがって、管理用ツールフレームワークは、こうした項目へのアクセス権をもっているので、本発明者は、セキュリティチェックは、ツール開発者がセキュリティチェックを実装することを要せずに管理用ツールフレームワーク内部から実施され得ることを認識した。
セキュリティチェックの動作は、confirmprocessing APIなどのフックを用いることによって、cmdlet内部で付加機能が要求されるといつでも実施され得る。あるいは、セキュリティチェックは、verbose、whatif、およびconfirmと同様にコマンドライン上でセキュリティスイッチが入れられたかどうか調べることによっても、実施され得る。いずれの実装の場合でも、checkSecurityメソッドは、誰が許可されるかを判定する1組のAPIを提供するセキュリティプロセス(図示せず)によって提供されるAPIをコールする。セキュリティプロセスは、管理用ツールフレームワークによって提供される情報を受け取り、タスクが完了され得るかどうかを示す結果をもたらす。管理用ツールフレームワークは次いで、エラーをもたらしても、単にタスクの実行を停止してもよい。
したがって、cmdlet中でフックを提供することによって、開発者は、管理用ツールフレームワークによって提供される追加処理を使うことができる。
(例示的な拡張タイプマネージャ処理)
図18とともに上で簡潔に述べられたように、拡張タイプマネージャは、供給されるオブジェクトに対して追加処理を実施することができる。追加処理は、パーサ220、スクリプトエンジン222、またはパイプラインプロセッサ402からの要求時に実施され得る。追加処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ機構、関係機構、およびプロパティセット機構を含む。拡張タイプマネージャは、特許請求の範囲に記載されている本発明の範囲から逸脱することなく、他の処理を用いても拡張され得ることを当業者は理解するであろう。追加処理機構がそれぞれ、次に説明される。
図18とともに上で簡潔に述べられたように、拡張タイプマネージャは、供給されるオブジェクトに対して追加処理を実施することができる。追加処理は、パーサ220、スクリプトエンジン222、またはパイプラインプロセッサ402からの要求時に実施され得る。追加処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバ機構、関係機構、およびプロパティセット機構を含む。拡張タイプマネージャは、特許請求の範囲に記載されている本発明の範囲から逸脱することなく、他の処理を用いても拡張され得ることを当業者は理解するであろう。追加処理機構がそれぞれ、次に説明される。
最初に、プロパティパス機構が、文字列に、オブジェクトのプロパティをナビゲートさせる。現在のリフレクションシステムでは、クエリは、オブジェクトのプロパティを照会することができる。しかし、本発明による拡張タイプマネージャでは、オブジェクトの一連のプロパティへのナビゲーションパスを提供する文字列が指定され得る。プロパティパスの例示的なシンタクスは、P1.P2.P3.P4である。
各コンポーネント(たとえば、P1、P2、P3、およびP4)は、プロパティ、パラメータを有するメソッド、パラメータをもたないメソッド、フィールド、XPATHなどを表し得る文字列を含む。XPATHは、要素(たとえば、「/FOO@=13」)を検索するためのクエリ文字列を指定する。文字列には、コンポーネントのタイプを具体的に示すための特殊文字が含まれ得る。文字列が特殊文字を含まない場合、拡張タイプマネージャは、コンポーネントのタイプを判定するためのルックアップを実施し得る。たとえば、コンポーネントP1がオブジェクトの場合、拡張タイプマネージャは、P2が、オブジェクトのプロパティ、オブジェクトのメソッド、オブジェクトのフィールド、またはプロパティセットであるか照会し得る。拡張タイプマネージャが、P2のタイプを識別すると、そのタイプに従った処理が実施される。コンポーネントが、上記のタイプの1つでない場合、拡張タイプマネージャは、拡張ソースをさらに照会して、P1タイプをP2タイプに変換するための変換関数が存在するかどうか判定することができる。こうしたおよび他のルックアップが、例示的なコマンド文字列を使い、それぞれの出力を示して次に説明される。
以下は、プロパティパスを含む例示的な文字列である。
$ get/process | /where hand* -gt> 500 | format/table name.toupper, ws.kb, exe*.ver*.description.tolower.trunc(30)
$ get/process | /where hand* -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」によって生成され、次いで、様々なcmdletを介してパイプライン処理される受信オブジェクトの直接プロパティであることに留意すべきである。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(30)」)に対して、この同じルックアップ機構を実施する。したがって、説明されたように、拡張タイプマネージャは、管理者が具体的なコードを何も書く必要なく、コマンド文字列に対して極めて入念な処理を実施することができる。テーブル1は、例示的な文字列に対して生成される出力を示す。
別のクエリ機構1824は、キーを含む。キーは、データ型のインスタンスを一義的にする1つまたは複数のプロパティを識別する。たとえば、データベース中で、ある列が、各行を一義的に識別し得るキー(たとえば、社会保障番号)として識別され得る。キーは、データ型に関連づけられたタイプメタデータ1840に格納される。このキーは次いで、そのデータ型のオブジェクトを処理するときに拡張タイプマネージャによって使われ得る。データ型は、拡張データ型でも、既存のデータ型でもよい。
別のクエリ機構1824は、比較機構を含む。比較機構は、2つのオブジェクトを比較する。2つのオブジェクトが、比較関数を直接サポートする場合、直接サポートされる比較関数が実行される。しかし、どちらのオブジェクトも比較関数をサポートしない場合、拡張タイプマネージャは、タイプメタデータの中で、2つのオブジェクトの比較をサポートするために登録されているコードを探し得る。比較機構を伴う例示的な一連のコマンドライン文字列が、テーブル2の中の対応する出力とともに下に示されている。
compare/time cmdletは、2つのdatetimeオブジェクトを比較するために書かれる。この場合、DateTimeオブジェクトは、IComparableインターフェイスをサポートする。
別のクエリ機構1824は、変換機構を含む。拡張タイプマネージャは、具体的な変換を実施する機能を言明するコードを登録させる。次いで、タイプAのオブジェクトが入力されるとともにcmdletがタイプBのオブジェクトを指定すると、拡張タイプマネージャは、登録された変換の1つを用いて変換を実施し得る。拡張タイプマネージャは、タイプAをタイプBに強制的に変換するために、一連の変換を実施し得る。上述されたプロパティパス(「ws.kb」)は、変換機構を示す。
別のクエリ機構1824は、グロバ機構を含む。グロバは、文字列中のワイルドカード文字を指す。グロバ機構は、ワイルドカード文字を有する文字列を入力し、1組のオブジェクトを生じる。拡張タイプマネージャは、ワイルドカード処理を指定するコードを登録させる。上述されたプロパティパス(「exe*.ver*.description.tolower.trunc(30))は、グロバ機構を示す。登録されたプロセスは、ファイル名、ファイルオブジェクト、受信プロパティなどに対してグロビングを提供し得る。
別のクエリ機構1824は、プロパティセット機構を含む。プロパティセット機構は、1組のプロパティ用の名称を定義させる。管理者は次いで、コマンド文字列中で名称を指定して、プロパティの組を入手することができる。プロパティセットは、様々な方式で定義され得る。一方式では、「?」など、予め定義されたパラメータが、cmdlet用の入力パラメータとして入力され得る。動作環境は、予め定義されたパラメータを認識すると、受信オブジェクトのプロパティすべてを列挙する。リストは、管理者が、望まれるプロパティを容易にチェックする(たとえば、「クリックする」)とともにプロパティセットに名前をつけることを可能にするGUIでよい。プロパティセット情報は次いで、拡張メタデータに格納される。プロパティセット機構を呼び出す例示的な文字列が、テーブル3の対応する出力とともに下に示されている。
この例示的な文字列では、「config」というプロパティセットが、名称プロパティ、プロセスidプロパティ(Pid)、および優先度プロパティを含むように定義されている。このテーブル用の出力が次に示される。
別のクエリ機構1824は、関係機構を含む。1つの関係(すなわち、継承)をサポートする従来型システムとは対照的に、関係機構は、タイプの間の複数の関係の表現をサポートする。やはり、こうした関係も登録される。関係は、オブジェクトが使用する項目を見つけることも、オブジェクトを使用する項目を見つけることも含み得る。拡張タイプマネージャは、様々な関係を記述する存在論(オントロジー)にアクセスし得る。拡張メタデータおよびコードを用いて、どのオントロジーサービスにも、たとえばOWL、DAWLなどにアクセスする仕様が記述され得る。.OWL:”string”が、関係機構を使用する例示的な文字列の一部分である。
「OWL」識別子は、オントロジーサービスを識別し、「string」は、オントロジーサービスにおける具体的な文字列を指定する。したがって、拡張タイプマネージャは、オントロジーサービスによって供給されるタイプにアクセスし得る。
コマンドラインデータを表示する例示的なプロセス
本機構は、データ駆動コマンドライン出力を提供する。データのフォーマット化および出力は、cmdletからなるパイプライン中の1つまたは複数のcmdletによって実現される。通常、こうしたcmdletは、上で図2とともに説明された非管理cmdletに含まれる。cmdletは、フォーマットcmdlet、マークアップcmdlet、変換cmdlet、変形cmdlet、およびアウトcmdletを含み得る。
本機構は、データ駆動コマンドライン出力を提供する。データのフォーマット化および出力は、cmdletからなるパイプライン中の1つまたは複数のcmdletによって実現される。通常、こうしたcmdletは、上で図2とともに説明された非管理cmdletに含まれる。cmdletは、フォーマットcmdlet、マークアップcmdlet、変換cmdlet、変形cmdlet、およびアウトcmdletを含み得る。
図19は、パイプライン中のこうしたcmdletの例示的なシーケンス1901〜1907を図表により示す。第1のシーケンス1901は、パイプライン中の最後のcmdletとしてアウトcmdlet1910を示す。他のcmdletに対して上述されたのと同じやり方で、アウトcmdlet1910は、パイプライン中の他のcmdletによって生成され処理されたパイプラインオブジェクトのストリームを受諾する。ただし、ほとんどのcmdletとは対照的に、アウトcmdlet1910は、他のcmdlet用にパイプラインオブジェクトを送出しない。そうではなく、アウトcmdlet1910は、パイプラインによって生成された結果のレンダリング/表示を担当する。各アウトcmdlet1910は、デバイス、プログラムなど、出力の宛先に関連づけられる。たとえば、コンソールデバイスに対して、アウトcmdlet1910は、out/consoleとして指定されることができ、インターネットブラウザに対して、アウトcmdlet1910は、out/browserとして指定されることができ、ウィンドウに対して、アウトcmdlet1910は、out/windowとして指定されることができる。具体的な各アウトcmdletは、それに関連づけられた宛先の機能を熟知しいている。変換cmdletがパイプライン中でアウトcmdletに先行しない限り、ロケール情報(たとえば、日付および通貨フォーマット)がアウトcmdlet1910によって処理される。この状況において、変換cmdletは、ロケール情報を処理した。
各ホストは、out/consoleなど、特定のアウトcmdletのサポートを担当する。ホストは、どの宛先固有ホストcmdlet(たとえば、表計算アプリケーションによって提供されるチャートに出力を向けるout/chart)もサポートする。さらに、ホストは、結果のデフォルト操作の提供を担当する。このシーケンス中のアウトcmdletは、他の出力処理cmdlet(形式/マークアップ/変換/変形など)をコールすることによって、その行動の実装を決定し得る。したがって、アウトcmdletは、シーケンス1901を他のシーケンスのいずれにも暗黙的に変更することもでき、それ自体の追加形式/出力cmdletを追加することもできる。
第2のシーケンス1902は、アウトcmdlet1910の前にフォーマットcmdlet1920を示す。このシーケンスに対して、フォーマットcmdlet1920は、パイプライン中の他のcmdletによって生成され処理されたパイプラインオブジェクトのストリームを受諾する。概して、フォーマットcmdlet1920は、表示プロパティを選択するための方式と、ページレイアウト、たとえば形状、列の幅、ヘッダー、フッターなどを指定するための方式とを提供する。形状は、テーブル、ワイドリスト、縦書きリストなどを含み得る。さらに、フォーマットcmdlet1920は、総計または合計の計算を含み得る。フォーマットcmdlet1920によって実施される例示的な処理が、後で図20とともに説明される。簡潔には、フォーマットcmdletは、パイプラインオブジェクトの送出に加えて、フォーマットオブジェクトを送出する。フォーマットオブジェクトは、拡張タイプマネージャまたは他の機構を介してアウトcmdlet(たとえば、シーケンス1902中のアウトcmdlet1920)によって、ダウンストリームと認識され得る。アウトcmdlet1920は、発せられるフォーマットオブジェクトの使用を選ぶこともでき、こうしたオブジェクトの無視を選ぶこともできる。アウトcmdletは、表示情報において指定されたページレイアウトデータに基づいて、ページレイアウトを決定する。特定の例において、ページレイアウトに対する修正は、アウトcmdletによって指定され得る。例示的な一プロセスにおいて、アウトcmdletは、所定のいくつかのオブジェクトの各プロパティに対する最大長(たとえば50)を見つけることによって未指定の列幅を判定し、列幅を最大長に設定することができる。フォーマットオブジェクトは、フォーマット情報、ヘッダー/フッター情報などを含む。
第3のシーケンス1903は、アウトcmdlet1910の前にフォーマットcmdlet1920を示す。ただし、第3のシーケンス1903において、マークアップcmdlet1930が、フォーマットcmdlet1920とアウトcmdlet1910の間にパイプライン処理される。マークアップcmdlet1930は、選択されたパラメータにプロパティ注釈(たとえば、フォント、色)を追加する機構を提供する。したがって、マークアップcmdlet1930は、出力cmdlet1910の前に現れる。プロパティ注釈は、「プロパティバッグに影をつける」を用いて、またはプロパティバッグ中のカスタム名前空間中のプロパティ注釈を追加することによって実装され得る。マークアップcmdlet1930は、フォーマットcmdlet1920の処理の間、マークアップ注釈が維持され得る限り、フォーマットcmdlet1920の前に現れ得る。
第4のシーケンス1904もやはり、アウトcmdlet1910の前にフォーマットcmdlet1920を示す。ただし、第4のシーケンス1904において、変換cmdlet1940が、フォーマットcmdlet1920とアウトcmdlet1910の間にパイプライン処理される。変換cmdlet1940も、フォーマットcmdlet1920によって発せられるフォーマットオブジェクトを処理するように構成される。変換cmdlet1940は、フォーマットオブジェクトに基づいて、パイプラインオブジェクトを固有エンコーディングに変換する。変換cmdlet1940は、固有エンコーディングに関連づけられる。たとえば、パイプラインオブジェクトをアクティブディレクトリオブジェクト(ADO)に変換する変換cmdlet1940は、コマンドライン上で「convert/ADO」として宣言され得る。同様に、パイプラインオブジェクトを、コンマで区切られた値(comma separate value、csv)に変換する変換cmdlet1940は、コマンドライン上で「convert/csv」として宣言され得る。変換cmdlet1940のいくつか(たとえば、convert/XMLおよびconvert/html)はブロッキングコマンドでよく、すなわち、変換を実行する前にパイプラインオブジェクトすべてが受け取られる。通常、アウトcmdlet1920は、フォーマットオブジェクトによって提供されるフォーマット情報を使うかどうか、判定することができる。ただし、変換cmdlet1920がアウトcmdlet1920の前に現れる場合、アウトcmdletがオブジェクトを受け取る前に実際のデータ変換が既に起こっている。したがって、この状況において、アウトcmdletは、変換を無視することができない。
第5のシーケンス1905は、フォーマットcmdlet1920、マークアップcmdlet1930、変換cmdlet1940、およびアウトcmdlet1910をこの順序で示す。したがって、この順序は、マークアップcmdlet1930が変換cmdlet1940の前に現れ得ることを示す。
第6のシーケンス1906は、フォーマットcmdlet1920、固有の変換cmdlet(たとえば、convert/xml cmdlet1940’)、固有の変形cmdlet(たとえば、transform/xslt cmdlet1950)、およびアウトcmdlet1910を示す。convert/XML cmdlet1940’は、パイプラインオブジェクトを、拡張マークアップ言語(XML)に変換する。transform/xslt cmdlet1950は、拡張スタイル言語(XSL)スタイルシートを使って、XMLドキュメントを別のXMLドキュメントに変形する。変形プロセスは一般に、拡張スタイル言語変換(XSLT)と呼ばれ、XSLTにおいて、XSLプロセッサは、XMLドキュメントを読み、XSLスタイルシート中の命令に従って、新規XMLドキュメントを作成する。
第7のシーケンス1907は、フォーマットcmdlet1920、マークアップcmdlet1930、固有の変換cmdlet(たとえば、convert/xml cmdlet1940’)、固有の変形cmdlet(たとえば、transform/xslt cmdlet1950)、およびアウトcmdlet1910を示す。したがって、第7のシーケンス1907は、変換cmdletおよび変形cmdletの上流にあるマークアップcmdlet1930を有することを示す。
図20は、フォーマットcmdletによって実施される例示的な処理2000を示す。フォーマットプロセスは、フォーマットcmdletが、上述されたやり方でパーサおよびパイプラインプロセッサによって解析され呼び出された後、ブロック2001で始まる。処理は、ブロック2002で継続する。
ブロック2002で、パイプラインオブジェクトが、フォーマットcmdletへの入力として受け取られる。処理は、ブロック2004で継続する。
ブロック2004で、パイプラインオブジェクトのタイプを識別するためのクエリが開始される。このクエリは、図18とともに上述されたように、拡張タイプマネージャによって実施される。拡張タイプマネージャがオブジェクトのタイプを識別すると、処理は、ブロック2006で継続する。
ブロック2006で、識別されたタイプが表示情報中でルックアップされる。表示情報の例示的な形式は、図21に示され、後で説明される。処理は、判断ブロック2008で継続する。
判断ブロック2008で、識別されたタイプが、表示情報中で指定されているかどうか、判定が行われる。表示情報中に識別されたタイプのエントリがない場合、処理は完了する。エントリがある場合、処理は、ブロック2010で継続する。
ブロック2010で、識別されたタイプに関連づけられたフォーマット情報が、表示情報から入手される。処理は、ブロック2012で継続する。
ブロック2012で、パイプライン上で情報が発せられる。情報が発せられると、処理は完了する。
発せられ得る例示的な情報が、次にさらに詳しく説明される。情報は、フォーマット情報、ヘッダー/フッター情報、およびグループ終了/開始信号オブジェクトを含み得る。フォーマット情報は、形状、ラベル、番号づけ/点打ち、列の幅、キャラクタエンコードタイプ、内容フォントプロパティ、ページの長さ、プロパティ名によるグループ化などを含み得る。こうした情報はそれぞれ、関連づけられた追加仕様を有し得る。たとえば、形状は、形状が、テーブル、リストなどであるかを指定し得る。ラベルは、列ヘッダー、リストラベルなどを使うかどうかを指定し得る。キャラクタエンコードは、アスキー、UTF−8、Unicodeなどを指定し得る。内容フォントプロパティは、表示されるプロパティ値に適用されるフォントを指定し得る。デフォルトフォントプロパティ(たとえば、Courier New、10ポイント)は、内容フォントプロパティが指定されていない場合に使われ得る。
ヘッダー/フッター情報は、ヘッダー/フッタースコープ、フォントプロパティ、タイトル、サブタイトル、日付、時刻、ページ番号、分離記号などを含み得る。たとえば、スコープは、ドキュメント、ページ、グループなどを指定し得る。追加プロパティは、ヘッダーまたはフッターのどちらかに対して指定され得る。たとえば、グループおよびドキュメントのフッター用に、追加プロパティは、合計/総計を計算するためのプロパティまたは列、オブジェクトカウント、総計およびカウント用ラベル文字列などを含み得る。
グループ終了/開始信号オブジェクトは、フォーマットcmdletが、グループ化プロパティ(group-by property)が変わったことを検出したときに発せられる。これが起こると、フォーマットcmdletは、パイプラインオブジェクトのストリームを、予めソートされたものとして扱い、ソートし直さない。グループ終了/開始信号オブジェクトは、パイプラインオブジェクトとともに点在され得る。ネスト式ソート用に複数のグループ化プロパティが指定され得る。フォーマットcmdletは、最終合計および総計を含む形式終了オブジェクトを送出することもできる。
手短に図21に移ると、例示的な表示情報2100は、構造化形式であり、定義されている各オブジェクトに関連づけられた情報(たとえば、フォーマット情報、ヘッダー/フッター情報、グループ化プロパティまたはメソッド)を含む。たとえば、表示情報2100は、XMLベースでよい。上述されたプロパティはそれぞれ、次いで、表示情報中で指定され得る。表示情報2100中の情報は、入力されているオブジェクトタイプの所有者によって投入され得る。動作環境は、所有者が、エントリを作成し、消去し、修正することによって表示情報をアップデートすることを可能にする特定のAPIおよびcmdletを提供する。
図22は、特定のフォーマットcmdlet(たとえば、format/table、format/list、およびformat/wide)、マークアップcmdlet(たとえば、add/markup)、変換cmdlet(たとえば、convert/text、convert/sv、convert/csv、convert/ADO、convert/XML、convert/html)、変形cmdlet(たとえば、transform/XSLT)、ならびにアウトcmdlet(たとえば、out/console、out/file)用の例示的なシンタクス2201〜2213を列挙するテーブルである。図23は、出力処理cmdlet(たとえば、フォーマットcmdlet、変換cmdlet、およびマークアップcmdlet)の様々なパイプラインシーケンスを用いて、out/console cmdletによってレンダリングされる結果を示す。
説明されたように、コマンドライン命令に拡張機能を提供する機構は、管理用ツール環境において利用され得る。しかし、この機構は、コマンドライン命令を入力する様々な環境で利用され得ることを当業者は理解するであろう。たとえば、「whatif」機能は、「whatif」パラメータ用のコマンドラインを解析するとともにシミュレーションモード処理を実施するのに必要な命令を挿入することによって、スタンドアロン型コマンドに組み込まれ得る。コマンドライン命令に拡張機能を提供する本機構は、従来の機能拡張機構とは大きく異なる。たとえば、従来の機構では、拡張機能を望む各コマンドが、コマンドにコードを組み込まなければならなかった。次いで、コマンド自体が、コマンド文字列を解析して、スイッチ(たとえば、verbose、whatif)が提供されるかどうか判定し、それに従って拡張機能を実行しなければならなかった。対照的に本機構は、cmdletが拡張機能にフックを組み込む限り、ある特定のcmdlet用の拡張機能を実行するためにユーザがコマンド文字列中で引数を指定することを可能にする。したがって、本機構は、システム管理者が書く必要があるコードの量を最小限にする。さらに、本機構を用いることによって、統一されたやり方で拡張機能が実装される。
具体的な実装形態および実施形態の詳細が上述されたが、このような詳細は、添付の特許請求の範囲を限定することではなく、法定の開示義務を満たすことを意図する。したがって、特許請求の範囲によって定義される本発明は、上述された具体的な特徴に限定されない。そうではなく、本発明は、適正な添付の特許請求の範囲内である形または修正形態のいずれにおいても権利請求され、均等論の原則に従って適切に解釈される。
Claims (20)
- コマンドライン動作環境において、
第1の実行モードまたは代替実行モードで、コマンドライン上の各コマンドを実行することであって、前記代替実行モードでの前記コマンドの実行は、前記コマンドが、前記代替実行モードで実行する命令を含むときに起こり、前記代替実行モードは、前記動作環境によって提供されることを含むことを特徴とするコンピュータ実行可能方法。 - 前記代替実行モードは、前記コマンドの実行結果を視覚表示することを特徴とする請求項1に記載のコンピュータ実行可能方法。
- 前記代替実行モードは、前記コマンドの実行をシミュレートした結果を視覚表示することを特徴とする請求項1に記載のコンピュータ実行可能方法。
- 前記代替実行モードは、前記コマンドを実行する前に前記コマンドの実行の検証を促すことを特徴とする請求項1に記載のコンピュータ実行可能方法。
- 前記代替実行モードは、前記コマンドの実行を要求しているユーザが、前記コマンドを実行するのに十分な特権をもっているかどうか判定するためのセキュリティチェックを実施することを特徴とする請求項1に記載のコンピュータ実行可能方法。
- 前記代替実行モードでの前記コマンドの実行は、前記コマンドラインが、前記代替実行モードを指すスイッチを含むときにさらに起こることを特徴とする請求項1に記載のコンピュータ実行可能方法。
- 前記スイッチは、「whatif」を含み、前記代替実行モードは、前記コマンドの実行をシミュレートした結果を視覚表示することを特徴とする請求項6に記載のコンピュータ実行可能方法。
- 前記命令は、前記動作環境によって提供されるメソッドのコールを含むことを特徴とする請求項1に記載のコンピュータ実行可能方法。
- コンピュータ実行可能命令を有する少なくとも1つのコンピュータ可読媒体であって、前記命令は、
タスクの性能を指示するように動作可能なコマンドラインを受け取ること、
シミュレーションモードに関連づけられる前記コマンドラインにパラメータが存在するかどうか判定すること、
前記パラメータが存在する場合、前記タスクの性能をシミュレートすること、および
前記シミュレーションの結果を報告することを含む方法を実施することを特徴とするコンピュータ可読媒体。 - 前記パラメータは、スイッチを含むことを特徴とする請求項9に記載のコンピュータ可読媒体。
- 前記スイッチは、「whatif」を含むことを特徴とする請求項10に記載のコンピュータ可読媒体。
- 前記タスクは、スタンドアロン型実行可能コマンドを含むことを特徴とする請求項9に記載のコンピュータ可読媒体。
- 前記タスクは、実行可能コマンドからなるパイプラインを含み、各実行可能コマンドは、別個のプロセス中で動作することを特徴とする請求項9に記載のコンピュータ可読媒体。
- 前記タスクは、実行可能コマンドからなるパイプラインを含み、各実行可能コマンドは、同じプロセス中で動作することを特徴とする請求項9に記載のコンピュータ可読媒体。
- 各実行可能コマンドは、インスタンス化されたクラスを含むことを特徴とする請求項14に記載のコンピュータ可読媒体。
- コマンドライン動作環境を提供するシステムであって、
プロセッサと、
メモリとを備え、前記メモリは、前記プロセッサによる実行のために前記メモリにロードされる複数のコンピュータ実行可能命令用に割り振られ、前記コンピュータ実行可能命令は、
コマンドライン上で入力される各コマンドを実行することであって、前記コマンドが、前記動作環境によって提供される拡張機能を用いて、前記コマンドを実行させる命令を含む場合、前記コマンドの実行は、前記拡張機能を用いることを含む方法を実施することを特徴とするシステム。 - 前記拡張機能は、前記コマンドの実行結果を視覚表示することを含むことを特徴とする請求項16に記載のシステム。
- 前記拡張機能は、前記コマンドの実行をシミュレートした結果を視覚表示することを含むことを特徴とする請求項16に記載のシステム。
- 前記拡張機能は、前記コマンドを実行する前に検証を促すことを含むことを特徴とする請求項16に記載のシステム。
- 前記拡張機能は、前記コマンドの実行を要求しているユーザが、前記コマンドを実行するのに十分な特権をもっているかどうか判定するためのセキュリティチェックを実施することを含むことを特徴とする請求項16に記載のシステム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/693,409 US7640540B2 (en) | 2003-10-24 | 2003-10-24 | Mechanism for providing extended functionality to command line instructions |
PCT/US2004/023608 WO2005045565A2 (en) | 2003-10-24 | 2004-07-22 | Mechanism for providing extended functionality to command line instructions |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007509407A true JP2007509407A (ja) | 2007-04-12 |
Family
ID=34522388
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006536563A Pending JP2007509407A (ja) | 2003-10-24 | 2004-07-22 | コマンドライン命令への拡張機能を提供する機構 |
Country Status (11)
Country | Link |
---|---|
US (1) | US7640540B2 (ja) |
EP (1) | EP1588242A4 (ja) |
JP (1) | JP2007509407A (ja) |
KR (1) | KR101150059B1 (ja) |
CN (1) | CN101073057B (ja) |
AU (1) | AU2004279165B2 (ja) |
BR (1) | BRPI0406420A (ja) |
CA (1) | CA2501364C (ja) |
MX (1) | MXPA05006616A (ja) |
RU (1) | RU2395837C2 (ja) |
WO (1) | WO2005045565A2 (ja) |
Families Citing this family (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7594170B2 (en) * | 2003-10-24 | 2009-09-22 | Microsoft Corporation | Mechanism for providing data driven command line output |
WO2005106598A1 (ja) * | 2004-04-28 | 2005-11-10 | Canon Kabushiki Kaisha | トナー |
US7409532B2 (en) * | 2005-03-24 | 2008-08-05 | International Business Machines Corporation | Method and apparatus for extending operations of an application in a data processing system |
US20080057484A1 (en) * | 2006-09-05 | 2008-03-06 | Shinichi Miyata | Event-driven method for tutoring a user in the determination of an analyte in a bodily fluid sample |
US8234623B2 (en) * | 2006-09-11 | 2012-07-31 | The Mathworks, Inc. | System and method for using stream objects to perform stream processing in a text-based computing environment |
US20080127128A1 (en) * | 2006-10-30 | 2008-05-29 | Daniel Mateescu | Type Validation for Applications Incorporating A Weakly-Typed Language |
US20090077537A1 (en) * | 2007-09-18 | 2009-03-19 | International Business Machines Corporation | method of automatically generating test cases to test command line interfaces |
US8281390B1 (en) * | 2007-11-26 | 2012-10-02 | Adobe Systems Incorporated | Remotely defining security data for authorization of local application activity |
JP5304381B2 (ja) * | 2009-03-27 | 2013-10-02 | 富士通株式会社 | 実行形式プログラム、およびその生成装置、生成方法 |
EP2239658A1 (en) * | 2009-04-08 | 2010-10-13 | Siemens Aktiengesellschaft | Custom command line switch |
US9524179B2 (en) | 2011-05-05 | 2016-12-20 | Microsoft Technology Licensing, Llc | Virtual-machine-deployment-action analysis |
CN102279744A (zh) * | 2011-08-24 | 2011-12-14 | 北京星网锐捷网络技术有限公司 | 命令行处理系统及方法 |
CN102571774B (zh) * | 2011-12-27 | 2015-10-21 | 浙江省电力公司 | 一种字符操作命令识别方法及装置 |
US9715372B2 (en) * | 2013-03-13 | 2017-07-25 | Microsoft Technology Licensing, Llc | Executable guidance experiences based on implicitly generated guidance models |
RU2534823C1 (ru) * | 2013-09-23 | 2014-12-10 | Сергей Михайлович Назаров | Способ генерирования синтаксически и семантически верных команд |
US10169127B2 (en) | 2014-03-06 | 2019-01-01 | International Business Machines Corporation | Command execution results verification |
US9558101B2 (en) * | 2014-08-08 | 2017-01-31 | Raytheon Company | Preprocessor directive symbol analyzer devices and methods |
WO2016140653A1 (en) * | 2015-03-03 | 2016-09-09 | Hewlett Packard Enterprise Development Lp | Command parsing in command-line-interface |
CN105847036B (zh) * | 2016-03-17 | 2018-11-13 | 烽火通信科技股份有限公司 | 命令预执行的系统及方法 |
US10419582B2 (en) | 2016-06-30 | 2019-09-17 | International Business Machines Corporation | Processing command line templates for database queries |
CN113467868B (zh) * | 2016-08-26 | 2023-12-15 | 成都华为技术有限公司 | 一种创建设备资源的方法和装置 |
US20190188384A1 (en) * | 2017-12-19 | 2019-06-20 | Crowdstrike, Inc. | Detecting script-based malware |
CN109189633A (zh) * | 2018-07-27 | 2019-01-11 | 西安交通大学 | 全息实时的模型运行监控方法 |
CN110928575B (zh) * | 2018-09-20 | 2022-04-29 | 上海登临科技有限公司 | 一种多设备同步控制系统和控制方法 |
US10824446B2 (en) * | 2018-11-02 | 2020-11-03 | Salesforce.Com, Inc. | Methods and systems for autocompletion |
CN111291299B (zh) * | 2020-01-22 | 2023-08-15 | 北京飞漫软件技术有限公司 | 一种直接获取本地命令执行结果的方法及本地服务器 |
CN111538531A (zh) * | 2020-04-28 | 2020-08-14 | 高新兴物联科技有限公司 | 一种基于面向对象的at指令系统、处理方法以及计算机存储介质 |
CN112667324B (zh) * | 2020-12-30 | 2023-12-05 | 凌云光技术股份有限公司 | 一种调用命令模式中命令类的方法及装置 |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3032031B2 (ja) * | 1991-04-05 | 2000-04-10 | 株式会社東芝 | ループ最適化方法及び装置 |
JP2520543B2 (ja) | 1991-09-06 | 1996-07-31 | インターナショナル・ビジネス・マシーンズ・コーポレイション | プログラムの実行を管理する方法及びシステム |
US5671418A (en) * | 1995-05-22 | 1997-09-23 | Bull Hn Information Systems Inc. | Operating system translator incorporating a verbose mode of operation |
US5754861A (en) * | 1995-08-16 | 1998-05-19 | Motorola, Inc. | Dynamic program input/output determination |
US5848393A (en) * | 1995-12-15 | 1998-12-08 | Ncr Corporation | "What if . . . " function for simulating operations within a task workflow management system |
US5974549A (en) | 1997-03-27 | 1999-10-26 | Soliton Ltd. | Security monitor |
US6192512B1 (en) | 1998-09-24 | 2001-02-20 | International Business Machines Corporation | Interpreter with virtualized interface |
US6654953B1 (en) | 1998-10-09 | 2003-11-25 | Microsoft Corporation | Extending program languages with source-program attribute tags |
US6857124B1 (en) * | 1999-01-11 | 2005-02-15 | Eolas Technologies, Inc. | Method and system for hypermedia browser API simulation to enable use of browser plug-ins and applets as embedded widgets in script-language-based interactive programs |
GB0031206D0 (en) * | 2000-12-21 | 2001-01-31 | Ibm | Multi-platform command line interpretation |
US7207031B2 (en) * | 2001-03-01 | 2007-04-17 | Wind River Systems, Inc. | System and method for utilization of a command structure representation |
US7103590B1 (en) * | 2001-08-24 | 2006-09-05 | Oracle International Corporation | Method and system for pipelined database table functions |
CN1389796A (zh) * | 2002-07-30 | 2003-01-08 | 北京港湾网络有限公司 | 一种数据网络基础设施设备使用实时操作系统命令的方法 |
TW591540B (en) * | 2003-03-07 | 2004-06-11 | Wistron Corp | Win F-language interpreter |
US7251735B2 (en) * | 2003-07-22 | 2007-07-31 | Lockheed Martin Corporation | Buffer overflow protection and prevention |
US7506307B2 (en) * | 2003-10-24 | 2009-03-17 | Microsoft Corporation | Rules definition language |
US7676798B2 (en) * | 2003-10-24 | 2010-03-09 | Microsoft Corporation | Mechanism for obtaining and applying constraints to constructs within an interactive environment |
US20050091424A1 (en) * | 2003-10-24 | 2005-04-28 | Snover Jeffrey P. | Mechanism for analyzing partially unresolved input |
US7536696B2 (en) * | 2003-10-24 | 2009-05-19 | Microsoft Corporation | Mechanism for handling input parameters |
US7155706B2 (en) * | 2003-10-24 | 2006-12-26 | Microsoft Corporation | Administrative tool environment |
-
2003
- 2003-10-24 US US10/693,409 patent/US7640540B2/en not_active Expired - Fee Related
-
2004
- 2004-07-22 WO PCT/US2004/023608 patent/WO2005045565A2/en active Application Filing
- 2004-07-22 MX MXPA05006616A patent/MXPA05006616A/es active IP Right Grant
- 2004-07-22 JP JP2006536563A patent/JP2007509407A/ja active Pending
- 2004-07-22 CN CN2004800012944A patent/CN101073057B/zh not_active Expired - Fee Related
- 2004-07-22 AU AU2004279165A patent/AU2004279165B2/en not_active Ceased
- 2004-07-22 RU RU2005115974/09A patent/RU2395837C2/ru not_active IP Right Cessation
- 2004-07-22 BR BR0406420-8A patent/BRPI0406420A/pt not_active IP Right Cessation
- 2004-07-22 CA CA2501364A patent/CA2501364C/en not_active Expired - Fee Related
- 2004-07-22 EP EP04778901A patent/EP1588242A4/en not_active Ceased
- 2004-07-22 KR KR1020057009154A patent/KR101150059B1/ko active IP Right Grant
Non-Patent Citations (1)
Title |
---|
JPN5006017293, ALTIRIS RAPIDINSTALL, 20010717, P1−14 * |
Also Published As
Publication number | Publication date |
---|---|
AU2004279165B2 (en) | 2010-03-11 |
AU2004279165A8 (en) | 2008-10-02 |
CA2501364C (en) | 2012-01-03 |
EP1588242A2 (en) | 2005-10-26 |
US20050091525A1 (en) | 2005-04-28 |
EP1588242A4 (en) | 2009-01-21 |
CA2501364A1 (en) | 2005-04-24 |
AU2004279165A1 (en) | 2005-06-23 |
KR20060114617A (ko) | 2006-11-07 |
WO2005045565A2 (en) | 2005-05-19 |
RU2395837C2 (ru) | 2010-07-27 |
CN101073057A (zh) | 2007-11-14 |
CN101073057B (zh) | 2012-06-13 |
MXPA05006616A (es) | 2005-08-16 |
BRPI0406420A (pt) | 2005-10-04 |
US7640540B2 (en) | 2009-12-29 |
RU2005115974A (ru) | 2006-01-20 |
WO2005045565A3 (en) | 2006-07-20 |
KR101150059B1 (ko) | 2012-07-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101120853B1 (ko) | 관리 도구 환경 | |
JP5047621B2 (ja) | 対話環境における構文への制約を入手し適用する機構 | |
US7536696B2 (en) | Mechanism for handling input parameters | |
KR101130500B1 (ko) | 데이터 구동 커맨드 라인 출력을 제공하는 메커니즘 | |
KR101150059B1 (ko) | 커맨드 라인 명령에 확장된 기능을 제공하는 메커니즘 | |
AU2004279192B2 (en) | Mechanism for analyzing partially unresolved input |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070703 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101022 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110426 |