Apache Camel: полная независимость информации о маршрутизации от кода Java.

Прежде всего, спасибо людям, которые в настоящее время участвуют в разработке Camel, я благодарен за всю тяжелую работу, которую они проделали.

Мне нужен совет по дизайну.

Архитектура примерно такая: у меня есть несколько классов Java, которые при создании экземпляров должны соединяться друг с другом и отправлять сообщения с помощью Apache Camel. Ограничения дизайна требуют, чтобы я создал структуру, в которой вся информация о маршрутизации, производители, потребители, конечные точки и т. Д. Должны быть частью camel-context.xml.

Человек должен иметь возможность изменять такой файл и полностью изменять существующий маршрут, не имея доступного Java-кода (Java-код не будет предоставлен, будет только скомпилированный Jar)

Например, в одной настройке Bean A -> Bean B-> Bean C-> файл-> электронная почта. в другом Bean B-> Bean A-> Bean C-> ftp-> file-> email Мы пробовали разные подходы, но если исходный компонент не реализован как Java DSL, скорость сообщений очень высока, потому что верблюд постоянно вызывает Bean A в первом примере и Bean B в первом примере. второй (они являются источником).

Bean A и Bean B создают сообщения и управляются событиями. В случае возникновения необходимого события bean-компоненты отправляют сообщение с уведомлением.

Мои преобразования очень просты, и мне совсем не нужна мощь Java DSL. Подводя итог, у меня есть следующие вопросы:

1) Принимая во внимание указанные выше ограничения, могу ли я гарантировать, что вся информация о маршрутизации, включая адреса назначения, является частью файла контекста верблюда?

2) Есть ли пример, на который я могу посмотреть, чтобы информация о маршрутизации полностью независима от кода Java?

3) Как убедиться, что Camel не вызывает постоянно исходный компонент?

4) Постоянно ли Camel вызывает только исходный bean-компонент или любой bean-компонент, который он отправляет и которому отправляет сообщения, независимо от положения bean-компонента во всей очереди сообщений?

У меня закончились варианты, пытаясь различными способами настроить это. Любая помощь будет оценена по достоинству.


person Community    schedule 04.10.2010    source источник


Ответы (2)


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

Еще лучше подумайте о покупке книги «Верблюд в действии» и прочтите об этом главу 14. http://www.manning.com/ibsen/

Сэкономьте 41% на книгах по укомплектованию персоналом: Camel в действии или ActiveMQ в действии. Используйте код s2941. Срок действия истекает 6 окт. http://www.manning.com/ibsen/

person Community    schedule 04.10.2010
comment
Спасибо, достал книгу. Глава 14 выглядит довольно интересно. Я вас снова подведу, если у меня возникнут еще вопросы. - person smschauhan; 04.10.2010
comment
Думаю, мне стоит отказаться от идеи реализовать это внутри Fuse Servicemix. Конфигурация в главе 14 работает только верблюд: беги. Его невозможно выполнить при развертывании в servicemix. - person smschauhan; 03.11.2010
comment
Вы по-прежнему можете использовать ServiceMix, поместив весь Java-код в пакет и развернув его, одновременно перенеся логику маршрутизации в файл Spring / Blueprint и удалив этот файл отдельно в каталог {smx_home} / etc. Этот файл будет запущен как пакет. - person Jakub Korab; 21.02.2012

Если вы подумываете об использовании ServiceMix или FuseESB, вы можете разделить маршруты на две части.

Первой частью будет bean-компонент Event-driver, запускающий маршрут. Он может отправлять сообщения в ServiceNMR (см. http://camel.apache.org/nmr.html).

Другая часть будет оставлена ​​на усмотрение пользователей фреймворка, использующих Spring DSL. Он просто слушал сообщение ЯМР (отправлял другим путем) и делал с ним все, что захотел.

Конечно, определение конечной точки можно присвоить с помощью службы конфигурации servicemix (см. http://camel.apache.org/properties.html#Properties-UsingBlueprintpropertyplaceholderwithCamelroutes)

person Community    schedule 15.02.2012