Captulo

3
Banco de Dados para um Ambiente de Computao Mvel
Srgio da Costa Crtes e Srgio Lifschitz

Abstract
Portable computers have been used in many different application domains and are, together with communication networks, the underlying technology for mobile computing. Database Systems (DBS) provide reliability, security and availability for data, besides integrity control and efficient data access. These DBS can either be located in conventional (fixed) networks as common data servers for many applications, or may serve global and local data for mobile computers and related technology. The latter defines a new role for Database Management Systems (DBMS), which might have to be adapted to answer new requirements due to the mobile environment. Indeed, these include support for unstable networks, weak connectivity and limited resources. This work is concerned with the main problems one may find when DBS are used in mobile computer systems. We present solutions and approaches used both in academy and at the industry. We give also an overview of ongoing research in this area. Particularly, we focus on systems architectures, transaction models, data management and mobile users location.

Resumo
Computadores portteis so cada vez mais utilizados em diversos domnios de aplicaes. Juntamente com as tecnologias das redes de comunicaes provem a base do hardware para a computao mvel. Os Sistemas de Bancos de Dados (SBD) e seus componentes bsicos fornecem todos os mecanismos para confiana, segurana, disponibilidade, integridade e acesso eficiente a suas bases de dados. Assim, os SBDs podem estar localizados tanto nas redes fixas, desempenhando um papel tradicional de servidores de dados para todas as aplicaes, como podem, tambm, desempenhar um novo papel de servidores de dados globais e locais, agora residindo em um equipamento mvel. Este novo papel dos SBDs, exigir um novo comportamento e adaptaes nos Sistemas de Gerncia de Bancos de Dados (SGBDs), para que os mesmos possam desempenhar seus papeis na administrao dos dados, em face s caractersticas do ambiente mvel. Entre estas caractersticas se destacam as constantes desconexes voluntrias ou involuntrias dos equipamentos mveis de suas redes, a fraca conectividade das redes sem fio nas quais os equipamentos mveis esto conectados e os poucos recursos dos equipamentos que hospedaro os SGBDs Mveis. Este trabalho apresenta os SBDs para o ambiente de computao mvel, os principais problemas encontrados, as solues hoje utilizadas acadmica e comercialmente e algumas das pesquisas em andamento. Vamos dar destaque em particular para assuntos tais como arquiteturas de sistemas, modelos de transaes, gerncia de dados e localizao de usurios mveis.

o 1. Introduc a
Diversas atividades que envolvem alguma interac a o com um Sistemas de Bancos de Dados (SBD) est ao presentes no nosso dia-a-dia. O dep osito ou a retirada de dinheiro em um banco, reservas em hot eis ou assentos de avi oes em companhias a ereas, a compra de produtos em um supermercado ou consultas a cat alogos informatizados de uma biblioteca, s ao bons exemplos da utilizac a o dos SBD na vida das pessoas. Todas essas atividades, para serem ecientes, envolvem o acesso a um banco de dados. As interac o es acima s ao exemplos do que podemos chamar de aplicac o es de bancos de dados tradicionais (convencionais) [Elmasri and Navathe, 2002]. Ao longo dos u ltimos anos, os Sistemas de Bancos de Dados (SBD) tamb em est ao sendo utilizados em novas e interessantes aplicac o es. Entre essas aplicac o es se destacam as aplicac o es geogr acas, de multim dia, biol ogicas, de apoio a ` decis ao e processamento anal tico on-line, em sistemas de tempo real, na internet e no ambiente de computac a o m ovel. Recentes avanc os na tecnologia da comunicac a o sem o (wireless) t em transformado os servic os de informac o es m oveis em uma realidade. H a um n umero cada vez maior de novos sistemas m oveis que necessitam de acessos a bancos de dados utilizando equipamentos do tipo Personal Digital Assistant - (PDA), computadores port ateis ou telefones celulares [Phatak and Badrinath, 1999]. A tecnologia de computac a o m ovel traz uma melhoria na distribuic a o e no uxo de informac o es e tamb em prov e um aumento consider avel nas funcionalidades das aplicac o es de bancos de dados [Ozsu and Valduriez, 1999]. A computac a o m ovel tem se transformado em uma realidade grac as a ` converg encia de duas tecnologias: o surgimento de computadores port ateis com maior poder de processamento e o desenvolvimento de redes de comunicac a o de dados mais velozes e con aveis. Um n umero cada vez maior de computadores necessita consultar diversos bancos de dados atrav es de canais de comunicac a o sem o. Esses clientes m oveis, dependendo do contexto, ir ao freq uentemente desconectar-se de suas redes de comunicac a o de dados por longos per odos de tempo, desconex ao esta causada, entre outros motivos, pela pouca capacidade das baterias de seus equipamentos. Al em disso, ir ao se locomover entre pontos distintos de suas redes, se conectando a diferentes servidores de dados em diferentes momentos [Barbar a, 1999]. O paradigma da computac a o m ovel tem afetado conceitos e modelos tradicionais em v arias a reas da ci encia da computac a o. Por exemplo, na a rea das redes de comunicac a o de dados, as redes necessitam estar dispon veis em todos os lugares, pois devem garantir a conectividade aos seus usu arios independente de sua localizac a o f sica. Redes de comunicac a o que atendam a essa propriedade s ao chamadas de ad hoc networks. J a na a rea de engenharia de software o paradigma da computac a o m ovel introduziu a noc a o de c odigo m ovel, o que signica a capacidade do c odigo migrar, por exemplo, de um servidor de banco de dados para um cliente m ovel, visando executar uma funcionalidade espec ca. J a na a rea de banco de dados e introduzido o conceito e a necessidade dos clientes m oveis acessarem seus bancos de dados a partir de qualquer lugar (any-where) e a qualquer momento (any-time) [Brayner and Filho, 2002] e [Satyanarayanan, 2001]. A computac a o m ovel pode ser considerada como uma variac a o da computac a o

 distribu da [Ozsu and Valduriez, 1999]. Assim sendo, quest oes relativas a ` ger encia de dados distribu dos tamb em podem ser aplicadas aos bancos de dados m oveis, tais como distribuic a o e replicac a o de dados, modelos de transac o es, processamento de consultas, recuperac a o e toler ancia a falhas, bem como seu projeto de bancos de dados, todas analisadas com o objetivo de atender os requisitos do ambiente da computac a o m ovel [Frank, 1999], [Gore and Ghosh, 2000] e [Lam et al., 2000]. Entre os principais objetivos deste trabalho destacam-se a utilizac a o dos bancos de dados no ambiente da computac a o m ovel, ressaltando seus novos requisitos e funcionalidades, a apresentac a o de diversos modelos e arquiteturas que podem ser utilizados com os bancos de dados no ambiente de computac a o m ovel, os principais problemas encontrados no ambiente de computac a o m ovel e como os bancos de dados podem ajudar a resolver estes problemas. Este trabalho est a organizado da seguinte forma: nesta sec a o e apresentada uma introduc a o ao ambiente da computac a o m ovel, destacando suas tecnologias, sua arquitetura, algumas aplicac o es, seus principais problemas e limitac o es, bem como uma breve revis ao dos principais conceitos de um Sistema de Banco de Dados (SBD). Na segunda sec a o e apresentada uma classicac a o para os Sistemas de Ger encia de Banco de Dados M oveis (SGBDs M oveis), com destaque para as extens oes do modelo cliente/servidor e o modelo de agentes m oveis. Na terceira sec a o a e nfase est a na apresentac a o dos principais problemas da computac a o m ovel que envolvem os bancos de dados, com destaque para o processamento de transac o es, os estados de operac a o que as unidades m oveis podem assumir, que tipo de operac o es podem executar em cada um desses estados, como os bancos de dados s ao utilizados nestes estados, os problemas envolvendo a desconex ao de suas redes, a fraca conectividade e como tratar as falhas para recuperac a o dos bancos de dados. A quarta sec a o apresenta a ger encia de dados m oveis, destacando a comunicac a o via broadcast, o problema da localizac a o dos clientes m oveis e alguns requisitos e funcionalidades necess arios para a ger encia da informac a o. Na quinta sec a o e apresentado o problema da localizac a o dos clientes m oveis, enfatizando as arquiteturas de bancos de dados usadas para gerenciar a localizac a o desses clientes. Na sexta sec a o o destaque e para como os bancos de dados m oveis est ao dispon veis comercialmente pela ind ustria e o andamento de alguns seguimentos de pesquisa cient ca e, nalmente, na s etima sec a o e apresentada uma conclus ao deste trabalho. 1.1. Tecnologia sem o (wireless) Conex oes sem o podem existir em diferentes partes de um ambiente das redes de comunicac a o de dados. Um importante papel das redes que suportam conex oes sem o e a sua capacidade de permitir a conex ao de um grande n umero de enderec os xos e sem o na sua infra-estrutura j a existente. Existem muitas tecnologias de acessos sem o para conex ao de usu arios m oveis ao backbone de redes com grande largura de banda. Tais tecnologias incluem: celular, r adios p ublicas e privadas, redes locais sem o, sistemas de paging e sistemas de sat elites em o rbita da terra [Pitoura and Samaras, 1998]. Celular - Estes sistemas podem ser geralmente caracterizados por proverem um amplo alcance de cobertura, suportarem duas formas (direc a o) de comunicac a o sem o e terem uma sosticada intelig encia para gerenciar a mobilidade dos usu arios. Sistemas

de celulares foram projetados para prover servic os de voz de grande alcance a pessoas que estejam em movimento e geralmente usam grande poder de transmiss ao. Por esta raz ao, sistemas de celulares podem somente prover servic os reduzidos para um conjunto de equipamentos port ateis que usam um pouco do baixo poder de transmiss ao e antenas menos ecientes que os ve culos dos usu arios. A primeira gerac a o dos sistemas celulares foi baseada na tecnologia anal o gica. Nesta tecnologia a voz e transmitida atrav es de circuitos-switch com estreitas larguras de bandas nos canais, usando freq ue ncia modular (FM). O sistema controla para cada c elula1 sob controle de uma Estac a o de Suporte a Mobilidade (ESM), tamb em conhecida como Estac a o de Base (EB), a sua localizac a o. Uma ESM est a localizada em uma rede xa. Esta gerac a o de sistemas sem o se caracteriza por possuir uma baixa taxa de transmiss ao de dados entre a ESM e o usu ario m ovel. A segunda gerac a o de sistemas sem o emprega modulac a o digital e possui uma capacidade avanc ada no processando de chamadas. Todos os sistemas celulares digitais prov em servic os de uma Rede Digital de Servic os Integrados, padr ao ISDN (Integrated Services Digital Network), os quais tornam a transfer encia de dados muito mais r apida. Portanto, podem oferecer servic os de voz junto com uma variedade de servic os de dados, tais como paging, faxsimile e outros acessos a redes com melhores taxas de transfer encia de dados. Nesta gerac a o, as estac o es m oveis apresentam e executam mais func o es de controles do que nos sistemas da primeira gerac a o, incluindo o controle 2 do processo de handoff , codicac a o e criptograa de dados. Exemplos dessa segunda gerac a o de sistemas sem o incluem o Global System for Mobile (GSM), desenvolvido principalmente na Europa, o Time Division Multiple Access (TDMA) e o Code Division Multiple Access (CDMA), padr ao digital dos Estados Unidos da Am erica (EUA), o Personal Access Comunication Systems (PACS) e o Digital European Cordless Telephone (DECT), padr ao Europeu para os telefones sem o e de escrit orios. R adios Publicas - Sistemas de R adios P ublicas (SRP) possibilitam um excelente e eciente canal para transmiss ao de dados de pequeno tamanho. Os sistemas existentes podem ser geralmente caracterizados como provedoras de alta mobilidade, ampla abrang encia e baixa taxa de comunicac a o de dados digital. Esses sistemas t em atra do muita atenc a o e servem muitos clientes em suas aplicac o es verticais, ou seja, espec cas de uma empresa. R adios M oveis Privadas - Sistemas de R adios M oveis Privadas (SRMP) s ao sistemas de r adio tradicionais provendo sistemas de voz sem o, a uma crescente demanda de servic os de comunicac a o de dados a organizac o es, tais como policias estaduais, servic os de t axis, servic os de ambul ancia, empresas de transportes, etc. Algumas redes s ao constru das em forma de cons orcios e servem a v arias organizac o es. Tais sistemas s ao chamados de Sistemas de R adio M oveis Compartilhados (SRMC). Os SRMP e os SRMC podem ser caracterizados como sistemas sem conex ao de voz, uma vez que seus usu arios est ao, basicamente, competindo por pequeno intervalo de tempo na mesma freq ue ncia. Em geral, a tecnologia e propriet aria e totalmente fornecida pelo vendedor dos equipamentos.
1 2

Area geogr aca de abrang encia de uma estac a o de suporte a mobilidade ou estac a o de base. Mudanc a da estac a o de base em func a o do movimento entre c elulas por um host m ovel.

Redes Locais Sem Fio (RLSF) - As RLSF s ao geralmente vistas como provedoras de alta velocidade de comunicac a o e com menor mobilidade dos seus clientes. RLSFs n ao objetivam suportar a verdadeira mobilidade, mas particularmente fornecer uma ponte entre as redes com o convencionais e as redes sem o. S ao projetadas para operarem em regi oes bem denidas, como por exemplo no campus de uma universidade, em departamentos de uma empresa, etc. Na falta de um padr ao, esses sistemas empregam uma variedade de tecnologias para suas conex oes. Em geral, as RLSFs de alta velocidade se enquadram em duas categorias: as que s ao desenvolvidas para operarem usando freq ue ncia de r adio e as que s ao desenvolvidas para utilizar regi oes infravermelho. Possibilitam altas taxas de transmiss ao de dados, a partir de centenas de Kbps a mais de 15 Mbps. Alguns exemplos dessas redes incluem as fabricadas pela Motorola, NCR, Proxim, WinData e InfraLan. Redes de Paging - Paging, na sua forma mais simples de apresentac a o, nada mais possui do que a capacidade de avisar e alertar que algu em deseja se comunicar com o seu portador. Um sistema de r adio paging foi originalmente denido como n ao discursivo (non-speech), de m ao u nica, um sistema seletivo pessoal com alertas, sem mensagens ou com mensagens denidas como alfanum ericas ou num ericas. J a os sistemas mais recentes possuem uma limitada capacidade de comunicac a o em m ao dupla e enviam pequenas mensagens de voz. Um aspecto atrativo dos paging e o baixo consumo de recursos para receber mensagens. Sistemas de Sat elites - Sistemas sem o com base em sat elites representam a maior cobertura de longo alcance, cobrindo amplas a reas como oceanos, continentes e pa ses. Podem ser caracterizadas por proverem uma comunicac a o em m ao dupla, com baixas qualidades de comunicac a o de voz e/ou com capacidade muito limitada para troca de mensagem ou de dados. 1.2. Arquiteturas Sem Fio Mobilidade tornou-se um novo paradigma em sistemas distribu dos. Como conseq ue ncia da mobilidade, destaca-se a complexa e dif cil tarefa de manter as bases de dados operacionais atualizadas. Em relac a o a ` interface de comunicac a o, existe o problema da qualidade da conex ao sem o, que varia abruptamente em func a o do local, as falhas de comunicac a o entre os terminais remotos e seus hosts, e a seguranc a da comunicac a o entres os clientes m oveis e seus servidores xos. Quanto a ` portabilidade dos dispositivos, destacam-se a pouca mem oria dispon vel nos equipamentos m oveis, a lentid ao de seus processadores e a sua capacidade em se manter ativo em func a o da energia fornecida por sua bateria [Endler and da Silva e Silva, 2000]. 1.2.1. Arquitetura de um Sistema M ovel A arquitetura gen erica de uma plataforma m ovel consiste em uma arquitetura distribu da [Ozsu and Valduriez, 1999], na qual diversos computadores, geralmente conhecidos como Hosts Fixos (FS - Fixed Hosts) e Estac o es de Base (BS - Base Stations), s ao interligados atrav es de uma rede com o de alta velocidade. Hosts xos s ao computadores de nalidade gen erica que n ao s ao equipados para gerenciar unidades m oveis, mas podem ser congurados de forma a faz e-lo. Estac o es de Base s ao equipadas com interfaces para

as redes sem o e podem comunicar-se com as unidades m oveis para suportar o acesso a dados [Elmasri and Navathe, 2002]. Unidades M oveis (Mobile Units) s ao computadores port ateis movidos a ` bateria, que se movimentam livremente em um dom nio geogr aco de mobilidade, uma a rea que e restringida pela limitada amplitude de banda dos canais de comunicac a o sem os. Para gerenciar a mobilidade dessas unidades, o dom nio de mobilidade geogr aca e dividido em dom nios menores chamados de c elulas. A computac a o m ovel requer que o movimento de unidades seja irrestrito dentro do dom nio de mobilidade geogr aca (movimento intercelular), ao mesmo tempo em que possuir contig uidade de acesso durante o movimento, garante que o movimento de uma unidade m ovel atrav es dos limites das c elulas n ao ter a nenhum efeito sobre o processo de recuperac a o de dados [Elmasri and Navathe, 2002]. es de Base se comunicam atrav Unidades M oveis e Estac o es de canais sem o que possuem largura de banda signicativamente menores do que aquelas de uma rede com o. Um canal de conex ao do tipo downlink e utilizado para enviar dados da Estac o es de Base para as Unidades M oveis, e um canal de conex ao do tipo uplink e utilizado para enviar dados das Unidades M oveis para as Estac o es de Base [Elmasri and Navathe, 2002]. A Figura 1, extra da de [Dunham and Helal, 1995] apresenta uma arquitetura gen erica para um sistema de computac a o m ovel.
Clula de Rdio no-cabeada

disconectado
Host SiteFixo 1

Host Fixo Host Fixo

Rede cabeada de alta velocidade

Estao de Base

Estao de Base

Host Fixo Host Fixo

Estao de Base

Clula LAN no-cabeada

cruzamento
Clula de Rdio no-cabeada

Unidades mveis
Links no-cabeados

Movel Figura 1: Arquitetura de um Sistema de Computac ao

Segundo [Endler and da Silva e Silva, 2000], entre os principais requisitos impostos pelas caracter sticas da computac a o m ovel aos sistemas de softwares destacamse: 1. A capacidade de localizar/enderec ar elementos m oveis;

2. 3. 4. 5. 6. 7. 8.

A capacidade de perceber mudanc as no ambiente de execuc a o; A capacidade de se autocongurar; A capacidade de migrar funcionalidade; O uso eciente dos recursos no elemento m ovel; O uso eciente dos recursos do canal de comunicac a o sem o; O alto grau de toler ancia a ` falhas; e Os mecanismos para autenticac a o e encriptograa de dados.

1.2.2. Ger encia de Dados em um Ambiente M ovel A computac a o m ovel pode ser considerada como uma variac a o da computac a o distribu da. Os bancos de dados m o dos sob dois aspectos veis podem ser distribu [Ozsu and Valduriez, 1999]: 1. Todo o banco de dados e distribu do, principalmente, entre os componentes sob a rede com o, possivelmente com replicac a o total ou parcial. Assim, uma estac a o de base gerencia seu pr oprio banco de dados com as funcionalidades inerentes aos Sistemas de Ger encia de Banco de Dados (SGBDs), com funcionalidades adicionais para localizar unidades m o sticas adicionais de ger encia veis e caracter de consultas e transac o oveis; es, para atender aos requisitos de ambientes m 2. O banco de dados e distribu do entre os componentes sob a rede com o e com os componentes sob a rede sem o. A responsabilidade sobre a ger encia de dados e compartilhada entre estac o es de base e unidades m oveis. Segundo [Elmasri and Navathe, 2002], [Frank, 1999], [Lam et al., 2000] e [Gore and Ghosh, 2000], as quest oes relativas a ` ger encia de dados distribu dos podem tamb em ser aplicadas aos bancos de dados m oveis com os seguintes aspectos sendo analisados de forma especial: 1. 2. 3. 4. 5. A distribuic a o e replicac a o de dados; Os modelo de transac a o; O processamento de consultas; A recuperac a o e toler ancia a ` falhas: O projeto de bancos de dados m oveis.

es 1.3. Aplicac o Com a arquitetura e a infra-estrutura dispon veis surge uma nova classe de aplicac o es, a qual combina a computac a o pessoal com clientes e o ambiente da computac a o m ovel. Para que essas novas tecnologias de computac a o m ovel e bancos de dados m oveis possam trabalhar em conjunto, e necess ario que as mesmas d eem suporte a aplicac o es que sejam necess arias e u teis a uma comunidade de usu arios. A tecnologia sem o dever ir al em de servir a um pequeno n umero de aplicac o es verticais (de a mbito espec co de empresas) e alcanc ar um grande n umero de usu arios. Entre as principais caracter sticas que podem levar essas tecnologias a se popularizarem destacam-se: 1. A possibilidade de acessar a grandes bancos de dados de qualquer lugar e a qualquer momento;

2. A versatilidade de formas de comunicac a o e a cooperac a o que poder existir entre seus usu arios; 3. A possibilidade de noticac a o a uma comunidade de usu arios a respeito de fatos ou eventos cr ticos e u teis para seus usu arios m oveis; 4. A possibilidade de integrac a o de pontos distantes de empresas. Entre os muitos exemplos de aplicac o es para o ambiente de computac a o m ovel e bancos de dados m oveis destacam-se diversas aplicac o es que podem ser classic a-las em verticais e horizontais (no a mbito geral de comunidades) [Imielinski and Badrinath, 1992], [Badrinath et al., 1993] e [Pitoura and Bhargava, 1994a]: Vendas de produtos por vendedores com acesso a estoques em tempo real; Controle de transportes de cargas e localizac a o geogr acas de caminh oes atrav es de rastreamento; Acompanhamento e orientac a o de procedimentos m edicos em ambul ancias; Envio e recebimento de arquivos e e-mails em notebooks atrav es de modem de celular; Acesso a ` internet em notebooks e PADs atrav es de modem de celular; Computac a o cooperativa entre usu arios m oveis, como por exemplo alertas de acidentes em rodovias, cat astrofes naturais, situac o es de perigo, etc; Recebimento e armazenamento de fotos de sat elites; es 1.4. Problemas e Limitac o Diversas novas caracter sticas e limitac o es inerentes aos sistemas de computac a o m oveis precisam ser reavaliadas, principalmente no contexto dos SBDs. Segundo [Satyanarayanan, 1996] estas limitac o es podem ser explicadas pelas seguintes restric o es: Elementos m oveis s ao relativamente pobres em recursos em relac a o aos elementos xos, est aticos; A mobilidade e em sua natureza perigosa; A conectividade no ambiente m ovel e altamente vari avel em seu desempenho e na conabilidade da conex ao; Os elementos m oveis contam com uma fonte de energia nita para seus equipamentos. As caracter sticas e limitac o es dos sistemas de computac a o m oveis, descritas em [Pitoura and Samaras, 1998] e [Endler and da Silva e Silva, 2000], podem ser classicadas de acordo com as seguintes propriedades: 1. Mobilidade dos hosts - A localizac a o dos elementos m oveis e conseq uentemente seus pontos de conex ao a rede xa se alteram como o seu movimento. As principais conseq ue ncias da mobilidade s ao: (a) A congurac a o dos sistemas que incluem elementos m oveis n ao s ao est aticas. i. Os algoritmos de processamento distribu dos tradicionais precisam ser reprojetados devido a ` aus encia de uma topologia xa da rede com os elementos m oveis;

ii. A distribuic a o de carga em uma rede com elementos m oveis pode mudar de maneira muito r apida, em func a o da possibilidade de mudanc a de localizac a o din amica desses elementos. (b) Ger encia de localizac a o. i. O custo para localizar um elemento m ovel contribui de forma signicativa para o custo de cada comunicac a o; ii. Estruturas de dados, algoritmos e planos de consultas ecientes devem ser planejados e desenvolvidos para representar, gerenciar e consultar a localizac a o dos elementos m oveis, uma vez que os dados de localizac a o podem se alterar de forma muito r apida. (c) Heterogeneidade. i. A conectividade de um elemento m ovel pode variar muito em relac a o ao seu desempenho, principalmente pela largura de banda do canal de comunicac a o e pela lat encia3 da comunicac a o, bem como pela conabilidade dessa comunicac a o; ii. O n umero de servic os dispon veis para um elemento m ovel pode variar de uma localizac a o para outra, em func a o das caracter sticas da c elula e da estac a o de base na qual ele se conecta; iii. Os recursos dispon veis nos elementos m oveis variam, como por exemplo a sua capacidade de mem oria, o tamanho de sua tela, o tempo de durac a o de sua bateria, etc. o sem o - O fato da comunicac 2. Interface de comunicac a a o entre um elemento m ovel e uma estac a o de base ser atrav es de uma rede de comunicac a o sem o, tem como principais conseq ue ncias: (a) Conectividade fraca e intermitente4. i. As redes sem o s ao monetariamente mais caras; ii. Oferecem menores larguras de banda; iii. Possuem uma lat encia maior do que as redes com o; iv. S ao menos con aveis que as redes com o. (b) Conectividade vari avel. i. A qualidade da conex ao pode variar abruptamente em func a o de poss veis interfer encias na comunicac a o, da dist ancia do elemento m ovel com a estac a o de base na qual est a conectado ou devido ao compartilhamento da estac a o de base por v arios elementos m oveis; ii. A tecnologia sem o se modica em func a o do grau da largura da banda de comunicac a o e da seguranc a que a rede fornece; (c) Facilidade para transmiss ao de dados (broadcast). i. Existe um canal com grande largura de banda para transmiss ao de dados da estac a o de base para todos os clientes m oveis em sua c elula; ii. Possibilidade para disseminac a o de informac o es a grupos de clientes m oveis espec cos; iii. Possibilidade de prestac a o de servic os espec cos para certos grupos de clientes m oveis (d) Tarifas
3 4

Per odo de inatividade entre um est mulo e a resposta por ele provocada. Apresenta interrupc o es ou suspens oes; n ao cont nua.

i. Em algumas redes o acesso a ` rede e pago pelo tempo de conex ao, como por exemplo nas comunicac o es via telefones celulares; ii. Em outras redes o acesso a ` rede e pago por mensagens, como por exemplo nas comunicac o es via pacotes de r adio. 3. Portabilidade dos Elementos M oveis - Por serem port ateis, os elementos m oveis precisam ser pequenos e leves, tornando-os inferiores em suas capacidades de processamento aos computadores convencionais. Assim sendo: (a) Elementos m oveis s ao pobres em recursos quando comparados com os elementos est aticos; i. S ao equipados com pouca mem oria do tipo RAM (Randon Access 5 Memory) ; ii. Seus processadores s ao mais lentos; iii. Possuem pouca mem oria n ao vol atil (n ao possuem disco r gido); iv. A interface do usu ario e mais limitada; v. O monitor e menor ou tem menor capacidade em seu buffer; vi. Os dispositivos de entrada de dados tamb em s ao menores e limitados (por exemplo, teclados de aparelhos celulares). (b) Elementos m oveis contam com pouca capacidade em suas baterias; i. Dependem da energia fornecida por baterias; ii. Normalmente as baterias possuem capacidades limitadas; iii. Em alguns lugares, diculdade para recarga da bateria. (c) Elementos m oveis s ao poucos robustos i. F aceis de serem danicados; ii. Facilmente perdidos ou roubados. es 1.5. Sistemas de Bancos de Dados (SBD) - SGBDs, BDs e Aplicac o Bancos de Dados e suas tecnologias v em tendo um grande impacto no crescimento do uso de computadores. Podemos armar que os bancos de dados desempenham um papel extremamente importante em todas as a reas da ci encia onde a computac a o e utilizada. A express ao banco de dados tem sido t ao amplamente utilizada que precisamos iniciar com a denic a o do que seja um banco de dados. Segundo [Elmasri and Navathe, 2002], um banco de dados e a ao denidos como fatos uma colec o de dados relacionados. Dados s conhecidos que podem ser registrados e que possuem signicado impl cito. Por exemplo, o c odigo, nome, valor e a quantidade do produto em estoque de um supermercado, e uma colec a o de dados relacionados com um signicado impl cito e, portanto, um banco de dados. Um banco de dados possui as seguintes propriedades impl citas: Representa algum aspecto do mundo real. Alterac o es neste mundo real s ao reetidas no banco de dados; uma colec E a o l ogica e coerente de dados com algum signicado inerente. Uma organizac a o aleat oria de dados n ao pode ser referenciada corretamente como um banco de dados; projetado, constru E do e povoado com dados que possuem um objetivo espec co. Ele possui um grupo prov avel de usu arios e algumas aplicac o es preconcebidas, nas quais esses usu arios est ao interessados;
5

Mem oria de Acesso Aleat orio.

 Deve possuir alguma fonte da qual os dados s ao derivados, algum grau de interac a o com eventos do mundo real e um p ublico que est a ativamente interessado no conte udo do banco de dados.

Um Sistema de Ger encia de Banco de Dados (SGBD) e uma colec a o de programas que possibilita que os usu arios criem e mantenham um banco de dados. O SGBD e portanto um sistema de software de nalidade gen erica que facilita o processo de denic a o, construc a o e manipulac a o de bancos de dados para v arias aplicac o es. Denir um banco de dados envolve especicar os tipos de dados, as estruturas e as restric o es para os dados que ser ao armazenados no banco de dados. Construir o banco de dados e o processo de armazenar os referidos dados em algum meio de armazenamento que seja controlado pelo SGBD. Manipular o banco de dados inclui func o es como fazer consultas ao banco de dados para recuperar dados espec cos, atualizar o banco de dados para reetir as alterac o es do mundo real e gerar relat orios a partir dos dados [Elmasri and Navathe, 2002]. Um Sistema de Banco de Dados (SBD) e formado pelos bancos de dados, pelo SGBD e pelas aplicac o es necess arias para criac a o e manutenc a o do banco de dados, bem como pelas aplicac o es para atualizac a o e consulta aos dados do banco de dados. A Figura 2, extra da de [Elmasri and Navathe, 2002], apresenta um ambiente simplicado de um SBD.

SBD

Programas da aplicao/consultas BD + SGBD + aplicao

SGBD Software para processar programas/consultas

programadores/usurios

Software para acessar os dados armazenados

software que facilita o gerenciamento do BD

Armazenamento com as definies do Banco de Dados (metadados)

Armazenamento com o Banco de Dados

conjunto de itens de dados interrelacionados que podem ser processados por 1 ou + sistemas de aplicao

Figura 2: Um ambiente simplicado de um SBD

 o dos SGBDs M 2. Classicac a oveis e Arquiteturas de software para o M computac a ovel

O ambiente de computac a o m ovel e restritivo em v arios aspectos. Os elementos m oveis possuem poucos recursos e n ao s ao muito con aveis. Sua conectividade com a rede e freq uentemente obtida atrav es de links sem o com pequena largura de banda. Al em disso, a conectividade e freq uentemente perdida em v arios momentos. Essas diculdades causadas por estas restric o es s ao combinac o es da mobilidade que induz a variabilidade na disponibilidade tanto dos recursos computacionais como de comunicac a o. Essas restric o es causam um grande impacto no projeto e na estrutura das aplicac o es para computac a o m ovel e motivam a pesquisa e desenvolvimento de novos modelos computacionais. Esses modelos devem prover eci encia de acesso tanto para as novas aplicac o es como as j a existentes, o que e o requisito b asico para uma ampla aceitac a o da computac a o m ovel. o dos Sistemas de Ger 2.1. Classicac a encia de Banco de Dados M oveis Podemos ver o ambiente de computac a o dos SGBDs M oveis como uma extens ao dos sistemas distribu dos. [ Ozsu and Valduriez, 1999] oferece uma excelente classicac a o para os SGBDs Distribu dos baseado nas caracter sticas do sistema quanto a autonomia, distribuic a ao para essa classicac a o o e heterogeneidade. A Figura 3 apresenta uma extens segundo [Dunham and Helal, 1995] para os SGBDs M oveis, os quais acrescentam um ponto no eixo de distribuic a a o m oveis. A o, caracterizando os sistemas de computac l ogica para essa extens ao est a no fato que os sistemas de computac a o m oveis devem ter uma rede xa (veja gura 1) que e um sistema distribu do.

Distribuio
SGBD homogneo mvel SGBD homogneo distribudo sistema multidatabase homogneo mvel

SGBD heterogneo mvel

sistema multidatabase heterogneo mvel sistema multidatabase homogneo distribudo

SGBD heterogneo distribudo SGBD homogneo centralizado

sistema multidatabase homogneo centralizado

Autonomia
SGBD heterogneo centralizado sistema multidatabase heterogneo distribudo

Heterogeneidade

sistema multidatabase heterogneo centralizado

dos SGBDs Moveis Figura 3: Classicac ao

Considerando os sistemas m oveis como um caso especial dos sistemas distribu dos, percebe-se que enquanto muitos problemas s ao iguais, existem outros problemas bem diferentes. Os sistemas distribu dos t em como principal objeto a transpar encia de distribuic a a os sistemas m oveis buscam o conhecimento da o, j localizac a ovel est a localizado geogracamente o, ou seja, saber onde um cliente m (espacialmente) para poder manter uma comunicac a o constante, sem interrupc o es, com o mesmo. Entre as principais caracter sticas dos SGBDs M oveis podemos destacar: V arios bancos de dados interligados por uma rede de comunicac a o sem o; Acesso de um computador m ovel (host m o vel) a um banco de dados residindo em um em um computador xo (host xo) ou em um computador m ovel; O computador m ovel pode desempenhar o papel de cliente ou servidor de banco de dados; Os bancos de dados s ao aut onomos, distribu dos e provavelmente heterog eneos. Quanto a ` ger encia e administrac a o dos dados, diversos fatores podem inuenciar o funcionamento e a performance dos bancos de dados no ambiente de computac a o m ovel. Entre esses fatores, destacam-se: Velocidade dos links sem o - 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 oveis; Mobilidade - pode causar desconectividades e cancelamento de transac o es; Localizac a o dos hosts mo veis - implica na necessidade de administrar a localizac a o dos hosts m oveis para interac a o durante as consultas; Limite do poder das baterias - exigem trabalho em modo desconectado da rede e podem causar desconex oes e cancelamento de transac o es; Desconectividade (volunt aria ou involunt aria) - causam o cancelamento de transac o es, aumentando a necessidade de novos modelos de recuperac a o (recovery) do banco de dados; Replicac a oria dos hosts m oveis; o/Caching - limitadas pelo pouco poder de mem Handoff - aumenta a necessidade de controle e administrac a o da localizac a o dos hosts m oveis. Para facilitar o entendimento de algumas caracter sticas do ambiente de computac a o m ovel, e importante entender algumas diferenc as entre as soluc o es tradicionais aplicadas aos bancos de dados convencionais para soluc a o de problemas em bancos de dados distribu dos, e esses mesmos problemas no ambiente de computac a o m ovel. A tabela 1, extra da de [Dunham and Helal, 1995] apresenta essas principais diferenc as.

No ambiente distribu do o SGBD necessita se recuperar de eventuais falhas em sites, nos meios de comunicac a o, de transac o es e de comunicac a o. Estes mesmos problemas persistem na computac a o m ovel, entretanto, a freq ue ncia pode ser muito maior. Estes problemas complicam a recuperac a o, devido ao fator de mobilidade nas transac o es. Transac o es distribu das s ao executadas concorrentemente em m ultiplos

Principais diferenc as para os BDs m oveis Implicac o a as com a Computac a ovel es na Administrac o de Dados Diferenc o M - Pode ser dependente de localizac a o do host m ovel Aplicac o es - Necessita adaptar-se a ` s mudanc as no contexto do sistema Transac o es - Novos modelos para captac a o da mobilidade - Divis ao (particionamento) freq uente da rede - Desligamento volunt ario do host m ovel n ao e uma falha do sistema Recuperac a o - A mobilidade pode causar in umeros acessos (logins) ao sistema - T ecnicas para recuperac a o de desconex oes durante o handoff - Diferentes restric o es de consist encia Replicac a o - Novas t ecnicas para os hosts m oveis atualizarem suas mem orias cache durante as freq uentes desconex oes - Dependente da localizac a o do host m ovel - Diferentes fatores de custos Processamento de consulta - Resposta das consultas retornam para diferentes localizac o es - Necessidade de adaptac o es das t ecnicas Resoluc a o de nomes (enderec os) - Estrat egia de nome global devido a desconectividade e mobilidade
Tabela 1: Diferenc as entre a gerencia de dados distribu dos e a gerencia de dados moveis

conjuntos de dados e processadores. As execuc o es das transac o es distribu das s ao totalmente coordenadas pelo sistema, incluindo o controle de concorr encia, a ger encia de replicac a o e a atomicidade das transac o es. Transac o es m oveis, por outro lado, s ao executadas seq uencialmente atrav es de m ultiplas estac o es de base, em v arios conjuntos de dados, dependendo do movimento da unidade m ovel. Assim, a execuc a o da transac a o m ovel na estac a o de base pode ser considerada uma transac a o distribu da. A execuc a o da transac a o, e ent ao, n ao totalmente coordenada pelo SGBD. O movimento da unidade m ovel, por uma grande extens ao espacial, controla a execuc a o. Somente este fato exige um novo modelo de transac o es para o SGBD M ovel. 2.2. Agentes de Software Um agente e um sistema de computac a o situado em algum ambiente computacional, sistema este que e capaz de executar ac o es aut onomas neste ambiente, visando atingir os objetivos para o qual foi projetado e desenvolvido. Um sistema de agentes deve poder agir sem a intervenc a o direta dos seres humanos ou de outros agentes, como tamb em deve possuir todo o controle de suas pr oprias ac o es e estado interno. Um agente inteligente e um sistema computacional que e capaz de executar ac o es aut onomas ex veis a m se atingir os objetivos do projeto para o qual foi projetado e

desenvolvido. Por ex vel, entendemos que o sistema deve ser reativo, proativo e social [Jennings and Wooldridge, 1998]. A principal caracter stica de um agente e a sua habilidade de agir de forma aut onoma. Isto implica que um agente recebe est mulos de seu ambiente, pode executar um conjunto de ac o es que alteram este mesmo ambiente, decidindo pelas ac o es que devem executadas baseadas em seus pr oprios objetivos [Kearney, 1998]. Os agentes de software podem ser classicados por sua (1) mobilidade; (2) capacidade de reac a es o; (3) atrav dos diversos atributos que idealmente devem exibir; (4) por seus pap e is; e (5) pelos agentes h bridos que combinam duas ou mais losoas do agente em um u nico agente [Nwana and Ndumu, 1998]. o M 2.3. O modelo Cliente/Servidor e suas extens oes para Computac a ovel O planejamento de modelos apropriados para aplicac o es estruturadas que envolvem elementos sem o e uma quest ao fundamental no desenvolvimento do software para a computac a o m ovel. A seguir e apresentado um breve resumo sobre o modelo cliente/servidor, bem como algumas extens oes desse modelo de software para a computac a o m ovel. 2.3.1. O modelo Cliente/Servidor A modelo (arquitetura) cliente-servidor sup oe uma estrutura (framework) b asica que consiste de muitos microcomputadores (PCs) e estac o es de trabalho, bem como um n umero menor de equipamentos de grande porte, conectados atrav es de sistemas de redes locais e outros tipos de sistemas de rede de computadores. Um cliente nesta estrutura e geralmente um equipamento de um usu ario 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 ao reside neste equipamento, ele se conecta a um servidor que fornece a funcionalidade necess aria. Um servidor e um equipamento que pode fornecer servic os para as estac o es clientes, como impress ao, armazenamento de dados ou acesso ao banco de dados [Elmasri and Navathe, 2000]. A id eia da arquitetura cliente-servidor e dividir as funcionalidades que precisam ser fornecidas aos usu arios do SGBD em duas camadas, a camada servidor e a camada cliente, ambas com funcionalidades distintas. Essa arquitetura facilita o gerenciamento da complexidade dos SGBDs atuais [Ozsu and Valduriez, 1999]. A arquitetura clienteservidor est a incorporada aos Sistemas de Ger encia de Banco de Dados (SGBD). Em SGBDs relacionais, atrav es de sua uma linguagem padr ao chamada Structured Query Language (SQL), criou-se um ponto de divis ao l ogica entre o cliente e o servidor do banco de dados. Nos cliente est ao os programas de aplicac a o e a interface do usu ario, enquanto que as funcionalidades de consultas e transac o es permaneceu no lado do servidor. Neste caso podemos dizer que o servidor e um servidor de consulta ou servidor de transac a o, pois fornece essas duas funcionalidades. Os programas da interface do usu ario e da aplicac a o podem ser executados no lado do cliente. Quando e necess ario acesso ao banco de dados, o programa estabelece uma conex ao com o SGBD, que est a no lado do servidor, e uma vez que a conex ao e estabelecida, os programas no cliente podem se comunicar com o SGBD. Um exemplo de como efetivar essa conex ao e atrav es do

padr ao chamado Open Database Connectivity (ODBC), o qual fornece uma Application Programming Interface (API), que permite que programas no lado do cliente chamem o SGBD, contanto que os equipamentos do cliente e do servidor tenham instalado os software necess arios. Os resultados das consultas s ao enviados de volta para os programas no cliente, que podem processar ou exibir os resultados conforme necess ario. Um outro exemplo de conex ao e a utilizac a o de programac a o JAVA, chamado JDBC, permitindo que programas de clientes escritos na linguagem JAVA acessem o SGBD atrav es de uma interface padr ao [Elmasri and Navathe, 2000]. Conforme mostra a Figura 4, extra da de [Ozsu and Valduriez, 1999], a camada servidor faz a maior parte do trabalho de gerenciamento de dados, enquanto que a camada cliente cuida da interface do usu ario e da aplicac a o, al em de administrar uma mem oria local para solicitac a o e armazenamento do resultado das consultas.

Sistema Operacional

Interface do Programas Outros usurio aplicativos software SGBD cliente (driver) Software de comunicao
Resultado das consultas
Software de comunicao Controlador semntico de dados

Consultas SQL

Sistema

Otimizador de consultas Gerente de transaes Gerente de recuperao Processador de execuo

Operacional
Banco de Dados

Figura 4: Componentes da modelo/arquitetura Cliente/Servidor para SGBDs

Diferentes tipos de arquiteturas cliente/servidor podem ser implementadas. A arquitetura mais simples e aquela em que v arios clientes acessam um u nico servidor, denominada m ultiplos clientes-servidor u aquela em nico. A arquitetura mais complexa e que o ambiente possui mu and Valduriez, 1999] ltiplos clientes-multiplos servidores [ Ozsu e [Melo et al., 1997]. o M 2.3.2. O modelo Cliente/Servidor para Ambiente de Computac a ovel Na computac a o m ovel, o host m ovel atua como um cliente requisitando servic os dos servidores localizados na rede xa. Nestes casos, os dados e as funcionalidades est ao distribu dos atrav es de v arios servidores em diferentes hosts xos que podem

comunicar-se entre si para atender as solicitac o es dos clientes. Em muitos casos, o servidor e replicado em diferentes sites na rede xa para aumentar a disponibilidade nos casos de falhas nos sites ou na rede de comunicac a o. A Figura 5, extra da de [Pitoura and Chrysanthis, 2000], apresenta um ambiente de computac a o m ovel em uma arquitetura cliente servidor tradicional.

Link sem fio Rede fixa

Aplicao Cliente Cliente mvel

Aplicao Servidora

movel Figura 5: Ambiente de computac ao em uma arquitetura Cliente/Servidor convencional

A divis ao das funcionalidades entre os clientes m o veis e os servidores xos que est ao sob as redes xas n ao e muito clara. Em muitos casos o papel de cada um ca confuso, como no caso durante as desconex oes em que o cliente m ovel necessita emular as funcionalidades de um servidor para continuar operando. Um importante componente da arquitetura cliente/servidor e o tipo de mecanismo de comunicac a o que e usado para a troca de informac o es entre o cliente e o servidor. Uma possibilidade e a troca de mensagens direta entre o cliente e o servidor. Essa abordagem n ao e adequada para as redes lentas e pouco con aveis como e o caso da computac a o sem o e novos mecanismos de troca de informac o es est ao em estudos. Extens oes do tradicional modelo cliente/servidor, como se enleirar mensagens RDC (Remote Procedure Call), s ao necess arias para dar apoio a operac o es desconectadas e a fraca conectividade. Otimizac o es adicionais como compress ao e ltros de dados tamb em s ao importantes. Por estes motivos, o tradicional modelo cliente/servidor deve ser estendido para prover s erios componentes para implementac a o de otimizac o es adequadas e possibilitar o m nimo poss vel de mudanc as nos clientes e nos servidores [Pitoura and Samaras, 1998]. 2.3.3. O Modelo Cliente/Agente-Servidor/Servidor Este modelo em tr es camadas (three-tier) realiza a comunicac a o entre o cliente m ovel e o servidor, atrav es 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 (surrogate) do cliente m ovel na rede xa. Esta arquitetura alivia um pouco o impacto da limitac a o da largura de banda e da pouca seguranc a do link sem o, atrav es da presenc a do cliente

m ovel na rede xa via o agente. Os agentes, tipicamente, dividem a interac a o entre os clientes m oveis e os servidores xos em duas partes, sendo uma entre o cliente e o agente e a outra entre o agente e o servidor xo. Assim, diferentes protocolos 6 podem ser usados para interac a o em cada parte e essas partes podem ser executar suas funcionalidades independentemente. A Figura 6, extra da de [Pitoura and Chrysanthis, 2000], apresenta essa arquitetura.

Link sem fio

Rede fixa

Aplicao Cliente Cliente mvel

Agente

Aplicao Servidora

camadas Cliente/Agente-Servidor /Servidor Figura 6: Modelo em tres

Este modelo e mais apropriado para clientes m oveis com limitado poder de recursos e poder computacional. Assim, diversas responsabilidades dos clientes m oveis migram para os agentes. Por exemplo, uma consulta com grande quantidade de dados como resposta pode ser gerenciada pelo agente e somente ao seu nal ter seus resultados transmitido ao cliente m ovel. A localizac a o do agente na rede xa possibilita o acesso a ` rede com grande largura de banda e grande poder computacional, podendo usar esses recursos em favor dos clientes m oveis. Por exemplo, a compress ao dos dados pode ser executada no agente, antes da transmiss ao dos dados aos clientes m oveis. Para lidar com a desconex ao os clientes m oveis podem submeter suas solicitac o es aos agentes e esperar a devoluc a o dos resultados quando a conex ao for restabelecida. Durante a desconex ao, v arias solicitac o es dos clientes m oveis podem ser processadas e enleiradas para serem transmitidas aos clientes m oveis logo ap os a nova conex ao. Esta estrat egia tamb em pode ser usada pelos clientes m oveis para preservar o tempo u til de suas baterias. Os clientes m oveis submetem suas solicitac o es, entram em modo de cochilo (doze) e aguardam a espera das respostas dos agentes. A fraca conectividade tamb em pode ser efetivamente manuseada pelos agentes de v arias formas, empregando in umeras t ecnicas para minimizar o tamanho dos dados a serem transmitidos aos clientes m oveis, dependendo do tipo de dados e das aplicac o es. O agente tamb em pode manipular os dados antes da sua transmiss ao, alterando a sua ordem de transmiss ao em func a o da prioridade dos mesmos para os clientes m oveis. Os agentes podem ser usados de v arias formas e desempenhando diversos papeis nesta arquitetura. A exata posic a o dos agentes na rede xa depende do papel que o mesmo
6 Conjunto de regras, padr oes e especicac o es t ecnicas que regulam a transmiss ao de dados entre computadores por meio de programas espec cos

venha a desempenhar. Colocando-o na extremidade da rede xa, como por exemplo nas estac o as algumas vantagens quando o agente atua como substituto es de bases, tr (surrogate) do cliente m ovel em sua a rea de cobertura. Assim, ca mais f acil reunir informac o es das caracter sticas do link sem o; utilizar um protocolo especial entre o cliente m ovel e o agente; personalizar informac o es sobre o cliente m ovel que podem ser disponibilizadas localmente. O modelo Cliente/Agente-Servidor/Servidor oferece um grande n umero de vantagens, por em, falha no suporte da operac a o dos clientes m oveis durante o per odo de desconex ao. Quando acontece uma desconex ao, o cliente m ovel n ao continua a operar ininterruptamente. Finalmente, o agente somente consegue otimizar a transmiss ao de dados do agente para o cliente m ovel, mas n ao no caminho inverso [Pitoura and Samaras, 1998]. 2.3.4. O Modelo Cliente/Agente-Cliente/Servidor Este modelo apresenta uma extens ao do modelo cliente/servidor, tamb em em tr es camadas, por em, com a inclus ao do agente de software junto ao host m ovel, ou seja, no cliente m ovel. A Figura 7, extra da de [Pitoura and Chrysanthis, 2000], apresenta essa extens ao. Genericamente, podemos dizer que o agente assume o papel de ampliar as funcionalidades nos clientes m oveis, geralmente pobres em recursos computacionais. Entre as muitas atividades espec cas de uma aplicac a o que os agentes podem desempenhar, podemos destacar, de uma forma mais gen erica, as seguintes atividades: Administrar a mem oria caching no cliente m ovel; Disponibilizar mem oria progressivamente para o cliente m ovel durante o pouco tr afego da rede (prefetching7); Copiar parte do banco de dados para a mem oria do cliente m ovel (hoarding 8), caracterizando um caso especial de replicac a o; Otimizar a comunicac a o entre o cliente m ovel e sua estac a o de base.

2.3.5. O Modelo Cliente/Agente-Agente/Servidor Para sanar as deci encias dos dois modelos anteriores, nos quais os agentes de software residem e executam em apenas um dos lados da arquitetura, ou seja, no cliente m ovel ou no servidor da rede xa, [Samaras and Pitsillides, 1997] propuseram este modelo, tamb em chamado de Cliente/Intercept/Server no qual o agente situado no cliente m ovel executar a em conjunto com o agente situado no servidor. O agente situado no cliente m ovel detecta (intercepta) as solicitac o es do cliente e juntamente com o agente situado no servidor executam otimizac o es para reduc a o da quantidade de dados transmitidos na rede sem o, melhoram a seguranc a na transfer encia dos dados e sustentam a n ao interrupc a o da computac a o m ovel, entre outras poss veis atividades. A Figura 8, extra da de [Pitoura and Chrysanthis, 2000], apresenta este modelo.
7

Prefetching e um processo progressivo de transferir dados para a mem oria cache do host m ovel o mais

Link sem fio

Rede fixa

Aplicao Cliente

Agente
Cliente mvel

Aplicao Servidora

camadas Cliente/Agente-Cliente /Servidor Figura 7: O modelo em tres

Link sem fio

Rede fixa

Aplicao Cliente

Agente
Cliente mvel

Aplicao

Agente

Servidora

camadas Cliente/Agente-Agente /Servidor Figura 8: O modelo em tres

Este modelo e transparente tanto para o cliente como para o servidor. Conseq uentemente, o par de agentes pode ser empregado em v arias aplicac o es clientes. O protocolo de comunicac a o entre os dois agentes pode proporcionar uma alta eci encia na reduc a o (compress ao) dos dados e na otimizac a o de protocolos, sem limitar as funcionalidades ou interoperabilidade do cliente. A cooperac a o entre os dois agentes permite uma maior otimizac a o nos links sem o, beneciando diferentes aplicac o es. Al em disso, otimizac o es especicas para algumas aplicac o es podem ser efetivamente realizadas pelos agentes. Este modelo oferece exibilidade no manuseio da desconex ao. Por exemplo, a mem oria cache dos clientes m oveis pode ser mantida pelo seu agente. Esta mem oria pode ser usada para atender as necessidade e solicitac o es dos clientes durante o per odo de desconex ao. Na falta de mem oria cache, o agente pode enleirar solicitac o es para serem enviadas ao servidor quando da reconex ao. Similarmente, o agente situado no servidor pode acumular e transferir requisic o es do cliente, quando de uma nova reconex ao. A
cedo poss vel durante os per odos de baixo tr aco na rede. 8 Hoarding e um processo de carga antecipada dos dados para garantir a sobreviv encia do host m ovel durante a desconectividade que est a por vir.

fraca conectividade tamb em pode ser manuseada de varias formas, como por exemplo, por uma relocac a o computacional do agente do cliente ao agente do servidor ou viceversa. O retardo de gravac a o e disponibilidade de mem oria progressivamente ao cliente m ovel (prefetch) tamb em reduz a comunicac a o durante a o per odo de fraca conectividade ou nos momentos de inatividade da rede. Este modelo e apropriado para clientes m oveis com suciente poder computacional e que possua mem oria secund aria. O ponto fraco deste modelo e que cada aplicac a o necessita de trabalho de desenvolvimento tanto no servidor quanto no cliente. Por em, n ao e necess ario o desenvolvimento do par de agentes para cada nova aplicac a o. Construindo-se as funcionalidades e otimizac o es suciente mente gen ericas, somente ser a necess ario o desenvolvimento de pares de agentes diferentes para aplicac o es do tipo de acesso a um banco de dados, aplicac o es Web, etc. O Modelo Cliente/Agente-Agente/Servidor prov e uma clara distinc a o entre os agentes do cliente e do servidor, bem como divide a responsabilidade da execuc a o das tarefas necess arias ao ambiente de computac a o m ovel entre os mesmos. Um exemplo da aplicac a o deste modelo e apresentado em [Villate et al., 2000]. 2.4. O Modelo de Agentes M oveis Agentes M oveis s ao processo enviados de um computador fonte para realizar uma tarefa espec ca em outro computador. S ao processos que migram associados com um itiner ario (direc a o) e com uma distribuic a o din amica do seu c odigo e do seu estado. Ap os a sua submiss ao, o agente m ovel processa de forma aut onoma e independente de seu emissor. Quando alcanc a um cliente ou servidor, se integra a um ambiente de execuc a o de agentes. Possui a capacidade de se transportar para outro cliente ou servidor, gerando novos agentes ou interagindo com outros agentes. Quando conclu do, entrega seus resultados ao cliente ou servidor emissor ou a outro cliente ou servidor. A diferenc a entre os agentes m oveis e os agentes est aticos n ao e , entretanto, demasiadamente grande. Sistemas que empregam agentes m oveis, tamb em empregam agentes est aticos associados com seus ambientes computacionais. A forma de enviar os agentes m oveis para um outro ambiente para recolher as informac o es necess arias e an aloga a ` forma como um agente est atico emite um pedido declarativo a um outro agente, o qual contem a informac a o desejada. Um sistema que usa agentes m oveis requer um ambiente comum para execuc a o do agente durante toda a execuc a o do sistema ou o m nimo poss vel de compatibilidade para sua execuc a o [Kearney, 1998]. Al em de seus componentes computacionais, os agentes m oveis s ao equipados com intelig encia para reagir, tomar decis oes e resolver problemas. Alem desses aspectos, os fatores principais para o paradigma dos agentes m oveis s ao: Sua habilidade de interagir e cooperar com outros agentes; Sua autonomia, ou seja, sua capacidade de executar processos com pouca ou nenhuma intervenc a o com o seu emissor; Sua capacidade de interoperabilidade, possibilitando a sua execuc a o em diversas plataformas de software e hardware; Seu poder de reac a o, dando-lhe a habilidade de responder a eventos externos; Sua mobilidade, dando-lhe a capacidade de se movimentar pela rede de comunicac a o com e sem o;

Dois fatores principais motivam a utilizac a o dos agentes m oveis na computac a o m ovel. Em primeiro lugar, os agentes m oveis oferecem um m etodo ass ncrono eciente para procurar informac o es ou servic os, de forma r apida em uma rede. Clientes m oveis s ao lanc ados na rede e procuram em toda parte pela informac a o ou servic o desejado. Em segundo lugar, os agentes m oveis suportam a conectividade intermitente, as redes lentas e os equipamentos com poucos recursos. Este segundo fator torna a utilizac a o dos agentes m oveis muito atraente para a computac a o m ovel. Durante um per odo de desconex ao o cliente m ovel envia um agente m ovel para a rede xa e este agente age como um substituto da aplicac a o na rede xa, permitindo interac a o durante a desconex ao. De forma oposta, o agende m ovel e carregado no cliente m ovel, oriundo da rede xa, quando acontece uma nova conex ao. Quando em fraca conectividade, todo o tr afego de comunicac a o atrav es do link sem o reduz a possibilidade de submiss ao de um grande n umero de mensagens pelos agentes xos e na obtenc a o de seus resultados. Por este motivo, os agentes m oveis deslocam a carga de computac a o dos clientes m oveis, pobres em recursos, para a rede xa [Pitoura and Samaras, 1998]. Um dos principais obst aculos para a utilizac a o e aceitac a o dos agentes m oveis em aplicac o es comerciais e a sua seguranc a, como por exemplo, proteg e-los contra v rus.

o M 3. Os SGBDs e o ambiente da Computac a ovel

Entre os principais problemas do ambiente de computac a o m ovel que afetar ao diretamente as transac o ao as constantes desconexo es dos bancos de dados est es dos clientes m oveis de suas redes xas, a fraca conectividade das redes sem o, a mobilidade dos clientes m o o geogr aco e as constantes falhas veis por um amplo espac de recuperac a o es. Alguns desses aspectos ser ao discutidos nesta sec a o, com o das transac o objetivo de enfatizar a import ancia para a ger encia de dados dos SGBDs. es nos SGBDs Convencionais e Distribu 3.1. Transac o dos o fornece um mecanismo para descrever unidades l O conceito de transac a ogicas o e de processamento do banco de dados. Uma transac a uma unidade l ogica de processamento do banco de dados que inclui uma ou mais operac o es de acesso ao banco es podem incluir operac de dados. Essas transac o o es de inclusa ao, modicac a o, exclus o ou recuperac a o es do banco de dados que formam uma transac a o o de dados. As operac podem se embutidas dentro de um programa da aplicac a o ou podem ser especicadas de maneira interativa atrav es de uma linguagem de consulta de alto n vel como a SQL. Se o n as operac o es do banco de dados em uma transac a ao atualizarem o banco de dados, o e mas somente recuperarem dados, a transac a denominada como transac a o somente de leitura (read-only transaction). Para assegurar a integridade dos dados, o SGBD deve garantir as seguintes propriedades das transac o es, denominadas de propriedades ACID: Atomicidade - ou todas as operac o es da transac a ao reetidas corretamente no o s banco de dados ou nenhuma ser a; Consist encia - a execuc a o de uma transac a a o o isolada, ou seja, sem a execuc concorrente de outra transac a o, preserva a consist encia do banco de dados;

 Isolamento - embora diversas transac o es possam ser executadas de forma concorrente, o sistema garante que, para todo par de transac o es Ti e Tj , Ti tem a terminou sua execuc a o antes de Ti comec ar, ou que a sensac a o de que Tj j ou a sua execuc a o ap os Ti terminar. Assim, cada transac a o n ao toma Tj comec conhecimento de outras transac o es concorrentes no sistema; Durabilidade - depois da transac a o completar-se com sucesso, fazer seu commit, as mudanc as que ela fez no banco de dados persistem, at e mesmo se houver falhas no sistema. O acesso a diversos itens de dados em um sistema distribu do e normalmente acompanhado de transac o es que s ao obrigadas a preservar as propriedades ACID. Existem dois tipos de transac o es que devem ser consideradas nos sistemas distribu dos: as transac o o o ao aquelas que mant em es locais e as transac es globais. As transac es locais s acesso e atualizam somente ao banco de dados local. J a as transac o ao es globais s aquelas que mant em acesso e atualizam diversas bancos de dados locais. A garantia das propriedades ACID nas transac o bem mais complicada, uma vez que es globais e diversos sites podem participar de sua execuc a o. Maiores detalhes sobre as transac o es de banco de dados nos sistemas centralizados e distribu dos podem ser encontrados em [Elmasri and Navathe, 2000], [Elmasri and Navathe, 2002], [Silberschatz et al., 1997] e [Ozsu and Valduriez, 1999]. es no Ambiente de Computac o M 3.2. Processamento de Transac o a ovel Uma computac a o (um conjunto de instruc o es) que acessa dados compartilhados em um banco de dados e comumente estruturada como uma transac a omica, com o o at objetivo de preservar a consist encia dos dados na presenc a de concorr encia e falhas no sistema. Entretanto, uma computac a ovel que acessa dados compartilhados n ao pode o m ser estruturado usando uma transac a o at omica. Isto se d a porque transac o omicas es at assumem o pressuposto de executarem isoladas, o que impede as mesma de dividirem a sua computac a o e de compartilhar seus estados e resultados parciais. J a na computac a o m ovel, considerac o es pr aticas u nicas deste ambiente, exigem que as computac o es nos hosts m oveis sejam sustentadas e apoiadas por um host de suporte a mobilidade (estac a o de base), tanto para computac a o como para comunicac a o de dados. Isto signica que a computac a o m ovel precisa ser estruturada como um conjunto de transac o es, algumas que executam no host m ovel, enquanto outras executam no host de suporte a mobilidade [Chrysanthis, 1993]. Alem da necessidade da divis ao de suas transac o es, a computac a o m ovel tamb em est a 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 arios. Assim, uma outra exig encia que as transac o es at omicas n ao podem satisfazer e a sua habilidade de lidar com falhas parciais e prover diferentes estrat egias de recuperac a o, desta forma minimizando os efeitos das falhas [Chrysanthis, 1993]. Uma transac a ovel e a da, onde alguma parte da o m uma transac o distribu computac a ovel e outra parte em um host xo, n a ovel. O o e executada no host m o m uso do meio sem o e a mobilidade resultante dos consumidores e produtores de dados afetam o processamento das transac o es de v arias formas [Pitoura and Bhargava, 1994b].

O emprego de conex oes em o resulta em transac o es longas, em func a o dos longos atrasos da rede. Al em disso, transac o oveis envolvem sites que s ao intermitentemente es m conectados ao resto da rede. Por esta raz ao e que os usu arios de hosts m oveis evitam freq uentemente o uso dos meios sem o, uma vez que estas conex oes s ao caras, tanto monetariamente quanto em termos de poder de consumo dos hosts m oveis, ou porque os recursos da rede n ao est ao dispon veis na sua localizac a o geogr aca. Adicionalmente, para muitas tecnologias, como os modem celulares, h a uma alta carga inicial para cada comunicac a o. O custo efetivo da ger encia de transac a o para cada tecnologia pode adotar a abordagem do suporte a poucas transac o es longas ou inv es de muitas transac o es curtas. Finalmente, a computac a o m ovel e mais propensa a erros, em func a o das freq uentes desconex oes e serem mais suscet veis a acidentes do que os hosts xos. A mobilidade resulta em transac o es que acessam sistemas de informac o es heterog eneas. Alem disso, enquanto em projetos est aticos a localizac a o dos usu arios e xa, no ambiente m ovel mudam constantemente. Conseq uentemente, as transac o es m oveis acessam dados de posic a o (localizac a o) dos clientes que mudam rapidamente, em muitos casos em posic o es imprecisas. Finalmente, as transac o es podem envolver dados que est ao dinamicamente sendo mudados de lugar [Pitoura and Bhargava, 1994b]. Nos u ltimos anos, diversos modelos de transac o es foram propostos. Entre estes modelos tantos modelos podemos citar: o modelo de Transac o es Isolation-only, proposto por [Lu and Satyanarayanan, 1994]; o modelo Two-tier replication, proposto por [Gray et al., 1996]; o modelo Mobile Open Nested Transactions, proposto por [Chrysanthis, 1993]; o modelo Kangoroo, proposto por [Dunham et al., 1997]; o modelo de Clustering, proposto por [Pitoura and Bhargava, 1995, Pitoura and Bhargava, 1999]; o modelo Pro-motion, proposto por [Walborn and Chrysanthis, 1997]; o modelo Transaction Processing Agent - TXAgent, proposto por [Buchholz et al., 2000]; o modelo desenvolvido para o projeto Mobisnap, proposto por [Preguica et al., 2000]; o modelo desenvolvido para o projeto MDRTDBS, proposto por [Lam et al., 1999]. Uma comparac a o interessante de alguns destes modelos pode ser encontrada em [Serrano-Alvarado et al., 2001]. o de um Host M 3.3. Estados de Operac a ovel Em um sistema distribu do n ao m ovel as operac o es em seus hosts ou s ao totalmente conectadas ou totalmente desconectadas. J a no ambiente m ovel, existem v arios graus 9 de desconex ao que v ao desde a desconex ao total at e a fraca desconex ao . Como resultado desta caracter stica do ambiente m ovel, um host m ovel pode operar em v arios estados. Adicionalmente, para conservar bateria um host m ovel pode operar no estado cochilo (doze mode). A Figura 9, extra da de [Pitoura and Bhargava, 1994a] resume os diferentes estados de operac a o que um host pode se encontrar, Uma outra caracter stica dos estados de operac a o e que eles s ao previs veis. Enquanto nos ambientes distribu dos n ao m oveis esta caracter stica de desconex ao n ao existe, no ambiente m ovel a maioria das desconex oes podem ser detectadas. Assim sendo, um protocolo especial pode ser projetado para manusear a desconex ao. Al em disto, visto que as desconex oes s ao freq uentes, idealmente um host m ovel deve operar de forma aut onoma mesmo durante a desconex ao total.
9

Quando um terminal est a conectado ao resto da rede via uma pequena largura de banda.

Protocolo de Hand-off

Hand-off

Consideraes de energia

Totalmente Conectado
Recebimento de alguma mensagem

Largura de banda pequena

Protocolo de Parcialmente Desconexo

Protocolo de Recuperao

Modo de Cochilo (Doze)

Bateria ou falha

Parcialmente Conectado

Desconectado

Protocolo de Desconexo

de um Host Movel Figura 9: Estados de operac ao

Um host m ovel pode executar um protocolo de desconex ao antes de se desligar sicamente da rede. Este protocolo visa garantir a transfer encia suciente de dados para que o mesmo continue a operar durante o estado de desconex ao. Um host m ovel pode trocar seu estado de parcialmente conectado para executar no estado parcialmente desconectado. Enquanto permanecer neste estado, toda a comunicac a o com a rede deve ser limitada. Finalmente, enquanto um host m ovel esta operando em um modo ele pode entrar em uma nova c elula. Neste caso, toda a informac a o pertinente ao estado do host m ovel deve ser transferida a estac a o de base da nova c elula, atrav es da execuc a o de um protocolo de hand-off. es Desconectadas de um Host M 3.4. Estados de Operac o ovel Os hosts m oveis (ou clientes m oveis) s ao constantemente desconectados de suas redes de comunicac a o. Um host m ovel desconectado n ao pode enviar nem receber mensagens. Assim sendo, um host m ovel que se desconecte no meio da execuc a o de um processo (algoritmo), pode causar a suspens ao da tarefa em execuc a o at e a sua nova conex ao com a rede xa. Desconex ao no ambiente m ovel e diferente de falha, pois a mesma pode ser volunt aria ou involunt aria. As desconex oes s ao eleitas (elective). Assim sendo, um host m ovel pode informar ao sistema, a priori, uma iminente desconex ao, e ent ao executar um protocolo espec co para desconex ao. Desconex oes s ao constantemente esperadas, tornando-as uma caracter stica t pica do ambiente m ovel. Com a possibilidade de prever uma desconex ao, o host m ovel pode executar um protocolo de desconex ao antes do seu desligamento f sico da rede de comunicac a o [Badrinath et al., 1993]. Uma nova operac a o nos hosts m oveis com o objetivo de reduzir o consumo das baterias, principalmente em palmtops e laptops e o modo cochilo (doze mode).

Neste modo a velocidade do clock do processador e reduzida e nenhuma operac a o do usu ario e executada. O host m ovel simplesmente aguarda passivamente o recebimento de mensagens enviadas dos demais componentes da rede, retornando ao modo normal (de execuc a o) quando uma mensagem e recebida. Como na desconex ao, esta e uma operac a o volunt aria. Entretanto, as implicac o es s ao diferentes. No modo cochilo o host m ovel e alcanc a vel pelo resto do sistema, e assim, pode ser induzido pelo sistema a retomar o seu modo de operac a o norma. Diferentemente dos dois tipos de desconex oes, a conex ao com o sistema s o pode ser retomada somente pelo host m ovel [Badrinath et al., 1993]. A id eia por tr as do suporte as operac o es desconectadas e simples. Quando uma desconex ao e percebida antecipadamente, os itens de dados s ao transferidos para o cliente m ovel (host m ovel), para possibilitar a sua operac a o durante o per odo de desconex ao. A carga antecipada dos dados para garantir a sobreviv encia durante a desconectividade que est a por vir e chamada de hoarding. Segundo [Pitoura and Samaras, 1998] a desconex ao pode ser descrita como a transic a o entre tr es estados: 1. Carga Antecipada de Dados (Hoarding); 2. Operac o es Desconectadas; e 3. Reintegrac a o. A Figura 10, extra da de [Pitoura and Chrysanthis, 2000] resume os diferentes modos de operac a o que um host m ovel pode se encontrar.

Carga Antecipada de Dados (Hoarding)

Reintegrao

Operaes Desconectadas

Figura 10: Estados de Operac oes Desconectadas de um Host Movel

3.4.1. Carga Antecipada de Dados Antes da desconex ao o host m ovel est a no estado de Carga Antecipada de Dados (Hoarding). Neste estado os itens de dados necess arios para operac a o s ao carregados na unidade m ovel. Os itens podem ser simplesmente realocados (mudados de enderec o) ou movimentados do host xo para a unidade m ovel. Entretanto, fazendo assim, esses itens de dados se tornar ao inacess veis para outros sites. Como alternativa, os itens de dados podem ser replicados ou mantidos na mem oria cache da unidade m ovel. O tipo de dados transferidos para o host m ovel depende da aplicac a o e do modelo de dados que o sustenta. Por exemplo, no caso de sistemas de arquivos os dados podem ser arquivos, diret orios ou volumes de disco. No caso de SGBDs, os dados podem ser relac o es ou vis oes. No caso de sistemas de browsing na web os dados podem ser p aginas. No caso do modelo de objetos os objetos de dados podem carregar com eles informac o es adicionais, tais como o conjunto de operac o es permitidas. No caso do modelo baseado em agentes mo veis, os agentes podem ser transmitidos ao longo da rede para serem executados no cliente m ovel. Para desconex oes previs veis, como por exemplo, a motivada pela entrada do cliente em uma regi ao fora da sua a rea original de cobertura, e portanto nanceiramente mais cara, os dados podem ser carregados imediatamente antes da desconex ao [Pitoura and Samaras, 1998]. Uma quest ao complicada quando um cliente m ovel est a neste estado e como antecipar suas necessidades futuras de dados. Uma abordagem simplista e permitir que o usu ario especique explicitamente que itens de dados necessita carregar para suas aplicac o es. Uma outra abordagem e usar as informac o es sobre o hist orico dos acessos aos dados para predizer a prov avel necessidade futura dos dados. Que dados carregar depende tamb em da aplicac a o que o sistema ir a usar. Por exemplo, pode precisar de arquivos para um processador de texto ou uma tabela atualizada de prec os. Al em das quest oes anteriores, uma outra quest ao complexa para a carga antecipada dos dados ocorre quando os dados carregados s ao compartilhados por v arios clientes ou sites que necessitam continuar acessando e modicando os dados com o host m ovel desconectado. Assim, avaliando a probabilidade de operac o es conitantes quando se decide que itens de dados carregar antecipadamente pode-se melhorar a efetividade das operac o es desconectadas. Em [Saygn et al., 2001] existe uma abordagem muito interessante para especicac a o da carga antecipada de dados, utilizando-se uma t ecnica de minerac a o de dados (data mining) chamada de regras de associac a o.

es Desconectadas 3.4.2. Operac o Quando acontece uma ruptura de conex ao com a rede xa a unidade m ovel entra no estado de desconex ao. Enquanto estiver neste estado, somente pode usar dados locais. Solicitac o es de dados que n ao est ao localmente dispon veis n ao podem ser atendidas e retornam com indicac a o de erro. Estas pend encias podem ser organizadas em uma la para serem atendidas quando ocorrer a ` pr oxima conex ao. Aplicac o es com solicitac o es de dados n ao atendidas tamb em podem suspender sua execuc a o ou continuar trabalhando em outro processamento que n ao dependa dos dados solicitados. Existem duas abordagens para reparar as atualizac o es dos dados compartilhados.

A abordagem pessimista e a abordagem otimista. Na abordagem pessimista as atualizac o es s ao executadas somente em um site utilizando bloqueio (lock) ou alguma forma de vericac a o dos dados de entrada e sa da (check-in/check-out). Na abordagem otimista as atualizac o es s ao permitidas em mais de um site com a possibilidade perigosa de conito nas operac o es. As atualizac o es nas unidades m oveis s ao registradas (logged ) na mem oria est avel do cliente. As informac o es s ao armazenadas no log (di a rio) do sistema. O tipo de informac a o afeta a ec acia da reintegrac a o das atualizac o es quando da reconex ao, assim como a ec acia da otimizac a o do log. A otimizac a o do log, mantendo-o em um pequeno tamanho, e muito importante pois este logo e armazenado na mem oria do cliente m ovel e reduz o seu tempo para propagac a o das atualizac o es e reintegrac a o durante a reconex ao. Operac o es de otimizac a o no log podem ser realizadas durante as operac o es quando a unidade m ovel est a desconectada, incrementalmente cada vez que uma nova operac a o e inserida no log ou como um passo de pr e-processamento antes da propagac a o ou aplicando o log na pr oxima reconex ao [Pitoura and Samaras, 1998]. o 3.4.3. Reintegrac a Quando acontece uma nova conex ao com a rede xa a unidade m ovel entra no estado de reintegrac a o es do host m ovel s ao reintegradas com as o. Neste estado, as atualizac atualizac o es de outros sites , re-executando o seu log no host xo. Quest oes referentes a concorr encia e seriac a o das transac o es s ao efetivadas em func a o de cada sistema em particular, visando resolver o problema da atualizac a o sobre o mesmo objeto. A tabela 2, extra da de [Pitoura and Samaras, 1998], apresenta os principais problemas e quest oes relacionadas ao estado de desconex ao de uma unidade m ovel.

3.4.4. Desconex ao e os SGBDs Existem muitos problemas que permanecem abertos quanto a quest ao da carga de dados antecipada (hoarding) em banco de dados. A primeira quest ao em aberto e determinar qual deve ser a granularidade dos dados para a carga antecipada. Por exemplo, no caso dos SGBDs relacionais vai desde uma tupla, um conjunto de tuplas ou toda uma relac a o. Uma abordagem l ogica seria carregar os dados em func a o das consultas realizadas, por exemplo, carregando antecipadamente de forma progressiva (prefetching) apenas os dados que constituem a resposta a uma dada pergunta. Isso corresponde a carregar na unidade m ovel uma vis ao materializada. Uma outra quest ao e como decidir que dados carregar. Em termos de vis oes, signica identicar as vis oes materializadas ou como especicar as consultas para as cargas que denem as vis oes. Usu arios podem explicitamente especicar quais as consultas para a carga antecipada. Uma outra alternativa, e pela avaliac a o do comportamento das consultas anteriormente realizadas, para que o pr oprio sistema tente identicar futuras prov aveis necessidades dos usu arios. Em ambos os casos o sistema carregaria automaticamente o conjunto de dados mais comumente usado ou por u ltimo referenciado nas consultas dos usu arios. Existem algumas particularidades que se deve considerar quando se rever o problema de ruptura (partic a o, divis ao) das redes, particularmente na identicac a o do

Estado

Abordagens Depende do sistema Unidade de carga (por exemplo, arquivos ou) fragmentos de BD) - Especicado pelo usu ario - Usar as informac o es sobre o Que itens carregar ? hist orico dos acessos aos dados Hoarding - Depende na aplicac a o para que o sistema e usado Quando executar a carga dos dados ? - Antes da Desconex ao - Em uma base regular Solicitac a o para dados - Retorna uma excec a o/erro n ao dispon veis localmente - Solicita uma la para futuros servic os - Valores dos dados O que por no LOG ? - Timestamps - Operac o es Desconex ao Quando otimizar o LOG ? - Nas operac o es locais (incrementac a o) - Antes da integrac a o Como otimizar o LOG Depende do sistema Como integrar ? Reexecutando as operac o es do LOG Reintegrac a o - Usar sem antica das aplicac o es Como resolver os conitos ? - Soluc o es autom aticas - Ferramentas para ajudar ao usu ario
relacionadas ao estado de deconexao Tabela 2: Principais problemas e questoes de uma unidade movel

Problemas e Questo es

local ideal para se executar algum processo para a computac a o m ovel. As transac o es de banco de dados executadas em um sistema distribu do s ao de igual import ancia, de mesmo n vel, seja ela executada no servidor ou no cliente distribu do. Na computac a o m ovel, entretanto, as transac o es executadas nos host m oveis s ao freq uentemente consideradas de segunda classe. Uma outra quest ao e a freq ue ncia da desconex ao na computac a o m ovel. A ruptura da rede corresponde a um comportamento de falha, visto que desconex oes s ao comuns na computac a o m ovel. Somente este fato j a justica a construc a o de sistemas para tratar as transac o es de banco de dados. Finalmente, muitas desconex oes na computac a o m ovel podem ser consideradas previs veis [Pitoura and Samaras, 1998]. Uma tend encia comum e fazer o (commit) da transac a o de forma tempor aria na unidade m ovel, fazendo com que seus resultados sejam vis veis apenas para uma pr oxima transac a o na mesma unidade m ovel. Por exemplo, um vendedor de bebidas pode ter carregado em seu host m ovel um valor de estoque para cada bebida e a cada venda realizada esta quantidade e atualizada, neste caso, diminuindo a sua quantidade dispon vel para venda para este vendedor. Na reconex ao, ocorre um processo de certicac a o, durante o qual toda transac a o temporariamente conrmada (committed ) no host m ovel e validada contra uma aplicac a o ou por um crit erio de exatid ao denido pelo sistema. Se o crit erio for satisfeito, ent ao a transac a o e conrmada. Por exemplo, o crit erio no nosso exemplo anterior, poderia ser existir bebidas em estoque para entrega no prazo combinado

entre o vendedor e o comprador, uma vez que o estoque total da empresa e fornecido diariamente a todos os vendedores. Caso o crit erio n ao seja satisfeito, a transac a o deve ser cancelada, reconciliada ou compensada. Isto realmente se torna um problema, pois estas ac o es podem ter efeito em cascata sobre as transac o es temporariamente conrmadas no host m ovel. Para resolver este problema [Lu and Satyanarayanan, 1994] e [Lu and Satyanarayanan, 1995] introduziram o conceito de transac o es Isolation-only (IOTs) e [Gray et al., 1996] o conceito de transac o es no esquema de Two-tier Replication para computac a o m ovel. 3.5. Fraca Conectividade Fraca conectividade e a conectividade fornecida por redes de comunicac a o de dados lentas e ou monetariamente caras para seu usu ario. Alem disso, a conectividade nessas redes s ao oferecidas em pequenos per odos de tempo. A fraca conectividade causa v arias limitac o es que n ao est ao presentes quando a conectividade e normal e estimula a revis ao de v arios protocolos. Uma caracter stica adicional da fraca conectividade na computac a o m ovel e a variac a o de sua intensidade. Conectividade em computac a o m ovel varia no custo, fornece largura de banda e seguranc a/conanc a. Muitas propostas para tratamento da fraca conectividade examinam estas caracter sticas e fornecem suporte para operac o es que se adaptam ao corrente grau de conectividade. Neste sistemas, operac o es desconectadas s ao exatamente a forma de operac a o no extremo total da falta conectividade. O objetivo da maioria das propostas para tratamento da fraca conectividade e a prud encia no uso da largura de banda. Elas aceitam trocar a conanc a (exatid ao) do dado transmitido pela a reduc a o dos custos na comunicac a o [Pitoura and Samaras, 1998]. 3.6. Fraca Conectividade e os SGBDs Abordagens para tratar a fraca conectividade em SGBDs objetivam minimizar a comunicac a o e sobreviver a pequenas desconex oes. Entretanto, devido a ` complicada depend encia entre os itens de dados do banco de dados, o problema e complexo. Um host m ovel pode desempenhar v arios pap eis em sua ambientac a o em um banco de dados distribu do. Por exemplo, ele pode simplesmente submeter operac o es para serem executadas em um servidor ou para um agente residentes na rede xa. Uma abordagem diferente no papel do host m ovel e reservada ao processamento local no mesmo. Assim, e necess ario permitir operac o es aut onomas durante a desconex ao, por em, complicando a ger encia dos dados e podendo causar um inaceit avel aumento no tempo de processamento (overhead ) na comunicac a o. Colocando os dados no host m ovel causa novos problemas no projeto f sico do banco de dados. Tais problemas incluem, entre outros, como fragmentar de forma apropriada o banco de dados e como alocar os fragmentos no host m ovel e xo. Quando o fragmento e alocado ele pode, tamb em, ser replicado em alguns sites, ou em todos os sites ou mantido como uma u nica c opia. Em geral, manter os dados como uma u nica c opia dos dados no host m ovel n ao e apropriada em func a o da disponibilidade e seguranc a dos mesmos [Pitoura and Samaras, 1998]. O controle de concorr encia nos casos de transac o es que envolvem tanto host m oveis quanto xos e complicado. Para transac o es que acessam dados tanto nos hosts m oveis quanto nos xos via conex oes sem o, certamente, ir ao impor um maior overheads. Por exemplo, no caso do protocolo de controle de concorr encia pessimista

que requer que a transac a o adquira bloqueios (locks) em v arios sites, as transac o es podem bloquear se pedirem bloqueios em sites que est ao desconectados ou pedirem bloqueios a sites bloqueados por transac o es desconectadas. Por outro lado, t ecnicas tais como (timestamps) podem levar a um grande n umero de transac o es canceladas (abortadas) em func a o da lentid ao das operac o es na rede. Para evitar os atrasos pela lentid ao das conex oes sem o, um modelo de transac o es chamado de Mobile Open Nested Transactions foi proposto por [Chrysanthis, 1993]. 3.7. Mobilidade Um sistema distribu do que inclua elementos m oveis e dito din amico. Unidades m oveis se comunicam diretamente com diferentes estac o es de base, como tamb em se movimentam dentro e para fora de sua a rea, em uma nova c elula. A mobilidade tamb em signica que os clientes se movem e executam atividades de leitura/gravac a o para realizar suas funcionalidades. Por esta raz ao, tamb em alguns dados ou algumas tarefas precisam se movimentar juntamente com as unidades m oveis, principalmente, por quest oes de performance. Tamb em, muitos sites se tornam indispon veis durante a desconex ao. Al em disso, o custo da comunicac a o na computac a o m ovel e diferente do custo da computac a o xa. Primeiramente porque existe a necessidade de se determinar exatamente a ` localizac a o do host m ovel e segundo porque pode ser baseado na durac a o da conex ao e n ao no n umero das mensagens enviadas. Assim, os algoritmos para distribuic a o de dados e tarefas dos sistemas distribu dos precisam ser revisados para a computac a o m ovel. Muitos par ametros se modicam com o tempo no ambiente da computac a o m ovel. Assim sendo, deixar os dados localizados em locais xos pode n ao ser apropriado. Em [Huang and Wolfson, 1994] e feita uma distinc a o entre os custos de replicac a o na computac a o xa e na computac a o m ovel, baseado no pressuposto de que na computac a o m ovel, o custo de entrada/sa da (input/output) de dados se torna insignicante, em func a o da carga da comunicac a o sem o. Tamb em e introduzido um algoritmo de alocac a o din amica de dados que tem a propriedade de sempre que um processador l e uma c opia, salva essa c opia em um banco de dados local. Ent ao, este algoritmo din amico e comparado ao esquema de alocac a o est atica e demonstra ser superior. Em [Huang et al., 1994] e estudado o caso em que computadores m oveis acessam dados de forma on-line em hosts xos. O problema discutido e se e ben eco, em termos de custo de comunicac a o, guardar uma c opia dos dados localmente no host m ovel. Intuitivamente, guardar uma c opia local e apropriado para itens de dados que s ao freq uentemente lidos, quando comparados com a sua taxa de gravac a o. o 3.8. Falhas de Recuperac a Recuperac a o em ambiente m ovel tem se concentrado em gravar checkpoints (pontos de vericac a o) de consist encia global de uma aplicac a o distribu da m ovel. O processamento de recuperac a o para transac o es m oveis dentro do contexto desses algoritmos de checkpoints n ao est ao ainda bem amadurecidos. As caracter sticas do ambiente m ovel e sem o que s ao levados em considerac a o na denic a o dos esquemas de checkpoints s ao as seguinte: A mobilidade dos hosts m o elula para c elula, em que o problema e veis de c encontrar o melhor lugar para armazenar o pr oximo local do checkpoints;

 A disponibilidade de armazenamento est a ovel, que determina o grau vel no host m de participac a o do host m ovel no processo de checkpoints; A largura de banda, que juntamente com a disponibilidade de armazenamento est avel, rena a participac a o do host m ovel no checkpoints e afeta a freq ue ncia em fazer o checkpoints. 3.8.1. Checkpoints no ambiente M ovel Em sistemas distribu dos, a recuperac a o de falhas e baseada nos protocolos de checkpoints. Esses protocolos periodicamente armazenam o estado da aplicac a o em armazenamento est avel (seguro). Ap os uma falha, a aplicac a o usa esses checkpoints para desfazer (roll back) at eou ltimo ponto salvo e reiniciar a execuc a o. Um estado global e armazenado e usado pelo protocolo para recuperar a aplicac a o. O estado global inclui o estado de cada processo participante na aplicac a o distribu da e possivelmente muitas mensagens. Para uma correta recuperac a o, o protocolo deve conservar recuper avel o estado global da aplicac a o. Maiores detalhes sobre protocolos em sistemas distribu dos podem ser encontrados em [Ozsu and Valduriez, 1999]. Em [Acharya and Badrinath, 1994] um checkpoint global e denido como um checkpoint local consistente para cada host m ovel/processo participante na aplicac a o. Considerando que estamos lidando com hosts m oveis que enviam e recebem mensagens, [Ssu et al., 1998] traduziu nas seguintes condic o es de recuperac a o e consist encia: Consist encia: Um checkpoint global e consistente se as seguintes condic o es s ao satisfeitas: para cada mensagem m, se o recebedor da mensagem (m) e inclu do no checkpoint global, ent ao o emissor da mensagem (m) tamb em e inclu do no checkpoints global. Recuperabilidade: Para evitar a perda de mensagens em tr ansito que foram enviadas, por em, n ao recebidas por nenhum outro processo, se o checkpoint global conter o emissor da mensagem (m), mas n ao conter o recebedor da mensagem (m), ent ao o protocolo de checkpoint deve salvar a mensagem (m) tamb em. Os algoritmos de checkpointing s ao classicados em duas categorias: coordenados e n ao-coordenados. Os protocolos coordenados necessitam que cada participante coordene seus checkpoints locais para garantir a recuperac a o e consist encia do checkpoint global. Os protocolos n a o-coordenados, por sua vez, permitem aos participantes checkpoints independentes em seu estado local. Durante a recuperac a o, um esforc o de coordenac a o e necess ario para selecionar um checkpoint para cada participante criar o checkpoint global consistente. Devido a ` mobilidade, pequena largura de banda e desconex oes, ambos os tipos de protocolos, em sua forma original, s ao inadequados para a computac a o m ovel. Protocolos coordenados requerem controle de mensagens enviadas a diferentes hosts m oveis para sincronizar o processo de checkpointing. Isto envolve um custo de pesquisa para encontrar a localizac a o do host m ovel. O processo pode ser ainda mais complicado, pois o host m ovel pode se movimentar para outra c elula antes do processo de checkpointing ter sido conclu do. Os esquemas coordenados tamb em s ao afetados pela desconex ao. Durante a desconex ao, os checkpoint locais dos hosts m oveis cam inacess veis para o

algoritmo de sincronismo do checkpointing, tornando assim a execuc a o problem atica. Protocolos n ao-coordenados permite aos participantes m oveis o estado de checkpointing sem troca de mensagens. Isto e adequado para o ambiente m ovel porque permite que o processo de checkpointing continue durante a desconex ao. Entretanto, mensagens necessitam ser trocadas durante a recuperac a o para encontrar o checkpointing global ou pegar informac o es sobre outros participantes [Pitoura and Samaras, 1998]. 3.8.2. Protocolos de Checkpoints M oveis Um pequeno n umero de adaptac o es para os protocolos de checkpointing coordenados e n ao-coordenados tem sido desenvolvidos para manusear as limitac o es do ambiente de computac a o m ovel. Estes protocolos podem ser classicados baseados no seu grau de adaptabilidade e se os armazenamentos est aveis s ao considerados um lugar relativamente seguro para armazenar o estado local da aplicac a o. Assim sendo, os checkpointing s ao classicados como soft ou hard baseados nos tipos de falhas que podem ocorrer. falhas soft s ao aquelas que n ao causam danos permanentes aos host m oveis, como por exemplo descarga de bateria ou problemas no sistema operacional. J a as Falhas hard s ao aquelas que causam danos permanentes aos host m oveis. Falhas hard s ao manuseadas pelo chamado checkpoint hard que s ao armazenados na rede xa, enquanto as falhas soft s ao distribu das por um chamado checkpoint soft que s ao armazenados localmente no host m ovel. Checkpoints armazenados localmente, s ao f aceis de serem criados e sobretudo, permite que o host m ovel continue funcionando durante a desconex ao [Pitoura and Samaras, 1998]. A tabela 3, extra da de [Pitoura and Samaras, 1998] apresenta caracter sticas desejadas dos grupos de protocolos em torno do grau de conectividade. Conectado Desconectado Tipo de Login Imediato ou peri odico Peri odico Raz ao do Checkpoints hard = sof t Somente soft Tipo de Coordenac a o Coordenado ou N ao-coordenado n ao-coordenado Clientes com Equilibrado Maximizado poucos recursos ou minimizado o uso do cliente (armazenamento o uso do cliente (somente mem oria est avel inseguro) do cliente) Clientes com Equilibrado ou Maximizado muitos recursos maximizado o uso do cliente (armazenamento o uso do cliente (somente mem oria est avel seguro) do cliente)
Tabela 3: Conectividade e Checkpointing

Fraca Conectividade Peri odico sof t > hard N ao-coordenado Maximizado o uso do cliente

Maximizado o uso do cliente

Entre os trabalhos de destaque podemos citar [Acharya and Badrinath, 1994] e [Pradhan et al., 1996], os quais apresentam tr es protocolos n ao-coordenados que consideram os armazenamento em disco dos hosts m oveis como inst aveis e

conseq uentemente inapropriados para armazenar o estado de um participante. [Ssu et al., 1998] e [Prakash and Sihghal, 1996], entretanto, assumem que os Hosts m oveis tem um armazenamento est avel relativamente seguro e assim podem participar no processo de checkpoint como um host xo.

4. Ger encia de Dados M oveis

Esta sec a o est a focada nas t ecnicas de ger encia de informac a o e recuperac a o em sistemas m oveis. Destaca-se a import ancia das t ecnicas de Disseminac a ao de Dados o ou Difus (Broadcast) como meio de entregar a informac a o aos hosts m oveis e o impacto da computac a o m ovel na ger encia de consultas. A maioria das tecnologias sem o suportam a disseminac a o de dados broadcast para todos os elementos m oveis que est ao em uma c elula. No modelo cliente/servidor, o servidor ou o agente localizado na estac a o de base pode tirar vantagem desta caracter stica para disseminar informac o es para todos os clientes de sua c elula. Assim, e estabelecida uma nova forma de enviar dados aos clientes, diferente da forma tradicional de envio de dados somente por solicitac a o (sob demanda) dos clientes. A Figura 11, apresenta uma arquitetura gen erica para utilizac a o da t ecnica de broadcast.

Cliente Mvel

Cliente Mvel

Servidor de Broadcast

Cliente Mvel Cliente Mvel

Rede cabeada de alta velocidade

Servidor de Banco de Dados

Banco de Dados

da tecnica Figura 11: Arquitetura generica para utilizac ao de broadcast

A ger encia de consultas para a computac a o m ovel deve tratar de forma eciente consultas que envolvem a localizac a o do usu ario m ovel. A localizac a o do usu ario m ovel introduz v arios novos problemas referentes ao armazenamento e atualizac a o desta informac a o. A ger encia de consulta tamb em deve trabalhar com os recursos limitados dos hosts m oveis, nos quais destacam-se o pequeno tamanho de sua tela, o escasso poder de

suas baterias, o longo per odo de desconex ao dos clientes, as transac o es longas de banco de dados, o pouco recurso de mem oria, entre outros [Brayner and Monteiro, 2000]. o ou Difus 4.1. Disseminac a ao de Dados (Broadcast) No modelo cliente/servidor tradicional, os dados s ao enviados para o cliente somente sob demanda, ou seja, atendendo a uma solicitac a o do cliente. O servidor recebe a solicitac a o, processa-a e retorna ao cliente a informac a o solicitada. Esta forma de entrega dos dados e chamada de pull-based (puxar/buscar na base). Na computac a o sem o, os servidores xos s ao providos de canais com relativa largura de banda que suportam a entrega dos dados por broadcast ao clientes m oveis em suas c elulas. Esta facilidade de infra-estrutura propiciou a uma nova forma de entrega de dados chamada push-based, que consiste do servidor, repetitivamente, disseminar dados ao universo de clientes sem uma solicitac a o espec ca por parte dos clientes. Os pr oprios clientes monitoram a difus ao dos dados (broadcast) e recuperam os itens de dados que eles precisam, da forma como eles chegam na transmiss ao. A Figura 12, extra da de [Pitoura and Chrysanthis, 2000], apresenta a forma de broadcast push-based.

G A

E D

..
Servidor

Cliente

Figura 12: Forma de broadcast push-based

A entrega de dados na forma broadcast push-based (impulsionada pela base) e extremamente importante para um grande conjunto de aplicac o es que necessitam disseminar informac o es para um grande n umero de clientes. Entre estas aplicac o es podemos citar as aplicac o es comunicados de emerg encia a policiais de uma determinada a rea, controle de tr afego de autom oveis, informac o es sobre as condic o es de tempo, renovac a o e novas cotas de estoques de vendedores, entre outras. A id eia da entrega de dados pela t ecnica de broadcast n ao e nova, os primeiros trabalhos s ao origin arios das tecnologias de Tele-Texto e V deo-Texto. Recentemente o broadcast ganhou mais atenc a o nos sistemas sem o, devido ao suporte f sico para broadcast tanto nas redes de celulares como nas redes de sat elites. Nas redes de celulares constantemente recebemos comunicados das operadoras com ofertas, ou mesmo os chamados torpedos coletivos. A entrega dos dados na forma de broadcast push-based (impulsionada pela base) e apropriada para os casos em que a informac a o precisa ser transmitida para um grande n umero de clientes que possuem interesses comuns. Neste caso, os servidores guardam

diversas mensagens que nos sistemas com a forma de entrega dos dados pull-based teriam que envi a-las individualmente. Al em disso, o servidor e impedido de ser bombardeado por in umeras solicitac o es dos clientes. A entrega de dados na forma push-based e escal avel em seu desempenho, pois n ao depende do numero de clientes ouvindo os canais de broadcast. Por outro lado, a entrega dos dados na forma pull-based n ao pode ser escal avel al em da capacidade do servidor ou da rede. Uma limitac a o na entregada de dados em broadcast e que o acesso e somente seq uencial. Os clientes precisam esperar at e que a solicitac a o de dados esteja (aparec a) no canal de comunicac a o para ent ao peg a-la. Assim, a lat encia10 degrada com o volume de dados existente no broadcast, que e compat vel com o tamanho do banco de dados. Na forma de entrega pull-based, os clientes podem ter um papel mais ativo e explicitamente solicitarem seus dados ao servidor. As formas de entrega pull-based e push-based podem ser combinadas, considerando os sistemas em que al em do canal de broadcast, os clientes possuem um canal de alta velocidade (uplink) para comunicac a o com o servidor, tamb em chamado de backchannel, no qual os usu arios enviam suas mensagens. Esta abordagem e tamb em conhecida como entregada de dados h brida. Uma caracter stica importante desta abordagem, est a no fato de que se o mesmo canal do servidor at e os clientes e usado para as duas formas de broadcast e tamb em para transmiss ao de respostas as consultas sob demanda dos clientes, ent ao existe a necessidade do uso de t ecnicas para um eciente compartilhamento do canal de comunicac a o. Os clientes podem usar o backchannel de v arias formas, como por exemplo, para solicitar dados diretamente ao servidor, como no casos em que os dados requerem sigilo e portanto n ao podem aparecer no canal de broadcast. A Figura 13, extra da de [Pitoura and Chrysanthis, 2000], apresenta a forma de broadcast com a combinac o es das formas push-based e pull-based, na qual existe um compartilhamento de canal [Pitoura and Samaras, 1998].

G A

E D C

..
Servidor

Cliente
14.4 Kbps

Figura 13: Forma de broadcast com as combinac oes push-based e pull-based

Em vez de broadcasting de todos itens de dados do banco de dados, um caminho para realizar a entrega dos dados na forma h brida e particionar os itens de dados em
10 Per odo de inatividade entre um est mulo e a resposta por ele provocada, neste caso entre uma solicitac a o ao servidor e sua resposta.

dois conjuntos: um para ser usado nas transmiss oes de broadcasting e o outro para ser disponibilizado por demanda dos clientes. Determinar que subconjunto de dados poder a ser transmitido via broadcasting e uma tarefa complicada, uma vez que esta decis ao depende de muitos fatores, incluindo o padr ao de acesso dos clientes e a capacidade dos servidores de atender aos servic os por demanda dos clientes. A mobilidade dos usu arios tamb em e um fator cr tico na determinac a o de que conjunto de dados selecionar para o broadcast. As c elulas podem diferir em seus tipos de estrutura de comunicac o es, e assim, em sua capacidade de prestac a o de servic os as solicitac o es dos servidores. Al em disso, como os usu arios est ao em constantes movimentos entre as c elulas, a distribuic a o das solicitac o es para um especif co conjunto de dados muda em cada c elula. Em [Datta et al., 1997] s ao apresentadas duas variac o es adapt aveis de um algoritmo que leva em conta a mobilidade dos usu arios entre as c elulas. Este algoritmo seleciona estatisticamente os dados do broadcast em func a o do perl e registros dos usu arios em cada c elula. 4.2. Uso de Caches em Broadcast O armazenamento de dados na mem oria dos hosts m oveis (caching) pode ser desenvolvido junto com o broadcast nos sistemas de bases para disseminac a o (textitbroadcast-based systems). Clientes podem colocar em sua mem oria cache itens de dados para diminuir a sua depend encia com a escolha do servidor sobre que itens de dados priorizar para o broadcast. Esta prioridade de escolha do servidor pode n ao ser o tima para um cliente espec co, uma vez que o servidor pode basear sua prioridade de escolha na freq ue ncia m edia dos itens de dados dos broadcast anteriores, os quais cobriram uma populac a o de clientes com necessidades diferentes. Al em disso, as necessidades de um cliente podem se modicar ao longo do tempo. Em alguns casos, o armazenamento de itens de dados na mem oria cache reduzem a expectativa de atraso para acesso a esses dados. Em um outro contexto, o broadcast pode ser usado para propagar atualizac o es de dados na mem oria cache em alguns sistemas cliente/servidor, independentemente de ser a transmiss ao, na entrega dos dados, sob demanda, ou uma combinac a o das duas formas de broadcast, push-based e pull-based. Pol ticas de substituic a egias para substituir os itens de o especicam as estrat dados na mem oria cache dos hosts m oveis. Nos sistemas de ger encia de cache tradicionais, os clientes armazenam na mem oria cache seus dados mais importantes para melhorar a taxa de acesso aos mesmos. Em geral, em tais sistemas, o custo de obtenc a o de uma p agina11 perdida na mem oria cache e considerado constante, e assim n ao e contabilizado durante a substituic a o (troca) da p agina. Entretanto, nos sistemas de broadcast, o custo da prestac a o de servic os de manutenc a o de uma p agina em falta depende de quando a p agina solicitada ir a aparecer no pr oximo broadcast. Assim sendo, [Acharya et al., 1995a] e [Acharya et al., 1995b] criaram o custo b asico de substituic a o de p agina, onde o custo de se obter uma p agina ausente na mem oria cache deve levar em considerac a o a decis ao de que p agina substituir. Um cliente pode disponibilizar (reservar) p aginas (prefetch) em sua mem oria cache prevendo acessos futuros. Usando prefetching ao inv es de substituic a o de p agina, pode-se reduzir o custo da aus encia de um conjunto de dados em uma p agina. Diversas
11

Parte da RAM de tamanho xo.

estrat egicas para prefetching podem ser usadas. Usando-se a heur stica de reserva PT de prefetching, busca-se decidir se a p agina corrente transmitida e mais valiosa que alguma outra p agina que j a est a na mem oria cache. Esta heur stica calcula a probabilidade de acesso (P) multiplicada pelo tempo (T ), que e o tempo decorrido antes que a p agina aparec a de novo no broadcast. Com este valor, uma p agina transmitida substitui na mem oria cache a p agina com o menor valor de PT [Acharya et al., 1995a]. o (posic o) dos Clientes 4.3. Consulta aos Dados de Localizac a a A ger encia de consultas que envolve objetos que se movem e um problema desaador, uma vez que os dados de localizac a o (posic a o) de um cliente m ovel, seu contexto, pode mudar rapidamente. Assim, o resultado da consulta pode depender tanto da localizac a o do usu ario quanto do tempo para este usu ario chegar a um outro local. Por exemplo, em cliente gostaria de saber se, em func a o da sua posic a o, ele est a perto de um determinado prestador de servic o ou se o tempo at e que ele possa chegar a este prestador de servic o e menor do que uma hora. Consultas podem n ao diretamente incluir a localizac a o, mas podem solicitar seguir ao encalce (tracking) de objetos m oveis. Por exemplo, consultas que envolvem a produc a o de dados e a localizac a o dos hosts m oveis, como e o caso de um grupo de vendedores de produtos aliment cios consultando e atualizando os seus estoques em um servidor localizado na rede xa. Consultas de posic a o podem ser impostas tanto por usu arios m oveis ou est aticos e podem incluir bancos de dados localizados tanto em sites m oveis ou est aticos. Consultas de localizac a o podem incluir dados transientes, que s ao dados nos quais seus valores mudam enquanto a consulta estar sendo processada. Por exemplo, um usu ario em movimento querendo saber o quanto ele est a pr oximo de um hospital. Outro tipo poss vel de consulta de localizac a o s ao as cont nuas consultas . Por exemplo, uma ambul ancia em movimento perguntando por um local de um acidente em um raio de 5 quil ometros e solicitando que a resposta a esta consulta seja continuamente atualizada. A posic a o (localizac a sica atual de um usu ario em movimento muda o) f rapidamente. Controlar o volume das atualizac o es da posic a o, atualizando a posic a o armazenada de um usu ario em movimento pode ser demorada. Uma outra forma para reduzir o tr aco de atualizac o es e a manutenc a o de informac o es aproximadas da posic a o, especicando, por exemplo, somente a zona ou partic a o onde o usu ario reside naquele momento. Neste caso, para responder a posic a o, um processamento extra ser a necess ario para calcular a exata posic a o do usu ario. Entretanto, em uma variedade de consultas de posic a o, conhecer a exata posic a o de alguns usu arios pode n ao ser necess ario. Assim, um novo problema que aparece no processamento de consultas e como obter um plano de execuc a a o, que adquirir a somente esta o da consulta o timo para a consulta da posic informac a o faltante para esta resposta. Na pr oxima sec a o a ger encia de localizac a a o ser tratada com mais detalhes. o 4.4. Novos requisitos e funcionalidades para a ger encia de informac a Al em dos itens citados anteriormente nesta sec a o, tamb em s ao necess arios para a ger encia de informac o es a textitmanutenc a o de vis oes, o processamento de consultas com um consumo eciente de energia nos hosts m oveis e as interfaces com o banco de dados. o de vis A manutenc a oes na rede nas estac o es m oveis e xas introduz um n umero de novos par ametros. Primeiro, vis oes podem conter dados de posic a o e tempo,

constantemente modicados. Segundo, as transmiss oes por broadcast e uma nova opc a o. Um caminho poss vel para incorpora o broadcast na manutenc a o de vis oes e por transmiss ao de relat orios inv alidos por broadcast e atualizac o es de vis oes em uma base de demanda. Finalmente, exames de desconex ao e tamb em um fator importante [Wolfson et al., 1995]. O processamento de consultas com um consumo eciente de energia nos hosts m oveis busca levar a vida u til da bateria a um extremo. Um crit erio de otimizac a o e desenvolvido que minimize a energia gasta pelo host m ovel, enquanto n ao permite que o throughput 12 total degrade al em dado de um ponto inicial. O projeto das interfaces do banco de dados para a computac a o m ovel enfrenta v arias restric o es. Essas restric o es incluem o tamanho reduzido das telas, a necessidade para uma interface simples, a lenta e cara comunicac a o sem o e o limite das baterias [Alonso et al., 1992]. Um facilitador para o processamento de consulta, chamado Query by Icons (QBI), que contempla as restric o es citadas anteriormente est a descrito em [Massari et al., 1996]. As func o es do QBI em uma interface com uma linguagem visual ic onica, permitem ao usu ario compor uma consulta ao banco de dados por manipulac a o de cones. Um ponteiro, do tipo light-pen, e usado para manipular a limitac a o de tamanho. Al em disso, o modelo sem antico de dados do QBI esconde do usu ario os detalhes do banco de dados e uma ferramenta de meta-consulta ajuda na formulac a o da consulta durante a desconex ao.

o dos Clientes M 5. Ger encia de Localizac a oveis

Com o crescimento do n umero de usu arios utilizando equipamentos m oveis e o aumento da quantidade de servic os oferecidos a estes usu arios, e esperado que o tr afego da movimentac a o desses usu arios e os bancos de dados para a ger encia da localizac a o (posic a o) desses usu arios cresc am de forma bastante r apida. Assim sendo, desenvolver estrat egias para a ger encia da localizac a o dos clientes m oveis e uma quest ao central para a computac a o m ovel [Pitoura and Samaras, 1998]. o 5.1. O problema da localizac a A ger encia de localizac a o e um importante problema na computac a o m ovel. Esta ger encia consiste, basicamente, em atualizar, procurar e procurar/atualizar a localizac a o do usu ario m ovel. Uma atualizac a ovel o altera a sua localizac a o. o ocorre quando o host m Uma procura (busca) ocorre quando um host, por exemplo um servidor de banco de dados, deseja se comunicar com um host m ovel cuja localizac a o e desconhecida. Uma procura/atualizac a os uma procura com sucesso, quando o host solicitante o ocorre, ap atualiza a informac a o referente a ` posic a o do host m ovel procurado. A meta de um bom esquema de ger encia de localizac a o e oferecer um m etodo eciente para procura e atualizac a o. O custo da procura e atualizac a o de uma localizac a o e caracterizada pelo n umero de mensagens e a distancia que a mensagem necessita viajar. Uma ger encia de localizac a o eciente deve tentar minimizar essas quantidades [Krishna et al., 1994].
12 Representa o n umero de processos (tarefas) executados em um determinado intervalo de tempo. Quanto maior, maior o n umero de tarefas executadas. Sua maximizac a o e sempre desejada

As abordagens para armazenar a informac a o da localizac a o de um host m ovel oscilam entre dois extremos. De um lado, a informac a o atualizada da exata localizac a o de todos os usu arios e mantida em cada e em todas as localizac o es da rede. Neste caso, localizar um usu ario se reduz a uma consulta no banco de dados. Por outro lado, toda vez que a localizac a o do usu ario se altera, um grande n umero de bancos de dados de localizac o es deve ser atualizado. No outro extremo, nenhuma informac a o e armazena em qualquer site. Neste caso, para localizar um cliente em um busca global, todos os sites da rede devem ser consultado. Entretanto, n ao h a custo associado com a atualizac a o dos bancos de dados de localizac a o [Pitoura and Samaras, 2001]. Entre esses dois extremos, v arias abordagens que tentem balancear o custo da procura (lookups) contra o custo da atualizac a o s ao cab veis. Essas abordagens comprometem a disponibilidade, a precis ao ou a corr encia((currency) da informac a o armazenada para cada usu ario. A Figura 14, extra da de [Pitoura and Chrysanthis, 2000], apresenta essas abordagens.

o que (granularidade) onde (disponibilidade) quando (corrncia/currency)

Em todos os sites

Disponibilidade

Em site selecionados

A rede inteira

Posio exata

io a part m u lg a

Em nenhum lugar

de arida l u n Gra

Nunca atualizado

Corrncia (currenc y)
Sempre atualizado (em cada movimento)

dos Figura 14: Abordagens para armazenamento de informac oes da localizac ao usuarios moveis

Em termos de disponibilidade, a escolha varia entre salvar a localizac a o dos usu arios m oveis em todos os sites da rede at e n ao armazenar em nenhum local. Entre essas duas abordagens extremas, a informac a o de localizac a o pode ser mantida seletivamente em sites espec cos da rede. Existe uma grande quantidade de crit erios de selec a o para indicar os sites que ir ao armazenar a informac a o de localizac a o para cada usu ario. Por exemplo, a escolha pode ser salvar a localizac a o dos usu arios no site de sua maior freq ue ncia de chamadas. A imprecis ao na informac a o da posic a o pode tomar v arias formas. Por exemplo, ao inv es de manter a exata posic a o do usu ario, uma ampla regi ao ou um conjunto poss vel de localizac o es e mantido. Isto se d a em func a o da

granularidade13 da informac a o armazenada. A corr encia ((currency) se refere a quando a informac a o da localizac a o armazenada e atualizada. Por exemplo, para usu arios com alta mobilidade pode fazer sentido adiar a atualizac a o da informac a o armazenada sobre a sua localizac a o toda vez que ele se movimentar.Quando a informac a o precisa e corrente sobre a posic a o do usu ario n ao estiver dispon vel, localizar o usu ario envolve combinar algum procedimento da busca e um n umero de consultas que prop oem as localizac o es armazenadas no banco de dados [Pitoura and Samaras, 2001]. o 5.2. Arquiteturas dos Bancos de Dados de Localizac a As duas abordagens mais comuns para arquitetura dos bancos de dados de localizac a o s ao os Esquema em Duas Camadas (Two-tier schemes), similar ao modelo utilizado na telefonia celular, no qual a localizac a o corrente para cada usu ario em movimento e salvo em duas localizac o es da rede e o Esquemas Hier arquico em que o espac o e hierarquicamente decomposto em sub-regi oes. Nesta sec a o trataremos apenas dessas duas abordagens. Diversas outras abordagens para os bancos de dados de localizac a o foram pesquisadas e desenvolvidas. Maiores detalhes sobre essas abordagens podem ser encontrados em [Pitoura and Samaras, 2001], [Pitoura and Fudos, 1998], [Pitoura and Samaras, 1998], [Cayirci, 2002], [Krishna et al., 1994], [Li et al., 2000], [Li et al., 1999] e [Shivakumar and Widom, 1995]. 5.2.1. Esquemas em Duas Camadas No esquema em duas camadas (two-tier schemes), o banco de dados de localizac a o local, chamada de Home Location Register (HLR), e associado com cada usu ario m ovel. O HLR e localizado em uma localizac a o da rede (zona) pr e-especicado para cada usu ario. Ele armazena a posic a o corrente de cada usu ario em movimento como parte do perl do usu ario. Os procedimentos de busca e atualizac a o s ao bastante simples. Para localizar o usu ario x, a HLR de x e identicada e a consulta e realizada. Quando o usu ario x se movimenta para uma nova zona, a HLR de x e contatada e atualizada para manter a nova localizac a o. Como aprimoramento deste esquema, um Visitor Location Register (VLR) tamb em e mantido em cada zona. O VLR da zona armazena as c opias dos pers dos usu arios que n ao s ao da sua a rea e est ao atualmente localizados dentro de sua zona. Quando uma chamada e estabelecida da zona i para o usu ario x, a VLR da zona i e primeiramente consultada e somente se o usu ario n ao for encontrado l a, a HLR de x e contatada. Quando x se movimenta da zona i para a zona j, em adic a o a ` atualizac a o da HLR de x, o registro de x e exclu do da VLR da zona i e um novo registro para x e adicionado na VLR da zona j. Os dois padr oes existentes prevalecem para a tecnologia celular. A Eletronics Industry Association Telecommunications Industry Associations (EIA/TIA) Interim Standard 41 (IS-41), muito comum na Am erica do Norte e a Global System for Mobile Communications (GSM) usada na Europa, ambas utilizam as estrat egias de HLR e VLR [Pitoura and Samaras, 2001].
13 Granularidade se refere ao n vel de detalhe em que as informac o es s ao mantidas no banco de dados. Quanto maior o n vel de detalhes, menor o n vel de granularidade.

5.2.2. Esquemas Hier arquico O Esquema de Localizac a arquico estende o esquema em duas camadas mantendo o Hier o banco de dados de localizac a o em uma hierarquia. Nesta hierarquia, um banco de dados de localizac a o contem as informac o es de localizac a o de n vel mais alto para todos os usu arios localizados nos n veis inferiores. Normalmente esta hierarquia e uma estrutura em a rvore. Neste caso, o banco de dados armazena em uma folha uma u nica zona (c elula) e contem as entradas para todos os usu arios registrados nesta zona. Em seus n os internos mant em informac o es sobre os usu arios registrados no conjunto de zonas das sub- arvores. Para cada usu ario m ovel, estas informac o es s ao tamb em um ponteiro para as entradas de n vel mais baixo do banco de dados ou a localizac a o atual do usu ario. Os bancos de dados s ao normalmente conectados por conex oes da rede de sinalizac a o inteligentes, por exemplo uma Common Chanel Signaling (CCS). Por exemplo, em telefonia, o banco freq de dados pode ser colocado nos switches da rede. E uente o caso em que a u nica maneira que duas zonas poderem se comunicar seja atrav es da hierarquia. N ao existe outra conex ao f sica entre elas. A Figura 15, extra da de [Pitoura and Chrysanthis, 2000], apresenta alguns exemplos de armazenamento e busca nesta hierarquia. A gura a e um exemplo de registro de um usu ario m ovel na hierarquia. A gura b apresenta uma simulac a o de caminhamento na hierarquia para encontrar a localizac a o de um usu ario que recebeu uma chamada. A gura c apresenta o registro de uma nova localizac a o de um cliente em movimento para fora de sua zona e a gura d apresenta a t ecnica de partic a o, a qual busca reduzir o custo de busca na hierarquia.

Chamada

Chamador

Movimento

Parties

d
P 3 P 4

P 1

P 2

P 5

Antiga localizao

Nova localizao

Usurio x

Usurio x

Figura 15: Armazenamento e busca utilizando um banco de dados de localizac ao hierarquico

 6. Est agio Atual dos SGBDs M oveis na Industria e nos Centros de Pesquisas Cient cas
A computac a o m ovel e uma a rea em franca expans ao, tanto pelo lado da pesquisa cient ca como pelo lado da ind ustria. Cada vez mais novas aplicac o es necessitam ser apoiadas pela tecnologia sem o, requerendo o lanc amento de novos produtos e motivando a pesquisa, tanto no contexto da comunicac a o de dados, da engenharia de software como do armazenamento e gerenciamento de dados. Esta sec a o tem por objetivo apresentar alguns produtos de SGBDs comerciais para a computac a o m ovel, bem como algumas linhas de pesquisas cient cas em bancos de dados m oveis. 6.1. Est agio atual dos SGBDs M oveis na Industria Os maiores fabricantes de SGBDs atuam no mercado da computac a o m ovel, oferecendo um conjunto de produtos que incluem software para o desenvolvimento de aplicac o es e SGBDs adaptados para este ambiente, os quais buscam uma integrac a o dos dados destas aplicac o es com os servidores de bancos de dados localizados na rede xa. Uma caracter stica comum desses produtos est a no fato de serem desenvolvidos, principalmente, para atuarem na desconex ao dos clientes, como bancos de dados locais, sempre necessitando de uma carga antecipada dos dados (hoarding) para dar suporte as aplicac o es. Quando conectados a rede xa, executam a sincronizac a o com seus servidores, evitando trabalharem conectados como se estivessem em um ambiente de banco de dados distribu do. Segundo uma pesquisa do Gartner Dataquest de 2002, publicada na [Magazine, 2002], a Sybase com o seu produto Sybase SQL Anywhere dominava, aproximadamente, 65% do mercado de banco de dados m oveis. Outros produtos tamb em relevantes no mercado s ao o Oracle Lite da Oracle, o DB2 Everyplace da IBM, o SQL Server 2000 CE da Microsoft e o SQLBase da Gupta Technologies. Todos esses produtos s ao considerados como Small Footprint DBMS, ou seja, SGBDs projetados para minimizar a utilizac a o da mem oria dos hosts m oveis. A seguir s ao apresentados alguns desses produtos, sem o objetivo de comparac a o entre os mesmos. 6.1.1. Sybase UltraLite O produto SQL Anywhere Studio da Sybase e um pacote de software que prov e a ger encia de dados e possui uma soluc a o de banco de dados embutida chamada de Sybase UltraLite. Al em do seu sincronismo com os SGBDs da Sybase, pode se comunicar com produtos de outros fabricantes. Suas principais caracter sticas s ao: Pode ser utilizado nas plataformas Windows 95/98/Me, NT, 200, XP, Windows CE (Pocket PC/Handheld PC), Palm Computing Platform, Wind River VxWorks; Acesso aos dados atrav es de JDBC, SQL embutida e API baseada em C++; As funcionalidades da SQL incluem processamento de transac o es, integridade referencial e operac o es de junc o es de v arias tabelas; Suporta Binary Large Object (BLOB); Prov e servic o de encriptograa para seguranc a dos dados; O tamanho m aximo do banco de dados e de 2Gb;

O tamanho m aximo de cada linha e de 4k; O n umero de linhas de cada tabela depende do tamanho do banco de dados; pode ter at e 1.000 tabelas por banco de dados; Pode ter at e 65.535 linhas por tabela; Possui suporte para sincronizac a o em redes sem o.

Maiores detalhes sobre este produto da Sybase podem ser encontrados em [Sybase, 2003] 6.1.2. Oracle Lite Mobile Server O produto Oracle Lite Mobile Server est a constru do sob o produto Oracle9i Application Server. Possui uma estrutura XML e suporta o desenvolvimento de aplicac o es que podem utilizar voz, troca de mensagens e o acesso sem o. As aplicac o es m oveis desconectadas podem acessar seus dados localmente. O vers ao Oracle9i Lite possui dois componentes principais: 1. Oracle9i Lite Mobile Server, respons avel pela ger encia dos bancos de dados m oveis e pelo sincronismo das aplicac o es m oveis desconectadas com um amplo n umero de equipamentos m oveis; 2. Oracle9i Lite Mobile Development Kit, produto para desenvolvimento de aplicac o es para v arias plataformas; Suas principais caracter sticas s ao: Pode ser utilizado nas plataformas Palm, CE, Symbian EPOC e Windows 95/98/NT/2000; Possui suporte para sincronizac a o em redes sem o; Suporta as funcionalidades da SQL padr ao; Possui servic os de mensagens em aparelhos de telefone, pagers e computadores port ateis; Possui servic os de mensagens Push-based e Pull-based para broadcast; Possui servic os de voz; Prov e servic o de encriptograa para seguranc a dos dados. Maiores detalhes sobre este produto da Oracle podem ser encontrados em [Oracle, 2003] 6.1.3. DB2 Everyplace O DB2 Everyplace e um banco de dados relacional com aproximadamente 150K. Pode ser utilizado como um banco de dados local quando seu host est a desconectado ou como um cliente acessando o servidor durante a conex ao com a rede xa. Possui sincronismo bi-direcional com os SGBDs corporativos. Suas principais caracter sticas s ao: Pode ser utilizado nas plataformas PalmOS, Microsoft Windows CE/Pocket PC, Symbian EPOC, embutido no Linux, QNX Neutrino e Microsoft Win32; Possui suporte para sincronizac a o em redes sem o;

 Pode ser sincronizado como cliente com o IBM DB2 Universal Server nas platafromas Unix, Windows, OS/2,OS/390 e AS/400; Suporta as funcionalidades da SQL padr ao; Possui interface Query-By-Example (QBE) como interface de consulta; N ao suporta sub-consultas, vis oes, triggers, stored procedure, tipo de dados LOBs e func o es denidas pelo usu ario. Maiores detalhes sobre este produto da IBM podem ser encontrados em [IBM, 2003] 6.1.4. Microsoft SQL Server CE O Microsoft SQL Server CE e um banco de dados relacional para o desenvolvimento de aplicac o es para os equipamentos m oveis. Pode ser utilizado como um banco de dados local quando seu host est a desconectado ou como um cliente acessando o servidor durante a conex ao com a rede xa. Suas principais caracter sticas s ao: Suporta a sintaxe de consulta da (SQL); Fornece uma API para acesso ao SGBD Microsoft SQL Server; Possui otimizac a o de consultas e processamento de transac o es; Projetado para ser integrado com a plataforma Microsoft .NET; Possui seu tamanho em torno de 1 Mb; Prov e servic os de encriptograa para seguranc a dos dados; Mant em interoperabilidade com os produtos da IBM, Oracle e Sybase; Suporta as plataformasWin32 e Windows CE, Linux, Palm OS, QNX Neutrino e Symbian EPOC.

Maiores detalhes sobre este produto da Microsoft podem ser encontrados em [Microsoft, 2003]. 6.2. Est agio Atual dos SGBDs M oveis nos Centros de Pesquisas Cient cas Diversos trabalhos est ao sendo propostos em v arias a reas da computac a o m ovel. Particularmente na a rea de banco de dados m oveis podemos citar: Em [Satyanarayanan, 2001] s ao discutidos os desaos nos sistema computadorizados para um novo campo de pesquisa chamado de Pervasive Computing (computac a o penetrante, envolvente, presente em todos os lugares), no qual e examinado o relacionamento deste novo campo de pesquisa com seus predecessores, os sistemas distribu dos e de computac a o m ovel. Maiores detalhes sobre este campo de pesquisa podem ser encontrados em http://www.computer.org/pervasive. O sistema Coda, uma refer encia em pesquisa sobre sistemas m oveis, e apresentado em [Satyanarayanan et al., 1990] e [Kistler and Satyanarayanan, 1991]. Diversos t opicos de pesquisa em bancos de dados m oveis, tais como operac o es desconectadas, seguranc a, performance, replicac a o e escalabilidade foram e est ao sendo desenvolvidos neste projeto. Junto com o projeto Coda e desenvolvido o projeto Odyssey, com e nfase nas aplicac o es adapt aveis para a computac a o m ovel. Esses dois projetos deram origem ao projeto Aura, cujo objetivo principal e criar um ambiente chamado de Ubiquitous Computing (computac a o que est a em todos os lugares), cujo objetivo

e fornecer a cada usu ario uma o vel de servic os computacionais e de rbita invis informac o es que persistem n ao obstante a posic a o do usu ario. Informac o es sobre esses projetos podem ser encontradas em http://www.coda.cs.cmu.edu/, ttp://www2.cs.cmu.edu/afs/cs/project/coda/Web/coda.html e http://www-2.cs.cmu.edu/ aura/ [Vlach, 2001] apresenta o projeto MDBAS que e um prot otipo de um sistema de ger encia de m ultiplos bancos de dados baseado em agentes m oveis, integrando um conjunto de bancos de dados aut onomos distribu dos sob a rede, possibilitando a criac a o de esquemas globais de bancos de dados, gerenciando a transpar encia de execuc a o para os clientes m oveis. Em [Preguica et al., 2000] e apresentado um modelo de transac a o para o projeto MobiSnap, o qual e um projeto que tem por objetivo dar suporte ao desenvolvimento de aplicac o es baseadas em um banco de dados relacional para o ambiente m ovel. Em [Peng and Chen, 2003] e proposto um algoritmo de data mining para descoberta de padr oes na movimentac a o dos clientes. O interessante desta pesquisa e que combina t ecnicas de data mining de reconhecimento de padr oes com o objetivo de para melhorar desempenho total de um sistema m ovel. Diversos outros trabalhos de pesquisas cient cas foram citados ao longo deste trabalho, destacando o processamento de transac o es, a consist encia e a recuperac a o dos bancos de dados para um ambiente de computac a o m ovel.

7. Conclus ao
O objetivo deste trabalho foi apresentar o papel dos Sistemas de Bancos de Dados (SBDs) no ambiente da computac a o m ovel, destacando os principais problemas deste ambiente e como os SBDs podem contribuir e serem utilizados no sentido de expandir, cada vez mais, a utilizac a o dos sistemas de informac o es, propiciando que em qualquer lugar e em qualquer hora o usu ario m ovel possa ter acesso a ` informac a o. O texto e apresentado buscando contribuir, principalmente, no entendimento do ambiente da computac a o m ovel, para os leitores interessados na a rea de banco de dados, n ao se aprofundado nas quest oes das redes de computadores, sua infra-estrutura, protocolos e outros requisitos para esta a rea t ao complexa. A inserc a o dos SBDs na computac a o m ovel n ao e algo trivial. Os pressupostos para garantia da consist encia e integridade dos dados, principal func a o dos SGBDs, n ao pode ser totalmente aplicado no ambiente m ovel, uma vez que suas operac o es por dependerem de dois ambientes, em muitos momentos desconectados, n ao permitem que as transac o es de banco de dados possam ser executadas como nos seus modelos centralizados ou distribu dos. Assim, constantes pesquisas se fazem necess arias no sentido de desenvolver novos modelos de transac o es que possam garantir as operac o es m oveis, mantendo os requisitos b asicos dos SGBDs em relac a o aos dados que armazenam. Diversas pesquisas em bancos de dados para computac a o m ovel acontecem em v arios centros de pesquisas cient cas e s ao absorvidas pela ind ustria. Este trabalho tamb em pode servir de um bom referencial bibliogr aco para os interessados na a rea de bancos de dados para computac a o m ovel.

Refer encias
Acharya, A. and Badrinath, B. R. (1994). Checkpoint distributed applications on mobile computers. In 3 rd International Conference on Paralell and Distributed Information Systems, pages 7380. Acharya, S., Alonso, R., Franklin, M., and Zdonik, S. (1995a). Broadcast disks: Data management for asymmetric communication environments. In ACM SIGMOD, pages 199210. Acharya, S., Franklin, M., and Zdonik, S. (1995b). Dissemination-based data delivery using broadcast disks. In IEEE Personal Communication, pages 5060. Alonso, R., Haber, E. M., and Korth, H. F. (1992). A database interface for mobile computers. In Proceedings of IEEE GLOBECOM 92 Workshop on Networking of Personal Communications Applications. Badrinath, B. R., Acharya, A., and Imielinski, T. (1993). Impact of mobility on distributed computations. Operating Systems Review, 27(2):1520. Barbar a, D. (1999). Mobile computing and databases - a survey. Knowledge and Data Engineering, 11(1):108117. Brayner, A. and Filho, J. A. M. (2002). Amdb: An approach for sharing mobile databases in dynamically congurable environments. In Anais XVII Simp o sio Brasileliro de Banco de Dados, pages 1226. Brayner, A. and Monteiro, J. M. (2000). Temporal serialization graph testing: An approach to control concurrency in broadcast environments. In Anais XVII Simp o sio Brasileliro de Banco de Dados, pages 28730. Buchholz, S., Zeigert, T., Schill, A., and Held, A. (2000). Transaction processing in a mobile computing environment with alternating client hosts. In RIDE, pages 18. Cayirci, E. (2002). User mobility pattern scheme for location update and paging in wireless systems. IEEE Transactions on Mobile Computing, 01(3):236247. Chrysanthis, P. K. (1993). Transaction processing in mobile computing environment. In IEEE Workshop on Advances in Parallel and Distributed Systems, pages 7783, Princeton, New Jersey. Datta, A., Celik, A., Kim, J. G., VanderMeer, D. E., and Kumar, V. (1997). Adaptive broadcast protocols to support power conservant retrieval by mobile users. In ICDE, pages 124133. Dunham, M. H. and Helal, A. (1995). Mobile computing and databases: Anything new? In SIGMOD Record, pages 59. Dunham, M. H., Helal, A., and Balakrishnan, S. (1997). A mobile transaction model that captures both the data and movement behavior. Mobile Networks and Applications, 2(2):149162. Elmasri, R. and Navathe, S. B. (2000). Fundamentals of Database Systens, volume Third Edition. Addison-Wesley.

Elmasri, R. and Navathe, S. B. (2002). Sistemas de Banco de Dados - Fundamentos e Aplicac o a o da terceira edic a o. Livros T ecnicos e Cient fcos Editora es, volume Traduc - LTC. Endler, M. and da Silva e Silva, F. J. (2000). Requisitos e arquiteturas de software para computac a o m ovel. In I Workshop de Sistemas de Informac o das de Agentes es Distribu M oveis, S ao Paulo - Brazil. USP. Frank, L. (1999). Atomicity implementation in mobile. In Proceedings of the DEXA Conference, pages 105113. Gore, M. and Ghosh, R. (2000). Recovery of mobile transaction. In Proceedings of the DEXA Conference, pages 2327. Gray, J., Helland, P., ONeil, P., and Shasha, D. (1996). The dangers of replication and a solution. In ACM SIGMOD, pages 173182, Montreal, Canada. Huang, Y., Sistla, P., and Wolfson, O. (1994). Data replication for mobile computers. In SIGMOD Conference, pages 1324. Huang, Y. and Wolfson, O. (1994). Object allocation in distributed databases and mobile computers. In ICDE, pages 2029. IBM (2003). Db2 everyplace. 3.ibm.com/software/data/db2/everyplace/), IBM. Web address (http://www-

Imielinski, T. and Badrinath, B. R. (1992). Mobile wireless computing: Solutions and challenges in data management. Technical report, Rutgers University, U.S. Jennings, N. R. and Wooldridge, M. J. (1998). Agent Technology - Foundations, Applications, and Markets - Applications of Intelligent Agents, volume part 1, pages 3-28. Springer. Kearney, P. (1998). Agent Technology - Foundations, Applications, and Markets Applications of Intelligent Agents, volume part 1, pages 125-136. Springer. Kistler, J. J. and Satyanarayanan, M. (1991). Disconnected operation in the coda le system. In Thirteenth ACM Symposium on Operating Systems Principles, volume 25, pages 213225, Asilomar Conference Center, Pacic Grove, U.S. ACM Press. Krishna, P., Vaidya, N. H., and Pradhan, D. K. (1994). Location management in distributed mobile environments. In 3rd International Conference on Parallel and Distributed Information Systems (PDIS), pages 8188, Washington, DC. IEEE Computer Society. Lam, K.-Y., Kuo, T.-W., Tsang, W.-H., and Law, G. C. K. (1999). Transaction shipping approach for mobile distributed real-time databases. In Database and Expert Systems Applications, pages 932941. Lam, K.-Y., Kuo, T.-W., Tsang, W.-H., and Law, G. C. K. (2000). Concurrency control in mobile distributed real-time database systems. Information Systems, 25(3):261286. Li, G.-H., Lam, K.-Y., and Kuo, T.-W. (1999). Location update generation in cellular mobile computing systems. Li, G.-H., Lam, K.-Y., Kuo, T.-W., and Lo, S.-W. (2000). Location management in cellular mobile computing systems.

Lu, Q. and Satyanarayanan, M. (1994). Isolation-only transactions for mobile computing. Operating Systems Review, 28(2):8187. Lu, Q. and Satyanarayanan, M. (1995). Improving data consistency in mobile computing using isolation-only transactions. In Fifth IEEE HotOS Topics Workshop, Orcas Island, WA, USA. Magazine, P. (2002). On the road to mobile databases. (http://www.pcmag.com/article2/0,4149,4180,00.asp), PC Magazine. Web address

Massari, A., Weissman, S., and Chrysanthis, P. K. (1996). Supporting mobile database access through query by icons. Distributed and Parallel Databases, 4(3):249269. Melo, R. N., Silva, S. D., and Tanaka, A. (1997). Banco de Dados em Aplicac o es ClienteServidor. Editora Infobook. Microsoft (2003). Db2 everyplace. (http://www.microsoft.com/sql/ce/default.asp/), IBM. Web address

Nwana, H. and Ndumu, D. (1998). Agent Technology - Foundations, Applications, and Markets - Applications of Intelligent Agents, volume part 1, pages 29-47. Springer. Oracle (2003). Oracle9i application server in mobile. (http://www.oracle.com/ip/deploy/ias/mobile/index.html/), Oracle. Web address

Peng, W.-C. and Chen, M.-S. (2003). Developing data allocation schemes by incremental mining of user moving patterns in a mobile computing system. IEEE Transactions on Knowledge and Data Engeneering, 15(1):7085. Phatak, S. H. and Badrinath, B. R. (1999). Data partitioning for disconnected client server databases. In MobiDE, pages 102109. Pitoura, E. and Bhargava, B. (1994a). Dealing with mobility: Issues and research challenges. Technical report, Pudue University, USA. Pitoura, E. and Bhargava, B. (1994b). Revising transaction concepts for mobile computing. In First IEEE Workshop on Mobile Computing Systems and Applications, pages 164168, Santa Cruz, CA, US. Pitoura, E. and Bhargava, B. K. (1995). Maintaining consistency of data in mobile distributed environments. In International Conference on Distributed Computing Systems, pages 404413. Pitoura, E. and Bhargava, B. K. (1999). Data consistency in intermittently connected distributed systems. Knowledge and Data Engineering, 11(6):896915. Pitoura, E. and Chrysanthis, P. K. (2000). Mobile and wireless database access for pervasive computing. Pitoura, E. and Fudos, I. (1998). An efcient hierarchical scheme for locating highly mobile users. In CIKM, pages 218225. Pitoura, E. and Samaras, G. (1998). Data Management for Mobile Computing, volume 10. Kluwer Academic Publishers. Pitoura, E. and Samaras, G. (2001). Locating objects in mobile computing. Knowledge and Data Engineering, 13(4):571592.

Pradhan, D., Krishna, P., and Vaidya, N. (1996). environment: Design and trade-off analysis.

Recovery in mobile wireless

Prakash, R. and Sihghal, M. (1996). Low-cost checkpointing and failere recovery in mobile systems. In IEEE Transactions on Parallel and Distributed Systems. Preguica, N. M., Baquero, C., Moura, F., Martins, J. L., Oliveira, R., Domingos, H. J. L., Pereira, J. O., and Duarte, S. (2000). Mobile transaction management in mobisnap. In ADBIS-DASFAA, pages 379386. Samaras, G. and Pitsillides, A. (1997). Client/intercept: a computional model for wireless environments. In 4 th International Conference on Telecommunications (ICT97), Melbourne, Australia. Satyanarayanan, M. (1996). Fundamental challenges in mobile computing. In Symposium on Principles of Distributed Computing, pages 17. Satyanarayanan, M. (2001). Pervasive computing: Vision and challenges. IEEE Personal Communications, pages 1017. Satyanarayanan, M., Kistler, J. J., Kumar, P., Okasaki, M. E., Siegel, E. H., and Steere, D. C. (1990). Coda: A highly available le system for a distributed workstation environment. IEEE Transactions on Computers, 39(4):447459. ur Ulusoy, and Elmagarmid, A. K. (2001). Association rules for supporting Saygn, Y., Ozg hoarding in mobile computing environments. Serrano-Alvarado, P., Roncacio, C. L., and Adiba, M. (2001). Mobile transaction supports for dbms: An overview. Shivakumar, N. and Widom, J. (1995). User prole replication for faster location lookup in mobile environments. In Mobile Computing and Networking, pages 161169. Silberschatz, A., Korth, H. F., and Sudarshan, S. (1997). Database System Concepts, volume Third Edition. Mc Graw Hill. Ssu, K.-F., Yao, B., Neves, N. F., and Fuchs, W. K. (1998). Adaptive checkpointing with storage management for mobile environments. Sybase (2003). Sql anywhere studio8 database. (http://www.sybase.com/products/anywhere/), Sybase. Web address

Villate, Y., Pitoura, E., Illarramendi, A., and Elmagarmid, A. K. (2000). Extending the data services of mobile computers by external data lockers. In DEXA Workshop, pages 160164. Vlach, R. (2001). Mobile database procedures in MDBAS. In DEXA Workshop, pages 559563. Walborn, G. D. and Chrysanthis, P. K. (1997). PRO-MOTION : Management of mobile transactions. In Selected Areas in Cryptography, pages 101108. Wolfson, O., Sistla, A. P., Dao, S., Narayanan, K., and Raj, R. (1995). View maintenance in mobile computing. SIGMOD Record, 24(4):2227. Ozsu, M. T. and Valduriez, P. (1999). Principles of Distributed Database Systems. Prentice Hall.