REST

FACULDADE DE TECNOLOGIA ZONA LESTE

GUILHERME DE OLIVEIRA SANTOS

VINICIUS ARAUJO RIBEIRO

Desenvolvimento de um framework para consumo de Webservice REST

em aplicaes Android

So Paulo

2013

FACULDADE DE TECNOLOGIA ZONA LESTE

GUILHERME DE OLIVEIRA SANTOS

VINICIUS ARAUJO RIBEIRO

Desenvolvimento de um framework para consumo de Webservice REST

em aplicaes Android

Trabalho de Concluso de Curso apresentado

Faculdade de Tecnologia da Zona Leste,

sob a orientao do (a) Professor (a) MSc

Wilson Vendramel, como requisito parcial

para a obteno do diploma de Graduao no

Curso de Anlise e Desenvolvimento de

Sistemas.

So Paulo

2013

RIBEIRO, Vinicius Araujo; SANTOS, Guilherme de Oliveria

Desenvolvimento de um framework para consumo de Webservice REST em

aplicaes Android / Vinicius Araujo Ribeiro, Guilherme de Oliveira Santos Faculdade de

Tecnologia da Zona Leste, So Paulo, 2013

80 p.

Orientador: Msc Wilson Vendramel

Trabalho de Concluso de Curso Faculdade de Tecnologia da Zona Leste

1. Android 2. Framework 3. Integrao de sistemas 4. Webservices 5. REST

RIBEIRO, Vinicius. A, SANTOS, Guilherme O.,Desenvolvimento de um Framework para Consumo de Webservice REST em aplicaes Android. P.80, Trabalho de Concluso de Curso, Faculdade de Tecnologia da Zona Leste, So Paulo, 2013.

RESUMO

Diversas plataformas disponibilizam API de Webservices REST para estender suas

funcionalidades e permitir uma maior interao com sistemas externos. Para o

consumo de Webservice REST no sistema operacional Android necessrio a

utilizao de bibliotecas nativas para efetuar requisies HTTP, uma abordagem que

precisa de desenvolvimento de cdigo que no pertence ao negcio. O objetivo

deste trabalho desenvolver um framework para consumo de Webservice REST

que encapsule funes genricas para ser reutilizado no desenvolvimento de

aplicaes Android, na busca de responder a seguinte questo: Como diminuir a

necessidade de cdigo no inerente ao negcio no desenvolvimento de uma

aplicao que precisa consumir Webservice REST? A hiptese levantada para sanar

essa questo a utilizao de um framework que encapsule funes comuns no

desenvolvimento de uma aplicao Android no que tange o consumo de Webservice

REST. Na execuo deste trabalho foi feito pesquisa bibliogrfica para dar

fundamentao terica sobre os assuntos tratados, tambm foi desenvolvido um

framework para simplificar o consumo de Webservices REST, encapsulando funes

comuns e oferendo uma API para o desenvolvedor utilizar no desenvolvimento de

aplicativos para o sistema operacional Android, e uma aplicao que utiliza o

framework demonstrando sua funcionalidade.

Palavras-chave: Android; Framework; Integrao de Sistemas; Webservices; REST.

RIBEIRO, Vinicius. A, SANTOS, Guilherme O., Development of a framework to

Consumption of Rest Webservices in Android Applications. P.80 Trabalho de

Concluso de Curso, Faculdade de Tecnologiada Zona Leste, So Paulo, 2013.

ABSTRACT

Several platforms provide Rest API Webservices to extend its functionality and allow

greater interaction with external products. For consuming Rest Webservice in

Android operating system is necessary to use native libraries to make HTTP

requests, an approach that needs development code that does not belong to the

business. This paper aims to develop a framework for consuming Webservie REST

that wraps generic functions to be reused in the development of Android applications,

seeking to answer the question: How to reduce the need for code not inherent in the

business in the development of an application that need to consume REST

webservice? The hypothesis to remedy this issue is to use a framework that

encapsulate common functions in the development of an Android application

regarding the consumption of REST webservice. To fulfill his work were made a

bibliographic research to give a theoretical validity about subjects addressed, was

also developed a framework to simplify the consumption of REST Webservices ,

encapsulating common functions and Offering an API for developer use in

developing applications for the Android OS and an application that uses the

framework demonstrating its functionality .

Keywords: System integration; Web Services; REST; Android; Framework.

Lista de Quadros

Quadro 1: Benefcios do reuso de software ......................................................................... 14

Quadro 2: Exemplo de URI .................................................................................................. 21

Quadro 3: Exemplo HATEOAS, ordem de compra com link para o cliente. ......................... 22

Quadro 4: Semntica CRUD/Verbos HTTP ......................................................................... 23

Quadro 5: Semntica verbo HTTP/URI ................................................................................ 24

Quadro 6: Comparao entre SOAP e REST ...................................................................... 26

Quadro 7: Mdulos do padro de projeto Service API ......................................................... 31

Quadro 8: Exemplo bsico de requisio HTTP com biblioteca nativa HttpUrlconnection .... 32

Quadro 9: Requisitos funcionais .......................................................................................... 33

Quadro 10: Mdulos do framework ...................................................................................... 35

Lista de Figuras

Figura 1: Interseco de funes comuns entre sistemas distintos. ..................................... 17

Figura 2: Exposio de servios atravs de Webservices que encapsulam uma infraestrutura

interna. ................................................................................................................................ 18

Figura 3: Interoperabilidade intrnseca na comunicao entre Webservices ........................ 19

Figura 4: Webservices expe uma interface de acesso via web para servios locais .......... 20

Figura 5: Estrutura Pattern Service API ............................................................................... 30

Figura 6: Diagrama de caso de uso ..................................................................................... 34

Figura 7: Arquitetura do Framework ..................................................................................... 35

Figura 8: Diagrama de classes ............................................................................................ 37

Figura 9: Classe Resource................................................................................................... 38

Figura 10: Exemplo de Utilizao da Classe Resource ........................................................ 38

Figura 11: Classe RestExecutor .......................................................................................... 39

Figura 12: Exemplo de Utilizao da Classe RestExecutor .................................................. 39

Figura 13: Classe HttpHeader .............................................................................................. 40

Figura 14: Exemplo de Utilizao da Classe HttpHeader ..................................................... 40

Figura 15: Interface CallBack ............................................................................................... 41

Figura 16: Exemplo de Utilizao da interface CallBack ...................................................... 41

Figura 17: Interface PostCallback ........................................................................................ 41

Figura 18: Classe Response ................................................................................................ 42

Figura 19: Entidade Resource da base de dados ................................................................ 43

Figura 20: Exemplo de vinculao de objeto a um objeto Resource .................................... 44

Figura 21: Exemplo de requisio GET................................................................................ 44

Figura 22: Diagrama de sequncia GET .............................................................................. 45

Figura 23: Fragmento 1 do diagrama de sequncia do fluxo da operao GET ................... 47




Figura 27: Exemplo de uma requisio DELETE ................................................................. 51

Figura 28: Diagrama de sequncia DELETE ....................................................................... 52

Figura 29: Fragmento 1 do diagrama de sequncia do fluxo da operao DELETE ............ 54




Figura 33: Exemplo de uma requisio PUT ........................................................................ 58

Figura 34: Diagrama de sequncia PUT .............................................................................. 59

Figura 35: Fragmento 1 do diagrama de sequncia do fluxo da operao PUT ................... 61




Figura 39: Exemplo de uma requisio POST ..................................................................... 65

Figura 40: Diagrama de sequncia POST ............................................................................ 66

Figura 41: Fragmento 1 do diagrama de sequncia do fluxo da operao POST ................ 68




Figura 45: Interface grfica da aplicao com lista de cursos existentes no Coursera ......... 73

Figura 46: Interface grfica da aplicao com detalhes de um curso no Coursera ............... 74

Figura 47: Uso do framework na aplicao do Coursera ...................................................... 75

Lista de Siglas

API - Application Programming Interface

B2B - Business-to-Business

BPEL - Business Process Execution Language

CRUD - Create, Retrieve, Update, Delete

ESB - Enterprise Service Bus

HATEOAS - Hypermedia as the Engine of Application State

HTTP - Hypertext Transfer Protocol

HTTPS - HyperText Transfer Protocol Secure

JSON - JavaScript Object Notation

MIME - Multipurpose Internet Mail Extensions

Ph.D. - Philosophiae Doctor

REST - Representation State Transfer

RSS - Really Simple Syndication

SOAP - Simple Object Access Protocol

SQL - Structured Query Language

UDDI - Universal Description Discovery and Integration

URI - Uniform Resource Identifier

URL - Uniform Resource Location

WADL - Web Application Description Language

WSDL - Web Service Description Language

XML - Extensible Markup Language

SUMRIO

1 INTRODUO.............................................................................................................. 11

2 FUNDAMENTAO TERICA .................................................................................... 14

2.1 WEBSERVICE ....................................................................................................... 17

2.2 REST (REpresentation State Transfer) .................................................................. 20

2.3 HATEOAS - Hypermedia As the Engine of Application State ................................. 22

2.4 Uniform Interface ................................................................................................... 23

2.5 POST x PUT .......................................................................................................... 24

2.6 Stateless ................................................................................................................ 25

2.7 SOAP x REST ....................................................................................................... 25

3 DESENVOLVENDO O FRAMEWORK ......................................................................... 28

3.1 O padro de projeto Service API ........................................................................... 28

3.2 Estrutura do Pattern Service API ........................................................................... 29

3.3 Consumindo Webservice REST no Android........................................................... 32

3.4 Funcionalidades do Framework ............................................................................. 33

3.5 Arquitetura do projeto ............................................................................................ 34

3.6 Classes Principais ................................................................................................. 37

3.7 Banco de Dados .................................................................................................... 42

3.7.1 Estrutura do Banco de Dados ......................................................................... 43

3.8 Exemplos bsicos: ................................................................................................. 44

3.8.1 GET: ............................................................................................................... 44

3.8.2 DELETE: ........................................................................................................ 51

3.8.3 PUT: ............................................................................................................... 58

3.8.4 POST:............................................................................................................. 65

4 DESENVOLVENDO UMA APLICAO........................................................................ 72

4.1 Pr-requisitos ........................................................................................................ 72

4.2 Funes ................................................................................................................. 73

5 CONSIDERAES FINAIS .......................................................................................... 76

6 GLOSSRIO ................................................................................................................ 77

7 REFERNCIAS ............................................................................................................ 79

1 INTRODUO

A comunicao entre diferentes dispositivos e sistemas abre um grande parque para

inovao e novos produtos.

Novas tecnologias surgem para suprir essas novas necessidades. Uma dessas

tecnologias Webservice REST (REpresentation State Transfer), um meio de obter

interoperabilidade entre diferentes sistemas atravs da exposio de recursos na

Web de maneira genrica de forma que no importa quem o fornecedor ou o

consumidor, eles podero se comunicar.

Outra tecnologia que tem levado a conectividade e a mobilidade a outros patamares

so os sistemas operacionais mveis, dentre eles o Android, sistema operacional da

Google Inc. presente em celulares, smartphones, culos e at casas e carros.

Este trabalho prope um framework para o consumo de Webservice REST em

aplicaes Android.

O consumo de Webservice REST na plataforma Android desenvolvido utilizando

as bibliotecas nativas para efetuar requisies HTTP, porm existe a necessidade do

desenvolvimento de cdigo de infraestrutura e suporte para se obter uma aplicao

com qualidade e performance, e dependendo da situao, para que possa atender

aos requisitos do negcio.

Esses cdigos de infraestrutura e suporte referem-se lgica para controle

multithread, serializao de requisies assncronas, persistncia de dados, controle

transacional, entre outras, de modo que no so relacionados ao negcio, dessa

forma estes cdigos podem ser englobados em uma biblioteca de cdigo genrica

para ser reutilizado por qualquer projeto que precise de um componente que oferea

essas funes.

12

O reuso um conceito amplamente usado em engenharia de software, o

desenvolvimento de software baseado em componentes traz grandes benefcios,

como cerca de 70% de reduo do tempo do ciclo de desenvolvimento e 84% de

reduo do custo do projeto (PRESSMAN, 2011).

Referente ao consumo de Webservice na plataforma Android; esperado que nos

prximos 5 anos as redes de celulares tenham um aumento em 40 vezes em seu

trfego e o uso de REST tem ligeira vantagem no meio mvel tendo em vista que

oferece grande performance atravs de um sistema de mensagem mais leve.

Webservice baseado em SOAP tem duas grandes desvantagens: A alta

necessidade de recursos para processar XMLs e a performance sobrecarregada e

instvel de comunicao em comparao com outras abordagens de sistemas

distribudos, tanto que a prpria Google j demonstrou no ter interesse em suportar

Webservice SOAP no Android (COBRZAN, 2010).

relevante tambm indicar que o sistema operacional Android responde por 53% do

mercado dos Estados Unidos de smartphones e, de acordo com o Google, cerca de

500.000 dispositivos Android so ativados por dia (FIAWOO, SOWAH, 2013).

Sobre o modelo de arquitetura apresentada na hiptese de soluo deste trabalho,

vlido destacar o trabalho de Dornin et al. (2012), onde apresentam os problemas do

custo do desperdcio de recursos do Android e apresentam como soluo o uso de

uma interface assncrona para a interao com a rede e o uso de persistncia local

de informaes.

O objetivo deste trabalho desenvolver um framework para consumo de Webservice

REST que encapsule funes genricas para ser reutilizado no desenvolvimento de

aplicaes Android, para responder a seguinte questo: Como diminuir a

necessidade de cdigo no inerente ao negcio no desenvolvimento de uma

aplicao que precisa consumir Webservice REST?

A hiptese levantada utilizar um framework que encapsule funes comuns no

desenvolvimento de uma aplicao Android no consumo de Webservice REST.

13

Para o desenvolvimento deste trabalho, foi realizada uma pesquisa bibliogrfica a

fim de fornecer a fundamentao terica sobre os assuntos abordados, que so

apresentados no segundo captulo e que contm tcnicas e benefcios da

engenharia de software, principalmente as estratgias de reuso, os conceitos sobre

a tecnologia de Webservices e a arquitetura REST.

O terceiro captulo apresenta o desenvolvimento de um framework para o consumo

de Webservices REST, desenvolvido em linguagem de programao Java, para o

sistema operacional Android. Neste captulo, apresentada a arquitetura do

framework, suas funcionalidades e exemplos de utilizao.

O quarto captulo mostra uma aplicao para o sistema operacional Android com a

finalidade de testar o framework desenvolvido, utilizando um Webservice externo e

demonstrando suas funcionalidades.

O quinto captulo contm as consideraes finais, resultados obtidos e proposies

futuras.

14

2 FUNDAMENTAO TERICA

Engenharia de software baseada em reuso uma abordagem de desenvolvimento

que tenta maximizar a reutilizao de software existente. As unidades de software

que podem ser reutilizadas podem ter tamanhos radicalmente diferentes como um

objeto, uma funo, componentes e at aplicaes inteiras (SOMMERVILLE, 2007).

O quadro 1 apresenta os benefcios do reuso de software.

Quadro 1: Benefcios do reuso de software

Benefcio Explicao

Aumento de confiabilidade

Software reutilizado, que j tenha sido

testado e utilizado em ambiente de

produo, mais confivel do que um

novo software porque em sua concepo

e implementao e uso falhas j foram

encontradas e corrigidas.

Diminuio do risco do processo

O custo do software existente j

conhecido, embora os custos de

desenvolvimento sejam sempre uma

questo de julgamento. Esse um fator

importante para o gerenciamento de

projetos, pois reduz a margem de erro

em estimativa de custo do projeto. Isto

particularmente verdadeiro quando os

componentes de software relativamente

grandes, tais subsistemas so

reutilizados

Continua

15

Continuao

Uso efetivo de especialistas

Em vez fazendo o mesmo trabalho mais

e mais, estes especialistas de aplicativos

podem desenvolver software reutilizveis

que encapsulam o seu conhecimento.

Cumprimento de normas

Algumas normas, como padres de

interface de usurio, podem ser

implementadas como um conjunto

padro de componentes reutilizveis.

Por exemplo, se os menus em uma

interface do usurio so implementados

usando componentes reutilizveis, todas

as aplicaes iro apresentar os

mesmos formatos de menu para os

usurios. O uso de interfaces padro

para o usurio melhora confiabilidade,

pois os usurios so menos propensos a

fazer erros quando apresentados com

uma interface familiar.

Desenvolvimento acelerado

Trazendo um sistema para o mercado o

mais cedo possvel muitas vezes mais

importante do que os custos globais de

desenvolvimento. Reutilizar software

pode acelerar o sistema de produo

porque tanto o desenvolvimento e tempo

de validao devem ser reduzidos.

Fonte: (SOMMERVILLE, 2007, p. 276, adaptado)

Ao longo dos anos, muitas tcnicas de desenvolvimento baseado em reuso foram

criadas, cada sistema possui diferentes nveis de potencial de reuso (indo desde

simples funes at aplicaes inteiras), duas dessas tcnicas so:

Desenvolvimento baseado em componentes e frameworks (SOMMERVILLE, 2007).

16

Um componente elemento funcional de um programa que incorpora a lgica e

estruturas de dados internas necessrias para o processamento, junto a uma

interface que habilita o componente a ser chamado e que dados possam ser

passados a ele (PRESSMAN, 2011).

Um framework um conjunto de classes que colaboram para realizar uma

responsabilidade para um domnio de um subsistema da aplicao, isto , um

subsistema que contm a soluo para um problema especfico (FAYAD, SCHMIDT,

1997).

De uma maneira mais especfica, um framework pode ser definido como uma

arquitetura desenvolvida com o objetivo de atingir a mxima reutilizao,

representada como um conjunto de classes abstratas e concretas, com grande

potencial de especializao (MATTSSON, 1996, p. 52).

O fato de que muitos sistemas de software contm componentes idnticos ou com

funes semelhante (que so desenvolvidos diversas vezes) nos trouxe a

necessidade do reuso (SAMETINGER, 1997).

Como apresenta a figura 1, a interseco (mesma famlia de problemas) entre

sistemas distintos, cria a oportunidade da criao de um framework, que encapsula

essa lgica de maneira genrica e fornece um componente que pode ser includo a

qualquer software que precise dessas funes (SAUV, 2011).

17

Figura 1: Interseco de funes comuns entre sistemas distintos.

Fonte: (SAUV, 2011, s. p)

2.1 WEBSERVICE

Integrao entre sistemas tem se tornado uma atividade crtica para que as

empresas mantenham a competitividade em todos os setores. A cooperao de

diferentes reas e at diferentes organizaes para a criao de produtos

complexos que atendam as necessidades tornou-se o ponto chave para a vantagem

competitiva em diferentes reas (HOBDAY, PRENCIPE, DAVIES, 2003).

Em um cenrio em que h a interao, entre diferentes empresas que precisam

integrar sistemas heterogneos e cada companhia precisa gerenciar e operar seus

prprios sistemas de software possvel oferecer essa integrao atravs do

paradigma da orientao a servios, onde funcionalidades de um software so

expostos como servios atravs de interfaces que podem ser invocado por clientes

(ALONSO, et al. , 2004).

A figura 2 apresenta esse modelo onde funcionalidades de uma infraestrutura

interna so acessadas atravs de um Webservice.

18

Figura 2: Exposio de servios atravs de Webservices que encapsulam uma infraestrutura interna.

Fonte: (ALONSO, et al., 2004, p.134, adaptado)

Mesmo que a orientao a servios seja independente a tecnologia, a plataforma

tecnolgica mais utilizada a de Webservices (ERL, 2009).

A popularidade dos Webservices precedeu a da computao orientada a servios. Como resultado, o uso inicial ocorreu principalmente em solues distribudas tradicionais, em que eles eram mais comumente usados para facilitar a integrao de canais ponto-a-ponto. medida que a maturidade e a adoo dos padres Webservices aumentaram, tambm aumentou o escopo de sua utilizao (ERL, 2009, p. 31).

Webservice uma aplicao acessvel por outra aplicao atravs da Web, a qual

promove interoperabilidade entre linguagens por meio de uma linguagem

intermediria que tanto consumidor quanto fornecedor do servio conhecem

(ALONSO, et al., 2004).

Com a lgica de servio podendo ser acessada via um framework de comunicao

neutro em relao ao fornecedor (de tecnologia), o servio se torna disponvel para

um numero maior de consumidores e transformaes de tipos de dados entre

diferentes plataformas so desnecessrias (ERL, 2009).

19

A figura 3 apresenta que com um padro de comunicao diferentes tipos de

fornecedores e consumidores podem se comunicar, pois h uma interoperabilidade

oferecida pelo padro.

Figura 3: Interoperabilidade intrnseca na comunicao entre Webservices

Fonte: (ERL, 2009, p. 32, adaptado)

Webservices so desenvolvidos com um uso especfico em mente: a de serem pontos de entrada para o sistema local. Assim, o principal uso de um Webservice o de expor (atravs da interface) a funcionalidade interna, deixando o sistema visvel e acessvel atravs da Web, de forma controlada. Webservices so, portanto, anlogas s wrappers sofisticados que encapsulam uma ou mais aplicaes, fornecendo uma interface nica e um acesso Web (ALONSO, et al., 2004, p. 134).

A figura 4 mostra esta abordagem, onde o cliente acessa os servios internos de um

fornecedor atravs de Webservices disponveis na internet.

20

Figura 4: Webservices expe uma interface de acesso via web para servios locais

Fonte: (ALONSO, et al., 2004, p.135, adaptado)

2.2 REST (REpresentation State Transfer)

O termo REST foi criado por Roy Fielding em sua dissertao de Ph.D., que pelo

prprio autor definido como estilo arquitetural para sistemas de hipermdia

distribudos (FIELDING, 2000, p. 76), isso significa que um estilo de arquitetura de

software; uma maneira de desenho da soluo para que hipermdias (udio, vdeo,

imagem, texto) sejam armazenadas e interconectadas pela rede atravs de

hyperlinks, um exemplo deste modelo maior rede hipermdia do mundo, a World

Wide Web (KALIM, 2009).

O acrnimo REST significa REpresentational State Transfer (Transferncia de

estado da representao), e representa efetivamente o envio de uma representao

de alguma informao em certo momento, este pedao de informao identificada

por um hyperlink o conceito de recurso (RICHARDSON, RUBY, 2009).

Um recurso qualquer coisa que seja importante o suficiente para que seja criado

um hyperlink para referenci-lo, qualquer pedao de informao a qual tenha um

hyperlink um recurso, essa propriedade chamada de adressability

(RICHARDSON, RUBY, 2009).

21

Um recurso depende de um hyperlink para estar na Web, precisa ter um endereo,

este endereo uma URI (Uniform Resource Identifier) (RICHARDSON, RUBY,

2009).

Uma URI deve ser descritiva, deve identificar o recurso de maneira intuitiva, por

exemplo, em uma aplicao de uma loja, para um recurso chamado produto, sua

URI deve identificar este produto (RICHARDSON, RUBY, 2009).

O quadro 2 apresenta um exemplo, onde possvel identificar que a URI referencia

a release 1.0.3 do software.

Quadro 2: Exemplo de URI

http://www.example.com/software/releases/1.0.3.tar.gz

Fonte: (RICHARDSON, RUBY, 2009, p. 83)

URIs devem ter uma estrutura, devem identificar nomes para que o recurso possa

ser interpretado. A sintaxe da URI deve ser utilizada como a navegao em um

sistemas de arquivos hierrquico. Esta restrio no descrita e no uma regra

absoluta no modelo REST, mas orientado fortemente que as URIs sejam

construdas desta maneira (RICHARDSON, RUBY, 2009).

Uma URI deve ser organizada hierarquicamente, com os componentes em ordem

decrescente de significncia da esquerda para direita (MASINTER, BERNERS-LEE,

FIELDING, 2005). Um recurso contm uma URI, um hyperlink a qual ser utilizado

por um cliente para solicitar um pedao de informao a um servidor.

Esta informao que ser transferida a representao do recurso naquele dado

momento.

Os tipo MIME (Multipurpose Internet Mail Extensions) presentes no protocolo HTTP

podem descrever em qual formato essa representao ser transferida, se uma

imagem, um texto, udio, vdeo. (RICHARDSON, RUBY ,2009).

22

2.3 HATEOAS - Hypermedia As the Engine of Application State

Um Webservice REST no um endpoint, mas uma rede de recursos

interconectados, com um modelo de hipermdia que no determina somente

relaes entre diferentes recursos, mas a possibilidade de conectar e navegar entre

os recursos (ALARCON, BELLIDO, WILDE, 2011).

Outros estados (de recursos) podem ser embutidos na representao de um recurso

atravs de um link, esses links podem ser descobertos dinamicamente e utilizados

para acessar outros recursos (PAUTASSO, 2009).

O quadro 3 d um exemplo deste comportamento onde a ordem de compra de um

servio de e-commerce contm referncias (links) para outros recursos.

Quadro 3: Exemplo HATEOAS, ordem de compra com link para o cliente.

http://customers.myintranet.com/customer/32133 5

http://products.myintranet.com/product/111

Fonte: (BURKE, 2010. p. 11, adaptado)

Esse conceito de navegao entre recursos atravs de hyperlinks carregados pela

representao do recurso chamado de HATEOAS (FIELDING, 2000).

23

2.4 Uniform Interface

Uma vez que um recurso tenha sido identificado, o conjunto de operaes que

podem ser aplicadas a ele fixo, atravs dos quatro mtodos (ou verbos): PUT,

GET, POST e DELETE do protocolo HTTP. Estas operaes semelhantes ao CRUD

(Create, Retrieve, Update e Delete (do ingls, criar, ler, atualizar e apagar)) se

aplicam a todos os recursos com semntica semelhantes. Cada um destes mtodos

invocado sobre um recurso usando uma requisio HTTP (PAUTASSO, 2009).

As operaes CRUD fornecem aes para interagir com os recursos, o quadro 4

apresenta como o protocolo HTTP fornece as mesmas operaes com quatros

verbos (GET, POST, PUT, DELETE) (KALIM, 2009).

Quadro 4: Semntica CRUD/Verbos HTTP

Retrieve - Ler um recurso (GET) Create - Criar um recurso (POST em uma URI j existente, PUT em uma nova URI) Update - Atualizar um recurso (PUT em uma URI j existente) Delete - Deletar um recurso (DELETE)

Fonte: (KALIM, 2009, p. 122, adaptado)

O quadro 5 mostra que utilizando os verbos HTTP e uma URI possvel criar

diversas interaes entre o cliente e o servidor:

24

Quadro 5: Semntica verbo HTTP/URI

Verbo HTTP URI Significado

POST empregados

Cria um novo empregado

de acordo com as

informaes passadas

GET empregados L uma lista de todos os

empregados

GET empregados?id=27 L o empregado com id

27

PUT Empregados

Atualiza toda a lista de

empregados de acordo

com as informaes

passadas

DELETE Empregados Deleta a lista de

empregados

DELETE empregados?id=27 Deleta o empregado com

id 27

Fonte: (KALIM, 2009, p.125 adaptado)

2.5 POST x PUT

POST e PUT contm diferenas sutis, um cliente utiliza PUT quando ele ir decidir

qual URI o novo recurso ter, mas o cliente ir utilizar POST quando o servidor ir

decidir qual ser a URI do novo recurso (RICHARDSON, RUBY, 2009).

25

O verbo POST utilizado para criao de recursos subordinados (PAUTASSO,

2009).

Por exemplo, em um tpico em um frum, um recurso que representa o tpico

(/frum/meutopico), quando um cliente faz cria um comentrio no tpico ele executa

um POST nesta URI j existente (/frum/meutopico), o servidor quem deve decidir

qual URI essa postagem ter, como por exemplo /frum/meutopico/comentarios/1. O

cliente no tem o poder de indicar como ser formado a URI que representa o novo

comentrio (recurso), porm o cliente pode criar um tpico, nomeando-o, e assim

decidir qual URI esse tpico ter. Neste caso ele deve executar um PUT em uma

nova URI (/frum/novotopico) (RICHARDSON, RUBY, 2009).

2.6 Stateless

A caracterstica Stateless (sem estado) indica que cada interao entre cliente e o

servidor deve conter toda a informao necessria para processar a requisio, ou

seja, no deve depender de nenhuma outra informao salva no servidor em alguma

outra operao. Essa propriedade melhora na visibilidade, pois o sistema de controle

no precisa ter a viso alm da prpria requisio. Tambm melhora confiabilidade

(pois mais fcil de recuperar uma falha parcial, que ocorreu apenas em uma

requisio) e em escalabilidade, pois simplifica a aplicao tendo em vista que o

servidor no precisa armazenar estados e gerenciar recursos entre as requisies

(FIELDING, 2000).

2.7 SOAP x REST

Webservices podem ser classificados em duas categorias principais: RESTful e

baseado em SOAP. Esta classificao baseada no estilo arquitetural e na

tecnologia utilizada (FEDA, KLAUS, 2010).

26

Em um trabalho de comparao, o resultado obtido do experimento de

manutenibilidade entre as duas abordagens demonstrou que REST mais

manutenvel do lado do servidor e que Webservices SOAP so mais manutenveis

do lado do cliente (OLIVEIRA, 2012).

De modo geral os servios WS-* tm a vantagem de ser bastante difundidos atualmente nas empresas e organizaes de grande porte, ideais em circunstncias que envolvem diferentes protocolos de comunicao; em ferramentas middleware utilizadas na integrao de sistemas complexos e de diferentes arquiteturas (BPEL, ESB). Servios RESTful, por outro lado, tm uma boa resposta em utilizaes que envolvam manipulaes de dados onde resgatam as caractersticas da Web. Recomenda-se em aplicaes mobile, onde o custo na troca de mensagens bastante elevado; em blogs e sites de relacionamento, os quais so baseados em recursos e demandam de chamadas RSS ou Atom; em servios de busca na

internet, que trabalham com um alto trfego de informaes (DAL MORO, DORNELES, TRINDADE, 2009, p. 14).

O quadro 6 apresenta um quadro comparativo entre os diferentes estilos de

Webservices, REST e SOAP.

Quadro 6: Comparao entre SOAP e REST

Critrio SOAP REST

Cliente/Servidor Alto acoplamento Baixo acoplamento

URI Uma URI representa o

endpoint

Uma URI para cada

recurso

Camada de Transporte

(Protocolo) Qualquer HTTP

Continua

27

Continuao

Cache No suporta Suporta

Interface No uniforme, descrita em

um documento (WSDL) Interface Uniforme

Tipo de dados

Qualquer, mas binrios

necessria converso em

anexo.

Qualquer tipo diretamente

Informao da operao

(mtodo) No corpo da mensagem Mtodo HTTP

Passagem de informao Informaes passadas no

corpo da mensagem

Informaes passadas no

corpo da mensagem e na

URI

Documento descritor WSDL WADL

Escalabilidade No expansvel sem criar

um novos webservices

Expansvel sem ser

necessrio criar novos

webservices

Padres utilizados

Padres especficos do

SOAP (WSDL, UDDI, WS-

Security)

Padres da WEB (URL,

HTTP, XML, MIME Types)

Segurana Especificao WS-

Security Segurana HTTP

Fonte: (FEDA, KLAUS, 2010, p 174 adaptado)

28

3 DESENVOLVENDO O FRAMEWORK

Nesta seo ser apresentado o desenvolvimento do framework, sua arquitetura,

requisitos e exemplos de utilizao:

3.1 O padro de projeto Service API

O projeto baseado em um padro de projeto descrito pelo engenheiro de software

da Google Inc., Virgil Dobjanschi, chamado de Service API.

O padro de projeto foi criado para auxiliar os desenvolvedores a criar aplicaes

mais robustas com relao ao consumo de Webservice REST. A abordagem

tradicional continha dois grandes problemas, a qual o padro de projeto foi feito para

tratar.

O primeiro referente ao gerenciamento de threads em paralelo pelo sistema

operacional Android. Ao ter a necessidade de consumir um Webservice, natural

pensar em problemas sobre a comunicao tendo em vista que a comunicao com

o servidor, o tratamento da resposta, o estado da rede, tudo pode ser demorado; a

abordagem normal a de executar a requisio em uma thread separada da thread

principal, porm no Android as threads criadas de maneira convencional no fazem

parte do ciclo de vida dos processos do sistema operacional, e o Android, caso

necessrio, ir encerrar a thread sem o processamento terminar. Para sanar esse

problema necessrio a criao de um componente especfico, chamado Service

(ou uma de suas variaes como AsyncTask, IntentService), esse componente

conhecido e gerenciado pelo sistema operacional, utilizado exatamente para

execues em segundo plano de longa durao e o Android no ir encerrar este

processo de maneira abrupta (DOBJANSCHI, 2010).

29

O segundo problema com relao persistncia de dados. Manter os dados

obtidos pelo Webservice somente na memria voltil do dispositivo pode ser

altamente custoso, pois caso a aplicao seja encerrada, o dispositivo seja

desligado ou outro fator que faa com que os dados sejam perdidos, ser necessrio

executar novamente as requisies pela Web para recuperar os dados, causando

grande gasto de recursos como bateria, dados, memria e processamento de

maneira desnecessria (DOBJANSCHI, 2010).

3.2 Estrutura do Pattern Service API

O pattern Service API estruturado em componentes com funes distintas, a figura

5 mostra cada componente e a interao entre os componentes:

30

Figura 5: Estrutura Pattern Service API

Fonte: (DOBJANSCHI, 2010, s. p., adaptado)

O quadro 7 apresenta uma breve explanao sobre cada mdulo descrito no padro

Service API.

31

Quadro 7: Mdulos do padro de projeto Service API

Mdulo Explicao

Rest Method

Responsvel por preparar a requisio

HTTP, tanto a URI quanto o corpo da

mensagem, alm da execuo da

requisio e processar a resposta.

Processor

O Processor utilizado para efetuar

controle das requisies efetuando

incluses de flags sobre se uma

requisio est sendo executada e se foi

finalizada.

Service

Responsvel por receber requisies do

componente Service Helper e invocar a

requisio correspondente ao Rest

Method, deve tambm executar

Callbacks para Service Helper.

Service Helper

Expe uma API assncrona para ser

utilizada pela Activity, deve fazer

validaes iniciais sobre a requisio (se

existe comunicao com a rede, por

exemplo), verifica se requisio esta

pendente, cria componente

Intent(utilizado para invocar o

componente Service), adiciona id

requisio, adiciona parmetros

especficos da requisio (como

informaes para autenticao), retorna

ID da requisio para o chamador e

deve executar Callback para Activity.

Continua

32

Continuao

Activity

A Activity o componente que

representa a tela que interage com o

usurio, Virgil Dobjanschi orienta sobre o

ciclo de vida da Activity, o qual deve ter

manipuladores das requisies sobre os

estados da Activity(onResume, onPause,

etc..).

ContentProvider e CursosAdapter

Gerenciam o acesso a uma estrutura de

dados.

Fonte: (DOBJANSCHI, 2010, s. p., adaptado)

3.3 Consumindo Webservice REST no Android

O consumo de Webservice no Android feito utilizando as bibliotecas nativas para

executar requisies HTTP, o quadro 8 apresenta um exemplo de uma requisio

bsica.

Quadro 8: Exemplo bsico de requisio HTTP com biblioteca nativa HttpUrlconnection

Fonte: Developer Android, s,d,, s,p.

Diversas outras funcionalidades devem ser desenvolvidas, funes relacionadas

segurana, tratamento de resposta, controle multithread, controle transacional.

33

3.4 Funcionalidades do Framework

O framework encapsula funes genricas e expe uma API para ser utilizada pela

aplicao, as funcionalidades encapsuladas so apresentadas no quadro 9 onde so

descritos os requisitos funcionais:

Quadro 9: Requisitos funcionais

Requisito Descrio

API assncrona para o consumo

de Webservice REST sobre o

protocolo HTTP.

O framework deve expor uma API para executar

requisies HTTP para Webservice REST. Esta

API deve conter mtodos para a execuo dos

verbos HTTP para cada operao CRUD,

representados no protocolo HTTP pelos os

verbos GET, POST, PUT e DELETE.

Serializao de chamadas

assncronas

Tendo em vista que as requisies HTTP sero

assncronas, necessrio garantir a integridade

dos dados, pois requisies como POST,

DELETE e PUT afetam a representao do

recurso no servidor. A serializao deve manter

a integridade dos dados de forma que

operaes sobre o mesmo recurso devem ser

serializadas para que executem na mesma

ordem a qual foram requisitadas.

Persistncia e recuperao de

dados offline

O framework deve persistir dados das

requisies para recuperao offline, para

continuidade da execuo da aplicao em

casos de erros, perda do sinal, indisponibilidade

de acesso rede, etc.

Continua

34

Continuao

O framework deve controlar a

execuo de mltiplas threads e

do componente Service (utilizado

para execues em segundo

plano de longa durao).

O framework deve garantir o inicio da execuo

do componente Service em uma nova thread

quando necessrio e deve garantir a liberao

dos recursos quando no for mais necessrio.

Fonte: Os autores, 2013.

A figura 6 apresenta os requisitos em forma de um diagrama de caso de uso:

Figura 6: Diagrama de caso de uso


3.5 Arquitetura do projeto

O framework se baseia no modelo de Virgil Dobjanschi e contm uma arquitetura

interna semelhante, a figura 6 apresenta os componentes do framework:

35

Figura 7: Arquitetura do Framework


O quadro 10 apresenta cada mdulo e sua funo.

Quadro 10: Mdulos do framework

Mdulo Funo

RestExecutor

Expe a API assncrona para ser

utilizado pela aplicao, alm de efetuar

validaes iniciais para a requisio.

ServiceHelper

Recebe chamada do RestExecutor, faz

validaes secundrias e decide se a

operao ser executada, tem a funo

de iniciar a nova thread em um

componente ServiceExecutor (o qual

corresponde ao Service, componente do

sistema operacional Android para

execues de longa durao em

segundo plano).

Tambm tem a funo de persistir o

recurso incluindo uma flag indicando que

o objeto est sendo processado, alm de

informar o chamador que a operao foi

encaminhada.

Continua

36

Continuao

ServiceExecutor

Junto com ServiceHelper, orquestra a

requisio ao Webservice, cria objetos

para requisio com chamada ao

HTTPHelper, solicita a execuo da

requisio HTTP ao HTTPExecutor, cria

objetos para resposta com chamadas ao

HTTPHelper, persiste dados com

chamadas ao PersistExecutor, executa

Callbacks para aplicao quando a

requisio est terminada.

Persist Executor

Responsvel por efetuar persistncia de

dados em banco de dados local.

HTTPExecutor

Responsvel por preparar e executar as

requisies HTTP, alm de preparar as

respostas obtidas.

HTTPHelper

Prepara objetos para requisies HTTP,

utiliza o Parser para transformaes de

objetos Java para texto (XML,JSON,

etc.), que sero introduzidos no corpo

das mensagens HTTP.

Prepara objetos para resposta HTTP,

utiliza o Parser para transformaes de

texto (XML, JSON) para objetos Java,

que sero retornados para o solicitante.

Parser

Efetua transformao de objetos Java

para texto XML e JSON, e vice-versa.


37

3.6 Classes Principais

A figura 8 ilustra o diagrama de classes do framework:


Figura 8: Diagrama de classes

38

A classe Resource a principal classe do framework, nela vinculado um objeto da

aplicao com a maneira de acessar a representao deste objeto no servidor,

sendo isto uma URI, e possveis campos em um cabealho HTTP.

A figura 9 apresenta os detalhes da classe.

Figura 9: Classe Resource

Fonte: Os autores, 2013

A figura 10 apresenta um exemplo de utilizao, onde um objeto do tipo produto

vinculado ao recm-criado recurso. A partir deste momento temos um objeto da

aplicao (produto1) vinculado a um recurso (recursoProduto1), dessa forma

possvel efetuar requisies HTTP atravs da URI informada.

Figura 10: Exemplo de Utilizao da Classe Resource


A classe RestExecutor representa um singleton o qual expe a API assncrona para

requisies HTTP.

39

A figura 11 apresenta detalhes da classe que contm mtodos para as chamadas

aos quatro verbos HTTP utilizados no projeto e solicita sobre qual objeto efetuar a

operao.

Figura 11: Classe RestExecutor


A figura 12 demonstra a utilizao da API, executando o verbo GET do protocolo

HTTP atravs do mtodo GET do objeto (alm da implementao annima de um

Callback).

Figura 12: Exemplo de Utilizao da Classe RestExecutor


A Classe HttpHeader contm informaes que devem ser adicionadas ao cabealho

HTTP para efetuar a requisio, como por exemplo, informaes de localidade ou

para autenticao. A figura 13 apresenta a estrutura interna da classe.

40

Figura 13: Classe HttpHeader


A figura 14 contm um exemplo, onde anexado um recurso um novo objeto do

tipo HttpHeader, nele foi includo uma nova informao a ser adicionada ao

cabealho da requisio HTTP.

Figura 14: Exemplo de Utilizao da Classe HttpHeader


A interface Callback utilizada para criar callbacks que sero invocados ao receber

a resposta do servidor sobre a requisio, criado na chamada do mtodo na API

assncrona pela aplicao, a figura 15 contm a definio da interface.

41

Figura 15: Interface CallBack


A figura 16 apresenta uma implementao annima da interface, a qual ser

invocada quando a requisio HTTP for terminada.

Figura 16: Exemplo de Utilizao da interface CallBack


A interface PostCallback semelhante interface Callback, porm utilizado em

uma chamada ao POST, esta interface entrega aplicao a nova URI criada para o

novo recurso, a figura 17 contm a definio da interface PostCallback.

Figura 17: Interface PostCallback


42

A classe Response contm a resposta do servidor sobre a requisio HTTP,

utilizada pela aplicao no callback para recuperar informaes como cdigo de

resposta da operao e o objeto retornado, a figura 18 contm a especificao da

classe Response.

Figura 18: Classe Response


3.7 Banco de Dados

O framework deve persistir dados para acesso offline, para tal ele contm um banco

de dados genrico que armazena os recursos utilizados pela aplicao cliente.

Para o funcionamento do framework, o banco de dados tambm armazena o vnculo

entre um objeto da aplicao e um objeto do tipo Resource (que contm as

informaes necessrias para acessar a representao do objeto em um servidor),

43

permitindo chamadas transparentes diretamente do objeto da aplicao.

3.7.1 Estrutura do Banco de Dados

O sistema operacional Android contm um banco de dados nativo chamado SQLite,

o qual ser utilizado no projeto. O banco de dados contm somente uma tabela, a

qual apresentada na figura 19.

Figura 19: Entidade Resource da base de dados


44

3.8 Exemplos bsicos:

Nesta seo so apresentados exemplos bsicos da utilizao com as quatro

operaes CRUD, utilizando os verbos HTTP: GET, POST, PUT, e DELETE,

seguidos de diagramas de sequncia que demonstram o fluxo executado no

framework:

3.8.1 GET:

A figura 20 apresenta o vnculo de um objeto da aplicao um objeto recurso, a

figura 21 demonstra a invocao do verbo GET do protocolo HTTP, atravs da

execuo do mtodo get do objeto restExecutor.

Figura 20: Exemplo de vinculao de objeto a um objeto Resource

Fonte: Os autores

Figura 21: Exemplo de requisio GET


A figura 22 contm um digrama de sequencia fragmentado que demonstra o fluxo da

operao GET, as figuras 23, 24, 25 e 26 complementam os fragmentos.

45

Figura 22: Diagrama de sequncia GET


46

A figura 23 (Fragmento 1 do diagrama de sequncia do fluxo da operao GET)

contm a busca pelo recurso vinculado ao objeto na base de dados (mtodo

findResourceByObjectKey()) e a persistncia de atualizaes sobre o objeto

proveniente da aplicao (mtodo persistResource()).

A figura 24 (Fragmento 2 do diagrama de sequncia do fluxo da operao GET) inicia

a preparao para executar o mtodo HTTP GET (mtodo invokeMethod) e tem a

solicitao para processar a requisio HTTP em uma nova thread (mtodo

startService()).


contm o inicio do processamento j na nova thread (mdoto onHandleIntent()) e a

requisio ao servidor pelo HttpExecutor (mtodo openUrlConnection()), alm do

processamento da resposta(mtodo generateResponse()).


contm a preparao (mtodo transformContentResponseInObject()) e execuo

(mtodo sendBroadcast()) dos callbacks vinculados quele recurso.

47

Figura 15: Parte 1 do diagrama de sequncia do fluxo da operao GET


Figura 23: Fragmento 1 do diagrama de sequncia do fluxo da operao GET

48



49



50



51

3.8.2 DELETE:

A figura 27 demonstra a chamada execuo do verbo DELETE do protocolo HTTP,

atravs da execuo do mtodo delete do objeto restExecutor.

Figura 27: Exemplo de uma requisio DELETE



operao DELETE, as figuras 29, 30, 31 e 32 complementam os fragmentos.

52

Figura 28: Diagrama de sequncia DELETE


53

A figura 29 (Fragmento 1 do diagrama de sequncia do fluxo da operao DELETE)





inicia a preparao para executar o mtodo HTTP DELETE (mtodo invokeMethod)

e tem a solicitao para processar a requisio HTTP em uma nova thread (mtodo

startService()).








54

Figura 29: Fragmento 1 do diagrama de sequncia do fluxo da operao DELETE


55



56



57



58

3.8.3 PUT:

A figura 33 demonstra a vinculao de um objeto cliente um objeto recurso, alm

da execuo da operao PUT atravs no mtodo homnimo do objeto

restExecutor:

Figura 33: Exemplo de uma requisio PUT



operao PUT, as figuras 35, 36, 37 e 38 complementam os fragmentos.

59

Figura 34: Diagrama de sequncia PUT


60

A figura 35 (Fragmento 1 do diagrama de sequncia do fluxo da operao PUT)





inicia a preparao para executar o mtodo HTTP PUT (mtodo invokeMethod) e

tem a solicitao para processar a requisio HTTP em uma nova thread (mtodo

startService()).








61

Figura 35: Fragmento 1 do diagrama de sequncia do fluxo da operao PUT


62



63



64



65

3.8.4 POST:

A chamada ao POST um pouco diferente, tendo em vista que sua funo criar

um recurso vinculado a outro e que a definio da URI deve ser feita pelo servidor, o

POST executado sobre o "recurso pai" e repassado qual recurso deve ser

vinculado ele. A URI do novo recurso repassada no Callback.

A figura 39 demonstra a execuo de uma operao POST.

Figura 39: Exemplo de uma requisio POST



operao POST, as figuras 41, 42, 43 e 44 complementam os fragmentos.

66

Figura 40: Diagrama de sequncia POST


67

A figura 41 (Fragmento 1 do diagrama de sequncia do fluxo da operao POST)





inicia a preparao para executar o mtodo PUT e tem a solicitao para processar

a requisio HTTP em uma nova thread (mtodo startService()).





A figura 44 (Par Fragmento te 4 do diagrama de sequncia do fluxo da operao

POST) contm a preparao (mtodo transformContentResponseInObject()) e

execuo (mtodo sendBroadcast()) dos callbacks vinculados quele recurso.

68

Figura 41: Fragmento 1 do diagrama de sequncia do fluxo da operao POST


69



70



71



72

4 DESENVOLVENDO UMA APLICAO

Este captulo apresenta um aplicativo criado utilizando o framework. A aplicao

utiliza servios expostos do http://coursera.org/ para duas funes: Listar cursos

existentes e exibir detalhes de um curso selecionado.

Coursera uma empresa de educao que tem parceria com as melhores

universidades e organizaes em todo o mundo para oferecer cursos on-line para

que todos possam acessar de forma gratuita (COURSERA, 2013).

4.1 Pr-requisitos

Para desenvolver a aplicao so necessrios alguns pr-requisitos relacionados a

funcionalidade do framework:

1 Adicionar o arquivo jar do framework ao projeto da aplicao, para utilizar as

classes do framework.

2 Adicionar a biblioteca Gson ao projeto, esta biblioteca utilizada pelo framework

como motor de transformao entre objetos Java para JSON e vice-versa.

3 Registrar no arquivo de descrio da aplicao (AndroidManifest.xml) o

componente Service utilizado pelo framework (para processamentos assincronos em

segundo plano).

4 Registrar na aplicao o componente BroadCasterReceiver com a tag do

framework (para que a aplicao possa receber os callbacks do framework).

73

4.2 Funes

Esta aplicao apenas um prottipo e serve apenas como teste de validao do

framework, dessa forma a aplicao tem apenas duas funes:

1. Listar cursos existentes

A figura 45 apresenta a interface grfica que corresponde a lista de cursos, a URI

utilizada para receber a lista de cursos, disponibilizada pela plataforma do Coursera

(foi limitado o nmero de cursos exibidos de maneira hardcoded devido ao grande

nmero de resultados que retornado e por ser apenas uma aplicao de teste).

Figura 45: Interface grfica da aplicao com lista de cursos existentes no Coursera


74

2. Exibir detalhes de um curso selecionado

A figura 46 contm a interface grfica que apresenta os detalhes de um curso

selecionado na lista, a URI utilizada pra receber as informaes especficas de um

curso, disponibilizada pela plataforma do Coursera :

https://www.coursera.org/maestro/api/topic/information?topic-id=algs4partI

Onde algs4partI o id que identifica o curso e deve ser passada como valor do

parmetro topic-id.

Figura 46: Interface grfica da aplicao com detalhes de um curso no Coursera


75

Na figura 47 apresentado todo o cdigo utilizado na aplicao, com relao

requisio HTTP, para buscar um curso.

Figura 47: Uso do framework na aplicao do Coursera


76

5 CONSIDERAES FINAIS

O consumo de Webservices no sistema operacional Android uma tarefa complexa

e que demanda bastante cdigo no inerente ao negcio apenas para suportar a

funo.

Ao desenvolver a aplicao foi possvel consumir Webservices sem a necessidade

de utilizar as bibliotecas bsicas para requisio HTTP presente no sistema

operacional Android. As funes de consumo de Webservice referentes ao

processamento de metadados (JSON), persistncia local das informaes,

gerenciamento de thread (com relao ao consumo de servio) e dos componentes

do sistema operacional Android que permitem a execuo assncrona foram

totalmente encapsulados pelo framework e sendo totalmente transparente

aplicao e ao desenvolvedor (que se limita a atender aos pr-requisitos descritos

no desenvolvimento da aplicao).

Utilizando somente a API oferecida pelo framework foi possvel consumir servios,

promovendo um grande reuso de cdigo e consequentemente, um menor esforo no

desenvolvimento.

Para tornar o framework um produto robusto para utilizao em maior escala so

necessrios outros tipos de teste, resultando em possveis melhorias, dentre as

quais o tratamento de erros.

O framework necessita ser mais transparente aplicao, principalmente para

eliminar a necessidade de registrar o objeto da aplicao ao recurso por meio da

chamada um mtodo. Tambm necessrio o desenvolvimento de mdulos para

configurao, tornando o framework mais verstil, e funes de segurana,

implementando conexes HTTPS e criptografia.

77

6 GLOSSRIO

Activity - Componente do sistema operacional Android que geralmente representa

uma tela da aplicao.

Android - Android um sistema operacional baseado no ncleo do Linux6 para

dispositivos mveis, desenvolvido pela Open Handset Alliance, liderada pelo Google

e outras empresas.

Atom - Protocolo de contedo da Web baseado em XML

AsyncTask - Componente do sistema operacional Android utilizado para executar

operaes em segundo plano.

BinderCallback - Compenente do sistema operacional Android para efetuar

callbacks atravs de Intents

BPEL - Linguagem executvel para especificar aes de processos de negcios

dentro de web services.

BroadCasterReceiver - Componente do sistema operacional Android para efetuar

multiplas notificaes a diversos elementos da plataforma.

Callback - Cdigo que esperado que se execute ao final de determinado

processamento.

ContentObserver - Componente do sistema operacional Android que recebe

callbacks.

ContentProvider - Componente do sistema operacional Android que gerencia o

acesso a uma estrutuda de dados.

CursorAdapter - Componente do sistema operacional Android que adapta diversos

elementos como listas.

Endpoint - Ponto de acesso de determinada aplicao

78

Gson - Biblioteca de cdigos em Java desenvolvida pela Google Inc. para converso

de objetos Java em represetaes JSON e vice-versa.

Implementao annima - Implementao (e instanciao de um objeto)de uma

classe que no contm nome e utilizada somente localmente.

Intent - Componente do sistema operacional Android que indica a solicitao de

execuo de alguma ao.

IntentService - Componente do sistema operacional Android que solicita a

execuo de uma ao assncrona (atravs de um Intent)

JSON - um formato leve para intercmbio de dados computacionais.

Service - Componente do sistema operacional Android utilizado para executar

operaes em segundo plano, geralmente vinculado a um processo que deve

executar por tempo indeterminado.

Singleton - Padro garante a existncia de apenas uma instncia de uma classe,

mantendo um ponto global de acesso ao seu objeto.

SQLite - Banco de dados nativo no sistema operacional Android

UDDI - Servio de diretrio onde possvel publicar e descobrir Webservices

WADL - Documento XML que descreve aplicaes Webservices baseadas na

arquitetura REST

WS-* - Conjunto de especificaes para Webservices

WS-Security - Especificao para diretrizes de segurana para Webservices

WSDL - Documento XML que descreve aplicaes Webservices baseadas em

SOAP

79

7 REFERNCIAS

ALONSO, Gustavo; CASATI, Fabio; KUNO, Harumi; MACHIRAJU, Vijay. Web

Services Concepts, Architectures and Applications. Berlin: Springer, 2004.

ALARCON, Rosa; BELLIDO, Jesus; WILDE, Erik. Hypermedia-driven RESTful service composition in Service-Oriented Computing. Berlin: Springer, 2011. BURKE, Bill. RESTful Java with Jax-RS. Sebastopol: O'Reilly, 2010.

COBRZAN, Alin. Consuming Web Services on Mobile Platform, Faculty of Economic Sciences. Cluj-Napoca: Informatica Economica Journal, 2010. COURSERA, About us, https://www.coursera.org/about, acessado: 24.Outubro.2013 s 12h14. DAL MORO, Tharcis; DORNELES, Carina Friedrich; TRINDADE, Marcelo. Web services WS-* versus Web Services REST, Rio Grande do Sul: Universidade de Passo Fundo, 2009. DEVELOPER ANDROID, s.d; Disponvel em: http://developer.android.com/reference/java/net/HttpURLConnection.html, acessado: 07. Maio. 2013 s 12h14. DOBJANSCHI, Virgil. Developing Android REST Client Applications. s,d. Disponivel em: https://dl.google.com/googleio/2010/android-developing-RESTful-android-apps.pdf. Acesso em: 07.Maio.2013 s 12h14. DORNIN, Laird; MEDNIEKS Zigurd, MEIKE G. Blake, NAKAMURA, Masumi, Programming Android: Java Programming for the New Generation of Mobile Devices. Sebastopol: O'Reilly , 2012. ERL, Thomas. SOA Princpios e Design, So Paulo: Pearson Education do Brasil, 2009.

FAYAD, Mohamed E., SCHMIDT, Douglas C. Object-oriented Application

frameworks. Communications of the ACM, Vol. 40, 1997.

FEDA AlShahwan, KLAUS Moessner. Providing SOAP Web Services and RESTful Web Services from Mobile Hosts. Guildford: University of Surrey, 2010. FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectues. Irvine, Estados Unidos. University of California, 2000. 161. Dissertao, Doctor of Philosophy in Information and Computer Science. FIAWOO Seth Y., SOWAH Robert A., Design and Development of a Web Service for Android Applications for Extensive Data Processing, Accra: University of

80

Ghana, 2013. HOBDAY, Michael, PRENCIPE, Andrea; DAVIES, Andrew; The Business Of Systems Integration. Oxford: Oxford University Press, 2003. JOHNSON, Ralph E. Frameworks=(components+patterns). Communications of

the ACM, v. 40, n. 10, p. 39-42, Ralph.

KALIM, Martin. Java Web Services: Up and Running. Sebastopol: OReally, 2009.

MASINTER, Larry; BERNERS-LEE, Tim; FIELDING, Roy T. Uniform resource identifier (URI): Generic syntax. 2005. http://tools.ietf.org/html/rfc3986

MATTSSON, Michael. Object-oriented frameworks. Ronneby: University College of Karlskrona/Ronneby, Licentiate thesis, 1996.

OLIVEIRA, Ricardo R. Avaliao de manutenibilidade entre as abordagens de web services RESTful e SOAP-WSDL. Mestre em cincias da computao, USP So Carlos, 2012.

PAUTASSO, Cesare. RESTful Web service composition with BPEL for REST, Lugano: Elsevier, 2009

PRESSMAN, Roger S. Engenharia de software, Uma Abordagem Profissional Stima Edo. So Paulo: McGraw HillHigher Education, 2011.

RICHARDSON, Leonard; RUBY, Sam. Restful Web Services. Sebastopol: OReally, 2009.

SAMETINGER, Johannes. Software engineering with reusable components. Linz: Springer, 1997.

SAUV Jaques, P. Frameworks O que um Framework?, 2011. Universidade de Campina Grande. Disponvel em: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htmacessado:25/09/2013 s 23:45

SOMMERVILLE, Ian. Software Engineering Eighth Edition. USA, Pearson Education Limited, 2007.

Documents

REST