Web Services têm que ser stateless. Envie username / password em cada request encryptado (https) e eu autentico/carrego o User em cada request.
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.
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 :roll: ) 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. :lol:
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.
[quote=celso.martins]Cara, estou há um certo tempo para falar sobre isso. Vou falar agora. :lol:
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.[/quote]
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.
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.
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.
[quote=mochuara]
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.[/quote]
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.
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.[/quote]
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. :lol:
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.[/quote]
Procure por web services REST e como usar “Hypermedia as the Engine of Application State” (HATEOAS).
Mas foi justamente sobre isso que o Jim Webber falou. E é justamente sobre isso que tenho lido ultimamente (posso não ter entendido nada :lol: ).
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?
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.
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.
[quote=celso.martins]Mas foi justamente sobre isso que o Jim Webber falou. E é justamente sobre isso que tenho lido ultimamente (posso não ter entendido nada :lol: ).
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?[/quote]
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.
Desculpa, mas não entendi como o acoplamento com HTTP possa ser introduzido dinamicamente. No momento em que for definido que um serviço X deva ser consumido, você precisa saber como encontrar X, pelo que entendo.
E não creio, mais uma vez posso estar errado, que o acoplamento seja definido apenas por uma conhecimento da implementação (parte interna) da outra extremidade da relação. Acredito que uma dependência possa introduzir alto 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.[/quote]
Se considerarmos que a alternativa em questão não introduz acoplamento, qual seria a vantagem em se ter acoplamento? Acredito que deva haver casos onde faça sentido usar SOA, mas não deve ser porque acoplamento é legal certo?
Desculpe o autor do tópico por não estarmos falando especificamente sobre stateful web services, mas pelo menos em relação a web services REST espero que tenha ficado claro que toda comunicação é stateless. Ou seja, ou o carrinho de compra é mantido no cliente, ou como um resource no servidor (não necessariamente em um bando de dados!).
