Подтвердить что ты не робот

Кросс-платформенная, межязыковая система обмена сообщениями?

Я разрабатываю набор приложений, которые работают вместе, чтобы создать систему для обработки данных измерений. Есть несколько причин, по которым я хочу, чтобы они были слабо связаны, и система должна быть расширена третьими сторонами, поэтому приложения будут связаны между собой посредством обмена сообщениями.

Я ищу систему обмена сообщениями, которая предлагает привязки в (по крайней мере) С#, Java и Python и поддерживает шаблоны обмена сообщениями, такие как Publish-Subscribe, Guaranteed Delivery, Selective Consumer (например, Peek in.Net Messaging).

Насколько я могу судить, нет ничего плохого в JMS или .Net Messaging, просто они предназначены только для .Net/Java.

Система должна дать мне контроль над механизмом транспорта (сокеты, очереди сообщений и т.д.), которые будут использоваться при настройке канала. Я хочу иметь возможность как масштабировать удаленные машины, так и ускорять работу с местными транспортными средствами.

Если я не смогу найти что-нибудь подходящее, мне придется сворачивать самостоятельно. Я бы, вероятно, использовал буферы протокола Google для сериализации. Если у кого-то есть другие рекомендации по технологическим параметрам, уберите их.

О, да - и я хотел бы иметь факультативное шифрование для каждого канала или для каждого сообщения.

ETA: Спасибо за все быстрые ответы. Сейчас я работаю над документами и пропагандой. Кто-нибудь использовал технологии ниже и для чего/с какими результатами?

4b9b3361

Ответ 2

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

Sonic Software

Ответ 3

Как сказал Павел, попробуйте ActiveMQ, который поддерживает многие языковые клиенты и проводные протоколы.

BTW ActiveMQ 6.x, вероятно, будет использовать буферы протокола Google в качестве одного из своих базовых проводников:)

Я использовал Apache ActiveMQ для многих проектов с большим успехом. Его наиболее популярный и мощный брокер сообщений с открытым исходным кодом вокруг сегодня.

Кстати, на .Net/С# проект ActiveMQ создал NMS API, который является стандартным API для общения с брокерскими сообщениями. Чистая платформа, которая теперь интегрирована в Spring.Net

Ответ 4

Вы считали MPI?

Ответ 5

Вы можете использовать ESB (Enterprise Service Bus), например Mule. Идея состоит в том, что вы отправляете свои сообщения на шину любым способом (JMS, http, email), а шина выполняет маршрутизацию для вас. Я не знаю, есть ли привязки .NET, но даже если их нет, вы можете создать свой собственный, используя механизм расширения. Конечно, это означает, что вам нужно настроить автобус где-то.

Ответ 6

Если вы хотите получить твердую, коммерческую поддержку и интеграцию с IBM IBM MQ Series, теперь Websphere MQ предоставляет все описанные функции в ваших требованиях.

Иногда вы получаете то, за что платите...; -)

Ответ 7

Открытая очередь сообщений (Open MQ) включена в сервер приложений GlassFish, а также работает автономно. Он запускается через несколько секунд и поддерживает Java и C-клиент. Поддержка Stomp в настоящее время находится в разработке в версии 4.4.

Ответ 8

Если вам нужен многоязычный "стандарт" - это означает, что вы не привязаны к использованию конкретного брокера/посредника, такого как ActiveMQ, SonicMQ или WebsphereMQ, - я настоятельно рекомендую вам взглянуть на стандарт AMQP (http://www.amqp.org) и связанных с ними брокеров (RabbitMQ, QPid, OpenAMQ; см. http://www.amqp.org/confluence/display/AMQP/AMQP+Products).