Является ли сообщение очередью еще хорошим ответом?

Question

Десятилетие и больше в прошлом я изучал и использовал программное обеспечение IBM MQSeries и Websphere MQ. Это было отличное решение для подключения двух приложений в разных компаниях в разных местах: приложение в каждой компании могло отказаться от сообщения с MQSeries на локальном компьютере, MQSeries перенесет его на машину в другой компании, а приложение с этой стороны будет получать сообщение локально.

Ускоренная перемотка вперед на сегодня: я больше не работаю для IBM, но я пытаюсь решить подобную проблему. Моему приложению нужно отправить несколько сообщений в день, каждый на несколько МБ или меньше, в приложение в удаленной компании и получить аналогичное количество несколько меньших ответов.

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

Answer 1

WebSphere MQ все еще может решить вашу проблему ... Я думаю, что сценарий связан с точкой-точкой с сценарием Request-Response. Вы можете использовать некоторые относительно новые вещи, такие как JMS, которые хорошо интегрируются с вашим приложением.

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

Другим способом решения проблемы является совместное использование общей базы данных между двумя приложениями.

Answer 2

уверен, что это может быть - если удаленная компания намеревается предоставить такую ​​же услугу другим, а не только вам.

Возможно, низкая латентность WMQ - это то, что вам нужно, поскольку сервер не требуется.
- Обмен сообщениями с низкой задержкой WebSphere MQ отличается от обычных продуктов WebSphere, таких как WebSphere MQ, WebSphere Message Broker и WebSphere Application Server, в том, что нет установленной и настроенной инфраструктуры продукта, такой как диспетчеры очередей, брокеры сообщений или серверы приложений. Таким образом, нет конкретных компонентов продукта для мониторинга, измерения и управления.

http://www-03.ibm.com/software/products/en/wmq-llm http://pic.dhe.ibm.com/infocenter/wllm/v2r5/index.jsp?topic=%2Fcom.ibm.wllm.doc%2Fintroductiontowebspheremqlowlatencymessaging.html

Конечно, простой RESTful веб-интерфейс может быть в состоянии обеспечить такую ​​же функциональность.

Я не рекомендую записывать приложения сокетов TCP - почему все, что поднимает средний вес, когда есть так много продуктов, которые будут делать тяжелую и среднюю тягу для вас? Вы хотите сделать только легкий подъем - отправьте запрос, получите ответ - 6 2 и даже, перейдите и выйдите.

Необходимо написать свой список требований reagrding: - надежность - насколько это важно, если запрос или ответ потеряны? - Возможность восстановления - могут ли сообщения в полете быть восстановлены и повторно отправлены в случае сбоя приложения (ов)? - время в оба конца - с одной стороны латентности - 1: 1 сервис? многие-к-одному?

Надеюсь, это поможет. Dave