Anda di halaman 1dari 24

UNIDADE 4 BANCO DE DADOS PARA COMPUTAO UBQUA

OBJETIVO DA UNIDADE
Nesta unidade o leitor ir conhecer os conceitos bsicos a cerca de banco de dados para computao ubqua. O usurio conhecer principalmente as arquiteturas relacionadas a essa tecnologia.

1. BANCO DE DADOS PARA COMPUTAO UBQUA


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.

Figura 36 - CLASSIFICAO DE BANCO DE DADOS DISTRIBUDOS E MVEIS

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 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.

2. ARQUITETURAS
2.1. CLIENTE SERVIDOR

Figura 37 - ARQUITETURA CLIENTE SERVIDOR

A arquitetura clienteservidor 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 clienteservidor 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. 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 comunicarse 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 clienteservidor 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 clienteservidor, 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.

2.2.

CLIENTE-AGENTE SERVIDOR-CLIENTE

Figura 38 - ARQUITETURA CLIENTE - AGENTE 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 agentes podem: Processar os dados da consulta e enviar somente o resultado para o cliente; Compactar os dados antes de envilos; 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; 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.

2.3.

CLIENTE AGENTE SERVIDOR- SERVIDOR

Figura 39 - ARQUITETURA 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.

Naturalmente, para que o cliente tenha um agente, preciso que ele cumpra um requisito mnimo de recursos, que nem todo dispositivo mvel possui.

2.4.

Cliente Agente Cliente Agente Servidor Servidor

Figura 40 - ARQUITETURA 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.

2.5.

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 que originou o acesso ao banco de dados.

2.6.

GSN E MLTIPLOS AGENTES

Essa arquitetura baseada no modelo Client/Interceptor/Server, que foi apresentado no item 2.4. 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 41 - ARQUITETURA MULTI AGENTES

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 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.

3. 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.

4. ENVIO DE DADOS

4.1.

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 pushbased. 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 pushbased 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 multinvel, 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 multinvel 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 pullbased. Nesse caso, o cliente faz a requisio dos dados de que necessita para o servidor. Um sistema puramente pullbased 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 pushbased 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 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 pullbased. 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 tradeoff 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.

4.2.

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.

Figura 42 - PROCESSO DE DESCONEXO DE HOARDING

Conforme podemos observar na figura ao lado, a desconexo dividida em trs etapas: Carga antecipada de dados (hoarding); Operaes desconectadas;

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 mantlos 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, reexecutando 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 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 cach (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.

5. TRANSAES
5.1. 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 multiusurio. 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 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.

5.2.

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.

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 twophase 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 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.

6. 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 NPcompleto. Uma alternativa o uso de heursticas gulosas baseadas no algoritmo ID3 para resolver esse problema. 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.

7. 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.

8. 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.

8.1.

DISPOSITIVO 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() 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.

8.2.

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 utilizar).

8.3.

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.

8.4.

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 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.

RESUMO DA UNIDADE
Pode-se observar nessa unidade, os Modelos de Arquiteturas de Gerenciamento para Banco de Dados mveis existentes, evidenciando sua evoluo. Observou-se tambm os tipos de transaes,envio de dados e localizao. E por fim abordou-se tpicos de interface com usurio e sincronizao de dados.

PARA SABER MAIS


Para saber mais sobre o que foi abordado na unidade 4, ler sobre banco de dados relacionais, banco de dados mveis e banco de dados geogrficos.

REFLEXES SOBRE A UNIDADE


Muito se tem discutido sobre o uso de solues mveis para processos empresariais, automao de sistemas em campo e outras aplicaes para o ambiente corporativo. Em princpio, o uso de e-mails nos celulares a aplicao mais popular, a qual se enraizou na mente das pessoas como sendo a chegada do mundo dos negcios nos celulares. Eis a a fora de alguns dispositivos, que incorporam as ferramentas de e-mail como seu principal artifcio para conquista do cliente corporativo.

SUGESTO DE LEITURA
Segue abaixo algumas sugestes de leitura: Banco de Dados para um Ambiente de Computao Mvel, Srgio da Costa Cortes e Srgio Lifschitz. Proposta de Dissertao de Mestrado Operaes Desconectadas em Dispositivos Mveis, Mariano Cravo Teixeira Neto.

Anda mungkin juga menyukai