Насколько хороши и / или необходимы веб-службы с отслеживанием состояния?

Какой сервер вы видите в реальных проектах?

1) Веб-службы ДОЛЖНЫ быть без сохранения состояния: в основном вы должны отправлять имя пользователя / пароль с каждым запросом, каждый запрос должен использовать HTTPS, и я буду аутентифицировать и загружать объект User каждый раз, если это необходимо.

2) Сессия для веб-служб: как в веб-контейнере, поэтому я могу по крайней мере сохранить аутентифицированный объект User и иметь что-то похожее на идентификатор сеанса, поэтому мне не нужно аутентифицировать, загружать и проверять пользователя при каждом запросе.

3) Прикрепленная служба (постоянная служба для запросов): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

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

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

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


stateful session web-services
person TraderJoeChicago    schedule 17.06.2009    source источник

Ответы (5)


arrow_upward
6
arrow_downward

В идеале веб-службы (и веб-сайты) не должны иметь состояния.

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

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

Я также обнаружил, что многие реальные веб-службы также зависят от состояния.

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

person John Weldon    schedule 17.06.2009
comment
Спасибо за отзыв из реальной жизни, Джон. Итак, мой вопрос: если вы решите, что вам нужно состояние, что вы должны использовать. 1) База данных, 2) Состояние на клиенте, 3) сеанс, 4) постоянная служба. Есть простой способ использовать 3 ??? 4 работает ??? Я начинаю соглашаться с Джейсоном в том, что база данных - лучший вариант. :-) - person TraderJoeChicago; 18.06.2009

arrow_upward
19
arrow_downward

Хотя это небольшая разница, но все же следует упомянуть:

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

Совершенно нормально (и лично рекомендуется), если вы хотите поддерживать состояние для передачи токена аутентификации и при каждом запросе получать службу для извлечения вашего `` состояния '' из хранилища данных (предпочтительно избыточного и секционированного, например, распределенного + реплицированного ключа / хранилище данных значения). Вот как Amazon делает это с SimpleDb и Google с BigTable.

Ebay использует несколько иной подход и хранит большинство состояний клиентов в файлах cookie, чтобы они передавались с каждым запросом. Хотя он генерирует намного больше трафика, он по-прежнему масштабируется, поскольку любой из их серверов по-прежнему может обрабатывать запрос.

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

Вам также следует проверить highscalability.com, если вы хотите получить доступ к хорошим материалам о том, как создавать быстрые и масштабируемые услуги.

person mythz    schedule 09.02.2010
comment
Это очень хороший момент, который не следует упускать из виду при разработке веб-сервисов. - person jzonthemtn; 19.05.2016

arrow_upward
2
arrow_downward

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

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

person Jason Watts    schedule 17.06.2009
comment
Время от времени вам придется чистить базу данных, но, возможно, вы правы. Выглядит некрасиво, но на самом деле не так уж и плохо. :-) Если у вас есть сеанс, другим вариантом будет сеансовый кластер, или вы можете смириться с тем фактом, что если ваш сервер выйдет из строя, вам придется начинать заново (при условии, что у вас есть интеллектуальный балансировщик нагрузки, который отправляет запросы от пользователя к тот же сервер, что сейчас не сложно, я полагаю) - person TraderJoeChicago; 18.06.2009

arrow_upward
0
arrow_downward

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

person duffymo    schedule 17.06.2009

arrow_upward
0
arrow_downward

Похоже, вы приравниваете состояние и аутентификацию. Возможно, вы привыкли хранить имя пользователя и пароль в состоянии сеанса?

В этом нет необходимости даже для старых веб-служб ASMX. Просто передайте любую информацию, которая вам нужна, для операции «Вход». Эта операция будет определена для возврата заголовка «Authentication Ticket».

Для всех других операций, требующих аутентификации, потребуется этот заголовок «Authentication Ticket». Каждый из них будет проверять заголовок, чтобы убедиться, что он представляет действительного аутентифицированного пользователя. Если так, то они свою задачу выполнят. В противном случае они вернут ошибку SOAP, указывающую, что требуется аутентификация.

Состояние не требуется. Просто убедитесь, что билет проверки подлинности можно проверить на любом сервере, на котором работает ваша служба (например, в веб-ферме), и все будет в порядке.

person John Saunders    schedule 17.06.2009
comment
Билет проверки подлинности работает как идентификатор сеанса. Итак, могу ли я получить аутентифицированный объект User из этого билета или мне нужно отправлять user_id, выполняющий службу, при каждом вызове службы? Я могу ошибаться здесь, но я бы подумал, что этот билет - форма государства, не так ли? - person TraderJoeChicago; 18.06.2009
comment
Это был бы ваш билет - делайте как хотите. Вы можете включить идентификатор пользователя в тикет, если хотите, или иметь весь тикет Dictionary ‹, User› в памяти, загружать из базы данных и индексировать свой тикет при каждом вызове. - person John Saunders; 18.06.2009
comment
Эта система билетов, о которой вы говорите, похоже, не присутствует в JAX-WS. Похоже, они предлагают вам захватить базовый HttpSession, который концептуально совпадает с этой системой билетов. Но вы должны предположить (достаточно справедливо), что вы будете использовать HTTP для своих служб. - person TraderJoeChicago; 18.06.2009
comment
@Sergio: они предлагают вам взять что-нибудь для конкретной платформы? Планируют ли они, чтобы вы отправили его по сети? А зачем ограничиваться HTTP? - person John Saunders; 18.06.2009
comment
Какой еще вариант для JAX-WS? Самостоятельно внедрить тикет-систему? Совсем несложно, но если я уверен, что буду использовать HTTP, как и большинство WS, зачем вообще заново реализовывать HttpSession? (не стесняйтесь выдвигать свои аргументы, эти дебаты для меня - процесс обучения, а не соревнование) - person TraderJoeChicago; 18.06.2009