Ответ 1
Всегда используйте REST. Это самый современный, продвинутый и масштабируемый интеграционный подход, доступный сегодня. Балансировка нагрузки службы на основе REST достигается просто с помощью аппаратного или программного HTTP-балансировщика нагрузки и может считаться столь же свободным, как и балансировка нагрузки в JMS.
MOM (ориентированное на сообщения промежуточное ПО) не масштабируется легко (но может масштабироваться достаточно для ваших нужд). REST работает в масштабе сети.
В MOM нет эффекта масштаба. Для запросов на получение данных каждый раз, когда запрашивается конкретная часть данных, другое сообщение должно быть отправлено на сервер и на него отвечает сервер. В системе на основе REST запросы на одни и те же данные могут обслуживаться с помощью HTTP-кеша. Это означает, что по мере увеличения объема запросов с течением времени система на основе MOM увидит увеличение загрузки сервера с той же скоростью, что и запросы. Система на основе REST увидит увеличение загрузки сервера с меньшей скоростью, чем запросы.
MOM соблазнит вас сообщениями о пожаре и забывании с гарантированной доставкой, только чтобы укусить вас с проблемой цепочки поставок .
MOM ужасен для синхронного запроса-ответа, так как он будет терпеть неудачу (т.е. ждать таймаута), когда сервер не работает. Когда запрос будет терпеть неудачу, вы хотите, чтобы он быстро провалился. HTTP-запрос к службе на основе REST будет немедленно сбой (при подключении TCP), если сервер не работает.
MOM полезен для асинхронного обмена сообщениями "запрос-ответ", но тогда вам останется проблема с тем, где хранить состояние между запросом и ответом (подсказка: ваши параметры Файл или обычная база данных, Сообщение или База данных NoSQL). Часто дополнительные усилия по осуществлению не стоят ощутимых преимуществ асинхронности. Также службы на основе REST поддерживают асинхронные запросы, если вам это действительно нужно. 202 Принято является вашим другом в этой ситуации.
Наконец, использование кеширования позволяет основанным на REST системам реализовывать интеграцию на основе pull-based, которые намного легче поддерживать. Например, просто скажите, что мы хотим переместить данные из системы A в систему B. Подход MOM должен был отправлять сообщения от A до B. Подход, основанный на REST, заключался бы в создании службы передачи данных в (например, в RSS-канале) что B опроса для новых данных (так же, как ваш RSS-ридер публикует опросы для новых статей). Когда B терпит неудачу, в примере MOM команде поддержки необходимо будет следить за очередями сообщений, чтобы убедиться, что они не переполняются, а кто-то другой получает B обратно. В примере REST команда поддержки просто должна беспокоиться о том, чтобы вернуть B. Когда A терпит неудачу, нет большой разницы. В примере MOM B не знает и не заботится. В примере REST B знает, что A не работает, но все равно все равно, потому что, очевидно, нет новых данных от A, когда он работает. Первоначально опрос, основанный на использовании pull-based интеграции, требует, чтобы швы были очень неэффективными, однако HTTP-кеширование делает это не проблемой.
Другими словами, вместо того, чтобы инвестировать в JMS-сервер, инвестируйте в хороший балансировщик нагрузки HTTP-кеширования.