Apache Camel и другие продукты ESB

Привет,
Если у нас есть Apache Camel, зачем использовать другие решения, такие как Apache ServiceMix и Mule?
Есть ли что-то Apache Camel не может сделать по сравнению с этими продуктами?
Когда использовать Mule / ServiceMix и когда использовать Camel?

68
apache-camel apache-servicemix esb mule

7 ответов

Apache Camel-это библиотека, которая реализует шаблоны интеграции предприятия (EIP). Хотя он может использовать Spring в качестве своей структуры IOC, он даже не зависит от Spring, поэтому он полностью независим от платформы. Это "просто" библиотека. Таким образом, вы можете запустить любую среду JVM, например simple jvm, servlet, ejb, osgi. Он не приносит с какой-либо из преимуществ (или накладных расходов) контейнера такого Мула. Он, на мой взгляд, более четко разделяет озабоченности в этой области.

мул также может быть встроен в разные среды, но я думаю, что у Mule есть как преимущества, так и недостатки соединения их библиотеки EIP с их контейнером. Когда вы развертываете Мула внутри сервлета или среды ejb, вы действительно хотите нести весь этот багаж контейнера Мула? Я не эксперт по мулам, и я думаю, что вы, вероятно, можете потратить относительно скромное количество усилий и очистить некоторые из избыточных возможностей. (Обратите внимание, это не плохая возможность во всех случаях, это просто избыточно, если вы используете встроенный в другой контейнер.)

Apache ServiceMix-это контейнер OSGI, который использует Camel для реализации EIP в качестве основы ESB. Хотя ServiceMix исторически начинался с его корней в JBI, он отошел от JBI и превратился в (IMO) хорошую слоистую архитектуру, сочетающую лучшее из породы Apache CXF, Camel и ActiveMQ в контейнере OSGI. Основным значением здесь является не ServiceMix и его поддержка JBI, а базовая OSGI контейнер стандартный в сочетании с проверенными транспортами Apache, такими как CXF для веб-сервисов и ActiveMQ для JMS. OSGI-это зрелый стандарт, который предлагает контейнер, который обращается к тем же типам" DLL", которые преследовали Microsoft до появления .Сеть. Хотя ни .NET, ни OSGI не решают существенную сложность основной проблемы, они, по крайней мере, предоставляют средства для ее решения. OSGI имеет и другие преимущества, но с точки зрения выбора продукта стандарты основанный контейнер является основным, и его существенной особенностью, которую Mule (и Java в целом) не адресует, является управление зависимостями.

некоторые важные вещи, которые следует отметить при сравнении Мула с сообществами Apache. Мул похож на Redhat в том смысле, что, хотя это лицензия с открытым исходным кодом, на мой взгляд, это не открытое сообщество. Любой может участвовать в Apache, тогда как MuleSoft владеет сообществом Mule и окончательной дорожной картой. Во-вторых, хотя мул сообщество, возможно, довольно активно, я думаю, что сообщество Apache намного больше (и, естественно, так как это не закрытое сообщество). Оба подхода имеют как плюсы, так и минусы. Одним из плюсов подхода Apache является то, что существует несколько поставщиков ESB на основе Camel, CXF, ActiveMQ и OSGI. Например, Talend предлагает ESB на тех же основных технологиях без истории ServiceMix JBI. Это имеет как плюсы, так и минусы в сообществе Apache, но реальный смысл в том, чтобы выделите разницу между Apache и Mule. Вы не найдете поставщиков multilple в сообществе Mule. Таким образом, IMO Apache ESB, такой как Talend или ServiceMix, является более широким и более инклюзивным и в конечном счете конкурентоспособным сообществом, чем закрытое сообщество, такое как Mule.

Эд Ост

63

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

стратегически говоря

  • Apache Camel остался верен своим корням и не превратился в тяжеловесную и полноценную платформу выполнения. Это универсальный и модульный, и может работать:

    1. встроенный в любом виде контейнера Java (контейнер сервлета, приложение сервер, Весенняя загрузка).
    2. Автономной как процесс Java.
    3. внутри среды OSGi (Апач Все Супер).

  • Apache Camel продолжал развиваться и набирать обороты и активность на ежемесячной основе, как показано на графике под этим пунктом, который я извлек из OpenHub. Пользователей системы также продолжает расти.

Apache Camel Contributors per Month

  • в 2012 году Red Hat приобрел FuseSource, один из основных промоутеров и разработчиков Apache Camel, ActiveMQ, ServiceMix и CXF. Несколько коммиттеров и членов PMC теперь используются Red Hat для работы на Apache Camel.

  • мул ESB предлагает две версии их продукта: сообщество (бесплатно по лицензии CPAL) и предприятия (платная). Они определяют их сообщество версия:

Ideal для пользы оценки или pre-продукции.

=> Это означает, что вы должны приобрести платная подписка предприятия для использования производства.

  • на самом деле, мул ESB Community Edition распространяется под лицензия CPAL. Это означает, что если вы все еще решите использовать это версия, мул ТРЕБУЕТ:

    • каждый раз, когда исполняемый и исходный код или большая работа запускается или первоначально запускается, видное отображение информации атрибуции Mulesoft должно происходить на графическом пользовательском интерфейсе, используемом конечным пользователем для доступа к такому покрытому коду (который может включать отображение на заставке), если таковые имеются. = > В основном вам нужно реклама что все, что вы построили с Mule работает на Мул.

    • Если ваше развертывание Mule ESB доступно по сети (это всегда будет, так как это платформа интеграции!), вы также должны сделать источник вашего развертывания доступным для всех, кто обращается к нему.

  • Как уже упоминалось выше, Apache Camel-это полностью открытый проект и управляемый сообществом, для сообщества. Весь исходный код является общедоступным, и все рекомендуется отправлять запросы pull, вносить компоненты и помогать или запрашивать на форумах. И наоборот, мул сообщество жилой комплекс.

  • последнее, но не менее важное; возможно, самая важная часть. вот что Google Trends должен сказать о мул ESB против Apache Camel. Обратите внимание, что я использую новый semantic темы измерение для более высокой точности, а не стандарт запрос. Таким образом, мы не измеряем популярность животных (мул против верблюда), но программного обеспечения! Интерпретация: мул сильно снизился с 2007 по 2011 год, в то время как верблюд Apache поднялся. С 2011 года мул плато, в то время как Apache Camel продолжает тренд вверх здоровым!

Mule vs Camel in Google Trends

техническая эволюция Apache Camel

просто хотел дать вам некоторые функциональные показатели эволюции Apache Camel с 25 сентября 2010 года, когда вы впервые задали этот вопрос. это было исходное дерево в тот момент времени.

  • тогда у Camel было 88 компонентов, теперь у него есть 220 компонентов, включая интеграцию с Facebook, Twitter, Salesforce,Apache Ignite, Апач Кассандра, AWS,Апач Кафка, MongoDB, Apache Spark etc.
  • многие, многие технические улучшения: асинхронная маршрутизация Двигатель, История сообщений, автомат Защити цепи EIP, много много улучшений и улучшений к EIPs как комплексирование, разделять, динамическая трасса, etc.
  • экосистема выросла, чтобы теперь также включать Hawtio для мониторинга и управления, fabric8 для развертывания и т. д.
  • С тех пор более чем 5500 билетов были разрешены, включая новые функции,улучшения, ошибки и т. д.
  • и многое, многое еще!

конечные ноты

оба продукта эволюционировали много за последние 5,25 лет! Однако из-за разницы в лицензиях и общинного характера Mule ESB и Apache Camel я не думаю, что они больше сопоставимы друг с другом.

Apache Camel является полностью открытым исходным кодом❤️, в то время как Mule ESB Community требует от пользователей атрибутировать Mulesoft и публиковать исходный код программного обеспечения, которое использует Mule. Лицензия на программное обеспечение Apache бизнес-центр лицензия: вы можете использовать Camel без атрибуции или каких-либо других требований. Поистине свободный как в пиве!

надеюсь, что это размышление о последних годах поможет новым зрителям! :)

отказ от ответственности: я коммиттер и член PMC в проекте Apache Camel.

65

мой пост в блоге отвечает именно на этот вопрос:http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel-это легкая платформа интеграции, ServiceMix и так далее-полные ESBs.

7

Верблюд-это посреднический движок, а мул-легкая интеграционная платформа. Разница в том, что этот мул предлагает все возможности ESB, включая контейнер для развертывания приложений, REST и веб-служб. Мул может быть встроен таким же образом Camel, чтобы разработчики приложений могли встроить туда код приложения со своим кодом интеграции. Оба интегрируют плотно с весной.

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

5

в Apache Camel есть некоторые записи FAQ, которые проливают свет на это http://camel.apache.org/faq

и коллекция ссылок на Apache Camel http://camel.apache.org/articles.html

есть некоторые ссылки, где люди в сообществе разговаривают и сравнивают Camel с другими проектами.

4

Клаус, в FAQ Camel есть ряд ошибок, неудивительно, что ни одна из них не в нашу пользу:)

  • модель УМО в муле больше не находится в муле. Мы начинаем отходить от этой модели в муле 2, и она была полностью изменена в муле 3. Теперь у нас есть очень простая модель процессора сообщений, которая делает ваше заявление об этом избыточным
  • Mule имеет явное преобразование типов в течение нескольких лет, это не дифференциатор для Верблюд!--4-->
  • мул лицензирован под OSI одобрил лицензию CPAL 1.0. Это лицензия с открытым исходным кодом, а не коммерческая. Пожалуйста, обновите это как можно скорее
0

сначала вам нужно понять, что Service Mix похож на контейнер, который может запускать код Apache Camel, а Mule ESB-отдельный продукт сам по себе

может быть много различий, которые вы можете обеспечить между продуктами ESB.

вы должны знать несколько вещей, прежде чем искать в дифференциации. Они

  1. как продукты начаты
  2. лицензирования
  3. его функции поддержки
  4. открыть Источник или нет
  5. если с открытым исходным кодом можно изменить и использовать источник и так далее.

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

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

  1. поддержка сообщества
  2. стек товара
  3. расширяемость с точки зрения изменения собственного кода
  4. Learn-способность и удобство использования
  5. поддержка продукта при покупке как предприятие

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

когда дело доходит до Apache camel или другого ESB. Разница, которая сделает

  1. количество транспорта
  2. Apache Camel, предоставляющий вам разнообразие DSL над мулом, и другие-это то, что у них нет нескольких DSL, как в Camel.
  3. мул в своем стеке продукта содержит управление API и в соединителях облака дома где как верблюд Апача рамки когда взрыватель ESB учтен стог JBoss обеспечивает пристойное количество других продуктов, которые могут дополнить ваш выбор.
0