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 ecommerce 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, WSSecurity, WS-Trust, WS-ReliableMessaging, WS-Transfer, WS-I Basic Profile, WSTransaction 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 Tamanho de Pacote HTTP Armazenamento de estados Abordagem de design Interface

Web services WS-* 584 bytes Permite Baseado em operaes ou verbos Interface No Uniforme

Web services REST 399 bytes Stateless Baseado em recursos ou substantivos (URIs) Interface Uniforme GET, POST, UPDATE, DELETE. Permite que cdigo originado da requisio ao Servidor seja executado no lado Cliente. Aberto WSDL/WADL/Nenhum

Code on demand (COD) Representao de dados Descritor

No voltado a COD XML WSDL

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.