Дополнительные источники информации

Эта глава только касается поверхности бездонного омута технологий управления па­раллельными операциями. Чтобы погрузиться глубже, понадобится более серьезная эки­пировка; в этом вам помогут книги [8,27, 36].

Глава 6 Сеансы и состояния

Различия между системными и бизнес-транзакциями уже рассматривались при обсу­ждении параллельного выполнения заданий (см. главу 5). Эти различия не только влияют на те или иные аспекты параллелизма, но и обусловливают способы сохранения в кон­тексте транзакции информации временного характера, которая до определенного момен­та не может фиксироваться в базе данных.

Те же принципиальные различия лежат в основе многих дискуссий о роли и месте так называемых сеансов с сохранением промежуточного состояния (или, коротко говоря, сеан­сов "с состоянием") (stateful sessions) и сеансов "без состояния" (stateless sessions). По этому поводу сломано немало копий, но, как мне кажется, основная проблема нередко оказы­вается скрытой за частоколом сугубо технических вопросов. Необходимо понимать, что "состояние" является неотъемлемой частью сеансов определенных категорий и даль­нейшие решения должны приниматься только с учетом этого факта.

В чем преимущество отсутствия "состояния"

Что подразумевается под сервером "без состояния"? Если говорить об объектах, то главное их достоинство состоит в том, что они сочетают в себе состояние (данные) и пове­дение (функции). Объект, лишенный состояния, — это объект без полей данных. Подоб­ные объекты встречаются довольно редко, поскольку считается, что их наличие — при­знак плохого проектирования.

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

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

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

Основная проблема связана с потребностью в ресурсах. Объекту сервера с состоянием необходимо сохранять все данные, образующие состояние, в период ожидания, пока пользователь предается тяжким раздумьям, "пялясь" в Web-страницу. Объект сервера без состояния, однако, в такой ситуации мог бы заняться обслуживанием запросов, иниции­руемых в других сеансах. Проведем далекий от реальности, тем не менее полезный мыс­лительный эксперимент. Представим, что сто человек интересуются книгами, упоми­наемыми на страницах электронного каталога, и для обработки запроса по любой книге требуется одна секунда. Каждые 10 секунд каждый пользователь инициирует по одному запросу, и все запросы равномерно распределяются во времени. Если необходимо про­следить историю запросов пользователей с помощью объектов сервера с состоянием, надлежит выделить по одному объекту для каждого пользователя, т.е. 100 объектов. Но 90% времени жизни объектов будет пропадать вхолостую. Отказавшись от намерений накопить сведения о читательских пристрастиях пользователей и решив применять объ­екты без состояния, способные просто обрабатывать запросы, можно обойтись всего де­сятью объектами сервера, которые будут заняты "делом" непрерывно.

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

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