Когда использовать Spring Integration против Camel?

Как опытный пользователь Spring, я предполагал, что Spring Integration будет наиболее целесообразным в недавнем проекте, требующем некоторых (JMS) возможностей обмена сообщениями ( более подробно ). После нескольких дней работы с Spring Integration все еще ощущается большая нагрузка на конфигурацию, учитывая количество каналов, которые вы должны сконфигурировать, чтобы обеспечить связь между запросом-ответом (прослушивание разных очередей JMS).

Поэтому я искал некоторую справочную информацию о том, чем Camel отличается от Spring Integration, но кажется, что информация там довольно скудная, я обнаружил:

• http://java.dzone.com/articles/spring-integration-and-apache (очень нейтральное сравнение между реализацией сценария интеграции в реальном мире в Spring Integration vs. Camel, с декабря 2009 г.)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Сравнение Camel с другими решениями, октябрь 2009 г.)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Мэтт Рейбл, октябрь 2008 г.)

Вопрос: какой опыт вы получили при использовании одного стека над другим? В каких случаях вы бы порекомендовали Camel, если Spring Integration не имеет поддержки? Где вы видите плюсы и минусы каждого? Любой совет от реальных проектов высоко ценится.

Мы выбираем Camel вместо Spring-Integration, потому что свободный API действительно хорош. Мы фактически используем его в проектах Spring и используем Spring для его настройки. API-интерфейсы программирования понятны, и есть большой набор разумных компонентов.

Мы провели небольшую перестрелку, и в то время, по нашему требованию, победил Верблюд. Мы используем его главным образом для передачи внутренних файлов данных внешним сторонним организациям, которые обычно требуют преобразования формата, отправляя его с использованием ftp / sftp / ... или прикрепляя его к электронному письму и отправляя его.

Мы обнаружили, что цикл edit-compile-debug сокращен. Используя groovy для экспериментов по настройке маршрутов, добавляются бонусы.

Spring-Integration также является отличным продуктом, и я уверен, что он также удовлетворит наши потребности.

Я рекомендую Spring Integration только в том случае, если у вас уже есть проект Spring, и вам просто нужно добавить некоторую «базовую» интеграцию, используя File, FTP, JMS, JDBC и так далее.

Apache Camel имеет два основных преимущества:

1. Многие, многие другие технологии поддерживаются.
2. Кроме (хорошего) XML DSL, существуют свободные API для Java, Groovy и Scala.

Поскольку Apache Camel имеет очень хорошую интеграцию со Spring, я бы даже использовал его вместо Spring Integration в большинстве проектов Spring.

Если вам нужна дополнительная информация, вы можете прочитать мой опыт в моем блоге: « Избранный для выбора»: какую интеграционную платформу использовать - Spring Integration, Mule ESB или Apache Camel?

Недавно я провел перестрелку Camel vs Spring Integration с целью интеграции Apache Kafka . Несмотря на то , заядлый разработчик Spring, я , к сожалению , нашел мое подозрение с постоянно растущим стеком проекта Spring подтвердил: Spring является удивительным , как МОК-Container , чтобы служить в качестве клея для других рамок, но она не в обеспечении жизнеспособных альтернатив в этих рамках . Могут быть исключения из этого, а именно все, что связано с MVC, откуда пришел Spring и где он отлично справляется, но другие попытки предоставить новые функциональные возможности поверх функций контейнера терпят неудачу по трем причинам, и пример использования SI Kafka подтверждает все они:

• Внедрение давно сложного в использовании DSL для XML-конфигурации.
• Страницы кода XML-конфигурации для подключения всех компонентов инфраструктуры.
• Недостающие ресурсы для обеспечения функциональности наравне с выделенными фреймворками.

Теперь вернемся к результатам моей перестрелки: самое главное, я впечатлен общей концепцией маршрутов между конечными точками Camels . Kafka легко интегрируется с этой концепцией, и для ее запуска достаточно трех линий конфигурации. Проблемы, возникшие в ходе процесса, аккуратно решены с помощью обширной документации от команды проекта, а также с множеством вопросов по Stackoverflow. И последнее, но не менее важное: в Spring есть комплексная интеграция, которая не оставляет желаний невыполненными.

С SI, наоборот, документация для интеграции Kafka довольно интенсивна и все еще не в состоянии ясно объяснить, как интегрировать Kafka. Интеграция Кафки нажимается в SI-способ делать вещи, что добавляет дополнительную сложность. Другая документация, например, о Stackoverflow, также менее распространена и менее полезна, чем для Camel.

Мой вывод: сапожник придерживается вашей профессии - используйте Spring в качестве контейнера и Camel в качестве основы для системной интеграции.

Это действительно зависит от того, что вы хотите сделать. Если вам нужно что-то расширить, чтобы создать собственное решение для обмена сообщениями, Spring Integration имеет лучшую модель программирования. Если вам нужно что-то, что поддерживает множество протоколов без специального кода, Camel опережает Spring Integration.

Небольшая перестрелка - очень хорошая идея, просто убедитесь, что вы пытаетесь делать то, что обычно делаете в проекте.

--disclaimer: я коммиттер Spring Integration

Большинство сравнений Camel и SI, которые я видел, не учитывают следующее:

1.) Влияние Spring Boot на производительность разработчика для Spring Integration

2.) Эффект Spring XD оказал влияние на то, чтобы приложения Spring Integration были доступны без компиляции кода - также источники и приемники Spring XD - это просто адаптеры каналов Spring Integration, если вы хотите расширить Spring XD.

3.) Влияние Spring XD на объединение Spring Integration, Spring Batch, Spring Data (+ Hadoop!) В одном стеке, эффективное объединение пакетной и потоковой обработки, поддержку HDFS / Apache Hadoop и многое другое в Spring Integration.

4.) Эффект Java-DSL Spring Integration 4.0, который скоро будет выпущен, https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

На ваш взгляд,

/ Питер (отказ от ответственности, я работаю на Pivotal)

Мы используем Spring Integration для нашего приложения и теперь планируем перейти на Apache Camel, поскольку столкнулись с множеством проблем со средой Spring Integration. Вот пара вопросов.

1. CachingConnectionFactory, предоставляемый Spring, открывает тысячи незанятых соединений в IBM MQ, и нет никакой гарантии, что эти соединения будут использованы повторно. И все же эти связи будут оставаться открытыми навсегда, что создает проблемы на стороне MQ. Приходилось перезапускать приложение каждую неделю в более низких средах, чтобы просто обновить соединения. Apache Camel также обеспечивает кэширование, и кажется, что соединения увеличиваются / уменьшаются в зависимости от нагрузки.

2. Spring не предоставляет картографы для параметров QoS. Даже если вы включите QoS, режим доставки и свойства expiration / timetolive будут потеряны (я собираюсь поднять проблему JIRA для этого). Apache Camel обрабатывает это, и параметры QoS отправляются в исходящие приложения, а не отбрасываются.

Сейчас я работаю над проблемами обработки исключений и транзакций с Apache Camel, которые Spring, похоже, лучше справляется с AOP.

На самом деле, я бы сказал, что FTP закончил свой инкубационный период. Вы можете выполнить простой поиск на форумах SI / JIRA, чтобы увидеть, какие новые функции были реализованы и исправлены ошибки. Судя по разным болтовням, кажется, что уже есть какое-то использование в производстве, поэтому я бы посоветовал ему еще раз взглянуть на него и, конечно, сообщить нам о своих проблемах через

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

Ура Олег

Отказ от ответственности: я коммиттер Spring Integration

Apache Camel - очень хороший фреймворк и очень полный. Но если ваше приложение использует Spring, мой личный совет - использовать Spring Integration.

Spring Integration является интегрированной средой обработки жалоб EIP в экосистеме Spring-Source. Отличная интеграция с экосистемой: Spring boot, Batch, XD; даже ядро ​​использует ту же абстракцию, начиная с Spring Framework 4. Некоторые из абстракций обмена сообщениями были перемещены в фреймворк в качестве доказательства того, что базовая абстракция обмена сообщениями в Spring Integration очень сильна. Теперь Spring Framework, например, использует абстракцию обмена сообщениями для Spring Web, поддержку веб-сокетов.

Еще одна полезная вещь в приложении Spring с интеграцией Spring для использования Apache Camel заключается в том, что с интеграцией Spring можно использовать только один контекст приложения. Помните, что Camel Context - это контекст Spring. если у вас есть возможность использовать новую версию Spring, я предлагаю использовать Spring Integration Java DSL для конфигурации. Я использую это в моих новых проектах, и это чувствует себя более читабельным и ясным. Я надеюсь, что это отражение поможет вам в ваших оценках.

Одна из причин использовать Camel поверх Spring Integration - когда вам нужен более функциональный набор EIP. Spring Integration не предоставляет абстракций над такими вещами, как ThreadPool.

Camel предоставляет дополнительные конструкции для этого, упрощая некоторые аспекты работы с параллельным кодом:

http://camel.apache.org/camel-23-threadpool-configuration.html

Если вам не нужны такие вещи и вы просто хотите подключить файл, JMS, конечные точки FTP и т. Д., Тогда просто используйте Spring Integration.

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

Если ваше текущее приложение находится в Spring и требует функций, которые поддерживаются Spring Integration EIP, тогда Spring Integration является лучшим вариантом, в противном случае требуются сторонние поддержки / протоколы / форматы файлов и т. Д.