LINUX.ORG.RU

Apache Camel 2.14.0

 , ,


3

1

Сегодня, 19 сентября, вышла в свет новая версия интеграционного фреймворка Apache Camel 2.14.0. При подготовке релиза было закрыто около 399 задач (добавление нового функционала, улучшения и исправления).

Основные изменения:

  • поддержка работы на виртуальных машинах Java JVM 1.8;
  • поддержка Spring 4.x; модуль camel-test-spring теперь работает только с Spring 4.x. Для поддержки Spring 3.x создан отдельный модуль camel-test-spring3;
  • добавлен REST DSL для упрощённого создания RESTful сервисов. Новый DSL можно использовать в Java DSL и Spring XML DSL. Кроме того, REST DSL был интегрирован с Swagger;
  • в sql компоненте появилась возможность использовать Simple выражения для определения sql параметров;
  • добавлен RuntimeEndpointRegistry для сбора статистики использования ендпойнтов (endpoint);
  • в camel-jackson добавлена возможность пропускать null значения при формировании выходного JSON;
  • также camel-jackson теперь позволяет указывать ожидаемый класс при демаршаллинге с использованием хедеров (header);
  • Компонент Quartz2 получил возможность использования задач, хранимых в базе данных;
  • и многое другое.

Коме того, в новой версии реализован паттерн интеграции Circuit Breaker в качестве режима балансировщика нагрузки.

>>> Подробности

★★

Проверено: Shaman007 ()

На самом деле, изменений намного больше. Я сам пока во все ещё не вник.

Hater ★★ ()

можно в двух словах , для чего оно надо ?
это некий мета-язык или что ?

kto_tama ★★★★★ ()
Ответ на: комментарий от kto_tama

можно в двух словах , для чего оно надо ?

Для осуществления интеграции различных информационных систем. Особенно он уместен если лезть в эти системы ты не можешь, а научить общаться их между собой необходимо.

это некий мета-язык или что ?

DSL - лишь малая часть кемела. Можно например описывать интеграцию и через аннотации, хотя не рекомендую, она всё ещё работает очень криво. Так же кемел включает в себя огромное количество компонентов на все случаи жизни. Есть например даже компонент для твиттера :)

Hater ★★ ()
Последнее исправление: Hater (всего исправлений: 1)

Жуть, какая-то супер-мега-advanced-technology ^_^ Не дорос я до таких фреймворков чтоб такую энтерпрайзщину понимать :)

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Жуть

Да ну, оно няшное. Сейчас его понемногу приводят к такому виду, что будем просто в графическом интерфейсе роут из блоков накидывать. Такие намётки есть уже в Fuse IDE и активно нынче развиваемом редхатовцами hawtio.

Hater ★★ ()

Почему у Apache большинство проектов на Java?

bluesman ()

Похоже, это просто уберэнтерпрайз

GblGbl ★★★★★ ()

А чего за верблюд такой? В википедии пара слов про сообщения из которых ничего не понятно.
CP давай разжуй чёпачем! ЗЫ. Прочитал твои посты. Непонятки остались.

vada ★★★★★ ()
Последнее исправление: vada (всего исправлений: 1)
Ответ на: комментарий от vada

В википедии пара слов про сообщения из которых ничего не понятно.

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

Этот фреймворк является ядром некоторых современных ESB систем (JBoss Fuse, ServiceMix и то ли Talend, то ли MuleESB). В чём удобство: на нём можно в несколько строчек наваять простой и легко читаемый роут для интеграции.

Вся его идея основана на ентерпрайзных паттернах интеграции. Каждый роут по сути состоит из 1 или нескольких ендпойнтов (входных точек), которые по сути соединены с чем-либо по своему протоколу (JMS очередь, БД, HTTP, файловая система, даже твиттер, тысячи их!). Т.е. Роут представляет собой некую маршрутизацию от одного ендпойнта к заданным по требуемым критериям к содержимому с возможной трансформацией. Например, если по телу сообщения мы видим, что это для Васи Пупкина, то мы шлём его ему на мыло. А если видим, что Лёне Поттерингу, то добавляем к исходному сообщению «systemd не нужен» и постим ему в гугл+.

Короче тут можно долго распыляться. На тему кемела написано не мало книжек.

Hater ★★ ()
Ответ на: комментарий от Hater

Например, если по телу сообщения мы видим, что это для Васи Пупкина, то мы шлём его ему на мыло. А если видим, что Лёне Поттерингу, то добавляем к исходному сообщению «systemd не нужен» и постим ему в гугл+.

а мне объясняли что бизнес задачами шина не должна заниматься, а только передачей сообщений и преобразованием форматов. То есть в данном случае именно системы должны говорить ей кому какое сообщение отправить, а не рассчитывать на магические правила внутри. Хотя это было про оракл есб и как часть ежедневного вайна от разработчика :)

tulskiy ()
Ответ на: комментарий от tulskiy

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

anonymous ()

А чем он лучше Spring Integration?

f1xmAn ★★★★★ ()
Ответ на: комментарий от f1xmAn

Много больше (число готовых адаптеров к источникам данных несравнимо) и гибче в настройке.

Для труъ - эти штуки (enterprise service bus) нужны для маршрутизации потоков данных между сторонними системами. Когда в большой организации маршруты данных становятся похожи на карту улиц в центре дс, тогда и нужен Camel (или его корпоративные сородичи).

anonymous ()
Ответ на: комментарий от Hater

Для осуществления интеграции различных информационных систем. Особенно он уместен если лезть в эти системы ты не можешь, а научить общаться их между собой необходимо.

Ну camel это слишком низкоуровневое решение, только транспорт и роутинг. ServiceMix с друзьями не спроста появились.

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

Хоть свой велик пиши, ей богу.

bj ()
Ответ на: комментарий от bj

На каждодневные задачи интеграции лучше писать максимально конкретный код руками, чем интеграционных монстров использовать. Это будет гораздо быстрее, а главное результат выше качеством (обработка ошибок, стриминг и т.п.). Обычному бизнесу надо конкретные задачи решать, а не шины настраивать. Вот когда бизнес становится достаточно большим и гетерогенным (т.е. для 99% компаний - никогда), тогда приходят шины.

anonymous ()
Ответ на: комментарий от anonymous

На каждодневные задачи интеграции лучше писать максимально конкретный код руками

И каждый раз этот код обрастает обработкой ошибок, гарантированной доставкой, повторами отправок при фейлах, косыми реализациями DLQ и т.п.

Вот бы какой-нибудь фреймворк на скриптоте, который на себя берет всю эту муть.

bj ()

Используем эту крутотень в банке. Для интеграции фронтофиса с бэкофисом. Проще простого. Складывается как lego. Один челоек способен создать приложение которое делает все что нужно вместо того чтобы пятьдесят индусов придумывали велосипеды и все равно сделали криво и убого

zapruder ()
Последнее исправление: zapruder (всего исправлений: 1)
Ответ на: комментарий от bj

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

В целом да.

Но иногда все проще, чем кажется: ESB - Talend Open Studio for ESB in 60 Seconds - REST Endpoint =)

Harliff ★★★★★ ()
Ответ на: комментарий от f1xmAn

s-i много чего нет для нормальной интеграции, например я сразу столкнулся с тем что нет готовой реализации Idempotent Consumer - приходится велосипедить вручную + на мой взгляд в s-i конфигурации писать приходится больше, чем в camel

maloi ★★★★★ ()
Последнее исправление: maloi (всего исправлений: 1)

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

dycore ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.