Вот собирался строить приложение на stateless, rest или xml-rpc сервисах.

И чего то в друг задумался, а стоит ли так сильно боятся и избегать statefull сервисов ?
В конце концов они не редко бывают удобнее...

Как основную причину использования stateless сервисов я вижу горизонтальную маштабируемость ну и общирное повторное использование.
Повторного использования можно добится и в стейтфул варианте, по этому мысли мои касались маштабируемости...

Ведь если поставить нормальный load balancer который будет отслеживать создание сесси клиентом на конретной ноде
и при последющих вызовах мапить этого клиента по его сессии на ту же самую ноду, и очищать мапинг по таймауту скажем, то мы получаем такую же горизонтальную маштабируемость ценной одной выделеной машины с load balancer'ом ?
Собствено я в чем то ошибаюсь ? или я просто заново открыл для себя велосипед ?

Прокоментируйте пажалуйста...

Как всегда, "хорошее" решение находиться где-то посередине (имхо, ближе к стэйт-лесс). Причем этот баланс лучше найти/нащупать самому исходя из специфики приложения. (Да-да именно нащупать. После того как будет написана часть функционала, "нащупать" во время тестов приложения. И не стоит наперед загадывать. Это как с преждевременной оптимизацией.)

Плюсы stateless сервисов не только в горизонтальной массштабируемости, но и в том, что эта массштабируемость (новые сервера) понадобиться гораздо позже чем в statefull варианте. А все потому, что ресурсы сервера тратятся меньше (только вычислительные, да и те, как понимаешь, кратковременно). Поэтому один и тот же сервер может выдержать большую нагрузку при разных подходах.

С другой стороны, Statefull сервисы проще в реализации. И не требут передачи дополнительной информации клиенту (а это трафик) только для того чтобы позже восстановить предыдущее состояние.

ёё>Ведь если поставить нормальный load balancer который будет отслеживать создание сесси клиентом на конретной ноде...
А что за технология? Если ASP net, то такая функциональность вшита в среду: храниение сессии в SQL БД.

Но в любом случае это "затраты на передачу сессии между серверами" против "передачи сессии в запросе клиента".



Теперь к реальному опыту (моему есесснно).
Я предпочитаю stateless для каждого запроса, но statefull для сеанса в целом (между login и logout). Т.е. данные о конкретном запросе я стараюсь хранить на стороне клиента, а данные о залогиненном пользователе на стороне сервера.
Кроме того, бывают случаи когда stateless просто невыгоден: глупо передавать большой объем данных пользователю, а если передавать только "ID данных" то их потом тяжело восстанавливать на стороне сервера.


Вот так. Резюме: "этот баланс лучше найти/нащупать самому исходя из специфики приложения".


СУВ, Aikin

Здравствуйте, frёёm, Вы писали:

ёё>И чего то в друг задумался, а стоит ли так сильно боятся и избегать statefull сервисов ?
Зависит от...

ёё>В конце концов они не редко бывают удобнее...
Опять-таки, как посмотреть.

ёё>Ведь если поставить нормальный load balancer который будет отслеживать создание сесси клиентом на конретной ноде
ёё>и при последющих вызовах мапить этого клиента по его сессии на ту же самую ноду, и очищать мапинг по таймауту скажем, то мы получаем такую же горизонтальную маштабируемость ценной одной выделеной машины с load balancer'ом ?
Это вряд ли.

ёё>Прокоментируйте пажалуйста...
statefull хорош при очень сожной логике и достаточно малом количестве клиентов и по итогу возни с ним больше чем со stateless.
Вообще же, перейти от stateless к statefull — достаточно просто, а вот с обратным лучше не связываться.

ёё>Ведь если поставить нормальный load balancer который будет отслеживать создание сесси клиентом на конретной ноде и при последющих вызовах мапить этого клиента по его сессии на ту же самую ноду, и очищать мапинг по таймауту скажем, то мы получаем такую же горизонтальную маштабируемость ценной одной выделеной машины с load balancer'ом ?

Гм, не получится.
Во-первых, одного load balancer мало — так как не надежно. Для надежности нужно уже два, но тогда сразу возникает вопрос, а как они синхронизируют связь сессия/нода.
Если через общее хранилище — то узким место становится это хранилище (сколько тысяч запросов в секунду оно потянет?)
Если через нотификации, то там свои проблемы с восстановлением после падения и разнообразными конфликтами.


Проще, конечно, сессии сразу хранить в общем хранилище (memcached, MySQL Cluster и т.п.). Но производительности может и не хватить...

Здравствуйте, IB, Вы писали:

ёё>>Ведь если поставить нормальный load balancer который будет отслеживать создание сесси клиентом на конретной ноде
ёё>>и при последющих вызовах мапить этого клиента по его сессии на ту же самую ноду, и очищать мапинг по таймауту скажем, то мы получаем такую же горизонтальную маштабируемость ценной одной выделеной машины с load balancer'ом ?
IB>Это вряд ли.

А можно более развёрнуто ? что может помещать ? по идее все должо будет корректно работать

IB>Вообще же, перейти от stateless к statefull — достаточно просто, а вот с обратным лучше не связываться.
Мне как то странно переходить от рабочей stateless архитектуре к statefull, зачем ?
Если только добавлять statefull сервисы, но это уже не переход а добавление.
Ну а наоборот уже да...это понятно...

Здравствуйте, frёёm, Вы писали:

ёё>Прокоментируйте пажалуйста...

Ты случайно не путаешь state и cache?

Здравствуйте, IT, Вы писали:
IT>Ты случайно не путаешь state и cache?

Говоря про statefull сервисы я имел в виду state как вариант кеширования, а не конечные автоматы...
В каком плане вы полагаете я их путаю

Здравствуйте, frёёm, Вы писали:

ёё>А можно более развёрнуто ? что может помещать ? по идее все должо будет корректно работать
Load Balancer поможет только в том случае, если стейт между нодами шарить не надо, но это тот же stateless, только с кешем на уровне сессий, так что не понятно какие преимущества ты хочешь получишь от такого "statefull". Возможно работать будет по шустрее, но такого рода кеш ты всегда сможешь прикрутить поверх stateless, поставить лоад балансер и добиться ровно такого же эффекта.

ёё>Мне как то странно переходить от рабочей stateless архитектуре к statefull, зачем ?
Ну вдруг statless перестанет по каким-то причинам устраивать...
Я собственно к тому, что проектировать и разрабатывать надо начинать со stateless и только если вылезут какие-то фатальные проблемы — двигаться в сторону хранения стейта ближе к потребителю...

Здравствуйте, frёёm, Вы писали:

ёё>Говоря про statefull сервисы я имел в виду state как вариант кеширования, а не конечные автоматы...
ёё>В каком плане вы полагаете я их путаю

state и cache — это разные вещи. Первое — касается именно состояния, второе — оптимизация, которая вполне уместна в stateless.

ёё>Говоря про statefull сервисы я имел в виду state как вариант кеширования, а не конечные автоматы...
Таки уже я не понял. Что значит "state как вариант кешировани"???

Что такое state в моем понимании (надеюсь не только в моем):
Возьмем обычный вэб-магазин и корзину пользователя. Пользователь лазит по сайту, кладет потиху заказы в свою корзину и эта корзина доступна из любой страницы сайта (куда бы пользовтель не кликнул). Вот это state, состояние.

stateless отличается от statefull сервера тем кто хранит это состояние. Сервер с состоянием хранит их у себя, сервер без состояния хранит его не у себя (у пользователя, в скрытом поле, например).
Вот и вся наука. Ничего сложного.

А кэш или не кэш... так это уже детали ускорения работы сервера.
Причем обычно с кэшем больше сложностей чем без него. Особенно при высокой конкуренции пользователей.
А если уж у нас еще и кластер серверов, то тут вообще атас. Лучше убиться, чем делать кэш. Ну кроме как кэша по времени (маааленькому такому времени, 1 сек, например).

Здравствуйте, Aikin, Вы писали:

A>stateless отличается от statefull сервера тем кто хранит это состояние. Сервер с состоянием хранит их у себя, сервер без состояния хранит его не у себя (у пользователя, в скрытом поле, например).
нет, все не так...
Строго говоря, stateless не существует. По большому счету — все statefull, зависит только от того, насколько далекий путь придется проделать этому самому состоянию, прежде чем добраться до пользователя... Вот если я храню корзину и историю заказов в БД — это еще stateless или уже statefull?
Формально, stateless считается, если состояние объекта приходится явно восстанавливать из какого-нибудь внешнего контейнера при каждом обращении, но это довольно условная граница..

A>>stateless отличается от statefull сервера тем кто хранит это состояние. Сервер с состоянием хранит их у себя, сервер без состояния хранит его не у себя (у пользователя, в скрытом поле, например).
IB>нет, все не так...
Все не так или или же немного не так?
IB>Строго говоря, stateless не существует.
Нуу, не сказал бы. Начнем с того, что сам протокол HTTP является stateless. Так что весь стэйтфулл накручивается уже вручную либо с помощью апликейшин сервера.
IB> Вот если я храню корзину и историю заказов в БД — это еще stateless или уже statefull?
Про корзину -- ответов как минимум три: да, нет и "и да, и нет". В зависимости от реализации.
Про историю -- это однозначный stateless. Эти данные нужны приложению (вернее его владельцам) даже больше чем самому пользователю.

Хотелось бы уточнить что такое state (замечу, что четкой формулировки вчера еще не было, и сформировалось оно в голове у меня только сейчас).
State -- это данные имеющие значение только в контексте текущего сианса пользователя (или между запросами пользователя, что еще короче). Т.е. в рамках всей системы или в рамках большого промжутка времени бесполезные.
Для корзины это то какие товары конкретный пользователь положил в нее за время конкретного сеанса (утрированно -- между login/logout).

Получается, в нашем случае, связь "товары -- пользователь". И в зависимости от того кто хранит эту связь у нас будет stateless/statefull/нечто среднее.

Вернемся к нашей БД:
stateless: пользоваетелю передаются ID-шники товаров которые он положил в корзину. При повторном обращении этот список достается из базы.
statefull: есть дополнительная таблица, которая хранит информацию какой пользователь положил в корзину какой товар. На стороне пользователя ничего не храниться.
Нечто среднее (комбинация первых двух): ID товаров хранятся у пользователя, но в базе хранится информация о том, что такой-то товар положили в корзину (безотносительно к пользователю) (пессимистическая блокировака, в отличии от оптимистической в первом случае).

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

Вариант когда на стороне пользователя храниться полностью весь товар, а не ID не касается темы разговора, так как это оптимизация, а не stateless/full.
IB>Формально, stateless считается, если состояние объекта приходится явно восстанавливать из какого-нибудь внешнего контейнера при каждом обращении, но это довольно условная граница..
Перечитаю-ка я Фаулера (от него я впервые услышал об stateless/full).

Здравствуйте, Aikin, Вы писали:

A>Все не так или или же немного не так?
Все.

A>Начнем с того, что сам протокол HTTP является stateless.
Причем здесь протокол?

A>Про корзину -- ответов как минимум три: да, нет и "и да, и нет". В зависимости от реализации.
Ответ один — это stateless, в общепринятом понимании, но опять-таки повторюсь — граница довольно условна, любому приложению, в конечном итоге, от состояния никуда не деться.

A>Про историю -- это однозначный stateless. Эти данные нужны приложению (вернее его владельцам) даже больше чем самому пользователю.
Какая разница кому они нужны — это состояние и оно остается состоянием вне зависимости от того, кто его потребитель.

A>Хотелось бы уточнить что такое state (замечу, что четкой формулировки вчера еще не было, и сформировалось оно в голове у меня только сейчас).
A>State -- это данные имеющие значение только в контексте текущего сианса пользователя (или между запросами пользователя, что еще короче).
State — это данные. Все, точка. Это данные, вне зависимости от контекста, не надо придумывать ничего лишнего.

A>Т.е. в рамках всей системы или в рамках большого промжутка времени бесполезные.
То есть, у всей системы в целом, по твоему, состояния быть не может?

A>statefull: есть дополнительная таблица, которая хранит информацию какой пользователь положил в корзину какой товар. На стороне пользователя ничего не храниться.
На стороне пользователя не может ничего не хранится, в этом случае ты не сможешь этого пользователя идентифицировать.
Так что это тоже типа stateless. Разница лишь в том, что в первом случае пользователь приходит с десятком идентификаторов и говорит "вот это мои товары", а в другом приходит с одним идентификатором и говорит "вот он я".
С какого количества идентификаторов на клиенте, по твоему, statefull начинает становиться stateless, и почему?

A>Перечитаю-ка я Фаулера (от него я впервые услышал об stateless/full).
Перечитай, перечитай...
А вообще, еще лет семь назад, на эту тему было очень правильное выступление Стива Шварца и Клеменса Вастерса, боюсь, правда, что тогда никто ничего не записывал....

Браво!!! Супер просто!!! Вот это я понимаю конструктивная беседа. Пришел, быстренько разметал оппонента, ничего не предложив взамен, и с гордым видом удалился. Так и надо вести беседу!!!! Зачем напрягаться, зачем доказывать свою точку зрения, когда можно простыми наездами сделать много большее?
И знаете, часто это очень действенное средство. Особенно против людей не совсем разбирающихся в теме.

Ну ничего, мы тоже так умеем, поехали...

A>>Все не так или или же немного не так?
IB>Все.
Замечательный ответ. А вы знаете, что когда все неправильно об этом говорят и останавливаются. Дают ссылки на литературу либо объясняют сами. Потому что комментирлвать полностью неправильные слова нет смысла.
Комментируют только тогда, когда точка зрения ошибочна, но не полностью. Только в этом случае имеет смысл корректировать слова собеседника.

A>>Начнем с того, что сам протокол HTTP является stateless.
IB>Причем здесь протокол?
А при том, что это основа основ, часть фундамента на которм построена вэб-разработка. Фундаментальные понятия накладывают отпечаток на все остальные вещи. В данном случае на искуственное добавление состояния в транспорт, который его не поддерживает. Если вы этого не понимаете о чем мы тогда разговариваем?

A>>Про корзину -- ответов как минимум три: да, нет и "и да, и нет". В зависимости от реализации.
IB>Ответ один — это stateless, в общепринятом понимании, но опять-таки повторюсь — граница довольно условна, любому приложению, в конечном итоге, от состояния никуда не деться.
Замечательное у вас определение состояния (которого мы кстати, еще не видели)! То у вас почти нет чистого stateless, то большой класс решений оказывается stateless. Как это понимать?

A>>Про историю -- это однозначный stateless. Эти данные нужны приложению (вернее его владельцам) даже больше чем самому пользователю.
IB>Какая разница кому они нужны — это состояние и оно остается состоянием вне зависимости от того, кто его потребитель.
В каком смысле вы понимаете термин "состояние"?

A>>Хотелось бы уточнить что такое state (замечу, что четкой формулировки вчера еще не было, и сформировалось оно в голове у меня только сейчас).
A>>State -- это данные имеющие значение только в контексте текущего сианса пользователя (или между запросами пользователя, что еще короче).
IB>State — это данные. Все, точка. Это данные, вне зависимости от контекста, не надо придумывать ничего лишнего.
Товарищ модератор, а вы не путаете, случаем, мягкое с горячим? Данные -- это данные. Они же стэйт в ООП. Но причем тут вэбразработка?
Подумайте на досуге почему понятия stateless/full server приминимы только к вэб-разработке, почему они не используются с настольными приложениями (которые, кстати statefull)? Ведь и там и там ДАННЫЕ. Да и без данных вообще программирование безсмысленно. Получается что понятия stateless вообще не существует, а люди его просто себе выдумали (чтоб сложнее жилось)? Неувязочка вышла

A>>Т.е. в рамках всей системы или в рамках большого промжутка времени бесполезные.
IB>То есть, у всей системы в целом, по твоему, состояния быть не может?
В каком смысле вы понимаете термин "состояние"? Как я уже сказал, ИМХО, вы путаете теплое с мягким.

A>>statefull: есть дополнительная таблица, которая хранит информацию какой пользователь положил в корзину какой товар. На стороне пользователя ничего не храниться.
IB>На стороне пользователя не может ничего не хранится, в этом случае ты не сможешь этого пользователя идентифицировать.
IB>Так что это тоже типа stateless. Разница лишь в том, что в первом случае пользователь приходит с десятком идентификаторов и говорит "вот это мои товары", а в другом приходит с одним идентификатором и говорит "вот он я".
IB>С какого количества идентификаторов на клиенте, по твоему, statefull начинает становиться stateless, и почему?
Причем здесь количестко? Все дело в качестве.

A>>Перечитаю-ка я Фаулера (от него я впервые услышал об stateless/full).
IB>Перечитай, перечитай...
IB>А вообще, еще лет семь назад, на эту тему было очень правильное выступление Стива Шварца и Клеменса Вастерса, боюсь, правда, что тогда никто ничего не записывал....
Либо давайте цитату и/или ссылку либо вообще их сюда не вмешивайте.

Ваш выход, сэр.

P.S. Ну как у меня получилось? По моему неплохо. Самое главное, что это намного проще чем предлагать что-то конструктивное. 10 минут сегодня против 1,5 часов вчера. Да это действительно рульлный способ!!! Только вот это не мой метод (Но кто сказал, что ты не должны владеть техникой оппонента?).

Здравствуйте, Aikin, Вы писали:

A>Вот это я понимаю конструктивная беседа.
Когда обсуждают не вопрос, а способ общения собеседника — это называется демагогия. Понятия не имею, что так задело твою тонкую душевную организацию, но если уж ты пронес свежепридуманную пургу, то уж не обижайся, когда тебя поправляют, тем более, что сделано все было достаточно корректно.

A>Пришел, быстренько разметал оппонента, ничего не предложив взамен, и с гордым видом удалился.
Взамен чего тебе надо что-то предложить?

A> Особенно против людей не совсем разбирающихся в теме.
Ну, если ты в ней не разбираешься, зачем тогда споришь?

A>>>Все не так или или же немного не так?
IB>>Все.
A>Замечательный ответ.
Заметь — это четкий, конкретный и совершенно верный ответ на твой вопрос. Что тебя в нем не устраивает?

A>А при том, что это основа основ, часть фундамента на которм построена вэб-разработка.
А причем тут веб-разработка? Причем тут вообще http? Ты оригинальный вопрос внимательно прочитал, прежде чем в бой бросаться?

A>Фундаментальные понятия накладывают отпечаток на все остальные вещи.
Ну, расскажи мне, как фундаментальное понятие поможет мне обойтись без состояния в моем приложении.

A> Если вы этого не понимаете о чем мы тогда разговариваем?
Я так понимаю, что мы разговариваем о том, что ты не очень хорошо понимаешь.

A> Как это понимать?
Могу еще раз повторить. В общепринятой трактовке, если состояние после каждого изменения сбрасывается во внешнее хранилище (в частности БД), и при новом обращении достается оттуда, то это stateless. Хотя формально стейт никуда не девается.

A>В каком смысле вы понимаете термин "состояние"?
В том смысле, что это данные.

A>Товарищ модератор, а вы не путаете, случаем, мягкое с горячим?
Я примерно представляю, кто здесь что и с чем путает.. =))

A> Данные -- это данные. Они же стэйт в ООП. Но причем тут вэбразработка?
"Фундаментальные понятия накладывают отпечаток на все остальные вещи." (с).

А вот при чем тут веб-разработка, это я хочу у тебя спросить. Начнем с того, что автор оригинального вопроса ни словом не обмолвился ни про веб, ни про http... Или тебя слово сервис смутило? Так сервисы и в десктопе есть...

A>Подумайте на досуге почему понятия stateless/full server приминимы только к вэб-разработке,
Обожемой... Для тебя наверное это новость, но термины satefull/stateless Application Server пришли в веб, да и во все остальные места, из распределенных приложений масштаба предприятия. Так что утверждение, что они применимы только к веб — мягко говоря, является большим заблуждением, вернее было бы сказать, что они, помимо всего прочего, применимы еще и в веб...
Я тебе даже больше скажу, веб в данном смысле, вообще мало отличается от обычного корпоративного распределенного приложения, особенно если речь идет о сервисах. Так что как-то не очень понятно, из каких соображений ты выделяешь веб и пытаешься придумать для него свою терминологию, отличающуюся от общепринятой.

A>Да и без данных вообще программирование безсмысленно. Получается что понятия stateless вообще не существует, а люди его просто себе выдумали (чтоб сложнее жилось)?
Именно это я тебе и сказал с самого начала, но ты почему-то спорить полез.

A>Причем здесь количестко? Все дело в качестве.
И в каком качестве тут дело? Формальный критерий можешь придумать?

A>Либо давайте цитату и/или ссылку либо вообще их сюда не вмешивайте.
Суть я пересказал — стейт никуда не девается, вся разница лишь в том, как далеко он находится от места обработки.

A>P.S. Ну как у меня получилось? По моему неплохо.
Неумелая демагогия приравнивается к эксгибиционизму в особо крупных размерах, срам лучше все же прикрывать.

Прошу прощения, что долго не отвечал -- искал Фаулера, читал, анализировал, готовил ответ, ...

IB>Понятия не имею, что так задело твою тонкую душевную организацию, но если уж ты пронес свежепридуманную пургу, то уж не обижайся, когда тебя поправляют
Да не думай ты про мою "тонкую душевную организацию", говори как есть, только, плиз, аргументированно. Я, конечно, понимаю, что для тебя твои ответы полностью аргументированны, но подумай и о тех кто их будет читать.
Я на форуме не для того, чтобы доказать кому-то что я супер-пупер-гений-"всем байацца". Я здесь для того чтобы учиться. И это самая главная моя цель. А кто учился не набивая "шишек"?
Есть в рунете форум по программированию на котором я имею репутацию очень хорошего специалиста, только вот толку с того, если учиться там уже нечему?

IB>Заметь — это четкий, конкретный и совершенно верный ответ на твой вопрос. Что тебя в нем не устраивает?
Я считаю его необоснованным. Более того, так как он неаргументированный, я даже не имею ни малейшего шанса оценить его верность.

---

Фаулер, "Архитектура корпоративных приложений", глава 6 "Сеансы и состояния", цитаты:
Предисловие:

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

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

Что такое сервер с состоянием и без:

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

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

Примеры серверов без состояния и объектов сервера ссостоянием:

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

"Сеанс с состоянием" и "сервер с состоянием":

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

Про "состояние сеанса":

Содержимое карты покупателя, о которой упоминалось в предыдущем разделе, пред-ставляет состояние сеанса (session state) — в том смысле, что данные, отображаемые в кар-те, имеют отношение только к конкретному сеансу. Это состояние действительно в кон-тексте конкретной бизнес-транзакции, т.е. отделено от других сеансов и охватываемых ими бизнес-транзакций. Состояние сеанса отличается оттого, что принято называть хранимыми данными (record data), т.е. от информации, которая размещается в базах данных и становится доступной для сеансов всех пользо-вателей, наделенных соответствующими полномочиями. Чтобы информация состоя-ния сеанса приобрела статус хранимых данных, она должна быть зафиксирована в базе данных.
...
Не все данные, хранимые на протяжении сеанса, трактуются как состояние сеанса. Во время протекания сеанса некоторая информация может кэшироваться, причем не в целях сохранения, а для повышения производительности системы. Поскольку данные кэш-памяти можно удалить без потери функциональности, они принципиально отлича-ются от состояния сеанса, которое подлежит обязательному сохранению в промежутках между циклами обработки запросов.

Способы сохранения состояния сеанса:

1) Типовое решение сохранение состояния сеанса на стороне клиента предусматривает сохранение информации о состоянии сеанса на клиентской машине. Существует несколько вариантов достижения цели: кодирование данных для Web-представления, использование файлов cookie, сериализация информации в скрытых полях Web-формы и сохранение объектов в приложении толстого клиента.
2) Сохранение состояния сеанса на стороне сервера может быть, в частности, настолько простым, как размещение данных в памяти на период между циклами обработки запросов. Однако обычно используется механизм долговременного хранения информации в виде некоего сериализованного объекта. Объект сберегают в фай-ловой системе сервера приложений или в источнике данных, допускающем совместный доступ, например в виде простой таблицы базы данных с двумя полями: первое — ключ сеанса, а второе — содержимое сериализованного объекта.
Решение сохранение состояния сеанса в базе данных также предусматривает использование носителей сервера, но с более тщательным структуриро-ванием информации по таблицам и полям базы данных.

---

Мои комментарии:
Начну с того, произошла путаница, прошу меня за это извинить, я говорил про "сеанс с/без состояния", а не про "сервер с/без состояния". С другой стороны, перечитав первый пост темы, я считаю, что автор имел ввиду именно сеансы с/без состояния.
И еще: большинство серверов являются серверами без состояния, особенно это касается вэб серверов трактующих каждый запрос пользователя как абсолютно новый (именно это я хотел сказать ссылаясь на HTTP).


Все же остальное я, ИМХО, излагал верно. Ключевые фразы в цитатах я выделил. Выводы делайте сами.



P.S. Просто ответы IB
A>>А при том, что это основа основ, часть фундамента на которм построена вэб-разработка.
IB>А причем тут веб-разработка? Причем тут вообще http? Ты оригинальный вопрос внимательно прочитал, прежде чем в бой бросаться?
Название темы: "stateless/full web service"

A>>Фундаментальные понятия накладывают отпечаток на все остальные вещи.
IB>Ну, расскажи мне, как фундаментальное понятие поможет мне обойтись без состояния в моем приложении.
Я не про то как обойтись без состояния, а про то, что это состояние нужно куда-то сохранять между запросами пользователя раз протокол этого не поддерживает (я не говорю, что он должен, боже мой, только этого не хватало).

A>>Подумайте на досуге почему понятия stateless/full server приминимы только к вэб-разработке,
IB>Обожемой... Для тебя наверное это новость, но термины satefull/stateless Application Server пришли в веб, да и во все остальные места, из распределенных приложений масштаба предприятия. Так что утверждение, что они применимы только к веб — мягко говоря, является большим заблуждением, вернее было бы сказать, что они, помимо всего прочего, применимы еще и в веб...
IB>Я тебе даже больше скажу, веб в данном смысле, вообще мало отличается от обычного корпоративного распределенного приложения, особенно если речь идет о сервисах. Так что как-то не очень понятно, из каких соображений ты выделяешь веб и пытаешься придумать для него свою терминологию, отличающуюся от общепринятой.
Не, я не про то говорил. Я про standalone приложение (паинт, ворд, фотошоп, ...) в которых данные есть, а stateless понятия нет.

Здравствуйте, Aikin, Вы писали:

A>Прошу прощения, что долго не отвечал -- искал Фаулера, читал, анализировал, готовил ответ, ...

>>skipped

Мне кажется, ты не понял что имел ввиду ИВ. Когда состояние объекта сохраняется в памяти между сосденими обращениями — это statefull. Когда оно скидывается к примеру в б д и потом восстанавливается при новом обращении — это stateless. При этом ключевым моментом является изменение объекта. В statefull просто меняется объект в памяти, шаренный между обращениями. В stateless состояние меняется локально — мы его меняем только для того, чтобы сохранить в б д измененный объект с целью его восстановления.

Грубо говоря

statefull:

object.addPoint(new Point(newId))

где object существует в сессии е примеру или расшарен между сессиями (неважно)
и stateless:

public static void addPointProcedure(int newId)
{
PointCollection object = Database.load(newId);
object.addPoint(new Point(newId));
Database.store(object)
}

Что касается веб-сервера, который возвращает html-страницу в ответ на запрос — это лишь кусок от stateless, в котором не показан способ изменения состояния, о котором я написал выше.

LP>Мне кажется, ты не понял что имел ввиду ИВ. Когда состояние объекта сохраняется в памяти между сосденими обращениями — это statefull. Когда оно скидывается к примеру в б д и потом восстанавливается при новом обращении — это stateless.
Нет это утверждение я понял. Я не понял почему именно оно является определением стэйтфулл/лесс.

Еще раз говорю, в моем понимании стэйтфулл/лесс -- это то что написано у Фаулера, так как я впервые прочитал это у него.
Кроме того я не использовал слова statefull/stateless голословно, я расписал что я имеюю ввиду под ними. После чего достаточно было сказать, что мы просто говорим о разных вещах.

LP>При этом ключевым моментом является изменение объекта. В statefull просто меняется объект в памяти, шаренный между обращениями. В stateless состояние меняется локально — мы его меняем только для того, чтобы сохранить в б д измененный объект с целью его восстановления.
LP> Грубо говоря
В данном определении слишком тонкая грань между stateless/full.

Такой пример (грубая архитектура сессий в ASPNet):

      private void SessionUsage() // Session использует ISession для сохранения
      {
          // запрос
          // обработка
          anObject.addPoint(new Point(newId));
          Session.Set("anObject", aObject); // как-то ведь нужно сохранить объект между сеансами связи

          // разрыв связи, пользователь что-то читает, что-то меняет
          // второй запрос
          
          anObject = Session.Get("anObject"); // восстановили объект
          // работаем дальше 
      }


        // интерфейс и его реализации
    public interface ISession
    {
        void Set(string id, object anObject);
        object Get(string id);
    }

    public class InMemorySession :ISession
    {
        private readonly Hashtable _internalSet = new Hashtable();

        public void Set(string id, object anObject)
        {
            _internalSet[id] = anObject;
        }

        public object Get(string id)
        {
            if(_internalSet.ContainsKey(id) )
            {
                return _internalSet[id];
            }

            return null;
        }
    }

    public class InDBSession : ISession
    {
        private readonly DBSessionRepository _internalRepository = new DBSessionRepository();

        public void Set(string id, object anObject)
        {
            _internalRepository.Save(id, anObject);
        }

        public object Get(string id)
        {
            return _internalRepository.Load(id);
        }
    }

Что тут stateless/full сеанс? По Фаулеру можно дать дать одночначный ответ: это statefull сеанс.



LP>Что касается веб-сервера, который возвращает html-страницу в ответ на запрос — это лишь кусок от stateless, в котором не показан способ изменения состояния, о котором я написал выше.
Не понял, как-то. Можно подробнее

Возвращаясь на землю, имею следующий вопрос.


А чем принципиально будет отличатся stateless по сердствам базы данных от statefull по средствам load balancer'a или иного фасада ?

Теже несколько нод ?
Какой то внешний контейнер.
Разница в том что load balancer сам падает state на ноды, а в случае с БД сами ноды тянут от туда state ?
Какие есть приемушества у этих подходов с точки зрения, маштабируемости, расширения, ограничений ?
На мой взгляд одно и тоже...

IB>Возможно работать будет по шустрее, но такого рода кеш ты всегда сможешь прикрутить поверх stateless, поставить лоад балансер и добиться ровно такого же эффекта.
Мне думается мы говорим об одном и том же ?

Вероятно можно назвать stateless сервисы которые не тянут, а получают своё состояние из вне ?

Здравствуйте, Aikin, Вы писали:

A>Да не думай ты про мою "тонкую душевную организацию", говори как есть,
Я как есть и говорю — все не так.

A>только, плиз, аргументированно.
Очень знаешь ли сложно говорить аргументировано, в ответ на совершенно неаргументированный поток сознания.

A> Я здесь для того чтобы учиться. И это самая главная моя цель.
У тебя странный способ это делать. Вместо того, чтобы просто спросить, ты придумываешь свою теорию и ждешь, чтобы тебя разубедили.

A>Я считаю его необоснованным.
Твои проблемы.

A>Фаулер, "Архитектура корпоративных приложений", глава 6 "Сеансы и состояния", цитаты:
Я всегда говорил, что неокрепший мозг Фаулер разрывает напрочь. А тут еще, похоже, не очень адекватный перевод.

A>Различия между системными и бизнес-транзакциями
Отложи пока системные транзакции, бизнес-транзакции и сессии — а то совсем закопаешься. Они имеют весьма слабое отношение к текущему разговору.

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

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

A>Теперь вообразите, что ставится задача сбора сведений обо всех кодах ISBN, запрашиваемых клиентом с определенным IP-адресом. Информацию можно располагать в списке, поддерживаемом объектом сервера. В паузах между циклами обработки запросов список должен каким-то образом сохраняться, поэтому речь следует вести об объекте сервера "с состоянием".
Опять ты не то выделил. Суть содержится во фразе "Информацию можно располагать в списке, поддерживаемом объектом сервера." Смысл этой фразы в том, что мы добавляем в нашу систему объект "список заказов", и состояние этого объекта не восстанавливается при каждом новом запросе из внешнего хранилища (stateless), а сервер сам держит этот объект в актуальном состоянии между вызовами и помещает в него информацию обо всех новых заказах (statefull). Ровно с тем же успехом я могу при каждом новом запросе восстанавливать этот объект из БД, прошерстив таблицу заказов — и схема волшебным образом становится "stateless".

A> С другой стороны, перечитав первый пост темы, я считаю, что автор имел ввиду именно сеансы с/без состояния.
Автор совершенно четко написал, что имел ввиду приложение.
А "Сеанс/сессия с состоянием", обычно называется сессия. Просто в EJB под сессией понимается просто единичное обращение к серверу, поэтому там используется термин "сессия с состоянием", чтобы как-то обозначить такого рода сценарии.

A>И еще: большинство серверов являются серверами без состояния,
У тебя есть конкретные цифры?

A> особенно это касается вэб серверов трактующих каждый запрос пользователя как абсолютно новый (именно это я хотел сказать ссылаясь на HTTP).
Как я уже неоднократно говорил, совершенно не факт, что ресь идет про веб и http.

A>Ключевые фразы в цитатах я выделил.
Ты какие-то не те фразы выделил.
Мартин, как всегда, в своем репертуаре. Он не привел ни одной четкой формулировки или формального критерия, но мозг запудрил конкретно, приводя довольно противоречивые примеры и тезисы. Продраться через его весьма многословные описания до сути (хотя иногда оно того стоит) бывает весьма проблематично, так что рекомендую читать его аккуратно и внимательно.

A>Название темы: "stateless/full web service"
Тебя термин web-service смутил? В настоящее время этот термин имеет весьма посредственное отношение к вебу. Например, транспортом может служить MSMQ, tcp/ip, named-pipe, а не только http. Более того, веб-сервисы отлично работают в рамках одной машины для межпроцессного взаимодействия в сугубо десктопных приложениях, какой тут веб?

A>Я не про то как обойтись без состояния, а про то, что это состояние нужно куда-то сохранять между запросами пользователя раз протокол этого не поддерживает (я не говорю, что он должен, боже мой, только этого не хватало).
Дело в том, что тебе его в любом случае надо где-то хранить, вне зависимости от того, поддерживает это протокол или нет.

A>Не, я не про то говорил.
Тебе напомнить что ты говорил? "понятия stateless/full server приминимы только к вэб-разработке" (С)
Так вот, этот термин даже появился не в веб-разработке.

A>Я про standalone приложение (паинт, ворд, фотошоп, ...) в которых данные есть, а stateless понятия нет.
Правильно, потому что там нет необходимости восстанавливать состояние при каждом обращении к объекту.