Говорят специалисты по BPM: Иоахим Франк: За кулисами обработки событий в WebSphere Business Monitor

Вы хотели бы узнать, как происходит обработка событий в продукте WebSphere® Business Monitor? Вы не понимаете, что такое выражения фильтров, предикаты корреляции и контексты мониторинга, и не знаете, как эти концепции взаимодействуют между собой, чтобы гарантировать обновление нужных показателей на основе информации о соответствующих событиях и тем самым обеспечить быструю реакцию вашего бизнеса? В этой статье Иоахим Франк приоткрывает занавес и показывает, что происходит за сценой и как все эти компоненты функционируют, обеспечивая вашему бизнесу получение необходимой информации – в нужном месте и в нужное время. Из журнала IBM Business Process Management Journal.

Франк Иоахим, старший архитектор по программному обеспечению, IBM

Иоахим Франк (Joachim H. Frank) является старшим архитектором по программному обеспечению в корпорации IBM. Он осуществляет техническое руководство проектированием и разработкой продуктов WebSphere Business Modeler и WebSphere Business Monitor. Адрес электронной почты: jhfrank@us.ibm.com.



03.10.2011

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

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

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

Концепции обработки событий

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

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

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

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

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

Теперь, когда вы понимаете базовые концепции и термины, посмотрим, как это все работает.


Пошаговая обработка событий

Обработка событий состоит из следующих трех шагов.

  1. Фильтрация – определение типа события
  2. Коррелирование – выявление контекста мониторинга, интересующегося этим событием
  3. Обновление контекста мониторинга – выявление показателей, обновляемых данным событием, и определение порядка этого обновления

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

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

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

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

В нашем примере с компанией по автомобильным перевозкам пассажиров, если автомобили всегда отчитываются о состоянии поездки посредством события, полезная нагрузка которого имеет тип limo:TripStatus (где limo представляет пространство имен), а события планирования, посадки и высадки различаются по полю event nature, то для установления типа поступившего события нужно проверить поле event nature вместе с атрибутом xsi:type.

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

Но что делать если этого окажется недостаточно? К примеру, для поступившего события «посадка пассажиров» не найдено никакого соответствующего контекста мониторинга. В этом случае вы можете не создавать новый контекст мониторинга, а вместо этого инициировать сбойную ситуацию, заключающуюся в том, что еще не было получено события «автомобиль отправлен» (которое должен было бы произойти первым и создать соответствующий контекст мониторинга). Аналогично, если событие «автомобиль отправлен» поступило и для этой поездки уже найден контекст мониторинга, то этот результат является непредвиденным и указывает на наличие сбоя. Как и в предыдущем примере, вам следует инициировать сбойную ситуацию, а не направлять дублирующееся событие отправки в уже существующий контекст мониторинга.

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

Параметры доставки событий
Нулевое число совпаденийОдно совпадениеНесколько совпадений
Игнорировать Игнорировать Игнорировать
Рассматривать как ошибку Рассматривать как ошибку Рассматривать как ошибку
Создать новый контекст мониторинга Доставить соответствующему контексту мониторинга (единственному) Доставить любому соответствующему контексту мониторинга
Откатить все изменения и позднее повторить попытку обработки этого события Доставить всем соответствующим контекстам мониторинга

После того как корреляционная обработка идентифицировала контекст мониторинга для доставки события, его состояние обновляется на основе содержания этого события.

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

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


Рассмотрите слайд-шоу

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


Заключение

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


Загрузка

ОписаниеИмяРазмер
Демонстрационное слайд-шоуepdemo.pdf299 KБ

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, SOA и web-сервисы
ArticleID=762911
ArticleTitle=Говорят специалисты по BPM: Иоахим Франк: За кулисами обработки событий в WebSphere Business Monitor
publish-date=10032011