Вопрос по session, web-services – Насколько хороши и / или необходимы Stateful Web Services?

17

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

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

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

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

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

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

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

Ваш Ответ

5   ответов
6

я.

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

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

Я также обнаружил, чтоmany реальный мирweb-services также полагаться на государство.

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

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

Это неstate in web services которые убивают масштабируемость, скорее этоstate on the App Server это хостинг веб-сервисов, который убьет масштабируемость. В тот момент, когда вы говорите, что этому пользователю необходим доступ к этому серверу (как это делается в липких сессиях), вы фактически ограничиваете свои возможности масштабирования. Точка, к которой вы хотите добраться, это то, что «любой из ваших бесплатных серверов приложений с балансировкой нагрузки»; может обработать этот запрос веб-службы, и если яadd 1 more App Server I should be able to handle % more users.

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

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

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

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

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

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

2

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

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

Вам придется время от времени чистить базу данных, но, возможно, вы правы. Выглядит некрасиво, но на самом деле все не так плохо. :-) Если у вас есть сеанс, другим вариантом будет кластер сессий, или вы можете смириться с тем фактом, что если ваш сервер выходит из строя, вы должны начать все сначала (при условии, что у вас есть интеллектуальный балансировщик нагрузки, который отправляет запросы от пользователя к тот же сервер, что не сложно в наше время я бы предположил) TraderJoeChicago
0

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

Это не обязательно, даже со старыми веб-сервисами ASMX. Просто передайте всю необходимую информацию на свой & quot; Логин & quot; операция. Эта операция будет определена для возврата «билета аутентификации» заголовок.

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

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

Эта система тикетов, о которой вы говорите, похоже, отсутствует в JAX-WS. Похоже, они предлагают вам захватить базовый HttpSession, который концептуально совпадает с этой системой тикетов. Но вы должны предположить (достаточно справедливо), что вы будете использовать HTTP для своих сервисов. TraderJoeChicago
Это был бы твой билет - делай это как хочешь. Вы можете включить идентификатор пользователяin билет, если вы хотите, или иметь полный словарь & lt; билет, пользователь & gt; в памяти, загруженные из базы данных, и индексировать ваш тикет при каждом вызове.
Билет аутентификации работает как идентификатор сеанса. Так могу ли я получить аутентифицированный объект User из этого билета или мне нужно отправлять user_id, выполняющий сервис, при каждом вызове сервиса? Я могу ошибаться здесь, но я думаю, что этот билет является формой государства, не так ли? TraderJoeChicago

Похожие вопросы