Google Cloud Platform para Aplicações Móveis - inf.ufpr.br · GustavoFelipeZandonáPuchalski...

Gustavo Felipe Zandoná PuchalskiJuliana Campos Franchi

Google Cloud Platform para Aplicações Móveis

Curitiba

2014



Trabalho de Graduação apresentado como re-quisito parcial à obtenção do grau de Bacharelem Ciência da Computação da UniversidadeFederal do Paraná, UFPR, Setor de CiênciasExatas.

Universidade Federal do Paraná – UFPR

Curso de Ciência da Computação

Graduação

Orientador: Bruno Müller Junior

Curitiba2014

Gustavo Felipe Zandoná PuchalskiJuliana Campos FranchiGoogle Cloud Platform para Aplicações Móveis/ Gustavo Felipe Zandoná PuchalskiJuliana Campos Franchi. – Curitiba, 2014- 57 p. : il. (algumas color.) ; 30 cm.Orientador: Bruno Müller JuniorTrabalho de conclusão de curso (Graduação) – Universidade Federal do Paraná –UFPRCurso de Ciência da ComputaçãoGraduação, 2014.1. Mobile Cloud Computing. 2. Google Cloud Platform. 3. Cloud Computing. 4.Mobile services. I. Bruno Müller Junior. II. Universidade Federal do Paraná. III.Curso de Ciência da Computação. IV. Google Cloud Platform para aplicações mobile

CDU 02:141:005.7



Trabalho de Graduação apresentado como re-quisito parcial à obtenção do grau de Bacharelem Ciência da Computação da UniversidadeFederal do Paraná, UFPR, Setor de CiênciasExatas.

Trabalho aprovado. Curitiba, 16 de dezembro de 2014:

Bruno Müller JuniorOrientador

Andrey Ricardo PimentelConvidado 1

Armando Luiz N. DelgadoConvidado 2

Curitiba2014

“A Estrada em frente vai seguindoDeixando a porta por onde começa.

Agora longe já vai indo,Devo seguir, nada me impeça;Em seu encalço vão meus pés,

Até a junção com a grande estrada,De muitas sendas através.

Que vem depois? Não sei mais nada.”(O Senhor dos Anéis, pg 36, J. R. R. Tolkien)

ResumoEste trabalho descreve como utilizar computação em nuvem para o desenvolvimento deaplicações móveis. Dentre os vários modelos existentes, apresentaremos o funcionamentoda plataforma de cloud computing voltada para dispositivos móveis da Google e demons-traremos a viabilidade de se utilizá-la no desenvolvimento de aplicações.A linguagem de desenvolvimento utilizada para construir o aplicativo será a Objective-Cpara o sistema operacional da Apple - iOS.

Palavras-chaves: Computação em nuvem, Computação em nuvem móvel, Google CloudPlatform, serviços móveis.

AbstractThis paper will describe how to use cloud computing in the development of mobileapplications. Among the several existing models, we will present the behaviour of theGoogle cloud computing platform for mobile devices, demonstrating the viability of usingit in the development of mobile applications.The development language used to build the application is the Objective-C for Apple’soperating system - iOS.

Key-words: Cloud computing, mobile cloud computing, Google Cloud Platform, mobileservices.

Lista de abreviaturas e siglas

API Application Programming Interface

Apps Aplicativos

AWS Amazon Web Services

CC Cloud Computing

GCP Google Cloud Platform

MA Microsoft Azure

MCC Mobile Cloud Computing

REST Representational State Transfer

SOA Arquitetura Orientada a Serviço

SOAP Simple Object Access Protocol

WS Web Services

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 MOBILE CLOUD COMPUTING . . . . . . . . . . . . . . . . . . . . 172.1 Conceitos e Tecnologias em MCC . . . . . . . . . . . . . . . . . . . . 172.1.1 Arquitetura Orientada a Serviço . . . . . . . . . . . . . . . . . . . . . . . 182.1.2 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.2.1 SOAP vs. REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.3 Interface de Programação de Aplicações . . . . . . . . . . . . . . . . . . . 222.1.4 Autenticação OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Características da MCC . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 Arquiteturas da MCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Vantagens da MCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.5 Principais Plataformas Existentes para MCC . . . . . . . . . . . . . . 27

3 GOOGLE CLOUD PLATFORM . . . . . . . . . . . . . . . . . . . . 313.1 Opções Oferecidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 GCP para Dispositivos Móveis . . . . . . . . . . . . . . . . . . . . . . 323.2.1 Arquitetura da GCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 APLICAÇÕES MÓVEIS . . . . . . . . . . . . . . . . . . . . . . . . . 394.1 Abordagens de Aplicações . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Tecnologias de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . 404.2.1 Desenvolvimento nativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Aplicações Coss-Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.3 Aplicações Web móveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 A Escolha da Melhor Tecnologia . . . . . . . . . . . . . . . . . . . . . 42

5 DESCRIÇÃO DA IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . 435.1 Nossa Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 Construção da Arquitetura GCP . . . . . . . . . . . . . . . . . . . . . 455.2.1 Criação do Código back-end da API . . . . . . . . . . . . . . . . . . . . . 475.2.2 Configuração do Código . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2.3 Geração das Bibliotecas do lado cliente . . . . . . . . . . . . . . . . . . . 535.3 Resultados na Integração com a GCP . . . . . . . . . . . . . . . . . . 55

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

15

1 Introdução

Atualmente, cerca de 43 milhões de pessoas acessam a internet através de dispo-sitivos móveis somente no Brasil (??) e estima-se que existam cerca de 1.75 bilhões deusuários de smartphones no mundo (??). O acesso à internet para dispositivos móveis estácada vez mais rápido. No Brasil, este ano, já existe internet 4G nas capitais e municípioscom mais de 500 mil habitantes. Até 2016 estima-se que esta tecnologia será oferecidatambém às cidades com mais de 100 mil habitantes, englobando mais de 104 milhões depessoas (??). Além disso, já está em andamento a homologação do padrão de tecnologia5G (????).

Juntamente com o grande crescimento de smartphones, tablets e o uso de internetmóvel, aumentou também o número de aplicativos para estes aparelhos, que geraram umademanda por padrões de dados mais rápidos para celulares, aumentando o poder dosaplicativos móveis.

Hoje é uma necessidade dos usuários acessar seus dados em tempo real, não apenaspor uma questão de comodidade, mas também por segurança: quebrar, perder ou ter seudispositivo furtado não são situações tão incomuns. Portanto, ter seus dados integrados epoder acessá-los de qualquer lugar, é essencial.

A principal tecnologia que temos para este fim é a computação em nuvem, ou cloudcomputing (CC) (??). De acordo com o NIST (??), ela é um modelo que permite acessosob demanda, via rede, para um local de recursos compartilhados (por exemplo: servidores,equipamentos de armazenamento, aplicações e serviços) que podem ser rapidamentefornecidos e liberados com um esforço mínimo de gerenciamento ou interação com oprovedor de serviços. Portanto, ela permite que o usuário final acesse dados e serviços, devários lugares por vários usuários simultaneamente, independente da plataforma. Basta,para isso, ter um terminal conectado à nuvem.

A palavra nuvem pode remeter a um ambiente nebuloso, onde não conseguimosdistinguir seu interior, visualizando apenas seu inicio e fim. Em computação, este termoé utilizado, pois toda a infraestrutura e recursos computacionais não ficam visíveis e ousuário tem acesso apenas a uma interface onde é disponibilizada a aplicação ou o serviço.Todo o tipo de processamento, infraestrutura e armazenamento de dados, é fornecidoatravés da internet.

Dispositivos móveis possuem pouca segurança, conexão instável e energia limitada(uma vez que utilizam bateria). Prover recursos para minimizar estas deficiencias é o maiordesafio para a maioria das aplicações.

16 Capítulo 1. Introdução

Com o crescente uso destes dispositivos (??) e com o suporte da CC para váriosserviços móveis, surgiu a computação em nuvem para dispositivos móveis, ou mobile cloudcomputing (MCC), que é uma integração da CC para o ambiente móvel.

As principais plataformas de MCC existentes hoje no mercado são a Google CloudPlatform da Google1, a Amazon Web Services da Amazon2 e a Microsoft Azure daMisrosoft3 (??).

Este trabalho irá detalhar o funcionamento da plataforma da Google e mostrarcomo desenvolver aplicações móveis para interagir com esta plataforma de MCC. Paraisso, foi desenvolvido um aplicativo simples para o sistema operacional iOS da Apple como objetivo de ter seu back-end rodando na plataforma da Google.

No capítulo 2 é explicado o conceito de computação em nuvem para dispositivosmóveis, suas características, vantagens, desvantagens e as principais plataformas existentese suas diferenças. O capítulo 3 explica em detalhes o funcionamento da plataforma daGoogle. O capítulo 4 explica as principais tecnologias e abordagens ao se desenvolverum aplicativo móvel, e quais escolhemos utilizar. O capítulo 5 descreve a ideia geral daimplementação do nosso aplicativo e como a plataforma apresentada deverá interagir comele. Finalmente o capítulo 6 irá apontar nossas considerações finais.

A lista de acrônimos contidos neste trabalho é apresentada na “Lista de abreviaturase siglas”.

1 https://cloud.google.com2 http://aws.amazon.com/pt/3 http://azure.microsoft.com/pt-br/

17

2 Mobile Cloud Computing

Cloud computing está sendo reconhecida como a nova geração de modelo computaci-onal (??). Ela possui várias vantagens ao oferecer aos usuários a utilização da infraestrutura,plataformas e softwares fornecidos por provedores da nuvem (Google, Amazon e Microsoft,por exemplo) a um custo muito baixo (??).

Existem três grandes grupos que interagem com a nuvem: provedores de serviços,desenvolvedores e o usuário final. Os provedores são responsáveis por disponibilizar,gerenciar e monitorar toda a infraestrutura da nuvem, garantindo um nível de serviçoe segurança adequados. Os desenvolvedores utilizam esta infraestrutura disponibilizadapelos provedores de serviços para prover serviços e funcionalidades ao usuário final.

A combinação de CC, comunicação wireless, dispositivos computacionais portáteis,internet móvel etc., forneceu a base para o novo modelo computacional chamado mobilecloud computing.

O Mobile Cloud Computing Forum definiu MCC como segue (??):

“Mobile cloud computing refere-se a uma infraestrutura onde tanto o arma-zenamento de dados e o processamento de dados ocorrem fora do dispositivomóvel. Aplicações móveis na nuvem transferem o poder de computação e oarmazenamento de dados para fora dos telefones móveis para dentro da nuvem,trazendo aplicações e computação móvel não apenas a usuários de smartphonesmas para uma gama muito mais ampla de clientes móveis”.

MCC é um novo padrão para aplicações móveis onde todo o processamento earmazenamento de dados não é mais feito no próprio dispositivo, mas em plataformascomputacionais localizadas na nuvem e acessadas pela internet. Desta forma, os dispositivosmóveis não necessitam de configurações complexas, como capacidade da memória e poderde processamento, pois todo esse processamento passa a ser feito na nuvem (??).

Nas próximas seções explicaremos os principais conceitos dentro da MCC, ascaracterísticas desta tecnologia, sua arquitetura, vantagens e as principais plataformasexistentes no mercado.

2.1 Conceitos e Tecnologias em MCCEsta seção aborda os principais conceitos de MCC, assim como as tecnologias

associadas. Para tal, ela foi assim dividida: a seção 2.1.1 descreve a arquitetura por trás

18 Capítulo 2. Mobile Cloud Computing

da computação móvel; a seção 2.1.2 descreve os protocolos de comunicação entre serviçosweb1 associados a esta arquitetura; a seção 2.1.3 da o conceito de interface de programaçãode aplicações; e por fim, a seção 2.1.4 descreve o serviço de autenticação utilizado poralgumas plataformas móveis.

2.1.1 Arquitetura Orientada a Serviço

Para melhor entendermos o funcionamento das principais arquiteturas utilizadaspara soluções móveis, devemos entender o conceito de Arquitetura Orientada a Serviço2

(SOA). A SOA é um conjunto de princípios de design utilizados durante as fases dedesenvolvimento e integração de sistemas e que fornece a base para sistemas de webservices (Apresentaremos mais detalhes sobre este tema na seção 2.1.2).

“Orientação a Serviço é um paradigma que molda o que você faz. ArquiteturaOrientada a Serviço (SOA) é um tipo de arquitetura que resulta da aplicação de orientaçãoa serviço.” (??). A SOA é essencialmente uma coleção de serviços que se comunicam umcom o outro. Esta comunicação pode envolver tanto dados simples quanto dois ou maisserviços complexos coordenando alguma atividade. Serviços em nuvem são basicamenteserviços web. A SOA os organiza e gerencia dentro da nuvem e, para isso, ela consiste detrês entidades, representadas na figura 1:

Figura 1 – Arquitetura Orientada a Serviço

• Provedor do serviço - É o servidor que irá implementar e publicar o serviço,tornando-o disponível para ser usado. Para isso ele registra este serviço no servidorchamado Registrador de serviços.

1 Do inglês: web services.2 Do inglês: Service-Oriented Architecture

2.1. Conceitos e Tecnologias em MCC 19

• Registrador de serviços - Mantém um registro dos serviços disponíveis, com sualocalização. É o responsável por garantir que as informações deste serviço fiquemdisponíveis para qualquer consumidor, serviço requisitador ou clientes web.

• Consumidores do serviço - É a aplicação que irá utilizar o serviço. Ela iráencontrar este serviço disponível pelo provedor através de uma busca nos registrosdo Registrador de serviços e irá utilizá-lo enviando uma solicitação por uma conexãode rede.

Todo o processo, desde o pedido inicial até a entrega do serviço, é gerenciado pelacomunicação entre os web services, possibilitados pela estrutura que a SOA oferece. Eladefine como que duas entidades de computação interagem de forma a permitir que umaentidade faça o trabalho pela outra.

Web services estão se tornando a implementação mais comum da SOA (????).SOA e CC estão relacionadas, elas se complementam e dão suporte uma a outra. A SOA éum padrão arquitetural que orienta as soluções a criarem, organizarem e reutilizarem oscomponentes computacionais enquanto a CC é um conjunto de tecnologias que servemuma plataforma muito maior e mais flexível para que as soluções SOA sejam construídas(??).

2.1.2 Web Services

Web Services (WS) é um modelo para o uso da web, que consiste em uma aplicaçãode software que permite a publicação de suas funções para utilização através da internet.Normalmente ele é identificado por uma URL, como qualquer outro site, porém o quediferencia um WS é o tipo de informação que ele pode prover.

Ao acessar um site no navegador, o que está sendo feito é uma requisição ao servidorda página desejada. Este, por sua vez, envia o arquivo que será renderizado pelo navegadordo cliente. Esta requisição pode possuir instruções ao servidor, mas elas são muito simples,limitando-se a arquivos que se deseja acessar, alguns parâmetros e, eventualmente, algumscript do lado do servidor que se deseja executar e obter uma resposta.

A diferença para WS está no conteúdo que é enviado na requisição do cliente parao servidor. Os clientes de WS enviam um documento (normalmente XML ou JSON), deacordo com a especificação do protocolo utilizado. Existem dois tipos de WS, baseado emSOAP ou em REST3 (????):

• SOAP (Simple Object Access Protocol) - Possui um protocolo próprio de comunicaçãode mensagens baseado em XML. Uma mensagem SOAP é composta de: envelope

3 Também conhecida como RESTful Web Services.


(que identifica o documento XML como sendo uma mensagem SOAP); header (quepossui chamadas de funções e é opcional); e o body (espaço para colocar qualquer tipode informação). Esta mensagem é apenas um documento XML que, ao ser recebida, éavaliada pelo mecanismo de processamento do SOAP conforme suas regras e do XML,a fim de determinar que é um arquivo válido. Caso seja, o processador SOAP chamao WS com os parâmetros contidos no arquivo que foi recebido. Quando ele terminade processar a requisição, é fornecida uma resposta que é formatada conforme aespecificação do protocolo (formato XML), que será entregue ao servidor web que irátransmiti-la ao cliente (usando um protocolo de transporte SMTP, FTP ou HTTP).

• REST (Representational State Transfer) - É um protocolo que não possui umformato de mensagem estruturado, ao contrário do SOAP. Ele utiliza o protocoloHTTP para suas requisições e, desta forma, suas operações CRUD4 são feitas pelosmétodos POST, GET, PUT e DELETE, respectivamente, do HTTP. Cada transaçãoé independente e não se relaciona com as outras. Assim, toda informação para oservidor processá-la deve estar contida nela mesma. Logo, o servidor não precisaarmazenar as respostas das transações anteriores. Isto torna a aplicação REST maissimples e leve.

Não faz parte do escopo deste trabalho discutir maiores detalhes quanto ao funcio-namento destes protocolos. Apresentaremos apenas uma breve comparação entre eles parao melhor entendimento das principais arquiteturas móveis existentes.

2.1.2.1 SOAP vs. REST

O SOAP possui uma definição mais formal, através da WSDL5, o que o torna maiscomplexo para implementar do que o REST que usa o protocolo HTTP como mecanismo derequest and response, simplificando a implementação e o recebimento/envio de mensagens.

O SOAP permite criar o seu próprio protocolo de comunicação com a aplicação.Seu foco está no acesso a funções e operações do software como serviço e não nos dados.

O REST permite vários formatos diferentes de dados, enquanto o SOAP permiteapenas XML.

• Segurança - Ambos suportam SSL6 (Secure Sockets Layer), porém o SOAP possuiainda suporte as WS-Security que permite a implementação de mecanismos degarantia da integridade e privacidade dos dados. Esta opção simplesmente permite

4 Do inglês: Create, Read, Update e Delete5 WSDL, ou Web Services Description Language, é um documento escrito em XML que descreve as

operações, parâmetros, requisições e respostas utilizados pela web services e como acessá-la. Para maisinformações sobre este documento acesse (??).

6 É um protocolo de segurança para comunicação criptografada entre cliente e servidor (??).


suporte a algumas ferramentas de segurança que na maioria das vezes não sãonecessárias. Por isso ela é normalmente utilizada em cenários corporativos.

• Transações - O REST é limitado ao HTTP e, conforme mencionado, suas tran-sações são independentes e não se relacionam, portanto não podem fornecer umatransação distribuída em duas fases entre os recursos, ao contrário do SOAP. Poréma maioria dos aplicativos web geralmente não necessitam deste nível de confiabilidadetransacional.

• Troca de Mensagens - O REST não possui um sistema padrão de mensagem.Caso a comunicação falhe, o cliente deve tentar novamente. Já o SOAP possui umalógica de reenvio implementada e fornece uma confiabilidade ponto-a-ponto.

Na tabela 1 temos um resumo do comparativo entre estes protocolos.

# SOAP REST

1 Protocolo baseado emmensagens XML Protocolo de estilo arquitetural

2 Usa WSDL para comunicaçãoentre cliente e provedor

Usa XML ou JSON para enviar ereceber dados

3 A chamada de serviços é feitapela chamada do método RPC Invoca serviços via URL

4 O resultado retornado emlinguagem de máquina

O resultado pode ser lido em XMLou JSON

5

A tranferência é sobre o protocoloHTTP. Podendo ainda ser feitasobre SMTP, FTP, e outros destacategoria.

Transferência apenas pelo protocoloHTTP

6JavaScript pode chamar diretamenteo SOAP, porém é difícil deimplementar

Facilmente integrado com o JavaScript

7 Performance não é tão boa quanto a doREST

Performance é muito melhor secomparado ao SOAP - menos emuso do CPU.

Tabela 1 – Resumo do comparativo entre os protocolos SOAP e REST (??)

Se o aplicativo que se deseja construir for lidar com dados sensíveis, como dadosbancários, a melhor opção será o SOAP (??). Porém, por ser baseado em XML, ele requerum maior uso de recursos (para codificar e decodificar as mensagens) além de consumiruma maior largura de banda (??). Como estes recursos, em geral, ainda são escassos nolado da aplicação móvel, ao desenvolver nestes ambientes, sempre que for possível, indica-sea utilização do padrão REST (??).


2.1.3 Interface de Programação de Aplicações

Uma interface de programação de aplicações, ou API7, é um conjunto de rotinase funções disponibilizadas por um software para que um aplicativo consiga utilizar seusserviços, sem ter que se envolver em detalhes sobre a implementação do software (??). Elaroda por trás do aplicativo, podendo estar conectada a diversos outros sistemas e aplicaçõessem que o usuário perceba, disponibilizando alguns recursos deles para que os usuáriospossam fazer requisições, executando estas requisições e retornando suas respostas.

Uma WS é um tipo de API. Uma API REST, por exemplo, envia requisições HTTPa um servidor que as executa e retorna a resposta. Esta execução não é perceptível aousuário, que deve tratar apenas do envio da requisição e do recebimento da resposta.

Veremos na prática o funcionamento deste conceito na seção 5.2, onde será cons-truída e testada uma API.

2.1.4 Autenticação OAuth

Existem sites que disponibilizam a credencial de seus usuários para que eles possamse autenticar em outros sites ou aplicativos. Principalmente em aplicações móveis, éfundamental que seja possível ao usuário fazer autenticação usando contas como Facebook,Google+, Twitter, entre outros. Para isso, dados do usuário (login e senha) devem serfornecidos, mas, por questões óbvias de segurança, estas informações não podem serdivulgadas.

Para resolver este problema nasceu o OAuth, que visa permitir que o usuário deuma aplicação possa se autenticar em outras, sem que seja necessário compartilhar a senhae outras informações de segurança. Iremos deixar de lado aspectos técnicos relacionadoscom criptografia e HTTPS, que fogem ao escopo deste trabalho, e iremos focar em seufuncionamento.

Basicamente, a autenticação OAuth funciona em 3 passos, também descritos nafigura 2:

1) A aplicação pede permissão de acesso para o usuário em questão e obtém a chave deautenticação;

2) A aplicação que irá fornecer a credencial do usuário, solicita ao mesmo uma autorizaçãopara fornecer a chave de acesso;

3) A aplicação cliente troca a chave de autenticação pela chave de acesso.

7 Do inglês: Application Programming Interface.


Este tipo de autenticação vem se tornando muito importante em aplicações web e,principalmente, em aplicações móveis. Esta funcionalidade agrega grande valor à usabilidadedo sistema, uma vez que facilita e torna mais rápido ao usuário fazer a autenticação, oque normalmente é um processo chato e demorado (no caso de ter que se cadastrar).

Para entender como funciona este tipo de autenticação, vamos supor que o usuárioqueira fazer o login com sua conta do Google+ (??).

Figura 2 – Resumo do fluxo de funcionamento da autenticação via OAuth (??)

O primeiro fluxo da figura 2 explica como irá funcionar este primeiro passo. Apóso usuário selecionar a autenticação via Google+, o aplicativo solicita uma chave deautenticação ao servidor da Google, que devolve uma chave pública e uma privada (noteque estas chaves são usadas apenas durante a autenticação, e não dão permissão de acesso).Então o aplicativo redireciona o usuário para a aplicação do Google+ e fornece a ela achave pública.

Em seguida passamos ao passo 2, onde o usuário, através da página da aplicaçãoque irá fornecer os dados da autenticação (no exemplo, Google+), autoriza o acesso daaplicação cliente. Ao fazer esta autorização, inicia-se o passo 3, onde a aplicação clientedeverá fornecer a chave privada à aplicação servidora. Assim que esta chave for aceita, aaplicação servidora irá trocar a chave de autenticação por uma chave de acesso, que seráutilizada pelo cliente para acessar a API do servidor “em nome” do usuário.

É bom ser mencionado que, mesmo não fornecendo a senha, ao autorizar umaaplicação a se autenticar com sua conta do Google+ por exemplo, você está permitindoque esta aplicação controle algumas funcionalidades na aplicação servidora como se fosseo próprio usuário (????).


2.2 Características da MCCAs seguintes características estão presentes tanto em sistemas de CC como em

MCC (????):

• Serviço sob demanda: o usuário deve ser capaz de adicionar e remover funcionali-dades do seu sistema de forma automática e instantânea. Para isso a nuvem permiteo acesso em "autoatendimento"para que o usuário possa solicitar, personalizar e usarserviços desejados, sem intervenção humana, ao provedor de serviços.

• Elasticidade: a nuvem deve ser capaz de fornecer rapidamente os recursos, dandoao usuário a sensação de que ele possui recursos ilimitados, em qualquer quantidade,a qualquer momento.

• Amplo acesso à rede: para permitir a utilização dos recursos por dispositivosmóveis e portáteis, computadores, dentre outros, os recursos computacionais de-vem estar disponíveis através da internet para serem acessados por mecanismospadronizados.

• Medição de serviços: uma vez que o usuário pode solicitar e utilizar somente aquantidade de recursos que julgar necessário, a nuvem deve controlar e monitorarautomaticamente estes recursos, utilizando os serviços de gerenciamento para cadatipo de serviço (armazenamento, processamento e largura de banda). Este monitora-mento deve ser transparente tanto para o provedor de serviços como para o usuáriofinal.

A proposta da CC é dar a ilusão que os recursos computacionais disponíveis sãoinfinitos, permitindo o pagamento pelo uso dos serviços conforme a demanda (??).

2.3 Arquiteturas da MCCOs detalhes da arquitetura podem ser diferentes dependendo do contexto utilizado.

Mas, de forma geral, a arquitetura padrão baseada em CC pode ser vista na figura 3, ondeé mostrado os seguintes elementos:

• Os dispositivos móveis (Mobile devices), que correspondem aos tablets, telefonescelulares, entre outros;

• A rede móvel (Mobile network A e B) que é composta de estações base (que podemser satélites (Satellite), access points8 ou uma estação base transmissora (BTS))

8 Ou pontos de acesso. São dispositivos em uma rede sem fio que realizam a interconexão entre osdispositivos móveis. Fazem a conexão entre uma rede e outra.

2.3. Arquiteturas da MCC 25

Figura 3 – Arquitetura da MCC (??)

e dos serviços da rede móvel (Mobile Network Services) que são os processadorescentrais (Central Processors), os servidores (Servers) e a base de dados (Database);

• A internet;

• Aplicações do servidor (Application servers);

• A computação em nuvem propriamente dita, que é composta pelos controladores danuvem (Cloud controller) e pelas centrais de dados (Data centers).

Os dispositivos móveis estão conectados à rede móvel através das estações base,que fazem a conexão via ar entre a rede e os dispositivos. Todas as requisições feitas pelosusuários são transmitidas aos processadores centrais que estão conectados aos servidores,fornecendo todos os serviços à rede móvel. Neste ponto, os operadores das redes móveispodem fornecer serviços como autenticação e autorização, baseado nos dados armazenadosem sua base de dados. Depois disso, todas as solicitações dos usuários são transmitidas ànuvem através da internet. Os controladores da nuvem vão, então, processar os pedidospara retornar aos usuários os serviços correspondentes que foram solicitados.

A nuvem pode se comunicar com os usuários de várias maneiras através doschamados serviços. Eles são geralmente classificados com base em um conceito de camadasque leva em consideração o nível de abstração do recurso e o modelo de serviço do provedor.


Os serviços das camadas superiores podem ser compostos pelos serviços das camadasinferiores. Os modelos desta camada são: Infraestrutura como Serviço (IaaS), Plataformacomo Serviço (PaaS) e Software como Serviço (SaaS) e estão presentes não apenas naarquitetura da MCC como na CC como um todo (????).

• IaaS: Disponibiliza uma infraestrutura de processamento e armazenamento deinformação. Servidores, dispositivos de rede (hubs, switches e roteadores por exemplo)e de armazenamento de dados não são acessados diretamente, mas através demecanismos de virtualização onde o cliente tem acesso a um controle limitadodos recursos destes componentes, além de possuir controle sobre armazenamento,aplicações instaladas e o sistema operacional. Esta camada também é responsávelpor prover a infraestrutura necessária para as duas próximas camadas. Exemplo:Amazon Elastic Cloud Computing (Amazon EC2)9.

• PaaS: Oferece um ambiente para o desenvolvimento, testes e implementação dasaplicações. É disponibilizado um modelo de computação, armazenamento e comunica-ção para os dados, onde o desenvolvedor não precisa se preocupar com característicasdo hardware, como o número de processadores ou o nível de utilização da memória.Exemplos: Microsoft Azure e Google App Engine10 (utilizada na Google CloudPlatform).

• SaaS: Este modelo é utilizado para oferecer aplicações completas ao usuário final,que acessam o software remotamente via internet. Todo o controle e gerenciamentonecessários para o funcionamento da aplicação são feitos pelo provedor do ser-viço. Exemplos: Google Apps (Gmail, Gtalk e Gdocs por exemplo), SalesForce11 eMicrosoft’s One Drive12.

Alguns serviços podem também fazer parte de mais de uma camada ao mesmotempo. Um serviço de armazenamento de dados pode estar tanto na camada IaaS comona PaaS. Outro exemplo é o Microsoft Azure que oferece tanto os serviços de PaaS quantode IaaS.

2.4 Vantagens da MCCA MCC se beneficia das próprias vantagens da CC, tais como: mobilidade e

flexibilidade ao permitir que o usuário acesse dados e aplicações de qualquer lugar, aqualquer hora, contanto que haja uma conexão de qualidade com a internet; facilidade9 http://aws.amazon.com/pt/ec2/10 https://cloud.google.com/appengine/11 http://www.salesforce.com/br/12 https://onedrive.live.com/about/pt-br/

2.5. Principais Plataformas Existentes para MCC 27

de utilização e compartilhamento dos recursos; evita o desperdício de recursos, uma vezque o usuário só irá utilizar o que ele necessariamente pagou; e escalabilidade, pois épossível aumentar a disponibilidade dos recursos automaticamente conforme a necessidadedo usuário.

Ao utilizarmos CC em dispositivos móveis, trazemos não apenas estes benefícios ci-tados acima, mas também conseguimos superar alguns obstáculos presentes na computaçãomóvel. Estas vantagens estão listadas abaixo (????):

a) Redução no consumo de bateria: as tarefas de computação passam a ser executadasna nuvem ao invés de no aparelho móvel. Ao migrar o processamento computacionalpara a nuvem nós evitamos gerar um longo tempo de execução da aplicação nodispositivo, o que poderia resultar em um grande consumo de energia.

b) Aumento do poder de processamento: Ao migrar as tarefas computacionais para anuvem nós acabamos também por aumentar o poder de processamento das aplicações,pois elas não ficam mais restritas ao poder do próprio dispositivo.

c) Aumento da capacidade de armazenamento: as aplicações móveis não estão maisrestritas à capacidade de armazenamento do dispositivo. A MCC é desenvolvidapara permitir que o usuário armazene e acesse seus dados na nuvem através da redewireless. Desta forma, além de economizar espaço no dispositivo, também há umaconsiderável economia de energia. Um bom exemplo do uso desta aplicação é peloFacebook13, uma das redes sociais mais bem sucedidas hoje em dia e que utiliza anuvem para compartilhar imagem e dados.

d) Aumento da segurança: como mencionado no início deste texto, ter seu dispositivomóvel quebrado, perdido ou furtado é um risco real. Armazenar seus dados eaplicativos na nuvem faz com que eles possam ser acessados de diversos dispositivos/ computadores diferentes, diminuindo a chance de perda de dados. Além do mais, aMCC pode ser usada para proteger os dados tanto dos usuários como dos prestadoresde serviços.

2.5 Principais Plataformas Existentes para MCC

Atualmente existem várias plataformas de CC. Dentre elas, há as que oferecem umsuporte específico que permite facilitar o uso da MCC em suas soluções para dispositivosmóveis. Como mencionado anteriomente, as principais plataformas deste tipo no mercadosão: Amazon Web Services, Google Cloud Platform e Microsoft Azure.13 www.facebook.com


Todas elas possuem soluções específicas para o ambiente móvel e oferecem emgrande parte as mesmas funções, tais como envio de notificações push aos dispositivos(funcionalidade descrita na seção 3.2.1), autenticação de usuário, opção de banco de dadosem SQL e NoSQL, grande escalabilidade e habilidade de guardar, retornar e processardados fora dos dispositivos móveis. As três também possuem suporte para aplicaçõesAndroid e iOS.

Os principais pontos que as diferenciam são quanto à tecnologia empregada e aslinguagens adotadas por cada uma. Uma comparação entre suas principais característicaspode ser vista abaixo:

• Amazon Web Services (AWS): Possui serviços de IaaS e PaaS. Como Plataforma,permite o desenvolvimento do próprio aplicativo (de forma nativa ou utilizando umacross-plataform14), além do back-end. Utiliza a arquitetura de web services baseada emSOAP para fazer a comunicação entre os clientes e o back-end. O desenvolvedor podeescolher entre Java, PHP, Python, Ruby e .NET como linguagens para codificação.Permite montar a infraestrutura de back-end com alguns serviços padrões como oAmazon S3 (infraestrutura de armazenamento de dados), o Amazon DynamoDB(banco de dados NoSQL) e alguns outros serviços desenvolvidos especificamentepara aplicativos móveis como o Amazon Cognito (gerenciamento e sincronizaçãode identidade). Ela disponibiliza alguns recursos de graça pelo período de um ano,e outros que possuem limite de utilização gratuito onde você só passa a pagar seultrapassar este limite15.

• Google Cloud Platform (GCP): Possui serviço PaaS restrito ao desenvolvi-mento de back-end, configuração de proteção DoS16, geo-localização e busca degeo-proximidade. Permite a utilização de Python, Java, PHP e Go como linguagenspara codificação do back-end e utiliza uma arquitetura de web services baseada emREST para fazer a comunicação entre os clientes e o back-end. Ela já disponibilizauma arquitetura padrão para soluções móveis e o desenvolvedor pode escolher quaiscomponentes desta arquitetura ele gostaria de usar em sua aplicação. Não possuilimite de tempo para utilização gratuita, mas um limite de dados por mês17.

• Microsoft Azure (MA): Assim como a AWS, possui serviço de PaaS que permiteo desenvolvimento do próprio aplicativo dentro da nuvem, além do desenvolvimentodo back-end, que pode ser feito em .NET ou Javascript. Sua arquitetura de webservices para a comunicação entre os clientes e o back-end pode ser baseada tanto

14 Discutiremos mais sobre estas opções na seção 4.215 Para maiores detalhes sobre preços da AWS acesse: http://aws.amazon.com/pt/s3/pricing/ e

http://aws.amazon.com/pt/free/16 Ataque de negação de serviço, ou denial of service (DoS) attack.17 Para maiores detalhes sobre preços da GCP acesse: https://cloud.google.com/products/cloud-storage/

2.5. Principais Plataformas Existentes para MCC 29

em REST como em SOAP. É possível implantar até 10 web sites ou construir umserviço móvel que suporte até 500 dispositivos sem gastar um centavo. Tambémpossui um limite de dados mensal para utilização gratuita18.

Dentre as linguagens disponíveis para implementação, temos mais familiaridadecom Java, e entre a AWS, a MA e a GCP, achamos a arquitetura baseada em componentesda GCP de mais fácil entendimento e implementação. Portanto, dados estes motivos,escolhemos utilizar a plataforma da Google. Além dela ser mais rápida (????) e atualmentea mais barata (??), encontramos também mais documentação sobre a sua API em relaçãoàs outras duas plataformas.

No próximo capítulo descreveremos em detalhes o funcionamento da arquiteturada GCP para soluções móveis.

18 Para maiores detalhes sobre preços da MA acesse: http://azure.microsoft.com/en-us/pricing/details/storage/

31

3 Google Cloud Platform

A GCP oferece uma ampla variedade do que eles chamam de soluções1. Este termose refere à um conjunto de produtos que utilizam tecnologias da Google (como seu bancode dados, Google Cloud Storage, por exemplo), formando uma arquitetura predefinidadestinada à construção de determinadas aplicações. Estas tecnologias funcionam comocomponentes da arquitetura. Cada um dos itens a seguir possui uma arquitetura, que podeser moldada (componentes podem ser ativados ou desativados) para melhor se adequar asnecessidades de um determinado projeto.

A seguir, será descrito as soluções oferecidas e depois explicaremos toda a arquiteturapor trás da solução para dispositivos móveis.

3.1 Opções Oferecidas1) Dispositivos Móveis: Permite a construção e hospedagem de um back-end para seus

aplicativos móveis, provendo benefícios como processamento de dados, pesquisa porproximidade geográfica, notificações push2, armazenamento de dados, escalonamentoe balanceamento de carga automáticos para oferecer suporte a milhões de usuários.

2) Hadoop: O Apache Hadoop é um projeto de software open-source que permite o arma-zenamento e processamento em larga escala de conjuntos de dados em clusters. Estasolução oferece ao desenvolvedor tirar vantagem do armazenamento e infraestruturada GCP para rodar o Apache Hadoop, simplificando a arquitetura e melhorando aperformance deste software.

3) Jogos: Facilita a construção de jogos oferecendo escalabilidade infinita e permitindoque o desenvolvedor concentre-se em seu jogo sem se preocupar com problemassubjacentes de infraestrutura. Fornece o armazenamento de grandes arquivos nanuvem, como imagens de alta resolução e downloads de todos os tamanhos, sincronizao estado de jogos em vários dispositivos diferentes, permite uma fácil integração comdispositivos móveis e permite criar jogos para eles com integração para Android, iOSe plataformas web.

4) MongoDB3: Considerado o banco de dados de mais rápido crescimento para startupse principais organizações de todos os tamanhos (??), é um banco de dados multi-plataforma orientado a documentos, classificado como NoSQL. Ao integrá-lo com a

1 Todas podem ser vistas em: https://cloud.google.com/solutions/2 Descrita na seção 3.2.1.3 Do inglês "humongous"que significa monstruoso.

32 Capítulo 3. Google Cloud Platform

sua plataforma, a GCP oferece benefícios como alta performance e disponibilidade,escalabilidade e segurança através de criptografia.

5) RabbitMQ: É um sistema open-source de message broker4. A GCP permite o usodeste sistema em sua plataforma oferecendo uma alta vazão, alta disponibilidadealém de robustez e flexibilidade.

6) Cassandra: O Apache Cassandra é um banco de dados open-source distribuído e pro-jetado para lidar com grande quantidade de dados provendo uma alta disponibilidadesem nenhum ponto de falha. O GCP consegue rapidamente prover e escalar a cargada rede para lidar com até um milhão de pedidos por segundo, também oferecendoalta vazão e alta disponibilidade.

Na próxima seção vamos entrar em detalhes sobre a arquitetura da solução paradispositivos móveis oferecida pela GCP.

3.2 GCP para Dispositivos MóveisConforme explicado brevemente na seção 2.5, a GCP oferece uma arquitetura

predefinida para soluções móveis, onde é permitido construir o seu próprio back-end efazer a comunicação entre ele e os clientes móveis. Dentre os principais componentes destaarquitetura destacamos:

1. Os clientes móveis;

2. A aplicação back-end responsável por responder às requisições dos clientes;

3. A camada de comunicação entre o back-end e os clientes e

4. Os vários serviços da nuvem disponibilizados para, por exemplo, guardar os dados daaplicação, retornar estes dados e autenticar o usuário.

As principais tarefas que o desenvolvedor deve realizar é definir os recursos queserão utilizados e implementar a lógica necessária para manipular as operações específicasdestes recursos.

3.2.1 Arquitetura da GCP

A figura 4 mostra a arquitetura completa sugerida pela GCP para aplicações móveis.Esta é uma solução genérica, montada com a finalidade de disponibilizar a maioria das4 Message broker é um programa intermediário que traduz uma mensagem do protocolo de mensagens

formal do remetente para o protocolo formal de mensagens do receptor (??).

3.2. GCP para Dispositivos Móveis 33

Figura 4 – Diagrama da arquitetura sugerida pela Google para soluções móveis (??)

funcionalidades existentes para satisfazer o maior número de soluções possíveis. Algunsdestes componentes são opcionais e podem ser adicionados ou removidos conforme aaplicação.

Utilizar esta arquitetura recomendada oferece alguns benefícios de infraestruturaque o desenvolvedor não precisa se preocupar em implementar, como escalabilidade auto-mática, balanceamento automático de carga entre as instâncias do back-end, confiabilidade,performance, recursos de segurança, monitoramento e gestão. Ao utilizá-la sua soluçãopoderá, entre outros recursos, utilizar a autenticação de usuário integrada, oferecer suportea aplicativos nativos para Android e iOS, armazenar, recuperar e processar dados fora dosdispositivos móveis, além de utilizar a pesquisa por proximidade geográfica (??).

A seguir será descrito cada um dos componentes que compõe a arquitetura sugeridapela Google, conforme apresentado na figura 4.

• Google Cloud Endpoints - Podemos dizer que é a porta da frente do back-end. Éresponsável pela autenticação dos usuários e facilita o acesso a dados de aplicações.É baseada no modelo REST e fornece autenticação baseada no OAuth2 para que oback-end possa saber a identidade do usuário.Como dito no início desta seção, um dos principais componentes da arquitetura é acamada de comunicação entre o back-end e os clientes e o Google Cloud Endpoints éo responsável por esta comunicação.


• Google App Engine5 - É o local aonde o código da aplicação back-end irá rodar.É o responsável por atender às requisições dos clientes e fazer a comunicação com osvários serviços disponibilizados na nuvem. O desenvolvedor tem como opções para aimplementação da lógica as linguagens Python, Java, PHP ou Go.

• Armazenamento de Dados - Na seção 2.4 discutimos que uma das vantagens de seutilizar CC é o aumento da segurança ao fazer, entre outras coisas, o armazenamentode dados na nuvem, fora dos dispositivos móveis. Os dados podem ser categorizadosem dois grupos diferentes e esta arquitetura oferece meios de armazenamento paracada um deles.1) Dados grandes e tipicamente binários, como imagens: estes objetos podem sertanto parte da solução, como por exemplo imagens retornadas por alguma buscadentro da aplicação, quanto objetos enviados pelos usuários, como fotos de perfil.Para estes tipos de dados, pode se usar o armazenamento através da Google CloudStorage, um serviço que consegue fazer o armazenamento de objetos e arquivos comaté terabytes de tamanho.2) Entidades e propriedades específicas: incluem dados do próprio aplicativo, comopor exemplo informações sobre a última fase completada em um jogo, informaçõessobre usuários, sobre o recebimento de notificações push, registros de compras dentrodo aplicativo e outros dados semelhantes específicos da aplicação. Estas informaçõespodem ser armazenadas dentro do App Engine Datastore, um banco de dados NoSQL,com transações atômicas e um mecanismo de consultas.

• Memcache - Responsável por fazer a otimização do acesso aos dados. Caso os clientesestejam fazendo solicitações frequentes para acessar determinadas informações, oideal é manter estes dados em uma cache, melhorando o desempenho da aplicaçãoao diminuir o acesso ao App Engine Datastore.

• Fila de Tarefas6 - É responsável por enfileirar as tarefas que precisam ser executa-das de maneira assíncrona. Muitas vezes, não é possível e nem desejável realizar todoo processamento envolvido em uma tarefa requisitada pelo usuário móvel, antes de seenviar uma resposta de volta ao dispositivo. Como exemplo, considere um aplicativoque irá notificar os amigos do usuário sempre que ele fizer o carregamento de umafoto. Podemos enviar uma resposta de confirmação ao cliente imediatamente apóstermos registrado o carregamento da foto e a necessidade de processar as notificações,sem ter que necessariamente esperar o processamento delas.Normalmente, configura-se o serviço de fila de tarefas para enviar as tarefas enfileira-das (modelo push) para o código executado no Google App Engine. Mas o códigopode também tirar as tarefas da fila de duas formas: através do código do back-end

5 Na figura: Mobile Backend Running On Google App Engine Instances.6 Na figura: Task Queues.


executando no Google App Engine, ou pelo código executado fora dele, podendo serusado para processar tarefas pelas instâncias do Google Compute Engine, que seráabordado mais adiante nesta seção.

• Notificações push - É uma das formas que o aplicativo tem de se comunicar como cliente. São mensagens que o aplicativo envia ao dispositivo, contendo informaçõessobre atualizações, status de um jogo, notificações recebidas, entre outros, mesmoquando o aplicativo não está em execução. Também é possível utilizar este recursopara continuar fornecendo dados relevantes à aplicação.Dependendo da plataforma do cliente, a arquitetura da Google oferece duas tecnolo-gias para o envio de notificações push:1) Google Cloud Messaging para Android: um serviço da Google que permite oenvio de dados aos usuários que tenham a aplicação cliente instalada em dispositivosAndroid.2) Sockets API: serviço que envia as notificações push utilizando o Apple PushNotification Service aos usuários iOS.

• Fornecimento de Conteúdo Estático - A arquitetura também permite a possi-bilidade de empacotar conteúdos estáticos que posteriormente poderão ser disponi-bilizados pela infraestrutura da Google App Engine através de servidores e cachesdedicados, sem envolver seu código back-end em nenhum momento. Este recursopode ser utilizado, por exemplo, para imagens.Digamos que a sua solução tenha um grande número de imagens estáticas, comoícones utilizados para construir a interface da sua aplicação. Essas imagens podemser empacotadas como parte da sua solução nativa.Outro tipo de imagem são as que não fazem parte da sua aplicação, mas estãorelacionados a processos dela, como resultados de uma busca, imagens de perfil dosseus conhecidos, entre outros. Este tipo de imagem pode ser carregada para o GoogleCloud Storage, que irá fornecer aos clientes móveis URLs diretas a estas imagens.Novamente sem envolver o código back-end, esta solução é muito escalável, poispermite aos clientes recuperar as imagens diretamente do armazenamento da nuvem.Caso o cliente queira poder manipular a imagem além de armazená-la, a arquiteturadisponibiliza o serviço de imagens da Google App Engine7, onde é possível rotacionar,cortar, inverter, redimensionar e ajustar a imagem de acordo com a resolução dodispositivo do cliente. Todos estes serviços não envolvem o código back-end, queé responsável apenas por utilizar a API para obter as URLs de cada imagem erepassá-las aos clientes móveis.

• Buscas - Os usuários podem fazer dois tipos de busca dentro de sua aplicação. Umadelas é a busca por texto através do Google App Engine Search API. Para usá-la,

7 Na imagem: Images Service.


basta construir documentos que contenham dados pesquisáveis e adicionar estesdocumentos a um índice. Desta forma o código back-end pode construir consultas depesquisa que irão rodar nos documentos indexados.Outro tipo de busca é através de geo proximidade, que também pode ser executadapelo Search API para retornar por exemplo, lojas ou restaurantes próximos ao seulocal atual.

• Tarefas Programadas - Além de processar as requisições dos usuários sincro-namente através do Google Cloud Endpoints e assincronamente através das TaskQueues, também é permitido ao seu código executar algumas tarefas de formaagendada em determinado espaço de tempo, utilizando para isso as Scheduled Tasks.Um exemplo de sua utilização é seu aplicativo enviar notificações push aos dispositi-vos todas as manhãs, com informações sobre o tempo. O aplicativo também podese aproveitar deste recurso para atualizar dados na Memcache a cada meia hora,por exemplo, e pode utilizar a Mail API para enviar e-mails sempre que houveralguma atualização relevante, dependendo da aplicação, como promoções de livros,lançamentos de filmes etc.

• Google BigQuery - Fazer uma consulta em conjuntos de dados massivos podeser demorado e caro, sem o hardware e infraestrutura adequados, o que é casoda maioria dos dispositivos móveis. O Google BigQuery resolve este problema,permitindo consultas rápidas baseadas em SQL, usando o poder de processamento dainfraestrutura da Google. Para isso, basta apenas mover seus dados para o BigQuery.

• Armazenamento e análise dos logs da aplicação8 - Utilizado para fornecer oslogs da sua aplicação. Os logs podem fornecer várias informações sobre o comporta-mento do seu código back-end e sobre como os usuários estão utilizando sua solução.Com o código rodando no Google App Engine é possível recuperar estes logs atravésda API, carregá-los no Google Cloud Storage e então inseri-los no Google BigQuery.

• Google Compute Engine - É utilizado para executar partes do back-end escritasem linguagens que não são suportadas pelo Google App Engine. Por exemplo, se oseu código tiver requisições para processamento utilizando alguma biblioteca C/C++ou programas em Perl.Pode-se também utilizar o seu back-end executando no Google App Engine paraenfileirar algumas tarefas utilizando as Tasks Queues e fazer com que o códigorodando na Google Compute Engine as execute.

A Google ainda oferece vários outros serviços e APIs disponíveis para construirsoluções mais robustas, como Maps API que abrange Android Maps, iOS Maps SDKs9,8 Na figura: Logs API.9 Software Development Kit.


entre outros. Porém o escopo deste documento envolve apenas os serviços básicos para autilização da arquitetura10.

10 Uma lista com todas as funcionalidades do App Engine pode ser vista em:https://cloud.google.com/appengine/features/

39

4 Aplicações Móveis

Apesar das facilidades que os ambientes de desenvolvimento de aplicativos (Apps)móveis permitem, desenvolver para estes dispositivos ainda traz muitos desafios. Ambientesde computação móvel são caracterizados por graves restrições de recursos e frequentesmudanças nas condições de operação (??).

Vários pontos devem ser considerados quando vamos desenvolver um aplicativo.Por ser um ambiente relativamente novo, ainda não existem padrões canônicos de desen-volvimento, porém vários métodos já foram levantados e testados.

Na seção 4.1 explicaremos três diferentes abordagens na construção de um aplicativo;na seção 4.2 mostraremos todas as diferentes maneiras de se implementar um aplicativo; ena seção 4.3 explicaremos quais das tecnologias e abordagens explicadas foram escolhidaspara este trabalho e o porquê.

4.1 Abordagens de AplicaçõesAparelhos móveis possuem limitações quanto ao seu poder de processamento,

consumo de energia, capacidade de memória, tamanho da tela, estabilidade da rede dedados, entre outros. Sendo assim, para o desenvolvimento móvel, temos as seguintesabordagens (??):

a) Aplicações offline: a maior parte dos Apps se enquadram neste contexto. São aplicaçõesonde as informações e dados vêm de um back-end em um servidor (muitas vezes umCC) e é possível utilizar o aplicativo sem uma conexão com a internet. A sincronizaçãopara atualizar estes dados ocorre de tempos em tempos. Todo o processamento earmazenamento de dados é feito localmente no dispositivo móvel.

b) Aplicações online: neste contexto assumimos que uma conexão entre o dispositivoe seu back-end estará disponível sempre, ou seja, haverá acesso a internet. Assim,estas aplicações não funcionam sem esta conexão. Outro ponto relevante é que astecnologias web podem ser usadas nestes Apps.

c) Aplicações mistas: são Apps que continuam funcionais quando não estão online, po-rém algumas de suas funcionalidades não podem ser acessadas por demandaremcomunicação com um servidor de back-end. As demais funções não sofrem restrições.

Assim, ao pensar na arquitetura de uma solução para ambientes móveis, váriosfatores devem ser levados em conta para que seja construído um software com qualidade. Ao

40 Capítulo 4. Aplicações Móveis

usarmos MCC, conforme vimos na seção 2.4, vários destes desafios podem ser amenizados.

4.2 Tecnologias de Desenvolvimento

Existem várias maneiras de se implementar um aplicativo para um dispositivo móvel.O desenvolvedor pode escolher programar dentre três tipos de tecnologias: desenvolvimentonativo, aplicações Cross-Platform e aplicações Web móveis (??). Cada uma possui suasvantagens e desvantagens e a melhor escolha depende de cada projeto, da equipe dedesenvolvimento, bem como das funcionalidades que o sistema deve possuir.

A seguir, discutiremos sobre cada uma destas formas de se desenvolver uma aplicaçãoe, ao final, na tabela 2, mostraremos um resumo sobre as três soluções.

4.2.1 Desenvolvimento nativo

A construção do aplicativo é feita em seu código nativo para rodar em um dispositivoe sistema operacional específicos. Aplicativos construídos desta forma oferecem a maisrica experiência de usuário, pois são otimizados para o ambiente onde irão rodar e parao qual foram construídos. Como o aplicativo fica instalado no próprio dispositivo, eleconsegue rodar offline. A transferência de dados ocorre quando a conexão com a interneté restaurada.

Outra grande vantagem desta tecnologia é que ela provê acesso completo a todosos recursos do aparelho, tanto de hardware, como GPS e câmera, quanto de software, comocalendário, contatos e arquivos. Porém, sua maior desvantagem é quanto ao custo. Comoo aplicativo é construído especificamente para um determinado sistema operacional, de 75a 80% da aplicação normalmente precisa ser reconstruída, caso se queira rodá-la em outraplataforma1. O que também acarreta em outro problema: a linguagem de desenvolvimento.Se formos pegar os três principais sistemas operacionais do mercado (iOS, Android eWindows), cada um deles exige conhecimento em uma linguagem de programação diferente(Objective-C/Swift, Java e .NET respectivamente). Para o cenário de uma empresa, ouela precisa ter profissionais treinados em múltiplas tecnologias, ou contratar pessoasespecializadas para cada plataforma. As duas opções acabam gerando custos a mais paraa companhia.

Outro empecilho desta solução é que ela exige o desenvolvimento, teste e distribuição,cada vez que uma nova versão do sistema operacional é lançada.

Os aplicativos desenvolvidos por esta tecnologia são baixados diretamente da appstore e ficam instalados no aparelho.

1 Este cenário se aplica para desenvolvimento da interface do cliente e não servidor (??).

4.2. Tecnologias de Desenvolvimento 41

4.2.2 Aplicações Coss-Platform

A construção do aplicativo é feita utilizando-se um framework cross-platform quepode ser rodado em múltiplas plataformas móveis.

Os principais frameworks deste tipo são Appcelerator2, PhoneGap3, RhoMobile4 eIBM Worklight5.

A ideia deles é permitir que os desenvolvedores construam sua aplicação emlinguagens mais amplamente conhecidas, como Javascript e HTML, e adaptar este códigopara múltiplas plataformas utilizando o próprio framework. Desta forma consegue-sediminuir para 20 a 25% o esforço adicional para adaptar a aplicação para cada plataforma,uma vez que a aplicação base esteja construída (??). Isto torna esta solução menos custosaem relação ao desenvolvimento nativo, quando o objetivo é construir um aplicativo multi-plataforma. Porém, ela não consegue prover a mesma experiência de usuário que aplicaçõesfeitas no código nativo e também não tem acesso a todos os recursos e capacidades doaparelho6.

Sempre que uma nova versão do sistema operacional fica disponível, demora umtempo para o framework suportar esta mudança e, na verdade, não há garantia de queestas plataformas consigam suportar as novas versões.

Os aplicativos desenvolvidos por esta tecnologia também são baixados diretamenteda app store e ficam instalados no aparelho.

4.2.3 Aplicações Web móveis

A construção do aplicativo é feita para rodar pela internet através de um servidorcentral que pode ser acessado por qualquer dispositivo pelo browser.

A grande vantagem desta solução é conseguir rodar em qualquer smartphone outablet, independente do sistema operacional. No entanto, ela possui duas grandes limitações:o fato de ser necessário ter sempre uma conexão com a internet, e o fato de não ser possívelutilizar nenhum dos recursos do aparelho7.

É importante ressaltar que, mesmo com a promessa de funcionar em qualquersistema operacional, aplicativos construídos utilizando HTML5 ainda precisam de ajustespara diferentes plataformas.

2 http://www.appcelerator.com3 http://phonegap.com4 http://rhomobile.com5 http://www-03.ibm.com/software/products/en/mobilefirstfoundation6 Com exceção do Appcelerator que consegue criar uma aplicação nativa para cada plataforma suportada,

uma vez que o código base estiver escrito (??).7 Uma versão do HTML5 em andamento prevê entregar conteúdo web com uma sensação muito mais

próxima as de aplicações nativas e com algumas funcionalidades disponíveis.

42 Capítulo 4. Aplicações Móveis

Abordagens deDesenvolvimento

Desenvolvimentonativo

Aplicações Cross-Platform

Aplicações Webmóveis

Definições eFerramentas

Construção do aplicativoutilizando ferramentasnativas como:- iPhone SDK- Android SDK- Windows Phone SDK

Construa uma vez edisponibilize para múltiplasplataformas:- RhoMobile- Titanium Appcelerator- PhoneGap- Worklight- etc.

Construção utilizandotecnologias Web:- HTML5- Sencha- JQuery Mobile- etc.

Linguagens deProgramação

- iPhone: Objective-C eSwift- Android: Java- Windows Phone: .NET

- RhoMobile: Ruby on Rails- Appcelerator: Javascript,HTML- PhoneGap: Javascript, HTML- Worklight: Javascript, HTML

- Javascript, HTML

Forma deentrega App stores App stores Pela internet

Principais casosde uso

- Aplicações quenecessitam de uma maiorexperiência de usuário- Uso offline- Aplicações que precisemutilizar amplamente osrecursos do aparelho

- Aplicações mais simples- Uso offline- Distribuição para vários tiposde dispositivos- Aplicações que não necessitamde uma grande utilização dosrecursos do aparelho

- Experiência de usuáriogenérica- Dependem de conexãocom a internet- Quantidade moderada defunções para o dispositivo

Tabela 2 – Resumo das tecnologias de desenvolvimento para aplicações móveis (??)

Cada coluna da tabela 2 se refere a uma das três tecnologias de desenvolvimentode aplicativos móveis e é dado resumidamente um comparativo entre os principais pontosdiscutidos nesta seção.

4.3 A Escolha da Melhor TecnologiaA escolha da melhor tecnologia, como já mencionado, depende de diversos fatores,

como a audiência, funcionalidades necessárias, equipe de desenvolvimento e tempo dispo-nível. Por exemplo, se o seu aplicativo também precisar funcionar offline, uma aplicaçãoWeb móvel pode não ser a melhor escolha. Se você dispõe de pouco tempo, mas precisa deum aplicativo para mais de uma plataforma, as aplicações Cross-platform ou Web móveispodem ser o ideal.

Como o objetivo principal deste trabalho é mostrar a integração entre a nuveme a aplicação móvel, não é necessário o desenvolvimento de uma aplicação para mais deuma plataforma, mas queremos que a aplicação funcione offline. Dentre os principaissistemas operacionas: iOS, Android e Windows, possuímos muito mais familiaridade coma linguagem de desenvolvimento do iOS (Objective-C/Swift) que é baseada em C, do quecom as linguagens dos outros sistemas (Java e .NET). Sendo assim, escolhemos utilizar atecnologia de desenvolvimento nativo para o sistema iOS para desenvolver nossa aplicação,cujos detalhes estão descritos no próximo capítulo.

43

5 Descrição da Implementação

Inicialmente, o nosso objetivo era conseguir integrar a aplicação que foi construída,com o back-end na nuvem da Google. Porém, encontramos problemas durante esta inte-gração. Os tutoriais disponibilizados pela Google não são interativos, eles apenas dizemos comandos e os passos que devem ser seguidos, mas não explicam o porquê de seguirtais passos, nem o que os comandos solicitados deveriam fazer. Como eles não dão umaexplicação sobre o caminho que está sendo seguido, nos deparamos com vários errosinesperados e alguns comandos que não funcionavam conforme o descrito.

A Google disponibiliza alguns tutoriais explicando como fazer a integração comaplicativos desenvolvidos para Android, mas ela não dá o mesmo suporte para iOS. Noinício deste trabalho existia uma página1 com exemplos e um passo-a-passo para integraçãocom iOS, mas ela foi modificada durante o desenvolvimento deste trabalho, não contendomais as explicações necessárias para esta integração.

Conseguimos, então, encontrar um tutorial em um blog (??) com explicações sobrecomo e o que deve ser feito para realizar esta integração. Embora este tutorial seja paraAndroid, nós percebemos que os primeiros passos são os mesmo, independente da plataformade desenvolvimento do aplicativo. Como não havia mais tempo hábil para migrar nossaaplicação iOS para Android, será descrito até onde chegamos nesta implementação, o quedeveria ser feito para concluir a integração e será dada uma explicação sobre os problemasencontrados.

Para isto, este capítulo está dividido da seguinte forma: a seção 5.1 dará umadescrição do aplicativo desenvolvido para este trabalho; a seção 5.2 irá descrever emdetalhes como realizar a integração do aplicativo com a plataforma da Google, indo desdea criação do back-end, explicando também os problemas que tivemos; por fim, a seção 5.3descreve os resultados obtidos e a nossa conclusão geral sobre os problemas encontrados ea viabilidade de se utilizar a plataforma da Google para este tipo de aplicação.

5.1 Nossa Aplicação

A plataforma para o desenvolvimento de aplicativos iOS oferecida pela Apple é cha-mada de Xcode. Em sua mais nova versão, ela oferece duas linguagens de desenvolvimento,Objectve-C e Swift, ambas baseadas na linguagem C. Para a construção do aplicativo foiutilizada a linguagem Objective-C, pois a Swift foi lançada no meio da elaboração destetrabalho, em Junho de 2014.

1 https://cloud.google.com/cloud/samples/mbs

44 Capítulo 5. Descrição da Implementação

Para testar as funcionalidades básicas da GCP e sua operabilidade, criamos umaplicativo chamado “Lista de Livros”. Nele, o usuário pode incluir, editar e remover livrosde uma lista, alterando o nome, foto e dando uma classificação para o livro, indo de uma(ruim) até cinco (ótimo) estrelas.

Originalmente, o objetivo era que a lista de livros seria armazenada tanto nodispositivo móvel quanto na nuvem. Esta forma de armazenamento funcionaria como umespelho. Por exemplo, ao adicionarmos um livro na lista, ele seria salvo na lista local doaparelho e uma requisição seria enviada para adicionar também na lista salva na nuvem,sempre quando houver conexão com a internet. Desta forma, pensando nos conceitos deusabilidade do cliente, o aplicativo conseguiria visualizar, remover e incluir itens, mesmoquando não houvesse esta conexão.

O aplicativo também faria a autenticação do usuário pela GCP, conforme explicadono capitulo 3.2.1. Desta forma, sempre que o cliente logasse de um dispositivo diferente efizesse a autenticação, o aplicativo buscaria a lista de livros já armazenada na nuvem e atraria para o dispositivo em questão, salvando uma cópia na memória interna.

(a) Tela inicial com a lista doslivros

(b) Tela de detalhes do livro

Figura 5 – Telas do aplicativo

A figura 5a mostra a tela inicial do aplicativo, com a lista de livros do usuário.Esta lista mostra a foto da capa e o nome do livro. Ao clicarmos em um dos itens, seremosdirecionados à tela de detalhes, mostrada na figura 5b. Aqui podemos editar o nome ea imagem, e também fazer a classificação do livro. Este livro em questão possui umaclassificação de 4 estrelas.

A partir da tela inicial podemos também adicionar um novo item à lista, clicandono símbolo de soma presente no canto superior direito. Ao fazer isso, seremos levados à

5.2. Construção da Arquitetura GCP 45

(a) Tela para adição de umnovo item

(b) Tela para remoção de umitem

Figura 6 – Mais telas do aplicativo

tela de adição, que pode ser vista na figura 6a. Nesta tela daremos um nome ao novo livroe adicionaremos uma capa e uma classificação.

Pode-se também excluir um livro da lista. Na tela inicial, basta clicar em “Edit”,no canto superior esquerdo. Será mostrado uma “bolinha” vermelha ao lado de cada livro,conforme a figura 6b. Basta então clicar na “bolinha” que está ao lado do livro que sequer excluir. Depois clicamos em “Done” e o aplicativo voltará à tela inicial com o livroexcluído.

5.2 Construção da Arquitetura GCP

Para iniciarmos a construção do back-end na GCP, precisamos criar um Projeto.Ele será o ambiente de desenvolvimento onde ocorrerá a criação da arquitetura sugeridapela Google que vimos na seção 3.2.1. É onde o nosso back-end será criado e rodado.

A criação de um novo projeto na GCP é uma tarefa simples, é disponibilizado umtutorial para esta criação (??), é necessário apenas possuir uma conta de e-mail da Googlee em poucos passos já é possível visualizar seu projeto de dentro do Developers Console.

Com o projeto criado, podemos iniciar o desenvolvimento do back-end e da API decomunicação entre ele e os dispositivos móveis. Para isso, iremos focar nos dois principaiscomponentes da arquitetura: o Google App Engine e o Google Cloud Endpoints.

Como podemos notar na figura 7, o back-end API é uma aplicação App Engineque executa a lógica e outras funções dos clientes móveis e web. Por ser uma aplicaçãoApp Engine, o desenvolvedor pode utilizar todas as funcionalidades e serviços do back-end,


Figura 7 – Arquitetura básica do Cloud Endpoints (??)

que podem ser acessadas pelos clientes através dos Endpoints por uma API.

Iremos mostrar como criar a comunicação entre cliente (usuário) e servidor (back-end) através da Google Cloud Endpoints e como a arquitetura processa as informaçõesprovenientes do cliente.

A Google Cloud Endpoints consiste de ferramentas, bibliotecas e recursos quepermitem gerar API’s e bibliotecas do cliente a partir de uma aplicação App Engine(back-end API) simplificando o acesso do cliente a dados de outras aplicações. O Endpointstornam mais fácil a criação de um back-end web, tanto para clientes web quanto móveis.

É possível fazer a criação de clientes móveis que utilizem o back-end da App Enginesem os Endpoints. Porém o processo é muito mais fácil e simples ao utilizá-lo, pois elelibera o desenvolvedor da necessidade de escrever uma lógica para a comunicação como App Engine. As bibliotecas do cliente geradas pelos Endpoints torna possível fazerchamadas diretas à API.

Sua lógica pode ser feita tanto utilizando a linguagem Java como Phyton. Paraeste trabalho escolhemos utilizar Java por questões de maior facilidade e conhecimentonesta linguagem.

O processo de desenvolvimento pode ser resumido nos seguintes passos:

1. Criar o projeto do back-end API;

2. Criar o código back-end da API para comunicação entre o dispositivo móvel e a AppEngine;

3. Configurar o código para que as classes e as bibliotecas do cliente possam ser geradas;

4. Gerar as bibliotecas do cliente;

5. Escrever sua aplicação cliente, utilizando as bibliotecas do cliente quando fizer chamadasao back-end API.


A Google disponibiliza um Plugin para o Eclipse 2 e para o Android Studio3, quetorna mais fácil a criação e configuração de várias funções durante o desenvolvimento.Para este trabalho iremos utilizar o Eclipse4 para o processo de desenvolvimento5.

O primeiro passo já foi executado no começo desta seção. Com o ambiente dedesenvolvimento já configurado, as seções 5.2.1 à 5.2.3 irão descrever os passos 2 ao 5.

5.2.1 Criação do Código back-end da API

Iremos mostrar como podemos escrever a nossa camada de API manualmente, comajuda das APIs da Google Cloud Endpoits. Iremos escrever uma REST API que expõenosso objeto (Lista de Livros) e fornece métodos API para adicionar, atualizar, remover econsultar os livros já adicionados.

O objetivo é escrever uma API pública que nos permite administrar nossa Lista deLivros. Nosso objeto “Book” terá os seguintes atributos:

• id: Um identificador único para cada livro no sistema;

• autor (author): O nome do autor que escreveu o livro;

• título (title): Título do livro.

Uma amostra do nosso código back-end inicial pode ser visto na figura 8.

Neste código, fazemos a declaração do objeto “Book” com os atributos já mencio-nados, e fazemos a declaração dos métodos básicos de manipulação deste objeto.

Na figura 9 podemos ver o código da implementação dos métodos utilizados paragerenciar nossa Lista de Livros.

Este arquivo contém os métodos para adicionar, atualizar, remover e consultartodos os livros adicionados ou por id ou também por autor.

O método “addBook” irá adicionar um novo livro a lista, com sua nova id, nome doautor e título do livro, e irá retornar o novo objeto Book que foi adicionado com sucesso alista.

O método “updateBook” recebe como parâmetro o objeto Book que deve seratualizado e também irá retornar o objeto atualizado com sucesso.2 Para mais informações acesse: https://developers.google.com/eclipse/docs/getting_started3 Para mais informações acesse: http://googlecloudplatform.blogspot.com.br/2013/06/tutorial-adding-

cloud-back-end-to-your-application-with-android-studio_26.html4 http://www.eclipse.org/home/index.php5 Como alternativa ao Eclipse, também é possível utilizar outros métodos, descritos em:

https://cloud.google.com/appengine/docs/java/endpoints/


Figura 8 – Parte do código back-end da API

O método “removeBook” recebe como parâmetro o id do objeto Book que se desejaremover da lista.

Os diferentes métodos “get” irão retornar um ou mais Books, dependendo docritério e irão retornar um tipo List que pode conter um ou mais registros.

Na próxima seção veremos como fazer para expor o código mostrado acima emuma REST API.

5.2.2 Configuração do Código

Conforme vimos anteriormente na seção 2.5, o Google Clound Endpoints utiliza oprotocolo REST para a comunicação entre cliente e servidor. Como este protocolo utilizaos métodos do protocolo HTTP, temos que fazer um mapeamento dos nossos métodospara os equivalentes em HTTP, como explicado na seção 2.1.2. Este mapeamento estádescrito na tabela 3:


Figura 9 – Código back-end da API contendo a implementação dos métodos

CRUD HTTP Nossos MétodosCreate POST addBookRead GET getBooks, getBooksByAuthor e getBook

Update PUT updateBookDelete DELETE removeBook

Tabela 3 – Mapeamento dos métodos CRUD e HTTP para os nossos métodos

O código irá se comunicar com o back-end através do protocolo HTTP. Feito estemapeamento, podemos agora converter o nosso código com a implementação dos métodospara uma classe da Google Cloud Endpoints6. Está conversão pode ser vista na figura 10.

A classe padrão “java.lang.Exception” existente no código da figura 9 foi substituida6 Para mais detalhes sobre esta conversão veja: cloud.google.com/appengine/docs/java/endpoints/annotations


Figura 10 – Código back-end da API contendo a conversão dos métodos

pela classe “NotFoundException”, que faz parte das classes da Google Cloud Endpoints7.

Para identificarmos esta classe como sendo uma classe API, utilizamos a notaçãoda linha 12, onde damos um nome para a nossa API, a versão e uma descrição. Caso odesenvolvedor não faça esta declaração, a Google usará valores padrões.

Cada um dos métodos recebe a notação “@ApiMethod” e é declarado em seguida onome do respectivo método na API. Devemos também colocar a notação “@Named” antesde cada parâmetro que a API Method deve considerar. Estes são os parâmetros cujo valorserá passado pelo próprio cliente.7 Outras classes de exceção podem ser vistas em: https://cloud.google.com/appengine/docs/java/endpoints/exceptions


O mapeamento que fizemos na tabela 3 não foi especificado no código. Isto não énecessário, pois o próprio Cloud Endpoints consegue converter corretamente estes métodos,utilizando os métodos HTTP corretos. Mas se desejarmos, também é possível especificar ométodo HTTP utilizado através da notação “httpMethod”8.

Depois de terminada a conversão, podemos testar localmente a API que acabou deser criada. Para isto, deve-se compilar e rodar o código. Se tudo der certo, é possível ver olocal onde a aplicação está rodando. Conforme a figura 11, nossa aplicação está na porta8888.

Figura 11 – Mensagem com informação sobre o local em que a aplicação está rodando

Deve-se então acessar a seguinte URL: http://localhost:8888/_ah/api/explorer.Esta URL irá nos levar a página da Google APIs Explorer onde o nosso código back-endda API está rodando, conforme podemos ver na figura 12.

Figura 12 – Página web com a API rodando localmente

Pode-se notar que o APIs Explorer utilizou a nossa notação na linha 12 do códigoda figura 10 para criar o nome, versão e descrição da API.

Se clicarmos no link “bookapi API” será listado todos os métodos que foramimplementados. Podemos notar também pela figura 13 que o nome dos métodos é o quefoi declarado pela notação @APIMethod.8 Mais informações sobre esta notação podem ser vistas em:

https://cloud.google.com/appengine/docs/java/javadoc/com/google/appengine/api/urlfetch/HTTPMethod


Figura 13 – Lista dos métodos criados para a API

Para demonstrar o funcionamento da aplicação, vamos adicionar um livro à lista.Ao clicar no link “bookapi.add” será apresentada uma tela onde é possível incluir a id donovo livro, o nome do autor e o nome do livro, conforme a figura 14.

Figura 14 – Tela com funcionalidades para adicionar um livro a lista

Ao clicar no botão “Execute” a API irá adicionar o novo livro na lista. Se olharmosa requisição que o sistema retorna, podemos ver que uma chamada ao método POST doHTTP foi executada, conforme a figura 15.

Para ver se a inclusão foi executada com sucesso, pode-se voltar na lista de métodose escolher o método “bookapi.list” e clicar no botão “Execute”. A execução irá fazer umachamada ao método GET do HTTP e retornará todos os livros incluídos até o momento


Figura 15 – Retorno da requisição do método addBook

na lista. Podemos ver esta resposta na figura 16. Adicionamos mais um livro na lista sópara demostrar esta funcionalidade.

Todos os outros métodos da lista irão fazer chamadas a métodos HTTP igual aosdescritos até agora, conforme cada caso. Não iremos mostrar a execução de todos eles,pois apenas um exemplo é o suficiente para entender o funcionamento do código back-endda API. Caso haja interesse em entender melhor as outras classes, indicamos o tutorialque utilizamos para este desenvolvimento (??).

A conversão do código para a classe da Google Cloud Endpoints foi feita manual-mente. Porém, vale apontar que esta conversão pode ser gerada automaticamente peloEclipse através do Plugin da Google adicionado9.

5.2.3 Geração das Bibliotecas do lado cliente

Até agora, temos um back-end API hospedado na nuvem (App Engine). Assim,quando o dispositivo móvel fizer uma requisição, o App Engine saberá qual métodoexecutar. Porém, as instâncias do aplicativo desenvolvido ainda não conhecem a API e,por essa razão, precisamos destas bibliotecas, que irão agir como um intermediário entre oaplicativo e o App Engine e que serão utilizadas no aplicativo para invocar as operaçõesCRUD da API.

Note que, até este momento, o processo é o mesmo, tanto para desenvolvimentoAndroid quanto para iOS. Mas, para gerar as bibliotecas, o processo se torna diferentepara cada uma das plataformas.9 Um tutorial sobre como fazer a geração deste arquivo automaticamente pode ser vista em:

http://rominirani.com/2014/01/13/google-cloud-endpoints-tutorial-part-2/


Figura 16 – Retorno da requisição do método listBook

Como já mencionado, esta lógica pode ser feita tanto em Java como em Python.Quanto aos processos de criação das bibliotecas, estes também diferem, dependendoda linguagem escolhida. Como a criação do back-end foi feita em Java, a geração dasbibliotecas também devem ser feitas nesta linguagem.

Para gerar estas bibliotecas e realizar a integração com a App Engine, é precisobaixar o pacote com os SDKs da Google App Engine de acordo com a linguagem escolhida.Os passos para a instalação destes pacotes pode ser visto em (??).

A geração destas bibliotecas, por sua vez, pode ser feita de duas formas diferentes:utilizando o projeto Apache Maven10 ou por linha de comando11.

Os últimos erros encontrados foram especificamente nesta parte. Não foi possívelgerar as bibliotecas, pois houveram problemas durante esta execução.

Primeiramente ocorreram alguns erros inesperados na geração do back-end. Após

10 http://maven.apache.org11 Ou ainda, para Android, pode ser feito através do Plugin do Eclipse:

https://cloud.google.com/appengine/docs/java/endpoints/gen_clients

5.3. Resultados na Integração com a GCP 55

estes erros terem sido superados e o back-end criado, tentou-se gerar as bibliotecas utilizandoo Apache Maven. Houveram dificuldades na instalação do Maven e em seguida não foipossível fazer ele interegir com o Xcode. Ao tentar gerar as bibliotecas por linha de comandoocorreram erros durante a execução. Não foi possível solucionar nenhum destes problemasatravés do tutorial da Google, por ele não possuir nenhuma explicação complementar.

Neste momento tentamos pesquisar tutoriais fora da documentação da Google,porém só foram encontrados para o sistema Android. Ao tentar seguir um deles houveramproblemas na instalação de duas versões diferentes do Eclipse, tanto na versão Luna quantona Juno. Na primeira não foi possível realizar a geração do back-end devido a um conflitocom o Plugin da Google. Na segunda houveram conflitos na integração com o Maven. Apósalgumas tentativas foi possível realizar a instalação do Plugin sem o Maven. Conseguimosentão construir o back-end e as API’s conforme descrito nesta seção e foi então que ocorreuo erro final na geração das bibliotecas, não sendo possível avançar com a implementaçãodeste trabalho.

O passo seguinte seria acrescentar a chamada das bibliotecas no códico da aplicaçãopara conseguir fazer a ligação com o Endpoints e, consequentemente, a comunicação como App Engine.

5.3 Resultados na Integração com a GCP

A primeira impressão que temos ao entrar no site da GCP é que interagir umaplicativo com o back-end é muito fácil. A própria empresa divulga que isto pode ser feitoem menos de 300 segundos. Porém, o que percebemos é que a realidade não é essa. Érealmente possível interagir os dois em pouco tempo, caso você já tenha um conhecimentoprévio com a utilização de PaaS ou com a própria plataforma. Para pessoas sem experiênciacom este tipo de tecnologia, como nós, isto pode se tornar um grande desafio.

Como comentamos no começo deste trabalho, a Google possui um grande númerode documentações e tutoriais, mas eles não são didáticos e nem interativos. Em sua grandemaioria, explicam apenas os passos e comandos que devem ser seguidos, mas não explicamo porquê de segui-los, e nem os resultados que devemos obter.

Conforme explicado nas seções anteriores, não há nenhum tutorial disponível paraiOS com exemplos e explicações, como existe para Android, o único disponível foi removidodo site.

Não sabiamos o resultado esperado nem o porquê de se executar alguns coman-dos, o que tornou muito complicado encontrar soluções para os problemas e erros daimplementação.

A Google só possui suporte por e-mail para usuários de classes Silver, Gold ou


Platinum e por telefone apenas para Gold e Platinum12. Como o pacote que contratamosera o Bronze, contatos para auxílio de nossas dificuldades não foram possíveis.

Acabou sendo gasto muito tempo para conseguir entender o que realmente deveriaser feito para conseguir interagir uma aplicação com o back-end. A documentação daGoogle não forneceu o suporte necessário para isso e acabou sendo preciso procurar ajudaem fóruns e em outros blogs. Mas ainda sim, o suporte para aplicativos desenvolvidos emiOS é muito escasso.

Pelos motivos descritos acima, entendemos que, para aplicativos desenvolvidos parao sistema iOS, a Google Cloud Platform pode não ser a melhor opção.

12 Site para o suporte da Google: https://support.google.com/cloud/answer/3420056?hl=enref_topic=3473162

57

6 Conclusão

Mobile Cloud Computing é uma tecnologia que só tende a crescer nos próximos anos.O aumento do número de smartphones, a crescente demanda por aplicativos para estesaparelhos e a fácil disponibilização destes aplicativos para o público, possibilitou a criaçãode um mercado onde não apenas empresas, mas qualquer pessoa com algum conhecimentode desenvolvimento, possa criar e disponibilizar seus próprios aplicativos. Neste cenário,a MCC vem como uma grande aliada, uma vez que reduz consideravelmente os custosenvolvidos em manter uma infraestrutura para seu back-end, visto que o desenvolvedorpagará apenas pelo que ele utilizar. Este é o principal motivo pelo qual acreditamos queesta tecnologia, que é relativamente nova, ainda irá evoluir muito daqui para frente.

Este trabalho forneceu uma visão geral sobre as tecnologias e definições envolvi-das em MCC e descreveu em detalhes o funcionamento de uma das plataformas maisimportantes no mercado para soluções móveis, a Google Cloud Platform. Foi descrito asprincipais tecnologias e abordagens para a construção de um aplicativo móvel que derama base para a construção do nosso próprio aplicativo. Por fim discutimos como deve serfeita a integração da aplicação com a plataforma da Google, os problemas encontradosque impossibilitaram esta integração e a inviabilidade de se utilizar esta plataforma paraaplicativos desenvolvidos no sistema iOS.

59

Referências

1 About ssl certificates and ssl encryption. Disponível em <https://www.digicert.com/ssl.htm>. Acessado em 24 out, 2014. Nenhuma citação no texto.

2 Google cloud platform - mongo db. Disponível em <https://cloud.google.com/solutions/mongodb/>. Acessado em 05 dez, 2014. Nenhuma citação no texto.

3 Mobile solutions on google cloud platform. Disponível em <https://cloud.google.com/developers/articles/mobile-application-solutions/>. Acessado em 23 set, 2014. Nenhumacitação no texto.

4 Soa manifesto. Disponível em <http://www.soa-manifesto.org>. Acessado em 24 out,2014. Nenhuma citação no texto.

5 How to choose the right architecture for your mobile application. Disponível em <http://rapidvaluesolutions.com/whitepapers/how-to-choose-the-right-architecture.html>,Novembro 2012. Acessado em 21 set, 2014. Nenhuma citação no texto.

6 Comparison between various web services data transfer frameworks for mobileenabling applications. Disponível em <http://rapidvaluesolutions.com/whitepapers/mobility-information-series.html>, Janeiro 2013. Acessado em 25 out, 2014. Nenhumacitação no texto.

7 43 milhões de brasileiros acessam internet por dispositivos mó-veis. Disponível em <http://datafolha.folha.uol.com.br/mercado/2014/01/1400618-43-milhoes-de-brasileiros-acessam-internet-por-dispositivos-moveis.shtml>,Janeiro 2014. Acessado em 08 set, 2014. Nenhuma citação no texto.

8 5g. Disponível em <http://en.wikipedia.org/wiki/5G>, 2014. Acessado em 18 nov,2014. Nenhuma citação no texto.

9 Backend api tutorial. Disponível em <https://cloud.google.com/appengine/docs/java/endpoints/getstarted/backend/>, Setembro 2014. Acessado em 29 nov, 2014. Nenhumacitação no texto.

10 Crescimento da internet móvel ’salta aos olhos’. Disponível em<http://www.mc.gov.br/sala-de-imprensa/todas-as-noticias/institucionais/30310-crescimento-da-internet-movel-salta-aos-olhos-afirma-bernardo>, Março2014. Acessado em 08 set, 2014. Nenhuma citação no texto.

11 Google app engine sdk. Disponível em <https://cloud.google.com/appengine/downloads>, Novembro 2014. Acessado em 29 nov, 2014. Nenhuma citação no texto.

12 Google cloud endpoints overview. Disponível em <https://cloud.google.com/appengine/docs/java/endpoints/>, Novembro 2014. Acessado em 29 nov, 2014. Nenhumacitação no texto.

13 Google cloud endpoints tutorial. Disponível em <http://rominirani.com/2014/01/10/google-cloud-endpoints-tutorial-part-1/>, Janeiro 2014. Acessado em 29 nov, 2014.Nenhuma citação no texto.

https://www.digicert.com/ssl.htm

https://www.digicert.com/ssl.htm

https://cloud.google.com/solutions/mongodb/

https://cloud.google.com/solutions/mongodb/

https://cloud.google.com/developers/articles/mobile-application-solutions/

https://cloud.google.com/developers/articles/mobile-application-solutions/

http://www.soa-manifesto.org

http://rapidvaluesolutions.com/whitepapers/how-to-choose-the-right-architecture.html

http://rapidvaluesolutions.com/whitepapers/how-to-choose-the-right-architecture.html

http://rapidvaluesolutions.com/whitepapers/mobility-information-series.html

http://rapidvaluesolutions.com/whitepapers/mobility-information-series.html

http://datafolha.folha.uol.com.br/mercado/2014/01/1400618-43-milhoes-de-brasileiros-acessam-internet-por-dispositivos-moveis.shtml

http://datafolha.folha.uol.com.br/mercado/2014/01/1400618-43-milhoes-de-brasileiros-acessam-internet-por-dispositivos-moveis.shtml

http://en.wikipedia.org/wiki/5G

https://cloud.google.com/appengine/docs/java/endpoints/getstarted/backend/

https://cloud.google.com/appengine/docs/java/endpoints/getstarted/backend/

http://www.mc.gov.br/sala-de-imprensa/todas-as-noticias/institucionais/30310-crescimento-da-internet-movel-salta-aos-olhos-afirma-bernardo

http://www.mc.gov.br/sala-de-imprensa/todas-as-noticias/institucionais/30310-crescimento-da-internet-movel-salta-aos-olhos-afirma-bernardo

https://cloud.google.com/appengine/downloads

https://cloud.google.com/appengine/downloads





60 Referências

14 Interface de programação de aplicações. Disponível em <http://pt.wikipedia.org/wiki/Interface_de_programaç~ao_de_aplicaç~oes>, 2014. Acessado em 05 dez, 2014.Nenhuma citação no texto.

15 Message broker. Disponível em <http://en.wikipedia.org/wiki/Message_broker>,2014. Acessado em 23 set, 2014. Nenhuma citação no texto.

16 Smartphone users worldwide will total 1.75 billion in 2014. Disponível em <http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536>, Janeiro 2014. Acessado em 08 set, 2014. Nenhuma citação no texto.

17 Web services description language. Disponível em <http://en.wikipedia.org/wiki/Web_Services_Description_Language>, 2014. Acessado em 25 out, 2014. Nenhumacitação no texto.

18 Nenhuma citação no texto.

19 Rajkumar Buyya, James Broberg, and Andrzej M Goscinski. Cloud computing:Principles and paradigms, volume 87. John Wiley & Sons, 2010. Nenhuma citação notexto.

20 Hoang T Dinh, Chonho Lee, Dusit Niyato, and Ping Wang. A survey of mobile cloudcomputing: architecture, applications, and approaches. Wireless communications andmobile computing, 13(18):1587–1611, 2013. Nenhuma citação no texto.

21 Fábio Flatschart, Clécio Bachini, and Cesar Cusin. Open Web Platform. Brasport,2013. Nenhuma citação no texto.

22 Steve Francia. Rest vs soap, the difference between soap and rest. Disponívelem <http://spf13.com/post/soap-vs-rest>, Janeiro 2010. Acessado em 24 out, 2014.Nenhuma citação no texto.

23 Peter Garraghan, Paul Townend, and Jie Xu. An analysis of the server characteristicsand resource utilization in google cloud. In Cloud Engineering (IC2E), 2013 IEEEInternational Conference on, pages 124–131. IEEE, 2013. Nenhuma citação no texto.

24 Helton Simões Gomes. Teste do 5g, 250 mais veloz que 4g, deve começarem 2 anos. Disponível em <http://g1.globo.com/tecnologia/noticia/2014/07/teste-do-5g-250-mais-veloz-que-4g-deve-comecar-em-2-anos-diz-ericsson.html>, Julho2014. Acessado em 18 nov, 2014. Nenhuma citação no texto.

25 Eran Hammer. Beginner’s guide to oauth – part i: Overview. Disponível em<http://hueniverse.com/2007/10/04/beginners-guide-to-oauth-part-i-overview/>,Outubro 2007. Acessado em 24 out, 2014. Nenhuma citação no texto.

26 Samantha Murphy Kelly. Mobile devices will outnumber people by the end of theyear. Disponível em <http://mashable.com/2013/02/06/mobile-growth/>, Fevereiro2013. Acessado em 08 set, 2014. Nenhuma citação no texto.

27 Dejan Kovachev, Yiwei Cao, and Ralf Klamma. Mobile cloud computing: a comparisonof application models. arXiv preprint arXiv:1107.4940, 2011. Nenhuma citação no texto.

28 G Lakshmanan. Cloud computing relevance to enterprise. page 3, Abril 2009.Nenhuma citação no texto.

http://pt.wikipedia.org/wiki/Interface_de_programa�~ao_de_aplica�~oes

http://pt.wikipedia.org/wiki/Interface_de_programa�~ao_de_aplica�~oes

http://en.wikipedia.org/wiki/Message_broker

http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536



http://en.wikipedia.org/wiki/Web_Services_Description_Language

http://en.wikipedia.org/wiki/Web_Services_Description_Language

http://spf13.com/post/soap-vs-rest

http://g1.globo.com/tecnologia/noticia/2014/07/teste-do-5g-250-mais-veloz-que-4g-deve-comecar-em-2-anos-diz-ericsson.html

http://g1.globo.com/tecnologia/noticia/2014/07/teste-do-5g-250-mais-veloz-que-4g-deve-comecar-em-2-anos-diz-ericsson.html

http://hueniverse.com/2007/10/04/beginners-guide-to-oauth-part-i-overview/

http://mashable.com/2013/02/06/mobile-growth/

Referências 61

29 Elzavita MacLennan and Jean-Paul Van Belle. Factors affecting the organizationaladoption of service-oriented architecture (soa). Janeiro 2013. Nenhuma citação no texto.

30 Diogo Mafra. Como funciona a autenticação oauth. Disponível em <http://www.diogomafra.com.br/2010/09/como-funciona-autenticacao-oauth.html>, Setembro2010. Acessado em 24 out, 2014. Nenhuma citação no texto.

31 Peter Mell and Timothy Grance. The nist definition of cloud computing. page 2,Setembro 2011. Nenhuma citação no texto.

32 Snehal Mumbaikar and Puja Padiya. Web services based on soap and rest principles.International Journal of Scientific and Research Publications, 3(5), Maio 2013. Nenhumacitação no texto.

33 Tony Paw. Amazon s3, azure and google cloud prices compare. Disponível em <http://www.cloudberrylab.com/blog/amazon-s3-azure-and-google-cloud-prices-compare/>,Abril 2014. Acessado em 23 set, 2014. Nenhuma citação no texto.

34 Margaret Rouse. service-oriented architecture (soa). Disponível em <http://searchsoa.techtarget.com/definition/service-oriented-architecture>, 2014. Acessado em24 out, 2014. Nenhuma citação no texto.

35 Wei-Tek Tsai, Xin Sun, and J Balasooriya. Service-oriented cloud computingarchitecture. Information Technology: New Generations (ITNG), 2010 SeventhInternational Conference on, pages 684–689, Abril 2010. Nenhuma citação no texto.

36 Dave Vellante and David Floyer. What cloud computing means for next generationstorage infrastructure. Disponível em <http://wikibon.org/wiki/v/What_cloud_computing_means_for_next_generation_storage_infrastructure>, Dezembro 2010.Acessado em 08 set, 2014. Nenhuma citação no texto.

37 Manoel Veras. Virtualização - Componente Central do Datacenter. Brasport, 2011.Nenhuma citação no texto.

38 Peter Wayner. Ultimate cloud speed tests: Amazon vs. google vs. windowsazure. Disponível em <http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html?page=2>,Fevereiro 2014. Acessado em 23 set, 2014. Nenhuma citação no texto.

http://www.diogomafra.com.br/2010/09/como-funciona-autenticacao-oauth.html

http://www.diogomafra.com.br/2010/09/como-funciona-autenticacao-oauth.html

http://www.cloudberrylab.com/blog/amazon-s3-azure-and-google-cloud-prices-compare/

http://www.cloudberrylab.com/blog/amazon-s3-azure-and-google-cloud-prices-compare/

http://searchsoa.techtarget.com/definition/service-oriented-architecture

http://searchsoa.techtarget.com/definition/service-oriented-architecture

http://wikibon.org/wiki/v/What_cloud_computing_means_for_next_generation_storage_infrastructure

http://wikibon.org/wiki/v/What_cloud_computing_means_for_next_generation_storage_infrastructure

http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html?page=2

http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html?page=2

Google Cloud Platform para Aplicações Móveis - inf.ufpr.br · GustavoFelipeZandonáPuchalski...

Documents

Transcript of Google Cloud Platform para Aplicações Móveis - inf.ufpr.br · GustavoFelipeZandonáPuchalski...