Clique aqui para ler esse artigo em PDF.
REST vs WS-*
Uma visão pragmática
Analisando as duas formas de implementação de web services para decidir onde a aplicação de cada uma é mais adequada
Já há alguns anos o assunto das arquiteturas orientadas a serviços (service oriented architectures – SOA) está em evidência. A necessidade de se construir aplicações distribuídas, porém, facilmente interoperáveis e fracamente acopladas existe há um bom tempo, e tem sido progressivamente satisfeita por uma série de tecnologias, da RPC e orientação a objetos aos web services. A arquitetura SOA é o último passo nesta evolução, e se caracteriza por não ser uma nova linguagem, middleware, protocolo ou formato de dados. Pelo contrário, é um paradigma que coloca a tecnologia em segundo plano e toma como eixo central os processos de negócio, que serão satisfeitos por serviços implementados por componentes de software discretos (aplicações). Este foco no negócio implica que não existe uma tecnologia exclusiva para implementar aplicações SOA; se uma tecnologia única fosse imposta, por melhor que fosse, não teríamos um SOA completo, pois haveria restrições de interoperabilidade com aplicações que, por qualquer motivo, não pudessem se adaptar à nova tecnologia.
Mas o objetivo deste artigo não é oferecer mais um ponto de vista filosófico sobre o tema. Justamente por ser este estilo de arquitetura bastante abstrato, surgem questões práticas de implementação. Dissemos que o SOA não é uma tecnologia específica, mas certamente precisamos de alguma tecnologia concreta para implementar aplicações com arquitetura orientada a serviços.
No sentido de implementar este modelo, surgiram duas linhagens de tecnologia fundamentalmente distintas. A primeira delas foi o que chamamos de WS-*, pronunciado “WS asterisco”. Ou segundo as más línguas, “WS death star”, o que representa o enorme conjunto de especificações de web services já publicadas. A segunda forma de implementação de web services baseia-se no REpresentational State Transfer (REST), que defende a exploração dos recursos do HTTP de forma extensa.
O foco deste artigo será analisar de forma imparcial as duas tecnologias e então tentar ilustrar os pontos positivos e negativos de cada uma, dando uma visão pragmática do momento atual em que estamos com relação a SOA.
Surgimento das arquiteturas
No final da década de 1990, aplicações distribuídas começaram a ser desenvolvidas com HTTP e XML. Entretanto, isto era feito de forma customizada em todos os casos, com definição de protocolos próprios que variavam de uma implementação para outra e de uma empresa para a outra. Em cada protocolo diferente mudava também a abordagem de segurança, robustez, transações, entre outras coisas.Isto abriu uma oportunidade para os fabricantes de middleware que desejavam vender seus produtos e serviços na área. Mas eles precisavam de algo mais controlado para basear sua estratégia tecnológica.
Com o objetivo de padronizar estas implementações e facilitar a interoperabilidade entre sistemas e empresas, foi iniciada a linha de arquitetura do WS-*. A razão da nomenclatura WS-* fica bastante clara quando se pesquisa pelas especificações de web services definidas pelos grupos de estudos formados na área e depara-se com a voracidade dos grupos em criar documentos e mais documentos padronizando coisas que não estavam nem começando a ser implementadas.
O surgimento das especificações WS-* pode ser comparado com o do modelo OSI de 7 camadas. O modelo OSI é uma ótima abstração e referência para um entendimento de como as redes de computadores funcionam, mas ele foi definido teoricamente antes que houvesse implementações práticas o acompanhando. Quando as implementações do OSI chegaram, eram grandes, lentas e frágeis, e acabaram sendo varridas do mercado quando um concorrente mais simples e pragmático – o TCP/IP – se mostrou mais simples, eficiente e robusto. O OSI acabou valendo apenas como um ponto de partida histórico, e até hoje, como um modelo formal muito completo a partir do qual podem ser derivadas diversas tecnologias de rede.
De forma similar ao OSI, as especificações WS-* andaram muito mais rapidamente do que aplicações baseadas nelas. Os comitês formados por várias empresas geraram uma massa extensa de documentos que em boa parte não foram validados por uso extenso em aplicações reais. Por um lado, o WS-* oferece soluções para praticamente todos os problemas imagináveis em arquiteturas SOA, inclusive recursos sofisticados para transações e segurança. Por outro lado, quantas aplicações você conhece que realmente já utilizaram estas especificações avançadas? A esmagadora maioria das aplicações da família WS-* só usa os seus recursos mais básicos, como SOAP e WSDL.
Um caminho bastante diferente pôde ser observado no início dos RESTFul web services. Roy Fielding é um dos principais autores do protocolo HTTP, e ele propôs em sua tese de doutorado um modelo de tecnologia que faz extenso uso dos recursos oferecidos por este protocolo, que nos serviços padrão WS-* são muito pouco explorados (inclusive porque o SOAP é independente de transporte; não precisa necessariamente trafegar sobre HTTP, ainda que este seja o caso mais comum).
O desenvolvimento da abordagem REST de serviços foi bastante semelhante ao que ocorreu com a arquitetura TCP/IP. No surgimento do TCP/IP, as implementações práticas foram surgindo e sendo refinadas, e à medida que as tecnologias foram sendo adotadas com sucesso, se transformaram em especificações do grupo Internet Engineering Task Force (IETF) para garantir a interoperabilidade entre implementações. Com a abordagem REST, inicialmente havia apenas um conjunto de regras que ditavam como seriam os serviços que seguissem esta linha de pensamento. Não havia inicialmente especificação para muita coisa, havia apenas a tese defendida por Roy Fielding e então começaram a surgir aplicações desenvolvidas com esta abordagem para resolver problemas reais.
À medida que a adoção de serviços REST foi aumentando, foram surgindo alguns padrões de implementação, que indicavam como abordar alguns pontos que ficaram abstratos na tese original. Com os primeiros casos de sucesso vieram os esforços de especificação mais precisa e padronização, para permitir o re-uso de idéias nos traços comuns de todos os serviços e permitir que um nível de abstração superior fosse alcançado. Este progresso levou à formação de grupos de estudo do IETF que estão atuando na padronização dos serviços REST.
" [...] continue lendo...
