Ответ 1
ActiveMQ
http://activemq.apache.org/cross-language-clients.html
Поддерживает все следующие протоколы
- OpenWire
- REST
- Stomp
- Уведомление WS
- XMPP
- AMQP
Спасибо Пол
Я разрабатываю набор приложений, которые работают вместе, чтобы создать систему для обработки данных измерений. Есть несколько причин, по которым я хочу, чтобы они были слабо связаны, и система должна быть расширена третьими сторонами, поэтому приложения будут связаны между собой посредством обмена сообщениями.
Я ищу систему обмена сообщениями, которая предлагает привязки в (по крайней мере) С#, Java и Python и поддерживает шаблоны обмена сообщениями, такие как Publish-Subscribe, Guaranteed Delivery, Selective Consumer (например, Peek in.Net Messaging).
Насколько я могу судить, нет ничего плохого в JMS или .Net Messaging, просто они предназначены только для .Net/Java.
Система должна дать мне контроль над механизмом транспорта (сокеты, очереди сообщений и т.д.), которые будут использоваться при настройке канала. Я хочу иметь возможность как масштабировать удаленные машины, так и ускорять работу с местными транспортными средствами.
Если я не смогу найти что-нибудь подходящее, мне придется сворачивать самостоятельно. Я бы, вероятно, использовал буферы протокола Google для сериализации. Если у кого-то есть другие рекомендации по технологическим параметрам, уберите их.
О, да - и я хотел бы иметь факультативное шифрование для каждого канала или для каждого сообщения.
ETA: Спасибо за все быстрые ответы. Сейчас я работаю над документами и пропагандой. Кто-нибудь использовал технологии ниже и для чего/с какими результатами?
ActiveMQ
http://activemq.apache.org/cross-language-clients.html
Поддерживает все следующие протоколы
Спасибо Пол
SonicMQ может быть инструментом, который вы ищете. Я знаю, что они тяжелы в Прогрессе, но они также поддерживают другие альтернативы языка и являются ведущим игроком в секторе обмена сообщениями.
Как сказал Павел, попробуйте ActiveMQ, который поддерживает многие языковые клиенты и проводные протоколы.
BTW ActiveMQ 6.x, вероятно, будет использовать буферы протокола Google в качестве одного из своих базовых проводников:)
Я использовал Apache ActiveMQ для многих проектов с большим успехом. Его наиболее популярный и мощный брокер сообщений с открытым исходным кодом вокруг сегодня.
Кстати, на .Net/С# проект ActiveMQ создал NMS API, который является стандартным API для общения с брокерскими сообщениями. Чистая платформа, которая теперь интегрирована в Spring.Net
Вы считали MPI?
Вы можете использовать ESB (Enterprise Service Bus), например Mule. Идея состоит в том, что вы отправляете свои сообщения на шину любым способом (JMS, http, email), а шина выполняет маршрутизацию для вас. Я не знаю, есть ли привязки .NET, но даже если их нет, вы можете создать свой собственный, используя механизм расширения. Конечно, это означает, что вам нужно настроить автобус где-то.
Если вы хотите получить твердую, коммерческую поддержку и интеграцию с IBM IBM MQ Series, теперь Websphere MQ предоставляет все описанные функции в ваших требованиях.
Иногда вы получаете то, за что платите...; -)
Открытая очередь сообщений (Open MQ) включена в сервер приложений GlassFish, а также работает автономно. Он запускается через несколько секунд и поддерживает Java и C-клиент. Поддержка Stomp в настоящее время находится в разработке в версии 4.4.
Если вам нужен многоязычный "стандарт" - это означает, что вы не привязаны к использованию конкретного брокера/посредника, такого как ActiveMQ, SonicMQ или WebsphereMQ, - я настоятельно рекомендую вам взглянуть на стандарт AMQP (http://www.amqp.org) и связанных с ними брокеров (RabbitMQ, QPid, OpenAMQ; см. http://www.amqp.org/confluence/display/AMQP/AMQP+Products).