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
190 CAPÍTULO 11. TRABALHO RELACIONADO sobre a evolução dos dados é criada no código das operações através de funções definidas para o efeito. O tratamento desta informação é integrado no sistema, permitindo manter esta informação com os dados ou enviar notificações para os utilizadores usando diferentes transportes. 11.3 Integração de sessões síncronas O problemas da integração de sessões de trabalho síncrono e assíncrono tem sido abordado em vários sistemas de suporte ao trabalho cooperativo. Várias aproximações têm sido propostas. Uma possível aproximação consiste em gravar os eventos produzidos numa sessão cooperativa. Quando um utilizador acede à sessão cooperativa num momento posterior, ele pode observar as acções executadas reproduzindo os eventos armazenados [77, 98]. Greenberg et al. [62] definem um espaço de dados partilhado baseado na noção de quarto (room), onde os utilizadores podem guardar objectos partilhados. As aplicações executam no âmbito de um quarto, podendo um utilizador ligar-se ao servidor central para observar e modificar o estado do quarto (utilizando as aplicações que executam nesse quarto). Os utilizadores que acedem ao mesmo quarto simultaneamente podem modificar um objecto de forma síncrona. As modificações assíncronas resultam do acesso a um quarto em diferentes momentos. O sistema Sepia [67] permite a edição de documentos de hipertexto de forma síncrona e assíncrona usando uma aproximação semelhante. Qu et al. [136] descrevem um ambiente de educação à distância que combina o trabalho síncrono e assíncrono. Um repositório WebDav assíncrono mantém os objectos usando um modelo simples de trincos ou check-in/check-out. Um objecto pode ser manipulado sincronamente (usando o sistema Lotus Sametime). Para tal, o objecto deve ser transferido do repositório assíncrono. As aproximações anteriores não são apropriadas para ambientes de computação móvel porque reque- rem o acesso a um servidor central. Adicionalmente, as primeiras soluções apenas permitem a existência de um único fluxo de actividade (com excepção de períodos de tempo muito curtos durante as sessões síncronas). Assim, a interacção assíncrona restringe-se à manipulação da cópia única de um objecto em diferentes momentos. No ambiente de educação à distância apresentado [136] é possível existirem múl- tiplos fluxos de actividade. No entanto, os conflitos são resolvidos criando múltiplas versões do objecto, i.e., não é possível integrar automaticamente as modificações executadas durante estas sessões. O sistema Prospero [42] permite a manipulação concorrente de cópias de um mesmo objecto. Este sistema é baseado no conceito de stream, no qual se guardam as operações executadas em cada fluxo de actividade. A implementação de aplicações síncronas e assíncronas é possível usando diferentes frequências da sincronização dos streams. Os streams podem ser usados para integrar sessões síncro- nas e assíncronas fazendo variar a frequência de sincronização, mas apenas quando é possível usar as
11.3. INTEGRAÇÃO DE SESSÕES SÍNCRONAS 191 mesmas operações e mecanismos de controlo de concorrência. Uma aproximação semelhante é proposta em [154]. O sistema SAMS [105] permite a edição de documentos estruturados em modo síncrono, assíncrono e multi-síncrono. A diferença entre os vários modos reside no período de tempo que cada elemento do sistema armazena as operações executadas antes de as propagar para os outros elementos do sistema. A integração, em cada réplica local, das operações executadas concorrentemente é efectuada de forma idêntica em todos os modos através da reexecução das operações e recorrendo a um mecanismo de transformação de operações. No entanto, como se discutiu na secção 4.4.1, existem aplicações que necessitam de usar operações e mecanismos de reconciliação diferentes durante as sessões síncronas e assíncronas. No âmbito do sistema DOORS, propôs-se uma solução genérica para a integração de sessões síncronas e assíncronas com essas propriedades.
- 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
- Page 175 and 176: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 177 and 178: 10.4. OPTIMIZAÇÃO DA RECONCILIAÇ
- Page 179 and 180: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 181 and 182: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 183 and 184: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 185 and 186: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 187 and 188: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 189 and 190: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 191 and 192: Capítulo 11 Trabalho relacionado A
- Page 193 and 194: 11.1. REPLICAÇÃO 175 11.1.2 Arqui
- Page 195 and 196: 11.1. REPLICAÇÃO 177 a unidade de
- Page 197 and 198: 11.1. REPLICAÇÃO 179 O mecanismo
- Page 199 and 200: 11.1. REPLICAÇÃO 181 dade 3 . Est
- Page 201 and 202: 11.1. REPLICAÇÃO 183 e ser propag
- Page 203 and 204: 11.1. REPLICAÇÃO 185 ordem de exe
- Page 205 and 206: 11.1. REPLICAÇÃO 187 execução d
- Page 207: 11.2. INFORMAÇÃO SOBRE A EVOLUÇ
- Page 211 and 212: Capítulo 12 Conclusões A generali
- Page 213 and 214: 12.1. SUMÁRIO 195 é executado no
- Page 215 and 216: Apêndice A DOORS Este apêndice ap
- Page 217 and 218: A.1. FILIAÇÃO 199 A operação de
- Page 219 and 220: A.1. FILIAÇÃO 201 anterior à de
- Page 221 and 222: A.1. FILIAÇÃO 203 associados e o
- Page 223 and 224: A.1. FILIAÇÃO 205 Actualização
- Page 225 and 226: A.1. FILIAÇÃO 207 • Periodicame
- Page 227 and 228: A.1. FILIAÇÃO 209 estas situaçõ
- Page 229 and 230: A.1. FILIAÇÃO 211 2. Um servidor
- Page 231 and 232: A.2. SINCRONIZAÇÃO EPIDÉMICA 213
- Page 233 and 234: A.2. SINCRONIZAÇÃO EPIDÉMICA 215
- Page 235 and 236: A.2. SINCRONIZAÇÃO EPIDÉMICA 217
- Page 237 and 238: A.2. SINCRONIZAÇÃO EPIDÉMICA 219
- Page 239 and 240: Apêndice B Mobisnap B.1 Transacç
- Page 241 and 242: Bibliografia [1] S. Agarwal, D. Sta
- Page 243 and 244: BIBLIOGRAFIA 225 [22] Michael J. Ca
- Page 245 and 246: BIBLIOGRAFIA 227 [45] Sérgio Duart
- Page 247 and 248: BIBLIOGRAFIA 229 [67] Jörg M. Haak
- Page 249 and 250: BIBLIOGRAFIA 231 [92] David Lacey,
- Page 251 and 252: BIBLIOGRAFIA 233 [120] Vern E. Paxs
- Page 253 and 254: BIBLIOGRAFIA 235 [139] David Ratner
- Page 255: BIBLIOGRAFIA 237 third internationa
190 CAPÍTULO 11. TRABALHO RELACIONADO<br />
sobre a evolução dos <strong>dados</strong> é criada no código das operações através <strong>de</strong> funções <strong>de</strong>finidas para o efeito.<br />
O tratamento <strong>de</strong>sta informação é integrado no sist<strong>em</strong>a, permitindo manter esta informação com os <strong>dados</strong><br />
ou enviar notificações para os utilizadores usando diferentes transportes.<br />
11.3 Integração <strong>de</strong> sessões síncronas<br />
O probl<strong>em</strong>as da integração <strong>de</strong> sessões <strong>de</strong> trabalho síncrono e assíncrono t<strong>em</strong> sido abordado <strong>em</strong> vários<br />
sist<strong>em</strong>as <strong>de</strong> suporte ao trabalho cooperativo. Várias aproximações têm sido propostas.<br />
Uma possível aproximação consiste <strong>em</strong> gravar os eventos produzidos numa sessão cooperativa.<br />
Quando um utilizador ace<strong>de</strong> à sessão cooperativa num momento posterior, ele po<strong>de</strong> observar as acções<br />
executadas reproduzindo os eventos armazenados [77, 98].<br />
Greenberg et al. [62] <strong>de</strong>fin<strong>em</strong> um espaço <strong>de</strong> <strong>dados</strong> partilhado baseado na noção <strong>de</strong> quarto (room),<br />
on<strong>de</strong> os utilizadores po<strong>de</strong>m guardar objectos <strong>partilhados</strong>. As aplicações executam no âmbito <strong>de</strong> um<br />
quarto, po<strong>de</strong>ndo um utilizador ligar-se ao servidor central para observar e modificar o estado do quarto<br />
(utilizando as aplicações que executam nesse quarto). Os utilizadores que ace<strong>de</strong>m ao mesmo quarto<br />
simultaneamente po<strong>de</strong>m modificar um objecto <strong>de</strong> forma síncrona. As modificações assíncronas resultam<br />
do acesso a um quarto <strong>em</strong> diferentes momentos.<br />
O sist<strong>em</strong>a Sepia [67] permite a edição <strong>de</strong> documentos <strong>de</strong> hipertexto <strong>de</strong> forma síncrona e assíncrona<br />
usando uma aproximação s<strong>em</strong>elhante.<br />
Qu et al. [136] <strong>de</strong>screv<strong>em</strong> um ambiente <strong>de</strong> educação à distância que combina o trabalho síncrono<br />
e assíncrono. Um repositório WebDav assíncrono mantém os objectos usando um mo<strong>de</strong>lo simples <strong>de</strong><br />
trincos ou check-in/check-out. Um objecto po<strong>de</strong> ser manipulado sincronamente (usando o sist<strong>em</strong>a Lotus<br />
Sametime). Para tal, o objecto <strong>de</strong>ve ser transferido do repositório assíncrono.<br />
As aproximações anteriores não são apropriadas para <strong>ambientes</strong> <strong>de</strong> <strong>computação</strong> <strong>móvel</strong> porque reque-<br />
r<strong>em</strong> o acesso a um servidor central. Adicionalmente, as primeiras soluções apenas permit<strong>em</strong> a existência<br />
<strong>de</strong> um único fluxo <strong>de</strong> activida<strong>de</strong> (com excepção <strong>de</strong> períodos <strong>de</strong> t<strong>em</strong>po muito curtos durante as sessões<br />
síncronas). Assim, a interacção assíncrona restringe-se à manipulação da cópia única <strong>de</strong> um objecto <strong>em</strong><br />
diferentes momentos. No ambiente <strong>de</strong> educação à distância apresentado [136] é possível existir<strong>em</strong> múl-<br />
tiplos fluxos <strong>de</strong> activida<strong>de</strong>. No entanto, os conflitos são resolvidos criando múltiplas versões do objecto,<br />
i.e., não é possível integrar automaticamente as modificações executadas durante estas sessões.<br />
O sist<strong>em</strong>a Prospero [42] permite a manipulação concorrente <strong>de</strong> cópias <strong>de</strong> um mesmo objecto. Este<br />
sist<strong>em</strong>a é baseado no conceito <strong>de</strong> stream, no qual se guardam as operações executadas <strong>em</strong> cada fluxo<br />
<strong>de</strong> activida<strong>de</strong>. A impl<strong>em</strong>entação <strong>de</strong> aplicações síncronas e assíncronas é possível usando diferentes<br />
frequências da sincronização dos streams. Os streams po<strong>de</strong>m ser usados para integrar sessões síncro-<br />
nas e assíncronas fazendo variar a frequência <strong>de</strong> sincronização, mas apenas quando é possível usar as