Фреймворк Camel: сравнение компонентов HTTP и AHC

[@sshikov]

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

P.S. Версия Java кстати тоже не помешает. Много потоков, много создаваемых объектов, влияние GC вполне может быть сильным. Не говоря уже про то, что если вы что-то меряете — то потребление ресурсов, таких как память и процессор, тоже интересно было бы поглядеть. Поэтому — как можно более полное описание тестового стенда :)

[@shmakovaa]

Добавил описание версий Camel и Java, а тестового стенда как такового и нет, все делалось на обычном ПК

[@sshikov]

Ну, параметры ПК же тоже интересны — ну хотя бы, сколько ядер, сколько памяти?

[@Gokudera]

Camel — нечто нечитаемое и непостижимое.

from(«jetty:http://localhost:8080/test») //допустим, создали endpoint принимающий запросы

.log(«receive request body ${body}») // ${body} — магическая константа.

.removeHeaders(«CamelHttp*») //ну конечно же каждый разработчик от рождения знает: «удаление заголовков, начинающихся на „CamelHttp“ необходимо потому, что они выставляются в Jetty-компоненте и могут повлиять на работу Http-компонента.»

.to(«http://{{another.url}}?connectionsPerRoute=200») //почему это connectionsPerRoute=200 находится в урле? а если мне нужно передать в запросе параметр зарезервированный в camel?

.log(«finish process body ${body}»);//${body} — магическая константа.А куда делся запрос который пришел на «jetty:http://localhost:8080/test»

и что в конце концов получит вызвавший endpoint?

[@1nd1go]

Теперь так много где стало, увы. Надо просто верить в «магию»

[@sshikov]

В camel кстати нет практически никакой магии — там все весьма прозрачно (да, я код не только читал, но и собирал патчи к некоторым компонентам). И не просто прозрачно — а практически совсем не менялось с самого момента его рождения.

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

[@DarkSavant]

Справедливости ради, тут всё же речь о замерах, как я понял, а не об основах Camel.
Вообще Camel, по моему, классный фреймворк. По возможностям похож на Spring Integration, но мне верблюд как-то ближе.
Я вообще уже некоторое время подумываю написать про него статью, что и как работает. Только не уверен, интересно ли кому.

[@sshikov]

Уже была. И очень неплохая.

[@1nd1go]

Какая?

[@sshikov]

Блин, да вот попытался найти, но она куда-то в дебри хабра пропала. Борисов кажется автор, и там не совсем camel, а скорее ServiceMix + Camel, и в целом она про ESB.

Если найду — отпишусь непременно. Если кто возьмется писать новую — я с радостью поучаствую в любом формате.

[@shmakovaa]

В начале статьи указано, что основы Camel рассматриваться не будут. Для этого уже есть хорошие статьи на просторах интернета, правда англоязычные, но все же. Более углубленно про него можно прочитать в книге Camel in Action основателя фреймворка Claus Ibsen. Либо изучать документацию на официальном сайте.
Вкратце по вопросам:
${body} не константа, а наоборот выражение на встроенном Simple-языке, автоматически подставляет тело сообщения.
.to(«http://{{another.url}}?connectionsPerRoute=200») Если нужно передать в запросе параметр зарезервированный в camel, то можно просто задать заголовок с нужным именем — он автоматически будет передан в сервис как HTTP-заголовок.

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