Event-driven architecture

В 2006 году Gartner закрыл аналитическую группу, которая занималась управляемой событиями архитектурой (Event-driven architecture, EDA). Термин EDA предложил аналитик Gartner Roy W. Schulte тремя годами раньше в работе The Growing Role of Events in Enterprise Applications Обзор работы на русском языке можно посмотреть в статье EDA – архитектура, управляемая событиями До какого-то момента SOA и EDA в сознании аналитиков шли рука о руку (см., например 2.0 The Mission and Future of Integration), но потом управляемая событиями архитектура впала в немилость и была забыта. Может быть, концепция была слишком революционной, а может идея Complex event processing (CEP) отвлекла на себя основной внимание, но из-за задержки внедрения таких технологий как RFID ушла в тень, прихватив с собой и EDA, не важно. Для нас важно другое:

  • во-первых, в отличии от SOA, EDA – это действительно архитектура, т.е. определенный подход к построению информационной системы предприятия;
  • во-вторых, концепция управляемой событиями архитектуры объясняет, почему сегодня интерес к сервисной шине предприятия (ESB) опережает интерес к SOA (см. ссылки в сообщении Forrester: SOA жив и здоров)

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

Следующая тонкость состоит в том, что для построения сервис-ориентированой архитекутры Enterprsie service bus, вообще говоря, не нужна. Приложения сами могут предоставлять сервисы. ESB позиционировалась как инструмент разработки сервисов для унаследованных приложений. Но если такое приложение хоть как-нибудь развивается, то вытащить из него программные интерфейсы и обернуть их сервисами можно и без помощи ESB. А если приложение уж совсем унаследованное и никто не понимает, как оно там внутри себя функционирует, то «вытащить» из него сервисы и при помощи ESB не удастся. А вот для построения управляемой событиями архитектуры интеграционная среда необходима. События надо перехватывать, преобразовывать, маршрутизировать и т.д. (Подробнее см. мою презентация на конференции SOA AHConference 2007)
Таким образом, EDA расставляет все на свои места. Интересно, что в уже выше упомянутой работе The Mission and Future of Integration все это было сказано. И в ней же был приведен список распространенных мифов относительно интеграции. Приведу лишь некоторые из них:

  • Миф №1: Архитектура предприятия (Enterprise architecture) способна предотвратить потребность в интеграции. Реальность: ни одно предприятие не может себе позволить переписать «с нуля» все имеющиеся приложения, поэтому организациям так или иначе придется работать с набором разрозненных систем
  • Миф №2: Готовые пакеты приложений (Packaged application suites) устранят необходимость интеграции. Реальность: внедрение таких приложений увеличит потребность в интеграции; новые системы придется интегрировать с уже существующими приложениями
  • Миф №3: Сервера приложений позволят отказаться от использования интеграционных сред. Реальность: поставщики серверов приложений, видя потребность в средствах интеграции и управления бизнес-процессами, включили в свои решения ESB и BPMS

Event-driven architecture: 17 комментариев

  1. >> …Приложения сами могут предоставлять сервисы. ESB позиционировалась как инструмент разработки сервисов для унаследованных приложений…

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

  2. Если верить http://www.ibm.com/developerworks/webservices/library/ws-esbscen/
    То:
    The use of explicit implementation-independent interfaces to define services.
    The use of communication protocols that stress location transparency and interoperability.
    The definition of services that encapsulate reusable business function.

    Только первые два хоть как-то можно отнести к “обеспечения коммуникации между компонентами”.
    Имхо, третья задача более ценна – реализация бизнес ценных сценариев используя интерфейсы компонентов решения.

    Связанность, наверное, уменьшается за счет того что ESB предоставит _единый_ протокол в решении и действительно коммуникации становятся проще (нагляднее, естественнее).

    Правда, читая другие посты Максима и соглашаясь с ним, скажу что если всё решение сделано на SOA, то ценность шины очень мала. А случае если шина используется для “сокрытия” за странных интерфейсов легаси продуктов – то тут удобно.Но! Как Максим заметил в этой статье, можно было бы обойтись и “обернуть их сервисами можно и без помощи ESB”.

  3. Добавлю немного практики относительно ESB в обсуждние. Даже при наличии разработки новых компонентов решения с Native-реализацией у них сервисов роль ESB никак не снижает (по моему опыту):
    0. Безопасность обеспечения коммуникаций и защита информации на уровне ESB – а у каждого вашего сервиса. Думаю, понятно, что можно сделать некую DMZ сервис-есб, отдельную от зоны есб-потребитель, где ESB сыграет роль firewall.
    1. всё той же интероперабельности, т.к., думаю, кто-то сталкивался с проблемой трансляции SOAP rpc/encoded (“старые сервисы” Axis1) doc/literal (“новые сервисы” по WS-Basic Profile c Axis2) – а тем более при интеграции сервисов без наличия WSDL. Можно вспомнить ещё любителей писать REST-сервисы (считающие их таковыми, если они GETом вызывают запуск транзакции:).
    2. журналирования всех происходящих в системе запросов/ответов (для возможности анализа происходящего, а также расследования инцидентов), отработки HA или LB-политик – без чего система с реально работающими сервисами слишком хрупкая.
    3. обеспечения политик QoS (контроль пропускной способности, размера очереди запросов и т.п.), нотификации при отказах и т.п. – без чего (вместе с п.2) нельзя построить “не хрупкое” решение, где интегрированы чужие компоненты.
    4. ESB не корректно использовать в качестве сервиса бизнес-сценариев (для этого есть специальные engine на базе Apache ODE и т.п.) – то, что в Glassfish засунули BPEL JBI – это всётаки не означает, что ESB и предназначена для этого. На мой взгляд, функции BP-engine и ESB корректнее разносить, раздельно масштабировать и управлять (как минимум у них разные характеристики нагрузки и принцип функционирования).
    5. Не уверен, что ESB предоставляет “единый протокол” – скорее она поставляет набор шаблонов интеграции, а также среду для их описания и функционирования (особенно, если вам не придётся писать на джаве или перле под ESB очередной адаптер для “нового супер-уникального протокола” вашего нового партнёра:).

    Отдельно. Например, всеми любимый Axis2 позволяет делать из java-бинов сервисы почти автоматически, без написания прослойки, аннотаций и др. (похожим образом можно использовать SCA-движки). Думаю, что тот, кто пишет какой-нибудь бизнес-уровень не должен особо задумываться о том, какой же xmlns нужно прописать в аннотации или т.п. – он должен думать о бизнес-логике, а не об инфраструктурных проблемах.

    1. 0,1 – согласен, так оно и используется
      2 – хороший подход, а журналирование, объединение логов из разных источников, корреляция событий – отдельная тема
      3 – мы называем это квотированием, оно потребовалось практически сразу же после появления шины. Было это давно, на тот момент мы работали с линейкой websphere и нужного функционала там не было. Пришлось делать “на коленке”
      4 – BPELу вообще не везет. Из BPM его выкинули и ESB – вроде не о том. На самом деле, нужен стандарт на разработку сценариев content base routing-а, более простой чем BPEL. С трансформацией – все нормально, а с CBR – нет. А разработчикам Glassfish ESB – все равно огромное спасибо за BPEL service engine. Если бы он еще Worklist service engine доделали бы, то инструмент стал бы полнофункциональным
      5 – адаптеры писать придется 🙂

      1. 4 – ну не скажу, что BPEL-выкинули, Intalio (похоже на промышленную BPM) по-сути на нём строится, хотя нужно и BPMN рисовать, со всеми ограничениями, которые есть у Apache ODE:).
        Кстати, стоит посмотреть на jBPM5 и его native-интегрированность с POJO и Drools – это может быть намного выгоднее, особенно из-за возможностей BRMS Drools-Guvnor, которая – например – даже где-то перекрывает BPM, например, для биллингов…

        Насчёт DSL ESB – http://synapse.apache.org/Synapse_Configuration_Language.html. На его основе, например, работает http://wso2.org/library/esb – у нас есть большой опыт работы с ней – в принципе всё красочно:)

  4. По поводу вопросов использования подхода EDA для больших и нагруженных решений.

    0. Бизнес-логика
    Не секрет, что наличие событийной модели хорошо работает в связке со state-machine-движками, в том числе бизнес-процессов, что не редко сильно упрощает разработку бизнес-логики.
    1. Контекст
    На самом деле, сами по себе события без контекста их создания или обработки – для более менее сложных решений – не так интересны. Отсюда, возникает желание делать события более самодостаточными, содержащими весь контекст (все данные, которые дополняет сам факт события), чтобы получающие их компоненты/подписчики могли полностью их обработать, с минимум запросов в чужие БД и т.п. для уточнения контекста, что, собственно, снижает выгодны от той самой EDA и всей её connectionless – чудес не бывает:).
    Таким образом, по мере развития вашего EDA-решения, размер циркулирующих по вашей ESB (или другой EDA-среде) сообщений о событиях начинает быстро расти, а вместе с этим и скорость обработки их потоков – уменьшаться. Хотя да – зато все эти сообщения в очередях мы когда-то обработаем!:). Не, всётаки надо сокращать объём контекста в сообщениях и делать старые-добрые сервисы данных и т.п. – ну да, немного снижать роль EDA и смешивать с обычной сервис-ориентированной парадигмой.
    2. CEP
    (позволю себе менее формальное определение) Собственно, это некий вариант использования бизнес-правил для потоков событий, с генерацией новых событий, агрегациями и корреляциями их. Это позволяет выносить из компонентов генераторов/потребителей событий бизнес-правила по аналогии с BRMS. И здесь самое интересное, что для более менее сложного CEP только событий не достаточно – нужен тот самый контекст, т.е. запросы в другие сервисы и др. Что автоматически усложняет разработку CEP-правил и т.п.
    3. Инфраструктура
    По-сути EDA без инфраструктуры для CRUD контекста, которая работает отдельно от сообщений – не очень подходит для сложных решений с большими потоками событий. В простейшем варианте, такая инфраструктура имеет вид некоторого достаточно быстрого кластера (memcached, Terracotta, GigaSpace, Cassandra, HBase), где по ключу можно сохранять данные контекста (Xml, json, csv), а сам ключ включать в содержание сообщения. Соответственно, получатель сообщения события может поднимать и обновлять контекст по ключу в хранилище – важен быстрый I/O.
    П.С, (полезные примеры производительных решений) http://s4.io/, http://www.flumebase.org/ – и без всяких Drools Fusion, StreamBase и т.п. Могу сказать, что для задач связанных с т.н. поведенческим таргетингом в вэб для маркетинга и рекламы уже используется CEP (во всяком случае сейчас у нас это работает) – хотя работает отдельно от SOA и RFID тут уже давно не драйвер развития:).
    4. GUI
    При использовании асинхронных событий-команд и подтверждений сильно усложняется разработка GUI (поддержка временных топиков ответов, AJAX-Comet и т.п. – desktop не рассматриваю:). GUI плохо работает в связке с EDA (кажется, у альфа-банка на сайте есть подобная проблема), т.к. пользователь всётаки привык работать синхронно, а не редко сложно гарантировать QoS обработки нашего события за вменяемое время, особенно, если один из подписчиков каскада обработки события – сторонний (хотя тут приходит на помощь ESB!:). По-сути, это приводит нас к необходимости имитации синхронности для пользователя (“мы приняли вашу заявку, скоро ответим!”), что потребует создания дополнительного слоя адаптации для GUI-уровня и инфраструктуры EDA-сервисов.

    П,С, Не рассматриваю варианты, что “мы можем с подписчиком подписать SLA” – всётаки в архитектуре что-то в первую очередь решать.

    —-

    EDA сама по себе, без хранилища контекста – мало эффективна в сложных решениях (чем-то похоже на проблему BPEL-движков для хранилища гидрированных экземпляров – то же контексты). Хотя нет, если вы, настроив пачку сервисов, начнёте генерировать по их вызовам события (например в ESB), для которых найдутся потребители – можно уже считать, что у вас уже работает EDA:), только это всё формальности…

  5. Хорошая тема, содержательное обсуждение, спасибо! Мой следующий пост будет про ESB. Честно говоря, тему про сервисную шину давно пора выносить в onlne. Есть что пообсуждать

  6. Максим (или кто-нибудь из участников обсуждения), а Вам известна какая-нибудь статья, в которой бы показывались примеры реализации на базе EDA известных со времен ESB интеграционных паттернов? Спуститься, так сказать, от стратегических выгод (архитектура выглядит стройнее) до сугубо практических (проще реализовать).
    Кстати (не сочтите меня противником EDA ни в коем разе), представленная Вами картинка с SOA-хаосом вполне применима и к EDA-реализации, только представьте еще себе “набухающие” в просветах между ИТ-системами очереди сообщений, на которые никто не подписан, т.к. что-то поменялось в ИТ-ландшафте :))) Так что тут тоже глаз да глаз нужен!
    Ну и все же легаси-системы, как правило, ориентированы более на сервисную парадигму (она так или иначе растет из процедурного подхода в программировании), нежели на мессаджинг.
    Резюме: подходы всякие нужны, подходы всякие важны, причем, возможно, одновременно в рамках одной организации. Меня в этой ситуации несколько смущает отсутствие объединяющей методологии.

      1. Максим, спасибо за интересные ссылки. Из них лично я сделал (уже напрашивашийся у меня) вывод, что EDA – не альтернатива, а дополнение к SOA (ну, или наоборот – SOA дополнение к EDA). Собственно, на уровне инструментария это уже признано – хорошо известный мне по определенным причинам webMethods в равной степени поддерживает и SOA-, и ED-сцерании взаимодействия. Подозреваю, что все “одноклассники” придерживаются такой же стратегии. Остальное в больщой степени зависит от особенностей архитектуры. EDA – быстро делаем простые сценарии, легко добавляем контрагентов. SOA – обеспечиваем единую точку контроля, трассируемость интеграционных сценариев, гарантированную доставку. Плохо, как я уже говорил, то, что архитектура взаимодействия ИС на предприятии “размазывается” по двум подходам, между которыми, по сути, нет общей методологической точки – невозможно из одного бинокля осмотреть все поле битвы, сначала надо глянуть в SOA-бинокль (кто кого вызывает), а потом в ED-бинокль (кто что публикует, кто на что подписан). Здесь, должны подключаться средства архитектурного моделирования (или даже средства реверс-инжиниринга интеграционной архитектуры), дающие возможность обозревать картину целиком.

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

Добавить комментарий для slookin Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *