ОСНОВАННОЕ НА ШАБЛОНЕ УПРАВЛЕНИЕ СЛУЖБАМИ Российский патент 2011 года по МПК G06F17/00 

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

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

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

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

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

• На что похожа данная служба?

• Из каких компонентов состоит данная служба и как компоненты службы взаимодействуют?

• От каких служб инфраструктуры зависит рассматриваемая служба?

• Как мы обнаруживаем ввод в действие службы в сети?

• Как мы различаем два развертывания данной службы?

• Какие признаки службы представляют интерес для пользователя?

• Какие данные измерений необходимо собирать для этой службы?

• Как эти данные необходимо форматировать и отображать, чтобы они были полезны администратору службы?

• Какие задачи обычно выполняют пользователи с помощью данной службы?

• Как администратор узнает, что служба выполняется как положено?

• Какие проблемы могут повлиять на функционирование службы?

• Как можно обнаруживать, или еще лучше, предотвращать такие проблемы?

• Какие данные необходимо собирать для диагностики этих проблем?

• Существуют ли какие-нибудь корректирующие действия, которые можно выполнять в ответ на такие проблемы?

• Когда необходимо уведомлять администратора о возможных проблемах?

• Какие данные необходимо обеспечивать администратору в качестве контекста для того, чтобы понять и решить возможную проблему?

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 3D иллюстрирует один из вариантов осуществления модели состояния, которую может генерировать автор шаблона.

Фиг. 4 - структурная схема конфигурации для создания шаблона в соответствии с одним из вариантов осуществления.

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

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

Фиг. 7 - иллюстрирует всю схему механизма доставки для доставки шаблонов к системе контроля.

Фиг. 7A-7E показывают схему для шаблонов.

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

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

Обращаясь к фиг. 1, примерная система для осуществления некоторых вариантов осуществления включает в себя универсальное вычислительное устройство в форме компьютера 110. Компоненты компьютера 110 могут включать в себя, но не ограничены ими, процессор 120, системную память 130 и системную шину 121, которая связывает различные компоненты системы, включающие в себя системную память, с процессором 120. Системная шина 121 может быть любым из нескольких видов шинных структур, включающих в себя шину памяти или контроллер памяти, периферийную шину и локальную шину, используя любое разнообразие шинной архитектуры. Для примера, а не в качестве ограничения, такая архитектура включает в себя шину архитектуры промышленного стандарта (ISA), шину микроканальной архитектуры (MCA), шину усовершенствованной ISA (EISA), локальную шину ассоциации по стандартам в области видеоэлектроники (VESA) и шину стандарта соединения периферийных устройств (PCI), также известную как шина расширения.

Компьютер 110 обычно включает в себя разнообразие считываемых компьютером носителей. Считываемые компьютером носители могут быть любыми доступными носителями, к которым может обращаться компьютер 110, и они включают в себя и энергозависимые, и энергонезависимые носители, съемные и несъемные носители. Для примера, а не в качестве ограничения, считываемый компьютером носитель может содержать компьютерные носители данных и средства связи. Компьютерные носители данных включают в себя и энергозависимые, и энергонезависимые, съемные и несъемные носители, воплощенные любым способом или технологией хранения информации, такой как считываемые компьютером команды, структуры данных, программные модули или другие данные. Компьютерные носители данных включают в себя, но не ограничены ими, оперативную память (ОП), постоянное запоминающее устройство (ПЗУ), электрически стираемое программируемое постоянное запоминающее устройство (ЭСППЗУ), флэш-память или память другой технологии, компакт-диски (CD-ROM), цифровые универсальные диски (DVD) или другое запоминающее устройство на оптическом диске, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитном диске или другие магнитные запоминающие устройства, или любой другой носитель, который можно использовать для хранения необходимой информации и к которому может обращаться компьютер 110. Средства связи обычно воплощают считываемые компьютером команды, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущая, или используют другой механизм транспортировки и включают в себя любые средства доставки информации. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или большее количество своих характеристик, которые устанавливаются или изменяются таким образом, чтобы кодировать информацию в сигнале. Для примера, а не в качестве ограничения, средства связи включают в себя проводные каналы связи, такие как проводные сети или прямое проводное подключение, и беспроводные каналы связи, такие как акустические, радиочастотные (РЧ), инфракрасные и другие беспроводные каналы связи. Считываемые компьютером носители должны также включать в себя комбинации любых из указанных выше носителей.

Системная память 130 включает в себя компьютерные носители данных в форме энергозависимой и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ) 131 и оперативная память (ОП) 132. Базовая система ввода-вывода 133 (BIOS), которая содержит основные подпрограммы, которые помогают перемещать информацию между элементами в пределах компьютера 110, например, во время запуска, обычно хранятся в ПЗУ 131. ОП 132 обычно содержит данные и/или программные модули, которые мгновенно доступны для обработки и/или в данный момент обрабатываются процессором 120. Для примера, а не в качестве ограничения, фиг. 1 показывает операционную систему 134, прикладные программы 135, другие программные модули 136 и данные 137 программ.

Компьютер 110 может также включать в себя другие съемные/несъемные энергозависимые/энергонезависимые компьютерные носители данных. Только для примера фиг. 1 показывает накопитель 141 на жестком диске, который считывает информацию или который записывает информацию на несъемный энергонезависимый магнитный диск, накопитель 151 на магнитном диске, который считывает информацию или записывает информацию на съемный энергонезависимый магнитный диск 152, и привод 155 оптического диска, который считывает информацию или записывает информацию на съемный энергонезависимый оптический диск 156, такой как CD-ROM или другой оптический носитель. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители данных, которые могут использоваться в примерной конфигурации, включают в себя, но не ограничены ими, кассеты магнитной ленты, платы флэш-памяти, цифровые универсальные диски, цифровую видеоленту, полупроводниковую ОП, полупроводниковое ПЗУ и т.п. Накопитель 141 на жестком диске обычно подключается к системной шине 121 через интерфейс с несъемным запоминающим устройством, такой как интерфейс 140, а накопитель 151 на магнитном диске и привод 155 оптического диска обычно подключается к системной шине 121 через интерфейс со съемным запоминающим устройством, такой как интерфейс 150.

Устройства и соответствующие им компьютерные носители данных, которые обсуждаются выше и показаны на фиг. 1, обеспечивают хранение считываемых компьютером команд, структур данных, программных модулей и других данных для компьютера 110. На фиг. 1, например, накопитель 141 на жестком диске показан в качестве устройства хранения операционной системы 144, прикладных программ 145, других программных модулей 146 и данных 147 программ. Следует отметить, что эти компоненты могут или быть теми же самыми, как операционная система 134, прикладные программы 135, другие программные модули 136 и данные 137 программ, или отличаться от них. Операционной системе 144, прикладным программам 145, другим программным модулям 146 и данным 147 программ присвоены другие обозначения для того, чтобы показать, что они, как минимум, являются различными копиями.

Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода данных, такие как клавиатура 162, микрофон 163 и устройство 161 позиционирования, такое как «мышь», шаровой манипулятор («трекболл») или сенсорная панель. Другие устройства ввода данных (не показаны) могут включать в себя джойстик, игровую клавиатуру, спутниковую антенну, сканер или подобное устройство. Эти и другие устройства ввода данных часто устанавливают связь с процессором 120 через входной пользовательский интерфейс 160, который связан с системной шиной, но они могут устанавливать связь с помощью другого интерфейса и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 191 или другой тип устройства отображения также связан с системной шиной 121 через интерфейс, такой как видеоинтерфейс 190. В дополнение к монитору, компьютеры могут также включать в себя другие периферийные устройства вывода информации, такие как динамики 197 и принтер 196, которые могут быть связаны через интерфейс 195 периферийных устройств вывода информации.

Компьютер 110 может работать в сетевом окружении, используя логические подключения к одному или большему количеству удаленных компьютеров, такому как удаленный компьютер 180. Удаленный компьютер 180 может быть персональным компьютером, карманным устройством, сервером, маршрутизатором, сетевым ПК, устройством пользователя сети или другим обычным сетевым узлом, и обычно включает в себя многие или все элементы, описанные выше относительно компьютера 110. Логические подключения, изображенные на фиг. 1, включают в себя локальную сеть (ЛС) 171 и глобальную сеть (ГС) 173, но могут также включать в себя другие сети. Такие сетевые конфигурации обычно применяют в офисах, в компьютерных сетях в масштабах предприятия, в корпоративных сетях (интранет) и в Интернет.

При работе в конфигурации с ЛС компьютер 110 связан с ЛС 171 через сетевой интерфейс, или адаптер 170. При работе в конфигурации с ГС компьютер 110 обычно включает в себя модем 172 или другие средства установления связи по ГС 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, может быть связан с системной шиной 121 через входной пользовательский интерфейс 160 или использовать другой соответствующий механизм. В сетевом окружении программные модули, изображенные относительно компьютера 110 или его частей, могут храниться в удаленном запоминающем устройстве. Для примера, а не в качестве ограничения, фиг. 1 показывает удаленные прикладные программы 185, как находящиеся на удаленном компьютере 180. Следует признать, что показанные сетевые соединения являются примерными, и могут использоваться другие средства установления связи между компьютерами.

Фиг. 2 является структурной схемой структуры 200 шаблона в соответствии с одним из вариантов осуществления. Структура 200 шаблона включает в себя «мастер» 202 конфигурирования контроля и уровень 204 программирования системы контроля. Показано, что «мастер» 202 обращается к шаблонам 208 и 210, каждый из которых генерируют из набора общих характеристик 212 и 214, соответственно, служб различного типа. Показано, что шаблон 208 основан на характеристиках 212 служб первого типа (все вместе обозначены цифрой 216), и шаблон 210 основан на характеристиках 214 служб второго типа (все вместе обозначены цифрой 218).

Показано, что «мастер» 202 конфигурирования принимает информацию 226 конфигурирования от пользователя 224 и обращается к совокупностям 209 ПИ, которые являются изображениями ПИ, соответствующими шаблонам 208 и 210. Как описано более подробно ниже, «мастер» 202 конфигурирования генерирует описание 228 службы из выбранного шаблона 208 или 210 (выбранного пользователем) и основываясь на информации 226 конфигурирования, обеспеченной пользователем.

Показано, что уровень 204 программирования системы контроля принимает описание 228 службы и обращается к доступной логике 220 контроля. Основываясь на описании 228 службы, уровень 204 программирования генерирует логику 222 контроля, которую используют для контроля данной службы.

Фиг. 3A - последовательность операций, показывающая работу показанной на фиг. 2 структуры 200 более подробно. Однако перед обсуждением работы структуры 200 обсуждают шаблоны 212 и 214. Каждый из шаблонов получают с помощью группирования служб, которые будут контролировать, в группы типов службы. Службы первого типа обозначают цифрой 216, и службы второго типа обозначают цифрой 218. Каждая из служб имеет общие характеристики контроля. Например, службы первого типа 216 имеют общие характеристики 212 контроля, в то время как службы второго типа 218 имеют общие характеристики 214 контроля. Шаблон 208 генерируют, основываясь на общих характеристиках 212 контроля служб первого типа 216. Шаблон 210 генерируют из общих характеристик 214 контроля служб второго типа 218.

Хотя общие характеристики группы служб можно получать, используя большое разнообразие различных средств, одно из иллюстративных средств получают при использовании наследования типа для группы служб. Например, фиг. 3C показывает наследование типа для конкретной службы 400 операционной системы. Служба 400, как можно заметить с помощью наследования типа, является локальным приложением 402 операционной системы (ОС). Локальное приложение 402 ОС является локальным приложением 404 системы, которое само является приложением 406 системы. Приложение 406 системы является классом ManagedEntity 408 системы. Таким образом, фиг. 3C показывает, что конкретная служба 400 ОС имеет набор характеристик 410 конфигурирования контроля. Поэтому в одном из вариантов осуществления каждый из отличающихся шаблонов 208 и 210 имеет соответствующий набор общих характеристик контроля, которые можно получать с помощью наследования типа для типа службы, представленной этим шаблоном.

Фактом является то, что для генерации и использования логики контроля для данной службы пользователь 224 сначала обеспечивает ввод информации для запуска «мастера» 202 конфигурирования контроля. Это обозначено с помощью этапа 300 на фиг. 3A. Когда «мастер» 202 конфигурирования запускают, он генерирует изображения пользовательского интерфейса для того, чтобы провести пользователя через конфигурирование контроля, используя «мастер» 202 конфигурирования.

Один из примерных наборов изображений пользовательского интерфейса показан с помощью фиг. 3B. Когда «мастер» 202 конфигурирования запускают первый раз, он может иллюстративно генерировать постоянное приветственное изображение, такое как изображение 350 на фиг. 3B. Можно заметить, что постоянное изображение может иллюстративно отображать приветственное сообщение и обеспечивать элементы, на которые может воздействовать пользователь, такие как кнопки «далее», расположенные вдоль нижнего края изображения 250, для предоставления пользователю возможности перехода к следующему экрану. Постоянное изображение является постоянным потому, что оно не изменяется, независимо от того, какой шаблон конфигурируют с помощью «мастера» 202 конфигурирования.

Пользователь затем продвигается к экрану выбора шаблона, например, к такому, который показан в кадре 352 на фиг. 3B. Как можно заметить, кадр 352 обеспечивает список доступных шаблонов, которые служат отправной точкой при генерации описания службы для конфигурирования контроля для данной службы. Список шаблонов, показанных на изображении 352 ПИ, включает в себя шаблоны, соответствующие службе операционной системы, приложению com+, множеству приложений, веб-сайту, веб-службе, сетевому приложению, приложению базы данных и распределенному приложению. Различные шаблоны, показанные на изображении 352, представляют доступные шаблоны 208-210 (из фиг. 2), которые доступны для выбора пользователем. Шаблоны на изображении 352 представляют только типичный список шаблонов, и также можно обеспечивать другие шаблоны.

Пользователь просто выбирает один из шаблонов контроля, отображаемых пользователю, например, на изображениях 352 пользовательского интерфейса. Выбор шаблона контроля обозначают с помощью этапа 302 на фиг. 3A. Это можно делать большим разнообразием способов, например, выделяя требуемый шаблон и щелкая «далее», или дважды щелкая на выбранном шаблоне и т.д.

Когда пользователь выбрал шаблон контроля, «мастер» 202 конфигурирования контроля обращается к совокупностям 209 ПИ и получает набор страниц ПИ в совокупности, соответствующей выбранному шаблону. Страницы ПИ в наборе страниц ПИ изображают как экраны 354 конфигурирования (показаны на фиг. 3B), и они предоставляют пользователю возможность вводить информацию 226 конфигурирования, которая используется для дополнительного конфигурирования функций контроля, представленных выбранным шаблоном. Например, шаблон может предоставлять пользователю возможность включать или выключать разнообразие различных опций контроля или устанавливать пороговые уровни для критериев производительности системы и т.д. Отображение экранов конфигурирования для конфигурирования пользователем выбранного шаблона обозначено с помощью этапа 304 на фиг. 3A.

Пользователь затем обеспечивает передачу информации 226 конфигурирования «мастеру» 202 конфигурирования, и «мастер» 202 генерирует описание 228 службы. Это обозначено с помощью этапа 306 на фиг. 3A.

Экраны 354 конфигурирования могут также иллюстративно предоставлять пользователю возможность добавлять специализированный контроль. Фиг. 3D показывает один из примерных вариантов осуществления модели состояния, которая может быть представлена с помощью шаблона, и которую пользователь конфигурирует и настраивает через экраны 354 конфигурирования. Эта примерная модель 320 будет теперь описана для расширения понимания остальной части обсуждения.

Модель 320 состояния иллюстративно включает в себя первую часть 315 модели и вторую часть 330 модели. Первая часть 315 модели иллюстративно контролирует то, что предварительно определено и представлено с помощью выбранного шаблона, который пользователь может конфигурировать через экраны 354 конфигурирования. Вторая часть 330 модели иллюстративно является конфигурацией специализированного контроля, вводимой пользователем через экраны конфигурирования.

Первая часть 315 модели иллюстративно включает в себя множество мониторов 321-325, каждый из которых контролирует различные элементы. Модель 320 дополнительно включает в себя накапливающие мониторы 326-329, которые накапливают результаты от мониторов 321-325 нижнего уровня. В варианте осуществления, показанном на фиг. 3D, мониторы 321-325 включают в себя монитор 321 проверки службы, который просто проверяет состояние службы (т.е. выполняется ли она, остановлена или неправильно завершилась). Мониторы также включают в себя монитор 322 проверки зависимой службы, который проверяет состояние зависимых служб. Мониторы 323-325 являются мониторами использования ресурса, которые контролируют использование процессора, памяти и указателей, соответственно. Информацию от этих мониторов накапливают с помощью накапливающих мониторов 326 и 327, которые воплощают правила обеспечения информации о состоянии к основному накапливающему монитору 328 состояния службы, который указывает, соответствуют ли основные контролируемые критерии или характеристики (контролируемые мониторами 321-325) данному пороговому значению или превышают его. Основной накапливающий монитор 328 состояния службы, в свою очередь, обеспечивает передачу данных состояния к монитору 329 состояния службы, основываясь на вводимой информации от накапливающих мониторов 326 и 327.

Фиг. 3D также показывает, что вторая часть 330 модели 320 состояния службы включает в себя конфигурацию контроля специализированного оборудования. Конфигурация 330 монитора включает в себя пару специализированных мониторов 331 и 332, которые контролируют дополнительные (не основные) характеристики или критерии, которые накапливаются в мониторе 333 дополнительного состояния службы. Специализированные мониторы могут контролировать специализированное оборудование в контролируемой службе. Например, монитор 331 может иллюстративно быть монитором событий, который контролирует специализированные события оборудования, которые относятся к дополнительным состояниям контролируемой службы. Точно так же монитор 332 числовых данных может иллюстративно контролировать любой тип числовых данных, генерированных контролируемым оборудованием (например, количество относящихся к безопасности событий). Данные от мониторов 331 и 332 накапливаются монитором 333, и их обеспечивают к монитору 329 состояния службы, который обеспечивает выходную информацию, которая указывает полное состояние контролируемой службы. В одном из иллюстративных вариантов осуществления конфигурацию контроля специализированного оборудования в части 330 модели конфигурируют с помощью пользовательской информации 226 конфигурирования, которую вводят через экраны 354 конфигурирования, соответствующие выбранным шаблонам.

В любом случае, когда всю пользовательскую информацию 226 выбора конфигурации вводят к «мастеру» 202 конфигурирования, «мастер» 202 конфигурирования генерирует описание 228 службы, как обозначено с помощью этапа 306 на фиг. 3.

«Мастер» 202 конфигурирования может затем иллюстративно обеспечивать пользователю дополнительные экраны, такие как экран 356 ПИ на фиг. 3B, которые запрашивают у пользователя название, характеристику и местоположение описания 228 службы. Это предоставляет пользователю возможность определенным образом называть и сохранять описание 228 службы в заданном местоположении.

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

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

Когда описание службы сформировано, его передают к уровню 204 программирования контроля. Уровень 204 программирования затем обращается к доступной логике 220 контроля и создает мониторы, правила, задания, представления, классы и т.д., которые должны контролировать службу, определенную с помощью описания 228 службы. Эту информацию иллюстративно сохраняют в устройстве хранения данных, к которому обращаются с помощью уровня 204. Это обозначено с помощью этапа 307 на фиг. 3A.

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

Например, предполагают, что службой, которую будут контролировать, является антивирусное приложение. Предполагают также, что данный компьютер в пользовательской конфигурации компьютеров содержит антивирусное приложение. В этом случае уровень 204 программирования идентифицирует компьютер, на котором содержится антивирусное приложение, и применяет политики контроля, связанные с описанием 228 службы, к этому компьютеру. Этого можно достичь с помощью большого разнообразия различных способов. В одном из вариантов осуществления уровень 204 программирования передает правило обнаружения к каждому из компьютеров в пользовательской конфигурации, которые контролируются системой контроля. Эти компьютеры принимают правило обнаружения и периодически выполняют данное правило обнаружения для проверки, существует ли определенная служба (в данном случае антивирусное приложение) на этом компьютере. Когда служба действительно существует на этом компьютере, тогда политики контроля, требуемые для контроля этой службы, как описано в описании 228 службы, обеспечивают на этот компьютер так, чтобы можно было осуществлять контроль требуемой службы. Выполнение обнаружения обозначено с помощью этапа 308 на фиг. 3A.

Выполнив обнаружение и идентификацию компьютеров, на которых будут выполнять контроль службы, уровень 204 программирования затем идентифицирует отдельные варианты службы, которую будут контролировать, для того, чтобы отличать один вариант от другого. Другими словами, если на компьютере запущены два варианта той же самой службы, то эти два варианта необходимо различать. В одном из вариантов осуществления это выполняют при использовании информации идентификатора в выбранном пользователем шаблоне. Шаблон иллюстративно включает в себя идентификатор или ключевые свойства (такие как название службы в пределах компьютера и название компьютера для воплощения с множеством компьютеров), которые успешно идентифицирует каждый вариант службы, которую будут контролировать. Это будет иллюстративно выполнено с помощью шаблона, выбранного пользователем. Идентификация отдельных вариантов обозначена с помощью этапа 310 на фиг. 3A.

Когда идентифицированы местоположение и отдельные варианты службы, которую будут контролировать, уровень 204 программирования системы контроля затем использует созданные мониторы, правила, представления и т.д. на идентифицированных компьютерах для контроля службы. Это обозначено с помощью этапа 312 на фиг. 3A.

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

Логика 222 контроля и уровень 204 программирования вместе с «мастером» 202 конфигурирования могут также выполнять задания. Например, задание может предоставлять пользователю возможность перезапускать службу, когда она остановлена. Обеспечение выходной информации обозначают с помощью этапа 314 на фиг. 3A.

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

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

Фиг. 4 - структурная схема конфигурации 500 для создания шаблона в соответствии с одним из вариантов осуществления изобретения. Конфигурация 500 для создания шаблона включает в себя компонент 502 создания шаблона, который принимает от автора 510 описание 504 шаблона вместе с совокупностью, которая включает в себя набор 506 страниц пользовательского интерфейса. Компонент 502 создания шаблона генерирует шаблон и вставляет его, вместе с совокупностью 506, в механизм распространения, такой как пакет управления (ПУ), как обозначено цифрой 512.

Фиг. 5 - последовательность операций, лучше иллюстрирующая работу конфигурации 500 при генерации механизма распространения. Механизмом распространения может быть любой из разнообразия различных механизмов, и механизмом, описанным в данной работе для примера, является пакет управления. Как описано выше, шаблон является в основном предопределенным набором контроля, который конфигурирован клиентом, вводящим некоторый набор информации конфигурирования. Сначала автор генерирует описание шаблона. Это обозначено с помощью этапа 600 на фиг. 5. В одном из вариантов осуществления для генерации описания 504 шаблона необходимы три вещи: информация конфигурирования, ссылки и информация реализации. Информация конфигурирования является иллюстративно информацией, с помощью которой определяют значения конфигурирования, которые будут введены пользователем и будут использоваться в разделе реализации. Ссылками является список ссылок, которые будут созданы в пакете управления, в котором сохраняют выходную информацию шаблона. Сам раздел реализации является фрагментом пакета управления, который имеет параметры замены, которые внедрили в него. Эти параметры относятся к разделу конфигурирования шаблона. Например, если элемент ServiceName требуется как часть конфигурирования, то он может использоваться в разделе реализации как $config/ServiceName$. Затем, когда шаблон выполняют, это значение заменяют фактическим значением ServiceName.

Первым этапом в создании описания 504 шаблона является создание необходимых элементов пакета управления (таких как классы, мониторы, правила и т.д.), как правильного отдельного пакета управления. Функциональные возможности проверяют и обновляют при желании, и шаблон создают из пакета управления и вставляют в раздел шаблонов пакета управления, который будет в конечном счете содержать шаблон. Затем определяют информацию конфигурирования, которая требуется для шаблона, и параметры конфигурирования заменяют там, где требуется в шаблоне. Шаблон можно затем выполнять, и выходную информацию проверяют.

Компонент 502 создания шаблона иллюстративно обеспечивает этот поэтапный подход к созданию 510 при генерации описания 504 шаблона. Этапы генерации описания шаблона описаны более подробно ниже относительно фиг. 6.

Автор затем генерирует соответствующую совокупность, которая включает в себя набор страниц пользовательского интерфейса, которые будут отображать пользователю в качестве страниц 354 конфигурирования (показаны на фиг. 3B), когда пользователь выбирает шаблон. Это обозначено с помощью этапа 602 на фиг. 5. Набор страниц ПИ можно генерировать множеством различных способов. Например, пакет управления может содержать одно или большее количество многократно используемых описаний страниц ПИ, которые можно конфигурировать как набор страниц ПИ. Пример описания страниц ПИ показан ниже в таблице 1.

Таблица 1   <UIPages>
<! - страница ПИ, которая предоставляет пользователю возможность искать компьютер и выбирать счетчики производительности Windows и их экземпляры.
 

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

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

Таблица 2   <UIPages>
<! - страница ПИ, которая предоставляет пользователю возможность выбирать пространство имен, класс, свойства класса и частоты WMI для исследования WMI.
 

Затем генерируют пакет управления или изменяют существующий пакет управления так, чтобы он включал в себя новый шаблон и соответствующую совокупность (соответствующий набор страниц ПИ). Альтернативно, описание ПУ и совокупности можно доставлять через другой механизм, такой как инсталляционный пакет, установленный на компьютере, который использует пользователь. Важно то, что их доставляют некоторым способом, и вероятно, что их доставляют вместе. Это обозначено с помощью этапа 604 на фиг. 5.

Затем пакет управления распространяют к компьютерам, которые имеют систему контроля работы (например, «мастер» и уровень программирования, как обсуждается выше) и где контроль необходимо делать. Это можно делать различными способами, такими как импорт его в базу данных и извлечение надлежащими компьютерами. Это обозначено с помощью этапа 606 на фиг. 5.

Когда распространенный к компьютерам пакет управления импортируют в базу данных, новый шаблон добавляют к списку доступных шаблонов, вместе с его ссылками на совокупности ПИ. Это предоставляет пользователю возможность выбирать новый шаблон. Другими словами, когда пользователь вызывает «мастер» 202 конфигурирования, «мастер» 202 запрашивает базу данных на получение списка доступных шаблонов. Затем изображение, соответствующее новому шаблону, будет отображаться на экране 352 отображения шаблона, показанном на фиг. 3B, так что новый шаблон может быть выбран пользователем. Это обозначено с помощью этапа 608 на фиг. 5.

Когда пользователь выбирает новый шаблон, «мастер» 202 конфигурирования отображает экраны 354 конфигурирования, основываясь на соответствующей совокупности (наборе страниц ПИ) 209. Это обозначено с помощью этапа 610 на фиг. 5. Другими словами, когда пользователь выбирает новый шаблон, конкретную конфигурацию набора страниц ПИ, которые связаны с этим шаблоном, идентифицируют и отображают пользователю. Эти наборы страниц будут отображаться, как страницы 354 конфигурирования, показанные на фиг. 3B.

Фиг. 6 является последовательностью операций, которая лучше показывает, как генерируют описание шаблона, как показано с помощью этапа 600 на фиг. 5. Сначала, автор генерирует элементы пакета управления (такие как классы, мониторы и правила), используемые шаблоном. Это может делаться также, как генерация любого другого пакета управления. Например, таблица 3 показывает примерный пакет управления, который содержит очень немного информации (один класс), но разработан просто для иллюстрации основных обсуждаемых принципов.

Таблица 3  

Генерация элементов пакета управления обозначена с помощью этапа 702 на фиг. 6.

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

Таблица 4  

Преобразование исходного пакета управления в шаблон обозначено с помощью этапа 704 на фиг. 6. В другом варианте осуществления шаблон является просто одной частью пакета управления.

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

Таблица 5  

Описание конфигурирования шаблона обозначено с помощью этапа 706 на фиг. 6.

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

Таблица 6  

Добавление переменных замены обозначено с помощью этапа 708 на фиг. 6. Описание шаблона закончено, и автор иллюстративно тестирует выполнение этого шаблона.

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

Полная схема пакета управления показана на фиг. 7. Следует отметить, что, поскольку существующее обсуждение имеет дело с добавлением шаблонов к пакету управления, только раздел шаблона обсуждается в данной работе. Фиг. 7 просто показывает, где, в одной примерной схеме, шаблоны могут размещаться в пакете управления. Можно заметить, что с помощью этой схемы шаблон описывают в пакете управления, с которым его отправляют, и все необходимые типы и объекты, которые требуются шаблону, включает в себя тот же самый пакет управления или пакеты управления, на которые ссылаются. Компоненты ПИ обеспечивают как совокупности с пакетом управления, и пакет управления включает в себя ссылки на эти совокупности.

Фиг. 7A-7E показывают схему для описания шаблонов, и фиг. 8A-8J показывают схему для описания наборов страниц ПИ.

Раздел шаблона пакета управления включает в себя один или большее количество шаблонов, как показано на фиг. 7A. Каждый шаблон требует конфигурации, ссылок и раздела реализации, как показано на фиг. 7B. Шаблон иллюстративно имеет два признака. Первым является идентификатор, который представляет внутренний идентификатор для этого типа, и данный идентификатор уникален в пространстве имен пакета управления. Второй - дополнительный комментарий, который является полем комментария для использования автором пакета управления.

Раздел конфигурации описывает элементы конфигурации, которые должны быть установлены для запуска данного шаблона. Это показано на фиг. 1C.

Раздел ссылок иллюстративно содержит информацию ссылок, которую включает в себя пакет управления, в котором сохраняют выходную информацию после запуска шаблона. Это лучше показано на фиг. 7D. Актуальные ссылки описывают в пакете управления, который содержит шаблон, перед использованием. Одной определенной для шаблона ссылкой, которая не описана в пакете управления, является описанная выше ссылка сама на себя.

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

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

Каждая страница ПИ требует раздела реализации. Схема для этого показана на фиг. 8B. Этот раздел реализации содержит информацию совокупности и типа, которая определяет страницу. Это показано на фиг. 8C.

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

Набор страниц имеет набор ссылок к страницам ПИ, и дополнительно выходную информацию можно преобразовывать, как обозначено с помощью фиг. 8E. Элемент ссылок на страницы ПИ содержит ссылки «один ко многим» на страницы ПИ, которые были определены предварительно. Это обозначено с помощью фиг. 8F. Каждая ссылка на страницы ПИ имеет два признака, включающие в себя признак идентификатора и признак типа идентификатора. Признак типа идентификатора является ссылкой на страницу ПИ, уже определенную в данном пакете управления или пакете управления, на который ссылаются.

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

Ссылка на страницу ПИ в пределах набора страниц ПИ имеет схему, показанную на фиг. 8H. Заголовок и подзаголовок управляют отображением страницы в ПИ. Они являются внутренними названиями, и на них могут ссылаться в языковых разделах пакета для удобного в использовании локализованного текста. «Название вкладки» управляет названием вкладки, на которой это название появится, когда отображается в управлении вкладками. В этом случае заголовок и подзаголовок могут не использоваться. Описание набора страниц не должно ничего знать о том, как оно будет отображаться в ПИ (например, на странице «мастера» или странице таблицы).

Страница может дополнительно использовать входные параметры. Эти параметры используются при реализации страницы, когда требуется. Входные параметры могут быть любой известной конфигурацией, такой как XML (расширяемый язык разметки), как показано на фиг. 8l.

Страница ПИ использует конфигурацию целевого объекта в качества входной информации. Например, когда открывают свойства шаблона, конфигурацию этого шаблона передают к каждой странице. Странице может быть нужна только часть этой конфигурации, таким образом она может применять преобразование к этой конфигурации так, чтобы только необходимая конфигурация использовалась страницей. Это дополнительное преобразование определяют в элементе преобразования входной информации ссылки на страницу, как показано на фиг. 8J.

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

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

Изобретение относится к системам конфигурирования служб контроля компьютерной системы. Технический результат заключается в повышении скорости конфигурирования функций контроля для выборочных решений или с помощью компьютерной системы. Используют шаблоны, которые описывают определенные особенности службы данного типа, причем данные особенности являются общими для всех служб этого типа. Шаблон может конфигурироваться пользователем для получения описания службы для данной службы. Описание службы передают к уровню программирования, и оно обеспечивает информацию таким образом, чтобы уровень программирования мог создавать различные мониторы, правила, классы и задания, требуемые для контроля данной службы без дополнительной настройки пользователем. Пользователь может также настраивать описание службы, необходимое для получения дополнительного контроля. 2 н. и 8 з.п. ф-лы, 6 табл., 25 ил.

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

2. Реализуемый на компьютере способ по п.1, причем реализуемый на компьютере способ используется в пользовательской среде, дополнительно содержащий этап, на котором: перед использованием сконфигурированной логики контроля идентифицируют местоположения, где в пользовательской среде используется упомянутая служба.

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

4. Реализуемый на компьютере способ по п.2, дополнительно содержащий этап, на котором идентифицируют отдельные экземпляры службы, используемой в пользовательской среде.

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

6. Реализуемый на компьютере способ по п.1, дополнительно содержащий этап, на котором принимают ввод выбора шаблона, указывающий тип службы, который должен контролироваться.

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

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

9. Система контроля службы по п.7, в которой уровень программирования контроля использует сконфигурированную логику контроля для контроля данной службы.

10. Система контроля службы по п.9, в которой уровень программирования контроля идентифицирует отдельные экземпляры данной службы, используемые в пользовательской среде, и использует сконфигурированную логику контроля для контроля каждого экземпляра данной службы.