Я не розумію, що саме робить Camel .

Якщо ви могли б дати 101 слово вступ до верблюда:

• Що це саме?
• Як це взаємодіє з додатком, написаним на Java?
• Це щось, що йде разом із сервером?
• Це незалежна програма?

Поясніть, будь ласка, що таке верблюд.

Якщо у вас від 5 до 10 хвилин, я, як правило, рекомендую людям читати цю Інтеграцію з верблюдом Apache Джонатана Анстея. Це добре написаний фрагмент, який дає короткий вступ та огляд деяких концепцій Camel, і він реалізує випадок використання із зразками коду. У ньому Джонатан пише:

Apache Camel - це програма з відкритим кодом Java, яка фокусується на спрощенні та доступності розробників інтеграції. Це робиться, забезпечуючи:

• конкретні реалізації всіх широко використовуваних моделей інтеграції підприємств (EIP)
• підключення до великої кількості транспортних засобів та API
• прості у використанні мови домену (DSL) для з'єднання EIP та транспортування разом

Існує також безкоштовна глава « Верблюда в дії», яка представляє Верблюда в першій главі. Джонатан є співавтором цієї книги зі мною.

Я берусь описати це більш доступним способом ...

Щоб зрозуміти, що таке Apache Camel, вам потрібно зрозуміти, що таке шаблони інтеграції підприємств.

Почнемо з того, що ми, мабуть, уже знаємо: шаблон Singleton, Factory Factory тощо; Вони є лише способами організації вашого вирішення проблеми, але самі не є рішеннями. Ці зразки були проаналізовані та вилучені для решти нас бандою четвірок, коли вони видали свою книгу: Шаблони дизайну . Вони заощадили деяких із нас величезних зусиль, роздумуючи, як найкраще структурувати наш код.

Так само, як "Банда четвірок", Грегор Хопе та Боббі Вулф написали книгу " Шаблони інтеграції підприємств" (EIP), в якій вони пропонують і документують набір нових шаблонів та креслення, щоб ми могли найкраще спроектувати великі компоненти на основі компонентів, де компоненти можуть бути працює на тому ж процесі або в іншій машині.

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

То що таке Apache Camel?

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

Візьміть MVC. Теоретично MVC досить простий, і ми могли б реалізувати його без допомоги рамки. Але хороші рамки MVC надають нам структуру, готову до використання, і пройшли додаткову милю та продумали всі інші «побічні» речі, необхідні при створенні великого проекту MVC, і саме тому ми використовуємо їх більшу частину часу.

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

Створення опису проекту не повинно бути складним.

Я кажу:

Apache Camel - це технологія обміну повідомленнями з клеєм. Він поєднує разом початкову та кінцеву точки обміну повідомленнями, що дозволяє переносити повідомлення з різних джерел у різні пункти призначення. Наприклад: JMS -> JSON, HTTP -> JMS або Fneneling FTP -> JMS, HTTP -> JMS, JSON -> JMS

У Вікіпедії сказано:

Apache Camel - це механізм маршрутизації та посередництва, заснований на правилах, який забезпечує реалізацію шаблонів інтеграції підприємств на основі об'єкта Java за допомогою API (або декларативної мови домену Java) для налаштування правил маршрутизації та посередництва. Мова, що відповідає домену, означає, що Apache Camel може підтримувати безпечне для розумного завершення правила маршрутизації у вашому IDE, використовуючи звичайний код Java без величезної кількості файлів конфігурації XML; хоча конфігурація XML всередині Spring також підтримується.

Подивитися? Це було не важко, чи не так?

Коротко:

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

Для цього:

1) Ви можете розробити власну програму, яка б це зробила (це може зайняти багато часу і важко зрозуміти, підтримувати для іншого розробника)

2) Крім того, ви можете використовувати Apache Camel, щоб зробити це стандартизованим способом (у нього є більшість роз'ємів, які вже розроблені для вас, вам просто потрібно налаштувати його та підключити свою логіку - називається Process):

Верблюд допоможе вам:

1. Використовуйте дані з будь-якого джерела / формату
2. Обробити ці дані
3. Виводить дані в будь-яке джерело / формат

Використовуючи Apache Camel, ви полегшите розуміння / підтримку / розширення вашої системи іншому розробнику.

Apache Camel розроблений з шаблонами інтеграції підприємств. Шаблони допомагають вам добре інтегрувати системи :-)

Верблюд надсилає повідомлення від А до В:

Чому для цього цілі рамки? Що робити, якщо у вас є:

• багато відправників і багато приймачів
• десяток протоколів ( ftp, http, jmsі т.д.)
• багато складних правил
  • Надішліть повідомлення А лише приймачам A і B
  • Надішліть повідомлення B на ресивер C як XML , але частково перекладіть його, збагатіть його (додайте метадані) та IF умова X , а потім надішліть його також на Receiver D, але як CSV .

Тому зараз вам потрібно:

• перекладати між протоколами
• склеюйте компоненти разом
• визначити маршрути - що куди йде
• фільтруйте деякі речі в деяких випадках

Верблюд дає вам вищезгадане (та більше) з коробки:

за допомогою прохолодної мови DSL для визначення того, що і як:

  new DefaultCamelContext().addRoutes(new RouteBuilder() {
        public void configure() {
            from("jms:incomingMessages")
                    .choice() // start router rules
                    .when(header("CamelFileName")
                            .endsWith(".xml"))
                    .to("jms:xmlMessages")
                    .when(header("CamelFileName")
                            .endsWith(".csv"))
                    .to("ftp:csvMessages");
}

Дивіться також це і це та «Верблюда в дії» (як вже казали інші, відмінна книга!)

Діаграма краще, ніж тисячі описів. Ця діаграма ілюструє архітектуру верблюда.

НА ОСНОВІ АНАЛОГІЇ

Маршрут на основі верблюдів можна зрозуміти набагато легко, якщо поставити себе взуття власника авіакомпанії (наприклад: American Airlines, Jet Airways).

Мета "вашої авіакомпанії" - перевезти "пасажирів" з одного "міста" в інше у світі. Ви використовуєте літаки різних авіаційних компаній, таких як Boeing, Airbus, HAL для перевезення пасажирів.

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

Зауважте, що пасажир, який "відправляється" з міста, по суті "прибуває" до літака вашої авіакомпанії. І пасажир, який "приїжджає" в місто, по суті відходить від літака. Оскільки ми є взуттям власника авіакомпанії, терміни "пасажир, що прибуває" та "пасажир, що від'їжджає", змінюються нашими традиційними поняттями, які базуються на перспективах міст.

Те саме «аеропортна» інфраструктура кожного міста використовується пасажирами, що «від’їжджають», та пасажирами, що «прибувають». Аеропорт забезпечує "інфраструктуру виїзду" для пасажирів, що відправляються, що відрізняється від "інфраструктури прибуття", передбаченої для пасажирів, що прибувають.

Пасажири можуть продовжувати займатися своєю діяльністю через різноманітні «зручності», які надаються Вашими авіакомпаніями під час подорожі.

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

Дозволяє замінити кілька використаних вище слів / фраз наступними:

Ваша авіакомпанія: Apache Camel

авіаційні компанії: Транспортні механізми

літак Вашої авіакомпанії: базовий транспортний механізм Apache Camel

перевозити: маршрут

пасажири: повідомлення;

місто: система;

аеропорт: Camel Component;

розуміння місцевих мов: конверсії типів;

відходить: виробляти, виробляти

приїжджаючи: споживати, споживати

подорож: маршрутка

зручності: надається

Після заміни слів ви отримаєте ось що:

Призначення "Apache Camel" полягає в маршрутизації "повідомлень" від однієї "системи" до іншої у світі. Верблюд Apache використовує різні транспортні механізми для маршрутизації повідомлень.

Apache Camel приймає повідомлення, використовуючи «Компонент на основі верблюда» системи «від» і скидає їх, використовуючи «Компонент на основі верблюда» системи «до». Повідомлення може переходити до декількох систем, але скрізь вони повинні пройти "Компоненти на основі верблюда", щоб пройти між базовим транспортним механізмом Apache Camel та системою.

Зауважте, що повідомлення, "вироблене" із системи, по суті "споживається" в базовому транспортному механізмі Apache Camel ". І повідомлення, що споживається системою, по суті виробляється основним транспортним механізмом Apache Camel.

Оскільки ми намагаємось зрозуміти верблюда, ми повинні думати з точки зору Камелі тут далі. Значення термінів "повідомлення споживача" та "повідомлення виробника", таким чином, повертаються від наших традиційних понять, які базуються на перспективі системи.

Інфраструктура кодування тієї ж «Компонента на основі верблюда» використовується у вигляді «повідомлення виробника» та «повідомлення споживача». Компонент на основі верблюда надає "кінцеву точку виробника" для "повідомлення виробника" та "кінцеву точку споживача" для "повідомлення споживача".

Повідомлення можуть оброблятися верблюдом під час їх маршрутизації.

Крім цього маршруту, Camel надає такі особливості, як "Перетворення типів" та багато іншого ...

Перш ніж спробувати розібратися з Apache Camel, вам потрібно зрозуміти одну з речей - це інтеграція підприємств. Не всі в галузі насправді їх знають. Хоча ви, безумовно, можете читати книгу "Шаблони інтеграції підприємств", більш швидким способом швидкої роботи було б прочитати щось на зразок статті у Вікіпедії про інтеграцію корпоративних програм. .

Коли ви прочитали та зрозуміли предметну область, ви набагато частіше зрозумієте мету верблюда Apache

HTH

Якщо вам відомі шаблони інтеграції підприємств, Apache Camel - це одна інтеграційна структура, яка реалізує всі EIP.

І ви можете розгорнути верблюда як окрему програму в веб-контейнері.

В основному, якщо вам доведеться інтегрувати кілька додатків з різними протоколами та технологіями, ви можете використовувати Camel.

Визначення з іншої точки зору:

Apache Camel є інтеграційною основою. Він складається з деяких бібліотек Java, що допомагає реалізувати проблеми інтеграції на платформі Java. Що це означає і чим він відрізняється від API-інтерфейсів з одного боку та Enterprise Service Bus (ESB) з іншого, описано в моїй статті " Коли користуватися Apache Camel ".

Що це саме?

Apache Camel - це легка рамка інтеграції, яка реалізує всі шаблони інтеграції підприємств. Ви можете легко інтегрувати різні програми, використовуючи необхідні шаблони.

Можна використовувати Java, Spring XML, Scala або Groovy. Практично кожна технологія, яку ви можете собі уявити, доступна, наприклад, HTTP, FTP, JMS, EJB, JPA, RMI, JMS, JMX, LDAP, Netty тощо.

Подивіться цю статтю та статтю EIP

Як це взаємодіє з додатком, написаним на Java?

Camel використовує специфічну мову або DSL для домену Java для створення шаблонів або маршрутів інтеграції підприємства на різних мовах, що залежать від домену (DSL), як зазначено нижче.

Java DSL - DSL на основі Java, що використовує вільний стиль конструктора.

Історія шаблону інтеграції підприємств вирішується навколо таких понять:

Повідомлення, кінцева точка, виробник, споживач, маршрутизація, шина, перетворення та обробка .

Перегляньте цю статтю Анірбана Конара для одного із випадків використання реального часу.

Це щось, що йде разом із сервером?

Він діє як міст через декілька підсистем підприємства.

Це незалежна програма?

Apache Camel, інтеграційна структура, інтегрує різні незалежні програми.

Основна перевага Camel : Ви можете інтегрувати різні програми з різними технологіями (і різними протоколами), використовуючи однакові концепції для кожної інтеграції.

Більшість «нових» речей в обчислювальних технологіях зовсім не є новими, вони просто загадкова обгортка навколо чогось, що вже добре зрозуміло. Коли їх важко зрозуміти, це зазвичай тому, що хтось вирішив винайти нові мовні терміни або колонізувати існуючі терміни з іншою метою (хорошим прикладом цього є перетворення розробниками X того, що означають "клієнт" і "сервер".)

Camel - оболонка / API на основі Java для проміжного програмного забезпечення між додатками.

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

Ось, що це верблюд, внизу. Ми можемо деталізувати опис, зазначивши, що він передбачає середнє програмне забезпечення типу EIP.

Він не забезпечує проміжне програмне забезпечення, оскільки він не може знати подробиці того, про що потрібно зв’язувати програми. Але він надає API для створення інваріантних частин цього проміжного програмного забезпечення (створити початкову точку, створити кінцеву точку, створити умови для початку та закінчення тощо)

Сподіваюся, що це допомагає.

Ось ще одна спроба.

Ви знаєте, як існували такі речі, як Webmethods, ICAN Seebeyond, Tibco BW, IBM Broker. Усі вони допомагали інтеграційним рішенням на підприємстві. Ці інструменти загальновідомі під назвою інструментів Enterprise Application Integration (EAI).

Здебільшого було створено інструменти перетягування, створені навколо цих технологій, і в деяких частинах вам доведеться писати адаптери на Java. Ці адаптерні коди були або не перевіреними, або мали поганий інструментарій / автоматизацію навколо тестування.

Так само, як і з моделями дизайну в програмуванні, у вас є шаблони інтеграції підприємств для загальних інтеграційних рішень. Вони прославилися однойменною книгою Грегора Хопе та Боббі Вульфа.

Хоча цілком можливо реалізувати інтеграційні рішення, які використовують один або багато EIP, Camel - це спроба зробити це в кодовій базі за допомогою одного з XML, Java, Groovy або Scala.

Camel підтримує всі шаблони інтеграції підприємств, перелічені в книзі, завдяки своєму багатому DSL та механізму маршрутизації.

Таким чином, Camel є конкуруючим технологом для інших інструментів EAI з кращою підтримкою для тестування вашого інтеграційного коду. Код є стислим через мови, що задаються для домену (DSL). Він читається навіть діловими користувачами, він безкоштовний і робить вас продуктивними.

Існує безліч рамок, які полегшують нам обмін повідомленнями та вирішення проблем в обміні повідомленнями. Одним з таких продуктів є верблюд Apache.

Більшість поширених проблем - це перевірені рішення, які називаються моделями дизайну. Шаблон дизайну для обміну повідомлень є моделлю Enterprise Integration (EIPs) , які добре пояснюються тут . Верблюд Apache допомагає нам реалізувати наше рішення за допомогою EIP.

Міцність інтеграційної основи полягає в її здатності полегшувати нас за допомогою EIPs або інших моделей, кількості транспорту та компонентів та простоті розробки, на якій верблюд Apache стоїть у верхній частині списку

Кожна з Рамок має свої переваги. Деякі особливості верблюда Apache полягають у наступному.

1. Він забезпечує кодування в багатьох DSL, а саме в Java DSL та DSL на основі Spring XML, які популярні.
2. Простота у використанні та проста у використанні.
3. Fuse IDE - це продукт, який допомагає кодувати через інтерфейс користувача

На простотій англійській мові верблюд отримує (багато) речі, зроблені без особливого коду пластини котла.

Тільки для того, щоб дати вам перспективу, Java DSL, наведений нижче, створить кінцеву точку REST, яка зможе прийняти XML, що складається з Переліку продуктів, і розділить його на декілька продуктів і викличе з ним метод Process BrandProcessor. І лише додавши .parallelProcessing (відзначте коментовану частину), він буде паралельно обробляти всі Об'єкти продукту. (Клас продукту - створений JAXB / XJC заглушку Java з XSD, до якого обмежений вхідний xml.) Цей великий код (разом із кількома залежностями від Camel) отримає роботу, яка використовувалась для отримання 100-ти рядків коду Java.

from("servlet:item-delta?matchOnUriPrefix=true&httpMethodRestrict=POST")
.split(stax(Product.class))
/*.parallelProcessing()*/
.process(itemDeltaProcessor);

Після додавання ідентифікатора маршруту та заяви ведення журналу

from("servlet:item-delta?matchOnUriPrefix=true&httpMethodRestrict=POST")
.routeId("Item-DeltaRESTRoute")
.log(LoggingLevel.INFO, "Item Delta received on Item-DeltaRESTRoute")
.split(stax(Product.class))
.parallelProcessing()
.process(itemDeltaProcessor);

Це лише зразок, верблюд - це набагато більше, ніж просто кінцева точка REST. Просто подивіться список компонентів, що підключаються http://camel.apache.org/components.html

Верблюд допомагає в маршрутизації, перетворенні, спостереженні.

Він використовує маршрути; який можна описати як:

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

Приклад: ваша заявка на запас отримала деякий внесок аналітиком, вона буде оброблена через додаток / веб-компонент, після чого результат буде опублікований для всіх зацікавлених / зареєстрованих членів для конкретного оновлення акцій.

Припустимо, ви створюєте електронну комерційну компанію, як Amazon, і ви хочете зосередитись лише на стратегії / виборі продуктів для продажу. На відміну від флоту доставки амазонки, замість того, щоб ви самостійно обробляли переміщення товарів від продавців до складів, вносили зміни до складу на зразок упаковки та відправляли їх іншим містам та клієнтам. Ви наймаєте компанію, яка все це робить, і просто даєте їм інформацію про всі місця вашого складу, типи транспортних засобів, місця доставки та перелік того, що робити. Тоді вони вирішують це самі, це був би Apache Camel. Вони дбають про переміщення речей з одного кінця в інший, як тільки ви передаєте їм речі, щоб ви могли зосередитись на інших речах.

101 слово вступ

Camel - це структура з послідовною програмою API та програмування для інтеграції програм разом. API базується на теоріях моделей інтеграції підприємств - тобто, шаблоні дизайну, які зазвичай використовують обмін повідомленнями. Він забезпечує реалізацію більшості цих моделей, а також постачає понад 200 різних компонентів ви можете легко спілкуватися з усіма іншими системами. Щоб використовувати Camel, спочатку напишіть свою бізнес-логіку в POJO та застосуйте прості інтерфейси, зосереджені навколо повідомлень. Потім використовуйте DSL Camel, щоб створити "Маршрути", які є наборами правил для склеювання вашої програми.

Розширений вступ

На перший погляд, функціональність Camel конкурує з традиційними продуктами Enterprise Service Bus. Зазвичай ми думаємо, що Camel Route є компонентом "посередництва" (він же оркестрації), який живе на серверній стороні, але, оскільки це бібліотека Java, вона легко вбудовуватися, і вона може жити в додатку на стороні клієнта і допомагає вам інтегруватися. це з точки зору послуг (він же хореографія). Ви навіть можете взяти ваші POJO, які обробляють повідомлення всередині маршруту верблюда, і легко відкручувати їх у власні віддалені споживчі процеси, наприклад, якщо вам потрібно самостійно масштабувати лише одну частину. Ви можете використовувати верблюда для підключення маршрутів або процесорів через будь-яку кількість різних віддалених транспортних / протоколів, залежно від ваших потреб. Вам потрібен надзвичайно ефективний та швидкий бінарний протокол, або такий, який читає людину і простіше відлагодити? Що робити, якщо ви хотіли переключитися? З Camel це зазвичай так просто, як змінити лінію або дві на своєму маршруті і взагалі не змінити жодної логіки бізнесу. Або ви могли б підтримати і те, і інше - ви вільні керувати багатьма маршрутами одночасно в контексті верблюдів.

Вам не потрібно використовувати Camel для простих додатків, які збираються жити в єдиному процесі або JVM - це буде надмірно. Але це концептуально не складніше, ніж код, який ви можете написати самостійно. І якщо ваші вимоги змінюються, розділення ділової логіки та коду клею полегшує підтримку з часом. Після того, як ви дізнаєтесь API верблюда, його легко використовувати як ніж у армії Швейцарії та швидко застосовувати його у багатьох різних контекстах, щоб зменшити кількість спеціального коду, який ви інакше повинні писати. Ви можете навчитися одному аромату - наприклад, Java DSL, безперебійному API, який легко з'єднати між собою - і легко підібрати інші аромати.

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

Так, це, мабуть, трохи пізно. Але одне, що слід додати до коментарів усіх інших, це те, що Camel - це фактично набір інструментів, а не повний набір функцій. Ви повинні мати це на увазі, коли розробляєте і потрібно робити різні перетворення та перетворення протоколів.

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

Apache Camel - це програма Java для інтеграції з корпорацією. Наприклад: - якщо ви створюєте веб-додаток, який взаємодіє з багатьма постачальниками API, ми можемо використовувати верблюда як інструмент зовнішньої інтеграції. Ми можемо зробити більше з ним, виходячи із випадку використання. Camel in Action з видань Manning - це чудова книга для вивчення верблюда. Інтеграції можна визначити як нижче.

Java DSL

from("jetty://0.0.0.0:8080/searchProduct").routeId("searchProduct.products").threads()
    .log(LoggingLevel.INFO, "searchProducts request Received with body: ${body}")
    .bean(Processor.class, "createSearchProductsRequest").removeHeaders("CamelHttp*")
    .setHeader(Exchange.HTTP_METHOD, constant(org.apache.camel.component.http4.HttpMethods.POST))
    .to("http4://" + preLiveBaseAPI + searchProductsUrl + "?apiKey=" + ApiKey
                    + "&bridgeEndpoint=true")
    .bean(Processor.class, "buildResponse").log(LoggingLevel.INFO, "Search products finished");

Це просто створити кінцеву точку API REST, яка, в свою чергу, викликає зовнішній API і відправляє запит назад

Весняний DSL

<route id="GROUPS-SHOW">
    <from uri="jetty://0.0.0.0:8080/showGroups" />
    <log loggingLevel="INFO" message="Reqeust receviced service to fetch groups -> ${body}" />
    <to uri="direct:auditLog" />
    <process ref="TestProcessor" />
</route>

До ваших питань

1. Що це саме? Відповідь: - Це рамка, яка реалізує схеми інтеграції підприємств
2. Як це взаємодіє з додатком, написаним на Java? Відповідь: - він може взаємодіяти з будь-якими доступними протоколами, такими як http, ftp, amqp тощо
3. Це щось, що йде разом із сервером? Відповідь: - Він може бути розгорнутий у контейнері на зразок tomcat або може бути розгорнутий незалежно як Java-процес
4. Це незалежна програма? Відповідь: - Це може бути.

Сподіваюся, це допомагає

Apache Camel - це легкий інтеграційний каркас, який реалізує всі моделі інтеграції підприємств. Ви можете легко інтегрувати різні програми, використовуючи необхідні шаблони. Можна використовувати Java, Spring XML, Scala або Groovy.

Apache Camel працює на віртуальній машині Java (JVM). ... Основним функціоналом Apache Camel є його двигун маршрутизації. Він розподіляє повідомлення на основі пов'язаних маршрутів. Маршрут містить логіку потоку та інтеграції. Він реалізується за допомогою EIP та конкретного DSL.

Це як трубопровід, що з'єднує

From---->To

Між і може бути додано стільки каналів і труб. Змішувач може бути будь-якого типу автоматичним або вручну для передачі даних та маршруту для каналізації потоку.

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

Наприклад, передачу файлів можна зробити на верблюді з типом файлів, переміщених або скопійованих, а також із папки, сервера чи черги.

-from-->To
   - from-->process-->to
   - from-->bean-->to
   - from-->process-->bean-->to
   -from-->marshal-->process-->unmarshal-->to

З / в ---- папки, прямо, seda, vm може бути будь-що

Інша точка зору (заснована на більш фундаментальних математичних темах)

Найбільш загальною обчислювальною платформою є [ https://en.wikipedia.org/wiki/Turing_machine]

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

Питання: Як нам вдається змусити незалежні машини Тьюрінга розмовляти між собою найбільш загальним способом, щоб кожен тюрінг-верстат бачив своїх однолітків або джерелом вхідних даних, або раковиною вихідних даних?

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