В 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