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

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

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

Раскрытие изобретения

Настоящий механизм предусматривает вывод управляемой данными командной строки в пределах окружения, которое поддерживает конвейерную обработку объектно-ориентированных команд. Каждая объектно-ориентированная команда вводит синтаксически анализируемый объект для осуществления обработки и выводит другой синтаксически анализируемый объект для последующей обработки команды. Механизм является работоспособным для непосредственного форматирования и последующей обработки команд на основе типа входящего синтаксически анализируемого объекта. Для типа получена информация о формате, такая как начертание, свойства отображения и подобная. Информация о формате может быть специфицирована в пределах XML-ориентированного документа. Механизм употребляет одну или более команд обработки вывода, таких как команд формата, команд разметки, команд конвертации, команд вывода и выходных команд. Эти команды обработки вывода могут быть расставлены в пределах конвейера различным образом, чтобы достичь желаемых результатов вывода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Осуществление изобретения

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

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

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

Примерное вычислительное окружение

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

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

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

Примерная оболочка инструмента

администрирования

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

Централизованные компоненты

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

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

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

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

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

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

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

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

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

Централизованно-специфические компоненты

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

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

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

Компоненты специального обработчика

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

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

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

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

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

Централизованно-независимые компоненты

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

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

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

Примерная машина сценария

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

Примерная главная машина

Главная машина 224 ответственна за обработку командных апплетов, идентифицируемых синтаксическим анализатором 220. Кратко обращаясь к фиг.4, проиллюстрирована примерная главная машина 224 в пределах оболочки 200 административного инструментального средства. Примерная главная машина 224 включает в себя конвейерный обработчик 402 данных, загрузчик 404, обработчик 406 метаданных, обработчик 408 ошибок & событий (Error&Event), управляющую программу 410 сеанса и управляющую программу 412 расширенного типа.

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

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

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

Обработчик 408 ошибок & событий предусматривает объект ошибки, чтобы хранить информацию о каждом случае ошибки во время обработки командной строки. Для дополнительной информации об одном из конкретных обработчиков ошибок и событий, который конкретно подходит для настоящей оболочки административного инструментального средства, следует обратиться к заявке на выдачу патента США №10/4