[quote=celso.martins]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.[/quote]
Se o “fórum do GUJ” sofrer alguma alteração no serviço você vai descobrir acessando a url inicial, www.guj.com.br.
ps: Estou usando o GUJ como exemplo não porque se trate de um serviço restful. O GUJ não é uma aplicação REST! Mas pelo fato de ser uma aplicação web e por estarmos falando de web-based services algumas analogias se aplicam.
“Me dê informações sobre o maior fórum sobre Java do Brasil”[/quote]
Ok, digamos que o GUJ se funda com um outro forum de Java (www.javaiscool.com.br). o GUJ tinha um serviço para disponibilizar conteúdo (GET www.guj.com.br/posts) e o javaiscool tenha outro que faz algo parecido (GET www.javaiscool.com.br/messages). Como os dois forums se fundiram, o correto seria ter um mecanismo que “junte” os dois.
É bem simplista, mas existem muitas situações assim, não sou especialista nessas suites de SOA por aí, mas eles dizem resolver esse probelma
“Me dê informações sobre o maior fórum sobre Java do Brasil”[/quote]
Ok, digamos que o GUJ se funda com um outro forum de Java (www.javaiscool.com.br). o GUJ tinha um serviço para disponibilizar conteúdo (GET www.guj.com.br/posts) e o javaiscool tenha outro que faz algo parecido (GET www.javaiscool.com.br/messages). Como os dois forums se fundiram, o correto seria ter um mecanismo que “junte” os dois.
É bem simplista, mas existem muitas situações assim, não sou especialista nessas suites de SOA por aí, mas eles dizem resolver esse probelma
[/quote]
E o que esse mecanismo tem a ver com as urls?
Não sei até que ponto isso é um problema em SOA, mas no caso da web não há problema algum. URLs podem apontar para o mesmo recurso, diretamente ou não, via redirects.
Bom, você também pode ter serviços contemplando diversos contratos. O que o ESB lhe dá no caso citado pelo Rubem é transformação de estrutura de dados, para uma possível integração ou roteamento interno, de acordo com uma premissa da requisição.
PS: Não sabia desse tópico, volto amanhã cedo pra responder tudo …hoje se continuar, minha noiva me esfola
[quote=saoj]O que o pessoal tem visto por aí nos projetos?
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.
[/quote]
Voltando à pergunta central, WebService é sim de fato Statless. O ESB pode autenticar uma requisição com usuário ou certificado digital para você numa base LDAP por exemplo e propagar essa autenticação aos outros serviços, utilizando a especificação WS-Security, aliás esse é um dos pontos da implementação tradicional com SOAP + WSDL vs REST.
Quanto ao uso de WebService com estado, esqueça. O máximo que pode ter são Callbacks para cenários assíncronos.
[quote=Kenobi]Bom, você também pode ter serviços contemplando diversos contratos. O que o ESB lhe dá no caso citado pelo Rubem é transformação de estrutura de dados, para uma possível integração ou roteamento interno, de acordo com uma premissa da requisição.
PS: Não sabia desse tópico, volto amanhã cedo pra responder tudo …hoje se continuar, minha noiva me esfola
[/quote]
Sei que o roteamento pode trazer mais um fator gerador de complexidade (o próprio ESB), mas algo me agrada nessa arquitetura onde todas as extremidades só deveriam conhecer o ESB e o serviço consumido.
E voltando ao que afirmei antes. Não sei se esse acoplamento (cliente conhecendo serviço e quem fornece o serviço) seria, realmente, um problema, principalmente quando colocado de frente com a facilidade de escalar um sistema desses.
Antes de postar gostaria de esclarecer os termos que estão sendo usados nesse tópico de forma um pouco confusa:
SOA - Estilo arquitetural que cuida de gestão e integração de aplicações baseado em serviços (que podem ser SOAP ou REST ou qualquer outra coisa)
SOAP - Protocolo para criação de serviços.
REST - Estilo arquitetural baseado totalmente no protocolo HTTP
Sobre a questão de serviços stateless, tirando como exemplo o carrinho de compras, você poderia ter serviços do tipo:
POST /carrinho - que te devolveria o ID do carrinho criado e ai o cliente guardaria esse ID (no caso de uma app web na session se quiser)
PUT /carrinho/{ID} - Atualizar itens do carrinho
GET /carrinho/{ID} - Pegar o carrinho com todos os dados
DELETE /carrinho - Apagaria todos os itens do carrinho
Eu escrevi isso bem rápidamente pra ilustrar como os serviços não precisam ser statefull. Essa implementação nem é a ideal para carrinho de compras mas é só pra pegar seu exemplo mesmo. Resumindo, se projetar bem sua arquitetura, não será problema ter serviços stateless.
Mochuara, pelo menos na minha visão eu não vejo vantagem REST sobre SOAP + WSDL, por mais que vc tenha que regerar o seu cliente
oq é fácil d+, e no caso do REST se os atributos seu serviço mudam o cliente também é impactado, coisa que acredito ser fácil de resolver.
E no lado do servidor com ESB o impacto na mudança de serviços é transparente, vc pode criar até regras de negócio em seu proxy para direcionar de acordo com a situação par o serviço adequado, vc nem sabe qual é o serviço implementado apenas segue o contrato.
[quote=Emerson Macedo]Antes de postar gostaria de esclarecer os termos que estão sendo usados nesse tópico de forma um pouco confusa:
SOA - Estilo arquitetural que cuida de gestão e integração de aplicações baseado em serviços (que podem ser SOAP ou REST ou qualquer outra coisa)
SOAP - Protocolo para criação de serviços.
REST - Estilo arquitetural baseado totalmente no protocolo HTTP
[/quote]
REST não é uma arquitetura baseada em serviços, portanto REST e SOA nada tem a ver.
Mochuara, pelo menos na minha visão eu não vejo vantagem REST sobre SOAP + WSDL, por mais que vc tenha que regerar o seu cliente
oq é fácil d+, e no caso do REST se os atributos seu serviço mudam o cliente também é impactado, coisa que acredito ser fácil de resolver.
E no lado do servidor com ESB o impacto na mudança de serviços é transparente, vc pode criar até regras de negócio em seu proxy para direcionar de acordo com a situação par o serviço adequado, vc nem sabe qual é o serviço implementado apenas segue o contrato. [/quote]
Se o contrato muda e o cliente, que funciona como stub, deve ser gerado novamente, então a mudança não é transparente.
Vc não me entendeu, ou melhor dizendo não fui claro o suficiente, eu disse que podemos colocar inteligência no ESB a ponto de ele trocar um serviço por outro serviço, sem o cliente ficar sabendo. ESB também pode alterar os parametros mensagem original para adequar a mensagem para consumir o serviço, esse processo é transparente.
[quote=DaviPiala]Vc não me entendeu, ou melhor dizendo não fui claro o suficiente, eu disse que podemos colocar inteligência no ESB a ponto de ele trocar um serviço por outro serviço, sem o cliente ficar sabendo. ESB também pode alterar os parametros mensagem original para adequar a mensagem para consumir o serviço, esse processo é transparente.
[/quote]
Isso se chama depender de interfaces, não de implementação. Das coisas mais básicas na computação.
Acredito que você só conheça sistemas REST usando HTTP, mas isso não faz do REST uma arquitetura baseada no HTTP. A não ser que esteja falando de alguma versão proprietária de REST. Sem ofensas, mas se informe em relação ao assunto antes pra não falar besteira.
[quote=Rubem Azenha]
E REST é uma forma de disponibilizar serviços, se você vai basear sua arquitetura nisso ou não depende de você e não da tecnologia.[/quote]
Depende da sua definição de serviços. Acredito que esteja falando de serviços no contexto de SOA, neste caso REST e SOA são arquiteturas totalmente distintas.
REST é uma forma de disponibilizar serviços??
Novamente, se informe sobre o assunto ou então cite suas fontes para que possamos discutir.
