SOA, управляемая событиями

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

СОА 2.0

Архитектура SOA 2.0 («SOA, управляемая событиями») позволяет бизнес-пользователям отслеживать, анализировать и обогащать события, чтобы устанавливать связи между разрозненными событиями, которые на первый взгляд не кажутся интуитивно очевидными. Это делает эти расширенные события видимыми для других, особенно для бизнес-аналитиков или директоров по маркетингу, а также позволяет системе SOA 2.0 возможно автоматизировать действия, необходимые для устранения какой-либо уникальной закономерности. ^[1]

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

Если благодаря расширенным событиям, создаваемым средой SOA 2.0, станет ясно, что за последние несколько дней возросло количество отказов от корзин покупок, уведомление в отдел маркетинга может инициировать исследование того, что сделали конкуренты, чтобы побудить клиентов совершить покупку. продукты в другом месте. Был ли в большинстве тележек один и тот же товар? Если да, то каковы цены, предлагаемые конкурентами?

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

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

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

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

Прототип парадигмы SOA 2.0

Прототип парадигмы SOA 2.0 содержит четыре основных элемента:

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

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

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

BPEL следует парадигме оркестровки. Хореография регулируется другими стандартами, такими как WSCI (интерфейс хореографии веб-служб) и WS-CDL (язык описания хореографии веб-служб).

Несколько системных событий низкого уровня

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

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

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

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

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

Бизнес-аналитики могут внести дополнительные определяющие детали с помощью оператора SQL-запроса, прикрепленного к контексту правила или события. Приложение CVE работает во многом как современное приложение для торговли акциями, которое управляющие взаимными фондами используют для управления рисками. Пример приложения и механизма CVE можно увидеть в SILK. ^[2]

Обогащение данных

Большинство реализаций корпоративной сервисной шины (ESB) содержат функцию, называемую « посредничеством ». Например, потоки передачи являются частью перехвата корпоративной сервисной шины WebSphere . Mule также поддерживает потоки посредничества. Потоки передачи изменяют сообщения, которые передаются между существующими службами и клиентами, использующими эти службы. Поток передачи выступает посредником или вмешивается для предоставления таких функций, как регистрация сообщений, преобразование данных и маршрутизация. Обычно эти функции могут быть реализованы с использованием шаблона проектирования перехвата. ^[3]

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

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

Потоки медиации

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

После того как разработчики запрограммировали пользовательскую привязку для экспорта и импорта, они могут сосредоточиться на компоненте потока передачи. В редакторе сборок WebSphere Integration Developer это выполняется компонентом JMS Custom Binding Mediation Component, где каждая операция в интерфейсе компонента потока представлена запросом и ответом.

Платформа объектов служебных данных (SDO) обеспечивает унифицированную среду для разработки приложений данных. Благодаря SDO разработчикам не нужно знать какой-либо конкретный API для доступа к данным и их использования. С помощью SDO разработчики просто работают с данными из нескольких источников данных, таких как реляционные базы данных, EJB-компоненты сущностей, XML-страницы, веб-службы, архитектура сервисных компонентов и страницы страниц JavaServer.

Потоки передачи полностью независимы от привязок, которые используются при импорте и экспорте. Фактически, цель преобразования в экземпляр SDO DataObject вне реализации потока заключается в том, что потоки передачи могут быть построены без знания протокола и формата, в котором сообщения отправляются в модуль передачи и из него.

Условие триггера бизнес-уровня

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

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

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

Итоговый бизнес-процесс

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

Концептуальные примеры SOA 2.0

Заброшенная корзина

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

Инженерный дефект

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

Реализации SOA 2.0

Одним из механизмов, который можно использовать в большинстве реализаций Enterprise Service Bus SOA 1.0, является возможность публикации/подписки . Благодаря реализации функциональности ESB в виде сообщений Pub/Sub для создания шаблонов сообщений SOA 2.0 не требуется дополнительных знаний о системных событиях. После того как предприятие реализовало множество функций публикации, аналитики промежуточного программного обеспечения SOA могут приступить к разработке стратегии, какие из доступных сообщений публикации можно объединить в уникальный шаблон для обнаружения триггера, обогащенного SOA 2.0.

Механика Causal Vector Engine (CVE) реализована просто, с расширяемым представлением конструкций SQL, записанных в хранимых процедурах . ^[4] Если A вызывает B и причинно-следственная связь должна произойти в пределах N транзакций, то предложение SQL ORDER BY timestamp создает набор результатов , который увеличивает счетчик всех транзакций, произошедших в течение определенного периода времени, на N число совпадений B с A. транзакциями Создание дополнительных хранимых процедур осуществляется с помощью консольного приложения CVE или с помощью любого стандартного инструментария разработчика баз данных. ^[5]

Медицинские применения

Алгоритмы предметной области, такие как логика предметной области лихорадки/гриппа/инфекции в цитируемой ссылке, используются для получения кода SQL, который применяет выбранные бизнес-правила к варианту использования. Использование CVE в средах SOA повышает гибкость бизнеса, поскольку применение принципов SOA 2.0 выявляет бизнес-возможности, которые в противном случае были бы упущены или выявлены гораздо позже. ^[6]

Функциональная магнитно-резонансная томография (фМРТ) с использованием причинно-следственного анализа Грейнджера (GCA) обнаруживает причинные эффекты между областями мозга. Результаты одного выборочного теста продемонстрировали положительный причинный эффект между rFIC и дорсальной передней поясной извилиной коры (dACC). ^[7]

Бизнес-аналитика Oracle

Аналитический механизм Oracle CVE использует набор теоретических моделей, каждая из которых оценивает некоторые или все данные. Когда бизнес-аналитик настраивает причинные факторы, он/она указывает критерии, указывающие, какие модели должны учитывать тот или иной причинный фактор. ^[8]

См. также

Ссылки

^ «Уступите место SOA 2.0» . 17 мая 2006 г.
^ http://silk.semwebcentral.org/gui-ruleml-2010.pdf. Архивировано 21 мая 2013 г. в графическом интерфейсе движка причинных векторов Wayback Machine как плагин Eclipse.
^ «Э. Карри, Д. Чемберс и Дж. Лайонс, «Расширение промежуточного программного обеспечения, ориентированного на сообщения, с использованием перехвата», представлено на Третьем международном семинаре по распределенным системам, основанным на событиях (DEBS '04), ICSE '04, Эдинбург, Шотландия, Великобритания. , 2004» (PDF) . Архивировано из оригинала (PDF) 26 июля 2011 г. Проверено 9 августа 2011 г.
^ http://bicep.dei.uc.pt/images/5/58/FINCoS_DEBS2008.pdf Разработка причинно-векторного двигателя.
^ http://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Алгоритмический инструментарий Causal Vector Engine.
^ http://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Логика причинно-векторного двигателя в медицинской сфере.
^ Занг, ZX; Ян, CG; Донг, ЗЯ; Хуанг, Дж; Занг, Ю.Ф. (2012). «Реализация причинно-следственного анализа Грейнджера в MATLAB: набор инструментов графического пользовательского интерфейса для обработки данных фМРТ». Дж. Нейроски. Методы . 203 (2): 418–26. дои : 10.1016/j.jneumeth.2011.10.006 . ПМИД 22020117 . S2CID 44845757 .
^ http://docs.oracle.com/cd/E18727_01/doc.121/e05136/T485796T488110.htm Механизм Oracle Business Intelligence широко использует временные данные в исторических и будущих временных интервалах.

[1] «Уступите место SOA 2.0» . 17 мая 2006 г.

[2] ttp://silk.semwebcentral.org/gui-ruleml-2010.pdf. Архивировано 21 мая 2013 г. в графическом интерфейсе движка причинных векторов Wayback Machine как плагин Eclipse.

[MOM-3] «Э. Карри, Д. Чемберс и Дж. Лайонс, «Расширение промежуточного программного обеспечения, ориентированного на сообщения, с использованием перехвата», представлено на Третьем международном семинаре по распределенным системам, основанным на событиях (DEBS '04), ICSE '04, Эдинбург, Шотландия, Великобритания. , 2004» (PDF) . Архивировано из оригинала (PDF) 26 июля 2011 г. Проверено 9 августа 2011 г.

[4] ttp://bicep.dei.uc.pt/images/5/58/FINCoS_DEBS2008.pdf Разработка причинно-векторного двигателя.

[5] ttp://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Алгоритмический инструментарий Causal Vector Engine.

[6] ttp://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Логика причинно-векторного двигателя в медицинской сфере.

[7] Занг, ZX; Ян, CG; Донг, ЗЯ; Хуанг, Дж; Занг, Ю.Ф. (2012). «Реализация причинно-следственного анализа Грейнджера в MATLAB: набор инструментов графического пользовательского интерфейса для обработки данных фМРТ». Дж. Нейроски. Методы . 203 (2): 418–26. дои : 10.1016/j.jneumeth.2011.10.006 . ПМИД 22020117 . S2CID 44845757 .

[8] ttp://docs.oracle.com/cd/E18727_01/doc.121/e05136/T485796T488110.htm Механизм Oracle Business Intelligence широко использует временные данные в исторических и будущих временных интервалах.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]