Является ли сообщение хорошей реализацией запроса/ответа

Question

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

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

Заставляет меня задаться вопросом, является ли Http лучшим решением для доступа к таким решениям вместо того, чтобы идти через маршрут обмена сообщениями? Я видел, что многие приложения используют MoM, например AMQ или TIBCO Rvd, для фактического использования для немедленного запроса/ответа - но это плохой дизайн, или это какая-то тонкая настройка или настройка, которая делает ее такой же, как Http.

Answer 1

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

• Гарантированная доставка
• транзакционных
• Persistent (т.е. сообщения, сохраняются до тех пор, пока доставлено, даже если система не в interrim)

HTTP-соединение не может [easilly] реализовать эти атрибуты, но опять же, если они вам не нужны, то, полагаю, вы можете сделать так, что «simple« HTTP предложит более простой и легкий olution. (Акцент на «простой», потому что некоторые приложения обмена сообщениями будут работать через HTTP).

Я не думаю, что запрос/ответ, реализованный через обмен сообщениями, сам по себе является плохим дизайном. Я имею в виду, вот что ... вы реализуете обе стороны этого процесса? Если нет, и у вас уже есть установленная служба обмена сообщениями, которая будет реагировать на запросы, все остальные соображения в стороне, это, казалось бы, способ ... и в обход этого для переопределения с использованием HTTP из-за некоторого понятия desgin потребуется довольно на мой взгляд, сильная аргументация.

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

Если вы полностью рекламируете табула-расу, и вы должны реализовать обе стороны с нуля ..... тогда ..... отправьте еще один вопрос здесь с некоторыми подробностями! :)