Arquitetura REST

Lvia Couto Ruback Rodrigues

Universidade Federal de Juiz de Fora

Instituto de Cincias Exatas
Departamento de Cincia da Computao
Bacharelado em Cincia da Computao
Orientadora: Profa. Regina Maria Maciel Braga Villela

Juiz de Fora, MG
Julho de 2009

Arquitetura REST

Lvia Couto Ruback Rodrigues

Monografia submetida ao corpo docente do Departamento de Cincia da Computao do

Instituto de Cincias Exatas da Universidade Federal de Juiz de Fora, como parte integrante dos
requisitos necessrios para a obteno do grau de Bacharel em Cincia da Computao.

Aprovada pela banca constituda pelos seguintes professores:

_______________________________________________________

Profa. Regina Maria Maciel Braga Orientadora

DSc. em Engenharia de Sistemas e Computao,
COPPE/UFRJ, 2000

_______________________________________________________

Prof. Marco Antnio Pereira Arajo

DSc. em Engenharia de Sistemas e Computao,
COPPE/UFRJ, 2009

_______________________________________________________

Profa. Jesuliana Nascimento Ulysses

Mestre em Computao
UFF

Juiz de Fora, MG
Julho de 2009

Agradecimentos
Agradeo a Deus, por me dar foras para seguir adiante.
Agradeo a meus familiares, em especial minha me, pelo incentivo e apoio incondicionais
em todos os momentos.
Aos amigos e colegas de sala por compartilhar comigo bons momentos e ajudar a superar os
momentos difceis.
Ao meu namorado Adriano por se fazer sempre presente, pelo carinho, pacincia e dedicao.
E a todos que de alguma forma contriburam no somente para o desenvolvimento deste
trabalho, mas tambm para a concluso do curso.

ii

Sumrio
Lista de Redues ................................................................................................................... vi
Lista de Figuras ..................................................................................................................... vii
Resumo .................................................................................................................................... ix
Abstract .................................................................................................................................... x

Introduo........................................................................................................................... 1
1.1

Motivao ...................................................................................................................... 1

1.2

Objetivos........................................................................................................................ 2

1.3

Organizao do trabalho ................................................................................................. 2

Arquitetura de Software..................................................................................................... 3
2.1

Histrico ........................................................................................................................ 3

2.2

Conceito e Papel da Arquitetura de Software .................................................................. 4

2.4

Estilos Arquiteturais ....................................................................................................... 9

2.5

Documentao de Arquiteturas..................................................................................... 11

2.5.2

Vises Arquiteturais .............................................................................................. 11

2.5.3

Documentao de Interfaces .................................................................................. 13

Arquitetura para Servios Web ....................................................................................... 15

3.1

Introduo .................................................................................................................... 15

3.2

Arquitetura ................................................................................................................... 16

3.3

Modelos de Arquitetura de Servios Web ..................................................................... 19

3.3.1

Modelo Orientado a Mensagens ............................................................................. 20

3.3.2

Modelo Orientado a Servio .................................................................................. 20

3.3.3

Modelo Orientado a Recursos ................................................................................ 21

3.3.4

Modelo de Policiamento ........................................................................................ 22

iii

3.4

Tecnologias para Servios Web .................................................................................... 22

3.5

Integrao e Operaes entre as Entidades ................................................................... 27

Arquitetura REST ............................................................................................................ 30

4.1 Fundamentao Bsica ................................................................................................... 30
4.1.1 Null Style .................................................................................................................. 30
4.1.2 Cliente-servidor ........................................................................................................ 31
4.1.3 Sem Estado ............................................................................................................... 31
4.1.4 Cache ........................................................................................................................ 32
4.1.5 Interface Uniforme .................................................................................................... 32
4.1.6 Separao em Camadas ............................................................................................. 33
4.1.7 Cdigo Sob Demanda ............................................................................................... 33
4.2 Elementos Arquiteturais REST....................................................................................... 34
4.2.1 Elementos de Dados .................................................................................................. 34
4.2.1.1 Recursos e Identificadores de Recursos ................................................................ 35
4.2.1.2 Representao ...................................................................................................... 35
4.2.2 Conectores ................................................................................................................. 36
4.2.3 Componentes ............................................................................................................. 38
4.2 Vises Arquiteturais REST ............................................................................................. 39
4.2.1 Vises de Processo.................................................................................................... 39
4.2.2 Vises de Conectores ................................................................................................ 40
4.2.3 Vises de Dados ....................................................................................................... 40
4.3 Arquitetura Orientada a Recursos .................................................................................... 41
4.3.1 Recursos ................................................................................................................... 41
4.3.2 Endereamento ......................................................................................................... 42
4.3.3 Sem-Estado ............................................................................................................... 42
4.3.4 Representaes ......................................................................................................... 43
4.3.5 Ligaes e Conectividade .......................................................................................... 44
4.3.6 Interface Uniforme .................................................................................................... 44
4.4 Servios Web segundo o modelo REST .......................................................................... 45
iv

Exemplos de Aplicao ..................................................................................................... 48

5.1 Exemplo de abordagem tradicional de Servios Web .................................................... 48
5.2 Exemplo de Servios Web RESTFul ............................................................................. 52
5.3 Organizaes que utilizam ............................................................................................ 58
5.4 Consideraes ............................................................................................................... 59

Concluso .......................................................................................................................... 62

Lista de Redues
XML

Extensible Markup Language

WSDL

Web Services Description Language

SOAP

Simple Object Access Protocol

OASIS

Organization for the Advancement of Structured Information Standards

HTTP

Hypertext Transfer Protocol

DSSA

Domain-Specific Software Architecture

ADL

Architecture Description Language

SEI

Software Engineering Institute

UML

Unified Modeling Language

W3C

World Wide Web Consortium

DCOM

Distributed Component Object Model

CORBA

Common Object Request Broker Architecture

RMI

Remote Method Invocation

REST

Representational State Transfer

WSA

Web Service Architecture

WSD

Web Service Description

UDDI

Universal Description, Discovery and Integration

URI

Uniform Resource Identifier

vi

Lista de Figuras
Figura 2.1 Nveis de descrio de um sistema ............................................................................ 5
Figura 2.2 Principais linguagens de descrio arquitetural ......................................................... 7
Figura 2.3 Exemplo de descrio ACME.................................................................................... 8
Figura 2.4 Principais Estilos Arquiteturais ............................................................................... 10
Figura 2.5 reas de Interesse dos Estilos Arquiteturais ........................................................... 10
Figura 3.1 Processo Geral de um Servio Web ........................................................................ 16
Figura 3.2 Relacionamento entre um WSD e seus agentes ....................................................... 18
Figura 3.3 Modelos da Arquitetura de Servios Web ............................................................... 19
Figura 3.4 Esquema Simplificado do Message Oriented Model ................................................ 20
Figura 3.5 Esquema simplificado do Service Oriented Model ................................................... 21
Figura 3.6 Esquema simplificado do Resource Oriented Model ................................................ 21
Figura 3.7 Esquema simplificado do Policy Model ................................................................... 22
Figura 3.8 Tecnologias Relacionadas aos Servios Web .......................................................... 23
Figura 3.9 Estrutura da mensagem SOAP ................................................................................. 24
Figura 3.10 Exemplo de mensagem SOAP .............................................................................. 25
Figura 3.11 Estrutura de um documento WSDL ...................................................................... 25
Figura 3.12 Exemplo de um documento WSDL ...................................................................... 26
Figura 3.13 Interao entre as tecnologias Web Services ......................................................... 27
Figura 3.14 Operaes entre as entidades relacionadas ............................................................ 28
Figura 4.1 Null Style ................................................................................................................ 31
Figura 4.2 Estilo Arquitetural Cliente-Servidor ....................................................................... 31
Figura 4.3 Estilo Arquitetural Cliente-servidor Sem Estado ...................................................... 32
Figura 4.4 Elementos de Dados REST ..................................................................................... 35
Figura 4.5 Conectores REST .................................................................................................... 37
Figura 4.6 Componentes REST ................................................................................................ 38
Figura 4.7 Mtodos do protocolo HTTP utilizados pela Arquitetura Orientada a Recursos ...... 45
Figura 4.8 Invocao e resposta de um mtodo pela viso tradicional de Servios Web ........... 46
Figura 4.9 Invocao e resposta de um mtodo pela viso REST de Servios Web .................. 47
vii

Figura 5.1 Classe Filme.java .................................................................................................... 49

Figura 5.2 Classe FilmeWS.java .............................................................................................. 49
Figura 5.3 Arquivo FilmeWS.wsdl ........................................................................................... 50
Figura 5.4 Classe FilmeMain.java ............................................................................................ 51
Figura 5.5 Sada da execuo da classe FilmeMain.java ........................................................... 51
Figura 5.6 Arquivo web.xml da aplicao ................................................................................ 52
Figura 5.7 Classe Filme.java .................................................................................................... 53
Figura 5.8 Classe de Recurso FilmeResource.java .................................................................... 54
Figura 5.9 Classe de teste FilmeMain.java................................................................................ 56
Figura 5.10 Sada da execuo da classe de teste FilmeMain.java............................................. 57
Figura 5.11 Requisio do tipo GET atravs de um Web Browser ............................................ 58

viii

Resumo
A Arquitetura de Servios Web surgiu para permitir a interoperabilidade entre aplicaes
rodando em diferentes plataformas. Ela foi especificada com base em um protocolo que
encapsula as mensagens SOAP (Simple Object Access Protocol) e em uma linguagem que
descreve as interfaces dos servios, conhecida como WSDL (Web Services Description
Language). A forma tradicional pela qual os servios web so implementados hoje em dia, que
segue aos padres citados, gera uma camada de abstrao que envolve o protocolo HTTP.
Este trabalho tem por finalidade apresentar os conceitos e tecnologias que envolvem uma
nova abordagem no contexto de implementao de servios o paradigma REST. Criado a
partir da tese de doutorado de Roy Fielding e baseado em outros estilos arquiteturais, tem como
principal meta a simplicidade e o desempenho das aplicaes. Alm disso, este trabalho aborda
uma aplicao prtica dos conceitos arquiteturais de REST a Arquitetura Orientada a
Recursos que permite transformar um problema em uma aplicao REST atravs do emprego
de URIs, HTTP e XML.

ix

Abstract
The architecture of Web services has emerged to allow interoperability between
applications running on different platforms. It was specified based on a protocol that
encapsulates messages - SOAP (Simple Object Access Protocol) and in a language that
describes the interfaces of services, WSDL (Web Services Description Language). The
traditional way in which web services are implemented today is a layer of abstraction that
includes the HTTP protocol.
This paper aims to present the concepts and technologies that involve a new approach for
implementation of services - the REST paradigm. Created by Roy Fielding in his thesis, it uses
some architectural styles in order to get applications simplicity and better performance.
Moreover, this paper addresses a practical application of REST architectural concepts - the
Resource Oriented Architecture - which allows transforming a problem in an REST application
through the use of URI, HTTP and XML.

1 Introduo
A complexidade dos softwares vem aumentando muito rapidamente de forma que as tcnicas
para lidar com os problemas existentes - conhecidas como tcnicas de abstrao - j se tornaram
insuficientes para lidar com os desafios da nova gerao de sistemas. Uma destas tcnicas de
abstrao a modularizao de um sistema. Dessa forma, todo sistema de software de alto
nvel de abstrao pode ser descrito por meio de subsistemas ou mdulos inter-relacionados. O
papel de analisar as propriedades de cada subsistema ou mdulo atribudo arquitetura de
software.
Com o surgimento de vrias arquiteturas de software, fez-se necessria a categorizao
das mesmas de acordo com suas caractersticas, componentes e propriedades peculiares. Dessa
forma, as classes de arquiteturas foram sendo classificadas em seus respectivos estilos
arquiteturais. Concomitante ao surgimento dos estilos arquiteturais surgiu uma arquitetura com
o objetivo de permitir a interoperabilidade entre aplicaes e sistemas de plataformas,
ambientes e arquiteturas diferentes a Arquitetura de Servios Web.
A abordagem tradicional do uso de Servios Web utiliza uma interface descrita em um
formato especfico - WSDL (Web Services Description Language). Essa interface permite que
sistemas interajam com um servio Web atravs de mensagens em um formato especfico,
conhecido como SOAP (Simple Object Access Protocol), normalmente enviadas utilizando
HTTP. Dessa forma, os servios esto escondidos por trs dos mtodos que podem ser
invocados remotamente.

1.1 Motivao
O surgimento da Arquitetura de Servios Web tornou possvel a interoperabilidade entre
aplicaes heterogneas. Porm, muitas vezes o desempenho do sistema comprometido,
devido ao tamanho das mensagens envelopadas no protocolo SOAP.
No entanto, surgiram algumas alternativas que podem melhorar o desempenho das
1

aplicaes com servios Web. Uma destas alternativas e a que tem sido mais focada atualmente
a arquitetura orientada a recursos, baseada no paradigma REST Representational State
Transfer.

1.2 Objetivos
O objetivo deste trabalho estudar os conceitos relacionados ao estilo REST e a
Arquitetura Orientada a Recursos, suas vantagens, desvantagens e, sobretudo suas diferenas
em relao abordagem tradicional de manipulao de Servios Web.

1.3 Organizao do trabalho

Este trabalho, alm desta introduo, apresenta o conceito e papel da Arquitetura de
Software no captulo 2, onde ainda so conceituados e exemplificados estilos arquiteturais, uma
viso geral de Linguagens de Descrio Arquitetural e de Documentao de Arquiteturas.
Em seguida, no captulo 3, a Arquitetura de Servios Web apresentada de acordo com
a sua especificao. So abordadas as tecnologias de Servios Web existentes e os modelos de
Arquiteturas definidas pela especificao.
J o captulo 4 conceitua o estilo REST atravs do processo de derivao do mesmo
como um estilo arquitetural. Apresenta tambm a Arquitetura Orientada a Recursos, uma
aplicao prtica dos conceitos por trs do REST.
O captulo 5 ilustra um exemplo de uma consulta um acervo de filmes por ambas as
abordagens viso tradicional e REST. O captulo 6 apresenta concluses tiradas a partir do
conhecimento adquirido com o presente trabalho.

2 Arquitetura de Software

2.1 Histrico

Atualmente, cada vez mais o computador vem representando para as pessoas e instituies uma
ferramenta essencial e imprescindvel para a realizao de suas atividades, desde as mais bsicas
at as complexas. Concomitante a essa crescente dependncia dos sistemas computacionais, a
complexidade dos softwares vem aumentando to rapidamente que as tcnicas para lidar com a
complexidade de problemas existentes - conhecidas como tcnicas de abstrao - j se tornaram
insuficientes para lidar com os desafios da nova gerao de sistemas.
O crescimento contnuo do tamanho e da complexidade dos sistemas requer cada vez mais
atributos tais como confiabilidade, desempenho e manutenibilidade. A confiabilidade
fundamental para garantir que o sistema realizar as tarefas conforme o esperado e pode ser
medida de forma estatstica atravs da anlise do comportamento do sistema durante um
determinado perodo de tempo [MENDES, 2003]. O desempenho tambm tem se tornado um
fator crtico, devido principalmente s novas necessidades dos sistemas. J a manutenibilidade se
desmembra em dois aspectos distintos: reparo em funcionalidades (correo de erros) e evoluo
do sistema (insero de novos requisitos). Dessa forma, com o passar do tempo, todo e qualquer
sistema precisar de manuteno.
A Engenharia de Software surgiu com o propsito de lidar com esses problemas. Porm,
eles vo alm do mbito das estruturas de dados e dos algoritmos utilizados nos sistemas. Tornase ento imprescindvel, principalmente em sistemas de grande porte, projetar a estrutura global
do sistema antes de inici-lo, ou seja, desenvolver o software orientado a uma arquitetura. Foi
ento a partir da necessidade de um projeto arquitetural para os sistemas que surgiu o interesse
em Arquitetura de Software.

2.2 Conceito e Papel da Arquitetura de Software

De acordo com o livro An Introduction to Software Architecture, (David Garlan e Mary
Shaw - 1994), a arquitetura de software surgiu para resolver questes que vo "alm dos
algoritmos e das estruturas de dados da computao. O projeto e a especificao da estrutura
global de um sistema emergem como um problema importante. As questes estruturais incluem
organizao total e estrutura de controle global; protocolos de comunicao, sincronizao e
acesso aos dados; atribuio de funcionalidades a elementos de design; distribuio fsica;
composio de elementos de design; escalonamento e desempenho; e seleo entre as alternativas
de design".
Em 1995, David Garlan e Dewayne Perry definiram a arquitetura de software como: "A
estrutura dos componentes de um programa/sistema, seus inter-relacionamentos, princpios e
diretrizes guiando o projeto e evoluo ao longo do tempo" [BUSCHMANN, 1996] .
A Arquitetura de Software pode ser entendida, de maneira geral, como o estudo da
organizao global dos sistemas de software e das inter-relaes entre seus subsistemas e
componentes. Todo sistema de software de alto nvel de abstrao que for projetado seguindo
alguma arquitetura pode ento ser descrito por meio de subsistemas ou mdulos interrelacionados. O papel da arquitetura de software analisar as propriedades de cada subsistema ou
mdulo. Isso proporciona, entre outras vantagens, o desenvolvimento de linhas de produto de
software das quais podem ser criados vrios sistemas com funcionalidades distintas. Essa
prtica conhecida como arquitetura de referncia ou DSSA (Domain Specific Software
Architecture) [MENDES, 2002] e utiliza conceitos como reuso com base em componentes,
classes de componentes, entre outros.
A utilizao de uma arquitetura no gerenciamento do processo de software pode tambm
prover suporte para a estimativa de custos e na gerncia do processo e principalmente pode atuar
como a estrutura principal para atender aos requisitos do sistema [MENDES, 2002]. Para
entender melhor o seu papel, a figura 2.1 ilustra o afunilamento nas descries arquiteturais de
um sistema atravs das fases do processo de desenvolvimento do software, que comea pela
concepo do sistema, passa pela anlise e aceitao dos requisitos e vai at sua efetiva
implementao.

Figura 2.1 Nveis de descrio de um sistema [Mendes, adaptado, 2003]

Conforme apresentado na figura 2.1, a fase inicial no requer nenhuma tomada de deciso
no mbito arquitetural e responsvel pela decomposio das funcionalidades do sistema em
mdulos. A compreenso das funcionalidades pode ser feita atravs da anlise dos servios
oferecidos por sistemas similares. Durante a fase final, a anlise do sistema em mdulos permite
encontrar a arquitetura ideal que satisfaa s reais necessidades do sistema dentre a gama de
arquiteturas de referncia disponveis na fase intermediria.
Analisando as fases como um todo, a arquitetura de um sistema engloba o
particionamento das funes entre subsistemas ou mdulos e a interao entre eles. Portanto, a
arquitetura composta de subsistemas ou componentes, conectores (interligando os compontes),
e de padres de conexo (tipos de interao e compartilhamento de informaes entre esses
componentes). Durante o desenvolvimento do software, vrias questes so levantadas no
processo de modularizao do sistema e as suas respostas so fundamentais para a construo de
uma boa soluo. A funo de avaliar essas questes e decidir qual alternativa a melhor para
cada situao-problema atribuda a um profissional especializado, o arquiteto de software.
Ao arquiteto de software cabe tomar as decises tcnicas, liderar, coordenar as atividades
e os artefatos tcnicos no decorrer do projeto. Porm, a viso do arquiteto deve ser ampla - e no
detalhada - pois ele deve ter um conhecimento geral do sistema em um nvel alto de abstrao.
Uma arquitetura de software pode ser especificada utilizando duas abordagens principais:
5

Linguagens de Descrio Arquiteturais e/ou Estilos Arquiteturais. Sero detalhadas a seguir estas
duas abordagens.

2.3 Linguagem de Descrio Arquitetural (ADL - Architectural

Description Language)
A partir da necessidade natural de representar de forma lingustica as arquiteturas de
software principalmente visando facilitar a comunicao entre os envolvidos nos projetos,
surgiram as ADLs (em portugus, LDAs Linguagens de Descrio Arquitetural). As linguagens
de descrio arquitetural possibilitam a descrio de um sistema em um alto nvel de abstrao,
oferecem uma base formal para a descrio e anlise do comportamento do sistema e tm a
pretenso de serem entendidas no s por humanos, mas tambm por mquinas [CHAVEZ,
2009].
Outra vantagem proporcionada pelo uso de ADLs a reusabilidade, pois elas podem
prover, em situaes especficas, a gerao automtica de sistemas. Cada ADL define a natureza
e propriedades do componente, a semntica das conexes e o comportamento do sistema como
um todo.
Segundo o Software Engineering Institute (SEI) [SEI, 2009], as principais linguagens de
descrio arquitetural so (figura 2.2):

Figura 2.2 Principais linguagens de descrio arquitetural [SEI, adaptado, 2009]

A seguir ser abordada mais detalhadamente uma das ADLs citadas a linguagem
Acme, que surgiu a partir da necessidade de um padro frente proliferao de ADLs que
surgiram, cada uma com suas capacidades especficas.

Acme
Acme uma linguagem simples e genrica para a descrio de arquiteturas que pode ser
usada como ferramenta para converter formatos de design e/ou como base para desenvolver
novas arquiteturas e ferramentas de anlise.
A linguagem Acme surgiu em 1995 a partir de contribuies e feedbacks de alguns
membros da comunidade de projeto de arquiteturas. Os princpios da linguagem e os trabalhos
para desenvolvimento de ferramentas foram financiados por um grupo da Carnegie Mellon
University aliado a outros colaboradores. Surgiu com o objetivo de fornecer uma linguagem que
pudesse ser utilizada como suporte para troca de arquiteturas entre diferentes ferramentas de
design de arquiteturas [ACME, 2009].
A linguagem possui trs caractersticas principais:

Descrio de arquiteturas: a linguagem fornece um conjunto de construtores para

7

descrever a estrutura, tipo e estilo das arquiteturas e as propriedades dos elementos

que compem as mesmas.

Troca de arquitetura: atravs de um formato de trocas genrico para design de

arquiteturas, a Acme permite a integrao de ferramentas desenvolvidas com
outras ferramentas complementares.

Extensibilidade para projeto de novas arquiteturas e ferramentas de anlise: a

soluo fornecida pela Acme fornece uma base slida e extensvel que evita a
reconstruo de infraestruturas padro. Dessa forma torna-se possvel desenvolver
ferramentas usando Acme como linguagem de representao nativa, sendo
compatvel com diversas ADLs e ferramentas sem esforos adicionais de
integrao.

O site do projeto (http://www.cs.cmu.edu/~acme/) oferece uma introduo e uma viso

geral do projeto Acme, tais como a especificao da linguagem, artigos, exemplos e downloads
das bibliotecas e ferramentas.
A figura 2.3 ilustra um exemplo de uma descrio ACME. O componente cliente
declarado para se ter uma porta nica para a requisio e outra somente para a resposta. O
conector desempenha dois papis: chamador e chamado (caller e callee). A topologia deste
sistema declarada atravs da lista de anexos [ACME, 2009].

Figura 2.3 Exemplo de descrio ACME [ACME, 2009]

Porm, a maioria dos trabalhos relacionados a ADLs atualmente ainda tem objetivos
acadmicos e so relativamente difceis de analisar, pois ainda no h um entendimento universal
no que se refere ao que uma ADL deve representar (no que diz respeito ao comportamento do
8

sistema).
Alm disso, as representaes de ADLs usadas hoje em dia no so suportadas por
ferramentas comerciais e a maioria delas muito focada em um determinado tipo de anlise.

2.4 Estilos Arquiteturais

A partir da necessidade natural de organizar o conhecimento de projeto de software de
maneira til para uma possvel reutilizao, as arquiteturas de software foram sendo
caracterizadas e, de acordo com suas caractersticas, componentes e propriedades peculiares,
foram catalogadas. Dessa forma, classes de arquiteturas (ou famlias) foram sendo identificadas
de acordo com os aspectos caractersticos a elas, culminando no surgimento dos estilos
arquiteturais.
Para determinar um estilo arquitetural que retrata a arquitetura de software do sistema, um
profissional de software deve determinar a classe a qual pertence a organizao de um sistema.
Para isso, so definidas caractersticas dos componentes (e os mecanismos de interao entre
eles) e conectores do sistema, a topologia da arquitetura, entre outros.

2.4.1 Conceito e Propriedades

Shaw e Garlan [GARLAN; SHAW, 1994] definiram estilos arquiteturais como "Padres
ou idiomas de projeto que guiam a organizao de mdulos e subsistemas em sistemas
completos". J Medvidovic [MEDVIDOVIC, 2000] definiu como "idiomas de projeto chave que
permitem a explorao de padres estruturais e evolutivos adequados e que facilitam a
reutilizao de componentes, conectores e processo".
O Application Architecture Guide 2.0 (Microsoft patterns and pratices) [MICROSOFT,
2009], lista alguns dos estilos arquiteturais mais relevantes, descritos na figura 2.4.

Figura 2.4 Principais Estilos Arquiteturais [MICROSOFT, adaptado, 2008]

Cada um desses estilos arquiteturais pode ser classificado de acordo com as reas
especficas de interesse de cada um. A figura 2.5 agrupa os estilos em reas de interesse:

Figura 2.5 reas de Interesse dos Estilos Arquiteturais [MICROSOFT, adaptado, 2008]

10

Existem tambm outros estilos arquiteturais que no foram classificados originalmente,

tais como: Peer-to-Peer [VERMA, 2004], Shared Nothing Architecture [STONEBRAKER,
1986] e REST (Representational State Transfer) [FIELDING, 2000].

2.5 Documentao de Arquiteturas

Alm de tcnicas para criar e avaliar arquiteturas de software, o SEI (Software
Engineering Institute) desenvolve tcnicas para document-las.
O foco da comunidade de engenharia de software se voltou para documentao de
arquiteturas a partir de uma necessidade percebida pelo SEI de uma representao formal das
mesmas, pois muitas vezes as arquiteturas criadas no so documentadas (e conseqentemente
comunicadas) de forma efetiva. Isso faz com que os envolvidos com o sistema no tenham acesso
a uma representao adequada da arquitetura.
Baseado nessa necessidade, o principal motivo pelo qual as arquiteturas de software
devem ser documentadas que a documentao representa o artefato principal em todas as fases
do desenvolvimento de sistemas [MERSON, 2006].

2.5.2 Vises Arquiteturais

Neste contexto, o SEI destaca a documentao de arquiteturas atravs de mltiplas views.
Uma view representa uma perspectiva da arquitetura e contm elementos e relaes entre os
elementos. A definio de quais tipos de elementos e as relaes de cada view servem de base
para criar uma organizao padro para a documentao da arquitetura [MERSON, 2006].
A questo mais importante a ser considerada no contexto das views como identificar
quais delas merecem ser documentadas. Para auxiliar nessa tarefa, as views foram classificadas
em cinco categorias: Module Views, Runtime Views, Deployment Views, Implementation Views e
Data Model.

Module Views

As module views mostram a estrutura do sistema em termos de unidades de cdigo, ou

11

seja, representam a planta (blue prints) para a construo do software. A notao mais utilizada
para representar as module views so os diagramas UML mais especificamente os diagramas de
classes. Atravs deles, o sistema decomposto em mdulos e as dependncias e hierarquias entre
eles so representadas nos diagramas.

Runtime Views

As Runtime Views representam um raio-x do sistema em execuo e so teis para

entender o funcionamento do sistema e analisar algumas propriedades que se manifestam
somente em tempo de execuo, como por exemplo desempenho. As notaes usadas para
representar runtime views geralmente so informais com a utilizao de caixas e linhas, embora a
UML tenha definido alguns tipos de elementos e relaes que facilitam a criao de runtime
views.

Implementation Views

As Implementation Views so responsveis por exibir a estrutura do software (como ou

como dever ser) em termos de arquivos, pacotes e diretrios, tanto para o ambiente de
desenvolvimento quanto para de produo.
Notaes informais so tambm muito utilizadas na representao de implementation
views, embora a notao UML seja uma alternativa atraente.

Deployment Views

Uma Deployment View mostra a estrutura de hardware na qual o sistema executado,

geralmente uma rede. Tambm possui as notaes formal e informal, sendo a informal mais
utilizada.

Data Model

Os Data Models normalmente so usados para representar bases de dados cuja estrutura
12

precisa ser modelada. O data model inicia como um modelo conceitual/lgico que vai sendo
refinado at conter todas as informaes necessrias para a criao da base de dados fsica.
A notao mais utilizada para esse tipo de view a de diagramas UML de entidaderelacionamento, nos quais as classes contenham apenas atributos e nenhum mtodo.

Durante o processo de documentao de arquiteturas, o nmero de views e de seus

elementos pode aumentar tanto a ponto de tornar impraticvel manter todas as informaes em
uma s view. A tcnica usada para particionar o design em mdulos que possam ser visualizados,
editados e entendidos separadamente conhecida como tcnica do refinamento [CLEMENT,
2001].
O refinamento pode ser feito de duas maneiras diferentes: a primeira ocorre quando uma
viso composta de muitos elementos e ento a view particionada em duas ou mais views, cada
uma contendo um subconjunto de elementos. Neste caso as novas views criadas so irms. A
segunda forma de refinamento mais comum: quando uma determinada view possui um
elemento muito complexo, criada outra view para mostrar a estrutura interna desse elemento.
Neste caso a nova view criada filha da original.

2.5.3 Documentao de Interfaces

Embora no seja muito comum a documentao de interfaces, ela necessria, pois a
descrio de uma interface considerada tambm uma informao arquitetural, pois expe
detalhes essenciais integrao daquele componente ao restante do sistema ou at mesmo a
sistemas externos [CLEMENT, 2001].
Uma questo importante quais itens so relevantes para serem documentados em uma
interface. Merson [MERSON, 2006] sugere sete dos dez itens listados por Clement [CLEMENT,
2001]:

Nome e descrio da interface;

Mtodos/Funes/Operaes disponveis (sintaxe, descrio, restrio de uso e excees);

Tipos de dados e constantes;

Guia de Variabilidade
13

Atributos de Qualidade

Decises de Projeto

Exemplos de uso

Como apresentado no presente captulo, os estilos arquiteturais surgiram para guiar a

organizao de mdulos e subsistemas em sistemas completos. Os estilos foram classificados de
acordo com as respectivas reas de interesse de arquiteturas de software j existentes.
Alm da escolha de um estilo arquitetural no desenvolvimento de um sistema, tambm
importante a utilizao de uma linguagem de descrio arquitetural, que tem como principais
vantagens a comunicao efetiva entre os envolvidos no projeto e a reutilizao.
Porm, independente do foco do estilo arquitetural, indispensvel conhecer como a
arquitetura de software e os estilos surgiram e a importncia da documentao da arquitetura
selecionada em todas as fases do projeto de software, atravs da utilizao diferentes perspectivas
da arquitetura views.

14

3 Arquitetura para Servios Web

3.1 Introduo
De acordo com a definio do World Wide Web Consortium (W3C) [W3C, 2009], um servio
Web "um sistema de software responsvel por proporcionar a interao entre duas mquinas
diferentes atravs de uma rede. Para possibilitar essa interao, utiliza uma interface descrita em
um formato especfico - WSDL (Web Services Description Language). Essa interface permite
que sistemas interajam com um servio Web atravs de mensagens SOAP (Simple Object Access
Protocol) ou de outros protocolos, normalmente enviadas utilizando HTTP com uma serializao
em XML em conjunto com outros padres utilizados na Web" [W3C, 2009]. Esses padres sero
detalhados mais adiante.
O W3C um consrcio de empresas de tecnologia que cria padres comuns para o
contedo da Web e apoiado por grandes empresas como Microsoft, IBM, HP, entre outras. No
final do ano 2000 foi criado um grupo no W3C com propsito de desenvolver uma arquitetura
que permitisse a interoperabilidade entre aplicaes e sistemas de plataformas, ambientes e
arquiteturas diferentes. Alguns padres foram propostos, como o DCOM (Distributed Component
Object Model) [DCOM, 2009], CORBA (Common Object Request Broker Architecture)
[CORBA, 2009], e RMI (Remote Method Invocation) [RMI, 2009]. Porm as abordagens j
existentes foram bem sucedidas somente na integrao de redes locais e tiveram muitas
limitaes quando foram transpostas para sistemas de grande porte rodando sobre a Web,
principalmente devido independncia de plataforma que deixou a desejar.
Visando atender a essas necessidades, foi proposta uma arquitetura computacional voltada
para servios Web, que tornou possvel a interao entre diferentes tipos de aplicaes mesmo
rodando em plataformas e sistemas operacionais diferentes.
O objetivo deste trabalho apresentar, de forma comparativa, um novo estilo de
15

implementao de servios web REST.

3.2 Arquitetura
A arquitetura de Servios Web descrita neste trabalho tomou como base a referncia
arquitetural do W3C, o WSA (Web Service Architecture) [WSA, 2004] e ir fornecer uma
definio comum de servios Web, atravs de um modelo conceitual e um contexto no qual os
componentes da arquitetura sero inter-relacionados. importante ressaltar que este trabalho no
tem a inteno de mostrar como os servios Web devem ser implementados e sim de descrever as
caractersticas arquiteturais mnimas comuns a todos eles.
A figura 3.1 ilustra o processo geral de um Servio Web.

Figura 3.1 Processo Geral de um Servio Web [WSA, 2004]

H muitas maneiras pelas quais uma entidade pode acessar e usar um Servio Web. Em
geral, os passos necessrios ilustrados na figura 3.1 so:

1. As entidades Requester e Provider tornam-se conhecidas (ou pelo menos uma se

torna conhecida da outra).
16

2. As entidades Requester e Provider chegam a um acordo em relao ao WSD e a

semntica que ir coordenar a interao entre os agentes.
3. O WSD e a semntica so consumados pelos agentes.
4. As entidades Requester e Provider trocam mensagens, atravs de seus
respectivos agentes.

Apresentamos a seguir uma breve descrio dos principais componentes presentes na

interao com um servio Web.

a) Agentes e Servios

Um servio Web uma noo abstrata que deve ser implementada por um agente
concreto. O agente um mdulo de software ou hardware responsvel por receber ou enviar
mensagens, enquanto o servio caracterizado pelo conjunto de funcionalidades que sero
fornecidas. A diferena entre um agente e um servio pode ser visualizada mais claramente se um
servio Web for implementado usando um agente com diferentes linguagens de programao,
porm com a mesma funcionalidade. Dessa forma, o Servio Web permaneceria o mesmo
[MEDYK, 2006].
Basicamente, um agente pode ser entendido como a concretizao da noo abstrata (que
nesse contexto representa um servio). Em termos de padres de projeto, um servio representa
uma interface a ser implementada por uma classe concreta, representada por um agente.

b) Requisitores (Requesters) e Provedores (Providers)

A proposta de um servio Web fornecer uma determinada funcionalidade em nome de

alguma pessoa ou organizao. A entidade Provider a pessoa ou organizao que fornece o
agente adequado para implementar um determinado servio, enquanto a entidade Requester a
pessoa ou organizao que faz uso da entidade Provider.
Um Requester Agent usado para a troca de mensagens com o Provider Agent. Ambos
podem iniciar a troca de mensagens. Porm, na maioria dos casos, quem inicia a troca o
Requester Agent. Para garantir a troca de mensagens, as entidades precisam definir e acordar o
17

que o padro de servios Web chama de semntica [MEDYK, 2006].

c) Descrio do Servio

Os mecanismos de troca de mensagens so documentados em um Service Description

(descrio do servio). O WSD (Web Service Description) uma especificao para a interface
do servio Web, implementadas atravs de uma WSDL (Web Service Description Language).
A WSDL define os padres dos formatos das mensagens, tipos de dados, protocolos de
transportes, e formatos da serializao do transporte usados para a comunicao entre os agentes
Requester e Provider. Mais adiante, um tpico abordar especificamente WSDL. De forma geral,
o WSD representa um acordo de interao com um determinado servio. A figura 3.2 ilustra o
relacionamento entre um documento WSD e os agentes. [WSA, W3C]

Figura 3.2 Relacionamento entre um WSD e seus agentes [WSA, 2004]

d) Semntica

A semntica de um Servio Web a expectativa compartilhada a respeito do

comportamento do servio, em particular a resposta para as mensagens que so enviadas aos

18

servios. Este o contrato entre a entidade Requester e a entidade Provider a respeito da proposta
e conseqncias da interao.
Embora este contrato represente um acordo geral entre as duas entidades em como e
porqu seus respectivos agentes iro interagir, ele no necessariamente implementado ou
explicitamente negociado. Ele pode ser explcito ou implcito, oral ou escrito e atravs de um
acordo legal ou informal.

3.3 Modelos de Arquitetura de Servios Web

O papel principal de um modelo explicar e encapsular um tema relevante dentro da
arquitetura. Embora diferentes modelos compartilhem alguns conceitos gerais, eles geralmente
so gerados a partir de diferentes pontos de vista. Na arquitetura definida pelo W3C, existem
quatro modelos utilizados por servios Web [WSA, 2004].
A figura 3.3 ilustra os quatro modelos e as suas inter-relaes. Cada modelo rotulado
como deve ser visualizado, a partir do conceito-chave do mesmo.

Figura 3.3 Modelos da Arquitetura de Servios Web [WSA, 2004]

A seguir, cada um dos quatro modelos ilustrados na figura acima ser detalhado.

19

3.3.1 Modelo Orientado a Mensagens

O Message Oriented Model (Modelo Orientado a Mensagens) foca em aspectos da
arquitetura que esto relacionados com o processamento de mensagens, como, por exemplo, sua
estrutura, o modo de transporte, entre outros aspectos relevantes [MEDYK, 2006]. A figura 3.4
ilustra um esquema simplificado do modelo.

Figura 3.4 Esquema Simplificado do Message Oriented Model [WSA, 2004]

3.3.2 Modelo Orientado a Servio

O Service Oriented Model (Modelo Orientado a Servios) foca nos aspectos servio e
ao. Em sistemas distribudos, os servios podem no ser perfeitamente adequados se no
houver uma modelagem da estrutura das mensagens utilizadas. Porm, o oposto possvel, j que
as mensagens no precisam necessariamente estar atreladas a servios. A figura 3.5 ilustra um
esquema simplificado do modelo [MEDYK, 2006].

20

Figura 3.5 Esquema simplificado do Service Oriented Model [WSA, 2004]

3.3.3 Modelo Orientado a Recursos

O Resource Oriented Model (Modelo Orientado a Recursos) foca nos recursos e
reutilizado da arquitetura web, o qual expandida para o conceito de servios Web para
incorporar o relacionamento entre os recursos e as entidades que os fornecem. A figura 3.6 ilustra
um esquema simplificado do modelo [MEDYK, 2006].
Foi a partir do conceito comum de recursos do modelo orientado a recursos que surgiu o
estilo REST e a arquitetura orientada a recursos.

Figura 3.6 Esquema simplificado do Resource Oriented Model [WSA, 2004]

21

3.3.4 Modelo de Policiamento

O Policy Model (Modelo de Policiamento) foca no comportamento dos agentes e servios.
Os recursos do modelo so generalizados uma vez que o policiamento vigilncia do
comportamento pode ser aplicado igualmente a documentos, descries do servio, e a recursos
computacionais. A figura 3.7 ilustra um esquema simplificado do modelo [MEDYK, 2006].

Figura 3.7 Esquema simplificado do Policy Model [WSA, 2004]

O policiamento se aplica sobre os recursos. Este modelo aplicado sobre agentes que
necessitam acessar diretamente estes recursos e estabelecido pelo administrador dos mesmos. O
modelo se relaciona com outros aspectos, tais como polticas de segurana, gerenciamento e
aplicaes.

3.4 Tecnologias para Servios Web

A arquitetura para servios Web envolve muitas camadas e tecnologias inter-relacionadas.
H diversas formas de visualiz-las, da mesma forma como existem muitas formas de
implementao de Servios Web. A figura 3.8 ilustra de forma geral as tecnologias relacionadas
aos Servios Web [W3C, 2009].

22

Figura 3.8 Tecnologias Relacionadas aos Servios Web [W3C, 2009]

A seguir as principais tecnologias presentes na figura acima sero detalhadas.

XML (eXtensible Markup Language)

XML uma linguagem de marcao criada pelo W3C a partir do SGML (Standard
Generalized Markup Language). Por oferecer padronizao, flexibilidade e a possibilidade de
descrever classes com diversos tipos de dados, o uso de XML reduziu significativamente os
custos de desenvolvimento. Estas classes de dados so documentos XML. [XML, W3C]
O objetivo principal da linguagem facilitar o compartilhamento de informaes pela
Web, podendo ser usado tambm por servios Web.

SOAP (Simple Object Access Protocol)

SOAP um protocolo baseado em XML para a troca de informaes estruturadas em

ambientes distribudos [MEDYK, 2006]. O protocolo prov uma forma de possibilitar a
passagem de comandos e parmetros entre as entidades Requester e Provider, independente da
plataforma de implementao ou de linguagem de programao utilizada.
A descrio das mensagens utilizando SOAP e o protocolo de comunicao utilizado
23

(geralmente HTTP - Hypertext Transfer Protocol) formam a camada fundamental de

comunicao dos servios Web [MEDYK, 2006].
Uma mensagem SOAP, como ilustrada da figura 3.9, consiste basicamente nos seguintes
elementos:
1. Envelope: o elemento raiz do documento XML. Toda mensagem SOAP deve
cont-lo.
2. Header: um cabealho opcional. Quando utilizado, o header deve ser o primeiro
elemento do envelope.
3. Body: um elemento obrigatrio e contm o payload (informao a ser
transportada para o seu destino final). Pode conter um elemento opcional fault,
usado para carregar mensagens de status e erros retornados pelos ns ao
processarem a mensagem.

Figura 3.9 Estrutura da mensagem SOAP [MEDYK, 2006]

A figura 3.10 ilustra um exemplo de mensagem de requisio SOAP. O corpo da
mensagem contm os dados necessrios busca do preo do livro informado.

24

Figura 3.10 Exemplo de mensagem SOAP [SOUZA, 2009]

WSDL (Web Service Description Language)

Um servio Web deve definir todas as suas interfaces, operaes, esquemas de

codificao, entre outros, em um documento para que a entidade Requester saiba o formato dos
mtodos a serem chamados e quais parmetros devem ser passados. WDSL a linguagem de
metadados utilizada nesses documentos para estes fins [MEDYK, 2006].
Um documento WSDL define um XML Schema (linguagem baseada em XML para
definio de regras de validao em documentos XML) para descrever um servio Web. Possui
uma parte abstrata, que descreve a interface de um servio e as operaes suportadas e uma parte
concreta, que especifica os formatos de dados e protocolos especficos que sero utilizados. A
figura 3.11 mostra a estrutura de um documento WSDL.

Figura 3.11 Estrutura de um documento WSDL [ROSSINI, 2008]

A figura 3.12 ilustra um exemplo de um documento WSDL que contm a definio de um

25

mtodo getQuantidadeEmEstoque. O documento define tambm o parmetro da

requisio cdigo - e os parmetros da resposta - o cdigo e a quantidade em estoque.

Figura 3.12 Exemplo de um documento WSDL [SOUZA, 2009]

UDDI (Universal Description Discovery and Integration)

O Service Registry (Registro de Servios) a entidade que representa a localizao central

onde o provedor de servios pode relacionar os seus servios web, possibilitando assim a
pesquisa e a descoberta desses servios. Este papel desempenhado pela UDDI, que consiste em
um servio estruturado na forma de repositrios para nomeao e localizao dos servios web
[BELLWOOD, 2002].
O padro UDDI foi criado em agosto de 2000 pela organizao OASIS [OASIS, 2006] e
especifica um protocolo para obter e atualizar um diretrio comum de informao dos servios
Web. O diretrio inclui informaes sobre Service Providers, os servios que eles fornecem e os
protocolos que so implementados por aquele servio [MEDYK, 2006].
26

O padro foi desenvolvido para ser acessado atravs de mensagens SOAP e fornecer
acesso aos documentos WSDL descrevendo os protocolos e os formatos das mensagens
necessrios para a interao com determinado servio listado no diretrio.
O UDDI pode ser visto como as pginas amarelas dos servios Web. De forma anloga
s pginas amarelas tradicionais, um UDDI Registry oferece informaes categorizadas sobre os
servios e as funcionalidades que eles oferecem.

A figura 3.13 mostra a interao entre as tecnologias citadas.

Figura 3.13 Interao entre as tecnologias Web Services [MEDYK, 2006]

3.5 Integrao e Operaes entre as Entidades

A arquitetura de servios Web, de forma geral, baseada na integrao entre trs
elementos ou entidades: Service Provider (Provedor de Servios), Service Requestor (Cliente do
Servio) e Service Registry (Registro de Servio). A figura 3.14 ilustra as operaes entre as
entidades citadas.

27

Figura 3.14 Operaes entre as entidades relacionadas [W3C, 2009]

As principais operaes ilustradas na figura acima so: Publish (Publicao), Find
(Busca) e Bind (Vinculao). De uma maneira geral o provedor do servio (Service Provider)
hospeda o Servio Web, tornando-o disponvel para os clientes (Service Requestor) acessarem.
Os clientes so quaisquer aplicaes que queiram iniciar uma interao com os servios Web
(pode ser tambm um acesso direto atravs de um browser). J os Services Registries so os
servidores de registro e busca dos servios atravs de arquivos de descrio dos mesmos
(especificados de acordo com a linguagem WSDL e registrados nos UDDI Registries) que foram
publicados pelos Services Providers. Dessa forma os clientes buscam por servios nos servidores
de registro e recuperam as informaes necessrias para a implementao do mesmo.

Dessa forma, a Arquitetura de Servios Web surgiu para permitir a interoperabilidade

entre diferentes tipos de aplicao mesmo rodando em plataformas e sistemas operacionais
diferentes, visto que as abordagens j existentes DCOM, CORBA e RMI deixaram a desejar
no que se refere independncia de plataforma.
Como apresentado, o processo geral de um servio web dado a partir da interao entre
duas entidades Requester (consumidora do servio) e Provider (fornecedora do servio). A
troca de mensagens se d somente aps a consumao de acordos da descrio e da semntica do
servio.
Foram apresentados os quatro modelos definidos pela especificao da Arquitetura de
28

Servios Web: Modelo Orientado a Mensagens, Modelo Orientado a Servio, Modelo Orientado
a Recursos e Modelo de Policiamento. Cada modelo foca em um aspecto da arquitetura e
gerado a partir de um ponto de vista diferente. Um desses pontos de vista o do Modelo
Orientado a Recursos provm de um conceito comum com o paradigma REST o recurso.
As tecnologias relacionadas aos servios web XML, SOAP, WSDL e UDDI descritas
representam a forma tradicional como so implementados os servios web e ser comparada
com o paradigma REST mais adiante.

29

4 Arquitetura REST

REST (Representation State Transfer) um estilo arquitetural hbrido para sistemas distribudos
derivado da combinao de alguns estilos arquiteturais (descritos abaixo) com algumas
caractersticas adicionais. Foi criado a partir de um captulo da tese de doutorado de Roy Fielding
no ano de 2000 [FIELDING, 2000].

4.1 Fundamentao Bsica

Esta seo ir fornecer uma viso geral de REST, atravs do processo de derivao do
mesmo como um estilo arquitetural.

4.1.1 Null Style

Uma das perspectivas do processo de projeto de arquiteturas parte do princpio de que o
mesmo comea tomando as necessidades do sistema como um todo, sem caractersticas e ento,
de forma incremental elas vo sendo identificadas e aplicadas aos elementos do sistema a fim de
diferenciar o espao de projeto e permitir que o comportamento do sistema flua naturalmente em
harmonia com o todo.
Esta perspectiva conhecida como Null Style (Figura 4.1). Basicamente, representa um
conjunto simples e vazio de caractersticas. A partir de uma viso arquitetural, descreve um
sistema o qual no distingue limites entre componentes. Este o ponto inicial da descrio de
REST por Fielding em sua tese de doutorado [FIELDING, 2000].

30

Figura 4.1 Null Style [FIELDING, 2000]

4.1.2 Cliente-servidor
A primeira caracterstica adicionada ao Null Style deriva do estilo arquitetural clienteservidor (Figura 4.2).
O princpio por trs da arquitetura cliente-servidor o de separao de responsabilidades.
Ao separar as responsabilidades de interface das de armazenamento de dados, a utilizao da
arquitetura cliente-servidor permite que os componentes, o cliente e o servidor, se desenvolvam
de forma independente. A evoluo independente de cada parte torna a arquitetura apta a suportar
os requisitos de aplicao de mltiplos domnios organizacionais na escala da Internet.

Figura 4.2 Estilo Arquitetural Cliente-Servidor [FIELDING, 2000]

4.1.3 Sem Estado

A prxima caracterstica a ser adicionada interao cliente-servidor a baseada no
princpio de que as comunicaes devem ser stateless, ou em portugus, sem estado (Figura 4.3).
Em REST, as comunicaes no devem depender de estados controlados pelo servidor.
Toda informao de estado deve ser conhecida somente pelo cliente. Dessa forma, todas as
requisies feitas pelo cliente devero sempre possuir todos os atributos necessrios para que ela
possa ser processada sem que o mesmo se aproveite de informaes adicionais no contexto de
comunicao.

31

Figura 4.3 Estilo Arquitetural Cliente-servidor Sem Estado [FIELDING, 2000]

4.1.4 Cache
Combinando-se os estilos Cliente-Servidor, Sem Estado e Cache chega-se ao Cliente com
Cache-Servidor Sem Estado.
A grande vantagem deste estilo sobre o anterior de poder, parcialmente ou at
totalmente, eliminar algumas interaes entre cliente e servidor, sobrecarregando menos o
servidor. Com o uso do cacheamento, melhora-se o desempenho geral do sistema, pois diminui o
tempo de resposta da aplicao [TOBALDINI, 2008].
Para melhorar a eficincia da comunicao entre o cliente e o servidor, adiciona-se a
REST a caracterstica de cache, o que torna necessria a marcao explcita de uma resposta no
mbito de esta ser ou no passvel de cache. Em caso afirmativo, o cliente tem o direito de reusar
esta resposta futuramente, podendo se aproveitar das vantagens oferecidas pelo cacheamento.

4.1.5 Interface Uniforme

A caracterstica principal que diferencia REST de outras arquiteturas baseadas em rede a
sua nfase em uma interface uniforme entre componentes [FIELDING, 2000].
Aplicando o princpio de generalizao de engenharia de software interface dos
componentes, a arquitetura simplificada e a visibilidade melhorada. O problema dessa
uniformizao que toda a troca de informao feita de forma genrica ao invs de ser
especfica para cada necessidade [TOBALDINI, 2008].
32

Para obter uma interface uniforme, vrias caractersticas arquiteturais so necessrias para
guiar o comportamento dos componentes.
REST definido atravs de quatro elementos de interface: Identificao de Recursos;
Manipulao de Recursos atravs de Representaes; Mensagens Auto-descritivas e Hipermdia
como Mquina de Estados da Aplicao. Estes elementos sero detalhados na seo 4.2.

4.1.6 Separao em Camadas

Um sistema em camadas permite a uma arquitetura ser composta por diversos nveis
hierrquicos, restringindo os componentes participantes de tal forma que nenhum deles possa
enxergar atravs da camada adjacente, ou seja, o conhecimento do sistema que o componente
possui restrito sua camada apenas [FIELDING, 2000].
A grande desvantagem do uso de sistemas em camadas o maior atraso na chegada da
informao de um extremo ao outro, por conta das camadas intermedirias. Para um sistema que
suporta as caractersticas de cache essa desvantagem pode ser contornada atravs do
compartilhamento de cache entre as camadas permitindo que uma requisio que j foi feita
anteriormente possa ser utilizada por uma camada intermediria ao invs de percorrer todo o
caminho at o destino final [TOBALDINI, 2008].
Ao estilo REST adicionada tambm a possibilidade de separao em camadas. Seu uso
prov uma maior flexibilidade e simplicidade na comunicao entre sistemas diversos.
Embora as interaes entre cliente e servidor ocorram sempre nos dois sentidos, cada
troca de dados pode ser tratada como um fluxo independente. Isto possvel devido ao fato de
que as mensagens REST so sempre auto-descritivas e seus significados so sempre visveis a
todos os seus intermedirios.

4.1.7 Cdigo Sob Demanda

A utilizao de cdigo sob demanda permite que as funcionalidades do cliente sejam
inseridas em tempo de execuo atravs da descarga e execuo de cdigo em forma de scripts.
Esta caracterstica pode facilitar a extenso do sistema, porm reduz a visibilidade.
33

O recurso de cdigo sob demanda em REST tem o objetivo de simplificar e ampliar as

capacidades dos clientes. Porm o seu uso opcional, pois acarreta em reduo de visibilidade do
sistema. [FIELDING, 2000]

Dessa forma, REST foi gerado a partir de um null style em composio com
caractersticas de outros estilos arquiteturais. Embora cada uma dessas caractersticas possa ser
considerada de forma isolada, descrev-las em termos de suas derivaes de estilos arquiteturais
torna mais fcil entender a razo por trs destas escolhas.

4.2 Elementos Arquiteturais REST

REST uma abstrao de elementos arquiteturais em sistemas distribudos. O estilo
ignora detalhes de implementao de componentes e sintaxe de protocolos para focar nos papis
dos componentes, suas interaes e interpretao de elementos de dados [TOBALDINI, 2008].
A seguir, os elementos arquiteturas de REST sero detalhados.

4.2.1 Elementos de Dados

A natureza e o estado dos elementos de dados de uma arquitetura so os aspectos-chave
de REST. Quando um link selecionado na Web, por exemplo a informao precisa ser
movida do local onde ela ser processada. Esta caracterstica difere de outros paradigmas de
processamento distribudo, onde possvel e geralmente mais eficiente levar o
processamento at os dados ao invs de levar os dados at o processamento.
No REST, os componentes se comunicam atravs da transferncia de representaes de
um recurso em um formato dentre um conjunto de tipos de dados padro selecionado
dinamicamente baseado nas capacidades ou desejos do componente que ir receber as
informaes e na natureza do recurso. Sejam estas representaes no mesmo formato que os
dados ou derivadas deste, a comunicao se d de forma transparente. Portanto, REST se
beneficia da separao de responsabilidades do estilo cliente servidor sem o problema da
escalabilidade [FIELDING, 2000].
34

A figura 4.4 ilustra os elementos de dados do estilo REST e seus respectivos exemplos.

Figura 4.4 Elementos de Dados REST [FIELDING, 2000]

4.2.1.1 Recursos e Identificadores de Recursos

A abstrao chave de informao no estilo REST um recurso. Qualquer informao que
possa receber um nome pode ser um recurso: um documento, uma imagem, um servio, uma
coleo de outros recursos, e assim por diante. Em outras palavras qualquer conceito que possa
ser alvo de uma referncia deve se encaixar na definio de recurso [TOBALDINI, 2008].
REST usa um identificador de recurso para identificar um recurso especfico envolvido
em uma interao entre os componentes. Um exemplo de um identificador de recursos o URI
(Unified Resource Identifier).

4.2.1.2 Representao
Componentes REST executam aes sob um recurso utilizando uma representao para
capturar o estado atual e o estado desejado de um recurso solicitado e transferir a representao
entre os componentes.
Uma representao, em REST, uma seqncia de bytes acrescida dos meta-dados dessa
representao que descrevem estes bytes. Uma representao pode ser, por exemplo, um
documento, um arquivo, uma mensagem HTTP, entre outros. Mais especificamente uma

35

representao consiste em dados, meta-dados para descrever os dados e, ocasionalmente, outro

conjunto de meta-dados que descrevem meta-dados (utilizados para verificao da integridade da
mensagem).
Os meta-dados so apresentados na forma de pares nome-valor, onde o nome corresponde
a um padro que define a estrutura e a semntica do valor. As mensagens de resposta em REST
incluem tanto os meta-dados da representao quanto os meta-dados do recurso (informaes
sobre o recurso que no so especficas representao especfica) [FIELDING, 2000].
Outro elemento participante de uma representao a informao de controle (control
data). Informaes de controle definem o propsito de uma mensagem entre os componentes,
assim como a natureza da ao solicitada ou a finalidade de uma resposta. Elas so usadas para
parametrizar requisies e redefinir o comportamento padro de alguns elementos. Por exemplo,
o comportamento de um cache pode ser modificado atravs de informaes de controle
embutidas em uma requisio ou resposta.
O formato dos dados de uma representao conhecido como media-type (ou em
portugus, tipo de informao). Uma representao pode ser includa em uma mensagem e
processada de acordo com as informaes de controle da mensagem e a natureza do tipo de
informao.

4.2.2 Conectores
REST utiliza vrios tipos de conectores (resumidos na figura 4.5) para encapsular a
atividade de acesso a recursos e para transferir representaes dos mesmos. Os conectores
provm uma interface abstrata para a comunicao entre componentes, melhorando a
simplicidade do sistema atravs da separao das responsabilidades e ocultando a implementao
de recursos e mecanismos de comunicao [FIELDING, 2000].

36

Figura 4.5 Conectores REST [FIELDING, 2000]

Todas as interaes REST so, por natureza, sem estado. Isto , cada requisio contm
toda a informao necessria para o conector entender a requisio, independente de qualquer
requisio que tiver precedido a mesma.
A interface do conector semelhante invocao procedural, porm com diferenas em
relao passagem de parmetros e resultados. Os parmetros de entrada consistem em
informaes de controle da requisio acrescidas de um identificador de recurso e,
opcionalmente, uma representao. Os parmetros de sada so compostos pela informao de
controle da resposta e opcionalmente meta-dados do recurso ou uma representao
[TOBALDINI, 2008].
Os dois primeiros tipos de conectores da figura cliente e servidor so os conectores
primrios. A diferena bsica entre eles que cabe ao cliente inicializar a comunicao a partir de
uma requisio, enquanto o servidor deve aguardar passivamente e atender s requisies de
forma a fornecer acesso aos seus servios. Um componente pode incluir ambos os conectores
[FIELDING, 2000].
O conector cache encontrado entre o cliente e o servidor e tem a funo de armazenar as
respostas passveis de cache para que elas possam ser reutilizadas em requisies futuras. Um
cache tambm pode ser utilizado no cliente para evitar repeties de comunicaes de rede, ou
pelo servidor para evitar a repetio no processo de gerao de respostas. Em ambos os casos, o
cache contribui para diminuir o tempo de resposta latncia da aplicao [TOBALDINI,
2008].
A resoluo de nomes (resolver) traduz, parcial ou completamente, identificadores de
recurso (um URI, por exemplo) em endereos de rede. Essa converso torna possvel estabelecer
uma conexo entre componentes.
37

Finalmente, a ltima pea dos conectores de REST o tnel. Sua funo de criar um
caminho virtual para o trfego de dados de forma a transpor limites, como um firewall ou um
roteador.
A nica razo para incluir o tnel como parte da arquitetura REST e no abstrair como
parte da infra-estrutura de rede que alguns componentes de REST podem trocar dinamicamente
de um comportamento ativo para um comportamento de tnel. O exemplo desse cenrio o
Proxy HTTP que, dependendo do tipo de requisio que ele intermedia, deixa suas funes de
proxy e passa a se comportar como um tnel para permitir a comunicao direta (sem passagem
pelo proxy). Os tneis so destrudos aps o trmino de uma comunicao entre componentes
[TOBALDINI, 2008].

4.2.3 Componentes
Os componentes REST so categorizados de acordo com o papel que eles exercem no
mbito geral de uma aplicao, de acordo com a figura 4.6.

Figura 4.6 Componentes REST [FIELDING, 2000]

O agente do usurio utiliza um conector do tipo cliente para iniciar uma requisio e, em
seguida, se torna o destino final de uma resposta.
O tipo mais comum de um agente do usurio o navegador web que prov acesso
informao (recursos) e processa as respostas (representaes) de forma a ser visualizada pelo
usurio de acordo com a necessidade [TOBALDINI, 2008].
Um servidor de origem utiliza um conector do tipo servidor e trata das requisies de um
cliente. Cada servidor deve prover seus servios atravs de uma interface genrica para a sua

38

hierarquia de recursos. Os detalhes de implementao destes recursos ficam escondidos por esta
interface [FIELDING, 2000].
Os outros dois componentes gateway e proxy atuam simultaneamente como cliente e
servidor para permitir o encaminhamento de requisies e respostas. O proxy um componente
intermedirio escolhido pelo cliente que torna possvel o encapsulamento de outros servios,
traduo de dados, melhoria de performance ou algum tipo de controle de acesso de segurana. J
o gateway funciona como um proxy reverso. Ele fornece os mesmos servios que um proxy,
porm o gateway transparente ao usurio e utilizado pelo servidor de origem, enquanto o proxy
utilizado explicitamente pelo usurio.

4.2 Vises Arquiteturais REST

Como mencionado no captulo 2, as vises de uma arquitetura so utilizadas para
descrever como os elementos arquiteturais trabalham em conjunto para formar uma arquitetura.
Sero abordados trs tipos de vises dentro do conceito arquitetural REST Vises de Processo,
Vises de Conectores e Viso de Dados.

4.2.1 Vises de Processo

Uma viso de processo de uma arquitetura particularmente til para extrair as relaes e
interaes entre os componentes, revelando o caminho dos dados como um fluxo atravs do
sistema [FIELDING, 2000]. Porm, a interao de componentes de um sistema real geralmente
envolve muitos componentes, resultando em uma viso geral complexa.
A separao de responsabilidades entre cliente e servidor da arquitetura REST torna mais
simples a implementao de componentes, reduz a complexidade da semntica dos conectores,
melhora o desempenho e aumenta a escalabilidade de componentes. As caractersticas de
sistemas em camadas permitem que intermedirios proxies, gateways e firewalls possam ser
inseridos em vrios pontos da comunicao sem alterar a interface entre os componentes, o que
permite que eles participem da comunicao e melhora do desempenho atravs do uso de cache.
Servios podem ser implementados utilizando uma hierarquia de intermedirios e
39

servidores de origem distribudos. A caracterstica natural de REST Sem-Estado permite de

cada interao seja independente das outras e permite que componentes desempenhem um papel
determinado dinamicamente de acordo com o foco de cada requisio.
Os conectores devem ter conhecimento da existncia de outros conectores somente
durante o escopo da comunicao, embora eles possam usar o cache para armazenar informaes
de outros componentes por razes de desempenho.

4.2.2 Vises de Conectores

A viso dos conectores de uma arquitetura foca nos mecanismos de comunicao entre os
componentes. Para a arquitetura REST, interessam somente as caractersticas que definem uma
interface de recursos genrica.
Conectores do tipo cliente consideram a identificao de recurso para escolher o
mecanismo de comunicao mais conveniente para cada requisio. Por exemplo, um cliente
pode ser configurado para se conectar um determinado componente de proxy somente quando o
identificador indicar que ele um recurso local. Da mesma forma, um cliente tambm pode ser
configurado para rejeitar requisies de um determinado subconjunto de identificadores
[FIELDING, 2000].

4.2.3 Vises de Dados

A viso de dados de uma arquitetura revela o estado de uma aplicao como um fluxo de
informao atravs dos componentes. Devido ao foco da arquitetura REST ser em sistemas
distribudos, sua viso de dados uma estrutura coesa de informao e alternativas de controle
pelas quais um usurio pode realizar as tarefas desejadas.
Os estados da aplicao so controlados e armazenados por um agente usurio e podem
ser decompostos em representaes de vrios servidores. O usurio pode manipular diretamente o
estado (por exemplo, o histrico de um Web Browser), antecipar mudanas um estado e pular
de uma aplicao para outra (por exemplo, bookmarks).
40

4.3 Arquitetura Orientada a Recursos

O estilo arquitetural REST define somente um conjunto de caractersticas que
caracterizam uma aplicao dita RESTFul, de forma muito abstrata e geral. Esta seo introduz a
Arquitetura Orientada a Recursos, uma aplicao prtica dos conceitos arquiteturais REST.
A Arquitetura Orientada a Recursos torna possvel transformar um problema em uma
aplicao REST atravs do emprego de URIs, HTTP e XML. Ela composta por recursos, seus
nomes, suas representaes, a ligao entre eles e algumas propriedades: Endereamento, SemEstado, Conectividade e Interface Uniforme [RICHARDSON; RUBY, 2007].
A seguir os conceitos acerca da arquitetura sero contextualizados e exemplificados.

4.3.1 Recursos
Um recurso algo que possa ser armazenado em um computador e representado como
uma seqncia de bits, como por exemplo, um documento ou uma imagem. Um recurso pode ser
um objeto fsico, como por exemplo, uma ma, ou at mesmo um conceito abstrato, como
coragem.
So exemplos de recursos:
A ltima verso de uma distribuio de um software;
Um nmero primo qualquer;
Uma lista de bugs de um banco de dados;
A relao entre dois conhecidos, Alice e Bob.

Para ser acessado, o recurso deve ser associado a um nome e um lugar onde ele possa ser
encontrado. Para isto utilizado um identificador de recurso, dessa forma, um recurso precisa ter
ao menos um identificador para que se torne acessvel [TOBALDINI, 2008].
REST, enquanto um estilo arquitetural, utiliza um identificador de recurso. No caso da
arquitetura orientada a recursos, os identificadores de recurso utilizados so as URIs (Unified
Resource Identifier).
As URIs devem ser utilizadas de forma estruturada, intuitiva e uniforme

41

[RICHARDSON; RUBY, 2007]. Um exemplo de prtica no aconselhvel desse cenrio a

utilizao das URIs /informacoessobre/rest e /arespeitode/rest para se obter
informaes sobre REST. O objetivo destes dois recursos o mesmo: representar informaes
sobre a arquitetura REST, porm suas URIs so compostas de forma no-uniforme.
O que torna essa prtica no aconselhvel o fato de no haver uma forma automtica de
verificar que vrias URIs se referem ao mesmo recurso, embora esse problema possa ser
contornado atravs do uso de um URI principal e sua indicao como tal na resposta para URIs
secundrias.

4.3.2 Endereamento
Uma aplicao enderevel se ela expe aspectos interessantes sobre seu conjunto de
dados como recursos. Como URIs so atribudas a recursos, uma aplicao enderevel
quando ela expe pelo menos um URI para cada informao que ela deseja servir
[RICHARDSON; RUBY, 2007].
Um exemplo que ilustra a propriedade de endereamento o protocolo HTTP. O stio
http://www.google.com.br pode ser tomado como exemplo de aplicao HTTP
enderevel. Quando a busca de uma expresso realizada, a mesma traduzida em um URI que
possui todas as informaes para que a mesma possa ser repetida e obter a mesma resposta em
outra ocasio. Alm disso, este URI poder ser repassado para outra pessoa que necessitar obter a
mesma pesquisa [TOBALDINI, 2008].
Se esta aplicao no fosse enderevel o recurso mencionado no seria possvel. Sempre
que uma pesquisa fosse necessria, seria preciso entrar no stio e preencher o campo de busca e
solicitar a pesquisa.

4.3.3 Sem-Estado
A ausncia de estados (statelessness) significa que cada requisio feita pelo cliente
ocorre de maneira isolada no servidor, isto significa que no h lembrana de estados entre uma
requisio e outra. Quando uma requisio feita, ela dever conter todas as informaes
necessrias para que seja completada pelo servidor, que nunca ir se utilizar de informaes de
requisies anteriores [RICHARDSON; RUBY, 2007].
42

Pode-se considerar a ausncia de estados em termos de endereamento. O endereamento

prega que cada informao interessante deve ser exposta na forma de um recurso e ter seu prprio
URI. No caso da ausncia de estados, de forma anloga ao endereamento, cada estado possvel
deve ser representado na forma de um recurso e ter seu prprio URI.
Uma forma de quebrar a ausncia de estados no servidor utilizando o conceito de
sesses. Quando um cliente faz sua primeira requisio ao servidor, lhe atribudo um
identificador de sesso que pode ser um nmero ou uma cadeia de caracteres. Este identificador
pode ser propagado como um componente do URI ou ser associado a um cliente atravs do uso
de cookies. Cookies so informaes enviadas pelo servidor e que permanecem sem modificaes
no cliente. A cada vez que uma requisio feita pelo cliente, os cookies so enviados ao
servidor [TOBALDINI, 2008].

4.3.4 Representaes
Uma aplicao composta por diversos recursos. Cada recurso criado deve transmitir
alguma idia ao usurio, como por exemplo, informaes sobre REST. Porm, um servidor
no pode enviar uma idia ao usurio, mas sim uma seqncia de bytes em um formato especfico
para que possa ter utilidade ao cliente. Isto uma representao de um recurso [RICHARDSON;
RUBY, 2007].
Um recurso a origem de uma representao e as representaes so basicamente alguns
dados relevantes sobre o estado atual de um recurso. Alguns recursos so, por natureza, dados.
Um exemplo desse tipo de recurso uma lista de bugs, que tem como representao seus prprios
dados os itens da lista. Esta lista pode ser representada por um documento XML, uma pgina
HTML ou at mesmo um documento de texto puro [RICHARDSON; RUBY, 2007].
Porm, alguns tipos de recursos representam objetos fsicos ou outro elemento que no
possa ser naturalmente representado atravs de dados, como por exemplo, uma geladeira.
Considerando o cenrio de uma geladeira, seria impossvel obter uma geladeira atravs do acesso
a este recurso. Porm, o objeto geladeira possui informaes teis a seu respeito seus
metadados como, por exemplo, sua temperatura interna, a posio do termostato que a regula,
entre outros.
Como j mencionado, um recurso pode ter mais de uma representao. Torna-se
necessrio ento escolher qual representao deve ser obtida. Este problema pode ser resolvido
43

de vrias maneiras dentro das restries impostas pela arquitetura REST. Porm, a Arquitetura
Orientada a Recursos recomenda apenas uma maneira de solucionar este problema: utilizando
URIs distintas para cada tipo de representao. Esta abordagem torna possvel que cada URI
possua todas as informaes acerca do recurso, incluindo o tipo de representao desejada. Por
outro lado, isto causa diluio de um mesmo recurso em vrias URIs [TOBALDINI, 2008].

4.3.5 Ligaes e Conectividade

Uma representao de um recurso pode conter, alm dos dados sobre ele, ligaes para
outros recursos. Tomando como exemplo, novamente, uma pesquisa de informaes sobre REST
em um stio de pesquisa, como o Google, a representao desta busca seria uma pgina HTML
contendo vrias ligaes para outros recursos que contenham algum tipo de informaes
relacionadas REST. Dessa forma, o servidor guia o usurio s informaes atravs das ligaes
[TOBALDINI, 2008].
Da forma tradicional como a Web usada, ela possui um alto grau de conectividade.
Qualquer usurio experiente pode inserir diretamente um URI em um Browser e navegar atravs
de stios mudando este URI. Tambm possvel acessar estas URIs atravs de um nico ponto
de partida como um stio de busca e navegar atravs das ligaes [RICHARDSON; RUBY,
2007].

4.3.6 Interface Uniforme

Como j mencionado, a arquitetura REST especifica uma interface uniforme, porm de
forma genrica. A arquitetura orientada a recursos utiliza os conceitos de uma interface uniforme
proveniente do protocolo HTTP [TOBALDINI, 2008].
O protocolo HTTP define oito mtodos, dos quais seis so utilizados na arquitetura em
questo, sumarizados na figura 4.7.

44

Figura 4.7 Mtodos do protocolo HTTP utilizados pela Arquitetura Orientada a Recursos
[TOBALDINI, 2008].

4.4 Servios Web segundo o modelo REST

De acordo com a viso tradicional para os Servios Web, a fase de interao
implementada atravs de troca de mensagens SOAP. A figura 4.8 ilustra um exemplo de
invocao de procedimento e sua respectiva resposta ao pedido, baseados na viso tradicional dos
Servios Web (baseada em troca de mensagens SOAP) [NUNES; DAVID, 2009]. O exemplo
representa uma viso simplificada de um servio que disponibiliza informaes de alunos.

45

Figura 4.8 Invocao e resposta de um mtodo pela viso tradicional de Servios Web
[NUNES; DAVID, 2009]
Segundo a abordagem convencional do desenvolvimento de Servios Web, os servios
esto escondidos por trs de mtodos que podem ser invocados.
A arquitetura orientada a recursos se tornou uma alternativa para a construo de Servios
Web tendo por base os pressupostos estabelecidos com o modelo REST. Em um Servio Web
compatvel com a arquitetura REST, os recursos devem ser expostos e ter uma identificao
global. Ainda no cenrio utilizado como exemplo, na viso REST, os recursos correspondem a
documentos XML com a informao sobre os alunos. Cada URI identifica de forma nica a
informao sobre um estudante.
Depois de expostos os recursos, a interao realizada utilizando as operaes genricas
do protocolo HTTP. Dessa forma, para obter a representao da informao relativa a um
estudante, utiliza-se o mtodo GET sobre o URI do recurso. A figura 4.9 ilustra o pedido e a
resposta de uma requisio baseada nos princpios REST [NUNES; DAVID, 2009].

46

Figura 4.9 Invocao e resposta de um mtodo pela viso REST de Servios Web [NUNES;
DAVID, 2009]

47

5 Exemplos de Aplicao
Para contextualizar a apresentao dos conceitos das duas abordagens de Servios Web
apresentadas nos captulos anteriores viso tradicional e viso REST, um exemplo de servio
em Java ser ilustrado por ambas as implementaes.
A

IDE

utilizada

nos

exemplos

foi

Eclipse

verso

Galileo

(http://www.eclipse.org/galileo/) e o continer web utilizado foi o Apache Tomcat,

(http://tomcat.apache.org/) em sua verso 6.0.
O servio oferecido consiste em um acervo simplificado de filmes e os mtodos
oferecidos so os de cadastro e busca dos mesmos. Por questes de simplicidade, os dados dos
exemplos no so persistidos e as camadas de acesso aos dados (padro DAO) e de servio
(padro Service) foram omitidas. Alm disso, os mtodos get e set de atributos foram
omitidos, como tambm declaraes do tipo import.

5.1 Exemplo de abordagem tradicional de Servios Web

Atualmente, a plataforma Java possui uma gama de componentes que permitem
implementar servios pela abordagem tradicional sem precisar manipular diretamente SOAP e
WSDL. As principais opes so os servidores de aplicao Java EE completos ou frameworks
independentes, como o Apache Axis (http://ws.apache.org/axis2/). Pela sua maturidade; por
abstrair o uso do protocolo SOAP e ser compatvel com WSDL, o Apache Axis 2 foi escolhido
para o desenvolvimento do exemplo.
A classe Filme.java, ilustrada na figura 5.1 representa a classe de modelo do exemplo.
Os dados do filme, neste contexto, representa o servio que ser oferecido por uma entidade
Provider por exemplo, um servidor que armazena o acervo de filmes e consumido por um
determinado usurio que representa a entidade Requester.

48

Figura 5.1 Classe Filme.java

A classe de servio que contm os mtodos a serem invocados remotamente e que gerou o
WSDL ilustrada na figura 5.2.

Figura 5.2 Classe FilmeWS.java

O arquivo WSDL ilustrado na figura 5.3 foi criado de forma automtica pelo Eclipse,
atravs da opo Create Web Service. O WSDL representa a descrio do servio e
disponibiliza todos os mtodos oferecidos pelo mesmo e os parmetros de entrada e sada.

49

Figura 5.3 Arquivo FilmeWS.wsdl

O plugin do Eclipse permite tambm que se gere o cliente de um servio a partir de um
documento WSDL. A ferramenta gera automaticamente as classes cliente, entre elas a Proxy,
cuja instncia permite a invocao dos mtodos do servio, como descrito na classe de teste
FilmeMain.java, ilustrada na figura 5.4.

50

Figura 5.4 Classe FilmeMain.java

A execuo da classe FilmeMain.java gera a sada ilustrada na figura 5.5.

Figura 5.5 Sada da execuo da classe FilmeMain.java

51

5.2 Exemplo de Servios Web RESTFul

Para oferecer suporte a servios REST em Java, foi criada a JAX-RS, uma API que busca
simplificar o desenvolvimento da linha de servios REST e oferecer uma forma padro de
implementao da mesma [PEREIRA, 2008]. Sua implementao de referncia conhecida
como Jersey (https://jersey.dev.java.net/).
Com a utilizao de Jersey, um servio implementado como um recurso web atravs de
uma classe Recurso e as requisies so tratadas por mtodos das mesmas. Uma classe Recurso
contm anotaes da JAX-RS para indicar os mapeamentos e as operaes existentes
[PEREIRA, 2008].
Para utilizar o Jersey em uma aplicao RESTFul, os prefixos de URIs do servio
devem ser mapeados para um Servlet do Jersey. A figura 5.6 mostra o arquivo web.xml da
aplicao configurado com este mapeamento. Como todas as URIs so do servio REST, toda
a aplicao mapeada para o Servlet do Jersey.

Figura 5.6 Arquivo web.xml da aplicao

52

No nosso exemplo, classe de modelo (Filme.java) foi includa uma anotao do

tipo @XmlRootElement, que

indica que o valor de uma instncia desta classe ser

representado como um elemento XML (figura 5.7).

Para contextualizar o exemplo nos conceitos apresentados no captulo anterior, pode-se
considerar a classe de modelo como uma representao de um recurso a ser disponibilizado.
Enquanto a viso tradicional disponibiliza um servio, a viso REST torna um recurso acessvel
para se obter a sua representao (os dados do filme solicitado).

Figura 5.7 Classe Filme.java

A classe de recurso do exemplo a FilmeResource.java (figura 5.8). Nela esto

todos os servios com o prefixo /filme.
A classe deve ser anotada com @Path contendo o prefixo. Esta anotao necessria
para que a classe seja associada com o prefixo nas requisies. Alm disso, a classe deve conter
as anotaes @Consumes e @Produces, que declaram que os servios da mesma so capazes
de consumir e gerar contedo nos formatos text/XML e application/json [PEREIRA, 2008]. O
formato JSON (JavaScript Objection Notation) um subconjunto da notao de objeto de
JavaScript que pode ser interpretado por qualquer linguagem.
53

Figura 5.8 Classe de Recurso FilmeResource.java

O primeiro mtodo oferecido pelo recurso o de busca de filmes. O mtodo

buscarFilme foi anotado com @Path({codFilme}). A juno da anotao do
mtodo @Path({codFilme}) com a da classe (@Path(filme)) especifica que o
mtodo capaz de responder a requisies para a URI /filme/codFilme, como por
exemplo /filme/1.
Como tambm foi inserida a anotao @GET no mtodo de busca, todas as requisies
do tipo HTTP GET sero tratadas por este mtodo. A anotao @PathParam utilizada para
injetar no parmetro codFilme o valor que veio da URI.
O outro mtodo oferecido o de cadastro de filmes. A utilizao da anotao @POST
garante que todas as requisies do tipo HTTP POST sero encaminhadas para o mtodo

54

anotado. O parmetro do mtodo cadastrarFilme um objeto Filme, que ser enviado

no formato XML em uma requisio.
Para utilizao do recurso por uma aplicao cliente RESTFul, as solicitaes HTTP
devem ser feitas atravs da classe HttpClient (da API commons-http-client). Esta
API permite que se montem requisies HTTP e sejam recebidas suas respostas, da mesma
forma que ocorreria com um browser simples [PEREIRA, 2008].
Para consumir o recurso disponibilizado pelo lado servidor, a classe FilmeMain.java
(figura 5.9) efetua um cadastro de um filme e realiza uma busca do mesmo.
A converso do filme criado em um arquivo XML feita com o auxlio da classe
XStream, que pertence a uma biblioteca criada para serializar objetos.

55

Figura 5.9 Classe de teste FilmeMain.java

Na execuo da classe, ainda so exibidos o cabealho e o corpo tanto da requisio

quanto da resposta, para fins de demonstrao. A figura 5.10 mostra a sada da execuo da
classe FilmeMain.java.

56

Figura 5.10 Sada da execuo da classe de teste FilmeMain.java

As requisies do tipo GET podem ainda ser feitas atravs de um browser, como ilustra a
figura

5.11.

Atravs

das

URIs

http://localhost:8080/REST/filme/1

http://localhost:8080/REST/filme/2, os dados dos filmes de cdigos 1 e 2,

respectivamente, foram retornados no formato XML.
Neste contexto, estas URIs representam os identificadores de recurso definidos por
Fielding. Ainda de forma contextual, o browser utilizado na figura 5.11 o Web Browser do
Eclipse representa o agente do usurio, tambm definido por Fielding.

57

Figura 5.11 Requisio do tipo GET atravs de um Web Browser

5.3 Utilizao do REST

Buscando, sobretudo simplicidade e maior desempenho das aplicaes, o paradigma
REST tem sido utilizado em larga escala por algumas organizaes, listadas a seguir.
Google
No ano de 2008, mais de um ano aps o Google ter descontinuado o Google SOAP
Search API conjunto de bibliotecas para acessar alguns servios do Google atravs de
servios web em sua forma tradicional, utilizando SOAP a organizao lanou o AJAX
Search API (http://code.google.com/intl/pt-BR/apis/ajaxsearch/), que
oferece uma interface simples REST. A API suporta o mtodo HTTP GET e retorna mensagens
do tipo JSON [GOOGLE, 2009].
A utilizao da API simples. Basta fazer uma solicitao GET e processar uma resposta
JSON. Alm disso, no necessria a utilizao de uma chave de licena obrigatria para a
Google SOAP Search API. Outra vantagem a facilidade de uso e o nmero ilimitado de
58

requisies.
Porm, a API ainda apresenta algumas restries, como o nmero mximo de oito
resultados por requisio e a no-permisso para alterar a ordem dos resultados da pesquisa
[GOOGLE, 2009].

Twitter
O twitter representa um dos mais recentes e bem sucedidos exemplos de redes sociais da
Web. Oferece uma API para desenvolvedores web possibilitando que os usurios acessem de
forma simples as diversas funcionalidades que a ferramenta disponibiliza a Twitter REST API
(http://apiwiki.twitter.com/Twitter-API-Documentation).
A API permite automatizar todas as funcionalidades da ferramenta que so acessadas
manualmente. A mesma torna possvel, atravs de requisies HTTP, obter tweets mensagens
enviadas de um determinado usurio, responder um usurio ou at mesmo filtrar tweets com
base em critrios pr-definidos [IBM, 2009].
Para

ilustrar

este

cenrio,

pode-se

considerar

URI

http://twitter.com/statuses/user_timeline.atom?id=liviaruback. A
mesma retorna o timeline ltima mensagem enviada em formato XML, do usurio
liviaruback.
Assim como A API REST do Google, a Twitter REST API ainda tem algumas limitaes
como o nmero mximo de 100 requisies por hora. Porm, Caso sejam necessrias mais de
100 requisies, pode-se requisitar ao twitter pertencer uma lista branca que permite aos
seus usurios mais de 100 acessos por hora [IBM, 2009].

5.4 Consideraes

Como demonstrado nas sees anteriores, a implementao de Servios Web pode ser
feita de duas maneiras: 1) da forma como a Arquitetura de Servios Web foi especificada (seo
4.5.1) ou 2) atravs de princpios da Arquitetura Orientada a Recursos (seo 4.5.2).
A Arquitetura de Servios Web baseada na viso tradicional de Servios Web (utilizando
59

SOAP, WSDL e UDDI) muito bem definida; segue regras para a troca de dados, segurana,
entre outros. J a Arquitetura Orientada a Recursos, por ser uma aplicao prtica dos conceitos
REST definidos por Fielding, segue as caractersticas de vrios estilos arquiteturais.
A principal diferena entre as duas abordagens citadas terica e no tecnolgica: A
Arquitetura de Servios Web baseada em servios, enquanto na Arquitetura Orientada a
Recursos, os servios so encarados como recursos e so identificados por uma URI.
A viso tradicional para implementao de Servios Web baseada em trocas de
mensagens no formato do protocolo SOAP e que devem seguir um contrato WSDL. Nesse
contexto, o protocolo HTTP utilizado somente para transporte. Ambos os lados cliente e
servidor precisam conhecer e entender SOAP e WSDL para desempacotar e utilizar os dados.
Dessa forma, cria-se uma abstrao da comunicao onde ferramentas devem encapsular a
informao para que o seu receptor a entenda e a processe. Alm disso, as trocas de mensagens
precisam ser envelopadas dentro de um pacote SOAP, e o que realmente utilizado uma parte
muito pequena do contedo contido no mesmo. Estas informaes desnecessrias podem
comprometer o desempenho de um sistema.
O fato que, para se construir um Servio Web necessrio apenas: um cliente, um
servio, informao, um meio de encapsular esta informao geralmente XML e de um meio
para acessar esta informao o protocolo HTTP.
De acordo com a viso arquitetural de REST, o protocolo HTTP j rico o suficiente para
que seja criada uma abstrao para a construo de servios.
A Arquitetura Orientada a Recursos faz uso unicamente do protocolo HTTP para a
comunicao, atravs do acesso direto aos mtodos nativos GET, POST, PUT, DELETE,
HEAD e OPTIONS. Como a Web baseada em HTTP, em alguns casos a utilizao de REST
mais adequada, pois aumenta a velocidade de comunicao entre os servios e conseqentemente
o desempenho geral da aplicao.
importante destacar que o paradigma REST no surgiu para substituir a viso j
existente e sim pra complementar a mesma. Quando realmente existe a necessidade de serem
manipulados vrios formatos - em vez de s XML ou quando for uma interao do tipo
aplicao-aplicao no faz sentido usar REST, mas sim a viso tradicional.
Porm, em determinadas aplicaes, REST claramente mais adequado do que a viso
tradicional, por exemplo, quando se pode ter uma interao usurio-aplicao. Um exemplo que
60

ilustra este cenrio um servio que poderia ser acessado via Ajax atravs de um browser
diretamente por um usurio.
Em casos como esse, a utilizao de REST muito mais simples. Basta ter um
conhecimento sobre o protocolo HTTP e seus mtodos invocando-os a partir de mtodos nativos
do protocolo. No exemplo descrito nas sesses anteriores, por exemplo, para se buscar
informaes sobre um determinado filme, a abordagem REST visivelmente a mais simples,
visto que a solicitao GET pode ser realizada at mesmo atravs de um browser.
Porm, para integraes em aplicaes corporativas, nas quais os servios oferecidos
devem possuir um contrato formal, serem desacoplados e reutilizveis, o paradigma REST no
a melhor opo, pois no possui um padro oficial para a descrio dos seus servios.
J no caso de servios para celulares, PDAs e outros dispositivos mveis, onde cada
requisio tem um custo relativamente alto, utilizar servios REST sem dvida a melhor opo,
devido, sobretudo simplicidade e ao desempenho. A maior prova disso tem sido a utilizao em
larga escala do paradigma por organizaes descritas anteriormente, como o Google e Twitter.

61

6 Concluso
Nos ltimos tempos, o aumento da complexidade dos sistemas de software, aliado crescente
importncia de aplicaes distribudas eficientes acarretou mudanas nos projetos dos sistemas.
Fez-se necessrio, ento, o surgimento de modelos em diferentes nveis de abstrao para a
soluo de problemas relacionados ao projeto de sistemas. A Arquitetura de Software surgiu
como o objetivo de identificar propriedades e relacionamentos relevantes em um projeto de um
sistema.
Para que o conhecimento de projeto de software fosse catalogado de maneira organizada e
til para uma futura reutilizao, surgiram os estilos arquiteturais. Os estilos arquiteturais
surgiram com a finalidade de classificar as classes de arquiteturas de software de acordo com
suas caractersticas peculiares.
Paralelo ao surgimento dos estilos arquiteturais e visando atender necessidades de
interao entre diferentes tipos de aplicaes mesmo rodando em plataformas e sistemas
operacionais diferentes, a Arquitetura de Servios Web surgiu como uma arquitetura
computacional voltada para servios Web - componentes que permitem s aplicaes enviar e
receber dados em formato XML.
A Arquitetura de Servios Web foi especificada de acordo com o protocolo SOAP
responsvel por empacotar as mensagens de requisio e resposta e com base em uma
linguagem de descrio responsvel por expor as interfaces dos Servios Web WSDL.
Atualmente, a maioria dos servios web faz uso dos padres definidos na especificao, ou seja,
as mensagens so trocadas encapsuladas pelo protocolo SOAP e seguem um contrato WSDL.
Esta maneira de manipular servios muitas vezes pode comprometer o desempenho do
sistema, visto que se gera uma camada de abstrao acima do protocolo HTTP. Alm disso, o que
realmente utilizado uma parte muito pequena do contedo contido nas mensagens.
Este trabalho apresentou um estilo arquitetural para lidar com servios web o paradigma
REST. O mesmo surgiu a partir de uma tese de doutorado de Roy Fielding em 2000 e tem
emergido como uma alternativa capaz de melhorar o desempenho das aplicaes com servios

62

Web. A aplicao prtica dos conceitos definidos por Fielding conhecida como Arquitetura
Orientada a Recursos.
A partir de um mesmo cenrio de consultas a um acervo de filmes foram ilustradas,
alm das caractersticas de ambas as abordagens, suas principais diferenas.
Embora as ferramentas e IDEs para a manipulao de servios Web ainda sejam recentes,
REST tem ganhado cada dia mais credibilidade, devido sua simplicidade e melhoria de
desempenho dos sistemas que o utilizam.

63

Referncias Bibliogrficas
[ACME. The Acme Project. 2009. Disponvel em: http://www.cs.cmu.edu/~acme/index.html.
Acesso em maio de 2009]
[AMORIM, S. S. A Tecnologia Web Services e sua Aplicao num Sistema de Gerncia de
Telecomunicaes. Dissertao (Mestrado Profissional de Engenharia de Computao) Universidade Estadual de Campinas, Instituto de Computao, Maro 2004. Disponvel em:
http://libdigi.unicamp.br/document/?code=vtls000332721. Acesso em maio de 2009]
[BELLWOOD, T. UDDI Version 2.04 API Specification. [S.l.], 2002. Disponvel em:
http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm. Acesso em maio
de 2009]
[BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P. e STAL, M. Pattern
Oriented Software Architecture: A System Of Patterns, John Wiley e Sons, 1996]
[CLEMENTS, P., et al. Documenting Software Architectures: Views and Beyond. 2 Edio.
Addison Wesley, 2001]
[CHAVEZ, CHRISTINA VON FLACH G. Linguagens de Descrio Arquitetural, Disponvel
em
https://disciplinas.dcc.ufba.br/pastas/MAT161/2006.2%20(antes%20do%20CurriculoNovo)/Proj
eto/apss2-6.ModelagemSA-ADL.ppt Acesso em junho de 2009]
[CORBA. The official CORBA standard from the OMG group. 2009. Disponvel em
http://www.omg.org/docs/formal/04-03-12.pdf. Acesso em junho de 2009]
[DCOM. [MS-DCOM]: Distributed Component Object Model (DCOM) Remote Protocol
Specification. 2009. Disponvel em http://msdn.microsoft.com/pt-br/library/cc201989(enus).aspx. Acesso em junho de 2009]
[FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software
Architectures. Dissertao de Doutorado - University of California, Irvine, 2000. Disponvel em
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Acesso em junho de
2009]
[GARLAN, David; SHAW, Mary. An Introduction to Software Architecture. Carnegie Mellon
University, 1994. Disponvel em
http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf. Acesso em maio
de 2009]
[GOOGLE, SEARCH API REST. Disponvel em
64

http://googlesystem.blogspot.com/2008/04/google-search-rest-api.html. Acesso em julho de

2009]
[IBM, Using the Twitter REST API. Disponvel em
http://www.ibm.com/developerworks/web/library/x-twitterREST/index.html?ca=drs- . Acesso
em julho de 2009]
[MICROSOFT. Application Architecture Guide 2.0. Microsoft patterns and pratices. 2008.
Disponvel em http://apparchguide.codeplex.com/. Acesso em maio de 2009]
[MEDYK, Srgio. Web Services em Gerncia de Redes. Material de Apoio. Paran, 2006
Disponvel em
http://www.ppgia.pucpr.br/~jamhour/Download/pub/Mestrado%202006/Web%20Service.pdf.
Acesso em maio de 2009]
[MEDVIDOVIC, N.; TAYLOR, R. A Classification and Comparison Framework for
Software Architecture Description Languages, IEEE Transactions on Software Engineering,
26(1), Janeiro 2000.]
[MENDES, Antonio. Arquitetura de Software, 2002. Desenvolvimento orientado para
arquitetura. Rio de Janeiro]
[MERSON, Paulo. Mini-Curso: Como documentar arquitetura de software.
https://disciplinas.dcc.ufba.br/pastas/MATA63/leitura/Merson05_minicurso_SBES1.pdf. Acesso
em maio de 2009]
[NUNES, Srgio; DAVID, Gabriel. Uma Arquitectura Web para Servios Web. Universidade
do Porto, Portugal. Disponvel em
http://repositorio.up.pt/aberto/bitstream/10216/281/2/Uma%20Arquitectura%20Web%20para%2
0Servi%C3%A7os%20Web.pdf Acesso em junho de 2009]
[OMG, I. Unified Modeling Language. [S.l.], 2008. Disponvel em: http://www.uml.org/.
Acesso em maio de 2009]
[PEREIRA, Bruno. Web Services REST. 2008. Artigo da edio 56 da Java Magazine.]
[RICHARDSON, Leonard; RUBY, Sam. RESTFul Web Services. Web Services for the real
world. OReilly Media, Sebastopol: 2007]
[RMI.
Remote
Method
Invocation
Home.
2009.
Disponvel
http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp. Acesso em junho de 2009]

em

[ROSSINI, Srgio. Servios Web Semnticos. Juiz de Fora: 2008. 80p. Monografia em Cincia
da Computao - UFJF]
[SOFTWARE
ENGINEERING
INSTITUTE,
http://www.sei.cmu.edu/architecture/index.html. Acesso em maio de 2009]
65

CarnegieMellon.

[SOUZA, JAIRO DE Mini-Curso: Tecnologias para desenvolvimento de uma arquitetura

orientada a servios, 2008. Disponvel em
http://www.semanadacomputacao.ufjf.br/arquivos.php . Acesso em junho de 2009]
[STONEBRAKER, Michael. The Case for Shared Nothing Architecture. Publicado em
Database Engineering, Volume 9, Nmero 1 (1986)]
[TOBALDINI, Ricardo Ghisi. Aplicao do Estilo Arquitetural REST a um Sistema de
Congressos. Florianpolis: 2008. Monografia em Cincias da Computao UFSC]
[VERMA, Dinesh C. Legitimate Applications of Peer-to-Peer Networks. John Wiley & Sons,
Inc, 2004. Disponvel em:
http://media.wiley.com/product_data/excerpt/98/04714636/0471463698.pdf. Acesso em maio de
2009]
[W3C. World Wide Web Consortium, 2009. Disponvel em: http://www.w3.org/. Acesso em
maio de 2009]
[WSA. Web Services Architecture, 2004. Disponvel em: http://www.w3.org/TR/wsarch/wsa.pdf. Acesso em junho de 2009]con

66