Насколько хорошими и/или необходимыми являются Stateful Web Services?

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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