Implementando padrões de controle de sessão para a plataforma Android

Apresentação em tema: "Implementando padrões de controle de sessão para a plataforma Android"— Transcrição da apresentação:

1 Implementando padrões de controle de sessão para a plataforma Android
Aluno: Hugo Leonardo Campos Ferreira Orientadora: Maria Augusta Vieira Nelson

2 Agenda Contextualização Problema Objetivo geral Objetivos específicos
Revisão bibliográfica Metodologia Estudo de caso Experimentos e resultados

3 Contextualização

4 Contextualização O telefone celular é um dos bens de consumo mais bem sucedidos do mundo (OPEN HANDSET ALLIANCE, 2007) 1,5 bilhão de aparelhos de televisão 1 bilhão de pessoas têm acesso à Internet quase 3 bilhões de pessoas têm um telefone celular A tendência é que as aplicações corporativas passem a executar também sobre a plataforma móvel (LECHETA, 2009)

5 Contextualização Aplicações corporativas, em geral, trabalham ou utilizam o conceito de sessão Sessão: “O intervalo decorrido entre o início de execução do aplicativo utilizado pelo usuário e sua finalização” (THE CRYPTHING INITIATIVE SIGNTHING PERSONAL EDITION, 2008). “Espaço de tempo compreendido entre o início e o fim da navegação de um usuário na Internet” (UOL, 2010).

6 Contextualização Tipos de aplicativo quanto à sessão:
Sem estado da sessão Visualização de produtos em um site Com estado da sessão Carrinho de compras de um site e-commerce Impossibilidade de se ter apenas servidores sem estado da sessão * certas interações cliente-servidor são intrinsecamente com estado

7 Contextualização Sessões com estado podem ser
Autenticadas Não autenticadas Toda sessão precisa ser encerrada em um determinado momento Solicitação do cliente Inatividade da sessão É uma medida de segurança e para liberação de recursos

8 Elucidação do trabalho

9 Problema Verificar o suporte que a API da plataforma móvel Android oferece ao desenvolvimento de aplicativos online com estado da sessão Verificar os pontos fortes e fracos ao se implementar as diferentes abordagens do padrão de Estado da Sessão descritos por Fowler (2006) nessa plataforma

10 Objetivo geral Avaliar a implementação de aplicativos online com gerenciamento de estado da sessão na plataforma do sistema operacional móvel Android

11 Objetivos específicos
Compreender os padrões arquiteturais referentes ao gerenciamento do estado da sessão Verificar como a API do Android oferece recursos ao gerenciamento de estado da sessão Selecionar e definir a aplicação alvo do estudo Definir alguns critérios de avaliação para submeter as aplicações desenvolvidas Desenvolver duas implementações da aplicação alvo: uma utilizando a abordagem de Gerenciamento de Estado da Sessão no Cliente e, a outra, no Servidor Avaliar e comparar as duas implementações tendo com base os critérios definidos

12 Justificativa Oferecer serviços online em plataformas móveis será um diferencial para as corporações Necessário garantir segurança dos dados desempenho adequado baixo custo de operação desses serviços Um dos mecanismos que devem ser bem projetados é o controle das sessões. Com a computação móvel se tornando uma tecnologia economicamente acessível, tornar-se-á um diferencial para uma corporação disponibilizar serviços online acessíveis através de dispositivos móveis, como smartphones, PDAs, tablets, etc.

13 Motivações Interesse pessoal pelo sistema Android por parte dos envolvidos no trabalho Tem sido difundido com muita força durante os últimos dois anos É um sistema operacional mantido pela Google Inc. Recebe atualizações e melhorias com frequência Tem uma API livre para o desenvolvimento de aplicações * Pesquisas recentes da AdMob (2010), a venda de dispositivos com esse sistema é a que mais tem crescido ao longo dos ano de 2009 e 2010.

14 Revisão bibliográfica
A plataforma Android

15 A plataforma Android É uma plataforma para desenvolvimento de sistemas em dispositivos móveis Foi concebida em 2007 pela Open Handset Alliance OHA: um grupo de gigantes das comunicações (operadoras de telefonia, empresas de comercialização e fabricantes de aparelhos móveis, de dispositivos semicondutores e de software) HTC, Motorola, ASUS, Samsung, Sony, Vodafone, Telefônica, nVidia, dentre outras, encabeçadas pela Google Falar apenas a primeira linha desse slide

16 A plataforma Android Componentes:
Um sistema operacional baseado no Linux Diversas bibliotecas (gerenciador de banco de dados, segurança, gráficos 3D, etc.) Um framework para desenvolvimento de aplicativos Linguagem de desenvolvimento é a linguagem Java Uma máquina virtual que executa os aplicativos (Dalvik) Ambiente de desenvolvimento Diversas aplicações nativas Isso é o que tenho de explicar quando estiver rolando o próximo slide

17 A plataforma Android Fonte: Android Developers (2007)
É uma plataforma para desenvolvimento de sistemas em dispositivos móveis Componentes: Um sistema operacional baseado no Linux Diversas bibliotecas (gerenciador de banco de dados, segurança, gráficos 3D, etc.) Um framework para desenvolvimento de aplicativos Linguagem de desenvolvimento é a linguagem Java Uma máquina virtual que executa os aplicativos (Dalvik) Ambiente de desenvolvimento Diversas aplicações nativas Fonte: Android Developers (2007)

18 Revisão bibliográfica
Estados da Sessão

19 Estados da Sessão De acordo com Fowler (2006) existem 3 abordagens diferentes para o gerenciamento de estado da sessão: Estado da Sessão no Cliente Estado da Sessão no Servidor Estado da Sessão no Banco de Dados

20 Estado da Sessão no Cliente
Armazena os dados de sessão no cliente Meios de armazenar os dados: Em apresentações Web: Codificados na URL Cookies Serializados em um campo escondido Em apresentações ricas: Em objetos no cliente É quase sempre utilizado em conjunto com outras abordagens para a identificação da sessão

21 Estado da Sessão no Cliente
Pontos positivos Permite implementar servidores sem estado Servidores mais baratos Facilita implementação de migração da sessão Alta tolerância a falhas do servidor Pontos negativos A contra-indicação dessa abordagem cresce de acordo com o volume de dados Segurança: os dados da sessão no cliente os deixam vulneráveis à leitura e alteração por espiões e usuários mal intencionados Ex. Dados de controle que ficarem na sessão podem ser acessados pelo usuário

22 Estado da Sessão no Servidor
Armazena os dados de sessão em um sistema no lado servidor Meio de armazenamento dos dados Na memória primária do servidor Serializado na memória secundária do servidor Em um banco de dados

23 Estado da Sessão no Servidor
Pontos positivos É a abordagem mais fácil de ser implementada Economia de largura de banda da rede Maior segurança Maior agilidade na recuperação da sessão Pontos negativos Necessita de servidor mais poderoso Apresenta dificuldades para implementar migração da sessão em clusters de computadores

24 Estado da Sessão no Banco de Dados
Armazena os dados de sessão no banco de dados Facilita a clusterização da aplicação Demanda grande esforço para isolar as os dados de sessão dos registros de dados Indicado quando é necessário haver recuperação automática de falhas e utilização de clusters

25 Revisão bibliográfica
Serviços RESTful

26 Serviços RESTful REST: Transferência de Estado Representacional*
O termo foi introduzido e definido em 2000 por Roy Fielding em sua tese de doutorado É um estilo de arquitetura de software para sistemas distribuídos como a World Wide Web Define um pequeno conjunto de restrições Serviços Web que são implementados de acordo com suas restrições são chamados RESTful Transferência de Estado Representacional: tal nome vem do comportamento de transferir entre cliente e servidor representações do estado do recurso Roy Fielding é um dos principais autores do protocolo HTTP

27 Restrições Cliente-servidor Sem estado
Cacheable (capacidade de se fazer cache) Sistema em camadas Código sob demanda (opcional) Interface uniforme Cacheable: para eliminar interações cliente-servidor, provendo escalabilidade e performance Sistemas em camadas podem prover escalabilidade habilitando balanceamento de carga e aplicar políticas de segurança

28 Estudo de caso

29 Metodologia

30 Estado da sessão no Android
Não foi encontrado em Android Developer's Guide (2010) uma forma definida para a implementação de estado da sessão Todo o projeto de gerenciamento dos dados de sessão ficam a cargo da equipe técnica Neste trabalho foi utilizado um objeto para armazenar os dados da sessão - Lembrar de falar que o Android é um cliente rico similar à biblioteca Swing, o que torna fácil projetar e manipular os objetos de sessão da forma desejada

31 Especificação do aplicativo

32 Especificação do aplicativo

33 Distribuição dos componentes

34 Sistema com sessão no cliente
Aplicação cliente-servidor em 3 camadas: Cliente Android Aplicação Web (Java Servlets + Tomcat) Banco de dados relacional (JPA + PostgreSQL)

35 Interface do Serviço Web
Operação Interface Listar tarefas GET/tasks Criar uma tarefa POST/tasks Obter uma tarefa GET/tasks/{id_da_tarefa} Modificar uma tarefa PUT/tasks/{id_da_tarefa} Apagar uma tarefa DELETE/tasks/{id_da_tarefa}

36 Classes: estado da sessão no cliente

37 Classes: estado da sessão no servidor
Utilização da HttpSession

38 Experimentos e resultados

39 Ambiente de testes Aparelho móvel Samsung Galaxy S
Android versão 2.2 (Froyo) Processador de 1GHz 512MB de memória RAM 8GB de memória interna e 2GB de memória externa Conexões Wi-Fi b/g e 3G

40 Ambiente de testes Servidor de aplicação e banco de dados
Windows 7 Professional 32bits 3GB de memória RAM Processador Intel core 2 duo 2.10GHz PostgreSQL 8.4 Tomcat 6.0

41 Consumo memória do aparelho móvel
Experimentos e resultados

42 Consumo memória do aparelho móvel
Busca comparar a quantidade de memória do dispositivo móvel que cada sistema desenvolvido consome Foram criados 10 usuários, cada um com uma quantidade diferente de tarefas, escalando de 10 até Foi utilizada perspectiva DDMS (Dalvik Debug Monitor Server)* Abrir eclipse Falar que é uma parte do plugin ADT que se integra ao Eclipse Falar o que a interface da DDMS oferece de recurso para desenvolvimento

43 Roteiro do teste Para cada usuário:
Iniciar o aplicativo Efetuar login / listar todas as tarefas do usuário Executar a ação “Cause GC” no DDMS para obter as informações sobre alocação na heap do processo do aplicativo O script foi executado uma vez para a aplicação com o estado da sessão no servidor e uma vez para a aplicação com estado da sessão no cliente

44 Resultados Abrir planilha

45 Análise dos resultados
Baixa diferença de utilização de recursos de memória do dispositivo móvel à medida que a quantidade de dados na sessão aumenta Os dados da sessão não estão contribuindo para o aumento no consumo de memória O consumo de memória aumenta devido à quantidade de objetos gráficos que são criados na tela Aplicações com estado da sessão no cliente podem ser viáveis em clientes Android* * Levando-se em consideração somente o consumo de memória

46 Teste de Segurança Experimentos e resultados

47 Teste de segurança Objetivo Utilizado o Microsoft Network Monitor 3.4
Tentar, de alguma forma, violar o acesso seguro às informações do sistema Utilizado o Microsoft Network Monitor 3.4 ferramenta que auxilia a análise de protocolos de redes TCP/IP HTTP FTP

48 Roteiro Microsoft Network Monitor escutando as requisições à interface de rede do servidor Cada aplicativo foi utilizado da seguinte forma: Logar com o usuário “hugo” Criar uma tarefa Concluir a tarefa criada Apagar a tarefa criada e concluída

49 Resultados Nos pacotes HTTP da aplicação com estado no cliente encontrou-se a string “aHVnbzoxMjM0” no cabeçalho “Authorization” das requisições

50 Resultados

51 Conclusão e trabalhos futuros

52 Conclusões Foi avaliado o consumo de recursos de hardware do aparelho móvel e a segurança dos dados A aplicação com estado da sessão no servidor demonstrou ser mais segura Pela inexistência de dados de credenciais de usuário nos cabeçalhos HTTP das requisições Contém apenas os cookies identificadores da sessão Foi possível obter os cookies a partir dos pacotes HTTP desta aplicação, mas não foi possível apropriar da sessão de usuário existente Credenciais incluídas no cabeçalho HTTP do aplicativo com estado da sessão no cliente: aumento do risco

53 Conclusões Utilização de recursos de hardware do aparelho móvel
diferença pequena de comportamento entre os dois aplicativos Constatação viabiliza a escolha da implementações de serviços Web sem estado Aumento de escalabilidade a um custo menor Preocupação maior com a segurança dos dados do usuário informar suas credenciais em todas as requisições é uma prática perigosa, deixando vulneráveis dados que podem ser sigilosos

54 Trabalhos futuros Medir outros fatores que influenciam na escolha da arquitetura de um sistema Tamanho, quantidade e frequência dos dados trafegados Escalabilidade do servidor Robustez Performance

55 Trabalhos futuros Comparar uma aplicação com estado da sessão no cliente desenvolvida sob a arquitetura REST com uma aplicação com estado da sessão no servidor desenvolvida sob a arquitetura SOA