Upload
internet
View
110
Download
3
Embed Size (px)
Citation preview
Implementando padrões de controle de sessão para
a plataforma Android
Aluno: Hugo Leonardo Campos FerreiraOrientadora: Maria Augusta Vieira Nelson
Contextualização Problema Objetivo geral Objetivos específicos Revisão bibliográfica Metodologia Estudo de caso Experimentos e resultados
Agenda
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)
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).
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
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
Contextualização
Elucidação do trabalho
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
Problema
Avaliar a implementação de aplicativos online com gerenciamento de estado da sessão na plataforma do sistema operacional móvel Android
Objetivo geral
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
Objetivos específicos
Revisão bibliográficaEstados 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
Estados da Sessão
Revisão bibliográficaServiç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
Serviços RESTful
Cliente-servidor Sem estado Cacheable (capacidade de se fazer cache) Sistema em camadas Código sob demanda (opcional) Interface uniforme
Restrições
Estudo de caso
Metodologia
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
Estado da sessão no Android
Especificação do aplicativo
Especificação do aplicativo
Distribuição dos componentes
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)
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}
Classes: estado da sessão no cliente
Classes: estado da sessão no servidor
Experimentos e resultados
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 802.11 b/g e 3G
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
Consumo memória do aparelho móvel
Experimentos e resultados
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é 10.000
Foi utilizada perspectiva DDMS (Dalvik Debug Monitor Server)*
Consumo memória do aparelho móvel
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
Roteiro do teste
Abrir planilha
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*
Análise dos resultados
Teste de SegurançaExperimentos e resultados
Objetivo◦ 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
Teste de segurança
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
Roteiro
Resultados
Resultados
Conclusão e trabalhos futuros
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
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
Conclusões
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
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
Trabalhos futuros