O que ocorre é que existe uma quantidade imensa de especificações WS-* que nem foram implementadas ainda. Existem vários problemas relacionados a questões relativamente simples em um sistema *local*, como por exemplo transação.
Outro problema é a complexidade. É muito complexo e pouco produtivo trabalhar com Web Services. Ahh beleza vai vir um engraçadinho dizendo: "Ahh mas tudo pode usar Xfire ou até mesmo o AXIS", eu digo: "ok". Mas o que acontece na outra ponta? E a sua outra aplicação em C++ ou Smalltalk como fica?
Mesmo com Xfire ainda assim existe muita complexidade por traís das especificações WS-*, sem falar em um outro problema o XML, e o custo de se fazer o parser prá lá e prá cá.
NOTA: Isso ainda é um problema. Por que ferramentas novas por exemplo como o BPEL da ORACLE até a versão 10.1.0.3 tinha seu parser em XML com DOM. Isso ai dom4j.jar!
Soluções com WS são uteis para integração de sistemas, principalmente com tecnologias diferentes como Java e .NET ou C++. Des de 18/10/2006 o pessoal do Open Group iniciou seus trabalhos com SOA. Então nesses últimos anos a filosofia SOA vem ganhando destaque, de fato SOA é algo muito bom.
Uma das formas de se implementar os princípios da filosofia SOA é através de Web Services. Ai novamente o uso de Web Services ganhou mais destaque.
Muito esforço e complexidade com WS
Bom pra começar como vocês já sabem mensagens enviadas e recebidas são em formato XML. Dentro dessas mensagens existem métodos que serão executados, esses métodos podem possuir parâmetros( tanto de entrada, como de saída) e serão empacotados no protocolo SOAP. Adivinhem sobre SOAP? Isso ele é baseado em XML! Tudo isso é descrito com uma especificação WS para descrição que é a WSDL. Quem conhece sabe que a WSDL é asquerosa e nojenta.
Legal, depois disso ainda falta publicar o serviço para isso é utilizado o protocolo UDDI. Esse protocolo não é utilizando apenas para publicação, é utilizado também para pesquisa de serviços. Lembrando que tudo isso roda sobre o protocolo de transporte que nesse caso é o HTTP.
Se você tem dúvidas quanto a complexidade, implemente alguns e depois pense novamente de maneira mais pragmática.
REST é o futuro
Ele foi criado em 2000 através de uma tese de doutorado do Roy Fielding. Que por sinal é um dos criadores do protocolo http. Não bastasse o cara criou o REST. Mas a final o que é REST?
REST é um modelo de design Arquitetural que baseada em transição de estados e hoje em dia é conhecido por utilizar: HTML + XML( ou Json) + utilizam mais os metodos da especificação http. Quando eu digo usar mais os metodos eu digo em usar: DELETE, PUT, etc... Não apénas POST e GET como o dé abitual.
Essas aplicações que utilizam REST são chamads de RESTFull. Em 2007 eu tinha sugerido um framework java para rest. Hoje possuimos outros como o Jersey que é a implementação padrão da JSR311. Também existem outros projetos que estão quase em produção como o Apache ABdera.
Ná prática você pode usufluir dos principios REST em uma aplicação JEE com apénas um Servlet e uma infra em java, conforme apáreceu ante-penultiuma edição da revista Mundo Java.
A tecnologia já vem sendo utilizado com muito sucesso em empresas como: eBay e a Amazon.
NOTA: Diferentemente dos Web Services REST é um estilo arquitetural não um padrão. É bem possivel que ele vire um padrão, em Java já a JSR311, mas em ternos de W3C ainda não. Por equanto só se viu workshops.
Quais são as caracteristicas de um WS-REST ?
- Modelo Cliente-Servidor
- Ciclo de vida Stateless
- Uso de Cache
- Interface unificada( http, PUT, GET, TRACE, etc...)
- Recursos nomeados com URL
- Camadas de Componentes (Firewalls, Gateways)
A Figura a cima é auto explicativa. Mas basicamente ganhamos com Agilidade, Robustes e conectividade. Outro item que ganhamos e não está ai e a questão da Aderesabilidade que é o fato de endereçarmos recursos e operações a métodos + URLS.
5 Motivos para você usar REST
- Agilidade e Simplicidade
- Uso correto do protocolo HTTP (EX: uso de GET)
- Produtividade e Clareza
- Já existe uma JSR (JSR311)
- Manutenção (muito mais simples de modificar o sistema)
2 comments:
Diego, seus textos estão melhorando muito, parabéns, apenas corrija o termo "Filosofia SOA", SOA nao é filosofia, é Arquitetura.
Obrigado.
Post a Comment