Исследование ESB-систем

Ссылки сюда (1) →

В данной статье будет накапливаться опыт в исследовании и использовании различных ESB-систем.

Enterprise Service Bus (сервисная шина предприятия) — подход к построению распределённых корпоративных информационных систем. Архитектура ESB заключается во взаимодействии всех приложений через единую точку, которая, при необходимости, обеспечивает транзакции, преобразование данных, сохранность обращений. Данный подход обеспечивает большую гибкость, простоту масштабирования и переноса. При замене одного приложения, подключенного к шине, нет необходимости перенастраивать остальные.

Обзор различных ESB

Рассматриваются следующие ESB-системы.

Sun OpenESB v2

Он же — Glassfish ESB;

Старая (2009 год) версия OpenESB.

Сервер приложений

Glassfish — свободная версия Sun Java Application Server;

Маршруты

• Чистый JBI (Java Business Integration), жёсткая маршрутизация. Невозможен, например, «прозрачный» аудит всех сообщений без явного встраивания аудитора в каждый маршрут;
• Поддержка BPEL (Business Process Execution Language), удобный визуальный редактор «бизнес-процессов», встроенный в NetBeans;
• Точки связи задаются с помощью WSDL (Web Service Definition Language). Компонентов хватает, их 43, хотя не все из них находятся в стабильном состоянии;
• Есть поддержка Persistence для BPEL движка, хотя влезть «внутрь» него и увидеть сам Message Router, который внутри, невозможно, как невозможно и заставить его использовать внешний Message Router (к примеру, JMS);

IDE

Плотная и удобная интеграция с NetBeans;

Производительность

• Приличная производительность — 25000 запросов в минуту в простом приложении с SOAP-адаптером и XSLT-преобразованием, есть поддержка работы на кластере из Стеклорыбов (Glassfish’ей);
• На тестовом примере (см.ниже) производительность приблизительно 32.77 файла в секунду;

OpenESB SE (3.0.5)

Актуальная стабильная версия OpenESB.

После покупки Sun’а Oracle’ом доработка OpenESB, дабы он не конкурировал с Oracle SOA Suite, ораклом была прекращена и проект был передан в руки сообщества.

С тех пор случилось несколько стабильных релизов, но изменений было не очень много. Основные изменения:

• OpenESB перестало основываться на Glassfish’е и появилась Standalone версия (содержащая урезанный HTTP-контейнер Grizzly).
• NetBeans стал поставляться в готовом виде с полным набором предустановленных компонентов, под названием OpenESB Studio.
• Появилась новая симпатичная веб-консоль управления OpenESB Console.

Остальные изменения в основном являются следствием перехода от Glassfish к SE:

• По отзывам компаний, использующих OpenESB в продакшне, за счёт легковесности SE чуть ли не в 2 раза выросла производительность и снизилось потребление ресурсов. Стартовать сервер стал тоже гораздо быстрее.
• BPEL Monitor не был портирован с Glassfish и перестал поставляться в комплекте. Исходники его, однако, остались на месте, и при желании его наверняка можно завести.
• Стало невозможно добавлять JDBC pool’ы из консоли управления — теперь их приходится заранее прописывать в конфигурации.
• Не факт, что это было возможно в OpenESB 2.x (досконально не проверял), но в SE, похоже, нет возможности детально разграничивать права администраторов — администратор один и имеет доступ ко всем функциям консоли.

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

По поводу возможностей дать Read-Only доступ — мысли следующие:

• Чтобы мог отлаживать из среды, но не мог деплоить — видимо не получится, так как Debug BPEL вначале делает Deploy, то есть если отобрать право деплоя, то и дебаг не удастся.
• Чтобы мог смотреть OpenESB Console, но не мог ничего там менять — такой фичи, к сожалению, готовой нет, хотя есть невлитый патч (Pull Request) вот тут: https://bitbucket.org/openesb/openesb-web-console/pull-requests/1/add-rouser-condition/diff (то есть с минимальной доработкой можно).
• Чтобы мог смотреть, скажем, только логи — тоже сходу не удастся, так как возможности смотреть логи онлайн в OpenESB Console нет. Ну, к файлам логов можно доступ как-то отдельно дать, конечно.
• Чтобы мог только смотреть статистику по выполняющимся BPEL процессам — это можно средствами СУБД, дать ридонли доступ к БД BPEL Persistence.
• Чтобы мог подключаться BPEL монитором и тоже не мог ничего менять — в случае с тем консольным монитором не получится, так как там через JMX админский доступ позволяет вмешиваться в работу процессов; если же какой-то BPEL монитор (скажем, вебовый) ходит не через JMX, а через БД, тогда наверное можно тоже правами порулить.

Sun Fuji

Warning: Труп. Задумывался Sun’ом как преемник OpenESB, в 2009 году находился в «активной фазе» разработки и был сыроват, а после поглощения Sun’а загнулся совсем и перестал существовать.

Сервер приложений

может запускаться из-под

• Apache Felix'а,
• Equinox'а (зло),
• Glassfish’а (начиная с Milestone 6).

Первые два — означают фактически standalone, так как Felix/Equinox весят где-то по 300 кб каждый;

Система сборки

В качестве системы сборки используется Maven2;

Маршруты

• Есть поддержка JBI;
• OSGi (Open Services Gateway Initiative) используется в качестве «среды выполнения»;
• Гибкая маршрутизация — есть возможность добавления различных Interceptor’ов (перехватчиков сообщений) и т. п.;
• Язык описания маршрутов — IFL (Integration Flow Language). Довольно простой и тупой. Это, кстати, создаёт некоторые проблемы, например, при преобразовании из текста в XML, так как недоступен BPEL Mapper;
• Есть поддержка BPEL в виде отдельного компонента, однако:

Шаблон:Caution На момент 22.05.2009 компонент BPEL ещё сырой и не очень юзабельный;

IDE

Гламурный и довольно удобный веб-редактор схем интеграции на JavaScript’е (AJAX’е)

;

Компоненты

немного, а стабильных ещё меньше. Есть определённые новые по сравнению с OpenESB, но довольно извращённые, компоненты, вроде JRuby — можно встраивать в схему интеграции скрипты на Ruby, причём документации по тому, как их писать, не существует. Однако, например, для преобразования из текста в XML другого пути нет;

Производительность

• Замеров производительности не найдено;

Шаблон:Caution Реализация тестового примера не удалась (см.ниже). Fuji очень сырой. Не используем.

Apache ServiceMix v3, v4

Старые версии (до 2009).

Сервер приложений

Standalone, Apache Felix (OSGi);

Система сборки — Maven2;

IDE

никакого визуального редактора схем интеграции нет;

Маршруты

• Поддержки BPEL и WSDL самой по себе нет, однако теоретически, внутрь ServiceMix можно развернуть Apache ODE, что её даст;
• Для медиации используется либо некоторый свой, достаточно слабенький, XML — язык описания, либо Camel (см.ниже);
• Поддерживаются основные EIP (Enterprise Integration Patterns) — фильтр, конвейер, контентный маршрутизатор, асинхрон, разделение, агрегация. В то же время, к примеру, прозрачный перехватчик поддерживался только начиная с 4-ой версии.

Компоненты

• Ни много, ни мало, основное: JavaBeans, Apache CXF, File / FTP / любые Apache VFS, HTTP / SOAP, JMS, Email, таймер (Quartz), XSLT (Saxon), Groovy, JS, SMPP, SNMP, XMPP, валидация по XML-схемам;
• А также из мистического: JBoss Drools, JSR181, Lightweight Containers, OS Workflow, WS-Notification;

Чем использовать ServiceMix, лучше посмотреть на FUSE v3/v4 (следующий пункт);

FUSE ESB v3/v4

Немного доработанная версия ServiceMix, имеющая коммерческую поддержку, разрабатывается теми же людьми;

IDE

есть визуальный редактор схем интеграции на основе Eclipse (и весит он 200 мб, ахтунг), ощутимо менее удобный, чем в OpenESB;

Маршруты

FUSE любит использовать Camel, что, в некотором смысле, и понятно — он довольно мощный;

Документация

она есть, однако во многих случаях её не хватает — например, в случае написания мистических «выражений» для преобразования. Справедливости ради нужно отметить, что документация — копипаст документации открытых продуктов, в том числе, того же Camel’а, и там ситуация аналогичная;

Шаблон:Caution Сыроват. Даже демо-примеры не все запускаются, о чём я им и сообщил в форуме, и результатом было, что некто seanoc признал, что это баг, и запостил в трекер;

MULE

Довольно живой продукт, есть и возможность коммерческой поддержки;

(Ещё?) не пробовали.

IDE

есть визуальный редактор на основе Eclipse;

Маршруты

Разработчики Apache Camel пишут, что MULE похож, но Camel, конечно же, лучше!, а также свободнее;

Apache Camel

Стабильная версия.

Весьма интересный продукт — нестандартный подход к ESB. Camel — это фреймворк, медиатор / язык описания схем интеграции.

Сервер приложений

может использоваться «Как Угодно»:

• Standalone;
• внутри OpenESB;
• внутри ServiceMix;
• внутри ActiveMQ;
• в любой OSGi-среде, хотя на OSGi не завязан;

IDE

• Своего визуального редактора нет. Однако, FUSE Integration Designer позволяет рисовать верблюжьи схемки. Правда, удобством он не отличается — а чего ещё ждать от Eclipse;
• Есть плагин к Maven, позволяющий генерировать на основе описаний маршрутов диаграммы;

Маршруты

• Не поддерживает JBI;
• Поддержка многих EIP (Enterprise Integration Patterns);
• Гибкая маршрутизация, перехватчики, гарантированная доставка и пр.;
• Способ связи «публикация/подписка» Camel может только в сочетании с JMS (например, OpenMQ или ActiveMQ, асинхрон ведь);
• Для описания маршрутов применяется либо Fluent API на Java — то есть, from(«…»).choice().if(…).to(…).else(…)…, либо оно же, но кодированное в XML-язык описания;
• Для описания точек связи используются URI, и параметры компонентам передаются через ?param=value&param=value и т. п. (строки запроса URI);
• Поддерживается куча скриптовых языков для задания предикатов и выражений, в том числе PHP, Python и т. п.;

Компоненты

• Очень богатый набор компонентов, не похожий, в частности, на OpenESB;
• В комплекте поставки не хватает многих библиотек-зависимостей, что создаёт проблемы с запуском

Документация

• Есть неплохая документация, тем не менее, некоторые вопросы в ней всё-таки не освещены (к примеру, «выражения» на скриптовых языках);

Производительность

• Высокая производительность благодаря простоте;
• Замер производительности на тестовом примере показал приблизительно 58.1 файлов в секунду без XSLT и 15 файлов в секунду с XSLT. Подробности см. ниже;

Представляет определённый интерес в сочетании с JMS-брокером (например, ActiveMQ или OpenMQ).

Apache Synapse

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

Стабильная версия, проект вполне живой как сейчас (2015), так и в момент прошлого тестирования (2009).

Компоненты

• HTTP, SOAP во всех инстациях, XML файлы (любые VFS через Apache’вский интерфейс), POJO, Database, JMS, Email, FIX (Financial Information eXchange), HL7 (протоколы медицинских систем учёта), Hessian, AMQP;
• Для работы с plaintext файлами нужен дополнительный компонент, не входящий в базовую поставку;
• На входе: HTTP/HTTPS/File/JMS/HL7/Kafka/CXF WS-RM/MQTT/RabbitMQ + можно подключить собственную реализацию;
• Поддерживаются WS-Штуки: WSDL :-) WS-Addressing, WS-Security, WS-Reliable Messaging;
• XSLT, XQuery, Validate (валидация по XML схемам);
• Throttle, Cache;
• EIP: Clone, Iterate, Aggregate;

IDE

нет;

Маршруты

• JBI нет, BPEL нет;
• «Переменных» нет, всё время обрабатывается одно и то же XML сообщение, по пути просто трансформируемое XSLT/XQuery. Последовательность обработчиков («медиаторов») называется Sequence.

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

• Логика маршрутизации разнообразная, но странноватая — всё описывается либо как Inbound Endpoint + Sequence, либо Proxy (две Endpoint — входная и выходная и две Sequence — от входа к выходу и обратно), либо Message Processor (по сути — Sequence, читающий из персистентного Message Store и поддерживающий QoS), либо Scheduled Task (по сути — просто регулярная инициация сообщений по таймеру).
• Прозрачной надёжной маршрутизации нет, чтобы её реализовать, нужно явно создать JMS Message Store, а процесс обернуть в Message Processor. То есть, если просто взять и сделать либо Proxy, либо Inbound Endpoint + Sequence, надёжной доставки не будет!
• Есть развитый механизм конфигурации («реестры»), через которые можно конфигурировать многое — например, как endpoint’ы, так и XSLT.

Производительность

заявлена «немереная» засчёт простоты;

Сервер приложений

любая OSGi среда (Felix/Equinox). Всё равно самопал :-) типа, ещё один Camel;

Сам по себе не очень интересен именно из-за простоты и отсутствия инструментария, но лежит в основе WSO2 ESB.

WSO2 ESB

Стабильная версия. Open-source ESB на основе Apache Synapse с возможностью коммерческой поддержки (код свободный, использование бесплатное, лицензия Apache License 2.0).

В комплект поставки также входят Apache Axis2 (можно разворачивать веб-сервисы прямо внутри ESB), Apache Qpid (JMS/AMQP очередь сообщений), Java СУБД H2 и собственная веб-консоль управления всем этим добром.

Компоненты

• В целом все те же, что и в Synapse. См. выше.
• Есть «магазин компонентов» (https://store.wso2.com/store/), на момент 30.09.2015 в нём 114 компонентов. Однако полезного среди них мало, в основном всякие инстаграмы, фейсбуки и твиттеры. Из полезного разве что Paypal, Apple Push, а также адаптеры к сервисам амазона и к некоторым CRM’кам.

Маршруты

• В целом все те же, что в Synapse, описываются в той же Synapse-нотации (sequence, proxy, message store, message processor), и имеют точно те же ограничения.
• BPEL выделен в отдельный продукт — WSO2 Business Process Server (видимо, на основе Apache ODE). Пример статьи о том, как его можно прикрутить к WSO2 ESB.
• У WSO2 есть собственные фреймворки/библиотеки для создания SOAP веб-сервисов на разных языках — Java, C, C++, PHP, Perl, Python, Ruby, Spring, Jython и т. п. Однако сейчас (2015) на сайте написано, что как минимум часть из них поддерживаться больше не будет. Собственно, логично, так как смысл существования этих библиотек не очень понятен.

Документация

• Она есть и в целом неплохая, хотя местами и не идеальная (примеры описаны как-то так: возьмите вот этот XML и суньте в ESB, опа! вот и пример).

IDE

• Почти всё можно делать через веб-консоль — создавать endpoint’ы, sequence’ы и так далее. Это во многом даже удобнее IDE, потому что визуальный редактор тех же Sequence’ов в ней довольно неудобный.
• Статистика и мониторинг интеграционных процессов в веб-консоли присутствуют.
• Есть IDE на основе Eclipse, называется WSO2 Developer Studio. Поддерживает как WSO2 ESB, так и WSO2 Business Process Server и графическое редактирование как BPEL’а, так и Synapse’овской нотации.
• В WSO2 Business Process Server также есть веб-консоль, поддерживающая просмотр и управление самими экземплярами BPEL процессов.

IBM WebSphere ESB и IBM WebSphere Message Broker

Стабильная Ынтерпрайз версия.

Рассматриваем в роли коммерческого «образца подражания», пробуем потихоньку посмотреть, чтобы посмотреть, на кого же равняться-то, какие фичи нужны?

WebSphere Message Broker

Из нетривиального: WS MB — это не очередь сообщений, а ESB-шка, более мощная, чем WS ESB, сделанная на основе очереди сообщений (WebSphere MQ). Прошлое название MQSI — MQSeries Integrator;

Сервер приложений

• Требует DB2 или Oracle в качестве базы;
• Standalone: отдельно DB2, отдельно MQ, отдельно MB, всё очень многопроцессное;
• Установка тяжеловесная до ужаса: DB2 500 мб + WSMQ 500 мб + WSMB 230 мб;

IDE

• Гвоздь программы: Message Broker Toolkit (среда разработки под MB на основе опять-таки Eclipse) — 1700 мб (!)
  
  ;
• На основе Eclipse. Не так хорош, как хотелось бы. Имеет различные баги;
• Интегрируется с Rational ClearCase :-! ;

Документация

• Она есть и весьма подробная.

Маршруты

• BPEL’а нет, за BPEL у IBM отвечает Process Server;
• По первым прикидкам гибкости и возможностей меньше чем у Camel’а. Примерно так же как у OpenESB. Есть EIP: Filter, Aggregate, Collector, Content-Based Router реализуется. По возможности реализации Interceptor’а (прозрачного перехватчика) данных не найдено. Склоняюсь к тому, что не реализуется;
• Заявлена поддержка распределённости и резервирования;
• Куча велосипедов! Своя Java (IBM JDK 5.0), все свои языки описаний, примеры:
  • Некий свой XML-язык описания наборов сообщений *.mset (расположения схем стоят ibm.com/msgmodel);
  • Странное поведение среды разработки, которая поддерживает отдельные файлы *.mxsd для описания самих сообщений, которые вроде-бы, всё-таки являются обычным XSD (все фичи не проверял, точно сказать не могу);
  • Дополнительно MRM и TDS форматы передачи сообщений (ссылка);
  • Дополнительно свой XML-язык описания Message Mappings;
  • Аналогично свой XML-язык описания Message Flows;
  • Все эти XML-языки, разумеется, абсолютно нередактируемые и перегруженные :-);
  • WSDL для описания служб поддерживается (хоть что-то стандартное);
  • К ESQL относилась фраза «даже есть своё что-то типа селект билдера :), очередное изобретение для абстрагирования от SQL», хотя ESQL служит скорее для расширения SQL для работы с сообщениями. Насколько я понял, можно использовать для преобразования сообщений вместо Message Flows;

Производительность

• Performance Reports. Однако, прикинуть по ним результирующую производительность весьма нетривиально, так как указана производительность отдельных действий;

Компоненты — набор компонентов довольно небогатый

• Основной набор: WS MQ, JMS, HTTP, SOAP (умеет WS-Security и WS-Addressing), XSLT, Mapping, PHP, Database, File, FTP, Email (отправка), IMS, Timer;
• И из мистического: PeopleSoft, SAP, Siebel, TwineBall, SCADA (в первые 3 может интегрироваться, аки Camel в OpenESB);
• Ссылка на документацию;

Описание тестового примера

В качестве тестового примера:

• Опрашиваем заданную директорию на предмет наличия новых файлов;
• Читаем из файла число;
• Архивируем файл в другую директорию;
• Оборачиваем число в SOAP-запрос, отправляем его в SOAP сервис, получаем ответ — квадрат числа;
• Записываем в базу: имя файла из которого прочитано число, исходное число, полученный квадрат.

http://www.predic8.com/openesb-servicemix-comparison.htm