Stateful Web Services

This message was edited 2 times. Last update was at 17/06/2009 17:31:45

O que o pessoal tem visto por aí nos projetos?

1) Web Services têm que ser stateless. Envie username / password em cada request encryptado (https) e eu autentico/carrego o User em cada request.

2) Web Service Session: como numa aplicação web, para eu pelo menos guardar o objeto User autenticado e poder ter algo similar a uma session ID para não precisar ficar autenticando, carregando User, checando o password do cara toda hora.

3) Sticky Service (serviço persistente): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

Entendo os problemas de escalabilidade e fail-over de stateful services (ou das sessions numa aplicação web), mas em algumas situações você precisa ter um estado, como num carrinho de compras, por exemplo. Se bem que mesmo nesses casos onde um estado é necessário vc pode colocá-lo no banco-de-dados (usar o back-end como session

) ou no cliente (o cliente recebe o carrinho com tudo dentro e se encarrega de guardá-lo e repassá-lo entre as requisições).

A verdade é que em aplicações web acabamos por utilizar a session em situações onde ela facilita muito. Em web services isso é estritamente proibido ou se utiliza também? Estou inclinado a concluir que web service não é uma aplicação web e aceitar a opção 1) sempre stateless, mas queria ouvir a opinião de outros baseado em projetos reais.

Cara, estou há um certo tempo para falar sobre isso. Vou falar agora.

Não tenho domínio sobre o assunto. O que conheço é "o famoso" que tenho lido por aí.

Há pouquíssimo tempo atrás, vi empresas vendendo ESB (inlcusive na contracapa da MJ) como um centralizador de requisições. Dessa forma, quem estivesse consumindo o serviço, só precisaria conhecer como falar com o ESB. Concordo com que o Jim Webber falou no "Falando em Java", pois o ESB pode acabar se tornando um "espaguete encapsulado". Entretanto, por estar em um módulo gerenciável, não seria, obviamente, mais simples de gerenciar? Deixando claro, também, que não passei pelos problemas de escalabilidade que ele citou.

A pergunta é: com os web-based middlewares, o cliente não precisa ter um conhecimento considerável da outra ponta? Isto é, não voltaríamos a arquitetura SOA sem ESB, onde cada web-service era extremamente acoplado a outra extremidade?

Esse é o grande ponto de interrogação que paira sobre a minha cabeça.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

celso.martins wrote:Cara, estou há um certo tempo para falar sobre isso. Vou falar agora.

Não tenho domínio sobre o assunto. O que conheço é "o famoso" que tenho lido por aí.

Há pouquíssimo tempo atrás, vi empresas vendendo ESB (inlcusive na contracapa da MJ) como um centralizador de requisições. Dessa forma, quem estivesse consumindo o serviço, só precisaria conhecer como falar com o ESB. Concordo com que o Jim Webber falou no "Falando em Java", pois o ESB pode acabar se tornando um "espaguete encapsulado". Entretanto, por estar em um módulo gerenciável, não seria, obviamente, mais simples de gerenciar? Deixando claro, também, que não passei pelos problemas de escalabilidade que ele citou.

A pergunta é: com os web-based middlewares, o cliente não precisa ter um conhecimento considerável da outra ponta? Isto é, não voltaríamos a arquitetura SOA sem ESB, onde cada web-service era extremamente acoplado a outra extremidade?

Esse é o grande ponto de interrogação que paira sobre a minha cabeça.

A diferença é que a interface utilizada por um cliente web é genérica (GET, POST, URLs, MediaTypes). Na web o cliente precisa apenas de uma URL inicial para conectar com o serviço. O cliente chega aonde quer da mesma forma que você pode chegar a esse tópico a partir da url www.guj.com.br, ou seja, acessando links.

SOA por sua vez precisa de um cliente gerado por meio de um documento WSDL, e o fato do cliente ser específico para apenas aquela aplicação é que introduz o acoplamento.

This message was edited 1 time. Last update was at 17/06/2009 22:20:25

Na parte de autenticação eu estive utilizando o ws-security ele encapsula no header soap o login e senha, nos outros projetos que eu vi era usados autenticação http, ouvi falar de uma ferramenta de EAI senão me engano o nome é vasco que trabalha com uma solução bacana de tokens. Quanto a guardar estado da autenticação no webservice stateful eu acho um pouco perigoso.

Quanto ao ESB, pelo menos na Oracle existe um suite de governança com um produto chamado WebServices Manager que atua como uma camada de autenticação, permissão antes de se direcionar a solicitação pro ESB, não sei se os outros vendors estão indo na mesma onda.

SOA por sua vez precisa de um cliente gerado por meio de um documento WSDL, e o fato do cliente ser específico para apenas aquela aplicação é que introduz o acoplamento.

Cara, eu não consigo enxergar isso como desvantagem, na maioria das ferramentas vc gera o cliente a partir do WSDL com apenas um clique e fica fácil de identificar o "contrato" que vc deve assumir pra consumir o serviço, sem contar que uma ferramenta de governança pode te dar todo o histórico de alterações no contrato que já é uma mão na roda em algumas situações.

mochuara wrote:
A diferença é que a interface utilizada por um cliente web é genérica (GET, POST, URLs, MediaTypes). Na web o cliente precisa apenas de uma URL inicial para conectar com o serviço. O cliente chega aonde quer da mesma forma que você pode chegar a esse tópico a partir da url www.guj.com.br, ou seja, acessando links.

SOA por sua vez precisa de um cliente gerado por meio de um documento WSDL, e o fato do cliente ser específico para apenas aquela aplicação é que introduz o acoplamento.

Imagina 150 clientes podendo consumir 300 serviços. (numero chutado).

Repito, não vi isso na prática, mas não sei se uma URI pode fornecer mais de um serviço. Se puder, deve ter um indicador para o serviço requerido. Dessa forma, o cliente precisa conhecer a URI e a identificação do destino, aumentando o acoplamento. Na engenharia de software OO temos diversos exemplos de introdução de uma classe intermediária para reduzir o acoplamento entre duas classes. Posso estar viajando, mas me parece que o ESB faz exatamente esse papel.

Eu conhecer guj.com.br é uma coisa (e nem conheço todos os endereços que acesso diariamente), os clientes conhecerem detalhes de conexão de todos os serviços consumidos por eles é outra.

This message was edited 1 time. Last update was at 17/06/2009 22:34:05

DaviPiala wrote:

SOA por sua vez precisa de um cliente gerado por meio de um documento WSDL, e o fato do cliente ser específico para apenas aquela aplicação é que introduz o acoplamento.

Cara, eu não consigo enxergar isso como desvantagem, na maioria das ferramentas vc gera o cliente a partir do WSDL com apenas um clique e fica fácil de identificar o "contrato" que vc deve assumir pra consumir o serviço, sem contar que uma ferramenta de governança pode te dar todo o histórico de alterações no contrato que já é uma mão na roda em algumas situações.

Vejo muitos problemas, nas equipes vizinhas, com relação a manutenção.

EDIT: Hoje em dia estão pensando em adotar o ESB. E já ouvimos por aí que não é a melhor solução. Coisas de TI.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

celso.martins wrote:
Imagina 150 clientes podendo consumir 300 serviços. (numero chutado).

Repito, não vi isso na prática, mas não sei se uma URI pode fornecer mais de um serviço. Se puder, deve ter um indicador para o serviço requerido. Dessa forma, o cliente precisa conhecer a URI e a identificação do destino, aumentando o acoplamento. Na engenharia de software OO temos diversos exemplos de introdução de uma classe intermediária para reduzir o acoplamento entre duas classes. Posso estar viajando, mas me parece que o ESB faz exatamente esse papel.

Eu conhecer guj.com.br é uma coisa (e nem conheço todos os endereços que acesso diariamente), os clientes conhecerem detalhes de conexão de todos os serviços consumidos por eles é outra.

Procure por web services REST e como usar "Hypermedia as the Engine of Application State" (HATEOAS).

This message was edited 2 times. Last update was at 17/06/2009 22:44:37

Mas foi justamente sobre isso que o Jim Webber falou. E é justamente sobre isso que tenho lido ultimamente (posso não ter entendido nada

).

Só queria entender com é possível reduzir o acoplamento.

Também tenho ressalvas quanto a segurança, mas isso é outra conversa.

EDIT: Eu entendo dessa forma: Cliente -> WEB -> Fornecedor. Como passar pela WEB sem um alto acoplamento entre cliente e fornecedor? Outra questão: Isso é um problema?

Na engenharia de software OO temos diversos exemplos de introdução de uma classe intermediária para reduzir o acoplamento entre duas classes. Posso estar viajando, mas me parece que o ESB faz exatamente esse papel.

Isso, esse conceito veio originalmente de um message broker, o ESB é mais complexo vc consegue fazer com que seus proxys dimensionem a carga no serviço, trocar mensagens com jms, load-balancer e por ai vai.

http://www.soapatterns.org/enterprise_service_bus.asp

DaviPiala wrote:

Na engenharia de software OO temos diversos exemplos de introdução de uma classe intermediária para reduzir o acoplamento entre duas classes. Posso estar viajando, mas me parece que o ESB faz exatamente esse papel.

Isso, esse conceito veio originalmente de um message broker, o ESB é mais complexo vc consegue fazer com que seus proxys dimensionem a carga no serviço, trocar mensagens com jms, load-balancer e por ai vai.

http://www.soapatterns.org/enterprise_service_bus.asp

Blz... estou "abstraindo" essas questões. =)

O que eu quero saber é, o ESB não serve para reduzir o acoplamento?

Para ilustrar a discussão, uma entrevista do Webber com o Ian Robinson sobre Web-based Integration. Eles estão escrevendo um livro sobre o assunto.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

celso.martins wrote:Mas foi justamente sobre isso que o Jim Webber falou. E é justamente sobre isso que tenho lido ultimamente (posso não ter entendido nada ).

Só queria entender com é possível reduzir o acoplamento.

Também tenho ressalvas quanto a segurança, mas isso é outra conversa.

EDIT: Eu entendo dessa forma: Cliente -> WEB -> Fornecedor. Como passar pela WEB sem um alto acoplamento entre cliente e fornecedor? Outra questão: Isso é um problema?

Você tem razão que algum acoplamento deve existir, a diferença que achei que tivesse ficado claro, é que com SOA o acoplamento é introduzido em tempo de compilação, na geração do cliente. No caso de servicos baseados no REST/HTTP o acoplamento só é introduzido dinamicamente, apos o cliente acessar a url inicial. O fato do acoplamento se dar posteiormente e não em tempo de compilação faz com que o serviço possa mudar internamente sem precisar alterações no cliente. Isso pra mim se chama baixo acoplamento.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

celso.martins wrote:Para ilustrar a discussão, uma entrevista do Webber com o Ian Robinson sobre Web-based Integration. Eles estão escrevendo um livro sobre o assunto.

Eu vi essa entrevista, realmente muito boa.

This message was edited 1 time. Last update was at 17/06/2009 22:59:57

O que eu quero saber é, o ESB não serve para reduzir o acoplamento?

Sim, exemplo se vc precisar migrar alguns serviços que estão expostos no ESB pra outro servidor, isso iria ficar transparante.

Notícias, artigos e o maior fórum brasileiro sobre Java