EDA как очередная инкарнация SOA

Леонид Черняк

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

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

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

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

Следующим шагом стало управление бизнес-процессами (Business Process Management, BPM). Основоположниками этого течения считаются Дэйл Скина, основатель компании Teknekron Software Systems, известной теперь как Tibco, и Исмаэль Халими, который создал компанию Intalio [1]. Напомним, что термин BPM распространяется на действия, выполняемые с целью оптимизации и адаптации своих процессов. В широком смысле такое управление существовало всегда, но с появлением специализированного программного инструментария этот термин приобрел более узкий смысл; его относят прежде всего к интеграции и оптимизации бизнес-приложений. Рождение BPM в данном контексте датируется концом 90-х годов; первые решения в этой области были построены на частных технологиях, но они просуществовали недолго. Уже через несколько лет дали о себе знать сервисный подход к интеграции и сервис-ориентированная архитектура (Service-Oriented Architecture, SOA). Сервисный подход к организации систем оказался настоящей находкой для BPM.

Технологии SOA и BPM удачно дополнили друг друга; ИТ-компании быстро осознали их родственность, и начался активный процесс конвергенции, который продолжается и сегодня. Интенсивность событий, происходящих в этой области, позволяет оценить перечисление всего нескольких анонсов, сделанных в первом квартале 2006 года. Корпорация Sun Microsystems, объединив технологию, полученную в результате приобретения компании SeeBeyond, с собственными программными продуктами, предложила пакет Java Composite Application Platform Suite (Java CAPS) для создания составных приложений практически без написания кода и анонсировала пакеты профессиональных услуг по планированию и внедрению SOA в организациях. Компания Tibco объединила системы управления бизнес-процессами с интеграционными продуктами, создав пакет Tibco Staffware Process Suite 10.3, обеспечивающий возможность многократного использования сервисных приложений в составе процессов. Компания BEA Systems предложила инструментарий управления бизнес-процессами «пользовательского» уровня AquaLogic Interaction Process 1.5, который позволяет с помощью портала управлять бизнес-процессами, подразумевающими коллективную работу. Кроме того, BEA объявила о приобретении компании Fuego, разработчика систем BPM на базе SOA. Технологии Fuego позволят компании предложить своим клиентам семейство унифицированных инструментов для интеграции в рамках SOA бизнес-процессов, приложений и унаследованных систем.

Объединение компонентов информационной системы средствами SOA — только первый шаг. Благодаря интеграции приложений на фундаменте SOA действительно создается определенная машина, которая, вообще говоря, способна работать, но не связана с окружающей средой — той реальной средой, где происходят какие-то события. Чтобы преодолеть этот разрыв, прибегают к архитектуре, управляемой событиями (Event Driven Architecture, EDA).

Из «больших» компаний первой на эту архитектуру сделала ставку Oracle. Представляя ее, вице-президент Oracle Амлан Дебтах сказал: «Биологическая жизнь управляется событиями. Посмотрите на свое тело, на органы, они посылают сведения в центральный процессор-мозг. Если вы дотронетесь до горячего, то невольно отдерните руку, это ваша реакция на событие». Что же, верное наблюдение, но стоит учесть, что после 1948 года, когда Норберт Винер написал свою знаменитую книгу «Кибернетика: управление и коммуникация в животном и в машине», теория ушла несколько дальше. Тот же Дебтах считает, что между SOA и EDA сохраняется разрыв, а потому задача, стоящая, в том числе и перед его компанией, заключается в преодолении этого разрыва.

Но какого рода этот разрыв? Аналитики Gartner считают, что между двумя архитектурными подходами есть разрыв во времени: одна появилась после другой с заметным временным лагом. С этим утверждением трудно не согласиться, но в контексте обработки событий они логически неразрывны — обмен сообщениями между взаимодействующими компонентами и способность реагировать на них. Поэтому если и стоит говорить о разрыве между SOA и EDA, то это разрыв по уровню зрелости технологий.

Аналитики про SOA

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

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

Но другие аналитики-практики, в большей мере занятые не прогнозированием, а социометрией ИТ, утверждают совершенно противоположное. Они не столь оптимистичны в своих оценках принятия идей SOA клиентами. Так, директор по исследованиям английской аналитической компании Ovum убедился на своем опыте выступлений перед ИТ-руководителями, что, как только он переходит к теме, связанной с SOA, пользовательский интерес к докладу явным образом снижается. Он уверен, что эта тема большинству слушателей пока не интересна. Более того, австралийская компания Springboard Research, опросив почти 3 тыс. ИТ-руководителей в Австралии, Индии, Китае и Сингапуре (отнюдь не самый отсталый регион), установила, что только 21% из них понимают суть концепции SOA. Как следствие, 28% не уверены в том, будут ли они когда-либо ориентироваться на нее, а 9% вообще категорически отказались думать о SOA. Среди отечественных ИТ-директоров тоже немало тех, кто относится к SOA скептически. В чем же причина очевидного противоречия между восторженными воззрениями теоретиков и скепсисом практиков? 

SOA, долгая дорога к определению

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

А период на самом деле наисложнейший, не будет сильным преувеличением сравнить его с тем периодом в развитии физики, когда появились теория относительности и квантовая теория. И тогда в физике, и сейчас в ИТ наблюдается переход из детерминированного мира в недетерминированный (применительно к компьютерным системам переход не столь революционен — новый мир скорее «менее детерминированный»). Старый ИТ-мир был построен на вполне естественных «ньютоновских» предположениях о том, что все события происходят последовательно, каждое в свой отведенный ему момент. Было хорошо известно, что и в какой очередности случается, было известно и то, какие функции и в какой момент времени потребуются, наконец, вся обработка происходила на одной физической (или, в крайнем случае, виртуальной) машине.

Новый, менее детерминированный мир имеет ряд отличий.

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

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

●     Объекты и явления могут быть представлены более сложными формами, которые называют онтологиями.

●     Объектами обработки могут быть транзакции, выполняемые через Internet, в нем необходимо поддерживать системы, обеспечивающие сложные B2B-взаимодействия, одноранговые (peer-to-peer) коммуникации, процессы, происходящие в реальном времени.

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

Путь к пониманию SOA как универсальной инфраструктурной основы нового типа был и остается чрезвычайно сложным. Начало было положено Web-сервисами; первоначально архитектура SOA отождествлялась только лишь с совокупностью стандартов и технологий SOAP, UDDI, WSDL и др. Довольно долго не удавалось отделить приставку Web от сервисов, но в конце концов удалось. Одну из самых интересных попыток переосмысления происходящего на протяжении последних нескольких лет можно найти в интервью, данном известным специалистом в области программного обеспечения промежуточного слоя, сотрудником Oracle Дэниэлом Сeрейном [3]. Представление о SOA двух-трехлетней давности отражено в работе [4]. Несмотря на разнообразие трактовок, все они, в конечном счете, сводятся к тому, что SOA представляет собой отличный инструмент интеграции приложений и служит для устранения зазора между бизнесом и ИТ. Развитием этих взглядов стали работы [5] и [6], связывающие SOA с корпоративной архитектурой (Enterprise Architecture). Полноценный профессиональный анализ SOA в контексте интеграции можно найти в отчете, подготовленном Национальным институтом здоровья США [7], а также в чрезвычайно содержательной работе группы европейских исследователей [8].

Особое внимание стоит обратить на свободно распространяемую интеграционную платформу Mule (mule.mulesource.org), содержащую необходимые программные продукты и документацию для создания работоспособной системы на принципах SOA с использованием сервисной шины предприятия (Enterprise Service Bus, ESB).

И вот, когда все вроде бы стало как-то укладываться в общую концепцию, сводящую SOA к интеграции приложений и бизнес-процессов, объявилась еще одна, родственная SOA инициатива. И на этот раз в роли возмутителей спокойствия, как обычно, выступили аналитики. Среди них на первое место следовало бы поставить представителей Gartner Роя Шульте и Ефима Натиса; в 2003 году они опубликовали целый ряд документов, где предложили на суд ИТ-общественности очередную «фишку», именно ими названную EDA. Подобные «вбросы» замечательны тем, что аналитики совершенно необъяснимым образом, каким-то боковым зрением, улавливают актуальность того, что они предлагают, сами должным образом не понимая сути. Шульте и Натис «заняли термин», и другим стало обидно. Их весьма известный коллега Джейсон Блумберг из компании ZapThink ответил броским материалом SOA + EDA = FUD? Обсуждение перипетий, возникших в связи с первым появлением EDA, можно найти в работах [9, 10].

Нынешним летом в «гонку определений» вступила Oracle. Вице-президент корпорации Стив Харрис заявил: «Мы используем термин SOA 2.0 для комбинации сервис-ориентированной архитектуры и архитектуры, управляемой событиями». Натис из Gartnet с ним вполне согласен, он интерпретирует SOA 2.0 как расширение сервисной архитектуры: «SOA, как мы теперь это понимаем, имеет дело с отношениями между модулями, которые построены на принципах ‘клиент-сервер’, однако не все процессы и программные топологии можно уложить в эту модель. SOA 2.0 — это такая архитектура, где отношения между модулями не столь детерминированы, где имеют место, как в бизнесе, асинхронные обращения, стимулированные внешними или внутренними обстоятельствами». В ответ на инициативу по адресу www.mwdadvisors.com/resources/stop-the-madness.php была опубликована петиция своего рода «движения сопротивления», там же организован сбор подписей против термина SOA 2.0. 

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

Вне зависимости от технологий, которыми реализуются сервисы (Web, REST, RPC…), любой из них — это лишь некоторый абстрактный ресурс, имеющий имя, способный выполнять какую-то работу на основании получаемой им контактной информации, заключенной в сообщении, причем выполнять ее на заданном уровне безопасности и по определенным правилам. (Стоит напомнить, сорвав покров таинственности с самого слова «сервис», что основные значения английского слова service — «служба», «занятие», «работа».) Для того чтобы использовать сервис, ему надо тем или иным образом послать сообщение с контактной информацией, желательно также получить от него подтверждение о приеме. Предполагается, что сервис может выполнить какое-то одно действие, связанное с бизнесом (business concept), одну функцию или один компонент процесса. Искусство архитектора информационной системы состоит в определении области действия сервиса (bound of a service). По окончании своей работы сервис может вызвать другой сервис (такое отношение сервисов называют «коллаборацией»).

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

Сервисная ориентация отличается тем, что между модулями нет единожды и навсегда установленной жесткой связанности, она заменяется легко изменяемой слабой связанностью компонентов (loose coupling). Чтобы отличить такую организацию от более привычной, ее модули и стали называть сервисами, то есть устройствами, способными выполнять работу по заказу. Еще одно существенное отличие состоит в том, что в дополнение к обычным данным сервис еще получает метаданные, то есть вспомогательные данные, сопровождающие данные. Вызывающий или обращающийся за сервисом модуль знает, как осуществить вызов и какая работа будет выполнена, а вызываемый, используя метаданные и данные, может выполнить заказ на обслуживание.

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

Насколько динамично и под влиянием каких факторов может происходить такое перепрограммирование? Простая интеграция приложений, в конечном счете, сводится к тому, что автомат программируется вручную; если появляются новые модули или новые функции, происходит то же самое. Характерным примером такого рода интеграции могут служить композитные приложения (composite application). По мере необходимости пользователь включает в работу один или несколько сервисов, такие сервисы обычно синхронны, относятся к одной области бизнеса. Типичная сфера применения данного подхода — порталы.

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

Если же архитектура способна воспринимать еще и события из внешней среды, то ее называют управляемой событиями (event-driven). По сравнению с обычной интеграционной средой SOA, где события имеют последовательный и предсказуемый характер, EDA допускает множественные менее предсказуемые асинхронные потоки событий. Из общего потока событий, происходящих как внутри бизнеса, так и вне него, выделяют значимые (notable) события и направляют по адресам рассылки.

События и EDA

Поступающие в систему сообщения о событиях распространяются по списку, их получателей называют подписчиками (subscriber); в качестве подписчика может выступать автомат или человек. Каждое такое сообщение имеет заголовок (header) и тело (event body) В заголовок входят относящиеся к событию метаданные, в том числе: идентификатор спецификации события, указатель типа, имя события, отметка времени и источник. Тело события содержит описание того, что случилось (собственно события). Тело должно быть достаточно содержательным, чтобы получатель мог, пользуясь предоставленными данными, предпринимать какие-то действия, не делая дополнительных запросов. Чтобы суть события была понятна подписчику, тело должно содержать описание, подготовленное на принятом в бизнесе языке, или полную онтологию.

В архитектуре, управляемой событиями, сообщение о последнем распространяется между подписчиками, которые тем или иным образом на него реагируют; это может быть вызов какого-то определенного сервиса, перестройка бизнес-процесса или дальнейшее распространение сведений о событии, в том числе дополнительных. Такая архитектура является не просто слабо связанной, а очень слабосвязанной (extreme loose coupling) и распределенной. Источник или создатель сообщения знает лишь то, что сообщение передано, но никак не участвует в его дальнейшей судьбе. Вообще проследить траекторию отработки сообщения в условиях, когда оно распространяется по подписке, чрезвычайно сложно. Поэтому в EDA предполагается наличие асинхронных потоков работ и входных данных.

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

В первом случае осуществляется простая обработка событий (simple event processing); она предполагает прямую передачу событий из входного потока в процессор обработки событий. Во втором случае, при потоковой обработке событий (stream event processing), единичные события сначала поступают в генератор, где из них путем фильтрации или иной предварительной обработки формируются значимые события, которые затем передаются в процессор событий. Третий случай, обработка сложных событий (complex event processing), отличается тем, что единичные события не являются однородными, она включает фильтрацию, разнообразные статистические методы. Можно сказать, это целое научное направление, основоположником которого считается профессор Дэвид Лукхэм [11].

Система, построенная по архитектуре EDA, должна включать четыре основных компонента.

●     Генератор событий (event generator). Обладает функциональностью, зависящей от стиля обработки событий; задача этого компонента — первичная обработка, выделение из входного потока значимых событий.

●     Канал событий (event channel). Служит внутренней магистралью, которая обеспечивает транспортировку значимых событий из генератора в процессор.

●     Процессор событий (event processor). Оценивает полученные события, соотносит их с имеющимися правилами обработки, вырабатывает необходимые решения, в том числе запуск тех или иных сервисов и бизнес-процессов, направляет сообщения подписчикам, осуществляет прямые рассылки сведений о событиях и архивирование.

●     Управление последующими событиями (downstream event-driven activity). Одно вводное событие может потребовать выполнения целого комплекса последующих действий, поэтому нужны соответствующие средства для управления.

В простейшем случае SOA служит механизмом для передачи запросов к сервисам, а в более сложных — для асинхронной обработки событий. Поэтому, говоря EDA, стоит подразумевать не event driven architecture, а event-driven SOA, то есть «сервис-ориентированную архитектуру, управляемую событиями».

Для «материализации» идей EDA может быть использовано хорошо известное архитектурное решение — сервисная шина предприятия [11]. В большинстве известных реализаций ESB сочетает в себе возможности как сервис-ориентированного, так и стимулированного данными подходов к распространению потока работ, являясь своего рода мостом между разнородными платформами и средами. Шина ESB соответствует характеристикам, приведенным в таблице, она выполняет функцию промежуточного слоя между различными прикладными процессами, поэтому сервис, включенный в систему ее средствами, может быть с равным успехом запущен и клиентом и событием. Шину ESB удобно рассматривать как своего рода архитектурный шаблон, который может быть реализован различными программными продуктами, в том числе IBM WebSphere ESB или Sonic ESB компании Progress Software. Стоит также обратить внимание на свободно распространяемую шину Mule [13].

Влияние идей программных систем, управляемых событиями, далеко не ограничивается SOA; оно может затронуть глубинные основы программирования. В связи с этим особый интерес представляет статья программного архитектора компании Google Грегора Хопе [14].

Литература

●     Леонид Черняк, BPM: близкие перспективы и далекие горизонты. // Открытые системы, 2004, № 11.

●     Tom Gruber, What is an Ontology? www.ksl.stanford.edu/kst/what-is-an-ontology.html

●     Леонид Черняк, Поход за Чашей Грааля информационных технологий. // Открытые системы, 2006, № 1.

●     Леонид Черняк, SOA — шаг за горизонт. «Открытые системы», 2003, № 9.

●     Леонид Черняк, Говорим SOA, подразумеваем EA. // Открытые системы, 2005, № 4.

●     Леонид Черняк, Общая шина предприятия. // Открытые системы, 2003, № 4.

●     NIH Enterprise Architecture. Application Integration — Technology Architecture, Version 1.0, 26 July 2004.

●     Michael Papazoglou et al, Service-Oriented Computing Research Roadmap. drops.dagstuhl.de/opus/volltexte/2006/524/pdf/05462.SWM.Paper.524.pdf

●     Леонид Черняк, SOA + EDA = RTE. Computerworld Россия, 2005, № 5.

●     Леонид Черняк, EDA — архитектура, управляемая событиями. // Открытые системы, 2005, № 2.

●     Леонид Черняк, Сложные события и мониторинг бизнеса. «Открытые системы», 2005, №2.

●     Леонид Черняк, От экстрима до мэйнстрима — один шаг. // Открытые системы, 2003, № 5.

●     Jeff Hanson, Event-driven services in SOA, Design an event-driven and service-oriented platform with Mule. JavaWorld, January 2005.

●     Gregor Hohpe, Programming Without a Call Stack — Event-driven Architectures. www.enterpriseintegrationpatterns.com/docs/EDA.pdf