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

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

Иллюстрации

Показать все

Реферат

Перекрестная ссылка на родственные заявки

Приоритет настоящей патентной заявки основан на родственной предварительной патентной заявке 61/048932 под названием "Service Performance Manager with Obligation-Bound Service Level Agreements (SLA) and Patterns for Mitigation and Autoprotection", поданной 29 апреля 2008 г.и во всех отношениях в порядке ссылки включенной в настоящую заявку.

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

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

Предпосылки создания изобретения

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

Краткое изложение сущности изобретения

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

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

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

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

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

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

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

на фиг.5 схематически проиллюстрирована определяемая пользователем последовательность действий описанного SPM в соответствии с настоящим изобретением,

на фиг.6 схематически проиллюстрирована определяемая пользователем последовательность действий описанного SPM в соответствии с настоящим изобретением,

на фиг.7 представлена схема, иллюстрирующая архитектуру продуктов SPM в соответствии с настоящим изобретением,

на фиг.8 проиллюстрирована блок-схема, на которой подробно представлено простое правило и сложное правило в соответствии с настоящим изобретением,

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

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

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

на фиг.12 показан перечень типов эталонных целевых объектов в соответствии с настоящим изобретением,

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

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

Подробное описание

Диспетчер состояния предоставляемых услуг

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

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

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

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

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

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

В одном из вариантов осуществления SPM обеспечивает создание SLA и правил с использованием функции-мастера.

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

В случае инцидента или нарушения оно может быть устранено путем передачи оповещения на пользовательский интерфейс или приборную панель или по электронной почте. В одном из вариантов осуществления может быть инициирована последовательность действий управления бизнес-процессом (ВРМ) или управления взаимоотношениями с клиентами (CRM).

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

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

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

Бизнес-сценарий

В типичном бизнес-сценарии действуют поставщики услуг и обслуживаемые клиенты. SPM может использоваться для контроля и управления бизнес-услугами вне зависимости от того, является ли пользователь поставщиком услуг или обслуживаемым клиентом. На фиг.1 показана схема 100, на которой проиллюстрирован один из примеров выбора наименований для контроля в одном из вариантов осуществления описанного SPM. Описанный SPM может контролировать запросы, инфраструктуру и услуги, включая без ограничения контроль запросов поставщика услуг или клиента или запросы с деловой сфере; контроль инфраструктурных узлов или контейнеров; и контроль неделимых, организованных или коллективных услуг. В одном из вариантов осуществления для устранения последствий инцидентов и передачи оповещений SPM использует системы датчиков и/или SLA в сочетании с контролем запросов, инфраструктуры и предоставляемых услуг.

На фиг.2 показана блок-схема, иллюстрирующая, как в одном из вариантов осуществления SPM может использоваться в одном из примеров процесса 200 предоставления кредита. На первом шаге 210 проиллюстрированного процесса извлекают данные клиента. На следующем шаге 220 проверяют кредитоспособность клиента с использованием внешней службы 230 проверки кредитоспособности. В одном из вариантов осуществления служба проверки кредитоспособности является внешней и может иметь гарантированную доступность 99,9%. В зависимости от того, является ли кредит допустимым или нет (шаг 240), делают предложение или в кредите отказывают. Если кредит является допустимым, на шаге 250 устанавливают ставку по кредиту, в противном случае на шаге 260 в кредите отказывают. SPM используют в этом примере, чтобы контролировать доступность, реагирование и обмен данными между внешней службой 230 проверки кредитоспособности и кредитной компанией.

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

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

Цикл осуществления проекта

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

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

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

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

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

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

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

Определяемая пользователем последовательность действий

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

На фиг.4 показана схема 400, иллюстрирующая определяемую пользователем последовательность действий при установлении технических требований. Она может предусматривать установление технических бизнес-требований. В одном из вариантов осуществления бизнес-аналитик 410 определяет все используемые бизнесом услуги и предоставляет данные 420 для настройки и конфигурирования SPM. Эти данные могут включать бизнес-потребности на всех уровнях обслуживания. Данные 420 предоставляют системному администратору 430. Затем может быть собрана информация, включая без ограничения информацию от системного администратора 430, системного архитектора 440 и администратора 450 SPM, а также другую информацию для определения технических требований 460, включая без ограничения потребности в обслуживании, правила, действия, узлы и устройства. Для оценки бизнес-услуг определяют контрольные точки, такие как услуги, технология, устройства и узлы. Данные предоставляют администратору 450 SPM, и они могут направлять настройку и конфигурирование SPM.

На фиг.5 показана схема 500, иллюстрирующая определяемую пользователем последовательность действий при конфигурировании системы и правил контроля функционирования. Администратор 510 SPM может создавать конфигурацию 530 областей и сред. Создание конфигурации 530 администратором 510 SPM может включать идентификацию всех сред и областей, которыми должна управлять инстанция SPM, идентификацию всех контейнеров услуг и/или идентификацию всех услуг в этих средах и областях. После идентификации контейнеров услуг и услуг администратор SPM также может сконфигурировать или создать группы 570 целевых объектов с целью объединения целевых объектов в логические группы. Например, в одном из вариантов осуществления администратор SPM может объединить в одну группу целевых объектов все услуги согласно требованиям золотого SLA, а все остальные услуги - в другую группу целевых объектов. До установления правил для групп 570 целевых объектов администратор SPM изучает доступные выходные показатели 560, чтобы оценить, являются ли они достаточными. Если для систематизации существующих показателей или накопления нового числового показателя необходим какой-либо индивидуальный показатель, администратор SPM задает индивидуальные показатели 560. Исходя из SLA или неформальных ожиданий предоставляемых услуг, администратор SPM устанавливает правила для групп целевых объектов и организует их в технические требования и наборы 550 правил. Администратор SPM задает предпринимаемые действия, когда правило инициирует или активизирует конкретный целевой объект 540. Действия включают оповещение группы пользователей, действия по изменению масштаба, такие как предоставление нового функционального контейнера (узла/механизма) или внедрение услуг в новом функциональном контейнере, действия по самозащите, такие как блокирование пользователя, передающего слишком много запросов, или заданное администратором индивидуальное действие. В одном из вариантов осуществления администратор 510 SPM может использовать перспективу построения и конфигурирования правил, чтобы устанавливать правила для группы выбранных целевых объектов. Соответствующие услуги объединяют в группы целевых объектов, и устанавливают для них правила. Эти правила могут содержать условия, заданные для показателей степени обслуживания. Правила также могут быть связанными с индивидуальными действиями, которые автоматически инициируются при выполнении определенных условий для правила. Данные показателей в различных формах, таких как диаграммы и отчеты, отображаются на приборной панели для просмотра и управления.

На фиг.6 показана схема 600, иллюстрирующая определяемую пользователем последовательность действий при контроле и управлении системой. Администратор 610 SPM может в диалоговом режиме контролировать систему 630 путем просмотра на приборной панели исходных и совокупных показателей с сопутствующей контекстной информацией, такой как подробности внедрения, информация об устройствах и узлах и генерированные оповещения. Если правила установлены, система будет сравнивать результаты 640 измерений с заданными пороговыми условиями правил и при необходимости инициировать действия 620. Пороги могут динамически генерироваться внешней системой путем анализа характеристик показателя за прошлый период. Чтобы генерировать пороговые значения для сравнения, может использоваться тестирование и моделирование. Гарантированные действия 620 могут включать действия по самозащите, такие как блокирование запросов до устранения инициирующего условия, предоставление новых ресурсов (изменение масштаба) до устранения инициирующего условия, инициирование ручной последовательности действий, чтобы администратор вручную устранил последствия (например, повторно запустил базу данных, предоставил новое аппаратное обеспечение и т.д.). Ручное устранение последствий также может быть инициировано путем генерирования оповещения (сообщения по электронной почте или другого сообщения). Если условие задано и правило выполняется, правило может инициировать действие 620. Действием может являться, например, передача уведомления, передача оповещения, вызов сценария или добавление узла. Действия помогают администратору 610 SPM управлять показателями работы системы и обеспечивать надежность системы.

Архитектура продукта

В архитектуру описанного SPM могут входить группы, включая без ограничения пользовательский интерфейс, подключенный к администратору платформы услуг с сервис-ориентированной архитектурой, серверные веб-услуги, интегрированные в платформу услуг с сервис-ориентированной архитектурой, и системные услуги, такие как услуга правил и услуга действий, развернутые в основании платформы услуг с сервис-ориентированной архитектурой. В одном из вариантов осуществления описанный SPM может быть интегрирован в платформу услуг TIBCO ActiveMatrix®.

На фиг.7 показана схема 700, иллюстрирующая один из вариантов осуществления архитектуры продуктов SPM. SPM имеет датчики 760 различных категорий для контроля данных, относящихся к платформам с SOA. В одном из вариантов осуществления датчики непосредственно внедрены в инфраструктуру 780 контейнера. Датчики также могут измерять информацию, поступающую от другого интегрирующего программного обеспечения или прикладного программного обеспечения 770, которое обеспечивает сервис в SOA. Дополнительные датчики 770 могут измерять соответствующую информацию о каждой компьютерной операционной системе, чтобы обеспечивать дополнительный контекст, такой как информация о ЦП, памяти и использовании сети. В одном из вариантов осуществления датчики SPM могут быть усовершенствованы, чтобы поддерживать индивидуальные показатели. Например, датчики SPM могут извлекать информацию о бизнесе из полезной нагрузки запроса на обслуживание, обеспечивая дополнительный контекст о важности запроса. Информация, собранная датчиками, может распределяться по системным сервисам 750 SPM посредством действующей в режиме реального времени инструментальной шины 740. В одном из вариантов осуществления SPM может иметь динамические датчики 760 услуг узлов контроля данных, относящихся к ТIBСО ActiveMatrix® и/или TIBCO BusinessWorks™.

Системные услуги SPM обычно действуют в изолированной системной среде 750 SPM на одном или множестве специально предусмотренных узлов и аппаратных средств. В одном из вариантов осуществления все характерные для SPM услуги размещены на узле под названием "spmnode" в отдельной среде "spmenv". В одном из вариантов осуществления обеспечивается отдельная среда "spmenv", которая не используется для каких-либо бизнес-услуг. Системные услуги SPM могут среди прочих услуг включать услугу правил, услугу диспетчера действий, услугу стандартных действий и услугу оповещения. Услуга правил может осуществлять сбор и агрегирование базовых и индивидуальных показателей, перевод и применение правил SPM и передачу триггеров правил или разрешающих сообщений услуге диспетчера действий. Услуга диспетчера действий может обрабатывать предусмотренные правилами действия, например передавать оповещение, активизировать услугу и осуществлять регистрацию триггеров правил или разрешающих сообщений при условии 790, таком как блокирование дальнейших запросов или предоставление новых вычислительных ресурсов. Услуга диспетчера действий может генерировать сообщения с использованием шаблонов для оповещения. Услуга стандартных действий может развертывать услуги на дополнительных существующих узлах, развертывать услугу на дополнительных узлах путем предоставления нового кода, активизировать сценарии в устройстве, генерировать асинхронные уведомления или "прерывания" согласно простому протоколу сетевого управления (SNMP) и обеспечивать поддержку интегрирующего программного обеспечения способов управления устройствами на базе платформ услуг с сервис-ориентированной архитектурой. Действия снова распределяются среди узлов для выполнения посредством шины 740 управления. Сервис оповещения позволяет пользователю определять формат электронной почты (например, текст или HTML) и способ доставки электронной почты (например, в режиме краткого изложения).

В одном из вариантов осуществления интегрирующее программное обеспечение платформ услуг с SOA включает TIBCO Business Works™.

Пользовательский интерфейс (UI) SPM подключен к администратору платформы услуг с SOA. Пользовательский интерфейс выполнен с перспективой построения и конфигурирования правил, а также перспективой просмотра и управления приборными панелями, включая без ограничения контрольную приборную панель 710 и приборную панель 720 SLA. Кроме того, UI может поддерживать контроль индивидуальных показателей, включая определение индивидуального показателя для контроля и управления состоянием любых предоставляемых услуг. Обновления в режиме реального времени результатов измерений функционирования и оповещения выводятся на приборную панель посредством шины обмена сообщениями в режиме реального времени или шины 730 приборной панели.

Интерфейс типа командной строки (CLI) (не показан) поддерживает преимущественно все действия, выполняемые с использованием UI. CLI также может поддерживать создание шаблонов оповещений и их использование для уведомления по электронной почте. Веб-услуги для поддержки UI и CLI SPM могут быть встроены в сервер платформы услуг с сервис-ориентированной архитектурой посредством стандартного протокола HTTP, а также асинхронной шины 730 связи в режиме реального времени. Эти веб-услуги осуществляют вызов данных и затем их отображение для пользователя.

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

Правила

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

В одном из вариантов осуществления правила представляют собой базовые стандартные блоки SPM. Существуют правила двух типов: простые правила и сложные правила. На фиг.8 показана блок-схема 800, иллюстрирующая простое правило 810 и сложное правило 850. Простое правило 810 может содержать целевой объект 812, условие 814 и действие 816. В одном из вариантов осуществления создают простое утверждение, чтобы инициировать действия 816 одного или нескольких типов (например, передачу оповещения, активизацию сценария или сервиса или регистрацию события). Сложное правило 850 может содержать целевой объект 852, несколько условий 854, 856, 858 и действие 860. В одном из вариантов осуществления сложное правило 850 включает логическую функцию ИЛИ. Сложное правило 850 может инициировать несколько действий 860. В одном из вариантов осуществления задают условие 814, 854, 856, 858, исходя из показателей по умолчанию, доступных для выбранного целевого объекта.

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

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

Шаг 920 выбора целевого объекта может включать выбор одного целевого объекта 922 или группы целевых объектов 924. Группа целевых объектов 924 может быть сформирована из объектов одного и того же типа или объектов, имеющих общий критерий. Целевыми объектами 922, 924 могут являться устройства, узлы, узлы услуг, инстанции или операции услуг. В одном из вариантов осуществления целевые объекты выбирают, исходя из инфраструктуры или развертывания среды или области TIB СО ActiveMatrix®. В одном из вариантов осуществления устанавливают датчик услуг TIBCO BusinessWorks™, а в качестве целевых объектов могут быть выбраны услуги и процессы BusinessWorks™.

В зависимости от выбранного целевого объекта становятся доступными соответствующие показатели для создания условия 930. Условием может являться простое условие 932 или сложное условие 934.

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

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

Наборы правил

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