Эта статья о том, как перейти от сценариев к шаблонам интеграции. На примере нашей системы рассказать о типовых архитектурных задачах. Провести параллель между задачами и средством интеграции таким, как Camel. Эта статья не заменяет Camel In Action. Но Camel In Action — это оторванные от реальности куски кода хоть и с подробным описанием.
Да вы правы, добавил. Эта книга будет полезна для старта, а её примеры в качестве образца исходного кода.
Правда, для решения практических задач её не достаточно, придется набивать свои шишки.
Мы обкатываем новые решения на прототипах. Без последних новые технологии не обкатать и не внедрить.
Главное, следить за тем, чтобы прототип выходил в подакшн доработанным.
Мы используем практически голый Camel.
На текущий момент в его состав входят:
— ActiveMQ + KahaDB
— Jetty
— Компоненты Camel: FTP, file, jetty, JMS, velocity
В остальных системах в качестве клиента JMS используем ActiveMQ в паре c собственным велосипедом.
Когда мы начинали работать с Camel не было ни ServiceMix-а, ни Karaf-а, да и альтернатив Camel-у не было.
По опыту работы могу сказать, что очень не хватает в “голом верблюде” средств мониторинга и гибкого администрирования. Мы использовали ActiveMQBrowser, на тот момент других вариантов не было. Этот инструмент имеет очень ограниченный функционал и сейчас уже не развивается. Сейчас склоняемся в сторону нового аналогичного инструмента встроенного в ActiveMQ.
Наша система развивается с 2006 года и объём выгружаемых данных не превышает нескольких мегабайт в день. Поэтому такой сценарий практически невозможен.
Мы используем ActiveMQ в качестве JMS брокера и KahaDB в качестве персистентного хранилища брокера. С уверенностью можно утверждать, что даже если объём данных увеличится на порядок, шина с ним справится. Моя уверенность подтверждается нагрузочными тестами, которые мы проводили перед релизом.
Подробнее о сложностях связанных с ростом нагрузки, а также о полезных настройках брокера будет в третьей части.
Правда, для решения практических задач её не достаточно, придется набивать свои шишки.
Главное, следить за тем, чтобы прототип выходил в подакшн доработанным.
На текущий момент в его состав входят:
— ActiveMQ + KahaDB
— Jetty
— Компоненты Camel: FTP, file, jetty, JMS, velocity
В остальных системах в качестве клиента JMS используем ActiveMQ в паре c собственным велосипедом.
Когда мы начинали работать с Camel не было ни ServiceMix-а, ни Karaf-а, да и альтернатив Camel-у не было.
По опыту работы могу сказать, что очень не хватает в “голом верблюде” средств мониторинга и гибкого администрирования. Мы использовали ActiveMQBrowser, на тот момент других вариантов не было. Этот инструмент имеет очень ограниченный функционал и сейчас уже не развивается. Сейчас склоняемся в сторону нового аналогичного инструмента встроенного в ActiveMQ.
Наша система развивается с 2006 года и объём выгружаемых данных не превышает нескольких мегабайт в день. Поэтому такой сценарий практически невозможен.
Мы используем ActiveMQ в качестве JMS брокера и KahaDB в качестве персистентного хранилища брокера. С уверенностью можно утверждать, что даже если объём данных увеличится на порядок, шина с ним справится. Моя уверенность подтверждается нагрузочными тестами, которые мы проводили перед релизом.
Подробнее о сложностях связанных с ростом нагрузки, а также о полезных настройках брокера будет в третьей части.