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



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

7   68  

7 ответов:

Apache Camel-это библиотека, которая реализует шаблоны интеграции предприятия (EIP). Хотя он может использовать Spring в качестве своей структуры IOC, он даже не зависит от Spring, поэтому он полностью независим от платформы. Это "просто" библиотека. Таким образом, вы можете запустить его в любой среде JVM, например, простой jvm, сервлет, 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. хотя ни .NET, ни OSGI не решают существенную сложность основной проблемы, они, по крайней мере, предоставляют средства для ее решения. OSGI имеет и другие преимущества, но с точки зрения выбора продукта стандарты контейнер на основе является основным, и его существенной особенностью, которую Mule (и Java в целом) не решает, является управление зависимостями.

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

Эд Ост

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

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

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

    1. встроенный в любом виде контейнера Java (контейнер сервлета, применение сервер, Весенняя загрузка).
    2. Автономной как процесс Java.
    3. внутри среды OSGi (Apache Karaf).
  • Apache Camel продолжает развиваться и получать тягу и активность на ежемесячной основе, как показано на графике под этой точкой, которую я извлек из OpenHub. Пользовательская база также продолжает расти.

Apache Camel Contributors per Month

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

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

идеально подходят для оценки или подготовки к использованию.

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

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

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

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

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

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

Mule vs Camel in Google Trends

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

когда дело доходит до Apache camel или другого ESB. Разница в том, что будет делать

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

Comments

    No results found.