Механизм для получения и применения ограничений к логическим структурам в интерактивной среде

Механизм для получения и применения ограничений к логическим структурам в интерактивной среде

Иллюстрации

Показать все

Реферат

Область техники

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

Предшествующий уровень техники

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

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

Сущность изобретения

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

Краткое описание чертежей

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

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

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

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

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

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

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

Фиг.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 - графическое представление примерных последовательностей для команд “cmdlet” обработки вывода в конвейере.

Фиг.20 - пример обработки, выполняемой одной из команд “cmdlet” обработки вывода, показанных на фиг.19.

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

Фиг.22 - таблица, представляющая пример синтаксиса для примерных команд “cmdlet” обработки вывода.

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

Детальное описание предпочтительного варианта осуществления

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

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

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

Примерная вычислительная среда

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

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

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

Иллюстративное базовое средство разработки административных инструментальных средств

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

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

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

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

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

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

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

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

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

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

Специфические для хоста компоненты

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

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

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

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

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

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

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

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

Например, web-сервис 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 ошибок и событий обеспечивает объект ошибки для сохранения информации о каждом появлении ошибки в процессе обработки командной строки. Дополнительная информация о конкретном процессоре ошибок и событий, особенно подходящем для настоящего базового средства 200 разработки административных инструментальных средств, содержится в патентной заявке США №10/413054, патент США №20040205415 на «Систему и способ для сохранения информации об ошибках в среде командных строк», того же заявителя, что и в настоящем изобретении, которая включена в настоящее описание посредством ссылки.

Примерный администратор сессии

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

Примерный конвейерный процессор и загрузчик

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

Примерный администратор расширенного типа

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

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

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

В общих чертах администратор расширенного типа конфигурируется для доступа к точно синтаксически анализируемому вводу (не показано) и для коррелирования точно си