Область техники, к которой относится изобретение
Предмет изучения, раскрытый в настоящем патентном документе, относится к окружениям командной строки и более конкретно к выводу команд, введенных посредством окружения командной строки.
Уровень техники
Многие операционные системы предусматривают механизм для «сшивания» (то есть конвейерной обработки) многочисленных приложений вместе, чтобы создавать сделанные на заказ, специально подобранные к данному случаю команды, которые могут быть введены в командную строку операционной системы. Типично, упомянутые команды использованы в инструментальных средствах администрирования систем, таких как инструментальные средства для управления свойствами систем. Каждая из конвейерно обрабатываемых обслуживающих программ в команде связывается с каждой другой посредством передачи текста. Таким образом, каждая обслуживающая программа в конвейере ответственна за синтаксический разбор текста, который принят, и за форматирование текста, который выведен.
Форматирование текста, который выведен, выполнено кодом в пределах команды и, типично, основано на интерпретировании ключей, предусмотренных для команды в командной строке. Таким образом, каждая команда, как желательно, ответственна за форматирование и отображение вывода.
Следовательно, существует необходимость в механизме, который предусматривает улучшенные варианты выбора форматирования и не требует протяженного кода в пределах команды для того, чтобы предусматривать такие улучшенные варианты выбора форматирования.
Раскрытие изобретения
Настоящий механизм предусматривает вывод управляемой данными командной строки в пределах окружения, которое поддерживает конвейерную обработку объектно-ориентированных команд. Каждая объектно-ориентированная команда вводит синтаксически анализируемый объект для осуществления обработки и выводит другой синтаксически анализируемый объект для последующей обработки команды. Механизм является работоспособным для непосредственного форматирования и последующей обработки команд на основе типа входящего синтаксически анализируемого объекта. Для типа получена информация о формате, такая как начертание, свойства отображения и подобная. Информация о формате может быть специфицирована в пределах 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/413054, озаглавленной «Система и способ для фиксирования информации об ошибке в окружении командной строки» («System and Method for Persisting Error Information in a Command Line Environment»), которая является находящейся в собственности того же самого правопреемника, что и настоящее изобретение, и включена в состав настоящего описания ссылкой.
Примерная управляющая программа сеанса
Управляющая программа 410 сеанса поставляет информацию о сеансе и информацию о строении другим компонентам в пределах оболочки 200 административного инструментального средства. К информации о строении, управляемой управляющей программой сеанса, может быть осуществлен доступ любым командным апплетом, централизованным вычислительным устройством или главной машиной посредством интерфейсов программирования. Эти интерфейсы программирования предоставляют возможность для создания, модификации и удаления информации о состоянии.
Примерные обработчик и загрузчик конвейера
Загрузчик 404 сконфигурирован, чтобы загружать каждый командный апплет в память надлежащим образом для того, чтобы конвейерному обработчику приводить в исполнение командный апплет. Конвейерный обработчик 402 включает в себя обработчик 420 командного апплета и управляющую программу 422 командного апплета. Обработчик 420 командного апплета осуществляет диспетчеризацию отдельных командных апплетов. Если командный апплет требует приведения в исполнение на удаленной или множестве удаленных машин, то обработчик 420 командного апплета осуществляет координацию приведения в исполнение совместно с вынесенным командным апплетом 236, показанным на фиг.2. Управляющая программа 422 командного апплета специально обрабатывает приведение в исполнение совокупностей командных апплетов. Программа 422 управления командным апплетом, обработчик 420 командного апплета и машина 222 сценария (фиг. 2) связываются каждый друг с другом для того, чтобы выполнять обработку над входными данными, принимаемыми от централизованной программы 210-214. Связь может быть рекурсивной и естественной. Например, если централизованная программа предусматривает сценарий, то сценарий может вызывать управляющую программу 422 командного апплета, чтобы приводить в исполнение командный апплет, который сам может являться сценарием. Сценарий может быть затем приведен в исполнение машиной сценария 222. Одна из примерных последовательностей операций для главной машины описана детально в связи с фиг.14.
Примерная программа управления расширенным типом
Как установлено выше, оболочка административного инструментального средства предусматривает множество обслуживающих программ, которые предоставляют возможность осмысления объектов и позволяют обрабатывать осмысленные объекты независимо от их (объектного) типа. Оболочка 200 административного инструментального средства взаимодействует с компонентной оболочкой в вычислительной системе (компонентная оболочка 120 по фиг.1), чтобы выполнять это осмысление. Как будет принято во внимание специалистом в данной области техники, осмысление предусматривает возможность запрашивать объект и получать тип объекта, и затем осмысливать различные объекты и свойства, ассоциативно связанные с типом объекта, чтобы получать другие объекты и/или желаемые значения.
Несмотря на то, что осмысление предусматривает оболочку 200 административного инструментального средства как значительное количество информации в объектах, изобретатели принимали во внимание, что осмысление сфокусировано на типе объекта. Например, когда таблица данных базы данных осмыслена, информация, которая возвращена, является такой, что таблица данных имеет два свойства: свойство столбца и свойство строки. Эти два свойства не предусматривают достаточно детального соответствия «объекту» в пределах базы данных. Подобные проблемы возникают, когда осмысление основано на расширяемом языке разметки (XML) и других объектах.
Таким образом, изобретатели представляли себе программу 412 управления расширенного типа, которая фокусируется на использовании типа. Для этой программы управления расширенного типа не важен тип объекта. Взамен программа управления расширенного типа заинтересована в том, может ли объект быть использован, чтобы получить требуемую информацию. Продолжая вышеприведенный пример таблицы данных, изобретатели принимали во внимание, что знание того, что таблица данных имеет свойство столбца и свойство строки, не является особенно интересным, но полагали, что один из столбцов содержал в себе интересующую информацию. Фокусируясь на использовании, можно ассоциативно связывать каждую строку с «объектом» и ассоциативно связывать каждый столбец со свойством такого «объекта». Таким образом, управляющая программа 412 расширенного типа предусматривает механизм для создания «объектов» из любого типа строго пригодных для синтаксического разбора входных данных.
В общем виде управляющая программа расширенного типа сконфигурирована, чтобы осуществлять доступ к строго пригодным для синтаксического разбора входным данным (не показаны) и чтобы устанавливать соотношение строго пригодных для синтаксического разбора входных данных с запрашиваемым типом данных. Управляющая программа 412 расширенного типа затем предусматривает запрашиваемую информацию для запрашивающего компонента, такого как конвейерный обработчик 402 или синтаксический анализатор 220. В последующем подробном обсуждении строго пригодные для синтаксического разбора входные данные определены как входные данные, в которых свойства и значения могут быть распознаны. Некоторые примерные строго пригодные для синтаксического разбора входные данные включают в себя входные данные управляющего инструментария операционной системы Windows (WMI), входные данные объектов универсального доступа к данным (ADO - ActiveX Data Objects), входные данные расширяемого языка разметки (XML) и входные данные объекта, такие как у.NET-объектов. Другие строго пригодные для синтаксического разбора входные данные могут включать в себя форматы данных стороннего производителя.
Кратко обращаясь к фиг.18, показана функциональная блок-схема примерной управляющей программы расширенного типа для использования в пределах оболочки административного инструментального средства. В целях разъяснения, функциональные возможности (помеченные цифрой «3» в кружочке), предусмотренные управляющей программой расширенного типа, противопоставлены функциональным возможностям, предусмотренным традиционной системой с непроницаемыми границами (помеченной цифрой «1» в кружочке) и функциональным возможностям, предусмотренным системой осмысления (помеченной цифрой «2» в кружочке). В обычной системе с непрозрачными границами вызывающая программа 1802 в пределах приложения непосредственно осуществляет доступ к информации (например, к свойствам P1 и P2, методам M1 и M2) в пределах объекта A. Как установлено ранее, вызывающая программа 1802 должна предварительно знать свойства (например, свойства P1 и P2) и методы (M1 и M2), предусмотренные объектом A, во время компиляции. В системе с осмыслением групповой код 1820 (не зависящий от любого типа данных) запрашивает систему 1808, которая выполняет осмысление 1810 запрошенного объектом и возвращает информацию (например, свойства P1 и P2, методы M1 и M2) об объекте (например, об объекте A), в групповой код 1820. Хотя это не показано в объекте A, возвращаемая информация может включать в себя дополнительную информацию, такую как информацию о производителе, файле, дате и подобную. Таким образом, через осмысление групповой код 1820 получает по меньшей мере ту же самую информацию, которую предусматривает система с непроницаемыми границами. Система с осмыслением также предоставляет возможность вызывающей программе 1802 запрашивать систему и получать дополнительную информацию без какого-либо предварительного знания параметров.
И в системах с непроницаемыми границами, и в системах с преобразованием новые типы данных не могут быть легко объединены в пределах операционного окружения. Например, в системе с непроницаемой границей, после того как операционное окружение доставлено, операционное окружение не может включать в состав новые типы данных, поскольку оно должно быть перестроено для того, чтобы поддерживать их. Подобно этому в системах с осмыслением метаданные для каждого объектного класса фиксированы. Таким образом, включение новых типов данных обычно не выполняется.
Однако с помощью настоящей управляющей программы расширенного типа новые типы данных могут быть включены в состав операционной системы. С помощью управляющей программы 1822 расширенного типа групповой код 1820 может осмыслять запрашиваемый объект для получения расширенных типов данных (например, объекта A'), предусмотренных различными внешними источниками, такими как объектами сторонних производителей (например, объектами A' и B), семантической инфраструктурой 1832, онтологической службой 1834 и подобными. Как показано, объекты сторонних производителей могут расширять существующие объекты (например, объект A') или могут создавать полностью новый объект (например, объект B).
Каждый из этих внешних источников может регистрировать свою уникальную структуру в пределах метаданных 1840 типа и может предусматривать код 1842. Когда объект запрошен, управляющая программа расширенного типа просматривает метаданные 1840 типа, чтобы определить, был ли объект зарегистрирован. Если объект не зарегистрирован в пределах метаданных 1840 типа, то выполняется осмысление. Иначе выполняется расширенное осмысление. Код 1842 возвращает дополнительные свойства и методы, ассоциативно связанные с типом, над которым осуществляется осмысление. Например, если тип входных данных - это XML, то код 1842 может включать в себя файл описания, который описывает образ действий, которым XML был использован, чтобы создавать объекты из XML-документа. Таким образом, метаданные 1840 типа описывают, каким образом управляющая программа 412 расширенного типа должна запрашивать различные типы строго пригодных для синтаксического разбора входных данных (например, объектов A' и B стороннего производителя семантической инфраструктурой 1832), чтобы получать требуемые свойства для создания объекта, для такого специфического типа, и код 1842 предусматривает инструкции для получения этих требуемых свойств. Как результат, управляющая программа 412 расширенного типа предусматривает прослойку опосредованных логических операций, которые предоставляют возможность «осмысления» всех типов объектов.
В дополнение к предусмотрению расширенных типов управляющая программа 412 расширенного типа предусматривает дополнительные механизмы запроса, такие как механизм пути свойства, механизм ключа, механизм сравнения, механизм конвертации, механизм универсализатора, механизм установки свойства, механизм родства и подобные. Каждый из этих механизмов запроса, описанный далее в разделе «Примерная обработка управляющей программы расширенного типа», предусматривает для системных администраторов гибкость при вводе символьных строк команды. Различные технологии могут быть использованы, чтобы реализовать семантику для управляющей программы расширенного типа. Далее описаны три технологии. Однако специалистам в данной области техники следует принимать во внимание, что могут быть использованы изменения этих технологий, не выходящие за пределы объема заявленного изобретения.
В одной из технологий может быть предусмотрена серия классов, имеющих статические методы (например, метод getproperty() - взять свойство). Объект является входными данными для статического метода (например, метода getproperty(object) - взять свойство объекта), и статический метод возвращает множество результатов. В еще одной технологии операционное окружение обертывает объект адаптером. Таким образом, никакие входные данные не поставляются. Каждый отдельный пример адаптера имеет метод getproperty, который воздействует на обернутый объект и возвращает свойства для обернутого объекта. Последующий псевдокод иллюстрирует эту технологию:
Class Adaptor
{
Object X;
getProperties();
}.
В еще одной технологии, класс адаптера делает объект своим производным классом (подклассом). Традиционно осуществление определения подклассов происходило перед компиляцией. Однако с операционными окружениями определенного рода осуществление определения подклассов может происходить динамически. Для этих типов окружений последующий псевдокод иллюстрирует эту технологию:
Class Adaptor: A
{
getProperties();
{
return data
}
}.
Таким образом, как проиллюстрировано на фиг.18, управляющая программа расширенного типа предоставляет разработчикам возможность создавать новый тип данных, регистрировать тип данных и предоставляет другим приложениям и командным апплетам возможность использовать новый тип данных. В противоположность этому в предшествующих административных окружениях каждый тип данных должен быть известен ко времени компиляции, так что свойство или метод, ассоциативно связанные с объектом, конкретизируемым по такому типу данных, могли быть доступны непосредственно. Следовательно, добавление новых типов данных, которые поддерживались административным окружением, в прошлом делалось редко.
Снова ссылаясь на фиг.2, в общем виде, оболочка 200 административного инструментального средства не полагается на командный процессор для координирования приведения в исполнение команд, вводимых пользователями, но предпочтительнее разделяет функциональные возможности на порции обработки (например, централизованно-независимые компоненты 206) и порции пользовательского взаимодействия (например, посредством централизованных командных апплетов). В дополнение, настоящее окружение административного инструментального средства чрезвычайно упрощает программирование административных инструментальных средств, поскольку код, требуемый для осуществления текстового анализа и проверки действительности данных, больше не включен в пределы каждой команды, но предпочтительнее предусмотрен компонентами (например, анализатором текста 220) в пределах оболочки административного инструментального средства. Примерная обработка, выполняемая в пределах оболочки административного инструментального средства, описана ниже.
Примерная работа
Фиг. 5-7 графически иллюстрируют примерные структуры данных, используемые в пределах окружения административного инструментального средства. Фиг. 8-17 графически иллюстрируют примерные потоки обработки в пределах оболочки административного инструментального средства. Специалист в данной области техники будет принимать во внимание, что определенного рода обработка может быть выполнена компонентом, отличающимся от компонента, описанного ниже, не выходя за пределы объема настоящего изобретения. Перед описанием обработки, выполняемой в пределах компонентов оболочки административного инструментального средства, описаны примерные структуры данных, используемые в пределах оболочки административного инструментального средства.
Примерные структуры данных для объектов командного апплета
Фиг.15 - примерная структура данных для специфицирования командного апплета, подходящего для использования в пределах оболочки административного инструментального средства, показанной на фиг.2. При завершении командный апплет может быть управляющим командным апплетом, неуправляющим командным апплетом, централизованным апплетом, командным апплетом поставщика или подобным. Последующее подробное обсуждение описывает создание командного апплета относительно ракурса системного администратора (то есть командный апплет поставщика). Однако каждый тип командного апплета создан одним и тем же образом и действует подобным образом. Командный апплет может быть написан на любом языке, к примеру, C#. В дополнение, командный апплет может быть написан с использованием языков создания сценария или подобными. Когда окружение административного инструментального средства действует совместно с Оболочкой.NET Framework, командный апплет может быть.NET-объектом.
Командный апплет 500 поставщика (вышеуказанный в настоящем патентном документе как командный апплет 500) является открытым (типа public) классом, имеющим наименование класса командного апплета (например, StopProcess - «Остановить последовательность операций»). Командный апплет 500 происходит из класса 506 командного апплета. Примерная структура данных для класса 506 командного апплета описана ниже в связи с фиг.6. Каждый командный апплет 500 ассоциативно связан с атрибутом 502 команды, который ассоциативно связывает наименование (например, Stop/Process), с командным апплетом 500. Наименование зарегистрировано в пределах окружения административного инструментального средства. Как будет описано ниже, синтаксический анализатор осматривает реестр командных апплетов, чтобы идентифицировать командный апплет 500, когда символьная строка команды, имеющая наименование (например, Stop/Process), поставляется в качестве входных данных по командной строке или в сценарии.
Командный апплет 500 ассоциативно связан с механизмом грамматики, который определяет грамматику для ожидаемых входных параметров по отношению к командному апплету. Механизм грамматики может быть непосредственно или опосредованно ассоциирован с командным апплетом. Например, командный апплет 500 иллюстрирует непосредственную грамматическую ассоциативную связь. В этом командном апплете 500 объявлены один или более открытых для общего использования параметров (например, ProcessName 510 - наименование процесса и PID 512 - идентификатор процесса). Объявление открытых параметров управляет осуществлением синтаксического анализа объектов входных данных по отношению к командному апплету 500. В качестве альтернативы, описание параметров может происходить во внешнем источнике, таком как XML-документ. Описание параметров в этом внешнем источнике будет затем управлять осуществлением синтаксического анализа входных объектов по отношению к командному апплету.
Каждый открытый параметр 510, 512 может иметь один или более атрибутов (то есть директив), ассоциативно связанных с ним. Директивы могут быть любыми из следующих категорий: директива 521 синтаксического анализа, директива 522 проверки действительности данных, директива 523 выработки данных, директива 524 обработки, директива кодирования 525 и директива 526 документирования. Директивы могут быть окружены квадратными скобками. Каждая директива описывает операцию, которая должна быть выполнена над последующим ожидаемым входным параметром. Некоторые из директив, такие как директивы типа пользовательского взаимодействия, могут также быть применены на уровне класса. Применение этих атрибутов описано ниже в связи с фиг.12.
Эти атрибуты могут также действовать на наполнение параметров, объявленных в пределах командного апплета. Одна из примерных последовательностей операций для осуществления наполнения этих параметров описана ниже в связи с фиг.16. Главная машина может применять эти директивы, чтобы гарантировать соответствие. Командный апплет 500 включает в себя первый метод 530 (далее в настоящем патентном документе взаимозаменяемо указываемый ссылкой как метод 540 processRecod - запись последовательности операций). Главная машина использует первый и второй методы 530, 540, чтобы управлять обработкой командного апплета 500. Например, первый метод 530 приведен в исполнение однажды и выполняет функции установки. Код 542 в пределах второго метода 540 приведен в исполнение для каждого объекта (например, записи), который нуждается в том, чтобы быть обработанным командным апплетом 500. Командный апплет 500 может также включать в себя третий метод (не показан), который окончательно завершает работу после командного апплета 500.
Таким образом, как показано на фиг.5, код 542 в пределах второго метода 540 типично на самом деле краток и не содержит в себе функциональных возможностей, требуемых в обычных окружениях административного инструментального средства, таких как код синтаксического анализа, код проверки действительности данных и подобных. Таким образом, системные администраторы могут разрабатывать смешанные административные задачи без изучения смешанных языков программирования.
Фиг.6 - примерная структура 600 данных для специфицирования базового класса 602 командного апплета, из которого командный апплет, показанный на фиг.5, выведен. Базовый класс 602 командного апплета включает в себя инструкции, которые предусматривают дополнительные функциональные возможности всякий раз, когда командный апплет включает в себя выражение ловушки и соответствующий переключатель введен по командной строке или в сценарии (вместе указанные как ввод команды).
Примерная структура 600 данных включает в себя параметры, такие как словесные 610, условные 620 и директивные 630 булевы (логические) параметры. Как будет представлено далее, эти параметры соответствуют символьным строкам, которые могут быть введены при вводе команды. Примерная структура 600 данных может также включать в себя метод 640 обеспечения безопасности, который определяет, позволена ли задача, запрашиваемая для приведения в исполнение.
Фиг.7 - еще одна примерная структура 700 данных для специфицирования командного апплета. В общем виде структура 700 данных предусматривает средство для безусловного выражения соглашения между оболочкой административного инструментального средства и командным апплетом. Подобно структуре 500 данных, структура 700 данных является открытым классом, который произведен из класса 704 командного апплета. Разработчик программного обеспечения специфицирует объявление 702 командного апплета (cmdletDeclaration), которое ассоциативно связывает именно/глагольную пару, такую как «получить/процесс» и «форматировать/таблицу», с командным апплетом 700. Именно/глагольная пара зарегистрирована в пределах окружения административного инструментального средства. Глагол или имя существительное могут быть неявно выражены в наименовании командного апплета. Также, подобно структуре 500 данных, структура 700 данных может включать в себя один или более открытых членов класса (например, Name 730 - «наименование» и Recurse 732 - «рекурсия»), которые могут быть ассоциативно связаны с одной или более директивами 520-526, описанными в связи со структурой 500 данных.
Однако в этой примерной структуре 700 данных каждый из ожидаемых входных параметров 730 и 732 ассоциативно связаны с входными атрибутами 731 и 733 соответственно. Входные атрибуты 731 и 733 предписывают, что данные для этих соответственных параметров 730 и 732 должны быть получены из командной строки. Таким образом, в этой примерной структуре 700 данных отсутствуют какие-либо ожидаемые входные параметры, которые заполнены данными из конвейерно обрабатываемого объекта, который был порожден другим командным апплетом. Таким образом, структура 700 данных не может подменить первый метод (например, StartProcessing - Начать обработку) или второй метод (например, ProcessRecord), которые предусмотрены базовым классом командного апплета.
Структура 700 данных может также включать в себя приватный член 740, который не опознан как входной параметр. Приватный член 740 может быть использован для хранения данных, которые выработаны, на основании одной из директив.
Таким образом, как проиллюстрировано в структуре 700 данных, через использование объявления открытых свойств и директив в пределах специального класса командного апплета разработчики командного апплета могут легко специфицировать грамматику для ожидаемых входных параметров по отношению к их командному апплету и специфицировать обработку, которая должна быть выполнена над ожидаемыми входными параметрами, не требуя от разработчиков командного апплета выработки, лежащей в основе логики. Структура 700 данных иллюстрирует непосредственную ассоциативную связь между командным апплетом и грамматическим механизмом. Как установлено выше, это ассоциативное связывание, к примеру, осуществленное специфицированием определений ожидаемых параметров в пределах внешнего источника, такого как XML-документ, может быть также опосредованным.
Далее описаны примерные действия последовательности операций обработки в пределах окружения административного инструментального средства.
Примерное действие централизованной обработки
Фиг.8 - логическая блок-схема, иллюстрирующая примерную последовательность операций для централизованной обработки, которая выполнена в пределах оболочки административного инструментального средства, показанной на фиг.2. Последовательность 800 операций начинается на этапе 801, где был принят запрос, чтобы инициировать окружение административного инструментального средства на специальное приложение. Запрос мог быть отправлен локально через ввод с клавиатуры, к примеру, через выбор значка приложения или удаленно через интерфейс веб-службы другого вычислительного устройства. По любому из планов действий обработка продолжается по направлению к этапу 802.
На этапе 802 специальное приложение (например централизованная программа) на «целевом» вычислительном устройстве устанавливает свое окружение. Это включает в себя определение того, какие подмножества командных апплетов (например, управляющих командных апплетов 232, неуправляющих командных апплетов 234 и централизованных командных апплетов 218) сделаны доступными пользователю. Типично, централизованная программа будет делать доступными все управляющие командные апплеты 234 и свои собственные централизованные командные апплеты 218. В дополнение, централизованная программа будет делать доступным подмножество управляющих командных апплетов 234, таких как командные апплеты, общающиеся с программными последовательностями операций (процессами), диском и подобные. Таким образом, как только централизованная программа делает подмножество командных апплетов доступным, оболочка административного инструментального средства становится эффективно встроенной в пределы соответствующего приложения. Обработка продолжается до этапа 804.
На этапе 804 входные данные получены через специальное приложение. Как установлено выше, входные данные могут принимать определенные формы, такие как форма командных строк, сценариев, голосовая форма, форма GUI-интерфейса (графического интерфейса пользователя) и подобные. Например, когда входные данные получены посредством командной строки, входные данные извлекают информацию путем нажатия клавиш, зафиксированных на клавиатуре. Для централизованного вычислительного устройства с GUI-интерфейсом строка составлена, основываясь на GUI-интерфейсе. Обработка продолжается на этапе 806.
На этапе 806 для обработки предусмотрен ввод данных в другие компоненты в пределах оболочки административного инструментального средства. Централизованная программа может пересылать входные данные непосредственно в другие компоненты, такие как синтаксический анализатор. В качестве альтернативы, централизованная программа может пересылать входные данные посредством одного из ее централизованных командных апплетов. Централизованный командный апплет может преобразовывать его собственный специальный тип входных данных (например, голосовой) в тип входных данных (например, символьной текстовой строки, сценария), которые распознаны оболочкой административного инструментального средства. Например, голосовой ввод может быть преобразован в сценарий или строку символов командной строки в зависимости от содержимого голосового ввода. Поскольку каждая централизованная программа ответственна за преобразование ее типа входных данных в тип входных данных, распознаваемый оболочкой административного инструментального средства, оболочка административного инструментального средства может принимать ввод от любого количества различных централизованных компонентов. В дополнение, оболочка административного инструментального средства предусматривает наполненное широкими возможностями множества обслуживающих программ, которые выполняют преобразования между типами данных, когда входные данные пересылаются посредством одного из командных апплетов. Обработка, выполняемая над входными данными другими компонентами, описана ниже в связи с некоторыми другими чертежами. Централизованная обработка продолжается до этапа 808 принятия решения.
На этапе 808 принятия решения сделано определение того, был ли принят запрос на дополнительные входные данные. Это может происходить, если один из других компонентов, ответственных за обработку входных данных, нуждается в дополнительной информации от пользователя, для того чтобы завершить их обработку. Например, может быть затребован пароль для осуществления доступа к определенному роду данных, может быть необходимо подтверждение специальных действий и подобное. Для определенного рода типов централизованных программ (например, голосовой почты) запрос, такой как этот, может не быть подходящим. Таким образом, взамен запрашивания у пользователя дополнительной информации централизованная программа может переводить строение в последовательный режим, приостанавливать строение и посылать уведомление таким образом, что позже строение может быть возобновлено и приведение в исполнение входных данных будет продолжено. В другом варианте централизованная программа может предусматривать значение по умолчанию по истечении предопределенного периода времени. Если запрос на дополнительные входные данные принят, обработка зацикливается на этап 804, где получены дополнительные входные данные. Обработка затем продолжается через этапы 806 и 808, как описано выше. Если запрос на дополнительные входные данные отсутствует и входные данные были обработаны, то обработка продолжается до этапа 810.
На этапе 810 от других компонентов в пределах оболочки административного инструментального средства приняты результаты. Результаты могут включать в себя сообщения об ошибке, состоянии и подобном. Результаты являются представленными в форме объекта, которая распознана и обработана централизованным командным апплетом в пределах оболочки административного инструментального средства. Как будет описано ниже, код, написанный для каждого централизованного командного апплета, является самым минимальным. Таким образом, наполненное широкими возможностями множество входных данных может быть отображено, не требуя большого вложения средств в затраты на разработку. Обработка продолжается на этапе 812.
На этапе 812 результаты могут быть просмотрены. Централизованный командный апплет конвертирует результаты в стиль отображения, поддерживаемый централизованной программой. Например, возвращаемый объект может быть отображен централизованной программой GUI-интерфейса, используя графическое изображение, такое как изображения значка, лающей собаки и подобного. Централизованный командный апплет предусматривает формат и вывод по умолчанию для данных. Формат и вывод по умолчанию могут употреблять примерные командные апплеты обработки вывода, описанные ниже в связи с фиг. 19-23. После необязательного отображения результатов централизованная обработка завершается.
Примерные действия последовательности операций
для обработки входных данных
Фиг.9 - логическая блок-схема, иллюстрирующая примерную последовательность операций для специальной обработки входных данных, которая выполнена в пределах оболочки административного инструментального средства, показанного на фиг. 2. Обработка начинается на этапе 901, где входные данные введены посредством централизованной программы и пересланы другим компонентам в пределах оболочки административного инструментального средства. Обработка продолжается на этапе 902.
На этапе 902 входные данные приняты от централизованной программы. В одной из примерных оболочек административного инструментального средства входные данные приняты синтаксическим анализатором, который расшифровывает входные данные и направляет входные данные на дальнейшую обработку. Обработка продолжается на этапе 904 принятия решения.
На этапе 904 принятия решения сделано определение того, являются ли входные данные сценарием. Входные данные могут принимать форму сценария или символьную строку, представляющую командную строку (далее в настоящем патентном документе указываемую ссылкой как «символьная строка команды»). Символьная строка команды может представлять один или более совместно конвейерно обрабатываемых командных апплетов. Несмотря на то, что оболочка административного инструментального средства поддерживает несколько разных централизованных вычислительных устройств, каждое централизованное вычислительное устройство предусматривает для обработки входные данные в качестве либо сценария, либо символьных строк команды. Как будет показано ниже, взаимодействие между сценариями и командными символьными строками по своей природе является рекурсивным. Например, сценарий может иметь строку, которая вызывает командный апплет. Командный апплет сам по себе может быть сценарием.
Таким образом, на этапе 904 принятия решения, если входные данные имеют форму сценария, то обработка продолжается на этапе 906, где выполняется обработка сценария. В ином случае обработка продолжается на этапе 908, где выполняется обработка символьной строки команды. Как только обработка в пределах этапа 906 либо этапа 908 завершена, обработка входных данных завершается.
Примерная обработка сценариев
Фиг.10 - логическая блок-схема, иллюстрирующая последовательность операций для обработки сценария, подходящую для использования в пределах последовательности операций для специальной обработки входных данных, показанной на фиг.9. Последовательность операций начинается на этапе 1001, где входные данные были идентифицированы как сценарий. Машина сценария и синтаксический анализатор связываются друг с другом, чтобы выполнять последующие функции. Обработка продолжается на этапе 1002.
На этапе 1002 над сценарием выполнена предварительная обработка. Кратко обращаясь к фиг.11, показана логическая блок-схема, которая иллюстрирует последовательность операций 1100 предварительной обработки сценария, подходящая для использования в пределах последовательности операций 1000 обработки сценария. Предварительная обработка сценария начинается на этапе 1101 и продолжается на этапе 1102 принятия решения.
На этапе 1102 принятия решения сделано определение того, является ли сценарий запускаемым впервые. Это определение может быть основано на информации, получаемой из реестра или другого механизма хранения. Сценарий идентифицирован из пределов механизма хранения, и ассоциативно связанные данные просмотрены. Если сценарий предварительно не запускался, обработка продолжается на этапе 1104.
На этапе 1104 сценарий зарегистрирован в реестре. Это предоставляет возможность информации о сценарии быть сохраненной для более позднего осуществления доступа к ней со стороны компонентов в пределах оболочки административного инструментального средства. Обработка продолжается на этапе 1106.
На этапе 1106 помощь и документация извлечены из сценария и сохранены в реестре. К тому же, к этой информации позднее может быть осуществлен доступ со стороны компонентов в пределах оболочки административного инструментального средства. Сценарий с этого момента готов для обработки и возврата к этапу 1004 по фиг.10.
Возвращаясь к этапу 1102 принятия решения, если последовательность операций приходит к заключению, что сценарий запускался ранее, обработка продолжается до этапа 1108 принятия решения. На этапе 1108 принятия решения делается определение того, был ли сценарий неудавшимся в течение обработки. Эта информация может быть получена из реестра. Если сценарий не был неудавшимся, то сценарий готов для обработки и возвращается к этапу 1004 по фиг.10.
Однако, если сценарий не удался, обработка продолжается на этапе 1110. На этапе 1110 машина сценария может уведомлять пользователя через централизованную программу, что сценарий ранее не удался. Уведомление будет предоставлять пользователю возможность решить, продолжать ли сценарий или выйти из сценария. Как установлено выше в связи с фиг.8, централизованная программа может проводить специальную обработку над этими запросами различным образом, в зависимости от стиля ввода (например, голосового, командной строки). Как только дополнительные входные данные приняты от пользователя, сценарий либо возвращается к этапу 1004 по фиг.10 для обработки, либо сценарий прекращается.
Обращаясь к этапу 1004 по фиг.10, строка извлекается из сценария. Обработка продолжается на этапе 1006 принятия решения. На этапе 1006 принятия решения делается определение того, включает ли в себя строка какие-либо ограничительные условия. Ограничительное условие обнаружено при помощи предопределенного символа начала (например, скобки «[») и соответствующего символа окончания (например, закрывающей скобки «]»). Если строка включает в себя ограничительные условия, обработка продолжается до этапа 1008.
На этапе 1008 применены ограничительные условия, включенные в строку. В общем, ограничительные условия предусматривают механизм в пределах оболочки административного инструментального средства, чтобы специфицировать тип для параметра, вводимого в сценарий, и чтобы специфицировать логику проверки действительности, которая должна быть выполнена над параметром. Ограничительные условия предусматривают механизм в пределах интерпретируемых окружений, чтобы специфицировать тип данных и чтобы проверить действительность параметров. В обычных окружениях системные администраторы не способны формально проверить параметры, введенные в пределы сценария. Примерный способ для применения ограничительных условий проиллюстрирован на фиг.12.
На этапе 1010 принятия решения сделано определение того, включает ли строка из сценария в себя встроенные возможности. Встроенные возможности являются возможностями, которые не выполнены главной машиной. Встроенные возможности могут быть обработаны, используя командные апплеты, или могут быть обработаны, используя другие механизмы, такие как поточные функции. Если строка не имеет поточных возможностей, обработка продолжается на этапе 1014 принятия решения. Иначе обработка продолжается на этапе 1012.
На этапе 1012 обработаны поточные возможности, предусмотренные в строке сценария. Примеры поточных возможностей могут включать в себя приведение в исполнение управляющих структур, таких как выражения «if» («если»), циклы «for» («до тех пор, пока»), переключатели и подобных. Встроенные возможности могут также включать в себя выражения типа присваивания (например, a=3). Как только встроенные возможности обработались, обработка продолжается до этапа 1014 принятия решения.
На этапе 1014 принятия решения сделано определение того, включает ли сценарий в себя символьную строку команды. Определение основано на том, ассоциированы ли данные в строке с символьной строкой команды, которая была зарегистрирована, и с синтаксисом потенциального вызова командного апплета. Как установлено выше, обработка символьных строк команды и сценариев может быть рекурсивной по своей природе, поскольку сценарии могут включать в себя символьные строки команды и символьные строки команды могут приводить в исполнение командные апплеты, которые являются сценариями сами по себе. Если строка не включает в себя символьную строку команды, обработка продолжается на этапе 1018 принятия решения. Иначе обработка продолжается на этапе 1016.
На этапе 1016 обработана символьная строка команды. В общем виде обработка символьной строки команды включает в себя идентификацию класса командного апплета синтаксическим анализатором и отправку соответствующего объекта командного апплета в главную машину для приведения в исполнение. Командная символьная строка может также включать в себя конвейерно обрабатываемую командную символьную строку, которая синтаксически проанализирована по отношению к нескольким отдельным объектам командного апплета и отдельно обработана главной машиной. Одна из примерных последовательностей операций для обработки командной символьной строки описана ниже в связи с фиг. 14. Как только обработана символьная строка команды, обработка продолжается на этапе 1018 принятия решения.
На этапе 1018 принятия решения сделано определение того, есть ли еще одна строка в сценарии. Если еще одна строка в сценарии есть, обработка зацикливается обратно на этап 1004 и продолжается, как описано выше, по этапам 1004-1016. Иначе обработка завершается.
Примерная последовательность операций для применения ограничительных условий на этапе 1008 проиллюстрирована на фиг.12. Последовательность операций начинается с этапа 1201, где ограничительное условие обнаружено в сценарии или в символьной строке команды на командной строке. Когда ограничительное условие является находящимся в пределах сценария, ограничительное условие и ассоциативно связанные логические структуры встречаются до индикатора окончания строки (например, клавиши enter-ввод). Обработка продолжается до этапа 1202.
На этапе 1202 ограничительные условия получены из интерпретируемого окружения. В одном из примерных окружений административного инструментального средства, синтаксический анализатор расшифровывает входные данные и определяет присутствие ограничительных условий. Ограничительные условия могут быть из одной из последующих категорий: директивы утверждения, директивы синтаксического анализа, директивы проверки действительности, директивы выработки данных, директивы обработки, директивы кодирования и директивы документирования. В одном из примерных осуществлений анализа синтаксиса, директивы окружены квадратными скобками и описывают конструкцию, которая следует за ними. Конструкция может быть функцией, переменной, сценарием или подобными.
Как будет описано ниже, через использование директив, авторам сценариев предоставлена возможность легко набирать на клавиатуре и выполнять обработку параметров в пределах сценария или командной строки (то есть интерпретируемого окружения), не требуя от авторов сценария осуществления выработки какой-либо логики, лежащей в основе. Обработка продолжается до этапа 1204.
На этапе 1204 ограничительные условия, которые получены, сохранены в метаданных для ассоциативно связанной логической структуры. Ассоциативно связанная логическая структура идентифицирована как существующая первая не атрибутная метка, которая встретилась после одной или более атрибутных меток (меток, которые обозначают логические структуры). Обработка продолжается до этапа 1206.
На этапе 1206 каждый раз, когда встречена логическая структура в пределах сценария или в символьной строке команды, ограничительные условия, определенные в пределах метаданных, применены к логической структуре. Ограничительные условия могут включать в себя тип данных, директивы 1210 утверждения, директивы 1212 документирования, директивы 1214 синтаксического анализа, директивы 1216 выработки данных, директивы 1218 проверки действительности данных и директивы 1220 обработки и кодирования объекта. Ограничительные условия, специфицирующие типы данных, могут специфицировать любые типы данных, поддерживаемые системой, на которой запущена оболочка административного инструментального средства. Директивы утверждения 1210 являются директивами, которые показывают, может ли происходить обработка. Таким образом, директивы 1210 утверждения гарантируют, что окружение корректно для приведения в исполнение. Например, сценарий может включать в себя следующую директиву утверждения:
[PredicateScript(“isInstalled”,”ApplicationZ”)].
Директива утверждения гарантирует, что на вычислительное устройство до запуска сценария установлено корректное приложение. Типично переменные системного окружения могут быть специфицированы как директивы утверждения. Примерные директивы из типов 1212-1220 директив проиллюстрированы в таблицах 1-5. Обработка сценария затем завершается.
Таким образом, последовательность операций для применения типов и ограничительных условий в пределах интерпретируемого окружения предоставляет системным администраторам возможность легко специфицировать тип, специфицировать требования проверки действительности и подобное, не обладая средствами для написания лежащей в основе логики для выполнения этой обработки. Нижеследующее является примером обработки ограничительного условия, выполняемого над командной символьной строкой, специфицированной, как изложено ниже:
[Integer][ValidationRange(3,5)]$a=4.
Имеются в наличии два ограничительных условия, специфицированные посредством меток назначения атрибута, обозначенных при помощи «[]». Первая метка назначения атрибута показывает, что переменная является целочисленным типом, и вторая метка назначения атрибута показывает, что значение переменной $a должно быть между 3 и 5 включительно. Примерная командная символьная строка гарантирует, что если переменная $a назначена в последующей символьной строке команды или строке ввода, переменная $a будет проверена в отношении двух ограничительных условий. Таким образом, последующие командные символьные строки имели бы каждым результатом ошибку:
$a=231
$a=”apple”
$a=$(get/location).
Ограничительные условия применены к различным стадиям в пределах оболочки административного инструментального средства. Например, директивы применимости, директивы документирования и директивы нормативов осуществления синтаксического анализа обработаны на самых ранних стадиях в пределах синтаксического анализатора. Директивы выработки данных и директивы проверки действительности обработаны в машине, как только синтаксический анализатор закончил синтаксический анализ всех входных параметров.
Последующие таблицы иллюстрируют показательные директивы для различных категорий вместе с пояснением обработки, выполняемой окружением административного инструментального средства в ответ на директиву.
Директивы применимости
Директивы нормативов осуществления синтаксического анализа
Директивы документирования
Директивы проверки действительности данных
Директивы обработки и кодирования
Когда примерная оболочка административного инструментального средства действует в пределах оболочки.NET Framework, каждая категория имеет базовый класс, который порожден из базового класса категории (например, класса CmdAttribute - атрибут команды). Базовый класс категории порождается из класса System.Attribute (Системный атрибут). Каждая категория имеет предопределенную функцию (например, attrib.func() - функция атрибута), которая вызвана синтаксическим анализатором во время обработки категории. Автор сценария может создавать изготовленную на заказ категорию, которая порождена из класса изготовленной на заказ категории (например, CmdCustomAttribute - заказной атрибут команды). Автор сценария может также расширять существующий класс категории путем порождения директивного класса из базового класса категории для такой категории и подменять предопределенную функцию своей реализацией. Автор сценария может также подменять директивы и добавлять директивы к предопределенному множеству директив.
Порядок обработки этих директив может быть сохранен во внешнем хранилище данных, доступном синтаксическому анализатору. Оболочка административного инструментального средства просматривает зарегистрированные категории и вызывает функцию (например, ProcessCustomDirective - заказная директива обработки) для каждой из директив в этой категории. Таким образом, порядок обработки категорий может быть динамическим с помощью сохранения информации о приведении в исполнение в перманентном хранилище. На разных стадиях обработки синтаксический анализатор проверяет в перманентном хранилище, чтобы определить, имеется ли необходимость в приведении какой-либо категории метаданных в исполнение в это время. Это предоставляет категориям возможность быть легко исключенными посредством удаления содержимого категории из перманентного хранилища.
Примерная обработка символьных строк команды
Далее описана одна из примерных последовательностей операций для обработки командных символьных строк. Фиг.13 - функциональная блок-схема, графически иллюстрирующая обработку символьной строки 1350 команды посредством синтаксического анализатора 220 и главной машины 224 в пределах оболочки административного инструментального средства, показанной на фиг. 2. Примерная символьная строка команды 1350 конвейерно обрабатывает несколько команд (например, команду 1360 обработки, команду 1362 места, команду 1364 сортировки и команду 1366 занесения в таблицу). Командная строка 1350 может посылать входные параметры любой из команд (например, «handlecount>400» - «номер обработчика», послан команде 1362 места). Иногда будет замечено, что команда 1360 обработки не имеет каких-либо ассоциативно связанных параметров ввода.
В прошлом каждая команда была ответственна за осуществление синтаксического анализа параметров ввода, ассоциативно связанных с командой, определяя, были ли параметры ввода действительными, и выпуская сообщения об ошибке, если параметры ввода не были действительными. Поскольку команды были типично написаны различными программистами, синтаксис для параметров ввода по командной строке не был совершенно непротиворечивым. В дополнение, если происходила ошибка, то сообщение об ошибке, даже для одной и той же ошибки не было совершенно непротиворечивым от команды к команде.
Например, в UNIX-окружении команда «ls» и команда «ps» имеют много противоречий между собой. Хотя обе из них допускают элемент выбора «-w», командой «ls» элемент выбора «-w» использован, чтобы обозначать ширину страницы, тогда как командой «ps» элемент выбора «-w» использован, чтобы обозначать ширину вывода печати (в сущности, игнорируя ширину страницы). Страницы помощи, ассоциативно связанные с командами «ls» и «ps», также имеют некоторые противоречия, такие как наличие выделенных полужирным шрифтом элементов выбора в одном и отсутствие в другом, упорядочивание элементов выбора в алфавитном порядке в одном и отсутствие его в другом, требование к некоторым элементам выбора в наличии тире и отсутствие такого требования к некоторым другим.
Настоящая оболочка административного инструментального средства предусматривает более непротиворечивый подход и минимизирует количество повторного кода, который каждый разработчик должен написать. Оболочка 200 административного инструментального средства предусматривает синтаксис (например, грамматику), соответствующую семантику (например, в виде словаря), и эталонную модель, чтобы позволить разработчикам легко получать преимущество общих функциональных возможностей, предусмотренных оболочкой 200 административного инструментального средства.
Перед всем дальнейшим описанием настоящего изобретения предусмотрены определения для дополнительных терминов, встречающихся по всей этой спецификации. Входные параметры указываются ссылкой на входные поля для командного апплета. Аргументы указываются ссылкой на входные параметры, пересылаемые командному апплету, которые являются эквивалентом одиночной символьной строки в массиве argv, или пересылаемые в качестве одиночного элемента в объекте командного апплета. Как будет описано ниже, командный апплет предусматривает механизм для специфицирования грамматики. Механизм может быть предусмотрен непосредственно или опосредованно. Аргумент является одним из элемента выбора, необязательного аргумента, или операндом, следующим за командным наименованием. Примеры аргументов даны, основываясь на следующей командной строке:
findstr/i/d:\winnt;\winnt\system32aa*b.ini.
В приведенной выше командной строке, «findstr» является аргументом 0, «/i» является аргументом 1, «/d:\winnt;winnt\system32» является аргументом 2, «aa*b» является аргументом 3 и «*.ini» является аргументом 4. «Элемент выбора» является аргументом по отношению к командному апплету, который в общем случае использован, чтобы специфицировать изменения для определенного по умолчанию поведения программы. Продолжая вышеприведенный пример командной строки, «/i» и «/d» являются элементами выбора. «Необязательный аргумент» является входным параметром, который следует за определенными элементами выбора. В некоторых случаях необязательный аргумент включен в пределы той же самой символьной строки аргумента, что и элемент выбора. В других случаях необязательный аргумент включен в пределы в качестве следующего аргумента. Снова ссылаясь на приведенную выше командную символьную строку, «/d:\winnt;winnt\system32» является необязательным аргументом. «Операнд» является аргументом по отношению к командному апплету, который в общем случае использован в качестве объекта, поставляющего информацию программе, необходимую для завершения программной обработки. Операнды в общем случае следуют за элементами выбора в командной строке. Снова ссылаясь на приведенную выше команду, «aa*b» и «*.ini» являются операндами. «Синтаксически анализируемый поток» включает в себя аргументы.
Ссылаясь на фиг.13, синтаксический анализатор 220 анализирует синтаксически анализируемый поток (например, командную символьную строку 1350) до составляющих частей 1320-1326 (например, порция положения 1322). Каждая порция 1320-1326 ассоциативно связана с одним из командных апплетов 1330-1336. Синтаксический анализатор 220 и машина 224 выполняют различную обработку, такую как синтаксический разбор, проверку действительности параметра, выработку данных, обработку параметра, кодирование параметра и документирование параметра. Поскольку синтаксический анализатор 220 и машина 224 выполняют общие функциональные возможности над входными параметрами на командной строке, оболочка 200 административного инструментального средства способна выдавать пользователям непротиворечивые сообщения об ошибках.
Как каждый будет осознавать, приводимые в исполнение командные апплеты 1330-1336, написанные в соответствии с настоящей оболочкой административного командного средства, требуют меньшего кода, чем команды в предшествующих административных окружениях. Каждый приводимый в исполнение командный апплет 1330-1336 идентифицирован, используя его соответственную составляющую часть 1320-1326. В дополнение, каждый приводимый в исполнение командный апплет 1330-1336 выводит объекты (представлено стрелками 1340, 1342, 1344 и 1346), которые являются входными данными в качестве входных объектов (представлено стрелками 1341, 1343 и 1345) по отношению к следующему конвейерно обрабатываемому командному апплету. Эти объекты могут быть введены путем отправки ссылки (например, дескриптора) на объект. Приводимые в исполнение командные апплеты 1330-1336 могут затем выполнять дополнительную обработку над объектами, которые были пересланы.
Фиг.14 является логической блок-схемой, иллюстрирующей более детально обработку командных символьных строк, подходящую для использования в пределах последовательности операций для специальной обработки входных данных, показанной на фиг.9. Обработка командной символьной строки начинается на этапе 1401, где синтаксический анализатор или машина сценария идентифицировали командную символьную строку в пределах входных данных. В общем случае главная машина выполняет расстановку и упорядочивание потока данных командных апплетов. Расстановка и упорядочивание для одного из командных апплетов описана ниже, но является применимой к каждому командному апплету в конвейре. Обработка продолжается на этапе 1404.
На этапе 1404 командный апплет идентифицирован. Идентификация командного апплета может происходить в течение регистрации. Главная машина определяет, является ли командный апплет локальным или удаленным. Командный апплет может приводиться в исполнение в последующих местоположениях: 1) в пределах области применения оболочки административного инструментального средства; 2) в пределах другой области применения той же самой последовательности операций, такой как оболочка административного инструментального средства; 3) в пределах другой последовательности операций на том же самом вычислительном устройстве; или 4) в пределах удаленного вычислительного устройства. Связь между командными апплетами, действующая в пределах одной и той же последовательности операций, является связью через объекты. Связь между командными апплетами, действующими в пределах разных последовательностей операций, является связью через формат упорядоченных структурированных данных. Один из форматов упорядоченных структурированных данных основан на расширяемом языке разметки (XML). Обработка продолжается на этапе 1406.
На этапе 1406 создан экземпляр командного апплета. Примерный способ для создания экземпляра командного апплета описан ниже в связи с фиг.15. Как только объект командного апплета создан, обработка продолжается на этапе 1408.
На этапе 1408 заполнены свойства, ассоциативно связанные с объектом командного апплета. Как описано выше, разработчик объявляет свойства в пределах класса командного апплета или в пределах внешнего источника. Кратко, оболочка административного командного средства будет расшифровывать объект(ы), поступающие в командный апплет, подвергнутый присваиванию значений из класса командного апплета, основываясь на наименовании и типе, которые объявлены для свойства. Если типы являются разными, тип может быть приведен посредством управляющей программы базового типа. Как установлено ранее, в конвейерно обрабатываемых символьных строках команды выходные данные каждого командного апплета могут быть перечнем дескрипторов для объектов. Следующий командный апплет может вводить этот перечень объектных дескрипторов, выполнять обработку и отправлять другой перечень объектных дескрипторов следующему командному апплету. В дополнение, как проиллюстрировано на фиг.7, входные параметры могут быть специфицированы как поступающие из командной строки. Одна из примерных последовательностей операций для наполнения свойств, ассоциативно связанных с командным апплетом, описана ниже в связи с фиг. 16. Как только командный апплет наполнен, обработка продолжается на этапе 1410.
На этапе 1410 командный апплет приводится в исполнение. В общем виде обработка, предусмотренная командным апплетом, выполнена по меньшей мере один раз, который включает в себя обработку для каждого входного объекта по отношению к командному апплету. Таким образом, если командный апплет является первым командным апплетом в пределах конвейерно обрабатываемой символьной строки команды, то обработка выполняется один раз. Для последующих командных апплетов обработка приведена в исполнение для каждого объекта, который отправлен командному апплету. Одна из примерных последовательностей операций для приведения в исполнение командных апплетов описана ниже в связи с фиг. 5. Когда входные параметры только поступают из командной строки, приведение в исполнение командного апплета использует методы по умолчанию, предусмотренные комплектацией базового командного апплета. Как только командный апплет заканчивает приведение в исполнение, обработка направляется на этап 1412.
На этапе 1412 командный апплет окончательно завершен. Это включает в себя вызов деструктора для ассоциативно связанных объектов командного апплета, который ответственен за освобождение памяти и подобные действия. После этого обработка командного апплета завершена.
Примерная последовательность операций для создания
объекта командного апплета
Фиг.15 - блок-схема, иллюстрирующая примерную последовательность операций для создания объекта командного апплета, подходящую для использования в пределах обработки символьных строк команды, показанной на фиг.14. В этой точке структура данных командного апплета была разработана и атрибуты и ожидаемые входные параметры были специфицированы. Командный апплет был скомпилирован и зарегистрирован. Во время регистрации наименование класса (то есть наименование командного апплета) записано в хранилище регистрационных данных и были сохранены метаданные, ассоциативно связанные с командным апплетом. Последовательность операций 1500 начинается на этапе 1501, где синтаксический анализатор принял входные данные (например, последовательность нажатий клавиш), показывающие командный апплет. Синтаксический анализатор может распознавать входные данные как командный апплет путем отыскивания входных данных в пределах реестра и ассоциативного связывания входных данных с одним из зарегистрированных командных апплетов. Обработка направляется на этап 1504.
На этапе 1504 прочитаны метаданные, ассоциативно связанные с классом объекта командного апплета. Метаданные включают в себя любые из директив, ассоциированных с командным апплетом. Директивы могут применяться к самому командному апплету или одному или более параметров. Во время регистрации командного апплета код регистрации регистрирует метаданные в перманентном хранилище. Метаданные могут быть сохранены в XML-файле в упорядоченном формате, внешней базе данных и подобных. Подобно обработке директив, во время обработки сценария каждая категория директив обработана на разной стадии. Каждая директива метаданных специально обрабатывает свою собственную обработку ошибок. Обработка продолжается на этапе 1508.
На этапе 1508 получена информация о командном апплете. Это может происходить через осмысление или другими средствами. Информация является информацией об ожидаемых входных параметрах. Как установлено выше, параметры, которые объявлены открытыми (например, открытое наименование Name 730 символьной строки), соответствуют ожидаемым входным параметрам, которые могут быть специфицированы в символьной строке команды в командной строке или предусмотрены во входном потоке данных. Оболочка административного командного средства через управляющую программу расширенного типа, описанную на Фиг.18, предусматривает общий интерфейс для возвращения информации (в необходимом базисе) вызывающей программе. Обработка продолжается на этапе 1510.
На этапе 1510 применены директивы применимости (например, по таблице 1). Директивы применимости гарантируют, что класс использован в определенного рода ролевых именах машины и/или ролевых именах пользователя. Например, определенного рода командные апплеты могут быть использованы только администраторами домена. Если ограничительные условия, специфицированные в одной из директив применимости, не встретились, происходит ошибка. Обработка продолжается на этапе 1512.
На этапе 1512 метаданные использованы, чтобы предусмотреть знания. К этой точке обработки целостная символьная строка команды еще не была введена. Оболочке административного инструментального средства, однако, известны доступные командные апплеты. В то время как командный апплет определен, оболочке административного командного средства известны входные параметры, которые позволены осмыслением объекта командного апплета. Таким образом, оболочка административного командного средства может автоматически дополнять командный апплет, как только предусмотрена устраняющая противоречия порция имени командного апплета, и затем автоматически дополнять входной параметр, как только в строке ввода команды была набрана устраняющая противоречия порция входного параметра. Автоматическое дополнение может происходить, коль скоро порция входного параметра может недвусмысленно идентифицировать один из входных параметров. В дополнение, автоматическое дополнение может происходить в отношении наименований командного апплета, а также в отношении операндов. Обработка продолжается на этапе 1514.
На этапе 1514 программный процесс ожидает до тех пор, пока входные параметры для командного апплета не будут введены. Это может происходить, как только пользователь показал окончание командной символьной строки, к примеру, нажатием на клавишу возврата каретки. В сценарии новая строка показывает окончание командной символьной строки. Это ожидание может включать в себя получение дополнительной информации от пользователя, касательно параметров и применения других директив. Когда командный апплет является одним из конвейерно обрабатываемых параметров, обработка может начинаться немедленно. Как только необходимая командная символьная строка и входные параметры были предусмотрены, обработка завершается.
Примерная последовательность операций
для наполнения командного апплета
Примерная последовательность операций для наполнения командного апплета проиллюстрирована на фиг.16 и далее описана в связи с фиг.5. В одной из примерных оболочек административного инструментального средства главная машина выполняет обработку, чтобы заполнить параметры для командного апплета. Обработка начинается на этапе 1601 после момента, когда командный апплет был создан. Обработка продолжается до этапа 1602.
На этапе 1602 извлечен параметр (например, ProcessName - наименование последовательности операций), объявленный в пределах командного апплета. На основании объявления в командном апплете главная машина распознает, что поступающий входной объект будет предусматривать свойство «ProcessName». Если тип поступающего свойства отличается от типа, специфицированного в объявлении параметра, то тип будет приведен посредством управляющей программы расширенного типа. Последовательность операций приведения типов данных объяснен ниже в подразделе, озаглавленном «Примерная обработка управляющей программы расширенного типа». Обработка продолжается до этапа 1603.
На этапе 1603 получен атрибут, ассоциативно связанный с параметром. Атрибут идентифицирует, является ли входным источником для параметра командная строка или он поступает из конвейера. Обработка продолжается до этапа принятия решения 1604.
На этапе 1604 принятия решения сделано определение того, специфицирует ли атрибут источник ввода в качестве командной строки. Если источником ввода является командная строка, обработка продолжается на этапе 1609. Иначе обработка продолжается на этапе 1605 принятия решения.
На этапе 1605 принятия решения сделано определение, должно ли быть использовано наименование свойства, специфицированного в объявлении, или должно быть использовано сопоставление для наименования свойства. Это определение основано на любом сопоставлении для параметра, специфицированного входными данными команды. Последующая строка ввода иллюстрирует примерное преобразование параметра «ProcessName» в член «foo» («нечто») поступающего объекта.
$get/process|wherehan*-gt500|stop/process-ProcessName<-foo.
Обработка продолжается на этапе 1606.
На этапе 1606 применено сопоставление. Преобразование замещает наименование ожидаемого параметра «ProcessName» на «foo», которое затем использовано главной машиной для синтаксического анализа поступающих объектов и для идентификации корректного ожидаемого параметра. Обработка продолжается на этапе 1608.
На этапе 1608 управляющая программа расширенного типа требуется для локализации значения для параметра в пределах поступающего объекта. Как пояснено в связи с управляющей программой расширенного типа, управляющая программа расширенного типа приобретает наименование параметра и использует осмысление для идентификации параметра в пределах поступающего объекта по наименованию параметра. Если необходимо, управляющая программа расширенного типа может также выполнять другую обработку для параметра. Например, управляющая программа расширенного типа может переопределять тип данных в ожидаемый тип данных через механизм конвертации, описанный выше. Обработка продолжается до этапа 1610 принятия решения.
Снова ссылаясь на этап 1609, если атрибут специфицирует, что источником входных данных является командная строка, то данные получены из командной строки. Получение данных из командной строки может быть выполнено посредством управляющей программы расширенного типа. Обработка затем продолжается до этапа 1610 принятия решения.
На этапе 1610 принятия решения определено, имеется ли в наличии другой ожидаемый параметр. Если есть другой ожидаемый параметр, то обработка снова зацикливается на этап 1602 и продолжает движение, как описано выше. Иначе обработка завершается и возвращает результаты.
Таким образом, как показано, командный апплет действует в качестве шаблона для деления на небольшие порции поступающих данных, чтобы получать ожидаемые параметры. В дополнение, ожидаемые параметры получены, не зная типа поступающего объекта, предусматривающего значение для ожидаемого параметра. Это является совершенно отличающимся от традиционных административных окружений. Традиционные административные окружения непроницаемо ограничены и требуют, чтобы тип объекта был известен во время компиляции. В дополнение, в традиционных окружениях, ожидаемый параметр должен быть переслан в функцию значением или ссылкой. Таким образом, настоящий механизм синтаксического анализа (например, «деления на небольшие порции») предоставляет программистам возможность специфицировать тип параметра, не требуя от них специального знания того, каким образом получены значения этих параметров.
Например, дано следующее определение для командного апплета Foo:
class Foo: Cmdlet
{
string Name;
Bool Recurse;
}
Синтаксис строки ввода команды может быть одним из следующих:
$ Foo -Name: (string) -Recurse: True
$ Foo -Name: <string> -Recorse True
$Foo -Name(string).
Множество правил может быть модифицировано системными администраторами для того, чтобы вырабатывать желаемый синтаксис. В дополнение, синтаксический анализатор может поддерживать многочисленные множества правил так, что более чем один синтаксис может быть использован пользователями. В сущности, грамматика, ассоциативно связанная со структурой командного апплета (например, наименование символьной строки и булева рекурсия), управляет синтаксическим анализатором.
В общем случае директивы синтаксического анализа описывают, каким образом параметры, введенные в качестве командной символьной строки, могут преобразовываться в ожидаемые параметры, идентифицированные в объекте командного апплета. Типы входных параметров проверены, чтобы убедиться, корректны ли они. Если типы входных параметров являются некорректными, то входные параметры могут быть переопределены, чтобы стать корректными. Если типы входных параметров являются некорректными и не могут быть переопределены, печатается ошибка использования. Ошибка использования предоставляет пользователю возможность постигать корректный синтаксис, который ожидаем. Ошибка использования может способствовать получению информации, описывающей синтаксис, из директив документирования. Как только типы входного параметра были преобразованы или подтверждены, то заполнены соответствующие члены экземпляра объекта командного апплета. Когда члены заполнены, управляющая программа расширенного типа предусматривает обработку типов входных параметров. Кратко, обработка может включать механизм пути свойства, механизм ключа, механизм сравнения, механизм конвертации, механизм универсализации, механизм родства и механизм набора свойства. Каждый из этих механизмов детально описан ниже, в разделе, озаглавленном «Обработка управляющей программы расширенного типа», который также включает иллюстративные примеры.
Примерная последовательность операций
для обработки командного апплета
Примерная последовательность операций для приведения в исполнение командного апплета проиллюстрирована на фиг.17 и описана далее. В одном из примерных окружений административного инструментального средства главная машина приводит в исполнение командный апплет. Как установлено выше, код 1442 в пределах второго метода 1440 приведен в исполнение для каждого входного объекта. Обработка начинается на этапе 1701, где командный апплет уже был заполнен. Обработка продолжается на этапе 1702.
На этапе 1702 выражение из кода 542 извлечено для приведения в исполнение. Обработка продолжается на этапе принятия решения 1704.
На этапе принятия решения 1704 сделано определение того, включена ли ловушка в пределы выражения. Кратко обращаясь к фиг.5, ловушка может включать в себя вызов API (прикладного интерфейса программирования), предусмотренный главной машиной. Например, выражение 550 в пределах кода 542 командного апплета 500 по фиг. 5 вызывает API подтвержденной обработки, специфицирующей необходимые параметры, первую символьную строку (например, «PID=») и параметр (например, PID). Снова обращаясь к фиг.17, если выражение включает в себя ловушку, то обработка продолжается до этапа 1712. Таким образом, если специфицирована инструкция, вызывающая API подтвержденной обработки, то командный апплет действует в режиме поочередного приведения в исполнение, который предусмотрен операционным окружением. Иначе обработка продолжается на этапе 1706 и исполнение продолжается в «нормальном» режиме.
На этапе 1706 выражение обработано. Обработка затем направляется на этап 1708 принятия решения. На этапе 1708 сделано определение того, включает ли в себя код еще одно выражение. Если имеется в наличии другое выражение, обработка снова зацикливается на этап 1702, чтобы взять следующее выражение, и продолжает движение, как описано выше. Иначе обработка продолжается до этапа 1714 принятия решения.
На этапе 1714 принятия решения сделано определение того, имеется ли в наличии еще один входной объект для обработки. Если есть еще один входной объект, то обработка продолжается до этапа 1716, где командный апплет заполнен данными из следующего объекта. Способ заполнения, описанный на фиг.16, выполнен со следующим объектом. Как только все объекты были обработаны, способ по приведению в исполнение завершен и возвращает данные.
Снова обращаясь к этапу 1704 принятия решения, если выражение включает в себя ловушку, обработка продолжается до этапа 1712. На этапе 1712 обработаны дополнительные признаки, предусмотренные окружением административного командного средства. Обработка продолжается до этапа 1708 принятия решения и продолжается, как описано выше.
Дополнительная обработка, выполненная в пределах этапа 1712 принятия решения, далее описана в соединении с примерной структурой 600 данных, проиллюстрированной на фиг.6. Как объяснено выше, в пределах базового класса 600 команды могут находиться объявленные параметры, которые соответствуют дополнительным ожидаемым входным параметрам (например, ключ).
Ключ включает в себя предопределенную символьную строку и, когда определен, направляет главную машину, чтобы предусматривать дополнительные функциональные возможности для командного апплета. Если слово 610 параметра специфицировано во входных данных команды, словесное выражение 614 приведено в исполнение. Последующее является примером командной строки, которая включает в себя словесный ключ:
$ get/process|where“han*-gt500”|stop/process-verbose.
В общем виде, когда “-verbose” специфицировано в пределах входных данных команды, главная машина приводит в исполнение команду для каждого входного объекта и переправляет действующую команду, которая была приведена в исполнение для каждого входного объекта, в командную строку централизованного вычислительного устройства для отображения. Последующее является примером вывода, выработанного, когда приведенная выше командная строка приведена в исполнение в примерном окружении административного инструментального средства:
$stop/processPID=15
$stop/processPID=33.
Если условие 620 параметра специфицировано во входных данных команды, выражения 624 условия приведены в исполнение. Последующее является примером строки ввода команды, которая включает ключ условия:
$get/process|where“han*-gt500”|stop/process-whatif.
В общем виде, когда “-whatif” («-условие») специфицировано, главная машина в действительности не приводит в исполнение код 542, но, вернее, отправляет команды, которые должны быть приведены в исполнение централизованной программе для отображения. Последующее является примером вывода, вырабатываемого, когда приведенная выше командная строка приведена в исполнение в окружении административного инструментального средства по настоящему изобретению:
#$stop/processPID=15
#$stop/processPID=33
Если подтверждение 630 параметра специфицировано во входных данных команды, выражения 634 подтверждения приведены в исполнение. Последующее является примером строки ввода команды, которая включает в себя ключ подтверждения:
$get/process|where“han*-gt500”|stop/process-confirm.
В общем случае, когда “-confirm” («-подтверждение») специфицирован, главная машина запрашивает дополнительный пользовательский ввод по поводу того, возобновлять ли команду или нет. Последующее является примером вывода, выработанного, когда упомянутая выше командная строка приведена в исполнение в окружении административного инструментального средства по настоящему изобретению.
#$stop/processPID 15
Y/N Y
#$stop/processPID 33
Y/N N.
Как описано выше, примерная структура 600 данных может также включать в себя метод 640 обеспечения безопасности, который определяет, может ли быть позволена задача, запрашиваемая на приведение в исполнение. В традиционных административных окружениях каждая команда ответственна за осуществление проверки, имеет ли персона, приводящая в исполнение команду, достаточные права, чтобы выполнять команду. Для того чтобы выполнять эту проверку, необходим протяженный код для осуществления доступа к информации из нескольких источников. Вследствие этих сложностей многие команды не выполняли проверку обеспечения безопасности. Изобретатели настоящего окружения административного инструментального средства осознавали, что, когда задача специфицирована во входных данных команды, необходимая информация для выполнения проверки обеспечения безопасности доступна в пределах окружения административного инструментального средства. Следовательно, оболочка административного инструментального средства выполняет проверку обеспечения безопасности, не требуя сложного кода от разработчиков инструментального средства. Проверка обеспечения безопасности может быть выполнена для любого командного апплета, который определяет ловушку в пределах своего командного апплета. В качестве альтернативы, ловушка может быть необязательным входным параметром, который может быть специфицирован во входных данных команды, подобно словесному параметру, описанному выше.
Проверка обеспечения безопасности применена, чтобы поддерживать основанную на ролевых именах аутентификацию, которая обычно определена по ролевому имени пользователя. Таким образом, каждое ролевое имя является назначенными определенного рода правами доступа к разным ресурсам. Затем назначен пользователь для одного или более ролевых имен. В общем случае, основанная на ролевых именах аутентификация фокусируется на трех отдельных предметах: правиле, ресурсе и действии. Правило идентифицирует, кто запрашивал действие, чтобы оно было выполнено над ресурсом.
Изобретатели настоящего изобретения осознавали, что командный апплет, являющийся запрошенным, соответствовал действию, которое должно было быть выполнено. В дополнение, изобретатели принимали во внимание, что владелец последовательности операций, в которой оболочка административного инструментального средства приводилась в исполнение, относилась к правилу. Более того, изобретатели принимали во внимание, что ресурс специфицирован в пределах командного апплета. Следовательно, поскольку оболочка административного инструментального средства имела доступ к этим отдельным предметам, изобретатели осознавали, что проверка обеспечения безопасности могла быть выполнена из пределов оболочки административного инструментального средства, не требуя от разработчиков инструментального средства применения проверки обеспечения безопасности.
Операция проверки обеспечения безопасности может быть выполнена каждый раз, когда дополнительные, функциональные возможности запрошены в пределах командного апплета, путем использования ловушки, такой как API-интерфейс подтвержденной обработки. В качестве альтернативы, проверка обеспечения безопасности может быть выполнена проверкой того, был ли введен ключ безопасности по строке ввода команды, подобно слову, условию и подтверждению. Для любого из двух применений метод checkSecurity (проверить безопасность) вызывает API-интерфейс, предусмотренный последовательностью операций обеспечения безопасности (не показана), которая предусматривает множество API-интерфейсов для определения тех, кто допущен. Последовательность операций приобретает информацию, предусмотренную оболочкой административного инструментального средства, и предусматривает результат, показывающий, может ли задача быть завершена. Оболочка административного инструментального средства может затем предусматривать ошибку или просто прекращение приведения в исполнение задачи.
Таким образом, с помощью предусмотрения ловушки в пределах командного апплета разработчики могут использовать дополнительную обработку, предусмотренную оболочкой административного инструментального средства.
Примерная обработка управляющей программы
расширенного типа
Как кратко установлено выше в соединении с фиг.18, управляющая программа расширенного типа может выполнять дополнительную обработку над объектами, которые поставлены. Дополнительная обработка может быть выполнена при запросе синтаксического анализатора 220, машины 222 сценария или обработчика 402 конвейера. Дополнительная обработка включает в себя механизм пути свойства, механизм переключателя, механизм сравнения, механизм конвертации, механизм универсализации, механизм родства и механизм набора свойства. Специалисты в данной области техники будут принимать во внимание, что управляющая программа расширенного типа также может быть расширена другой обработкой, не выходя за пределы объема заявленного изобретения. Далее описан каждый из дополнительных механизмов.
Прежде всего, механизм пути свойства предоставляет возможность символьной строке осуществлять навигацию свойств объектов. В современных системах преобразования запросы могут запрашивать свойства объекта. Однако в настоящей управляющей программе расширенного типа может быть специфицирована символьная строка, которая будет предусматривать навигационный путь к доступным свойствам объекта. Последующее является иллюстративным синтаксисом для пути свойства: P1.P2.P3.P4.
Каждый компонент (например, P1, P2, P3 и P4) содержит символьную строку, которая может представлять свойство, метод с параметрами, метод без параметров, поле, XPATH (расширение пути) или подобное. XPATH специфицирует символьную строку запроса для поиска элемента (например, “/FOO$=13”). В пределах символьной строки специальный символ может быть включен, чтобы специально показать тип компонента. Если символьная строка не содержит в себе специальный символ, управляющая программа расширенного типа может выполнять просмотр, чтобы определить тип компонента. Например, если компонент P1 является объектом, управляющая программа расширенного типа может запросить, является ли P2 свойством объекта, методом над объектом, полем объекта или установкой свойства. Как только управляющая программа расширенного типа идентифицирует тип для P2, выполнена обработка согласно такому типу. Если компонент не является одним из упомянутых выше типов, управляющая программа расширенного типа может дополнительно запрашивать расширенные источники, чтобы определить, имеется ли в наличии функция преобразования, чтобы преобразовать тип P1 в тип P2. Эти и другие просмотры будут далее описаны, используя иллюстративную строку ввода команды и показывая соответственный вывод.
Последующее является иллюстративной символьной строкой, которая включает в себя путь свойства:
$get/process|/where hand* -gt>500|format/table name.toupper, ws.kb,exe*.ver*.description.tolower.trunc(30).
В приведенной выше иллюстративной символьной строке есть три пути свойства: (1) «name.toupper»; (2) «ws.kb»; и «exe*.ver*.description.tolower.trunc(30)». Перед описанием этих путей свойств следует обратить внимание на то, что «name» «ws» и «exe» специфицируют свойства для таблицы. В дополнение, следует обратить внимание на то, что каждое из этих свойств является непосредственным свойством входного поступающего объекта, первоначально выработанного при помощи «get/process» и затем конвейерно обработанного через различные командные апплеты. Далее будет описана обработка, привлекаемая для каждого из трех путей свойства.
Во втором пути свойства (то есть «ws.kb»), «ws» является непосредственным свойством поступающего объекта и, в свою очередь, тоже является объектом. Управляющая программа расширенного типа определяет, что «ws» является целочисленным. Затем управляющая программа расширенного типа запрашивает, является ли целочисленным свойство «kb» или методом целочисленного типа, и в заключение запрашивает, знает ли какой-либо код, как получить целочисленное значение и преобразовать его в тип kb. Третья часть кода зарегистрирована, чтобы выполнить это преобразование, и преобразование выполнено.
В третьем пути свойства (то есть «exe*.ver*.description.tolower.trunc(30)») имеется несколько компонентов. Первый компонент («exe») является непосредственным свойством поступающего объекта ,и сам он также является объектом. К тому же, управляющая программа расширенного типа возобновляет просмотровый запрос для того, чтобы обрабатывать второй компонент («ver*»). Объект «exe*» не имеет свойства или метода «ver*», поэтому управляющая программа расширенного типа запрашивает расширенные метаданные, чтобы определить, есть ли какой-либо код, который зарегистрирован для осуществления преобразования приводимого в исполнение наименования в версию. Для этого примера такой код существует. Код может получить символьную строку приводимого в исполнение наименования и использовать ее, чтобы открыть файл, затем получить объект блока версии и возвратить свойство описания (третий компонент (“description” - «описание»)) объекта блока версии. Управляющая программа расширенного типа затем выполняет этот тот же самый механизм для четвертого компонента (“tolower” - «опустить») и пятый компонент (“trunc(40)” - «усечение до сорока символов»)). Таким образом, как проиллюстрировано, управляющая программа расширенного типа может выполнять действительно доскональную обработку над командной символьной строкой, не требуя от администратора писать какой-либо специальный код. Таблица 1 иллюстрирует вывод, выработанный для иллюстративной символьной строки:
Name.toupper s.kb.exe*.ver*.description.tolower.trunc(30)
Другой механизм 1824 запроса включает в себя ключ. Переключатель идентифицирует одно или несколько свойств, которые делают отдельный пример типа данных уникальным. Например, в базе данных один столбец может быть идентифицирован как ключ, который может уникально идентифицировать каждую последовательность (например, номер общественной службы безопасности). Ключ сохранен в пределах метаданных 1840, ассоциативно связанных с типом данных. Этот ключ может затем быть использован управляющей программой расширенного типа при обработке объектов такого типа данных. Тип данных может быть расширенным типом данных или существующим типом данных.
Другой механизм 1824 запроса включает в себя механизм сравнения. Механизм сравнения сравнивает два объекта. Если два объекта непосредственно поддерживают функцию сравнения, то приведена в исполнение непосредственно поддерживаемая функция сравнения. Однако, если ни тот ни другой объект не поддерживают функцию сравнения, управляющая программа расширенного типа может осматривать в метаданных типа код, который был зарегистрирован для поддержки сравнения двух объектов. Иллюстративные последовательности символьных строк командной строки, вызывающие механизм сравнения, показаны ниже вместе с соответствующим выводом по таблице 2.
$ $a=$(get/date)
$ start/sleep 5
$ $b=$(get/date)
compare/time $a $b
Командный апплет compare/time (сравнить время) написан для сравнения двух объектов даты и времени. В этом случае объект DateTime («дата и время») поддерживает интерфейс, способный сравнивать производительность.
Другой механизм 1824 запроса включает в себя механизм конвертации. Управляющая программа расширенного типа предоставляет коду возможность быть зарегистрированным, утверждая свою способность выполнять специальную конвертацию. Затем, когда объект типа A введен и командный апплет специфицирует объект типа B, управляющая программа расширенного типа может выполнять конвертацию, используя одну из зарегистрированных конвертаций. Управляющая программа расширенного типа может выполнять последовательности конвертаций, чтобы привести тип A к типу B. Путь свойства, описанный выше («ws.kb»), иллюстрирует механизм конвертации.
Еще один механизм 1824 запроса включает в себя механизм универсализации. Универсализатор указывается ссылкой на свободный символ в пределах символьной строки. Механизм универсализатора вводит символьную строку с групповым символом и производит множество объектов. Управляющая программа расширенного типа предоставляет возможность быть зарегистрированным коду, который специфицирует групповую обработку. Путь свойства, описанный выше (“exe*.ver*.description.tolower.trunk(30)), иллюстрирует механизм универсализатора. Зарегистрированная последовательность операций может предусматривать осуществление универсализации для имен файла, файловых объектов, поступающих свойств и подобного.
Еще один механизм 1824 запроса включает в себя механизм установки свойства. Механизм набора свойства предоставляет наименованию возможность быть определенным для множества свойств. Администратор может затем быть определен в различных направлениях. В одном из направлений предопределенный параметр, такой как “?”, может быть введен как входной параметр для командного апплета. Операционное окружение после распознавания предопределенного параметра составляет перечень всех свойств поступающего объекта. Перечень может быть GUI-интерфейсом, который предоставляет администратору возможность легко проверить (например, “click on” - «по нажатию клавиши мыши») желаемые свойства и дать наименование набору свойств. Информация о наборе свойств затем сохранена в расширенных метаданных. Ниже показана иллюстративная символьная строка, вызывающая механизм набора свойств, вместе с соответствующим выводом по таблице 3:
$ get/process|where han*-gt>500|format/table config.
В иллюстративной символьной строке набор свойств, названный “config” («конфигурационный»), был определен, чтобы включать в себя свойство наименования, свойство идентификатора последовательности операций (Pid) и свойство приоритета. Ниже по таблице показан вывод.
Другой механизм 1824 запроса включает в себя механизм родства. В отличие от систем традиционного типа, которые поддерживают такое родство (то есть наследование), механизм родства поддерживает выражение более чем одного родства типов. К тому же, эти родственные отношения зарегистрированы. Родство может включать нахождение отдельного предмета, который объект поглощает, или нахождение отдельного предмета, который поглощает объект. Управляющая программа расширенного типа может осуществлять доступ к онтологиям, которые описывают различные родственные взаимоотношения. Используя расширенные метаданные и код, может быть описана спецификация для осуществления доступа к какой-либо онтологической службе, такой как OWL (Object Windows Library - библиотека объектов Windows), DAWL (Data Access Windows Library - библиотека доступа к данным Windows) и подобным. Последующее является порцией иллюстративной символьной строки, которая употребляет механизм родства.OWL: “string” («символьная строка»).
Идентификатор «OWL» идентифицирует онтологическую службу, и “string” специфицирует специальную символьную строку в пределах онтологической службы. Таким образом, управляющая программа расширенного типа может осуществлять доступ к типам, поставляемым онтологическими службами.
Примерная последовательность операций для
отображения данных строки ввода команды
Настоящий механизм предусматривает управляемый данными вывод строки ввода команды. Форматирование и осуществление вывода данных предусмотрено одним или более командных апплетов в конвейере командных апплетов. Типично, эти командные апплеты включены в пределы неуправляющих командных апплетов, описанных выше в соединении с фиг.2. Командные апплеты могут включать в себя командный апплет формата, командный апплет разметки, командный апплет конвертации, командный апплет преобразования и командный апплет вывода.
Фиг.19 графически показывает примерные последовательности 1901-1907 этих командных последовательностей в пределах конвейера. Первая последовательность 1901 иллюстрирует командный апплет 1910 вывода в качестве последнего командного апплета в конвейере. Тем же самым образом, как описано выше для других командных апплетов, командный апплет 1910 вывода приемлет поток данных объектов конвейера, выработанных и обработанных другими командными апплетами в пределах конвейера. Однако в отличие от большинства командный апплет 1910 вывода не испускает объекты конвейера для других командных апплетов. Взамен командный апплет 1910 вывода ответственен за визуализацию/отображение результатов, выработанных конвейером. Каждый командный апплет 1910 вывода ассоциативно связан с пунктом назначения вывода, таким как устройство, программа и подобными. Например, для консольного устройства, командный апплет 1910 вывода может быть специфицирован в качестве вывода/консоли; для обозревателя Интернета, командный апплет 1910 вывода может быть специфицирован в качестве вывода/обозревателя; и для окна командный апплет 1910 вывода может быть специфицирован в качестве вывода/окна. Каждый специальный апплет вывода является близким по отношению к возможностям собственного ассоциативно связанного пункта назначения. Информация о местной специфике (например, форматы времени & продолжительности) обработаны командным апплетом 1910 вывода, за исключением командного апплета конвертации, предшествующего выходному командному апплету в конвейере. В этой ситуации, командный апплет обрабатывал локальную информацию.
Каждое централизованное вычислительное устройство ответственно за осуществление поддержки определенного рода командных апплетов вывода, таких как командных апплетов вывода/консоли. Централизованное вычислительное устройство также поддерживает любые специфические пункты назначения, централизованные командные апплеты (например, вывода/диаграммы, который направляет вывод в диаграмму, предусмотренную приложением обработки таблиц). В дополнение, централизованное вычислительное устройство ответственно за предусмотрение обработки результатов по умолчанию. Командный апплет вывода в этой последовательности может принимать решение применить собственное поведение при помощи вызова других командных апплетов обработки вывода (таких как формата/разметки/конвертации/преобразования). Таким образом, командные апплеты вывода могут неявным образом модифицировать последовательность 1901 в любые другие последовательности или могут добавить свои собственные дополнительные командные апплеты формата/вывода.
Вторая последовательность 1902 иллюстрирует командный апплет 1920 формата перед командным апплетом 1910 вывода. Для этой последовательности командный апплет 1920 приемлет поток объектов конвейера, выработанных и обработанных другими командными апплетами в пределах конвейера. В общем виде командный апплет 1920 формата предусматривает образ действия для выбора свойств отображения и образ действия для специфицирования компоновки страницы, к примеру, очертания, ширины столбцов, заголовков, нижних колонтитулов и подобного. Очертание может включать в себя таблицу, развернутый перечень, колоночный перечень и подобное. В дополнение, командный апплет 1920 может включать в себя вычисления итогов или сумм. Примерная обработка, выполненная командным апплетом 1920 формата, описана ниже в связи с фиг.20. Кратко, командный апплет формата порождает объекты формата в дополнение к порождению конвейерных объектов. Объекты формата могут быть нисходящим потоком данных, распознаваемым командным апплетом вывода (например, командным апплетом 1920 вывода в последовательности 1902), посредством управляющей программы расширенного типа или другого механизма. Командный апплет 1920 вывода может выбрать либо использование порожденных объектов формата или может выбрать их игнорирование. Командный апплет вывода определяет компоновку страницы на основании данных компоновки страницы, специфицированных в информации об отображении. В определенного рода случаях модификации для компоновки страницы могут быть специфицированы выходным командным апплетом. В одной из последовательностей операций командный апплет вывода может определять неспецифицированную ширину колонки при помощи нахождения максимальной длины для каждого свойства предопределенного количества объектов (например, 50) и установки ширины столбца по максимальной длине. Объекты формата включают в себя информацию о форматировании, информацию о заголовке/нижнем колонтитуле и подобную.
Третья последовательность 1903 иллюстрирует командный апплет формата перед командным апплетом 1910 вывода. Однако в третьей последовательности командный апплет 1930 разметки конвейерно обработан между командным апплетом 1920 формата и командным апплетом 1910 вывода. Командный апплет 1930 разметки предусматривает механизм для добавления аннотации свойства (например, шрифт, цвет) для выбранных параметров. Таким образом, командный апплет 1930 разметки появляется перед командным апплетом 1910 вывода. Аннотации свойства могут быть применены, используя «сопутствующий набор значений свойства» или путем добавления аннотаций свойства в сделанном на заказ пространстве имен в наборе значений свойства. Командный апплет 1930 разметки может появляться перед командным апплетом 1920 формата до тех пор, пока аннотации разметки могут быть поддержаны в работоспособном состоянии во время обработки командного апплета 1920 формата.
Четвертая последовательность 1904 снова иллюстрирует командный апплет 1920 перед командным апплетом 1910 вывода. Однако в четвертой последовательности 1904 командный апплет 1940 конвертации конвейерно обработан между командным апплетом 1920 и командным апплетом 1910. Командный апплет 1940 конвертации также сконфигурирован, чтобы обрабатывать объекты формата, порожденные командным апплетом 1920 формата. Командный апплет 1940 конвертирует конвейерно обрабатываемые объекты в специальную кодировку, основанную на объектах формата. Командный апплет 1940 конвертации ассоциативно связан со специальной кодировкой. Например, командный апплет 1940 конвертации, который преобразует конвейерно обрабатываемые объекты в объекты активных каталогов (ADO), может быть объявлен в командной строке как “convert/ADO” («конвертировать/ADO»). Подобным образом, командный апплет 1940 конвертации, который конвертирует конвейерно обрабатываемые объекты в разделенные запятыми значения (comma separated values - csv), может быть объявлен как “convert/csv” («преобразовать/csv») в командной строке. Некоторые из командных апплетов 1940 конвертации (например, convert/XML и convert/html - конвертировать/XML и конвертировать/html) могут быть блокирующими командами, означающими, что все конвейерно обрабатываемые объекты приняты до приведения в исполнение конвертации. Типично, командный апплет 1920 вывода может определять, следует ли использовать информацию о форматировании, предусмотренную объектами формата. Однако, когда командный апплет 1940 конвертации появляется перед командным апплетом 1920 вывода, действующее преобразование данных уже произошло до того, как командный апплет вывода принимает объекты. Следовательно, в этой ситуации командный апплет вывода не может игнорировать конвертацию.
Пятая последовательность 1905 иллюстрирует командный апплет 1920 формата, командный апплет 1930 разметки, командный апплет 1940 конвертации и командный апплет 1910 вывода именно в таком порядке. Таким образом, это иллюстрирует, что командный апплет 1930 разметки может появляться перед командным апплетом 1940 конвертации.
Шестая последовательность 1906 иллюстрирует командный апплет 1920 формата, специальный командный апплет конвертации (например, командный апплет 1940' конвертировать/xml), специальный командный апплет преобразования (например, командный апплет 1950 преобразовать/xslt) и командный апплет 1910 вывода. Командный апплет 1940' конвертировать/xml конвертирует конвейерно обрабатываемые объекты в документ расширяемого языка разметки (XML). Командный апплет 1950 преобразовать/xslt преобразует XML-документ в иной XML-документ, используя расширяемый язык стилей (XSL) таблицы стилей. Последовательность операций преобразования, обобщенно указываемая ссылкой как преобразование расширяемого языка стилей (XSLT), в которой XSL-обработчик читает XML-документ и следует инструкциям в пределах XSL-таблицы стилей, чтобы создать новый XML-документ.
Седьмая последовательность 1907 иллюстрирует командный апплет 1920 формата, командный апплет 1930 разметки, специальный командный апплет конвертации (например, командный апплет 1940' конвертировать/xml), специальный командный апплет преобразования (например, командный апплет 1950 преобразовать/xslt) и командный апплет 1910 вывода. Таким образом, седьмая последовательность 1907 иллюстрирует получение восходящего потока командного апплета 1930 разметки из командного апплета конвертации и командного апплета преобразования.
Фиг.20 иллюстрирует примерную обработку 2000, выполняемую командным апплетом формата. Последовательность операций форматирования начинается на этапе 2001 после того, как командный апплет формата был синтаксически проанализирован и вызван синтаксическим анализатором и обработчиком конвейера описанным выше образом. Обработка продолжается на этапе 2002.
На этапе 2002 конвейерный объект принят в качестве входных данных для командного апплета формата. Обработка продолжается на этапе 2004.
На этапе 2004 инициирован запрос на идентификацию типа для конвейерно обрабатываемого объекта. Этот запрос выполнен управляющей программой расширенного типа, как описано ранее в связи с фиг. 18. Как только управляющая программа расширенного типа идентифицировала тип для объекта, обработка продолжается на этапе 2006.
На этапе 2006 идентифицированный тип отыскивается в информации об отображении. Примерный формат для информации об отображении проиллюстрирован на фиг.21 и будет описан ниже. Обработка продолжается на этапе 2008 принятия решения.
На этапе 2008 принятия решения сделано определение того, специфицирован ли идентифицированный тип в пределах информации об отображении. Если содержимого для идентифицированного типа в пределах информации об отображении нет, то обработка завершается. Иначе обработка продолжается на этапе 2010.
На этапе 2010 из информации об отображении получена информация о форматировании, ассоциативно связанная с идентифицированным типом. Обработка продолжается на этапе 2012.
На этапе 2012 информация порождена на конвейере. Как только информация порождена, обработка завершена.
Примерная информация, которая может быть порождена, далее описана более подробно. Информация может включать в себя информацию о форматировании, информацию о верхнем/нижнем колонтитуле и объект сигнала об окончании/начале группы. Информация о форматировании может включать в себя очертание, метку, нумерацию/маркировку, ширину столбцов, тип символьной кодировки, свойства шрифта содержания, длину страницы, наименование группирования по свойствам или подобное. Каждый из них может иметь дополнительные спецификации, ассоциативно связанные с ним. Например, очертание может специфицировать, является ли очертание таблицей, перечнем или подобным. Метки могут специфицировать, использовать ли заголовки столбца, метки перечня или подобное. Кодировка символов может специфицировать ASCII (американская стандартная кодировка для обмена информацией), UTF-8 (универсальный шрифт для передачи), Unicode (универсальный символьная кодировка) и подобные. Свойства шрифта содержимого могут специфицировать шрифт, который применен для значений свойства, которые отображены. Свойство шрифта по умолчанию (например, Courier New, 10 pt - новый дипломатический с размером в 10 точек) может быть использовано, если свойства шрифта содержимого не специфицированы.
Информация о верхнем/нижнем колонтитуле может включать в себя область видимости верхнего/нижнего колонтитула, свойства шрифта, заголовок, подзаголовок, дату, время, нумерацию страниц, разделитель и подобное. Например, область видимости может специфицировать документ, страницу, группу или подобное. Дополнительные свойства могут быть специфицированы и для верхнего, и для нижнего колонтитула. Например, для нижних колонтитулов группы и документа дополнительные свойства могут включать в себя свойства или столбцы для вычисления суммы/итога, номеров объекта, символьных строк обозначения для итогов и номеров и подобное.
Объекты сигналов окончания/начала группы порождены, когда командный апплет формата обнаруживает, что группирование по свойству изменено. Когда это происходит, командный апплет формата имеет дело с потоком объектов конвейера в качестве предварительно отсортированных и не пересортировывает их. Объекты сигнала окончания/начала группы могут быть заинтересованы в объектах конвейера. Многочисленные группирования по свойствам могут быть специфицированы для вложенной сортировки. Командный апплет формата может также порождать объекты окончания формата, которые включают в себя окончательные суммы и итоги.
Кратко обращаясь к фиг.21, примерная информация 2100 об отображении находится в виде структурированного формата и содержит в себе информацию (например, информацию о форматировании, информацию о нижнем/верхнем колонтитуле, группирования по свойствам и методам), ассоциативно связанную с каждым объектом, который был определен. Например, информация 2100 об отображении может быть XML-ориентированной. Каждое из преднамеренно установленных свойств затем может быть специфицировано в пределах информации об отображении. Информация в пределах информации 2100 об отображении может быть наполнена владельцем объектного типа, который является введенным. Операционное окружение предусматривает определенного рода API-интерфейсы и командные апплеты, которые предоставляют владельцу возможность обновлять информацию об отображении путем создания, удаления и модифицирования составляющих.
Фиг.22 - таблица, предоставляющая перечень примерного синтаксиса 2201-2213 для определенного рода командных апплетов формата (например, форматировать/таблицу, форматировать/перечень и форматировать/везде), командных апплетов разметки (например, добавить/разметку), командные апплеты преобразования (например, конвертировать/текст, конвертировать /sv, конвертировать /csv, конвертировать /ADO, конвертировать /XML, конвертировать /html), командные апплеты преобразования (например, преобразовать/XSLT) и командные апплеты вывода (например, вывести/консоль, вывести/файл). Фиг.23 иллюстрирует результаты, визуализированные командным апплетом вывода/консоли, использующим различные конвейерные последовательности командных апплетов обработки вывода (например, командные апплеты формата, командные апплеты конвертации и командные апплеты разметки).
Как описано, механизм для предусмотрения управляемого данными вывода командной строки может быть применен в окружении административного инструментального средства. Однако специалисты в данной области техники будут принимать во внимание, что механизм может быть применен в различных окружениях, которые нуждаются в отображении результатов конвейерно обрабатываемых команд. Путем использования командных апплетов обработки вывода в различных конвейерных последовательностях пользователи командной строки могут вырабатывать трудоемкие и многоцелевые отображения с минимальным кодом. В противоположность, при использовании традиционных механизмов протяженный код в команде вывода является необходимым. В дополнение, протяженный код не может быть унифицирован с другими кодами в других командах вывода. Эти и другие ограничения, связанные с традиционным механизмом для отображения результатов, преодолены настоящим механизмом для предусмотрения управляемого данными вывода командной строки.
Несмотря на то, что выше описаны подробности специфических применений и вариантов осуществления, такие подробности имели намерением скорее удовлетворять предписанным законом обязательствам раскрытия изобретения, чем ограничивать объем охраны последующей формулы. Таким образом, изобретение, как определено формулой, не ограничено специфичными признаками, описанными ранее. Точнее, изобретение заявлено в любом из его форм или модификаций, которые попадают в пределы надлежащего объема прилагаемой формулы изобретения, уместно интерпретированной в соответствии с принципом эквивалентов.
Изобретение относится к вычислительной технике и может быть использовано в механизме, который предусматривает управляемый данными вывод командной строки в пределах окружения, которое поддерживает конвейер объектно-ориентированных команд. Техническим результатом является обеспечение улучшенных вариантов выбора форматирования, при котором не требуется протяженного кода в пределах команды для того, чтобы предусмотреть такие улучшенные варианты выбора форматирования. В механизме для предусмотрения вывода управляемой данными командной строки каждая объектно-ориентированная команда вводит синтаксически анализируемый объект для обработки и вывода еще одного другого синтаксически анализируемого объекта для обработки последующей команды. Механизм является работоспособным для непосредственного форматирования и последующей обработки команд на основании типа поступающего синтаксически анализируемого объекта. Для типа синтаксически анализируемого объекта получают информацию о формате, такую как очертание, свойства для отображения и т.п. Информация о формах может быть описана в XML документе. Данный механизм использует одну или более команд обработки вывода, таких как команды формата, команды разметки, команды преобразования и команды вывода. Эти команды обработки вывода могут быть размещены в пределах конвейера различным образом, чтобы достичь желаемых результатов вывода. 3 н. и 22 з.п. ф-лы, 23 ил., 5 табл.
1. Машинореализуемый способ для обработки данных, способ содержит этапы, на которых: в операционном окружении поддерживают конвейер большого количества объектно-ориентированных команд, последующая команда в пределах конвейера является сконфигурированной, чтобы связываться с предшествующей командой в пределах конвейера через синтаксически анализируемый объект, порожденный из предшествующей команды, операционное окружение сконфигурировано, чтобы поддерживать приведение в исполнение команд в пределах одной и той же последовательности операций, принимают синтаксически анализируемый объект, порожденный из предшествующей команды; получают тип данных для синтаксически анализируемого объекта; получают информацию о формате, описывающую формат для типа данных; и порождают объект формата для осуществления доступа еще одной последующей командой, объект формата является основанным на информации о формате.
2. Машинореализуемый способ по п.1, в котором получение информации о формате содержит осуществление доступа к XML-ориентированному документу.
3. Машинореализуемый способ по п.1, в котором последующая команда содержит команду вывода, сконфигурированную, чтобы визуализировать результаты конвейера, основываясь на принятом синтаксически анализируемом объекте и объекте формата.
4. Машинореализуемый способ по п.3, в котором визуализация результатов содержит отображение на консоли.
5. Машинореализуемый способ по п.3, в котором визуализация результатов содержит импортирование результатов в приложение.
6. Машинореализуемый способ по п.3, в котором визуализация результатов содержит отображение в графическом интерфейсе пользователя.
7. Машинореализуемый способ по п.1, в котором другая последующая команда содержит команду разметки, сконфигурированную, чтобы добавлять аннотацию свойства к отобранным в пределах синтаксически анализируемого объекта параметрам и порождение этих аннотаций свойства для ввода дальнейшими последующими командами в конвейере.
8. Машинореализуемый способ по п.1, в котором другая последующая команда содержит команду конвертации, сконфигурированную, чтобы конвертировать принятый синтаксически анализируемый поток в специальный формат.
9. Машинореализуемый способ по п.8, в котором специальный формат содержит XML-документ, объект активного каталога или формат разделенных запятыми значений.
10. Машинореализуемый способ по п.8, в котором еще одна последующая команда содержит команду преобразования, которая принимает специальный формат из команды конвертации и преобразует специальный формат в еще один специальный формат на основании таблицы стилей.
11. Машинореализуемый способ по п.1, в котором информация о формате описывает тип данных и, по меньшей мере, одно из очертания, свойства или верхнего колонтитула.
12. Машиночитаемый носитель, имеющий машиночитаемые инструкции для обеспечения управляемого данными вывода, инструкции содержат: прием синтаксически анализируемого объекта, порождаемого из предшествующей команды в пределах операционного окружения, которое поддерживает конвейер большого количества объектно-ориентированных команд и которое сконфигурировано, чтобы поддерживать приведение в исполнение команд в пределах одной и той же последовательности операций, предшествующая команда является одной из большого количества команд, получение типа данных для синтаксически анализируемого объекта; получение информации о формате, описывающей формат для типа данных; и порождение объекта формата для осуществления доступа последующей командой из большого количества команд, объект формата является основанным на информации о формате.
13. Машиночитаемый носитель по п.12, в котором получение информации о формате содержит осуществление доступа к XML-ориентированному документу.
14. Машиночитаемый носитель по п.12, в котором последующая команда содержит команду вывода, сконфигурированную, чтобы визуализировать результаты конвейера на основании принятого синтаксически анализируемого объекта и объекта формата.
15. Машиночитаемый носитель по п.12, в котором другая последующая команда содержит команду разметки, сконфигурированную, чтобы добавлять аннотацию свойства к отобранным в пределах синтаксически анализируемого объекта параметрам и порождение этих аннотаций свойства для ввода дальнейшими последующими командами в конвейере.
16. Машиночитаемый носитель по п.12, в котором другая последующая команда содержит команду конвертации, сконфигурированную, чтобы конвертировать принятый синтаксически анализируемый поток в специальный формат.
17. Машиночитаемый носитель по п.16, в котором специальный формат содержит XML-документ, объект активного каталога или формат разделенных запятыми значений.
18. Машиночитаемый носитель по п.16, в котором еще одна последующая команда содержит команду преобразования, которая принимает специальный формат от команды конвертации и преобразует специальный формат в еще один специальный формат на основании таблицы стилей.
19. Машиночитаемый носитель по п.12, в котором информация о формате описывает тип данных и, по меньшей мере, одно из очертания, свойства или верхнего колонтитула.
20. Система, которая поддерживает управляемый данными вывод, система содержит: устройство обработки данных; запоминающее устройство, запоминающее устройство является выделенным для множества машиночитаемых инструкций, которые загружены в запоминающее устройство для приведения в исполнение устройством обработки данных, машиночитаемые инструкции, выполняющие способ, содержат: прием синтаксически анализируемого объекта, порожденного из предшествующей команды в пределах операционного окружения, которое поддерживает конвейер большого количества объектно-ориентированных команд и которое сконфигурировано, чтобы поддерживать приведение в исполнение команд в пределах одной и той же последовательности операций, причем предшествующая команда является одной из множества команд, получение типа данных для синтаксически анализируемого объекта; получение информации о формате, описывающей формат для типа данных; и порождение объекта формата для осуществления доступа последующей командой из большого количества команд, объект формата является основанным на информации о формате.
21. Система по п.20, в которой получение информации о формате содержит осуществление доступа к XML-ориентированному документу.
22. Система по п.20, в которой информация о формате описывает тип данных и, по меньшей мере, одно из очертания, свойства или верхнего колонтитула.
23. Система по п.20, в которой другая последующая команда содержит команду разметки, сконфигурированную, чтобы добавлять аннотацию свойства к отобранным в пределах синтаксически анализируемого объекта параметрам и порождение этих аннотаций свойства для ввода дальнейшими последующими командами в конвейере.
24. Система по п.20, в которой другая последующая команда содержит команду конвертации, сконфигурированную, чтобы конвертировать принятый синтаксически анализируемый поток в специальный формат.
25. Система по п.20, в которой еще одна последующая команда содержит команду преобразования, которая принимает специальный формат от команды конвертации и преобразует специальный формат в еще один формат на основании таблицы стилей.
| СИСТЕМА ОБРАБОТКИ И СПОСОБ ЕЕ ФУНКЦИОНИРОВАНИЯ | 1994 |
|
RU2150738C1 |
| УСТРОЙСТВО ДЛЯ ОБРАБОТКИ ИНФОРМАЦИИ | 1991 |
|
RU2029359C1 |
| Вычислительная система | 1989 |
|
SU1777148A1 |
| US 20030001894 A1, 02.01.2003 | |||
| US 2003018765 A1, 23.01.2003 | |||
| JP 52105526 A, 20.08.1993 | |||
| Способ изготовления конусов для намотки ниток и пряжи | 1956 |
|
SU106670A1 |
