Web Services

Os Web Services so o ponto fundamental para a integrao de aplicaes web. aqui que reside a importncia dos Web Services, no facto de fornecerem a aplicaes diferentes, de diferentes plataformas, linguagens ou sistemas operativos, um meio de interligar a informao. portanto uma aplicao cujos componentes podem ser distribudos e executados em dispositivos distintos [6]. A chave a interoperabilidade. Apesar de esta no ser a nica soluo, pois tecnologias como CORBA,RMI e COM tambm abordavam este problema, os Web Services so baseados no protocolo HTTP (protocolo mais usado na internet), e na linguagem XML, usada para codificar e descodificar dados. Assim, desenvolver um sistema deste tipo torna-se mais simples, o que no acontece com as tecnologias referidas anteriormente, uma vez que exigem a aprendizagem de novas linguagens e tecnologias. Os Web Services podem ser divididos em dois grandes grupos, os baseados em SOAP, e os baseados no estilo REST, que sero abordados individualmente. A transparncia de linguagem, ou seja, a interoperabilidade, pode parecer algo de enigmtico, mas se um Web Service seja REST ou SOAP, escrito em Php, pode ser consumido por clientes Java, C# ou flex, ter que existir obviamente uma espcie de intermedirio, que trata as diferenas das linguagens entre o servidor e o cliente. A tecnologia XML, que suporta a troca e processamento de um documento estruturado, age como um intermedirio [6]. Por exemplo, num Web Service SOAP, um determinado cliente envia um documento SOAP (escrito em XML) em forma de pedido ao servio, que por sua vez e de forma transparente, responde com outro documento SOAP [6].

Num quadro onde o aumento do software escrito em linguagens distintas e a sua distribuio numa vasta variedade de plataformas notrio e cada vez mais acentuado, os Web Services so de extrema importncia. Repare-se que raro um sistema de software operar isoladamente. Um sistema de software tpico tem que interagir com outros, que podem eventualmente residir em plataformas diferentes e serem escritos em linguagens distintas [6].

SOAP Web Services

Os elementos de uma plataforma Web Services baseada em SOAP so os seguintes: SOAP (Simple Object Access Point) UDDI (Universal Description Discovery and Integration) WSDL (Web Services Description Language)

O primeiro um protocolo de comunicao, independente da plataforma ou linguagem baseado em XML, que permite a troca de dados, sobre HTTP, entre aplicaes. O WSDL um documento em XML, que descreve o Web Service. Especifica a localizao do Web Service, e os mtodos de que ele dispe. Estes dois so os componentes relevantes para a implementao de um Web Service baseado em SOAP, e por isso so abordados com detalhe. SOAP

SOAP (Simple Object Access Protocol) pode ser definido de uma forma simplista, como um protocolo para aceder a um Web Service. portanto, um formato para enviar mensagens XML entre aplicaes via internet, tipicamente sobre HTTP. Oficialmente este protocolo descrito da seguinte forma: O SOAP um protocolo leve, intencionado para trocar informao estruturada num ambiente distribudo e descentralizado. O SOAP usa tecnologias XML para definir uma framework extensvel de mensagens, que proporciona uma construo de mensagem que pode ser trocada atravs de uma variedade de protocolos numa camada inferior. A framework foi desenhada para ser independente de qualquer modelo de programao em particular e de outras implementaes semnticas especificas. [1] Uma mensagem SOAP um documento XML constitudo pelos elementos apresentados na Error: Reference source not found. O envelope identifica o documento XML como uma mensagem SOAP. O cabealho (Header) opcional, e contm informaes especficas de uma determinada aplicao. O corpo (Body) da mensagem obrigatrio, pois possui informaes sobre o pedido e resposta, entre um cliente e servidor. Por fim o ltimo elemento indica possveis erros e o estado da mensagem. A Figura 5 exemplifica um documento em XML com o esqueleto de uma mensagem SOAP. Tipicamente num Web Service baseado em SOAP, o cliente efectua uma RPC (Remote Procedure Call) atravs da invocao de uma das operaes do servio e obtm uma resposta, formando um padro pedido/resposta. Neste padro so trocados envelopes SOAP que permitem o servio e o cliente serem programados em linguagens diferentes.

Figura

- Constitui??o de uma mensagem SOAP

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <soap:Header> ... </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> </soap:Envelope> Figura 5 - Esqueleto de uma mensagem SOAP [2]

Apesar de existirem outros padres (e.g. um cliente pode apenas enviar uma mensagem sem esperar por uma resposta), este o dominante. Para exemplificar, veja-se o pedido HTTP cujo corpo da mensagem contm uma mensagem SOAP (Figura 5). Este pedido tem

como objectivo solicitar a data e hora actuais ao servidor. Comea com o mtodo HTTP utilizado, que neste caso um POST. usado o POST ao invs do GET (o que faria mais sentido uma vez que se est a fazer um pedido e no a introduzir nova informao no servidor), pois este ltimo no possui um corpo para encapsular o envelope SOAP [6]. De seguida vem a URL e verso HTTP que o cliente compreende. Seguido do cabealho, que especifica entre outros, o tamanho da mensagem e o tipo (text/xml), vem o corpo que contm o envelope SOAP. Por sua vez o corpo do envelope SOAP contm a operao que o cliente pretende invocar (GetTime). Repare-se que num Web Service baseado em SOAP, necessria a especificao no pedido, do nome da operao que se pretende invocar (RPC). Este pormenor importante e interessante, pois nesta mensagem est-se a invocar um mtodo (GetTime) a partir de um outro mtodo (POST), o que nunca deve acontecer num Web Service REST, como alis se ir verificar posteriormente.

POST /TimeS erverPhp/PhpTimeSoapServer.php HTTP/1.1 Host: localhost Referer: http://localhost/Monitor-debug/Monitor.swf Content-Length: 279 soapaction: "" content-type: text/xml; charset= utf-8 Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.133 Safari/ 534.16 Accept-Encoding: gzip,deflate,sdch Accept-Language pt-PT,pt;q= : 0.8,en-US;q= 0.6,en;q= 0.4 Accept-Charset: ISO-8859-1,utf-8;q= 0.7,*;q= 0.3 < SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org /soap/envelope/" xmlns:xsd= "http://www.w3.org/2001/ XMLSchema" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance"> < SOAP-ENV:Body> < tns:GetTime xmlns :tns= "http:// soap/"/> < /SOAP-ENV:Body> < /SOAP-ENV:Envelope>

Figura 5 Pedido HTTP cujo corpo contm uma mensagem SOAP

Do lado do servidor, o envelope SOAP processado e identificada a operao requisitada. O servio invoca essa operao e retorna uma resposta HTTP (Figura 5). Neste caso a mensagem HTTP, comea com o cdigo 200 e respectivo OK, que significa que o pedido foi processado correctamente. O corpo da mensagem HTTP contm novamente um envelope SOAP, cujo corpo contm a resposta com a data e hora actual.

HTTP/1.1 200 OK Date: Mon, 14 Mar 2011 16:45:19 GMT Server: Apache/2.2.17 (Win32) PHP/5.3.5 X-Powered-By: PHP/5.3.5 Content-Length: 286 Content-Type: text/ xml; charset= utf-8 < ?xml version "1.0" encoding= = "UTF-8"?> < SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org /soap/envelope/" xmlns:ns1= "http://soap/"> < SOAP-ENV:Body> < ns1:GetTimeResponse> < return> Mon, 14 Mar 2011 16:45:19 + 0000< /return> < /ns1:GetTimeResponse> < /SOAP-ENV:Body> < /SOAP-ENV:Envelope>

Figura 5 Resposta HTTP ao pedido anterior

WSDL

Um documento WSDL (whiz dull) um documento XML, que

descreve os mtodos que um determinado Web Service expe. Alguns servios necessitam deste documento antes de serem publicados, outros geram-no automaticamente, mas este documento particularmente til para o desenvolvimento e suporte do cliente, sendo que existem ferramentas que permitem a gerao de cdigo de suporte para o cliente, em vrias linguagens, atravs da inspeco deste documento. Um cliente pode consumir um documento WSDL associado a um Web Service, para obter informaes crticas sobre os tipos de dados e operaes que o servio fornece. Pode-se portanto afirmar que este documento um contracto entre o servio e os seus consumidores, que fornece informaes relevantes como, a URL do servio, as suas operaes, tipos de dados e atravs da descrio das mensagens trocadas pelo servio e cliente, o padro do servio, como por exemplo o padro pedido/resposta [6]. Um documento WSDL dividido nas seguintes seces (Figura 5): types: uma seco opcional, que define o tipo dos dados. Se esta seco no estiver preenchida, significa que o servio usa apenas dados de tipo simples, tais como, string, int, ou float. O tipo dos dados definido, por defeito, atravs do sistema de tipos XML Schema. este sistema de tipos que serve de intermedirio entre o tipo de dados do cliente e do servidor; message: Esta seco define as mensagens que

implementam o servio. A ordem das mensagens indica o padro de funcionamento do servio (Pedido/Resposta); portType: Esta seco agrupa as operaes que o servio oferece. As operaes so apresentadas de forma abstracta, ou seja, sem detalhes de implementao;

binding: Nesta seco os detalhes omitidos na seco precedente so apresentados. Neste caso o atributo transport indica que as mensagens SOAP vo ser recebidas e enviadas atravs de HTTP e o atributo style, indica o estilo do servio, que neste caso RPC;

service: Por fim esta seco indica o endpoint ou a URL, onde o servio e as suas operaes se encontram disponveis.

Finalizando, este documento til para um cliente consumir um determinado Web Service. A UDDI, por exemplo, uma maneira de publicar um documento WSDL e de facilitar os clientes a descobrir e consumir o Web Service que o WSDL descreve. A Amazon ou a Google so exemplos de empresas, que disponibilizam Web Services baseados em SOAP atravs de documentos WSDL, que podem ser consumidos por clientes. No entanto, apesar de este documento descrever toda a sintaxe do servio, o mesmo no acontece com a semntica, ou seja, descreve as operaes do servio, tipos de dados, padro de mensagens, entre outros, mas o documento em si, no tem informaes explcitas sobre o propsito do servio. Cabe ao programador prever ou analisar a funcionalidade do servio, o que se traduz numa limitao do WSDL.

Figura 5 - Documento WSDL correspondente ao servio que retorna a data e hora actuais

RESTful Web Services

O REST, termo criado por Roy Fielding e acrnimo de Representational State Transfer, surge como uma alternativa ao SOAP, e apesar de no ser um novo conceito, s recentemente se tornou mais popular. O REST no um standard, mas sim uma abordagem para o desenvolvimento e fornecimento de servios na internet [4]. Ao contrrio do SOAP, que um protocolo de troca de mensagens, o REST um estilo de arquitectura de software para sistemas de hipermdia distribudos [6]. Um exemplo bvio de um sistema de este tipo a internet. A filosofia do REST sustenta que os princpios e protocolos da arquitectura da internet existentes so suficientes para criar Web Services. Assim o REST assenta num simples conceito: A tudo o que pode ser manipulado atravs de um conjunto limitado de operaes, atribui-se uma URI (Uniform Resource Identifier), sendo que o cliente determina o mtodo a utilizar. Isto significa que, um nmero reduzido de mtodos aplicvel a uma grande quantidade de dados. Imagine-se uma mesa. Existem copos, pratos e chvenas. Todos eles so nomes. Podese pegar neles, parti-los ou move-los. Para qualquer um daqueles nomes, pode-se aplicar qualquer um destes verbos. Isto importante pois, significa que

possvel

aplicar

um

verbo

universal

(GET,

PUT,

DELETE), para diferentes nomes, e no um verbo diferente, para cada nome. Quando um browser, faz um HTTP GET de uma URL, retornada uma pgina web, que pode conter imagens, ficheiros de udio, texto, vdeos, etc. O importante aqui, cada um desses nomes poderem ser acedidos atravs do mesmo verbo. Na arquitectura REST, identificam-se seis

elementos de dados [8]:

Recurso; Identificador de recurso; Metadados de recurso; Representao; Metadados de representao; Dados de controlo.

Um recurso tudo o que possui uma identidade, que tenha um estado e um determinado comportamento, sendo que pode ser esttico, na

medida em que quando examinados possuem sempre o mesmo valor, ou varivel. Toda a informao que pode ter um nome pode ser um recurso [8]: um documento,

uma imagem, um determinado servio, entre outros. Uma URI identifica um recurso, que observvel atravs de uma representao, ou seja, um recurso no manipulado directamente. Uma representao algo que se obtm do recurso quando o cliente faz um pedido, sendo que o cliente recebe uma representao do recurso. a representao que transferida da mquina do servidor para a mquina do cliente. Uma representao portanto um conjunto de bytes com a adio de metadados de representao, que descrevem esse conjunto de bytes [8]. Os metadados consistem num formato de pares nome-valor, onde o nome corresponde a um standard que define a estrutura e semntica do valor [8]. Uma resposta pode incluir metadados de representao e de recurso. Por fim os dados de controlo, seleccionam a representao solicitada adequada. A Tabela 2 resume os elementos que constituem o REST.
Tabela 2-Elementos de dados do REST [8]

Uma determinada URL, pode ser um recurso. O cliente acede num a esse browser recurso, a URL introduzindo por exemplo, correspondente

(www.exemplo.pt). Uma representao retornada (tipicamente um documento em HTML ou XML), e a aplicao cliente, permanece num determinado estado. Este estado alterado quando o cliente acede a um outro recurso, atravs da representao retornada (www.exemplo.pt/menu). Portanto, a aplicao cliente, move-se de um determinado estado para outro, baseada na representao, da o Representational State Transfer.

Princpios arquitecturais do REST

Alguns dos princpios arquitecturais foram j mencionados e introduzidos no captulo anterior. Porm abordam-se agora os princpios desta arquitectura de forma mais directa e aprofundada, uma vez que so importantes para o desenvolvimento de um servio REST. Uma aplicao RESTful, ou um Web Service RESTful, um programa que segue rigorosamente os princpios e restries impostas pela arquitectura REST. Assim uma aplicao REST deve possuir as caractersticas relatadas de seguida.

Endereamento O endereamento a ideia de que todos os recursos podem ser

acedidos atravs de um nico identificador [7]. Como j referido, este aspecto conseguido atribuindo-se a cada recurso uma URI. Quando um pedido efectuado atravs de um browser, o utilizador introduz uma URI, sendo que o formato tipicamente:
protocolo://host:porta/caminho?queryString

O protocolo numa aplicao REST usualmente o HTTP(S). A localizao do recurso na rede dada pelo par host:porta, sendo que o caminho especifica a directoria do recurso na respectiva localizao de rede. O caminho pode ser visto como uma directoria local do computador de um utilizador. O ? opcional e indica uma query, como por exemplo:
http://exemplo.pt/PinkFloydCds?CdName=TheDivisonBell

Neste caso perceptvel que o utilizador solicita um recurso, que se trata de um cd dos PinkFloyd cujo nome The Divison Bell.

Restrio de operaes Este princpio foi j mencionado, quando se fez referncia que um determinado conjunto pequeno de verbos pode manipular uma infinidade de nomes. A ideia usar o conjunto finito de operaes que o protocolo de distribuio do servio oferece. Como usualmente o protocolo utilizado pelo REST o HTTP, significa que os mtodos normalmente utilizados so os fornecidos por este protocolo. Na Tabela 2 esto listados os mtodos, tambm conhecidos como verbos HTTP mais utilizados, e a sua correspondncia s operaes CRUD (Create, Read, Update, Delete). de realar que estes verbos devem ser utilizados de forma coerente, relativamente operao que se pretende efectuar. Por exemplo e recorrendo ao exemplo anterior, se o utilizador pretende visualizar um determinado cd dos PinkFloyd, o verbo adequado para esta operao seria obviamente o GET.

Tabela 2 Verbos HTTP mais utilizados

Verbo HTTP GET Operao CRUD Ler um recurso Descrio do verbo

PUT

DELETE POST

Operao somente de leitura, usada para obter dados do servidor. uma operao idempotente e segura1. Actualizar um Coloca o corpo da mensagem HTTP numa localizao especificada na mensagem recurso HTTP. O cliente sabe qual o recurso que est a ser actualizado. uma operao idempotente. Apagar um recurso Usada para remover um recurso. uma operao tambm idempotente. Criar um recurso a nica operao no-idempotente e no segura, pois pode alterar o servio.

Servio orientado representao

Cada recurso enderevel atravs de uma URI, sendo que existe uma troca da representao de um recurso entre o cliente e o servidor. Com a operao GET, o cliente recebe uma representao do estado actual de um determinado recurso. A complexidade na interaco clienteservidor num servio RESTful reside na troca de representaes [7]. Estas so normalmente um documento XML, podendo ser tambm JSON ou YAML. Este encapsulado no corpo da mensagem HTTP, sendo que o formato da representao indicado no cabealho dessa mesma mensagem.

Comunicao Stateless
1 Idempotente na medida em que o facto de se ler uma informao do servidor, no altera o contedo da informao. segura pois a operao no altera o estado do servidor.

No REST, stateless significa que no existem dados das sesses iniciadas por um determinado cliente no servidor [7], ou seja, o servidor no se lembra dos eventos ou interaces realizadas anteriormente. Se existir a necessidade de manter o estado de uma sesso especfica, esta deve ser tratada pelo cliente. Isto implica uma maior facilidade de manuteno do servidor.

REST vs. SOAP

Neste captulo, realizada uma comparao entre o SOAP e Web Services, e a abordagem do REST. Esta uma discusso usual, e tanto o REST como o SOAP, tm os seus proponentes. A W3C (World Wide Web consortium) afirma: A W3C est a transformar a arquitectura inicial da web (HTML,URI e HTTP), na arquitectura da web de amanh, construda sobre uma fundao slida proveniente do XML [5]

No entanto os defensores do REST, argumentam que os standards envolvidos no funcionamento da internet so suficientes e possuem vantagens. Uma delas o facto de que qualquer recurso (nome) poder ser identificado por uma URL. Os clientes manipulam esse recurso atravs dos comandos HTTP, como o GET, PUT, ou DELETE, ou seja, o enfse na diversidade de nomes. O SOAP, pelo contrrio, enfatiza a diversidade de comandos do protocolo (verbos), pois segue uma abordagem RPC. Assim, o facto de o REST utilizar uma interface amplamente conhecida e usada

(URI) e de explorar o que o HTTP oferece, constitui uma vantagem em relao ao SOAP para o desenvolvimento de Web Services, uma vez que a curva de aprendizagem menor. Outro tpico importante a utilizao da largura de banda. Um dos benefcios do REST que os pedidos e respostas podem ser mais curtos, resultando numa latncia de interaco menor. O SOAP, por outro lado, necessita sempre da construo do envelope e das definies dos namespaces para cada mensagem. Uma determinada resposta em SOAP, necessita de um maior nmero de bytes do que a mesma resposta em REST. No entanto, os envelopes SOAP so transparentes ao programador [6], que no tm que se preocupar com a escrita do documento XML a enviar, e com a anlise desse mesmo documento na recepo. Nas aplicaes RESTful implementadas nesta dissertao, com uma nica excepo (o cliente em flex faz o parse do XML automaticamente), foi sempre necessria a construo e anlise do documento XML. Isto pode tornar-se num processo moroso e difcil, quando se lida com documentos XML grandes e complicados. A existncia de um contracto entre o servio e o seu consumidor, ou seja o WSDL, do ponto de vista do programador uma grande vantagem, pois pode ser usado para gerar cdigo de suporte escrita do cliente. De facto, uma das grandes desvantagens do REST a falta de um contracto deste tipo, de forma a suportar a codificao do cliente [6]. Imagine-se o caso, possivelmente bastante comum, em que o programador do cliente no o mesmo que o programador do servidor. Neste caso, o programador ter que obrigatoriamente ter informaes acerca dos formatos das URI de cada recurso, os mtodos relacionados com cada URI, a correspondncia entre as URI e respectivos recursos, o contexto em que uma determinada operao se insere no mundo real, entre outras. Apesar disso existem j iniciativas para a introduo de um documento desse tipo. O WADL (Web Applications Description Language) age como

um contracto, que semelhantemente ao WSDL permite facilitar o programador na escrita do cliente (iniciativa Java). O aparecimento de um formato standard deste gnero seria de grande vantagem para o REST. A segurana tambm um assunto muito discutido. Apesar de os proponentes do REST afirmarem que este seguro, por ser baseado na infra-estrutura de segurana da internet, a verdade que, dados que necessitem de estar seguros, no devem ser enviados como parmetros numa URI. No entanto, as opinies neste campo so muito divergentes, existindo ainda alguma falta de comparao entre as propriedades relacionadas com a segurana no HTTP e nos Web Services.

REST Simples de implementar; Leve; Falta de frameworks de apoio para o

desenvolvimento de aplicaes RESTful, apesar de ser rara a linguagem que no possua os meios necessrios para a codificao de uma aplicao deste tipo (suporte HTTP e XML); Necessidade da codificao e anlise do

documento XML.

SOAP Strong typed; Boas ferramentas de desenvolvimento inclusive

uma quantidade alargada de APIs dedicadas a Web Services SOAP em vrias linguagens; WSDL que facilita a codificao dos clientes; No tira partido das vantagens, j h muito existentes, fornecidas pelo HTTP; Mais pesado que o REST.

Concluses

Ambas as abordagens possuem os seus apoiantes. O SOAP tem a vantagem de ter mais suporte por parte de grandes empresas, e de organizaes como a W3C. Nomeadamente a Microsoft e IBM, oferecem kits baseados em SOAP para o desenvolvimento de Web Services. No entanto, so j vrios os sistemas que utilizam REST:

Amazon.com: Fornece Web Services com SOAP e REST

Ebay: Fornece Web Services com SOAP e REST Yahoo: Fornece Web Services com REST

De notar que a internet baseada na mesma abordagem que o REST, o que prova que este bastante promissor.

Referncias

[1] World Wide Web consortium (W3C). W3C Recommendation 27 April 2007. http://www.w3.org/TR/soap12-part1/ [2] World Wide Web consortium (W3C).W3Schools. http://www.w3schools.com/soap/soap_intro.asp [3] Web Services Essentials [4] Michael Przybilski. REST REpresentational State Transfer. [5] World Wide Web Consortium (W3C). About the World Wide Web consortium (w3c). http://www.w3.org/Consortium/. [6] Martin Kalin. Java Web Services: Up and Running. OReilly Media, Inc. 2009. [7] Bill Burke. RESTful Java with JAX-RS. OReilly Media, Inc.2009. [8] Roy Thomas Fielding. Architectural Styles and the Design of Networkbased Software Architectures. University of California, Irvine. 2000.