Apache Camel та інші продукти ESB

Гей,
якщо у нас Apache Camel, навіщо використовувати інші рішення, такі як Apache ServiceMix та Mule?
Чи є щось, що Apache Camel не може зробити порівняно з цими продуктами?
Коли використовувати Mule / ServiceMix, а коли Camel?

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

Mule також можна вбудовувати в різні середовища, але я думаю, що Mule має як переваги, так і недоліки, пов’язуючи свою бібліотеку EIP із своїм контейнером. Коли ви розгортаєте Mule всередині сервлету або середовища ejb, ви дійсно хочете перевезти весь багаж контейнера 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 загалом) не стосується, є управління залежностями.

Деякі важливі речі, на які слід звернути увагу при порівнянні мулів із громадами апачів. Мюл схожий на Redhat в тому сенсі, що хоча це і ліцензія з відкритим кодом, на мій погляд, це не є відкритою спільнотою. Будь-хто може взяти участь в Apache, тоді як MuleSoft належить спільноті Mule та остаточній дорожній карті. По-друге, хоча спільнота мулів, можливо, досить активна, я думаю, що спільнота апачів набагато більша (і, природно, так як це не спільнота, яка є закритою). Обидва підходи мають як плюси, так і мінуси. Позитивним підходом Apache є те, що для ESB існує кілька постачальників на основі Camel, CXF, ActiveMQ та OSGI. Наприклад, Talend пропонує ESB щодо тих самих основних технологій без історії ServiceBix JBI. Це має як плюси, так і мінуси у спільноті Apache, але справжній сенс полягає у висвітленні різниці між Apache та Mule. Ви не знайдете різноманітних продавців у спільноті мулів. Тож ІМО Apache ESB, такий як Talend або ServiceMix, є більш широким і всеохоплюючим, і зрештою конкурентним співтовариством, ніж закрите співтовариство, як Mule.

Ед Ост

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

Стратегічно кажучи

• Apache Camel залишився вірним своїм корінням і не перетворився на важку вагу та повноцінну платформу для роботи. Він універсальний і модульний, і може працювати:

  1. Вбудований у будь-який тип контейнера Java (контейнер сервлетів, сервер додатків, 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 пропонує дві версії свого продукту : Community (безкоштовно за ліцензією CPAL) та Enterprise (платно). Вони визначають свою версію спільноти як:

Ідеально підходить для оцінки або передвиробничого використання.

=> Це означає, що ви повинні придбати платну підписку на Enterprise для виробничого використання.

• Фактично, Mule ESB Community Edition поширюється під ліцензією CPAL . Це означає, що якщо ви все-таки вирішите використовувати цю версію, Mule ПОТРІБНО, ЩО :

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

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

• Як хтось ще згадував вище, Apache Camel - це повністю відкритий проект, що керується громадою для громади . Весь вихідний код є загальнодоступним, і всім рекомендується надсилати запити на вилучення, додавати компоненти та допомагати або запитувати на форумах. І навпаки, спільнота мулів - це спільнота, що закривається .

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

Технічна еволюція верблюда апача

Просто хотів дати вам декілька функціональних показників щодо розвитку верблюда Apache з 25 вересня 2010 року, коли ви спочатку задали питання. На той момент це було дерево джерел .

• Тоді Camel налічував 88 компонентів, зараз у нього 220 компонентів, включаючи інтеграції з Facebook, Twitter, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark тощо.
• Багато-багато технічних удосконалень: механізм асинхронної маршрутизації, історія повідомлень, автоматичний вимикач EIP, безліч вдосконалень та вдосконалень EIP, таких як агрегація, розділення, динамічна маршрутизація тощо.
• Екосистема розрослася до теперішнього часу також включає Hawtio для моніторингу та управління, тканину8 для розгортання тощо.
• З тих пір було вирішено понад 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 та так далі - це повні ESB.

Верблюд - це механізм посередництва, тоді як 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

Є кілька посилань, де люди в громаді говорять і порівнюють Верблюда з іншими проектами.

Клаусе, у Поширених запитаннях про верблюдів є низка помилок, як не дивно, жодна з них не на нашу користь :)

• модель UMO в Mule більше не в Mule. Ми починаємо відходити від цієї моделі в Mule 2, і вона була повністю змінена в Mule 3. Зараз у нас є дуже проста модель процесора повідомлень, яка робить вашу заяву про неї зайвою
• У Мула вже кілька років відбувається явне перетворення типу, це не є відмінником для Верблюда
• Mule ліцензований відповідно до затвердженої OSI ліцензії CPAL 1.0 . Це ліцензія з відкритим кодом, а не комерційна. Будь ласка, оновіть це якомога швидше

Спочатку потрібно зрозуміти, що Service Mix - це як контейнер, на якому можна запускати код Apache Camel, а Mule ESB - це окремий продукт

Між продуктами ESB може бути багато відмінностей.

Ви повинні знати кілька речей, перш ніж шукати диференціацію. Вони є

1. Як розробляється продукція
2. Його ліцензування
3. Його функції підтримки
4. З відкритим кодом чи ні
5. Якщо відкрите джерело може бути змінене та використано, тощо.

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

Відмінність вторинного продукту залежить від інструментів та його домену. Це, мабуть, відповідь, яку ви шукаєте. Знайдіть список, який вам потрібно проаналізувати перед тим, як зробити вибір.

1. Підтримка громади
2. Стек продуктів
3. Розширюваність з точки зору модифікації власного коду
4. Навчання та зручність використання
5. Підтримка товару, коли купується як підприємство

Ймовірно, це дослідження, яке вам потрібно зробити самостійно, щоб вибрати різницю. У будь-який спосіб існує багато додаткових цінностей, які роблять продукт придатним для вашої організації, а не як найкращий на ринку.

Коли справа стосується верблюда апача або іншого ESB. Різниця, яка буде мати значення

1. Кількість транспорту
2. Apache Camel, що надає вам різноманітність DSL у порівнянні з мулом, - це те, що вони не мають кількох DSL, як у верблюда.
3. Mule у своєму наборі продуктів містить управління API та внутрішні хмарні роз'єми, де як Apache Camel - це структура, коли враховується FUSE ESB, JBoss Stack забезпечує пристойну кількість інших продуктів, які можуть доповнити ваш вибір.