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

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

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

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 в целом) не рассматривает, - это управление зависимостями.

Некоторые важные моменты, на которые следует обратить внимание при сравнении Mule с сообществами Apache. Mule похож на Redhat в том смысле, что, хотя это лицензия с открытым исходным кодом, на мой взгляд, это не открытое сообщество. Любой может участвовать в Apache, тогда как MuleSoft владеет сообществом Mule и окончательной дорожной картой. Во-вторых, хотя сообщество 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. Embedded in any kind of Java container (servlet container, application server, Spring Boot).
  2. Автономный как процесс Java.
  3. В среде OSGi (Apache Karaf).

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

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

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

Идеально подходит для ознакомительного или предпроизводственного использования.

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

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

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

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

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

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

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

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

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

Заключительные примечания

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

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

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

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

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

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

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

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

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

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

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

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

Сначала вам нужно понять, что 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 поверх Mule, а также то, что у них нет нескольких DSL, как в Camel.
3. Mule в своем стеке продуктов содержит управление API и внутренние облачные коннекторы, где, поскольку Apache Camel является фреймворком, когда учитывается FUSE ESB, JBoss Stack предоставляет приличное количество других продуктов, которые могут дополнить ваш выбор.