Механизм для обеспечения расширенных функциональных возможностей для инструкций командной строки

Механизм для обеспечения расширенных функциональных возможностей для инструкций командной строки

Иллюстрации

Показать все

Реферат

Предмет, раскрываемый здесь, относится к средам командной строки, и, в особенности, к обработке команд в среде командной строки.

УРОВЕНЬ ТЕХНИКИ

В среде командной строки интерфейс командной строки позволяет пользователю непосредственно выполнить задачу, вводя команду. Например, интерфейс командной строки может быть вызван так, чтобы показать окно, которое отображает приглашение (например, «C:\>»). Пользователь может напечатать команду, такую как «dir», в приглашении для выполнения команды. Несколько команд могут быть вместе сведены в конвейер (совокупность команд, выполняемых последовательно, где результат одной может быть входными условиями для следующей) для выполнения более сложной задачи. Обычным для этих конвейерных команд являются наличие очень сложных инструкций командной строки.

Одним из недостатков интерфейса командной строки является то, что пользователь должен знать точные инструкции командной строки для ввода, потому что полезная информацию не показывается интерфейсом командной строки. Если случайная ошибка, типа опечатки, введена для одной из инструкций командной строки, задача может быть выполнена не так, как ожидает пользователь.

Поэтому существует потребность в механизме, который помогает пользователям, которые вводят инструкции командной строки.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Представленный механизм позволяет командам, введенным в командную строку в среде командной строки, возможность выполняться в первом режиме выполнения или альтернативном режиме выполнения. Команда выполняется в альтернативном режиме выполнения, если команда содержит инструкцию выполнения в альтернативном режиме выполнения. Альтернативный режим выполнения обеспечивается операционной средой и предоставляет расширенные функциональные возможности команде. Альтернативный режим выполнения может визуально отобразить результаты выполнения команды, визуально отобразить смоделированные результаты выполнения команды, запросить проверку перед выполнением команды, может выполнить проверку защиты для определения того, имеет ли пользователь, запрашивающий выполнение, достаточные привилегии для выполнения команды, и т.п. Таким образом, расширенные функциональные возможности, предоставляемые средой, помогают пользователям, которые вводят инструкции командной строки, но не требует от разработчиков писать дополнительный код для команды.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 иллюстрирует примерное компьютерное устройство, которое может использовать примерную среду административной сервисной программы.

Фиг.2 является блок-схемой, в общем иллюстрирующей краткий обзор примерной оболочки административной сервисной программы для существующей среды административной сервисной программы.

Фиг.3 является блок-схемой, иллюстрирующей компоненты в специфических для хоста компонентах оболочки административной сервисной программы, показанной на фиг.2.

Фиг.4 является блок-схемой, иллюстрирующей компоненты в компоненте механизма ядра оболочки административной сервисной программы, показанной на фиг.2.

Фиг.5 является одной примерной структурой данных для определения cmdlet, подходящей для использования в административной сервисной программе, показанной на фиг.2.

Фиг.6 является примерной структурой данных для определения исходного типа команды, из которого получен cmdlet, показанный на фиг.5.

Фиг.7 является другой примерной структурой данных для определения cmdlet, подходящей для использования в административной сервисной программе, показанной на фиг.2.

Фиг.8 является логической блок-схемой, иллюстрирующей примерный процесс для обработки хоста, который осуществляется в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.9 является логической блок-схемой, иллюстрирующей примерный процесс для обработки ввода, который выполнен в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.10 является логической блок-схемой, иллюстрирующей процесс для обработки сценариев, подходящих для использования в процессе обработки ввода, показанного на фиг.9.

Фиг.11 является логической блок-схемой, иллюстрирующей процесс предварительной обработки сценария, подходящего для использования в процессе обработки сценария, показанного на фиг.10.

Фиг.12 является логической блок-схемой, иллюстрирующей процесс для применения ограничений, подходящих для использования в процессе обработки сценария, показанного на фиг.10.

Фиг.13 является функциональной блок-схемой, иллюстрирующей обработку командной строки в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.14 является логической блок-схемой, иллюстрирующей процесс для обработки командных строк, подходящих для использования в процессе для обработки ввода, показанного на фиг.9.

Фиг.15 является логической блок-схемой, иллюстрирующей примерный процесс для создания экземпляра cmdlet, подходящего для использования в обработке командных строк, показанных на фиг.14.

Фиг.16 является логической блок-схемой, иллюстрирующей примерный процесс для заполнения свойств cmdlet, подходящего для использования в обработке команд, показанной на фиг.14.

Фиг.17 является логической блок-схемой, иллюстрирующей примерный процесс для выполнения cmdlet, подходящего для использования в обработке команд, показанной на фиг.14.

Фиг.18 является функциональной блок-схемой примерного устройства управления расширенного типа, подходящего для использования в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.19 графически изображает примерные последовательности для обработки вывода cmdlets в конвейере.

Фиг.20 иллюстрирует примерную обработку, выполненную одной из обработок вывода cmdlets, показанной на фиг.19.

Фиг.21 графически изображает примерную структуру для отображения информации, доступной при обработке на фиг.20.

Фиг.22 является таблицей, показывающей список примерного синтаксиса для примерной обработки вывода cmdlets.

Фиг.23 иллюстрирует результаты, представленные выводом/консолью cmdlet, используя различные конвейерные последовательности для обработки вывода cmdlets.

РАСКРЫТИЕ

Кратко описанный выше, данный механизм обеспечивает расширенные функциональные возможности инструкций командной строки и помогает пользователям, которые вводят инструкции командной строки. Механизм предоставляет грамматику командной строки для определения желаемых расширенных функциональных возможностей. Расширенные функциональные возможности могут позволить подтверждение инструкций перед выполнением, могут обеспечить визуальное представление выполненных инструкций, могут обеспечить визуальное представление смоделированных инструкций, или могут проверить привилегии перед выполнением инструкций. Грамматика командной строки может быть расширена для обеспечения других функциональных возможностей.

Следующее описание формулирует определенную примерную оболочку административной сервисной программы, в которой работает механизм. Другие примерные среды могут включать особенности этого специфического варианта воплощения и/или другие особенности, которые нацелены на помощь тем пользователям, которые вводят инструкции командной строки.

Следующее подробное описание разделено на несколько разделов. Первый раздел описывает примерную компьютерную среду, в которой может работать среда административной сервисной программы. Второй раздел описывает примерную оболочку для административной сервисной программы. Последующие разделы описывают индивидуальные компоненты примерной оболочки и функционирование этих компонентов. Например, раздел «Примерный процесс для выполнения Cmdlet», вместе с фиг.6, описывает примерный механизм для предоставления расширенных функциональных возможностей инструкциям командной строки.

Примерная компьютерная среда

Фиг.1 иллюстрирует примерное компьютерное устройство, которое может использоваться в примерной среде административной сервисной программы. В самой базовой конфигурации компьютерное устройство 100 обычно включает, по меньшей мере, один процессорный модуль 102 и системную память 104. В зависимости от точной конфигурации и типа компьютерного устройства, системная память 104 может быть энергозависимой (типа оперативной памяти (RAM)), энергонезависимой (типа постоянной памяти (ROM), флэш-памяти, и т.д.) или некоторая их комбинации. Системная память 104 обычно включает операционную систему 105, один или более программных модулей 106, и может включать программные данные 107. Операционная система 106 включает компонентно-ориентированную оболочку 120, которая поддерживает компоненты (включая свойства и события), объекты, наследование, полиморфизм, отражение, и обеспечивает объектно-ориентированный, основанный на использовании компонентов прикладной программный интерфейс (API), такой как NET™ Framework, созданный Microsoft Corporation, Redmond, WA. Операционная система 105 также включает оболочку 200 административной сервисной программы, которая взаимодействует с основанной на использовании компонентов оболочкой 120 для поддержки разработки административных инструментальных средств (не показанных здесь). Эта основная конфигурация проиллюстрирована на фиг.1 этими компонентами в пределах пунктирной линии 108.

Компьютерное устройство 100 может иметь дополнительные особенности или функциональные возможности. Например, компьютерное устройство 100 может также включает дополнительные устройства хранения данных (сменные и/или несменные), такие как, например, магнитные диски, оптические диски или ленты. Такое дополнительное устройство хранения проиллюстрировано на фиг.1 сменной памятью 109 и несменной памятью 110. Компьютерные носители данных могут включить энергозависимые и энергонезависимые, сменные и несменные носители, реализующие любой способ или технологию для хранения информации, такой как читаемые компьютером инструкции, структуры данных, программные модули, или другие данные. Системная память 104, сменная память 109 и несменная память 110 все являются примерами компьютерных носителей данных. Компьютерные носители данных включают, но не ограничены этим, оперативную память, ROM, RAM, EEPROM, флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другую оптическую память, магнитные кассеты, магнитную ленту, магнитную память на диске или другие магнитные запоминающие устройства, или любые другие носители информации, которые могут использоваться для хранения требуемой информации, и к которой можно обратиться компьютерным устройством 100. Любые такие компьютерные носители данных могут быть частью устройства 100. Компьютерное устройство 100 может также иметь устройство(а) ввода данных 112, такое как клавиатура, мышь, перо, устройства голосового ввода данных, сенсорное устройство ввода данных, и т.д. Устройство(а) вывода 114, такое как дисплей, динамики, принтер, и т.д. также может быть включено. Эти устройства хорошо известны в данной области техники и нет необходимости обсуждать их здесь подробно.

Компьютерное устройство 100 может также содержать коммуникационные подключения 116, которые позволяют устройству связываться с другими компьютерными устройствами 118, например по сети. Коммуникационные подключения 116 являются одним из примеров коммуникационных носителей информации. Коммуникационные носители информации могут обычно воплощаться читаемыми компьютером инструкциями, структурами данных, программными модулями, или другими данными в модулируемом сигнале данных, типа несущей или другом транспортном механизме, и включают любые доставляющие информационные носители. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или более из своих характеристик установленной или измененной таким способом, чтобы кодировать информацию в сигнале. В качестве примера, но не ограничения, коммуникационные носители включают проводные носители типа проводной сети или прямого сетевого подключения, и беспроводные носители, типа акустических, ради инфракрасных и других беспроводных носителей информации. Термин «читаемые компьютером носители», используемый здесь, включает и носитель данных и коммуникационный носители.

Примерная оболочка административной сервисной программы

Фиг.2 является блок-схемой, в общем иллюстрирующей краткий обзор примерной оболочки 200 административной сервисной программы. Оболочка 200 административной сервисной программы включает один или более хост-компонентов 202, хост-специфичные компоненты 204, хост-независимые компоненты 206, и компоненты обработчика 208. Хост-независимые компоненты 206 могут связываться с каждым из других компонентов (то есть хост-компонентами 202, хост-специфичными компонентами 204, хост-независимыит компонентами 206 и компонентами обработчика 208). Каждый из этих компонентов кратко описан ниже и описан в деталях, когда это необходимо, в последующих разделах.

Хост-компоненты

Хост-компоненты 202 включают одну или более хост-программ (например, хост-программы 210-214), которые открывают возможности автоматизации для связанного приложения пользователю или другим программам. Каждая хост-программа 210-214 может открыть эти возможности автоматизации в своем собственном специфическом стиле, например через командную строку, графический интерфейс пользователя (GUI), интерфейс распознавания речи, прикладной программный интерфейс (API), язык сценариев, веб-сервис (служба, работающая через стандартный протокол интернета), и т.п. Однако каждая из хост-программ 210-214 открывает одну или более возможностей автоматизации через механизм, предоставляемый оболочкой административной сервисной программы.

В этом примере механизм использует cmdlets к плоскости возможностей административной сервисной программы для пользователя связанной хост-программы 210-214. Кроме того, механизм использует набор интерфейсов, сделанных доступными хостом, встроенным в среду административной сервисной программы в приложении, связанном с соответствующей хост-программой 210-214. Во время следующего обсуждения, термин «cmdlet» используется для ссылки на команды, которые используются в примерной среде административной сервисной программы, описанной со ссылкой на фиг.2-23.

Cmdlets относится к командам в традиционных административных средах. Однако cmdlets весьма отличен от этих традиционных команд. Например, cmdlets обычно меньше по размеру, чем их эквивалентные команды, потому что cmdlets может использовать общие функции, предоставленные оболочкой административной сервисной программы, такие как синтаксический анализ, проверка правильности данных, сообщения об ошибках, и т.п. Поскольку такие общие функции могут быть один раз реализованы и проверены, использование cmdlets всюду в оболочке административной сервисной программы позволяет увеличивающейся стоимости разработки и тестирования, связанной со специфическими для приложения функциями, быть весьма низкой по сравнению с традиционными средами.

Кроме того, в отличие от традиционных сред, у cmdlets нет необходимости выполняться независимыми программами. Напротив, cmdlets может выполняться в тех же самых процессах в оболочке административной сервисной программы. Это позволяет cmdlets обмениваться «живыми» объектами друг между другом. Эта способность обмениваться «живыми» объектами позволяет cmdlets непосредственно вызывать методы этих объектов. Детали для создания и использования cmdlets описаны в дополнительных деталях ниже.

В общем представлении каждая хост-программа 210-214 управляет взаимодействиями между пользователем и другими компонентами в оболочке административной сервисной программы. Эти взаимодействия могут включить подсказки для параметров, сообщения об ошибках и т.п. Как правило, каждая хост-программа 210-213 может обеспечить свой собственный набор определенных для хоста cmdlets (например, хост cmdlets 218). Например, если хост-программа является программой электронной почты, хост-программа может предоставить хост cmdlets, который взаимодействует с почтовыми ящиками и сообщениями. Даже притом, что фиг.2 иллюстрирует хост-программы 210-214, специалист в данной области техники оценит, что хост-компоненты 202 могут включать другие хост-программы, связанные с существующим или вновь созданными приложениями. Эти другие хост-программы также встраивают функциональные возможности, предоставленные средой административной сервисной программы в их связанном приложении. Обработка, обеспеченная хост-программой, описывается подробно ниже в связи с фиг.8.

В примерах, иллюстрированных на фиг.2, хост-программа может быть управляющей консолью (то есть хост-программа 210), которая обеспечивает простой, непротиворечивый, административный интерфейс пользователя для создания, сохранения и открытия пользователем административных инструментальных средств, которые управляют аппаратными средствами, программным обеспечением и сетевыми компонентами компьютерного устройства. Для достижения этих функций хост-программа 210 предоставляет набор сервисов для управления построением графических интерфейсов пользователя на вершине оболочки административной сервисной программы. Взаимодействия графического интерфейса пользователя могут также быть открыты как видимые пользователю сценарии, которые помогают в обучении пользователей возможностям создания сценария, предоставляемые средой административной сервисной программы.

В другом примере, хост-программа может быть интерактивной оболочкой командной строки (то есть хост-программа 212). Интерактивная оболочка командной строки может позволить метаданным 216 оболочки быть введенными в командную строку для влияния на обработку командной строки.

В еще одном примере, хост-программа может быть веб-сервисом (то есть хост-программа 214), который использует спецификации промышленного стандарта для распределенного вычисления и взаимодействия между платформами, языками программирования и приложениями.

В дополнение к этим примерам, третьи стороны могут добавить свои собственные хост-компоненты, создавая интерфейсы «третьей стороны» или «поставщика» и предоставить cmdlets, которые используются с их хост-программой или другими хост-программами. Интерфейс поставщика открывает приложение или инфраструктуру так, чтобы приложение или инфраструктура могли управляться оболочкой административной сервисной программы. Поставщик cmdlets обеспечивает автоматизацию для навигации, диагностики, конфигурации, жизненного цикла, операций и т.п. Поставщик cmdlets демонстрирует полиморфное поведение cmdlet на полностью гетерогенном наборе хранилищ данных. Среда административной сервисной программы оперирует на поставщике cmdlets с тем же самым приоритетом, что и другие классы cmdlet. Поставщик cmdlet создается, используя те же самые механизмы, что и другие cmdlets. Поставщик cmdlets открывает определенные функциональные возможности приложения или инфраструктуры оболочке административной сервисной программы. Таким образом, с помощью cmdlets, разработчикам продукта требуется только создать один хост-компонент, который позволит их продукту работать со многими административными сервисными программами. Например, с примерной средой административной сервисной программы, справочные меню графического интерфейса пользователя системного уровня могут быть интегрированы и перенесены на существующие приложения.

Хост-специфичные компоненты

Хост-специфичные компоненты 204 включают совокупность служб, которые компьютерные системы (например, компьютерное устройство 100 на фиг.1) используют для изолирования оболочки административной сервисной программы от специфичной платформы, на которой выполняется оболочка. Таким образом, есть набор хост-специфичных компонентов для каждого типа платформ. Хост-специфичные компоненты позволяют пользователям использовать те же самые административные сервисные программы на различных операционных системах.

Обратимся к фиг.3, на которой хост-специфичные компоненты 204 могут включать компоненту 302 доступа к intellisense(технология отображения справочных ссылок по мере того, как печатается текст, без необходимости выхода из редактора)/метаданным, компонент 304 справки cmdlet, компонент 306 конфигурации/регистрации, компонент 308 установки cmdlet, и компонент 309 интерфейса вывода. Компоненты 302-308 взаимодействует с менеджером 312 хранилища базы данных, связанным с хранилищем 314 базы данных. Синтаксический анализатор 220 и механизм 222 сценариев взаимодействуют с компонентой 302 доступа к intellisense/метаданным. Механизм 224 ядра взаимодействует с компонентом 304 справки cmdlet, компонентом 306 конфигурации/регистрации cmdlet, компонентом установки 308, и компонентом 309 интерфейса вывода. Компонент 309 интерфейса вывода включает интерфейсы, предоставленные хостом для cmdlets. Эти cmdlets вывода могут вызывать объект вывода хоста для выполнения отображения. Хост-специфичные компоненты 204 могут также включать компонент 310 регистрации логов/аудита, который механизм 224 ядра использует для взаимодействия с хост-специфичной (то есть платформо-специфичной) службой, которая обеспечивают возможности регистрацию лога и аудита.

В одной примерной оболочке административной сервисной программы, компонента 302 доступа к intellisense/метаданным обеспечивает автозавершение команд, параметров, и значений параметра. Компонент 304 справки cmdlet обеспечивает настроенную систему справки, основанную на хост-интерфейсе пользователя.

Компоненты обработчика

Вернемся вновь к фиг.2, на котором компоненты обработчика 208 включают традиционные утилиты 230, управляющие cmdlets 232, неуправляющие cmdlets 234, удаленные cmdlets 236, и интерфейс 238 веб-сервиса. Управляющие cmdlets 232 (также называемые платформенными cmdlets) включают cmdlets, которые заращивают или манипулируют информацией о конфигурации, связанной с компьютерным устройством. Поскольку управляющие cmdlets 232 манипулируют информацией системного типа, они являются зависимыми от специфической платформы. Однако каждая платформа обычно имеет управляющие cmdlets 232, которые обеспечивают подобные действия, как управляющие cmdlets 232 на других платформах. Например, каждая платформа поддерживает управляющие cmdlets 232, которые получают и устанавливают системные административные атрибуты (например, получить/обработать, установить/IPAddress). Хост-независимые компоненты 206 взаимодействуют с управляющими cmdlets через объекты cmdlet, сгенерированные в хост-независимых компонентах 206. Примерные структуры данных для объектов cmdlets будут описаны подробно ниже в связи с фиг.5-7.

Неуправляющие cmdlets 234 (иногда называемые как базовые cmdlets) включают такие cmdlets, которые выполняют группировку, сортировку, фильтрацию, и выполняют другую обработку на объектах, предоставленных управляющих cmdlets 232. Неуправляющие cmdlets 234 могут также включать cmdlets для форматирования и вывода данных, связанных с конвейерными объектами. Примерный механизм для обеспечения вывода данных управляемых командной строкой описывается ниже в связи с фиг.19-23. Неуправляющие cmdlets 234 могут быть одними и теме же на каждой платформе и предоставлять набор утилит для взаимодействия с хост-независимыми компонентами 206 через объекты cmdlet. Взаимодействия между неуправляющими cmdlets 234 и хост-специфичными компонентами 206 позволяют отражение на объектах и позволяют обрабатывать на отраженных объектах, в не зависимости от их (объекта) типа. Таким образом, эти утилиты позволяют разработчикам написать неуправляющие cmdlets однажды и затем применять эти неуправляющие cmdlets во всех классах объектов, поддерживаемых на компьютерной системе. В прошлом разработчики должны были сначала осмыслить формат данных, который должен был быть обработан, а затем написать приложение для обработки только этих данных. Как следствие, традиционные приложения могли обработать данные только очень ограниченного объема. Один примерный механизм для обработки объектов, независимо от их типа, описан ниже в связи с фиг.18.

Традиционные утилиты 230 включают существующие исполняемые программы, такие как исполняемые программы под Win32, которые запускаются под cmd.exe. Каждая традиционная утилита 230 взаимодействует с оболочкой административной сервисной программы использования текстовые потоки (то есть stdin (стандартный поток ввода) и stdout (стандартный поток вывода)), которые являются типом объекта в объектной оболочке. Поскольку традиционные утилиты 230 используют текстовые потоки, операции на основе отражения, предоставляемые оболочкой административной сервисной программы, являются недоступными. Традиционные утилиты 230 выполняются в процессе, отличном от оболочки административной сервисной программы. Хотя и не показанные здесь, другие cmdlets могут также работать вне процесса.

Удаленные cmdlets 236, в комбинации с интерфейсом 238 веб-сервиса, обеспечивают удаленные механизмы для доступа к интерактивным и программируемым средам административной сервисной программы на других компьютерных устройствах с помощью коммуникационных носителей, таких как интернет или интранет (например, интернет/интранет 240, показанный на фиг.2). В одной примерной оболочке административной сервисной программы удаленные механизмы поддерживают объединенные службы, которые зависят от инфраструктуры, которая охватывает множество независимых управляемых доменов. Удаленный механизм позволяет сценариям выполняться на удаленных компьютерных устройствах. Сценарии могут быть запущены на отдельной или на множестве удаленных систем. Результаты сценариев могут быть обработаны по завершению каждого отдельного сценария, или результаты могут быть соединены и обработаны совместно после того, как все сценарии на различных компьютерных устройствах завершаться.

Например, веб-сервис 214, показанный как один из хост-компонентов 202, может быть удаленным агентом. Удаленный агент передает представление запроса удаленной команды синтаксическому анализатору и оболочке административной сервисной программы на целевой системе. Удаленный cmdlets служит удаленным клиентом, обеспечивающим доступ к удаленному агенту. Удаленный агент и удаленный cmdlets взаимодействуют через анализируемый поток. Этот анализируемый поток может быть защищен на уровне протокола, или дополнительный cmdlets может использоваться для шифрования и затем расшифровки анализируемого потока.

Хост-независимые компоненты

Хост-независимые компоненты 206 включают синтаксический анализатор 220, механизм 222 сценариев и механизм 224 ядра. Хост-независимые компоненты 206 предоставляют механизмы и службы группе множества cmdlets, координирующих работу cmdlets, и координирующих взаимодействие других ресурсов, сеансов и заданий с cmdlets.

Примерный синтаксический анализатор

Синтаксический анализатор 220 предоставляет механизмы для получения входных запросов от различных хост-программ и отображения входных запросов на единообразные объекты cmdlet, которые используются всюду в оболочке административной сервисной программы, например в механизме 224 ядра. Кроме того, синтаксический анализатор 220 может выполнить обработку данных, основываясь на полученном вводе. Один примерный способ для выполнения обработки данных, основываясь на вводе, описывается ниже в связи с фиг.12. Синтаксический анализатор 220 данной оболочки административной сервисной программы обеспечивает возможность легко открыть различные языки или синтаксис пользователям для одних и тех же возможностей. Например, поскольку синтаксический анализатор 220 отвечает за интерпретацию входных запросов, изменение в коде в синтаксическом анализаторе 220, который затрагивает ожидаемый входной синтаксис, по существу затронет каждого пользователя оболочки административной сервисной программы. Поэтому системные администраторы могут предоставить различные синтаксические анализаторы на различных компьютерных устройствах, которые поддерживают различный синтаксис. Однако каждый пользователь, работающий с одним и тем же синтаксическим анализатором, будет иметь опыт в непротиворечивом синтаксисе для каждого cmdlet. Напротив, в традиционных средах каждая команда реализовывала бы свой собственный синтаксис. Таким образом, с тысячами команд, каждая среда поддерживает несколько различных синтаксисов, многие из которых, обычно, противоречат друг другу.

Примерный механизм сценариев

Механизм 222 сценария предоставляет механизмы и службы для связи множества cmdlets вместе, используя сценарий. Сценарий является соединением частей командных строк, которые совместно используют состояние сеанса при строгих правилах наследования. Множество командных строк в сценарии могут быть выполнены или синхронно или асинхронно, основываясь на синтаксисе, переданном во входном запросе. Механизм 222 сценария имеет возможность обрабатывать управляющие структуры, такие как циклы и условные операторы, и обрабатывать переменные в сценарии. Механизм сценария также управляет состоянием сеанса и дает cmdlets доступ к данным сеанса, основываясь на политике (не показанной здесь).

Примерный механизм ядра

Механизм 224 ядра ответственен за обработку cmdlets, идентифицированных синтаксическим анализатором 220. Обратимся к фиг.4, на которой проиллюстрирован примерный механизм 224 ядра оболочки 200 административной сервисной программы. Примерный механизм 224 ядра включает конвейерный процессор 402, загрузчик 404, процессор 406 метаданных, обработчик 408 ошибок и событий, менеджер сеанса 410 и менеджер 412 расширенного типа.

Примерный обработчик метаданных

Обработчик 406 метаданных сконфигурирован для обращения и сохраненным метаданным в хранилище метаданных, таком как хранилище 314 базы данных, показанное на фиг.3. Метаданные могут быть переданы через командную строку, внутри определения класса cmdlet, и т.п. Различные компоненты оболочки 200 административной сервисной программы могут запросить метаданных при выполнении своей обработки. Например, синтаксический анализатор 202 может запросить метаданные для проверки правильности параметров, переданных в командной строке.

Примерный обработчик ошибок и событий

Обработчик 408 ошибок и событий предоставляет объект ошибки для хранения информации о каждом возникновении ошибки во время обработки командной строки. Для дополнительной информации о одном специфическом обработчике ошибок и событий, который наиболее подходит для представленной оболочки административной сервисной программы, требуется обратится к заявке на патент США № _____/ и патенту США № _____, озаглавленных «System and Method for Persisting Error information in a Command Line Environment», который принадлежит тому же самому правопреемнику, что и данное изобретение, и включен сюда по ссылке.

Примерный менеджер сеанса

Менеджер сеанса 410 сеанса предоставляет информацию о сеансе и состоянии другим компонентам в оболочке 200 административной сервисной программы. К информации о состоянии, управляемой менеджером сеанса, можно обратиться любым cmdlet, хостом, или базовым механизмом через программные интерфейсы. Эти программные интерфейсы предназначены для создания, модификации, и удаления информации о состоянии.

Примерный конвейерный обработчик и загрузчик

Загрузчик 404 сконфигурирован для загрузки каждого cmdlet в память для того, чтобы конвейерный процессор 402 выполнил cmdlet. Конвейерный процессор 402 включает обработчик 420 cmdlet и менеджер 422 cmdlet. Обработчик 420 cmdlet обеспечивает диспетчеризацию индивидуальных cmdlets. Если cmdlet требует выполнения на удаленной, или наборе удаленных машин, процессор 420 cmdlet координирует выполнение вместе с удаленным cmdlet 236 показанным на фиг.2. Менеджер 422 cmdlet обрабатывает выполнение агрегирования (механизм многократного использования при наследовании одним объектом методов другого объекта) cmdlets. Менеджер 422 cmdlet, процессор 420 cmdlet, и механизм 222 сценариев (фиг.2) связываются друг с другом для выполнения обработки ввода, полученного от хост-программы 210-214. Взаимодействие может быть рекурсивным по своей природе. Например, если хост-программа предоставляет сценарий, сценарий может вызвать менеджера 422 cmdlet для того, чтобы выполнить cmdlet, который сам может быть сценарием. Сценарий может тогда быть выполненным механизмом 222 сценария. Один примерный поток обработки для базового механизма описывается подробно ниже при рассмотрении фиг.14.

Примерный менеджер расширенных типов

Как упомянуто выше, оболочка административной сервисной программы предоставляет набор утилит, который позволяет отражение на объектах и позволяет осуществлять обработку на отраженных объектах, независимо от их (объектов) типа. Оболочка 200 административной сервисной программы взаимодействует с оболочкой компонентов на компьютерной системе (оболочка компонентов 120 на фиг.1) для выполнения этого отражения. Как может оценить специалист в данной области техники, отражение обеспечивает способность сделать запрос объекта и получить тип для объекта, и затем отразить на различные объекты и свойства, связанные с тем же типом объекта для того, чтобы получить другие объекты и/или желаемое значение.

Даже при том, что отражение обеспечивает оболочке 200 административной сервисной программы значительное количество информации относительно объектов, изобретатели осознают, что отражения фокусируются на типе объекта. Например, когда база данных datatable отражена, возвращаемой информацией является то, что datatable имеет два свойства: свойство столбца и свойство строки. Эти два свойства не обеспечивают достаточных деталей относительно «объектов» в datatable. Подобные проблем возникают, когда отражение используется на расширяемом языке разметки (XML) и других объектах.

Таким образом, изобретатели придумали менеджер 412 расширенного типа, который фокусируется на использование типа. Для этого менеджера расширенного типа, тип объекта не важен. Вместо этого, менеджер расширенного типа интересуется тем, может ли объект использоваться для получения требуемой информации. Продолжая пример вышеупомянутой datatable, изобретатели осознают, что знание того, что datatable имеет свойство столбца и свойство строки, не особенно интересно, но осознают то, что один столбец содержит информацию, представляющую интерес. Фокусируясь на использовании, можно было связать каждую строку с «объектом» и связать каждый столбец со «свойством» этого «объекта». Таким образом, менеджер 412 расширенного типа обеспечивает механизм для создания «объектов» из любого типа предназначенного для точного синтаксического анализа ввода. Таким образом, менеджер 412 расширенного типа добавляет возможности отражения, предоставленные компонентно-ориентированной оболочкой 120, и расширяет «отражение» на любой тип предназначенного для точного синтаксического анализа ввода.

В общих чертах, менеджер расширенного типа сконфигурирован для обращения к точно предназначенному для синтаксического анализа вводу (не показанному здесь) и корреляции предназначенному для точного синтаксического анализа ввода с требуемым типом данных. Менеджер 412 расширенного типа после этого обеспечивает требуемую информацию требуемой компоненте, такой как конвейерный обработчик 402 или синтаксический анализатор 220. В следующем обсуждении, предназначенный для точного синтаксического анализа ввод определен как ввод, в котором свойства и значения могут различаться. Некоторые примеры предназначенного для точного синтаксического анализа ввода включает ввод Windows Management Instrument (WMI), ввод ActiveX Data Object (ADO), ввод расширяемого языка разметки (XML), и объектный ввод, такой как объекты.NET. Другой предназначенный для точного синтаксического анализа ввод может включить форматы данных третьих сторон.

Обратимся кратко к фиг.18, показывающей функциональную блок-схему примерного менеджера расширенного типа для использования в оболочке административной сервисной программы. Для целей объяснения, функциональные возможности (обозначенные номером «3» в круге) предоставляемые менеджером расширенного типа, противопоставлены функциональными возможностями, предоставляемыми традиционной тесно связанной системой (обозначенные номером «1» в круге) и функциональные возможности, предоставляемые системой отражения (обозначенные номером «2» в круге). В традиционной тесно св