Como é bom e / ou necessário são Stateful Web Services?

Question

Que tipo de servidor que você as pessoas vêem em projectos reais?

1) Serviços da Web deve ser apátrida:. Basicamente, você deve enviar nome de usuário / senha com cada pedido, cada pedido deve usar HTTPS e vou autenticar e carregar o objeto do usuário cada vez que se necessário

2) uma sessão para Web Services: como em um container web para que eu possa, pelo menos, salvar o objeto usuário autenticado e ter algo semelhante a um ID da sessão para que eu não precisa se autenticar, carga e verificar o usuário em cada solicitação.

3) Fixo Serviço (serviço persistentes entre solicitações): https : //jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

Eu entendo os problemas de escalabilidade de serviços com estado (e de sessões de aplicação web), mas às vezes você deve ter algum tipo de estado, por exemplo, para um carrinho de compras. Mas você também pode colocar este estado no banco de dados (use o back-end como uma espécie de sessão argh ) ou passar todo o estado para o cliente (o cliente torna-se responsável por reenviar todo o carrinho de compras) .

A verdade é, pelo menos para aplicações web, a sessão ajuda muito em muitas situações. problemas de escalabilidade pode ser ignorado se o seu sistema aceita que "o usuário deve começar de fazer o que ele está fazendo, se o seu servidor web acontece para ir para baixo" ou você pode tentar um cluster sessão se isso é inaceitável.

Como é para serviços web? Estou inclinado a concluir que web serviços são muito diferentes do que as aplicações web e aceito opção 1) (sempre apátrida), mas seria bom ouvir outras opiniões com base na experiência do projeto real.

Answer 1

O ideal webservices (e sites) deve ser apátrida.

Infelizmente isso leva muito bem pensado domínio do problema, e separação clara das preocupações.

Descobri que, na prática mais real-world sites depender de estado apesar de isso limita sua escalabilidade.

Eu também descobri que muitos real-world web-services também dependem do estado.

Finalmente a decisão 'certa' é o que funciona para o problema específico, por isso é provavelmente tudo bem para escrever um webservice que depende de estado, e refatorar-lo mais tarde, se escalabilidade se torna um problema.

Answer 2

Embora seja apenas uma pequena diferença, mas ainda deve ser mencionado:

Não é Estado em serviços web que a escalabilidade matar, mas sim de estado na App Servidor que está hospedando os serviços web que vai matar escalabilidade. No momento em que você diz que este usuário precisa acessar este servidor (como é feito em sessões pegajosas) que você está efetivamente limitar suas opções de escalabilidade. O ponto que você quer chegar é que 'Qualquer um dos seus balanceamento de carga servidores aplicativo gratuito' pode lidar com essa solicitação de serviço web e se eu adicionar 1 mais App Servidor I deve ser capaz de lidar% mais usuários .

É totalmente bem (e recomendado pessoalmente) se você quiser manter o estado de passar em um token de autenticação e em cada pedido obter o serviço para recuperar o seu 'estado' de um armazenamento de dados (de preferência um redundante e particionado um, por exemplo, distribuídos + replicado armazenamento de chaves de dados de valor /). Isso é como Amazon faz isso com SimpleDB eo Google com BigTable.

Ebay tem uma abordagem ligeiramente diferente e armazena a maioria do Estado clientes em um cookie por isso é passado com cada pedido. Embora ele gera um tráfego muito mais, ainda escalável como qualquer um de seus servidores ainda pode manipular a solicitação.

Se você quer um armazenamento de dados escalável eu recomendo olhar Redis tem velocidade e recursos que não pode ser batida em um armazenamento de dados de chave / valor.

Você também deve verificar se highscalability.com se você quer acesso a bom material sobre como construir serviços escaláveis ??e rápido.

Answer 3

Altamente dependente se o serviço é orientado única transação (dizem recebendo cotações de ações) ou se a saída do serviço depende de um conjunto de dados fornecidos a partir de um determinado cliente em várias transações (em deve ser mantida nesse estado caso.)

Quanto problemas de escalabilidade, armazenamento de estado em um banco de dados não é realmente um mau caminho a percorrer (na verdade, é provavelmente a única maneira de ir se você estiver balanceamento de carga seu serviço através de um farm de servidores.)

Answer 4

Eu acho que com clientes Flex estado é movido para fora do serviço e na camada do cliente. Mantenha o apátrida serviços e deixar os clientes manter o estado necessário. Os serviços de permanecer simples, e os clientes são livres para mash-los juntos como quiserem.

Answer 5

Você parece estar igualando estado e autenticação. Talvez você esteja acostumado a armazenar nome de usuário e senha no estado de sessão?

Isso não é necessário, mesmo com serviços ASMX Web idade. Simplesmente passar qualquer informação que você precisa para sua operação "Login". Esta operação será definido para retornar um cabeçalho "Ticket de autenticação".

Todas as outras operações que exigem autenticação irá exigir este cabeçalho "Ticket de autenticação". Eles vão cada verificar o cabeçalho para ver se ele representa um usuário válido, autenticada. Se assim for, então eles irão realizar a sua tarefa. Se não, então eles vão voltar uma SOAP Fault indicando que a autenticação é necessária.

É necessário

No estado. Basta certificar-se de que a permissão de autenticação pode ser validada em qualquer servidor suas corridas de serviços on (por exemplo, em uma fazenda web), e você vai ficar bem.