Web services WS-* versus Web Services REST

Tharcis Dal Moro, Carina Friedrich Dorneles, Marcelo Trindade Rebonatto

Instituto de Cincias Exatas e Geocincias Universidade de Passo Fundo (UPF)

Passo Fundo RS Brasil

{68973,dorneles,rebonatto}@upf.br
Abstract. This paper presents a study about Web services using the WS-*
architecture and the ROA architecture (RESTful), as well as a detail of the
main technologies involved. This paper also presents a case study developed
on Java platform for the purpose of demonstrate the functionality and main
differences in working with Web services using the two methodologies
mentioned.
Resumo. Este artigo apresenta um estudo sobre Web services utilizando a
arquitetura WS-* e a arquitetura ROA (RESTful), bem como um detalhamento
das principais tecnologias envolvidas. Este artigo tambm apresenta um
estudo de caso desenvolvido na plataforma Java a fim de demonstrar o
funcionamento e principais diferenas em se trabalhar com Web services que
utilizam das duas metodologias citadas.

1. Introduo
Com o passar do tempo, o mundo da tecnologia sofre grandes mudanas. Junto a essas
mudanas, surgem tambm novas necessidades. A necessidade da integrao entre
aplicaes, a utilizao unificada de processos encontrados em diferentes sistemas e
escritos em diferentes linguagens so alguns exemplos. A fim de sanar estas questes, a
tecnologia dos Web services foi criada. Permitindo assim, disponibilizar formas de
integrar sistemas distintos, modularizar servios e capacitar a integrao e consumo de
informaes [Menndez 2002].
Este artigo apresenta um estudo sobre Web services utilizando a arquitetura
WS-* e Web services que seguem o estilo de arquitetura REST (ROA), bem como um
estudo de caso para demonstrar as duas abordagens e servir de instrumento no processo
de comparao entre ambas. A principal contribuio do estudo realizado
proporcionar um embasamento macro da tecnologia e destacar as principais
caractersticas das arquiteturas em questo.
O artigo est dividido como segue. Seo 2 apresenta alguns trabalhos
relacionados a este artigo. Seo 3 dispe de uma explanao sobre o conjunto de
padres contidos na WWW, bem como um enfoque no protocolo de transporte HTTP o
qual amplamente utilizado junto aos servios. Seo 4 introduz a tecnologia de Web
Services para assim, detalhar nas Sees 5 e 6 os Web services WS-* e REST
respectivamente. Seo 7 apresenta um estudo de caso de servios utilizando a
plataforma Java, seguido de uma anlise comparativa na Seo 8 e das concluses na
Seo 9.
2. Trabalhos relacionados
Alguns artigos foram elaborados com a finalidade de demonstrar os principais aspectos
que constituem os Web services REST e WS-* de uma maneira isolada. Dentre eles
esto os trabalhos de [Tilkov 2007] no qual explanou os conceitos e princpios do estilo
de arquitetura REST; [Silva 2008b] explorou os Web services WS-* por meio de uma
abordagem prtica; e [Cunha 2002] o qual realizou estudos sobre aplicaes Web
utilizando SOAP. Outros realizaram trabalhos comparando caractersticas entre os Web
services REST e WS-* em diferentes reas; como os artigos de [Chinthaka 2007] que
focou na utilizao da WSDL 2.0 nas duas abordagens; [Newmarch 2004] enfatizou o
uso de ambas as abordagens na arquitetura UPnP, destacando vantagens e desvantagens;
e o artigo de [Shi 2006] sobre Web services Semnticos utilizando servios RESTful e
WS-*. Nenhum trabalho utilizando de um caso de uso para comparar caractersticas
entre Web services RESTful e WS-* foi encontrado na literatura pesquisada.

3. World-Wide Web
A World-Wide Web, conhecida tambm como WWW, ou simplesmente Web um
espao de informao em que os objetos de interesse, chamados de recursos, so
identificados por chaves globais chamadas de Uniform Resource Identifiers (URI)
[W3C 2004b]. A iniciativa que tornou possvel a Web ser o que hoje foi tomada por
Tim Berners-Lee em 1980 na Sua. Seu intento original era tornar mais fcil o
compartilhamento de documentos de pesquisas entre seus colegas. Ainda que diferente
da Web atual, o projeto continha algumas das mesmas idias primordiais. Utilizando
como base os padres URI, HTML e HTTP.
Segundo [Berners-Lee, 2005], o sistema de identificao URI disponibiliza uma
forma simples e extensvel de identificar recursos; como: pginas Web, imagens, vdeos
e servios. Existem diversos benefcios acarretados pelo Uniform Resource Identifiers,
incluindo a hiperligao (hiperlink), bookmarking, cache e indexao de motores de
busca como o Google.
O formato HTML foi o primeiro formato de dados usado na Web. Desde ento,
vrios formatos surgiram para a representao de recursos. Como a arquitetura WWW
no dita nenhuma restrio quanto ao formato a ser utilizado, XHTML, CSS, PNG,
XML dentre outros, ganharam espao. A maioria dos protocolos de recuperao e envio
de representaes faz uso de uma seqncia de uma ou mais mensagens, que juntas
contm os dados e metadados de uma representao a ser transferida entre agentes
(navegador/servidor).
O protocolo HTTP, por exemplo, limita os tipos de formatos das representaes
de dados e metadados que podem ser transmitidos. Para que seja transferida uma
representao no formato XHTML, o cabealho HTTP ter que ser configurado para tal
indicando que a representao pode ser processada de acordo com a especificao
XHTML.

Protocolo HTTP
Atualmente, O TCP/IP a base de todas as comunicaes na internet. Ele oferece
controle de roteamento de informaes em uma rede, e uma maneira dos computadores
se conectarem [Potss 2003]. Conforme o modelo OSI, ilustrado na Figura 1, o TCP e o
protocolo IP se localizam nas camadas de transporte e de rede respectivamente. Sendo
que o HTTP e os demais protocolos possveis de utilizao na comunicao de Web
services ficam na camada de aplicao.

Fonte: Potss, 2003, p.92

Figura 1. Modelo OSI de Comunicaes

Segundo [Fielding et al. 1999] o protocolo HTTP (Hypertext Transfer

Protocol), um protocolo voltado a sistemas distribudos, colaborativos e hipermdia.
Este protocolo est em uso pela World-Wide Web desde sua primeira verso
(HTTP/0.9), lanada em 1990. Na poca, era utilizado para transferir dados brutos
atravs da Internet. Atualmente est na verso HTTP/1.1, muito mais aperfeioada
comparada a sua primeira verso.
O HTTP tem como base de comunicao a troca de mensagens
(requisies/respostas), ou seja, um cliente envia uma requisio ao servidor, utilizando
um mtodo HTTP, uma URI, verso do protocolo, seguida de metadados e podendo
possuir um corpo. O servidor responde a solicitao contendo um cdigo de status,
podendo ou no apresentar um corpo [Fielding 2000]. Toda a comunicao entre o
cliente e o servidor feita na seqncia do handshake de comunicao HTTP.

4. Web Services
Um Web Service um sistema de software desenvolvido para suportar
interoperabilidade entre mquinas sobre uma rede, o qual pode apresentar uma interface
que o descreve (WSDL, WADL). Outros sistemas interagem com os Web services por
meio de mensagens SOAP, geralmente usando HTTP com serializao XML em
conjunto com outros padres relacionados a Web [W3C 2004a].
Com esta tecnologia, torna-se possvel que aplicaes diferentes interajam entre si e
sistemas desenvolvidos em plataformas diferentes se tornem compatveis. Os Web
services so componentes que permitem que aplicaes enviem e recebam dados em
formatos variados. Cada aplicao pode ter a sua prpria "linguagem", que traduzida
para uma linguagem universal, como o caso do formato XML.
Uma caracterstica fundamental dos Web services diz respeito a possibilidade de
utilizao de diferentes formas de transmisso de dados pela rede. Logo, a arquitetura
de Web services pode trabalhar com protocolos, tais como HTTP, SMTP, FTP,
RMI/IIOP ou protocolos de mensagem proprietrios [W3C 2004a].
 Segundo [Potss 2003], as primeiras verses das especificaes de Web services
ofereciam apenas o HTTP como meio de transporte de dados (mensagens SOAP XML)
e comunicao entre clientes e servios, sendo ainda o mais utilizado atualmente.

5. Web Services WS-*

No final da dcada de 90, milhares de pessoas estavam desenvolvendo sistemas de e-
commerce baseados em HTTP e XML. Cada qual com sua prpria maneira de
implementar segurana, confiabilidade, gerenciamento de transaes. Com isso, um
caos comeou a ser formado: incompatibilidades entre sistemas, dificuldade na
manuteno e em contrapartida, a necessidade de se criar uma maneira comum de
realizar estas tarefas. Estes fatos impulsionaram o surgimento dos padres WS-*. Hoje
mantidos pela W3C e OASIS [Weerawarana, et al. 2007].
Atualmente, a arquitetura WS-* composta por mais de 20 especificaes. Sendo as
especificaes base deste conjunto a SOAP, WSDL e UDDI. Alm dos citados, existem
tambm os padres WS-Notification, WS-Addressing, WS-Transfer, WS-Policy, WS-
Security, WS-Trust, WS-ReliableMessaging, WS-Transfer, WS-I Basic Profile, WS-
Transaction entre outros. Uma das principais reclamaes em relao a esse formato diz
respeito a esse grande nmero de especificaes que o torna complexo e burocrtico,
difcil de ser dominado por uma s pessoa.
Nos padres WS-*, as mensagens trocadas entre servio e cliente consumidor
devem ser armazenadas em envelopes SOAP. Este protocolo de comunicao dita um
formato de envio de mensagens entre aplicaes [W3C 2000].
Para descrever e localizar Web services utilizada a linguagem WSDL considerada
um vocabulrio XML. Permite que desenvolvedores de servios disponibilizem
informaes importantes para a utilizao dos mesmos. Segundo [Weerawarana, et al.
2007] altamente adaptvel e extensvel, o que permite a descrio de servios que se
comunicam por diferentes meios, tais como SOAP, RMI/IIOP.
Description, Discovery, and Integration (UDDI) um protocolo que disponibiliza
mtodos padres para publicao e localizao de informaes sobre Web services,
funcionando como um repositrio de metadados com informaes teis para a utilizao
de servios [Oasis 2004].

6. Web Services REST

Na era da Web 2.0 a integrao entre aplicaes se faz um requisito bsico. cada vez
mais freqente o aparecimento de aplicaes Mashups, aplicaes estas que usam
contedo de mais de uma fonte para criar um novo servio completo (Web feeds). Esse
tipo de sistema em parte proveniente da Service Oriented Architecture (SOA), estilo
de arquitetura orientado a servios, na qual possui aspectos fortes de reutilizao de
cdigo e desacoplamento.
Pensando neste contexto, os sistemas devem ser capazes de disponibilizar
diferentes formatos de dados para uma mesma fonte. Para uma aplicao Web o
conveniente seria retornar HTML ou ainda JavaScript Object Notation (JSON),
diferentemente de uma aplicao desktop onde o mais indicado seria o retorno de um
formato XML.
 Logo, enfrenta-se a necessidade de disponibilizar servios de maneira fcil e em
diferentes formatos adequados para integrao (HTML, XML, JSON, TEXT PLAIN).
Caractersticas estas que podem ser atendidas por sistemas desenvolvidos utilizando o
estilo de arquitetura REST, formalizado por Roy Fielding [Dias e Machado 2007].

Definio de REST
REST (Representational State Transfer) um termo que foi utilizado pela primeira vez
por Roy Fielding (um dos criadores do protocolo HTTP), em sua tese de doutorado
publicada no ano 2000. Este estilo de arquitetura de software para sistemas distribudos
(como a World Wide Web) no se torna aplicvel somente no desenvolvimento de Web
services.
O termo geralmente usado para descrever qualquer interface que transmita dados
de um domnio especfico sobre HTTP sem uma camada adicional de mensagem como
SOAP ou session tracking via cookies HTTP. Estes dois significados podem entrar tanto
em conflito como em sobreposio. possvel desenvolver um sistema de software de
acordo com as restries impostas pelo estilo arquitetural REST sem usar HTTP e sem
interagir com a Web. Tambm se torna possvel projetar interfaces HTTP + XML que
no condizem com os princpios REST de Fielding [Fielding 2000]. Sistemas que
seguem os princpios REST so referenciados tambm como RESTful.

Princpios do estilo REST

Segundo [Fielding 2000], para que os princpios deste estilo sejam respeitados, um
conjunto de restries deve ser seguido, os quais so abordados em detalhes:
Cliente-Servidor
Esta caracterstica mais comumente encontrada em aplicaes Web. Um servidor, com
um conjunto de servios disponveis, escuta requisies a estes servios. Um cliente,
que deseja que um servio disponvel no servidor seja executado, envia uma requisio
para o servidor. O servidor ento pode tanto rejeitar como executar o servio solicitado,
e retornar uma resposta ao cliente.
Esta diviso de preocupaes um item que prevalece no estilo cliente-servidor.
Separando a estrutura do usurio/cliente da estrutura do servidor (dados e servios),
possvel melhorar a portabilidade do cliente atravs de mltiplas plataformas e tambm
melhorar a escalabilidade, simplificando o componente servidor. Talvez o mais
interessante para a Web seja a conseqncia que esta separao prov. A qual permite
aos componentes evoluir independentemente, suportando o requisito de escalabilidade
da Internet.
Stateless (Sem estado)
Outra restrio imposta pelo estilo REST diz respeito interao entre cliente e
servidor. A comunicao deve ser feita sem o armazenamento de qualquer tipo de
estado no servidor, ou seja, cada requisio do cliente para o servidor deve conter todas
as informaes necessrias para que ela seja entendida. Portanto, estados de sesso,
quando necessrios, devem ser totalmente mantidos no cliente.
Este item influencia positivamente na visibilidade, fiabilidade e escalabilidade. A
visibilidade otimizada, pois um sistema de monitoramento no precisa olhar atravs de
uma dada requisio para determinar sua natureza. A fiabilidade aumentada, pois a
tarefa de recuperao a falhas parciais se torna fcil. A escalabilidade tambm
melhorada, porque no tendo que se preocupar com o armazenamento de estados entre
as requisies, o servidor pode rapidamente liberar recursos facilitando seu
gerenciamento.
Como a maioria das opes arquiteturais, esta caracterstica possui desvantagens. A
reduo de performance na rede uma delas, pois este mtodo aumenta os dados
repetidos enviados nas requisies. Agregado a isso, o controle do servidor sobre o
comportamento consistente da aplicao reduzido j que todo o estado da aplicao
fica no lado cliente.
Cache
Uma forma de diminuir o impacto da desvantagem trazida pela reduo de desempenho
a utilizao de cache. O mesmo exige que os dados de uma resposta, vindos de uma
requisio ao servidor, sejam marcados como cacheable ou noncacheable (passveis ou
no de utilizao da cache). Se uma resposta setada como cacheable, ento ela ser
reutilizada como resposta para as futuras requisies equivalentes. Com a utilizao de
cache torna-se possvel diminuir ou at mesmo eliminar completamente algumas
interaes com o servidor, otimizando eficincia, escalabilidade e performance para o
usurio.
Interface Uniforme
A caracterstica central que diferencia o estilo arquitetural REST de outros estilos
baseados em rede sua nfase em uma interface uniforme entre os componentes
(cliente, servidor). Com o objetivo de obter uma interface uniforme, REST define
quatro requisitos de interface: Identificao de recursos; manipulao de recursos
atravs de representaes; mensagens auto-descritivas e hipermdia como mecanismo de
estado da aplicao. A Figura 2 ilustra as interfaces em ambas as abordagens (servios
RESTful e WS-*).

Fonte: Snell, 2004.

Figura 2. Abordagem orientada a recursos (ROA) e abordagem orientada a
servios (SOA)

Atualmente, o HTTP o protocolo chave, sendo o mais indicado para trabalhar

com Web services REST. O mesmo prov uma interface uniforme com quatro mtodos
bsicos para as quatro operaes mais comuns. GET para recuperar uma representao
de um recurso, PUT para criar um novo recurso ou modificar um existente, DELETE
para deletar um recurso e POST comumente utilizado para criao de um novo recurso.
A desvantagem de possuir uma interface uniforme est na diminuio da eficincia,
pois os dados so transmitidos de uma forma padronizada ao invs de serem otimizados
para as necessidades de uma aplicao especfica.
 Multicamada
Com o intuito de aperfeioar o requisito de escalabilidade da Internet, foi adicionado ao
estilo REST a caracterstica de diviso em camadas. Sistemas multicamada utilizam
camadas para separar diferentes unidades de funcionalidade. A principal desvantagem
deste modelo est na adio de overhead e latncia nos dados processados, reduzindo a
performance. Para um sistema baseado em rede que suporte cache, esta desvantagem
pode ser amenizada.
Code-On-Demand
O ltimo item do conjunto proposto pelo estilo REST uma caracterstica opcional, ou
seja, dependendo da situao ele poder ser adotado ou no. REST permite que clientes
tenham a funcionalidade de baixar e executar diretamente cdigo no lado cliente. Deste
modo, prima pela simplificao da parte cliente e foca na extensibilidade, em
contrapartida, reduz a visibilidade.
Um exemplo prtico conhecido de Code-On-Demand o Adobe Flash: Um usurio
(cliente) solicita uma pgina Web a qual contm um link para um SWF usando um web
browser. Aps a requisio, a pgina Web transportada para a mquina do cliente
juntamente com um SWF e o mesmo executado.

Troca de Mensagens
Uma das idias centrais na troca de mensagens a utilizao de um URI de
identificao nica para cada recurso. Dependendo do mtodo utilizado para invoc-lo e
dos dados na requisio HTTP, este URI ter um funcionamento diferenciado. Para
melhor contextualizar pode-se tomar como exemplo um Web service de uma loja virtual
qualquer, onde existam servios para gerenciamento de produtos. Funes bsicas como
cadastro, alterao, deleo e listagem de produtos. Para invocar um destes servios
REST identificados por URIs, utiliza-se o formato genrico de mensagem HTTP. Caso
seja uma solicitao a um servio de deleo ou listagem de produto (DELETE, GET),
apenas a requisio para o identificador do servio necessrio, pois o mtodo HTTP j
indica qual a operao a ser realizada e o recurso solicitado. Caso seja uma requisio
de cadastro de produto ou de alterao do mesmo (POST, PUT), sero enviados no
corpo da requisio, os dados do produto, como: nome, descrio e marca.

Figura 3. Retorno XML de um Web Service RESTful

 Neste protocolo, foi definida a passagem do cdigo de um produto especfico para
buscar os dados do mesmo. No informando este ID, todos os produtos so listados. O
retorno de uma chamada a um destes servios pode ser visto na Figura 3.
Outra caracterstica do protocolo HTTP, muito til na troca de mensagens nos
servios REST, o retorno de cdigos de status na resposta a uma requisio. Voltando
ao exemplo do cadastro de um produto, pode-se ter como retorno um HTTP/1.1 201
Created para a chamada ao servio de cadastro caso o servio seja executado com
sucesso, ou um HTTP/1.1 404 Not Found para a busca de um produto especfico que
no foi encontrado. O HTTP simples e de baixo overhead e sabendo utilizar bem suas
caractersticas, o desenvolvimento de Web services REST se torna ainda mais simples
[Silva 2008a].

Representaes
Quando uma aplicao dividida em recursos, conforme pregado pelo estilo REST, as
necessidades do usurio de um servio podem ser sanadas de uma forma mais dinmica.
O usurio pode construir uma URI apropriada e acess-la para que o servio desejado
seja alcanado. Trabalhando com a idia de recursos torna-se possvel oferecer
representaes em diferentes formatos e linguagens. Um usurio acessando um servio
da Itlia pode receber uma representao de um recurso em italiano, como um
americano acessando o mesmo servio dos EUA, pode ter como resultado a
representao na lngua inglesa.
Um recurso uma fonte de representaes, e uma representao so apenas dados
sobre o estado do recurso corrente. A maioria dos recursos na Web so itens de dados
prprios, como uma lista de produtos, logo uma representao bvia de um recurso so
seus dados em si. O servidor pode ento oferecer uma lista de produtos como um
documento XML, uma pgina Web ou em formato texto separado por vrgula. Alguns
recursos representam objetos fsicos, ou coisas que no podem ser reduzidas a
informao. Uma mquina de refrigerante ligada a um Web service pode disponibilizar
aos usurios da mquina informaes teis, como se o refrigerante est gelado, se o
refrigerante no est em falta, ou seja, metadados sobre o objeto e no que latas de
refrigerante estejam fisicamente disponveis por Web Service, pois objetos fsicos no
so dados [Richardson 2007].

Tipos de Representaes
Caso o servidor oferea mltiplas representaes de um recurso, o cliente do servio
deve decidir pela representao desejada. Existem diferentes maneiras RESTful de
passar essa informao ao servidor.
Uma das formas mais simples, prope a criao de URIs distintas para cada
representao de um recurso. Na analogia de um Web service que lista produtos de uma
loja, pode-se consumir o servio tendo como retorno uma representao em XML pela
URI http://www.loja.com.br/produtos/lista.xml e uma representao em formato
JSON pela URI http://www.loja.com.br/produtos/lista.json.
Uma segunda alternativa chamada de content negociation. Neste cenrio, existiria
somente uma URI para representar a lista de produtos,
http://www.loja.com.br/produtos/lista, no momento que um cliente fizesse uma
requisio ao servio, juntamente a requisio, seriam enviados dados no cabealho
HTTP, o qual sinalizaria o tipo de representao que o cliente espera receber. As
informaes no cabealho HTTP podem tanto originar do browser do cliente como
tambm serem setadas na criao do request, pelo cliente consumidor do servio. O
campo Accept-Language do cabealho HTTP pode ser usado pelo servidor para
identificar em que linguagem o cliente espera o retorno da requisio ou o campo
Content-Type para fins de identificao do formato solicitado.

Descritores de Web services REST

Existem opinies variadas sobre as interfaces de descrio de servios REST. H quem
julgue que elas no so necessrias. Outros acham vlido possuir um descritor de
servios, semelhante ao WSDL dos servios WS-*. Atualmente, os frameworks e
ferramentas voltadas ao desenvolvimento de servios REST esto se preocupando em
incluir o suporte a uma linguagem de descrio. Umas das linguagens mais difundidas
disponveis para isso a WADL. Com a liberao da WSDL 2.0 tornou-se possvel
tambm utiliz-la para descrever um servio REST.

WADL
O projeto WADL iniciou em 2006 e foi criado por Marc Hadley na Sun Microsystems.
Esta linguagem foi concebida para prover um formato descritivo para aplicaes Web,
especialmente as que utilizam XML. Em outras palavras, uma espcie de IDL
(Interface Definition Language) para aplicaes Web [Sun Microsystems 2006].
A Web Application Description Language (WADL) um vocabulrio XML que
expressa o funcionamento de recursos HTTP. Foi nomeada em analogia a conhecida
linguagem para descrio de Web services - WSDL, utilizada para descrever servios
baseados em SOAP e no estilo RPC. A WADL informa quais so os recursos
disponveis, os mtodos permitidos em cada um deles, e os parmetros de entrada e
sada dos servios. possvel disponibilizar um arquivo WADL que descreva todos os
recursos disponveis pelo servio criado, funcionando como um manual para o cliente
interessado na utilizao do mesmo.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<application xmlns="http://research.sun.com/wadl/2006/10">
<doc xmlns:jersey="http://jersey.dev.java.net/"/>
<resources base="http://localhost:8080/BestPriceTool-WS-REST/">
<resource path="categoria/">
<resource path="listar/">
<method name="GET" id="listarCategorias">
<response>
<representation mediaType="text/xml"/>
</response>
</method>
</resource>
</resource>
</resources>
</application>

Figura 4: Exemplo de WADL

 A estrutura do arquivo WADL simples e de fcil entendimento. Um exemplo de
WADL pode ser vista na Figura 4.

Estilo REST na Web

Pode-se perceber que todos os princpios do REST esto presentes na Web, tais como:
protocolo sem estado, endereamento, cache. Analisando o acesso a um site tpico da
Web com implementaes comuns REST (HTTP + XML) possvel notar que ambas
no se diferem. A nica caracterstica que no torna um site totalmente REST diz
respeito ao contedo de resposta/retorno de uma requisio. Enquanto o retorno de uma
requisio para um site tpico da web constitudo de informaes de formatao e
estilo para que os dados sejam estruturados para o usurio, o retorno de um servio
REST est voltado informao que o servio disponibiliza [Dias e Machado 2007].
As semelhanas entre REST e a Web foi, segundo [Fielding 2000], o motivador de
seus estudos, capturando as caractersticas que tornaram a Web bem sucedida. Portanto,
estas caractersticas esto sendo usadas para guiar a evoluo da Web.

7. Estudo de Caso
Nesta seo, apresentado um estudo de caso do desenvolvimento de servios de uma
loja virtual fictcia. A qual possui Web services para a manipulao de informaes
bsicas de uma loja, como: produtos, categorias e marcas. Estes Web services realizam
manipulaes de informaes como insero, edio, deleo e consulta. Sendo que, os
mesmos servios foram implementados em duas arquiteturas diferentes, uma utilizando
WS-* e outra no estilo REST (ROA).
Ambos os projetos foram desenvolvidos utilizando Java 6 na IDE Eclipse
Ganymede 3.4.1. Onde acessam uma base de dados em comum que utiliza como SGBD
a verso 5 do MySQL. A estrutura de dados da base utilizada apresentada na Figura 5.
A camada de persistncia dos Web services foi desenvolvida utilizando o framework
Hibernate verso 3, o qual possibilita o mapeamento das entidades da base de dados em
objetos Java. O servidor Web Java utilizado foi o Tomcat verso 6.

Figura 5. Estrutura de tabelas do caso de uso

Para a criao dos Web services WS-* foi utilizada a API Java JAX-WS 2.0
(Java API for XML Web Services) a qual baseada em annotations introduzidos na Java
SE 5. Esta API faz parte da plataforma Java EE da Sun Microsystems e facilita o
desenvolvimento e organizao dos servios.
Na criao dos Web services REST, foi empregada a API JAX-RS (Java API
RESTful Web Services) que dispe de suporte na criao de servios de acordo com os
princpios do estilo de arquitetura REST. Esta API tambm faz uso de annotations Java.
Aps o deploy das aplicaes no servidor Tomcat so disponibilizados arquivos de
descrio dos servios oferecidos (WSDL, WADL), conforme Figura 6.

Figura 6. Fluxograma do caso de uso

Para a criao do lado cliente, foi utilizada a ferramenta SoapUI verso 3. Esta
ferramenta possibilita a criao dos consumidores dos servios atravs de seus arquivos
de descrio (WSDL/WADL). O preenchimento de um header HTTP ou o
preenchimento de um envelope SOAP tambm facilmente realizado.
O fluxo de funcionamento dos servios WS-* iniciam com a requisio de um
cliente. Esta requisio encapsulada em um envelope SOAP que por sua vez
transportada at o Web service desejado em um pacote HTTP. Todos os dados que o
servio espera receber de um cliente est descrito no arquivo WSDL, disponibilizado
pelo Web service. A requisio de um cliente chega ao servio atravs de um Servlet
Java que serve como Listener de requisies e pertence ao JAX-WS.
O Web service aps receber a requisio contendo o envelope SOAP, o processa,
executa a regra de negcio contida no corpo do servio e monta um envelope SOAP de
resposta. Esta resposta enviada atravs do dispatcher presente na estrutura do
framework JAX-WS para o cliente consumidor do servio. Por fim, o cliente
desmembra o SOAP retornado e analisa os dados de retorno. Eventuais falhas na
execuo do servio so relatadas ao consumidor do servio atravs do envelope SOAP,
campo fault.
Nos servios REST, o fluxo de funcionamento se diferencia em alguns pontos
importantes. O cliente consumidor do Web service RESTful estrutura sua requisio em
uma mensagem HTTP. Esta mensagem HTTP pode conter um corpo de dados que so
enviados juntamente aos dados do cabealho. No cabealho pode ser informado atravs
do campo Content-Type, o tipo de dado que se deseja receber do servio (XML, JSON),
caso o mesmo seja um servio de listagem de dados. Para indicar que servio se deseja
chamar em um Web service, utiliza-se as URIs dos servios invocadas utilizando um
dos mtodos HTTP.
A requisio do cliente chega ao Web service atravs de um Servlet Java (JAX-RS)
que age como um Listener configurado no projeto REST. A partir da, a requisio
processada, endereada ao mtodo solicitado, onde executa a regra de negcio contida
nesse mtodo. Aps o termino da execuo do mtodo, enviada a resposta ao cliente
consumidor do servio. Caso alguma falha tenha ocorrido na execuo do mtodo, so
utilizados os cdigos de erro do protocolo HTTP para informar o cliente do acontecido.

8. Anlise Comparativa
No processo de anlise, foi visto que algumas caractersticas esto presentes em ambas
as partes. Dentre elas est a possibilidade de uso de cache e a propriedade de dividir o
sistema em camadas, fortalecendo a reusabilidade de cdigo. A Tabela 1 apresenta itens
da comparao entre servios WS-* e servios RESTful.
Tabela 1. Anlise Comparativa entre Web Services WS-* e Web services REST
Fator de Comparao Web services WS-* Web services REST

Tamanho de Pacote HTTP 584 bytes 399 bytes

Armazenamento de estados Permite Stateless

Baseado em operaes ou Baseado em recursos ou

Abordagem de design
verbos substantivos (URIs)

Interface Uniforme GET,

Interface Interface No Uniforme
POST, UPDATE, DELETE.

Permite que cdigo originado

Code on demand (COD) No voltado a COD da requisio ao Servidor seja
executado no lado Cliente.

Representao de dados XML Aberto

Descritor WSDL WSDL/WADL/Nenhum

O pacote usado na comparao foi o da resposta a uma requisio a um mtodo

de listagem de produtos em formato XML, sendo seu tamanho calculado pela
ferramenta SoapUI 3. Nesse aspecto REST leva vantagem uma vez que os servios
WS-* trabalham com envelopes SOAP envolvidos por pacotes HTTP. Com isso o
desempenho tambm afetado, pois os pacotes SOAP devem sofrer um parse antes de
os dados serem utilizados.
Na comunicao Cliente/Servidor, nenhum tipo de estado mantido (stateless)
no uso de RESTful. Esta caracterstica prima pela escalabilidade e simplicidade dos
servios e da infra-estrutura envolvida. Nos testes tanto os Web services RESTful quanto
os WS-* foram desenvolvidos sem armazenamento de estados, mas os servios WS-*
podem ser desenvolvidos visando esta caracterstica. Por exemplo, em uma aplicao
que necessite de autenticao, a qual solicite um usurio e uma senha, o cliente do
servio RESTful deve enviar os dados de autenticao a cada requisio. Nos servios
WS-* possvel solicitar os dados de autenticao somente na primeira requisio,
salvando os mesmos em sesso no servidor. Nesta abordagem, pode-se ganhar em
desempenho, pois estes dados no precisaro ser enviados e validados a cada requisio.
Por outro lado, a questo da escalabilidade se torna mais complexa e custosa onde o
armazenamento de estado de mltiplos clientes acarretar o aumento na demanda de
recursos como memria e processamento no servidor.
 Enquanto a abordagem dos servios WS-* que foram desenvolvidos conforme o
caso de uso da Seo 7 disponibiliza operaes tais como getCategoria(), setCategoria(),
deleteCategoria(), os servios RESTful se baseiam em recursos representados por URIs.
Para requisitar os mtodos REST equivalentes citados acima necessrio requisitar a
URI http://localhost:8888/categorias/[nomeCategoria] requisitada juntamente com os
verbos da interface uniforme do HTTP, ou seja, uma requisio HTTP/GET para esta
URI busca os dados dessa categoria, uma requisio POST cria uma nova categoria e
uma requisio DELETE a deleta.
Os verbos do HTTP caracterizam a interface uniforme presente no estilo REST.
Sendo que nos servios WS-* a interface no uniforme e definida pelo
desenvolvedor quando nomeia as atividades do servio (nome dos mtodos). Com uma
interface uniforme o desenvolvimento fica mais claro e padronizado, entretanto, as
URIs podem no ter o mesmo poder de descrio de um nome de mtodo bem
elaborado.
A possibilidade de baixar scripts/Applets para execuo no cliente no tem
nenhuma restrio de ser feita atravs de servios RESTful ou WS-*. possvel baixar
cdigo Javascript ou um Applet fazendo requisies SOAP, embora isso seja bastante
incomum, sendo mais factvel ocorrer com REST do que com WS-*. REST
freqentemente associado a Web, onde o navegador fortemente utilizado, provendo
um melhor suporte a Code on Demand, comparado aos servios SOAP que so mais
associados a Desktop. Os navegadores possibilitam que um servidor retorne cdigo para
ser executado no lado cliente. Essa execuo adicional de cdigo permite estender ou
at mesmo customizar a capacidade de um cliente sem a necessidade de instalaes ou
alteraes. Sendo um exemplo prtico o objeto XmlHttpRequest do Javascript (AJAX).
Com base no Code on Demand desenvolvido no caso de uso dos servios REST pode-se
notar que apesar de trazer vantagens como as citadas acima, esta prtica encobre o que
est sendo recebido e executado no cliente, logo, deve-se confiar na fonte do servio.
A possibilidade de retornar dados em diferentes representaes torna os servios
mais dinmicos e oferece diferentes opes ao cliente requisitante. Esta caracterstica
dos servios REST no encontrada nativamente nos servios WS-*, os quais
trabalham com representao XML por padro. Nos servios desenvolvidos no caso de
uso, o retorno dos Web services no estilo REST podem ser requisitados nas
representaes XML ou JSON, sendo que em servios WS-*, representaes diferentes
da XML no so possveis sem serem parte do contedo do pacote SOAP.
A utilizao de um arquivo descritor de Web service de fundamental
importncia para servios WS-*. Atravs dele ferramentas de desenvolvimento e at
mesmo os prprios programadores tem acesso a informaes teis sobre os Web
services. Estes descritores podem auxiliar no consumo dos servios, tornando este mais
vivel. Os Web services RESTful podem ser descritos atravs de WSDLs ou WADLs,
mas seu uso no um requisito imposto pelo estilo REST. Esta flexibilidade garante
que um servio RESTful funcione normalmente sem um arquivo descritor. No caso de
uso da Sesso 7, foi utilizada WSDL para descrever os servios WS-* e WADL para os
RESTful, com isso o consumo dos servios atravs da ferramenta SoapUI se tornou
prtica e fcil. Sem a utilizao de um descritor o consumo de um servio ou criao de
um cliente para este servio se tornaria mais demorado, tendo que o desenvolvedor
buscar manualmente as informaes necessrias. Ferramentas como a IDE JDeveloper
da Oracle, NetBeans da Sun Microsystem e Eclipse inicialmente desenvolvido pela
IBM, utilizam dos descritores para a gerao de servios ou clientes de forma
automatizada.

9. Concluses
Este artigo apresentou uma anlise comparativa e conceitual entre Web services
RESTful e WS-*. Tambm apresentou um estudo de caso para demonstrar as duas
abordagens e servir de instrumento no processo de comparao. No decorrer dos
estudos, constatou-se que as duas abordagens tm suas vantagens e desvantagens,
demonstrando que cada uma tem sua rea de especialidade e, portanto, o dever de
coexistir.
Os servios WS-* tm a vantagem de ser bastante difundidos atualmente nas
empresas e organizaes de grande porte, ideais em circunstncias que envolvem
diferentes protocolos de comunicao; em ferramentas middleware utilizadas na
integrao de sistemas complexos e de diferentes arquiteturas (BPEL, ESB). Servios
RESTful, por outro lado, tm uma boa resposta em utilizaes que envolvam
manipulaes de dados onde resgatam as caractersticas da Web. Recomenda-se em
aplicaes mobile, onde o custo na troca de mensagens bastante elevado; em blogs e
sites de relacionamento, os quais so baseados em recursos e demandam de chamadas
RSS ou Atom; em servios de busca na internet, que trabalham com um alto trfego de
informaes.
Como trabalhos futuros tm-se em vista a avaliao de ferramentas para o
desenvolvimento de Web services que suportem ambos os tipos de servios, bem como
o detalhamento e aprofundamento de metodologias para implementar segurana em
servios de ambas as abordagens.
Referncias
BERNERS-LEE, Tim. Uniform Resource Identifier (URI): Generic Syntax, 2005.
Disponvel em: < http://labs.apache.org/webarch/uri/rfc/rfc3986.html>. Acesso em:
05 ago. 2009.
CHINTAKHA, Eran. Enable REST with Web services, Part 1: REST and Web services
in WSDL 2.0. Disponvel em: <https://www.ibm.com/developerworks/webservices/li
brary/ws-rest1/>. Acesso em: 08 nov. 2009.
CUNHA, Davi. Web Services, SOAP e Aplicaes Web. Disponvel em:
<http://www.devedge-temp.mozilla.org/viewsource/2002/soap-overview/index_pt_br
.html>. Acesso em: 08 nov. 2009.
DIAS, Ari Neto; MACHADO, Lucas Alves. REST com Struts 2. Java Magazine, So
Paulo, Edio 48, pg. 58 66, 2007.
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based
Software Architectures. 2000. Tese (Doutorado em Informao e Cincia da
Computao) Universidade da Califrnia, Califrnia, 2000.
FIELDING, Roy Thomas; BERNERS-LEE, Tim; W3C; UC Irvine; J. Gettys; Compaq;
H. Frystyk; J. Mogul; L. Masinter; Xerox; Microsoft; P. Leach. Hypertext Transfer
Protocol -- HTTP/1.1, 1999. Disponvel em: < ftp://ftp.isi.edu/in-notes/rfc2616.txt >.
Acesso em: 05 ago. 2009.
MENNDEZ, Andrs Igncio Martnez. Uma ferramenta de apoio ao desenvolvimento
de Web Services. Dissertao de Mestrado, Universidade Federal de Campina
Grande, curso de Ps-Graduao em Informtica, 2002.
NEWMARCH, Jan; A RESTful Approach: Clean UPnP without SOAP: Using Java in
Service-Oriented Architectures. 2004. School of Network Computing, Monash
University, 2004. Disponvel em: <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?
arnumber=1405157>. Acesso em: 08 nov. 2009.
OASIS. UDDI Executive Overview: Enabling Service-Oriented Architecture, 2004.
Disponvel em: <http://uddi.xml.org/files/uddi-exec-wp.pdf>. Acesso em: 23 jun.
2009.
POTSS, Stephen. Aprenda Web Services em 24 Horas: Para quem no pode perder
tempo 24 lies de 1 hora. Editora Elsevier, 2003.
RICHARDSON, Leonard; RUBY, Sam. RESTful Web Services: Web Services for the
Real World. OReilly Media Inc, 2007.
SHI, Xuan; Sharing service semantics using SOAP-based and REST Web services.
School of Network Computing, West Virginia University, VA, 2006. Disponvel em:
< http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1628908>. Acesso em: 08
nov. 2009.
SILVA, Pereira Bruno Luiz. REST vs WS-*: Uma Viso Pragmtica. Java Magazine,
So Paulo, Edio 54, pg. 38 47, 2008a.
SILVA, Pereira Bruno Luiz. Web services WS-*. Java Magazine, So Paulo, Edio 55,
pg. 24 31, 2008b.
SNELL, James. Resource-oriented vs. activity-oriented Web services. 2004. Disponvel
em: <http://www.ibm.com/developerworks/webservices/library/ws-restvsoap/>.
Acesso em: 15 set. 2009.
SUN MICROSYSTEMS. Web Application Description Language (WADL). Disponvel
em: <https://wadl.dev.java.net/wadl20090202.pdf>. Acesso em: 9 jun. 2009.
TILKOV, Stefan. A Brief Introduction to REST. Disponvel em:
<http://www.infoq.com/articles/rest-introduction/>. Acesso em: 08 nov. 2009.
WEERAWARANA, Sanjiva; CURBERA, Francisco; LEYMANN, Frank; STOREY,
Tony; FERGUSON, Donald F. Web Services Platform Architecture: SOAP, WSDL,
WS-Policy, WS-Adressing, WS-BPEL, WS-Reliable Messaging, and more. Prentice
Hall PTR, 2005.
W3C. Simple Object Access Protocol (SOAP) 1.1: W3C Note 08 May 2000. Disponvel
em: < http://www.w3.org/TR/2000/NOTE-SOAP-20000508/>. Acesso em: 14 jun.
2009.
W3C. Web Services Architecture: W3C Working Group 2004a. Disponvel em:
<http://www.w3.org/TR/ws-arch/ >. Acesso em: 13 maio 2009.
W3C. Architecture of the World Wide Web, Volume One 2004b. Disponvel em:
<http://norman.walsh.name/2004/12/15/examples/webarch.pdf>. Acesso em: 04 ago.
2009.