gestão de dados partilhados em ambientes de computação móvel
gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel
106 CAPÍTULO 7. APRESENTAÇÃO DO SISTEMA MOBISNAP clientes e o servidor, além de permitir gerir a execução dessas operações no servidor de acordo com a carga do sistema. O Mobisnap integra um sistema de reservas, detalhado no capítulo 8, que permite aos clientes obter garantias sobre os valores da base de dados. Caso o cliente disponha de reservas suficiente, o cliente pode garantir que não surgirá nenhum conflito quando a transacção móvel é executada no servidor, permitindo garantir o resultado da transacção de forma independente. Alguns dos tipos de reservas definidos no sistema Mobisnap já foram utilizados noutros siste- mas [111]. No entanto, a sua integração num sistema unificado como o apresentado é fundamental para a sua utilidade. Considere-se o exemplo da figura 7.1. Usando técnicas de divisão (escrow) 1 é pos- sível garantir a existência de unidades suficientes de um produto para satisfazer o pedido. No entanto, para que o sistema possa garantir o resultado da transacção é igualmente necessário que possa garantir o valor do preço. Assim, seria necessário usar outro tipo de garantia. Neste caso, poder-se-ia usar um trinco (lock) apesar de essa técnica ser desnecessariamente restritiva. Uma propriedade importante do sistema de reservas é a verificação transparente das reservas que podem ser utilizadas para garantir uma transacção móvel. Esta verificação é efectuada a partir do código da transacção, sem que seja necessário especificar quaisquer instruções especiais. Assim, qualquer tran- sacção pode usar todas as reservas existentes e não apenas aquelas que a transacção está preparada para utilizar. O sistema faz respeitar as garantias relativas às reservas concedidas, não ficando as propriedades as- sociadas dependentes de convenções a cumprir pelas transacções. Assim, impede-se qualquer transacção executada no sistema Mobisnap ou directamente na base de dados central de modificar a base de dados de forma a violar as garantias relativas a qualquer reserva. Como as reservas são temporárias (leased) [58], garante-se que as restrições impostas às outras transacções não duram indefinidamente, mesmo que o cliente móvel, a quem a reserva foi concedida, seja destruído ou fique permanentemente desconectado. No entanto, para que a garantia dada quanto ao resultado de uma transacção seja válida é necessário que a transacção seja propagada para o servidor antes das reservas usadas expirarem. Reconciliação de múltiplas transacções O sistema Mobisnap inclui ainda um mecanismo de recon- ciliação que permite criar um plano de execução quase óptimo como resultado da reconciliação de um conjunto de transacções móveis. A solução proposta é uma extensão do modelo do sistema IceCube [85], e utiliza informação semântica extraída automaticamente das transacções móveis. Este mecanismo de reconciliação é genérico e pode ser usado independentemente em qualquer sistema de bases de dados para reconciliar conjuntos de transacções executadas concorrentemente. Assim, este mecanismo é apre- 1 As técnicas de divisão (escrow) permitem dividir um recurso fungível por várias réplicas — por exemplo, a existência (stock) de um produto pode ser dividido por vários vendedores. Cada réplica pode decidir sobre a sua parte de forma indepen- dente.
7.2. ARQUITECTURA 107 BD réplica Cliente Mobisnap controle de execução e interpretador trx. móveis sistema de replicação e reservas sistema de comunicações sentado de forma independente no capítulo 10. Servidor Mobisnap controle de execução e interpretador trx. móveis sistema de replicação e reservas sistema de notificação sistema de comunicações BD réplica principal Cliente Mobisnap controle de execução e interpretador trx. móveis sistema de replicação e reservas sistema de comunicações Figura 7.2: Arquitectura do sistema Mobisnap. BD réplica cliente legado Aproximação evolutiva O modelo do sistema Mobisnap é evolutivo, pois permite que aplicações que não usem o sistema Mobisnap continuem a aceder directamente à base de dados central. O sistema ga- rante o funcionamento correcto dos mecanismos propostos no sistema Mobisnap (transacções móveis, reservas e reconciliação de múltiplas transacções) independentemente de qualquer modificação concor- rente executada na base de dados central. Adicionalmente, o sistema baseia-se na utilização de linguagens normalizadas (SQL e PL/SQL). Esta característica, ao permitir que os programadores utilizem as funcionalidades do sistema através de ferramentas que lhe são familiares permite facilitar o desenvolvimento de novas aplicações que utilizem as novas funcionalidades (como se discutiu na secção 2.3.8). 7.2 Arquitectura A arquitectura do sistema Mobisnap é baseada no modelo cliente estendido/servidor [78], como se re- presenta na figura 7.2. O servidor deve executar numa máquina com boa conectividade (em geral, um computador fixo). O servidor mantém o estado “oficial” dos dados, ou seja, a réplica principal (e com- pleta) da base de dados. Os clientes podem ser computadores fixos ou móveis capazes de comunicar com o servidor. Os clientes mantêm cópias parciais dos dados. O Mobisnap é desenhado (e implementado) como uma camada de sistema intermédia (middleware). Assim, o Mobisnap utiliza um sistema de gestão de bases de dados para gerir os dados no cliente e no servidor. As funcionalidades do sistema Mobisnap são implementadas pelos componentes do sistema recorrendo aos serviços básicos fornecidos pelo sistema de gestão de bases de dados.
- Page 73 and 74: 4.1. RECONCILIAÇÃO 55 4.1.3 Ordem
- Page 75 and 76: 4.1. RECONCILIAÇÃO 57 4.1.4.2 Ver
- Page 77 and 78: 4.1. RECONCILIAÇÃO 59 No decurso
- Page 79 and 80: 4.3. INVOCAÇÃO CEGA 61 4.3 Invoca
- Page 81 and 82: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 83 and 84: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 85 and 86: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 87 and 88: Capítulo 5 Avaliação do modelo d
- Page 89 and 90: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 91 and 92: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 93 and 94: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 95 and 96: 5.2. AGENDA PARTILHADA 77 Figura 5.
- Page 97 and 98: 5.2. AGENDA PARTILHADA 79 de awaren
- Page 99 and 100: Capítulo 6 Núcleo do sistema DOOR
- Page 101 and 102: 6.1. COOBJECTOS 83 o mesmo estado i
- Page 103 and 104: 6.2. SERVIDORES 85 global a associa
- Page 105 and 106: 6.2. SERVIDORES 87 segundo servidor
- Page 107 and 108: 6.2. SERVIDORES 89 6.2.2 Sincroniza
- Page 109 and 110: 6.2. SERVIDORES 91 6.2.3 Serviço d
- Page 111 and 112: 6.2. SERVIDORES 93 ao cliente compl
- Page 113 and 114: 6.2. SERVIDORES 95 • Emulação d
- Page 115 and 116: 6.3. CLIENTES 97 do coobjecto consi
- Page 117 and 118: 6.3. CLIENTES 99 seguinte informaç
- Page 119 and 120: 6.3. CLIENTES 101 A propagação as
- Page 121 and 122: Capítulo 7 Apresentação do siste
- Page 123: 7.1. MODELO GERAL 105 encomenda de
- Page 127 and 128: 7.2. ARQUITECTURA 109 O subsistema
- Page 129 and 130: 7.3. TRANSACÇÕES MÓVEIS 111 7.3
- Page 131 and 132: 7.3. TRANSACÇÕES MÓVEIS 113 abor
- Page 133 and 134: Capítulo 8 Reservas Neste capítul
- Page 135 and 136: 8.1. TIPOS DE RESERVAS 117 8.1.4 Re
- Page 137 and 138: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 139 and 140: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 141 and 142: 8.3. PROCESSAMENTO DAS TRANSACÇÕE
- Page 143 and 144: 8.4. PROCESSAMENTO DAS TRANSACÇÕE
- Page 145 and 146: 8.5. EXEMPLOS 127 id tipo tabela co
- Page 147 and 148: 8.5. EXEMPLOS 129 1 ------ COMPRA 1
- Page 149 and 150: Capítulo 9 Avaliação do modelo b
- Page 151 and 152: 9.1. APLICAÇÕES 133 1 ------ REMO
- Page 153 and 154: 9.2. RESERVAS 135 dentemente em dif
- Page 155 and 156: 9.2. RESERVAS 137 seguinte forma. P
- Page 157 and 158: 9.2. RESERVAS 139 Commit (% total)
- Page 159 and 160: 9.2. RESERVAS 141 Commit (% total)
- Page 161 and 162: 9.2. RESERVAS 143 Commit (% total)
- Page 163 and 164: 9.2. RESERVAS 145 Commit (% total)
- Page 165 and 166: 9.2. RESERVAS 147 Por exemplo, no c
- Page 167 and 168: Capítulo 10 Sistema de reconcilia
- Page 169 and 170: 10.2. RELAÇÕES ESTÁTICAS 151 10.
- Page 171 and 172: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 173 and 174: 10.3. ALGORITMO DE RECONCILIAÇÃO
7.2. ARQUITECTURA 107<br />
BD<br />
réplica<br />
Cliente Mobisnap<br />
controle <strong>de</strong> execução e<br />
interpretador trx. móveis<br />
sist<strong>em</strong>a <strong>de</strong> replicação e<br />
reservas<br />
sist<strong>em</strong>a <strong>de</strong> comunicações<br />
sentado <strong>de</strong> forma in<strong>de</strong>pen<strong>de</strong>nte no capítulo 10.<br />
Servidor Mobisnap<br />
controle <strong>de</strong> execução e<br />
interpretador trx. móveis<br />
sist<strong>em</strong>a <strong>de</strong> replicação e<br />
reservas<br />
sist<strong>em</strong>a <strong>de</strong> notificação<br />
sist<strong>em</strong>a <strong>de</strong> comunicações<br />
BD<br />
réplica<br />
principal<br />
Cliente Mobisnap<br />
controle <strong>de</strong> execução e<br />
interpretador trx. móveis<br />
sist<strong>em</strong>a <strong>de</strong> replicação e<br />
reservas<br />
sist<strong>em</strong>a <strong>de</strong> comunicações<br />
Figura 7.2: Arquitectura do sist<strong>em</strong>a Mobisnap.<br />
BD<br />
réplica<br />
cliente<br />
legado<br />
Aproximação evolutiva O mo<strong>de</strong>lo do sist<strong>em</strong>a Mobisnap é evolutivo, pois permite que aplicações que<br />
não us<strong>em</strong> o sist<strong>em</strong>a Mobisnap continu<strong>em</strong> a ace<strong>de</strong>r directamente à base <strong>de</strong> <strong>dados</strong> central. O sist<strong>em</strong>a ga-<br />
rante o funcionamento correcto dos mecanismos propostos no sist<strong>em</strong>a Mobisnap (transacções móveis,<br />
reservas e reconciliação <strong>de</strong> múltiplas transacções) in<strong>de</strong>pen<strong>de</strong>nt<strong>em</strong>ente <strong>de</strong> qualquer modificação concor-<br />
rente executada na base <strong>de</strong> <strong>dados</strong> central.<br />
Adicionalmente, o sist<strong>em</strong>a baseia-se na utilização <strong>de</strong> linguagens normalizadas (SQL e PL/SQL).<br />
Esta característica, ao permitir que os programadores utiliz<strong>em</strong> as funcionalida<strong>de</strong>s do sist<strong>em</strong>a através <strong>de</strong><br />
ferramentas que lhe são familiares permite facilitar o <strong>de</strong>senvolvimento <strong>de</strong> novas aplicações que utiliz<strong>em</strong><br />
as novas funcionalida<strong>de</strong>s (como se discutiu na secção 2.3.8).<br />
7.2 Arquitectura<br />
A arquitectura do sist<strong>em</strong>a Mobisnap é baseada no mo<strong>de</strong>lo cliente estendido/servidor [78], como se re-<br />
presenta na figura 7.2. O servidor <strong>de</strong>ve executar numa máquina com boa conectivida<strong>de</strong> (<strong>em</strong> geral, um<br />
computador fixo). O servidor mantém o estado “oficial” dos <strong>dados</strong>, ou seja, a réplica principal (e com-<br />
pleta) da base <strong>de</strong> <strong>dados</strong>. Os clientes po<strong>de</strong>m ser computadores fixos ou móveis capazes <strong>de</strong> comunicar com<br />
o servidor. Os clientes mantêm cópias parciais dos <strong>dados</strong>.<br />
O Mobisnap é <strong>de</strong>senhado (e impl<strong>em</strong>entado) como uma camada <strong>de</strong> sist<strong>em</strong>a intermédia (middleware).<br />
Assim, o Mobisnap utiliza um sist<strong>em</strong>a <strong>de</strong> <strong>gestão</strong> <strong>de</strong> bases <strong>de</strong> <strong>dados</strong> para gerir os <strong>dados</strong> no cliente e no<br />
servidor. As funcionalida<strong>de</strong>s do sist<strong>em</strong>a Mobisnap são impl<strong>em</strong>entadas pelos componentes do sist<strong>em</strong>a<br />
recorrendo aos serviços básicos fornecidos pelo sist<strong>em</strong>a <strong>de</strong> <strong>gestão</strong> <strong>de</strong> bases <strong>de</strong> <strong>dados</strong>.
Change language