Концептуальная модель для систем обработки событий

В данной статье представляется концептуальная модель обработки событий. Она рассматривается в терминах лежащей в ее основе сети обработки событий (Event Processing Network) и ассоциированной с ней концептуальной архитектуры для обработки событий (Conceptual Architecture for Event Processing). Это обеспечивает концептуальный взгляд на архитектуру обработки событий и на ключевые компоненты, необходимые для создания эффективных систем обработки событий.

Майк Эдвардс, разработчик стратегии, IBM

Майк Эдвардс (Mike Edwards) –разработчик стратегии в подразделении Emerging Technologies в лаборатории IBM в Херсли, Великобритания. Он является также сопредседателем технического комитета OASIS SCA Assembly и участником проекта Apache Tuscany. Также участвует в написании спецификаций для проекта European PEPPOL.



Офер Этцион, старший инженер, научный руководитель по обработке событий, IBM

Офер Этцион (Opher Etzion) – старший инженер и главный разработчик. Он также является научным руководителем системы обработки событий в IBM Research Lab в Хайфе и председателем руководящего комитета Event Process Technical Society (EPTS).



Мамду Ибрагим, инженер, IBM

Мамду Ибрагим (Mamdouh Ibrahim) – почетный инженер IBM и главный технический директор направления Enterprise Architecture and Technology. В его обязанности входит разработка активов EA и SOA, экспертная оценка архитектуры и консультирование клиентов. Доктор Ибрагим имеет степени бакалавра по электротехнике и математике, степени магистра по математике, физике твердого тела и вычислительной технике, а также степень доктора философии по вычислительной технике. Член IEEE, ACM и адъюнкт-профессор в университете Central Michigan.



Хуберт Лалане, инженер, IBM

Хуберт Лалане (Hubert Lalanne) – почетный инженер IBM, разработчик подразделения Software Information Technology Architect (SWITA), расположенного во Франции. Также является членом всемирного совета технических руководителей IBM Software Group и совета технических экспертов IBM по Франции и северо-западной Африке.



Кэтрин Мокси, старший инженер CICS Transaction Server for z/OS, IBM

Кэтрин Мокси (Catherine Moxey) – старший инженер группы CICS Transaction Server for z/OS в лаборатории IBM в Херсли, Великобритания и разработчик поддержки обработки событий в CICS. Она является членом Event Processing Technical Society и активно участвует в рабочей группе по эталонной архитектуре.



Марк Петерс, старший разработчик, IBM

Марк Петерс (Marc Peters) - старший разработчик программного обеспечения для энергетического и коммунального сектора в Кельне, Германия. Руководит проектами в области SOA, обработки событий и IoD, связанными с бизнес-требованиями в отрасли энергетики. Марк имеет более чем семнадцатилетний опыт работы в международных проектах. Часто выступает докладчиком внутри компании и у клиентов.



Юрий Рабинович, исследователь, IBM

Юрий Рабинович (Yuri Rabinovich) работает исследователем в группе Event-based Middleware and Solutions в исследовательской лаборатории IBM в Хайфе, Израиль. Получил степень магистра наук по управлению информационными системами в Технионе. Поступил в лабораторию IBM в Хайфе в 2006 году и сконцентрировался на разработке механизма правил сложной обработки событий AMiT (Active Middleware Technology). Руководил проектами по масштабируемой и распределенной обработке событий и разрабатывал новые методики повышения производительности обработки событий для механизма WebSphere Business Events.



Гай Шарон, руководитель Event Based Middleware, IBM

Гай Шарон (Guy Sharon) руководит группой Event-based Middleware and Solutions в исследовательской лаборатории IBM в Хайфе, Израиль. Получил степень магистра наук по управлению информационными системами в Технионе. Защитил диссертацию по концептуальной модели сетей обработки событий. Поступил в лабораторию IBM в Хайфе в 2000 году, был членом группы исследований и разработки механизма правил сложной обработки событий AMIT (Active Middleware Technology)



Кристиан Стюарт, разработчик Tivoli Software, IBM

Кристиан Стюарт (Kristian Stewart) – разработчик архитектуры Tivoli Network Availability Management.



29.03.2012

Введение

Предприятия разных отраслей в своей деятельности всегда руководствуются событиями и имеют дело с постоянно растущим объемом бизнес-событий и транзакций. Обработка событий (Event Processing – EP) – это новое направление, возникшее главным образом в ответ на возросшую потребность в быстром реагировании на большие объемы информационных и бизнес-событий. Она учитывает необходимость поддержки цикла принятия решений путем более эффективной обработки событий корпоративной значимости и становится важнейшей частью корпоративных стратегий для сервис-ориентированных архитектур (Service Oriented Architecture – SOA).

В данной статье сначала обсуждается необходимость обработки событий, различные ее виды и значение внедрения обработки событий для предприятий. Затем подробно рассматривается модель обработки событий, которую можно использовать для внедрения управляемой событиями архитектуры (Event Driven Architecture – EDA). Эти концепции затем подробно разбираются в ходе обсуждения трех бизнес-сценариев, реализующих обработку событий для улучшения процесса принятия решений.


Обзор обработки событий

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

Рисунок 1. Обзор обработки события
Рисунок 1. Обзор обработки события

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

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


Концептуальные основы

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

Типы обработки событий

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

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

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

Обработка бизнес-событий

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

Рисунок 2. Обработка бизнес-событий: добавляет бизнес-перспективу к возможностям обработки событий
Рисунок 2. Обработка бизнес-событий: добавляет бизнес-перспективу к возможностям обработки событий

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

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

Значение обработки событий

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

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

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

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

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

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


Обзор сценариев обработки событий

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

  • Сценарий управления автотранспортным парком (Fleet Management).
  • Сценарий системы уведомления в здравоохранении (Public Health Alert).
  • Сценарий поставщика коммуникационных услуг (Communication Service Provider).

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

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

Сценарий управления автотранспортным парком

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

Рисунок 3. Обзор сценария управления автотранспортным парком
Рисунок 3. Обзор сценария управления автотранспортным парком

Идеи данного сценария основаны на решениях IBM по оптимизации автотранспортного парка. Вот некоторые цели, которые преследуют менеджеры автопарков в управлении и ведении бизнеса:

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

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

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

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

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

В выбранном сценарии рассматриваются вспышки птичьего гриппа (Bird Flu) и птичьего гриппа А (H5N1), хотя его также можно применить и к другим разновидностям заболевания, например, H1N1.

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

Рисунок 4. Обзор сценария системы уведомления в здравоохранении
Рисунок 4. Обзор сценария системы уведомления в здравоохранении

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

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

Сценарий поставщика коммуникационных услуг

Данный сценарий описывает вымышленную компанию-поставщика коммуникационных услуг (CSP). Компания предлагает разнообразные услуги проводной связи домашним пользователям и фирмам малого и среднего размера, от широкополосного доступа в Интернет до VOIP и VPN (Virtual Private Network). Базовая сеть MPLS (Multiprotocol Label Switching) компании состоит из компонентов от многих различных производителей, поддерживаемых набором систем управления компонентами (Element Management System). Компания применяет для подключения клиентов различные сетевые технологии, включая коммутируемый доступ, DSL и технологии, поддерживающие VPN уровней 2 и 3.

В зависимости от пакета услуг, приобретенного клиентом, компания предлагает различные соглашения об уровне сервиса (Service Level Agreement – SLA). Эти SLA содержат контракты, гарантирующие согласованные уровни сервиса в соответствии с указанными параметрами, такими, например, как непрерывность сервиса или доступная пропускная способность сети. Несоблюдение SLA может привести к финансовым потерям для компании и повредить ее репутации. Клиенты компании распределены по категориям в соответствии с их согласованными уровнями сервиса.

Данная компания, как и все CSP, имеет центр сетевого управления (Network Operations Centre), состоящий из сотрудников, аппаратного и программного обеспечения, предназначенных для обеспечения непрерывной работы базовой сети компании и предоставляемых ею сервисов. Их целью является:

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

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

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

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

  • Выполнять мониторинг жизнеспособности, доступности и производительности компонентов, составляющих базовую сеть.
  • Нормализовать сетевые события в общий формат для единообразной визуализации и обработки.
  • Предоставлять операторам центра сетевого управления актуальные интерактивные отчеты о событиях, произошедших в сети.
  • Автоматически обнаруживать и поддерживать актуальные модели базовой сети для:
    • поддержки видимости развернутых активов;
    • поддержки моделей физической и логической сетевой топологии и их взаимоотношения с предоставляемыми сетевыми сервисами;
    • предоставления информационных панелей карты сети оперативному персоналу для диагностирования проблем и устранения неисправностей;
    • выполнения основанного на сетевой топологии анализа первопричин сетевых событий и простоев сервисов;
    • поддержки предоставления процессов для новых сервисов.
  • Автоматически реагировать, диагностировать и исправлять большое количество сценариев сетевых аварий.
  • Выполнять анализ шаблонов событий и делать заключения об их причинах и воздействии на бизнес.
  • Пополнять сетевые события информацией на основе технического, топологического и бизнес-контекста.
  • Определять стратегии автоматического создания в приложении службы поддержки заявок на устранение неисправности (trouble ticket), приводящих к физическим действиям по обслуживанию.

Наша вымышленная CSP-компания имеет контракт с компанией среднего размера по обеспечению VPN-сервисов между ее распределенными филиалами. Контракт предусматривает высокий уровень готовности, установленный соответствующим SLA. CSP предоставляет (и обслуживает) выделенные клиентские маршрутизаторы (CE), расположенные в каждом помещении этой компании среднего размера, для соединения с базовой сетью CPS. Каждый CE подключен к провайдерскому маршрутизатору (PE), расположенному на территории CSP.

При возникновении неисправности в маршрутизаторе PE (например, при отказе сетевого интерфейса) система обработки событий будет получать много событий, указывающих на физические и логические ошибки, от оборудования и систем управления в окружающей сети, включая таймауты проверки связи ICMP (Internet Control Message Protocol), уведомления об отсутствии связи, нарушения связности протокола маршрутизации. В такой ситуации система обработки событий должна:

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

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


Концептуальная модель

Наша концептуальная модель представляет два различных взгляда на системы обработки событий, предназначенные для описания важных концепций и их взаимоотношений на абстрактном уровне с отвлечением от всех технических подробностей. Сеть обработки событий (Event Processing Network – EPN) абстрагирует важные функциональные возможности компонентов ввода, обработки и вывода системы обработки событий. Руководствуясь концепциями EPN, наша концептуальная архитектура (Conceptual Architecture) идентифицирует абстрактные архитектурные элементы, или компоненты, которые могут быть вовлечены в реализацию системы обработки событий и во взаимоотношения между ними для обеспечения бизнес-ценности. Этот абстрактный уровень не зависит от технологий, протоколов и продуктов, которые могли бы использоваться для реализации компонентов.

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

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


Сеть обработки событий

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

Рисунок 5. Сеть обработки событий
Рисунок 5. Сеть обработки событий

EPN состоит из четырех компонентов: производитель событий, потребитель событий, агент обработки событий (обозначен сокращенно как EPA – event processing agent) и компонент соединения, называемый каналом событий (event channel). EPN описывает, как события, принимаемые от производителей, направляются потребителям через агентов, обрабатывающих эти события, - например, путем выполнения преобразований, проверки корректности или пополнения информацией. Любое событие, приходящее от одного компонента к другому, должно проходить по каналу событий в соответствии с рисунком 5, на котором показано взаимоотношение между каналами событий, потребителями, производителями и агентами обработки. Каналы событий соединяют производителей событий с EPA внутри EPN, разные EPA между собой, если это необходимо, и EPA с потребителями, что в результате обеспечивает прохождение событий от производителей событий через EPN к потребителям событий. Этот рисунок также демонстрирует, что различные события, генерируемые производителями событий в EPN, могут обрабатываться соответствующими группами EPA, соединенными посредством каналов, для дальнейшего направления этих событий (или порожденных из них) различным потребителям событий в EPN.

Канал событий

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

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

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

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

Производитель и потребитель событий

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

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

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

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

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

Агент обработки событий

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

EPA может иметь три состояния:

  • Сопоставление с шаблоном. Данное состояние, если оно необходимо, отвечает за выбор событий для обработки согласно указанному шаблону. EPA, выполняющий сопоставление с шаблоном, называется "EPA обнаружения шаблонов" ("pattern detection EPA").
  • Обработка. Данное состояние, если оно предусмотрено, отвечает за применение функций обработки к выбранным событиям, удовлетворяющим шаблону, что приводит к порождению событий.
  • Распространение. Данное состояние отвечает за распространение событий или порожденных событий в канал.

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

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


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

Давайте отобразим определения и компоненты сети обработки событий на сценарии, описанные в разделе "Введение".

Сценарий управления автопарком

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

Таблица 1. Производители событий
Производитель событийОписание
Транспортное средствоGPS-координаты, установленные датчики (топливо, расход, вес и т.д.).
Система отчетности водителейЭлектронный маршрутный лист.
Система доставкиУправление заказами, сортировка и распределение товаров, система диспетчеризации транспортных средств.
RFID-система отслеживания товаровСистема отслеживания товаров со считывателями в центрах погрузки или с мобильными считывателями для персонала (например, используются водителями при сборе, передаче и доставке товаров).
Таблица 2. Потребители событий
Потребитель событийОписание
Дисплей водителяБортовой и мобильный дисплей водителя для отображения маршрутов, изменений в доставке и уведомлений.
Информационная панель управления доставкойПолный обзор операций – местоположение транспортного средства, маршруты, заказы, товары и т.д.
КлиентыОтправители и получатели заказов могут принимать уведомления и искать свои заказы.
Таблица 3. Типы событий
Идентификатор событияТип событияАтрибутыКомментарии
E1Водитель начинает работуОтметка времени; идентификатор водителя-
E2Водитель начинает работу (расширенное)Отметка времени; идентификатор водителя; идентификатор транспортного средства; фамилия водителя-
E3Водитель завершает работуОтметка времени; идентификатор водителяМожет быть основано на структуре E1.
E4Время вождения превышеноОтметка времени; идентификатор водителя; идентификатор транспортного средства; фамилия водителя-
E5Изменение доставкиОтметка времени; идентификатор водителя 1; идентификатор транспортного средства 1; идентификатор водителя 2; идентификатор транспортного средства 2; идентификатор отправителя; идентификатор получателя-
Таблица 4. Каналы событий
Идентификатор канала событийТип событияПроизводителиПотребителиСтратегия сохранения
EC1E1 Система отчетности водителейA1 -
EC2E2A1A2-
EC3E3Система отчетности водителейA2-
EC4E4A2A3, информационная панель управления доставкой-
EC5E5A3A4-
EC6E5A4Клиенты, дисплей водителя, информационная панель управления доставкой1 неделя
Таблица 5. Агенты обработки событий, пример 1
Свойство агентаХарактеристика
Идентификатор агентаA1
Имя агентаEnrich Driver Starts Working (пополнение информацией события начала работы водителя)
Тип агентаОбогащение
Контекст агента-
Входные события E1
Спецификация агентаПополнить событие с указанным идентификатором водителя информацией об идентификаторе транспортного средства и фамилии водителя из таблицы с подробной информацией о водителе.
Выходные событияE2
КомментарийПополняет событие информацией о водителе.
Таблица 6. Агенты обработки событий, пример 2
Свойство агентаХарактеристика
Идентификатор агентаA2
Имя агентаDriver Exceeded Driving Time (превышение времени вождения водителем)
Тип агента Обнаружение шаблона
Контекст агентаинтервал (E2,+8ч) по идентификатору водителя
Входные событияE3
Спецификация агентаОтсутствие E3
Выходные события-
Таблица 7. Агенты обработки событий, пример 3
Свойство агентаХарактеристика
Идентификатор агентаA3
Имя агентаDelivery Reallocation (перераспределение доставки)
Тип агентаОбнаружение шаблона
Контекст агента-
Входные событияE4, Ex
Спецификация агентаПополнить событие с указанным идентификатором водителя информацией об идентификаторе транспортного средства и фамилии водителя из таблицы с подробной информацией о водителе.
Выходные событияE5
КомментарийЭтот агент получает различные типы событий для обнаружения необходимости изменения доставки. Агент ответственен за принятие решения о том, какое транспортное средство принимает на себя функции доставки и как организовать встречу двух транспортных средств в логистическом центре или в другом месте.
Таблица 8. Агенты обработки событий, пример 4
Свойство агентаХарактеристика
Идентификатор агентаA4
Имя агентаRoute Reallocation Notification to required consumers (маршрутизация уведомления о перераспределении соответствующим клиентам)
Тип агентаМаршрутизатор
Контекст агента-
Входные событияE5
Спецификация агента-
Выходные событияE5
КомментарийНаправляет информацию об изменении доставки различным клиентам. Возможно направление уведомлений клиентам (срок действия - неделя), отправка новых инструкций водителям и контроль исполнения новых инструкций диспетчерской службой.

На рисунке 6 схематически показаны компоненты этой EPN. Система отчетности водителей генерирует событие E1 и публикует его в канал EC1, когда водитель начинает работу. Агент обработки события A1 пополняет событие E1 информацией и генерирует порожденное событие E2. По истечении 8 часов агент A2 генерирует событие E4, так как водитель превышает выделенное ему до конца смены время. Событие E4 принимается информационной панелью управления доставкой для контроля. Агент A3 принимает это событие через канал EC4 и перераспределяет заказы водителя другим водителям для своевременной доставки, но без превышения времени работы другими водителями. Уведомление о перераспределении происходит посредством события E5, которое агент A4 направляет различным потребителям, нуждающимся в уведомлении – водителю, превысившему время работы, водителю или водителям, которые должны принять и доставить свои заказы, клиентам, которые должны знать об изменениях маршрута доставки и предполагаемом времени доставки, и, наконец, информационной панели управления доставкой для контроля. Только после передачи водителем своих товаров другим водителям его смена заканчивается и генерируется событие E3 (это событие не влияет на описанных агентов).

Рисунок 6. Графическое представление EPN для сценария управления автотранспортным парком
Рисунок 6. Графическое представление EPN для сценария управления автотранспортным парком

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

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

Таблица 9. Производители событий
Производитель событийОписание
БольницаБольница может обнаружить возможные вирусы или симптомы и сгенерировать событие.
ЛабораторияЛаборатория может обнаружить возможные вирусы или симптомы и сгенерировать событие.
ВрачВрач может обнаружить возможные симптомы и сгенерировать событие.
Иностранное правительственное учреждениеИностранное правительственное учреждение генерирует событие.
Таблица 10. Потребители событий
Потребитель событий Описание
Фармацевтическая компанияФармацевтическая компания подписывается на получение уведомлений системы здравоохранения.
Правительственное учреждение Правительственное учреждение подписывается на получение уведомлений системы здравоохранения.
Практикующий врачПрактикующий врач подписывается на получение уведомлений системы здравоохранения, возможно, пополненных более подробной информацией о характеристиках и методах обнаружения.
Медицинская страховая компанияМедицинская страховая компания подписывается на получение уведомлений системы здравоохранения.
Новостное агентство Новостное агентство подписывается на получение уведомлений о состоянии здоровья.
Ведомство национальной безопасностиВедомство национальной безопасности подписывается на получение уведомлений системы здравоохранения, возможно, пополненных специальной предупреждающей информацией и методами обнаружения.

Имеется также концепция "системы-посредника", которая реализует сеть обработки событий (EPN) и обеспечивает развязывание производителей событий (которые не знают ни о том, кто будет потреблять событие, ни о том, что с ним будет происходить) и потребителей событий (которые не знают источника исходного события, его первоначальный вид и смысл).

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

Таблица 11. Типы событий
Идентификатор событияТип событияАтрибутыКомментарии
E1Potential Epidemic Outbreak Alert (уведомление о потенциальной вспышке эпидемии)Идентификатор; подробностиПротивоположным событием является No Potential Epidemic Outbreak (отсутствие потенциальной вспышки эпидемии).
E2Potential Epidemic Outbreak normalized (потенциальная вспышка эпидемии, нормализованное)Идентификатор; метка времени; месторасположение; подробностиНормализованное / преобразованное из оригинального событие.
E3Potential Epidemic Outbreak enriched (потенциальная вспышка эпидемии, пополненное)Идентификатор; метка времени; месторасположение; дополнительные подробностиПополненное информацией событие.
E4Epidemic Outbreak Detected Alert (уведомление об обнаружении вспышки эпидемии)Идентификатор; метка времени; месторасположение; подробностиОбнаружена вспышка эпидемии (обнаружение шаблона событий).
E5Epidemic Outbreak Alert (уведомление о вспышке эпидемии)Идентификатор; метка времени; месторасположение; подробности-
E6Potential Pandemic Outbreak Alert (уведомление о потенциальной вспышке пандемии)Идентификатор; метка времени; месторасположение; подробности-
E7Potential Pandemic Outbreak normalized (потенциальная вспышка пандемии, нормализованное)Идентификатор; метка времени; месторасположение; подробностиОбнаружена вспышка пандемии (обнаружение шаблона событий).
E8Potential Pandemic Outbreak enriched (потенциальная вспышка пандемии, пополненное)Идентификатор; метка времени; месторасположение; дополнительные подробностиПополненное информацией событие.
E9Pandemic Outbreak Detected Alert (уведомление об обнаружении вспышки пандемии)Идентификатор; метка времени; месторасположение; подробностиОбнаружена вспышка пандемии (обнаружение шаблона событий).
E10Pandemic Outbreak Alert (уведомление о вспышке пандемии)Идентификатор; метка времени; месторасположение; подробности.-

На рисунке 7 приведено графическое представление этой EPN.

Рисунок 7. EPN для сценария системы уведомления в здравоохранении
Рисунок 7. EPN для сценария системы уведомления в здравоохранении

Сценарий поставщика телекоммуникационных услуг

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

Таблица 12. Производители событий
Производитель событийОписание
Монитор сетиПрограммное обеспечение, опрашивающее сетевое оборудование для проверки его доступности и производительности, с использованием обычно таких протоколов, как ICMP и SNMP. Генерирует события, информирующие о важных изменениях в компонентах сети и нарушениях нормального функционирования.
Датчики компонентов сетиПринимает уведомления от компонентов сети и генерирует события, информирующие о важных изменениях и авариях в компонентах сети и в их физических и логических соседях. Для прослушивания уведомлений обычно используются такие протоколы, как SNMP.
Датчик систем управления компонентамиПринимает уведомления из систем управления компонентами (Element Management System), информирующие о неисправностях и важных изменениях в контролируемых компонентах сети. Может использовать стандартные или фирменные форматы событий по стандартным или фирменным протоколам, включая SNMP, SOAP, CORBA, бесструктурные файлы (flat file).
Информационная панель оператора событийГенерирует события на основе действий оператора, включая подтверждение, разрешение и очистку событий от сетевого оборудования и простоев сервисов.
Таблица 13. Потребители событий
Потребитель событийОписание
Информационные панели оператораИнтерактивное представление важных событий операторам центра сетевого управления (Network Operations Centre), включая настраиваемые средства диагностики и возможности фильтрации.
Телефоны сетевых инженеров и система электронной почтыПолучатели SMS-сообщений и электронных писем о критических событиях, возникающих в системе.
Представления для клиентовАктуальные представления обнаруженных простоев сервисов, отфильтрованные для конкретных клиентов, с доступом только по чтению.
Система заявок на устранение неисправностейПринимает события от системы, которые требуют вмешательства инженерного или обслуживающего персонала.
Таблица 14. Типы событий
Идентификатор Тип события Атрибуты Комментарии
E1Ping failed (сбой проверки доступности)Метка времени; недоступный адрес-
E2Link Down (нерабочий канал)Метка времени; имя порта нерабочего канала в PE-маршрутизаторе; адрес PE-маршрутизатора-
E3Card Failure (неисправность интерфейса)Метка времени; адрес PE-маршрутизатора; идентификатор интерфейса-
E4Root cause event (первопричина события)Как E3Копия E3, идентифицированного как первопричина.
E5Symptom events (события-симптомы)Как E1 и E2; ассоциированная первопричинаКопии E1 и E2, идентифицированные как симптомы.
E6VPN service affected (затронутый VPN-сервис)Метка времени; идентификатор VPN-
E7VPN service affected enriched (затронутый VPN-сервис, пополненный)Как E6; подробная информация о контактах с клиентом-
E8Technician dispatched (выбранный инженер)Метка времени; подробная информация о контактах с техником-
E9Ping success (удачная проверка доступности)Метка времени; доступный адрес-
E10Link Up (канал восстановлен)Метка времени; имя порта восстановленного канала на PE-маршрутизаторе; адрес PE-маршрутизатора-
E11Card Up (интерфейс восстановлен)Метка времени; адрес PE-маршрутизатора; идентификатор интерфейса-
E12VPN service active (VPN-сервис активен)Метка времени; идентификатор VPN-
Таблица 15. Агенты обработки событий, пример 1
Свойство агентаХарактеристика
Agent ID (идентификатор агента)A2
Agent Name (имя агента)Service Impact Analyzer (анализатор влияния на сервис)
Agent Type (тип агента)Pattern Detection (обнаружение шаблонов)
Agent Context (контекст агента)-
Input Events (входные события)E4, E5
Agent Specification (спецификация агента)Генерирует событие Service Affected (затронутый сервис), если сетевой сервис клиента нарушен
Output Events (выходные события)E6
Agent Comments (комментарии)Использует смоделированные взаимоотношения между компонентами сети и предоставляемыми сервисами для определения того, был ли затронут сервис
Таблица 16. Агенты обработки событий, пример 2
Свойство агентаХарактеристика
Идентификатор агентаA3
Имя агентаCustomer Impact Analyzer (анализатор влияния на клиента)
Тип агентаRouting, Enrich (маршрутизация, пополнение)
Контекст агента-
Входные событияE6
Спецификация агентаРасширяет событие Service affected согласно стратегии, ассоциированной с SLA; пополняет подробной контактной информацией клиента.
Выходные событияE7
Комментарии-
Таблица 17. Агенты обработки событий, пример 3
Свойство агентаХарактеристика
Идентификатор агентаA4
Имя агентаМодуль расстановки приоритетов
Тип агентаМаршрутизация, обогащение
Контекст агента-
Входные событияE7
Спецификация агентаПополняет событие информацией об относительном приоритете
Route events to consumers dependent on priority (направить события потребителям в зависимости от приоритета)-
Instigate Corrective Action via Trouble Ticket system (активизировать корректировочные действия через систему заявок на устранение неисправностей)-
Выходные событияE4, E5, E7, E8
Комментарии -

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

Рисунок 8. EPN для сценария поставщика телекоммуникационных услуг
Рисунок 8. EPN для сценария поставщика телекоммуникационных услуг

Концептуальная архитектура

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

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

Чтобы понять, какую выгоду для бизнеса может дать система обработки событий, важно рассмотреть более мелкий уровень детализации, чем сеть обработки событий, рассмотреть компоненты, которые можно использовать для создания системы обработки событий, и их взаимодействия. Результатом этого процесса является то, что мы называем концептуальной архитектурой системы обработки событий. Кроме трех обычных уровней системы обработки событий (производитель событий и ассоциированные компоненты, потребитель событий и ассоциированные компоненты, промежуточный уровень шины событий – Event Bus) наша концептуальная архитектура предусматривает включение компонентов системы защиты, мониторинга, аналитики и управления событиями и потоками событий.

На простейшем уровне минимальный набор концептуальных компонентов, необходимых для системы обработки событий, состоит из уровня генератора событий (Event Emitter) для генерирования событий от производителей событий, шины событий (Event Bus) и уровня обработчика событий (Event Handler) для обработки событий с целью потребления событий потребителями. Это продемонстрировано на рисунке 9, на котором показано несколько примеров производителей и потребителей событий.

Рисунок 9. Минимальная концептуальная архитектура обработки событий
Рисунок 9. Минимальная концептуальная архитектура обработки событий

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

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

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

Рисунок 10. Концептуальная архитектура обработки событий – компоненты, которые могут принимать участие в системе обработки событий
Event Processing Conceptual Architecture components which can be involved in an Event Processing system

Архитектурные компоненты

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

  • Производитель событий (Event Producer). Производитель событий генерирует событие, когда происходит (или не происходит) что-то интересное. Производитель событий не содержит ни логики управления событиями, ни какой-либо логики принятия решений о том, что генерировать и когда, а генерируемые события могут быть избыточны или неуместны. Типичными примерами производителей событий являются:
    • Датчики событий, которые обнаруживают ситуации (происходящие явления) и генерируют необработанные события или порождают события из потоков данных или бизнес-потоков (например, передача данных о температуре).
    • Мониторы и датчики, которые генерируют события о доступности и проблемах в системах (например, неисправности в информационной сети).
    • Бизнес-процессы, которые генерируют события в важных точках обработки (например, в контрольных точках) или когда начинается или достигается конкретная задача обработки.
    • Сервисы и приложения, которые генерируют события в ключевых точках обработки (например, при активизации и завершении сервиса или при его сбое).
    • Конечные автоматы, которые генерируют события при изменении состояния.
  • Генератор событий (Event Emitter). Он логически (хотя не обязательно физически) ассоциирован с производителем событий и отвечает за преобразование и упаковку необработанных событий от производителей для доставки в шину событий. Генератор событий может содержать формирователь экземпляров событий (Event Instantiator), который создает экземпляры событий, сервисы простой обработки событий (Simple Event Processing Services), такие как фильтрация и промежуточное хранение событий, выданных одним производителем, или пополнение события доступной во время его возникновения информацией, и адаптеры событий (Event Adapters). Формирователь экземпляров событий принимает события от производителя и делает все необходимое (если нужно), чтобы сделать их доступными для дальнейшей обработки или доставки (например, объединение, кэширование и сериализация). Формирователь экземпляров событий может применяться для управления заголовком события, для вставки "семантических метаданных" в само сообщение и для самоописания (путем добавления такой информации как время, дата, тип инструмента, идентификатор процесса и т.д.). Генератор событий может обеспечивать оптимизацию, выполняя простую обработку событий на данном этапе, а не после достижения событиями шины событий. Адаптеры событий могут обеспечивать форматирование и преобразование протоколов событий в форму, принимаемую сетью обработки событий (например, помещение записей о событии в сообщения и отправка этих сообщений в шину событий).
  • Шина событий (Event Bus). Шина событий принимает события от генераторов событий, потенциально в очень больших объемах, и активизирует потребителей посредством обработчиков событий. Среди возможностей шины событий можно отметить обработку с целью порождения из входящих событий более информативных событий меньшего объема. Компоненты шины событий могут быть разнесены в пространстве. В следующем подразделе шина событий рассматривается более подробно.
  • Обработчик событий (Event Handler). Этот компонент подготавливает события из шины событий для потребления потребителем событий, принимая события и решая, как реагировать на них. Обработчик событий имеет адаптеры событий (Event Adapter) для приема сообщений из шины событий и извлекает из них записи о событии. Обработчик событий может также предоставлять сервисы простой обработки событий, которые занимаются обработкой на стороне потребителя с целью фильтрации и промежуточного хранения событий, принимаемых из шины событий. Обработчики событий могут также определять надлежащих потребителей для реагирования на событие и активизировать их с контекстом, порожденным из события. Наконец, обработчик события может обеспечивать оркестровку сервисов с целью распределения событий потребителям.
  • Потребитель событий (Event Consumer). Потребитель событий выполняет задания, реагируя на события. Потребитель событий имеет ограниченные знания об источнике события и просто знает о том, что он активизирован в результате события с предоставлением информация о контексте этого события. Примерами типичных потребителей событий являются:
    • Исполнительные элементы (Event Actuators), которые активизируются для выполнения таких физических задач, как приведение в действие клапанов управления, переключателей или сигналов тревоги.
    • Информационные панели оператора, отображающие информацию о поведении информационных систем и соответствующих сервисов.
    • Информационные панели предприятия, которые отображают информацию о поведении бизнес-процессов.
    • Бизнес-процессы, которые могут быть активизированы или продолжены в ответ на событие.
    • Сервисы и приложения, которые могут быть активизированы в ответ на событие и могут включать в себя внешние системы управления содержимым или репозитории событий.
    • Конечные автоматы, состояние которых может быть изменено в ответ на событие.

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

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

Компоненты шины событий

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

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

Шина событий должна предоставлять следующие сервисы, или строительные блоки:

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

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

  • Transformation (преобразование) – функция, преобразующая входящее событие путем его трансляции или разделения.
  • Enrichment (пополнение информацией) – функция, пополняющая содержимое событий справочными данными, возможно, из нескольких источников.
  • Validation (проверка корректности) – функция для проверки корректности согласно требуемым критериям.
  • Pattern Detection (обнаружение шаблонов) – функция, распознающая актуальные и ретроспективные шаблоны – сочетания из, возможно, нескольких событий, характеризующие важные бизнес-ситуации.
  • Filtering (фильтрация) – функция без запоминания состояния (stateless), фильтрующая события на основе их содержимого, т.е. информации, находящейся в сообщении, сгенерированном при возникновении события.
  • Aggregation (объединение) – функция, которая может группировать события при необходимости.
  • Routing (маршрутизация) – функция, направляющая события по назначению на основе различных шаблонов маршрутизации (например, по заранее установленному маршруту, на основе календарного плана, подписки или используя "интеллектуальную" маршрутизацию).

Концептуальная архитектура также включает в себя сервисы руководства и безопасности (Event Governance and Security Services) для управления и контроля жизненного цикла событий и их метаданных. Инфраструктура анализа и мониторинга событий (Event Monitoring and Analytic Infrastructure) необходима главным образом для администрирования, для уведомления о неисправностях в инфраструктуре событий и для сбора и отображения статистических данных о потоке событий. Эти возможности должны охватывать весь поток событий, поэтому они представлены с правой стороны схемы концептуальной модели.

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

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

Рисунок 11. EPN, используемая концептуальной архитектурой обработки событий
Рисунок 11. EPN, используемая концептуальной архитектурой обработки событий

Поток обработки в концептуальной архитектуре

В этом подразделе описывается концептуальная модель в действии. В работе модели можно выделить три фазы:

  • фаза генерирования события;
  • фаза обработки события;
  • фаза потребления события.

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

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

Фаза генерирования событий

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

Техническая точка зрения

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

Пример. В сценарии управления автопарком мы рассматриваем систему доставки, и в частности подсистему диспетчеризации транспортных средств, в качестве производителя событий. Давайте предположим, что подсистема диспетчеризации транспортных средств является бизнес-приложением, сохраняющим свои данные в реляционной базе данных. "Изменение доставки" – это бизнес-событие, которое должно генерироваться при каждом изменении водителя или транспортного средства, которые ответственны за конкретную доставку. Формирователь экземпляров события реализуется как триггер таблицы, хранящей данные о доставке (Delivery). Этот триггер активизируется при каждом обновлении экземпляра Delivery в данной таблице. Этот триггер реализует локальные сервисы обработки событий. Он проверяет, что обновление связано с изменением транспортного средства или водителя, которые ответственны за данную доставку. Если эта проверка проходит успешно, логика триггера собирает всю необходимую информацию (идентификатор водителя 1, идентификатор автомобиля 1, идентификатор водителя 2, идентификатор автомобиля 2, идентификатор отправителя, идентификатор получателя) и создает экземпляр сообщения о событии "Изменение доставки" в выделенной таблице событий Delivery Change. Подуровень "Адаптер событий" реализуется с использованием JDBC-адаптера, который опрашивает данную таблицу и активизирует внешнюю логику обработки событий на уровне шины событий.

Точка зрения бизнеса

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

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

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

Фаза обработки событий

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

Обработка одного входящего события

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

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

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

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

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

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

Обработка нескольких входящих событий

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

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

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

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

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

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

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

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

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

Фаза потребления событий

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

Техническая точка зрения

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

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

Точка зрения бизнеса

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

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

  • Информация может передаваться напрямую в интранет-портал больницы через канал новостей.
  • Посредством SMS-сообщений могут вызываться ключевые специалисты.

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


Отображение сценариев на концептуальную модель

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

Сценарий управления автопарком

Определив в предыдущем разделе различных участников (производителей и потребителей сообщений), события и агенты обработки событий, можно отобразить сценарий управления автопарком на концептуальную архитектуру обработки событий (см. рисунок 12). Взаимосвязь производителей и потребителей событий довольно очевидна. Все агенты, за исключением агента маршрутизации A4, отображаются на компонент обработки событий в шине событий. В Отображения на генератор событий и на часть обработчиков событий концептуальной модели отсутствуют, так как два события E1 и E3, генерируемые системой отчетности водителя, не требуют специальной обработки и могут обрабатываться агентами A1 и A2 в своем исходном виде, а E5 может потребляться всеми потребителями в своем исходном виде.

Рисунок 12. Компоненты концептуальной архитектуры в сценарии управления автопарком
Рисунок 12. Компоненты концептуальной архитектуры в сценарии управления автопарком

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

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

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

Рисунок 13. Компоненты концептуальной архитектуры в сценарии системы уведомлений в здравоохранении
Рисунок 13. Компоненты концептуальной архитектуры в сценарии системы уведомлений в здравоохранении

Завершив описание сценария, давайте посмотрим, почему обработка событий важна для данного примера.

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

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

Сценарий поставщика телекоммуникационных услуг

На рисунке 14 показано отображение сценария поставщика коммуникационных услуг на компоненты концептуальной архитектуры обработки событий.

Рисунок 14. Компоненты концептуальной архитектуры в сценарии поставщика телекоммуникационных услуг
Рисунок 14. Компоненты концептуальной архитектуры в сценарии поставщика телекоммуникационных услуг

Заключение

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

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

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


Благодарности

Авторы хотели бы поблагодарить за значительный вклад в концептуальную модель и в данную статью Кристофера Арендта (Christopher Ahrendt), Кайла Брауна (Kyle Brown), Котесвара Кейджарла (Koteswara R Chejarla), Нормана Коэна (Norman Cohen), Джона Динджера (John Dinger), Грега Фларри (Greg Flurry), Пола Гиангарра (Paul Giangarra), Кевина Холла (Kevin Hall), Роберта Хойкерта (Robert Heuchert), Бет Хатчинсон (Beth Hutchison), Дэвида Джансона (David H Janson), Джоджо Джозефа (Jojo Joseph), Чун-Шен Ли (Chung-Sheng Li), Рахула Нараина (Rahul Narain), Питера Ниблетта (Peter Niblett), Дэйва Расселла (Dave Russell), Роберта Сойера (Robert Sawyer), Бориса Шульмана (Boris Shulman), Майкла Спайсера (Michael Spicer) и Бобби Вульфа (Bobby Woolf).

Ресурсы

Комментарии

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=SOA и web-сервисы
ArticleID=807488
ArticleTitle=Концептуальная модель для систем обработки событий
publish-date=03292012