Бизнес-логика в процессорах Camel против конечных точек обслуживания - PullRequest
Новая
       6

Бизнес-логика в процессорах Camel против конечных точек обслуживания

7 голосов
/ 23 февраля 2012

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

Кажется, что четкое разделение интересов заключается в использовании Camel только для посредничества и оркестровки, с использованием процессоров в качестве фильтров, а не в качестве контейнера для бизнес-логики. Однако в настоящее время я не вижу необходимости в контейнере EJB, и мне кажется, что он мне нужен для размещения MDB.

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

Ответы [ 2 ]

11 голосов
/ 23 февраля 2012

Обычно я использую Camel для выполнения следующих действий:

  • любой компонент интеграция (файл, jms, http и т. Д.)
  • для реализации логика EIP (маршрутизация на основе содержимого, фильтры, регулирование и т. Д.)
  • процессы на основе таймера (с использованием таймер или кварц )
  • обработка исключений (логика повторов, регистрация ошибок / уведомление / постановка в очередь)

В противном случае для автономной бизнес-логики (особенно унаследованной интеграции) может оказаться предпочтительным использовать POJO или веб-сервисы.Это повышает тестируемость и делает ваше приложение более модульным и т. Д. Затем вы можете использовать Camel для следующего ...

  • для взаимодействия с этими службами, используя Процессоры , Связывание Bean и CXF
  • для связывания этих сервисов вместе в маршруты
  • управление / мониторинг потока сообщений, обработка исключений

InЧто касается длительных процессов, Camel может облегчить это с помощью различных асинхронных шаблонов / технологий (JMS, CXF, опросы потребителей, запланированные задания и т. д.), а также дает вам контроль над многопоточностью ...

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

0 голосов
/ 24 февраля 2012

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

Итак, самая важная часть - не смешивать их в одном классе. Разделять их на отдельные единицы развертывания может иметь смысл, но это менее важно.

Camel может очень хорошо использоваться для реализации "bean-компонентов, управляемых сообщениями". Просто определите свои структуры данных, используя аннотации pojos + JAXB, или сгенерируйте их из XSD. Затем вы можете использовать верблюжий обмен сообщениями pojo, чтобы подключить их к конечным точкам http, jms или даже файла.

См. http://www.liquid -reality.de / x / NoBe

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

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

...