Я работаю над приложением, которое использует Apache Camel для передачи одного сообщения-запроса (ввода) через некоторые исходные компоненты / логику Camel, а затем в многоадресную передачу, после чего маршрут разветвляется на несколько ветвей.Цель каждой ветви состоит в том, чтобы извлекать данные из определенной веб-службы (или другого внутреннего источника данных, например базы данных), а затем после завершения операции вызова / извлечения данных веб-службы каждая из ветвей сбрасывает свои выходные данные в одну и ту жепуть через пользовательскую конечную точку бина.Я ожидаю, что в конечном итоге в маршруте Camel будет примерно 40 различных ветвей, каждая из которых может проходить через свой набор компонентов Camel для подготовки своего запроса, отправки запроса, обработки ответа и т. Д. Я ожидаю, чточисло ветвей будет очень похожим (например, все вызовы SOAP очень похожи, все вызовы REST очень похожи и т. д.) и поэтому разработали подход, при котором в файле конфигурации хранится список внутренних источников данных, которые должны быть вызваны / извлечены.наряду со способностью определять (косвенно) маршрут, который должен быть выбран для достижения каждого из этих источников.Файл конфигурации выглядит примерно так:
[a]
route=X + Y
Y.url=http://someservice
[b]
route=Z
Z.someproperty=123
А затем у меня есть код, который читает этот файл конфигурации и обрабатывает каждый из «разделов» (например, «[a]», «[b]»,и т. д.) как ветвь (т. е. пункт назначения из многоадресной рассылки) и полагается на классы, которые создаются динамически (например, XRouteSegment, YRouteSegment, ZRouteSegment), чтобы каждый в свою очередь заполнял / определял маршрут для своей конкретной ветки.В качестве некоторых примеров я построил вспомогательные классы RouteSegment для подключения таких компонентов, как Velocity, CXF, CXF-RS, для маршалинга / демаршаллинга данных и т. Д., На основе свойств, установленных в файле конфигурации.
Насколько это возможноПо мере инициализации контекста Camel он начинается довольно типичным образом с одного RouteBuilder, который выстраивает первую часть маршрута до многоадресной рассылки.Но затем я вхожу в цикл for и перебираю все источники, найденные в файле конфигурации (например, «a», «b» и т. Д.), И создаю узлы seda для каждого из тех, в которые направляется многоадресная рассылка.Затем я вызываю каждый из экземпляров RouteSegment, связанных с данным источником (например, X + Y), и позволяю им добавлять их в RouteDefinition по мере необходимости (например, из начальной точки седы в будущем).И затем, возвращаясь в свой «основной» RouteBuilder, я добавляю некоторые окончательные маршруты / компоненты, которые должны быть одинаковыми для всех ветвей (т. Е. Логика, которая заставляет каждую из ветвей хранить свои данные через один и тот же пользовательский компонент).
Код работает просто отлично, но я задаюсь вопросом, является ли этот подход излишним и / или есть ли какой-то более простой / чистый способ сделать это, который я пропускаю.Будет ли лучше иметь отдельные классы Java (например, RouteBuilders) для каждой из ветвей (в дополнение к «стволам» и «хвостам» маршрута)?Чего я пытался избежать, так это слишком большого количества дублирующейся логики / кода во всех этих классах ... например, в 20 классах все данные извлекаются из веб-сервисов SOAP практически одинаково.Поэтому я использую экземпляр RouteSegment, такой как «X», на который ссылаются выше, в качестве сокращенного обозначения для повторного использования для того, что в противном случае было бы последовательностью различных вызовов DSL Camel Java (например, из / в / process / log / etc ... с параметрами для управленияспецифика отдельных высказываний).Существуют ли другие стратегии / подходы, которые я должен рассмотреть, чтобы динамически построить маршрут Camel (+ значительное количество веток) во время выполнения (например, в цикле for, или с помощью какого-либо процесса отражения / обнаружения (приложение запускается с использованием Spring Boot)))?
Заранее благодарим за любые идеи, которые вы могли бы предоставить / предложить, что я, возможно, еще не подумал / не попробовал!