Bancos de Dados Móveis

Transcrição

1 Bancos de Dados Móveis I. Introdução O paradigma de computação móvel tem afetado conceitos, modelos e premissas tradicionais em várias áreas da ciência da computação. Na área de redes, é preciso que os dispositivos estejam conectados à rede independente de sua localização, o que é conhecido como computação ubíqua. Na área de engenharia, o novo paradigma introduziu a noção de código móvel, que significa a capacidade do código de migrar entre unidades da rede. Em relação à base de dados não é diferente. A computação móvel introduziu o conceito e a necessidade de os clientes móveis acessarem seus bancos de dados de qualquer lugar. Como veremos, muitas características da computação móvel influenciam as premissas utilizadas nessa área. Conforme foi visto no curso, a computação móvel se resume a diversos componentes, possivelmente heterogêneos, ligados a uma rede sem fio. Essa, por sua vez, está conectada a uma rede fixa, através de estações de base, componentes da rede fixa que possuem antenas de comunicação com a rede sem fio. Todas as unidades conectadas à rede fixa são unidades fixas. Adicione a esse cenário um ou mais bancos de dados implantados em unidades da rede. Bancos de dados móveis se resumem a uma ou mais base de dados acessada por unidades móveis. Cada base de dados está sitiada em uma outra unidade da rede, seja ela fixa ou móvel. Podemos ver a computação móvel como uma variação da computação distribuída. Os bancos de dados móveis são distribuídos sob dois aspectos: Todo banco de dados é distribuído, principalmente, entre os componentes sob a rede com fio, possivelmente com replicação parcial ou total. Assim, uma estação de base gerencia seu próprio banco de dados com as funcionalidades inerentes aos Sistemas de Gerenciamento de Banco de Dados (SGBDs), com funcionalidades adicionais para localizar unidades móveis e características adicionais de gerência de consultas e transações, para atender aos requisitos de ambientes móveis; O banco de dados é distribuído entre os componentes sob a rede com fio e com os componentes sob a rede sem fio. A responsabilidade sobre a gerência de dados é compartilhada entre estações de base e unidades móveis. Observe a classificação para os SGBDs Distribuídos baseada nas características do sistema quanto à autonomia, distribuição e heterogeneidade (Figura 1). A figura apresenta uma extensão para essa classificação segundo os SGBDs Móveis, os quais acrescentam um ponto no eixo de distribuição, caracterizando os sistemas de computação móveis. A lógica para essa extensão está no fato de que os sistemas de computação móveis devem ter uma parte em rede fixa, que é um sistema distribuído. página 1

2 Figura 1 Classificação de Bancos de Dados Distribuídos e Móveis As questões relativas à gerência de bancos de dados distribuídos podem ser aplicadas aos bancos de dados móveis desde que alguns aspectos sejam analisados de forma especial: Velocidade dos links sem fio: pode ocasionar demora nas consultas; Escalabilidade: crescimento dos bancos de dados tem impacto nas consultas e limita a quantidade de dados nos bancos de dados residentes em clientes móveis; Mobilidade: pode causar desconexão e cancelamento de transações; Localização das unidades móveis: implica na necessidade de administrar a localização das unidades móveis para interação durante as consultas; Limite do poder das baterias: exigem trabalho em modo desconectado da rede e podem causar desconexões e cancelamento de transações; Desconexões (voluntárias ou involuntárias): causam o cancelamento de transações aumentando a necessidade de novos modelos de recuperação do banco de dados. Replicação / Caching: limitadas pelo pouco poder de memória das unidades móveis; Handoff: aumenta a necessidade de controle e administração da localização das unidades móveis. As principais conseqüências que isso traz para os bancos de dados móveis são: As aplicações podem ser dependentes da localização da unidade móvel; As transações podem ser interrompidas pela divisão (particionamento) freqüente da rede; O sistema tem que estar preparado para se recuperar e não falhar em casos de: desligamento página 2

3 voluntário da unidade móvel; inúmeros acessos (logins) ao sistema, causados por desconexões; e situações de handoff. São necessárias novas técnicas de replicação para atualização da memória cache dos dispositivos móveis. As consultas podem ter resultados dependentes da localização do dispositivo e os fatores de custo são diferentes daqueles em ambiente fixo. Como podemos ver, a área de bancos de dados móveis é bem complexa e extensa, e envolve inúmeros aspectos. Vejamos, a seguir, cada um deles. II.Arquiteturas A.Cliente Servidor UM Cliente APP Comunicação Sem fio ou Híbrida SGDB Unidade Servidora BD Figura 2 Arquitetura Cliente Servidor A arquitetura cliente servidor supõe uma estrutura básica que consiste de inúmeros microcomputadores (PCs) e estações de trabalho, bem como um número menor de equipamentos de grande porte, conectados através de sistemas de redes locais e outros tipos de sistemas de rede de computadores. Um cliente, nesta estrutura, é geralmente um equipamento de um usuário que possui capacidades de interface e processamento local. Quando um cliente solicita acesso a funcionalidades adicionais, como, por exemplo, acesso a um banco de dados e este não reside neste equipamento, ele se conecta a um servidor que fornece a funcionalidade necessária. Um servidor é um equipamento que pode fornecer serviços para as estações clientes como impressão, armazenamento de dados ou acesso ao banco de dados. A idéia da arquitetura cliente servidor é dividir as funcionalidades que precisam ser fornecidas aos usuários do SGBD em duas camadas, a camada servidor e a camada cliente, ambas com funcionalidades distintas. Esta arquitetura facilita o gerenciamento da complexidade dos SGBDs atuais. A arquitetura cliente servidor está incorporada aos Sistemas de Gerência de Banco de Dados (SGBD). Os programas da interface do usuário e da aplicação podem ser executados no lado do cliente. Quando é necessário acesso ao banco de dados, o programa estabelece uma conexão com o SGBD, que está no lado do servidor, e uma vez que a conexão é estabelecida, os programas no cliente podem se comunicar com o SGBD. A camada servidor faz a maior parte do trabalho de gerenciamento de dados, enquanto que a camada cliente é responsável pela interface do usuário e pela própria aplicação, além de administrar uma memória local para solicitação e armazenamento do resultado das consultas. Diferentes tipos de arquiteturas cliente servidor podem ser implementadas. página 3

4 A arquitetura mais simples é aquela em que vários clientes acessam um único servidor, denominada múltiplos clientes servidor único. A arquitetura mais complexa é aquela em que o ambiente possui múltiplos clientes múltiplos servidores. Na computação móvel, a unidade móvel atua como um cliente requisitando serviços dos servidores localizados na rede fixa. Neste caso, os dados e as funcionalidades estão distribuídos através de vários servidores que podem comunicar se entre si para atender às solicitações dos clientes. Na maioria dos casos, os servidores se encontram na rede fixa. Um servidor pode ser replicado em diferentes unidades na rede fixa para aumentar a disponibilidade nos casos de falhas nas unidades ou na rede de comunicação. A divisão das funcionalidades entre os clientes móveis e os servidores fixos que estão sob as redes fixas não é muito clara. Em muitos casos, o papel de cada um fica confuso, como no caso durante as desconexões em que o cliente móvel necessita emular as funcionalidades de um servidor para continuar operando. Um importante componente da arquitetura cliente servidor é o tipo de mecanismo de comunicação que é utilizado para a troca de informações entre o cliente e o servidor. Uma possibilidade é a troca de mensagens direta entre o cliente e o servidor. Essa abordagem não é adequada para as redes lentas e pouco confiáveis como é o caso da computação sem fio e novos mecanismos de troca de informações estão em estudos. Extensões do tradicional modelo cliente servidor, como se enfileirar mensagens RPC (Remote Procedure Call), são necessárias para dar apoio a operações desconectadas e a fraca conectividade. Otimizações adicionais como compressão e filtros de dados também são importantes. Por estes motivos, o tradicional modelo cliente servidor deve ser estendido para prover componentes sérios que possibilitem a implementação de otimizações adequadas e, ainda assim, acarretem no mínimo possível de mudanças a serem feitas nos clientes e nos servidores. B.Cliente Agente Servidor Servidor UM Cliente Unidade Unidade Servidora APP Agente Servidor SGDB BD Figura 3 Aquitetura Cliente Agente Servidor Servidor Este modelo em três camadas realiza a comunicação entre o cliente móvel e o servidor através da troca de mensagens do cliente com o agente e deste com o servidor. Genericamente, podemos dizer que o agente assume o papel de substituto do cliente móvel na rede fixa. Esta arquitetura alivia um pouco o impacto da limitação da largura de banda e da pouca segurança do link sem fio, através da presença do cliente móvel na rede fixa via o agente. Os agentes, tipicamente, dividem a interação entre os clientes móveis e os servidores fixos em duas partes, sendo uma entre o cliente e o agente e a outra entre o agente e o servidor fixo. Assim, diferentes protocolos podem ser usados para interação em cada parte e essas partes podem executar suas funcionalidades independentemente. Este modelo é mais apropriado para clientes móveis com limitado poder de recursos e poder computacional. Assim, diversas responsabilidades dos clientes móveis migram para os agentes. Os página 4

5 agentes podem: processar os dados da consulta e enviar somente o resultado para o cliente; compactar os dados antes de enviá los; processar as buscas e enfileirar as respostas quando o cliente estiver desconectado; alterar a ordem de transmissão dos dados para os clientes, de acordo com sua prioridade. Além disso, os clientes também podem acumular as buscas para enviá las aos agentes em blocos, pois isso economiza bateria. Após enviarem as solicitações, os clientes podem entrar em modo de cochilo, para economizar bateria. A exata posição dos agentes na rede fixa depende do papel que o mesmo venha a desempenhar. Colocando o na extremidade da rede fixa, como, por exemplo, nas estações de bases, obtemos algumas vantagens quando o agente atua como substituto do cliente móvel em sua área de cobertura. Assim, fica mais fácil: reunir informações das características do link sem fio; utilizar um protocolo especial entre o cliente móvel e o agente; e personalizar informações sobre o cliente móvel que podem ser disponibilizadas localmente. Esse modelo oferece muitas vantagens. Porém, falha no suporte da operação dos clientes móveis durante o período de desconexão. Quando acontece uma desconexão, o cliente móvel não continua a operar ininterruptamente. Finalmente, o agente somente consegue otimizar a transmissão de dados do agente para o cliente móvel, mas não no caminho inverso. C.Cliente Agente Cliente Servidor UM Cliente Unidade Servidora APP Agente Cliente SGDB BD Figura 4 Arquitetura Cliente Agente Cliente Servidor Este modelo apresenta uma extensão do modelo cliente servidor, também em três camadas, porém, com a inclusão do agente de software junto à unidade móvel, ou seja, no cliente móvel. Genericamente, podemos dizer que o agente assume o papel de ampliar as funcionalidades nos clientes móveis, geralmente pobres em recursos computacionais. Entre as muitas atividades específicas de uma aplicação que os agentes podem desempenhar, podemos destacar, de uma forma mais genérica, as seguintes atividades: administrar a memória cache no cliente móvel; disponibilizar memória progressivamente para o cliente móvel durante o pouco tráfego da rede (prefetching); copiar parte do banco de dados para a memória do cliente móvel (hoarding); otimizar a comunicação entre o cliente móvel e sua estação de base. página 5

6 Naturalmente, para que o cliente tenha um agente, é preciso que ele cumpra um requisito mínimo de recursos, que nem todo dispositivo móvel possui. D.Cliente Agente Cliente Agente Servidor Servidor UM Cliente Unidade Unidade Servidora APP Agente Cliente Agente Servidor SGDB BD Figura 5 Arquitetura Cliente Agente Cliente Agente Servidor Servidor Para sanar as deficiências dos dois modelos anteriores, nos quais os agentes de software residem e executam em apenas um dos lados da arquitetura, foi proposto este modelo, também chamado de Client/Intercept/Server. Nessa arquitetura, o agente situado no cliente móvel executará em conjunto com o agente situado no servidor. Dessa forma, unimos as vantagens dos modelos anteriores. Além disso, os dois agentes otimizam a comunicação através da redução da quantidade de dados transmitidos na rede sem fio, melhoram a segurança na transferência dos dados e sustentam a não interrupção da computação móvel, entre outras possíveis atividades. O ponto fraco deste modelo é que cada aplicação necessita de trabalho de desenvolvimento tanto no servidor quanto no cliente. Porém, não é necessário o desenvolvimento do par de agentes para cada nova aplicação. Construindo se as funcionalidades e otimizações suficientemente genéricas, somente será necessário o desenvolvimento de pares de agentes diferentes para aplicações de cada tipo. Por exemplo, um agente para aplicações do tipo web. E.AMDB A arquitetura AMDB visa à interoperabilidade entre sistemas de bancos de dados móveis. Esse modelo é baseado no conceito de agentes. Os agentes são divididos em duas classes: estáticos e móveis. Os primeiros são responsáveis pela criação do contexto de execução para os agentes móveis, gerenciamento de recursos locais de um computador móvel e identificação de serviços disponibilizados no ambiente móvel. Os agentes móveis, por sua vez, são responsáveis por transportar o código de acesso a bancos de dados e os resultados destes acessos. Temos dois tipos de agentes estáticos. O Administrador e o Mantenedor. Aquele é responsável pelo gerenciamento de recursos do dispositivo, identificação e disponibilização de serviços, transferência de serviços e por efetuar a conexão e desconexão do sistema de comunicação. O Mantenedor é responsável pelo mapeamento dos dados locais em um formato de representação comum (XML) e pela comunicação com o sistema de banco de dados. Ou seja, é ele quem deve executar o código de acesso ao banco de dados, que é transportado por um agente móvel. Na classe de agentes móveis, encontramos o Executor e o Carregador. O Executor é responsável por migrar entre os componentes móveis levando consigo o código de acesso aos bancos visitados. O agente Carregador é criado pelo Executor sempre que é preciso enviar um resultado para o cliente página 6

7 que originou o acesso ao banco de dados. F.GSN e Múltiplos Agentes Essa arquitetura é baseada no modelo Client/Interceptor/Server, que foi apresentado no item D. A diferença é a adição de um elemento intermediário situado na rede fixa. Esse elemento, denominado Gateway Support Node (GSN), se responsabiliza por intermediar a comunicação das unidades móveis sob sua cobertura com as outras unidades da rede (sejam elas fixas ou móveis). O objetivo do GSN é livrar as unidades móveis de diversas tarefas e otimizar o uso dos seus recursos, que são, como já vimos, limitados. O GSN é um componente ciente dos problemas inerentes a uma rede móvel e preocupado em tratá los. O par formado por unidade móvel e GSN permite que a unidade móvel se comporte como uma unidade fixa perante as outras unidades da rede. O GSN empresta a sua identidade para as unidades móveis que ele monitora, de modo que quando ele recebe uma mensagem, ele a reenvia para a unidade móvel apropriada. Figura 6 Arquietura Multi Agentes (Mordomos Alfredo) e GSN Quando se trata de arquiteturas com múltiplos agentes, a idéia mais comum é criar um agente para cada tarefa a ser realizada, dar ao agente os dados necessários para acessar alguma fonte de informação, e enviá lo para a rede móvel. Quando o agente obtém o resultado, ele retorna ao computador móvel com a resposta.na figura 2 temos uma proposta de arquitetura que apresenta algumas vantagens em relação a essa arquitetura mais comumente encontrada. Aqui, utilizamos um agente denominado mordomo Alfredo para evitar as transferências contínuas de agentes através da rede se fio. Cada unidade móvel possui um mordomo Alfredo, que é um mordomo eficiente que tem como objetivo prover os serviços adequados para o seu dono. Do ponto de vista de implementação, Alfredo é a união de dois agentes SAlfredo (Alfredo estático) e MAlfredo (Alfredo página 7

8 Móvel). Enquanto SAlfredo se situa no componente móvel, o MAlfredo se situa no GSN. O agente MAlfredo é criado no computador móvel e viaja pela rede até o elemento intermediário, o GSN, onde ele trabalha em prol do usuário móvel, representando o na rede, se tornando o ponto comum de toda comunicação na qual a unidade móvel está envolvida, mesmo quando ela está desconectada da rede. Quando é preciso executar uma tarefa, SAlfredo envia uma mensagem para MAlfredo com as informações necessárias. Então, MAlfredo executa a tarefa, ou cria um agente, um especialista (os agentes especialistas ficam localizados no GSN), para que ele execute a tarefa. Após a execução da tarefa, MAlfredo envia os resultados para SAlfredo. III.Heterogeneidade Um dos problemas que dificultam a implementação de bancos de dados móveis é o problema da heterogeneidade. Integrar informações armazenadas em vários bancos de dados distribuídos, heterogêneos e autônomos não é uma tarefa simples. Para que tais bancos de dados (BDLs ou bancos de dados locais) se tornem interoperáveis, diversas arquiteturas de integração têm sido propostas. Uma das principais propostas é a arquitetura de sistemas de bancos de dados federados. Nesse caso, a integração entre BDLs é realizada através de um esquema federado, que representa uma visão integrada dos diversos esquemas locais. A grande desvantagem desta proposta é exatamente a especificação e manutenção do esquema federado. Em um caso em que muitos bancos de dados estão envolvidos, obter um esquema integrando todos os bancos de dados seria uma tarefa sobrehumana, pois implicaria em se conhecer todos os esquemas locais, resolver os conflitos entre os BDLs (sejam estruturais ou semânticos) e depois especificar os esquemas federados. Haveria ainda o problema da evolução do esquema federado, pois os esquemas locais podem estar em constante evolução. E, vale lembrar que, evolução e dinamicidade são uma das principais características da computação móvel, inclusive quando se trata de redes ad hoc. Uma outra abordagem bastante difundida para integrar múltiplas fontes de dados é a arquitetura de mediadores. Um mediador representa dados relacionais e legados como objetos. Contudo, essa proposta sofre dos mesmos problemas que a arquitetura de bancos de dados federados, pois a integração é realizada através de uma visão de integração. Tal visão nada mais é que um esquema federado. Uma proposta que provê maior autonomia à integração é o sistema de bancos de dados múltiplos (Multidatabase System MDBS). Um MDBS integra vários sistemas de bancos de dados heterogêneos e autônomos. Ele inclui um componente de software que é composto de uma coleção de funções globais. Para que essas funções sejam implementadas, é preciso especificar e desenvolver módulos globais de software e de estruturas de dados globais. Processamento de consultas, controle de concorrência global, mecanismo de recuperação global, transformação entre a forma de representação de dados locais e representação de dados globais são exemplos de módulos globais de software. A integração de diferentes fontes de dados é realizada pela linguagem de bancos de dados múltiplos (Multidatabase Language MDL). A MDL é uma ferramenta através da qual um usuário global pode definir e manipular múltiplos bancos de dados locais. Portanto, a tecnologia de bancos de dados múltiplos integra dados de múltiplas fontes de dados sem requerer a existência de um ou mais esquemas globais (federados). É exatamente essa propriedade que torna esta tecnologia atrativa para integrar bancos de dados em ambientes com suporte à computação móvel. página 8

9 IV.Envio de Dados A.Disseminação de Dados Disseminação de dados é a entrega de dados a partir de um conjunto de produtores para um grande número de clientes. Isso é caracterizado por uma assimetria nas comunicações: a banda passante para download deve ser maior do que a de upload. Esse modelo se encaixa com a característica de computação móvel: um dispositivo móvel recebe dados a uma velocidade maior do que envia. Além disso, é muito mais caro para um dispositivo enviar dados do que receber. O modelo em que dados são enviados para o cliente sem esperar por requisições específicas é chamado push based. Enviar dados para os clientes evita interrupções causadas por requisições e permite a propagação de dados que poderiam, caso contrário, ser ignorados pelos clientes. Por outro lado, sistemas push based têm o problema de decidir qual a relevância dos dados a serem enviados para os clientes. A utilidade do sistema depende da sua habilidade em prever as necessidades dos clientes. Uma solução simples seria permitir que os clientes se inscrevessem para receber serviços e provessem perfis do seu interesse. Os clientes podem inscrever buscas específicas no servidor para receber os resultados das buscas freqüentemente. Isso é chamado de buscas contínuas ou continous queries. Além disso, cabe ao servidor decidir se os dados serão enviados periodicamente ou não. O envio periódico apresenta a vantagem de que, se um cliente se desconectar da rede, ele não perderá itens, pois os dados serão reenviados novamente. Por outro lado, o envio não periódico é uma forma mais efetiva de utilizar a banda passante. A arquitetura Broadcast Disks faz uso de envios de dados não periódicos. Essa arquitetura inova nos seguintes pontos: uso de um mecanismo multi nível, que permite que dados sejam enviados de forma não uniforme. Assim, a banda passante é alocada para os itens de acordo com a sua importância; mecanismos para gerenciar o armazenamento nos clientes com suporte a caching e prefetching, para tornar o broadcast multi nível mais eficiente. Com o uso de Broadcast Disks, podemos construir uma hierarquia entre os dados de modo que o nível mais alto contém poucos itens que devem ser transmitidos com alta freqüência, enquanto que os níveis subseqüentes contêm cada vez mais itens para serem transmitidos com freqüências cada vez menores. Nenhum algoritmo de escolha dos dados a serem enviados e com qual freqüência resolve todos os casos. Por isso mesmo, existe a necessidade do uso de cache e prefetching do lado do cliente. Naturalmente, também existe a possibilidade de termos um sistema pull based. Nesse caso, o cliente faz a requisição dos dados de que necessita para o servidor. Um sistema puramente pull based é aconselhável apenas quando existe pouca contenção no servidor e quando os próprios dispositivos não precisam de um volume muito grande de dados. Por outro lado, um sistema puramente push based é adequado somente quando o servidor está muito sobrecarregado com requisições de clientes. O ideal é um sistema que envia dados com broadcast, e que também recebe requisições, ou seja, um sistema que seja intermediário entre esses dois modelos de disseminação de dados. Essa solução híbrida se chama Interleaved Push and Pull (IPP). Para que ocorra o envio e o recebimento de dados entre os clientes e servidores é preciso a página 9

10 existência de dois canais. O backchannel é utilizado para clientes fazerem requisições específicas de dados para o servidor. O frontchannel é utilizado para envio de broadcasts do servidor e de resposta a requisições de clientes. Desse modo, é possível decidir quais dados valem a pena transmitir em broadcast. Todos os dados que não são enviados para os clientes no broadcast podem ser requisitados por clientes. Infelizmente, o IPP sofre dos mesmos problemas de gargalo na rede que sofrem as abordagens pull based. Para tornar essa solução mais escalável, é possível: Ajustar a banda passante do backchannel, sob o custo de diminuir a banda do frontchannel. Isso introduz um trade off entre quão rápido a fila de requisições dos clientes é processada e quão rápida a entrega de dados broadcast é executada. Fazer com que os clientes requisitem somente as suas perdas mais caras, ou seja, dados que seriam enviados em um futuro distante. O efeito dessa técnica é atrasar o ponto no qual a fila de requisições pelo servidor fica saturada. Dividir a parte mais lenta do agendamento de broadcast em partes sucessivamente maiores. O efeito é o aumento da banda disponível para requisições dos clientes. Se ainda assim não existir banda passante o suficiente para as requisições, a performance pode degradar consideravelmente uma vez que clientes não serão capazes de requisitar os itens que não foram enviados em broadcast. Uma outra forma de efetuar a disseminação de dados eficientemente é o servidor enviar mensagens de invalidação para os clientes. Através de Invalidation Reports (IRs), o servidor pode notificar os clientes sobre mudanças nos dados que eles armazenam no cache. Os IRs são formas sucintas de transmitir informação. Eles podem ser implementados de inúmeras formas diferentes. Por exemplo, uma lista de identificadores dos itens que foram alterados desde a última notificação pode ser enviada em um IR. Além disso, a granularidade dos dados abrangidos em cada item a ser invalidado na notificação do IR também é importante. Em muitos casos, pode ser custoso enviar invalidações a uma granularidade fina, ou seja, item por item. A granularidade é um fator essencial que deve ser analisado no momento de se implementar um IR. Dependendo do modo como é utilizado, o IR pode fazer com que um cliente apague dados no seu cache que ainda são válidos. Existe também a possibilidade de não impor tanto rigor quando à consistência dos caches. Em se tratando de uma aplicação que envolva preços de um estoque, por exemplo, pode ser aceitável que os valores não estejam completamente atualizados com o banco de dados servidor, desde que a diferença entre o valor do cache e o preço real seja de 0,5%. Isso pode ser obtido se considerarmos os dados do cache como quase cópias dos valores do servidor. Uma quase cópia é um valor armazenado em cache que pode desviar um pouco do valor real do servidor de forma controlada. O uso de quasecópias torna as IRs mais curtas, e otimiza o uso da banda de comunicação. B.Hoarding Um dos problemas envolvidos em implantar bancos de dados móveis é a desconexão freqüente do dispositivo da rede. Para que a aplicação continue funcionando, é preciso que o dispositivo possua os dados que irá utilizar em cache. Para resolver esse problema, existe a técnica de hoarding. Quando o dispositivo nota uma desconexão inesperada antecipadamente, os itens de dados são transferidos para o cliente móvel, para possibilitar a sua operação durante o período da desconexão. Essa carga antecipada de dados é o que chamamos de hoarding. página 10

11 REINTEGRAÇÃO CARGA ANTECIPADA DE DADOS (HOARDING) OPERAÇÕES DESCONECTADAS Conforme podemos observar na figura ao lado, a desconexão é dividida em três etapas: carga antecipada de dados (hoarding); operações desconectadas; e reintegração. Durante a etapa de hoarding, os itens necessários para operação são carregados na unidade móvel. Os itens podem ser simplesmente realocados Figura 7 Processo de Desconexão com Hoarding ou movimentados da unidade fixa para a unidade móvel. Porém, eles se tornarão inacessíveis para as outras unidades. Uma alternativa é replicar os dados ou mantê los no cache da unidade móvel. O tipo de dados transferidos para a unidade móvel depende da aplicação e do modelo de dados que o sustenta. Veja os exemplos: Em sistemas de arquivos os dados podem ser arquivos, diretórios ou volumes de disco. No caso de SGBDs, os dados podem ser relações ou visões. Para sistemas de browsing na web, os dados podem ser páginas. Em se tratando do modelo de objetos, os objetos de dados podem carregar com eles informações adicionais, tais como o conjunto de operações permitidas. No modelo baseado em agentes móveis, os agentes podem ser transmitidos ao longo da rede para serem executados no cliente móvel. Para desconexões previsíveis, como por exemplo, a motivada pela entrada do cliente em uma região fora da sua área original de cobertura, e, portanto, financeiramente mais cara, os dados podem ser carregados imediatamente antes da desconexão. Quando a unidade se desconecta, ela entra no estado de operações desconectadas. Nesse ponto, todas as requisições da aplicação a dados que não estão armazenados no dispositivo móvel serão recusadas ou enfileiradas para execução após a reconexão do dispositivo. Para evitar ou minimizar esse problema, é importante que o processo de hoarding saiba escolher quais os dados que o dispositivo tem que armazenar. Quando acontece uma nova conexão com a rede fixa, a unidade móvel entra no estado de reintegração. Neste estado, as atualizações da unidade móvel são reintegradas com as atualizações de outros sites, re executando o seu log na unidade fixa. Questões referentes à concorrência e seriação das transações são efetivadas em função de cada sistema em particular, visando resolver o problema da atualização sobre o mesmo objeto. Dois exemplos de aplicação de hoarding são: Coda: como foi visto em aula, o Coda é um sistema de arquivos distribuídos, desenvolvido no Departamento de Ciência da Computação da Carnegie Mellon University, EUA, desde Em cada cliente do Coda, existe um gerenciador de cache chamado Venus, que obtém página 11

12 dinamicamente os dados e os põe na memória cache. Para dar suporte à operação desconectada, o Venus trabalha em três estágios: estado de hoarding, emulação e reintegração. O hoarding do Venus é baseado em prioridade. Ele combina informações implícitas e explícitas para avaliar quais dados devem estar no cache. Implicitamente, um algoritmo tradicional de gerenciamento de cache (no caso, o LRU) é utilizado para avaliar o histórico de arquivos recentemente usados. Explicitamente, é utilizado um banco de dados de hoard, o HDB, cujo conteúdo são os caminhos dos arquivos que o usuário tem interesse que o Venus mantenha na cache. Para manipular o HDB, o Venus usa um programa chamado hoard profile que atualiza diretamente ou via scripts. O Venus periodicamente avalia a retenção de objetos do cache em um processo chamado hoard walking. O hoard walking é necessário para que seja atingida a expectativa do usuário em relação à importância da permanência de seus objetos no cache, isto é, se aqueles dados que o usuário espera que estejam na cache de fato se encontrem lá. Quando o cache atinge esta expectativa, é dito que ele está em equilíbrio. Seer: o Seer é um sistema de predição de hoarding, onde a escolha dos dados que devem estar presentes no cache é feita de forma automática e transparente ao usuário. O Seer não executa a replicação e transferência de arquivos entre servidores e clientes. Em vez disso, ele roda sobre sistemas de arquivos que têm esta funcionalidade (como o Coda, por exemplo). A escolha de quais arquivos devem ser mantidos no cache é baseada na observação do comportamento do usuário através dos arquivos utilizados e no uso inferências quanto à relação entre estes arquivos. O Seer é composto de dois módulos: o Observer ou Observador, que acompanha o comportamento do usuário e seus acessos a arquivos, classificando cada acesso de acordo com um tipo, convertendo caminhos dos arquivos em um formato absoluto, e assim alimentando o módulo Correlator. O Correlator avalia as referências dos arquivos, calculando a distância semântica entre eles. Esta distância semântica alimenta um algoritmo de clustering, que atribui cada arquivo a um ou mais projetos. Esta distância semântica é a métrica utilizada para a definição da relação entre arquivos. Assim, grupos de arquivos necessários para se trabalhar em um determinado projeto são identificados. Desta forma, o Seer prediz os projetos que o usuário está trabalhando e carrega seus arquivos localmente no cliente móvel. V.Transações A.Transações Móveis O ambiente de computação móvel, como já foi visto, influencia muito o modo como são implementados os bancos de dados. Entre as características de tal ambiente está o fato de ele ser multi usuário. Bancos de dados móveis são implantados em um ambiente no qual vários clientes podem querer acessar diversas bases. Essas podem ser locais ou remotas. A concorrência entre aplicações locais e remotas é implementada através do entrelaçamento temporal de operações de um conjunto de aplicações distintas. Isso tudo leva a um problema. Execuções entrelaçadas de transações podem produzir inconsistências. Além desses fatores, temos as freqüentes desconexões e a intermitência na comunicação, que podem interromper a execução de uma transação a qualquer momento. Desse modo, existe uma grande necessidade de soluções de transações específicas para o ambiente de bancos de dados móveis. E uma das primeiras premissas que o ambiente de computação ameaça em relação a transações é a página 12

13 atomicidade. Uma transação é comumente estruturada como atômica com o objetivo de preservar a consistência dos dados na presença de concorrência e falhas no sistema. Entretanto, uma computação móvel que acessa dados compartilhados não pode ser estruturada usando uma transação atômica. Isto se dá porque transações atômicas assumem o pressuposto de executarem isoladas, o que impede as mesmas de dividirem a sua computação e de compartilharem seus estados e resultados parciais. Já na computação móvel, considerações práticas únicas deste ambiente exigem que as computações nas unidades móveis sejam sustentadas e apoiadas por uma unidade de suporte a mobilidade (estação de base), tanto para computação como para comunicação de dados. Isto significa que a computação móvel precisa ser estruturada como um conjunto de transações, algumas das quais executam na unidade móvel, enquanto que outras executam na unidade de suporte à mobilidade. Além da necessidade da divisão de suas transações, a computação móvel também está envolvida, em primeiro lugar, com a mobilidade de suas fontes de dados e de seus consumidores e, em segundo lugar, por sua natureza interativa, como, por exemplo, pausas para entrada de dados por seus usuários. Assim, uma outra exigência que as transações atômicas não podem satisfazer é a sua habilidade de lidar com falhas parciais e prover diferentes estratégias de recuperação, desta forma minimizando os efeitos das falhas. Uma transação móvel é uma transação distribuída, onde alguma parte da computação é executada na unidade móvel e outra parte em uma unidade fixa. O uso do meio sem fio e a mobilidade resultante dos consumidores e produtores de dados afetam o processamento das transações de várias formas. O emprego de conexões sem fio resulta em transações longas, em função dos longos atrasos da rede. A mobilidade resulta em transações que acessam sistemas de informações heterogêneas. Além disso, enquanto em projetos estáticos a localização dos usuários é fixa, no ambiente móvel mudam constantemente. Conseqüentemente, as transações móveis acessam dados de localização dos clientes que mudam rapidamente, em muitos casos em posições imprecisas. Finalmente, as transações podem envolver dados que estão dinamicamente sendo mudados de lugar. B.Consistência de Dados Garantias de consistência para dados processados por clientes móveis é um campo de pesquisa importante. Essas garantias provêem a base para qualquer trabalho colaborativo e processamento de transação feito com os sistemas envolvidos. É preciso um mecanismo que forneça às aplicações uma visão da base de dados consistente com as suas ações. Isso é importante, pois clientes podem ler e escrever dados de qualquer servidor disponível e esses servidores podem conter visões inconsistentes da base de dados. Por exemplo, um cliente poderia fazer uma escrita em um servidor e depois ler o dado que ele alterou de outro servidor. Isso resultaria em uma leitura inconsistente, caso os dois servidores não tivessem se sincronizado entre as duas operações. Desse modo, é necessário que tenhamos garantias de sessão para resolver o problema. Essas garantias são: Leia as suas escritas: qualquer operação de leitura na sessão deve refletir os valores estabelecidos pelas escritas anteriores feitas naquela sessão; Leituras monotônicas: leituras sucessivas refletem um número não decrescente de escritas. Propagação de escritas: escritas são propagadas depois das leituras das quais elas dependem. Escritas monotônicas: escritas são propagadas depois das escritas que as precederam logicamente. página 13

14 Essas restrições são garantidas por um gerenciador de sessões que ordena as leituras e escritas em série de fornece identificadores únicos a cada escrita. O servidor deve retornar informação sobre o identificador de escrita único e conjunto de identificadores de escritas que são relevantes para uma dada leitura. O gerenciador mantém um conjunto dos identificadores das escritas relevantes para as leituras de dados da sessão e um conjunto dos identificadores das escritas efetuadas durante a sessão. Essas garantias de sessão foram desenvolvidas para serem aplicadas no protótipo do projeto Bayou, que tem como objetivo prover uma framework de colaboração entre usuários de computação móvel. Outra forma de garantir a consistência de dados durante as transações dos clientes móveis é a técnica do método escrow. Esse método consiste em dividir as instâncias dos itens do banco de dados entre os clientes móveis. Uma transação pode suceder facilmente se o número de instâncias que ela requer não ultrapassar o número de instâncias que a unidade móvel possui. Através de um protocolo de reconfiguração, a unidade pode requisitar instâncias das outras unidades, nesse caso, para aumentar o número de instâncias que ela tem disponível. Uma das vantagens desse método é que ele é compatível com o handoff. Se, durante uma transação, a unidade trocar de estação base e de servidor de banco de dados, ela só precisa informar ao novo servidor qual o próximo passo a ser realizado na transação. Isso funciona porque o servidor antigo tomou as suas decisões baseado nos elementos que estavam de posse da unidade móvel. O único passo necessário ao trocar de servidor é que, após a transação, o protocolo two phase commit deve ser utilizado para a sincronização dos dois servidores. As técnicas de escrow podem ser generalizadas se explorarmos a semântica dos objetos, a fim de facilitar operações autônomas e desconectadas em aplicações de bancos de dados móveis. A idéia é dividir objetos extensos e complexos em pequenos fragmentos e armazenar um conjunto desses fragmentos no cache de uma unidade móvel. Ao transformar os fragmentos em unidades de consistência e definir restrições de consistência sobre o uso dos fragmentos, é possível a execução de operações concorrentes sobre o mesmo objeto. Utilizando um protocolo de demarcação, podemos garantir que as execuções locais são seriáveis. O protocolo faz isso explorando a organização do objeto e das suas restrições. Quando um cliente móvel requisita acesso a um objeto, ele envia ao servidor uma requisição com um pedido de split, que seleciona parte do objeto e estabelece algumas condições de consistência. A partir desse instante, a parte do objeto selecionada está disponível apenas para transações realizadas na unidade móvel que fez a requisição. O restante do objeto continua disponível para os outros clientes. Um exemplo de objetos que podem ser fragmentados dessa forma são itens agregados (como, por exemplo, assentos de avião), conjuntos e pilhas. Por exemplo, conjuntos podem ser divididos em subconjuntos e esses, por sua vez, podem ser combinados em uma ordem arbitrária para a reobtenção do conjunto original. Cada unidade móvel pode especificar um intervalo de elementos como critério de seleção, com os intervalos sendo disjuntos. Uma outra técnica utilizada para manter a consistência é um algoritmo de replicação que permite que aplicações móveis proponham tentativas de transações no cliente móvel. Essas tentativas são realizadas sobre as réplicas gravadas nos clientes enquanto estão desconectados. Quando a unidade reconecta na rede, a tentativa de transação é proposta para a unidade fixa que contém a cópia mestra dos dados. Essa tentativa pode suceder, ou falhar (caso ocorra conflito com outras transações). No segundo caso, a unidade cliente é informada da falha e por que ela ocorreu. Essa técnica pode causar falhas freqüentes na aplicação cliente. Além disso, a tentativa de transação página 14

15 executada no servidor pode obter resultados diferentes dos obtidos na aplicação móvel, e nem sempre isso é aceitável. Uma melhoria para essa solução é a técnica de Certification Reports. O canal de broadcast é utilizado pelo servidor para auxiliar os clientes móveis a prever se as transações que eles estão executando pode ser abortada. Isso é feito através do recebimento de Certification Reports, que contêm uma lista dos itens que estão no conjunto de operações de leitura e escrita de transações ativas que declararam ao servidor a sua intenção em comitar. O cliente verifica se as leituras e escritas que ele executou na sua transação conflitam com as leituras e escritas das outras transações. Caso afirmativo, o próprio cliente aborta a sua transação. Caso contrário, ele continua a executar a sua transação. Quando está no momento de efetuar a transação, ele envia para o servidor o conjunto de operações de escrita e leituras envolvidas na transação, declarando o seu interesse em comitar. O servidor faz uma última verificação de possíveis conflitos. Na ausência deles, o servidor comita a transação, e envia no próximo broadcast o conjunto de escritas e leituras feitas na transação comitada para que as outras unidades móveis tomem conhecimento dessas operações. No mesmo broadcast, o servidor também envia o comunicado notificando, das transações que enviaram requisição para comitarem, quais delas foram abortadas e quais foram comitadas. Uma das vantagens dessa solução é que os clientes móveis ficam responsáveis por parte da validação das suas transações. Além disso, transações que seriam abortadas só quando fossem enviadas para o servidor são abortadas mais cedo. Finalmente, tem o modelo de Isolation Only Transactions (IOT). Nesse modelo, temos garantias fortes de consistência, embora outras propriedades tradicionais não sejam garantidas, tais como atomicidade e durabilidade. O modelo de execução utiliza controle de concorrência otimista. Do mesmo modo que nas soluções anteriores, a transação é executada no cliente e nenhuma execução parcial é visível no servidor. Quando a transação completa, ela entra em estado de comitada ou pendente. Se não há dados partilhados com outros clientes envolvidos na transação, ela é comitada e o seu resultado é comunicado para os servidores. Caso contrário, e transação fica pendente e aguarda pela sua validação. Se a validação suceder, os seus resultados são comitados e reintegrados nos servidores. Caso contrário, a transação terá que ser resolvida, manualmente ou automaticamente. Para isso, podemos utilizar o modelo de transação otimista de Davidson. Esse método constrói um grafo de precedências para representar interdependências entre transações e detectar ciclos no grafo que indiquem que a transação não satistaz a seriação global. VI.Localização O fato de que os clientes podem mudar a sua localização possibilita responder às buscas feitas por clientes de acordo com a sua localização. Realizar buscas relacionadas à localização de um ou mais objetos pode ser custoso. Por exemplo, encontrar X, Y e Z de modo que eles estejam no mesmo endereço e Y está entre X e Z. Para responder essa busca, o custo de comunicação para obtenção dos dados necessários é muito alto. O problema principal relacionado à localização se torna como minimizar o custo da comunicação necessária para responder a busca. Estratégias ingênuas resultam em muitas mensagens e altas latências. Por outros lados, construir planos otimizados para responder a esse tipo de busca é um problema NP completo. Uma alternativa é o uso de heurísticas gulosas baseadas no algoritmo ID3 para resolver esse problema. página 15

16 Quanto à necessidade de fornecer aplicações para os usuários dependentes da sua localização, apresentamos duas abordagens interessantes. Alguns protocolos integram o Global Positioning System (GPS) ao IP, para permitir a criação de serviços dependentes da localização. Alguns exemplos desses serviços são: enviar mensagens para dispositivos que se encontram em uma determinada região, prover serviços para clientes que se encontram em uma área geográfica e prover informações aos usuários dependentes da sua localização. É possível também estender o WWW, permitindo que documentos refiram e reajam à localização do usuário. Isso pode ser feito através de dois conceitos: Dynamic Uniform Resource Locators (DURLs) e Active Documents ou documentos ativos. Uma URL é dinâmica se ela contém no mínimo uma variável dinâmica que é substituída pela localização. Por exemplo, um usuário obtém um hyperlink para um documento que descreve a sua localização atual em um prédio através de uma URL dinâmica na página correspondente que contém o link. Quando o usuário seleciona uma URL dinâmica em um documento, o seu browser é responsável por resolver todas as referências para variáveis de ambiente dinâmicas dentro da URL. Feito isso, o browser utiliza uma URL padrão que pode ser enviada para o servidor para obter a página correspondente. Documentos ativos são documentos HyperText Markup Language (HTML) que permitem que o cliente reaja automaticamente a mudanças no contexto do dispositivo móvel. Autores escrevem documentos ativos do mesmo modo que escrevem HTML padrão, com a diferença de que escrevem também um comando subscribe que lista automaticamente as variáveis de ambiente dinâmicas às quais o cliente precisa se inscrever quando ele carregar o documento. Quando as variáveis envolvidas têm o seu valor alterado, cabe ao cliente recarregar a página. VII.Interface com o Usuário O tamanho das telas de dispositivos móveis levou pesquisadores a pensarem em interfaces adequadas para obtenção de informação em telas tão pequenas. Uma interface de processamento de buscas existente é a Query by Icons (QBI), que aborda características como o tamanho da tela e memória e bateria limitadas. As características do QBI são: uma linguagem icônica visual que permite usuários comporem buscas utilizando dispositivos apontadores como uma caneta para manipular os ícones; um modelo de dados semântico que captura a maior parte dos aspectos das estruturas das bases de dados; ferramentas de metabusca que auxiliam a formular buscas durante períodos de desconexão. Isso é feito sem necessidade de acessar o servidor. Dados são acessados e transmitidos para a unidade móvel somente quando uma busca é respondida. VIII.Na Prática Existem muitos bancos de dados de diversos vendedores disponíveis para dispositivos móveis. Essa é uma área que está crescendo constantemente no mercado também. Alguns exemplos são o Sybase Ultralite, o Oracle Lite Mobile Server, o DB2 Everyplace, e o Microsoft SQL Server CE. Vejamos, agora, como é o cenário do uso de bancos de dados móveis para os desenvolvedores Java, utilizando J2ME. página 16

17 A.Dispositivos CDC CDC (Connected Device Configuration) é um componente da arquitetura J2ME para dispositivos relativamente poderosos, com 2MB de memória e processadores de 32 bits. Esse componente é suportado por uma máquina virtual Java 2. Em dispositivos como esses, é interessante ter alguma ferramenta que permita o acesso direto de bancos de dados. Bancos de dados móveis nesses dispositivos podem ser utilizados para armazenar informações pessoais do usuário, ou para implementação de cache no dispositivo. Um dos pacotes opcionais do CDC é o JDBC. Esse pacote é um subconjunto do JDBC3.0. Não são suportados: Connection Pools; A interface ParameterMetaData; Definição de parâmetros através do nome na interface CallableStatement; Tipos do SQL 99 como Struct, Array, etc; Tipo de mapeamento customizado (os métodos settypemap() e gettypemap()). O subconjunto de JDBC opcional para J2ME é suportado pela maioria dos vendedores de bancos de dados móveis. Além disso, vendedores fornecem algumas extensões não padronizadas para melhorar a performance e produtividade. Algumas das opções de bancos de dados móveis para dispositivos CDC são: HSQL (projeto livre); Anywhere Solutions SQL Anywhere Studio; IBM DB2 Everyplace; Oracle 9i Lite; PointBase Micro Edition. B.Dispositivos MIDP MIDP é a sigla de Mobile Information Device Profile e é o perfil mais importante da arquitetura J2ME. Ele tem como alvo os dispositivos menores, como telefones celulares. Por se tratar de dispositivos muito limitados, implantar um banco de dados relacional completo sobre tais dispositivos é muito caro. O MIDP padrão não suporta sequer tipos básicos do SQL tal como o float, por exemplo. Por outro lado, o RMS (Record Management System), que é a ferramenta de armazenamento de dados persistentes do MIDP, é extremamente inadequado para aplicações corporativas. As gravações realizadas pelo RMS são muito lentas, além de não serem indexadas, nem poderem ser buscadas. A estrutura linear do RMS torna a manipulação de dados relacionais um pesadelo. Para resolver esse problema, os vendedores de bancos de dados desenvolveram soluções simples para executarem em cima do RMS. Uma vez que essas bases de dados são extremamente leves, suporte total para o JDBC não é necessário. Cada vendedor provê a sua API de acesso. As opções mais conhecidas são: PointBase Micro Edition (sua API é similar ao JDBC e fornece um MIDlet que acessa a base, mas é muito pesado); Oracle J2ME SODA SDK (Simple Object Database Access, banco de dados orientado a objetos); IBM DB2e FastRecordStore (provê uma interface, FastRecordStore, sobre o RMS, e efetua sincronização com o banco de dados no servidorç é eficiente, mas apresenta uma API difícil de página 17

18 utilizar). C.Sincronização A agregação de informação é umas das funcionalidades centrais de sistemas corporativos. Bases de dados desconectadas não são muito úteis. Mas, se por um lado os dados dos dispositivos precisam ser agregados ao sistema servidor, por outro, os dispositivos precisam confiar no servidor para manterem seus dados atualizados. A melhor solução para isso é a sincronização de dados. Vendedores de bancos de dados móveis fornecem soluções de sincronização para as suas bases de dados. A arquitetura de sincronização utilizada se resume a um servidor de sincronização na rede fixa. Esse se comunica com o servidor da base de dados através de comunicação padrão, como, por exemplo, JDBC. O servidor de sincronização é responsável por se comunicar com os dispositivos móveis e tomar algumas decisões. Para a comunicação na rede sem fio, é preciso a existência de dois canais. Um para recebimento de informações e outro para envio. A troca de dados é feita através de protocolos proprietários, mas a tendência é que seja criado um padrão para que dispositivos possam se comunicar com os servidores sem utilizarem bases de dados do mesmo vendedor. O mecanismo de sincronização aplica a idéia de dispositivo desconectado porém sincronizado. Isso significa que o dispositivo se conecta de tempos em tempos com o servidor para a sincronização. Afinal, depois de tudo o que vimos em relação à computação móvel e a bancos de dados móveis, sabemos que não é possível que o dispositivo se conecte a cada consulta, e a cada alteração. Sob esse ponto de vista, a base de dados que se encontra no dispositivo móvel faz o papel de cache. D.Acesso Direto Apesar de sincronizar bases de dados ser uma boa idéia, nem sempre é a solução adequada. Algumas aplicações exigem que a base de dados do dispositivo móvel esteja sempre atualizada, como, por exemplo, aplicações de tempo real. Nesse caso seria preciso que a sincronização fosse freqüente para manter a base de dados sempre atualizada. Porém, já vimos que não é possível fazer a sincronização a intervalos curtos de tempo. Em outras aplicações, é preciso acessar uma base de dados legada, que só está disponibilizada remotamente. Além de tudo isso, nem sempre é viável manter os dados necessários na base de dados do dispositivo móvel. Nesse caso, a solução é fazer acesso direto ao banco de dados servidor. Em dispositivos CDC, como já vimos, podemos utilizar JDBC, o que permite o acesso ao banco de dados servidor. Mas, infelizmente, isso não se aplica para dispositivos MIDP. Nesse caso, é necessário expor serviços SQL através de um gateway HTTP. Uma das formas de fazer isso é utilizando a biblioteca Oracle J2ME SQL SDK. Ela disponibiliza uma API que acessa um gateway servlet que, por sua vez, acessa o banco de dados servidor. Em se tratando de bancos de dados legados, isso pode não ser suficiente. Esses sistemas legados utilizam protocolos proprietários e APIs de baixo nível. Seria necessário desenvolver uma camada intermediária para permitir o acesso de clientes através de JDBC. Isso exige tempo e recursos. Uma boa alternativa para fornecer acesso a sistemas legados e que não exige tantos esforços é a técnica de screen scrapping. Ela é baseada no uso de um agente gravador (o screen scrapper ), que grava cada tecla pressionada e todas as mensagens impressas em um terminal durante um período. Quando o gravador estiver ligado, o usuário do mainframe realiza uma determinada tarefa durante a página 18

19 sessão interativa. Feito isso, o gravador gera código Java para replicar o processo. Uma ferramenta que provê acesso a mainframes é a Simplicity IDE da Data Representations. IX.Bibliografia WCSF2002 Minicurso 1 Acesso a Bancos de Dados Móveis, Angelo Brayner. Banco de Dados para um Ambiente de Computação Móvel, Sérgio da Costa Cortes e Sérgio Lifschitz. Mobile Computing and Database A Survey, Daniel Barbará. Location Dependent Data and its Management in Mobile Databases, Margaret H. Dunham e Vijay Kumar. Mobile Computing: Data Management Issues, Alfredo Goñi e Arantza Illarramendi. Proposta de Dissertação de Mestrado Operações Desconectadas em Dispositivos Móveis, Mariano Cravo Teixeira Neto. Enterprise J2ME: Developing Mobile Java Applications, Michael Juntao Yuan. página 19