Архитектурный совет для Apache Camel и C

Question

Я немного экспериментирую с Apache Camel, чтобы предложить его своему боссу в качестве «решения ESB», к которому он стремится. Верблюд выглядит как хороший проект и хороший способ держаться подальше от более тяжеловесных вещей.

У нас есть низкоуровневый слой, реализованный в C, который прослушивает сетевые события и должен запустить некоторый демонстрационный Camel-маршрут. Какой лучший способ сделать такую ​​интеграцию? Я думал о JMS и STOMP протоколе, к сожалению, его клиентская библиотека C выглядит забавно (например, вы должны скомпилировать его в XCode).

Есть ли у вас какие-либо альтернативы, чтобы предложить?

Answer 1

Camel имеет несколько компонентов ( camel-netty , camel-mina ), которые могут обеспечить взаимодействие с сокетами более низкого уровня. Вы можете использовать их для общения с вашей системой.

Answer 2

Наконец, я прибег к использованию шлюза Java, который принимает внутренние вызовы IPC с использованием собственной библиотеки, предоставленной нашим поставщиком (мэйнфреймы HP Tandem NonStop), и переводит их в сообщения JMS для демонстрационного брокера, работающего на моем ПК.

(Первым моим шагом было использование HttpEndpoint).

Хороший совет также по поводу низкоуровневых библиотек сокетов в Java, нам нужно немного настроить, чтобы избежать странного поведения стандартных сетевых библиотек на NonStop.

Answer 3

есть несколько компонентов , которые позволяют Camel взаимодействовать с другими (не Java) приложениями. Сверху, Camel-Jetty , Camel-JMS , Camel-File и Camel-AMQP все это обеспечивают легко. это, как говорится, я не парень C, поэтому я не уверен, лучший выбор с этой точки зрения ...

Если вы только готовите демонстрацию, просто используйте определение конечной точки HTTP (используя верблюжий причал), чтобы начать демонстрационный маршрут. По мере продвижения вы можете переключиться на что-то более надежное (JMS и т. Д.) Для обмена сообщениями между двумя ...