Stateful Web Services

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.

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.

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.

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.

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.

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. :lol:

celso.martins:

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).

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.

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

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.

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?

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.

Eu vi essa entrevista, realmente muito boa.

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

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.

Como assim em tempo de compilação? Não entendi!

Eu vi essa entrevista, realmente muito boa.

O melhor é que podemos ler a entrevista. =D

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.

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!).

Nada a contra a discussão, mas vcs passaram longe da minha pergunta acredito eu.

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.

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.

Cara, foi mal.

Eu meio que puxei a discussão para esse lado. Na verdade eu tava querendo puxar uma posição sua a respeito. :lol:

Reparei que você tem falado muito (e muito bem) disso ultimamente.

Mas não foi tão longe assim, foi? =D

Sim. Mas o que estou questionando é a necessidade de você conhecer guj.com.br.

Entendi o ponto do celso.martins, ele queria um serviço do tipo:

“Me dê informações sobre Java”

ao invez de

GET www.guj.com.br

Nada impede de criar um serviço “wrapper” de outros serviços, mas já tem algumas ferramentras de fazem essa abstração.

Rubem Azenha:

Entendi o ponto do celso.martins, ele queria um serviço do tipo:

“Me dê informações sobre Java”

ao invez de

GET www.guj.com.br

Nada impede de criar um serviço “wrapper” de outros serviços, mas já tem algumas ferramentras de fazem essa abstração.

GET www.guj.com.br

é o mesmo que:

“Me dê informações sobre o maior fórum sobre Java do Brasil”

mochuara:

GET www.guj.com.br

é o mesmo que:

“Me dê informações sobre o maior fórum sobre Java do Brasil”

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

Rubem Azenha:

mochuara:

GET www.guj.com.br

é o mesmo que:

“Me dê informações sobre o maior fórum sobre Java do Brasil”

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

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

saoj:

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 :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.

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.

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

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

@saoj
Sobre autenticação, você pode optar por HTTP Authentication - http://www.ietf.org/rfc/rfc2617.txt

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.

@saoj
Sobre autenticação, você pode optar por HTTP Authentication - http://www.ietf.org/rfc/rfc2617.txt

Só pra acrescentar vc pode usar autenticação HTTP tanto em REST como em SOAP+WSDL.

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

REST não é uma arquitetura baseada em serviços, portanto REST e SOA nada tem a ver.

REST não é baseado no protocolo HTTP.

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.

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.

REST é TOTALMENTE baseado no protocolo HTTP!

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.

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.

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.

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.

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.

Rubem Azenha:

mochuara:

REST não é uma arquitetura baseada em serviços, portanto REST e SOA nada tem a ver.

REST não é baseado no protocolo HTTP.

REST é TOTALMENTE baseado no protocolo HTTP!

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.

Fonte: http://java.sun.com/developer/technicalArticles/WebServices/restful/

Mas eu entendi oq vc quis dizer: os dois utilizam-se das mesmas palavras. O seu único erro foi vincular fortemente um ao outro.

clone_zealot:

Fonte: http://java.sun.com/developer/technicalArticles/WebServices/restful/

Mas eu entendi oq vc quis dizer: os dois utilizam-se das mesmas palavras. O seu único erro foi vincular fortemente um ao outro.

O que tem de tão complicado em entender que REST é uma arquitetura e o S não é de serviço?

Entendido isso fica fácil perceber o engano; implementações são baseadas em padrões arquiteturais, não o contrário.

mochuara:

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

REST não é uma arquitetura baseada em serviços, portanto REST e SOA nada tem a ver.

REST não é baseado no protocolo HTTP.

Quanto a REST e SOA, acho que você confundiu um pouco, pois SOA não diz nada sobre como os serviços devem ser implementados e já existe inclusive ESBs que suportam REST e nem sequer precisamos de ESB para termos SOA.

Falar que REST não é uma arquitetura baseada em HTTP que é besteira! você já viu alguma vez REST não ser construído sem ser baseado em HTTP? Agora vamos abrir sockets e começar a trafegar dados usando REST?

Você pode digitar REST no google e não vai uma única fonte que não vai falar de REST com HTTP.

Eu entendi o que você quiz dizer, mas acho que você esta entendendo errado… SOA é para uma coisa, REST é para outra, mas você pode usar REST para implementar SOA.

mochuara:

Novamente, se informe sobre o assunto ou então cite suas fontes para que possamos discutir.

http://www.google.com/search?&q=SOA%2BREST

clone_zealot:

Fonte: http://java.sun.com/developer/technicalArticles/WebServices/restful/

Mas eu entendi oq vc quis dizer: os dois utilizam-se das mesmas palavras. O seu único erro foi vincular fortemente um ao outro.

Realmente não esta acoplado ao HTTP, mas na prática, existe alguma forma de praticar REST sem ser com HTTP?

mochuara:

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.

Isso se chama depender de interfaces, não de implementação. Das coisas mais básicas na computação.

Sim, mas no ESB vc tem muito mais suporte que somente isso, vc pode implementar lógica nessa camada.

Exato, o discurso de SOA está muito mais ligado preocupado com o negócio do que com a tecnologia.

Também estou curioso pra ver.

Ficou notório que preciso ler muito mais sobre o assunto.

Na MJ deste mês tem um artigo sobre REST que já li superficialmente (sem me deter nas dúvidas). Porém, me lembro bem (e acabei de ler na Wikipedia) esse termo foi cunhado pelo criador da especificação HTTP, Roy Fielding, em sua tese de doutorado.

Não sei ainda se somente isso seria necessário para um acoplamento REST-HTTP. Entretanto, me parece que os verbos utilizados (GET, PUT, DELETE, etc) são da especificação HTTP, não?

Como costumo dizer, não estou querendo gerar flame. Estou querendo entender mesmo.

Segue mais uma referência (que ainda não li), essa do pai da criança: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Bom, só pra falarmos um pouco mais de estilo de arquitetura - WOA - http://www.infoq.com/news/2009/06/hinchcliffe-REST-WOA e se pegarem os slides do gartner, o qual criou o acrônimo, verá que é um estilo derivado do SOA. Na prática é SOA, apenas mudaram o acrônimo para representar um estilo definido e vender isso ao mercado.

Também facilita a linguagem entre os desenvolvedores, que é um dos papéis do Pattern

PS: O tópico ficou doido de vez !!

Kenobi:

Bom, só pra falarmos um pouco mais de estilo de arquitetura - WOA - http://www.infoq.com/news/2009/06/hinchcliffe-REST-WOA e se pegarem os slides do gartner, o qual criou o acrônimo, verá que é um estilo derivado do SOA. Na prática é SOA, apenas mudaram o acrônimo para representar um estilo definido e vender isso ao mercado.

Também facilita a linguagem entre os desenvolvedores, que é um dos papéis do Pattern

Então tá, vamos partir do princípio. De uma forma bem genérica e abstrata, o WOA seria o SOA que usa a WEB como middleware? Ou não? Pois é isso que está sedimentado no meu crânio. Se eu estiver com um conceito errado sedimentado, vai ser um problema entender o resto.

Verdade.
E eu to endoidando junto.

WOA seria o padrão convencionado de utilizar estilo Restful, mais hypermedia entre outros elementos como ATOM, para mensageria…seria um SOA light !!

Blz. Vlw a resposta.

E quem faz o meio de campo?

Eu entendi que o Webber, na primeira palestra no Falando em Java 2009, criticou os ESBs, principalmente pela escalabilidade e o “macarrão” encapsulado, usando justamente esse argumento para defender a WEB como grande middleware. Entendi direito?

Blz. Vlw a resposta.

E quem faz o meio de campo?

Eu entendi que o Webber, na primeira palestra no Falando em Java 2009, criticou os ESBs, principalmente pela escalabilidade e o "macarrão" encapsulado, usando justamente esse argumento para defender a WEB como grande middleware. Entendi direito?

Entendeu exatamente certo e o meio de campo é feito por URIs, links através de hypermedia. Agora, como fica governança para o caso de desenvolvimento entre departamentos, falta de contratos e por aí vai , são questões que eu também levantei nesse tópico > http://www.guj.com.br/posts/list/30/127676.java

Bem, vamos fazer uma pausa para o café, e definirmos ALGUNS pontos que nós podemos concluir até agora:

• Temos SOA, que pode ser implementada com WS, ou não;
• Temos WS, que pode ser implementado como SOAP, ou REST(tecnologias que dominam o mercado. Alguém pode ter outra, mas desconheço)
• Temos o HTTP, que é um protocolo de comunicação;
• Um dos protocolos de comunicação mais usados na WEB é o HTTP;

Após isto, podemos ver que faz bastante sentido fundirmos REST com HTTP, mas, analisando bem, os dois são duas tecnologias que podem viver isoladas.

@celso.martins: e REST não usa como verbos o GET, PUT, POST etc.
Como está no artigo do Sun Developer Network, que a pouco passei: "REST is an analytical description of the existing web architecture, and thus the interplay between the style and the underlying HTTP protocol appears seamless."
Os dois PARECEM ser indisolúveis, mas não necessariamente o são.

E sempre é bom vermos discussões interessantes =)

SOA light parece que é mais fraco ou tem limitações em relação ao SOA “original”. Pode explicar melhor?