Я не понимаю, что именно делает Camel.
Если бы вы могли дать представление о Camel в 101 слове:
Пожалуйста, объясните, что такое Camel.
Если у вас есть 5–10 минут, я обычно рекомендую людям прочитать этот Интеграция с Apache Camel Джонатана Ансти. Это хорошо написанный фрагмент, который дает краткое введение и обзор некоторых концепций Camel, а также реализует вариант использования с примерами кода. В нем Джонатан пишет:
Apache Camel - это Java-фреймворк с открытым исходным кодом, цель которого - упростить интеграцию и сделать ее более доступной для разработчиков. Он делает это, предоставляя:
- конкретные реализации всех широко используемых шаблонов корпоративной интеграции (EIP)
- возможность подключения к большому количеству транспортов и API
- простые в использовании доменные языки (DSL) для соединения EIP и транспорта вместе
Также есть бесплатная глава Camel in Action (Camel in Action, 2 ed. Is здесь), который знакомит с Camel в первой главе. Джонатан - соавтор этой книги со мной.
Я хочу описать это более доступным образом ...
Чтобы понять, что такое Apache Camel, вам необходимо понять, что такое шаблоны интеграции предприятия.
Начнем с того, что мы, по-видимому, уже знаем: шаблон Singleton, шаблон Factory и т. Д .; Это просто способы организовать ваше решение проблемы, но сами по себе они не являются решениями. Эти шаблоны были проанализированы и извлечены для остальных из нас «Бандой четырех», когда они опубликовали свою книгу: Design Patterns. Некоторым из нас они сэкономили огромные усилия на размышления о том, как лучше всего структурировать наш код.
Как и «Банда четырех», Грегор Хоуп и Бобби Вульф написали книгу Enterprise Integration Patterns (EIP), в которой они предлагают и документируют набор новых шаблонов и схем того, как мы могли бы лучше разрабатывать большие компонентные системы, в которых компоненты могут выполняться в одном процессе или на другом компьютере.
По сути, они предлагают структурировать нашу систему так, чтобы она была ориентирована на сообщения, когда компоненты взаимодействуют друг с другом, используя сообщения в качестве входных и выходных данных и ничего больше. Они показывают нам полный набор шаблонов, которые мы можем выбрать и реализовать в наших различных компонентах, которые вместе образуют всю систему.
Итак, что такое Apache Camel?
Apache Camel предлагает вам интерфейсы для EIP, базовые объекты, часто необходимые реализации, инструменты отладки, систему конфигурации и многие другие помощники, которые сэкономят вам массу времени, если вы захотите реализовать свое решение в соответствии с EIP.
Возьмите MVC. В теории MVC довольно прост, и мы могли бы реализовать его без какой-либо помощи фреймворка. Но хорошие фреймворки MVC предоставляют нам структуру, готовую к использованию, и приложили все усилия и продумали все другие «побочные» вещи, которые вам нужны при создании большого проекта MVC, и поэтому мы используем их большую часть времени.
Именно это и есть Apache Camel для EIP. Это полностью готовая к работе среда для людей, которые хотят внедрить свое решение в соответствии с EIP.
Создание описания проекта не должно быть сложным.
Я говорю:
Apache Camel - это связующее звено технологии обмена сообщениями с маршрутизацией. Он объединяет начальную и конечную точки обмена сообщениями, позволяя передавать сообщения из разных источников в разные места назначения. Например: JMS -> JSON, HTTP -> JMS или воронка FTP -> JMS, HTTP -> JMS, JSON -> JMS.
Википедия говорит:
Apache Camel - это основанный на правилах механизм маршрутизации и посредничества, который предоставляет основанную на Java объектную реализацию шаблонов интеграции предприятия с использованием API (или декларативного языка Java Domain Specific Language) для настройки правил маршрутизации и посредничества. Специфичный для предметной области язык означает, что Apache Camel может поддерживать типобезопасное интеллектуальное завершение правил маршрутизации в вашей среде IDE с использованием обычного кода Java без огромного количества файлов конфигурации XML; хотя также поддерживается конфигурация XML внутри Spring.
Видеть? Это было несложно, правда?
Суммируя:
Когда возникает потребность в подключении / интеграции систем, вам, вероятно, потребуется подключиться к какому-либо источнику данных, а затем обработать эти данные в соответствии с вашими бизнес-требованиями.
Для этого:
1) Вы можете разработать собственную программу, которая будет делать это (может потребовать много времени и трудностей для понимания, поддерживать для другого разработчика)
2) В качестве альтернативы вы можете использовать Apache Camel, чтобы сделать это стандартизированным способом (у него есть большинство коннекторов, уже разработанных для вас, вам просто нужно настроить его и подключить свою логику - под названием Process):
Camel поможет вам:
Используя Apache Camel, вы упростите понимание / поддержку / расширение вашей системы для другого разработчика.
Apache Camel разработан с использованием шаблонов корпоративной интеграции. Шаблоны помогут вам правильно интегрировать системы :-)
Camel отправляет сообщения от A к B:
Зачем для этого целый фреймворк? Ну а если у вас есть:
ftp, http, jms и т. д.)Итак, теперь вам нужно:
Camel дает вам все вышеперечисленное (и многое другое) из коробки:
с классным языком 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 (как говорили другие, отличная книга!)
Диаграмма лучше, чем тысячи описаний. Эта диаграмма иллюстрирует архитектуру Camel.
НА ОСНОВЕ АНАЛОГИИ
Маршрут на основе верблюда можно легко понять, поставив себя на место владельца авиакомпании (например, American Airlines, Jet Airways).
Цель «вашей авиакомпании» - «перевозить» пассажиров из одного «города» в другой в мире. Для перевозки пассажиров вы используете самолеты разных «авиастроительных компаний», таких как Boeing, Airbus, HAL.
Ваша авиакомпания садится на пассажиров, используя «аэропорты» из города, и высаживает их, используя аэропорт из города в город. Пассажир может «путешествовать» по нескольким городам, но везде он должен пройти через аэропорт, чтобы путешествовать между самолетом вашей авиакомпании и городом.
Обратите внимание, что пассажир, «вылетающий» из города, по сути, «прибывает» в самолет вашей авиакомпании. А прохожий, «приехавший» в город, по сути, вылетает из самолета. Поскольку мы находимся на месте владельца авиакомпании, термины «прибывающий пассажир» и «вылетающий пассажир» перевернуты по сравнению с нашими традиционными понятиями, основанными на перспективе городов.
Та же «аэропортовая» инфраструктура каждого города используется «вылетающими» и «прибывающими» пассажирами. Аэропорт предоставляет «инфраструктуру вылета» для вылетающих пассажиров, которая отличается от «инфраструктуры прибытия», предоставляемой прибывающим пассажирам.
Пассажиры могут продолжать заниматься своими делами благодаря различным «удобствам», предоставляемым вашими авиакомпаниями в салоне самолета во время путешествия.
Вдобавок к этому ваша авиакомпания также предоставляет залы ожидания для особых процедур, таких как «понимание местного языка» и / или подготовка вас к «путешествию».
Давайте заменим несколько слов / фраз, использованных выше, на следующие:
ваша авиакомпания: Apache Camel
авиастроительные компании: Транспортные механизмы
самолет вашей авиакомпании: основной транспортный механизм Apache Camel
нести: маршрут
пассажиры: сообщение;
город: система;
аэропорт: Camel Component;
понимание местных языков: преобразование типов;
отбытие: производство, производство
прибытие: потребляющее, потребляемое
путешествия: маршрутный
удобства: при условии
После замены слов вот что вы получите:
Цель Apache Camel - направлять «сообщения» из одной «системы» в другую в мире. Apache camel использует разные транспортные механизмы для маршрутизации сообщений.
Apache Camel принимает сообщения, используя «Компонент на основе Camel» системы «от», и отбрасывает их, используя «Компонент на основе Camel» системы «Кому». Сообщение может быть направлено в несколько систем, но везде, где они должны проходить через «Компоненты на основе Camel», чтобы перемещаться между «базовым транспортным механизмом Apache Camel» и системой.
Обратите внимание, что сообщение, «созданное» системой, по сути, «потребляется» в базовом транспортном механизме Apache Camel ». А сообщение, потребляемое системой, по существу создается «базовым транспортным механизмом Apache Camel».
Поскольку мы пытаемся понять Camel, мы должны думать с точки зрения Camel здесь и далее. Таким образом, значения терминов «сообщение потребителя» и «сообщение производителя» полностью противоположны нашим традиционным понятиям, основанным на точке зрения системы.
Та же инфраструктура кодирования «Компонента на основе верблюда» используется «сообщением производителя» и «сообщением потребителя». «Компонент на основе верблюда» обеспечивает «конечную точку производителя» для «сообщения производителя» и «конечную точку потребителя» для «сообщения потребителя».
Сообщения могут обрабатываться Camel, когда они маршрутизируются.
Помимо этой маршрутизации, Camel предоставляет специальные функции, такие как «Преобразование типов» и многие другие ...
Одна из вещей, которую вам нужно понять, прежде чем пытаться понять Apache Camel, - это шаблоны интеграции предприятия. Не все в этой области на самом деле знают о них. Хотя вы, безусловно, можете прочитать книгу Enterprise Integration Patterns, более быстрый способ освоить их - это прочитать что-то вроде статьи в Википедии о Интеграция корпоративных приложений.
Если вы прочитали и поняли предметную область, вы с гораздо большей вероятностью поймете цель Apache Camel.
HTH
Если вы знаете о шаблонах интеграции предприятия, 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 и т. Д.
Прочтите эту статью и статья о шаблоне EIP
Как он взаимодействует с приложением, написанным на Java?
Camel использует язык, специфичный для домена Java, или DSL для создания шаблонов интеграции предприятия или маршрутов на различных языках, зависящих от домена (DSL), как указано ниже.
Java DSL - DSL на основе Java, использующий стиль Fluent Builder.
История Enterprise Integration Pattern решается вокруг следующих концепций:
Сообщение, Конечная точка, Производитель, Потребитель, Маршрутизация, Шина, Преобразование и Обработка.
Взгляните на эту статья Анирбана Конара для одного из вариантов использования в реальном времени.
Это что-то, что идет вместе с сервером?
Он действует как мост между несколькими подсистемами предприятия.
Это независимая программа?
Apache Camel, платформа интеграции, объединяет различные независимые приложения.
Главное преимущество Camel: вы можете интегрировать разные приложения с разными технологиями (и разными протоколами), используя одни и те же концепции для каждой интеграции.
Большинство «новых» вещей в вычислительной технике вовсе не новы, это просто загадочная обертка вокруг чего-то, что уже хорошо изучено. Когда их трудно понять, обычно это происходит из-за того, что кто-то решил изобрести новые языковые термины или колонизировать существующие термины для другой цели (хороший пример того, что - это то, что разработчики X отменили то, что «клиент» и "сервер" означают.)
Camel - это оболочка / API на основе Java для межплатформенного ПО промежуточного слоя.
Промежуточное ПО - это общий термин для программного обеспечения, которое предоставляет услуги интерпретации между объектами, не имеющими общего языка или типов данных.
Вот что такое Camel, по сути. Мы можем конкретизировать описание, отметив, что оно обеспечивает промежуточное ПО типа EIP.
Он не предоставляет самого промежуточного программного обеспечения, так как не может знать подробностей того, что приложения должны передавать. Но он предоставляет API для создания инвариантных частей этого промежуточного программного обеспечения (создание начальной точки, создание конечной точки, создание условий для начала и завершения и т. Д.)
Надеюсь, это поможет.
Вот еще одна попытка.
Вы знаете, как существуют такие вещи, как Webmethods, ICAN Seebeyond, Tibco BW, IBM Broker. Все они помогли с интеграционными решениями на предприятии. Эти инструменты широко известны под названием инструменты интеграции корпоративных приложений (EAI).
В основном на основе этих технологий были построены инструменты перетаскивания, и в некоторых случаях вам пришлось бы писать адаптеры на Java. Этот код адаптера либо не был протестирован, либо имел плохие инструменты / автоматизацию при тестировании.
Как и в случае с шаблонами проектирования в программировании, у вас есть шаблоны корпоративной интеграции для общих интеграционных решений. Их прославила одноименная книга Грегора Хопе и Бобби Вульфа.
Хотя вполне возможно реализовать интеграционные решения, использующие один или несколько EIP, Camel - это попытка сделать это в рамках вашей кодовой базы с использованием одного из XML, Java, Groovy или Scala.
Camel поддерживает все шаблоны интеграции предприятия, перечисленные в книге, через свой богатый DSL и механизм маршрутизации.
Итак, Camel - это технология, конкурирующая с другими инструментами EAI, с лучшей поддержкой для тестирования вашего кода интеграции. Код краток из-за доменных языков (DSL). Его читают даже бизнес-пользователи, он бесплатный и позволяет продуктивно работать.
Существует множество фреймворков, которые облегчают нам обмен сообщениями и решение проблем с обменом сообщениями. Одним из таких продуктов является Apache Camel.
Для большинства распространенных проблем есть проверенные решения, которые называются шаблонами проектирования. Шаблон проектирования для обмена сообщениями - это шаблоны интеграции предприятия (EIP), которые хорошо объяснены здесь. Apache camel помог нам реализовать наше решение с использованием EIP.
Сильной стороной интеграционной платформы является ее способность облегчить нам использование EIP или других шаблонов, количество транспортных средств и компонентов, а также простота разработки, по которой Apache camel занимает первое место в списке.
Каждая из фреймворков имеет свои преимущества. Некоторые из особенностей Apache camel следующие.
Говоря простым языком, camel выполняет (многие) вещи без особого кода котельной пластины.
Чтобы дать вам представление, приведенный ниже Java DSL создаст конечную точку REST, которая сможет принимать XML, состоящий из списка продуктов, разбивать его на несколько продуктов и вызывать с ним метод Process BrandProcessor. И просто добавив .parallelProcessing (обратите внимание на закомментированную часть), он будет параллельно обрабатывать все объекты продукта. (Класс продукта - это JAXB / XJC-сгенерированная Java-заглушка из XSD, которой ограничен входной xml.) Этот большой код (вместе с несколькими зависимостями Camel) выполнит работу, которая раньше занимала сотни строк кода 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
Предположим, вы создаете компанию электронной коммерции, такую как Amazon, и хотите сосредоточиться только на стратегии / выборе продуктов для продажи. В отличие от парка доставки Amazon, вместо того, чтобы самостоятельно заниматься перемещением товаров от продавцов на склад, вносить в них изменения на складе, например, упаковывать и отправлять их в другие города и клиентам. Вы нанимаете компанию, которая делает все это, и просто предоставляете им информацию обо всех ваших складах, типах транспортных средств, местах доставки и список того, когда что делать. Затем они справятся с этим сами, это будет Apache Camel. Они позаботятся о перемещении вещей из одного конца в другой, как только вы передадите им материал, чтобы вы могли сосредоточиться на других вещах.
Camel помогает в маршрутизации, трансформации, мониторинге.
Он использует маршруты; который можно описать как:
Когда служебная шина получает определенное сообщение, она не направляет его ни через одно из назначений служб / брокеров, таких как очередь / темы. Этот путь называется маршрутом.
Пример: ваше стандартное приложение получило некоторую информацию от аналитика, оно будет обработано через приложение / веб-компонент, а затем результат будет опубликован для всех заинтересованных / зарегистрированных участников для конкретного обновления акций.
Camel - это фреймворк с согласованным API и моделью программирования для интеграции приложений. API основан на теориях из корпоративных шаблонов интеграции, т. Е. Набора шаблонов проектирования, которые, как правило, используют обмен сообщениями. Он предоставляет готовые реализации большинства этих шаблонов и дополнительно поставляется с более чем 200 различными компонентами. вы можете использовать его, чтобы легко общаться со всеми видами других систем. Чтобы использовать Camel, сначала напишите свою бизнес-логику в POJO и реализуйте простые интерфейсы, ориентированные на сообщения. Затем используйте Camel DSL для создания «маршрутов», которые представляют собой наборы правил для склеивания вашего приложения.
На первый взгляд, функциональность Camel не уступает традиционным продуктам Enterprise Service Bus. Обычно мы думаем о Camel Route как о «посредническом» (также известном как оркестровка) компоненте, который находится на стороне сервера, но поскольку это библиотека Java, ее легко встраивать, и она также может жить в приложении на стороне клиента и поможет вам интегрировать это с услугами точка-точка (иначе хореография). Вы даже можете взять свои POJO, которые обрабатывают сообщения внутри маршрута Camel, и легко включить их в свои собственные процессы удаленного потребителя, например если вам нужно масштабировать только одну деталь самостоятельно. Вы можете использовать Camel для подключения маршрутов или процессоров через любое количество различных удаленных транспортных / протоколов в зависимости от ваших потребностей. Вам нужен чрезвычайно эффективный и быстрый двоичный протокол или более понятный и простой для отладки? Что, если вы захотите переключиться? С Camel это обычно так же просто, как изменить одну или две строки в вашем маршруте и вообще не менять бизнес-логику. Или вы можете поддерживать оба варианта - вы можете запускать сразу несколько маршрутов в контексте Camel.
На самом деле вам не нужно использовать Camel для простых приложений, которые будут жить в одном процессе или JVM - это было бы излишним. Но концептуально это не сложнее, чем код, который вы можете написать самостоятельно. А если ваши требования изменятся, разделение бизнес-логики и связующего кода облегчит поддержку с течением времени. После того, как вы изучите Camel API, его легко будет использовать как швейцарский армейский нож и быстро применять во многих различных контекстах, чтобы сократить количество пользовательского кода, который в противном случае вам пришлось бы писать. Вы можете изучить один вариант - например, Java DSL, свободный API, который легко объединить в цепочку - и легко выбрать другие варианты.
В целом Camel отлично подходит, если вы пытаетесь использовать микросервисы. Я считаю, что это бесценно для эволюционной архитектуры, потому что вы можете отложить принятие многих сложных, «легко ошибочных» решений о протоколах, транспорте и других проблемах системной интеграции, пока не узнаете больше о своей проблемной области. Просто сосредоточьтесь на своих EIP и основной бизнес-логике и переходите на новые маршруты с «правильными» компонентами, когда узнаете больше.
Apache Camel - это среда Java для корпоративной интеграции. Например: - если вы создаете веб-приложение, которое взаимодействует с API многих поставщиков, мы можем использовать верблюда в качестве инструмента внешней интеграции. Мы можем сделать с ним больше в зависимости от варианта использования. Camel in Action из публикаций Мэннинга - отличная книга для изучения верблюдов. Интеграции можно определить, как показано ниже.
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");
Это просто создание конечной точки REST API, которая, в свою очередь, вызывает внешний 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>
Переходя к вашим вопросам
Надеюсь, это поможет
Да, наверное, немного поздно. Но одна вещь, которую следует добавить к комментариям всех остальных, заключается в том, что Camel на самом деле представляет собой набор инструментов, а не полный набор функций. Вы должны иметь это в виду при разработке и выполнять различные преобразования и преобразования протоколов.
Сам Camel полагается на другие фреймворки, и поэтому иногда вам нужно понимать и их, чтобы понять, какая из них лучше всего подходит для ваших нужд. Например, существует несколько способов обработки REST. Поначалу это может немного сбивать с толку, но как только вы начнете использовать и тестировать, вы почувствуете себя непринужденно, и ваши знания о различных концепциях увеличатся.
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
From / to ---- folder, direct, seda, vm может быть любым
Другая точка зрения (основанная на более фундаментальных математических темах)
Наиболее распространенной вычислительной платформой является машина Тьюринга.
Проблема с машиной Тьюринга. Все данные ввода / вывода остаются внутри машины Тьюринга. В реальном мире есть источники ввода и приемники вывода, внешние по отношению к нашей машине Тьюринга и в целом управляемые системами вне нашего контроля. То есть эта внешняя система будет отправлять / получать данные по желанию в любом формате с любым желаемым планировщиком данных.
Вопрос: Как нам удается заставить независимые машины Тьюринга разговаривать друг с другом самым общим способом, чтобы каждая машина Тьюринга рассматривала своих сверстников либо как источник входных данных, либо как приемник выходных данных?
Ответ: Использование чего-то вроде camel, mule, BizTalk или любой другой ESB, которая абстрагируется от обработки данных между завершением отдельных физических (или виртуальных программных) машин Тьюринга.
