В среде JVM доступны три инфраструктуры интеграции, которые отвечают этим требованиям: Spring Integration, Mule ESB и Apache Camel . Они реализуют хорошо известные шаблоны интеграции Enteprise (EIP, http://www.eaipatterns.com ) и поэтому предлагают стандартизированный, предметно-ориентированный язык для интеграции приложений.
Эти интеграционные инфраструктуры могут использоваться практически в каждом интеграционном проекте в среде JVM — независимо от того, какие технологии, транспортные протоколы или форматы данных используются. Все интеграционные проекты могут быть реализованы согласованным образом без избыточного стандартного кода.
В этой статье сравниваются все три альтернативы и обсуждаются их плюсы и минусы. Если вы хотите знать, когда использовать более мощную Enterprise Service Bus (ESB) вместо одной из этих облегченных интеграционных сред, то вам следует прочитать этот пост в блоге: http://www.kai-waehner.de/blog/2011 / 06/02 / when-to-use-apache-camel / (объясняется, когда использовать Apache Camel, но заголовок также может быть «Когда использовать облегченную интеграционную среду»).
Критерии сравнения
Несколько критериев могут быть использованы для сравнения этих трех интеграционных структур:
- Открытый исходный код
- Основные понятия / архитектура
- способность быть свидетелем в суде
- развертывание
- популярность
- Коммерческая поддержка
- IDE-поддержка
- Обработка ошибок
- Мониторинг
- Готовность предприятия
- Домен-специфический язык (DSL)
- Количество компонентов для интерфейсов, технологий и протоколов
- Расширяемость
сходства
Все три структуры имеют много общего. Поэтому многие из приведенных выше критериев сравнения являются четными! Все они реализуют EIP и предлагают согласованную модель и архитектуру обмена сообщениями для интеграции нескольких технологий . Независимо от того, какие технологии вы должны использовать, вы всегда делаете это одинаково, то есть один и тот же синтаксис, один и тот же API, одни и те же автоматические тесты. Единственным отличием является конфигурация каждой конечной точки (например, JMS требуется имя очереди, а JDBC — URL-адрес подключения к базе данных). ИМО, это самая значимая особенность. Каждый фреймворк использует разные имена, но идея одна и та же. Например, «верблюжьи маршруты» эквивалентны «потокам мула», «верблюжьи компоненты» называются «адаптерами» в Spring Integration.
Кроме того, существует несколько других сходств, которые отличаются от тяжелых ESB. Вам просто нужно добавить несколько библиотек в ваш путь к классам. Следовательно, вы можете использовать каждый фреймворк везде в среде JVM. Неважно, является ли ваш проект автономным приложением Java SE или вы хотите развернуть его в веб-контейнере (например, Tomcat), сервере приложений JEE (например, Glassfish), контейнере OSGi или даже в облаке. Просто добавьте библиотеки, выполните простую настройку, и все готово. Затем вы можете приступить к реализации ваших компонентов интеграции (маршрутизация, преобразование и т. Д.).
Все три платформы имеют открытый исходный код и предлагают знакомые, общедоступные функции, такие как исходный код, форумы, списки рассылки, отслеживание проблем и голосование за новые функции. Хорошие сообщества пишут документацию, блоги и учебные пособия (наиболее заметное сообщество имеет IMO Apache Camel). Только количество выпущенных книг могло бы быть лучше для всех трех. Коммерческая поддержка доступна от разных поставщиков:
- Spring Integration: SpringSource ( http://www.springsource.com )
- Mule ESB: MuleSoft ( http://www.mulesoft.org )
- Apache Camel: FuseSource ( http://fusesource.com ) и Talend ( http://www.talend.com )
Поддержка IDE очень хорошая, даже визуальные дизайнеры доступны для всех трех альтернатив задачам интеграции моделей (и позволяют им генерировать код). Каждая из этих платформ готова для предприятия, потому что все предлагают необходимые функции, такие как обработка ошибок, автоматическое тестирование, транзакции, многопоточность, масштабируемость и мониторинг.
Различия
Если вы знаете одну из этих структур, вы можете легко изучить другие из-за их одинаковых концепций и многих других сходств. Далее, давайте обсудим их различия, чтобы иметь возможность решить, когда использовать какой. Двумя наиболее важными отличиями являются количество поддерживаемых технологий и используемых DSL. Таким образом, я сосредоточусь особенно на этих двух критериях в следующем. Я буду использовать фрагменты кода, реализующие известный EIP «Content-based Router» во всех примерах. Судите сами, какой из них вы предпочитаете.
Весенняя интеграция
Spring Integration основана на известном проекте Spring и расширяет модель программирования за счет поддержки интеграции. Вы можете использовать такие функции Spring, как внедрение зависимостей, транзакции или безопасность, как и в других проектах Spring.
Spring Integration — это круто, если у вас уже есть проект Spring и вам нужно добавить кое-что для интеграции. Практически без усилий изучить Spring Integration, если вы знаете саму Spring. Тем не менее, Spring Integration предлагает только очень простую поддержку технологий — просто «базовые вещи», такие как File, FTP, JMS, TCP, HTTP или Web Services. Mule и Apache Camel предлагают множество дополнительных компонентов!
Интеграции реализуются путем написания большого количества XML-кода (без реального DSL), как вы можете видеть в следующем фрагменте кода:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<file:inbound-channel-adapter id=”incomingOrders” directory=”file:incomingOrders”/><payload-type-router input-channel=”incomingOrders”> <mapping type=”com.kw.DvdOrder” channel=”dvdOrders” /> <mapping type=”com.kw.VideogameOrder” channel=”videogameOrders” /> <mapping type=”com.kw.OtherOrder” channel=”otherOrders” /></payload-type-router><file:outbound-channel-adapter id=”dvdOrders” directory=”dvdOrders”/><jms:outbound-channel-adapter id=”videogamesOrders” destination=”videogameOrdersQueue” channel=”videogamesOrders”/><logging-channel-adapter id=”otherOrders” level=”INFO”/> |
Вы также можете использовать Java-код и аннотации для некоторых вещей, но, в конце концов, вам нужно много XML. Честно говоря, я не очень люблю декларации XML. Это хорошо для конфигурации (например, фабрики соединений JMS), но не для сложной логики интеграции. По крайней мере, это должен быть DSL с лучшей читабельностью, но более сложные примеры Spring Integration действительно сложны для чтения.
Кроме того, визуальный дизайнер для Eclipse (называемый графом интеграции) в порядке, но не так хорош и интуитивно понятен, как его конкуренты. Поэтому я бы использовал Spring Integration только в том случае, если у меня уже есть существующий проект Spring, и мне нужно просто добавить некоторую логику интеграции, требующую только «базовых технологий», таких как File, FTP, JMS или JDBC.
Мул ESB
Mule ESB — это, как следует из названия, полный ESB, включающий несколько дополнительных функций, а не просто интегрированную инфраструктуру (вы можете сравнить его с Apache ServiceMix, который является ESB на основе Apache Camel). Тем не менее, Mule можно использовать и как легкую интеграционную среду, просто не добавляя и не используя никаких дополнительных функций, кроме EIP. Что касается Spring Integration, Mule предлагает только XML DSL. По крайней мере, по моему мнению, читать намного проще, чем Spring Integration. Mule Studio предлагает очень хороший и интуитивно понятный визуальный дизайнер. Сравните следующий фрагмент кода с кодом интеграции Spring выше. Это больше похоже на DSL, чем на Spring Integration. Это имеет значение, если логика интеграции более сложна.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
<flow name=”muleFlow”> <file:inbound-endpoint path=”incomingOrders”/> <choice> <when expression=”payload instanceof com.kw.DvdOrder” evaluator=”groovy”> <file:outbound-endpoint path=”incoming/dvdOrders”/> </when> <when expression=”payload instanceof com.kw.DvdOrder” evaluator=”groovy”> <jms:outbound-endpoint queue=”videogameOrdersQueue”/> </when> <otherwise> <logger level=”INFO”/> </otherwise> </choice></flow> |
Основным преимуществом Mule являются некоторые очень интересные разъемы для важных фирменных интерфейсов, таких как SAP, Tibco Rendevous, Oracle Siebel CRM, Paypal или IBM CICS Transaction Gateway . Если вашему интеграционному проекту требуются некоторые из этих разъемов, я бы, наверное, выбрал Mule!
Недостатком некоторых проектов может быть то, что Мул говорит «нет» OSGi: http://blogs.mulesoft.org/osgi-no-thanks/
Apache Camel
Apache Camel практически идентичен Mule. Он предлагает множество компонентов (даже больше, чем Mule) практически для каждой технологии, о которой вы только могли подумать. Если нет доступных компонентов, вы можете легко создать свой собственный компонент, начиная с архетипа Maven! Если вы парень из Spring: у Camel также отличная интеграция с Spring. Как и два других, он предлагает XML DSL:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
<route> <from uri=”file:incomingOrders”/> <choice> <when> <simple>${in.header.type} is ‘com.kw.DvdOrder’</simple> <to uri=”file:incoming/dvdOrders”/> </when> <when> <simple>${in.header.type} is ‘com.kw.VideogameOrder’ </simple> <to uri=”jms:videogameOrdersQueue”/> </when> <otherwise> <to uri=”log:OtherOrders”/> </otherwise> </choice> </route> |
Читаемость лучше, чем у Spring Integration и почти идентична Mule. Кроме того, FuseSource предоставляет очень хороший (но коммерческий) визуальный дизайнер Fuse IDE, который генерирует код XML DSL. Тем не менее, это много XML, независимо от того, используете ли вы визуальный дизайнер или только ваш XML-редактор. Лично мне это не нравится.
Поэтому давайте покажем вам еще одну замечательную функцию: Apache Camel также предлагает DSL для Java, Groovy и Scala . Вам не нужно писать столько ужасных XML. Лично я предпочитаю использовать один из этих быстрых DSL вместо XML для логики интеграции. Я занимаюсь только настройками, такими как фабрики соединений JMS или свойства JDBC, используя XML. Здесь вы можете увидеть тот же пример, используя фрагмент кода Java DSL:
|
1
2
3
4
5
6
7
8
|
from(“file:incomingOrders “) .choice() .when(body().isInstanceOf(com.kw.DvdOrder.class)) .to(“file:incoming/dvdOrders”) .when(body().isInstanceOf(com.kw.VideogameOrder.class)) .to(“jms:videogameOrdersQueue “) .otherwise() .to(“mock:OtherOrders “); |
Свободно читаемые DSL программирования (даже в более сложных примерах). Кроме того, эти программные DSL имеют лучшую поддержку IDE, чем XML (завершение кода, рефакторинг и т. Д.). Из-за этих потрясающих быстрых DSL я всегда использовал бы Apache Camel, если бы мне не нужны были некоторые из превосходных разъемов Mule для проприетарных продуктов. Из-за его очень хорошей интеграции с Spring, я бы даже предпочел Apache Camel вместо Spring Integration в большинстве случаев.
Кстати, Talend предлагает визуальный дизайнер, генерирующий код Java DSL, но он генерирует много стандартного кода и не позволяет редактировать наоборот (т.е. вы не можете редактировать сгенерированный код). Это запретный критерий и должен быть исправлен в ближайшее время (надеюсь)!
И победителем становится…
… Все три интеграционных каркаса, потому что все они легки и просты в использовании — даже для сложных интеграционных проектов. Замечательно интегрировать несколько разных технологий, всегда используя один и тот же синтаксис и концепции, включая очень хорошую поддержку тестирования.
Мой личный фаворит — Apache Camel из-за его потрясающих Java, Groovy и Scala DSL в сочетании со многими поддерживаемыми технологиями. Я бы использовал Mule только в том случае, если мне нужны некоторые из его уникальных разъемов для проприетарных продуктов. Я бы использовал Spring Integration только в существующем проекте Spring, и мне нужно было бы интегрировать «базовые технологии», такие как FTP или JMS. Тем не менее: независимо от того, какую из этих облегченных интеграционных сред вы выберете, вам будет очень весело реализовывать сложные интеграционные проекты с минимальными усилиями. Помните: часто толстый ESB имеет слишком много функциональности и, следовательно, слишком много ненужной сложности и усилий. Используйте правильный инструмент для правильной работы!
Ссылка: Избранный для выбора: какую интеграционную платформу использовать — Spring Integration, Mule ESB или Apache Camel? от нашего партнера JCG Кай Ванер (Kai Wahner) из блога о блоге Java EE / SOA / Cloud Computing .