http интерфейс для длительной эксплуатации - PullRequest
Новая
       6

http интерфейс для длительной эксплуатации

0 голосов
/ 09 сентября 2011

У меня есть работающая система, которая обрабатывает краткосрочные и длительные операции с интерфейсом запрос-ответ на основе Agatha-RRSL.

Теперь мы хотим немного измениться, чтобы можно было отправлять запросы через веб-сайт в формате Json, поэтому я пробую многие реализации REST-сервера, поддерживающие Json. Сервер REST будет одним модулем или «полкой», обрабатываемой Topshelf, другой модуль будет модулем обработки и последним модулем запуска базы данных NoSQL.

Чтобы поговорить между REST и модулем обработки, я думаю о сервисной шине, но у нас есть два типа запросов: короткие запросы, которые выполняют работу за 1-2 секунды, и длинные запросы, которые работают за 1 минуту.

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

Я думаю, что у меня также есть проблемы с размером ответа (при передаче сообщений MSMQ), когда мне нужно вернуть огромный список объектов

Любой намек?

1 Ответ

1 голос
/ 09 сентября 2011

NServiceBus не очень подходит для шаблонов обмена сообщениями запрос-ответ.Он больше подходит для асинхронной публикации-подписки.

Редактировать : для реализации своего рода ответа на запрос вам необходимо отправить сообщение в обоих направлениях, но оно состоит из трех логических шагов:

  1. Итак, ваш клиент отправляет сообщение с запросом данных.
  2. Сервер получит сообщение, обработает его, создаст ответное сообщение с данными и отправит его клиенту.
  3. Затем клиент может обработать данные.

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

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

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

Также NServiceBus использует MSMQ в качестве основного транспорта, а не http.

...