Я хочу описать это более доступным способом...

Чтобы понять, что такое Apache Camel, вам нужно понять, что представляют собой шаблоны интеграции с корпорацией.

Начнем с того, что мы, по-видимому, уже знаем: шаблон Singleton, шаблон Factory и т.д.; Это всего лишь способы организации вашего решения проблемы, но они сами не являются решениями. Эти модели были проанализированы и извлечены для всех нас "Бандой четырех", когда они опубликовали свою книгу: Шаблоны проектирования. Они сэкономили некоторым из нас огромные усилия, подумав о том, как наилучшим образом структурировать наш код.

Как и Банда Четырех, Грегор Хохпе и Бобби Вульф создали книгу Шаблоны интеграции предприятия (EIP), в которой они предлагают и документируют набор новых шаблонов и чертежи для того, как мы могли бы лучше проектировать большие системы на основе компонентов, где компоненты могут работать на одном и том же процессе или на другой машине.

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

Итак, что такое Apache Camel?

Apache Camel предлагает вам интерфейсы для EIP, базовых объектов, общеупотребительных реализаций, средств отладки, системы конфигурации и многих других помощников, которые сэкономит вам массу времени, когда вы захотите реализовать свое решение, чтобы следовать EIPs.

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

То, что Apache Camel для EIP. Это полноценная готовая среда для людей, которые хотят реализовать свое решение, следуя EIP.

Создание описания не должно быть сложным.

Я говорю:

Apache Camel - это технологический клей для обмена сообщениями с маршрутизацией. Он объединяет стартовые и конечные точки обмена сообщениями, позволяющие переносить сообщения из разных источников в разные пункты назначения. Например: JMS → JSON, HTTP → JMS или трафик FTP → JMS, HTTP → JMS, JSON → JMS

Википедия говорит:

Apache Camel - это механизм маршрутизации и посредничества, основанный на правилах, который обеспечивает реализацию на основе объектов Java шаблонов Enterprise Integration с использованием API (или декларативного языка Java Domain Specific Language) для настройки правил маршрутизации и посредничества. Язык, специфичный для домена, означает, что Apache Camel может поддерживать безопасное интеллектуальное завершение правил маршрутизации в вашей среде IDE с использованием обычного кода Java без огромного количества файлов конфигурации XML; хотя поддержка XML внутри Spring также поддерживается.

См? Это было не сложно?

Короче:

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

Чтобы сделать это:

1) Вы могли бы разработать собственную программу, которая бы это сделала (может потребоваться много времени и трудно понять, поддерживать для другого разработчика)

2) В качестве альтернативы вы можете использовать Apache Camel для стандартизации (у него есть большинство коннекторов, уже разработанных для вас, вам просто нужно настроить его и подключить свой логический процесс):

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

• Потребляйте данные из любого источника/формата
• Обработать эти данные
• Вывести данные в любой источник/формат

Используя Apache Camel, вы легко поймете/поддерживаете/расширяете свою систему до другого разработчика.

Apache Camel разработан с использованием корпоративных интеграционных шаблонов. Шаблоны помогают вам эффективно интегрировать системы: -)

Диаграмма лучше, чем тысячи описаний. Эта диаграмма иллюстрирует архитектуру Camel.

Camel отправляет сообщения от A до B:

Почему для этого нужна вся основа? Что ж, если у вас есть:

• многие отправители и многие получатели
• десятка протоколов (ftp, http, jms и т.д.)
• множество сложных правил
  • Отправить сообщение A только получателям A и B
  • Отправить сообщение B получателю C как XML, но частично перевести, обогатить его (добавить метаданные) и IF условие X, затем отправьте его в приемник 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");
}

См. также this и this и Camel in Action (как говорили другие, отличная книга!)

НА ОСНОВЕ АНАЛОГИИ

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

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

Ваши пассажирские платы авиакомпаний используют "аэропорты" из города и отбрасывают их, используя аэропорт города. Пассажир может "путешествовать" по нескольким городам, но везде они должны пройти через аэропорт, чтобы путешествовать между вашим авиационным самолетом и городом.

Обратите внимание, что пассажир, "вылетающий" из города, по сути "прибывает" в самолет ваших авиакомпаний. И пассажир, "прибывающий" в город, по сути отходит от самолета. Поскольку мы находимся на месте владельца авиакомпании, термин "пассажир прибытия" и "вылетающий пассажир" отменены из наших обычных понятий, которые основаны на перспективах городов.

Такую "инфраструктуру аэропорта" каждого города используют "вылетающие" пассажиры и пассажиры "прибытия". Аэропорт предоставляет "уходящую инфраструктуру" для вылетающих пассажиров, что отличается от "инфраструктуры прибытия", предусмотренной для прибывающих пассажиров.

Пассажиры могут продолжать делать свой день своей деятельности из-за различных "удобств", предоставляемых внутри самолета вашими авиакомпаниями во время путешествия.

Кроме того, ваша авиакомпания также предоставляет лаундж-центры для специальных процедур, таких как "понимание локального языка" и подготовка к "путешествию".

Позволяет заменить несколько слов/фраз, которые использовались выше, со следующими параметрами:

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

авиационные компании: транспортные механизмы

ваш самолет авиакомпании: Apache Camel, лежащий в основе транспортного механизма

перенос: маршрут

пассажиры: сообщение;

город: система;

аэропорт: компонент Camel;

понимание локальных языков: преобразование типов;

Отправление: производство, производство

прибытие: потребление, потребление

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

удобства: при условии

После замены слов вот что вы получаете:

Цель "Apache Camel" - направить "сообщения" от одной "системы" к другой в мире. Верблюд Apache использует различные механизмы транспорта для маршрутизации сообщений.

Apache Camel собирает сообщения, используя "Компонент на основе Camel" из системы "from" и отбрасывает их, используя "Компонент на основе Camel" системы "to". Сообщение может направляться на несколько систем, но везде они должны пройти "Компоненты на основе Camel" для перемещения между "Apache Camel, лежащим в основе транспортного механизма" и системой.

Обратите внимание, что сообщение, "произведенное" из системы, по существу "потребляется" в транспортном механизме Apache Camel ". И сообщение, потребляемое системой, по существу производится" механизмом транспортировки "Apache Camel".

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

Такая же инфраструктура кодирования Component на основе Camel используется "сообщениями производителя" и "потребительским сообщением". "Компонент на основе Camel" предоставляет "конечную точку производителя" для "сообщения производителя" и "конечной точки потребителя" для "потребительского сообщения".

Сообщения могут обрабатываться Camel при их маршрутизации.

В дополнение к этой маршрутизации Camel предоставляет специальные функции, такие как "Преобразование типов" и многое другое...

Одна из вещей, которую вам нужно понять, прежде чем пытаться понять Apache Camel, - это шаблоны интеграции с корпорацией. Не все в этой области действительно знают о них. Хотя вы, безусловно, можете прочитать книгу "Интеграционные схемы предприятия", более быстрый способ ускорить их работу - прочитать статью " "Интеграция корпоративных приложений" в статье Wikipedia.

То, что вы прочитали и поняли предметную область, вы, скорее всего, поймете цель Apache Camel

НТН

Если вам известны шаблоны интеграции предприятия, Apache Camel - это одна интеграционная структура, которая реализует все EIP.

И вы можете развернуть Camel как отдельное приложение в веб-контейнере.

В принципе, если вам нужно интегрировать несколько приложений с различными протоколами и технологиями, вы можете использовать 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 и т.д.

Посмотрите на article и статья шаблона EIP

Как это взаимодействует с приложением, написанным на Java?

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

Java DSL - DSL на основе Java с использованием свободного стиля построителя.

История шаблона интеграции предприятия решает эти понятия:

Сообщение, конечная точка, производитель, потребитель, маршрутизация, шина, преобразование и процесс.

Посмотрите на это article. Анирбан Конар для одного из вариантов использования в реальном времени.

Это что-то, что идет вместе с сервером?

Он действует как мост между несколькими подсистемами предприятия.

Является ли это независимой программой?

Apache Camel, интеграционная структура, объединяет различные независимые приложения.

Главное преимущество Camel: вы можете интегрировать различные приложения с различными технологиями (и разными протоколами), используя те же самые концепции для каждой интеграции.

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

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

Middleware - это общий термин для программного обеспечения, предоставляющего услуги интерпретации между объектами, которые не имеют общего языка или типов данных.

То, что такое верблюд, внизу. Мы можем описать описание, отметив, что оно обеспечивает промежуточное программное обеспечение типа EIP.

Он не предоставляет самого промежуточного ПО, поскольку он не может знать детали того, что приложения должны связывать. Но он предоставляет API для создания инвариантных частей этого промежуточного программного обеспечения (создание начальной точки, создание конечной точки, создание условий для начала и окончания и т.д.)

Надеюсь, что это поможет.

Вот еще одна попытка.

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

В основном были созданы инструменты перетаскивания, основанные на этих технологиях, и по частям вам пришлось бы писать адаптеры на Java. Этот код адаптера был либо непроверен, либо имел плохую оснастку/автоматизацию вокруг тестирования.

Как и при использовании шаблонов проектирования в программировании, у вас есть шаблоны Enterprise Integration для общих интеграционных решений. Их прославили одноименная книга Грегора Хохпе и Бобби Вульфа.

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

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

Итак, Camel является конкурирующей технологией для других инструментов EAI с лучшей поддержкой для тестирования вашего кода интеграции. Код является кратким из-за доменных спецификаций (DSL). Он читается даже бизнес-пользователями, и он свободен и делает вас продуктивным.

Существует множество фреймворков, которые облегчают нам обмен сообщениями и решение проблем обмена сообщениями. Одним из таких продуктов является Apache Camel.

Большинство распространенных проблем имеют проверенные решения, называемые шаблонами проектирования. Шаблон проектирования для обмена сообщениями - это шаблоны Enterprise Integration (EIP), которые хорошо описаны здесь. Верблюд Apache помогает нам реализовать наше решение с помощью EIP.

Силой интеграции является ее способность облегчать нас через EIP или другие шаблоны, количество транспортов и компонентов и простоту разработки, на которой верблюд верхушки верхушки списка

Каждая из рамок имеет свои преимущества. Некоторые из особенностей верблюда Apache следующие.

• Он обеспечивает кодирование во многих DSL, а именно DSL DSL и Spring xml основе DSL, которые популярны.
• Простота использования и простота использования.
• 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);

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

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

Он использует Маршруты; который может быть описан как:

Когда служебная шина получает определенное сообщение, она будет маршрутизировать ее через никакие услуги/адреса брокеров, такие как очередь/темы. Этот путь известен как маршрут.

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

Да, это, наверное, немного поздно. Но одна вещь, которая добавляет ко всем остальным комментариям, заключается в том, что Camel на самом деле является набором инструментов, а не полным набором функций. Это следует учитывать при разработке и выполнении различных преобразований и преобразовании протоколов.

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

На предприятии существует ряд систем различного типа. Некоторые из них могут быть устаревшими системами, в то время как некоторые из них могут быть новыми. Эти системы часто взаимодействуют друг с другом и нуждаются в интеграции. Это взаимодействие или интеграция не так просто, как реализация систем, их форматы сообщений могут отличаться. Один из способов добиться этого - реализовать код, который связывает эти различия. Однако это будет точка-точка интеграции. Если завтра снова, если есть изменение в системе, другое может также быть изменено, что не очень хорошо. Вместо этой точки к интеграции точек, которая вызывает жесткую связь, мы можем реализовать дополнительный уровень для для опознавания различий между системами. Это приводит к ослаблению сцепления и не влияет на наши существующие системы. Apache Camel - это механизм маршрутизации и посредничества, основанный на правилах, который обеспечивает объектную реализацию шаблонов Enterprise Integration, основанных на Java, с использованием API (или декларативного языка Java Domain Specific Language) для настройки правил маршрутизации и посредничества.
Подробное объяснение и примеры можно найти здесь Учебники Apache Camel

Apache Camel - это инфраструктура Java для интеграции с предприятием. Например: - если вы создаете веб-приложение, которое взаимодействует с API многих поставщиков, мы можем использовать верблюда в качестве инструмента внешней интеграции. Мы можем сделать больше с этим в зависимости от варианта использования. "Верблюд в действии" из публикаций Мэннинга - отличная книга для изучения верблюда. Интеграции могут быть определены как ниже.

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 и отправляет запрос обратно.

Spring 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. Это независимая программа? Ответ: - Может быть.

Надеюсь, поможет

Его как трубопровод, соединяющий

From---->To

В промежутке между u можно добавить столько каналов и труб. Кран может быть любого типа автоматический или ручной для потока данных и маршрут для направления потока.

Он поддерживает и имеет реализацию для всех типов и видов обработки. И для такой же обработки многие подходы, потому что у нее много компонентов, и каждый компонент может также предоставить желаемый результат, используя различные методы под ним.

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

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

От/до ---- папки, direct, seda, vm может быть что угодно

Другая точка зрения (на основе более фундаментальных математических тем)

Самая общая вычислительная платформа - это [ https://en.wikipedia.org/wiki/Turing_machine]

Есть проблема с машиной Тьюринга. Все входные/выходные данные остаются внутри машины Тьюринга. В реальном мире существуют входные источники и выходные приемники, внешние по отношению к нашей машине Тьюринга и в целом управляемые системами вне нашего контроля. То есть эти внешние системы будут отправлять/получать данные по желанию в любом формате с любым желаемым планировщиком данных.

Вопрос: Как нам удается заставить независимые машины Тьюринга общаться друг с другом наиболее общим образом, чтобы каждая машина Тьюринга воспринимала своих пиров как источник входных данных или приемник выходных данных?

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

101 Word Intro

Camel - это фреймворк с согласованным API и моделью программирования для интеграции приложений. API основан на теориях в шаблонах Enterprise Integration Patterns - то есть на наборе шаблонов проектирования, которые, как правило, используют обмен сообщениями. Он предоставляет готовые реализации большинства из этих шаблонов и дополнительно поставляется с более чем 200 различными компонентами, которые вы можете использовать, чтобы легко общаться со всеми видами других систем. Чтобы использовать Camel, сначала напишите свою бизнес-логику в POJO и внедрите простые интерфейсы, сосредоточенные вокруг сообщений. Затем используйте Camels DSL для создания "Маршрутов", которые представляют собой наборы правил для склеивания вашего приложения.

Расширенное вступление

На первый взгляд, функциональность Camel конкурирует с традиционными продуктами Enterprise Service Bus. Обычно мы думаем о том, что Camel Route является компонентом-посредником (он же оркестровка), который живет на стороне сервера, но поскольку он является библиотекой Java, которую легко внедрить, и он также может жить в клиентском приложении и помочь вам интегрироваться это с услугами точка-точка (хореография). Вы даже можете взять свои POJO, которые обрабатывают сообщения внутри маршрута Camel, и легко выделить их в свои собственные процессы удаленного потребителя, например, если вам нужно было масштабировать только одну часть независимо. Вы можете использовать Camel для подключения маршрутов или процессоров через любое количество различных удаленных транспортных протоколов/протоколов в зависимости от ваших потребностей. Вам нужен чрезвычайно эффективный и быстрый двоичный протокол или протокол, который более удобочитаем и прост в отладке? Что если вы хотите переключиться? С верблюдом это обычно так же просто, как изменить одну или две линии в вашем маршруте и вообще не менять какую-либо бизнес-логику. Или вы можете поддерживать оба - вы можете запускать сразу несколько маршрутов в контексте верблюда.

Вам действительно не нужно использовать Camel для простых приложений, которые будут работать в одном процессе или в JVM - это было бы излишним. Но концептуально это не сложнее, чем код, который вы можете написать сами. А если ваши требования изменятся, разделение бизнес-логики и связующего кода облегчит обслуживание с течением времени. Как только вы изучите API Camel, вы легко сможете использовать его как швейцарский армейский нож и быстро применять его во многих различных контекстах, чтобы сократить объем пользовательского кода, который в противном случае придется писать. Вы можете изучить один из вариантов - например, Java DSL, свободный API, который легко объединить в цепочку, - и легко выбрать другие варианты.

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

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