Рекомендации: сохранение данных в течение нескольких вызовов веб-методов

Question

У меня есть веб-сервис, который имеет 8 веб-методов. Эти методы вызываются синхронно, первый вызов аутентифицирует пользователя, а остальные методы выполняют единицу работы, эти методы вызываются до тех пор, пока работа не будет завершена.

Мне нужно сохранить состояние работы (например, какие действия следует выполнить дальше, и какая работа была выполнена и выполняется в настоящее время.) В настоящее время у меня есть объект состояния, который содержит эту информацию.

Мой вопрос: как лучше сохранить этот объект между каждым вызовом веб-службы? Обратите внимание, что этот веб-сервис может вызывать несколько пользователей, каждый из которых имеет свое уникальное состояние.

Вот несколько сценариев, о которых я думаю:

Идея № 1

Сохранить объект в сеансе.

Идея № 2 Создайте переменную экземпляра, которая является HashMap userId и их соответствующими данными. что-то вроде:

[WebService(Namespace = "http://developer.intuit.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class QBWCService : QBWebConnectorSvc {

    // instance variable to hold current session data...
    private Dictionary<Guid,Session&gt Sessions;

    public QBWCService () {

        Sessions = new Dictionary<Guid,Session&gt();
    }
    [WebMethod]
    public override string[] authenticate(string strUserName, string strPassword)
    {
        ...
        Sessions.Add(UserId, new SessoionObject());
    }
 [WebMethod]
    public override string[] authenticate(Guid UserId)
    {
        SessionObject o = Sessions[UserId];
    }
}

Я думаю, что Идея 2 будет самым чистым "естественным путем", однако я не знаю никаких последствий реализации такого рода схемы ... какой путь или что еще вы бы порекомендовали?

Answer 1

Это может быть одна из тех ситуаций, когда вы уже слишком далеко, чтобы выполнить большой рефакторинг, но ...

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

http://msdn.microsoft.com/en-us/magazine/cc163538.aspx

[РЕДАКТИРОВАТЬ]: Стреляй, Джедай избил меня до этого. Что он сказал.

Answer 2

Вам следует взглянуть на Windows Workflow Foundation (WF) . Вы можете создать свой рабочий процесс, а затем подключить постоянные модели и т. Д.

Как говорится, вы не можете использовать сессию! он не будет масштабироваться после создания нескольких веб-ферм / серверов. Конечно, API разработчика QBW должен масштабироваться и быть отказоустойчивым!

Дополнительная информация об использовании этого с ASP.NET: здесь .

Answer 3

Idea one имеет преимущество ASP.NET, управляющее сессиями для вас. Я мог бы видеть, что второй вариант становится проблематичным, если у вас есть пользователи, которые не завершают полный жизненный цикл, поскольку у вас есть записи в хэш-таблице, которые ссылаются на старые сеансы. Как минимум, если перейти к # 2, я бы включил процесс очистки, чтобы гарантировать, что старые сеансы истекают.

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

Answer 4

Идея 2 имитирует управление состоянием сеанса. Я не вижу внутренней выгоды от выполнения вашего собственного управления оператором сеанса.