Ответы:
Если у вас есть от 5 до 10 минут, я обычно рекомендую людям прочитать эту Интеграцию с Apache Camel Джонатана Ансти. Это хорошо написанная часть, которая дает краткое введение и обзор некоторых концепций Camel, а также реализует пример использования с примерами кода. В нем Джонатан пишет:
Apache Camel - это инфраструктура Java с открытым исходным кодом, цель которой - сделать интеграцию проще и доступнее для разработчиков. Это достигается путем предоставления:
- конкретные реализации всех широко используемых шаблонов корпоративной интеграции (EIP)
- подключение к большому количеству транспортов и API
- простые в использовании доменно-ориентированные языки (DSL) для соединения EIP и транспорта
Существует также бесплатная глава « Верблюд в действии», в которой рассказывается о верблюде в первой главе. Джонатан соавтор этой книги со мной.
Я хочу описать это более доступным способом ...
Чтобы понять, что такое Apache Camel, вам необходимо понять, что такое шаблоны корпоративной интеграции.
Давайте начнем с того, что мы, по-видимому, уже знаем: шаблон Singleton, шаблон Factory и т. Д .; Это всего лишь способы организации вашего решения проблемы, но сами они не являются решениями. Эти паттерны были проанализированы и извлечены для остальных из нас Бандой Четырех, когда они опубликовали свою книгу « Конструктивные паттерны» . Они спасли некоторых из нас огромными усилиями в размышлениях о том, как лучше структурировать наш код.
Так же, как «Бригада четырех», Грегор Хопе и Бобби Вульф создали книгу « Шаблоны корпоративной интеграции (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) для настройки правил маршрутизации и передачи. Специфичный для домена язык означает, что Apache Camel может поддерживать интеллектуальное завершение правил маршрутизации в вашей среде IDE с безопасным типом, используя обычный код Java без огромного количества файлов конфигурации XML; хотя конфигурация XML внутри Spring также поддерживается.
Видеть? Это было не сложно, не так ли?
Короче говоря:
Когда требуется подключить / интегрировать системы, вам, вероятно, потребуется подключиться к некоторому источнику данных и затем обработать эти данные в соответствии с требованиями вашего бизнеса.
Для этого:
1) Вы можете разработать специальную программу, которая будет делать это (может быть трудоемким и трудным для понимания, сопровождение для другого разработчика)
2) В качестве альтернативы, вы можете использовать Apache Camel, чтобы сделать это стандартизированным способом (большинство соединителей уже разработано для вас, вам просто нужно настроить его и подключить свою логику - называемую Process):
Верблюд поможет вам:
Используя Apache Camel, вы упростите понимание / поддержку / расширение вашей системы другому разработчику.
Apache Camel разработан с использованием корпоративных шаблонов интеграции. Шаблоны помогают вам хорошо интегрировать системы :-)
Верблюд отправляет сообщения от А до Б:
Зачем целая основа для этого? Ну, что если у вас есть:
ftp
, http
, jms
и т.д.)Итак, теперь вам нужно:
Верблюд дает вам выше (и больше) из коробки:
с классным языком 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
нести: маршрут
пассажиры: сообщение;
город: система;
аэропорт: верблюжий компонент;
понимание местных языков: преобразование типов;
отправление: производство, производство
прибывающий: потребляющий, потребляемый
путешествия: разгромлен
удобства: предоставляются
После замены слов вот что вы получаете:
Цель 'Apache Camel' - направлять «сообщения» из одной «системы» в другую в мире. Верблюд Apache использует различные транспортные механизмы для маршрутизации сообщений.
Apache Camel получает сообщения, используя «компонент на основе верблюда» системы «от», и отбрасывает их с помощью «компонента на основе верблюда» системы «на». Сообщение может направляться в несколько систем, но везде они должны проходить через «Компоненты на основе Camel», чтобы перемещаться между «основным транспортным механизмом Apache Camel» и системой.
Обратите внимание, что сообщение, «созданное» из системы, по сути «потребляется» в базовый транспортный механизм Apache Camel ». И сообщение, потребляемое системой, по сути, создается «базовым транспортным механизмом Apache Camel».
Поскольку мы пытаемся понять верблюда, мы должны думать с точки зрения верблюда здесь и далее. Таким образом, значения терминов «сообщение потребителя» и «сообщение производителя» полностью противоположны нашим традиционным представлениям, которые основаны на ракурсе системы.
Та же инфраструктура кодирования «Camel-компонента» используется «сообщениями-производителями» и «сообщениями-потребителями». «Компонент на основе верблюда» предоставляет «конечную точку производителя» для «сообщения производителя» и «конечную точку потребителя» для «сообщения потребителя».
Сообщения могут быть обработаны Camel, когда они маршрутизируются.
Помимо этой маршрутизации, Camel предоставляет специальные функции, такие как «Преобразование типов» и многие другие ...
Прежде чем пытаться понять Apache Camel, вам необходимо понять, что такое Enterprise Integration Patterns. Не все в этой области на самом деле знают о них. Хотя вы, безусловно, можете прочитать книгу «Шаблоны интеграции предприятия», более быстрый способ освоить их - прочитать что-то вроде статьи в Википедии об интеграции приложений предприятия. .
Когда вы прочитали и поняли предметную область, вы, скорее всего, поймете цель Apache Camel
НТН
Если вы знакомы с корпоративными шаблонами интеграции, Apache Camel - это одна инфраструктура интеграции, которая реализует все EIP.
И вы можете развернуть Camel как отдельное приложение в веб-контейнере.
По сути, если вам нужно интегрировать несколько приложений с разными протоколами и технологиями, вы можете использовать Camel.
Определение с другой точки зрения:
Apache Camel - это интегрированная среда. Он состоит из нескольких библиотек Java, которые помогут вам реализовать проблемы интеграции на платформе Java. Что это означает и чем оно отличается от API с одной стороны и Enterprise Service Bus (ESB) с другой стороны, описано в моей статье « Когда использовать Apache Camel ».
Что именно это?
Apache Camel - это облегченная инфраструктура интеграции, которая реализует все шаблоны Enterprise Integration. Вы можете легко интегрировать различные приложения, используя необходимые шаблоны.
Вы можете использовать Java, Spring XML, Scala или Groovy. Доступны практически все технологии, которые вы можете себе представить, например, HTTP, FTP, JMS, EJB, JPA, RMI, JMS, JMX, LDAP, Netty и т. Д.
Взгляните на эту статью и статью EIP pattern
Как это взаимодействует с приложением, написанным на Java?
Camel использует язык, специфичный для домена Java, или DSL для создания корпоративных шаблонов интеграции или маршрутов на различных языках, специфичных для домена (DSL), как указано ниже.
Java DSL - основанный на Java DSL, использующий свободный стиль построения.
История Enterprise Integration Pattern основана на следующих концепциях:
Сообщение, Конечная точка, Производитель, Потребитель, Маршрутизация, Шина, Преобразование и Процесс .
Взгляните на эту статью Анирбана Конара для одного из вариантов использования в реальном времени.
Это что-то, что идет вместе с сервером?
Он действует как мост через несколько корпоративных подсистем.
Это независимая программа?
Apache Camel, интегрированная среда, объединяет различные независимые приложения.
Основное преимущество Camel : вы можете интегрировать разные приложения с разными технологиями (и разными протоколами), используя одни и те же концепции для каждой интеграции.
Большинство «новых» вещей в вычислительной технике вовсе не новы, они просто загадочная оболочка вокруг чего-то, что уже хорошо понято. Когда их трудно понять, обычно это происходит потому, что кто-то решил изобрести новые языковые термины или колонизировать существующие термины для другой цели (хороший пример этого является изменение X-разработчиками того, что означают «клиент» и «сервер»).
Camel - это Java-оболочка / API для межплатформенного промежуточного программного обеспечения.
Промежуточное программное обеспечение - это общий термин для программного обеспечения, которое предоставляет услуги по интерпретации между объектами, которые не используют общий язык или типы данных.
Вот что такое Верблюд, внизу. Мы можем конкретизировать описание, отметив, что оно предусматривает промежуточное программное обеспечение типа 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.
Большинство общих проблем имеют проверенные решения, называемые шаблонами проектирования. Шаблон дизайна для обмена сообщениями - это шаблоны корпоративной интеграции (EIP), которые хорошо объяснены здесь. . Apache верблюд поможет нам реализовать наше решение с использованием EIP.
Сила интегрированной среды - это ее способность облегчать нам работу с помощью EIP или других шаблонов, количество транспортных средств и компонентов, а также простота разработки, благодаря которой верблюд Apache стоит на вершине списка.
Каждая из рамок имеет свои преимущества. Некоторые из особенностей верблюда Apache заключаются в следующем.
Говоря простым языком, верблюд делает (много) вещей, не прибегая к большому количеству кода котельной плиты.
Просто чтобы дать вам представление, Java DSL, приведенный ниже, создаст конечную точку REST, которая сможет принимать XML, состоящий из Списка продуктов, и разбивать его на несколько продуктов и вызывать с ним метод Process BrandProcessor. И просто добавив .parallelProcessing (обратите внимание на закомментированную часть), он будет параллельно обрабатывать все объекты Product. (Класс продукта - это сгенерированный 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);
Это всего лишь пример, верблюд - намного больше, чем просто конечная точка ОТДЫХА. Просто посмотрите список подключаемых компонентов http://camel.apache.org/components.html
Верблюд помогает в маршрутизации, трансформации, мониторинге.
Использует маршруты; который может быть описан как:
Когда сервисная шина получает конкретное сообщение, она направляет его через ни одно из сервисов / пунктов назначения брокера, таких как очередь / темы. Этот путь известен как маршрут.
Пример: ваше фондовое приложение получило некоторую информацию от аналитика, оно будет обработано через прикладной / веб-компонент, а затем результат будет опубликован всем заинтересованным / зарегистрированным участникам для конкретного обновления акций.
Предположим, вы создаете компанию электронной коммерции, такую как Amazon, и хотите сосредоточиться только на стратегии / выборе продуктов для продажи. в отличие от парка доставки Amazon, вместо того, чтобы самостоятельно обрабатывать перемещение товаров от продавцов на склад, вносить изменения в него на складе, например, в упаковку и отправлять его в другие города и покупателям. Вы нанимаете компанию, которая делает все это, и просто даете им информацию обо всех местах вашего склада, типах транспортных средств, местах доставки и список того, когда и что делать. Тогда они справятся с этим сами, это будет Apache Camel. Они заботятся о перемещении вещей с одного конца на другой, как только вы передадите им вещи, чтобы вы могли сосредоточиться на других вещах.
Camel - это фреймворк с согласованным API и моделью программирования для интеграции приложений. API основан на теориях в шаблонах Enterprise Integration Patterns - то есть на наборе шаблонов проектирования, которые обычно используют обмен сообщениями. Он предоставляет готовые реализации большинства из этих шаблонов и дополнительно поставляется с более чем 200 различными компонентами. вы можете использовать, чтобы легко общаться со всеми видами других систем. Чтобы использовать Camel, сначала напишите свою бизнес-логику в POJO и внедрите простые интерфейсы, сосредоточенные вокруг сообщений. Затем используйте DSL Camel для создания «маршрутов», которые представляют собой наборы правил для склеивания вашего приложения.
На первый взгляд, функциональность Camel конкурирует с традиционными продуктами Enterprise Service Bus. Обычно мы думаем о том, что Camel Route является компонентом-посредником (он же оркестровка), который живет на стороне сервера, но поскольку это библиотека Java, ее легко внедрить, и она также может жить в клиентском приложении и помочь вам в интеграции. это с услугами точка-точка (хореография). Вы даже можете взять свои POJO, которые обрабатывают сообщения внутри маршрута Camel, и легко выделить их в свои собственные процессы удаленного потребителя, например, если вам нужно было масштабировать только одну часть независимо. Вы можете использовать Camel для подключения маршрутов или процессоров через любое количество различных удаленных транспортных протоколов / протоколов в зависимости от ваших потребностей. Вам нужен чрезвычайно эффективный и быстрый двоичный протокол, или тот, который более читабелен и легок в отладке? Что если вы хотите переключиться? С верблюдом это обычно так же просто, как изменить одну или две строки в вашем маршруте и вообще не менять какую-либо бизнес-логику. Или вы можете поддерживать оба - вы можете запускать сразу несколько маршрутов в контексте верблюда.
Вам не нужно использовать Camel для простых приложений, которые будут работать в одном процессе или в JVM - это было бы излишним. Но концептуально это не сложнее, чем код, который вы можете написать сами. А если ваши требования меняются, разделение бизнес-логики и связующего кода облегчает сопровождение с течением времени. Как только вы изучите API Camel, вы легко сможете использовать его как швейцарский армейский нож и быстро применять его во многих различных контекстах, чтобы сократить объем пользовательского кода, который вам пришлось бы писать. Вы можете изучить один вариант - Java DSL, например, плавный API, который легко объединить в цепочку, - и легко выбрать другие варианты.
В целом, верблюд отлично подходит, если вы пытаетесь делать микроуслуги. Я нашел его бесценным для эволюционной архитектуры, потому что вы можете отложить множество трудных, «легко ошибающихся» решений о протоколах, транспортах и других проблемах системной интеграции, пока не узнаете больше о своей проблемной области. Просто сосредоточьтесь на своих EIP и основной бизнес-логике и переходите на новые маршруты с «правильными» компонентами, когда узнаете больше.
Да, это, вероятно, немного поздно. Но одна вещь, которую нужно добавить к комментариям всех остальных, это то, что Camel - это на самом деле набор инструментов, а не полный набор функций. Вы должны помнить об этом при разработке и должны делать различные преобразования и преобразования протокола.
Сам верблюд опирается на другие структуры, и поэтому иногда вам также необходимо понимать их, чтобы понять, что лучше всего подходит для ваших нужд. Есть, например, несколько способов обработки REST. Поначалу это может немного запутать, но как только вы начнете использовать и тестировать, вы почувствуете себя непринужденно, и ваши знания различных концепций возрастут.
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>
Приходя на ваши вопросы
Надеюсь, поможет
Apache Camel - это легкая интегрированная среда, которая реализует все шаблоны Enterprise Integration. Вы можете легко интегрировать различные приложения, используя необходимые шаблоны. Вы можете использовать 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
От / до ---- папка, direct, seda, vm может быть чем угодно
Другая точка зрения (на основе более фундаментальных математических тем)
Самая общая вычислительная платформа - это [ https://en.wikipedia.org/wiki/Turing_machine]
Есть проблема с машиной Тьюринга. Все входные / выходные данные остаются внутри машины Тьюринга. В реальном мире существуют входные источники и выходные приемники, внешние по отношению к нашей машине Тьюринга и в целом управляемые системами вне нашего контроля. То есть эти внешние системы будут отправлять / получать данные по желанию в любом формате с любым желаемым планировщиком данных.
Вопрос: Как нам удается заставить независимые машины Тьюринга общаться друг с другом наиболее общим образом, чтобы каждая машина Тьюринга воспринимала своих пиров как источник входных данных или приемник выходных данных?
Ответ: Использование чего-то вроде верблюда, мула, BizTalk или любого другого ESB, который абстрагирует обработку данных между завершением отдельных «физических» (или виртуальных программ) машин тьюринга.