Чем отличаются разработки Apache от Redhat Fuse?
Мы уже давно используем продукты Apache ActiveMQ и Camel, но хотим взглянуть на хорошую базовую ESB. Я читал сайт Redhat о Fuse, но не смог найти хорошее резюме значительных различий между Fuse и Apache для кодировщиков.
С точки зрения дизайнера / разработчика, каковы существенные различия между Fuse и Apache Camel и ActiveMQ, которые мы использовали? Я получил прекрасный обзорный материал, FuseIDE и инструменты управления ESB. Но я действительно просто хочу узнать о различиях на уровне кода, то есть, вводит ли он более полезные конечные точки Camel? Существуют ли дополнительные библиотеки действительно полезных вещей, которые облегчат мою жизнь дизайнера / программиста? Есть ли подводные камни, на которые стоит обратить внимание?
Мне просто нужно несколько указателей, чтобы помочь мне в поиске, а не том. Или, что еще лучше, быстрая ссылка на документ, в котором рассказывается обо всем этом (когда-либо обнадеживающем:o)!) У меня есть короткое время, чтобы сформировать точку зрения, по которой можно двигаться дальше, или эта возможность пропустит меня.
Спасибо.
SK
3 ответа
На уровне кода нет никакой разницы. Процесс заключается в том, что мы разрабатываем проекты Apache и синхронизируем изменения кода с репозиториями Red Hat / Fuse git. Там мы выбираем изменения, которые хотим внести в наши филиалы, чтобы сохранить продукт стабильным. Кроме того, бэкпорт исправляет старые ветки, если наши клиенты нуждаются в этом / etc (например, вы можете повлиять на это)
Продукты от Red Hat также поддерживаются гораздо дольше, чем поддержка сообщества от Apache. Существует гарантированное время жизни, которое вы можете найти здесь: https://access.redhat.com/support/policy/updates/jboss_notes/
Существует только несколько дополнительных компонентов Camel из продуктов Fuse / JBoss Fuse, которые являются частью проекта с открытым исходным кодом Fuse Fabric ( http://fuse.fusesource.org/fabric/), который является частью продуктов JBoss Fuse. Fuse Fabric находится в процессе передачи в дар Apache ServiceMix, поэтому он также может принести пользу этому сообществу, позволяя ServiceMix также собирать Fabric из коробки. В Fabric есть несколько компонентов Camel, которые позволяют отправлять сообщения на любую конечную точку Camel, которая автоматически балансирует нагрузку в кластерной среде / облачной среде. И есть еще один компонент Camel для выбора мастера, и он запускает маршрут только на главном узле, и если мастер умирает, тогда другой узел вступает во владение.
Я также думаю, что этот шаг является свидетельством готовности open source, которую команда Fuse имеет и продолжает иметь. Мы делаем как можно больше в дебюте. Например, новый проект - hawtio ( http://hawt.io/) также имеет полностью открытый исходный код, лицензию ASL, проект github, любой может внести свой вклад / разветвиться и т. Д.
А продукт JBoss Fuse позволяет исправлять себя в производстве. Поэтому, если вам нужно исправление как можно скорее, мы можем предоставить исправление в виде файла.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.
Apache ActiveMQ и Camel являются проектами с открытым исходным кодом. Redhat fuse объединяет их и, возможно, многие другие компоненты в один пакет, поэтому его можно использовать как один пакет ESB. Я вижу самую большую разницу в поддержке, которую вы можете получить. Вы можете получить поддержку за то, что ваша организация не произвела. И инструменты, поставляемые с пакетом, на мой взгляд, помогают при разработке и обслуживании.
На уровне кода разница очень мала, если вообще существует.
Из коммерческого пакета RedHat вы получаете поддержку, проверенный пакет и эксплуатационные преимущества (о которых вы упомянули).
Все дело в том, что происходит после того, как код сделан - когда вы запускаете свои вещи в производство, а кодер все еще не может обрабатывать инциденты.