Граф маршрутов для Apache Camel

[SnowBearRu]

А в сторону hawt.io не смотрели? По крайней мере некая статистика и роуты в нем визуально оценить можно. Может даже допилить под себя…

[Avvero]

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

[Throwable]

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

[Avvero]

В нашем случае такая архитектура, когда общение между сервисами реализовано в асинхронном режиме в виде событий.

[sshikov]

В нашем это именно потоковые данные (биржа, например). Сделки, котировки и разные другие документы.

[sshikov]

Эк вы ловко объединили два jms:topic в один, из разных контекстов. Я догадываюсь, что у вас наверное возможно такое — но в общем случае это могут быть совсем разные топики на разных jms серверах. И простое объединение узлов графа на базе их названий в camel некорректно (а другого способа не существует, потому что у нас например соединение проходит через qpid, и там внутри тоже существует обработка — которую в подобный граф не включить.

[Avvero]

Эк вы ловко объединили два jms:topic в один, из разных контекстов

Почему из разных? Общий jms брокер. И в рамках одного брокера всякий jms:topic:foo ссылается на один и тот же топик foo.

И простое объединение узлов графа на базе их названий в camel некорректно

Да, некорректно. И я так не делаю. Информации, чтобы отличать похожие узлы, достаточно и я их отличаю. Но я прячу детали от пользователя и использую, например, цвета, чтобы визуально показать, что это разные сервисы или контексты.

[sshikov]

>Почему из разных
Потому что по тексту это выглядит как объединение двух разных routes из разных контекстов (ну, во всяком случае я вас так понял). А в разных контекстах jms:topic:foo вовсе не обязаны быть двумя одинаковыми брокерами.

Ну то есть, я не говорю что так нельзя, но скажем на нашей шине такое бы не прокатило, потому что jms: (или в нашем случае amqp:) это всего-лишь имя в некотором camel registry, и два разных jms вполне могут ссылаться как на один брокер, так и на разные, и понять это можно только если залезть в определение самого jms, и даже там это будет не очевидно.

[Avvero]

Интересно, а как Вы отличаете jms брокеров тогда? Через connectionFactory?

[sshikov]

Конечно. Ну то есть, я хочу сказать, что только посмотрев туда в свойства, вы точно можете сказать, один это брокер, или два разных. Впрочем, у нас такая задача не стояла, как у вас, и никто не пытался построить граф всех маршрутов, в первую очередь потому, что большая часть обработки была в qpid, и в других местах вне camel, поэтому даже если бы мы такой граф построили, от него было бы не очень много пользы. Поэтому нас вполне устроила hawt.io.