Подтвердить что ты не робот

Apache Camel: работают ли процессоры и Beans с той же целью?

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

4b9b3361

Ответ 1

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

Beans обеспечивают большую гибкость, а также поддерживают истинный подход POJO. Это позволяет вам более легко интегрироваться с существующими API (просто нужно преобразовать входы/выходы в соответствие и т.д.).

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

Ответ 2

Я бы сказал, что это зависит от предпочтений. Обычно я выбираю подход POJO, поэтому я начал использовать beans для выполнения моей обработки, но со временем я медленно перешел к использованию процессоров.

Я чувствовал боль в следующих случаях:

  • Bean методы с несколькими параметрами
  • Попытка получить данные из параметров обмена/заголовков сообщений

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

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

Только мои 2 цента - маршрут bean действительно не плохой - он тоже будет работать (esp в 2.8)

ИЗМЕНИТЬ

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