Веб-сервис .NET - быстро подтвердить, но продолжить обработку в фоновом режиме - PullRequest
Новая
       15

Веб-сервис .NET - быстро подтвердить, но продолжить обработку в фоновом режиме

4 голосов
/ 01 марта 2010

Я создаю веб-сервис .NET, который будет использоваться приложением поставщика, и я не уверен, как выполнить следующее:

  • Продавец позвонит на мою веб-страницу с некоторой информацией, но хочет быстро получить подтверждение, просто сообщив, что я получил их информацию. Им все равно, что я с ним сделаю, и не хотят подтверждения, что я закончил обработку.
  • Информация, которую мне передали, должна сделать что-то негласное и воздействовать на информацию чувствительным ко времени образом, то есть предпринять некоторые действия в течение нескольких минут. Я буду связываться с рядом других веб-сервисов, а также выполнять некоторые работы с базой данных. Очевидно, это будет после того, как я ответил «Успех» вызывающему приложению.

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

  1. Поскольку вызывающее приложение по сути отправляется в очередь, чтобы процесс, который я написал, мог его обработать, я могу заставить веб-службу просто отправить элемент в базу данных (или в MSMQ, или в другую очередь) и затем вернуть успех , Процесс очереди получит оттуда обработку.
  2. В идеале я представлял, что мой сервис может вернуть «Успех», а затем просто продолжить обработку самостоятельно, но я не уверен, возможно ли это. Поскольку моя обработка зависит от времени, запуск серверной обработки нового запроса идеален, поэтому время ожидания минимально.

Есть ли другие идеи или одна из них звучит предпочтительнее?

Ответы [ 3 ]

2 голосов
/ 01 марта 2010

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

1-й вариант хорош, потому что вы имеете полный контроль над тем, как вы будете хранить и обрабатывать запросы. Хороший дизайн - иметь веб-сервис в качестве внешнего интерфейса, который будет просто отвечать на запросы «Success» и ставить в очередь запросы. В качестве постоянного хранилища я рекомендую MSMQ или базу данных. Затем создайте сервисное приложение, которое будет иметь пул потоков и будет выбирать из очереди (дБ).

2 голосов
/ 01 марта 2010
  1. Получить запрос
  2. Выделение фонового процесса (например, с помощью BackgroundWorker) с переданными параметрами
  3. Возврат подтверждения - с Guid или аналогичным идентификатором запроса
  4. Ваша обработка ...
    1. Между тем, вызывающий абонент может пропинговать ваш сервис для обновления статуса на основе идентификатора
    2. Пока идет обработка, верните либо «все еще работающий» ответ, либо, если вы умны или можете точно предсказать его, верните показатель прогресса (может быть, в процентах или оставшееся время)
  5. Когда обработка будет завершена, верните сообщение об успешном завершении запроса статуса
  6. Сделать решение доступным через идентификатор, который вы ответили ранее
0 голосов
/ 01 марта 2010

Вариант 1 - путь, поскольку приложение уже поддерживает организацию очереди.

Что касается варианта 2 - вы можете запустить рабочий поток из своего веб-сервиса, это обработает работу, и вы сможете продолжить возвращать «success» из основного потока.

...