ОСНОВАННОЕ НА МОДЕЛИ УПРАВЛЕНИЕ КОМПЬЮТЕРНЫМИ СИСТЕМАМИ И РАСПРЕДЕЛЕННЫМИ ПРИЛОЖЕНИЯМИ Российский патент 2009 года по МПК G06F9/44 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Эта заявка связана со следующими находящимися на рассмотрении одновременно с настоящей заявкой заявками: US №10/692216, озаглавленная “MODEL-BASED MANAGEMENT OF COMPUTER SYSTEMS AND DISTRIBUTED APPLICATIONS” («ОСНОВАННОЕ НА МОДЕЛИ УПРАВЛЕНИЕ КОМПЬЮТЕРНЫМИ СИСТЕМАМИ И РАСПРЕДЕЛЕННЫМИ ПРИЛОЖЕНИЯМИ»), поданная 23 октября, 2003 г.; US №10/693072, озаглавленная “SCALABLE SYNCHRONOUS AND ASYNCHRONOUS PROCESSING OF RULE MONITORING” («МАСШТАБИРУЕМАЯ СИНХРОННАЯ И АСИНХРОННАЯ ОБРАБОТКА МОНИТОРИНГА ПРАВ»), поданная 24 октября 2003 г.; US № 10/692660, озаглавленная “RULES DEFINITION LANGUAGE” («ЯЗЫК ОПРЕДЕЛЕНИЯ ПРАВИЛ»), поданная 24 октября, 2003 г.; US № 10/693.588, озаглавленная “USING URI'S TO IDENTIFY MULTIPLE INSTANCES WITH A COMMON SCHEMA” («ИСПОЛЬЗОВАНИЕ URI ДЛЯ ОПРЕДЕЛЕНИЯ МНОЖЕСТВА ЭКЗЕМПЛЯРОВ С ОБЩЕЙ СХЕМОЙ»), поданная 24 октября 2003 г.; US № 10/692432 индекс в реестре поверенного № MSFTP522US), озаглавленная “USE OF ATTRIBUTION TO DESCRIBE MANAGEMENT INFORMATION” («ИСПОЛЬЗОВАНИЕ АТРИБУТОВ ДЛЯ ОПИСАНИЯ ИНФОРМАЦИИ УПРАВЛЕНИЯ»), поданная 23 октября 2003 г., которые полностью включены в материалы настоящей заявки посредством ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Это изобретение относится к компьютерным системам и, более конкретно, к управлению компьютерными системами и приложениями.

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

Что необходимо - это улучшенный механизм для инфраструктуры управления.

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

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

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

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

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

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

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

ПЕРЕЧЕНЬ ЧЕРТЕЖЕЙ

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

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

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

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

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

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

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

На Фиг.1 проиллюстрирована архитектура 100, которая обеспечивает основанное на модели управление приложениями или службами в соответствии с настоящим изобретением. Основанный на модели подход к управлению позволяет разработчику описать приложение или службу 102 в терминах его составляющих компонентов и желаемые состояния в терминах функциональных возможностей, конфигурации, защиты и рабочих характеристик. Таким образом, описание 104 приложения или службы обеспечивает описание приложения или службы 102 в терминах одного или более управляемых компонентов, включающих в себя по меньшей мере компонент 106 моделей, компонент 108 декларации, системный компонент 110 и компонент 112 задач.

Система 100 основанного на модели управления использует компонент 114 задания атрибутов, чтобы обеспечить задание атрибутов для исходного кода от компонента 106 модели к компоненту 108 декларации.

Компьютерная система 116 использует описание 104 приложения или службы при установке приложения 102 для конфигурирования служб 118 управления, связанных с компьютерной операционной системой. Службы 118 управления далее помогают удостовериться в доступности приложения или службы 102 через действия автоматического управления, такие как управление конфигурацией, обнаружение проблем, диагностика и восстановление. Модель 106 также описывает общие задачи, которые администратор может исполнять. Основанная на модели архитектура 100 управления делает возможной более низкую общую стоимость владения, и используется весь жизненный цикл приложения от разработки к развертыванию, эксплуатации и бизнес-анализу. Вообще, разработчик начинает с создания одной или более моделей приложения или службы в терминах того, как приложение работает, его составляющих компонент, предпочтительных состояний исправности, которые определяет разработчик и выбирает для мониторинга, конфигурационные аспекты, в отношении того, как оно будет установлено и какие параметры настройки приложению или службе потребуются, а также административные задачи и их планирование. Для исходного кода модели далее задают атрибуты (или вводят теги (неотображаемые элементы разметки)) в специфических областях для декларирования.

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

Подкомпонент 114 задания атрибутов связан с заданием атрибутов в исходном коде. Задание атрибутов используется, чтобы выразить информацию управления наряду с кодом, к которому она относится. Без задания атрибутов должны были бы быть написаны две отдельные части кода: один - для нормальной работы приложения и другой - для предоставления его для управления. Задание атрибутов в пределах исходного кода используется для того, чтобы описать, какие части кода (названные зондами) следует использовать для определения и/или корректировки степени исправности, а также для задания того, когда следует выполнить правила мониторинга. Зонды могут быть предоставлены из компонентов, которые осуществляют доступ к существующим Интерфейсам Прикладного Программирования (API) операционной системы, или из компонентов, загруженных внутрь исполняющихся приложений или служб. В обоих случаях разработчик добавляет атрибуты, чтобы указать, какое подмножество типов в пределах компонентов должно быть предоставлено и как они должны быть идентифицированы. Зонды идентифицируют с использованием Уникальных Идентификаторов Информационных Ресурсов (URI) в пределах пространства имен администратора. Во время исполнения зонд извлекают посредством его идентификации из каталога всех зондов на компьютере, и вслед за ним ассоциированную информацию в отношении этого зонда.

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

На Фиг.2 показана схема 200, относящаяся к описанию основных компонентов основанной на модели архитектуры 100 управления. Архитектура включает в себя компонент 106 моделей, описываемый в соответствии с Фиг.3А, компонент 108 декларации, описываемый в соответствии с Фиг.3B, системный компонент 110, описываемый в соответствии с Фиг.3C и Фиг.3D, и компонент 112 задач, описываемый в соответствии с Фиг.3E. Задание атрибутов уже было объяснено и на него будут делаться ссылки по всему описанию.

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

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

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

Подкомпонент 302 конфигурационной модели связан с моделированием конфигурации системы. Конфигурационная модель 302 используется для описания параметров настройки приложения, пользовательских элементов управления, значений по умолчанию, различных ограничений и т.д. Подкомпонент 303 модели задач администрирования связан с моделированием административных задач и включает в себя действия, которыми пользователь может воздействовать на систему, такие как запуск, остановка, добавление пользователя, добавление базы данных и корректирующие действия, которые могут быть вызваны из модели 301 исправности. Модель 302 перечисляет все, что может быть сделано с приложением или службой. Архитектурная модель 304 используется для описания распределенных сред и связанного с ними развертывания, обычно связанного, например, с большими сетями клиентов, имеющих одинаковые или подобные параметры настройки и конфигурацию аппаратных и программных средств, и распределенных баз данных. Таким образом, локальное приложение может зависеть от удаленного дискового массива. При развертывании дисковый массив должен присутствовать на уровне развертывания с декларацией и использованием идентификаторов URI. Так как URI независим от машины, распределенные системы могут также получать выгоды от основанной на модели системы управления, соответствующей настоящему изобретению. Модель 305 рабочих характеристик может быть разработана для описания пути, которым разработчик желает использовать метрики для мониторинга рабочих характеристик приложения или службы. Это близко связано с исправностью системы. Может быть сгенерирована модель 306 защиты, которая описывает типы защиты, ассоциированные с приложением или службой.

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

Для выполнения различных аспектов изобретения в настоящем изобретении могут использоваться различные схемы, основанные на искусственном интеллекте. Например, относительно моделей процесс определения того, какие модели могут использоваться для заданного экземпляра или реализации, может быть обеспечен посредством системы и процесса автоматического классифицирования. Кроме того, такие классификаторы могут использоваться для построения рабочих профилей системы, которые начинают обнаружение образов системы, и дают понимание того, что является хорошим состоянием, что плохим состоянием, а также успешными и неудачными транзакциями. Эта информация может затем быть возвращена назад в соответствующую модель и может использоваться как обновленная модель для последующей системы. Такая классификация может использовать вероятностный и/или основывающийся на статистике анализ (например, разложение на полезность и затраты анализа) для прогнозирования или выведения действия, автоматическое выполнение которого для пользователя является желательным. Например, можно использовать классификатор на основе метода опорных векторов (SVM). Можно использовать другие подходы классифицирования, включая Байесовы (Bayes) сети, деревья решений и вероятностные модели классификации, обеспечивающие различные образы модели независимости. Классифицирование, как оно используется здесь, также включает в себя статистическую регрессию, которая используется для разработки модели приоритета.

Как можно без труда понять из рассматриваемого описания, согласно настоящему изобретению можно использовать классификаторы, которые как явно обучены (например, через общие обучающие данные), так и неявно обучены (например, через наблюдение поведения пользователя, прием внешней информации), так, чтобы классификаторы использовались для автоматического определения согласно предопределенным критериям, например того, какие начальные установки необходимо использовать для заданной реализации, и последующей корректировки параметров настройки через какое-то время по мере того, как система развивается и испытывает различные условия нагрузки относительно данных, количества установленных приложений и количества узлов, с которыми требуется взаимодействие. Например, относительно хорошо понятных классификаторов SVM, классификаторы SVM конфигурируют через обучающую или тренировочную фазу в пределах конструктора классификатора и модуля отбора признаков. Классификатор - это функция, которая ставит входному вектору признаков, х = (х1, x2, x3, x4, xn), в соответствие показатель уверенности в том, что ввод принадлежит классу, то есть f(x) = уверенность (класс). Например, в случае систем управления признаки - это системные параметры желаемых состояний, а классы - это категории или области, представляющие интерес (например, все диски, все собственные процессы). Классификаторы также можно использовать, чтобы фиксировать и анализировать журналы регистрации транзакций, искать образы и диагностировать систему посредством поиска успешных и неудачных образов.

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

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

Система основанного на модели управления, соответствующая настоящему изобретению, является компонуемой. Она основана на компонентах, причем компонент включает в себя по существу что угодно. Таким образом, система может быть сокращена до самой меньшей управляемой части и затем скомпонована обратно. В базе данных, например, имеется приложение с экземплярами, базой данных, таблицами и сохраненными процедурами, и она может быть приведена к одному файлу. Рассмотрим приложение 401К. Приложение 401К может зависеть от базы данных, WEB-сервера, собственной деловой логики заказчика, опускаясь до базы данных, которая зависит от операционной системы и всего связанного с ней. В соответствии с новыми аспектами настоящего изобретения желательно осуществлять управление и выдачу отчетов на различных уровнях. Приложения описаны через зависимости между компонентами. Эти зависимости могут выражать то, как отдельное приложение составлено (например, сервер языка структурированных запросов (SQL) содержит службы, экземпляры и базы данных), требования платформы (например, операционная система и другие приложения), а также связь с другим компонентом (Web-сервер, соединенный с сервером SQL). Один администратор может поддерживать базу данных и одну машину, в то время как финансовый руководитель может работать с приложением 401К, а руководитель информационной службы поддерживать работу всех приложений и машин. Модели, сообщения и желаемые состояния должны обработать все так, чтобы к отдельной метрике можно было обратиться с целью определения того, работает ли система, как ожидается.

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

На Фиг.3B показаны блоки, связанные с компонентом 108 декларации основанной на модели архитектуры управления, соответствующей настоящему изобретению. Декларация, которая поставляется вместе с приложением, содержит информацию относительно моделей и задания атрибутов в исходном коде в машиночитаемой форме для использования службами системы управления. Административные задачи для приложения определены в декларации. Может иметься ряд сгенерированных деклараций, которые соответствуют моделям, включая следующее: первый подкомпонент 307 декларации, связанный с зависимостями компонентов, взаимосвязями между компонентами и ролями служб; второй подкомпонент 308 декларации, связанный с событиями, зондами, правилами и действиями; третий подкомпонент 309 декларации, связанный с параметрами настройки и утверждениями; четвертый подкомпонент 310 декларации, связанный с командами (т.н. командлетами) и административными ролями; пятый подкомпонент 311 декларации, связанный с распределенными средами; и шестой подкомпонент 312 декларации, связанный с развертыванием.

Декларация - это "мост" между разработчиком и эксплуатационной группой и администратором, и она создается автоматически специальным инструментальным средством, просматривающим модели на предмет снабженного атрибутами кода. Компонент 307 декларации используется средством настройки для определения того, как устанавливать приложение или службу. Он описывает логические компоненты, файлы, куда файлы должны быть установлены, и конфигурационные параметры настройки (или любые другие параметры настройки). Зависимости - это то, что должно быть определено перед установкой, и они включают в себя различные роли, так чтобы приложение могло быть установлено в различных режимах, с различными степенями защиты и с различными рабочими профилями. Компонент 307 декларации помогает понять пользователю и/или системе, что делать вручную и что автоматически. Степень структурированности (гранулярность) декларации может доходить до одной декларации на один компонент.

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

Модель 301 исправности используется, чтобы сформировать декларацию 308 исправности. Декларация 308 исправности заполняется на основе модели 301 исправности с использованием задания атрибутов и других инструментальных средств. События вызываются не в модели 301, а в файле ресурса. Программное инструментальное средство просматривает ресурсные файлы и снабженный атрибутами исходный код и заполняет декларацию 308 исправности. Состояния отказа могут быть обнаружены посредством наблюдения за предопределенной последовательностью событий или посредством мониторинга порогов счетчиков рабочих характеристик. Команды могут передаваться в систему в отношении того, как реагировать на такие состояния отказа. Модель исправности преобразуется в правила. Декларация 308 исправности включает в себя последовательности событий типа правил с параметрами, такими как событие1, событие2, время3 и т.д.

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

Модель 303 административных задач преобразуется в действия через командлеты и декларацию 310 административных ролей. Например, если требуется создание резервной копии данных, то командлет представляет собой действительный код или URI, используемый для реализации задачи резервирования. Если должны быть выполнены многочисленные задачи администрирования, декларация 310 дает путь URI к этим командам и, возможно, к коду. Командлет может быть обработан через утверждение в коде или может потребовать внешнего кода. Административная роль представляет собой еще одну абстракцию, поддерживающую, например, множество классов пользователей, которые управляют этим приложением или службой, а также уровень управления, который они могут осуществлять. Это связано с основанным на роли доступом. Требуются метаданные, которые описывают роли различных пользователей и разрешенные им действия. Роли пересекают все аспекты системы - кому разрешено устанавливать, кто может изменять мониторинг, кто может наблюдать за исправностью, кто может разрешать предупреждения, кто может предпринимать эти различные действия и т.д.

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

Архитектурной модели 304 соответствуют декларация 311 распределенных компонентов и декларация 312 развертывания. Здесь, например, охватываются сетевые соединения между машинами, требования к аппаратному обеспечению. Декларация 312 развертывания поддерживает по меньшей мере приложения, содержащие WEB-серверы, серверы среднего уровня и серверы баз данных и включает в себя интерфейсные приложения, исполняемые на клиенте/сервере, сетевые взаимодействия между двумя приложениями, и описывает зависимости между отдельными узлами. Во время развертывания создаются экземпляры того, что было описано в полной архитектурной модели 304.

Каждая из моделей рабочих характеристик и защиты (305 и 306) поддерживает соответствующие декларации (не показаны), которые описывают относящиеся к ним функции и операции.

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

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

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

На Фиг.3C проиллюстрирована блок-схема основных системных API системного компонента 110 системы, используемого для управления приложением или службой 314 в соответствии с основанной на модели архитектурой управления согласно настоящему изобретению. Системный компонент 110 включает в себя приложение или службу 314, управление которым должно осуществляться в соответствии с настоящим изобретением. Система 110 включает в себя ряд связанных интерфейсов API для обеспечения управления, основанного на модели. Система 110 содержит множество служб, которые сконфигурированы согласно информации из декларации приложения (описанной в соответствии с Фиг.3B).

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

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

Предусмотрен API 316 установки, осуществляющий связь с приложением 314, с целью обеспечения установки приложения, обновления приложения и установки исправлений. API 316 установки берет совокупности деклараций через код и создает экземпляры этих совокупностей посредством предписания системе установить этот компонент, эту декларацию и эту версию на этой машине. API 316 установки имеет ассоциированный с ним протокол 318 и средство 320 просмотра. Протокол 318 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство просмотра 320 отображает данные, относящиеся к API 316 установки. API 316 установки не только обеспечивает установку на одной машине, но также и для распределенных приложений или служб, задействующих как локальные, так и удаленные системы, а также инициализацию и абстракцию аппаратного обеспечения. Для среды распределенного информационного центра важна способность реализации абстракции аппаратного обеспечения в целом и с более мелкой гранулярностью для реализации абстракции в отношении конкретной машины. Протокол, как рассмотрено здесь в связи с API, представляет собой правила, которые регламентируют передачу и прием этих данных, относящихся к API. Средство 320 просмотра, как понимается в этом описании, является программой, которая отображает данные, относящиеся к API, в данном случае - к API 316 установки. Данные API включают в себя, но не в ограничительном смысле, например, звуковые файлы, видеофайлы и другие типы файлов данных.

Система 110 включает в себя конфигурационный API 322, осуществляющий связь с приложением 314, чтобы обеспечить конфигурирование приложения 314. Конфигурационный API 322 имеет ассоциированные с ним схему 323, протокол 324 и средство 326 просмотра. Схема 323 определяет структуру и содержание данных, проходящих между API 322 и приложением 314. Протокол 324 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство просмотра 326 отображает данные, относящиеся к конфигурационному API 322.

Также предусмотрен API 328 администрирования, который обеспечивает администрирование для распределенных сред по принципу «многие к одному». API 328 осуществляет связь с управляемым приложением 314, а также с удаленными системами (не показанными). API 328 имеет ассоциированный протокол 330 и средство 332 просмотра.

Система 110 включает в себя API 334 счетчика рабочих характеристик, осуществляющий связь с приложением 314, чтобы облегчить отслеживание переменных счетчика, которые используются в управлении приложением 314. API 334 счетчика имеет ассоциированные с ним протокол 336 и средство 338 просмотра. Протокол 336 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство 338 просмотра отображает данные, относящиеся к API 334 счетчика. Счетчики рабочих характеристик предоставляются приложением 314, которое делает эти счетчики доступными через средство 338 просмотра.

Также прилагается API 340 инструментальных средств, осуществляющий связь с приложением 314, чтобы обеспечить конфигурирование инструментальных средств и прохождение данных инструментальных средств от приложения 314. API 340 инструментальных средств имеет ассоциированные с ним протокол 342 и средство 344 просмотра, через которое предоставляются инструментальные средства. Протокол 342 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство 344 просмотра отображает данные, относящиеся к API 340 инструментальных средств. API 340 инструментальных средств взаимодействует с управляемым приложением 314 через IPC (межпроцессорное взаимодействие) 346. IPC - это автоматический обмен данными между одной и другой программами в пределах одного компьютера или по сети. Один пример функции IPC происходит, когда пользователь вручную вырезает данные из одного файла и вставляет их в другой файл, используя буфер обмена. Счетчики всегда открыты через совместно используемую память, в то время как инструментальные средства выдаются по требованию. API 340 инструментальных средств также включает в себя схему 348, которая обеспечивает совокупность классов инструментальных средств аналогично схеме событий, также может быть включен относящийся к инструментальным средствам журнал регистрации (не показан); однако многие администраторы предпочитают использовать журнал регистрации событий.

Система 110 включает в себя каталог 347, который является хранилищем, которое отслеживает информацию о компонентах и режиме и выполняет кэширование этой информации режима. Эта информация режима исходит из деклараций при установке, ее части являются динамическими и обновляются во время выполнения. Каталог 347 включает в себя API каталога и обеспечивает доступ к событиям, счетчикам, инструментальным средствам и конфигурационным данным, при этом перечислены только несколько типов данных, хранящихся в нем. Доступ к каталогу 347 обеспечивается посредством протокола 351 и через средство 353 просмотра. Центральная база данных конфигурации содержит свернутый или совокупный вид каталога по множеству управляемых узлов.

Система 110 включает в себя API 350 событий, осуществляющий связь с приложением или службой 314, чтобы обеспечить реализацию и отслеживание событий, которые используются в управлении приложением 314. API 350 событий сопряжен с журналом 352 регистрации событий, который служит хранилищем для всех происходящих событий. API 350 событий имеет ассоциированные с ним протокол 354 и средство 356 просмотра. Протокол 354 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство 356 просмотра отображает данные, относящиеся к API 350 событий. Обмен данными с приложением 314 происходит в соответствии со схемой 358 событий, которая определяет структуру и содержание проходящих данных. События оказываются раскрытыми по мере их описания или появления. Схема описывает внешнюю сторону события.

Система 110 включает в себя API 360 автоматизации, осуществляющий связь с приложением 314, чтобы обеспечить процедуры автоматизации, которые можно было бы нормальным образом выполнять во взаимодействии с приложением 314. API 360 автоматизации имеет ассоциированные с ним протокол 362 и оболочки 364. Протокол 362 обеспечивает обмен данными, относящимися к API, с другими компонентами системы 110. Оболочка 364 обеспечивает пользовательский интерфейс к API 360 автоматизации, чтобы обеспечить взаимодействие пользователя с ним для ввода и отображения данных, связанных с процессами автоматизации, и пользовательского управления процессами автоматизации.

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

API 366 запланированных задач имеет ассоциированные с ним протокол 368 и средство 370 просмотра. Протокол 368 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство 370 просмотра отображает данные, связанные с API 366 запланированных задач.

Схема 372 задач определяет структуру и содержание данных, проходящих между API задач и другими компонентами.

Данные автоматизации и данные задач принимают от моделей задач и командлетов. Эти признаки могут быть автоматизированы через оболочку управления либо локальным, либо удаленным образом. Система планирования может выполнять это, например, выполнение резервного копирования в 3:00 утра.

Следует понимать, что компоненты, описанные на Фиг.3С, могут представлять таковые из локальной реализации, в то время как компоненты по Фиг.3D могут представлять компоненты, которые связаны с распределенной реализацией, так что анализ охватывает множество машин и программных систем. Таким образом, в распределенной реализации компоненты по Фиг.3D обмениваются данными по меньшей мере с одной из локальных систем по Фиг.3С, но обычно со множеством таких локальных реализаций в проводном и/или беспроводном режиме. В локальной реализации система 110 может также включать в себя любой или все из компонентов, показанных на Фиг.3D, включая API 365 службы локального мониторинга. API 365 службы локального мониторинга также включает в себя протокол 367, средство 369 просмотра и схему 371, каждый из которых обеспечивает функциональные возможности, подобные функциональным возможностям аналогичных компонентов других API. В распределенной реализации API 365 службы локального мониторинга далее передает информацию мониторинга службе распределенного мониторинга, описанной ниже.

На Фиг.3D изображена блок-схема относящихся к управлению интерфейсов API системного компонента 110 основанной на модели архитектуры управления, соответствующей настоящему изобретению. Предусмотрен подкомпонент 374 базы данных конфигурации, доступ к которому и управление которым осуществляется через API 376 центрального конфигурирования. API 376 центрального конфигурирования сопряжен со всеми подкомпонентами системы 110 и имеет ассоциированные с ним протокол 378 и средство 380 просмотра для связи и взаимодействия, а также компонент схемы 382, который описывает форму конфигурационных параметров настройки и атрибутов, типа утверждений и значений по умолчанию. Протокол 378 обеспечивает обмен относящимися к API данными с другими компонентами системы 110.

Предусмотрен также подкомпонент 383 базы данных операций, который служит в качестве хранилища для относящихся к операциям данных системы управления, например отчеты, текущие состояния и статистические данные. API 384 мониторинга сопряжен с базой данных 383 операций и со всеми подкомпонентами основанной на модели системы управления и дополнительно имеет ассоциированные с ним протокол 385, средство 386 просмотра и схему 387. Протокол 385 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство 386 просмотра отображает данные, относящиеся к API 384 мониторинга. Схема 387 предоставляет определение для всей базы данных 383 операций по меньшей мере относительно структуры и типа содержания, которое каждый элемент данных может иметь в пределах этой структуры.

Центральное конфигурирование может касаться всех API и используется администратором, чтобы задавать детали конфигурации, которые могут включать в себя детали сценария для распределенного приложения, такие как, например, на какие машины приложение должно быть установлено. Конфигурирование также включает в себя конфигурирование мониторинга. Например, все машины должны показывать загрузку центрального процессора не менее 80% в течение 5 минут. Таким образом, система мониторинга использует систему конфигурирования. Мониторинг - это то, как администратор гарантирует через систему управления, что приложение сконфигурировано, установлено и ведет себя согласно модели. Это также включает в себя обеспечение ожидаемых функциональных возможностей, желаемого уровня безопасности, должных рабочих характеристик и доставки данных пользователям, как ожидается. Таким образом, мониторинг охватывает все эти области. Общий процесс состоит в установке, конфигурировании, выполнении задач по требованию, обработке событий, обеспечении инструментальных средств и конфирурации, сохранении данных и результатов. Декларация исправности предоставляет рабочие команды системе мониторинга в форме правил, которые являются командами для системы мониторинга. В целом, декларация содержит команды времени выполнения, и во время выполнения реализуется желаемое состояние.

Служба мониторинга является как локальной службой, так и центральным или распределенным механизмом. Для распределенной реализации степень исправности включает в себя степень исправности для локальной машины, а также взаимосвязи между локальной и удаленными машинами. Например, пусть в заданном кластере имеется 10 машин, пока шесть машин функционируют должным образом, система считается исправной. Однако, если работает не более пяти машин, статус исправности системы ухудшается до предостерегающего состояния. Если работает не более четырех машин, то статус исправности системы может считаться соответствующим состоянию отказа. Абстракция аппаратных средств обеспечивает активацию одной или более резервных систем или приложений/служб, если одна или более машин кластера отказывают или переходят в автономный режим. Таким образом, управление пулом неактивных или совместно используемых ресурсов может осуществляться на основе команд. Эта возможность особенно полезна в среде информационного центра. Можно реализовывать автоматизированные действия для обеспечения гарантии того, что система поддерживает оптимум или по меньшей мере минимум функциональных возможностей.

Один аспект основанной на модели архитектуры управления позволяет разработчику создать большое количество правил, которые выражают критерии, которые должны выполняться для системы, чтобы она могла считаться исправной. API 384 мониторинга включает в себя средство обработки правил во время выполнения, которое обеспечивает неявную параллельную обработку правил. Средство обработки правил принимает входные команды, которые выражают правила в промежуточной форме, где правила выражены, используя язык определения правил (RDL). Средство обработки правил также принимает конфигурационные данные от базы 374 данных конфигураций, которые используются для получения кода правила. Транслятор считывает входные команды и преобразовывает их в форму для параллельного выполнения. Средство времени выполнения считывает преобразованные команды и обеспечивает параллельное выполнение. Код правила получают, загружая конфигурационные данные в средство времени выполнения, которое задает, какие правила должны выполняться, а также необходимые для выполнения этого правила параметры. Параметры правил могут быть изменены во время выполнения, так, например, запуск правил, имеющих значительное воздействие на систему, только когда обнаружена проблема. Таким образом, правила являются динамическими, так же как и пороги, которые соответственно также могут быть изменены. API 384 мониторинга также соединяется со всеми подкомпонентами системы 110.

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

Также предусмотрен API 391 доступа, основанного на роли, который сопряжен со всеми подкомпонентами основанной на модели системы управления и дополнительно имеет ассоциированные с ним протокол 392 и средство 393 просмотра. Протокол 392 обеспечивает обмен относящимися к API данными с другими компонентами системы 110. Средство 393 просмотра отображает данные, относящиеся к API 391 доступа, основанного на роли. Этот API 391 поясняется на уровне над компонентами мониторинга и конфигурирования для обеспечения полного администрирования доступа к различным компонентам и аспектам основанной на модели системы управления. Нет необходимости, чтобы API 391 доступа, основанного на роли, включал бы в себя протокол 392 и средство 393 просмотра, т.к. эти функции могут быть обеспечены другими компонентами системы 110.

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

На Фиг.3Е показаны главные подкомпоненты компонента 112 задач из основанной на модели архитектуры управления, соответствующей настоящему изобретению. Задачи описаны через модель задач администрирования. Задачи распределяются на три подкомпонента: подкомпонент 395 мониторинга, подкомпонент 396 выявления неисправностей и подкомпонент 397 администрирования.

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

Идентификаторы URI используются в основанной на модели архитектуре управления для уникальной идентификации абстрактных или физических ресурсов или наборов ресурсов. Схема для ресурса может быть идентифицирована по URI с меткой-заполнителем для ресурса. URI с меткой-заполнителем назван шаблоном URI. Каталог системы основан на шаблонах URI для описания инструментальных средств без ссылок на конкретные экземпляры. Шаблоны URI позволяют идентифицировать зонды и понять их характеристики без реального извлечения зонда для конкретного экземпляра. Защита возможности предварительного определения инструментальных средств отдельно от экземпляров делает развертывание и авторскую разработку правил проще и связанную с этим операционную систему более управляемой.

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

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

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

Раскрытая архитектура находит применение с помощью системы модели определения услуг, различные аспекты которой являются предметом патентных заявок настоящего правообладателя, первая из которых озаглавлена «Architecture for Distributed Computing System and Automated Design, Deployment, And Management of distributed Applications”, подана 24 октября 2003 г. и имеет номер US 10/693004, а вторая озаглавлена «Integrating Design, Deployment, and Management Inases for an Application”, подана 24 октября 2003 г. и имеет номер US 10/693838.

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

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

На Фиг.5 показана более детальная блок-схема последовательности операций процесса реализации управления, основанного на модели. На этапе 500 модели разрабатывают для компонентов приложения, состояний исправности и восстановления, конфигурационных параметров настройки и задач администрирования. На этапе 502 пользователь настраивает систему/правила/модели в соответствии с программным окружением. На этапе 504 в исходный код вводят задание атрибутов, чтобы указать инструментальные и логические средства для мониторинга. На этапе 506 представляют декларацию информации модели задания атрибутов в исходном коде для использования службами системы управления. Декларацию предоставляют для использования службами системы управления в машиночитаемой форме. На этапе 508 одну или более служб системы управления конфигурируют на основе информации из декларации. На этапе 510 административные задачи определяют для приложения в пределах декларации, например, посредством регистрации командлетов в системе планирования и т.д. Процесс далее достигает останова.

На Фиг.6 изображена блок-схема последовательности операций процесса реализации желаемых состояний управления, основанного на модели. На этапе 600 осуществляют доступ к желаемым состояниям из декларации. На этапе 602 проверяют зависимости и устанавливают только необходимые файлы, параметры настройки и средства безопасности. На этапе 604 выполняют подписку на события и их пересылку, как определено в декларации. На этапе 606 периодически собирают данные инструментальных средств и данные счетчиков, а также результаты выполненных тестов и синтетических транзакций. На этапе 608 выполняют задачи автоматического управления. На этапе 610 ограничивают доступ к программным функциям. Однако этот этап необязательно включать, чтобы облегчить основанное на модели управление в соответствии с настоящим изобретением. На этапе 612 обнаруживают проблемы, выполняют диагностику первопричин, предпринимают корректирующие действия и уведомляют системного администратора, когда необходимо вмешаться. На этапе 614 для всего вышеперечисленного настраивают политики для применения по многим другим типам машин и систем. Процесс далее достигает останова.

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

На Фиг.7 изображена примерная среда 700 для реализации различных аспектов изобретения, которая включает в себя компьютер 702, включающий в себя процессор 704, системную память 706 и системную шину 708. Системная шина 708 подсоединяет элементы системы, включая, но не в ограничительном смысле, системную память 706, к процессору 704. Процессор 704 может быть любым из различных имеющихся в продаже процессоров. Двухпроцессорные и другие многопроцессорные архитектуры также можно использовать как процессор 704.

Системная шина 708 может относиться к любому из нескольких типов структуры шины, которая может быть далее подключена к шине памяти (с контроллером памяти или без него), периферийной шине и локальной шине, используя любую из ряда коммерчески доступных шинных архитектур. Системная память 706 включает в себя постоянное запоминающее устройство (ПЗУ, ROM) 710 и оперативное запоминающее устройство (ОЗУ, RAM) 712. Базовая система ввода-вывода (BIOS) хранится в энергонезависимой памяти 710 типа ПЗУ, электрически программируемого ПЗУ (EPROM), электрически стираемого программируемого ПЗУ (EEPROM), при этом BIOS содержит основные процедуры, помогающие передавать информацию между элементами в пределах компьютера 702, как, например, во время запуска. ОЗУ 712 может также включать в себя высокоскоростное ОЗУ типа статического ОЗУ для кэширования данных.

Компьютер 702 дополнительно включает в себя накопитель 714 на жестких дисках, магнитный дисковод 716 (например, для чтения или записи на съемный диск 718) и оптический дисковод 720 (например, читающий диск 722 CD-ROM или читающий или записывающий на другие оптические носители большой емкости типа цифрового многофункционального (DVD)). Накопитель 714 на жестких дисках, магнитный дисковод 716 и оптический дисковод 720 могут быть подсоединены к системной шине 708 через интерфейс 724 накопителя на жестких дисках, интерфейс 726 магнитного дисковода и интерфейс 728 оптического дисковода соответственно. Дисководы и накопители и соответствующие им машиночитаемые носители обеспечивают энергонезависимое хранение структур данных, машиноисполняемых команд и т.д. в памяти. Для компьютера 702 дисководы и носители обеспечивают хранение программ вещания в соответствующем цифровом формате. Хотя вышеупомянутое описание машиночитаемых носителей относится к жесткому диску, сменным магнитным дискам и компакт-дискам, должно быть оценено специалистами в данной области техники, что другие типы машиноносителей, такие как ZIP-диски, магнитные кассеты, карты флэш-памяти, цифровые видеодиски, картриджи и т.п., могут также использоваться в примерной рабочей среде, кроме того, любой такой носитель может содержать машиноисполняемые команды для выполнения способов настоящего изобретения.

Ряд программных модулей может быть сохранен на накопителях и в дисководах и в ОЗУ 712, включая операционную систему 730, одну или более прикладных программ 732, другие программные модули 734 и данные 736 программ. Вся операционная система, приложения, модули, и/или данные, либо их части могут также быть кэшированы в ОЗУ 712.

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

Пользователь может вводить команды и информацию в компьютер 702 с использованием клавиатуры 738 и координатно-указательного устройства типа мыши 740. Другие устройства ввода данных (не показанные) могут включать в себя микрофон, пульт инфракрасного дистанционного управления, джойстик, игровую панель, спутниковую антенну, сканер или что-либо подобное. Эти и другие устройства ввода данных часто подсоединены к процессору 704 через интерфейс 742 последовательного порта, который подключен к системной шине 708, но может быть подсоединены посредством других интерфейсов, таких как параллельный порт, игровой порт, универсальная последовательная шина (USB), интерфейс инфракрасного порта и т.д. Монитор 744 или другой тип устройства отображения также подсоединен к системной шине 708 через интерфейс типа видеоадаптера 746. В дополнение к монитору 744 компьютер обычно включает в себя другие периферийные устройства вывода (не показанные) типа громкоговорителей, принтеров и т.д.

Компьютер 702 может работать в сетевой среде, используя логические соединения через проводные и/или беспроводные линии связи к одному или более компьютерам, таким как удаленный компьютер 748. Удаленный компьютер(ы) 748 может быть рабочей станцией, компьютером-сервером, маршрутизатором, персональным компьютером, портативным компьютером, основанным на микропроцессоре развлекательным устройством, одноранговым устройством или другим обычным узлом сети и обычно включает в себя многие или все элементы, описанные применительно к компьютеру 702, хотя для целей краткости показано только устройство 750 хранения данных. Изображенные логические соединения включают в себя локальную сеть (LAN) 752 и глобальную сеть (WAN) 754. Такие сетевые среды распространены в офисах, компьютерных сетях масштаба предприятия, интрасетях и Интернет.

При использовании в сетевой среде LAN компьютер 702 соединен с локальной сетью 752 через сетевой интерфейс или адаптер 756 проводной или беспроводной связи. Адаптер 756 может обеспечить проводную или беспроводную связь с LAN 752, которая может также включать в себя точку беспроводного доступа, расположенную в ней для связи с адаптером 756 беспроводной связи. При использовании в сетевой среде WAN компьютер 702 обычно включает в себя модем 758, или он подключен к серверу связи по LAN, или имеет другое средство для установления связи через WAN 754, такую как Internet. Модем 758, который может быть внутренним или внешним устройством проводной или беспроводной связи, подключен к системной шине 708 через интерфейс 742 последовательного порта. В сетевой среде программные модули, изображенные относительно компьютера 702, или их части, могут храниться в удаленном запоминающем устройстве 750. Следует понимать, что показанные сетевые соединения являются иллюстративными и могут применяться другие средства установления линии связи между компьютерами.

Компьютер 702 выполнен с возможностью осуществления связи с любым беспроводным устройством или объектом, осуществляющим в рабочем состоянии беспроводную связь, например принтер, сканер, настольный и/или портативный компьютер, персональное цифровое информационное устройство, любая часть оборудования или расположения, связанного с обнаруживаемой по беспроводной связи меткой (например, киоск, стенд новостей, комната отдыха), и телефон. Это включает в себя по меньшей мере беспроводные технологии Wi-Fi и Bluetooth™. Таким образом, связь может иметь предопределенную структуру, как, например, обычная сеть или просто осуществляемая по необходимости связь между по меньшей мере двумя устройствами.

Wi-Fi, дословно «Беспроводная Точность», позволяет организовать соединение с Internet с дивана дома, из кровати в гостиничном номере или из зала заседаний на работе, без проводов. Wi-Fi - это беспроводная технология, подобная сотовому телефону, которая обеспечивает таким устройствам, как компьютеры, возможность посылки и приема данных дома и на улице в пределах зоны обслуживания базовой станции. Wi-Fi сети используют радиотехнологии, называемые IEEE 802.11 (a, b, g и т.д.), чтобы обеспечить безопасную, надежную, быстродействующую беспроводную связь. Wi-Fi сеть может использоваться, чтобы соединять компьютеры друг с другом, с Internet и с проводными сетями (которые используют IEEE 802.3 или Ethernet). Wi-Fi сети функционируют в нелицензированных полосах радиочастот 2,4, и 5 ГГц со скоростью передачи данных 11 Мбит/с (802.11 b) или 54 Мбит/с (802.11 a) или с изделиями, которые поддерживают обе полосы частот (двухполосные), так что сети могут обеспечить практическую эффективность, подобную базовой эффективности проводной сети 10BaseT Ethernet, используемой во многих офисах.

На Фиг.8, показана схематическая блок-схема примерной вычислительной среды 800 в соответствии с настоящим изобретением. Система 800 включает в себя одного или более клиентов 802. Клиент(ы) 802 могут быть аппаратными и/или программными (например, потоки, процессы, вычислительные устройства). Клиент(ы) 802 могут вмещать cookies (небольшие фрагменты данных о предыстории обращений пользователя к серверу) и/или соответствующую им контекстную информацию, например, используя настоящее изобретение. Система 800 также включает в себя один или более серверов 804. Сервер(ы) 804 могут также быть аппаратными и/или программными (например, потоки, процессы, вычислительные устройства). Серверы 804, например, могут вмещать потоки, чтобы производить преобразования посредством применения настоящего изобретения. Одна возможная связь между клиентом 802 и сервером 804 может быть в форме пакета данных, адаптированного для передачи между двумя или более компьютерными процессами. Пакет данных, например, может включать в себя cookies и/или ассоциированную контекстную информацию. Система 800 включает в себя инфраструктуру 806 связи (например, глобальную сеть связи типа Internet), которая может использоваться для обеспечения связи между клиентом(ами) 802 и сервером(ами) 804.

Связь может быть обеспечена посредством проводной (включая оптическое волокно) и/или беспроводной технологии. Клиент(ы) 802 в рабочем состоянии подсоединены к одному или более клиентским хранилищам 808 данных, которые могут быть использованы, чтобы хранить информацию, локальную для клиента(ов) (например, cookies и/или ассоциированную контекстную информацию). Точно так же сервер(ы) 804 в рабочем состоянии связаны с одним или более серверами 810 данных, которые можно использовать для хранения информации, локальной для серверов 804.

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

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

Изобретение относится к управлению компьютерными системами и приложениями. Техническим результатом является улучшение и повышение надежности управляемости приложений. Разработчик может описывать приложение или службу в терминах составляющих его компонентов. Желаемые состояния могут быть описаны в терминах функциональных возможностей, конфигурации, защиты и рабочих характеристик. Описание используют при установке приложения, чтобы сконфигурировать службы управления, которые помогают гарантировать доступность приложения через автоматические действия управления, такие как управление конфигурацией, обнаружение проблем, диагностика и восстановление. 7 н. и 32 з.п. ф-лы, 12 ил.

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

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

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

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

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

6. Система по п.1, в которой компонент описания содержит компонент административных задач, который включает в себя административные задачи, определенные в декларации приложения.

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

8. Система по п.1, в которой компонент описания содержит компонент системы управления, который использует желаемые состояния, выраженные в декларации.

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

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

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

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

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

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

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

16. Система по п.9, в которой в соответствии с одним или более из желаемых состояний выполняется настройка политики для использования со множеством различных компьютеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36. Система по п.35, в которой приложение или служба являются распределенными.

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

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

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