80
FACULDADE DE TECNOLOGIA ZONA LESTE GUILHERME DE OLIVEIRA SANTOS VINICIUS ARAUJO RIBEIRO Desenvolvimento de um framework para consumo de Webservice REST em aplicações Android São Paulo 2013

REST

Embed Size (px)

DESCRIPTION

Criação de framework REST para utilização em aplicativos Android

Citation preview

  • 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 24: Fragmento 2 do diagrama de sequncia do fluxo da operao GET ................... 48

    Figura 25: Fragmento 3 do diagrama de sequncia do fluxo da operao GET ................... 49

    Figura 26: Fragmento 4 do diagrama de sequncia do fluxo da operao GET ................... 50

    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 30: Fragmento 2 do diagrama de sequncia do fluxo da operao DELETE ............ 55

    Figura 31: Fragmento 3 do diagrama de sequncia do fluxo da operao DELETE ............ 56

    Figura 32: Fragmento 4 do diagrama de sequncia do fluxo da operao DELETE ............ 57

    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 36: Fragmento 2 do diagrama de sequncia do fluxo da operao PUT ................... 62

    Figura 37: Fragmento 3 do diagrama de sequncia do fluxo da operao PUT ................... 63

    Figura 38: Fragmento 4 do diagrama de sequncia do fluxo da operao PUT ................... 64

    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 42: Fragmento 2 do diagrama de sequncia do fluxo da operao POST ................ 69

    Figura 43: Fragmento 3 do diagrama de sequncia do fluxo da operao POST ................ 70

    Figura 44: Fragmento 4 do diagrama de sequncia do fluxo da operao POST ................ 71

    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

    Fonte: Os autores, 2013.

    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

    Fonte: Os autores, 2013.

    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.

    Fonte: Os autores, 2013.

  • 37

    3.6 Classes Principais

    A figura 8 ilustra o diagrama de classes do framework:

    Fonte: Os autores, 2013.

    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

    Fonte: Os autores, 2013

    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

    Fonte: Os autores, 2013.

    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

    Fonte: Os autores, 2013

    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

    Fonte: Os autores, 2013

    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

    Fonte: Os autores, 2013

    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

    Fonte: Os autores, 2013

    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

    Fonte: Os autores, 2013.

    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

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013

    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

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013.

    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

    Fonte: Os autores, 2013.

  • 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()).

    A figura 25 (Fragmento 3 do diagrama de sequncia do fluxo da operao GET)

    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()).

    A figura 26 (Fragmento 4 do diagrama de sequncia do fluxo da operao GET)

    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

    Fonte: Os autores, 2013.

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

  • 48

    Figura 24: Fragmento 2 do diagrama de sequncia do fluxo da operao GET

    Fonte: Os autores, 2013.

  • 49

    Figura 25: Fragmento 3 do diagrama de sequncia do fluxo da operao GET

    Fonte: Os autores, 2013.

  • 50

    Figura 26: Fragmento 4 do diagrama de sequncia do fluxo da operao GET

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013.

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

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

  • 52

    Figura 28: Diagrama de sequncia DELETE

    Fonte: Os autores, 2013.

  • 53

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

    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 30 (Fragmento 2 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()).

    A figura 31 (Fragmento 3 do diagrama de sequncia do fluxo da operao DELETE)

    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()).

    A figura 32 (Fragmento 4 do diagrama de sequncia do fluxo da operao DELETE)

    contm a preparao (mtodo transformContentResponseInObject()) e execuo

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

  • 54

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

    Fonte: Os autores, 2013

  • 55

    Figura 30: Fragmento 2 do diagrama de sequncia do fluxo da operao DELETE

    Fonte: Os autores, 2013.

  • 56

    Figura 31: Fragmento 3 do diagrama de sequncia do fluxo da operao DELETE

    Fonte: Os autores, 2013.

  • 57

    Figura 32: Fragmento 4 do diagrama de sequncia do fluxo da operao DELETE

    Fonte: Os autores, 2013

  • 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

    Fonte: Os autores, 2013.

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

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

  • 59

    Figura 34: Diagrama de sequncia PUT

    Fonte: Os autores, 2013.

  • 60

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

    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 36 (Fragmento 2 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()).

    A figura 37 (Fragmento 3 do diagrama de sequncia do fluxo da operao PUT)

    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()).

    A figura 38 (Fragmento 4 do diagrama de sequncia do fluxo da operao PUT)

    contm a preparao (mtodo transformContentResponseInObject()) e execuo

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

  • 61

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

    Fonte: Os autores, 2013.

  • 62

    Figura 36: Fragmento 2 do diagrama de sequncia do fluxo da operao PUT

    Fonte: Os autores, 2013.

  • 63

    Figura 37: Fragmento 3 do diagrama de sequncia do fluxo da operao PUT

    Fonte: Os autores, 2013.

  • 64

    Figura 38: Fragmento 4 do diagrama de sequncia do fluxo da operao PUT

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013.

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

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

  • 66

    Figura 40: Diagrama de sequncia POST

    Fonte: Os autores, 2013.

  • 67

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

    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 42 (Fragmento 2 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 43 (Fragmento 3 do diagrama de sequncia do fluxo da operao POST)

    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()).

    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

    Fonte: Os autores, 2013.

  • 69

    Figura 42: Fragmento 2 do diagrama de sequncia do fluxo da operao POST

    Fonte: Os autores, 2013.

  • 70

    Figura 43: Fragmento 3 do diagrama de sequncia do fluxo da operao POST

    Fonte: Os autores, 2013.

  • 71

    Figura 44: Fragmento 4 do diagrama de sequncia do fluxo da operao POST

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013.

  • 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

    Fonte: Os autores, 2013.

  • 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.