Nome: Flvia Rainone N

o
USP: 3286141
Bancos de Dados Mveis
I. Introduo
O paradigma de computao mvel tem afetado conceitos, modelos e premissas tradicionais em
vrias reas da cincia da computao.
Na rea de redes, preciso que os dispositivos estejam conectados rede independente de sua
localizao, o que conhecido como computao ubqua.
Na rea de engenharia, o novo paradigma introduziu a noo de cdigo mvel, que significa a
capacidade do cdigo de migrar entre unidades da rede.
Em relao base de dados no diferente. A computao mvel introduziu o conceito e a
necessidade de os clientes mveis acessarem seus bancos de dados de qualquer lugar. Como
veremos, muitas caractersticas da computao mvel influenciam as premissas utilizadas nessa
rea.
Conforme foi visto no curso, a computao mvel se resume a diversos componentes, possivelmente
heterogneos, ligados a uma rede sem fio. Essa, por sua vez, est conectada a uma rede fixa,
atravs de estaes de base, componentes da rede fixa que possuem antenas de comunicao com
a rede sem fio. Todas as unidades conectadas rede fixa so unidades fixas.
Adicione a esse cenrio um ou mais bancos de dados implantados em unidades da rede. Bancos de
dados mveis se resumem a uma ou mais base de dados acessada por unidades mveis. Cada base
de dados est sitiada em uma outra unidade da rede, seja ela fixa ou mvel.
Podemos ver a computao mvel como uma variao da computao distribuda. Os bancos de
dados mveis so distribudos sob dois aspectos:
Todo banco de dados distribudo, principalmente, entre os componentes sob a rede com fio,
possivelmente com replicao parcial ou total. Assim, uma estao de base gerencia seu prprio
banco de dados com as funcionalidades inerentes aos Sistemas de Gerenciamento de Banco de
Dados (SGBDs), com funcionalidades adicionais para localizar unidades mveis e caractersticas
adicionais de gerncia de consultas e transaes, para atender aos requisitos de ambientes
mveis;
O banco de dados distribudo entre os componentes sob a rede com fio e com os componentes
sob a rede sem fio. A responsabilidade sobre a gerncia de dados compartilhada entre estaes
de base e unidades mveis.
Observe a classificao para os SGBDs Distribudos baseada nas caractersticas do sistema quanto
autonomia, distribuio e heterogeneidade (Figura 1). A figura apresenta uma extenso para essa
classificao segundo os SGBDs Mveis, os quais acrescentam um ponto no eixo de distribuio,
caracterizando os sistemas de computao mveis. A lgica para essa extenso est no fato de que
os sistemas de computao mveis devem ter uma parte em rede fixa, que um sistema distribudo.
pgina 1
Nome: Flvia Rainone N
o
USP: 3286141
As questes relativas gerncia de bancos de dados distribudos podem ser aplicadas aos
bancos de dados mveis desde que alguns aspectos sejam analisados de forma especial:
Velocidade dos links sem fio: pode ocasionar demora nas consultas;
Escalabilidade: crescimento dos bancos de dados tem impacto nas consultas e limita a quantidade
de dados nos bancos de dados residentes em clientes mveis;
Mobilidade: pode causar desconexo e cancelamento de transaes;
Localizao das unidades mveis: implica na necessidade de administrar a localizao das
unidades mveis para interao durante as consultas;
Limite do poder das baterias: exigem trabalho em modo desconectado da rede e podem causar
desconexes e cancelamento de transaes;
Desconexes (voluntrias ou involuntrias): causam o cancelamento de transaes aumentando a
necessidade de novos modelos de recuperao do banco de dados.
Replicao / Caching: limitadas pelo pouco poder de memria das unidades mveis;
Handoff: aumenta a necessidade de controle e administrao da localizao das unidades mveis.
As principais conseqncias que isso traz para os bancos de dados mveis so:
As aplicaes podem ser dependentes da localizao da unidade mvel;
As transaes podem ser interrompidas pela diviso (particionamento) freqente da rede;
O sistema tem que estar preparado para se recuperar e no falhar em casos de: desligamento
pgina 2
Figura 1 - Classificao de Bancos de Dados Distribudos e Mveis
Nome: Flvia Rainone N
o
USP: 3286141
voluntrio da unidade mvel; inmeros acessos (logins) ao sistema, causados por desconexes; e
situaes de handoff.
So necessrias novas tcnicas de replicao para atualizao da memria cache dos
dispositivos mveis.
As consultas podem ter resultados dependentes da localizao do dispositivo e os fatores de
custo so diferentes daqueles em ambiente fixo.
Como podemos ver, a rea de bancos de dados mveis bem complexa e extensa, e envolve
inmeros aspectos. Vejamos, a seguir, cada um deles.
II.Arquiteturas
A.Cliente Servidor
A arquitetura cliente-servidor supe uma estrutura bsica que consiste de inmeros
microcomputadores (PCs) e estaes de trabalho, bem como um nmero menor de equipamentos de
grande porte, conectados atravs de sistemas de redes locais e outros tipos de sistemas de rede de
computadores. Um cliente, nesta estrutura, geralmente um equipamento de um usurio 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 no reside neste
equipamento, ele se conecta a um servidor que fornece a funcionalidade necessria. Um servidor
um equipamento que pode fornecer servios para as estaes clientes como impresso,
armazenamento de dados ou acesso ao banco de dados.
A idia da arquitetura cliente-servidor dividir as funcionalidades que precisam ser fornecidas aos
usurios do SGBD em duas camadas, a camada servidor e a camada cliente, ambas com
funcionalidades distintas. Esta arquitetura facilita o gerenciamento da complexidade dos SGBDs
atuais. A arquitetura cliente - servidor est incorporada aos Sistemas de Gerncia de Banco de
Dados (SGBD). Os programas da interface do usurio e da aplicao podem ser executados no lado
do cliente. Quando necessrio acesso ao banco de dados, o programa estabelece uma conexo
com o SGBD, que est no lado do servidor, e uma vez que a conexo estabelecida, os programas
no cliente podem se comunicar com o SGBD. A camada servidor faz a maior parte do trabalho de
gerenciamento de dados, enquanto que a camada cliente responsvel pela interface do usurio e
pela prpria aplicao, alm de administrar uma memria local para solicitao e armazenamento do
resultado das consultas. Diferentes tipos de arquiteturas cliente servidor podem ser implementadas.
pgina 3
Figura 2 - Arquitetura Cliente - Servidor
UM
Cliente
APP
Unidade
Servidora
BD
SGDB
Comunicao
Sem fio
ou Hbrida
Nome: Flvia Rainone N
o
USP: 3286141
A arquitetura mais simples aquela em que vrios clientes acessam um nico servidor, denominada
mltiplos clientes - servidor nico. A arquitetura mais complexa aquela em que o ambiente possui
mltiplos clientes - mltiplos servidores.
Na computao mvel, a unidade mvel atua como um cliente requisitando servios dos servidores
localizados na rede fixa. Neste caso, os dados e as funcionalidades esto distribudos atravs de
vrios servidores que podem comunicar-se entre si para atender s solicitaes dos clientes. Na
maioria dos casos, os servidores se encontram na rede fixa. Um servidor pode ser replicado em
diferentes unidades na rede fixa para aumentar a disponibilidade nos casos de falhas nas unidades
ou na rede de comunicao. A diviso das funcionalidades entre os clientes mveis e os servidores
fixos que esto sob as redes fixas no muito clara. Em muitos casos, o papel de cada um fica
confuso, como no caso durante as desconexes em que o cliente mvel necessita emular as
funcionalidades de um servidor para continuar operando. Um importante componente da arquitetura
cliente-servidor o tipo de mecanismo de comunicao que utilizado para a troca de informaes
entre o cliente e o servidor. Uma possibilidade a troca de mensagens direta entre o cliente e o
servidor. Essa abordagem no adequada para as redes lentas e pouco confiveis como o caso
da computao sem fio e novos mecanismos de troca de informaes esto em estudos. Extenses
do tradicional modelo cliente-servidor, como se enfileirar mensagens RPC (Remote Procedure Call),
so necessrias para dar apoio a operaes desconectadas e a fraca conectividade. Otimizaes
adicionais como compresso e filtros de dados tambm so importantes. Por estes motivos, o
tradicional modelo cliente-servidor deve ser estendido para prover componentes srios que
possibilitem a implementao de otimizaes adequadas e, ainda assim, acarretem no mnimo
possvel de mudanas a serem feitas nos clientes e nos servidores.
B.Cliente Agente Servidor Servidor
Este modelo em trs camadas realiza a comunicao entre o cliente mvel e o servidor atravs da
troca de mensagens do cliente com o agente e deste com o servidor. Genericamente, podemos dizer
que o agente assume o papel de substituto do cliente mvel na rede fixa. Esta arquitetura alivia um
pouco o impacto da limitao da largura de banda e da pouca segurana do link sem fio, atravs da
presena do cliente mvel na rede fixa via o agente. Os agentes, tipicamente, dividem a interao
entre os clientes mveis e os servidores fixos em duas partes, sendo uma entre o cliente e o agente
e a outra entre o agente e o servidor fixo. Assim, diferentes protocolos podem ser usados para
interao em cada parte e essas partes podem executar suas funcionalidades independentemente.
Este modelo mais apropriado para clientes mveis com limitado poder de recursos e poder
computacional. Assim, diversas responsabilidades dos clientes mveis migram para os agentes. Os
pgina 4
Figura 3 - Aquitetura Cliente - Agente Servidor - Servidor
UM
Cliente
APP
Unidade
Servidora
BD
SGDB
Unidade
Agente
Servidor
Nome: Flvia Rainone N
o
USP: 3286141
agentes podem:
processar os dados da consulta e enviar somente o resultado para o cliente;
compactar os dados antes de envi-los;
processar as buscas e enfileirar as respostas quando o cliente estiver desconectado;
alterar a ordem de transmisso dos dados para os clientes, de acordo com sua prioridade.
Alm disso, os clientes tambm podem acumular as buscas para envi-las aos agentes em blocos,
pois isso economiza bateria. Aps enviarem as solicitaes, os clientes podem entrar em modo de
cochilo, para economizar bateria.
A exata posio dos agentes na rede fixa depende do papel que o mesmo venha a desempenhar.
Colocando-o na extremidade da rede fixa, como, por exemplo, nas estaes de bases, obtemos
algumas vantagens quando o agente atua como substituto do cliente mvel em sua rea de
cobertura. Assim, fica mais fcil:
reunir informaes das caractersticas do link sem fio;
utilizar um protocolo especial entre o cliente mvel e o agente;
e personalizar informaes sobre o cliente mvel que podem ser disponibilizadas localmente.
Esse modelo oferece muitas vantagens. Porm, falha no suporte da operao dos clientes mveis
durante o perodo de desconexo. Quando acontece uma desconexo, o cliente mvel no continua
a operar ininterruptamente. Finalmente, o agente somente consegue otimizar a transmisso de
dados do agente para o cliente mvel, mas no no caminho inverso.
C.Cliente Agente Cliente Servidor
Este modelo apresenta uma extenso do modelo cliente - servidor, tambm em trs camadas,
porm, com a incluso do agente de software junto unidade mvel, ou seja, no cliente mvel.
Genericamente, podemos dizer que o agente assume o papel de ampliar as funcionalidades nos
clientes mveis, geralmente pobres em recursos computacionais. Entre as muitas atividades
especficas de uma aplicao que os agentes podem desempenhar, podemos destacar, de uma
forma mais genrica, as seguintes atividades:
administrar a memria cache no cliente mvel;
disponibilizar memria progressivamente para o cliente mvel durante o pouco trfego da rede
(prefetching);
copiar parte do banco de dados para a memria do cliente mvel (hoarding);
otimizar a comunicao entre o cliente mvel e sua estao de base.
pgina 5
Figura 4 - Arquitetura Cliente - Agente Cliente - Servidor
UM
Cliente
APP
Unidade
Servidora
BD
SGDB
Agente
Cliente
Nome: Flvia Rainone N
o
USP: 3286141
Naturalmente, para que o cliente tenha um agente, preciso que ele cumpra um requisito mnimo de
recursos, que nem todo dispositivo mvel possui.
D.Cliente Agente Cliente Agente Servidor Servidor
Para sanar as deficincias dos dois modelos anteriores, nos quais os agentes de software residem e
executam em apenas um dos lados da arquitetura, foi proposto este modelo, tambm chamado de
Client/Intercept/Server.
Nessa arquitetura, o agente situado no cliente mvel executar em conjunto com o agente situado no
servidor. Dessa forma, unimos as vantagens dos modelos anteriores. Alm disso, os dois agentes
otimizam a comunicao atravs da reduo da quantidade de dados transmitidos na rede sem fio,
melhoram a segurana na transferncia dos dados e sustentam a no interrupo da computao
mvel, entre outras possveis atividades.
O ponto fraco deste modelo que cada aplicao necessita de trabalho de desenvolvimento tanto no
servidor quanto no cliente. Porm, no necessrio o desenvolvimento do par de agentes para cada
nova aplicao. Construindo-se as funcionalidades e otimizaes suficientemente genricas,
somente ser necessrio o desenvolvimento de pares de agentes diferentes para aplicaes de cada
tipo. Por exemplo, um agente para aplicaes do tipo web.
E.AMDB
A arquitetura AMDB visa interoperabilidade entre sistemas de bancos de dados mveis.
Esse modelo baseado no conceito de agentes. Os agentes so divididos em duas classes:
estticos e mveis. Os primeiros so responsveis pela criao do contexto de execuo para os
agentes mveis, gerenciamento de recursos locais de um computador mvel e identificao de
servios disponibilizados no ambiente mvel. Os agentes mveis, por sua vez, so responsveis por
transportar o cdigo de acesso a bancos de dados e os resultados destes acessos.
Temos dois tipos de agentes estticos. O Administrador e o Mantenedor. Aquele responsvel pelo
gerenciamento de recursos do dispositivo, identificao e disponibilizao de servios, transferncia
de servios e por efetuar a conexo e desconexo do sistema de comunicao. O Mantenedor
responsvel pelo mapeamento dos dados locais em um formato de representao comum (XML) e
pela comunicao com o sistema de banco de dados. Ou seja, ele quem deve executar o cdigo de
acesso ao banco de dados, que transportado por um agente mvel.
Na classe de agentes mveis, encontramos o Executor e o Carregador. O Executor responsvel por
migrar entre os componentes mveis levando consigo o cdigo de acesso aos bancos visitados. O
agente Carregador criado pelo Executor sempre que preciso enviar um resultado para o cliente
pgina 6
Figura 5 - Arquitetura Cliente - Agente Cliente - Agente Servidor - Servidor
Unidade
Servidora
BD
SGDB
Unidade
Agente
Servidor
UM
Cliente
APP
Agente
Cliente
Nome: Flvia Rainone N
o
USP: 3286141
que originou o acesso ao banco de dados.
F.GSN e Mltiplos Agentes
Essa arquitetura baseada no modelo Client/Interceptor/Server, que foi apresentado no item D.
A diferena a adio de um elemento intermedirio situado na rede fixa. Esse elemento,
denominado Gateway Support Node (GSN), se responsabiliza por intermediar a comunicao das
unidades mveis sob sua cobertura com as outras unidades da rede (sejam elas fixas ou mveis). O
objetivo do GSN livrar as unidades mveis de diversas tarefas e otimizar o uso dos seus recursos,
que so, como j vimos, limitados. O GSN um componente ciente dos problemas inerentes a uma
rede mvel e preocupado em trat-los. O par formado por unidade mvel e GSN permite que a
unidade mvel se comporte como uma unidade fixa perante as outras unidades da rede. O GSN
empresta a sua identidade para as unidades mveis que ele monitora, de modo que quando ele
recebe uma mensagem, ele a reenvia para a unidade mvel apropriada.
Figura 6 - Arquietura Multi Agentes (Mordomos Alfredo) e GSN
Quando se trata de arquiteturas com mltiplos agentes, a idia mais comum criar um agente para
cada tarefa a ser realizada, dar ao agente os dados necessrios para acessar alguma fonte de
informao, e envi-lo para a rede mvel. Quando o agente obtm o resultado, ele retorna ao
computador mvel com a resposta.Na figura 2 temos uma proposta de arquitetura que apresenta
algumas vantagens em relao a essa arquitetura mais comumente encontrada. Aqui, utilizamos um
agente denominado mordomo Alfredo para evitar as transferncias contnuas de agentes atravs
da rede se fio. Cada unidade mvel possui um mordomo Alfredo, que um mordomo eficiente que
tem como objetivo prover os servios adequados para o seu dono. Do ponto de vista de
implementao, Alfredo a unio de dois agentes SAlfredo (Alfredo esttico) e MAlfredo (Alfredo
pgina 7
Nome: Flvia Rainone N
o
USP: 3286141
Mvel). Enquanto SAlfredo se situa no componente mvel, o MAlfredo se situa no GSN. O agente
MAlfredo criado no computador mvel e viaja pela rede at o elemento intermedirio, o GSN, onde
ele trabalha em prol do usurio mvel, representando-o na rede, se tornando o ponto comum de toda
comunicao na qual a unidade mvel est envolvida, mesmo quando ela est desconectada da
rede. Quando preciso executar uma tarefa, SAlfredo envia uma mensagem para MAlfredo com as
informaes necessrias. Ento, MAlfredo executa a tarefa, ou cria um agente, um especialista (os
agentes especialistas ficam localizados no GSN), para que ele execute a tarefa. Aps a execuo da
tarefa, MAlfredo envia os resultados para SAlfredo.
III.Heterogeneidade
Um dos problemas que dificultam a implementao de bancos de dados mveis o problema da
heterogeneidade. Integrar informaes armazenadas em vrios bancos de dados distribudos,
heterogneos e autnomos no uma tarefa simples. Para que tais bancos de dados (BDLs ou
bancos de dados locais) se tornem interoperveis, diversas arquiteturas de integrao tm sido
propostas.
Uma das principais propostas a arquitetura de sistemas de bancos de dados federados. Nesse
caso, a integrao entre BDLs realizada atravs de um esquema federado, que representa uma
viso integrada dos diversos esquemas locais. A grande desvantagem desta proposta exatamente
a especificao e manuteno do esquema federado. Em um caso em que muitos bancos de dados
esto envolvidos, obter um esquema integrando todos os bancos de dados seria uma tarefa sobre-
humana, pois implicaria em se conhecer todos os esquemas locais, resolver os conflitos entre os
BDLs (sejam estruturais ou semnticos) e depois especificar os esquemas federados. Haveria ainda
o problema da evoluo do esquema federado, pois os esquemas locais podem estar em constante
evoluo. E, vale lembrar que, evoluo e dinamicidade so uma das principais caractersticas da
computao mvel, inclusive quando se trata de redes ad hoc.
Uma outra abordagem bastante difundida para integrar mltiplas fontes de dados a arquitetura de
mediadores. Um mediador representa dados relacionais e legados como objetos. Contudo, essa
proposta sofre dos mesmos problemas que a arquitetura de bancos de dados federados, pois a
integrao realizada atravs de uma viso de integrao. Tal viso nada mais que um esquema
federado.
Uma proposta que prov maior autonomia integrao o sistema de bancos de dados mltiplos
(Multidatabase System MDBS). Um MDBS integra vrios sistemas de bancos de dados
heterogneos e autnomos. Ele inclui um componente de software que composto de uma coleo
de funes globais. Para que essas funes sejam implementadas, preciso especificar e
desenvolver mdulos globais de software e de estruturas de dados globais. Processamento de
consultas, controle de concorrncia global, mecanismo de recuperao global, transformao entre a
forma de representao de dados locais e representao de dados globais so exemplos de mdulos
globais de software. A integrao de diferentes fontes de dados realizada pela linguagem de
bancos de dados mltiplos (Multidatabase Language MDL). A MDL uma ferramenta atravs da
qual um usurio global pode definir e manipular mltiplos bancos de dados locais. Portanto, a
tecnologia de bancos de dados mltiplos integra dados de mltiplas fontes de dados sem requerer a
existncia de um ou mais esquemas globais (federados). exatamente essa propriedade que torna
esta tecnologia atrativa para integrar bancos de dados em ambientes com suporte computao
mvel.
pgina 8
Nome: Flvia Rainone N
o
USP: 3286141
IV.Envio de Dados
A.Disseminao de Dados
Disseminao de dados a entrega de dados a partir de um conjunto de produtores para um grande
nmero de clientes. Isso caracterizado por uma assimetria nas comunicaes: a banda passante
para download deve ser maior do que a de upload.
Esse modelo se encaixa com a caracterstica de computao mvel: um dispositivo mvel recebe
dados a uma velocidade maior do que envia. Alm disso, muito mais caro para um dispositivo
enviar dados do que receber.
O modelo em que dados so enviados para o cliente sem esperar por requisies especficas
chamado push-based. Enviar dados para os clientes evita interrupes causadas por requisies e
permite a propagao de dados que poderiam, caso contrrio, ser ignorados pelos clientes. Por outro
lado, sistemas push-based tm o problema de decidir qual a relevncia dos dados a serem enviados
para os clientes. A utilidade do sistema depende da sua habilidade em prever as necessidades dos
clientes. Uma soluo simples seria permitir que os clientes se inscrevessem para receber servios e
provessem perfis do seu interesse. Os clientes podem inscrever buscas especficas no servidor para
receber os resultados das buscas freqentemente. Isso chamado de buscas contnuas ou
continous queries.
Alm disso, cabe ao servidor decidir se os dados sero enviados periodicamente ou no. O envio
peridico apresenta a vantagem de que, se um cliente se desconectar da rede, ele no perder itens,
pois os dados sero reenviados novamente. Por outro lado, o envio no peridico uma forma mais
efetiva de utilizar a banda passante.
A arquitetura Broadcast Disks faz uso de envios de dados no peridicos. Essa arquitetura inova nos
seguintes pontos:
uso de um mecanismo multi-nvel, que permite que dados sejam enviados de forma no uniforme.
Assim, a banda passante alocada para os itens de acordo com a sua importncia;
mecanismos para gerenciar o armazenamento nos clientes com suporte a caching e prefetching,
para tornar o broadcast multi-nvel mais eficiente.
Com o uso de Broadcast Disks, podemos construir uma hierarquia entre os dados de modo que o
nvel mais alto contm poucos itens que devem ser transmitidos com alta freqncia, enquanto que
os nveis subseqentes contm cada vez mais itens para serem transmitidos com freqncias cada
vez menores.
Nenhum algoritmo de escolha dos dados a serem enviados e com qual freqncia resolve todos os
casos. Por isso mesmo, existe a necessidade do uso de cache e prefetching do lado do cliente.
Naturalmente, tambm existe a possibilidade de termos um sistema pull-based. Nesse caso, o cliente
faz a requisio dos dados de que necessita para o servidor. Um sistema puramente pull-based
aconselhvel apenas quando existe pouca conteno no servidor e quando os prprios dispositivos
no precisam de um volume muito grande de dados.
Por outro lado, um sistema puramente push-based adequado somente quando o servidor est
muito sobrecarregado com requisies de clientes. O ideal um sistema que envia dados com
broadcast, e que tambm recebe requisies, ou seja, um sistema que seja intermedirio entre esses
dois modelos de disseminao de dados. Essa soluo hbrida se chama Interleaved Push and Pull
(IPP). Para que ocorra o envio e o recebimento de dados entre os clientes e servidores preciso a
pgina 9
Nome: Flvia Rainone N
o
USP: 3286141
existncia de dois canais. O backchannel utilizado para clientes fazerem requisies especficas de
dados para o servidor. O frontchannel utilizado para envio de broadcasts do servidor e de resposta
a requisies de clientes. Desse modo, possvel decidir quais dados valem a pena transmitir em
broadcast. Todos os dados que no so enviados para os clientes no broadcast podem ser
requisitados por clientes. Infelizmente, o IPP sofre dos mesmos problemas de gargalo na rede que
sofrem as abordagens pull-based. Para tornar essa soluo mais escalvel, possvel:
Ajustar a banda passante do backchannel, sob o custo de diminuir a banda do frontchannel. Isso
introduz um trade-off entre quo rpido a fila de requisies dos clientes processada e quo
rpida a entrega de dados broadcast executada.
Fazer com que os clientes requisitem somente as suas perdas mais caras, ou seja, dados que
seriam enviados em um futuro distante. O efeito dessa tcnica atrasar o ponto no qual a fila de
requisies pelo servidor fica saturada.
Dividir a parte mais lenta do agendamento de broadcast em partes sucessivamente maiores. O
efeito o aumento da banda disponvel para requisies dos clientes. Se ainda assim no existir
banda passante o suficiente para as requisies, a performance pode degradar consideravelmente
uma vez que clientes no sero capazes de requisitar os itens que no foram enviados em
broadcast.
Uma outra forma de efetuar a disseminao de dados eficientemente o servidor enviar mensagens
de invalidao para os clientes. Atravs de Invalidation Reports (IRs), o servidor pode notificar os
clientes sobre mudanas nos dados que eles armazenam no cache. Os IRs so formas sucintas de
transmitir informao. Eles podem ser implementados de inmeras formas diferentes. Por exemplo,
uma lista de identificadores dos itens que foram alterados desde a ltima notificao pode ser
enviada em um IR. Alm disso, a granularidade dos dados abrangidos em cada item a ser invalidado
na notificao do IR tambm importante. Em muitos casos, pode ser custoso enviar invalidaes a
uma granularidade fina, ou seja, item por item. A granularidade um fator essencial que deve ser
analisado no momento de se implementar um IR. Dependendo do modo como utilizado, o IR pode
fazer com que um cliente apague dados no seu cache que ainda so vlidos. Existe tambm a
possibilidade de no impor tanto rigor quando consistncia dos caches. Em se tratando de uma
aplicao que envolva preos de um estoque, por exemplo, pode ser aceitvel que os valores no
estejam completamente atualizados com o banco de dados servidor, desde que a diferena entre o
valor do cache e o preo real seja de 0,5%. Isso pode ser obtido se considerarmos os dados do
cache como quase-cpias dos valores do servidor. Uma quase-cpia um valor armazenado em
cache que pode desviar um pouco do valor real do servidor de forma controlada. O uso de quase-
cpias torna as IRs mais curtas, e otimiza o uso da banda de comunicao.
B.Hoarding
Um dos problemas envolvidos em implantar bancos de dados mveis a desconexo freqente do
dispositivo da rede. Para que a aplicao continue funcionando, preciso que o dispositivo possua
os dados que ir utilizar em cache.
Para resolver esse problema, existe a tcnica de hoarding. Quando o dispositivo nota uma
desconexo inesperada antecipadamente, os itens de dados so transferidos para o cliente mvel,
para possibilitar a sua operao durante o perodo da desconexo. Essa carga antecipada de dados
o que chamamos de hoarding.
pgina 10
Nome: Flvia Rainone N
o
USP: 3286141
Conforme podemos
observar na figura ao
lado, a desconexo
dividida em trs etapas:
carga antecipada de
dados (hoarding);
operaes
desconectadas;
e reintegrao.
Durante a etapa de
hoarding, os itens
necessrios para
operao so carregados
na unidade mvel. Os
itens podem ser
simplesmente realocados
ou movimentados da unidade fixa para a unidade mvel. Porm, eles se tornaro inacessveis para
as outras unidades. Uma alternativa replicar os dados ou mant-los no cache da unidade mvel.
O tipo de dados transferidos para a unidade mvel depende da aplicao e do modelo de dados que
o sustenta. Veja os exemplos:
Em sistemas de arquivos os dados podem ser arquivos, diretrios ou volumes de disco.
No caso de SGBDs, os dados podem ser relaes ou vises.
Para sistemas de browsing na web, os dados podem ser pginas.
Em se tratando do modelo de objetos, os objetos de dados podem carregar com eles informaes
adicionais, tais como o conjunto de operaes permitidas.
No modelo baseado em agentes mveis, os agentes podem ser transmitidos ao longo da rede
para serem executados no cliente mvel.
Para desconexes previsveis, como por exemplo, a motivada pela entrada do cliente em uma regio
fora da sua rea original de cobertura, e, portanto, financeiramente mais cara, os dados podem ser
carregados imediatamente antes da desconexo.
Quando a unidade se desconecta, ela entra no estado de operaes desconectadas. Nesse ponto,
todas as requisies da aplicao a dados que no esto armazenados no dispositivo mvel sero
recusadas ou enfileiradas para execuo aps a reconexo do dispositivo. Para evitar ou minimizar
esse problema, importante que o processo de hoarding saiba escolher quais os dados que o
dispositivo tem que armazenar.
Quando acontece uma nova conexo com a rede fixa, a unidade mvel entra no estado de
reintegrao. Neste estado, as atualizaes da unidade mvel so reintegradas com as atualizaes
de outros sites, re-executando o seu log na unidade fixa. Questes referentes concorrncia e
seriao das transaes so efetivadas em funo de cada sistema em particular, visando resolver o
problema da atualizao sobre o mesmo objeto.
Dois exemplos de aplicao de hoarding so:
Coda: como foi visto em aula, o Coda um sistema de arquivos distribudos, desenvolvido no
Departamento de Cincia da Computao da Carnegie Mellon University, EUA, desde 1987. Em
cada cliente do Coda, existe um gerenciador de cache chamado Venus, que obtm
pgina 11
Figura 7 - Processo de Desconexo com Hoarding
REINTEGRAO
CARGA
ANTECIPADA DE
DADOS
(HOARDING)
OPERAES
DESCONECTADAS
Nome: Flvia Rainone N
o
USP: 3286141
dinamicamente os dados e os pe na memria cache. Para dar suporte operao desconectada,
o Venus trabalha em trs estgios: estado de hoarding, emulao e reintegrao. O hoarding do
Venus baseado em prioridade. Ele combina informaes implcitas e explcitas para avaliar quais
dados devem estar no cache. Implicitamente, um algoritmo tradicional de gerenciamento de cache
(no caso, o LRU) utilizado para avaliar o histrico de arquivos recentemente usados.
Explicitamente, utilizado um banco de dados de hoard, o HDB, cujo contedo so os caminhos
dos arquivos que o usurio tem interesse que o Venus mantenha na cache. Para manipular o
HDB, o Venus usa um programa chamado hoard profile que atualiza diretamente ou via scripts. O
Venus periodicamente avalia a reteno de objetos do cache em um processo chamado hoard
walking. O hoard walking necessrio para que seja atingida a expectativa do usurio em relao
importncia da permanncia de seus objetos no cache, isto , se aqueles dados que o usurio
espera que estejam na cache de fato se encontrem l. Quando o cache atinge esta expectativa,
dito que ele est em equilbrio.
Seer: o Seer um sistema de predio de hoarding, onde a escolha dos dados que devem estar
presentes no cache feita de forma automtica e transparente ao usurio. O Seer no executa a
replicao e transferncia de arquivos entre servidores e clientes. Em vez disso, ele roda sobre
sistemas de arquivos que tm esta funcionalidade (como o Coda, por exemplo). A escolha de
quais arquivos devem ser mantidos no cache baseada na observao do comportamento do
usurio atravs dos arquivos utilizados e no uso inferncias quanto relao entre estes arquivos.
O Seer composto de dois mdulos: o Observer ou Observador, que acompanha o
comportamento do usurio e seus acessos a arquivos, classificando cada acesso de acordo com
um tipo, convertendo caminhos dos arquivos em um formato absoluto, e assim alimentando o
mdulo Correlator. O Correlator avalia as referncias dos arquivos, calculando a distncia
semntica entre eles. Esta distncia semntica alimenta um algoritmo de clustering, que atribui
cada arquivo a um ou mais projetos. Esta distncia semntica a mtrica utilizada para a
definio da relao entre arquivos. Assim, grupos de arquivos necessrios para se trabalhar em
um determinado projeto so identificados. Desta forma, o Seer prediz os projetos que o usurio
est trabalhando e carrega seus arquivos localmente no cliente mvel.
V.Transaes
A.Transaes Mveis
O ambiente de computao mvel, como j foi visto, influencia muito o modo como so
implementados os bancos de dados. Entre as caractersticas de tal ambiente est o fato de ele ser
multi-usurio. Bancos de dados mveis so implantados em um ambiente no qual vrios clientes
podem querer acessar diversas bases. Essas podem ser locais ou remotas. A concorrncia entre
aplicaes locais e remotas implementada atravs do entrelaamento temporal de operaes de
um conjunto de aplicaes distintas. Isso tudo leva a um problema. Execues entrelaadas de
transaes podem produzir inconsistncias.
Alm desses fatores, temos as freqentes desconexes e a intermitncia na comunicao, que
podem interromper a execuo de uma transao a qualquer momento.
Desse modo, existe uma grande necessidade de solues de transaes especficas para o
ambiente de bancos de dados mveis.
E uma das primeiras premissas que o ambiente de computao ameaa em relao a transaes a
pgina 12
Nome: Flvia Rainone N
o
USP: 3286141
atomicidade. Uma transao comumente estruturada como atmica com o objetivo de preservar a
consistncia dos dados na presena de concorrncia e falhas no sistema. Entretanto, uma
computao mvel que acessa dados compartilhados no pode ser estruturada usando uma
transao atmica. Isto se d porque transaes atmicas assumem o pressuposto de executarem
isoladas, o que impede as mesmas de dividirem a sua computao e de compartilharem seus
estados e resultados parciais. J na computao mvel, consideraes prticas nicas deste
ambiente exigem que as computaes nas unidades mveis sejam sustentadas e apoiadas por uma
unidade de suporte a mobilidade (estao de base), tanto para computao como para comunicao
de dados. Isto significa que a computao mvel precisa ser estruturada como um conjunto de
transaes, algumas das quais executam na unidade mvel, enquanto que outras executam na
unidade de suporte mobilidade. Alm da necessidade da diviso de suas transaes, a
computao mvel tambm est envolvida, em primeiro lugar, com a mobilidade de suas fontes de
dados e de seus consumidores e, em segundo lugar, por sua natureza interativa, como, por exemplo,
pausas para entrada de dados por seus usurios. Assim, uma outra exigncia que as transaes
atmicas no podem satisfazer a sua habilidade de lidar com falhas parciais e prover diferentes
estratgias de recuperao, desta forma minimizando os efeitos das falhas.
Uma transao mvel uma transao distribuda, onde alguma parte da computao executada na
unidade mvel e outra parte em uma unidade fixa.
O uso do meio sem fio e a mobilidade resultante dos consumidores e produtores de dados afetam o
processamento das transaes de vrias formas. O emprego de conexes sem fio resulta em
transaes longas, em funo dos longos atrasos da rede.
A mobilidade resulta em transaes que acessam sistemas de informaes heterogneas. Alm
disso, enquanto em projetos estticos a localizao dos usurios fixa, no ambiente mvel mudam
constantemente. Conseqentemente, as transaes mveis acessam dados de localizao dos
clientes que mudam rapidamente, em muitos casos em posies imprecisas. Finalmente, as
transaes podem envolver dados que esto dinamicamente sendo mudados de lugar.
B.Consistncia de Dados
Garantias de consistncia para dados processados por clientes mveis um campo de pesquisa
importante. Essas garantias provem a base para qualquer trabalho colaborativo e processamento
de transao feito com os sistemas envolvidos.
preciso um mecanismo que fornea s aplicaes uma viso da base de dados consistente com as
suas aes. Isso importante, pois clientes podem ler e escrever dados de qualquer servidor
disponvel e esses servidores podem conter vises inconsistentes da base de dados. Por exemplo,
um cliente poderia fazer uma escrita em um servidor e depois ler o dado que ele alterou de outro
servidor. Isso resultaria em uma leitura inconsistente, caso os dois servidores no tivessem se
sincronizado entre as duas operaes. Desse modo, necessrio que tenhamos garantias de sesso
para resolver o problema. Essas garantias so:
Leia as suas escritas: qualquer operao de leitura na sesso deve refletir os valores
estabelecidos pelas escritas anteriores feitas naquela sesso;
Leituras monotnicas: leituras sucessivas refletem um nmero no-decrescente de escritas.
Propagao de escritas: escritas so propagadas depois das leituras das quais elas dependem.
Escritas monotnicas: escritas so propagadas depois das escritas que as precederam
logicamente.
pgina 13
Nome: Flvia Rainone N
o
USP: 3286141
Essas restries so garantidas por um gerenciador de sesses que ordena as leituras e escritas em
srie de fornece identificadores nicos a cada escrita. O servidor deve retornar informao sobre o
identificador de escrita nico e conjunto de identificadores de escritas que so relevantes para uma
dada leitura. O gerenciador mantm um conjunto dos identificadores das escritas relevantes para as
leituras de dados da sesso e um conjunto dos identificadores das escritas efetuadas durante a
sesso. Essas garantias de sesso foram desenvolvidas para serem aplicadas no prottipo do
projeto Bayou, que tem como objetivo prover uma framework de colaborao entre usurios de
computao mvel.
Outra forma de garantir a consistncia de dados durante as transaes dos clientes mveis a
tcnica do mtodo escrow. Esse mtodo consiste em dividir as instncias dos itens do banco de
dados entre os clientes mveis. Uma transao pode suceder facilmente se o nmero de instncias
que ela requer no ultrapassar o nmero de instncias que a unidade mvel possui. Atravs de um
protocolo de reconfigurao, a unidade pode requisitar instncias das outras unidades, nesse caso,
para aumentar o nmero de instncias que ela tem disponvel. Uma das vantagens desse mtodo
que ele compatvel com o handoff. Se, durante uma transao, a unidade trocar de estao base e
de servidor de banco de dados, ela s precisa informar ao novo servidor qual o prximo passo a ser
realizado na transao. Isso funciona porque o servidor antigo tomou as suas decises baseado nos
elementos que estavam de posse da unidade mvel. O nico passo necessrio ao trocar de servidor
que, aps a transao, o protocolo two-phase commit deve ser utilizado para a sincronizao dos
dois servidores.
As tcnicas de escrow podem ser generalizadas se explorarmos a semntica dos objetos, a fim de
facilitar operaes autnomas e desconectadas em aplicaes de bancos de dados mveis. A idia
dividir objetos extensos e complexos em pequenos fragmentos e armazenar um conjunto desses
fragmentos no cache de uma unidade mvel. Ao transformar os fragmentos em unidades de
consistncia e definir restries de consistncia sobre o uso dos fragmentos, possvel a execuo
de operaes concorrentes sobre o mesmo objeto. Utilizando um protocolo de demarcao, podemos
garantir que as execues locais so seriveis. O protocolo faz isso explorando a organizao do
objeto e das suas restries. Quando um cliente mvel requisita acesso a um objeto, ele envia ao
servidor uma requisio com um pedido de split, que seleciona parte do objeto e estabelece algumas
condies de consistncia. A partir desse instante, a parte do objeto selecionada est disponvel
apenas para transaes realizadas na unidade mvel que fez a requisio. O restante do objeto
continua disponvel para os outros clientes. Um exemplo de objetos que podem ser fragmentados
dessa forma so itens agregados (como, por exemplo, assentos de avio), conjuntos e pilhas. Por
exemplo, conjuntos podem ser divididos em subconjuntos e esses, por sua vez, podem ser
combinados em uma ordem arbitrria para a reobteno do conjunto original. Cada unidade mvel
pode especificar um intervalo de elementos como critrio de seleo, com os intervalos sendo
disjuntos.
Uma outra tcnica utilizada para manter a consistncia um algoritmo de replicao que permite que
aplicaes mveis proponham tentativas de transaes no cliente mvel. Essas tentativas so
realizadas sobre as rplicas gravadas nos clientes enquanto esto desconectados. Quando a
unidade reconecta na rede, a tentativa de transao proposta para a unidade fixa que contm a
cpia mestra dos dados. Essa tentativa pode suceder, ou falhar (caso ocorra conflito com outras
transaes). No segundo caso, a unidade cliente informada da falha e por que ela ocorreu. Essa
tcnica pode causar falhas freqentes na aplicao cliente. Alm disso, a tentativa de transao
pgina 14
Nome: Flvia Rainone N
o
USP: 3286141
executada no servidor pode obter resultados diferentes dos obtidos na aplicao mvel, e nem
sempre isso aceitvel.
Uma melhoria para essa soluo a tcnica de Certification Reports. O canal de broadcast
utilizado pelo servidor para auxiliar os clientes mveis a prever se as transaes que eles esto
executando pode ser abortada. Isso feito atravs do recebimento de Certification Reports, que
contm uma lista dos itens que esto no conjunto de operaes de leitura e escrita de transaes
ativas que declararam ao servidor a sua inteno em comitar. O cliente verifica se as leituras e
escritas que ele executou na sua transao conflitam com as leituras e escritas das outras
transaes. Caso afirmativo, o prprio cliente aborta a sua transao. Caso contrrio, ele continua a
executar a sua transao. Quando est no momento de efetuar a transao, ele envia para o
servidor o conjunto de operaes de escrita e leituras envolvidas na transao, declarando o seu
interesse em comitar. O servidor faz uma ltima verificao de possveis conflitos. Na ausncia
deles, o servidor comita a transao, e envia no prximo broadcast o conjunto de escritas e leituras
feitas na transao comitada para que as outras unidades mveis tomem conhecimento dessas
operaes. No mesmo broadcast, o servidor tambm envia o comunicado notificando, das
transaes que enviaram requisio para comitarem, quais delas foram abortadas e quais foram
comitadas. Uma das vantagens dessa soluo que os clientes mveis ficam responsveis por parte
da validao das suas transaes. Alm disso, transaes que seriam abortadas s quando fossem
enviadas para o servidor so abortadas mais cedo.
Finalmente, tem o modelo de Isolation Only Transactions (IOT). Nesse modelo, temos garantias
fortes de consistncia, embora outras propriedades tradicionais no sejam garantidas, tais como
atomicidade e durabilidade. O modelo de execuo utiliza controle de concorrncia otimista. Do
mesmo modo que nas solues anteriores, a transao executada no cliente e nenhuma execuo
parcial visvel no servidor. Quando a transao completa, ela entra em estado de comitada ou
pendente. Se no h dados partilhados com outros clientes envolvidos na transao, ela comitada
e o seu resultado comunicado para os servidores. Caso contrrio, e transao fica pendente e
aguarda pela sua validao. Se a validao suceder, os seus resultados so comitados e
reintegrados nos servidores. Caso contrrio, a transao ter que ser resolvida, manualmente ou
automaticamente. Para isso, podemos utilizar o modelo de transao otimista de Davidson. Esse
mtodo constri um grafo de precedncias para representar interdependncias entre transaes e
detectar ciclos no grafo que indiquem que a transao no satistaz a seriao global.
VI.Localizao
O fato de que os clientes podem mudar a sua localizao possibilita responder s buscas feitas por
clientes de acordo com a sua localizao.
Realizar buscas relacionadas localizao de um ou mais objetos pode ser custoso. Por exemplo,
encontrar X, Y e Z de modo que eles estejam no mesmo endereo e Y est entre X e Z. Para
responder essa busca, o custo de comunicao para obteno dos dados necessrios muito alto.
O problema principal relacionado localizao se torna como minimizar o custo da comunicao
necessria para responder a busca. Estratgias ingnuas resultam em muitas mensagens e altas
latncias. Por outros lados, construir planos otimizados para responder a esse tipo de busca um
problema NP-completo. Uma alternativa o uso de heursticas gulosas baseadas no algoritmo ID3
para resolver esse problema.
pgina 15
Nome: Flvia Rainone N
o
USP: 3286141
Quanto necessidade de fornecer aplicaes para os usurios dependentes da sua localizao,
apresentamos duas abordagens interessantes.
Alguns protocolos integram o Global Positioning System (GPS) ao IP, para permitir a criao de
servios dependentes da localizao. Alguns exemplos desses servios so: enviar mensagens para
dispositivos que se encontram em uma determinada regio, prover servios para clientes que se
encontram em uma rea geogrfica e prover informaes aos usurios dependentes da sua
localizao.
possvel tambm estender o WWW, permitindo que documentos refiram e reajam localizao do
usurio. Isso pode ser feito atravs de dois conceitos: Dynamic Uniform Resource Locators (DURLs)
e Active Documents ou documentos ativos. Uma URL dinmica se ela contm no mnimo uma
varivel dinmica que substituda pela localizao. Por exemplo, um usurio obtm um hyperlink
para um documento que descreve a sua localizao atual em um prdio atravs de uma URL
dinmica na pgina correspondente que contm o link. Quando o usurio seleciona uma URL
dinmica em um documento, o seu browser responsvel por resolver todas as referncias para
variveis de ambiente dinmicas dentro da URL. Feito isso, o browser utiliza uma URL padro que
pode ser enviada para o servidor para obter a pgina correspondente. Documentos ativos so
documentos HyperText Markup Language (HTML) que permitem que o cliente reaja automaticamente
a mudanas no contexto do dispositivo mvel. Autores escrevem documentos ativos do mesmo
modo que escrevem HTML padro, com a diferena de que escrevem tambm um comando
subscribe que lista automaticamente as variveis de ambiente dinmicas s quais o cliente precisa
se inscrever quando ele carregar o documento. Quando as variveis envolvidas tm o seu valor
alterado, cabe ao cliente recarregar a pgina.
VII.Interface com o Usurio
O tamanho das telas de dispositivos mveis levou pesquisadores a pensarem em interfaces
adequadas para obteno de informao em telas to pequenas.
Uma interface de processamento de buscas existente a Query by Icons (QBI), que aborda
caractersticas como o tamanho da tela e memria e bateria limitadas. As caractersticas do QBI so:
uma linguagem icnica visual que permite usurios comporem buscas utilizando dispositivos
apontadores como uma caneta para manipular os cones;
um modelo de dados semntico que captura a maior parte dos aspectos das estruturas das bases
de dados;
ferramentas de metabusca que auxiliam a formular buscas durante perodos de desconexo. Isso
feito sem necessidade de acessar o servidor. Dados so acessados e transmitidos para a
unidade mvel somente quando uma busca respondida.
VIII.Na Prtica
Existem muitos bancos de dados de diversos vendedores disponveis para dispositivos mveis. Essa
uma rea que est crescendo constantemente no mercado tambm. Alguns exemplos so o
Sybase Ultralite, o Oracle Lite Mobile Server, o DB2 Everyplace, e o Microsoft SQL Server CE.
Vejamos, agora, como o cenrio do uso de bancos de dados mveis para os desenvolvedores
Java, utilizando J2ME.
pgina 16
Nome: Flvia Rainone N
o
USP: 3286141
A.Dispositivos CDC
CDC (Connected Device Configuration) um componente da arquitetura J2ME para dispositivos
relativamente poderosos, com 2MB de memria e processadores de 32 bits. Esse componente
suportado por uma mquina virtual Java 2.
Em dispositivos como esses, interessante ter alguma ferramenta que permita o acesso direto de
bancos de dados. Bancos de dados mveis nesses dispositivos podem ser utilizados para armazenar
informaes pessoais do usurio, ou para implementao de cache no dispositivo.
Um dos pacotes opcionais do CDC o JDBC. Esse pacote um subconjunto do JDBC3.0. No so
suportados:
Connection Pools;
A interface ParameterMetaData;
Definio de parmetros atravs do nome na interface CallableStatement;
Tipos do SQL 99 como Struct, Array, etc;
Tipo de mapeamento customizado (os mtodos setTypeMap() e getTypeMap()).
O subconjunto de JDBC opcional para J2ME suportado pela maioria dos vendedores de bancos de
dados mveis. Alm disso, vendedores fornecem algumas extenses no padronizadas para
melhorar a performance e produtividade.
Algumas das opes de bancos de dados mveis para dispositivos CDC so:
HSQL (projeto livre);
Anywhere Solutions SQL Anywhere Studio;
IBM DB2 Everyplace;
Oracle 9i Lite;
PointBase Micro Edition.
B.Dispositivos MIDP
MIDP a sigla de Mobile Information Device Profile e o perfil mais importante da arquitetura J2ME.
Ele tem como alvo os dispositivos menores, como telefones celulares.
Por se tratar de dispositivos muito limitados, implantar um banco de dados relacional completo sobre
tais dispositivos muito caro. O MIDP padro no suporta sequer tipos bsicos do SQL tal como o
float, por exemplo. Por outro lado, o RMS (Record Management System), que a ferramenta de
armazenamento de dados persistentes do MIDP, extremamente inadequado para aplicaes
corporativas. As gravaes realizadas pelo RMS so muito lentas, alm de no serem indexadas,
nem poderem ser buscadas. A estrutura linear do RMS torna a manipulao de dados relacionais um
pesadelo.
Para resolver esse problema, os vendedores de bancos de dados desenvolveram solues simples
para executarem em cima do RMS. Uma vez que essas bases de dados so extremamente leves,
suporte total para o JDBC no necessrio. Cada vendedor prov a sua API de acesso.
As opes mais conhecidas so:
PointBase Micro Edition (sua API similar ao JDBC e fornece um MIDlet que acessa a base, mas
muito pesado);
Oracle J2ME SODA SDK (Simple Object Database Access, banco de dados orientado a objetos);
IBM DB2e FastRecordStore (prov uma interface, FastRecordStore, sobre o RMS, e efetua
sincronizao com o banco de dados no servidor eficiente, mas apresenta uma API difcil de
pgina 17
Nome: Flvia Rainone N
o
USP: 3286141
utilizar).
C.Sincronizao
A agregao de informao umas das funcionalidades centrais de sistemas corporativos. Bases de
dados desconectadas no so muito teis. Mas, se por um lado os dados dos dispositivos precisam
ser agregados ao sistema servidor, por outro, os dispositivos precisam confiar no servidor para
manterem seus dados atualizados. A melhor soluo para isso a sincronizao de dados.
Vendedores de bancos de dados mveis fornecem solues de sincronizao para as suas bases de
dados.
A arquitetura de sincronizao utilizada se resume a um servidor de sincronizao na rede fixa. Esse
se comunica com o servidor da base de dados atravs de comunicao padro, como, por exemplo,
JDBC. O servidor de sincronizao responsvel por se comunicar com os dispositivos mveis e
tomar algumas decises. Para a comunicao na rede sem fio, preciso a existncia de dois canais.
Um para recebimento de informaes e outro para envio. A troca de dados feita atravs de
protocolos proprietrios, mas a tendncia que seja criado um padro para que dispositivos possam
se comunicar com os servidores sem utilizarem bases de dados do mesmo vendedor.
O mecanismo de sincronizao aplica a idia de dispositivo desconectado porm sincronizado. Isso
significa que o dispositivo se conecta de tempos em tempos com o servidor para a sincronizao.
Afinal, depois de tudo o que vimos em relao computao mvel e a bancos de dados mveis,
sabemos que no possvel que o dispositivo se conecte a cada consulta, e a cada alterao. Sob
esse ponto de vista, a base de dados que se encontra no dispositivo mvel faz o papel de cache.
D.Acesso Direto
Apesar de sincronizar bases de dados ser uma boa idia, nem sempre a soluo adequada.
Algumas aplicaes exigem que a base de dados do dispositivo mvel esteja sempre atualizada,
como, por exemplo, aplicaes de tempo real. Nesse caso seria preciso que a sincronizao fosse
freqente para manter a base de dados sempre atualizada. Porm, j vimos que no possvel fazer
a sincronizao a intervalos curtos de tempo. Em outras aplicaes, preciso acessar uma base de
dados legada, que s est disponibilizada remotamente. Alm de tudo isso, nem sempre vivel
manter os dados necessrios na base de dados do dispositivo mvel.
Nesse caso, a soluo fazer acesso direto ao banco de dados servidor. Em dispositivos CDC,
como j vimos, podemos utilizar JDBC, o que permite o acesso ao banco de dados servidor. Mas,
infelizmente, isso no se aplica para dispositivos MIDP. Nesse caso, necessrio expor servios
SQL atravs de um gateway HTTP.
Uma das formas de fazer isso utilizando a biblioteca Oracle J2ME SQL SDK. Ela disponibiliza uma
API que acessa um gateway servlet que, por sua vez, acessa o banco de dados servidor.
Em se tratando de bancos de dados legados, isso pode no ser suficiente. Esses sistemas legados
utilizam protocolos proprietrios e APIs de baixo nvel. Seria necessrio desenvolver uma camada
intermediria para permitir o acesso de clientes atravs de JDBC. Isso exige tempo e recursos. Uma
boa alternativa para fornecer acesso a sistemas legados e que no exige tantos esforos a tcnica
de screen scrapping. Ela baseada no uso de um agente gravador (o screen scrapper), que
grava cada tecla pressionada e todas as mensagens impressas em um terminal durante um perodo.
Quando o gravador estiver ligado, o usurio do mainframe realiza uma determinada tarefa durante a
pgina 18
Nome: Flvia Rainone N
o
USP: 3286141
sesso interativa. Feito isso, o gravador gera cdigo Java para replicar o processo. Uma ferramenta
que prov acesso a mainframes a Simplicity IDE da Data Representations.
IX.Bibliografia
WCSF2002 Minicurso 1 Acesso a Bancos de Dados Mveis, Angelo Brayner.
Banco de Dados para um Ambiente de Computao Mvel, Srgio da Costa Cortes e Srgio
Lifschitz.
Mobile Computing and Database A Survey, Daniel Barbar.
Location Dependent Data and its Management in Mobile Databases, Margaret H. Dunham e Vijay
Kumar.
Mobile Computing: Data Management Issues, Alfredo Goi e Arantza Illarramendi.
Proposta de Dissertao de Mestrado Operaes Desconectadas em Dispositivos Mveis,
Mariano Cravo Teixeira Neto.
Enterprise J2ME: Developing Mobile Java Applications, Michael Juntao Yuan.
pgina 19