Каковы различия в развитии продуктов Apache и Redhat Fuse?

Question

Мы уже некоторое время используем Apache ActiveMQ и продукты Camel, но хотим взглянуть на хороший базовый ESB. Я читал сайт Redhat о Fuse, но не смог найти хорошее резюме существенных различий между Fuse и Apache для кодеров.

С точки зрения дизайнера/разработчика, каковы существенные различия между Fuse и Apache Camel и ActiveMQ, которые мы использовали? Я получаю прекрасный обзор, инструменты FuseIDE и ESB. Но я просто хочу знать о различиях на уровне кода, т. Е. Вводит ли более полезные конечные точки Camel? есть ли дополнительные библиотеки действительно полезных вещей, которые облегчат мою жизнь как дизайнера/кодера? есть ли какие-то подводные камни, которые нужно искать?

Мне просто нужно несколько указателей, чтобы помочь мне в поиске, а не томе. Или еще лучше - быстрая ссылка на документ, который охватывает все это (когда-либо обнадеживающее: o)!) У меня есть короткое время, чтобы сформировать представление, чтобы идти вперед, или возможность пройдет мимо меня.

спасибо.

SK

Answer 1

На уровне кода есть разница «нет». Процесс заключается в том, что мы разрабатываем проекты Apache и синхронизируем изменения кода в Red Hat/Fuse git repos. Там мы вишневые выбираем изменения, которые хотим внести в наши филиалы, чтобы сохранить продукт стабильным. Кроме того, исправления backport для старых филиалов, если нашим клиентам необходимо это/etc (например, вы можете повлиять на это)

Продукты Red Hat также поддерживаются на гораздо более длительный период времени, чем поддержка сообщества от Apache. Существует Гарантированное время жизни, которое вы можете найти здесь: https://access.redhat.com/support/policy/updates/jboss_notes/

Существует лишь несколько дополнительных компонентов Camel из продуктов Предохранитель/JBoss предохранитель, который является частью проекта с открытым исходным кодом Предохранитель Fabric (http://fuse.fusesource.org/fabric/), который является частью JBoss Предохранители. Fuse Fabric находится в процессе пожертвования Apache ServiceMix, поэтому он также может принести пользу этому сообществу, что позволяет ServiceMix также собирать Fabric из коробки. В Fabric есть несколько компонентов Camel, которые позволяют отправлять сообщения на любую конечную точку Camel, которая автоматически балансирует нагрузки в кластерной среде/облачной среде. И есть еще один компонент Camel для выбора мастера и только запуск маршрута на главном узле, и если мастер умирает, то другой узел берет верх.

Я также считаю, что этот шаг является свидетельством открытого источника готовности команды Fuse иметь и продолжает иметь. Мы делаем как можно больше в открытии.Например, новый проект - hawtio (http://hawt.io/) также полностью открытый исходный код, лицензия ASL, GitHub проект, любой желающий может внести свой вклад/вилы и т.д.

и продукт JBoss предохранителя позволяет латать себя в производстве. Поэтому, если вам нужно исправление как можно скорее, мы можем предоставить исправление как .zip-файл, который может быть исправлен с помощью встроенного инструмента патча в продукте. Это невозможно из Apache.

Несколько ссылок для дальнейшего материала (от нашего старого сайта и сайт JBoss сообщества)

• http://fusesource.com/enterprise-support/support-offerings/
• http://fusesource.com/community/apache-committers-and-fuse/
• http://www.jboss.org/products/fuse
• http://www.davsclaus.com/2013/04/apache-camel-web-dashboard-with-hawtio.html

Раскрытие: Я работаю для Fusesource/Red Hat.

Answer 2

На уровне кода, разница очень мала, если вообще.

Что вы получаете от коммерческого пакета RedHat - это поддержка, пакет, который был протестирован, и операционные преимущества (что вы упомянули).

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

Answer 3

Apache ActiveMQ и Camel - проекты с открытым исходным кодом. Плавкий предохранитель Redhat объединяет их и, возможно, многие другие компоненты в один пакет, и поэтому он может использоваться как один пакет ESB. Я вижу самую большую разницу в качестве поддержки, которую вы можете получить. Вы можете получить поддержку от того, что ваша организация не создала. И инструменты, которые поставляются с пакетом, действительно помогают в процессе разработки и обслуживания на мой взгляд.