=EN-US style="FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Verdana">

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.

Analisando estes dois históricos, poderíamos talvez classificar o surgimento do WS-* como resultado de um processo de desenvolvimento “waterfall”, no qual muito foi planejado e decidido antes de começarem as implementações. Com os problemas e desafios enfrentados ao aplicar estas idéias em situações reais, algumas especificações como SOAP e WSDL precisaram ser revistas várias vezes para transformar as especificações complexas em serviços úteis, o que causou re-trabalho e o emprego de um esforço considerável.

Por outro lado, o desenvolvimento dos serviços REST seguiu uma linha muito mais incremental, evolutiva. Um conjunto pequeno de regras de fácil compreensão foi usado como ponto de partida, e então com a evolução do entendimento do problema, a comunidade de pesquisadores e usuários da tecnologia pôde identificar algumas questões de difícil decisão na arquitetura. Estas questões foram tendo soluções propostas e documentadas à medida que se acumulavam os casos de sucesso na sua adoção.

Alguns conceitos de web services e especificamente alguns detalhes das abordagens WS-* e REST para resolver alguns problemas são um tanto complicadas de se entender sem um exemplo real para mapear as idéias. Nas próximas seções, descreverei a arquitetura dos dois estilos de tecnologia SOA, e ao longo do processo usarei alguns exemplos de serviços fictícios do Submarino, envolvendo operações sobre produtos.

Arquitetura das tecnologias SOA WS-*

Após uma boa contextualização sobre a motivação para criação dos web services e um pequeno histórico do surgimento dos dois estilos de arquitetura, precisamos detalhar bem mais as características de cada um para podermos compará-los.

Uma visão geral de como ocorre a comunicação nos web services que utilizam SOAP pode ser vista na Figura 1.

 

Figura 1. Fluxo de comunicação dos web services WS-*

Neste fluxo, a primeira etapa é descobrir onde o serviço com o qual deseja-se comunicar está publicado. Esta descoberta pode ser feita a partir de alguma documentação do serviço ou através de uma consulta a um repositório UDDI.

UDDI, que significa Universal Description, Discovery and Integration, é um registro baseado em XML e independente de plataforma que possibilita que companhias publiquem seus serviços disponíveis. O UDDI permite consultar como serviços ou aplicações interagem, e foi desenhado para ser acessado através de mensagens SOAP e fornecer os documentos WSDL referentes aos serviços em questão.

Tendo descoberto o local de publicação do serviço que nos interessa, conseguimos obter um documento WSDL (Web Services Description Language).

O WSDL é um artefato muito importante dos web services WS-*, pois ele especifica de forma precisa as operações que estão expostas nos serviços, mapeando de forma tão precisa quanto se deseje os formatos de documentos de entrada e de saída das operações. É bom enfatizar este termo utilizado, pois uma das principais características dos web services é a troca de documentos XML.

Não interessa se por trás da implementação do serviço está um servidor de aplicações Java serializando objetos ou se está uma aplicação PHP gerando documentos XML com seus recursos de processamento de texto ou até mesmo uma interface para algum sistema legado de tecnologia arcaica. As regras que definem a comunicação especificam os documentos XML que precisam ser trocados, e isto permite que um amplo conjunto de plataformas e aplicações estabeleçam conversações entre si.

Esta não foi a primeira tentativa de se padronizar comunicações remotas entre diferentes plataformas. CORBA, RPC e COM foram outras iniciativas neste sentido, mas não tiveram muito sucesso. A grande motivação para o sucesso atual dos web services é que houve um amplo consenso em torno da adoção de documentos XML como padrão de comunicação, e então todas as iniciativas neste caminho ganharam muita força.

Voltando ao WSDL, ele é muito importante por definir, de uma forma aceita universalmente, como será a interação de clientes com os serviços que estamos oferecendo. Ao especificar no WSDL quais são os schemas XML dos documentos que serão trocados e a cardinalidade precisa de cada elemento, conseguimos garantir que qualquer cliente que entenda o padrão estabelecido será capaz de interpretar os documentos e comunicar-se corretamente com nossos serviços. Além disto, a maturidade deste padrão traz a vantagem de que já existem geradores de clientes em várias linguagens a partir de um documento WSDL.

Durante muito tempo esta foi e ainda é uma das vantagens dos web services WS-* sobre os RESTful. Embora já exista a versão 2.0 da especificação WSDL que permite descrever também os web services REST, isto ainda está sendo muito pouco adotado. De uma maneira geral, não existe um padrão sobre como descrever o protocolo de comunicação a ser utilizado para conversação com web services REST.

...

Quer ler esse conteúdo completo? Tenha acesso completo