Очередь сообщений и веб-сервисы? [закрыто]

При каких условиях предпочтение отдавалось бы приложениям, которые общаются через очередь сообщений, а не через веб-службы (я просто имею в виду XML, JSON или YAML или что-то еще через HTTP, а не какой-то конкретный тип)?

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

Веб-приложение - Ruby on Rails, но я думаю, что вопрос шире.

Когда вы используете веб-сервис, у вас есть клиент и сервер:

1. В случае сбоя сервера клиент должен взять на себя ответственность за обработку ошибки.
2. Когда сервер снова работает, клиент отвечает за его повторную отправку.
3. Если сервер дает ответ на вызов и клиент терпит неудачу, операция теряется.
4. У вас нет разногласий, а именно: если миллионы клиентов вызывают веб-службу на одном сервере в секунду, скорее всего, ваш сервер выйдет из строя.
5. Вы можете ожидать немедленного ответа от сервера, но вы также можете обрабатывать асинхронные вызовы.

Когда вы используете очередь сообщений, такую ​​как RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, вы ожидаете других и более отказоустойчивых результатов:

1. В случае сбоя сервера очередь сохраняет сообщение (опционально, даже если машина выключена).
2. Когда сервер снова работает, он получает ожидающее сообщение.
3. Если сервер дает ответ на вызов и клиент терпит неудачу, если клиент не подтвердил ответ, сообщение сохраняется.
4. У вас есть разногласия, вы можете решить, сколько запросов обрабатывает сервер (вместо этого назовите это работающим).
5. Вы не ожидаете немедленного синхронного ответа, но вы можете реализовать / смоделировать синхронные вызовы.

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

В последнее время было проведено немало исследований, посвященных тому, как HTTP-вызовы REST могут заменить концепцию очереди сообщений.

Если вы представите концепцию процесса и задачи как ресурса, потребность в среднем уровне обмена сообщениями начнет исчезать.

Пример:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Задача может иметь несколько шагов для инициализации, и процесс может вернуть статус при опросе или POST на URL-адрес обратного вызова после завершения.

Это очень просто и становится достаточно мощным, когда вы понимаете, что теперь вы можете подписаться на канал rss / atom всех запущенных процессов и задач без какого-либо промежуточного уровня. Любая система массового обслуживания в любом случае потребует какого-то веб-интерфейса, и в эту концепцию она встроена без другого слоя пользовательского кода.

Ваши ресурсы существуют до тех пор, пока вы их не удалите, что означает, что вы можете просматривать историческую информацию еще долго после завершения процесса и задачи.

Вы встроили обнаружение службы даже для задачи, которая состоит из нескольких этапов, без каких-либо дополнительных сложных протоколов.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Обнаружение вашего сервиса - это форма HTML - универсальный и удобный для чтения формат.

Весь поток может использоваться программно или человеком, используя общепринятые инструменты. Это клиент, и поэтому RESTful. Каждый инструмент, созданный для Интернета, может управлять вашими бизнес-процессами. У вас по-прежнему есть альтернативные каналы сообщений путем асинхронной отправки сообщений на отдельный массив серверов журналов.

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

http://www.infoq.com/presentations/BPM-with-REST

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

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

Обратите внимание, что очереди сообщений и веб-сервисы являются ортогональными понятиями, то есть они не являются взаимоисключающими. Например, у вас может быть веб-служба на основе XML, которая действует как интерфейс к очереди сообщений. Я думаю, что вы ищете различие между очередями сообщений и запросом / ответом, последнее - когда запрос обрабатывается синхронно.

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

Фраза «веб-сервисы» заставляет меня думать о синхронных вызовах к распределенному компоненту по HTTP. Используйте веб-сервисы, если запрашивающий ответ нуждается в ответе.

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