SOA и EDA: разные архитектуры или одна и та же?

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

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

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

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

Хорошие новости заключаются в том, что SOA и EDA могут быть включены в одну архитектуру. На самом деле, «новая SOA» или «событийно-управляемая SOA» - это развитие SOA. Следуя основным принципам SOA, эти компании смогли пошагово добавить событийно-управляемые технологии.
 

Как работает SOA

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



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



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

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

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

[Перепечатка материалов 12NEWS.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]
 

На сцену выходит EDA

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

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

Есть несколько ключевых отличий между классической SOA и EDA. События существуют и в SOA, но их нельзя назвать «толкающими» для нескольких получателей. SOA – это классический тип архитектуры «запрос/ответ». Это отношения один-к-одному, внедренные с использованием web-сервисов или других протоколов. В EDA уведомление представляет собой уведомления один-ко-многим, эти уведомления обычно внедрены с использованием механизма публикации-подписки. Это серьезное отличие.

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

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

Компоненты событийно-управляемой SOA

Какие компоненты включают в себя SOA и EDA, и как их можно использовать вместе в одной архитектуре?

Сервисы - ДНК SOA

Сервисы – это самый простой для понимания компонент SOA. Это модули ПО, которые представляют собой используемую функциональность бизнеса, например, «процесс заказов» или «выставление счетов клиентам». Существуют также системные сервисы, такие как: контроль системы, ведение журналов и даже организация взаимодействия.

По своей сути SOA разнородна, что, по существу, означает, что компании держат сервисы на множестве разных платформ. Сервисы большинства компаний работают на Java, Java EE, и .NET. Большинство компаний также обслуживают подключение существующих приложений, представляя функциональность в виде сервисов, используя адаптеры или web-сервисы.

События - ДНК EDA

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

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

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

Передача сообщений - обычный способ перемещения для SOA и EDA

Технология, которая завоевала популярность в последние десять лет, – это промежуточное программное обеспечение, ориентированное на обработку сообщений (MOM). Примерами служат любые продукты, основанные на Java Message Service (JMS), такие как TIBCO Enterprise Message Service™ или продукты по работе с сообщениями, такие как TIBCO Rendezvous®, Microsoft Message Queue и IBM’s WebSphere MQ. Передача сообщений - это «другой» вид передачи сервисов через HTTP, и это также основа для EDA.

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

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

Сервисная шина предприятия (ESB) - основа для SOA и EDA

ESB(Enterprise Service Bus) поддерживает разные типы протоколов и форматов, используемых в SOA, включая web-сервисы, системы передачи сообщений, основанные на JMS или собственной разработке, так же, как и другие протоколы: HTTP и электронная почта или протоколы на основе адаптеров. Определения могут быть разными, но обычно они включают трансформации и маршрутизацию содержания. Некоторые ESB можно приобрести отдельно, другие - могут быть частью большого комплекта, который включает взаимодействие и интеграцию.

Если ESB поддерживает все виды обмена сообщениями, тогда она так же может поддерживать EDA, ставя ee в основание для объединенной архитектуры. В этом случае часто широко используется передача сообщений, как для связи публикация/подписка в EDA, так и для испытанной связи запрос/ответ в SOA. Одна из опасностей ESB в том, что разные ESB и продукты по передаче сообщений внедряются отдельно для EDA и SOA. Результатом является то, что события часто задерживаются в разных подразделениях ESB, сверху сообщений, уже задержанных в подразделениях приложений, которые имеют собственные форматы, и откуда их намного сложнее достать. Все это ведет к большим разработкам, интеграции и непрерывной поддержке.

Взаимодействие: гибкий подход к автоматизации структурированных процессов

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

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

CEP: гибкий подход к автоматизированному интеллектуальному принятию решений

В последние годы CEP (Complex Event Processing) стал более распространенным. CEP помогает автоматизировать интеллектуальный отклик на различные события, часто используя графический подход. Как и организация взаимодействия, CEP представляет собой более гибкий подход, чем программирование.

Соотношение событий для большей их части - это черная дыра в знаниях, потому что это очень сложно. Система CEP определяет значимые события (источник не важен), добивается понимания, что событие собой представляет, отслеживает его и помещает в большую структуру, так чтобы можно было предпринять какие-то действия. Это действие может быть результатом события, которое уведомляет ответственного человека или запускает автоматический процесс. В то время как SOA и взаимодействие автоматизируют четкие процессы, CEP автоматизирует интеллектуальное соотношение и принятие решений для отдельных людей. Многие наблюдатели полагают, что тип продукта CEP необходим для завершения настоящей EDA, потому что ESB/MOM понимают события, но они понимают их на простом уровне, который прикрепляется к довольно динамичному процессу.

Система CEP обычно состоит из нескольких частей. Первая – это соединители для захвата и распознавания событий, которые обычно находятся на верху ESB/MOM, баз данных и приложений. Они захватывают события, посылают их через сервер, обрабатывающий события, отфильтровывают бесполезные события и помещают их в общий индексируемый формат так, что они могут быть отслежены. Метаданные часто являются частью такого индексируемого формата. Хотя это звучит как RDBMS, CEP не требует постоянного хранения событий и работает с событиями в движении, так как затраченное время критично. В CEP обнаруженные события и ситуации могут храниться для проверки и требований о соответствии нормам.

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

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

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

Современная ситуация с внедрением грамотной SOA

Итак, возвратимся к первоначальному вопросу: внедряете ли вы хорошую SOA надолго? Если вы внедряете ESB, которая поддерживает EDA и передачу сообщений для любых событийно-управляемых соединений, тогда ответ - «да». Если вы не внедряете ESB, например, если вы внедряете SOA, используя сервер приложений, брокеры интеграции и программы, тогда ответ - «нет». Вам скоро понадобится ESB.

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

По материалам BTQmagazine©
Перевод: Алексей Маринин
12NEWS©

© Издание 12NEWS (ИП Маринин А.Л.), 2007