Сеансы и состояния Преимущество отсутствия состояния

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

Примером сервера без состояния может служить система, в ответ на запрос возвращающая Web-страницу с информацией о книге. Пользователь задает код ISBN книги и активизирует объект ASP-документа или сервлета. Извлекая из базы данных информацию об авторе книги, ее наименовании и т.п., объект сервера может временно сохранять ее во внутренних полях, чтобы во всеоружии подойти к фазе генерации текста HTML. Объект также способен реализовать некоторую бизнес-логику, связанную, скажем, с определением того, какие дополнительные данные о книге следует предоставить пользователю. По завершении обработки запроса накопленная в полях объекта информация становится бесполезной. Очередной запрос с иным кодом ISBN — это, как говорится, совсем другая история. Поэтому поля такого объекта во избежание возможных ошибок инициируются заново.

Теперь представим, что ставится задача сбора сведений обо всех кодах ISBN, запрашиваемых клиентом с определенным IP-адресом. Информацию можно располагать в списке, поддерживаемом объектом сервера. В паузах между циклами обработки запросов список должен каким-то образом сохраняться, поэтому речь следует вести об объекте сервера «с состоянием».

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

Если в промежутках между вызовами методов данные не сохраняются, не имеет значения, каким именно объектом обслуживается запрос, но если состояние должно фиксироваться, обработкой запроса должен заниматься один и тот же объект. Отсутствие потребности в сохранении состояния дает возможность сформировать пул объектов, который позволит с меньшими затратами обслужить большее количество запросов. Чем больше «медленных» пользователей, тем выше ценность объектов сервера без состояния. Вполне очевидно, что особенно полезны объекты серверов без состояния, которые обслуживают Web-сайты с высоким уровнем трафика. Концепция объектов без состояния совершенно органично вписывается в модель Web, поскольку основной протокол Web, а именно HTTP, относится к категории протоколов без состояния.

Так что, никаких состояний? Eсть одна проблема: многие сценарии взаимодействия клиентов с сервером по своей природе предполагают сохранение состояния. Рассмотрим метафору «карты покупателя», лежащую в основе тысяч приложений электронной коммерции. В процессе общения с сайтом виртуального магазина (в данном случае книжного) посетитель формирует запросы и выбирает книги, которые желает приобрести. Карта покупателя должна сохраняться в течение всего пользовательского сеанса. По сути, речь идет о бизнес-транзакции с состоянием, которая может быть реализована посредством сеанса с состоянием. Если посетитель будет только пролистывать книги, но ничего так и не купит, его сеанс в этом частном случае лишится состояния, но стоит ему выбрать хотя бы одну книгу, данные о ней и определят состояние сеанса. Можно попытаться избежать необходимости сохранения информации состояния, но тогда придется существенно обеднить приложение; при выборе схемы с состоянием, напротив, нужно решать, как именно ее использовать.

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