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

Формула изобретения

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

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

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

анализируют в компьютерном процессоре по меньшей мере одно наблюдаемое событие,

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

устраняют последствия ответа на первое прогнозируемое поведение исходя из второго прогнозируемого поведения.

2. Способ по п.1, в котором дополнительно:

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

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

4. Способ по п.1, в котором дополнительно:

устанавливают по меньшей мере одно правило и создают график действия по меньшей мере одного правила в запланированное время.

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

6. Способ по п.4, в котором дополнительно выбирают по меньшей мере один целевой объект для применения к нему по меньшей мере одного правила.

7. Способ по п.6, в котором дополнительно задают по меньшей мере одно условие для показателя, доступного по меньшей мере для одного целевого объекта.

8. Способ по п.7, в котором дополнительно:

задают по меньшей мере одно действие и

связывают по меньшей мере одно действие по меньшей мере с одним правилом или по меньшей мере одним условием.

9. Способ по п.1, в котором дополнительно передают посредством сетевого интерфейса по меньшей мере одно оповещение от компьютерного процессора на дисплей.

10. Способ по п.1, в котором дополнительно выполняют по меньшей мере одно действие.

11. Способ по п.1, в котором по меньшей мере один сервис представляет собой групповой сервис.

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

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

14. Диспетчерская система управления состоянием предоставляемых услуг для управления системой с сервис-ориентированной архитектурой, содержащая:

по меньшей мере одну коммуникационную шину,

один или несколько запоминающих элементов,

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

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

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

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

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

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

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

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

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

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

20. Диспетчерская система управления состоянием предоставляемых услуг по п.19. в которой модуль установления правила дополнительно способен выбирать по меньшей мере один целевой объект для применения к нему по меньшей мере одного правила.

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

22. Диспетчерская система управления состоянием предоставляемых услуг по п.21. в которой модуль установления правила дополнительно способен задавать по меньшей мере одно действие и связывать по меньшей мере одно действие по меньшей мере с одним правилом или по меньшей мере одним условием.

Описание изобретения к патенту

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

Приоритет настоящей патентной заявки основан на родственной предварительной патентной заявке 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 правил, в который входит техническое требование 1010, содержащее правила А, В, С, D с целевыми объектами А, В, С, D, условиями А, В, С, D, и действиями А, В, С, D соответственно.

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

На фиг.11 показана схема, иллюстрирующая организацию совокупности правил в один из примеров набора 1110 правил. В одном из вариантов осуществления набором правил является цифровое представление SLA. Набор правил может быть простым и состоять из одного правила или сложным и состоять из сотен правил, сгруппированных на основании общих технических требований. Набор 1110 правил содержит одно или несколько технических требований 1120, а техническое требование содержит одно или несколько правил 1130. Технические требования могут создаваться при создании нового набора правил. Поскольку наборы правил содержат стандартный график 1112 технических требований, для любых технических требований, создаваемых без графика, используется стандартный график. В одном из вариантов осуществления для стандартного графика 1112 задан режим "Всегда", поэтому график применяется всегда. В наборах 1110 правил также могут быть заданы общие метаданные 1118 для технических требований 1120, содержащихся в наборах правил. В наборах 1110 правил предусмотрена возможность идентификации сторон поставщика услуг и клиента в SLA 1114, а также необязательной идентификации представляемого набором правил уровня обслуживания (роли) 1116, то есть поля сторон и ролей являются необязательными. В одном из вариантов осуществления для осуществления доступа к набору правил пользователь должен выбрать набор правил из перспективы построения и конфигурирования. Эталонные целевые объекты

Эталонным целевым объектом является целевой объект, указанный в одном или нескольких правилах. Условия, заданные в правиле, сверяют с выбранными целевыми объектами. Если условие нарушено, приводится в действие правило с целью передачи оповещения. Если правило связано с действием, при осуществлении действия предпринимаются корректирующие меры в попытке привести характеристики в соответствие с заданным условием. На фиг.12 показан перечень типов эталонных целевых объектов 1200. Типы эталонных целевых объектов могут включать объекты 1210 типа услуги, объекты 1220 типа инстанции услуги, объекты 1230 типа операции услуги, объекты 1240 типа инстанции операции услуги, объекты типа среды или области, объекты 1260 типа устройства и объекты 1250 типа узла или механизма. В одном из вариантов осуществления объекты 1210 типа услуги, объекты 1220 типа инстанции услуги, объекты 1230 типа операции услуги, объекты 1240 типа инстанции операции услуги и объекты типа среды или области могут включать услуги TIBCO ActiveMatrix® или TIBCO BusinessWorks , инстанции услуг, операции услуг или процессы услуг, операционные инстанции услуг или инстанции процесса и среды или области. Объекты 1260 типа устройства могут включать устройство, в котором действует TIBCO ActiveMatrix® или TIBCO BusinessWorks . Объекты 1250 типа узла или механизма могут включать узел ТIBСО ActiveMatrix® или механизм TIBCO BusinessWorks . Как индивидуальные пользователи, так и привилегированные пользователи могут осуществлять доступ к библиотеке эталонных целевых объектов с целью просмотра, удаления или повторного выбора эталонных целевых объектов.

Графики

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

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

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

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

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

Индивидуальные действия

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

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

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

Условные SLA

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

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

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

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

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

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

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

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

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

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

После того как на шаге 1320 и/или 1330 идентифицированы возможные нарушения, сервис-ориентированная архитектура выполняет шаг 1340 "оценки устранения последствий". В зависимости от идентифицированных нарушений может быть предпринято любое из нескольких действий, проиллюстрированных шагами 1350, 1360 и 1370. Показано, что на этих шагах могут быть предприняты соответствующие действия для устранения нарушений путем добавления дополнительных ресурсов, назначения различных ресурсов или иного повторного выделения ресурсов (на шаге 1350); оповещения клиента о проблеме, чтобы клиент мог повторно дать задание, заново сформулировать задание, поручить задание другому поставщику услуг или предпринять какое-либо иное действие (на шаге 1360); или ограничения или прекращения работы клиента (или, в частности, агентского процесса/демона), использующего клиентский компьютер (на шаге 1370).

На фиг.14 показана блок-схема, иллюстрирующая систему 1400 для реализации одного из вариантов осуществления SPM. В одном из вариантов осуществления компьютер 1410 SPM, в котором реализованы функции SPM, имеет шину или другое средство связи для обмена информацией между компонентами компьютера 1410 SPM. Компьютер 1410 SPM может дополнительно включать процессор, связанный с шиной и запоминающим элементом, например оперативным запоминающим устройством (ОЗУ) или другим динамическим запоминающим устройством, также связанным с шиной. В запоминающем элементе хранятся команды, выполняемые процессором. В запоминающем элементе также могут храниться временные переменные. Компьютер 1410 SPM может иметь связанное с шиной массовое запоминающее устройство для хранения информации, доступ к которой не осуществляется так же регулярно, как к информации, хранящейся в запоминающем элементе. Компьютер 1410 SPM также может иметь устройство связи. Если в компьютере 1410 SPM реализуется одна часть одного из вариантов осуществления системы, устройство связи позволяет компьютеру 1410 SPM поддерживать связь с другими частями системы, включая все услуги. Компьютером 1410 SPM может являться один компьютер SPM или множество компьютеров SPM.

На базе процессора компьютера 1410 SPM действуют модули системы SPM. Правила и результаты измерений могут храниться в базах 1420, 1430 данных с возможностью доступа к ним компьютера 1410 SPM и их реализации или использования модулями системы SPM. Компьютер 1410 SPM обменивается данными по сети 1450 с одним или несколькими компьютерами 1460 приложений с SOA. В компьютерах 1460 приложений с SOA расположены датчики 1465 SPM, способные контролировать данные, относящиеся к платформам с SOA. В одном из вариантов осуществления датчики непосредственно внедрены в инфраструктуру контейнера. Данные, собираемые датчиками 1465, по сети 1450 могут передаваться компьютеру 1410 SPM, обеспечивающему системные услуги SPM. Результаты измерений и правила могут храниться в базах 1420, 1430 данных с возможностью доступа к ним компьютера 1410 SPM. Результаты измерений и показатели по сети 1440 могут передаваться компьютеру 1470 для визуального отображения. В одном из вариантов осуществления компьютер 1470 для визуального отображения может 1470 представлять собой приборную панель для отображения результатов измерений и показателей на дисплее 1480. В одном из вариантов осуществления компьютер 1410 SPM может передавать по сети 1440 команду записи обновлений компьютера 1470 для визуального отображения и дисплея.

Компьютер 1410 SPM по сети 1450 принимает результаты 1490 измерений от датчиков 1465 системы и по сети передает компьютерам 1460 приложений с SOA гарантии 1495.

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

Помимо этого, содержащиеся в описании заголовки разделов приведены в соответствии с рекомендациями статьи 1.77 Раздела 37 Свода федеральных нормативных актов США или для облегчения поиска информации. Эти заголовки не ограничивают и не описывают изобретение(-я), заявленное в каком-либо из пунктов формулы изобретения, который может вытекать из раскрытия. В частности и в качестве примера, хотя в описании содержится раздел под заголовком "Область техники, к которой относится изобретение", формула изобретения не должна быть ограничена содержанием этого раздела, в котором описана так называемая область техники. Кроме того, описание технологии в разделе "Предпосылки создания изобретения" не должно считаться признанием того, что определенная технология является прототипом какого-либо изобретения, раскрытого в настоящем описании. Раздел "Краткое изложение сущности изобретения" также не должен рассматриваться в качестве описания изобретения(-й), заявленного в формуле изобретения. Помимо этого, любое упоминание в настоящем описании "изобретения" в единственном числе не должно использоваться для доказательства того, что в настоящем описании раскрыт лишь один обладающий новизной объект. В объем множества пунктов формулы изобретения, вытекающих из настоящего описания, может входить множество изобретений, и, соответственно, в таких пунктах формулы изобретения заявлены охраняемые ими изобретение(-я) и его эквиваленты. Во всех случаях объем таких пунктов формулы изобретения рассматривается согласно их существу в свете настоящего описания и не должен быть ограничен приведенными в описании заголовками разделов.